diff -Nrcpad gcc-13.4.0/INSTALL/binaries.html gcc-13.5.0-RC-20260904/INSTALL/binaries.html *** gcc-13.4.0/INSTALL/binaries.html Thu Jun 5 16:05:04 2025 --- gcc-13.5.0-RC-20260904/INSTALL/binaries.html Fri Sep 4 07:35:16 2026 *************** *** 1,9 **** ! ! ! ! --- 33,39 ---- *************** ul.no-bullet {list-style: none} *** 55,61 **** -

Installing GCC: Binaries

--- 41,46 ---- *************** ul.no-bullet {list-style: none} *** 82,89 **** ! !

We are often asked about pre-compiled versions of GCC. While we cannot provide these for all platforms, below you’ll find links to binaries for --- 67,74 ---- ! !

We are often asked about pre-compiled versions of GCC. While we cannot provide these for all platforms, below you’ll find links to binaries for *************** reasons. *** 94,136 **** support them. If you have any problems installing them, please contact their makers.

!

!

Return to the GCC Installation page

--- 79,121 ---- support them. If you have any problems installing them, please contact their makers.

!

!

Return to the GCC Installation page

diff -Nrcpad gcc-13.4.0/INSTALL/build.html gcc-13.5.0-RC-20260904/INSTALL/build.html *** gcc-13.4.0/INSTALL/build.html Thu Jun 5 16:05:04 2025 --- gcc-13.5.0-RC-20260904/INSTALL/build.html Fri Sep 4 07:35:15 2026 *************** *** 1,9 **** ! ! ! ! --- 33,42 ---- *************** ul.no-bullet {list-style: none} *** 55,61 **** -

Installing GCC: Building

--- 44,49 ---- *************** ul.no-bullet {list-style: none} *** 79,91 **** !

Now that GCC is configured, you are ready to build the compiler and runtime libraries.

Some commands executed when making the compiler may fail (return a ! nonzero status) and be ignored by make. These failures, which are often due to files that were not found, are expected, and can safely be ignored.

--- 67,79 ---- !

Now that GCC is configured, you are ready to build the compiler and runtime libraries.

Some commands executed when making the compiler may fail (return a ! nonzero status) and be ignored by make. These failures, which are often due to files that were not found, are expected, and can safely be ignored.

*************** Unless you are a GCC developer, you can *** 94,103 **** unless they cause compilation to fail. Developers should attempt to fix any warnings encountered, however they can temporarily continue past warnings-as-errors by specifying the configure flag ! --disable-werror.

On certain old systems, defining certain environment variables such as ! CC can interfere with the functioning of make.

If you encounter seemingly strange errors when trying to build the compiler in a directory other than the source directory, it could be --- 82,91 ---- unless they cause compilation to fail. Developers should attempt to fix any warnings encountered, however they can temporarily continue past warnings-as-errors by specifying the configure flag ! --disable-werror.

On certain old systems, defining certain environment variables such as ! CC can interfere with the functioning of make.

If you encounter seemingly strange errors when trying to build the compiler in a directory other than the source directory, it could be *************** because you have previously configured t *** 105,121 **** directory. Make sure you have done all the necessary preparations.

If you build GCC on a BSD system using a directory stored in an old System ! V file system, problems may occur in running fixincludes if the System V file system doesn’t support symbolic links. These problems ! result in a failure to fix the declaration of size_t in ! sys/types.h. If you find that size_t is a signed type and that type mismatches occur, this could be the cause.

The solution is not to use such a directory for building GCC.

Similarly, when building from the source repository or snapshots, or if you modify ! *.l files, you need the Flex lexical analyzer generator ! installed. If you do not modify *.l files, releases contain the Flex-generated files and you do not need Flex installed to build them. There is still one Flex-based lexical analyzer (part of the build machinery, not of GCC itself) that is used even if you only --- 93,109 ---- directory. Make sure you have done all the necessary preparations.

If you build GCC on a BSD system using a directory stored in an old System ! V file system, problems may occur in running fixincludes if the System V file system doesn’t support symbolic links. These problems ! result in a failure to fix the declaration of size_t in ! sys/types.h. If you find that size_t is a signed type and that type mismatches occur, this could be the cause.

The solution is not to use such a directory for building GCC.

Similarly, when building from the source repository or snapshots, or if you modify ! *.l files, you need the Flex lexical analyzer generator ! installed. If you do not modify *.l files, releases contain the Flex-generated files and you do not need Flex installed to build them. There is still one Flex-based lexical analyzer (part of the build machinery, not of GCC itself) that is used even if you only *************** documentation, you need version 4.7 or l *** 126,332 **** want Info documentation to be regenerated. Releases contain Info documentation pre-built for the unmodified documentation in the release.

!
!

Building a native compiler

For a native build, the default configuration is to perform ! a 3-stage bootstrap of the compiler when ‘make’ is invoked. This will build the entire GCC system and ensure that it compiles ! itself correctly. It can be disabled with the --disable-bootstrap ! parameter to ‘configure’, but bootstrapping is suggested because the compiler will be tested more completely and could also have better performance.

The bootstrapping process will complete the following steps:

! !

If you are short on disk space you might consider ‘make bootstrap-lean’ instead. The sequence of compilation is the same described above, but object files from the stage1 and stage2 of the 3-stage bootstrap of the compiler are deleted as soon as they are no longer needed.

If you wish to use non-default GCC flags when compiling the stage2 ! and stage3 compilers, set BOOT_CFLAGS on the command line when ! doing ‘make’. For example, if you want to save additional space during the bootstrap and in the final installation as well, you can build the compiler binaries without debugging information as in the following example. This will save roughly 40% of disk space both for the bootstrap and the final installation. (Libraries will still contain debugging information.)

!
! 
make BOOT_CFLAGS='-O' bootstrap
!

You can place non-default optimization flags into BOOT_CFLAGS; they ! are less well tested here than the default of ‘-g -O2’, but should still work. In a few cases, you may find that you need to specify special ! flags such as -msoft-float here to complete the bootstrap; or, if the native compiler miscompiles the stage1 compiler, you may need ! to work around this, by choosing BOOT_CFLAGS to avoid the parts ! of the stage1 compiler that were miscompiled, or by using ‘make bootstrap4’ to increase the number of stages of bootstrap.

!

BOOT_CFLAGS does not apply to bootstrapped target libraries. Since these are always compiled with the compiler currently being ! bootstrapped, you can use CFLAGS_FOR_TARGET to modify their compilation flags, as for non-bootstrapped target libraries. Again, if the native compiler miscompiles the stage1 compiler, you may need to work around this by avoiding non-working parts of the stage1 ! compiler. Use STAGE1_TFLAGS to this end.

!

If you used the flag --enable-languages=… to restrict the compilers to be built, only those you’ve actually enabled will be built. This will of course only build those runtime libraries, for which the particular compiler has been built. Please note, ! that re-defining LANGUAGES when calling ‘make’ ! does not work anymore!

If the comparison of stage2 and stage3 fails, this normally indicates that the stage2 compiler has compiled GCC incorrectly, and is therefore a potentially serious bug which you should investigate and report. (On a few systems, meaningful comparison of object files is impossible; they always appear “different”. If you encounter this problem, you will ! need to disable comparison in the Makefile.)

If you do not want to bootstrap your compiler, you can configure with ! --disable-bootstrap. In particular cases, you may want to bootstrap your compiler even if the target system is not the same as the one you are building on: for example, you could build a ! powerpc-unknown-linux-gnu toolchain on a ! powerpc64-unknown-linux-gnu host. In this case, pass ! --enable-bootstrap to the configure script.

!

BUILD_CONFIG can be used to bring in additional customization to the build. It can be set to a whitespace-separated list of names. ! For each such NAME, top-level config/NAME.mk will ! be included by the top-level Makefile, bringing in any settings ! it contains. The default BUILD_CONFIG can be set using the ! configure option --with-build-config=NAME.... Some examples of supported build configurations are:

!
!
‘bootstrap-O1’
!

Removes any -O-started option from BOOT_CFLAGS, and adds ! -O1 to it. ‘BUILD_CONFIG=bootstrap-O1’ is equivalent to ! ‘BOOT_CFLAGS='-g -O1'’.

!
‘bootstrap-O3’
!
‘bootstrap-Og’
!

Analogous to bootstrap-O1.

!
‘bootstrap-lto’

Enables Link-Time Optimization for host tools during bootstrapping. ! ‘BUILD_CONFIG=bootstrap-lto’ is equivalent to adding ! -flto to ‘BOOT_CFLAGS’. This option assumes that the host supports the linker plugin (e.g. GNU ld version 2.21 or later or GNU gold version 2.21 or later).

!
‘bootstrap-lto-noplugin’
!

This option is similar to bootstrap-lto, but is intended for hosts that do not support the linker plugin. Without the linker plugin static libraries are not compiled with link-time optimizations. Since ! the GCC middle end and back end are in libbackend.a this means that only the front end is actually LTO optimized.

!
‘bootstrap-lto-lean’
!

This option is similar to bootstrap-lto, but is intended for faster build by only using LTO in the final bootstrap stage. ! With ‘make profiledbootstrap’ the LTO frontend is trained only on generator files.

!
‘bootstrap-debug’

Verifies that the compiler generates the same executable code, whether or not it is asked to emit debug information. To this end, this option builds stage2 host programs without debug information, and uses ! contrib/compare-debug to compare them with the stripped stage3 ! object files. If BOOT_CFLAGS is overridden so as to not enable debug information, stage2 will have it, and stage3 won’t. This option is enabled by default when GCC bootstrapping is enabled, if ! strip can turn object files compiled with and without debug info into identical object files. In addition to better test coverage, this option makes default bootstraps faster and leaner.

!
‘bootstrap-debug-big’

Rather than comparing stripped object files, as in ! bootstrap-debug, this option saves internal compiler dumps during stage2 and stage3 and compares them as well, which helps catch additional potential problems, but at a great cost in terms of disk ! space. It can be specified in addition to ‘bootstrap-debug’.

!
‘bootstrap-debug-lean’
!

This option saves disk space compared with bootstrap-debug-big, but at the expense of some recompilation. Instead of saving the dumps of stage2 and stage3 until the final compare, it uses ! -fcompare-debug to generate, compare and remove the dumps during stage3, repeating the compilation that already took place in stage2, whose dumps were not saved.

!
‘bootstrap-debug-lib’

This option tests executable code invariance over debug information ! generation on target libraries, just like bootstrap-debug-lean tests it on host programs. It builds stage3 libraries with ! -fcompare-debug, and it can be used along with any of the ! bootstrap-debug options above.

!

There aren’t -lean or -big counterparts to this option because most libraries are only build in stage3, so bootstrap compares would not get significant coverage. Moreover, the few libraries built in stage2 are used in stage3 host programs, so we wouldn’t want to compile stage2 libraries with different options for comparison purposes.

!
‘bootstrap-debug-ckovw’

Arranges for error messages to be issued if the compiler built on any ! stage is run without the option -fcompare-debug. This is ! useful to verify the full -fcompare-debug testing coverage. It ! must be used along with bootstrap-debug-lean and ! bootstrap-debug-lib.

!
‘bootstrap-cet’

This option enables Intel CET for host tools during bootstrapping. ! ‘BUILD_CONFIG=bootstrap-cet’ is equivalent to adding ! -fcf-protection to ‘BOOT_CFLAGS’. This option assumes that the host supports Intel CET (e.g. GNU assembler version 2.30 or later).

!
‘bootstrap-time’

Arranges for the run time of each program started by the GCC driver, ! built in any stage, to be logged to time.log, in the top level of the build tree.

!
‘bootstrap-asan’

Compiles GCC itself using Address Sanitization in order to catch invalid memory accesses within the GCC code.

!
‘bootstrap-hwasan’

Compiles GCC itself using HWAddress Sanitization in order to catch invalid memory accesses within the GCC code. This option is only available on AArch64 systems that are running Linux kernel version 5.4 or later. --- 114,320 ---- want Info documentation to be regenerated. Releases contain Info documentation pre-built for the unmodified documentation in the release.

!
!

Building a native compiler

For a native build, the default configuration is to perform ! a 3-stage bootstrap of the compiler when ‘make’ is invoked. This will build the entire GCC system and ensure that it compiles ! itself correctly. It can be disabled with the --disable-bootstrap ! parameter to ‘configure’, but bootstrapping is suggested because the compiler will be tested more completely and could also have better performance.

The bootstrapping process will complete the following steps:

!
    !
  • Build tools necessary to build the compiler. !
  • Perform a 3-stage bootstrap of the compiler. This includes building three times the target tools for use by the compiler such as binutils (bfd, binutils, gas, gprof, ld, and opcodes) if they have been individually linked or moved into the top level GCC source tree before configuring. !
  • Perform a comparison test of the stage2 and stage3 compilers. !
  • Build runtime libraries using the stage3 compiler from the previous step.
!

If you are short on disk space you might consider ‘make bootstrap-lean’ instead. The sequence of compilation is the same described above, but object files from the stage1 and stage2 of the 3-stage bootstrap of the compiler are deleted as soon as they are no longer needed.

If you wish to use non-default GCC flags when compiling the stage2 ! and stage3 compilers, set BOOT_CFLAGS on the command line when ! doing ‘make’. For example, if you want to save additional space during the bootstrap and in the final installation as well, you can build the compiler binaries without debugging information as in the following example. This will save roughly 40% of disk space both for the bootstrap and the final installation. (Libraries will still contain debugging information.)

!
! 
make BOOT_CFLAGS='-O' bootstrap
!

You can place non-default optimization flags into BOOT_CFLAGS; they ! are less well tested here than the default of ‘-g -O2’, but should still work. In a few cases, you may find that you need to specify special ! flags such as -msoft-float here to complete the bootstrap; or, if the native compiler miscompiles the stage1 compiler, you may need ! to work around this, by choosing BOOT_CFLAGS to avoid the parts ! of the stage1 compiler that were miscompiled, or by using ‘make bootstrap4’ to increase the number of stages of bootstrap.

!

BOOT_CFLAGS does not apply to bootstrapped target libraries. Since these are always compiled with the compiler currently being ! bootstrapped, you can use CFLAGS_FOR_TARGET to modify their compilation flags, as for non-bootstrapped target libraries. Again, if the native compiler miscompiles the stage1 compiler, you may need to work around this by avoiding non-working parts of the stage1 ! compiler. Use STAGE1_TFLAGS to this end.

!

If you used the flag --enable-languages=… to restrict the compilers to be built, only those you’ve actually enabled will be built. This will of course only build those runtime libraries, for which the particular compiler has been built. Please note, ! that re-defining LANGUAGES when calling ‘make’ ! does not work anymore!

If the comparison of stage2 and stage3 fails, this normally indicates that the stage2 compiler has compiled GCC incorrectly, and is therefore a potentially serious bug which you should investigate and report. (On a few systems, meaningful comparison of object files is impossible; they always appear “different”. If you encounter this problem, you will ! need to disable comparison in the Makefile.)

If you do not want to bootstrap your compiler, you can configure with ! --disable-bootstrap. In particular cases, you may want to bootstrap your compiler even if the target system is not the same as the one you are building on: for example, you could build a ! powerpc-unknown-linux-gnu toolchain on a ! powerpc64-unknown-linux-gnu host. In this case, pass ! --enable-bootstrap to the configure script.

!

BUILD_CONFIG can be used to bring in additional customization to the build. It can be set to a whitespace-separated list of names. ! For each such NAME, top-level config/NAME.mk will ! be included by the top-level Makefile, bringing in any settings ! it contains. The default BUILD_CONFIG can be set using the ! configure option --with-build-config=NAME.... Some examples of supported build configurations are:

!
!
‘bootstrap-O1’
!

Removes any -O-started option from BOOT_CFLAGS, and adds ! -O1 to it. ‘BUILD_CONFIG=bootstrap-O1’ is equivalent to ! ‘BOOT_CFLAGS='-g -O1'’.

!
‘bootstrap-O3’
!
‘bootstrap-Og’
!

Analogous to bootstrap-O1.

!
‘bootstrap-lto’

Enables Link-Time Optimization for host tools during bootstrapping. ! ‘BUILD_CONFIG=bootstrap-lto’ is equivalent to adding ! -flto to ‘BOOT_CFLAGS’. This option assumes that the host supports the linker plugin (e.g. GNU ld version 2.21 or later or GNU gold version 2.21 or later).

!
‘bootstrap-lto-noplugin’
!

This option is similar to bootstrap-lto, but is intended for hosts that do not support the linker plugin. Without the linker plugin static libraries are not compiled with link-time optimizations. Since ! the GCC middle end and back end are in libbackend.a this means that only the front end is actually LTO optimized.

!
‘bootstrap-lto-lean’
!

This option is similar to bootstrap-lto, but is intended for faster build by only using LTO in the final bootstrap stage. ! With ‘make profiledbootstrap’ the LTO frontend is trained only on generator files.

!
‘bootstrap-debug’

Verifies that the compiler generates the same executable code, whether or not it is asked to emit debug information. To this end, this option builds stage2 host programs without debug information, and uses ! contrib/compare-debug to compare them with the stripped stage3 ! object files. If BOOT_CFLAGS is overridden so as to not enable debug information, stage2 will have it, and stage3 won’t. This option is enabled by default when GCC bootstrapping is enabled, if ! strip can turn object files compiled with and without debug info into identical object files. In addition to better test coverage, this option makes default bootstraps faster and leaner.

!
‘bootstrap-debug-big’

Rather than comparing stripped object files, as in ! bootstrap-debug, this option saves internal compiler dumps during stage2 and stage3 and compares them as well, which helps catch additional potential problems, but at a great cost in terms of disk ! space. It can be specified in addition to ‘bootstrap-debug’.

!
‘bootstrap-debug-lean’
!

This option saves disk space compared with bootstrap-debug-big, but at the expense of some recompilation. Instead of saving the dumps of stage2 and stage3 until the final compare, it uses ! -fcompare-debug to generate, compare and remove the dumps during stage3, repeating the compilation that already took place in stage2, whose dumps were not saved.

!
‘bootstrap-debug-lib’

This option tests executable code invariance over debug information ! generation on target libraries, just like bootstrap-debug-lean tests it on host programs. It builds stage3 libraries with ! -fcompare-debug, and it can be used along with any of the ! bootstrap-debug options above.

!

There aren’t -lean or -big counterparts to this option because most libraries are only build in stage3, so bootstrap compares would not get significant coverage. Moreover, the few libraries built in stage2 are used in stage3 host programs, so we wouldn’t want to compile stage2 libraries with different options for comparison purposes.

!
‘bootstrap-debug-ckovw’

Arranges for error messages to be issued if the compiler built on any ! stage is run without the option -fcompare-debug. This is ! useful to verify the full -fcompare-debug testing coverage. It ! must be used along with bootstrap-debug-lean and ! bootstrap-debug-lib.

!
‘bootstrap-cet’

This option enables Intel CET for host tools during bootstrapping. ! ‘BUILD_CONFIG=bootstrap-cet’ is equivalent to adding ! -fcf-protection to ‘BOOT_CFLAGS’. This option assumes that the host supports Intel CET (e.g. GNU assembler version 2.30 or later).

!
‘bootstrap-time’

Arranges for the run time of each program started by the GCC driver, ! built in any stage, to be logged to time.log, in the top level of the build tree.

!
‘bootstrap-asan’

Compiles GCC itself using Address Sanitization in order to catch invalid memory accesses within the GCC code.

!
‘bootstrap-hwasan’

Compiles GCC itself using HWAddress Sanitization in order to catch invalid memory accesses within the GCC code. This option is only available on AArch64 systems that are running Linux kernel version 5.4 or later. *************** systems that are running Linux kernel ve *** 335,342 ****

!
!

Building a cross compiler

When building a cross compiler, it is not generally possible to do a 3-stage bootstrap of the compiler. This makes for an interesting problem --- 323,330 ----

!
!

Building a cross compiler

When building a cross compiler, it is not generally possible to do a 3-stage bootstrap of the compiler. This makes for an interesting problem *************** cross compiler. The installed native co *** 348,367 **** 2.95 or later.

Assuming you have already installed a native copy of GCC and configured ! your cross compiler, issue the command make, which performs the following steps:

!

Note that if an error occurs in any step the make process will exit. --- 336,355 ---- 2.95 or later.

Assuming you have already installed a native copy of GCC and configured ! your cross compiler, issue the command make, which performs the following steps:

!

Note that if an error occurs in any step the make process will exit. *************** tree before configuring. *** 369,392 ****

If you are not building GNU binutils in the same source tree as GCC, you will need a cross-assembler and cross-linker installed before configuring GCC. Put them in the directory ! prefix/target/bin. Here is a table of the tools you should put in this directory:

!
!
as

This should be the cross-assembler.

!
ld

This should be the cross-linker.

!
ar

This should be the cross-archiver: a program which can manipulate archive files (linker libraries) in the target machine’s format.

!
ranlib

This should be a program to construct a symbol table in an archive file.

--- 357,380 ----

If you are not building GNU binutils in the same source tree as GCC, you will need a cross-assembler and cross-linker installed before configuring GCC. Put them in the directory ! prefix/target/bin. Here is a table of the tools you should put in this directory:

!
!
as

This should be the cross-assembler.

!
ld

This should be the cross-linker.

!
ar

This should be the cross-archiver: a program which can manipulate archive files (linker libraries) in the target machine’s format.

!
ranlib

This should be a program to construct a symbol table in an archive file.

*************** and copy or link them to the proper plac *** 396,402 **** find them when run later.

The easiest way to provide these files is to build the Binutils package. ! Configure it with the same --host and --target options that you use for configuring GCC, then build and install them. They install their executables automatically into the proper directory. Alas, they do not support all the targets that GCC --- 384,390 ---- find them when run later.

The easiest way to provide these files is to build the Binutils package. ! Configure it with the same --host and --target options that you use for configuring GCC, then build and install them. They install their executables automatically into the proper directory. Alas, they do not support all the targets that GCC *************** supports. *** 405,467 ****

If you are not building a C library in the same source tree as GCC, you should also provide the target libraries and headers before configuring GCC, specifying the directories with ! --with-sysroot or --with-headers and ! --with-libs. Many targets also require “start files” such ! as crt0.o and ! crtn.o which are linked into each executable. There may be several ! alternatives for crt0.o, for use with profiling or other compilation options. Check your target’s definition of ! STARTFILE_SPEC to find out what start files it uses.

!
!

Building in parallel

GNU Make 3.80 and above, which is necessary to build GCC, support ! building in parallel. To activate this, you can use ‘make -j 2’ ! instead of ‘make’. You can also specify a bigger number, and in most cases using a value greater than the number of processors in your machine will result in fewer and shorter I/O latency hits, thus improving overall throughput; this is especially true for slow drives and network filesystems.

!
!

Building the Ada compiler

!

GNAT prerequisites.

!
!

Building the D compiler

!

GDC prerequisites.

!
!

Building with profile feedback

It is possible to use profile feedback to optimize the compiler itself. This should result in a faster compiler binary. Experiments done on x86 using gcc 3.3 showed approximately 7 percent speedup on compiling C programs. To ! bootstrap the compiler with profile feedback, use make profiledbootstrap.

!

When ‘make profiledbootstrap’ is run, it will first build a stage1 ! compiler. This compiler is used to build a stageprofile compiler instrumented to collect execution counts of instruction and branch ! probabilities. Training run is done by building stagetrain ! compiler. Finally a stagefeedback compiler is built using the information collected.

Unlike standard bootstrap, several additional restrictions apply. The ! compiler used to build stage1 needs to support a 64-bit integral type. It is recommended to only use GCC for this.

On Linux/x86_64 hosts with some restrictions (no virtualization) it is ! also possible to do autofdo build with ‘make autoprofiledback’. This uses Linux perf to sample branches in the binary and then rebuild it with feedback derived from the profile. ! Linux perf and the autofdo toolkit needs to be installed for this.

Only the profile from the current build is used, so when an error --- 393,455 ----

If you are not building a C library in the same source tree as GCC, you should also provide the target libraries and headers before configuring GCC, specifying the directories with ! --with-sysroot or --with-headers and ! --with-libs. Many targets also require “start files” such ! as crt0.o and ! crtn.o which are linked into each executable. There may be several ! alternatives for crt0.o, for use with profiling or other compilation options. Check your target’s definition of ! STARTFILE_SPEC to find out what start files it uses.

!
!

Building in parallel

GNU Make 3.80 and above, which is necessary to build GCC, support ! building in parallel. To activate this, you can use ‘make -j 2’ ! instead of ‘make’. You can also specify a bigger number, and in most cases using a value greater than the number of processors in your machine will result in fewer and shorter I/O latency hits, thus improving overall throughput; this is especially true for slow drives and network filesystems.

!
!

Building the Ada compiler

!

GNAT prerequisites.

!
!

Building the D compiler

!

GDC prerequisites.

!
!

Building with profile feedback

It is possible to use profile feedback to optimize the compiler itself. This should result in a faster compiler binary. Experiments done on x86 using gcc 3.3 showed approximately 7 percent speedup on compiling C programs. To ! bootstrap the compiler with profile feedback, use make profiledbootstrap.

!

When ‘make profiledbootstrap’ is run, it will first build a stage1 ! compiler. This compiler is used to build a stageprofile compiler instrumented to collect execution counts of instruction and branch ! probabilities. Training run is done by building stagetrain ! compiler. Finally a stagefeedback compiler is built using the information collected.

Unlike standard bootstrap, several additional restrictions apply. The ! compiler used to build stage1 needs to support a 64-bit integral type. It is recommended to only use GCC for this.

On Linux/x86_64 hosts with some restrictions (no virtualization) it is ! also possible to do autofdo build with ‘make autoprofiledback’. This uses Linux perf to sample branches in the binary and then rebuild it with feedback derived from the profile. ! Linux perf and the autofdo toolkit needs to be installed for this.

Only the profile from the current build is used, so when an error *************** the code quality may be much worse. *** 470,476 ****

!

Return to the GCC Installation page

--- 458,464 ----

!

Return to the GCC Installation page

*************** the code quality may be much worse. *** 478,484 **** !
--- 466,472 ---- ! diff -Nrcpad gcc-13.4.0/INSTALL/configure.html gcc-13.5.0-RC-20260904/INSTALL/configure.html *** gcc-13.4.0/INSTALL/configure.html Thu Jun 5 16:05:03 2025 --- gcc-13.5.0-RC-20260904/INSTALL/configure.html Fri Sep 4 07:35:15 2026 *************** *** 1,9 **** ! ! ! ! --- 33,43 ---- *************** ul.no-bullet {list-style: none} *** 55,61 **** -

Installing GCC: Configuration

--- 45,50 ---- *************** ul.no-bullet {list-style: none} *** 78,153 **** ! !

Like most GNU software, GCC must be configured before it can be built. This document describes the recommended configuration procedure for both native and cross targets.

!

We use srcdir to refer to the toplevel source directory for ! GCC; we use objdir to refer to the toplevel build/object directory.

!

If you obtained the sources by cloning the repository, srcdir ! must refer to the top gcc directory, the one where the ! MAINTAINERS file can be found, and not its gcc subdirectory, otherwise the build will fail.

!

If either srcdir or objdir is located on an automounted NFS ! file system, the shell’s built-in pwd command will return temporary pathnames. Using these can lead to various sorts of build ! problems. To avoid this issue, set the PWDCMD environment ! variable to an automounter-aware pwd command, e.g., ! pawd or ‘amq -w’, during the configuration and build phases.

!

First, we highly recommend that GCC be built into a ! separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building ! where srcdir == objdir should still work, but doesn’t ! get extensive testing; building where objdir is a subdirectory ! of srcdir is unsupported.

If you have previously built GCC in the same directory for a ! different target machine, do ‘make distclean’ to delete all files ! that might be invalid. One of the files this deletes is Makefile; ! if ‘make distclean’ complains that Makefile does not exist or issues a message like “don’t know how to make distclean” it probably means that the directory is already suitably clean. However, with the ! recommended method of building in a separate objdir, you should ! simply use a different objdir for each target.

!

Second, when configuring a native system, either cc or ! gcc must be in your path or you must set CC in your environment before running configure. Otherwise the configuration scripts may fail.

To configure GCC:

!
! 
% mkdir objdir
! % cd objdir
! % srcdir/configure [options] [target]
!

Distributor options

If you will be distributing binary versions of GCC, with modifications to the source code, you should use the options described in this section to make clear that your version contains modifications.

!
!
--with-pkgversion=version

Specify a string that identifies your package. You may wish to include a build number or build date. This version string will be ! included in the output of gcc --version. This suffix does ! not replace the default version string, only the ‘GCC’ part.

!

The default value is ‘GCC’.

!
--with-bugurl=url

Specify the URL that users should visit if they wish to report a bug. You are of course welcome to forward bugs reported to you to the FSF, if you determine that they are not bugs in your modifications. --- 67,142 ---- ! !

Like most GNU software, GCC must be configured before it can be built. This document describes the recommended configuration procedure for both native and cross targets.

!

We use srcdir to refer to the toplevel source directory for ! GCC; we use objdir to refer to the toplevel build/object directory.

!

If you obtained the sources by cloning the repository, srcdir ! must refer to the top gcc directory, the one where the ! MAINTAINERS file can be found, and not its gcc subdirectory, otherwise the build will fail.

!

If either srcdir or objdir is located on an automounted NFS ! file system, the shell’s built-in pwd command will return temporary pathnames. Using these can lead to various sorts of build ! problems. To avoid this issue, set the PWDCMD environment ! variable to an automounter-aware pwd command, e.g., ! pawd or ‘amq -w’, during the configuration and build phases.

!

First, we highly recommend that GCC be built into a ! separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building ! where srcdir == objdir should still work, but doesn’t ! get extensive testing; building where objdir is a subdirectory ! of srcdir is unsupported.

If you have previously built GCC in the same directory for a ! different target machine, do ‘make distclean’ to delete all files ! that might be invalid. One of the files this deletes is Makefile; ! if ‘make distclean’ complains that Makefile does not exist or issues a message like “don’t know how to make distclean” it probably means that the directory is already suitably clean. However, with the ! recommended method of building in a separate objdir, you should ! simply use a different objdir for each target.

!

Second, when configuring a native system, either cc or ! gcc must be in your path or you must set CC in your environment before running configure. Otherwise the configuration scripts may fail.

To configure GCC:

!
! 
% mkdir objdir
! % cd objdir
! % srcdir/configure [options] [target]
!

Distributor options

If you will be distributing binary versions of GCC, with modifications to the source code, you should use the options described in this section to make clear that your version contains modifications.

!
!
--with-pkgversion=version

Specify a string that identifies your package. You may wish to include a build number or build date. This version string will be ! included in the output of gcc --version. This suffix does ! not replace the default version string, only the ‘GCC’ part.

!

The default value is ‘GCC’.

!
--with-bugurl=url

Specify the URL that users should visit if they wish to report a bug. You are of course welcome to forward bugs reported to you to the FSF, if you determine that they are not bugs in your modifications. *************** if you determine that they are not bugs *** 155,214 ****

The default value refers to the FSF’s GCC bug tracker.

!
--with-documentation-root-url=url
!

Specify the URL root that contains GCC option documentation. The url ! should end with a / character.

!

The default value is https://gcc.gnu.org/onlinedocs/.

!
--with-changes-root-url=url

Specify the URL root that contains information about changes in GCC ! releases like gcc-version/changes.html. ! The url should end with a / character.

!

The default value is https://gcc.gnu.org/.

!

Host, Build and Target specification

Specify the host, build and target machine configurations. You do this ! when you run the configure script.

!

The build machine is the system which you are using, the ! host machine is the system where you want to run the resulting ! compiler (normally the build machine), and the target machine is the system for which you want the compiler to generate code.

If you are building a compiler to produce code for the machine it runs on (a native compiler), you normally do not need to specify any operands ! to configure; it will try to guess the type of machine you are on and use that as the build, host and target machines. So you don’t need to specify a configuration when building a native compiler unless ! configure cannot figure out what your configuration is or guesses wrong.

!

In those cases, specify the build machine’s configuration name ! with the --host option; the host and target will default to be the same as the host machine.

Here is an example:

!
! 
./configure --host=x86_64-pc-linux-gnu

A configuration name may be canonical or it may be more or less ! abbreviated (config.sub script produces canonical versions).

A canonical configuration name has three parts, separated by dashes. ! It looks like this: ‘cpu-company-system’.

Here are the possible CPU types:

!

aarch64, aarch64_be, alpha, alpha64, amdgcn, arc, arceb, arm, armeb, avr, bfin, bpf, cris, csky, epiphany, fido, fr30, frv, ft32, h8300, hppa, hppa2.0, hppa64, i486, i686, ia64, iq2000, lm32, loongarch64, m32c, m32r, m32rle, m68k, --- 144,203 ----

The default value refers to the FSF’s GCC bug tracker.

!
--with-documentation-root-url=url
!

Specify the URL root that contains GCC option documentation. The url ! should end with a / character.

!

The default value is https://gcc.gnu.org/onlinedocs/.

!
--with-changes-root-url=url

Specify the URL root that contains information about changes in GCC ! releases like gcc-version/changes.html. ! The url should end with a / character.

!

The default value is https://gcc.gnu.org/.

!

Host, Build and Target specification

Specify the host, build and target machine configurations. You do this ! when you run the configure script.

!

The build machine is the system which you are using, the ! host machine is the system where you want to run the resulting ! compiler (normally the build machine), and the target machine is the system for which you want the compiler to generate code.

If you are building a compiler to produce code for the machine it runs on (a native compiler), you normally do not need to specify any operands ! to configure; it will try to guess the type of machine you are on and use that as the build, host and target machines. So you don’t need to specify a configuration when building a native compiler unless ! configure cannot figure out what your configuration is or guesses wrong.

!

In those cases, specify the build machine’s configuration name ! with the --host option; the host and target will default to be the same as the host machine.

Here is an example:

!
! 
./configure --host=x86_64-pc-linux-gnu

A configuration name may be canonical or it may be more or less ! abbreviated (config.sub script produces canonical versions).

A canonical configuration name has three parts, separated by dashes. ! It looks like this: ‘cpu-company-system’.

Here are the possible CPU types:

!

aarch64, aarch64_be, alpha, alpha64, amdgcn, arc, arceb, arm, armeb, avr, bfin, bpf, cris, csky, epiphany, fido, fr30, frv, ft32, h8300, hppa, hppa2.0, hppa64, i486, i686, ia64, iq2000, lm32, loongarch64, m32c, m32r, m32rle, m68k, *************** v850e, v850e1, vax, visium, x86_64, xsto *** 223,379 ****

Here is a list of system types:

!
!

aixversion, amdhsa, aout, cygwin, darwinversion, eabi, eabialtivec, eabisim, eabisimaltivec, elf, elf32, ! elfbare, elfoabi, freebsdversion, gnu, hpux, hpuxversion, kfreebsd-gnu, kopensolaris-gnu, linux-androideabi, linux-gnu, linux-gnu_altivec, linux-musl, linux-uclibc, lynxos, mingw32, mingw32crt, ! mmixware, msdosdjgpp, netbsd, netbsdelfversion, nto-qnx, openbsd, ! rtems, solarisversion, symbianelf, tpf, uclinux, uclinux_eabi, vms, vxworks, vxworksae, vxworksmils

!

Options specification

!

Use options to override several configure time options for ! GCC. A list of supported options follows; ‘configure --help’ may list other options, but those not listed below may not work and should not normally be used.

!

Note that each --enable option has a corresponding ! --disable option and that each --with option has a ! corresponding --without option.

!
!
--prefix=dirname

Specify the toplevel installation directory. This is the recommended way to install the tools into a directory other than the default. The toplevel installation directory defaults to ! /usr/local.

!

We highly recommend against dirname being the same or a ! subdirectory of objdir or vice versa. If specifying a directory beneath a user’s home directory tree, some shells will not expand ! dirname correctly if it contains the ‘~’ metacharacter; use ! $HOME instead.

!

The following standard autoconf options are supported. Normally you should not need to use these options. !

!
--exec-prefix=dirname

Specify the toplevel installation directory for architecture-dependent ! files. The default is prefix.

!
--bindir=dirname

Specify the installation directory for the executables called by users ! (such as gcc and g++). The default is ! exec-prefix/bin.

!
--libdir=dirname

Specify the installation directory for object code libraries and ! internal data files of GCC. The default is exec-prefix/lib.

!
--libexecdir=dirname

Specify the installation directory for internal executables of GCC. ! The default is exec-prefix/libexec.

!
--with-slibdir=dirname

Specify the installation directory for the shared libgcc library. The ! default is libdir.

!
--datarootdir=dirname

Specify the root of the directory tree for read-only architecture-independent ! data files referenced by GCC. The default is prefix/share.

!
--infodir=dirname

Specify the installation directory for documentation in info format. ! The default is datarootdir/info.

!
--datadir=dirname

Specify the installation directory for some architecture-independent ! data files referenced by GCC. The default is datarootdir.

!
--docdir=dirname

Specify the installation directory for documentation files (other ! than Info) for GCC. The default is datarootdir/doc.

!
--htmldir=dirname

Specify the installation directory for HTML documentation files. ! The default is docdir.

!
--pdfdir=dirname

Specify the installation directory for PDF documentation files. ! The default is docdir.

!
--mandir=dirname

Specify the installation directory for manual pages. The default is ! datarootdir/man. (Note that the manual pages are only extracts from the full GCC manuals, which are provided in Texinfo format. The manpages are derived by an automatic conversion process from parts of the full manual.)

!
--with-gxx-include-dir=dirname

Specify the installation directory for G++ header files. The default depends on other configuration options, and differs between cross and native configurations.

!
--with-specs=specs

Specify additional command line driver SPECS. This can be useful if you need to turn on a non-standard feature by default without modifying the compiler’s source code, for instance ! --with-specs=%{!fcommon:%{!fno-common:-fno-common}}. See “Spec Files” in the main manual

!
--program-prefix=prefix

GCC supports some transformations of the names of its programs when ! installing them. This option prepends prefix to the names of ! programs to install in bindir (see above). For example, specifying ! --program-prefix=foo- would result in ‘gcc’ ! being installed as /usr/local/bin/foo-gcc.

!
--program-suffix=suffix
!

Appends suffix to the names of programs to install in bindir ! (see above). For example, specifying --program-suffix=-3.1 ! would result in ‘gcc’ being installed as ! /usr/local/bin/gcc-3.1.

!
--program-transform-name=pattern
!

Applies the ‘sed’ script pattern to be applied to the names ! of programs to install in bindir (see above). pattern has to ! consist of one or more basic ‘sed’ editing commands, separated by ! semicolons. For example, if you want the ‘gcc’ program name to be ! transformed to the installed program /usr/local/bin/myowngcc and ! the ‘g++’ program name to be transformed to ! /usr/local/bin/gspecial++ without changing other program names, you could use the pattern ! --program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/' to achieve this effect.

All three options can be combined and used together, resulting in more ! complex conversion patterns. As a basic rule, prefix (and ! suffix) are prepended (appended) before further transformations ! can happen with a special transformation script pattern.

As currently implemented, this option only takes effect for native builds; cross compiler binaries’ names are not transformed even when a --- 212,368 ----

Here is a list of system types:

!
!

aixversion, amdhsa, aout, cygwin, darwinversion, eabi, eabialtivec, eabisim, eabisimaltivec, elf, elf32, ! elfbare, elfoabi, freebsdversion, gnu, hpux, hpuxversion, kfreebsd-gnu, kopensolaris-gnu, linux-androideabi, linux-gnu, linux-gnu_altivec, linux-musl, linux-uclibc, lynxos, mingw32, mingw32crt, ! mmixware, msdosdjgpp, netbsd, netbsdelfversion, nto-qnx, openbsd, ! rtems, solarisversion, symbianelf, tpf, uclinux, uclinux_eabi, vms, vxworks, vxworksae, vxworksmils

!

Options specification

!

Use options to override several configure time options for ! GCC. A list of supported options follows; ‘configure --help’ may list other options, but those not listed below may not work and should not normally be used.

!

Note that each --enable option has a corresponding ! --disable option and that each --with option has a ! corresponding --without option.

!
!
--prefix=dirname

Specify the toplevel installation directory. This is the recommended way to install the tools into a directory other than the default. The toplevel installation directory defaults to ! /usr/local.

!

We highly recommend against dirname being the same or a ! subdirectory of objdir or vice versa. If specifying a directory beneath a user’s home directory tree, some shells will not expand ! dirname correctly if it contains the ‘~’ metacharacter; use ! $HOME instead.

!

The following standard autoconf options are supported. Normally you should not need to use these options. !

!
--exec-prefix=dirname

Specify the toplevel installation directory for architecture-dependent ! files. The default is prefix.

!
--bindir=dirname

Specify the installation directory for the executables called by users ! (such as gcc and g++). The default is ! exec-prefix/bin.

!
--libdir=dirname

Specify the installation directory for object code libraries and ! internal data files of GCC. The default is exec-prefix/lib.

!
--libexecdir=dirname

Specify the installation directory for internal executables of GCC. ! The default is exec-prefix/libexec.

!
--with-slibdir=dirname

Specify the installation directory for the shared libgcc library. The ! default is libdir.

!
--datarootdir=dirname

Specify the root of the directory tree for read-only architecture-independent ! data files referenced by GCC. The default is prefix/share.

!
--infodir=dirname

Specify the installation directory for documentation in info format. ! The default is datarootdir/info.

!
--datadir=dirname

Specify the installation directory for some architecture-independent ! data files referenced by GCC. The default is datarootdir.

!
--docdir=dirname

Specify the installation directory for documentation files (other ! than Info) for GCC. The default is datarootdir/doc.

!
--htmldir=dirname

Specify the installation directory for HTML documentation files. ! The default is docdir.

!
--pdfdir=dirname

Specify the installation directory for PDF documentation files. ! The default is docdir.

!
--mandir=dirname

Specify the installation directory for manual pages. The default is ! datarootdir/man. (Note that the manual pages are only extracts from the full GCC manuals, which are provided in Texinfo format. The manpages are derived by an automatic conversion process from parts of the full manual.)

!
--with-gxx-include-dir=dirname

Specify the installation directory for G++ header files. The default depends on other configuration options, and differs between cross and native configurations.

!
--with-specs=specs

Specify additional command line driver SPECS. This can be useful if you need to turn on a non-standard feature by default without modifying the compiler’s source code, for instance ! --with-specs=%{!fcommon:%{!fno-common:-fno-common}}. See “Spec Files” in the main manual

!
--program-prefix=prefix

GCC supports some transformations of the names of its programs when ! installing them. This option prepends prefix to the names of ! programs to install in bindir (see above). For example, specifying ! --program-prefix=foo- would result in ‘gcc’ ! being installed as /usr/local/bin/foo-gcc.

!
--program-suffix=suffix
!

Appends suffix to the names of programs to install in bindir ! (see above). For example, specifying --program-suffix=-3.1 ! would result in ‘gcc’ being installed as ! /usr/local/bin/gcc-3.1.

!
--program-transform-name=pattern
!

Applies the ‘sed’ script pattern to be applied to the names ! of programs to install in bindir (see above). pattern has to ! consist of one or more basic ‘sed’ editing commands, separated by ! semicolons. For example, if you want the ‘gcc’ program name to be ! transformed to the installed program /usr/local/bin/myowngcc and ! the ‘g++’ program name to be transformed to ! /usr/local/bin/gspecial++ without changing other program names, you could use the pattern ! --program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/' to achieve this effect.

All three options can be combined and used together, resulting in more ! complex conversion patterns. As a basic rule, prefix (and ! suffix) are prepended (appended) before further transformations ! can happen with a special transformation script pattern.

As currently implemented, this option only takes effect for native builds; cross compiler binaries’ names are not transformed even when a *************** transformation is explicitly asked for b *** 381,418 ****

For native builds, some of the installed programs are also installed with the target alias in front of their name, as in ! ‘i686-pc-linux-gnu-gcc’. All of the above transformations happen before the target alias is prepended to the name—so, specifying ! --program-prefix=foo- and program-suffix=-3.1, the resulting binary would be installed as ! /usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1.

As a last shortcoming, none of the installed Ada programs are transformed yet, which will be fixed in some time.

!
--with-local-prefix=dirname

Specify the installation directory for local include files. The default is ! /usr/local. Specify this option if you want the compiler to ! search directory dirname/include for locally installed ! header files instead of /usr/local/include.

!

You should specify --with-local-prefix only if your ! site has a different convention (not /usr/local) for where to put site-specific files.

!

The default value for --with-local-prefix is /usr/local ! regardless of the value of --prefix. Specifying ! --prefix has no effect on which directory GCC searches for local header files. This may seem counterintuitive, but actually it is logical.

!

The purpose of --prefix is to specify where to install ! GCC. The local header files in /usr/local/include—if you put any in that directory—are not part of GCC. They are part of other programs—perhaps many others. (GCC installs its own header files in ! another directory which is based on the --prefix value.)

Both the local-prefix include directory and the GCC-prefix include directory are part of GCC’s “system include” directories. Although these --- 370,407 ----

For native builds, some of the installed programs are also installed with the target alias in front of their name, as in ! ‘i686-pc-linux-gnu-gcc’. All of the above transformations happen before the target alias is prepended to the name—so, specifying ! --program-prefix=foo- and program-suffix=-3.1, the resulting binary would be installed as ! /usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1.

As a last shortcoming, none of the installed Ada programs are transformed yet, which will be fixed in some time.

!
--with-local-prefix=dirname

Specify the installation directory for local include files. The default is ! /usr/local. Specify this option if you want the compiler to ! search directory dirname/include for locally installed ! header files instead of /usr/local/include.

!

You should specify --with-local-prefix only if your ! site has a different convention (not /usr/local) for where to put site-specific files.

!

The default value for --with-local-prefix is /usr/local ! regardless of the value of --prefix. Specifying ! --prefix has no effect on which directory GCC searches for local header files. This may seem counterintuitive, but actually it is logical.

!

The purpose of --prefix is to specify where to install ! GCC. The local header files in /usr/local/include—if you put any in that directory—are not part of GCC. They are part of other programs—perhaps many others. (GCC installs its own header files in ! another directory which is based on the --prefix value.)

Both the local-prefix include directory and the GCC-prefix include directory are part of GCC’s “system include” directories. Although these *************** local-prefix include directory is search *** 422,462 **** include directory. Another characteristic of system include directories is that pedantic warnings are turned off for headers in these directories.

!

Some autoconf macros add -I directory options to the compiler command line, to ensure that directories containing installed ! packages’ headers are searched. When directory is one of GCC’s system include directories, GCC will ignore the option so that system directories continue to be processed in the correct order. This may result in a search order different from what was specified but the directory will still be searched.

GCC automatically searches for ordinary libraries using ! GCC_EXEC_PREFIX. Thus, when the same installation prefix is used for both GCC and packages, GCC will automatically search for both headers and libraries. This provides a configuration that is easy to use. GCC behaves in a manner similar to that when it is ! installed as a system compiler in /usr.

Sites that need to install multiple versions of GCC may not want to use the above simple configuration. It is possible to use the ! --program-prefix, --program-suffix and ! --program-transform-name options to install multiple versions into a single directory, but it may be simpler to use different prefixes ! and the --with-local-prefix option to specify the location of the site-specific files for each version. It will then be necessary for users to specify explicitly the location of local site libraries ! (e.g., with LIBRARY_PATH).

!

The same value can be used for both --with-local-prefix and ! --prefix provided it is not /usr. This can be used ! to avoid the default search of /usr/local/include.

!

Do not specify /usr as the --with-local-prefix! ! The directory you use for --with-local-prefix must not contain any of the system’s standard header files. If it did contain them, certain programs would be miscompiled (including GNU Emacs, on certain targets), because this would override and nullify the header ! file corrections made by the fixincludes script.

Indications are that people who use this option use it based on mistaken ideas of what it is for. People use it as if it specified where to --- 411,451 ---- include directory. Another characteristic of system include directories is that pedantic warnings are turned off for headers in these directories.

!

Some autoconf macros add -I directory options to the compiler command line, to ensure that directories containing installed ! packages’ headers are searched. When directory is one of GCC’s system include directories, GCC will ignore the option so that system directories continue to be processed in the correct order. This may result in a search order different from what was specified but the directory will still be searched.

GCC automatically searches for ordinary libraries using ! GCC_EXEC_PREFIX. Thus, when the same installation prefix is used for both GCC and packages, GCC will automatically search for both headers and libraries. This provides a configuration that is easy to use. GCC behaves in a manner similar to that when it is ! installed as a system compiler in /usr.

Sites that need to install multiple versions of GCC may not want to use the above simple configuration. It is possible to use the ! --program-prefix, --program-suffix and ! --program-transform-name options to install multiple versions into a single directory, but it may be simpler to use different prefixes ! and the --with-local-prefix option to specify the location of the site-specific files for each version. It will then be necessary for users to specify explicitly the location of local site libraries ! (e.g., with LIBRARY_PATH).

!

The same value can be used for both --with-local-prefix and ! --prefix provided it is not /usr. This can be used ! to avoid the default search of /usr/local/include.

!

Do not specify /usr as the --with-local-prefix! ! The directory you use for --with-local-prefix must not contain any of the system’s standard header files. If it did contain them, certain programs would be miscompiled (including GNU Emacs, on certain targets), because this would override and nullify the header ! file corrections made by the fixincludes script.

Indications are that people who use this option use it based on mistaken ideas of what it is for. People use it as if it specified where to *************** install part of GCC. Perhaps they make *** 464,484 **** installing GCC creates the directory.

!
--with-gcc-major-version-only

Specifies that GCC should use only the major number rather than ! major.minor.patchlevel in filesystem paths.

!
--with-native-system-header-dir=dirname
!

Specifies that dirname is the directory that contains native system ! header files, rather than /usr/include. This option is most useful if you are creating a compiler that should be isolated from the system as much as possible. It is most commonly used with the ! --with-sysroot option and will cause GCC to search ! dirname inside the system root specified by that option.

!
--enable-shared[=package[,…]]

Build shared versions of libraries, if shared libraries are supported on the target platform. Unlike GCC 2.95.x and earlier, shared libraries are enabled by default on all platforms that support shared libraries. --- 453,473 ---- installing GCC creates the directory.

!
--with-gcc-major-version-only

Specifies that GCC should use only the major number rather than ! major.minor.patchlevel in filesystem paths.

!
--with-native-system-header-dir=dirname
!

Specifies that dirname is the directory that contains native system ! header files, rather than /usr/include. This option is most useful if you are creating a compiler that should be isolated from the system as much as possible. It is most commonly used with the ! --with-sysroot option and will cause GCC to search ! dirname inside the system root specified by that option.

!
--enable-shared[=package[,…]]

Build shared versions of libraries, if shared libraries are supported on the target platform. Unlike GCC 2.95.x and earlier, shared libraries are enabled by default on all platforms that support shared libraries. *************** are enabled by default on all platforms *** 486,608 ****

If a list of packages is given as an argument, build shared libraries only for the listed packages. For other packages, only static libraries will be built. Package names currently recognized in the GCC tree are ! ‘libgcc’ (also known as ‘gcc’), ‘libstdc++’ (not ! ‘libstdc++-v3’), ‘libffi’, ‘zlib’, ‘boehm-gc’, ! ‘ada’, ‘libada’, ‘libgo’, ‘libobjc’, and ‘libphobos’. ! Note ‘libiberty’ does not support shared libraries at all.

!

Use --disable-shared to build only static libraries. Note that ! --disable-shared does not accept a list of package names as ! argument, only --enable-shared does.

!

Contrast with --enable-host-shared, which affects host code.

!
--enable-host-shared
!

Specify that the host code should be built into position-independent machine code (with -fPIC), allowing it to be used within shared libraries, but yielding a slightly slower compiler.

This option is required when building the libgccjit.so library.

!

Contrast with --enable-shared, which affects target libraries.

!
--with-gnu-as

Specify that the compiler should assume that the assembler it finds is the GNU assembler. However, this does not modify the rules to find an assembler and will result in confusion if the assembler found is not actually the GNU assembler. (Confusion may also result if the compiler finds the GNU assembler but has not been ! configured with --with-gnu-as.) If you have more than one assembler installed on your system, you may want to use this option in ! connection with --with-as=pathname or ! --with-build-time-tools=pathname.

The following systems are the only ones where it makes a difference whether you use the GNU assembler. On any other system, ! --with-gnu-as has no effect.

!
    !
  • ‘hppa1.0-any-any’ !
  • ‘hppa1.1-any-any’ !
  • ‘*-*-solaris2.11’
!
--with-as=pathname

Specify that the compiler should use the assembler pointed to by ! pathname, rather than the one found by the standard rules to find an assembler, which are: !

    !
  • Unless GCC is being built with a cross compiler, check the ! libexec/gcc/target/version directory. ! libexec defaults to exec-prefix/libexec; ! exec-prefix defaults to prefix, which ! defaults to /usr/local unless overridden by the ! --prefix=pathname switch described above. target ! is the target system triple, such as ‘sparc-sun-solaris2.11’, and ! version denotes the GCC version, such as 3.0. !
  • If the target system is the same that you are building on, check operating system specific directories. !
  • Check in the PATH for a tool whose name is prefixed by the target system triple. !
  • Check in the PATH for a tool whose name is not prefixed by the target system triple, if the host and target system triple are the same (in other words, we use a host tool if it can be used for the target as well).
!

You may want to use --with-as if no assembler is installed in the directories listed above, or if you have multiple assemblers installed and want to choose one that is not found by the above rules.

!
--with-gnu-ld
!

Same as --with-gnu-as but for the linker.

!
--with-ld=pathname
!

Same as --with-as but for the linker.

!
--with-dsymutil=pathname
!

Same as --with-as but for the debug linker (only used on Darwin platforms so far).

!
--with-tls=dialect
!

Specify the default TLS dialect, for systems were there is a choice. ! For ARM targets, possible values for dialect are gnu or ! gnu2, which select between the original GNU dialect and the GNU TLS descriptor-based dialect.

!
--enable-multiarch

Specify whether to enable or disable multiarch support. The default is to check for glibc start files in a multiarch location, and enable it if the files are found. The auto detection is enabled for native builds, ! and for cross builds configured with --with-sysroot, and without ! --with-native-system-header-dir. More documentation about multiarch can be found at ! https://wiki.debian.org/Multiarch.

!
--enable-sjlj-exceptions
!

Force use of the setjmp/longjmp-based scheme for exceptions. ! ‘configure’ ordinarily picks the correct value based on the platform. Only use this option if you are sure you need a different setting.

!
--enable-vtable-verify

Specify whether to enable or disable the vtable verification feature. Enabling this feature causes libstdc++ to be built with its virtual calls in verifiable mode. This means that, when linked with libvtv, every --- 475,597 ----

If a list of packages is given as an argument, build shared libraries only for the listed packages. For other packages, only static libraries will be built. Package names currently recognized in the GCC tree are ! ‘libgcc’ (also known as ‘gcc’), ‘libstdc++’ (not ! ‘libstdc++-v3’), ‘libffi’, ‘zlib’, ‘boehm-gc’, ! ‘ada’, ‘libada’, ‘libgo’, ‘libobjc’, and ‘libphobos’. ! Note ‘libiberty’ does not support shared libraries at all.

!

Use --disable-shared to build only static libraries. Note that ! --disable-shared does not accept a list of package names as ! argument, only --enable-shared does.

!

Contrast with --enable-host-shared, which affects host code.

!
--enable-host-shared
!

Specify that the host code should be built into position-independent machine code (with -fPIC), allowing it to be used within shared libraries, but yielding a slightly slower compiler.

This option is required when building the libgccjit.so library.

!

Contrast with --enable-shared, which affects target libraries.

!
--with-gnu-as

Specify that the compiler should assume that the assembler it finds is the GNU assembler. However, this does not modify the rules to find an assembler and will result in confusion if the assembler found is not actually the GNU assembler. (Confusion may also result if the compiler finds the GNU assembler but has not been ! configured with --with-gnu-as.) If you have more than one assembler installed on your system, you may want to use this option in ! connection with --with-as=pathname or ! --with-build-time-tools=pathname.

The following systems are the only ones where it makes a difference whether you use the GNU assembler. On any other system, ! --with-gnu-as has no effect.

!
    !
  • ‘hppa1.0-any-any’ !
  • ‘hppa1.1-any-any’ !
  • ‘*-*-solaris2.11’
!
--with-as=pathname

Specify that the compiler should use the assembler pointed to by ! pathname, rather than the one found by the standard rules to find an assembler, which are: !

    !
  • Unless GCC is being built with a cross compiler, check the ! libexec/gcc/target/version directory. ! libexec defaults to exec-prefix/libexec; ! exec-prefix defaults to prefix, which ! defaults to /usr/local unless overridden by the ! --prefix=pathname switch described above. target ! is the target system triple, such as ‘sparc-sun-solaris2.11’, and ! version denotes the GCC version, such as 3.0. !
  • If the target system is the same that you are building on, check operating system specific directories. !
  • Check in the PATH for a tool whose name is prefixed by the target system triple. !
  • Check in the PATH for a tool whose name is not prefixed by the target system triple, if the host and target system triple are the same (in other words, we use a host tool if it can be used for the target as well).
!

You may want to use --with-as if no assembler is installed in the directories listed above, or if you have multiple assemblers installed and want to choose one that is not found by the above rules.

!
--with-gnu-ld
!

Same as --with-gnu-as but for the linker.

!
--with-ld=pathname
!

Same as --with-as but for the linker.

!
--with-dsymutil=pathname
!

Same as --with-as but for the debug linker (only used on Darwin platforms so far).

!
--with-tls=dialect
!

Specify the default TLS dialect, for systems where there is a choice. ! For ARM targets, possible values for dialect are gnu or ! gnu2, which select between the original GNU dialect and the GNU TLS descriptor-based dialect.

!
--enable-multiarch

Specify whether to enable or disable multiarch support. The default is to check for glibc start files in a multiarch location, and enable it if the files are found. The auto detection is enabled for native builds, ! and for cross builds configured with --with-sysroot, and without ! --with-native-system-header-dir. More documentation about multiarch can be found at ! https://wiki.debian.org/Multiarch.

!
--enable-sjlj-exceptions
!

Force use of the setjmp/longjmp-based scheme for exceptions. ! ‘configure’ ordinarily picks the correct value based on the platform. Only use this option if you are sure you need a different setting.

!
--enable-vtable-verify

Specify whether to enable or disable the vtable verification feature. Enabling this feature causes libstdc++ to be built with its virtual calls in verifiable mode. This means that, when linked with libvtv, every *************** call will be made before actually making *** 611,651 **** the verifier will call stub functions (in libstdc++ itself) and do nothing. If vtable verification is disabled, then libstdc++ is not built with its virtual calls in verifiable mode at all. However the libvtv library will ! still be built (see --disable-libvtv to turn off building libvtv). ! --disable-vtable-verify is the default.

!
--disable-gcov

Specify that the run-time library used for coverage analysis and associated host tools should not be built.

!
--disable-multilib

Specify that multiple target libraries to support different target variants, calling conventions, etc. should not be built. The default is to build a predefined set of them.

Some targets provide finer-grained control over which multilibs are built ! (e.g., --disable-softfloat): !

!
arm-*-*

fpu, 26bit, underscore, interwork, biendian, nofmult.

!
m68*-*-*

softfloat, m68881, m68000, m68020.

!
mips*-*-*

single-float, biendian, softfloat.

!
msp430-*-*

no-exceptions

!
powerpc*-*-*, rs6000*-*-*

aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian, sysv, aix.

--- 600,640 ---- the verifier will call stub functions (in libstdc++ itself) and do nothing. If vtable verification is disabled, then libstdc++ is not built with its virtual calls in verifiable mode at all. However the libvtv library will ! still be built (see --disable-libvtv to turn off building libvtv). ! --disable-vtable-verify is the default.

!
--disable-gcov

Specify that the run-time library used for coverage analysis and associated host tools should not be built.

!
--disable-multilib

Specify that multiple target libraries to support different target variants, calling conventions, etc. should not be built. The default is to build a predefined set of them.

Some targets provide finer-grained control over which multilibs are built ! (e.g., --disable-softfloat): !

!
arm-*-*

fpu, 26bit, underscore, interwork, biendian, nofmult.

!
m68*-*-*

softfloat, m68881, m68000, m68020.

!
mips*-*-*

single-float, biendian, softfloat.

!
msp430-*-*

no-exceptions

!
powerpc*-*-*, rs6000*-*-*

aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos, biendian, sysv, aix.

*************** sysv, aix. *** 653,803 ****
!
--with-multilib-list=list
!
--without-multilib-list
!

Specify what multilibs to build. list is a comma separated list of values, possibly consisting of a single value. Currently only implemented for aarch64*-*-*, arm*-*-*, loongarch64-*-*, riscv*-*-*, sh*-*-* and x86-64-*-linux*. The accepted values and meaning for each target is given below.

!
!
aarch64*-*-*
!

list is a comma separated list of ilp32, and lp64 to enable ILP32 and LP64 run-time libraries, respectively. If ! list is empty, then there will be no multilibs and only the ! default run-time library will be built. If list is ! default or –with-multilib-list= is not specified, then the default set of libraries is selected based on the value of ! --target.

!
arm*-*-*
!

list is a comma separated list of aprofile and ! rmprofile to build multilibs for A or R and M architecture profiles respectively. Note that, due to some limitation of the current ! multilib framework, using the combined aprofile,rmprofile multilibs selects in some cases a less optimal multilib than when using the multilib profile for the architecture targetted. The special value ! default is also accepted and is equivalent to omitting the option, i.e., only the default run-time library will be enabled.

!

list may instead contain @name, to use the multilib ! configuration Makefile fragment name in gcc/config/arm in the source tree (it is part of the corresponding sources, after all). It is recommended, but not required, that files used for this purpose to ! be named starting with t-ml-, to make their intended purpose self-evident, in line with GCC conventions. Such files enable custom, user-chosen multilib lists to be configured. Whether multiple such files can be used together depends on the contents of the supplied ! files. See gcc/config/arm/t-multilib and its supplementary ! gcc/config/arm/t-*profile files for an example of what such Makefile fragments might look like for this version of GCC. The macros expected to be defined in these fragments are not stable across GCC ! releases, so make sure they define the MULTILIB-related macros expected by the version of GCC you are building. See “Target Makefile Fragments” in the internals manual.

The table below gives the combination of ISAs, architectures, FPUs and floating-point ABIs for which multilibs are built for each predefined profile. The union of these options is considered when specifying both ! aprofile and rmprofile.

! ! ! !
Optionaprofilermprofile
ISAs-marm and -mthumb-mthumb
Architectures





default architecture
! -march=armv7-a
! -march=armv7ve
! -march=armv8-a


default architecture
! -march=armv6s-m
! -march=armv7-m
! -march=armv7e-m
! -march=armv8-m.base
! -march=armv8-m.main
! -march=armv7
FPUs




none
! -mfpu=vfpv3-d16
! -mfpu=neon
! -mfpu=vfpv4-d16
! -mfpu=neon-vfpv4
! -mfpu=neon-fp-armv8		none
! -mfpu=vfpv3-d16
! -mfpu=fpv4-sp-d16
! -mfpu=fpv5-sp-d16
! -mfpu=fpv5-d16
floating-point ABIs

-mfloat-abi=soft
! -mfloat-abi=softfp
! -mfloat-abi=hard		-mfloat-abi=soft
! -mfloat-abi=softfp
! -mfloat-abi=hard
!
loongarch*-*-*
!

list is a comma-separated list of the following ABI identifiers: ! lp64d[/base] lp64f[/base] lp64d[/base], where the ! /base suffix may be omitted, to enable their respective run-time ! libraries. If list is empty or default, ! or if --with-multilib-list is not specified, then the default ABI ! as specified by --with-abi or implied by --target is selected.

!
riscv*-*-*
!

list is a single ABI name. The target architecture must be either ! rv32gc or rv64gc. This will build a single multilib for the ! specified architecture and ABI pair. If --with-multilib-list is not given, then a default set of multilibs is selected based on the value of ! --target. This is usually a large set of multilibs.

!
sh*-*-*
!

list is a comma separated list of CPU names. These must be of the ! form sh* or m* (in which case they match the compiler option for that processor). The list should not contain any endian options - ! these are handled by --with-endian.

!

If list is empty, then there will be no multilibs for extra processors. The multilib for the secondary endian remains enabled.

!

As a special case, if an entry in the list starts with a ! (exclamation point), then it is added to the list of excluded multilibs. ! Entries of this sort should be compatible with ‘MULTILIB_EXCLUDES’ ! (once the leading ! has been stripped).

!

If --with-multilib-list is not given, then a default set of ! multilibs is selected based on the value of --target. This is usually the complete set of libraries, but some targets imply a more specialized subset.

Example 1: to configure a compiler for SH4A only, but supporting both endians, with little endian being the default: !

! 
--with-cpu=sh4a --with-endian=little,big --with-multilib-list=

Example 2: to configure a compiler for both SH4A and SH4AL-DSP, but with only little endian SH4AL: !

! 
--with-cpu=sh4a --with-endian=little,big \
  --with-multilib-list=sh4al,!mb/m4al
!
x86-64-*-linux*
!

list is a comma separated list of m32, m64 and ! mx32 to enable 32-bit, 64-bit and x32 run-time libraries, ! respectively. If list is empty, then there will be no multilibs and only the default run-time library will be enabled.

!

If --with-multilib-list is not given, then only 32-bit and 64-bit run-time libraries will be enabled.

!
--with-multilib-generator=config
!

Specify what multilibs to build. config is a semicolon separated list of values, possibly consisting of a single value. Currently only implemented for riscv*-*-elf*. The accepted values and meanings are given below.

--- 642,793 ----
!
--with-multilib-list=list
!
--without-multilib-list
!

Specify what multilibs to build. list is a comma separated list of values, possibly consisting of a single value. Currently only implemented for aarch64*-*-*, arm*-*-*, loongarch64-*-*, riscv*-*-*, sh*-*-* and x86-64-*-linux*. The accepted values and meaning for each target is given below.

!
!
aarch64*-*-*
!

list is a comma separated list of ilp32, and lp64 to enable ILP32 and LP64 run-time libraries, respectively. If ! list is empty, then there will be no multilibs and only the ! default run-time library will be built. If list is ! default or –with-multilib-list= is not specified, then the default set of libraries is selected based on the value of ! --target.

!
arm*-*-*
!

list is a comma separated list of aprofile and ! rmprofile to build multilibs for A or R and M architecture profiles respectively. Note that, due to some limitation of the current ! multilib framework, using the combined aprofile,rmprofile multilibs selects in some cases a less optimal multilib than when using the multilib profile for the architecture targetted. The special value ! default is also accepted and is equivalent to omitting the option, i.e., only the default run-time library will be enabled.

!

list may instead contain @name, to use the multilib ! configuration Makefile fragment name in gcc/config/arm in the source tree (it is part of the corresponding sources, after all). It is recommended, but not required, that files used for this purpose to ! be named starting with t-ml-, to make their intended purpose self-evident, in line with GCC conventions. Such files enable custom, user-chosen multilib lists to be configured. Whether multiple such files can be used together depends on the contents of the supplied ! files. See gcc/config/arm/t-multilib and its supplementary ! gcc/config/arm/t-*profile files for an example of what such Makefile fragments might look like for this version of GCC. The macros expected to be defined in these fragments are not stable across GCC ! releases, so make sure they define the MULTILIB-related macros expected by the version of GCC you are building. See “Target Makefile Fragments” in the internals manual.

The table below gives the combination of ISAs, architectures, FPUs and floating-point ABIs for which multilibs are built for each predefined profile. The union of these options is considered when specifying both ! aprofile and rmprofile.

! ! ! ! !
Optionaprofilermprofile
ISAs-marm and -mthumb-mthumb
Architectures





default architecture
! -march=armv7-a
! -march=armv7ve
! -march=armv8-a


default architecture
! -march=armv6s-m
! -march=armv7-m
! -march=armv7e-m
! -march=armv8-m.base
! -march=armv8-m.main
! -march=armv7
FPUs




none
! -mfpu=vfpv3-d16
! -mfpu=neon
! -mfpu=vfpv4-d16
! -mfpu=neon-vfpv4
! -mfpu=neon-fp-armv8		none
! -mfpu=vfpv3-d16
! -mfpu=fpv4-sp-d16
! -mfpu=fpv5-sp-d16
! -mfpu=fpv5-d16
floating-point ABIs

-mfloat-abi=soft
! -mfloat-abi=softfp
! -mfloat-abi=hard		-mfloat-abi=soft
! -mfloat-abi=softfp
! -mfloat-abi=hard
!
loongarch*-*-*
!

list is a comma-separated list of the following ABI identifiers: ! lp64d[/base] lp64f[/base] lp64d[/base], where the ! /base suffix may be omitted, to enable their respective run-time ! libraries. If list is empty or default, ! or if --with-multilib-list is not specified, then the default ABI ! as specified by --with-abi or implied by --target is selected.

!
riscv*-*-*
!

list is a single ABI name. The target architecture must be either ! rv32gc or rv64gc. This will build a single multilib for the ! specified architecture and ABI pair. If --with-multilib-list is not given, then a default set of multilibs is selected based on the value of ! --target. This is usually a large set of multilibs.

!
sh*-*-*
!

list is a comma separated list of CPU names. These must be of the ! form sh* or m* (in which case they match the compiler option for that processor). The list should not contain any endian options - ! these are handled by --with-endian.

!

If list is empty, then there will be no multilibs for extra processors. The multilib for the secondary endian remains enabled.

!

As a special case, if an entry in the list starts with a ! (exclamation point), then it is added to the list of excluded multilibs. ! Entries of this sort should be compatible with ‘MULTILIB_EXCLUDES’ ! (once the leading ! has been stripped).

!

If --with-multilib-list is not given, then a default set of ! multilibs is selected based on the value of --target. This is usually the complete set of libraries, but some targets imply a more specialized subset.

Example 1: to configure a compiler for SH4A only, but supporting both endians, with little endian being the default: !

! 
--with-cpu=sh4a --with-endian=little,big --with-multilib-list=

Example 2: to configure a compiler for both SH4A and SH4AL-DSP, but with only little endian SH4AL: !

! 
--with-cpu=sh4a --with-endian=little,big \
  --with-multilib-list=sh4al,!mb/m4al
!
x86-64-*-linux*
!

list is a comma separated list of m32, m64 and ! mx32 to enable 32-bit, 64-bit and x32 run-time libraries, ! respectively. If list is empty, then there will be no multilibs and only the default run-time library will be enabled.

!

If --with-multilib-list is not given, then only 32-bit and 64-bit run-time libraries will be enabled.

!
--with-multilib-generator=config
!

Specify what multilibs to build. config is a semicolon separated list of values, possibly consisting of a single value. Currently only implemented for riscv*-*-elf*. The accepted values and meanings are given below.

*************** for riscv*-*-elf*. The accepted values *** 806,872 **** reuse rule with architecture string and reuse rule with sub-extension.

Example 1: Add multi-lib suppport for rv32i with ilp32. !

! 
rv32i-ilp32--

Example 2: Add multi-lib suppport for rv32i with ilp32 and rv32imafd with ilp32. !

! 
rv32i-ilp32--;rv32imafd-ilp32--

Example 3: Add multi-lib suppport for rv32i with ilp32; rv32im with ilp32 and rv32ic with ilp32 will reuse this multi-lib set. !

! 
rv32i-ilp32-rv32im-c

Example 4: Add multi-lib suppport for rv64ima with lp64; rv64imaf with lp64, rv64imac with lp64 and rv64imafc with lp64 will reuse this multi-lib set. !

! 
rv64ima-lp64--f,c,fc
!

--with-multilib-generator have an optional configuration argument ! --cmodel=val for code model, this option will expand with other ! config options, val is a comma separated list of possible code model, currently we support medlow and medany.

Example 5: Add multi-lib suppport for rv64ima with lp64; rv64ima with lp64 and medlow code model !

! 
rv64ima-lp64--;--cmodel=medlow

Example 6: Add multi-lib suppport for rv64ima with lp64; rv64ima with lp64 and medlow code model; rv64ima with lp64 and medany code model !

! 
rv64ima-lp64--;--cmodel=medlow,medany
!
--with-endian=endians

Specify what endians to use. Currently only implemented for sh*-*-*.

!

endians may be one of the following: !

!
big

Use big endian exclusively.

!
little

Use little endian exclusively.

!
big,little

Use big endian by default. Provide a multilib for little endian.

!
little,big

Use little endian by default. Provide a multilib for big endian.

!
--enable-threads

Specify that the target supports threads. This affects the Objective-C compiler and runtime library, and exception handling for other languages like C++. --- 796,862 ---- reuse rule with architecture string and reuse rule with sub-extension.

Example 1: Add multi-lib suppport for rv32i with ilp32. !

! 
rv32i-ilp32--

Example 2: Add multi-lib suppport for rv32i with ilp32 and rv32imafd with ilp32. !

! 
rv32i-ilp32--;rv32imafd-ilp32--

Example 3: Add multi-lib suppport for rv32i with ilp32; rv32im with ilp32 and rv32ic with ilp32 will reuse this multi-lib set. !

! 
rv32i-ilp32-rv32im-c

Example 4: Add multi-lib suppport for rv64ima with lp64; rv64imaf with lp64, rv64imac with lp64 and rv64imafc with lp64 will reuse this multi-lib set. !

! 
rv64ima-lp64--f,c,fc
!

--with-multilib-generator have an optional configuration argument ! --cmodel=val for code model, this option will expand with other ! config options, val is a comma separated list of possible code model, currently we support medlow and medany.

Example 5: Add multi-lib suppport for rv64ima with lp64; rv64ima with lp64 and medlow code model !

! 
rv64ima-lp64--;--cmodel=medlow

Example 6: Add multi-lib suppport for rv64ima with lp64; rv64ima with lp64 and medlow code model; rv64ima with lp64 and medany code model !

! 
rv64ima-lp64--;--cmodel=medlow,medany
!
--with-endian=endians

Specify what endians to use. Currently only implemented for sh*-*-*.

!

endians may be one of the following: !

!
big

Use big endian exclusively.

!
little

Use little endian exclusively.

!
big,little

Use big endian by default. Provide a multilib for little endian.

!
little,big

Use little endian by default. Provide a multilib for big endian.

!
--enable-threads

Specify that the target supports threads. This affects the Objective-C compiler and runtime library, and exception handling for other languages like C++. *************** On some systems, this is the default. *** 875,1013 ****

In general, the best (and, in many cases, the only known) threading model available will be configured for use. Beware that on some systems, GCC has not been taught what threading models are generally ! available for the system. In this case, --enable-threads is an ! alias for --enable-threads=single.

!
--disable-threads

Specify that threading support should be disabled for the system. ! This is an alias for --enable-threads=single.

!
--enable-threads=lib

Specify that ! lib is the thread support library. This affects the Objective-C compiler and runtime library, and exception handling for other languages ! like C++. The possibilities for lib are:

!
!
aix

AIX thread support.

!
dce

DCE thread support.

!
lynx

LynxOS thread support.

!
mipssde

MIPS SDE thread support.

!
no
!

This is an alias for ‘single’.

!
posix

Generic POSIX/Unix98 thread support.

!
rtems

RTEMS thread support.

!
single

Disable thread support, should work for all platforms.

!
tpf

TPF thread support.

!
vxworks

VxWorks thread support.

!
win32

Microsoft Win32 API thread support.

!
--enable-tls

Specify that the target supports TLS (Thread Local Storage). Usually configure can correctly determine if TLS is supported. In cases where it guesses incorrectly, TLS can be explicitly enabled or disabled with ! --enable-tls or --disable-tls. This can happen if the assembler supports TLS but the C library does not, or if the assumptions made by the configure test are incorrect.

!
--disable-tls

Specify that the target does not support TLS. ! This is an alias for --enable-tls=no.

!
--disable-tm-clone-registry

Disable TM clone registry in libgcc. It is enabled in libgcc by default. This option helps to reduce code size for embedded targets which do not use transactional memory.

!
--with-cpu=cpu
!
--with-cpu-32=cpu
!
--with-cpu-64=cpu

Specify which cpu variant the compiler should generate code for by default. ! cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARC, ARM, i386, M68k, ! PowerPC, and SPARC. It is mandatory for ARC. The --with-cpu-32 and ! --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for aarch64, i386, x86-64, PowerPC, and SPARC.

!
--with-schedule=cpu
!
--with-arch=cpu
!
--with-arch-32=cpu
!
--with-arch-64=cpu
!
--with-tune=cpu
!
--with-tune-32=cpu
!
--with-tune-64=cpu
!
--with-abi=abi
!
--with-fpu=type
!
--with-float=type
!

These configure options provide default values for the -mschedule=, ! -march=, -mtune=, -mabi=, and -mfpu= ! options and for -mhard-float or -msoft-float. As with ! --with-cpu, which switches will be accepted and acceptable values of the arguments depend on the target.

!
--with-mode=mode
!

Specify if the compiler should default to -marm or -mthumb. This option is only supported on ARM targets.

!
--with-stack-offset=num
!

This option sets the default for the -mstack-offset=num option, and will thus generally also control the setting of this option for libraries. This option is only supported on Epiphany targets.

!
--with-fpmath=isa
!

This options sets -mfpmath=sse by default and specifies the default ! ISA for floating-point arithmetics. You can select either ‘sse’ which ! enables -msse2 or ‘avx’ which enables -mavx by default. This option is only supported on i386 and x86-64 targets.

!
--with-fp-32=mode
!

On MIPS targets, set the default value for the -mfp option when using ! the o32 ABI. The possibilities for mode are: !

!
32
!

Use the o32 FP32 ABI extension, as with the -mfp32 command-line option.

!
xx
!

Use the o32 FPXX ABI extension, as with the -mfpxx command-line option.

!
64
!

Use the o32 FP64 ABI extension, as with the -mfp64 command-line option.

--- 865,1003 ----

In general, the best (and, in many cases, the only known) threading model available will be configured for use. Beware that on some systems, GCC has not been taught what threading models are generally ! available for the system. In this case, --enable-threads is an ! alias for --enable-threads=single.

!
--disable-threads

Specify that threading support should be disabled for the system. ! This is an alias for --enable-threads=single.

!
--enable-threads=lib

Specify that ! lib is the thread support library. This affects the Objective-C compiler and runtime library, and exception handling for other languages ! like C++. The possibilities for lib are:

!
!
aix

AIX thread support.

!
dce

DCE thread support.

!
lynx

LynxOS thread support.

!
mipssde

MIPS SDE thread support.

!
no
!

This is an alias for ‘single’.

!
posix

Generic POSIX/Unix98 thread support.

!
rtems

RTEMS thread support.

!
single

Disable thread support, should work for all platforms.

!
tpf

TPF thread support.

!
vxworks

VxWorks thread support.

!
win32

Microsoft Win32 API thread support.

!
--enable-tls

Specify that the target supports TLS (Thread Local Storage). Usually configure can correctly determine if TLS is supported. In cases where it guesses incorrectly, TLS can be explicitly enabled or disabled with ! --enable-tls or --disable-tls. This can happen if the assembler supports TLS but the C library does not, or if the assumptions made by the configure test are incorrect.

!
--disable-tls

Specify that the target does not support TLS. ! This is an alias for --enable-tls=no.

!
--disable-tm-clone-registry

Disable TM clone registry in libgcc. It is enabled in libgcc by default. This option helps to reduce code size for embedded targets which do not use transactional memory.

!
--with-cpu=cpu
!
--with-cpu-32=cpu
!
--with-cpu-64=cpu

Specify which cpu variant the compiler should generate code for by default. ! cpu will be used as the default value of the -mcpu= switch. This option is only supported on some targets, including ARC, ARM, i386, M68k, ! PowerPC, and SPARC. It is mandatory for ARC. The --with-cpu-32 and ! --with-cpu-64 options specify separate default CPUs for 32-bit and 64-bit modes; these options are only supported for aarch64, i386, x86-64, PowerPC, and SPARC.

!
--with-schedule=cpu
!
--with-arch=cpu
!
--with-arch-32=cpu
!
--with-arch-64=cpu
!
--with-tune=cpu
!
--with-tune-32=cpu
!
--with-tune-64=cpu
!
--with-abi=abi
!
--with-fpu=type
!
--with-float=type
!

These configure options provide default values for the -mschedule=, ! -march=, -mtune=, -mabi=, and -mfpu= ! options and for -mhard-float or -msoft-float. As with ! --with-cpu, which switches will be accepted and acceptable values of the arguments depend on the target.

!
--with-mode=mode
!

Specify if the compiler should default to -marm or -mthumb. This option is only supported on ARM targets.

!
--with-stack-offset=num
!

This option sets the default for the -mstack-offset=num option, and will thus generally also control the setting of this option for libraries. This option is only supported on Epiphany targets.

!
--with-fpmath=isa
!

This options sets -mfpmath=sse by default and specifies the default ! ISA for floating-point arithmetics. You can select either ‘sse’ which ! enables -msse2 or ‘avx’ which enables -mavx by default. This option is only supported on i386 and x86-64 targets.

!
--with-fp-32=mode
!

On MIPS targets, set the default value for the -mfp option when using ! the o32 ABI. The possibilities for mode are: !

!
32
!

Use the o32 FP32 ABI extension, as with the -mfp32 command-line option.

!
xx
!

Use the o32 FPXX ABI extension, as with the -mfpxx command-line option.

!
64
!

Use the o32 FP64 ABI extension, as with the -mfp64 command-line option.

*************** option. *** 1015,1081 **** FP32 ABI extension.

!
--with-odd-spreg-32
!

On MIPS targets, set the -modd-spreg option by default when using the o32 ABI.

!
--without-odd-spreg-32
!

On MIPS targets, set the -mno-odd-spreg option by default when using the o32 ABI. This is normally used in conjunction with ! --with-fp-32=64 in order to target the o32 FP64A ABI extension.

!
--with-nan=encoding

On MIPS targets, set the default encoding convention to use for the special not-a-number (NaN) IEEE 754 floating-point data. The ! possibilities for encoding are: !

!
legacy
!

Use the legacy encoding, as with the -mnan=legacy command-line option.

!
2008
!

Use the 754-2008 encoding, as with the -mnan=2008 command-line option.

To use this configuration option you must have an assembler version ! installed that supports the -mnan= command-line option too. In the absence of this configuration option the default convention is ! the legacy encoding, as when neither of the -mnan=2008 and ! -mnan=legacy command-line options has been used.

!
--with-divide=type

Specify how the compiler should generate code for checking for division by zero. This option is only supported on the MIPS target. ! The possibilities for type are: !

!
traps

Division by zero checks use conditional traps (this is the default on systems that support conditional traps).

!
breaks

Division by zero checks use the break instruction.

!
--with-compact-branches=policy

Specify how the compiler should generate branch instructions. This option is only supported on the MIPS target. ! The possibilities for type are: !

!
optimal

Cause a delay slot branch to be used if one is available in the current ISA and the delay slot is successfully filled. If the delay slot is not filled, a compact branch will be chosen if one is available.

!
never

Ensures that compact branch instructions will never be generated.

!
always

Ensures that a compact branch instruction will be generated if available. If a compact branch instruction is not available, a delay slot form of the branch will be used instead. --- 1005,1071 ---- FP32 ABI extension.

!
--with-odd-spreg-32
!

On MIPS targets, set the -modd-spreg option by default when using the o32 ABI.

!
--without-odd-spreg-32
!

On MIPS targets, set the -mno-odd-spreg option by default when using the o32 ABI. This is normally used in conjunction with ! --with-fp-32=64 in order to target the o32 FP64A ABI extension.

!
--with-nan=encoding

On MIPS targets, set the default encoding convention to use for the special not-a-number (NaN) IEEE 754 floating-point data. The ! possibilities for encoding are: !

!
legacy
!

Use the legacy encoding, as with the -mnan=legacy command-line option.

!
2008
!

Use the 754-2008 encoding, as with the -mnan=2008 command-line option.

To use this configuration option you must have an assembler version ! installed that supports the -mnan= command-line option too. In the absence of this configuration option the default convention is ! the legacy encoding, as when neither of the -mnan=2008 and ! -mnan=legacy command-line options has been used.

!
--with-divide=type

Specify how the compiler should generate code for checking for division by zero. This option is only supported on the MIPS target. ! The possibilities for type are: !

!
traps

Division by zero checks use conditional traps (this is the default on systems that support conditional traps).

!
breaks

Division by zero checks use the break instruction.

!
--with-compact-branches=policy

Specify how the compiler should generate branch instructions. This option is only supported on the MIPS target. ! The possibilities for type are: !

!
optimal

Cause a delay slot branch to be used if one is available in the current ISA and the delay slot is successfully filled. If the delay slot is not filled, a compact branch will be chosen if one is available.

!
never

Ensures that compact branch instructions will never be generated.

!
always

Ensures that a compact branch instruction will be generated if available. If a compact branch instruction is not available, a delay slot form of the branch will be used instead. *************** For pre-R6/microMIPS/MIPS16, this option *** 1086,1121 ****

!
--with-llsc
!

On MIPS targets, make -mllsc the default when no ! -mno-llsc option is passed. This is the default for Linux-based targets, as the kernel will emulate them if the ISA does not provide them.

!
--without-llsc
!

On MIPS targets, make -mno-llsc the default when no ! -mllsc option is passed.

!
--with-synci
!

On MIPS targets, make -msynci the default when no ! -mno-synci option is passed.

!
--without-synci
!

On MIPS targets, make -mno-synci the default when no ! -msynci option is passed. This is the default.

!
--with-lxc1-sxc1
!

On MIPS targets, make -mlxc1-sxc1 the default when no ! -mno-lxc1-sxc1 option is passed. This is the default.

!
--without-lxc1-sxc1
!

On MIPS targets, make -mno-lxc1-sxc1 the default when no ! -mlxc1-sxc1 option is passed. The indexed load/store instructions are not directly a problem but can lead to unexpected behaviour when deployed in an application intended for a 32-bit address space but run on a 64-bit processor. The issue is seen because all --- 1076,1111 ----

!
--with-llsc
!

On MIPS targets, make -mllsc the default when no ! -mno-llsc option is passed. This is the default for Linux-based targets, as the kernel will emulate them if the ISA does not provide them.

!
--without-llsc
!

On MIPS targets, make -mno-llsc the default when no ! -mllsc option is passed.

!
--with-synci
!

On MIPS targets, make -msynci the default when no ! -mno-synci option is passed.

!
--without-synci
!

On MIPS targets, make -mno-synci the default when no ! -msynci option is passed. This is the default.

!
--with-lxc1-sxc1
!

On MIPS targets, make -mlxc1-sxc1 the default when no ! -mno-lxc1-sxc1 option is passed. This is the default.

!
--without-lxc1-sxc1
!

On MIPS targets, make -mno-lxc1-sxc1 the default when no ! -mlxc1-sxc1 option is passed. The indexed load/store instructions are not directly a problem but can lead to unexpected behaviour when deployed in an application intended for a 32-bit address space but run on a 64-bit processor. The issue is seen because all *************** known MIPS 64-bit Linux kernels execute *** 1123,1142 **** with 64-bit addressing enabled which affects the overflow behaviour of the indexed addressing mode. GCC will assume that ordinary 32-bit arithmetic overflow behaviour is the same whether performed ! as an addu instruction or as part of the address calculation ! in lwxc1 type instructions. This assumption holds true in a pure 32-bit environment and can hold true in a 64-bit environment if the address space is accurately set to be 32-bit for o32 and n32.

!
--with-madd4
!

On MIPS targets, make -mmadd4 the default when no ! -mno-madd4 option is passed. This is the default.

!
--without-madd4
!

On MIPS targets, make -mno-madd4 the default when no ! -mmadd4 option is passed. The madd4 instruction family can be problematic when targeting a combination of cores that implement these instructions differently. There are two known cores that implement these as fused operations instead of unfused (where --- 1113,1132 ---- with 64-bit addressing enabled which affects the overflow behaviour of the indexed addressing mode. GCC will assume that ordinary 32-bit arithmetic overflow behaviour is the same whether performed ! as an addu instruction or as part of the address calculation ! in lwxc1 type instructions. This assumption holds true in a pure 32-bit environment and can hold true in a 64-bit environment if the address space is accurately set to be 32-bit for o32 and n32.

!
--with-madd4
!

On MIPS targets, make -mmadd4 the default when no ! -mno-madd4 option is passed. This is the default.

!
--without-madd4
!

On MIPS targets, make -mno-madd4 the default when no ! -mmadd4 option is passed. The madd4 instruction family can be problematic when targeting a combination of cores that implement these instructions differently. There are two known cores that implement these as fused operations instead of unfused (where *************** only way to ensure compatible code is ge *** 1145,1237 **** a performance penalty.

!
--with-msa
!

On MIPS targets, make -mmsa the default when no ! -mno-msa option is passed.

!
--without-msa
!

On MIPS targets, make -mno-msa the default when no ! -mmsa option is passed. This is the default.

!
--with-mips-plt

On MIPS targets, make use of copy relocations and PLTs. These features are extensions to the traditional SVR4-based MIPS ABIs and require support from GNU binutils and the runtime C library.

!
--with-stack-clash-protection-guard-size=size

On certain targets this option sets the default stack clash protection guard ! size as a power of two in bytes. On AArch64 size is required to be either 12 (4KB) or 16 (64KB).

!
--with-isa-spec=ISA-spec-string

On RISC-V targets specify the default version of the RISC-V Unprivileged (formerly User-Level) ISA specification to produce code conforming to. ! The possibilities for ISA-spec-string are: !

!
2.2

Produce code conforming to version 2.2.

!
20190608

Produce code conforming to version 20190608.

!
20191213

Produce code conforming to version 20191213.

In the absence of this configuration option the default version is 20191213.

!
--enable-__cxa_atexit

Define if you want to use __cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects. This is essential for fully standards-compliant handling of destructors, but requires __cxa_atexit in libc. This option is currently only available on systems with GNU libc. When enabled, this will cause ! -fuse-cxa-atexit to be passed by default.

!
--enable-gnu-indirect-function
!

Define if you want to enable the ifunc attribute. This option is currently only available on systems with GNU libc on certain targets.

!
--enable-target-optspace

Specify that target libraries should be optimized for code space instead of code speed. This is the default for the m32r platform.

!
--with-cpp-install-dir=dirname
!

Specify that the user visible cpp program should be installed ! in prefix/dirname/cpp, in addition to bindir.

!
--enable-comdat

Enable COMDAT group support. This is primarily used to override the automatically detected value.

!
--enable-initfini-array
!

Force the use of sections .init_array and .fini_array ! (instead of .init and .fini) for constructors and ! destructors. Option --disable-initfini-array has the opposite effect. If neither option is specified, the configure script ! will try to guess whether the .init_array and ! .fini_array sections are supported and, if they are, use them.

!
--enable-link-mutex

When building GCC, use a mutex to avoid linking the compilers for multiple languages at the same time, to avoid thrashing on build systems with limited free memory. The default is not to use such a mutex.

!
--enable-link-serialization

When building GCC, use make dependencies to serialize linking the compilers for multiple languages, to avoid thrashing on build systems with limited free memory. The default is not to add such --- 1135,1227 ---- a performance penalty.

!
--with-msa
!

On MIPS targets, make -mmsa the default when no ! -mno-msa option is passed.

!
--without-msa
!

On MIPS targets, make -mno-msa the default when no ! -mmsa option is passed. This is the default.

!
--with-mips-plt

On MIPS targets, make use of copy relocations and PLTs. These features are extensions to the traditional SVR4-based MIPS ABIs and require support from GNU binutils and the runtime C library.

!
--with-stack-clash-protection-guard-size=size

On certain targets this option sets the default stack clash protection guard ! size as a power of two in bytes. On AArch64 size is required to be either 12 (4KB) or 16 (64KB).

!
--with-isa-spec=ISA-spec-string

On RISC-V targets specify the default version of the RISC-V Unprivileged (formerly User-Level) ISA specification to produce code conforming to. ! The possibilities for ISA-spec-string are: !

!
2.2

Produce code conforming to version 2.2.

!
20190608

Produce code conforming to version 20190608.

!
20191213

Produce code conforming to version 20191213.

In the absence of this configuration option the default version is 20191213.

!
--enable-__cxa_atexit

Define if you want to use __cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects. This is essential for fully standards-compliant handling of destructors, but requires __cxa_atexit in libc. This option is currently only available on systems with GNU libc. When enabled, this will cause ! -fuse-cxa-atexit to be passed by default.

!
--enable-gnu-indirect-function
!

Define if you want to enable the ifunc attribute. This option is currently only available on systems with GNU libc on certain targets.

!
--enable-target-optspace

Specify that target libraries should be optimized for code space instead of code speed. This is the default for the m32r platform.

!
--with-cpp-install-dir=dirname
!

Specify that the user visible cpp program should be installed ! in prefix/dirname/cpp, in addition to bindir.

!
--enable-comdat

Enable COMDAT group support. This is primarily used to override the automatically detected value.

!
--enable-initfini-array
!

Force the use of sections .init_array and .fini_array ! (instead of .init and .fini) for constructors and ! destructors. Option --disable-initfini-array has the opposite effect. If neither option is specified, the configure script ! will try to guess whether the .init_array and ! .fini_array sections are supported and, if they are, use them.

!
--enable-link-mutex

When building GCC, use a mutex to avoid linking the compilers for multiple languages at the same time, to avoid thrashing on build systems with limited free memory. The default is not to use such a mutex.

!
--enable-link-serialization

When building GCC, use make dependencies to serialize linking the compilers for multiple languages, to avoid thrashing on build systems with limited free memory. The default is not to add such *************** compilers concurrently. If the argument *** 1240,1272 **** that number of concurrent link processes for the large binaries.

!
--enable-maintainer-mode

The build rules that regenerate the Autoconf and Automake output files as ! well as the GCC master message catalog gcc.pot are normally disabled. This is because it can only be rebuilt if the complete source tree is present. If you have changed the sources and want to rebuild the ! catalog, configuring with --enable-maintainer-mode will enable ! this. Note that you need a recent version of the gettext tools to do so.

!
--disable-bootstrap

For a native build, the default configuration is to perform ! a 3-stage bootstrap of the compiler when ‘make’ is invoked, testing that GCC can compile itself correctly. If you want to disable ! this process, you can configure with --disable-bootstrap.

!
--enable-bootstrap

In special cases, you may want to perform a 3-stage build even if the target and host triplets are different. This is possible when the host can run code compiled for the target (e.g. host is i686-linux, target is i486-linux). Starting from GCC 4.2, to do this you have to configure explicitly ! with --enable-bootstrap.

!
--enable-generated-files-in-srcdir

Neither the .c and .h files that are generated from Bison and flex nor the info manuals and man pages that are built from the .texi files are present in the repository development tree. When building GCC from that development tree, --- 1230,1262 ---- that number of concurrent link processes for the large binaries.

!
--enable-maintainer-mode

The build rules that regenerate the Autoconf and Automake output files as ! well as the GCC master message catalog gcc.pot are normally disabled. This is because it can only be rebuilt if the complete source tree is present. If you have changed the sources and want to rebuild the ! catalog, configuring with --enable-maintainer-mode will enable ! this. Note that you need a recent version of the gettext tools to do so.

!
--disable-bootstrap

For a native build, the default configuration is to perform ! a 3-stage bootstrap of the compiler when ‘make’ is invoked, testing that GCC can compile itself correctly. If you want to disable ! this process, you can configure with --disable-bootstrap.

!
--enable-bootstrap

In special cases, you may want to perform a 3-stage build even if the target and host triplets are different. This is possible when the host can run code compiled for the target (e.g. host is i686-linux, target is i486-linux). Starting from GCC 4.2, to do this you have to configure explicitly ! with --enable-bootstrap.

!
--enable-generated-files-in-srcdir

Neither the .c and .h files that are generated from Bison and flex nor the info manuals and man pages that are built from the .texi files are present in the repository development tree. When building GCC from that development tree, *************** or from one of our snapshots, those gene *** 1274,1506 **** build directory, which allows for the source to be in a readonly directory.

!

If you configure with --enable-generated-files-in-srcdir then those generated files will go into the source directory. This is mainly intended for generating release or prerelease tarballs of the GCC sources, since it is not a requirement that the users of source releases to have flex, Bison, or makeinfo.

!
--enable-version-specific-runtime-libs

Specify that runtime libraries should be installed in the compiler specific ! subdirectory (libdir/gcc) rather than the usual places. In ! addition, ‘libstdc++’’s include files will be installed into ! libdir unless you overruled it by using ! --with-gxx-include-dir=dirname. Using this option is particularly useful if you intend to use several versions of GCC in ! parallel. The default is ‘yes’ for ‘libada’, and ‘no’ for the remaining libraries.

!
--with-aix-soname=‘aix’, ‘svr4’ or ‘both’
!

Traditional AIX shared library versioning (versioned Shared Object ! files as members of unversioned Archive Library files named ! ‘lib.a’) causes numerous headaches for package managers. However, ! Import Files as members of Archive Library files allow for ! filename-based versioning of shared libraries as seen on Linux/SVR4, where this is called the "SONAME". But as they prevent static linking, ! Import Files may be used with Runtime Linking only, where the ! linker does search for ‘libNAME.so’ before ‘libNAME.a’ library ! filenames with the ‘-lNAME’ linker flag.

!

For detailed information please refer to the AIX ! ld Command reference.

As long as shared library creation is enabled, upon: !

!
--with-aix-soname=aix
!
--with-aix-soname=both
!

A (traditional AIX) Shared Archive Library file is created: !

    !
  • using the ‘libNAME.a’ filename scheme !
  • with the Shared Object file as archive member named ! ‘libNAME.so.V’ (except for ‘libgcc_s’, where the Shared ! Object file is named ‘shr.o’ for backwards compatibility), which !
      !
    • - is used for runtime loading from inside the ‘libNAME.a’ file !
    • - is used for dynamic loading via ! dlopen("libNAME.a(libNAME.so.V)", RTLD_MEMBER) !
    • - is used for shared linking !
    • - is used for static linking, so no separate Static Archive Library file is needed
!
--with-aix-soname=both
!
--with-aix-soname=svr4
!

A (second) Shared Archive Library file is created: !

    !
  • using the ‘libNAME.so.V’ filename scheme !
  • with the Shared Object file as archive member named ! ‘shr.o’, which !
      !
    • - is created with the -G linker flag !
    • - has the F_LOADONLY flag set !
    • - is used for runtime loading from inside the ‘libNAME.so.V’ file !
    • - is used for dynamic loading via dlopen("libNAME.so.V(shr.o)", RTLD_MEMBER)
    !
  • with the Import File as archive member named ‘shr.imp’, which !
      !
    • - refers to ‘libNAME.so.V(shr.o)’ as the "SONAME", to be recorded ! in the Loader Section of subsequent binaries !
    • - indicates whether ‘libNAME.so.V(shr.o)’ is 32 or 64 bit !
    • - lists all the public symbols exported by ‘lib.so.V(shr.o)’, ! eventually decorated with the ‘weak’ Keyword !
    • - is necessary for shared linking against ‘lib.so.V(shr.o)’
!

A symbolic link using the ‘libNAME.so’ filename scheme is created: !

    !
  • pointing to the ‘libNAME.so.V’ Shared Archive Library file !
  • to permit the ld Command to find ‘lib.so.V(shr.imp)’ via ! the ‘-lNAME’ argument (requires Runtime Linking to be enabled) !
  • to permit dynamic loading of ‘lib.so.V(shr.o)’ without the need ! to specify the version number via dlopen("libNAME.so(shr.o)", RTLD_MEMBER)

As long as static library creation is enabled, upon: !

!
--with-aix-soname=svr4
!

A Static Archive Library is created: !

    !
  • using the ‘libNAME.a’ filename scheme !
  • with all the Static Object files as archive members, which !
      !
    • - are used for static linking
!

While the aix-soname=‘svr4’ option does not create Shared Object ! files as members of unversioned Archive Library files any more, package managers still are responsible to ! transfer Shared Object files ! found as member of a previously installed unversioned Archive Library ! file into the newly installed Archive Library file with the same filename.

!

WARNING: Creating Shared Object files with Runtime Linking ! enabled may bloat the TOC, eventually leading to TOC overflow errors, ! requiring the use of either the -Wl,-bbigtoc linker flag (seen to ! break with the GDB debugger) or some of the TOC-related compiler flags, see “RS/6000 and PowerPC Options” in the main manual.

!

--with-aix-soname is currently supported by ‘libgcc_s’ only, so this option is still experimental and not for normal use yet.

!

Default is the traditional behavior --with-aix-soname=‘aix’.

!
--enable-languages=lang1,lang2,…

Specify that only a particular subset of compilers and their runtime libraries should be built. For a list of valid values for ! langN you can issue the following command in the ! gcc directory of your GCC source tree:
!

! 
grep ^language= */config-lang.in

Currently, you can use any of the following: ! all, default, ada, c, c++, d, ! fortran, go, jit, lto, m2, ! objc, obj-c++. Building the Ada compiler has special requirements, see below. ! If you do not pass this flag, or specify the option default, then the ! default languages available in the gcc sub-tree will be configured. Ada, D, Go, Jit, Objective-C++ and Modula-2 are not default languages. LTO is not a ! default language, but is built by default because --enable-lto is enabled by default. The other languages are default languages. If ! all is specified, then all available languages are built. An ! exception is jit language, which requires ! --enable-host-shared to be included with all.

!
--enable-stage1-languages=lang1,lang2,…

Specify that a particular subset of compilers and their runtime libraries should be built with the system C compiler during stage 1 of the bootstrap process, rather than only in later stages with the bootstrapped C compiler. The list of valid values is the same as for ! --enable-languages, and the option all will select all ! of the languages enabled by --enable-languages. This option is primarily useful for GCC development; for instance, when a development version of the compiler cannot bootstrap due to compiler bugs, or when one is debugging front ends other than the C front end. When this option is used, one can then build the target libraries for the ! specified languages with the stage-1 compiler by using make stage1-bubble all-target, or run the testsuite on the stage-1 compiler ! for the specified languages using make stage1-start check-gcc.

!
--disable-libada

Specify that the run-time libraries and tools used by GNAT should not be built. This can be useful for debugging, or for compatibility with previous Ada build procedures, when it was required to explicitly ! do a ‘make -C gcc gnatlib_and_tools’.

!
--disable-libgm2

Specify that the run-time libraries and tools used by Modula-2 should not be built. This can be useful for debugging.

!
--disable-libsanitizer

Specify that the run-time libraries for the various sanitizers should not be built.

!
--disable-libssp

Specify that the run-time libraries for stack smashing protection should not be built or linked against. On many targets library support is provided by the C library instead.

!
--disable-libquadmath

Specify that the GCC quad-precision math library should not be built. On some systems, the library is required to be linkable when building ! the Fortran front end, unless --disable-libquadmath-support is used.

!
--disable-libquadmath-support
!

Specify that the Fortran front end and libgfortran do not add ! support for libquadmath on systems supporting it.

!
--disable-libgomp

Specify that the GNU Offloading and Multi Processing Runtime Library should not be built.

!
--disable-libvtv

Specify that the run-time libraries used by vtable verification should not be built.

!
--with-dwarf2

Specify that the compiler should use DWARF debugging information as the default; the exact DWARF version that is the default is target-specific.

!
--with-advance-toolchain=at

On 64-bit PowerPC Linux systems, configure the compiler to use the header files, library files, and the dynamic linker from the Advance ! Toolchain release at instead of the default versions that are provided by the Linux distribution. In general, this option is intended for the developers of GCC, and it is not intended for general use.

!
--enable-targets=all
!
--enable-targets=target_list

Some GCC targets, e.g. powerpc64-linux, build bi-arch compilers. These are compilers that are able to generate either 64-bit or 32-bit code. Typically, the corresponding 32-bit target, e.g. --- 1264,1496 ---- build directory, which allows for the source to be in a readonly directory.

!

If you configure with --enable-generated-files-in-srcdir then those generated files will go into the source directory. This is mainly intended for generating release or prerelease tarballs of the GCC sources, since it is not a requirement that the users of source releases to have flex, Bison, or makeinfo.

!
--enable-version-specific-runtime-libs

Specify that runtime libraries should be installed in the compiler specific ! subdirectory (libdir/gcc) rather than the usual places. In ! addition, ‘libstdc++’’s include files will be installed into ! libdir unless you overruled it by using ! --with-gxx-include-dir=dirname. Using this option is particularly useful if you intend to use several versions of GCC in ! parallel. The default is ‘yes’ for ‘libada’, and ‘no’ for the remaining libraries.

!
--with-aix-soname=‘aix’, ‘svr4’ or ‘both’
!

Traditional AIX shared library versioning (versioned Shared Object ! files as members of unversioned Archive Library files named ! ‘lib.a’) causes numerous headaches for package managers. However, ! Import Files as members of Archive Library files allow for ! filename-based versioning of shared libraries as seen on Linux/SVR4, where this is called the "SONAME". But as they prevent static linking, ! Import Files may be used with Runtime Linking only, where the ! linker does search for ‘libNAME.so’ before ‘libNAME.a’ library ! filenames with the ‘-lNAME’ linker flag.

!

For detailed information please refer to the AIX ! ld Command reference.

As long as shared library creation is enabled, upon: !

!
--with-aix-soname=aix
!
--with-aix-soname=both
!

A (traditional AIX) Shared Archive Library file is created: !

    !
  • using the ‘libNAME.a’ filename scheme !
  • with the Shared Object file as archive member named ! ‘libNAME.so.V’ (except for ‘libgcc_s’, where the Shared ! Object file is named ‘shr.o’ for backwards compatibility), which !
      !
    • is used for runtime loading from inside the ‘libNAME.a’ file !
    • is used for dynamic loading via ! dlopen("libNAME.a(libNAME.so.V)", RTLD_MEMBER) !
    • is used for shared linking !
    • is used for static linking, so no separate Static Archive Library file is needed
!
--with-aix-soname=both
!
--with-aix-soname=svr4
!

A (second) Shared Archive Library file is created: !

    !
  • using the ‘libNAME.so.V’ filename scheme !
  • with the Shared Object file as archive member named ! ‘shr.o’, which !
      !
    • is created with the -G linker flag !
    • has the F_LOADONLY flag set !
    • is used for runtime loading from inside the ‘libNAME.so.V’ file !
    • is used for dynamic loading via dlopen("libNAME.so.V(shr.o)", RTLD_MEMBER)
    !
  • with the Import File as archive member named ‘shr.imp’, which !
      !
    • refers to ‘libNAME.so.V(shr.o)’ as the "SONAME", to be recorded ! in the Loader Section of subsequent binaries !
    • indicates whether ‘libNAME.so.V(shr.o)’ is 32 or 64 bit !
    • lists all the public symbols exported by ‘lib.so.V(shr.o)’, ! eventually decorated with the ‘weak’ Keyword !
    • is necessary for shared linking against ‘lib.so.V(shr.o)’
!

A symbolic link using the ‘libNAME.so’ filename scheme is created: !

    !
  • pointing to the ‘libNAME.so.V’ Shared Archive Library file !
  • to permit the ld Command to find ‘lib.so.V(shr.imp)’ via ! the ‘-lNAME’ argument (requires Runtime Linking to be enabled) !
  • to permit dynamic loading of ‘lib.so.V(shr.o)’ without the need ! to specify the version number via dlopen("libNAME.so(shr.o)", RTLD_MEMBER)

As long as static library creation is enabled, upon: !

!
--with-aix-soname=svr4
!

A Static Archive Library is created: !

    !
  • using the ‘libNAME.a’ filename scheme !
  • with all the Static Object files as archive members, which !
      !
    • are used for static linking
!

While the aix-soname=‘svr4’ option does not create Shared Object ! files as members of unversioned Archive Library files any more, package managers still are responsible to ! transfer Shared Object files ! found as member of a previously installed unversioned Archive Library ! file into the newly installed Archive Library file with the same filename.

!

WARNING: Creating Shared Object files with Runtime Linking ! enabled may bloat the TOC, eventually leading to TOC overflow errors, ! requiring the use of either the -Wl,-bbigtoc linker flag (seen to ! break with the GDB debugger) or some of the TOC-related compiler flags, see “RS/6000 and PowerPC Options” in the main manual.

!

--with-aix-soname is currently supported by ‘libgcc_s’ only, so this option is still experimental and not for normal use yet.

!

Default is the traditional behavior --with-aix-soname=‘aix’.

!
--enable-languages=lang1,lang2,…

Specify that only a particular subset of compilers and their runtime libraries should be built. For a list of valid values for ! langN you can issue the following command in the ! gcc directory of your GCC source tree:
!

! 
grep ^language= */config-lang.in

Currently, you can use any of the following: ! all, default, ada, c, c++, d, ! fortran, go, jit, lto, m2, ! objc, obj-c++. Building the Ada compiler has special requirements, see below. ! If you do not pass this flag, or specify the option default, then the ! default languages available in the gcc sub-tree will be configured. Ada, D, Go, Jit, Objective-C++ and Modula-2 are not default languages. LTO is not a ! default language, but is built by default because --enable-lto is enabled by default. The other languages are default languages. If ! all is specified, then all available languages are built. An ! exception is jit language, which requires ! --enable-host-shared to be included with all.

!
--enable-stage1-languages=lang1,lang2,…

Specify that a particular subset of compilers and their runtime libraries should be built with the system C compiler during stage 1 of the bootstrap process, rather than only in later stages with the bootstrapped C compiler. The list of valid values is the same as for ! --enable-languages, and the option all will select all ! of the languages enabled by --enable-languages. This option is primarily useful for GCC development; for instance, when a development version of the compiler cannot bootstrap due to compiler bugs, or when one is debugging front ends other than the C front end. When this option is used, one can then build the target libraries for the ! specified languages with the stage-1 compiler by using make stage1-bubble all-target, or run the testsuite on the stage-1 compiler ! for the specified languages using make stage1-start check-gcc.

!
--disable-libada

Specify that the run-time libraries and tools used by GNAT should not be built. This can be useful for debugging, or for compatibility with previous Ada build procedures, when it was required to explicitly ! do a ‘make -C gcc gnatlib_and_tools’.

!
--disable-libgm2

Specify that the run-time libraries and tools used by Modula-2 should not be built. This can be useful for debugging.

!
--disable-libsanitizer

Specify that the run-time libraries for the various sanitizers should not be built.

!
--disable-libssp

Specify that the run-time libraries for stack smashing protection should not be built or linked against. On many targets library support is provided by the C library instead.

!
--disable-libquadmath

Specify that the GCC quad-precision math library should not be built. On some systems, the library is required to be linkable when building ! the Fortran front end, unless --disable-libquadmath-support is used.

!
--disable-libquadmath-support
!

Specify that the Fortran front end and libgfortran do not add ! support for libquadmath on systems supporting it.

!
--disable-libgomp

Specify that the GNU Offloading and Multi Processing Runtime Library should not be built.

!
--disable-libvtv

Specify that the run-time libraries used by vtable verification should not be built.

!
--with-dwarf2

Specify that the compiler should use DWARF debugging information as the default; the exact DWARF version that is the default is target-specific.

!
--with-advance-toolchain=at

On 64-bit PowerPC Linux systems, configure the compiler to use the header files, library files, and the dynamic linker from the Advance ! Toolchain release at instead of the default versions that are provided by the Linux distribution. In general, this option is intended for the developers of GCC, and it is not intended for general use.

!
--enable-targets=all
!
--enable-targets=target_list

Some GCC targets, e.g. powerpc64-linux, build bi-arch compilers. These are compilers that are able to generate either 64-bit or 32-bit code. Typically, the corresponding 32-bit target, e.g. *************** Currently, this option only affects spar *** 1514,1687 **** mips-linux and s390-linux.

!
--enable-default-pie
!

Turn on -fPIE and -pie by default.

!
--enable-secureplt
!

This option enables -msecure-plt by default for powerpc-linux. See “RS/6000 and PowerPC Options” in the main manual

!
--enable-default-ssp
!

Turn on -fstack-protector-strong by default.

!
--enable-cld
!

This option enables -mcld by default for 32-bit x86 targets. See “i386 and x86-64 Options” in the main manual

!
--enable-large-address-aware
!

The --enable-large-address-aware option arranges for MinGW ! executables to be linked using the --large-address-aware option, that enables the use of more than 2GB of memory. If GCC is configured with this option, its effects can be reversed by passing the ! -Wl,--disable-large-address-aware option to the so-configured compiler driver.

!
--enable-win32-registry
!
--enable-win32-registry=key
!
--disable-win32-registry
!

The --enable-win32-registry option enables Microsoft Windows-hosted GCC to look up installations paths in the registry using the following key:

!
! 
HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\key
!

key defaults to GCC version number, and can be overridden by the ! --enable-win32-registry=key option. Vendors and distributors who use custom installers are encouraged to provide a different key, perhaps one comprised of vendor name and GCC version number, to avoid conflict with existing installations. This feature is enabled ! by default, and can be disabled by --disable-win32-registry option. This option has no effect on the other hosts.

!
--nfp

Specify that the machine does not have a floating point unit. This ! option only applies to ‘m68k-sun-sunosn’. On any other ! system, --nfp has no effect.

!
--enable-werror
!
--disable-werror
!
--enable-werror=yes
!
--enable-werror=no

When you specify this option, it controls whether certain files in the ! compiler are built with -Werror in bootstrap stage2 and later. ! If you don’t specify it, -Werror is turned on for the main development trunk. However it defaults to off for release branches and ! final releases. The specific files which get -Werror are controlled by the Makefiles.

!
--enable-checking
!
--disable-checking
!
--enable-checking=list

This option controls performing internal consistency checks in the compiler. It does not change the generated code, but adds error checking of the requested complexity. This slows down the compiler and may only work properly if you are building the compiler with GCC.

When the option is not specified, the active set of checks depends on context. ! Namely, bootstrap stage 1 defaults to ‘--enable-checking=yes’, builds from release branches or release archives default to ! ‘--enable-checking=release’, and otherwise ! ‘--enable-checking=yes,extra’ is used. When the option is ! specified without a list, the result is the same as ! ‘--enable-checking=yes’. Likewise, ‘--disable-checking’ is ! equivalent to ‘--enable-checking=no’.

!

The categories of checks available in list are ‘yes’ (most common ! checks ‘assert,misc,gc,gimple,rtlflag,runtime,tree,types’), ‘no’ ! (no checks at all), ‘all’ (all but ‘valgrind’), ‘release’ ! (cheapest checks ‘assert,runtime’) or ‘none’ (same as ‘no’). ! ‘release’ checks are always on and to disable them ! ‘--disable-checking’ or ‘--enable-checking=no[,<other checks>]’ must be explicitly requested. Disabling assertions makes the compiler and runtime slightly faster but increases the risk of undetected internal errors causing wrong code to be generated.

!

Individual checks can be enabled with these flags: ‘assert’, ‘df’, ! ‘extra’, ‘fold’, ‘gc’, ‘gcac’, ‘gimple’, ! ‘misc’, ‘rtl’, ‘rtlflag’, ‘runtime’, ‘tree’, ! ‘types’ and ‘valgrind’. ‘extra’ extends ‘misc’ checking with extra checks that might affect code generation and should therefore not differ between stage1 and later stages in bootstrap.

!

The ‘valgrind’ check requires the external valgrind simulator, ! available from https://valgrind.org. The ‘rtl’ checks are ! expensive and the ‘df’, ‘gcac’ and ‘valgrind’ checks are very expensive.

!
--disable-stage1-checking
!
--enable-stage1-checking
!
--enable-stage1-checking=list
!

This option affects only bootstrap build. If no --enable-checking ! option is specified the stage1 compiler is built with ‘yes’ checking enabled, otherwise the stage1 checking flags are the same as specified by ! --enable-checking. To build the stage1 compiler with ! different checking options use --enable-stage1-checking. ! The list of checking options is the same as for --enable-checking. If your system is too slow or too small to bootstrap a released compiler ! with checking for stage1 enabled, you can use ‘--disable-stage1-checking’ to disable checking for the stage1 compiler.

!
--enable-coverage
!
--enable-coverage=level

With this option, the compiler is built to collect self coverage information, every time it is run. This is for internal development purposes, and only works when the compiler is being built with gcc. The ! level argument controls whether the compiler is built optimized or ! not, values are ‘opt’ and ‘noopt’. For coverage analysis you want to disable optimization, for performance analysis you want to enable optimization. When coverage is enabled, the default level is without optimization.

!
--enable-gather-detailed-mem-stats

When this option is specified more detailed information on memory allocation is gathered. This information is printed when using ! -fmem-report.

!
--enable-valgrind-annotations

Mark selected memory related operations in the compiler when run under valgrind to suppress false positives.

!
--enable-nls
!
--disable-nls
!

The --enable-nls option enables Native Language Support (NLS), which lets GCC output diagnostics in languages other than American English. Native Language Support is enabled by default if not doing a ! canadian cross build. The --disable-nls option disables NLS.

!
--with-included-gettext
!

If NLS is enabled, the --with-included-gettext option causes the build ! procedure to prefer its copy of GNU gettext.

!
--with-catgets
!

If NLS is enabled, and if the host lacks gettext but has the ! inferior catgets interface, the GCC build procedure normally ! ignores catgets and instead uses GCC’s copy of the GNU ! gettext library. The --with-catgets option causes the ! build procedure to use the host’s catgets in this situation.

!
--with-libiconv-prefix=dir
!

Search for libiconv header files in dir/include and ! libiconv library files in dir/lib.

!
--enable-obsolete

Enable configuration for an obsoleted system. If you attempt to configure GCC for a system (build, host, or target) which has been obsoleted, and you do not specify this flag, configure will halt with an --- 1504,1677 ---- mips-linux and s390-linux.

!
--enable-default-pie
!

Turn on -fPIE and -pie by default.

!
--enable-secureplt
!

This option enables -msecure-plt by default for powerpc-linux. See “RS/6000 and PowerPC Options” in the main manual

!
--enable-default-ssp
!

Turn on -fstack-protector-strong by default.

!
--enable-cld
!

This option enables -mcld by default for 32-bit x86 targets. See “i386 and x86-64 Options” in the main manual

!
--enable-large-address-aware
!

The --enable-large-address-aware option arranges for MinGW ! executables to be linked using the --large-address-aware option, that enables the use of more than 2GB of memory. If GCC is configured with this option, its effects can be reversed by passing the ! -Wl,--disable-large-address-aware option to the so-configured compiler driver.

!
--enable-win32-registry
!
--enable-win32-registry=key
!
--disable-win32-registry
!

The --enable-win32-registry option enables Microsoft Windows-hosted GCC to look up installations paths in the registry using the following key:

!
! 
HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\key
!

key defaults to GCC version number, and can be overridden by the ! --enable-win32-registry=key option. Vendors and distributors who use custom installers are encouraged to provide a different key, perhaps one comprised of vendor name and GCC version number, to avoid conflict with existing installations. This feature is enabled ! by default, and can be disabled by --disable-win32-registry option. This option has no effect on the other hosts.

!
--nfp

Specify that the machine does not have a floating point unit. This ! option only applies to ‘m68k-sun-sunosn’. On any other ! system, --nfp has no effect.

!
--enable-werror
!
--disable-werror
!
--enable-werror=yes
!
--enable-werror=no

When you specify this option, it controls whether certain files in the ! compiler are built with -Werror in bootstrap stage2 and later. ! If you don’t specify it, -Werror is turned on for the main development trunk. However it defaults to off for release branches and ! final releases. The specific files which get -Werror are controlled by the Makefiles.

!
--enable-checking
!
--disable-checking
!
--enable-checking=list

This option controls performing internal consistency checks in the compiler. It does not change the generated code, but adds error checking of the requested complexity. This slows down the compiler and may only work properly if you are building the compiler with GCC.

When the option is not specified, the active set of checks depends on context. ! Namely, bootstrap stage 1 defaults to ‘--enable-checking=yes’, builds from release branches or release archives default to ! ‘--enable-checking=release’, and otherwise ! ‘--enable-checking=yes,extra’ is used. When the option is ! specified without a list, the result is the same as ! ‘--enable-checking=yes’. Likewise, ‘--disable-checking’ is ! equivalent to ‘--enable-checking=no’.

!

The categories of checks available in list are ‘yes’ (most common ! checks ‘assert,misc,gc,gimple,rtlflag,runtime,tree,types’), ‘no’ ! (no checks at all), ‘all’ (all but ‘valgrind’), ‘release’ ! (cheapest checks ‘assert,runtime’) or ‘none’ (same as ‘no’). ! ‘release’ checks are always on and to disable them ! ‘--disable-checking’ or ‘--enable-checking=no[,<other checks>]’ must be explicitly requested. Disabling assertions makes the compiler and runtime slightly faster but increases the risk of undetected internal errors causing wrong code to be generated.

!

Individual checks can be enabled with these flags: ‘assert’, ‘df’, ! ‘extra’, ‘fold’, ‘gc’, ‘gcac’, ‘gimple’, ! ‘misc’, ‘rtl’, ‘rtlflag’, ‘runtime’, ‘tree’, ! ‘types’ and ‘valgrind’. ‘extra’ extends ‘misc’ checking with extra checks that might affect code generation and should therefore not differ between stage1 and later stages in bootstrap.

!

The ‘valgrind’ check requires the external valgrind simulator, ! available from https://valgrind.org. The ‘rtl’ checks are ! expensive and the ‘df’, ‘gcac’ and ‘valgrind’ checks are very expensive.

!
--disable-stage1-checking
!
--enable-stage1-checking
!
--enable-stage1-checking=list
!

This option affects only bootstrap build. If no --enable-checking ! option is specified the stage1 compiler is built with ‘yes’ checking enabled, otherwise the stage1 checking flags are the same as specified by ! --enable-checking. To build the stage1 compiler with ! different checking options use --enable-stage1-checking. ! The list of checking options is the same as for --enable-checking. If your system is too slow or too small to bootstrap a released compiler ! with checking for stage1 enabled, you can use ‘--disable-stage1-checking’ to disable checking for the stage1 compiler.

!
--enable-coverage
!
--enable-coverage=level

With this option, the compiler is built to collect self coverage information, every time it is run. This is for internal development purposes, and only works when the compiler is being built with gcc. The ! level argument controls whether the compiler is built optimized or ! not, values are ‘opt’ and ‘noopt’. For coverage analysis you want to disable optimization, for performance analysis you want to enable optimization. When coverage is enabled, the default level is without optimization.

!
--enable-gather-detailed-mem-stats

When this option is specified more detailed information on memory allocation is gathered. This information is printed when using ! -fmem-report.

!
--enable-valgrind-annotations

Mark selected memory related operations in the compiler when run under valgrind to suppress false positives.

!
--enable-nls
!
--disable-nls
!

The --enable-nls option enables Native Language Support (NLS), which lets GCC output diagnostics in languages other than American English. Native Language Support is enabled by default if not doing a ! canadian cross build. The --disable-nls option disables NLS.

!
--with-included-gettext
!

If NLS is enabled, the --with-included-gettext option causes the build ! procedure to prefer its copy of GNU gettext.

!
--with-catgets
!

If NLS is enabled, and if the host lacks gettext but has the ! inferior catgets interface, the GCC build procedure normally ! ignores catgets and instead uses GCC’s copy of the GNU ! gettext library. The --with-catgets option causes the ! build procedure to use the host’s catgets in this situation.

!
--with-libiconv-prefix=dir
!

Search for libiconv header files in dir/include and ! libiconv library files in dir/lib.

!
--enable-obsolete

Enable configuration for an obsoleted system. If you attempt to configure GCC for a system (build, host, or target) which has been obsoleted, and you do not specify this flag, configure will halt with an *************** is removed entirely in the next major re *** 1692,1798 **** forward to maintain the port.

!
--enable-decimal-float
!
--enable-decimal-float=yes
!
--enable-decimal-float=no
!
--enable-decimal-float=bid
!
--enable-decimal-float=dpd
!
--disable-decimal-float

Enable (or disable) support for the C decimal floating point extension that is in the IEEE 754-2008 standard. This is enabled by default only on AArch64, PowerPC, i386, and x86_64 GNU/Linux systems. Other systems may also support it, but require the user to specifically enable it. You can optionally control which decimal floating point ! format is used (either ‘bid’ or ‘dpd’). The ‘bid’ (binary integer decimal) format is default on AArch64, i386 and x86_64 ! systems, and the ‘dpd’ (densely packed decimal) format is default on PowerPC systems.

!
--enable-fixed-point
!
--disable-fixed-point

Enable (or disable) support for C fixed-point arithmetic. This option is enabled by default for some targets (such as MIPS) which have hardware-support for fixed-point operations. On other targets, you may enable this option manually.

!
--with-long-double-128
!

Specify if long double type should be 128-bit by default on selected ! GNU/Linux architectures. If using --without-long-double-128, ! long double will be by default 64-bit, the same as double type. When neither of these configure options are used, the default will be ! 128-bit long double when built against GNU C Library 2.4 and later, ! 64-bit long double otherwise.

!
--with-long-double-format=ibm
!
--with-long-double-format=ieee
!

Specify whether long double uses the IBM extended double format or the IEEE 128-bit floating point format on PowerPC Linux systems. This configuration switch will only work on little endian PowerPC Linux systems and on big endian 64-bit systems where the default cpu ! is at least power7 (i.e. --with-cpu=power7, ! --with-cpu=power8, or --with-cpu=power9 is used).

!

If you use the --with-long-double-64 configuration option, ! the --with-long-double-format=ibm and ! --with-long-double-format=ieee options are ignored.

!

The default long double format is to use IBM extended double. Until all of the libraries are converted to use IEEE 128-bit floating point, it is not recommended to use ! --with-long-double-format=ieee.

!
--enable-fdpic

On SH Linux systems, generate ELF FDPIC code.

!
--with-gmp=pathname
!
--with-gmp-include=pathname
!
--with-gmp-lib=pathname
!
--with-mpfr=pathname
!
--with-mpfr-include=pathname
!
--with-mpfr-lib=pathname
!
--with-mpc=pathname
!
--with-mpc-include=pathname
!
--with-mpc-lib=pathname

If you want to build GCC but do not have the GMP library, the MPFR library and/or the MPC library installed in a standard location and do not have their sources present in the GCC source tree then you can explicitly specify the directory where they are installed ! (‘--with-gmp=gmpinstalldir’, ! ‘--with-mpfr=mpfrinstalldir’, ! ‘--with-mpc=mpcinstalldir’). The ! --with-gmp=gmpinstalldir option is shorthand for ! --with-gmp-lib=gmpinstalldir/lib and ! --with-gmp-include=gmpinstalldir/include. Likewise the ! --with-mpfr=mpfrinstalldir option is shorthand for ! --with-mpfr-lib=mpfrinstalldir/lib and ! --with-mpfr-include=mpfrinstalldir/include, also the ! --with-mpc=mpcinstalldir option is shorthand for ! --with-mpc-lib=mpcinstalldir/lib and ! --with-mpc-include=mpcinstalldir/include. If these shorthand assumptions are not correct, you can use the explicit include and lib options directly. You might also need to ensure the shared libraries can be found by the dynamic linker when building and using GCC, for example by setting the runtime shared library path ! variable (LD_LIBRARY_PATH on GNU/Linux and Solaris systems).

These flags are applicable to the host platform only. When building a cross compiler, they will not be used to configure target libraries.

!
--with-isl=pathname
!
--with-isl-include=pathname
!
--with-isl-lib=pathname

If you do not have the isl library installed in a standard location and you want to build GCC, you can explicitly specify the directory where it is ! installed (‘--with-isl=islinstalldir’). The ! --with-isl=islinstalldir option is shorthand for ! --with-isl-lib=islinstalldir/lib and ! --with-isl-include=islinstalldir/include. If this shorthand assumption is not correct, you can use the explicit include and lib options directly.

--- 1682,1788 ---- forward to maintain the port.

!
--enable-decimal-float
!
--enable-decimal-float=yes
!
--enable-decimal-float=no
!
--enable-decimal-float=bid
!
--enable-decimal-float=dpd
!
--disable-decimal-float

Enable (or disable) support for the C decimal floating point extension that is in the IEEE 754-2008 standard. This is enabled by default only on AArch64, PowerPC, i386, and x86_64 GNU/Linux systems. Other systems may also support it, but require the user to specifically enable it. You can optionally control which decimal floating point ! format is used (either ‘bid’ or ‘dpd’). The ‘bid’ (binary integer decimal) format is default on AArch64, i386 and x86_64 ! systems, and the ‘dpd’ (densely packed decimal) format is default on PowerPC systems.

!
--enable-fixed-point
!
--disable-fixed-point

Enable (or disable) support for C fixed-point arithmetic. This option is enabled by default for some targets (such as MIPS) which have hardware-support for fixed-point operations. On other targets, you may enable this option manually.

!
--with-long-double-128
!

Specify if long double type should be 128-bit by default on selected ! GNU/Linux architectures. If using --without-long-double-128, ! long double will be by default 64-bit, the same as double type. When neither of these configure options are used, the default will be ! 128-bit long double when built against GNU C Library 2.4 and later, ! 64-bit long double otherwise.

!
--with-long-double-format=ibm
!
--with-long-double-format=ieee
!

Specify whether long double uses the IBM extended double format or the IEEE 128-bit floating point format on PowerPC Linux systems. This configuration switch will only work on little endian PowerPC Linux systems and on big endian 64-bit systems where the default cpu ! is at least power7 (i.e. --with-cpu=power7, ! --with-cpu=power8, or --with-cpu=power9 is used).

!

If you use the --with-long-double-64 configuration option, ! the --with-long-double-format=ibm and ! --with-long-double-format=ieee options are ignored.

!

The default long double format is to use IBM extended double. Until all of the libraries are converted to use IEEE 128-bit floating point, it is not recommended to use ! --with-long-double-format=ieee.

!
--enable-fdpic

On SH Linux systems, generate ELF FDPIC code.

!
--with-gmp=pathname
!
--with-gmp-include=pathname
!
--with-gmp-lib=pathname
!
--with-mpfr=pathname
!
--with-mpfr-include=pathname
!
--with-mpfr-lib=pathname
!
--with-mpc=pathname
!
--with-mpc-include=pathname
!
--with-mpc-lib=pathname

If you want to build GCC but do not have the GMP library, the MPFR library and/or the MPC library installed in a standard location and do not have their sources present in the GCC source tree then you can explicitly specify the directory where they are installed ! (‘--with-gmp=gmpinstalldir’, ! ‘--with-mpfr=mpfrinstalldir’, ! ‘--with-mpc=mpcinstalldir’). The ! --with-gmp=gmpinstalldir option is shorthand for ! --with-gmp-lib=gmpinstalldir/lib and ! --with-gmp-include=gmpinstalldir/include. Likewise the ! --with-mpfr=mpfrinstalldir option is shorthand for ! --with-mpfr-lib=mpfrinstalldir/lib and ! --with-mpfr-include=mpfrinstalldir/include, also the ! --with-mpc=mpcinstalldir option is shorthand for ! --with-mpc-lib=mpcinstalldir/lib and ! --with-mpc-include=mpcinstalldir/include. If these shorthand assumptions are not correct, you can use the explicit include and lib options directly. You might also need to ensure the shared libraries can be found by the dynamic linker when building and using GCC, for example by setting the runtime shared library path ! variable (LD_LIBRARY_PATH on GNU/Linux and Solaris systems).

These flags are applicable to the host platform only. When building a cross compiler, they will not be used to configure target libraries.

!
--with-isl=pathname
!
--with-isl-include=pathname
!
--with-isl-lib=pathname

If you do not have the isl library installed in a standard location and you want to build GCC, you can explicitly specify the directory where it is ! installed (‘--with-isl=islinstalldir’). The ! --with-isl=islinstalldir option is shorthand for ! --with-isl-lib=islinstalldir/lib and ! --with-isl-include=islinstalldir/include. If this shorthand assumption is not correct, you can use the explicit include and lib options directly.

*************** include and lib options directly. *** 1800,1926 **** a cross compiler, they will not be used to configure target libraries.

!
--with-stage1-ldflags=flags

This option may be used to set linker flags to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with ! --disable-bootstrap. If --with-stage1-libs is not set to a ! value, then the default is ‘-static-libstdc++ -static-libgcc’, if supported.

!
--with-stage1-libs=libs

This option may be used to set libraries to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with ! --disable-bootstrap.

!
--with-boot-ldflags=flags

This option may be used to set linker flags to be used when linking stage 2 and later when bootstrapping GCC. If –with-boot-libs is not is set to a value, then the default is ! ‘-static-libstdc++ -static-libgcc’.

!
--with-boot-libs=libs

This option may be used to set libraries to be used when linking stage 2 and later when bootstrapping GCC.

!
--with-debug-prefix-map=map
!

Convert source directory names using -fdebug-prefix-map when ! building runtime libraries. ‘map’ is a space-separated ! list of maps of the form ‘old=new’.

!
--enable-linker-build-id
!

Tells GCC to pass --build-id option to the linker for all final ! links (links performed without the -r or --relocatable option), if the linker supports it. If you specify ! --enable-linker-build-id, but your linker does not ! support --build-id option, a warning is issued and the ! --enable-linker-build-id option is ignored. The default is off.

!
--with-linker-hash-style=choice
!

Tells GCC to pass --hash-style=choice option to the ! linker for all final links. choice can be one of ! ‘sysv’, ‘gnu’, and ‘both’ where ‘sysv’ is the default.

!
--enable-gnu-unique-object
!
--disable-gnu-unique-object

Tells GCC to use the gnu_unique_object relocation for C++ template static data members and inline function local statics. Enabled by default for a toolchain with an assembler that accepts it and GLIBC 2.11 or above, otherwise disabled.

!
--with-diagnostics-color=choice
!

Tells GCC to use choice as the default for -fdiagnostics-color= ! option (if not used explicitly on the command line). choice ! can be one of ‘never’, ‘auto’, ‘always’, and ‘auto-if-env’ ! where ‘auto’ is the default. ‘auto-if-env’ makes ! -fdiagnostics-color=auto the default if GCC_COLORS is present and non-empty in the environment of the compiler, and ! -fdiagnostics-color=never otherwise.

!
--with-diagnostics-urls=choice
!

Tells GCC to use choice as the default for -fdiagnostics-urls= ! option (if not used explicitly on the command line). choice ! can be one of ‘never’, ‘auto’, ‘always’, and ‘auto-if-env’ ! where ‘auto’ is the default. ‘auto-if-env’ makes ! -fdiagnostics-urls=auto the default if GCC_URLS ! or TERM_URLS is present and non-empty in the environment of the ! compiler, and -fdiagnostics-urls=never otherwise.

!
--enable-lto
!
--disable-lto

Enable support for link-time optimization (LTO). This is enabled by ! default, and may be disabled using --disable-lto.

!
--enable-linker-plugin-configure-flags=FLAGS
!
--enable-linker-plugin-flags=FLAGS

By default, linker plugins (such as the LTO plugin) are built for the host system architecture. For the case that the linker has a different (but run-time compatible) architecture, these flags can be specified to build plugins that are compatible to the linker. For example, if you are building GCC for a 64-bit x86_64 ! (‘x86_64-pc-linux-gnu’) host system, but have a 32-bit x86 ! GNU/Linux (‘i686-pc-linux-gnu’) linker executable (which is executable on the former system), you can configure GCC as follows for getting compatible linker plugins:

!
! 
% srcdir/configure \
      --host=x86_64-pc-linux-gnu \
      --enable-linker-plugin-configure-flags=--host=i686-pc-linux-gnu \
      --enable-linker-plugin-flags='CC=gcc\ -m32\ -Wl,-rpath,[...]/i686-pc-linux-gnu/lib'
!
--with-plugin-ld=pathname

Enable an alternate linker to be used at link-time optimization (LTO) ! link time when -fuse-linker-plugin is enabled. This linker should have plugin support such as gold starting with version 2.20 or GNU ld starting with version 2.21. ! See -fuse-linker-plugin for details.

!
--enable-canonical-system-headers
!
--disable-canonical-system-headers
!

Enable system header path canonicalization for libcpp. This can produce shorter header file paths in diagnostics and dependency output files, but these changed header paths may conflict with some compilation environments. Enabled by default, and may be disabled using ! --disable-canonical-system-headers.

!
--with-glibc-version=major.minor

Tell GCC that when the GNU C Library (glibc) is used on the target it ! will be version major.minor or later. Normally this can be detected from the C library’s header files, but this option may be needed when bootstrapping a cross toolchain without the header files available for building the initial bootstrap compiler. --- 1790,1916 ---- a cross compiler, they will not be used to configure target libraries.

!
--with-stage1-ldflags=flags

This option may be used to set linker flags to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with ! --disable-bootstrap. If --with-stage1-libs is not set to a ! value, then the default is ‘-static-libstdc++ -static-libgcc’, if supported.

!
--with-stage1-libs=libs

This option may be used to set libraries to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with ! --disable-bootstrap.

!
--with-boot-ldflags=flags

This option may be used to set linker flags to be used when linking stage 2 and later when bootstrapping GCC. If –with-boot-libs is not is set to a value, then the default is ! ‘-static-libstdc++ -static-libgcc’.

!
--with-boot-libs=libs

This option may be used to set libraries to be used when linking stage 2 and later when bootstrapping GCC.

!
--with-debug-prefix-map=map
!

Convert source directory names using -fdebug-prefix-map when ! building runtime libraries. ‘map’ is a space-separated ! list of maps of the form ‘old=new’.

!
--enable-linker-build-id
!

Tells GCC to pass --build-id option to the linker for all final ! links (links performed without the -r or --relocatable option), if the linker supports it. If you specify ! --enable-linker-build-id, but your linker does not ! support --build-id option, a warning is issued and the ! --enable-linker-build-id option is ignored. The default is off.

!
--with-linker-hash-style=choice
!

Tells GCC to pass --hash-style=choice option to the ! linker for all final links. choice can be one of ! ‘sysv’, ‘gnu’, and ‘both’ where ‘sysv’ is the default.

!
--enable-gnu-unique-object
!
--disable-gnu-unique-object

Tells GCC to use the gnu_unique_object relocation for C++ template static data members and inline function local statics. Enabled by default for a toolchain with an assembler that accepts it and GLIBC 2.11 or above, otherwise disabled.

!
--with-diagnostics-color=choice
!

Tells GCC to use choice as the default for -fdiagnostics-color= ! option (if not used explicitly on the command line). choice ! can be one of ‘never’, ‘auto’, ‘always’, and ‘auto-if-env’ ! where ‘auto’ is the default. ‘auto-if-env’ makes ! -fdiagnostics-color=auto the default if GCC_COLORS is present and non-empty in the environment of the compiler, and ! -fdiagnostics-color=never otherwise.

!
--with-diagnostics-urls=choice
!

Tells GCC to use choice as the default for -fdiagnostics-urls= ! option (if not used explicitly on the command line). choice ! can be one of ‘never’, ‘auto’, ‘always’, and ‘auto-if-env’ ! where ‘auto’ is the default. ‘auto-if-env’ makes ! -fdiagnostics-urls=auto the default if GCC_URLS ! or TERM_URLS is present and non-empty in the environment of the ! compiler, and -fdiagnostics-urls=never otherwise.

!
--enable-lto
!
--disable-lto

Enable support for link-time optimization (LTO). This is enabled by ! default, and may be disabled using --disable-lto.

!
--enable-linker-plugin-configure-flags=FLAGS
!
--enable-linker-plugin-flags=FLAGS

By default, linker plugins (such as the LTO plugin) are built for the host system architecture. For the case that the linker has a different (but run-time compatible) architecture, these flags can be specified to build plugins that are compatible to the linker. For example, if you are building GCC for a 64-bit x86_64 ! (‘x86_64-pc-linux-gnu’) host system, but have a 32-bit x86 ! GNU/Linux (‘i686-pc-linux-gnu’) linker executable (which is executable on the former system), you can configure GCC as follows for getting compatible linker plugins:

!
! 
% srcdir/configure \
      --host=x86_64-pc-linux-gnu \
      --enable-linker-plugin-configure-flags=--host=i686-pc-linux-gnu \
      --enable-linker-plugin-flags='CC=gcc\ -m32\ -Wl,-rpath,[...]/i686-pc-linux-gnu/lib'
!
--with-plugin-ld=pathname

Enable an alternate linker to be used at link-time optimization (LTO) ! link time when -fuse-linker-plugin is enabled. This linker should have plugin support such as gold starting with version 2.20 or GNU ld starting with version 2.21. ! See -fuse-linker-plugin for details.

!
--enable-canonical-system-headers
!
--disable-canonical-system-headers
!

Enable system header path canonicalization for libcpp. This can produce shorter header file paths in diagnostics and dependency output files, but these changed header paths may conflict with some compilation environments. Enabled by default, and may be disabled using ! --disable-canonical-system-headers.

!
--with-glibc-version=major.minor

Tell GCC that when the GNU C Library (glibc) is used on the target it ! will be version major.minor or later. Normally this can be detected from the C library’s header files, but this option may be needed when bootstrapping a cross toolchain without the header files available for building the initial bootstrap compiler. *************** However, such configurations may not wor *** 1931,1953 **** configuration in GCC is on a per-multilib basis.

!
--enable-as-accelerator-for=target
!

Build as offload target compiler. Specify offload host triple by target.

!
--enable-offload-targets=target1[=path1],…,targetN[=pathN]
!

Enable offloading to targets target1, …, targetN. Offload compilers are expected to be already installed. Default search ! path for them is exec-prefix, but it can be changed by ! specifying paths path1, …, pathN.

!
! 
% srcdir/configure \
      --enable-offload-targets=amdgcn-amdhsa,nvptx-none
!
--enable-offload-defaulted

Tell GCC that configured but not installed offload compilers and libgomp plugins are silently ignored. Useful for distribution compilers where --- 1921,1943 ---- configuration in GCC is on a per-multilib basis.

!
--enable-as-accelerator-for=target
!

Build as offload target compiler. Specify offload host triple by target.

!
--enable-offload-targets=target1[=path1],…,targetN[=pathN]
!

Enable offloading to targets target1, …, targetN. Offload compilers are expected to be already installed. Default search ! path for them is exec-prefix, but it can be changed by ! specifying paths path1, …, pathN.

!
! 
% srcdir/configure \
      --enable-offload-targets=amdgcn-amdhsa,nvptx-none
!
--enable-offload-defaulted

Tell GCC that configured but not installed offload compilers and libgomp plugins are silently ignored. Useful for distribution compilers where *************** of those optional packages should determ *** 1956,1976 **** target set rather than the GCC configure-time selection.

!
--enable-cet
!
--disable-cet

Enable building target run-time libraries with control-flow ! instrumentation, see -fcf-protection option. When ! --enable-cet is specified target libraries are configured ! to add -fcf-protection and, if needed, other target specific options to a set of building options.

!

--enable-cet=auto is default. CET is enabled on Linux/x86 if ! target binutils supports Intel CET instructions and disabled otherwise. In this case, the target libraries are configured to get ! additional -fcf-protection option.

!
--with-riscv-attribute=‘yes’, ‘no’ or ‘default’

Generate RISC-V attribute by default, in order to record extra build information in object.

--- 1946,1966 ---- target set rather than the GCC configure-time selection.

!
--enable-cet
!
--disable-cet

Enable building target run-time libraries with control-flow ! instrumentation, see -fcf-protection option. When ! --enable-cet is specified target libraries are configured ! to add -fcf-protection and, if needed, other target specific options to a set of building options.

!

--enable-cet=auto is default. CET is enabled on Linux/x86 if ! target binutils supports Intel CET instructions and disabled otherwise. In this case, the target libraries are configured to get ! additional -fcf-protection option.

!
--with-riscv-attribute=‘yes’, ‘no’ or ‘default’

Generate RISC-V attribute by default, in order to record extra build information in object.

*************** information in object. *** 1978,1988 **** target if target binutils supported.

!
--enable-s390-excess-float-precision
!
--disable-s390-excess-float-precision

On s390(x) targets, enable treatment of float expressions with double precision ! when in standards-compliant mode (e.g., when --std=c99 or ! -fexcess-precision=standard are given).

For a native build and cross compiles that have target headers, the option’s default is derived from glibc’s behavior. When glibc clamps float_t to double, --- 1968,1978 ---- target if target binutils supported.

!
--enable-s390-excess-float-precision
!
--disable-s390-excess-float-precision

On s390(x) targets, enable treatment of float expressions with double precision ! when in standards-compliant mode (e.g., when --std=c99 or ! -fexcess-precision=standard are given).

For a native build and cross compiles that have target headers, the option’s default is derived from glibc’s behavior. When glibc clamps float_t to double, *************** GCC follows and enables the option. For *** 1990,2004 **** disabled.

!
--with-zstd=pathname
!
--with-zstd-include=pathname
!
--with-zstd-lib=pathname
!

If you do not have the zstd library installed in a standard location and you want to build GCC, you can explicitly specify the ! directory where it is installed (‘--with-zstd=zstdinstalldir’). ! The --with-zstd=zstdinstalldir option is shorthand for ! --with-zstd-lib=zstdinstalldir/lib and ! --with-zstd-include=zstdinstalldir/include. If this shorthand assumption is not correct, you can use the explicit include and lib options directly.

--- 1980,1994 ---- disabled.

!
--with-zstd=pathname
!
--with-zstd-include=pathname
!
--with-zstd-lib=pathname
!

If you do not have the zstd library installed in a standard location and you want to build GCC, you can explicitly specify the ! directory where it is installed (‘--with-zstd=zstdinstalldir’). ! The --with-zstd=zstdinstalldir option is shorthand for ! --with-zstd-lib=zstdinstalldir/lib and ! --with-zstd-include=zstdinstalldir/include. If this shorthand assumption is not correct, you can use the explicit include and lib options directly.

*************** a cross compiler, they will not be used *** 2007,2308 ****

!

Cross-Compiler-Specific Options

The following options only apply to building cross compilers.

!
!
--with-toolexeclibdir=dir

Specify the installation directory for libraries built with a cross compiler. ! The default is ${gcc_tooldir}/lib.

!
--with-sysroot
!
--with-sysroot=dir
!

Tells GCC to consider dir as the root of a tree that contains (a subset of) the root filesystem of the target operating system. Target system headers, libraries and run-time object files will be searched for in there. More specifically, this acts as if ! --sysroot=dir was added to the default options of the built compiler. The specified directory is not copied into the ! install tree, unlike the options --with-headers and ! --with-libs that this option obsoletes. The default value, ! in case --with-sysroot is not given an argument, is ! ${gcc_tooldir}/sys-root. If the specified directory is a ! subdirectory of ${exec_prefix}, then it will be found relative to the GCC binaries if the installation tree is moved.

This option affects the system root for the compiler used to build target libraries (which runs on the build system) and the compiler newly ! installed with make install; it does not affect the compiler which is used to build GCC itself.

!

If you specify the --with-native-system-header-dir=dirname ! option then the compiler will search that directory within dirname for ! native system headers rather than the default /usr/include.

!
--with-build-sysroot
!
--with-build-sysroot=dir
!

Tells GCC to consider dir as the system root (see ! --with-sysroot) while building target libraries, instead of ! the directory specified with --with-sysroot. This option is ! only useful when you are already using --with-sysroot. You ! can use --with-build-sysroot when you are configuring with ! --prefix set to a directory that is different from the one in which you are installing GCC and your target libraries.

This option affects the system root for the compiler used to build target libraries (which runs on the build system); it does not affect the compiler which is used to build GCC itself.

!

If you specify the --with-native-system-header-dir=dirname ! option then the compiler will search that directory within dirname for ! native system headers rather than the default /usr/include.

!
--with-headers
!
--with-headers=dir
!

Deprecated in favor of --with-sysroot. Specifies that target headers are available when building a cross compiler. ! The dir argument specifies a directory which has the target include ! files. These include files will be copied into the gcc install ! directory. This option with the dir argument is required when ! building a cross compiler, if prefix/target/sys-include ! doesn’t pre-exist. If prefix/target/sys-include does ! pre-exist, the dir argument may be omitted. fixincludes will be run on these files to make them compatible with GCC.

!
--without-headers

Tells GCC not use any target headers from a libc when building a cross compiler. When crossing to GNU/Linux, you need the headers so GCC can build the exception handling for libgcc.

!
--with-libs
!
--with-libs="dir1 dir2 … dirN"
!

Deprecated in favor of --with-sysroot. Specifies a list of directories which contain the target runtime ! libraries. These libraries will be copied into the gcc install directory. If the directory list is omitted, this option has no effect.

!
--with-newlib
!

Specifies that ‘newlib’ is ! being used as the target C library. This causes __eprintf to be ! omitted from libgcc.a on the assumption that it will be provided by ! ‘newlib’.

!
--with-avrlibc
!

Only supported for the AVR target. Specifies that ‘AVR-Libc’ is being used as the target C  library. This causes float support ! functions like __addsf3 to be omitted from libgcc.a on ! the assumption that it will be provided by libm.a. For more ! technical details, cf. PR54461. It is not supported for RTEMS configurations, which currently use newlib. The option is supported since version 4.7.2 and is the default in 4.8.0 and newer.

!
--with-double={32|64|32,64|64,32}
!
--with-long-double={32|64|32,64|64,32|double}

Only supported for the AVR target since version 10. ! Specify the default layout available for the C/C++ ‘double’ ! and ‘long double’ type, respectively. The following rules apply: !

    !
  • The first value after the ‘=’ specifies the default layout (in bits) ! of the type and also the default for the -mdouble= resp. ! -mlong-double= compiler option. !
  • If more than one value is specified, respective multilib variants are ! available, and -mdouble= resp. -mlong-double= acts as a multilib option. !
  • If --with-long-double=double is specified, ‘double’ and ! ‘long double’ will have the same layout. !
  • The defaults are --with-long-double=64,32 and ! --with-double=32,64. The default ‘double’ layout imposed by the latter is compatible with older versions of the compiler that implement ! ‘double’ as a 32-bit type, which does not comply to the language standard.
!

Not all combinations of --with-double= and ! --with-long-double= are valid. For example, the combination ! --with-double=32,64 --with-long-double=32 will be rejected because the first option specifies the availability of ! multilibs for ‘double’, whereas the second option implies ! that ‘long double’ — and hence also ‘double’ — is always 32 bits wide.

!
--with-double-comparison={tristate|bool|libf7}

Only supported for the AVR target since version 10. Specify what result format is returned by library functions that ! compare 64-bit floating point values (DFmode). ! The GCC default is ‘tristate’. If the floating point ! implementation returns a boolean instead, set it to ‘bool’.

!
--with-libf7={libgcc|math|math-symbols|no}

Only supported for the AVR target since version 10. Specify to which degree code from LibF7 is included in libgcc. LibF7 is an ad-hoc, AVR-specific, 64-bit floating point emulation ! written in C and (inline) assembly. ‘libgcc’ adds support for functions that one would usually expect in libgcc like double addition, ! double comparisons and double conversions. ‘math’ also adds routines ! that one would expect in libm.a, but with __ (two underscores) ! prepended to the symbol names as specified by math.h. ! ‘math-symbols’ also defines weak aliases for the functions ! declared in math.h. However, --with-libf7 won’t ! install no math.h header file whatsoever, this file must come ! from elsewhere. This option sets --with-double-comparison ! to ‘bool’.

!
--with-nds32-lib=library
!

Specifies that library setting is used for building libgcc.a. ! Currently, the valid library is ‘newlib’ or ‘mculib’. This option is only supported for the NDS32 target.

!
--with-build-time-tools=dir

Specifies where to find the set of target tools (assembler, linker, etc.) that will be used while building GCC itself. This option can be useful if the directory layouts are different between the system you are building GCC on, and the system where you will deploy it.

!

For example, on an ‘ia64-hp-hpux’ system, you may have the GNU ! assembler and linker in /usr/bin, and the native tools in a different path, and build a toolchain that expects to find the ! native tools in /usr/bin.

!

When you use this option, you should ensure that dir includes ! ar, as, ld, nm, ! ranlib and strip if necessary, and possibly ! objdump. Otherwise, GCC may use an inconsistent set of tools.

!

Overriding configure test results

Sometimes, it might be necessary to override the result of some ! configure test, for example in order to ease porting to a new ! system or work around a bug in a test. The toplevel configure script provides three variables for this:

!
!
! !
!
build_configargs
!

The contents of this variable is passed to all build configure scripts.

-
!
host_configargs
!

The contents of this variable is passed to all host configure scripts.

-
!
target_configargs
!

The contents of this variable is passed to all target configure scripts.

!

In order to avoid shell and make quoting issues for complex ! overrides, you can pass a setting for CONFIG_SITE and set variables in the site file.

!

Objective-C-Specific Options

The following options apply to the build of the Objective-C runtime library.

!
!
--enable-objc-gc

Specify that an additional variant of the GNU Objective-C runtime library is built, using an external build of the Boehm-Demers-Weiser garbage ! collector (https://www.hboehm.info/gc/). This library needs to be available for each multilib variant, unless configured with ! --enable-objc-gc=‘auto’ in which case the build of the additional runtime library is skipped when not available and the build continues.

!
--with-target-bdw-gc=list
!
--with-target-bdw-gc-include=list
!
--with-target-bdw-gc-lib=list

Specify search directories for the garbage collector header files and ! libraries. list is a comma separated list of key value pairs of the ! form ‘multilibdir=path’, where the default multilib key ! is named as ‘.’ (dot), or is omitted (e.g. ! ‘--with-target-bdw-gc=/opt/bdw-gc,32=/opt-bdw-gc32’).

!

The options --with-target-bdw-gc-include and ! --with-target-bdw-gc-lib must always be specified together for each multilib variant and they take precedence over ! --with-target-bdw-gc. If --with-target-bdw-gc-include is missing values for a multilib, then the value for the default ! multilib is used (e.g. ‘--with-target-bdw-gc-include=/opt/bdw-gc/include’ ! ‘--with-target-bdw-gc-lib=/opt/bdw-gc/lib64,32=/opt-bdw-gc/lib32’). If none of these options are specified, the library is assumed in default locations.

!

D-Specific Options

The following options apply to the build of the D runtime library.

!
!
--enable-libphobos-checking
!
--disable-libphobos-checking
!
--enable-libphobos-checking=list

This option controls whether run-time checks and contracts are compiled into the D runtime library. When the option is not specified, the library is built ! with ‘release’ checking. When the option is specified without a ! list, the result is the same as ‘--enable-libphobos-checking=yes’. ! Likewise, ‘--disable-libphobos-checking’ is equivalent to ! ‘--enable-libphobos-checking=no’.

!

The categories of checks available in list are ‘yes’ (compiles ! libphobos with -fno-release), ‘no’ (compiles libphobos with ! -frelease), ‘all’ (same as ‘yes’), ‘none’ or ! ‘release’ (same as ‘no’).

!

Individual checks available in list are ‘assert’ (compiles libphobos ! with an extra option -fassert).

!
--with-libphobos-druntime-only
!
--with-libphobos-druntime-only=choice

Specify whether to build only the core D runtime library (druntime), or both the core and standard library (phobos) into libphobos. This is useful for targets that have full support in druntime, but no or incomplete support ! in phobos. choice can be one of ‘auto’, ‘yes’, and ‘no’ ! where ‘auto’ is the default.

!

When the option is not specified, the default choice ‘auto’ means that it is inferred whether the target has support for the phobos standard library. ! When the option is specified without a choice, the result is the same as ! ‘--with-libphobos-druntime-only=yes’.

!
--with-target-system-zlib
!

Use installed ‘zlib’ rather than that included with GCC. This needs to be available for each multilib variant, unless configured with ! --with-target-system-zlib=‘auto’ in which case the GCC included ! ‘zlib’ is only used when the system installed library is not available.

!

Return to the GCC Installation page

--- 1997,2293 ----

!

Cross-Compiler-Specific Options

The following options only apply to building cross compilers.

!
!
--with-toolexeclibdir=dir

Specify the installation directory for libraries built with a cross compiler. ! The default is ${gcc_tooldir}/lib.

!
--with-sysroot
!
--with-sysroot=dir
!

Tells GCC to consider dir as the root of a tree that contains (a subset of) the root filesystem of the target operating system. Target system headers, libraries and run-time object files will be searched for in there. More specifically, this acts as if ! --sysroot=dir was added to the default options of the built compiler. The specified directory is not copied into the ! install tree, unlike the options --with-headers and ! --with-libs that this option obsoletes. The default value, ! in case --with-sysroot is not given an argument, is ! ${gcc_tooldir}/sys-root. If the specified directory is a ! subdirectory of ${exec_prefix}, then it will be found relative to the GCC binaries if the installation tree is moved.

This option affects the system root for the compiler used to build target libraries (which runs on the build system) and the compiler newly ! installed with make install; it does not affect the compiler which is used to build GCC itself.

!

If you specify the --with-native-system-header-dir=dirname ! option then the compiler will search that directory within dirname for ! native system headers rather than the default /usr/include.

!
--with-build-sysroot
!
--with-build-sysroot=dir
!

Tells GCC to consider dir as the system root (see ! --with-sysroot) while building target libraries, instead of ! the directory specified with --with-sysroot. This option is ! only useful when you are already using --with-sysroot. You ! can use --with-build-sysroot when you are configuring with ! --prefix set to a directory that is different from the one in which you are installing GCC and your target libraries.

This option affects the system root for the compiler used to build target libraries (which runs on the build system); it does not affect the compiler which is used to build GCC itself.

!

If you specify the --with-native-system-header-dir=dirname ! option then the compiler will search that directory within dirname for ! native system headers rather than the default /usr/include.

!
--with-headers
!
--with-headers=dir
!

Deprecated in favor of --with-sysroot. Specifies that target headers are available when building a cross compiler. ! The dir argument specifies a directory which has the target include ! files. These include files will be copied into the gcc install ! directory. This option with the dir argument is required when ! building a cross compiler, if prefix/target/sys-include ! doesn’t pre-exist. If prefix/target/sys-include does ! pre-exist, the dir argument may be omitted. fixincludes will be run on these files to make them compatible with GCC.

!
--without-headers

Tells GCC not use any target headers from a libc when building a cross compiler. When crossing to GNU/Linux, you need the headers so GCC can build the exception handling for libgcc.

!
--with-libs
!
--with-libs="dir1 dir2 … dirN"
!

Deprecated in favor of --with-sysroot. Specifies a list of directories which contain the target runtime ! libraries. These libraries will be copied into the gcc install directory. If the directory list is omitted, this option has no effect.

!
--with-newlib
!

Specifies that ‘newlib’ is ! being used as the target C library. This causes __eprintf to be ! omitted from libgcc.a on the assumption that it will be provided by ! ‘newlib’.

!
--with-avrlibc
!

Only supported for the AVR target. Specifies that ‘AVR-Libc’ is being used as the target C  library. This causes float support ! functions like __addsf3 to be omitted from libgcc.a on ! the assumption that it will be provided by libm.a. For more ! technical details, cf. PR54461. It is not supported for RTEMS configurations, which currently use newlib. The option is supported since version 4.7.2 and is the default in 4.8.0 and newer.

!
--with-double={32|64|32,64|64,32}
!
--with-long-double={32|64|32,64|64,32|double}

Only supported for the AVR target since version 10. ! Specify the default layout available for the C/C++ ‘double’ ! and ‘long double’ type, respectively. The following rules apply: !

    !
  • The first value after the ‘=’ specifies the default layout (in bits) ! of the type and also the default for the -mdouble= resp. ! -mlong-double= compiler option. !
  • If more than one value is specified, respective multilib variants are ! available, and -mdouble= resp. -mlong-double= acts as a multilib option. !
  • If --with-long-double=double is specified, ‘double’ and ! ‘long double’ will have the same layout. !
  • The defaults are --with-long-double=64,32 and ! --with-double=32,64. The default ‘double’ layout imposed by the latter is compatible with older versions of the compiler that implement ! ‘double’ as a 32-bit type, which does not comply to the language standard.
!

Not all combinations of --with-double= and ! --with-long-double= are valid. For example, the combination ! --with-double=32,64 --with-long-double=32 will be rejected because the first option specifies the availability of ! multilibs for ‘double’, whereas the second option implies ! that ‘long double’ — and hence also ‘double’ — is always 32 bits wide.

!
--with-double-comparison={tristate|bool|libf7}

Only supported for the AVR target since version 10. Specify what result format is returned by library functions that ! compare 64-bit floating point values (DFmode). ! The GCC default is ‘tristate’. If the floating point ! implementation returns a boolean instead, set it to ‘bool’.

!
--with-libf7={libgcc|math|math-symbols|no}

Only supported for the AVR target since version 10. Specify to which degree code from LibF7 is included in libgcc. LibF7 is an ad-hoc, AVR-specific, 64-bit floating point emulation ! written in C and (inline) assembly. ‘libgcc’ adds support for functions that one would usually expect in libgcc like double addition, ! double comparisons and double conversions. ‘math’ also adds routines ! that one would expect in libm.a, but with __ (two underscores) ! prepended to the symbol names as specified by math.h. ! ‘math-symbols’ also defines weak aliases for the functions ! declared in math.h. However, --with-libf7 won’t ! install no math.h header file whatsoever, this file must come ! from elsewhere. This option sets --with-double-comparison ! to ‘bool’.

!
--with-nds32-lib=library
!

Specifies that library setting is used for building libgcc.a. ! Currently, the valid library is ‘newlib’ or ‘mculib’. This option is only supported for the NDS32 target.

!
--with-build-time-tools=dir

Specifies where to find the set of target tools (assembler, linker, etc.) that will be used while building GCC itself. This option can be useful if the directory layouts are different between the system you are building GCC on, and the system where you will deploy it.

!

For example, on an ‘ia64-hp-hpux’ system, you may have the GNU ! assembler and linker in /usr/bin, and the native tools in a different path, and build a toolchain that expects to find the ! native tools in /usr/bin.

!

When you use this option, you should ensure that dir includes ! ar, as, ld, nm, ! ranlib and strip if necessary, and possibly ! objdump. Otherwise, GCC may use an inconsistent set of tools.

!

Overriding configure test results

Sometimes, it might be necessary to override the result of some ! configure test, for example in order to ease porting to a new ! system or work around a bug in a test. The toplevel configure script provides three variables for this:

!
!
build_configargs
!

The contents of this variable is passed to all build configure scripts.

!
host_configargs
!

The contents of this variable is passed to all host configure scripts.

!
target_configargs
!

The contents of this variable is passed to all target configure scripts.

!

In order to avoid shell and make quoting issues for complex ! overrides, you can pass a setting for CONFIG_SITE and set variables in the site file.

!

Objective-C-Specific Options

The following options apply to the build of the Objective-C runtime library.

!
!
--enable-objc-gc

Specify that an additional variant of the GNU Objective-C runtime library is built, using an external build of the Boehm-Demers-Weiser garbage ! collector (https://www.hboehm.info/gc/). This library needs to be available for each multilib variant, unless configured with ! --enable-objc-gc=‘auto’ in which case the build of the additional runtime library is skipped when not available and the build continues.

!
--with-target-bdw-gc=list
!
--with-target-bdw-gc-include=list
!
--with-target-bdw-gc-lib=list

Specify search directories for the garbage collector header files and ! libraries. list is a comma separated list of key value pairs of the ! form ‘multilibdir=path’, where the default multilib key ! is named as ‘.’ (dot), or is omitted (e.g. ! ‘--with-target-bdw-gc=/opt/bdw-gc,32=/opt-bdw-gc32’).

!

The options --with-target-bdw-gc-include and ! --with-target-bdw-gc-lib must always be specified together for each multilib variant and they take precedence over ! --with-target-bdw-gc. If --with-target-bdw-gc-include is missing values for a multilib, then the value for the default ! multilib is used (e.g. ‘--with-target-bdw-gc-include=/opt/bdw-gc/include’ ! ‘--with-target-bdw-gc-lib=/opt/bdw-gc/lib64,32=/opt-bdw-gc/lib32’). If none of these options are specified, the library is assumed in default locations.

!

D-Specific Options

The following options apply to the build of the D runtime library.

!
!
--enable-libphobos-checking
!
--disable-libphobos-checking
!
--enable-libphobos-checking=list

This option controls whether run-time checks and contracts are compiled into the D runtime library. When the option is not specified, the library is built ! with ‘release’ checking. When the option is specified without a ! list, the result is the same as ‘--enable-libphobos-checking=yes’. ! Likewise, ‘--disable-libphobos-checking’ is equivalent to ! ‘--enable-libphobos-checking=no’.

!

The categories of checks available in list are ‘yes’ (compiles ! libphobos with -fno-release), ‘no’ (compiles libphobos with ! -frelease), ‘all’ (same as ‘yes’), ‘none’ or ! ‘release’ (same as ‘no’).

!

Individual checks available in list are ‘assert’ (compiles libphobos ! with an extra option -fassert).

!
--with-libphobos-druntime-only
!
--with-libphobos-druntime-only=choice

Specify whether to build only the core D runtime library (druntime), or both the core and standard library (phobos) into libphobos. This is useful for targets that have full support in druntime, but no or incomplete support ! in phobos. choice can be one of ‘auto’, ‘yes’, and ‘no’ ! where ‘auto’ is the default.

!

When the option is not specified, the default choice ‘auto’ means that it is inferred whether the target has support for the phobos standard library. ! When the option is specified without a choice, the result is the same as ! ‘--with-libphobos-druntime-only=yes’.

!
--with-target-system-zlib
!

Use installed ‘zlib’ rather than that included with GCC. This needs to be available for each multilib variant, unless configured with ! --with-target-system-zlib=‘auto’ in which case the GCC included ! ‘zlib’ is only used when the system installed library is not available.

!

Return to the GCC Installation page

diff -Nrcpad gcc-13.4.0/INSTALL/download.html gcc-13.5.0-RC-20260904/INSTALL/download.html *** gcc-13.4.0/INSTALL/download.html Thu Jun 5 16:05:03 2025 --- gcc-13.5.0-RC-20260904/INSTALL/download.html Fri Sep 4 07:35:15 2026 *************** *** 1,9 **** ! ! ! ! - -

Downloading GCC

--- 31,41 ---- *************** ul.no-bullet {list-style: none} *** 77,89 **** ! ! !

GCC is distributed via git and via ! HTTPS as tarballs compressed with gzip or bzip2.

!

Please refer to the releases web page for information on how to obtain GCC.

The source distribution includes the C, C++, Objective-C, Fortran, --- 57,69 ---- ! ! !

GCC is distributed via git and via ! HTTPS as tarballs compressed with gzip or bzip2.

!

Please refer to the releases web page for information on how to obtain GCC.

The source distribution includes the C, C++, Objective-C, Fortran, *************** installation or for use in place of the *** 99,119 **** OS), unpack the binutils distribution either in the same directory or a separate one. In the latter case, add symbolic links to any components of the binutils you intend to build alongside the compiler ! (bfd, binutils, gas, gprof, ld, ! opcodes, …) to the directory containing the GCC sources.

Likewise the GMP, MPFR and MPC libraries can be automatically built together with GCC. You may simply run the ! contrib/download_prerequisites script in the GCC source directory to set up everything. Otherwise unpack the GMP, MPFR and/or MPC source distributions in the directory containing the GCC sources and rename ! their directories to gmp, mpfr and mpc, respectively (or use symbolic links with the same name).

!

Return to the GCC Installation page

--- 79,99 ---- OS), unpack the binutils distribution either in the same directory or a separate one. In the latter case, add symbolic links to any components of the binutils you intend to build alongside the compiler ! (bfd, binutils, gas, gprof, ld, ! opcodes, …) to the directory containing the GCC sources.

Likewise the GMP, MPFR and MPC libraries can be automatically built together with GCC. You may simply run the ! contrib/download_prerequisites script in the GCC source directory to set up everything. Otherwise unpack the GMP, MPFR and/or MPC source distributions in the directory containing the GCC sources and rename ! their directories to gmp, mpfr and mpc, respectively (or use symbolic links with the same name).

!

Return to the GCC Installation page

diff -Nrcpad gcc-13.4.0/INSTALL/finalinstall.html gcc-13.5.0-RC-20260904/INSTALL/finalinstall.html *** gcc-13.4.0/INSTALL/finalinstall.html Thu Jun 5 16:05:04 2025 --- gcc-13.5.0-RC-20260904/INSTALL/finalinstall.html Fri Sep 4 07:35:15 2026 *************** *** 1,9 **** ! ! ! ! --- 33,40 ---- *************** ul.no-bullet {list-style: none} *** 55,61 **** -

Installing GCC: Final installation

--- 42,47 ---- *************** ul.no-bullet {list-style: none} *** 83,90 ****

Now that GCC has been built (and optionally tested), you can install it with !

! 
cd objdir && make install

We strongly recommend to install into a target directory where there is --- 69,76 ----

Now that GCC has been built (and optionally tested), you can install it with !

! 
cd objdir && make install

We strongly recommend to install into a target directory where there is *************** depend on this debugging information (ca *** 94,159 **** instance).

That step completes the installation of GCC; user level binaries can ! be found in prefix/bin where prefix is the value ! you specified with the --prefix to configure (or ! /usr/local by default). (If you specified --bindir, that directory will be used instead; otherwise, if you specified ! --exec-prefix, exec-prefix/bin will be used.) Headers for the C++ library are installed in ! prefix/include; libraries in libdir ! (normally prefix/lib); internal parts of the compiler in ! libdir/gcc and libexecdir/gcc; documentation ! in info format in infodir (normally ! prefix/info).

When installing cross-compilers, GCC’s executables ! are not only installed into bindir, that ! is, exec-prefix/bin, but additionally into ! exec-prefix/target-alias/bin, if that directory ! exists. Typically, such tooldirs hold target-specific binutils, including assembler and linker.

!

Installation into a temporary staging area or into a chroot jail can be achieved with the command

!
! 
make DESTDIR=path-to-rootdir install
!

where path-to-rootdir is the absolute path of a directory relative to which all installation paths will be ! interpreted. Note that the directory specified by DESTDIR need not exist yet; it will be created if necessary.

!

There is a subtle point with tooldirs and DESTDIR: If you relocate a cross-compiler installation with ! e.g. ‘DESTDIR=rootdir’, then the directory ! rootdir/exec-prefix/target-alias/bin will be filled with duplicated GCC executables only if it already exists, it will not be created otherwise. This is regarded as a feature, not as a bug, because it gives slightly more control to the packagers ! using the DESTDIR feature.

You can install stripped programs and libraries with

!
! 
make install-strip

By default, only the man pages and info-format GCC documentation are built and installed. If you want to generate the GCC manuals in other formats, use commands like

!
! 
make dvi
  make pdf
  make html

to build the manuals in the corresponding formats, and

!
! 
make install-dvi
  make install-pdf
  make install-html
--- 80,145 ---- instance).

That step completes the installation of GCC; user level binaries can ! be found in prefix/bin where prefix is the value ! you specified with the --prefix to configure (or ! /usr/local by default). (If you specified --bindir, that directory will be used instead; otherwise, if you specified ! --exec-prefix, exec-prefix/bin will be used.) Headers for the C++ library are installed in ! prefix/include; libraries in libdir ! (normally prefix/lib); internal parts of the compiler in ! libdir/gcc and libexecdir/gcc; documentation ! in info format in infodir (normally ! prefix/info).

When installing cross-compilers, GCC’s executables ! are not only installed into bindir, that ! is, exec-prefix/bin, but additionally into ! exec-prefix/target-alias/bin, if that directory ! exists. Typically, such tooldirs hold target-specific binutils, including assembler and linker.

!

Installation into a temporary staging area or into a chroot jail can be achieved with the command

!
! 
make DESTDIR=path-to-rootdir install
!

where path-to-rootdir is the absolute path of a directory relative to which all installation paths will be ! interpreted. Note that the directory specified by DESTDIR need not exist yet; it will be created if necessary.

!

There is a subtle point with tooldirs and DESTDIR: If you relocate a cross-compiler installation with ! e.g. ‘DESTDIR=rootdir’, then the directory ! rootdir/exec-prefix/target-alias/bin will be filled with duplicated GCC executables only if it already exists, it will not be created otherwise. This is regarded as a feature, not as a bug, because it gives slightly more control to the packagers ! using the DESTDIR feature.

You can install stripped programs and libraries with

!
! 
make install-strip

By default, only the man pages and info-format GCC documentation are built and installed. If you want to generate the GCC manuals in other formats, use commands like

!
! 
make dvi
  make pdf
  make html

to build the manuals in the corresponding formats, and

!
! 
make install-dvi
  make install-pdf
  make install-html
*************** make install-html *** 161,217 ****

to install them. Alternatively, there are prebuilt online versions of the manuals for released versions of GCC on ! the GCC web site.

If you are bootstrapping a released version of GCC then please quickly review the build status page for your release, available from ! https://gcc.gnu.org/buildstat.html. If your system is not listed for the version of GCC that you built, send a note to ! gcc@gcc.gnu.org indicating that you successfully built and installed GCC. Include the following information:

!
    !
  • Output from running srcdir/config.guess. Do not send that file itself, just the one-line output from running it. !
  • The output of ‘gcc -v’ for your newly installed gcc. This tells us which version of GCC you built and the options you passed to configure. !
  • If the build was for GNU/Linux, also include: !
      !
    • The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3); ! this information should be available from /etc/issue. !
    • The version of the Linux kernel, available from ‘uname --version’ ! or ‘uname -a’. !
    • The version of glibc you used; for RPM-based systems like Red Hat, ! Mandrake, and SuSE type ‘rpm -q glibc’ to get the glibc version, ! and on systems like Debian and Progeny use ‘dpkg -l libc6’.

    For other systems, you can include similar information if you think it is relevant.

    !
  • Any other information that you think would be useful to people building GCC on the same configuration. The new entry in the build status list will include a link to the archived copy of your message.

We’d also like to know if the ! host/target specific installation notes didn’t include your host/target information or if that information is incomplete or out of date. Send a note to ! gcc@gcc.gnu.org detailing how the information should be changed.

If you find a bug, please report it following the ! bug reporting guidelines.

!

Return to the GCC Installation page

--- 147,203 ----

to install them. Alternatively, there are prebuilt online versions of the manuals for released versions of GCC on ! the GCC web site.

If you are bootstrapping a released version of GCC then please quickly review the build status page for your release, available from ! https://gcc.gnu.org/buildstat.html. If your system is not listed for the version of GCC that you built, send a note to ! indicating that you successfully built and installed GCC. Include the following information:

!
    !
  • Output from running srcdir/config.guess. Do not send that file itself, just the one-line output from running it. !
  • The output of ‘gcc -v’ for your newly installed gcc. This tells us which version of GCC you built and the options you passed to configure. !
  • If the build was for GNU/Linux, also include: !
      !
    • The distribution name and version (e.g., Red Hat 7.1 or Debian 2.2.3); ! this information should be available from /etc/issue. !
    • The version of the Linux kernel, available from ‘uname --version’ ! or ‘uname -a’. !
    • The version of glibc you used; for RPM-based systems like Red Hat, ! Mandrake, and SuSE type ‘rpm -q glibc’ to get the glibc version, ! and on systems like Debian and Progeny use ‘dpkg -l libc6’.

    For other systems, you can include similar information if you think it is relevant.

    !
  • Any other information that you think would be useful to people building GCC on the same configuration. The new entry in the build status list will include a link to the archived copy of your message.

We’d also like to know if the ! host/target specific installation notes didn’t include your host/target information or if that information is incomplete or out of date. Send a note to ! detailing how the information should be changed.

If you find a bug, please report it following the ! bug reporting guidelines.

!

Return to the GCC Installation page

diff -Nrcpad gcc-13.4.0/INSTALL/gfdl.html gcc-13.5.0-RC-20260904/INSTALL/gfdl.html *** gcc-13.4.0/INSTALL/gfdl.html Thu Jun 5 16:05:04 2025 --- gcc-13.5.0-RC-20260904/INSTALL/gfdl.html Fri Sep 4 07:35:16 2026 *************** *** 1,9 **** ! ! ! ! --- 33,44 ---- *************** ul.no-bullet {list-style: none} *** 55,61 **** -

Installing GCC: GNU Free Documentation License

--- 46,51 ---- *************** ul.no-bullet {list-style: none} *** 86,107 ****

Installing GCC: GNU Free Documentation License

! !
Version 1.3, 3 November 2008
! 
Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
! https://www.fsf.org
  
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
!
  1. 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 --- 76,97 ----

    Installing GCC: GNU Free Documentation License

    ! !
    Version 1.3, 3 November 2008
    ! 
    Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
! https://www.fsf.org
  
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
    !
    1. 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 *************** An image format is not Transparent if us *** 175,190 **** 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, --- 165,180 ---- 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, *************** Version filling the role of the Document *** 273,279 **** and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

      !
      1. 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 --- 263,269 ---- and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

        !
        1. 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 *************** not give you any rights to use it. *** 473,479 **** 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 ! https://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 --- 463,469 ---- 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 ! https://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 *************** provided the MMC is eligible for relicen *** 519,549 ****

        !
        !

        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 --- 509,539 ----

      !
      !

      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 *************** to permit their use in free software. *** 557,566 ****

      !

      Return to the GCC Installation page

      !
      --- 547,556 ----

      !

      Return to the GCC Installation page

      ! diff -Nrcpad gcc-13.4.0/INSTALL/index.html gcc-13.5.0-RC-20260904/INSTALL/index.html *** gcc-13.4.0/INSTALL/index.html Thu Jun 5 16:05:02 2025 --- gcc-13.5.0-RC-20260904/INSTALL/index.html Fri Sep 4 07:35:14 2026 *************** *** 1,9 **** ! ! ! ! - -

      Installing GCC

      --- 31,41 ---- *************** ul.no-bullet {list-style: none} *** 77,83 ****

      The latest version of this document is always available at ! https://gcc.gnu.org/install/. It refers to the current development sources, instructions for specific released versions are included with the sources.

      --- 57,63 ----

      The latest version of this document is always available at ! https://gcc.gnu.org/install/. It refers to the current development sources, instructions for specific released versions are included with the sources.

      *************** as detailing some target specific instal *** 88,114 **** with their own installation instructions. This document supersedes all package-specific installation instructions.

      !

      Before starting the build/install procedure please check the ! host/target specific installation notes. We recommend you browse the entire generic installation instructions before you proceed.

      Lists of successful builds for released versions of GCC are ! available at https://gcc.gnu.org/buildstat.html. These lists are updated as new information becomes available.

      The installation procedure itself is broken into five steps.

      !
        !
      1. Prerequisites !
      2. Downloading the source !
      3. Configuration !
      4. Building !
      5. Testing (optional) !
      6. Final install
      !

      Please note that GCC does not support ‘make uninstall’ and probably won’t do so in the near future as this would open a can of worms. Instead, we suggest that you install GCC into a directory of its own and simply remove that directory when you do not need that specific version of GCC --- 68,94 ---- with their own installation instructions. This document supersedes all package-specific installation instructions.

      !

      Before starting the build/install procedure please check the ! host/target specific installation notes. We recommend you browse the entire generic installation instructions before you proceed.

      Lists of successful builds for released versions of GCC are ! available at https://gcc.gnu.org/buildstat.html. These lists are updated as new information becomes available.

      The installation procedure itself is broken into five steps.

      !
        !
      1. Prerequisites !
      2. Downloading the source !
      3. Configuration !
      4. Building !
      5. Testing (optional) !
      6. Final install
      !

      Please note that GCC does not support ‘make uninstall’ and probably won’t do so in the near future as this would open a can of worms. Instead, we suggest that you install GCC into a directory of its own and simply remove that directory when you do not need that specific version of GCC *************** more binaries exist that use them. *** 117,123 ****

      !

      Return to the GCC Installation page

      Copyright © 1988-2023 Free Software Foundation, Inc.


      --- 97,103 ----

      !

      Return to the GCC Installation page

      Copyright © 1988-2023 Free Software Foundation, Inc.


      *************** under the terms of the GNU Free Document *** 126,132 **** any later version published by the Free Software Foundation; with no Invariant Sections, the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the ! license is included in the section entitled “GNU Free Documentation License”.

      (a) The FSF’s Front-Cover Text is: --- 106,112 ---- any later version published by the Free Software Foundation; with no Invariant Sections, the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the ! license is included in the section entitled “GNU Free Documentation License”.

      (a) The FSF’s Front-Cover Text is: diff -Nrcpad gcc-13.4.0/INSTALL/prerequisites.html gcc-13.5.0-RC-20260904/INSTALL/prerequisites.html *** gcc-13.4.0/INSTALL/prerequisites.html Thu Jun 5 16:05:03 2025 --- gcc-13.5.0-RC-20260904/INSTALL/prerequisites.html Fri Sep 4 07:35:15 2026 *************** *** 1,9 **** ! ! ! ! --- 33,40 ---- *************** ul.no-bullet {list-style: none} *** 55,61 **** -

      Prerequisites for GCC

      --- 42,47 ---- *************** ul.no-bullet {list-style: none} *** 76,90 **** !

      GCC requires that various tools and packages be available for use in the build procedure. Modifying GCC sources requires additional tools described below.

      !

      Tools/packages necessary for building GCC

      !
      !
      ISO C++11 compiler

      Necessary to bootstrap GCC. GCC 4.8.3 or newer has sufficient support for used C++11 features, with earlier GCC versions you might run into implementation bugs. --- 62,76 ---- !

      GCC requires that various tools and packages be available for use in the build procedure. Modifying GCC sources requires additional tools described below.

      !

      Tools/packages necessary for building GCC

      !
      !
      ISO C++11 compiler

      Necessary to bootstrap GCC. GCC 4.8.3 or newer has sufficient support for used C++11 features, with earlier GCC versions you might run into implementation bugs. *************** GCC binary (version 4.8.3 or later) beca *** 100,129 **** frontends other than C might use GCC extensions.

      !
      C standard library and headers

      In order to build GCC, the C standard library and headers must be present for all target variants for which target libraries will be built (and not only the variant of the host C++ compiler).

      !

      This affects the popular ‘x86_64-pc-linux-gnu’ platform (among ! other multilib targets), for which 64-bit (‘x86_64’) and 32-bit ! (‘i386’) libc headers are usually packaged separately. If you do a ! build of a native compiler on ‘x86_64-pc-linux-gnu’, make sure you either have the 32-bit libc developer package properly installed (the exact name of the package depends on your distro) or you must build GCC as a 64-bit only compiler by configuring with the option ! --disable-multilib. Otherwise, you may encounter an error such as ! ‘fatal error: gnu/stubs-32.h: No such file’

      !
      GNAT

      In order to build GNAT, the Ada compiler, you need a working GNAT compiler (GCC version 5.1 or later).

      !

      This includes GNAT tools such as gnatmake and ! gnatlink, since the Ada front end is written in Ada and uses some GNAT-specific extensions.

      In order to build a cross compiler, it is strongly recommended to install --- 86,115 ---- frontends other than C might use GCC extensions.

      !
      C standard library and headers

      In order to build GCC, the C standard library and headers must be present for all target variants for which target libraries will be built (and not only the variant of the host C++ compiler).

      !

      This affects the popular ‘x86_64-pc-linux-gnu’ platform (among ! other multilib targets), for which 64-bit (‘x86_64’) and 32-bit ! (‘i386’) libc headers are usually packaged separately. If you do a ! build of a native compiler on ‘x86_64-pc-linux-gnu’, make sure you either have the 32-bit libc developer package properly installed (the exact name of the package depends on your distro) or you must build GCC as a 64-bit only compiler by configuring with the option ! --disable-multilib. Otherwise, you may encounter an error such as ! ‘fatal error: gnu/stubs-32.h: No such file’

      !
      GNAT

      In order to build GNAT, the Ada compiler, you need a working GNAT compiler (GCC version 5.1 or later).

      !

      This includes GNAT tools such as gnatmake and ! gnatlink, since the Ada front end is written in Ada and uses some GNAT-specific extensions.

      In order to build a cross compiler, it is strongly recommended to install *************** build. *** 136,157 **** GNAT. More recent versions of GNAT than the version built are not guaranteed to work and will often fail during the build with compilation errors.

      !

      Note that configure does not test whether the GNAT installation works and has a sufficiently recent version; if too old a GNAT version is ! installed and --enable-languages=ada is used, the build will fail.

      !

      ADA_INCLUDE_PATH and ADA_OBJECT_PATH environment variables must not be set when building the Ada compiler, the Ada tools, or the Ada runtime libraries. You can check that your build environment is clean ! by verifying that ‘gnatls -v’ lists only one explicit path in each section.

      !
      GDC

      In order to build GDC, the D compiler, you need a working GDC compiler (GCC version 9.4 or later) and D runtime library, ! ‘libphobos’, as the D front end is written in D.

      Versions of GDC prior to 12 can be built with an ISO C++11 compiler, which can then be installed and used to bootstrap newer versions of the D front end. --- 122,143 ---- GNAT. More recent versions of GNAT than the version built are not guaranteed to work and will often fail during the build with compilation errors.

      !

      Note that configure does not test whether the GNAT installation works and has a sufficiently recent version; if too old a GNAT version is ! installed and --enable-languages=ada is used, the build will fail.

      !

      ADA_INCLUDE_PATH and ADA_OBJECT_PATH environment variables must not be set when building the Ada compiler, the Ada tools, or the Ada runtime libraries. You can check that your build environment is clean ! by verifying that ‘gnatls -v’ lists only one explicit path in each section.

      !
      GDC

      In order to build GDC, the D compiler, you need a working GDC compiler (GCC version 9.4 or later) and D runtime library, ! ‘libphobos’, as the D front end is written in D.

      Versions of GDC prior to 12 can be built with an ISO C++11 compiler, which can then be installed and used to bootstrap newer versions of the D front end. *************** recent versions of GDC than the version *** 161,212 **** will often fail during the build with compilation errors relating to deprecations or removed features.

      !

      Note that configure does not test whether the GDC installation works and has a sufficiently recent version. Though the implementation of the D front end does not make use of any GDC-specific extensions, or novel features of the D language, if too old a GDC version is installed and ! --enable-languages=d is used, the build will fail.

      !

      On some targets, ‘libphobos’ isn’t enabled by default, but compiles ! and works if --enable-libphobos is used. Specifics are documented for affected targets.

      !
      GM2

      Python3 is required if you want to build the complete Modula-2 ! documentation including the target SYSTEM definition module. If Python3 is unavailable Modula-2 documentation will include a target independent version of the SYSTEM modules.

      !
      A “working” POSIX compatible shell, or GNU bash
      !

      Necessary when running configure because some ! /bin/sh shells have bugs and may crash when configuring the ! target libraries. In other cases, /bin/sh or ksh have disastrous corner-case performance problems. This ! can cause target configure runs to literally take days to complete in some cases.

      !

      So on some platforms /bin/ksh is sufficient, on others it isn’t. See the host/target specific instructions for your platform, or ! use bash to be sure. Then set CONFIG_SHELL in your environment to your “good” shell prior to running ! configure/make.

      !

      zsh is not a fully compliant POSIX shell and will not work when configuring GCC.

      !
      A POSIX or SVR4 awk

      Necessary for creating some of the generated source files for GCC. If in doubt, use a recent GNU awk version, as some of the older ones are broken. GNU awk version 3.1.5 is known to work.

      !
      GNU binutils

      Necessary in some circumstances, optional in others. See the host/target specific instructions for your platform for the exact --- 147,198 ---- will often fail during the build with compilation errors relating to deprecations or removed features.

      !

      Note that configure does not test whether the GDC installation works and has a sufficiently recent version. Though the implementation of the D front end does not make use of any GDC-specific extensions, or novel features of the D language, if too old a GDC version is installed and ! --enable-languages=d is used, the build will fail.

      !

      On some targets, ‘libphobos’ isn’t enabled by default, but compiles ! and works if --enable-libphobos is used. Specifics are documented for affected targets.

      !
      GM2

      Python3 is required if you want to build the complete Modula-2 ! documentation including the target SYSTEM definition module. If Python3 is unavailable Modula-2 documentation will include a target independent version of the SYSTEM modules.

      !
      A “working” POSIX compatible shell, or GNU bash
      !

      Necessary when running configure because some ! /bin/sh shells have bugs and may crash when configuring the ! target libraries. In other cases, /bin/sh or ksh have disastrous corner-case performance problems. This ! can cause target configure runs to literally take days to complete in some cases.

      !

      So on some platforms /bin/ksh is sufficient, on others it isn’t. See the host/target specific instructions for your platform, or ! use bash to be sure. Then set CONFIG_SHELL in your environment to your “good” shell prior to running ! configure/make.

      !

      zsh is not a fully compliant POSIX shell and will not work when configuring GCC.

      !
      A POSIX or SVR4 awk

      Necessary for creating some of the generated source files for GCC. If in doubt, use a recent GNU awk version, as some of the older ones are broken. GNU awk version 3.1.5 is known to work.

      !
      GNU binutils

      Necessary in some circumstances, optional in others. See the host/target specific instructions for your platform for the exact *************** requirements. *** 216,258 **** with GNU libtool that includes doing a bootstrap with LTO enabled.

      !
      gzip version 1.2.4 (or later) or
      !
      bzip2 version 1.0.2 (or later)
      !

      Necessary to uncompress GCC tar files when source code is obtained via HTTPS mirror sites.

      !
      GNU make version 3.80 (or later)

      You must have GNU make installed to build GCC.

      !
      GNU tar version 1.14 (or later)

      Necessary (only on some platforms) to untar the source code. Many ! systems’ tar programs will also work, only try GNU ! tar if you have problems.

      !
      Perl version between 5.6.1 and 5.6.24
      !

      Necessary when targeting Darwin, building ‘libstdc++’, ! and not using --disable-symvers. ! Necessary when targeting Solaris with Solaris ld and not using ! --disable-symvers.

      !

      Necessary when regenerating Makefile dependencies in libiberty. ! Necessary when regenerating libiberty/functions.texi. Necessary when generating manpages from Texinfo manuals. Used by various scripts to generate some files included in the source repository (mainly Unicode-related and rarely changing) from source tables.

      !

      Used by automake.

      !

      If available, enables parallel testing of ‘libgomp’ in case that ! flock is not available.

      --- 202,244 ---- with GNU libtool that includes doing a bootstrap with LTO enabled.

      !
      gzip version 1.2.4 (or later) or
      !
      bzip2 version 1.0.2 (or later)
      !

      Necessary to uncompress GCC tar files when source code is obtained via HTTPS mirror sites.

      !
      GNU make version 3.80 (or later)

      You must have GNU make installed to build GCC.

      !
      GNU tar version 1.14 (or later)

      Necessary (only on some platforms) to untar the source code. Many ! systems’ tar programs will also work, only try GNU ! tar if you have problems.

      !
      Perl version between 5.6.1 and 5.6.24
      !

      Necessary when targeting Darwin, building ‘libstdc++’, ! and not using --disable-symvers. ! Necessary when targeting Solaris with Solaris ld and not using ! --disable-symvers.

      !

      Necessary when regenerating Makefile dependencies in libiberty. ! Necessary when regenerating libiberty/functions.texi. Necessary when generating manpages from Texinfo manuals. Used by various scripts to generate some files included in the source repository (mainly Unicode-related and rarely changing) from source tables.

      !

      Used by automake.

      !

      If available, enables parallel testing of ‘libgomp’ in case that ! flock is not available.

      *************** newer versions, though. If your OS vend *** 266,383 **** support libraries then using those packages may be the simplest way to install the libraries.

      !
      !
      GNU Multiple Precision Library (GMP) version 4.3.2 (or later)

      Necessary to build GCC. It can be downloaded from ! https://gmplib.org/. If a GMP source distribution is found in a ! subdirectory of your GCC sources named gmp, it will be built together with GCC. Alternatively, if GMP is already installed but it is not in your library search path, you will have to configure with the ! --with-gmp configure option. See also --with-gmp-lib ! and --with-gmp-include. The in-tree build is only supported with the GMP version that download_prerequisites installs.

      !
      MPFR Library version 3.1.0 (or later)

      Necessary to build GCC. It can be downloaded from ! https://www.mpfr.org. If an MPFR source distribution is found ! in a subdirectory of your GCC sources named mpfr, it will be built together with GCC. Alternatively, if MPFR is already installed but it is not in your default library search path, the ! --with-mpfr configure option should be used. See also ! --with-mpfr-lib and --with-mpfr-include. The in-tree build is only supported with the MPFR version that download_prerequisites installs.

      !
      MPC Library version 1.0.1 (or later)

      Necessary to build GCC. It can be downloaded from ! https://www.multiprecision.org/mpc/. If an MPC source distribution ! is found in a subdirectory of your GCC sources named mpc, it will be built together with GCC. Alternatively, if MPC is already installed but it is not in your default library search path, the ! --with-mpc configure option should be used. See also ! --with-mpc-lib and --with-mpc-include. The in-tree build is only supported with the MPC version that download_prerequisites installs.

      !
      isl Library version 0.15 or later.

      Necessary to build GCC with the Graphite loop optimizations. ! It can be downloaded from https://gcc.gnu.org/pub/gcc/infrastructure/. If an isl source distribution is found ! in a subdirectory of your GCC sources named isl, it will be ! built together with GCC. Alternatively, the --with-isl configure option should be used if isl is not installed in your default library search path.

      !
      zstd Library.

      Necessary to build GCC with zstd compression used for LTO bytecode. The library is searched in your default library patch search. ! Alternatively, the --with-zstd configure option should be used.

      !
      Python3 modules

      The complete list of Python3 modules broken down by GCC subcomponent is shown below:

      !
      !
      internal debugging in gdbhooks
      !

      gdb, gdb.printing, gdb.types, ! os.path, re, sys and tempfile,

      !
      g++ testsuite
      !

      gcov, gzip, json, os and pytest.

      !
      c++ cxx api generation
      !

      csv, os, sys and time.

      !
      modula-2 documentation
      !

      argparse, os, pathlib, shutil and ! sys.

      !
      git developer tools
      !

      os and sys.

      !
      ada documentation
      !

      latex_elements, os, pygments, re, ! sys and time.

      !

      Tools/packages necessary for modifying GCC

      !
      !
      autoconf version 2.69
      !
      GNU m4 version 1.4.6 (or later)
      !

      Necessary when modifying configure.ac, aclocal.m4, etc. ! to regenerate configure and config.in files.

      !
      automake version 1.15.1
      !

      Necessary when modifying a Makefile.am file to regenerate its ! associated Makefile.in.

      !

      Much of GCC does not use automake, so directly edit the Makefile.in ! file. Specifically this applies to the gcc, intl, ! libcpp, libiberty, libobjc directories as well as any of their subdirectories.

      For directories that use automake, GCC requires the latest release in --- 252,369 ---- support libraries then using those packages may be the simplest way to install the libraries.

      !
      !
      GNU Multiple Precision Library (GMP) version 4.3.2 (or later)

      Necessary to build GCC. It can be downloaded from ! https://gmplib.org/. If a GMP source distribution is found in a ! subdirectory of your GCC sources named gmp, it will be built together with GCC. Alternatively, if GMP is already installed but it is not in your library search path, you will have to configure with the ! --with-gmp configure option. See also --with-gmp-lib ! and --with-gmp-include. The in-tree build is only supported with the GMP version that download_prerequisites installs.

      !
      MPFR Library version 3.1.0 (or later)

      Necessary to build GCC. It can be downloaded from ! https://www.mpfr.org. If an MPFR source distribution is found ! in a subdirectory of your GCC sources named mpfr, it will be built together with GCC. Alternatively, if MPFR is already installed but it is not in your default library search path, the ! --with-mpfr configure option should be used. See also ! --with-mpfr-lib and --with-mpfr-include. The in-tree build is only supported with the MPFR version that download_prerequisites installs.

      !
      MPC Library version 1.0.1 (or later)

      Necessary to build GCC. It can be downloaded from ! https://www.multiprecision.org/mpc/. If an MPC source distribution ! is found in a subdirectory of your GCC sources named mpc, it will be built together with GCC. Alternatively, if MPC is already installed but it is not in your default library search path, the ! --with-mpc configure option should be used. See also ! --with-mpc-lib and --with-mpc-include. The in-tree build is only supported with the MPC version that download_prerequisites installs.

      !
      isl Library version 0.15 or later.

      Necessary to build GCC with the Graphite loop optimizations. ! It can be downloaded from https://gcc.gnu.org/pub/gcc/infrastructure/. If an isl source distribution is found ! in a subdirectory of your GCC sources named isl, it will be ! built together with GCC. Alternatively, the --with-isl configure option should be used if isl is not installed in your default library search path.

      !
      zstd Library.

      Necessary to build GCC with zstd compression used for LTO bytecode. The library is searched in your default library patch search. ! Alternatively, the --with-zstd configure option should be used.

      !
      Python3 modules

      The complete list of Python3 modules broken down by GCC subcomponent is shown below:

      !
      !
      internal debugging in gdbhooks
      !

      gdb, gdb.printing, gdb.types, ! os.path, re, sys and tempfile,

      !
      g++ testsuite
      !

      gcov, gzip, json, os and pytest.

      !
      c++ cxx api generation
      !

      csv, os, sys and time.

      !
      modula-2 documentation
      !

      argparse, os, pathlib, shutil and ! sys.

      !
      git developer tools
      !

      os and sys.

      !
      ada documentation
      !

      latex_elements, os, pygments, re, ! sys and time.

      !

      Tools/packages necessary for modifying GCC

      !
      !
      autoconf version 2.69
      !
      GNU m4 version 1.4.6 (or later)
      !

      Necessary when modifying configure.ac, aclocal.m4, etc. ! to regenerate configure and config.in files.

      !
      automake version 1.15.1
      !

      Necessary when modifying a Makefile.am file to regenerate its ! associated Makefile.in.

      !

      Much of GCC does not use automake, so directly edit the Makefile.in ! file. Specifically this applies to the gcc, intl, ! libcpp, libiberty, libobjc directories as well as any of their subdirectories.

      For directories that use automake, GCC requires the latest release in *************** to a newer version, please update all th *** 386,440 **** to the latest released version.

      !
      gettext version 0.14.5 (or later)
      !

      Needed to regenerate gcc.pot.

      !
      gperf version 2.7.2 (or later)
      !

      Necessary when modifying gperf input files, e.g. ! gcc/cp/cfns.gperf to regenerate its associated header file, e.g. ! gcc/cp/cfns.h.

      !
      DejaGnu version 1.5.3 (or later)
      !
      Expect
      !
      Tcl

      Necessary to run the GCC testsuite; see the section on testing for details.

      !
      autogen version 5.5.4 (or later) and
      !
      guile version 1.4.1 (or later)
      !

      Necessary to regenerate fixinc/fixincl.x from ! fixinc/inclhack.def and fixinc/*.tpl.

      !

      Necessary to run ‘make check’ for fixinc.

      !

      Necessary to regenerate the top level Makefile.in file from ! Makefile.tpl and Makefile.def.

      !
      Flex version 2.5.4 (or later)
      !

      Necessary when modifying *.l files.

      Necessary to build GCC during development because the generated output files are not included in the version-controlled source repository. They are included in releases.

      !
      Texinfo version 4.7 (or later)
      !

      Necessary for running makeinfo when modifying *.texi files to test your changes.

      !

      Necessary for running make dvi, make pdf, ! or make html to create formatted documentation. Texinfo version ! 4.8 or later is required for make pdf.

      Necessary to build GCC documentation in info format during development because the generated output files are not included in the repository. --- 372,426 ---- to the latest released version.

      !
      gettext version 0.14.5 (or later)
      !

      Needed to regenerate gcc.pot.

      !
      gperf version 2.7.2 (or later)
      !

      Necessary when modifying gperf input files, e.g. ! gcc/cp/cfns.gperf to regenerate its associated header file, e.g. ! gcc/cp/cfns.h.

      !
      DejaGnu version 1.5.3 (or later)
      !
      Expect
      !
      Tcl

      Necessary to run the GCC testsuite; see the section on testing for details.

      !
      autogen version 5.5.4 (or later) and
      !
      guile version 1.4.1 (or later)
      !

      Necessary to regenerate fixinc/fixincl.x from ! fixinc/inclhack.def and fixinc/*.tpl.

      !

      Necessary to run ‘make check’ for fixinc.

      !

      Necessary to regenerate the top level Makefile.in file from ! Makefile.tpl and Makefile.def.

      !
      Flex version 2.5.4 (or later)
      !

      Necessary when modifying *.l files.

      Necessary to build GCC during development because the generated output files are not included in the version-controlled source repository. They are included in releases.

      !
      Texinfo version 4.7 (or later)
      !

      Necessary for running makeinfo when modifying *.texi files to test your changes.

      !

      Necessary for running make dvi, make pdf, ! or make html to create formatted documentation. Texinfo version ! 4.8 or later is required for make pdf.

      Necessary to build GCC documentation in info format during development because the generated output files are not included in the repository. *************** install a newer release to get the best *** 449,482 **** the generated manuals.

      !
      TeX (any working version)
      !

      Necessary for running texi2dvi and texi2pdf, which ! are used when running make dvi or make pdf to create DVI or PDF files, respectively.

      !
      Sphinx version 1.0 (or later)
      !

      Necessary to regenerate jit/docs/_build/texinfo from the .rst ! files in the directories below jit/docs.

      !
      git (any version)
      !
      SSH (any version)

      Necessary to access the source repository. Public releases and weekly snapshots of the development sources are also available via HTTPS.

      !
      GNU diffutils version 2.7 (or later)

      Useful when submitting patches for the GCC source code.

      !
      patch version 2.5.4 (or later)
      !

      Necessary when applying patches, created with diff, to one’s own sources.

      --- 435,468 ---- the generated manuals.

      !
      TeX (any working version)
      !

      Necessary for running texi2dvi and texi2pdf, which ! are used when running make dvi or make pdf to create DVI or PDF files, respectively.

      !
      Sphinx version 1.0 (or later)
      !

      Necessary to regenerate jit/docs/_build/texinfo from the .rst ! files in the directories below jit/docs.

      !
      git (any version)
      !
      SSH (any version)

      Necessary to access the source repository. Public releases and weekly snapshots of the development sources are also available via HTTPS.

      !
      GNU diffutils version 2.7 (or later)

      Useful when submitting patches for the GCC source code.

      !
      patch version 2.5.4 (or later)
      !

      Necessary when applying patches, created with diff, to one’s own sources.

      *************** own sources. *** 484,490 ****

      !

      Return to the GCC Installation page

      --- 470,476 ----

      !

      Return to the GCC Installation page

      diff -Nrcpad gcc-13.4.0/INSTALL/specific.html gcc-13.5.0-RC-20260904/INSTALL/specific.html *** gcc-13.4.0/INSTALL/specific.html Thu Jun 5 16:05:03 2025 --- gcc-13.5.0-RC-20260904/INSTALL/specific.html Fri Sep 4 07:35:15 2026 *************** *** 1,9 **** ! ! ! ! --- 33,42 ---- *************** ul.no-bullet {list-style: none} *** 55,61 **** -

      Host/Target specific installation notes for GCC

      --- 44,49 ---- *************** ul.no-bullet {list-style: none} *** 83,319 **** ! ! ! ! ! !

      Please read this document carefully before installing the GNU Compiler Collection on your machine.

      !

      Note that this list of install notes is not a list of supported hosts or targets. Not all supported hosts and targets are listed here, only the ones that require host-specific or target-specific information have to.

      ! !
      !

      aarch64*-*-*

      !

      Binutils pre 2.24 does not have support for selecting -mabi and does not support ILP32. If it is used to build GCC 4.9 or later, GCC will ! not support option -mabi=ilp32.

      To enable a workaround for the Cortex-A53 erratum number 835769 by default (for all CPUs regardless of -mcpu option given) at configure time use the ! --enable-fix-cortex-a53-835769 option. This will enable the fix by default and can be explicitly disabled during compilation by passing the ! -mno-fix-cortex-a53-835769 option. Conversely, ! --disable-fix-cortex-a53-835769 will disable the workaround by default. The workaround is disabled by default if neither of ! --enable-fix-cortex-a53-835769 or ! --disable-fix-cortex-a53-835769 is given at configure time.

      To enable a workaround for the Cortex-A53 erratum number 843419 by default (for all CPUs regardless of -mcpu option given) at configure time use the ! --enable-fix-cortex-a53-843419 option. This workaround is applied at link time. Enabling the workaround will cause GCC to pass the relevant option to the linker. It can be explicitly disabled during compilation by passing the ! -mno-fix-cortex-a53-843419 option. Conversely, ! --disable-fix-cortex-a53-843419 will disable the workaround by default. The workaround is disabled by default if neither of ! --enable-fix-cortex-a53-843419 or ! --disable-fix-cortex-a53-843419 is given at configure time.

      To enable Branch Target Identification Mechanism and Return Address Signing by ! default at configure time use the --enable-standard-branch-protection ! option. This is equivalent to having -mbranch-protection=standard during compilation. This can be explicitly disabled during compilation by ! passing the -mbranch-protection=none option which turns off all types of branch protections. Conversely, ! --disable-standard-branch-protection will disable both the protections by default. This mechanism is turned off by default if neither of the options are given at configure time.

      !

      alpha*-*-*

      This section contains general configuration information for all Alpha-based platforms using ELF. In addition to reading this section, please read all other sections that match your target.

      !

      amd64-*-solaris2*

      !

      This is a synonym for ‘x86_64-*-solaris2*’.

      !

      amdgcn-*-amdhsa

      AMD GCN GPU target.

      Instead of GNU Binutils, you will need to install LLVM 13.0.1, or later, and copy ! bin/llvm-mc to amdgcn-amdhsa/bin/as, ! bin/lld to amdgcn-amdhsa/bin/ld, ! bin/llvm-nm to amdgcn-amdhsa/bin/nm, and ! bin/llvm-ar to both bin/amdgcn-amdhsa-ar and ! bin/amdgcn-amdhsa-ranlib.

      Use Newlib (4.3.0 or newer).

      To run the binaries, install the HSA Runtime from the ! ROCm Platform, and use ! libexec/gcc/amdhsa-amdhsa/version/gcn-run to launch them on the GPU.

      !

      arc-*-elf32

      !

      Use ‘configure --target=arc-elf32 --with-cpu=cpu --enable-languages="c,c++"’ ! to configure GCC, with cpu being one of ‘arc600’, ‘arc601’, ! or ‘arc700’.

      !

      arc-linux-uclibc

      !

      Use ‘configure --target=arc-linux-uclibc --with-cpu=arc700 --enable-languages="c,c++"’ to configure GCC.

      !

      arm-*-eabi

      ARM-family processors.

      Building the Ada frontend commonly fails (an infinite loop executing ! xsinfo) if the host compiler is GNAT 4.8. Host compilers built from the GNAT 4.6, 4.9 or 5 release branches are known to succeed.

      !

      avr

      ATMEL AVR-family micro controllers. These are used in embedded applications. There are no standard Unix configurations. See “AVR Options” in the main manual for the list of supported MCU types.

      !

      Use ‘configure --target=avr --enable-languages="c"’ to configure GCC.

      Further installation notes and other useful information about AVR tools can also be obtained from:

      !

      The following error: !

      ! 
      Error: register required

      indicates that you should upgrade to a newer version of the binutils.

      !

      Blackfin

      The Blackfin processor, an Analog Devices DSP. See “Blackfin Options” in the main manual

      More information, and a version of binutils with support for this processor, ! are available at https://sourceforge.net/projects/adi-toolchain/.

      !

      CRIS

      CRIS is a CPU architecture in Axis Communications systems-on-a-chip, for example the ETRAX series. These are used in embedded applications.

      See “CRIS Options” in the main manual for a list of CRIS-specific options.

      !

      Use ‘configure --target=cris-elf’ to configure GCC for building a cross-compiler for CRIS.

      !

      DOS

      !

      Please have a look at the binaries page.

      You cannot install GCC by itself on MSDOS; it will not compile under any MSDOS compiler except itself. You need to get the complete --- 71,307 ---- ! ! ! ! ! !

      Please read this document carefully before installing the GNU Compiler Collection on your machine.

      !

      Note that this list of install notes is not a list of supported hosts or targets. Not all supported hosts and targets are listed here, only the ones that require host-specific or target-specific information have to.

      ! !
      !

      aarch64*-*-*

      !

      Binutils pre 2.24 does not have support for selecting -mabi and does not support ILP32. If it is used to build GCC 4.9 or later, GCC will ! not support option -mabi=ilp32.

      To enable a workaround for the Cortex-A53 erratum number 835769 by default (for all CPUs regardless of -mcpu option given) at configure time use the ! --enable-fix-cortex-a53-835769 option. This will enable the fix by default and can be explicitly disabled during compilation by passing the ! -mno-fix-cortex-a53-835769 option. Conversely, ! --disable-fix-cortex-a53-835769 will disable the workaround by default. The workaround is disabled by default if neither of ! --enable-fix-cortex-a53-835769 or ! --disable-fix-cortex-a53-835769 is given at configure time.

      To enable a workaround for the Cortex-A53 erratum number 843419 by default (for all CPUs regardless of -mcpu option given) at configure time use the ! --enable-fix-cortex-a53-843419 option. This workaround is applied at link time. Enabling the workaround will cause GCC to pass the relevant option to the linker. It can be explicitly disabled during compilation by passing the ! -mno-fix-cortex-a53-843419 option. Conversely, ! --disable-fix-cortex-a53-843419 will disable the workaround by default. The workaround is disabled by default if neither of ! --enable-fix-cortex-a53-843419 or ! --disable-fix-cortex-a53-843419 is given at configure time.

      To enable Branch Target Identification Mechanism and Return Address Signing by ! default at configure time use the --enable-standard-branch-protection ! option. This is equivalent to having -mbranch-protection=standard during compilation. This can be explicitly disabled during compilation by ! passing the -mbranch-protection=none option which turns off all types of branch protections. Conversely, ! --disable-standard-branch-protection will disable both the protections by default. This mechanism is turned off by default if neither of the options are given at configure time.

      !

      alpha*-*-*

      This section contains general configuration information for all Alpha-based platforms using ELF. In addition to reading this section, please read all other sections that match your target.

      !

      amd64-*-solaris2*

      !

      This is a synonym for ‘x86_64-*-solaris2*’.

      !

      amdgcn-*-amdhsa

      AMD GCN GPU target.

      Instead of GNU Binutils, you will need to install LLVM 13.0.1, or later, and copy ! bin/llvm-mc to amdgcn-amdhsa/bin/as, ! bin/lld to amdgcn-amdhsa/bin/ld, ! bin/llvm-nm to amdgcn-amdhsa/bin/nm, and ! bin/llvm-ar to both bin/amdgcn-amdhsa-ar and ! bin/amdgcn-amdhsa-ranlib.

      Use Newlib (4.3.0 or newer).

      To run the binaries, install the HSA Runtime from the ! ROCm Platform, and use ! libexec/gcc/amdhsa-amdhsa/version/gcn-run to launch them on the GPU.

      !

      arc-*-elf32

      !

      Use ‘configure --target=arc-elf32 --with-cpu=cpu --enable-languages="c,c++"’ ! to configure GCC, with cpu being one of ‘arc600’, ‘arc601’, ! or ‘arc700’.

      !

      arc-linux-uclibc

      !

      Use ‘configure --target=arc-linux-uclibc --with-cpu=arc700 --enable-languages="c,c++"’ to configure GCC.

      !

      arm-*-eabi

      ARM-family processors.

      Building the Ada frontend commonly fails (an infinite loop executing ! xsinfo) if the host compiler is GNAT 4.8. Host compilers built from the GNAT 4.6, 4.9 or 5 release branches are known to succeed.

      !

      avr

      ATMEL AVR-family micro controllers. These are used in embedded applications. There are no standard Unix configurations. See “AVR Options” in the main manual for the list of supported MCU types.

      !

      Use ‘configure --target=avr --enable-languages="c"’ to configure GCC.

      Further installation notes and other useful information about AVR tools can also be obtained from:

      !

      The following error: !

      ! 
      Error: register required

      indicates that you should upgrade to a newer version of the binutils.

      !

      Blackfin

      The Blackfin processor, an Analog Devices DSP. See “Blackfin Options” in the main manual

      More information, and a version of binutils with support for this processor, ! are available at https://sourceforge.net/projects/adi-toolchain/.

      !

      CRIS

      CRIS is a CPU architecture in Axis Communications systems-on-a-chip, for example the ETRAX series. These are used in embedded applications.

      See “CRIS Options” in the main manual for a list of CRIS-specific options.

      !

      Use ‘configure --target=cris-elf’ to configure GCC for building a cross-compiler for CRIS.

      !

      DOS

      !

      Please have a look at the binaries page.

      You cannot install GCC by itself on MSDOS; it will not compile under any MSDOS compiler except itself. You need to get the complete *************** compilation package DJGPP, which include *** 321,338 **** and includes all the necessary compilation tools and libraries.

      !

      epiphany-*-elf

      Adapteva Epiphany. This configuration is intended for embedded systems.

      !

      *-*-freebsd*

      In order to better utilize FreeBSD base system functionality and match the configuration of the system compiler, GCC 4.5 and above as well as GCC 4.4 past 2010-06-20 leverage SSP support in libc (which is present ! on FreeBSD 7 or later) and the use of __cxa_atexit by default ! (on FreeBSD 6 or later). The use of dl_iterate_phdr inside ! libgcc_s.so.1 and boehm-gc (on FreeBSD 7 or later) is enabled by GCC 4.5 and above.

      We support FreeBSD using the ELF file format with DWARF 2 debugging --- 309,326 ---- and includes all the necessary compilation tools and libraries.

      !

      epiphany-*-elf

      Adapteva Epiphany. This configuration is intended for embedded systems.

      !

      *-*-freebsd*

      In order to better utilize FreeBSD base system functionality and match the configuration of the system compiler, GCC 4.5 and above as well as GCC 4.4 past 2010-06-20 leverage SSP support in libc (which is present ! on FreeBSD 7 or later) and the use of __cxa_atexit by default ! (on FreeBSD 6 or later). The use of dl_iterate_phdr inside ! libgcc_s.so.1 and boehm-gc (on FreeBSD 7 or later) is enabled by GCC 4.5 and above.

      We support FreeBSD using the ELF file format with DWARF 2 debugging *************** for all CPU architectures. There are *** 340,370 **** no known issues with mixing object files and libraries with different debugging formats. Otherwise, this release of GCC should now match more of the configuration used in the stock FreeBSD configuration of ! GCC. In particular, --enable-threads is now configured by default. However, as a general user, do not attempt to replace the system compiler with this release. Known to bootstrap and check with good results on FreeBSD 7.2-STABLE. In the past, known to bootstrap and check with good results on FreeBSD 3.0, 3.4, 4.0, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9 and 5-CURRENT.

      !

      The version of binutils installed in /usr/bin probably works with this release of GCC. Bootstrapping against the latest GNU ! binutils and/or the version found in /usr/ports/devel/binutils has been known to enable additional features and improve overall testsuite results. However, it is currently known that boehm-gc may not configure properly on FreeBSD prior to the FreeBSD 7.0 release with GNU binutils after 2.16.1.

      !

      ft32-*-elf

      The FT32 processor. This configuration is intended for embedded systems.

      !

      h8300-hms

      Renesas H8/300 series of processors.

      !

      Please have a look at the binaries page.

      The calling convention and structure layout has changed in release 2.6. All code must be recompiled. The calling convention now passes the --- 328,358 ---- no known issues with mixing object files and libraries with different debugging formats. Otherwise, this release of GCC should now match more of the configuration used in the stock FreeBSD configuration of ! GCC. In particular, --enable-threads is now configured by default. However, as a general user, do not attempt to replace the system compiler with this release. Known to bootstrap and check with good results on FreeBSD 7.2-STABLE. In the past, known to bootstrap and check with good results on FreeBSD 3.0, 3.4, 4.0, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9 and 5-CURRENT.

      !

      The version of binutils installed in /usr/bin probably works with this release of GCC. Bootstrapping against the latest GNU ! binutils and/or the version found in /usr/ports/devel/binutils has been known to enable additional features and improve overall testsuite results. However, it is currently known that boehm-gc may not configure properly on FreeBSD prior to the FreeBSD 7.0 release with GNU binutils after 2.16.1.

      !

      ft32-*-elf

      The FT32 processor. This configuration is intended for embedded systems.

      !

      h8300-hms

      Renesas H8/300 series of processors.

      !

      Please have a look at the binaries page.

      The calling convention and structure layout has changed in release 2.6. All code must be recompiled. The calling convention now passes the *************** first three arguments in function calls *** 372,396 **** longer a multiple of 2 bytes.

      !

      hppa*-hp-hpux*

      Support for HP-UX version 9 and older was discontinued in GCC 3.4.

      We require using gas/binutils on all hppa platforms. Version 2.19 or later is recommended.

      It may be helpful to configure GCC with the ! --with-gnu-as and ! --with-as=… options to ensure that GCC can find GAS.

      The HP assembler should not be used with GCC. It is rarely tested and may not work. It shouldn’t be used with any languages other than C due to its many limitations.

      !

      Specifically, -g does not work (HP-UX uses a peculiar debugging format which GCC does not know about). It also inserts timestamps into each object file it creates, causing the 3-stage comparison test to fail during a bootstrap. You should be able to continue by saying ! ‘make all-host all-target’ after getting the failure from ‘make’.

      Various GCC features are not supported. For example, it does not support weak symbols or alias definitions. As a result, explicit template instantiations --- 360,384 ---- longer a multiple of 2 bytes.

      !

      hppa*-hp-hpux*

      Support for HP-UX version 9 and older was discontinued in GCC 3.4.

      We require using gas/binutils on all hppa platforms. Version 2.19 or later is recommended.

      It may be helpful to configure GCC with the ! --with-gnu-as and ! --with-as=… options to ensure that GCC can find GAS.

      The HP assembler should not be used with GCC. It is rarely tested and may not work. It shouldn’t be used with any languages other than C due to its many limitations.

      !

      Specifically, -g does not work (HP-UX uses a peculiar debugging format which GCC does not know about). It also inserts timestamps into each object file it creates, causing the 3-stage comparison test to fail during a bootstrap. You should be able to continue by saying ! ‘make all-host all-target’ after getting the failure from ‘make’.

      Various GCC features are not supported. For example, it does not support weak symbols or alias definitions. As a result, explicit template instantiations *************** build many C++ applications. *** 401,407 **** PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc architecture specified for the target machine when configuring. PROCESSOR_8000 is the default. PROCESSOR_7100LC is selected when ! the target is a ‘hppa1*’ machine.

      The PROCESSOR_8000 model is not well suited to older processors. Thus, it is important to completely specify the machine architecture when --- 389,395 ---- PROCESSOR_7100LC and PROCESSOR_8000. They are selected from the pa-risc architecture specified for the target machine when configuring. PROCESSOR_8000 is the default. PROCESSOR_7100LC is selected when ! the target is a ‘hppa1*’ machine.

      The PROCESSOR_8000 model is not well suited to older processors. Thus, it is important to completely specify the machine architecture when *************** through 11.00, and the UNIX 98 namespace *** 414,430 **** This namespace change might cause problems when bootstrapping with an earlier version of GCC or the HP compiler as essentially the same namespace is required for an entire build. This problem can be avoided ! in a number of ways. With HP cc, UNIX_STD can be set to ‘95’ ! or ‘98’. Another way is to add an appropriate set of predefines ! to CC. The description for the munix= option contains a list of the predefines used with each standard.

      !

      More specific information to ‘hppa*-hp-hpux*’ targets follows.

      !

      hppa*-hp-hpux10

      !

      For hpux10.20, we highly recommend you pick up the latest sed patch ! PHCO_19798 from HP.

      The C++ ABI has changed incompatibly in GCC 4.0. COMDAT subspaces are used for one-only code and data. This resolves many of the previous --- 402,418 ---- This namespace change might cause problems when bootstrapping with an earlier version of GCC or the HP compiler as essentially the same namespace is required for an entire build. This problem can be avoided ! in a number of ways. With HP cc, UNIX_STD can be set to ‘95’ ! or ‘98’. Another way is to add an appropriate set of predefines ! to CC. The description for the munix= option contains a list of the predefines used with each standard.

      !

      More specific information to ‘hppa*-hp-hpux*’ targets follows.

      !

      hppa*-hp-hpux10

      !

      For hpux10.20, we highly recommend you pick up the latest sed patch ! PHCO_19798 from HP.

      The C++ ABI has changed incompatibly in GCC 4.0. COMDAT subspaces are used for one-only code and data. This resolves many of the previous *************** problems in using C++ on this target. H *** 432,444 **** with the one implemented under HP-UX 11 using secondary definitions.

      !

      hppa*-hp-hpux11

      GCC 3.0 and up support HP-UX 11. GCC 2.95.x is not supported and cannot be used to compile GCC 3.0 and up.

      The libffi library haven’t been ported to 64-bit HP-UX and doesn’t build.

      !

      Refer to binaries for information about obtaining precompiled GCC binaries for HP-UX. Precompiled binaries must be obtained to build the Ada language as it cannot be bootstrapped using C. Ada is only available for the 32-bit PA-RISC runtime. --- 420,432 ---- with the one implemented under HP-UX 11 using secondary definitions.

      !

      hppa*-hp-hpux11

      GCC 3.0 and up support HP-UX 11. GCC 2.95.x is not supported and cannot be used to compile GCC 3.0 and up.

      The libffi library haven’t been ported to 64-bit HP-UX and doesn’t build.

      !

      Refer to binaries for information about obtaining precompiled GCC binaries for HP-UX. Precompiled binaries must be obtained to build the Ada language as it cannot be bootstrapped using C. Ada is only available for the 32-bit PA-RISC runtime. *************** is best not to start from a binary distr *** 460,490 ****

      On 64-bit capable systems, there are two distinct targets. Different installation prefixes must be used if both are to be installed on ! the same system. The ‘hppa[1-2]*-hp-hpux11*’ target generates code for the 32-bit PA-RISC runtime architecture and uses the HP linker. ! The ‘hppa64-hp-hpux11*’ target generates 64-bit code for the PA-RISC 2.0 architecture.

      The script config.guess now selects the target type based on the compiler ! detected during configuration. You must define PATH or CC so that configure finds an appropriate compiler for the initial bootstrap. ! When CC is used, the definition should contain the options that are ! needed whenever CC is used.

      Specifically, options that determine the runtime architecture must be ! in CC to correctly select the target for the build. It is also ! convenient to place many other compiler options in CC. For example, ! CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE" can be used to bootstrap the GCC 3.3 branch with the HP compiler in ! 64-bit K&R/bundled mode. The +DA2.0W option will result in ! the automatic selection of the ‘hppa64-hp-hpux11*’ target. The macro definition table of cpp needs to be increased for a successful build with the HP compiler. _CLASSIC_TYPES and _HPUX_SOURCE need to be defined when building with the bundled compiler, or when using the ! -Ac option. These defines aren’t necessary with -Ae.

      !

      It is best to explicitly configure the ‘hppa64-hp-hpux11*’ target ! with the --with-ld=… option. This overrides the standard search for ld. The two linkers supported on this target require different commands. The default linker is determined during configuration. As a result, it’s not possible to switch linkers in the middle of a GCC build. --- 448,478 ----

      On 64-bit capable systems, there are two distinct targets. Different installation prefixes must be used if both are to be installed on ! the same system. The ‘hppa[1-2]*-hp-hpux11*’ target generates code for the 32-bit PA-RISC runtime architecture and uses the HP linker. ! The ‘hppa64-hp-hpux11*’ target generates 64-bit code for the PA-RISC 2.0 architecture.

      The script config.guess now selects the target type based on the compiler ! detected during configuration. You must define PATH or CC so that configure finds an appropriate compiler for the initial bootstrap. ! When CC is used, the definition should contain the options that are ! needed whenever CC is used.

      Specifically, options that determine the runtime architecture must be ! in CC to correctly select the target for the build. It is also ! convenient to place many other compiler options in CC. For example, ! CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE" can be used to bootstrap the GCC 3.3 branch with the HP compiler in ! 64-bit K&R/bundled mode. The +DA2.0W option will result in ! the automatic selection of the ‘hppa64-hp-hpux11*’ target. The macro definition table of cpp needs to be increased for a successful build with the HP compiler. _CLASSIC_TYPES and _HPUX_SOURCE need to be defined when building with the bundled compiler, or when using the ! -Ac option. These defines aren’t necessary with -Ae.

      !

      It is best to explicitly configure the ‘hppa64-hp-hpux11*’ target ! with the --with-ld=… option. This overrides the standard search for ld. The two linkers supported on this target require different commands. The default linker is determined during configuration. As a result, it’s not possible to switch linkers in the middle of a GCC build. *************** This has been reported to sometimes occu *** 492,501 **** and GCC.

      A recent linker patch must be installed for the correct operation of ! GCC 3.3 and later. PHSS_26559 and PHSS_24304 are the oldest linker patches that are known to work. They are for HP-UX ! 11.00 and 11.11, respectively. PHSS_24303, the companion to ! PHSS_24304, might be usable but it hasn’t been tested. These patches have been superseded. Consult the HP patch database to obtain the currently recommended linker patch for your system.

      --- 480,489 ---- and GCC.

      A recent linker patch must be installed for the correct operation of ! GCC 3.3 and later. PHSS_26559 and PHSS_24304 are the oldest linker patches that are known to work. They are for HP-UX ! 11.00 and 11.11, respectively. PHSS_24303, the companion to ! PHSS_24304, might be usable but it hasn’t been tested. These patches have been superseded. Consult the HP patch database to obtain the currently recommended linker patch for your system.

      *************** linking issues involving secondary symbo *** 509,542 ****

      GCC 3.3 uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capabilities to run initializers and finalizers on the 64-bit port. The 32-bit port ! uses the linker +init and +fini options for the same purpose. The patches correct various problems with the +init/+fini options, including program core dumps. Binutils 2.14 corrects a problem on the 64-bit port resulting from HP’s non-standard use of the .init and .fini sections for array initializers and finalizers.

      Although the HP and GNU linkers are both supported for the ! ‘hppa64-hp-hpux11*’ target, it is strongly recommended that the HP linker be used for link editing on this target.

      At this time, the GNU linker does not support the creation of long branch stubs. As a result, it cannot successfully link binaries containing branch offsets larger than 8 megabytes. In addition, there are problems linking shared libraries, linking executables ! with -static, and with dwarf2 unwind and exception support. It also doesn’t provide stubs for internal calls to global functions in shared libraries, so these calls cannot be overloaded.

      The HP dynamic loader does not support GNU symbol versioning, so symbol versioning is not supported. It may be necessary to disable symbol ! versioning with --disable-symvers when using GNU ld.

      POSIX threads are the default. The optional DCE thread library is not ! supported, so --enable-threads=dce does not work.

      !

      *-*-linux-gnu

      !

      The .init_array and .fini_array sections are enabled unconditionally which requires at least glibc 2.1 and binutils 2.12.

      Versions of libstdc++-v3 starting with 3.2.1 require bug fixes present --- 497,530 ----

      GCC 3.3 uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capabilities to run initializers and finalizers on the 64-bit port. The 32-bit port ! uses the linker +init and +fini options for the same purpose. The patches correct various problems with the +init/+fini options, including program core dumps. Binutils 2.14 corrects a problem on the 64-bit port resulting from HP’s non-standard use of the .init and .fini sections for array initializers and finalizers.

      Although the HP and GNU linkers are both supported for the ! ‘hppa64-hp-hpux11*’ target, it is strongly recommended that the HP linker be used for link editing on this target.

      At this time, the GNU linker does not support the creation of long branch stubs. As a result, it cannot successfully link binaries containing branch offsets larger than 8 megabytes. In addition, there are problems linking shared libraries, linking executables ! with -static, and with dwarf2 unwind and exception support. It also doesn’t provide stubs for internal calls to global functions in shared libraries, so these calls cannot be overloaded.

      The HP dynamic loader does not support GNU symbol versioning, so symbol versioning is not supported. It may be necessary to disable symbol ! versioning with --disable-symvers when using GNU ld.

      POSIX threads are the default. The optional DCE thread library is not ! supported, so --enable-threads=dce does not work.

      !

      *-*-linux-gnu

      !

      The .init_array and .fini_array sections are enabled unconditionally which requires at least glibc 2.1 and binutils 2.12.

      Versions of libstdc++-v3 starting with 3.2.1 require bug fixes present *************** in glibc 2.2.5 and later. More informat *** 544,594 **** libstdc++-v3 documentation.

      !

      i?86-*-linux*

      As of GCC 3.3, binutils 2.13.1 or later is required for this platform. ! See bug 10877 for more information.

      If you receive Signal 11 errors when building on GNU/Linux, then it is possible you have a hardware problem. Further information on this can be ! found on www.bitwizard.nl.

      !

      i?86-*-solaris2*

      Use this for Solaris 11.3 or later on x86 and x86-64 systems. Starting ! with GCC 4.7, there is also a 64-bit ‘amd64-*-solaris2*’ or ! ‘x86_64-*-solaris2*’ configuration that corresponds to ! ‘sparcv9-sun-solaris2*’.

      !

      ia64-*-linux

      IA-64 processor (also known as IPF, or Itanium Processor Family) running GNU/Linux.

      If you are using the installed system libunwind library with ! --with-system-libunwind, then you must use libunwind 0.98 or later.

      !

      ia64-*-hpux*

      Building GCC on this target requires the GNU Assembler. The bundled HP assembler will not work. To prevent GCC from using the wrong assembler, ! the option --with-gnu-as may be necessary.

      The GCC libunwind library has not been ported to HPUX. This means that for ! GCC versions 3.2.3 and earlier, --enable-libunwind-exceptions is required to build GCC. For GCC 3.3 and later, this is the default. ! For gcc 3.4.3 and later, --enable-libunwind-exceptions is removed and the system libunwind library will always be used.

      !

      *-ibm-aix*

      Support for AIX version 3 and older was discontinued in GCC 3.4. Support for AIX version 4.2 and older was discontinued in GCC 4.5.

      “out of memory” bootstrap failures may indicate a problem with process resource limits (ulimit). Hard limits are configured in the ! /etc/security/limits system configuration file.

      GCC 4.9 and above require a C++ compiler for bootstrap. IBM VAC++ / xlC cannot bootstrap GCC. xlc can bootstrap an older version of GCC and --- 532,582 ---- libstdc++-v3 documentation.

      !

      i?86-*-linux*

      As of GCC 3.3, binutils 2.13.1 or later is required for this platform. ! See bug 10877 for more information.

      If you receive Signal 11 errors when building on GNU/Linux, then it is possible you have a hardware problem. Further information on this can be ! found on www.bitwizard.nl.

      !

      i?86-*-solaris2*

      Use this for Solaris 11.3 or later on x86 and x86-64 systems. Starting ! with GCC 4.7, there is also a 64-bit ‘amd64-*-solaris2*’ or ! ‘x86_64-*-solaris2*’ configuration that corresponds to ! ‘sparcv9-sun-solaris2*’.

      !

      ia64-*-linux

      IA-64 processor (also known as IPF, or Itanium Processor Family) running GNU/Linux.

      If you are using the installed system libunwind library with ! --with-system-libunwind, then you must use libunwind 0.98 or later.

      !

      ia64-*-hpux*

      Building GCC on this target requires the GNU Assembler. The bundled HP assembler will not work. To prevent GCC from using the wrong assembler, ! the option --with-gnu-as may be necessary.

      The GCC libunwind library has not been ported to HPUX. This means that for ! GCC versions 3.2.3 and earlier, --enable-libunwind-exceptions is required to build GCC. For GCC 3.3 and later, this is the default. ! For gcc 3.4.3 and later, --enable-libunwind-exceptions is removed and the system libunwind library will always be used.

      !

      *-ibm-aix*

      Support for AIX version 3 and older was discontinued in GCC 3.4. Support for AIX version 4.2 and older was discontinued in GCC 4.5.

      “out of memory” bootstrap failures may indicate a problem with process resource limits (ulimit). Hard limits are configured in the ! /etc/security/limits system configuration file.

      GCC 4.9 and above require a C++ compiler for bootstrap. IBM VAC++ / xlC cannot bootstrap GCC. xlc can bootstrap an older version of GCC and *************** G++ can bootstrap recent releases of GCC *** 597,606 ****

      GCC can bootstrap with recent versions of IBM XLC, but bootstrapping with an earlier release of GCC is recommended. Bootstrapping with XLC requires a larger data segment, which can be enabled through the ! LDR_CNTRL environment variable, e.g.,

      !
      ! 
      % LDR_CNTRL=MAXDATA=0x50000000
  % export LDR_CNTRL
      --- 585,594 ----

      GCC can bootstrap with recent versions of IBM XLC, but bootstrapping with an earlier release of GCC is recommended. Bootstrapping with XLC requires a larger data segment, which can be enabled through the ! LDR_CNTRL environment variable, e.g.,

      !
      ! 
      % LDR_CNTRL=MAXDATA=0x50000000
  % export LDR_CNTRL
      *************** sources. One may delete GCC’s &ld *** 609,642 **** with a version of GCC built for an earlier release of AIX.

      To speed up the configuration phases of bootstrapping and installing GCC, ! one may use GNU Bash instead of AIX /bin/sh, e.g.,

      !
      ! 
      % CONFIG_SHELL=/opt/freeware/bin/bash
  % export CONFIG_SHELL
      !

      and then proceed as described in the build instructions, where we strongly recommend specifying an absolute path ! to invoke srcdir/configure.

      Because GCC on AIX is built as a 32-bit executable by default, (although it can generate 64-bit programs) the GMP and MPFR libraries required by gfortran must be 32-bit libraries. Building GMP and MPFR as static archive libraries works better than shared libraries.

      !

      Errors involving alloca when building GCC generally are due ! to an incorrect definition of CC in the Makefile or mixing files compiled with the native C compiler and GCC. During the stage1 phase of ! the build, the native AIX compiler must be invoked as cc ! (not xlc). Once configure has been informed of ! xlc, one needs to use ‘make distclean’ to remove the ! configure cache files and ensure that CC environment variable ! does not provide a definition that will confuse configure. If this error occurs during stage2 or later, then the problem most likely is the version of Make (see above).

      !

      The native as and ld are recommended for bootstrapping on AIX. The GNU Assembler, GNU Linker, and GNU Binutils version 2.20 is the minimum level that supports bootstrap on AIX 5. The GNU Assembler has not been updated to support AIX 6 or --- 597,630 ---- with a version of GCC built for an earlier release of AIX.

      To speed up the configuration phases of bootstrapping and installing GCC, ! one may use GNU Bash instead of AIX /bin/sh, e.g.,

      !
      ! 
      % CONFIG_SHELL=/opt/freeware/bin/bash
  % export CONFIG_SHELL
      !

      and then proceed as described in the build instructions, where we strongly recommend specifying an absolute path ! to invoke srcdir/configure.

      Because GCC on AIX is built as a 32-bit executable by default, (although it can generate 64-bit programs) the GMP and MPFR libraries required by gfortran must be 32-bit libraries. Building GMP and MPFR as static archive libraries works better than shared libraries.

      !

      Errors involving alloca when building GCC generally are due ! to an incorrect definition of CC in the Makefile or mixing files compiled with the native C compiler and GCC. During the stage1 phase of ! the build, the native AIX compiler must be invoked as cc ! (not xlc). Once configure has been informed of ! xlc, one needs to use ‘make distclean’ to remove the ! configure cache files and ensure that CC environment variable ! does not provide a definition that will confuse configure. If this error occurs during stage2 or later, then the problem most likely is the version of Make (see above).

      !

      The native as and ld are recommended for bootstrapping on AIX. The GNU Assembler, GNU Linker, and GNU Binutils version 2.20 is the minimum level that supports bootstrap on AIX 5. The GNU Assembler has not been updated to support AIX 6 or *************** IZ98477 for AIX 5.3 TL11 and IZ98134 for *** 657,699 **** AIX 5.3 TL12 SP5, AIX 6.1 TL04 SP11, AIX 6.1 TL05 SP7, AIX 6.1 TL06 SP6, AIX 6.1 TL07 and AIX 7.1 TL01 should include the fix.

      !

      Building libstdc++.a requires a fix for an AIX Assembler bug APAR IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1). It also requires a fix for another AIX Assembler bug and a co-dependent AIX Archiver fix referenced as APAR IY53606 (AIX 5.2) or as APAR IY54774 (AIX 5.1)

      !

      ‘libstdc++’ in GCC 3.4 increments the major version number of the ! shared object and GCC installation places the libstdc++.a shared library in a common location which will overwrite the and GCC 3.3 version of the shared library. Applications either need to be re-linked against the new shared library or the GCC 3.1 and GCC 3.3 ! versions of the ‘libstdc++’ shared object needs to be available ! to the AIX runtime loader. The GCC 3.1 ‘libstdc++.so.4’, if ! present, and GCC 3.3 ‘libstdc++.so.5’ shared objects can be installed for runtime dynamic loading using the following steps to set ! the ‘F_LOADONLY’ flag in the shared object for each ! multilib libstdc++.a installed:

      Extract the shared objects from the currently installed ! libstdc++.a archive: !

      ! 
      % ar -x libstdc++.a libstdc++.so.4 libstdc++.so.5
      !

      Enable the ‘F_LOADONLY’ flag so that the shared object will be available for runtime dynamic loading, but not linking: !

      ! 
      % strip -e libstdc++.so.4 libstdc++.so.5

      Archive the runtime-only shared object in the GCC 3.4 ! libstdc++.a archive: !

      ! 
      % ar -q libstdc++.a libstdc++.so.4 libstdc++.so.5

      Eventually, the ! --with-aix-soname=svr4 configure option may drop the need for this procedure for libraries that support it.

      --- 645,687 ---- AIX 5.3 TL12 SP5, AIX 6.1 TL04 SP11, AIX 6.1 TL05 SP7, AIX 6.1 TL06 SP6, AIX 6.1 TL07 and AIX 7.1 TL01 should include the fix.

      !

      Building libstdc++.a requires a fix for an AIX Assembler bug APAR IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1). It also requires a fix for another AIX Assembler bug and a co-dependent AIX Archiver fix referenced as APAR IY53606 (AIX 5.2) or as APAR IY54774 (AIX 5.1)

      !

      ‘libstdc++’ in GCC 3.4 increments the major version number of the ! shared object and GCC installation places the libstdc++.a shared library in a common location which will overwrite the and GCC 3.3 version of the shared library. Applications either need to be re-linked against the new shared library or the GCC 3.1 and GCC 3.3 ! versions of the ‘libstdc++’ shared object needs to be available ! to the AIX runtime loader. The GCC 3.1 ‘libstdc++.so.4’, if ! present, and GCC 3.3 ‘libstdc++.so.5’ shared objects can be installed for runtime dynamic loading using the following steps to set ! the ‘F_LOADONLY’ flag in the shared object for each ! multilib libstdc++.a installed:

      Extract the shared objects from the currently installed ! libstdc++.a archive: !

      ! 
      % ar -x libstdc++.a libstdc++.so.4 libstdc++.so.5
      !

      Enable the ‘F_LOADONLY’ flag so that the shared object will be available for runtime dynamic loading, but not linking: !

      ! 
      % strip -e libstdc++.so.4 libstdc++.so.5

      Archive the runtime-only shared object in the GCC 3.4 ! libstdc++.a archive: !

      ! 
      % ar -q libstdc++.a libstdc++.so.4 libstdc++.so.5

      Eventually, the ! --with-aix-soname=svr4 configure option may drop the need for this procedure for libraries that support it.

      *************** executable. *** 709,845 **** to parse archive libraries did not handle the new format correctly. These routines are used by GCC and result in error messages during linking such as “not a COFF file”. The version of the routines shipped ! with AIX 4.3.1 should work for a 32-bit environment. The -g option of the archive command may be used to create archives of 32-bit objects using the original “small format”. A correct version of the routines is shipped with AIX 4.3.2 and above.

      Some versions of the AIX binder (linker) can fail with a relocation ! overflow severe error when the -bbigtoc option is used to link GCC-produced object files into an executable that overflows the TOC. A fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is available from IBM Customer Support and from its ! techsupport.services.ibm.com website as PTF U455193.

      The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core with a segmentation fault when invoked by any version of GCC. A fix for APAR IX87327 is available from IBM Customer Support and from its ! techsupport.services.ibm.com website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above.

      The initial assembler shipped with AIX 4.3.0 generates incorrect object files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS TO ASSEMBLE/BIND) is available from IBM Customer Support and from its ! techsupport.services.ibm.com website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above.

      AIX provides National Language Support (NLS). Compilers and assemblers use NLS to support locale-specific representations of various data ! formats including floating-point numbers (e.g., ‘.’ vs ‘,’ for separating decimal fractions). There have been problems reported where GCC does not produce the same floating-point formats that the assembler ! expects. If one encounters this problem, set the LANG ! environment variable to ‘C’ or ‘En_US’.

      !

      A default can be specified with the -mcpu=cpu_type ! switch and using the configure option --with-cpu-cpu_type.

      !

      iq2000-*-elf

      Vitesse IQ2000 processors. These are used in embedded applications. There are no standard Unix configurations.

      !

      lm32-*-elf

      Lattice Mico32 processor. This configuration is intended for embedded systems.

      !

      lm32-*-uclinux

      Lattice Mico32 processor. This configuration is intended for embedded systems running uClinux.

      !

      LoongArch

      LoongArch processor. The following LoongArch targets are available: !

      !
      loongarch64-linux-gnu*

      LoongArch processor running GNU/Linux. This target triplet may be coupled with a small set of possible suffixes to identify their default ABI type: !

      !
      f64
      !

      Uses lp64d/base ABI by default.

      !
      f32
      !

      Uses lp64f/base ABI by default.

      !
      sf
      !

      Uses lp64s/base ABI by default.

      !
      loongarch64-linux-gnu
      !

      Same as loongarch64-linux-gnuf64, but may be used with ! --with-abi=* to configure the default ABI type.

      More information about LoongArch can be found at ! https://github.com/loongson/LoongArch-Documentation.

      !

      m32c-*-elf

      Renesas M32C processor. This configuration is intended for embedded systems.

      !

      m32r-*-elf

      Renesas M32R processor. This configuration is intended for embedded systems.

      !

      m68k-*-*

      By default, ! ‘m68k-*-elf*’, ‘m68k-*-rtems’, ‘m68k-*-uclinux’ and ! ‘m68k-*-linux’ build libraries for both M680x0 and ColdFire processors. If you only need the M680x0 libraries, you can omit the ColdFire ones by passing ! --with-arch=m68k to configure. Alternatively, you ! can omit the M680x0 libraries by passing --with-arch=cf to ! configure. These targets default to 5206 or 5475 code as appropriate for the target system when ! configured with --with-arch=cf and 68020 code otherwise.

      !

      The ‘m68k-*-netbsd’ and ! ‘m68k-*-openbsd’ targets also support the --with-arch option. They will generate ColdFire CFV4e code when configured with ! --with-arch=cf and 68020 code otherwise.

      You can override the default processors listed above by configuring ! with --with-cpu=target. This target can either ! be a -mcpu argument or one of the following values: ! ‘m68000’, ‘m68010’, ‘m68020’, ‘m68030’, ! ‘m68040’, ‘m68060’, ‘m68020-40’ and ‘m68020-60’.

      GCC requires at least binutils version 2.17 on these targets.

      !

      m68k-*-uclinux

      GCC 4.3 changed the uClinux configuration so that it uses the ! ‘m68k-linux-gnu’ ABI rather than the ‘m68k-elf’ ABI. It also added improved support for C++ and flat shared libraries, both of which were ABI changes.

      !

      microblaze-*-elf

      Xilinx MicroBlaze processor. This configuration is intended for embedded systems.

      !

      mips-*-*

      If on a MIPS system you get an error message saying “does not have gp sections for all it’s [sic] sectons [sic]”, don’t worry about it. This happens whenever you use GAS with the MIPS linker, but there is not --- 697,833 ---- to parse archive libraries did not handle the new format correctly. These routines are used by GCC and result in error messages during linking such as “not a COFF file”. The version of the routines shipped ! with AIX 4.3.1 should work for a 32-bit environment. The -g option of the archive command may be used to create archives of 32-bit objects using the original “small format”. A correct version of the routines is shipped with AIX 4.3.2 and above.

      Some versions of the AIX binder (linker) can fail with a relocation ! overflow severe error when the -bbigtoc option is used to link GCC-produced object files into an executable that overflows the TOC. A fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC) is available from IBM Customer Support and from its ! techsupport.services.ibm.com website as PTF U455193.

      The AIX 4.3.2.1 linker (bos.rte.bind_cmds Level 4.3.2.1) will dump core with a segmentation fault when invoked by any version of GCC. A fix for APAR IX87327 is available from IBM Customer Support and from its ! techsupport.services.ibm.com website as PTF U461879. This fix is incorporated in AIX 4.3.3 and above.

      The initial assembler shipped with AIX 4.3.0 generates incorrect object files. A fix for APAR IX74254 (64BIT DISASSEMBLED OUTPUT FROM COMPILER FAILS TO ASSEMBLE/BIND) is available from IBM Customer Support and from its ! techsupport.services.ibm.com website as PTF U453956. This fix is incorporated in AIX 4.3.1 and above.

      AIX provides National Language Support (NLS). Compilers and assemblers use NLS to support locale-specific representations of various data ! formats including floating-point numbers (e.g., ‘.’ vs ‘,’ for separating decimal fractions). There have been problems reported where GCC does not produce the same floating-point formats that the assembler ! expects. If one encounters this problem, set the LANG ! environment variable to ‘C’ or ‘En_US’.

      !

      A default can be specified with the -mcpu=cpu_type ! switch and using the configure option --with-cpu-cpu_type.

      !

      iq2000-*-elf

      Vitesse IQ2000 processors. These are used in embedded applications. There are no standard Unix configurations.

      !

      lm32-*-elf

      Lattice Mico32 processor. This configuration is intended for embedded systems.

      !

      lm32-*-uclinux

      Lattice Mico32 processor. This configuration is intended for embedded systems running uClinux.

      !

      LoongArch

      LoongArch processor. The following LoongArch targets are available: !

      !
      loongarch64-linux-gnu*

      LoongArch processor running GNU/Linux. This target triplet may be coupled with a small set of possible suffixes to identify their default ABI type: !

      !
      f64
      !

      Uses lp64d/base ABI by default.

      !
      f32
      !

      Uses lp64f/base ABI by default.

      !
      sf
      !

      Uses lp64s/base ABI by default.

      !
      loongarch64-linux-gnu
      !

      Same as loongarch64-linux-gnuf64, but may be used with ! --with-abi=* to configure the default ABI type.

      More information about LoongArch can be found at ! https://github.com/loongson/LoongArch-Documentation.

      !

      m32c-*-elf

      Renesas M32C processor. This configuration is intended for embedded systems.

      !

      m32r-*-elf

      Renesas M32R processor. This configuration is intended for embedded systems.

      !

      m68k-*-*

      By default, ! ‘m68k-*-elf*’, ‘m68k-*-rtems’, ‘m68k-*-uclinux’ and ! ‘m68k-*-linux’ build libraries for both M680x0 and ColdFire processors. If you only need the M680x0 libraries, you can omit the ColdFire ones by passing ! --with-arch=m68k to configure. Alternatively, you ! can omit the M680x0 libraries by passing --with-arch=cf to ! configure. These targets default to 5206 or 5475 code as appropriate for the target system when ! configured with --with-arch=cf and 68020 code otherwise.

      !

      The ‘m68k-*-netbsd’ and ! ‘m68k-*-openbsd’ targets also support the --with-arch option. They will generate ColdFire CFV4e code when configured with ! --with-arch=cf and 68020 code otherwise.

      You can override the default processors listed above by configuring ! with --with-cpu=target. This target can either ! be a -mcpu argument or one of the following values: ! ‘m68000’, ‘m68010’, ‘m68020’, ‘m68030’, ! ‘m68040’, ‘m68060’, ‘m68020-40’ and ‘m68020-60’.

      GCC requires at least binutils version 2.17 on these targets.

      !

      m68k-*-uclinux

      GCC 4.3 changed the uClinux configuration so that it uses the ! ‘m68k-linux-gnu’ ABI rather than the ‘m68k-elf’ ABI. It also added improved support for C++ and flat shared libraries, both of which were ABI changes.

      !

      microblaze-*-elf

      Xilinx MicroBlaze processor. This configuration is intended for embedded systems.

      !

      mips-*-*

      If on a MIPS system you get an error message saying “does not have gp sections for all it’s [sic] sectons [sic]”, don’t worry about it. This happens whenever you use GAS with the MIPS linker, but there is not *************** optional, and there should not be a warn *** 851,1117 ****

      The libstdc++ atomic locking routines for MIPS targets requires MIPS II and later. A patch went in just after the GCC 3.3 release to ! make ‘mips*-*-*’ use the generic implementation instead. You can also ! configure for ‘mipsel-elf’ as a workaround. The ! ‘mips*-*-linux*’ target continues to use the MIPS II routines. More work on this is expected in future releases.

      !

      The built-in __sync_* functions are available on MIPS II and ! later systems and others that support the ‘ll’, ‘sc’ and ! ‘sync’ instructions. This can be overridden by passing ! --with-llsc or --without-llsc when configuring GCC. Since the Linux kernel emulates these instructions if they are ! missing, the default for ‘mips*-*-linux*’ targets is ! --with-llsc. The --with-llsc and ! --without-llsc configure options may be overridden at compile ! time by passing the -mllsc or -mno-llsc options to the compiler.

      MIPS systems check for division by zero (unless ! -mno-check-zero-division is passed to the compiler) by generating either a conditional trap or a break instruction. Using trap results in smaller code, but is only supported on MIPS II and later. Also, some versions of the Linux kernel have a bug that ! prevents trap from generating the proper signal (SIGFPE). To enable ! the use of break, use the --with-divide=breaks ! configure option when configuring GCC. The default is to use traps on systems that support them.

      !

      moxie-*-elf

      The moxie processor.

      !

      msp430-*-elf*

      TI MSP430 processor. This configuration is intended for embedded systems.

      !

      ‘msp430-*-elf’ is the standard configuration with most GCC features enabled by default.

      !

      ‘msp430-*-elfbare’ is tuned for a bare-metal environment, and disables features related to shared libraries and other functionality not used for this device. This reduces code and data usage of the GCC libraries, resulting in a minimal run-time environment by default.

      Features disabled by default include: !

        !
      • transactional memory !
      • __cxa_atexit
      !

      nds32le-*-elf

      Andes NDS32 target in little endian mode.

      !

      nds32be-*-elf

      Andes NDS32 target in big endian mode.

      !

      nvptx-*-none

      Nvidia PTX target.

      Instead of GNU binutils, you will need to install ! nvptx-tools. Tell GCC where to find it: ! --with-build-time-tools=[install-nvptx-tools]/nvptx-none/bin.

      You will need newlib 4.3.0 or later. It can be automatically built together with GCC. For this, add a symbolic link ! to nvptx-newlib’s newlib directory to the directory containing the GCC sources.

      !

      Use the --disable-sjlj-exceptions and ! --enable-newlib-io-long-long options when configuring.

      !

      The --with-arch option may be specified to override the ! default value for the -march option, and to also build corresponding target libraries. ! The default is --with-arch=sm_30.

      !

      For example, if --with-arch=sm_70 is specified, ! -march=sm_30 and -march=sm_70 target libraries are ! built, and code generation defaults to -march=sm_70.

      !

      or1k-*-elf

      The OpenRISC 1000 32-bit processor with delay slots. This configuration is intended for embedded systems.

      !

      or1k-*-linux

      The OpenRISC 1000 32-bit processor with delay slots.

      !

      powerpc-*-*

      !

      You can specify a default version for the -mcpu=cpu_type ! switch by using the configure option --with-cpu-cpu_type.

      You will need GNU binutils 2.20 or newer.

      !

      powerpc-*-darwin*

      PowerPC running Darwin (Mac OS X kernel).

      Pre-installed versions of Mac OS X may not include any developer tools, meaning that you will not be able to build GCC from source. Tool binaries are available at ! https://opensource.apple.com.

      This version of GCC requires at least cctools-590.36. The cctools-590.36 package referenced from ! https://gcc.gnu.org/ml/gcc/2006-03/msg00507.html will not work on systems older than 10.3.9 (aka darwin7.9.0).

      !

      powerpc-*-elf

      PowerPC system in big endian mode, running System V.4.

      !

      powerpc*-*-linux-gnu*

      PowerPC system in big endian mode running Linux.

      !

      powerpc-*-netbsd*

      PowerPC system in big endian mode running NetBSD.

      !

      powerpc-*-eabisim

      Embedded PowerPC system in big endian mode for use in running under the PSIM simulator.

      !

      powerpc-*-eabi

      Embedded PowerPC system in big endian mode.

      !

      powerpcle-*-elf

      PowerPC system in little endian mode, running System V.4.

      !

      powerpcle-*-eabisim

      Embedded PowerPC system in little endian mode for use in running under the PSIM simulator.

      !

      powerpcle-*-eabi

      Embedded PowerPC system in little endian mode.

      !

      rl78-*-elf

      The Renesas RL78 processor. This configuration is intended for embedded systems.

      !

      riscv32-*-elf

      The RISC-V RV32 instruction set. This configuration is intended for embedded systems. This (and all other RISC-V) targets require the binutils 2.30 release.

      !

      riscv32-*-linux

      The RISC-V RV32 instruction set running GNU/Linux. This (and all other RISC-V) targets require the binutils 2.30 release.

      !

      riscv64-*-elf

      The RISC-V RV64 instruction set. This configuration is intended for embedded systems. This (and all other RISC-V) targets require the binutils 2.30 release.

      !

      riscv64-*-linux

      The RISC-V RV64 instruction set running GNU/Linux. This (and all other RISC-V) targets require the binutils 2.30 release.

      !

      rx-*-elf

      The Renesas RX processor.

      !

      s390-*-linux*

      S/390 system running GNU/Linux for S/390.

      !

      s390x-*-linux*

      zSeries system (64-bit) running GNU/Linux for zSeries.

      !

      s390x-ibm-tpf*

      zSeries system (64-bit) running TPF. This platform is supported as cross-compilation target only.

      !

      *-*-solaris2*

      Support for Solaris 11.3 and earlier has been obsoleted in GCC 13, but ! can still be enabled by configuring with --enable-obsolete. Support for Solaris 10 has been removed in GCC 10. Support for Solaris 9 has been removed in GCC 5. Support for Solaris 8 has been removed in GCC 4.8. Support for Solaris 7 has been removed in GCC 4.6.

      Solaris 11.3 provides GCC 4.5.2, 4.7.3, and 4.8.2 as ! /usr/gcc/4.5/bin/gcc or similar. Solaris 11.4 provides one or more of GCC 5, 7, 9, 10, 11, and 12.

      !

      You need to install the system/header, system/linker, and ! developer/assembler packages.

      !

      Trying to use the compatibility tools in /usr/ucb, from the ! compatibility/ucb package, to install GCC has been observed to ! cause trouble. The fix is to remove /usr/ucb from your ! PATH.

      The build process works more smoothly with the legacy Solaris tools so, ! if you have /usr/xpg4/bin in your PATH, we recommend that ! you place /usr/bin before /usr/xpg4/bin for the duration of the build.

      We recommend the use of the Solaris assembler or the GNU assembler, in conjunction with the Solaris linker.

      !

      The GNU as versions included in Solaris 11.3, from GNU ! binutils 2.23.1 or newer (in /usr/bin/gas and ! /usr/gnu/bin/as), are known to work. The version from GNU binutils 2.40 is known to work as well. Recent versions of the Solaris ! assembler in /usr/bin/as work almost as well, though. To use GNU ! as, configure with the options --with-gnu-as --with-as=/usr/gnu/bin/as.

      For linking, the Solaris linker is preferred. If you want to use the GNU linker instead, the version in Solaris 11.3, from GNU binutils ! 2.23.1 or newer (in /usr/gnu/bin/ld and /usr/bin/gld), works, as does the version from GNU binutils 2.40. However, it generally lacks platform specific features, so better stay with Solaris ! ld. To use the LTO linker plugin ! (-fuse-linker-plugin) with GNU ld, GNU binutils ! must be configured with --enable-largefile. To use ! Solaris ld, we recommend to configure with ! --without-gnu-ld --with-ld=/usr/bin/ld to guarantee the ! right linker is found irrespective of the user’s PATH.

      Note that your mileage may vary if you use a combination of the GNU ! tools and the Solaris tools: while the combination GNU as and ! Solaris ld works well, the reverse combination Solaris ! as with GNU ld may fail to build or cause memory corruption at runtime in some cases for C++ programs.

      !

      To enable symbol versioning in ‘libstdc++’ and other runtime libraries with the Solaris linker, you need to have any version of GNU ! c++filt, which is part of GNU binutils. Symbol versioning will be disabled if no appropriate version is found. Solaris ! c++filt from the Solaris Studio compilers does not work.

      In order to build the GNU Ada compiler, GNAT, a working GNAT is needed. Since Solaris 11.4 SRU 39, GNAT 11 or 12 is bundled in the ! developer/gcc/gcc-gnat package.

      !

      In order to build the GNU D compiler, GDC, a working ‘libphobos’ is needed. That library wasn’t built by default in GCC 9–11 on SPARC, or on x86 when the Solaris assembler is used, but can be enabled by ! configuring with --enable-libphobos. Also, GDC 9.4.0 is required on x86, while GDC 9.3.0 is known to work on SPARC.

      The versions of the GNU Multiple Precision Library (GMP), the MPFR --- 839,1105 ----

      The libstdc++ atomic locking routines for MIPS targets requires MIPS II and later. A patch went in just after the GCC 3.3 release to ! make ‘mips*-*-*’ use the generic implementation instead. You can also ! configure for ‘mipsel-elf’ as a workaround. The ! ‘mips*-*-linux*’ target continues to use the MIPS II routines. More work on this is expected in future releases.

      !

      The built-in __sync_* functions are available on MIPS II and ! later systems and others that support the ‘ll’, ‘sc’ and ! ‘sync’ instructions. This can be overridden by passing ! --with-llsc or --without-llsc when configuring GCC. Since the Linux kernel emulates these instructions if they are ! missing, the default for ‘mips*-*-linux*’ targets is ! --with-llsc. The --with-llsc and ! --without-llsc configure options may be overridden at compile ! time by passing the -mllsc or -mno-llsc options to the compiler.

      MIPS systems check for division by zero (unless ! -mno-check-zero-division is passed to the compiler) by generating either a conditional trap or a break instruction. Using trap results in smaller code, but is only supported on MIPS II and later. Also, some versions of the Linux kernel have a bug that ! prevents trap from generating the proper signal (SIGFPE). To enable ! the use of break, use the --with-divide=breaks ! configure option when configuring GCC. The default is to use traps on systems that support them.

      !

      moxie-*-elf

      The moxie processor.

      !

      msp430-*-elf*

      TI MSP430 processor. This configuration is intended for embedded systems.

      !

      ‘msp430-*-elf’ is the standard configuration with most GCC features enabled by default.

      !

      ‘msp430-*-elfbare’ is tuned for a bare-metal environment, and disables features related to shared libraries and other functionality not used for this device. This reduces code and data usage of the GCC libraries, resulting in a minimal run-time environment by default.

      Features disabled by default include: !

        !
      • transactional memory !
      • __cxa_atexit
      !

      nds32le-*-elf

      Andes NDS32 target in little endian mode.

      !

      nds32be-*-elf

      Andes NDS32 target in big endian mode.

      !

      nvptx-*-none

      Nvidia PTX target.

      Instead of GNU binutils, you will need to install ! nvptx-tools. Tell GCC where to find it: ! --with-build-time-tools=[install-nvptx-tools]/nvptx-none/bin.

      You will need newlib 4.3.0 or later. It can be automatically built together with GCC. For this, add a symbolic link ! to nvptx-newlib’s newlib directory to the directory containing the GCC sources.

      !

      Use the --disable-sjlj-exceptions and ! --enable-newlib-io-long-long options when configuring.

      !

      The --with-arch option may be specified to override the ! default value for the -march option, and to also build corresponding target libraries. ! The default is --with-arch=sm_30.

      !

      For example, if --with-arch=sm_70 is specified, ! -march=sm_30 and -march=sm_70 target libraries are ! built, and code generation defaults to -march=sm_70.

      !

      or1k-*-elf

      The OpenRISC 1000 32-bit processor with delay slots. This configuration is intended for embedded systems.

      !

      or1k-*-linux

      The OpenRISC 1000 32-bit processor with delay slots.

      !

      powerpc-*-*

      !

      You can specify a default version for the -mcpu=cpu_type ! switch by using the configure option --with-cpu-cpu_type.

      You will need GNU binutils 2.20 or newer.

      !

      powerpc-*-darwin*

      PowerPC running Darwin (Mac OS X kernel).

      Pre-installed versions of Mac OS X may not include any developer tools, meaning that you will not be able to build GCC from source. Tool binaries are available at ! https://opensource.apple.com.

      This version of GCC requires at least cctools-590.36. The cctools-590.36 package referenced from ! https://gcc.gnu.org/ml/gcc/2006-03/msg00507.html will not work on systems older than 10.3.9 (aka darwin7.9.0).

      !

      powerpc-*-elf

      PowerPC system in big endian mode, running System V.4.

      !

      powerpc*-*-linux-gnu*

      PowerPC system in big endian mode running Linux.

      !

      powerpc-*-netbsd*

      PowerPC system in big endian mode running NetBSD.

      !

      powerpc-*-eabisim

      Embedded PowerPC system in big endian mode for use in running under the PSIM simulator.

      !

      powerpc-*-eabi

      Embedded PowerPC system in big endian mode.

      !

      powerpcle-*-elf

      PowerPC system in little endian mode, running System V.4.

      !

      powerpcle-*-eabisim

      Embedded PowerPC system in little endian mode for use in running under the PSIM simulator.

      !

      powerpcle-*-eabi

      Embedded PowerPC system in little endian mode.

      !

      rl78-*-elf

      The Renesas RL78 processor. This configuration is intended for embedded systems.

      !

      riscv32-*-elf

      The RISC-V RV32 instruction set. This configuration is intended for embedded systems. This (and all other RISC-V) targets require the binutils 2.30 release.

      !

      riscv32-*-linux

      The RISC-V RV32 instruction set running GNU/Linux. This (and all other RISC-V) targets require the binutils 2.30 release.

      !

      riscv64-*-elf

      The RISC-V RV64 instruction set. This configuration is intended for embedded systems. This (and all other RISC-V) targets require the binutils 2.30 release.

      !

      riscv64-*-linux

      The RISC-V RV64 instruction set running GNU/Linux. This (and all other RISC-V) targets require the binutils 2.30 release.

      !

      rx-*-elf

      The Renesas RX processor.

      !

      s390-*-linux*

      S/390 system running GNU/Linux for S/390.

      !

      s390x-*-linux*

      zSeries system (64-bit) running GNU/Linux for zSeries.

      !

      s390x-ibm-tpf*

      zSeries system (64-bit) running TPF. This platform is supported as cross-compilation target only.

      !

      *-*-solaris2*

      Support for Solaris 11.3 and earlier has been obsoleted in GCC 13, but ! can still be enabled by configuring with --enable-obsolete. Support for Solaris 10 has been removed in GCC 10. Support for Solaris 9 has been removed in GCC 5. Support for Solaris 8 has been removed in GCC 4.8. Support for Solaris 7 has been removed in GCC 4.6.

      Solaris 11.3 provides GCC 4.5.2, 4.7.3, and 4.8.2 as ! /usr/gcc/4.5/bin/gcc or similar. Solaris 11.4 provides one or more of GCC 5, 7, 9, 10, 11, and 12.

      !

      You need to install the system/header, system/linker, and ! developer/assembler packages.

      !

      Trying to use the compatibility tools in /usr/ucb, from the ! compatibility/ucb package, to install GCC has been observed to ! cause trouble. The fix is to remove /usr/ucb from your ! PATH.

      The build process works more smoothly with the legacy Solaris tools so, ! if you have /usr/xpg4/bin in your PATH, we recommend that ! you place /usr/bin before /usr/xpg4/bin for the duration of the build.

      We recommend the use of the Solaris assembler or the GNU assembler, in conjunction with the Solaris linker.

      !

      The GNU as versions included in Solaris 11.3, from GNU ! binutils 2.23.1 or newer (in /usr/bin/gas and ! /usr/gnu/bin/as), are known to work. The version from GNU binutils 2.40 is known to work as well. Recent versions of the Solaris ! assembler in /usr/bin/as work almost as well, though. To use GNU ! as, configure with the options --with-gnu-as --with-as=/usr/gnu/bin/as.

      For linking, the Solaris linker is preferred. If you want to use the GNU linker instead, the version in Solaris 11.3, from GNU binutils ! 2.23.1 or newer (in /usr/gnu/bin/ld and /usr/bin/gld), works, as does the version from GNU binutils 2.40. However, it generally lacks platform specific features, so better stay with Solaris ! ld. To use the LTO linker plugin ! (-fuse-linker-plugin) with GNU ld, GNU binutils ! must be configured with --enable-largefile. To use ! Solaris ld, we recommend to configure with ! --without-gnu-ld --with-ld=/usr/bin/ld to guarantee the ! right linker is found irrespective of the user’s PATH.

      Note that your mileage may vary if you use a combination of the GNU ! tools and the Solaris tools: while the combination GNU as and ! Solaris ld works well, the reverse combination Solaris ! as with GNU ld may fail to build or cause memory corruption at runtime in some cases for C++ programs.

      !

      To enable symbol versioning in ‘libstdc++’ and other runtime libraries with the Solaris linker, you need to have any version of GNU ! c++filt, which is part of GNU binutils. Symbol versioning will be disabled if no appropriate version is found. Solaris ! c++filt from the Solaris Studio compilers does not work.

      In order to build the GNU Ada compiler, GNAT, a working GNAT is needed. Since Solaris 11.4 SRU 39, GNAT 11 or 12 is bundled in the ! developer/gcc/gcc-gnat package.

      !

      In order to build the GNU D compiler, GDC, a working ‘libphobos’ is needed. That library wasn’t built by default in GCC 9–11 on SPARC, or on x86 when the Solaris assembler is used, but can be enabled by ! configuring with --enable-libphobos. Also, GDC 9.4.0 is required on x86, while GDC 9.3.0 is known to work on SPARC.

      The versions of the GNU Multiple Precision Library (GMP), the MPFR *************** library and the MPC library bundled with *** 1119,1135 **** usually recent enough to match GCC’s requirements. There are two caveats:

      !
        !
      • While the version of the GMP library in Solaris 11.3 works with GCC, you ! need to configure with --with-gmp-include=/usr/include/gmp. !
      • The version of the MPFR libary included in Solaris 11.3 is too old; you need to provide a more recent one.
      !

      sparc*-*-*

      This section contains general configuration information for all SPARC-based platforms. In addition to reading this section, please read all other sections that match your target. --- 1107,1123 ---- usually recent enough to match GCC’s requirements. There are two caveats:

      !
        !
      • While the version of the GMP library in Solaris 11.3 works with GCC, you ! need to configure with --with-gmp-include=/usr/include/gmp. !
      • The version of the MPFR libary included in Solaris 11.3 is too old; you need to provide a more recent one.
      !

      sparc*-*-*

      This section contains general configuration information for all SPARC-based platforms. In addition to reading this section, please read all other sections that match your target. *************** read all other sections that match your *** 1138,1147 **** library and the MPC library are known to be miscompiled by earlier versions of GCC on these platforms. We therefore recommend the use of the exact versions of these libraries listed as minimal versions ! in the prerequisites.

      !

      sparc-sun-solaris2*

      When GCC is configured to use GNU binutils 2.14 or later, the binaries produced are smaller than the ones produced using Solaris native tools; this difference is quite significant for binaries containing debugging --- 1126,1135 ---- library and the MPC library are known to be miscompiled by earlier versions of GCC on these platforms. We therefore recommend the use of the exact versions of these libraries listed as minimal versions ! in the prerequisites.

      !

      sparc-sun-solaris2*

      When GCC is configured to use GNU binutils 2.14 or later, the binaries produced are smaller than the ones produced using Solaris native tools; this difference is quite significant for binaries containing debugging *************** information. *** 1149,1204 ****

      Starting with Solaris 7, the operating system is capable of executing 64-bit SPARC V9 binaries. GCC 3.1 and later properly supports ! this; the -m64 option enables 64-bit code generation.

      When configuring the GNU Multiple Precision Library (GMP), the MPFR library or the MPC library on Solaris, the canonical target triplet must ! be specified as the build parameter on the configure line. This target triplet can be obtained by invoking ! ./config.guess in the toplevel source directory of GCC (and not that of GMP or MPFR or MPC). For example:

      !
      ! 
      % srcdir/configure --build=sparc-sun-solaris2.11 --prefix=dirname
      !

      sparc-*-linux*

      !

      sparc64-*-solaris2*

      !

      This is a synonym for ‘sparcv9-*-solaris2*’.

      !

      sparcv9-*-solaris2*

      When configuring a 64-bit-default GCC on Solaris/SPARC, you must use a build compiler that generates 64-bit code, either by default or by ! specifying ‘CC='gcc -m64' CXX='g++ -m64' GDC='gdc -m64'’ to configure. ! Additionally, you must pass --build=sparcv9-sun-solaris2.11 ! or --build=sparc64-sun-solaris2.11 because config.guess misdetects this situation, which can cause build failures.

      When configuring the GNU Multiple Precision Library (GMP), the MPFR library or the MPC library, the canonical target triplet must be specified ! as the build parameter on the configure line. For example:

      !
      ! 
      % srcdir/configure --build=sparcv9-sun-solaris2.11 --prefix=dirname
      !

      c6x-*-*

      The C6X family of processors. This port requires binutils-2.22 or newer.

      !

      visium-*-elf

      CDS VISIUMcore processor. This configuration is intended for embedded systems.

      !

      *-*-vxworks*

      !

      Support for VxWorks is in flux. At present GCC supports only the very recent VxWorks 5.5 (aka Tornado 2.2) release, and only on PowerPC. We welcome patches for other architectures supported by VxWorks 5.5. Support for VxWorks AE would also be welcome; we believe this is merely --- 1137,1192 ----

      Starting with Solaris 7, the operating system is capable of executing 64-bit SPARC V9 binaries. GCC 3.1 and later properly supports ! this; the -m64 option enables 64-bit code generation.

      When configuring the GNU Multiple Precision Library (GMP), the MPFR library or the MPC library on Solaris, the canonical target triplet must ! be specified as the build parameter on the configure line. This target triplet can be obtained by invoking ! ./config.guess in the toplevel source directory of GCC (and not that of GMP or MPFR or MPC). For example:

      !
      ! 
      % srcdir/configure --build=sparc-sun-solaris2.11 --prefix=dirname
      !

      sparc-*-linux*

      !

      sparc64-*-solaris2*

      !

      This is a synonym for ‘sparcv9-*-solaris2*’.

      !

      sparcv9-*-solaris2*

      When configuring a 64-bit-default GCC on Solaris/SPARC, you must use a build compiler that generates 64-bit code, either by default or by ! specifying ‘CC='gcc -m64' CXX='g++ -m64' GDC='gdc -m64'’ to configure. ! Additionally, you must pass --build=sparcv9-sun-solaris2.11 ! or --build=sparc64-sun-solaris2.11 because config.guess misdetects this situation, which can cause build failures.

      When configuring the GNU Multiple Precision Library (GMP), the MPFR library or the MPC library, the canonical target triplet must be specified ! as the build parameter on the configure line. For example:

      !
      ! 
      % srcdir/configure --build=sparcv9-sun-solaris2.11 --prefix=dirname
      !

      c6x-*-*

      The C6X family of processors. This port requires binutils-2.22 or newer.

      !

      visium-*-elf

      CDS VISIUMcore processor. This configuration is intended for embedded systems.

      !

      *-*-vxworks*

      !

      Support for VxWorks is in flux. At present GCC supports only the very recent VxWorks 5.5 (aka Tornado 2.2) release, and only on PowerPC. We welcome patches for other architectures supported by VxWorks 5.5. Support for VxWorks AE would also be welcome; we believe this is merely *************** not interested in supporting older, a.ou *** 1207,1313 **** VxWorks in GCC 3.

      VxWorks comes with an older version of GCC installed in ! $WIND_BASE/host; we recommend you do not overwrite it. ! Choose an installation prefix entirely outside $WIND_BASE. ! Before running configure, create the directories prefix ! and prefix/bin. Link or copy the appropriate assembler, ! linker, etc. into prefix/bin, and set your PATH to ! include that directory while running both configure and ! make.

      !

      You must give configure the ! --with-headers=$WIND_BASE/target/h switch so that it can find the VxWorks system headers. Since VxWorks is a cross compilation ! target only, you must also specify --target=target. ! configure will attempt to create the directory ! prefix/target/sys-include and copy files into it; ! make sure the user running configure has sufficient privilege to do so.

      GCC’s exception handling runtime requires a special “configlette” ! module, contrib/gthr_supp_vxw_5x.c. Follow the instructions in that file to add the module to your kernel build. (Future versions of VxWorks will incorporate this module.)

      !

      x86_64-*-*, amd64-*-*

      GCC supports the x86-64 architecture implemented by the AMD64 processor (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD. On GNU/Linux the default is a bi-arch compiler which is able to generate ! both 64-bit x86-64 and 32-bit x86 code (via the -m32 switch).

      !

      x86_64-*-solaris2*

      GCC also supports the x86-64 architecture implemented by the AMD64 ! processor (‘amd64-*-*’ is an alias for ‘x86_64-*-*’). Unlike other systems, without special options a bi-arch compiler is built which generates 32-bit code by default, but ! can generate 64-bit x86-64 code with the -m64 switch. Since GCC 4.7, there is also a configuration that defaults to 64-bit code, but ! can generate 32-bit code with -m32. To configure and build ! this way, you have to provide all support libraries like libgmp ! as 64-bit code, configure with --target=x86_64-pc-solaris2.11 ! and ‘CC=gcc -m64’.

      !

      xtensa*-*-elf

      This target is intended for embedded Xtensa systems using the ! ‘newlib’ C library. It uses ELF but does not support shared objects. Designed-defined instructions specified via the Tensilica Instruction Extension (TIE) language are only supported through inline assembly.

      The Xtensa configuration information must be specified prior to ! building GCC. The include/xtensa-config.h header file contains the configuration information. If you created your own Xtensa configuration with the Xtensa Processor Generator, the downloaded files include a customized copy of this header file, which you can use to replace the default header file.

      !

      xtensa*-*-linux*

      This target is for Xtensa systems running GNU/Linux. It supports ELF shared objects and the GNU C library (glibc). It also generates position-independent code (PIC) regardless of whether the ! -fpic or -fPIC options are used. In other respects, this target is the same as the ! ‘xtensa*-*-elf’ target.

      !

      Microsoft Windows

      !

      Intel 16-bit versions

      The 16-bit versions of Microsoft Windows, such as Windows 3.1, are not supported.

      However, the 32-bit port has limited support for Microsoft Windows 3.11 in the Win32s environment, as a target only. See below.

      !

      Intel 32-bit versions

      The 32-bit versions of Windows, including Windows 95, Windows NT, Windows XP, and Windows Vista, are supported by several different target platforms. These targets differ in which Windows subsystem they target and which C libraries are used.

      !
        !
      • Cygwin *-*-cygwin: Cygwin provides a user-space Linux API emulation layer in the Win32 subsystem. !
      • MinGW *-*-mingw32: MinGW is a native GCC port for the Win32 subsystem that provides a subset of POSIX. !
      • MKS i386-pc-mks: NuTCracker from MKS. See ! https://www.mkssoftware.com for more information.
      !

      Intel 64-bit versions

      GCC contains support for x86-64 using the mingw-w64 ! runtime library, available from https://www.mingw-w64.org/downloads/. This library should be used with the target triple x86_64-pc-mingw32.

      !

      Windows CE

      Windows CE is supported as a target only on Hitachi SuperH (sh-wince-pe), and MIPS (mips-wince-pe).

      !

      Other Windows Platforms

      GCC no longer supports Windows NT on the Alpha or PowerPC.

      GCC no longer supports the Windows POSIX subsystem. However, it does --- 1195,1301 ---- VxWorks in GCC 3.

      VxWorks comes with an older version of GCC installed in ! $WIND_BASE/host; we recommend you do not overwrite it. ! Choose an installation prefix entirely outside $WIND_BASE. ! Before running configure, create the directories prefix ! and prefix/bin. Link or copy the appropriate assembler, ! linker, etc. into prefix/bin, and set your PATH to ! include that directory while running both configure and ! make.

      !

      You must give configure the ! --with-headers=$WIND_BASE/target/h switch so that it can find the VxWorks system headers. Since VxWorks is a cross compilation ! target only, you must also specify --target=target. ! configure will attempt to create the directory ! prefix/target/sys-include and copy files into it; ! make sure the user running configure has sufficient privilege to do so.

      GCC’s exception handling runtime requires a special “configlette” ! module, contrib/gthr_supp_vxw_5x.c. Follow the instructions in that file to add the module to your kernel build. (Future versions of VxWorks will incorporate this module.)

      !

      x86_64-*-*, amd64-*-*

      GCC supports the x86-64 architecture implemented by the AMD64 processor (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD. On GNU/Linux the default is a bi-arch compiler which is able to generate ! both 64-bit x86-64 and 32-bit x86 code (via the -m32 switch).

      !

      x86_64-*-solaris2*

      GCC also supports the x86-64 architecture implemented by the AMD64 ! processor (‘amd64-*-*’ is an alias for ‘x86_64-*-*’). Unlike other systems, without special options a bi-arch compiler is built which generates 32-bit code by default, but ! can generate 64-bit x86-64 code with the -m64 switch. Since GCC 4.7, there is also a configuration that defaults to 64-bit code, but ! can generate 32-bit code with -m32. To configure and build ! this way, you have to provide all support libraries like libgmp ! as 64-bit code, configure with --target=x86_64-pc-solaris2.11 ! and ‘CC=gcc -m64’.

      !

      xtensa*-*-elf

      This target is intended for embedded Xtensa systems using the ! ‘newlib’ C library. It uses ELF but does not support shared objects. Designed-defined instructions specified via the Tensilica Instruction Extension (TIE) language are only supported through inline assembly.

      The Xtensa configuration information must be specified prior to ! building GCC. The include/xtensa-config.h header file contains the configuration information. If you created your own Xtensa configuration with the Xtensa Processor Generator, the downloaded files include a customized copy of this header file, which you can use to replace the default header file.

      !

      xtensa*-*-linux*

      This target is for Xtensa systems running GNU/Linux. It supports ELF shared objects and the GNU C library (glibc). It also generates position-independent code (PIC) regardless of whether the ! -fpic or -fPIC options are used. In other respects, this target is the same as the ! ‘xtensa*-*-elf’ target.

      !

      Microsoft Windows

      !

      Intel 16-bit versions

      The 16-bit versions of Microsoft Windows, such as Windows 3.1, are not supported.

      However, the 32-bit port has limited support for Microsoft Windows 3.11 in the Win32s environment, as a target only. See below.

      !

      Intel 32-bit versions

      The 32-bit versions of Windows, including Windows 95, Windows NT, Windows XP, and Windows Vista, are supported by several different target platforms. These targets differ in which Windows subsystem they target and which C libraries are used.

      !
        !
      • Cygwin *-*-cygwin: Cygwin provides a user-space Linux API emulation layer in the Win32 subsystem. !
      • MinGW *-*-mingw32: MinGW is a native GCC port for the Win32 subsystem that provides a subset of POSIX. !
      • MKS i386-pc-mks: NuTCracker from MKS. See ! https://www.mkssoftware.com for more information.
      !

      Intel 64-bit versions

      GCC contains support for x86-64 using the mingw-w64 ! runtime library, available from https://www.mingw-w64.org/downloads/. This library should be used with the target triple x86_64-pc-mingw32.

      !

      Windows CE

      Windows CE is supported as a target only on Hitachi SuperH (sh-wince-pe), and MIPS (mips-wince-pe).

      !

      Other Windows Platforms

      GCC no longer supports Windows NT on the Alpha or PowerPC.

      GCC no longer supports the Windows POSIX subsystem. However, it does *************** support the Interix subsystem. See abov *** 1318,1326 ****

      UWIN support has been removed due to a lack of maintenance.

      !

      *-*-cygwin

      Ports of GCC are included with the ! Cygwin environment.

      GCC will build under Cygwin without modification; it does not build with Microsoft’s C++ compiler and there are no plans to make it do so. --- 1306,1314 ----

      UWIN support has been removed due to a lack of maintenance.

      !

      *-*-cygwin

      Ports of GCC are included with the ! Cygwin environment.

      GCC will build under Cygwin without modification; it does not build with Microsoft’s C++ compiler and there are no plans to make it do so. *************** the latest official GNU binutils release *** 1332,1348 **** or version 2.20 or above if building your own.

      !

      *-*-mingw32

      GCC will build with and support only MinGW runtime 3.12 and later. Earlier versions of headers are incompatible with the new default semantics ! of extern inline in -std=c99 and -std=gnu99 modes.

      To support emitting DWARF debugging info you need to use GNU binutils ! version 2.16 or above containing support for the .secrel32 assembler pseudo-op.

      !

      Older systems

      GCC contains support files for many older (1980s and early 1990s) Unix variants. For the most part, support for these systems has not been deliberately removed, but it has not been maintained for --- 1320,1336 ---- or version 2.20 or above if building your own.

      !

      *-*-mingw32

      GCC will build with and support only MinGW runtime 3.12 and later. Earlier versions of headers are incompatible with the new default semantics ! of extern inline in -std=c99 and -std=gnu99 modes.

      To support emitting DWARF debugging info you need to use GNU binutils ! version 2.16 or above containing support for the .secrel32 assembler pseudo-op.

      !

      Older systems

      GCC contains support files for many older (1980s and early 1990s) Unix variants. For the most part, support for these systems has not been deliberately removed, but it has not been maintained for *************** several years and may suffer from bitrot *** 1350,1356 ****

      Starting with GCC 3.1, each release has a list of “obsoleted” systems. Support for these systems is still present in that release, but ! configure will fail unless the --enable-obsolete option is given. Unless a maintainer steps forward, support for these systems will be removed from the next release of GCC.

      --- 1338,1344 ----

      Starting with GCC 3.1, each release has a list of “obsoleted” systems. Support for these systems is still present in that release, but ! configure will fail unless the --enable-obsolete option is given. Unless a maintainer steps forward, support for these systems will be removed from the next release of GCC.

      *************** bring GCC up on such a system, if still *** 1361,1369 **** require first installing an old version of GCC which did work on that system, and using it to compile a more recent GCC, to avoid bugs in the vendor compiler. Old releases of GCC 1 and GCC 2 are available in the ! old-releases directory on the GCC mirror sites. Header bugs may generally be avoided using ! fixincludes, but bugs or deficiencies in libraries and the operating system may still cause problems.

      Support for older systems as targets for cross-compilation is less --- 1349,1357 ---- require first installing an old version of GCC which did work on that system, and using it to compile a more recent GCC, to avoid bugs in the vendor compiler. Old releases of GCC 1 and GCC 2 are available in the ! old-releases directory on the GCC mirror sites. Header bugs may generally be avoided using ! fixincludes, but bugs or deficiencies in libraries and the operating system may still cause problems.

      Support for older systems as targets for cross-compilation is less *************** problematic than support for them as hos *** 1371,1383 **** wishes to make such a target work again (including resurrecting any of the targets that never worked with GCC 2, starting from the last version before they were removed), patches ! following the usual requirements would be likely to be accepted, since they should not affect the support for more modern targets.

      For some systems, old versions of GNU binutils may also be useful, ! and are available from pub/binutils/old-releases on ! sourceware.org mirror sites.

      Some of the information on specific systems above relates to such older systems, but much of the information --- 1359,1371 ---- wishes to make such a target work again (including resurrecting any of the targets that never worked with GCC 2, starting from the last version before they were removed), patches ! following the usual requirements would be likely to be accepted, since they should not affect the support for more modern targets.

      For some systems, old versions of GNU binutils may also be useful, ! and are available from pub/binutils/old-releases on ! sourceware.org mirror sites.

      Some of the information on specific systems above relates to such older systems, but much of the information *************** about GCC on such systems (which may no *** 1385,1400 **** current GCC) is to be found in the GCC texinfo manual.

      !

      all ELF targets (SVR4, Solaris, etc.)

      C++ support is significantly better on ELF targets if you use the ! GNU linker; duplicate copies of inlines, vtables and template instantiations will be discarded automatically.

      !

      Return to the GCC Installation page

      --- 1373,1388 ---- current GCC) is to be found in the GCC texinfo manual.

      !

      all ELF targets (SVR4, Solaris, etc.)

      C++ support is significantly better on ELF targets if you use the ! GNU linker; duplicate copies of inlines, vtables and template instantiations will be discarded automatically.

      !

      Return to the GCC Installation page

      diff -Nrcpad gcc-13.4.0/INSTALL/test.html gcc-13.5.0-RC-20260904/INSTALL/test.html *** gcc-13.4.0/INSTALL/test.html Thu Jun 5 16:05:04 2025 --- gcc-13.5.0-RC-20260904/INSTALL/test.html Fri Sep 4 07:35:15 2026 *************** *** 1,9 **** ! ! ! ! --- 33,42 ---- *************** ul.no-bullet {list-style: none} *** 55,61 **** -

      Installing GCC: Testing

      --- 44,49 ---- *************** ul.no-bullet {list-style: none} *** 80,115 **** ! ! !

      Before you install GCC, we encourage you to run the testsuites and to compare your results with results from a similar configuration that have been submitted to the ! gcc-testresults mailing list. Some of these archived results are linked from the build status lists ! at https://gcc.gnu.org/buildstat.html, although not everyone who reports a successful build runs the testsuites and submits the results. This step is optional and may require you to download additional software, but it can give you confidence in your new GCC installation or point out problems before you install and start using your new GCC.

      !

      First, you must have downloaded the testsuites. These are included in the source tarball.

      Second, you must have the testing tools installed. This includes ! DejaGnu, Tcl, and Expect; the DejaGnu site has links to these. Some optional tests also require Python3 and pytest module.

      !

      If the directories where runtest and expect were ! installed are not in the PATH, you may need to set the following environment variables appropriately, as in the following example (which ! assumes that DejaGnu has been installed under /usr/local):

      !
      ! 
      TCL_LIBRARY = /usr/local/share/tcl8.0
  DEJAGNULIBS = /usr/local/share/dejagnu
      --- 68,103 ---- ! ! !

      Before you install GCC, we encourage you to run the testsuites and to compare your results with results from a similar configuration that have been submitted to the ! gcc-testresults mailing list. Some of these archived results are linked from the build status lists ! at https://gcc.gnu.org/buildstat.html, although not everyone who reports a successful build runs the testsuites and submits the results. This step is optional and may require you to download additional software, but it can give you confidence in your new GCC installation or point out problems before you install and start using your new GCC.

      !

      First, you must have downloaded the testsuites. These are included in the source tarball.

      Second, you must have the testing tools installed. This includes ! DejaGnu, Tcl, and Expect; the DejaGnu site has links to these. Some optional tests also require Python3 and pytest module.

      !

      If the directories where runtest and expect were ! installed are not in the PATH, you may need to set the following environment variables appropriately, as in the following example (which ! assumes that DejaGnu has been installed under /usr/local):

      !
      ! 
      TCL_LIBRARY = /usr/local/share/tcl8.0
  DEJAGNULIBS = /usr/local/share/dejagnu
      *************** portability in the DejaGnu code.) *** 119,211 ****

      Finally, you can run the testsuite (which may take a long time): !

      ! 
      cd objdir; make -k check

      This will test various components of GCC, such as compiler front ends and runtime libraries. While running the testsuite, DejaGnu might emit some harmless messages resembling ! ‘WARNING: Couldn't find the global config file.’ or ! ‘WARNING: Couldn't find tool init file’ that can be ignored.

      If you are testing a cross-compiler, you may want to run the testsuite ! on a simulator as described at https://gcc.gnu.org/simtest-howto.html.

      !
      !

      How can you run the testsuite on selected tests?

      In order to run sets of tests selectively, there are targets ! ‘make check-gcc’ and language specific ‘make check-c’, ! ‘make check-c++’, ‘make check-d’ ‘make check-fortran’, ! ‘make check-ada’, ‘make check-m2’, ‘make check-objc’, ! ‘make check-obj-c++’, ‘make check-lto’ in the gcc subdirectory of the object directory. You can also just run ! ‘make check’ in a subdirectory of the object directory.

      !

      A more selective way to just run all gcc execute tests in the testsuite is to use

      !
      ! 
      make check-gcc RUNTESTFLAGS="execute.exp other-options"
      !

      Likewise, in order to run only the g++ “old-deja” tests in ! the testsuite with filenames matching ‘9805*’, you would use

      !
      ! 
      make check-g++ RUNTESTFLAGS="old-deja.exp=9805* other-options"
      !

      The file-matching expression following filename.exp= is treated as a series of whitespace-delimited glob expressions so that multiple patterns may be passed, although any whitespace must either be escaped or surrounded by single quotes if multiple expressions are desired. For example,

      !
      ! 
      make check-g++ RUNTESTFLAGS="old-deja.exp=9805*\ virtual2.c other-options"
! make check-g++ RUNTESTFLAGS="'old-deja.exp=9805* virtual2.c' other-options"
      !

      The *.exp files are located in the testsuite directories of the GCC ! source, the most important ones being compile.exp, ! execute.exp, dg.exp and old-deja.exp. ! To get a list of the possible *.exp files, pipe the ! output of ‘make check’ into a file and look at the ! ‘Running … .exp’ lines.

      !
      !

      Passing options and running multiple testsuites

      You can pass multiple options to the testsuite using the ! ‘--target_board’ option of DejaGNU, either passed as part of ! ‘RUNTESTFLAGS’, or directly to runtest if you prefer to work outside the makefiles. For example,

      !
      ! 
      make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
      !

      will run the standard g++ testsuites (“unix” is the target name for a standard native testsuite situation), passing ! ‘-O3 -fmerge-constants’ to the compiler on every test, i.e., slashes separate options.

      You can run the testsuites multiple times using combinations of options with a syntax similar to the brace expansion of popular shells:

      !
      ! 
      …"--target_board=arm-sim\{-mhard-float,-msoft-float\}\{-O1,-O2,-O3,\}"

      (Note the empty option caused by the trailing comma in the final group.) ! The following will run each testsuite eight times using the ‘arm-sim’ target, as if you had specified all possible combinations yourself:

      !
      ! 
      --target_board='arm-sim/-mhard-float/-O1 \
                  arm-sim/-mhard-float/-O2 \
                  arm-sim/-mhard-float/-O3 \
                  arm-sim/-mhard-float \
--- 107,199 ----
  
      
  
  
      Finally, you can run the testsuite (which may take a long time):
! 
      
! 
      cd objdir; make -k check
  
      
  
  
      This will test various components of GCC, such as compiler
  front ends and runtime libraries.  While running the testsuite, DejaGnu
  might emit some harmless messages resembling
! ‘WARNING: Couldn't find the global config file.’ or
! ‘WARNING: Couldn't find tool init file’ that can be ignored.
  
      
  
      If you are testing a cross-compiler, you may want to run the testsuite
! on a simulator as described at https://gcc.gnu.org/simtest-howto.html.
  
      
! 
      
! 
      How can you run the testsuite on selected tests?
      
  
  
      In order to run sets of tests selectively, there are targets
! ‘make check-gcc’ and language specific ‘make check-c’,
! ‘make check-c++’, ‘make check-d’ ‘make check-fortran’,
! ‘make check-ada’, ‘make check-m2’, ‘make check-objc’,
! ‘make check-obj-c++’, ‘make check-lto’ in the gcc
  subdirectory of the object directory.  You can also just run
! ‘make check’ in a subdirectory of the object directory.
  
      
  
! 
      A more selective way to just run all gcc execute tests in the
  testsuite is to use
  
      
! 
      
! 
      make check-gcc RUNTESTFLAGS="execute.exp other-options"
  
      
  
! 
      Likewise, in order to run only the g++ “old-deja” tests in
! the testsuite with filenames matching ‘9805*’, you would use
  
      
! 
      
! 
      make check-g++ RUNTESTFLAGS="old-deja.exp=9805* other-options"
  
      
  
! 
      The file-matching expression following filename.exp= is treated
  as a series of whitespace-delimited glob expressions so that multiple patterns
  may be passed, although any whitespace must either be escaped or surrounded by
  single quotes if multiple expressions are desired. For example,
  
      
! 
      
! 
      make check-g++ RUNTESTFLAGS="old-deja.exp=9805*\ virtual2.c other-options"
! make check-g++ RUNTESTFLAGS="'old-deja.exp=9805* virtual2.c' other-options"
  
      
  
! 
      The *.exp files are located in the testsuite directories of the GCC
! source, the most important ones being compile.exp,
! execute.exp, dg.exp and old-deja.exp.
! To get a list of the possible *.exp files, pipe the
! output of ‘make check’ into a file and look at the
! ‘Running …  .exp’ lines.
  
      
  
      
! 
      
! 
      Passing options and running multiple testsuites
      
  
  
      You can pass multiple options to the testsuite using the
! ‘--target_board’ option of DejaGNU, either passed as part of
! ‘RUNTESTFLAGS’, or directly to runtest if you prefer to
  work outside the makefiles.  For example,
  
      
! 
      
! 
      make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
  
      
  
! 
      will run the standard g++ testsuites (“unix” is the target name
  for a standard native testsuite situation), passing
! ‘-O3 -fmerge-constants’ to the compiler on every test, i.e.,
  slashes separate options.
  
      
  
      You can run the testsuites multiple times using combinations of options
  with a syntax similar to the brace expansion of popular shells:
  
      
! 
      
! 
      ..."--target_board=arm-sim\{-mhard-float,-msoft-float\}\{-O1,-O2,-O3,\}"
  
      
  
  
      (Note the empty option caused by the trailing comma in the final group.)
! The following will run each testsuite eight times using the ‘arm-sim’
  target, as if you had specified all possible combinations yourself:
  
      
! 
      
! 
      --target_board='arm-sim/-mhard-float/-O1 \
                  arm-sim/-mhard-float/-O2 \
                  arm-sim/-mhard-float/-O3 \
                  arm-sim/-mhard-float \
*************** target, as if you had specified all poss
*** 218,270 ****
  
      They can be combined as many times as you wish, in arbitrary ways.  This
  list:
  
      
! 
      
! 
      …"--target_board=unix/-Wextra\{-O3,-fno-strength\}\{-fomit-frame,\}"
  
      
  
! 
      will generate four combinations, all involving ‘-Wextra’.
  
      
  
      The disadvantage to this method is that the testsuites are run in serial,
  which is a waste on multiprocessor systems.  For users with GNU Make and
  a shell which performs brace expansion, you can run the testsuites in
! parallel by having the shell perform the combinations and make
! do the parallel runs.  Instead of using ‘--target_board’, use a
  special makefile target:
  
      
! 
      
! 
      make -jN check-testsuite//test-target/option1/option2/…
  
      
  
  
      For example,
  
      
! 
      
! 
      make -j3 check-gcc//sh-hms-sim/{-m1,-m2,-m3,-m3e,-m4}/{,-nofpu}
  
      
  
  
      will run three concurrent “make-gcc” testsuites, eventually testing all
  ten combinations as described above.  Note that this is currently only
! supported in the gcc subdirectory.  (To see how this works, try
! typing echo before the example given here.)
  
      
  
  
      
! 
      
! 
      How to interpret test results
      
  
! 
      The result of running the testsuite are various *.sum and *.log
! files in the testsuite subdirectories.  The *.log files contain a
  detailed log of the compiler invocations and the corresponding
! results, the *.sum files summarize the results.  These summaries
  contain status codes for all tests:
  
      
! 
        
! 
      •  PASS: the test passed as expected
! 
      •  XPASS: the test unexpectedly passed
! 
      •  FAIL: the test unexpectedly failed
! 
      •  XFAIL: the test failed as expected
! 
      •  UNSUPPORTED: the test is not supported on this platform
! 
      •  ERROR: the testsuite detected an error
! 
      •  WARNING: the testsuite detected a possible problem
  
      
  
  
      It is normal for some tests to report unexpected failures.  At the
--- 206,258 ----
  
      They can be combined as many times as you wish, in arbitrary ways.  This
  list:
  
      
! 
      
! 
      ..."--target_board=unix/-Wextra\{-O3,-fno-strength\}\{-fomit-frame,\}"
  
      
  
! 
      will generate four combinations, all involving ‘-Wextra’.
  
      
  
      The disadvantage to this method is that the testsuites are run in serial,
  which is a waste on multiprocessor systems.  For users with GNU Make and
  a shell which performs brace expansion, you can run the testsuites in
! parallel by having the shell perform the combinations and make
! do the parallel runs.  Instead of using ‘--target_board’, use a
  special makefile target:
  
      
! 
      
! 
      make -jN check-testsuite//test-target/option1/option2/...
  
      
  
  
      For example,
  
      
! 
      
! 
      make -j3 check-gcc//sh-hms-sim/{-m1,-m2,-m3,-m3e,-m4}/{,-nofpu}
  
      
  
  
      will run three concurrent “make-gcc” testsuites, eventually testing all
  ten combinations as described above.  Note that this is currently only
! supported in the gcc subdirectory.  (To see how this works, try
! typing echo before the example given here.)
  
      
  
  
      
! 
      
! 
      How to interpret test results
      
  
! 
      The result of running the testsuite are various *.sum and *.log
! files in the testsuite subdirectories.  The *.log files contain a
  detailed log of the compiler invocations and the corresponding
! results, the *.sum files summarize the results.  These summaries
  contain status codes for all tests:
  
      
! 
        
! 
      • PASS: the test passed as expected
! 
      • XPASS: the test unexpectedly passed
! 
      • FAIL: the test unexpectedly failed
! 
      • XFAIL: the test failed as expected
! 
      • UNSUPPORTED: the test is not supported on this platform
! 
      • ERROR: the testsuite detected an error
! 
      • WARNING: the testsuite detected a possible problem
  
      
  
  
      It is normal for some tests to report unexpected failures.  At the
*************** be fixed in future releases.
*** 274,292 ****
  
      
  
  
      
! 
      
! 
      Submitting test results
      
  
  
      If you want to report the results to the GCC project, use the
! contrib/test_summary shell script.  Start it in the objdir with
  
      
! 
      
! 
      srcdir/contrib/test_summary -p your_commentary.txt \
      -m gcc-testresults@gcc.gnu.org |sh
  
      
  
! 
      This script uses the Mail program to send the results, so
! make sure it is in your PATH.  The file your_commentary.txt is
  prepended to the testsuite summary and should contain any special
  remarks you have on your results or your build environment.  Please
  do not edit the testsuite result block or the subject line, as these
--- 262,280 ----
  
      
  
  
      
! 
      
! 
      Submitting test results
      
  
  
      If you want to report the results to the GCC project, use the
! contrib/test_summary shell script.  Start it in the objdir with
  
      
! 
      
! 
      srcdir/contrib/test_summary -p your_commentary.txt \
      -m gcc-testresults@gcc.gnu.org |sh
  
      
  
! 
      This script uses the Mail program to send the results, so
! make sure it is in your PATH.  The file your_commentary.txt is
  prepended to the testsuite summary and should contain any special
  remarks you have on your results or your build environment.  Please
  do not edit the testsuite result block or the subject line, as these
*************** messages may be automatically processed.
*** 294,307 ****
  
      
  
      
  
      
! 
      Return to the GCC Installation page
  
      
  
  
  
  
  
! 
      
  
  
  
--- 282,295 ----
  
      
  
      
  
      
! 
      Return to the GCC Installation page
  
      
  
  
  
  
  
! 
      
  
  
  
diff -Nrcpad gcc-13.4.0/LAST_UPDATED gcc-13.5.0-RC-20260904/LAST_UPDATED
*** gcc-13.4.0/LAST_UPDATED	Thu Jun  5 16:05:02 2025
--- gcc-13.5.0-RC-20260904/LAST_UPDATED	Fri Sep  4 07:35:14 2026
***************
*** 1 ****
! Obtained from git: releases/gcc-13.4.0 revision 99677969d463d75a562f94460ea75e9f6a016b4f
--- 1 ----
! Obtained from git: releases/gcc-13 revision 3c92f70d174a1bc9a4bfb866d331caa9943fe724
diff -Nrcpad gcc-13.4.0/MD5SUMS gcc-13.5.0-RC-20260904/MD5SUMS
*** gcc-13.4.0/MD5SUMS	Thu Jun  5 16:32:32 2025
--- gcc-13.5.0-RC-20260904/MD5SUMS	Fri Sep  4 07:57:55 2026
***************
*** 1,5 ****
  # This file contains the MD5 checksums of the files in the
! # gcc-13.4.0.tar.xz tarball.
  #
  # Besides verifying that all files in the tarball were correctly expanded,
  # it also can be used to determine if any files have changed since the
--- 1,5 ----
  # This file contains the MD5 checksums of the files in the
! # gcc-13.5.0-RC-20260904.tar.xz tarball.
  #
  # Besides verifying that all files in the tarball were correctly expanded,
  # it also can be used to determine if any files have changed since the
*************** d32239bcb673463ab874e80d47fae504  COPYIN
*** 21,42 ****
  fd4ecdf5d672efe2b0e409aca9cf9446  ChangeLog.jit
  09538b708302f1735f6fa05b622ecf5e  ChangeLog.tree-ssa
  24ab760126489e69436a43185dc3d202  INSTALL/README
! e611a6d09222f5d36a873ea66fe9a9f2  INSTALL/binaries.html
! a2eb6e11d0c89068f788113372c76b23  INSTALL/build.html
! b9ec3c7a83c86f7307278e13f486234d  INSTALL/configure.html
! b505e790ec3f9e097a4b1d43a7bdd178  INSTALL/download.html
! 06e5c3d38f648573ed6e03c7bbbb672c  INSTALL/finalinstall.html
! fe07f4a77b2b246f67cc5eae162b510e  INSTALL/gfdl.html
! 1d59b420876d0ffc1fa8dd47836597cb  INSTALL/index.html
! cd5076051085f5cff39d8bfe54d1e160  INSTALL/prerequisites.html
! 2c354642f325b07772e4d3c926b98f79  INSTALL/specific.html
! 62069886bede1942dc164b60e4e4f62c  INSTALL/test.html
! d83e96064b94604535750f674c79d282  LAST_UPDATED
  81b3330d422f3ce1ef8b720dfae35068  MAINTAINERS
  2b61ddbd876fa839639a7ca551773426  Makefile.def
  5d2d6a74f897f8158d37f5f2ec6877ce  Makefile.in
  ee1e4bbc0929b8c8b5030564189dac22  Makefile.tpl
! 70ee04dcbde099c3d4bd5432024a07a6  NEWS
  80d26bc3b1ad4f6969a96a24c9181bf5  README
  a657821f65bab77f4fbf3a75cdee6da9  ar-lib
  83975a957803b20bc02b9f8600e8a234  c++tools/ChangeLog
--- 21,42 ----
  fd4ecdf5d672efe2b0e409aca9cf9446  ChangeLog.jit
  09538b708302f1735f6fa05b622ecf5e  ChangeLog.tree-ssa
  24ab760126489e69436a43185dc3d202  INSTALL/README
! 4e572a0751a2bd0d9af69796830097eb  INSTALL/binaries.html
! 71d713a8bd27e534c57a02ab1ba01d71  INSTALL/build.html
! 00a282607cf086fdb1132b3f5228e4d5  INSTALL/configure.html
! 8d7315ca6fe49a4e358ceca3b3a424fb  INSTALL/download.html
! ccb61b55e5435984676e707ee130e66d  INSTALL/finalinstall.html
! 0eb5feaac351bc5f56357d3686b5493c  INSTALL/gfdl.html
! d8f45cab3ba80d26d5b6dce81ebab421  INSTALL/index.html
! ec70482379c6030bac1fa4ef3668e024  INSTALL/prerequisites.html
! 01a42186dc76bcb551cb9848b5f49ff5  INSTALL/specific.html
! 826dbdf1d37f0ecd8e716ffe14875e73  INSTALL/test.html
! ffa4c088f327d564502dbee4a0fbf5f2  LAST_UPDATED
  81b3330d422f3ce1ef8b720dfae35068  MAINTAINERS
  2b61ddbd876fa839639a7ca551773426  Makefile.def
  5d2d6a74f897f8158d37f5f2ec6877ce  Makefile.in
  ee1e4bbc0929b8c8b5030564189dac22  Makefile.tpl
! 66a4023d69127e6e10c5809ab083f523  NEWS
  80d26bc3b1ad4f6969a96a24c9181bf5  README
  a657821f65bab77f4fbf3a75cdee6da9  ar-lib
  83975a957803b20bc02b9f8600e8a234  c++tools/ChangeLog
*************** a22e70b3f29292d0e628450f4bb11e62  fixinc
*** 481,492 ****
  8baab8698bb83c6b90ef4091c00ddc1e  fixincludes/tests/base/unistd.h
  75d75572793b62bdd8ff4d1504e0cb4c  fixincludes/tests/base/yvals.h
  6593c1e7d0535b989e3b12084f001039  gcc/ABOUT-GCC-NLS
! 93779f9d84ced7bf2de42bc824b71f8a  gcc/BASE-VER
  59530bdf33659b29e73d4adb9f9f6552  gcc/COPYING
  a916467b91076e631dd8edb7424769c7  gcc/COPYING.LIB
  d32239bcb673463ab874e80d47fae504  gcc/COPYING3
  6a6a8e020838b23406c81b19c1d46df6  gcc/COPYING3.LIB
! 45508de0ce666cb8423fa502b7c3fa49  gcc/ChangeLog
  a3b63c675afa7a655cc2bfa8a907af79  gcc/ChangeLog-1997
  d9a88529352a010253c2e8fb1ed6023b  gcc/ChangeLog-1998
  240f08f81cb4699e8b49347db38233db  gcc/ChangeLog-1999
--- 481,492 ----
  8baab8698bb83c6b90ef4091c00ddc1e  fixincludes/tests/base/unistd.h
  75d75572793b62bdd8ff4d1504e0cb4c  fixincludes/tests/base/yvals.h
  6593c1e7d0535b989e3b12084f001039  gcc/ABOUT-GCC-NLS
! 0cc720d97be91208d41af219ef2dbe66  gcc/BASE-VER
  59530bdf33659b29e73d4adb9f9f6552  gcc/COPYING
  a916467b91076e631dd8edb7424769c7  gcc/COPYING.LIB
  d32239bcb673463ab874e80d47fae504  gcc/COPYING3
  6a6a8e020838b23406c81b19c1d46df6  gcc/COPYING3.LIB
! 1438a3bcf332fdb36f4f7a36361ff6a1  gcc/ChangeLog
  a3b63c675afa7a655cc2bfa8a907af79  gcc/ChangeLog-1997
  d9a88529352a010253c2e8fb1ed6023b  gcc/ChangeLog-1998
  240f08f81cb4699e8b49347db38233db  gcc/ChangeLog-1999
*************** fb3fadb88e1d2b3b640cfaaa5ff11780  gcc/Ch
*** 521,527 ****
  3eb07e0b2e542409bf73d359f7f65609  gcc/ChangeLog.ptr
  e13638e26743ba41e6011b76cc00d9a9  gcc/ChangeLog.tree-ssa
  739ab47f6425bcea1d05e4fc0542de54  gcc/ChangeLog.tuples
! fc63a5f59d6e9c4222fa7604b3ff39e7  gcc/DATESTAMP
  d41d8cd98f00b204e9800998ecf8427e  gcc/DEV-PHASE
  eb92e1ff5e982ca07e173e0eb286d243  gcc/FSFChangeLog
  30e1e33411566388b3164558482dc5e6  gcc/FSFChangeLog.10
--- 521,527 ----
  3eb07e0b2e542409bf73d359f7f65609  gcc/ChangeLog.ptr
  e13638e26743ba41e6011b76cc00d9a9  gcc/ChangeLog.tree-ssa
  739ab47f6425bcea1d05e4fc0542de54  gcc/ChangeLog.tuples
! 72c925ff5fb832697ccb857dceadce76  gcc/DATESTAMP
  d41d8cd98f00b204e9800998ecf8427e  gcc/DEV-PHASE
  eb92e1ff5e982ca07e173e0eb286d243  gcc/FSFChangeLog
  30e1e33411566388b3164558482dc5e6  gcc/FSFChangeLog.10
*************** ec6799501b2eb2923d5de6a66169dbd2  gcc/ON
*** 533,539 ****
  f6d47a542d432aed7e7eaaecb71d3a4c  gcc/acinclude.m4
  6526979dd900a0b58b7691b478a91fec  gcc/aclocal.m4
  16a499934b71eb6cf7c0d6899cd6006a  gcc/ada/.gitignore
! 4525d67bae5e046bda83ab349680a25e  gcc/ada/ChangeLog
  683be0b07dc4f64f118fd5e8ae9cb30d  gcc/ada/ChangeLog-2001
  7aff25efb203be4136b8776cdc812956  gcc/ada/ChangeLog-2002
  cd2379152000f40157d349018fb9364d  gcc/ada/ChangeLog-2003
--- 533,539 ----
  f6d47a542d432aed7e7eaaecb71d3a4c  gcc/acinclude.m4
  6526979dd900a0b58b7691b478a91fec  gcc/aclocal.m4
  16a499934b71eb6cf7c0d6899cd6006a  gcc/ada/.gitignore
! 9970d44973ad1be2fd0f48e732d648a4  gcc/ada/ChangeLog
  683be0b07dc4f64f118fd5e8ae9cb30d  gcc/ada/ChangeLog-2001
  7aff25efb203be4136b8776cdc812956  gcc/ada/ChangeLog-2002
  cd2379152000f40157d349018fb9364d  gcc/ada/ChangeLog-2003
*************** c81efe8ccbd5f5b8399a3496f5015859  gcc/ad
*** 560,566 ****
  2cf41efa2dee24b2dda73018b855edd3  gcc/ada/ChangeLog.tree-ssa
  79432d3beb46b4a8f4c4c114203a6527  gcc/ada/Make-generated.in
  6c9c3b4249e781ed48c7ae55e8ef9999  gcc/ada/Makefile.in
! 954a50a9d70041598f8c0618c6c66951  gcc/ada/Makefile.rtl
  328b32369db4e87b95cc21b16114a723  gcc/ada/accessibility.adb
  8398361054d01170d7c487f246c526e5  gcc/ada/accessibility.ads
  13cf7e52e4314ac021f4e7d70a814880  gcc/ada/ada_get_targ.adb
--- 560,566 ----
  2cf41efa2dee24b2dda73018b855edd3  gcc/ada/ChangeLog.tree-ssa
  79432d3beb46b4a8f4c4c114203a6527  gcc/ada/Make-generated.in
  6c9c3b4249e781ed48c7ae55e8ef9999  gcc/ada/Makefile.in
! d39da956525e9f73cd14e6bd796fd267  gcc/ada/Makefile.rtl
  328b32369db4e87b95cc21b16114a723  gcc/ada/accessibility.adb
  8398361054d01170d7c487f246c526e5  gcc/ada/accessibility.ads
  13cf7e52e4314ac021f4e7d70a814880  gcc/ada/ada_get_targ.adb
*************** c81efe8ccbd5f5b8399a3496f5015859  gcc/ad
*** 568,574 ****
  6b271163709fbc06df6ef8a7fd1c13da  gcc/ada/adabkend.ads
  a9e8e57440f10ce2ff3fbe5984b1c56c  gcc/ada/adadecode.c
  5933c19a89a051b38aa7a6e4716f502c  gcc/ada/adadecode.h
! 18bb16ad13ce57c6f4e8ca399648f1d6  gcc/ada/adaint.c
  6276ae5d40f1552dee393838e562b00b  gcc/ada/adaint.h
  6fb46a612b1053603893b4c055a97bde  gcc/ada/affinity.c
  4482e2fcea81b8826350b4f00907a278  gcc/ada/ali-util.adb
--- 568,574 ----
  6b271163709fbc06df6ef8a7fd1c13da  gcc/ada/adabkend.ads
  a9e8e57440f10ce2ff3fbe5984b1c56c  gcc/ada/adadecode.c
  5933c19a89a051b38aa7a6e4716f502c  gcc/ada/adadecode.h
! aa76838ad4f792edf5f7fafce67b0e2d  gcc/ada/adaint.c
  6276ae5d40f1552dee393838e562b00b  gcc/ada/adaint.h
  6fb46a612b1053603893b4c055a97bde  gcc/ada/affinity.c
  4482e2fcea81b8826350b4f00907a278  gcc/ada/ali-util.adb
*************** b989a7c6b1c5cc32357303dd95b3abfc  gcc/ad
*** 717,723 ****
  a9c24cbcffac5d49ea9292aebe5db0c4  gcc/ada/exp_ch12.ads
  764c0f39ff6b795aa889da01f26b2e69  gcc/ada/exp_ch13.adb
  da828d4dca65dbb421d61d7faa8d0487  gcc/ada/exp_ch13.ads
! 1014458fddfddaa600134bdd0b7ee2df  gcc/ada/exp_ch2.adb
  874379155c2b31c67f54611f40fb4cde  gcc/ada/exp_ch2.ads
  4f75c9a91928bda7bcdf4826cf5e434b  gcc/ada/exp_ch3.adb
  d218e87874041895cd5628dbbd8a6666  gcc/ada/exp_ch3.ads
--- 717,723 ----
  a9c24cbcffac5d49ea9292aebe5db0c4  gcc/ada/exp_ch12.ads
  764c0f39ff6b795aa889da01f26b2e69  gcc/ada/exp_ch13.adb
  da828d4dca65dbb421d61d7faa8d0487  gcc/ada/exp_ch13.ads
! b6c421f43eccb727ea5921fa00b5cd90  gcc/ada/exp_ch2.adb
  874379155c2b31c67f54611f40fb4cde  gcc/ada/exp_ch2.ads
  4f75c9a91928bda7bcdf4826cf5e434b  gcc/ada/exp_ch3.adb
  d218e87874041895cd5628dbbd8a6666  gcc/ada/exp_ch3.ads
*************** d69e0fff19957a7b29ee08926fc6f3cf  gcc/ad
*** 793,799 ****
  29e1f3d1ec783849cfedc4ba5b3f86d2  gcc/ada/gcc-interface/ada.h
  67dc9599090345bd6fc9fed0361f76ee  gcc/ada/gcc-interface/config-lang.in
  df2ffb467ff9812983d01da40295ec68  gcc/ada/gcc-interface/cuintp.cc
! 6dba8ed83dcf439bd6eef93dfb9a45ec  gcc/ada/gcc-interface/decl.cc
  2e46e3864371bc11eae92e2f030fe9c3  gcc/ada/gcc-interface/gadaint.h
  1e23461a8b089b3f96b0eec67b96b60d  gcc/ada/gcc-interface/gigi.h
  9f177b1d16ab7e6e558ee0eccca943ff  gcc/ada/gcc-interface/lang-specs.h
--- 793,799 ----
  29e1f3d1ec783849cfedc4ba5b3f86d2  gcc/ada/gcc-interface/ada.h
  67dc9599090345bd6fc9fed0361f76ee  gcc/ada/gcc-interface/config-lang.in
  df2ffb467ff9812983d01da40295ec68  gcc/ada/gcc-interface/cuintp.cc
! 9823a920edd689b62a47787950265ae0  gcc/ada/gcc-interface/decl.cc
  2e46e3864371bc11eae92e2f030fe9c3  gcc/ada/gcc-interface/gadaint.h
  1e23461a8b089b3f96b0eec67b96b60d  gcc/ada/gcc-interface/gigi.h
  9f177b1d16ab7e6e558ee0eccca943ff  gcc/ada/gcc-interface/lang-specs.h
*************** ba346875ad154b36248e6079d3289fbc  gcc/ad
*** 2133,2139 ****
  bd502dda780d8937cb41db3f3f0e2e2b  gcc/ada/libgnat/s-forrea.ads
  5ca3fdd5ab1b38ab57ba492007c4e17c  gcc/ada/libgnat/s-gearop.adb
  cb3a5533d9038f16078dc2c96ea9af4a  gcc/ada/libgnat/s-gearop.ads
! ff6a9f72bc1e109569388dee6b3254e0  gcc/ada/libgnat/s-genbig.adb
  23caa17005b767020406d5758fe2cb02  gcc/ada/libgnat/s-genbig.ads
  245b86cdfb6f5b2c7e4b1d771dc2ffb8  gcc/ada/libgnat/s-geveop.adb
  0f77fdbf1ddfe614fe464e248db0be4a  gcc/ada/libgnat/s-geveop.ads
--- 2133,2139 ----
  bd502dda780d8937cb41db3f3f0e2e2b  gcc/ada/libgnat/s-forrea.ads
  5ca3fdd5ab1b38ab57ba492007c4e17c  gcc/ada/libgnat/s-gearop.adb
  cb3a5533d9038f16078dc2c96ea9af4a  gcc/ada/libgnat/s-gearop.ads
! fa9287e534ecd955080d347014606a31  gcc/ada/libgnat/s-genbig.adb
  23caa17005b767020406d5758fe2cb02  gcc/ada/libgnat/s-genbig.ads
  245b86cdfb6f5b2c7e4b1d771dc2ffb8  gcc/ada/libgnat/s-geveop.adb
  0f77fdbf1ddfe614fe464e248db0be4a  gcc/ada/libgnat/s-geveop.ads
*************** a845759ca7545ffe7ea7d86a6a867c69  gcc/ad
*** 2550,2556 ****
  38e48db96a47eb13259c70ae75ac3cf1  gcc/ada/libgnat/s-stoele.ads
  425a5d46fd725b290bc16d8e6a778a9d  gcc/ada/libgnat/s-stopoo.adb
  9324411deb777159107eefa6d17ed9ea  gcc/ada/libgnat/s-stopoo.ads
! 3aebb5ee4350f712d8f571f6326a1f6e  gcc/ada/libgnat/s-stposu.adb
  ea1e1a3f35f2d87d360a6fa148cf942f  gcc/ada/libgnat/s-stposu.ads
  013a1fe809f60910c3103c300c64bd3d  gcc/ada/libgnat/s-stratt.adb
  6c3dfd4ebb852fee1d9774d767dbb81f  gcc/ada/libgnat/s-stratt.ads
--- 2550,2556 ----
  38e48db96a47eb13259c70ae75ac3cf1  gcc/ada/libgnat/s-stoele.ads
  425a5d46fd725b290bc16d8e6a778a9d  gcc/ada/libgnat/s-stopoo.adb
  9324411deb777159107eefa6d17ed9ea  gcc/ada/libgnat/s-stopoo.ads
! 047dfc31ca7ce727605d0a6f4f150fc8  gcc/ada/libgnat/s-stposu.adb
  ea1e1a3f35f2d87d360a6fa148cf942f  gcc/ada/libgnat/s-stposu.ads
  013a1fe809f60910c3103c300c64bd3d  gcc/ada/libgnat/s-stratt.adb
  6c3dfd4ebb852fee1d9774d767dbb81f  gcc/ada/libgnat/s-stratt.ads
*************** b60f965eb0068f4ef9f60362378b0c9e  gcc/ad
*** 2822,2828 ****
  e70e0fe1deaf9153a4884095d153dd82  gcc/ada/sem.ads
  9044b2c904fea0ca89b122ec391975c0  gcc/ada/sem_aggr.adb
  bc71ad0491fa61390ba4b31d799b2dae  gcc/ada/sem_aggr.ads
! aeb43cb4faf5bcec6ef0e0525387f2f0  gcc/ada/sem_attr.adb
  3d50876170b765a588430f4d1cd04558  gcc/ada/sem_attr.ads
  8e42c26d133289bc49008e92fd966b83  gcc/ada/sem_aux.adb
  088bd6652821c1edc3b504cc95da3f42  gcc/ada/sem_aux.ads
--- 2822,2828 ----
  e70e0fe1deaf9153a4884095d153dd82  gcc/ada/sem.ads
  9044b2c904fea0ca89b122ec391975c0  gcc/ada/sem_aggr.adb
  bc71ad0491fa61390ba4b31d799b2dae  gcc/ada/sem_aggr.ads
! 0a5eb8fdbb432d4a190b24ce499c7121  gcc/ada/sem_attr.adb
  3d50876170b765a588430f4d1cd04558  gcc/ada/sem_attr.ads
  8e42c26d133289bc49008e92fd966b83  gcc/ada/sem_aux.adb
  088bd6652821c1edc3b504cc95da3f42  gcc/ada/sem_aux.ads
*************** c156ead71c635cc56cae1c48807cfb5c  gcc/ad
*** 2860,2866 ****
  f978d8f8f0edbaf8c197284638108b29  gcc/ada/sem_disp.ads
  168aef97312277b4f89436222a3460ae  gcc/ada/sem_dist.adb
  8b571ad8113f9236f95206ab1f00a46f  gcc/ada/sem_dist.ads
! 6be9e9d751399d1ef7c1c67316b326e8  gcc/ada/sem_elab.adb
  d1499d742250ba3357ffe435a3bab8b6  gcc/ada/sem_elab.ads
  109d959ed516000de7fd993de2c9ae63  gcc/ada/sem_elim.adb
  3e62676371055aca95243aee2b7afc2b  gcc/ada/sem_elim.ads
--- 2860,2866 ----
  f978d8f8f0edbaf8c197284638108b29  gcc/ada/sem_disp.ads
  168aef97312277b4f89436222a3460ae  gcc/ada/sem_dist.adb
  8b571ad8113f9236f95206ab1f00a46f  gcc/ada/sem_dist.ads
! 10c11965b92836346210e5d24f3bc56c  gcc/ada/sem_elab.adb
  d1499d742250ba3357ffe435a3bab8b6  gcc/ada/sem_elab.ads
  109d959ed516000de7fd993de2c9ae63  gcc/ada/sem_elim.adb
  3e62676371055aca95243aee2b7afc2b  gcc/ada/sem_elim.ads
*************** cd1485ab473af7619af9b0cdb75ff5f4  gcc/ad
*** 2872,2879 ****
  2628f4db0a13a198a497a1438f61ffa9  gcc/ada/sem_mech.ads
  0059c1f573176b8af855bd92c9043dbd  gcc/ada/sem_prag.adb
  2fc94fa1637a92b8548fdb0b65fd7bd4  gcc/ada/sem_prag.ads
! b208560eaf074caaa529eb6a1540df5e  gcc/ada/sem_res.adb
! 8ed4f4454daa145c7fddf86782258422  gcc/ada/sem_res.ads
  e4b6d1e16b208ca35791c42ee9c3d067  gcc/ada/sem_scil.adb
  55301aee52465a299b07b1bb889a8304  gcc/ada/sem_scil.ads
  f8d57c959d78db9bc3e28697e1ec08ca  gcc/ada/sem_smem.adb
--- 2872,2879 ----
  2628f4db0a13a198a497a1438f61ffa9  gcc/ada/sem_mech.ads
  0059c1f573176b8af855bd92c9043dbd  gcc/ada/sem_prag.adb
  2fc94fa1637a92b8548fdb0b65fd7bd4  gcc/ada/sem_prag.ads
! b9f2bcf8a2e20da1295614ec568662fe  gcc/ada/sem_res.adb
! 114fc8d7f5c4c78d983c97f96f06298a  gcc/ada/sem_res.ads
  e4b6d1e16b208ca35791c42ee9c3d067  gcc/ada/sem_scil.adb
  55301aee52465a299b07b1bb889a8304  gcc/ada/sem_scil.ads
  f8d57c959d78db9bc3e28697e1ec08ca  gcc/ada/sem_smem.adb
*************** c639abfea0fd6ce8174c76689f8098b9  gcc/ad
*** 2991,2997 ****
  576518abce20cefac18d69412e741a99  gcc/ada/xutil.ads
  978031793256be605b05ec556e69fc09  gcc/addresses.h
  6104bb06e8b5a16c6679280b8bd89a47  gcc/adjust-alignment.cc
! 01d823a21f405732f330e9f16c9d15e0  gcc/alias.cc
  e1f9606817a872c9b1770a2950665e17  gcc/alias.h
  e2c04eccc631052e7aa15c27e287e593  gcc/align.h
  889f9ffc24064f8ad2fbaf928d50d3e6  gcc/alloc-pool.cc
--- 2991,2997 ----
  576518abce20cefac18d69412e741a99  gcc/ada/xutil.ads
  978031793256be605b05ec556e69fc09  gcc/addresses.h
  6104bb06e8b5a16c6679280b8bd89a47  gcc/adjust-alignment.cc
! 5399373bda895d9c1d70e3e3535e05cb  gcc/alias.cc
  e1f9606817a872c9b1770a2950665e17  gcc/alias.h
  e2c04eccc631052e7aa15c27e287e593  gcc/align.h
  889f9ffc24064f8ad2fbaf928d50d3e6  gcc/alloc-pool.cc
*************** ecfe23b98189d9162eabf34977125e6d  gcc/au
*** 3102,3116 ****
  294ed61d52ae893dd5c09710fe945aca  gcc/btfout.cc
  bbdd0e6a2c558889d7b99c9e61ca5571  gcc/builtin-attrs.def
  cd880946aff3cd75bff1d0edafa92c14  gcc/builtin-types.def
! 64eabaf62f98ec188eff79bd5f9294ff  gcc/builtins.cc
  8a86b0c51f15d3cd6813b9c29784719f  gcc/builtins.def
  92a923d816f64b2130d01c337f74afaa  gcc/builtins.h
! 2ff0bb04dd1e6ea18277066ed76500f2  gcc/c-family/ChangeLog
  ea3fa1f4d7390a105fa3caab4f79aaf7  gcc/c-family/ChangeLog.gimple-classes
  aef14c07c0730693e794681c71142814  gcc/c-family/c-ada-spec.cc
  de8eafcdf817fbea182e701f29a59aa1  gcc/c-family/c-ada-spec.h
  685fbbfc5dd238220e1a87a69c1959f8  gcc/c-family/c-attribs.cc
! 858855870c75d2029a59b182cec44350  gcc/c-family/c-common.cc
  14cc2c078b45b45e351e4ee4453dffe7  gcc/c-family/c-common.def
  5dae9e83d3de07bbde587cb0204b8f57  gcc/c-family/c-common.h
  5ff5aeae6bf668de7d54ae8fc4ce2738  gcc/c-family/c-cppbuiltin.cc
--- 3102,3116 ----
  294ed61d52ae893dd5c09710fe945aca  gcc/btfout.cc
  bbdd0e6a2c558889d7b99c9e61ca5571  gcc/builtin-attrs.def
  cd880946aff3cd75bff1d0edafa92c14  gcc/builtin-types.def
! e537ce4485fe845f3dbda727ab76114e  gcc/builtins.cc
  8a86b0c51f15d3cd6813b9c29784719f  gcc/builtins.def
  92a923d816f64b2130d01c337f74afaa  gcc/builtins.h
! d0334fe4487746c6168d205e97a8cd16  gcc/c-family/ChangeLog
  ea3fa1f4d7390a105fa3caab4f79aaf7  gcc/c-family/ChangeLog.gimple-classes
  aef14c07c0730693e794681c71142814  gcc/c-family/c-ada-spec.cc
  de8eafcdf817fbea182e701f29a59aa1  gcc/c-family/c-ada-spec.h
  685fbbfc5dd238220e1a87a69c1959f8  gcc/c-family/c-attribs.cc
! b33fa0627c278aa7e67bb01612ee9ed7  gcc/c-family/c-common.cc
  14cc2c078b45b45e351e4ee4453dffe7  gcc/c-family/c-common.def
  5dae9e83d3de07bbde587cb0204b8f57  gcc/c-family/c-common.h
  5ff5aeae6bf668de7d54ae8fc4ce2738  gcc/c-family/c-cppbuiltin.cc
*************** b61b11fd774225229263a3340bfa12df  gcc/c-
*** 3136,3142 ****
  8411b634e6ec8162b939e5dcb34197d3  gcc/c-family/c-target-def.h
  049ab05c5422404998ab3673cf18a8ad  gcc/c-family/c-target.def
  f2fccfe3cc85eeb29299baf4e96dee97  gcc/c-family/c-target.h
! beb75e8a7cb114d9af708092226dc0ad  gcc/c-family/c-ubsan.cc
  79e54a900b8b64b90c3eb82e40a758de  gcc/c-family/c-ubsan.h
  a52ef4a4723e7cdac973679710b1eb5b  gcc/c-family/c-warn.cc
  59b4098846e607d14af0bb533d761dd2  gcc/c-family/c.opt
--- 3136,3142 ----
  8411b634e6ec8162b939e5dcb34197d3  gcc/c-family/c-target-def.h
  049ab05c5422404998ab3673cf18a8ad  gcc/c-family/c-target.def
  f2fccfe3cc85eeb29299baf4e96dee97  gcc/c-family/c-target.h
! 07de75c5c82d948b1b9cd8c4a858bfd3  gcc/c-family/c-ubsan.cc
  79e54a900b8b64b90c3eb82e40a758de  gcc/c-family/c-ubsan.h
  a52ef4a4723e7cdac973679710b1eb5b  gcc/c-family/c-warn.cc
  59b4098846e607d14af0bb533d761dd2  gcc/c-family/c.opt
*************** a52ef4a4723e7cdac973679710b1eb5b  gcc/c-
*** 3145,3155 ****
  8ec9a4912d8b3f7d94a11ee04da7517e  gcc/c-family/known-headers.h
  6b3898853ed0b8ac1c9365f8e0da36bd  gcc/c-family/name-hint.h
  78725d6bd115506bafd5753f5e1e3cd0  gcc/c-family/stub-objc.cc
! 206055a3bbabebb16c7cce7160f23367  gcc/c/ChangeLog
  99998984ca5752ab57a30960e8384032  gcc/c/Make-lang.in
  5d00d791728697d48bdf1b6e276ce5bb  gcc/c/c-aux-info.cc
  1c014228ffb2f2191a1ab3cbd03422dc  gcc/c/c-convert.cc
! bf0332b558184c505f6690fc57ac56f7  gcc/c/c-decl.cc
  1d53fd8d8e52cf57a0005164f40c31b7  gcc/c/c-errors.cc
  b425749aff683118700bf07ba9eb0653  gcc/c/c-fold.cc
  36f1771d9957e6a1622b001a02e07e2c  gcc/c/c-lang.cc
--- 3145,3155 ----
  8ec9a4912d8b3f7d94a11ee04da7517e  gcc/c-family/known-headers.h
  6b3898853ed0b8ac1c9365f8e0da36bd  gcc/c-family/name-hint.h
  78725d6bd115506bafd5753f5e1e3cd0  gcc/c-family/stub-objc.cc
! 271a258238b5e143a97bb1e068456d78  gcc/c/ChangeLog
  99998984ca5752ab57a30960e8384032  gcc/c/Make-lang.in
  5d00d791728697d48bdf1b6e276ce5bb  gcc/c/c-aux-info.cc
  1c014228ffb2f2191a1ab3cbd03422dc  gcc/c/c-convert.cc
! c84b848f2335b0a09a4a572c885e9a4c  gcc/c/c-decl.cc
  1d53fd8d8e52cf57a0005164f40c31b7  gcc/c/c-errors.cc
  b425749aff683118700bf07ba9eb0653  gcc/c/c-fold.cc
  36f1771d9957e6a1622b001a02e07e2c  gcc/c/c-lang.cc
*************** d2ee82e91fa150947cec2d680d653ad4  gcc/cf
*** 3178,3184 ****
  650ab513e0404ac58a19e4200f491d8a  gcc/cfgbuild.h
  f58dfd6d19e5f05cdc84465ac491c541  gcc/cfgcleanup.cc
  faf5886336423b3c1589e8b8b55f2cec  gcc/cfgcleanup.h
! 299977530c2ef928dbad03e9a99b7c27  gcc/cfgexpand.cc
  e0f3df5bcd51198c70302a24cfecea78  gcc/cfgexpand.h
  8645e0e85a21570658b7cd0f8b66028b  gcc/cfghooks.cc
  38772c7ea67be80e15630312bda73eba  gcc/cfghooks.h
--- 3178,3184 ----
  650ab513e0404ac58a19e4200f491d8a  gcc/cfgbuild.h
  f58dfd6d19e5f05cdc84465ac491c541  gcc/cfgcleanup.cc
  faf5886336423b3c1589e8b8b55f2cec  gcc/cfgcleanup.h
! 8309cb2f6c945f087269c15a510bb5b6  gcc/cfgexpand.cc
  e0f3df5bcd51198c70302a24cfecea78  gcc/cfgexpand.h
  8645e0e85a21570658b7cd0f8b66028b  gcc/cfghooks.cc
  38772c7ea67be80e15630312bda73eba  gcc/cfghooks.h
*************** b5f4ea42b8d9f3a3c90ebad493a090e4  gcc/cf
*** 3187,3193 ****
  c1c032d2fc3eeaf6c0fa41ca7fa43fd6  gcc/cfgloopanal.cc
  d019cb2ea45f5fa1f8a9cf4c24738ff7  gcc/cfgloopmanip.cc
  19dacb8567e06231de7fe4cc82fe63da  gcc/cfgloopmanip.h
! 747aaa45beb48effaf961370d9c062ce  gcc/cfgrtl.cc
  da68b1c5283ed68c563e46ff6573c10a  gcc/cfgrtl.h
  b69a154b40defaf9e2ab375547199a50  gcc/cgraph.cc
  018a16a4b62363ae44492c72bd779cfa  gcc/cgraph.h
--- 3187,3193 ----
  c1c032d2fc3eeaf6c0fa41ca7fa43fd6  gcc/cfgloopanal.cc
  d019cb2ea45f5fa1f8a9cf4c24738ff7  gcc/cfgloopmanip.cc
  19dacb8567e06231de7fe4cc82fe63da  gcc/cfgloopmanip.h
! 8364160cc3a370f9119277571912cca3  gcc/cfgrtl.cc
  da68b1c5283ed68c563e46ff6573c10a  gcc/cfgrtl.h
  b69a154b40defaf9e2ab375547199a50  gcc/cgraph.cc
  018a16a4b62363ae44492c72bd779cfa  gcc/cgraph.h
*************** a72185fb3571a1a22bbb61fc3b7454f3  gcc/co
*** 3203,3209 ****
  44030d04130f80c7a8b32788a7d2f5e7  gcc/collect2.h
  cb80b744e071259c95e671849491dde2  gcc/color-macros.h
  e2b80b721f5d66e672c4f7978b551172  gcc/combine-stack-adj.cc
! 75f5b587ada82f6d311060854366967c  gcc/combine.cc
  043cecacdd70fa8fef961a26b00040fa  gcc/common.md
  434e51870f06b036b8e82feed2edac9a  gcc/common.opt
  dbdf1cd9a2b5243c1b082761a4401069  gcc/common/common-target-def.h
--- 3203,3209 ----
  44030d04130f80c7a8b32788a7d2f5e7  gcc/collect2.h
  cb80b744e071259c95e671849491dde2  gcc/color-macros.h
  e2b80b721f5d66e672c4f7978b551172  gcc/combine-stack-adj.cc
! 200eb2c2bbcfe35fc40b8519eabcb0c7  gcc/combine.cc
  043cecacdd70fa8fef961a26b00040fa  gcc/common.md
  434e51870f06b036b8e82feed2edac9a  gcc/common.opt
  dbdf1cd9a2b5243c1b082761a4401069  gcc/common/common-target-def.h
*************** f2ee28be11fb50093a5b8b54ed351b61  gcc/co
*** 3215,3221 ****
  d983944b066a9f91d172e604162aec56  gcc/common/config/alpha/alpha-common.cc
  cf52ea7bf51ae49e7e06fa2382572eff  gcc/common/config/arc/arc-common.cc
  84e073cf5e63cefa544a5487559115db  gcc/common/config/arm/arm-common.cc
! f17742b7e09805e3eaeb1632013bab42  gcc/common/config/avr/avr-common.cc
  b6aa06bc7a7bd27c2cb491c7f4fcb99c  gcc/common/config/bfin/bfin-common.cc
  3f4c33e47f1dd32c6a3941e0d29da768  gcc/common/config/bpf/bpf-common.cc
  72f7ae607e7fc2c7741c3c59750bc7de  gcc/common/config/c6x/c6x-common.cc
--- 3215,3221 ----
  d983944b066a9f91d172e604162aec56  gcc/common/config/alpha/alpha-common.cc
  cf52ea7bf51ae49e7e06fa2382572eff  gcc/common/config/arc/arc-common.cc
  84e073cf5e63cefa544a5487559115db  gcc/common/config/arm/arm-common.cc
! 0de3a7a78f5e97e3904fd33cca206dd1  gcc/common/config/avr/avr-common.cc
  b6aa06bc7a7bd27c2cb491c7f4fcb99c  gcc/common/config/bfin/bfin-common.cc
  3f4c33e47f1dd32c6a3941e0d29da768  gcc/common/config/bpf/bpf-common.cc
  72f7ae607e7fc2c7741c3c59750bc7de  gcc/common/config/c6x/c6x-common.cc
*************** bbb86dc26326c9e21536b29093ef0ccd  gcc/co
*** 3264,3270 ****
  08b08b7d10f25136197b98ebe582137e  gcc/compare-elim.cc
  c29a5051809c4038f65af7557c1e9fcd  gcc/conditions.h
  d343cb4b75d4bf1ab6e7001d3ce082eb  gcc/config.build
! 641499d4e856c6f34bd062593ad33ad8  gcc/config.gcc
  0d31f9eb11863dd34b34981d3e4acb3f  gcc/config.host
  5ce7c19d80c83cb13de5fb0dfe3cbca1  gcc/config.in
  8e697813dc96ca90f5d0f4c196efe2cc  gcc/config/README
--- 3264,3270 ----
  08b08b7d10f25136197b98ebe582137e  gcc/compare-elim.cc
  c29a5051809c4038f65af7557c1e9fcd  gcc/conditions.h
  d343cb4b75d4bf1ab6e7001d3ce082eb  gcc/config.build
! 9ce873f4539722bd7cba6114e172a9fe  gcc/config.gcc
  0d31f9eb11863dd34b34981d3e4acb3f  gcc/config.host
  5ce7c19d80c83cb13de5fb0dfe3cbca1  gcc/config.in
  8e697813dc96ca90f5d0f4c196efe2cc  gcc/config/README
*************** d626f1f61bc2d0cad5551d7bb2666b91  gcc/co
*** 3294,3303 ****
  afd3ea5ae83178ba9ef0abc732623c75  gcc/config/aarch64/aarch64-simd-builtins.def
  a8aad92f02ba8729f4cd1b8b3c4efc5f  gcc/config/aarch64/aarch64-simd.md
  0fd01f881e8207e1d6c6521e7122e0a0  gcc/config/aarch64/aarch64-speculation.cc
! 33a2627754cd7f586c413d23113cca3e  gcc/config/aarch64/aarch64-sve-builtins-base.cc
  59c3c335a6c6e57c547fb2e9fef3eef9  gcc/config/aarch64/aarch64-sve-builtins-base.def
  33bd4a836a53e47b04b4c46ba55098c9  gcc/config/aarch64/aarch64-sve-builtins-base.h
! 768e4d9fba61f6fed2d93aa6876abcc2  gcc/config/aarch64/aarch64-sve-builtins-functions.h
  95fba8f677af6b5ce473993252b2e591  gcc/config/aarch64/aarch64-sve-builtins-shapes.cc
  33225ba0ccaf7cef5d184301b71d91f2  gcc/config/aarch64/aarch64-sve-builtins-shapes.h
  fb2af51188d71aa0ad4edbb97be3fe41  gcc/config/aarch64/aarch64-sve-builtins-sve2.cc
--- 3294,3303 ----
  afd3ea5ae83178ba9ef0abc732623c75  gcc/config/aarch64/aarch64-simd-builtins.def
  a8aad92f02ba8729f4cd1b8b3c4efc5f  gcc/config/aarch64/aarch64-simd.md
  0fd01f881e8207e1d6c6521e7122e0a0  gcc/config/aarch64/aarch64-speculation.cc
! b55422ba5d2ac05d9fd2710ffd30ba3f  gcc/config/aarch64/aarch64-sve-builtins-base.cc
  59c3c335a6c6e57c547fb2e9fef3eef9  gcc/config/aarch64/aarch64-sve-builtins-base.def
  33bd4a836a53e47b04b4c46ba55098c9  gcc/config/aarch64/aarch64-sve-builtins-base.h
! 3ef925c8b0f8ce245e440cf959f51dab  gcc/config/aarch64/aarch64-sve-builtins-functions.h
  95fba8f677af6b5ce473993252b2e591  gcc/config/aarch64/aarch64-sve-builtins-shapes.cc
  33225ba0ccaf7cef5d184301b71d91f2  gcc/config/aarch64/aarch64-sve-builtins-shapes.h
  fb2af51188d71aa0ad4edbb97be3fe41  gcc/config/aarch64/aarch64-sve-builtins-sve2.cc
*************** fb2af51188d71aa0ad4edbb97be3fe41  gcc/co
*** 3306,3319 ****
  45d75fc8775a4aa44d49b8571fdf7b29  gcc/config/aarch64/aarch64-sve-builtins.cc
  d944ba1876e827e8299a96fc31433c22  gcc/config/aarch64/aarch64-sve-builtins.def
  4ec15579b7cd3388c4d8eb7117540e35  gcc/config/aarch64/aarch64-sve-builtins.h
! de96fdd9da0d4a9bb48655452dc138c2  gcc/config/aarch64/aarch64-sve.md
  539c5094467274e03fa1ea0087d02d65  gcc/config/aarch64/aarch64-sve2.md
  7110ab6fb22b0e5dc8f7c105640b73f4  gcc/config/aarch64/aarch64-tune.md
  59a2e50c10aa66ea9757d8594c3cb6dc  gcc/config/aarch64/aarch64-tuning-flags.def
  703c876523c318a07e43cdfe4a0a2bee  gcc/config/aarch64/aarch64-vxworks.h
! d32970a53b05552eadc6493e3657fc9d  gcc/config/aarch64/aarch64.cc
  8df0eba1e11a7d9dcc4820353ddc6ba5  gcc/config/aarch64/aarch64.h
! a0a174ab1c6d081490ab52ebf1d0bee1  gcc/config/aarch64/aarch64.md
  27b3d58e07a631b044b51b2920e36271  gcc/config/aarch64/aarch64.opt
  f10e987cf60989a2c0882723035228c8  gcc/config/aarch64/arm_acle.h
  037341ded31b1b6e3ab4e48e63f32185  gcc/config/aarch64/arm_bf16.h
--- 3306,3319 ----
  45d75fc8775a4aa44d49b8571fdf7b29  gcc/config/aarch64/aarch64-sve-builtins.cc
  d944ba1876e827e8299a96fc31433c22  gcc/config/aarch64/aarch64-sve-builtins.def
  4ec15579b7cd3388c4d8eb7117540e35  gcc/config/aarch64/aarch64-sve-builtins.h
! 9a44af0b55f9dc930d1ba4d89dc3eeb1  gcc/config/aarch64/aarch64-sve.md
  539c5094467274e03fa1ea0087d02d65  gcc/config/aarch64/aarch64-sve2.md
  7110ab6fb22b0e5dc8f7c105640b73f4  gcc/config/aarch64/aarch64-tune.md
  59a2e50c10aa66ea9757d8594c3cb6dc  gcc/config/aarch64/aarch64-tuning-flags.def
  703c876523c318a07e43cdfe4a0a2bee  gcc/config/aarch64/aarch64-vxworks.h
! df041521ccd5d43ee927ad2edf1204ed  gcc/config/aarch64/aarch64.cc
  8df0eba1e11a7d9dcc4820353ddc6ba5  gcc/config/aarch64/aarch64.h
! 9a34b88782e645b1f51ad5bf799a9ce5  gcc/config/aarch64/aarch64.md
  27b3d58e07a631b044b51b2920e36271  gcc/config/aarch64/aarch64.opt
  f10e987cf60989a2c0882723035228c8  gcc/config/aarch64/arm_acle.h
  037341ded31b1b6e3ab4e48e63f32185  gcc/config/aarch64/arm_bf16.h
*************** e0d82c4a6ccdb783c299ef853b07a85a  gcc/co
*** 3326,3339 ****
  5d97853bf44cafd1dd5a692c7ecd6d9e  gcc/config/aarch64/check-sve-md.awk
  13907bf624e4b4301887700631c9e355  gcc/config/aarch64/constraints.md
  cb3895773e41ffc0b75ab3f97389f5d5  gcc/config/aarch64/cortex-a57-fma-steering.cc
! c8fca69ee7fa6e445bf2e659cb90f7b4  gcc/config/aarch64/driver-aarch64.cc
  1ccc0238da5ced89db717f38da7987aa  gcc/config/aarch64/falkor-tag-collision-avoidance.cc
  6ea648b863a85cca380d5385687c7249  gcc/config/aarch64/falkor.md
  c89c7b8fec07c5b75e3628a6ee822c1f  gcc/config/aarch64/fractional-cost.h
  47ed472d8ab7676239a8c2afaee00d0c  gcc/config/aarch64/geniterators.sh
  02eca4bc365f9478480ced1203a5fbf8  gcc/config/aarch64/gentune.sh
  86eaf33edeb885c2c9ae2a9825879e59  gcc/config/aarch64/host-aarch64-darwin.cc
! cbc20167372d42d8ad4c6b6f5ef3d54e  gcc/config/aarch64/iterators.md
  3ffffea8efebe8709a5fb79b70ebef56  gcc/config/aarch64/predicates.md
  0cba3aa930062f2526baf26c05de99ce  gcc/config/aarch64/rtems.h
  bfaa30c9cf04a5f4960f9507fb6c93ed  gcc/config/aarch64/saphira.md
--- 3326,3339 ----
  5d97853bf44cafd1dd5a692c7ecd6d9e  gcc/config/aarch64/check-sve-md.awk
  13907bf624e4b4301887700631c9e355  gcc/config/aarch64/constraints.md
  cb3895773e41ffc0b75ab3f97389f5d5  gcc/config/aarch64/cortex-a57-fma-steering.cc
! 1c1636f2a87314dafeb0a31f18680db0  gcc/config/aarch64/driver-aarch64.cc
  1ccc0238da5ced89db717f38da7987aa  gcc/config/aarch64/falkor-tag-collision-avoidance.cc
  6ea648b863a85cca380d5385687c7249  gcc/config/aarch64/falkor.md
  c89c7b8fec07c5b75e3628a6ee822c1f  gcc/config/aarch64/fractional-cost.h
  47ed472d8ab7676239a8c2afaee00d0c  gcc/config/aarch64/geniterators.sh
  02eca4bc365f9478480ced1203a5fbf8  gcc/config/aarch64/gentune.sh
  86eaf33edeb885c2c9ae2a9825879e59  gcc/config/aarch64/host-aarch64-darwin.cc
! f171a70307e9860a97a38e541016da90  gcc/config/aarch64/iterators.md
  3ffffea8efebe8709a5fb79b70ebef56  gcc/config/aarch64/predicates.md
  0cba3aa930062f2526baf26c05de99ce  gcc/config/aarch64/rtems.h
  bfaa30c9cf04a5f4960f9507fb6c93ed  gcc/config/aarch64/saphira.md
*************** a66f3c594c6fc329800e3fb836fdfd26  gcc/co
*** 3439,3447 ****
  604d3b4e6182f09e4a772f53ed92d704  gcc/config/arm/arm-simd-builtin-types.def
  0e7b2ceea31abf677030625bec385ac3  gcc/config/arm/arm-tables.opt
  5a144b12347f9e5cd1b3b8c2fcf8a8a3  gcc/config/arm/arm-tune.md
! 4600e7f254fe7e45c3b912aeac984352  gcc/config/arm/arm.cc
  c14964f7e41f42d7c9bf3b5b0b556ebf  gcc/config/arm/arm.h
! 4b623b84f69c0f93d1212fd10edf4ab5  gcc/config/arm/arm.md
  cf127021475a9bc9dca6dabb24611b52  gcc/config/arm/arm.opt
  ae0d6a7918a07a46e029c0586ebfd584  gcc/config/arm/arm1020e.md
  411234d30435fe643f2aea88d2a73e8c  gcc/config/arm/arm1026ejs.md
--- 3439,3447 ----
  604d3b4e6182f09e4a772f53ed92d704  gcc/config/arm/arm-simd-builtin-types.def
  0e7b2ceea31abf677030625bec385ac3  gcc/config/arm/arm-tables.opt
  5a144b12347f9e5cd1b3b8c2fcf8a8a3  gcc/config/arm/arm-tune.md
! 927c45a49457470411085e1f0908f8d9  gcc/config/arm/arm.cc
  c14964f7e41f42d7c9bf3b5b0b556ebf  gcc/config/arm/arm.h
! 973fbe07473e72230f9d0d07fe63fb92  gcc/config/arm/arm.md
  cf127021475a9bc9dca6dabb24611b52  gcc/config/arm/arm.opt
  ae0d6a7918a07a46e029c0586ebfd584  gcc/config/arm/arm1020e.md
  411234d30435fe643f2aea88d2a73e8c  gcc/config/arm/arm1026ejs.md
*************** e77f7696b58814939d7e7ad921a38f19  gcc/co
*** 3462,3468 ****
  84ecce562f7cb7b7cc93005aac1c1017  gcc/config/arm/arm_vfp_builtins.def
  79ab104de3312f2b4cf0f67d914a2d2b  gcc/config/arm/bpabi.h
  65a7ab5fcf7564784afb364788a4283b  gcc/config/arm/common.md
! dd0f07e4c2335b9e8ee1d77a9ebb20a3  gcc/config/arm/constraints.md
  f6d76c35442b52381ff0dcd26efa83bf  gcc/config/arm/cortex-a15-neon.md
  15f1c652045e6f032a1195b533ddb7ab  gcc/config/arm/cortex-a15.md
  0f5b810c73bc341aee5e91fda44872a5  gcc/config/arm/cortex-a17-neon.md
--- 3462,3468 ----
  84ecce562f7cb7b7cc93005aac1c1017  gcc/config/arm/arm_vfp_builtins.def
  79ab104de3312f2b4cf0f67d914a2d2b  gcc/config/arm/bpabi.h
  65a7ab5fcf7564784afb364788a4283b  gcc/config/arm/common.md
! c4ea8731e72ebe3839945116cb5012e5  gcc/config/arm/constraints.md
  f6d76c35442b52381ff0dcd26efa83bf  gcc/config/arm/cortex-a15-neon.md
  15f1c652045e6f032a1195b533ddb7ab  gcc/config/arm/cortex-a15.md
  0f5b810c73bc341aee5e91fda44872a5  gcc/config/arm/cortex-a17-neon.md
*************** fcd6b308d68cd7bc641bb91e473518bf  gcc/co
*** 3503,3509 ****
  e2efbd2171ce4a6433002f5b9dabc4e6  gcc/config/arm/marvell-f-iwmmxt.md
  de8cd2160d601b4afb431254b804f705  gcc/config/arm/marvell-pj4.md
  be508a7c9d8bb071759bff618b2fbc2c  gcc/config/arm/mmintrin.h
! 77d8b7747068713b7ed1d03e3d4c6fee  gcc/config/arm/mve.md
  34261e480034458c42d06108151b78d8  gcc/config/arm/neon.md
  e092dc54e5e4e06263edfb3ec84d76af  gcc/config/arm/netbsd-eabi.h
  6accf4d7d44501880bfd48b1eb70b05e  gcc/config/arm/netbsd-elf.h
--- 3503,3509 ----
  e2efbd2171ce4a6433002f5b9dabc4e6  gcc/config/arm/marvell-f-iwmmxt.md
  de8cd2160d601b4afb431254b804f705  gcc/config/arm/marvell-pj4.md
  be508a7c9d8bb071759bff618b2fbc2c  gcc/config/arm/mmintrin.h
! 7abd00605ecb1841472250e87bfa8d4f  gcc/config/arm/mve.md
  34261e480034458c42d06108151b78d8  gcc/config/arm/neon.md
  e092dc54e5e4e06263edfb3ec84d76af  gcc/config/arm/netbsd-eabi.h
  6accf4d7d44501880bfd48b1eb70b05e  gcc/config/arm/netbsd-elf.h
*************** dc8e1ff924dd1f2699f60837b792825a  gcc/co
*** 3527,3533 ****
  99532a3b480860f7a66fd99e84508362  gcc/config/arm/t-symbian
  951be86a80be890746abaaf44836bd12  gcc/config/arm/t-vxworks
  3f0d4ea121f03e0f25da9fbf40fda7c7  gcc/config/arm/thumb1.md
! b864052b21701670ce016e2bf0220ed6  gcc/config/arm/thumb2.md
  828cfc365756bb6e28d16660a2722f18  gcc/config/arm/types.md
  8f644b0d696c8000b5b31ac50912783f  gcc/config/arm/uclinux-eabi.h
  53ad55adc5a9fd90930c0335e26244d8  gcc/config/arm/uclinux-elf.h
--- 3527,3533 ----
  99532a3b480860f7a66fd99e84508362  gcc/config/arm/t-symbian
  951be86a80be890746abaaf44836bd12  gcc/config/arm/t-vxworks
  3f0d4ea121f03e0f25da9fbf40fda7c7  gcc/config/arm/thumb1.md
! f48661530894decdbb7d71d2756c0878  gcc/config/arm/thumb2.md
  828cfc365756bb6e28d16660a2722f18  gcc/config/arm/types.md
  8f644b0d696c8000b5b31ac50912783f  gcc/config/arm/uclinux-eabi.h
  53ad55adc5a9fd90930c0335e26244d8  gcc/config/arm/uclinux-elf.h
*************** e7e7ef073cb669f87b1c3d19a818da5f  gcc/co
*** 3535,3541 ****
  81115de2baf547c45bac2d5a9351d0d1  gcc/config/arm/unknown-elf.h
  ba045ad86a2d928edec4dd73916e3bfe  gcc/config/arm/unspecs.md
  d3f86ea670553a63589dd121a82deda4  gcc/config/arm/vec-common.md
! 6b0999f69646c0e1acbf4c59437ddb12  gcc/config/arm/vfp.md
  a373ca0dfe835fe420a8d470352225d5  gcc/config/arm/vfp11.md
  0c48cf1cdfe34e99dab3413a702c4b55  gcc/config/arm/vxworks.h
  19d25b9fb05789a755ec49d65b5d6fcd  gcc/config/arm/vxworks.opt
--- 3535,3541 ----
  81115de2baf547c45bac2d5a9351d0d1  gcc/config/arm/unknown-elf.h
  ba045ad86a2d928edec4dd73916e3bfe  gcc/config/arm/unspecs.md
  d3f86ea670553a63589dd121a82deda4  gcc/config/arm/vec-common.md
! 63d3443fa8e730182ee440dde4b1a6ca  gcc/config/arm/vfp.md
  a373ca0dfe835fe420a8d470352225d5  gcc/config/arm/vfp11.md
  0c48cf1cdfe34e99dab3413a702c4b55  gcc/config/arm/vxworks.h
  19d25b9fb05789a755ec49d65b5d6fcd  gcc/config/arm/vxworks.opt
*************** f4c79e9220e9187c3a843e0a42c1d503  gcc/co
*** 3545,3571 ****
  5ac6143a494b67b2408579331c71c89a  gcc/config/avr/avr-c.cc
  1f1b24bccebced685f22675a39d03550  gcc/config/avr/avr-devices.cc
  45d01b1a247cd92dd44c4bc361a97321  gcc/config/avr/avr-dimode.md
! 708f772e2588821bfa91118474a89d0a  gcc/config/avr/avr-fixed.md
  c3ab3d8980033cd869c1c27b318115ce  gcc/config/avr/avr-log.cc
! 301062653b41a8bc14b7342f09f9a32a  gcc/config/avr/avr-mcus.def
  69b36d3d75fa8c748a6f1c843d6888f7  gcc/config/avr/avr-modes.def
  9126e9ec7dee9b9d66f6893bb9926647  gcc/config/avr/avr-passes.def
  0e3f58ff86af5534419a0e0fb1a552a1  gcc/config/avr/avr-protos.h
  55c51229f13ced0bdddbfd397c9a57d4  gcc/config/avr/avr-stdint.h
! 86ba0b159451932a8735d4422011f882  gcc/config/avr/avr.cc
! 800f7501f0eacfee1c1b717e491085b2  gcc/config/avr/avr.h
! 43fee9a758fe7d37f8c47f01e9eb6fad  gcc/config/avr/avr.md
  154dcf10de2f21666b4516257fbcecd2  gcc/config/avr/avr.opt
  d5ca1928fb0eef4a39e419faa25782b4  gcc/config/avr/avrlibc.h
  82e55abb13cdee932b88cb4c074f76fe  gcc/config/avr/builtins.def
  f0880103f5af621d5051b6b0ef710ba1  gcc/config/avr/constraints.md
  751bd406a3dcc3e4cc452b962e925114  gcc/config/avr/driver-avr.cc
! 828f146c096d2950c6ab263bc3818e13  gcc/config/avr/elf.h
  7dea2902f1765bf0a4a6483fadb36c32  gcc/config/avr/gen-avr-mmcu-specs.cc
  bcef8a3e0aed8ec9bca46e7c98959588  gcc/config/avr/gen-avr-mmcu-texi.cc
  b66a49b68d591a6c0b7af5fc6a368c25  gcc/config/avr/genmultilib.awk
  bcf32309fb3db2a9d7062f64b15abd3a  gcc/config/avr/predicates.md
! 55f61938445efff9a372e6135a536342  gcc/config/avr/specs.h
  a90b049a5422ac5aa92130f8d01d1a39  gcc/config/avr/stdfix.h
  5f9b9e751722dbcab353617d7f7521a1  gcc/config/avr/t-avr
  17266d6ea4ed538b3d9b230711b7213f  gcc/config/bfin/bfin-modes.def
--- 3545,3571 ----
  5ac6143a494b67b2408579331c71c89a  gcc/config/avr/avr-c.cc
  1f1b24bccebced685f22675a39d03550  gcc/config/avr/avr-devices.cc
  45d01b1a247cd92dd44c4bc361a97321  gcc/config/avr/avr-dimode.md
! 88c70dbe14ec8bf9fc4bf0c2506de8e4  gcc/config/avr/avr-fixed.md
  c3ab3d8980033cd869c1c27b318115ce  gcc/config/avr/avr-log.cc
! 82d18b02b662531290604c811b5cd303  gcc/config/avr/avr-mcus.def
  69b36d3d75fa8c748a6f1c843d6888f7  gcc/config/avr/avr-modes.def
  9126e9ec7dee9b9d66f6893bb9926647  gcc/config/avr/avr-passes.def
  0e3f58ff86af5534419a0e0fb1a552a1  gcc/config/avr/avr-protos.h
  55c51229f13ced0bdddbfd397c9a57d4  gcc/config/avr/avr-stdint.h
! f5c2f17f7344ec1d55919512ee02ac4e  gcc/config/avr/avr.cc
! 04b344cc6e8130b10c0d465be571bce6  gcc/config/avr/avr.h
! 35250616ce3da36c62ec7beb6dc3f78b  gcc/config/avr/avr.md
  154dcf10de2f21666b4516257fbcecd2  gcc/config/avr/avr.opt
  d5ca1928fb0eef4a39e419faa25782b4  gcc/config/avr/avrlibc.h
  82e55abb13cdee932b88cb4c074f76fe  gcc/config/avr/builtins.def
  f0880103f5af621d5051b6b0ef710ba1  gcc/config/avr/constraints.md
  751bd406a3dcc3e4cc452b962e925114  gcc/config/avr/driver-avr.cc
! e385867b49fdaa675228e06994b0aba3  gcc/config/avr/elf.h
  7dea2902f1765bf0a4a6483fadb36c32  gcc/config/avr/gen-avr-mmcu-specs.cc
  bcef8a3e0aed8ec9bca46e7c98959588  gcc/config/avr/gen-avr-mmcu-texi.cc
  b66a49b68d591a6c0b7af5fc6a368c25  gcc/config/avr/genmultilib.awk
  bcf32309fb3db2a9d7062f64b15abd3a  gcc/config/avr/predicates.md
! 54e187fda60b9580910b0954e5506955  gcc/config/avr/specs.h
  a90b049a5422ac5aa92130f8d01d1a39  gcc/config/avr/stdfix.h
  5f9b9e751722dbcab353617d7f7521a1  gcc/config/avr/t-avr
  17266d6ea4ed538b3d9b230711b7213f  gcc/config/bfin/bfin-modes.def
*************** cd03b988a7bd186e66210d7bb24d12ed  gcc/co
*** 3668,3680 ****
  92e09d436d26dd5f2e2b2090dba422ce  gcc/config/csky/t-csky-linux
  b62a47b77dccb47ce687a46ca17cec43  gcc/config/darwin-c.cc
  2556b4330fdb56e9355a33998b8b94d3  gcc/config/darwin-d.cc
! 09733777605726a19bf8f3de69b594e3  gcc/config/darwin-driver.cc
  3c146a1c17fda17c760cd5672fb5a5a8  gcc/config/darwin-f.cc
  7b2dacd23f2809fe6462e592b6ff5744  gcc/config/darwin-ppc-ldouble-patch.def
  39a0c9fb5dd1e1cfc368f3b0778f07f9  gcc/config/darwin-protos.h
  a581ffcfe57fc085bb14fed30225dcf4  gcc/config/darwin-sections.def
  017d51eec9cabc9e51025a6ced560872  gcc/config/darwin.cc
! 3108516175e16c24ce25dfe9aff7e7c8  gcc/config/darwin.h
  2d0c2e46036e1142674c71c1683e5029  gcc/config/darwin.opt
  e995cbf40e93284ca4ad4576deae0b57  gcc/config/default-c.cc
  d492599e2fe59e667eb069826c292f25  gcc/config/default-d.cc
--- 3668,3680 ----
  92e09d436d26dd5f2e2b2090dba422ce  gcc/config/csky/t-csky-linux
  b62a47b77dccb47ce687a46ca17cec43  gcc/config/darwin-c.cc
  2556b4330fdb56e9355a33998b8b94d3  gcc/config/darwin-d.cc
! b94a11b865dc6eab463f931fbd7e0cad  gcc/config/darwin-driver.cc
  3c146a1c17fda17c760cd5672fb5a5a8  gcc/config/darwin-f.cc
  7b2dacd23f2809fe6462e592b6ff5744  gcc/config/darwin-ppc-ldouble-patch.def
  39a0c9fb5dd1e1cfc368f3b0778f07f9  gcc/config/darwin-protos.h
  a581ffcfe57fc085bb14fed30225dcf4  gcc/config/darwin-sections.def
  017d51eec9cabc9e51025a6ced560872  gcc/config/darwin.cc
! 1d2e23f7731f51448fa4124c6e381d79  gcc/config/darwin.h
  2d0c2e46036e1142674c71c1683e5029  gcc/config/darwin.opt
  e995cbf40e93284ca4ad4576deae0b57  gcc/config/default-c.cc
  d492599e2fe59e667eb069826c292f25  gcc/config/default-d.cc
*************** ed52c14ae2117a1e2218b99326e827f7  gcc/co
*** 3759,3765 ****
  84710268000799a6e443185c65b5083e  gcc/config/gnu-d.cc
  66b5cf864ec6eee452dbe2a23c5f63b8  gcc/config/gnu-user.h
  e678ec61caa08addb752cf31cf39ea19  gcc/config/gnu-user.opt
! df334611bfceb7de93b71522186c97a8  gcc/config/gnu.h
  614bb3102b667d8f96684dddffd1f625  gcc/config/h8300/addsub.md
  cddc64825ce6e6e92692684251745f9e  gcc/config/h8300/bitfield.md
  7e3877c14e73e7008a634518dea17e1a  gcc/config/h8300/combiner.md
--- 3759,3765 ----
  84710268000799a6e443185c65b5083e  gcc/config/gnu-d.cc
  66b5cf864ec6eee452dbe2a23c5f63b8  gcc/config/gnu-user.h
  e678ec61caa08addb752cf31cf39ea19  gcc/config/gnu-user.opt
! b28807777f9e860e17fc11e4075ea340  gcc/config/gnu.h
  614bb3102b667d8f96684dddffd1f625  gcc/config/h8300/addsub.md
  cddc64825ce6e6e92692684251745f9e  gcc/config/h8300/bitfield.md
  7e3877c14e73e7008a634518dea17e1a  gcc/config/h8300/combiner.md
*************** e7804843eb0a64776c47655d24acd9d3  gcc/co
*** 3799,3809 ****
  96509d4dd1922555873784e523a931a2  gcc/config/hpux11.opt
  55883df46978a976c938c240c6dce165  gcc/config/i386/adxintrin.h
  c062d8c4f543cce10ae4bbb7c220a765  gcc/config/i386/ammintrin.h
! b2f4aad298263f48f1ac8a7ad50e6f53  gcc/config/i386/amxbf16intrin.h
! 1e1e5e7dc305e186cdbf59e26f4150d7  gcc/config/i386/amxcomplexintrin.h
! d66542a1143209ed7ff609cc1351aad2  gcc/config/i386/amxfp16intrin.h
! f7ec04b3ae6ab0665561d3c64e2a8eb6  gcc/config/i386/amxint8intrin.h
! 710bcde235c4c970360614b8d64e43d7  gcc/config/i386/amxtileintrin.h
  5ad8113f98b3741dba255479fb0b4c5c  gcc/config/i386/athlon.md
  e34a8bf10542af8efc22acbb32ee2fdd  gcc/config/i386/atom.md
  f15918dfd12bc1857aa07367503167fd  gcc/config/i386/att.h
--- 3799,3809 ----
  96509d4dd1922555873784e523a931a2  gcc/config/hpux11.opt
  55883df46978a976c938c240c6dce165  gcc/config/i386/adxintrin.h
  c062d8c4f543cce10ae4bbb7c220a765  gcc/config/i386/ammintrin.h
! 1ebdef82889f963ca636efeedbb9ee6a  gcc/config/i386/amxbf16intrin.h
! 76796585df87ec00edd1fec62f6f30f9  gcc/config/i386/amxcomplexintrin.h
! d089463f6dbb00952fd8a032a51933de  gcc/config/i386/amxfp16intrin.h
! 6e291af09734149dc285f2eae63da382  gcc/config/i386/amxint8intrin.h
! d828301502cc56bceb366834dd36c2ea  gcc/config/i386/amxtileintrin.h
  5ad8113f98b3741dba255479fb0b4c5c  gcc/config/i386/athlon.md
  e34a8bf10542af8efc22acbb32ee2fdd  gcc/config/i386/atom.md
  f15918dfd12bc1857aa07367503167fd  gcc/config/i386/att.h
*************** e92e6092340e3f2f41fe23e91d749ca0  gcc/co
*** 3903,3909 ****
  362075d5c55c01a58a8688d152965d39  gcc/config/i386/haswell.md
  519fbd902e6476af80fccdd9c3ddf609  gcc/config/i386/host-cygwin.cc
  6e90fcf8b884d9635ab934026d3f144e  gcc/config/i386/host-i386-darwin.cc
! 43ba62e2c05246010d29bc459f648c78  gcc/config/i386/host-mingw32.cc
  c712f75327bcb8b5d026dfb3dea205df  gcc/config/i386/hresetintrin.h
  05b81cca7926b1d1ab6ed9ad1de53cf0  gcc/config/i386/i386-builtin-types.awk
  3d2082f02d6f85c1c7931b78a04b1f0e  gcc/config/i386/i386-builtin-types.def
--- 3903,3909 ----
  362075d5c55c01a58a8688d152965d39  gcc/config/i386/haswell.md
  519fbd902e6476af80fccdd9c3ddf609  gcc/config/i386/host-cygwin.cc
  6e90fcf8b884d9635ab934026d3f144e  gcc/config/i386/host-i386-darwin.cc
! 1123075e817d3b43f7b97c0cca2f0607  gcc/config/i386/host-mingw32.cc
  c712f75327bcb8b5d026dfb3dea205df  gcc/config/i386/hresetintrin.h
  05b81cca7926b1d1ab6ed9ad1de53cf0  gcc/config/i386/i386-builtin-types.awk
  3d2082f02d6f85c1c7931b78a04b1f0e  gcc/config/i386/i386-builtin-types.def
*************** c712f75327bcb8b5d026dfb3dea205df  gcc/co
*** 3913,3919 ****
  93a35614595edc9f907a159250600af9  gcc/config/i386/i386-c.cc
  111cfdf2d21796a75b1dc6dad85b1e0b  gcc/config/i386/i386-d.cc
  8a2fd04b87d1c3d5e2c0f09d28bbbabb  gcc/config/i386/i386-d.h
! 67e1a5ddd4239a486c722dacc7385c51  gcc/config/i386/i386-expand.cc
  41a8f20de760a6af6575dd59a61d9d53  gcc/config/i386/i386-expand.h
  9239e5c6dba5eb6506ce40c23c41c768  gcc/config/i386/i386-features.cc
  1e007dd2e12b7cf3a6530dd879fb3f1c  gcc/config/i386/i386-features.h
--- 3913,3919 ----
  93a35614595edc9f907a159250600af9  gcc/config/i386/i386-c.cc
  111cfdf2d21796a75b1dc6dad85b1e0b  gcc/config/i386/i386-d.cc
  8a2fd04b87d1c3d5e2c0f09d28bbbabb  gcc/config/i386/i386-d.h
! 114f069a49516181c72911b3fd66aaaf  gcc/config/i386/i386-expand.cc
  41a8f20de760a6af6575dd59a61d9d53  gcc/config/i386/i386-expand.h
  9239e5c6dba5eb6506ce40c23c41c768  gcc/config/i386/i386-features.cc
  1e007dd2e12b7cf3a6530dd879fb3f1c  gcc/config/i386/i386-features.h
*************** ffb1b3ecba72997c3e6804714698295d  gcc/co
*** 3924,3932 ****
  7512d54a6f733ab8b39bf9b02c1ba4db  gcc/config/i386/i386-opts.h
  3d980f6dc86b67acb7d8e5be6c08c589  gcc/config/i386/i386-passes.def
  15146e6cff34da8c1205b0df0813ccb0  gcc/config/i386/i386-protos.h
! 37411c56abf14704d70f5f8934f354ea  gcc/config/i386/i386.cc
! ea1b2e9630b4be0a48c861f84f8b8226  gcc/config/i386/i386.h
! 132edee19206a270c6ab9a859fa5eea8  gcc/config/i386/i386.md
  c32251e85ab598cb51e89383639566bb  gcc/config/i386/i386.opt
  faa318618e52a0740019e9aa0764b007  gcc/config/i386/i386elf.h
  7c89dc80159b83f67c1fa47a10c88c13  gcc/config/i386/ia32intrin.h
--- 3924,3932 ----
  7512d54a6f733ab8b39bf9b02c1ba4db  gcc/config/i386/i386-opts.h
  3d980f6dc86b67acb7d8e5be6c08c589  gcc/config/i386/i386-passes.def
  15146e6cff34da8c1205b0df0813ccb0  gcc/config/i386/i386-protos.h
! ecf823696e56603700033a07f131f0b3  gcc/config/i386/i386.cc
! 0c9ab892c366f3f64c88a3562987a4ba  gcc/config/i386/i386.h
! 0a5e515326725afb3814eed4db734b2c  gcc/config/i386/i386.md
  c32251e85ab598cb51e89383639566bb  gcc/config/i386/i386.opt
  faa318618e52a0740019e9aa0764b007  gcc/config/i386/i386elf.h
  7c89dc80159b83f67c1fa47a10c88c13  gcc/config/i386/ia32intrin.h
*************** f71c2e5572561a74ea464ac5e46b48e9  gcc/co
*** 3986,3995 ****
  9ac8a2404b744a4725303bcaa6eb18ee  gcc/config/i386/slm.md
  78848cd4caaf8dc8240bd6c097488abe  gcc/config/i386/smmintrin.h
  f636ec0022d2efe9257b23fc816e2b32  gcc/config/i386/sol2.h
! f240cd1fbe1582422e3bbba0d220cb98  gcc/config/i386/sse.md
  d5e445dfcfe76b4409b1d6a2115663fc  gcc/config/i386/ssemath.h
  0547e7c6a1807f6096d1ef483c6f9c13  gcc/config/i386/stringop.def
! 5e04bf034cc99782faa1edf2d7d26383  gcc/config/i386/subst.md
  945c6888d50080573fad6f6c8969b67f  gcc/config/i386/sym-mingw32.cc
  5927dc15e6d5c74d087d26beb013139d  gcc/config/i386/sync.md
  2d4c630f2726c23bf8ece1af1e9f5655  gcc/config/i386/sysv4.h
--- 3986,3995 ----
  9ac8a2404b744a4725303bcaa6eb18ee  gcc/config/i386/slm.md
  78848cd4caaf8dc8240bd6c097488abe  gcc/config/i386/smmintrin.h
  f636ec0022d2efe9257b23fc816e2b32  gcc/config/i386/sol2.h
! 1397c1a3a6cf2677265e37218e25b0e5  gcc/config/i386/sse.md
  d5e445dfcfe76b4409b1d6a2115663fc  gcc/config/i386/ssemath.h
  0547e7c6a1807f6096d1ef483c6f9c13  gcc/config/i386/stringop.def
! 7f1f93f5d11321776da8577466be14e3  gcc/config/i386/subst.md
  945c6888d50080573fad6f6c8969b67f  gcc/config/i386/sym-mingw32.cc
  5927dc15e6d5c74d087d26beb013139d  gcc/config/i386/sync.md
  2d4c630f2726c23bf8ece1af1e9f5655  gcc/config/i386/sysv4.h
*************** b4cde95b709fc93c90bf4d6b3edc7fd0  gcc/co
*** 4041,4054 ****
  ceeba8f332c332a7db03815dd3144457  gcc/config/i386/x86-tune-sched-atom.cc
  cf77688a79e9eb5530fb5a30f8ead444  gcc/config/i386/x86-tune-sched-bd.cc
  30bef3dbd64dfc29211a442df4597f25  gcc/config/i386/x86-tune-sched-core.cc
! 45245aff4235c8461409871e7e5070af  gcc/config/i386/x86-tune-sched.cc
! 5873f6de94f7f02a908186234d8a56fb  gcc/config/i386/x86-tune.def
  bd48650a48294465d345812ad5e1b4e8  gcc/config/i386/x86gprintrin.h
  9bbe408d1dc406ddf72aa175ea24a4ab  gcc/config/i386/x86intrin.h
  8262b37347a6f221be8fda380c23e595  gcc/config/i386/xm-cygwin.h
  be0b0f2d6bbac5aa9acc0aa9ca9939bb  gcc/config/i386/xm-djgpp.h
  5a5edc97dfee054c50445d3976a1f593  gcc/config/i386/xm-mingw32.h
! e20d725be97ea6dcf6d6796132a2fe44  gcc/config/i386/xmmintrin.h
  a215229c735d32f3d01211350fd1f318  gcc/config/i386/xopintrin.h
  389521d349b62cd9a6946fee844e5397  gcc/config/i386/xsavecintrin.h
  90f4cdaf601934d2d661a2b054020133  gcc/config/i386/xsaveintrin.h
--- 4041,4054 ----
  ceeba8f332c332a7db03815dd3144457  gcc/config/i386/x86-tune-sched-atom.cc
  cf77688a79e9eb5530fb5a30f8ead444  gcc/config/i386/x86-tune-sched-bd.cc
  30bef3dbd64dfc29211a442df4597f25  gcc/config/i386/x86-tune-sched-core.cc
! 2ce2f57723a06c770361888ae4adb027  gcc/config/i386/x86-tune-sched.cc
! f322f4891aa00eb9359d5d043e6e04d9  gcc/config/i386/x86-tune.def
  bd48650a48294465d345812ad5e1b4e8  gcc/config/i386/x86gprintrin.h
  9bbe408d1dc406ddf72aa175ea24a4ab  gcc/config/i386/x86intrin.h
  8262b37347a6f221be8fda380c23e595  gcc/config/i386/xm-cygwin.h
  be0b0f2d6bbac5aa9acc0aa9ca9939bb  gcc/config/i386/xm-djgpp.h
  5a5edc97dfee054c50445d3976a1f593  gcc/config/i386/xm-mingw32.h
! d85c963da68aa4a5c72b4faabd0cd6b6  gcc/config/i386/xmmintrin.h
  a215229c735d32f3d01211350fd1f318  gcc/config/i386/xopintrin.h
  389521d349b62cd9a6946fee844e5397  gcc/config/i386/xsavecintrin.h
  90f4cdaf601934d2d661a2b054020133  gcc/config/i386/xsaveintrin.h
*************** bbcb9180a6500397530127e9345b90fc  gcc/co
*** 4116,4122 ****
  a9d1d80c40cc6eb8e9a32d54f82dae43  gcc/config/lm32/t-lm32
  660559cdac2b08e91486a9db7b4a2872  gcc/config/lm32/t-rtems
  8ef085012d9493b632c484a8fb32b403  gcc/config/lm32/uclinux-elf.h
! 8417e1e84ade261be3883c9b991c14a6  gcc/config/loongarch/constraints.md
  db93094f0d4b754b9521b7a08ff59eb3  gcc/config/loongarch/generic.md
  56ef1e2b8eb28fe4018b37a6a9a6f26e  gcc/config/loongarch/genopts/genstr.sh
  9ce5785ab5a5194757c33063bafb644b  gcc/config/loongarch/genopts/loongarch-strings
--- 4116,4122 ----
  a9d1d80c40cc6eb8e9a32d54f82dae43  gcc/config/lm32/t-lm32
  660559cdac2b08e91486a9db7b4a2872  gcc/config/lm32/t-rtems
  8ef085012d9493b632c484a8fb32b403  gcc/config/lm32/uclinux-elf.h
! 5a2c3555fd5e58a03702f6cab9bf47a0  gcc/config/loongarch/constraints.md
  db93094f0d4b754b9521b7a08ff59eb3  gcc/config/loongarch/generic.md
  56ef1e2b8eb28fe4018b37a6a9a6f26e  gcc/config/loongarch/genopts/genstr.sh
  9ce5785ab5a5194757c33063bafb644b  gcc/config/loongarch/genopts/loongarch-strings
*************** a5a8ae397bdf9e20c3426ef156508e74  gcc/co
*** 4137,4150 ****
  ae7cfcf36635345c7a6629d3bfbb53d6  gcc/config/loongarch/loongarch-modes.def
  a12887e2d76caaa13e14ecd486af32d8  gcc/config/loongarch/loongarch-opts.cc
  5a7e634f3067a9d7102737f15a2762c2  gcc/config/loongarch/loongarch-opts.h
! 0a2ea88aa9d8b16199a929903fe1420e  gcc/config/loongarch/loongarch-protos.h
  b7e7ae8ebef609fa5b3638fc6d8da01c  gcc/config/loongarch/loongarch-str.h
  1d43515673828076071c491e3cdd6f1f  gcc/config/loongarch/loongarch-tune.h
! 0604e558b65c0a185caf86ec71780386  gcc/config/loongarch/loongarch.cc
  a1b94a398a7e906ba7b8e6f3bc0e7839  gcc/config/loongarch/loongarch.h
! 1092d0af6bbdeeebaf276d6b403a51fc  gcc/config/loongarch/loongarch.md
  a9bcbd6c03a77e0c5c0b70d652aa908e  gcc/config/loongarch/loongarch.opt
! 2f8826252720e1086662bde87ecbe35f  gcc/config/loongarch/predicates.md
  9ae896f20aba612b39f17b74e0e88d42  gcc/config/loongarch/sync.md
  b99456ed262c9decb8e975492dece6b9  gcc/config/loongarch/t-linux
  2cb1531abdf14df62c1e88e14377d454  gcc/config/loongarch/t-loongarch
--- 4137,4150 ----
  ae7cfcf36635345c7a6629d3bfbb53d6  gcc/config/loongarch/loongarch-modes.def
  a12887e2d76caaa13e14ecd486af32d8  gcc/config/loongarch/loongarch-opts.cc
  5a7e634f3067a9d7102737f15a2762c2  gcc/config/loongarch/loongarch-opts.h
! 1300afa201a794ce7aef6311bf010154  gcc/config/loongarch/loongarch-protos.h
  b7e7ae8ebef609fa5b3638fc6d8da01c  gcc/config/loongarch/loongarch-str.h
  1d43515673828076071c491e3cdd6f1f  gcc/config/loongarch/loongarch-tune.h
! 00ff6e894d712223ed852337a52bb181  gcc/config/loongarch/loongarch.cc
  a1b94a398a7e906ba7b8e6f3bc0e7839  gcc/config/loongarch/loongarch.h
! 818998d98333ae2d5c5822cd3d6e8662  gcc/config/loongarch/loongarch.md
  a9bcbd6c03a77e0c5c0b70d652aa908e  gcc/config/loongarch/loongarch.opt
! 1ad122ed816eec75657abe494e2e0b83  gcc/config/loongarch/predicates.md
  9ae896f20aba612b39f17b74e0e88d42  gcc/config/loongarch/sync.md
  b99456ed262c9decb8e975492dece6b9  gcc/config/loongarch/t-linux
  2cb1531abdf14df62c1e88e14377d454  gcc/config/loongarch/t-loongarch
*************** e2a5b46a69472ea8c1b02e68518c0831  gcc/co
*** 4287,4300 ****
  ac7b52c7fc21bb9196eee41f2f0dc65a  gcc/config/mips/mips-dsp.md
  d7c7d648633e3751538d001af47d7dc0  gcc/config/mips/mips-dspr2.md
  c2cfe00ae73a68f07ce649b980612c9c  gcc/config/mips/mips-fixed.md
! c08e4bab6c1e75a72083a45020a5b446  gcc/config/mips/mips-ftypes.def
  78532a885490fb3a90b0c4a85437f2e1  gcc/config/mips/mips-modes.def
  fbe407e03794a9ee607663ce7de6eadb  gcc/config/mips/mips-msa.md
  30376b626fc9050218641fcde797c92f  gcc/config/mips/mips-opts.h
  b6ef595c9b75af5e5679a8799c944443  gcc/config/mips/mips-protos.h
  32ba594f8a210398a1e585dfcc8b1d8d  gcc/config/mips/mips-ps-3d.md
  e0f0f7f5cd3f66adff43ada64fd352e1  gcc/config/mips/mips-tables.opt
! 36265b8f606076aae7dc7221733043d1  gcc/config/mips/mips.cc
  9e3bffdb2b33a326178eddd2138674d0  gcc/config/mips/mips.h
  fd1a1985d2fa9e92b6867215ad4b9127  gcc/config/mips/mips.md
  3b233a9733cc91ecbf6950b871004528  gcc/config/mips/mips.opt
--- 4287,4300 ----
  ac7b52c7fc21bb9196eee41f2f0dc65a  gcc/config/mips/mips-dsp.md
  d7c7d648633e3751538d001af47d7dc0  gcc/config/mips/mips-dspr2.md
  c2cfe00ae73a68f07ce649b980612c9c  gcc/config/mips/mips-fixed.md
! 42a377d9bf35d532317346ab82352a7c  gcc/config/mips/mips-ftypes.def
  78532a885490fb3a90b0c4a85437f2e1  gcc/config/mips/mips-modes.def
  fbe407e03794a9ee607663ce7de6eadb  gcc/config/mips/mips-msa.md
  30376b626fc9050218641fcde797c92f  gcc/config/mips/mips-opts.h
  b6ef595c9b75af5e5679a8799c944443  gcc/config/mips/mips-protos.h
  32ba594f8a210398a1e585dfcc8b1d8d  gcc/config/mips/mips-ps-3d.md
  e0f0f7f5cd3f66adff43ada64fd352e1  gcc/config/mips/mips-tables.opt
! 5f7a010c33a78d3b3266a09a5bc96512  gcc/config/mips/mips.cc
  9e3bffdb2b33a326178eddd2138674d0  gcc/config/mips/mips.h
  fd1a1985d2fa9e92b6867215ad4b9127  gcc/config/mips/mips.md
  3b233a9733cc91ecbf6950b871004528  gcc/config/mips/mips.opt
*************** c8af08e2d69d3942ed3fa6f40a02be9b  gcc/co
*** 4517,4525 ****
  d6ed3ea0b084fce25b744c74274588a5  gcc/config/pa/pa-openbsd.h
  e90c5d0d138f683915e32d52840e42cc  gcc/config/pa/pa-opts.h
  6d7f17931666ea98e5793e2f41c93ac3  gcc/config/pa/pa-protos.h
! 6a43f63b7f89c5ed6bcfccf2b6f36676  gcc/config/pa/pa.cc
  765c3a4331887e13e7e4d4df4747b59b  gcc/config/pa/pa.h
! f875aa50d58ae06c01348a46110d9c45  gcc/config/pa/pa.md
  20ba6e16f7d2cf5e5eb89348793f2610  gcc/config/pa/pa.opt
  5268cfc61e7af09cd3b9ba6d2fa3faff  gcc/config/pa/pa32-linux.h
  c14312e902452e23e82cf7aea2550044  gcc/config/pa/pa32-netbsd.h
--- 4517,4525 ----
  d6ed3ea0b084fce25b744c74274588a5  gcc/config/pa/pa-openbsd.h
  e90c5d0d138f683915e32d52840e42cc  gcc/config/pa/pa-opts.h
  6d7f17931666ea98e5793e2f41c93ac3  gcc/config/pa/pa-protos.h
! c633d974174bdb76ed46a210048c5ed1  gcc/config/pa/pa.cc
  765c3a4331887e13e7e4d4df4747b59b  gcc/config/pa/pa.h
! f6bd48f3298d21b1fd29bb4bc1aeb436  gcc/config/pa/pa.md
  20ba6e16f7d2cf5e5eb89348793f2610  gcc/config/pa/pa.opt
  5268cfc61e7af09cd3b9ba6d2fa3faff  gcc/config/pa/pa32-linux.h
  c14312e902452e23e82cf7aea2550044  gcc/config/pa/pa32-netbsd.h
*************** d910da6919ac5db4583b4c606a2a94e5  gcc/co
*** 4647,4659 ****
  331273395372eddd12e125c743ba20b0  gcc/config/rs6000/8540.md
  0574596a3aa61f5ed67581712ce8a431  gcc/config/rs6000/a2.md
  7066cb868f097d4aedbe42b4de90f4ca  gcc/config/rs6000/aix-stdint.h
! 13f319aa5c2928f7ad24baf9da2ac70e  gcc/config/rs6000/aix.h
  bd35332d6b4881a6b7c1887edcbc4760  gcc/config/rs6000/aix64.opt
  b4ae894c7649abb1dc14070d9797b00d  gcc/config/rs6000/aix71.h
  43cf8f7978a5d583e2342acb04cc595b  gcc/config/rs6000/aix72.h
  a87be9ee98a714eeeb92bad73f32f88f  gcc/config/rs6000/aix73.h
  02b877a569032dd21efb85d41dac9c4f  gcc/config/rs6000/altivec.h
! 071400944dc417db4ed74d3288710a61  gcc/config/rs6000/altivec.md
  347774e3882e15d0157b143fa1f2df42  gcc/config/rs6000/amo.h
  656fb98293d82a76779be75ae8207857  gcc/config/rs6000/biarch64.h
  8eb9a873478c1238a6d5921b1c5ed77e  gcc/config/rs6000/bmi2intrin.h
--- 4647,4659 ----
  331273395372eddd12e125c743ba20b0  gcc/config/rs6000/8540.md
  0574596a3aa61f5ed67581712ce8a431  gcc/config/rs6000/a2.md
  7066cb868f097d4aedbe42b4de90f4ca  gcc/config/rs6000/aix-stdint.h
! 7499b04f22446e843be2add460f747f1  gcc/config/rs6000/aix.h
  bd35332d6b4881a6b7c1887edcbc4760  gcc/config/rs6000/aix64.opt
  b4ae894c7649abb1dc14070d9797b00d  gcc/config/rs6000/aix71.h
  43cf8f7978a5d583e2342acb04cc595b  gcc/config/rs6000/aix72.h
  a87be9ee98a714eeeb92bad73f32f88f  gcc/config/rs6000/aix73.h
  02b877a569032dd21efb85d41dac9c4f  gcc/config/rs6000/altivec.h
! f7a177877fafe47947dbc04e176c52bb  gcc/config/rs6000/altivec.md
  347774e3882e15d0157b143fa1f2df42  gcc/config/rs6000/amo.h
  656fb98293d82a76779be75ae8207857  gcc/config/rs6000/biarch64.h
  8eb9a873478c1238a6d5921b1c5ed77e  gcc/config/rs6000/bmi2intrin.h
*************** ed576fb9a2ba561b17ab61f2a9bfe17f  gcc/co
*** 4832,4838 ****
  c7d2c6e9b07c780b3b02da4f5165316e  gcc/config/s390/s390-opts.h
  5871932ed4c83ad11e5593250b1e04a4  gcc/config/s390/s390-passes.def
  5d7bff78c36ce807dbd9be40c035eb93  gcc/config/s390/s390-protos.h
! e54e3503384dfd75a6f2e548bc9c0917  gcc/config/s390/s390.cc
  0889a37d3bd6fd89b5ac6ae2d35ecee4  gcc/config/s390/s390.h
  0479677f52785f8340cf7b1d5fab5bc2  gcc/config/s390/s390.md
  7eeb85e77191dec9449c41ad7680f212  gcc/config/s390/s390.opt
--- 4832,4838 ----
  c7d2c6e9b07c780b3b02da4f5165316e  gcc/config/s390/s390-opts.h
  5871932ed4c83ad11e5593250b1e04a4  gcc/config/s390/s390-passes.def
  5d7bff78c36ce807dbd9be40c035eb93  gcc/config/s390/s390-protos.h
! 4132dc1fe8bb871edb1d61f3ab31511c  gcc/config/s390/s390.cc
  0889a37d3bd6fd89b5ac6ae2d35ecee4  gcc/config/s390/s390.h
  0479677f52785f8340cf7b1d5fab5bc2  gcc/config/s390/s390.md
  7eeb85e77191dec9449c41ad7680f212  gcc/config/s390/s390.opt
*************** dafa05de62e4f5bb6c9b7a2ffb7a55df  gcc/co
*** 4869,4875 ****
  4515312140f2002feb7cd75134f2c396  gcc/config/sh/sh-protos.h
  8688af86f284a2353424ec768bfdf7ac  gcc/config/sh/sh.cc
  37b97b8797def6afb72ea964a453eca5  gcc/config/sh/sh.h
! cb421e48d5ee6f1a768564c1b2975300  gcc/config/sh/sh.md
  b5bc1e3d906715c2267ae3b833e714a8  gcc/config/sh/sh.opt
  3a51dff173dae73355e8cad1f8bd5866  gcc/config/sh/sh1.md
  8980e2d146877b565a494bb33095eb9e  gcc/config/sh/sh4-300.md
--- 4869,4875 ----
  4515312140f2002feb7cd75134f2c396  gcc/config/sh/sh-protos.h
  8688af86f284a2353424ec768bfdf7ac  gcc/config/sh/sh.cc
  37b97b8797def6afb72ea964a453eca5  gcc/config/sh/sh.h
! 88a623b955db46385f18108dc768de9f  gcc/config/sh/sh.md
  b5bc1e3d906715c2267ae3b833e714a8  gcc/config/sh/sh.opt
  3a51dff173dae73355e8cad1f8bd5866  gcc/config/sh/sh1.md
  8980e2d146877b565a494bb33095eb9e  gcc/config/sh/sh4-300.md
*************** c02c2e60a2b7403e97217854b6697545  gcc/co
*** 5007,5013 ****
  8f8e1b1a1dc2614e0b2b036dd47fb5bc  gcc/config/vax/vax-protos.h
  b44ad2f7c6bccd8179fbeb0c77a09f40  gcc/config/vax/vax.cc
  4a28295dcd9cad1669329908a7982023  gcc/config/vax/vax.h
! 00059b8f723cd17f61829ad0b035118e  gcc/config/vax/vax.md
  41d56a166600eba6041cd52c0e1fedfd  gcc/config/vax/vax.opt
  1d6ede1e8b576a8ff0cc70391c119740  gcc/config/visium/constraints.md
  b709eba0a7e411322054701a24a1c12d  gcc/config/visium/elf.h
--- 5007,5013 ----
  8f8e1b1a1dc2614e0b2b036dd47fb5bc  gcc/config/vax/vax-protos.h
  b44ad2f7c6bccd8179fbeb0c77a09f40  gcc/config/vax/vax.cc
  4a28295dcd9cad1669329908a7982023  gcc/config/vax/vax.h
! 12369021e85aafda46d56c3157de32cf  gcc/config/vax/vax.md
  41d56a166600eba6041cd52c0e1fedfd  gcc/config/vax/vax.opt
  1d6ede1e8b576a8ff0cc70391c119740  gcc/config/visium/constraints.md
  b709eba0a7e411322054701a24a1c12d  gcc/config/visium/elf.h
*************** a92be6f532ece352cab8309520cf28f0  gcc/co
*** 5089,5095 ****
  6614aac0ce8960f693faf880a7560bc5  gcc/coroutine-passes.cc
  9d6931fedff9a87a6266d15841579e67  gcc/coverage.cc
  b964f4291cd58a61a06769149429435f  gcc/coverage.h
! e28e384b6677cf52a6e0794e2030c2a5  gcc/cp/ChangeLog
  d271e3663538ba1f3281cab3838e92cd  gcc/cp/ChangeLog-1993
  f5a44adbc05521162350ca409d1d95ce  gcc/cp/ChangeLog-1994
  ac55db48d964cb5469ff03c1cd3ee04d  gcc/cp/ChangeLog-1995
--- 5089,5095 ----
  6614aac0ce8960f693faf880a7560bc5  gcc/coroutine-passes.cc
  9d6931fedff9a87a6266d15841579e67  gcc/coverage.cc
  b964f4291cd58a61a06769149429435f  gcc/coverage.h
! 3d477a7882e5c9f6b0fb95e48ba463d4  gcc/cp/ChangeLog
  d271e3663538ba1f3281cab3838e92cd  gcc/cp/ChangeLog-1993
  f5a44adbc05521162350ca409d1d95ce  gcc/cp/ChangeLog-1994
  ac55db48d964cb5469ff03c1cd3ee04d  gcc/cp/ChangeLog-1995
*************** d9b5ec86750c5cd59daf7a5aae58585b  gcc/cp
*** 5128,5134 ****
  896d83eec5aaaa6e6d65eaf91d39d283  gcc/cp/cfns.h
  0b2a03d49770c4eace1cd0be60ee4b69  gcc/cp/class.cc
  b0062ee9c9d42ee91eaf7512f6e1e0be  gcc/cp/config-lang.in
! 08921b99d388726f86b809fbbce118ef  gcc/cp/constexpr.cc
  edccbdb3f4c2f1f4d32e807cb29e3c40  gcc/cp/constraint.cc
  da0483e6a5389a7d06c30a4f41b34d48  gcc/cp/contracts.cc
  3fff7a95b0ebd54a1f3f2b2ace365aae  gcc/cp/contracts.h
--- 5128,5134 ----
  896d83eec5aaaa6e6d65eaf91d39d283  gcc/cp/cfns.h
  0b2a03d49770c4eace1cd0be60ee4b69  gcc/cp/class.cc
  b0062ee9c9d42ee91eaf7512f6e1e0be  gcc/cp/config-lang.in
! c93cafe127c9905ede0b4600896f5b4a  gcc/cp/constexpr.cc
  edccbdb3f4c2f1f4d32e807cb29e3c40  gcc/cp/constraint.cc
  da0483e6a5389a7d06c30a4f41b34d48  gcc/cp/contracts.cc
  3fff7a95b0ebd54a1f3f2b2ace365aae  gcc/cp/contracts.h
*************** ebeaa808f85fa8a261591cd99ad1e7b0  gcc/cp
*** 5142,5148 ****
  d6887ccac1e3a9dea9c2908ef57ec747  gcc/cp/cp-tree.def
  6607508a527a2e0df92d89ddffb2b518  gcc/cp/cp-tree.h
  b65da920bdc209a44d1cba37f4a1e4a7  gcc/cp/cp-ubsan.cc
! c1554fda460dfa5f48a6851603bd9332  gcc/cp/cvt.cc
  0f2a998ba44768f9ca6fbf7c608096bb  gcc/cp/cxx-pretty-print.cc
  e0aeb037cb4d8ca738781ded46d00a5d  gcc/cp/cxx-pretty-print.h
  434b32d34aae1276a754296e20dbe8d9  gcc/cp/cxxapi-data.csv
--- 5142,5148 ----
  d6887ccac1e3a9dea9c2908ef57ec747  gcc/cp/cp-tree.def
  6607508a527a2e0df92d89ddffb2b518  gcc/cp/cp-tree.h
  b65da920bdc209a44d1cba37f4a1e4a7  gcc/cp/cp-ubsan.cc
! 0c6e811dbccfa5db5f519601c1a77140  gcc/cp/cvt.cc
  0f2a998ba44768f9ca6fbf7c608096bb  gcc/cp/cxx-pretty-print.cc
  e0aeb037cb4d8ca738781ded46d00a5d  gcc/cp/cxx-pretty-print.h
  434b32d34aae1276a754296e20dbe8d9  gcc/cp/cxxapi-data.csv
*************** ad0139bc4d542f2e5abe2c0adedf3a07  gcc/cp
*** 5150,5167 ****
  04eca9fc6dc327f816ff062ad8e899a5  gcc/cp/decl.h
  7382d510c21a206975eaf2dbec80e7c7  gcc/cp/decl2.cc
  c00489cd7633dcb8caed5defda9fdc95  gcc/cp/dump.cc
! 1bcab327fe1f6fb1402f82439488dce5  gcc/cp/error.cc
  84cc118eb988fc2b48cffcc665159d9c  gcc/cp/except.cc
  15a221742a7bc56a599ea1bf93e7e0b0  gcc/cp/expr.cc
  281fa9e99941b10d92e580b8d8b19a97  gcc/cp/friend.cc
  38d795f01430a0d433f133d955f161f4  gcc/cp/g++spec.cc
  aae4769663c02dfe48e64b7622706074  gcc/cp/gen-cxxapi-file.py
  9b4f175743b46b3ce1e48901dda38b97  gcc/cp/init.cc
! 6bd222a6b8cbe1c6cc29ff623d02ab70  gcc/cp/lambda.cc
  0c9e7039d9e6c649820e714e1877a4c3  gcc/cp/lang-specs.h
  f6faa21098c86eb47a6c838ddfcdca1b  gcc/cp/lex.cc
  0aa2860fccee2e2e75b2e00297d0f39f  gcc/cp/logic.cc
! 0a56c4f22a02c37dda3fe049724c2181  gcc/cp/mangle.cc
  c7cdcc0d91396db6f388061dec91b1bb  gcc/cp/mapper-client.cc
  73e96c254c4c826c654b7a43099710d0  gcc/cp/mapper-client.h
  ad0c37db747b2c38777b4746b7e9ccd8  gcc/cp/mapper-resolver.cc
--- 5150,5167 ----
  04eca9fc6dc327f816ff062ad8e899a5  gcc/cp/decl.h
  7382d510c21a206975eaf2dbec80e7c7  gcc/cp/decl2.cc
  c00489cd7633dcb8caed5defda9fdc95  gcc/cp/dump.cc
! 2b997011dd87eaa3164fec2800531e4b  gcc/cp/error.cc
  84cc118eb988fc2b48cffcc665159d9c  gcc/cp/except.cc
  15a221742a7bc56a599ea1bf93e7e0b0  gcc/cp/expr.cc
  281fa9e99941b10d92e580b8d8b19a97  gcc/cp/friend.cc
  38d795f01430a0d433f133d955f161f4  gcc/cp/g++spec.cc
  aae4769663c02dfe48e64b7622706074  gcc/cp/gen-cxxapi-file.py
  9b4f175743b46b3ce1e48901dda38b97  gcc/cp/init.cc
! 7cb1d8045f0ebde7a9477347b622a1cb  gcc/cp/lambda.cc
  0c9e7039d9e6c649820e714e1877a4c3  gcc/cp/lang-specs.h
  f6faa21098c86eb47a6c838ddfcdca1b  gcc/cp/lex.cc
  0aa2860fccee2e2e75b2e00297d0f39f  gcc/cp/logic.cc
! 47fbb2a6802d98d25a2aba47c73fc76f  gcc/cp/mangle.cc
  c7cdcc0d91396db6f388061dec91b1bb  gcc/cp/mapper-client.cc
  73e96c254c4c826c654b7a43099710d0  gcc/cp/mapper-client.h
  ad0c37db747b2c38777b4746b7e9ccd8  gcc/cp/mapper-resolver.cc
*************** eba9d2541aa4aa5f8a8e7aa169c9d594  gcc/cp
*** 5171,5189 ****
  340bb6c30bc1451bc4e2aee47ac22c19  gcc/cp/name-lookup.h
  8cef47f00b2658d60aa8aeac08d34464  gcc/cp/operators.def
  7037f63acd4161418cc8dcd1d86866e0  gcc/cp/optimize.cc
! 233f423f1efad6a65da7b34342f3a2d9  gcc/cp/parser.cc
  fbb3d4644cdc4c0c8d47620a0b3a8094  gcc/cp/parser.h
! ea1aa35d4cd4b7c23cf5da64052c2179  gcc/cp/pt.cc
  d03dc5c4f806d6a6841801d7d7d0080c  gcc/cp/ptree.cc
  aba5829381a2a8991e36ebb8d4eb9761  gcc/cp/rtti.cc
  88eb1ceb39a66b26decf9af394a4f5c2  gcc/cp/search.cc
! 43d87713204e7f945875e8ab10ff89a3  gcc/cp/semantics.cc
  6ee0fac37bab072bf0804b3f1dfb78f1  gcc/cp/std-name-hint.gperf
  f46ba3abf12a9521b0a8ac2aac5e8373  gcc/cp/std-name-hint.h
! bde75ae2e2dc98ce0d7ebbb2e49e70c1  gcc/cp/tree.cc
  48f7db9af3b30491ed4f238605782993  gcc/cp/type-utils.h
! bd758da929d27a010b0a933dbc9ab2dd  gcc/cp/typeck.cc
! b08fff9701626891fd78d4b60a5b2b83  gcc/cp/typeck2.cc
  d1622a9e8d6f8df6c5834932b9488b97  gcc/cp/vtable-class-hierarchy.cc
  2597401b7544997a7f6e4811a977c2c8  gcc/cppbuiltin.cc
  ec059990dce01decdd41fdf61eb21678  gcc/cppbuiltin.h
--- 5171,5189 ----
  340bb6c30bc1451bc4e2aee47ac22c19  gcc/cp/name-lookup.h
  8cef47f00b2658d60aa8aeac08d34464  gcc/cp/operators.def
  7037f63acd4161418cc8dcd1d86866e0  gcc/cp/optimize.cc
! 31af1271743bda5277b267bf355e9660  gcc/cp/parser.cc
  fbb3d4644cdc4c0c8d47620a0b3a8094  gcc/cp/parser.h
! c992cc845e944d76179acb69133dc298  gcc/cp/pt.cc
  d03dc5c4f806d6a6841801d7d7d0080c  gcc/cp/ptree.cc
  aba5829381a2a8991e36ebb8d4eb9761  gcc/cp/rtti.cc
  88eb1ceb39a66b26decf9af394a4f5c2  gcc/cp/search.cc
! a845888c4112b1f7a26bbc34395db534  gcc/cp/semantics.cc
  6ee0fac37bab072bf0804b3f1dfb78f1  gcc/cp/std-name-hint.gperf
  f46ba3abf12a9521b0a8ac2aac5e8373  gcc/cp/std-name-hint.h
! 11d6b362e5f4fd712545bacca326269e  gcc/cp/tree.cc
  48f7db9af3b30491ed4f238605782993  gcc/cp/type-utils.h
! 7215ff50e495a6ca69b479a32ef74dbd  gcc/cp/typeck.cc
! 5a3dfd99b7b810797ae18af3b0ff886e  gcc/cp/typeck2.cc
  d1622a9e8d6f8df6c5834932b9488b97  gcc/cp/vtable-class-hierarchy.cc
  2597401b7544997a7f6e4811a977c2c8  gcc/cppbuiltin.cc
  ec059990dce01decdd41fdf61eb21678  gcc/cppbuiltin.h
*************** aec47cbaec48561e260557f0682793cf  gcc/cs
*** 5197,5203 ****
  a667c8581cf5009d6af17f19f1186065  gcc/ctfc.cc
  9881edbbb726db4859766d0a32beb6a7  gcc/ctfc.h
  744cafae198aaa990e1c303aa66f0504  gcc/ctfout.cc
! bfdb4adbd0ba2933f14b00bc7057f7a2  gcc/d/ChangeLog
  86f687c485111eedca2eb048294f957e  gcc/d/ChangeLog-2006
  70ed1c47fd9b3f5dd95055642ed79265  gcc/d/ChangeLog-2007
  a7090ab2dd83aa4f44823c17566b83ef  gcc/d/ChangeLog-2008
--- 5197,5203 ----
  a667c8581cf5009d6af17f19f1186065  gcc/ctfc.cc
  9881edbbb726db4859766d0a32beb6a7  gcc/ctfc.h
  744cafae198aaa990e1c303aa66f0504  gcc/ctfout.cc
! fe4ad520a2c1a78cb16592302f68c328  gcc/d/ChangeLog
  86f687c485111eedca2eb048294f957e  gcc/d/ChangeLog-2006
  70ed1c47fd9b3f5dd95055642ed79265  gcc/d/ChangeLog-2007
  a7090ab2dd83aa4f44823c17566b83ef  gcc/d/ChangeLog-2008
*************** c7b625d76017d2ec4f8970c167523c57  gcc/d/
*** 5220,5226 ****
  758e5fe316e70ac29cdf3b2f894655eb  gcc/d/config-lang.in
  85746b2dfddc127a55b01ebb697bf36d  gcc/d/d-attribs.cc
  8348e5c20fb3ad49d06d69cffb935c47  gcc/d/d-builtins.cc
! 62ea809eb84816d478adf86ee577874c  gcc/d/d-codegen.cc
  971f4804175b7a391dcd1281695fa5a2  gcc/d/d-compiler.cc
  6677da531b8c8e5f00f6772e6c4a0ed4  gcc/d/d-convert.cc
  d2b1f01e0988dcd39d9447e3e7178798  gcc/d/d-ctfloat.cc
--- 5220,5226 ----
  758e5fe316e70ac29cdf3b2f894655eb  gcc/d/config-lang.in
  85746b2dfddc127a55b01ebb697bf36d  gcc/d/d-attribs.cc
  8348e5c20fb3ad49d06d69cffb935c47  gcc/d/d-builtins.cc
! 08b2ccb618a79c25e97bc9fc1c8e6c56  gcc/d/d-codegen.cc
  971f4804175b7a391dcd1281695fa5a2  gcc/d/d-compiler.cc
  6677da531b8c8e5f00f6772e6c4a0ed4  gcc/d/d-convert.cc
  d2b1f01e0988dcd39d9447e3e7178798  gcc/d/d-ctfloat.cc
*************** eed95c64afa2c5152ed24f9e036c8558  gcc/d/
*** 5232,5238 ****
  ce6b33dda672c5a4dd51d395bb584cb5  gcc/d/d-lang.cc
  ef961ae9fa4971d839f64528e0a37ae0  gcc/d/d-longdouble.cc
  3681feafef438df6cf30a76d70231ab9  gcc/d/d-port.cc
! 185499ceba21feb6f33c538ec84ccc2b  gcc/d/d-spec.cc
  3d5fc447a9af0885c21b752580606718  gcc/d/d-system.h
  702fee3dac729038fda2766339cd7526  gcc/d/d-target-def.h
  fbc8000ee222d6ad5a0e1c6e84a312d4  gcc/d/d-target.cc
--- 5232,5238 ----
  ce6b33dda672c5a4dd51d395bb584cb5  gcc/d/d-lang.cc
  ef961ae9fa4971d839f64528e0a37ae0  gcc/d/d-longdouble.cc
  3681feafef438df6cf30a76d70231ab9  gcc/d/d-port.cc
! 0fd914e5960f7132da6673bb0eca25fe  gcc/d/d-spec.cc
  3d5fc447a9af0885c21b752580606718  gcc/d/d-system.h
  702fee3dac729038fda2766339cd7526  gcc/d/d-target-def.h
  fbc8000ee222d6ad5a0e1c6e84a312d4  gcc/d/d-target.cc
*************** fbc8000ee222d6ad5a0e1c6e84a312d4  gcc/d/
*** 5240,5246 ****
  0ef8ddb83bcd9713cc0bc91299edff2c  gcc/d/d-target.h
  df7deb9723aa01d867aaeec5d746c208  gcc/d/d-tree.def
  8bb261b53d8eeeb70c0c97ed965aacc2  gcc/d/d-tree.h
! 647b3e7b67ae9032b1716758b451426d  gcc/d/decl.cc
  2d7446d51cf4738aad1c8ceb43174a72  gcc/d/dmd/MERGE
  39fa65f9345bb0319180e90c1912a1ae  gcc/d/dmd/README.md
  dde7939f1c35c9e979832ac123e5692f  gcc/d/dmd/VERSION
--- 5240,5246 ----
  0ef8ddb83bcd9713cc0bc91299edff2c  gcc/d/d-target.h
  df7deb9723aa01d867aaeec5d746c208  gcc/d/d-tree.def
  8bb261b53d8eeeb70c0c97ed965aacc2  gcc/d/d-tree.h
! 10679d8c044e7de01ceb4eda974b70ee  gcc/d/decl.cc
  2d7446d51cf4738aad1c8ceb43174a72  gcc/d/dmd/MERGE
  39fa65f9345bb0319180e90c1912a1ae  gcc/d/dmd/README.md
  dde7939f1c35c9e979832ac123e5692f  gcc/d/dmd/VERSION
*************** c9a7dddb98d89035d4e0853147d7fb06  gcc/d/
*** 5415,5421 ****
  0e19f04aef543d4fabb6ec79def5b2df  gcc/d/dmd/version.h
  f9c518566ad51d0492965951bb50bc49  gcc/d/dmd/visitor.d
  0479d55eda5ee9de0e2106ae722ad649  gcc/d/dmd/visitor.h
! 88ab8c337e2d8355f94eb5fdf72cfe5d  gcc/d/expr.cc
  7c8d068883546d6053ab89a4aa3ad55c  gcc/d/gdc.texi
  09d8459a6a0334281c058ddbf35b079a  gcc/d/implement-d.texi
  52b373830c8db1956184db3d7c644eed  gcc/d/imports.cc
--- 5415,5421 ----
  0e19f04aef543d4fabb6ec79def5b2df  gcc/d/dmd/version.h
  f9c518566ad51d0492965951bb50bc49  gcc/d/dmd/visitor.d
  0479d55eda5ee9de0e2106ae722ad649  gcc/d/dmd/visitor.h
! 2e190cbfbe74120be172eb485523e225  gcc/d/expr.cc
  7c8d068883546d6053ab89a4aa3ad55c  gcc/d/gdc.texi
  09d8459a6a0334281c058ddbf35b079a  gcc/d/implement-d.texi
  52b373830c8db1956184db3d7c644eed  gcc/d/imports.cc
*************** a21521366267b1a7b68ceb6ce15a9246  gcc/d/
*** 5427,5435 ****
  5251baac92e17d12efc1de93cbfe6ba5  gcc/d/modules.cc
  b1d8cca7f88b3b7a419bdaad940457c0  gcc/d/runtime.cc
  7fbf81ad217c5efa6f267572778e7ab8  gcc/d/runtime.def
! 48b3a4ef1af87b926e52c50d3bc81595  gcc/d/toir.cc
  168e3e721d8dc43fb9d250ca847af79a  gcc/d/typeinfo.cc
! d36c80c26768a485a06631dbc94be775  gcc/d/types.cc
  accc2d7f211bb139fde71fcb94dbbf92  gcc/data-streamer-in.cc
  888eb4c7a007875545f7f89fa223643c  gcc/data-streamer-out.cc
  047c64792c9f1e60b4b6498df8817c94  gcc/data-streamer.cc
--- 5427,5435 ----
  5251baac92e17d12efc1de93cbfe6ba5  gcc/d/modules.cc
  b1d8cca7f88b3b7a419bdaad940457c0  gcc/d/runtime.cc
  7fbf81ad217c5efa6f267572778e7ab8  gcc/d/runtime.def
! 94e59e9f9adf115478148e8ffd079d8e  gcc/d/toir.cc
  168e3e721d8dc43fb9d250ca847af79a  gcc/d/typeinfo.cc
! 9c046db86e0710d26de7518fdee18595  gcc/d/types.cc
  accc2d7f211bb139fde71fcb94dbbf92  gcc/data-streamer-in.cc
  888eb4c7a007875545f7f89fa223643c  gcc/data-streamer-out.cc
  047c64792c9f1e60b4b6498df8817c94  gcc/data-streamer.cc
*************** b5cf698f62fc897667ca73b3cf884ea2  gcc/di
*** 5463,5475 ****
  1ef25caa15e3cb5ab9492b923312e4cc  gcc/diagnostic-spec.cc
  0aa96cf64ff55c2058c4f77d12b1f9b7  gcc/diagnostic-spec.h
  aec86f5bdff3085fdd00d7f8271d8bd0  gcc/diagnostic-url.h
! 5f9e7d5e357718ba41664aa23b032e18  gcc/diagnostic.cc
  d80c9704cdea98d063f65ef7fae04621  gcc/diagnostic.def
  e927561ee87ffd471419ab7c04a9c03d  gcc/diagnostic.h
  768604617d8710f1848e11fd6d4f6713  gcc/digraph.cc
  1309ef041fe49676049fddd61225f25e  gcc/digraph.h
  ed4a41716cd834ae3e0120f4e94f21f6  gcc/doc/analyzer.texi
! 042775b60723e8f420675b84d19dbec6  gcc/doc/avr-mmcu.texi
  b55159f9c9fbeadedbd6a971434bef5e  gcc/doc/bugreport.texi
  97af20afa0c976df424f847ab0e7072d  gcc/doc/cfg.texi
  8784212b864de1903df4a7574095012f  gcc/doc/collect2.texi
--- 5463,5475 ----
  1ef25caa15e3cb5ab9492b923312e4cc  gcc/diagnostic-spec.cc
  0aa96cf64ff55c2058c4f77d12b1f9b7  gcc/diagnostic-spec.h
  aec86f5bdff3085fdd00d7f8271d8bd0  gcc/diagnostic-url.h
! b1d90cf99a7654fe89cb862a50d30e6f  gcc/diagnostic.cc
  d80c9704cdea98d063f65ef7fae04621  gcc/diagnostic.def
  e927561ee87ffd471419ab7c04a9c03d  gcc/diagnostic.h
  768604617d8710f1848e11fd6d4f6713  gcc/digraph.cc
  1309ef041fe49676049fddd61225f25e  gcc/digraph.h
  ed4a41716cd834ae3e0120f4e94f21f6  gcc/doc/analyzer.texi
! 57f7f634d014a76f1c96e2054de2d5a1  gcc/doc/avr-mmcu.texi
  b55159f9c9fbeadedbd6a971434bef5e  gcc/doc/bugreport.texi
  97af20afa0c976df424f847ab0e7072d  gcc/doc/cfg.texi
  8784212b864de1903df4a7574095012f  gcc/doc/collect2.texi
*************** ab5a29a444213b7a4b7edbae0720adf0  gcc/do
*** 5478,5524 ****
  8c23b33261e6d434a3bb388d13bf9750  gcc/doc/configterms.texi
  41fe29b312b42ee001aa367476b9444e  gcc/doc/contrib.texi
  42159646cb48b375710fd78e3dd6e6b4  gcc/doc/contribute.texi
! 35a0bc4c81e09b037af53e1a78b063fd  gcc/doc/cpp.1
! 32db0c54c279a68e8856d7b1f2c3915c  gcc/doc/cpp.info
  587fd46d043d4c91fa743bf32451859c  gcc/doc/cpp.texi
  417eef489bd26f8def602795e86741fa  gcc/doc/cppdiropts.texi
  2011321798f5e6d57961e25563305e06  gcc/doc/cppenv.texi
! 285e8a199dd7f9c4a06f98fa0f38cd37  gcc/doc/cppinternals.info
  60a3fa41bf1f6e279008366c78cb007c  gcc/doc/cppinternals.texi
  8d68aa98b0af8010285255a92aea623d  gcc/doc/cppopts.texi
  50173f3902d3d3c6e3bdb1a4f9044352  gcc/doc/cppwarnopts.texi
  c99b8f869f34a5dd9cd46d59a3a76ae4  gcc/doc/extend.texi
  9da857d64fdcfd6b1982a75cf86bc597  gcc/doc/fragments.texi
  e3892bc4361a803d8c568c54c20cbcd9  gcc/doc/frontends.texi
! 2da924ddbb453b05a019b926a62577c2  gcc/doc/fsf-funding.7
! 0e07810bb7ccdac8559fbda78f8476bd  gcc/doc/g++.1
! 0e07810bb7ccdac8559fbda78f8476bd  gcc/doc/gcc.1
! 9b57a59b8eb0ebd5d5b75463a5677434  gcc/doc/gcc.info
  295291ec7baa70b04da2b1b6ecffee99  gcc/doc/gcc.texi
! 91f4d873caa77d8686116b28aeedc564  gcc/doc/gccgo.1
! d8d743e3a7186baedfcc9d31fed204a1  gcc/doc/gccgo.info
! b732036db666d1191019593ac6523278  gcc/doc/gccinstall.info
! acdc2ae3b7fdbcb55c232d018c65732e  gcc/doc/gccint.info
  edc0e7584ec44bfd909e0126057141b2  gcc/doc/gccint.texi
! 421d09dddb138c6adf182dc547c8d63a  gcc/doc/gcov-dump.1
  8cbf639fe99f374f9e305a031d0d6736  gcc/doc/gcov-dump.texi
! 7a7df0aea396a3d759256110c2b127f8  gcc/doc/gcov-tool.1
  a4e8708b41fe686d6ecdc5246226e3e3  gcc/doc/gcov-tool.texi
! c33983d1cc3499723848c0a3847f2aac  gcc/doc/gcov.1
  ccaf4e1393ac66805b8317145261710e  gcc/doc/gcov.texi
! 6378832f3814a025c819e59543b98559  gcc/doc/gdc.1
! f233a58cb023243d48e8d8d85fab4dc6  gcc/doc/gdc.info
  87c3d3669bc27263b6c7fc5d7fdd7c28  gcc/doc/generic.texi
! 63a7f74b4aadcbc3843a474690c7d943  gcc/doc/gfdl.7
! 995d523e49e3cb045615de39f6c8dafc  gcc/doc/gfortran.1
  5630240c5ef619f03fc1bd750bde7b61  gcc/doc/gimple.texi
! c1c3d9cf0456a61410af3092abd21bae  gcc/doc/gm2.1
  8c5e921b4436013be7b3d375620753f6  gcc/doc/gm2.texi
! 28d5c30df0c36abc0041d609cc15a9f4  gcc/doc/gnat-style.info
! 93b5cac01e32d4af83387f86e0d4d40f  gcc/doc/gnat_rm.info
! 2b449ebb58ae2949cf09dc6c9031f726  gcc/doc/gnat_ugn.info
  dc4ccd9843d88bc01c909438dabfd6ab  gcc/doc/gnu.texi
! f6b3263ab1e5301cb6fa8a9f0a687779  gcc/doc/gpl.7
  9c051a6abfe79317ad83904f042d2738  gcc/doc/gty.texi
  42ebfb9fc08dafdae427760be5354428  gcc/doc/headerdirs.texi
  971cd503a0a7fde3063283de000ba2ea  gcc/doc/hostconfig.texi
--- 5478,5524 ----
  8c23b33261e6d434a3bb388d13bf9750  gcc/doc/configterms.texi
  41fe29b312b42ee001aa367476b9444e  gcc/doc/contrib.texi
  42159646cb48b375710fd78e3dd6e6b4  gcc/doc/contribute.texi
! 790d8362909e93778263f654dd8b3cc0  gcc/doc/cpp.1
! 59ff99e0f8e90b3b9de8690bb637b228  gcc/doc/cpp.info
  587fd46d043d4c91fa743bf32451859c  gcc/doc/cpp.texi
  417eef489bd26f8def602795e86741fa  gcc/doc/cppdiropts.texi
  2011321798f5e6d57961e25563305e06  gcc/doc/cppenv.texi
! 62a2f6360eaa0bfb4685667028efd799  gcc/doc/cppinternals.info
  60a3fa41bf1f6e279008366c78cb007c  gcc/doc/cppinternals.texi
  8d68aa98b0af8010285255a92aea623d  gcc/doc/cppopts.texi
  50173f3902d3d3c6e3bdb1a4f9044352  gcc/doc/cppwarnopts.texi
  c99b8f869f34a5dd9cd46d59a3a76ae4  gcc/doc/extend.texi
  9da857d64fdcfd6b1982a75cf86bc597  gcc/doc/fragments.texi
  e3892bc4361a803d8c568c54c20cbcd9  gcc/doc/frontends.texi
! edd93ba0b70a3b460e9e00efc65b2b85  gcc/doc/fsf-funding.7
! 0f2a2bb7ef7b636d058782eebf220923  gcc/doc/g++.1
! 0f2a2bb7ef7b636d058782eebf220923  gcc/doc/gcc.1
! d6501419f18c4ccf4b5f5404b9c6228b  gcc/doc/gcc.info
  295291ec7baa70b04da2b1b6ecffee99  gcc/doc/gcc.texi
! ae737fa92695d7c91678797250c7d454  gcc/doc/gccgo.1
! e89775457b668d0434bea4062214fb7b  gcc/doc/gccgo.info
! 85913d1a3b7b21e80921909f0892704a  gcc/doc/gccinstall.info
! 86c56e81dcdc2bbb8a6068690180d25b  gcc/doc/gccint.info
  edc0e7584ec44bfd909e0126057141b2  gcc/doc/gccint.texi
! 40897a7ba49196826b3a15fff9494986  gcc/doc/gcov-dump.1
  8cbf639fe99f374f9e305a031d0d6736  gcc/doc/gcov-dump.texi
! b7640801d0c9f40ed7308f3bd3ac66ea  gcc/doc/gcov-tool.1
  a4e8708b41fe686d6ecdc5246226e3e3  gcc/doc/gcov-tool.texi
! 165172136b169d0cc7a1bec36a3320fc  gcc/doc/gcov.1
  ccaf4e1393ac66805b8317145261710e  gcc/doc/gcov.texi
! 67a676e479759b0d1ae2b7c0c8c75a24  gcc/doc/gdc.1
! 0ef60f856f7fad1091a4b6bf7ae9e3e7  gcc/doc/gdc.info
  87c3d3669bc27263b6c7fc5d7fdd7c28  gcc/doc/generic.texi
! eedb7dc95146443e25c142f134a8b74f  gcc/doc/gfdl.7
! 53644433f46c11d012f2e8abccd24d59  gcc/doc/gfortran.1
  5630240c5ef619f03fc1bd750bde7b61  gcc/doc/gimple.texi
! 9797906dc17801830d31ac5543d07e3c  gcc/doc/gm2.1
  8c5e921b4436013be7b3d375620753f6  gcc/doc/gm2.texi
! 3b9971e9cfbb4a4e96d315f762c88f44  gcc/doc/gnat-style.info
! 767bb45e34539868aee09a4a25db0635  gcc/doc/gnat_rm.info
! a314fd57428817dc03a4c18109f122f0  gcc/doc/gnat_ugn.info
  dc4ccd9843d88bc01c909438dabfd6ab  gcc/doc/gnu.texi
! 69d7cc416af74e37c693da57cac9eca1  gcc/doc/gpl.7
  9c051a6abfe79317ad83904f042d2738  gcc/doc/gty.texi
  42ebfb9fc08dafdae427760be5354428  gcc/doc/headerdirs.texi
  971cd503a0a7fde3063283de000ba2ea  gcc/doc/hostconfig.texi
*************** f6b3263ab1e5301cb6fa8a9f0a687779  gcc/do
*** 5529,5545 ****
  918ccfd7be5640e27067c203dbf40d2f  gcc/doc/include/gcc-common.texi
  95c90bf85d3eab67f348ee3ce0bf4050  gcc/doc/include/gpl_v3.texi
  e9b8122841fbfbbc30fee8ed6613c399  gcc/doc/include/texinfo.tex
! b4c57b64e59441421fbf276de0639649  gcc/doc/install.texi
  0f44cc63abf9b607d1b8880175256326  gcc/doc/install.texi2html
  34b99c10f577dd2da256de717941c862  gcc/doc/interface.texi
! b5fe517d44d3c4b55830c628f692e4c0  gcc/doc/invoke.texi
  f64676ceacf4c713f83bad704dbc5eaf  gcc/doc/languages.texi
  e36a87d027eabff1a8595ee341342560  gcc/doc/libgcc.texi
  8b6fb2575a94998971924157a5cabfd8  gcc/doc/loop.texi
! a12b2aa5462613eabba7366a9ae70e50  gcc/doc/lto-dump.1
  ecfae67b5004f374351f0448f9b764e0  gcc/doc/lto-dump.texi
  a1c3440fcd17355fcd9956685728338c  gcc/doc/lto.texi
! 56302c35ebdbafd6185326b049fceb52  gcc/doc/m2.info
  e215e75acc6a49ab683dd3a4560fb7f8  gcc/doc/makefile.texi
  ac506e04e4e513f2e736736ace0a17ac  gcc/doc/match-and-simplify.texi
  41a368efad7b97a4b0d02368aa139e8f  gcc/doc/md.texi
--- 5529,5545 ----
  918ccfd7be5640e27067c203dbf40d2f  gcc/doc/include/gcc-common.texi
  95c90bf85d3eab67f348ee3ce0bf4050  gcc/doc/include/gpl_v3.texi
  e9b8122841fbfbbc30fee8ed6613c399  gcc/doc/include/texinfo.tex
! 6a31e908e197d0508bd9487b4eda9058  gcc/doc/install.texi
  0f44cc63abf9b607d1b8880175256326  gcc/doc/install.texi2html
  34b99c10f577dd2da256de717941c862  gcc/doc/interface.texi
! 6693201a6d28ecdc77d7dbe42e8d5e32  gcc/doc/invoke.texi
  f64676ceacf4c713f83bad704dbc5eaf  gcc/doc/languages.texi
  e36a87d027eabff1a8595ee341342560  gcc/doc/libgcc.texi
  8b6fb2575a94998971924157a5cabfd8  gcc/doc/loop.texi
! c7c5c8e67a06ec57a18316839b4f2cc1  gcc/doc/lto-dump.1
  ecfae67b5004f374351f0448f9b764e0  gcc/doc/lto-dump.texi
  a1c3440fcd17355fcd9956685728338c  gcc/doc/lto.texi
! b4620fb2c125a668a6083f100c6963b3  gcc/doc/m2.info
  e215e75acc6a49ab683dd3a4560fb7f8  gcc/doc/makefile.texi
  ac506e04e4e513f2e736736ace0a17ac  gcc/doc/match-and-simplify.texi
  41a368efad7b97a4b0d02368aa139e8f  gcc/doc/md.texi
*************** a281851392abb8220c82d93122bbd813  gcc/do
*** 5567,5573 ****
  590b7faf49265506edf4350a83e27f34  gcc/domwalk.h
  bd9a28f0b9c1df93c93d20711940ffbb  gcc/double-int.cc
  d7039a063609512d531816adc085e3fd  gcc/double-int.h
! ff15a9f4a15149ff9d7c5275673e2af2  gcc/dse.cc
  bcfc3857a75f879ec761a824ae77aa77  gcc/dump-context.h
  52f12315abc001a6345e995675976567  gcc/dumpfile.cc
  276fcdf9faad8f99eba0c32558648e49  gcc/dumpfile.h
--- 5567,5573 ----
  590b7faf49265506edf4350a83e27f34  gcc/domwalk.h
  bd9a28f0b9c1df93c93d20711940ffbb  gcc/double-int.cc
  d7039a063609512d531816adc085e3fd  gcc/double-int.h
! 3cbadf3dde3951d90f1ac5b94ac8a26b  gcc/dse.cc
  bcfc3857a75f879ec761a824ae77aa77  gcc/dump-context.h
  52f12315abc001a6345e995675976567  gcc/dumpfile.cc
  276fcdf9faad8f99eba0c32558648e49  gcc/dumpfile.h
*************** bcfc3857a75f879ec761a824ae77aa77  gcc/du
*** 5576,5582 ****
  3aecdcd1ecb4330fb6d35220436b4e16  gcc/dwarf2cfi.cc
  4b4d88e890847c2849c8a0dd429ad7d4  gcc/dwarf2ctf.cc
  6339307d1a91f4115e2184f117a9152f  gcc/dwarf2ctf.h
! f875a454019ec249dc151f8ca693547a  gcc/dwarf2out.cc
  da9eb5f94d9f2537c44626df2e2d0731  gcc/dwarf2out.h
  56a3faa5b916a76e3e8e799879bb6f9f  gcc/early-remat.cc
  c916e1e3ac5144157fdf894c31dca957  gcc/edit-context.cc
--- 5576,5582 ----
  3aecdcd1ecb4330fb6d35220436b4e16  gcc/dwarf2cfi.cc
  4b4d88e890847c2849c8a0dd429ad7d4  gcc/dwarf2ctf.cc
  6339307d1a91f4115e2184f117a9152f  gcc/dwarf2ctf.h
! a83befe4c08c383fa6fe5acf451c093a  gcc/dwarf2out.cc
  da9eb5f94d9f2537c44626df2e2d0731  gcc/dwarf2out.h
  56a3faa5b916a76e3e8e799879bb6f9f  gcc/early-remat.cc
  c916e1e3ac5144157fdf894c31dca957  gcc/edit-context.cc
*************** b50077475f8f7a1b64242ec5e01d7784  gcc/ex
*** 5593,5599 ****
  d2189b62c37dd572addf61825a41d344  gcc/exec-tool.in
  10518df9c294e40a2a7660c8d93f39a3  gcc/explow.cc
  16380b9326d8ac062959a6a82043cce3  gcc/explow.h
! efcdb43408c74630692eff921a1cc07f  gcc/expmed.cc
  19036d67b94612828e60a36131f73399  gcc/expmed.h
  3bf4610f6c4a28c419e8f9ed167ceb37  gcc/expr.cc
  a58f8d09aca5337953e4002f8d46ada5  gcc/expr.h
--- 5593,5599 ----
  d2189b62c37dd572addf61825a41d344  gcc/exec-tool.in
  10518df9c294e40a2a7660c8d93f39a3  gcc/explow.cc
  16380b9326d8ac062959a6a82043cce3  gcc/explow.h
! 41127ab9fe308f5a28b81d40dfdcfdd8  gcc/expmed.cc
  19036d67b94612828e60a36131f73399  gcc/expmed.h
  3bf4610f6c4a28c419e8f9ed167ceb37  gcc/expr.cc
  a58f8d09aca5337953e4002f8d46ada5  gcc/expr.h
*************** fe6768163b0ca6c41fea1719448908eb  gcc/fi
*** 5610,5618 ****
  c2dbf831f4bbc53553765214d1b2d674  gcc/flags.h
  84632412a9570c311bb6f9944fdacccf  gcc/fold-const-call.cc
  46538296abcbd26df93f276f5974ec0f  gcc/fold-const-call.h
! f32e31e2e5d7d430555b0a476972ca3a  gcc/fold-const.cc
  9dd2c87502c864095a8b942bea07b5f3  gcc/fold-const.h
! 0c6771b89b2cb598d39fe199e783fd9a  gcc/fortran/ChangeLog
  3330102ad3a0217cba963be6b5eefd58  gcc/fortran/ChangeLog-2002
  d000ab985b1eeb1ad5749f98b8fef99f  gcc/fortran/ChangeLog-2003
  bf42f94f0c51dcc7d8051cc7fda1efdc  gcc/fortran/ChangeLog-2004
--- 5610,5618 ----
  c2dbf831f4bbc53553765214d1b2d674  gcc/flags.h
  84632412a9570c311bb6f9944fdacccf  gcc/fold-const-call.cc
  46538296abcbd26df93f276f5974ec0f  gcc/fold-const-call.h
! e091b0ed4e31525d6d685d5e6f7a7fa0  gcc/fold-const.cc
  9dd2c87502c864095a8b942bea07b5f3  gcc/fold-const.h
! 57b8deed69f380f38ba34a35cee51ec3  gcc/fortran/ChangeLog
  3330102ad3a0217cba963be6b5eefd58  gcc/fortran/ChangeLog-2002
  d000ab985b1eeb1ad5749f98b8fef99f  gcc/fortran/ChangeLog-2003
  bf42f94f0c51dcc7d8051cc7fda1efdc  gcc/fortran/ChangeLog-2004
*************** d1595b2ed8fb2a33f6ce0dc595f4f33c  gcc/fo
*** 5638,5644 ****
  a1031ddafa666ce3ade625f41c0dc3f8  gcc/fortran/Make-lang.in
  d5bee359d146b78cacb1cef09ac5102f  gcc/fortran/arith.cc
  d725b555490bb7f2cd61f6bcc2c3de67  gcc/fortran/arith.h
! bae3ddfd77897b5f94b83cad27576c0f  gcc/fortran/array.cc
  35e889b2dd5fcf9ccf78e37ed082d6e6  gcc/fortran/bbt.cc
  807fa70f21f149b3b3e27d9942f008b9  gcc/fortran/check.cc
  0d3a98abb785a18e1b0e25ca1315e27b  gcc/fortran/class.cc
--- 5638,5644 ----
  a1031ddafa666ce3ade625f41c0dc3f8  gcc/fortran/Make-lang.in
  d5bee359d146b78cacb1cef09ac5102f  gcc/fortran/arith.cc
  d725b555490bb7f2cd61f6bcc2c3de67  gcc/fortran/arith.h
! 3607fc12de5ffe78bdc4ba57118c97d2  gcc/fortran/array.cc
  35e889b2dd5fcf9ccf78e37ed082d6e6  gcc/fortran/bbt.cc
  807fa70f21f149b3b3e27d9942f008b9  gcc/fortran/check.cc
  0d3a98abb785a18e1b0e25ca1315e27b  gcc/fortran/class.cc
*************** dead8f794e0bc7ece3c9f46a4b9ead58  gcc/fo
*** 5650,5667 ****
  bc8a50172db20622023d7b83c31d7737  gcc/fortran/cpp.h
  d49d08bf3282ebea910b14cf88b1b5ee  gcc/fortran/data.cc
  86b2ebfc95645333cba0df8f79638b62  gcc/fortran/data.h
! af7535cdf336627a57c695f9708c2ba8  gcc/fortran/decl.cc
  03376b1f69cb12088fb0957658714aa3  gcc/fortran/dependency.cc
  528121f9fe625a6b314dd0e4e9601e70  gcc/fortran/dependency.h
  638a4c6c1f147853ccf44c5442c876f9  gcc/fortran/dump-parse-tree.cc
  75860b58e8a01aadbfb046789efa8a88  gcc/fortran/error.cc
! 0af32ed33f5748db7e33876cb180cbb3  gcc/fortran/expr.cc
  012392c6483a51939022df7c6de22fbc  gcc/fortran/f95-lang.cc
! 2c46f4a85ebcd58b3bdb7f98f7d0b85c  gcc/fortran/frontend-passes.cc
  5d21a6b2bc38e36e9ce485f9b899cf5d  gcc/fortran/gfc-diagnostic.def
  d428ee96a4c880140da26aec0f107bda  gcc/fortran/gfc-internals.texi
! 706de8b42efb4516e0de8473694c5cde  gcc/fortran/gfortran.h
! bbdd5fdc9c27fb3e32e192c6d9ce6e0f  gcc/fortran/gfortran.info
  0da9587d85518945e473eb0045cf3202  gcc/fortran/gfortran.texi
  538b040a49c9f6c46cbd59c2a9ce1afd  gcc/fortran/gfortranspec.cc
  97f68911dc79e4809e6107ec13390bf9  gcc/fortran/interface.cc
--- 5650,5667 ----
  bc8a50172db20622023d7b83c31d7737  gcc/fortran/cpp.h
  d49d08bf3282ebea910b14cf88b1b5ee  gcc/fortran/data.cc
  86b2ebfc95645333cba0df8f79638b62  gcc/fortran/data.h
! e626fc9f74be348b19ed678ca99adfee  gcc/fortran/decl.cc
  03376b1f69cb12088fb0957658714aa3  gcc/fortran/dependency.cc
  528121f9fe625a6b314dd0e4e9601e70  gcc/fortran/dependency.h
  638a4c6c1f147853ccf44c5442c876f9  gcc/fortran/dump-parse-tree.cc
  75860b58e8a01aadbfb046789efa8a88  gcc/fortran/error.cc
! a2e9fd77d69fe3504d738dccd3f751e2  gcc/fortran/expr.cc
  012392c6483a51939022df7c6de22fbc  gcc/fortran/f95-lang.cc
! 45ee62f4958c472703abd5a75e157996  gcc/fortran/frontend-passes.cc
  5d21a6b2bc38e36e9ce485f9b899cf5d  gcc/fortran/gfc-diagnostic.def
  d428ee96a4c880140da26aec0f107bda  gcc/fortran/gfc-internals.texi
! 18f9a7bac53ec8c9ec3d6e189090e830  gcc/fortran/gfortran.h
! 2b8d1fa6572f0a497ca34599266d3c5b  gcc/fortran/gfortran.info
  0da9587d85518945e473eb0045cf3202  gcc/fortran/gfortran.texi
  538b040a49c9f6c46cbd59c2a9ce1afd  gcc/fortran/gfortranspec.cc
  97f68911dc79e4809e6107ec13390bf9  gcc/fortran/interface.cc
*************** d2a4c5315fb086aeaa125c4b2829a29f  gcc/fo
*** 5677,5683 ****
  5659bf0ae0187cfd21cd8f599d82f98d  gcc/fortran/lang-specs.h
  92cf8f5887329d298f04e41b7fd4b780  gcc/fortran/lang.opt
  dfe2708ae1610f0355d4e3f64825ed31  gcc/fortran/libgfortran.h
! f820f80f97ddcdeff771996b47adc742  gcc/fortran/match.cc
  a91d0fda9651b722ffd4fb160f95378a  gcc/fortran/match.h
  38fc5448e9ea8b828a44496034ac708e  gcc/fortran/matchexp.cc
  540b2df11e809f8e922d0bc5b5562d6b  gcc/fortran/mathbuiltins.def
--- 5677,5683 ----
  5659bf0ae0187cfd21cd8f599d82f98d  gcc/fortran/lang-specs.h
  92cf8f5887329d298f04e41b7fd4b780  gcc/fortran/lang.opt
  dfe2708ae1610f0355d4e3f64825ed31  gcc/fortran/libgfortran.h
! bea3116ee750dc99599200ed7513be4e  gcc/fortran/match.cc
  a91d0fda9651b722ffd4fb160f95378a  gcc/fortran/match.h
  38fc5448e9ea8b828a44496034ac708e  gcc/fortran/matchexp.cc
  540b2df11e809f8e922d0bc5b5562d6b  gcc/fortran/mathbuiltins.def
*************** a91d0fda9651b722ffd4fb160f95378a  gcc/fo
*** 5685,5714 ****
  c33036651adba2e736f64129207c7d23  gcc/fortran/module.cc
  c310fb2cf5f2bb20fbf7f911e7a5b2cc  gcc/fortran/openmp.cc
  47d8fa5113c1f84c750b8fa73bbc5cfa  gcc/fortran/options.cc
! 05417d717e262d61c78b736bc93c703d  gcc/fortran/parse.cc
  b07d21325e9bf64201a6131a3dacb9e2  gcc/fortran/parse.h
! 1f61601d93e03a871f0903165ed660ad  gcc/fortran/primary.cc
! 209042c6f306fb2591745a1d48a78c8f  gcc/fortran/resolve.cc
! 4c64219f591caa92c353a8d113120d87  gcc/fortran/scanner.cc
  0ea05c5f1f9c27f26a76525f5eed9380  gcc/fortran/scanner.h
  d7be9766180ba9d84c17fe538c02907f  gcc/fortran/simplify.cc
  72519934fee840610460010d9b5e0503  gcc/fortran/st.cc
! b51ee6b2a9e4f3e8bf69662f69c8f23c  gcc/fortran/symbol.cc
  e99e43daa5fef5f3d2c6dce6be81a683  gcc/fortran/target-memory.cc
  70445c82cc8c84eb76adf2a52acad00d  gcc/fortran/target-memory.h
! b16988fb11ef93959450cfdd9eaa8825  gcc/fortran/trans-array.cc
  23946ddd5d17c204402c44a0b9a00d75  gcc/fortran/trans-array.h
  4c2eb969dbee5d6b83074ed09773b70b  gcc/fortran/trans-common.cc
  45ab297b0b34853431ed0f3c09a63db3  gcc/fortran/trans-const.cc
  2825c959ade33ef2a6492d640b05ef8c  gcc/fortran/trans-const.h
! c15bfe2308615f6c0395efd6cdf7a3ae  gcc/fortran/trans-decl.cc
! db3105c2b544e19c5f87f1fc6165b7c0  gcc/fortran/trans-expr.cc
! 270fb3d641aa95f5ab3435bcf555d167  gcc/fortran/trans-intrinsic.cc
! c2777cd0e39ba69462f4cf01549e1001  gcc/fortran/trans-io.cc
! 4100e048c21085f4f2f9bdb70f4e29a2  gcc/fortran/trans-openmp.cc
  8c36caba9ba82554a7f97e56b2a48d63  gcc/fortran/trans-stmt.cc
  61675b3c591abd1d33f4d00338f84245  gcc/fortran/trans-stmt.h
! fc8598d1cff8fe85c82eb15bd14d186b  gcc/fortran/trans-types.cc
  5581dfe9c36f8428667284c49aa3d0a8  gcc/fortran/trans-types.h
  78b4a00c913f103a3f3d18c8c181efd9  gcc/fortran/trans.cc
  f816175a2ce44db1f8492faf3a65da0d  gcc/fortran/trans.h
--- 5685,5714 ----
  c33036651adba2e736f64129207c7d23  gcc/fortran/module.cc
  c310fb2cf5f2bb20fbf7f911e7a5b2cc  gcc/fortran/openmp.cc
  47d8fa5113c1f84c750b8fa73bbc5cfa  gcc/fortran/options.cc
! c0c3bcf7a95794a179458f5f74c2d450  gcc/fortran/parse.cc
  b07d21325e9bf64201a6131a3dacb9e2  gcc/fortran/parse.h
! 5f0c0fe49a7aa8f038cc4438385e178e  gcc/fortran/primary.cc
! 2fbe151fd04a3c2bb12a256141ae86ba  gcc/fortran/resolve.cc
! f1620f6af6f4d226dd7e0ee858f8bd10  gcc/fortran/scanner.cc
  0ea05c5f1f9c27f26a76525f5eed9380  gcc/fortran/scanner.h
  d7be9766180ba9d84c17fe538c02907f  gcc/fortran/simplify.cc
  72519934fee840610460010d9b5e0503  gcc/fortran/st.cc
! f517590a45dbb7448f8bdabbb424c775  gcc/fortran/symbol.cc
  e99e43daa5fef5f3d2c6dce6be81a683  gcc/fortran/target-memory.cc
  70445c82cc8c84eb76adf2a52acad00d  gcc/fortran/target-memory.h
! a0564053d153378bb6f52b60bd869d73  gcc/fortran/trans-array.cc
  23946ddd5d17c204402c44a0b9a00d75  gcc/fortran/trans-array.h
  4c2eb969dbee5d6b83074ed09773b70b  gcc/fortran/trans-common.cc
  45ab297b0b34853431ed0f3c09a63db3  gcc/fortran/trans-const.cc
  2825c959ade33ef2a6492d640b05ef8c  gcc/fortran/trans-const.h
! 13a5d3dd3c4bb9f7708081058f2745e4  gcc/fortran/trans-decl.cc
! 3ca908789ece558ac42f6be494731d55  gcc/fortran/trans-expr.cc
! 7a6a0f4f555cbc9df7d147a017fc7444  gcc/fortran/trans-intrinsic.cc
! f6db1c9d47520d97d86df27171bd0050  gcc/fortran/trans-io.cc
! c7930b7764e05d4b5c9e3c65f7ccc34c  gcc/fortran/trans-openmp.cc
  8c36caba9ba82554a7f97e56b2a48d63  gcc/fortran/trans-stmt.cc
  61675b3c591abd1d33f4d00338f84245  gcc/fortran/trans-stmt.h
! 7065faf196096868a61e1b84526614b9  gcc/fortran/trans-types.cc
  5581dfe9c36f8428667284c49aa3d0a8  gcc/fortran/trans-types.h
  78b4a00c913f103a3f3d18c8c181efd9  gcc/fortran/trans.cc
  f816175a2ce44db1f8492faf3a65da0d  gcc/fortran/trans.h
*************** bae9bee7bfae062bb68f7c3b8d6acdb0  gcc/fo
*** 5720,5726 ****
  9d3f4e62a09a4f1b7e01c2611985469b  gcc/function-tests.cc
  dc0db54f4e74be29d19799f88ed3a0f9  gcc/function.cc
  26caa4b20f75c2eb576da5bea538a2bc  gcc/function.h
! 97522e4b206b460428df4f324aa88fe4  gcc/fwprop.cc
  8b44f92603525757cdb88056f5f18ca2  gcc/gcc-ar.cc
  5d0b85771982e816a798a8206c3fc74c  gcc/gcc-main.cc
  73e2fac76430bce31ea211c315bda445  gcc/gcc-plugin.h
--- 5720,5726 ----
  9d3f4e62a09a4f1b7e01c2611985469b  gcc/function-tests.cc
  dc0db54f4e74be29d19799f88ed3a0f9  gcc/function.cc
  26caa4b20f75c2eb576da5bea538a2bc  gcc/function.h
! f2f74988d8e8927907da6f1d3f3d09ca  gcc/fwprop.cc
  8b44f92603525757cdb88056f5f18ca2  gcc/gcc-ar.cc
  5d0b85771982e816a798a8206c3fc74c  gcc/gcc-main.cc
  73e2fac76430bce31ea211c315bda445  gcc/gcc-plugin.h
*************** dd957e5f5e732e49835454d18d409c43  gcc/ge
*** 5761,5767 ****
  7a825a2d078d154675036b7133c6816a  gcc/genextract.cc
  7dc273587dd4838a57817b211ad1f139  gcc/genflags.cc
  b6fd297a00cab6b8993690131bc4c0f7  gcc/gengenrtl.cc
! 9a796a13fcb7a64a6f9ae52ede4ffbca  gcc/gengtype-lex.cc
  ff24fa6416a039455ff62a41252d6f7b  gcc/gengtype-lex.l
  91e7a263b28c131771f0c6463ebb1bcb  gcc/gengtype-parse.cc
  433b94a87abdc5536d0c8d2b097cb669  gcc/gengtype-state.cc
--- 5761,5767 ----
  7a825a2d078d154675036b7133c6816a  gcc/genextract.cc
  7dc273587dd4838a57817b211ad1f139  gcc/genflags.cc
  b6fd297a00cab6b8993690131bc4c0f7  gcc/gengenrtl.cc
! 708261b1d420bad9a1e65fd1659df459  gcc/gengtype-lex.cc
  ff24fa6416a039455ff62a41252d6f7b  gcc/gengtype-lex.l
  91e7a263b28c131771f0c6463ebb1bcb  gcc/gengtype-parse.cc
  433b94a87abdc5536d0c8d2b097cb669  gcc/gengtype-state.cc
*************** db0ccc0edfede8aba0098ae504276e86  gcc/gi
*** 5794,5804 ****
  2e82b4bd416d82267e23cfb6b62145d3  gcc/gimple-builder.h
  dcb207c1736268c66a622256d89d2336  gcc/gimple-expr.cc
  029271620b653993e15dfe20ddd2d37b  gcc/gimple-expr.h
! 0d4a2f003e7841c11e2a6c1b5e122669  gcc/gimple-fold.cc
  9a9d95793deb7de9860fc0d1215b3390  gcc/gimple-fold.h
  7cf98e471595ea406079ac821d418500  gcc/gimple-harden-conditionals.cc
  ab5c0e8e80c5a594037aa3a03ad791c9  gcc/gimple-if-to-switch.cc
! af0a5d375973bf0c61c83fe07c8953f2  gcc/gimple-isel.cc
  01b268628675b950255b0100e37fe075  gcc/gimple-iterator.cc
  348a424f3832c9ef4a35f364e4b74bf7  gcc/gimple-iterator.h
  9cb5accb4acfb52a12c188eb63da85aa  gcc/gimple-laddress.cc
--- 5794,5804 ----
  2e82b4bd416d82267e23cfb6b62145d3  gcc/gimple-builder.h
  dcb207c1736268c66a622256d89d2336  gcc/gimple-expr.cc
  029271620b653993e15dfe20ddd2d37b  gcc/gimple-expr.h
! c30c322635ac78dc841b9ec4efbb7c71  gcc/gimple-fold.cc
  9a9d95793deb7de9860fc0d1215b3390  gcc/gimple-fold.h
  7cf98e471595ea406079ac821d418500  gcc/gimple-harden-conditionals.cc
  ab5c0e8e80c5a594037aa3a03ad791c9  gcc/gimple-if-to-switch.cc
! 40786d02cb4681332c435205a7fe5511  gcc/gimple-isel.cc
  01b268628675b950255b0100e37fe075  gcc/gimple-iterator.cc
  348a424f3832c9ef4a35f364e4b74bf7  gcc/gimple-iterator.h
  9cb5accb4acfb52a12c188eb63da85aa  gcc/gimple-laddress.cc
*************** a11dc84518ffe22131bef7c5c59fb394  gcc/gi
*** 5818,5830 ****
  cd5746fe031b5d538b360fa10b1d17af  gcc/gimple-range-cache.h
  e9fa223929f8020fb122ede18c383ffa  gcc/gimple-range-edge.cc
  63552731dc609ddfd75542482f4ac3f9  gcc/gimple-range-edge.h
! e4f0c00a688b3744a867a1aabeee69fb  gcc/gimple-range-fold.cc
  91c4c0f1e668a1c3844c18cf84d74fce  gcc/gimple-range-fold.h
  630825f89ae6bad2278bb7f7782a3d83  gcc/gimple-range-gori.cc
  83fa369894ed79484edcd88e46e5ff5d  gcc/gimple-range-gori.h
  7b1dc20ba60b4caa74daea9f1f124b18  gcc/gimple-range-infer.cc
  9f35006871562ecf765135728e0d57c4  gcc/gimple-range-infer.h
! 487a96f6c36ce32cfe9885b8dcb738ee  gcc/gimple-range-op.cc
  40bb619c45615b32a7d0005623488726  gcc/gimple-range-op.h
  8172ae668f7250132a8b9a287010fa34  gcc/gimple-range-path.cc
  e29891d13b0ac2e960cac756204b9b46  gcc/gimple-range-path.h
--- 5818,5830 ----
  cd5746fe031b5d538b360fa10b1d17af  gcc/gimple-range-cache.h
  e9fa223929f8020fb122ede18c383ffa  gcc/gimple-range-edge.cc
  63552731dc609ddfd75542482f4ac3f9  gcc/gimple-range-edge.h
! 91ff5174e764b2d567ad99529fa797ad  gcc/gimple-range-fold.cc
  91c4c0f1e668a1c3844c18cf84d74fce  gcc/gimple-range-fold.h
  630825f89ae6bad2278bb7f7782a3d83  gcc/gimple-range-gori.cc
  83fa369894ed79484edcd88e46e5ff5d  gcc/gimple-range-gori.h
  7b1dc20ba60b4caa74daea9f1f124b18  gcc/gimple-range-infer.cc
  9f35006871562ecf765135728e0d57c4  gcc/gimple-range-infer.h
! a2b63a2aec32e358c1c3e681d7a07aed  gcc/gimple-range-op.cc
  40bb619c45615b32a7d0005623488726  gcc/gimple-range-op.h
  8172ae668f7250132a8b9a287010fa34  gcc/gimple-range-path.cc
  e29891d13b0ac2e960cac756204b9b46  gcc/gimple-range-path.h
*************** a03b4f17862e24c25dc27bd52bf6e4c9  gcc/gi
*** 5834,5840 ****
  5d089e48413b174d906755a37859dc74  gcc/gimple-range.cc
  d3d0bf916b0feeb213e0d274c25a85c9  gcc/gimple-range.h
  09f02da5a2f5cbc14b2967c94d2c1697  gcc/gimple-ssa-backprop.cc
! 8d00f32ff8f171436e955a222205301e  gcc/gimple-ssa-isolate-paths.cc
  749a81e49450342357c075a9b79b8992  gcc/gimple-ssa-nonnull-compare.cc
  11b5e3a1e0c7638d90da5ecf2cdb04e3  gcc/gimple-ssa-split-paths.cc
  e6db658fd173ce4a9dd146d9a796e834  gcc/gimple-ssa-sprintf.cc
--- 5834,5840 ----
  5d089e48413b174d906755a37859dc74  gcc/gimple-range.cc
  d3d0bf916b0feeb213e0d274c25a85c9  gcc/gimple-range.h
  09f02da5a2f5cbc14b2967c94d2c1697  gcc/gimple-ssa-backprop.cc
! 5a2ecb38247ee9993a0364d58ca9730f  gcc/gimple-ssa-isolate-paths.cc
  749a81e49450342357c075a9b79b8992  gcc/gimple-ssa-nonnull-compare.cc
  11b5e3a1e0c7638d90da5ecf2cdb04e3  gcc/gimple-ssa-split-paths.cc
  e6db658fd173ce4a9dd146d9a796e834  gcc/gimple-ssa-sprintf.cc
*************** f2ac4765424453762a2ec4deb1a07d64  gcc/gi
*** 5855,5863 ****
  8816cef486527a9fec6b68b907bba021  gcc/gimple.cc
  cdca7003d337efe5219b5d19f7155bc8  gcc/gimple.def
  bb54e7f3ff9957dcf7b1b10fcd527797  gcc/gimple.h
! 839b10eca81556c0515395365235a888  gcc/gimplify-me.cc
  0a4464e175c1aed6501ea243476b7c6d  gcc/gimplify-me.h
! 61549cdc6e1dd28cded29325e40de7b4  gcc/gimplify.cc
  d0042a88c5e87b0904397052ddc6c33a  gcc/gimplify.h
  02d1486ff7d3d34b7868801df9534c0e  gcc/ginclude/float.h
  b0ab9b7ae13d3afe6cdbfc24425a93fe  gcc/ginclude/iso646.h
--- 5855,5863 ----
  8816cef486527a9fec6b68b907bba021  gcc/gimple.cc
  cdca7003d337efe5219b5d19f7155bc8  gcc/gimple.def
  bb54e7f3ff9957dcf7b1b10fcd527797  gcc/gimple.h
! 37917e333c48d8a39452a53c773577aa  gcc/gimplify-me.cc
  0a4464e175c1aed6501ea243476b7c6d  gcc/gimplify-me.h
! ee53e607221e5dafbfffb110997843de  gcc/gimplify.cc
  d0042a88c5e87b0904397052ddc6c33a  gcc/gimplify.h
  02d1486ff7d3d34b7868801df9534c0e  gcc/ginclude/float.h
  b0ab9b7ae13d3afe6cdbfc24425a93fe  gcc/ginclude/iso646.h
*************** d805766cac737a191548368792524f9d  gcc/gi
*** 5873,5879 ****
  5402c032b10ed83d1f77ec71616dd286  gcc/ginclude/tgmath.h
  c92410f8fdb1cb95371b72c53ad55b5f  gcc/ginclude/unwind-arm-common.h
  8d9ecf0d6ef93c79623ce1d27a32a2cb  gcc/ginclude/varargs.h
! 5a3af36f882f0b8588bf6b6d2a2dd6d4  gcc/glimits.h
  6203700585b0aeb810914a5e9db364ca  gcc/go/ChangeLog
  1e68fc87619f2cd82132ed974cbcea92  gcc/go/Make-lang.in
  60ea054548c83c7f66170073f9f3e74c  gcc/go/README.gcc
--- 5873,5879 ----
  5402c032b10ed83d1f77ec71616dd286  gcc/ginclude/tgmath.h
  c92410f8fdb1cb95371b72c53ad55b5f  gcc/ginclude/unwind-arm-common.h
  8d9ecf0d6ef93c79623ce1d27a32a2cb  gcc/ginclude/varargs.h
! 5700356ce2d0cf330916f6862124c244  gcc/glimits.h
  6203700585b0aeb810914a5e9db364ca  gcc/go/ChangeLog
  1e68fc87619f2cd82132ed974cbcea92  gcc/go/Make-lang.in
  60ea054548c83c7f66170073f9f3e74c  gcc/go/README.gcc
*************** d9aef0bb49476bc2d492b82983032a3d  gcc/hw
*** 5977,5983 ****
  01b52dd1df8c52ed9edf50b535362f54  gcc/hw-doloop.h
  a2c970a78392773f57877bd6b739f5a5  gcc/hwint.cc
  44500fc305015a9aba3b0e4521e64a20  gcc/hwint.h
! 94b26ea9cc3c6cf63edc05afdc14fad4  gcc/ifcvt.cc
  af5696bbd759bde4b826b69e196cfdfd  gcc/ifcvt.h
  e628722087508f838cdb4899f48c7f43  gcc/inchash.cc
  a5b79003066c0e5bfacf7d9d006f46cd  gcc/inchash.h
--- 5977,5983 ----
  01b52dd1df8c52ed9edf50b535362f54  gcc/hw-doloop.h
  a2c970a78392773f57877bd6b739f5a5  gcc/hwint.cc
  44500fc305015a9aba3b0e4521e64a20  gcc/hwint.h
! dd6400a2a47c20bc6b869526981a0e78  gcc/ifcvt.cc
  af5696bbd759bde4b826b69e196cfdfd  gcc/ifcvt.h
  e628722087508f838cdb4899f48c7f43  gcc/inchash.cc
  a5b79003066c0e5bfacf7d9d006f46cd  gcc/inchash.h
*************** c12e2732707baf23e73a14d0b1b36dfd  gcc/in
*** 5995,6001 ****
  b604200ebd6bbb8075a58d20d96105e3  gcc/intl.cc
  2086a023243c1aeb61f8be26da7a72ad  gcc/intl.h
  f1c9645780e7d29c2d852ae147ef5d45  gcc/ipa-comdats.cc
! 91346ff57f1624cfcd802a92dface4d8  gcc/ipa-cp.cc
  55517140580887ca4deb8ce1e0321892  gcc/ipa-devirt.cc
  c8ce953e3c995ecf84e97c4c93a60807  gcc/ipa-fnsummary.cc
  fb25c569d03784bece5c17aaaaa369c5  gcc/ipa-fnsummary.h
--- 5995,6001 ----
  b604200ebd6bbb8075a58d20d96105e3  gcc/intl.cc
  2086a023243c1aeb61f8be26da7a72ad  gcc/intl.h
  f1c9645780e7d29c2d852ae147ef5d45  gcc/ipa-comdats.cc
! b99e784ab51d3c4658406ce120e4d3a1  gcc/ipa-cp.cc
  55517140580887ca4deb8ce1e0321892  gcc/ipa-devirt.cc
  c8ce953e3c995ecf84e97c4c93a60807  gcc/ipa-fnsummary.cc
  fb25c569d03784bece5c17aaaaa369c5  gcc/ipa-fnsummary.h
*************** b66a71357a6149335f63d1d38da0ff9f  gcc/ip
*** 6010,6018 ****
  d4b7959c20a98ff6f25372701739be82  gcc/ipa-inline.h
  bf2c8193144d067992fafe66ec1b66c4  gcc/ipa-modref-tree.cc
  c4370973ef8ca23676e8dd1782308f9c  gcc/ipa-modref-tree.h
! 5a78fdd6a39f4b401e23ae691ae39080  gcc/ipa-modref.cc
  b2fae5a0c725823232307d1ff107c412  gcc/ipa-modref.h
! f73a29a76199a719eea19b3d53ed26fe  gcc/ipa-param-manipulation.cc
  0a0833ceaf3d91577600c81d30513737  gcc/ipa-param-manipulation.h
  7cea60b3666f6942e8ff38e2854bcfc2  gcc/ipa-polymorphic-call.cc
  eeca019a2a20494b0c27fccd9ffa6e38  gcc/ipa-predicate.cc
--- 6010,6018 ----
  d4b7959c20a98ff6f25372701739be82  gcc/ipa-inline.h
  bf2c8193144d067992fafe66ec1b66c4  gcc/ipa-modref-tree.cc
  c4370973ef8ca23676e8dd1782308f9c  gcc/ipa-modref-tree.h
! c587bfd43c92d46a7ed06981d3cceb48  gcc/ipa-modref.cc
  b2fae5a0c725823232307d1ff107c412  gcc/ipa-modref.h
! e21d3914ecb784f21f94c8b81ca0b27c  gcc/ipa-param-manipulation.cc
  0a0833ceaf3d91577600c81d30513737  gcc/ipa-param-manipulation.h
  7cea60b3666f6942e8ff38e2854bcfc2  gcc/ipa-polymorphic-call.cc
  eeca019a2a20494b0c27fccd9ffa6e38  gcc/ipa-predicate.cc
*************** f64420b638d7ebaa362a56a8ee6e09b9  gcc/ir
*** 6038,6044 ****
  04825acf2804a1cbac4ea42e34f5d78a  gcc/ira-emit.cc
  221ce32bce49d374e617c10cc457c146  gcc/ira-int.h
  11f493755c61302aed33b9e2e678c8ca  gcc/ira-lives.cc
! ca3aaf780b4820c2efb4f99d452eafb2  gcc/ira.cc
  daec5f5daeb40974ee5715d87b784866  gcc/ira.h
  794ab6840c05630c3df07341a0f339e5  gcc/is-a.h
  83fa9cced7fd3d64ba760bf4dd2f1414  gcc/iterator-utils.h
--- 6038,6044 ----
  04825acf2804a1cbac4ea42e34f5d78a  gcc/ira-emit.cc
  221ce32bce49d374e617c10cc457c146  gcc/ira-int.h
  11f493755c61302aed33b9e2e678c8ca  gcc/ira-lives.cc
! d6401593afcaa0c9d5e87fcac2944455  gcc/ira.cc
  daec5f5daeb40974ee5715d87b784866  gcc/ira.h
  794ab6840c05630c3df07341a0f339e5  gcc/is-a.h
  83fa9cced7fd3d64ba760bf4dd2f1414  gcc/iterator-utils.h
*************** fdb910a61276129e6981a007c1cd94f6  gcc/lo
*** 6154,6164 ****
  0196e3b94cf6fd637ba9f3bf6a314bd5  gcc/lower-subreg.h
  1843969b87343439d9591acd32785e25  gcc/lra-assigns.cc
  6f8948f5953e4ded18580ae4df9a36f1  gcc/lra-coalesce.cc
! e7abca99420529cfac5bbb1e0273dc1b  gcc/lra-constraints.cc
  770e42213cbcd993a445bee76524f8eb  gcc/lra-eliminations.cc
  7c8aeab71bcfacb356aecdcdb7762210  gcc/lra-int.h
  399337ad638584d9290158ea06d18de8  gcc/lra-lives.cc
! a8f3bbbd00b9de205b710a6cb7112517  gcc/lra-remat.cc
  f29a4612195d306e5b22fd456cfb2a91  gcc/lra-spills.cc
  292ab755fb0b9a22616cefeb10633fff  gcc/lra.cc
  e39f5642047f20c01157ff09360cf476  gcc/lra.h
--- 6154,6164 ----
  0196e3b94cf6fd637ba9f3bf6a314bd5  gcc/lower-subreg.h
  1843969b87343439d9591acd32785e25  gcc/lra-assigns.cc
  6f8948f5953e4ded18580ae4df9a36f1  gcc/lra-coalesce.cc
! 65f730364f57fd7e00de0e20da43c174  gcc/lra-constraints.cc
  770e42213cbcd993a445bee76524f8eb  gcc/lra-eliminations.cc
  7c8aeab71bcfacb356aecdcdb7762210  gcc/lra-int.h
  399337ad638584d9290158ea06d18de8  gcc/lra-lives.cc
! 5a047d5b34101580c863ac3dc4532998  gcc/lra-remat.cc
  f29a4612195d306e5b22fd456cfb2a91  gcc/lra-spills.cc
  292ab755fb0b9a22616cefeb10633fff  gcc/lra.cc
  e39f5642047f20c01157ff09360cf476  gcc/lra.h
*************** c65f55fed79f6f011c286a8c15d49485  gcc/lt
*** 6174,6180 ****
  84bdf4dde2c999956f004a2cec5fcdfa  gcc/lto-streamer.cc
  4051a87eb8e439afcde2567e10273f08  gcc/lto-streamer.h
  937c657e2ab15274b95fdb91519d7865  gcc/lto-wrapper.cc
! 2466e7895148af5a4575b78d9aee2152  gcc/lto/ChangeLog
  1c031130b442e688f20c6f97577f6f1c  gcc/lto/Make-lang.in
  10ec91fabc2cd5424224460087811ade  gcc/lto/common.cc
  797d875c24181ac44cc33ff020e1b788  gcc/lto/common.h
--- 6174,6180 ----
  84bdf4dde2c999956f004a2cec5fcdfa  gcc/lto-streamer.cc
  4051a87eb8e439afcde2567e10273f08  gcc/lto-streamer.h
  937c657e2ab15274b95fdb91519d7865  gcc/lto-wrapper.cc
! 369fb8beefda3a002a9354dc54fc56d6  gcc/lto/ChangeLog
  1c031130b442e688f20c6f97577f6f1c  gcc/lto/Make-lang.in
  10ec91fabc2cd5424224460087811ade  gcc/lto/common.cc
  797d875c24181ac44cc33ff020e1b788  gcc/lto/common.h
*************** a497c0ed98b232be3d905aa138636779  gcc/lt
*** 6188,6194 ****
  db24810ac399c4a5d6146bd71ef73426  gcc/lto/lto-object.cc
  f018d5b0f30e1d8cb11793871268668a  gcc/lto/lto-partition.cc
  b42fe0b38243f7d8bd946b42c8b1fdcc  gcc/lto/lto-partition.h
! 4fa8e84a8428772802769f231e45ad45  gcc/lto/lto-symtab.cc
  64117f906dfc57aab1b4dcf007dc88fb  gcc/lto/lto-symtab.h
  e1760b67860124dafbbaf58a3e22c65e  gcc/lto/lto-tree.h
  885788a8016feb1e435d6099e3eebde0  gcc/lto/lto.cc
--- 6188,6194 ----
  db24810ac399c4a5d6146bd71ef73426  gcc/lto/lto-object.cc
  f018d5b0f30e1d8cb11793871268668a  gcc/lto/lto-partition.cc
  b42fe0b38243f7d8bd946b42c8b1fdcc  gcc/lto/lto-partition.h
! af5e34b9a3683a3dc46261aee0b25bbe  gcc/lto/lto-symtab.cc
  64117f906dfc57aab1b4dcf007dc88fb  gcc/lto/lto-symtab.h
  e1760b67860124dafbbaf58a3e22c65e  gcc/lto/lto-tree.h
  885788a8016feb1e435d6099e3eebde0  gcc/lto/lto.cc
*************** d26ca7644b0c87e9afba723a82e83ffa  gcc/ma
*** 7121,7127 ****
  020ac57561ab532784bab813afc03f17  gcc/machmode.h
  f837fae8701f147a459629038cc2f8d1  gcc/main.cc
  1f00c2ae711dcf705d2724bc1912adec  gcc/make-unique.h
! 19924de2a2dbf163c8a7663f82e2a372  gcc/match.pd
  ad32d5a9a041bd32e3123d6caba1f49d  gcc/mcf.cc
  c3df3b1477c180924303d737bff27c46  gcc/mem-stats-traits.h
  6682c830fe9e4f4ab3d82e31b7e3aa49  gcc/mem-stats.h
--- 7121,7127 ----
  020ac57561ab532784bab813afc03f17  gcc/machmode.h
  f837fae8701f147a459629038cc2f8d1  gcc/main.cc
  1f00c2ae711dcf705d2724bc1912adec  gcc/make-unique.h
! fd1d063b693ad6ac67904df3bf96a8c3  gcc/match.pd
  ad32d5a9a041bd32e3123d6caba1f49d  gcc/mcf.cc
  c3df3b1477c180924303d737bff27c46  gcc/mem-stats-traits.h
  6682c830fe9e4f4ab3d82e31b7e3aa49  gcc/mem-stats.h
*************** dadcfdc4c2674da3bb7172f1bda846a5  gcc/ob
*** 7162,7172 ****
  37450e1d0a6c6e763d0044f7bd625e1c  gcc/objcp/objcp-lang.cc
  b33ce8e63d322a6dc9496144d93baefb  gcc/obstack-utils.h
  e8768e7bddbebe0721552be034c8a56d  gcc/omp-builtins.def
! bebed5d660bdaed4bcd05a8e7a0bd66b  gcc/omp-expand.cc
  b602f2dfec40ed722b5aee2bf7e3e8ac  gcc/omp-expand.h
  e82073a6eb81a0c7e2715dffb046afea  gcc/omp-general.cc
  009c63d00f91f4e914f53c0ecdee6908  gcc/omp-general.h
! 711c590e7e6af52526895c4008ee7671  gcc/omp-low.cc
  c28514b051bd58349c8ce22a92021e01  gcc/omp-low.h
  297d0a39fb8707da61286135c64c3cda  gcc/omp-oacc-kernels-decompose.cc
  2ecc74cf5fab725715493514e0c7a5bb  gcc/omp-oacc-neuter-broadcast.cc
--- 7162,7172 ----
  37450e1d0a6c6e763d0044f7bd625e1c  gcc/objcp/objcp-lang.cc
  b33ce8e63d322a6dc9496144d93baefb  gcc/obstack-utils.h
  e8768e7bddbebe0721552be034c8a56d  gcc/omp-builtins.def
! ab47c3e43da4d2cbb60f59f54e550e8e  gcc/omp-expand.cc
  b602f2dfec40ed722b5aee2bf7e3e8ac  gcc/omp-expand.h
  e82073a6eb81a0c7e2715dffb046afea  gcc/omp-general.cc
  009c63d00f91f4e914f53c0ecdee6908  gcc/omp-general.h
! 3e03d22cc57968b45df20f0c75feb606  gcc/omp-low.cc
  c28514b051bd58349c8ce22a92021e01  gcc/omp-low.h
  297d0a39fb8707da61286135c64c3cda  gcc/omp-oacc-kernels-decompose.cc
  2ecc74cf5fab725715493514e0c7a5bb  gcc/omp-oacc-neuter-broadcast.cc
*************** f8f3df70c36095097945cb03323a693b  gcc/op
*** 7188,7194 ****
  74bc067eadc826ac4c141664fff05ae4  gcc/optabs-query.h
  6ddb0119ae19dadd9224a450c1e3e8b6  gcc/optabs-tree.cc
  1c8dfa2acc3b3ae4f083ef0d55515944  gcc/optabs-tree.h
! 7c90f9a44f9f5dcffe2881376f3d9f63  gcc/optabs.cc
  425698078194ac5f06fe487ecbba9dfe  gcc/optabs.def
  65ccc81ac4251caf331468bf897a4d21  gcc/optabs.h
  3dfd8d122c4d56a7627db3105cc0942f  gcc/optc-gen.awk
--- 7188,7194 ----
  74bc067eadc826ac4c141664fff05ae4  gcc/optabs-query.h
  6ddb0119ae19dadd9224a450c1e3e8b6  gcc/optabs-tree.cc
  1c8dfa2acc3b3ae4f083ef0d55515944  gcc/optabs-tree.h
! c390b81071ce90ad7fc75955f7734fb9  gcc/optabs.cc
  425698078194ac5f06fe487ecbba9dfe  gcc/optabs.def
  65ccc81ac4251caf331468bf897a4d21  gcc/optabs.h
  3dfd8d122c4d56a7627db3105cc0942f  gcc/optc-gen.awk
*************** b7c23a22025fc638936c8776d5141077  gcc/pl
*** 7216,7228 ****
  0d98256396aa9909139748326fe2ec5a  gcc/plugin.h
  2149bb7e8f20e653da6a1356df7728f2  gcc/po/ChangeLog
  529a60fd475862c5330245c858e844e1  gcc/po/EXCLUDES
! e4e35545a1fab9b9decbe9b06b468f72  gcc/po/be.gmo
  2ba501322d853f2ba4f16e197e60de49  gcc/po/be.po
  526c65acd465c005385d7aa0608f31d9  gcc/po/da.gmo
  dabe29c220e8ad6aeae160ee1999c69e  gcc/po/da.po
  d39918abbc3d79e054e1b2caa7dfbd33  gcc/po/de.gmo
  0e6fc6e1a3e3e324d4a95800d941ac5d  gcc/po/de.po
! 189b9d1af87594807b0d0e10036a64c3  gcc/po/el.gmo
  60da9ffca8ed77da660f5b60b5f2f2e4  gcc/po/el.po
  f8c66f2d87931e85c7dbf4b94f461633  gcc/po/es.gmo
  866f56e18e1ecc3173733aa05ac015eb  gcc/po/es.po
--- 7216,7228 ----
  0d98256396aa9909139748326fe2ec5a  gcc/plugin.h
  2149bb7e8f20e653da6a1356df7728f2  gcc/po/ChangeLog
  529a60fd475862c5330245c858e844e1  gcc/po/EXCLUDES
! e832b89b6dbf9df838167843217e810d  gcc/po/be.gmo
  2ba501322d853f2ba4f16e197e60de49  gcc/po/be.po
  526c65acd465c005385d7aa0608f31d9  gcc/po/da.gmo
  dabe29c220e8ad6aeae160ee1999c69e  gcc/po/da.po
  d39918abbc3d79e054e1b2caa7dfbd33  gcc/po/de.gmo
  0e6fc6e1a3e3e324d4a95800d941ac5d  gcc/po/de.po
! 17988b99399797e62f94326e0f42bdc1  gcc/po/el.gmo
  60da9ffca8ed77da660f5b60b5f2f2e4  gcc/po/el.po
  f8c66f2d87931e85c7dbf4b94f461633  gcc/po/es.gmo
  866f56e18e1ecc3173733aa05ac015eb  gcc/po/es.po
*************** c72bef625d77ba402907d3c5240f8b7b  gcc/po
*** 7234,7240 ****
  df7ea335e1fc6e41c7c14462e5ff8e26  gcc/po/gcc.pot
  c2cabce77f2459a83441f7bc743b0c32  gcc/po/hr.gmo
  074f10ba65f9fdc3d5d6dd9f55e7028e  gcc/po/hr.po
! 3c1cd9a547de9c7e50fd85d47abb5587  gcc/po/id.gmo
  e152f33e03d9e477105a086735d0f00f  gcc/po/id.po
  cc1f48b6706c3b9ab09d19ef09ca1379  gcc/po/ja.gmo
  85936b8435028da666014306b2703067  gcc/po/ja.po
--- 7234,7240 ----
  df7ea335e1fc6e41c7c14462e5ff8e26  gcc/po/gcc.pot
  c2cabce77f2459a83441f7bc743b0c32  gcc/po/hr.gmo
  074f10ba65f9fdc3d5d6dd9f55e7028e  gcc/po/hr.po
! c199012adb6103fed627f0e079931ab7  gcc/po/id.gmo
  e152f33e03d9e477105a086735d0f00f  gcc/po/id.po
  cc1f48b6706c3b9ab09d19ef09ca1379  gcc/po/ja.gmo
  85936b8435028da666014306b2703067  gcc/po/ja.po
*************** d106e1f524c9bc71a6317219b4248be3  gcc/po
*** 7256,7267 ****
  b561422731073b68d89df759bdbab101  gcc/po/zh_CN.po
  26080b5d6659bf16b31d74c084bbe8d2  gcc/po/zh_TW.gmo
  e787a3b9712d1eb24c32dd0cc731ccbd  gcc/po/zh_TW.po
! 8e945f56b5e2ea904a47c83a60fc2105  gcc/pointer-query.cc
  27a82acfef939a6105653100ca817c22  gcc/pointer-query.h
  826e8613602ff66b4826777cca1f0f8c  gcc/poly-int-types.h
  904c1ca12d0557980609eab0e8c559a7  gcc/poly-int.h
  8d639c83a53e2fc94a92dd31a295728e  gcc/postreload-gcse.cc
! aa38a16aae72c73780bfc35f1192be5e  gcc/postreload.cc
  e391674d14a8a9d1efc43643c37b2f21  gcc/predict.cc
  a4947e8f0ddcbc7eb9df2fa43790fec7  gcc/predict.def
  005dc519df06271b4a76719be9cc89ed  gcc/predict.h
--- 7256,7267 ----
  b561422731073b68d89df759bdbab101  gcc/po/zh_CN.po
  26080b5d6659bf16b31d74c084bbe8d2  gcc/po/zh_TW.gmo
  e787a3b9712d1eb24c32dd0cc731ccbd  gcc/po/zh_TW.po
! 589c60e20e5db65edc2e5fb432ffda03  gcc/pointer-query.cc
  27a82acfef939a6105653100ca817c22  gcc/pointer-query.h
  826e8613602ff66b4826777cca1f0f8c  gcc/poly-int-types.h
  904c1ca12d0557980609eab0e8c559a7  gcc/poly-int.h
  8d639c83a53e2fc94a92dd31a295728e  gcc/postreload-gcse.cc
! 58d44f3850805a0ffb22539255a1803b  gcc/postreload.cc
  e391674d14a8a9d1efc43643c37b2f21  gcc/predict.cc
  a4947e8f0ddcbc7eb9df2fa43790fec7  gcc/predict.def
  005dc519df06271b4a76719be9cc89ed  gcc/predict.h
*************** e8627c87ea01f9f273bb02b8b6ac82f2  gcc/pr
*** 7278,7284 ****
  b7344110e5c574b4be9c320add505c04  gcc/profile-count.h
  38675dd56002512bad75809f6c8501b6  gcc/profile.cc
  139e817371eff9511cbb43f0f6774b34  gcc/profile.h
! a93f4f4bace3525748617df94d30f69e  gcc/range-op-float.cc
  80e82c3c70b062932694cbf63ac01d67  gcc/range-op.cc
  a97482360b7088e2305d2382195e523a  gcc/range-op.h
  c1360f9d799d927a43938d0fa2197c2f  gcc/range.cc
--- 7278,7284 ----
  b7344110e5c574b4be9c320add505c04  gcc/profile-count.h
  38675dd56002512bad75809f6c8501b6  gcc/profile.cc
  139e817371eff9511cbb43f0f6774b34  gcc/profile.h
! 0834594cc7639dabac8602f3c69078ab  gcc/range-op-float.cc
  80e82c3c70b062932694cbf63ac01d67  gcc/range-op.cc
  a97482360b7088e2305d2382195e523a  gcc/range-op.h
  c1360f9d799d927a43938d0fa2197c2f  gcc/range.cc
*************** dba0f0365eba7e1180b97b202ad14f26  gcc/sr
*** 7665,7671 ****
  bca179f44085fd8edc737e4ba262fcfd  gcc/stack-ptr-mod.cc
  8b9baba6588250d0568a6e79a77b40b1  gcc/statistics.cc
  105fe33a71f974f02ef7f3263c08669a  gcc/statistics.h
! 0d3c777db64aa3d968af3598592d5b63  gcc/stmt.cc
  be9918eb7971ed2aa227d2a9556ab4c1  gcc/stmt.h
  ca456c74be9de499884af205fbfa10fe  gcc/stor-layout.cc
  b3072e70f0734ebf8ff3e86db3e31313  gcc/stor-layout.h
--- 7665,7671 ----
  bca179f44085fd8edc737e4ba262fcfd  gcc/stack-ptr-mod.cc
  8b9baba6588250d0568a6e79a77b40b1  gcc/statistics.cc
  105fe33a71f974f02ef7f3263c08669a  gcc/statistics.h
! 3ff8e4c47657b3fe63801afd74ea74c8  gcc/stmt.cc
  be9918eb7971ed2aa227d2a9556ab4c1  gcc/stmt.h
  ca456c74be9de499884af205fbfa10fe  gcc/stor-layout.cc
  b3072e70f0734ebf8ff3e86db3e31313  gcc/stor-layout.h
*************** e6c15bb100982c366657793f0ba5405f  gcc/sy
*** 7683,7689 ****
  1df86ebb721c32a31780042b3a5afa4f  gcc/symtab-thunks.h
  5d430915c811c8ef34649ce9ef163f79  gcc/symtab.cc
  ff3675d3b97df46f8e1ed96a13ce7dd7  gcc/sync-builtins.def
! fe435b44b913dfd987519b7bf9e1d294  gcc/system.h
  744e683ea9d5282ff763bca2bba4f90d  gcc/target-def.h
  e880e2e7aadcca94c17ee3bff654d152  gcc/target-globals.cc
  a4178410f0dd9596b6066554d292aa02  gcc/target-globals.h
--- 7683,7689 ----
  1df86ebb721c32a31780042b3a5afa4f  gcc/symtab-thunks.h
  5d430915c811c8ef34649ce9ef163f79  gcc/symtab.cc
  ff3675d3b97df46f8e1ed96a13ce7dd7  gcc/sync-builtins.def
! b254296ef80bc14d012f98ee0187a78a  gcc/system.h
  744e683ea9d5282ff763bca2bba4f90d  gcc/target-def.h
  e880e2e7aadcca94c17ee3bff654d152  gcc/target-globals.cc
  a4178410f0dd9596b6066554d292aa02  gcc/target-globals.h
*************** b829ed0032c899e107be2db349c913f3  gcc/ta
*** 7694,7700 ****
  811da275a2b9d3186a6decf96c01b0ed  gcc/targhooks.cc
  edb193a32070c4a7626fb75382def9b9  gcc/targhooks.h
  f39fcaa8197187283ccfed40107b426d  gcc/testsuite/.gitattributes
! 4661784bb4508a9f5be43f5dd666ac81  gcc/testsuite/ChangeLog
  862f04afbd87da2cc6bc432c3f28430f  gcc/testsuite/ChangeLog-1993-2007
  029a5d8dacd25eb5d4711452ac448e5b  gcc/testsuite/ChangeLog-2008
  13ac28c41d51b66b4ec40dba6bd50f39  gcc/testsuite/ChangeLog-2009
--- 7694,7700 ----
  811da275a2b9d3186a6decf96c01b0ed  gcc/targhooks.cc
  edb193a32070c4a7626fb75382def9b9  gcc/targhooks.h
  f39fcaa8197187283ccfed40107b426d  gcc/testsuite/.gitattributes
! 4929884c526ee744d50bddbce929f336  gcc/testsuite/ChangeLog
  862f04afbd87da2cc6bc432c3f28430f  gcc/testsuite/ChangeLog-1993-2007
  029a5d8dacd25eb5d4711452ac448e5b  gcc/testsuite/ChangeLog-2008
  13ac28c41d51b66b4ec40dba6bd50f39  gcc/testsuite/ChangeLog-2009
*************** cc70faf06727814cce7b45e0a0d0614d  gcc/te
*** 10333,10338 ****
--- 10333,10339 ----
  76fa33c917471922e94d50763fda451c  gcc/testsuite/c-c++-common/Waddress-of-packed-member-2.c
  273f580aad8918060378ff0f64998aa7  gcc/testsuite/c-c++-common/Walloca-larger-than.c
  afef2f2a384ff98fc41df320bb6a2419  gcc/testsuite/c-c++-common/Warray-bounds-10.c
+ a1f750193e9b002ef72772e807bd3a32  gcc/testsuite/c-c++-common/Warray-bounds-11.c
  26f47ca8f4d16158af229f5e0181ba58  gcc/testsuite/c-c++-common/Warray-bounds-2.c
  735f67562fd278388dfba29a23faba55  gcc/testsuite/c-c++-common/Warray-bounds-3.c
  bd8f64abbcab43dedc51e54273763e0c  gcc/testsuite/c-c++-common/Warray-bounds-4.c
*************** b090341af8b5d9e1054e1c181b49de0d  gcc/te
*** 10878,10883 ****
--- 10879,10886 ----
  da5e564f6cffb4d2f63384ba5d7351b1  gcc/testsuite/c-c++-common/cpp/diagnostic-pragma-2.c
  7e07a117bfa1cbd4313441da514b62a7  gcc/testsuite/c-c++-common/cpp/dir-only-1.c
  94f40e67e3617fd463bd2b73d2f6d54c  gcc/testsuite/c-c++-common/cpp/dir-only-1.h
+ 3ddedbc00d4ff771f66edefc8d70881f  gcc/testsuite/c-c++-common/cpp/dir-only-10.c
+ 948247aa95702e920da7ab25ee7cf601  gcc/testsuite/c-c++-common/cpp/dir-only-11.c
  92a3350e430f3da6be21354b2cc4eb5d  gcc/testsuite/c-c++-common/cpp/dir-only-2.c
  d17c82849bf7f540adedf0e80d9b41df  gcc/testsuite/c-c++-common/cpp/dir-only-3.c
  f120018b9734950cca9c0e7ba0e9a33a  gcc/testsuite/c-c++-common/cpp/dir-only-3a.h
*************** f2e2a6171e51d284aef6b4356f338ad3  gcc/te
*** 10963,10968 ****
--- 10966,10972 ----
  027fa50fd78720edd2f51bb22c3bd84f  gcc/testsuite/c-c++-common/cpp/ucnid-2011-1-utf8.c
  3a1169881f0152504462d4376c3b8083  gcc/testsuite/c-c++-common/cpp/ucnid-2011-1.c
  83bc077362cc4ef37199360c8b7fe130  gcc/testsuite/c-c++-common/cpp/va-opt-10.c
+ c0cee8d2b608a65564c4f25246c1a566  gcc/testsuite/c-c++-common/cpp/va-opt-11.c
  0f93514d0ad79c03edfd672fb354e619  gcc/testsuite/c-c++-common/cpp/va-opt-2.c
  adb3860eef253c75b743827724ba1bbc  gcc/testsuite/c-c++-common/cpp/va-opt-3.c
  ffa7f1250b7f00a641ad13c5836e4f01  gcc/testsuite/c-c++-common/cpp/va-opt-4.c
*************** ef8ec3320ae234be32fcdfc5379eaca2  gcc/te
*** 11537,11542 ****
--- 11541,11548 ----
  8f995161beda01326e712ba172a760f8  gcc/testsuite/c-c++-common/gomp/pr107001.c
  9b182f81cba9d60fb2cbbde45ceae582  gcc/testsuite/c-c++-common/gomp/pr108244-3.c
  c83ce004951a9a0719e190f7457302c7  gcc/testsuite/c-c++-common/gomp/pr119000.c
+ 250f54e2a193f434f875e2caf2868bc6  gcc/testsuite/c-c++-common/gomp/pr120052.c
+ c315375dde6dfd35915ac372415190a8  gcc/testsuite/c-c++-common/gomp/pr120564.c
  e16ef156ad193ef1f3cba60ad16e57ab  gcc/testsuite/c-c++-common/gomp/pr51360.c
  84c977571aeb43c0224137efe7f5b213  gcc/testsuite/c-c++-common/gomp/pr53580.c
  28bfd873981083756a16f70fdb0b86db  gcc/testsuite/c-c++-common/gomp/pr54017.c
*************** e1ef9c58498f72552b0ec84751024b54  gcc/te
*** 11820,11825 ****
--- 11826,11832 ----
  2ce597ddfe4f3e0b48f9b9dbd2e4cb0a  gcc/testsuite/c-c++-common/pr108365.c
  043b8dd187f001c1699789f752f3432d  gcc/testsuite/c-c++-common/pr108605.c
  7e6323dd9b11ca893c79859f430b53ed  gcc/testsuite/c-c++-common/pr109884.c
+ b27edfb18a0a46230f08ed022faced81  gcc/testsuite/c-c++-common/pr111817.c
  f5dce8e27cfb8a6bfffe57596fecb796  gcc/testsuite/c-c++-common/pr19807-1.c
  78a05c6e7d414ef4fd6f21dece4e9f21  gcc/testsuite/c-c++-common/pr19807-2.c
  39c0873a2c1c7f951e8b2f90ebc9e12d  gcc/testsuite/c-c++-common/pr19807-3.c
*************** b1579268264426b91fb29ca4a7ae6672  gcc/te
*** 12882,12887 ****
--- 12889,12895 ----
  ed79cf5bf3c45230ee9187c4cf51338e  gcc/testsuite/g++.dg/abi/packed1.C
  a6094bf319c105760bebe41768865b66  gcc/testsuite/g++.dg/abi/param1.C
  dc8d04461395fe21c8df3c3ddc0eaefb  gcc/testsuite/g++.dg/abi/param2.C
+ c6ee91a6fae5891b271cf08faea94bc7  gcc/testsuite/g++.dg/abi/pr121801.C
  4f8a99ff3fb06bd92fa2824ba0222b0d  gcc/testsuite/g++.dg/abi/pr39188-1.h
  0b334e68ad96b9b585797769690bad26  gcc/testsuite/g++.dg/abi/pr39188-1a.C
  c96cb62975d4855a114a03ac254e17ce  gcc/testsuite/g++.dg/abi/pr39188-1b.C
*************** fb777e6427f4a224508112af8340c3d4  gcc/te
*** 13016,13021 ****
--- 13024,13030 ----
  ca4a8065918a3119cb5474bacec801f2  gcc/testsuite/g++.dg/asan/pr102656.C
  b03be3a03970717959df65ccdcbebe88  gcc/testsuite/g++.dg/asan/pr104449.C
  350e8cfd78cd243b5ca66f3b0149e4b7  gcc/testsuite/g++.dg/asan/pr118763.C
+ 97d271ad3822668b82fdab6ac348be35  gcc/testsuite/g++.dg/asan/pr120201-1.C
  e472f2ce37f2b55b1358ec08717d9f08  gcc/testsuite/g++.dg/asan/pr55617.C
  74a04a20e12a8acd0fd7d05742cf8d63  gcc/testsuite/g++.dg/asan/pr62017.C
  505943436d80a41b5e95bf0b67db97cd  gcc/testsuite/g++.dg/asan/pr64937.C
*************** c11fb9d024f89aea2e027172cee4bda2  gcc/te
*** 14172,14177 ****
--- 14181,14187 ----
  5319a9de79517accc19d4cb1801c0616  gcc/testsuite/g++.dg/cpp0x/constexpr-104226.C
  eeac975a1b841cef4d5a4c468314ed8c  gcc/testsuite/g++.dg/cpp0x/constexpr-104472.C
  6ef86dfa8bcd129320f2714974f8ad93  gcc/testsuite/g++.dg/cpp0x/constexpr-105321.C
+ cf48bd83fff3e69e5f82d30185ef08d0  gcc/testsuite/g++.dg/cpp0x/constexpr-123889.C
  3e4cac522763806230540d3da6cc5ee1  gcc/testsuite/g++.dg/cpp0x/constexpr-46336.C
  d079e67f3b2be485ac7aed93b70984d2  gcc/testsuite/g++.dg/cpp0x/constexpr-46420.C
  329a82a822423273c0c0256fd27a6d52  gcc/testsuite/g++.dg/cpp0x/constexpr-47570.C
*************** b9007290e56f8c058df6fc2174bc755b  gcc/te
*** 14244,14249 ****
--- 14254,14261 ----
  b2e8cc3ca2686458232f6ab8399d9dda  gcc/testsuite/g++.dg/cpp0x/constexpr-93169.C
  bc7ccf4287a38e8f82df800db6150879  gcc/testsuite/g++.dg/cpp0x/constexpr-95307.C
  32c39fce8b20cb104d6da1cffca8a530  gcc/testsuite/g++.dg/cpp0x/constexpr-96241.C
+ 629f0389a900c8203177e0396b4ac416  gcc/testsuite/g++.dg/cpp0x/constexpr-97740a.C
+ eb45e434ffc94954a98ab41dfca4430c  gcc/testsuite/g++.dg/cpp0x/constexpr-97740b.C
  6aa74413b4ef74580a0a5da7abf23914  gcc/testsuite/g++.dg/cpp0x/constexpr-98.C
  5f550fa68a208c2d1f3f6d02dca0b709  gcc/testsuite/g++.dg/cpp0x/constexpr-98295.C
  d08d3bdb37be475451a39fd6f72486e9  gcc/testsuite/g++.dg/cpp0x/constexpr-99.C
*************** dfc43f4a6c6619f77e2370dc3ac7c5bd  gcc/te
*** 14350,14355 ****
--- 14362,14368 ----
  df7772e8bce1917bb8d1e66fcbe1ce31  gcc/testsuite/g++.dg/cpp0x/constexpr-ctor2.C
  50c4fa620f7ec653b83dbc313350ac22  gcc/testsuite/g++.dg/cpp0x/constexpr-ctor20.C
  75570067f1748bbf63ecff0edf089f3f  gcc/testsuite/g++.dg/cpp0x/constexpr-ctor21.C
+ c3ffed418366431e337c777209f796c0  gcc/testsuite/g++.dg/cpp0x/constexpr-ctor23.C
  6149d79aef3c5dc04bce76d97b8072e3  gcc/testsuite/g++.dg/cpp0x/constexpr-ctor3.C
  fe03ae0923ec0f159b32d4c95a97afbb  gcc/testsuite/g++.dg/cpp0x/constexpr-ctor4.C
  a15ac39628455598191a6c7526c0ea4b  gcc/testsuite/g++.dg/cpp0x/constexpr-ctor5.C
*************** cf5dbf6e27520dc069362029f5cb0540  gcc/te
*** 14406,14412 ****
  0639a526e3e93a7d7ddd53722d0d65a4  gcc/testsuite/g++.dg/cpp0x/constexpr-empty9.C
  de31aeecff5f54f6a1e2a6e6e8096298  gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
  4e6fff7f5e83663f75c94efbf299525b  gcc/testsuite/g++.dg/cpp0x/constexpr-ex2.C
! c42ce017f72e0ac9bc977500bc2d096c  gcc/testsuite/g++.dg/cpp0x/constexpr-ex3.C
  ce75146a9a51521a3b4ff82cc14225c3  gcc/testsuite/g++.dg/cpp0x/constexpr-ex4.C
  19eb610e0af0918f7473197af97c60d4  gcc/testsuite/g++.dg/cpp0x/constexpr-expinst.C
  54953d2c31360e2eeefa3305044bd360  gcc/testsuite/g++.dg/cpp0x/constexpr-explicit-inst.C
--- 14419,14425 ----
  0639a526e3e93a7d7ddd53722d0d65a4  gcc/testsuite/g++.dg/cpp0x/constexpr-empty9.C
  de31aeecff5f54f6a1e2a6e6e8096298  gcc/testsuite/g++.dg/cpp0x/constexpr-ex1.C
  4e6fff7f5e83663f75c94efbf299525b  gcc/testsuite/g++.dg/cpp0x/constexpr-ex2.C
! ee1630d30fdca78fd9a901d17054b392  gcc/testsuite/g++.dg/cpp0x/constexpr-ex3.C
  ce75146a9a51521a3b4ff82cc14225c3  gcc/testsuite/g++.dg/cpp0x/constexpr-ex4.C
  19eb610e0af0918f7473197af97c60d4  gcc/testsuite/g++.dg/cpp0x/constexpr-expinst.C
  54953d2c31360e2eeefa3305044bd360  gcc/testsuite/g++.dg/cpp0x/constexpr-explicit-inst.C
*************** a174690fe306aaf345b02df91c3ddebe  gcc/te
*** 15912,15917 ****
--- 15925,15932 ----
  fa773bb98628f5c9f0fa9d8d8b29beda  gcc/testsuite/g++.dg/cpp0x/pr107065.C
  69f8f66bd163b5bad0e399b5155f053b  gcc/testsuite/g++.dg/cpp0x/pr108698.C
  c6b0d9f964bf85f5f703f5dfa5e809e9  gcc/testsuite/g++.dg/cpp0x/pr119123.C
+ b2f7d7cab4ef6e12f25f82545d59869a  gcc/testsuite/g++.dg/cpp0x/pr123818.C
+ 823666b75dc5cb540393daba4df2d5df  gcc/testsuite/g++.dg/cpp0x/pr124489.C
  26dea799d49ce223a0c4130a3c955271  gcc/testsuite/g++.dg/cpp0x/pr31431-2.C
  4d1da29b669bf3178b3987abce4d58b1  gcc/testsuite/g++.dg/cpp0x/pr31431.C
  d65e06a3830e2b511cc25692b94615a1  gcc/testsuite/g++.dg/cpp0x/pr31432.C
*************** ccba3040ed86b5ffae7d72b18f556d1c  gcc/te
*** 16242,16247 ****
--- 16257,16263 ----
  0a9a74fc1be6ebe8c0f8c42d06cbc453  gcc/testsuite/g++.dg/cpp0x/rv-conv2.C
  55bf372aa23fed509d52b517cd46aa98  gcc/testsuite/g++.dg/cpp0x/rv-conv3.C
  889a7002f4d78b4abd44856da792f8dc  gcc/testsuite/g++.dg/cpp0x/rv-copy1.C
+ fa930410478009be16ff5c21544f405c  gcc/testsuite/g++.dg/cpp0x/rv-decl1.C
  de88aaa56b0d394bd02f079bb0f4dddf  gcc/testsuite/g++.dg/cpp0x/rv-deduce.C
  f213598004dcfd0117fecc9593637790  gcc/testsuite/g++.dg/cpp0x/rv-deduce2.C
  589e28fb5e0fffb1d369fc47ca52bcfd  gcc/testsuite/g++.dg/cpp0x/rv-dotstar.C
*************** e791b94844e59093ad5ec4175c3b673a  gcc/te
*** 16877,16882 ****
--- 16893,16899 ----
  86dff67be95912f694daebdd0aee911b  gcc/testsuite/g++.dg/cpp1y/auto-fn63.C
  f97d20d3d680128b6e125d1793e29b87  gcc/testsuite/g++.dg/cpp1y/auto-fn64.C
  a5fbd625e8b645b90b2755400e929e2b  gcc/testsuite/g++.dg/cpp1y/auto-fn65.C
+ 88309773bbf1feef7121ba73e86cc151  gcc/testsuite/g++.dg/cpp1y/auto-fn66.C
  03b6f2674c38c8f6ed9f7fc03583b1dc  gcc/testsuite/g++.dg/cpp1y/auto-fn7.C
  e9a317fa32e36cef4553b50965e48550  gcc/testsuite/g++.dg/cpp1y/auto-fn8.C
  d67958b896eb1dae6f8862fd59b01c62  gcc/testsuite/g++.dg/cpp1y/auto-fn9.C
*************** b18c63a0e6b162de2b47ab0e61b704bd  gcc/te
*** 16900,16905 ****
--- 16917,16923 ----
  afbdcf440b8da95f919e745c0f3a85d1  gcc/testsuite/g++.dg/cpp1y/constexpr-105774.C
  bff4672a992bc57b0432abbc32b3c2c9  gcc/testsuite/g++.dg/cpp1y/constexpr-108158.C
  1d40cabd787f31f0fad7fcf842281e0d  gcc/testsuite/g++.dg/cpp1y/constexpr-110382.C
+ 99784bf84926c6a7d522ec738bd5f9aa  gcc/testsuite/g++.dg/cpp1y/constexpr-121445.C
  2d72668eefa5659edd32ef8dabc1c48e  gcc/testsuite/g++.dg/cpp1y/constexpr-50060.C
  9b2030f5f70b0e913feb1b957c799f4f  gcc/testsuite/g++.dg/cpp1y/constexpr-66093.C
  9ecc58eab147adafbf3780c51ed706fc  gcc/testsuite/g++.dg/cpp1y/constexpr-70265-1.C
*************** f8cacc42b6d0ee02c4ec28b4871b946c  gcc/te
*** 17072,17077 ****
--- 17090,17096 ----
  e210eaaa7545615d95f00423c888ec15  gcc/testsuite/g++.dg/cpp1y/decltype-auto4.C
  194055ab7fa17e843b9e74ef24b2d117  gcc/testsuite/g++.dg/cpp1y/decltype-auto5.C
  29d019b91f9e9754780b3f7d3b824a43  gcc/testsuite/g++.dg/cpp1y/decltype-auto6.C
+ bdf42806bc072f01f4ad0c2f053df450  gcc/testsuite/g++.dg/cpp1y/decltype-auto9.C
  516d0cef75f4267f67d755a810807bc2  gcc/testsuite/g++.dg/cpp1y/digit-sep-cxx11-neg.C
  689cbb9207e775c0f7572b0587fbd4fd  gcc/testsuite/g++.dg/cpp1y/digit-sep-line-neg.C
  b0b8339395130310f925dd038dff1c6c  gcc/testsuite/g++.dg/cpp1y/digit-sep-line.C
*************** e6baed7e5941603d690b9c2c737ea663  gcc/te
*** 17802,17807 ****
--- 17821,17827 ----
  63be3b6d75aa3c2c8088552683d5245e  gcc/testsuite/g++.dg/cpp1z/eval-order10.C
  3abc6084e572264410718d38beb290bb  gcc/testsuite/g++.dg/cpp1z/eval-order11.C
  2a2d4866a044c20823b5f37f629ac147  gcc/testsuite/g++.dg/cpp1z/eval-order13.C
+ 612e7cfe92accd2bee31cd13a0976f33  gcc/testsuite/g++.dg/cpp1z/eval-order14.C
  bb194d9ce590c9e5e69935ebac0f25e4  gcc/testsuite/g++.dg/cpp1z/eval-order2.C
  8b89dee7164b6f4d992706e5b85433f4  gcc/testsuite/g++.dg/cpp1z/eval-order3.C
  6d8d378fedaf65b4cb89952060799280  gcc/testsuite/g++.dg/cpp1z/eval-order4.C
*************** ae3e1959f85f05c9ec509a6dbdbe24ca  gcc/te
*** 17975,17980 ****
--- 17995,18001 ----
  2d69a9b79c8f3fadb2bfb68b9d761c49  gcc/testsuite/g++.dg/cpp1z/nontype4a.C
  914a640ece1bdc2a12062de65d60a78d  gcc/testsuite/g++.dg/cpp1z/nontype5.C
  1a73a13a161c05eab6182bb64cba004b  gcc/testsuite/g++.dg/cpp1z/nontype7.C
+ ad7260377d53bd5be2c8dfecf32c3fc2  gcc/testsuite/g++.dg/cpp1z/nontype9.C
  86d3c074d77c88bd7ef317faea9d2968  gcc/testsuite/g++.dg/cpp1z/pr115440.C
  e668ace19a2b0d8946e0e19fd8317af1  gcc/testsuite/g++.dg/cpp1z/pr78771.C
  bc5edc17d9b70d77a054dd4736a66223  gcc/testsuite/g++.dg/cpp1z/pr79143.C
*************** f35c40f9359deda380357490b21bcf4f  gcc/te
*** 18000,18005 ****
--- 18021,18027 ----
  1cec7e8e1ac5999209a00a7fd3e2dbab  gcc/testsuite/g++.dg/cpp1z/static1.C
  41cdf88b4e2dc9ba29ab954fd0f3d05c  gcc/testsuite/g++.dg/cpp1z/static2.C
  491588e8dd93d83d5049e3c332e8755f  gcc/testsuite/g++.dg/cpp1z/static_assert-nomsg.C
+ d123582c5d5cdc2e4fdc925fa563f023  gcc/testsuite/g++.dg/cpp1z/static_assert1.C
  7dd3448d4722a9ee0446db6aa3c7a0b0  gcc/testsuite/g++.dg/cpp1z/ttp1.C
  0cd62ffa5ae2d02bd665e02895b12f01  gcc/testsuite/g++.dg/cpp1z/ttp2.C
  64b3f9e4e9d3f04ac339e1f86e353e9b  gcc/testsuite/g++.dg/cpp1z/typename-tmpl-tmpl-parm-neg.C
*************** f2780bc5fd525d2709b14d4b73adff01  gcc/te
*** 18062,18067 ****
--- 18084,18090 ----
  d132bd3d955db10a4c1bdd4e4fb66f69  gcc/testsuite/g++.dg/cpp23/auto-fncast12.C
  c6ad3dc1af7ae5c57b2194ad705be2a4  gcc/testsuite/g++.dg/cpp23/auto-fncast13.C
  5464572dd400e693935b759dd0a5828a  gcc/testsuite/g++.dg/cpp23/auto-fncast14.C
+ 7538b8341492d3e37f991c7d882723b9  gcc/testsuite/g++.dg/cpp23/auto-fncast19.C
  76d2964f5d2d58ccec6afc73c59f1b53  gcc/testsuite/g++.dg/cpp23/auto-fncast2.C
  dda23dff758a778a7ead9dd8b58268fc  gcc/testsuite/g++.dg/cpp23/auto-fncast3.C
  7f7896e62e131143c799cd8b4ac52168  gcc/testsuite/g++.dg/cpp23/auto-fncast4.C
*************** edb46bdf72eaeb378f5f0d557153ad9d  gcc/te
*** 18301,18306 ****
--- 18324,18331 ----
  ce0107015099b9bc8bbb6308d69d1335  gcc/testsuite/g++.dg/cpp2a/concepts-decltype2.C
  20942197b42aecb2031c455e6c7139db  gcc/testsuite/g++.dg/cpp2a/concepts-decltype3.C
  bd5315a1ae1bb7ab6b080320eca4e7cc  gcc/testsuite/g++.dg/cpp2a/concepts-decltype4.C
+ 22508583fabe144a053070d600a2f4ff  gcc/testsuite/g++.dg/cpp2a/concepts-decltype5.C
+ c2e23a46012960cb2717300e180866e4  gcc/testsuite/g++.dg/cpp2a/concepts-decltype6.C
  2ff1559b74cd8147b9de258edac783b1  gcc/testsuite/g++.dg/cpp2a/concepts-defarg1.C
  8b450b687a58857141c45425bdbf8e80  gcc/testsuite/g++.dg/cpp2a/concepts-defarg2.C
  e0a60fccd4fe206005be1e84cfb2682d  gcc/testsuite/g++.dg/cpp2a/concepts-defarg3.C
*************** a7e2f7d20a67204e43ab8b4439aa4e77  gcc/te
*** 18374,18379 ****
--- 18399,18405 ----
  db4d7afa9cc5c159bbf139e868fd3544  gcc/testsuite/g++.dg/cpp2a/concepts-lambda19.C
  c61f89754bf19eb066c90223050eb1d6  gcc/testsuite/g++.dg/cpp2a/concepts-lambda2.C
  2cdd3df6d70a6187c69e0b2e31916579  gcc/testsuite/g++.dg/cpp2a/concepts-lambda20.C
+ c5f62ec8bee71a828d47886f4bfb04dc  gcc/testsuite/g++.dg/cpp2a/concepts-lambda24.C
  c1dc95530d3c5579fce346628c40061a  gcc/testsuite/g++.dg/cpp2a/concepts-lambda3.C
  6f185f0a7016ab67c7f0d4ffa7012182  gcc/testsuite/g++.dg/cpp2a/concepts-lambda4.C
  86976d8466300862e381a2182c187b35  gcc/testsuite/g++.dg/cpp2a/concepts-lambda5.C
*************** b48de652a269ba0411d9c971e6b06869  gcc/te
*** 18428,18433 ****
--- 18454,18460 ----
  966bf7435554a7a150aa0fb09697b04c  gcc/testsuite/g++.dg/cpp2a/concepts-placeholder11.C
  f57d40e8c8a062ab42228a604dc8b336  gcc/testsuite/g++.dg/cpp2a/concepts-placeholder12.C
  3d20f95d326918d497b3b309b9eda0d9  gcc/testsuite/g++.dg/cpp2a/concepts-placeholder13.C
+ 10165b900c5003d3691cd5cf5fae858b  gcc/testsuite/g++.dg/cpp2a/concepts-placeholder15.C
  9a1776b1d9b3c080e847b78507e8c1c6  gcc/testsuite/g++.dg/cpp2a/concepts-placeholder2.C
  d4ce4a5306e35eff2b78390b50d6c95b  gcc/testsuite/g++.dg/cpp2a/concepts-placeholder3.C
  e428d578c8a0c5a61ab85eddccb24071  gcc/testsuite/g++.dg/cpp2a/concepts-placeholder4.C
*************** fc797eabdd1dc0d22609e8841d633f99  gcc/te
*** 18440,18445 ****
--- 18467,18474 ----
  93d1e55f1ec8ecc0589c4cf386fc18c7  gcc/testsuite/g++.dg/cpp2a/concepts-pr104410.C
  d730bf14b7c6a0ff4579eb13739f7d2f  gcc/testsuite/g++.dg/cpp2a/concepts-pr108579.C
  4b3fe1ba64fb6a81fe92d55b090adf3a  gcc/testsuite/g++.dg/cpp2a/concepts-pr116681.C
+ 24814124a2638795704cea1177c1d93c  gcc/testsuite/g++.dg/cpp2a/concepts-pr122494.C
+ c3a5a8ffeaedc47bb7c475c240bce1c2  gcc/testsuite/g++.dg/cpp2a/concepts-pr123814.C
  2e23f19968091d773a47c43a32a784ae  gcc/testsuite/g++.dg/cpp2a/concepts-pr58500.C
  07c6a4dff1357ef61c0d30b12db5c948  gcc/testsuite/g++.dg/cpp2a/concepts-pr58534.C
  b6ba42db630bfd3259d65662fc03aaa0  gcc/testsuite/g++.dg/cpp2a/concepts-pr58535.C
*************** b5f4f9a8f5933754f321648f67e54dac  gcc/te
*** 18709,18714 ****
--- 18738,18745 ----
  1a30baf82f09866d37d6e96a76379f47  gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic16.C
  aa504b7ff788990adcf5e4c4b174e0ae  gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic17.C
  8fe226b0e900985b1f76643e8aaf737b  gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic18.C
+ ba2b3d3cd6f23028bc237ee7025256fb  gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic19.C
+ dd98bfd651ed53723db105ea6def894e  gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic1a.C
  6a856dd4720aaf5ca7ba6e7422f849a9  gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic2.C
  6ddf97a1878f89c02ca0c76de5f0f08f  gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic3.C
  28c0eaf9ba35a479b5d50ddb90e7dc07  gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic4.C
*************** ac9bb69a57b021f97f435bdd64fdc923  gcc/te
*** 18757,18762 ****
--- 18788,18795 ----
  56cf7b227da9e5878b8fab57be913c5e  gcc/testsuite/g++.dg/cpp2a/constexpr-new20.C
  c045618ca4ccc6ddfb47d7c232152a06  gcc/testsuite/g++.dg/cpp2a/constexpr-new21.C
  8f15e7c6c4a56e33628394c948bba9aa  gcc/testsuite/g++.dg/cpp2a/constexpr-new22.C
+ 27208da003125c43373cb29367bffb95  gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
+ 842eb288f31fa0fd04ade7dce7711c8f  gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C
  d1fc949626e604a60a7cd826bb9fe696  gcc/testsuite/g++.dg/cpp2a/constexpr-new3.C
  44e96a6cfd450fc9d40c13cc7a4e98f3  gcc/testsuite/g++.dg/cpp2a/constexpr-new4.C
  09667d3c51ef176269e12b2ece101f3d  gcc/testsuite/g++.dg/cpp2a/constexpr-new5.C
*************** c4beb3372cb0e77f36a788efb02031c2  gcc/te
*** 18765,18773 ****
  d29f558af48deff313645aecd90adb8d  gcc/testsuite/g++.dg/cpp2a/constexpr-new8.C
  89741a348551bf62e5198e689a2cb9eb  gcc/testsuite/g++.dg/cpp2a/constexpr-new9.C
  fe2e298a3cf2e9094a79a25a4ffd8fc2  gcc/testsuite/g++.dg/cpp2a/constexpr-shift1.C
! 1d1e610556de3295af12cf17177f42b7  gcc/testsuite/g++.dg/cpp2a/constexpr-try1.C
! 27ac7e1957f04ea6ee6160a7f7c14ecc  gcc/testsuite/g++.dg/cpp2a/constexpr-try2.C
! c169c0f663257a769b1da0d94c0c7307  gcc/testsuite/g++.dg/cpp2a/constexpr-try3.C
  d74e93a21b21eb22ce0742e9b6bbb923  gcc/testsuite/g++.dg/cpp2a/constexpr-try4.C
  02c2a396d7fac0a627ada9a52c486da3  gcc/testsuite/g++.dg/cpp2a/constexpr-try5.C
  e8575fbcf5a3e212ea28a4b89fbf8253  gcc/testsuite/g++.dg/cpp2a/constexpr-typeid1.C
--- 18798,18806 ----
  d29f558af48deff313645aecd90adb8d  gcc/testsuite/g++.dg/cpp2a/constexpr-new8.C
  89741a348551bf62e5198e689a2cb9eb  gcc/testsuite/g++.dg/cpp2a/constexpr-new9.C
  fe2e298a3cf2e9094a79a25a4ffd8fc2  gcc/testsuite/g++.dg/cpp2a/constexpr-shift1.C
! 1f5b8000b29315ba3af28b7bd9f18540  gcc/testsuite/g++.dg/cpp2a/constexpr-try1.C
! 998420d0a57cce98957e79abdb9865d3  gcc/testsuite/g++.dg/cpp2a/constexpr-try2.C
! 7735fb04b9642ba24ab00207340cff41  gcc/testsuite/g++.dg/cpp2a/constexpr-try3.C
  d74e93a21b21eb22ce0742e9b6bbb923  gcc/testsuite/g++.dg/cpp2a/constexpr-try4.C
  02c2a396d7fac0a627ada9a52c486da3  gcc/testsuite/g++.dg/cpp2a/constexpr-try5.C
  e8575fbcf5a3e212ea28a4b89fbf8253  gcc/testsuite/g++.dg/cpp2a/constexpr-typeid1.C
*************** d61cc66863701219edff4cd7fe87ebb9  gcc/te
*** 18922,18927 ****
--- 18955,18961 ----
  c158bbb4df76b9867cf177e079c2ce23  gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated13.C
  bc1c49df918c7bedb2c04165b007f136  gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated14.C
  13b8a2f12e5511e8657e1c29bb0f8073  gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated15.C
+ 492b06a1a3a2082a82c1c64332111201  gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated16.C
  4617b7d86ad3299b351c033f194bee8a  gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated2.C
  73b56ba004639bd18c7c3c95c3bfd080  gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated3.C
  5c37b5cacdb70688ac2e90c563d9613c  gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated4.C
*************** c79632f5b81fdadda65a61ca549d97f6  gcc/te
*** 18990,18995 ****
--- 19024,19030 ----
  e1f6714196bc4cc815de786f8301141d  gcc/testsuite/g++.dg/cpp2a/lambda-uneval17.C
  e99d0c361f9eaa55d53c9232f30b64cf  gcc/testsuite/g++.dg/cpp2a/lambda-uneval2.C
  5f89a0a811ca20d222ad6994a619a023  gcc/testsuite/g++.dg/cpp2a/lambda-uneval24.C
+ e59f63d278e1f049c181594746f34930  gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C
  95297857429ac8850dbeb5773639ea6b  gcc/testsuite/g++.dg/cpp2a/lambda-uneval3.C
  2f7bd1774e5f890e65ee937419a29669  gcc/testsuite/g++.dg/cpp2a/lambda-uneval4.C
  8e6b610dd3dab06841943bfa5f325489  gcc/testsuite/g++.dg/cpp2a/lambda-uneval5.C
*************** ddb0c78842f6b4e3e4606849bc1a4a82  gcc/te
*** 19143,19148 ****
--- 19178,19184 ----
  fc8ccbfe7f14dd4a41ff708c5a05b226  gcc/testsuite/g++.dg/cpp2a/paren-init9.C
  9d5c0df7ab0b6e3e5ab03bc8eb135452  gcc/testsuite/g++.dg/cpp2a/pr117317-1.C
  4b52a1949fed25dc03d5cfb83047e7c5  gcc/testsuite/g++.dg/cpp2a/pr117317-2.C
+ 938acbb8068f7a8fc2c3f43271324ef4  gcc/testsuite/g++.dg/cpp2a/pr123578.C
  7d1c1719a1c3e44cf69662819769f8a5  gcc/testsuite/g++.dg/cpp2a/pr88534.C
  3a4139bbe15eef2dce96cb020b2681f7  gcc/testsuite/g++.dg/cpp2a/pr88537.C
  b94ce4741edeca1190c4590e425522dc  gcc/testsuite/g++.dg/cpp2a/pr89913.C
*************** becc0e6f064af285a504ff10eaffc525  gcc/te
*** 19580,19585 ****
--- 19616,19623 ----
  204f6d67816240aa15bfa5d9320862f5  gcc/testsuite/g++.dg/dfp/mangle-6.C
  8b4d16a77a1edab85ee4c99fda03eb79  gcc/testsuite/g++.dg/dfp/mangle-mode.C
  3a865b01c504023d0b90b1f055163c6a  gcc/testsuite/g++.dg/dfp/nofields.C
+ fd0549fb3825f83ce2ac884838fe2187  gcc/testsuite/g++.dg/dfp/pr122834-1.C
+ 87b1932d8497bd7b8b41f36fb0c23208  gcc/testsuite/g++.dg/dfp/pr122834-2.C
  919ff80bde2b401e1cf10423071bab16  gcc/testsuite/g++.dg/dfp/pr92744.C
  cd0133a632a541db051ef84d53754ac6  gcc/testsuite/g++.dg/dfp/typeid1.C
  69cbd7b4b86323de45b6388e2fc2366b  gcc/testsuite/g++.dg/dg.exp
*************** bd9556c57358bc478181fd7105e19b2f  gcc/te
*** 21166,21171 ****
--- 21204,21210 ----
  e1073bec80cbc48fb15e02126aebb2b0  gcc/testsuite/g++.dg/gomp/pr107558.C
  641b551c65455ce91907afab3c572a40  gcc/testsuite/g++.dg/gomp/pr108503.C
  e6195ed8251ecef3da90dc8d0e37ed89  gcc/testsuite/g++.dg/gomp/pr108607.C
+ 996def323ebaae8304a543404625c64a  gcc/testsuite/g++.dg/gomp/pr121977.C
  539bba6df5330b7a6631eca5665a0899  gcc/testsuite/g++.dg/gomp/pr24849.C
  78ea34fd7a1a2767f61a703271e7070a  gcc/testsuite/g++.dg/gomp/pr25874.C
  93a85a09acfdf011a86ff95fc9184a94  gcc/testsuite/g++.dg/gomp/pr25996.C
*************** ecfa94e705bc436ad699767b1e4c929e  gcc/te
*** 21965,21976 ****
--- 22004,22017 ----
  55ee7bff7cc115f42266bd1d62dda46b  gcc/testsuite/g++.dg/ipa/pr100413.C
  901698e6dabf29dd6ced031811fcf59e  gcc/testsuite/g++.dg/ipa/pr103099.C
  f2ff4523ab9758b8e447b088ac708879  gcc/testsuite/g++.dg/ipa/pr106258.C
+ 4b93844d472e68bdcc050f5ef8ce7079  gcc/testsuite/g++.dg/ipa/pr106260.C
  c43cd4a90674d630795e0323738e0460  gcc/testsuite/g++.dg/ipa/pr107661.C
  7d63c0342d026b9ee4f2ecb03364cefe  gcc/testsuite/g++.dg/ipa/pr108110.C
  9a257f3564fd42fe9d7e00c5567f89d2  gcc/testsuite/g++.dg/ipa/pr108509.C
  9cf2cc98e56a48a7332ea02be0425960  gcc/testsuite/g++.dg/ipa/pr108830.C
  e66c84f48f938ed2bb548ce51957afce  gcc/testsuite/g++.dg/ipa/pr113757.C
  9183db2978d574bc26d43a0d942ec920  gcc/testsuite/g++.dg/ipa/pr118243.C
+ 2e880749089a9c6febba9ae1fa0de490  gcc/testsuite/g++.dg/ipa/pr122856.C
  02f3704c0511b2d171c55dbf09c64325  gcc/testsuite/g++.dg/ipa/pr43695.C
  5345293723ad062b59b168c319738e1e  gcc/testsuite/g++.dg/ipa/pr43812.C
  b001cbe3dfdeb7d2a1061f024aa08ea4  gcc/testsuite/g++.dg/ipa/pr44372.C
*************** eb2e0f01c9a4d46c1646751931cacef7  gcc/te
*** 23862,23867 ****
--- 23903,23909 ----
  020cc92178f45d27f797218781bfe02c  gcc/testsuite/g++.dg/no-stack-protector-attr.C
  8782d87c3ab6e3b20b317d9f1492e146  gcc/testsuite/g++.dg/opt/20050511-1.C
  5e1f1ec360f2ae54c78ee347de5c583f  gcc/testsuite/g++.dg/opt/20181025-1.C
+ 169bea5dd58c1746026b7e4924bbd199  gcc/testsuite/g++.dg/opt/20260703-1.C
  960bd912d3dccb44df0ecdebdfd45b44  gcc/testsuite/g++.dg/opt/alias1.C
  15bcb0db43b0a7c6f0b1a4ff014da35d  gcc/testsuite/g++.dg/opt/alias2.C
  91fe29b9b1f08a3ca87595896db03497  gcc/testsuite/g++.dg/opt/alias3.C
*************** fc956d5d39ddca9870d1a2fca7df287d  gcc/te
*** 24049,24054 ****
--- 24091,24097 ----
  b66c56d1ba4ee568e881df0560f18827  gcc/testsuite/g++.dg/opt/pr109462.C
  b8fef9a1bd09e90415f3e35f5466c85c  gcc/testsuite/g++.dg/opt/pr110515.C
  149c3b47d16cfa08669bf79341552440  gcc/testsuite/g++.dg/opt/pr119327.C
+ 46bab0272c3e399fa4db680833cb9a89  gcc/testsuite/g++.dg/opt/pr122394.C
  2896f5b1a96dd9fabb1dbb65cb4c5921  gcc/testsuite/g++.dg/opt/pr13066-1.C
  4f87f86b9f018cae74888e97468b2fe0  gcc/testsuite/g++.dg/opt/pr14029.C
  8fb7e68e9e9b5eb02628e03f5333e645  gcc/testsuite/g++.dg/opt/pr14888.C
*************** a0196ebfddfdcb265613530b34c75302  gcc/te
*** 24365,24370 ****
--- 24408,24414 ----
  d0b5965b4982fc2453056380914a719f  gcc/testsuite/g++.dg/other/anon-union5.C
  498c728995604cce6cd6fb0603cfbad8  gcc/testsuite/g++.dg/other/anon-union6.C
  4f90ececca3ff47581ca71749fda9c86  gcc/testsuite/g++.dg/other/anon-union7.C
+ fe4ccc701c313926fdf04eb36eca6435  gcc/testsuite/g++.dg/other/anon-union8.C
  25bec11b40119085408d52eaa5b86f6e  gcc/testsuite/g++.dg/other/anon2.C
  ac03cab67f2c4f5731d36b19f2ee4f42  gcc/testsuite/g++.dg/other/anon3.C
  735bc52cab8eca56a711c2c10845c981  gcc/testsuite/g++.dg/other/anon4.C
*************** f3924301e9a75e88ee237b6baeb316be  gcc/te
*** 24987,24992 ****
--- 25031,25037 ----
  73b1cabb6ebba6515fc142024f664fa3  gcc/testsuite/g++.dg/parse/crash70.C
  78546442b1a4a93b74bc9a74697998e4  gcc/testsuite/g++.dg/parse/crash71.C
  c3945b36146c7d629c7336eb3f9329fe  gcc/testsuite/g++.dg/parse/crash77.C
+ 23b7108a88804e5cf4c0a9d029afae56  gcc/testsuite/g++.dg/parse/crash81.C
  5818f331167c496db06ad694932a1beb  gcc/testsuite/g++.dg/parse/crash9.C
  5940e29a523673e2c47048c21c11d678  gcc/testsuite/g++.dg/parse/ctor1.C
  6a4d22d64949d622a19d9e79684aad65  gcc/testsuite/g++.dg/parse/ctor10.C
*************** ce5771924fa5fd60b270c30c11bee489  gcc/te
*** 25245,25250 ****
--- 25290,25297 ----
  290161573b66c49ae4261f07f77681d3  gcc/testsuite/g++.dg/parse/parser-pr28152-2.C
  a0fee4f3ee4678b54afd993b619baa05  gcc/testsuite/g++.dg/parse/parser-pr28152.C
  19f7d11d9ad101a38756eab150921947  gcc/testsuite/g++.dg/parse/pr101783.C
+ 732ccde523003692267913067f6a0ccd  gcc/testsuite/g++.dg/parse/pr120471.C
+ 225e1d7f8cf80186eac35ff37acc9379  gcc/testsuite/g++.dg/parse/pr120940.C
  2dde7d845edb3fc1b6b06c1f7c1d71f6  gcc/testsuite/g++.dg/parse/pr16696-permissive.C
  f8326578679fecd658e1bec2d3ed7654  gcc/testsuite/g++.dg/parse/pr16696.C
  29f6ba15da1283765b5179abe6707d09  gcc/testsuite/g++.dg/parse/pr18770.C
*************** b8d7ae2a709e06f2d49e19cfb00e77d3  gcc/te
*** 25983,25988 ****
--- 26030,26037 ----
  fc503a6c4d63b92622d495b917629877  gcc/testsuite/g++.dg/template/bitfield2.C
  8a0fec8b2c65fed33977466ab46bb239  gcc/testsuite/g++.dg/template/bitfield3.C
  3beaec71f8c3eee7f77d4f01acdfd9c8  gcc/testsuite/g++.dg/template/bitfield4.C
+ 0943a2ed1de251cec2159b8a51827115  gcc/testsuite/g++.dg/template/bitfield5.C
+ d3445364009e0426fd4a308fcd2abf5c  gcc/testsuite/g++.dg/template/bitfield6.C
  479ce6c62d0ab31928edd3bcef27bd5c  gcc/testsuite/g++.dg/template/builtin1.C
  2f695f5e6701fd2021f98c6f4737f36a  gcc/testsuite/g++.dg/template/builtin2.C
  11d89720e8ea4a5f11553338c13ffab9  gcc/testsuite/g++.dg/template/call1.C
*************** b705911769b4dedde26fc55666525547  gcc/te
*** 26411,26416 ****
--- 26460,26466 ----
  b21023a383690906d31ed5c2f45cd122  gcc/testsuite/g++.dg/template/fn-ptr3b.C
  2137f89260c82e219c89d76cc24abafa  gcc/testsuite/g++.dg/template/fn-ptr4.C
  15c91b52ba262150255ee24fc766130a  gcc/testsuite/g++.dg/template/fn-ptr5.C
+ 9b70bd323857b4dedfeb3ec4e118c6ad  gcc/testsuite/g++.dg/template/fn-ptr6.C
  636ef7c6b9de68376146848db023fb19  gcc/testsuite/g++.dg/template/fn-ref1.C
  f85ab66eeb2b191e2fee2b0b5013d956  gcc/testsuite/g++.dg/template/fn.C
  1581f9141ad183d6d31a009275ebf7a4  gcc/testsuite/g++.dg/template/fnspec1.C
*************** e8eff4c0ef885b002db007e536bb99f2  gcc/te
*** 27566,27577 ****
--- 27616,27636 ----
  4b7c75dc51b97d5dc81c7e936ff3b460  gcc/testsuite/g++.dg/torture/pr111019.C
  6766aa21b009a63d71d22aa6baba228d  gcc/testsuite/g++.dg/torture/pr111245.C
  25af1620df0107cd03f275ddc7fd98b6  gcc/testsuite/g++.dg/torture/pr111465.C
+ 5c620542544d327d513aa9525aba2286  gcc/testsuite/g++.dg/torture/pr112400.C
  f5cb8caa482838045861d5ee18445814  gcc/testsuite/g++.dg/torture/pr113896.C
  6c3c5585841ff28b7c4ab8a61978f689  gcc/testsuite/g++.dg/torture/pr113994.C
  ef666186552a9562e70783bbdf98ac33  gcc/testsuite/g++.dg/torture/pr115694.C
+ 433f2d5d832623625319b4192fc7b69c  gcc/testsuite/g++.dg/torture/pr117217-1.C
+ 370446845d836416f63d6f4ab2dbab30  gcc/testsuite/g++.dg/torture/pr117217-2.C
  f298eddbaaad3dfdc15f6cf9683ff08a  gcc/testsuite/g++.dg/torture/pr11911.C
  9df51f0b5a7e716286f2e97dfd28d477  gcc/testsuite/g++.dg/torture/pr119610.C
  9cede7e8b587157ccdf0f9f6667d6cc8  gcc/testsuite/g++.dg/torture/pr119778.C
+ 0d979e637ca747e39d8182a541458797  gcc/testsuite/g++.dg/torture/pr120987-1.C
+ 75b55c517ba9c0f47c83851f084cb294  gcc/testsuite/g++.dg/torture/pr121870.C
+ fd8e483532e07909315ca8711ef4503b  gcc/testsuite/g++.dg/torture/pr123603.C
+ 947406bbc75c3117568a96cd4a4cc34b  gcc/testsuite/g++.dg/torture/pr124130.C
+ 61fcf1bc001bfcf25117da95aaa8edd8  gcc/testsuite/g++.dg/torture/pr124135-1.C
+ 101facde39ac59f9b142786ef251d0ca  gcc/testsuite/g++.dg/torture/pr124135-2.C
  161154ed9f6193a2a7da119e068c3f3f  gcc/testsuite/g++.dg/torture/pr27218.C
  a84e9fff95df4801f8e582fbc33303b8  gcc/testsuite/g++.dg/torture/pr30252.C
  e980bf95890544d46879b89f7aa98df6  gcc/testsuite/g++.dg/torture/pr30567.C
*************** ad6c0b4132032f21f64bfdd4836d3313  gcc/te
*** 28364,28369 ****
--- 28423,28429 ----
  59f2687e6719ef7d3d19b4de0e99a075  gcc/testsuite/g++.dg/ubsan/pr105729.C
  06fb5e3c91f4d1b4f58ee978dd2b4b30  gcc/testsuite/g++.dg/ubsan/pr116449.C
  a9c7210a5fb28a26cd54ad5ce0872a53  gcc/testsuite/g++.dg/ubsan/pr117259.C
+ a4c08c025f777efea858788766890b26  gcc/testsuite/g++.dg/ubsan/pr120471.C
  a654df71119821a4303cc9fe0501191b  gcc/testsuite/g++.dg/ubsan/pr59250.C
  420a6623146bb014dc1310134356d81f  gcc/testsuite/g++.dg/ubsan/pr59306.C
  79755a51c3cbb97ff48bd411272f6b08  gcc/testsuite/g++.dg/ubsan/pr59331.C
*************** ece1d03dfdd44a22781b77ed9ec271d4  gcc/te
*** 28724,28729 ****
--- 28784,28790 ----
  c32e2d9c26f73ceab75448129f154a62  gcc/testsuite/g++.dg/warn/Wduplicated-branches5.C
  c1c94fbed68712c556c47675075fab08  gcc/testsuite/g++.dg/warn/Wduplicated-branches6.C
  df34a3119747a72018c056305c89abd6  gcc/testsuite/g++.dg/warn/Wduplicated-branches7.C
+ b78135999b9fbdc92326bfae8b355202  gcc/testsuite/g++.dg/warn/Wduplicated-branches9.C
  53e8ba692e810326b135e28115da516a  gcc/testsuite/g++.dg/warn/Wduplicated-cond1.C
  aee46bcb7031162dcee9c8ebe1228c6f  gcc/testsuite/g++.dg/warn/Wduplicated-cond2.C
  3fd71ef4467ff2d96bedfb8624c9f6c9  gcc/testsuite/g++.dg/warn/Wduplicated-cond3.C
*************** f1360330e2c03adfb9e1efd9136d3f31  gcc/te
*** 28800,28805 ****
--- 28861,28867 ----
  1184b1df4ae243b5ab6917e0e3b219b6  gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-2.C
  beb0dbeb6a47cd7fb34d04b431670905  gcc/testsuite/g++.dg/warn/Wmismatched-dealloc-3.C
  d183cd43f2c2caf1b71024ba3762ff44  gcc/testsuite/g++.dg/warn/Wmismatched-dealloc.C
+ c64dfbca6c8c86f3fd65230eca021a72  gcc/testsuite/g++.dg/warn/Wmismatched-new-delete-10.C
  74decc16b8ca63b12db874b7dde868cf  gcc/testsuite/g++.dg/warn/Wmismatched-new-delete-2.C
  5c4cad449e21fe0fade92c9c0d19fb5f  gcc/testsuite/g++.dg/warn/Wmismatched-new-delete-3.C
  da3dbc8526151b41f4a741a5d5e51eae  gcc/testsuite/g++.dg/warn/Wmismatched-new-delete-4.C
*************** cbeb61a079567f59bdce9faa40877398  gcc/te
*** 29462,29467 ****
--- 29524,29530 ----
  70adf2e2f20bd052cfca2787bd225b0c  gcc/testsuite/g++.dg/warn/template-2.C
  6f5999bf56f2861a257750422cda17b6  gcc/testsuite/g++.dg/warn/translate-ice-1.C
  81ccb812ec92857cf80d860b4ffa0d31  gcc/testsuite/g++.dg/warn/undefined1.C
+ ea3b303b6284894a2a7543bc63c639eb  gcc/testsuite/g++.dg/warn/undefined2.C
  338b16478b2b401f31f40a2d7b08dfb1  gcc/testsuite/g++.dg/warn/uninit-1.C
  c439e6ca6ae1ca3377fa6507bf891b6c  gcc/testsuite/g++.dg/warn/uninit-pr105562.C
  69c608be9c8c02e5a60a4342603a5fac  gcc/testsuite/g++.dg/warn/uninit-pr48483.C
*************** ab6c5e333d0a740ae5ecff69966813a2  gcc/te
*** 32906,32911 ****
--- 32969,32975 ----
  0dc60096927b240a4fb696311ad6b402  gcc/testsuite/g++.target/aarch64/sve/pr107920.C
  a36c6629cdaa92f5a41aa0c862cf5a54  gcc/testsuite/g++.target/aarch64/sve/pr119610-sve.C
  a99137b765de9aa71ce57dc37592e682  gcc/testsuite/g++.target/aarch64/sve/pr119706.C
+ 81119ead1d39599a647b5c79f9d21a85  gcc/testsuite/g++.target/aarch64/sve/pr121449.C
  29fcc7f7695fcab2e4779698100f3053  gcc/testsuite/g++.target/aarch64/sve/pr96974.C
  6c0e94c363caf9e62df35ea98b4918ed  gcc/testsuite/g++.target/aarch64/sve/pr98177-1.C
  e64000c150bb204c31dca884ee33dd4f  gcc/testsuite/g++.target/aarch64/sve/pr98177-2.C
*************** a47169fc44b57b7b3d6ec05df74c336a  gcc/te
*** 33082,33087 ****
--- 33146,33158 ----
  51556317586878910157bab09d18703d  gcc/testsuite/g++.target/i386/pr111822.C
  f0bd5d5c6a67d4e72ffa0abde025c525  gcc/testsuite/g++.target/i386/pr112443.C
  309d3ebda65ef0d79e21d0a9c0310055  gcc/testsuite/g++.target/i386/pr119689.C
+ 8881751e1efd14bcab3460abca01e627  gcc/testsuite/g++.target/i386/pr122446-1.C
+ e7e909b0858a352117bc6ee5a8fcafc7  gcc/testsuite/g++.target/i386/pr122446-amxbf16.C
+ b48e2095b969e9e4d541b80007eaed1f  gcc/testsuite/g++.target/i386/pr122446-amxcomplex.C
+ ea015573ee8ddabae38c2a615f8228fb  gcc/testsuite/g++.target/i386/pr122446-amxfp16.C
+ 59ffb1a0656cc43a87c4b7e240fb28c6  gcc/testsuite/g++.target/i386/pr122446-amxint8.C
+ ffbb5e0bd5668625c6d5cef769228118  gcc/testsuite/g++.target/i386/pr122446-amxtile.C
+ fe98d8bd643079ebf7d12496d3189d03  gcc/testsuite/g++.target/i386/pr123779.C
  55fb67abf6517f92b1a0240d2c06b5c5  gcc/testsuite/g++.target/i386/pr35513-1.C
  14dde546e4eefec7aa6d1ac41261cb16  gcc/testsuite/g++.target/i386/pr35513-2.C
  1c706f97b6d93c0124dc4a203c98f6d2  gcc/testsuite/g++.target/i386/pr57362.C
*************** daf40cbe22c01f26a5655b3c8ce6f5a7  gcc/te
*** 33137,33142 ****
--- 33208,33214 ----
  0326a0afb833c5dbd49b5d623c8dd93b  gcc/testsuite/g++.target/mips/cxx17_empty_base.C
  57a6c9f80be13720acfbbdbeef414716  gcc/testsuite/g++.target/mips/mips.exp
  dcd3af289f36f150df28be99b5efc7ed  gcc/testsuite/g++.target/mips/pr102024.C
+ db65053e8b783b1724e9fc6d06e3794c  gcc/testsuite/g++.target/mips/pr126484.C
  436543179ef45c1a7c596bfa70c8ef1d  gcc/testsuite/g++.target/msp430/data-attributes.C
  a7c5e3a5228d3ef0c41fbf94725ca379  gcc/testsuite/g++.target/msp430/msp430.exp
  5848d6741a53192ff50fe53e91b24df1  gcc/testsuite/g++.target/nios2/hello-pie.C
*************** a2656a59d00f50e3a24dc4e71bfb3973  gcc/te
*** 34302,34307 ****
--- 34374,34380 ----
  6d13d2354182ca3dc50d8f4d6d5ed5ab  gcc/testsuite/gcc.c-torture/compile/pr103813.c
  4a6f867d2a09bace8b7a324f6a4f5237  gcc/testsuite/gcc.c-torture/compile/pr104327.c
  43abe0671a6ea621a4ca89fda41e49b8  gcc/testsuite/gcc.c-torture/compile/pr104499.c
+ acee4f72cc5b1f29df02485de18a69c0  gcc/testsuite/gcc.c-torture/compile/pr105192.c
  b8c09513cab59ca8f22d38e515f50fa8  gcc/testsuite/gcc.c-torture/compile/pr105234.c
  112c17f5638bc2cf5c04c9e917943218  gcc/testsuite/gcc.c-torture/compile/pr105247.c
  9477024f0d6e7d41ab0ee7d8ab3d3e58  gcc/testsuite/gcc.c-torture/compile/pr106030.c
*************** cddb5f327c3c1dc3f843d95d86f7f6a9  gcc/te
*** 34328,34334 ****
--- 34401,34412 ----
  ece87744c4e664bf39922d9937465df1  gcc/testsuite/gcc.c-torture/compile/pr115143-2.c
  14405634ff4726e79f727af592887eec  gcc/testsuite/gcc.c-torture/compile/pr115143-3.c
  a374b3675317752237cc478b2e662a04  gcc/testsuite/gcc.c-torture/compile/pr115277.c
+ 4b342b76caa9e8e213c9b81ca64d1333  gcc/testsuite/gcc.c-torture/compile/pr116600.c
  0385d5805cb6d90dc8a17f2f44d3450e  gcc/testsuite/gcc.c-torture/compile/pr117358.c
+ ab667119ae39828bcd103bb5c5434cdc  gcc/testsuite/gcc.c-torture/compile/pr120250.c
+ 9f275c2b6e96b2a9fdee0b1a4aee96e9  gcc/testsuite/gcc.c-torture/compile/pr123365.c
+ 8c484e5df297a43329f4182432f35fda  gcc/testsuite/gcc.c-torture/compile/pr123386.c
+ ffc2d0352a16ed7c76c12152bde69753  gcc/testsuite/gcc.c-torture/compile/pr123703.c
  33c7141fcf5b1add3ddd2be0100f1f0d  gcc/testsuite/gcc.c-torture/compile/pr12517.c
  ec16b12ab11c499bf321be18ea59da33  gcc/testsuite/gcc.c-torture/compile/pr12578.c
  86f3d5cf87d24e97aa663b79f2d0ac5d  gcc/testsuite/gcc.c-torture/compile/pr12899.c
*************** e854bc80f793329b6c96d31e3f80a012  gcc/te
*** 36382,36387 ****
--- 36460,36466 ----
  12785ab6e086a50cd8ab9f5bdb9a9bc5  gcc/testsuite/gcc.c-torture/execute/pending-4.c
  5ad23d6cafc55e78896b90e3669a14b8  gcc/testsuite/gcc.c-torture/execute/postmod-1.c
  64b80dcfbe526f0e5993e4b739431227  gcc/testsuite/gcc.c-torture/execute/pr100453.c
+ 7eb7ffbe788ba5ef0ae0a135815b758b  gcc/testsuite/gcc.c-torture/execute/pr101188.c
  859a8616bb39c775a0c9e44482a3e048  gcc/testsuite/gcc.c-torture/execute/pr101335.c
  a2175770e21b82966738b5577f0fae06  gcc/testsuite/gcc.c-torture/execute/pr102134.c
  6f562291c92a478431678da451525a90  gcc/testsuite/gcc.c-torture/execute/pr103052.c
*************** abc98cdd2ec724c17d58a00efc56816b  gcc/te
*** 36436,36441 ****
--- 36515,36523 ----
  5802f1a3b7f07033d3e5c9e6bc333779  gcc/testsuite/gcc.c-torture/execute/pr118915.c
  fd7185346c3b94c0a7f7afba7b6bc241  gcc/testsuite/gcc.c-torture/execute/pr119071.c
  b7150a91a8e64c0a2f8d47a9f857fd6e  gcc/testsuite/gcc.c-torture/execute/pr119291.c
+ d41fd1ea09327fdf9b68f657aea5661c  gcc/testsuite/gcc.c-torture/execute/pr122000.c
+ cb4c82184137c0933c1bae60a7df15bc  gcc/testsuite/gcc.c-torture/execute/pr123864.c
+ 256e8d04f36f265861609fbe23468388  gcc/testsuite/gcc.c-torture/execute/pr124358.c
  7758cb727d75f4fc1c0e483d503de146  gcc/testsuite/gcc.c-torture/execute/pr15262-1.c
  58dc249612dbc918d7fc4010e94deb8d  gcc/testsuite/gcc.c-torture/execute/pr15262-2.c
  d9c36fc850771445c5e4b6ce6dae1a12  gcc/testsuite/gcc.c-torture/execute/pr15262.c
*************** d05bdce55447fc39d09a1133e04e88b4  gcc/te
*** 40324,40329 ****
--- 40406,40412 ----
  45e735b0d33fac192a119347115d5b0c  gcc/testsuite/gcc.dg/completion-4.c
  649ce6d53eeda31c7cb4947fab7ac38f  gcc/testsuite/gcc.dg/completion-5.c
  a86556f4f0c72c0bee2f104440830505  gcc/testsuite/gcc.dg/complex-1.c
+ 79e8cd8a2d1264875feb64c5169b21d2  gcc/testsuite/gcc.dg/complex-10.c
  ec2d607c705e532267dc3c09849c554f  gcc/testsuite/gcc.dg/complex-2.c
  da2226add6799fd192e2b367404d1b0b  gcc/testsuite/gcc.dg/complex-2.h
  7cbd734da9d8330b57f4e78af353b9f2  gcc/testsuite/gcc.dg/complex-3.c
*************** ee94511375797117140ca777fd1695b1  gcc/te
*** 41012,41018 ****
  704c9a2dca0a451cca6e5855f7f2347f  gcc/testsuite/gcc.dg/darwin-minversion-7.c
  5a8b775f8ce1e0cafb8782fbc39b58e4  gcc/testsuite/gcc.dg/darwin-minversion-8.c
  aa9dfa39c42ef65a88c0a708412fb842  gcc/testsuite/gcc.dg/darwin-minversion-9.c
! 956d9c5ca31de05aa49da3cb99f3d4ef  gcc/testsuite/gcc.dg/darwin-minversion-link.c
  b66bb093837bda7692b73c8aa9711e00  gcc/testsuite/gcc.dg/darwin-sections.c
  f7857b3d082c7452ee5a60411d5f02bc  gcc/testsuite/gcc.dg/darwin-segaddr.c
  e3d2d2840d7d23dee7e2cd94e097a114  gcc/testsuite/gcc.dg/darwin-version-1.c
--- 41095,41101 ----
  704c9a2dca0a451cca6e5855f7f2347f  gcc/testsuite/gcc.dg/darwin-minversion-7.c
  5a8b775f8ce1e0cafb8782fbc39b58e4  gcc/testsuite/gcc.dg/darwin-minversion-8.c
  aa9dfa39c42ef65a88c0a708412fb842  gcc/testsuite/gcc.dg/darwin-minversion-9.c
! c4adb9fbe996928419d7acb79ac559cd  gcc/testsuite/gcc.dg/darwin-minversion-link.c
  b66bb093837bda7692b73c8aa9711e00  gcc/testsuite/gcc.dg/darwin-sections.c
  f7857b3d082c7452ee5a60411d5f02bc  gcc/testsuite/gcc.dg/darwin-segaddr.c
  e3d2d2840d7d23dee7e2cd94e097a114  gcc/testsuite/gcc.dg/darwin-version-1.c
*************** d9a1f43ca6ac2a073e22bbbf243f300b  gcc/te
*** 42273,42278 ****
--- 42356,42363 ----
  cd38ec3195ea21395e6d6950ff620410  gcc/testsuite/gcc.dg/gomp/pr104532.c
  0c8d7b49664fa54dbd4054b13e8a3133  gcc/testsuite/gcc.dg/gomp/pr104757.c
  a633f425b4fdde0a7b6f0aa6aa2f2754  gcc/testsuite/gcc.dg/gomp/pr108435.c
+ ec1d4016ba60492b723014b99d2804e6  gcc/testsuite/gcc.dg/gomp/pr121453.c
+ c80489ac8415077c5335cf251371d6e9  gcc/testsuite/gcc.dg/gomp/pr123876.c
  7a163e65fe52b23fc85f2daa18c442ee  gcc/testsuite/gcc.dg/gomp/pr25874.c
  597de3ed24e1bc1c650af918589d83c3  gcc/testsuite/gcc.dg/gomp/pr25989.c
  0bd3e8dc860de61dd8e09229c090e1f5  gcc/testsuite/gcc.dg/gomp/pr25990.c
*************** a7add68c69c48bffecd543855bc97366  gcc/te
*** 43532,43537 ****
--- 43617,43624 ----
  313b5ef23d14915b2a6f61b519f95205  gcc/testsuite/gcc.dg/lto/attr-weakref-1_0.c
  8c3a2c4fa0f190c6d2749b5524ab98c4  gcc/testsuite/gcc.dg/lto/attr-weakref-1_1.c
  5a674e54883d5de8ea06860e38b0cd2e  gcc/testsuite/gcc.dg/lto/attr-weakref-1_2.c
+ 18e88a9f17f78b46c1ce166e48f8d785  gcc/testsuite/gcc.dg/lto/attr-weakref-2_0.c
+ 7e33f6cf523487191171fa66361dc197  gcc/testsuite/gcc.dg/lto/attr-weakref-2_1.c
  77a8ef1bedade751008154d0c1ea49c8  gcc/testsuite/gcc.dg/lto/c-compatible-types-1_0.c
  2efe9845bc7f2a94bdb6da1ddfe698fc  gcc/testsuite/gcc.dg/lto/c-compatible-types-1_1.c
  fd5005c6fbb07e4f27713809ef1f5759  gcc/testsuite/gcc.dg/lto/chkp-privatize-1_1.c
*************** ce4c9d39348d671d75f2c9b6009262fb  gcc/te
*** 44307,44312 ****
--- 44394,44401 ----
  d98596956367fc29b9341da6c0f03f55  gcc/testsuite/gcc.dg/pr101254.c
  2eebdeb5aef44432de1498de14cbf4e6  gcc/testsuite/gcc.dg/pr101266.c
  cbe7e390158f186ae3fd0f808bea7563  gcc/testsuite/gcc.dg/pr101294.c
+ 280ab2738fa9f4a59440b24de22faee0  gcc/testsuite/gcc.dg/pr101312-1.c
+ 1e4a8d2edc5aa23b12908e90b5487800  gcc/testsuite/gcc.dg/pr101312-2.c
  70303171ed7f5b2cba05e6b98daad2ab  gcc/testsuite/gcc.dg/pr101384.c
  566100ed369cb8ddbb77ca59ac7f4416  gcc/testsuite/gcc.dg/pr101403.c
  cf17d565e22770879e54b6d0b5f98c72  gcc/testsuite/gcc.dg/pr101419.c
*************** b4bb8ae97fc12f1c66b22b9149ca7a2b  gcc/te
*** 44562,44567 ****
--- 44651,44657 ----
  26cb03e00d88f4257622852ed3e5369b  gcc/testsuite/gcc.dg/pr109327.c
  45f9003776530da05643fd2fcd9640b8  gcc/testsuite/gcc.dg/pr109392.c
  c84c4385dc7b913c1ab044bf620d7696  gcc/testsuite/gcc.dg/pr109409.c
+ e3305bd5445d5fff018b1f9ab0c905d3  gcc/testsuite/gcc.dg/pr109410-2.c
  8c5ddd68de1ed874eb52f91b7136909e  gcc/testsuite/gcc.dg/pr109410.c
  3399ef12e5625e30f72a928ee7afca74  gcc/testsuite/gcc.dg/pr109412.c
  86a351ab8a6255c1c7e39f673dcac916  gcc/testsuite/gcc.dg/pr109417.c
*************** a3d075dd1b96232581aa40c9e02294e1  gcc/te
*** 44621,44628 ****
--- 44711,44725 ----
  23b8c99f9e2dfda91a95f1195ab38bfd  gcc/testsuite/gcc.dg/pr119183.c
  5b4015cb994569a43c505c35b96cda44  gcc/testsuite/gcc.dg/pr119204.c
  9444444b4f048eadd4b6a2d7592f5fca  gcc/testsuite/gcc.dg/pr120480.c
+ 3675df2622072bf0e5cccbf94e93a50f  gcc/testsuite/gcc.dg/pr122126_vextr.c
+ b975ebfa27ac446e553bacbb75421590  gcc/testsuite/gcc.dg/pr122126_vset.c
+ 3e218010f127737b8ec6efbf8cb00273  gcc/testsuite/gcc.dg/pr123431.c
+ a7df0df7e527949ee5dc73c443a056f4  gcc/testsuite/gcc.dg/pr123882.c
+ f402be89e4891c76c691c8144fe168f7  gcc/testsuite/gcc.dg/pr124138.c
+ c24af1592de8918050b279c29b0300ce  gcc/testsuite/gcc.dg/pr125173-1.c
  bc5ddfbbc46f4e0cce1629d1b58d3090  gcc/testsuite/gcc.dg/pr12603.c
  72a2fca76cb69617ae36bab93c7ec0d7  gcc/testsuite/gcc.dg/pr12625-1.c
+ fdb2036892a5d4d268eb67a8a000644c  gcc/testsuite/gcc.dg/pr126464.c
  6f0ef61e5a12db5f11da839b2988c5e1  gcc/testsuite/gcc.dg/pr13519-1.c
  86dc5cfaafafc79e11d0559d71baea6b  gcc/testsuite/gcc.dg/pr13804-1.c
  2a52cc05fb1415e0eafbc468a7ccc138  gcc/testsuite/gcc.dg/pr14092-1.c
*************** b36a66c501ef03ad7cedb1c40484affd  gcc/te
*** 47227,47232 ****
--- 47324,47330 ----
  359473db5cdd37f1bf6095e84675f821  gcc/testsuite/gcc.dg/strlenopt-93.c
  088575aea180cd1ef854fcc43bef2769  gcc/testsuite/gcc.dg/strlenopt-94.c
  92d0e4eba5d71d4f20fc6e1a8575d10f  gcc/testsuite/gcc.dg/strlenopt-95.c
+ 7acdb4df3aa6d4d3b2a024a99bbaa231  gcc/testsuite/gcc.dg/strlenopt-97.c
  b5f70e58553a0938c1120805bb7995ab  gcc/testsuite/gcc.dg/strlenopt.h
  984ef97553c0d059b2563ed51439cb62  gcc/testsuite/gcc.dg/strncmp-1.c
  f58f592113e43197dadf58bbb685b20d  gcc/testsuite/gcc.dg/strncmp-2.c
*************** b04080329963def55af4aa7a95268fbe  gcc/te
*** 47501,47507 ****
  fa7bdb79eb170773050b26a5ed2ae1ec  gcc/testsuite/gcc.dg/torture/builtin-math-3.c
  86c9312908e71a32a216fd720343d58f  gcc/testsuite/gcc.dg/torture/builtin-math-4.c
  091ba46b9b5948f7b1173f21c6c558b6  gcc/testsuite/gcc.dg/torture/builtin-math-5.c
! 35aafd27620207da2f66dd0e44ff780f  gcc/testsuite/gcc.dg/torture/builtin-math-6.c
  6f699b99531328babffd4ec110ba2fd7  gcc/testsuite/gcc.dg/torture/builtin-math-7.c
  c77f4d57bad6850b166ed11f47ce8a4e  gcc/testsuite/gcc.dg/torture/builtin-math-8.c
  d7925eb09751128af786d99274bd0ab7  gcc/testsuite/gcc.dg/torture/builtin-minmax-1.c
--- 47599,47605 ----
  fa7bdb79eb170773050b26a5ed2ae1ec  gcc/testsuite/gcc.dg/torture/builtin-math-3.c
  86c9312908e71a32a216fd720343d58f  gcc/testsuite/gcc.dg/torture/builtin-math-4.c
  091ba46b9b5948f7b1173f21c6c558b6  gcc/testsuite/gcc.dg/torture/builtin-math-5.c
! 2a86d2b8d17f5c82a3b1eac7e071ce50  gcc/testsuite/gcc.dg/torture/builtin-math-6.c
  6f699b99531328babffd4ec110ba2fd7  gcc/testsuite/gcc.dg/torture/builtin-math-7.c
  c77f4d57bad6850b166ed11f47ce8a4e  gcc/testsuite/gcc.dg/torture/builtin-math-8.c
  d7925eb09751128af786d99274bd0ab7  gcc/testsuite/gcc.dg/torture/builtin-minmax-1.c
*************** b465b03e50a5f0e6eb3f4fc778cae87c  gcc/te
*** 47515,47520 ****
--- 47613,47619 ----
  c1b87db2a9e9bd9b79aeb89e694fd159  gcc/testsuite/gcc.dg/torture/builtin-round-roundevenf128.c
  9e1b5d427790f2b01d5620a8b551a56a  gcc/testsuite/gcc.dg/torture/builtin-rounding-1.c
  e09f1e946db0ab1dc4d3acd77ea2b116  gcc/testsuite/gcc.dg/torture/builtin-self.c
+ c2dc4a738c80577d7e4b917e325e63aa  gcc/testsuite/gcc.dg/torture/builtin-shufflevector-pr123156.c
  fe01d458fb1e7b307aca4d27de62eff0  gcc/testsuite/gcc.dg/torture/builtin-sin-mpfr-1.c
  8d42dae4813a5c391a3481a72ac9c577  gcc/testsuite/gcc.dg/torture/builtin-sprintf.c
  23e1ea0bdd97005c1b4f8564d23f2b6a  gcc/testsuite/gcc.dg/torture/builtin-sqrt-cmp-1.c
*************** eeac37698d62ac42c407cf7ffdab1b4a  gcc/te
*** 47819,47824 ****
--- 47918,47924 ----
  ef2b84dc0bce27c12bd12e27c33dd806  gcc/testsuite/gcc.dg/torture/pr109564-2.c
  72f322a0e5d8096eb7fa42e2d8fabe7d  gcc/testsuite/gcc.dg/torture/pr109585.c
  f5aad1409cbbb9e3039cb7da55080bc6  gcc/testsuite/gcc.dg/torture/pr109609.c
+ cfb24796cf777565d6ee8e3cc9faa0c1  gcc/testsuite/gcc.dg/torture/pr110043.c
  c68e0fca588779377278aa9e84380d07  gcc/testsuite/gcc.dg/torture/pr110176.c
  0c0edd5cb473e3baec880eabda166963  gcc/testsuite/gcc.dg/torture/pr110228.c
  2c65ac9bb8c6b6218eb71392ab387879  gcc/testsuite/gcc.dg/torture/pr110298.c
*************** aaecc5ca23f58b7071a57eaa96693127  gcc/te
*** 47828,47834 ****
--- 47928,47936 ----
  39a13c5ef6e1f4f1fb97ea3cdca7f2f7  gcc/testsuite/gcc.dg/torture/pr110702.c
  adcee8c1e5b1ea90af01ed3ee2f5548f  gcc/testsuite/gcc.dg/torture/pr110766.c
  fd4292c0fcabd728ea0a1a6dbef87843  gcc/testsuite/gcc.dg/torture/pr110799.c
+ 7423e38f878a6e56fb7be82847619a5b  gcc/testsuite/gcc.dg/torture/pr111036.c
  a5aabe56aa9f2db146fb1185eabbfacb  gcc/testsuite/gcc.dg/torture/pr111137.c
+ c03a94bf3221f3e1fe6701290ec4b037  gcc/testsuite/gcc.dg/torture/pr111387.c
  880ef8f569f8ceaf9a94d105c12a8f97  gcc/testsuite/gcc.dg/torture/pr111445.c
  6b2965d4ac5485c88aa22c20791498bd  gcc/testsuite/gcc.dg/torture/pr111519.c
  9ac3aab221fd38c4d0dda7ec4429c95d  gcc/testsuite/gcc.dg/torture/pr111614.c
*************** b9fe62163204f0f9de8d47547473ce6c  gcc/te
*** 47853,47858 ****
--- 47955,47962 ----
  b9f75d112b5891dd319ae19e3779967f  gcc/testsuite/gcc.dg/torture/pr116057.c
  99a6c1e6285db8d08064cd8aaa300ddd  gcc/testsuite/gcc.dg/torture/pr116380.c
  78733925c03c093a5b9fb429087338ac  gcc/testsuite/gcc.dg/torture/pr116412-1.c
+ 798adbb1647443200e77c0fd667ada2f  gcc/testsuite/gcc.dg/torture/pr116454-1.c
+ 8059636329da8ba84cf6fc4ecf02e524  gcc/testsuite/gcc.dg/torture/pr116454-2.c
  26feb828f8efabc996ee22e90cd17fc1  gcc/testsuite/gcc.dg/torture/pr116585.c
  59484ae831cab97471a148691d17d840  gcc/testsuite/gcc.dg/torture/pr116768.c
  7ff97033e93d5c0fd815ba8a91fcd00e  gcc/testsuite/gcc.dg/torture/pr116922.c
*************** eed87995921a41d6f215168315f20d67  gcc/te
*** 47864,47873 ****
--- 47968,47997 ----
  0f6fc6ed111e2e5782be3518bfe6e1eb  gcc/testsuite/gcc.dg/torture/pr117333.c
  6ae50575ec63bfcc997168ba66e3cd75  gcc/testsuite/gcc.dg/torture/pr117417.c
  211f874eb690213e110852d5efe7da32  gcc/testsuite/gcc.dg/torture/pr117574-1.c
+ fbc66d37323062d4dfeea9f5f179a29e  gcc/testsuite/gcc.dg/torture/pr117811.c
  66b62cd3c17e663e000967aafbe81bc7  gcc/testsuite/gcc.dg/torture/pr117979.c
  673535a31d0d70358a6475962b4d71c2  gcc/testsuite/gcc.dg/torture/pr118476-1.c
  d29f5dbd5ce72ebe101793547b043347  gcc/testsuite/gcc.dg/torture/pr118717.c
  4f00237a70e232a883a71b2c8d7c8f95  gcc/testsuite/gcc.dg/torture/pr118922-1.c
+ 6286b6d7f9b6777b4b6d41fea79f96cb  gcc/testsuite/gcc.dg/torture/pr119532.c
+ e1b9ad351c56aebfaff790ff4002bf6e  gcc/testsuite/gcc.dg/torture/pr120182.c
+ e9469d38b4234580f9b2284233404b3c  gcc/testsuite/gcc.dg/torture/pr120341-1.c
+ aef01c040da8abd2a1e547ed6a07eb5a  gcc/testsuite/gcc.dg/torture/pr120341-2.c
+ e23df6b1422011499b9a500d2bf25add  gcc/testsuite/gcc.dg/torture/pr120944.c
+ d41266e6594db1994e416e7a7353751e  gcc/testsuite/gcc.dg/torture/pr121370.c
+ 949a4a95ad545289488a204b883b05d6  gcc/testsuite/gcc.dg/torture/pr121844.c
+ 0cd9b5f403d655ca4804a15fc23543fd  gcc/testsuite/gcc.dg/torture/pr123416.c
+ ea90221ab80b5c3561ffc7665d2a343a  gcc/testsuite/gcc.dg/torture/pr123645-1.c
+ c6c07c813f67e0f94f1352f2810dfcff  gcc/testsuite/gcc.dg/torture/pr123645-2.c
+ 50838f4736657229a26dc1b011faf8d3  gcc/testsuite/gcc.dg/torture/pr123864.c
+ d4f9bc1a728b13f9940b71ab03cc40fd  gcc/testsuite/gcc.dg/torture/pr124132.c
+ 16b777622562135656ac0ab96375cfb5  gcc/testsuite/gcc.dg/torture/pr124868.c
+ fbe779467ae6f7cb7ee578922f1e8686  gcc/testsuite/gcc.dg/torture/pr125025.c
+ 34d76b7c3d511915334d6295155dc103  gcc/testsuite/gcc.dg/torture/pr125774-1.c
+ 41ed1d0a724d4e7e08239b14b14a1043  gcc/testsuite/gcc.dg/torture/pr126464.c
+ e6132b99fe49e5ef626b8a5c49e9670a  gcc/testsuite/gcc.dg/torture/pr126547.c
+ dd52fd0f3c0ee9acc92c2956c8695df5  gcc/testsuite/gcc.dg/torture/pr126564.c
+ f80e9f48f86c757f3f37f34e4c8e4f8c  gcc/testsuite/gcc.dg/torture/pr126576.c
  ded4330fd1cd52783bd9b1761db038ef  gcc/testsuite/gcc.dg/torture/pr16104-1.c
  fc265ee05da2f29f0e92804661cd1f28  gcc/testsuite/gcc.dg/torture/pr17526.c
  01c583edb41b632b835aa892b9c1cb14  gcc/testsuite/gcc.dg/torture/pr17933-1.c
*************** d2e1860fa8199fa9cae01ffe45caa0c0  gcc/te
*** 48976,48982 ****
  d870c565ecc3624fb4fbcb1510c36484  gcc/testsuite/gcc.dg/torture/tree-loop-1.c
  6970cdcc7bdfd578411b169b161f82cf  gcc/testsuite/gcc.dg/torture/type-generic-1.c
  bd588e9316f28797985023db337c730b  gcc/testsuite/gcc.dg/torture/va-arg-25.c
! 5c82e599e9517c158609d3871bb6ab3f  gcc/testsuite/gcc.dg/torture/vec-cvt-1.c
  70a7b1e7d786a67e8b07f4d2d0baba21  gcc/testsuite/gcc.dg/torture/vect-bool-1.c
  deba47b8439d01c869eba7f288c1e8d7  gcc/testsuite/gcc.dg/torture/vector-1.c
  976d72752026efa82ba29f7e5ec18661  gcc/testsuite/gcc.dg/torture/vector-2.c
--- 49100,49106 ----
  d870c565ecc3624fb4fbcb1510c36484  gcc/testsuite/gcc.dg/torture/tree-loop-1.c
  6970cdcc7bdfd578411b169b161f82cf  gcc/testsuite/gcc.dg/torture/type-generic-1.c
  bd588e9316f28797985023db337c730b  gcc/testsuite/gcc.dg/torture/va-arg-25.c
! a2fa4a55ce8fbbb549f006c693524abb  gcc/testsuite/gcc.dg/torture/vec-cvt-1.c
  70a7b1e7d786a67e8b07f4d2d0baba21  gcc/testsuite/gcc.dg/torture/vect-bool-1.c
  deba47b8439d01c869eba7f288c1e8d7  gcc/testsuite/gcc.dg/torture/vector-1.c
  976d72752026efa82ba29f7e5ec18661  gcc/testsuite/gcc.dg/torture/vector-2.c
*************** c4778a5d167ea622bf99df287c4bd701  gcc/te
*** 49539,49546 ****
  c177f823491b23ed671dd72cae6bdd38  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11c.c
  f339f3a1e5bd9548ccfe5b18c2c7c7e5  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
  407f5e3525abdace7d6ff525b35e9b3b  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
! a9035f101274c289aedd6685e9ed30ec  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c
! d637cf73f6c38b75ddfb9687a20f1ec6  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c
  e04b32c6114139e6a8e522e17e1b449b  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-32.c
  c700544c3e68a401546cefbdad359728  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-33.c
  955e41ee303f67ec226ec41283fd05af  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c
--- 49663,49670 ----
  c177f823491b23ed671dd72cae6bdd38  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-11c.c
  f339f3a1e5bd9548ccfe5b18c2c7c7e5  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-2.c
  407f5e3525abdace7d6ff525b35e9b3b  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-25.c
! 9fcbd0dab1d2b9030b560564a66de479  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c
! 5d637cf26e6d8c5497804c69b1efa111  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c
  e04b32c6114139e6a8e522e17e1b449b  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-32.c
  c700544c3e68a401546cefbdad359728  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-33.c
  955e41ee303f67ec226ec41283fd05af  gcc/testsuite/gcc.dg/tree-ssa/gen-vect-34.c
*************** c6848ef9d4a9873e77016b18db0eef64  gcc/te
*** 49937,49942 ****
--- 50061,50071 ----
  91ab942db3d3d13291ae97a65be94e36  gcc/testsuite/gcc.dg/tree-ssa/pr113993.c
  8710d339fbc689e052900f47a175994e  gcc/testsuite/gcc.dg/tree-ssa/pr114864.c
  5dd2285e0a64c83e08b6d68b6cd36eba  gcc/testsuite/gcc.dg/tree-ssa/pr117142.c
+ 5f36d3d6eda4211f506ed2e65fc779c4  gcc/testsuite/gcc.dg/tree-ssa/pr117423.c
+ b0891b1dddf226da47f4f976abdd7cb0  gcc/testsuite/gcc.dg/tree-ssa/pr119085.c
+ 71eb14b3ae5faf81c5226dc766d48edd  gcc/testsuite/gcc.dg/tree-ssa/pr122976.c
+ d87a1ad6187c06f07e6ee3b7c6352e9e  gcc/testsuite/gcc.dg/tree-ssa/pr124151.c
+ 48b9927c83dc18a6b5d592a592dad513  gcc/testsuite/gcc.dg/tree-ssa/pr126601.c
  78e6c5fe63f7305009c8a79840fe20dc  gcc/testsuite/gcc.dg/tree-ssa/pr13146.c
  eab19e0c04884cd782c9879cbe292109  gcc/testsuite/gcc.dg/tree-ssa/pr14341.c
  9945ed7002a5f7d4918e8ff5eb4cb647  gcc/testsuite/gcc.dg/tree-ssa/pr14490-1.c
*************** cefdc2a9eb13f2095c81dff3665fcbe2  gcc/te
*** 51315,51320 ****
--- 51444,51450 ----
  5ecc4a818796a17622dbe25b368725ec  gcc/testsuite/gcc.dg/ubsan/pr112709-1.c
  f7352e346071f20c88b4cda3aefaf007  gcc/testsuite/gcc.dg/ubsan/pr112709-2.c
  9d35f4aafed7065254d5bcbd8e4b3469  gcc/testsuite/gcc.dg/ubsan/pr113012.c
+ cae65f7755e556ca92edd7478099c942  gcc/testsuite/gcc.dg/ubsan/pr120837.c
  8b53119c2975ba4eb7e0a8a3f21049bc  gcc/testsuite/gcc.dg/ubsan/pr63690.c
  7a3b89a11b570c0d6817707c745a9fba  gcc/testsuite/gcc.dg/ubsan/pr67279.c
  c9a455b03d901e306e1836d50e9e37d6  gcc/testsuite/gcc.dg/ubsan/pr67662.c
*************** d26c1450e737c9198e3e413deb96e2b3  gcc/te
*** 52069,52074 ****
--- 52199,52206 ----
  b8e70a728432436afa060e498411cc94  gcc/testsuite/gcc.dg/vect/pr119145.c
  8312a9b4f3649f0390632c660109eb1d  gcc/testsuite/gcc.dg/vect/pr119399.c
  f5749a6330ea4377b859350a23760b4a  gcc/testsuite/gcc.dg/vect/pr119534.c
+ 7df91aea22a8a2dc08bd0d355fa30fae  gcc/testsuite/gcc.dg/vect/pr120817.c
+ 3ccd618a730abdb13ec305c26f14ac22  gcc/testsuite/gcc.dg/vect/pr121059.c
  42d48d2ecd5682545b12ac42f879a831  gcc/testsuite/gcc.dg/vect/pr16105.c
  231c99dba9475fe09525bbf6f4374124  gcc/testsuite/gcc.dg/vect/pr18308.c
  3aed50f38aa86c4915d6e4b3cef91287  gcc/testsuite/gcc.dg/vect/pr18400.c
*************** aa46a01c430ca6bcb60fb6bc2edfbb1d  gcc/te
*** 52999,53009 ****
  b10686cc9cc745d9a4e579ee285eae2d  gcc/testsuite/gcc.dg/vect/vect-fma-2.c
  f26bda59075ce8ddcb0291dc86a118b3  gcc/testsuite/gcc.dg/vect/vect-fma-3.c
  609ec8572941506ac02bdead3631cf1a  gcc/testsuite/gcc.dg/vect/vect-fmax-1.c
! 8dd709fc543f80ce70588b05e38be7ae  gcc/testsuite/gcc.dg/vect/vect-fmax-2.c
! b913a0ce97e1075ed9731f6e62b860bf  gcc/testsuite/gcc.dg/vect/vect-fmax-3.c
  f7641c61bbf333053e42be5bfa67d8e4  gcc/testsuite/gcc.dg/vect/vect-fmin-1.c
! 33e9990b22cd49f97ec590b283e99e41  gcc/testsuite/gcc.dg/vect/vect-fmin-2.c
! 92e4333ba4e6a6e7852441677e9dd7e1  gcc/testsuite/gcc.dg/vect/vect-fmin-3.c
  8fd9883d5396ca3292f66484ef525262  gcc/testsuite/gcc.dg/vect/vect-fncall-mask.c
  f7e0d01143aad0f81b1d1f66c5737e3a  gcc/testsuite/gcc.dg/vect/vect-fold-1.c
  35c3ee4b34fc72c77cfca5c91b2ab36c  gcc/testsuite/gcc.dg/vect/vect-gather-1.c
--- 53131,53141 ----
  b10686cc9cc745d9a4e579ee285eae2d  gcc/testsuite/gcc.dg/vect/vect-fma-2.c
  f26bda59075ce8ddcb0291dc86a118b3  gcc/testsuite/gcc.dg/vect/vect-fma-3.c
  609ec8572941506ac02bdead3631cf1a  gcc/testsuite/gcc.dg/vect/vect-fmax-1.c
! ff69a9e19928b3a1de48ce1b898d4a45  gcc/testsuite/gcc.dg/vect/vect-fmax-2.c
! d6b11f32049737083a9d8a816c7de6db  gcc/testsuite/gcc.dg/vect/vect-fmax-3.c
  f7641c61bbf333053e42be5bfa67d8e4  gcc/testsuite/gcc.dg/vect/vect-fmin-1.c
! 0cde09c690b3ca2b483cb6ce9cc4115e  gcc/testsuite/gcc.dg/vect/vect-fmin-2.c
! c8add09e1cb63057bdcddaad5063ed57  gcc/testsuite/gcc.dg/vect/vect-fmin-3.c
  8fd9883d5396ca3292f66484ef525262  gcc/testsuite/gcc.dg/vect/vect-fncall-mask.c
  f7e0d01143aad0f81b1d1f66c5737e3a  gcc/testsuite/gcc.dg/vect/vect-fold-1.c
  35c3ee4b34fc72c77cfca5c91b2ab36c  gcc/testsuite/gcc.dg/vect/vect-gather-1.c
*************** f77bcd6abf3d7fc181b5c9099b8107e9  gcc/te
*** 53195,53200 ****
--- 53327,53334 ----
  57fce33d05ece46874b1533bb515f641  gcc/testsuite/gcc.dg/vect/vect-recurr-4.c
  4fd234c6d904b08de1c1ef5da8a85989  gcc/testsuite/gcc.dg/vect/vect-recurr-5.c
  341e8cf83af90ee08e2f0e11eabd1b72  gcc/testsuite/gcc.dg/vect/vect-recurr-6.c
+ 7871d15555bf4ec0abcd6a88f3433086  gcc/testsuite/gcc.dg/vect/vect-recurr-pr121256-2.c
+ 39b82075f86d610ada0f9574ce45d00a  gcc/testsuite/gcc.dg/vect/vect-recurr-pr121256.c
  14379418c35bd92a759c557ae5c861c6  gcc/testsuite/gcc.dg/vect/vect-reduc-1.c
  22a0d53785f7d6c47cd23f6847097e73  gcc/testsuite/gcc.dg/vect/vect-reduc-10.c
  5e2267c9823c709c9186c2bae29c4b9e  gcc/testsuite/gcc.dg/vect/vect-reduc-11.c
*************** d335e36067020cadd7d9a133513eafd0  gcc/te
*** 54744,54749 ****
--- 54878,54884 ----
  4c4387d4071cf10c793b4efe11f43439  gcc/testsuite/gcc.target/aarch64/cpunative/info_3
  d7c6ea3e81a5b70c38883962d2efd8ee  gcc/testsuite/gcc.target/aarch64/cpunative/info_34
  d7c6ea3e81a5b70c38883962d2efd8ee  gcc/testsuite/gcc.target/aarch64/cpunative/info_35
+ 18a6f5935390f2dcfad26b80665b4c02  gcc/testsuite/gcc.target/aarch64/cpunative/info_36
  d8a7caffcc99feff5312001aed51cd38  gcc/testsuite/gcc.target/aarch64/cpunative/info_4
  195bf754aeaf6d4fa8426e8fb4a553ce  gcc/testsuite/gcc.target/aarch64/cpunative/info_5
  73a2f048b60d92f4c6f8167c05bbd47c  gcc/testsuite/gcc.target/aarch64/cpunative/info_6
*************** b261e4b3a92afb198bb5a15e54284bae  gcc/te
*** 54769,54774 ****
--- 54904,54910 ----
  5932d955ed9dc11faefb9f331763ff2c  gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_3.c
  8c086c230f3d3301367bcba61e8701bd  gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_34.c
  ed6c20b66e7487d804e92b9c34f85aa5  gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_35.c
+ a1187a95c840252f3c77a8ad50920229  gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_36.c
  cfd988497c936bc048f9b952dc82ebac  gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_4.c
  f40714de7a09b627eb98087b5a7cff0a  gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_5.c
  9852d3f0d62cf759f60853c972dbbedb  gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_6.c
*************** c06d3b2030bc06f25071cbc162980592  gcc/te
*** 55150,55155 ****
--- 55286,55292 ----
  c0b04f74adb90213a554c87f602b9139  gcc/testsuite/gcc.target/aarch64/pr109661-1.c
  7506b184bf1ad4df113825935c38bf26  gcc/testsuite/gcc.target/aarch64/pr112787.c
  5c93b32021bd32ca40c9fb5ec6a30f04  gcc/testsuite/gcc.target/aarch64/pr113552.c
+ 83ac293146b05a62ec4a19e52751ebd1  gcc/testsuite/gcc.target/aarch64/pr121253.c
  9adb42733d9f5e2b1f2dbb364b62100d  gcc/testsuite/gcc.target/aarch64/pr37780_1.c
  e668fb9e0d32efadd671247467dc90db  gcc/testsuite/gcc.target/aarch64/pr58460.c
  9023f817c07ddec673c5b546525fc184  gcc/testsuite/gcc.target/aarch64/pr60034.c
*************** ae44d68f203e7d5a17d19738cfbc53a0  gcc/te
*** 57704,57714 ****
--- 57841,57858 ----
  23037c19fa0b1b3f5bcac32c8d73393c  gcc/testsuite/gcc.target/aarch64/sve/acle/general/nrv_1.c
  618eed08c799209fcc7e876e7bc1f5a9  gcc/testsuite/gcc.target/aarch64/sve/acle/general/orn_1.c
  c43619dc0345cb75df63193d4ecf32a5  gcc/testsuite/gcc.target/aarch64/sve/acle/general/orr_1.c
+ 0a35f14f6f82735e897ca461fd10bd66  gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_2.c
+ acdd75031b126bdb8ede449a87a8b4c8  gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_3.c
+ eb5400f39cf4b8034ce9bf768b42f01e  gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_4.c
+ dc5cc4bd54f699543e29d49d190cf7f3  gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_5.c
+ 4505bd757cf0718372154e481c4a2da0  gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_6.c
+ 453c5ef83bc5137397e38e9f3c9d6da9  gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_7.c
  bb3a7f2587d8584d185738649f93a6f6  gcc/testsuite/gcc.target/aarch64/sve/acle/general/pfirst_1.c
  4a5457bf98a3061b6c949b777ceca410  gcc/testsuite/gcc.target/aarch64/sve/acle/general/pnext_1.c
  6d3b0cbb6b0b88e0030fbf0003faa4c9  gcc/testsuite/gcc.target/aarch64/sve/acle/general/pnext_2.c
  9ff121474de72b7f1e7df15e02d1fcbf  gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr104092.c
  06b9fe18846ba9da10d77ea945b0fa4f  gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr107920.c
+ c1f0d92266055a62f8c3a0b32cffca32  gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr121118_1.c
  cd84e485b3fa7a0d50f2ee5113eca33d  gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr94683.c
  111a35b5bdbe877086a99d29b13dc65b  gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr94700.c
  dd9873ff910539b000561a51ccc3a52f  gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr96146.c
*************** a5788fbbeb941609b02d51151c326705  gcc/te
*** 57723,57728 ****
--- 57867,57873 ----
  bf328a0ed3cadaf01cdcd516cb16a2eb  gcc/testsuite/gcc.target/aarch64/sve/acle/general/ptrue_pat_4.c
  21cf8f26265cb4080b1703c09d296dc5  gcc/testsuite/gcc.target/aarch64/sve/acle/general/ptrue_pat_5.c
  ef386f442776c7325a9c4120d5f0f1cd  gcc/testsuite/gcc.target/aarch64/sve/acle/general/qincb_1.c
+ 52959d72e6279c53e3e28e80ecb896fe  gcc/testsuite/gcc.target/aarch64/sve/acle/general/rev_2.c
  b73d2b4b9aeaceb7898b89f8e147cc04  gcc/testsuite/gcc.target/aarch64/sve/acle/general/stack_vars_1.c
  a60971180940fb9126dc3f2440073c3a  gcc/testsuite/gcc.target/aarch64/sve/acle/general/struct_1.c
  9404c4e4b822b81b48891a1fe0625266  gcc/testsuite/gcc.target/aarch64/sve/acle/general/temporaries_1.c
*************** fca208aba0269c8218d4736a10ac6a83  gcc/te
*** 58449,58454 ****
--- 58594,58600 ----
  bc4cb512648e75cde04a28680b1c4a89  gcc/testsuite/gcc.target/aarch64/sve/pr109505.c
  ea42d07119e6d0bf4a13e781c6d1367d  gcc/testsuite/gcc.target/aarch64/sve/pr110280.c
  32ab14334cab1c6336c74f3dc7e201db  gcc/testsuite/gcc.target/aarch64/sve/pr116238.c
+ e823376093c32dfd1c352c612c6a2602  gcc/testsuite/gcc.target/aarch64/sve/pr122724.c
  7e2aaf0806edd37415079b5c2e48b66c  gcc/testsuite/gcc.target/aarch64/sve/pr81003.c
  00b752a6e175de8b1a300df08f275461  gcc/testsuite/gcc.target/aarch64/sve/pr87563.c
  c56eeba71ad463673a1bdb30e7a94863  gcc/testsuite/gcc.target/aarch64/sve/pr87815.c
*************** fc2eb8ac52faed5fba0a017b858d4ae4  gcc/te
*** 59767,59772 ****
--- 59913,59921 ----
  8a43a90457a76e1e8f6951c362fed0e0  gcc/testsuite/gcc.target/aarch64/torture/aarch64-torture.exp
  4036d83a59b4adcf9e8a4cf5a291d22e  gcc/testsuite/gcc.target/aarch64/torture/pr111677.c
  8ba6cf5317762b2b89350d4f652efa53  gcc/testsuite/gcc.target/aarch64/torture/pr116564.c
+ d03b2f46140f14ae9b2101813aec3525  gcc/testsuite/gcc.target/aarch64/torture/pr121772.c
+ a9e9dc89b86dea48cebffdbd8459e3a1  gcc/testsuite/gcc.target/aarch64/torture/pr125621.c
+ d7b61dffce1d1bb0e0a1418de081d6df  gcc/testsuite/gcc.target/aarch64/torture/pr125818.c
  5266ac107a73e3ee1d1f44e1cda7d9f2  gcc/testsuite/gcc.target/aarch64/torture/simd-abi-1.c
  9c3416db2fc04c3f91b03ecae15e943e  gcc/testsuite/gcc.target/aarch64/torture/simd-abi-10.c
  df55bfe2c1ce46074b19b4566cedeef4  gcc/testsuite/gcc.target/aarch64/torture/simd-abi-11.c
*************** c6c1c759a610556eca59987a77084f45  gcc/te
*** 60327,60333 ****
  53e11cdab71cca17d6fdaf4ed9224a30  gcc/testsuite/gcc.target/arm/armv8_2-fp16-arith-1.c
  5790d3efd74c1ddf5aeb2e8743385c60  gcc/testsuite/gcc.target/arm/armv8_2-fp16-arith-2.c
  e760d8a00f0e4b4ceedce756dc61f6c1  gcc/testsuite/gcc.target/arm/armv8_2-fp16-conv-1.c
! 2f54b8d253156a2be1577d30ce773f07  gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c
  8411d0e77a0611b1b9aef23030254fbe  gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c
  43365e7220d0c89c221983b0088e64ec  gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c
  dc2445fc2ce3b9779058431b1cfb377b  gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-2.c
--- 60476,60482 ----
  53e11cdab71cca17d6fdaf4ed9224a30  gcc/testsuite/gcc.target/arm/armv8_2-fp16-arith-1.c
  5790d3efd74c1ddf5aeb2e8743385c60  gcc/testsuite/gcc.target/arm/armv8_2-fp16-arith-2.c
  e760d8a00f0e4b4ceedce756dc61f6c1  gcc/testsuite/gcc.target/arm/armv8_2-fp16-conv-1.c
! 1e4a9e637ba2067c00eb31092a65dfb4  gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c
  8411d0e77a0611b1b9aef23030254fbe  gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-2.c
  43365e7220d0c89c221983b0088e64ec  gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-1.c
  dc2445fc2ce3b9779058431b1cfb377b  gcc/testsuite/gcc.target/arm/armv8_2-fp16-neon-2.c
*************** e5306c98e7af9542607cef498d9d4cab  gcc/te
*** 60443,60448 ****
--- 60592,60598 ----
  bf06244dec6dc49e0817b03e4494a90f  gcc/testsuite/gcc.target/arm/builtin_uaddll.c
  f842ae48d03fd71d6c4251ee6b88d526  gcc/testsuite/gcc.target/arm/builtin_usubl.c
  33305e972aaa5cd2660665305329c212  gcc/testsuite/gcc.target/arm/builtin_usubll.c
+ 00d46b35880659bc8001ea4047b5bb1c  gcc/testsuite/gcc.target/arm/cbz-range.c
  528a1cc7ada5bc63c0c59152d86b8557  gcc/testsuite/gcc.target/arm/cbz.c
  78f9bef0e50a143219120e7b5b4af7b9  gcc/testsuite/gcc.target/arm/cmp-1.c
  97376f46024c436de8ce633177de6e0b  gcc/testsuite/gcc.target/arm/cmp-2.c
*************** ab72cfcef8400549b3b4d4d318e4955e  gcc/te
*** 60808,60813 ****
--- 60958,60964 ----
  08cf164f5014eeb82272fbef22e3878f  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vstr.c
  4211e73819bb661ddd18271cf8dab0e5  gcc/testsuite/gcc.target/arm/mve/intrinsics/mve_vstr_p.c
  cfb4125c4550d5cf153bac3dcd2886ad  gcc/testsuite/gcc.target/arm/mve/intrinsics/pr101016.c
+ 0584832f92d1fa9172d7b5f0af9daf91  gcc/testsuite/gcc.target/arm/mve/intrinsics/pr122223.c
  a8d3fa3695fbd309660950fb5598ecaf  gcc/testsuite/gcc.target/arm/mve/intrinsics/pr97327.c
  f1860ef4320f7f2a6a4791bdb0c063ba  gcc/testsuite/gcc.target/arm/mve/intrinsics/sqrshr.c
  5d7653e2d5007d0c5a0f2368f9b07c02  gcc/testsuite/gcc.target/arm/mve/intrinsics/sqrshrl_sat48.c
*************** ca03d4215dfd4e98fc1d17e6890fcc4a  gcc/te
*** 63362,63367 ****
--- 63513,63520 ----
  2f719adc3f3e3724629a17daf9bb2e71  gcc/testsuite/gcc.target/arm/pr100775.c
  b78ed4b32814a22ad0cf1f46aee89cc8  gcc/testsuite/gcc.target/arm/pr105312.c
  d59d090be25d48a18820542cf3abe1eb  gcc/testsuite/gcc.target/arm/pr109939.c
+ 82da20b2c4061a368f405dbeb1cdb341  gcc/testsuite/gcc.target/arm/pr123271.c
+ 236563c6007691d6571ab9e909e2c81e  gcc/testsuite/gcc.target/arm/pr124933.c
  03b84ccc5b909e6ece59f619e9298211  gcc/testsuite/gcc.target/arm/pr19599.c
  3425143e88f989a8f52f345e6237106a  gcc/testsuite/gcc.target/arm/pr26702.c
  fc0dd660f56108005b4f0b142e94d10d  gcc/testsuite/gcc.target/arm/pr37780_1.c
*************** c02c9b09a64e3c14adfe954730cf8f3c  gcc/te
*** 64056,64061 ****
--- 64209,64224 ----
  caa7b81fc83f2373b987ae3dec63aa32  gcc/testsuite/gcc.target/avr/torture/pr119989-memx-3.c
  9d65901f178212417bd03274e7a0ff1d  gcc/testsuite/gcc.target/avr/torture/pr119989-memx-4.c
  51d04706ca0c4216d8d453fbe55f52ca  gcc/testsuite/gcc.target/avr/torture/pr119989.h
+ 29f4c964db7ef564a3a000cb063b157c  gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-ssk.c
+ 67193b81ec722633cd4a96c262f212b7  gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-ssr.c
+ 74bee38deb2c7a93221837e40bbfadc7  gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-suk.c
+ cfa6dc119f8aecd5a863526026a0b850  gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-sur.c
+ ebbf958a9ec613b0e83f39734d21b008  gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-usk.c
+ 61f30bb6c17362860da7175576769d9c  gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-usr.c
+ b5f3dac0a4aa3e456482d4b3162d64b6  gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-uuk.c
+ f5a1361523de0e3faf7dfdd815bbaedf  gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-uur.c
+ 33205c0601ab01f0a0bb4fcfdc9bd796  gcc/testsuite/gcc.target/avr/torture/pr125409.h
+ a191de98a42b86fd465aa24b4f900324  gcc/testsuite/gcc.target/avr/torture/pr127098.c
  0844a939ea2464d30cc8892c85b4aecc  gcc/testsuite/gcc.target/avr/torture/pr39633.c
  8fb17af722ee890b7fa08b5610cdb80e  gcc/testsuite/gcc.target/avr/torture/pr41885.c
  70b849f57ecf42299230b99b7734dd2d  gcc/testsuite/gcc.target/avr/torture/pr51374-1.c
*************** d3f15f077bac4fdd98e262ff70319e29  gcc/te
*** 64889,64905 ****
  ab183c688cdb4a97e3f15f79a1c2e13f  gcc/testsuite/gcc.target/i386/amx-check.h
  e41de94d793974394641e42ed7370a65  gcc/testsuite/gcc.target/i386/amx-helper.h
  3e5ed8f51d1403b179db592f12cb019c  gcc/testsuite/gcc.target/i386/amxbf16-asmatt-1.c
! 215b9569abd57352c2d13ba5129e07cd  gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c
  c4406ef230e7a6bb0e7b45b2f94958e9  gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c
  0787eb1011631a123144aa2e9fe5b9f2  gcc/testsuite/gcc.target/i386/amxcomplex-asmatt-1.c
! 971dbba18c823297793b59421738511a  gcc/testsuite/gcc.target/i386/amxcomplex-asmintel-1.c
  88abb806331f7455dfc053e7bfa9993d  gcc/testsuite/gcc.target/i386/amxcomplex-cmmimfp16ps-2.c
  5029635b15d7dd713761d53e4630a666  gcc/testsuite/gcc.target/i386/amxcomplex-cmmrlfp16ps-2.c
  0a13ebe83385a9aedb0a82cf5504a96b  gcc/testsuite/gcc.target/i386/amxfp16-asmatt-1.c
! eefaf66ff1c174b18d152560427620f0  gcc/testsuite/gcc.target/i386/amxfp16-asmintel-1.c
  26723806e86b2502f2d6b3c39febf8ce  gcc/testsuite/gcc.target/i386/amxfp16-dpfp16ps-2.c
  9c0241aa040bd07b656b878c62a423b9  gcc/testsuite/gcc.target/i386/amxint8-asmatt-1.c
! 2622cfbb5e38bb55e4751132b8d85ea3  gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c
  06751f31b3086f1ff040533de854e994  gcc/testsuite/gcc.target/i386/amxint8-dpbssd-2.c
  e3f6b37649c7f1fa4d20b6327cdcdb27  gcc/testsuite/gcc.target/i386/amxint8-dpbsud-2.c
  a8ab966558faa138830cc3e75dbe4464  gcc/testsuite/gcc.target/i386/amxint8-dpbusd-2.c
--- 65052,65068 ----
  ab183c688cdb4a97e3f15f79a1c2e13f  gcc/testsuite/gcc.target/i386/amx-check.h
  e41de94d793974394641e42ed7370a65  gcc/testsuite/gcc.target/i386/amx-helper.h
  3e5ed8f51d1403b179db592f12cb019c  gcc/testsuite/gcc.target/i386/amxbf16-asmatt-1.c
! 56eacc542ab2a1453a34424301380e68  gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c
  c4406ef230e7a6bb0e7b45b2f94958e9  gcc/testsuite/gcc.target/i386/amxbf16-dpbf16ps-2.c
  0787eb1011631a123144aa2e9fe5b9f2  gcc/testsuite/gcc.target/i386/amxcomplex-asmatt-1.c
! 4a8b5d514b0a549de6d01da6a871cace  gcc/testsuite/gcc.target/i386/amxcomplex-asmintel-1.c
  88abb806331f7455dfc053e7bfa9993d  gcc/testsuite/gcc.target/i386/amxcomplex-cmmimfp16ps-2.c
  5029635b15d7dd713761d53e4630a666  gcc/testsuite/gcc.target/i386/amxcomplex-cmmrlfp16ps-2.c
  0a13ebe83385a9aedb0a82cf5504a96b  gcc/testsuite/gcc.target/i386/amxfp16-asmatt-1.c
! 6367ac8d32cb21d49cfff80aef3427bd  gcc/testsuite/gcc.target/i386/amxfp16-asmintel-1.c
  26723806e86b2502f2d6b3c39febf8ce  gcc/testsuite/gcc.target/i386/amxfp16-dpfp16ps-2.c
  9c0241aa040bd07b656b878c62a423b9  gcc/testsuite/gcc.target/i386/amxint8-asmatt-1.c
! 2a1a600bd028c3c6663894e5e2dbe1ac  gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c
  06751f31b3086f1ff040533de854e994  gcc/testsuite/gcc.target/i386/amxint8-dpbssd-2.c
  e3f6b37649c7f1fa4d20b6327cdcdb27  gcc/testsuite/gcc.target/i386/amxint8-dpbsud-2.c
  a8ab966558faa138830cc3e75dbe4464  gcc/testsuite/gcc.target/i386/amxint8-dpbusd-2.c
*************** fc50af06e61cf9d13887f2fe515b0e27  gcc/te
*** 64908,64914 ****
  a455baf8f9990eb7494164842dce7c91  gcc/testsuite/gcc.target/i386/amxtile-3.c
  84fc02cc52ddc8bdd53d77902c0176fb  gcc/testsuite/gcc.target/i386/amxtile-4.c
  8e7fab1b3f5c89155f09aabb59da8382  gcc/testsuite/gcc.target/i386/amxtile-asmatt-1.c
! 2629a435840ab211444b4a2af4563d8d  gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c
  000edc038d71c16eb844c26f6d7f2f53  gcc/testsuite/gcc.target/i386/and-1.c
  c5cfc6b01e748536e4ac5d65b3528952  gcc/testsuite/gcc.target/i386/andor-1.c
  c052d916aa90fa5343dac48ba370180f  gcc/testsuite/gcc.target/i386/andor-2.c
--- 65071,65077 ----
  a455baf8f9990eb7494164842dce7c91  gcc/testsuite/gcc.target/i386/amxtile-3.c
  84fc02cc52ddc8bdd53d77902c0176fb  gcc/testsuite/gcc.target/i386/amxtile-4.c
  8e7fab1b3f5c89155f09aabb59da8382  gcc/testsuite/gcc.target/i386/amxtile-asmatt-1.c
! fd1b7cbd5c658f65380f068fc3718869  gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c
  000edc038d71c16eb844c26f6d7f2f53  gcc/testsuite/gcc.target/i386/and-1.c
  c5cfc6b01e748536e4ac5d65b3528952  gcc/testsuite/gcc.target/i386/andor-1.c
  c052d916aa90fa5343dac48ba370180f  gcc/testsuite/gcc.target/i386/andor-2.c
*************** fe43a9deff46d9922603adbeeafc1bca  gcc/te
*** 65642,65647 ****
--- 65805,65811 ----
  d88c63775cca32821a256ed084eb0bc4  gcc/testsuite/gcc.target/i386/avx2-pr101611-1.c
  f9c098fee9a454404b6c994c1b481bc0  gcc/testsuite/gcc.target/i386/avx2-pr101611-2.c
  b2a5408a9b77cab42d5d95146250a38f  gcc/testsuite/gcc.target/i386/avx2-pr108599.c
+ a1410da90f646f82394ac1561d97a301  gcc/testsuite/gcc.target/i386/avx2-pr126446.c
  a544282846ec57648b2f38abf14119f0  gcc/testsuite/gcc.target/i386/avx2-pr51581-1.c
  46ffedd4e5e66cd46ad561ee8562eb7b  gcc/testsuite/gcc.target/i386/avx2-pr51581-2.c
  adf63582badc02467af57f768108628f  gcc/testsuite/gcc.target/i386/avx2-pr57233.c
*************** dc7877a60c094039a172aa23afb1e37c  gcc/te
*** 66773,66778 ****
--- 66937,66945 ----
  ce0cad9f4c5da96b0d07d2029604250c  gcc/testsuite/gcc.target/i386/avx512f-pr103750-1.c
  1d9114b974ef8241068b2ece25e00b2e  gcc/testsuite/gcc.target/i386/avx512f-pr103750-2.c
  9a6936f1815277f15801196159007f44  gcc/testsuite/gcc.target/i386/avx512f-pr114566.c
+ f20f5c3dc20ef0309b2a3dc9fdde483e  gcc/testsuite/gcc.target/i386/avx512f-pr124138-1.c
+ efe0a21951178063e3b3f10cf90f0adb  gcc/testsuite/gcc.target/i386/avx512f-pr124138-2.c
+ 1f47d4671c0dd3d13b733838385048ed  gcc/testsuite/gcc.target/i386/avx512f-pr124315.c
  88877c518076ecdec1dba128743ad627  gcc/testsuite/gcc.target/i386/avx512f-pr57233.c
  0272e0fc54cb34ee03db4b0027dbec3d  gcc/testsuite/gcc.target/i386/avx512f-pr63594-1.c
  381f53de01f1e9893e6903d9fac40b87  gcc/testsuite/gcc.target/i386/avx512f-pr63594-2.c
*************** b27abeb08b864284971b1aba8ced6b22  gcc/te
*** 67648,67653 ****
--- 67815,67821 ----
  a0059c72ee5f8a3b553da9a85e2e8686  gcc/testsuite/gcc.target/i386/avx512fp16-pr101846.c
  2e40da5c6cc066c5c3fc6534287c3bb1  gcc/testsuite/gcc.target/i386/avx512fp16-pr103750-1.c
  ddf42476c9bd487716414f58d3c10527  gcc/testsuite/gcc.target/i386/avx512fp16-pr103750-2.c
+ c0aba89383e573771d0b9ccacbca61eb  gcc/testsuite/gcc.target/i386/avx512fp16-pr124335.c
  b5d5082a6d865b8b24dbefc908fafb2d  gcc/testsuite/gcc.target/i386/avx512fp16-pr94680.c
  0be682c7ab6c675fa46f84d592d76785  gcc/testsuite/gcc.target/i386/avx512fp16-recip-1.c
  38a807ac8fade227ea34604df002fb5f  gcc/testsuite/gcc.target/i386/avx512fp16-recip-2.c
*************** dfd6d048c4cc790cbf85d5080d1b5a6e  gcc/te
*** 69000,69005 ****
--- 69168,69174 ----
  e420c76b5d51167be532aea06e242b7d  gcc/testsuite/gcc.target/i386/cet-notrack-icf-2.c
  ecf5960debbf0be72bff47ede8c8800e  gcc/testsuite/gcc.target/i386/cet-notrack-icf-3.c
  8f1538b43a15c0827f66b6f4352ef5fb  gcc/testsuite/gcc.target/i386/cet-notrack-icf-4.c
+ c62171467fd6ad70fac732b022943ed4  gcc/testsuite/gcc.target/i386/cet-pr124366.c
  b8e1eda2f252f129a90e54617fa39500  gcc/testsuite/gcc.target/i386/cet-property-1.c
  f03688bba56369ec92f324db56599b3d  gcc/testsuite/gcc.target/i386/cet-property-2.c
  a4dff4664eff59fc1d1d6ac49e52a6b6  gcc/testsuite/gcc.target/i386/cet-rdssp-1.c
*************** f22f68b0840ac6ff981a038296834407  gcc/te
*** 69044,69050 ****
  b72099cd966e9c576a224799821d5d28  gcc/testsuite/gcc.target/i386/cold-attribute-1.c
  0167fa6749ad93cf0251a4b9260fbccd  gcc/testsuite/gcc.target/i386/cold-attribute-2.c
  c1eab7ffc4e6134b9c680fe0c2920314  gcc/testsuite/gcc.target/i386/cold-attribute-3.c
! dcc5b76590328fd9f7c421fcb66d52d6  gcc/testsuite/gcc.target/i386/cold-attribute-4.c
  6475e870c428b4aeb9a5a7ed5149bb30  gcc/testsuite/gcc.target/i386/combine-mul.c
  51ddf79878f8a3a62bc3a456a718ddb8  gcc/testsuite/gcc.target/i386/compress-float-387-pic.c
  f5b6283707f17b1db37120fd03d9ecf7  gcc/testsuite/gcc.target/i386/compress-float-387.c
--- 69213,69219 ----
  b72099cd966e9c576a224799821d5d28  gcc/testsuite/gcc.target/i386/cold-attribute-1.c
  0167fa6749ad93cf0251a4b9260fbccd  gcc/testsuite/gcc.target/i386/cold-attribute-2.c
  c1eab7ffc4e6134b9c680fe0c2920314  gcc/testsuite/gcc.target/i386/cold-attribute-3.c
! fb80b8e91abc0725f03bd2c87f0692c9  gcc/testsuite/gcc.target/i386/cold-attribute-4.c
  6475e870c428b4aeb9a5a7ed5149bb30  gcc/testsuite/gcc.target/i386/combine-mul.c
  51ddf79878f8a3a62bc3a456a718ddb8  gcc/testsuite/gcc.target/i386/compress-float-387-pic.c
  f5b6283707f17b1db37120fd03d9ecf7  gcc/testsuite/gcc.target/i386/compress-float-387.c
*************** f1728b5e83b3ce3c8eaebf907d52fe30  gcc/te
*** 69499,69504 ****
--- 69668,69674 ----
  c6f6aaff47d064fbceed4cfbcb5b9279  gcc/testsuite/gcc.target/i386/keylocker-encodekey128.c
  a468c392fd8838d0198cfb8b367d4b6d  gcc/testsuite/gcc.target/i386/keylocker-encodekey256.c
  78393ec91600382e98db57e560deaea9  gcc/testsuite/gcc.target/i386/keylocker-loadiwkey.c
+ 75eec9ddfedd16dad1c34342d4bb3a1a  gcc/testsuite/gcc.target/i386/keylocker-pr123217.c
  6a61f297f5746de86187140f048ab655  gcc/testsuite/gcc.target/i386/l_fma_1.h
  c598c1d2a127be1189b3dfe020919429  gcc/testsuite/gcc.target/i386/l_fma_2.h
  8aa60b44b83369f838965e6e8e99c4e7  gcc/testsuite/gcc.target/i386/l_fma_3.h
*************** cbaafd43310e10a7ba4ce687bafe06da  gcc/te
*** 69761,69771 ****
  89d909d7d758041e829631ac800bf196  gcc/testsuite/gcc.target/i386/pieces-memcpy-15.c
  437a6c001b5f504cb8a978424f9f229c  gcc/testsuite/gcc.target/i386/pieces-memcpy-16.c
  a0fc0b89838032f850b17823a354b986  gcc/testsuite/gcc.target/i386/pieces-memcpy-17.c
! ce99ca62859e3b5ee0e5695b59309237  gcc/testsuite/gcc.target/i386/pieces-memcpy-18.c
  b5f6fb3aaac27e15ae52d9111e60d98d  gcc/testsuite/gcc.target/i386/pieces-memcpy-19.c
  279c04d20615905ca5bf2f44eb5a231d  gcc/testsuite/gcc.target/i386/pieces-memcpy-2.c
  7e2d486487e1f536c226d8bc290fd8ad  gcc/testsuite/gcc.target/i386/pieces-memcpy-20.c
! 2f4b551b9d6addea576cff08a8831f3f  gcc/testsuite/gcc.target/i386/pieces-memcpy-21.c
  483ed3c0a5b3efe685343cb5dc87d54d  gcc/testsuite/gcc.target/i386/pieces-memcpy-22.c
  2820c9b91ec98c38843764eea07d4b75  gcc/testsuite/gcc.target/i386/pieces-memcpy-3.c
  698986063dd5ba005476ca849de14359  gcc/testsuite/gcc.target/i386/pieces-memcpy-4.c
--- 69931,69941 ----
  89d909d7d758041e829631ac800bf196  gcc/testsuite/gcc.target/i386/pieces-memcpy-15.c
  437a6c001b5f504cb8a978424f9f229c  gcc/testsuite/gcc.target/i386/pieces-memcpy-16.c
  a0fc0b89838032f850b17823a354b986  gcc/testsuite/gcc.target/i386/pieces-memcpy-17.c
! 7a34703054f1d16fc3e3de2cc1b87012  gcc/testsuite/gcc.target/i386/pieces-memcpy-18.c
  b5f6fb3aaac27e15ae52d9111e60d98d  gcc/testsuite/gcc.target/i386/pieces-memcpy-19.c
  279c04d20615905ca5bf2f44eb5a231d  gcc/testsuite/gcc.target/i386/pieces-memcpy-2.c
  7e2d486487e1f536c226d8bc290fd8ad  gcc/testsuite/gcc.target/i386/pieces-memcpy-20.c
! 9d90237b50551a44a67d354724502ebb  gcc/testsuite/gcc.target/i386/pieces-memcpy-21.c
  483ed3c0a5b3efe685343cb5dc87d54d  gcc/testsuite/gcc.target/i386/pieces-memcpy-22.c
  2820c9b91ec98c38843764eea07d4b75  gcc/testsuite/gcc.target/i386/pieces-memcpy-3.c
  698986063dd5ba005476ca849de14359  gcc/testsuite/gcc.target/i386/pieces-memcpy-4.c
*************** b9528f9fe022aa90d7c7d9764f67ece4  gcc/te
*** 69814,69823 ****
  6a10741d846589134acea1c912c80293  gcc/testsuite/gcc.target/i386/pieces-memset-43.c
  2b47b7f82aeabc7a238642520819b3f0  gcc/testsuite/gcc.target/i386/pieces-memset-44.c
  f2f0e85f12be6d8c85584ef9e34e08ca  gcc/testsuite/gcc.target/i386/pieces-memset-45.c
! f29f6d2af05e1f08f148f0eed162d860  gcc/testsuite/gcc.target/i386/pieces-memset-46.c
  8f0614f1d8cbc09d9e6e515b9c85586c  gcc/testsuite/gcc.target/i386/pieces-memset-47.c
  fab4224ceed336ed6902793909c0c6c2  gcc/testsuite/gcc.target/i386/pieces-memset-48.c
! b6a5763cac2b72e43f0900c7fbca0740  gcc/testsuite/gcc.target/i386/pieces-memset-49.c
  e59e962761850423b307c01f720c8e84  gcc/testsuite/gcc.target/i386/pieces-memset-5.c
  f6afe5571570af54d1d2e02c0e28d3f6  gcc/testsuite/gcc.target/i386/pieces-memset-50.c
  587ca57e48d1c64f4cb91b6203512c99  gcc/testsuite/gcc.target/i386/pieces-memset-51.c
--- 69984,69993 ----
  6a10741d846589134acea1c912c80293  gcc/testsuite/gcc.target/i386/pieces-memset-43.c
  2b47b7f82aeabc7a238642520819b3f0  gcc/testsuite/gcc.target/i386/pieces-memset-44.c
  f2f0e85f12be6d8c85584ef9e34e08ca  gcc/testsuite/gcc.target/i386/pieces-memset-45.c
! 3647374ee718421444609e296cfa0ad2  gcc/testsuite/gcc.target/i386/pieces-memset-46.c
  8f0614f1d8cbc09d9e6e515b9c85586c  gcc/testsuite/gcc.target/i386/pieces-memset-47.c
  fab4224ceed336ed6902793909c0c6c2  gcc/testsuite/gcc.target/i386/pieces-memset-48.c
! 9f2ed79a200ad2a71bf00d1e582aae79  gcc/testsuite/gcc.target/i386/pieces-memset-49.c
  e59e962761850423b307c01f720c8e84  gcc/testsuite/gcc.target/i386/pieces-memset-5.c
  f6afe5571570af54d1d2e02c0e28d3f6  gcc/testsuite/gcc.target/i386/pieces-memset-50.c
  587ca57e48d1c64f4cb91b6203512c99  gcc/testsuite/gcc.target/i386/pieces-memset-51.c
*************** e12ace984bb5ee071207675ca43c7e58  gcc/te
*** 70311,70318 ****
--- 70481,70504 ----
  991b7f7f44e28179f98bb458fdb69ea6  gcc/testsuite/gcc.target/i386/pr11877-2.c
  e7f6a568e551d3786797d6f56294b949  gcc/testsuite/gcc.target/i386/pr11877.c
  61d1a6c7aba6d7071f54e24b6dc92da7  gcc/testsuite/gcc.target/i386/pr118776.c
+ 1404641b6882eb8151341efedd467313  gcc/testsuite/gcc.target/i386/pr120427-1.c
+ b912addc770944f54b5baa8db2467d9d  gcc/testsuite/gcc.target/i386/pr120427-2.c
+ c87152a8a84d546309327b3da89eb566  gcc/testsuite/gcc.target/i386/pr120427-3.c
+ f5a1252b1fe24ea2b97ff3762c399ed9  gcc/testsuite/gcc.target/i386/pr120427-4.c
+ 16984aa55364473d08d90334f60bf59e  gcc/testsuite/gcc.target/i386/pr120427-5.c
+ e33b63cd8f6d60b286b2286424f25714  gcc/testsuite/gcc.target/i386/pr120908.c
  b03b1d817538a863277c823b5e4cdf75  gcc/testsuite/gcc.target/i386/pr12092-1.c
+ 06cf62e068f23c847b4e4ce15a37d992  gcc/testsuite/gcc.target/i386/pr121208-1a.c
+ d7bb5368ed41a3ee6fb312a80c99d313  gcc/testsuite/gcc.target/i386/pr121208-1b.c
+ 4bc0f0b5cb9d3cd77907d3b642e0f8db  gcc/testsuite/gcc.target/i386/pr121208-2a.c
+ 26d68c5cba57817989670af4634fe936  gcc/testsuite/gcc.target/i386/pr121208-2b.c
+ d4ebe08b4cb963582547d8bb5712e712  gcc/testsuite/gcc.target/i386/pr121208-3a.c
+ 5064c3ab2b92e2f20dcd604d557d738c  gcc/testsuite/gcc.target/i386/pr121208-3b.c
+ 600ff3c5da35f468b87a23e0d1678a3e  gcc/testsuite/gcc.target/i386/pr122104.c
+ dc0ac30205a49a37f80c833e996ed4d2  gcc/testsuite/gcc.target/i386/pr123121.c
  f99f88a6e994ad6e55e065e41bc58f8f  gcc/testsuite/gcc.target/i386/pr12329.c
+ 0871390dda9d3f14f2d642eb1d5aa640  gcc/testsuite/gcc.target/i386/pr124056.c
+ daa1cb0a89547fecac9f64b4325b1f0c  gcc/testsuite/gcc.target/i386/pr126429-1.c
  8951a1fa31f2d45ef9eacfff6a733f77  gcc/testsuite/gcc.target/i386/pr13366.c
  9a752a4b3b77930d91d3c8b0c8897b90  gcc/testsuite/gcc.target/i386/pr13685.c
  31ead0ee84b382ba03e3561931bc6e40  gcc/testsuite/gcc.target/i386/pr14289-1.c
*************** a0e47f84ef019a0c0609e9c44732ef14  gcc/te
*** 72920,72925 ****
--- 73106,73112 ----
  f09f84c085c0e194eb110e475ef95081  gcc/testsuite/gcc.target/i386/ssse3-phsubw.c
  e6a3ecb80a089c5e971a5a097701255d  gcc/testsuite/gcc.target/i386/ssse3-pmaddubsw.c
  9779e9b9b03ccba1bbd02aa8014a0c6e  gcc/testsuite/gcc.target/i386/ssse3-pmulhrsw.c
+ 7fe48df578c96c6992918e4881f43572  gcc/testsuite/gcc.target/i386/ssse3-pr125611.c
  15e3df89b9592d7a755e5107a4c6b718  gcc/testsuite/gcc.target/i386/ssse3-pshufb.c
  b3082251265483716a53827b31517936  gcc/testsuite/gcc.target/i386/ssse3-psignb.c
  5c58d5d7c2e35b22f6a4c28d124bde6f  gcc/testsuite/gcc.target/i386/ssse3-psignd.c
*************** d6f2200e900b3d85d0a491db3bfa13bc  gcc/te
*** 73346,73351 ****
--- 73533,73539 ----
  dfafc65f0a89ca5ee45ebec52ceac527  gcc/testsuite/gcc.target/loongarch/pr107713-2.c
  ee611d581d29c00b7178ec95c3dc6e82  gcc/testsuite/gcc.target/loongarch/pr107731.c
  9ad6397c4344b9805128cce24404b86a  gcc/testsuite/gcc.target/loongarch/pr115752.c
+ 8784ee3164375854ef7b1ffc0c536b5e  gcc/testsuite/gcc.target/loongarch/pr125049.c
  3adba2a8ae6f671eb22ec8228777c1ac  gcc/testsuite/gcc.target/loongarch/prolog-opt.c
  1075563283e6d2ab3492f10a46a844ad  gcc/testsuite/gcc.target/loongarch/relocs-symbol-noaddend.c
  1794666eb38b2c760f7e0797a8843251  gcc/testsuite/gcc.target/loongarch/stack-check-alloca-1.c
*************** c02928696f09c7fc9c99174083ecb49c  gcc/te
*** 74727,74733 ****
  a8f9adaf01b9c4605ccf3a2b91395d9a  gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c
  d7a191d70b9b9996b4b19f79964cf6c2  gcc/testsuite/gcc.target/powerpc/builtins-1-le-folded.c
  3630b13056a134afac9072861304e1b7  gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c
! f2df3bae9f5a0120e073ffd853edc95d  gcc/testsuite/gcc.target/powerpc/builtins-1-p9-runnable.c
  b2a3592bc01a8390ab0bcd360e5bfb80  gcc/testsuite/gcc.target/powerpc/builtins-1.c
  ec989a2f75efdf3d6a18fdd8ae6ce35b  gcc/testsuite/gcc.target/powerpc/builtins-1.fold.h
  8e9c179d065241f1abc6396d9fe644c2  gcc/testsuite/gcc.target/powerpc/builtins-2-p9-runnable.c
--- 74915,74921 ----
  a8f9adaf01b9c4605ccf3a2b91395d9a  gcc/testsuite/gcc.target/powerpc/builtins-1-be-folded.c
  d7a191d70b9b9996b4b19f79964cf6c2  gcc/testsuite/gcc.target/powerpc/builtins-1-le-folded.c
  3630b13056a134afac9072861304e1b7  gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c
! dc57c7d2d3ef6cbd9f55a24e38ba3fca  gcc/testsuite/gcc.target/powerpc/builtins-1-p9-runnable.c
  b2a3592bc01a8390ab0bcd360e5bfb80  gcc/testsuite/gcc.target/powerpc/builtins-1.c
  ec989a2f75efdf3d6a18fdd8ae6ce35b  gcc/testsuite/gcc.target/powerpc/builtins-1.fold.h
  8e9c179d065241f1abc6396d9fe644c2  gcc/testsuite/gcc.target/powerpc/builtins-2-p9-runnable.c
*************** d128b18a20f2a55978e519508f48f1ae  gcc/te
*** 76926,76932 ****
  cdde8569ebb2ca104f942dd183c12fa2  gcc/testsuite/gcc.target/powerpc/vsx-builtin-4.c
  9bacca313420b00c643d89ba549c4c57  gcc/testsuite/gcc.target/powerpc/vsx-builtin-5.c
  34d5d7bd0a57589cc1249d19cac92fbf  gcc/testsuite/gcc.target/powerpc/vsx-builtin-6.c
! b85a4370874d0558ca845f7c6e5f0a6d  gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c
  6c165a9a07d4fa8f16289c23ae6a58fd  gcc/testsuite/gcc.target/powerpc/vsx-builtin-8.c
  33633751eb0bfabbb2951a0070770508  gcc/testsuite/gcc.target/powerpc/vsx-builtin-9a.c
  2e9c4b2355be46611bfe42e4a9f8d1f3  gcc/testsuite/gcc.target/powerpc/vsx-builtin-9b.c
--- 77114,77120 ----
  cdde8569ebb2ca104f942dd183c12fa2  gcc/testsuite/gcc.target/powerpc/vsx-builtin-4.c
  9bacca313420b00c643d89ba549c4c57  gcc/testsuite/gcc.target/powerpc/vsx-builtin-5.c
  34d5d7bd0a57589cc1249d19cac92fbf  gcc/testsuite/gcc.target/powerpc/vsx-builtin-6.c
! a3ba74a674fd49b3c22b51c6c608e158  gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c
  6c165a9a07d4fa8f16289c23ae6a58fd  gcc/testsuite/gcc.target/powerpc/vsx-builtin-8.c
  33633751eb0bfabbb2951a0070770508  gcc/testsuite/gcc.target/powerpc/vsx-builtin-9a.c
  2e9c4b2355be46611bfe42e4a9f8d1f3  gcc/testsuite/gcc.target/powerpc/vsx-builtin-9b.c
*************** d8cb2c01011fd067b893a6a06b16aa6e  gcc/te
*** 76971,76984 ****
  43056c312ed673fb7ffa6728311a212d  gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p9.c
  a47d2b2aa16e29fea0595606b20b538e  gcc/testsuite/gcc.target/powerpc/vsx-vector-7.c
  ebd3e2644f3e43135e2172b26fafd1bf  gcc/testsuite/gcc.target/powerpc/vsx-vector-abss.c
! 35d7bcc6cf69574c463501a1e76e510d  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-1.c
! 84cfc07d80810cb3573b9b1f672ac915  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-2.c
! f594dbaf22d3e98eb44318a87d87b445  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-3.c
! dfed3e0b27e36cef4c1b5ca379a587cd  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-4.c
! 90b06f6dd3084d0a0463758c56860af8  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-5.c
! 66401779cf7819a1c89fe27214fee960  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-6.c
! 83dfe066840d622625d47fb5a0b0a7e6  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-7.c
! 909fbf2c73af98a99b3970443e100b03  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-8.c
  c64a5cc2ce1d0b7ac9d881b4585a9313  gcc/testsuite/gcc.target/powerpc/vsx_mask-count-runnable.c
  37a4787409404cc5944ae67ed64e5513  gcc/testsuite/gcc.target/powerpc/vsx_mask-expand-runnable.c
  829a2621c1495feaccfe06f5b735d1db  gcc/testsuite/gcc.target/powerpc/vsx_mask-extract-runnable.c
--- 77159,77180 ----
  43056c312ed673fb7ffa6728311a212d  gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p9.c
  a47d2b2aa16e29fea0595606b20b538e  gcc/testsuite/gcc.target/powerpc/vsx-vector-7.c
  ebd3e2644f3e43135e2172b26fafd1bf  gcc/testsuite/gcc.target/powerpc/vsx-vector-abss.c
! ab8e1bcaca06d2ade6381bc84c1c416b  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-1.c
! 48ee9cd54a5b90dfbb5863a2e48a09c8  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-10.c
! 57c9502895b5ef5cc036b4a24bc9dae2  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-11.c
! 85dab13ddf2c377ae5582da8786f518a  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-12.c
! 7e81559fd15bfe837065dcaf03ed5979  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-13.c
! 7c6cffdf3e1f05d2dec66c7d197e7517  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-14.c
! f4f27e95eeb7fb1d9c950a2108741642  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-15.c
! 8b8ea43be20a8eef8443ed25138feb09  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-16.c
! 71874a8c00aca849836510519349f098  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-2.c
! 29a0c4df2c499616fd17e0c500878f2a  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-3.c
! 8f01c5c01ee100d414706c6b8f14dc39  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-4.c
! 1d534745164dd9ed3170573f14e704c9  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-5.c
! 88516a15016b0ed6d4199e01a383834c  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-6.c
! b2e1150d55fe0e18ac0dc545afe43181  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-7.c
! c66a4fab0f17dd4813aec6e80e6042dc  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-8.c
! a9b38e5a37de52ced500d53d1d518b95  gcc/testsuite/gcc.target/powerpc/vsx-vectorize-9.c
  c64a5cc2ce1d0b7ac9d881b4585a9313  gcc/testsuite/gcc.target/powerpc/vsx_mask-count-runnable.c
  37a4787409404cc5944ae67ed64e5513  gcc/testsuite/gcc.target/powerpc/vsx_mask-expand-runnable.c
  829a2621c1495feaccfe06f5b735d1db  gcc/testsuite/gcc.target/powerpc/vsx_mask-extract-runnable.c
*************** a69e5256407f09ac05e2e19ea14c9e15  gcc/te
*** 78324,78329 ****
--- 78520,78526 ----
  5680e7515cb52b85f38e10b48d5e6a75  gcc/testsuite/gcc.target/s390/pr106355.h
  b3924bf1892d3c296907c61da351118a  gcc/testsuite/gcc.target/s390/pr115860-1.c
  e282b73f72ab6c2a629448cad8de65a7  gcc/testsuite/gcc.target/s390/pr118835.c
+ d519a0e6ac82acfc25e0475e29ea6d80  gcc/testsuite/gcc.target/s390/pr125972.c
  765307a040de72f2f4376b7068d68018  gcc/testsuite/gcc.target/s390/pr20927.c
  85f31fb9b4b15529205376d3f6fa385c  gcc/testsuite/gcc.target/s390/pr24624.c
  7adacbd67601dc0845e556e5632cd718  gcc/testsuite/gcc.target/s390/pr27661.c
*************** d5753d3f6bf92409af4a8ed1584a9000  gcc/te
*** 78779,78784 ****
--- 78976,78982 ----
  4a850593fc1a7bbabb90b46094c87964  gcc/testsuite/gcc.target/sh/hiconst.c
  ae8390e15b5eaf5fd9c40f8bb42c7724  gcc/testsuite/gcc.target/sh/memset.c
  cdd0e79dc0c4fb2425cf6753e465a85e  gcc/testsuite/gcc.target/sh/mfmovd.c
+ e0c2175829f132bf44d0a7d6f8cf419f  gcc/testsuite/gcc.target/sh/pr122948.c
  9439f7da71328f8113b757d9c4130319  gcc/testsuite/gcc.target/sh/pr21255-1.c
  de6f77c59627b198d6e5048192e2f128  gcc/testsuite/gcc.target/sh/pr21255-2-mb.c
  475ae84e95ba85931d38a06a5d6f12f8  gcc/testsuite/gcc.target/sh/pr21255-2-ml.c
*************** bcf389e3992a960c831b1dafe53a539c  gcc/te
*** 79915,79920 ****
--- 80113,80120 ----
  511a4b96302498f658f208676182a550  gcc/testsuite/gdc.dg/debug/pr119826.d
  0121ae6408f107a6bf6f915c24102bd3  gcc/testsuite/gdc.dg/debug/trivial.d
  221872e623e7561cf7ee01e02bd48936  gcc/testsuite/gdc.dg/dg.exp
+ 1f25f7140ea236c33498050fa3d25fc3  gcc/testsuite/gdc.dg/driver_debuglib.d
+ bfb9dc003b6110d37dc4b62c222afe7d  gcc/testsuite/gdc.dg/driver_defaultlib.d
  e13b61cf77c000f61413c39e9ed0fa64  gcc/testsuite/gdc.dg/extern-c++/extern-c++.exp
  61180002f0f17ca7ed75def599d123f0  gcc/testsuite/gdc.dg/extern-c++/pr101664.d
  68936fbe708c1d13dcaca6e4a4a06f77  gcc/testsuite/gdc.dg/extern-c++/pr101664_1.cc
*************** a2d402e0596a4abb1dc6e25b11e9aa9c  gcc/te
*** 80031,80036 ****
--- 80231,80245 ----
  204042c2eb4ac43dee360b7272aee369  gcc/testsuite/gdc.dg/pr116961.d
  a81f29fc44be5cd208351e9e8b4a742b  gcc/testsuite/gdc.dg/pr117621.d
  0b4ca5d336606fc94e656b8731b0a78e  gcc/testsuite/gdc.dg/pr119139.d
+ ad51c6065b49988f50a3f799a0e5f9a3  gcc/testsuite/gdc.dg/pr121477.d
+ e4d8064a02951cfe69cf639a94128dd0  gcc/testsuite/gdc.dg/pr123046.d
+ 9ce0fee5b0fbb84c1de9a43ef50b9462  gcc/testsuite/gdc.dg/pr123264.d
+ e89ebd75d9b162289c929675222e8501  gcc/testsuite/gdc.dg/pr123407a.d
+ a45efe7a1d6f8b7f15f7befa3e7b1768  gcc/testsuite/gdc.dg/pr123407b.d
+ 4e7020df6ad139d4b43104ca5b97d142  gcc/testsuite/gdc.dg/pr123419.d
+ 56c2a0939424aafd465f15ffdd08847b  gcc/testsuite/gdc.dg/pr123798.d
+ 8121b336beaee98841d3fb15f1ac0198  gcc/testsuite/gdc.dg/pr124026.d
+ 0510f96a422a0543d9382a0700a9b0fb  gcc/testsuite/gdc.dg/pr125089.d
  d32aa8ed5ea10931be4ddb5bb9e863d8  gcc/testsuite/gdc.dg/pr89017.d
  53fa8db94d4ca3fc9ba83769733dc0e7  gcc/testsuite/gdc.dg/pr89041.d
  6c316b13f71ea31fcada56b58a41ebd1  gcc/testsuite/gdc.dg/pr89042a.d
*************** eebe0b1a8ecf5f5162d0d07addd22be4  gcc/te
*** 80146,80151 ****
--- 80355,80361 ----
  11af6bc37407477e6b53012a5574c0a9  gcc/testsuite/gdc.dg/torture/imports/pr108055spec.d
  e253515f214e7f5bb8a972ce8348282f  gcc/testsuite/gdc.dg/torture/imports/pr108055write.d
  50c9072e0ffdfc079790d637e1a5c72a  gcc/testsuite/gdc.dg/torture/imports/pr109108.d
+ 1759a92fda4dd14f25ea525b1ce3d479  gcc/testsuite/gdc.dg/torture/imports/pr119799c.c
  646170aa418a99d37c59a7bb02130400  gcc/testsuite/gdc.dg/torture/init1.d
  1ae8edb9b2cd9747efb9868621aec4e8  gcc/testsuite/gdc.dg/torture/pr100882.d
  cede80748e43884ad3613a2a7e4b6ff3  gcc/testsuite/gdc.dg/torture/pr101273.d
*************** de9193ce38f7ef3ee1cc3a94fc8a92dc  gcc/te
*** 80161,80166 ****
--- 80371,80379 ----
  ad67c2aef0ecf01677e58695b0cc5d36  gcc/testsuite/gdc.dg/torture/pr113758.d
  c3a3fcac804266bf984aad50e1f84157  gcc/testsuite/gdc.dg/torture/pr114171.d
  a1ef8a304026fe097c3f6356f2dd2b2a  gcc/testsuite/gdc.dg/torture/pr117002.d
+ afca27995d2dc34f26a56b5ac812a53a  gcc/testsuite/gdc.dg/torture/pr119799.d
+ 07b590affdb88374b53601052d66c8a8  gcc/testsuite/gdc.dg/torture/pr120096.d
+ 18190856d5dece191ecd40c185c2b684  gcc/testsuite/gdc.dg/torture/pr123422.d
  580aadb24b666799e25f1f02ef3b7bbb  gcc/testsuite/gdc.dg/torture/pr92309.d
  d5626e21f8cdc22799175cb6adfddfd6  gcc/testsuite/gdc.dg/torture/pr94424.d
  ae5b279461655f243d767b80a6d0bc1b  gcc/testsuite/gdc.dg/torture/pr94777b.d
*************** d679116c9da43355228e413e4d728bf6  gcc/te
*** 85832,85837 ****
--- 86045,86051 ----
  cb50185eaf87f5357dad5873642eec33  gcc/testsuite/gfortran.dg/contiguous_11.f90
  68eb9244ed2d584beb39fffd7e64f96d  gcc/testsuite/gfortran.dg/contiguous_12.f90
  8621637c284842966acb59cdbfe4e51a  gcc/testsuite/gfortran.dg/contiguous_15.f90
+ dc2299cf4c7a62af39c55807bb5e6d36  gcc/testsuite/gfortran.dg/contiguous_17.f90
  9975df3f787a3eaea63dd5664ff235eb  gcc/testsuite/gfortran.dg/contiguous_2.f90
  a59d0430a52a3cf47c280856725dee23  gcc/testsuite/gfortran.dg/contiguous_3.f90
  b81d56e35fe81ed4c9f6f67cca8a0ab2  gcc/testsuite/gfortran.dg/contiguous_4.f90
*************** c03d85028dd31582bfd3d1f8ca418aa3  gcc/te
*** 87195,87200 ****
--- 87409,87415 ----
  a003f13028702fcf73483db6234e657a  gcc/testsuite/gfortran.dg/goacc/nested-reductions-2-parallel.f90
  dc0ed8100589e01d391b4954bad7b048  gcc/testsuite/gfortran.dg/goacc/nested-reductions-2-routine.f90
  f8fe06410fd4ca50e585e681d35f4482  gcc/testsuite/gfortran.dg/goacc/note-parallelism.f90
+ 8f7b26e930f121be0c4ee68193d7adf3  gcc/testsuite/gfortran.dg/goacc/omp-108382.f90
  44c6212e07bf6b44bd6d26e3224f93d7  gcc/testsuite/gfortran.dg/goacc/omp-fixed.f
  0d004a9c292993dcae37ce3958b7e212  gcc/testsuite/gfortran.dg/goacc/omp.f95
  30617b4201e681ce9fc02f97597b907d  gcc/testsuite/gfortran.dg/goacc/orphan-reductions-1.f90
*************** edeec1fe2488c7117f56e10734af03dc  gcc/te
*** 87579,87584 ****
--- 87794,87800 ----
  697c52a53eea166cade44a3f935b8caf  gcc/testsuite/gfortran.dg/gomp/pr107214-7.f90
  1474c5a5881d7047f1212bc8cfb8ef92  gcc/testsuite/gfortran.dg/gomp/pr107214-8.f90
  3beded12a494129bebcc732d85089896  gcc/testsuite/gfortran.dg/gomp/pr107214.f90
+ 9413acb66d424e7e859e5b387d479808  gcc/testsuite/gfortran.dg/gomp/pr107425.f90
  616305573acc701769497c1eee637edc  gcc/testsuite/gfortran.dg/gomp/pr114825.f90
  9a6817790a272cd8153d4303d324c00f  gcc/testsuite/gfortran.dg/gomp/pr26224.f
  d2c74a71f2bea0005d853821e6f0142c  gcc/testsuite/gfortran.dg/gomp/pr27573.f90
*************** c2c9b1a1db79eedb25331d3565231b66  gcc/te
*** 87665,87670 ****
--- 87881,87887 ----
  6db6e7072dccd0be789b6dc9bd2a586c  gcc/testsuite/gfortran.dg/gomp/pr93555.f90
  a921eeb5697bd066712d41d66d374930  gcc/testsuite/gfortran.dg/gomp/pr94672.f90
  8a04653b9aa2543e13a3136934e00444  gcc/testsuite/gfortran.dg/gomp/pr95869.f90
+ 8512ba21f2d6bfcb3e878c6c91c4dc17  gcc/testsuite/gfortran.dg/gomp/pr98203.f90
  499f4d9c60bbb1a2be81d1888def444c  gcc/testsuite/gfortran.dg/gomp/pr99226.f90
  bcd0369b2e799c3808032efd4c583295  gcc/testsuite/gfortran.dg/gomp/pr99928-1.f90
  5a122e0df6f86c9b8f25e3ef0a8de595  gcc/testsuite/gfortran.dg/gomp/pr99928-11.f90
*************** e5a418513e079e50ea576e021cf5ad8e  gcc/te
*** 88195,88200 ****
--- 88412,88418 ----
  1545bc137f7bcb397e7986a3324b63be  gcc/testsuite/gfortran.dg/inline_matmul_23.f90
  89a35f94060b171becdc54771a02040b  gcc/testsuite/gfortran.dg/inline_matmul_24.f90
  d5dddad98efc37928795b446cb8d6501  gcc/testsuite/gfortran.dg/inline_matmul_25.f90
+ f500cc59ecbd3442513dea98e8f73719  gcc/testsuite/gfortran.dg/inline_matmul_27.f90
  ffdb4ca68f61f3bd618415335c9c7c21  gcc/testsuite/gfortran.dg/inline_matmul_3.f90
  f95e5fd479c839cfa9cb3ac127ee7584  gcc/testsuite/gfortran.dg/inline_matmul_4.f90
  6cb787ca0dac6ea814c8af4ac7cb8022  gcc/testsuite/gfortran.dg/inline_matmul_5.f90
*************** afe21b866be9162c6b654dc6771e6ead  gcc/te
*** 89380,89387 ****
--- 89598,89608 ----
  1dd53d463caf1e16e47d0fe9cbf2309f  gcc/testsuite/gfortran.dg/pr102366.f90
  fc5031b16be6a0dc4152f151793f4acb  gcc/testsuite/gfortran.dg/pr102458.f90
  cbd40bc334c217d37c198b1f27373810  gcc/testsuite/gfortran.dg/pr102458b.f90
+ 44bc627bf6c28a64567fdb75fe688fdc  gcc/testsuite/gfortran.dg/pr102459.f90
  09759ba73ae30c3a54be532d97b7f526  gcc/testsuite/gfortran.dg/pr102520.f90
  107263fe1c86ee042c855774a2b8e242  gcc/testsuite/gfortran.dg/pr102532.f90
+ 4efde3b7d107b33c9c8792e23b683d17  gcc/testsuite/gfortran.dg/pr102596.f90
+ 322a54b0e735415005b9446efbfd32f0  gcc/testsuite/gfortran.dg/pr102619.f90
  c081e1f510a2d68ec176356111dab188  gcc/testsuite/gfortran.dg/pr102685.f90
  d99cea26823109c0bb853b42df152999  gcc/testsuite/gfortran.dg/pr102715.f90
  f28998ba16e7a78633a9de3d5eaf0667  gcc/testsuite/gfortran.dg/pr102816.f90
*************** c35066e873add73fe333d803e2854739  gcc/te
*** 89392,89397 ****
--- 89613,89622 ----
  48782be659f3ec5c8d9cba03ca6cc43d  gcc/testsuite/gfortran.dg/pr103286.f90
  ce86820082e25f5aad2607f9163c3cf4  gcc/testsuite/gfortran.dg/pr103312.f90
  ab2e9f64b18aaf6df9600288ded6ce51  gcc/testsuite/gfortran.dg/pr103366.f90
+ f5b2d7909d22359486a362b6e2b6e6d2  gcc/testsuite/gfortran.dg/pr103367.f90
+ c35efc88e117f86638938a16d6b88054  gcc/testsuite/gfortran.dg/pr103367_2.f90
+ 8a27376a5ce044b06ca3b47f787353d7  gcc/testsuite/gfortran.dg/pr103367_3.f90
+ 066ab4b80e43f24da3f7fe87a2cf8014  gcc/testsuite/gfortran.dg/pr103367_4.f90
  9e00f34ad9d6d78b98007d4ad68251f5  gcc/testsuite/gfortran.dg/pr103389.f90
  5403c8d36e959e2211ecc4f2a1db6e1c  gcc/testsuite/gfortran.dg/pr103475.f90
  b624133cafd19857eb2915c507731455  gcc/testsuite/gfortran.dg/pr103504.f90
*************** d832d83a7f0305ed5af20dce6be24b4b  gcc/te
*** 89498,89503 ****
--- 89723,89729 ----
  e91d746b0b9de2b6ed5529fb46921a0b  gcc/testsuite/gfortran.dg/pr114535d.f90
  60e9f03f051c282f39e48a14c058f5de  gcc/testsuite/gfortran.dg/pr114535iv.f90
  d3d77a4c149cf5358eb97935171795fb  gcc/testsuite/gfortran.dg/pr114739.f90
+ dcc85737c1fe827eb6a63f372dd52f3e  gcc/testsuite/gfortran.dg/pr115260.f90
  862aedc97da38fe9b3319406b768d9c0  gcc/testsuite/gfortran.dg/pr115348.f90
  6c3af77c51cf7ae784cf117509d09064  gcc/testsuite/gfortran.dg/pr117730_a.f90
  c409953e60b511d0f73cda8df16bc1dc  gcc/testsuite/gfortran.dg/pr117730_b.f90
*************** c409953e60b511d0f73cda8df16bc1dc  gcc/te
*** 89507,89512 ****
--- 89733,89741 ----
  4787146fc7e8109511f0d22d056e2127  gcc/testsuite/gfortran.dg/pr120191_2.f90
  05457962d41eef6a41a3de889144d78a  gcc/testsuite/gfortran.dg/pr120191_3.f90
  b1cb2c9a52574c2df5df49bd13ee7e5d  gcc/testsuite/gfortran.dg/pr120196.f90
+ 5bfaeea8d13a5035cf46aaab485c2803  gcc/testsuite/gfortran.dg/pr124450.f90
+ d2d5151630bb11e6342143dc4afe5e96  gcc/testsuite/gfortran.dg/pr125866.f90
+ 79f761eaecad212ada45e8ca1650129e  gcc/testsuite/gfortran.dg/pr126303.f
  984f8307f36d56a0b48b5acce2dd5eb5  gcc/testsuite/gfortran.dg/pr12884.f
  64075248b9d1bffd6f380bb4e2a6eae0  gcc/testsuite/gfortran.dg/pr15129.f90
  e9cbd51db4e16292fc5dd1fead2e5a49  gcc/testsuite/gfortran.dg/pr15140.f90
*************** f166fdd0a6158ee4997aa03d50735f03  gcc/te
*** 89934,89939 ****
--- 90163,90169 ----
  5b2aa5e5d8aa97b69f0cc98bc9709f3f  gcc/testsuite/gfortran.dg/pr78741.f90
  18ef55c7791c30ff0793ca246df65036  gcc/testsuite/gfortran.dg/pr78758.f90
  ee35970003b8954b57c5ce45c7fd506c  gcc/testsuite/gfortran.dg/pr79315.f90
+ 76b2c561e2cc2dffb48457fae519ab01  gcc/testsuite/gfortran.dg/pr79524.f90
  7dde52ec5dffa2ae8586c577cf97f742  gcc/testsuite/gfortran.dg/pr79886.f90
  c0b10ae015725070f4297a1ba8927463  gcc/testsuite/gfortran.dg/pr79966.f90
  21b5f06229f04696cc787b63748c5de0  gcc/testsuite/gfortran.dg/pr80494.f90
*************** e338cfba2f466abedf9af92b52cd6fb3  gcc/te
*** 89954,89959 ****
--- 90184,90190 ----
  b6ff04901e3aee18765a74bf65804e38  gcc/testsuite/gfortran.dg/pr82253.f90
  344be7c0602202457870166d368441e0  gcc/testsuite/gfortran.dg/pr82314.f90
  7f04eca318ca64e1442ceabc31fab9fb  gcc/testsuite/gfortran.dg/pr82397.f
+ 9f2daedbf44298499832b2b6d72eb79f  gcc/testsuite/gfortran.dg/pr82721.f90
  5e9eb92684de357b4c23a7f04959db82  gcc/testsuite/gfortran.dg/pr82774.f90
  616772c135ee9b14c410dcd23fdbc3e4  gcc/testsuite/gfortran.dg/pr82973.f90
  0a918cecf6f52a31004b77728cb30038  gcc/testsuite/gfortran.dg/pr83113.f90
*************** fd7937a762c5733d3533bba0d9b05a6e  gcc/te
*** 89968,89973 ****
--- 90199,90205 ----
  95b2ba5b10167fedc1a075877a7a103b  gcc/testsuite/gfortran.dg/pr84088.f90
  ee7b5aa850a8be8a1ed15f2fcdca347a  gcc/testsuite/gfortran.dg/pr84117.f90
  c41bc69547a048a19ccb1adc57ce3bca  gcc/testsuite/gfortran.dg/pr84155.f90
+ e6d08fa65e9eb602b71f0e6a8b44a739  gcc/testsuite/gfortran.dg/pr84245.f90
  12af81a97aa86950b63e458f115e45c9  gcc/testsuite/gfortran.dg/pr84523.f90
  6d593814cbde3b81eb21e9501a48bac2  gcc/testsuite/gfortran.dg/pr84565.f90
  4cf62650961664b3e4bce16d177b5929  gcc/testsuite/gfortran.dg/pr84674.f90
*************** f9cd7fe0c8cb7be5b0846aa6c3eb0b93  gcc/te
*** 90175,90181 ****
--- 90407,90416 ----
  9a2df63b77cda57168f292b09bde71b3  gcc/testsuite/gfortran.dg/pr93686_4.f90
  0636d4a049257c8e3f6c32b4b7309697  gcc/testsuite/gfortran.dg/pr93714_1.f90
  93b8b244bce4583a43c29d892e177744  gcc/testsuite/gfortran.dg/pr93714_2.f90
+ 9a8647e0b1ef01e06d45cc2715ae05e8  gcc/testsuite/gfortran.dg/pr93715.f90
  4d2e245917c39b1bcaeea6010bcb6284  gcc/testsuite/gfortran.dg/pr93792.f90
+ 1c1c17dce5c14eb846c34e6f6eba3b12  gcc/testsuite/gfortran.dg/pr93814.f90
+ 5494bfcb0d61c11d34ea0b6e4e610c45  gcc/testsuite/gfortran.dg/pr93832.f90
  8b7bf068692a6a31b63dd4963c050e98  gcc/testsuite/gfortran.dg/pr93835.f08
  6736173bcc319bca35f5453a7bca947b  gcc/testsuite/gfortran.dg/pr94030_1.f90
  b0f8acfae3746c459e5af7bcca222814  gcc/testsuite/gfortran.dg/pr94030_2.f90
*************** b0f8acfae3746c459e5af7bcca222814  gcc/te
*** 90183,90188 ****
--- 90418,90424 ----
  f17ab40b1ca95ac01da77049baa72103  gcc/testsuite/gfortran.dg/pr94329.f90
  b9faba8aac0e0dd38443caeb527db93d  gcc/testsuite/gfortran.dg/pr94397.F90
  16d161f7900dd36eabcbaea6cd9c1b6e  gcc/testsuite/gfortran.dg/pr94708.f90
+ e49db1fd07a952483324884a3682a4e8  gcc/testsuite/gfortran.dg/pr94978.f90
  b3aa92652c768e489db71c4bdec58492  gcc/testsuite/gfortran.dg/pr95053.f
  4643a453de4a8df5432d833cf8bfa122  gcc/testsuite/gfortran.dg/pr95053_2.f90
  9a887ac1c462736f729ec4ec967c8be2  gcc/testsuite/gfortran.dg/pr95053_3.f90
*************** a6b1d851f4c5b6cfffa8f56c8f9cd150  gcc/te
*** 90191,90196 ****
--- 90427,90433 ----
  81355955ad98611710451ef6e76d9dbe  gcc/testsuite/gfortran.dg/pr95090.f90
  10a1157f7a9fa8f2042a563c98a25914  gcc/testsuite/gfortran.dg/pr95091.f90
  7d3e3457f90590b31740ffdd3a4866a3  gcc/testsuite/gfortran.dg/pr95104.f90
+ e11cb19990efd60513bbac52ee105f02  gcc/testsuite/gfortran.dg/pr95338.f90
  66c58770643ed3f1944820fa6790cc27  gcc/testsuite/gfortran.dg/pr95340.f90
  395135621c98fea610c5f2b17feb7637  gcc/testsuite/gfortran.dg/pr95342.f90
  b9d5894d240b89777d50d53e0cd60929  gcc/testsuite/gfortran.dg/pr95373_1.f90
*************** a5234963084d71f3cbff36fdddbc2a39  gcc/te
*** 90223,90228 ****
--- 90460,90466 ----
  662210e69dcf405442181d9c4c2a91ec  gcc/testsuite/gfortran.dg/pr95827.f90
  62cd2c3c38efcf3442a00b172c23a0f1  gcc/testsuite/gfortran.dg/pr95828.f90
  f2cfdbd57b646ea77c8d2d572b0b4a79  gcc/testsuite/gfortran.dg/pr95829.f90
+ 153dd2ab3bb579bad81f3ed62e079ff2  gcc/testsuite/gfortran.dg/pr95879.f90
  4624ef21d27373ca19abedc766bf24c8  gcc/testsuite/gfortran.dg/pr95880.f90
  5f79fc5c2f7a030ad1b82b4793b0c8a7  gcc/testsuite/gfortran.dg/pr95881.f90
  5f9a08444201a18392648013e972a14a  gcc/testsuite/gfortran.dg/pr95882_1.f90
*************** c8c260dea52e24ac6be6641b8f123d9a  gcc/te
*** 90261,90266 ****
--- 90499,90505 ----
  a056a75dc3c7830d385da1c0b9d587bc  gcc/testsuite/gfortran.dg/pr96711.f90
  a94ae73a3b6b9628990c54fb08f2950c  gcc/testsuite/gfortran.dg/pr96737.f90
  74a709306836d044b8cd43d035aecdf2  gcc/testsuite/gfortran.dg/pr96859.f90
+ 3b72f7e6589a60bc5e040e31c77484b8  gcc/testsuite/gfortran.dg/pr96986.f90
  76f063a5164cc2eff42c50fc9b9989a1  gcc/testsuite/gfortran.dg/pr97036.f90
  70cac68f93e5398eb60f3aa67f709e6a  gcc/testsuite/gfortran.dg/pr97095.f
  f219dfba008fc41e9e809107b3498d57  gcc/testsuite/gfortran.dg/pr97272.f90
*************** ad625f0340741a09e4be8d42e070139e  gcc/te
*** 91137,91142 ****
--- 91376,91382 ----
  7f1199fe5fa90085dcbb4f81cbcf7062  gcc/testsuite/gfortran.dg/transfer_class_2.f90
  4003da30901edcfc6adf19924dc746a2  gcc/testsuite/gfortran.dg/transfer_class_3.f90
  d9a1040ed4fe93e5d91936d8b26af4cc  gcc/testsuite/gfortran.dg/transfer_class_4.f90
+ d265a0bb0e3067107f69caac520518ea  gcc/testsuite/gfortran.dg/transfer_class_5.f90
  dc67674921059cc6c14a48ba9f6e8515  gcc/testsuite/gfortran.dg/transfer_hollerith_1.f90
  adc172acf631bf550ac06d92fba37d99  gcc/testsuite/gfortran.dg/transfer_intrinsic_1.f90
  e26ab1b7e21f778b1135b8600958bcd1  gcc/testsuite/gfortran.dg/transfer_intrinsic_2.f90
*************** dc0d018c7ef4988da05274a87a491db9  gcc/te
*** 94176,94181 ****
--- 94416,94422 ----
  f1da017e79e481af350005333250268b  gcc/testsuite/gnat.dg/bias2.adb
  aae39b549f5bb7a2b837495c637aaa94  gcc/testsuite/gnat.dg/biased_subtype.adb
  9bbc182ee19d36c4abbd7d6046ac5664  gcc/testsuite/gnat.dg/biased_uc.adb
+ e075dee38216366d67c6249860794304  gcc/testsuite/gnat.dg/bigint1.adb
  faf4a0c852ea85d2eab4ec4413be5fba  gcc/testsuite/gnat.dg/bip_aggregate_bug.adb
  8207ec6dfb08b203e67809b4591cc486  gcc/testsuite/gnat.dg/bip_case_expr.adb
  0dd427e9ad2957343c4c86027593a8a0  gcc/testsuite/gnat.dg/bip_case_expr_pkg.ads
*************** da22f29f94ebe295441ccc41597913b0  gcc/te
*** 94693,94698 ****
--- 94934,94942 ----
  29969c1ad7978ac871e75cd3b2d99efd  gcc/testsuite/gnat.dg/generic_inst14_pkg.ads
  bfa8ba450e641250f8eccf95997dd260  gcc/testsuite/gnat.dg/generic_inst2.adb
  063cf5c93b1a85bf617a62be0da63bdb  gcc/testsuite/gnat.dg/generic_inst2.ads
+ 9754b7078322105e191275ecef261619  gcc/testsuite/gnat.dg/generic_inst20-sub.adb
+ 0681c30c9efac88d67f6a19fb0a024db  gcc/testsuite/gnat.dg/generic_inst20.adb
+ c840150e814260285b976366030a3845  gcc/testsuite/gnat.dg/generic_inst20.ads
  2faefd507420ceafdccad8d472e66202  gcc/testsuite/gnat.dg/generic_inst2_c.ads
  1997a63f7761d0c3157019f91d059346  gcc/testsuite/gnat.dg/generic_inst3.adb
  ec082cac4cc6410759efb287bf918b11  gcc/testsuite/gnat.dg/generic_inst3_kafka_lib-topic.ads
*************** e3943d4860baba3dd60a559ec3b4df36  gcc/te
*** 95215,95220 ****
--- 95459,95466 ----
  858a5d2e6efff052115969f794debc69  gcc/testsuite/gnat.dg/opt102_pkg.ads
  337a806a6dd1106b843af17238d34b5b  gcc/testsuite/gnat.dg/opt104.adb
  7ee5b6675114982998270619932802bf  gcc/testsuite/gnat.dg/opt104.ads
+ 9d150b19ff3791d45b239fbe539ca3ec  gcc/testsuite/gnat.dg/opt107.adb
+ b639e95e2056957733aa779c0c757061  gcc/testsuite/gnat.dg/opt107_pkg.ads
  5d50fb38b1ab84c39760906cb103c522  gcc/testsuite/gnat.dg/opt10_pkg.ads
  603264d4afdd2fd2174ea9c4cf4653ed  gcc/testsuite/gnat.dg/opt11.adb
  53160585b3a5d820b653e1e0d5f14c75  gcc/testsuite/gnat.dg/opt11.ads
*************** a4f83930fb87bd91e5bb42db50c8d318  gcc/te
*** 95586,95591 ****
--- 95832,95838 ----
  c0f68295e348ad36a641d8edeff2cfc6  gcc/testsuite/gnat.dg/prot9_pkg1.ads
  4cd15245a3399652865b3c6a9daf87ad  gcc/testsuite/gnat.dg/prot9_pkg2.ads
  8b9d81034e4a3268cbc4aae764775fd9  gcc/testsuite/gnat.dg/prot_def.adb
+ 00f160c0176ca352cbe49cfb9735cb39  gcc/testsuite/gnat.dg/protected_deref1.adb
  ca3a0803b3696ed0b41f6d8cbb5b962b  gcc/testsuite/gnat.dg/protected_func.adb
  f010d95f371dbccc1be8c51d48eb4db5  gcc/testsuite/gnat.dg/protected_func.ads
  ce1ec39ed99de56ced45d8b9f86bc85a  gcc/testsuite/gnat.dg/protected_null.adb
*************** e51121d34de5e0d22067137864528c8a  gcc/te
*** 95638,95643 ****
--- 95885,95891 ----
  72d48cda9550a7251bbd90fa56eff48e  gcc/testsuite/gnat.dg/renaming15.adb
  b08ade850be1a0a80325c1a93e9c9043  gcc/testsuite/gnat.dg/renaming16.adb
  0278c64b189f758651064d6a8aeac4db  gcc/testsuite/gnat.dg/renaming16_pkg.ads
+ b500c932c841816b5021e1c75ea367c9  gcc/testsuite/gnat.dg/renaming18.adb
  3afb13f37cfc3455f0f0be64d053892f  gcc/testsuite/gnat.dg/renaming2.adb
  1a954da0b1e7e11673319b058eb82146  gcc/testsuite/gnat.dg/renaming3.adb
  9c415422ce59266c9af89e8d3fd1df74  gcc/testsuite/gnat.dg/renaming4.ads
*************** d2c31258feee390ed4af80cdc8eacf9e  gcc/te
*** 95863,95868 ****
--- 96111,96119 ----
  4f688dab65d3a3dce65837fb7dc54961  gcc/testsuite/gnat.dg/specs/opt5.ads
  f156038848774963622d503fe89a172b  gcc/testsuite/gnat.dg/specs/opt5_pkg.ads
  3ea255ec02895b0a6def7cabd8242168  gcc/testsuite/gnat.dg/specs/opt6.ads
+ 28f117df0f784b2fc789be52a8363bc4  gcc/testsuite/gnat.dg/specs/opt7.ads
+ 9076cc8edf48925166dff1f53e624108  gcc/testsuite/gnat.dg/specs/opt7_pkg.adb
+ ab4d470a175348305442c782df20dc08  gcc/testsuite/gnat.dg/specs/opt7_pkg.ads
  a33d565d33da0c1fd4225f3e0005c81e  gcc/testsuite/gnat.dg/specs/oversize.ads
  c177b376a4a8546663a7caa87b66abb4  gcc/testsuite/gnat.dg/specs/pack10.ads
  aca39671a4d090d6d3c7a2abf4ee74a6  gcc/testsuite/gnat.dg/specs/pack10_pkg.adb
*************** de366240409b1c3413cd274333487fb7  gcc/te
*** 95937,95942 ****
--- 96188,96194 ----
  67001591d13a2654ac5b7435e121cb10  gcc/testsuite/gnat.dg/specs/unchecked_convert2.ads
  a013922e8c147a09784a5aca21aa3a65  gcc/testsuite/gnat.dg/specs/unchecked_union1.ads
  fbc11dba24887c4af40c8660f7168a67  gcc/testsuite/gnat.dg/specs/unchecked_union2.ads
+ bc8a00cafe93a77626f7d163fb369bcf  gcc/testsuite/gnat.dg/specs/unchecked_union3.ads
  c8cf8a4c8db78f809bd3550ca820e6a5  gcc/testsuite/gnat.dg/specs/universal_fixed.ads
  956da2e940d0e7706607f91ce39d70ad  gcc/testsuite/gnat.dg/specs/variant_part.ads
  12e2e0159b45a86a40c49bc020048d43  gcc/testsuite/gnat.dg/specs/varsize_return.ads
*************** fd304d08c4ca43544588bd14358a9c0a  gcc/te
*** 96042,96047 ****
--- 96294,96300 ----
  6c87692ce5565e68f354b3b1cb842c39  gcc/testsuite/gnat.dg/sso18.adb
  ff784f7bca69d0717e740273960b0387  gcc/testsuite/gnat.dg/sso2.adb
  ccf43eb5df39869bb23ff9110d3b93cb  gcc/testsuite/gnat.dg/sso2.ads
+ 2ba1a49876e7f91ccde7f7d0288debb0  gcc/testsuite/gnat.dg/sso20.adb
  6fe64945c0d0238672cdece04341c316  gcc/testsuite/gnat.dg/sso3.adb
  cce4578d630a50acb2e3a4f2535af90b  gcc/testsuite/gnat.dg/sso4.adb
  6547028813699cf5a1bebf9380db3b22  gcc/testsuite/gnat.dg/sso5.adb
*************** f37d4791cfa22e9a20848922ea5de498  gcc/te
*** 96462,96468 ****
  b760f8c4f0593565426879b84ab6787b  gcc/testsuite/go.go-torture/execute/var-1.go
  55c3fdb5eab9130c79b8548c994aa8d9  gcc/testsuite/go.go-torture/execute/var-2.go
  ac0017eb534302ec5987291f615d13ca  gcc/testsuite/go.go-torture/execute/var-3.go
! f6da68fce4ac830fac5e50ccfca98947  gcc/testsuite/go.test/go-test.exp
  88c59e0bc9f2a79ed3a3e8f1409ed1d8  gcc/testsuite/go.test/test/235.go
  1a94dd86d2262280f883261800a13104  gcc/testsuite/go.test/test/64bit.go
  43e15a8d565d16ab908b7cf6db8e0bf9  gcc/testsuite/go.test/test/README.gcc
--- 96715,96721 ----
  b760f8c4f0593565426879b84ab6787b  gcc/testsuite/go.go-torture/execute/var-1.go
  55c3fdb5eab9130c79b8548c994aa8d9  gcc/testsuite/go.go-torture/execute/var-2.go
  ac0017eb534302ec5987291f615d13ca  gcc/testsuite/go.go-torture/execute/var-3.go
! 2481358c4d9cdd81607b425d7eb5b891  gcc/testsuite/go.test/go-test.exp
  88c59e0bc9f2a79ed3a3e8f1409ed1d8  gcc/testsuite/go.test/test/235.go
  1a94dd86d2262280f883261800a13104  gcc/testsuite/go.test/test/64bit.go
  43e15a8d565d16ab908b7cf6db8e0bf9  gcc/testsuite/go.test/test/README.gcc
*************** dfe90e3e8ee193e050914ed19adcef15  gcc/te
*** 98605,98612 ****
  98b18bc4d02a0dcf760cf74fff32b5da  gcc/testsuite/lib/go.exp
  6f968754557e9731dcf79c719ac64887  gcc/testsuite/lib/hwasan-dg.exp
  9acf7bc29364e8ee8fc4c28b27e8f6fc  gcc/testsuite/lib/lto.exp
! 3a5404afeb2a25b9128a466e80230c0e  gcc/testsuite/lib/mike-g++.exp
! 090d0fd3aa8a38a3cb03da40bb61c7fb  gcc/testsuite/lib/mike-gcc.exp
  133f3398df43cb63a1377e277f365f1e  gcc/testsuite/lib/multiline.exp
  65197ec2d78a9b0c43a393366a2f636f  gcc/testsuite/lib/obj-c++-dg.exp
  794e25dc0eab921c538676df31b0bd3d  gcc/testsuite/lib/obj-c++.exp
--- 98858,98865 ----
  98b18bc4d02a0dcf760cf74fff32b5da  gcc/testsuite/lib/go.exp
  6f968754557e9731dcf79c719ac64887  gcc/testsuite/lib/hwasan-dg.exp
  9acf7bc29364e8ee8fc4c28b27e8f6fc  gcc/testsuite/lib/lto.exp
! d97875761a7b6ff1df1d89a2ecbfccdd  gcc/testsuite/lib/mike-g++.exp
! 6ac6c1271ece2c10cb4d2de3a694556b  gcc/testsuite/lib/mike-gcc.exp
  133f3398df43cb63a1377e277f365f1e  gcc/testsuite/lib/multiline.exp
  65197ec2d78a9b0c43a393366a2f636f  gcc/testsuite/lib/obj-c++-dg.exp
  794e25dc0eab921c538676df31b0bd3d  gcc/testsuite/lib/obj-c++.exp
*************** e020b68426183241592d8d9e6fc099b4  gcc/te
*** 98634,98640 ****
  b295a72c05b831c76c031b8e2eb4d3b2  gcc/testsuite/lib/scanwpaipa.exp
  193dff75973e9817b77d076cd499f3fa  gcc/testsuite/lib/target-libpath.exp
  3d3f2e71aead61b3117d14eb7bbd4a01  gcc/testsuite/lib/target-supports-dg.exp
! c340faeb4b9a17de175506f693cdba4a  gcc/testsuite/lib/target-supports.exp
  7e0169745cc1fb5c7a32430931fd5493  gcc/testsuite/lib/target-utils.exp
  60311806ad83bff4ff32a9473e1b70f2  gcc/testsuite/lib/timeout-dg.exp
  b097a1276df72ba56dc546dc3859883c  gcc/testsuite/lib/timeout.exp
--- 98887,98893 ----
  b295a72c05b831c76c031b8e2eb4d3b2  gcc/testsuite/lib/scanwpaipa.exp
  193dff75973e9817b77d076cd499f3fa  gcc/testsuite/lib/target-libpath.exp
  3d3f2e71aead61b3117d14eb7bbd4a01  gcc/testsuite/lib/target-supports-dg.exp
! 0f9acc7018e46dd69e49ec12a112f6d5  gcc/testsuite/lib/target-supports.exp
  7e0169745cc1fb5c7a32430931fd5493  gcc/testsuite/lib/target-utils.exp
  60311806ad83bff4ff32a9473e1b70f2  gcc/testsuite/lib/timeout-dg.exp
  b097a1276df72ba56dc546dc3859883c  gcc/testsuite/lib/timeout.exp
*************** ad4739e1ababa9fe99c700a409d4d39c  gcc/tr
*** 100469,100475 ****
  51a9944253ec880d2fcefce4f457fd81  gcc/tree-hasher.h
  4528063fea5b6304571700b11c07ee3f  gcc/tree-if-conv.cc
  d827a40245726bb17d7019eeb50733a5  gcc/tree-if-conv.h
! 2370d942b5c54b26b1330de13e076535  gcc/tree-inline.cc
  05a54334040842ce3f2e8586d3d67b76  gcc/tree-inline.h
  9cfa0b6fbd2cdc3d42b9a6a68ee42ef5  gcc/tree-into-ssa.cc
  f1fe226578aba70864fab526bf69c25b  gcc/tree-into-ssa.h
--- 100722,100728 ----
  51a9944253ec880d2fcefce4f457fd81  gcc/tree-hasher.h
  4528063fea5b6304571700b11c07ee3f  gcc/tree-if-conv.cc
  d827a40245726bb17d7019eeb50733a5  gcc/tree-if-conv.h
! 3c0a109e3e3bf7fa940cc1b2a779b1ae  gcc/tree-inline.cc
  05a54334040842ce3f2e8586d3d67b76  gcc/tree-inline.h
  9cfa0b6fbd2cdc3d42b9a6a68ee42ef5  gcc/tree-into-ssa.cc
  f1fe226578aba70864fab526bf69c25b  gcc/tree-into-ssa.h
*************** dd6ddd51a9c744753847a5f1a430a39f  gcc/tr
*** 100481,100487 ****
  4ab7af103ce3eb3d3e4ae5c7181a3141  gcc/tree-nested.cc
  9bba957c6a1ab17bb89c93f7fe4f63df  gcc/tree-nested.h
  f08dc5d3e5c244c9f3d0921a13600db5  gcc/tree-nrv.cc
! a8b5a8b393e29bc66eabece825727e6e  gcc/tree-object-size.cc
  bfa736bad94c583d64422b6c456d417c  gcc/tree-object-size.h
  3e0aa973134ed4274a15d14bb99f4705  gcc/tree-outof-ssa.cc
  68b06a88c5e019fa02e2cc89cc51aae9  gcc/tree-outof-ssa.h
--- 100734,100740 ----
  4ab7af103ce3eb3d3e4ae5c7181a3141  gcc/tree-nested.cc
  9bba957c6a1ab17bb89c93f7fe4f63df  gcc/tree-nested.h
  f08dc5d3e5c244c9f3d0921a13600db5  gcc/tree-nrv.cc
! d51c407fb5b8a906873bdf4f5e93aa8c  gcc/tree-object-size.cc
  bfa736bad94c583d64422b6c456d417c  gcc/tree-object-size.h
  3e0aa973134ed4274a15d14bb99f4705  gcc/tree-outof-ssa.cc
  68b06a88c5e019fa02e2cc89cc51aae9  gcc/tree-outof-ssa.h
*************** a454429f57d8839090a7ec73abbfa772  gcc/tr
*** 100494,100507 ****
  edd6c1f313befbbd0943aa5df67a8379  gcc/tree-pretty-print.cc
  feca017a2b8993f6879429c3b7fa9740  gcc/tree-pretty-print.h
  13e933e748d0799695ef67be87740769  gcc/tree-profile.cc
! 835e107c7d950e109cab7dc47dd27a51  gcc/tree-scalar-evolution.cc
  b8223329488a4001552728350c5dbbef  gcc/tree-scalar-evolution.h
! 031698db6d2907dd7d749a4ff8847897  gcc/tree-sra.cc
  1f7981f8ac0c98c7d1acb674035e2c16  gcc/tree-sra.h
  931fca6fc15298fa1f2021f8e4f2ed8d  gcc/tree-ssa-address.cc
  c37e139873f3e8da2fffefa09903ee42  gcc/tree-ssa-address.h
  e7da83a9f8b9fdd2773b043ed2e5d28d  gcc/tree-ssa-alias-compare.h
! 7fac33c1038c88f8f926620ac4bdf3c8  gcc/tree-ssa-alias.cc
  ba44f6b9cdb34f227ce92ce6bbaaf35d  gcc/tree-ssa-alias.h
  6a88811f7f31882f57fe34d498a722d4  gcc/tree-ssa-ccp.cc
  cd2e4de6ee944facf2a1995f8743f8c2  gcc/tree-ssa-ccp.h
--- 100747,100760 ----
  edd6c1f313befbbd0943aa5df67a8379  gcc/tree-pretty-print.cc
  feca017a2b8993f6879429c3b7fa9740  gcc/tree-pretty-print.h
  13e933e748d0799695ef67be87740769  gcc/tree-profile.cc
! c48cd3335056d0f516107ea6b728d398  gcc/tree-scalar-evolution.cc
  b8223329488a4001552728350c5dbbef  gcc/tree-scalar-evolution.h
! 7911dc1647f159903a7b02949f0ae9ef  gcc/tree-sra.cc
  1f7981f8ac0c98c7d1acb674035e2c16  gcc/tree-sra.h
  931fca6fc15298fa1f2021f8e4f2ed8d  gcc/tree-ssa-address.cc
  c37e139873f3e8da2fffefa09903ee42  gcc/tree-ssa-address.h
  e7da83a9f8b9fdd2773b043ed2e5d28d  gcc/tree-ssa-alias-compare.h
! 7067bad4860c241813f77e8cde8790b0  gcc/tree-ssa-alias.cc
  ba44f6b9cdb34f227ce92ce6bbaaf35d  gcc/tree-ssa-alias.h
  6a88811f7f31882f57fe34d498a722d4  gcc/tree-ssa-ccp.cc
  cd2e4de6ee944facf2a1995f8743f8c2  gcc/tree-ssa-ccp.h
*************** da67de91badb3e7882b0f0f56a67670e  gcc/tr
*** 100512,100554 ****
  e36c0da1e5dc257d4ccff9c24043d7fc  gcc/tree-ssa-dce.h
  35f365067a15b900bdc007c8c4366fd1  gcc/tree-ssa-dom.cc
  aba207ac671bbe2380e556429ad21a00  gcc/tree-ssa-dom.h
! 96193370d3840ed2faa499783b5b1028  gcc/tree-ssa-dse.cc
  9fe4418350cac32811c9ed2ed8de371f  gcc/tree-ssa-dse.h
  8d97cf47138ffd7cd6f4c316e206b8f2  gcc/tree-ssa-forwprop.cc
  567c30a8d9160fdcd286536c8e4a553e  gcc/tree-ssa-ifcombine.cc
  e5c556ba07b04f0f9890c0d4618c716e  gcc/tree-ssa-live.cc
  d68a110616d98e6c023567d2239e4e13  gcc/tree-ssa-live.h
  286a1abc75a2657034c3ff16b07e46cb  gcc/tree-ssa-loop-ch.cc
! 82db0d5ee7e3891957928ab4770ad9df  gcc/tree-ssa-loop-im.cc
  e167c39b8e8961b4e66068ab4f68bed2  gcc/tree-ssa-loop-ivcanon.cc
! 2a82e5db3ae8cda9f73ccedf14ad528f  gcc/tree-ssa-loop-ivopts.cc
  370a3d6606f97b793ee8a94e17f8a1f5  gcc/tree-ssa-loop-ivopts.h
  aa498fcb0de83e00d2d79464ed4fa669  gcc/tree-ssa-loop-manip.cc
  c10dc1a11bed8461c36db2d370f534b6  gcc/tree-ssa-loop-manip.h
! c90a53a9053650864e74999a5ab82442  gcc/tree-ssa-loop-niter.cc
  63e23177ceb0e06f07092e962fb6ec1e  gcc/tree-ssa-loop-niter.h
  29515e41d02e46edeeede5dbddecc177  gcc/tree-ssa-loop-prefetch.cc
! 8d00446e723fdc157e179d58c825952a  gcc/tree-ssa-loop-split.cc
! 26df2fae62e7d250256c7f2b30015278  gcc/tree-ssa-loop-unswitch.cc
  e2040b0e641b28b006e48fb2094500e2  gcc/tree-ssa-loop.cc
  943d41105325f8de1cdae2b4faf2dd0a  gcc/tree-ssa-loop.h
! 576b94b194874eb083ba0b791d6a2494  gcc/tree-ssa-math-opts.cc
  e9484a6f5b1f9056c6681cedce910ed4  gcc/tree-ssa-math-opts.h
  918abd54b699b48204a42158c4379381  gcc/tree-ssa-operands.cc
  0db421e827039fe3c4f796b4c7600c52  gcc/tree-ssa-operands.h
! e78eec419e994fc2d9ed7161400c6439  gcc/tree-ssa-phiopt.cc
  731542d52a45ac5f609554aee9faf6dd  gcc/tree-ssa-phiprop.cc
! ef15621f3fcf286ff9b897cc3ef0d498  gcc/tree-ssa-pre.cc
! 92e37073a834f5e59681947910d76467  gcc/tree-ssa-propagate.cc
  658e45ca3c1c387fbd4e8bf835de1acd  gcc/tree-ssa-propagate.h
! 58c0ef78644b94b752f3d6d91823c3f9  gcc/tree-ssa-reassoc.cc
  3d6728ab6aa97921854f86b5d2116c3d  gcc/tree-ssa-reassoc.h
! 043efbe0ee23033d49aed6bcec082b3b  gcc/tree-ssa-sccvn.cc
  1c663c39e61b7e64cbea685db2598475  gcc/tree-ssa-sccvn.h
  0dd72fccd9280ac160f5ac770517ee10  gcc/tree-ssa-scopedtables.cc
  bdda02f8f5872266cc26122c45c7d248  gcc/tree-ssa-scopedtables.h
  3651b347d24df9f7410ea32fdf639a5d  gcc/tree-ssa-sink.cc
! edb47f7d1dfba701b0bea40c2c33eeb2  gcc/tree-ssa-strlen.cc
  cae334e8d7f57adf439062af515c28ae  gcc/tree-ssa-strlen.h
  c447caeb8cd3ddc21a4fac3f7536d8bd  gcc/tree-ssa-structalias.cc
  5fb55b888080a274f1a657904168a72f  gcc/tree-ssa-tail-merge.cc
--- 100765,100807 ----
  e36c0da1e5dc257d4ccff9c24043d7fc  gcc/tree-ssa-dce.h
  35f365067a15b900bdc007c8c4366fd1  gcc/tree-ssa-dom.cc
  aba207ac671bbe2380e556429ad21a00  gcc/tree-ssa-dom.h
! ac53f170ce2d238972f604eab2d06164  gcc/tree-ssa-dse.cc
  9fe4418350cac32811c9ed2ed8de371f  gcc/tree-ssa-dse.h
  8d97cf47138ffd7cd6f4c316e206b8f2  gcc/tree-ssa-forwprop.cc
  567c30a8d9160fdcd286536c8e4a553e  gcc/tree-ssa-ifcombine.cc
  e5c556ba07b04f0f9890c0d4618c716e  gcc/tree-ssa-live.cc
  d68a110616d98e6c023567d2239e4e13  gcc/tree-ssa-live.h
  286a1abc75a2657034c3ff16b07e46cb  gcc/tree-ssa-loop-ch.cc
! 43ebf36725b67c539b7efc1916793683  gcc/tree-ssa-loop-im.cc
  e167c39b8e8961b4e66068ab4f68bed2  gcc/tree-ssa-loop-ivcanon.cc
! b6d15e3409e7288f1d2564e38ca6c727  gcc/tree-ssa-loop-ivopts.cc
  370a3d6606f97b793ee8a94e17f8a1f5  gcc/tree-ssa-loop-ivopts.h
  aa498fcb0de83e00d2d79464ed4fa669  gcc/tree-ssa-loop-manip.cc
  c10dc1a11bed8461c36db2d370f534b6  gcc/tree-ssa-loop-manip.h
! 707b56ccbba46f1786c23392c1ca355a  gcc/tree-ssa-loop-niter.cc
  63e23177ceb0e06f07092e962fb6ec1e  gcc/tree-ssa-loop-niter.h
  29515e41d02e46edeeede5dbddecc177  gcc/tree-ssa-loop-prefetch.cc
! 2147068f6f7f5752d71fc7a68447adf4  gcc/tree-ssa-loop-split.cc
! d64db354e8b15e125e29a328c68f0612  gcc/tree-ssa-loop-unswitch.cc
  e2040b0e641b28b006e48fb2094500e2  gcc/tree-ssa-loop.cc
  943d41105325f8de1cdae2b4faf2dd0a  gcc/tree-ssa-loop.h
! 77da4133df9c8452382c403a490589aa  gcc/tree-ssa-math-opts.cc
  e9484a6f5b1f9056c6681cedce910ed4  gcc/tree-ssa-math-opts.h
  918abd54b699b48204a42158c4379381  gcc/tree-ssa-operands.cc
  0db421e827039fe3c4f796b4c7600c52  gcc/tree-ssa-operands.h
! f574f527c18df7c89c7ed22450b162e6  gcc/tree-ssa-phiopt.cc
  731542d52a45ac5f609554aee9faf6dd  gcc/tree-ssa-phiprop.cc
! 996d006bce38c28f8906e3d735d3c63f  gcc/tree-ssa-pre.cc
! fa89601dd394c5e02d327c2c2aebf80e  gcc/tree-ssa-propagate.cc
  658e45ca3c1c387fbd4e8bf835de1acd  gcc/tree-ssa-propagate.h
! 40fd91780563b5a4a2ae1b5868dd7f62  gcc/tree-ssa-reassoc.cc
  3d6728ab6aa97921854f86b5d2116c3d  gcc/tree-ssa-reassoc.h
! ddc1ad96c9216dbdf654ab58e74766a1  gcc/tree-ssa-sccvn.cc
  1c663c39e61b7e64cbea685db2598475  gcc/tree-ssa-sccvn.h
  0dd72fccd9280ac160f5ac770517ee10  gcc/tree-ssa-scopedtables.cc
  bdda02f8f5872266cc26122c45c7d248  gcc/tree-ssa-scopedtables.h
  3651b347d24df9f7410ea32fdf639a5d  gcc/tree-ssa-sink.cc
! 5b1cc016b1ac698e7576d0be0bf12637  gcc/tree-ssa-strlen.cc
  cae334e8d7f57adf439062af515c28ae  gcc/tree-ssa-strlen.h
  c447caeb8cd3ddc21a4fac3f7536d8bd  gcc/tree-ssa-structalias.cc
  5fb55b888080a274f1a657904168a72f  gcc/tree-ssa-tail-merge.cc
*************** ad22fabedd9c85512941d6537188dcdc  gcc/tr
*** 100573,100594 ****
  4e31a4ce5936cf46e49ed3fd6bc1c49d  gcc/tree-streamer.h
  55b4d99428849459155be80d762f91a7  gcc/tree-switch-conversion.cc
  7c63c2566792c75263e89aad9dbdd648  gcc/tree-switch-conversion.h
! a4918516d4e0d24a0f05be8cdde5d93f  gcc/tree-tailcall.cc
! c4f2e2a2cc275dcf93b14541755c8797  gcc/tree-vect-data-refs.cc
  8d1574c041db981b77499997880f38ff  gcc/tree-vect-generic.cc
  c45157ab0aed55ef9c76715a91e9ec64  gcc/tree-vect-loop-manip.cc
! a3f570d0bae1f5cb941213a48c4e8187  gcc/tree-vect-loop.cc
  fc473067a8cba47493488fd0e39e82e1  gcc/tree-vect-patterns.cc
  b2d8890f59e3b9eaa4fce183bf5f75be  gcc/tree-vect-slp-patterns.cc
! ae5fc3590da86a81b77b9bbbda17c40c  gcc/tree-vect-slp.cc
! 2578b9def1e89bc98e186ae47cdbfc3d  gcc/tree-vect-stmts.cc
  9ed16219bf6ab97b79539fb1bca89485  gcc/tree-vector-builder.cc
  672861a6f3b4ede253a47c708e10856d  gcc/tree-vector-builder.h
  ca7a666858d4e46dfb08e1e6932bb5f4  gcc/tree-vectorizer.cc
  273e2d8b40a81cd971fbfbf62d964bfa  gcc/tree-vectorizer.h
  bc72028fa27951bff9394d746764fc75  gcc/tree-vrp.cc
  1506b4121fe3a1f91b7dce7fd11903b1  gcc/tree-vrp.h
! cf071e7cb5ad16b6a14bede98d4c0aa5  gcc/tree.cc
  90cbee0521eed701cdda38cb80c79c9a  gcc/tree.def
  fe516d7c8d021430db52ce4066099c2c  gcc/tree.h
  1bc8e733e733c31e894ea8e9911dc5c0  gcc/treestruct.def
--- 100826,100847 ----
  4e31a4ce5936cf46e49ed3fd6bc1c49d  gcc/tree-streamer.h
  55b4d99428849459155be80d762f91a7  gcc/tree-switch-conversion.cc
  7c63c2566792c75263e89aad9dbdd648  gcc/tree-switch-conversion.h
! 904794c761da2ed5523744dae904475f  gcc/tree-tailcall.cc
! d255c49e1e03485afa4f96cbc7ef5d94  gcc/tree-vect-data-refs.cc
  8d1574c041db981b77499997880f38ff  gcc/tree-vect-generic.cc
  c45157ab0aed55ef9c76715a91e9ec64  gcc/tree-vect-loop-manip.cc
! df6079d25ce36b8c45d4d6e500c82ee8  gcc/tree-vect-loop.cc
  fc473067a8cba47493488fd0e39e82e1  gcc/tree-vect-patterns.cc
  b2d8890f59e3b9eaa4fce183bf5f75be  gcc/tree-vect-slp-patterns.cc
! e6cdb8f76b3c8afd7ea4644c56b6eb2c  gcc/tree-vect-slp.cc
! f29cc0aa032e863fc48da6b0d0c78fc5  gcc/tree-vect-stmts.cc
  9ed16219bf6ab97b79539fb1bca89485  gcc/tree-vector-builder.cc
  672861a6f3b4ede253a47c708e10856d  gcc/tree-vector-builder.h
  ca7a666858d4e46dfb08e1e6932bb5f4  gcc/tree-vectorizer.cc
  273e2d8b40a81cd971fbfbf62d964bfa  gcc/tree-vectorizer.h
  bc72028fa27951bff9394d746764fc75  gcc/tree-vrp.cc
  1506b4121fe3a1f91b7dce7fd11903b1  gcc/tree-vrp.h
! 393cfa89de675c007caa5a7dc83c7aa7  gcc/tree.cc
  90cbee0521eed701cdda38cb80c79c9a  gcc/tree.def
  fe516d7c8d021430db52ce4066099c2c  gcc/tree.h
  1bc8e733e733c31e894ea8e9911dc5c0  gcc/treestruct.def
*************** e6184a6abb9af9d66b052e39e9f5fa34  gcc/va
*** 100618,100624 ****
  503ab1c6d5150f14e3b6b5094d13d500  gcc/value-range.h
  e102b0f38013046bea428c1347577c4e  gcc/value-relation.cc
  4d6e7c80d58e26a86b0f46f81d4fe33c  gcc/value-relation.h
! e31285175438a68675780b419cf964ec  gcc/var-tracking.cc
  e8028efd8ee5b5ad4b762c6e09d663e9  gcc/varasm.cc
  a801df1efea35850028f5ec3cc36b36d  gcc/varasm.h
  dc419bc01226f41334020c39be67d5cb  gcc/varpool.cc
--- 100871,100877 ----
  503ab1c6d5150f14e3b6b5094d13d500  gcc/value-range.h
  e102b0f38013046bea428c1347577c4e  gcc/value-relation.cc
  4d6e7c80d58e26a86b0f46f81d4fe33c  gcc/value-relation.h
! 019f9d5d4d1290baaeaa22ed67c28905  gcc/var-tracking.cc
  e8028efd8ee5b5ad4b762c6e09d663e9  gcc/varasm.cc
  a801df1efea35850028f5ec3cc36b36d  gcc/varasm.h
  dc419bc01226f41334020c39be67d5cb  gcc/varpool.cc
*************** d0eb9eb0a1908e5adeca21c5333cca67  libcc1
*** 100936,100949 ****
  8e32b4f309146e8842db7a077d77be28  libcody/CMakeLists.txt
  c96a56ec7f0400e30e99a9aa445e0425  libcody/CODING.md
  b5243c8c76fc965a409394a30679e613  libcody/CONTRIB.md
! 1153674fa49f5d3c92f8e056b2c6acf6  libcody/ChangeLog
  86d3f3a95c324c9479bd8986968f4327  libcody/LICENSE
  ba83ee39cdf97b35fb51d4f39880aa89  libcody/Makefile.in
  ca1c6fe3df5427016005ce753c73d454  libcody/README.md
  99ad81d536fef63b80b7f776f0dec53c  libcody/buffer.cc
! 69dd1db758b0ea369d20d7331d889ef5  libcody/client.cc
  40072537e3589ff033129e9d5aa10660  libcody/cmake/libcody-config-ix.cmake
! 521e6cc4ebd40d0fbc4ad2fbd8c8063b  libcody/cody.hh
  b7630b2f7e3997152972e0d3f86af193  libcody/config.h.in
  a003d1057213ab79099f7bdbea631d9e  libcody/config.m4
  5ab03eb54e266c8023cdff6b6e06eabf  libcody/configure
--- 101189,101202 ----
  8e32b4f309146e8842db7a077d77be28  libcody/CMakeLists.txt
  c96a56ec7f0400e30e99a9aa445e0425  libcody/CODING.md
  b5243c8c76fc965a409394a30679e613  libcody/CONTRIB.md
! 4087301585de6d53672139fc3074610e  libcody/ChangeLog
  86d3f3a95c324c9479bd8986968f4327  libcody/LICENSE
  ba83ee39cdf97b35fb51d4f39880aa89  libcody/Makefile.in
  ca1c6fe3df5427016005ce753c73d454  libcody/README.md
  99ad81d536fef63b80b7f776f0dec53c  libcody/buffer.cc
! 6085d20f25e5c2f4809b76fc28261fb5  libcody/client.cc
  40072537e3589ff033129e9d5aa10660  libcody/cmake/libcody-config-ix.cmake
! fbd197f7a8c4380bf81aa2ca35950438  libcody/cody.hh
  b7630b2f7e3997152972e0d3f86af193  libcody/config.h.in
  a003d1057213ab79099f7bdbea631d9e  libcody/config.m4
  5ab03eb54e266c8023cdff6b6e06eabf  libcody/configure
*************** b7f8907c165e46ed56efaa23a2c2a570  libcod
*** 100954,100961 ****
  cffdeae41b78da05839b193e90188f55  libcody/netserver.cc
  6419dfc879387358e95288142e569914  libcody/packet.cc
  688ece05c8b9d378b3df186808162e76  libcody/resolver.cc
! b1f3850fc5ac62999d1e124aa6f76531  libcody/server.cc
! e55f48359f5ae93517911eb90e2a5c88  libcpp/ChangeLog
  2bd831b17997584e38305782cebe6948  libcpp/ChangeLog.jit
  c0a6ef2c7117069e80a305c7adaf1650  libcpp/Makefile.in
  9d15bb14e9ac1a74366e673ea260722e  libcpp/aclocal.m4
--- 101207,101214 ----
  cffdeae41b78da05839b193e90188f55  libcody/netserver.cc
  6419dfc879387358e95288142e569914  libcody/packet.cc
  688ece05c8b9d378b3df186808162e76  libcody/resolver.cc
! c94add0032978604acf65591bb86d2d6  libcody/server.cc
! e2b45f330d5877f5dda86b1e51db1b53  libcpp/ChangeLog
  2bd831b17997584e38305782cebe6948  libcpp/ChangeLog.jit
  c0a6ef2c7117069e80a305c7adaf1650  libcpp/Makefile.in
  9d15bb14e9ac1a74366e673ea260722e  libcpp/aclocal.m4
*************** ece481a9fcb69fc638d9146bd6088711  libcpp
*** 100966,100972 ****
  b441038d72bbfe5d18a0535fe9862846  libcpp/directives.cc
  3e4b49fd3a19b54de9921c80cfce0321  libcpp/errors.cc
  56c15f4e909e8d9891d42926a5c5479c  libcpp/expr.cc
! af5a15f7fb14aee661358d76d317e81e  libcpp/files.cc
  a91fac880a6d16a6c8bbbe6c25e2d8ac  libcpp/generated_cpp_wcwidth.h
  111fc904696e6294b16734dc26cf7cb1  libcpp/identifiers.cc
  4e693c1a191e0751af9c7bf5f3d68c4c  libcpp/include/cpplib.h
--- 101219,101225 ----
  b441038d72bbfe5d18a0535fe9862846  libcpp/directives.cc
  3e4b49fd3a19b54de9921c80cfce0321  libcpp/errors.cc
  56c15f4e909e8d9891d42926a5c5479c  libcpp/expr.cc
! 8cb48d45cb3cfe0f2725756e5fa933f7  libcpp/files.cc
  a91fac880a6d16a6c8bbbe6c25e2d8ac  libcpp/generated_cpp_wcwidth.h
  111fc904696e6294b16734dc26cf7cb1  libcpp/identifiers.cc
  4e693c1a191e0751af9c7bf5f3d68c4c  libcpp/include/cpplib.h
*************** a91fac880a6d16a6c8bbbe6c25e2d8ac  libcpp
*** 100975,101001 ****
  fdb620c15e6f934b317e2311ee26683e  libcpp/include/symtab.h
  72502fd7910efaafd6e57090d597fb21  libcpp/init.cc
  9b75a240393d9ded89f1f53f8bde743e  libcpp/internal.h
! f6d10ef1f47671a4482f3cf888ded146  libcpp/lex.cc
  9069946f6da4520e2be3263aba1fc15b  libcpp/line-map.cc
  46a07100f95f5e354c7e25cd19d26884  libcpp/location-example.txt
! ff413cbf5d61faa394a5ab2ef711257d  libcpp/macro.cc
  ab776697d1c83f80b45ce82ce889ce27  libcpp/makeucnid.cc
  8200bcdbc955945f7651606e2f838c81  libcpp/makeuname2c.cc
! 5db6ce86211354562c9ae6339d3716ea  libcpp/mkdeps.cc
  d127e0980eecd90c5bbb6bcad6d44d9d  libcpp/pch.cc
  a1a555ee8b54179bb8df913c9db9dbdb  libcpp/po/ChangeLog
! 768453cca0d8c0e2666a269e0aff862b  libcpp/po/be.gmo
  a2192a718d535196be1091cf9c6c2ff5  libcpp/po/be.po
! 6d54c123e102174620d1738492df73d5  libcpp/po/ca.gmo
  1261125217f973d8dbe7503c2d493333  libcpp/po/ca.po
  4677e4c7a90c44f214b5700f49c4ecb5  libcpp/po/cpplib.pot
  e5e81aa7ea0601dfcbd6a4d46269d803  libcpp/po/da.gmo
  498e008db7233fe5d4badac23691d05a  libcpp/po/da.po
  55c482205082e1dd4eb78fe792744dd9  libcpp/po/de.gmo
  0a71cb05a2c6b067c81d9b48505a8415  libcpp/po/de.po
! 9d8037a85a1603875c62ac38b52bfe1d  libcpp/po/el.gmo
  54f7163e6e1cf5141ab1b50160cfb01f  libcpp/po/el.po
! 464e7507ac048ac7cef20f8f26460f9d  libcpp/po/eo.gmo
  02c479377b7fd3ef073d8cf147d26497  libcpp/po/eo.po
  930ae5926382e8d66f8dad5200974f06  libcpp/po/es.gmo
  e11ae882708e0259be7885e42729f661  libcpp/po/es.po
--- 101228,101254 ----
  fdb620c15e6f934b317e2311ee26683e  libcpp/include/symtab.h
  72502fd7910efaafd6e57090d597fb21  libcpp/init.cc
  9b75a240393d9ded89f1f53f8bde743e  libcpp/internal.h
! f782b3f8758e5c71f8803e8fbf2f59a8  libcpp/lex.cc
  9069946f6da4520e2be3263aba1fc15b  libcpp/line-map.cc
  46a07100f95f5e354c7e25cd19d26884  libcpp/location-example.txt
! 21686ec48e8770e419ef2bf1920f4eb7  libcpp/macro.cc
  ab776697d1c83f80b45ce82ce889ce27  libcpp/makeucnid.cc
  8200bcdbc955945f7651606e2f838c81  libcpp/makeuname2c.cc
! 686ab269c27d4ae5268d12330ce28ee1  libcpp/mkdeps.cc
  d127e0980eecd90c5bbb6bcad6d44d9d  libcpp/pch.cc
  a1a555ee8b54179bb8df913c9db9dbdb  libcpp/po/ChangeLog
! f8911d7159af7a85a3b79336f7013869  libcpp/po/be.gmo
  a2192a718d535196be1091cf9c6c2ff5  libcpp/po/be.po
! d1e13011efdbba83c9dcdb3f83b57627  libcpp/po/ca.gmo
  1261125217f973d8dbe7503c2d493333  libcpp/po/ca.po
  4677e4c7a90c44f214b5700f49c4ecb5  libcpp/po/cpplib.pot
  e5e81aa7ea0601dfcbd6a4d46269d803  libcpp/po/da.gmo
  498e008db7233fe5d4badac23691d05a  libcpp/po/da.po
  55c482205082e1dd4eb78fe792744dd9  libcpp/po/de.gmo
  0a71cb05a2c6b067c81d9b48505a8415  libcpp/po/de.po
! 0c935c2376e3b53208861ce3f86449da  libcpp/po/el.gmo
  54f7163e6e1cf5141ab1b50160cfb01f  libcpp/po/el.po
! 645e3aaf003317859711e6d208dfb0d9  libcpp/po/eo.gmo
  02c479377b7fd3ef073d8cf147d26497  libcpp/po/eo.po
  930ae5926382e8d66f8dad5200974f06  libcpp/po/es.gmo
  e11ae882708e0259be7885e42729f661  libcpp/po/es.po
*************** dd372f52d2bf706aa6f9d5ad42e18fc0  libcpp
*** 101003,101009 ****
  8ffbecde56c2ca22c582f5776233eb67  libcpp/po/fi.po
  764a274c52e8eda81fcc2fae5745af29  libcpp/po/fr.gmo
  aafb3740cef0b63fcdc0b1f2b9d888f2  libcpp/po/fr.po
! 1f25accfdceffa4f72251252a589b349  libcpp/po/id.gmo
  7c78758201adf694f7c7b61f1ca134cd  libcpp/po/id.po
  d16137a8e7e85bccf28abe5c4ad0a81f  libcpp/po/ja.gmo
  b9580e522bd0c48fd49115fc19da95fc  libcpp/po/ja.po
--- 101256,101262 ----
  8ffbecde56c2ca22c582f5776233eb67  libcpp/po/fi.po
  764a274c52e8eda81fcc2fae5745af29  libcpp/po/fr.gmo
  aafb3740cef0b63fcdc0b1f2b9d888f2  libcpp/po/fr.po
! bca8399beb4ffac80a3f7f79c4f9bedd  libcpp/po/id.gmo
  7c78758201adf694f7c7b61f1ca134cd  libcpp/po/id.po
  d16137a8e7e85bccf28abe5c4ad0a81f  libcpp/po/ja.gmo
  b9580e522bd0c48fd49115fc19da95fc  libcpp/po/ja.po
*************** a105c5fcae34948c5756a38ba3a7043e  libcpp
*** 101027,101033 ****
  d39b27cd81483dbd14698d04380bf4cf  libcpp/po/uk.po
  d7329d40de2565a890e0ad0f2376dc20  libcpp/po/vi.gmo
  f7a922f11598d3db6f895bf5ac5ec22e  libcpp/po/vi.po
! 0bdf646da4277d7ba4dd64ab87e18b91  libcpp/po/zh_CN.gmo
  e265facd2ea64b5d6d3cc411cf6406a4  libcpp/po/zh_CN.po
  b375e96c670c3f0dd283014bbc260422  libcpp/po/zh_TW.gmo
  2b266205a8a5e33de493825f9f0704ad  libcpp/po/zh_TW.po
--- 101280,101286 ----
  d39b27cd81483dbd14698d04380bf4cf  libcpp/po/uk.po
  d7329d40de2565a890e0ad0f2376dc20  libcpp/po/vi.gmo
  f7a922f11598d3db6f895bf5ac5ec22e  libcpp/po/vi.po
! fe5f8904f4bb527ca46f37ebe93e93fb  libcpp/po/zh_CN.gmo
  e265facd2ea64b5d6d3cc411cf6406a4  libcpp/po/zh_CN.po
  b375e96c670c3f0dd283014bbc260422  libcpp/po/zh_TW.gmo
  2b266205a8a5e33de493825f9f0704ad  libcpp/po/zh_TW.po
*************** b65906677faeb64d5b833fe9c2963544  libffi
*** 101121,101127 ****
  dbd21d77c2acf20037c7e2e16de7a70c  libffi/configure.ac
  b2dbb88c38d08a37b89fc9ed08e79538  libffi/configure.host
  bad91ff01547ce79fe537211f4763ac0  libffi/doc/Makefile.am
! 20ebc69e7e1224fe9bf01a9f9b85e674  libffi/doc/libffi.info
  db28be3951c18d6db6e90f7e612bc67b  libffi/doc/libffi.texi
  0c1453cd8505c0c665c9194ef9d7f529  libffi/doc/version.texi
  ea125d6ff0b3d20372a1556f82ca6a05  libffi/fficonfig.h.in
--- 101374,101380 ----
  dbd21d77c2acf20037c7e2e16de7a70c  libffi/configure.ac
  b2dbb88c38d08a37b89fc9ed08e79538  libffi/configure.host
  bad91ff01547ce79fe537211f4763ac0  libffi/doc/Makefile.am
! c9f5f3eb2deb219f7587d6d862f6fd3e  libffi/doc/libffi.info
  db28be3951c18d6db6e90f7e612bc67b  libffi/doc/libffi.texi
  0c1453cd8505c0c665c9194ef9d7f529  libffi/doc/version.texi
  ea125d6ff0b3d20372a1556f82ca6a05  libffi/fficonfig.h.in
*************** d3a9f35aa3368d1b42549e9f573b7f19  libgcc
*** 101624,101630 ****
  660f8302d8422ba8cf16712c84a2bde0  libgcc/config/avr/lib1funcs.S
  622f81485f02d0eac2caaafa7d3a2fd1  libgcc/config/avr/lib2-object.mk
  624dc6fc660cb976b810335b3730ec59  libgcc/config/avr/lib2funcs.c
! 4241d61a93883e73a622f9f1ca7d1885  libgcc/config/avr/libf7/ChangeLog
  69b1e41bdec3b286de0827697e4b6acd  libgcc/config/avr/libf7/asm-defs.h
  434f68c401e93814081ae499ba72ffaf  libgcc/config/avr/libf7/f7-renames.h
  ec0383052925c464decb1bfdeaa5c95c  libgcc/config/avr/libf7/f7-wraps.h
--- 101877,101883 ----
  660f8302d8422ba8cf16712c84a2bde0  libgcc/config/avr/lib1funcs.S
  622f81485f02d0eac2caaafa7d3a2fd1  libgcc/config/avr/lib2-object.mk
  624dc6fc660cb976b810335b3730ec59  libgcc/config/avr/lib2funcs.c
! 6fc6177aface8980a51b37e6d6c5dea9  libgcc/config/avr/libf7/ChangeLog
  69b1e41bdec3b286de0827697e4b6acd  libgcc/config/avr/libf7/asm-defs.h
  434f68c401e93814081ae499ba72ffaf  libgcc/config/avr/libf7/f7-renames.h
  ec0383052925c464decb1bfdeaa5c95c  libgcc/config/avr/libf7/f7-wraps.h
*************** c0d4a5a9b2844505ec941ff60cae008f  libgcc
*** 101632,101638 ****
  8df828b3d2faf7a35d58170a9bafa333  libgcc/config/avr/libf7/f7wraps.sh
  929b89a7da7c3071631792a97bbda961  libgcc/config/avr/libf7/libf7-array.def
  5d9def53110ec07e8f29e66d593d758f  libgcc/config/avr/libf7/libf7-asm-object.mk
! 508c8be98af26874d031b6b77b89a761  libgcc/config/avr/libf7/libf7-asm.sx
  6b4886ae302fca1fa733831066c5c830  libgcc/config/avr/libf7/libf7-c-object.mk
  47dccabf16372b55fb7154bd70ce141f  libgcc/config/avr/libf7/libf7-common.mk
  abb1c90068e1f456d0639bcaa1cc4a94  libgcc/config/avr/libf7/libf7-const.def
--- 101885,101891 ----
  8df828b3d2faf7a35d58170a9bafa333  libgcc/config/avr/libf7/f7wraps.sh
  929b89a7da7c3071631792a97bbda961  libgcc/config/avr/libf7/libf7-array.def
  5d9def53110ec07e8f29e66d593d758f  libgcc/config/avr/libf7/libf7-asm-object.mk
! 5a70f9714e3446cee40e8e763c805c30  libgcc/config/avr/libf7/libf7-asm.sx
  6b4886ae302fca1fa733831066c5c830  libgcc/config/avr/libf7/libf7-c-object.mk
  47dccabf16372b55fb7154bd70ce141f  libgcc/config/avr/libf7/libf7-common.mk
  abb1c90068e1f456d0639bcaa1cc4a94  libgcc/config/avr/libf7/libf7-const.def
*************** b3c219e3fe7be0926b9c45521b07ca2a  libgcc
*** 101917,101923 ****
  d528fa6fb472c8cbd6b9df08a8d0a244  libgcc/config/ia64/vms-unwind.h
  f998607b97eeae6d2a3d1e10128c7cb1  libgcc/config/iq2000/lib2funcs.c
  102f7dad8ad6b54434a1b8313d1e42c4  libgcc/config/iq2000/t-iq2000
! a9c9cf1fb9ea1725d713e877f231161a  libgcc/config/libbid/ChangeLog
  e354955f92ec07ad37a62cd940b9001b  libgcc/config/libbid/_addsub_dd.c
  b89183791201be7d372019b758b007bb  libgcc/config/libbid/_addsub_sd.c
  a4d88b5941b22be078d1fb782e621350  libgcc/config/libbid/_addsub_td.c
--- 102170,102176 ----
  d528fa6fb472c8cbd6b9df08a8d0a244  libgcc/config/ia64/vms-unwind.h
  f998607b97eeae6d2a3d1e10128c7cb1  libgcc/config/iq2000/lib2funcs.c
  102f7dad8ad6b54434a1b8313d1e42c4  libgcc/config/iq2000/t-iq2000
! d68d6b53740580df064e15895e3f0eee  libgcc/config/libbid/ChangeLog
  e354955f92ec07ad37a62cd940b9001b  libgcc/config/libbid/_addsub_dd.c
  b89183791201be7d372019b758b007bb  libgcc/config/libbid/_addsub_sd.c
  a4d88b5941b22be078d1fb782e621350  libgcc/config/libbid/_addsub_td.c
*************** e3e86019491a40bd4f45424d7ce11037  libgo/
*** 109468,109481 ****
  c5574d106d35be5d94e80301b0855ada  libgo/testsuite/libgo-test-support.exp.in
  bf162aa572f7b96b25dbd2b027845d32  libgo/testsuite/libgo.testmain/testmain.exp
  cc9d2a0e34e31ba866a8caf9f46f48f3  libgomp/.gitattributes
! e8fec1070192f0170f59f649e41fa112  libgomp/ChangeLog
  0d55aa862aee66efdc5f8d62c94ff8fb  libgomp/ChangeLog.graphite
  8126886ecbd94666cc701e26bf9d7ec7  libgomp/Makefile.am
  54dac50e0dd75535eabeac324da5d027  libgomp/Makefile.in
  ddb4b1d0aa58f609604577990350df9e  libgomp/acc_prof.h
  d45f3b20f1be5d95a6c06fb81bedafe9  libgomp/acinclude.m4
  30a64ccfecfa60e8b5098e9fe26ea707  libgomp/aclocal.m4
! 8b170dafe28e7fbad76d127519542347  libgomp/affinity-fmt.c
  40719a43f32cd0bb4ae9c9e9199cf349  libgomp/affinity.c
  ebbb23a1a465e1ef266d0563f61aa38a  libgomp/alloc.c
  4e024af5cd8d0f98a80d35fc66016317  libgomp/allocator.c
--- 109721,109734 ----
  c5574d106d35be5d94e80301b0855ada  libgo/testsuite/libgo-test-support.exp.in
  bf162aa572f7b96b25dbd2b027845d32  libgo/testsuite/libgo.testmain/testmain.exp
  cc9d2a0e34e31ba866a8caf9f46f48f3  libgomp/.gitattributes
! 3c7065dc713371fdf256fb794d71d4fa  libgomp/ChangeLog
  0d55aa862aee66efdc5f8d62c94ff8fb  libgomp/ChangeLog.graphite
  8126886ecbd94666cc701e26bf9d7ec7  libgomp/Makefile.am
  54dac50e0dd75535eabeac324da5d027  libgomp/Makefile.in
  ddb4b1d0aa58f609604577990350df9e  libgomp/acc_prof.h
  d45f3b20f1be5d95a6c06fb81bedafe9  libgomp/acinclude.m4
  30a64ccfecfa60e8b5098e9fe26ea707  libgomp/aclocal.m4
! 881929df966f0741785d3359df7b1639  libgomp/affinity-fmt.c
  40719a43f32cd0bb4ae9c9e9199cf349  libgomp/affinity.c
  ebbb23a1a465e1ef266d0563f61aa38a  libgomp/alloc.c
  4e024af5cd8d0f98a80d35fc66016317  libgomp/allocator.c
*************** afec558551844f771b3aefe51131cecb  libgom
*** 109603,109609 ****
  b57a27985ae45d7a6dd20996bd6552bd  libgomp/libgomp-plugin.c
  68d34b49a2f832646487fdf463b7d497  libgomp/libgomp-plugin.h
  597562f7bd3816b527464f3a2d586fd7  libgomp/libgomp.h
! 63737f7c291511d3a2938ffa7551bf07  libgomp/libgomp.info
  816d5eb75954dad2681f7c36dd4b709c  libgomp/libgomp.map
  8b2aa50aecad82171348a6918309afd6  libgomp/libgomp.spec.in
  478cf48537e336fddf9de759cb858270  libgomp/libgomp.texi
--- 109856,109862 ----
  b57a27985ae45d7a6dd20996bd6552bd  libgomp/libgomp-plugin.c
  68d34b49a2f832646487fdf463b7d497  libgomp/libgomp-plugin.h
  597562f7bd3816b527464f3a2d586fd7  libgomp/libgomp.h
! f5a55e1336953873ce25732ac1af1075  libgomp/libgomp.info
  816d5eb75954dad2681f7c36dd4b709c  libgomp/libgomp.map
  8b2aa50aecad82171348a6918309afd6  libgomp/libgomp.spec.in
  478cf48537e336fddf9de759cb858270  libgomp/libgomp.texi
*************** b018601a4e35da4037b1e04dfdb00b98  libgom
*** 110850,110855 ****
--- 111103,111109 ----
  10f51539240fd456f44686f1368a9ebb  libgomp/testsuite/libgomp.fortran/pointer1.f90
  ea1e8a0a21d27e85d504f82d979196a3  libgomp/testsuite/libgomp.fortran/pointer2.f90
  5a38dd4751898fd9556aa9ed131fad76  libgomp/testsuite/libgomp.fortran/pr100981-2.f90
+ bd4d373b7453a268a0da695bf8bf8f52  libgomp/testsuite/libgomp.fortran/pr120286.f90
  1e7de6c9f1376e7662fc088ab6ec5e64  libgomp/testsuite/libgomp.fortran/pr25162.f
  150790c35955da1ca1b74284c2553f34  libgomp/testsuite/libgomp.fortran/pr25219.f90
  a83bd562c0d1b609f2a71de244b3a1a0  libgomp/testsuite/libgomp.fortran/pr27395-1.f90
*************** e8a3245c095430c8ef2413afe2ee4c48  libgom
*** 111728,111734 ****
  b409f1646a05495747142fadf3690e0c  libgomp/work.c
  99c2e5e712b990ee07be10f53e41f3fb  libiberty/.gitignore
  a916467b91076e631dd8edb7424769c7  libiberty/COPYING.LIB
! 346ccfeb3decb562b8aa99df50c6a9ce  libiberty/ChangeLog
  347c31392973de6a4872d540c1718dc1  libiberty/ChangeLog.jit
  fa93bac944903a228f11c248e20425c1  libiberty/Makefile.in
  8b93d0e0369daed24e2260ccfd102eb3  libiberty/README
--- 111982,111988 ----
  b409f1646a05495747142fadf3690e0c  libgomp/work.c
  99c2e5e712b990ee07be10f53e41f3fb  libiberty/.gitignore
  a916467b91076e631dd8edb7424769c7  libiberty/COPYING.LIB
! 0cb8ff7183a25edfefef0297b40b5941  libiberty/ChangeLog
  347c31392973de6a4872d540c1718dc1  libiberty/ChangeLog.jit
  fa93bac944903a228f11c248e20425c1  libiberty/Makefile.in
  8b93d0e0369daed24e2260ccfd102eb3  libiberty/README
*************** e7ff11c4ae7f1858d4cda405eadc20db  libibe
*** 111839,111845 ****
  f6dc20493a7999b1b5f8da12b01b3963  libiberty/simple-object-elf.c
  a60ce9470fc2a0d124b0931b858b3265  libiberty/simple-object-mach-o.c
  085b4b2948c994fb2b65894a77756e60  libiberty/simple-object-xcoff.c
! ace1a8709791ca05541a70dca2614837  libiberty/simple-object.c
  4863a11e04a2021af582edf86f156954  libiberty/simple-object.txh
  842fc5284a9f4ae10e07a32837db3a4e  libiberty/snprintf.c
  c74c68e14f2a52e22ec6f46986bf9735  libiberty/sort.c
--- 112093,112099 ----
  f6dc20493a7999b1b5f8da12b01b3963  libiberty/simple-object-elf.c
  a60ce9470fc2a0d124b0931b858b3265  libiberty/simple-object-mach-o.c
  085b4b2948c994fb2b65894a77756e60  libiberty/simple-object-xcoff.c
! 27931922a61f9a8e6d8a4b7e5dcbc592  libiberty/simple-object.c
  4863a11e04a2021af582edf86f156954  libiberty/simple-object.txh
  842fc5284a9f4ae10e07a32837db3a4e  libiberty/snprintf.c
  c74c68e14f2a52e22ec6f46986bf9735  libiberty/sort.c
*************** d3c04038acc1a42be3f3ead86551e0e1  libitm
*** 111959,111965 ****
  68025c5c42c305b8b7d2f4b08f7910f1  libitm/dispatch.h
  5da5b705758c793173f8bee058aee611  libitm/eh_cpp.cc
  8932f57735cf74b619c31912006a8974  libitm/libitm.h
! 8dd1a8aa042fa12b383946aa4ec1ec9c  libitm/libitm.info
  0c43820b921ecdbe9d98f068100e716a  libitm/libitm.map
  ea467d7117853d139bb288ab75261139  libitm/libitm.spec.in
  71434a0441eb61041d10daf560a5219d  libitm/libitm.texi
--- 112213,112219 ----
  68025c5c42c305b8b7d2f4b08f7910f1  libitm/dispatch.h
  5da5b705758c793173f8bee058aee611  libitm/eh_cpp.cc
  8932f57735cf74b619c31912006a8974  libitm/libitm.h
! 2ba1319cedb748e31bf418ac37aa7964  libitm/libitm.info
  0c43820b921ecdbe9d98f068100e716a  libitm/libitm.map
  ea467d7117853d139bb288ab75261139  libitm/libitm.spec.in
  71434a0441eb61041d10daf560a5219d  libitm/libitm.texi
*************** f73dc5b4bd6ccb056fedbcc20afbb42e  libobj
*** 112062,112068 ****
  4315de5775daa14dcb27acf8981e900b  libobjc/selector.c
  76858dbd60cea84725adf102503b0caf  libobjc/sendmsg.c
  07a2d7242871d2ccd937ab58211f029a  libobjc/thr.c
! 5c0fa592f36e58ad64d939cd646105b5  libphobos/ChangeLog
  94c5ad2e83438058486ba0c7c2fba0ab  libphobos/Makefile.am
  138fba343eb20a167ee2f5240bb53f27  libphobos/Makefile.in
  ee88c20a7744a2305503e1670f3b7889  libphobos/README.gcc
--- 112316,112322 ----
  4315de5775daa14dcb27acf8981e900b  libobjc/selector.c
  76858dbd60cea84725adf102503b0caf  libobjc/sendmsg.c
  07a2d7242871d2ccd937ab58211f029a  libobjc/thr.c
! eb0e0ea716dc95c755d646fee623ba38  libphobos/ChangeLog
  94c5ad2e83438058486ba0c7c2fba0ab  libphobos/Makefile.am
  138fba343eb20a167ee2f5240bb53f27  libphobos/Makefile.in
  ee88c20a7744a2305503e1670f3b7889  libphobos/README.gcc
*************** fbb3c30724cb241010afacb0505c53e7  libpho
*** 112071,112077 ****
  4923b1152206303a26c7dfb87f5de315  libphobos/config.h.in
  2a7da53393c7ac4e7d7b120f939f4abb  libphobos/configure
  c8692ecfddc51256a49f22096c2c2335  libphobos/configure.ac
! 5401a27c56bfc7c225627c0a4ce1d766  libphobos/configure.tgt
  04bef1902aef470aee5ea39c14c9529d  libphobos/d_rules.am
  e4224ccaecb14d942c71d31bef20d78c  libphobos/libdruntime/LICENSE.txt
  2d7446d51cf4738aad1c8ceb43174a72  libphobos/libdruntime/MERGE
--- 112325,112331 ----
  4923b1152206303a26c7dfb87f5de315  libphobos/config.h.in
  2a7da53393c7ac4e7d7b120f939f4abb  libphobos/configure
  c8692ecfddc51256a49f22096c2c2335  libphobos/configure.ac
! e2f9e6330c473720ab48f7187b6fa762  libphobos/configure.tgt
  04bef1902aef470aee5ea39c14c9529d  libphobos/d_rules.am
  e4224ccaecb14d942c71d31bef20d78c  libphobos/libdruntime/LICENSE.txt
  2d7446d51cf4738aad1c8ceb43174a72  libphobos/libdruntime/MERGE
*************** d9afbc1f1e04c7e461265ff9323cc6f4  libqua
*** 112921,112927 ****
  cf5a7864ff15ab4dd1604e0f6fe4e501  libquadmath/config.h.in
  035eb12396ed54eabc107d50a6093049  libquadmath/configure
  06e51379889d00dc467f2a2d496fa0a7  libquadmath/configure.ac
! 70f6009f2a5b2ed91b92a70a33e73c0c  libquadmath/libquadmath.info
  a385ffa67608997e98aa725913cf5169  libquadmath/libquadmath.texi
  77280bb7ee423875e03d9c0d34527df6  libquadmath/libtool-version
  452fee0ef153d65eb7413a5103c63a23  libquadmath/math/acoshq.c
--- 113175,113181 ----
  cf5a7864ff15ab4dd1604e0f6fe4e501  libquadmath/config.h.in
  035eb12396ed54eabc107d50a6093049  libquadmath/configure
  06e51379889d00dc467f2a2d496fa0a7  libquadmath/configure.ac
! dae221b865f73a5de8f57bd6ac2cbd5c  libquadmath/libquadmath.info
  a385ffa67608997e98aa725913cf5169  libquadmath/libquadmath.texi
  77280bb7ee423875e03d9c0d34527df6  libquadmath/libtool-version
  452fee0ef153d65eb7413a5103c63a23  libquadmath/math/acoshq.c
*************** e0bd9b8669e44ec6010f92da1d5188ad  libqua
*** 113053,113059 ****
  af84fa5118f4adec8393614994e1c4d6  libquadmath/strtod/strtoflt128.c
  d15a18f7c46ba2add6148edc5b7563c0  libquadmath/strtod/tens_in_limb.c
  12c73a846f7668d29de720bd79502bef  libquadmath/update-quadmath.py
! 4e8d2ba5eec5b7ed23ec618a764e4d83  libsanitizer/ChangeLog
  63916ba64a3cfa7ce2809fb46ab38597  libsanitizer/HOWTO_MERGE
  0249c37748936faf5b1efd5789587909  libsanitizer/LICENSE.TXT
  29e193ebd43391db91cd7be26d8cd169  libsanitizer/LOCAL_PATCHES
--- 113307,113313 ----
  af84fa5118f4adec8393614994e1c4d6  libquadmath/strtod/strtoflt128.c
  d15a18f7c46ba2add6148edc5b7563c0  libquadmath/strtod/tens_in_limb.c
  12c73a846f7668d29de720bd79502bef  libquadmath/update-quadmath.py
! 823d48330c51d4c74c3681753eec31b0  libsanitizer/ChangeLog
  63916ba64a3cfa7ce2809fb46ab38597  libsanitizer/HOWTO_MERGE
  0249c37748936faf5b1efd5789587909  libsanitizer/LICENSE.TXT
  29e193ebd43391db91cd7be26d8cd169  libsanitizer/LOCAL_PATCHES
*************** a32b38d2eae806bfe95f3e089a711f7a  libsan
*** 113273,113279 ****
  6e3ba9b2a5302ee4e0b833e4cc174db2  libsanitizer/sanitizer_common/sanitizer_common.h
  820bd5f9d0b610aeee0ddc864394a83f  libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
  873ecc8932cb8410c4e2b06ea4fd99ff  libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc
! aa961fb0d47d9369601c5aa4bd24ea02  libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc
  c664d5fb1514c978d28a6a62b2040b53  libsanitizer/sanitizer_common/sanitizer_common_interceptors_netbsd_compat.inc
  fda3dee294d9edce69f269af077bbd80  libsanitizer/sanitizer_common/sanitizer_common_interceptors_vfork_aarch64.inc.S
  b4b4ed1f1a36cce44031fd0b4a1a141f  libsanitizer/sanitizer_common/sanitizer_common_interceptors_vfork_arm.inc.S
--- 113527,113533 ----
  6e3ba9b2a5302ee4e0b833e4cc174db2  libsanitizer/sanitizer_common/sanitizer_common.h
  820bd5f9d0b610aeee0ddc864394a83f  libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc
  873ecc8932cb8410c4e2b06ea4fd99ff  libsanitizer/sanitizer_common/sanitizer_common_interceptors_format.inc
! f7ca723d15d4d448c700727f05b86537  libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc
  c664d5fb1514c978d28a6a62b2040b53  libsanitizer/sanitizer_common/sanitizer_common_interceptors_netbsd_compat.inc
  fda3dee294d9edce69f269af077bbd80  libsanitizer/sanitizer_common/sanitizer_common_interceptors_vfork_aarch64.inc.S
  b4b4ed1f1a36cce44031fd0b4a1a141f  libsanitizer/sanitizer_common/sanitizer_common_interceptors_vfork_arm.inc.S
*************** b582d1c8ad1dfab45211cbb7c25cf5f6  libsan
*** 113350,113357 ****
  363c19d7d7061beabfcc5393b85ef479  libsanitizer/sanitizer_common/sanitizer_platform_limits_netbsd.h
  d41d8cd98f00b204e9800998ecf8427e  libsanitizer/sanitizer_common/sanitizer_platform_limits_openbsd.cpp
  d41d8cd98f00b204e9800998ecf8427e  libsanitizer/sanitizer_common/sanitizer_platform_limits_openbsd.h
! f59aa2137df87f1dd3e7564e8ca41b55  libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
! ce8a0aaa4129f14a6b70fe701a4aee99  libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
  711b54008ada7faff939a95e325b185b  libsanitizer/sanitizer_common/sanitizer_platform_limits_solaris.cpp
  ab1ad414331f77e459da9a32b756cbac  libsanitizer/sanitizer_common/sanitizer_platform_limits_solaris.h
  1019f8f3de270256a0b3ed857645dec8  libsanitizer/sanitizer_common/sanitizer_posix.cpp
--- 113604,113611 ----
  363c19d7d7061beabfcc5393b85ef479  libsanitizer/sanitizer_common/sanitizer_platform_limits_netbsd.h
  d41d8cd98f00b204e9800998ecf8427e  libsanitizer/sanitizer_common/sanitizer_platform_limits_openbsd.cpp
  d41d8cd98f00b204e9800998ecf8427e  libsanitizer/sanitizer_common/sanitizer_platform_limits_openbsd.h
! 073e50e3d8b36def74cb6ff7942abd46  libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
! 40a8327e0c94fa88314fad7bb6d05547  libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
  711b54008ada7faff939a95e325b185b  libsanitizer/sanitizer_common/sanitizer_platform_limits_solaris.cpp
  ab1ad414331f77e459da9a32b756cbac  libsanitizer/sanitizer_common/sanitizer_platform_limits_solaris.h
  1019f8f3de270256a0b3ed857645dec8  libsanitizer/sanitizer_common/sanitizer_posix.cpp
*************** fcdf88c4922b4bf531859f5e19f37f19  libsan
*** 113498,113504 ****
  339793c91cce47c39da05aab388a1d91  libsanitizer/tsan/tsan_symbolize.h
  ac99e2a1604f10691ceb3d4a4600d0ed  libsanitizer/tsan/tsan_sync.cpp
  6f7b135e2c27d09f0db426a5f7427966  libsanitizer/tsan/tsan_sync.h
! 8ca6a9e7f5c97b2069ca2eb034d7b61f  libsanitizer/tsan/tsan_trace.h
  7043f9d2d6d55a4a9dad3179e81ac578  libsanitizer/tsan/tsan_vector_clock.cpp
  5f66ec32201aa975081f4ec4905d1343  libsanitizer/tsan/tsan_vector_clock.h
  f6d1a5a4cab859262269889366adae69  libsanitizer/ubsan/Makefile.am
--- 113752,113758 ----
  339793c91cce47c39da05aab388a1d91  libsanitizer/tsan/tsan_symbolize.h
  ac99e2a1604f10691ceb3d4a4600d0ed  libsanitizer/tsan/tsan_sync.cpp
  6f7b135e2c27d09f0db426a5f7427966  libsanitizer/tsan/tsan_sync.h
! f1ca5453760bb7bd86e35914eb6a4cc2  libsanitizer/tsan/tsan_trace.h
  7043f9d2d6d55a4a9dad3179e81ac578  libsanitizer/tsan/tsan_vector_clock.cpp
  5f66ec32201aa975081f4ec4905d1343  libsanitizer/tsan/tsan_vector_clock.h
  f6d1a5a4cab859262269889366adae69  libsanitizer/ubsan/Makefile.am
*************** c265574887f4390ecccd1073ee5c0190  libssp
*** 113563,113569 ****
  02470b541ab713bd1bfb8e6787e65f2c  libssp/strncpy-chk.c
  8a7a0719ef45cb3ae0041192eac8d550  libssp/vsnprintf-chk.c
  d662ba7536e1bd06226d47b1a7f1f4e2  libssp/vsprintf-chk.c
! ae2bd6cb395bb4775257b1550b43a11d  libstdc++-v3/ChangeLog
  7aa6c40440a44fcf5ec94c066160c2f8  libstdc++-v3/ChangeLog-1998
  7aff86600b6a1ed3fa87305075a92db0  libstdc++-v3/ChangeLog-1999
  a6f28e8fc9bb07696a9e068b439a3a87  libstdc++-v3/ChangeLog-2000
--- 113817,113823 ----
  02470b541ab713bd1bfb8e6787e65f2c  libssp/strncpy-chk.c
  8a7a0719ef45cb3ae0041192eac8d550  libssp/vsnprintf-chk.c
  d662ba7536e1bd06226d47b1a7f1f4e2  libssp/vsprintf-chk.c
! ddd8fdc83349cb3342615538876b8d74  libstdc++-v3/ChangeLog
  7aa6c40440a44fcf5ec94c066160c2f8  libstdc++-v3/ChangeLog-1998
  7aff86600b6a1ed3fa87305075a92db0  libstdc++-v3/ChangeLog-1999
  a6f28e8fc9bb07696a9e068b439a3a87  libstdc++-v3/ChangeLog-2000
*************** adcea90b4e1088e2e86276002047930d  libstd
*** 113655,113667 ****
  b9781348efbb56e34bbcbae0c133c4c8  libstdc++-v3/config/cpu/sh/atomicity.h
  f0d558aa9a20f3e1cb155d4bf7338f1a  libstdc++-v3/config/cpu/sparc/atomic_word.h
  9cb5258fc5ee28e47bb10eb3a5b9993e  libstdc++-v3/config/cpu/sparc/atomicity.h
! 859dc35b61c4326aa5dc08ee1a73e78a  libstdc++-v3/config/io/basic_file_stdio.cc
  667751272c2634e9ca84aafbf5899453  libstdc++-v3/config/io/basic_file_stdio.h
  a0d5f7157fc4b3fc206d8bf4497dd924  libstdc++-v3/config/io/c_io_stdio.h
  8d8376bd496628e6daff6e43c6a00f43  libstdc++-v3/config/locale/darwin/ctype_members.cc
  f093a64957701e345212de01e53fea28  libstdc++-v3/config/locale/dragonfly/c_locale.cc
  214f9d51d4d1ecb13b2b070b96648e19  libstdc++-v3/config/locale/dragonfly/c_locale.h
! 99930a8b6fc64a818f7ff183ec3b26dc  libstdc++-v3/config/locale/dragonfly/codecvt_members.cc
  4a5699f8b5de77b6cb0185f837bac4f0  libstdc++-v3/config/locale/dragonfly/collate_members.cc
  a1463943efae57b930a3a778e2596408  libstdc++-v3/config/locale/dragonfly/ctype_members.cc
  e82371f75a7f131a45c51112632b00b4  libstdc++-v3/config/locale/dragonfly/monetary_members.cc
--- 113909,113921 ----
  b9781348efbb56e34bbcbae0c133c4c8  libstdc++-v3/config/cpu/sh/atomicity.h
  f0d558aa9a20f3e1cb155d4bf7338f1a  libstdc++-v3/config/cpu/sparc/atomic_word.h
  9cb5258fc5ee28e47bb10eb3a5b9993e  libstdc++-v3/config/cpu/sparc/atomicity.h
! 9b0c42384ee92fc019cfe3a934380c43  libstdc++-v3/config/io/basic_file_stdio.cc
  667751272c2634e9ca84aafbf5899453  libstdc++-v3/config/io/basic_file_stdio.h
  a0d5f7157fc4b3fc206d8bf4497dd924  libstdc++-v3/config/io/c_io_stdio.h
  8d8376bd496628e6daff6e43c6a00f43  libstdc++-v3/config/locale/darwin/ctype_members.cc
  f093a64957701e345212de01e53fea28  libstdc++-v3/config/locale/dragonfly/c_locale.cc
  214f9d51d4d1ecb13b2b070b96648e19  libstdc++-v3/config/locale/dragonfly/c_locale.h
! 140189cc17f59735139e8c963b8e00df  libstdc++-v3/config/locale/dragonfly/codecvt_members.cc
  4a5699f8b5de77b6cb0185f837bac4f0  libstdc++-v3/config/locale/dragonfly/collate_members.cc
  a1463943efae57b930a3a778e2596408  libstdc++-v3/config/locale/dragonfly/ctype_members.cc
  e82371f75a7f131a45c51112632b00b4  libstdc++-v3/config/locale/dragonfly/monetary_members.cc
*************** b6b915f387842bca4ee5e8a11b0385f8  libstd
*** 113683,113689 ****
  942cafcd7b13ed006a05b9b3cba3416b  libstdc++-v3/config/locale/gnu/c++locale_internal.h
  adc14174bf7d5246d2139f20e418378e  libstdc++-v3/config/locale/gnu/c_locale.cc
  b61cea41d386450b82fdf27639b4874d  libstdc++-v3/config/locale/gnu/c_locale.h
! a78cc28e1751d8d73b9efa685484a413  libstdc++-v3/config/locale/gnu/codecvt_members.cc
  1395acff5a39083f5231094df4befc63  libstdc++-v3/config/locale/gnu/collate_members.cc
  de202fda56a19eec7e45a1e10aed9752  libstdc++-v3/config/locale/gnu/ctype_members.cc
  327af32905ecdcce8bdaadc497871495  libstdc++-v3/config/locale/gnu/messages_members.cc
--- 113937,113943 ----
  942cafcd7b13ed006a05b9b3cba3416b  libstdc++-v3/config/locale/gnu/c++locale_internal.h
  adc14174bf7d5246d2139f20e418378e  libstdc++-v3/config/locale/gnu/c_locale.cc
  b61cea41d386450b82fdf27639b4874d  libstdc++-v3/config/locale/gnu/c_locale.h
! 9175bcd273d2a7b21d15abe75a7a095c  libstdc++-v3/config/locale/gnu/codecvt_members.cc
  1395acff5a39083f5231094df4befc63  libstdc++-v3/config/locale/gnu/collate_members.cc
  de202fda56a19eec7e45a1e10aed9752  libstdc++-v3/config/locale/gnu/ctype_members.cc
  327af32905ecdcce8bdaadc497871495  libstdc++-v3/config/locale/gnu/messages_members.cc
*************** bf556dc6840d7dadbb3b6275d1a0246f  libstd
*** 113710,113716 ****
  f0f692d4993106f00dc73fffe8481a5a  libstdc++-v3/config/os/bsd/darwin/ctype_base.h
  bff3f0f5f7fae007b47106e4cd2aedd8  libstdc++-v3/config/os/bsd/darwin/ctype_configure_char.cc
  b3726c7385b8a8c7b6ae336f5eef90a8  libstdc++-v3/config/os/bsd/darwin/ctype_inline.h
! 36e4c8ce8504c11324759a1cdc69c4b2  libstdc++-v3/config/os/bsd/darwin/os_defines.h
  9e91dfcb11e4c78744df0e1e0cf69b5b  libstdc++-v3/config/os/bsd/darwin/ppc-extra.ver
  d05e9e7b17b7b8b3d1a862ceda60c106  libstdc++-v3/config/os/bsd/dragonfly/ctype_base.h
  7e7ffc1a0dbe201efefbdbc801c4cfaf  libstdc++-v3/config/os/bsd/dragonfly/ctype_configure_char.cc
--- 113964,113970 ----
  f0f692d4993106f00dc73fffe8481a5a  libstdc++-v3/config/os/bsd/darwin/ctype_base.h
  bff3f0f5f7fae007b47106e4cd2aedd8  libstdc++-v3/config/os/bsd/darwin/ctype_configure_char.cc
  b3726c7385b8a8c7b6ae336f5eef90a8  libstdc++-v3/config/os/bsd/darwin/ctype_inline.h
! f34d1793fa7dc794c23c01b6e9d614f6  libstdc++-v3/config/os/bsd/darwin/os_defines.h
  9e91dfcb11e4c78744df0e1e0cf69b5b  libstdc++-v3/config/os/bsd/darwin/ppc-extra.ver
  d05e9e7b17b7b8b3d1a862ceda60c106  libstdc++-v3/config/os/bsd/dragonfly/ctype_base.h
  7e7ffc1a0dbe201efefbdbc801c4cfaf  libstdc++-v3/config/os/bsd/dragonfly/ctype_configure_char.cc
*************** d05e9e7b17b7b8b3d1a862ceda60c106  libstd
*** 113719,113725 ****
  70b706514677753f53f175644c6d1c3c  libstdc++-v3/config/os/bsd/freebsd/ctype_base.h
  7e7ffc1a0dbe201efefbdbc801c4cfaf  libstdc++-v3/config/os/bsd/freebsd/ctype_configure_char.cc
  b3726c7385b8a8c7b6ae336f5eef90a8  libstdc++-v3/config/os/bsd/freebsd/ctype_inline.h
! efcb0a7d47a741c72b91843ad95c5242  libstdc++-v3/config/os/bsd/freebsd/os_defines.h
  88f0caf3f3b225d015f8768e496ebd4a  libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
  37c0176086b51b82cdf41777685ce449  libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
  b0500c41fc08ce01a06b84e41fa43c31  libstdc++-v3/config/os/bsd/netbsd/ctype_inline.h
--- 113973,113979 ----
  70b706514677753f53f175644c6d1c3c  libstdc++-v3/config/os/bsd/freebsd/ctype_base.h
  7e7ffc1a0dbe201efefbdbc801c4cfaf  libstdc++-v3/config/os/bsd/freebsd/ctype_configure_char.cc
  b3726c7385b8a8c7b6ae336f5eef90a8  libstdc++-v3/config/os/bsd/freebsd/ctype_inline.h
! 0547f3b8c175ad170df00e0342a1982a  libstdc++-v3/config/os/bsd/freebsd/os_defines.h
  88f0caf3f3b225d015f8768e496ebd4a  libstdc++-v3/config/os/bsd/netbsd/ctype_base.h
  37c0176086b51b82cdf41777685ce449  libstdc++-v3/config/os/bsd/netbsd/ctype_configure_char.cc
  b0500c41fc08ce01a06b84e41fa43c31  libstdc++-v3/config/os/bsd/netbsd/ctype_inline.h
*************** aedbb1de1dc942434f2d23b8971c0b6f  libstd
*** 113791,113797 ****
  f2586e13ea278d1f5cb3ffccc9efc110  libstdc++-v3/doc/Makefile.in
  3f7ff07f68cc7610addc1921bc125548  libstdc++-v3/doc/doxygen/Intro.3
  8cd134670f5092cbc6540d6789acc229  libstdc++-v3/doc/doxygen/doxygroups.cc
! 520db39aef0e2a59418132af88b897ed  libstdc++-v3/doc/doxygen/mainpage.html
  f298475c719652bf6b563563d90f327a  libstdc++-v3/doc/doxygen/stdheader.cc
  1273764cd133c402d2d3f22cf2913af5  libstdc++-v3/doc/doxygen/tables.html
  4e2062754819106c107a975574733a1a  libstdc++-v3/doc/doxygen/user.cfg.in
--- 114045,114051 ----
  f2586e13ea278d1f5cb3ffccc9efc110  libstdc++-v3/doc/Makefile.in
  3f7ff07f68cc7610addc1921bc125548  libstdc++-v3/doc/doxygen/Intro.3
  8cd134670f5092cbc6540d6789acc229  libstdc++-v3/doc/doxygen/doxygroups.cc
! 0afaede288e1533644cb1445cf4ff813  libstdc++-v3/doc/doxygen/mainpage.html
  f298475c719652bf6b563563d90f327a  libstdc++-v3/doc/doxygen/stdheader.cc
  1273764cd133c402d2d3f22cf2913af5  libstdc++-v3/doc/doxygen/tables.html
  4e2062754819106c107a975574733a1a  libstdc++-v3/doc/doxygen/user.cfg.in
*************** f298475c719652bf6b563563d90f327a  libstd
*** 113799,113805 ****
  c68ff21babfa14f20b98e36a2c808418  libstdc++-v3/doc/html/api.html
  08920438eea18325b4bfdf979379ff66  libstdc++-v3/doc/html/bk02.html
  47886ba7da131bf3cbf81a27cada5f6f  libstdc++-v3/doc/html/bk03.html
! f03dd1c38b579d5d224000379ab03739  libstdc++-v3/doc/html/faq.html
  1ae70f0bf94464b036515d333fff8ab2  libstdc++-v3/doc/html/images/confdeps.png
  d7f63b43e9f4c39cf71de7585de522ee  libstdc++-v3/doc/html/images/pbds_balls_and_bins.png
  22eedc841676a98f8ae8b95131ac4d7e  libstdc++-v3/doc/html/images/pbds_binary_priority_queue_int_push.png
--- 114053,114059 ----
  c68ff21babfa14f20b98e36a2c808418  libstdc++-v3/doc/html/api.html
  08920438eea18325b4bfdf979379ff66  libstdc++-v3/doc/html/bk02.html
  47886ba7da131bf3cbf81a27cada5f6f  libstdc++-v3/doc/html/bk03.html
! 72f7069a39b62d155c8ae874835a5555  libstdc++-v3/doc/html/faq.html
  1ae70f0bf94464b036515d333fff8ab2  libstdc++-v3/doc/html/images/confdeps.png
  d7f63b43e9f4c39cf71de7585de522ee  libstdc++-v3/doc/html/images/pbds_balls_and_bins.png
  22eedc841676a98f8ae8b95131ac4d7e  libstdc++-v3/doc/html/images/pbds_binary_priority_queue_int_push.png
*************** c60c6ae778d5dedae24ac21abf948bdb  libstd
*** 113897,113904 ****
  6095fbb12cc581b2614870b42ad0e8b0  libstdc++-v3/doc/html/manual/bugs.html
  cc3700f2fde50987f186f23abf98a7b1  libstdc++-v3/doc/html/manual/concept_checking.html
  f3a54a6315d716742603d33f454f2c19  libstdc++-v3/doc/html/manual/concurrency.html
! e4aaeef0b98cb4c49ee46b83c543ca34  libstdc++-v3/doc/html/manual/configure.html
! af4e79b9e55fd023eeb0459df34a4a82  libstdc++-v3/doc/html/manual/containers.html
  c7e40c1085e414b3b4d5896db4013205  libstdc++-v3/doc/html/manual/containers_and_c.html
  2b78750eb3e29b38e12b7ed1ba8ee8b8  libstdc++-v3/doc/html/manual/debug.html
  1bd34529d162b6f3a08d5f2ea4943c6a  libstdc++-v3/doc/html/manual/debug_mode.html
--- 114151,114158 ----
  6095fbb12cc581b2614870b42ad0e8b0  libstdc++-v3/doc/html/manual/bugs.html
  cc3700f2fde50987f186f23abf98a7b1  libstdc++-v3/doc/html/manual/concept_checking.html
  f3a54a6315d716742603d33f454f2c19  libstdc++-v3/doc/html/manual/concurrency.html
! 5947575728a455bd84faee21330f2ab0  libstdc++-v3/doc/html/manual/configure.html
! 5328918ec42768cddb06c3e97ef4530c  libstdc++-v3/doc/html/manual/containers.html
  c7e40c1085e414b3b4d5896db4013205  libstdc++-v3/doc/html/manual/containers_and_c.html
  2b78750eb3e29b38e12b7ed1ba8ee8b8  libstdc++-v3/doc/html/manual/debug.html
  1bd34529d162b6f3a08d5f2ea4943c6a  libstdc++-v3/doc/html/manual/debug_mode.html
*************** afcc2751dae09e088abc1e3175cb94cc  libstd
*** 113918,113926 ****
  a9a11843531e8f06066ca107b8c76ceb  libstdc++-v3/doc/html/manual/ext_demangling.html
  05003e71d54cfdfd4c8291489f8ffa07  libstdc++-v3/doc/html/manual/ext_io.html
  44f8ef8b093904d418755d0e32d700b7  libstdc++-v3/doc/html/manual/ext_iterators.html
! 8f3bd86e04d263ad87cc258c289aae6d  libstdc++-v3/doc/html/manual/ext_numerics.html
  6d380acac52eb8c888a54068e44b16ac  libstdc++-v3/doc/html/manual/ext_preface.html
! 5632eb8ef681cd35b41be7eb7a3d7a98  libstdc++-v3/doc/html/manual/ext_sgi.html
  9b34310c7cb7faa4373ee6683678c457  libstdc++-v3/doc/html/manual/ext_utilities.html
  9e255046a8ef2903114374ed06403045  libstdc++-v3/doc/html/manual/extensions.html
  76cac108e21e304b7607196fb5245e00  libstdc++-v3/doc/html/manual/facets.html
--- 114172,114180 ----
  a9a11843531e8f06066ca107b8c76ceb  libstdc++-v3/doc/html/manual/ext_demangling.html
  05003e71d54cfdfd4c8291489f8ffa07  libstdc++-v3/doc/html/manual/ext_io.html
  44f8ef8b093904d418755d0e32d700b7  libstdc++-v3/doc/html/manual/ext_iterators.html
! ffd5e74a40bbf6623b8ccf687eb584d8  libstdc++-v3/doc/html/manual/ext_numerics.html
  6d380acac52eb8c888a54068e44b16ac  libstdc++-v3/doc/html/manual/ext_preface.html
! 6889f243ab6934ae5f80ea7fa9c69dbf  libstdc++-v3/doc/html/manual/ext_sgi.html
  9b34310c7cb7faa4373ee6683678c457  libstdc++-v3/doc/html/manual/ext_utilities.html
  9e255046a8ef2903114374ed06403045  libstdc++-v3/doc/html/manual/extensions.html
  76cac108e21e304b7607196fb5245e00  libstdc++-v3/doc/html/manual/facets.html
*************** ffceba0f3c20f451f9753c101c0fa634  libstd
*** 113965,113971 ****
  01c6fb78afa342def6da44376b90a890  libstdc++-v3/doc/html/manual/source_code_style.html
  f875f3f4cddfe4fee6aff2308ccb4563  libstdc++-v3/doc/html/manual/source_design_notes.html
  391422dd4f4cdbd4d764a952a0f345e6  libstdc++-v3/doc/html/manual/source_organization.html
! 7810b58abc912971d66aae870302da12  libstdc++-v3/doc/html/manual/status.html
  ea0c531c09fa230f346f8ba700961e4a  libstdc++-v3/doc/html/manual/std_contents.html
  dbb5f81a9e8864374fbb835eaa4e8b0d  libstdc++-v3/doc/html/manual/streambufs.html
  99d2fb8d1299bbdeefb3417992bcd322  libstdc++-v3/doc/html/manual/strings.html
--- 114219,114225 ----
  01c6fb78afa342def6da44376b90a890  libstdc++-v3/doc/html/manual/source_code_style.html
  f875f3f4cddfe4fee6aff2308ccb4563  libstdc++-v3/doc/html/manual/source_design_notes.html
  391422dd4f4cdbd4d764a952a0f345e6  libstdc++-v3/doc/html/manual/source_organization.html
! 7692e1c0580d3d1a8eae4827d45b63b8  libstdc++-v3/doc/html/manual/status.html
  ea0c531c09fa230f346f8ba700961e4a  libstdc++-v3/doc/html/manual/std_contents.html
  dbb5f81a9e8864374fbb835eaa4e8b0d  libstdc++-v3/doc/html/manual/streambufs.html
  99d2fb8d1299bbdeefb3417992bcd322  libstdc++-v3/doc/html/manual/strings.html
*************** f68eb6ec77205287aeb6b8d394f6f320  libstd
*** 113976,113995 ****
  c39b927efcec5ac84139c1490c8ef320  libstdc++-v3/doc/html/manual/traits.html
  530b96535baacfe35df2e65f9dfe7efc  libstdc++-v3/doc/html/manual/unordered_associative.html
  dd7e5ec8a331bbd3f15aa29f3b191afb  libstdc++-v3/doc/html/manual/using.html
! ea78c1e7e98f6458923056e2b869969d  libstdc++-v3/doc/html/manual/using_concurrency.html
  f8898e59cc7155a01a17f15a3b853c30  libstdc++-v3/doc/html/manual/using_dual_abi.html
  a372b01a93ca1beeb843a1440bd25cdd  libstdc++-v3/doc/html/manual/using_dynamic_or_shared.html
  09eeb2fa79fb240e032461adcbe2cb4a  libstdc++-v3/doc/html/manual/using_exceptions.html
  8fc6625206a4feba33ced5fa38ab3af8  libstdc++-v3/doc/html/manual/using_headers.html
  c1e8d8c0d84363807d41edeb82e9dbfc  libstdc++-v3/doc/html/manual/using_macros.html
  ccc3b1a320ccc49a977c80546610195b  libstdc++-v3/doc/html/manual/using_namespaces.html
! d881fcffb799c09a28d8174ccb1326a2  libstdc++-v3/doc/html/manual/utilities.html
  ccbc0492a648982f2dc225595bdbc567  libstdc++-v3/doc/xml/api.xml
  8059eb81f5540dc3ae678ac09e1f3159  libstdc++-v3/doc/xml/authors.xml
  5906074c27c57c65b220c35bbcb2c5ec  libstdc++-v3/doc/xml/book.txml
  44d3a92b83abfb18efac80519c79b44c  libstdc++-v3/doc/xml/chapter.txml
  011b8e6a5442e4dc08f02e7295b644a3  libstdc++-v3/doc/xml/class.txml
! cd3e86b2f1ae5be8167ef6f329aad872  libstdc++-v3/doc/xml/faq.xml
  ea77580f7e81e2c49aea3f425c01ee2b  libstdc++-v3/doc/xml/gnu/fdl-1.3.xml
  56bb32e9ab9358834c5f8eca2cd0e969  libstdc++-v3/doc/xml/gnu/gpl-3.0.xml
  18a6390297702ec8fd75cbcc525d2005  libstdc++-v3/doc/xml/images/confdeps.dot
--- 114230,114249 ----
  c39b927efcec5ac84139c1490c8ef320  libstdc++-v3/doc/html/manual/traits.html
  530b96535baacfe35df2e65f9dfe7efc  libstdc++-v3/doc/html/manual/unordered_associative.html
  dd7e5ec8a331bbd3f15aa29f3b191afb  libstdc++-v3/doc/html/manual/using.html
! 08121b7fa3846487302afa82afc9d571  libstdc++-v3/doc/html/manual/using_concurrency.html
  f8898e59cc7155a01a17f15a3b853c30  libstdc++-v3/doc/html/manual/using_dual_abi.html
  a372b01a93ca1beeb843a1440bd25cdd  libstdc++-v3/doc/html/manual/using_dynamic_or_shared.html
  09eeb2fa79fb240e032461adcbe2cb4a  libstdc++-v3/doc/html/manual/using_exceptions.html
  8fc6625206a4feba33ced5fa38ab3af8  libstdc++-v3/doc/html/manual/using_headers.html
  c1e8d8c0d84363807d41edeb82e9dbfc  libstdc++-v3/doc/html/manual/using_macros.html
  ccc3b1a320ccc49a977c80546610195b  libstdc++-v3/doc/html/manual/using_namespaces.html
! 13c8dfb643338ee235bfc84a29e5d3f2  libstdc++-v3/doc/html/manual/utilities.html
  ccbc0492a648982f2dc225595bdbc567  libstdc++-v3/doc/xml/api.xml
  8059eb81f5540dc3ae678ac09e1f3159  libstdc++-v3/doc/xml/authors.xml
  5906074c27c57c65b220c35bbcb2c5ec  libstdc++-v3/doc/xml/book.txml
  44d3a92b83abfb18efac80519c79b44c  libstdc++-v3/doc/xml/chapter.txml
  011b8e6a5442e4dc08f02e7295b644a3  libstdc++-v3/doc/xml/class.txml
! 8f93da72f75ed83d18ee45f5e595a36e  libstdc++-v3/doc/xml/faq.xml
  ea77580f7e81e2c49aea3f425c01ee2b  libstdc++-v3/doc/xml/gnu/fdl-1.3.xml
  56bb32e9ab9358834c5f8eca2cd0e969  libstdc++-v3/doc/xml/gnu/gpl-3.0.xml
  18a6390297702ec8fd75cbcc525d2005  libstdc++-v3/doc/xml/images/confdeps.dot
*************** e184d827d7fb559037041e81118936cb  libstd
*** 114183,114197 ****
  8f13cae7ea80bc018b87b4ff8de7e3cf  libstdc++-v3/doc/xml/manual/codecvt.xml
  af3361d0d0af961859ec0346c38ac8c8  libstdc++-v3/doc/xml/manual/concurrency.xml
  9da4610e32c81714e9188c6852c8dc93  libstdc++-v3/doc/xml/manual/concurrency_extensions.xml
! c814233bae2af79cc1273d72145d497c  libstdc++-v3/doc/xml/manual/configure.xml
! 0af07cc2460e288292186ea8149169ee  libstdc++-v3/doc/xml/manual/containers.xml
  d08c687d9520b2f9d8dd6d973cca9e6a  libstdc++-v3/doc/xml/manual/ctype.xml
  abf083b50c6a5992ed45fd74c564ce42  libstdc++-v3/doc/xml/manual/debug.xml
  c38bf467401b65722356772cdf4d064b  libstdc++-v3/doc/xml/manual/debug_mode.xml
  f320f25003678cca910f09ba54c923fc  libstdc++-v3/doc/xml/manual/diagnostics.xml
  c7467f13981c47fc740c948b16a42a53  libstdc++-v3/doc/xml/manual/documentation_hacking.xml
  07eb831e9f3d714ededaf4fd8eaf953e  libstdc++-v3/doc/xml/manual/evolution.xml
! bdd63abf4539dfac8d1930024114b8ac  libstdc++-v3/doc/xml/manual/extensions.xml
  7f1864c7f3c3b2bfde84b7086be97ca7  libstdc++-v3/doc/xml/manual/internals.xml
  7dd90360d3e28e9f8aa299d81e4234c7  libstdc++-v3/doc/xml/manual/intro.xml
  93c3158fe28bdfbbf03dd039cc4e79a2  libstdc++-v3/doc/xml/manual/io.xml
--- 114437,114451 ----
  8f13cae7ea80bc018b87b4ff8de7e3cf  libstdc++-v3/doc/xml/manual/codecvt.xml
  af3361d0d0af961859ec0346c38ac8c8  libstdc++-v3/doc/xml/manual/concurrency.xml
  9da4610e32c81714e9188c6852c8dc93  libstdc++-v3/doc/xml/manual/concurrency_extensions.xml
! c41c4c9fa14f2b606c7f84c03138db8f  libstdc++-v3/doc/xml/manual/configure.xml
! d7100469dfefd97836f3007f2682087d  libstdc++-v3/doc/xml/manual/containers.xml
  d08c687d9520b2f9d8dd6d973cca9e6a  libstdc++-v3/doc/xml/manual/ctype.xml
  abf083b50c6a5992ed45fd74c564ce42  libstdc++-v3/doc/xml/manual/debug.xml
  c38bf467401b65722356772cdf4d064b  libstdc++-v3/doc/xml/manual/debug_mode.xml
  f320f25003678cca910f09ba54c923fc  libstdc++-v3/doc/xml/manual/diagnostics.xml
  c7467f13981c47fc740c948b16a42a53  libstdc++-v3/doc/xml/manual/documentation_hacking.xml
  07eb831e9f3d714ededaf4fd8eaf953e  libstdc++-v3/doc/xml/manual/evolution.xml
! f0ce8ebd60c1c48b65fb2ee9197b6cf9  libstdc++-v3/doc/xml/manual/extensions.xml
  7f1864c7f3c3b2bfde84b7086be97ca7  libstdc++-v3/doc/xml/manual/internals.xml
  7dd90360d3e28e9f8aa299d81e4234c7  libstdc++-v3/doc/xml/manual/intro.xml
  93c3158fe28bdfbbf03dd039cc4e79a2  libstdc++-v3/doc/xml/manual/io.xml
*************** f25986e96331b9ee671b4fe62ab33a1c  libstd
*** 114208,114216 ****
  adadeaccd7e3be18b69dcc095e96f3af  libstdc++-v3/doc/xml/manual/shared_ptr.xml
  d7f222c42325cd44eadad2c59eef7e6f  libstdc++-v3/doc/xml/manual/spine.xml
  95aa2fc9a168e2b8d3cd7a6ff333683b  libstdc++-v3/doc/xml/manual/status_cxx1998.xml
! 10a19df4d3fefacaf3ed4ca4c5cb4e05  libstdc++-v3/doc/xml/manual/status_cxx2011.xml
  4f70307aa2cb0ee63e0118644ca335f7  libstdc++-v3/doc/xml/manual/status_cxx2014.xml
! 7497dc124fde2f4f2c9ec52524ddd874  libstdc++-v3/doc/xml/manual/status_cxx2017.xml
  2b8d7fa4458f9cef741ce5f3a1ea20c2  libstdc++-v3/doc/xml/manual/status_cxx2020.xml
  978a702dd6ecf22eddec8319d1845acb  libstdc++-v3/doc/xml/manual/status_cxx2023.xml
  e12241b98a6c1e835b7b1d1bb31761ca  libstdc++-v3/doc/xml/manual/status_cxxis29124.xml
--- 114462,114470 ----
  adadeaccd7e3be18b69dcc095e96f3af  libstdc++-v3/doc/xml/manual/shared_ptr.xml
  d7f222c42325cd44eadad2c59eef7e6f  libstdc++-v3/doc/xml/manual/spine.xml
  95aa2fc9a168e2b8d3cd7a6ff333683b  libstdc++-v3/doc/xml/manual/status_cxx1998.xml
! 7dda1718eb7cf53b8c90d27b9029a94d  libstdc++-v3/doc/xml/manual/status_cxx2011.xml
  4f70307aa2cb0ee63e0118644ca335f7  libstdc++-v3/doc/xml/manual/status_cxx2014.xml
! 55de75fe326978eb3c7429d26847c7a4  libstdc++-v3/doc/xml/manual/status_cxx2017.xml
  2b8d7fa4458f9cef741ce5f3a1ea20c2  libstdc++-v3/doc/xml/manual/status_cxx2020.xml
  978a702dd6ecf22eddec8319d1845acb  libstdc++-v3/doc/xml/manual/status_cxx2023.xml
  e12241b98a6c1e835b7b1d1bb31761ca  libstdc++-v3/doc/xml/manual/status_cxxis29124.xml
*************** f034a532553ac7a651470a37734de409  libstd
*** 114220,114228 ****
  2b80feb1b53a8d0895a292620ec430b2  libstdc++-v3/doc/xml/manual/support.xml
  00b1a0e7aadec2255b3511eddc296e0b  libstdc++-v3/doc/xml/manual/test.xml
  e2e099be3dd6a4b7a940a7232635ee2c  libstdc++-v3/doc/xml/manual/test_policy_data_structures.xml
! 73e68ba75395798b0bc3fc9ebcafa33f  libstdc++-v3/doc/xml/manual/using.xml
  257e301935b13b4b045e571fa248a4d8  libstdc++-v3/doc/xml/manual/using_exceptions.xml
! 74a5acaa32b3d223bd413c1bb5b69ac6  libstdc++-v3/doc/xml/manual/utilities.xml
  0c8bbf7c330217f862dd4871a5ba88d0  libstdc++-v3/doc/xml/spine.xml
  bd966b4a0df6f2a84f9770525581d45c  libstdc++-v3/doc/xsl/customization.xsl.in
  42d14268f2b16c54a6bc2f71538a838c  libstdc++-v3/fragment.am
--- 114474,114482 ----
  2b80feb1b53a8d0895a292620ec430b2  libstdc++-v3/doc/xml/manual/support.xml
  00b1a0e7aadec2255b3511eddc296e0b  libstdc++-v3/doc/xml/manual/test.xml
  e2e099be3dd6a4b7a940a7232635ee2c  libstdc++-v3/doc/xml/manual/test_policy_data_structures.xml
! 2e9f68af1df8747f1aed7f497c8e8be0  libstdc++-v3/doc/xml/manual/using.xml
  257e301935b13b4b045e571fa248a4d8  libstdc++-v3/doc/xml/manual/using_exceptions.xml
! b820e3490221bb85cbf6bcdde0aa8150  libstdc++-v3/doc/xml/manual/utilities.xml
  0c8bbf7c330217f862dd4871a5ba88d0  libstdc++-v3/doc/xml/spine.xml
  bd966b4a0df6f2a84f9770525581d45c  libstdc++-v3/doc/xsl/customization.xsl.in
  42d14268f2b16c54a6bc2f71538a838c  libstdc++-v3/fragment.am
*************** b7a02d402cc5dc3b5900e144b1443bb7  libstd
*** 114244,114269 ****
  c5174ab6282ecbeced42a602ef71aa54  libstdc++-v3/include/bits/atomic_base.h
  f32e39c120815c7e19ae3bd66fae1f0c  libstdc++-v3/include/bits/atomic_futex.h
  10c6f59884b2d39c8bfaeb46e55b914d  libstdc++-v3/include/bits/atomic_timed_wait.h
! d365c012b1cfe6ca40197bca4b8e9abe  libstdc++-v3/include/bits/atomic_wait.h
  7a572f1436f9b069a82a366cd364af5c  libstdc++-v3/include/bits/basic_ios.h
  f72ffffc3ea2a2cb85b705217a116e9e  libstdc++-v3/include/bits/basic_ios.tcc
! b9b621010f3ee8b23e19f54706fcfe72  libstdc++-v3/include/bits/basic_string.h
  9e86f840e9d2da76f6ca15673d268d93  libstdc++-v3/include/bits/basic_string.tcc
  12d210ea7f6b7aff57c126940f016d55  libstdc++-v3/include/bits/boost_concept_check.h
  588d77b5caf0f9ab703289024f7faf88  libstdc++-v3/include/bits/c++0x_warning.h
  0db914ce3afb935ae5ae23a1f37308c8  libstdc++-v3/include/bits/c++config
  7f47148b0e13c75cb1ca1385d6ba2b3e  libstdc++-v3/include/bits/char_traits.h
  0a14bf55d3849f91b6f272370226f0b8  libstdc++-v3/include/bits/charconv.h
! a26ba7aaa694d8aeb87258e9cd78db1d  libstdc++-v3/include/bits/chrono.h
! 728eefcd3d8bd361f5754ccef8cd601d  libstdc++-v3/include/bits/chrono_io.h
  99228a8561efb5af08fdf896e792dbd3  libstdc++-v3/include/bits/codecvt.h
  02b297f22d933704022d62bb998083b6  libstdc++-v3/include/bits/concept_check.h
! ab05c0fac3a44588f6ca1f197b7758d2  libstdc++-v3/include/bits/cow_string.h
  ec765e2f1e49a5d8005cfb00827e03af  libstdc++-v3/include/bits/cpp_type_traits.h
  abf10f7822a3d2b4feaa7a1a2daa8865  libstdc++-v3/include/bits/deque.tcc
  144af56eb1fdcfa071b31d4e35716372  libstdc++-v3/include/bits/enable_special_members.h
  9fbde52831f934ca63d09c817fe5f7b3  libstdc++-v3/include/bits/erase_if.h
! 68f726da90926f2730fc257270d717cd  libstdc++-v3/include/bits/forward_list.h
  fc266b1bf548f2445b990be5c7f574c1  libstdc++-v3/include/bits/forward_list.tcc
  c9541d566769e4c7678db8b75d569397  libstdc++-v3/include/bits/fs_dir.h
  01a4d96f29ae6ac0bb84541df306c3f5  libstdc++-v3/include/bits/fs_fwd.h
--- 114498,114523 ----
  c5174ab6282ecbeced42a602ef71aa54  libstdc++-v3/include/bits/atomic_base.h
  f32e39c120815c7e19ae3bd66fae1f0c  libstdc++-v3/include/bits/atomic_futex.h
  10c6f59884b2d39c8bfaeb46e55b914d  libstdc++-v3/include/bits/atomic_timed_wait.h
! d89e6d1110a073677944d3c2f6d3b4b9  libstdc++-v3/include/bits/atomic_wait.h
  7a572f1436f9b069a82a366cd364af5c  libstdc++-v3/include/bits/basic_ios.h
  f72ffffc3ea2a2cb85b705217a116e9e  libstdc++-v3/include/bits/basic_ios.tcc
! f905c739c406885aba58dd48cd9eddab  libstdc++-v3/include/bits/basic_string.h
  9e86f840e9d2da76f6ca15673d268d93  libstdc++-v3/include/bits/basic_string.tcc
  12d210ea7f6b7aff57c126940f016d55  libstdc++-v3/include/bits/boost_concept_check.h
  588d77b5caf0f9ab703289024f7faf88  libstdc++-v3/include/bits/c++0x_warning.h
  0db914ce3afb935ae5ae23a1f37308c8  libstdc++-v3/include/bits/c++config
  7f47148b0e13c75cb1ca1385d6ba2b3e  libstdc++-v3/include/bits/char_traits.h
  0a14bf55d3849f91b6f272370226f0b8  libstdc++-v3/include/bits/charconv.h
! 89af0ab72b50a7bc31ce564865821616  libstdc++-v3/include/bits/chrono.h
! 77ed55d73137df2f8b49a45cfb51a985  libstdc++-v3/include/bits/chrono_io.h
  99228a8561efb5af08fdf896e792dbd3  libstdc++-v3/include/bits/codecvt.h
  02b297f22d933704022d62bb998083b6  libstdc++-v3/include/bits/concept_check.h
! 35c9669d9e15757a7acf82d95cda0a0a  libstdc++-v3/include/bits/cow_string.h
  ec765e2f1e49a5d8005cfb00827e03af  libstdc++-v3/include/bits/cpp_type_traits.h
  abf10f7822a3d2b4feaa7a1a2daa8865  libstdc++-v3/include/bits/deque.tcc
  144af56eb1fdcfa071b31d4e35716372  libstdc++-v3/include/bits/enable_special_members.h
  9fbde52831f934ca63d09c817fe5f7b3  libstdc++-v3/include/bits/erase_if.h
! 389647ab8cd9b735917d8102235acc84  libstdc++-v3/include/bits/forward_list.h
  fc266b1bf548f2445b990be5c7f574c1  libstdc++-v3/include/bits/forward_list.tcc
  c9541d566769e4c7678db8b75d569397  libstdc++-v3/include/bits/fs_dir.h
  01a4d96f29ae6ac0bb84541df306c3f5  libstdc++-v3/include/bits/fs_fwd.h
*************** ea9f3638ad1b48ca29f5994d80c71708  libstd
*** 114309,114315 ****
  5063de5afefced00ecaace4d45d034d3  libstdc++-v3/include/bits/random.h
  09901fcf0de4c3ba0d6a0dfd023607b9  libstdc++-v3/include/bits/random.tcc
  473f8f1ef247a71477d517401689f0c9  libstdc++-v3/include/bits/range_access.h
! 0b340f9f0aa8be50f3129c18e59e2b02  libstdc++-v3/include/bits/ranges_algo.h
  8da69d1883c69ec7a5d57af5d6bb60fd  libstdc++-v3/include/bits/ranges_algobase.h
  9b18aa7d8fd40cbccc3783c4d2e93046  libstdc++-v3/include/bits/ranges_base.h
  130f0e54de161dc32742e62f03e44704  libstdc++-v3/include/bits/ranges_cmp.h
--- 114563,114569 ----
  5063de5afefced00ecaace4d45d034d3  libstdc++-v3/include/bits/random.h
  09901fcf0de4c3ba0d6a0dfd023607b9  libstdc++-v3/include/bits/random.tcc
  473f8f1ef247a71477d517401689f0c9  libstdc++-v3/include/bits/range_access.h
! e9bcf745979805249ec896781f4a79e9  libstdc++-v3/include/bits/ranges_algo.h
  8da69d1883c69ec7a5d57af5d6bb60fd  libstdc++-v3/include/bits/ranges_algobase.h
  9b18aa7d8fd40cbccc3783c4d2e93046  libstdc++-v3/include/bits/ranges_base.h
  130f0e54de161dc32742e62f03e44704  libstdc++-v3/include/bits/ranges_cmp.h
*************** ea9f3638ad1b48ca29f5994d80c71708  libstd
*** 114320,114326 ****
  2715eb7a43f808404c2629768d926ff1  libstdc++-v3/include/bits/regex.tcc
  093a9e6cddf80585a28f72f3b3919114  libstdc++-v3/include/bits/regex_automaton.h
  431d58faa74d17aed8a543d406a6cff6  libstdc++-v3/include/bits/regex_automaton.tcc
! d0185a0935bbce160f36ba8d07fd7679  libstdc++-v3/include/bits/regex_compiler.h
  3165a3840032b820376dc39675396cd4  libstdc++-v3/include/bits/regex_compiler.tcc
  41be9061647eafed77fbf93815faa644  libstdc++-v3/include/bits/regex_constants.h
  bab03b51484604b9075a12c146b15eb9  libstdc++-v3/include/bits/regex_error.h
--- 114574,114580 ----
  2715eb7a43f808404c2629768d926ff1  libstdc++-v3/include/bits/regex.tcc
  093a9e6cddf80585a28f72f3b3919114  libstdc++-v3/include/bits/regex_automaton.h
  431d58faa74d17aed8a543d406a6cff6  libstdc++-v3/include/bits/regex_automaton.tcc
! 849a117fa68ae1f4dbb79f8580aa756c  libstdc++-v3/include/bits/regex_compiler.h
  3165a3840032b820376dc39675396cd4  libstdc++-v3/include/bits/regex_compiler.tcc
  41be9061647eafed77fbf93815faa644  libstdc++-v3/include/bits/regex_constants.h
  bab03b51484604b9075a12c146b15eb9  libstdc++-v3/include/bits/regex_error.h
*************** c63271fac886a0347ae54d09ec615a70  libstd
*** 114332,114338 ****
  d4ab3a218dd86e5f987bcd411be99642  libstdc++-v3/include/bits/semaphore_base.h
  aa7b516414d2b32705387e26d6fa52da  libstdc++-v3/include/bits/shared_ptr.h
  8d97d19a65806c0e81b6f50221951b57  libstdc++-v3/include/bits/shared_ptr_atomic.h
! 398b697f034a380e2062e59e71a6eec9  libstdc++-v3/include/bits/shared_ptr_base.h
  70168d829c78bb22a3de01f9da622f52  libstdc++-v3/include/bits/slice_array.h
  19fe23e6a7a34cff22e75da635190a85  libstdc++-v3/include/bits/specfun.h
  f5db8c25a45bb53faa4affdc482ec0ae  libstdc++-v3/include/bits/sstream.tcc
--- 114586,114592 ----
  d4ab3a218dd86e5f987bcd411be99642  libstdc++-v3/include/bits/semaphore_base.h
  aa7b516414d2b32705387e26d6fa52da  libstdc++-v3/include/bits/shared_ptr.h
  8d97d19a65806c0e81b6f50221951b57  libstdc++-v3/include/bits/shared_ptr_atomic.h
! 91d14beeffd36a0fc98f8586e1ffbb14  libstdc++-v3/include/bits/shared_ptr_base.h
  70168d829c78bb22a3de01f9da622f52  libstdc++-v3/include/bits/slice_array.h
  19fe23e6a7a34cff22e75da635190a85  libstdc++-v3/include/bits/specfun.h
  f5db8c25a45bb53faa4affdc482ec0ae  libstdc++-v3/include/bits/sstream.tcc
*************** f7dbdb00cb5664fe06868cb519c18fbf  libstd
*** 114343,114349 ****
  5be391a12793142550786b0bb50e6138  libstdc++-v3/include/bits/stl_algo.h
  443f7678e66a208008b30b4fe6575fc7  libstdc++-v3/include/bits/stl_algobase.h
  017c2db5a715f2c5215992f550936e62  libstdc++-v3/include/bits/stl_bvector.h
! 2692aca002018b5b1663c464dddaf63f  libstdc++-v3/include/bits/stl_construct.h
  4a0bb23f380040a1ce59a88a8353ce1b  libstdc++-v3/include/bits/stl_deque.h
  60507e6d5f3434ae5ce86363f622a178  libstdc++-v3/include/bits/stl_function.h
  f1a151d37c2259f38ae9f3bb60c184cc  libstdc++-v3/include/bits/stl_heap.h
--- 114597,114603 ----
  5be391a12793142550786b0bb50e6138  libstdc++-v3/include/bits/stl_algo.h
  443f7678e66a208008b30b4fe6575fc7  libstdc++-v3/include/bits/stl_algobase.h
  017c2db5a715f2c5215992f550936e62  libstdc++-v3/include/bits/stl_bvector.h
! 1614f1b27bffe489aa8c4b32eeaf08e0  libstdc++-v3/include/bits/stl_construct.h
  4a0bb23f380040a1ce59a88a8353ce1b  libstdc++-v3/include/bits/stl_deque.h
  60507e6d5f3434ae5ce86363f622a178  libstdc++-v3/include/bits/stl_function.h
  f1a151d37c2259f38ae9f3bb60c184cc  libstdc++-v3/include/bits/stl_heap.h
*************** c4df460e330dbfd383b0f347b37e5c6e  libstd
*** 114355,114362 ****
  acfce1940d41d37560494851676d5991  libstdc++-v3/include/bits/stl_multimap.h
  6c5062c35eced881ad87ebac2c8a5faf  libstdc++-v3/include/bits/stl_multiset.h
  a160d3a1010219c7f0a400e068b1b39c  libstdc++-v3/include/bits/stl_numeric.h
! 73730f2e40d95437864180754ecd0b92  libstdc++-v3/include/bits/stl_pair.h
! 420d5465635ca7fcbba4bc1a1f702222  libstdc++-v3/include/bits/stl_queue.h
  d12837792d22543fb74e959b8671dc45  libstdc++-v3/include/bits/stl_raw_storage_iter.h
  04b280c2aae349e2e28e67c88e0500c3  libstdc++-v3/include/bits/stl_relops.h
  3d95e52c0ad2bef5b3530737dc1f1013  libstdc++-v3/include/bits/stl_set.h
--- 114609,114616 ----
  acfce1940d41d37560494851676d5991  libstdc++-v3/include/bits/stl_multimap.h
  6c5062c35eced881ad87ebac2c8a5faf  libstdc++-v3/include/bits/stl_multiset.h
  a160d3a1010219c7f0a400e068b1b39c  libstdc++-v3/include/bits/stl_numeric.h
! 6c9baa7c3c4d143fae498a34a9efda80  libstdc++-v3/include/bits/stl_pair.h
! a7453339a2e48473111a6a57f28020a2  libstdc++-v3/include/bits/stl_queue.h
  d12837792d22543fb74e959b8671dc45  libstdc++-v3/include/bits/stl_raw_storage_iter.h
  04b280c2aae349e2e28e67c88e0500c3  libstdc++-v3/include/bits/stl_relops.h
  3d95e52c0ad2bef5b3530737dc1f1013  libstdc++-v3/include/bits/stl_set.h
*************** c3445e498460fdc279feccd5ae8fbb86  libstd
*** 114364,114370 ****
  f7c3cbbbff1984288eafd88b89681a07  libstdc++-v3/include/bits/stl_tempbuf.h
  36d6f928cc8e71e112b42db10f544bc1  libstdc++-v3/include/bits/stl_tree.h
  318d09ba72a8265560864b609bcb530f  libstdc++-v3/include/bits/stl_uninitialized.h
! 270f7329af0d2978723eb52b899a22c3  libstdc++-v3/include/bits/stl_vector.h
  8b9076ee3d87752c4e3d5cdafa8b9461  libstdc++-v3/include/bits/stream_iterator.h
  9210c3666e5e698bc555d7335c97696d  libstdc++-v3/include/bits/streambuf.tcc
  c41c5f3f46185db536fa877db8f0dd4e  libstdc++-v3/include/bits/streambuf_iterator.h
--- 114618,114624 ----
  f7c3cbbbff1984288eafd88b89681a07  libstdc++-v3/include/bits/stl_tempbuf.h
  36d6f928cc8e71e112b42db10f544bc1  libstdc++-v3/include/bits/stl_tree.h
  318d09ba72a8265560864b609bcb530f  libstdc++-v3/include/bits/stl_uninitialized.h
! d5f756910855904797959217b349410e  libstdc++-v3/include/bits/stl_vector.h
  8b9076ee3d87752c4e3d5cdafa8b9461  libstdc++-v3/include/bits/stream_iterator.h
  9210c3666e5e698bc555d7335c97696d  libstdc++-v3/include/bits/streambuf.tcc
  c41c5f3f46185db536fa877db8f0dd4e  libstdc++-v3/include/bits/streambuf_iterator.h
*************** a6cc9d4b57dc76ee00dc459b9aa9aa4b  libstd
*** 114383,114389 ****
  322814b36de24720a8d60f70da5e3f19  libstdc++-v3/include/bits/valarray_array.h
  d0dc224b4535c28e743c20c95a58c09e  libstdc++-v3/include/bits/valarray_array.tcc
  497da4999eb1bda92fc3d86d2d395554  libstdc++-v3/include/bits/valarray_before.h
! eb9f9f894ffc2193a0a27653af910f84  libstdc++-v3/include/bits/vector.tcc
  51aca95b9c0bb2ebdb0394442ba41eb5  libstdc++-v3/include/c/cassert
  a92920f183eb4d2e23e70f36bdd58854  libstdc++-v3/include/c/cctype
  d81a9516b0313de19e213978a64ec2e6  libstdc++-v3/include/c/cerrno
--- 114637,114643 ----
  322814b36de24720a8d60f70da5e3f19  libstdc++-v3/include/bits/valarray_array.h
  d0dc224b4535c28e743c20c95a58c09e  libstdc++-v3/include/bits/valarray_array.tcc
  497da4999eb1bda92fc3d86d2d395554  libstdc++-v3/include/bits/valarray_before.h
! 861482247fa3ea48ee33fec7c7bb8d04  libstdc++-v3/include/bits/vector.tcc
  51aca95b9c0bb2ebdb0394442ba41eb5  libstdc++-v3/include/c/cassert
  a92920f183eb4d2e23e70f36bdd58854  libstdc++-v3/include/c/cctype
  d81a9516b0313de19e213978a64ec2e6  libstdc++-v3/include/c/cerrno
*************** bedeabf12edce197ed12dcd0316fb014  libstd
*** 114439,114445 ****
  e056e894d561a617e8a5fbe43b91fe5c  libstdc++-v3/include/c_global/ciso646
  6630f0421a36b3f446414bf99ca60dd8  libstdc++-v3/include/c_global/climits
  e4c7c2d232b07c4cd56e5e8f767283f8  libstdc++-v3/include/c_global/clocale
! bfedd8724dfb7d08f864ea6b57586b4a  libstdc++-v3/include/c_global/cmath
  999c263b7a2d246d1187abd6a13e8c28  libstdc++-v3/include/c_global/csetjmp
  9829a810311d8c8e3e1dd51b6db1980a  libstdc++-v3/include/c_global/csignal
  f4048bb0abba66f92a6c162d91e03840  libstdc++-v3/include/c_global/cstdalign
--- 114693,114699 ----
  e056e894d561a617e8a5fbe43b91fe5c  libstdc++-v3/include/c_global/ciso646
  6630f0421a36b3f446414bf99ca60dd8  libstdc++-v3/include/c_global/climits
  e4c7c2d232b07c4cd56e5e8f767283f8  libstdc++-v3/include/c_global/clocale
! f67cf8cfd9f34d556c60b4a67f24fd20  libstdc++-v3/include/c_global/cmath
  999c263b7a2d246d1187abd6a13e8c28  libstdc++-v3/include/c_global/csetjmp
  9829a810311d8c8e3e1dd51b6db1980a  libstdc++-v3/include/c_global/csignal
  f4048bb0abba66f92a6c162d91e03840  libstdc++-v3/include/c_global/cstdalign
*************** a71f1dd732989c548e6fb3cd90bfcc75  libstd
*** 114835,114841 ****
  6a9b1e88e1ec57acf528ceb9b5e779b8  libstdc++-v3/include/ext/pb_ds/tree_policy.hpp
  e7b68ea74dbc4486f304d6445d5772a5  libstdc++-v3/include/ext/pb_ds/trie_policy.hpp
  caadfacabfe85328d467de9b1a25d397  libstdc++-v3/include/ext/pod_char_traits.h
! 20ee1e20f41dc68c730b2c9db8475c3c  libstdc++-v3/include/ext/pointer.h
  77bb1ef847d55994d9c652b65ddf54e1  libstdc++-v3/include/ext/pool_allocator.h
  7955d1b4c96e31649813e1ada0e5811b  libstdc++-v3/include/ext/random
  bcda42405934b29e401f272851d5bfaf  libstdc++-v3/include/ext/random.tcc
--- 115089,115095 ----
  6a9b1e88e1ec57acf528ceb9b5e779b8  libstdc++-v3/include/ext/pb_ds/tree_policy.hpp
  e7b68ea74dbc4486f304d6445d5772a5  libstdc++-v3/include/ext/pb_ds/trie_policy.hpp
  caadfacabfe85328d467de9b1a25d397  libstdc++-v3/include/ext/pod_char_traits.h
! 68d276b2ab6eb7aeff31c3b34d0cf48a  libstdc++-v3/include/ext/pointer.h
  77bb1ef847d55994d9c652b65ddf54e1  libstdc++-v3/include/ext/pool_allocator.h
  7955d1b4c96e31649813e1ada0e5811b  libstdc++-v3/include/ext/random
  bcda42405934b29e401f272851d5bfaf  libstdc++-v3/include/ext/random.tcc
*************** f98a7da671b9686b71b6a61ff48d0538  libstd
*** 114898,114904 ****
  085e36e6e77e7679b5f2f5cd5fd93931  libstdc++-v3/include/parallel/types.h
  ee876d1419f189568c9dd7ed916f35d5  libstdc++-v3/include/parallel/unique_copy.h
  025ff1d1cd81f4b5551024effaad0749  libstdc++-v3/include/parallel/workstealing.h
! ac6f3952b9775da8d2d822fb28883525  libstdc++-v3/include/precompiled/extc++.h
  88de13548af2742f88d9e3dca38ccdb3  libstdc++-v3/include/precompiled/stdc++.h
  60623194aa23fd2879dab07a37497288  libstdc++-v3/include/precompiled/stdtr1c++.h
  75cfb36aeb3ed8672bb4e2957272203c  libstdc++-v3/include/pstl/LICENSE.txt
--- 115152,115158 ----
  085e36e6e77e7679b5f2f5cd5fd93931  libstdc++-v3/include/parallel/types.h
  ee876d1419f189568c9dd7ed916f35d5  libstdc++-v3/include/parallel/unique_copy.h
  025ff1d1cd81f4b5551024effaad0749  libstdc++-v3/include/parallel/workstealing.h
! 18420be6479549d1404167040e088ee3  libstdc++-v3/include/precompiled/extc++.h
  88de13548af2742f88d9e3dca38ccdb3  libstdc++-v3/include/precompiled/stdc++.h
  60623194aa23fd2879dab07a37497288  libstdc++-v3/include/precompiled/stdtr1c++.h
  75cfb36aeb3ed8672bb4e2957272203c  libstdc++-v3/include/pstl/LICENSE.txt
*************** b692aa95f9f120acbe330c2893c3ce6e  libstd
*** 114918,114924 ****
  f77d53ba87bdc41f32fe05abd7640590  libstdc++-v3/include/pstl/numeric_impl.h
  f0154f75dafee0c95cfc13f091939f93  libstdc++-v3/include/pstl/parallel_backend.h
  e972bfc42cfac92bfde04a35e915514e  libstdc++-v3/include/pstl/parallel_backend_serial.h
! 902b12072934917ec50145590999c9ac  libstdc++-v3/include/pstl/parallel_backend_tbb.h
  e128e525f970f3948feec2f4750919a8  libstdc++-v3/include/pstl/parallel_backend_utils.h
  d3d2812c60e828c1e822801f148c7630  libstdc++-v3/include/pstl/parallel_impl.h
  64e9a3bc96d1e3015387cb95106544cf  libstdc++-v3/include/pstl/pstl_config.h
--- 115172,115178 ----
  f77d53ba87bdc41f32fe05abd7640590  libstdc++-v3/include/pstl/numeric_impl.h
  f0154f75dafee0c95cfc13f091939f93  libstdc++-v3/include/pstl/parallel_backend.h
  e972bfc42cfac92bfde04a35e915514e  libstdc++-v3/include/pstl/parallel_backend_serial.h
! 06921253c5d0c5ab4b315c0e2f16aa61  libstdc++-v3/include/pstl/parallel_backend_tbb.h
  e128e525f970f3948feec2f4750919a8  libstdc++-v3/include/pstl/parallel_backend_utils.h
  d3d2812c60e828c1e822801f148c7630  libstdc++-v3/include/pstl/parallel_impl.h
  64e9a3bc96d1e3015387cb95106544cf  libstdc++-v3/include/pstl/pstl_config.h
*************** c236e001d2914387b789ce13408d7224  libstd
*** 114927,114938 ****
  685f5bca7582106082732b3aa4facb12  libstdc++-v3/include/std/algorithm
  fc9b21dd5374fb6eb8ae18d329975612  libstdc++-v3/include/std/any
  2d7e12f609af86f79536f7ce64c736c4  libstdc++-v3/include/std/array
! 0919c06365948d659b248b825a7d0146  libstdc++-v3/include/std/atomic
  9f99ade7dd4b9b396effd0996ee55664  libstdc++-v3/include/std/barrier
  6a6e184e0a63330c64ab616785279ac6  libstdc++-v3/include/std/bit
  06852873ecbf5b23ff53ea0b1952d3d8  libstdc++-v3/include/std/bitset
  3ee0e8090ee1f0e442c4bf1bc44a96f4  libstdc++-v3/include/std/charconv
! c1d080b2c23b4f05b4cb6ae8fe066cad  libstdc++-v3/include/std/chrono
  bbf20db5408848d929deed7c0ba28df3  libstdc++-v3/include/std/codecvt
  d3e91ccfa90352c8af77f3f7e0303ac8  libstdc++-v3/include/std/complex
  933005cab15e64abf8af0d4e0972908f  libstdc++-v3/include/std/concepts
--- 115181,115192 ----
  685f5bca7582106082732b3aa4facb12  libstdc++-v3/include/std/algorithm
  fc9b21dd5374fb6eb8ae18d329975612  libstdc++-v3/include/std/any
  2d7e12f609af86f79536f7ce64c736c4  libstdc++-v3/include/std/array
! be2393381a05eac4c3ce9c1ca48fcc14  libstdc++-v3/include/std/atomic
  9f99ade7dd4b9b396effd0996ee55664  libstdc++-v3/include/std/barrier
  6a6e184e0a63330c64ab616785279ac6  libstdc++-v3/include/std/bit
  06852873ecbf5b23ff53ea0b1952d3d8  libstdc++-v3/include/std/bitset
  3ee0e8090ee1f0e442c4bf1bc44a96f4  libstdc++-v3/include/std/charconv
! de252c9134d2cd911e75698e72683062  libstdc++-v3/include/std/chrono
  bbf20db5408848d929deed7c0ba28df3  libstdc++-v3/include/std/codecvt
  d3e91ccfa90352c8af77f3f7e0303ac8  libstdc++-v3/include/std/complex
  933005cab15e64abf8af0d4e0972908f  libstdc++-v3/include/std/concepts
*************** d4f9ad7eed03fb685a74447a8cd6ef66  libstd
*** 114942,114948 ****
  eea32f3270e190607c59e827a3854ace  libstdc++-v3/include/std/execution
  fee506a1489dec7f7e00673a321a5570  libstdc++-v3/include/std/expected
  0e0edf5c0fdce36e4277045c50bf6e82  libstdc++-v3/include/std/filesystem
! 2f46544d95881c00b89b0232fe577183  libstdc++-v3/include/std/format
  e8b3f7dcdc2931df0cd13c42bbd3dcc8  libstdc++-v3/include/std/forward_list
  7aba15a067efc51b46fe83c639a9b4d4  libstdc++-v3/include/std/fstream
  16e7743571a067798c9ef29c142086b1  libstdc++-v3/include/std/functional
--- 115196,115202 ----
  eea32f3270e190607c59e827a3854ace  libstdc++-v3/include/std/execution
  fee506a1489dec7f7e00673a321a5570  libstdc++-v3/include/std/expected
  0e0edf5c0fdce36e4277045c50bf6e82  libstdc++-v3/include/std/filesystem
! 8c83fbd9c793c126e013740af02e6dd1  libstdc++-v3/include/std/format
  e8b3f7dcdc2931df0cd13c42bbd3dcc8  libstdc++-v3/include/std/forward_list
  7aba15a067efc51b46fe83c639a9b4d4  libstdc++-v3/include/std/fstream
  16e7743571a067798c9ef29c142086b1  libstdc++-v3/include/std/functional
*************** ae3312c33853f8a52ee7443cbe05a3f5  libstd
*** 114961,114967 ****
  f78d1595423575bfc922448e67e52239  libstdc++-v3/include/std/memory
  654e4d13aaec5087497c0b3cd42d26b3  libstdc++-v3/include/std/memory_resource
  6294ee905a70436875640f1d15627c30  libstdc++-v3/include/std/mutex
! ce04f4fc0fa3c3aa259cf4b87813d4a7  libstdc++-v3/include/std/numbers
  911822e909a122dab0874ada31ffa30f  libstdc++-v3/include/std/numeric
  f983d195aabe6ddf5bdb53a8b9960b70  libstdc++-v3/include/std/optional
  d80e37105837d110af793b72a4094525  libstdc++-v3/include/std/ostream
--- 115215,115221 ----
  f78d1595423575bfc922448e67e52239  libstdc++-v3/include/std/memory
  654e4d13aaec5087497c0b3cd42d26b3  libstdc++-v3/include/std/memory_resource
  6294ee905a70436875640f1d15627c30  libstdc++-v3/include/std/mutex
! 0b0656abe62b38159901549320557c2b  libstdc++-v3/include/std/numbers
  911822e909a122dab0874ada31ffa30f  libstdc++-v3/include/std/numeric
  f983d195aabe6ddf5bdb53a8b9960b70  libstdc++-v3/include/std/optional
  d80e37105837d110af793b72a4094525  libstdc++-v3/include/std/ostream
*************** d03063a4bedb845e2ff7fba28b7ecb1d  libstd
*** 114976,114995 ****
  91349ac9a04bb9ff2dc33d743bcf6601  libstdc++-v3/include/std/shared_mutex
  d379c79a4b4ed0a78190d8f4a9da9aa2  libstdc++-v3/include/std/source_location
  2a2066d8e8f8c8a94b2d17fa0990856d  libstdc++-v3/include/std/span
! d85e5f395906ee64d169f731e153854e  libstdc++-v3/include/std/spanstream
! a75470ffd4afdfac6eca39a7b36542d2  libstdc++-v3/include/std/sstream
  91e5fdbed2e8180adc1417ecfceba477  libstdc++-v3/include/std/stack
  bbc0c33c94ab18dc7789ef417cbd2143  libstdc++-v3/include/std/stacktrace
  91c2dec920e37dc2bdfcd57f2ee1917c  libstdc++-v3/include/std/stdexcept
  59e3dae4ebf67b9eb46705e56e8541af  libstdc++-v3/include/std/stdfloat
  7fd4f7aceafc9e47af067236ba39094f  libstdc++-v3/include/std/stop_token
! 2b9390e43d36e97d4ea240c08afeeba5  libstdc++-v3/include/std/streambuf
  d4462abdac571d8d61a236930c8cfc4b  libstdc++-v3/include/std/string
! 0fecd4da9af242a5c73494454baddd26  libstdc++-v3/include/std/string_view
  389b652a4f0c6e87818f8b1ab805ec13  libstdc++-v3/include/std/syncstream
  0ef04d7cdcad35a449aec6319852270f  libstdc++-v3/include/std/system_error
  f247d2ab92c9235549e795b99206b5e7  libstdc++-v3/include/std/thread
! f16a4d988e4018aed43e10d719ed07a4  libstdc++-v3/include/std/tuple
  aaf1c30405392a16806fece2b71d7820  libstdc++-v3/include/std/type_traits
  5a950e25b3e5d469314bc0a340057eaa  libstdc++-v3/include/std/typeindex
  b3721b1a59dccec76d19cdcd7d20c684  libstdc++-v3/include/std/unordered_map
--- 115230,115249 ----
  91349ac9a04bb9ff2dc33d743bcf6601  libstdc++-v3/include/std/shared_mutex
  d379c79a4b4ed0a78190d8f4a9da9aa2  libstdc++-v3/include/std/source_location
  2a2066d8e8f8c8a94b2d17fa0990856d  libstdc++-v3/include/std/span
! db9fe283b6b937cb9e68fc46bd412a89  libstdc++-v3/include/std/spanstream
! 20d55bd6ba1c90c00d51f7ab0d3f765c  libstdc++-v3/include/std/sstream
  91e5fdbed2e8180adc1417ecfceba477  libstdc++-v3/include/std/stack
  bbc0c33c94ab18dc7789ef417cbd2143  libstdc++-v3/include/std/stacktrace
  91c2dec920e37dc2bdfcd57f2ee1917c  libstdc++-v3/include/std/stdexcept
  59e3dae4ebf67b9eb46705e56e8541af  libstdc++-v3/include/std/stdfloat
  7fd4f7aceafc9e47af067236ba39094f  libstdc++-v3/include/std/stop_token
! 2870643ab3d1ccb6dbf8f8e9131777a7  libstdc++-v3/include/std/streambuf
  d4462abdac571d8d61a236930c8cfc4b  libstdc++-v3/include/std/string
! 1f5767878023aeda25ed5a092a92c77a  libstdc++-v3/include/std/string_view
  389b652a4f0c6e87818f8b1ab805ec13  libstdc++-v3/include/std/syncstream
  0ef04d7cdcad35a449aec6319852270f  libstdc++-v3/include/std/system_error
  f247d2ab92c9235549e795b99206b5e7  libstdc++-v3/include/std/thread
! 1ebc3bd587e5a65ca5464450d7e4a0a2  libstdc++-v3/include/std/tuple
  aaf1c30405392a16806fece2b71d7820  libstdc++-v3/include/std/type_traits
  5a950e25b3e5d469314bc0a340057eaa  libstdc++-v3/include/std/typeindex
  b3721b1a59dccec76d19cdcd7d20c684  libstdc++-v3/include/std/unordered_map
*************** e4724aea7b38f8f2110f154ac4a2df43  libstd
*** 115165,115171 ****
  68b329da9893e34099c7d8ad5cb9c940  libstdc++-v3/python/libstdcxx/__init__.py
  74cf87654ab91027b27296333b040171  libstdc++-v3/python/libstdcxx/v6/__init__.py
  25fca50ddaa1dca3dfd2c2fa6d6159c0  libstdc++-v3/python/libstdcxx/v6/printers.py
! 358ce01ad28bc23f412d6cca22c00026  libstdc++-v3/python/libstdcxx/v6/xmethods.py
  cdac7363b91e7d57b85f7b560f62f033  libstdc++-v3/scripts/check_compile
  a4c1d51bba293cee2307fc7f9dd090f7  libstdc++-v3/scripts/check_performance
  128d0fbc24e1d43d9ff93d14bd521aa6  libstdc++-v3/scripts/check_simd
--- 115419,115425 ----
  68b329da9893e34099c7d8ad5cb9c940  libstdc++-v3/python/libstdcxx/__init__.py
  74cf87654ab91027b27296333b040171  libstdc++-v3/python/libstdcxx/v6/__init__.py
  25fca50ddaa1dca3dfd2c2fa6d6159c0  libstdc++-v3/python/libstdcxx/v6/printers.py
! dd2459c1d55e50551a5832be61dccac7  libstdc++-v3/python/libstdcxx/v6/xmethods.py
  cdac7363b91e7d57b85f7b560f62f033  libstdc++-v3/scripts/check_compile
  a4c1d51bba293cee2307fc7f9dd090f7  libstdc++-v3/scripts/check_performance
  128d0fbc24e1d43d9ff93d14bd521aa6  libstdc++-v3/scripts/check_simd
*************** cdf9c54ab7ea85aa42bbf32b2e749913  libstd
*** 115263,115270 ****
  3b38edf9d188d303f6aa2c63b7032e89  libstdc++-v3/src/c++17/floating_to_chars.cc
  fa072ccb9e6e80b3f27e4b23dfd619f9  libstdc++-v3/src/c++17/fs_dir.cc
  4f8743f3869fca4fcea53ac133a5149c  libstdc++-v3/src/c++17/fs_ops.cc
! 17fedf8750118959c518303ad2958de2  libstdc++-v3/src/c++17/fs_path.cc
! 115b4116584b81ff091cc1c8a434be2b  libstdc++-v3/src/c++17/memory_resource.cc
  2e23492a9bdff13463ee6d01c4b7cc20  libstdc++-v3/src/c++17/ostream-inst.cc
  f7696e2f5518e5e873ced4beacb8d107  libstdc++-v3/src/c++17/ryu/LOCAL_PATCHES
  e225c39ccc4c6adc72a744687977d59d  libstdc++-v3/src/c++17/ryu/MERGE
--- 115517,115524 ----
  3b38edf9d188d303f6aa2c63b7032e89  libstdc++-v3/src/c++17/floating_to_chars.cc
  fa072ccb9e6e80b3f27e4b23dfd619f9  libstdc++-v3/src/c++17/fs_dir.cc
  4f8743f3869fca4fcea53ac133a5149c  libstdc++-v3/src/c++17/fs_ops.cc
! 03d1d71565ab06303ddc8ce45e1db34c  libstdc++-v3/src/c++17/fs_path.cc
! 99c2aeb80767d9674325cb0cf760d949  libstdc++-v3/src/c++17/memory_resource.cc
  2e23492a9bdff13463ee6d01c4b7cc20  libstdc++-v3/src/c++17/ostream-inst.cc
  f7696e2f5518e5e873ced4beacb8d107  libstdc++-v3/src/c++17/ryu/LOCAL_PATCHES
  e225c39ccc4c6adc72a744687977d59d  libstdc++-v3/src/c++17/ryu/MERGE
*************** fbb127f006c65ae37d591c627cc6235c  libstd
*** 115285,115292 ****
  254cd9c33da3fa7ab663f4fb0c3eb02d  libstdc++-v3/src/c++20/Makefile.am
  1a78ce3875810d2fbde4c0259e6da49c  libstdc++-v3/src/c++20/Makefile.in
  b914ff6670ac6160405a2435443a4a06  libstdc++-v3/src/c++20/sstream-inst.cc
! e9e89f4578e59d252e4caaf0b63d6dfb  libstdc++-v3/src/c++20/tzdata.zi
! 9bb91b77dc34356d05e32ad4ef38f6e4  libstdc++-v3/src/c++20/tzdb.cc
  45134a761e2989110bf92106ea6dca4e  libstdc++-v3/src/c++98/Makefile.am
  9b27a44fa8ef5adb147c45f43b150e95  libstdc++-v3/src/c++98/Makefile.in
  0da013c21616235a62a7ce091c9e8ab8  libstdc++-v3/src/c++98/allocator-inst.cc
--- 115539,115546 ----
  254cd9c33da3fa7ab663f4fb0c3eb02d  libstdc++-v3/src/c++20/Makefile.am
  1a78ce3875810d2fbde4c0259e6da49c  libstdc++-v3/src/c++20/Makefile.in
  b914ff6670ac6160405a2435443a4a06  libstdc++-v3/src/c++20/sstream-inst.cc
! e868493d039d86bca105c23a24b87383  libstdc++-v3/src/c++20/tzdata.zi
! 84608cc3c5b549d5d3b98e83fbd468db  libstdc++-v3/src/c++20/tzdb.cc
  45134a761e2989110bf92106ea6dca4e  libstdc++-v3/src/c++98/Makefile.am
  9b27a44fa8ef5adb147c45f43b150e95  libstdc++-v3/src/c++98/Makefile.in
  0da013c21616235a62a7ce091c9e8ab8  libstdc++-v3/src/c++98/allocator-inst.cc
*************** a6f95078e97a60d866de0908aeb10897  libstd
*** 115340,115346 ****
  3985b8fca46c60e27ba47d4d73565f04  libstdc++-v3/src/filesystem/cow-path.cc
  a9e784beb869d9bc7d37934ce0a952f9  libstdc++-v3/src/filesystem/dir-common.h
  d45c23b8e35edb3a14e4d3400daeb1ed  libstdc++-v3/src/filesystem/dir.cc
! c182f1c2e54adc3a27981482189fa2e8  libstdc++-v3/src/filesystem/ops-common.h
  9888787832c93f2184290cfcc78eb874  libstdc++-v3/src/filesystem/ops.cc
  2fa22da658515e688182701d446f5194  libstdc++-v3/src/filesystem/path.cc
  39db16d7fc6280edeec0ba37d212cb2d  libstdc++-v3/src/libbacktrace/Makefile.am
--- 115594,115600 ----
  3985b8fca46c60e27ba47d4d73565f04  libstdc++-v3/src/filesystem/cow-path.cc
  a9e784beb869d9bc7d37934ce0a952f9  libstdc++-v3/src/filesystem/dir-common.h
  d45c23b8e35edb3a14e4d3400daeb1ed  libstdc++-v3/src/filesystem/dir.cc
! 7f621885dd6cb6f0875e0bf786388308  libstdc++-v3/src/filesystem/ops-common.h
  9888787832c93f2184290cfcc78eb874  libstdc++-v3/src/filesystem/ops.cc
  2fa22da658515e688182701d446f5194  libstdc++-v3/src/filesystem/path.cc
  39db16d7fc6280edeec0ba37d212cb2d  libstdc++-v3/src/libbacktrace/Makefile.am
*************** f85ce0eb8f8613b9ca3c5eaee59ae62e  libstd
*** 116512,116522 ****
  36b67ad86ea801dc337f0d54fe42b2ac  libstdc++-v3/testsuite/20_util/pair/astuple/constexpr_get_by_type.cc
  f2f2b91309730f195c55679493733944  libstdc++-v3/testsuite/20_util/pair/astuple/get-2.cc
  82db2025a4d299eba41e5c05e9db4754  libstdc++-v3/testsuite/20_util/pair/astuple/get.cc
! 44cb72be0132169cc67167c6f46d3121  libstdc++-v3/testsuite/20_util/pair/astuple/get_by_type.cc
  00b514e9ef49c58e9e95575a0ea7f4b9  libstdc++-v3/testsuite/20_util/pair/astuple/get_by_type_neg.cc
  48940b90d447509433832bad389182bf  libstdc++-v3/testsuite/20_util/pair/astuple/get_neg.cc
  ec618870c1f0079db86b80616f28ce73  libstdc++-v3/testsuite/20_util/pair/comparison_operators/constexpr.cc
  28c1f9f768fed1fd3801d2bd6b7e363a  libstdc++-v3/testsuite/20_util/pair/comparison_operators/constexpr_c++20.cc
  3f110cfd7485de1ab2b675c801318cf6  libstdc++-v3/testsuite/20_util/pair/cons/92878_92947.cc
  c5964cf74c99c86ce570bfdb15835bb8  libstdc++-v3/testsuite/20_util/pair/cons/99957.cc
  1dc6da744a411e2a03d603b4b5f085d3  libstdc++-v3/testsuite/20_util/pair/cons/constexpr.cc
--- 116766,116777 ----
  36b67ad86ea801dc337f0d54fe42b2ac  libstdc++-v3/testsuite/20_util/pair/astuple/constexpr_get_by_type.cc
  f2f2b91309730f195c55679493733944  libstdc++-v3/testsuite/20_util/pair/astuple/get-2.cc
  82db2025a4d299eba41e5c05e9db4754  libstdc++-v3/testsuite/20_util/pair/astuple/get.cc
! df8fdd5d5bd3928dec41493458c927a5  libstdc++-v3/testsuite/20_util/pair/astuple/get_by_type.cc
  00b514e9ef49c58e9e95575a0ea7f4b9  libstdc++-v3/testsuite/20_util/pair/astuple/get_by_type_neg.cc
  48940b90d447509433832bad389182bf  libstdc++-v3/testsuite/20_util/pair/astuple/get_neg.cc
  ec618870c1f0079db86b80616f28ce73  libstdc++-v3/testsuite/20_util/pair/comparison_operators/constexpr.cc
  28c1f9f768fed1fd3801d2bd6b7e363a  libstdc++-v3/testsuite/20_util/pair/comparison_operators/constexpr_c++20.cc
+ de22916c6d33b4376c80895f09fe7345  libstdc++-v3/testsuite/20_util/pair/cons/110853.cc
  3f110cfd7485de1ab2b675c801318cf6  libstdc++-v3/testsuite/20_util/pair/cons/92878_92947.cc
  c5964cf74c99c86ce570bfdb15835bb8  libstdc++-v3/testsuite/20_util/pair/cons/99957.cc
  1dc6da744a411e2a03d603b4b5f085d3  libstdc++-v3/testsuite/20_util/pair/cons/constexpr.cc
*************** a54664d62954ab2649e6aa8c09a2a87c  libstd
*** 116747,116753 ****
  8918180e68742cf67fb91de83bdeda09  libstdc++-v3/testsuite/20_util/shared_ptr/observers/owner_before.cc
  d8b105856e6a3f411dcde3c993534970  libstdc++-v3/testsuite/20_util/shared_ptr/observers/unique.cc
  028cce135beddf6da08f9db75918ea20  libstdc++-v3/testsuite/20_util/shared_ptr/observers/use_count.cc
! 565b34e5163e6a1e5b24a81b53e3ad9d  libstdc++-v3/testsuite/20_util/shared_ptr/requirements/explicit_instantiation/1.cc
  5b56506b9bd6c8a882702360efaa172b  libstdc++-v3/testsuite/20_util/shared_ptr/requirements/explicit_instantiation/2.cc
  5df2437456d5a6883be7e5f3d8b89ea5  libstdc++-v3/testsuite/20_util/shared_ptr/requirements/weak_type.cc
  f977c7ffc1890ee3239a73e5a016d36d  libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc
--- 117002,117009 ----
  8918180e68742cf67fb91de83bdeda09  libstdc++-v3/testsuite/20_util/shared_ptr/observers/owner_before.cc
  d8b105856e6a3f411dcde3c993534970  libstdc++-v3/testsuite/20_util/shared_ptr/observers/unique.cc
  028cce135beddf6da08f9db75918ea20  libstdc++-v3/testsuite/20_util/shared_ptr/observers/use_count.cc
! 549b70e5de4de4416498a203f84f2f0c  libstdc++-v3/testsuite/20_util/shared_ptr/requirements/1.cc
! 170d176a30a056cf3718a5c9f393c10a  libstdc++-v3/testsuite/20_util/shared_ptr/requirements/explicit_instantiation/1.cc
  5b56506b9bd6c8a882702360efaa172b  libstdc++-v3/testsuite/20_util/shared_ptr/requirements/explicit_instantiation/2.cc
  5df2437456d5a6883be7e5f3d8b89ea5  libstdc++-v3/testsuite/20_util/shared_ptr/requirements/weak_type.cc
  f977c7ffc1890ee3239a73e5a016d36d  libstdc++-v3/testsuite/20_util/shared_ptr/thread/default_weaktoshared.cc
*************** d6bc384ca66ff3fdd05e0b2371122457  libstd
*** 116757,116763 ****
  227931069351de891d63e6a0ce09cf3a  libstdc++-v3/testsuite/20_util/specialized_algorithms/construct_at/95788.cc
  13432f208160f26ba0e05a30f46f88f0  libstdc++-v3/testsuite/20_util/specialized_algorithms/destroy/constrained.cc
  307ed30ab86d3f9f310f22ef029e832e  libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/1.cc
! 0695e76e14d0d1b7c0729b84e8e85149  libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc
  7e2d819342973c849d87437556e29d5c  libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_construct.cc
  681f3ec9c3b800b4e5258afc87a95231  libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc
  7377989805a8e1aa7f8896037d2eefae  libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_fill_destroy.cc
--- 117013,117020 ----
  227931069351de891d63e6a0ce09cf3a  libstdc++-v3/testsuite/20_util/specialized_algorithms/construct_at/95788.cc
  13432f208160f26ba0e05a30f46f88f0  libstdc++-v3/testsuite/20_util/specialized_algorithms/destroy/constrained.cc
  307ed30ab86d3f9f310f22ef029e832e  libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/1.cc
! 3d215c86194df15b75fdf87c57f36962  libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_n_neg.cc
! 060089834fae7f70e97089bd874bfd08  libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc
  7e2d819342973c849d87437556e29d5c  libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_construct.cc
  681f3ec9c3b800b4e5258afc87a95231  libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc
  7377989805a8e1aa7f8896037d2eefae  libstdc++-v3/testsuite/20_util/specialized_algorithms/pstl/uninitialized_fill_destroy.cc
*************** fced6aef1c90b8200f7966d8fc0d1e2b  libstd
*** 116798,116803 ****
--- 117055,117061 ----
  23c56fdbc29d5022809523814c5efbb7  libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/94540.cc
  14b31098d096d0fc451958711491a982  libstdc++-v3/testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/sizes.cc
  a7c2ab37c69a57274f01d9c1c0925d2b  libstdc++-v3/testsuite/20_util/steady_clock/constexpr_data.cc
+ 309b7ad3662d6e3be2a1afeaaef39c0e  libstdc++-v3/testsuite/20_util/synchronized_pool_resource/118681.cc
  e01bbbdabdcc05d3ec7cd1288920cb0b  libstdc++-v3/testsuite/20_util/synchronized_pool_resource/allocate.cc
  8cb654edf02f6707a3f06925f75baeaf  libstdc++-v3/testsuite/20_util/synchronized_pool_resource/allocate_single.cc
  3ec8a2fc64cb64aa1082ab02188507a8  libstdc++-v3/testsuite/20_util/synchronized_pool_resource/cons.cc
*************** bd7b1df14e0242e5cc6bb963a8caf000  libstd
*** 116808,116813 ****
--- 117066,117072 ----
  7c4cbea59e0d8fa4d2479c9e8494c9ff  libstdc++-v3/testsuite/20_util/synchronized_pool_resource/release.cc
  12bde2861fe41d383cbc8aa9c4cac9fd  libstdc++-v3/testsuite/20_util/synchronized_pool_resource/release_single.cc
  5307895572f0fc61ec27f7a5d657f483  libstdc++-v3/testsuite/20_util/system_clock/1.cc
+ e35adc34ffc9e022a7b41fe2c88640fb  libstdc++-v3/testsuite/20_util/system_clock/99832.cc
  6292b64c03c25ef42b661d0c57d13bdd  libstdc++-v3/testsuite/20_util/system_clock/constexpr_data.cc
  32bc098b843d29bdcae3ff1441d6e005  libstdc++-v3/testsuite/20_util/temporary_buffer.cc
  c1c191bc9337a174e6159bb8834f26a7  libstdc++-v3/testsuite/20_util/time_point/1.cc
*************** ccb35fb7a62300af936085819483975c  libstd
*** 116871,116876 ****
--- 117130,117136 ----
  d23b1a747046dfeaadefce18d2c02b12  libstdc++-v3/testsuite/20_util/tuple/cons/101960.cc
  32c154912a091023741fdaa263538a86  libstdc++-v3/testsuite/20_util/tuple/cons/102270.cc
  9a6dc1f9548e126de2581231c632a19f  libstdc++-v3/testsuite/20_util/tuple/cons/114147.cc
+ acc813dd1edb9480437149d28cd4faf0  libstdc++-v3/testsuite/20_util/tuple/cons/121771.cc
  f27dfd667d19d5a586e2805084cc1c5a  libstdc++-v3/testsuite/20_util/tuple/cons/41530.cc
  c5d05d77429ce4ba3914543541b3764e  libstdc++-v3/testsuite/20_util/tuple/cons/44487.cc
  45938586f3445d3925b645ab2e912816  libstdc++-v3/testsuite/20_util/tuple/cons/45228.cc
*************** b06d4bee43487cb46ceadf7135cb4db5  libstd
*** 117015,117020 ****
--- 117275,117281 ----
  fc63665747e3ea8f7fba3bd2b8231ddb  libstdc++-v3/testsuite/20_util/unique_ptr/specialized_algorithms/swap_cxx17.cc
  79ae7324ed01aba2f0a26aa803be147c  libstdc++-v3/testsuite/20_util/unreachable/1.cc
  39e33d60fe45843188bb85ba28c7f355  libstdc++-v3/testsuite/20_util/unreachable/version.cc
+ e71310aab27f8280547a5f500ddfc531  libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/118681.cc
  6cdad804e564520c37e1afc56cab7f5b  libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate-max-chunks.cc
  304b459dc12bebfddf1f302c0d20acf8  libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/allocate.cc
  e146873cfa2a56eb95438a7e5f8ae879  libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/cons.cc
*************** b53ced7be024099d627a420130ddfae8  libstd
*** 117074,117080 ****
  6b897d033cb55ff130e351833c656265  libstdc++-v3/testsuite/20_util/weak_ptr/cons/self_move.cc
  b246d8f6e64c2116455b4dd4f1f8d8a5  libstdc++-v3/testsuite/20_util/weak_ptr/lock/1.cc
  717e4469de743d17c7df0a72edddf518  libstdc++-v3/testsuite/20_util/weak_ptr/observers/owner_before.cc
! e3fe5ffa6e73649a9f21bc27604fa67e  libstdc++-v3/testsuite/20_util/weak_ptr/requirements/explicit_instantiation/1.cc
  54d858067f0b4d5586a96694db21335d  libstdc++-v3/testsuite/20_util/weak_ptr/requirements/explicit_instantiation/2.cc
  5a245092d50fbff80c427ac99d035c64  libstdc++-v3/testsuite/21_strings/basic_string/40160.cc
  b6e891619cb7e448b49abc63a8ea5d5e  libstdc++-v3/testsuite/21_strings/basic_string/56166.cc
--- 117335,117342 ----
  6b897d033cb55ff130e351833c656265  libstdc++-v3/testsuite/20_util/weak_ptr/cons/self_move.cc
  b246d8f6e64c2116455b4dd4f1f8d8a5  libstdc++-v3/testsuite/20_util/weak_ptr/lock/1.cc
  717e4469de743d17c7df0a72edddf518  libstdc++-v3/testsuite/20_util/weak_ptr/observers/owner_before.cc
! 5932ad1030d5abe0125342125560f5b2  libstdc++-v3/testsuite/20_util/weak_ptr/requirements/1.cc
! 2ef2623d0703aefa06333b8e1093f2fb  libstdc++-v3/testsuite/20_util/weak_ptr/requirements/explicit_instantiation/1.cc
  54d858067f0b4d5586a96694db21335d  libstdc++-v3/testsuite/20_util/weak_ptr/requirements/explicit_instantiation/2.cc
  5a245092d50fbff80c427ac99d035c64  libstdc++-v3/testsuite/21_strings/basic_string/40160.cc
  b6e891619cb7e448b49abc63a8ea5d5e  libstdc++-v3/testsuite/21_strings/basic_string/56166.cc
*************** fbc6650336935a3df653043ccd1f83a2  libstd
*** 117285,117294 ****
--- 117547,117558 ----
  a246493248782db6f36668ae289a3451  libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/wchar_t/stoull.cc
  baf8c9f546b7737cdb576bce7b283486  libstdc++-v3/testsuite/21_strings/basic_string/numeric_conversions/wchar_t/to_wstring.cc
  0c824132f07dd1ab74199f3b2d01ac67  libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/1.cc
+ c24c0e6f49ab658726699f1007f123b4  libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/123991.cc
  5411d35d28c144d53fad3bfecd4d78eb  libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/13650.cc
  a3e06e8d0e373199c662ae08b6a473c6  libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/2.cc
  bd5d27b6c1da7f4be96a036ee98cfdc7  libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/3.cc
  52cf6d72521f757bfd4e167ebcaa9702  libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/wchar_t/1.cc
+ ec53bc1685fb080b40ba203340985256  libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/wchar_t/123991.cc
  b342297140022db104d8a7e9314eaba7  libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/wchar_t/13650.cc
  ba9327af72c6d0e0d7bd3784fd5f2a8e  libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/wchar_t/2.cc
  93f87f1a0b3ba768472cc8db84a95184  libstdc++-v3/testsuite/21_strings/basic_string/operations/contains/char.cc
*************** c0e3faee3730a602e20eb2371cab4609  libstd
*** 117593,117598 ****
--- 117857,117863 ----
  4395d337731f3acdedd84cecc15c82b5  libstdc++-v3/testsuite/22_locale/codecvt/length/char/wrapped_env.cc
  c0e3faee3730a602e20eb2371cab4609  libstdc++-v3/testsuite/22_locale/codecvt/length/char/wrapped_locale.cc
  cc133e010fcec429e0ed8c3d45381ea1  libstdc++-v3/testsuite/22_locale/codecvt/length/wchar_t/1.cc
+ d1962df70f021ebd3de8499b1b388c4e  libstdc++-v3/testsuite/22_locale/codecvt/length/wchar_t/105857.cc
  db5451522f9a1cbddbd048f0a329642e  libstdc++-v3/testsuite/22_locale/codecvt/length/wchar_t/2.cc
  a17dff2c0511c57be6c2b17558a024a5  libstdc++-v3/testsuite/22_locale/codecvt/length/wchar_t/3.cc
  c913eb5a9f6543f72a184aee236f7fdc  libstdc++-v3/testsuite/22_locale/codecvt/length/wchar_t/4.cc
*************** c1c67b7f0cdd8a4e08ccb5f1c47684d4  libstd
*** 118397,118402 ****
--- 118662,118668 ----
  9f32ca6f0a5bc2f373d834b141e33c11  libstdc++-v3/testsuite/23_containers/forward_list/debug/swap.cc
  ffad374cf7ee755cfefd656ab0e265d2  libstdc++-v3/testsuite/23_containers/forward_list/erasure.cc
  3d729b39a39f38eeb3bb2e0215082778  libstdc++-v3/testsuite/23_containers/forward_list/modifiers/1.cc
+ 6bcb325735429aba259858615ce5626d  libstdc++-v3/testsuite/23_containers/forward_list/modifiers/122661.cc
  53165a1f8a0bc90aa9a98a98f6c3fce1  libstdc++-v3/testsuite/23_containers/forward_list/modifiers/2.cc
  921bfaa93cd79b819d72430ef8eaf8ad  libstdc++-v3/testsuite/23_containers/forward_list/modifiers/3.cc
  4801ba53c46f4f392e9b499134be960f  libstdc++-v3/testsuite/23_containers/forward_list/modifiers/4.cc
*************** f750de8f7a7b9f522f1d20e2d7b1c24b  libstd
*** 118838,118843 ****
--- 119104,119110 ----
  83fbed2c29ae3d0412c684b7c70a428c  libstdc++-v3/testsuite/23_containers/multiset/requirements/explicit_instantiation/5.cc
  dda5d6f1c5182a1b581a45ec2d4bc71c  libstdc++-v3/testsuite/23_containers/multiset/requirements/partial_specialization/1.cc
  95eade5bc721f08b1dd1d74efb06e211  libstdc++-v3/testsuite/23_containers/multiset/requirements/typedefs.cc
+ c2def03f80594fdacabf96a3fe28473a  libstdc++-v3/testsuite/23_containers/priority_queue/118088.cc
  67f73d3809efd5946ecf4de7a8538042  libstdc++-v3/testsuite/23_containers/priority_queue/67085.cc
  55e1b3aaddbbda2b023958a8dc2ddcb4  libstdc++-v3/testsuite/23_containers/priority_queue/77528.cc
  95f7ba6a7e6c8dace2c3383d38968f2a  libstdc++-v3/testsuite/23_containers/priority_queue/92878_92947.cc
*************** a6306b96109e4ac88fec3e48390ea520  libstd
*** 119535,119542 ****
  1ce2272844a9da337ee743c345bec85b  libstdc++-v3/testsuite/23_containers/vector/cons/constexpr.cc
  46f0c2a0b0960e4576e3270d26769808  libstdc++-v3/testsuite/23_containers/vector/cons/deduction.cc
  7a66bf7f5aca27ddc8ca203f2f55a9b6  libstdc++-v3/testsuite/23_containers/vector/cons/destroy-adl.cc
! dac5f3f9aadcf745fb603c739588aaa2  libstdc++-v3/testsuite/23_containers/vector/cons/destructible_debug_neg.cc
! f7bab4eab1d2bc6e522c4cb05878163e  libstdc++-v3/testsuite/23_containers/vector/cons/destructible_neg.cc
  5893577535f0a3d5bb18f37b6f785f5f  libstdc++-v3/testsuite/23_containers/vector/cons/moveable.cc
  b59054fb1d00091880d5605b974fa84c  libstdc++-v3/testsuite/23_containers/vector/cons/moveable2.cc
  43e21483e0953a254bd6139216fbe169  libstdc++-v3/testsuite/23_containers/vector/cons/noexcept_move_construct.cc
--- 119802,119809 ----
  1ce2272844a9da337ee743c345bec85b  libstdc++-v3/testsuite/23_containers/vector/cons/constexpr.cc
  46f0c2a0b0960e4576e3270d26769808  libstdc++-v3/testsuite/23_containers/vector/cons/deduction.cc
  7a66bf7f5aca27ddc8ca203f2f55a9b6  libstdc++-v3/testsuite/23_containers/vector/cons/destroy-adl.cc
! dbe19cc4c612d2abc999f18b0a66ac1c  libstdc++-v3/testsuite/23_containers/vector/cons/destructible_debug_neg.cc
! 5cb19c9b91d8d7eb22c067703b17e02c  libstdc++-v3/testsuite/23_containers/vector/cons/destructible_neg.cc
  5893577535f0a3d5bb18f37b6f785f5f  libstdc++-v3/testsuite/23_containers/vector/cons/moveable.cc
  b59054fb1d00091880d5605b974fa84c  libstdc++-v3/testsuite/23_containers/vector/cons/moveable2.cc
  43e21483e0953a254bd6139216fbe169  libstdc++-v3/testsuite/23_containers/vector/cons/noexcept_move_construct.cc
*************** bd380b2e874bfa2f8d63461b8f4a8add  libstd
*** 119615,119626 ****
  e237c5e34318ddc293afe0b0a6b36839  libstdc++-v3/testsuite/23_containers/vector/modifiers/insert/const_iterator.cc
  6e313c2420fa6f17886b2f672615f35f  libstdc++-v3/testsuite/23_containers/vector/modifiers/insert/self_insert.cc
  8fb5c601f412e71f5977219b7d89f18d  libstdc++-v3/testsuite/23_containers/vector/modifiers/insert_vs_emplace.cc
! fb16ee13d327a03c0452886cb723080d  libstdc++-v3/testsuite/23_containers/vector/modifiers/moveable.cc
  2f94f2f6c98e2efb2516ee180e3c55cb  libstdc++-v3/testsuite/23_containers/vector/modifiers/moveable2.cc
  f2b0284e80897ac080e298ee2edcc668  libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/49836.cc
  f13928764ad3413456ecdcac841cb955  libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/89130.cc
  5eb0636a0c51ba2e30c2f690ac8a27a4  libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/89416.cc
  22c8466b6a562e32f263f77f51560a72  libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/strong_guarantee.cc
  ceb73179b5ae4a668be768d817a05306  libstdc++-v3/testsuite/23_containers/vector/modifiers/swap/1.cc
  99b732b3220a41435951237657f89f63  libstdc++-v3/testsuite/23_containers/vector/modifiers/swap/2.cc
  8c650c34bec586db18c252282a5b2f72  libstdc++-v3/testsuite/23_containers/vector/modifiers/swap/3.cc
--- 119882,119894 ----
  e237c5e34318ddc293afe0b0a6b36839  libstdc++-v3/testsuite/23_containers/vector/modifiers/insert/const_iterator.cc
  6e313c2420fa6f17886b2f672615f35f  libstdc++-v3/testsuite/23_containers/vector/modifiers/insert/self_insert.cc
  8fb5c601f412e71f5977219b7d89f18d  libstdc++-v3/testsuite/23_containers/vector/modifiers/insert_vs_emplace.cc
! cab62aa446a5d7fd10db4244f6acf11d  libstdc++-v3/testsuite/23_containers/vector/modifiers/moveable.cc
  2f94f2f6c98e2efb2516ee180e3c55cb  libstdc++-v3/testsuite/23_containers/vector/modifiers/moveable2.cc
  f2b0284e80897ac080e298ee2edcc668  libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/49836.cc
  f13928764ad3413456ecdcac841cb955  libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/89130.cc
  5eb0636a0c51ba2e30c2f690ac8a27a4  libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/89416.cc
  22c8466b6a562e32f263f77f51560a72  libstdc++-v3/testsuite/23_containers/vector/modifiers/push_back/strong_guarantee.cc
+ 4a2f9f9e84018ea58dae284a14d839cd  libstdc++-v3/testsuite/23_containers/vector/modifiers/resize.cc
  ceb73179b5ae4a668be768d817a05306  libstdc++-v3/testsuite/23_containers/vector/modifiers/swap/1.cc
  99b732b3220a41435951237657f89f63  libstdc++-v3/testsuite/23_containers/vector/modifiers/swap/2.cc
  8c650c34bec586db18c252282a5b2f72  libstdc++-v3/testsuite/23_containers/vector/modifiers/swap/3.cc
*************** ed715a19eb62e470d1e8f47b0582b91e  libstd
*** 119719,119724 ****
--- 119987,119993 ----
  722fba5f66f393206764e6edb77ae51c  libstdc++-v3/testsuite/24_iterators/istream_iterator/requirements/explicit_instantiation.cc
  2d00e7f6ff4ba9e992b66a109d3209d2  libstdc++-v3/testsuite/24_iterators/istream_iterator/requirements/typedefs.cc
  82c2d1d6580a4b91c73034088080b212  libstdc++-v3/testsuite/24_iterators/istream_iterator/sentinel.cc
+ 486fa49e6e6487aad2e12a66d481a54c  libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/105580.cc
  7d12f077ff566bf32795441b77385f39  libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/2.cc
  62b6026aea56196b31df1c4191fa355f  libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/2627.cc
  d11769fe782ae211668b3927ebbc8271  libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/92285.cc
*************** fa24f7699d54865dec7259a08c7e4662  libstd
*** 120110,120116 ****
  acd5a7a2a15e0073569cdcc1245a020a  libstdc++-v3/testsuite/25_algorithms/is_permutation/check_type.cc
  94407288af818238e1963bfcf113c01a  libstdc++-v3/testsuite/25_algorithms/is_permutation/check_type2.cc
  bf0457e064b412e5321cb7abdedce454  libstdc++-v3/testsuite/25_algorithms/is_permutation/constexpr.cc
! b3df349844f402ddf2da56ca74458ba0  libstdc++-v3/testsuite/25_algorithms/is_permutation/constrained.cc
  9f05872e16a9f4efd4f8c5fbd07d562e  libstdc++-v3/testsuite/25_algorithms/is_permutation/requirements/explicit_instantiation/2.cc
  510e0094c5b2a140bae991c8303d8105  libstdc++-v3/testsuite/25_algorithms/is_permutation/requirements/explicit_instantiation/pod.cc
  169c1bd417ce688fdcd66fb419b3f9ab  libstdc++-v3/testsuite/25_algorithms/is_permutation/vectorbool.cc
--- 120379,120385 ----
  acd5a7a2a15e0073569cdcc1245a020a  libstdc++-v3/testsuite/25_algorithms/is_permutation/check_type.cc
  94407288af818238e1963bfcf113c01a  libstdc++-v3/testsuite/25_algorithms/is_permutation/check_type2.cc
  bf0457e064b412e5321cb7abdedce454  libstdc++-v3/testsuite/25_algorithms/is_permutation/constexpr.cc
! c39ab642a7d59f8c830fc1dd8f6ab378  libstdc++-v3/testsuite/25_algorithms/is_permutation/constrained.cc
  9f05872e16a9f4efd4f8c5fbd07d562e  libstdc++-v3/testsuite/25_algorithms/is_permutation/requirements/explicit_instantiation/2.cc
  510e0094c5b2a140bae991c8303d8105  libstdc++-v3/testsuite/25_algorithms/is_permutation/requirements/explicit_instantiation/pod.cc
  169c1bd417ce688fdcd66fb419b3f9ab  libstdc++-v3/testsuite/25_algorithms/is_permutation/vectorbool.cc
*************** c8e019417514e0aaf8303174ef0dd447  libstd
*** 120403,120408 ****
--- 120672,120678 ----
  7aec30c3e549bbc97112b84ca3ac4b85  libstdc++-v3/testsuite/25_algorithms/remove_copy_if/requirements/explicit_instantiation/2.cc
  cfd5677b094cacad86414fbf80178e71  libstdc++-v3/testsuite/25_algorithms/remove_copy_if/requirements/explicit_instantiation/pod.cc
  d7a8655c57e1bb6fe36bb4bcfebfb9ff  libstdc++-v3/testsuite/25_algorithms/remove_if/1.cc
+ 22e4da064ddab0c392673bb1bf3caaed  libstdc++-v3/testsuite/25_algorithms/remove_if/120789.cc
  722e27245847e91857d7e1688c69cd09  libstdc++-v3/testsuite/25_algorithms/remove_if/check_type.cc
  cb06372666dd722ec6c9bd8b7149b229  libstdc++-v3/testsuite/25_algorithms/remove_if/constexpr.cc
  0fbe2172f33b52e0496d6fdff0f0469f  libstdc++-v3/testsuite/25_algorithms/remove_if/constrained.cc
*************** ba592b284f6d2e508b60e76de25145aa  libstd
*** 120567,120572 ****
--- 120837,120843 ----
  703cb5226307aa45aa88ccbda0d4326a  libstdc++-v3/testsuite/25_algorithms/transform/requirements/explicit_instantiation/pod.cc
  a1865c601f9b9e4047af8a04408cfbc8  libstdc++-v3/testsuite/25_algorithms/unique/1.cc
  2b8ba383c0662d2fd3360201c3819551  libstdc++-v3/testsuite/25_algorithms/unique/11480.cc
+ 12ee07b6e724d84c83471a929de6054c  libstdc++-v3/testsuite/25_algorithms/unique/120789.cc
  d8412fa15e8cd756cab25c277d70c2a3  libstdc++-v3/testsuite/25_algorithms/unique/2.cc
  b794dd587e857350501af574115a867d  libstdc++-v3/testsuite/25_algorithms/unique/constexpr.cc
  a965812055fc5259d046624d0945cd7f  libstdc++-v3/testsuite/25_algorithms/unique/constrained.cc
*************** b8939124765ab9270338e83358b3ac2b  libstd
*** 121888,121893 ****
--- 122159,122165 ----
  c208c8de494bf32d878da5e4c9b204af  libstdc++-v3/testsuite/27_io/basic_stringbuf/sputn/wchar_t/1057.cc
  ca62659f7a645bedde2eca769be9962a  libstdc++-v3/testsuite/27_io/basic_stringbuf/sputn/wchar_t/9404-2.cc
  8622720c9345ba21912feea8824bdc15  libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char/1.cc
+ 977a013f60bef4a12b598777d9f03bd4  libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char/123100.cc
  336990ae2489df97e50305d0ed3f7c27  libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char/2.cc
  4b0f93f8b1f2c857573d6de9b3ff2517  libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char/3.cc
  5ca6a228218b7685c57f8087d179c4b3  libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char/3955.cc
*************** aa12f3ad5d07760fdef4c7f8339e1ea7  libstd
*** 121976,121982 ****
  0c6c07a9c9dbccc7719497b85201d9a6  libstdc++-v3/testsuite/27_io/filesystem/operations/relative.cc
  128c6f5ee47456ecc936373f2f323f1b  libstdc++-v3/testsuite/27_io/filesystem/operations/remove.cc
  42594b5cbf9a6ffadf5b6cb9b0895ce1  libstdc++-v3/testsuite/27_io/filesystem/operations/remove_all.cc
! 3ab7106fa9baea760ffb1735f2edbdd1  libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
  93258c1d01aa8dc2bfecf035e136dbca  libstdc++-v3/testsuite/27_io/filesystem/operations/resize_file.cc
  3faa5845a51c8d6c5755eed607cc8697  libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
  9f4e4355672050d1fd8eb5a7524deeb4  libstdc++-v3/testsuite/27_io/filesystem/operations/status.cc
--- 122248,122254 ----
  0c6c07a9c9dbccc7719497b85201d9a6  libstdc++-v3/testsuite/27_io/filesystem/operations/relative.cc
  128c6f5ee47456ecc936373f2f323f1b  libstdc++-v3/testsuite/27_io/filesystem/operations/remove.cc
  42594b5cbf9a6ffadf5b6cb9b0895ce1  libstdc++-v3/testsuite/27_io/filesystem/operations/remove_all.cc
! fae7fb9e8ecbd9ff2d620c12bcd466f4  libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc
  93258c1d01aa8dc2bfecf035e136dbca  libstdc++-v3/testsuite/27_io/filesystem/operations/resize_file.cc
  3faa5845a51c8d6c5755eed607cc8697  libstdc++-v3/testsuite/27_io/filesystem/operations/space.cc
  9f4e4355672050d1fd8eb5a7524deeb4  libstdc++-v3/testsuite/27_io/filesystem/operations/status.cc
*************** adc6839881d66900bdb4afec1183fee6  libstd
*** 121992,121997 ****
--- 122264,122270 ----
  76d9cd4f874777f208df909f580d633b  libstdc++-v3/testsuite/27_io/filesystem/path/compare/lwg2936.cc
  f96fd6968fd5dc0a924d195a63fd0f01  libstdc++-v3/testsuite/27_io/filesystem/path/compare/path.cc
  71dece1f73b5dfe83d3feeccea213e26  libstdc++-v3/testsuite/27_io/filesystem/path/compare/strings.cc
+ 9b500ed50c013cdbd0290f1d06786f83  libstdc++-v3/testsuite/27_io/filesystem/path/concat/120029.cc
  645545a2827964059e41fbf8a38f3610  libstdc++-v3/testsuite/27_io/filesystem/path/concat/92853.cc
  08d3a01e742eaf2deea882236be3a404  libstdc++-v3/testsuite/27_io/filesystem/path/concat/94063.cc
  b9c63e25d0a6079a7198ceb1e34281aa  libstdc++-v3/testsuite/27_io/filesystem/path/concat/path.cc
*************** b715c45a6677f269807dab0bbcf0ee1d  libstd
*** 122248,122253 ****
--- 122521,122527 ----
  4efed1789a62f6991adff97279bcd1f4  libstdc++-v3/testsuite/27_io/rvalue_streams-2.cc
  d1dfe55fd3a5885b95cd86dc0498bee0  libstdc++-v3/testsuite/27_io/rvalue_streams.cc
  fe40135327d86460d13b734f54db39ec  libstdc++-v3/testsuite/27_io/spanstream/1.cc
+ 3594f52a64f56373d233b505e211d1ba  libstdc++-v3/testsuite/27_io/spanstream/127006.cc
  44feabe2b97157af832bd4b647727182  libstdc++-v3/testsuite/27_io/spanstream/2.cc
  54572175dfa1a1c5dd980cde76230006  libstdc++-v3/testsuite/27_io/spanstream/version.cc
  900d1a060a2d7ff7077bef529057baa5  libstdc++-v3/testsuite/27_io/types/1.cc
*************** bb1893529216ccfd448782acac5863b8  libstd
*** 122434,122440 ****
  f1800adc0fc13bc4af222b5b2c2667e7  libstdc++-v3/testsuite/29_atomics/atomic/69301.cc
  bac63bc83699602fe139dbfa683b9402  libstdc++-v3/testsuite/29_atomics/atomic/69769.cc
  fa7c4f369fca094c91b1defc0937aa75  libstdc++-v3/testsuite/29_atomics/atomic/70766.cc
! 9c61550b8e13eb861b1192f9d1f53323  libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
  fc6d3820caef39ab514f64ef5ba6f4a3  libstdc++-v3/testsuite/29_atomics/atomic/cons/49445.cc
  bb4c8750d06e6cbcf2c116c8d2fdd3d1  libstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc
  79087b369afb5044402aed88e633298f  libstdc++-v3/testsuite/29_atomics/atomic/cons/constexpr.cc
--- 122708,122714 ----
  f1800adc0fc13bc4af222b5b2c2667e7  libstdc++-v3/testsuite/29_atomics/atomic/69301.cc
  bac63bc83699602fe139dbfa683b9402  libstdc++-v3/testsuite/29_atomics/atomic/69769.cc
  fa7c4f369fca094c91b1defc0937aa75  libstdc++-v3/testsuite/29_atomics/atomic/70766.cc
! 97d31d0960e3386926d4c8eac3174365  libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc
  fc6d3820caef39ab514f64ef5ba6f4a3  libstdc++-v3/testsuite/29_atomics/atomic/cons/49445.cc
  bb4c8750d06e6cbcf2c116c8d2fdd3d1  libstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc
  79087b369afb5044402aed88e633298f  libstdc++-v3/testsuite/29_atomics/atomic/cons/constexpr.cc
*************** bb4c8750d06e6cbcf2c116c8d2fdd3d1  libstd
*** 122445,122450 ****
--- 122719,122725 ----
  4251989d2e19682c01faed5c294409d4  libstdc++-v3/testsuite/29_atomics/atomic/cons/single_value.cc
  b3d7e6cfe8b8bd01758e4c07a4c28005  libstdc++-v3/testsuite/29_atomics/atomic/cons/user_pod.cc
  74c43187a818b684f8f265cb91a41448  libstdc++-v3/testsuite/29_atomics/atomic/cons/value_init.cc
+ 822ec88a7f5dfe8ce7d354c55824d6bb  libstdc++-v3/testsuite/29_atomics/atomic/cons/zero_padding.cc
  cbcc81eb663d244bc37286ed070abed1  libstdc++-v3/testsuite/29_atomics/atomic/is_always_lock_free.cc
  1405fe779f482abe4dfd50e50b9f6d04  libstdc++-v3/testsuite/29_atomics/atomic/lock_free_aliases.cc
  b098b856e7a62fed0201c9aa38383951  libstdc++-v3/testsuite/29_atomics/atomic/lwg3220.cc
*************** ff7443140f86745a2541bdb67674b537  libstd
*** 122986,122992 ****
  c597972e3e8cd6262fd847bc2867ee05  libstdc++-v3/testsuite/backward/hash_set/1.cc
  a34de0d8d7e82a11a5ac26aca9679cf7  libstdc++-v3/testsuite/backward/hash_set/25896.cc
  2c091597008357e678007f407f299a24  libstdc++-v3/testsuite/backward/hash_set/49060.cc
! b50f7b321b2fe24b18a96f6cb90be514  libstdc++-v3/testsuite/backward/hash_set/check_construct_destroy.cc
  d7e0c3a740f84a38fc897d2c79e82d54  libstdc++-v3/testsuite/backward/hash_set/requirements/explicit_instantiation.cc
  2db761d7855449f6ec325d0f85bd6702  libstdc++-v3/testsuite/backward/strstream_members.cc
  264b9e706c4036face402ab9b63e8259  libstdc++-v3/testsuite/backward/strstream_move.cc
--- 123261,123267 ----
  c597972e3e8cd6262fd847bc2867ee05  libstdc++-v3/testsuite/backward/hash_set/1.cc
  a34de0d8d7e82a11a5ac26aca9679cf7  libstdc++-v3/testsuite/backward/hash_set/25896.cc
  2c091597008357e678007f407f299a24  libstdc++-v3/testsuite/backward/hash_set/49060.cc
! f881eec22dae4db8175ab9b9a82b804e  libstdc++-v3/testsuite/backward/hash_set/check_construct_destroy.cc
  d7e0c3a740f84a38fc897d2c79e82d54  libstdc++-v3/testsuite/backward/hash_set/requirements/explicit_instantiation.cc
  2db761d7855449f6ec325d0f85bd6702  libstdc++-v3/testsuite/backward/strstream_members.cc
  264b9e706c4036face402ab9b63e8259  libstdc++-v3/testsuite/backward/strstream_move.cc
*************** b98948c551bee5cc7d9c094747ddba4a  libstd
*** 123125,123130 ****
--- 123400,123406 ----
  7a96d873382d822fd330b3b81ce412c1  libstdc++-v3/testsuite/experimental/filesystem/path/compare/compare.cc
  9781d2ddc7dcd407841d5aa8e364b349  libstdc++-v3/testsuite/experimental/filesystem/path/compare/path.cc
  751386fe94f215b9517c877cdc28e958  libstdc++-v3/testsuite/experimental/filesystem/path/compare/strings.cc
+ 83f8a63ee6afbdafe75f08d3ab59ded7  libstdc++-v3/testsuite/experimental/filesystem/path/concat/120029.cc
  918b69aab461293cc241390a9b1479dc  libstdc++-v3/testsuite/experimental/filesystem/path/concat/path.cc
  1b7d15b79bbcf73d77ef62f090e14db4  libstdc++-v3/testsuite/experimental/filesystem/path/concat/strings.cc
  c06b01e19066f0d4ffa4faa5202f4e3e  libstdc++-v3/testsuite/experimental/filesystem/path/construct/100630.cc
*************** c4026a6d0520e4329e27fe92fdd65a86  libstd
*** 124105,124111 ****
  5477cf5cf0d83c16c3641c1ba9a1fca9  libstdc++-v3/testsuite/std/format/formatter/concept.cc
  173f51673fac83c111c4b2dfcf5e4542  libstdc++-v3/testsuite/std/format/formatter/requirements.cc
  926f89ddc54be9fcf8daa5c0a5f35b88  libstdc++-v3/testsuite/std/format/functions/107871.cc
! 8014ce27e1306ec7f1b324f4f14e3bf4  libstdc++-v3/testsuite/std/format/functions/format.cc
  48557cbd39e13d7e8ae282149478ea92  libstdc++-v3/testsuite/std/format/functions/format_c++23.cc
  e891997379a2804aff5d4567d8e50802  libstdc++-v3/testsuite/std/format/functions/format_to.cc
  5763728e220b19553b5285dbd2311349  libstdc++-v3/testsuite/std/format/functions/format_to_n.cc
--- 124381,124387 ----
  5477cf5cf0d83c16c3641c1ba9a1fca9  libstdc++-v3/testsuite/std/format/formatter/concept.cc
  173f51673fac83c111c4b2dfcf5e4542  libstdc++-v3/testsuite/std/format/formatter/requirements.cc
  926f89ddc54be9fcf8daa5c0a5f35b88  libstdc++-v3/testsuite/std/format/functions/107871.cc
! c477c124ccdc237a917d32d806bda128  libstdc++-v3/testsuite/std/format/functions/format.cc
  48557cbd39e13d7e8ae282149478ea92  libstdc++-v3/testsuite/std/format/functions/format_c++23.cc
  e891997379a2804aff5d4567d8e50802  libstdc++-v3/testsuite/std/format/functions/format_to.cc
  5763728e220b19553b5285dbd2311349  libstdc++-v3/testsuite/std/format/functions/format_to_n.cc
*************** be10c13acd828ebea73db44489485d31  libstd
*** 124215,124224 ****
  be910052b3c95c93d92af43b6a22b3be  libstdc++-v3/testsuite/std/time/clock/file/members.cc
  345478b5ce7c143f57ec487df78d136d  libstdc++-v3/testsuite/std/time/clock/file/overview.cc
  17f8bff974757122a65883e7c33d9d80  libstdc++-v3/testsuite/std/time/clock/gps/1.cc
! 582df7dcaed4b97a2a4f6c981cd9c658  libstdc++-v3/testsuite/std/time/clock/gps/io.cc
! 74c3a6dc91a891549033088b48ed9eb7  libstdc++-v3/testsuite/std/time/clock/system/io.cc
  001b9c894be15711431b32cf6934f07e  libstdc++-v3/testsuite/std/time/clock/tai/1.cc
! 7db468492a30dc966a62a5676e3f47d5  libstdc++-v3/testsuite/std/time/clock/tai/io.cc
  7e3e7a495e0c19958f10682f7b49296d  libstdc++-v3/testsuite/std/time/clock/utc/1.cc
  23476f1e3b3d23b2649d29884d101d56  libstdc++-v3/testsuite/std/time/clock/utc/io.cc
  ff09d6a4a1def92f6d35e9fe30514c86  libstdc++-v3/testsuite/std/time/clock/utc/leap_second_info.cc
--- 124491,124501 ----
  be910052b3c95c93d92af43b6a22b3be  libstdc++-v3/testsuite/std/time/clock/file/members.cc
  345478b5ce7c143f57ec487df78d136d  libstdc++-v3/testsuite/std/time/clock/file/overview.cc
  17f8bff974757122a65883e7c33d9d80  libstdc++-v3/testsuite/std/time/clock/gps/1.cc
! 3fff7c8a9ff27a9167c62f08009448ca  libstdc++-v3/testsuite/std/time/clock/gps/io.cc
! 521877571e845eea902518b76a784d98  libstdc++-v3/testsuite/std/time/clock/local/io.cc
! a2772dcdba4aa99fa270f1bf4bc0e5c0  libstdc++-v3/testsuite/std/time/clock/system/io.cc
  001b9c894be15711431b32cf6934f07e  libstdc++-v3/testsuite/std/time/clock/tai/1.cc
! f7d720a4c23ba45d880ad68e66d87661  libstdc++-v3/testsuite/std/time/clock/tai/io.cc
  7e3e7a495e0c19958f10682f7b49296d  libstdc++-v3/testsuite/std/time/clock/utc/1.cc
  23476f1e3b3d23b2649d29884d101d56  libstdc++-v3/testsuite/std/time/clock/utc/io.cc
  ff09d6a4a1def92f6d35e9fe30514c86  libstdc++-v3/testsuite/std/time/clock/utc/leap_second_info.cc
*************** ed486cc2e31c6afcdde6ef9f6c13f745  libstd
*** 124286,124292 ****
  30bc9b2fd2b40e8027fe0054e4a38fe7  libstdc++-v3/testsuite/std/time/zoned_time/1.cc
  c5b4f50004a5d67e4537e73a7737a3b1  libstdc++-v3/testsuite/std/time/zoned_time/custom.cc
  189c09d558551ffe49e3d2dc9834b8a4  libstdc++-v3/testsuite/std/time/zoned_time/deduction.cc
! 59b340d5c1d26a795b8807bd3d3265f6  libstdc++-v3/testsuite/std/time/zoned_time/io.cc
  2efed5bb6e9bdea0ea3cd7fb040c1711  libstdc++-v3/testsuite/std/time/zoned_time/req_neg.cc
  a486e4fae5e727ed071c66c4751798e5  libstdc++-v3/testsuite/std/time/zoned_time/requirements.cc
  2e901ad2401971034cd40a777684dcf6  libstdc++-v3/testsuite/std/time/zoned_traits.cc
--- 124563,124569 ----
  30bc9b2fd2b40e8027fe0054e4a38fe7  libstdc++-v3/testsuite/std/time/zoned_time/1.cc
  c5b4f50004a5d67e4537e73a7737a3b1  libstdc++-v3/testsuite/std/time/zoned_time/custom.cc
  189c09d558551ffe49e3d2dc9834b8a4  libstdc++-v3/testsuite/std/time/zoned_time/deduction.cc
! bf1895421c2fd631595e3fe7d12104ba  libstdc++-v3/testsuite/std/time/zoned_time/io.cc
  2efed5bb6e9bdea0ea3cd7fb040c1711  libstdc++-v3/testsuite/std/time/zoned_time/req_neg.cc
  a486e4fae5e727ed071c66c4751798e5  libstdc++-v3/testsuite/std/time/zoned_time/requirements.cc
  2e901ad2401971034cd40a777684dcf6  libstdc++-v3/testsuite/std/time/zoned_traits.cc
diff -Nrcpad gcc-13.4.0/NEWS gcc-13.5.0-RC-20260904/NEWS
*** gcc-13.4.0/NEWS	Thu Jun  5 16:05:56 2025
--- gcc-13.5.0-RC-20260904/NEWS	Fri Sep  4 07:36:05 2026
*************** see ONEWS.
*** 6,11 ****
--- 6,12 ----
  
  ======================================================================
  http://gcc.gnu.org/gcc-13/index.html
+ 
                               GCC 13 Release Series
  
     June 5, 2025
*************** References and Acknowledgements
*** 59,65 ****
     provided this notice is preserved.
  
     These pages are [19]maintained by the GCC team. Last modified
!    2025-06-05.
  
  References
  
--- 60,66 ----
     provided this notice is preserved.
  
     These pages are [19]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 84,89 ****
--- 85,91 ----
    19. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-13/changes.html
+ 
                               GCC 13 Release Series
                          Changes, New Features, and Fixes
  
*************** Caveats
*** 289,304 ****
            + [56]P2266R3, Simpler implicit move ([57]PR101165)
            + [58]P2468R2, The Equality Operator You Are Looking For
              ([59]PR106644)
!           + [60]P2362R3, Remove non-encodable
!             wide character literals and multicharacter wide character lite
!             rals ([61]PR106647)
            + [62]P2448R2, Relaxing some constexpr restrictions
              ([63]PR106649)
            + [64]P1467R9, Extended floating-point types and standard names
              ([65]PR106652)
            + [66]P1774R8, Portable assumptions ([67]PR106654)
!           + [68]P2295R6, Support for
!             UTF-8 as a portable source file encoding ([69]PR106655)
            + [70]P2589R1, static operator[] ([71]PR107684)
       * New warnings:
            + [72]-Wself-move warns when a value is moved to itself with
--- 291,305 ----
            + [56]P2266R3, Simpler implicit move ([57]PR101165)
            + [58]P2468R2, The Equality Operator You Are Looking For
              ([59]PR106644)
!           + [60]P2362R3, Remove non-encodable wide character literals and
!             multicharacter wide character literals ([61]PR106647)
            + [62]P2448R2, Relaxing some constexpr restrictions
              ([63]PR106649)
            + [64]P1467R9, Extended floating-point types and standard names
              ([65]PR106652)
            + [66]P1774R8, Portable assumptions ([67]PR106654)
!           + [68]P2295R6, Support for UTF-8 as a portable source file
!             encoding ([69]PR106655)
            + [70]P2589R1, static operator[] ([71]PR107684)
       * New warnings:
            + [72]-Wself-move warns when a value is moved to itself with
*************** Caveats
*** 338,344 ****
       * Support for the  header from v2 of
         the Concurrency Technical Specification.
       * Support for many previously unavailable features in freestanding
!        mode, thanks to Arsen Arsenović. For example, std::tuple is now
         available for freestanding compilation. The freestanding subset
         contains all the components made freestanding by [80]P1642, and
         libstdc++ adds more components such as std::array and
--- 339,345 ----
       * Support for the  header from v2 of
         the Concurrency Technical Specification.
       * Support for many previously unavailable features in freestanding
!        mode, thanks to Arsen Arsenovic. For example, std::tuple is now
         available for freestanding compilation. The freestanding subset
         contains all the components made freestanding by [80]P1642, and
         libstdc++ adds more components such as std::array and
*************** Caveats
*** 454,460 ****
  
    [95]AVR
  
!      * Support for the following devices has been added in v13.3:
            + ATtiny102, ATtiny104, ATtiny424, ATtiny426, ATtiny427,
              ATtiny824, ATtiny826, ATtiny827, ATtiny1624, ATtiny1626,
              ATtiny1627, ATtiny3224, ATtiny3226, ATtiny3227, AVR32DD14,
--- 455,461 ----
  
    [95]AVR
  
!      * Support for the following devices has been added in GCC 13.3:
            + ATtiny102, ATtiny104, ATtiny424, ATtiny426, ATtiny427,
              ATtiny824, ATtiny826, ATtiny827, ATtiny1624, ATtiny1626,
              ATtiny1627, ATtiny3224, ATtiny3226, ATtiny3227, AVR32DD14,
*************** Caveats
*** 463,471 ****
              AVR64DD14, AVR64DD20, AVR64DD28, AVR64DD32, AVR64DU28,
              AVR64DU32, AVR64EA28, AVR64EA32, AVR64EA48, ATA5787, ATA5835,
              ATA5700M322.
!      * Support for the following devices has been added in v13.4:
            + AVR32SD20, AVR32SD28, AVR32SD32, AVR64SD28, AVR64SD32,
              AVR64SD48.
  
    [96]IA-32/x86-64
  
--- 464,478 ----
              AVR64DD14, AVR64DD20, AVR64DD28, AVR64DD32, AVR64DU28,
              AVR64DU32, AVR64EA28, AVR64EA32, AVR64EA48, ATA5787, ATA5835,
              ATA5700M322.
!      * Support for the following devices has been added in GCC 13.4:
            + AVR32SD20, AVR32SD28, AVR32SD32, AVR64SD28, AVR64SD32,
              AVR64SD48.
+      * Support for the following devices has been added in GCC 13.5:
+           + AVR32DA28S, AVR32DA32S, AVR32DA48S, AVR64DA28S, AVR64DA32S,
+             AVR64DA48S AVR64DA64S, AVR128DA28S, AVR128DA32S, AVR128DA48S,
+             AVR128DA64S, AVR32EB14, AVR32EB20, AVR32EB28, AVR32EB32,
+             AVR16LA14, AVR16LA20, AVR16LA28, AVR16LA32, AVR32LA14,
+             AVR32LA20, AVR32LA28, AVR32LA32.
  
    [96]IA-32/x86-64
  
*************** Caveats
*** 495,517 ****
       * New ISA extension support for Intel RAO-INT was added. RAO-INT
         intrinsics are available via the -mraoint compiler switch.
       * GCC now supports the Intel CPU named Raptor Lake through
!        -march=raptorlake. Raptor Lake is based on Alder Lake.
       * GCC now supports the Intel CPU named Meteor Lake through
!        -march=meteorlake. Meteor Lake is based on Alder Lake.
       * GCC now supports the Intel CPU named Sierra Forest through
         -march=sierraforest. Based on ISA extensions enabled on Alder Lake,
!        the switch further enables the AVX-IFMA, AVX-NE-CONVERT,
!        AVX-VNNI-INT8, CMPccXADD, ENQCMD and UINTR ISA extensions.
       * GCC now supports the Intel CPU named Grand Ridge through
!        -march=grandridge. Grand Ridge is based on Sierra Forest.
       * GCC now supports the Intel CPU named Emerald Rapids through
         -march=emeraldrapids. Emerald Rapids is based on Sapphire Rapids.
       * GCC now supports the Intel CPU named Granite Rapids through
!        -march=graniterapids. Based on Sapphire Rapids, the switch further
!        enables the AMX-FP16 and PREFETCHI ISA extensions.
       * GCC now supports the Intel CPU named Granite Rapids D through
!        -march=graniterapids-d. Based on Granite Rapids, the switch further
!        enables the AMX-COMPLEX ISA extensions.
       * GCC now supports AMD CPUs based on the znver4 core via
         -march=znver4. The switch makes GCC consider using 512-bit vectors
         when auto-vectorizing.
--- 502,532 ----
       * New ISA extension support for Intel RAO-INT was added. RAO-INT
         intrinsics are available via the -mraoint compiler switch.
       * GCC now supports the Intel CPU named Raptor Lake through
!        -march=raptorlake. Raptor Lake is based on Alder Lake. Since GCC
!        13.5, CLDEMOTE is not enabled any longer.
       * GCC now supports the Intel CPU named Meteor Lake through
!        -march=meteorlake. Meteor Lake is based on Alder Lake. Since GCC
!        13.5, CLDEMOTE is not enabled any longer.
       * GCC now supports the Intel CPU named Sierra Forest through
         -march=sierraforest. Based on ISA extensions enabled on Alder Lake,
!        the switch in addition enables the AVX-IFMA, AVX-NE-CONVERT,
!        AVX-VNNI-INT8 and CMPccXADD ISA extensions. Since GCC 13.2, ENQCMD
!        and UINTR are further enabled.
       * GCC now supports the Intel CPU named Grand Ridge through
!        -march=grandridge. Based on Sierra Forest, the switch in addition
!        enables the RAO-INT ISA extensions. Since GCC 13.2, ENQCMD and
!        UINTR are further enabled. Since GCC 13.3, RAO-INT is not enabled
!        any longer.
       * GCC now supports the Intel CPU named Emerald Rapids through
         -march=emeraldrapids. Emerald Rapids is based on Sapphire Rapids.
       * GCC now supports the Intel CPU named Granite Rapids through
!        -march=graniterapids. Based on Sapphire Rapids, the switch in
!        addition enables the AMX-FP16 and PREFETCHI ISA extensions.
       * GCC now supports the Intel CPU named Granite Rapids D through
!        -march=graniterapids-d. Based on Granite Rapids, the switch in
!        addition enables the AMX-COMPLEX ISA extensions.
!      * Since GCC 13.5, CLDEMOTE is not enabled through the compiler switch
!        -march=alderlake any longer.
       * GCC now supports AMD CPUs based on the znver4 core via
         -march=znver4. The switch makes GCC consider using 512-bit vectors
         when auto-vectorizing.
*************** Other significant improvements
*** 707,713 ****
     provided this notice is preserved.
  
     These pages are [145]maintained by the GCC team. Last modified
!    2025-06-05.
  
  References
  
--- 722,728 ----
     provided this notice is preserved.
  
     These pages are [145]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 814,820 ****
   101. https://gcc.gnu.org/install/
   102. https://gcc.gnu.org/install/specific.html#nvptx-x-none
   103. https://gcc.gnu.org/gcc-13/changes.html#riscv
!  104. https://github.com/riscv-non-isa/rvv-intrinsic-doc/tree/v0.11.x
   105. https://rivai-ic.com.cn/
   106. https://gcc.gnu.org/gcc-13/changes.html#os
   107. https://gcc.gnu.org/gcc-13/changes.html#windows
--- 829,835 ----
   101. https://gcc.gnu.org/install/
   102. https://gcc.gnu.org/install/specific.html#nvptx-x-none
   103. https://gcc.gnu.org/gcc-13/changes.html#riscv
!  104. https://github.com/riscv-non-isa/riscv-rvv-intrinsic-doc/tree/v0.11.x
   105. https://rivai-ic.com.cn/
   106. https://gcc.gnu.org/gcc-13/changes.html#os
   107. https://gcc.gnu.org/gcc-13/changes.html#windows
*************** References
*** 858,885 ****
   145. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-12/index.html
                               GCC 12 Release Series
  
!    Jun 20, 2024
  
!    The GCC developers are pleased to announce the release of GCC 12.4.
  
     This release is a bug-fix release, containing fixes for regressions in
!    GCC 12.3 relative to previous releases of GCC.
  
  Release History
  
     GCC 12.4
!           Jun 20, 2024 ([1]changes, [2]documentation)
  
     GCC 12.3
!           May 8, 2023 ([3]changes, [4]documentation)
  
     GCC 12.2
!           Aug 19, 2022 ([5]changes, [6]documentation)
  
     GCC 12.1
!           May 6, 2022 ([7]changes, [8]documentation)
  
  References and Acknowledgements
  
--- 873,906 ----
   145. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-12/index.html
+ 
                               GCC 12 Release Series
  
!    (This release series is no longer supported.)
  
!    July 11, 2025
! 
!    The GCC developers are pleased to announce the release of GCC 12.5.
  
     This release is a bug-fix release, containing fixes for regressions in
!    GCC 12.4 relative to previous releases of GCC.
  
  Release History
  
+    GCC 12.5
+           July 11, 2025 ([1]changes, [2]documentation)
+ 
     GCC 12.4
!           Jun 20, 2024 ([3]changes, [4]documentation)
  
     GCC 12.3
!           May 8, 2023 ([5]changes, [6]documentation)
  
     GCC 12.2
!           Aug 19, 2022 ([7]changes, [8]documentation)
  
     GCC 12.1
!           May 6, 2022 ([9]changes, [10]documentation)
  
  References and Acknowledgements
  
*************** References and Acknowledgements
*** 889,941 ****
  
     The GCC developers would like to thank the numerous people that have
     contributed new features, improvements, bug fixes, and other changes as
!    well as test results to GCC. This [9]amazing group of volunteers is
     what makes GCC successful.
  
!    For additional information about GCC please refer to the [10]GCC
!    project web site or contact the [11]GCC development mailing list.
  
!    To obtain GCC please use [12]our mirror sites or [13]our version
     control system.
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [14]GCC manuals. If that fails, the
!     [15]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [16]gcc@gcc.gnu.org. All of [17]our lists have public
      archives.
  
!    Copyright (C) [18]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [19]maintained by the GCC team. Last modified
!    2024-06-20.
  
  References
  
     1. https://gcc.gnu.org/gcc-12/changes.html
!    2. https://gcc.gnu.org/onlinedocs/12.4.0/
     3. https://gcc.gnu.org/gcc-12/changes.html
!    4. https://gcc.gnu.org/onlinedocs/12.3.0/
     5. https://gcc.gnu.org/gcc-12/changes.html
!    6. https://gcc.gnu.org/onlinedocs/12.2.0/
     7. https://gcc.gnu.org/gcc-12/changes.html
!    8. https://gcc.gnu.org/onlinedocs/12.1.0/
!    9. https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Contributors.html
!   10. https://gcc.gnu.org/index.html
!   11. mailto:gcc@gcc.gnu.org
!   12. https://gcc.gnu.org/mirrors.html
!   13. https://gcc.gnu.org/git.html
!   14. https://gcc.gnu.org/onlinedocs/
!   15. mailto:gcc-help@gcc.gnu.org
!   16. mailto:gcc@gcc.gnu.org
!   17. https://gcc.gnu.org/lists.html
!   18. https://www.fsf.org/
!   19. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-12/changes.html
                               GCC 12 Release Series
                          Changes, New Features, and Fixes
  
--- 910,965 ----
  
     The GCC developers would like to thank the numerous people that have
     contributed new features, improvements, bug fixes, and other changes as
!    well as test results to GCC. This [11]amazing group of volunteers is
     what makes GCC successful.
  
!    For additional information about GCC please refer to the [12]GCC
!    project web site or contact the [13]GCC development mailing list.
  
!    To obtain GCC please use [14]our mirror sites or [15]our version
     control system.
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [16]GCC manuals. If that fails, the
!     [17]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [18]gcc@gcc.gnu.org. All of [19]our lists have public
      archives.
  
!    Copyright (C) [20]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [21]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
     1. https://gcc.gnu.org/gcc-12/changes.html
!    2. https://gcc.gnu.org/onlinedocs/12.5.0/
     3. https://gcc.gnu.org/gcc-12/changes.html
!    4. https://gcc.gnu.org/onlinedocs/12.4.0/
     5. https://gcc.gnu.org/gcc-12/changes.html
!    6. https://gcc.gnu.org/onlinedocs/12.3.0/
     7. https://gcc.gnu.org/gcc-12/changes.html
!    8. https://gcc.gnu.org/onlinedocs/12.2.0/
!    9. https://gcc.gnu.org/gcc-12/changes.html
!   10. https://gcc.gnu.org/onlinedocs/12.1.0/
!   11. https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Contributors.html
!   12. https://gcc.gnu.org/index.html
!   13. mailto:gcc@gcc.gnu.org
!   14. https://gcc.gnu.org/mirrors.html
!   15. https://gcc.gnu.org/git.html
!   16. https://gcc.gnu.org/onlinedocs/
!   17. mailto:gcc-help@gcc.gnu.org
!   18. mailto:gcc@gcc.gnu.org
!   19. https://gcc.gnu.org/lists.html
!   20. https://www.fsf.org/
!   21. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-12/changes.html
+ 
                               GCC 12 Release Series
                          Changes, New Features, and Fixes
  
*************** function Multiply (S1, S2 : Sign) return
*** 1436,1441 ****
--- 1460,1467 ----
       * New ISA extension support for Intel AVX512-FP16 was added.
         AVX512-FP16 intrinsics are available via the -mavx512fp16 compiler
         switch.
+      * Since GCC 12.5, CLDEMOTE is not enabled through the compiler switch
+        -march=alderlake any longer.
       * For both C and C++ the _Float16 type is supported on x86 systems
         with SSE2 enabled. Without {-mavx512fp16}, all operations will be
         emulated in software and float instructions.
*************** Other significant improvements
*** 1634,1660 ****
  
    [165]Debugging formats
  
!      * GCC can now generate debugging information in [166]CTF, a
!        lightweight debugging format that provides information about C
!        types and the association between functions and data symbols and
!        types. This format is designed to be embedded in ELF files and to
!        be very compact and simple. A new command-line option -gctf enables
!        the generation of CTF.
       * GCC can now generate debugging information in BTF. This is a
         debugging format mainly used in BPF programs and the Linux kernel.
         The compiler can generate BTF for any target, when enabled with the
         command-line option -gbtf
  
! [167]GCC 12.1
  
!    This is the [168]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 12.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [169]GCC 12.2
  
!    This is the [170]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 12.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
--- 1660,1686 ----
  
    [165]Debugging formats
  
!      * GCC can now generate debugging information in CTF, a lightweight
!        debugging format that provides information about C types and the
!        association between functions and data symbols and types. This
!        format is designed to be embedded in ELF files and to be very
!        compact and simple. A new command-line option -gctf enables the
!        generation of CTF.
       * GCC can now generate debugging information in BTF. This is a
         debugging format mainly used in BPF programs and the Linux kernel.
         The compiler can generate BTF for any target, when enabled with the
         command-line option -gbtf
  
! [166]GCC 12.1
  
!    This is the [167]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 12.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [168]GCC 12.2
  
!    This is the [169]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 12.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
*************** Other significant improvements
*** 1668,1674 ****
         all optimization levels but -O0 and -Og. The old behavior can be
         obtained by explicitly passing -mcheck-zero-division to GCC.
  
! [171]GCC 12.3
  
    Target Specific Changes
  
--- 1694,1700 ----
         all optimization levels but -O0 and -Og. The old behavior can be
         obtained by explicitly passing -mcheck-zero-division to GCC.
  
! [170]GCC 12.3
  
    Target Specific Changes
  
*************** Other significant improvements
*** 1678,1709 ****
         -march=znver4. The switch makes GCC consider using 512-bit vectors
         when auto-vectorizing.
  
!    This is the [172]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 12.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [173]GCC 12.4
  
!    This is the [174]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 12.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [175]GCC manuals. If that fails, the
!     [176]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [177]gcc@gcc.gnu.org. All of [178]our lists have public
      archives.
  
!    Copyright (C) [179]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [180]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 1704,1742 ----
         -march=znver4. The switch makes GCC consider using 512-bit vectors
         when auto-vectorizing.
  
!    This is the [171]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 12.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [172]GCC 12.4
  
!    This is the [173]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 12.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
+ [174]GCC 12.5
+ 
+    This is the [175]list of problem reports (PRs) from GCC's bug tracking
+    system that are known to be fixed in the 12.5 release. This list might
+    not be complete (that is, it is possible that some PRs that have been
+    fixed are not listed here).
+ 
  
      For questions related to the use of GCC, please consult these web
!     pages and the [176]GCC manuals. If that fails, the
!     [177]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [178]gcc@gcc.gnu.org. All of [179]our lists have public
      archives.
  
!    Copyright (C) [180]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [181]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 1719,1725 ****
    10. https://gcc.gnu.org/gcc-12/changes.html#languages
    11. https://gcc.gnu.org/onlinedocs/gcc-12.1.0/libgomp/OpenMP-Implementation-Status.html
    12. https://www.openacc.org/
!   13. https://gcc.gnu.org/wiki/OpenACC/Implementation Status#status-12
    14. https://gcc.gnu.org/onlinedocs/gcc-12.1.0/libgomp/Enabling-OpenACC.html
    15. https://gcc.gnu.org/gcc-12/changes.html#amdgcn
    16. https://gcc.gnu.org/gcc-12/changes.html#nvptx
--- 1752,1758 ----
    10. https://gcc.gnu.org/gcc-12/changes.html#languages
    11. https://gcc.gnu.org/onlinedocs/gcc-12.1.0/libgomp/OpenMP-Implementation-Status.html
    12. https://www.openacc.org/
!   13. https://gcc.gnu.org/wiki/OpenACC/Implementation%20Status#status-12
    14. https://gcc.gnu.org/onlinedocs/gcc-12.1.0/libgomp/Enabling-OpenACC.html
    15. https://gcc.gnu.org/gcc-12/changes.html#amdgcn
    16. https://gcc.gnu.org/gcc-12/changes.html#nvptx
*************** References
*** 1823,1829 ****
   114. https://gcc.gnu.org/gcc-12/changes.html#targets
   115. https://gcc.gnu.org/gcc-12/changes.html#arm-targets
   116. https://gcc.gnu.org/gcc-12/changes.html#aarch64
!  117. https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2020
   118. https://gcc.gnu.org/gcc-12/changes.html#amdgcn
   119. https://gcc.gnu.org/gcc-12/changes.html#arm
   120. https://gcc.gnu.org/gcc-12/changes.html#bpf
--- 1856,1862 ----
   114. https://gcc.gnu.org/gcc-12/changes.html#targets
   115. https://gcc.gnu.org/gcc-12/changes.html#arm-targets
   116. https://gcc.gnu.org/gcc-12/changes.html#aarch64
!  117. https://developer.arm.com/community/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-a-profile-architecture-developments-2020
   118. https://gcc.gnu.org/gcc-12/changes.html#amdgcn
   119. https://gcc.gnu.org/gcc-12/changes.html#arm
   120. https://gcc.gnu.org/gcc-12/changes.html#bpf
*************** References
*** 1872,1896 ****
   163. https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
   164. https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
   165. https://gcc.gnu.org/gcc-12/changes.html#debug
!  166. https://ctfstd.org/
!  167. https://gcc.gnu.org/gcc-12/changes.html#12.1
!  168. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.0
!  169. https://gcc.gnu.org/gcc-12/changes.html#12.2
!  170. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.2
!  171. https://gcc.gnu.org/gcc-12/changes.html#12.3
!  172. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.3
!  173. https://gcc.gnu.org/gcc-12/changes.html#12.4
!  174. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.4
!  175. https://gcc.gnu.org/onlinedocs/
!  176. mailto:gcc-help@gcc.gnu.org
!  177. mailto:gcc@gcc.gnu.org
!  178. https://gcc.gnu.org/lists.html
!  179. https://www.fsf.org/
!  180. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-11/index.html
                               GCC 11 Release Series
  
     July 19, 2024
  
     The GCC developers are pleased to announce the release of GCC 11.5.
--- 1905,1933 ----
   163. https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
   164. https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init
   165. https://gcc.gnu.org/gcc-12/changes.html#debug
!  166. https://gcc.gnu.org/gcc-12/changes.html#12.1
!  167. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.0
!  168. https://gcc.gnu.org/gcc-12/changes.html#12.2
!  169. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.2
!  170. https://gcc.gnu.org/gcc-12/changes.html#12.3
!  171. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.3
!  172. https://gcc.gnu.org/gcc-12/changes.html#12.4
!  173. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.4
!  174. https://gcc.gnu.org/gcc-12/changes.html#12.5
!  175. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=12.5
!  176. https://gcc.gnu.org/onlinedocs/
!  177. mailto:gcc-help@gcc.gnu.org
!  178. mailto:gcc@gcc.gnu.org
!  179. https://gcc.gnu.org/lists.html
!  180. https://www.fsf.org/
!  181. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-11/index.html
+ 
                               GCC 11 Release Series
  
+    (This release series is no longer supported.)
+ 
     July 19, 2024
  
     The GCC developers are pleased to announce the release of GCC 11.5.
*************** References and Acknowledgements
*** 1945,1951 ****
     provided this notice is preserved.
  
     These pages are [21]maintained by the GCC team. Last modified
!    2024-07-19.
  
  References
  
--- 1982,1988 ----
     provided this notice is preserved.
  
     These pages are [21]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 1972,1977 ****
--- 2009,2015 ----
    21. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-11/changes.html
+ 
                               GCC 11 Release Series
                          Changes, New Features, and Fixes
  
*************** Caveats
*** 2001,2007 ****
       * The libstdc++ configure option --enable-cheaders=c_std is
         deprecated and will be removed in a future release. It should be
         possible to use --enable-cheaders=c_global (the default) with no
!        change in behaviour.
       * The front end for compiling BRIG format of Heterogeneous System
         Architecture Intermediate Language (HSAIL) has been deprecated and
         will likely be removed in a future release.
--- 2039,2045 ----
       * The libstdc++ configure option --enable-cheaders=c_std is
         deprecated and will be removed in a future release. It should be
         possible to use --enable-cheaders=c_global (the default) with no
!        change in behavior.
       * The front end for compiling BRIG format of Heterogeneous System
         Architecture Intermediate Language (HSAIL) has been deprecated and
         will likely be removed in a future release.
*************** Caveats
*** 2024,2033 ****
              and
            + multicolumn characters (requiring more than one column to
              display in a monospace font)
!        For example, the character π ("GREEK SMALL LETTER PI (U+03C0)")
         occupies one column, and its UTF-8 encoding requires two bytes; the
!        character 🙂 ("SLIGHTLY SMILING FACE (U+1F642)") occupies two
!        columns, and its UTF-8 encoding requires four bytes.
         In GCC 11 the column numbers default to being column numbers,
         respecting multi-column characters. The old behavior can be
         restored using a new option [8]-fdiagnostics-column-unit=byte.
--- 2062,2071 ----
              and
            + multicolumn characters (requiring more than one column to
              display in a monospace font)
!        For example, the character p ("GREEK SMALL LETTER PI (U+03C0)")
         occupies one column, and its UTF-8 encoding requires two bytes; the
!        character 🙂 ("SLIGHTLY SMILING FACE (U+1F642)") occupies
!        two columns, and its UTF-8 encoding requires four bytes.
         In GCC 11 the column numbers default to being column numbers,
         respecting multi-column characters. The old behavior can be
         restored using a new option [8]-fdiagnostics-column-unit=byte.
*************** Caveats
*** 2481,2489 ****
            + Arm Cortex-R82 (cortex-r82).
       * The AArch64 Armv8-R architecture is now supported through the
         -march=armv8-r option.
!      * Mitigation against the [66]Straight-line Speculation vulnerability
!        is supported with the -mharden-sls= option. Please refer to the
!        documentation for usage instructions.
       * The availability of Advanced SIMD intrinsics available through the
         arm_neon.h header is improved and GCC 11 supports the full set of
         intrinsics defined by ACLE Q3 2020.
--- 2519,2527 ----
            + Arm Cortex-R82 (cortex-r82).
       * The AArch64 Armv8-R architecture is now supported through the
         -march=armv8-r option.
!      * Mitigation against [66]Spectre/Meltdown is supported with the
!        -mharden-sls= option. Please refer to the documentation for usage
!        instructions.
       * The availability of Advanced SIMD intrinsics available through the
         arm_neon.h header is improved and GCC 11 supports the full set of
         intrinsics defined by ACLE Q3 2020.
*************** Other significant improvements
*** 2723,2729 ****
     provided this notice is preserved.
  
     These pages are [107]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 2761,2767 ----
     provided this notice is preserved.
  
     These pages are [107]maintained by the GCC team. Last modified
!    2026-08-29.
  
  References
  
*************** References
*** 2749,2755 ****
    20. https://gcc.gnu.org/gcc-11/changes.html#languages
    21. https://www.openmp.org/specifications/
    22. https://www.openacc.org/
!   23. https://gcc.gnu.org/wiki/OpenACC/Implementation Status#status-11
    24. https://gcc.gnu.org/onlinedocs/gcc-11.1.0/libgomp/Enabling-OpenACC.html
    25. https://gcc.gnu.org/gcc-11/changes.html#c-family
    26. https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Common-Function-Attributes.html#index-no_005fstack_005fprotector-function-attribute
--- 2787,2793 ----
    20. https://gcc.gnu.org/gcc-11/changes.html#languages
    21. https://www.openmp.org/specifications/
    22. https://www.openacc.org/
!   23. https://gcc.gnu.org/wiki/OpenACC/Implementation%20Status#status-11
    24. https://gcc.gnu.org/onlinedocs/gcc-11.1.0/libgomp/Enabling-OpenACC.html
    25. https://gcc.gnu.org/gcc-11/changes.html#c-family
    26. https://gcc.gnu.org/onlinedocs/gcc-11.1.0/gcc/Common-Function-Attributes.html#index-no_005fstack_005fprotector-function-attribute
*************** References
*** 2792,2798 ****
    63. https://gcc.gnu.org/gcc-11/changes.html#targets
    64. https://gcc.gnu.org/gcc-11/changes.html#arm-targets
    65. https://gcc.gnu.org/gcc-11/changes.html#aarch64
!   66. https://developer.arm.com/documentation/102587/0102/Straight-line-speculation-frequently-asked-questions
    67. https://gcc.gnu.org/gcc-11/changes.html#amdgcn
    68. https://gcc.gnu.org/gcc-11/changes.html#arm
    69. https://gcc.gnu.org/gcc-11/changes.html#x86
--- 2830,2836 ----
    63. https://gcc.gnu.org/gcc-11/changes.html#targets
    64. https://gcc.gnu.org/gcc-11/changes.html#arm-targets
    65. https://gcc.gnu.org/gcc-11/changes.html#aarch64
!   66. https://support.arm.com/documentation/110280/latest
    67. https://gcc.gnu.org/gcc-11/changes.html#amdgcn
    68. https://gcc.gnu.org/gcc-11/changes.html#arm
    69. https://gcc.gnu.org/gcc-11/changes.html#x86
*************** References
*** 2836,2841 ****
--- 2874,2880 ----
   107. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-10/index.html
+ 
                               GCC 10 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 2895,2901 ****
     provided this notice is preserved.
  
     These pages are [22]maintained by the GCC team. Last modified
!    2024-05-30.
  
  References
  
--- 2934,2940 ----
     provided this notice is preserved.
  
     These pages are [22]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 2923,2928 ****
--- 2962,2968 ----
    22. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-10/changes.html
+ 
                               GCC 10 Release Series
                          Changes, New Features, and Fixes
  
*************** Caveats
*** 3092,3100 ****
         the input encoding (UTF-8, by default), in addition to the UCN
         syntax (\uNNNN or \UNNNNNNNN) that is already supported:
  
! static const int π = 3;
! int get_naïve_pi() {
!   return π;
  }
  
    [33]C
--- 3132,3140 ----
         the input encoding (UTF-8, by default), in addition to the UCN
         syntax (\uNNNN or \UNNNNNNNN) that is already supported:
  
! static const int p = 3;
! int get_nave_pi() {
!   return p;
  }
  
    [33]C
*************** typedef svbool_t pred512 __attribute__((
*** 3374,3380 ****
              one. Previously it would always use SVE if possible.
            + If a vector loop uses Advanced SIMD rather than SVE, the
              vectorizer now considers using SVE to vectorize the left-over
!             elements (the “scalar tail” or “epilog”).
            + Besides these specific points, there have been many general
              improvements to the way that the vectorizer uses SVE.
       * The -mbranch-protection=pac-ret option now accepts the optional
--- 3414,3420 ----
              one. Previously it would always use SVE if possible.
            + If a vector loop uses Advanced SIMD rather than SVE, the
              vectorizer now considers using SVE to vectorize the left-over
!             elements (the "scalar tail" or "epilog").
            + Besides these specific points, there have been many general
              improvements to the way that the vectorizer uses SVE.
       * The -mbranch-protection=pac-ret option now accepts the optional
*************** typedef svbool_t pred512 __attribute__((
*** 3455,3461 ****
            + Arm Cortex-M55 (cortex-m55).
         The GCC identifiers can be used as arguments to the -mcpu or -mtune
         options, for example: -mcpu=cortex-a77 or -mtune=cortex-m35p.
!      * Support has been extended for the ACLE [57]data-processing
         intrinsics to include 32-bit SIMD, saturating arithmetic, 16-bit
         multiplication and other related intrinsics aimed at DSP algorithm
         optimization.
--- 3495,3501 ----
            + Arm Cortex-M55 (cortex-m55).
         The GCC identifiers can be used as arguments to the -mcpu or -mtune
         options, for example: -mcpu=cortex-a77 or -mtune=cortex-m35p.
!      * Support has been extended for the [57]ACLE data-processing
         intrinsics to include 32-bit SIMD, saturating arithmetic, 16-bit
         multiplication and other related intrinsics aimed at DSP algorithm
         optimization.
*************** typedef svbool_t pred512 __attribute__((
*** 3469,3488 ****
         intrinsics can be enabled by including the arm_mve.h header file
         and passing the +mve or +mve.fp option extensions (for example:
         -march=armv8.1-m.main+mve).
!      * Support for the Custom Datapath Extension beta ACLE [60]intrinsics
!        has been added.
       * Support for Armv8.1-M Mainline Security Extensions architecture has
         been added. The -mcmse option, when used in combination with an
         Armv8.1-M Mainline architecture (for example: -march=armv8.1-m.main
         -mcmse), now leads to the generation of improved code sequences
         when changing security states.
  
!   [61]AMD Radeon (GCN)
  
       * Code generation and in particular vectorization support have been
         much improved.
  
!   [62]ARC
  
       * The interrupt service routine functions save all used registers,
         including extension registers and auxiliary registers used by Zero
--- 3509,3528 ----
         intrinsics can be enabled by including the arm_mve.h header file
         and passing the +mve or +mve.fp option extensions (for example:
         -march=armv8.1-m.main+mve).
!      * Support for the Custom Datapath Extension beta ACLE intrinsics has
!        been added.
       * Support for Armv8.1-M Mainline Security Extensions architecture has
         been added. The -mcmse option, when used in combination with an
         Armv8.1-M Mainline architecture (for example: -march=armv8.1-m.main
         -mcmse), now leads to the generation of improved code sequences
         when changing security states.
  
!   [60]AMD Radeon (GCN)
  
       * Code generation and in particular vectorization support have been
         much improved.
  
!   [61]ARC
  
       * The interrupt service routine functions save all used registers,
         including extension registers and auxiliary registers used by Zero
*************** typedef svbool_t pred512 __attribute__((
*** 3495,3501 ****
       * Remove -mq-class option.
       * Improve 64-bit integer addition and subtraction operations.
  
!   [63]AVR
  
       * Support for the XMEGA-like devices
  
--- 3535,3541 ----
       * Remove -mq-class option.
       * Improve 64-bit integer addition and subtraction operations.
  
!   [62]AVR
  
       * Support for the XMEGA-like devices
  
*************** typedef svbool_t pred512 __attribute__((
*** 3508,3514 ****
         to provide a custom device-specs file by means of
  
       avr-gcc -nodevicespecs -specs=my-spec-file 
!        and without the need to provide options -B and -mmcu=. See [64]AVR
         command-line options for details. This feature is also available in
         GCC 9.3+ and GCC 8.4+.
       * New command-line options -mdouble=[32,64] and -mlong-double=[32,64]
--- 3548,3554 ----
         to provide a custom device-specs file by means of
  
       avr-gcc -nodevicespecs -specs=my-spec-file 
!        and without the need to provide options -B and -mmcu=. See [63]AVR
         command-line options for details. This feature is also available in
         GCC 9.3+ and GCC 8.4+.
       * New command-line options -mdouble=[32,64] and -mlong-double=[32,64]
*************** typedef svbool_t pred512 __attribute__((
*** 3516,3530 ****
         double and long double types, respectively. Whether or not the
         mentioned layouts are available, whether the options act as a
         multilib option, and the default for either option are controlled
!        by the new [65]AVR configure options --with-double= and
         --with-long-double=.
       * A new configure option --with-libf7= has been added. It controls to
         which level avr-libgcc provides 64-bit floating point support by
!        means of [66]Libf7.
       * A new configure option --with-double-comparison= has been added.
         It's unlikely you need to set this option by hand.
  
!   [67]IA-32/x86-64
  
       * Support to expand __builtin_roundeven into the appropriate SSE 4.1
         instruction has been added.
--- 3556,3570 ----
         double and long double types, respectively. Whether or not the
         mentioned layouts are available, whether the options act as a
         multilib option, and the default for either option are controlled
!        by the new [64]AVR configure options --with-double= and
         --with-long-double=.
       * A new configure option --with-libf7= has been added. It controls to
         which level avr-libgcc provides 64-bit floating point support by
!        means of [65]Libf7.
       * A new configure option --with-double-comparison= has been added.
         It's unlikely you need to set this option by hand.
  
!   [66]IA-32/x86-64
  
       * Support to expand __builtin_roundeven into the appropriate SSE 4.1
         instruction has been added.
*************** typedef svbool_t pred512 __attribute__((
*** 3537,3543 ****
         -march=tigerlake. The switch enables the MOVDIRI MOVDIR64B
         AVX512VP2INTERSECT ISA extensions.
  
!   [68]MIPS
  
       * The mips*-*-linux* targets now mark object files with appropriate
         GNU-stack note, facilitating use of non-executable stack hardening
--- 3577,3583 ----
         -march=tigerlake. The switch enables the MOVDIRI MOVDIR64B
         AVX512VP2INTERSECT ISA extensions.
  
!   [67]MIPS
  
       * The mips*-*-linux* targets now mark object files with appropriate
         GNU-stack note, facilitating use of non-executable stack hardening
*************** typedef svbool_t pred512 __attribute__((
*** 3546,3555 ****
         configured with --with-glibc-version=2.31 against glibc 2.31 or
         later.
  
!   [69]PowerPC / PowerPC64 / RS6000
  
       * Many vector builtins have been listed as deprecated in the
!        [70]64-Bit ELF V2 ABI Specification for quite a number of years.
         The vector builtins listed in Tables A.8 through A.10 are now
         deprecated for GCC 10, and will likely be removed from support in
         GCC 11. Note that this does not result in any loss of function.
--- 3586,3595 ----
         configured with --with-glibc-version=2.31 against glibc 2.31 or
         later.
  
!   [68]PowerPC / PowerPC64 / RS6000
  
       * Many vector builtins have been listed as deprecated in the
!        [69]64-Bit ELF V2 ABI Specification for quite a number of years.
         The vector builtins listed in Tables A.8 through A.10 are now
         deprecated for GCC 10, and will likely be removed from support in
         GCC 11. Note that this does not result in any loss of function.
*************** typedef svbool_t pred512 __attribute__((
*** 3560,3576 ****
         will be unlikely to affect much if any code, and any required code
         changes will be trivial.
  
!   [71]PRU
  
       * A new back end targeting TI PRU I/O processors has been contributed
         to GCC.
  
!   [72]RISC-V
  
       * The riscv*-*-* targets now require GNU binutils version 2.30 or
         later, to support new assembly instructions produced by GCC.
  
!   [73]V850
  
       * The ABI for V850 nested functions has been changed. Previously the
         V850 port used %r20 for the static chain pointer, now the port uses
--- 3600,3616 ----
         will be unlikely to affect much if any code, and any required code
         changes will be trivial.
  
!   [70]PRU
  
       * A new back end targeting TI PRU I/O processors has been contributed
         to GCC.
  
!   [71]RISC-V
  
       * The riscv*-*-* targets now require GNU binutils version 2.30 or
         later, to support new assembly instructions produced by GCC.
  
!   [72]V850
  
       * The ABI for V850 nested functions has been changed. Previously the
         V850 port used %r20 for the static chain pointer, now the port uses
*************** typedef svbool_t pred512 __attribute__((
*** 3578,3595 ****
         where a call to a nested function would unexpectedly change the
         value in %r20.
  
! [74]Operating Systems
  
! [75]Improvements for plugin authors
  
       * GCC diagnostics can now have a chain of events associated with
         them, describing a path through the code that triggers the problem.
         These can be printed by the diagnostics subsystem in various ways,
!        controlled by the [76]-fdiagnostics-path-format option, or captured
!        in JSON form via [77]-fdiagnostics-format=json.
!      * GCC diagnostics can now be associated with [78]CWE weakness
         identifiers, which will appear on the standard error stream, and in
!        the JSON output from [79]-fdiagnostics-format=json.
  
  Other significant improvements
  
--- 3618,3635 ----
         where a call to a nested function would unexpectedly change the
         value in %r20.
  
! [73]Operating Systems
  
! [74]Improvements for plugin authors
  
       * GCC diagnostics can now have a chain of events associated with
         them, describing a path through the code that triggers the problem.
         These can be printed by the diagnostics subsystem in various ways,
!        controlled by the [75]-fdiagnostics-path-format option, or captured
!        in JSON form via [76]-fdiagnostics-format=json.
!      * GCC diagnostics can now be associated with [77]CWE weakness
         identifiers, which will appear on the standard error stream, and in
!        the JSON output from [78]-fdiagnostics-format=json.
  
  Other significant improvements
  
*************** Other significant improvements
*** 3601,3628 ****
       * For many releases, when GCC emits a warning it prints the option
         controlling that warning. As of GCC 10, that option text is now a
         clickable hyperlink for the documentation of that option (assuming
!        a [80]sufficiently capable terminal). This behavior can be
!        controlled via a new [81]-fdiagnostics-urls option (along with
         various environment variables and heuristics documented with that
         option).
  
  GCC 10.1
  
!    This is the [82]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 10.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [83]GCC 10.2
  
!    This is the [84]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 10.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [85]GCC 10.3
  
!    This is the [86]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 10.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
--- 3641,3668 ----
       * For many releases, when GCC emits a warning it prints the option
         controlling that warning. As of GCC 10, that option text is now a
         clickable hyperlink for the documentation of that option (assuming
!        a [79]sufficiently capable terminal). This behavior can be
!        controlled via a new [80]-fdiagnostics-urls option (along with
         various environment variables and heuristics documented with that
         option).
  
  GCC 10.1
  
!    This is the [81]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 10.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [82]GCC 10.2
  
!    This is the [83]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 10.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [84]GCC 10.3
  
!    This is the [85]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 10.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
*************** GCC 10.1
*** 3647,3655 ****
       * GCC 10.3 supports AMD CPUs based on the znver3 core via
         -march=znver3.
  
! [87]GCC 10.4
  
!    This is the [88]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 10.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
--- 3687,3695 ----
       * GCC 10.3 supports AMD CPUs based on the znver3 core via
         -march=znver3.
  
! [86]GCC 10.4
  
!    This is the [87]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 10.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
*************** GCC 10.1
*** 3663,3689 ****
         MMX no longer changes how they are passed nor returned. This ABI
         change is now diagnosed with -Wpsabi.
  
! [89]GCC 10.5
  
!    This is the [90]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 10.5 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [91]GCC manuals. If that fails, the
!     [92]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [93]gcc@gcc.gnu.org. All of [94]our lists have public
      archives.
  
!    Copyright (C) [95]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [96]maintained by the GCC team. Last modified
!    2025-03-21.
  
  References
  
--- 3703,3729 ----
         MMX no longer changes how they are passed nor returned. This ABI
         change is now diagnosed with -Wpsabi.
  
! [88]GCC 10.5
  
!    This is the [89]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 10.5 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [90]GCC manuals. If that fails, the
!     [91]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [92]gcc@gcc.gnu.org. All of [93]our lists have public
      archives.
  
!    Copyright (C) [94]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [95]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 3706,3712 ****
    17. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Optimize-Options.html#index-fprofile-values
    18. https://gcc.gnu.org/gcc-10/changes.html#languages
    19. https://www.openacc.org/
!   20. https://gcc.gnu.org/wiki/OpenACC/Implementation Status#status-10
    21. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/libgomp/#toc-Enabling-OpenACC-1
    22. https://www.openmp.org/specifications/
    23. https://gcc.gnu.org/wiki/Offloading
--- 3746,3752 ----
    17. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Optimize-Options.html#index-fprofile-values
    18. https://gcc.gnu.org/gcc-10/changes.html#languages
    19. https://www.openacc.org/
!   20. https://gcc.gnu.org/wiki/OpenACC/Implementation%20Status#status-10
    21. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/libgomp/#toc-Enabling-OpenACC-1
    22. https://www.openmp.org/specifications/
    23. https://gcc.gnu.org/wiki/Offloading
*************** References
*** 3743,3790 ****
    54. https://gcc.gnu.org/gcc-10/changes.html#arm-targets
    55. https://gcc.gnu.org/gcc-10/changes.html#aarch64
    56. https://gcc.gnu.org/gcc-10/changes.html#arm
!   57. https://developer.arm.com/documentation/101028/0009/Data-processing-intrinsics
!   58. https://developer.arm.com/Architectures/M-Profile Architecture
    59. https://developer.arm.com/architectures/instruction-sets/intrinsics/
!   60. https://developer.arm.com/documentation/101028/0010/Custom-Datapath-Extension
!   61. https://gcc.gnu.org/gcc-10/changes.html#amdgcn
!   62. https://gcc.gnu.org/gcc-10/changes.html#arc
!   63. https://gcc.gnu.org/gcc-10/changes.html#avr
!   64. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/AVR-Options.html#index-nodevicespecs
!   65. https://gcc.gnu.org/install/configure.html#avr
!   66. https://gcc.gnu.org/wiki/avr-gcc#Libf7
!   67. https://gcc.gnu.org/gcc-10/changes.html#x86
!   68. https://gcc.gnu.org/gcc-10/changes.html#mips
!   69. https://gcc.gnu.org/gcc-10/changes.html#powerpc
!   70. https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture
!   71. https://gcc.gnu.org/gcc-10/changes.html#pru
!   72. https://gcc.gnu.org/gcc-10/changes.html#riscv
!   73. https://gcc.gnu.org/gcc-10/changes.html#v850
!   74. https://gcc.gnu.org/gcc-10/changes.html#os
!   75. https://gcc.gnu.org/gcc-10/changes.html#plugins
!   76. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-path-format
!   77. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-format
!   78. https://cwe.mitre.org/
!   79. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-format
!   80. https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
!   81. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-urls
!   82. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.0
!   83. https://gcc.gnu.org/gcc-10/changes.html#GCC10.2
!   84. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.2
!   85. https://gcc.gnu.org/gcc-10/changes.html#GCC10.3
!   86. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.3
!   87. https://gcc.gnu.org/gcc-10/changes.html#GCC10.4
!   88. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.4
!   89. https://gcc.gnu.org/gcc-10/changes.html#GCC10.5
!   90. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.5
!   91. https://gcc.gnu.org/onlinedocs/
!   92. mailto:gcc-help@gcc.gnu.org
!   93. mailto:gcc@gcc.gnu.org
!   94. https://gcc.gnu.org/lists.html
!   95. https://www.fsf.org/
!   96. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-9/index.html
                                GCC 9 Release Series
  
     (This release series is no longer supported.)
--- 3783,3830 ----
    54. https://gcc.gnu.org/gcc-10/changes.html#arm-targets
    55. https://gcc.gnu.org/gcc-10/changes.html#aarch64
    56. https://gcc.gnu.org/gcc-10/changes.html#arm
!   57. https://github.com/ARM-software/acle/releases
!   58. https://developer.arm.com/Architectures/M-Profile%20Architecture
    59. https://developer.arm.com/architectures/instruction-sets/intrinsics/
!   60. https://gcc.gnu.org/gcc-10/changes.html#amdgcn
!   61. https://gcc.gnu.org/gcc-10/changes.html#arc
!   62. https://gcc.gnu.org/gcc-10/changes.html#avr
!   63. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/AVR-Options.html#index-nodevicespecs
!   64. https://gcc.gnu.org/install/configure.html#avr
!   65. https://gcc.gnu.org/wiki/avr-gcc#Libf7
!   66. https://gcc.gnu.org/gcc-10/changes.html#x86
!   67. https://gcc.gnu.org/gcc-10/changes.html#mips
!   68. https://gcc.gnu.org/gcc-10/changes.html#powerpc
!   69. https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specification-power-architecture
!   70. https://gcc.gnu.org/gcc-10/changes.html#pru
!   71. https://gcc.gnu.org/gcc-10/changes.html#riscv
!   72. https://gcc.gnu.org/gcc-10/changes.html#v850
!   73. https://gcc.gnu.org/gcc-10/changes.html#os
!   74. https://gcc.gnu.org/gcc-10/changes.html#plugins
!   75. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-path-format
!   76. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-format
!   77. https://cwe.mitre.org/
!   78. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-format
!   79. https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
!   80. https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-urls
!   81. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.0
!   82. https://gcc.gnu.org/gcc-10/changes.html#GCC10.2
!   83. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.2
!   84. https://gcc.gnu.org/gcc-10/changes.html#GCC10.3
!   85. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.3
!   86. https://gcc.gnu.org/gcc-10/changes.html#GCC10.4
!   87. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.4
!   88. https://gcc.gnu.org/gcc-10/changes.html#GCC10.5
!   89. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=10.5
!   90. https://gcc.gnu.org/onlinedocs/
!   91. mailto:gcc-help@gcc.gnu.org
!   92. mailto:gcc@gcc.gnu.org
!   93. https://gcc.gnu.org/lists.html
!   94. https://www.fsf.org/
!   95. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-9/index.html
+ 
                                GCC 9 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 3844,3850 ****
     provided this notice is preserved.
  
     These pages are [22]maintained by the GCC team. Last modified
!    2024-05-30.
  
  References
  
--- 3884,3890 ----
     provided this notice is preserved.
  
     These pages are [22]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 3872,3877 ****
--- 3912,3918 ----
    22. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-9/changes.html
+ 
                                GCC 9 Release Series
                          Changes, New Features, and Fixes
  
*************** Caveats
*** 3919,3927 ****
  
  [9]General Improvements
  
!    The following GCC command line options have been introduced or
     improved.
!      * All command line options that take a byte-size argument accept
         64-bit integers as well as standard SI and IEC suffixes such as kb
         and KiB, MB and MiB, or GB and GiB denoting the corresponding
         multiples of bytes. See [10]Invoking GCC for more.
--- 3960,3968 ----
  
  [9]General Improvements
  
!    The following GCC command-line options have been introduced or
     improved.
!      * All command-line options that take a byte-size argument accept
         64-bit integers as well as standard SI and IEC suffixes such as kb
         and KiB, MB and MiB, or GB and GiB denoting the corresponding
         multiples of bytes. See [10]Invoking GCC for more.
*************** _SIZE'?
*** 4435,4446 ****
              option for Arm and thus -march=armv8-a+ssbs is an
              AArch64-specific option.
  
!       AArch64 specific
  
       * Support has been added for the Arm Neoverse E1 processor
         (-mcpu=neoverse-e1).
       * The AArch64 port now has support for stack clash protection using
!        the [72]-fstack-clash-protection option. The probing interval/guard
         size can be set by using --param
         stack-clash-protection-guard-size=12|16. The value of this
         parameter must be in bytes represented as a power of two. The two
--- 4476,4487 ----
              option for Arm and thus -march=armv8-a+ssbs is an
              AArch64-specific option.
  
!     [72]AArch64 specific
  
       * Support has been added for the Arm Neoverse E1 processor
         (-mcpu=neoverse-e1).
       * The AArch64 port now has support for stack clash protection using
!        the [73]-fstack-clash-protection option. The probing interval/guard
         size can be set by using --param
         stack-clash-protection-guard-size=12|16. The value of this
         parameter must be in bytes represented as a power of two. The two
*************** _SIZE'?
*** 4453,4459 ****
         option can now be used to enable the return address signing as well
         as the new Branch Target Identification feature of Armv8.5-A
         architecture. For more information on the arguments accepted by
!        this option, please refer to [73]AArch64-Options.
       * The following optional extensions to Armv8.5-A architecture are now
         supported and only affect the assembler.
            + Random Number Generation instructions through the
--- 4494,4500 ----
         option can now be used to enable the return address signing as well
         as the new Branch Target Identification feature of Armv8.5-A
         architecture. For more information on the arguments accepted by
!        this option, please refer to [74]AArch64-Options.
       * The following optional extensions to Armv8.5-A architecture are now
         supported and only affect the assembler.
            + Random Number Generation instructions through the
*************** _SIZE'?
*** 4461,4467 ****
            + Memory Tagging Extension through the -march=armv8.5-a+memtag
              option.
  
!       Arm specific
  
       * Support for the deprecated Armv2 and Armv3 architectures and their
         variants has been removed. Their corresponding -march values and
--- 4502,4508 ----
            + Memory Tagging Extension through the -march=armv8.5-a+memtag
              option.
  
!     [75]Arm specific
  
       * Support for the deprecated Armv2 and Armv3 architectures and their
         variants has been removed. Their corresponding -march values and
*************** _SIZE'?
*** 4472,4478 ****
       * Corrected FPU configurations for Cortex-R7 and Cortex-R8 when using
         their respective -mcpu options.
  
!   [74]AMD GCN
  
       * A new back end targeting AMD GCN GPUs has been contributed to GCC.
         The implementation is currently limited to compiling
--- 4513,4519 ----
       * Corrected FPU configurations for Cortex-R7 and Cortex-R8 when using
         their respective -mcpu options.
  
!   [76]AMD GCN
  
       * A new back end targeting AMD GCN GPUs has been contributed to GCC.
         The implementation is currently limited to compiling
*************** _SIZE'?
*** 4483,4501 ****
            + Fiji (fiji).
            + Vega 10 (gfx900).
  
!   [75]ARC
  
       * LRA is now on by default for the ARC target. This can be controlled
         by -mlra.
       * Add support for frame code-density and branch-and-index
         instructions.
  
!   [76]C-SKY
  
       * A new back end targeting C-SKY V2 processors has been contributed
         to GCC.
  
!   [77]IA-32/x86-64
  
       * Support of Intel MPX (Memory Protection Extensions) has been
         removed.
--- 4524,4542 ----
            + Fiji (fiji).
            + Vega 10 (gfx900).
  
!   [77]ARC
  
       * LRA is now on by default for the ARC target. This can be controlled
         by -mlra.
       * Add support for frame code-density and branch-and-index
         instructions.
  
!   [78]C-SKY
  
       * A new back end targeting C-SKY V2 processors has been contributed
         to GCC.
  
!   [79]IA-32/x86-64
  
       * Support of Intel MPX (Memory Protection Extensions) has been
         removed.
*************** _SIZE'?
*** 4506,4512 ****
         following ISA extensions: AVX512F, AVX512VL, AVX512CD, AVX512BW,
         AVX512DQ, AVX512VNNI.
  
!   [78]MIPS
  
       * The Loongson loongson-mmi and loongson-ext extensions have been
         split from loongson3a:
--- 4547,4553 ----
         following ISA extensions: AVX512F, AVX512VL, AVX512CD, AVX512BW,
         AVX512DQ, AVX512VNNI.
  
!   [80]MIPS
  
       * The Loongson loongson-mmi and loongson-ext extensions have been
         split from loongson3a:
*************** _SIZE'?
*** 4530,4541 ****
         -mtune options (as in -mcpu=gs464 or -mtune=gs464e) or as arguments
         to the equivalent target attributes and pragmas.
  
!   [79]OpenRISC
  
       * A new back end targeting OpenRISC processors has been contributed
         to GCC.
  
!   [80]S/390, System z, IBM z Systems
  
       * Support for the arch13 architecture has been added. When using the
         -march=arch13 option, the compiler will generate code making use of
--- 4571,4582 ----
         -mtune options (as in -mcpu=gs464 or -mtune=gs464e) or as arguments
         to the equivalent target attributes and pragmas.
  
!   [81]OpenRISC
  
       * A new back end targeting OpenRISC processors has been contributed
         to GCC.
  
!   [82]S/390, System z, IBM z Systems
  
       * Support for the arch13 architecture has been added. When using the
         -march=arch13 option, the compiler will generate code making use of
*************** _SIZE'?
*** 4565,4573 ****
         containing pointers to each profiling call stub. This is useful for
         automatically patching in and out calls.
  
! [81]Operating Systems
  
!   [82]Solaris
  
       * g++ now unconditionally enables large file support when compiling
         32-bit code.
--- 4606,4614 ----
         containing pointers to each profiling call stub. This is useful for
         automatically patching in and out calls.
  
! [83]Operating Systems
  
!   [84]Solaris
  
       * g++ now unconditionally enables large file support when compiling
         32-bit code.
*************** _SIZE'?
*** 4578,4586 ****
         Solaris 11/x86. It requires the use of GNU as. Solaris 11/SPARC
         support is still work-in-progress.
  
!   [83]Windows
  
!      * A C++ Microsoft ABI bitfield layout bug, [84]PR87137 has been
         fixed. A non-field declaration could cause the current bitfield
         allocation unit to be completed, incorrectly placing a following
         bitfield into a new allocation unit. The Microsoft ABI is selected
--- 4619,4627 ----
         Solaris 11/x86. It requires the use of GNU as. Solaris 11/SPARC
         support is still work-in-progress.
  
!   [85]Windows
  
!      * A C++ Microsoft ABI bitfield layout bug, [86]PR87137 has been
         fixed. A non-field declaration could cause the current bitfield
         allocation unit to be completed, incorrectly placing a following
         bitfield into a new allocation unit. The Microsoft ABI is selected
*************** _SIZE'?
*** 4591,4603 ****
            + SuperH targets when the -mhitachi option is specified, or
              __attribute__((renesas)) is used
  
! [85]Improvements for plugin authors
  
       * GCC's diagnostic subsystem now has a way to logically group
         together related diagnostics, auto_diagnostic_group. Such
         diagnostics will be nested by the output of
!        [86]-fdiagnostics-format=json.
!      * GCC now has a set of [87]user experience guidelines for GCC, with
         information and advice on implementing new diagnostics.
  
  Other significant improvements
--- 4632,4644 ----
            + SuperH targets when the -mhitachi option is specified, or
              __attribute__((renesas)) is used
  
! [87]Improvements for plugin authors
  
       * GCC's diagnostic subsystem now has a way to logically group
         together related diagnostics, auto_diagnostic_group. Such
         diagnostics will be nested by the output of
!        [88]-fdiagnostics-format=json.
!      * GCC now has a set of [89]user experience guidelines for GCC, with
         information and advice on implementing new diagnostics.
  
  Other significant improvements
*************** Other significant improvements
*** 4605,4634 ****
       * GCC's internal "selftest" suite now runs for C++ as well as C (in
         debug builds of the compiler).
  
! [88]GCC 9.1
  
!    This is the [89]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 9.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [90]GCC 9.2
  
!    This is the [91]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 9.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [92]GCC 9.3
  
!    This is the [93]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 9.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [94]GCC 9.4
  
!    This is the [95]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 9.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
--- 4646,4675 ----
       * GCC's internal "selftest" suite now runs for C++ as well as C (in
         debug builds of the compiler).
  
! [90]GCC 9.1
  
!    This is the [91]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 9.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [92]GCC 9.2
  
!    This is the [93]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 9.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [94]GCC 9.3
  
!    This is the [95]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 9.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [96]GCC 9.4
  
!    This is the [97]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 9.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
*************** Other significant improvements
*** 4651,4677 ****
         for all SVE implementations. Adding -msve-vector-bits=512 makes the
         code specific to 512-bit SVE.
  
! [96]GCC 9.5
  
!    This is the [97]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 9.5 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [98]GCC manuals. If that fails, the
!     [99]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [100]gcc@gcc.gnu.org. All of [101]our lists have public
      archives.
  
!    Copyright (C) [102]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [103]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 4692,4718 ----
         for all SVE implementations. Adding -msve-vector-bits=512 makes the
         code specific to 512-bit SVE.
  
! [98]GCC 9.5
  
!    This is the [99]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 9.5 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [100]GCC manuals. If that fails, the
!     [101]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [102]gcc@gcc.gnu.org. All of [103]our lists have public
      archives.
  
!    Copyright (C) [104]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [105]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 4712,4718 ****
    35. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Invoking-Gcov.html#Invoking-Gcov
    36. https://gcc.gnu.org/gcc-9/changes.html#languages
    37. https://www.openacc.org/
!   38. https://gcc.gnu.org/wiki/OpenACC/Implementation Status#status-9
    39. https://gcc.gnu.org/gcc-9/changes.html#c-family
    40. https://www.openmp.org/specifications/
    41. https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00628.html
--- 4753,4759 ----
    35. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Invoking-Gcov.html#Invoking-Gcov
    36. https://gcc.gnu.org/gcc-9/changes.html#languages
    37. https://www.openacc.org/
!   38. https://gcc.gnu.org/wiki/OpenACC/Implementation%20Status#status-9
    39. https://gcc.gnu.org/gcc-9/changes.html#c-family
    40. https://www.openmp.org/specifications/
    41. https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00628.html
*************** References
*** 4746,4785 ****
    69. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/jit/topics/contexts.html#gcc_jit_context_add_driver_option
    70. https://gcc.gnu.org/gcc-9/changes.html#targets
    71. https://gcc.gnu.org/gcc-9/changes.html#arm-targets
!   72. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Instrumentation-Options.html#index-fstack-protector
!   73. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/AArch64-Options.html#AArch64-Options
!   74. https://gcc.gnu.org/gcc-9/changes.html#amdgcn
!   75. https://gcc.gnu.org/gcc-9/changes.html#arc
!   76. https://gcc.gnu.org/gcc-9/changes.html#csky
!   77. https://gcc.gnu.org/gcc-9/changes.html#x86
!   78. https://gcc.gnu.org/gcc-9/changes.html#mips
!   79. https://gcc.gnu.org/gcc-9/changes.html#or1k
!   80. https://gcc.gnu.org/gcc-9/changes.html#s390
!   81. https://gcc.gnu.org/gcc-9/changes.html#os
!   82. https://gcc.gnu.org/gcc-9/changes.html#solaris
!   83. https://gcc.gnu.org/gcc-9/changes.html#windows
!   84. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137
!   85. https://gcc.gnu.org/gcc-9/changes.html#plugins
!   86. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-format
!   87. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gccint/User-Experience-Guidelines.html
!   88. https://gcc.gnu.org/gcc-9/changes.html#GCC9.1
!   89. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.0
!   90. https://gcc.gnu.org/gcc-9/changes.html#GCC9.2
!   91. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.2
!   92. https://gcc.gnu.org/gcc-9/changes.html#GCC9.3
!   93. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.3
!   94. https://gcc.gnu.org/gcc-9/changes.html#GCC9.4
!   95. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.4
!   96. https://gcc.gnu.org/gcc-9/changes.html#GCC9.5
!   97. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.5
!   98. https://gcc.gnu.org/onlinedocs/
!   99. mailto:gcc-help@gcc.gnu.org
!  100. mailto:gcc@gcc.gnu.org
!  101. https://gcc.gnu.org/lists.html
!  102. https://www.fsf.org/
!  103. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-8/index.html
                                GCC 8 Release Series
  
     (This release series is no longer supported.)
--- 4787,4829 ----
    69. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/jit/topics/contexts.html#gcc_jit_context_add_driver_option
    70. https://gcc.gnu.org/gcc-9/changes.html#targets
    71. https://gcc.gnu.org/gcc-9/changes.html#arm-targets
!   72. https://gcc.gnu.org/gcc-9/changes.html#aarch64
!   73. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Instrumentation-Options.html#index-fstack-protector
!   74. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/AArch64-Options.html#AArch64-Options
!   75. https://gcc.gnu.org/gcc-9/changes.html#arm
!   76. https://gcc.gnu.org/gcc-9/changes.html#amdgcn
!   77. https://gcc.gnu.org/gcc-9/changes.html#arc
!   78. https://gcc.gnu.org/gcc-9/changes.html#csky
!   79. https://gcc.gnu.org/gcc-9/changes.html#x86
!   80. https://gcc.gnu.org/gcc-9/changes.html#mips
!   81. https://gcc.gnu.org/gcc-9/changes.html#or1k
!   82. https://gcc.gnu.org/gcc-9/changes.html#s390
!   83. https://gcc.gnu.org/gcc-9/changes.html#os
!   84. https://gcc.gnu.org/gcc-9/changes.html#solaris
!   85. https://gcc.gnu.org/gcc-9/changes.html#windows
!   86. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87137
!   87. https://gcc.gnu.org/gcc-9/changes.html#plugins
!   88. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Diagnostic-Message-Formatting-Options.html#index-fdiagnostics-format
!   89. https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gccint/User-Experience-Guidelines.html
!   90. https://gcc.gnu.org/gcc-9/changes.html#GCC9.1
!   91. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.0
!   92. https://gcc.gnu.org/gcc-9/changes.html#GCC9.2
!   93. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.2
!   94. https://gcc.gnu.org/gcc-9/changes.html#GCC9.3
!   95. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.3
!   96. https://gcc.gnu.org/gcc-9/changes.html#GCC9.4
!   97. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.4
!   98. https://gcc.gnu.org/gcc-9/changes.html#GCC9.5
!   99. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.5
!  100. https://gcc.gnu.org/onlinedocs/
!  101. mailto:gcc-help@gcc.gnu.org
!  102. mailto:gcc@gcc.gnu.org
!  103. https://gcc.gnu.org/lists.html
!  104. https://www.fsf.org/
!  105. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-8/index.html
+ 
                                GCC 8 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 4842,4848 ****
     provided this notice is preserved.
  
     These pages are [23]maintained by the GCC team. Last modified
!    2024-05-30.
  
  References
  
--- 4886,4892 ----
     provided this notice is preserved.
  
     These pages are [23]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 4871,4876 ****
--- 4915,4921 ----
    23. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-8/changes.html
+ 
                                GCC 8 Release Series
                          Changes, New Features, and Fixes
  
*************** void copy (const char *s)
*** 5156,5162 ****
  {
      char buf[80];
      strncpy (buf, s, sizeof buf);
!     …
  }
  warning: 'strncpy' specified bound 80 equals destination size [-Wstringop-trunca
  tion]
--- 5201,5207 ----
  {
      char buf[80];
      strncpy (buf, s, sizeof buf);
!     ...
  }
  warning: 'strncpy' specified bound 80 equals destination size [-Wstringop-trunca
  tion]
*************** void f (void)
*** 5229,5235 ****
  {
      char a[] = "abcd1234";
      strcpy (a, a + 4);
!     …
  }
  warning: 'strcpy' accessing 5 bytes at offsets 0 and 4 overlaps 1 byte at offset
   4 [-Wrestrict]
--- 5274,5280 ----
  {
      char a[] = "abcd1234";
      strcpy (a, a + 4);
!     ...
  }
  warning: 'strcpy' accessing 5 bytes at offsets 0 and 4 overlaps 1 byte at offset
   4 [-Wrestrict]
*************** ctor >()' from 'map’
       template  struct X { static const int value = X::value; }; temp
  late struct X<1000>;
                                                    ^
!     test.C:2:46:   recursively required from ‘const int X<999>::value’
!     test.C:2:46:   required from ‘const int X<1000>::value’
      test.C:2:88:   required from here
  
!     test.C:2:46: error: incomplete type ‘X<100>’ used in nested name specifier
  
       * With the new [10]#pragma GCC ivdep, the user can assert that there
         are no loop-carried dependencies which would prevent concurrent
--- 9443,9463 ----
         -fdiagnostics-color=never.
         Sample diagnostics output:
      $ g++ -fdiagnostics-color=always -S -Wall test.C
!     test.C: In function `int foo()':
      test.C:1:14: warning: no return statement in function returning non-void [-W
  return-type]
       int foo () { }
                    ^
      test.C:2:46: error: template instantiation depth exceeds maximum of 900 (use
!  -ftemplate-depth= to increase the maximum) instantiating `struct X<100>'
       template  struct X { static const int value = X::value; }; temp
  late struct X<1000>;
                                                    ^
!     test.C:2:46:   recursively required from `const int X<999>::value'
!     test.C:2:46:   required from `const int X<1000>::value'
      test.C:2:88:   required from here
  
!     test.C:2:46: error: incomplete type `X<100>' used in nested name specifier
  
       * With the new [10]#pragma GCC ivdep, the user can assert that there
         are no loop-carried dependencies which would prevent concurrent
*************** late struct X<1000>;
*** 9421,9427 ****
         implementation follows ABI version 1.2; all features but _Cilk_for
         have been implemented.
  
!   C
  
       * ISO C11 atomics (the _Atomic type specifier and qualifier and the
          header) are now supported.
--- 9469,9475 ----
         implementation follows ABI version 1.2; all features but _Cilk_for
         have been implemented.
  
!   [11]C
  
       * ISO C11 atomics (the _Atomic type specifier and qualifier and the
          header) are now supported.
*************** late struct X<1000>;
*** 9438,9447 ****
       * A new C extension __auto_type provides a subset of the
         functionality of C++11 auto in GNU C.
  
!   [11]C++
  
!      * The G++ implementation of [12]C++1y return type deduction for
!        normal functions has been updated to conform to [13]N3638, the
         proposal accepted into the working paper. Most notably, it adds
         decltype(auto) for getting decltype semantics rather than the
         template argument deduction semantics of plain auto:
--- 9486,9495 ----
       * A new C extension __auto_type provides a subset of the
         functionality of C++11 auto in GNU C.
  
!   [12]C++
  
!      * The G++ implementation of [13]C++1y return type deduction for
!        normal functions has been updated to conform to [14]N3638, the
         proposal accepted into the working paper. Most notably, it adds
         decltype(auto) for getting decltype semantics rather than the
         template argument deduction semantics of plain auto:
*************** int& f();
*** 9450,9463 ****
           auto  i1 = f(); // int
  decltype(auto) i2 = f(); // int&
  
!      * G++ supports [14]C++1y lambda capture initializers:
  
  [x = 42]{ ... };
  
         Actually, they have been accepted since GCC 4.5, but now the
         compiler doesn't warn about them with -std=c++1y, and supports
         parenthesized and brace-enclosed initializers as well.
!      * G++ supports [15]C++1y variable length arrays. G++ has supported
         GNU/C99-style VLAs for a long time, but now additionally supports
         initializers and lambda capture by reference. In C++1y mode G++
         will complain about VLA uses that are not permitted by the draft
--- 9498,9511 ----
           auto  i1 = f(); // int
  decltype(auto) i2 = f(); // int&
  
!      * G++ supports [15]C++1y lambda capture initializers:
  
  [x = 42]{ ... };
  
         Actually, they have been accepted since GCC 4.5, but now the
         compiler doesn't warn about them with -std=c++1y, and supports
         parenthesized and brace-enclosed initializers as well.
!      * G++ supports [16]C++1y variable length arrays. G++ has supported
         GNU/C99-style VLAs for a long time, but now additionally supports
         initializers and lambda capture by reference. In C++1y mode G++
         will complain about VLA uses that are not permitted by the draft
*************** void f(int n) {
*** 9472,9478 ****
    &a; // error, taking address of VLA
  }
  
!      * G++ supports the [16]C++1y [[deprecated]] attribute modulo bugs in
         the underlying [[gnu::deprecated]] attribute. Classes and functions
         can be marked deprecated and a diagnostic message added:
  
--- 9520,9526 ----
    &a; // error, taking address of VLA
  }
  
!      * G++ supports the [17]C++1y [[deprecated]] attribute modulo bugs in
         the underlying [[gnu::deprecated]] attribute. Classes and functions
         can be marked deprecated and a diagnostic message added:
  
*************** A aa; // warning: 'A' is deprecated : A
*** 9490,9496 ****
  int j = bar(2); // warning: 'int bar(int)' is deprecated : bar is unsafe; use fo
  o() instead
  
!      * G++ supports [17]C++1y digit separators. Long numeric literals can
         be subdivided with a single quote ' to enhance readability:
  
  int i = 1048576;
--- 9538,9544 ----
  int j = bar(2); // warning: 'int bar(int)' is deprecated : bar is unsafe; use fo
  o() instead
  
!      * G++ supports [18]C++1y digit separators. Long numeric literals can
         be subdivided with a single quote ' to enhance readability:
  
  int i = 1048576;
*************** int n = 0b0001'0000'0000'0000'0000'0000;
*** 9502,9508 ****
  double x = 1.602'176'565e-19;
  double y = 1.602'176'565e-1'9;
  
!      * G++ supports [18]C++1y generic (polymorphic) lambdas.
  
  // a functional object that will increment any type
  auto incr = [](auto x) { return x++; };
--- 9550,9556 ----
  double x = 1.602'176'565e-19;
  double y = 1.602'176'565e-1'9;
  
!      * G++ supports [19]C++1y generic (polymorphic) lambdas.
  
  // a functional object that will increment any type
  auto incr = [](auto x) { return x++; };
*************** auto incr = [](auto x) { return x++; };
*** 9514,9521 ****
  // a functional object that will add two like-type objects
  auto add = []  (T a, T b) { return a + b; };
  
!      * G++ supports unconstrained generic functions as specified by §4.1.2
!        and §5.1.1 of [19]N3889: Concepts Lite Specification. Briefly, auto
         may be used as a type-specifier in a parameter declaration of any
         function declarator in order to introduce an implicit function
         template parameter, akin to generic lambdas.
--- 9562,9569 ----
  // a functional object that will add two like-type objects
  auto add = []  (T a, T b) { return a + b; };
  
!      * G++ supports unconstrained generic functions as specified by 4.1.2
!        and 5.1.1 of [20]N3889: Concepts Lite Specification. Briefly, auto
         may be used as a type-specifier in a parameter declaration of any
         function declarator in order to introduce an implicit function
         template parameter, akin to generic lambdas.
*************** auto incr(T x) { return x++; }
*** 9527,9539 ****
  
      Runtime Library (libstdc++)
  
!      * [20]Improved support for C++11, including:
            + support for ;
            + The associative containers in  and  and the
              unordered associative containers in  and
               meet the allocator-aware container
              requirements;
!      * [21]Improved experimental support for the upcoming ISO C++
         standard, C++14, including:
            + fixing constexpr member functions without const;
            + implementation of the std::exchange() utility function;
--- 9575,9587 ----
  
      Runtime Library (libstdc++)
  
!      * [21]Improved support for C++11, including:
            + support for ;
            + The associative containers in  and  and the
              unordered associative containers in  and
               meet the allocator-aware container
              requirements;
!      * [22]Improved experimental support for the upcoming ISO C++
         standard, C++14, including:
            + fixing constexpr member functions without const;
            + implementation of the std::exchange() utility function;
*************** auto incr(T x) { return x++; }
*** 9559,9565 ****
         and will be removed in a future version. std::make_exception_ptr
         should be used instead.
  
!   [22]Fortran
  
       * Compatibility notice:
            + Module files: The version of the module files (.mod) has been
--- 9607,9613 ----
         and will be removed in a future version. std::make_exception_ptr
         should be used instead.
  
!   [23]Fortran
  
       * Compatibility notice:
            + Module files: The version of the module files (.mod) has been
*************** auto incr(T x) { return x++; }
*** 9572,9578 ****
              object files and libraries are fully compatible with older
              versions (except as stated below).
            + ABI changes:
!                o The [23]argument passing ABI has changed for scalar dummy
                   arguments of type INTEGER, REAL, COMPLEX and LOGICAL,
                   which have both the VALUE and the OPTIONAL attributes.
                 o To support finalization the virtual table associated with
--- 9620,9626 ----
              object files and libraries are fully compatible with older
              versions (except as stated below).
            + ABI changes:
!                o The [24]argument passing ABI has changed for scalar dummy
                   arguments of type INTEGER, REAL, COMPLEX and LOGICAL,
                   which have both the VALUE and the OPTIONAL attributes.
                 o To support finalization the virtual table associated with
*************** auto incr(T x) { return x++; }
*** 9600,9606 ****
       * The compiler no longer unconditionally warns about DO loops with
         zero iterations. This warning is now controlled by the -Wzerotrip
         option, which is implied by -Wall.
!      * The new NO_ARG_CHECK attribute of the [24]!GCC$ directive can be
         used to disable the type-kind-rank (TKR) argument check for a dummy
         argument. The feature is similar to ISO/IEC TS 29133:2012's
         TYPE(*), except that it additionally also disables the rank check.
--- 9648,9654 ----
       * The compiler no longer unconditionally warns about DO loops with
         zero iterations. This warning is now controlled by the -Wzerotrip
         option, which is implied by -Wall.
!      * The new NO_ARG_CHECK attribute of the [25]!GCC$ directive can be
         used to disable the type-kind-rank (TKR) argument check for a dummy
         argument. The feature is similar to ISO/IEC TS 29133:2012's
         TYPE(*), except that it additionally also disables the rank check.
*************** auto incr(T x) { return x++; }
*** 9608,9614 ****
         be used as argument to ISO_C_BINDING's C_LOC and as actual argument
         to another NO_ARG_CHECK dummy argument; also the other constraints
         of TYPE(*) apply. The dummy arguments should be declared as scalar
!        or assumed-size variable of type type(*) (recommended) – or of type
         integer, real, complex or logical. With NO_ARG_CHECK, a pointer to
         the data without further type or shape information is passed,
         similar to C's void*. Note that also TS 29113's
--- 9656,9662 ----
         be used as argument to ISO_C_BINDING's C_LOC and as actual argument
         to another NO_ARG_CHECK dummy argument; also the other constraints
         of TYPE(*) apply. The dummy arguments should be declared as scalar
!        or assumed-size variable of type type(*) (recommended) - or of type
         integer, real, complex or logical. With NO_ARG_CHECK, a pointer to
         the data without further type or shape information is passed,
         similar to C's void*. Note that also TS 29113's
*************** auto incr(T x) { return x++; }
*** 9616,9633 ****
         contrary to NO_ARG_CHECK assumed-rank arguments pass an array
         descriptor which contains the array shape and stride of the
         argument.
!      * [25]Fortran 2003:
            + Finalization is now supported. It is currently only done for a
              subset of those situations in which it should occur.
            + Experimental support for scalar character components with
              deferred length (i.e. allocatable string length) in derived
              types has been added. (Deferred-length character variables are
              supported since GCC 4.6.)
!      * [26]Fortran 2008:
            + When STOP or ERROR STOP are used to terminate the execution
              and any exception (but inexact) is signaling, a warning is
              printed to ERROR_UNIT, indicating which exceptions are
!             signaling. The [27]-ffpe-summary= command-line option can be
              used to fine-tune for which exceptions the warning should be
              shown.
            + Rounding on input (READ) is now handled on systems where
--- 9664,9681 ----
         contrary to NO_ARG_CHECK assumed-rank arguments pass an array
         descriptor which contains the array shape and stride of the
         argument.
!      * [26]Fortran 2003:
            + Finalization is now supported. It is currently only done for a
              subset of those situations in which it should occur.
            + Experimental support for scalar character components with
              deferred length (i.e. allocatable string length) in derived
              types has been added. (Deferred-length character variables are
              supported since GCC 4.6.)
!      * [27]Fortran 2008:
            + When STOP or ERROR STOP are used to terminate the execution
              and any exception (but inexact) is signaling, a warning is
              printed to ERROR_UNIT, indicating which exceptions are
!             signaling. The [28]-ffpe-summary= command-line option can be
              used to fine-tune for which exceptions the warning should be
              shown.
            + Rounding on input (READ) is now handled on systems where
*************** auto incr(T x) { return x++; }
*** 9637,9649 ****
              least significant [cf. IEC 60559:1989] for a tie, while
              compatible rounds away from zero in that case).
  
!   [28]Go
  
       * GCC 4.9 provides a complete implementation of the Go 1.2.1 release.
  
! [29]New Targets and Target Specific Improvements
  
!   [30]AArch64
  
       * The ARMv8-A crypto and CRC instructions are now supported through
         intrinsics. These are enabled when the architecture supports these
--- 9685,9697 ----
              least significant [cf. IEC 60559:1989] for a tie, while
              compatible rounds away from zero in that case).
  
!   [29]Go
  
       * GCC 4.9 provides a complete implementation of the Go 1.2.1 release.
  
! [30]New Targets and Target Specific Improvements
  
!   [31]AArch64
  
       * The ARMv8-A crypto and CRC instructions are now supported through
         intrinsics. These are enabled when the architecture supports these
*************** auto incr(T x) { return x++; }
*** 9671,9682 ****
         default by configuring GCC with the --enable-fix-cortex-a53-835769
         option.
  
!   [31]ARC
  
       * A port for Synopsys Designware ARC has been contributed by Embecosm
         and Synopsys Inc.
  
!   [32]ARM
  
       * Use of Advanced SIMD (Neon) for 64-bit scalar computations has been
         disabled by default. This was found to generate better code in only
--- 9719,9730 ----
         default by configuring GCC with the --enable-fix-cortex-a53-835769
         option.
  
!   [32]ARC
  
       * A port for Synopsys Designware ARC has been contributed by Embecosm
         and Synopsys Inc.
  
!   [33]ARM
  
       * Use of Advanced SIMD (Neon) for 64-bit scalar computations has been
         disabled by default. This was found to generate better code in only
*************** auto incr(T x) { return x++; }
*** 9719,9731 ****
       * A number of code generation improvements for Thumb2 to reduce code
         size when compiling for the M-profile processors.
  
!   [33]AVR
  
       * A new command-line option -mfract-convert-truncate has been added.
         It allows compiler to use truncation instead of rounding towards
         zero for fractional fixed-point types.
  
!   [34]IA-32/x86-64
  
       * -mfpmath=sse is now implied by -ffast-math on all targets where
         SSE2 is supported.
--- 9767,9779 ----
       * A number of code generation improvements for Thumb2 to reduce code
         size when compiling for the M-profile processors.
  
!   [34]AVR
  
       * A new command-line option -mfract-convert-truncate has been added.
         It allows compiler to use truncation instead of rounding towards
         zero for fractional fixed-point types.
  
!   [35]IA-32/x86-64
  
       * -mfpmath=sse is now implied by -ffast-math on all targets where
         SSE2 is supported.
*************** auto incr(T x) { return x++; }
*** 9741,9747 ****
         a file that are tagged with the corresponding target attribute
         without having to compile the entire file with the -mxxx option.
         This improves the usability of x86 intrinsics and is particularly
!        useful when doing [35]Function Multiversioning.
       * GCC now supports the new Intel microarchitecture named Silvermont
         through -march=silvermont.
       * GCC now supports the new Intel microarchitecture named Broadwell
--- 9789,9795 ----
         a file that are tagged with the corresponding target attribute
         without having to compile the entire file with the -mxxx option.
         This improves the usability of x86 intrinsics and is particularly
!        useful when doing [36]Function Multiversioning.
       * GCC now supports the new Intel microarchitecture named Silvermont
         through -march=silvermont.
       * GCC now supports the new Intel microarchitecture named Broadwell
*************** auto incr(T x) { return x++; }
*** 9765,9771 ****
       * Support for new AMD family 15h processors (Excavator core) is now
         available through the -march=bdver4 and -mtune=bdver4 options.
  
!   [36]MSP430
  
       * A new command-line option -mcpu= has been added to the MSP430 back
         end. This option is used to specify the ISA to be used. Accepted
--- 9813,9819 ----
       * Support for new AMD family 15h processors (Excavator core) is now
         available through the -march=bdver4 and -mtune=bdver4 options.
  
!   [37]MSP430
  
       * A new command-line option -mcpu= has been added to the MSP430 back
         end. This option is used to specify the ISA to be used. Accepted
*************** auto incr(T x) { return x++; }
*** 9776,9794 ****
         preprocessor symbol that will be recognised by the msp430.h header
         file.
  
!   [37]NDS32
  
       * A new nds32 port supports the 32-bit architecture from Andes
         Technology Corporation.
       * The port provides initial support for the V2, V3, V3m instruction
         set architectures.
  
!   [38]Nios II
  
       * A port for the Altera Nios II has been contributed by Mentor
         Graphics.
  
!   [39]PowerPC / PowerPC64 / RS6000
  
       * GCC now supports Power ISA 2.07, which includes support for
         Hardware Transactional Memory (HTM), Quadword atomics and several
--- 9824,9842 ----
         preprocessor symbol that will be recognised by the msp430.h header
         file.
  
!   [38]NDS32
  
       * A new nds32 port supports the 32-bit architecture from Andes
         Technology Corporation.
       * The port provides initial support for the V2, V3, V3m instruction
         set architectures.
  
!   [39]Nios II
  
       * A port for the Altera Nios II has been contributed by Mentor
         Graphics.
  
!   [40]PowerPC / PowerPC64 / RS6000
  
       * GCC now supports Power ISA 2.07, which includes support for
         Hardware Transactional Memory (HTM), Quadword atomics and several
*************** auto incr(T x) { return x++; }
*** 9824,9836 ****
         certain leaf function with -march=z10 or higher.
       * The LRA rtl pass replaces reload by default on S/390.
  
!   [40]RX
  
       * The port now allows to specify the RX100, RX200, and RX600
         processors with the command-line options -mcpu=rx100, -mcpu=rx200
         and -mcpu=rx600.
  
!   [41]SH
  
       * Minor improvements to code generated for integer arithmetic and
         code that involves the T bit.
--- 9872,9884 ----
         certain leaf function with -march=z10 or higher.
       * The LRA rtl pass replaces reload by default on S/390.
  
!   [41]RX
  
       * The port now allows to specify the RX100, RX200, and RX600
         processors with the command-line options -mcpu=rx100, -mcpu=rx200
         and -mcpu=rx600.
  
!   [42]SH
  
       * Minor improvements to code generated for integer arithmetic and
         code that involves the T bit.
*************** auto incr(T x) { return x++; }
*** 9847,9855 ****
       * The option -mcmpeqdi has been deprecated. Specifying it will result
         in a warning and will not influence code generation.
  
! [42]GCC 4.9.1
  
!    This is the [43]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.9.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
--- 9895,9903 ----
       * The option -mcmpeqdi has been deprecated. Specifying it will result
         in a warning and will not influence code generation.
  
! [43]GCC 4.9.1
  
!    This is the [44]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.9.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
*************** auto incr(T x) { return x++; }
*** 9857,9897 ****
     Version 4.0 of the OpenMP specification is supported even in Fortran,
     not just C and C++.
  
! [44]GCC 4.9.2
  
!    This is the [45]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.9.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [46]GCC 4.9.3
  
!    This is the [47]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.9.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [48]GCC 4.9.4
  
!    This is the [49]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.9.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [50]GCC manuals. If that fails, the
!     [51]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [52]gcc@gcc.gnu.org. All of [53]our lists have public
      archives.
  
!    Copyright (C) [54]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [55]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 9905,9945 ----
     Version 4.0 of the OpenMP specification is supported even in Fortran,
     not just C and C++.
  
! [45]GCC 4.9.2
  
!    This is the [46]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.9.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [47]GCC 4.9.3
  
!    This is the [48]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.9.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [49]GCC 4.9.4
  
!    This is the [50]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.9.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [51]GCC manuals. If that fails, the
!     [52]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [53]gcc@gcc.gnu.org. All of [54]our lists have public
      archives.
  
!    Copyright (C) [55]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [56]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 9905,9957 ****
     8. https://gcc.gnu.org/gcc-4.9/changes.html#c-family
     9. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Language-Independent-Options.html#index-fdiagnostics-color-252
    10. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Loop-Specific-Pragmas.html
!   11. https://gcc.gnu.org/gcc-4.9/changes.html#cxx
!   12. https://gcc.gnu.org/projects/cxx1y.html
!   13. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html
!   14. https://gcc.gnu.org/projects/cxx1y.html
    15. https://gcc.gnu.org/projects/cxx1y.html
    16. https://gcc.gnu.org/projects/cxx1y.html
    17. https://gcc.gnu.org/projects/cxx1y.html
    18. https://gcc.gnu.org/projects/cxx1y.html
!   19. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3889.pdf
!   20. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/libstdc++/manual/manual/status.html#status.iso.2011
!   21. https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2014
!   22. https://gcc.gnu.org/gcc-4.9/changes.html#fortran
!   23. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gfortran/Argument-passing-conventions.html
!   24. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gfortran/GNU-Fortran-Compiler-Directives.html
!   25. https://gcc.gnu.org/wiki/Fortran2003Status
!   26. https://gcc.gnu.org/wiki/Fortran2008Status
!   27. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gfortran/Debugging-Options.html
!   28. https://gcc.gnu.org/gcc-4.9/changes.html#go
!   29. https://gcc.gnu.org/gcc-4.9/changes.html#targets
!   30. https://gcc.gnu.org/gcc-4.9/changes.html#aarch64
!   31. https://gcc.gnu.org/gcc-4.9/changes.html#arc
!   32. https://gcc.gnu.org/gcc-4.9/changes.html#arm
!   33. https://gcc.gnu.org/gcc-4.9/changes.html#avr
!   34. https://gcc.gnu.org/gcc-4.9/changes.html#x86
!   35. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Multiversioning.html
!   36. https://gcc.gnu.org/gcc-4.9/changes.html#msp430
!   37. https://gcc.gnu.org/gcc-4.9/changes.html#nds32
!   38. https://gcc.gnu.org/gcc-4.9/changes.html#nios2
!   39. https://gcc.gnu.org/gcc-4.9/changes.html#powerpc
!   40. https://gcc.gnu.org/gcc-4.9/changes.html#rx
!   41. https://gcc.gnu.org/gcc-4.9/changes.html#sh
!   42. https://gcc.gnu.org/gcc-4.9/changes.html#GCC4.9.1
!   43. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.9.1
!   44. https://gcc.gnu.org/gcc-4.9/changes.html#GCC4.9.2
!   45. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.9.2
!   46. https://gcc.gnu.org/gcc-4.9/changes.html#GCC4.9.3
!   47. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.9.3
!   48. https://gcc.gnu.org/gcc-4.9/changes.html#GCC4.9.4
!   49. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.9.4
!   50. https://gcc.gnu.org/onlinedocs/
!   51. mailto:gcc-help@gcc.gnu.org
!   52. mailto:gcc@gcc.gnu.org
!   53. https://gcc.gnu.org/lists.html
!   54. https://www.fsf.org/
!   55. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.8/index.html
                               GCC 4.8 Release Series
  
     (This release series is no longer supported.)
--- 9953,10007 ----
     8. https://gcc.gnu.org/gcc-4.9/changes.html#c-family
     9. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Language-Independent-Options.html#index-fdiagnostics-color-252
    10. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Loop-Specific-Pragmas.html
!   11. https://gcc.gnu.org/gcc-4.9/changes.html#c
!   12. https://gcc.gnu.org/gcc-4.9/changes.html#cxx
!   13. https://gcc.gnu.org/projects/cxx1y.html
!   14. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html
    15. https://gcc.gnu.org/projects/cxx1y.html
    16. https://gcc.gnu.org/projects/cxx1y.html
    17. https://gcc.gnu.org/projects/cxx1y.html
    18. https://gcc.gnu.org/projects/cxx1y.html
!   19. https://gcc.gnu.org/projects/cxx1y.html
!   20. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3889.pdf
!   21. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/libstdc++/manual/manual/status.html#status.iso.2011
!   22. https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2014
!   23. https://gcc.gnu.org/gcc-4.9/changes.html#fortran
!   24. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gfortran/Argument-passing-conventions.html
!   25. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gfortran/GNU-Fortran-Compiler-Directives.html
!   26. https://gcc.gnu.org/wiki/Fortran2003Status
!   27. https://gcc.gnu.org/wiki/Fortran2008Status
!   28. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gfortran/Debugging-Options.html
!   29. https://gcc.gnu.org/gcc-4.9/changes.html#go
!   30. https://gcc.gnu.org/gcc-4.9/changes.html#targets
!   31. https://gcc.gnu.org/gcc-4.9/changes.html#aarch64
!   32. https://gcc.gnu.org/gcc-4.9/changes.html#arc
!   33. https://gcc.gnu.org/gcc-4.9/changes.html#arm
!   34. https://gcc.gnu.org/gcc-4.9/changes.html#avr
!   35. https://gcc.gnu.org/gcc-4.9/changes.html#x86
!   36. https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Function-Multiversioning.html
!   37. https://gcc.gnu.org/gcc-4.9/changes.html#msp430
!   38. https://gcc.gnu.org/gcc-4.9/changes.html#nds32
!   39. https://gcc.gnu.org/gcc-4.9/changes.html#nios2
!   40. https://gcc.gnu.org/gcc-4.9/changes.html#powerpc
!   41. https://gcc.gnu.org/gcc-4.9/changes.html#rx
!   42. https://gcc.gnu.org/gcc-4.9/changes.html#sh
!   43. https://gcc.gnu.org/gcc-4.9/changes.html#GCC4.9.1
!   44. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.9.1
!   45. https://gcc.gnu.org/gcc-4.9/changes.html#GCC4.9.2
!   46. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.9.2
!   47. https://gcc.gnu.org/gcc-4.9/changes.html#GCC4.9.3
!   48. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.9.3
!   49. https://gcc.gnu.org/gcc-4.9/changes.html#GCC4.9.4
!   50. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.9.4
!   51. https://gcc.gnu.org/onlinedocs/
!   52. mailto:gcc-help@gcc.gnu.org
!   53. mailto:gcc@gcc.gnu.org
!   54. https://gcc.gnu.org/lists.html
!   55. https://www.fsf.org/
!   56. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.8/index.html
+ 
                               GCC 4.8 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 10017,10023 ****
     provided this notice is preserved.
  
     These pages are [25]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 10067,10073 ----
     provided this notice is preserved.
  
     These pages are [25]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 10048,10053 ****
--- 10098,10104 ----
    25. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.8/changes.html
+ 
                               GCC 4.8 Release Series
                          Changes, New Features, and Fixes
  
*************** New Languages and Language specific impr
*** 10166,10173 ****
         diagnostics. Combined with the caret information, an example
         diagnostic showing these two features is:
  
! t.c:1:94: error: invalid operands to binary < (have ‘struct mystruct’ and ‘float
! ’)
   #define MYMAX(A,B)    __extension__ ({ __typeof__(A) __a = (A); __typeof__(B) _
  _b = (B); __a < __b ? __b : __a; })
  
--- 10217,10224 ----
         diagnostics. Combined with the caret information, an example
         diagnostic showing these two features is:
  
! t.c:1:94: error: invalid operands to binary < (have `struct mystruct' and `float
! ')
   #define MYMAX(A,B)    __extension__ ({ __typeof__(A) __a = (A); __typeof__(B) _
  _b = (B); __a < __b ? __b : __a; })
  
*************** int i = A().f();  // error, f() requires
*** 10291,10298 ****
              older versions except as noted below.
            + ABI: Some internal names (used in the assembler/object file)
              have changed for symbols declared in the specification part of
!             a module. If an affected module – or a file using it via use
!             association – is recompiled, the module and all files which
              directly use such symbols have to be recompiled as well. This
              change only affects the following kind of module symbols:
                 o Procedure pointers. Note: C-interoperable function
--- 10342,10349 ----
              older versions except as noted below.
            + ABI: Some internal names (used in the assembler/object file)
              have changed for symbols declared in the specification part of
!             a module. If an affected module - or a file using it via use
!             association - is recompiled, the module and all files which
              directly use such symbols have to be recompiled as well. This
              change only affects the following kind of module symbols:
                 o Procedure pointers. Note: C-interoperable function
*************** int i = A().f();  // error, f() requires
*** 10319,10325 ****
       * The [21]-Wcompare-reals command-line option has been added. When
         this is set, warnings are issued when comparing REAL or COMPLEX
         types for equality and inequality; consider replacing a == b by
!        abs(a−b) < eps with a suitable eps. -Wcompare-reals is enabled by
         -Wextra.
       * The [22]-Wtarget-lifetime command-line option has been added
         (enabled with -Wall), which warns if the pointer in a pointer
--- 10370,10376 ----
       * The [21]-Wcompare-reals command-line option has been added. When
         this is set, warnings are issued when comparing REAL or COMPLEX
         types for equality and inequality; consider replacing a == b by
!        abs(a-b) < eps with a suitable eps. -Wcompare-reals is enabled by
         -Wextra.
       * The [22]-Wtarget-lifetime command-line option has been added
         (enabled with -Wall), which warns if the pointer in a pointer
*************** int i = A().f();  // error, f() requires
*** 10331,10337 ****
         4.0e0).
         (For Fortran source code, consider replacing the "q" in
         floating-point literals by a kind parameter (e.g. 4.0e0_qp with a
!        suitable qp). Note that – in Fortran source code – replacing "q" by
         a simple "e" is not equivalent.)
       * The GFORTRAN_TMPDIR environment variable for specifying a
         non-default directory for files opened with STATUS="SCRATCH", is
--- 10382,10388 ----
         4.0e0).
         (For Fortran source code, consider replacing the "q" in
         floating-point literals by a kind parameter (e.g. 4.0e0_qp with a
!        suitable qp). Note that - in Fortran source code - replacing "q" by
         a simple "e" is not equivalent.)
       * The GFORTRAN_TMPDIR environment variable for specifying a
         non-default directory for files opened with STATUS="SCRATCH", is
*************** int i = A().f();  // error, f() requires
*** 10369,10375 ****
         architecture from ARM. Note that this is a separate port from the
         existing 32-bit ARM port.
       * The port provides initial support for the Cortex-A53 and the
!        Cortex-A57 processors with the command line options
         -mcpu=cortex-a53 and -mcpu=cortex-a57.
       * As of GCC 4.8.4 a workaround for the ARM Cortex-A53 erratum 835769
         has been added and can be enabled by giving the
--- 10420,10426 ----
         architecture from ARM. Note that this is a separate port from the
         existing 32-bit ARM port.
       * The port provides initial support for the Cortex-A53 and the
!        Cortex-A57 processors with the command-line options
         -mcpu=cortex-a53 and -mcpu=cortex-a57.
       * As of GCC 4.8.4 a workaround for the ARM Cortex-A53 erratum 835769
         has been added and can be enabled by giving the
*************** int i = A().f();  // error, f() requires
*** 10434,10441 ****
      }
         The inline assembler in this example will generate code like
      mov r24, 8+7
!        provided c is allocated to R24 and val is allocated to R8…R15. This
!        works because the GNU assembler accepts plain register numbers
         without register prefix.
       * Static initializers with 3-byte symbols are supported now:
      extern const __memx char foo;
--- 10485,10492 ----
      }
         The inline assembler in this example will generate code like
      mov r24, 8+7
!        provided c is allocated to R24 and val is allocated to R8...R15.
!        This works because the GNU assembler accepts plain register numbers
         without register prefix.
       * Static initializers with 3-byte symbols are supported now:
      extern const __memx char foo;
*************** int i = A().f();  // error, f() requires
*** 10769,10775 ****
     provided this notice is preserved.
  
     These pages are [67]maintained by the GCC team. Last modified
!    2025-02-28.
  
  References
  
--- 10820,10826 ----
     provided this notice is preserved.
  
     These pages are [67]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 10842,10847 ****
--- 10893,10899 ----
    67. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.7/index.html
+ 
                               GCC 4.7 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 10904,10910 ****
     provided this notice is preserved.
  
     These pages are [23]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 10956,10962 ----
     provided this notice is preserved.
  
     These pages are [23]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 10933,10938 ****
--- 10985,10991 ----
    23. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.7/changes.html
+ 
                               GCC 4.7 Release Series
                          Changes, New Features, and Fixes
  
*************** int x;
*** 11177,11183 ****
  res = 2 + a;  /* means {2,2,2,2} + a  */
  res = a - x;  /* means a - {x,x,x,x}  */
  
!   C
  
       * There is support for some more features from the C11 revision of
         the ISO C standard. GCC now accepts the options -std=c11 and
--- 11230,11236 ----
  res = 2 + a;  /* means {2,2,2,2} + a  */
  res = a - x;  /* means a - {x,x,x,x}  */
  
!   [5]C
  
       * There is support for some more features from the C11 revision of
         the ISO C standard. GCC now accepts the options -std=c11 and
*************** res = a - x;  /* means a - {x,x,x,x}  */
*** 11191,11202 ****
            + A built-in function __builtin_complex is provided to support C
              library implementation of the CMPLX family of macros.
  
!   [5]C++
  
       * G++ now accepts the -std=c++11, -std=gnu++11, and -Wc++11-compat
         options, which are equivalent to -std=c++0x, -std=gnu++0x, and
         -Wc++0x-compat, respectively.
!      * G++ now implements [6]C++11 extended friend syntax:
  
  template
  class Q
--- 11244,11255 ----
            + A built-in function __builtin_complex is provided to support C
              library implementation of the CMPLX family of macros.
  
!   [6]C++
  
       * G++ now accepts the -std=c++11, -std=gnu++11, and -Wc++11-compat
         options, which are equivalent to -std=c++0x, -std=gnu++0x, and
         -Wc++0x-compat, respectively.
!      * G++ now implements [7]C++11 extended friend syntax:
  
  template
  class Q
*************** struct B
*** 11211,11217 ****
    int ar[Q::I];
  };
  
!      * Thanks to Ville Voutilainen, G++ now implements [7]C++11 explicit
         override control.
  
  struct B {
--- 11264,11270 ----
    int ar[Q::I];
  };
  
!      * Thanks to Ville Voutilainen, G++ now implements [8]C++11 explicit
         override control.
  
  struct B {
*************** struct D : B {
*** 11228,11253 ****
  struct E final { };
  struct F: E { }; // error: deriving from final class
  
!      * G++ now implements [8]C++11 non-static data member initializers.
  
  struct A {
    int i = 42;
  } a; // initializes a.i to 42
  
!      * Thanks to Ed Smith-Rowland, G++ now implements [9]C++11
         user-defined literals.
  
  // Not actually a good approximation.  :)
  constexpr long double operator"" _degrees (long double d) { return d * 0.0175; }
  long double pi = 180.0_degrees;
  
!      * G++ now implements [10]C++11 alias-declarations.
  
  template  using Ptr = T*;
  Ptr ip;  // decltype(ip) is int*
  
!      * Thanks to Ville Voutilainen and Pedro Lamarão, G++ now implements
!        [11]C++11 delegating constructors.
  
  struct A {
    A(int);
--- 11281,11306 ----
  struct E final { };
  struct F: E { }; // error: deriving from final class
  
!      * G++ now implements [9]C++11 non-static data member initializers.
  
  struct A {
    int i = 42;
  } a; // initializes a.i to 42
  
!      * Thanks to Ed Smith-Rowland, G++ now implements [10]C++11
         user-defined literals.
  
  // Not actually a good approximation.  :)
  constexpr long double operator"" _degrees (long double d) { return d * 0.0175; }
  long double pi = 180.0_degrees;
  
!      * G++ now implements [11]C++11 alias-declarations.
  
  template  using Ptr = T*;
  Ptr ip;  // decltype(ip) is int*
  
!      * Thanks to Ville Voutilainen and Pedro Lamaro, G++ now implements
!        [12]C++11 delegating constructors.
  
  struct A {
    A(int);
*************** const int &y = f(2);
*** 11326,11339 ****
         Using-declarations are to be used instead. Furthermore, some
         efforts have been made to improve the support of class scope
         using-declarations. In particular, using-declarations referring to
!        a dependent type now work as expected ([12]bug c++/14258).
       * The ELF symbol visibility of a template instantiation is now
         properly constrained by the visibility of its template arguments
!        ([13]bug c++/35688).
  
      Runtime Library (libstdc++)
  
!      * [14]Improved experimental support for the new ISO C++ standard,
         C++11, including:
            + using noexcept in most of the library;
            + implementations of pointer_traits, allocator_traits and
--- 11379,11392 ----
         Using-declarations are to be used instead. Furthermore, some
         efforts have been made to improve the support of class scope
         using-declarations. In particular, using-declarations referring to
!        a dependent type now work as expected ([13]bug c++/14258).
       * The ELF symbol visibility of a template instantiation is now
         properly constrained by the visibility of its template arguments
!        ([14]bug c++/35688).
  
      Runtime Library (libstdc++)
  
!      * [15]Improved experimental support for the new ISO C++ standard,
         C++11, including:
            + using noexcept in most of the library;
            + implementations of pointer_traits, allocator_traits and
*************** const int &y = f(2);
*** 11347,11375 ****
       * Debug Mode iterators for unordered associative containers.
       * Avoid polluting the global namespace and do not include .
  
!   [15]Fortran
  
!      * The compile flag [16]-fstack-arrays has been added, which causes
         all local arrays to be put on stack memory. For some programs this
         will improve the performance significantly. If your program uses
         very large local arrays, it is possible that you will have to
         extend your runtime limits for stack memory.
!      * The [17]-Ofast flag now also implies [18]-fno-protect-parens and
!        [19]-fstack-arrays.
       * Front-end optimizations can now be selected by the
!        [20]-ffrontend-optimize option and deselected by the
         -fno-frontend-optimize option.
       * When front-end optimization removes a function call,
!        [21]-Wfunction-elimination warns about that.
       * When performing front-end-optimization, the
!        [22]-faggressive-function-elimination option allows the removal of
         duplicate function calls even for impure functions.
!      * The flag [23]-Wreal-q-constant has been added, which warns if
         floating-point literals have been specified using q (such as
         1.0q0); the q marker is now supported as a vendor extension to
         denote quad precision (REAL(16) or, if not available, REAL(10)).
         Consider using a kind parameter (such as in 1.0_qp) instead, which
!        can be obtained via [24]SELECTED_REAL_KIND.
       * The GFORTRAN_USE_STDERR environment variable has been removed. GNU
         Fortran now always prints error messages to standard error. If you
         wish to redirect standard error, please consult the manual for your
--- 11400,11428 ----
       * Debug Mode iterators for unordered associative containers.
       * Avoid polluting the global namespace and do not include .
  
!   [16]Fortran
  
!      * The compile flag [17]-fstack-arrays has been added, which causes
         all local arrays to be put on stack memory. For some programs this
         will improve the performance significantly. If your program uses
         very large local arrays, it is possible that you will have to
         extend your runtime limits for stack memory.
!      * The [18]-Ofast flag now also implies [19]-fno-protect-parens and
!        [20]-fstack-arrays.
       * Front-end optimizations can now be selected by the
!        [21]-ffrontend-optimize option and deselected by the
         -fno-frontend-optimize option.
       * When front-end optimization removes a function call,
!        [22]-Wfunction-elimination warns about that.
       * When performing front-end-optimization, the
!        [23]-faggressive-function-elimination option allows the removal of
         duplicate function calls even for impure functions.
!      * The flag [24]-Wreal-q-constant has been added, which warns if
         floating-point literals have been specified using q (such as
         1.0q0); the q marker is now supported as a vendor extension to
         denote quad precision (REAL(16) or, if not available, REAL(10)).
         Consider using a kind parameter (such as in 1.0_qp) instead, which
!        can be obtained via [25]SELECTED_REAL_KIND.
       * The GFORTRAN_USE_STDERR environment variable has been removed. GNU
         Fortran now always prints error messages to standard error. If you
         wish to redirect standard error, please consult the manual for your
*************** const int &y = f(2);
*** 11379,11410 ****
         gfortran will now always abort the program. Whether a core dump is
         generated depends on the user environment settings; see the ulimit
         -c setting for POSIX shells, limit coredumpsize for C shells, and
!        the [25]WER user-mode dumps settings on Windows.
!      * The [26]-fbacktrace option is now enabled by default. When
         encountering a fatal error, gfortran will attempt to print a
         backtrace to standard error before aborting. It can be disabled
         with -fno-backtrace. Note: On POSIX targets with the addr2line
         utility from GNU binutils, GNU Fortran can print a backtrace with
         function name, file name, line number information in addition to
         the addresses; otherwise only the addresses are printed.
!      * [27]Fortran 2003:
            + Generic interface names which have the same name as derived
              types are now supported, which allows to write constructor
              functions. Note that Fortran does not support static
              constructor functions; only default initialization or an
              explicit structure-constructor initialization are available.
!           + [28]Polymorphic (class) arrays are now supported.
!      * [29]Fortran 2008:
            + Support for the DO CONCURRENT construct has been added, which
              allows the user to specify that individual loop iterations
              have no interdependencies.
!           + [30]Coarrays: Full single-image support except for polymorphic
              coarrays. Additionally, preliminary support for multiple
!             images via an MPI-based [31]coarray communication library has
              been added. Note: The library version is not yet usable as
              remote coarray access is not yet possible.
!      * [32]TS 29113:
!           + New flag [33]-std=f2008ts permits programs that are expected
              to conform to the Fortran 2008 standard and the draft
              Technical Specification (TS) 29113 on Further Interoperability
              of Fortran with C.
--- 11432,11463 ----
         gfortran will now always abort the program. Whether a core dump is
         generated depends on the user environment settings; see the ulimit
         -c setting for POSIX shells, limit coredumpsize for C shells, and
!        the [26]WER user-mode dumps settings on Windows.
!      * The [27]-fbacktrace option is now enabled by default. When
         encountering a fatal error, gfortran will attempt to print a
         backtrace to standard error before aborting. It can be disabled
         with -fno-backtrace. Note: On POSIX targets with the addr2line
         utility from GNU binutils, GNU Fortran can print a backtrace with
         function name, file name, line number information in addition to
         the addresses; otherwise only the addresses are printed.
!      * [28]Fortran 2003:
            + Generic interface names which have the same name as derived
              types are now supported, which allows to write constructor
              functions. Note that Fortran does not support static
              constructor functions; only default initialization or an
              explicit structure-constructor initialization are available.
!           + [29]Polymorphic (class) arrays are now supported.
!      * [30]Fortran 2008:
            + Support for the DO CONCURRENT construct has been added, which
              allows the user to specify that individual loop iterations
              have no interdependencies.
!           + [31]Coarrays: Full single-image support except for polymorphic
              coarrays. Additionally, preliminary support for multiple
!             images via an MPI-based [32]coarray communication library has
              been added. Note: The library version is not yet usable as
              remote coarray access is not yet possible.
!      * [33]TS 29113:
!           + New flag [34]-std=f2008ts permits programs that are expected
              to conform to the Fortran 2008 standard and the draft
              Technical Specification (TS) 29113 on Further Interoperability
              of Fortran with C.
*************** const int &y = f(2);
*** 11415,11432 ****
              compatible with the candidate draft of TS 29113 (since GCC
              4.6).
  
!   [34]Go
  
!      * GCC 4.7 implements the [35]Go 1 language standard. The library
         support in 4.7.0 is not quite complete, due to release timing.
         Release 4.7.1 includes complete support for Go 1. The Go library is
         from the Go 1.0.1 release.
       * Go has been tested on GNU/Linux and Solaris platforms. It may work
         on other platforms as well.
  
! [36]New Targets and Target Specific Improvements
  
!   [37]ARM
  
       * GCC now supports the Cortex-A7 processor implementing the v7-a
         version of the architecture using the option -mcpu=cortex-a7.
--- 11468,11485 ----
              compatible with the candidate draft of TS 29113 (since GCC
              4.6).
  
!   [35]Go
  
!      * GCC 4.7 implements the [36]Go 1 language standard. The library
         support in 4.7.0 is not quite complete, due to release timing.
         Release 4.7.1 includes complete support for Go 1. The Go library is
         from the Go 1.0.1 release.
       * Go has been tested on GNU/Linux and Solaris platforms. It may work
         on other platforms as well.
  
! [37]New Targets and Target Specific Improvements
  
!   [38]ARM
  
       * GCC now supports the Cortex-A7 processor implementing the v7-a
         version of the architecture using the option -mcpu=cortex-a7.
*************** const int &y = f(2);
*** 11436,11462 ****
       * A new option -mvectorize-with-neon-double was added to allow users
         to change the vector size to 64 bits.
  
!   [38]AVR
  
       * The AVR port's libgcc has been improved and its multilib structure
         has been enhanced. As a result, all objects contributing to an
         application must either be compiled with GCC versions up to 4.6.x
         or with GCC versions 4.7.1 or later. If the compiler is used with
         AVR-LibC, you need a version that supports the new layout, i.e.
!        implements [39]#35407.
       * The -mshort-calls command-line option has been deprecated. It will
         be removed in the GCC 4.8 release. See -mrelax for a replacement.
       * The compiled code only references startup code that clears .bss and
         the common section resp. initializes the .data and .rodata section
         provided respective sections (or subsections thereof) are not
!        empty, see [40]PR18145. Applications that put all static storage
         objects into non-standard sections and / or define all static
         storage objects in assembler modules, must reference __do_clear_bss
         resp. __do_copy_data by hand or undefine the symbol(s) by means of
         -Wl,-u,__do_clear_bss resp. -Wl,-u,__do_copy_data.
       * GCC now supports the XMEGA architecture. This requires GNU Binutils
         2.22 or later.
!      * Support for the [41]named address spaces __flash, __flash1, …,
         __flash5 and __memx has been added. These address spaces locate
         read-only data in flash memory and allow reading from flash memory
         by means of ordinary C code, i.e. without the need of (inline)
--- 11489,11515 ----
       * A new option -mvectorize-with-neon-double was added to allow users
         to change the vector size to 64 bits.
  
!   [39]AVR
  
       * The AVR port's libgcc has been improved and its multilib structure
         has been enhanced. As a result, all objects contributing to an
         application must either be compiled with GCC versions up to 4.6.x
         or with GCC versions 4.7.1 or later. If the compiler is used with
         AVR-LibC, you need a version that supports the new layout, i.e.
!        implements [40]#35407.
       * The -mshort-calls command-line option has been deprecated. It will
         be removed in the GCC 4.8 release. See -mrelax for a replacement.
       * The compiled code only references startup code that clears .bss and
         the common section resp. initializes the .data and .rodata section
         provided respective sections (or subsections thereof) are not
!        empty, see [41]PR18145. Applications that put all static storage
         objects into non-standard sections and / or define all static
         storage objects in assembler modules, must reference __do_clear_bss
         resp. __do_copy_data by hand or undefine the symbol(s) by means of
         -Wl,-u,__do_clear_bss resp. -Wl,-u,__do_copy_data.
       * GCC now supports the XMEGA architecture. This requires GNU Binutils
         2.22 or later.
!      * Support for the [42]named address spaces __flash, __flash1, ...,
         __flash5 and __memx has been added. These address spaces locate
         read-only data in flash memory and allow reading from flash memory
         by means of ordinary C code, i.e. without the need of (inline)
*************** int add_values (const __flash int *p, in
*** 11471,11482 ****
  
       * Support has been added for the AVR-specific configure option
         --with-avrlibc=yes in order to arrange for better integration of
!        [42]AVR-Libc. This configure option is supported in avr-gcc v4.7.2
         and newer and will only take effect in non-RTEMS configurations. If
         avr-gcc is configured for RTEMS, the option will be ignored which
!        is the same as specifying --with-avrlibc=no. See [43]PR54461 for
         more technical details.
!      * Support for AVR-specific [44]built-in functions has been added.
       * Support has been added for the signed and unsigned 24-bit scalar
         integer types __int24 and __uint24.
       * New command-line options -maccumulate-args, -mbranch-cost=cost and
--- 11524,11535 ----
  
       * Support has been added for the AVR-specific configure option
         --with-avrlibc=yes in order to arrange for better integration of
!        [43]AVR-Libc. This configure option is supported in avr-gcc v4.7.2
         and newer and will only take effect in non-RTEMS configurations. If
         avr-gcc is configured for RTEMS, the option will be ignored which
!        is the same as specifying --with-avrlibc=no. See [44]PR54461 for
         more technical details.
!      * Support for AVR-specific [45]built-in functions has been added.
       * Support has been added for the signed and unsigned 24-bit scalar
         integer types __int24 and __uint24.
       * New command-line options -maccumulate-args, -mbranch-cost=cost and
*************** void set_portb (uint8_t value)
*** 11500,11506 ****
         suitable to be used as operand in an I/O command. The address must
         be a constant integer known at compile time.
       * The inline assembler constraint "R" to represent integers in the
!        range −6 … 5 has been removed without replacement.
       * Many optimizations to:
            + 64-bit integer arithmetic
            + Widening multiplication
--- 11553,11559 ----
         suitable to be used as operand in an I/O command. The address must
         be a constant integer known at compile time.
       * The inline assembler constraint "R" to represent integers in the
!        range -6 ... 5 has been removed without replacement.
       * Many optimizations to:
            + 64-bit integer arithmetic
            + Widening multiplication
*************** void set_portb (uint8_t value)
*** 11512,11518 ****
            + If-else decision trees generated by switch instructions
            + Merging of data located in flash memory
            + New libgcc variants for devices with 8-bit wide stack pointer
!           + …
       * Better documentation:
            + Handling of EIND and indirect jumps on devices with more than
              128 KiB of program memory.
--- 11565,11571 ----
            + If-else decision trees generated by switch instructions
            + Merging of data located in flash memory
            + New libgcc variants for devices with 8-bit wide stack pointer
!           + ...
       * Better documentation:
            + Handling of EIND and indirect jumps on devices with more than
              128 KiB of program memory.
*************** void set_portb (uint8_t value)
*** 11558,11564 ****
         FMA, BMI, BMI2, LZCNT is available through -march=core-avx2.
       * Support for new AMD family 15h processors (Piledriver core) is now
         available through -march=bdver2 and -mtune=bdver2 options.
!      * Support for [45]the x32 psABI is now available through the -mx32
         option.
       * Windows mingw targets are using the -mms-bitfields option by
         default.
--- 11611,11617 ----
         FMA, BMI, BMI2, LZCNT is available through -march=core-avx2.
       * Support for new AMD family 15h processors (Piledriver core) is now
         available through -march=bdver2 and -mtune=bdver2 options.
!      * Support for [46]the x32 psABI is now available through the -mx32
         option.
       * Windows mingw targets are using the -mms-bitfields option by
         default.
*************** void set_portb (uint8_t value)
*** 11567,11573 ****
       * Support for the configure option --with-threads=posix for Windows
         mingw targets.
  
!   [46]MIPS
  
       * GCC now supports thread-local storage (TLS) for MIPS16. This
         requires GNU binutils 2.22 or later.
--- 11620,11626 ----
       * Support for the configure option --with-threads=posix for Windows
         mingw targets.
  
!   [47]MIPS
  
       * GCC now supports thread-local storage (TLS) for MIPS16. This
         requires GNU binutils 2.22 or later.
*************** Other significant improvements
*** 11673,11729 ****
         the DW_AT_producer attribute string in the DWARF debugging
         information.
       * GCC now supports various new GNU extensions to the DWARF debugging
!        information format, like [47]entry value and [48]call site
!        information, [49]typed DWARF stack or [50]a more compact macro
         representation. Support for these extensions has been added to GDB
         7.4. They can be disabled through the -gstrict-dwarf command-line
         option.
  
! [51]GCC 4.7.1
  
!    This is the [52]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.7.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
!    The Go front end in the 4.7.1 release fully supports the [53]Go 1
     language standard.
  
! [54]GCC 4.7.2
  
!    This is the [55]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.7.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [56]GCC 4.7.3
  
!    This is the [57]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.7.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [58]GCC 4.7.4
  
!    This is the [59]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.7.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [60]GCC manuals. If that fails, the
!     [61]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [62]gcc@gcc.gnu.org. All of [63]our lists have public
      archives.
  
!    Copyright (C) [64]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [65]maintained by the GCC team. Last modified
!    2025-02-28.
  
  References
  
--- 11726,11782 ----
         the DW_AT_producer attribute string in the DWARF debugging
         information.
       * GCC now supports various new GNU extensions to the DWARF debugging
!        information format, like [48]entry value and [49]call site
!        information, [50]typed DWARF stack or [51]a more compact macro
         representation. Support for these extensions has been added to GDB
         7.4. They can be disabled through the -gstrict-dwarf command-line
         option.
  
! [52]GCC 4.7.1
  
!    This is the [53]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.7.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
!    The Go front end in the 4.7.1 release fully supports the [54]Go 1
     language standard.
  
! [55]GCC 4.7.2
  
!    This is the [56]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.7.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [57]GCC 4.7.3
  
!    This is the [58]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.7.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [59]GCC 4.7.4
  
!    This is the [60]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.7.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [61]GCC manuals. If that fails, the
!     [62]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [63]gcc@gcc.gnu.org. All of [64]our lists have public
      archives.
  
!    Copyright (C) [65]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [66]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 11731,11799 ****
     2. https://gcc.gnu.org/gcc-4.7/porting_to.html
     3. https://gcc.gnu.org/wiki/TransactionalMemory
     4. https://gcc.gnu.org/wiki/Atomic/GCCMM
!    5. https://gcc.gnu.org/gcc-4.7/changes.html#cxx
!    6. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
     7. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
     8. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
     9. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
    10. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
    11. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
!   12. https://gcc.gnu.org/PR14258
!   13. https://gcc.gnu.org/PR35688
!   14. https://gcc.gnu.org/onlinedocs/gcc-4.7.4/libstdc++/manual/manual/status.html#status.iso.2011
!   15. https://gcc.gnu.org/gcc-4.7/changes.html#fortran
!   16. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack-arrays_007d-254
!   17. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Optimize-Options.html#index-Ofast-689
!   18. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfno-protect-parens_007d-270
!   19. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack-arrays_007d-254
!   20. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfrontend-optimize_007d-275
!   21. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Error-and-Warning-Options.html#index-g_t_0040code_007bWfunction-elimination_007d-170
!   22. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfaggressive-function-elimination_007d-270
!   23. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Error-and-Warning-Options.html#index-g_t_0040code_007bWreal-q-constant_007d-149
!   24. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/SELECTED_005fREAL_005fKIND.html
!   25. https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps
!   26. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Debugging-Options.html#index-g_t_0040code_007bfno-backtrace_007d-183
!   27. https://gcc.gnu.org/wiki/Fortran2003Status
!   28. https://gcc.gnu.org/wiki/OOP
!   29. https://gcc.gnu.org/wiki/Fortran2008Status
!   30. https://gcc.gnu.org/wiki/Coarray
!   31. https://gcc.gnu.org/wiki/CoarrayLib
!   32. https://gcc.gnu.org/wiki/TS29113Status
!   33. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Fortran-Dialect-Options.html#index-g_t_0040code_007bstd_003d_007d_0040var_007bstd_007d-option-53
!   34. https://gcc.gnu.org/gcc-4.7/changes.html#go
!   35. https://go.dev/doc/go1
!   36. https://gcc.gnu.org/gcc-4.7/changes.html#targets
!   37. https://gcc.gnu.org/gcc-4.7/changes.html#arm
!   38. https://gcc.gnu.org/gcc-4.7/changes.html#avr
!   39. http://savannah.nongnu.org/bugs/?35407
!   40. https://gcc.gnu.org/PR18145
!   41. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Named-Address-Spaces.html
!   42. http://www.nongnu.org/avr-libc/
!   43. https://gcc.gnu.org/PR54461
!   44. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/AVR-Built_002din-Functions.html
!   45. https://sites.google.com/site/x32abi/
!   46. https://gcc.gnu.org/gcc-4.7/changes.html#mips
!   47. https://dwarfstd.org/issues/100909.1.html
!   48. https://dwarfstd.org/issues/100909.2.html
!   49. https://dwarfstd.org/issues/140425.1.html
!   50. https://dwarfstd.org/issues/110722.1.html
!   51. https://gcc.gnu.org/gcc-4.7/changes.html#GCC4.7.1
!   52. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.1
!   53. https://go.dev/doc/go1
!   54. https://gcc.gnu.org/gcc-4.7/changes.html#GCC4.7.2
!   55. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.2
!   56. https://gcc.gnu.org/gcc-4.7/changes.html#GCC4.7.3
!   57. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.3
!   58. https://gcc.gnu.org/gcc-4.7/changes.html#GCC4.7.4
!   59. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.4
!   60. https://gcc.gnu.org/onlinedocs/
!   61. mailto:gcc-help@gcc.gnu.org
!   62. mailto:gcc@gcc.gnu.org
!   63. https://gcc.gnu.org/lists.html
!   64. https://www.fsf.org/
!   65. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.6/index.html
                               GCC 4.6 Release Series
  
     (This release series is no longer supported.)
--- 11784,11854 ----
     2. https://gcc.gnu.org/gcc-4.7/porting_to.html
     3. https://gcc.gnu.org/wiki/TransactionalMemory
     4. https://gcc.gnu.org/wiki/Atomic/GCCMM
!    5. https://gcc.gnu.org/gcc-4.7/changes.html#c
!    6. https://gcc.gnu.org/gcc-4.7/changes.html#cxx
     7. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
     8. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
     9. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
    10. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
    11. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
!   12. https://gcc.gnu.org/gcc-4.7/cxx0x_status.html
!   13. https://gcc.gnu.org/PR14258
!   14. https://gcc.gnu.org/PR35688
!   15. https://gcc.gnu.org/onlinedocs/gcc-4.7.4/libstdc++/manual/manual/status.html#status.iso.2011
!   16. https://gcc.gnu.org/gcc-4.7/changes.html#fortran
!   17. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack-arrays_007d-254
!   18. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Optimize-Options.html#index-Ofast-689
!   19. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfno-protect-parens_007d-270
!   20. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfstack-arrays_007d-254
!   21. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfrontend-optimize_007d-275
!   22. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Error-and-Warning-Options.html#index-g_t_0040code_007bWfunction-elimination_007d-170
!   23. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Code-Gen-Options.html#index-g_t_0040code_007bfaggressive-function-elimination_007d-270
!   24. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Error-and-Warning-Options.html#index-g_t_0040code_007bWreal-q-constant_007d-149
!   25. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/SELECTED_005fREAL_005fKIND.html
!   26. https://learn.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps
!   27. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Debugging-Options.html#index-g_t_0040code_007bfno-backtrace_007d-183
!   28. https://gcc.gnu.org/wiki/Fortran2003Status
!   29. https://gcc.gnu.org/wiki/OOP
!   30. https://gcc.gnu.org/wiki/Fortran2008Status
!   31. https://gcc.gnu.org/wiki/Coarray
!   32. https://gcc.gnu.org/wiki/CoarrayLib
!   33. https://gcc.gnu.org/wiki/TS29113Status
!   34. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gfortran/Fortran-Dialect-Options.html#index-g_t_0040code_007bstd_003d_007d_0040var_007bstd_007d-option-53
!   35. https://gcc.gnu.org/gcc-4.7/changes.html#go
!   36. https://go.dev/doc/go1
!   37. https://gcc.gnu.org/gcc-4.7/changes.html#targets
!   38. https://gcc.gnu.org/gcc-4.7/changes.html#arm
!   39. https://gcc.gnu.org/gcc-4.7/changes.html#avr
!   40. http://savannah.nongnu.org/bugs/?35407
!   41. https://gcc.gnu.org/PR18145
!   42. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Named-Address-Spaces.html
!   43. http://www.nongnu.org/avr-libc/
!   44. https://gcc.gnu.org/PR54461
!   45. https://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/AVR-Built%5f002din-Functions.html
!   46. https://sites.google.com/site/x32abi/
!   47. https://gcc.gnu.org/gcc-4.7/changes.html#mips
!   48. https://dwarfstd.org/issues/100909.1.html
!   49. https://dwarfstd.org/issues/100909.2.html
!   50. https://dwarfstd.org/issues/140425.1.html
!   51. https://dwarfstd.org/issues/110722.1.html
!   52. https://gcc.gnu.org/gcc-4.7/changes.html#GCC4.7.1
!   53. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.1
!   54. https://go.dev/doc/go1
!   55. https://gcc.gnu.org/gcc-4.7/changes.html#GCC4.7.2
!   56. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.2
!   57. https://gcc.gnu.org/gcc-4.7/changes.html#GCC4.7.3
!   58. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.3
!   59. https://gcc.gnu.org/gcc-4.7/changes.html#GCC4.7.4
!   60. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.4
!   61. https://gcc.gnu.org/onlinedocs/
!   62. mailto:gcc-help@gcc.gnu.org
!   63. mailto:gcc@gcc.gnu.org
!   64. https://gcc.gnu.org/lists.html
!   65. https://www.fsf.org/
!   66. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.6/index.html
+ 
                               GCC 4.6 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 11856,11862 ****
     provided this notice is preserved.
  
     These pages are [23]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 11911,11917 ----
     provided this notice is preserved.
  
     These pages are [23]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 11885,11890 ****
--- 11940,11946 ----
    23. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.6/changes.html
+ 
                               GCC 4.6 Release Series
                          Changes, New Features, and Fixes
  
*************** New Languages and Language specific impr
*** 12200,12206 ****
       * G++ now issues clearer diagnostics when a colon is used in a place
         where a double-colon was intended.
       * G++ no longer accepts mutable on reference members ([12]c++/33558).
!        Use -fpermissive to allow the old, non-conforming behaviour.
       * A few mangling fixes have been made, to attribute const/volatile on
         function pointer types, decltype of a plain decl, and use of a
         function parameter in the declaration of another parameter. By
--- 12256,12262 ----
       * G++ now issues clearer diagnostics when a colon is used in a place
         where a double-colon was intended.
       * G++ no longer accepts mutable on reference members ([12]c++/33558).
!        Use -fpermissive to allow the old, non-conforming behavior.
       * A few mangling fixes have been made, to attribute const/volatile on
         function pointer types, decltype of a plain decl, and use of a
         function parameter in the declaration of another parameter. By
*************** New Languages and Language specific impr
*** 12218,12230 ****
      struct A { A(); };
      struct B : A { int i; };
      const B b = B();
!        Use -fpermissive to allow the old, non-conforming behaviour.
  
      Runtime Library (libstdc++)
  
       * [14]Improved experimental support for the upcoming ISO C++
         standard, C++0x, including using constexpr and nullptr.
!      * Performance improvements to the [15]Debug Mode, thanks to François
         Dumont.
       * Atomic operations used for reference-counting are annotated so that
         they can be understood by race detectors such as Helgrind, see
--- 12274,12286 ----
      struct A { A(); };
      struct B : A { int i; };
      const B b = B();
!        Use -fpermissive to allow the old, non-conforming behavior.
  
      Runtime Library (libstdc++)
  
       * [14]Improved experimental support for the upcoming ISO C++
         standard, C++0x, including using constexpr and nullptr.
!      * Performance improvements to the [15]Debug Mode, thanks to Franois
         Dumont.
       * Atomic operations used for reference-counting are annotated so that
         they can be understood by race detectors such as Helgrind, see
*************** New Languages and Language specific impr
*** 12279,12285 ****
              allocated (if unallocated) or reallocated (if the shape or
              type parameter is different). To avoid the small performance
              penalty, you can use a(:) = ... instead of a = ... for arrays
!             and character strings – or disable the feature using -std=f95
              or -fno-realloc-lhs.
            + Deferred type parameter: For scalar allocatable and pointer
              variables the character length can be deferred.
--- 12335,12341 ----
              allocated (if unallocated) or reallocated (if the shape or
              type parameter is different). To avoid the small performance
              penalty, you can use a(:) = ... instead of a = ... for arrays
!             and character strings - or disable the feature using -std=f95
              or -fno-realloc-lhs.
            + Deferred type parameter: For scalar allocatable and pointer
              variables the character length can be deferred.
*************** New Languages and Language specific impr
*** 12334,12340 ****
              be declared in a single PROCEDURE statement; implied-shape
              arrays are supported for named constants (PARAMETER). The
              transformational, three argument versions of BESSEL_JN and
!             BESSEL_YN were added – the elemental, two-argument version had
              been added in GCC 4.4; note that the transformational
              functions use a recurrence algorithm.
  
--- 12390,12396 ----
              be declared in a single PROCEDURE statement; implied-shape
              arrays are supported for named constants (PARAMETER). The
              transformational, three argument versions of BESSEL_JN and
!             BESSEL_YN were added - the elemental, two-argument version had
              been added in GCC 4.4; note that the transformational
              functions use a recurrence algorithm.
  
*************** Changes for GCC Developers
*** 12779,12785 ****
     provided this notice is preserved.
  
     These pages are [46]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 12835,12841 ----
     provided this notice is preserved.
  
     These pages are [46]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 12831,12836 ****
--- 12887,12893 ----
    46. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.5/index.html
+ 
                               GCC 4.5 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 12893,12899 ****
     provided this notice is preserved.
  
     These pages are [18]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 12950,12956 ----
     provided this notice is preserved.
  
     These pages are [18]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 12917,12922 ****
--- 12974,12980 ----
    18. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.5/changes.html
+ 
                               GCC 4.5 Release Series
                          Changes, New Features, and Fixes
  
*************** New Languages and Language specific impr
*** 13153,13159 ****
         defined ([13]DR 757).
       * Labels may now have attributes, as has been permitted for a while
         in C. This is only permitted when the label definition and the
!        attribute specifier is followed by a semicolon—i.e., the label
         applies to an empty statement. The only useful attribute for a
         label is unused.
       * G++ now implements [14]DR 176. Previously G++ did not support using
--- 13211,13217 ----
         defined ([13]DR 757).
       * Labels may now have attributes, as has been permitted for a while
         in C. This is only permitted when the label definition and the
!        attribute specifier is followed by a semicolon--i.e., the label
         applies to an empty statement. The only useful attribute for a
         label is unused.
       * G++ now implements [14]DR 176. Previously G++ did not support using
*************** New Languages and Language specific impr
*** 13194,13200 ****
            + Existing facilities now exploit explicit operators and the
              newly implemented core C++0x features.
            + The header  has been renamed to .
!      * An experimental [15]profile mode has been added. This is an
         implementation of many C++ standard library constructs with an
         additional analysis layer that gives performance improvement advice
         based on recognition of suboptimal usage patterns. For example,
--- 13252,13258 ----
            + Existing facilities now exploit explicit operators and the
              newly implemented core C++0x features.
            + The header  has been renamed to .
!      * An experimental profile mode has been added. This is an
         implementation of many C++ standard library constructs with an
         additional analysis layer that gives performance improvement advice
         based on recognition of suboptimal usage patterns. For example,
*************** vector-size: improvement = 3: call stack
*** 13216,13222 ****
         These constructs can be substituted for the normal libstdc++
         constructs on a piecemeal basis, or all existing components can be
         transformed via the -D_GLIBCXX_PROFILE macro.
!      * [16]Support for decimal floating-point arithmetic (aka ISO C++ TR
         24733) has been added. This support is in header file
         , uses namespace std::decimal, and includes
         classes decimal32, decimal64, and decimal128.
--- 13274,13280 ----
         These constructs can be substituted for the normal libstdc++
         constructs on a piecemeal basis, or all existing components can be
         transformed via the -D_GLIBCXX_PROFILE macro.
!      * [15]Support for decimal floating-point arithmetic (aka ISO C++ TR
         24733) has been added. This support is in header file
         , uses namespace std::decimal, and includes
         classes decimal32, decimal64, and decimal128.
*************** vector-size: improvement = 3: call stack
*** 13226,13245 ****
         components that simplify the internal representation and present a
         more intuitive view of components when used with
         appropriately-advanced versions of GDB. For more information,
!        please consult the more [17]detailed description.
       * The default behavior for comparing typeinfo names has changed, so
         in , __GXX_MERGED_TYPEINFO_NAMES now defaults to zero.
       * The new -static-libstdc++ option directs g++ to link the C++
         library statically, even if the default would normally be to link
         it dynamically.
  
!   [18]Fortran
  
!      * The COMMON default padding has been changed – instead of adding the
         padding before a variable it is now added afterwards, which
         increases the compatibility with other vendors and helps to obtain
         the correct output in some cases. Cf. also the -falign-commons
!        option ([19]added in 4.4).
       * The -finit-real= option now also supports the value snan for
         signaling not-a-number; to be effective, one additionally needs to
         enable trapping (e.g. via -ffpe-trap=). Note: Compile-time
--- 13284,13303 ----
         components that simplify the internal representation and present a
         more intuitive view of components when used with
         appropriately-advanced versions of GDB. For more information,
!        please consult the more [16]detailed description.
       * The default behavior for comparing typeinfo names has changed, so
         in , __GXX_MERGED_TYPEINFO_NAMES now defaults to zero.
       * The new -static-libstdc++ option directs g++ to link the C++
         library statically, even if the default would normally be to link
         it dynamically.
  
!   [17]Fortran
  
!      * The COMMON default padding has been changed - instead of adding the
         padding before a variable it is now added afterwards, which
         increases the compatibility with other vendors and helps to obtain
         the correct output in some cases. Cf. also the -falign-commons
!        option ([18]added in 4.4).
       * The -finit-real= option now also supports the value snan for
         signaling not-a-number; to be effective, one additionally needs to
         enable trapping (e.g. via -ffpe-trap=). Note: Compile-time
*************** vector-size: improvement = 3: call stack
*** 13257,13263 ****
       * The run-time checking -fcheck=bounds now warns about invalid string
         lengths of character dummy arguments. Additionally, more
         compile-time checks have been added.
!      * The new option [20]-fno-protect-parens has been added; if set, the
         compiler may reorder REAL and COMPLEX expressions without regard to
         parentheses.
       * GNU Fortran no longer links against libgfortranbegin. As before,
--- 13315,13321 ----
       * The run-time checking -fcheck=bounds now warns about invalid string
         lengths of character dummy arguments. Additionally, more
         compile-time checks have been added.
!      * The new option [19]-fno-protect-parens has been added; if set, the
         compiler may reorder REAL and COMPLEX expressions without regard to
         parentheses.
       * GNU Fortran no longer links against libgfortranbegin. As before,
*************** vector-size: improvement = 3: call stack
*** 13265,13271 ****
         which is invoked by the main function. However, main is now
         generated and put in the same object file as MAIN__. For the time
         being, libgfortranbegin still exists for backward compatibility.
!        For details see the new [21]Mixed-Language Programming chapter in
         the manual.
       * The I/O library was restructured for performance and cleaner code.
       * Array assignments and WHERE are now run in parallel when OpenMP's
--- 13323,13329 ----
         which is invoked by the main function. However, main is now
         generated and put in the same object file as MAIN__. For the time
         being, libgfortranbegin still exists for backward compatibility.
!        For details see the new [20]Mixed-Language Programming chapter in
         the manual.
       * The I/O library was restructured for performance and cleaner code.
       * Array assignments and WHERE are now run in parallel when OpenMP's
*************** vector-size: improvement = 3: call stack
*** 13277,13283 ****
       * More Fortran 2003 and Fortran 2008 mathematical functions can now
         be used as initialization expressions.
       * Some extended attributes such as STDCALL are now supported via the
!        [22]GCC$ compiler directive.
       * For Fortran 77 compatibility: If -fno-sign-zero is used, the SIGN
         intrinsic behaves now as if zero were always positive.
       * For legacy compatibiliy: On Cygwin and MinGW, the special files
--- 13335,13341 ----
       * More Fortran 2003 and Fortran 2008 mathematical functions can now
         be used as initialization expressions.
       * Some extended attributes such as STDCALL are now supported via the
!        [21]GCC$ compiler directive.
       * For Fortran 77 compatibility: If -fno-sign-zero is used, the SIGN
         intrinsic behaves now as if zero were always positive.
       * For legacy compatibiliy: On Cygwin and MinGW, the special files
*************** vector-size: improvement = 3: call stack
*** 13303,13309 ****
              procedure pointer with PASS attribute now have to use CLASS in
              line with the Fortran 2003 standard; the workaround to use
              TYPE is no longer supported.
!           + [23]Experimental, incomplete support for polymorphism,
              including CLASS, SELECT TYPE and dynamic dispatch of
              type-bound procedure calls. Some features do not work yet such
              as unlimited polymorphism (CLASS(*)).
--- 13361,13367 ----
              procedure pointer with PASS attribute now have to use CLASS in
              line with the Fortran 2003 standard; the workaround to use
              TYPE is no longer supported.
!           + [22]Experimental, incomplete support for polymorphism,
              including CLASS, SELECT TYPE and dynamic dispatch of
              type-bound procedure calls. Some features do not work yet such
              as unlimited polymorphism (CLASS(*)).
*************** vector-size: improvement = 3: call stack
*** 13320,13326 ****
              ATAN(Y,X) is now an alias for ATAN2(Y,X).
            + The BLOCK construct has been implemented.
  
! [24]New Targets and Target Specific Improvements
  
    AIX
  
--- 13378,13384 ----
              ATAN(Y,X) is now an alias for ATAN2(Y,X).
            + The BLOCK construct has been implemented.
  
! [23]New Targets and Target Specific Improvements
  
    AIX
  
*************** vector-size: improvement = 3: call stack
*** 13351,13357 ****
            + ATmega16U2
            + ATmega32U2
  
!   [25]IA-32/x86-64
  
       * GCC now will set the default for -march= based on the configure
         target.
--- 13409,13415 ----
            + ATmega16U2
            + ATmega32U2
  
!   [24]IA-32/x86-64
  
       * GCC now will set the default for -march= based on the configure
         target.
*************** vector-size: improvement = 3: call stack
*** 13385,13391 ****
       * GCC now supports thread-local storage (TLS) on M68K and ColdFire
         processors.
  
!   [26]MeP
  
     Support has been added for the Toshiba Media embedded Processor (MeP,
     or mep-elf) embedded target.
--- 13443,13449 ----
       * GCC now supports thread-local storage (TLS) on M68K and ColdFire
         processors.
  
!   [25]MeP
  
     Support has been added for the Toshiba Media embedded Processor (MeP,
     or mep-elf) embedded target.
*************** vector-size: improvement = 3: call stack
*** 13423,13429 ****
         use_debug_exception_return. See the documentation for more details
         about these attributes.
  
!   [27]RS/6000 (POWER/PowerPC)
  
       * GCC now supports the Power ISA 2.06, which includes the VSX
         instructions that add vector 64-bit floating point support, new
--- 13481,13487 ----
         use_debug_exception_return. See the documentation for more details
         about these attributes.
  
!   [26]RS/6000 (POWER/PowerPC)
  
       * GCC now supports the Power ISA 2.06, which includes the VSX
         instructions that add vector 64-bit floating point support, new
*************** vector-size: improvement = 3: call stack
*** 13448,13460 ****
         adhere to the ABI for 128-bit vectors with 64-bit integer base
         types (PR 48857). This is also fixed in the GCC 4.6.1 release.
  
!   [28]RX
  
     Support has been added for the Renesas RX Processor (rx-elf) target.
  
! [29]Operating Systems
  
!   [30]Windows (Cygwin and MinGW)
  
       * GCC now installs all the major language runtime libraries as DLLs
         when configured with the --enable-shared option.
--- 13506,13518 ----
         adhere to the ABI for 128-bit vectors with 64-bit integer base
         types (PR 48857). This is also fixed in the GCC 4.6.1 release.
  
!   [27]RX
  
     Support has been added for the Renesas RX Processor (rx-elf) target.
  
! [28]Operating Systems
  
!   [29]Windows (Cygwin and MinGW)
  
       * GCC now installs all the major language runtime libraries as DLLs
         when configured with the --enable-shared option.
*************** Other significant improvements
*** 13503,13518 ****
         infodir info documentation [DATAROOTDIR/info]
         mandir  man documentation [DATAROOTDIR/man]
  
! [31]GCC 4.5.1
  
!    This is the [32]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.5.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
    All languages
  
!      * GCC's new link-time optimizer ([33]-flto) now also works on a few
         non-ELF targets:
            + Cygwin (*-cygwin*)
            + MinGW (*-mingw*)
--- 13561,13576 ----
         infodir info documentation [DATAROOTDIR/info]
         mandir  man documentation [DATAROOTDIR/man]
  
! [30]GCC 4.5.1
  
!    This is the [31]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.5.1 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
    All languages
  
!      * GCC's new link-time optimizer ([32]-flto) now also works on a few
         non-ELF targets:
            + Cygwin (*-cygwin*)
            + MinGW (*-mingw*)
*************** Other significant improvements
*** 13520,13535 ****
         LTO is not enabled by default for these targets. To enable LTO, you
         should configure with the --enable-lto option.
  
! [34]GCC 4.5.2
  
!    This is the [35]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.5.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [36]GCC 4.5.3
  
!    This is the [37]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.5.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
--- 13578,13593 ----
         LTO is not enabled by default for these targets. To enable LTO, you
         should configure with the --enable-lto option.
  
! [33]GCC 4.5.2
  
!    This is the [34]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.5.2 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
! [35]GCC 4.5.3
  
!    This is the [36]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.5.3 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
*************** Other significant improvements
*** 13544,13570 ****
     vec_vsx_ld and vec_vsx_st which always generates the VSX memory
     instructions.
  
! [38]GCC 4.5.4
  
!    This is the [39]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.5.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [40]GCC manuals. If that fails, the
!     [41]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [42]gcc@gcc.gnu.org. All of [43]our lists have public
      archives.
  
!    Copyright (C) [44]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [45]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 13602,13628 ----
     vec_vsx_ld and vec_vsx_st which always generates the VSX memory
     instructions.
  
! [37]GCC 4.5.4
  
!    This is the [38]list of problem reports (PRs) from GCC's bug tracking
     system that are known to be fixed in the 4.5.4 release. This list might
     not be complete (that is, it is possible that some PRs that have been
     fixed are not listed here).
  
  
      For questions related to the use of GCC, please consult these web
!     pages and the [39]GCC manuals. If that fails, the
!     [40]gcc-help@gcc.gnu.org mailing list might help. Comments on these
      web pages and the development of GCC are welcome on our developer
!     list at [41]gcc@gcc.gnu.org. All of [42]our lists have public
      archives.
  
!    Copyright (C) [43]Free Software Foundation, Inc. Verbatim copying and
     distribution of this entire article is permitted in any medium,
     provided this notice is preserved.
  
!    These pages are [44]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 13582,13620 ****
    12. https://gcc.gnu.org/gcc-4.5/cxx0x_status.html
    13. https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#757
    14. https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#176
!   15. https://gcc.gnu.org/onlinedocs/libstdc++/manual/profile_mode.html
!   16. https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.tr24733
!   17. https://sourceware.org/gdb/wiki/STLSupport
!   18. https://gcc.gnu.org/gcc-4.5/changes.html#Fortran
!   19. https://gcc.gnu.org/gcc-4.4/changes.html
!   20. https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html
!   21. https://gcc.gnu.org/onlinedocs/gfortran/Mixed-Language-Programming.html
!   22. https://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-Compiler-Directives.html
!   23. https://gcc.gnu.org/wiki/OOP
!   24. https://gcc.gnu.org/gcc-4.5/changes.html#targets
!   25. https://gcc.gnu.org/gcc-4.5/changes.html#x86
!   26. https://gcc.gnu.org/gcc-4.5/changes.html#mep
!   27. https://gcc.gnu.org/gcc-4.5/changes.html#rs6000
!   28. https://gcc.gnu.org/gcc-4.5/changes.html#rx
!   29. https://gcc.gnu.org/gcc-4.5/changes.html#os
!   30. https://gcc.gnu.org/gcc-4.5/changes.html#windows
!   31. https://gcc.gnu.org/gcc-4.5/changes.html#GCC4.5.1
!   32. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.1
!   33. https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto-801
!   34. https://gcc.gnu.org/gcc-4.5/changes.html#GCC4.5.2
!   35. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.2
!   36. https://gcc.gnu.org/gcc-4.5/changes.html#GCC4.5.3
!   37. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.3
!   38. https://gcc.gnu.org/gcc-4.5/changes.html#GCC4.5.4
!   39. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.4
!   40. https://gcc.gnu.org/onlinedocs/
!   41. mailto:gcc-help@gcc.gnu.org
!   42. mailto:gcc@gcc.gnu.org
!   43. https://gcc.gnu.org/lists.html
!   44. https://www.fsf.org/
!   45. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.4/index.html
                               GCC 4.4 Release Series
  
     This release series is no longer maintained.
--- 13640,13678 ----
    12. https://gcc.gnu.org/gcc-4.5/cxx0x_status.html
    13. https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#757
    14. https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#176
!   15. https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.tr24733
!   16. https://sourceware.org/gdb/wiki/STLSupport
!   17. https://gcc.gnu.org/gcc-4.5/changes.html#Fortran
!   18. https://gcc.gnu.org/gcc-4.4/changes.html
!   19. https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html
!   20. https://gcc.gnu.org/onlinedocs/gfortran/Mixed-Language-Programming.html
!   21. https://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-Compiler-Directives.html
!   22. https://gcc.gnu.org/wiki/OOP
!   23. https://gcc.gnu.org/gcc-4.5/changes.html#targets
!   24. https://gcc.gnu.org/gcc-4.5/changes.html#x86
!   25. https://gcc.gnu.org/gcc-4.5/changes.html#mep
!   26. https://gcc.gnu.org/gcc-4.5/changes.html#rs6000
!   27. https://gcc.gnu.org/gcc-4.5/changes.html#rx
!   28. https://gcc.gnu.org/gcc-4.5/changes.html#os
!   29. https://gcc.gnu.org/gcc-4.5/changes.html#windows
!   30. https://gcc.gnu.org/gcc-4.5/changes.html#GCC4.5.1
!   31. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.1
!   32. https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto-801
!   33. https://gcc.gnu.org/gcc-4.5/changes.html#GCC4.5.2
!   34. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.2
!   35. https://gcc.gnu.org/gcc-4.5/changes.html#GCC4.5.3
!   36. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.3
!   37. https://gcc.gnu.org/gcc-4.5/changes.html#GCC4.5.4
!   38. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.5.4
!   39. https://gcc.gnu.org/onlinedocs/
!   40. mailto:gcc-help@gcc.gnu.org
!   41. mailto:gcc@gcc.gnu.org
!   42. https://gcc.gnu.org/lists.html
!   43. https://www.fsf.org/
!   44. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.4/index.html
+ 
                               GCC 4.4 Release Series
  
     This release series is no longer maintained.
*************** References and Acknowledgements
*** 13686,13692 ****
     provided this notice is preserved.
  
     These pages are [21]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 13744,13750 ----
     provided this notice is preserved.
  
     These pages are [21]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 13713,13718 ****
--- 13771,13777 ----
    21. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.4/changes.html
+ 
                               GCC 4.4 Release Series
                          Changes, New Features, and Fixes
  
*************** Other significant improvements
*** 14315,14321 ****
     provided this notice is preserved.
  
     These pages are [32]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 14374,14380 ----
     provided this notice is preserved.
  
     These pages are [32]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 14353,14358 ****
--- 14412,14418 ----
    32. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.3/index.html
+ 
                               GCC 4.3 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 14421,14427 ****
     provided this notice is preserved.
  
     These pages are [20]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 14481,14487 ----
     provided this notice is preserved.
  
     These pages are [20]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 14447,14452 ****
--- 14507,14513 ----
    20. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.3/changes.html
+ 
                               GCC 4.3 Release Series
                          Changes, New Features, and Fixes
  
*************** Target Specific Changes
*** 15225,15231 ****
     provided this notice is preserved.
  
     These pages are [39]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 15286,15292 ----
     provided this notice is preserved.
  
     These pages are [39]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 15270,15275 ****
--- 15331,15337 ----
    39. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.2/index.html
+ 
                               GCC 4.2 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 15332,15338 ****
     provided this notice is preserved.
  
     These pages are [18]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 15394,15400 ----
     provided this notice is preserved.
  
     These pages are [18]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 15356,15361 ****
--- 15418,15424 ----
    18. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.2/changes.html
+ 
                               GCC 4.2 Release Series
                          Changes, New Features, and Fixes
  
*************** Other significant improvements
*** 15660,15666 ****
     provided this notice is preserved.
  
     These pages are [13]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 15723,15729 ----
     provided this notice is preserved.
  
     These pages are [13]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 15679,15684 ****
--- 15742,15748 ----
    13. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.1/index.html
+ 
                               GCC 4.1 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 15735,15741 ****
     provided this notice is preserved.
  
     These pages are [16]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 15799,15805 ----
     provided this notice is preserved.
  
     These pages are [16]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 15757,15762 ****
--- 15821,15827 ----
    16. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.1/changes.html
+ 
                               GCC 4.1 Release Series
                          Changes, New Features, and Fixes
  
*************** Other significant improvements
*** 16294,16300 ****
     provided this notice is preserved.
  
     These pages are [15]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 16359,16365 ----
     provided this notice is preserved.
  
     These pages are [15]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 16315,16320 ****
--- 16380,16386 ----
    15. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.0/index.html
+ 
                               GCC 4.0 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 16377,16383 ****
     provided this notice is preserved.
  
     These pages are [18]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 16443,16449 ----
     provided this notice is preserved.
  
     These pages are [18]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 16401,16406 ****
--- 16467,16473 ----
    18. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-4.0/changes.html
+ 
                               GCC 4.0 Release Series
                          Changes, New Features, and Fixes
  
*************** Other significant improvements
*** 16902,16908 ****
     provided this notice is preserved.
  
     These pages are [27]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 16969,16975 ----
     provided this notice is preserved.
  
     These pages are [27]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 16935,16940 ****
--- 17002,17008 ----
    27. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.4/index.html
+ 
                               GCC 3.4 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 17008,17014 ****
     provided this notice is preserved.
  
     These pages are [22]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 17076,17082 ----
     provided this notice is preserved.
  
     These pages are [22]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 17036,17041 ****
--- 17104,17110 ----
    22. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.4/changes.html
+ 
                               GCC 3.4 Release Series
                          Changes, New Features, and Fixes
  
*************** Other significant improvements
*** 18795,18801 ****
     provided this notice is preserved.
  
     These pages are [425]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 18864,18870 ----
     provided this notice is preserved.
  
     These pages are [425]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 18808,18814 ****
     7. https://www.boost.org/
     8. https://gcc.gnu.org/PR11953
     9. https://gcc.gnu.org/PR8361
!   10. https://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Other-Builtins.html#Other Builtins
    11. https://gcc.gnu.org/gcc-3.4/changes.html#cplusplus
    12. https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#209
    13. https://gcc.gnu.org/bugs/#cxx_rvalbind
--- 18877,18883 ----
     7. https://www.boost.org/
     8. https://gcc.gnu.org/PR11953
     9. https://gcc.gnu.org/PR8361
!   10. https://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Other-Builtins.html#Other%20Builtins
    11. https://gcc.gnu.org/gcc-3.4/changes.html#cplusplus
    12. https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#209
    13. https://gcc.gnu.org/bugs/#cxx_rvalbind
*************** References
*** 18827,18833 ****
    26. https://gcc.gnu.org/gcc-3.4/sparc-abi.html
    27. https://gcc.gnu.org/gcc-3.4/changes.html#obsolete_systems
    28. https://gcc.gnu.org/gcc-3.4/changes.html#GCC3.4.0
!   29. https://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=notregexp&short_desc=\[3\.4.*[Rr]egression&target_milestone=3.4.0&bug_status=RESOLVED&resolution=FIXED
    30. https://gcc.gnu.org/gcc-3.4/changes.html#GCC3.4.1
    31. https://gcc.gnu.org/PR10129
    32. https://gcc.gnu.org/PR14576
--- 18896,18902 ----
    26. https://gcc.gnu.org/gcc-3.4/sparc-abi.html
    27. https://gcc.gnu.org/gcc-3.4/changes.html#obsolete_systems
    28. https://gcc.gnu.org/gcc-3.4/changes.html#GCC3.4.0
!   29. https://gcc.gnu.org/bugzilla/buglist.cgi?short_desc_type=notregexp&short_desc=%5C%5B3%5C.4.*%5BRr%5Degression&target_milestone=3.4.0&bug_status=RESOLVED&resolution=FIXED
    30. https://gcc.gnu.org/gcc-3.4/changes.html#GCC3.4.1
    31. https://gcc.gnu.org/PR10129
    32. https://gcc.gnu.org/PR14576
*************** References
*** 19226,19231 ****
--- 19295,19301 ----
   425. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.3/index.html
+ 
                               GCC 3.3 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 19299,19305 ****
     provided this notice is preserved.
  
     These pages are [21]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 19369,19375 ----
     provided this notice is preserved.
  
     These pages are [21]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 19326,19331 ****
--- 19396,19402 ----
    21. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.3/changes.html
+ 
                               GCC 3.3 Release Series
                          Changes, New Features, and Fixes
  
*************** GCC 3.3
*** 20673,20679 ****
     provided this notice is preserved.
  
     These pages are [563]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
--- 20744,20750 ----
     provided this notice is preserved.
  
     These pages are [563]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 20682,20688 ****
     3. https://gcc.gnu.org/gcc-3.3/changes.html#obsolete_systems
     4. https://gcc.gnu.org/gcc-3.3/changes.html#nonnull_attribute
     5. https://gcc.gnu.org/news/dfa.html
!    6. https://gcc.gnu.org/c99status.html
     7. https://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/News.html
     8. https://gcc.gnu.org/gcc-3.3/changes.html#obsolete_systems
     9. https://gcc.gnu.org/PR10140
--- 20753,20759 ----
     3. https://gcc.gnu.org/gcc-3.3/changes.html#obsolete_systems
     4. https://gcc.gnu.org/gcc-3.3/changes.html#nonnull_attribute
     5. https://gcc.gnu.org/news/dfa.html
!    6. https://gcc.gnu.org/projects/c-status.html
     7. https://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/News.html
     8. https://gcc.gnu.org/gcc-3.3/changes.html#obsolete_systems
     9. https://gcc.gnu.org/PR10140
*************** References
*** 21242,21247 ****
--- 21313,21319 ----
   563. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.2/index.html
+ 
                               GCC 3.2 Release Series
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 21309,21315 ****
     provided this notice is preserved.
  
     These pages are [17]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 21381,21387 ----
     provided this notice is preserved.
  
     These pages are [17]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 21332,21337 ****
--- 21404,21410 ----
    17. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.2/changes.html
+ 
                               GCC 3.2 Release Series
                          Changes, New Features, and Fixes
  
*************** Caveats and New Features
*** 21931,21937 ****
     provided this notice is preserved.
  
     These pages are [255]maintained by the GCC team. Last modified
!    2025-04-08.
  
  References
  
--- 22004,22010 ----
     provided this notice is preserved.
  
     These pages are [255]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 22192,22197 ****
--- 22265,22271 ----
   255. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.1/index.html
+ 
                                      GCC 3.1
  
     (This release series is no longer supported.)
*************** http://gcc.gnu.org/gcc-3.1/index.html
*** 22239,22245 ****
     provided this notice is preserved.
  
     These pages are [13]maintained by the GCC team. Last modified
!    2024-07-04.
  
  References
  
--- 22313,22319 ----
     provided this notice is preserved.
  
     These pages are [13]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 22258,22263 ****
--- 22332,22338 ----
    13. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.1/changes.html
+ 
                               GCC 3.1 Release Series
                          Changes, New Features, and Fixes
  
*************** General Optimizer Improvements
*** 22292,22298 ****
         for profile driven optimizations.
         Options -fprofile-arcs and -fbranch-probabilities can now be used
         to improve speed of the generated code by profiling the actual
!        program behaviour on typical runs. In the absence of profile info
         the compiler attempts to guess the profile statically.
       * [3]SPEC2000 and SPEC95 benchmark suites are now used daily to
         monitor performance of the generated code.
--- 22367,22373 ----
         for profile driven optimizations.
         Options -fprofile-arcs and -fbranch-probabilities can now be used
         to improve speed of the generated code by profiling the actual
!        program behavior on typical runs. In the absence of profile info
         the compiler attempts to guess the profile statically.
       * [3]SPEC2000 and SPEC95 benchmark suites are now used daily to
         monitor performance of the generated code.
*************** New Targets and Target Specific Improvem
*** 22475,22481 ****
            + For those targets that support it, -mfpmath=sse will cause the
              compiler to generate SSE/SSE2 instructions for floating point
              math instead of x87 instructions. Usually, this will lead to
!             quicker code — especially on the Pentium 4. Note that only
              scalar floating point instructions are used and GCC does not
              exploit SIMD features yet.
            + Prefetch support has been added to the Pentium III, Pentium 4,
--- 22550,22556 ----
            + For those targets that support it, -mfpmath=sse will cause the
              compiler to generate SSE/SSE2 instructions for floating point
              math instead of x87 instructions. Usually, this will lead to
!             quicker code -- especially on the Pentium 4. Note that only
              scalar floating point instructions are used and GCC does not
              exploit SIMD features yet.
            + Prefetch support has been added to the Pentium III, Pentium 4,
*************** Documentation improvements
*** 22591,22604 ****
     provided this notice is preserved.
  
     These pages are [14]maintained by the GCC team. Last modified
!    2025-01-31.
  
  References
  
     1. https://gcc.gnu.org/ml/gcc/2002-07/msg01208.html
     2. https://gcc.gnu.org/news/profiledriven.html
     3. https://gcc.gnu.org/benchmarks/
!    4. https://gcc.gnu.org/c99status.html
     5. https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
     6. https://gcc.gnu.org/onlinedocs/gcc-3.1.1/g77/News.html
     7. https://www.adacore.com/
--- 22666,22679 ----
     provided this notice is preserved.
  
     These pages are [14]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
     1. https://gcc.gnu.org/ml/gcc/2002-07/msg01208.html
     2. https://gcc.gnu.org/news/profiledriven.html
     3. https://gcc.gnu.org/benchmarks/
!    4. https://gcc.gnu.org/projects/c-status.html
     5. https://gcc.gnu.org/onlinedocs/libstdc++/faq.html
     6. https://gcc.gnu.org/onlinedocs/gcc-3.1.1/g77/News.html
     7. https://www.adacore.com/
*************** References
*** 22611,22616 ****
--- 22686,22692 ----
    14. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.0/index.html
+ 
                                     GCC 3.0.4
  
     (This release series is no longer supported.)
*************** Previous 3.0.x Releases
*** 22665,22671 ****
     provided this notice is preserved.
  
     These pages are [14]maintained by the GCC team. Last modified
!    2024-07-04.
  
  References
  
--- 22741,22747 ----
     provided this notice is preserved.
  
     These pages are [14]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 22685,22690 ****
--- 22761,22767 ----
    14. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.0/features.html
+ 
                                GCC 3.0 New Features
  
  Additional changes in GCC 3.0.4
*************** New Languages and Language specific impr
*** 22766,22774 ****
       * New C++ support library and many C++ bug fixes, vastly improving
         our conformance to the ISO C++ standard.
       * New [7]inliner for C++.
!      * Rewritten C preprocessor, integrated into the C, C++ and Objective
!        C compilers, with very many improvements including ISO C99 support
!        and [8]improvements to dependency generation.
       * Support for more [9]ISO C99 features.
       * Many improvements to support for checking calls to format functions
         such as printf and scanf, including support for ISO C99 format
--- 22843,22851 ----
       * New C++ support library and many C++ bug fixes, vastly improving
         our conformance to the ISO C++ standard.
       * New [7]inliner for C++.
!      * Rewritten C preprocessor, integrated into the C, C++ and
!        Objective-C compilers, with very many improvements including ISO
!        C99 support and [8]improvements to dependency generation.
       * Support for more [9]ISO C99 features.
       * Many improvements to support for checking calls to format functions
         such as printf and scanf, including support for ISO C99 format
*************** Other significant improvements
*** 22855,22861 ****
     provided this notice is preserved.
  
     These pages are [18]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 22932,22938 ----
     provided this notice is preserved.
  
     These pages are [18]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 22867,22873 ****
     6. https://gcc.gnu.org/gcc-3.0/c++features.html
     7. https://gcc.gnu.org/news/inlining.html
     8. https://gcc.gnu.org/news/dependencies.html
!    9. https://gcc.gnu.org/c99status.html
    10. https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/News.html
    11. https://gcc.gnu.org/gcc-3.0/libgcc.html
    12. https://gcc.gnu.org/gcc-2.95/features.html
--- 22944,22950 ----
     6. https://gcc.gnu.org/gcc-3.0/c++features.html
     7. https://gcc.gnu.org/news/inlining.html
     8. https://gcc.gnu.org/news/dependencies.html
!    9. https://gcc.gnu.org/projects/c-status.html
    10. https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/News.html
    11. https://gcc.gnu.org/gcc-3.0/libgcc.html
    12. https://gcc.gnu.org/gcc-2.95/features.html
*************** References
*** 22879,22884 ****
--- 22956,22962 ----
    18. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-3.0/caveats.html
+ 
                                  GCC 3.0 Caveats
  
       * -fstrict-aliasing is now part of -O2 and higher optimization
*************** http://gcc.gnu.org/gcc-3.0/caveats.html
*** 22895,22901 ****
         about this may be fixed by adding a null statement (a single
         semicolon) after the label.
       * The poorly documented extension that allowed string constants in C,
!        C++ and Objective C to contain unescaped newlines has been
         deprecated and may be removed in a future version. Programs using
         this extension may be fixed in several ways: the bare newline may
         be replaced by \n, or preceded by \n\, or string concatenation may
--- 22973,22979 ----
         about this may be fixed by adding a null statement (a single
         semicolon) after the label.
       * The poorly documented extension that allowed string constants in C,
!        C++ and Objective-C to contain unescaped newlines has been
         deprecated and may be removed in a future version. Programs using
         this extension may be fixed in several ways: the bare newline may
         be replaced by \n, or preceded by \n\, or string concatenation may
*************** http://gcc.gnu.org/gcc-3.0/caveats.html
*** 22925,22931 ****
     provided this notice is preserved.
  
     These pages are [7]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 23003,23009 ----
     provided this notice is preserved.
  
     These pages are [7]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 22938,22943 ****
--- 23016,23022 ----
     7. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-2.95/index.html
+ 
                                      GCC 2.95
  
     (This release series is no longer supported.)
*************** References and Acknowledgements
*** 23006,23012 ****
     provided this notice is preserved.
  
     These pages are [15]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 23085,23091 ----
     provided this notice is preserved.
  
     These pages are [15]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 23027,23032 ****
--- 23106,23112 ----
    15. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-2.95/features.html
+ 
                               GCC 2.95 New Features
  
       * General Optimizer Improvements:
*************** http://gcc.gnu.org/gcc-2.95/features.htm
*** 23073,23079 ****
            + sh4
            + Support for new systems (OpenBSD, FreeBSD, UWIN, Interix,
              arm-linux)
!           + vxWorks targets include support for vxWorks threads
            + StrongARM 110 and ARM9 support added. ARM Scheduling
              parameters rewritten.
            + Various changes to the MIPS port to avoid assembler macros,
--- 23153,23159 ----
            + sh4
            + Support for new systems (OpenBSD, FreeBSD, UWIN, Interix,
              arm-linux)
!           + VxWorks targets include support for VxWorks threads
            + StrongARM 110 and ARM9 support added. ARM Scheduling
              parameters rewritten.
            + Various changes to the MIPS port to avoid assembler macros,
*************** Additional Changes in GCC 2.95.1
*** 23129,23135 ****
            + Fix compiler abort in new cfg code exposed by x86 port.
            + Fix out of range array reference in code convert flat
              registers to the x87 stacked FP register file.
!           + Fix minor vxworks configuration bug.
            + Fix return type of bsearch for SunOS 4.x.
       * Language & Runtime specific fixes.
            + The G++ signature extension has been deprecated. It will be
--- 23209,23215 ----
            + Fix compiler abort in new cfg code exposed by x86 port.
            + Fix out of range array reference in code convert flat
              registers to the x87 stacked FP register file.
!           + Fix minor VxWorks configuration bug.
            + Fix return type of bsearch for SunOS 4.x.
       * Language & Runtime specific fixes.
            + The G++ signature extension has been deprecated. It will be
*************** Additional Changes in GCC 2.95.3
*** 23270,23276 ****
     provided this notice is preserved.
  
     These pages are [22]maintained by the GCC team. Last modified
!    2023-09-02.
  
  References
  
--- 23350,23356 ----
     provided this notice is preserved.
  
     These pages are [22]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 23285,23291 ****
     9. https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/News.html
    10. https://gcc.gnu.org/news/gcj-announce.txt
    11. https://gcc.gnu.org/news/javaannounce.html
!   12. https://gcc.gnu.org/c99status.html
    13. https://gcc.gnu.org/news/chill.html
    14. https://gcc.gnu.org/news/sparc.html
    15. https://gcc.gnu.org/news/egcs-vcg.html
--- 23365,23371 ----
     9. https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/News.html
    10. https://gcc.gnu.org/news/gcj-announce.txt
    11. https://gcc.gnu.org/news/javaannounce.html
!   12. https://gcc.gnu.org/projects/c-status.html
    13. https://gcc.gnu.org/news/chill.html
    14. https://gcc.gnu.org/news/sparc.html
    15. https://gcc.gnu.org/news/egcs-vcg.html
*************** References
*** 23298,23303 ****
--- 23378,23384 ----
    22. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/gcc-2.95/caveats.html
+ 
                                  GCC 2.95 Caveats
  
       * GCC 2.95 will issue an error for invalid asm statements that had
*************** http://gcc.gnu.org/gcc-2.95/caveats.html
*** 23352,23358 ****
     provided this notice is preserved.
  
     These pages are [7]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 23433,23439 ----
     provided this notice is preserved.
  
     These pages are [7]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 23365,23370 ****
--- 23446,23452 ----
     7. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/egcs-1.1/index.html
+ 
                                      EGCS 1.1
  
     September 3, 1998: We are pleased to announce the release of EGCS 1.1.
*************** http://gcc.gnu.org/egcs-1.1/index.html
*** 23572,23578 ****
     provided this notice is preserved.
  
     These pages are [15]maintained by the GCC team. Last modified
!    2024-05-18.
  
  References
  
--- 23654,23660 ----
     provided this notice is preserved.
  
     These pages are [15]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 23593,23598 ****
--- 23675,23681 ----
    15. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/egcs-1.1/features.html
+ 
                               EGCS 1.1 new features
  
       * Integrated GNU Fortran (g77) compiler and runtime library with
*************** http://gcc.gnu.org/egcs-1.1/features.htm
*** 23670,23676 ****
     provided this notice is preserved.
  
     These pages are [10]maintained by the GCC team. Last modified
!    2023-09-02.
  
  References
  
--- 23753,23759 ----
     provided this notice is preserved.
  
     These pages are [10]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 23686,23691 ****
--- 23769,23775 ----
    10. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/egcs-1.1/caveats.html
+ 
                                  EGCS 1.1 Caveats
  
       * EGCS has an integrated libstdc++, but does not have an integrated
*************** http://gcc.gnu.org/egcs-1.1/caveats.html
*** 23723,23729 ****
     provided this notice is preserved.
  
     These pages are [6]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 23807,23813 ----
     provided this notice is preserved.
  
     These pages are [6]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 23735,23740 ****
--- 23819,23825 ----
     6. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/egcs-1.0/index.html
+ 
                                      EGCS 1.0
  
     December 3, 1997: We are pleased to announce the release of EGCS 1.0.
*************** http://gcc.gnu.org/egcs-1.0/index.html
*** 23918,23924 ****
     provided this notice is preserved.
  
     These pages are [10]maintained by the GCC team. Last modified
!    2023-09-02.
  
  References
  
--- 24003,24009 ----
     provided this notice is preserved.
  
     These pages are [10]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 23934,23939 ****
--- 24019,24025 ----
    10. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/egcs-1.0/features.html
+ 
                                 EGCS 1.0 features
  
       * Core compiler is based on the gcc2 development tree from Aug 2,
*************** http://gcc.gnu.org/egcs-1.0/features.htm
*** 23983,23989 ****
     provided this notice is preserved.
  
     These pages are [8]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 24069,24075 ----
     provided this notice is preserved.
  
     These pages are [8]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
*************** References
*** 23997,24002 ****
--- 24083,24089 ----
     8. https://gcc.gnu.org/about.html
  ======================================================================
  http://gcc.gnu.org/egcs-1.0/caveats.html
+ 
                                  EGCS 1.0 Caveats
  
       * EGCS has an integrated libstdc++, but does not have an integrated
*************** http://gcc.gnu.org/egcs-1.0/caveats.html
*** 24035,24041 ****
     provided this notice is preserved.
  
     These pages are [6]maintained by the GCC team. Last modified
!    2022-10-26.
  
  References
  
--- 24122,24128 ----
     provided this notice is preserved.
  
     These pages are [6]maintained by the GCC team. Last modified
!    2026-07-21.
  
  References
  
diff -Nrcpad gcc-13.4.0/gcc/BASE-VER gcc-13.5.0-RC-20260904/gcc/BASE-VER
*** gcc-13.4.0/gcc/BASE-VER	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/gcc/BASE-VER	Fri Sep  4 07:35:07 2026
***************
*** 1 ****
! 13.4.0
--- 1 ----
! 13.4.1
diff -Nrcpad gcc-13.4.0/gcc/ChangeLog gcc-13.5.0-RC-20260904/gcc/ChangeLog
*** gcc-13.4.0/gcc/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/gcc/ChangeLog	Fri Sep  4 07:35:07 2026
***************
*** 1,3 ****
--- 1,1424 ----
+ 2026-09-03  Francois-Xavier Coudert  
+ 
+ 	Backported from master:
+ 	2025-07-14  François-Xavier Coudert  
+ 
+ 	PR target/120645
+ 	* config/darwin-driver.cc: Account for latest macOS numbering
+ 	scheme.
+ 
+ 2026-09-03  Iain Sandoe  
+ 
+ 	* config/darwin.h: Remove references to heap trampoline
+ 	symbols.
+ 
+ 2026-08-29  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2026-08-29  Georg-Johann Lay  
+ 
+ 	PR middle-end/127098
+ 	* config/avr/avr.md (MPUSH): Add TImode to mode iterator.
+ 	* config/avr/avr.h (PUSH_ROUNDING): Adjust comment.
+ 
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-04  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126601
+ 	* tree-ssa-math-opts.cc (maybe_optimize_guarding_check): Use safe_push
+ 	on mul_stmts rather than quick_push.
+ 
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-04  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126564
+ 	* tree-ssa-phiopt.cc (spaceship_replacement): Fix up condition
+ 	when to punt because of redundant cmp1 with cmp2, xor in
+ 	lhs1 == lhs2 with difference of cmp2 from cmp1 (ignoring
+ 	LT_EXPR vs. LE_EXPR and GT_EXPR vs. GE_EXPR differences) and
+ 	1 if cond2_phi_edge is EDGE_FALSE_VALUE.
+ 
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-03  Jakub Jelinek  
+ 
+ 	PR target/126484
+ 	* config/mips/mips-ftypes.def (MIPS_SI_FTYPE_VOID,
+ 	MIPS_USI_FTYPE_VOID): Use DEF_MIPS_FTYPE with 0 as
+ 	first argument rather than 1 and leave out ", VOID" from
+ 	second argument.
+ 	* config/mips/mips.cc (MIPS_FTYPE_NAME0): Define.
+ 	(MIPS_FTYPE_ATYPES0): Define.
+ 
+ 2026-08-20  Marek Polacek  
+ 
+ 	Backported from master:
+ 	2025-05-14  Marek Polacek  
+ 
+ 	PR c++/116960
+ 	PR c++/119303
+ 	* diagnostic.cc (diagnostic_context::report_diagnostic): Check for
+ 	non-zero m_lock later, after checking diagnostic_enabled.
+ 
+ 2026-08-19  Alice Carlotti  
+ 
+ 	PR target/124629
+ 	* config/aarch64/driver-aarch64.cc (AARCH64_ARCH):
+ 	Don't skip first character of #ARCH_IDENT.
+ 
+ 2026-08-14  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-03-25  Richard Biener  
+ 
+ 	PR tree-optimization/124627
+ 	* tree-inline.cc (copy_debug_stmts): Only copy debug
+ 	stmts that are still in the IL.
+ 
+ 2026-08-14  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-02-17  Richard Biener  
+ 
+ 	PR tree-optimization/124130
+ 	* tree-inline.cc (copy_edges_for_bb): Fixup noreturn calls
+ 	with abnormal edge source.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-31  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126464
+ 	* range-op-float.cc (float_widen_lhs_range): Remove also_inf
+ 	argument, replace its uses as if it was always true.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-30  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126464
+ 	* range-op-float.cc (float_widen_lhs_range): Add also_inf argument
+ 	defaulted to false, if true, extend even lb of +inf and ub of -inf.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-29  Jakub Jelinek  
+ 
+ 	PR target/126446
+ 	* gimple-isel.cc (gimple_expand_vec_set_extract_expr): Punt if
+ 	idx doesn't fit into poly_uint64 but is poly_int_tree_p.  Use
+ 	known_ge rather than known_gt for out of bounds check.  Formatting
+ 	fixes.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-29  Jakub Jelinek  
+ 
+ 	PR target/126446
+ 	* config/i386/i386-expand.cc (ix86_expand_vector_set): If elt is
+ 	out of bounds, emit a no-op move.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-14  Jakub Jelinek  
+ 		    H.J. Lu  
+ 
+ 	PR tree-optimization/120201
+ 	* cfgexpand.cc (expand_used_vars): Set data.asan_alignb to
+ 	maximum of itself and crtl->stack_alignment_needed
+ 	/ BITS_PER_UNIT.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-06-06  Jakub Jelinek  
+ 
+ 	PR target/125611
+ 	* config/i386/sse.md (_pmulhrsw3, smulhrs3):
+ 	Use vector_operand instead of nonimmediate_operand.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-05-01  Jakub Jelinek  
+ 
+ 	PR tree-optimization/125079
+ 	* tree-ssa-strlen.cc (get_string_length): Transform
+ 	__strcat_chk (x, y, z) when we need strlen (x) afterwards into
+ 	l1 = strlen (x); l = __stpcpy_chk (x + l1, y, z - l1) - x;
+ 	where l is the strlen (x), instead of using z as last __stpcpy_chk
+ 	argument.
+ 
+ 2026-07-28  Haochen Jiang  
+ 
+ 	Backported from master:
+ 	2026-07-28  Haochen Jiang  
+ 
+ 	PR target/126429
+ 	* config/i386/sse.md (avx512fmaskhalfmode): Removed.
+ 	(avx512f_dpbf16ps__maskz): Use avx512fmaskmode instead of
+ 	avx512fmaskhalfmode.
+ 	(avx512f_dpbf16ps__mask): Ditto.
+ 	(avx512f_dpbf16ps_): Rename to ...
+ 	(avx512f_dpbf16ps_): ... this. Use
+ 	corresponding sd_mask_op4.
+ 	* config/i386/subst.md (maskz_half): Remove not used pattern.
+ 
+ 2026-07-09  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2026-05-12  Martin Jambor  
+ 
+ 	PR tree-optimization/124151
+ 	* tree-sra.cc (build_user_friendly_ref_for_offset): Added parameters
+ 	CUR_SIZE and EXP_SIZE.  Added code passing the correct CUR_SIZE and
+ 	checking it against EXP_SIZE.  Removed unused code for the case when
+ 	EXP_TYPE was NULL_TREE.
+ 	(create_artificial_child_access): Adjusted the call to
+ 	build_user_friendly_ref_for_offset.
+ 	(propagate_subaccesses_from_rhs): Likewise.
+ 	(propagate_subaccesses_from_rhs): Removed a check that the size of
+ 	lchild is a multiple of BITS_PER_UNIT.
+ 	(propagate_subaccesses_from_lhs): Likewise.
+ 
+ 2026-07-05  Oleg Endo  
+ 
+ 	PR target/67459
+ 	PR target/122948
+ 	* config/sh/sh.md (addc): Fix T bit set expression.
+ 	(subc): Likewise.
+ 
+ 2026-07-01  Stefan Schulze Frielinghaus  
+ 
+ 	Backported from master:
+ 	2026-06-26  Stefan Schulze Frielinghaus  
+ 
+ 	PR target/125972
+ 	* config/s390/s390.cc (s390_rtx_costs): Deal with non-compare
+ 	conditions during costing.  Also fix some indentation.
+ 
+ 2026-06-30  Stefan Schulze Frielinghaus  
+ 
+ 	Backported from master:
+ 	2026-06-12  Stefan Schulze Frielinghaus  
+ 
+ 	PR rtl-optimization/125173
+ 	* ira.cc (combine_and_move_insns): Allow multiple uses within
+ 	an insn.
+ 
+ 2026-06-29  Alex Coplan  
+ 
+ 	Backported from master:
+ 	2026-06-23  Alex Coplan  
+ 
+ 	PR target/125818
+ 	* config/aarch64/aarch64-sve-builtins-base.cc (svset_impl::fold): Fix
+ 	unsharing to ensure the returned stmt has the exact same lhs as the
+ 	original.
+ 
+ 2026-06-17  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-06-10  Andrew Pinski  
+ 
+ 	PR ipa/125699
+ 	* ipa-param-manipulation.cc (ipa_param_body_adjustments::prepare_debug_expressions): Fix
+ 	lifetime issue with m_dead_ssa_debug_equiv usage.
+ 
+ 2026-06-17  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-06-14  Andrew Pinski  
+ 
+ 	PR tree-optimization/125774
+ 	* gimple-range-fold.cc (fold_using_range::relation_fold_and_or): Use
+ 	relation_swap rather than relation_negate when the operands are exchanged.
+ 
+ 2026-06-17  Alex Coplan  
+ 
+ 	Backported from master:
+ 	2026-06-09  Alex Coplan  
+ 
+ 	PR middle-end/125621
+ 	* expmed.cc (make_tree): Fix CONST_POLY_INT case to pass type
+ 	instead of t, move it to its own switch case.
+ 
+ 2026-06-16  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-04-27  Richard Biener  
+ 
+ 	PR tree-optimization/125025
+ 	* tree-ssa-loop-niter.cc (number_of_iterations_ne): Avoid
+ 	negation of most negative signed integer.
+ 	(number_of_iterations_lt): Likewise.
+ 
+ 2026-06-16  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-04-14  Richard Biener  
+ 
+ 	PR tree-optimization/124868
+ 	* gimple-ssa-isolate-paths.cc (handle_return_addr_local_phi_arg):
+ 	Do not diagnose returns in blocks not dominated by the PHI.
+ 	(find_implicit_erroneous_behavior): Do two sweeps over PHIs,
+ 	first for NULL dereferences and then for local address returns.
+ 
+ 2026-06-16  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-02-17  Richard Biener  
+ 
+ 	PR tree-optimization/124132
+ 	* tree-ssa-loop-split.cc (compute_new_first_bound): Fix
+ 	bound difference computation.
+ 
+ 2026-06-16  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-02-03  Richard Biener  
+ 
+ 	PR ipa/123416
+ 	* ipa-modref.cc (ipa_merge_modref_summary_after_inlining):
+ 	Fix typo in condtion for load merging when no callee summary.
+ 
+ 2026-06-16  Jan Hubicka  
+ 
+ 	Backported from master:
+ 	2026-03-10  Jan Hubicka  
+ 		    Andrew Pinski  
+ 
+ 	PR tree-optimization/120987
+ 	* ipa-modref.cc (ipa_merge_modref_summary_after_inlining): Mask
+ 	off non const/pure/novops related flags when combining of outer
+ 	functions.
+ 
+ 2026-06-11  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2026-06-11  Georg-Johann Lay  
+ 
+ 	PR target/125751
+ 	* config/avr/avr.cc (avr_out_fract): Fix too small sequence
+ 	lengths in avr_asm_len calls.
+ 
+ 2026-06-11  Xi Ruoyao  
+ 
+ 	PR target/113233
+ 	* config/loongarch/loongarch.cc (TARGET_OPTION_SAVE): Undefine
+ 	before redefine.
+ 
+ 2026-06-11  Xi Ruoyao  
+ 
+ 	Backported from master:
+ 	2026-05-08  Xi Ruoyao  
+ 
+ 	PR target/125049
+ 	* config/loongarch/predicates.md (ssp_operand): New
+ 	define_predicate.
+ 	(ssp_normal_operand): New define_predicate.
+ 	* config/loongarch/constraints.md (ZE): New define_constraint.
+ 	(ZF): New define_constraint.
+ 	* config/loongarch/loongarch.md (UNSPEC_SSP): New unspec.
+ 	(cbranch4): Add "@" to create gen_cbranch4(machine_mode, ...).
+ 	(@stack_protect_combined_set_normal_): New define_insn.
+ 	(@stack_protect_combined_set_extreme_): New define_insn.
+ 	(@stack_protect_combined_test_internal_): New define_insn.
+ 	(stack_protect_combined_set): New define_expand.
+ 	(stack_protect_combined_test): New define_expand.
+ 	* config/loongarch/loongarch-protos.h
+ 	(loongarch_symbol_extreme_p): Declare.
+ 	(loongarch_output_asm_load_canary): Declare.
+ 	* config/loongarch/loongarch.cc (loongarch_print_operand): Allow
+ 	'v' to print d/w for DImode/SImode.
+ 	(loongarch_symbol_extreme_p): Remove static.
+ 	(loongarch_output_asm_load_canary): Implement.
+ 
+ 2026-06-10  Richard Biener  
+ 
+ 	PR tree-optimization/111387
+ 	* tree-vect-slp.cc (vect_get_and_check_slp_defs): Check
+ 	EDGE_DFS_BACK when doing BB vectorization.
+ 	(vect_slp_function): Mark backedges.
+ 
+ 2026-06-02  John David Anglin  
+ 
+ 	* config/pa/pa.cc (pa_trampoline_init): Rework to use
+ 	clear_cache pattern.
+ 	* config/pa/pa.md (dcacheflush): Use "<<" condition instead
+ 	of "<<=".
+ 	(icacheflush): Remove.
+ 	(icacheflush1, icacheflush2, icacheflush3): New flush patterns
+ 	for PA 1.x targets, PA 2.0 targets, and PA 1.x no space
+ 	register targets.
+ 	(clear_cache): New expander pattern.
+ 
+ 2026-05-27  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2026-04-15  Martin Jambor  
+ 
+ 	PR tree-optimization/122976
+ 	* tree-sra.cc (path_comparable_for_same_access): Return false if the
+ 	base is a MEM_REF with a different underlying type.
+ 
+ 2026-05-25  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2026-05-25  Georg-Johann Lay  
+ 
+ 	PR target/125409
+ 	* config/avr/avr-fixed.md (FIXED_A, FIXED_B): Add PSI to iterators.
+ 
+ 2026-05-03  Collin Funk  
+ 
+ 	Backported from master:
+ 	2026-05-03  Collin Funk  
+ 
+ 	* glimits.h (__STDC_VERSION_LIMITS_H__): Only define the macro
+ 	if it was not already defined.
+ 
+ 2026-04-30  Richard Earnshaw  
+ 
+ 	Backported from master:
+ 	2026-04-14  Richard Earnshaw  
+ 
+ 	PR target/123102
+ 	* config/arm/arm.md (*cmp_ite0): Apply stricter checks on the
+ 	comparison mode.
+ 	(*cmp_ite1, *cmp_and, *cmp_ior): Likewise.
+ 
+ 2026-04-30  Richard Earnshaw  
+ 
+ 	Backported from master:
+ 	2026-04-22  Richard Earnshaw  
+ 
+ 	PR target/124933
+ 	* config/arm/constraints.md (Uj): Allow offset addressing for
+ 	all targets, only allow Neon addressing when we have both Neon
+ 	and FP16INST.
+ 	* config/arm/vfp.md (mov_vfp_16): Only use vld1/vst1
+ 	when the pattern needs address write-back.
+ 
+ 2026-04-13  Richard Earnshaw  
+ 
+ 	Backported from master:
+ 	2026-03-11  Richard Earnshaw  
+ 
+ 	PR target/123271
+ 	* config/arm/arm.md (subvsi3_intmin): Renamed to ...
+ 	(sub_cmpVsi3_intmin): ... this.
+ 	(subvsi3): Renamed to ...
+ 	(sub_cmpVsi3): ... this.
+ 	(subvsi3_imm1): Renamed to ...
+ 	(sub_cmpVsi3_imm1): ... this.
+ 	(usubvsi3_borrow): Renamed to ...
+ 	(usub_cmpVsi3_borrow): ... this.
+ 	(usubvsi3_borrow_imm): Renamed to ...
+ 	(usub_cmpVsi3_borrow_imm): ... this.
+ 	(subvsi3_borrow): Renamed to ...
+ 	(sub_cmpVsi3_borrow): ... this.
+ 	(subvsi3_borrow_imm): Renamed to ...
+ 	(sub_cmpVsi3_borrow_imm): ... this.
+ 
+ 2026-04-09  Richard Biener  
+ 
+ 	Revert:
+ 	2026-03-20  Richard Biener  
+ 
+ 	PR ipa/116296
+ 	* ipa-modref-tree.cc (modref_access_node::contains): Use
+ 	poly_offset_int for the param offset difference and the
+ 	overlap computation.
+ 
+ 2026-04-09  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-04-09  Andrew Pinski  
+ 
+ 	PR target/117771
+ 	PR c/124830
+ 	* system.h: Move the include of sstream and memory above safe-ctype.h.
+ 
+ 2026-04-09  Xi Ruoyao  
+ 
+ 	Backported from master:
+ 	2026-04-09  Xi Ruoyao  
+ 
+ 	PR target/105192
+ 	* ifcvt.cc (find_if_header): Don't attempt to use ctrap expander
+ 	after reload.
+ 
+ 2026-03-31  Eric Botcazou  
+ 
+ 	* tree-ssa-dse.cc (compute_trims): Bail out if ref->size is not
+ 	byte aligned either.
+ 
+ 2026-03-27  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2026-02-20  Martin Jambor  
+ 
+ 	PR ipa/122856
+ 	* ipa-cp.cc (self_recursive_pass_through_p): Test jump function type first.
+ 	(self_recursive_ancestor_p): New function.
+ 	(find_scalar_values_for_callers_subset): Test also for self-recursive
+ 	ancestor jump functions.
+ 	(push_agg_values_for_index_from_edge): Likewise.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-06  Jakub Jelinek  
+ 
+ 	PR tree-optimization/124135
+ 	* tree-inline.cc (expand_call_inline): If both gimple_call_lhs (stmt)
+ 	and use_retvar aren't gimple regs but have gimple reg type, use
+ 	separate load of use_retva into SSA_NAME and then store of it
+ 	into gimple_call_lhs (stmt).
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-06  Jakub Jelinek  
+ 
+ 	PR tree-optimization/124358
+ 	* match.pd ((ptr) (x p+ y) p+ z -> (ptr) (x p+ (y + z))): Simplify
+ 	into (ptr) x p+ (y + z) instead.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-05  Jakub Jelinek  
+ 
+ 	PR target/124366
+ 	* config/i386/i386.md (@wrss, @wruss): Swap operand
+ 	order for -masm=intel.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-03  Jakub Jelinek  
+ 
+ 	PR target/124315
+ 	* config/i386/sse.md (avx512f_vmfmadd__mask3,
+ 	avx512f_vmfmsub__mask3,
+ 	avx512f_vmfnmadd__mask3,
+ 	avx512f_vmfnmsub__mask3): Use %1 instead of
+ 	%3 in -masm=intel syntax.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-03  Jakub Jelinek  
+ 
+ 	PR target/124335
+ 	* config/i386/sse.md (*avx512f_load_mask): Use %{%3%} instead of
+ 	%{3%} for -masm=intel syntax.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-18  Jakub Jelinek  
+ 
+ 	PR target/124138
+ 	* config/i386/i386.cc (avx_vpermilp_parallel): Verify
+ 	ipar[2] and ipar[3] aren't larger than 3.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-11  Jakub Jelinek  
+ 
+ 	PR middle-end/124056
+ 	* cfgexpand.cc (expand_asm_stmt): If after_md_seq is non-NULL, emit
+ 	it at the start of after_rtl_seq instead of after fallthru_label.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-11  Jakub Jelinek  
+ 
+ 	PR rtl-optimization/116600
+ 	PR middle-end/123386
+ 	* cfgrtl.cc (force_nonfallthru_and_redirect): Don't do any
+ 	asm goto adjustments early, only note in asm_goto_edge if
+ 	any labels point originally to e->dest head.  After jumpblock
+ 	creation don't add an extra edge for asm_goto_edge, instead
+ 	adjust those labels pointing to former e->dest head to point
+ 	to jumpblock instead.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-06  Jakub Jelinek  
+ 
+ 	PR c/101312
+ 	* alias.cc (get_alias_set): Allow TYPE_CANONICAL (mv) to be
+ 	not its own TYPE_MAIN_VARIANT, as long as its TYPE_MAIN_VARIANT
+ 	has TYPE_CANONICAL equal to itself.
+ 	* tree.cc (verify_type): Likewise.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-04  Jakub Jelinek  
+ 
+ 	PR c++/123818
+ 	* tree.cc (simple_cst_equal) : Return -1 if some
+ 	recursive call returns -1.  Also compare indexes.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-30  Jakub Jelinek  
+ 
+ 	PR tree-optimization/123864
+ 	* match.pd (__builtin_mul_overflow_p (x, cst, (stype) 0) ->
+ 	x > stype_max / cst || x < stype_min / cst): Only check
+ 	integer_minus_onep for signed types.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-30  Jakub Jelinek  
+ 
+ 	PR middle-end/123876
+ 	* omp-low.cc (diagnose_sb_2): Handle GIMPLE_ASM.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-23  Jakub Jelinek  
+ 
+ 	PR middle-end/123703
+ 	* builtins.cc (fold_builtin_abs): Return NULL_TREE if type is not
+ 	integral.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-22  Jakub Jelinek  
+ 
+ 	PR tree-optimization/123736
+ 	* tree-ssa-loop-unswitch.cc (hoist_guard): Guard dump message
+ 	on dump_file && (dump_flags & TDF_DETAILS) condition.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-17  Jakub Jelinek  
+ 
+ 	PR tree-optimization/123513
+ 	* tree.cc (valid_new_delete_pair_p): If new_name[3] or delete_name[3]
+ 	is 'I', return false with *pcertain set to false rather than true.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-14  Jakub Jelinek  
+ 
+ 	PR target/120250
+ 	* combine.cc (recog_for_combine): Don't try to put SET_SRC
+ 	into a constant pool if SET_DEST is pc_rtx.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-10  Jakub Jelinek  
+ 
+ 	PR tree-optimization/123431
+ 	* gimple-range-op.cc (gimple_range_op_handler::maybe_builtin_call):
+ 	Punt if type-generic builtins with a single argument don't have
+ 	exactly one argument.  For returns_arg punt if call doesn't have
+ 	at least one argument.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-09  Jakub Jelinek  
+ 
+ 	* doc/invoke.texi (-x): Add objc-cpp-output,
+ 	objc++-cpp-output, adascil, adawhy, modula-2, modula-2-cpp-output,
+ 	rust and lto as further possible option arguments.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-08  Jakub Jelinek  
+ 
+ 	PR middle-end/111817
+ 	* stmt.cc (parse_input_constraint): For matching construct, goto
+ 	before the loop without changing j instead of break.  Remove comment
+ 	about that problem.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-07  Jakub Jelinek  
+ 
+ 	PR rtl-optimization/119291
+ 	PR rtl-optimization/121773
+ 	* combine.cc (try_combine): Check that SET_DEST (setN) is neither
+ 	modified_between_p nor reg_used_between_p instead of just not
+ 	reg_used_between_p or pc_rtx.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-06  Jakub Jelinek  
+ 		    Marco Falke  
+ 
+ 	PR tree-optimization/123351
+ 	* tree-object-size.cc (object_sizes_set_temp): Separate calls to
+ 	make_ssa_name to ensure deterministic execution order.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-12-20  Jakub Jelinek  
+ 
+ 	PR target/123217
+ 	* config/i386/i386-expand.cc (ix86_expand_builtin)
+ 	: Set target to a new pseudo even
+ 	if it is non-NULL but doesn't satisfy register_operand predicate.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-12-19  Jakub Jelinek  
+ 
+ 	* doc/install.texi (--with-tls=): Fix a typo, were -> where.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-12-17  Jakub Jelinek  
+ 
+ 	PR target/123155
+ 	* config/i386/xmmintrin.h (_mm_maskmove_si64): Rename offset automatic
+ 	variable to __offset.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-25  Jakub Jelinek  
+ 
+ 	PR middle-end/120052
+ 	* gimplify.cc (gimplify_call_expr): For IFN_UBSAN_BOUNDS
+ 	call with integer_onep first argument, change that argument
+ 	to 0 and add TYPE_MAX_VALUE (TYPE_DOMAIN (arr_type)) to
+ 	3rd argument before gimplification.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-25  Jakub Jelinek  
+ 
+ 	PR middle-end/120564
+ 	* omp-expand.cc (extract_omp_for_update_vars): Use build2 instead of
+ 	fold_build2 to build argument for gimple_build_cond_empty.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-11  Jakub Jelinek  
+ 
+ 	PR lto/122620
+ 	* gimplify-me.cc (gimple_regimplify_operands): Don't try to regimplify
+ 	TREE_CLOBBER on rhs of gimple_clobber_p if it has gimple_reg_type.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	PR tree-optimization/122394
+ 	* tree-ssa-phiopt.cc (spaceship_replacement): Use
+ 	build_debug_expr_decl instead of manually building DEBUG_EXPR_DECL
+ 	and getting SET_DECL_MODE wrong.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-10-04  Jakub Jelinek  
+ 
+ 	PR tree-optimization/122104
+ 	* tree-ssa-math-opts.cc (maybe_optimize_guarding_check): Call
+ 	reset_flow_sensitive_info_in_bb on bb when optimizing out the
+ 	guarding condition.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-09-18  Jakub Jelinek  
+ 
+ 	PR c++/121977
+ 	* omp-low.cc (lower_omp_regimplify_operands_p): If maybe_lookup_decl
+ 	returns NULL, use maybe_lookup_decl_in_outer_ctx as fallback.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-08-25  Jakub Jelinek  
+ 
+ 	PR middle-end/121453
+ 	* omp-expand.cc (expand_omp_for_init_counts): Clear fd->loop.n2
+ 	before first zero count check if zero_iter1_bb is non-NULL upon
+ 	entry and fd->loop.n2 has not been written yet.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-09-08  Richard Biener  
+ 
+ 	PR tree-optimization/107997
+ 	PR tree-optimization/121844
+ 	* tree-ssa-loop-ivopts.cc (allow_ip_end_pos_p): Do not allow
+ 	IP_END for latches ending with a control stmt.
+ 	(create_new_iv): Do not split the latch edge, instead assert
+ 	that's not necessary.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-05-09  Richard Biener  
+ 
+ 	PR rtl-optimization/120182
+ 	* dse.cc (canon_address): Constant addresses have no
+ 	separate store group.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-03-31  Richard Biener  
+ 
+ 	PR tree-optimization/119532
+ 	* tree-tailcall.cc (process_assignment): FAIL for fixed-point
+ 	typed functions.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-30  Richard Biener  
+ 
+ 	PR tree-optimization/109410
+ 	* tree-ssa-reassoc.cc (build_and_add_sum): Use
+ 	gsi_start_nondebug_after_labels_bb to look for a possible
+ 	returns-twice call.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-30  Richard Biener  
+ 
+ 	PR debug/123886
+ 	* dwarf2out.cc (sym_off_pair::sym): Remove GTY((skip)).
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-19  Richard Biener  
+ 
+ 	PR tree-optimization/123602
+ 	* tree-ssa-pre.cc (find_or_generate_expression): Do not
+ 	generate references to abnormal SSA names.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-08-05  Richard Biener  
+ 
+ 	PR tree-optimization/121370
+ 	* tree-scalar-evolution.cc (scev_dfs::add_to_evolution_1):
+ 	Avoid UB integer overflow in accumulating CHREC_RIGHT.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-03-16  Richard Biener  
+ 
+ 	PR tree-optimization/120341
+ 	* tree-ssa-loop-im.cc (can_sm_ref_p): STRING_CSTs are readonly.
+ 
+ 2026-03-20  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2024-08-22  Andrew Pinski  
+ 		    Richard Biener   
+ 
+ 	PR middle-end/116454
+ 	* fold-const.cc (fold_binary_loc): Fix `a * +-1i`
+ 	by wrapping arg0 with save_expr when it is not COMPLEX_EXPR.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-27  Richard Biener  
+ 
+ 	PR ipa/116296
+ 	* ipa-modref-tree.cc (modref_access_node::contains): Use
+ 	poly_offset_int for the param offset difference and the
+ 	overlap computation.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-28  Richard Biener  
+ 
+ 	PR ipa/111036
+ 	* match.pd (__builtin_constant_p ((T)x)): Strip nop-conversions
+ 	from __builtin_constant_p arguments.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-28  Richard Biener  
+ 
+ 	PR tree-optimization/110043
+ 	* pointer-query.cc (get_offset_range): Fail for integer
+ 	types with precision larger than ptrdiff_type_node.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-28  Richard Biener  
+ 
+ 	PR rtl-optimization/106859
+ 	* var-tracking.cc (val_store): Dump -1 as UID if setting_insn
+ 	is NULL.
+ 
+ 2026-03-14  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-03-04  Andrew Pinski  
+ 
+ 	PR tree-optimization/119568
+ 	* tree-ssa-math-opts.cc (convert_plusminus_to_widen): Reject different
+ 	mode classes.
+ 
+ 2026-03-14  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-01-18  Andrew Pinski  
+ 
+ 	PR tree-optimization/123645
+ 	* tree-ssa-phiopt.cc (cond_removal_in_builtin_zero_pattern): Rewrite
+ 	the canonicalization of the args code based on e1/e2 being edges into
+ 	the join block.
+ 
+ 2026-03-14  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2025-09-02  Andrew Pinski  
+ 
+ 	PR tree-optimization/121776
+ 	* tree-ssa-strlen.cc (strlen_pass::handle_builtin_memcmp): Create
+ 	unaligned types if the alignment of the pointers is less
+ 	than the alignment of the new type.
+ 
+ 2026-03-09  Kalvis Duckmanton  
+ 
+ 	Backported from master:
+ 	2026-02-14  Kalvis Duckmanton  
+ 
+ 	PR target/112400
+ 	* config/vax/vax.md (casesi1): Wrap naked operand 1 with a USE
+ 	where used with the insn split to.
+ 	(*casesi1): Likewise naked incoming operand 1.
+ 
+ 2026-03-04  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2026-02-09  Martin Jambor  
+ 
+ 	PR tree-optimization/117217
+ 	* tree-sra.cc (propagate_subaccesses_from_rhs): Do not propagate
+ 	bit-field children.
+ 	(propagate_subaccesses_from_lhs): Likewise.
+ 
+ 2026-03-04  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2026-02-06  Martin Jambor  
+ 
+ 	PR ipa/106260
+ 	* ipa-cp.cc (initialize_node_lattices): Replace assert that there are
+ 	callers with handling that situation when -fno-toplevel_reorder.
+ 
+ 2026-02-05  Hongyu Wang  
+ 
+ 	Backported from master:
+ 	2026-01-28  Hongyu Wang  
+ 
+ 	PR target/123779
+ 	* config/i386/sse.md (*sse4_1_v8qiv8hi2_2):
+ 	Rename to ...
+ 	(*sse4_1_v8qiv8hi2_2): ... this, and drop mask conditions.
+ 	(*avx2_v8qiv8si2_2): Rename to ...
+ 	(*avx2_v8qiv8si2_2): ... this, and likewise.
+ 	(*sse4_1_v4qiv4si2_2): Rename to ...
+ 	(*sse4_1_v4qiv4si2_2): ... this, and likewise.
+ 	(*sse4_1_v4hiv4si2_2): Rename to ...
+ 	(*sse4_1_v4hiv4si2_2): ... this, and likewise.
+ 	(*avx2_v4qiv4di2_2): Rename to ...
+ 	(*avx2_v4qiv4di2_2): ... this, and likewise.
+ 	(*avx2_v4hiv4di2_2): Rename to ...
+ 	(*avx2_v4hiv4di2_2): ... this, and likewise.
+ 	(*sse4_1_v2hiv2di2_2): Rename to ...
+ 	(*sse4_1_v2hiv2di2_2): ... this, and likewise.
+ 	(*sse4_1_v2siv2di2_2): Rename to ...
+ 	(*sse4_1_v2siv2di2_2): ... this, and likewise.
+ 	(*avx512f_v8qiv8di2_2): Rename to ...
+ 	(*avx512f_v8qiv8di2_2): ... this.
+ 	(*avx512vl_v8qiv8hi2_mask_2): New define_insn_and_split.
+ 	(*avx512vl_v8qiv8si2_mask_2): Likewise.
+ 	(*avx512vl_v4qiv4si2_mask_2): Likewise.
+ 	(*avx512vl_v4hiv4si2_mask_2): Likewise.
+ 	(*avx512f_v8qiv8di2_mask_2): Likewise.
+ 	(*avx512vl_v4qiv4di2_mask_2): Likewise.
+ 	(*avx512vl_v4hiv4di2_mask_2): Likewise.
+ 	(*avx512vl_v2hiv2di2_mask_2): Likewise.
+ 	(*avx512vl_v2siv2di2_mask_2): Likewise.
+ 
+ 2026-01-23  Avinash Jayakar  
+ 
+ 	PR target/119130
+ 	* config/rs6000/altivec.md (convert_4f32_8f16): Use same operand
+ 	order for both endian format.
+ 
+ 2026-01-16  Alice Carlotti  
+ 
+ 	PR target/123460
+ 	* config.gcc: Accept hyphens in aarch64 --with-arch extensions.
+ 
+ 2026-01-16  LIU Hao  
+ 
+ 	Backported from master:
+ 	2025-05-06  LIU Hao  
+ 
+ 	PR pch/14940
+ 	* config/i386/host-mingw32.cc (mingw32_gt_pch_use_address):
+ 	Replace the loop that attempted to map the PCH only to its
+ 	original address with more adaptive operations
+ 
+ 2026-01-16  Vladimir N. Makarov  
+ 
+ 	PR rtl-optimization/123121
+ 	* lra-remat.cc (bad_for_rematerialization_p): Consider div/mod ops.
+ 	(operand_to_remat): Exclude rematerialization of insns with
+ 	multiple sets.
+ 
+ 2026-01-06  Avinash Jayakar  
+ 
+ 	PR tree-optimization/122126
+ 	* gimple-isel.cc (gimple_expand_vec_set_extract_expr): Add bound check.
+ 
+ 2025-12-01  Avinash Jayakar  
+ 
+ 	Revert:
+ 	2025-11-28  Avinash Jayakar  
+ 
+ 	PR tree-optimization/122126
+ 	* gimple-isel.cc (gimple_expand_vec_set_extract_expr): Add bound check.
+ 
+ 2025-11-28  Avinash Jayakar  
+ 
+ 	PR tree-optimization/122126
+ 	* gimple-isel.cc (gimple_expand_vec_set_extract_expr): Add bound check.
+ 
+ 2025-11-27  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2025-11-27  Georg-Johann Lay  
+ 
+ 	* config/avr/avr-mcus.def (AVR_MCUS): Add avr16la14, avr16la20,
+ 	avr16la28, avr16la32, avr32la14, avr32la20, avr32la28, avr32la32.
+ 	* doc/avr-mmcu.texi: Rebuild.
+ 
+ 2025-11-27  Richard Earnshaw  
+ 
+ 	Backported from master:
+ 	2025-11-26  Richard Earnshaw  
+ 
+ 	PR target/122867
+ 	* config/arm/arm.cc (arm_print_operand): Use %- to
+ 	emit LOCAL_LABEL_PREFIX.
+ 	(arm_print_operand_punct_valid_p): Allow %- for punct
+ 	and make %_ valid for all compilation variants.
+ 	* config/arm/thumb2.md (*thumb2_cbz): Handle very
+ 	large branch ranges that exceed the limit of b.
+ 	(*thumb2_cbnz): Likewise.
+ 
+ 2025-11-24  Jan Hubicka  
+ 
+ 	Backported from master:
+ 	2024-09-03  Jan Hubicka  
+ 
+ 	* config/i386/x86-tune-sched.cc (ix86_fuse_mov_alu_p): Fix
+ 	typo.
+ 
+ 2025-11-18  Richard Biener  
+ 	    Alex Coplan  
+ 
+ 	PR tree-optimization/112469
+ 	PR tree-optimization/122724
+ 	* match.pd (cond ? op a : b -> .COND_op (cond, a, b)): Add
+ 	missing view_converts.
+ 
+ 2025-11-13  Hu, Lin1  
+ 
+ 	Backported from master:
+ 	2025-11-13  Hu, Lin1  
+ 
+ 	PR target/122446
+ 	* config/i386/amxbf16intrin.h (_tile_dpbf16ps_internal):
+ 	Input register name by inline asm %c[...], and remove %% before tmm
+ 	from intel side.
+ 	* config/i386/amxcomplexintrin.h (_tile_cmmimfp16ps_internal): Ditto
+ 	(_tile_cmmrlfp16ps_internal): Ditto
+ 	(_tile_cmmimfp16ps): Ditto
+ 	(_tile_cmmrlfp16ps): Ditto
+ 	* config/i386/amxfp16intrin.h (_tile_dpfp16ps_internal): Ditto
+ 	(_tile_dpfp16ps): Ditto
+ 	* config/i386/amxint8intrin.h (_tile_int8_dp_internal): Ditto
+ 	* config/i386/amxtileintrin.h (_tile_loadd): Ditto
+ 	(_tile_loadd_internal): Ditto
+ 	(_tile_stream_loadd): Ditto
+ 	(_tile_stream_loadd_internal): Ditto
+ 	(_tile_stored): Ditto
+ 	(_tile_stored_internal): Ditto
+ 	(_tile_zero): Ditto
+ 	(_tile_zero_internal): Ditto
+ 
+ 2025-11-07  Christophe Lyon  
+ 
+ 	PR target/122223
+ 	* config/arm/mve.md (@mve_vbicq_f): Fix operands order.
+ 
+ 2025-11-06  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2025-11-06  Georg-Johann Lay  
+ 
+ 	PR target/122516
+ 	* config/avr/elf.h (SUPPORTS_SHF_GNU_RETAIN): Define if
+ 	HAVE_GAS_SHF_GNU_RETAIN.
+ 
+ 2025-10-31  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-09-11  Richard Biener  
+ 
+ 	PR tree-optimization/121870
+ 	* tree-ssa-propagate.cc
+ 	(substitute_and_fold_engine::substitute_and_fold): Skip
+ 	removed stmts from noreturn fixup.
+ 
+ 2025-10-31  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-10-14  Richard Biener  
+ 
+ 	PR tree-optimization/121256
+ 	* tree-vect-loop.cc (vectorizable_recurr): Build a correct
+ 	initialization vector for SLP_TREE_LANES > 1.
+ 
+ 2025-10-31  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-10-14  Richard Biener  
+ 		    Richard Sandiford   
+ 
+ 	PR tree-optimization/121059
+ 	* tree-vect-stmts.cc (vectorizable_operation): Query
+ 	scalar_cond_masked_set with the correct number of masks.
+ 
+ 2025-10-31  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-07-04  Richard Biener  
+ 
+ 	PR tree-optimization/120944
+ 	* tree-ssa-sccvn.cc (vn_reference_lookup_3): Gate optimizations
+ 	invalid when volatile is involved.
+ 
+ 2025-10-31  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-07-07  Richard Biener  
+ 
+ 	PR tree-optimization/120817
+ 	* tree-ssa-dse.cc (initialize_ao_ref_for_dse): Use
+ 	ao_ref_init_from_ptr_and_range with unknown size for
+ 	.MASK_STORE and .MASK_LEN_STORE.
+ 
+ 2025-10-26  LIU Hao  
+ 
+ 	Backported from master:
+ 	2025-10-26  LIU Hao  
+ 
+ 	PR target/119079
+ 	* config/i386/i386.md: Use `movsxd` to perform SI-to-DI extension in Intel
+ 	syntax.
+ 
+ 2025-10-20  Svante Signell  
+ 
+ 	Backported from master:
+ 	2025-10-20  Svante Signell  
+ 
+ 	PR go/104290
+ 	* config/gnu.h (OPTION_GLIBC_P, OPTION_GLIBC): Define.
+ 
+ 2025-10-16  Alex Coplan  
+ 
+ 	Backported from master:
+ 	2025-09-15  Alex Coplan  
+ 
+ 	PR tree-optimization/121772
+ 	* match.pd: Add type check to reduc(ctor) pattern.
+ 
+ 2025-10-16  Ayappan Perumal  
+ 
+ 	Backported from master:
+ 	2025-10-16  Ayappan Perumal  
+ 
+ 	* config/rs6000/aix.h (SUBTARGET_DRIVER_SELF_SPECS):
+ 	Error out when stack-protector option is used in AIX
+ 	as it is not supported on AIX
+ 	Approved By: Segher Boessenkool 
+ 
+ 2025-10-14  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-05-09  Richard Biener  
+ 
+ 	PR tree-optimization/120156
+ 	* tree-ssa-alias.cc (ptr_deref_may_alias_decl_p): Verify
+ 	the pointer is an SSA name.
+ 
+ 2025-10-03  Jeff Law  
+ 
+ 	Backported from master:
+ 	2023-06-12  Jeff Law  
+ 
+ 	PR rtl-optimization/101188
+ 	* postreload.cc (reload_cse_move2add_invalidate): New function,
+ 	extracted from...
+ 	(reload_cse_move2add): Call reload_cse_move2add_invalidate.
+ 
+ 2025-09-18  hongtao.liu  
+ 
+ 	Backported from master:
+ 	2025-09-18  hongtao.liu  
+ 
+ 	* config/i386/x86-tune.def (X86_TUNE_AVX512_MOVE_BY_PIECES):
+ 	Remove SPR/GNR/DMR.
+ 	(X86_TUNE_AVX512_STORE_BY_PIECES): Ditto.
+ 
+ 2025-09-17  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2025-08-20  Martin Jambor  
+ 
+ 	PR tree-optimization/119085
+ 	* tree-sra.cc (sort_and_splice_var_accesses): Prevent total
+ 	scalarization if two incompatible aggregates access the same place.
+ 
+ 2025-09-17  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2025-09-17  Martin Jambor  
+ 
+ 	PR tree-optimization/117423
+ 	* tree-sra.cc (analyze_access_subtree): Fix computation of grp_covered
+ 	flag.
+ 
+ 2025-09-16  Jeff Law  
+ 
+ 	Backported from master:
+ 	2025-09-12  Jeff Law  
+ 
+ 	* lra-constraints.cc (get_equiv): Bounds check before accessing
+ 	data in ira_reg_equiv.
+ 
+ 2025-09-15  Georg-Johann Lay  
+ 
+ 	* config/avr/avr-mcus.def: Support AVR32DA28S, AVR32DA32S,
+ 	AVR32DA48S, AVR64DA28S, AVR64DA32S, AVR64DA48S AVR64DA64S,
+ 	AVR128DA28S, AVR128DA32S, AVR128DA48S, AVR128DA64S,
+ 	AVR32EB14, AVR32EB20, AVR32EB28, AVR32EB32.
+ 	* doc/avr-mmcu.texi: Rebuild.
+ 
+ 2025-09-10  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2025-09-10  Georg-Johann Lay  
+ 
+ 	PR target/81540
+ 	PR target/49857
+ 	* common/config/avr/avr-common.cc: Disable -ftree-switch-conversion.
+ 
+ 2025-08-20  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2025-08-20  Georg-Johann Lay  
+ 
+ 	PR target/121608
+ 	* config/avr/specs.h (LINK_RELAX_SPEC): Wrap in %{!r...}.
+ 
+ 2025-08-18  Richard Sandiford  
+ 
+ 	Backported from master:
+ 	2025-08-18  Richard Sandiford  
+ 
+ 	PR target/121118
+ 	* config/aarch64/aarch64.cc (aarch64_sve_move_pred_via_while):
+ 	Return a VNx16BI predicate.
+ 
+ 2025-08-18  Richard Sandiford  
+ 
+ 	Backported from master:
+ 	2025-08-12  Richard Sandiford  
+ 
+ 	PR rtl-optimization/121253
+ 	* fwprop.cc (forward_propagate_into): Don't propagate asm defs.
+ 
+ 2025-08-15  Pengfei Li  
+ 
+ 	PR target/121449
+ 	* config/aarch64/aarch64-sve.md
+ 	(mask_gather_load): Use vg
+ 	constraints for alternatives with immediate offset.
+ 	(mask_scatter_store): Likewise.
+ 
+ 2025-08-14  Richard Sandiford  
+ 
+ 	Backported from master:
+ 	2025-08-14  Richard Sandiford  
+ 
+ 	PR target/121294
+ 	* config/aarch64/aarch64.md (UNSPEC_REV_PRED): New unspec.
+ 	* config/aarch64/aarch64-sve.md (@aarch64_sve_rev_acle)
+ 	(*aarch64_sve_rev_acle): New patterns.
+ 	* config/aarch64/aarch64-sve-builtins-base.cc
+ 	(svrev_impl::expand): Use the new patterns for boolean svrev.
+ 
+ 2025-08-14  Richard Sandiford  
+ 
+ 	Backported from master:
+ 	2025-08-14  Richard Sandiford  
+ 
+ 	PR target/121294
+ 	* config/aarch64/iterators.md (UNSPEC_TRN1_CONV): Delete.
+ 	(UNSPEC_PERMUTE_PRED): New unspec.
+ 	* config/aarch64/aarch64-sve.md (@aarch64_sve_trn1_conv):
+ 	Replace with...
+ 	(@aarch64_sve__acle)
+ 	(*aarch64_sve__acle): ...these new patterns.
+ 	* config/aarch64/aarch64.cc (aarch64_expand_sve_const_pred_trn):
+ 	Update accordingly.
+ 	* config/aarch64/aarch64-sve-builtins-functions.h
+ 	(binary_permute::expand): Use the new _acle patterns for
+ 	predicate operations.
+ 
+ 2025-08-14  H.J. Lu  
+ 
+ 	Backported from master:
+ 	2025-07-28  H.J. Lu  
+ 
+ 	PR target/121208
+ 	* config/i386/i386.cc (ix86_tls_get_addr): Issue an error for
+ 	-mtls-dialect=gnu with no_caller_saved_registers attribute and
+ 	suggest -mtls-dialect=gnu2.
+ 
+ 2025-07-31  H.J. Lu  
+ 
+ 	Backported from master:
+ 	2025-07-30  H.J. Lu  
+ 
+ 	PR target/120427
+ 	* config/i386/i386.md (peephole2): Transform "movq $-1,reg" to
+ 	"pushq $-1; popq reg" for -Oz if reg is a legacy integer register.
+ 
+ 2025-07-29  H.J. Lu  
+ 
+ 	Backported from master:
+ 	2025-06-19  H.J. Lu  
+ 
+ 	PR target/120427
+ 	* config/i386/i386.md (*mov_and): Changed to
+ 	define_insn_and_split.  Split it to "mov $0,mem" if not -Oz.
+ 	(*mov_or): Changed to define_insn_and_split.  Split it
+ 	to "mov $-1,mem" if not -Oz.
+ 	(peephole2): Don't transform "mov $-1,reg" to "push $-1; pop reg"
+ 	for -Oz since it will be transformed to "or $-1,reg".
+ 
+ 2025-07-17  H.J. Lu  
+ 
+ 	Backported from master:
+ 	2025-07-03  H.J. Lu  
+ 
+ 	PR target/120908
+ 	* config/i386/i386.cc (legitimize_tls_address): Pass RDI to
+ 	gen_tls_local_dynamic_64.
+ 	* config/i386/i386.md (*tls_global_dynamic_64_largepic): Add
+ 	RDI clobber and use it to generate LEA.
+ 	(*tls_local_dynamic_64_): Likewise.
+ 	(*tls_local_dynamic_base_64_largepic): Likewise.
+ 	(@tls_local_dynamic_64_): Add a clobber.
+ 
+ 2025-07-17  H.J. Lu  
+ 
+ 	Backported from master:
+ 	2025-07-02  H.J. Lu  
+ 
+ 	PR target/120908
+ 	* config/i386/i386.cc (legitimize_tls_address): Pass RDI to
+ 	gen_tls_global_dynamic_64.
+ 	* config/i386/i386.md (*tls_global_dynamic_64_): Add RDI
+ 	clobber and use it to generate LEA.
+ 	(@tls_global_dynamic_64_): Add a clobber.
+ 
+ 2025-06-27  Eric Botcazou  
+ 
+ 	* gimple-fold.cc (fold_const_aggregate_ref_1) :
+ 	Bail out immediately if the reference has reverse storage order.
+ 	* tree-ssa-sccvn.cc (fully_constant_vn_reference_p): Likewise.
+ 
+ 2025-06-25  Haochen Jiang  
+ 
+ 	* config/i386/i386.h (PTA_ALDERLAKE): Use PTA_GOLDMONT_PLUS
+ 	as base to remove PTA_CLDEMOTE.
+ 	(PTA_SIERRAFOREST): Add PTA_CLDEMOTE since PTA_ALDERLAKE
+ 	does not include that anymore.
+ 	* doc/invoke.texi: Update texi file.
+ 
+ 2025-06-13  Richard Earnshaw  
+ 
+ 	Backported from master:
+ 	2025-03-25  Richard Earnshaw  
+ 
+ 	PR middle-end/117811
+ 	* optabs.cc (expand_binop_directly): Remove LAST as an argument,
+ 	instead record the last insn on entry.  Only delete insns if
+ 	we need to restart and restart by calling ourself, not expand_binop.
+ 	(expand_binop): Update callers to expand_binop_directly.  If it
+ 	fails to expand the operation, delete back to LAST.
+ 
+ 2025-06-05  Eric Botcazou  
+ 
+ 	* tree-vect-data-refs.cc (vect_can_force_dr_alignment_p): Return
+ 	false if the variable has no symtab node.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/gcc/DATESTAMP gcc-13.5.0-RC-20260904/gcc/DATESTAMP
*** gcc-13.4.0/gcc/DATESTAMP	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/DATESTAMP	Fri Sep  4 07:35:07 2026
***************
*** 1 ****
! 20250605
--- 1 ----
! 20260904
diff -Nrcpad gcc-13.4.0/gcc/ada/ChangeLog gcc-13.5.0-RC-20260904/gcc/ada/ChangeLog
*** gcc-13.4.0/gcc/ada/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/ChangeLog	Fri Sep  4 07:35:07 2026
***************
*** 1,3 ****
--- 1,58 ----
+ 2026-06-10  Eric Botcazou  
+ 
+ 	PR ada/125695
+ 	* libgnat/s-genbig.adb ("**"): Do not drop the sign on the floor.
+ 	(Big_Exp): Take into account the parity of the exponent for -2.
+ 
+ 2026-04-12  Eric Botcazou  
+ 
+ 	PR ada/124836
+ 	* adaint.c [__MINGW32__]: Do not include mingw32.h twice, and also
+ 	include sys/param.h.
+ 
+ 2026-03-23  Eric Botcazou  
+ 
+ 	PR ada/124607
+ 	* sem_elab.adb (Has_Body.Find_Body): Fix thinko.
+ 
+ 2026-03-14  Matthias Klose  
+ 
+ 	PR ada/107475
+ 	* Makefile.rtl (s390% linux%): Define MISCLIB.
+ 	(arm% linux-gnueabi%): Likewise.
+ 	(%x32 linux%): Likewise.
+ 
+ 2026-02-28  Eric Botcazou  
+ 
+ 	PR ada/124285
+ 	* gcc-interface/decl.cc (components_to_record): Force a packed
+ 	layout for the innermost variant of an unchecked union type with
+ 	fixed part and full representation clause.
+ 
+ 2026-02-25  Eric Botcazou  
+ 
+ 	PR ada/124226
+ 	* sem_res.adb (Resolve_Implicit_Dereference): Move declaration to...
+ 	* sem_res.ads (Resolve_Implicit_Dereference): ...here.
+ 	* sem_attr.adb (Resolve_Attribute) : Also call
+ 	Resolve_Implicit_Dereference when resolving a protected operation.
+ 
+ 2026-02-20  Eric Botcazou  
+ 
+ 	* libgnat/s-stposu.adb (Finalize_Pool): Pass a local copy of the
+ 	handle in the call to Finalize_And_Deallocate.
+ 
+ 2025-10-20  Eric Botcazou  
+ 
+ 	PR ada/107536
+ 	* exp_ch2.adb (Expand_Renaming): Mark the entity as referenced.
+ 
+ 2025-07-03  Eric Botcazou  
+ 
+ 	* gcc-interface/decl.cc (gnat_to_gnu_component_type): Validate the
+ 	Component_Size like the size of a type only if the component type
+ 	is actually packed.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/gcc/ada/Makefile.rtl gcc-13.5.0-RC-20260904/gcc/ada/Makefile.rtl
*** gcc-13.4.0/gcc/ada/Makefile.rtl	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/Makefile.rtl	Fri Sep  4 07:35:07 2026
*************** ifeq ($(strip $(filter-out s390% linux%,
*** 1833,1838 ****
--- 1833,1839 ----
    EXTRA_GNATRTL_TASKING_OBJS=s-linux.o
    EH_MECHANISM=-gcc
    THREADSLIB = -lpthread
+   MISCLIB = -ldl
    GNATLIB_SHARED = gnatlib-shared-dual
    LIBRARY_VERSION := $(LIB_VERSION)
  endif
*************** ifeq ($(strip $(filter-out arm% linux-gn
*** 2231,2236 ****
--- 2232,2238 ----
    EXTRA_GNATRTL_TASKING_OBJS=s-linux.o
    EH_MECHANISM=-arm
    THREADSLIB = -lpthread
+   MISCLIB = -ldl
    GNATLIB_SHARED = gnatlib-shared-dual
    GMEM_LIB = gmemlib
    LIBRARY_VERSION := $(LIB_VERSION)
*************** ifeq ($(strip $(filter-out %x32 linux%,$
*** 2585,2590 ****
--- 2587,2593 ----
    EXTRA_GNATRTL_TASKING_OBJS=s-linux.o a-exetim.o
    EH_MECHANISM=-gcc
    THREADSLIB=-lpthread -lrt
+   MISCLIB = -ldl
    GNATLIB_SHARED=gnatlib-shared-dual
    GMEM_LIB = gmemlib
    LIBRARY_VERSION := $(LIB_VERSION)
diff -Nrcpad gcc-13.4.0/gcc/ada/adaint.c gcc-13.5.0-RC-20260904/gcc/ada/adaint.c
*** gcc-13.4.0/gcc/ada/adaint.c	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/adaint.c	Fri Sep  4 07:35:07 2026
*************** const char *__gnat_library_template = GN
*** 333,343 ****
  
  #else
  
- #if defined (__MINGW32__)
- #include "mingw32.h"
- #else
  #include 
- #endif
  
  #ifdef MAXPATHLEN
  #define GNAT_MAX_PATH_LEN MAXPATHLEN
--- 333,339 ----
diff -Nrcpad gcc-13.4.0/gcc/ada/exp_ch2.adb gcc-13.5.0-RC-20260904/gcc/ada/exp_ch2.adb
*** gcc-13.4.0/gcc/ada/exp_ch2.adb	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/exp_ch2.adb	Fri Sep  4 07:35:07 2026
*************** package body Exp_Ch2 is
*** 704,712 ****
        T : constant Entity_Id := Etype (N);
  
     begin
        Rewrite (N, New_Copy_Tree (Renamed_Object (E)));
  
!       --  We mark the copy as unanalyzed, so that it is sure to be reanalyzed
        --  at the top level. This is needed in the packed case since we
        --  specifically avoided expanding packed array references when the
        --  renaming declaration was analyzed.
--- 704,718 ----
        T : constant Entity_Id := Etype (N);
  
     begin
+       --  Mark the entity as referenced since this reference is going away
+ 
+       Set_Referenced (E);
+ 
+       --  Now rewrite the reference as a copy of the renamed object
+ 
        Rewrite (N, New_Copy_Tree (Renamed_Object (E)));
  
!       --  Mark the copy as unanalyzed to make sure that it is reanalyzed
        --  at the top level. This is needed in the packed case since we
        --  specifically avoided expanding packed array references when the
        --  renaming declaration was analyzed.
diff -Nrcpad gcc-13.4.0/gcc/ada/gcc-interface/decl.cc gcc-13.5.0-RC-20260904/gcc/ada/gcc-interface/decl.cc
*** gcc-13.4.0/gcc/ada/gcc-interface/decl.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/gcc-interface/decl.cc	Fri Sep  4 07:35:07 2026
*************** gnat_to_gnu_component_type (Entity_Id gn
*** 5277,5283 ****
    const bool is_bit_packed = Is_Bit_Packed_Array (gnat_array);
    tree gnu_type = gnat_to_gnu_type (gnat_type);
    tree gnu_comp_size;
!   bool has_packed_components;
    unsigned int max_align;
  
    /* If an alignment is specified, use it as a cap on the component type
--- 5277,5283 ----
    const bool is_bit_packed = Is_Bit_Packed_Array (gnat_array);
    tree gnu_type = gnat_to_gnu_type (gnat_type);
    tree gnu_comp_size;
!   bool has_packed_component;
    unsigned int max_align;
  
    /* If an alignment is specified, use it as a cap on the component type
*************** gnat_to_gnu_component_type (Entity_Id gn
*** 5298,5313 ****
        && !TYPE_FAT_POINTER_P (gnu_type)
        && tree_fits_uhwi_p (TYPE_SIZE (gnu_type)))
      {
!       gnu_type = make_packable_type (gnu_type, false, max_align);
!       has_packed_components = true;
      }
    else
!     has_packed_components = is_bit_packed;
  
    /* Get and validate any specified Component_Size.  */
    gnu_comp_size
      = validate_size (Component_Size (gnat_array), gnu_type, gnat_array,
! 		     has_packed_components ? TYPE_DECL : VAR_DECL, true,
  		     Has_Component_Size_Clause (gnat_array), NULL, NULL);
  
    /* If the component type is a RECORD_TYPE that has a self-referential size,
--- 5298,5319 ----
        && !TYPE_FAT_POINTER_P (gnu_type)
        && tree_fits_uhwi_p (TYPE_SIZE (gnu_type)))
      {
!       tree gnu_packable_type = make_packable_type (gnu_type, false, max_align);
!       if (gnu_packable_type != gnu_type)
! 	{
! 	  gnu_type = gnu_packable_type;
! 	  has_packed_component = true;
! 	}
!       else
! 	has_packed_component = false;
      }
    else
!     has_packed_component = is_bit_packed;
  
    /* Get and validate any specified Component_Size.  */
    gnu_comp_size
      = validate_size (Component_Size (gnat_array), gnu_type, gnat_array,
! 		     has_packed_component ? TYPE_DECL : VAR_DECL, true,
  		     Has_Component_Size_Clause (gnat_array), NULL, NULL);
  
    /* If the component type is a RECORD_TYPE that has a self-referential size,
*************** typedef struct vinfo
*** 7965,7971 ****
  
     DEBUG_INFO is true if we need to write debug information about the type.
  
!    IN_VARIANT is true if the componennt list is that of a variant.
  
     FIRST_FREE_POS, if nonzero, is the first (lowest) free field position in
     the outer record type down to this variant level.  It is nonzero only if
--- 7971,7977 ----
  
     DEBUG_INFO is true if we need to write debug information about the type.
  
!    IN_VARIANT is true if the component list is that of a variant.
  
     FIRST_FREE_POS, if nonzero, is the first (lowest) free field position in
     the outer record type down to this variant level.  It is nonzero only if
*************** components_to_record (Node_Id gnat_compo
*** 8082,8088 ****
        tree gnu_union_type;
        tree this_first_free_pos, gnu_variant_list = NULL_TREE;
        bool union_field_needs_strict_alignment = false;
!       bool innermost_variant_level = true;
        auto_vec  variant_types;
        vinfo_t *gnu_variant;
        unsigned int variants_align = 0;
--- 8088,8094 ----
        tree gnu_union_type;
        tree this_first_free_pos, gnu_variant_list = NULL_TREE;
        bool union_field_needs_strict_alignment = false;
!       bool innermost_of_unchecked_union = false;
        auto_vec  variant_types;
        vinfo_t *gnu_variant;
        unsigned int variants_align = 0;
*************** components_to_record (Node_Id gnat_compo
*** 8131,8145 ****
        /* For an unchecked union with a fixed part, we need to compute whether
  	 we are at the innermost level of the variant part.  */
        if (unchecked_union && gnu_field_list)
! 	for (variant = First_Non_Pragma (Variants (gnat_variant_part));
! 	     Present (variant);
! 	     variant = Next_Non_Pragma (variant))
! 	  if (Present (Component_List (variant))
! 	      && Present (Variant_Part (Component_List (variant))))
! 	    {
! 	      innermost_variant_level = false;
! 	      break;
! 	    }
  
        /* We build the variants in two passes.  The bulk of the work is done in
  	 the first pass, that is to say translating the GNAT nodes, building
--- 8137,8155 ----
        /* For an unchecked union with a fixed part, we need to compute whether
  	 we are at the innermost level of the variant part.  */
        if (unchecked_union && gnu_field_list)
! 	{
! 	  innermost_of_unchecked_union = true;
! 
! 	  for (variant = First_Non_Pragma (Variants (gnat_variant_part));
! 	       Present (variant);
! 	       variant = Next_Non_Pragma (variant))
! 	    if (Present (Component_List (variant))
! 		&& Present (Variant_Part (Component_List (variant))))
! 	      {
! 		innermost_of_unchecked_union = false;
! 		break;
! 	      }
! 	}
  
        /* We build the variants in two passes.  The bulk of the work is done in
  	 the first pass, that is to say translating the GNAT nodes, building
*************** components_to_record (Node_Id gnat_compo
*** 8186,8202 ****
  	     the outer variant, so as to flatten the rep-ed layout as much as
  	     possible, the reason being that we cannot do any flattening when
  	     a subtype statically selects a variant later on, for example for
! 	     an aggregate.  */
  	  has_rep
  	    = components_to_record (Component_List (variant), gnat_record_type,
! 				    NULL_TREE, gnu_variant_type, packed,
  				    definition, !all_rep_and_size, all_rep,
  				    unchecked_union, true, needs_xv_encodings,
  				    true, this_first_free_pos,
  				    (all_rep || this_first_free_pos)
! 				    && !(unchecked_union
! 				         && gnu_field_list
! 					 && innermost_variant_level)
  				    ? NULL : &gnu_rep_list);
  
  	  /* Translate the qualifier and annotate the GNAT node.  */
--- 8196,8212 ----
  	     the outer variant, so as to flatten the rep-ed layout as much as
  	     possible, the reason being that we cannot do any flattening when
  	     a subtype statically selects a variant later on, for example for
! 	     an aggregate; in that case, we force a packed layout because the
! 	     moved fields may overlap with packed bit-fields.  */
  	  has_rep
  	    = components_to_record (Component_List (variant), gnat_record_type,
! 				    NULL_TREE, gnu_variant_type, packed ||
! 				    (all_rep && innermost_of_unchecked_union),
  				    definition, !all_rep_and_size, all_rep,
  				    unchecked_union, true, needs_xv_encodings,
  				    true, this_first_free_pos,
  				    (all_rep || this_first_free_pos)
! 				    && !innermost_of_unchecked_union
  				    ? NULL : &gnu_rep_list);
  
  	  /* Translate the qualifier and annotate the GNAT node.  */
diff -Nrcpad gcc-13.4.0/gcc/ada/libgnat/s-genbig.adb gcc-13.5.0-RC-20260904/gcc/ada/libgnat/s-genbig.adb
*** gcc-13.4.0/gcc/ada/libgnat/s-genbig.adb	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/libgnat/s-genbig.adb	Fri Sep  4 07:35:07 2026
*************** package body System.Generic_Bignums is
*** 258,264 ****
           --  X ** 1 is X
  
           when 1 =>
!             return Normalize (X.D);
  
           --  X ** 2 is X * X
  
--- 258,264 ----
           --  X ** 1 is X
  
           when 1 =>
!             return Normalize (X.D, X.Neg);
  
           --  X ** 2 is X * X
  
*************** package body System.Generic_Bignums is
*** 327,340 ****
        elsif Y.Len > 1 then
           raise Storage_Error with "exponentiation result is too large";
  
!       --  Special case (+/-)2 ** K, where K is 1 .. 31 using a shift
  
        elsif X.Len = 1 and then X.D (1) = 2 and then Y.D (1) < 32 then
           declare
              D : constant Digit_Vector (1 .. 1) :=
                    [Shift_Left (SD'(1), Natural (Y.D (1)))];
           begin
!             return Normalize (D, X.Neg);
           end;
  
        --  Remaining cases have right operand of one word
--- 327,340 ----
        elsif Y.Len > 1 then
           raise Storage_Error with "exponentiation result is too large";
  
!       --  Special case (+/-)2 ** K, where K is in 1 .. 31, using a left shift
  
        elsif X.Len = 1 and then X.D (1) = 2 and then Y.D (1) < 32 then
           declare
              D : constant Digit_Vector (1 .. 1) :=
                    [Shift_Left (SD'(1), Natural (Y.D (1)))];
           begin
!             return Normalize (D, X.Neg and then (Y.D (1) and 1) = 1);
           end;
  
        --  Remaining cases have right operand of one word
diff -Nrcpad gcc-13.4.0/gcc/ada/libgnat/s-stposu.adb gcc-13.5.0-RC-20260904/gcc/ada/libgnat/s-stposu.adb
*** gcc-13.4.0/gcc/ada/libgnat/s-stposu.adb	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/libgnat/s-stposu.adb	Fri Sep  4 07:35:07 2026
*************** package body System.Storage_Pools.Subpoo
*** 523,528 ****
--- 523,529 ----
     procedure Finalize_Pool (Pool : in out Root_Storage_Pool_With_Subpools) is
        Curr_Ptr : SP_Node_Ptr;
        Ex_Occur : Exception_Occurrence;
+       Handle   : Subpool_Handle;
        Raised   : Boolean := False;
  
        function Is_Empty_List (L : not null SP_Node_Ptr) return Boolean;
*************** package body System.Storage_Pools.Subpoo
*** 557,572 ****
        while not Is_Empty_List (Pool.Subpools'Unchecked_Access) loop
           Curr_Ptr := Pool.Subpools.Next;
  
!          --  Perform the following actions:
! 
!          --    1) Finalize all objects chained on the subpool's master
!          --    2) Remove the subpool from the owner's list of subpools
!          --    3) Deallocate the doubly linked list node associated with the
!          --       subpool.
!          --    4) Call Deallocate_Subpool
  
           begin
!             Finalize_And_Deallocate (Curr_Ptr.Subpool);
  
           exception
              when Fin_Occur : others =>
--- 558,570 ----
        while not Is_Empty_List (Pool.Subpools'Unchecked_Access) loop
           Curr_Ptr := Pool.Subpools.Next;
  
!          --  Finalize and deallocate the subpool. Beware that the node pointed
!          --  to by Curr_Ptr will be deallocated so may not be passed as actual
!          --  in the call, since the formal parameter is In Out.
  
           begin
!             Handle := Curr_Ptr.Subpool;
!             Finalize_And_Deallocate (Handle);
  
           exception
              when Fin_Occur : others =>
diff -Nrcpad gcc-13.4.0/gcc/ada/sem_attr.adb gcc-13.5.0-RC-20260904/gcc/ada/sem_attr.adb
*** gcc-13.4.0/gcc/ada/sem_attr.adb	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/sem_attr.adb	Fri Sep  4 07:35:07 2026
*************** package body Sem_Attr is
*** 11336,11341 ****
--- 11336,11342 ----
                 end if;
  
                 Resolve (Prefix (P));
+                Resolve_Implicit_Dereference (Prefix (P));
  
                 if not Is_Overloaded (P) then
                    Generate_Reference (Entity (Selector_Name (P)), P);
diff -Nrcpad gcc-13.4.0/gcc/ada/sem_elab.adb gcc-13.5.0-RC-20260904/gcc/ada/sem_elab.adb
*** gcc-13.4.0/gcc/ada/sem_elab.adb	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/sem_elab.adb	Fri Sep  4 07:35:07 2026
*************** package body Sem_Elab is
*** 9903,9909 ****
                 --  The corresponding subunit was previously loaded
  
                 if Present (Lib_Unit) then
!                   return Lib_Unit;
  
                 --  Otherwise attempt to load the corresponding subunit
  
--- 9903,9909 ----
                 --  The corresponding subunit was previously loaded
  
                 if Present (Lib_Unit) then
!                   return Proper_Body (Unit (Lib_Unit));
  
                 --  Otherwise attempt to load the corresponding subunit
  
diff -Nrcpad gcc-13.4.0/gcc/ada/sem_res.adb gcc-13.5.0-RC-20260904/gcc/ada/sem_res.adb
*** gcc-13.4.0/gcc/ada/sem_res.adb	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/sem_res.adb	Fri Sep  4 07:35:07 2026
*************** package body Sem_Res is
*** 255,266 ****
     --  is the context type, which is used when the operation is a protected
     --  function with no arguments, and the return value is indexed.
  
-    procedure Resolve_Implicit_Dereference (P : Node_Id);
-    --  Called when P is the prefix of an indexed component, or of a selected
-    --  component, or of a slice. If P is of an access type, we unconditionally
-    --  rewrite it as an explicit dereference. This ensures that the expander
-    --  and the code generator have a fully explicit tree to work with.
- 
     procedure Resolve_Intrinsic_Operator (N : Node_Id; Typ : Entity_Id);
     --  A call to a user-defined intrinsic operator is rewritten as a call to
     --  the corresponding predefined operator, with suitable conversions. Note
--- 255,260 ----
diff -Nrcpad gcc-13.4.0/gcc/ada/sem_res.ads gcc-13.5.0-RC-20260904/gcc/ada/sem_res.ads
*** gcc-13.4.0/gcc/ada/sem_res.ads	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/ada/sem_res.ads	Fri Sep  4 07:35:07 2026
*************** package Sem_Res is
*** 125,130 ****
--- 125,136 ----
     --  own type. For now we assume that the prefix cannot be overloaded and
     --  the name of the entry plays no role in the resolution.
  
+    procedure Resolve_Implicit_Dereference (P : Node_Id);
+    --  Called when P is the prefix of an indexed component, or of a selected
+    --  component, or of a slice. If P is of an access type, we unconditionally
+    --  rewrite it as an explicit dereference. This ensures that the expander
+    --  and the code generator have a fully explicit tree to work with.
+ 
     procedure Resolve_Membership_Equality (N : Node_Id; Typ : Entity_Id);
     --  Resolve the equality operator in an individual membership test
  
diff -Nrcpad gcc-13.4.0/gcc/alias.cc gcc-13.5.0-RC-20260904/gcc/alias.cc
*** gcc-13.4.0/gcc/alias.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/alias.cc	Fri Sep  4 07:35:07 2026
*************** get_alias_set (tree t)
*** 949,955 ****
    else
      {
        t = TYPE_CANONICAL (t);
!       gcc_checking_assert (!TYPE_STRUCTURAL_EQUALITY_P (t));
      }
  
    /* If this is a type with a known alias set, return it.  */
--- 949,960 ----
    else
      {
        t = TYPE_CANONICAL (t);
!       gcc_checking_assert (TYPE_CANONICAL (t) == t);
!       if (t != TYPE_MAIN_VARIANT (t))
! 	{
! 	  t = TYPE_MAIN_VARIANT (t);
! 	  gcc_checking_assert (TYPE_CANONICAL (t) == t);
! 	}
      }
  
    /* If this is a type with a known alias set, return it.  */
diff -Nrcpad gcc-13.4.0/gcc/builtins.cc gcc-13.5.0-RC-20260904/gcc/builtins.cc
*** gcc-13.4.0/gcc/builtins.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/builtins.cc	Fri Sep  4 07:35:07 2026
*************** fold_builtin_fabs (location_t loc, tree
*** 8923,8929 ****
  static tree
  fold_builtin_abs (location_t loc, tree arg, tree type)
  {
!   if (!validate_arg (arg, INTEGER_TYPE))
      return NULL_TREE;
  
    arg = fold_convert_loc (loc, type, arg);
--- 8923,8929 ----
  static tree
  fold_builtin_abs (location_t loc, tree arg, tree type)
  {
!   if (!validate_arg (arg, INTEGER_TYPE) || !INTEGRAL_TYPE_P (type))
      return NULL_TREE;
  
    arg = fold_convert_loc (loc, type, arg);
diff -Nrcpad gcc-13.4.0/gcc/c/ChangeLog gcc-13.5.0-RC-20260904/gcc/c/ChangeLog
*** gcc-13.4.0/gcc/c/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/gcc/c/ChangeLog	Fri Sep  4 07:35:07 2026
***************
*** 1,3 ****
--- 1,12 ----
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-18  Jakub Jelinek  
+ 
+ 	PR c/123365
+ 	* c-decl.cc (build_compound_literal): Call relayout_decl
+ 	after completing the type.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/gcc/c/c-decl.cc gcc-13.5.0-RC-20260904/gcc/c/c-decl.cc
*** gcc-13.4.0/gcc/c/c-decl.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/c/c-decl.cc	Fri Sep  4 07:35:07 2026
*************** build_compound_literal (location_t loc,
*** 6288,6293 ****
--- 6288,6294 ----
  
        type = TREE_TYPE (decl);
        TREE_TYPE (DECL_INITIAL (decl)) = type;
+       relayout_decl (decl);
      }
  
    if (type == error_mark_node || !COMPLETE_TYPE_P (type))
diff -Nrcpad gcc-13.4.0/gcc/c-family/ChangeLog gcc-13.5.0-RC-20260904/gcc/c-family/ChangeLog
*** gcc-13.4.0/gcc/c-family/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/gcc/c-family/ChangeLog	Fri Sep  4 07:35:07 2026
***************
*** 1,3 ****
--- 1,43 ----
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-25  Jakub Jelinek  
+ 
+ 	PR middle-end/120052
+ 	* c-ubsan.cc (ubsan_instrument_bounds): For VLAs use
+ 	1 instead of 0 as first IFN_UBSAN_BOUNDS argument and only
+ 	use the addend without TYPE_MAX_VALUE (TYPE_DOMAIN (type))
+ 	in the 3rd argument.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-07-04  Jakub Jelinek  
+ 
+ 	PR c/120837
+ 	* c-common.cc (pointer_int_sum): Rewrite the intop PLUS_EXPR or
+ 	MINUS_EXPR optimization into extension of both intop operands,
+ 	their separate multiplication and then addition/subtraction followed
+ 	by rest of pointer_int_sum handling after the multiplication.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-12-18  Richard Biener  
+ 
+ 	PR c/123156
+ 	* c-common.cc (c_build_shufflevector): Use ssizetype for the
+ 	permute vector element type.
+ 
+ 2026-03-14  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-02-12  Andrew Pinski  
+ 
+ 	PR c/105555
+ 	* c-common.cc (fold_offsetof): Handle REALPART_EXPR
+ 	and IMAGPART_EXPR.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/gcc/c-family/c-common.cc gcc-13.5.0-RC-20260904/gcc/c-family/c-common.cc
*** gcc-13.4.0/gcc/c-family/c-common.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/c-family/c-common.cc	Fri Sep  4 07:35:07 2026
*************** c_build_shufflevector (location_t loc, t
*** 1190,1198 ****
    vec_perm_indices indices (sel, 2, maskl);
  
    tree ret_type = build_vector_type (TREE_TYPE (TREE_TYPE (v0)), maskl);
!   tree mask_type = build_vector_type (build_nonstandard_integer_type
! 		(TREE_INT_CST_LOW (TYPE_SIZE (TREE_TYPE (ret_type))), 1),
! 		maskl);
    /* Pad out arguments to the common vector size.  */
    if (v0n < maskl)
      {
--- 1190,1196 ----
    vec_perm_indices indices (sel, 2, maskl);
  
    tree ret_type = build_vector_type (TREE_TYPE (TREE_TYPE (v0)), maskl);
!   tree mask_type = build_vector_type (ssizetype, maskl);
    /* Pad out arguments to the common vector size.  */
    if (v0n < maskl)
      {
*************** pointer_int_sum (location_t loc, enum tr
*** 3343,3362 ****
  	 an overflow error if the constant is negative but INTOP is not.  */
        && (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (intop))
  	  || (TYPE_PRECISION (TREE_TYPE (intop))
! 	      == TYPE_PRECISION (TREE_TYPE (ptrop)))))
      {
!       enum tree_code subcode = resultcode;
!       tree int_type = TREE_TYPE (intop);
!       if (TREE_CODE (intop) == MINUS_EXPR)
! 	subcode = (subcode == PLUS_EXPR ? MINUS_EXPR : PLUS_EXPR);
!       /* Convert both subexpression types to the type of intop,
! 	 because weird cases involving pointer arithmetic
! 	 can result in a sum or difference with different type args.  */
!       ptrop = build_binary_op (EXPR_LOCATION (TREE_OPERAND (intop, 1)),
! 			       subcode, ptrop,
! 			       convert (int_type, TREE_OPERAND (intop, 1)),
! 			       true);
!       intop = convert (int_type, TREE_OPERAND (intop, 0));
      }
  
    /* Convert the integer argument to a type the same size as sizetype
--- 3341,3381 ----
  	 an overflow error if the constant is negative but INTOP is not.  */
        && (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (intop))
  	  || (TYPE_PRECISION (TREE_TYPE (intop))
! 	      == TYPE_PRECISION (TREE_TYPE (ptrop))))
!       && TYPE_PRECISION (TREE_TYPE (intop)) <= TYPE_PRECISION (sizetype))
      {
!       tree intop0 = TREE_OPERAND (intop, 0);
!       tree intop1 = TREE_OPERAND (intop, 1);
!       if (TYPE_PRECISION (TREE_TYPE (intop)) != TYPE_PRECISION (sizetype)
! 	  || TYPE_UNSIGNED (TREE_TYPE (intop)) != TYPE_UNSIGNED (sizetype))
! 	{
! 	  tree optype = c_common_type_for_size (TYPE_PRECISION (sizetype),
! 						TYPE_UNSIGNED (sizetype));
! 	  intop0 = convert (optype, intop0);
! 	  intop1 = convert (optype, intop1);
! 	}
!       tree t = fold_build2_loc (loc, MULT_EXPR, TREE_TYPE (intop0), intop0,
! 				convert (TREE_TYPE (intop0), size_exp));
!       intop0 = convert (sizetype, t);
!       if (TREE_OVERFLOW_P (intop0) && !TREE_OVERFLOW (t))
! 	intop0 = wide_int_to_tree (TREE_TYPE (intop0), wi::to_wide (intop0));
!       t = fold_build2_loc (loc, MULT_EXPR, TREE_TYPE (intop1), intop1,
! 			   convert (TREE_TYPE (intop1), size_exp));
!       intop1 = convert (sizetype, t);
!       if (TREE_OVERFLOW_P (intop1) && !TREE_OVERFLOW (t))
! 	intop1 = wide_int_to_tree (TREE_TYPE (intop1), wi::to_wide (intop1));
!       intop = build_binary_op (EXPR_LOCATION (intop), TREE_CODE (intop),
! 			       intop0, intop1, true);
! 
!       /* Create the sum or difference.  */
!       if (resultcode == MINUS_EXPR)
! 	intop = fold_build1_loc (loc, NEGATE_EXPR, sizetype, intop);
! 
!       ret = fold_build_pointer_plus_loc (loc, ptrop, intop);
! 
!       fold_undefer_and_ignore_overflow_warnings ();
! 
!       return ret;
      }
  
    /* Convert the integer argument to a type the same size as sizetype
*************** fold_offsetof (tree expr, tree type, enu
*** 6751,6756 ****
--- 6770,6785 ----
      case ERROR_MARK:
        return expr;
  
+     case REALPART_EXPR:
+      return fold_offsetof (TREE_OPERAND (expr, 0), type, code);
+ 
+     case IMAGPART_EXPR:
+      base = fold_offsetof (TREE_OPERAND (expr, 0), type, code);
+      if (base == error_mark_node)
+ 	return base;
+      off = TYPE_SIZE_UNIT (TREE_TYPE (TREE_TYPE (TREE_OPERAND (expr, 0))));
+      break;
+ 
      case VAR_DECL:
        error ("cannot apply % to static data member %qD", expr);
        return error_mark_node;
diff -Nrcpad gcc-13.4.0/gcc/c-family/c-ubsan.cc gcc-13.5.0-RC-20260904/gcc/c-family/c-ubsan.cc
*** gcc-13.4.0/gcc/c-family/c-ubsan.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/c-family/c-ubsan.cc	Fri Sep  4 07:35:07 2026
*************** ubsan_instrument_bounds (location_t loc,
*** 381,387 ****
  
    bound = fold_build2 (PLUS_EXPR, TREE_TYPE (bound), bound,
  		       build_int_cst (TREE_TYPE (bound),
! 		       1 + ignore_off_by_one));
  
    /* Detect flexible array members and suchlike, unless
       -fsanitize=bounds-strict.  */
--- 381,387 ----
  
    bound = fold_build2 (PLUS_EXPR, TREE_TYPE (bound), bound,
  		       build_int_cst (TREE_TYPE (bound),
! 				      1 + ignore_off_by_one));
  
    /* Detect flexible array members and suchlike, unless
       -fsanitize=bounds-strict.  */
*************** ubsan_instrument_bounds (location_t loc,
*** 468,475 ****
      return NULL_TREE;
  
    *index = save_expr (*index);
!   /* Create a "(T *) 0" tree node to describe the array type.  */
!   tree zero_with_type = build_int_cst (build_pointer_type (type), 0);
    return build_call_expr_internal_loc (loc, IFN_UBSAN_BOUNDS,
  				       void_type_node, 3, zero_with_type,
  				       *index, bound);
--- 468,483 ----
      return NULL_TREE;
  
    *index = save_expr (*index);
!   /* If TYPE is a VLA, use 1 instead of 0 as the first argument and
!      use just the addend to TYPE_MAX_VALUE (domain) as the third argument
!      temporarily, so that gimplification can use TYPE_MAX_VALUE (domain)
!      after gimplify_type_sizes.  See PR120052.  */
!   bool is_vla = (TYPE_MAX_VALUE (domain)
! 		 && TREE_CODE (TYPE_MAX_VALUE (domain)) != INTEGER_CST);
!   if (is_vla)
!     bound = build_int_cst (TREE_TYPE (bound), 1 + ignore_off_by_one);
!   /* Create a "(T *) 0" (or 1) tree node to describe the array type.  */
!   tree zero_with_type = build_int_cst (build_pointer_type (type), is_vla);
    return build_call_expr_internal_loc (loc, IFN_UBSAN_BOUNDS,
  				       void_type_node, 3, zero_with_type,
  				       *index, bound);
diff -Nrcpad gcc-13.4.0/gcc/cfgexpand.cc gcc-13.5.0-RC-20260904/gcc/cfgexpand.cc
*** gcc-13.4.0/gcc/cfgexpand.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cfgexpand.cc	Fri Sep  4 07:35:07 2026
*************** expand_used_vars (bitmap forced_stack_va
*** 2381,2386 ****
--- 2381,2389 ----
  	  HOST_WIDE_INT offset, sz, redzonesz;
  	  redzonesz = ASAN_RED_ZONE_SIZE;
  	  sz = data.asan_vec[0] - prev_offset;
+ 	  data.asan_alignb = MAX (data.asan_alignb,
+ 				  crtl->stack_alignment_needed
+ 				  / BITS_PER_UNIT);
  	  if (data.asan_alignb > ASAN_RED_ZONE_SIZE
  	      && data.asan_alignb <= 4096
  	      && sz + ASAN_RED_ZONE_SIZE >= (int) data.asan_alignb)
*************** expand_asm_stmt (gasm *stmt)
*** 3468,3479 ****
       Case in point is when the i386 backend moved from cc0 to a hard reg --
       maintaining source-level compatibility means automatically clobbering
       the flags register.  */
-   rtx_insn *after_md_seq = NULL;
    if (targetm.md_asm_adjust)
!     after_md_seq
  	= targetm.md_asm_adjust (output_rvec, input_rvec, input_mode,
  				 constraints, clobber_rvec, clobbered_regs,
  				 locus);
  
    /* Do not allow the hook to change the output and input count,
       lest it mess up the operand numbering.  */
--- 3471,3491 ----
       Case in point is when the i386 backend moved from cc0 to a hard reg --
       maintaining source-level compatibility means automatically clobbering
       the flags register.  */
    if (targetm.md_asm_adjust)
!     {
!       rtx_insn *after_md_seq
  	= targetm.md_asm_adjust (output_rvec, input_rvec, input_mode,
  				 constraints, clobber_rvec, clobbered_regs,
  				 locus);
+       if (after_md_seq)
+ 	{
+ 	  push_to_sequence (after_md_seq);
+ 	  emit_insn (after_rtl_seq);
+ 	  after_rtl_seq = get_insns ();
+ 	  after_rtl_end = get_last_insn ();
+ 	  end_sequence ();
+ 	}
+     }
  
    /* Do not allow the hook to change the output and input count,
       lest it mess up the operand numbering.  */
*************** expand_asm_stmt (gasm *stmt)
*** 3641,3648 ****
    if (fallthru_label)
      emit_label (fallthru_label);
  
-   if (after_md_seq)
-     emit_insn (after_md_seq);
    if (after_rtl_seq)
      {
        if (nlabels == 0)
--- 3653,3658 ----
diff -Nrcpad gcc-13.4.0/gcc/cfgrtl.cc gcc-13.5.0-RC-20260904/gcc/cfgrtl.cc
*** gcc-13.4.0/gcc/cfgrtl.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cfgrtl.cc	Fri Sep  4 07:35:07 2026
*************** force_nonfallthru_and_redirect (edge e,
*** 1596,1649 ****
      }
  
    /* If e->src ends with asm goto, see if any of the ASM_OPERANDS_LABELs
!      don't point to the target or fallthru label.  */
    if (JUMP_P (BB_END (e->src))
        && target != EXIT_BLOCK_PTR_FOR_FN (cfun)
        && (e->flags & EDGE_FALLTHRU)
        && (note = extract_asm_operands (PATTERN (BB_END (e->src)))))
      {
!       int i, n = ASM_OPERANDS_LABEL_LENGTH (note);
!       bool adjust_jump_target = false;
  
!       for (i = 0; i < n; ++i)
! 	{
! 	  if (XEXP (ASM_OPERANDS_LABEL (note, i), 0) == BB_HEAD (e->dest))
! 	    {
! 	      LABEL_NUSES (XEXP (ASM_OPERANDS_LABEL (note, i), 0))--;
! 	      XEXP (ASM_OPERANDS_LABEL (note, i), 0) = block_label (target);
! 	      LABEL_NUSES (XEXP (ASM_OPERANDS_LABEL (note, i), 0))++;
! 	      adjust_jump_target = true;
! 	    }
! 	  if (XEXP (ASM_OPERANDS_LABEL (note, i), 0) == BB_HEAD (target))
  	    asm_goto_edge = true;
! 	}
!       if (adjust_jump_target)
! 	{
! 	  rtx_insn *insn = BB_END (e->src);
! 	  rtx note;
! 	  rtx_insn *old_label = BB_HEAD (e->dest);
! 	  rtx_insn *new_label = BB_HEAD (target);
! 
! 	  if (JUMP_LABEL (insn) == old_label)
! 	    {
! 	      JUMP_LABEL (insn) = new_label;
! 	      note = find_reg_note (insn, REG_LABEL_TARGET, new_label);
! 	      if (note)
! 		remove_note (insn, note);
! 	    }
! 	  else
! 	    {
! 	      note = find_reg_note (insn, REG_LABEL_TARGET, old_label);
! 	      if (note)
! 		remove_note (insn, note);
! 	      if (JUMP_LABEL (insn) != new_label
! 		  && !find_reg_note (insn, REG_LABEL_TARGET, new_label))
! 		add_reg_note (insn, REG_LABEL_TARGET, new_label);
! 	    }
! 	  while ((note = find_reg_note (insn, REG_LABEL_OPERAND, old_label))
! 		 != NULL_RTX)
! 	    XEXP (note, 0) = new_label;
! 	}
      }
  
    if (EDGE_COUNT (e->src->succs) >= 2 || abnormal_edge_flags || asm_goto_edge)
--- 1596,1615 ----
      }
  
    /* If e->src ends with asm goto, see if any of the ASM_OPERANDS_LABELs
!      don't point to the fallthru label.  */
    if (JUMP_P (BB_END (e->src))
        && target != EXIT_BLOCK_PTR_FOR_FN (cfun)
        && (e->flags & EDGE_FALLTHRU)
        && (note = extract_asm_operands (PATTERN (BB_END (e->src)))))
      {
!       int n = ASM_OPERANDS_LABEL_LENGTH (note);
  
!       for (int i = 0; i < n; ++i)
! 	if (XEXP (ASM_OPERANDS_LABEL (note, i), 0) == BB_HEAD (e->dest))
! 	  {
  	    asm_goto_edge = true;
! 	    break;
! 	  }
      }
  
    if (EDGE_COUNT (e->src->succs) >= 2 || abnormal_edge_flags || asm_goto_edge)
*************** force_nonfallthru_and_redirect (edge e,
*** 1682,1696 ****
           and the reg crossing note should be removed.  */
        fixup_partition_crossing (new_edge);
  
!       /* If asm goto has any label refs to target's label,
! 	 add also edge from asm goto bb to target.  */
        if (asm_goto_edge)
  	{
! 	  new_edge->probability /= 2;
! 	  jump_block->count /= 2;
! 	  edge new_edge2 = make_edge (new_edge->src, target,
! 				      e->flags & ~EDGE_FALLTHRU);
! 	  new_edge2->probability = probability - new_edge->probability;
  	}
  
        new_bb = jump_block;
--- 1648,1692 ----
           and the reg crossing note should be removed.  */
        fixup_partition_crossing (new_edge);
  
!       /* If asm goto has any label refs to e->dest, change them to point
! 	 to jump_block instead.  */
        if (asm_goto_edge)
  	{
! 	  int n = ASM_OPERANDS_LABEL_LENGTH (note);
! 
! 	  for (int i = 0; i < n; ++i)
! 	    if (XEXP (ASM_OPERANDS_LABEL (note, i), 0) == BB_HEAD (e->dest))
! 	      {
! 		LABEL_NUSES (XEXP (ASM_OPERANDS_LABEL (note, i), 0))--;
! 		XEXP (ASM_OPERANDS_LABEL (note, i), 0)
! 		  = block_label (jump_block);
! 		LABEL_NUSES (XEXP (ASM_OPERANDS_LABEL (note, i), 0))++;
! 	      }
! 
! 	  rtx_insn *insn = BB_END (new_edge->src);
! 	  rtx note;
! 	  rtx_insn *old_label = BB_HEAD (e->dest);
! 	  rtx_insn *new_label = BB_HEAD (jump_block);
! 
! 	  if (JUMP_LABEL (insn) == old_label)
! 	    {
! 	      JUMP_LABEL (insn) = new_label;
! 	      note = find_reg_note (insn, REG_LABEL_TARGET, new_label);
! 	      if (note)
! 		remove_note (insn, note);
! 	    }
! 	  else
! 	    {
! 	      note = find_reg_note (insn, REG_LABEL_TARGET, old_label);
! 	      if (note)
! 		remove_note (insn, note);
! 	      if (JUMP_LABEL (insn) != new_label
! 		  && !find_reg_note (insn, REG_LABEL_TARGET, new_label))
! 		add_reg_note (insn, REG_LABEL_TARGET, new_label);
! 	    }
! 	  while ((note = find_reg_note (insn, REG_LABEL_OPERAND, old_label))
! 		 != NULL_RTX)
! 	    XEXP (note, 0) = new_label;
  	}
  
        new_bb = jump_block;
diff -Nrcpad gcc-13.4.0/gcc/combine.cc gcc-13.5.0-RC-20260904/gcc/combine.cc
*** gcc-13.4.0/gcc/combine.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/combine.cc	Fri Sep  4 07:35:07 2026
*************** try_combine (rtx_insn *i3, rtx_insn *i2,
*** 3999,4005 ****
  	  && !(GET_CODE (SET_DEST (set1)) == SUBREG
  	       && find_reg_note (i2, REG_DEAD,
  				 SUBREG_REG (SET_DEST (set1))))
! 	  && SET_DEST (set1) != pc_rtx
  	  && !reg_used_between_p (SET_DEST (set1), i2, i3)
  	  /* If I3 is a jump, ensure that set0 is a jump so that
  	     we do not create invalid RTL.  */
--- 3999,4005 ----
  	  && !(GET_CODE (SET_DEST (set1)) == SUBREG
  	       && find_reg_note (i2, REG_DEAD,
  				 SUBREG_REG (SET_DEST (set1))))
! 	  && !modified_between_p (SET_DEST (set1), i2, i3)
  	  && !reg_used_between_p (SET_DEST (set1), i2, i3)
  	  /* If I3 is a jump, ensure that set0 is a jump so that
  	     we do not create invalid RTL.  */
*************** try_combine (rtx_insn *i3, rtx_insn *i2,
*** 4015,4021 ****
  	       && !(GET_CODE (SET_DEST (set0)) == SUBREG
  		    && find_reg_note (i2, REG_DEAD,
  				      SUBREG_REG (SET_DEST (set0))))
! 	       && SET_DEST (set0) != pc_rtx
  	       && !reg_used_between_p (SET_DEST (set0), i2, i3)
  	       /* If I3 is a jump, ensure that set1 is a jump so that
  		  we do not create invalid RTL.  */
--- 4015,4021 ----
  	       && !(GET_CODE (SET_DEST (set0)) == SUBREG
  		    && find_reg_note (i2, REG_DEAD,
  				      SUBREG_REG (SET_DEST (set0))))
! 	       && !modified_between_p (SET_DEST (set0), i2, i3)
  	       && !reg_used_between_p (SET_DEST (set0), i2, i3)
  	       /* If I3 is a jump, ensure that set1 is a jump so that
  		  we do not create invalid RTL.  */
*************** recog_for_combine (rtx *pnewpat, rtx_ins
*** 11647,11653 ****
        rtx src = SET_SRC (pat);
        if (CONSTANT_P (src)
  	  && !CONST_INT_P (src)
! 	  && crtl->uses_const_pool)
  	{
  	  machine_mode mode = GET_MODE (src);
  	  if (mode == VOIDmode)
--- 11647,11654 ----
        rtx src = SET_SRC (pat);
        if (CONSTANT_P (src)
  	  && !CONST_INT_P (src)
! 	  && crtl->uses_const_pool
! 	  && SET_DEST (pat) != pc_rtx)
  	{
  	  machine_mode mode = GET_MODE (src);
  	  if (mode == VOIDmode)
diff -Nrcpad gcc-13.4.0/gcc/common/config/avr/avr-common.cc gcc-13.5.0-RC-20260904/gcc/common/config/avr/avr-common.cc
*** gcc-13.4.0/gcc/common/config/avr/avr-common.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/common/config/avr/avr-common.cc	Fri Sep  4 07:35:07 2026
***************
*** 29,34 ****
--- 29,41 ----
  /* Implement TARGET_OPTION_OPTIMIZATION_TABLE.  */
  static const struct default_options avr_option_optimization_table[] =
    {
+     // The lookup table from tree-swicth-conversion.cc lives in .rodata
+     // and hence consumes RAM on almost all devices.  As PR49857 has
+     // been rejected several times for non-technical reasons, just
+     // disable -ftree-switch-conversion by default.  But even with PR49857
+     // in place there remains PR81540, which cannot be filtered out since
+     // the pass has no way to hook in.
+     { OPT_LEVELS_ALL, OPT_ftree_switch_conversion, NULL, 0 },
      // The only effect of -fcaller-saves might be that it triggers
      // a frame without need when it tries to be smart around calls.
      { OPT_LEVELS_ALL, OPT_fcaller_saves, NULL, 0 },
diff -Nrcpad gcc-13.4.0/gcc/config/aarch64/aarch64-sve-builtins-base.cc gcc-13.5.0-RC-20260904/gcc/config/aarch64/aarch64-sve-builtins-base.cc
*** gcc-13.4.0/gcc/config/aarch64/aarch64-sve-builtins-base.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/aarch64/aarch64-sve-builtins-base.cc	Fri Sep  4 07:35:07 2026
*************** public:
*** 2032,2038 ****
    rtx
    expand (function_expander &e) const override
    {
!     return e.use_exact_insn (code_for_aarch64_sve_rev (e.vector_mode (0)));
    }
  };
  
--- 2032,2041 ----
    rtx
    expand (function_expander &e) const override
    {
!     auto mode = e.vector_mode (0);
!     return e.use_exact_insn (e.type_suffix (0).bool_p
! 			     ? code_for_aarch64_sve_rev_acle (mode)
! 			     : code_for_aarch64_sve_rev (mode));
    }
  };
  
*************** public:
*** 2082,2093 ****
         The fold routines expect the replacement statement to have the
         same lhs as the original call, so return the copy statement
         rather than the field update.  */
!     gassign *copy = gimple_build_assign (unshare_expr (f.lhs), rhs_tuple);
  
      /* Get a reference to the individual vector.  */
      tree field = tuple_type_field (TREE_TYPE (f.lhs));
      tree lhs_array = build3 (COMPONENT_REF, TREE_TYPE (field),
! 			     f.lhs, field, NULL_TREE);
      tree lhs_vector = build4 (ARRAY_REF, TREE_TYPE (rhs_vector),
  			      lhs_array, index, NULL_TREE, NULL_TREE);
      gassign *update = gimple_build_assign (lhs_vector, rhs_vector);
--- 2085,2096 ----
         The fold routines expect the replacement statement to have the
         same lhs as the original call, so return the copy statement
         rather than the field update.  */
!     gassign *copy = gimple_build_assign (f.lhs, rhs_tuple);
  
      /* Get a reference to the individual vector.  */
      tree field = tuple_type_field (TREE_TYPE (f.lhs));
      tree lhs_array = build3 (COMPONENT_REF, TREE_TYPE (field),
! 			     unshare_expr (f.lhs), field, NULL_TREE);
      tree lhs_vector = build4 (ARRAY_REF, TREE_TYPE (rhs_vector),
  			      lhs_array, index, NULL_TREE, NULL_TREE);
      gassign *update = gimple_build_assign (lhs_vector, rhs_vector);
diff -Nrcpad gcc-13.4.0/gcc/config/aarch64/aarch64-sve-builtins-functions.h gcc-13.5.0-RC-20260904/gcc/config/aarch64/aarch64-sve-builtins-functions.h
*** gcc-13.4.0/gcc/config/aarch64/aarch64-sve-builtins-functions.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/aarch64/aarch64-sve-builtins-functions.h	Fri Sep  4 07:35:07 2026
*************** public:
*** 481,487 ****
    rtx
    expand (function_expander &e) const override
    {
!     insn_code icode = code_for_aarch64_sve (m_unspec, e.vector_mode (0));
      return e.use_exact_insn (icode);
    }
  
--- 481,490 ----
    rtx
    expand (function_expander &e) const override
    {
!     auto mode = e.vector_mode (0);
!     insn_code icode = (e.type_suffix (0).bool_p
! 		       ? code_for_aarch64_sve_acle (m_unspec, mode)
! 		       : code_for_aarch64_sve (m_unspec, mode));
      return e.use_exact_insn (icode);
    }
  
diff -Nrcpad gcc-13.4.0/gcc/config/aarch64/aarch64-sve.md gcc-13.5.0-RC-20260904/gcc/config/aarch64/aarch64-sve.md
*** gcc-13.4.0/gcc/config/aarch64/aarch64-sve.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/aarch64/aarch64-sve.md	Fri Sep  4 07:35:07 2026
***************
*** 1421,1427 ****
    [(set (match_operand:SVE_4 0 "register_operand" "=w, w, w, w, w, w")
  	(unspec:SVE_4
  	  [(match_operand:VNx4BI 5 "register_operand" "Upl, Upl, Upl, Upl, Upl, Upl")
! 	   (match_operand:DI 1 "aarch64_sve_gather_offset_" "Z, vgw, rk, rk, rk, rk")
  	   (match_operand:VNx4SI 2 "register_operand" "w, w, w, w, w, w")
  	   (match_operand:DI 3 "const_int_operand" "Ui1, Ui1, Z, Ui1, Z, Ui1")
  	   (match_operand:DI 4 "aarch64_gather_scale_operand_" "Ui1, Ui1, Ui1, Ui1, i, i")
--- 1421,1427 ----
    [(set (match_operand:SVE_4 0 "register_operand" "=w, w, w, w, w, w")
  	(unspec:SVE_4
  	  [(match_operand:VNx4BI 5 "register_operand" "Upl, Upl, Upl, Upl, Upl, Upl")
! 	   (match_operand:DI 1 "aarch64_sve_gather_offset_" "Z, vg, rk, rk, rk, rk")
  	   (match_operand:VNx4SI 2 "register_operand" "w, w, w, w, w, w")
  	   (match_operand:DI 3 "const_int_operand" "Ui1, Ui1, Z, Ui1, Z, Ui1")
  	   (match_operand:DI 4 "aarch64_gather_scale_operand_" "Ui1, Ui1, Ui1, Ui1, i, i")
***************
*** 1443,1449 ****
    [(set (match_operand:SVE_2 0 "register_operand" "=w, w, w, w")
  	(unspec:SVE_2
  	  [(match_operand:VNx2BI 5 "register_operand" "Upl, Upl, Upl, Upl")
! 	   (match_operand:DI 1 "aarch64_sve_gather_offset_" "Z, vgd, rk, rk")
  	   (match_operand:VNx2DI 2 "register_operand" "w, w, w, w")
  	   (match_operand:DI 3 "const_int_operand")
  	   (match_operand:DI 4 "aarch64_gather_scale_operand_" "Ui1, Ui1, Ui1, i")
--- 1443,1449 ----
    [(set (match_operand:SVE_2 0 "register_operand" "=w, w, w, w")
  	(unspec:SVE_2
  	  [(match_operand:VNx2BI 5 "register_operand" "Upl, Upl, Upl, Upl")
! 	   (match_operand:DI 1 "aarch64_sve_gather_offset_" "Z, vg, rk, rk")
  	   (match_operand:VNx2DI 2 "register_operand" "w, w, w, w")
  	   (match_operand:DI 3 "const_int_operand")
  	   (match_operand:DI 4 "aarch64_gather_scale_operand_" "Ui1, Ui1, Ui1, i")
***************
*** 2254,2260 ****
    [(set (mem:BLK (scratch))
  	(unspec:BLK
  	  [(match_operand:VNx4BI 5 "register_operand" "Upl, Upl, Upl, Upl, Upl, Upl")
! 	   (match_operand:DI 0 "aarch64_sve_gather_offset_" "Z, vgw, rk, rk, rk, rk")
  	   (match_operand:VNx4SI 1 "register_operand" "w, w, w, w, w, w")
  	   (match_operand:DI 2 "const_int_operand" "Ui1, Ui1, Z, Ui1, Z, Ui1")
  	   (match_operand:DI 3 "aarch64_gather_scale_operand_" "Ui1, Ui1, Ui1, Ui1, i, i")
--- 2254,2260 ----
    [(set (mem:BLK (scratch))
  	(unspec:BLK
  	  [(match_operand:VNx4BI 5 "register_operand" "Upl, Upl, Upl, Upl, Upl, Upl")
! 	   (match_operand:DI 0 "aarch64_sve_gather_offset_" "Z, vg, rk, rk, rk, rk")
  	   (match_operand:VNx4SI 1 "register_operand" "w, w, w, w, w, w")
  	   (match_operand:DI 2 "const_int_operand" "Ui1, Ui1, Z, Ui1, Z, Ui1")
  	   (match_operand:DI 3 "aarch64_gather_scale_operand_" "Ui1, Ui1, Ui1, Ui1, i, i")
***************
*** 2276,2282 ****
    [(set (mem:BLK (scratch))
  	(unspec:BLK
  	  [(match_operand:VNx2BI 5 "register_operand" "Upl, Upl, Upl, Upl")
! 	   (match_operand:DI 0 "aarch64_sve_gather_offset_" "Z, vgd, rk, rk")
  	   (match_operand:VNx2DI 1 "register_operand" "w, w, w, w")
  	   (match_operand:DI 2 "const_int_operand")
  	   (match_operand:DI 3 "aarch64_gather_scale_operand_" "Ui1, Ui1, Ui1, i")
--- 2276,2282 ----
    [(set (mem:BLK (scratch))
  	(unspec:BLK
  	  [(match_operand:VNx2BI 5 "register_operand" "Upl, Upl, Upl, Upl")
! 	   (match_operand:DI 0 "aarch64_sve_gather_offset_" "Z, vg, rk, rk")
  	   (match_operand:VNx2DI 1 "register_operand" "w, w, w, w")
  	   (match_operand:DI 2 "const_int_operand")
  	   (match_operand:DI 3 "aarch64_gather_scale_operand_" "Ui1, Ui1, Ui1, i")
***************
*** 8834,8840 ****
  	(unspec:PRED_ALL [(match_operand:PRED_ALL 1 "register_operand" "Upa")]
  			 UNSPEC_REV))]
    "TARGET_SVE"
!   "rev\t%0., %1.")
  
  ;; -------------------------------------------------------------------------
  ;; ---- [PRED] Special-purpose binary permutes
--- 8834,8863 ----
  	(unspec:PRED_ALL [(match_operand:PRED_ALL 1 "register_operand" "Upa")]
  			 UNSPEC_REV))]
    "TARGET_SVE"
!   "rev\t%0., %1."
! )
! 
! (define_expand "@aarch64_sve_rev_acle"
!   [(set (match_operand:VNx16BI 0 "register_operand")
! 	(unspec:VNx16BI
! 	  [(match_operand:VNx16BI 1 "register_operand")
! 	   (match_dup:PRED_ALL 2)]
! 	  UNSPEC_REV_PRED))]
!   "TARGET_SVE"
!   {
!     operands[2] = CONST0_RTX (mode);
!   }
! )
! 
! (define_insn "*aarch64_sve_rev_acle"
!   [(set (match_operand:VNx16BI 0 "register_operand" "=Upa")
! 	(unspec:VNx16BI
! 	  [(match_operand:VNx16BI 1 "register_operand" "Upa")
! 	   (match_operand:PRED_ALL 2 "aarch64_simd_imm_zero")]
! 	  UNSPEC_REV_PRED))]
!   "TARGET_SVE"
!   "rev\t%0., %1."
! )
  
  ;; -------------------------------------------------------------------------
  ;; ---- [PRED] Special-purpose binary permutes
***************
*** 8859,8876 ****
    "\t%0., %1., %2."
  )
  
! ;; Special purpose permute used by the predicate generation instructions.
! ;; Unlike the normal permute patterns, these instructions operate on VNx16BI
! ;; regardless of the element size, so that all input and output bits are
! ;; well-defined.  Operand 3 then indicates the size of the permute.
! (define_insn "@aarch64_sve_trn1_conv"
    [(set (match_operand:VNx16BI 0 "register_operand" "=Upa")
  	(unspec:VNx16BI [(match_operand:VNx16BI 1 "register_operand" "Upa")
  			 (match_operand:VNx16BI 2 "register_operand" "Upa")
! 			 (match_operand:PRED_ALL 3 "aarch64_simd_imm_zero")]
! 			UNSPEC_TRN1_CONV))]
    "TARGET_SVE"
!   "trn1\t%0., %1., %2."
  )
  
  ;; =========================================================================
--- 8882,8920 ----
    "\t%0., %1., %2."
  )
  
! ;; Special-purpose permutes used by the ACLE intrinsics and predicate
! ;; generation instructions.  Unlike the normal permute patterns, these
! ;; instructions operate on VNx16BI regardless of the element size, so that
! ;; all input and output bits are well-defined.  Operand 3 then indicates
! ;; the size of the permute.
! ;;
! ;; To make generation easier, this pattern embeds the permute type as the
! ;; fourth operand to the unspec.  On the one hand, this avoids overloading
! ;; unspecs like UNSPEC_ZIP1 to represent two different operations.  On the
! ;; other hand, it avoids having a separate unspec for each variant, and
! ;; having to map from one kind of unspec to the other.
! (define_expand "@aarch64_sve__acle"
!   [(set (match_operand:VNx16BI 0 "register_operand")
! 	(unspec:VNx16BI [(match_operand:VNx16BI 1 "register_operand")
! 			 (match_operand:VNx16BI 2 "register_operand")
! 			 (match_dup:PRED_ALL 3)
! 			 (const_int PERMUTE)]
! 			UNSPEC_PERMUTE_PRED))]
!   "TARGET_SVE"
!   {
!     operands[3] = CONST0_RTX (mode);
!   }
! )
! 
! (define_insn "*aarch64_sve__acle"
    [(set (match_operand:VNx16BI 0 "register_operand" "=Upa")
  	(unspec:VNx16BI [(match_operand:VNx16BI 1 "register_operand" "Upa")
  			 (match_operand:VNx16BI 2 "register_operand" "Upa")
! 			 (match_operand:PRED_ALL 3 "aarch64_simd_imm_zero")
! 			 (const_int PERMUTE)]
! 			UNSPEC_PERMUTE_PRED))]
    "TARGET_SVE"
!   "\t%0., %1., %2."
  )
  
  ;; =========================================================================
diff -Nrcpad gcc-13.4.0/gcc/config/aarch64/aarch64.cc gcc-13.5.0-RC-20260904/gcc/config/aarch64/aarch64.cc
*** gcc-13.4.0/gcc/config/aarch64/aarch64.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/aarch64/aarch64.cc	Fri Sep  4 07:35:07 2026
*************** aarch64_sve_move_pred_via_while (rtx tar
*** 6518,6524 ****
    target = aarch64_target_reg (target, mode);
    emit_insn (gen_while (UNSPEC_WHILELO, DImode, mode,
  			target, const0_rtx, limit));
!   return target;
  }
  
  static rtx
--- 6518,6524 ----
    target = aarch64_target_reg (target, mode);
    emit_insn (gen_while (UNSPEC_WHILELO, DImode, mode,
  			target, const0_rtx, limit));
!   return gen_lowpart (VNx16BImode, target);
  }
  
  static rtx
*************** aarch64_expand_sve_const_pred_trn (rtx t
*** 6663,6670 ****
       operands but permutes them as though they had mode MODE.  */
    machine_mode mode = aarch64_sve_pred_mode (permute_size).require ();
    target = aarch64_target_reg (target, GET_MODE (a));
!   rtx type_reg = CONST0_RTX (mode);
!   emit_insn (gen_aarch64_sve_trn1_conv (mode, target, a, b, type_reg));
    return target;
  }
  
--- 6663,6669 ----
       operands but permutes them as though they had mode MODE.  */
    machine_mode mode = aarch64_sve_pred_mode (permute_size).require ();
    target = aarch64_target_reg (target, GET_MODE (a));
!   emit_insn (gen_aarch64_sve_acle (UNSPEC_TRN1, mode, target, a, b));
    return target;
  }
  
diff -Nrcpad gcc-13.4.0/gcc/config/aarch64/aarch64.md gcc-13.5.0-RC-20260904/gcc/config/aarch64/aarch64.md
*** gcc-13.4.0/gcc/config/aarch64/aarch64.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/aarch64/aarch64.md	Fri Sep  4 07:35:07 2026
***************
*** 203,208 ****
--- 203,209 ----
      UNSPEC_PACIBSP
      UNSPEC_PRLG_STK
      UNSPEC_REV
+     UNSPEC_REV_PRED
      UNSPEC_RBIT
      UNSPEC_SABAL
      UNSPEC_SABAL2
diff -Nrcpad gcc-13.4.0/gcc/config/aarch64/driver-aarch64.cc gcc-13.5.0-RC-20260904/gcc/config/aarch64/driver-aarch64.cc
*** gcc-13.4.0/gcc/config/aarch64/driver-aarch64.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/aarch64/driver-aarch64.cc	Fri Sep  4 07:35:07 2026
*************** struct aarch64_arch_driver_info
*** 80,88 ****
    aarch64_feature_flags flags;
  };
  
- /* Skip the leading "V" in the architecture name.  */
  #define AARCH64_ARCH(NAME, CORE, ARCH_IDENT, ARCH_REV, FLAGS) \
!   { #ARCH_IDENT + 1, NAME, feature_deps::ARCH_IDENT ().enable },
  
  static CONSTEXPR const aarch64_arch_driver_info aarch64_arches[] =
  {
--- 80,87 ----
    aarch64_feature_flags flags;
  };
  
  #define AARCH64_ARCH(NAME, CORE, ARCH_IDENT, ARCH_REV, FLAGS) \
!   { #ARCH_IDENT, NAME, feature_deps::ARCH_IDENT ().enable },
  
  static CONSTEXPR const aarch64_arch_driver_info aarch64_arches[] =
  {
diff -Nrcpad gcc-13.4.0/gcc/config/aarch64/iterators.md gcc-13.5.0-RC-20260904/gcc/config/aarch64/iterators.md
*** gcc-13.4.0/gcc/config/aarch64/iterators.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/aarch64/iterators.md	Fri Sep  4 07:35:07 2026
***************
*** 771,777 ****
      UNSPEC_UZP2Q	; Used in aarch64-sve.md.
      UNSPEC_ZIP1Q	; Used in aarch64-sve.md.
      UNSPEC_ZIP2Q	; Used in aarch64-sve.md.
-     UNSPEC_TRN1_CONV	; Used in aarch64-sve.md.
      UNSPEC_COND_CMPEQ_WIDE ; Used in aarch64-sve.md.
      UNSPEC_COND_CMPGE_WIDE ; Used in aarch64-sve.md.
      UNSPEC_COND_CMPGT_WIDE ; Used in aarch64-sve.md.
--- 771,776 ----
***************
*** 979,984 ****
--- 978,986 ----
      UNSPEC_BFCVTN2     ; Used in aarch64-simd.md.
      UNSPEC_BFCVT       ; Used in aarch64-simd.md.
      UNSPEC_FCVTXN	; Used in aarch64-simd.md.
+ 
+     ;; All used in aarch64-sve.md
+     UNSPEC_PERMUTE_PRED
  ])
  
  ;; ------------------------------------------------------------------
diff -Nrcpad gcc-13.4.0/gcc/config/arm/arm.cc gcc-13.5.0-RC-20260904/gcc/config/arm/arm.cc
*** gcc-13.4.0/gcc/config/arm/arm.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/arm/arm.cc	Fri Sep  4 07:35:07 2026
*************** arm_print_condition (FILE *stream)
*** 24078,24084 ****
  
  
  /* Globally reserved letters: acln
!    Puncutation letters currently used: @_|?().!#
     Lower case letters currently used: bcdefhimpqtvwxyz
     Upper case letters currently used: ABCDEFGHIJKLMNOPQRSTUV
     Letters previously used, but now deprecated/obsolete: sWXYZ.
--- 24078,24084 ----
  
  
  /* Globally reserved letters: acln
!    Puncutation letters currently used: @_-|?().!#
     Lower case letters currently used: bcdefhimpqtvwxyz
     Upper case letters currently used: ABCDEFGHIJKLMNOPQRSTUV
     Letters previously used, but now deprecated/obsolete: sWXYZ.
*************** arm_print_operand (FILE *stream, rtx x,
*** 24113,24118 ****
--- 24113,24123 ----
      case '_':
        fputs (user_label_prefix, stream);
        return;
+     case '-':
+ #ifdef LOCAL_LABEL_PREFIX
+       fputs (LOCAL_LABEL_PREFIX, stream);
+ #endif
+       return;
  
      case '|':
        fputs (REGISTER_PREFIX, stream);
*************** arm_print_operand_punct_valid_p (unsigne
*** 24963,24971 ****
  {
    return (code == '@' || code == '|' || code == '.'
  	  || code == '(' || code == ')' || code == '#'
  	  || (TARGET_32BIT && (code == '?'))
! 	  || (TARGET_THUMB2 && (code == '!'))
! 	  || (TARGET_THUMB && (code == '_')));
  }
  
  /* Target hook for assembling integer objects.  The ARM version needs to
--- 24968,24976 ----
  {
    return (code == '@' || code == '|' || code == '.'
  	  || code == '(' || code == ')' || code == '#'
+ 	  || code == '-' || code == '_'
  	  || (TARGET_32BIT && (code == '?'))
! 	  || (TARGET_THUMB2 && (code == '!')));
  }
  
  /* Target hook for assembling integer objects.  The ARM version needs to
diff -Nrcpad gcc-13.4.0/gcc/config/arm/arm.md gcc-13.5.0-RC-20260904/gcc/config/arm/arm.md
*** gcc-13.4.0/gcc/config/arm/arm.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/arm/arm.md	Fri Sep  4 07:35:07 2026
***************
*** 998,1004 ****
     (set_attr "type" "alus_sreg")]
  )
  
! (define_insn "subvsi3_intmin"
    [(set (reg:CC_V CC_REGNUM)
  	(compare:CC_V
  	  (plus:DI
--- 998,1004 ----
     (set_attr "type" "alus_sreg")]
  )
  
! (define_insn "sub_cmpVsi3_intmin"
    [(set (reg:CC_V CC_REGNUM)
  	(compare:CC_V
  	  (plus:DI
***************
*** 1418,1432 ****
        operands[2] = GEN_INT (-INTVAL (operands[2]));
        /* Special case for INT_MIN.  */
        if (INTVAL (operands[2]) == 0x80000000)
! 	emit_insn (gen_subvsi3_intmin (operands[0], operands[1]));
        else
  	emit_insn (gen_addsi3_compareV_imm (operands[0], operands[1],
! 					  operands[2]));
      }
    else if (CONST_INT_P (operands[1]))
!     emit_insn (gen_subvsi3_imm1 (operands[0], operands[1], operands[2]));
    else
!     emit_insn (gen_subvsi3 (operands[0], operands[1], operands[2]));
  
    arm_gen_unlikely_cbranch (NE, CC_Vmode, operands[3]);
    DONE;
--- 1418,1432 ----
        operands[2] = GEN_INT (-INTVAL (operands[2]));
        /* Special case for INT_MIN.  */
        if (INTVAL (operands[2]) == 0x80000000)
! 	emit_insn (gen_sub_cmpVsi3_intmin (operands[0], operands[1]));
        else
  	emit_insn (gen_addsi3_compareV_imm (operands[0], operands[1],
! 					    operands[2]));
      }
    else if (CONST_INT_P (operands[1]))
!     emit_insn (gen_sub_cmpVsi3_imm1 (operands[0], operands[1], operands[2]));
    else
!     emit_insn (gen_sub_cmpVsi3 (operands[0], operands[1], operands[2]));
  
    arm_gen_unlikely_cbranch (NE, CC_Vmode, operands[3]);
    DONE;
***************
*** 1499,1512 ****
      hi_op2 = force_reg (SImode, hi_op2);
    rtx ccreg = gen_rtx_REG (mode, CC_REGNUM);
    if (CONST_INT_P (hi_op2))
!     emit_insn (gen_subvsi3_borrow_imm (hi_result, hi_op1, hi_op2,
  				       gen_rtx_LTU (SImode, ccreg, const0_rtx),
  				       gen_rtx_LTU (DImode, ccreg,
  						    const0_rtx)));
-   else
-     emit_insn (gen_subvsi3_borrow (hi_result, hi_op1, hi_op2,
- 				   gen_rtx_LTU (SImode, ccreg, const0_rtx),
- 				   gen_rtx_LTU (DImode, ccreg, const0_rtx)));
    arm_gen_unlikely_cbranch (NE, CC_Vmode, operands[3]);
  
    DONE;
--- 1499,1514 ----
      hi_op2 = force_reg (SImode, hi_op2);
    rtx ccreg = gen_rtx_REG (mode, CC_REGNUM);
    if (CONST_INT_P (hi_op2))
!     emit_insn (gen_sub_cmpVsi3_borrow_imm (hi_result, hi_op1, hi_op2,
! 					   gen_rtx_LTU (SImode, ccreg,
! 							const0_rtx),
! 					   gen_rtx_LTU (DImode, ccreg,
! 							const0_rtx)));
!   else
!     emit_insn (gen_sub_cmpVsi3_borrow (hi_result, hi_op1, hi_op2,
  				       gen_rtx_LTU (SImode, ccreg, const0_rtx),
  				       gen_rtx_LTU (DImode, ccreg,
  						    const0_rtx)));
    arm_gen_unlikely_cbranch (NE, CC_Vmode, operands[3]);
  
    DONE;
***************
*** 1616,1630 ****
      hi_op2 = force_reg (SImode, hi_op2);
    rtx ccreg = gen_rtx_REG (mode, CC_REGNUM);
    if (CONST_INT_P (hi_op2))
!     emit_insn (gen_usubvsi3_borrow_imm (hi_result, hi_op1, hi_op2,
! 					GEN_INT (UINTVAL (hi_op2) & 0xffffffff),
  					gen_rtx_LTU (SImode, ccreg, const0_rtx),
  					gen_rtx_LTU (DImode, ccreg,
  						     const0_rtx)));
-   else
-     emit_insn (gen_usubvsi3_borrow (hi_result, hi_op1, hi_op2,
- 				    gen_rtx_LTU (SImode, ccreg, const0_rtx),
- 				    gen_rtx_LTU (DImode, ccreg, const0_rtx)));
    arm_gen_unlikely_cbranch (LTU, CC_Bmode, operands[3]);
  
    DONE;
--- 1618,1635 ----
      hi_op2 = force_reg (SImode, hi_op2);
    rtx ccreg = gen_rtx_REG (mode, CC_REGNUM);
    if (CONST_INT_P (hi_op2))
!     emit_insn (gen_usub_cmpVsi3_borrow_imm (hi_result, hi_op1, hi_op2,
! 					    GEN_INT (UINTVAL (hi_op2)
! 						     & 0xffffffff),
! 					    gen_rtx_LTU (SImode, ccreg,
! 							 const0_rtx),
! 					    gen_rtx_LTU (DImode, ccreg,
! 							 const0_rtx)));
!   else
!     emit_insn (gen_usub_cmpVsi3_borrow (hi_result, hi_op1, hi_op2,
  					gen_rtx_LTU (SImode, ccreg, const0_rtx),
  					gen_rtx_LTU (DImode, ccreg,
  						     const0_rtx)));
    arm_gen_unlikely_cbranch (LTU, CC_Bmode, operands[3]);
  
    DONE;
***************
*** 1643,1649 ****
     (set_attr "type" "alus_sreg")]
  )
  
! (define_insn "subvsi3"
    [(set (reg:CC_V CC_REGNUM)
  	(compare:CC_V
  	 (minus:DI
--- 1648,1654 ----
     (set_attr "type" "alus_sreg")]
  )
  
! (define_insn "sub_cmpVsi3"
    [(set (reg:CC_V CC_REGNUM)
  	(compare:CC_V
  	 (minus:DI
***************
*** 1660,1666 ****
     (set_attr "type" "alus_sreg")]
  )
  
! (define_insn "subvsi3_imm1"
    [(set (reg:CC_V CC_REGNUM)
  	(compare:CC_V
  	 (minus:DI
--- 1665,1671 ----
     (set_attr "type" "alus_sreg")]
  )
  
! (define_insn "sub_cmpVsi3_imm1"
    [(set (reg:CC_V CC_REGNUM)
  	(compare:CC_V
  	 (minus:DI
***************
*** 2117,2123 ****
     (set_attr "type" "alus_imm")]
  )
  
! (define_insn "usubvsi3_borrow"
    [(set (reg:CC_B CC_REGNUM)
  	(compare:CC_B
  	 (zero_extend:DI (match_operand:SI 1 "s_register_operand" "0,r"))
--- 2122,2128 ----
     (set_attr "type" "alus_imm")]
  )
  
! (define_insn "usub_cmpVsi3_borrow"
    [(set (reg:CC_B CC_REGNUM)
  	(compare:CC_B
  	 (zero_extend:DI (match_operand:SI 1 "s_register_operand" "0,r"))
***************
*** 2135,2141 ****
     (set_attr "length" "2,4")]
  )
  
! (define_insn "usubvsi3_borrow_imm"
    [(set (reg:CC_B CC_REGNUM)
  	(compare:CC_B
  	 (zero_extend:DI (match_operand:SI 1 "s_register_operand" "r,r"))
--- 2140,2146 ----
     (set_attr "length" "2,4")]
  )
  
! (define_insn "usub_cmpVsi3_borrow_imm"
    [(set (reg:CC_B CC_REGNUM)
  	(compare:CC_B
  	 (zero_extend:DI (match_operand:SI 1 "s_register_operand" "r,r"))
***************
*** 2154,2160 ****
     (set_attr "type" "alus_imm")]
  )
  
! (define_insn "subvsi3_borrow"
    [(set (reg:CC_V CC_REGNUM)
  	(compare:CC_V
  	 (minus:DI
--- 2159,2165 ----
     (set_attr "type" "alus_imm")]
  )
  
! (define_insn "sub_cmpVsi3_borrow"
    [(set (reg:CC_V CC_REGNUM)
  	(compare:CC_V
  	 (minus:DI
***************
*** 2175,2181 ****
     (set_attr "length" "2,4")]
  )
  
! (define_insn "subvsi3_borrow_imm"
    [(set (reg:CC_V CC_REGNUM)
  	(compare:CC_V
  	 (minus:DI
--- 2180,2186 ----
     (set_attr "length" "2,4")]
  )
  
! (define_insn "sub_cmpVsi3_borrow_imm"
    [(set (reg:CC_V CC_REGNUM)
  	(compare:CC_V
  	 (minus:DI
***************
*** 10128,10133 ****
--- 10133,10139 ----
     (set_attr "type" "multiple")]
  )
  
+ ;; (pred4 && pred5) != 0
  (define_insn "*cmp_ite0"
    [(set (match_operand 6 "dominant_cc_register" "")
  	(compare
***************
*** 10144,10150 ****
  	        "lPy,rI,L,lPy,lPy,rI,rI,L,L")])
  	  (const_int 0))
  	 (const_int 0)))]
!   "TARGET_32BIT"
    "*
    {
      static const char * const cmp1[NUM_OF_COND_CMP][2] =
--- 10150,10160 ----
  	        "lPy,rI,L,lPy,lPy,rI,rI,L,L")])
  	  (const_int 0))
  	 (const_int 0)))]
!   "TARGET_32BIT
!    && GET_MODE (operands[6]) != CCmode
!    && (GET_MODE (operands[6])
!        == arm_select_dominance_cc_mode (operands[4], operands[5],
! 					DOM_CC_X_AND_Y))"
    "*
    {
      static const char * const cmp1[NUM_OF_COND_CMP][2] =
***************
*** 10211,10216 ****
--- 10221,10227 ----
             (const_int 10))])]
  )
  
+ ;; (!pred4 || pred5) != 0
  (define_insn "*cmp_ite1"
    [(set (match_operand 6 "dominant_cc_register" "")
  	(compare
***************
*** 10227,10233 ****
  	        "lPy,rI,L,lPy,lPy,rI,rI,L,L")])
  	  (const_int 1))
  	 (const_int 0)))]
!   "TARGET_32BIT"
    "*
    {
      static const char * const cmp1[NUM_OF_COND_CMP][2] =
--- 10238,10248 ----
  	        "lPy,rI,L,lPy,lPy,rI,rI,L,L")])
  	  (const_int 1))
  	 (const_int 0)))]
!   "TARGET_32BIT
!    && GET_MODE (operands[6]) != CCmode
!    && (GET_MODE (operands[6])
!        == arm_select_dominance_cc_mode (operands[4], operands[5],
! 					DOM_CC_NX_OR_Y))"
    "*
    {
      static const char * const cmp1[NUM_OF_COND_CMP][2] =
***************
*** 10310,10316 ****
  	    (match_operand:SI 3 "arm_add_operand"
  	        "lPy,rI,L,lPy,lPy,r,rI,rI,L,L")]))
  	 (const_int 0)))]
!   "TARGET_32BIT"
    "*
    {
      static const char *const cmp1[NUM_OF_COND_CMP][2] =
--- 10325,10335 ----
  	    (match_operand:SI 3 "arm_add_operand"
  	        "lPy,rI,L,lPy,lPy,r,rI,rI,L,L")]))
  	 (const_int 0)))]
!   "TARGET_32BIT
!    && GET_MODE (operands[6]) != CCmode
!    && (GET_MODE (operands[6])
!        == arm_select_dominance_cc_mode (operands[4], operands[5],
! 					DOM_CC_X_AND_Y))"
    "*
    {
      static const char *const cmp1[NUM_OF_COND_CMP][2] =
***************
*** 10395,10401 ****
  	    (match_operand:SI 3 "arm_add_operand"
  	        "lPy,rI,L,lPy,lPy,r,rI,rI,L,L")]))
  	 (const_int 0)))]
!   "TARGET_32BIT"
    "*
    {
      static const char *const cmp1[NUM_OF_COND_CMP][2] =
--- 10414,10424 ----
  	    (match_operand:SI 3 "arm_add_operand"
  	        "lPy,rI,L,lPy,lPy,r,rI,rI,L,L")]))
  	 (const_int 0)))]
!   "TARGET_32BIT
!    && GET_MODE (operands[6]) != CCmode
!    && (GET_MODE (operands[6])
!        == arm_select_dominance_cc_mode (operands[4], operands[5],
! 					DOM_CC_X_OR_Y))"
    "*
    {
      static const char *const cmp1[NUM_OF_COND_CMP][2] =
diff -Nrcpad gcc-13.4.0/gcc/config/arm/constraints.md gcc-13.5.0-RC-20260904/gcc/config/arm/constraints.md
*** gcc-13.4.0/gcc/config/arm/constraints.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/arm/constraints.md	Fri Sep  4 07:35:07 2026
***************
*** 478,489 ****
  (define_memory_constraint "Uj"
   "@internal
    In ARM/Thumb-2 state a VFP load/store address that supports writeback
!   for Neon but not for MVE"
   (and (match_code "mem")
!       (match_test "TARGET_32BIT")
!       (match_test "TARGET_HAVE_MVE
!                    ? arm_coproc_mem_operand_no_writeback (op)
!                    : neon_vector_mem_operand (op, 2, true)")))
  
  (define_memory_constraint "Uy"
   "@internal
--- 478,489 ----
  (define_memory_constraint "Uj"
   "@internal
    In ARM/Thumb-2 state a VFP load/store address that supports writeback
!   for Neon but not for MVE or VFP_FP16INST"
   (and (match_code "mem")
!       (match_test "TARGET_32BIT
! 		   && (arm_coproc_mem_operand_no_writeback (op)
! 		       || (TARGET_NEON_FP16
! 			   && neon_vector_mem_operand (op, 2, true)))")))
  
  (define_memory_constraint "Uy"
   "@internal
diff -Nrcpad gcc-13.4.0/gcc/config/arm/mve.md gcc-13.5.0-RC-20260904/gcc/config/arm/mve.md
*** gcc-13.4.0/gcc/config/arm/mve.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/arm/mve.md	Fri Sep  4 07:35:07 2026
***************
*** 1874,1881 ****
  (define_insn "mve_vbicq_f"
    [
     (set (match_operand:MVE_0 0 "s_register_operand" "=w")
! 	(and:MVE_0 (not:MVE_0 (match_operand:MVE_0 1 "s_register_operand" "w"))
! 			      (match_operand:MVE_0 2 "s_register_operand" "w")))
    ]
    "TARGET_HAVE_MVE && TARGET_HAVE_MVE_FLOAT"
    "vbic\t%q0, %q1, %q2"
--- 1874,1881 ----
  (define_insn "mve_vbicq_f"
    [
     (set (match_operand:MVE_0 0 "s_register_operand" "=w")
! 	(and:MVE_0 (not:MVE_0 (match_operand:MVE_0 2 "s_register_operand" "w"))
! 			      (match_operand:MVE_0 1 "s_register_operand" "w")))
    ]
    "TARGET_HAVE_MVE && TARGET_HAVE_MVE_FLOAT"
    "vbic\t%q0, %q1, %q2"
diff -Nrcpad gcc-13.4.0/gcc/config/arm/thumb2.md gcc-13.5.0-RC-20260904/gcc/config/arm/thumb2.md
*** gcc-13.4.0/gcc/config/arm/thumb2.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/arm/thumb2.md	Fri Sep  4 07:35:07 2026
***************
*** 1465,1483 ****
  	      (pc)))
     (clobber (reg:CC CC_REGNUM))]
    "TARGET_THUMB2"
!   "*
!   if (get_attr_length (insn) == 2)
!     return \"cbz\\t%0, %l1\";
!   else
!     return \"cmp\\t%0, #0\;beq\\t%l1\";
!   "
    [(set (attr "length")
          (if_then_else
  	    (and (ge (minus (match_dup 1) (pc)) (const_int 2))
  	         (le (minus (match_dup 1) (pc)) (const_int 128))
  	         (not (match_test "which_alternative")))
  	    (const_int 2)
! 	    (const_int 8)))
     (set_attr "type" "branch,multiple")]
  )
  
--- 1465,1488 ----
  	      (pc)))
     (clobber (reg:CC CC_REGNUM))]
    "TARGET_THUMB2"
!   {
!     int offset = (INSN_ADDRESSES (INSN_UID (operands[1]))
! 		  - INSN_ADDRESSES (INSN_UID (insn)));
!     if (get_attr_length (insn) == 2)
!       return "cbz\t%0, %l1";
!     else if (offset >= -1048564 && offset <= 1048576)
!       return "cmp\t%0, #0\;beq\t%l1";
!     else if (which_alternative == 0)
!       return "cbnz\t%0, %-LCB%=\;b\t%l1\n%-LCB%=:";
!     return "cmp\t%0, #0\;bne\t%-LCB%=\;b\t%l1\n%-LCB%=:";
!   }
    [(set (attr "length")
          (if_then_else
  	    (and (ge (minus (match_dup 1) (pc)) (const_int 2))
  	         (le (minus (match_dup 1) (pc)) (const_int 128))
  	         (not (match_test "which_alternative")))
  	    (const_int 2)
! 	    (const_int 10)))
     (set_attr "type" "branch,multiple")]
  )
  
***************
*** 1489,1507 ****
  	      (pc)))
     (clobber (reg:CC CC_REGNUM))]
    "TARGET_THUMB2"
!   "*
!   if (get_attr_length (insn) == 2)
!     return \"cbnz\\t%0, %l1\";
!   else
!     return \"cmp\\t%0, #0\;bne\\t%l1\";
!   "
    [(set (attr "length")
          (if_then_else
  	    (and (ge (minus (match_dup 1) (pc)) (const_int 2))
  	         (le (minus (match_dup 1) (pc)) (const_int 128))
  	         (not (match_test "which_alternative")))
  	    (const_int 2)
! 	    (const_int 8)))
     (set_attr "type" "branch,multiple")]
  )
  
--- 1494,1517 ----
  	      (pc)))
     (clobber (reg:CC CC_REGNUM))]
    "TARGET_THUMB2"
!   {
!     int offset = (INSN_ADDRESSES (INSN_UID (operands[1]))
! 		  - INSN_ADDRESSES (INSN_UID (insn)));
!     if (get_attr_length (insn) == 2)
!       return "cbnz\t%0, %l1";
!     else if (offset >= -1048564 && offset <= 1048576)
!       return "cmp\t%0, #0\;bne\t%l1";
!     else if (which_alternative == 0)
!       return "cbz\t%0, %-LCB%=\;b\t%l1\n%-LCB%=:";
!     return "cmp\t%0, #0\;beq\t%-LCB%=\;b\t%l1\n%-LCB%=:";
!   }
    [(set (attr "length")
          (if_then_else
  	    (and (ge (minus (match_dup 1) (pc)) (const_int 2))
  	         (le (minus (match_dup 1) (pc)) (const_int 128))
  	         (not (match_test "which_alternative")))
  	    (const_int 2)
! 	    (const_int 10)))
     (set_attr "type" "branch,multiple")]
  )
  
diff -Nrcpad gcc-13.4.0/gcc/config/arm/vfp.md gcc-13.5.0-RC-20260904/gcc/config/arm/vfp.md
*** gcc-13.4.0/gcc/config/arm/vfp.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/arm/vfp.md	Fri Sep  4 07:35:07 2026
***************
*** 424,435 ****
      case 6: /* S register from immediate.  */
        return \"vmov.f16\\t%0, %1\t%@ __\";
      case 7: /* S register from memory.  */
!       if (TARGET_HAVE_MVE)
  	return \"vldr.16\\t%0, %1\";
        else
  	return \"vld1.16\\t{%z0}, %A1\";
      case 8: /* Memory from S register.  */
!       if (TARGET_HAVE_MVE)
  	return \"vstr.16\\t%1, %0\";
        else
  	return \"vst1.16\\t{%z1}, %A0\";
--- 424,435 ----
      case 6: /* S register from immediate.  */
        return \"vmov.f16\\t%0, %1\t%@ __\";
      case 7: /* S register from memory.  */
!       if (!auto_inc_p (XEXP (operands[1], 0)))
  	return \"vldr.16\\t%0, %1\";
        else
  	return \"vld1.16\\t{%z0}, %A1\";
      case 8: /* Memory from S register.  */
!       if (!auto_inc_p (XEXP (operands[0], 0)))
  	return \"vstr.16\\t%1, %0\";
        else
  	return \"vst1.16\\t{%z1}, %A0\";
diff -Nrcpad gcc-13.4.0/gcc/config/avr/avr-fixed.md gcc-13.5.0-RC-20260904/gcc/config/avr/avr-fixed.md
*** gcc-13.4.0/gcc/config/avr/avr-fixed.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/avr/avr-fixed.md	Fri Sep  4 07:35:07 2026
***************
*** 44,52 ****
     SQ USQ SA USA
     DQ UDQ DA UDA
     TA UTA
!    QI HI SI DI])
  
! ;; Same so that be can build cross products
  
  (define_mode_iterator FIXED_B
    [QQ UQQ
--- 44,52 ----
     SQ USQ SA USA
     DQ UDQ DA UDA
     TA UTA
!    QI HI PSI SI DI])
  
! ;; Same so that we can build cartesian products.
  
  (define_mode_iterator FIXED_B
    [QQ UQQ
***************
*** 54,60 ****
     SQ USQ SA USA
     DQ UDQ DA UDA
     TA UTA
!    QI HI SI DI])
  
  (define_insn_and_split "fract2"
    [(set (match_operand:FIXED_A 0 "register_operand" "=r")
--- 54,60 ----
     SQ USQ SA USA
     DQ UDQ DA UDA
     TA UTA
!    QI HI PSI SI DI])
  
  (define_insn_and_split "fract2"
    [(set (match_operand:FIXED_A 0 "register_operand" "=r")
diff -Nrcpad gcc-13.4.0/gcc/config/avr/avr-mcus.def gcc-13.5.0-RC-20260904/gcc/config/avr/avr-mcus.def
*** gcc-13.4.0/gcc/config/avr/avr-mcus.def	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/avr/avr-mcus.def	Fri Sep  4 07:35:07 2026
*************** AVR_MCU ("avr64da28",        ARCH_AVRXME
*** 313,318 ****
--- 313,322 ----
  AVR_MCU ("avr64da32",        ARCH_AVRXMEGA2, AVR_ISA_NONE, "__AVR_AVR64DA32__",    0x6000, 0x0, 0x10000, 0)
  AVR_MCU ("avr64da48",        ARCH_AVRXMEGA2, AVR_ISA_NONE, "__AVR_AVR64DA48__",    0x6000, 0x0, 0x10000, 0)
  AVR_MCU ("avr64da64",        ARCH_AVRXMEGA2, AVR_ISA_NONE, "__AVR_AVR64DA64__",    0x6000, 0x0, 0x10000, 0)
+ AVR_MCU ("avr64da28s",       ARCH_AVRXMEGA2, AVR_ISA_NONE, "__AVR_AVR64DA28S__",   0x6000, 0x0, 0x10000, 0)
+ AVR_MCU ("avr64da32s",       ARCH_AVRXMEGA2, AVR_ISA_NONE, "__AVR_AVR64DA32S__",   0x6000, 0x0, 0x10000, 0)
+ AVR_MCU ("avr64da48s",       ARCH_AVRXMEGA2, AVR_ISA_NONE, "__AVR_AVR64DA48S__",   0x6000, 0x0, 0x10000, 0)
+ AVR_MCU ("avr64da64s",       ARCH_AVRXMEGA2, AVR_ISA_NONE, "__AVR_AVR64DA64S__",   0x6000, 0x0, 0x10000, 0)
  AVR_MCU ("avr64db28",        ARCH_AVRXMEGA2, AVR_ISA_NONE, "__AVR_AVR64DB28__",    0x6000, 0x0, 0x10000, 0)
  AVR_MCU ("avr64db32",        ARCH_AVRXMEGA2, AVR_ISA_NONE, "__AVR_AVR64DB32__",    0x6000, 0x0, 0x10000, 0)
  AVR_MCU ("avr64db48",        ARCH_AVRXMEGA2, AVR_ISA_NONE, "__AVR_AVR64DB48__",    0x6000, 0x0, 0x10000, 0)
*************** AVR_MCU ("avr16du32",        ARCH_AVRXME
*** 389,394 ****
--- 393,401 ----
  AVR_MCU ("avr32da28",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32DA28__",   0x7000, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr32da32",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32DA32__",   0x7000, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr32da48",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32DA48__",   0x7000, 0x0, 0x8000, 0x8000)
+ AVR_MCU ("avr32da28s",       ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32DA28S__",  0x7000, 0x0, 0x8000, 0x8000)
+ AVR_MCU ("avr32da32s",       ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32DA32S__",  0x7000, 0x0, 0x8000, 0x8000)
+ AVR_MCU ("avr32da48s",       ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32DA48S__",  0x7000, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr32db28",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32DB28__",   0x7000, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr32db32",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32DB32__",   0x7000, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr32db48",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32DB48__",   0x7000, 0x0, 0x8000, 0x8000)
*************** AVR_MCU ("avr16eb14",        ARCH_AVRXME
*** 404,415 ****
--- 411,434 ----
  AVR_MCU ("avr16eb20",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR16EB20__",   0x7800, 0x0, 0x4000, 0x8000)
  AVR_MCU ("avr16eb28",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR16EB28__",   0x7800, 0x0, 0x4000, 0x8000)
  AVR_MCU ("avr16eb32",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR16EB32__",   0x7800, 0x0, 0x4000, 0x8000)
+ AVR_MCU ("avr32eb14",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32EB14__",   0x7400, 0x0, 0x8000, 0x8000)
+ AVR_MCU ("avr32eb20",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32EB20__",   0x7400, 0x0, 0x8000, 0x8000)
+ AVR_MCU ("avr32eb28",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32EB28__",   0x7400, 0x0, 0x8000, 0x8000)
+ AVR_MCU ("avr32eb32",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32EB32__",   0x7400, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr16ea28",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR16EA28__",   0x7800, 0x0, 0x4000, 0x8000)
  AVR_MCU ("avr16ea32",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR16EA32__",   0x7800, 0x0, 0x4000, 0x8000)
  AVR_MCU ("avr16ea48",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR16EA48__",   0x7800, 0x0, 0x4000, 0x8000)
  AVR_MCU ("avr32ea28",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32EA28__",   0x7000, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr32ea32",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32EA32__",   0x7000, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr32ea48",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32EA48__",   0x7000, 0x0, 0x8000, 0x8000)
+ AVR_MCU ("avr16la14",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR16LA14__",   0x7800, 0x0, 0x4000, 0x8000)
+ AVR_MCU ("avr16la20",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR16LA20__",   0x7800, 0x0, 0x4000, 0x8000)
+ AVR_MCU ("avr16la28",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR16LA28__",   0x7800, 0x0, 0x4000, 0x8000)
+ AVR_MCU ("avr16la32",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR16LA32__",   0x7800, 0x0, 0x4000, 0x8000)
+ AVR_MCU ("avr32la14",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32LA14__",   0x7800, 0x0, 0x8000, 0x8000)
+ AVR_MCU ("avr32la20",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32LA20__",   0x7800, 0x0, 0x8000, 0x8000)
+ AVR_MCU ("avr32la28",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32LA28__",   0x7800, 0x0, 0x8000, 0x8000)
+ AVR_MCU ("avr32la32",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32LA32__",   0x7800, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr32sd20",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32SD20__",   0x7000, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr32sd28",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32SD28__",   0x7000, 0x0, 0x8000, 0x8000)
  AVR_MCU ("avr32sd32",        ARCH_AVRXMEGA3, AVR_ISA_NONE,  "__AVR_AVR32SD32__",   0x7000, 0x0, 0x8000, 0x8000)
*************** AVR_MCU ("avr128da28",       ARCH_AVRXME
*** 427,432 ****
--- 446,455 ----
  AVR_MCU ("avr128da32",       ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_AVR128DA32__",   0x4000, 0x0, 0x20000, 0)
  AVR_MCU ("avr128da48",       ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_AVR128DA48__",   0x4000, 0x0, 0x20000, 0)
  AVR_MCU ("avr128da64",       ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_AVR128DA64__",   0x4000, 0x0, 0x20000, 0)
+ AVR_MCU ("avr128da28s",      ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_AVR128DA28S__",  0x4000, 0x0, 0x20000, 0)
+ AVR_MCU ("avr128da32s",      ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_AVR128DA32S__",  0x4000, 0x0, 0x20000, 0)
+ AVR_MCU ("avr128da48s",      ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_AVR128DA48S__",  0x4000, 0x0, 0x20000, 0)
+ AVR_MCU ("avr128da64s",      ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_AVR128DA64S__",  0x4000, 0x0, 0x20000, 0)
  AVR_MCU ("avr128db28",       ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_AVR128DB28__",   0x4000, 0x0, 0x20000, 0)
  AVR_MCU ("avr128db32",       ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_AVR128DB32__",   0x4000, 0x0, 0x20000, 0)
  AVR_MCU ("avr128db48",       ARCH_AVRXMEGA4, AVR_ISA_NONE, "__AVR_AVR128DB48__",   0x4000, 0x0, 0x20000, 0)
diff -Nrcpad gcc-13.4.0/gcc/config/avr/avr.cc gcc-13.5.0-RC-20260904/gcc/config/avr/avr.cc
*** gcc-13.4.0/gcc/config/avr/avr.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/avr/avr.cc	Fri Sep  4 07:35:07 2026
*************** avr_out_fract (rtx_insn *insn, rtx opera
*** 9323,9329 ****
          {
            avr_asm_len ("clr __tmp_reg__" CR_TAB
                         "sbrc %1,0"       CR_TAB
!                        "dec __tmp_reg__", xop, plen, 1);
            sn = src.regno;
            if (sn < s0)
              {
--- 9323,9329 ----
          {
            avr_asm_len ("clr __tmp_reg__" CR_TAB
                         "sbrc %1,0"       CR_TAB
!                        "dec __tmp_reg__", xop, plen, 3);
            sn = src.regno;
            if (sn < s0)
              {
*************** avr_out_fract (rtx_insn *insn, rtx opera
*** 9338,9344 ****
              avr_asm_len ("clt"                CR_TAB
                           "bld __tmp_reg__,7"  CR_TAB
                           "adc %0,__tmp_reg__",
!                          &all_regs_rtx[s0], plen, 1);
            else
              avr_asm_len ("lsr __tmp_reg" CR_TAB
                           "add %0,__tmp_reg__",
--- 9338,9344 ----
              avr_asm_len ("clt"                CR_TAB
                           "bld __tmp_reg__,7"  CR_TAB
                           "adc %0,__tmp_reg__",
!                          &all_regs_rtx[s0], plen, 3);
            else
              avr_asm_len ("lsr __tmp_reg" CR_TAB
                           "add %0,__tmp_reg__",
*************** avr_out_fract (rtx_insn *insn, rtx opera
*** 9537,9544 ****
  	  xop[2] = all_regs_rtx[s0];
  	  if (!lsb_in_tmp_reg && !MAY_CLOBBER (s0))
  	    avr_asm_len ("mov __tmp_reg__,%2", xop, plen, 1);
! 	  avr_asm_len ("tst %0" CR_TAB "brpl 0f",
! 		       &all_regs_rtx[src.regno_msb], plen, 2);
  	  if (!lsb_in_tmp_reg)
  	    {
  	      unsigned sn = src.regno;
--- 9537,9544 ----
  	  xop[2] = all_regs_rtx[s0];
  	  if (!lsb_in_tmp_reg && !MAY_CLOBBER (s0))
  	    avr_asm_len ("mov __tmp_reg__,%2", xop, plen, 1);
! 	  avr_asm_len ("tst %0" CR_TAB
! 		       "brpl 0f", &all_regs_rtx[src.regno_msb], plen, 2);
  	  if (!lsb_in_tmp_reg)
  	    {
  	      unsigned sn = src.regno;
diff -Nrcpad gcc-13.4.0/gcc/config/avr/avr.h gcc-13.5.0-RC-20260904/gcc/config/avr/avr.h
*** gcc-13.4.0/gcc/config/avr/avr.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/avr/avr.h	Fri Sep  4 07:35:07 2026
*************** enum reg_class {
*** 322,331 ****
  
  #define RETURN_ADDR_RTX(count, tem) avr_return_addr_rtx (count, tem)
  
- /* Don't use Push rounding. expr.cc: emit_single_push_insn is broken 
-    for POST_DEC targets (PR27386).  */
- /*#define PUSH_ROUNDING(NPUSHED) (NPUSHED)*/
- 
  typedef struct avr_args
  {
    /* # Registers available for passing */
--- 322,327 ----
*************** struct GTY(()) machine_function
*** 595,601 ****
  };
  
  /* AVR does not round pushes, but the existence of this macro is
!    required in order for pushes to be generated.  */
  #define PUSH_ROUNDING(X)	(X)
  
  /* Define prototype here to avoid build warning.  Some files using
--- 591,601 ----
  };
  
  /* AVR does not round pushes, but the existence of this macro is
!    required in order for pushes to be generated.
!    This macro was removed for PR27386 and then later re-added when
!    push insns were introduced.  Push insns can work around broken
!    argument setup in expr.cc that doesn't work properly for
!    STACK_GROWS_DOWNWARDS + POST_DEC push, see PR127098.  */
  #define PUSH_ROUNDING(X)	(X)
  
  /* Define prototype here to avoid build warning.  Some files using
diff -Nrcpad gcc-13.4.0/gcc/config/avr/avr.md gcc-13.5.0-RC-20260904/gcc/config/avr/avr.md
*** gcc-13.4.0/gcc/config/avr/avr.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/avr/avr.md	Fri Sep  4 07:35:07 2026
***************
*** 425,431 ****
     HI CHI HA UHA HQ UHQ
     SI CSI SA USA SQ USQ
     DI CDI DA UDA DQ UDQ
!    TA UTA
     SF DF SC DC
     PSI])
  
--- 425,431 ----
     HI CHI HA UHA HQ UHQ
     SI CSI SA USA SQ USQ
     DI CDI DA UDA DQ UDQ
!    TA UTA TI
     SF DF SC DC
     PSI])
  
diff -Nrcpad gcc-13.4.0/gcc/config/avr/elf.h gcc-13.5.0-RC-20260904/gcc/config/avr/elf.h
*** gcc-13.4.0/gcc/config/avr/elf.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/avr/elf.h	Fri Sep  4 07:35:07 2026
***************
*** 17,22 ****
--- 17,35 ----
     along with GCC; see the file COPYING3.  If not see
     .  */
  
+ /* defaults.h requires HAVE_INITFINI_ARRAY_SUPPORT to be present
+    in order for attribute "retain" to be recognized.  This is due
+    to some quirks in crtstuff.h -- which isn't even used by avr.
+    All we need is that Binutils supports the "R"etain section flag.
+    If that's the case, define SUPPORTS_SHF_GNU_RETAIN so that
+    defaults.h doesn't define it to 0.  */
+ #if defined(IN_GCC) && !defined(USED_FOR_TARGET) && !defined(GENERATOR_FILE)
+ #include "auto-host.h" /* HAVE_GAS_SHF_GNU_RETAIN */
+ #if HAVE_GAS_SHF_GNU_RETAIN
+ #undef SUPPORTS_SHF_GNU_RETAIN
+ #define SUPPORTS_SHF_GNU_RETAIN 1
+ #endif
+ #endif
  
  /* Overriding some definitions from elfos.h for AVR.  */
  
diff -Nrcpad gcc-13.4.0/gcc/config/avr/specs.h gcc-13.5.0-RC-20260904/gcc/config/avr/specs.h
*** gcc-13.4.0/gcc/config/avr/specs.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/avr/specs.h	Fri Sep  4 07:35:07 2026
*************** along with GCC; see the file COPYING3.
*** 59,65 ****
    "%{mmcu=*:-m%*} "
  
  #define LINK_RELAX_SPEC                         \
!   "%{mrelax:--relax} "
  
  #undef  LINK_SPEC
  #define LINK_SPEC                               \
--- 59,65 ----
    "%{mmcu=*:-m%*} "
  
  #define LINK_RELAX_SPEC                         \
!   "%{!r:%{mrelax:--relax}} "
  
  #undef  LINK_SPEC
  #define LINK_SPEC                               \
diff -Nrcpad gcc-13.4.0/gcc/config/darwin-driver.cc gcc-13.5.0-RC-20260904/gcc/config/darwin-driver.cc
*** gcc-13.4.0/gcc/config/darwin-driver.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/darwin-driver.cc	Fri Sep  4 07:35:07 2026
*************** validate_macosx_version_min (const char
*** 64,70 ****
  
    major = strtoul (version_str, &end, 10);
  
!   /* macOS 10, 11, and 12 are known. clang accepts up to 99.  */
    if (major < 10 || major > 99)
      return NULL;
  
--- 64,71 ----
  
    major = strtoul (version_str, &end, 10);
  
!   /* macOS 10, 11, 12, 13, 14, 15 and 26 are known.
!      clang accepts up to 99.  */
    if (major < 10 || major > 99)
      return NULL;
  
*************** darwin_find_version_from_kernel (void)
*** 159,173 ****
    if (*version_p++ != '.')
      goto parse_failed;
  
!   /* Darwin20 sees a transition to macOS 11.  In this, it seems that the
!      mapping to macOS minor version and patch level is now always 0, 0
!      (at least for macOS 11 and 12).  */
!   if (major_vers >= 20)
!     {
!       /* Apple clang doesn't include the minor version or the patch level
! 	 in the object file, nor does it pass it to ld  */
!       asprintf (&new_flag, "%d.00.00", major_vers - 9);
!     }
    else if (major_vers - 4 <= 4)
      /* On 10.4 and earlier, the old linker is used which does not
         support three-component system versions.
--- 160,175 ----
    if (*version_p++ != '.')
      goto parse_failed;
  
!   /* Darwin25 saw a transition to macOS 26.  */
!   if (major_vers >= 25)
!     /* Apple clang doesn't include the minor version or the patch level
!        in the object file, nor does it pass it to ld  */
!     asprintf (&new_flag, "%d.00.00", major_vers + 1);
!   /* Darwin20 saw a transition to macOS 11.  */
!   else if (major_vers >= 20)
!     /* Apple clang doesn't include the minor version or the patch level
!        in the object file, nor does it pass it to ld  */
!     asprintf (&new_flag, "%d.00.00", major_vers - 9);
    else if (major_vers - 4 <= 4)
      /* On 10.4 and earlier, the old linker is used which does not
         support three-component system versions.
diff -Nrcpad gcc-13.4.0/gcc/config/darwin.h gcc-13.5.0-RC-20260904/gcc/config/darwin.h
*** gcc-13.4.0/gcc/config/darwin.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/darwin.h	Fri Sep  4 07:35:07 2026
*************** extern GTY(()) int darwin_ms_struct;
*** 392,401 ****
  	   ___emutls_get_address -exported_symbol ___emutls_get_address \
  	  -U ___emutls_register_common \
  	  -exported_symbol ___emutls_register_common \
- 	  -U ___gcc_nested_func_ptr_created \
- 	  -exported_symbol ___gcc_nested_func_ptr_created \
- 	  -U ___gcc_nested_func_ptr_deleted \
- 	  -exported_symbol ___gcc_nested_func_ptr_deleted \
        }} \
      }}}\
      %{!r:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} %{F*} "\
--- 392,397 ----
diff -Nrcpad gcc-13.4.0/gcc/config/gnu.h gcc-13.5.0-RC-20260904/gcc/config/gnu.h
*** gcc-13.4.0/gcc/config/gnu.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/gnu.h	Fri Sep  4 07:35:07 2026
*************** You should have received a copy of the G
*** 19,24 ****
--- 19,28 ----
  along with GCC.  If not, see .
  */
  
+ /* C libraries used on GNU/Hurd.  */
+ #define OPTION_GLIBC_P(opts)	(DEFAULT_LIBC == LIBC_GLIBC)
+ #define OPTION_GLIBC		OPTION_GLIBC_P (&global_options)
+ 
  #undef GNU_USER_TARGET_OS_CPP_BUILTINS
  #define GNU_USER_TARGET_OS_CPP_BUILTINS()		\
      do {					\
diff -Nrcpad gcc-13.4.0/gcc/config/i386/amxbf16intrin.h gcc-13.5.0-RC-20260904/gcc/config/i386/amxbf16intrin.h
*** gcc-13.4.0/gcc/config/i386/amxbf16intrin.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/amxbf16intrin.h	Fri Sep  4 07:35:07 2026
***************
*** 36,43 ****
  
  #if defined(__x86_64__)
  #define _tile_dpbf16ps_internal(dst,src1,src2)					\
!   __asm__ volatile\
!   ("{tdpbf16ps\t%%tmm"#src2", %%tmm"#src1", %%tmm"#dst"|tdpbf16ps\t%%tmm"#dst", %%tmm"#src1", %%tmm"#src2"}" ::)
  
  #define _tile_dpbf16ps(dst,src1,src2)					\
    _tile_dpbf16ps_internal (dst, src1, src2)
--- 36,45 ----
  
  #if defined(__x86_64__)
  #define _tile_dpbf16ps_internal(dst,src1,src2)					\
!   __asm__ volatile								\
!   ("{tdpbf16ps\t%%tmm%c[_src2], %%tmm%c[_src1], %%tmm%c[_dst]			\
!     |tdpbf16ps\ttmm%c[_dst], tmm%c[_src1], tmm%c[_src2]}"			\
!     :: [_dst]"i"(dst), [_src1]"i"(src1), [_src2]"i"(src2))
  
  #define _tile_dpbf16ps(dst,src1,src2)					\
    _tile_dpbf16ps_internal (dst, src1, src2)
diff -Nrcpad gcc-13.4.0/gcc/config/i386/amxcomplexintrin.h gcc-13.5.0-RC-20260904/gcc/config/i386/amxcomplexintrin.h
*** gcc-13.4.0/gcc/config/i386/amxcomplexintrin.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/amxcomplexintrin.h	Fri Sep  4 07:35:07 2026
***************
*** 35,47 ****
  #endif /* __AMX_COMPLEX__ */
  
  #if defined(__x86_64__)
! #define _tile_cmmimfp16ps_internal(src1_dst,src2,src3)				\
!   __asm__ volatile\
!   ("{tcmmimfp16ps\t%%tmm"#src3", %%tmm"#src2", %%tmm"#src1_dst"|tcmmimfp16ps\t%%tmm"#src1_dst", %%tmm"#src2", %%tmm"#src3"}" ::)
  
! #define _tile_cmmrlfp16ps_internal(src1_dst,src2,src3)				\
!   __asm__ volatile\
!   ("{tcmmrlfp16ps\t%%tmm"#src3", %%tmm"#src2", %%tmm"#src1_dst"|tcmmrlfp16ps\t%%tmm"#src1_dst", %%tmm"#src2", %%tmm"#src3"}" ::)
  
  #define _tile_cmmimfp16ps(src1_dst,src2,src3)					\
    _tile_cmmimfp16ps_internal (src1_dst, src2, src3)
--- 35,51 ----
  #endif /* __AMX_COMPLEX__ */
  
  #if defined(__x86_64__)
! #define _tile_cmmimfp16ps_internal(src1_dst,src2,src3)			  \
!   __asm__ volatile							  \
!   ("{tcmmimfp16ps\t%%tmm%c[_src3], %%tmm%c[_src2], %%tmm%c[_src1_dst]	  \
!     |tcmmimfp16ps\ttmm%c[_src1_dst], tmm%c[_src2], tmm%c[_src3]}"	  \
!     :: [_src1_dst]"i"(src1_dst), [_src2]"i"(src2), [_src3]"i"(src3))
  
! #define _tile_cmmrlfp16ps_internal(src1_dst,src2,src3)			  \
!   __asm__ volatile							  \
!   ("{tcmmrlfp16ps\t%%tmm%c[_src3], %%tmm%c[_src2], %%tmm%c[_src1_dst]	  \
!     |tcmmrlfp16ps\ttmm%c[_src1_dst], tmm%c[_src2], tmm%c[_src3]}"	  \
!     :: [_src1_dst]"i"(src1_dst), [_src2]"i"(src2), [_src3]"i"(src3))
  
  #define _tile_cmmimfp16ps(src1_dst,src2,src3)					\
    _tile_cmmimfp16ps_internal (src1_dst, src2, src3)
diff -Nrcpad gcc-13.4.0/gcc/config/i386/amxfp16intrin.h gcc-13.5.0-RC-20260904/gcc/config/i386/amxfp16intrin.h
*** gcc-13.4.0/gcc/config/i386/amxfp16intrin.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/amxfp16intrin.h	Fri Sep  4 07:35:07 2026
***************
*** 29,37 ****
  #define _AMXFP16INTRIN_H_INCLUDED
  
  #if defined(__x86_64__)
! #define _tile_dpfp16ps_internal(dst,src1,src2)			\
!   __asm__ volatile \
!   ("{tdpfp16ps\t%%tmm"#src2", %%tmm"#src1", %%tmm"#dst"|tdpfp16ps\t%%tmm"#dst", %%tmm"#src1", %%tmm"#src2"}" ::)
  
  #define _tile_dpfp16ps(dst,src1,src2)				\
    _tile_dpfp16ps_internal (dst,src1,src2)
--- 29,39 ----
  #define _AMXFP16INTRIN_H_INCLUDED
  
  #if defined(__x86_64__)
! #define _tile_dpfp16ps_internal(dst,src1,src2)				\
!   __asm__ volatile							\
!   ("{tdpfp16ps\t%%tmm%c[_src2], %%tmm%c[_src1], %%tmm%c[_dst]		\
!     |tdpfp16ps\ttmm%c[_dst], tmm%c[_src1], tmm%c[_src2]}"		\
!     :: [_dst]"i"(dst), [_src1]"i"(src1), [_src2]"i"(src2))
  
  #define _tile_dpfp16ps(dst,src1,src2)				\
    _tile_dpfp16ps_internal (dst,src1,src2)
diff -Nrcpad gcc-13.4.0/gcc/config/i386/amxint8intrin.h gcc-13.5.0-RC-20260904/gcc/config/i386/amxint8intrin.h
*** gcc-13.4.0/gcc/config/i386/amxint8intrin.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/amxint8intrin.h	Fri Sep  4 07:35:07 2026
***************
*** 37,43 ****
  #if defined(__x86_64__)
  #define _tile_int8_dp_internal(name,dst,src1,src2)					\
    __asm__ volatile							\
!   ("{"#name"\t%%tmm"#src2", %%tmm"#src1", %%tmm"#dst"|"#name"\t%%tmm"#dst", %%tmm"#src1", %%tmm"#src2"}" ::)
  
  #define _tile_dpbssd(dst,src1,src2)					\
    _tile_int8_dp_internal (tdpbssd, dst, src1, src2)
--- 37,45 ----
  #if defined(__x86_64__)
  #define _tile_int8_dp_internal(name,dst,src1,src2)					\
    __asm__ volatile							\
!   ("{"#name"\t%%tmm%c[_src2], %%tmm%c[_src1], %%tmm%c[_dst]		\
!    |"#name"\ttmm%c[_dst], tmm%c[_src1], tmm%c[_src2]}"		\
!    ::[_dst]"i"(dst),[_src1]"i"(src1),[_src2]"i"(src2))
  
  #define _tile_dpbssd(dst,src1,src2)					\
    _tile_int8_dp_internal (tdpbssd, dst, src1, src2)
diff -Nrcpad gcc-13.4.0/gcc/config/i386/amxtileintrin.h gcc-13.5.0-RC-20260904/gcc/config/i386/amxtileintrin.h
*** gcc-13.4.0/gcc/config/i386/amxtileintrin.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/amxtileintrin.h	Fri Sep  4 07:35:07 2026
*************** _tile_release (void)
*** 61,92 ****
  
  #define _tile_loadd_internal(dst,base,stride)				\
    __asm__ volatile							\
!   ("{tileloadd\t(%0,%1,1), %%tmm"#dst"|tileloadd\t%%tmm"#dst", [%0+%1*1]}" \
!    :: "r" ((const void*) (base)), "r" ((__PTRDIFF_TYPE__) (stride)))
  
  #define _tile_stream_loadd(dst,base,stride)		\
    _tile_stream_loadd_internal (dst, base, stride)
  
  #define _tile_stream_loadd_internal(dst,base,stride)			\
    __asm__ volatile							\
!   ("{tileloaddt1\t(%0,%1,1), %%tmm"#dst"|tileloaddt1\t%%tmm"#dst", [%0+%1*1]}" \
!    :: "r" ((const void*) (base)), "r" ((__PTRDIFF_TYPE__) (stride)))
  
  #define _tile_stored(dst,base,stride)		\
    _tile_stored_internal (dst, base, stride)
  
  #define _tile_stored_internal(src,base,stride)				\
    __asm__ volatile							\
!   ("{tilestored\t%%tmm"#src", (%0,%1,1)|tilestored\t[%0+%1*1], %%tmm"#src"}" \
!    :: "r" ((void*) (base)), "r" ((__PTRDIFF_TYPE__) (stride)) \
!    : "memory")
  
  #define _tile_zero(dst)				\
    _tile_zero_internal (dst)
  
! #define _tile_zero_internal(dst)		\
!   __asm__ volatile				\
!   ("tilezero\t%%tmm"#dst ::)
  
  #endif
  
--- 61,92 ----
  
  #define _tile_loadd_internal(dst,base,stride)				\
    __asm__ volatile							\
!   ("{tileloadd\t(%0,%1,1), %%tmm%c[_dst]|tileloadd\ttmm%c[_dst], [%0+%1*1]}" \
!   :: "r" ((const void*) (base)), "r" ((__PTRDIFF_TYPE__) (stride)), [_dst]"i"(dst))
  
  #define _tile_stream_loadd(dst,base,stride)		\
    _tile_stream_loadd_internal (dst, base, stride)
  
  #define _tile_stream_loadd_internal(dst,base,stride)			\
    __asm__ volatile							\
!   ("{tileloaddt1\t(%0,%1,1), %%tmm%c[_dst]|tileloaddt1\ttmm%c[_dst], [%0+%1*1]}" \
!   :: "r" ((const void*) (base)), "r" ((__PTRDIFF_TYPE__) (stride)), [_dst]"i"(dst))
  
  #define _tile_stored(dst,base,stride)		\
    _tile_stored_internal (dst, base, stride)
  
  #define _tile_stored_internal(src,base,stride)				\
    __asm__ volatile							\
!   ("{tilestored\t%%tmm%c[_src], (%0,%1,1)|tilestored\t[%0+%1*1], tmm%c[_src]}" \
!   :: "r" ((void*) (base)), "r" ((__PTRDIFF_TYPE__) (stride)), [_src]"i"(src) \
!   : "memory")
  
  #define _tile_zero(dst)				\
    _tile_zero_internal (dst)
  
! #define _tile_zero_internal(dst)					\
!   __asm__ volatile							\
!   ("{tilezero\t%%tmm%c[_dst]|tilezero\ttmm%c[_dst]}" :: [_dst]"i"(dst))
  
  #endif
  
diff -Nrcpad gcc-13.4.0/gcc/config/i386/host-mingw32.cc gcc-13.5.0-RC-20260904/gcc/config/i386/host-mingw32.cc
*** gcc-13.4.0/gcc/config/i386/host-mingw32.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/host-mingw32.cc	Fri Sep  4 07:35:07 2026
*************** mingw32_gt_pch_use_address (void *&addr,
*** 135,141 ****
       and earlier, backslashes are invalid in object name.  So, we need
       to check if we are on Windows2000 or higher.  */
    OSVERSIONINFO version_info;
-   int r;
  
    version_info.dwOSVersionInfoSize = sizeof (version_info);
  
--- 135,140 ----
*************** mingw32_gt_pch_use_address (void *&addr,
*** 169,193 ****
        return -1; 
      }
  
!   /* Retry five times, as here might occure a race with multiple gcc's
!      instances at same time.  */
!   for (r = 0; r < 5; r++)
!    {
!       mmap_addr = MapViewOfFileEx (mmap_handle, FILE_MAP_COPY, 0, offset,
! 				   size, addr);
!       if (mmap_addr == addr)
! 	break;
!       if (r != 4)
!         Sleep (500);
!    }
!       
!   if (mmap_addr != addr)
      {
!       w32_error (__FUNCTION__, __FILE__, __LINE__, "MapViewOfFileEx");
!       CloseHandle(mmap_handle);
!       return  -1;
      }
  
    return 1;
  }
  
--- 168,191 ----
        return -1; 
      }
  
!   /* Try mapping the file at `addr`.  */
!   mmap_addr = MapViewOfFileEx (mmap_handle, FILE_MAP_COPY, 0, offset,
! 			       size, addr);
!   if (mmap_addr == NULL)
      {
!       /* We could not map the file at its original address, so let the
! 	 system choose a different one. The PCH can be relocated later.  */
!       mmap_addr = MapViewOfFileEx (mmap_handle, FILE_MAP_COPY, 0, offset,
! 				   size, NULL);
!       if (mmap_addr == NULL)
! 	{
! 	  w32_error (__FUNCTION__, __FILE__, __LINE__, "MapViewOfFileEx");
! 	  CloseHandle(mmap_handle);
! 	  return  -1;
! 	}
      }
  
+   addr = mmap_addr;
    return 1;
  }
  
diff -Nrcpad gcc-13.4.0/gcc/config/i386/i386-expand.cc gcc-13.5.0-RC-20260904/gcc/config/i386/i386-expand.cc
*** gcc-13.4.0/gcc/config/i386/i386-expand.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/i386-expand.cc	Fri Sep  4 07:35:07 2026
*************** ix86_expand_builtin (tree exp, rtx targe
*** 13170,13176 ****
  	for (i = 0; i < 3; i++)
  	  xmm_regs[i] = gen_rtx_REG (V2DImode, GET_SSE_REGNO (i));
  
! 	if (target == 0)
  	  target = gen_reg_rtx (SImode);
  
  	emit_insn (gen_encodekey128u32 (target, op0));
--- 13170,13176 ----
  	for (i = 0; i < 3; i++)
  	  xmm_regs[i] = gen_rtx_REG (V2DImode, GET_SSE_REGNO (i));
  
! 	if (target == 0 || !register_operand (target, SImode))
  	  target = gen_reg_rtx (SImode);
  
  	emit_insn (gen_encodekey128u32 (target, op0));
*************** ix86_expand_builtin (tree exp, rtx targe
*** 13213,13219 ****
  	for (i = 0; i < 4; i++)
  	  xmm_regs[i] = gen_rtx_REG (V2DImode, GET_SSE_REGNO (i));
  
! 	if (target == 0)
  	  target = gen_reg_rtx (SImode);
  
  	emit_insn (gen_encodekey256u32 (target, op0));
--- 13213,13219 ----
  	for (i = 0; i < 4; i++)
  	  xmm_regs[i] = gen_rtx_REG (V2DImode, GET_SSE_REGNO (i));
  
! 	if (target == 0 || !register_operand (target, SImode))
  	  target = gen_reg_rtx (SImode);
  
  	emit_insn (gen_encodekey256u32 (target, op0));
*************** ix86_expand_vector_set (bool mmx_ok, rtx
*** 16724,16729 ****
--- 16724,16734 ----
    machine_mode mmode = VOIDmode;
    rtx (*gen_blendm) (rtx, rtx, rtx, rtx);
  
+   if (!IN_RANGE (elt, 0, GET_MODE_NUNITS (mode)))
+     {
+       emit_move_insn (target, target);
+       return;
+     }
    switch (mode)
      {
      case E_V2SImode:
diff -Nrcpad gcc-13.4.0/gcc/config/i386/i386.cc gcc-13.5.0-RC-20260904/gcc/config/i386/i386.cc
*** gcc-13.4.0/gcc/config/i386/i386.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/i386.cc	Fri Sep  4 07:35:07 2026
*************** static GTY(()) rtx ix86_tls_symbol;
*** 11502,11507 ****
--- 11502,11527 ----
  static rtx
  ix86_tls_get_addr (void)
  {
+   if (cfun->machine->no_caller_saved_registers)
+     {
+       /* __tls_get_addr doesn't preserve vector registers.  When a
+ 	 function with no_caller_saved_registers attribute calls
+ 	 __tls_get_addr, YMM and ZMM registers will be clobbered.
+ 	 Issue an error and suggest -mtls-dialect=gnu2 in this case.  */
+       if (cfun->machine->func_type == TYPE_NORMAL)
+ 	error (G_("%<-mtls-dialect=gnu2%> must be used with a function"
+ 		  " with the % attribute"));
+       else
+ 	error (cfun->machine->func_type == TYPE_EXCEPTION
+ 	       ? G_("%<-mtls-dialect=gnu2%> must be used with an"
+ 		    " exception service routine")
+ 	       : G_("%<-mtls-dialect=gnu2%> must be used with an"
+ 		    " interrupt service routine"));
+       /* Don't issue the same error twice.  */
+       cfun->machine->func_type = TYPE_NORMAL;
+       cfun->machine->no_caller_saved_registers = false;
+     }
+ 
    if (!ix86_tls_symbol)
      {
        const char *sym
*************** legitimize_tls_address (rtx x, enum tls_
*** 11601,11611 ****
  	  if (TARGET_64BIT)
  	    {
  	      rtx rax = gen_rtx_REG (Pmode, AX_REG);
  	      rtx_insn *insns;
  
  	      start_sequence ();
  	      emit_call_insn
! 		(gen_tls_global_dynamic_64 (Pmode, rax, x, caddr));
  	      insns = get_insns ();
  	      end_sequence ();
  
--- 11621,11632 ----
  	  if (TARGET_64BIT)
  	    {
  	      rtx rax = gen_rtx_REG (Pmode, AX_REG);
+ 	      rtx rdi = gen_rtx_REG (Pmode, DI_REG);
  	      rtx_insn *insns;
  
  	      start_sequence ();
  	      emit_call_insn
! 		(gen_tls_global_dynamic_64 (Pmode, rax, x, caddr, rdi));
  	      insns = get_insns ();
  	      end_sequence ();
  
*************** legitimize_tls_address (rtx x, enum tls_
*** 11655,11666 ****
  	  if (TARGET_64BIT)
  	    {
  	      rtx rax = gen_rtx_REG (Pmode, AX_REG);
  	      rtx_insn *insns;
  	      rtx eqv;
  
  	      start_sequence ();
  	      emit_call_insn
! 		(gen_tls_local_dynamic_base_64 (Pmode, rax, caddr));
  	      insns = get_insns ();
  	      end_sequence ();
  
--- 11676,11688 ----
  	  if (TARGET_64BIT)
  	    {
  	      rtx rax = gen_rtx_REG (Pmode, AX_REG);
+ 	      rtx rdi = gen_rtx_REG (Pmode, DI_REG);
  	      rtx_insn *insns;
  	      rtx eqv;
  
  	      start_sequence ();
  	      emit_call_insn
! 		(gen_tls_local_dynamic_base_64 (Pmode, rax, caddr, rdi));
  	      insns = get_insns ();
  	      end_sequence ();
  
*************** avx_vpermilp_parallel (rtx par, machine_
*** 19302,19308 ****
  	}
        for (i = 2; i < 4; ++i)
  	{
! 	  if (ipar[i] < 2)
  	    return 0;
  	  mask |= (ipar[i] - 2) << i;
  	}
--- 19324,19330 ----
  	}
        for (i = 2; i < 4; ++i)
  	{
! 	  if (ipar[i] < 2 || ipar[i] >= 4)
  	    return 0;
  	  mask |= (ipar[i] - 2) << i;
  	}
diff -Nrcpad gcc-13.4.0/gcc/config/i386/i386.h gcc-13.5.0-RC-20260904/gcc/config/i386/i386.h
*** gcc-13.4.0/gcc/config/i386/i386.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/i386.h	Fri Sep  4 07:35:07 2026
*************** constexpr wide_int_bitmask PTA_GOLDMONT_
*** 2362,2373 ****
    | PTA_SGX | PTA_PTWRITE;
  constexpr wide_int_bitmask PTA_TREMONT = PTA_GOLDMONT_PLUS | PTA_CLWB
    | PTA_GFNI | PTA_MOVDIRI | PTA_MOVDIR64B | PTA_CLDEMOTE | PTA_WAITPKG;
! constexpr wide_int_bitmask PTA_ALDERLAKE = PTA_TREMONT | PTA_ADX | PTA_AVX
    | PTA_AVX2 | PTA_BMI | PTA_BMI2 | PTA_F16C | PTA_FMA | PTA_LZCNT
    | PTA_PCONFIG | PTA_PKU | PTA_VAES | PTA_VPCLMULQDQ | PTA_SERIALIZE
    | PTA_HRESET | PTA_KL | PTA_WIDEKL | PTA_AVXVNNI;
! constexpr wide_int_bitmask PTA_SIERRAFOREST = PTA_ALDERLAKE | PTA_AVXIFMA
!   | PTA_AVXVNNIINT8 | PTA_AVXNECONVERT | PTA_CMPCCXADD | PTA_ENQCMD | PTA_UINTR;
  constexpr wide_int_bitmask PTA_GRANITERAPIDS = PTA_SAPPHIRERAPIDS | PTA_AMX_FP16
    | PTA_PREFETCHI;
  constexpr wide_int_bitmask PTA_GRANITERAPIDS_D = PTA_GRANITERAPIDS
--- 2362,2375 ----
    | PTA_SGX | PTA_PTWRITE;
  constexpr wide_int_bitmask PTA_TREMONT = PTA_GOLDMONT_PLUS | PTA_CLWB
    | PTA_GFNI | PTA_MOVDIRI | PTA_MOVDIR64B | PTA_CLDEMOTE | PTA_WAITPKG;
! constexpr wide_int_bitmask PTA_ALDERLAKE = PTA_GOLDMONT_PLUS | PTA_CLWB
!   | PTA_GFNI | PTA_MOVDIRI | PTA_MOVDIR64B | PTA_WAITPKG | PTA_ADX | PTA_AVX
    | PTA_AVX2 | PTA_BMI | PTA_BMI2 | PTA_F16C | PTA_FMA | PTA_LZCNT
    | PTA_PCONFIG | PTA_PKU | PTA_VAES | PTA_VPCLMULQDQ | PTA_SERIALIZE
    | PTA_HRESET | PTA_KL | PTA_WIDEKL | PTA_AVXVNNI;
! constexpr wide_int_bitmask PTA_SIERRAFOREST = PTA_ALDERLAKE | PTA_CLDEMOTE
!   | PTA_AVXIFMA | PTA_AVXVNNIINT8 | PTA_AVXNECONVERT | PTA_CMPCCXADD
!   | PTA_ENQCMD | PTA_UINTR;
  constexpr wide_int_bitmask PTA_GRANITERAPIDS = PTA_SAPPHIRERAPIDS | PTA_AMX_FP16
    | PTA_PREFETCHI;
  constexpr wide_int_bitmask PTA_GRANITERAPIDS_D = PTA_GRANITERAPIDS
diff -Nrcpad gcc-13.4.0/gcc/config/i386/i386.md gcc-13.5.0-RC-20260904/gcc/config/i386/i386.md
*** gcc-13.4.0/gcc/config/i386/i386.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/i386.md	Fri Sep  4 07:35:07 2026
***************
*** 2184,2205 ****
     (set_attr "mode" "SI")
     (set_attr "length_immediate" "0")])
  
! (define_insn "*mov_and"
    [(set (match_operand:SWI248 0 "memory_operand" "=m")
  	(match_operand:SWI248 1 "const0_operand"))
     (clobber (reg:CC FLAGS_REG))]
    "reload_completed"
    "and{}\t{%1, %0|%0, %1}"
    [(set_attr "type" "alu1")
     (set_attr "mode" "")
     (set_attr "length_immediate" "1")])
  
! (define_insn "*mov_or"
    [(set (match_operand:SWI248 0 "nonimmediate_operand" "=rm")
  	(match_operand:SWI248 1 "constm1_operand"))
     (clobber (reg:CC FLAGS_REG))]
    "reload_completed"
    "or{}\t{%1, %0|%0, %1}"
    [(set_attr "type" "alu1")
     (set_attr "mode" "")
     (set_attr "length_immediate" "1")])
--- 2184,2215 ----
     (set_attr "mode" "SI")
     (set_attr "length_immediate" "0")])
  
! ;; Generate shorter "and $0,mem" for -Oz.  Split it to "mov $0,mem"
! ;; otherwise.
! (define_insn_and_split "*mov_and"
    [(set (match_operand:SWI248 0 "memory_operand" "=m")
  	(match_operand:SWI248 1 "const0_operand"))
     (clobber (reg:CC FLAGS_REG))]
    "reload_completed"
    "and{}\t{%1, %0|%0, %1}"
+   "&& !(optimize_insn_for_size_p () && optimize_size > 1)"
+   [(set (match_dup 0) (match_dup 1))]
+   ""
    [(set_attr "type" "alu1")
     (set_attr "mode" "")
     (set_attr "length_immediate" "1")])
  
! ;; Generate shorter "or $-1,mem" for -Oz.  Split it to "mov $-1,mem"
! ;; otherwise.
! (define_insn_and_split "*mov_or"
    [(set (match_operand:SWI248 0 "nonimmediate_operand" "=rm")
  	(match_operand:SWI248 1 "constm1_operand"))
     (clobber (reg:CC FLAGS_REG))]
    "reload_completed"
    "or{}\t{%1, %0|%0, %1}"
+   "&& !(optimize_insn_for_size_p () && optimize_size > 1)"
+   [(set (match_dup 0) (match_dup 1))]
+   ""
    [(set_attr "type" "alu1")
     (set_attr "mode" "")
     (set_attr "length_immediate" "1")])
***************
*** 2680,2685 ****
--- 2690,2697 ----
  	(match_operand:SWI248 1 "const_int_operand"))]
    "optimize_insn_for_size_p () && optimize_size > 1
     && operands[1] != const0_rtx
+    && (operands[1] != constm1_rtx
+        || (mode == DImode && LEGACY_INT_REG_P (operands[0])))
     && IN_RANGE (INTVAL (operands[1]), -128, 127)
     && !ix86_red_zone_used
     && REGNO (operands[0]) != SP_REG"
***************
*** 4548,4554 ****
    "TARGET_64BIT"
    "@
     {cltq|cdqe}
!    movs{lq|x}\t{%1, %0|%0, %1}"
    [(set_attr "type" "imovx")
     (set_attr "mode" "DI")
     (set_attr "prefix_0f" "0")
--- 4560,4566 ----
    "TARGET_64BIT"
    "@
     {cltq|cdqe}
!    movs{lq|xd}\t{%1, %0|%0, %1}"
    [(set_attr "type" "imovx")
     (set_attr "mode" "DI")
     (set_attr "prefix_0f" "0")
***************
*** 18621,18627 ****
  	 (match_operand 3)))
     (unspec:P [(match_operand 1 "tls_symbolic_operand")
  	      (reg:P SP_REG)]
! 	     UNSPEC_TLS_GD)]
    "TARGET_64BIT"
  {
    if (!TARGET_X32)
--- 18633,18640 ----
  	 (match_operand 3)))
     (unspec:P [(match_operand 1 "tls_symbolic_operand")
  	      (reg:P SP_REG)]
! 	     UNSPEC_TLS_GD)
!    (clobber (match_operand:P 4 "register_operand" "=D"))]
    "TARGET_64BIT"
  {
    if (!TARGET_X32)
***************
*** 18638,18644 ****
         Use data16 prefix instead, which doesn't have this problem.  */
      fputs ("\tdata16", asm_out_file);
    output_asm_insn
!     ("lea{q}\t{%E1@tlsgd(%%rip), %%rdi|rdi, %E1@tlsgd[rip]}", operands);
    if (TARGET_SUN_TLS || flag_plt || !HAVE_AS_IX86_TLS_GET_ADDR_GOT)
      fputs (ASM_SHORT "0x6666\n", asm_out_file);
    else
--- 18651,18657 ----
         Use data16 prefix instead, which doesn't have this problem.  */
      fputs ("\tdata16", asm_out_file);
    output_asm_insn
!     ("lea{q}\t{%E1@tlsgd(%%rip), %q4|%q4, %E1@tlsgd[rip]}", operands);
    if (TARGET_SUN_TLS || flag_plt || !HAVE_AS_IX86_TLS_GET_ADDR_GOT)
      fputs (ASM_SHORT "0x6666\n", asm_out_file);
    else
***************
*** 18662,18675 ****
  	 (match_operand 4)))
     (unspec:DI [(match_operand 1 "tls_symbolic_operand")
  	       (reg:DI SP_REG)]
! 	      UNSPEC_TLS_GD)]
    "TARGET_64BIT && ix86_cmodel == CM_LARGE_PIC && !TARGET_PECOFF
     && GET_CODE (operands[3]) == CONST
     && GET_CODE (XEXP (operands[3], 0)) == UNSPEC
     && XINT (XEXP (operands[3], 0), 1) == UNSPEC_PLTOFF"
  {
    output_asm_insn
!     ("lea{q}\t{%E1@tlsgd(%%rip), %%rdi|rdi, %E1@tlsgd[rip]}", operands);
    output_asm_insn ("movabs{q}\t{%3, %%rax|rax, %3}", operands);
    output_asm_insn ("add{q}\t{%2, %%rax|rax, %2}", operands);
    return "call\t{*%%rax|rax}";
--- 18675,18689 ----
  	 (match_operand 4)))
     (unspec:DI [(match_operand 1 "tls_symbolic_operand")
  	       (reg:DI SP_REG)]
! 	      UNSPEC_TLS_GD)
!    (clobber (match_operand:DI 5 "register_operand" "=D"))]
    "TARGET_64BIT && ix86_cmodel == CM_LARGE_PIC && !TARGET_PECOFF
     && GET_CODE (operands[3]) == CONST
     && GET_CODE (XEXP (operands[3], 0)) == UNSPEC
     && XINT (XEXP (operands[3], 0), 1) == UNSPEC_PLTOFF"
  {
    output_asm_insn
!     ("lea{q}\t{%E1@tlsgd(%%rip), %5|%5, %E1@tlsgd[rip]}", operands);
    output_asm_insn ("movabs{q}\t{%3, %%rax|rax, %3}", operands);
    output_asm_insn ("add{q}\t{%2, %%rax|rax, %2}", operands);
    return "call\t{*%%rax|rax}";
***************
*** 18685,18691 ****
  	   (const_int 0)))
       (unspec:P [(match_operand 1 "tls_symbolic_operand")
  		(reg:P SP_REG)]
! 	       UNSPEC_TLS_GD)])]
    "TARGET_64BIT"
    "ix86_tls_descriptor_calls_expanded_in_cfun = true;")
  
--- 18699,18706 ----
  	   (const_int 0)))
       (unspec:P [(match_operand 1 "tls_symbolic_operand")
  		(reg:P SP_REG)]
! 	       UNSPEC_TLS_GD)
!      (clobber (match_operand:P 3 "register_operand"))])]
    "TARGET_64BIT"
    "ix86_tls_descriptor_calls_expanded_in_cfun = true;")
  
***************
*** 18736,18746 ****
  	(call:P
  	 (mem:QI (match_operand 1 "constant_call_address_operand" "Bz"))
  	 (match_operand 2)))
!    (unspec:P [(reg:P SP_REG)] UNSPEC_TLS_LD_BASE)]
    "TARGET_64BIT"
  {
    output_asm_insn
!     ("lea{q}\t{%&@tlsld(%%rip), %%rdi|rdi, %&@tlsld[rip]}", operands);
    if (TARGET_SUN_TLS)
      return "call\t%p1@plt";
    if (flag_plt || !HAVE_AS_IX86_TLS_GET_ADDR_GOT)
--- 18751,18762 ----
  	(call:P
  	 (mem:QI (match_operand 1 "constant_call_address_operand" "Bz"))
  	 (match_operand 2)))
!    (unspec:P [(reg:P SP_REG)] UNSPEC_TLS_LD_BASE)
!    (clobber (match_operand:P 3 "register_operand" "=D"))]
    "TARGET_64BIT"
  {
    output_asm_insn
!     ("lea{q}\t{%&@tlsld(%%rip), %q3|%q3, %&@tlsld[rip]}", operands);
    if (TARGET_SUN_TLS)
      return "call\t%p1@plt";
    if (flag_plt || !HAVE_AS_IX86_TLS_GET_ADDR_GOT)
***************
*** 18756,18769 ****
  	 (mem:QI (plus:DI (match_operand:DI 1 "register_operand" "b")
  			  (match_operand:DI 2 "immediate_operand" "i")))
  	 (match_operand 3)))
!    (unspec:DI [(reg:DI SP_REG)] UNSPEC_TLS_LD_BASE)]
    "TARGET_64BIT && ix86_cmodel == CM_LARGE_PIC && !TARGET_PECOFF
     && GET_CODE (operands[2]) == CONST
     && GET_CODE (XEXP (operands[2], 0)) == UNSPEC
     && XINT (XEXP (operands[2], 0), 1) == UNSPEC_PLTOFF"
  {
    output_asm_insn
!     ("lea{q}\t{%&@tlsld(%%rip), %%rdi|rdi, %&@tlsld[rip]}", operands);
    output_asm_insn ("movabs{q}\t{%2, %%rax|rax, %2}", operands);
    output_asm_insn ("add{q}\t{%1, %%rax|rax, %1}", operands);
    return "call\t{*%%rax|rax}";
--- 18772,18786 ----
  	 (mem:QI (plus:DI (match_operand:DI 1 "register_operand" "b")
  			  (match_operand:DI 2 "immediate_operand" "i")))
  	 (match_operand 3)))
!    (unspec:DI [(reg:DI SP_REG)] UNSPEC_TLS_LD_BASE)
!    (clobber (match_operand:DI 4 "register_operand" "=D"))]
    "TARGET_64BIT && ix86_cmodel == CM_LARGE_PIC && !TARGET_PECOFF
     && GET_CODE (operands[2]) == CONST
     && GET_CODE (XEXP (operands[2], 0)) == UNSPEC
     && XINT (XEXP (operands[2], 0), 1) == UNSPEC_PLTOFF"
  {
    output_asm_insn
!     ("lea{q}\t{%&@tlsld(%%rip), %4|%4, %&@tlsld[rip]}", operands);
    output_asm_insn ("movabs{q}\t{%2, %%rax|rax, %2}", operands);
    output_asm_insn ("add{q}\t{%1, %%rax|rax, %1}", operands);
    return "call\t{*%%rax|rax}";
***************
*** 18777,18783 ****
  	   (call:P
  	    (mem:QI (match_operand 1))
  	    (const_int 0)))
!       (unspec:P [(reg:P SP_REG)] UNSPEC_TLS_LD_BASE)])]
    "TARGET_64BIT"
    "ix86_tls_descriptor_calls_expanded_in_cfun = true;")
  
--- 18794,18801 ----
  	   (call:P
  	    (mem:QI (match_operand 1))
  	    (const_int 0)))
!       (unspec:P [(reg:P SP_REG)] UNSPEC_TLS_LD_BASE)
!       (clobber (match_operand:P 2 "register_operand"))])]
    "TARGET_64BIT"
    "ix86_tls_descriptor_calls_expanded_in_cfun = true;")
  
***************
*** 22944,22950 ****
    DONE;
  })
  
- 
  ;; Avoid redundant prefixes by splitting HImode arithmetic to SImode.
  ;; Do not split instructions with mask registers.
  (define_split
--- 22962,22967 ----
***************
*** 24973,24979 ****
  		     (match_operand:SWI48 1 "memory_operand" "m")]
  		    UNSPECV_WRSS)]
    "TARGET_SHSTK"
!   "wrss\t%0, %1"
    [(set_attr "length" "3")
     (set_attr "type" "other")])
  
--- 24990,24996 ----
  		     (match_operand:SWI48 1 "memory_operand" "m")]
  		    UNSPECV_WRSS)]
    "TARGET_SHSTK"
!   "wrss\t{%0, %1|%1, %0}"
    [(set_attr "length" "3")
     (set_attr "type" "other")])
  
***************
*** 24982,24988 ****
  		     (match_operand:SWI48 1 "memory_operand" "m")]
  		    UNSPECV_WRUSS)]
    "TARGET_SHSTK"
!   "wruss\t%0, %1"
    [(set_attr "length" "4")
     (set_attr "type" "other")])
  
--- 24999,25005 ----
  		     (match_operand:SWI48 1 "memory_operand" "m")]
  		    UNSPECV_WRUSS)]
    "TARGET_SHSTK"
!   "wruss\t{%0, %1|%1, %0}"
    [(set_attr "length" "4")
     (set_attr "type" "other")])
  
diff -Nrcpad gcc-13.4.0/gcc/config/i386/sse.md gcc-13.5.0-RC-20260904/gcc/config/i386/sse.md
*** gcc-13.4.0/gcc/config/i386/sse.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/sse.md	Fri Sep  4 07:35:07 2026
***************
*** 987,1003 ****
     (V16SF "hi") (V8SF  "qi") (V4SF  "qi")
     (V8DF  "qi") (V4DF  "qi") (V2DF  "qi")])
  
- ;; Mapping of vector modes to corresponding mask half size
- (define_mode_attr avx512fmaskhalfmode
-   [(V64QI "SI") (V32QI "HI") (V16QI "QI")
-    (V32HI "HI") (V16HI "QI") (V8HI  "QI") (V4HI "QI")
-    (V16SI "QI") (V8SI  "QI") (V4SI  "QI")
-    (V8DI  "QI") (V4DI  "QI") (V2DI  "QI")
-    (V32HF "HI") (V16HF "QI") (V8HF  "QI")
-    (V32BF "HI") (V16BF "QI") (V8BF  "QI")
-    (V16SF "QI") (V8SF  "QI") (V4SF  "QI")
-    (V8DF  "QI") (V4DF  "QI") (V2DF  "QI")])
- 
  ;; Mapping of vector float modes to an integer mode of the same size
  (define_mode_attr sseintvecmode
    [(V32HF "V32HI") (V32BF "V32HI") (V16SF "V16SI") (V8DF  "V8DI")
--- 987,992 ----
***************
*** 1529,1535 ****
  	  (match_operand: 4 "const0_operand")
  	  (const_int 1)))]
    "TARGET_AVX512F"
!   "vmov\t{%1, %0%{%3%}%N2|%0%{3%}%N2, %1}"
    [(set_attr "type" "ssemov")
     (set_attr "prefix" "evex")
     (set_attr "memory" "load")
--- 1518,1524 ----
  	  (match_operand: 4 "const0_operand")
  	  (const_int 1)))]
    "TARGET_AVX512F"
!   "vmov\t{%1, %0%{%3%}%N2|%0%{%3%}%N2, %1}"
    [(set_attr "type" "ssemov")
     (set_attr "prefix" "evex")
     (set_attr "memory" "load")
***************
*** 6109,6115 ****
  	  (match_dup 3)
  	  (const_int 1)))]
    "TARGET_AVX512F"
!   "vfmadd231\t{%2, %1, %0%{%4%}|%0%{%4%}, %3, %2}"
    [(set_attr "type" "ssemuladd")
     (set_attr "mode" "")])
  
--- 6098,6104 ----
  	  (match_dup 3)
  	  (const_int 1)))]
    "TARGET_AVX512F"
!   "vfmadd231\t{%2, %1, %0%{%4%}|%0%{%4%}, %1, %2}"
    [(set_attr "type" "ssemuladd")
     (set_attr "mode" "")])
  
***************
*** 6180,6186 ****
  	  (match_dup 3)
  	  (const_int 1)))]
    "TARGET_AVX512F"
!   "vfmsub231\t{%2, %1, %0%{%4%}|%0%{%4%}, %3, %2}"
    [(set_attr "type" "ssemuladd")
     (set_attr "mode" "")])
  
--- 6169,6175 ----
  	  (match_dup 3)
  	  (const_int 1)))]
    "TARGET_AVX512F"
!   "vfmsub231\t{%2, %1, %0%{%4%}|%0%{%4%}, %1, %2}"
    [(set_attr "type" "ssemuladd")
     (set_attr "mode" "")])
  
***************
*** 6238,6244 ****
  	  (match_dup 3)
  	  (const_int 1)))]
    "TARGET_AVX512F"
!   "vfnmadd231\t{%2, %1, %0%{%4%}|%0%{%4%}, %3, %2}"
    [(set_attr "type" "ssemuladd")
     (set_attr "mode" "")])
  
--- 6227,6233 ----
  	  (match_dup 3)
  	  (const_int 1)))]
    "TARGET_AVX512F"
!   "vfnmadd231\t{%2, %1, %0%{%4%}|%0%{%4%}, %1, %2}"
    [(set_attr "type" "ssemuladd")
     (set_attr "mode" "")])
  
***************
*** 6312,6318 ****
  	  (match_dup 3)
  	  (const_int 1)))]
    "TARGET_AVX512F"
!   "vfnmsub231\t{%2, %1, %0%{%4%}|%0%{%4%}, %3, %2}"
    [(set_attr "type" "ssemuladd")
     (set_attr "mode" "")])
  
--- 6301,6307 ----
  	  (match_dup 3)
  	  (const_int 1)))]
    "TARGET_AVX512F"
!   "vfnmsub231\t{%2, %1, %0%{%4%}|%0%{%4%}, %1, %2}"
    [(set_attr "type" "ssemuladd")
     (set_attr "mode" "")])
  
***************
*** 20882,20890 ****
  	      (lshiftrt:
  		(mult:
  		  (sign_extend:
! 		    (match_operand:PMULHRSW 1 "nonimmediate_operand"))
  		  (sign_extend:
! 		    (match_operand:PMULHRSW 2 "nonimmediate_operand")))
  		(const_int 14))
  	      (match_dup 3))
  	    (const_int 1))))]
--- 20871,20879 ----
  	      (lshiftrt:
  		(mult:
  		  (sign_extend:
! 		    (match_operand:PMULHRSW 1 "vector_operand"))
  		  (sign_extend:
! 		    (match_operand:PMULHRSW 2 "vector_operand")))
  		(const_int 14))
  	      (match_dup 3))
  	    (const_int 1))))]
***************
*** 20902,20910 ****
  	      (lshiftrt:
  		(mult:
  		  (sign_extend:
! 		    (match_operand:VI2_AVX2 1 "nonimmediate_operand"))
  		  (sign_extend:
! 		    (match_operand:VI2_AVX2 2 "nonimmediate_operand")))
  		(const_int 14))
  	      (match_dup 3))
  	    (const_int 1))))]
--- 20891,20899 ----
  	      (lshiftrt:
  		(mult:
  		  (sign_extend:
! 		    (match_operand:VI2_AVX2 1 "vector_operand"))
  		  (sign_extend:
! 		    (match_operand:VI2_AVX2 2 "vector_operand")))
  		(const_int 14))
  	      (match_dup 3))
  	    (const_int 1))))]
***************
*** 22016,22022 ****
     (set_attr "prefix" "orig,orig,maybe_evex")
     (set_attr "mode" "TI")])
  
! (define_insn_and_split "*sse4_1_v8qiv8hi2_2"
    [(set (match_operand:V8HI 0 "register_operand")
  	(any_extend:V8HI
  	  (vec_select:V8QI
--- 22005,22011 ----
     (set_attr "prefix" "orig,orig,maybe_evex")
     (set_attr "mode" "TI")])
  
! (define_insn_and_split "*sse4_1_v8qiv8hi2_2"
    [(set (match_operand:V8HI 0 "register_operand")
  	(any_extend:V8HI
  	  (vec_select:V8QI
***************
*** 22028,22034 ****
  		       (const_int 2) (const_int 3)
  		       (const_int 4) (const_int 5)
  		       (const_int 6) (const_int 7)]))))]
!   "TARGET_SSE4_1 &&  && 
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
--- 22017,22023 ----
  		       (const_int 2) (const_int 3)
  		       (const_int 4) (const_int 5)
  		       (const_int 6) (const_int 7)]))))]
!   "TARGET_SSE4_1
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
***************
*** 22036,22041 ****
--- 22025,22056 ----
  	(any_extend:V8HI (match_dup 1)))]
    "operands[1] = adjust_address_nv (operands[1], V8QImode, 0);")
  
+ (define_insn_and_split "*avx512vl_v8qiv8hi2_mask_2"
+   [(set (match_operand:V8HI 0 "register_operand")
+ 	(vec_merge:V8HI
+ 	  (any_extend:V8HI
+ 	    (vec_select:V8QI
+ 	      (subreg:V16QI
+ 		(vec_concat:V2DI
+ 		  (match_operand:DI 1 "memory_operand")
+ 		  (const_int 0)) 0)
+ 	      (parallel [(const_int 0) (const_int 1)
+ 			 (const_int 2) (const_int 3)
+ 		         (const_int 4) (const_int 5)
+ 		         (const_int 6) (const_int 7)])))
+ 	  (match_operand:V8HI 2 "nonimm_or_0_operand")
+ 	  (match_operand:QI 3 "register_operand")))]
+   "TARGET_AVX512VL && TARGET_AVX512BW
+    && ix86_pre_reload_split ()"
+   "#"
+   "&& 1"
+   [(set (match_dup 0)
+ 	(vec_merge:V8HI
+ 	  (any_extend:V8HI (match_dup 1))
+ 	  (match_dup 2)
+ 	  (match_dup 3)))]
+   "operands[1] = adjust_address_nv (operands[1], V8QImode, 0);")
+ 
  (define_insn_and_split "*sse4_1_zero_extendv8qiv8hi2_3"
    [(set (match_operand:V16QI 0 "register_operand" "=Yr,*x,Yw")
  	(vec_select:V16QI
***************
*** 22160,22166 ****
     (set_attr "prefix" "maybe_evex")
     (set_attr "mode" "OI")])
  
! (define_insn_and_split "*avx2_v8qiv8si2_2"
    [(set (match_operand:V8SI 0 "register_operand")
  	(any_extend:V8SI
  	  (vec_select:V8QI
--- 22175,22181 ----
     (set_attr "prefix" "maybe_evex")
     (set_attr "mode" "OI")])
  
! (define_insn_and_split "*avx2_v8qiv8si2_2"
    [(set (match_operand:V8SI 0 "register_operand")
  	(any_extend:V8SI
  	  (vec_select:V8QI
***************
*** 22172,22178 ****
  		       (const_int 2) (const_int 3)
  		       (const_int 4) (const_int 5)
  		       (const_int 6) (const_int 7)]))))]
!   "TARGET_AVX2 && 
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
--- 22187,22193 ----
  		       (const_int 2) (const_int 3)
  		       (const_int 4) (const_int 5)
  		       (const_int 6) (const_int 7)]))))]
!   "TARGET_AVX2
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
***************
*** 22180,22185 ****
--- 22195,22227 ----
  	(any_extend:V8SI (match_dup 1)))]
    "operands[1] = adjust_address_nv (operands[1], V8QImode, 0);")
  
+ (define_insn_and_split "*avx512vl_v8qiv8si2_mask_2"
+   [(set (match_operand:V8SI 0 "register_operand")
+ 	(vec_merge:V8SI
+ 	  (any_extend:V8SI
+ 	    (vec_select:V8QI
+ 	      (subreg:V16QI
+ 		(vec_concat:V2DI
+ 		  (match_operand:DI 1 "memory_operand")
+ 		  (const_int 0)) 0)
+ 	      (parallel [(const_int 0) (const_int 1)
+ 			 (const_int 2) (const_int 3)
+ 			 (const_int 4) (const_int 5)
+ 			 (const_int 6) (const_int 7)])))
+ 	  (match_operand:V8SI 2 "nonimm_or_0_operand")
+ 	  (match_operand:QI 3 "register_operand")))]
+   "TARGET_AVX512VL
+    && ix86_pre_reload_split ()"
+   "#"
+   "&& 1"
+   [(set (match_dup 0)
+ 	(vec_merge:V8SI
+ 	  (any_extend:V8SI (match_dup 1))
+ 	  (match_dup 2)
+ 	  (match_dup 3)))]
+   "operands[1] = adjust_address_nv (operands[1], V8QImode, 0);")
+ 
+ 
  (define_expand "v8qiv8si2"
    [(set (match_operand:V8SI 0 "register_operand")
  	(any_extend:V8SI
***************
*** 22222,22228 ****
     (set_attr "prefix" "orig,orig,maybe_evex")
     (set_attr "mode" "TI")])
  
! (define_insn_and_split "*sse4_1_v4qiv4si2_2"
    [(set (match_operand:V4SI 0 "register_operand")
  	(any_extend:V4SI
  	  (vec_select:V4QI
--- 22264,22270 ----
     (set_attr "prefix" "orig,orig,maybe_evex")
     (set_attr "mode" "TI")])
  
! (define_insn_and_split "*sse4_1_v4qiv4si2_2"
    [(set (match_operand:V4SI 0 "register_operand")
  	(any_extend:V4SI
  	  (vec_select:V4QI
***************
*** 22244,22249 ****
--- 22286,22320 ----
  	(any_extend:V4SI (match_dup 1)))]
    "operands[1] = adjust_address_nv (operands[1], V4QImode, 0);")
  
+ (define_insn_and_split "*avx512vl_v4qiv4si2_mask_2"
+   [(set (match_operand:V4SI 0 "register_operand")
+ 	(vec_merge:V4SI
+ 	  (any_extend:V4SI
+ 	    (vec_select:V4QI
+ 	      (subreg:V16QI
+ 		(vec_merge:V4SI
+ 		  (vec_duplicate:V4SI
+ 		    (match_operand:SI 1 "memory_operand"))
+ 		  (const_vector:V4SI
+ 		    [(const_int 0) (const_int 0)
+ 		     (const_int 0) (const_int 0)])
+ 		  (const_int 1)) 0)
+ 	      (parallel [(const_int 0) (const_int 1)
+ 			 (const_int 2) (const_int 3)])))
+ 	  (match_operand:V4SI 2 "nonimm_or_0_operand")
+ 	  (match_operand:QI 3 "register_operand")))]
+   "TARGET_AVX512VL
+    && ix86_pre_reload_split ()"
+   "#"
+   "&& 1"
+   [(set (match_dup 0)
+ 	(vec_merge:V4SI
+ 	  (any_extend:V4SI (match_dup 1))
+ 	  (match_dup 2)
+ 	  (match_dup 3)))]
+   "operands[1] = adjust_address_nv (operands[1], V4QImode, 0);")
+ 
+ 
  (define_expand "v4qiv4si2"
    [(set (match_operand:V4SI 0 "register_operand")
  	(any_extend:V4SI
***************
*** 22394,22400 ****
     (set_attr "prefix" "orig,orig,maybe_evex")
     (set_attr "mode" "TI")])
  
! (define_insn_and_split "*sse4_1_v4hiv4si2_2"
    [(set (match_operand:V4SI 0 "register_operand")
  	(any_extend:V4SI
  	  (vec_select:V4HI
--- 22465,22471 ----
     (set_attr "prefix" "orig,orig,maybe_evex")
     (set_attr "mode" "TI")])
  
! (define_insn_and_split "*sse4_1_v4hiv4si2_2"
    [(set (match_operand:V4SI 0 "register_operand")
  	(any_extend:V4SI
  	  (vec_select:V4HI
***************
*** 22404,22410 ****
  		(const_int 0)) 0)
  	    (parallel [(const_int 0) (const_int 1)
  		       (const_int 2) (const_int 3)]))))]
!   "TARGET_SSE4_1 && 
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
--- 22475,22481 ----
  		(const_int 0)) 0)
  	    (parallel [(const_int 0) (const_int 1)
  		       (const_int 2) (const_int 3)]))))]
!   "TARGET_SSE4_1
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
***************
*** 22412,22417 ****
--- 22483,22513 ----
  	(any_extend:V4SI (match_dup 1)))]
    "operands[1] = adjust_address_nv (operands[1], V4HImode, 0);")
  
+ (define_insn_and_split "*avx512vl_v4hiv4si2_mask_2"
+   [(set (match_operand:V4SI 0 "register_operand")
+ 	(vec_merge:V4SI
+ 	  (any_extend:V4SI
+ 	    (vec_select:V4HI
+ 	      (subreg:V8HI
+ 		(vec_concat:V2DI
+ 		  (match_operand:DI 1 "memory_operand")
+ 		  (const_int 0)) 0)
+ 	      (parallel [(const_int 0) (const_int 1)
+ 			 (const_int 2) (const_int 3)])))
+ 	  (match_operand:V4SI 2 "nonimm_or_0_operand")
+ 	  (match_operand:QI 3 "register_operand")))]
+   "TARGET_AVX512VL
+    && ix86_pre_reload_split ()"
+   "#"
+   "&& 1"
+   [(set (match_dup 0)
+ 	(vec_merge:V4SI
+ 	  (any_extend:V4SI (match_dup 1))
+ 	  (match_dup 2)
+ 	  (match_dup 3)))]
+   "operands[1] = adjust_address_nv (operands[1], V4HImode, 0);")
+ 
+ 
  (define_expand "v4hiv4si2"
    [(set (match_operand:V4SI 0 "register_operand")
  	(any_extend:V4SI
***************
*** 22514,22520 ****
     (set_attr "prefix" "evex")
     (set_attr "mode" "XI")])
  
! (define_insn_and_split "*avx512f_v8qiv8di2_2"
    [(set (match_operand:V8DI 0 "register_operand")
  	(any_extend:V8DI
  	  (vec_select:V8QI
--- 22610,22616 ----
     (set_attr "prefix" "evex")
     (set_attr "mode" "XI")])
  
! (define_insn_and_split "*avx512f_v8qiv8di2_2"
    [(set (match_operand:V8DI 0 "register_operand")
  	(any_extend:V8DI
  	  (vec_select:V8QI
***************
*** 22533,22538 ****
--- 22629,22660 ----
  	(any_extend:V8DI (match_dup 1)))]
    "operands[1] = adjust_address_nv (operands[1], V8QImode, 0);")
  
+ (define_insn_and_split "*avx512f_v8qiv8di2_mask_2"
+   [(set (match_operand:V8DI 0 "register_operand")
+ 	(vec_merge:V8DI
+ 	  (any_extend:V8DI
+ 	    (vec_select:V8QI
+ 	      (subreg:V16QI
+ 		(vec_concat:V2DI
+ 		  (match_operand:DI 1 "memory_operand")
+ 		  (const_int 0)) 0)
+ 	      (parallel [(const_int 0) (const_int 1)
+ 			 (const_int 2) (const_int 3)
+ 		         (const_int 4) (const_int 5)
+ 		         (const_int 6) (const_int 7)])))
+ 	  (match_operand:V8DI 2 "nonimm_or_0_operand")
+ 	  (match_operand:QI 3 "register_operand")))]
+   "TARGET_AVX512F && ix86_pre_reload_split ()"
+   "#"
+   "&& 1"
+   [(set (match_dup 0)
+ 	(vec_merge:V8DI
+ 	  (any_extend:V8DI (match_dup 1))
+ 	  (match_dup 2)
+ 	  (match_dup 3)))]
+   "operands[1] = adjust_address_nv (operands[1], V8QImode, 0);")
+ 
+ 
  (define_expand "v8qiv8di2"
    [(set (match_operand:V8DI 0 "register_operand")
  	(any_extend:V8DI
***************
*** 22573,22579 ****
     (set_attr "prefix" "maybe_evex")
     (set_attr "mode" "OI")])
  
! (define_insn_and_split "*avx2_v4qiv4di2_2"
    [(set (match_operand:V4DI 0 "register_operand")
  	(any_extend:V4DI
  	  (vec_select:V4QI
--- 22695,22701 ----
     (set_attr "prefix" "maybe_evex")
     (set_attr "mode" "OI")])
  
! (define_insn_and_split "*avx2_v4qiv4di2_2"
    [(set (match_operand:V4DI 0 "register_operand")
  	(any_extend:V4DI
  	  (vec_select:V4QI
***************
*** 22587,22593 ****
  		(const_int 1)) 0)
  	    (parallel [(const_int 0) (const_int 1)
  		       (const_int 2) (const_int 3)]))))]
!   "TARGET_AVX2 && 
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
--- 22709,22715 ----
  		(const_int 1)) 0)
  	    (parallel [(const_int 0) (const_int 1)
  		       (const_int 2) (const_int 3)]))))]
!   "TARGET_AVX2
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
***************
*** 22595,22600 ****
--- 22717,22751 ----
  	(any_extend:V4DI (match_dup 1)))]
    "operands[1] = adjust_address_nv (operands[1], V4QImode, 0);")
  
+ (define_insn_and_split "*avx512vl_v4qiv4di2_mask_2"
+   [(set (match_operand:V4DI 0 "register_operand")
+ 	(vec_merge:V4DI
+ 	  (any_extend:V4DI
+ 	    (vec_select:V4QI
+ 	      (subreg:V16QI
+ 		(vec_merge:V4SI
+ 		  (vec_duplicate:V4SI
+ 		    (match_operand:SI 1 "memory_operand"))
+ 		  (const_vector:V4SI
+ 		    [(const_int 0) (const_int 0)
+ 		     (const_int 0) (const_int 0)])
+ 		  (const_int 1)) 0)
+ 	      (parallel [(const_int 0) (const_int 1)
+ 			 (const_int 2) (const_int 3)])))
+ 	  (match_operand:V4DI 2 "nonimm_or_0_operand")
+ 	  (match_operand:QI 3 "register_operand")))]
+   "TARGET_AVX512VL
+    && ix86_pre_reload_split ()"
+   "#"
+   "&& 1"
+   [(set (match_dup 0)
+ 	(vec_merge:V4DI
+ 	  (any_extend:V4DI (match_dup 1))
+ 	  (match_dup 2)
+ 	  (match_dup 3)))]
+   "operands[1] = adjust_address_nv (operands[1], V4QImode, 0);")
+ 
+ 
  (define_expand "v4qiv4di2"
    [(set (match_operand:V4DI 0 "register_operand")
  	(any_extend:V4DI
***************
*** 22714,22720 ****
     (set_attr "prefix" "maybe_evex")
     (set_attr "mode" "OI")])
  
! (define_insn_and_split "*avx2_v4hiv4di2_2"
    [(set (match_operand:V4DI 0 "register_operand")
  	(any_extend:V4DI
  	  (vec_select:V4HI
--- 22865,22871 ----
     (set_attr "prefix" "maybe_evex")
     (set_attr "mode" "OI")])
  
! (define_insn_and_split "*avx2_v4hiv4di2_2"
    [(set (match_operand:V4DI 0 "register_operand")
  	(any_extend:V4DI
  	  (vec_select:V4HI
***************
*** 22724,22730 ****
  		(const_int 0)) 0)
  	    (parallel [(const_int 0) (const_int 1)
  		       (const_int 2) (const_int 3)]))))]
!   "TARGET_AVX2 && 
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
--- 22875,22881 ----
  		(const_int 0)) 0)
  	    (parallel [(const_int 0) (const_int 1)
  		       (const_int 2) (const_int 3)]))))]
!   "TARGET_AVX2
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
***************
*** 22732,22737 ****
--- 22883,22913 ----
  	(any_extend:V4DI (match_dup 1)))]
    "operands[1] = adjust_address_nv (operands[1], V4HImode, 0);")
  
+ (define_insn_and_split "*avx512vl_v4hiv4di2_mask_2"
+   [(set (match_operand:V4DI 0 "register_operand")
+ 	(vec_merge:V4DI
+ 	  (any_extend:V4DI
+ 	    (vec_select:V4HI
+ 	      (subreg:V8HI
+ 		(vec_concat:V2DI
+ 		  (match_operand:DI 1 "memory_operand")
+ 		  (const_int 0)) 0)
+ 	      (parallel [(const_int 0) (const_int 1)
+ 		         (const_int 2) (const_int 3)])))
+ 	  (match_operand:V4DI 2 "nonimm_or_0_operand")
+ 	  (match_operand:QI 3 "register_operand")))]
+   "TARGET_AVX512VL
+    && ix86_pre_reload_split ()"
+   "#"
+   "&& 1"
+   [(set (match_dup 0)
+ 	(vec_merge:V4DI
+ 	  (any_extend:V4DI (match_dup 1))
+ 	  (match_dup 2)
+ 	  (match_dup 3)))]
+   "operands[1] = adjust_address_nv (operands[1], V4HImode, 0);")
+ 
+ 
  (define_expand "v4hiv4di2"
    [(set (match_operand:V4DI 0 "register_operand")
  	(any_extend:V4DI
***************
*** 22773,22779 ****
     (set_attr "prefix" "orig,orig,maybe_evex")
     (set_attr "mode" "TI")])
  
! (define_insn_and_split "*sse4_1_v2hiv2di2_2"
    [(set (match_operand:V2DI 0 "register_operand")
  	(any_extend:V2DI
  	  (vec_select:V2HI
--- 22949,22955 ----
     (set_attr "prefix" "orig,orig,maybe_evex")
     (set_attr "mode" "TI")])
  
! (define_insn_and_split "*sse4_1_v2hiv2di2_2"
    [(set (match_operand:V2DI 0 "register_operand")
  	(any_extend:V2DI
  	  (vec_select:V2HI
***************
*** 22786,22792 ****
  		    (const_int 0) (const_int 0)])
  		(const_int 1)) 0)
  	    (parallel [(const_int 0) (const_int 1)]))))]
!   "TARGET_SSE4_1 && 
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
--- 22962,22968 ----
  		    (const_int 0) (const_int 0)])
  		(const_int 1)) 0)
  	    (parallel [(const_int 0) (const_int 1)]))))]
!   "TARGET_SSE4_1
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
***************
*** 22794,22799 ****
--- 22970,23003 ----
  	(any_extend:V2DI (match_dup 1)))]
    "operands[1] = adjust_address_nv (operands[1], V2HImode, 0);")
  
+ (define_insn_and_split "*avx512vl_v2hiv2di2_mask_2"
+   [(set (match_operand:V2DI 0 "register_operand")
+ 	(vec_merge:V2DI
+ 	  (any_extend:V2DI
+ 	    (vec_select:V2HI
+ 	      (subreg:V8HI
+ 		(vec_merge:V4SI
+ 		  (vec_duplicate:V4SI
+ 		    (match_operand:SI 1 "memory_operand"))
+ 		  (const_vector:V4SI
+ 		    [(const_int 0) (const_int 0)
+ 		     (const_int 0) (const_int 0)])
+ 		  (const_int 1)) 0)
+ 	      (parallel [(const_int 0) (const_int 1)])))
+ 	  (match_operand:V2DI 2 "nonimm_or_0_operand")
+ 	  (match_operand:QI 3 "register_operand")))]
+   "TARGET_AVX512VL
+    && ix86_pre_reload_split ()"
+   "#"
+   "&& 1"
+   [(set (match_dup 0)
+ 	(vec_merge:V2DI
+ 	  (any_extend:V2DI (match_dup 1))
+ 	  (match_dup 2)
+ 	  (match_dup 3)))]
+   "operands[1] = adjust_address_nv (operands[1], V2HImode, 0);")
+ 
+ 
  (define_expand "v2hiv2di2"
    [(set (match_operand:V2DI 0 "register_operand")
  	(any_extend:V2DI
***************
*** 22938,22944 ****
     (set_attr "prefix" "orig,orig,maybe_evex")
     (set_attr "mode" "TI")])
  
! (define_insn_and_split "*sse4_1_v2siv2di2_2"
    [(set (match_operand:V2DI 0 "register_operand")
  	(any_extend:V2DI
  	  (vec_select:V2SI
--- 23142,23148 ----
     (set_attr "prefix" "orig,orig,maybe_evex")
     (set_attr "mode" "TI")])
  
! (define_insn_and_split "*sse4_1_v2siv2di2_2"
    [(set (match_operand:V2DI 0 "register_operand")
  	(any_extend:V2DI
  	  (vec_select:V2SI
***************
*** 22947,22953 ****
  		(match_operand:DI 1 "memory_operand")
  		(const_int 0)) 0)
  	    (parallel [(const_int 0) (const_int 1)]))))]
!   "TARGET_SSE4_1 && 
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
--- 23151,23157 ----
  		(match_operand:DI 1 "memory_operand")
  		(const_int 0)) 0)
  	    (parallel [(const_int 0) (const_int 1)]))))]
!   "TARGET_SSE4_1
     && ix86_pre_reload_split ()"
    "#"
    "&& 1"
***************
*** 22955,22960 ****
--- 23159,23187 ----
  	(any_extend:V2DI (match_dup 1)))]
    "operands[1] = adjust_address_nv (operands[1], V2SImode, 0);")
  
+ (define_insn_and_split "*avx512vl_v2siv2di2_mask_2"
+   [(set (match_operand:V2DI 0 "register_operand")
+ 	(vec_merge:V2DI
+ 	  (any_extend:V2DI
+ 	    (vec_select:V2SI
+ 	      (subreg:V4SI
+ 		(vec_concat:V2DI
+ 		  (match_operand:DI 1 "memory_operand")
+ 		  (const_int 0)) 0)
+ 	      (parallel [(const_int 0) (const_int 1)])))
+ 	  (match_operand:V2DI 2 "nonimm_or_0_operand")
+ 	  (match_operand:QI 3 "register_operand")))]
+   "TARGET_AVX512VL
+    && ix86_pre_reload_split ()"
+   "#"
+   "&& 1"
+   [(set (match_dup 0)
+ 	(vec_merge:V2DI
+ 	  (any_extend:V2DI (match_dup 1))
+ 	  (match_dup 2)
+ 	  (match_dup 3)))]
+   "operands[1] = adjust_address_nv (operands[1], V2SImode, 0);")
+ 
  (define_insn_and_split "*sse4_1_zero_extendv2siv2di2_3"
    [(set (match_operand:V4SI 0 "register_operand" "=Yr,*x,v")
  	(vec_select:V4SI
***************
*** 28993,28999 ****
     (match_operand:VF1_AVX512VL 1 "register_operand")
     (match_operand: 2 "register_operand")
     (match_operand: 3 "register_operand")
!    (match_operand: 4 "register_operand")]
    "TARGET_AVX512BF16"
  {
    emit_insn (gen_avx512f_dpbf16ps__maskz_1(operands[0], operands[1],
--- 29220,29226 ----
     (match_operand:VF1_AVX512VL 1 "register_operand")
     (match_operand: 2 "register_operand")
     (match_operand: 3 "register_operand")
!    (match_operand: 4 "register_operand")]
    "TARGET_AVX512BF16"
  {
    emit_insn (gen_avx512f_dpbf16ps__maskz_1(operands[0], operands[1],
***************
*** 29001,29007 ****
    DONE;
  })
  
! (define_insn "avx512f_dpbf16ps_"
    [(set (match_operand:VF1_AVX512VL 0 "register_operand" "=v")
  	(unspec:VF1_AVX512VL
  	  [(match_operand:VF1_AVX512VL 1 "register_operand" "0")
--- 29228,29234 ----
    DONE;
  })
  
! (define_insn "avx512f_dpbf16ps_"
    [(set (match_operand:VF1_AVX512VL 0 "register_operand" "=v")
  	(unspec:VF1_AVX512VL
  	  [(match_operand:VF1_AVX512VL 1 "register_operand" "0")
***************
*** 29009,29015 ****
  	   (match_operand: 3 "nonimmediate_operand" "vm")]
          UNSPEC_VDPBF16PS))]
    "TARGET_AVX512BF16"
!   "vdpbf16ps\t{%3, %2, %0|%0, %2, %3}")
  
  (define_insn "avx512f_dpbf16ps__mask"
    [(set (match_operand:VF1_AVX512VL 0 "register_operand" "=v")
--- 29236,29242 ----
  	   (match_operand: 3 "nonimmediate_operand" "vm")]
          UNSPEC_VDPBF16PS))]
    "TARGET_AVX512BF16"
!   "vdpbf16ps\t{%3, %2, %0|%0, %2, %3}")
  
  (define_insn "avx512f_dpbf16ps__mask"
    [(set (match_operand:VF1_AVX512VL 0 "register_operand" "=v")
***************
*** 29020,29026 ****
  	     (match_operand: 3 "nonimmediate_operand" "vm")]
               UNSPEC_VDPBF16PS)
            (match_dup 1)
!           (match_operand: 4 "register_operand" "Yk")))]
    "TARGET_AVX512BF16"
    "vdpbf16ps\t{%3, %2, %0%{%4%}|%0%{%4%}, %2, %3}")
  
--- 29247,29253 ----
  	     (match_operand: 3 "nonimmediate_operand" "vm")]
               UNSPEC_VDPBF16PS)
            (match_dup 1)
!           (match_operand: 4 "register_operand" "Yk")))]
    "TARGET_AVX512BF16"
    "vdpbf16ps\t{%3, %2, %0%{%4%}|%0%{%4%}, %2, %3}")
  
diff -Nrcpad gcc-13.4.0/gcc/config/i386/subst.md gcc-13.5.0-RC-20260904/gcc/config/i386/subst.md
*** gcc-13.4.0/gcc/config/i386/subst.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/subst.md	Fri Sep  4 07:35:07 2026
***************
*** 471,486 ****
  		(const_int 1))
  	     (match_operand:SI 3 "const48_operand")]
  		UNSPEC_EMBEDDED_ROUNDING))])
- 
- (define_subst_attr "maskz_half_name" "maskz_half" "" "_maskz_1")
- (define_subst_attr "maskz_half_operand4" "maskz_half" "" "%{%5%}%N4")
- 
- (define_subst "maskz_half"
-   [(set (match_operand:SUBST_V 0)
-         (match_operand:SUBST_V 1))]
-   ""
-   [(set (match_dup 0)
-         (vec_merge:SUBST_V
- 	  (match_dup 1)
- 	  (match_operand:SUBST_V 2 "const0_operand")
- 	  (match_operand: 3 "register_operand" "Yk")))])
--- 471,473 ----
diff -Nrcpad gcc-13.4.0/gcc/config/i386/x86-tune-sched.cc gcc-13.5.0-RC-20260904/gcc/config/i386/x86-tune-sched.cc
*** gcc-13.4.0/gcc/config/i386/x86-tune-sched.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/x86-tune-sched.cc	Fri Sep  4 07:35:07 2026
*************** ix86_fuse_mov_alu_p (rtx_insn *mov, rtx_
*** 584,590 ****
    /* One of operands should be register.  */
    if (op1 && (!REG_P (op0) || REGNO (op0) != REGNO (reg)))
      std::swap (op0, op1);
!   if (!REG_P (op0) || REGNO (op1) != REGNO (reg))
      return false;
    if (op1
        && !REG_P (op1)
--- 584,590 ----
    /* One of operands should be register.  */
    if (op1 && (!REG_P (op0) || REGNO (op0) != REGNO (reg)))
      std::swap (op0, op1);
!   if (!REG_P (op0) || REGNO (op0) != REGNO (reg))
      return false;
    if (op1
        && !REG_P (op1)
diff -Nrcpad gcc-13.4.0/gcc/config/i386/x86-tune.def gcc-13.5.0-RC-20260904/gcc/config/i386/x86-tune.def
*** gcc-13.4.0/gcc/config/i386/x86-tune.def	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/x86-tune.def	Fri Sep  4 07:35:07 2026
*************** DEF_TUNE (X86_TUNE_AVX256_AVOID_VEC_PERM
*** 577,582 ****
--- 577,584 ----
  /* X86_TUNE_AVX256_SPLIT_REGS: if true, AVX512 ops are split into two AVX256 ops.  */
  DEF_TUNE (X86_TUNE_AVX512_SPLIT_REGS, "avx512_split_regs", m_ZNVER4)
  
+ /* It's better to align MOVE_MAX with prefer_vector_width to reduce
+    risk of STLF stalls(small store followed by big load.)  */
  /* X86_TUNE_AVX256_MOVE_BY_PIECES: Optimize move_by_pieces with 256-bit
     AVX instructions.  */
  DEF_TUNE (X86_TUNE_AVX256_MOVE_BY_PIECES, "avx256_move_by_pieces",
*************** DEF_TUNE (X86_TUNE_AVX256_STORE_BY_PIECE
*** 590,603 ****
  /* X86_TUNE_AVX512_MOVE_BY_PIECES: Optimize move_by_pieces with 512-bit
     AVX instructions.  */
  DEF_TUNE (X86_TUNE_AVX512_MOVE_BY_PIECES, "avx512_move_by_pieces",
! 	  m_SAPPHIRERAPIDS | m_GRANITERAPIDS | m_GRANITERAPIDS_D
! 	  | m_ZNVER4 | m_ZNVER5)
  
  /* X86_TUNE_AVX512_STORE_BY_PIECES: Optimize store_by_pieces with 512-bit
     AVX instructions.  */
  DEF_TUNE (X86_TUNE_AVX512_STORE_BY_PIECES, "avx512_store_by_pieces",
! 	  m_SAPPHIRERAPIDS | m_GRANITERAPIDS | m_GRANITERAPIDS_D
! 	  | m_ZNVER4 | m_ZNVER5)
  
  /*****************************************************************************/
  /*****************************************************************************/
--- 592,603 ----
  /* X86_TUNE_AVX512_MOVE_BY_PIECES: Optimize move_by_pieces with 512-bit
     AVX instructions.  */
  DEF_TUNE (X86_TUNE_AVX512_MOVE_BY_PIECES, "avx512_move_by_pieces",
! 	   m_ZNVER4 | m_ZNVER5)
  
  /* X86_TUNE_AVX512_STORE_BY_PIECES: Optimize store_by_pieces with 512-bit
     AVX instructions.  */
  DEF_TUNE (X86_TUNE_AVX512_STORE_BY_PIECES, "avx512_store_by_pieces",
! 	  m_ZNVER4 | m_ZNVER5)
  
  /*****************************************************************************/
  /*****************************************************************************/
diff -Nrcpad gcc-13.4.0/gcc/config/i386/xmmintrin.h gcc-13.5.0-RC-20260904/gcc/config/i386/xmmintrin.h
*** gcc-13.4.0/gcc/config/i386/xmmintrin.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/i386/xmmintrin.h	Fri Sep  4 07:35:07 2026
*************** _mm_maskmove_si64 (__m64 __A, __m64 __N,
*** 1181,1197 ****
    __v2di __N128 = __extension__ (__v2di) { ((__v1di) __N)[0], 0 };
  
    /* Check the alignment of __P.  */
!   __SIZE_TYPE__ offset = ((__SIZE_TYPE__) __P) & 0xf;
!   if (offset)
      {
        /* If the misalignment of __P > 8, subtract __P by 8 bytes.
  	 Otherwise, subtract __P by the misalignment.  */
!       if (offset > 8)
! 	offset = 8;
!       __P = (char *) (((__SIZE_TYPE__) __P) - offset);
  
        /* Shift __A128 and __N128 to the left by the adjustment.  */
!       switch (offset)
  	{
  	case 1:
  	  __A128 = __builtin_ia32_pslldqi128 (__A128, 8);
--- 1181,1197 ----
    __v2di __N128 = __extension__ (__v2di) { ((__v1di) __N)[0], 0 };
  
    /* Check the alignment of __P.  */
!   __SIZE_TYPE__ __offset = ((__SIZE_TYPE__) __P) & 0xf;
!   if (__offset)
      {
        /* If the misalignment of __P > 8, subtract __P by 8 bytes.
  	 Otherwise, subtract __P by the misalignment.  */
!       if (__offset > 8)
! 	__offset = 8;
!       __P = (char *) (((__SIZE_TYPE__) __P) - __offset);
  
        /* Shift __A128 and __N128 to the left by the adjustment.  */
!       switch (__offset)
  	{
  	case 1:
  	  __A128 = __builtin_ia32_pslldqi128 (__A128, 8);
diff -Nrcpad gcc-13.4.0/gcc/config/loongarch/constraints.md gcc-13.5.0-RC-20260904/gcc/config/loongarch/constraints.md
*** gcc-13.4.0/gcc/config/loongarch/constraints.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/loongarch/constraints.md	Fri Sep  4 07:35:08 2026
***************
*** 200,202 ****
--- 200,211 ----
     and offset that is suitable for use in instructions with the same
     addressing mode as @code{preld}."
     (match_test "loongarch_12bit_offset_address_p (op, mode)"))
+ 
+ (define_constraint "ZE"
+   "A symbolic suitable as stack canary in the normal/medium code model."
+   (match_operand 0 "ssp_normal_operand"))
+ 
+ (define_constraint "ZF"
+   "A symbolic suitable as stack canary, but in the extreme code model."
+   (and (match_operand 0 "ssp_operand")
+        (not (match_operand 0 "ssp_normal_operand"))))
diff -Nrcpad gcc-13.4.0/gcc/config/loongarch/loongarch-protos.h gcc-13.5.0-RC-20260904/gcc/config/loongarch/loongarch-protos.h
*** gcc-13.4.0/gcc/config/loongarch/loongarch-protos.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/loongarch/loongarch-protos.h	Fri Sep  4 07:35:08 2026
*************** extern rtx loongarch_expand_builtin (tre
*** 180,183 ****
--- 180,185 ----
  				     machine_mode, int);
  extern tree loongarch_build_builtin_va_list (void);
  
+ extern bool loongarch_symbol_extreme_p (enum loongarch_symbol_type);
+ extern void loongarch_output_asm_load_canary (rtx reg, rtx canary, rtx tmp);
  #endif /* ! GCC_LOONGARCH_PROTOS_H */
diff -Nrcpad gcc-13.4.0/gcc/config/loongarch/loongarch.cc gcc-13.5.0-RC-20260904/gcc/config/loongarch/loongarch.cc
*** gcc-13.4.0/gcc/config/loongarch/loongarch.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/loongarch/loongarch.cc	Fri Sep  4 07:35:08 2026
*************** loongarch_force_address (rtx x, machine_
*** 2825,2831 ****
    return x;
  }
  
! static bool
  loongarch_symbol_extreme_p (enum loongarch_symbol_type type)
  {
    switch (type)
--- 2825,2831 ----
    return x;
  }
  
! bool
  loongarch_symbol_extreme_p (enum loongarch_symbol_type type)
  {
    switch (type)
*************** loongarch_print_operand (FILE *file, rtx
*** 5153,5158 ****
--- 5153,5172 ----
        fputc (',', file);
        break;
  
+     case 'v':
+       switch (GET_MODE (op))
+ 	{
+ 	case E_SImode:
+ 	  fprintf (file, "w");
+ 	  break;
+ 	case E_DImode:
+ 	  fprintf (file, "d");
+ 	  break;
+ 	default:
+ 	  output_operand_lossage ("invalid use of '%%%c'", letter);
+ 	}
+       break;
+ 
      default:
        switch (code)
  	{
*************** loongarch_asan_shadow_offset (void)
*** 6631,6636 ****
--- 6645,6692 ----
    return TARGET_64BIT ? (HOST_WIDE_INT_1 << 46) : 0;
  }
  
+ void
+ loongarch_output_asm_load_canary (rtx reg, rtx canary, rtx tmp)
+ {
+   gcc_checking_assert (ssp_operand (canary, VOIDmode));
+   gcc_checking_assert ((!tmp) == ssp_normal_operand (canary, VOIDmode));
+   gcc_checking_assert (register_operand (reg, Pmode));
+ 
+   rtx op[] = {reg, canary, tmp};
+   bool got = (loongarch_classify_symbol (canary) == SYMBOL_GOT_DISP);
+   bool need_ld = false;
+ 
+   if (!TARGET_EXPLICIT_RELOCS)
+     {
+       if (got)
+ 	output_asm_insn (tmp ? "la.global\t%0,%2,%1" : "la.global\t%0,%1",
+ 			 op);
+       else
+ 	output_asm_insn (tmp ? "la.local\t%0,%2,%1" : "la.local\t%0,%1",
+ 			 op);
+ 
+       need_ld = true;
+     }
+   else
+     {
+       output_asm_insn ("pcalau12i\t%0,%r1", op);
+       if (!tmp)
+ 	output_asm_insn ("ld.%v0\t%0,%0,%L1", op);
+       else
+ 	{
+ 	  output_asm_insn ("addi.d\t%2,$r0,%L1", op);
+ 	  output_asm_insn ("lu32i.d\t%2,%R1", op);
+ 	  output_asm_insn ("lu52i.d\t%2,%2,%H1", op);
+ 	  output_asm_insn ("ldx.d\t%0,%0,%2", op);
+ 	}
+ 
+       need_ld = got;
+     }
+ 
+   if (need_ld)
+     output_asm_insn ("ld.%v0\t%0,%0,0", op);
+ }
+ 
  /* Initialize the GCC target structure.  */
  #undef TARGET_ASM_ALIGNED_HI_OP
  #define TARGET_ASM_ALIGNED_HI_OP "\t.half\t"
*************** loongarch_asan_shadow_offset (void)
*** 6641,6646 ****
--- 6697,6703 ----
  
  #undef TARGET_OPTION_OVERRIDE
  #define TARGET_OPTION_OVERRIDE loongarch_option_override
+ #undef TARGET_OPTION_SAVE
  #define TARGET_OPTION_SAVE loongarch_option_save
  #undef TARGET_OPTION_RESTORE
  #define TARGET_OPTION_RESTORE loongarch_option_restore
diff -Nrcpad gcc-13.4.0/gcc/config/loongarch/loongarch.md gcc-13.5.0-RC-20260904/gcc/config/loongarch/loongarch.md
*** gcc-13.4.0/gcc/config/loongarch/loongarch.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/loongarch/loongarch.md	Fri Sep  4 07:35:08 2026
***************
*** 74,79 ****
--- 74,81 ----
  
    UNSPEC_SIBCALL_VALUE_MULTIPLE_INTERNAL_1
    UNSPEC_CALL_VALUE_MULTIPLE_INTERNAL_1
+ 
+   UNSPEC_SSP
  ])
  
  (define_c_enum "unspecv" [
***************
*** 2698,2704 ****
    [(set_attr "type" "branch")])
  
  
! (define_expand "cbranch4"
    [(set (pc)
  	(if_then_else (match_operator 0 "comparison_operator"
  			[(match_operand:GPR 1 "register_operand")
--- 2700,2706 ----
    [(set_attr "type" "branch")])
  
  
! (define_expand "@cbranch4"
    [(set (pc)
  	(if_then_else (match_operator 0 "comparison_operator"
  			[(match_operand:GPR 1 "register_operand")
***************
*** 3584,3589 ****
--- 3586,3675 ----
    [(set_attr "type" "unknown")
     (set_attr "mode" "")])
  
+ ;; Set and check against stack canary without leaving it in a register.
+ ;; DO NOT ATTEMPT TO SPLIT THESE INSNS!  It's important for security reason
+ ;; that the canary value does not live beyond the life of this sequence.
+ 
+ (define_insn "@stack_protect_combined_set_normal_"
+   [(set (match_operand:P 0 "memory_operand" "=m,ZC")
+         (unspec:P [(mem:P (match_operand:P 1 "ssp_normal_operand"))]
+ 		  UNSPEC_SSP))
+    (set (match_scratch:P 2 "=&r,&r") (const_int 0))]
+   ""
+ {
+   loongarch_output_asm_load_canary (operands[2], operands[1], NULL_RTX);
+   output_asm_insn (which_alternative ? "stptr.d\t%2,%0" : "st.d\t%2,%0",
+ 		   operands);
+   return "ori\t%2,$r0,0";
+ }
+   [(set_attr "type" "store")
+    (set_attr "length" "20")])
+ 
+ (define_insn "@stack_protect_combined_set_extreme_"
+   [(set (match_operand:P 0 "memory_operand" "=m,ZC")
+         (unspec:P [(mem:P (match_operand:P 1 "ssp_operand"))] UNSPEC_SSP))
+    (set (match_scratch:P 2 "=&r,&r") (const_int 0))
+    (set (match_scratch:P 3 "=&r,&r") (const_int 0))]
+   ""
+ {
+   loongarch_output_asm_load_canary (operands[2], operands[1], operands[3]);
+   output_asm_insn (which_alternative ? "stptr.d\t%2,%0" : "st.d\t%2,%0",
+ 		   operands);
+   return "ori\t%2,$r0,0\n\tori\t%3,$r0,0";
+ }
+   [(set_attr "type" "store")
+    (set_attr "length" "36")])
+ 
+ (define_insn "@stack_protect_combined_test_internal_"
+   [(set (match_operand:P 0 "register_operand" "=r,r,&r,&r")
+ 	(xor:P
+ 	  (match_operand:P 1 "memory_operand" "=m,ZC,m,ZC")
+ 	    (unspec:P
+ 	      [(mem:P (match_operand:P 2 "ssp_operand" "ZE,ZE,ZF,ZF"))]
+ 	      UNSPEC_SSP)))
+    (set (match_scratch:P 3 "=&r,&r,&r,&r") (const_int 0))]
+   ""
+ {
+   rtx t = (which_alternative >= 2 ? operands[0] : NULL_RTX);
+   loongarch_output_asm_load_canary (operands[3], operands[2], t);
+   output_asm_insn ((which_alternative & 1) ? "ldptr.d\t%0,%1"
+ 					   : "ld.d\t%0,%1",
+ 		   operands);
+   return "xor\t%0,%0,%3\n\tori\t%3,$r0,0";
+ }
+   [(set_attr "type" "load,load,load,load")
+    (set_attr "length" "24,24,36,36")])
+ 
+ (define_expand "stack_protect_combined_set"
+   [(match_operand 0 "memory_operand")
+    (match_operand 1 "memory_operand")]
+   ""
+ {
+   rtx canary = XEXP (operands[1], 0);
+   auto fn = (ssp_normal_operand (canary, VOIDmode)
+ 	     ? gen_stack_protect_combined_set_normal
+ 	     : gen_stack_protect_combined_set_extreme);
+ 
+   emit_insn (fn (Pmode, operands[0], canary));
+   DONE;
+ })
+ 
+ (define_expand "stack_protect_combined_test"
+   [(match_operand 0 "memory_operand")
+    (match_operand 1 "memory_operand")
+    (match_operand 2 "")]
+   ""
+ {
+   rtx t = gen_reg_rtx (Pmode);
+   rtx canary = XEXP (operands[1], 0);
+   emit_insn (gen_stack_protect_combined_test_internal (Pmode, t,
+ 						       operands[0],
+ 						       canary));
+   rtx cond = gen_rtx_EQ (VOIDmode, t, const0_rtx);
+   emit_jump_insn (gen_cbranch4 (Pmode, cond, t, const0_rtx, operands[2]));
+   DONE;
+ })
+ 
  ;; Synchronization instructions.
  
  (include "sync.md")
diff -Nrcpad gcc-13.4.0/gcc/config/loongarch/predicates.md gcc-13.5.0-RC-20260904/gcc/config/loongarch/predicates.md
*** gcc-13.4.0/gcc/config/loongarch/predicates.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/loongarch/predicates.md	Fri Sep  4 07:35:08 2026
***************
*** 248,253 ****
--- 248,269 ----
    return loongarch_symbolic_constant_p (op, &type);
  })
  
+ (define_predicate "symbolic_off64_operand"
+  (match_code "const,symbol_ref,label_ref")
+ {
+   enum loongarch_symbol_type type;
+   return loongarch_symbolic_constant_p (op, &type)
+ 	 && loongarch_symbol_extreme_p (type);
+ })
+ 
+ ;; Currently stack canary must be the global symbol __stack_chk_guard.
+ (define_predicate "ssp_operand" (match_code "symbol_ref"))
+ 
+ ;; If the stack canary is within the normal/medium code model.
+ (define_predicate "ssp_normal_operand"
+   (and (match_operand 0 "ssp_operand")
+        (not (match_operand 0 "symbolic_off64_operand"))))
+ 
  (define_predicate "equality_operator"
    (match_code "eq,ne"))
  
diff -Nrcpad gcc-13.4.0/gcc/config/mips/mips-ftypes.def gcc-13.5.0-RC-20260904/gcc/config/mips/mips-ftypes.def
*** gcc-13.4.0/gcc/config/mips/mips-ftypes.def	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/mips/mips-ftypes.def	Fri Sep  4 07:35:08 2026
*************** DEF_MIPS_FTYPE (1, (SI, V4QI))
*** 75,81 ****
  DEF_MIPS_FTYPE (2, (SI, V4QI, V4QI))
  DEF_MIPS_FTYPE (2, (SI, V4SI, UQI))
  DEF_MIPS_FTYPE (2, (SI, V8HI, UQI))
! DEF_MIPS_FTYPE (1, (SI, VOID))
  
  DEF_MIPS_FTYPE (2, (UDI, UDI, UDI))
  DEF_MIPS_FTYPE (2, (UDI, UV2SI, UV2SI))
--- 75,81 ----
  DEF_MIPS_FTYPE (2, (SI, V4QI, V4QI))
  DEF_MIPS_FTYPE (2, (SI, V4SI, UQI))
  DEF_MIPS_FTYPE (2, (SI, V8HI, UQI))
! DEF_MIPS_FTYPE (0, (SI))
  
  DEF_MIPS_FTYPE (2, (UDI, UDI, UDI))
  DEF_MIPS_FTYPE (2, (UDI, UV2SI, UV2SI))
*************** DEF_MIPS_FTYPE (2, (UDI, V2DI, UQI))
*** 84,90 ****
  DEF_MIPS_FTYPE (2, (USI, V16QI, UQI))
  DEF_MIPS_FTYPE (2, (USI, V4SI, UQI))
  DEF_MIPS_FTYPE (2, (USI, V8HI, UQI))
! DEF_MIPS_FTYPE (1, (USI, VOID))
  
  DEF_MIPS_FTYPE (2, (UV16QI, UV16QI, UQI))
  DEF_MIPS_FTYPE (2, (UV16QI, UV16QI, UV16QI))
--- 84,90 ----
  DEF_MIPS_FTYPE (2, (USI, V16QI, UQI))
  DEF_MIPS_FTYPE (2, (USI, V4SI, UQI))
  DEF_MIPS_FTYPE (2, (USI, V8HI, UQI))
! DEF_MIPS_FTYPE (0, (USI))
  
  DEF_MIPS_FTYPE (2, (UV16QI, UV16QI, UQI))
  DEF_MIPS_FTYPE (2, (UV16QI, UV16QI, UV16QI))
diff -Nrcpad gcc-13.4.0/gcc/config/mips/mips.cc gcc-13.5.0-RC-20260904/gcc/config/mips/mips.cc
*** gcc-13.4.0/gcc/config/mips/mips.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/mips/mips.cc	Fri Sep  4 07:35:08 2026
*************** enum mips_ucbranch_type
*** 211,216 ****
--- 211,217 ----
  };
  
  /* Macros to create an enumeration identifier for a function prototype.  */
+ #define MIPS_FTYPE_NAME0(A) MIPS_##A##_FTYPE_VOID
  #define MIPS_FTYPE_NAME1(A, B) MIPS_##A##_FTYPE_##B
  #define MIPS_FTYPE_NAME2(A, B, C) MIPS_##A##_FTYPE_##B##_##C
  #define MIPS_FTYPE_NAME3(A, B, C, D) MIPS_##A##_FTYPE_##B##_##C##_##D
*************** mips_build_cvpointer_type (void)
*** 16760,16765 ****
--- 16761,16769 ----
  
  /* MIPS_FTYPE_ATYPESN takes N MIPS_FTYPES-like type codes and lists
     their associated MIPS_ATYPEs.  */
+ #define MIPS_FTYPE_ATYPES0(A) \
+   MIPS_ATYPE_##A
+ 
  #define MIPS_FTYPE_ATYPES1(A, B) \
    MIPS_ATYPE_##A, MIPS_ATYPE_##B
  
diff -Nrcpad gcc-13.4.0/gcc/config/pa/pa.cc gcc-13.5.0-RC-20260904/gcc/config/pa/pa.cc
*** gcc-13.4.0/gcc/config/pa/pa.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/pa/pa.cc	Fri Sep  4 07:35:08 2026
*************** static void
*** 10476,10485 ****
  pa_trampoline_init (rtx m_tramp, tree fndecl, rtx chain_value)
  {
    rtx fnaddr = XEXP (DECL_RTL (fndecl), 0);
!   rtx start_addr = gen_reg_rtx (Pmode);
!   rtx end_addr = gen_reg_rtx (Pmode);
!   rtx line_length = gen_reg_rtx (Pmode);
!   rtx r_tramp, tmp;
  
    emit_block_move (m_tramp, assemble_trampoline_template (),
  		   GEN_INT (TRAMPOLINE_SIZE), BLOCK_OP_NORMAL);
--- 10476,10482 ----
  pa_trampoline_init (rtx m_tramp, tree fndecl, rtx chain_value)
  {
    rtx fnaddr = XEXP (DECL_RTL (fndecl), 0);
!   rtx start, end, r_tramp, tmp;
  
    emit_block_move (m_tramp, assemble_trampoline_template (),
  		   GEN_INT (TRAMPOLINE_SIZE), BLOCK_OP_NORMAL);
*************** pa_trampoline_init (rtx m_tramp, tree fn
*** 10487,10492 ****
--- 10484,10492 ----
  
    if (!TARGET_64BIT)
      {
+       /* Start of trampoline code.  */
+       start = r_tramp;
+ 
        tmp = adjust_address (m_tramp, Pmode, 48);
        emit_move_insn (tmp, fnaddr);
        tmp = adjust_address (m_tramp, Pmode, 52);
*************** pa_trampoline_init (rtx m_tramp, tree fn
*** 10494,10521 ****
  
        /* Create a fat pointer for the trampoline.  */
        tmp = adjust_address (m_tramp, Pmode, 56);
!       emit_move_insn (tmp, r_tramp);
        tmp = adjust_address (m_tramp, Pmode, 60);
        emit_move_insn (tmp, gen_rtx_REG (Pmode, 19));
- 
-       /* fdc and fic only use registers for the address to flush,
- 	 they do not accept integer displacements.  We align the
- 	 start and end addresses to the beginning of their respective
- 	 cache lines to minimize the number of lines flushed.  */
-       emit_insn (gen_andsi3 (start_addr, r_tramp,
- 			     GEN_INT (-MIN_CACHELINE_SIZE)));
-       tmp = force_reg (Pmode, plus_constant (Pmode, r_tramp,
- 					     TRAMPOLINE_CODE_SIZE-1));
-       emit_insn (gen_andsi3 (end_addr, tmp,
- 			     GEN_INT (-MIN_CACHELINE_SIZE)));
-       emit_move_insn (line_length, GEN_INT (MIN_CACHELINE_SIZE));
-       emit_insn (gen_dcacheflushsi (start_addr, end_addr, line_length));
-       emit_insn (gen_icacheflushsi (start_addr, end_addr, line_length,
- 				    gen_reg_rtx (Pmode),
- 				    gen_reg_rtx (Pmode)));
      }
    else
      {
        tmp = adjust_address (m_tramp, Pmode, 56);
        emit_move_insn (tmp, fnaddr);
        tmp = adjust_address (m_tramp, Pmode, 64);
--- 10494,10508 ----
  
        /* Create a fat pointer for the trampoline.  */
        tmp = adjust_address (m_tramp, Pmode, 56);
!       emit_move_insn (tmp, start);
        tmp = adjust_address (m_tramp, Pmode, 60);
        emit_move_insn (tmp, gen_rtx_REG (Pmode, 19));
      }
    else
      {
+       /* Start of trampoline code.  */
+       start = force_reg (Pmode, plus_constant (Pmode, r_tramp, 32));
+ 
        tmp = adjust_address (m_tramp, Pmode, 56);
        emit_move_insn (tmp, fnaddr);
        tmp = adjust_address (m_tramp, Pmode, 64);
*************** pa_trampoline_init (rtx m_tramp, tree fn
*** 10523,10551 ****
  
        /* Create a fat pointer for the trampoline.  */
        tmp = adjust_address (m_tramp, Pmode, 16);
!       emit_move_insn (tmp, force_reg (Pmode, plus_constant (Pmode,
! 							    r_tramp, 32)));
        tmp = adjust_address (m_tramp, Pmode, 24);
        emit_move_insn (tmp, gen_rtx_REG (Pmode, 27));
- 
-       /* fdc and fic only use registers for the address to flush,
- 	 they do not accept integer displacements.  We align the
- 	 start and end addresses to the beginning of their respective
- 	 cache lines to minimize the number of lines flushed.  */
-       tmp = force_reg (Pmode, plus_constant (Pmode, r_tramp, 32));
-       emit_insn (gen_anddi3 (start_addr, tmp,
- 			     GEN_INT (-MIN_CACHELINE_SIZE)));
-       tmp = force_reg (Pmode, plus_constant (Pmode, tmp,
- 					     TRAMPOLINE_CODE_SIZE - 1));
-       emit_insn (gen_anddi3 (end_addr, tmp,
- 			     GEN_INT (-MIN_CACHELINE_SIZE)));
-       emit_move_insn (line_length, GEN_INT (MIN_CACHELINE_SIZE));
-       emit_insn (gen_dcacheflushdi (start_addr, end_addr, line_length));
-       emit_insn (gen_icacheflushdi (start_addr, end_addr, line_length,
- 				    gen_reg_rtx (Pmode),
- 				    gen_reg_rtx (Pmode)));
      }
  
  #ifdef HAVE_ENABLE_EXECUTE_STACK
    emit_library_call (gen_rtx_SYMBOL_REF (Pmode, "__enable_execute_stack"),
  		     LCT_NORMAL, VOIDmode, XEXP (m_tramp, 0), Pmode);
--- 10510,10525 ----
  
        /* Create a fat pointer for the trampoline.  */
        tmp = adjust_address (m_tramp, Pmode, 16);
!       emit_move_insn (tmp, start);
        tmp = adjust_address (m_tramp, Pmode, 24);
        emit_move_insn (tmp, gen_rtx_REG (Pmode, 27));
      }
  
+   end = force_reg (Pmode, plus_constant (Pmode, start, TRAMPOLINE_CODE_SIZE));
+ 
+   /* Flush trampoline.  */
+   emit_insn (gen_clear_cache (start, end));
+ 
  #ifdef HAVE_ENABLE_EXECUTE_STACK
    emit_library_call (gen_rtx_SYMBOL_REF (Pmode, "__enable_execute_stack"),
  		     LCT_NORMAL, VOIDmode, XEXP (m_tramp, 0), Pmode);
diff -Nrcpad gcc-13.4.0/gcc/config/pa/pa.md gcc-13.5.0-RC-20260904/gcc/config/pa/pa.md
*** gcc-13.4.0/gcc/config/pa/pa.md	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/pa/pa.md	Fri Sep  4 07:35:08 2026
*************** add,l %2,%3,%3\;bv,n %%r0(%3)"
*** 9981,9990 ****
    [(set_attr "type" "fpalu")
     (set_attr "length" "4")])
  
! ;; The following two patterns are used by the trampoline code for nested
  ;; functions.  They flush the I and D cache lines from the start address
! ;; (operand0) to the end address (operand1).  No lines are flushed if the
! ;; end address is less than the start address (unsigned).
  ;;
  ;; Because the range of memory flushed is variable and the size of a MEM
  ;; can only be a CONST_INT, the patterns specify that they perform an
--- 9981,9989 ----
    [(set_attr "type" "fpalu")
     (set_attr "length" "4")])
  
! ;; The following four patterns are used by the trampoline code for nested
  ;; functions.  They flush the I and D cache lines from the start address
! ;; (operand0) to the end address (operand1).
  ;;
  ;; Because the range of memory flushed is variable and the size of a MEM
  ;; can only be a CONST_INT, the patterns specify that they perform an
*************** add,l %2,%3,%3\;bv,n %%r0(%3)"
*** 9993,10001 ****
  ;; The address range for an icache flush must lie within a single
  ;; space on targets with non-equivalent space registers.
  ;;
! ;; Operand 0 contains the start address.
  ;; Operand 1 contains the end address.
! ;; Operand 2 contains the line length to use.
  (define_insn "dcacheflush"
    [(const_int 1)
     (unspec_volatile [(mem:BLK (scratch))] UNSPECV_DCACHE)
--- 9992,10000 ----
  ;; The address range for an icache flush must lie within a single
  ;; space on targets with non-equivalent space registers.
  ;;
! ;; Operand 0 contains the line aligned start address.
  ;; Operand 1 contains the end address.
! ;; Operand 2 contains the line size to use.
  (define_insn "dcacheflush"
    [(const_int 1)
     (unspec_volatile [(mem:BLK (scratch))] UNSPECV_DCACHE)
*************** add,l %2,%3,%3\;bv,n %%r0(%3)"
*** 10004,10014 ****
     (use (match_operand 2 "pmode_register_operand" "r"))
     (clobber (match_scratch:P 3 "=&0"))]
    ""
!   "cmpb,<<=,n %3,%1,.\;fdc,m %2(%3)\;sync"
    [(set_attr "type" "multi")
     (set_attr "length" "12")])
  
! (define_insn "icacheflush"
    [(const_int 2)
     (unspec_volatile [(mem:BLK (scratch))] UNSPECV_ICACHE)
     (use (match_operand 0 "pmode_register_operand" "r"))
--- 10003,10013 ----
     (use (match_operand 2 "pmode_register_operand" "r"))
     (clobber (match_scratch:P 3 "=&0"))]
    ""
!   "{comb|cmpb},<<,n %3,%1,.\;fdc,m %2(%3)\;sync"
    [(set_attr "type" "multi")
     (set_attr "length" "12")])
  
! (define_insn "icacheflush1"
    [(const_int 2)
     (unspec_volatile [(mem:BLK (scratch))] UNSPECV_ICACHE)
     (use (match_operand 0 "pmode_register_operand" "r"))
*************** add,l %2,%3,%3\;bv,n %%r0(%3)"
*** 10018,10027 ****
     (clobber (match_operand 4 "pmode_register_operand" "=&r"))
     (clobber (match_scratch:P 5 "=&0"))]
    ""
!   "mfsp %%sr0,%4\;ldsid (%5),%3\;mtsp %3,%%sr0\;cmpb,<<=,n %5,%1,.\;fic,m %2(%%sr0,%5)\;sync\;mtsp %4,%%sr0\;nop\;nop\;nop\;nop\;nop\;nop"
    [(set_attr "type" "multi")
     (set_attr "length" "52")])
  
  ;; An out-of-line prologue.
  (define_insn "outline_prologue_call"
    [(unspec_volatile [(const_int 0)] UNSPECV_OPC)
--- 10017,10105 ----
     (clobber (match_operand 4 "pmode_register_operand" "=&r"))
     (clobber (match_scratch:P 5 "=&0"))]
    ""
!   "mfsp %%sr1,%4\;ldsid (%5),%3\;mtsp %3,%%sr1\;{comb|cmpb},<<,n %5,%1,.\;fic,m %2(%%sr1,%5)\;sync\;mtsp %4,%%sr1\;nop\;nop\;nop\;nop\;nop\;nop"
    [(set_attr "type" "multi")
     (set_attr "length" "52")])
  
+ (define_insn "icacheflush2"
+   [(const_int 2)
+    (unspec_volatile [(mem:BLK (scratch))] UNSPECV_ICACHE)
+    (use (match_operand 0 "pmode_register_operand" "r"))
+    (use (match_operand 1 "pmode_register_operand" "r"))
+    (use (match_operand 2 "pmode_register_operand" "r"))
+    (clobber (match_scratch:P 3 "=&0"))]
+   "TARGET_PA_20"
+   "cmpb,<<,n %3,%1,.\;fic,m %2(%3)\;sync\;nop\;nop\;nop\;nop\;nop\;nop\;nop"
+   [(set_attr "type" "multi")
+    (set_attr "length" "40")])
+ 
+ (define_insn "icacheflush3"
+   [(const_int 3)
+    (unspec_volatile [(mem:BLK (scratch))] UNSPECV_ICACHE)
+    (use (match_operand 0 "pmode_register_operand" "r"))
+    (use (match_operand 1 "pmode_register_operand" "r"))
+    (use (match_operand 2 "pmode_register_operand" "r"))
+    (clobber (match_scratch:P 3 "=&0"))]
+   "!TARGET_PA_20 && TARGET_NO_SPACE_REGS"
+   "comb,<<,n %3,%1,.\;fic,m %2(%%sr4,%3)\;sync\;nop\;nop\;nop\;nop\;nop\;nop\;nop"
+   [(set_attr "type" "multi")
+    (set_attr "length" "40")])
+ 
+ ;; clear_cache
+ ;;
+ ;; Note the data and instruction cache flushes need to be separated
+ ;; by a sync instruction (see page 7-151 in PA 2.0 architecture manual).
+ ;; Thus, we can't combine the flush operations in a single loop.
+ 
+ ;; Operand 0 contains the start address (inclusive).
+ ;; Operand 1 contains the end address (exclusive).
+ (define_expand "clear_cache"
+   [(match_operand 0 "pmode_register_operand")
+    (match_operand 1 "pmode_register_operand")]
+   ""
+ {
+   rtx start = gen_reg_rtx (Pmode);
+   rtx line_size = gen_reg_rtx (Pmode);
+   rtx lab = gen_label_rtx ();
+   rtx op0 = operands[0];
+   rtx op1 = operands[1];
+ 
+   /* Skip flush if op0 is greater than or equal to op1.  */
+   emit_cmp_and_jump_insns (op0, op1, GEU, NULL_RTX, Pmode, 0, lab);
+ 
+   /* Load cache line size.  */
+   emit_move_insn (line_size, GEN_INT (MIN_CACHELINE_SIZE));
+ 
+   if (TARGET_64BIT)
+     {
+       /* Align the start address.  */
+       emit_insn (gen_anddi3 (start, op0, GEN_INT (-MIN_CACHELINE_SIZE)));
+ 
+       /* Flush the cache.  */
+       emit_insn (gen_dcacheflushdi (start, op1, line_size));
+       emit_insn (gen_icacheflush2di (start, op1, line_size));
+     }
+   else
+     {
+       /* Align the start address.  */
+       emit_insn (gen_andsi3 (start, op0, GEN_INT (-MIN_CACHELINE_SIZE)));
+ 
+       /* Flush the cache.  */
+       emit_insn (gen_dcacheflushsi (start, op1, line_size));
+       if (TARGET_PA_20)
+ 	emit_insn (gen_icacheflush2si (start, op1, line_size));
+       else if (TARGET_NO_SPACE_REGS)
+ 	emit_insn (gen_icacheflush3si (start, op1, line_size));
+       else
+ 	emit_insn (gen_icacheflush1si (start, op1, line_size,
+ 				       gen_reg_rtx (Pmode),
+ 				       gen_reg_rtx (Pmode)));
+     }
+ 
+   emit_label (lab);
+   DONE;
+ })
+ 
  ;; An out-of-line prologue.
  (define_insn "outline_prologue_call"
    [(unspec_volatile [(const_int 0)] UNSPECV_OPC)
diff -Nrcpad gcc-13.4.0/gcc/config/rs6000/aix.h gcc-13.5.0-RC-20260904/gcc/config/rs6000/aix.h
*** gcc-13.4.0/gcc/config/rs6000/aix.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/config/rs6000/aix.h	Fri Sep  4 07:35:08 2026
***************
*** 283,286 ****
  #undef SUBTARGET_DRIVER_SELF_SPECS
  #define SUBTARGET_DRIVER_SELF_SPECS	\
  "%{m64:-maix64} %&2
  				  exit 1
  				fi
! 				ext_val=`echo $ext_val | sed -e 's/[a-z0-9]\+//'`
  			  done
  
  			  true
--- 4179,4185 ----
  				  echo "Unknown extension used in --with-$which=$val" 1>&2
  				  exit 1
  				fi
! 				ext_val=`echo $ext_val | sed -e 's/[a-z0-9-]\+//'`
  			  done
  
  			  true
diff -Nrcpad gcc-13.4.0/gcc/cp/ChangeLog gcc-13.5.0-RC-20260904/gcc/cp/ChangeLog
*** gcc-13.4.0/gcc/cp/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/ChangeLog	Fri Sep  4 07:35:08 2026
***************
*** 1,3 ****
--- 1,289 ----
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-08-14  Patrick Palka  
+ 
+ 	PR c++/126483
+ 	* typeck2.cc (store_init_value): Check maybe_constexpr_fn
+ 	instead of DECL_DECLARED_CONSTEXPR_P of the function scope.
+ 
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-07-25  Patrick Palka  
+ 
+ 	PR c++/126280
+ 	* pt.cc (mark_template_arguments_used): Split out loop into ...
+ 	(mark_template_arguments_used_1): ... here. Recurse into
+ 	argument packs.
+ 
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-04-07  Patrick Palka  
+ 
+ 	PR c++/123529
+ 	PR c++/98930
+ 	* pt.cc (has_value_dependent_address): Correct context
+ 	dependence check for a static local variable.
+ 
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-02-17  Patrick Palka  
+ 
+ 	PR c++/121822
+ 	* cvt.cc (convert_to_void): Don't evaluate a concept-id
+ 	in an unevaluated context.
+ 
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2025-09-20  Patrick Palka  
+ 
+ 	PR c++/121981
+ 	* pt.cc (any_template_parm_r) :
+ 	Don't walk TREE_TYPE.
+ 
+ 2026-08-20  Marek Polacek  
+ 
+ 	Backported from master:
+ 	2025-03-07  Marek Polacek  
+ 
+ 	PR c++/118775
+ 	* constexpr.cc (cxx_eval_call_expression): Check tree_fits_uhwi_p.
+ 
+ 2026-08-20  Marek Polacek  
+ 
+ 	PR c++/116379
+ 	* pt.cc (tsubst_expr) : Use force_paren_expr to set
+ 	REF_PARENTHESIZED_P.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-06-12  Jakub Jelinek  
+ 
+ 	PR c++/125674
+ 	* pt.cc (tsubst_decl): Diagnose bit-field widths
+ 	with invalid type.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-04-15  Jakub Jelinek  
+ 
+ 	PR c++/124850
+ 	* typeck.cc (cxx_mark_addressable): For DECL_ANON_UNION_VAR_P vars
+ 	also mark their DECL_VALUE_EXPR.
+ 
+ 2026-08-01  Yang Kun  
+ 
+ 	Backported from master:
+ 	2026-04-08  Yang Kun  
+ 
+ 	* parser.cc (cp_parser_omp_clause_proc_bind): Fix error message
+ 	(cp_parser_omp_clause_device_type): Likewise.
+ 
+ 2026-06-17  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-05-04  Andrew Pinski  
+ 
+ 	PR c++/65271
+ 	* parser.cc (cp_parser_class_specifier): Accept &&.
+ 
+ 2026-05-13  Jason Merrill  
+ 
+ 	Backported from master:
+ 	2025-08-21  Jason Merrill  
+ 
+ 	PR c++/120757
+ 	* pt.cc (tsubst_copy) [OFFSET_REF]: Don't tsubst the type.
+ 
+ 2026-03-30  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2025-09-03  Patrick Palka  
+ 
+ 	PR c++/97740
+ 	* pt.cc (tsubst_expr) : Don't check access
+ 	when the given member is already a FIELD_DECL.
+ 
+ 2026-03-22  Marek Polacek  
+ 
+ 	Backported from master:
+ 	2026-03-16  Marek Polacek  
+ 
+ 	PR c++/124489
+ 	* error.cc (dump_type) : Use pp_cxx_ws_string
+ 	instead of pp_string.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-12  Jakub Jelinek  
+ 
+ 	* parser.cc (cp_parser_omp_taskwait): Set TREE_TYPE of OMP_TASK
+ 	to void_type_node rather than void_node.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-17  Jakub Jelinek  
+ 
+ 	PR c++/120685
+ 	* typeck2.cc (build_functional_cast_1): For C++23 auto(x)
+ 	without tf_warning or tf_error return error_mark_node instead of
+ 	emitting pedwarn and handling it.
+ 	* semantics.cc (finish_compound_literal): Similarly for C++26
+ 	auto{x}.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-09  Jakub Jelinek  
+ 
+ 	PR c++/123889
+ 	* constexpr.cc (explain_invalid_constexpr_fn): Diagnose
+ 	NULL or error_mark_node massaged on non-constructor.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-27  Jakub Jelinek  
+ 
+ 	PR c++/123578
+ 	* tree.cc (cxx_printable_name_internal): Call lang_decl_name before
+ 	finding the slot to cache it in and repeat search in the cache
+ 	after the call.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-12-19  Jakub Jelinek  
+ 
+ 	PR c++/91388
+ 	* semantics.cc (finish_static_assert): Suppress -Wreturn-type warnings
+ 	in functions with failed assertions.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-12-19  Jakub Jelinek  
+ 
+ 	PR c++/122772
+ 	* tree.cc (cp_stabilize_bitfield_reference): New function.
+ 	(cp_stabilize_reference): Use it for stabilization of
+ 	clk_bitfield or clk_packed lvalues.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-12-19  Jakub Jelinek  
+ 
+ 	PR c++/122834
+ 	* typeck.cc (cp_compare_floating_point_conversion_ranks): Return
+ 	3 if fmt2->b is 10 except for _Float16 vs. _Decimal128, in that
+ 	case return -2.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-21  Jakub Jelinek  
+ 
+ 	PR c++/121445
+ 	* constexpr.cc (build_data_member_initialization): Just return
+ 	false if member is COMPONENT_REF of COMPONENT_REF with
+ 	VAR_P get_base_address.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-20  Jakub Jelinek  
+ 
+ 	PR c++/120876
+ 	* pt.cc (tsubst_baselink): Move maybe_incomplete handling after
+ 	!baselink handling.
+ 
+ 2026-03-13  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-01-30  Patrick Palka  
+ 
+ 	PR c++/123845
+ 	PR libstdc++/114865
+ 	* constexpr.cc (build_data_member_initialization): Remove
+ 	C++11-specific recognition of MODIFY_EXPR.
+ 	(check_constexpr_ctor_body): Relax error diagnostic to a
+ 	pedwarn and don't clear DECL_DECLARED_CONSTEXPR_P upon
+ 	error.  Return true if complaining.
+ 
+ 2026-03-13  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-01-27  Patrick Palka  
+ 
+ 	PR c++/123676
+ 	* pt.cc (tsubst_pack_expansion): Relax unsubsituted_packs
+ 	assert to allow !processing_template_decl when args is
+ 	NULL_TREE.
+ 
+ 2026-03-12  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-01-27  Patrick Palka  
+ 
+ 	PR c++/122494
+ 	PR c++/123814
+ 	* constexpr.cc (cxx_eval_outermost_constant_expr): Clear
+ 	uid_sensitive_constexpr_evaluation_value when mce_true.
+ 
+ 2025-09-15  Matthias Kretz  
+ 
+ 	Backported from master:
+ 	2025-09-09  Matthias Kretz  
+ 
+ 	PR c++/121801
+ 	* mangle.cc (write_real_cst): Handle 16-bit real and assert
+ 	that reals have 16 bits or a multiple of 32 bits.
+ 
+ 2025-08-08  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2025-08-04  Patrick Palka  
+ 
+ 	PR c++/120620
+ 	* constexpr.cc (cxx_dynamic_cast_fn_p): Return true only
+ 	for synthesized __dynamic_cast.
+ 
+ 2025-07-03  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-07-03  Jakub Jelinek  
+ 
+ 	PR c++/120940
+ 	* typeck.cc (cp_build_array_ref): Fix a pasto.
+ 
+ 2025-07-03  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-07-01  Jakub Jelinek  
+ 
+ 	PR c++/120471
+ 	* typeck.cc (cp_build_array_ref) : If idx is not
+ 	INTEGER_CST, don't optimize the case (but cp_default_conversion on
+ 	array early if it has ARRAY_TYPE) or use
+ 	SAVE_EXPR , SAVE_EXPR , SAVE_EXPR  as new op0 depending
+ 	on flag_strong_eval_order and whether op1 and op2 are arrays with
+ 	invariant address or tree invariant pointers.  Formatting fixes.
+ 
+ 2025-06-05  Jason Merrill  
+ 
+ 	PR c++/120123
+ 	* lambda.cc (nonlambda_method_basetype): Look through lambdas
+ 	even when current_class_ref is null.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/gcc/cp/constexpr.cc gcc-13.5.0-RC-20260904/gcc/cp/constexpr.cc
*** gcc-13.4.0/gcc/cp/constexpr.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/constexpr.cc	Fri Sep  4 07:35:08 2026
*************** build_data_member_initialization (tree t
*** 402,412 ****
      }
    if (TREE_CODE (t) == CONVERT_EXPR)
      t = TREE_OPERAND (t, 0);
!   if (TREE_CODE (t) == INIT_EXPR
!       /* vptr initialization shows up as a MODIFY_EXPR.  In C++14 we only
! 	 use what this function builds for cx_check_missing_mem_inits, and
! 	 assignment in the ctor body doesn't count.  */
!       || (cxx_dialect < cxx14 && TREE_CODE (t) == MODIFY_EXPR))
      {
        member = TREE_OPERAND (t, 0);
        init = break_out_target_exprs (TREE_OPERAND (t, 1));
--- 402,408 ----
      }
    if (TREE_CODE (t) == CONVERT_EXPR)
      t = TREE_OPERAND (t, 0);
!   if (TREE_CODE (t) == INIT_EXPR)
      {
        member = TREE_OPERAND (t, 0);
        init = break_out_target_exprs (TREE_OPERAND (t, 1));
*************** build_data_member_initialization (tree t
*** 467,472 ****
--- 463,471 ----
        if (TREE_CODE (aggr) != COMPONENT_REF)
  	/* Normal member initialization.  */
  	member = TREE_OPERAND (member, 1);
+       else if (VAR_P (get_base_address (aggr)))
+ 	/* Initializing a local variable, don't add anything.  */
+ 	return true;
        else if (ANON_AGGR_TYPE_P (TREE_TYPE (aggr)))
  	/* Initializing a member of an anonymous union.  */
  	return build_anon_member_initialization (member, init, vec);
*************** check_constexpr_ctor_body (tree last, tr
*** 565,575 ****
    else if (list != last
  	   && !check_constexpr_ctor_body_1 (last, list))
      ok = false;
!   if (!ok)
      {
!       if (complain)
! 	error ("% constructor does not have empty body");
!       DECL_DECLARED_CONSTEXPR_P (current_function_decl) = false;
      }
    return ok;
  }
--- 564,574 ----
    else if (list != last
  	   && !check_constexpr_ctor_body_1 (last, list))
      ok = false;
!   if (!ok && complain)
      {
!       pedwarn (input_location, OPT_Wc__14_extensions,
! 	       "% constructor does not have empty body");
!       ok = true;
      }
    return ok;
  }
*************** explain_invalid_constexpr_fn (tree fun)
*** 1097,1102 ****
--- 1096,1104 ----
  	  require_potential_rvalue_constant_expression (body);
  	  if (DECL_CONSTRUCTOR_P (fun))
  	    cx_check_missing_mem_inits (DECL_CONTEXT (fun), body, true);
+ 	  else if (body == NULL_TREE || body == error_mark_node)
+ 	    error ("body of % function %qD not a return-statement",
+ 		   fun);
  	}
      }
  }
*************** cxx_dynamic_cast_fn_p (tree fndecl)
*** 2272,2278 ****
  {
    return (cxx_dialect >= cxx20
  	  && id_equal (DECL_NAME (fndecl), "__dynamic_cast")
! 	  && CP_DECL_CONTEXT (fndecl) == abi_node);
  }
  
  /* Often, we have an expression in the form of address + offset, e.g.
--- 2274,2284 ----
  {
    return (cxx_dialect >= cxx20
  	  && id_equal (DECL_NAME (fndecl), "__dynamic_cast")
! 	  && CP_DECL_CONTEXT (fndecl) == abi_node
! 	  /* Only consider implementation-detail __dynamic_cast calls that
! 	     correspond to a dynamic_cast, and ignore direct calls to
! 	     abi::__dynamic_cast.  */
! 	  && DECL_ARTIFICIAL (fndecl));
  }
  
  /* Often, we have an expression in the form of address + offset, e.g.
*************** cxx_eval_call_expression (const constexp
*** 2742,2747 ****
--- 2748,2764 ----
  	  gcc_assert (arg0);
  	  if (IDENTIFIER_NEW_OP_P (DECL_NAME (fun)))
  	    {
+ 	      /* FIXME: We should not get here; the VERIFY_CONSTANT above
+ 		 should have already caught it.  But currently a conversion
+ 		 from pointer type to arithmetic type is only considered
+ 		 non-constant for CONVERT_EXPRs, not NOP_EXPRs.  */
+ 	      if (!tree_fits_uhwi_p (arg0))
+ 		{
+ 		  if (!ctx->quiet)
+ 		    error_at (loc, "cannot allocate array: size not constant");
+ 		  *non_constant_p = true;
+ 		  return t;
+ 		}
  	      tree type = build_array_type_nelts (char_type_node,
  						  tree_to_uhwi (arg0));
  	      tree var = build_decl (loc, VAR_DECL,
*************** cxx_eval_outermost_constant_expr (tree t
*** 8378,8383 ****
--- 8395,8411 ----
  	r = TARGET_EXPR_INITIAL (r);
      }
  
+   /* uid_sensitive_constexpr_evaluation_value restricts warning-dependent
+      constexpr evaluation to avoid unnecessary template instantiation, and is
+      always done with mce_unknown.  But due to gaps in the restriction logic
+      we may still end up taking an evaluation path that in turn requires
+      manifestly constant evaluation, and such evaluation must not be
+      restricted since it likely has semantic consequences.
+      TODO: Remove/replace the mechanism in GCC 17.  */
+   auto uids = make_temp_override (uid_sensitive_constexpr_evaluation_value);
+   if (ctx.manifestly_const_eval == mce_true)
+     uid_sensitive_constexpr_evaluation_value = false;
+ 
    auto_vec cleanups;
    global_ctx.cleanups = &cleanups;
  
diff -Nrcpad gcc-13.4.0/gcc/cp/cvt.cc gcc-13.5.0-RC-20260904/gcc/cp/cvt.cc
*** gcc-13.4.0/gcc/cp/cvt.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/cvt.cc	Fri Sep  4 07:35:08 2026
*************** convert_to_void (tree expr, impl_conv_vo
*** 1185,1191 ****
  
    /* Explicitly evaluate void-converted concept checks since their
       satisfaction may produce ill-formed programs.  */
!    if (concept_check_p (expr))
       expr = evaluate_concept_check (expr);
  
    if (VOID_TYPE_P (TREE_TYPE (expr)))
--- 1185,1191 ----
  
    /* Explicitly evaluate void-converted concept checks since their
       satisfaction may produce ill-formed programs.  */
!    if (concept_check_p (expr) && !cp_unevaluated_operand)
       expr = evaluate_concept_check (expr);
  
    if (VOID_TYPE_P (TREE_TYPE (expr)))
diff -Nrcpad gcc-13.4.0/gcc/cp/error.cc gcc-13.5.0-RC-20260904/gcc/cp/error.cc
*** gcc-13.4.0/gcc/cp/error.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/error.cc	Fri Sep  4 07:35:08 2026
*************** dump_type (cxx_pretty_printer *pp, tree
*** 722,728 ****
        break;
  
      case NULLPTR_TYPE:
!       pp_string (pp, "std::nullptr_t");
        break;
  
      default:
--- 722,728 ----
        break;
  
      case NULLPTR_TYPE:
!       pp_cxx_ws_string (pp, "std::nullptr_t");
        break;
  
      default:
diff -Nrcpad gcc-13.4.0/gcc/cp/lambda.cc gcc-13.5.0-RC-20260904/gcc/cp/lambda.cc
*** gcc-13.4.0/gcc/cp/lambda.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/lambda.cc	Fri Sep  4 07:35:08 2026
*************** current_nonlambda_function (void)
*** 975,986 ****
  tree
  nonlambda_method_basetype (void)
  {
-   if (!current_class_ref)
-     return NULL_TREE;
- 
    tree type = current_class_type;
    if (!type || !LAMBDA_TYPE_P (type))
!     return type;
  
    while (true)
      {
--- 975,983 ----
  tree
  nonlambda_method_basetype (void)
  {
    tree type = current_class_type;
    if (!type || !LAMBDA_TYPE_P (type))
!     return current_class_ref ? type : NULL_TREE;
  
    while (true)
      {
diff -Nrcpad gcc-13.4.0/gcc/cp/mangle.cc gcc-13.5.0-RC-20260904/gcc/cp/mangle.cc
*** gcc-13.4.0/gcc/cp/mangle.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/mangle.cc	Fri Sep  4 07:35:08 2026
*************** write_real_cst (const tree value)
*** 1999,2009 ****
    int i, limit, dir;
  
    tree type = TREE_TYPE (value);
!   int words = GET_MODE_BITSIZE (SCALAR_FLOAT_TYPE_MODE (type)) / 32;
  
    real_to_target (target_real, &TREE_REAL_CST (value),
  		  TYPE_MODE (type));
  
    /* The value in target_real is in the target word order,
       so we must write it out backward if that happens to be
       little-endian.  write_number cannot be used, it will
--- 1999,2022 ----
    int i, limit, dir;
  
    tree type = TREE_TYPE (value);
!   int bits = GET_MODE_BITSIZE (SCALAR_FLOAT_TYPE_MODE (type));
!   int words = bits / 32;
  
    real_to_target (target_real, &TREE_REAL_CST (value),
  		  TYPE_MODE (type));
  
+   if (words == 0)
+     {
+       /* _Float16 and std::bfloat16_t are the only supported types smaller than
+ 	 32 bits.  */
+       gcc_assert (bits == 16);
+       sprintf (buffer, "%04lx", (unsigned long) target_real[0]);
+       write_chars (buffer, 4);
+       return;
+     }
+ 
+   gcc_assert (bits % 32 == 0);
+ 
    /* The value in target_real is in the target word order,
       so we must write it out backward if that happens to be
       little-endian.  write_number cannot be used, it will
diff -Nrcpad gcc-13.4.0/gcc/cp/parser.cc gcc-13.5.0-RC-20260904/gcc/cp/parser.cc
*** gcc-13.4.0/gcc/cp/parser.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/parser.cc	Fri Sep  4 07:35:08 2026
*************** cp_parser_class_specifier (cp_parser* pa
*** 26231,26236 ****
--- 26231,26237 ----
        case CPP_SEMICOLON:
        case CPP_MULT:
        case CPP_AND:
+       case CPP_AND_AND:
        case CPP_OPEN_PAREN:
        case CPP_CLOSE_PAREN:
        case CPP_COMMA:
*************** cp_parser_omp_clause_proc_bind (cp_parse
*** 40781,40787 ****
    return c;
  
   invalid_kind:
!   cp_parser_error (parser, "invalid depend kind");
   resync_fail:
    cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
  					 /*or_comma=*/false,
--- 40782,40788 ----
    return c;
  
   invalid_kind:
!   cp_parser_error (parser, "invalid proc_bind kind");
   resync_fail:
    cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
  					 /*or_comma=*/false,
*************** cp_parser_omp_clause_device_type (cp_par
*** 40831,40837 ****
    return c;
  
   invalid_kind:
!   cp_parser_error (parser, "invalid depend kind");
   resync_fail:
    cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
  					 /*or_comma=*/false,
--- 40832,40838 ----
    return c;
  
   invalid_kind:
!   cp_parser_error (parser, "expected %, % or %");
   resync_fail:
    cp_parser_skip_to_closing_parenthesis (parser, /*recovering=*/true,
  					 /*or_comma=*/false,
*************** cp_parser_omp_taskwait (cp_parser *parse
*** 44827,44833 ****
    if (clauses)
      {
        tree stmt = make_node (OMP_TASK);
!       TREE_TYPE (stmt) = void_node;
        OMP_TASK_CLAUSES (stmt) = clauses;
        OMP_TASK_BODY (stmt) = NULL_TREE;
        SET_EXPR_LOCATION (stmt, pragma_tok->location);
--- 44828,44834 ----
    if (clauses)
      {
        tree stmt = make_node (OMP_TASK);
!       TREE_TYPE (stmt) = void_type_node;
        OMP_TASK_CLAUSES (stmt) = clauses;
        OMP_TASK_BODY (stmt) = NULL_TREE;
        SET_EXPR_LOCATION (stmt, pragma_tok->location);
diff -Nrcpad gcc-13.4.0/gcc/cp/pt.cc gcc-13.5.0-RC-20260904/gcc/cp/pt.cc
*** gcc-13.4.0/gcc/cp/pt.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/pt.cc	Fri Sep  4 07:35:08 2026
*************** static tree enclosing_instantiation_of (
*** 221,226 ****
--- 221,227 ----
  static void instantiate_body (tree pattern, tree args, tree d, bool nested);
  static tree maybe_dependent_member_ref (tree, tree, tsubst_flags_t, tree);
  static void mark_template_arguments_used (tree, tree);
+ static void mark_template_arguments_used_1 (tree);
  
  /* Make the current scope suitable for access checking when we are
     processing T.  T can be FUNCTION_DECL for instantiated function
*************** has_value_dependent_address (tree op)
*** 6904,6910 ****
        if (VAR_P (op)
  	  && TREE_STATIC (op)
  	  && TREE_CODE (ctx) == FUNCTION_DECL
! 	  && type_dependent_expression_p (ctx))
  	return true;
      }
  
--- 6905,6912 ----
        if (VAR_P (op)
  	  && TREE_STATIC (op)
  	  && TREE_CODE (ctx) == FUNCTION_DECL
! 	  && DECL_TEMPLATE_INFO (ctx)
! 	  && any_dependent_template_arguments_p (DECL_TI_ARGS (ctx)))
  	return true;
      }
  
*************** any_template_parm_r (tree t, void *data)
*** 10859,10865 ****
        break;
  
      case TEMPLATE_PARM_INDEX:
!       WALK_SUBTREE (TREE_TYPE (t));
        break;
  
      case TEMPLATE_DECL:
--- 10861,10870 ----
        break;
  
      case TEMPLATE_PARM_INDEX:
!       /* No need to consider template parameters within the type of an NTTP:
! 	 substitution into an NTTP is done directly with the corresponding
! 	 template argument, and its type only comes into play earlier during
! 	 coercion.  */
        break;
  
      case TEMPLATE_DECL:
*************** tsubst_pack_expansion (tree t, tree args
*** 13541,13547 ****
  	  /* We can't substitute for this parameter pack.  We use a flag as
  	     well as the missing_level counter because function parameter
  	     packs don't have a level.  */
! 	  gcc_assert (processing_template_decl || is_auto (parm_pack));
  	  unsubstituted_packs = true;
  	}
      }
--- 13546,13553 ----
  	  /* We can't substitute for this parameter pack.  We use a flag as
  	     well as the missing_level counter because function parameter
  	     packs don't have a level.  */
! 	  gcc_assert (processing_template_decl || is_auto (parm_pack)
! 		      || args == NULL_TREE);
  	  unsubstituted_packs = true;
  	}
      }
*************** tsubst_decl (tree t, tree args, tsubst_f
*** 15118,15128 ****
  	    cp_apply_type_quals_to_decl (cp_type_quals (type), r);
  
  	    if (DECL_C_BIT_FIELD (r))
! 	      /* For bit-fields, DECL_BIT_FIELD_REPRESENTATIVE gives the
! 		 number of bits.  */
! 	      DECL_BIT_FIELD_REPRESENTATIVE (r)
! 		= tsubst_expr (DECL_BIT_FIELD_REPRESENTATIVE (t), args,
! 			       complain, in_decl);
  	    if (DECL_INITIAL (t))
  	      {
  		/* Set up DECL_TEMPLATE_INFO so that we can get at the
--- 15124,15149 ----
  	    cp_apply_type_quals_to_decl (cp_type_quals (type), r);
  
  	    if (DECL_C_BIT_FIELD (r))
! 	      {
! 		/* For bit-fields, DECL_BIT_FIELD_REPRESENTATIVE gives the
! 		   number of bits.  */
! 		tree width
! 		  = tsubst_expr (DECL_BIT_FIELD_REPRESENTATIVE (t), args,
! 				 complain, in_decl);
! 		if (width
! 		    && width != error_mark_node
! 		    && !type_dependent_expression_p (width)
! 		    && !INTEGRAL_OR_UNSCOPED_ENUMERATION_TYPE_P
! 			 (TREE_TYPE (width)))
! 		  {
! 		    if (complain & tf_error)
! 		      error_at (DECL_SOURCE_LOCATION (t),
! 		      		"width of bit-field %qD has non-integral "
! 				"type %qT", r, TREE_TYPE (width));
! 		    RETURN (error_mark_node);
! 		  }
! 		DECL_BIT_FIELD_REPRESENTATIVE (r) = width;
! 	      }
  	    if (DECL_INITIAL (t))
  	      {
  		/* Set up DECL_TEMPLATE_INFO so that we can get at the
*************** tsubst_baselink (tree baselink, tree obj
*** 16940,16945 ****
--- 16961,16975 ----
        bool maybe_incomplete = BASELINK_FUNCTIONS_MAYBE_INCOMPLETE_P (baselink);
        baselink = lookup_fnfields (qualifying_scope, name, /*protect=*/1,
  				  complain);
+       if (!baselink)
+ 	{
+ 	  if ((complain & tf_error)
+ 	      && constructor_name_p (name, qualifying_scope))
+ 	    error ("cannot call constructor %<%T::%D%> directly",
+ 		   qualifying_scope, name);
+ 	  return error_mark_node;
+ 	}
+ 
        if (maybe_incomplete)
  	{
  	  /* Filter out from the new lookup set those functions which didn't
*************** tsubst_baselink (tree baselink, tree obj
*** 16953,16967 ****
  	  BASELINK_FUNCTIONS_MAYBE_INCOMPLETE_P (baselink) = true;
  	}
  
-       if (!baselink)
- 	{
- 	  if ((complain & tf_error)
- 	      && constructor_name_p (name, qualifying_scope))
- 	    error ("cannot call constructor %<%T::%D%> directly",
- 		   qualifying_scope, name);
- 	  return error_mark_node;
- 	}
- 
        fns = BASELINK_FUNCTIONS (baselink);
      }
    else
--- 16983,16988 ----
*************** tsubst_copy (tree t, tree args, tsubst_f
*** 17921,17932 ****
  
      case OFFSET_REF:
        {
! 	tree type = tsubst (TREE_TYPE (t), args, complain, in_decl);
  	tree op0 = tsubst_copy (TREE_OPERAND (t, 0), args, complain, in_decl);
  	tree op1 = tsubst_copy (TREE_OPERAND (t, 1), args, complain, in_decl);
  	r = build2 (code, type, op0, op1);
  	PTRMEM_OK_P (r) = PTRMEM_OK_P (t);
! 	if (!mark_used (TREE_OPERAND (r, 1), complain)
  	    && !(complain & tf_error))
  	  return error_mark_node;
  	return r;
--- 17942,17957 ----
  
      case OFFSET_REF:
        {
! 	/* We should only get here for an OFFSET_REF like A::m; a .* in a
! 	   template is represented as a DOTSTAR_EXPR.  */
! 	gcc_checking_assert
! 	  (same_type_p (TREE_TYPE (t), TREE_TYPE (TREE_OPERAND (t, 1))));
  	tree op0 = tsubst_copy (TREE_OPERAND (t, 0), args, complain, in_decl);
  	tree op1 = tsubst_copy (TREE_OPERAND (t, 1), args, complain, in_decl);
+ 	tree type = TREE_TYPE (op1);
  	r = build2 (code, type, op0, op1);
  	PTRMEM_OK_P (r) = PTRMEM_OK_P (t);
! 	if (!mark_used (op1, complain)
  	    && !(complain & tf_error))
  	  return error_mark_node;
  	return r;
*************** tsubst_copy_and_build (tree t,
*** 21510,21519 ****
  	  }
  	else if (TREE_CODE (member) == FIELD_DECL)
  	  {
  	    r = finish_non_static_data_member (member, object, NULL_TREE,
  					       complain);
! 	    if (TREE_CODE (r) == COMPONENT_REF)
! 	      REF_PARENTHESIZED_P (r) = REF_PARENTHESIZED_P (t);
  	    RETURN (r);
  	  }
  	else if (type_dependent_expression_p (object))
--- 21535,21550 ----
  	  }
  	else if (TREE_CODE (member) == FIELD_DECL)
  	  {
+ 	    /* Assume access of this FIELD_DECL has already been checked; we
+ 	       don't recheck it to avoid bogus access errors when substituting
+ 	       a reduced constant initializer (97740).  */
+ 	    gcc_checking_assert (TREE_CODE (TREE_OPERAND (t, 1)) == FIELD_DECL);
+ 	    push_deferring_access_checks (dk_deferred);
  	    r = finish_non_static_data_member (member, object, NULL_TREE,
  					       complain);
! 	    pop_deferring_access_checks ();
! 	    if (REF_PARENTHESIZED_P (t))
! 	      r = force_paren_expr (r);
  	    RETURN (r);
  	  }
  	else if (type_dependent_expression_p (object))
*************** mark_template_arguments_used (tree tmpl,
*** 22000,22005 ****
--- 22031,22044 ----
    /* We already marked outer arguments when specializing the context.  */
    args = INNERMOST_TEMPLATE_ARGS (args);
  
+   mark_template_arguments_used_1 (args);
+ }
+ 
+ /* Main recursive part of the above.  */
+ 
+ static void
+ mark_template_arguments_used_1 (tree args)
+ {
    for (tree arg : tree_vec_range (args))
      {
        /* A (pointer/reference to) function or variable NTTP argument.  */
*************** mark_template_arguments_used (tree tmpl,
*** 22040,22045 ****
--- 22079,22086 ----
  	  cp_walk_tree_without_duplicates (&DECL_INITIAL (arg),
  					   mark_used_r, nullptr);
  	}
+       else if (TREE_CODE (arg) == NONTYPE_ARGUMENT_PACK)
+ 	mark_template_arguments_used_1 (ARGUMENT_PACK_ARGS (arg));
      }
  }
  
diff -Nrcpad gcc-13.4.0/gcc/cp/semantics.cc gcc-13.5.0-RC-20260904/gcc/cp/semantics.cc
*** gcc-13.4.0/gcc/cp/semantics.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/semantics.cc	Fri Sep  4 07:35:08 2026
*************** finish_compound_literal (tree type, tree
*** 3246,3254 ****
  	  return error_mark_node;
  	}
        else if (cxx_dialect < cxx23)
! 	pedwarn (input_location, OPT_Wc__23_extensions,
! 		 "% only available with "
! 		 "%<-std=c++2b%> or %<-std=gnu++2b%>");
        type = do_auto_deduction (type, compound_literal, type, complain,
  				adc_variable_type);
        if (type == error_mark_node)
--- 3246,3257 ----
  	  return error_mark_node;
  	}
        else if (cxx_dialect < cxx23)
! 	{
! 	  if ((complain & tf_warning_or_error) != 0)
! 	    pedwarn (input_location, OPT_Wc__23_extensions,
! 		     "% only available with "
! 		     "%<-std=c++2b%> or %<-std=gnu++2b%>");
! 	}
        type = do_auto_deduction (type, compound_literal, type, complain,
  				adc_variable_type);
        if (type == error_mark_node)
*************** finish_static_assert (tree condition, tr
*** 11362,11367 ****
--- 11365,11380 ----
  		      TREE_STRING_POINTER (message));
  
  	  diagnose_failing_condition (bad, cloc, show_expr_p);
+ 
+ 	  /* Suppress -Wreturn-type for functions with failed static_asserts.
+ 	     Otherwise templates like:
+ 	     if constexpr (whatever)
+ 	       return something (args);
+ 	     else
+ 	       static_assert (false, "explanation");
+ 	     get a useless extra -Wreturn-type warning.  */
+ 	  if (current_function_decl)
+ 	    suppress_warning (current_function_decl, OPT_Wreturn_type);
  	}
        else if (condition && condition != error_mark_node)
  	{
diff -Nrcpad gcc-13.4.0/gcc/cp/tree.cc gcc-13.5.0-RC-20260904/gcc/cp/tree.cc
*** gcc-13.4.0/gcc/cp/tree.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/tree.cc	Fri Sep  4 07:35:08 2026
*************** bitfield_p (const_tree ref)
*** 404,409 ****
--- 404,486 ----
    return (lvalue_kind (ref) & clk_bitfield);
  }
  
+ /* C++-specific version of stabilize_reference for bit-fields and
+    DECL_PACKED fields.  We can't bind a reference to those.  */
+ 
+ static tree
+ cp_stabilize_bitfield_reference (tree ref)
+ {
+   tree op1, op2, op3;
+   STRIP_ANY_LOCATION_WRAPPER (ref);
+   switch (TREE_CODE (ref))
+     {
+     case VAR_DECL:
+     case PARM_DECL:
+     case RESULT_DECL:
+     CASE_CONVERT:
+     case FLOAT_EXPR:
+     case FIX_TRUNC_EXPR:
+     case INDIRECT_REF:
+     case COMPONENT_REF:
+     case BIT_FIELD_REF:
+     case ARRAY_REF:
+     case ARRAY_RANGE_REF:
+     case ERROR_MARK:
+     case REALPART_EXPR:
+     case IMAGPART_EXPR:
+     default:
+       break;
+     case COMPOUND_EXPR:
+       op2 = cp_stabilize_bitfield_reference (TREE_OPERAND (ref, 1));
+       if (op2 == TREE_OPERAND (ref, 1))
+ 	return ref;
+       op1 = TREE_OPERAND (ref, 0);
+       if (TREE_SIDE_EFFECTS (op1))
+ 	{
+ 	  if (VOID_TYPE_P (TREE_TYPE (op1)))
+ 	    op1 = save_expr (op1);
+ 	  else
+ 	    {
+ 	      op1 = build2 (COMPOUND_EXPR, void_type_node, op1,
+ 			    void_node);
+ 	      op1 = save_expr (op1);
+ 	    }
+ 	}
+       return build2 (COMPOUND_EXPR, TREE_TYPE (op2), op1, op2);
+     case COND_EXPR:
+       op1 = TREE_OPERAND (ref, 0);
+       op2 = TREE_OPERAND (ref, 1);
+       op3 = TREE_OPERAND (ref, 2);
+       if (op2 && TREE_CODE (op2) != THROW_EXPR)
+ 	op2 = cp_stabilize_bitfield_reference (op2);
+       if (TREE_CODE (op3) != THROW_EXPR)
+ 	op3 = cp_stabilize_bitfield_reference (op3);
+       if (op2 == NULL_TREE)
+ 	op1 = cp_stabilize_bitfield_reference (op1);
+       if (op1 == TREE_OPERAND (ref, 0)
+ 	  && op2 == TREE_OPERAND (ref, 1)
+ 	  && op3 == TREE_OPERAND (ref, 2))
+ 	return ref;
+       if (op2 != NULL_TREE && TREE_SIDE_EFFECTS (op1))
+ 	op1 = save_expr (op1);
+       return build3 (COND_EXPR, TREE_TYPE (ref), op1, op2, op3);
+     case PREINCREMENT_EXPR:
+     case PREDECREMENT_EXPR:
+       op1 = cp_stabilize_bitfield_reference (TREE_OPERAND (ref, 0));
+       if (op1 == TREE_OPERAND (ref, 0))
+ 	return ref;
+       return build2 (COMPOUND_EXPR, TREE_TYPE (ref),
+ 		     build2 (TREE_CODE (ref), TREE_TYPE (ref), op1,
+ 			     TREE_OPERAND (ref, 0)), op1);
+     case PAREN_EXPR:
+       op1 = cp_stabilize_bitfield_reference (TREE_OPERAND (ref, 0));
+       if (op1 == TREE_OPERAND (ref, 0))
+ 	return ref;
+       return build1 (PAREN_EXPR, TREE_TYPE (ref), op1);
+     }
+   return stabilize_reference (ref);
+ }
+ 
  /* C++-specific version of stabilize_reference.  */
  
  tree
*************** cp_stabilize_reference (tree ref)
*** 435,440 ****
--- 512,519 ----
        cp_lvalue_kind kind = lvalue_kind (ref);
        if ((kind & ~clk_class) != clk_none)
  	{
+ 	  if (kind & (clk_bitfield | clk_packed))
+ 	    return cp_stabilize_bitfield_reference (ref);
  	  tree type = unlowered_expr_type (ref);
  	  bool rval = !!(kind & clk_rvalueref);
  	  type = cp_build_reference_type (type, rval);
*************** cxx_printable_name_internal (tree decl,
*** 2714,2719 ****
--- 2793,2807 ----
        /* yes, so return it.  */
        return print_ring[i];
  
+   const char *ret = lang_decl_name (decl, v, translate);
+ 
+   /* The lang_decl_name call could have called this function recursively,
+      so check again.  */
+   for (i = 0; i < PRINT_RING_SIZE; i++)
+     if (uid_ring[i] == DECL_UID (decl) && translate == trans_ring[i])
+       /* yes, so return it.  */
+       return print_ring[i];
+ 
    if (++ring_counter == PRINT_RING_SIZE)
      ring_counter = 0;
  
*************** cxx_printable_name_internal (tree decl,
*** 2733,2739 ****
  
    free (print_ring[ring_counter]);
  
!   print_ring[ring_counter] = xstrdup (lang_decl_name (decl, v, translate));
    uid_ring[ring_counter] = DECL_UID (decl);
    trans_ring[ring_counter] = translate;
    return print_ring[ring_counter];
--- 2821,2827 ----
  
    free (print_ring[ring_counter]);
  
!   print_ring[ring_counter] = xstrdup (ret);
    uid_ring[ring_counter] = DECL_UID (decl);
    trans_ring[ring_counter] = translate;
    return print_ring[ring_counter];
diff -Nrcpad gcc-13.4.0/gcc/cp/typeck.cc gcc-13.5.0-RC-20260904/gcc/cp/typeck.cc
*** gcc-13.4.0/gcc/cp/typeck.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/typeck.cc	Fri Sep  4 07:35:08 2026
*************** cp_compare_floating_point_conversion_ran
*** 305,311 ****
  
    const struct real_format *fmt1 = REAL_MODE_FORMAT (TYPE_MODE (t1));
    const struct real_format *fmt2 = REAL_MODE_FORMAT (TYPE_MODE (t2));
!   gcc_assert (fmt1->b == 2 && fmt2->b == 2);
    /* For {ibm,mips}_extended_format formats, the type has variable
       precision up to ~2150 bits when the first double is around maximum
       representable double and second double is subnormal minimum.
--- 305,334 ----
  
    const struct real_format *fmt1 = REAL_MODE_FORMAT (TYPE_MODE (t1));
    const struct real_format *fmt2 = REAL_MODE_FORMAT (TYPE_MODE (t2));
!   /* Currently, extended floating point types are only binary, and
!      they never have a proper subset or superset of values with
!      decimal floating point types except for the _Float16 vs. _Decimal128
!      pair, so return 3 for unordered conversion ranks.  */
!   gcc_assert (fmt1->b == 2);
!   if (fmt2->b == 10)
!     {
!       /* _Float16 needs at most 21 decimal digits (e.g.
! 	 0x1.a3cp-14f16 is exactly 0.000100076198577880859375DL),
! 	 so it is not a proper subset of _Decimal64 but is subset
! 	 of _Decimal128.  While std::bfloat16_t needs at most 96
! 	 decimal digits, so even _Decimal128 doesn't cover it.
! 	 _Float32 has at least one value which needs 112 decimal
! 	 digits, _Float64 at least 767 decimal digits.  */
!       if (fmt1->emin == -13
! 	  && fmt1->emax == 16
! 	  && fmt1->p == 11
! 	  && fmt2->emin == -6142
! 	  && fmt2->emax == 6145
! 	  && fmt2->p == 34)
! 	return -2;
!       return 3;
!     }
!   gcc_assert (fmt2->b == 2);
    /* For {ibm,mips}_extended_format formats, the type has variable
       precision up to ~2150 bits when the first double is around maximum
       representable double and second double is subnormal minimum.
*************** cp_build_array_ref (location_t loc, tree
*** 3961,3973 ****
        }
  
      case COND_EXPR:
!       ret = build_conditional_expr
! 	       (loc, TREE_OPERAND (array, 0),
! 	       cp_build_array_ref (loc, TREE_OPERAND (array, 1), idx,
! 				   complain),
! 	       cp_build_array_ref (loc, TREE_OPERAND (array, 2), idx,
! 				   complain),
! 	       complain);
        protected_set_expr_location (ret, loc);
        return ret;
  
--- 3984,4112 ----
        }
  
      case COND_EXPR:
!       tree op0, op1, op2;
!       op0 = TREE_OPERAND (array, 0);
!       op1 = TREE_OPERAND (array, 1);
!       op2 = TREE_OPERAND (array, 2);
!       if (TREE_SIDE_EFFECTS (idx) || !tree_invariant_p (idx))
! 	{
! 	  /* If idx could possibly have some SAVE_EXPRs, turning
! 	     (op0 ? op1 : op2)[idx] into
! 	     op0 ? op1[idx] : op2[idx] can lead into temporaries
! 	     initialized in one conditional path and uninitialized
! 	     uses of them in the other path.
! 	     And if idx is a really large expression, evaluating it
! 	     twice is also not optimal.
! 	     On the other side, op0 must be sequenced before evaluation
! 	     of op1 and op2 and for C++17 op0, op1 and op2 must be
! 	     sequenced before idx.
! 	     If idx is INTEGER_CST, we can just do the optimization
! 	     without any SAVE_EXPRs, if op1 and op2 are both ARRAY_TYPE
! 	     VAR_DECLs or COMPONENT_REFs thereof (so their address
! 	     is constant or relative to frame), optimize into
! 	     (SAVE_EXPR , SAVE_EXPR , SAVE_EXPR )
! 	     ? op1[SAVE_EXPR ] : op2[SAVE_EXPR ]
! 	     Otherwise avoid this optimization.  */
! 	  if (flag_strong_eval_order == 2)
! 	    {
! 	      if (TREE_CODE (TREE_TYPE (array)) == ARRAY_TYPE)
! 		{
! 		  tree xop1 = op1;
! 		  tree xop2 = op2;
! 		  while (xop1 && handled_component_p (xop1))
! 		    {
! 		      switch (TREE_CODE (xop1))
! 			{
! 			case ARRAY_REF:
! 			case ARRAY_RANGE_REF:
! 			  if (!tree_invariant_p (TREE_OPERAND (xop1, 1))
! 			      || TREE_OPERAND (xop1, 2) != NULL_TREE
! 			      || TREE_OPERAND (xop1, 3) != NULL_TREE)
! 			    {
! 			      xop1 = NULL_TREE;
! 			      continue;
! 			    }
! 			  break;
! 
! 			case COMPONENT_REF:
! 			  if (TREE_OPERAND (xop1, 2) != NULL_TREE)
! 			    {
! 			      xop1 = NULL_TREE;
! 			      continue;
! 			    }
! 			  break;
! 
! 			default:
! 			  break;
! 			}
! 		      xop1 = TREE_OPERAND (xop1, 0);
! 		    }
! 		  if (xop1)
! 		    STRIP_ANY_LOCATION_WRAPPER (xop1);
! 		  while (xop2 && handled_component_p (xop2))
! 		    {
! 		      switch (TREE_CODE (xop2))
! 			{
! 			case ARRAY_REF:
! 			case ARRAY_RANGE_REF:
! 			  if (!tree_invariant_p (TREE_OPERAND (xop2, 1))
! 			      || TREE_OPERAND (xop2, 2) != NULL_TREE
! 			      || TREE_OPERAND (xop2, 3) != NULL_TREE)
! 			    {
! 			      xop2 = NULL_TREE;
! 			      continue;
! 			    }
! 			  break;
! 
! 			case COMPONENT_REF:
! 			  if (TREE_OPERAND (xop2, 2) != NULL_TREE)
! 			    {
! 			      xop2 = NULL_TREE;
! 			      continue;
! 			    }
! 			  break;
! 
! 			default:
! 			  break;
! 			}
! 		      xop2 = TREE_OPERAND (xop2, 0);
! 		    }
! 		  if (xop2)
! 		    STRIP_ANY_LOCATION_WRAPPER (xop2);
! 
! 		  if (!xop1
! 		      || !xop2
! 		      || !(CONSTANT_CLASS_P (xop1)
! 			   || decl_address_invariant_p (xop1))
! 		      || !(CONSTANT_CLASS_P (xop2)
! 			   || decl_address_invariant_p (xop2)))
! 		    {
! 		      /* Force default conversion on array if
! 			 we can't optimize this and array is ARRAY_TYPE
! 			 COND_EXPR, we can't leave COND_EXPRs with
! 			 ARRAY_TYPE in the IL.  */
! 		      array = cp_default_conversion (array, complain);
! 		      if (error_operand_p (array))
! 			return error_mark_node;
! 		      break;
! 		    }
! 		}
! 	      else if (!POINTER_TYPE_P (TREE_TYPE (array))
! 		       || !tree_invariant_p (op1)
! 		       || !tree_invariant_p (op2))
! 		break;
! 	    }
! 	  if (TREE_SIDE_EFFECTS (idx))
! 	    {
! 	      idx = save_expr (idx);
! 	      op0 = save_expr (op0);
! 	      tree tem = build_compound_expr (loc, op0, idx);
! 	      op0 = build_compound_expr (loc, tem, op0);
! 	    }
! 	}
!       op1 = cp_build_array_ref (loc, op1, idx, complain);
!       op2 = cp_build_array_ref (loc, op2, idx, complain);
!       ret = build_conditional_expr (loc, op0, op1, op2, complain);
        protected_set_expr_location (ret, loc);
        return ret;
  
*************** cxx_mark_addressable (tree exp, bool arr
*** 7823,7828 ****
--- 7962,7971 ----
  		    || DECL_IN_AGGR_P (x) == 0
  		    || TREE_STATIC (x)
  		    || DECL_EXTERNAL (x));
+ 	if (VAR_P (x)
+ 	    && DECL_ANON_UNION_VAR_P (x)
+ 	    && !TREE_ADDRESSABLE (x))
+ 	  cxx_mark_addressable (DECL_VALUE_EXPR (x));
  	/* Fall through.  */
  
        case RESULT_DECL:
diff -Nrcpad gcc-13.4.0/gcc/cp/typeck2.cc gcc-13.5.0-RC-20260904/gcc/cp/typeck2.cc
*** gcc-13.4.0/gcc/cp/typeck2.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/cp/typeck2.cc	Fri Sep  4 07:35:08 2026
*************** store_init_value (tree decl, tree init,
*** 914,920 ****
       that might fold away something that needs to be diagnosed at constexpr
       evaluation time.  */
    if (!current_function_decl
!       || !DECL_DECLARED_CONSTEXPR_P (current_function_decl)
        || TREE_STATIC (decl))
      value = cp_fully_fold_init (value);
  
--- 914,920 ----
       that might fold away something that needs to be diagnosed at constexpr
       evaluation time.  */
    if (!current_function_decl
!       || !maybe_constexpr_fn (current_function_decl)
        || TREE_STATIC (decl))
      value = cp_fully_fold_init (value);
  
*************** build_functional_cast_1 (location_t loc,
*** 2457,2465 ****
  	      return error_mark_node;
  	    }
  	  else if (cxx_dialect < cxx23)
! 	    pedwarn (loc, OPT_Wc__23_extensions,
! 		     "% only available with "
! 		     "%<-std=c++2b%> or %<-std=gnu++2b%>");
  	}
        else
  	{
--- 2457,2468 ----
  	      return error_mark_node;
  	    }
  	  else if (cxx_dialect < cxx23)
! 	    {
! 	      if ((complain & tf_warning_or_error) != 0)
! 		pedwarn (loc, OPT_Wc__23_extensions,
! 			 "% only available with "
! 			 "%<-std=c++2b%> or %<-std=gnu++2b%>");
! 	    }
  	}
        else
  	{
diff -Nrcpad gcc-13.4.0/gcc/d/ChangeLog gcc-13.5.0-RC-20260904/gcc/d/ChangeLog
*** gcc-13.4.0/gcc/d/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/gcc/d/ChangeLog	Fri Sep  4 07:35:08 2026
***************
*** 1,3 ****
--- 1,121 ----
+ 2026-05-05  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-05-05  Iain Buclaw  
+ 
+ 	PR d/125089
+ 	* types.cc (finish_aggregate_mode): Explicitly set TYPE_MODE of
+ 	non-POD types here.
+ 	(finish_aggregate_type): Propagate TREE_ADDRESSABLE to all variants.
+ 	(TypeVisitor::visit (TypeStruct *)): Set TREE_ADDRESSABLE before
+ 	visiting struct members.
+ 
+ 2026-02-08  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-02-08  Iain Buclaw  
+ 
+ 	PR d/124026
+ 	* expr.cc (ExprVisitor::visit (FuncExp *)): Always convert function
+ 	literal to a delegate if the expression expects one.
+ 
+ 2026-01-30  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-30  Iain Buclaw  
+ 
+ 	PR d/123264
+ 	* types.cc (finish_aggregate_type): Propagate struct TYPE_NAME to all
+ 	TYPE_NEXT_VARIANT types.
+ 
+ 2026-01-29  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-29  Iain Buclaw  
+ 
+ 	PR d/123407
+ 	* decl.cc (get_symbol_decl): Handle declarations with matching
+ 	assembler names, but different TREE_CODE.
+ 
+ 2026-01-29  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-29  Iain Buclaw  
+ 
+ 	PR d/123046
+ 	* d-codegen.cc (build_address): Return `null' when generating the
+ 	address of a `noreturn' declaration.
+ 	(d_build_call): Compare TYPE_MAIN_VARIANT of type with `noreturn'.
+ 	* decl.cc (get_fndecl_arguments): Likewise.
+ 	* types.cc (finish_aggregate_mode): Likewise.
+ 	(TypeVisitor::visit (TypeFunction *)): Likewise.
+ 
+ 2026-01-29  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-29  Iain Buclaw  
+ 
+ 	PR d/123349
+ 	* d-spec.cc (lang_specific_driver): Use xstrdup to copy -defaultlib
+ 	and -debuglib argument, and unconditionally free the old value.
+ 
+ 2026-01-28  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2025-04-15  Iain Buclaw  
+ 
+ 	PR d/119799
+ 	* decl.cc (DeclVisitor::visit (VarDeclaration *)): Check front-end
+ 	type size before building the VAR_DECL.  Allow C symbols to have a
+ 	size of `0'.
+ 
+ 2026-01-28  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-28  Iain Buclaw  
+ 
+ 	PR d/123419
+ 	* expr.cc (ExprVisitor::visit (VarExp *)): Adjust assertion.
+ 
+ 2026-01-28  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-28  Iain Buclaw  
+ 
+ 	PR d/123798
+ 	* types.cc (insert_aggregate_bitfield): Set DECL_NONADDRESSABLE_P and
+ 	DECL_PADDING_P on bit-field decls.
+ 	(finish_aggregate_type): Pass the aligned bit offset to layout_decl.
+ 
+ 2026-01-28  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-28  Iain Buclaw  
+ 
+ 	PR d/121477
+ 	* d-codegen.cc (d_mark_addressable): Give an error if taking the
+ 	address of a DECL_BIT_FIELD.
+ 
+ 2026-01-28  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-28  Iain Buclaw  
+ 
+ 	PR d/123422
+ 	* expr.cc (ExprVisitor::visit (ArrayLiteralExp *)): Don't add
+ 	TARGET_EXPR around constructor.
+ 	* toir.cc (IRVisitor::visit (ReturnStatement *)): Recognize more
+ 	patterns for return value optimization.
+ 
+ 2026-01-27  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-27  Iain Buclaw  
+ 
+ 	PR d/120096
+ 	* expr.cc (ExprVisitor::visit (ArrayLiteralExp *)): Include saved side
+ 	effects in expression result.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/gcc/d/d-codegen.cc gcc-13.5.0-RC-20260904/gcc/d/d-codegen.cc
*** gcc-13.4.0/gcc/d/d-codegen.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/d/d-codegen.cc	Fri Sep  4 07:35:08 2026
*************** build_address (tree exp)
*** 665,670 ****
--- 665,675 ----
    if (TREE_CODE (exp) == CONST_DECL)
      exp = DECL_INITIAL (exp);
  
+   /* Type `noreturn' has no storage, return `null' for the expression.  */
+   if (DECL_P (exp) && TREE_CODE (exp) != FIELD_DECL
+       && TYPE_MAIN_VARIANT (TREE_TYPE (exp)) == noreturn_type_node)
+     return compound_expr (init, null_pointer_node);
+ 
    /* Some expression lowering may request an address of a compile-time constant,
       or other non-lvalue expression.  Make sure it is assigned to a location we
       can reference.  */
*************** d_mark_addressable (tree exp, bool compl
*** 704,711 ****
  {
    switch (TREE_CODE (exp))
      {
-     case ADDR_EXPR:
      case COMPONENT_REF:
      case ARRAY_REF:
      case REALPART_EXPR:
      case IMAGPART_EXPR:
--- 709,720 ----
  {
    switch (TREE_CODE (exp))
      {
      case COMPONENT_REF:
+       if (complain && DECL_BIT_FIELD (TREE_OPERAND (exp, 1)))
+ 	error ("cannot take address of bit-field %qD", TREE_OPERAND (exp, 1));
+ 
+       /* Fall through.  */
+     case ADDR_EXPR:
      case ARRAY_REF:
      case REALPART_EXPR:
      case IMAGPART_EXPR:
*************** d_build_call (TypeFunction *tf, tree cal
*** 2241,2247 ****
  
  	  /* Type `noreturn` is a terminator, as no other arguments can possibly
  	     be evaluated after it.  */
! 	  if (TREE_TYPE (targ) == noreturn_type_node)
  	    noreturn_call = true;
  
  	  vec_safe_push (args, targ);
--- 2250,2256 ----
  
  	  /* Type `noreturn` is a terminator, as no other arguments can possibly
  	     be evaluated after it.  */
! 	  if (TYPE_MAIN_VARIANT (TREE_TYPE (targ)) == noreturn_type_node)
  	    noreturn_call = true;
  
  	  vec_safe_push (args, targ);
*************** d_build_call (TypeFunction *tf, tree cal
*** 2261,2267 ****
        unsigned int ix;
  
        FOR_EACH_VEC_SAFE_ELT (args, ix, arg)
! 	saved_args = compound_expr (saved_args, arg);
  
        /* Add a stub result type for the expression.  */
        tree result = build_zero_cst (TREE_TYPE (ctype));
--- 2270,2281 ----
        unsigned int ix;
  
        FOR_EACH_VEC_SAFE_ELT (args, ix, arg)
! 	{
! 	  saved_args = compound_expr (saved_args, arg);
! 
! 	  if (TYPE_MAIN_VARIANT (TREE_TYPE (arg)) == noreturn_type_node)
! 	    break;
! 	}
  
        /* Add a stub result type for the expression.  */
        tree result = build_zero_cst (TREE_TYPE (ctype));
diff -Nrcpad gcc-13.4.0/gcc/d/d-spec.cc gcc-13.5.0-RC-20260904/gcc/d/d-spec.cc
*** gcc-13.4.0/gcc/d/d-spec.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/d/d-spec.cc	Fri Sep  4 07:35:08 2026
*************** lang_specific_driver (cl_decoded_option
*** 162,185 ****
  	  break;
  
  	case OPT_defaultlib_:
! 	  if (defaultlib != NULL)
! 	    free (CONST_CAST (char *, defaultlib));
  	  if (arg != NULL)
  	    {
  	      args[i] |= SKIPOPT;
! 	      defaultlib = XNEWVEC (char, strlen (arg));
! 	      strcpy (CONST_CAST (char *, defaultlib), arg);
  	    }
  	  break;
  
  	case OPT_debuglib_:
! 	  if (debuglib != NULL)
! 	    free (CONST_CAST (char *, debuglib));
  	  if (arg != NULL)
  	    {
  	      args[i] |= SKIPOPT;
! 	      debuglib = XNEWVEC (char, strlen (arg));
! 	      strcpy (CONST_CAST (char *, debuglib), arg);
  	    }
  	  break;
  
--- 162,181 ----
  	  break;
  
  	case OPT_defaultlib_:
! 	  free (CONST_CAST (char *, defaultlib));
  	  if (arg != NULL)
  	    {
  	      args[i] |= SKIPOPT;
! 	      defaultlib = xstrdup (arg);
  	    }
  	  break;
  
  	case OPT_debuglib_:
! 	  free (CONST_CAST (char *, debuglib));
  	  if (arg != NULL)
  	    {
  	      args[i] |= SKIPOPT;
! 	      debuglib = xstrdup (arg);
  	    }
  	  break;
  
diff -Nrcpad gcc-13.4.0/gcc/d/decl.cc gcc-13.5.0-RC-20260904/gcc/d/decl.cc
*** gcc-13.4.0/gcc/d/decl.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/d/decl.cc	Fri Sep  4 07:35:08 2026
*************** get_fndecl_arguments (FuncDeclaration *d
*** 183,189 ****
  
  	  /* Type `noreturn` is a terminator, as no other arguments can possibly
  	     be evaluated after it.  */
! 	  if (TREE_TYPE (parm_decl) == noreturn_type_node)
  	    break;
  
  	  /* Chain them in the correct order.  */
--- 183,189 ----
  
  	  /* Type `noreturn` is a terminator, as no other arguments can possibly
  	     be evaluated after it.  */
! 	  if (TYPE_MAIN_VARIANT (TREE_TYPE (parm_decl)) == noreturn_type_node)
  	    break;
  
  	  /* Chain them in the correct order.  */
*************** public:
*** 781,786 ****
--- 781,792 ----
        }
      else if (d->isDataseg ())
        {
+ 	/* When the front-end type size is invalid, an error has already been
+ 	   given for the declaration or type.  */
+ 	dinteger_t size = d->type->size (d->loc);
+ 	if (size == SIZE_INVALID)
+ 	  return;
+ 
  	tree decl = get_symbol_decl (d);
  
  	/* Only need to build the VAR_DECL for extern declarations.  */
*************** public:
*** 794,802 ****
  	  return;
  
  	/* How big a symbol can be should depend on back-end.  */
! 	tree size = build_integer_cst (d->type->size (d->loc),
! 				       build_ctype (Type::tsize_t));
! 	if (!valid_constant_size_p (size))
  	  {
  	    error_at (make_location_t (d->loc), "size is too large");
  	    return;
--- 800,806 ----
  	  return;
  
  	/* How big a symbol can be should depend on back-end.  */
! 	if (!valid_constant_size_p (build_integer_cst (size, size_type_node)))
  	  {
  	    error_at (make_location_t (d->loc), "size is too large");
  	    return;
*************** public:
*** 824,831 ****
  	  }
  
  	/* Frontend should have already caught this.  */
! 	gcc_assert (!integer_zerop (size)
! 		    || d->type->toBasetype ()->isTypeSArray ());
  
  	d_finish_decl (decl);
  
--- 828,836 ----
  	  }
  
  	/* Frontend should have already caught this.  */
! 	gcc_assert ((size != 0 && size != SIZE_INVALID)
! 		    || d->type->toBasetype ()->isTypeSArray ()
! 		    || d->isCsymbol ());
  
  	d_finish_decl (decl);
  
*************** get_symbol_decl (Declaration *decl)
*** 1197,1204 ****
  
    /* Deal with placeholder symbols immediately:
       SymbolDeclaration is used as a shell around an initializer symbol.  */
!   SymbolDeclaration *sd = decl->isSymbolDeclaration ();
!   if (sd)
      {
        decl->csym = aggregate_initializer_decl (sd->dsym);
        return decl->csym;
--- 1202,1208 ----
  
    /* Deal with placeholder symbols immediately:
       SymbolDeclaration is used as a shell around an initializer symbol.  */
!   if (SymbolDeclaration *sd = decl->isSymbolDeclaration ())
      {
        decl->csym = aggregate_initializer_decl (sd->dsym);
        return decl->csym;
*************** get_symbol_decl (Declaration *decl)
*** 1209,1216 ****
      return get_typeinfo_decl ((TypeInfoDeclaration *) decl);
  
    /* FuncAliasDeclaration is used to import functions from another scope.  */
!   FuncAliasDeclaration *fad = decl->isFuncAliasDeclaration ();
!   if (fad)
      {
        decl->csym = get_symbol_decl (fad->funcalias);
        return decl->csym;
--- 1213,1219 ----
      return get_typeinfo_decl ((TypeInfoDeclaration *) decl);
  
    /* FuncAliasDeclaration is used to import functions from another scope.  */
!   if (FuncAliasDeclaration *fad = decl->isFuncAliasDeclaration ())
      {
        decl->csym = get_symbol_decl (fad->funcalias);
        return decl->csym;
*************** get_symbol_decl (Declaration *decl)
*** 1245,1252 ****
      }
  
    /* Build the tree for the symbol.  */
!   FuncDeclaration *fd = decl->isFuncDeclaration ();
!   if (fd)
      {
        /* Run full semantic on functions we need to know about.  */
        if (!fd->functionSemantic ())
--- 1248,1254 ----
      }
  
    /* Build the tree for the symbol.  */
!   if (FuncDeclaration *fd = decl->isFuncDeclaration ())
      {
        /* Run full semantic on functions we need to know about.  */
        if (!fd->functionSemantic ())
*************** get_symbol_decl (Declaration *decl)
*** 1338,1366 ****
        if (IDENTIFIER_DSYMBOL (mangled_name))
  	{
  	  Declaration *other = IDENTIFIER_DSYMBOL (mangled_name);
! 	  tree olddecl = decl->csym;
! 	  decl->csym = get_symbol_decl (other);
! 
! 	  /* Update the symbol location to the current definition.  */
! 	  if (DECL_EXTERNAL (decl->csym) && !DECL_INITIAL (decl->csym))
! 	    DECL_SOURCE_LOCATION (decl->csym) = DECL_SOURCE_LOCATION (olddecl);
  
! 	  /* The current declaration is a prototype or marked extern, merge
! 	     applied user attributes and return.  */
! 	  if (DECL_EXTERNAL (olddecl) && !DECL_INITIAL (olddecl))
! 	    {
! 	      apply_user_attributes (decl, decl->csym);
! 	      return decl->csym;
! 	    }
! 	  /* The previous declaration is a prototype or marked extern, set the
! 	     current declaration as the main reference of the symbol.  */
! 	  else if (DECL_EXTERNAL (decl->csym) && !DECL_INITIAL (decl->csym))
  	    {
! 	      IDENTIFIER_DSYMBOL (mangled_name) = decl;
! 	      DECL_EXTERNAL (decl->csym) = 0;
  	    }
! 	  /* Non-extern, non-templated decls shouldn't be defined twice.  */
! 	  else if (!decl->isInstantiated ())
  	    ScopeDsymbol::multiplyDefined (decl->loc, decl, other);
  	}
        else
--- 1340,1377 ----
        if (IDENTIFIER_DSYMBOL (mangled_name))
  	{
  	  Declaration *other = IDENTIFIER_DSYMBOL (mangled_name);
! 	  tree newdecl = decl->csym;
! 	  tree olddecl = get_symbol_decl (other);
  
! 	  if (TREE_CODE (olddecl) == TREE_CODE (newdecl))
  	    {
! 	      /* Update the symbol location to the current definition.  */
! 	      if (DECL_EXTERNAL (olddecl) && !DECL_INITIAL (olddecl))
! 		DECL_SOURCE_LOCATION (olddecl) = DECL_SOURCE_LOCATION (newdecl);
! 
! 	      /* The current declaration is a prototype or marked extern, merge
! 		 applied user attributes and return.  */
! 	      if (DECL_EXTERNAL (newdecl) && !DECL_INITIAL (newdecl))
! 		{
! 		  apply_user_attributes (decl, olddecl);
! 		  decl->csym = olddecl;
! 		  return decl->csym;
! 		}
! 	      /* The previous declaration is a prototype or marked extern, set
! 		 the current declaration as the main reference of the symbol.
! 	       */
! 	      else if (DECL_EXTERNAL (olddecl) && !DECL_INITIAL (olddecl))
! 		{
! 		  IDENTIFIER_DSYMBOL (mangled_name) = decl;
! 		  decl->csym = olddecl;
! 		  DECL_EXTERNAL (decl->csym) = 0;
! 		}
! 	      /* Non-extern, non-templated decls shouldn't be defined twice.  */
! 	      else if (!decl->isInstantiated ())
! 		ScopeDsymbol::multiplyDefined (decl->loc, decl, other);
  	    }
! 	  /* Declarations are for conflicting kinds of symbol.  */
! 	  else
  	    ScopeDsymbol::multiplyDefined (decl->loc, decl, other);
  	}
        else
*************** get_symbol_decl (Declaration *decl)
*** 1402,1407 ****
--- 1413,1421 ----
      }
    else if (TREE_CODE (decl->csym) == FUNCTION_DECL)
      {
+       FuncDeclaration *fd = decl->isFuncDeclaration ();
+       gcc_assert (fd != NULL);
+ 
        /* Dual-context functions require the code generation to build an array
  	 for the context pointer of the function, making the delicate task of
  	 tracking which context to follow when encountering a non-local symbol,
*************** get_symbol_decl (Declaration *decl)
*** 1555,1560 ****
--- 1569,1575 ----
    if (decl->isDataseg () || decl->isCodeseg () || decl->isThreadlocal ())
      {
        /* Set TREE_PUBLIC by default, but allow private template to override.  */
+       FuncDeclaration *fd = decl->isFuncDeclaration ();
        if (!fd || !fd->isNested ())
  	TREE_PUBLIC (decl->csym) = 1;
  
diff -Nrcpad gcc-13.4.0/gcc/d/expr.cc gcc-13.5.0-RC-20260904/gcc/d/expr.cc
*** gcc-13.4.0/gcc/d/expr.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/d/expr.cc	Fri Sep  4 07:35:08 2026
*************** public:
*** 2051,2077 ****
      /* Compile the function literal body.  */
      build_decl_tree (e->fd);
  
!     /* If nested, this will be a trampoline.  */
!     if (e->fd->isNested ())
!       {
! 	tree func = build_address (get_symbol_decl (e->fd));
! 	tree object;
  
! 	if (this->constp_)
  	  {
! 	    /* Static delegate variables have no context pointer.  */
! 	    object = null_pointer_node;
! 	    this->result_ = build_method_call (func, object, e->fd->type);
  	    TREE_CONSTANT (this->result_) = 1;
  	  }
  	else
  	  {
! 	    object = get_frame_for_symbol (e->fd);
  	    this->result_ = build_method_call (func, object, e->fd->type);
  	  }
        }
      else
        {
  	this->result_ = build_nop (build_ctype (e->type),
  				   build_address (get_symbol_decl (e->fd)));
        }
--- 2051,2081 ----
      /* Compile the function literal body.  */
      build_decl_tree (e->fd);
  
!     tree func = build_address (get_symbol_decl (e->fd));
!     Type *tb = e->type->toBasetype ();
  
!     /* If a delegate is expected, the literal will be inferred as a delegate
!        even if it accesses no variables from an enclosing function.  */
!     if (tb->ty == TY::Tdelegate)
!       {
! 	/* Static delegate variables have no context pointer.  */
! 	if (this->constp_ || !e->fd->isNested ())
  	  {
! 	    this->result_ = build_method_call (func, null_pointer_node,
! 					       e->fd->type);
  	    TREE_CONSTANT (this->result_) = 1;
  	  }
  	else
  	  {
! 	    gcc_assert (e->fd->isNested ());
! 	    tree object = get_frame_for_symbol (e->fd);
  	    this->result_ = build_method_call (func, object, e->fd->type);
  	  }
        }
      else
        {
+ 	/* The function literal is a function pointer.  */
+ 	gcc_assert (tb->ty == TY::Tpointer);
  	this->result_ = build_nop (build_ctype (e->type),
  				   build_address (get_symbol_decl (e->fd)));
        }
*************** public:
*** 2193,2199 ****
  	      {
  		/* Generate a slice for non-zero initialized aggregates,
  		   otherwise create an empty array.  */
! 		gcc_assert (e->type == Type::tvoid->arrayOf ()->constOf ());
  
  		tree type = build_ctype (e->type);
  		tree length = size_int (sd->dsym->structsize);
--- 2197,2204 ----
  	      {
  		/* Generate a slice for non-zero initialized aggregates,
  		   otherwise create an empty array.  */
! 		gcc_assert (e->type->nextOf ()->isConst ()
! 			    && e->type->nextOf ()->ty == TY::Tvoid);
  
  		tree type = build_ctype (e->type);
  		tree length = size_int (sd->dsym->structsize);
*************** public:
*** 2736,2743 ****
  	/* Array literal for a `scope' dynamic array.  */
  	gcc_assert (tb->ty == TY::Tarray);
  	ctor = force_target_expr (ctor);
! 	this->result_ = d_array_value (type, size_int (e->elements->length),
! 				       build_address (ctor));
        }
      else
        {
--- 2741,2749 ----
  	/* Array literal for a `scope' dynamic array.  */
  	gcc_assert (tb->ty == TY::Tarray);
  	ctor = force_target_expr (ctor);
! 	ctor = d_array_value (type, size_int (e->elements->length),
! 			      build_address (ctor));
! 	this->result_ = compound_expr (saved_elems, ctor);
        }
      else
        {
diff -Nrcpad gcc-13.4.0/gcc/d/toir.cc gcc-13.5.0-RC-20260904/gcc/d/toir.cc
*** gcc-13.4.0/gcc/d/toir.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/d/toir.cc	Fri Sep  4 07:35:08 2026
*************** public:
*** 990,1030 ****
  	/* Detect a call to a constructor function, or if returning a struct
  	   literal, write result directly into the return value.  */
  	StructLiteralExp *sle = NULL;
  	bool using_rvo_p = false;
  
  	if (DotVarExp *dve = (s->exp->isCallExp ()
  			      ? s->exp->isCallExp ()->e1->isDotVarExp ()
  			      : NULL))
  	  {
  	    if (dve->var->isCtorDeclaration ())
  	      {
  		if (CommaExp *ce = dve->e1->isCommaExp ())
  		  {
! 		    /* Temporary initialized inside a return expression, and
! 		       used as the return value.  Replace it with the hidden
! 			reference to allow RVO return.  */
! 		    DeclarationExp *de = ce->e1->isDeclarationExp ();
! 		    VarExp *ve = ce->e2->isVarExp ();
! 		    if (de != NULL && ve != NULL
! 			&& ve->var == de->declaration
! 			&& ve->var->storage_class & STCtemp)
! 		      {
! 			tree var = get_symbol_decl (ve->var);
! 			TREE_ADDRESSABLE (var) = 1;
! 			SET_DECL_VALUE_EXPR (var, decl);
! 			DECL_HAS_VALUE_EXPR_P (var) = 1;
! 			SET_DECL_LANG_NRVO (var, this->func_->shidden);
! 			using_rvo_p = true;
! 		      }
  		  }
  		else
  		  sle = dve->e1->isStructLiteralExp ();
  	      }
  	  }
  	else
  	  sle = s->exp->isStructLiteralExp ();
  
! 	if (sle != NULL)
  	  {
  	    StructDeclaration *sd = type->baseElemOf ()->isTypeStruct ()->sym;
  	    sle->sym = build_address (this->func_->shidden);
--- 990,1053 ----
  	/* Detect a call to a constructor function, or if returning a struct
  	   literal, write result directly into the return value.  */
  	StructLiteralExp *sle = NULL;
+ 	DeclarationExp *de = NULL;
+ 	VarExp *ve = NULL;
  	bool using_rvo_p = false;
  
  	if (DotVarExp *dve = (s->exp->isCallExp ()
  			      ? s->exp->isCallExp ()->e1->isDotVarExp ()
  			      : NULL))
  	  {
+ 	    /* Look for `var.__ctor(copytmp = {}, ©tmp)'  */
  	    if (dve->var->isCtorDeclaration ())
  	      {
  		if (CommaExp *ce = dve->e1->isCommaExp ())
  		  {
! 		    de = ce->e1->isDeclarationExp ();
! 		    ve = ce->e2->isVarExp ();
  		  }
  		else
  		  sle = dve->e1->isStructLiteralExp ();
  	      }
  	  }
+ 	else if (CommaExp *ce1 = s->exp->isCommaExp ())
+ 	  {
+ 	    /* Look for `copytmp = {}, copytmp.__ctor(), copytmp'  */
+ 	    if (CommaExp *ce2 = ce1->e2->isCommaExp ())
+ 	      {
+ 		DotVarExp *dve = ce2->e1->isCallExp ()
+ 		  ? ce2->e1->isCallExp ()->e1->isDotVarExp () : NULL;
+ 
+ 		if (dve && dve->var->isCtorDeclaration ())
+ 		  {
+ 		    de = ce1->e1->isDeclarationExp ();
+ 		    ve = ce2->e2->isVarExp ();
+ 		  }
+ 	      }
+ 	    else
+ 	      {
+ 		de = ce1->e1->isDeclarationExp ();
+ 		ve = ce1->e2->isVarExp ();
+ 	      }
+ 	  }
  	else
  	  sle = s->exp->isStructLiteralExp ();
  
! 	if (de != NULL && ve != NULL
! 	    && ve->var == de->declaration
! 	    && ve->var->storage_class & STCtemp)
! 	  {
! 	    /* Temporary initialized inside a return expression, and
! 	       used as the return value.  Replace it with the hidden
! 	       reference to allow RVO return.  */
! 	    tree var = get_symbol_decl (ve->var);
! 	    TREE_ADDRESSABLE (var) = 1;
! 	    SET_DECL_VALUE_EXPR (var, decl);
! 	    DECL_HAS_VALUE_EXPR_P (var) = 1;
! 	    SET_DECL_LANG_NRVO (var, this->func_->shidden);
! 	    using_rvo_p = true;
! 	  }
! 	else if (sle != NULL)
  	  {
  	    StructDeclaration *sd = type->baseElemOf ()->isTypeStruct ()->sym;
  	    sle->sym = build_address (this->func_->shidden);
diff -Nrcpad gcc-13.4.0/gcc/d/types.cc gcc-13.5.0-RC-20260904/gcc/d/types.cc
*** gcc-13.4.0/gcc/d/types.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/d/types.cc	Fri Sep  4 07:35:08 2026
*************** insert_aggregate_bitfield (tree type, tr
*** 324,329 ****
--- 324,333 ----
    DECL_BIT_FIELD (bitfield) = 1;
    DECL_BIT_FIELD_TYPE (bitfield) = TREE_TYPE (bitfield);
  
+   DECL_NONADDRESSABLE_P (bitfield) = 1;
+   if (DECL_NAME (bitfield) == NULL_TREE)
+     DECL_PADDING_P (bitfield) = 1;
+ 
    TYPE_FIELDS (type) = chainon (TYPE_FIELDS (type), bitfield);
  }
  
*************** finish_aggregate_mode (tree type)
*** 589,595 ****
  	return;
      }
  
!   compute_record_mode (type);
  
    /* Propagate computed mode to all variants of this aggregate type.  */
    for (tree t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
--- 593,604 ----
  	return;
      }
  
!   /* Force mode of non-trivially copyable structs to be BLKmode, preventing it
!      from being returned in a register.  */
!   if (TREE_ADDRESSABLE (type))
!     SET_TYPE_MODE (type, BLKmode);
!   else
!     compute_record_mode (type);
  
    /* Propagate computed mode to all variants of this aggregate type.  */
    for (tree t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
*************** finish_aggregate_type (unsigned structsi
*** 671,677 ****
  	  continue;
  	}
  
!       layout_decl (field, 0);
  
        /* Give bit-field its proper type after layout_decl.  */
        if (DECL_BIT_FIELD (field))
--- 680,690 ----
  	  continue;
  	}
  
!       /* Layout the field decl using its known alignment.  */
!       unsigned int known_align =
! 	least_bit_hwi (tree_to_uhwi (DECL_FIELD_BIT_OFFSET (field)));
! 
!       layout_decl (field, known_align);
  
        /* Give bit-field its proper type after layout_decl.  */
        if (DECL_BIT_FIELD (field))
*************** finish_aggregate_type (unsigned structsi
*** 699,704 ****
--- 712,718 ----
        if (t == type)
  	continue;
  
+       TYPE_NAME (t) = TYPE_NAME (type);
        TYPE_FIELDS (t) = TYPE_FIELDS (type);
        TYPE_LANG_SPECIFIC (t) = TYPE_LANG_SPECIFIC (type);
        TYPE_SIZE (t) = TYPE_SIZE (type);
*************** finish_aggregate_type (unsigned structsi
*** 706,711 ****
--- 720,726 ----
        TYPE_PACKED (t) = TYPE_PACKED (type);
        SET_TYPE_ALIGN (t, TYPE_ALIGN (type));
        TYPE_USER_ALIGN (t) = TYPE_USER_ALIGN (type);
+       TREE_ADDRESSABLE (t) = TREE_ADDRESSABLE (type);
      }
  
    /* Complete any other forward-referenced fields of this aggregate type.  */
*************** public:
*** 955,961 ****
  
  	/* Type `noreturn` is a terminator, as no other arguments can possibly
  	   be evaluated after it.  */
! 	if (type == noreturn_type_node)
  	  break;
  
  	fnparams = chainon (fnparams, build_tree_list (0, type));
--- 970,976 ----
  
  	/* Type `noreturn` is a terminator, as no other arguments can possibly
  	   be evaluated after it.  */
! 	if (TYPE_MAIN_VARIANT (type) == noreturn_type_node)
  	  break;
  
  	fnparams = chainon (fnparams, build_tree_list (0, type));
*************** public:
*** 981,987 ****
      d_keep (t->ctype);
  
      /* Qualify function types that have the type `noreturn` as volatile.  */
!     if (fntype == noreturn_type_node)
        t->ctype = build_qualified_type (t->ctype, TYPE_QUAL_VOLATILE);
  
      /* Handle any special support for calling conventions.  */
--- 996,1002 ----
      d_keep (t->ctype);
  
      /* Qualify function types that have the type `noreturn` as volatile.  */
!     if (TYPE_MAIN_VARIANT (fntype) == noreturn_type_node)
        t->ctype = build_qualified_type (t->ctype, TYPE_QUAL_VOLATILE);
  
      /* Handle any special support for calling conventions.  */
*************** public:
*** 1223,1228 ****
--- 1238,1249 ----
      TYPE_LANG_SPECIFIC (t->ctype) = build_lang_type (t);
      TYPE_CXX_ODR_P (t->ctype) = 1;
  
+     /* For structs with a user defined postblit, copy constructor, or a
+        destructor, also set TREE_ADDRESSABLE on the type and all variants.
+        This will make the struct be passed around by reference.  */
+     if (!t->sym->isPOD ())
+       TREE_ADDRESSABLE (t->ctype) = 1;
+ 
      if (t->sym->members)
        {
  	/* Must set up the overall size and alignment before determining
*************** public:
*** 1244,1261 ****
  	build_type_decl (t->ctype, t->sym);
  	apply_user_attributes (t->sym, t->ctype);
        }
- 
-     /* For structs with a user defined postblit, copy constructor, or a
-        destructor, also set TREE_ADDRESSABLE on the type and all variants.
-        This will make the struct be passed around by reference.  */
-     if (!t->sym->isPOD ())
-       {
- 	for (tree tv = t->ctype; tv != NULL_TREE; tv = TYPE_NEXT_VARIANT (tv))
- 	  {
- 	    TREE_ADDRESSABLE (tv) = 1;
- 	    SET_TYPE_MODE (tv, BLKmode);
- 	  }
-       }
    }
  
    /* Build a class type.  Whereas structs are value types, classes are
--- 1265,1270 ----
diff -Nrcpad gcc-13.4.0/gcc/diagnostic.cc gcc-13.5.0-RC-20260904/gcc/diagnostic.cc
*** gcc-13.4.0/gcc/diagnostic.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/diagnostic.cc	Fri Sep  4 07:35:08 2026
*************** diagnostic_report_diagnostic (diagnostic
*** 1517,1534 ****
    if (diagnostic->kind == DK_NOTE && context->inhibit_notes_p)
      return false;
  
-   if (context->lock > 0)
-     {
-       /* If we're reporting an ICE in the middle of some other error,
- 	 try to flush out the previous error, then let this one
- 	 through.  Don't do this more than once.  */
-       if ((diagnostic->kind == DK_ICE || diagnostic->kind == DK_ICE_NOBT)
- 	  && context->lock == 1)
- 	pp_newline_and_flush (context->printer);
-       else
- 	error_recursion (context);
-     }
- 
    /* If the user requested that warnings be treated as errors, so be
       it.  Note that we do this before the next block so that
       individual warnings can be overridden back to warnings with
--- 1517,1522 ----
*************** diagnostic_report_diagnostic (diagnostic
*** 1553,1558 ****
--- 1541,1558 ----
    if (diagnostic->kind != DK_NOTE && diagnostic->kind != DK_ICE)
      diagnostic_check_max_errors (context);
  
+   if (context->lock > 0)
+     {
+       /* If we're reporting an ICE in the middle of some other error,
+ 	 try to flush out the previous error, then let this one
+ 	 through.  Don't do this more than once.  */
+       if ((diagnostic->kind == DK_ICE || diagnostic->kind == DK_ICE_NOBT)
+ 	  && context->lock == 1)
+ 	pp_newline_and_flush (context->printer);
+       else
+ 	error_recursion (context);
+     }
+ 
    context->lock++;
  
    if (diagnostic->kind == DK_ICE || diagnostic->kind == DK_ICE_NOBT)
diff -Nrcpad gcc-13.4.0/gcc/doc/avr-mmcu.texi gcc-13.5.0-RC-20260904/gcc/doc/avr-mmcu.texi
*** gcc-13.4.0/gcc/doc/avr-mmcu.texi	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/avr-mmcu.texi	Fri Sep  4 07:35:08 2026
***************
*** 50,64 ****
  
  @item avrxmega2
  ``XMEGA'' devices with more than 8@tie{}KiB and up to 64@tie{}KiB of program memory.
! @*@var{mcu}@tie{}= @code{atxmega8e5}, @code{atxmega16a4}, @code{atxmega16a4u}, @code{atxmega16c4}, @code{atxmega16d4}, @code{atxmega16e5}, @code{atxmega32a4}, @code{atxmega32a4u}, @code{atxmega32c3}, @code{atxmega32c4}, @code{atxmega32d3}, @code{atxmega32d4}, @code{atxmega32e5}, @code{avr64da28}, @code{avr64da32}, @code{avr64da48}, @code{avr64da64}, @code{avr64db28}, @code{avr64db32}, @code{avr64db48}, @code{avr64db64}, @code{avr64dd14}, @code{avr64dd20}, @code{avr64dd28}, @code{avr64dd32}, @code{avr64du28}, @code{avr64du32}, @code{avr64ea28}, @code{avr64ea32}, @code{avr64ea48}, @code{avr64sd28}, @code{avr64sd32}, @code{avr64sd48}.
  
  @item avrxmega3
  ``XMEGA'' devices with up to 64@tie{}KiB of combined program memory and RAM, and with program memory visible in the RAM address space.
! @*@var{mcu}@tie{}= @code{attiny202}, @code{attiny204}, @code{attiny212}, @code{attiny214}, @code{attiny402}, @code{attiny404}, @code{attiny406}, @code{attiny412}, @code{attiny414}, @code{attiny416}, @code{attiny416auto}, @code{attiny417}, @code{attiny424}, @code{attiny426}, @code{attiny427}, @code{attiny804}, @code{attiny806}, @code{attiny807}, @code{attiny814}, @code{attiny816}, @code{attiny817}, @code{attiny824}, @code{attiny826}, @code{attiny827}, @code{attiny1604}, @code{attiny1606}, @code{attiny1607}, @code{attiny1614}, @code{attiny1616}, @code{attiny1617}, @code{attiny1624}, @code{attiny1626}, @code{attiny1627}, @code{attiny3214}, @code{attiny3216}, @code{attiny3217}, @code{attiny3224}, @code{attiny3226}, @code{attiny3227}, @code{atmega808}, @code{atmega809}, @code{atmega1608}, @code{atmega1609}, @code{atmega3208}, @code{atmega3209}, @code{atmega4808}, @code{atmega4809}, @code{avr16dd14}, @code{avr16dd20}, @code{avr16dd28}, @code{avr16dd32}, @code{avr16du14}, @code{avr16du20}, @code{avr16du28}, @code{avr16du32}, @code{avr16ea28}, @code{avr16ea32}, @code{avr16ea48}, @code{avr16eb14}, @code{avr16eb20}, @code{avr16eb28}, @code{avr16eb32}, @code{avr32da28}, @code{avr32da32}, @code{avr32da48}, @code{avr32db28}, @code{avr32db32}, @code{avr32db48}, @code{avr32dd14}, @code{avr32dd20}, @code{avr32dd28}, @code{avr32dd32}, @code{avr32du14}, @code{avr32du20}, @code{avr32du28}, @code{avr32du32}, @code{avr32ea28}, @code{avr32ea32}, @code{avr32ea48}, @code{avr32sd20}, @code{avr32sd28}, @code{avr32sd32}.
  
  @item avrxmega4
  ``XMEGA'' devices with more than 64@tie{}KiB and up to 128@tie{}KiB of program memory.
! @*@var{mcu}@tie{}= @code{atxmega64a3}, @code{atxmega64a3u}, @code{atxmega64a4u}, @code{atxmega64b1}, @code{atxmega64b3}, @code{atxmega64c3}, @code{atxmega64d3}, @code{atxmega64d4}, @code{avr128da28}, @code{avr128da32}, @code{avr128da48}, @code{avr128da64}, @code{avr128db28}, @code{avr128db32}, @code{avr128db48}, @code{avr128db64}.
  
  @item avrxmega5
  ``XMEGA'' devices with more than 64@tie{}KiB and up to 128@tie{}KiB of program memory and more than 64@tie{}KiB of RAM.
--- 50,64 ----
  
  @item avrxmega2
  ``XMEGA'' devices with more than 8@tie{}KiB and up to 64@tie{}KiB of program memory.
! @*@var{mcu}@tie{}= @code{atxmega8e5}, @code{atxmega16a4}, @code{atxmega16a4u}, @code{atxmega16c4}, @code{atxmega16d4}, @code{atxmega16e5}, @code{atxmega32a4}, @code{atxmega32a4u}, @code{atxmega32c3}, @code{atxmega32c4}, @code{atxmega32d3}, @code{atxmega32d4}, @code{atxmega32e5}, @code{avr64da28}, @code{avr64da28s}, @code{avr64da32}, @code{avr64da32s}, @code{avr64da48}, @code{avr64da48s}, @code{avr64da64}, @code{avr64da64s}, @code{avr64db28}, @code{avr64db32}, @code{avr64db48}, @code{avr64db64}, @code{avr64dd14}, @code{avr64dd20}, @code{avr64dd28}, @code{avr64dd32}, @code{avr64du28}, @code{avr64du32}, @code{avr64ea28}, @code{avr64ea32}, @code{avr64ea48}, @code{avr64sd28}, @code{avr64sd32}, @code{avr64sd48}.
  
  @item avrxmega3
  ``XMEGA'' devices with up to 64@tie{}KiB of combined program memory and RAM, and with program memory visible in the RAM address space.
! @*@var{mcu}@tie{}= @code{attiny202}, @code{attiny204}, @code{attiny212}, @code{attiny214}, @code{attiny402}, @code{attiny404}, @code{attiny406}, @code{attiny412}, @code{attiny414}, @code{attiny416}, @code{attiny416auto}, @code{attiny417}, @code{attiny424}, @code{attiny426}, @code{attiny427}, @code{attiny804}, @code{attiny806}, @code{attiny807}, @code{attiny814}, @code{attiny816}, @code{attiny817}, @code{attiny824}, @code{attiny826}, @code{attiny827}, @code{attiny1604}, @code{attiny1606}, @code{attiny1607}, @code{attiny1614}, @code{attiny1616}, @code{attiny1617}, @code{attiny1624}, @code{attiny1626}, @code{attiny1627}, @code{attiny3214}, @code{attiny3216}, @code{attiny3217}, @code{attiny3224}, @code{attiny3226}, @code{attiny3227}, @code{atmega808}, @code{atmega809}, @code{atmega1608}, @code{atmega1609}, @code{atmega3208}, @code{atmega3209}, @code{atmega4808}, @code{atmega4809}, @code{avr16dd14}, @code{avr16dd20}, @code{avr16dd28}, @code{avr16dd32}, @code{avr16du14}, @code{avr16du20}, @code{avr16du28}, @code{avr16du32}, @code{avr16ea28}, @code{avr16ea32}, @code{avr16ea48}, @code{avr16eb14}, @code{avr16eb20}, @code{avr16eb28}, @code{avr16eb32}, @code{avr16la14}, @code{avr16la20}, @code{avr16la28}, @code{avr16la32}, @code{avr32da28}, @code{avr32da28s}, @code{avr32da32}, @code{avr32da32s}, @code{avr32da48}, @code{avr32da48s}, @code{avr32db28}, @code{avr32db32}, @code{avr32db48}, @code{avr32dd14}, @code{avr32dd20}, @code{avr32dd28}, @code{avr32dd32}, @code{avr32du14}, @code{avr32du20}, @code{avr32du28}, @code{avr32du32}, @code{avr32ea28}, @code{avr32ea32}, @code{avr32ea48}, @code{avr32eb14}, @code{avr32eb20}, @code{avr32eb28}, @code{avr32eb32}, @code{avr32la14}, @code{avr32la20}, @code{avr32la28}, @code{avr32la32}, @code{avr32sd20}, @code{avr32sd28}, @code{avr32sd32}.
  
  @item avrxmega4
  ``XMEGA'' devices with more than 64@tie{}KiB and up to 128@tie{}KiB of program memory.
! @*@var{mcu}@tie{}= @code{atxmega64a3}, @code{atxmega64a3u}, @code{atxmega64a4u}, @code{atxmega64b1}, @code{atxmega64b3}, @code{atxmega64c3}, @code{atxmega64d3}, @code{atxmega64d4}, @code{avr128da28}, @code{avr128da28s}, @code{avr128da32}, @code{avr128da32s}, @code{avr128da48}, @code{avr128da48s}, @code{avr128da64}, @code{avr128da64s}, @code{avr128db28}, @code{avr128db32}, @code{avr128db48}, @code{avr128db64}.
  
  @item avrxmega5
  ``XMEGA'' devices with more than 64@tie{}KiB and up to 128@tie{}KiB of program memory and more than 64@tie{}KiB of RAM.
diff -Nrcpad gcc-13.4.0/gcc/doc/cpp.1 gcc-13.5.0-RC-20260904/gcc/doc/cpp.1
*** gcc-13.4.0/gcc/doc/cpp.1	Thu Jun  5 16:06:29 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/cpp.1	Fri Sep  4 07:36:30 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,146 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "CPP 1"
! .TH CPP 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  cpp \- The C Preprocessor
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
  cpp [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
      [\fB\-I\fR\fIdir\fR...] [\fB\-iquote\fR\fIdir\fR...]
--- 53,71 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "CPP 1"
! .TH CPP 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  cpp \- The C Preprocessor
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
  cpp [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
      [\fB\-I\fR\fIdir\fR...] [\fB\-iquote\fR\fIdir\fR...]
*************** cpp [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]..
*** 150,159 ****
      \fIinfile\fR [[\fB\-o\fR] \fIoutfile\fR]
  .PP
  Only the most useful options are given above; see below for a more
! complete list of preprocessor-specific options.  
  In addition, \fBcpp\fR accepts most \fBgcc\fR driver options, which
! are not listed here.  Refer to the \s-1GCC\s0 documentation for details.
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
  The C preprocessor, often known as \fIcpp\fR, is a \fImacro processor\fR
  that is used automatically by the C compiler to transform your program
--- 75,84 ----
      \fIinfile\fR [[\fB\-o\fR] \fIoutfile\fR]
  .PP
  Only the most useful options are given above; see below for a more
! complete list of preprocessor\-specific options.  
  In addition, \fBcpp\fR accepts most \fBgcc\fR driver options, which
! are not listed here.  Refer to the GCC documentation for details.
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
  The C preprocessor, often known as \fIcpp\fR, is a \fImacro processor\fR
  that is used automatically by the C compiler to transform your program
*************** before compilation.  It is called a macr
*** 161,169 ****
  you to define \fImacros\fR, which are brief abbreviations for longer
  constructs.
  .PP
! The C preprocessor is intended to be used only with C, \*(C+, and
! Objective-C source code.  In the past, it has been abused as a general
! text processor.  It will choke on input which does not obey C's lexical
  rules.  For example, apostrophes will be interpreted as the beginning of
  character constants, and cause errors.  Also, you cannot rely on it
  preserving characteristics of the input which are not significant to
--- 86,94 ----
  you to define \fImacros\fR, which are brief abbreviations for longer
  constructs.
  .PP
! The C preprocessor is intended to be used only with C, C++, and
! Objective\-C source code.  In the past, it has been abused as a general
! text processor.  It will choke on input which does not obey C\*(Aqs lexical
  rules.  For example, apostrophes will be interpreted as the beginning of
  character constants, and cause errors.  Also, you cannot rely on it
  preserving characteristics of the input which are not significant to
*************** C\-family languages.  If a Makefile is p
*** 171,209 ****
  will be removed, and the Makefile will not work.
  .PP
  Having said that, you can often get away with using cpp on things which
! are not C.  Other Algol-ish programming languages are often safe
  (Ada, etc.) So is assembly, with caution.  \fB\-traditional\-cpp\fR
  mode preserves more white space, and is otherwise more permissive.  Many
! of the problems can be avoided by writing C or \*(C+ style comments
  instead of native language comments, and keeping macros simple.
  .PP
  Wherever possible, you should use a preprocessor geared to the language
! you are writing in.  Modern versions of the \s-1GNU\s0 assembler have macro
  facilities.  Most high level programming languages have their own
  conditional compilation and inclusion mechanism.  If all else fails,
! try a true general text processor, such as \s-1GNU M4.\s0
  .PP
! C preprocessors vary in some details.  This manual discusses the \s-1GNU C\s0
! preprocessor, which provides a small superset of the features of \s-1ISO\s0
! Standard C.  In its default mode, the \s-1GNU C\s0 preprocessor does not do a
  few things required by the standard.  These are features which are
  rarely, if ever, used, and may cause surprising changes to the meaning
! of a program which does not expect them.  To get strict \s-1ISO\s0 Standard C,
  you should use the \fB\-std=c90\fR, \fB\-std=c99\fR,
  \&\fB\-std=c11\fR or \fB\-std=c17\fR options, depending
  on which version of the standard you want.  To get all the mandatory
  diagnostics, you must also use \fB\-pedantic\fR.
  .PP
! This manual describes the behavior of the \s-1ISO\s0 preprocessor.  To
! minimize gratuitous differences, where the \s-1ISO\s0 preprocessor's
  behavior does not conflict with traditional semantics, the
  traditional preprocessor should behave the same way.  The various
  differences that do exist are detailed in the section \fBTraditional
  Mode\fR.
  .PP
! For clarity, unless noted otherwise, references to \fB\s-1CPP\s0\fR in this
! manual refer to \s-1GNU CPP.\s0
! .SH "OPTIONS"
  .IX Header "OPTIONS"
  The \fBcpp\fR command expects two file names as arguments, \fIinfile\fR and
  \&\fIoutfile\fR.  The preprocessor reads \fIinfile\fR together with any
--- 96,134 ----
  will be removed, and the Makefile will not work.
  .PP
  Having said that, you can often get away with using cpp on things which
! are not C.  Other Algol\-ish programming languages are often safe
  (Ada, etc.) So is assembly, with caution.  \fB\-traditional\-cpp\fR
  mode preserves more white space, and is otherwise more permissive.  Many
! of the problems can be avoided by writing C or C++ style comments
  instead of native language comments, and keeping macros simple.
  .PP
  Wherever possible, you should use a preprocessor geared to the language
! you are writing in.  Modern versions of the GNU assembler have macro
  facilities.  Most high level programming languages have their own
  conditional compilation and inclusion mechanism.  If all else fails,
! try a true general text processor, such as GNU M4.
  .PP
! C preprocessors vary in some details.  This manual discusses the GNU C
! preprocessor, which provides a small superset of the features of ISO
! Standard C.  In its default mode, the GNU C preprocessor does not do a
  few things required by the standard.  These are features which are
  rarely, if ever, used, and may cause surprising changes to the meaning
! of a program which does not expect them.  To get strict ISO Standard C,
  you should use the \fB\-std=c90\fR, \fB\-std=c99\fR,
  \&\fB\-std=c11\fR or \fB\-std=c17\fR options, depending
  on which version of the standard you want.  To get all the mandatory
  diagnostics, you must also use \fB\-pedantic\fR.
  .PP
! This manual describes the behavior of the ISO preprocessor.  To
! minimize gratuitous differences, where the ISO preprocessor\*(Aqs
  behavior does not conflict with traditional semantics, the
  traditional preprocessor should behave the same way.  The various
  differences that do exist are detailed in the section \fBTraditional
  Mode\fR.
  .PP
! For clarity, unless noted otherwise, references to \fBCPP\fR in this
! manual refer to GNU CPP.
! .SH OPTIONS
  .IX Header "OPTIONS"
  The \fBcpp\fR command expects two file names as arguments, \fIinfile\fR and
  \&\fIoutfile\fR.  The preprocessor reads \fIinfile\fR together with any
*************** which take an argument may have that arg
*** 222,228 ****
  after the option, or with a space between option and argument:
  \&\fB\-Ifoo\fR and \fB\-I foo\fR have the same effect.
  .PP
! Many options have multi-letter names; therefore multiple single-letter
  options may \fInot\fR be grouped: \fB\-dM\fR is very different from
  \&\fB\-d\ \-M\fR.
  .IP "\fB\-D\fR \fIname\fR" 4
--- 147,153 ----
  after the option, or with a space between option and argument:
  \&\fB\-Ifoo\fR and \fB\-I foo\fR have the same effect.
  .PP
! Many options have multi\-letter names; therefore multiple single\-letter
  options may \fInot\fR be grouped: \fB\-dM\fR is very different from
  \&\fB\-d\ \-M\fR.
  .IP "\fB\-D\fR \fIname\fR" 4
*************** they appeared during translation phase t
*** 235,249 ****
  directive.  In particular, the definition is truncated by
  embedded newline characters.
  .Sp
! If you are invoking the preprocessor from a shell or shell-like
! program you may need to use the shell's quoting syntax to protect
  characters such as spaces that have a meaning in the shell syntax.
  .Sp
! If you wish to define a function-like macro on the command line, write
  its argument list with surrounding parentheses before the equals sign
  (if any).  Parentheses are meaningful to most shells, so you should
  quote the option.  With \fBsh\fR and \fBcsh\fR,
! \&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works.
  .Sp
  \&\fB\-D\fR and \fB\-U\fR options are processed in the order they
  are given on the command line.  All \fB\-imacros\fR \fIfile\fR and
--- 160,174 ----
  directive.  In particular, the definition is truncated by
  embedded newline characters.
  .Sp
! If you are invoking the preprocessor from a shell or shell\-like
! program you may need to use the shell\*(Aqs quoting syntax to protect
  characters such as spaces that have a meaning in the shell syntax.
  .Sp
! If you wish to define a function\-like macro on the command line, write
  its argument list with surrounding parentheses before the equals sign
  (if any).  Parentheses are meaningful to most shells, so you should
  quote the option.  With \fBsh\fR and \fBcsh\fR,
! \&\fB\-D\*(Aq\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB\*(Aq\fR works.
  .Sp
  \&\fB\-D\fR and \fB\-U\fR options are processed in the order they
  are given on the command line.  All \fB\-imacros\fR \fIfile\fR and
*************** provided with a \fB\-D\fR option.
*** 257,263 ****
  .IX Item "-include file"
  Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
  line of the primary source file.  However, the first directory searched
! for \fIfile\fR is the preprocessor's working directory \fIinstead of\fR
  the directory containing the main source file.  If not found there, it
  is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
  chain as normal.
--- 182,188 ----
  .IX Item "-include file"
  Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
  line of the primary source file.  However, the first directory searched
! for \fIfile\fR is the preprocessor\*(Aqs working directory \fIinstead of\fR
  the directory containing the main source file.  If not found there, it
  is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
  chain as normal.
*************** processing its declarations.
*** 273,296 ****
  .Sp
  All files specified by \fB\-imacros\fR are processed before all files
  specified by \fB\-include\fR.
! .IP "\fB\-undef\fR" 4
  .IX Item "-undef"
! Do not predefine any system-specific or GCC-specific macros.  The
  standard predefined macros remain defined.
! .IP "\fB\-pthread\fR" 4
  .IX Item "-pthread"
! Define additional macros required for using the \s-1POSIX\s0 threads library.
  You should use this option consistently for both compilation and linking.
  This option is supported on GNU/Linux targets, most other Unix derivatives,
  and also on x86 Cygwin and MinGW targets.
! .IP "\fB\-M\fR" 4
  .IX Item "-M"
  Instead of outputting the result of preprocessing, output a rule
  suitable for \fBmake\fR describing the dependencies of the main
  source file.  The preprocessor outputs one \fBmake\fR rule containing
  the object file name for that source file, a colon, and the names of all
  the included files, including those coming from \fB\-include\fR or
! \&\fB\-imacros\fR command-line options.
  .Sp
  Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
  object file name consists of the name of the source file with any
--- 198,221 ----
  .Sp
  All files specified by \fB\-imacros\fR are processed before all files
  specified by \fB\-include\fR.
! .IP \fB\-undef\fR 4
  .IX Item "-undef"
! Do not predefine any system\-specific or GCC\-specific macros.  The
  standard predefined macros remain defined.
! .IP \fB\-pthread\fR 4
  .IX Item "-pthread"
! Define additional macros required for using the POSIX threads library.
  You should use this option consistently for both compilation and linking.
  This option is supported on GNU/Linux targets, most other Unix derivatives,
  and also on x86 Cygwin and MinGW targets.
! .IP \fB\-M\fR 4
  .IX Item "-M"
  Instead of outputting the result of preprocessing, output a rule
  suitable for \fBmake\fR describing the dependencies of the main
  source file.  The preprocessor outputs one \fBmake\fR rule containing
  the object file name for that source file, a colon, and the names of all
  the included files, including those coming from \fB\-include\fR or
! \&\fB\-imacros\fR command\-line options.
  .Sp
  Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
  object file name consists of the name of the source file with any
*************** parts removed.  If there are many includ
*** 299,314 ****
  split into several lines using \fB\e\fR\-newline.  The rule has no
  commands.
  .Sp
! This option does not suppress the preprocessor's debug output, such as
  \&\fB\-dM\fR.  To avoid mixing such debug output with the dependency
  rules you should explicitly specify the dependency output file with
  \&\fB\-MF\fR, or use an environment variable like
! \&\fB\s-1DEPENDENCIES_OUTPUT\s0\fR.  Debug output
  is still sent to the regular output stream as normal.
  .Sp
  Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
  warnings with an implicit \fB\-w\fR.
! .IP "\fB\-MM\fR" 4
  .IX Item "-MM"
  Like \fB\-M\fR but do not mention header files that are found in
  system header directories, nor header files that are included,
--- 224,239 ----
  split into several lines using \fB\e\fR\-newline.  The rule has no
  commands.
  .Sp
! This option does not suppress the preprocessor\*(Aqs debug output, such as
  \&\fB\-dM\fR.  To avoid mixing such debug output with the dependency
  rules you should explicitly specify the dependency output file with
  \&\fB\-MF\fR, or use an environment variable like
! \&\fBDEPENDENCIES_OUTPUT\fR.  Debug output
  is still sent to the regular output stream as normal.
  .Sp
  Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
  warnings with an implicit \fB\-w\fR.
! .IP \fB\-MM\fR 4
  .IX Item "-MM"
  Like \fB\-M\fR but do not mention header files that are found in
  system header directories, nor header files that are included,
*************** When used with the driver options \fB\-M
*** 328,334 ****
  \&\fB\-MF\fR overrides the default dependency output file.
  .Sp
  If \fIfile\fR is \fI\-\fR, then the dependencies are written to \fIstdout\fR.
! .IP "\fB\-MG\fR" 4
  .IX Item "-MG"
  In conjunction with an option such as \fB\-M\fR requesting
  dependency generation, \fB\-MG\fR assumes missing header files are
--- 253,259 ----
  \&\fB\-MF\fR overrides the default dependency output file.
  .Sp
  If \fIfile\fR is \fI\-\fR, then the dependencies are written to \fIstdout\fR.
! .IP \fB\-MG\fR 4
  .IX Item "-MG"
  In conjunction with an option such as \fB\-M\fR requesting
  dependency generation, \fB\-MG\fR assumes missing header files are
*************** also suppresses preprocessed output, as
*** 339,350 ****
  this useless.
  .Sp
  This feature is used in automatic updating of makefiles.
! .IP "\fB\-Mno\-modules\fR" 4
  .IX Item "-Mno-modules"
  Disable dependency generation for compiled module interfaces.
! .IP "\fB\-MP\fR" 4
  .IX Item "-MP"
! This option instructs \s-1CPP\s0 to add a phony target for each dependency
  other than the main file, causing each to depend on nothing.  These
  dummy rules work around errors \fBmake\fR gives if you remove header
  files without updating the \fIMakefile\fR to match.
--- 264,275 ----
  this useless.
  .Sp
  This feature is used in automatic updating of makefiles.
! .IP \fB\-Mno\-modules\fR 4
  .IX Item "-Mno-modules"
  Disable dependency generation for compiled module interfaces.
! .IP \fB\-MP\fR 4
  .IX Item "-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 \fBmake\fR gives if you remove header
  files without updating the \fIMakefile\fR to match.
*************** This is typical output:
*** 359,373 ****
  .IP "\fB\-MT\fR \fItarget\fR" 4
  .IX Item "-MT target"
  Change the target of the rule emitted by dependency generation.  By
! default \s-1CPP\s0 takes the name of the main input file, deletes any
  directory components and any file suffix such as \fB.c\fR, and
! appends the platform's usual object suffix.  The result is the target.
  .Sp
  An \fB\-MT\fR option sets the target to be exactly the string you
  specify.  If you want multiple targets, you can specify them as a single
  argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
  .Sp
! For example, \fB\-MT\ '$(objpfx)foo.o'\fR might give
  .Sp
  .Vb 1
  \&        $(objpfx)foo.o: foo.c
--- 284,298 ----
  .IP "\fB\-MT\fR \fItarget\fR" 4
  .IX Item "-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 \fB.c\fR, and
! appends the platform\*(Aqs usual object suffix.  The result is the target.
  .Sp
  An \fB\-MT\fR option sets the target to be exactly the string you
  specify.  If you want multiple targets, you can specify them as a single
  argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
  .Sp
! For example, \fB\-MT\ \*(Aq$(objpfx)foo.o\*(Aq\fR might give
  .Sp
  .Vb 1
  \&        $(objpfx)foo.o: foo.c
*************** For example, \fB\-MT\ '$(objpfx)foo.o'\f
*** 375,381 ****
  .IP "\fB\-MQ\fR \fItarget\fR" 4
  .IX Item "-MQ target"
  Same as \fB\-MT\fR, but it quotes any characters which are special to
! Make.  \fB\-MQ\ '$(objpfx)foo.o'\fR gives
  .Sp
  .Vb 1
  \&        $$(objpfx)foo.o: foo.c
--- 300,306 ----
  .IP "\fB\-MQ\fR \fItarget\fR" 4
  .IX Item "-MQ target"
  Same as \fB\-MT\fR, but it quotes any characters which are special to
! Make.  \fB\-MQ\ \*(Aq$(objpfx)foo.o\*(Aq\fR gives
  .Sp
  .Vb 1
  \&        $$(objpfx)foo.o: foo.c
*************** Make.  \fB\-MQ\ '$(objpfx)foo.o'\fR give
*** 383,389 ****
  .Sp
  The default target is automatically quoted, as if it were given with
  \&\fB\-MQ\fR.
! .IP "\fB\-MD\fR" 4
  .IX Item "-MD"
  \&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
  \&\fB\-E\fR is not implied.  The driver determines \fIfile\fR based on
--- 308,314 ----
  .Sp
  The default target is automatically quoted, as if it were given with
  \&\fB\-MQ\fR.
! .IP \fB\-MD\fR 4
  .IX Item "-MD"
  \&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
  \&\fB\-E\fR is not implied.  The driver determines \fIfile\fR based on
*************** is understood to specify a target object
*** 398,408 ****
  .Sp
  Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
  a dependency output file as a side effect of the compilation process.
! .IP "\fB\-MMD\fR" 4
  .IX Item "-MMD"
  Like \fB\-MD\fR except mention only user header files, not system
  header files.
! .IP "\fB\-fpreprocessed\fR" 4
  .IX Item "-fpreprocessed"
  Indicate to the preprocessor that the input file has already been
  preprocessed.  This suppresses things like macro expansion, trigraph
--- 323,333 ----
  .Sp
  Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
  a dependency output file as a side effect of the compilation process.
! .IP \fB\-MMD\fR 4
  .IX Item "-MMD"
  Like \fB\-MD\fR except mention only user header files, not system
  header files.
! .IP \fB\-fpreprocessed\fR 4
  .IX Item "-fpreprocessed"
  Indicate to the preprocessor that the input file has already been
  preprocessed.  This suppresses things like macro expansion, trigraph
*************** a tokenizer for the front ends.
*** 414,426 ****
  .Sp
  \&\fB\-fpreprocessed\fR is implicit if the input file has one of the
  extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR.  These are the
! extensions that \s-1GCC\s0 uses for preprocessed files created by
  \&\fB\-save\-temps\fR.
! .IP "\fB\-fdirectives\-only\fR" 4
  .IX Item "-fdirectives-only"
  When preprocessing, handle directives, but do not expand macros.
  .Sp
! The option's behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
  options.
  .Sp
  With \fB\-E\fR, preprocessing is limited to the handling of directives
--- 339,351 ----
  .Sp
  \&\fB\-fpreprocessed\fR is implicit if the input file has one of the
  extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR.  These are the
! extensions that GCC uses for preprocessed files created by
  \&\fB\-save\-temps\fR.
! .IP \fB\-fdirectives\-only\fR 4
  .IX Item "-fdirectives-only"
  When preprocessing, handle directives, but do not expand macros.
  .Sp
! The option\*(Aqs behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
  options.
  .Sp
  With \fB\-E\fR, preprocessing is limited to the handling of directives
*************** files previously preprocessed with \f(CW
*** 437,463 ****
  With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
  \&\fB\-fpreprocessed\fR take precedence.  This enables full preprocessing of
  files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
! .IP "\fB\-fdollars\-in\-identifiers\fR" 4
  .IX Item "-fdollars-in-identifiers"
  Accept \fB$\fR in identifiers.
! .IP "\fB\-fextended\-identifiers\fR" 4
  .IX Item "-fextended-identifiers"
  Accept universal character names and extended characters in
  identifiers.  This option is enabled by default for C99 (and later C
! standard versions) and \*(C+.
! .IP "\fB\-fno\-canonical\-system\-headers\fR" 4
  .IX Item "-fno-canonical-system-headers"
  When preprocessing, do not shorten system header paths with canonicalization.
! .IP "\fB\-fmax\-include\-depth=\fR\fIdepth\fR" 4
  .IX Item "-fmax-include-depth=depth"
  Set the maximum depth of the nested #include. The default is 200.
! .IP "\fB\-ftabstop=\fR\fIwidth\fR" 4
  .IX Item "-ftabstop=width"
  Set the distance between tab stops.  This helps the preprocessor report
  correct column numbers in warnings or errors, even if tabs appear on the
  line.  If the value is less than 1 or greater than 100, the option is
  ignored.  The default is 8.
! .IP "\fB\-ftrack\-macro\-expansion\fR[\fB=\fR\fIlevel\fR]" 4
  .IX Item "-ftrack-macro-expansion[=level]"
  Track locations of tokens across macro expansions. This allows the
  compiler to emit diagnostic about the current macro expansion stack
--- 362,388 ----
  With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
  \&\fB\-fpreprocessed\fR take precedence.  This enables full preprocessing of
  files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
! .IP \fB\-fdollars\-in\-identifiers\fR 4
  .IX Item "-fdollars-in-identifiers"
  Accept \fB$\fR in identifiers.
! .IP \fB\-fextended\-identifiers\fR 4
  .IX Item "-fextended-identifiers"
  Accept universal character names and extended characters in
  identifiers.  This option is enabled by default for C99 (and later C
! standard versions) and C++.
! .IP \fB\-fno\-canonical\-system\-headers\fR 4
  .IX Item "-fno-canonical-system-headers"
  When preprocessing, do not shorten system header paths with canonicalization.
! .IP \fB\-fmax\-include\-depth=\fR\fIdepth\fR 4
  .IX Item "-fmax-include-depth=depth"
  Set the maximum depth of the nested #include. The default is 200.
! .IP \fB\-ftabstop=\fR\fIwidth\fR 4
  .IX Item "-ftabstop=width"
  Set the distance between tab stops.  This helps the preprocessor report
  correct column numbers in warnings or errors, even if tabs appear on the
  line.  If the value is less than 1 or greater than 100, the option is
  ignored.  The default is 8.
! .IP \fB\-ftrack\-macro\-expansion\fR[\fB=\fR\fIlevel\fR] 4
  .IX Item "-ftrack-macro-expansion[=level]"
  Track locations of tokens across macro expansions. This allows the
  compiler to emit diagnostic about the current macro expansion stack
*************** when a compilation error occurs in a mac
*** 465,521 ****
  option makes the preprocessor and the compiler consume more
  memory. The \fIlevel\fR parameter can be used to choose the level of
  precision of token location tracking thus decreasing the memory
! consumption if necessary. Value \fB0\fR of \fIlevel\fR de-activates
  this option. Value \fB1\fR tracks tokens locations in a
  degraded mode for the sake of minimal memory overhead. In this mode
  all tokens resulting from the expansion of an argument of a
! function-like macro have the same location. Value \fB2\fR tracks
  tokens locations completely. This value is the most memory hungry.
  When this option is given no argument, the default parameter value is
  \&\fB2\fR.
  .Sp
  Note that \f(CW\*(C`\-ftrack\-macro\-expansion=2\*(C'\fR is activated by default.
! .IP "\fB\-fmacro\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
  .IX Item "-fmacro-prefix-map=old=new"
! When preprocessing files residing in directory \fI\fIold\fI\fR,
  expand the \f(CW\*(C`_\|_FILE_\|_\*(C'\fR and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR macros as if the
! files resided in directory \fI\fInew\fI\fR instead.  This can be used
  to change an absolute path to a relative path by using \fI.\fR for
  \&\fInew\fR which can result in more reproducible builds that are
  location independent.  This option also affects
  \&\f(CW\*(C`_\|_builtin_FILE()\*(C'\fR during compilation.  See also
  \&\fB\-ffile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP "\fB\-fexec\-charset=\fR\fIcharset\fR" 4
  .IX Item "-fexec-charset=charset"
  Set the execution character set, used for string and character
! constants.  The default is \s-1UTF\-8.\s0  \fIcharset\fR can be any encoding
! supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP "\fB\-fwide\-exec\-charset=\fR\fIcharset\fR" 4
  .IX Item "-fwide-exec-charset=charset"
  Set the wide execution character set, used for wide string and
! character constants.  The default is one of \s-1UTF\-32BE, UTF\-32LE, UTF\-16BE,\s0
! or \s-1UTF\-16LE,\s0 whichever corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR and the
! big-endian or little-endian byte order being used for code generation.  As
  with \fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
! by the system's \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
  problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
! .IP "\fB\-finput\-charset=\fR\fIcharset\fR" 4
  .IX Item "-finput-charset=charset"
  Set the input character set, used for translation from the character
! set of the input file to the source character set used by \s-1GCC.\s0  If the
! locale does not specify, or \s-1GCC\s0 cannot get this information from the
! locale, the default is \s-1UTF\-8.\s0  This can be overridden by either the locale
! or this command-line option.  Currently the command-line option takes
! precedence if there's a conflict.  \fIcharset\fR can be any encoding
! supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP "\fB\-fworking\-directory\fR" 4
  .IX Item "-fworking-directory"
  Enable generation of linemarkers in the preprocessor output that
  let the compiler know the current working directory at the time of
  preprocessing.  When this option is enabled, the preprocessor
  emits, after the initial linemarker, a second linemarker with the
! current working directory followed by two slashes.  \s-1GCC\s0 uses 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
--- 390,446 ----
  option makes the preprocessor and the compiler consume more
  memory. The \fIlevel\fR parameter can be used to choose the level of
  precision of token location tracking thus decreasing the memory
! consumption if necessary. Value \fB0\fR of \fIlevel\fR de\-activates
  this option. Value \fB1\fR tracks tokens locations in a
  degraded mode for the sake of minimal memory overhead. In this mode
  all tokens resulting from the expansion of an argument of a
! function\-like macro have the same location. Value \fB2\fR tracks
  tokens locations completely. This value is the most memory hungry.
  When this option is given no argument, the default parameter value is
  \&\fB2\fR.
  .Sp
  Note that \f(CW\*(C`\-ftrack\-macro\-expansion=2\*(C'\fR is activated by default.
! .IP \fB\-fmacro\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 4
  .IX Item "-fmacro-prefix-map=old=new"
! When preprocessing files residing in directory \fIold\fR,
  expand the \f(CW\*(C`_\|_FILE_\|_\*(C'\fR and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR macros as if the
! files resided in directory \fInew\fR instead.  This can be used
  to change an absolute path to a relative path by using \fI.\fR for
  \&\fInew\fR which can result in more reproducible builds that are
  location independent.  This option also affects
  \&\f(CW\*(C`_\|_builtin_FILE()\*(C'\fR during compilation.  See also
  \&\fB\-ffile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP \fB\-fexec\-charset=\fR\fIcharset\fR 4
  .IX Item "-fexec-charset=charset"
  Set the execution character set, used for string and character
! constants.  The default is UTF\-8.  \fIcharset\fR can be any encoding
! supported by the system\*(Aqs \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP \fB\-fwide\-exec\-charset=\fR\fIcharset\fR 4
  .IX Item "-fwide-exec-charset=charset"
  Set the wide execution character set, used for wide string and
! character constants.  The default is one of UTF\-32BE, UTF\-32LE, UTF\-16BE,
! or UTF\-16LE, whichever corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR and the
! big\-endian or little\-endian byte order being used for code generation.  As
  with \fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
! by the system\*(Aqs \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
  problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
! .IP \fB\-finput\-charset=\fR\fIcharset\fR 4
  .IX Item "-finput-charset=charset"
  Set the input character set, used for translation from the character
! set of the input file to the source character set used by 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\*(Aqs a conflict.  \fIcharset\fR can be any encoding
! supported by the system\*(Aqs \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP \fB\-fworking\-directory\fR 4
  .IX Item "-fworking-directory"
  Enable generation of linemarkers in the preprocessor output that
  let the compiler know the current working directory at the time of
  preprocessing.  When this option is enabled, the preprocessor
  emits, after the initial linemarker, a second linemarker with the
! current working directory followed by two slashes.  GCC uses this
! directory, when it\*(Aqs 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
*************** it does not use shell special characters
*** 532,538 ****
  .IX Item "-A -predicate=answer"
  Cancel an assertion with the predicate \fIpredicate\fR and answer
  \&\fIanswer\fR.
! .IP "\fB\-C\fR" 4
  .IX Item "-C"
  Do not discard comments.  All comments are passed through to the output
  file, except for comments in processed directives, which are deleted
--- 457,463 ----
  .IX Item "-A -predicate=answer"
  Cancel an assertion with the predicate \fIpredicate\fR and answer
  \&\fIanswer\fR.
! .IP \fB\-C\fR 4
  .IX Item "-C"
  Do not discard comments.  All comments are passed through to the output
  file, except for comments in processed directives, which are deleted
*************** causes the preprocessor to treat comment
*** 543,611 ****
  For example, comments appearing at the start of what would be a
  directive line have the effect of turning that line into an ordinary
  source line, since the first token on the line is no longer a \fB#\fR.
! .IP "\fB\-CC\fR" 4
  .IX Item "-CC"
  Do not discard comments, including during macro expansion.  This is
  like \fB\-C\fR, except that comments contained within macros are
  also passed through to the output file where the macro is expanded.
  .Sp
  In addition to the side effects of the \fB\-C\fR option, the
! \&\fB\-CC\fR option causes all \*(C+\-style comments inside a macro
  to be converted to C\-style comments.  This is to prevent later use
  of that macro from inadvertently commenting out the remainder of
  the source line.
  .Sp
  The \fB\-CC\fR option is generally used to support lint comments.
! .IP "\fB\-P\fR" 4
  .IX Item "-P"
  Inhibit generation of linemarkers in the output from the preprocessor.
  This might be useful when running the preprocessor on something that is
  not C code, and will be sent to a program which might be confused by the
  linemarkers.
! .IP "\fB\-traditional\fR" 4
  .IX Item "-traditional"
  .PD 0
! .IP "\fB\-traditional\-cpp\fR" 4
  .IX Item "-traditional-cpp"
  .PD
! Try to imitate the behavior of pre-standard C preprocessors, as
! opposed to \s-1ISO C\s0 preprocessors.
  .Sp
! Note that \s-1GCC\s0 does not otherwise attempt to emulate a pre-standard 
  C compiler, and these options are only supported with the \fB\-E\fR 
! switch, or when invoking \s-1CPP\s0 explicitly.
! .IP "\fB\-trigraphs\fR" 4
  .IX Item "-trigraphs"
! Support \s-1ISO C\s0 trigraphs.
! These are three-character sequences, all starting with \fB??\fR, that
! are defined by \s-1ISO C\s0 to stand for single characters.  For example,
! \&\fB??/\fR stands for \fB\e\fR, so \fB'??/n'\fR is a character
  constant for a newline.
  .Sp
! By default, \s-1GCC\s0 ignores trigraphs, but in
! standard-conforming modes it converts them.  See the \fB\-std\fR and
  \&\fB\-ansi\fR options.
! .IP "\fB\-remap\fR" 4
  .IX Item "-remap"
  Enable special code to work around file systems which only permit very
! short file names, such as MS-DOS.
! .IP "\fB\-H\fR" 4
  .IX Item "-H"
  Print the name of each header file used, in addition to other normal
  activities.  Each name is indented to show how deep in the
  \&\fB#include\fR stack it is.  Precompiled header files are also
  printed, even if they are found to be invalid; an invalid precompiled
  header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
! .IP "\fB\-d\fR\fIletters\fR" 4
  .IX Item "-dletters"
  Says to make debugging dumps during compilation as specified by
  \&\fIletters\fR.  The flags documented here are those relevant to the
  preprocessor.  Other \fIletters\fR are interpreted
! by the compiler proper, or reserved for future versions of \s-1GCC,\s0 and so
  are silently ignored.  If you specify \fIletters\fR whose behavior
  conflicts, the result is undefined.
  .RS 4
! .IP "\fB\-dM\fR" 4
  .IX Item "-dM"
  Instead of the normal output, generate a list of \fB#define\fR
  directives for all the macros defined during the execution of the
--- 468,536 ----
  For example, comments appearing at the start of what would be a
  directive line have the effect of turning that line into an ordinary
  source line, since the first token on the line is no longer a \fB#\fR.
! .IP \fB\-CC\fR 4
  .IX Item "-CC"
  Do not discard comments, including during macro expansion.  This is
  like \fB\-C\fR, except that comments contained within macros are
  also passed through to the output file where the macro is expanded.
  .Sp
  In addition to the side effects of the \fB\-C\fR option, the
! \&\fB\-CC\fR option causes all C++\-style comments inside a macro
  to be converted to C\-style comments.  This is to prevent later use
  of that macro from inadvertently commenting out the remainder of
  the source line.
  .Sp
  The \fB\-CC\fR option is generally used to support lint comments.
! .IP \fB\-P\fR 4
  .IX Item "-P"
  Inhibit generation of linemarkers in the output from the preprocessor.
  This might be useful when running the preprocessor on something that is
  not C code, and will be sent to a program which might be confused by the
  linemarkers.
! .IP \fB\-traditional\fR 4
  .IX Item "-traditional"
  .PD 0
! .IP \fB\-traditional\-cpp\fR 4
  .IX Item "-traditional-cpp"
  .PD
! Try to imitate the behavior of pre\-standard C preprocessors, as
! opposed to ISO C preprocessors.
  .Sp
! Note that GCC does not otherwise attempt to emulate a pre\-standard 
  C compiler, and these options are only supported with the \fB\-E\fR 
! switch, or when invoking CPP explicitly.
! .IP \fB\-trigraphs\fR 4
  .IX Item "-trigraphs"
! Support ISO C trigraphs.
! These are three\-character sequences, all starting with \fB??\fR, that
! are defined by ISO C to stand for single characters.  For example,
! \&\fB??/\fR stands for \fB\e\fR, so \fB\*(Aq??/n\*(Aq\fR is a character
  constant for a newline.
  .Sp
! By default, GCC ignores trigraphs, but in
! standard\-conforming modes it converts them.  See the \fB\-std\fR and
  \&\fB\-ansi\fR options.
! .IP \fB\-remap\fR 4
  .IX Item "-remap"
  Enable special code to work around file systems which only permit very
! short file names, such as MS\-DOS.
! .IP \fB\-H\fR 4
  .IX Item "-H"
  Print the name of each header file used, in addition to other normal
  activities.  Each name is indented to show how deep in the
  \&\fB#include\fR stack it is.  Precompiled header files are also
  printed, even if they are found to be invalid; an invalid precompiled
  header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
! .IP \fB\-d\fR\fIletters\fR 4
  .IX Item "-dletters"
  Says to make debugging dumps during compilation as specified by
  \&\fIletters\fR.  The flags documented here are those relevant to the
  preprocessor.  Other \fIletters\fR are interpreted
! by the compiler proper, or reserved for future versions of GCC, and so
  are silently ignored.  If you specify \fIletters\fR whose behavior
  conflicts, the result is undefined.
  .RS 4
! .IP \fB\-dM\fR 4
  .IX Item "-dM"
  Instead of the normal output, generate a list of \fB#define\fR
  directives for all the macros defined during the execution of the
*************** Assuming you have no file \fIfoo.h\fR, t
*** 618,637 ****
  .Ve
  .Sp
  shows all the predefined macros.
! .IP "\fB\-dD\fR" 4
  .IX Item "-dD"
  Like \fB\-dM\fR except in two respects: it does \fInot\fR include the
  predefined macros, and it outputs \fIboth\fR the \fB#define\fR
  directives and the result of preprocessing.  Both kinds of output go to
  the standard output file.
! .IP "\fB\-dN\fR" 4
  .IX Item "-dN"
  Like \fB\-dD\fR, but emit only the macro names, not their expansions.
! .IP "\fB\-dI\fR" 4
  .IX Item "-dI"
  Output \fB#include\fR directives in addition to the result of
  preprocessing.
! .IP "\fB\-dU\fR" 4
  .IX Item "-dU"
  Like \fB\-dD\fR except that only macros that are expanded, or whose
  definedness is tested in preprocessor directives, are output; the
--- 543,562 ----
  .Ve
  .Sp
  shows all the predefined macros.
! .IP \fB\-dD\fR 4
  .IX Item "-dD"
  Like \fB\-dM\fR except in two respects: it does \fInot\fR include the
  predefined macros, and it outputs \fIboth\fR the \fB#define\fR
  directives and the result of preprocessing.  Both kinds of output go to
  the standard output file.
! .IP \fB\-dN\fR 4
  .IX Item "-dN"
  Like \fB\-dD\fR, but emit only the macro names, not their expansions.
! .IP \fB\-dI\fR 4
  .IX Item "-dI"
  Output \fB#include\fR directives in addition to the result of
  preprocessing.
! .IP \fB\-dU\fR 4
  .IX Item "-dU"
  Like \fB\-dD\fR except that only macros that are expanded, or whose
  definedness is tested in preprocessor directives, are output; the
*************** undefined at the time.
*** 641,654 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdebug\-cpp\fR" 4
  .IX Item "-fdebug-cpp"
! This option is only useful for debugging \s-1GCC.\s0  When used from \s-1CPP\s0 or with
  \&\fB\-E\fR, it dumps debugging information about location maps.  Every
  token in the output is preceded by the dump of the map its location
  belongs to.
  .Sp
! When used from \s-1GCC\s0 without \fB\-E\fR, this option has no effect.
  .IP "\fB\-I\fR \fIdir\fR" 4
  .IX Item "-I dir"
  .PD 0
--- 566,579 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-fdebug\-cpp\fR 4
  .IX Item "-fdebug-cpp"
! This option is only useful for debugging GCC.  When used from CPP or with
  \&\fB\-E\fR, it dumps debugging information about location maps.  Every
  token in the output is preceded by the dump of the map its location
  belongs to.
  .Sp
! When used from GCC without \fB\-E\fR, this option has no effect.
  .IP "\fB\-I\fR \fIdir\fR" 4
  .IX Item "-I dir"
  .PD 0
*************** or \f(CW$SYSROOT\fR is replaced by the s
*** 667,706 ****
  \&\fB\-\-sysroot\fR and \fB\-isysroot\fR.
  .Sp
  Directories specified with \fB\-iquote\fR apply only to the quote 
! form of the directive, \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.
  Directories specified with \fB\-I\fR, \fB\-isystem\fR, 
  or \fB\-idirafter\fR apply to lookup for both the
! \&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR and
! \&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR directives.
  .Sp
  You can specify any number or combination of these options on the 
  command line to search for header files in several directories.  
  The lookup order is as follows:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  For the quote form of the include directive, the directory of the current
  file is searched first.
! .IP "2." 4
  .IX Item "2."
  For the quote form of the include directive, the directories specified
! by \fB\-iquote\fR options are searched in left-to-right order,
  as they appear on the command line.
! .IP "3." 4
  .IX Item "3."
  Directories specified with \fB\-I\fR options are scanned in
! left-to-right order.
! .IP "4." 4
  .IX Item "4."
  Directories specified with \fB\-isystem\fR options are scanned in
! left-to-right order.
! .IP "5." 4
  .IX Item "5."
  Standard system directories are scanned.
! .IP "6." 4
  .IX Item "6."
  Directories specified with \fB\-idirafter\fR options are scanned in
! left-to-right order.
  .RE
  .RS 4
  .Sp
--- 592,631 ----
  \&\fB\-\-sysroot\fR and \fB\-isysroot\fR.
  .Sp
  Directories specified with \fB\-iquote\fR apply only to the quote 
! form of the directive, \f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR.
  Directories specified with \fB\-I\fR, \fB\-isystem\fR, 
  or \fB\-idirafter\fR apply to lookup for both the
! \&\f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR and
! \&\f(CW\*(C`#include\ <\fR\f(CIfile\fR\f(CW>\*(C'\fR directives.
  .Sp
  You can specify any number or combination of these options on the 
  command line to search for header files in several directories.  
  The lookup order is as follows:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  For the quote form of the include directive, the directory of the current
  file is searched first.
! .IP 2. 4
  .IX Item "2."
  For the quote form of the include directive, the directories specified
! by \fB\-iquote\fR options are searched in left\-to\-right order,
  as they appear on the command line.
! .IP 3. 4
  .IX Item "3."
  Directories specified with \fB\-I\fR options are scanned in
! left\-to\-right order.
! .IP 4. 4
  .IX Item "4."
  Directories specified with \fB\-isystem\fR options are scanned in
! left\-to\-right order.
! .IP 5. 4
  .IX Item "5."
  Standard system directories are scanned.
! .IP 6. 4
  .IX Item "6."
  Directories specified with \fB\-idirafter\fR options are scanned in
! left\-to\-right order.
  .RE
  .RS 4
  .Sp
*************** You can use \fB\-I\fR to override a syst
*** 708,714 ****
  file, substituting your own version, since these directories are
  searched before the standard system header file directories.  
  However, you should
! not use this option to add directories that contain vendor-supplied
  system header files; use \fB\-isystem\fR for that.
  .Sp
  The \fB\-isystem\fR and \fB\-idirafter\fR options also mark the directory
--- 633,639 ----
  file, substituting your own version, since these directories are
  searched before the standard system header file directories.  
  However, you should
! not use this option to add directories that contain vendor\-supplied
  system header files; use \fB\-isystem\fR for that.
  .Sp
  The \fB\-isystem\fR and \fB\-idirafter\fR options also mark the directory
*************** If a standard system include directory,
*** 719,731 ****
  \&\fB\-isystem\fR, is also specified with \fB\-I\fR, the \fB\-I\fR
  option is ignored.  The directory is still searched but as a
  system directory at its normal position in the system include chain.
! This is to ensure that \s-1GCC\s0's procedure to fix buggy system headers and
  the ordering for the \f(CW\*(C`#include_next\*(C'\fR directive are not inadvertently
  changed.
  If you really need to change the search order for system directories,
  use the \fB\-nostdinc\fR and/or \fB\-isystem\fR options.
  .RE
! .IP "\fB\-I\-\fR" 4
  .IX Item "-I-"
  Split the include path.
  This option has been deprecated.  Please use \fB\-iquote\fR instead for
--- 644,656 ----
  \&\fB\-isystem\fR, is also specified with \fB\-I\fR, the \fB\-I\fR
  option is ignored.  The directory is still searched but as a
  system directory at its normal position in the system include chain.
! This is to ensure that GCC\*(Aqs procedure to fix buggy system headers and
  the ordering for the \f(CW\*(C`#include_next\*(C'\fR directive are not inadvertently
  changed.
  If you really need to change the search order for system directories,
  use the \fB\-nostdinc\fR and/or \fB\-isystem\fR options.
  .RE
! .IP \fB\-I\-\fR 4
  .IX Item "-I-"
  Split the include path.
  This option has been deprecated.  Please use \fB\-iquote\fR instead for
*************** option.
*** 734,746 ****
  .Sp
  Any directories specified with \fB\-I\fR
  options before \fB\-I\-\fR are searched only for headers requested with
! \&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
! \&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR.  If additional directories are
  specified with \fB\-I\fR options after the \fB\-I\-\fR, those
  directories are searched for all \fB#include\fR directives.
  .Sp
  In addition, \fB\-I\-\fR inhibits the use of the directory of the current
! file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.  There is no way to override this effect of \fB\-I\-\fR.
  .IP "\fB\-iprefix\fR \fIprefix\fR" 4
  .IX Item "-iprefix prefix"
  Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
--- 659,671 ----
  .Sp
  Any directories specified with \fB\-I\fR
  options before \fB\-I\-\fR are searched only for headers requested with
! \&\f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR; they are not searched for
! \&\f(CW\*(C`#include\ <\fR\f(CIfile\fR\f(CW>\*(C'\fR.  If additional directories are
  specified with \fB\-I\fR options after the \fB\-I\-\fR, those
  directories are searched for all \fB#include\fR directives.
  .Sp
  In addition, \fB\-I\-\fR inhibits the use of the directory of the current
! file directory as the first search directory for \f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR.  There is no way to override this effect of \fB\-I\-\fR.
  .IP "\fB\-iprefix\fR \fIprefix\fR" 4
  .IX Item "-iprefix prefix"
  Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
*************** information.
*** 765,793 ****
  .IP "\fB\-imultilib\fR \fIdir\fR" 4
  .IX Item "-imultilib dir"
  Use \fIdir\fR as a subdirectory of the directory containing
! target-specific \*(C+ headers.
! .IP "\fB\-nostdinc\fR" 4
  .IX Item "-nostdinc"
  Do not search the standard system directories for header files.
  Only the directories explicitly specified with \fB\-I\fR,
  \&\fB\-iquote\fR, \fB\-isystem\fR, and/or \fB\-idirafter\fR
  options (and the directory of the current file, if appropriate) 
  are searched.
! .IP "\fB\-nostdinc++\fR" 4
  .IX Item "-nostdinc++"
! Do not search for header files in the \*(C+\-specific standard directories,
  but do still search the other standard directories.  (This option is
! used when building the \*(C+ library.)
! .IP "\fB\-Wcomment\fR" 4
  .IX Item "-Wcomment"
  .PD 0
! .IP "\fB\-Wcomments\fR" 4
  .IX Item "-Wcomments"
  .PD
! Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
! comment, or whenever a backslash-newline appears in a \fB//\fR comment.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wtrigraphs\fR" 4
  .IX Item "-Wtrigraphs"
  Warn if any trigraphs are encountered that might change the meaning of
  the program.  Trigraphs within comments are not warned about,
--- 690,718 ----
  .IP "\fB\-imultilib\fR \fIdir\fR" 4
  .IX Item "-imultilib dir"
  Use \fIdir\fR as a subdirectory of the directory containing
! target\-specific C++ headers.
! .IP \fB\-nostdinc\fR 4
  .IX Item "-nostdinc"
  Do not search the standard system directories for header files.
  Only the directories explicitly specified with \fB\-I\fR,
  \&\fB\-iquote\fR, \fB\-isystem\fR, and/or \fB\-idirafter\fR
  options (and the directory of the current file, if appropriate) 
  are searched.
! .IP \fB\-nostdinc++\fR 4
  .IX Item "-nostdinc++"
! Do not search for header files in the C++\-specific standard directories,
  but do still search the other standard directories.  (This option is
! used when building the C++ library.)
! .IP \fB\-Wcomment\fR 4
  .IX Item "-Wcomment"
  .PD 0
! .IP \fB\-Wcomments\fR 4
  .IX Item "-Wcomments"
  .PD
! Warn whenever a comment\-start sequence \fB/*\fR appears in a \fB/*\fR
! comment, or whenever a backslash\-newline appears in a \fB//\fR comment.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wtrigraphs\fR 4
  .IX Item "-Wtrigraphs"
  Warn if any trigraphs are encountered that might change the meaning of
  the program.  Trigraphs within comments are not warned about,
*************** This option is implied by \fB\-Wall\fR.
*** 797,825 ****
  given, this option is still enabled unless trigraphs are enabled.  To
  get trigraph conversion without warnings, but get the other
  \&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
! .IP "\fB\-Wundef\fR" 4
  .IX Item "-Wundef"
  Warn if an undefined identifier is evaluated in an \f(CW\*(C`#if\*(C'\fR directive.
  Such identifiers are replaced with zero.
! .IP "\fB\-Wexpansion\-to\-defined\fR" 4
  .IX Item "-Wexpansion-to-defined"
  Warn whenever \fBdefined\fR is encountered in the expansion of a macro
  (including the case where the macro is expanded by an \fB#if\fR directive).
  Such usage is not portable.
  This warning is also enabled by \fB\-Wpedantic\fR and \fB\-Wextra\fR.
! .IP "\fB\-Wunused\-macros\fR" 4
  .IX Item "-Wunused-macros"
  Warn about macros defined in the main file that are unused.  A macro
  is \fIused\fR if it is expanded or tested for existence at least once.
  The preprocessor also warns if the macro has not been used at the
  time it is redefined or undefined.
  .Sp
! Built-in macros, macros defined on the command line, and macros
  defined in include files are not warned about.
  .Sp
  \&\fINote:\fR If a macro is actually used, but only used in skipped
  conditional blocks, then the preprocessor reports it as unused.  To avoid the
! warning in such a case, you might improve the scope of the macro's
  definition by, for example, moving it into the first skipped block.
  Alternatively, you could provide a dummy use with something like:
  .Sp
--- 722,750 ----
  given, this option is still enabled unless trigraphs are enabled.  To
  get trigraph conversion without warnings, but get the other
  \&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
! .IP \fB\-Wundef\fR 4
  .IX Item "-Wundef"
  Warn if an undefined identifier is evaluated in an \f(CW\*(C`#if\*(C'\fR directive.
  Such identifiers are replaced with zero.
! .IP \fB\-Wexpansion\-to\-defined\fR 4
  .IX Item "-Wexpansion-to-defined"
  Warn whenever \fBdefined\fR is encountered in the expansion of a macro
  (including the case where the macro is expanded by an \fB#if\fR directive).
  Such usage is not portable.
  This warning is also enabled by \fB\-Wpedantic\fR and \fB\-Wextra\fR.
! .IP \fB\-Wunused\-macros\fR 4
  .IX Item "-Wunused-macros"
  Warn about macros defined in the main file that are unused.  A macro
  is \fIused\fR if it is expanded or tested for existence at least once.
  The preprocessor also warns if the macro has not been used at the
  time it is redefined or undefined.
  .Sp
! Built\-in macros, macros defined on the command line, and macros
  defined in include files are not warned about.
  .Sp
  \&\fINote:\fR If a macro is actually used, but only used in skipped
  conditional blocks, then the preprocessor reports it as unused.  To avoid the
! warning in such a case, you might improve the scope of the macro\*(Aqs
  definition by, for example, moving it into the first skipped block.
  Alternatively, you could provide a dummy use with something like:
  .Sp
*************** Alternatively, you could provide a dummy
*** 827,833 ****
  \&        #if defined the_macro_causing_the_warning
  \&        #endif
  .Ve
! .IP "\fB\-Wno\-endif\-labels\fR" 4
  .IX Item "-Wno-endif-labels"
  Do not warn whenever an \f(CW\*(C`#else\*(C'\fR or an \f(CW\*(C`#endif\*(C'\fR are followed by text.
  This sometimes happens in older programs with code of the form
--- 752,758 ----
  \&        #if defined the_macro_causing_the_warning
  \&        #endif
  .Ve
! .IP \fB\-Wno\-endif\-labels\fR 4
  .IX Item "-Wno-endif-labels"
  Do not warn whenever an \f(CW\*(C`#else\*(C'\fR or an \f(CW\*(C`#endif\*(C'\fR are followed by text.
  This sometimes happens in older programs with code of the form
*************** This sometimes happens in older programs
*** 842,850 ****
  .Sp
  The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments.
  This warning is on by default.
! .SH "ENVIRONMENT"
  .IX Header "ENVIRONMENT"
! This section describes the environment variables that affect how \s-1CPP\s0
  operates.  You can use them to specify directories or prefixes to use
  when searching for include files, or to control dependency output.
  .PP
--- 767,775 ----
  .Sp
  The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments.
  This warning is on by default.
! .SH ENVIRONMENT
  .IX Header "ENVIRONMENT"
! This section describes the environment variables that affect how CPP
  operates.  You can use them to specify directories or prefixes to use
  when searching for include files, or to control dependency output.
  .PP
*************** Note that you can also specify places to
*** 852,875 ****
  \&\fB\-I\fR, and control dependency output with options like
  \&\fB\-M\fR.  These take precedence over
  environment variables, which in turn take precedence over the
! configuration of \s-1GCC.\s0
! .IP "\fB\s-1CPATH\s0\fR" 4
  .IX Item "CPATH"
  .PD 0
! .IP "\fBC_INCLUDE_PATH\fR" 4
  .IX Item "C_INCLUDE_PATH"
! .IP "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4
  .IX Item "CPLUS_INCLUDE_PATH"
! .IP "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4
  .IX Item "OBJC_INCLUDE_PATH"
  .PD
! Each variable's value is a list of directories separated by a special
! character, much like \fB\s-1PATH\s0\fR, in which to look for header files.
! The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, is target-dependent and
! determined at \s-1GCC\s0 build time.  For Microsoft Windows-based targets it is a
  semicolon, and for almost all other targets it is a colon.
  .Sp
! \&\fB\s-1CPATH\s0\fR specifies a list of directories to be searched as if
  specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
  options on the command line.  This environment variable is used
  regardless of which language is being preprocessed.
--- 777,800 ----
  \&\fB\-I\fR, and control dependency output with options like
  \&\fB\-M\fR.  These take precedence over
  environment variables, which in turn take precedence over the
! configuration of GCC.
! .IP \fBCPATH\fR 4
  .IX Item "CPATH"
  .PD 0
! .IP \fBC_INCLUDE_PATH\fR 4
  .IX Item "C_INCLUDE_PATH"
! .IP \fBCPLUS_INCLUDE_PATH\fR 4
  .IX Item "CPLUS_INCLUDE_PATH"
! .IP \fBOBJC_INCLUDE_PATH\fR 4
  .IX Item "OBJC_INCLUDE_PATH"
  .PD
! Each variable\*(Aqs value is a list of directories separated by a special
! character, much like \fBPATH\fR, in which to look for header files.
! The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, 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.
  .Sp
! \&\fBCPATH\fR specifies a list of directories to be searched as if
  specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
  options on the command line.  This environment variable is used
  regardless of which language is being preprocessed.
*************** paths given with \fB\-isystem\fR options
*** 882,897 ****
  In all these variables, an empty element instructs the compiler to
  search its current working directory.  Empty elements can appear at the
  beginning or end of a path.  For instance, if the value of
! \&\fB\s-1CPATH\s0\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
  effect as \fB\-I.\ \-I/special/include\fR.
! .IP "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4
  .IX Item "DEPENDENCIES_OUTPUT"
  If this variable is set, its value specifies how to output
! dependencies for Make based on the non-system header files processed
  by the compiler.  System header files are ignored in the dependency
  output.
  .Sp
! The value of \fB\s-1DEPENDENCIES_OUTPUT\s0\fR can be just a file name, in
  which case the Make rules are written to that file, guessing the target
  name from the source file name.  Or the value can have the form
  \&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
--- 807,822 ----
  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
! \&\fBCPATH\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
  effect as \fB\-I.\ \-I/special/include\fR.
! .IP \fBDEPENDENCIES_OUTPUT\fR 4
  .IX Item "DEPENDENCIES_OUTPUT"
  If this variable is set, its value specifies how to output
! dependencies for Make based on the non\-system header files processed
  by the compiler.  System header files are ignored in the dependency
  output.
  .Sp
! The value of \fBDEPENDENCIES_OUTPUT\fR can be just a file name, in
  which case the Make rules are written to that file, guessing the target
  name from the source file name.  Or the value can have the form
  \&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
*************** file \fIfile\fR using \fItarget\fR as th
*** 900,921 ****
  In other words, this environment variable is equivalent to combining
  the options \fB\-MM\fR and \fB\-MF\fR,
  with an optional \fB\-MT\fR switch too.
! .IP "\fB\s-1SUNPRO_DEPENDENCIES\s0\fR" 4
  .IX Item "SUNPRO_DEPENDENCIES"
! This variable is the same as \fB\s-1DEPENDENCIES_OUTPUT\s0\fR (see above),
  except that system header files are not ignored, so it implies
  \&\fB\-M\fR rather than \fB\-MM\fR.  However, the dependence on the
  main input file is omitted.
! .IP "\fB\s-1SOURCE_DATE_EPOCH\s0\fR" 4
  .IX Item "SOURCE_DATE_EPOCH"
! If this variable is set, its value specifies a \s-1UNIX\s0 timestamp to be
  used in replacement of the current date and time in the \f(CW\*(C`_\|_DATE_\|_\*(C'\fR
  and \f(CW\*(C`_\|_TIME_\|_\*(C'\fR macros, so that the embedded timestamps become
  reproducible.
  .Sp
! The value of \fB\s-1SOURCE_DATE_EPOCH\s0\fR must be a \s-1UNIX\s0 timestamp,
  defined as the number of seconds (excluding leap seconds) since
! 01 Jan 1970 00:00:00 represented in \s-1ASCII\s0; identical to the output of
  \&\f(CW\*(C`date +%s\*(C'\fR on GNU/Linux and other systems that support the
  \&\f(CW%s\fR extension in the \f(CW\*(C`date\*(C'\fR command.
  .Sp
--- 825,846 ----
  In other words, this environment variable is equivalent to combining
  the options \fB\-MM\fR and \fB\-MF\fR,
  with an optional \fB\-MT\fR switch too.
! .IP \fBSUNPRO_DEPENDENCIES\fR 4
  .IX Item "SUNPRO_DEPENDENCIES"
! This variable is the same as \fBDEPENDENCIES_OUTPUT\fR (see above),
  except that system header files are not ignored, so it implies
  \&\fB\-M\fR rather than \fB\-MM\fR.  However, the dependence on the
  main input file is omitted.
! .IP \fBSOURCE_DATE_EPOCH\fR 4
  .IX Item "SOURCE_DATE_EPOCH"
! If this variable is set, its value specifies a UNIX timestamp to be
  used in replacement of the current date and time in the \f(CW\*(C`_\|_DATE_\|_\*(C'\fR
  and \f(CW\*(C`_\|_TIME_\|_\*(C'\fR macros, so that the embedded timestamps become
  reproducible.
  .Sp
! The value of \fBSOURCE_DATE_EPOCH\fR must be a UNIX timestamp,
  defined as the number of seconds (excluding leap seconds) since
! 01 Jan 1970 00:00:00 represented in ASCII; identical to the output of
  \&\f(CW\*(C`date +%s\*(C'\fR on GNU/Linux and other systems that support the
  \&\f(CW%s\fR extension in the \f(CW\*(C`date\*(C'\fR command.
  .Sp
*************** process.
*** 926,950 ****
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7),
  \&\fBgcc\fR\|(1), and the Info entries for \fIcpp\fR and \fIgcc\fR.
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 1987\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation.  A copy of
  the license is included in the
  man page \fBgfdl\fR\|(7).
! This manual contains no Invariant Sections.  The Front-Cover Texts are
! (a) (see below), and the Back-Cover Texts are (b) (see below).
  .PP
! (a) The \s-1FSF\s0's Front-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The \s-1FSF\s0's Back-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
--- 851,875 ----
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7),
  \&\fBgcc\fR\|(1), and the Info entries for \fIcpp\fR and \fIgcc\fR.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 1987\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the GNU Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation.  A copy of
  the license is included in the
  man page \fBgfdl\fR\|(7).
! This manual contains no Invariant Sections.  The Front\-Cover Texts are
! (a) (see below), and the Back\-Cover Texts are (b) (see below).
  .PP
! (a) The FSF\*(Aqs Front\-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The FSF\*(Aqs Back\-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
diff -Nrcpad gcc-13.4.0/gcc/doc/cpp.info gcc-13.5.0-RC-20260904/gcc/doc/cpp.info
*** gcc-13.4.0/gcc/doc/cpp.info	Thu Jun  5 16:21:56 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/cpp.info	Fri Sep  4 07:50:36 2026
***************
*** 1,6 ****
! This is cpp.info, produced by makeinfo version 6.8 from cpp.texi.
  
! Copyright (C) 1987-2023 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
--- 1,6 ----
! This is cpp.info, produced by makeinfo version 7.1 from cpp.texi.
  
! Copyright © 1987-2023 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
*************** Obsolete Features
*** 130,136 ****
  * Obsolete Features::
  
  
!    Copyright (C) 1987-2023 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
--- 130,136 ----
  * Obsolete Features::
  
  
!    Copyright © 1987-2023 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
*************** File: cpp.info,  Node: Overview,  Next:
*** 157,166 ****
  1 Overview
  **********
  
! The C preprocessor, often known as "cpp", is a "macro processor" that is
  used automatically by the C compiler to transform your program before
  compilation.  It is called a macro processor because it allows you to
! define "macros", which are brief abbreviations for longer constructs.
  
     The C preprocessor is intended to be used only with C, C++, and
  Objective-C source code.  In the past, it has been abused as a general
--- 157,166 ----
  1 Overview
  **********
  
! The C preprocessor, often known as “cpp”, is a “macro processor” that is
  used automatically by the C compiler to transform your program before
  compilation.  It is called a macro processor because it allows you to
! define “macros”, which are brief abbreviations for longer constructs.
  
     The C preprocessor is intended to be used only with C, C++, and
  Objective-C source code.  In the past, it has been abused as a general
*************** will be removed, and the Makefile will n
*** 173,179 ****
  
     Having said that, you can often get away with using cpp on things
  which are not C.  Other Algol-ish programming languages are often safe
! (Ada, etc.)  So is assembly, with caution.  '-traditional-cpp' mode
  preserves more white space, and is otherwise more permissive.  Many of
  the problems can be avoided by writing C or C++ style comments instead
  of native language comments, and keeping macros simple.
--- 173,179 ----
  
     Having said that, you can often get away with using cpp on things
  which are not C.  Other Algol-ish programming languages are often safe
! (Ada, etc.)  So is assembly, with caution.  ‘-traditional-cpp’ mode
  preserves more white space, and is otherwise more permissive.  Many of
  the problems can be avoided by writing C or C++ style comments instead
  of native language comments, and keeping macros simple.
*************** Standard C.  In its default mode, the GN
*** 190,198 ****
  few things required by the standard.  These are features which are
  rarely, if ever, used, and may cause surprising changes to the meaning
  of a program which does not expect them.  To get strict ISO Standard C,
! you should use the '-std=c90', '-std=c99', '-std=c11' or '-std=c17'
  options, depending on which version of the standard you want.  To get
! all the mandatory diagnostics, you must also use '-pedantic'.  *Note
  Invocation::.
  
     This manual describes the behavior of the ISO preprocessor.  To
--- 190,198 ----
  few things required by the standard.  These are features which are
  rarely, if ever, used, and may cause surprising changes to the meaning
  of a program which does not expect them.  To get strict ISO Standard C,
! you should use the ‘-std=c90’, ‘-std=c99’, ‘-std=c11’ or ‘-std=c17’
  options, depending on which version of the standard you want.  To get
! all the mandatory diagnostics, you must also use ‘-pedantic’.  *Note
  Invocation::.
  
     This manual describes the behavior of the ISO preprocessor.  To
*************** does not conflict with traditional seman
*** 201,207 ****
  preprocessor should behave the same way.  The various differences that
  do exist are detailed in the section *note Traditional Mode::.
  
!    For clarity, unless noted otherwise, references to 'CPP' in this
  manual refer to GNU CPP.
  
  * Menu:
--- 201,207 ----
  preprocessor should behave the same way.  The various differences that
  do exist are detailed in the section *note Traditional Mode::.
  
!    For clarity, unless noted otherwise, references to ‘CPP’ in this
  manual refer to GNU CPP.
  
  * Menu:
*************** there are really at least four.
*** 224,247 ****
     The files input to CPP might be in any character set at all.  CPP's
  very first action, before it even looks for line boundaries, is to
  convert the file into the character set it uses for internal processing.
! That set is what the C standard calls the "source" character set.  It
  must be isomorphic with ISO 10646, also known as Unicode.  CPP uses the
  UTF-8 encoding of Unicode.
  
     The character sets of the input files are specified using the
! '-finput-charset=' option.
  
     All preprocessing work (the subject of the rest of this manual) is
  carried out in the source character set.  If you request textual output
! from the preprocessor with the '-E' option, it will be in UTF-8.
  
     After preprocessing is complete, string and character constants are
! converted again, into the "execution" character set.  This character set
  is under control of the user; the default is UTF-8, matching the source
  character set.  Wide string and character constants have their own
  character set, which is not called out specifically in the standard.
  Again, it is under control of the user.  The default is UTF-16 or
! UTF-32, whichever fits in the target's 'wchar_t' type, in the target
  machine's byte order.(1)  Octal and hexadecimal escape sequences do not
  undergo conversion; '\x12' has the value 0x12 regardless of the
  currently selected execution character set.  All other escapes are
--- 224,247 ----
     The files input to CPP might be in any character set at all.  CPP's
  very first action, before it even looks for line boundaries, is to
  convert the file into the character set it uses for internal processing.
! That set is what the C standard calls the “source” character set.  It
  must be isomorphic with ISO 10646, also known as Unicode.  CPP uses the
  UTF-8 encoding of Unicode.
  
     The character sets of the input files are specified using the
! ‘-finput-charset=’ option.
  
     All preprocessing work (the subject of the rest of this manual) is
  carried out in the source character set.  If you request textual output
! from the preprocessor with the ‘-E’ option, it will be in UTF-8.
  
     After preprocessing is complete, string and character constants are
! converted again, into the “execution” character set.  This character set
  is under control of the user; the default is UTF-8, matching the source
  character set.  Wide string and character constants have their own
  character set, which is not called out specifically in the standard.
  Again, it is under control of the user.  The default is UTF-16 or
! UTF-32, whichever fits in the target's ‘wchar_t’ type, in the target
  machine's byte order.(1)  Octal and hexadecimal escape sequences do not
  undergo conversion; '\x12' has the value 0x12 regardless of the
  currently selected execution character set.  All other escapes are
*************** represent, then converted to the executi
*** 250,264 ****
  unescaped characters.
  
     In identifiers, characters outside the ASCII range can be specified
! with the '\u' and '\U' escapes or used directly in the input encoding.
  If strict ISO C90 conformance is specified with an option such as
! '-std=c90', or '-fno-extended-identifiers' is used, then those
  constructs are not permitted in identifiers.
  
     ---------- Footnotes ----------
  
     (1) UTF-16 does not meet the requirements of the C standard for a
! wide character set, but the choice of 16-bit 'wchar_t' is enshrined in
  some system ABIs so we cannot fix this.
  
  
--- 250,264 ----
  unescaped characters.
  
     In identifiers, characters outside the ASCII range can be specified
! with the ‘\u’ and ‘\U’ escapes or used directly in the input encoding.
  If strict ISO C90 conformance is specified with an option such as
! ‘-std=c90’, or ‘-fno-extended-identifiers’ is used, then those
  constructs are not permitted in identifiers.
  
     ---------- Footnotes ----------
  
     (1) UTF-16 does not meet the requirements of the C standard for a
! wide character set, but the choice of 16-bit ‘wchar_t’ is enshrined in
  some system ABIs so we cannot fix this.
  
  
*************** standard.
*** 278,285 ****
    1. The input file is read into memory and broken into lines.
  
       Different systems use different conventions to indicate the end of
!      a line.  GCC accepts the ASCII control sequences 'LF', 'CR LF' and
!      'CR' as end-of-line markers.  These are the canonical sequences
       used by Unix, DOS and VMS, and the classic Mac OS (before OSX)
       respectively.  You may therefore safely copy source code written on
       any of those systems to a different one and use it without
--- 278,285 ----
    1. The input file is read into memory and broken into lines.
  
       Different systems use different conventions to indicate the end of
!      a line.  GCC accepts the ASCII control sequences ‘LF’, ‘CR LF’ and
!      ‘CR’ as end-of-line markers.  These are the canonical sequences
       used by Unix, DOS and VMS, and the classic Mac OS (before OSX)
       respectively.  You may therefore safely copy source code written on
       any of those systems to a different one and use it without
*************** standard.
*** 295,312 ****
  
    2. If trigraphs are enabled, they are replaced by their corresponding
       single characters.  By default GCC ignores trigraphs, but if you
!      request a strictly conforming mode with the '-std' option, or you
!      specify the '-trigraphs' option, then it converts them.
  
!      These are nine three-character sequences, all starting with '??',
       that are defined by ISO C to stand for single characters.  They
       permit obsolete systems that lack some of C's punctuation to use C.
!      For example, '??/' stands for '\', so '??/n' is a character
       constant for a newline.
  
       Trigraphs are not popular and many compilers implement them
       incorrectly.  Portable code should not rely on trigraphs being
!      either converted or ignored.  With '-Wtrigraphs' GCC will warn you
       when a trigraph may change the meaning of your program if it were
       converted.  *Note Wtrigraphs::.
  
--- 295,312 ----
  
    2. If trigraphs are enabled, they are replaced by their corresponding
       single characters.  By default GCC ignores trigraphs, but if you
!      request a strictly conforming mode with the ‘-std’ option, or you
!      specify the ‘-trigraphs’ option, then it converts them.
  
!      These are nine three-character sequences, all starting with ‘??’,
       that are defined by ISO C to stand for single characters.  They
       permit obsolete systems that lack some of C's punctuation to use C.
!      For example, ‘??/’ stands for ‘\’, so '??/n' is a character
       constant for a newline.
  
       Trigraphs are not popular and many compilers implement them
       incorrectly.  Portable code should not rely on trigraphs being
!      either converted or ignored.  With ‘-Wtrigraphs’ GCC will warn you
       when a trigraph may change the meaning of your program if it were
       converted.  *Note Wtrigraphs::.
  
*************** standard.
*** 314,320 ****
       from being confused with a trigraph by inserting a backslash
       between the question marks, or by separating the string literal at
       the trigraph and making use of string literal concatenation.
!      "(??\?)" is the string '(???)', not '(?]'.  Traditional C compilers
       do not recognize these idioms.
  
       The nine trigraphs and their replacements are
--- 314,320 ----
       from being confused with a trigraph by inserting a backslash
       between the question marks, or by separating the string literal at
       the trigraph and making use of string literal concatenation.
!      "(??\?)" is the string ‘(???)’, not ‘(?]’.  Traditional C compilers
       do not recognize these idioms.
  
       The nine trigraphs and their replacements are
*************** standard.
*** 324,337 ****
  
    3. Continued lines are merged into one long line.
  
!      A continued line is a line which ends with a backslash, '\'.  The
       backslash is removed and the following line is joined with the
       current one.  No space is inserted, so you may split a line
       anywhere, even in the middle of a word.  (It is generally more
       readable to split lines only at white space.)
  
       The trailing backslash on a continued line is commonly referred to
!      as a "backslash-newline".
  
       If there is white space between a backslash and the end of a line,
       that is still a continued line.  However, as this is usually the
--- 324,337 ----
  
    3. Continued lines are merged into one long line.
  
!      A continued line is a line which ends with a backslash, ‘\’.  The
       backslash is removed and the following line is joined with the
       current one.  No space is inserted, so you may split a line
       anywhere, even in the middle of a word.  (It is generally more
       readable to split lines only at white space.)
  
       The trailing backslash on a continued line is commonly referred to
!      as a “backslash-newline”.
  
       If there is white space between a backslash and the end of a line,
       that is still a continued line.  However, as this is usually the
*************** standard.
*** 340,351 ****
  
    4. All comments are replaced with single spaces.
  
!      There are two kinds of comments.  "Block comments" begin with '/*'
!      and continue until the next '*/'.  Block comments do not nest:
  
            /* this is /* one comment */ text outside comment
  
!      "Line comments" begin with '//' and continue to the end of the
       current line.  Line comments do not nest either, but it does not
       matter, because they would end in the same place anyway.
  
--- 340,351 ----
  
    4. All comments are replaced with single spaces.
  
!      There are two kinds of comments.  “Block comments” begin with ‘/*’
!      and continue until the next ‘*/’.  Block comments do not nest:
  
            /* this is /* one comment */ text outside comment
  
!      “Line comments” begin with ‘//’ and continue to the end of the
       current line.  Line comments do not nest either, but it does not
       matter, because they would end in the same place anyway.
  
*************** comment.
*** 368,374 ****
           oops! this isn't a comment anymore */
  
     Comments are not recognized within string literals.  "/* blah */" is
! the string constant '/* blah */', not an empty string.
  
     Line comments are not in the 1989 edition of the C standard, but they
  are recognized by GCC as an extension.  In C++ and in the 1999 edition
--- 368,374 ----
           oops! this isn't a comment anymore */
  
     Comments are not recognized within string literals.  "/* blah */" is
! the string constant ‘/* blah */’, not an empty string.
  
     Line comments are not in the 1989 edition of the C standard, but they
  are recognized by GCC as an extension.  In C++ and in the 1999 edition
*************** of the C standard, they are an official
*** 377,384 ****
     Since these transformations happen before all other processing, you
  can split a line mechanically with backslash-newline anywhere.  You can
  comment out the end of a line.  You can continue a line comment onto the
! next line with backslash-newline.  You can even split '/*', '*/', and
! '//' onto multiple lines with backslash-newline.  For example:
  
       /\
       *
--- 377,384 ----
     Since these transformations happen before all other processing, you
  can split a line mechanically with backslash-newline anywhere.  You can
  comment out the end of a line.  You can continue a line comment onto the
! next line with backslash-newline.  You can even split ‘/*’, ‘*/’, and
! ‘//’ onto multiple lines with backslash-newline.  For example:
  
       /\
       *
*************** next line with backslash-newline.  You c
*** 388,394 ****
       O 10\
       20
  
! is equivalent to '#define FOO 1020'.  All these tricks are extremely
  confusing and should not be used in code intended to be readable.
  
     There is no way to prevent a backslash at the end of a line from
--- 388,394 ----
       O 10\
       20
  
! is equivalent to ‘#define FOO 1020’.  All these tricks are extremely
  confusing and should not be used in code intended to be readable.
  
     There is no way to prevent a backslash at the end of a line from
*************** File: cpp.info,  Node: Tokenization,  Ne
*** 402,408 ****
  ================
  
  After the textual transformations are finished, the input file is
! converted into a sequence of "preprocessing tokens".  These mostly
  correspond to the syntactic tokens used by the C compiler, but there are
  a few differences.  White space separates tokens; it is not itself a
  token of any kind.  Tokens do not have to be separated by white space,
--- 402,408 ----
  ================
  
  After the textual transformations are finished, the input file is
! converted into a sequence of “preprocessing tokens”.  These mostly
  correspond to the syntactic tokens used by the C compiler, but there are
  a few differences.  White space separates tokens; it is not itself a
  token of any kind.  Tokens do not have to be separated by white space,
*************** but it is often necessary to avoid ambig
*** 411,441 ****
     When faced with a sequence of characters that has more than one
  possible tokenization, the preprocessor is greedy.  It always makes each
  token, starting from the left, as big as possible before moving on to
! the next token.  For instance, 'a+++++b' is interpreted as
! 'a ++ ++ + b', not as 'a ++ + ++ b', even though the latter tokenization
  could be part of a valid C program and the former could not.
  
     Once the input file is broken into tokens, the token boundaries never
! change, except when the '##' preprocessing operator is used to paste
  tokens together.  *Note Concatenation::.  For example,
  
       #define foo() bar
       foo()baz
!           ==> bar baz
       _not_
!           ==> barbaz
  
     The compiler does not re-tokenize the preprocessor's output.  Each
  preprocessing token becomes one compiler token.
  
     Preprocessing tokens fall into five broad classes: identifiers,
  preprocessing numbers, string literals, punctuators, and other.  An
! "identifier" is the same as an identifier in C: any sequence of letters,
  digits, or underscores, which begins with a letter or underscore.
  Keywords of C have no significance to the preprocessor; they are
  ordinary identifiers.  You can define a macro whose name is a keyword,
  for instance.  The only identifier which can be considered a
! preprocessing keyword is 'defined'.  *Note Defined::.
  
     This is mostly true of other languages which use the C preprocessor.
  However, a few of the keywords of C++ are significant even in the
--- 411,441 ----
     When faced with a sequence of characters that has more than one
  possible tokenization, the preprocessor is greedy.  It always makes each
  token, starting from the left, as big as possible before moving on to
! the next token.  For instance, ‘a+++++b’ is interpreted as
! ‘a ++ ++ + b’, not as ‘a ++ + ++ b’, even though the latter tokenization
  could be part of a valid C program and the former could not.
  
     Once the input file is broken into tokens, the token boundaries never
! change, except when the ‘##’ preprocessing operator is used to paste
  tokens together.  *Note Concatenation::.  For example,
  
       #define foo() bar
       foo()baz
!           ↦ bar baz
       _not_
!           ↦ barbaz
  
     The compiler does not re-tokenize the preprocessor's output.  Each
  preprocessing token becomes one compiler token.
  
     Preprocessing tokens fall into five broad classes: identifiers,
  preprocessing numbers, string literals, punctuators, and other.  An
! “identifier” is the same as an identifier in C: any sequence of letters,
  digits, or underscores, which begins with a letter or underscore.
  Keywords of C have no significance to the preprocessor; they are
  ordinary identifiers.  You can define a macro whose name is a keyword,
  for instance.  The only identifier which can be considered a
! preprocessing keyword is ‘defined’.  *Note Defined::.
  
     This is mostly true of other languages which use the C preprocessor.
  However, a few of the keywords of C++ are significant even in the
*************** preprocessor.  *Note C++ Named Operators
*** 445,486 ****
  part of the "basic source character set", at the implementation's
  discretion (such as accented Latin letters, Greek letters, or Chinese
  ideograms).  This may be done with an extended character set, or the
! '\u' and '\U' escape sequences.
  
!    As an extension, GCC treats '$' as a letter.  This is for
! compatibility with some systems, such as VMS, where '$' is commonly used
! in system-defined function and object names.  '$' is not a letter in
! strictly conforming mode, or if you specify the '-$' option.  *Note
  Invocation::.
  
!    A "preprocessing number" has a rather bizarre definition.  The
  category includes all the normal integer and floating point constants
  one expects of C, but also a number of other things one might not
  initially recognize as a number.  Formally, preprocessing numbers begin
  with an optional period, a required decimal digit, and then continue
  with any sequence of letters, digits, underscores, periods, and
! exponents.  Exponents are the two-character sequences 'e+', 'e-', 'E+',
! 'E-', 'p+', 'p-', 'P+', and 'P-'.  (The exponents that begin with 'p' or
! 'P' are used for hexadecimal floating-point constants.)
  
     The purpose of this unusual definition is to isolate the preprocessor
  from the full complexity of numeric constants.  It does not have to
  distinguish between lexically valid and invalid floating-point numbers,
  which is complicated.  The definition also permits you to split an
  identifier at any position and get exactly two tokens, which can then be
! pasted back together with the '##' operator.
  
     It's possible for preprocessing numbers to cause programs to be
! misinterpreted.  For example, '0xE+12' is a preprocessing number which
  does not translate to any valid numeric constant, therefore a syntax
! error.  It does not mean '0xE + 12', which is what you might have
  intended.
  
!    "String literals" are string constants, character constants, and
! header file names (the argument of '#include').(1)  String constants and
  character constants are straightforward: "..." or '...'.  In either case
  embedded quotes should be escaped with a backslash: '\'' is the
! character constant for '''.  There is no limit on the length of a
  character constant, but the value of a character constant that contains
  more than one character is implementation-defined.  *Note Implementation
  Details::.
--- 445,486 ----
  part of the "basic source character set", at the implementation's
  discretion (such as accented Latin letters, Greek letters, or Chinese
  ideograms).  This may be done with an extended character set, or the
! ‘\u’ and ‘\U’ escape sequences.
  
!    As an extension, GCC treats ‘$’ as a letter.  This is for
! compatibility with some systems, such as VMS, where ‘$’ is commonly used
! in system-defined function and object names.  ‘$’ is not a letter in
! strictly conforming mode, or if you specify the ‘-$’ option.  *Note
  Invocation::.
  
!    A “preprocessing number” has a rather bizarre definition.  The
  category includes all the normal integer and floating point constants
  one expects of C, but also a number of other things one might not
  initially recognize as a number.  Formally, preprocessing numbers begin
  with an optional period, a required decimal digit, and then continue
  with any sequence of letters, digits, underscores, periods, and
! exponents.  Exponents are the two-character sequences ‘e+’, ‘e-’, ‘E+’,
! ‘E-’, ‘p+’, ‘p-’, ‘P+’, and ‘P-’.  (The exponents that begin with ‘p’ or
! ‘P’ are used for hexadecimal floating-point constants.)
  
     The purpose of this unusual definition is to isolate the preprocessor
  from the full complexity of numeric constants.  It does not have to
  distinguish between lexically valid and invalid floating-point numbers,
  which is complicated.  The definition also permits you to split an
  identifier at any position and get exactly two tokens, which can then be
! pasted back together with the ‘##’ operator.
  
     It's possible for preprocessing numbers to cause programs to be
! misinterpreted.  For example, ‘0xE+12’ is a preprocessing number which
  does not translate to any valid numeric constant, therefore a syntax
! error.  It does not mean ‘0xE + 12’, which is what you might have
  intended.
  
!    “String literals” are string constants, character constants, and
! header file names (the argument of ‘#include’).(1)  String constants and
  character constants are straightforward: "..." or '...'.  In either case
  embedded quotes should be escaped with a backslash: '\'' is the
! character constant for ‘'’.  There is no limit on the length of a
  character constant, but the value of a character constant that contains
  more than one character is implementation-defined.  *Note Implementation
  Details::.
*************** Operation::.
*** 495,506 ****
     No string literal may extend past the end of a line.  You may use
  continued lines instead, or string constant concatenation.
  
!    "Punctuators" are all the usual bits of punctuation which are
  meaningful to C and C++.  All but three of the punctuation characters in
! ASCII are C punctuators.  The exceptions are '@', '$', and '`'.  In
  addition, all the two- and three-character operators are punctuators.
! There are also six "digraphs", which the C++ standard calls "alternative
! tokens", which are merely alternate ways to spell other punctuators.
  This is a second attempt to work around missing punctuation in obsolete
  systems.  It has no negative side effects, unlike trigraphs, but does
  not cover as much ground.  The digraphs and their corresponding normal
--- 495,506 ----
     No string literal may extend past the end of a line.  You may use
  continued lines instead, or string constant concatenation.
  
!    “Punctuators” are all the usual bits of punctuation which are
  meaningful to C and C++.  All but three of the punctuation characters in
! ASCII are C punctuators.  The exceptions are ‘@’, ‘$’, and ‘`’.  In
  addition, all the two- and three-character operators are punctuators.
! There are also six “digraphs”, which the C++ standard calls “alternative
! tokens”, which are merely alternate ways to spell other punctuators.
  This is a second attempt to work around missing punctuation in obsolete
  systems.  It has no negative side effects, unlike trigraphs, but does
  not cover as much ground.  The digraphs and their corresponding normal
*************** punctuators are:
*** 512,519 ****
     Any other single byte is considered "other" and passed on to the
  preprocessor's output unchanged.  The C compiler will almost certainly
  reject source code containing "other" tokens.  In ASCII, the only
! "other" characters are '@', '$', '`', and control characters other than
! NUL (all bits zero).  (Note that '$' is normally considered a letter.)
  All bytes with the high bit set (numeric range 0x7F-0xFF) that were not
  succesfully interpreted as part of an extended character in the input
  encoding are also "other" in the present implementation.
--- 512,519 ----
     Any other single byte is considered "other" and passed on to the
  preprocessor's output unchanged.  The C compiler will almost certainly
  reject source code containing "other" tokens.  In ASCII, the only
! "other" characters are ‘@’, ‘$’, ‘`’, and control characters other than
! NUL (all bits zero).  (Note that ‘$’ is normally considered a letter.)
  All bytes with the high bit set (numeric range 0x7F-0xFF) that were not
  succesfully interpreted as part of an extended character in the input
  encoding are also "other" in the present implementation.
*************** have the same meaning.
*** 528,541 ****
       #define X^@1
       #define X 1
  
! (where '^@' is ASCII NUL).  Within string or character constants, NULs
  are preserved.  In the latter two cases the preprocessor emits a warning
  message.
  
     ---------- Footnotes ----------
  
!    (1) The C standard uses the term "string literal" to refer only to
! what we are calling "string constants".
  
  
  File: cpp.info,  Node: The preprocessing language,  Prev: Tokenization,  Up: Overview
--- 528,541 ----
       #define X^@1
       #define X 1
  
! (where ‘^@’ is ASCII NUL).  Within string or character constants, NULs
  are preserved.  In the latter two cases the preprocessor emits a warning
  message.
  
     ---------- Footnotes ----------
  
!    (1) The C standard uses the term “string literal” to refer only to
! what we are calling “string constants”.
  
  
  File: cpp.info,  Node: The preprocessing language,  Prev: Tokenization,  Up: Overview
*************** File: cpp.info,  Node: The preprocessing
*** 545,589 ****
  
  After tokenization, the stream of tokens may simply be passed straight
  to the compiler's parser.  However, if it contains any operations in the
! "preprocessing language", it will be transformed first.  This stage
  corresponds roughly to the standard's "translation phase 4" and is what
  most people think of as the preprocessor's job.
  
!    The preprocessing language consists of "directives" to be executed
! and "macros" to be expanded.  Its primary capabilities are:
  
!    * Inclusion of header files.  These are files of declarations that
       can be substituted into your program.
  
!    * Macro expansion.  You can define "macros", which are abbreviations
       for arbitrary fragments of C code.  The preprocessor will replace
       the macros with their definitions throughout the program.  Some
       macros are automatically defined for you.
  
!    * Conditional compilation.  You can include or exclude parts of the
       program according to various conditions.
  
!    * Line control.  If you use a program to combine or rearrange source
       files into an intermediate file which is then compiled, you can use
       line control to inform the compiler where each source line
       originally came from.
  
!    * Diagnostics.  You can detect problems at compile time and issue
       errors or warnings.
  
     There are a few more, less useful, features.
  
     Except for expansion of predefined macros, all these operations are
! triggered with "preprocessing directives".  Preprocessing directives are
! lines in your program that start with '#'.  Whitespace is allowed before
! and after the '#'.  The '#' is followed by an identifier, the "directive
! name".  It specifies the operation to perform.  Directives are commonly
! referred to as '#NAME' where NAME is the directive name.  For example,
! '#define' is the directive that defines a macro.
  
!    The '#' which begins a directive cannot come from a macro expansion.
! Also, the directive name is not macro expanded.  Thus, if 'foo' is
! defined as a macro expanding to 'define', that does not make '#foo' a
  valid preprocessing directive.
  
     The set of valid directive names is fixed.  Programs cannot define
--- 545,589 ----
  
  After tokenization, the stream of tokens may simply be passed straight
  to the compiler's parser.  However, if it contains any operations in the
! “preprocessing language”, it will be transformed first.  This stage
  corresponds roughly to the standard's "translation phase 4" and is what
  most people think of as the preprocessor's job.
  
!    The preprocessing language consists of “directives” to be executed
! and “macros” to be expanded.  Its primary capabilities are:
  
!    • Inclusion of header files.  These are files of declarations that
       can be substituted into your program.
  
!    • Macro expansion.  You can define “macros”, which are abbreviations
       for arbitrary fragments of C code.  The preprocessor will replace
       the macros with their definitions throughout the program.  Some
       macros are automatically defined for you.
  
!    • Conditional compilation.  You can include or exclude parts of the
       program according to various conditions.
  
!    • Line control.  If you use a program to combine or rearrange source
       files into an intermediate file which is then compiled, you can use
       line control to inform the compiler where each source line
       originally came from.
  
!    • Diagnostics.  You can detect problems at compile time and issue
       errors or warnings.
  
     There are a few more, less useful, features.
  
     Except for expansion of predefined macros, all these operations are
! triggered with “preprocessing directives”.  Preprocessing directives are
! lines in your program that start with ‘#’.  Whitespace is allowed before
! and after the ‘#’.  The ‘#’ is followed by an identifier, the “directive
! name”.  It specifies the operation to perform.  Directives are commonly
! referred to as ‘#NAME’ where NAME is the directive name.  For example,
! ‘#define’ is the directive that defines a macro.
  
!    The ‘#’ which begins a directive cannot come from a macro expansion.
! Also, the directive name is not macro expanded.  Thus, if ‘foo’ is
! defined as a macro expanding to ‘define’, that does not make ‘#foo’ a
  valid preprocessing directive.
  
     The set of valid directive names is fixed.  Programs cannot define
*************** new preprocessing directives.
*** 591,597 ****
  
     Some directives require arguments; these make up the rest of the
  directive line and must be separated from the directive name by
! whitespace.  For example, '#define' must be followed by a macro name and
  the intended expansion of the macro.
  
     A preprocessing directive cannot cover more than one line.  The line
--- 591,597 ----
  
     Some directives require arguments; these make up the rest of the
  directive line and must be separated from the directive name by
! whitespace.  For example, ‘#define’ must be followed by a macro name and
  the intended expansion of the macro.
  
     A preprocessing directive cannot cover more than one line.  The line
*************** File: cpp.info,  Node: Header Files,  Ne
*** 608,624 ****
  
  A header file is a file containing C declarations and macro definitions
  (*note Macros::) to be shared between several source files.  You request
! the use of a header file in your program by "including" it, with the C
! preprocessing directive '#include'.
  
     Header files serve two purposes.
  
!    * System header files declare the interfaces to parts of the
       operating system.  You include them in your program to supply the
       definitions and declarations you need to invoke system calls and
       libraries.
  
!    * Your own header files contain declarations for interfaces between
       the source files of your program.  Each time you have a group of
       related declarations and macro definitions all or most of which are
       needed in several different source files, it is a good idea to
--- 608,624 ----
  
  A header file is a file containing C declarations and macro definitions
  (*note Macros::) to be shared between several source files.  You request
! the use of a header file in your program by “including” it, with the C
! preprocessing directive ‘#include’.
  
     Header files serve two purposes.
  
!    • System header files declare the interfaces to parts of the
       operating system.  You include them in your program to supply the
       definitions and declarations you need to invoke system calls and
       libraries.
  
!    • Your own header files contain declarations for interfaces between
       the source files of your program.  Each time you have a group of
       related declarations and macro definitions all or most of which are
       needed in several different source files, it is a good idea to
*************** as the risk that a failure to find one c
*** 635,641 ****
  inconsistencies within a program.
  
     In C, the usual convention is to give header files names that end
! with '.h'.  It is most portable to use only letters, digits, dashes, and
  underscores in header file names, and at most one dot.
  
  * Menu:
--- 635,641 ----
  inconsistencies within a program.
  
     In C, the usual convention is to give header files names that end
! with ‘.h’.  It is most portable to use only letters, digits, dashes, and
  underscores in header file names, and at most one dot.
  
  * Menu:
*************** File: cpp.info,  Node: Include Syntax,
*** 656,688 ****
  ==================
  
  Both user and system header files are included using the preprocessing
! directive '#include'.  It has two variants:
  
! '#include '
       This variant is used for system header files.  It searches for a
       file named FILE in a standard list of system directories.  You can
!      prepend directories to this list with the '-I' option (*note
       Invocation::).
  
! '#include "FILE"'
       This variant is used for header files of your own program.  It
       searches for a file named FILE first in the directory containing
       the current file, then in the quote directories and then the same
!      directories used for ''.  You can prepend directories to the
!      list of quote directories with the '-iquote' option.
  
!    The argument of '#include', whether delimited with quote marks or
  angle brackets, behaves like a string constant in that comments are not
! recognized, and macro names are not expanded.  Thus, '#include '
! specifies inclusion of a system header file named 'x/*y'.
  
     However, if backslashes occur within FILE, they are considered
  ordinary text characters, not escape characters.  None of the character
  escape sequences appropriate to string constants in C are processed.
! Thus, '#include "x\n\\y"' specifies a filename containing three
! backslashes.  (Some systems interpret '\' as a pathname separator.  All
! of these also interpret '/' the same way.  It is most portable to use
! only '/'.)
  
     It is an error if there is anything (other than comments) on the line
  after the file name.
--- 656,688 ----
  ==================
  
  Both user and system header files are included using the preprocessing
! directive ‘#include’.  It has two variants:
  
! ‘#include ’
       This variant is used for system header files.  It searches for a
       file named FILE in a standard list of system directories.  You can
!      prepend directories to this list with the ‘-I’ option (*note
       Invocation::).
  
! ‘#include "FILE"’
       This variant is used for header files of your own program.  It
       searches for a file named FILE first in the directory containing
       the current file, then in the quote directories and then the same
!      directories used for ‘’.  You can prepend directories to the
!      list of quote directories with the ‘-iquote’ option.
  
!    The argument of ‘#include’, whether delimited with quote marks or
  angle brackets, behaves like a string constant in that comments are not
! recognized, and macro names are not expanded.  Thus, ‘#include ’
! specifies inclusion of a system header file named ‘x/*y’.
  
     However, if backslashes occur within FILE, they are considered
  ordinary text characters, not escape characters.  None of the character
  escape sequences appropriate to string constants in C are processed.
! Thus, ‘#include "x\n\\y"’ specifies a filename containing three
! backslashes.  (Some systems interpret ‘\’ as a pathname separator.  All
! of these also interpret ‘/’ the same way.  It is most portable to use
! only ‘/’.)
  
     It is an error if there is anything (other than comments) on the line
  after the file name.
*************** File: cpp.info,  Node: Include Operation
*** 693,709 ****
  2.2 Include Operation
  =====================
  
! The '#include' directive works by directing the C preprocessor to scan
  the specified file as input before continuing with the rest of the
  current file.  The output from the preprocessor contains the output
  already generated, followed by the output resulting from the included
  file, followed by the output that comes from the text after the
! '#include' directive.  For example, if you have a header file 'header.h'
  as follows,
  
       char *test (void);
  
! and a main program called 'program.c' that uses the header file, like
  this,
  
       int x;
--- 693,709 ----
  2.2 Include Operation
  =====================
  
! The ‘#include’ directive works by directing the C preprocessor to scan
  the specified file as input before continuing with the rest of the
  current file.  The output from the preprocessor contains the output
  already generated, followed by the output resulting from the included
  file, followed by the output that comes from the text after the
! ‘#include’ directive.  For example, if you have a header file ‘header.h’
  as follows,
  
       char *test (void);
  
! and a main program called ‘program.c’ that uses the header file, like
  this,
  
       int x;
*************** this,
*** 715,721 ****
         puts (test ());
       }
  
! the compiler will see the same token stream as it would if 'program.c'
  read
  
       int x;
--- 715,721 ----
         puts (test ());
       }
  
! the compiler will see the same token stream as it would if ‘program.c’
  read
  
       int x;
*************** the file.
*** 741,747 ****
  syntactic units--function declarations or definitions, type
  declarations, etc.
  
!    The line following the '#include' directive is always treated as a
  separate line by the C preprocessor, even if the included file lacks a
  final newline.
  
--- 741,747 ----
  syntactic units--function declarations or definitions, type
  declarations, etc.
  
!    The line following the ‘#include’ directive is always treated as a
  separate line by the C preprocessor, even if the included file lacks a
  final newline.
  
*************** File: cpp.info,  Node: Search Path,  Nex
*** 752,793 ****
  ===============
  
  By default, the preprocessor looks for header files included by the
! quote form of the directive '#include "FILE"' first relative to the
  directory of the current file, and then in a preconfigured list of
! standard system directories.  For example, if '/usr/include/sys/stat.h'
! contains '#include "types.h"', GCC looks for 'types.h' first in
! '/usr/include/sys', then in its usual search path.
  
!    For the angle-bracket form '#include ', the preprocessor's
  default behavior is to look only in the standard system directories.
  The exact search directory list depends on the target system, how GCC is
  configured, and where it is installed.  You can find the default search
! directory list for your version of CPP by invoking it with the '-v'
  option.  For example,
  
       cpp -v /dev/null -o /dev/null
  
     There are a number of command-line options you can use to add
  additional directories to the search path.  The most commonly-used
! option is '-IDIR', which causes DIR to be searched after the current
  directory (for the quote form of the directive) and ahead of the
! standard system directories.  You can specify multiple '-I' options on
  the command line, in which case the directories are searched in
  left-to-right order.
  
     If you need separate control over the search paths for the quote and
! angle-bracket forms of the '#include' directive, you can use the
! '-iquote' and/or '-isystem' options instead of '-I'.  *Note
  Invocation::, for a detailed description of these options, as well as
  others that are less generally useful.
  
!    If you specify other options on the command line, such as '-I', that
  affect where the preprocessor searches for header files, the directory
! list printed by the '-v' option reflects the actual search path used by
  the preprocessor.
  
     Note that you can also prevent the preprocessor from searching any of
! the default system header directories with the '-nostdinc' option.  This
  is useful when you are compiling an operating system kernel or some
  other program that does not use the standard C library facilities, or
  the standard C library itself.
--- 752,793 ----
  ===============
  
  By default, the preprocessor looks for header files included by the
! quote form of the directive ‘#include "FILE"’ first relative to the
  directory of the current file, and then in a preconfigured list of
! standard system directories.  For example, if ‘/usr/include/sys/stat.h’
! contains ‘#include "types.h"’, GCC looks for ‘types.h’ first in
! ‘/usr/include/sys’, then in its usual search path.
  
!    For the angle-bracket form ‘#include ’, the preprocessor's
  default behavior is to look only in the standard system directories.
  The exact search directory list depends on the target system, how GCC is
  configured, and where it is installed.  You can find the default search
! directory list for your version of CPP by invoking it with the ‘-v’
  option.  For example,
  
       cpp -v /dev/null -o /dev/null
  
     There are a number of command-line options you can use to add
  additional directories to the search path.  The most commonly-used
! option is ‘-IDIR’, which causes DIR to be searched after the current
  directory (for the quote form of the directive) and ahead of the
! standard system directories.  You can specify multiple ‘-I’ options on
  the command line, in which case the directories are searched in
  left-to-right order.
  
     If you need separate control over the search paths for the quote and
! angle-bracket forms of the ‘#include’ directive, you can use the
! ‘-iquote’ and/or ‘-isystem’ options instead of ‘-I’.  *Note
  Invocation::, for a detailed description of these options, as well as
  others that are less generally useful.
  
!    If you specify other options on the command line, such as ‘-I’, that
  affect where the preprocessor searches for header files, the directory
! list printed by the ‘-v’ option reflects the actual search path used by
  the preprocessor.
  
     Note that you can also prevent the preprocessor from searching any of
! the default system header directories with the ‘-nostdinc’ option.  This
  is useful when you are compiling an operating system kernel or some
  other program that does not use the standard C library facilities, or
  the standard C library itself.
*************** contents of the file in a conditional, l
*** 814,835 ****
  
       #endif /* !FILE_FOO_SEEN */
  
!    This construct is commonly known as a "wrapper #ifndef".  When the
  header is included again, the conditional will be false, because
! 'FILE_FOO_SEEN' is defined.  The preprocessor will skip over the entire
  contents of the file, and the compiler will not see it twice.
  
     CPP optimizes even further.  It remembers when a header file has a
! wrapper '#ifndef'.  If a subsequent '#include' specifies that header,
! and the macro in the '#ifndef' is still defined, it does not bother to
  rescan the file at all.
  
     You can put comments outside the wrapper.  They will not interfere
  with this optimization.
  
!    The macro 'FILE_FOO_SEEN' is called the "controlling macro" or "guard
! macro".  In a user header file, the macro name should not begin with
! '_'.  In a system header file, it should begin with '__' to avoid
  conflicts with user programs.  In any kind of header file, the macro
  name should contain the name of the file and some additional text, to
  avoid conflicts with other header files.
--- 814,835 ----
  
       #endif /* !FILE_FOO_SEEN */
  
!    This construct is commonly known as a “wrapper #ifndef”.  When the
  header is included again, the conditional will be false, because
! ‘FILE_FOO_SEEN’ is defined.  The preprocessor will skip over the entire
  contents of the file, and the compiler will not see it twice.
  
     CPP optimizes even further.  It remembers when a header file has a
! wrapper ‘#ifndef’.  If a subsequent ‘#include’ specifies that header,
! and the macro in the ‘#ifndef’ is still defined, it does not bother to
  rescan the file at all.
  
     You can put comments outside the wrapper.  They will not interfere
  with this optimization.
  
!    The macro ‘FILE_FOO_SEEN’ is called the “controlling macro” or “guard
! macro”.  In a user header file, the macro name should not begin with
! ‘_’.  In a system header file, it should begin with ‘__’ to avoid
  conflicts with user programs.  In any kind of header file, the macro
  name should contain the name of the file and some additional text, to
  avoid conflicts with other header files.
*************** File: cpp.info,  Node: Alternatives to W
*** 841,870 ****
  ===================================
  
  CPP supports two more ways of indicating that a header file should be
! read only once.  Neither one is as portable as a wrapper '#ifndef' and
  we recommend you do not use them in new programs, with the caveat that
! '#import' is standard practice in Objective-C.
  
!    CPP supports a variant of '#include' called '#import' which includes
! a file, but does so at most once.  If you use '#import' instead of
! '#include', then you don't need the conditionals inside the header file
! to prevent multiple inclusion of the contents.  '#import' is standard in
  Objective-C, but is considered a deprecated extension in C and C++.
  
!    '#import' is not a well designed feature.  It requires the users of a
  header file to know that it should only be included once.  It is much
  better for the header file's implementor to write the file so that users
! don't need to know this.  Using a wrapper '#ifndef' accomplishes this
  goal.
  
!    In the present implementation, a single use of '#import' will prevent
! the file from ever being read again, by either '#import' or '#include'.
! You should not rely on this; do not use both '#import' and '#include' to
  refer to the same header file.
  
     Another way to prevent a header file from being included more than
! once is with the '#pragma once' directive (*note Pragmas::).  '#pragma
! once' does not have the problems that '#import' does, but it is not
  recognized by all preprocessors, so you cannot rely on it in a portable
  program.
  
--- 841,870 ----
  ===================================
  
  CPP supports two more ways of indicating that a header file should be
! read only once.  Neither one is as portable as a wrapper ‘#ifndef’ and
  we recommend you do not use them in new programs, with the caveat that
! ‘#import’ is standard practice in Objective-C.
  
!    CPP supports a variant of ‘#include’ called ‘#import’ which includes
! a file, but does so at most once.  If you use ‘#import’ instead of
! ‘#include’, then you don't need the conditionals inside the header file
! to prevent multiple inclusion of the contents.  ‘#import’ is standard in
  Objective-C, but is considered a deprecated extension in C and C++.
  
!    ‘#import’ is not a well designed feature.  It requires the users of a
  header file to know that it should only be included once.  It is much
  better for the header file's implementor to write the file so that users
! don't need to know this.  Using a wrapper ‘#ifndef’ accomplishes this
  goal.
  
!    In the present implementation, a single use of ‘#import’ will prevent
! the file from ever being read again, by either ‘#import’ or ‘#include’.
! You should not rely on this; do not use both ‘#import’ and ‘#include’ to
  refer to the same header file.
  
     Another way to prevent a header file from being included more than
! once is with the ‘#pragma once’ directive (*note Pragmas::).  ‘#pragma
! once’ does not have the problems that ‘#import’ does, but it is not
  recognized by all preprocessors, so you cannot rely on it in a portable
  program.
  
*************** systems, for instance.  You could do thi
*** 888,915 ****
       #endif
  
     That rapidly becomes tedious.  Instead, the preprocessor offers the
! ability to use a macro for the header name.  This is called a "computed
! include".  Instead of writing a header name as the direct argument of
! '#include', you simply put a macro name there instead:
  
       #define SYSTEM_H "system_1.h"
       ...
       #include SYSTEM_H
  
! 'SYSTEM_H' will be expanded, and the preprocessor will look for
! 'system_1.h' as if the '#include' had been written that way originally.
! 'SYSTEM_H' could be defined by your Makefile with a '-D' option.
  
!    You must be careful when you define the macro.  '#define' saves
  tokens, not text.  The preprocessor has no way of knowing that the macro
! will be used as the argument of '#include', so it generates ordinary
  tokens, not a header name.  This is unlikely to cause problems if you
  use double-quote includes, which are close enough to string constants.
  If you use angle brackets, however, you may have trouble.
  
     The syntax of a computed include is actually a bit more general than
! the above.  If the first non-whitespace character after '#include' is
! not '"' or '<', then the entire line is macro-expanded like running text
  would be.
  
     If the line expands to a single string constant, the contents of that
--- 888,915 ----
       #endif
  
     That rapidly becomes tedious.  Instead, the preprocessor offers the
! ability to use a macro for the header name.  This is called a “computed
! include”.  Instead of writing a header name as the direct argument of
! ‘#include’, you simply put a macro name there instead:
  
       #define SYSTEM_H "system_1.h"
       ...
       #include SYSTEM_H
  
! ‘SYSTEM_H’ will be expanded, and the preprocessor will look for
! ‘system_1.h’ as if the ‘#include’ had been written that way originally.
! ‘SYSTEM_H’ could be defined by your Makefile with a ‘-D’ option.
  
!    You must be careful when you define the macro.  ‘#define’ saves
  tokens, not text.  The preprocessor has no way of knowing that the macro
! will be used as the argument of ‘#include’, so it generates ordinary
  tokens, not a header name.  This is unlikely to cause problems if you
  use double-quote includes, which are close enough to string constants.
  If you use angle brackets, however, you may have trouble.
  
     The syntax of a computed include is actually a bit more general than
! the above.  If the first non-whitespace character after ‘#include’ is
! not ‘"’ or ‘<’, then the entire line is macro-expanded like running text
  would be.
  
     If the line expands to a single string constant, the contents of that
*************** escapes in the string.  Therefore
*** 920,933 ****
       #define HEADER "a\"b"
       #include HEADER
  
! looks for a file named 'a\"b'.  CPP searches for the file according to
  the rules for double-quoted includes.
  
!    If the line expands to a token stream beginning with a '<' token and
! including a '>' token, then the tokens between the '<' and the first '>'
  are combined to form the filename to be included.  Any whitespace
  between tokens is reduced to a single space; then any space after the
! initial '<' is retained, but a trailing space before the closing '>' is
  ignored.  CPP searches for the file according to the rules for
  angle-bracket includes.
  
--- 920,933 ----
       #define HEADER "a\"b"
       #include HEADER
  
! looks for a file named ‘a\"b’.  CPP searches for the file according to
  the rules for double-quoted includes.
  
!    If the line expands to a token stream beginning with a ‘<’ token and
! including a ‘>’ token, then the tokens between the ‘<’ and the first ‘>’
  are combined to form the filename to be included.  Any whitespace
  between tokens is reduced to a single space; then any space after the
! initial ‘<’ is retained, but a trailing space before the closing ‘>’ is
  ignored.  CPP searches for the file according to the rules for
  angle-bracket includes.
  
*************** File: cpp.info,  Node: Wrapper Headers,
*** 949,962 ****
  ===================
  
  Sometimes it is necessary to adjust the contents of a system-provided
! header file without editing it directly.  GCC's 'fixincludes' operation
  does this, for example.  One way to do that would be to create a new
  header file with the same name and insert it in the search path before
  the original header.  That works fine as long as you're willing to
  replace the old header entirely.  But what if you want to refer to the
  old header from the new one?
  
!    You cannot simply include the old header with '#include'.  That will
  start from the beginning, and find your new header again.  If your
  header is not protected from multiple inclusion (*note Once-Only
  Headers::), it will recurse infinitely and cause a fatal error.
--- 949,962 ----
  ===================
  
  Sometimes it is necessary to adjust the contents of a system-provided
! header file without editing it directly.  GCC's ‘fixincludes’ operation
  does this, for example.  One way to do that would be to create a new
  header file with the same name and insert it in the search path before
  the original header.  That works fine as long as you're willing to
  replace the old header entirely.  But what if you want to refer to the
  old header from the new one?
  
!    You cannot simply include the old header with ‘#include’.  That will
  start from the beginning, and find your new header again.  If your
  header is not protected from multiple inclusion (*note Once-Only
  Headers::), it will recurse infinitely and cause a fatal error.
*************** This works, but is not clean; should the
*** 967,996 ****
  would have to edit the new headers to match.
  
     There is no way to solve this problem within the C standard, but you
! can use the GNU extension '#include_next'.  It means, "Include the
! _next_ file with this name".  This directive works like '#include'
  except in searching for the specified file: it starts searching the list
  of header file directories _after_ the directory in which the current
  file was found.
  
!    Suppose you specify '-I /usr/local/include', and the list of
! directories to search also includes '/usr/include'; and suppose both
! directories contain 'signal.h'.  Ordinary '#include ' finds
! the file under '/usr/local/include'.  If that file contains
! '#include_next ', it starts searching after that directory,
! and finds the file in '/usr/include'.
  
!    '#include_next' does not distinguish between '' and '"FILE"'
  inclusion, nor does it check that the file you specify has the same name
  as the current file.  It simply looks for the file named, starting with
  the directory in the search path after the one where the current file
  was found.
  
!    The use of '#include_next' can lead to great confusion.  We recommend
  it be used only when there is no other alternative.  In particular, it
  should not be used in the headers belonging to a specific program; it
  should be used only to make global corrections along the lines of
! 'fixincludes'.
  
  
  File: cpp.info,  Node: System Headers,  Prev: Wrapper Headers,  Up: Header Files
--- 967,996 ----
  would have to edit the new headers to match.
  
     There is no way to solve this problem within the C standard, but you
! can use the GNU extension ‘#include_next’.  It means, "Include the
! _next_ file with this name".  This directive works like ‘#include’
  except in searching for the specified file: it starts searching the list
  of header file directories _after_ the directory in which the current
  file was found.
  
!    Suppose you specify ‘-I /usr/local/include’, and the list of
! directories to search also includes ‘/usr/include’; and suppose both
! directories contain ‘signal.h’.  Ordinary ‘#include ’ finds
! the file under ‘/usr/local/include’.  If that file contains
! ‘#include_next ’, it starts searching after that directory,
! and finds the file in ‘/usr/include’.
  
!    ‘#include_next’ does not distinguish between ‘’ and ‘"FILE"’
  inclusion, nor does it check that the file you specify has the same name
  as the current file.  It simply looks for the file named, starting with
  the directory in the search path after the one where the current file
  was found.
  
!    The use of ‘#include_next’ can lead to great confusion.  We recommend
  it be used only when there is no other alternative.  In particular, it
  should not be used in the headers belonging to a specific program; it
  should be used only to make global corrections along the lines of
! ‘fixincludes’.
  
  
  File: cpp.info,  Node: System Headers,  Prev: Wrapper Headers,  Up: Header Files
*************** File: cpp.info,  Node: System Headers,
*** 1000,1007 ****
  
  The header files declaring interfaces to the operating system and
  runtime libraries often cannot be written in strictly conforming C.
! Therefore, GCC gives code found in "system headers" special treatment.
! All warnings, other than those generated by '#warning' (*note
  Diagnostics::), are suppressed while GCC is processing a system header.
  Macros defined in a system header are immune to a few warnings wherever
  they are expanded.  This immunity is granted on an ad-hoc basis, when we
--- 1000,1007 ----
  
  The header files declaring interfaces to the operating system and
  runtime libraries often cannot be written in strictly conforming C.
! Therefore, GCC gives code found in “system headers” special treatment.
! All warnings, other than those generated by ‘#warning’ (*note
  Diagnostics::), are suppressed while GCC is processing a system header.
  Macros defined in a system header are immune to a few warnings wherever
  they are expanded.  This immunity is granted on an ad-hoc basis, when we
*************** considered system headers.  These direct
*** 1013,1030 ****
  compiled.  There are, however, two ways to make normal headers into
  system headers:
  
!    * Header files found in directories added to the search path with the
!      '-isystem' and '-idirafter' command-line options are treated as
       system headers for the purposes of diagnostics.
  
!    * There is also a directive, '#pragma GCC system_header', which tells
       GCC to consider the rest of the current include file a system
       header, no matter where it was found.  Code that comes before the
!      '#pragma' in the file is not affected.  '#pragma GCC system_header'
       has no effect in the primary source file.
  
     On some targets, such as RS/6000 AIX, GCC implicitly surrounds all
! system headers with an 'extern "C"' block when compiling as C++.
  
  
  File: cpp.info,  Node: Macros,  Next: Conditionals,  Prev: Header Files,  Up: Top
--- 1013,1030 ----
  compiled.  There are, however, two ways to make normal headers into
  system headers:
  
!    • Header files found in directories added to the search path with the
!      ‘-isystem’ and ‘-idirafter’ command-line options are treated as
       system headers for the purposes of diagnostics.
  
!    • There is also a directive, ‘#pragma GCC system_header’, which tells
       GCC to consider the rest of the current include file a system
       header, no matter where it was found.  Code that comes before the
!      ‘#pragma’ in the file is not affected.  ‘#pragma GCC system_header’
       has no effect in the primary source file.
  
     On some targets, such as RS/6000 AIX, GCC implicitly surrounds all
! system headers with an ‘extern "C"’ block when compiling as C++.
  
  
  File: cpp.info,  Node: Macros,  Next: Conditionals,  Prev: Header Files,  Up: Top
*************** File: cpp.info,  Node: Macros,  Next: Co
*** 1032,1048 ****
  3 Macros
  ********
  
! A "macro" is a fragment of code which has been given a name.  Whenever
  the name is used, it is replaced by the contents of the macro.  There
  are two kinds of macros.  They differ mostly in what they look like when
! they are used.  "Object-like" macros resemble data objects when used,
! "function-like" macros resemble function calls.
  
     You may define any valid identifier as a macro, even if it is a C
  keyword.  The preprocessor does not know anything about keywords.  This
! can be useful if you wish to hide a keyword such as 'const' from an
  older compiler that does not understand it.  However, the preprocessor
! operator 'defined' (*note Defined::) can never be defined as a macro,
  and C++'s named operators (*note C++ Named Operators::) cannot be macros
  when you are compiling C++.
  
--- 1032,1048 ----
  3 Macros
  ********
  
! A “macro” is a fragment of code which has been given a name.  Whenever
  the name is used, it is replaced by the contents of the macro.  There
  are two kinds of macros.  They differ mostly in what they look like when
! they are used.  “Object-like” macros resemble data objects when used,
! “function-like” macros resemble function calls.
  
     You may define any valid identifier as a macro, even if it is a C
  keyword.  The preprocessor does not know anything about keywords.  This
! can be useful if you wish to hide a keyword such as ‘const’ from an
  older compiler that does not understand it.  However, the preprocessor
! operator ‘defined’ (*note Defined::) can never be defined as a macro,
  and C++'s named operators (*note C++ Named Operators::) cannot be macros
  when you are compiling C++.
  
*************** File: cpp.info,  Node: Object-like Macro
*** 1065,1090 ****
  3.1 Object-like Macros
  ======================
  
! An "object-like macro" is a simple identifier which will be replaced by
  a code fragment.  It is called object-like because it looks like a data
  object in code that uses it.  They are most commonly used to give
  symbolic names to numeric constants.
  
!    You create macros with the '#define' directive.  '#define' is
  followed by the name of the macro and then the token sequence it should
  be an abbreviation for, which is variously referred to as the macro's
! "body", "expansion" or "replacement list".  For example,
  
       #define BUFFER_SIZE 1024
  
! defines a macro named 'BUFFER_SIZE' as an abbreviation for the token
! '1024'.  If somewhere after this '#define' directive there comes a C
  statement of the form
  
       foo = (char *) malloc (BUFFER_SIZE);
  
! then the C preprocessor will recognize and "expand" the macro
! 'BUFFER_SIZE'.  The C compiler will see the same tokens as it would if
  you had written
  
       foo = (char *) malloc (1024);
--- 1065,1090 ----
  3.1 Object-like Macros
  ======================
  
! An “object-like macro” is a simple identifier which will be replaced by
  a code fragment.  It is called object-like because it looks like a data
  object in code that uses it.  They are most commonly used to give
  symbolic names to numeric constants.
  
!    You create macros with the ‘#define’ directive.  ‘#define’ is
  followed by the name of the macro and then the token sequence it should
  be an abbreviation for, which is variously referred to as the macro's
! “body”, “expansion” or “replacement list”.  For example,
  
       #define BUFFER_SIZE 1024
  
! defines a macro named ‘BUFFER_SIZE’ as an abbreviation for the token
! ‘1024’.  If somewhere after this ‘#define’ directive there comes a C
  statement of the form
  
       foo = (char *) malloc (BUFFER_SIZE);
  
! then the C preprocessor will recognize and “expand” the macro
! ‘BUFFER_SIZE’.  The C compiler will see the same tokens as it would if
  you had written
  
       foo = (char *) malloc (1024);
*************** you had written
*** 1093,1099 ****
  easier to read when it is possible to tell at a glance which names are
  macros.
  
!    The macro's body ends at the end of the '#define' line.  You may
  continue the definition onto multiple lines, if necessary, using
  backslash-newline.  When the macro is expanded, however, it will all
  come out on one line.  For example,
--- 1093,1099 ----
  easier to read when it is possible to tell at a glance which names are
  macros.
  
!    The macro's body ends at the end of the ‘#define’ line.  You may
  continue the definition onto multiple lines, if necessary, using
  backslash-newline.  When the macro is expanded, however, it will all
  come out on one line.  For example,
*************** come out on one line.  For example,
*** 1102,1108 ****
                       2, \
                       3
       int x[] = { NUMBERS };
!           ==> int x[] = { 1, 2, 3 };
  
  The most common visible consequence of this is surprising line numbers
  in error messages.
--- 1102,1108 ----
                       2, \
                       3
       int x[] = { NUMBERS };
!           ↦ int x[] = { 1, 2, 3 };
  
  The most common visible consequence of this is surprising line numbers
  in error messages.
*************** macros to expand.  For example,
*** 1132,1152 ****
       #define TABLESIZE BUFSIZE
       #define BUFSIZE 1024
       TABLESIZE
!           ==> BUFSIZE
!           ==> 1024
  
! 'TABLESIZE' is expanded first to produce 'BUFSIZE', then that macro is
! expanded to produce the final result, '1024'.
  
!    Notice that 'BUFSIZE' was not defined when 'TABLESIZE' was defined.
! The '#define' for 'TABLESIZE' uses exactly the expansion you specify--in
! this case, 'BUFSIZE'--and does not check to see whether it too contains
! macro names.  Only when you _use_ 'TABLESIZE' is the result of its
  expansion scanned for more macro names.
  
!    This makes a difference if you change the definition of 'BUFSIZE' at
! some point in the source file.  'TABLESIZE', defined as shown, will
! always expand using the definition of 'BUFSIZE' that is currently in
  effect:
  
       #define BUFSIZE 1020
--- 1132,1152 ----
       #define TABLESIZE BUFSIZE
       #define BUFSIZE 1024
       TABLESIZE
!           ↦ BUFSIZE
!           ↦ 1024
  
! ‘TABLESIZE’ is expanded first to produce ‘BUFSIZE’, then that macro is
! expanded to produce the final result, ‘1024’.
  
!    Notice that ‘BUFSIZE’ was not defined when ‘TABLESIZE’ was defined.
! The ‘#define’ for ‘TABLESIZE’ uses exactly the expansion you specify--in
! this case, ‘BUFSIZE’--and does not check to see whether it too contains
! macro names.  Only when you _use_ ‘TABLESIZE’ is the result of its
  expansion scanned for more macro names.
  
!    This makes a difference if you change the definition of ‘BUFSIZE’ at
! some point in the source file.  ‘TABLESIZE’, defined as shown, will
! always expand using the definition of ‘BUFSIZE’ that is currently in
  effect:
  
       #define BUFSIZE 1020
*************** effect:
*** 1154,1160 ****
       #undef BUFSIZE
       #define BUFSIZE 37
  
! Now 'TABLESIZE' expands (in two stages) to '37'.
  
     If the expansion of a macro contains its own name, either directly or
  via intermediate macros, it is not expanded again when the expansion is
--- 1154,1160 ----
       #undef BUFSIZE
       #define BUFSIZE 37
  
! Now ‘TABLESIZE’ expands (in two stages) to ‘37’.
  
     If the expansion of a macro contains its own name, either directly or
  via intermediate macros, it is not expanded again when the expansion is
*************** File: cpp.info,  Node: Function-like Mac
*** 1168,1180 ****
  ========================
  
  You can also define macros whose use looks like a function call.  These
! are called "function-like macros".  To define a function-like macro, you
! use the same '#define' directive, but you put a pair of parentheses
  immediately after the macro name.  For example,
  
       #define lang_init()  c_init()
       lang_init()
!           ==> c_init()
  
     A function-like macro is only expanded if its name appears with a
  pair of parentheses after it.  If you write just the name, it is left
--- 1168,1180 ----
  ========================
  
  You can also define macros whose use looks like a function call.  These
! are called “function-like macros”.  To define a function-like macro, you
! use the same ‘#define’ directive, but you put a pair of parentheses
  immediately after the macro name.  For example,
  
       #define lang_init()  c_init()
       lang_init()
!           ↦ c_init()
  
     A function-like macro is only expanded if its name appears with a
  pair of parentheses after it.  If you write just the name, it is left
*************** same name, and you wish to use the funct
*** 1187,1193 ****
         foo();
         funcptr = foo;
  
!    Here the call to 'foo()' will use the macro, but the function pointer
  will get the address of the real function.  If the macro were to be
  expanded, it would cause a syntax error.
  
--- 1187,1193 ----
         foo();
         funcptr = foo;
  
!    Here the call to ‘foo()’ will use the macro, but the function pointer
  will get the address of the real function.  If the macro were to be
  expanded, it would cause a syntax error.
  
*************** parentheses.
*** 1198,1208 ****
  
       #define lang_init ()    c_init()
       lang_init()
!           ==> () c_init()()
  
     The first two pairs of parentheses in this expansion come from the
  macro.  The third is the pair that was originally after the macro
! invocation.  Since 'lang_init' is an object-like macro, it does not
  consume those parentheses.
  
  
--- 1198,1208 ----
  
       #define lang_init ()    c_init()
       lang_init()
!           ↦ () c_init()()
  
     The first two pairs of parentheses in this expansion come from the
  macro.  The third is the pair that was originally after the macro
! invocation.  Since ‘lang_init’ is an object-like macro, it does not
  consume those parentheses.
  
  
*************** File: cpp.info,  Node: Macro Arguments,
*** 1211,1224 ****
  3.3 Macro Arguments
  ===================
  
! Function-like macros can take "arguments", just like true functions.  To
! define a macro that uses arguments, you insert "parameters" between the
  pair of parentheses in the macro definition that make the macro
  function-like.  The parameters must be valid C identifiers, separated by
  commas and optionally whitespace.
  
     To invoke a macro that takes arguments, you write the name of the
! macro followed by a list of "actual arguments" in parentheses, separated
  by commas.  The invocation of the macro need not be restricted to a
  single logical line--it can cross as many lines in the source file as
  you wish.  The number of arguments you give must match the number of
--- 1211,1224 ----
  3.3 Macro Arguments
  ===================
  
! Function-like macros can take “arguments”, just like true functions.  To
! define a macro that uses arguments, you insert “parameters” between the
  pair of parentheses in the macro definition that make the macro
  function-like.  The parameters must be valid C identifiers, separated by
  commas and optionally whitespace.
  
     To invoke a macro that takes arguments, you write the name of the
! macro followed by a list of “actual arguments” in parentheses, separated
  by commas.  The invocation of the macro need not be restricted to a
  single logical line--it can cross as many lines in the source file as
  you wish.  The number of arguments you give must match the number of
*************** macro body.)
*** 1231,1239 ****
  numeric values, as it is defined in many C programs, and some uses.
  
       #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
!        x = min(a, b);          ==>  x = ((a) < (b) ? (a) : (b));
!        y = min(1, 2);          ==>  y = ((1) < (2) ? (1) : (2));
!        z = min(a + 28, *p);    ==>  z = ((a + 28) < (*p) ? (a + 28) : (*p));
  
  (In this small example you can already see several of the dangers of
  macro arguments.  *Note Macro Pitfalls::, for detailed explanations.)
--- 1231,1239 ----
  numeric values, as it is defined in many C programs, and some uses.
  
       #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
!        x = min(a, b);          ↦  x = ((a) < (b) ? (a) : (b));
!        y = min(1, 2);          ↦  y = ((1) < (2) ? (1) : (2));
!        z = min(a + 28, *p);    ↦  z = ((a + 28) < (*p) ? (a + 28) : (*p));
  
  (In this small example you can already see several of the dangers of
  macro arguments.  *Note Macro Pitfalls::, for detailed explanations.)
*************** prevent a comma from separating argument
*** 1247,1255 ****
  
       macro (array[x = y, x + 1])
  
! passes two arguments to 'macro': 'array[x = y' and 'x + 1]'.  If you
! want to supply 'array[x = y, x + 1]' as an argument, you can write it as
! 'array[(x = y, x + 1)]', which is equivalent C code.
  
     All arguments to a macro are completely macro-expanded before they
  are substituted into the macro body.  After substitution, the complete
--- 1247,1255 ----
  
       macro (array[x = y, x + 1])
  
! passes two arguments to ‘macro’: ‘array[x = y’ and ‘x + 1]’.  If you
! want to supply ‘array[x = y, x + 1]’ as an argument, you can write it as
! ‘array[(x = y, x + 1)]’, which is equivalent C code.
  
     All arguments to a macro are completely macro-expanded before they
  are substituted into the macro body.  After substitution, the complete
*************** worry about whether any function call is
*** 1259,1265 ****
  You can run into trouble if you try to be too clever, though.  *Note
  Argument Prescan::, for detailed discussion.
  
!    For example, 'min (min (a, b), c)' is first expanded to
  
         min (((a) < (b) ? (a) : (b)), (c))
  
--- 1259,1265 ----
  You can run into trouble if you try to be too clever, though.  *Note
  Argument Prescan::, for detailed discussion.
  
!    For example, ‘min (min (a, b), c)’ is first expanded to
  
         min (((a) < (b) ? (a) : (b)), (c))
  
*************** and then to
*** 1275,1292 ****
  preprocessor (but many macros will then expand to invalid code).  You
  cannot leave out arguments entirely; if a macro takes two arguments,
  there must be exactly one comma at the top level of its argument list.
! Here are some silly examples using 'min':
  
!      min(, b)        ==> ((   ) < (b) ? (   ) : (b))
!      min(a, )        ==> ((a  ) < ( ) ? (a  ) : ( ))
!      min(,)          ==> ((   ) < ( ) ? (   ) : ( ))
!      min((,),)       ==> (((,)) < ( ) ? ((,)) : ( ))
  
!      min()      error-> macro "min" requires 2 arguments, but only 1 given
!      min(,,)    error-> macro "min" passed 3 arguments, but takes just 2
  
!    Whitespace is not a preprocessing token, so if a macro 'foo' takes
! one argument, 'foo ()' and 'foo ( )' both supply it an empty argument.
  Previous GNU preprocessor implementations and documentation were
  incorrect on this point, insisting that a function-like macro that takes
  a single argument be passed a space if an empty argument was required.
--- 1275,1292 ----
  preprocessor (but many macros will then expand to invalid code).  You
  cannot leave out arguments entirely; if a macro takes two arguments,
  there must be exactly one comma at the top level of its argument list.
! Here are some silly examples using ‘min’:
  
!      min(, b)        ↦ ((   ) < (b) ? (   ) : (b))
!      min(a, )        ↦ ((a  ) < ( ) ? (a  ) : ( ))
!      min(,)          ↦ ((   ) < ( ) ? (   ) : ( ))
!      min((,),)       ↦ (((,)) < ( ) ? ((,)) : ( ))
  
!      min()      error→ macro "min" requires 2 arguments, but only 1 given
!      min(,,)    error→ macro "min" passed 3 arguments, but takes just 2
  
!    Whitespace is not a preprocessing token, so if a macro ‘foo’ takes
! one argument, ‘foo ()’ and ‘foo ( )’ both supply it an empty argument.
  Previous GNU preprocessor implementations and documentation were
  incorrect on this point, insisting that a function-like macro that takes
  a single argument be passed a space if an empty argument was required.
*************** a single argument be passed a space if a
*** 1295,1301 ****
  their corresponding actual arguments.
  
       #define foo(x) x, "x"
!      foo(bar)        ==> bar, "x"
  
  
  File: cpp.info,  Node: Stringizing,  Next: Concatenation,  Prev: Macro Arguments,  Up: Macros
--- 1295,1301 ----
  their corresponding actual arguments.
  
       #define foo(x) x, "x"
!      foo(bar)        ↦ bar, "x"
  
  
  File: cpp.info,  Node: Stringizing,  Next: Concatenation,  Prev: Macro Arguments,  Up: Macros
*************** File: cpp.info,  Node: Stringizing,  Nex
*** 1305,1315 ****
  
  Sometimes you may want to convert a macro argument into a string
  constant.  Parameters are not replaced inside string constants, but you
! can use the '#' preprocessing operator instead.  When a macro parameter
! is used with a leading '#', the preprocessor replaces it with the
  literal text of the actual argument, converted to a string constant.
  Unlike normal parameter replacement, the argument is not macro-expanded
! first.  This is called "stringizing".
  
     There is no way to combine an argument with surrounding text and
  stringize it all together.  Instead, you can write a series of adjacent
--- 1305,1315 ----
  
  Sometimes you may want to convert a macro argument into a string
  constant.  Parameters are not replaced inside string constants, but you
! can use the ‘#’ preprocessing operator instead.  When a macro parameter
! is used with a leading ‘#’, the preprocessor replaces it with the
  literal text of the actual argument, converted to a string constant.
  Unlike normal parameter replacement, the argument is not macro-expanded
! first.  This is called “stringizing”.
  
     There is no way to combine an argument with surrounding text and
  stringize it all together.  Instead, you can write a series of adjacent
*************** combines all the adjacent string constan
*** 1324,1348 ****
               fprintf (stderr, "Warning: " #EXP "\n"); } \
       while (0)
       WARN_IF (x == 0);
!           ==> do { if (x == 0)
                  fprintf (stderr, "Warning: " "x == 0" "\n"); } while (0);
  
! The argument for 'EXP' is substituted once, as-is, into the 'if'
! statement, and once, stringized, into the argument to 'fprintf'.  If 'x'
! were a macro, it would be expanded in the 'if' statement, but not in the
  string.
  
!    The 'do' and 'while (0)' are a kludge to make it possible to write
! 'WARN_IF (ARG);', which the resemblance of 'WARN_IF' to a function would
  make C programmers want to do; see *note Swallowing the Semicolon::.
  
     Stringizing in C involves more than putting double-quote characters
  around the fragment.  The preprocessor backslash-escapes the quotes
  surrounding embedded string constants, and all backslashes within string
  and character constants, in order to get a valid C string constant with
! the proper contents.  Thus, stringizing 'p = "foo\n";' results in
  "p = \"foo\\n\";".  However, backslashes that are not inside string or
! character constants are not duplicated: '\n' by itself stringizes to
  "\n".
  
     All leading and trailing whitespace in text being stringized is
--- 1324,1348 ----
               fprintf (stderr, "Warning: " #EXP "\n"); } \
       while (0)
       WARN_IF (x == 0);
!           ↦ do { if (x == 0)
                  fprintf (stderr, "Warning: " "x == 0" "\n"); } while (0);
  
! The argument for ‘EXP’ is substituted once, as-is, into the ‘if’
! statement, and once, stringized, into the argument to ‘fprintf’.  If ‘x’
! were a macro, it would be expanded in the ‘if’ statement, but not in the
  string.
  
!    The ‘do’ and ‘while (0)’ are a kludge to make it possible to write
! ‘WARN_IF (ARG);’, which the resemblance of ‘WARN_IF’ to a function would
  make C programmers want to do; see *note Swallowing the Semicolon::.
  
     Stringizing in C involves more than putting double-quote characters
  around the fragment.  The preprocessor backslash-escapes the quotes
  surrounding embedded string constants, and all backslashes within string
  and character constants, in order to get a valid C string constant with
! the proper contents.  Thus, stringizing ‘p = "foo\n";’ results in
  "p = \"foo\\n\";".  However, backslashes that are not inside string or
! character constants are not duplicated: ‘\n’ by itself stringizes to
  "\n".
  
     All leading and trailing whitespace in text being stringized is
*************** you have to use two levels of macros.
*** 1361,1376 ****
       #define str(s) #s
       #define foo 4
       str (foo)
!           ==> "foo"
       xstr (foo)
!           ==> xstr (4)
!           ==> str (4)
!           ==> "4"
  
!    's' is stringized when it is used in 'str', so it is not
! macro-expanded first.  But 's' is an ordinary argument to 'xstr', so it
! is completely macro-expanded before 'xstr' itself is expanded (*note
! Argument Prescan::).  Therefore, by the time 'str' gets to its argument,
  it has already been macro-expanded.
  
  
--- 1361,1376 ----
       #define str(s) #s
       #define foo 4
       str (foo)
!           ↦ "foo"
       xstr (foo)
!           ↦ xstr (4)
!           ↦ str (4)
!           ↦ "4"
  
!    ‘s’ is stringized when it is used in ‘str’, so it is not
! macro-expanded first.  But ‘s’ is an ordinary argument to ‘xstr’, so it
! is completely macro-expanded before ‘xstr’ itself is expanded (*note
! Argument Prescan::).  Therefore, by the time ‘str’ gets to its argument,
  it has already been macro-expanded.
  
  
*************** File: cpp.info,  Node: Concatenation,  N
*** 1380,1418 ****
  =================
  
  It is often useful to merge two tokens into one while expanding macros.
! This is called "token pasting" or "token concatenation".  The '##'
  preprocessing operator performs token pasting.  When a macro is
! expanded, the two tokens on either side of each '##' operator are
! combined into a single token, which then replaces the '##' and the two
  original tokens in the macro expansion.  Usually both will be
  identifiers, or one will be an identifier and the other a preprocessing
  number.  When pasted, they make a longer identifier.  This isn't the
  only valid case.  It is also possible to concatenate two numbers (or a
! number and a name, such as '1.5' and 'e3') into a number.  Also,
! multi-character operators such as '+=' can be formed by token pasting.
  
     However, two tokens that don't together form a valid token cannot be
! pasted together.  For example, you cannot concatenate 'x' with '+' in
  either order.  If you try, the preprocessor issues a warning and emits
  the two tokens.  Whether it puts white space between the tokens is
! undefined.  It is common to find unnecessary uses of '##' in complex
  macros.  If you get this warning, it is likely that you can simply
! remove the '##'.
  
!    Both the tokens combined by '##' could come from the macro body, but
  you could just as well write them as one token in the first place.
  Token pasting is most useful when one or both of the tokens comes from a
! macro argument.  If either of the tokens next to an '##' is a parameter
! name, it is replaced by its actual argument before '##' executes.  As
  with stringizing, the actual argument is not macro-expanded first.  If
! the argument is empty, that '##' has no effect.
  
     Keep in mind that the C preprocessor converts comments to whitespace
  before macros are even considered.  Therefore, you cannot create a
! comment by concatenating '/' and '*'.  You can put as much whitespace
! between '##' and its operands as you like, including comments, and you
  can put comments in arguments that will be concatenated.  However, it is
! an error if '##' appears at either end of a macro body.
  
     Consider a C program that interprets named commands.  There probably
  needs to be a table of commands, perhaps an array of structures declared
--- 1380,1418 ----
  =================
  
  It is often useful to merge two tokens into one while expanding macros.
! This is called “token pasting” or “token concatenation”.  The ‘##’
  preprocessing operator performs token pasting.  When a macro is
! expanded, the two tokens on either side of each ‘##’ operator are
! combined into a single token, which then replaces the ‘##’ and the two
  original tokens in the macro expansion.  Usually both will be
  identifiers, or one will be an identifier and the other a preprocessing
  number.  When pasted, they make a longer identifier.  This isn't the
  only valid case.  It is also possible to concatenate two numbers (or a
! number and a name, such as ‘1.5’ and ‘e3’) into a number.  Also,
! multi-character operators such as ‘+=’ can be formed by token pasting.
  
     However, two tokens that don't together form a valid token cannot be
! pasted together.  For example, you cannot concatenate ‘x’ with ‘+’ in
  either order.  If you try, the preprocessor issues a warning and emits
  the two tokens.  Whether it puts white space between the tokens is
! undefined.  It is common to find unnecessary uses of ‘##’ in complex
  macros.  If you get this warning, it is likely that you can simply
! remove the ‘##’.
  
!    Both the tokens combined by ‘##’ could come from the macro body, but
  you could just as well write them as one token in the first place.
  Token pasting is most useful when one or both of the tokens comes from a
! macro argument.  If either of the tokens next to an ‘##’ is a parameter
! name, it is replaced by its actual argument before ‘##’ executes.  As
  with stringizing, the actual argument is not macro-expanded first.  If
! the argument is empty, that ‘##’ has no effect.
  
     Keep in mind that the C preprocessor converts comments to whitespace
  before macros are even considered.  Therefore, you cannot create a
! comment by concatenating ‘/’ and ‘*’.  You can put as much whitespace
! between ‘##’ and its operands as you like, including comments, and you
  can put comments in arguments that will be concatenated.  However, it is
! an error if ‘##’ appears at either end of a macro body.
  
     Consider a C program that interprets named commands.  There probably
  needs to be a table of commands, perhaps an array of structures declared
*************** as follows:
*** 1435,1441 ****
  in the string constant and once in the function name.  A macro which
  takes the name of a command as an argument can make this unnecessary.
  The string constant can be created with stringizing, and the function
! name by concatenating the argument with '_command'.  Here is how it is
  done:
  
       #define COMMAND(NAME)  { #NAME, NAME ## _command }
--- 1435,1441 ----
  in the string constant and once in the function name.  A macro which
  takes the name of a command as an argument can make this unnecessary.
  The string constant can be created with stringizing, and the function
! name by concatenating the argument with ‘_command’.  Here is how it is
  done:
  
       #define COMMAND(NAME)  { #NAME, NAME ## _command }
*************** a function.  Here is an example:
*** 1459,1492 ****
  
       #define eprintf(...) fprintf (stderr, __VA_ARGS__)
  
!    This kind of macro is called "variadic".  When the macro is invoked,
  all the tokens in its argument list after the last named argument (this
! macro has none), including any commas, become the "variable argument".
! This sequence of tokens replaces the identifier '__VA_ARGS__' in the
  macro body wherever it appears.  Thus, we have this expansion:
  
       eprintf ("%s:%d: ", input_file, lineno)
!           ==>  fprintf (stderr, "%s:%d: ", input_file, lineno)
  
     The variable argument is completely macro-expanded before it is
  inserted into the macro expansion, just like an ordinary argument.  You
! may use the '#' and '##' operators to stringize the variable argument or
  to paste its leading or trailing token with another token.  (But see
! below for an important special case for '##'.)
  
     If your macro is complicated, you may want a more descriptive name
! for the variable argument than '__VA_ARGS__'.  CPP permits this, as an
! extension.  You may write an argument name immediately before the '...';
! that name is used for the variable argument.  The 'eprintf' macro above
  could be written
  
       #define eprintf(args...) fprintf (stderr, args)
  
! using this extension.  You cannot use '__VA_ARGS__' and this extension
  in the same macro.
  
     You can have named arguments as well as variable arguments in a
! variadic macro.  We could define 'eprintf' like this, instead:
  
       #define eprintf(format, ...) fprintf (stderr, format, __VA_ARGS__)
  
--- 1459,1492 ----
  
       #define eprintf(...) fprintf (stderr, __VA_ARGS__)
  
!    This kind of macro is called “variadic”.  When the macro is invoked,
  all the tokens in its argument list after the last named argument (this
! macro has none), including any commas, become the “variable argument”.
! This sequence of tokens replaces the identifier ‘__VA_ARGS__’ in the
  macro body wherever it appears.  Thus, we have this expansion:
  
       eprintf ("%s:%d: ", input_file, lineno)
!           ↦  fprintf (stderr, "%s:%d: ", input_file, lineno)
  
     The variable argument is completely macro-expanded before it is
  inserted into the macro expansion, just like an ordinary argument.  You
! may use the ‘#’ and ‘##’ operators to stringize the variable argument or
  to paste its leading or trailing token with another token.  (But see
! below for an important special case for ‘##’.)
  
     If your macro is complicated, you may want a more descriptive name
! for the variable argument than ‘__VA_ARGS__’.  CPP permits this, as an
! extension.  You may write an argument name immediately before the ‘...’;
! that name is used for the variable argument.  The ‘eprintf’ macro above
  could be written
  
       #define eprintf(args...) fprintf (stderr, args)
  
! using this extension.  You cannot use ‘__VA_ARGS__’ and this extension
  in the same macro.
  
     You can have named arguments as well as variable arguments in a
! variadic macro.  We could define ‘eprintf’ like this, instead:
  
       #define eprintf(format, ...) fprintf (stderr, format, __VA_ARGS__)
  
*************** gotten a syntax error, because there wou
*** 1501,1507 ****
  after the format string.
  
       eprintf("success!\n", );
!           ==> fprintf(stderr, "success!\n", );
  
     This has been fixed in C++20, and GNU CPP also has a pair of
  extensions which deal with this problem.
--- 1501,1507 ----
  after the format string.
  
       eprintf("success!\n", );
!           ↦ fprintf(stderr, "success!\n", );
  
     This has been fixed in C++20, and GNU CPP also has a pair of
  extensions which deal with this problem.
*************** extensions which deal with this problem.
*** 1510,1543 ****
  leave the variable argument out entirely:
  
       eprintf ("success!\n")
!           ==> fprintf(stderr, "success!\n", );
  
! Second, C++20 introduces the '__VA_OPT__' function macro.  This macro
  may only appear in the definition of a variadic macro.  If the variable
! argument has any tokens, then a '__VA_OPT__' invocation expands to its
  argument; but if the variable argument does not have any tokens, the
! '__VA_OPT__' expands to nothing:
  
       #define eprintf(format, ...) \
         fprintf (stderr, format __VA_OPT__(,) __VA_ARGS__)
  
!    '__VA_OPT__' is also available in GNU C and GNU C++.
  
     Historically, GNU CPP has also had another extension to handle the
! trailing comma: the '##' token paste operator has a special meaning when
  placed between a comma and a variable argument.  Despite the
! introduction of '__VA_OPT__', this extension remains supported in GNU
  CPP, for backward compatibility.  If you write
  
       #define eprintf(format, ...) fprintf (stderr, format, ##__VA_ARGS__)
  
! and the variable argument is left out when the 'eprintf' macro is used,
! then the comma before the '##' will be deleted.  This does _not_ happen
  if you pass an empty argument, nor does it happen if the token preceding
! '##' is anything other than a comma.
  
       eprintf ("success!\n")
!           ==> fprintf(stderr, "success!\n");
  
  The above explanation is ambiguous about the case where the only macro
  parameter is a variable arguments parameter, as it is meaningless to try
--- 1510,1543 ----
  leave the variable argument out entirely:
  
       eprintf ("success!\n")
!           ↦ fprintf(stderr, "success!\n", );
  
! Second, C++20 introduces the ‘__VA_OPT__’ function macro.  This macro
  may only appear in the definition of a variadic macro.  If the variable
! argument has any tokens, then a ‘__VA_OPT__’ invocation expands to its
  argument; but if the variable argument does not have any tokens, the
! ‘__VA_OPT__’ expands to nothing:
  
       #define eprintf(format, ...) \
         fprintf (stderr, format __VA_OPT__(,) __VA_ARGS__)
  
!    ‘__VA_OPT__’ is also available in GNU C and GNU C++.
  
     Historically, GNU CPP has also had another extension to handle the
! trailing comma: the ‘##’ token paste operator has a special meaning when
  placed between a comma and a variable argument.  Despite the
! introduction of ‘__VA_OPT__’, this extension remains supported in GNU
  CPP, for backward compatibility.  If you write
  
       #define eprintf(format, ...) fprintf (stderr, format, ##__VA_ARGS__)
  
! and the variable argument is left out when the ‘eprintf’ macro is used,
! then the comma before the ‘##’ will be deleted.  This does _not_ happen
  if you pass an empty argument, nor does it happen if the token preceding
! ‘##’ is anything other than a comma.
  
       eprintf ("success!\n")
!           ↦ fprintf(stderr, "success!\n");
  
  The above explanation is ambiguous about the case where the only macro
  parameter is a variable arguments parameter, as it is meaningless to try
*************** standard.  Otherwise the comma is droppe
*** 1547,1564 ****
  standard.
  
     The C standard mandates that the only place the identifier
! '__VA_ARGS__' can appear is in the replacement list of a variadic macro.
  It may not be used as a macro name, macro argument name, or within a
  different type of macro.  It may also be forbidden in open text; the
  standard is ambiguous.  We recommend you avoid using it except for its
  defined purpose.
  
!    Likewise, C++ forbids '__VA_OPT__' anywhere outside the replacement
  list of a variadic macro.
  
     Variadic macros became a standard part of the C language with C99.
  GNU CPP previously supported them with a named variable argument
! ('args...', not '...' and '__VA_ARGS__'), which is still supported for
  backward compatibility.
  
  
--- 1547,1564 ----
  standard.
  
     The C standard mandates that the only place the identifier
! ‘__VA_ARGS__’ can appear is in the replacement list of a variadic macro.
  It may not be used as a macro name, macro argument name, or within a
  different type of macro.  It may also be forbidden in open text; the
  standard is ambiguous.  We recommend you avoid using it except for its
  defined purpose.
  
!    Likewise, C++ forbids ‘__VA_OPT__’ anywhere outside the replacement
  list of a variadic macro.
  
     Variadic macros became a standard part of the C language with C99.
  GNU CPP previously supported them with a named variable argument
! (‘args...’, not ‘...’ and ‘__VA_ARGS__’), which is still supported for
  backward compatibility.
  
  
*************** standards, so they are available with al
*** 1592,1612 ****
  standards.  Older compilers may not provide all of them.  Their names
  all start with double underscores.
  
! '__FILE__'
       This macro expands to the name of the current input file, in the
       form of a C string constant.  This is the path by which the
       preprocessor opened the file, not the short name specified in
!      '#include' or as the input file name argument.  For example,
!      '"/usr/local/include/myheader.h"' is a possible expansion of this
       macro.
  
! '__LINE__'
       This macro expands to the current input line number, in the form of
       a decimal integer constant.  While we call it a predefined macro,
       it's a pretty strange macro, since its "definition" changes with
       each new line of source code.
  
!    '__FILE__' and '__LINE__' are useful in generating an error message
  to report an inconsistency detected by the program; the message can
  state the source line at which the inconsistency was detected.  For
  example,
--- 1592,1612 ----
  standards.  Older compilers may not provide all of them.  Their names
  all start with double underscores.
  
! ‘__FILE__’
       This macro expands to the name of the current input file, in the
       form of a C string constant.  This is the path by which the
       preprocessor opened the file, not the short name specified in
!      ‘#include’ or as the input file name argument.  For example,
!      ‘"/usr/local/include/myheader.h"’ is a possible expansion of this
       macro.
  
! ‘__LINE__’
       This macro expands to the current input line number, in the form of
       a decimal integer constant.  While we call it a predefined macro,
       it's a pretty strange macro, since its "definition" changes with
       each new line of source code.
  
!    ‘__FILE__’ and ‘__LINE__’ are useful in generating an error message
  to report an inconsistency detected by the program; the message can
  state the source line at which the inconsistency was detected.  For
  example,
*************** example,
*** 1616,1719 ****
                        "%d at %s, line %d.",
                length, __FILE__, __LINE__);
  
!    An '#include' directive changes the expansions of '__FILE__' and
! '__LINE__' to correspond to the included file.  At the end of that file,
! when processing resumes on the input file that contained the '#include'
! directive, the expansions of '__FILE__' and '__LINE__' revert to the
! values they had before the '#include' (but '__LINE__' is then
  incremented by one as processing moves to the line after the
! '#include').
  
!    A '#line' directive changes '__LINE__', and may change '__FILE__' as
  well.  *Note Line Control::.
  
!    C99 introduced '__func__', and GCC has provided '__FUNCTION__' for a
  long time.  Both of these are strings containing the name of the current
  function (there are slight semantic differences; see the GCC manual).
  Neither of them is a macro; the preprocessor does not know the name of
  the current function.  They tend to be useful in conjunction with
! '__FILE__' and '__LINE__', though.
  
! '__DATE__'
       This macro expands to a string constant that describes the date on
       which the preprocessor is being run.  The string constant contains
!      eleven characters and looks like '"Feb 12 1996"'.  If the day of
       the month is less than 10, it is padded with a space on the left.
  
       If GCC cannot determine the current date, it will emit a warning
!      message (once per compilation) and '__DATE__' will expand to
!      '"??? ?? ????"'.
  
! '__TIME__'
       This macro expands to a string constant that describes the time at
       which the preprocessor is being run.  The string constant contains
!      eight characters and looks like '"23:59:01"'.
  
       If GCC cannot determine the current time, it will emit a warning
!      message (once per compilation) and '__TIME__' will expand to
!      '"??:??:??"'.
  
! '__STDC__'
       In normal operation, this macro expands to the constant 1, to
       signify that this compiler conforms to ISO Standard C.  If GNU CPP
       is used with a compiler other than GCC, this is not necessarily
       true; however, the preprocessor always conforms to the standard
!      unless the '-traditional-cpp' option is used.
  
!      This macro is not defined if the '-traditional-cpp' option is used.
  
       On some hosts, the system compiler uses a different convention,
!      where '__STDC__' is normally 0, but is 1 if the user specifies
       strict conformance to the C Standard.  CPP follows the host
       convention when processing system header files, but when processing
!      user files '__STDC__' is always 1.  This has been reported to cause
       problems; for instance, some versions of Solaris provide X Windows
!      headers that expect '__STDC__' to be either undefined or 1.  *Note
       Invocation::.
  
! '__STDC_VERSION__'
       This macro expands to the C Standard's version number, a long
!      integer constant of the form 'YYYYMML' where YYYY and MM are the
       year and month of the Standard version.  This signifies which
       version of the C Standard the compiler conforms to.  Like
!      '__STDC__', this is not necessarily accurate for the entire
       implementation, unless GNU CPP is being used with GCC.
  
!      The value '199409L' signifies the 1989 C standard as amended in
!      1994, which is the current default; the value '199901L' signifies
!      the 1999 revision of the C standard; the value '201112L' signifies
!      the 2011 revision of the C standard; the value '201710L' signifies
       the 2017 revision of the C standard (which is otherwise identical
       to the 2011 version apart from correction of defects).  An
!      unspecified value larger than '201710L' is used for the
!      experimental '-std=c2x' and '-std=gnu2x' modes.
  
!      This macro is not defined if the '-traditional-cpp' option is used,
       nor when compiling C++ or Objective-C.
  
! '__STDC_HOSTED__'
       This macro is defined, with value 1, if the compiler's target is a
!      "hosted environment".  A hosted environment has the complete
       facilities of the standard C library available.
  
! '__cplusplus'
       This macro is defined when the C++ compiler is in use.  You can use
!      '__cplusplus' to test whether a header is compiled by a C compiler
!      or a C++ compiler.  This macro is similar to '__STDC_VERSION__', in
       that it expands to a version number.  Depending on the language
!      standard selected, the value of the macro is '199711L' for the 1998
!      C++ standard, '201103L' for the 2011 C++ standard, '201402L' for
!      the 2014 C++ standard, '201703L' for the 2017 C++ standard,
!      '202002L' for the 2020 C++ standard, or an unspecified value
!      strictly larger than '202002L' for the experimental languages
!      enabled by '-std=c++23' and '-std=gnu++23'.
  
! '__OBJC__'
       This macro is defined, with value 1, when the Objective-C compiler
!      is in use.  You can use '__OBJC__' to test whether a header is
       compiled by a C compiler or an Objective-C compiler.
  
! '__ASSEMBLER__'
       This macro is defined with value 1 when preprocessing assembly
       language.
  
--- 1616,1719 ----
                        "%d at %s, line %d.",
                length, __FILE__, __LINE__);
  
!    An ‘#include’ directive changes the expansions of ‘__FILE__’ and
! ‘__LINE__’ to correspond to the included file.  At the end of that file,
! when processing resumes on the input file that contained the ‘#include’
! directive, the expansions of ‘__FILE__’ and ‘__LINE__’ revert to the
! values they had before the ‘#include’ (but ‘__LINE__’ is then
  incremented by one as processing moves to the line after the
! ‘#include’).
  
!    A ‘#line’ directive changes ‘__LINE__’, and may change ‘__FILE__’ as
  well.  *Note Line Control::.
  
!    C99 introduced ‘__func__’, and GCC has provided ‘__FUNCTION__’ for a
  long time.  Both of these are strings containing the name of the current
  function (there are slight semantic differences; see the GCC manual).
  Neither of them is a macro; the preprocessor does not know the name of
  the current function.  They tend to be useful in conjunction with
! ‘__FILE__’ and ‘__LINE__’, though.
  
! ‘__DATE__’
       This macro expands to a string constant that describes the date on
       which the preprocessor is being run.  The string constant contains
!      eleven characters and looks like ‘"Feb 12 1996"’.  If the day of
       the month is less than 10, it is padded with a space on the left.
  
       If GCC cannot determine the current date, it will emit a warning
!      message (once per compilation) and ‘__DATE__’ will expand to
!      ‘"??? ?? ????"’.
  
! ‘__TIME__’
       This macro expands to a string constant that describes the time at
       which the preprocessor is being run.  The string constant contains
!      eight characters and looks like ‘"23:59:01"’.
  
       If GCC cannot determine the current time, it will emit a warning
!      message (once per compilation) and ‘__TIME__’ will expand to
!      ‘"??:??:??"’.
  
! ‘__STDC__’
       In normal operation, this macro expands to the constant 1, to
       signify that this compiler conforms to ISO Standard C.  If GNU CPP
       is used with a compiler other than GCC, this is not necessarily
       true; however, the preprocessor always conforms to the standard
!      unless the ‘-traditional-cpp’ option is used.
  
!      This macro is not defined if the ‘-traditional-cpp’ option is used.
  
       On some hosts, the system compiler uses a different convention,
!      where ‘__STDC__’ is normally 0, but is 1 if the user specifies
       strict conformance to the C Standard.  CPP follows the host
       convention when processing system header files, but when processing
!      user files ‘__STDC__’ is always 1.  This has been reported to cause
       problems; for instance, some versions of Solaris provide X Windows
!      headers that expect ‘__STDC__’ to be either undefined or 1.  *Note
       Invocation::.
  
! ‘__STDC_VERSION__’
       This macro expands to the C Standard's version number, a long
!      integer constant of the form ‘YYYYMML’ where YYYY and MM are the
       year and month of the Standard version.  This signifies which
       version of the C Standard the compiler conforms to.  Like
!      ‘__STDC__’, this is not necessarily accurate for the entire
       implementation, unless GNU CPP is being used with GCC.
  
!      The value ‘199409L’ signifies the 1989 C standard as amended in
!      1994, which is the current default; the value ‘199901L’ signifies
!      the 1999 revision of the C standard; the value ‘201112L’ signifies
!      the 2011 revision of the C standard; the value ‘201710L’ signifies
       the 2017 revision of the C standard (which is otherwise identical
       to the 2011 version apart from correction of defects).  An
!      unspecified value larger than ‘201710L’ is used for the
!      experimental ‘-std=c2x’ and ‘-std=gnu2x’ modes.
  
!      This macro is not defined if the ‘-traditional-cpp’ option is used,
       nor when compiling C++ or Objective-C.
  
! ‘__STDC_HOSTED__’
       This macro is defined, with value 1, if the compiler's target is a
!      “hosted environment”.  A hosted environment has the complete
       facilities of the standard C library available.
  
! ‘__cplusplus’
       This macro is defined when the C++ compiler is in use.  You can use
!      ‘__cplusplus’ to test whether a header is compiled by a C compiler
!      or a C++ compiler.  This macro is similar to ‘__STDC_VERSION__’, in
       that it expands to a version number.  Depending on the language
!      standard selected, the value of the macro is ‘199711L’ for the 1998
!      C++ standard, ‘201103L’ for the 2011 C++ standard, ‘201402L’ for
!      the 2014 C++ standard, ‘201703L’ for the 2017 C++ standard,
!      ‘202002L’ for the 2020 C++ standard, or an unspecified value
!      strictly larger than ‘202002L’ for the experimental languages
!      enabled by ‘-std=c++23’ and ‘-std=gnu++23’.
  
! ‘__OBJC__’
       This macro is defined, with value 1, when the Objective-C compiler
!      is in use.  You can use ‘__OBJC__’ to test whether a header is
       compiled by a C compiler or an Objective-C compiler.
  
! ‘__ASSEMBLER__’
       This macro is defined with value 1 when preprocessing assembly
       language.
  
*************** with the same meanings regardless of the
*** 1728,1758 ****
  which you are using GNU C or GNU Fortran.  Their names all start with
  double underscores.
  
! '__COUNTER__'
       This macro expands to sequential integral values starting from 0.
!      In conjunction with the '##' operator, this provides a convenient
       means to generate unique identifiers.  Care must be taken to ensure
!      that '__COUNTER__' is not expanded prior to inclusion of
       precompiled headers which use it.  Otherwise, the precompiled
       headers will not be used.
  
! '__GFORTRAN__'
       The GNU Fortran compiler defines this.
  
! '__GNUC__'
! '__GNUC_MINOR__'
! '__GNUC_PATCHLEVEL__'
       These macros are defined by all GNU compilers that use the C
       preprocessor: C, C++, Objective-C and Fortran.  Their values are
       the major version, minor version, and patch level of the compiler,
       as integer constants.  For example, GCC version X.Y.Z defines
!      '__GNUC__' to X, '__GNUC_MINOR__' to Y, and '__GNUC_PATCHLEVEL__'
       to Z.  These macros are also defined if you invoke the preprocessor
       directly.
  
       If all you need to know is whether or not your program is being
       compiled by GCC, or a non-GCC compiler that claims to accept the
!      GNU C dialects, you can simply test '__GNUC__'.  If you need to
       write code which depends on a specific version, you must be more
       careful.  Each time the minor version is increased, the patch level
       is reset to zero; each time the major version is increased, the
--- 1728,1758 ----
  which you are using GNU C or GNU Fortran.  Their names all start with
  double underscores.
  
! ‘__COUNTER__’
       This macro expands to sequential integral values starting from 0.
!      In conjunction with the ‘##’ operator, this provides a convenient
       means to generate unique identifiers.  Care must be taken to ensure
!      that ‘__COUNTER__’ is not expanded prior to inclusion of
       precompiled headers which use it.  Otherwise, the precompiled
       headers will not be used.
  
! ‘__GFORTRAN__’
       The GNU Fortran compiler defines this.
  
! ‘__GNUC__’
! ‘__GNUC_MINOR__’
! ‘__GNUC_PATCHLEVEL__’
       These macros are defined by all GNU compilers that use the C
       preprocessor: C, C++, Objective-C and Fortran.  Their values are
       the major version, minor version, and patch level of the compiler,
       as integer constants.  For example, GCC version X.Y.Z defines
!      ‘__GNUC__’ to X, ‘__GNUC_MINOR__’ to Y, and ‘__GNUC_PATCHLEVEL__’
       to Z.  These macros are also defined if you invoke the preprocessor
       directly.
  
       If all you need to know is whether or not your program is being
       compiled by GCC, or a non-GCC compiler that claims to accept the
!      GNU C dialects, you can simply test ‘__GNUC__’.  If you need to
       write code which depends on a specific version, you must be more
       careful.  Each time the minor version is increased, the patch level
       is reset to zero; each time the major version is increased, the
*************** double underscores.
*** 1778,1831 ****
  
       Many people find this form easier to understand.
  
! '__GNUG__'
       The GNU C++ compiler defines this.  Testing it is equivalent to
!      testing '(__GNUC__ && __cplusplus)'.
  
! '__STRICT_ANSI__'
!      GCC defines this macro if and only if the '-ansi' switch, or a
!      '-std' switch specifying strict conformance to some version of ISO
       C or ISO C++, was specified when GCC was invoked.  It is defined to
!      '1'.  This macro exists primarily to direct GNU libc's header files
       to use only definitions found in standard C.
  
! '__BASE_FILE__'
       This macro expands to the name of the main input file, in the form
       of a C string constant.  This is the source file that was specified
       on the command line of the preprocessor or C compiler.
  
! '__FILE_NAME__'
       This macro expands to the basename of the current input file, in
       the form of a C string constant.  This is the last path component
       by which the preprocessor opened the file.  For example, processing
!      '"/usr/local/include/myheader.h"' would set this macro to
!      '"myheader.h"'.
  
! '__INCLUDE_LEVEL__'
       This macro expands to a decimal integer constant that represents
       the depth of nesting in include files.  The value of this macro is
!      incremented on every '#include' directive and decremented at the
       end of every included file.  It starts out at 0, its value within
       the base file specified on the command line.
  
! '__ELF__'
       This macro is defined if the target uses the ELF object format.
  
! '__VERSION__'
       This macro expands to a string constant which describes the version
       of the compiler in use.  You should not rely on its contents having
       any particular form, but it can be counted on to contain at least
       the release number.
  
! '__OPTIMIZE__'
! '__OPTIMIZE_SIZE__'
! '__NO_INLINE__'
!      These macros describe the compilation mode.  '__OPTIMIZE__' is
!      defined in all optimizing compilations.  '__OPTIMIZE_SIZE__' is
       defined if the compiler is optimizing for size, not speed.
!      '__NO_INLINE__' is defined if no functions will be inlined into
       their callers (when not optimizing, or when inlining has been
!      specifically disabled by '-fno-inline').
  
       These macros cause certain GNU header files to provide optimized
       definitions, using macros or inline functions, of system library
--- 1778,1831 ----
  
       Many people find this form easier to understand.
  
! ‘__GNUG__’
       The GNU C++ compiler defines this.  Testing it is equivalent to
!      testing ‘(__GNUC__ && __cplusplus)’.
  
! ‘__STRICT_ANSI__’
!      GCC defines this macro if and only if the ‘-ansi’ switch, or a
!      ‘-std’ switch specifying strict conformance to some version of ISO
       C or ISO C++, was specified when GCC was invoked.  It is defined to
!      ‘1’.  This macro exists primarily to direct GNU libc's header files
       to use only definitions found in standard C.
  
! ‘__BASE_FILE__’
       This macro expands to the name of the main input file, in the form
       of a C string constant.  This is the source file that was specified
       on the command line of the preprocessor or C compiler.
  
! ‘__FILE_NAME__’
       This macro expands to the basename of the current input file, in
       the form of a C string constant.  This is the last path component
       by which the preprocessor opened the file.  For example, processing
!      ‘"/usr/local/include/myheader.h"’ would set this macro to
!      ‘"myheader.h"’.
  
! ‘__INCLUDE_LEVEL__’
       This macro expands to a decimal integer constant that represents
       the depth of nesting in include files.  The value of this macro is
!      incremented on every ‘#include’ directive and decremented at the
       end of every included file.  It starts out at 0, its value within
       the base file specified on the command line.
  
! ‘__ELF__’
       This macro is defined if the target uses the ELF object format.
  
! ‘__VERSION__’
       This macro expands to a string constant which describes the version
       of the compiler in use.  You should not rely on its contents having
       any particular form, but it can be counted on to contain at least
       the release number.
  
! ‘__OPTIMIZE__’
! ‘__OPTIMIZE_SIZE__’
! ‘__NO_INLINE__’
!      These macros describe the compilation mode.  ‘__OPTIMIZE__’ is
!      defined in all optimizing compilations.  ‘__OPTIMIZE_SIZE__’ is
       defined if the compiler is optimizing for size, not speed.
!      ‘__NO_INLINE__’ is defined if no functions will be inlined into
       their callers (when not optimizing, or when inlining has been
!      specifically disabled by ‘-fno-inline’).
  
       These macros cause certain GNU header files to provide optimized
       definitions, using macros or inline functions, of system library
*************** double underscores.
*** 1833,2071 ****
       make sure that programs will execute with the same effect whether
       or not they are defined.  If they are defined, their value is 1.
  
! '__GNUC_GNU_INLINE__'
!      GCC defines this macro if functions declared 'inline' will be
       handled in GCC's traditional gnu90 mode.  Object files will contain
!      externally visible definitions of all functions declared 'inline'
!      without 'extern' or 'static'.  They will not contain any
!      definitions of any functions declared 'extern inline'.
  
! '__GNUC_STDC_INLINE__'
!      GCC defines this macro if functions declared 'inline' will be
       handled according to the ISO C99 or later standards.  Object files
       will contain externally visible definitions of all functions
!      declared 'extern inline'.  They will not contain definitions of any
!      functions declared 'inline' without 'extern'.
  
!      If this macro is defined, GCC supports the 'gnu_inline' function
       attribute as a way to always get the gnu90 behavior.
  
! '__CHAR_UNSIGNED__'
!      GCC defines this macro if and only if the data type 'char' is
       unsigned on the target machine.  It exists to cause the standard
!      header file 'limits.h' to work correctly.  You should not use this
       macro yourself; instead, refer to the standard macros defined in
!      'limits.h'.
  
! '__WCHAR_UNSIGNED__'
!      Like '__CHAR_UNSIGNED__', this macro is defined if and only if the
!      data type 'wchar_t' is unsigned and the front-end is in C++ mode.
  
! '__REGISTER_PREFIX__'
       This macro expands to a single token (not a string constant) which
       is the prefix applied to CPU register names in assembly language
       for this target.  You can use it to write assembly that is usable
!      in multiple environments.  For example, in the 'm68k-aout'
!      environment it expands to nothing, but in the 'm68k-coff'
!      environment it expands to a single '%'.
  
! '__USER_LABEL_PREFIX__'
       This macro expands to a single token which is the prefix applied to
       user labels (symbols visible to C code) in assembly.  For example,
!      in the 'm68k-aout' environment it expands to an '_', but in the
!      'm68k-coff' environment it expands to nothing.
  
       This macro will have the correct definition even if
!      '-f(no-)underscores' is in use, but it will not be correct if
       target-specific options that adjust this prefix are used (e.g. the
!      OSF/rose '-mno-underscores' option).
  
! '__SIZE_TYPE__'
! '__PTRDIFF_TYPE__'
! '__WCHAR_TYPE__'
! '__WINT_TYPE__'
! '__INTMAX_TYPE__'
! '__UINTMAX_TYPE__'
! '__SIG_ATOMIC_TYPE__'
! '__INT8_TYPE__'
! '__INT16_TYPE__'
! '__INT32_TYPE__'
! '__INT64_TYPE__'
! '__UINT8_TYPE__'
! '__UINT16_TYPE__'
! '__UINT32_TYPE__'
! '__UINT64_TYPE__'
! '__INT_LEAST8_TYPE__'
! '__INT_LEAST16_TYPE__'
! '__INT_LEAST32_TYPE__'
! '__INT_LEAST64_TYPE__'
! '__UINT_LEAST8_TYPE__'
! '__UINT_LEAST16_TYPE__'
! '__UINT_LEAST32_TYPE__'
! '__UINT_LEAST64_TYPE__'
! '__INT_FAST8_TYPE__'
! '__INT_FAST16_TYPE__'
! '__INT_FAST32_TYPE__'
! '__INT_FAST64_TYPE__'
! '__UINT_FAST8_TYPE__'
! '__UINT_FAST16_TYPE__'
! '__UINT_FAST32_TYPE__'
! '__UINT_FAST64_TYPE__'
! '__INTPTR_TYPE__'
! '__UINTPTR_TYPE__'
       These macros are defined to the correct underlying types for the
!      'size_t', 'ptrdiff_t', 'wchar_t', 'wint_t', 'intmax_t',
!      'uintmax_t', 'sig_atomic_t', 'int8_t', 'int16_t', 'int32_t',
!      'int64_t', 'uint8_t', 'uint16_t', 'uint32_t', 'uint64_t',
!      'int_least8_t', 'int_least16_t', 'int_least32_t', 'int_least64_t',
!      'uint_least8_t', 'uint_least16_t', 'uint_least32_t',
!      'uint_least64_t', 'int_fast8_t', 'int_fast16_t', 'int_fast32_t',
!      'int_fast64_t', 'uint_fast8_t', 'uint_fast16_t', 'uint_fast32_t',
!      'uint_fast64_t', 'intptr_t', and 'uintptr_t' typedefs,
       respectively.  They exist to make the standard header files
!      'stddef.h', 'stdint.h', and 'wchar.h' work correctly.  You should
       not use these macros directly; instead, include the appropriate
       headers and use the typedefs.  Some of these macros may not be
!      defined on particular systems if GCC does not provide a 'stdint.h'
       header on those systems.
  
! '__CHAR_BIT__'
       Defined to the number of bits used in the representation of the
!      'char' data type.  It exists to make the standard header given
       numerical limits work correctly.  You should not use this macro
       directly; instead, include the appropriate headers.
  
! '__SCHAR_MAX__'
! '__WCHAR_MAX__'
! '__SHRT_MAX__'
! '__INT_MAX__'
! '__LONG_MAX__'
! '__LONG_LONG_MAX__'
! '__WINT_MAX__'
! '__SIZE_MAX__'
! '__PTRDIFF_MAX__'
! '__INTMAX_MAX__'
! '__UINTMAX_MAX__'
! '__SIG_ATOMIC_MAX__'
! '__INT8_MAX__'
! '__INT16_MAX__'
! '__INT32_MAX__'
! '__INT64_MAX__'
! '__UINT8_MAX__'
! '__UINT16_MAX__'
! '__UINT32_MAX__'
! '__UINT64_MAX__'
! '__INT_LEAST8_MAX__'
! '__INT_LEAST16_MAX__'
! '__INT_LEAST32_MAX__'
! '__INT_LEAST64_MAX__'
! '__UINT_LEAST8_MAX__'
! '__UINT_LEAST16_MAX__'
! '__UINT_LEAST32_MAX__'
! '__UINT_LEAST64_MAX__'
! '__INT_FAST8_MAX__'
! '__INT_FAST16_MAX__'
! '__INT_FAST32_MAX__'
! '__INT_FAST64_MAX__'
! '__UINT_FAST8_MAX__'
! '__UINT_FAST16_MAX__'
! '__UINT_FAST32_MAX__'
! '__UINT_FAST64_MAX__'
! '__INTPTR_MAX__'
! '__UINTPTR_MAX__'
! '__WCHAR_MIN__'
! '__WINT_MIN__'
! '__SIG_ATOMIC_MIN__'
!      Defined to the maximum value of the 'signed char', 'wchar_t',
!      'signed short', 'signed int', 'signed long', 'signed long long',
!      'wint_t', 'size_t', 'ptrdiff_t', 'intmax_t', 'uintmax_t',
!      'sig_atomic_t', 'int8_t', 'int16_t', 'int32_t', 'int64_t',
!      'uint8_t', 'uint16_t', 'uint32_t', 'uint64_t', 'int_least8_t',
!      'int_least16_t', 'int_least32_t', 'int_least64_t', 'uint_least8_t',
!      'uint_least16_t', 'uint_least32_t', 'uint_least64_t',
!      'int_fast8_t', 'int_fast16_t', 'int_fast32_t', 'int_fast64_t',
!      'uint_fast8_t', 'uint_fast16_t', 'uint_fast32_t', 'uint_fast64_t',
!      'intptr_t', and 'uintptr_t' types and to the minimum value of the
!      'wchar_t', 'wint_t', and 'sig_atomic_t' types respectively.  They
       exist to make the standard header given numerical limits work
       correctly.  You should not use these macros directly; instead,
       include the appropriate headers.  Some of these macros may not be
!      defined on particular systems if GCC does not provide a 'stdint.h'
       header on those systems.
  
! '__INT8_C'
! '__INT16_C'
! '__INT32_C'
! '__INT64_C'
! '__UINT8_C'
! '__UINT16_C'
! '__UINT32_C'
! '__UINT64_C'
! '__INTMAX_C'
! '__UINTMAX_C'
!      Defined to implementations of the standard 'stdint.h' macros with
!      the same names without the leading '__'.  They exist the make the
       implementation of that header work correctly.  You should not use
       these macros directly; instead, include the appropriate headers.
       Some of these macros may not be defined on particular systems if
!      GCC does not provide a 'stdint.h' header on those systems.
  
! '__SCHAR_WIDTH__'
! '__SHRT_WIDTH__'
! '__INT_WIDTH__'
! '__LONG_WIDTH__'
! '__LONG_LONG_WIDTH__'
! '__PTRDIFF_WIDTH__'
! '__SIG_ATOMIC_WIDTH__'
! '__SIZE_WIDTH__'
! '__WCHAR_WIDTH__'
! '__WINT_WIDTH__'
! '__INT_LEAST8_WIDTH__'
! '__INT_LEAST16_WIDTH__'
! '__INT_LEAST32_WIDTH__'
! '__INT_LEAST64_WIDTH__'
! '__INT_FAST8_WIDTH__'
! '__INT_FAST16_WIDTH__'
! '__INT_FAST32_WIDTH__'
! '__INT_FAST64_WIDTH__'
! '__INTPTR_WIDTH__'
! '__INTMAX_WIDTH__'
       Defined to the bit widths of the corresponding types.  They exist
!      to make the implementations of 'limits.h' and 'stdint.h' behave
       correctly.  You should not use these macros directly; instead,
       include the appropriate headers.  Some of these macros may not be
!      defined on particular systems if GCC does not provide a 'stdint.h'
       header on those systems.
  
! '__SIZEOF_INT__'
! '__SIZEOF_LONG__'
! '__SIZEOF_LONG_LONG__'
! '__SIZEOF_SHORT__'
! '__SIZEOF_POINTER__'
! '__SIZEOF_FLOAT__'
! '__SIZEOF_DOUBLE__'
! '__SIZEOF_LONG_DOUBLE__'
! '__SIZEOF_SIZE_T__'
! '__SIZEOF_WCHAR_T__'
! '__SIZEOF_WINT_T__'
! '__SIZEOF_PTRDIFF_T__'
!      Defined to the number of bytes of the C standard data types: 'int',
!      'long', 'long long', 'short', 'void *', 'float', 'double', 'long
!      double', 'size_t', 'wchar_t', 'wint_t' and 'ptrdiff_t'.
  
! '__BYTE_ORDER__'
! '__ORDER_LITTLE_ENDIAN__'
! '__ORDER_BIG_ENDIAN__'
! '__ORDER_PDP_ENDIAN__'
!      '__BYTE_ORDER__' is defined to one of the values
!      '__ORDER_LITTLE_ENDIAN__', '__ORDER_BIG_ENDIAN__', or
!      '__ORDER_PDP_ENDIAN__' to reflect the layout of multi-byte and
!      multi-word quantities in memory.  If '__BYTE_ORDER__' is equal to
!      '__ORDER_LITTLE_ENDIAN__' or '__ORDER_BIG_ENDIAN__', then
       multi-byte and multi-word quantities are laid out identically: the
       byte (word) at the lowest address is the least significant or most
       significant byte (word) of the quantity, respectively.  If
!      '__BYTE_ORDER__' is equal to '__ORDER_PDP_ENDIAN__', then bytes in
       16-bit words are laid out in a little-endian fashion, whereas the
       16-bit subwords of a 32-bit quantity are laid out in big-endian
       fashion.
--- 1833,2071 ----
       make sure that programs will execute with the same effect whether
       or not they are defined.  If they are defined, their value is 1.
  
! ‘__GNUC_GNU_INLINE__’
!      GCC defines this macro if functions declared ‘inline’ will be
       handled in GCC's traditional gnu90 mode.  Object files will contain
!      externally visible definitions of all functions declared ‘inline’
!      without ‘extern’ or ‘static’.  They will not contain any
!      definitions of any functions declared ‘extern inline’.
  
! ‘__GNUC_STDC_INLINE__’
!      GCC defines this macro if functions declared ‘inline’ will be
       handled according to the ISO C99 or later standards.  Object files
       will contain externally visible definitions of all functions
!      declared ‘extern inline’.  They will not contain definitions of any
!      functions declared ‘inline’ without ‘extern’.
  
!      If this macro is defined, GCC supports the ‘gnu_inline’ function
       attribute as a way to always get the gnu90 behavior.
  
! ‘__CHAR_UNSIGNED__’
!      GCC defines this macro if and only if the data type ‘char’ is
       unsigned on the target machine.  It exists to cause the standard
!      header file ‘limits.h’ to work correctly.  You should not use this
       macro yourself; instead, refer to the standard macros defined in
!      ‘limits.h’.
  
! ‘__WCHAR_UNSIGNED__’
!      Like ‘__CHAR_UNSIGNED__’, this macro is defined if and only if the
!      data type ‘wchar_t’ is unsigned and the front-end is in C++ mode.
  
! ‘__REGISTER_PREFIX__’
       This macro expands to a single token (not a string constant) which
       is the prefix applied to CPU register names in assembly language
       for this target.  You can use it to write assembly that is usable
!      in multiple environments.  For example, in the ‘m68k-aout’
!      environment it expands to nothing, but in the ‘m68k-coff’
!      environment it expands to a single ‘%’.
  
! ‘__USER_LABEL_PREFIX__’
       This macro expands to a single token which is the prefix applied to
       user labels (symbols visible to C code) in assembly.  For example,
!      in the ‘m68k-aout’ environment it expands to an ‘_’, but in the
!      ‘m68k-coff’ environment it expands to nothing.
  
       This macro will have the correct definition even if
!      ‘-f(no-)underscores’ is in use, but it will not be correct if
       target-specific options that adjust this prefix are used (e.g. the
!      OSF/rose ‘-mno-underscores’ option).
  
! ‘__SIZE_TYPE__’
! ‘__PTRDIFF_TYPE__’
! ‘__WCHAR_TYPE__’
! ‘__WINT_TYPE__’
! ‘__INTMAX_TYPE__’
! ‘__UINTMAX_TYPE__’
! ‘__SIG_ATOMIC_TYPE__’
! ‘__INT8_TYPE__’
! ‘__INT16_TYPE__’
! ‘__INT32_TYPE__’
! ‘__INT64_TYPE__’
! ‘__UINT8_TYPE__’
! ‘__UINT16_TYPE__’
! ‘__UINT32_TYPE__’
! ‘__UINT64_TYPE__’
! ‘__INT_LEAST8_TYPE__’
! ‘__INT_LEAST16_TYPE__’
! ‘__INT_LEAST32_TYPE__’
! ‘__INT_LEAST64_TYPE__’
! ‘__UINT_LEAST8_TYPE__’
! ‘__UINT_LEAST16_TYPE__’
! ‘__UINT_LEAST32_TYPE__’
! ‘__UINT_LEAST64_TYPE__’
! ‘__INT_FAST8_TYPE__’
! ‘__INT_FAST16_TYPE__’
! ‘__INT_FAST32_TYPE__’
! ‘__INT_FAST64_TYPE__’
! ‘__UINT_FAST8_TYPE__’
! ‘__UINT_FAST16_TYPE__’
! ‘__UINT_FAST32_TYPE__’
! ‘__UINT_FAST64_TYPE__’
! ‘__INTPTR_TYPE__’
! ‘__UINTPTR_TYPE__’
       These macros are defined to the correct underlying types for the
!      ‘size_t’, ‘ptrdiff_t’, ‘wchar_t’, ‘wint_t’, ‘intmax_t’,
!      ‘uintmax_t’, ‘sig_atomic_t’, ‘int8_t’, ‘int16_t’, ‘int32_t’,
!      ‘int64_t’, ‘uint8_t’, ‘uint16_t’, ‘uint32_t’, ‘uint64_t’,
!      ‘int_least8_t’, ‘int_least16_t’, ‘int_least32_t’, ‘int_least64_t’,
!      ‘uint_least8_t’, ‘uint_least16_t’, ‘uint_least32_t’,
!      ‘uint_least64_t’, ‘int_fast8_t’, ‘int_fast16_t’, ‘int_fast32_t’,
!      ‘int_fast64_t’, ‘uint_fast8_t’, ‘uint_fast16_t’, ‘uint_fast32_t’,
!      ‘uint_fast64_t’, ‘intptr_t’, and ‘uintptr_t’ typedefs,
       respectively.  They exist to make the standard header files
!      ‘stddef.h’, ‘stdint.h’, and ‘wchar.h’ work correctly.  You should
       not use these macros directly; instead, include the appropriate
       headers and use the typedefs.  Some of these macros may not be
!      defined on particular systems if GCC does not provide a ‘stdint.h’
       header on those systems.
  
! ‘__CHAR_BIT__’
       Defined to the number of bits used in the representation of the
!      ‘char’ data type.  It exists to make the standard header given
       numerical limits work correctly.  You should not use this macro
       directly; instead, include the appropriate headers.
  
! ‘__SCHAR_MAX__’
! ‘__WCHAR_MAX__’
! ‘__SHRT_MAX__’
! ‘__INT_MAX__’
! ‘__LONG_MAX__’
! ‘__LONG_LONG_MAX__’
! ‘__WINT_MAX__’
! ‘__SIZE_MAX__’
! ‘__PTRDIFF_MAX__’
! ‘__INTMAX_MAX__’
! ‘__UINTMAX_MAX__’
! ‘__SIG_ATOMIC_MAX__’
! ‘__INT8_MAX__’
! ‘__INT16_MAX__’
! ‘__INT32_MAX__’
! ‘__INT64_MAX__’
! ‘__UINT8_MAX__’
! ‘__UINT16_MAX__’
! ‘__UINT32_MAX__’
! ‘__UINT64_MAX__’
! ‘__INT_LEAST8_MAX__’
! ‘__INT_LEAST16_MAX__’
! ‘__INT_LEAST32_MAX__’
! ‘__INT_LEAST64_MAX__’
! ‘__UINT_LEAST8_MAX__’
! ‘__UINT_LEAST16_MAX__’
! ‘__UINT_LEAST32_MAX__’
! ‘__UINT_LEAST64_MAX__’
! ‘__INT_FAST8_MAX__’
! ‘__INT_FAST16_MAX__’
! ‘__INT_FAST32_MAX__’
! ‘__INT_FAST64_MAX__’
! ‘__UINT_FAST8_MAX__’
! ‘__UINT_FAST16_MAX__’
! ‘__UINT_FAST32_MAX__’
! ‘__UINT_FAST64_MAX__’
! ‘__INTPTR_MAX__’
! ‘__UINTPTR_MAX__’
! ‘__WCHAR_MIN__’
! ‘__WINT_MIN__’
! ‘__SIG_ATOMIC_MIN__’
!      Defined to the maximum value of the ‘signed char’, ‘wchar_t’,
!      ‘signed short’, ‘signed int’, ‘signed long’, ‘signed long long’,
!      ‘wint_t’, ‘size_t’, ‘ptrdiff_t’, ‘intmax_t’, ‘uintmax_t’,
!      ‘sig_atomic_t’, ‘int8_t’, ‘int16_t’, ‘int32_t’, ‘int64_t’,
!      ‘uint8_t’, ‘uint16_t’, ‘uint32_t’, ‘uint64_t’, ‘int_least8_t’,
!      ‘int_least16_t’, ‘int_least32_t’, ‘int_least64_t’, ‘uint_least8_t’,
!      ‘uint_least16_t’, ‘uint_least32_t’, ‘uint_least64_t’,
!      ‘int_fast8_t’, ‘int_fast16_t’, ‘int_fast32_t’, ‘int_fast64_t’,
!      ‘uint_fast8_t’, ‘uint_fast16_t’, ‘uint_fast32_t’, ‘uint_fast64_t’,
!      ‘intptr_t’, and ‘uintptr_t’ types and to the minimum value of the
!      ‘wchar_t’, ‘wint_t’, and ‘sig_atomic_t’ types respectively.  They
       exist to make the standard header given numerical limits work
       correctly.  You should not use these macros directly; instead,
       include the appropriate headers.  Some of these macros may not be
!      defined on particular systems if GCC does not provide a ‘stdint.h’
       header on those systems.
  
! ‘__INT8_C’
! ‘__INT16_C’
! ‘__INT32_C’
! ‘__INT64_C’
! ‘__UINT8_C’
! ‘__UINT16_C’
! ‘__UINT32_C’
! ‘__UINT64_C’
! ‘__INTMAX_C’
! ‘__UINTMAX_C’
!      Defined to implementations of the standard ‘stdint.h’ macros with
!      the same names without the leading ‘__’.  They exist the make the
       implementation of that header work correctly.  You should not use
       these macros directly; instead, include the appropriate headers.
       Some of these macros may not be defined on particular systems if
!      GCC does not provide a ‘stdint.h’ header on those systems.
  
! ‘__SCHAR_WIDTH__’
! ‘__SHRT_WIDTH__’
! ‘__INT_WIDTH__’
! ‘__LONG_WIDTH__’
! ‘__LONG_LONG_WIDTH__’
! ‘__PTRDIFF_WIDTH__’
! ‘__SIG_ATOMIC_WIDTH__’
! ‘__SIZE_WIDTH__’
! ‘__WCHAR_WIDTH__’
! ‘__WINT_WIDTH__’
! ‘__INT_LEAST8_WIDTH__’
! ‘__INT_LEAST16_WIDTH__’
! ‘__INT_LEAST32_WIDTH__’
! ‘__INT_LEAST64_WIDTH__’
! ‘__INT_FAST8_WIDTH__’
! ‘__INT_FAST16_WIDTH__’
! ‘__INT_FAST32_WIDTH__’
! ‘__INT_FAST64_WIDTH__’
! ‘__INTPTR_WIDTH__’
! ‘__INTMAX_WIDTH__’
       Defined to the bit widths of the corresponding types.  They exist
!      to make the implementations of ‘limits.h’ and ‘stdint.h’ behave
       correctly.  You should not use these macros directly; instead,
       include the appropriate headers.  Some of these macros may not be
!      defined on particular systems if GCC does not provide a ‘stdint.h’
       header on those systems.
  
! ‘__SIZEOF_INT__’
! ‘__SIZEOF_LONG__’
! ‘__SIZEOF_LONG_LONG__’
! ‘__SIZEOF_SHORT__’
! ‘__SIZEOF_POINTER__’
! ‘__SIZEOF_FLOAT__’
! ‘__SIZEOF_DOUBLE__’
! ‘__SIZEOF_LONG_DOUBLE__’
! ‘__SIZEOF_SIZE_T__’
! ‘__SIZEOF_WCHAR_T__’
! ‘__SIZEOF_WINT_T__’
! ‘__SIZEOF_PTRDIFF_T__’
!      Defined to the number of bytes of the C standard data types: ‘int’,
!      ‘long’, ‘long long’, ‘short’, ‘void *’, ‘float’, ‘double’, ‘long
!      double’, ‘size_t’, ‘wchar_t’, ‘wint_t’ and ‘ptrdiff_t’.
  
! ‘__BYTE_ORDER__’
! ‘__ORDER_LITTLE_ENDIAN__’
! ‘__ORDER_BIG_ENDIAN__’
! ‘__ORDER_PDP_ENDIAN__’
!      ‘__BYTE_ORDER__’ is defined to one of the values
!      ‘__ORDER_LITTLE_ENDIAN__’, ‘__ORDER_BIG_ENDIAN__’, or
!      ‘__ORDER_PDP_ENDIAN__’ to reflect the layout of multi-byte and
!      multi-word quantities in memory.  If ‘__BYTE_ORDER__’ is equal to
!      ‘__ORDER_LITTLE_ENDIAN__’ or ‘__ORDER_BIG_ENDIAN__’, then
       multi-byte and multi-word quantities are laid out identically: the
       byte (word) at the lowest address is the least significant or most
       significant byte (word) of the quantity, respectively.  If
!      ‘__BYTE_ORDER__’ is equal to ‘__ORDER_PDP_ENDIAN__’, then bytes in
       16-bit words are laid out in a little-endian fashion, whereas the
       16-bit subwords of a 32-bit quantity are laid out in big-endian
       fashion.
*************** double underscores.
*** 2075,2115 ****
            /* Test for a little-endian machine */
            #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
  
! '__FLOAT_WORD_ORDER__'
!      '__FLOAT_WORD_ORDER__' is defined to one of the values
!      '__ORDER_LITTLE_ENDIAN__' or '__ORDER_BIG_ENDIAN__' to reflect the
       layout of the words of multi-word floating-point quantities.
  
! '__DEPRECATED'
       This macro is defined, with value 1, when compiling a C++ source
       file with warnings about deprecated constructs enabled.  These
       warnings are enabled by default, but can be disabled with
!      '-Wno-deprecated'.
  
! '__EXCEPTIONS'
       This macro is defined, with value 1, when compiling a C++ source
!      file with exceptions enabled.  If '-fno-exceptions' is used when
       compiling the file, then this macro is not defined.
  
! '__GXX_RTTI'
       This macro is defined, with value 1, when compiling a C++ source
!      file with runtime type identification enabled.  If '-fno-rtti' is
       used when compiling the file, then this macro is not defined.
  
! '__USING_SJLJ_EXCEPTIONS__'
       This macro is defined, with value 1, if the compiler uses the old
!      mechanism based on 'setjmp' and 'longjmp' for exception handling.
  
! '__GXX_EXPERIMENTAL_CXX0X__'
       This macro is defined when compiling a C++ source file with C++11
       features enabled, i.e., for all C++ language dialects except
!      '-std=c++98' and '-std=gnu++98'.  This macro is obsolete, but can
       be used to detect experimental C++0x features in very old versions
!      of GCC. Since GCC 4.7.0 the '__cplusplus' macro is defined
!      correctly, so most code should test '__cplusplus >= 201103L'
       instead of using this macro.
  
! '__GXX_WEAK__'
       This macro is defined when compiling a C++ source file.  It has the
       value 1 if the compiler will use weak symbols, COMDAT sections, or
       other similar techniques to collapse symbols with "vague linkage"
--- 2075,2115 ----
            /* Test for a little-endian machine */
            #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
  
! ‘__FLOAT_WORD_ORDER__’
!      ‘__FLOAT_WORD_ORDER__’ is defined to one of the values
!      ‘__ORDER_LITTLE_ENDIAN__’ or ‘__ORDER_BIG_ENDIAN__’ to reflect the
       layout of the words of multi-word floating-point quantities.
  
! ‘__DEPRECATED’
       This macro is defined, with value 1, when compiling a C++ source
       file with warnings about deprecated constructs enabled.  These
       warnings are enabled by default, but can be disabled with
!      ‘-Wno-deprecated’.
  
! ‘__EXCEPTIONS’
       This macro is defined, with value 1, when compiling a C++ source
!      file with exceptions enabled.  If ‘-fno-exceptions’ is used when
       compiling the file, then this macro is not defined.
  
! ‘__GXX_RTTI’
       This macro is defined, with value 1, when compiling a C++ source
!      file with runtime type identification enabled.  If ‘-fno-rtti’ is
       used when compiling the file, then this macro is not defined.
  
! ‘__USING_SJLJ_EXCEPTIONS__’
       This macro is defined, with value 1, if the compiler uses the old
!      mechanism based on ‘setjmp’ and ‘longjmp’ for exception handling.
  
! ‘__GXX_EXPERIMENTAL_CXX0X__’
       This macro is defined when compiling a C++ source file with C++11
       features enabled, i.e., for all C++ language dialects except
!      ‘-std=c++98’ and ‘-std=gnu++98’.  This macro is obsolete, but can
       be used to detect experimental C++0x features in very old versions
!      of GCC. Since GCC 4.7.0 the ‘__cplusplus’ macro is defined
!      correctly, so most code should test ‘__cplusplus >= 201103L’
       instead of using this macro.
  
! ‘__GXX_WEAK__’
       This macro is defined when compiling a C++ source file.  It has the
       value 1 if the compiler will use weak symbols, COMDAT sections, or
       other similar techniques to collapse symbols with "vague linkage"
*************** double underscores.
*** 2119,2218 ****
       the purpose of this macro is to ease implementation of the C++
       runtime library provided with G++.
  
! '__NEXT_RUNTIME__'
       This macro is defined, with value 1, if (and only if) the NeXT
!      runtime (as in '-fnext-runtime') is in use for Objective-C.  If the
       GNU runtime is used, this macro is not defined, so that you can use
       this macro to determine which runtime (NeXT or GNU) is being used.
  
! '__LP64__'
! '_LP64'
       These macros are defined, with value 1, if (and only if) the
!      compilation is for a target where 'long int' and pointer both use
!      64-bits and 'int' uses 32-bit.
  
! '__SSP__'
!      This macro is defined, with value 1, when '-fstack-protector' is in
       use.
  
! '__SSP_ALL__'
!      This macro is defined, with value 2, when '-fstack-protector-all'
       is in use.
  
! '__SSP_STRONG__'
       This macro is defined, with value 3, when
!      '-fstack-protector-strong' is in use.
  
! '__SSP_EXPLICIT__'
       This macro is defined, with value 4, when
!      '-fstack-protector-explicit' is in use.
  
! '__SANITIZE_ADDRESS__'
!      This macro is defined, with value 1, when '-fsanitize=address' or
!      '-fsanitize=kernel-address' are in use.
  
! '__SANITIZE_THREAD__'
!      This macro is defined, with value 1, when '-fsanitize=thread' is in
       use.
  
! '__TIMESTAMP__'
       This macro expands to a string constant that describes the date and
       time of the last modification of the current source file.  The
       string constant contains abbreviated day of the week, month, day of
       the month, time in hh:mm:ss form, year and looks like
!      '"Sun Sep 16 01:03:52 1973"'.  If the day of the month is less than
       10, it is padded with a space on the left.
  
       If GCC cannot determine the current date, it will emit a warning
!      message (once per compilation) and '__TIMESTAMP__' will expand to
!      '"??? ??? ?? ??:??:?? ????"'.
  
! '__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1'
! '__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2'
! '__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4'
! '__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8'
! '__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16'
       These macros are defined when the target processor supports atomic
       compare and swap operations on operands 1, 2, 4, 8 or 16 bytes in
       length, respectively.
  
! '__HAVE_SPECULATION_SAFE_VALUE'
       This macro is defined with the value 1 to show that this version of
!      GCC supports '__builtin_speculation_safe_value'.
  
! '__GCC_HAVE_DWARF2_CFI_ASM'
       This macro is defined when the compiler is emitting DWARF CFI
       directives to the assembler.  When this is defined, it is possible
       to emit those same directives in inline assembly.
  
! '__FP_FAST_FMA'
! '__FP_FAST_FMAF'
! '__FP_FAST_FMAL'
       These macros are defined with value 1 if the backend supports the
!      'fma', 'fmaf', and 'fmal' builtin functions, so that the include
!      file 'math.h' can define the macros 'FP_FAST_FMA', 'FP_FAST_FMAF',
!      and 'FP_FAST_FMAL' for compatibility with the 1999 C standard.
  
! '__FP_FAST_FMAF16'
! '__FP_FAST_FMAF32'
! '__FP_FAST_FMAF64'
! '__FP_FAST_FMAF128'
! '__FP_FAST_FMAF32X'
! '__FP_FAST_FMAF64X'
! '__FP_FAST_FMAF128X'
       These macros are defined with the value 1 if the backend supports
!      the 'fma' functions using the additional '_FloatN' and '_FloatNx'
       types that are defined in ISO/IEC TS 18661-3:2015.  The include
!      file 'math.h' can define the 'FP_FAST_FMAFN' and 'FP_FAST_FMAFNx'
!      macros if the user defined '__STDC_WANT_IEC_60559_TYPES_EXT__'
!      before including 'math.h'.
  
! '__GCC_IEC_559'
       This macro is defined to indicate the intended level of support for
       IEEE 754 (IEC 60559) floating-point arithmetic.  It expands to a
       nonnegative integer value.  If 0, it indicates that the combination
       of the compiler configuration and the command-line options is not
!      intended to support IEEE 754 arithmetic for 'float' and 'double' as
       defined in C99 and C11 Annex F (for example, that the standard
       rounding modes and exceptions are not supported, or that
       optimizations are enabled that conflict with IEEE 754 semantics).
--- 2119,2218 ----
       the purpose of this macro is to ease implementation of the C++
       runtime library provided with G++.
  
! ‘__NEXT_RUNTIME__’
       This macro is defined, with value 1, if (and only if) the NeXT
!      runtime (as in ‘-fnext-runtime’) is in use for Objective-C.  If the
       GNU runtime is used, this macro is not defined, so that you can use
       this macro to determine which runtime (NeXT or GNU) is being used.
  
! ‘__LP64__’
! ‘_LP64’
       These macros are defined, with value 1, if (and only if) the
!      compilation is for a target where ‘long int’ and pointer both use
!      64-bits and ‘int’ uses 32-bit.
  
! ‘__SSP__’
!      This macro is defined, with value 1, when ‘-fstack-protector’ is in
       use.
  
! ‘__SSP_ALL__’
!      This macro is defined, with value 2, when ‘-fstack-protector-all’
       is in use.
  
! ‘__SSP_STRONG__’
       This macro is defined, with value 3, when
!      ‘-fstack-protector-strong’ is in use.
  
! ‘__SSP_EXPLICIT__’
       This macro is defined, with value 4, when
!      ‘-fstack-protector-explicit’ is in use.
  
! ‘__SANITIZE_ADDRESS__’
!      This macro is defined, with value 1, when ‘-fsanitize=address’ or
!      ‘-fsanitize=kernel-address’ are in use.
  
! ‘__SANITIZE_THREAD__’
!      This macro is defined, with value 1, when ‘-fsanitize=thread’ is in
       use.
  
! ‘__TIMESTAMP__’
       This macro expands to a string constant that describes the date and
       time of the last modification of the current source file.  The
       string constant contains abbreviated day of the week, month, day of
       the month, time in hh:mm:ss form, year and looks like
!      ‘"Sun Sep 16 01:03:52 1973"’.  If the day of the month is less than
       10, it is padded with a space on the left.
  
       If GCC cannot determine the current date, it will emit a warning
!      message (once per compilation) and ‘__TIMESTAMP__’ will expand to
!      ‘"??? ??? ?? ??:??:?? ????"’.
  
! ‘__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1’
! ‘__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2’
! ‘__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4’
! ‘__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8’
! ‘__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16’
       These macros are defined when the target processor supports atomic
       compare and swap operations on operands 1, 2, 4, 8 or 16 bytes in
       length, respectively.
  
! ‘__HAVE_SPECULATION_SAFE_VALUE’
       This macro is defined with the value 1 to show that this version of
!      GCC supports ‘__builtin_speculation_safe_value’.
  
! ‘__GCC_HAVE_DWARF2_CFI_ASM’
       This macro is defined when the compiler is emitting DWARF CFI
       directives to the assembler.  When this is defined, it is possible
       to emit those same directives in inline assembly.
  
! ‘__FP_FAST_FMA’
! ‘__FP_FAST_FMAF’
! ‘__FP_FAST_FMAL’
       These macros are defined with value 1 if the backend supports the
!      ‘fma’, ‘fmaf’, and ‘fmal’ builtin functions, so that the include
!      file ‘math.h’ can define the macros ‘FP_FAST_FMA’, ‘FP_FAST_FMAF’,
!      and ‘FP_FAST_FMAL’ for compatibility with the 1999 C standard.
  
! ‘__FP_FAST_FMAF16’
! ‘__FP_FAST_FMAF32’
! ‘__FP_FAST_FMAF64’
! ‘__FP_FAST_FMAF128’
! ‘__FP_FAST_FMAF32X’
! ‘__FP_FAST_FMAF64X’
! ‘__FP_FAST_FMAF128X’
       These macros are defined with the value 1 if the backend supports
!      the ‘fma’ functions using the additional ‘_FloatN’ and ‘_FloatNx’
       types that are defined in ISO/IEC TS 18661-3:2015.  The include
!      file ‘math.h’ can define the ‘FP_FAST_FMAFN’ and ‘FP_FAST_FMAFNx’
!      macros if the user defined ‘__STDC_WANT_IEC_60559_TYPES_EXT__’
!      before including ‘math.h’.
  
! ‘__GCC_IEC_559’
       This macro is defined to indicate the intended level of support for
       IEEE 754 (IEC 60559) floating-point arithmetic.  It expands to a
       nonnegative integer value.  If 0, it indicates that the combination
       of the compiler configuration and the command-line options is not
!      intended to support IEEE 754 arithmetic for ‘float’ and ‘double’ as
       defined in C99 and C11 Annex F (for example, that the standard
       rounding modes and exceptions are not supported, or that
       optimizations are enabled that conflict with IEEE 754 semantics).
*************** double underscores.
*** 2227,2276 ****
       controlled by standard pragmas, where those standards do not
       require a particular default state.  It does not indicate whether
       optimizations respect signaling NaN semantics (the macro for that
!      is '__SUPPORT_SNAN__').  It does not indicate support for decimal
       floating point or the IEEE 754 binary16 and binary128 types.
  
! '__GCC_IEC_559_COMPLEX'
       This macro is defined to indicate the intended level of support for
       IEEE 754 (IEC 60559) floating-point arithmetic for complex numbers,
       as defined in C99 and C11 Annex G. It expands to a nonnegative
       integer value.  If 0, it indicates that the combination of the
       compiler configuration and the command-line options is not intended
       to support Annex G requirements (for example, because
!      '-fcx-limited-range' was used).  If 1 or more, it indicates that it
       is intended to support those requirements; this does not mean that
       all relevant language features are supported by GCC.
  
! '__NO_MATH_ERRNO__'
!      This macro is defined if '-fno-math-errno' is used, or enabled by
!      another option such as '-ffast-math' or by default.
  
! '__RECIPROCAL_MATH__'
!      This macro is defined if '-freciprocal-math' is used, or enabled by
!      another option such as '-ffast-math' or by default.
  
! '__NO_SIGNED_ZEROS__'
!      This macro is defined if '-fno-signed-zeros' is used, or enabled by
!      another option such as '-ffast-math' or by default.
  
! '__NO_TRAPPING_MATH__'
!      This macro is defined if '-fno-trapping-math' is used.
  
! '__ASSOCIATIVE_MATH__'
!      This macro is defined if '-fassociative-math' is used, or enabled
!      by another option such as '-ffast-math' or by default.
  
! '__ROUNDING_MATH__'
!      This macro is defined if '-frounding-math' is used.
  
! '__GNUC_EXECUTION_CHARSET_NAME'
! '__GNUC_WIDE_EXECUTION_CHARSET_NAME'
       These macros are defined to expand to a narrow string literal of
       the name of the narrow and wide compile-time execution character
       set used.  It directly reflects the name passed to the options
!      '-fexec-charset' and '-fwide-exec-charset', or the defaults
       documented for those options (that is, it can expand to something
!      like '"UTF-8"').  *Note Invocation::.
  
  
  File: cpp.info,  Node: System-specific Predefined Macros,  Next: C++ Named Operators,  Prev: Common Predefined Macros,  Up: Predefined Macros
--- 2227,2276 ----
       controlled by standard pragmas, where those standards do not
       require a particular default state.  It does not indicate whether
       optimizations respect signaling NaN semantics (the macro for that
!      is ‘__SUPPORT_SNAN__’).  It does not indicate support for decimal
       floating point or the IEEE 754 binary16 and binary128 types.
  
! ‘__GCC_IEC_559_COMPLEX’
       This macro is defined to indicate the intended level of support for
       IEEE 754 (IEC 60559) floating-point arithmetic for complex numbers,
       as defined in C99 and C11 Annex G. It expands to a nonnegative
       integer value.  If 0, it indicates that the combination of the
       compiler configuration and the command-line options is not intended
       to support Annex G requirements (for example, because
!      ‘-fcx-limited-range’ was used).  If 1 or more, it indicates that it
       is intended to support those requirements; this does not mean that
       all relevant language features are supported by GCC.
  
! ‘__NO_MATH_ERRNO__’
!      This macro is defined if ‘-fno-math-errno’ is used, or enabled by
!      another option such as ‘-ffast-math’ or by default.
  
! ‘__RECIPROCAL_MATH__’
!      This macro is defined if ‘-freciprocal-math’ is used, or enabled by
!      another option such as ‘-ffast-math’ or by default.
  
! ‘__NO_SIGNED_ZEROS__’
!      This macro is defined if ‘-fno-signed-zeros’ is used, or enabled by
!      another option such as ‘-ffast-math’ or by default.
  
! ‘__NO_TRAPPING_MATH__’
!      This macro is defined if ‘-fno-trapping-math’ is used.
  
! ‘__ASSOCIATIVE_MATH__’
!      This macro is defined if ‘-fassociative-math’ is used, or enabled
!      by another option such as ‘-ffast-math’ or by default.
  
! ‘__ROUNDING_MATH__’
!      This macro is defined if ‘-frounding-math’ is used.
  
! ‘__GNUC_EXECUTION_CHARSET_NAME’
! ‘__GNUC_WIDE_EXECUTION_CHARSET_NAME’
       These macros are defined to expand to a narrow string literal of
       the name of the narrow and wide compile-time execution character
       set used.  It directly reflects the name passed to the options
!      ‘-fexec-charset’ and ‘-fwide-exec-charset’, or the defaults
       documented for those options (that is, it can expand to something
!      like ‘"UTF-8"’).  *Note Invocation::.
  
  
  File: cpp.info,  Node: System-specific Predefined Macros,  Next: C++ Named Operators,  Prev: Common Predefined Macros,  Up: Predefined Macros
*************** File: cpp.info,  Node: System-specific P
*** 2281,2303 ****
  The C preprocessor normally predefines several macros that indicate what
  type of system and machine is in use.  They are obviously different on
  each target supported by GCC.  This manual, being for all systems and
! machines, cannot tell you what their names are, but you can use 'cpp
! -dM' to see them all.  *Note Invocation::.  All system-specific
  predefined macros expand to a constant value, so you can test them with
! either '#ifdef' or '#if'.
  
     The C standard requires that all system-specific macros be part of
! the "reserved namespace".  All names which begin with two underscores,
  or an underscore and a capital letter, are reserved for the compiler and
  library to use as they wish.  However, historically system-specific
  macros have had names with no special prefix; for instance, it is common
! to find 'unix' defined on Unix systems.  For all such macros, GCC
  provides a parallel macro with two underscores added at the beginning
! and the end.  If 'unix' is defined, '__unix__' will be defined too.
! There will never be more than two underscores; the parallel of '_mips'
! is '__mips__'.
  
!    When the '-ansi' option, or any '-std' option that requests strict
  conformance, is given to the compiler, all the system-specific
  predefined macros outside the reserved namespace are suppressed.  The
  parallel macros, inside the reserved namespace, remain defined.
--- 2281,2303 ----
  The C preprocessor normally predefines several macros that indicate what
  type of system and machine is in use.  They are obviously different on
  each target supported by GCC.  This manual, being for all systems and
! machines, cannot tell you what their names are, but you can use ‘cpp
! -dM’ to see them all.  *Note Invocation::.  All system-specific
  predefined macros expand to a constant value, so you can test them with
! either ‘#ifdef’ or ‘#if’.
  
     The C standard requires that all system-specific macros be part of
! the “reserved namespace”.  All names which begin with two underscores,
  or an underscore and a capital letter, are reserved for the compiler and
  library to use as they wish.  However, historically system-specific
  macros have had names with no special prefix; for instance, it is common
! to find ‘unix’ defined on Unix systems.  For all such macros, GCC
  provides a parallel macro with two underscores added at the beginning
! and the end.  If ‘unix’ is defined, ‘__unix__’ will be defined too.
! There will never be more than two underscores; the parallel of ‘_mips’
! is ‘__mips__’.
  
!    When the ‘-ansi’ option, or any ‘-std’ option that requests strict
  conformance, is given to the compiler, all the system-specific
  predefined macros outside the reserved namespace are suppressed.  The
  parallel macros, inside the reserved namespace, remain defined.
*************** encourage you to correct older code to u
*** 2308,2314 ****
  you find it.  We don't recommend you use the system-specific macros that
  are in the reserved namespace, either.  It is better in the long run to
  check specifically for features you need, using a tool such as
! 'autoconf'.
  
  
  File: cpp.info,  Node: C++ Named Operators,  Prev: System-specific Predefined Macros,  Up: Predefined Macros
--- 2308,2314 ----
  you find it.  We don't recommend you use the system-specific macros that
  are in the reserved namespace, either.  It is better in the long run to
  check specifically for features you need, using a tool such as
! ‘autoconf’.
  
  
  File: cpp.info,  Node: C++ Named Operators,  Prev: System-specific Predefined Macros,  Up: Predefined Macros
*************** File: cpp.info,  Node: C++ Named Operato
*** 2319,2343 ****
  In C++, there are eleven keywords which are simply alternate spellings
  of operators normally written with punctuation.  These keywords are
  treated as such even in the preprocessor.  They function as operators in
! '#if', and they cannot be defined as macros or poisoned.  In C, you can
  request that those keywords take their C++ meaning by including
! 'iso646.h'.  That header defines each one as a normal object-like macro
  expanding to the appropriate punctuator.
  
     These are the named operators and their corresponding punctuators:
  
  Named Operator   Punctuator
! 'and'            '&&'
! 'and_eq'         '&='
! 'bitand'         '&'
! 'bitor'          '|'
! 'compl'          '~'
! 'not'            '!'
! 'not_eq'         '!='
! 'or'             '||'
! 'or_eq'          '|='
! 'xor'            '^'
! 'xor_eq'         '^='
  
  
  File: cpp.info,  Node: Undefining and Redefining Macros,  Next: Directives Within Macro Arguments,  Prev: Predefined Macros,  Up: Macros
--- 2319,2343 ----
  In C++, there are eleven keywords which are simply alternate spellings
  of operators normally written with punctuation.  These keywords are
  treated as such even in the preprocessor.  They function as operators in
! ‘#if’, and they cannot be defined as macros or poisoned.  In C, you can
  request that those keywords take their C++ meaning by including
! ‘iso646.h’.  That header defines each one as a normal object-like macro
  expanding to the appropriate punctuator.
  
     These are the named operators and their corresponding punctuators:
  
  Named Operator   Punctuator
! ‘and’            ‘&&’
! ‘and_eq’         ‘&=’
! ‘bitand’         ‘&’
! ‘bitor’          ‘|’
! ‘compl’          ‘~’
! ‘not’            ‘!’
! ‘not_eq’         ‘!=’
! ‘or’             ‘||’
! ‘or_eq’          ‘|=’
! ‘xor’            ‘^’
! ‘xor_eq’         ‘^=’
  
  
  File: cpp.info,  Node: Undefining and Redefining Macros,  Next: Directives Within Macro Arguments,  Prev: Predefined Macros,  Up: Macros
*************** File: cpp.info,  Node: Undefining and Re
*** 2345,2372 ****
  3.8 Undefining and Redefining Macros
  ====================================
  
! If a macro ceases to be useful, it may be "undefined" with the '#undef'
! directive.  '#undef' takes a single argument, the name of the macro to
  undefine.  You use the bare macro name, even if the macro is
  function-like.  It is an error if anything appears on the line after the
! macro name.  '#undef' has no effect if the name is not a macro.
  
       #define FOO 4
!      x = FOO;        ==> x = 4;
       #undef FOO
!      x = FOO;        ==> x = FOO;
  
!    Once a macro has been undefined, that identifier may be "redefined"
! as a macro by a subsequent '#define' directive.  The new definition need
  not have any resemblance to the old definition.
  
     However, if an identifier which is currently a macro is redefined,
! then the new definition must be "effectively the same" as the old one.
  Two macro definitions are effectively the same if:
!    * Both are the same type of macro (object- or function-like).
!    * All the tokens of the replacement list are the same.
!    * If there are any parameters, they are the same.
!    * Whitespace appears in the same places in both.  It need not be
       exactly the same amount of whitespace, though.  Remember that
       comments count as whitespace.
  
--- 2345,2372 ----
  3.8 Undefining and Redefining Macros
  ====================================
  
! If a macro ceases to be useful, it may be “undefined” with the ‘#undef’
! directive.  ‘#undef’ takes a single argument, the name of the macro to
  undefine.  You use the bare macro name, even if the macro is
  function-like.  It is an error if anything appears on the line after the
! macro name.  ‘#undef’ has no effect if the name is not a macro.
  
       #define FOO 4
!      x = FOO;        ↦ x = 4;
       #undef FOO
!      x = FOO;        ↦ x = FOO;
  
!    Once a macro has been undefined, that identifier may be “redefined”
! as a macro by a subsequent ‘#define’ directive.  The new definition need
  not have any resemblance to the old definition.
  
     However, if an identifier which is currently a macro is redefined,
! then the new definition must be “effectively the same” as the old one.
  Two macro definitions are effectively the same if:
!    • Both are the same type of macro (object- or function-like).
!    • All the tokens of the replacement list are the same.
!    • If there are any parameters, they are the same.
!    • Whitespace appears in the same places in both.  It need not be
       exactly the same amount of whitespace, though.  Remember that
       comments count as whitespace.
  
*************** arguments.  For example,
*** 2451,2458 ****
       #define twice(x) (2*(x))
       #define call_with_1(x) x(1)
       call_with_1 (twice)
!           ==> twice(1)
!           ==> (2*(1))
  
     Macro definitions do not have to have balanced parentheses.  By
  writing an unbalanced open parenthesis in a macro body, it is possible
--- 2451,2458 ----
       #define twice(x) (2*(x))
       #define call_with_1(x) x(1)
       call_with_1 (twice)
!           ↦ twice(1)
!           ↦ (2*(1))
  
     Macro definitions do not have to have balanced parentheses.  By
  writing an unbalanced open parenthesis in a macro body, it is possible
*************** outside of it.  For example,
*** 2462,2468 ****
       #define strange(file) fprintf (file, "%s %d",
       ...
       strange(stderr) p, 35)
!           ==> fprintf (stderr, "%s %d", p, 35)
  
     The ability to piece together a macro call can be useful, but the use
  of unbalanced open parentheses in a macro body is just confusing, and
--- 2462,2468 ----
       #define strange(file) fprintf (file, "%s %d",
       ...
       strange(stderr) p, 35)
!           ↦ fprintf (stderr, "%s %d", p, 35)
  
     The ability to piece together a macro call can be useful, but the use
  of unbalanced open parentheses in a macro body is just confusing, and
*************** way.
*** 2485,2495 ****
       #define ceil_div(x, y) (x + y - 1) / y
  
  whose purpose is to divide, rounding up.  (One use for this operation is
! to compute how many 'int' objects are needed to hold a certain number of
! 'char' objects.)  Then suppose it is used as follows:
  
       a = ceil_div (b & c, sizeof (int));
!           ==> a = (b & c + sizeof (int) - 1) / sizeof (int);
  
  This does not do what is intended.  The operator-precedence rules of C
  make it equivalent to this:
--- 2485,2495 ----
       #define ceil_div(x, y) (x + y - 1) / y
  
  whose purpose is to divide, rounding up.  (One use for this operation is
! to compute how many ‘int’ objects are needed to hold a certain number of
! ‘char’ objects.)  Then suppose it is used as follows:
  
       a = ceil_div (b & c, sizeof (int));
!           ↦ a = (b & c + sizeof (int) - 1) / sizeof (int);
  
  This does not do what is intended.  The operator-precedence rules of C
  make it equivalent to this:
*************** Defining the macro as
*** 2506,2524 ****
  
  provides the desired result.
  
!    Unintended grouping can result in another way.  Consider 'sizeof
! ceil_div(1, 2)'.  That has the appearance of a C expression that would
! compute the size of the type of 'ceil_div (1, 2)', but in fact it means
  something very different.  Here is what it expands to:
  
       sizeof ((1) + (2) - 1) / (2)
  
  This would take the size of an integer and divide it by two.  The
! precedence rules have put the division outside the 'sizeof' when it was
  intended to be inside.
  
     Parentheses around the entire macro definition prevent such problems.
! Here, then, is the recommended way to define 'ceil_div':
  
       #define ceil_div(x, y) (((x) + (y) - 1) / (y))
  
--- 2506,2524 ----
  
  provides the desired result.
  
!    Unintended grouping can result in another way.  Consider ‘sizeof
! ceil_div(1, 2)’.  That has the appearance of a C expression that would
! compute the size of the type of ‘ceil_div (1, 2)’, but in fact it means
  something very different.  Here is what it expands to:
  
       sizeof ((1) + (2) - 1) / (2)
  
  This would take the size of an integer and divide it by two.  The
! precedence rules have put the division outside the ‘sizeof’ when it was
  intended to be inside.
  
     Parentheses around the entire macro definition prevent such problems.
! Here, then, is the recommended way to define ‘ceil_div’:
  
       #define ceil_div(x, y) (((x) + (y) - 1) / (y))
  
*************** File: cpp.info,  Node: Swallowing the Se
*** 2530,2536 ****
  
  Often it is desirable to define a macro that expands into a compound
  statement.  Consider, for example, the following macro, that advances a
! pointer (the argument 'p' says where to find it) across whitespace
  characters:
  
       #define SKIP_SPACES(p, limit)  \
--- 2530,2536 ----
  
  Often it is desirable to define a macro that expands into a compound
  statement.  Consider, for example, the following macro, that advances a
! pointer (the argument ‘p’ says where to find it) across whitespace
  characters:
  
       #define SKIP_SPACES(p, limit)  \
*************** Here backslash-newline is used to split
*** 2543,2556 ****
  be a single logical line, so that it resembles the way such code would
  be laid out if not part of a macro definition.
  
!    A call to this macro might be 'SKIP_SPACES (p, lim)'.  Strictly
  speaking, the call expands to a compound statement, which is a complete
  statement with no need for a semicolon to end it.  However, since it
  looks like a function call, it minimizes confusion if you can use it
! like a function call, writing a semicolon afterward, as in 'SKIP_SPACES
! (p, lim);'
  
!    This can cause trouble before 'else' statements, because the
  semicolon is actually a null statement.  Suppose you write
  
       if (*p != 0)
--- 2543,2556 ----
  be a single logical line, so that it resembles the way such code would
  be laid out if not part of a macro definition.
  
!    A call to this macro might be ‘SKIP_SPACES (p, lim)’.  Strictly
  speaking, the call expands to a compound statement, which is a complete
  statement with no need for a semicolon to end it.  However, since it
  looks like a function call, it minimizes confusion if you can use it
! like a function call, writing a semicolon afterward, as in ‘SKIP_SPACES
! (p, lim);’
  
!    This can cause trouble before ‘else’ statements, because the
  semicolon is actually a null statement.  Suppose you write
  
       if (*p != 0)
*************** semicolon is actually a null statement.
*** 2558,2568 ****
       else ...
  
  The presence of two statements--the compound statement and a null
! statement--in between the 'if' condition and the 'else' makes invalid C
  code.
  
!    The definition of the macro 'SKIP_SPACES' can be altered to solve
! this problem, using a 'do ... while' statement.  Here is how:
  
       #define SKIP_SPACES(p, limit)     \
       do { char *lim = (limit);         \
--- 2558,2568 ----
       else ...
  
  The presence of two statements--the compound statement and a null
! statement--in between the ‘if’ condition and the ‘else’ makes invalid C
  code.
  
!    The definition of the macro ‘SKIP_SPACES’ can be altered to solve
! this problem, using a ‘do ... while’ statement.  Here is how:
  
       #define SKIP_SPACES(p, limit)     \
       do { char *lim = (limit);         \
*************** this problem, using a 'do ... while' sta
*** 2571,2577 ****
                p--; break; }}}          \
       while (0)
  
!    Now 'SKIP_SPACES (p, lim);' expands into
  
       do {...} while (0);
  
--- 2571,2577 ----
                p--; break; }}}          \
       while (0)
  
!    Now ‘SKIP_SPACES (p, lim);’ expands into
  
       do {...} while (0);
  
*************** File: cpp.info,  Node: Duplication of Si
*** 2584,2590 ****
  3.10.4 Duplication of Side Effects
  ----------------------------------
  
! Many C programs define a macro 'min', for "minimum", like this:
  
       #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
  
--- 2584,2590 ----
  3.10.4 Duplication of Side Effects
  ----------------------------------
  
! Many C programs define a macro ‘min’, for "minimum", like this:
  
       #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
  
*************** it expands as follows:
*** 2597,2613 ****
  
       next = ((x + y) < (foo (z)) ? (x + y) : (foo (z)));
  
! where 'x + y' has been substituted for 'X' and 'foo (z)' for 'Y'.
  
!    The function 'foo' is used only once in the statement as it appears
! in the program, but the expression 'foo (z)' has been substituted twice
! into the macro expansion.  As a result, 'foo' might be called two times
  when the statement is executed.  If it has side effects or if it takes a
  long time to compute, the results might not be what you intended.  We
! say that 'min' is an "unsafe" macro.
  
!    The best solution to this problem is to define 'min' in a way that
! computes the value of 'foo (z)' only once.  The C language offers no
  standard way to do this, but it can be done with GNU extensions as
  follows:
  
--- 2597,2613 ----
  
       next = ((x + y) < (foo (z)) ? (x + y) : (foo (z)));
  
! where ‘x + y’ has been substituted for ‘X’ and ‘foo (z)’ for ‘Y’.
  
!    The function ‘foo’ is used only once in the statement as it appears
! in the program, but the expression ‘foo (z)’ has been substituted twice
! into the macro expansion.  As a result, ‘foo’ might be called two times
  when the statement is executed.  If it has side effects or if it takes a
  long time to compute, the results might not be what you intended.  We
! say that ‘min’ is an “unsafe” macro.
  
!    The best solution to this problem is to define ‘min’ in a way that
! computes the value of ‘foo (z)’ only once.  The C language offers no
  standard way to do this, but it can be done with GNU extensions as
  follows:
  
*************** follows:
*** 2616,2622 ****
          typeof (Y) y_ = (Y);          \
          (x_ < y_) ? x_ : y_; })
  
!    The '({ ... })' notation produces a compound statement that acts as
  an expression.  Its value is the value of its last statement.  This
  permits us to define local variables and assign each argument to one.
  The local variables have underscores after their names to reduce the
--- 2616,2622 ----
          typeof (Y) y_ = (Y);          \
          (x_ < y_) ? x_ : y_; })
  
!    The ‘({ ... })’ notation produces a compound statement that acts as
  an expression.  Its value is the value of its last statement.  This
  permits us to define local variables and assign each argument to one.
  The local variables have underscores after their names to reduce the
*************** risk of conflict with an identifier of w
*** 2624,2632 ****
  avoid this entirely).  Now each argument is evaluated exactly once.
  
     If you do not wish to use GNU C extensions, the only solution is to
! be careful when _using_ the macro 'min'.  For example, you can calculate
! the value of 'foo (z)', save it in a variable, and use that variable in
! 'min':
  
       #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
       ...
--- 2624,2632 ----
  avoid this entirely).  Now each argument is evaluated exactly once.
  
     If you do not wish to use GNU C extensions, the only solution is to
! be careful when _using_ the macro ‘min’.  For example, you can calculate
! the value of ‘foo (z)’, save it in a variable, and use that variable in
! ‘min’:
  
       #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
       ...
*************** the value of 'foo (z)', save it in a var
*** 2635,2641 ****
         next = min (x + y, tem);
       }
  
! (where we assume that 'foo' returns type 'int').
  
  
  File: cpp.info,  Node: Self-Referential Macros,  Next: Argument Prescan,  Prev: Duplication of Side Effects,  Up: Macro Pitfalls
--- 2635,2641 ----
         next = min (x + y, tem);
       }
  
! (where we assume that ‘foo’ returns type ‘int’).
  
  
  File: cpp.info,  Node: Self-Referential Macros,  Next: Argument Prescan,  Prev: Duplication of Side Effects,  Up: Macro Pitfalls
*************** File: cpp.info,  Node: Self-Referential
*** 2643,2649 ****
  3.10.5 Self-Referential Macros
  ------------------------------
  
! A "self-referential" macro is one whose name appears in its definition.
  Recall that all macro definitions are rescanned for more macros to
  replace.  If the self-reference were considered a use of the macro, it
  would produce an infinitely large expansion.  To prevent this, the
--- 2643,2649 ----
  3.10.5 Self-Referential Macros
  ------------------------------
  
! A “self-referential” macro is one whose name appears in its definition.
  Recall that all macro definitions are rescanned for more macros to
  replace.  If the self-reference were considered a use of the macro, it
  would produce an infinitely large expansion.  To prevent this, the
*************** preprocessor output unchanged.  Consider
*** 2652,2699 ****
  
       #define foo (4 + foo)
  
! where 'foo' is also a variable in your program.
  
!    Following the ordinary rules, each reference to 'foo' will expand
! into '(4 + foo)'; then this will be rescanned and will expand into '(4 +
! (4 + foo))'; and so on until the computer runs out of memory.
  
     The self-reference rule cuts this process short after one step, at
! '(4 + foo)'.  Therefore, this macro definition has the possibly useful
! effect of causing the program to add 4 to the value of 'foo' wherever
! 'foo' is referred to.
  
     In most cases, it is a bad idea to take advantage of this feature.  A
! person reading the program who sees that 'foo' is a variable will not
  expect that it is a macro as well.  The reader will come across the
! identifier 'foo' in the program and think its value should be that of
! the variable 'foo', whereas in fact the value is four greater.
  
     One common, useful use of self-reference is to create a macro which
  expands to itself.  If you write
  
       #define EPERM EPERM
  
! then the macro 'EPERM' expands to 'EPERM'.  Effectively, it is left
  alone by the preprocessor whenever it's used in running text.  You can
! tell that it's a macro with '#ifdef'.  You might do this if you want to
! define numeric constants with an 'enum', but have '#ifdef' be true for
  each constant.
  
!    If a macro 'x' expands to use a macro 'y', and the expansion of 'y'
! refers to the macro 'x', that is an "indirect self-reference" of 'x'.
! 'x' is not expanded in this case either.  Thus, if we have
  
       #define x (4 + y)
       #define y (2 * x)
  
! then 'x' and 'y' expand as follows:
  
!      x    ==> (4 + y)
!           ==> (4 + (2 * x))
  
!      y    ==> (2 * x)
!           ==> (2 * (4 + y))
  
  Each macro is expanded when it appears in the definition of the other
  macro, but not when it indirectly appears in its own definition.
--- 2652,2699 ----
  
       #define foo (4 + foo)
  
! where ‘foo’ is also a variable in your program.
  
!    Following the ordinary rules, each reference to ‘foo’ will expand
! into ‘(4 + foo)’; then this will be rescanned and will expand into ‘(4 +
! (4 + foo))’; and so on until the computer runs out of memory.
  
     The self-reference rule cuts this process short after one step, at
! ‘(4 + foo)’.  Therefore, this macro definition has the possibly useful
! effect of causing the program to add 4 to the value of ‘foo’ wherever
! ‘foo’ is referred to.
  
     In most cases, it is a bad idea to take advantage of this feature.  A
! person reading the program who sees that ‘foo’ is a variable will not
  expect that it is a macro as well.  The reader will come across the
! identifier ‘foo’ in the program and think its value should be that of
! the variable ‘foo’, whereas in fact the value is four greater.
  
     One common, useful use of self-reference is to create a macro which
  expands to itself.  If you write
  
       #define EPERM EPERM
  
! then the macro ‘EPERM’ expands to ‘EPERM’.  Effectively, it is left
  alone by the preprocessor whenever it's used in running text.  You can
! tell that it's a macro with ‘#ifdef’.  You might do this if you want to
! define numeric constants with an ‘enum’, but have ‘#ifdef’ be true for
  each constant.
  
!    If a macro ‘x’ expands to use a macro ‘y’, and the expansion of ‘y’
! refers to the macro ‘x’, that is an “indirect self-reference” of ‘x’.
! ‘x’ is not expanded in this case either.  Thus, if we have
  
       #define x (4 + y)
       #define y (2 * x)
  
! then ‘x’ and ‘y’ expand as follows:
  
!      x    ↦ (4 + y)
!           ↦ (4 + (2 * x))
  
!      y    ↦ (2 * x)
!           ↦ (2 * (4 + y))
  
  Each macro is expanded when it appears in the definition of the other
  macro, but not when it indirectly appears in its own definition.
*************** difference?  And why not skip it and mak
*** 2731,2749 ****
  answer is that the prescan does make a difference in three special
  cases:
  
!    * Nested calls to a macro.
  
!      We say that "nested" calls to a macro occur when a macro's argument
!      contains a call to that very macro.  For example, if 'f' is a macro
!      that expects one argument, 'f (f (1))' is a nested pair of calls to
!      'f'.  The desired expansion is made by expanding 'f (1)' and
!      substituting that into the definition of 'f'.  The prescan causes
!      the expected result to happen.  Without the prescan, 'f (1)' itself
!      would be substituted as an argument, and the inner use of 'f' would
       appear during the main scan as an indirect self-reference and would
       not be expanded.
  
!    * Macros that call other macros that stringize or concatenate.
  
       If an argument is stringized or concatenated, the prescan does not
       occur.  If you _want_ to expand a macro, then stringize or
--- 2731,2749 ----
  answer is that the prescan does make a difference in three special
  cases:
  
!    • Nested calls to a macro.
  
!      We say that “nested” calls to a macro occur when a macro's argument
!      contains a call to that very macro.  For example, if ‘f’ is a macro
!      that expects one argument, ‘f (f (1))’ is a nested pair of calls to
!      ‘f’.  The desired expansion is made by expanding ‘f (1)’ and
!      substituting that into the definition of ‘f’.  The prescan causes
!      the expected result to happen.  Without the prescan, ‘f (1)’ itself
!      would be substituted as an argument, and the inner use of ‘f’ would
       appear during the main scan as an indirect self-reference and would
       not be expanded.
  
!    • Macros that call other macros that stringize or concatenate.
  
       If an argument is stringized or concatenated, the prescan does not
       occur.  If you _want_ to expand a macro, then stringize or
*************** cases:
*** 2756,2766 ****
            #define TABLESIZE 1024
            #define BUFSIZE TABLESIZE
  
!      then 'AFTERX(BUFSIZE)' expands to 'X_BUFSIZE', and
!      'XAFTERX(BUFSIZE)' expands to 'X_1024'.  (Not to 'X_TABLESIZE'.
       Prescan always does a complete expansion.)
  
!    * Macros used in arguments, whose expansions contain unshielded
       commas.
  
       This can cause a macro expanded on the second scan to be called
--- 2756,2766 ----
            #define TABLESIZE 1024
            #define BUFSIZE TABLESIZE
  
!      then ‘AFTERX(BUFSIZE)’ expands to ‘X_BUFSIZE’, and
!      ‘XAFTERX(BUFSIZE)’ expands to ‘X_1024’.  (Not to ‘X_TABLESIZE’.
       Prescan always does a complete expansion.)
  
!    • Macros used in arguments, whose expansions contain unshielded
       commas.
  
       This can cause a macro expanded on the second scan to be called
*************** cases:
*** 2770,2778 ****
            #define bar(x) lose(x)
            #define lose(x) (1 + (x))
  
!      We would like 'bar(foo)' to turn into '(1 + (foo))', which would
!      then turn into '(1 + (a,b))'.  Instead, 'bar(foo)' expands into
!      'lose(a,b)', and you get an error because 'lose' requires a single
       argument.  In this case, the problem is easily solved by the same
       parentheses that ought to be used to prevent misnesting of
       arithmetic operations:
--- 2770,2778 ----
            #define bar(x) lose(x)
            #define lose(x) (1 + (x))
  
!      We would like ‘bar(foo)’ to turn into ‘(1 + (foo))’, which would
!      then turn into ‘(1 + (a,b))’.  Instead, ‘bar(foo)’ expands into
!      ‘lose(a,b)’, and you get an error because ‘lose’ requires a single
       argument.  In this case, the problem is easily solved by the same
       parentheses that ought to be used to prevent misnesting of
       arithmetic operations:
*************** cases:
*** 2781,2787 ****
       or
            #define bar(x) lose((x))
  
!      The extra pair of parentheses prevents the comma in 'foo''s
       definition from being interpreted as an argument separator.
  
  
--- 2781,2787 ----
       or
            #define bar(x) lose((x))
  
!      The extra pair of parentheses prevents the comma in ‘foo’'s
       definition from being interpreted as an argument separator.
  
  
*************** different to the line containing the arg
*** 2804,2810 ****
                          ignored (),
                          syntax error);
  
! The syntax error triggered by the tokens 'syntax error' results in an
  error message citing line three--the line of ignore_second_arg-- even
  though the problematic code comes from line five.
  
--- 2804,2810 ----
                          ignored (),
                          syntax error);
  
! The syntax error triggered by the tokens ‘syntax error’ results in an
  error message citing line three--the line of ignore_second_arg-- even
  though the problematic code comes from line five.
  
*************** File: cpp.info,  Node: Conditionals,  Ne
*** 2816,2830 ****
  4 Conditionals
  **************
  
! A "conditional" is a directive that instructs the preprocessor to select
  whether or not to include a chunk of code in the final token stream
  passed to the compiler.  Preprocessor conditionals can test arithmetic
  expressions, or whether a name is defined as a macro, or both
! simultaneously using the special 'defined' operator.
  
!    A conditional in the C preprocessor resembles in some ways an 'if'
  statement in C, but it is important to understand the difference between
! them.  The condition in an 'if' statement is tested during the execution
  of your program.  Its purpose is to allow your program to behave
  differently from run to run, depending on the data it is operating on.
  The condition in a preprocessing conditional directive is tested when
--- 2816,2830 ----
  4 Conditionals
  **************
  
! A “conditional” is a directive that instructs the preprocessor to select
  whether or not to include a chunk of code in the final token stream
  passed to the compiler.  Preprocessor conditionals can test arithmetic
  expressions, or whether a name is defined as a macro, or both
! simultaneously using the special ‘defined’ operator.
  
!    A conditional in the C preprocessor resembles in some ways an ‘if’
  statement in C, but it is important to understand the difference between
! them.  The condition in an ‘if’ statement is tested during the execution
  of your program.  Its purpose is to allow your program to behave
  differently from run to run, depending on the data it is operating on.
  The condition in a preprocessing conditional directive is tested when
*************** included in the program depending on the
*** 2833,2842 ****
  compilation.
  
     However, the distinction is becoming less clear.  Modern compilers
! often do test 'if' statements when a program is compiled, if their
  conditions are known not to vary at run time, and eliminate code which
  can never be executed.  If you can count on your compiler to do this,
! you may find that your program is more readable if you use 'if'
  statements with constant conditions (perhaps determined by macros).  Of
  course, you can only use this to exclude code, not type definitions or
  other preprocessing directives, and you can only do it if the code
--- 2833,2842 ----
  compilation.
  
     However, the distinction is becoming less clear.  Modern compilers
! often do test ‘if’ statements when a program is compiled, if their
  conditions are known not to vary at run time, and eliminate code which
  can never be executed.  If you can count on your compiler to do this,
! you may find that your program is more readable if you use ‘if’
  statements with constant conditions (perhaps determined by macros).  Of
  course, you can only use this to exclude code, not type definitions or
  other preprocessing directives, and you can only do it if the code
*************** File: cpp.info,  Node: Conditional Uses,
*** 2856,2862 ****
  
  There are three general reasons to use a conditional.
  
!    * A program may need to use different code depending on the machine
       or operating system it is to run on.  In some cases the code for
       one operating system may be erroneous on another operating system;
       for example, it might refer to data types or constants that do not
--- 2856,2862 ----
  
  There are three general reasons to use a conditional.
  
!    • A program may need to use different code depending on the machine
       or operating system it is to run on.  In some cases the code for
       one operating system may be erroneous on another operating system;
       for example, it might refer to data types or constants that do not
*************** There are three general reasons to use a
*** 2866,2877 ****
       the offending code can be effectively excised from the program when
       it is not valid.
  
!    * You may want to be able to compile the same source file into two
       different programs.  One version might make frequent time-consuming
       consistency checks on its intermediate data, or print the values of
       those data for debugging, and the other not.
  
!    * A conditional whose condition is always false is one way to exclude
       code from the program but keep it as a sort of comment for future
       reference.
  
--- 2866,2877 ----
       the offending code can be effectively excised from the program when
       it is not valid.
  
!    • You may want to be able to compile the same source file into two
       different programs.  One version might make frequent time-consuming
       consistency checks on its intermediate data, or print the values of
       those data for debugging, and the other not.
  
!    • A conditional whose condition is always false is one way to exclude
       code from the program but keep it as a sort of comment for future
       reference.
  
*************** File: cpp.info,  Node: Conditional Synta
*** 2885,2892 ****
  4.2 Conditional Syntax
  ======================
  
! A conditional in the C preprocessor begins with a "conditional
! directive": '#if', '#ifdef' or '#ifndef'.
  
  * Menu:
  
--- 2885,2892 ----
  4.2 Conditional Syntax
  ======================
  
! A conditional in the C preprocessor begins with a “conditional
! directive”: ‘#if’, ‘#ifdef’ or ‘#ifndef’.
  
  * Menu:
  
*************** The simplest sort of conditional is
*** 2915,2930 ****
  
       #endif /* MACRO */
  
!    This block is called a "conditional group".  CONTROLLED TEXT will be
  included in the output of the preprocessor if and only if MACRO is
! defined.  We say that the conditional "succeeds" if MACRO is defined,
! "fails" if it is not.
  
     The CONTROLLED TEXT inside of a conditional can include preprocessing
  directives.  They are executed only if the conditional succeeds.  You
  can nest conditional groups inside other conditional groups, but they
! must be completely nested.  In other words, '#endif' always matches the
! nearest '#ifdef' (or '#ifndef', or '#if').  Also, you cannot start a
  conditional group in one file and end it in another.
  
     Even if a conditional fails, the CONTROLLED TEXT inside it is still
--- 2915,2930 ----
  
       #endif /* MACRO */
  
!    This block is called a “conditional group”.  CONTROLLED TEXT will be
  included in the output of the preprocessor if and only if MACRO is
! defined.  We say that the conditional “succeeds” if MACRO is defined,
! “fails” if it is not.
  
     The CONTROLLED TEXT inside of a conditional can include preprocessing
  directives.  They are executed only if the conditional succeeds.  You
  can nest conditional groups inside other conditional groups, but they
! must be completely nested.  In other words, ‘#endif’ always matches the
! nearest ‘#ifdef’ (or ‘#ifndef’, or ‘#if’).  Also, you cannot start a
  conditional group in one file and end it in another.
  
     Even if a conditional fails, the CONTROLLED TEXT inside it is still
*************** must all be lexically valid C.  Normally
*** 2933,2964 ****
  that all comments and string literals inside a failing conditional group
  must still be properly ended.
  
!    The comment following the '#endif' is not required, but it is a good
  practice if there is a lot of CONTROLLED TEXT, because it helps people
! match the '#endif' to the corresponding '#ifdef'.  Older programs
! sometimes put MACRO directly after the '#endif' without enclosing it in
  a comment.  This is invalid code according to the C standard.  CPP
! accepts it with a warning.  It never affects which '#ifndef' the
! '#endif' matches.
  
     Sometimes you wish to use some code if a macro is _not_ defined.  You
! can do this by writing '#ifndef' instead of '#ifdef'.  One common use of
! '#ifndef' is to include code only the first time a header file is
  included.  *Note Once-Only Headers::.
  
     Macro definitions can vary between compilations for several reasons.
  Here are some samples.
  
!    * Some macros are predefined on each kind of machine (*note
       System-specific Predefined Macros::).  This allows you to provide
       code specially tuned for a particular machine.
  
!    * System header files define more macros, associated with the
       features they implement.  You can test these macros with
       conditionals to avoid using a system feature on a machine where it
       is not implemented.
  
!    * Macros can be defined or undefined with the '-D' and '-U'
       command-line options when you compile the program.  You can arrange
       to compile the same source file into two different programs by
       choosing a macro name to specify which program you want, writing
--- 2933,2964 ----
  that all comments and string literals inside a failing conditional group
  must still be properly ended.
  
!    The comment following the ‘#endif’ is not required, but it is a good
  practice if there is a lot of CONTROLLED TEXT, because it helps people
! match the ‘#endif’ to the corresponding ‘#ifdef’.  Older programs
! sometimes put MACRO directly after the ‘#endif’ without enclosing it in
  a comment.  This is invalid code according to the C standard.  CPP
! accepts it with a warning.  It never affects which ‘#ifndef’ the
! ‘#endif’ matches.
  
     Sometimes you wish to use some code if a macro is _not_ defined.  You
! can do this by writing ‘#ifndef’ instead of ‘#ifdef’.  One common use of
! ‘#ifndef’ is to include code only the first time a header file is
  included.  *Note Once-Only Headers::.
  
     Macro definitions can vary between compilations for several reasons.
  Here are some samples.
  
!    • Some macros are predefined on each kind of machine (*note
       System-specific Predefined Macros::).  This allows you to provide
       code specially tuned for a particular machine.
  
!    • System header files define more macros, associated with the
       features they implement.  You can test these macros with
       conditionals to avoid using a system feature on a machine where it
       is not implemented.
  
!    • Macros can be defined or undefined with the ‘-D’ and ‘-U’
       command-line options when you compile the program.  You can arrange
       to compile the same source file into two different programs by
       choosing a macro name to specify which program you want, writing
*************** Here are some samples.
*** 2966,2976 ****
       controlling the state of the macro with command-line options,
       perhaps set in the Makefile.  *Note Invocation::.
  
!    * Your program might have a special header file (often called
!      'config.h') that is adjusted when the program is compiled.  It can
       define or not define macros depending on the features of the system
       and the desired capabilities of the program.  The adjustment can be
!      automated by a tool such as 'autoconf', or done by hand.
  
  
  File: cpp.info,  Node: If,  Next: Defined,  Prev: Ifdef,  Up: Conditional Syntax
--- 2966,2976 ----
       controlling the state of the macro with command-line options,
       perhaps set in the Makefile.  *Note Invocation::.
  
!    • Your program might have a special header file (often called
!      ‘config.h’) that is adjusted when the program is compiled.  It can
       define or not define macros depending on the features of the system
       and the desired capabilities of the program.  The adjustment can be
!      automated by a tool such as ‘autoconf’, or done by hand.
  
  
  File: cpp.info,  Node: If,  Next: Defined,  Prev: Ifdef,  Up: Conditional Syntax
*************** File: cpp.info,  Node: If,  Next: Define
*** 2978,2984 ****
  4.2.2 If
  --------
  
! The '#if' directive allows you to test the value of an arithmetic
  expression, rather than the mere existence of one macro.  Its syntax is
  
       #if EXPRESSION
--- 2978,2984 ----
  4.2.2 If
  --------
  
! The ‘#if’ directive allows you to test the value of an arithmetic
  expression, rather than the mere existence of one macro.  Its syntax is
  
       #if EXPRESSION
*************** expression, rather than the mere existen
*** 2990,3025 ****
     EXPRESSION is a C expression of integer type, subject to stringent
  restrictions.  It may contain
  
!    * Integer constants.
  
!    * Character constants, which are interpreted as they would be in
       normal code.
  
!    * Arithmetic operators for addition, subtraction, multiplication,
       division, bitwise operations, shifts, comparisons, and logical
!      operations ('&&' and '||').  The latter two obey the usual
       short-circuiting rules of standard C.
  
!    * Macros.  All macros in the expression are expanded before actual
       computation of the expression's value begins.
  
!    * Uses of the 'defined' operator, which lets you check whether macros
!      are defined in the middle of an '#if'.
  
!    * Identifiers that are not macros, which are all considered to be the
!      number zero.  This allows you to write '#if MACRO' instead of
!      '#ifdef MACRO', if you know that MACRO, when defined, will always
       have a nonzero value.  Function-like macros used without their
       function call parentheses are also treated as zero.
  
!      In some contexts this shortcut is undesirable.  The '-Wundef'
       option causes GCC to warn whenever it encounters an identifier
!      which is not a macro in an '#if'.
  
     The preprocessor does not know anything about types in the language.
! Therefore, 'sizeof' operators are not recognized in '#if', and neither
! are 'enum' constants.  They will be taken as identifiers which are not
! macros, and replaced by zero.  In the case of 'sizeof', this is likely
  to cause the expression to be invalid.
  
     The preprocessor calculates the value of EXPRESSION.  It carries out
--- 2990,3025 ----
     EXPRESSION is a C expression of integer type, subject to stringent
  restrictions.  It may contain
  
!    • Integer constants.
  
!    • Character constants, which are interpreted as they would be in
       normal code.
  
!    • Arithmetic operators for addition, subtraction, multiplication,
       division, bitwise operations, shifts, comparisons, and logical
!      operations (‘&&’ and ‘||’).  The latter two obey the usual
       short-circuiting rules of standard C.
  
!    • Macros.  All macros in the expression are expanded before actual
       computation of the expression's value begins.
  
!    • Uses of the ‘defined’ operator, which lets you check whether macros
!      are defined in the middle of an ‘#if’.
  
!    • Identifiers that are not macros, which are all considered to be the
!      number zero.  This allows you to write ‘#if MACRO’ instead of
!      ‘#ifdef MACRO’, if you know that MACRO, when defined, will always
       have a nonzero value.  Function-like macros used without their
       function call parentheses are also treated as zero.
  
!      In some contexts this shortcut is undesirable.  The ‘-Wundef’
       option causes GCC to warn whenever it encounters an identifier
!      which is not a macro in an ‘#if’.
  
     The preprocessor does not know anything about types in the language.
! Therefore, ‘sizeof’ operators are not recognized in ‘#if’, and neither
! are ‘enum’ constants.  They will be taken as identifiers which are not
! macros, and replaced by zero.  In the case of ‘sizeof’, this is likely
  to cause the expression to be invalid.
  
     The preprocessor calculates the value of EXPRESSION.  It carries out
*************** all calculations in the widest integer t
*** 3027,3033 ****
  most machines supported by GCC this is 64 bits.  This is not the same
  rule as the compiler uses to calculate the value of a constant
  expression, and may give different results in some cases.  If the value
! comes out to be nonzero, the '#if' succeeds and the CONTROLLED TEXT is
  included; otherwise it is skipped.
  
  
--- 3027,3033 ----
  most machines supported by GCC this is 64 bits.  This is not the same
  rule as the compiler uses to calculate the value of a constant
  expression, and may give different results in some cases.  If the value
! comes out to be nonzero, the ‘#if’ succeeds and the CONTROLLED TEXT is
  included; otherwise it is skipped.
  
  
*************** File: cpp.info,  Node: Defined,  Next: E
*** 3036,3070 ****
  4.2.3 Defined
  -------------
  
! The special operator 'defined' is used in '#if' and '#elif' expressions
! to test whether a certain name is defined as a macro.  'defined NAME'
! and 'defined (NAME)' are both expressions whose value is 1 if NAME is
  defined as a macro at the current point in the program, and 0 otherwise.
! Thus, '#if defined MACRO' is precisely equivalent to '#ifdef MACRO'.
  
!    'defined' is useful when you wish to test more than one macro for
  existence at once.  For example,
  
       #if defined (__vax__) || defined (__ns16000__)
  
! would succeed if either of the names '__vax__' or '__ns16000__' is
  defined as a macro.
  
     Conditionals written like this:
  
       #if defined BUFSIZE && BUFSIZE >= 1024
  
! can generally be simplified to just '#if BUFSIZE >= 1024', since if
! 'BUFSIZE' is not defined, it will be interpreted as having the value
  zero.
  
!    If the 'defined' operator appears as a result of a macro expansion,
  the C standard says the behavior is undefined.  GNU cpp treats it as a
! genuine 'defined' operator and evaluates it normally.  It will warn
  wherever your code uses this feature if you use the command-line option
! '-Wpedantic', since other compilers may handle it differently.  The
! warning is also enabled by '-Wextra', and can also be enabled
! individually with '-Wexpansion-to-defined'.
  
  
  File: cpp.info,  Node: Else,  Next: Elif,  Prev: Defined,  Up: Conditional Syntax
--- 3036,3070 ----
  4.2.3 Defined
  -------------
  
! The special operator ‘defined’ is used in ‘#if’ and ‘#elif’ expressions
! to test whether a certain name is defined as a macro.  ‘defined NAME’
! and ‘defined (NAME)’ are both expressions whose value is 1 if NAME is
  defined as a macro at the current point in the program, and 0 otherwise.
! Thus, ‘#if defined MACRO’ is precisely equivalent to ‘#ifdef MACRO’.
  
!    ‘defined’ is useful when you wish to test more than one macro for
  existence at once.  For example,
  
       #if defined (__vax__) || defined (__ns16000__)
  
! would succeed if either of the names ‘__vax__’ or ‘__ns16000__’ is
  defined as a macro.
  
     Conditionals written like this:
  
       #if defined BUFSIZE && BUFSIZE >= 1024
  
! can generally be simplified to just ‘#if BUFSIZE >= 1024’, since if
! ‘BUFSIZE’ is not defined, it will be interpreted as having the value
  zero.
  
!    If the ‘defined’ operator appears as a result of a macro expansion,
  the C standard says the behavior is undefined.  GNU cpp treats it as a
! genuine ‘defined’ operator and evaluates it normally.  It will warn
  wherever your code uses this feature if you use the command-line option
! ‘-Wpedantic’, since other compilers may handle it differently.  The
! warning is also enabled by ‘-Wextra’, and can also be enabled
! individually with ‘-Wexpansion-to-defined’.
  
  
  File: cpp.info,  Node: Else,  Next: Elif,  Prev: Defined,  Up: Conditional Syntax
*************** File: cpp.info,  Node: Else,  Next: Elif
*** 3072,3078 ****
  4.2.4 Else
  ----------
  
! The '#else' directive can be added to a conditional to provide
  alternative text to be used if the condition fails.  This is what it
  looks like:
  
--- 3072,3078 ----
  4.2.4 Else
  ----------
  
! The ‘#else’ directive can be added to a conditional to provide
  alternative text to be used if the condition fails.  This is what it
  looks like:
  
*************** looks like:
*** 3085,3091 ****
  If EXPRESSION is nonzero, the TEXT-IF-TRUE is included and the
  TEXT-IF-FALSE is skipped.  If EXPRESSION is zero, the opposite happens.
  
!    You can use '#else' with '#ifdef' and '#ifndef', too.
  
  
  File: cpp.info,  Node: Elif,  Next: __has_attribute,  Prev: Else,  Up: Conditional Syntax
--- 3085,3091 ----
  If EXPRESSION is nonzero, the TEXT-IF-TRUE is included and the
  TEXT-IF-FALSE is skipped.  If EXPRESSION is zero, the opposite happens.
  
!    You can use ‘#else’ with ‘#ifdef’ and ‘#ifndef’, too.
  
  
  File: cpp.info,  Node: Elif,  Next: __has_attribute,  Prev: Else,  Up: Conditional Syntax
*************** two possible alternatives.  For example,
*** 3106,3112 ****
       #endif /* X != 2 */
       #endif /* X != 1 */
  
!    Another conditional directive, '#elif', allows this to be abbreviated
  as follows:
  
       #if X == 1
--- 3106,3112 ----
       #endif /* X != 2 */
       #endif /* X != 1 */
  
!    Another conditional directive, ‘#elif’, allows this to be abbreviated
  as follows:
  
       #if X == 1
*************** as follows:
*** 3117,3152 ****
       ...
       #endif /* X != 2 and X != 1*/
  
!    '#elif' stands for "else if".  Like '#else', it goes in the middle of
  a conditional group and subdivides it; it does not require a matching
! '#endif' of its own.  Like '#if', the '#elif' directive includes an
! expression to be tested.  The text following the '#elif' is processed
! only if the original '#if'-condition failed and the '#elif' condition
  succeeds.
  
!    More than one '#elif' can go in the same conditional group.  Then the
! text after each '#elif' is processed only if the '#elif' condition
! succeeds after the original '#if' and all previous '#elif' directives
  within it have failed.
  
!    '#else' is allowed after any number of '#elif' directives, but
! '#elif' may not follow '#else'.
  
  
  File: cpp.info,  Node: __has_attribute,  Next: __has_cpp_attribute,  Prev: Elif,  Up: Conditional Syntax
  
! 4.2.6 '__has_attribute'
  -----------------------
  
! The special operator '__has_attribute (OPERAND)' may be used in '#if'
! and '#elif' expressions to test whether the attribute referenced by its
  OPERAND is recognized by GCC. Using the operator in other contexts is
  not valid.  In C code, if compiling for strict conformance to standards
  before C2x, OPERAND must be a valid identifier.  Otherwise, OPERAND may
! be optionally introduced by the 'ATTRIBUTE-SCOPE::' prefix.  The
  ATTRIBUTE-SCOPE prefix identifies the "namespace" within which the
! attribute is recognized.  The scope of GCC attributes is 'gnu' or
! '__gnu__'.  The '__has_attribute' operator by itself, without any
  OPERAND or parentheses, acts as a predefined macro so that support for
  it can be tested in portable code.  Thus, the recommended use of the
  operator is as follows:
--- 3117,3152 ----
       ...
       #endif /* X != 2 and X != 1*/
  
!    ‘#elif’ stands for "else if".  Like ‘#else’, it goes in the middle of
  a conditional group and subdivides it; it does not require a matching
! ‘#endif’ of its own.  Like ‘#if’, the ‘#elif’ directive includes an
! expression to be tested.  The text following the ‘#elif’ is processed
! only if the original ‘#if’-condition failed and the ‘#elif’ condition
  succeeds.
  
!    More than one ‘#elif’ can go in the same conditional group.  Then the
! text after each ‘#elif’ is processed only if the ‘#elif’ condition
! succeeds after the original ‘#if’ and all previous ‘#elif’ directives
  within it have failed.
  
!    ‘#else’ is allowed after any number of ‘#elif’ directives, but
! ‘#elif’ may not follow ‘#else’.
  
  
  File: cpp.info,  Node: __has_attribute,  Next: __has_cpp_attribute,  Prev: Elif,  Up: Conditional Syntax
  
! 4.2.6 ‘__has_attribute’
  -----------------------
  
! The special operator ‘__has_attribute (OPERAND)’ may be used in ‘#if’
! and ‘#elif’ expressions to test whether the attribute referenced by its
  OPERAND is recognized by GCC. Using the operator in other contexts is
  not valid.  In C code, if compiling for strict conformance to standards
  before C2x, OPERAND must be a valid identifier.  Otherwise, OPERAND may
! be optionally introduced by the ‘ATTRIBUTE-SCOPE::’ prefix.  The
  ATTRIBUTE-SCOPE prefix identifies the "namespace" within which the
! attribute is recognized.  The scope of GCC attributes is ‘gnu’ or
! ‘__gnu__’.  The ‘__has_attribute’ operator by itself, without any
  OPERAND or parentheses, acts as a predefined macro so that support for
  it can be tested in portable code.  Thus, the recommended use of the
  operator is as follows:
*************** operator is as follows:
*** 3157,3165 ****
       #  endif
       #endif
  
!    The first '#if' test succeeds only when the operator is supported by
  the version of GCC (or another compiler) being used.  Only when that
! test succeeds is it valid to use '__has_attribute' as a preprocessor
  operator.  As a result, combining the two tests into a single expression
  as shown below would only be valid with a compiler that supports the
  operator but not with others that don't.
--- 3157,3165 ----
       #  endif
       #endif
  
!    The first ‘#if’ test succeeds only when the operator is supported by
  the version of GCC (or another compiler) being used.  Only when that
! test succeeds is it valid to use ‘__has_attribute’ as a preprocessor
  operator.  As a result, combining the two tests into a single expression
  as shown below would only be valid with a compiler that supports the
  operator but not with others that don't.
*************** operator but not with others that don't.
*** 3171,3185 ****
  
  File: cpp.info,  Node: __has_cpp_attribute,  Next: __has_c_attribute,  Prev: __has_attribute,  Up: Conditional Syntax
  
! 4.2.7 '__has_cpp_attribute'
  ---------------------------
  
! The special operator '__has_cpp_attribute (OPERAND)' may be used in
! '#if' and '#elif' expressions in C++ code to test whether the attribute
! referenced by its OPERAND is recognized by GCC. '__has_cpp_attribute
! (OPERAND)' is equivalent to '__has_attribute (OPERAND)' except that when
  OPERAND designates a supported standard attribute it evaluates to an
! integer constant of the form 'YYYYMM' indicating the year and month when
  the attribute was first introduced into the C++ standard.  For
  additional information including the dates of the introduction of
  current standard attributes, see
--- 3171,3185 ----
  
  File: cpp.info,  Node: __has_cpp_attribute,  Next: __has_c_attribute,  Prev: __has_attribute,  Up: Conditional Syntax
  
! 4.2.7 ‘__has_cpp_attribute’
  ---------------------------
  
! The special operator ‘__has_cpp_attribute (OPERAND)’ may be used in
! ‘#if’ and ‘#elif’ expressions in C++ code to test whether the attribute
! referenced by its OPERAND is recognized by GCC. ‘__has_cpp_attribute
! (OPERAND)’ is equivalent to ‘__has_attribute (OPERAND)’ except that when
  OPERAND designates a supported standard attribute it evaluates to an
! integer constant of the form ‘YYYYMM’ indicating the year and month when
  the attribute was first introduced into the C++ standard.  For
  additional information including the dates of the introduction of
  current standard attributes, see
*************** SD-6: SG10 Feature Test Recommendations
*** 3188,3220 ****
  
  File: cpp.info,  Node: __has_c_attribute,  Next: __has_builtin,  Prev: __has_cpp_attribute,  Up: Conditional Syntax
  
! 4.2.8 '__has_c_attribute'
  -------------------------
  
! The special operator '__has_c_attribute (OPERAND)' may be used in '#if'
! and '#elif' expressions in C code to test whether the attribute
  referenced by its OPERAND is recognized by GCC in attributes using the
! '[[]]' syntax.  GNU attributes must be specified with the scope 'gnu' or
! '__gnu__' with '__has_c_attribute'.  When OPERAND designates a supported
  standard attribute it evaluates to an integer constant of the form
! 'YYYYMM' indicating the year and month when the attribute was first
  introduced into the C standard, or when the syntax of operands to the
  attribute was extended in the C standard.
  
  
  File: cpp.info,  Node: __has_builtin,  Next: __has_include,  Prev: __has_c_attribute,  Up: Conditional Syntax
  
! 4.2.9 '__has_builtin'
  ---------------------
  
! The special operator '__has_builtin (OPERAND)' may be used in constant
! integer contexts and in preprocessor '#if' and '#elif' expressions to
  test whether the symbol named by its OPERAND is recognized as a built-in
  function by GCC in the current language and conformance mode.  It
  evaluates to a constant integer with a nonzero value if the argument
  refers to such a function, and to zero otherwise.  The operator may also
! be used in preprocessor '#if' and '#elif' expressions.  The
! '__has_builtin' operator by itself, without any OPERAND or parentheses,
  acts as a predefined macro so that support for it can be tested in
  portable code.  Thus, the recommended use of the operator is as follows:
  
--- 3188,3220 ----
  
  File: cpp.info,  Node: __has_c_attribute,  Next: __has_builtin,  Prev: __has_cpp_attribute,  Up: Conditional Syntax
  
! 4.2.8 ‘__has_c_attribute’
  -------------------------
  
! The special operator ‘__has_c_attribute (OPERAND)’ may be used in ‘#if’
! and ‘#elif’ expressions in C code to test whether the attribute
  referenced by its OPERAND is recognized by GCC in attributes using the
! ‘[[]]’ syntax.  GNU attributes must be specified with the scope ‘gnu’ or
! ‘__gnu__’ with ‘__has_c_attribute’.  When OPERAND designates a supported
  standard attribute it evaluates to an integer constant of the form
! ‘YYYYMM’ indicating the year and month when the attribute was first
  introduced into the C standard, or when the syntax of operands to the
  attribute was extended in the C standard.
  
  
  File: cpp.info,  Node: __has_builtin,  Next: __has_include,  Prev: __has_c_attribute,  Up: Conditional Syntax
  
! 4.2.9 ‘__has_builtin’
  ---------------------
  
! The special operator ‘__has_builtin (OPERAND)’ may be used in constant
! integer contexts and in preprocessor ‘#if’ and ‘#elif’ expressions to
  test whether the symbol named by its OPERAND is recognized as a built-in
  function by GCC in the current language and conformance mode.  It
  evaluates to a constant integer with a nonzero value if the argument
  refers to such a function, and to zero otherwise.  The operator may also
! be used in preprocessor ‘#if’ and ‘#elif’ expressions.  The
! ‘__has_builtin’ operator by itself, without any OPERAND or parentheses,
  acts as a predefined macro so that support for it can be tested in
  portable code.  Thus, the recommended use of the operator is as follows:
  
*************** portable code.  Thus, the recommended us
*** 3230,3249 ****
  
  File: cpp.info,  Node: __has_include,  Prev: __has_builtin,  Up: Conditional Syntax
  
! 4.2.10 '__has_include'
  ----------------------
  
! The special operator '__has_include (OPERAND)' may be used in '#if' and
! '#elif' expressions to test whether the header referenced by its OPERAND
! can be included using the '#include' directive.  Using the operator in
  other contexts is not valid.  The OPERAND takes the same form as the
! file in the '#include' directive (*note Include Syntax::) and evaluates
  to a nonzero value if the header can be included and to zero otherwise.
  Note that that the ability to include a header doesn't imply that the
! header doesn't contain invalid constructs or '#error' directives that
  would cause the preprocessor to fail.
  
!    The '__has_include' operator by itself, without any OPERAND or
  parentheses, acts as a predefined macro so that support for it can be
  tested in portable code.  Thus, the recommended use of the operator is
  as follows:
--- 3230,3249 ----
  
  File: cpp.info,  Node: __has_include,  Prev: __has_builtin,  Up: Conditional Syntax
  
! 4.2.10 ‘__has_include’
  ----------------------
  
! The special operator ‘__has_include (OPERAND)’ may be used in ‘#if’ and
! ‘#elif’ expressions to test whether the header referenced by its OPERAND
! can be included using the ‘#include’ directive.  Using the operator in
  other contexts is not valid.  The OPERAND takes the same form as the
! file in the ‘#include’ directive (*note Include Syntax::) and evaluates
  to a nonzero value if the header can be included and to zero otherwise.
  Note that that the ability to include a header doesn't imply that the
! header doesn't contain invalid constructs or ‘#error’ directives that
  would cause the preprocessor to fail.
  
!    The ‘__has_include’ operator by itself, without any OPERAND or
  parentheses, acts as a predefined macro so that support for it can be
  tested in portable code.  Thus, the recommended use of the operator is
  as follows:
*************** as follows:
*** 3254,3262 ****
       #  endif
       #endif
  
!    The first '#if' test succeeds only when the operator is supported by
  the version of GCC (or another compiler) being used.  Only when that
! test succeeds is it valid to use '__has_include' as a preprocessor
  operator.  As a result, combining the two tests into a single expression
  as shown below would only be valid with a compiler that supports the
  operator but not with others that don't.
--- 3254,3262 ----
       #  endif
       #endif
  
!    The first ‘#if’ test succeeds only when the operator is supported by
  the version of GCC (or another compiler) being used.  Only when that
! test succeeds is it valid to use ‘__has_include’ as a preprocessor
  operator.  As a result, combining the two tests into a single expression
  as shown below would only be valid with a compiler that supports the
  operator but not with others that don't.
*************** code will end the commenting-out.  The p
*** 3278,3297 ****
  syntax errors.
  
     One way to avoid this problem is to use an always-false conditional
! instead.  For instance, put '#if 0' before the deleted code and '#endif'
  after it.  This works even if the code being turned off contains
! conditionals, but they must be entire conditionals (balanced '#if' and
! '#endif').
  
!    Some people use '#ifdef notdef' instead.  This is risky, because
! 'notdef' might be accidentally defined as a macro, and then the
! conditional would succeed.  '#if 0' can be counted on to fail.
  
!    Do not use '#if 0' for comments which are not C code.  Use a real
! comment, instead.  The interior of '#if 0' must consist of complete
  tokens; in particular, single-quote characters must balance.  Comments
  often contain unbalanced single-quote characters (known in English as
! apostrophes).  These confuse '#if 0'.  They don't confuse '/*'.
  
  
  File: cpp.info,  Node: Diagnostics,  Next: Line Control,  Prev: Conditionals,  Up: Top
--- 3278,3297 ----
  syntax errors.
  
     One way to avoid this problem is to use an always-false conditional
! instead.  For instance, put ‘#if 0’ before the deleted code and ‘#endif’
  after it.  This works even if the code being turned off contains
! conditionals, but they must be entire conditionals (balanced ‘#if’ and
! ‘#endif’).
  
!    Some people use ‘#ifdef notdef’ instead.  This is risky, because
! ‘notdef’ might be accidentally defined as a macro, and then the
! conditional would succeed.  ‘#if 0’ can be counted on to fail.
  
!    Do not use ‘#if 0’ for comments which are not C code.  Use a real
! comment, instead.  The interior of ‘#if 0’ must consist of complete
  tokens; in particular, single-quote characters must balance.  Comments
  often contain unbalanced single-quote characters (known in English as
! apostrophes).  These confuse ‘#if 0’.  They don't confuse ‘/*’.
  
  
  File: cpp.info,  Node: Diagnostics,  Next: Line Control,  Prev: Conditionals,  Up: Top
*************** File: cpp.info,  Node: Diagnostics,  Nex
*** 3299,3309 ****
  5 Diagnostics
  *************
  
! The directive '#error' causes the preprocessor to report a fatal error.
! The tokens forming the rest of the line following '#error' are used as
  the error message.
  
!    You would use '#error' inside of a conditional that detects a
  combination of parameters which you know the program does not properly
  support.  For example, if you know that the program will not run
  properly on a VAX, you might write
--- 3299,3309 ----
  5 Diagnostics
  *************
  
! The directive ‘#error’ causes the preprocessor to report a fatal error.
! The tokens forming the rest of the line following ‘#error’ are used as
  the error message.
  
!    You would use ‘#error’ inside of a conditional that detects a
  combination of parameters which you know the program does not properly
  support.  For example, if you know that the program will not run
  properly on a VAX, you might write
*************** properly on a VAX, you might write
*** 3314,3333 ****
  
     If you have several configuration parameters that must be set up by
  the installation in a consistent way, you can use conditionals to detect
! an inconsistency and report it with '#error'.  For example,
  
       #if !defined(FOO) && defined(BAR)
       #error "BAR requires FOO."
       #endif
  
!    The directive '#warning' is like '#error', but causes the
  preprocessor to issue a warning and continue preprocessing.  The tokens
! following '#warning' are used as the warning message.
  
!    You might use '#warning' in obsolete header files, with a message
  directing the user to the header file which should be used instead.
  
!    Neither '#error' nor '#warning' macro-expands its argument.  Internal
  whitespace sequences are each replaced with a single space.  The line
  must consist of complete tokens.  It is wisest to make the argument of
  these directives be a single string constant; this avoids problems with
--- 3314,3333 ----
  
     If you have several configuration parameters that must be set up by
  the installation in a consistent way, you can use conditionals to detect
! an inconsistency and report it with ‘#error’.  For example,
  
       #if !defined(FOO) && defined(BAR)
       #error "BAR requires FOO."
       #endif
  
!    The directive ‘#warning’ is like ‘#error’, but causes the
  preprocessor to issue a warning and continue preprocessing.  The tokens
! following ‘#warning’ are used as the warning message.
  
!    You might use ‘#warning’ in obsolete header files, with a message
  directing the user to the header file which should be used instead.
  
!    Neither ‘#error’ nor ‘#warning’ macro-expands its argument.  Internal
  whitespace sequences are each replaced with a single space.  The line
  must consist of complete tokens.  It is wisest to make the argument of
  these directives be a single string constant; this avoids problems with
*************** reported as having appeared on the line
*** 3346,3384 ****
  outermost macro was used.  We intend to be more accurate in the future.
  
     If you write a program which generates source code, such as the
! 'bison' parser generator, you may want to adjust the preprocessor's
  notion of the current file name and line number by hand.  Parts of the
! output from 'bison' are generated from scratch, other parts come from a
! standard parser file.  The rest are copied verbatim from 'bison''s
  input.  You would like compiler error messages and symbolic debuggers to
! be able to refer to 'bison''s input file.
  
!    'bison' or any such program can arrange this by writing '#line'
! directives into the output file.  '#line' is a directive that specifies
  the original line number and source file name for subsequent input in
! the current preprocessor input file.  '#line' has three variants:
  
! '#line LINENUM'
       LINENUM is a non-negative decimal integer constant.  It specifies
       the line number which should be reported for the following line of
       input.  Subsequent lines are counted from LINENUM.
  
! '#line LINENUM FILENAME'
       LINENUM is the same as for the first form, and has the same effect.
       In addition, FILENAME is a string constant.  The following line and
       all subsequent lines are reported to come from the file it
       specifies, until something else happens to change that.  FILENAME
       is interpreted according to the normal rules for a string constant:
       backslash escapes are interpreted.  This is different from
!      '#include'.
  
! '#line ANYTHING ELSE'
       ANYTHING ELSE is checked for macro calls, which are expanded.  The
       result should match one of the above two forms.
  
!    '#line' directives alter the results of the '__FILE__' and '__LINE__'
  predefined macros from that point on.  *Note Standard Predefined
! Macros::.  They do not have any effect on '#include''s idea of the
  directory containing the current file.
  
  
--- 3346,3384 ----
  outermost macro was used.  We intend to be more accurate in the future.
  
     If you write a program which generates source code, such as the
! ‘bison’ parser generator, you may want to adjust the preprocessor's
  notion of the current file name and line number by hand.  Parts of the
! output from ‘bison’ are generated from scratch, other parts come from a
! standard parser file.  The rest are copied verbatim from ‘bison’'s
  input.  You would like compiler error messages and symbolic debuggers to
! be able to refer to ‘bison’'s input file.
  
!    ‘bison’ or any such program can arrange this by writing ‘#line’
! directives into the output file.  ‘#line’ is a directive that specifies
  the original line number and source file name for subsequent input in
! the current preprocessor input file.  ‘#line’ has three variants:
  
! ‘#line LINENUM’
       LINENUM is a non-negative decimal integer constant.  It specifies
       the line number which should be reported for the following line of
       input.  Subsequent lines are counted from LINENUM.
  
! ‘#line LINENUM FILENAME’
       LINENUM is the same as for the first form, and has the same effect.
       In addition, FILENAME is a string constant.  The following line and
       all subsequent lines are reported to come from the file it
       specifies, until something else happens to change that.  FILENAME
       is interpreted according to the normal rules for a string constant:
       backslash escapes are interpreted.  This is different from
!      ‘#include’.
  
! ‘#line ANYTHING ELSE’
       ANYTHING ELSE is checked for macro calls, which are expanded.  The
       result should match one of the above two forms.
  
!    ‘#line’ directives alter the results of the ‘__FILE__’ and ‘__LINE__’
  predefined macros from that point on.  *Note Standard Predefined
! Macros::.  They do not have any effect on ‘#include’'s idea of the
  directory containing the current file.
  
  
*************** File: cpp.info,  Node: Pragmas,  Next: O
*** 3387,3422 ****
  7 Pragmas
  *********
  
! The '#pragma' directive is the method specified by the C standard for
  providing additional information to the compiler, beyond what is
  conveyed in the language itself.  The forms of this directive (commonly
! known as "pragmas") specified by C standard are prefixed with 'STDC'.  A
  C compiler is free to attach any meaning it likes to other pragmas.
! Most GNU-defined, supported pragmas have been given a 'GCC' prefix.
  
!    C99 introduced the '_Pragma' operator.  This feature addresses a
! major problem with '#pragma': being a directive, it cannot be produced
! as the result of macro expansion.  '_Pragma' is an operator, much like
! 'sizeof' or 'defined', and can be embedded in a macro.
  
!    Its syntax is '_Pragma (STRING-LITERAL)', where STRING-LITERAL can be
  either a normal or wide-character string literal.  It is destringized,
! by replacing all '\\' with a single '\' and all '\"' with a '"'.  The
  result is then processed as if it had appeared as the right hand side of
! a '#pragma' directive.  For example,
  
       _Pragma ("GCC dependency \"parse.y\"")
  
! has the same effect as '#pragma GCC dependency "parse.y"'.  The same
  effect could be achieved using macros, for example
  
       #define DO_PRAGMA(x) _Pragma (#x)
       DO_PRAGMA (GCC dependency "parse.y")
  
!    The standard is unclear on where a '_Pragma' operator can appear.
  The preprocessor does not accept it within a preprocessing conditional
! directive like '#if'.  To be safe, you are probably best keeping it out
! of directives other than '#define', and putting it on a line of its own.
  
     This manual documents the pragmas which are meaningful to the
  preprocessor itself.  Other pragmas are meaningful to the C or C++
--- 3387,3422 ----
  7 Pragmas
  *********
  
! The ‘#pragma’ directive is the method specified by the C standard for
  providing additional information to the compiler, beyond what is
  conveyed in the language itself.  The forms of this directive (commonly
! known as “pragmas”) specified by C standard are prefixed with ‘STDC’.  A
  C compiler is free to attach any meaning it likes to other pragmas.
! Most GNU-defined, supported pragmas have been given a ‘GCC’ prefix.
  
!    C99 introduced the ‘_Pragma’ operator.  This feature addresses a
! major problem with ‘#pragma’: being a directive, it cannot be produced
! as the result of macro expansion.  ‘_Pragma’ is an operator, much like
! ‘sizeof’ or ‘defined’, and can be embedded in a macro.
  
!    Its syntax is ‘_Pragma (STRING-LITERAL)’, where STRING-LITERAL can be
  either a normal or wide-character string literal.  It is destringized,
! by replacing all ‘\\’ with a single ‘\’ and all ‘\"’ with a ‘"’.  The
  result is then processed as if it had appeared as the right hand side of
! a ‘#pragma’ directive.  For example,
  
       _Pragma ("GCC dependency \"parse.y\"")
  
! has the same effect as ‘#pragma GCC dependency "parse.y"’.  The same
  effect could be achieved using macros, for example
  
       #define DO_PRAGMA(x) _Pragma (#x)
       DO_PRAGMA (GCC dependency "parse.y")
  
!    The standard is unclear on where a ‘_Pragma’ operator can appear.
  The preprocessor does not accept it within a preprocessing conditional
! directive like ‘#if’.  To be safe, you are probably best keeping it out
! of directives other than ‘#define’, and putting it on a line of its own.
  
     This manual documents the pragmas which are meaningful to the
  preprocessor itself.  Other pragmas are meaningful to the C or C++
*************** compilers.  They are documented in the G
*** 3424,3431 ****
  
     GCC plugins may provide their own pragmas.
  
! '#pragma GCC dependency'
!      '#pragma GCC dependency' allows you to check the relative dates of
       the current file and another file.  If the other file is more
       recent than the current file, a warning is issued.  This is useful
       if the current file is derived from the other file, and should be
--- 3424,3431 ----
  
     GCC plugins may provide their own pragmas.
  
! ‘#pragma GCC dependency’
!      ‘#pragma GCC dependency’ allows you to check the relative dates of
       the current file and another file.  If the other file is more
       recent than the current file, a warning is issued.  This is useful
       if the current file is derived from the other file, and should be
*************** compilers.  They are documented in the G
*** 3436,3446 ****
            #pragma GCC dependency "parse.y"
            #pragma GCC dependency "/usr/include/time.h" rerun fixincludes
  
! '#pragma GCC poison'
       Sometimes, there is an identifier that you want to remove
       completely from your program, and make sure that it never creeps
!      back in.  To enforce this, you can "poison" the identifier with
!      this pragma.  '#pragma GCC poison' is followed by a list of
       identifiers to poison.  If any of those identifiers appears
       anywhere in the source after the directive, it is a hard error.
       For example,
--- 3436,3446 ----
            #pragma GCC dependency "parse.y"
            #pragma GCC dependency "/usr/include/time.h" rerun fixincludes
  
! ‘#pragma GCC poison’
       Sometimes, there is an identifier that you want to remove
       completely from your program, and make sure that it never creeps
!      back in.  To enforce this, you can “poison” the identifier with
!      this pragma.  ‘#pragma GCC poison’ is followed by a list of
       identifiers to poison.  If any of those identifiers appears
       anywhere in the source after the directive, it is a hard error.
       For example,
*************** compilers.  They are documented in the G
*** 3463,3490 ****
  
       will not produce an error.
  
! '#pragma GCC system_header'
       This pragma takes no arguments.  It causes the rest of the code in
       the current file to be treated as if it came from a system header.
       *Note System Headers::.
  
! '#pragma GCC warning'
! '#pragma GCC error'
!      '#pragma GCC warning "message"' causes the preprocessor to issue a
!      warning diagnostic with the text 'message'.  The message contained
!      in the pragma must be a single string literal.  Similarly, '#pragma
!      GCC error "message"' issues an error message.  Unlike the
!      '#warning' and '#error' directives, these pragmas can be embedded
!      in preprocessor macros using '_Pragma'.
  
! '#pragma once'
!      If '#pragma once' is seen when scanning a header file, that file
       will never be read again, no matter what.  It is a less-portable
!      alternative to using '#ifndef' to guard the contents of header
       files against multiple inclusions.
  
! '#pragma region {tokens}...'
! '#pragma endregion {tokens}...'
       These pragmas are accepted, but have no effect.
  
  
--- 3463,3490 ----
  
       will not produce an error.
  
! ‘#pragma GCC system_header’
       This pragma takes no arguments.  It causes the rest of the code in
       the current file to be treated as if it came from a system header.
       *Note System Headers::.
  
! ‘#pragma GCC warning’
! ‘#pragma GCC error’
!      ‘#pragma GCC warning "message"’ causes the preprocessor to issue a
!      warning diagnostic with the text ‘message’.  The message contained
!      in the pragma must be a single string literal.  Similarly, ‘#pragma
!      GCC error "message"’ issues an error message.  Unlike the
!      ‘#warning’ and ‘#error’ directives, these pragmas can be embedded
!      in preprocessor macros using ‘_Pragma’.
  
! ‘#pragma once’
!      If ‘#pragma once’ is seen when scanning a header file, that file
       will never be read again, no matter what.  It is a less-portable
!      alternative to using ‘#ifndef’ to guard the contents of header
       files against multiple inclusions.
  
! ‘#pragma region {tokens}...’
! ‘#pragma endregion {tokens}...’
       These pragmas are accepted, but have no effect.
  
  
*************** File: cpp.info,  Node: Other Directives,
*** 3493,3513 ****
  8 Other Directives
  ******************
  
! The '#ident' directive takes one argument, a string constant.  On some
  systems, that string constant is copied into a special segment of the
! object file.  On other systems, the directive is ignored.  The '#sccs'
! directive is a synonym for '#ident'.
  
     These directives are not part of the C standard, but they are not
  official GNU extensions either.  What historical information we have
  been able to find, suggests they originated with System V.
  
!    The "null directive" consists of a '#' followed by a newline, with
  only whitespace (including comments) in between.  A null directive is
  understood as a preprocessing directive but has no effect on the
  preprocessor output.  The primary significance of the existence of the
! null directive is that an input line consisting of just a '#' will
! produce no output, rather than a line of output containing just a '#'.
  Supposedly some old C programs contain such lines.
  
  
--- 3493,3513 ----
  8 Other Directives
  ******************
  
! The ‘#ident’ directive takes one argument, a string constant.  On some
  systems, that string constant is copied into a special segment of the
! object file.  On other systems, the directive is ignored.  The ‘#sccs’
! directive is a synonym for ‘#ident’.
  
     These directives are not part of the C standard, but they are not
  official GNU extensions either.  What historical information we have
  been able to find, suggests they originated with System V.
  
!    The “null directive” consists of a ‘#’ followed by a newline, with
  only whitespace (including comments) in between.  A null directive is
  understood as a preprocessing directive but has no effect on the
  preprocessor output.  The primary significance of the existence of the
! null directive is that an input line consisting of just a ‘#’ will
! produce no output, rather than a line of output containing just a ‘#’.
  Supposedly some old C programs contain such lines.
  
  
*************** the form
*** 3542,3583 ****
  
       # LINENUM FILENAME FLAGS
  
! These are called "linemarkers".  They are inserted as needed into the
  output (but never within a string or character constant).  They mean
  that the following line originated in file FILENAME at line LINENUM.
  FILENAME will never contain any non-printing characters; they are
  replaced with octal escape sequences.
  
!    After the file name comes zero or more flags, which are '1', '2',
! '3', or '4'.  If there are multiple flags, spaces separate them.  Here
  is what the flags mean:
  
! '1'
       This indicates the start of a new file.
! '2'
       This indicates returning to a file (after having included another
       file).
! '3'
       This indicates that the following text comes from a system header
       file, so certain warnings should be suppressed.
! '4'
       This indicates that the following text should be treated as being
!      wrapped in an implicit 'extern "C"' block.
  
     As an extension, the preprocessor accepts linemarkers in
  non-assembler input files.  They are treated like the corresponding
! '#line' directive, (*note Line Control::), except that trailing flags
  are permitted, and are interpreted with the meanings described above.
  If multiple flags are given, they must be in ascending order.
  
     Some directives may be duplicated in the output of the preprocessor.
! These are '#ident' (always), '#pragma' (only if the preprocessor does
! not handle the pragma itself), and '#define' and '#undef' (with certain
! debugging options).  If this happens, the '#' of the directive will
  always be in the first column, and there will be no space between the
! '#' and the directive name.  If macro expansion happens to generate
  tokens which might be mistaken for a duplicated directive, a space will
! be inserted between the '#' and the directive name.
  
  
  File: cpp.info,  Node: Traditional Mode,  Next: Implementation Details,  Prev: Preprocessor Output,  Up: Top
--- 3542,3583 ----
  
       # LINENUM FILENAME FLAGS
  
! These are called “linemarkers”.  They are inserted as needed into the
  output (but never within a string or character constant).  They mean
  that the following line originated in file FILENAME at line LINENUM.
  FILENAME will never contain any non-printing characters; they are
  replaced with octal escape sequences.
  
!    After the file name comes zero or more flags, which are ‘1’, ‘2’,
! ‘3’, or ‘4’.  If there are multiple flags, spaces separate them.  Here
  is what the flags mean:
  
! ‘1’
       This indicates the start of a new file.
! ‘2’
       This indicates returning to a file (after having included another
       file).
! ‘3’
       This indicates that the following text comes from a system header
       file, so certain warnings should be suppressed.
! ‘4’
       This indicates that the following text should be treated as being
!      wrapped in an implicit ‘extern "C"’ block.
  
     As an extension, the preprocessor accepts linemarkers in
  non-assembler input files.  They are treated like the corresponding
! ‘#line’ directive, (*note Line Control::), except that trailing flags
  are permitted, and are interpreted with the meanings described above.
  If multiple flags are given, they must be in ascending order.
  
     Some directives may be duplicated in the output of the preprocessor.
! These are ‘#ident’ (always), ‘#pragma’ (only if the preprocessor does
! not handle the pragma itself), and ‘#define’ and ‘#undef’ (with certain
! debugging options).  If this happens, the ‘#’ of the directive will
  always be in the first column, and there will be no space between the
! ‘#’ and the directive name.  If macro expansion happens to generate
  tokens which might be mistaken for a duplicated directive, a space will
! be inserted between the ‘#’ and the directive name.
  
  
  File: cpp.info,  Node: Traditional Mode,  Next: Implementation Details,  Prev: Preprocessor Output,  Up: Top
*************** File: cpp.info,  Node: Traditional Mode,
*** 3587,3593 ****
  
  Traditional (pre-standard) C preprocessing is rather different from the
  preprocessing specified by the standard.  When the preprocessor is
! invoked with the '-traditional-cpp' option, it attempts to emulate a
  traditional preprocessor.
  
     This mode is not useful for compiling C code with GCC, but is
--- 3587,3593 ----
  
  Traditional (pre-standard) C preprocessing is rather different from the
  preprocessing specified by the standard.  When the preprocessor is
! invoked with the ‘-traditional-cpp’ option, it attempts to emulate a
  traditional preprocessor.
  
     This mode is not useful for compiling C code with GCC, but is
*************** the output.  In particular, hard tabs re
*** 3630,3638 ****
  useful if, for example, you are preprocessing a Makefile.
  
     Traditional CPP only recognizes C-style block comments, and treats
! the '/*' sequence as introducing a comment only if it lies outside
  quoted text.  Quoted text is introduced by the usual single and double
! quotes, and also by an initial '<' in a '#include' directive.
  
     Traditionally, comments are completely removed and are not replaced
  with a space.  Since a traditional compiler does its own tokenization of
--- 3630,3638 ----
  useful if, for example, you are preprocessing a Makefile.
  
     Traditional CPP only recognizes C-style block comments, and treats
! the ‘/*’ sequence as introducing a comment only if it lies outside
  quoted text.  Quoted text is introduced by the usual single and double
! quotes, and also by an initial ‘<’ in a ‘#include’ directive.
  
     Traditionally, comments are completely removed and are not replaced
  with a space.  Since a traditional compiler does its own tokenization of
*************** re-lex its input.  For example, in
*** 3643,3649 ****
  
       #if foo/**/bar
  
! 'foo' and 'bar' are distinct identifiers and expanded separately if they
  happen to be macros.  In other words, this directive is equivalent to
  
       #if foo bar
--- 3643,3649 ----
  
       #if foo/**/bar
  
! ‘foo’ and ‘bar’ are distinct identifiers and expanded separately if they
  happen to be macros.  In other words, this directive is equivalent to
  
       #if foo bar
*************** with replacement text that contains an u
*** 3658,3664 ****
  you attempt to compile preprocessed output containing an unmatched quote
  you will get a syntax error.
  
!    However, all preprocessing directives other than '#define' require
  matching quotes.  For example:
  
       #define m This macro's fine and has an unmatched quote
--- 3658,3664 ----
  you attempt to compile preprocessed output containing an unmatched quote
  you will get a syntax error.
  
!    However, all preprocessing directives other than ‘#define’ require
  matching quotes.  For example:
  
       #define m This macro's fine and has an unmatched quote
*************** can run together with the text after the
*** 3689,3701 ****
  single token.
  
     Normally comments are removed from the replacement text after the
! macro is expanded, but if the '-CC' option is passed on the command-line
  comments are preserved.  (In fact, the current implementation removes
  comments even before saving the macro replacement text, but it careful
  to do it in such a way that the observed effect is identical even in the
  function-like macro case.)
  
!    The ISO stringizing operator '#' and token paste operator '##' have
  no special meaning.  As explained later, an effect similar to these
  operators can be obtained in a different way.  Macro names that are
  embedded in quotes, either from the main file or after macro
--- 3689,3701 ----
  single token.
  
     Normally comments are removed from the replacement text after the
! macro is expanded, but if the ‘-CC’ option is passed on the command-line
  comments are preserved.  (In fact, the current implementation removes
  comments even before saving the macro replacement text, but it careful
  to do it in such a way that the observed effect is identical even in the
  function-like macro case.)
  
!    The ISO stringizing operator ‘#’ and token paste operator ‘##’ have
  no special meaning.  As explained later, an effect similar to these
  operators can be obtained in a different way.  Macro names that are
  embedded in quotes, either from the main file or after macro
*************** invocation.
*** 3713,3719 ****
       #define PLUS +
       #define INC(x) PLUS+x
       INC(foo);
!           ==> ++foo;
  
     Function-like macros are similar in form but quite different in
  behavior to their ISO counterparts.  Their arguments are contained
--- 3713,3719 ----
       #define PLUS +
       #define INC(x) PLUS+x
       INC(foo);
!           ↦ ++foo;
  
     Function-like macros are similar in form but quite different in
  behavior to their ISO counterparts.  Their arguments are contained
*************** comma or parenthesis that comes before t
*** 3724,3736 ****
  any other character.  There is no facility for handling variadic macros.
  
     This implementation removes all comments from macro arguments, unless
! the '-C' option is given.  The form of all other horizontal whitespace
  in arguments is preserved, including leading and trailing whitespace.
  In particular
  
       f( )
  
! is treated as an invocation of the macro 'f' with a single argument
  consisting of a single space.  If you want to invoke a function-like
  macro that takes no arguments, you must not leave any whitespace between
  the parentheses.
--- 3724,3736 ----
  any other character.  There is no facility for handling variadic macros.
  
     This implementation removes all comments from macro arguments, unless
! the ‘-C’ option is given.  The form of all other horizontal whitespace
  in arguments is preserved, including leading and trailing whitespace.
  In particular
  
       f( )
  
! is treated as an invocation of the macro ‘f’ with a single argument
  consisting of a single space.  If you want to invoke a function-like
  macro that takes no arguments, you must not leave any whitespace between
  the parentheses.
*************** quotes or not.  This provides a way to s
*** 3745,3751 ****
  
       #define str(x) "x"
       str(/* A comment */some text )
!           ==> "some text "
  
  Note that the comment is removed, but that the trailing space is
  preserved.  Here is an example of using a comment to effect token
--- 3745,3751 ----
  
       #define str(x) "x"
       str(/* A comment */some text )
!           ↦ "some text "
  
  Note that the comment is removed, but that the trailing space is
  preserved.  Here is an example of using a comment to effect token
*************** pasting.
*** 3753,3759 ****
  
       #define suffix(x) foo_/**/x
       suffix(bar)
!           ==> foo_bar
  
  
  File: cpp.info,  Node: Traditional miscellany,  Next: Traditional warnings,  Prev: Traditional macros,  Up: Traditional Mode
--- 3753,3759 ----
  
       #define suffix(x) foo_/**/x
       suffix(bar)
!           ↦ foo_bar
  
  
  File: cpp.info,  Node: Traditional miscellany,  Next: Traditional warnings,  Prev: Traditional macros,  Up: Traditional Mode
*************** File: cpp.info,  Node: Traditional misce
*** 3764,3785 ****
  Here are some things to be aware of when using the traditional
  preprocessor.
  
!    * Preprocessing directives are recognized only when their leading '#'
       appears in the first column.  There can be no whitespace between
!      the beginning of the line and the '#', but whitespace can follow
!      the '#'.
  
!    * A true traditional C preprocessor does not recognize '#error' or
!      '#pragma', and may not recognize '#elif'.  CPP supports all the
       directives in traditional mode that it supports in ISO mode,
       including extensions, with the exception that the effects of
!      '#pragma GCC poison' are undefined.
  
!    * __STDC__ is not defined.
  
!    * If you use digraphs the behavior is undefined.
  
!    * If a line that looks like a directive appears within macro
       arguments, the behavior is undefined.
  
  
--- 3764,3785 ----
  Here are some things to be aware of when using the traditional
  preprocessor.
  
!    • Preprocessing directives are recognized only when their leading ‘#’
       appears in the first column.  There can be no whitespace between
!      the beginning of the line and the ‘#’, but whitespace can follow
!      the ‘#’.
  
!    • A true traditional C preprocessor does not recognize ‘#error’ or
!      ‘#pragma’, and may not recognize ‘#elif’.  CPP supports all the
       directives in traditional mode that it supports in ISO mode,
       including extensions, with the exception that the effects of
!      ‘#pragma GCC poison’ are undefined.
  
!    • __STDC__ is not defined.
  
!    • If you use digraphs the behavior is undefined.
  
!    • If a line that looks like a directive appears within macro
       arguments, the behavior is undefined.
  
  
*************** File: cpp.info,  Node: Traditional warni
*** 3789,3826 ****
  =========================
  
  You can request warnings about features that did not exist, or worked
! differently, in traditional C with the '-Wtraditional' option.  GCC does
  not warn about features of ISO C which you must use when you are using a
! conforming compiler, such as the '#' and '##' operators.
  
!    Presently '-Wtraditional' warns about:
  
!    * Macro parameters that appear within string literals in the macro
       body.  In traditional C macro replacement takes place within string
       literals, but does not in ISO C.
  
!    * In traditional C, some preprocessor directives did not exist.
       Traditional preprocessors would only consider a line to be a
!      directive if the '#' appeared in column 1 on the line.  Therefore
!      '-Wtraditional' warns about directives that traditional C
!      understands but would ignore because the '#' does not appear as the
       first character on the line.  It also suggests you hide directives
!      like '#pragma' not understood by traditional C by indenting them.
!      Some traditional implementations would not recognize '#elif', so it
       suggests avoiding it altogether.
  
!    * A function-like macro that appears without an argument list.  In
       some traditional preprocessors this was an error.  In ISO C it
       merely means that the macro is not expanded.
  
!    * The unary plus operator.  This did not exist in traditional C.
  
!    * The 'U' and 'LL' integer constant suffixes, which were not
!      available in traditional C.  (Traditional C does support the 'L'
       suffix for simple long integer constants.)  You are not warned
       about uses of these suffixes in macros defined in system headers.
!      For instance, 'UINT_MAX' may well be defined as '4294967295U', but
!      you will not be warned if you use 'UINT_MAX'.
  
       You can usually avoid the warning, and the related warning about
       constants which are so large that they are unsigned, by writing the
--- 3789,3826 ----
  =========================
  
  You can request warnings about features that did not exist, or worked
! differently, in traditional C with the ‘-Wtraditional’ option.  GCC does
  not warn about features of ISO C which you must use when you are using a
! conforming compiler, such as the ‘#’ and ‘##’ operators.
  
!    Presently ‘-Wtraditional’ warns about:
  
!    • Macro parameters that appear within string literals in the macro
       body.  In traditional C macro replacement takes place within string
       literals, but does not in ISO C.
  
!    • In traditional C, some preprocessor directives did not exist.
       Traditional preprocessors would only consider a line to be a
!      directive if the ‘#’ appeared in column 1 on the line.  Therefore
!      ‘-Wtraditional’ warns about directives that traditional C
!      understands but would ignore because the ‘#’ does not appear as the
       first character on the line.  It also suggests you hide directives
!      like ‘#pragma’ not understood by traditional C by indenting them.
!      Some traditional implementations would not recognize ‘#elif’, so it
       suggests avoiding it altogether.
  
!    • A function-like macro that appears without an argument list.  In
       some traditional preprocessors this was an error.  In ISO C it
       merely means that the macro is not expanded.
  
!    • The unary plus operator.  This did not exist in traditional C.
  
!    • The ‘U’ and ‘LL’ integer constant suffixes, which were not
!      available in traditional C.  (Traditional C does support the ‘L’
       suffix for simple long integer constants.)  You are not warned
       about uses of these suffixes in macros defined in system headers.
!      For instance, ‘UINT_MAX’ may well be defined as ‘4294967295U’, but
!      you will not be warned if you use ‘UINT_MAX’.
  
       You can usually avoid the warning, and the related warning about
       constants which are so large that they are unsigned, by writing the
*************** File: cpp.info,  Node: Implementation-de
*** 3854,3873 ****
  ====================================
  
  This is how CPP behaves in all the cases which the C standard describes
! as "implementation-defined".  This term means that the implementation is
  free to do what it likes, but must document its choice and stick to it.
  
!    * The mapping of physical source file multi-byte characters to the
       execution character set.
  
       The input character set can be specified using the
!      '-finput-charset' option, while the execution character set may be
!      controlled using the '-fexec-charset' and '-fwide-exec-charset'
       options.
  
!    * Identifier characters.
  
!      The C and C++ standards allow identifiers to be composed of '_' and
       the alphanumeric characters.  C++ also allows universal character
       names.  C99 and later C standards permit both universal character
       names and implementation-defined characters.  In both C and C++
--- 3854,3873 ----
  ====================================
  
  This is how CPP behaves in all the cases which the C standard describes
! as “implementation-defined”.  This term means that the implementation is
  free to do what it likes, but must document its choice and stick to it.
  
!    • The mapping of physical source file multi-byte characters to the
       execution character set.
  
       The input character set can be specified using the
!      ‘-finput-charset’ option, while the execution character set may be
!      controlled using the ‘-fexec-charset’ and ‘-fwide-exec-charset’
       options.
  
!    • Identifier characters.
  
!      The C and C++ standards allow identifiers to be composed of ‘_’ and
       the alphanumeric characters.  C++ also allows universal character
       names.  C99 and later C standards permit both universal character
       names and implementation-defined characters.  In both C and C++
*************** free to do what it likes, but must docum
*** 3875,3894 ****
       that correspond to universal character names permitted by the
       chosen standard.
  
!      GCC allows the '$' character in identifiers as an extension for
!      most targets.  This is true regardless of the 'std=' switch, since
       this extension cannot conflict with standards-conforming programs.
       When preprocessing assembler, however, dollars are not identifier
       characters by default.
  
!      Currently the targets that by default do not permit '$' are AVR,
       IP2K, MMIX, MIPS Irix 3, ARM aout, and PowerPC targets for the AIX
       operating system.
  
!      You can override the default with '-fdollars-in-identifiers' or
!      '-fno-dollars-in-identifiers'.  *Note fdollars-in-identifiers::.
  
!    * Non-empty sequences of whitespace characters.
  
       In textual output, each whitespace sequence is collapsed to a
       single space.  For aesthetic reasons, the first token on each
--- 3875,3894 ----
       that correspond to universal character names permitted by the
       chosen standard.
  
!      GCC allows the ‘$’ character in identifiers as an extension for
!      most targets.  This is true regardless of the ‘std=’ switch, since
       this extension cannot conflict with standards-conforming programs.
       When preprocessing assembler, however, dollars are not identifier
       characters by default.
  
!      Currently the targets that by default do not permit ‘$’ are AVR,
       IP2K, MMIX, MIPS Irix 3, ARM aout, and PowerPC targets for the AIX
       operating system.
  
!      You can override the default with ‘-fdollars-in-identifiers’ or
!      ‘-fno-dollars-in-identifiers’.  *Note fdollars-in-identifiers::.
  
!    • Non-empty sequences of whitespace characters.
  
       In textual output, each whitespace sequence is collapsed to a
       single space.  For aesthetic reasons, the first token on each
*************** free to do what it likes, but must docum
*** 3896,3938 ****
       that it appears in the same column as it did in the original source
       file.
  
!    * The numeric value of character constants in preprocessor
       expressions.
  
       The preprocessor and compiler interpret character constants in the
!      same way; i.e. escape sequences such as '\a' are given the values
       they would have on the target machine.
  
       The compiler evaluates a multi-character character constant a
       character at a time, shifting the previous value left by the number
       of bits per target character, and then or-ing in the bit-pattern of
       the new character truncated to the width of a target character.
!      The final bit-pattern is given type 'int', and is therefore signed,
       regardless of whether single characters are signed or not.  If
       there are more characters in the constant than would fit in the
!      target 'int' the compiler issues a warning, and the excess leading
       characters are ignored.
  
!      For example, ''ab'' for a target with an 8-bit 'char' would be
       interpreted as
!      '(int) ((unsigned char) 'a' * 256 + (unsigned char) 'b')', and
!      ''\234a'' as
!      '(int) ((unsigned char) '\234' * 256 + (unsigned char) 'a')'.
  
!    * Source file inclusion.
  
       For a discussion on how the preprocessor locates header files,
       *note Include Operation::.
  
!    * Interpretation of the filename resulting from a macro-expanded
!      '#include' directive.
  
       *Note Computed Includes::.
  
!    * Treatment of a '#pragma' directive that after macro-expansion
       results in a standard pragma.
  
!      No macro expansion occurs on any '#pragma' directive line, so the
       question does not arise.
  
       Note that GCC does not yet implement any of the standard pragmas.
--- 3896,3938 ----
       that it appears in the same column as it did in the original source
       file.
  
!    • The numeric value of character constants in preprocessor
       expressions.
  
       The preprocessor and compiler interpret character constants in the
!      same way; i.e. escape sequences such as ‘\a’ are given the values
       they would have on the target machine.
  
       The compiler evaluates a multi-character character constant a
       character at a time, shifting the previous value left by the number
       of bits per target character, and then or-ing in the bit-pattern of
       the new character truncated to the width of a target character.
!      The final bit-pattern is given type ‘int’, and is therefore signed,
       regardless of whether single characters are signed or not.  If
       there are more characters in the constant than would fit in the
!      target ‘int’ the compiler issues a warning, and the excess leading
       characters are ignored.
  
!      For example, ‘'ab'’ for a target with an 8-bit ‘char’ would be
       interpreted as
!      ‘(int) ((unsigned char) 'a' * 256 + (unsigned char) 'b')’, and
!      ‘'\234a'’ as
!      ‘(int) ((unsigned char) '\234' * 256 + (unsigned char) 'a')’.
  
!    • Source file inclusion.
  
       For a discussion on how the preprocessor locates header files,
       *note Include Operation::.
  
!    • Interpretation of the filename resulting from a macro-expanded
!      ‘#include’ directive.
  
       *Note Computed Includes::.
  
!    • Treatment of a ‘#pragma’ directive that after macro-expansion
       results in a standard pragma.
  
!      No macro expansion occurs on any ‘#pragma’ directive line, so the
       question does not arise.
  
       Note that GCC does not yet implement any of the standard pragmas.
*************** and all the others known.  It is intende
*** 3949,4000 ****
  limits as possible.  If you encounter an undocumented or inconvenient
  limit, please report that as a bug.  *Note Reporting Bugs: (gcc)Bugs.
  
!    Where we say something is limited "only by available memory", that
  means that internal data structures impose no intrinsic limit, and space
! is allocated with 'malloc' or equivalent.  The actual limit will
  therefore depend on many things, such as the size of other things
  allocated by the compiler at the same time, the amount of memory
  consumed by other processes on the same computer, etc.
  
!    * Nesting levels of '#include' files.
  
       We impose an arbitrary limit of 200 levels, to avoid runaway
       recursion.  The standard requires at least 15 levels.
  
!    * Nesting levels of conditional inclusion.
  
       The C standard mandates this be at least 63.  CPP is limited only
       by available memory.
  
!    * Levels of parenthesized expressions within a full expression.
  
       The C standard requires this to be at least 63.  In preprocessor
       conditional expressions, it is limited only by available memory.
  
!    * Significant initial characters in an identifier or macro name.
  
       The preprocessor treats all characters as significant.  The C
       standard requires only that the first 63 be significant.
  
!    * Number of macros simultaneously defined in a single translation
       unit.
  
       The standard requires at least 4095 be possible.  CPP is limited
       only by available memory.
  
!    * Number of parameters in a macro definition and arguments in a macro
       call.
  
!      We allow 'USHRT_MAX', which is no smaller than 65,535.  The minimum
       required by the standard is 127.
  
!    * Number of characters on a logical source line.
  
       The C standard requires a minimum of 4096 be permitted.  CPP places
       no limits on this, but you may get incorrect column numbers
       reported in diagnostics for lines longer than 65,535 characters.
  
!    * Maximum size of a source file.
  
       The standard does not specify any lower limit on the maximum size
       of a source file.  GNU cpp maps files into memory, so it is limited
--- 3949,4000 ----
  limits as possible.  If you encounter an undocumented or inconvenient
  limit, please report that as a bug.  *Note Reporting Bugs: (gcc)Bugs.
  
!    Where we say something is limited “only by available memory”, that
  means that internal data structures impose no intrinsic limit, and space
! is allocated with ‘malloc’ or equivalent.  The actual limit will
  therefore depend on many things, such as the size of other things
  allocated by the compiler at the same time, the amount of memory
  consumed by other processes on the same computer, etc.
  
!    • Nesting levels of ‘#include’ files.
  
       We impose an arbitrary limit of 200 levels, to avoid runaway
       recursion.  The standard requires at least 15 levels.
  
!    • Nesting levels of conditional inclusion.
  
       The C standard mandates this be at least 63.  CPP is limited only
       by available memory.
  
!    • Levels of parenthesized expressions within a full expression.
  
       The C standard requires this to be at least 63.  In preprocessor
       conditional expressions, it is limited only by available memory.
  
!    • Significant initial characters in an identifier or macro name.
  
       The preprocessor treats all characters as significant.  The C
       standard requires only that the first 63 be significant.
  
!    • Number of macros simultaneously defined in a single translation
       unit.
  
       The standard requires at least 4095 be possible.  CPP is limited
       only by available memory.
  
!    • Number of parameters in a macro definition and arguments in a macro
       call.
  
!      We allow ‘USHRT_MAX’, which is no smaller than 65,535.  The minimum
       required by the standard is 127.
  
!    • Number of characters on a logical source line.
  
       The C standard requires a minimum of 4096 be permitted.  CPP places
       no limits on this, but you may get incorrect column numbers
       reported in diagnostics for lines longer than 65,535 characters.
  
!    • Maximum size of a source file.
  
       The standard does not specify any lower limit on the maximum size
       of a source file.  GNU cpp maps files into memory, so it is limited
*************** plan to remove the feature in a future v
*** 4015,4021 ****
  11.3.1 Assertions
  -----------------
  
! "Assertions" are a deprecated alternative to macros in writing
  conditionals to test what sort of computer or system the compiled
  program will run on.  Assertions are usually predefined, but you can
  define them with preprocessing directives or command-line options.
--- 4015,4021 ----
  11.3.1 Assertions
  -----------------
  
! “Assertions” are a deprecated alternative to macros in writing
  conditionals to test what sort of computer or system the compiled
  program will run on.  Assertions are usually predefined, but you can
  define them with preprocessing directives or command-line options.
*************** PREDICATE must be a single identifier.
*** 4036,4047 ****
  tokens; all characters are significant except for leading and trailing
  whitespace, and differences in internal whitespace sequences are
  ignored.  (This is similar to the rules governing macro redefinition.)
! Thus, '(x + y)' is different from '(x+y)' but equivalent to '( x + y )'.
  Parentheses do not nest inside an answer.
  
!    To test an assertion, you write it in an '#if'.  For example, this
! conditional succeeds if either 'vax' or 'ns16000' has been asserted as
! an answer for 'machine'.
  
       #if #machine (vax) || #machine (ns16000)
  
--- 4036,4047 ----
  tokens; all characters are significant except for leading and trailing
  whitespace, and differences in internal whitespace sequences are
  ignored.  (This is similar to the rules governing macro redefinition.)
! Thus, ‘(x + y)’ is different from ‘(x+y)’ but equivalent to ‘( x + y )’.
  Parentheses do not nest inside an answer.
  
!    To test an assertion, you write it in an ‘#if’.  For example, this
! conditional succeeds if either ‘vax’ or ‘ns16000’ has been asserted as
! an answer for ‘machine’.
  
       #if #machine (vax) || #machine (ns16000)
  
*************** omitting the answer in the conditional:
*** 4050,4057 ****
  
       #if #machine
  
!    Assertions are made with the '#assert' directive.  Its sole argument
! is the assertion to make, without the leading '#' that identifies
  assertions in conditionals.
  
       #assert PREDICATE (ANSWER)
--- 4050,4057 ----
  
       #if #machine
  
!    Assertions are made with the ‘#assert’ directive.  Its sole argument
! is the assertion to make, without the leading ‘#’ that identifies
  assertions in conditionals.
  
       #assert PREDICATE (ANSWER)
*************** answers.  Subsequent assertions do not o
*** 4061,4075 ****
  same predicate.  All the answers for any given predicate are
  simultaneously true.
  
!    Assertions can be canceled with the '#unassert' directive.  It has
! the same syntax as '#assert'.  In that form it cancels only the answer
! which was specified on the '#unassert' line; other answers for that
  predicate remain true.  You can cancel an entire predicate by leaving
  out the answer:
  
       #unassert PREDICATE
  
! In either form, if no such assertion has been made, '#unassert' has no
  effect.
  
     You can also make or cancel assertions using command-line options.
--- 4061,4075 ----
  same predicate.  All the answers for any given predicate are
  simultaneously true.
  
!    Assertions can be canceled with the ‘#unassert’ directive.  It has
! the same syntax as ‘#assert’.  In that form it cancels only the answer
! which was specified on the ‘#unassert’ line; other answers for that
  predicate remain true.  You can cancel an entire predicate by leaving
  out the answer:
  
       #unassert PREDICATE
  
! In either form, if no such assertion has been made, ‘#unassert’ has no
  effect.
  
     You can also make or cancel assertions using command-line options.
*************** File: cpp.info,  Node: Invocation,  Next
*** 4084,4128 ****
  Most often when you use the C preprocessor you do not have to invoke it
  explicitly: the C compiler does so automatically.  However, the
  preprocessor is sometimes useful on its own.  You can invoke the
! preprocessor either with the 'cpp' command, or via 'gcc -E'.  In GCC,
  the preprocessor is actually integrated with the compiler rather than a
  separate program, and both of these commands invoke GCC and tell it to
  stop after the preprocessing phase.
  
!    The 'cpp' options listed here are also accepted by 'gcc' and have the
! same meaning.  Likewise the 'cpp' command accepts all the usual 'gcc'
  driver options, although those pertaining to compilation phases after
  preprocessing are ignored.
  
     Only options specific to preprocessing behavior are documented here.
  Refer to the GCC manual for full documentation of other driver options.
  
!    The 'cpp' command expects two file names as arguments, INFILE and
  OUTFILE.  The preprocessor reads INFILE together with any other files it
! specifies with '#include'.  All the output generated by the combined
  input files is written in OUTFILE.
  
!    Either INFILE or OUTFILE may be '-', which as INFILE means to read
  from standard input and as OUTFILE means to write to standard output.
! If either file is omitted, it means the same as if '-' had been
! specified for that file.  You can also use the '-o OUTFILE' option to
  specify the output file.
  
!    Unless otherwise noted, or the option ends in '=', all options which
  take an argument may have that argument appear either immediately after
! the option, or with a space between option and argument: '-Ifoo' and '-I
! foo' have the same effect.
  
     Many options have multi-letter names; therefore multiple
! single-letter options may _not_ be grouped: '-dM' is very different from
! '-d -M'.
  
! '-D NAME'
!      Predefine NAME as a macro, with definition '1'.
  
! '-D NAME=DEFINITION'
       The contents of DEFINITION are tokenized and processed as if they
!      appeared during translation phase three in a '#define' directive.
       In particular, the definition is truncated by embedded newline
       characters.
  
--- 4084,4128 ----
  Most often when you use the C preprocessor you do not have to invoke it
  explicitly: the C compiler does so automatically.  However, the
  preprocessor is sometimes useful on its own.  You can invoke the
! preprocessor either with the ‘cpp’ command, or via ‘gcc -E’.  In GCC,
  the preprocessor is actually integrated with the compiler rather than a
  separate program, and both of these commands invoke GCC and tell it to
  stop after the preprocessing phase.
  
!    The ‘cpp’ options listed here are also accepted by ‘gcc’ and have the
! same meaning.  Likewise the ‘cpp’ command accepts all the usual ‘gcc’
  driver options, although those pertaining to compilation phases after
  preprocessing are ignored.
  
     Only options specific to preprocessing behavior are documented here.
  Refer to the GCC manual for full documentation of other driver options.
  
!    The ‘cpp’ command expects two file names as arguments, INFILE and
  OUTFILE.  The preprocessor reads INFILE together with any other files it
! specifies with ‘#include’.  All the output generated by the combined
  input files is written in OUTFILE.
  
!    Either INFILE or OUTFILE may be ‘-’, which as INFILE means to read
  from standard input and as OUTFILE means to write to standard output.
! If either file is omitted, it means the same as if ‘-’ had been
! specified for that file.  You can also use the ‘-o OUTFILE’ option to
  specify the output file.
  
!    Unless otherwise noted, or the option ends in ‘=’, all options which
  take an argument may have that argument appear either immediately after
! the option, or with a space between option and argument: ‘-Ifoo’ and ‘-I
! foo’ have the same effect.
  
     Many options have multi-letter names; therefore multiple
! single-letter options may _not_ be grouped: ‘-dM’ is very different from
! ‘-d -M’.
  
! ‘-D NAME’
!      Predefine NAME as a macro, with definition ‘1’.
  
! ‘-D NAME=DEFINITION’
       The contents of DEFINITION are tokenized and processed as if they
!      appeared during translation phase three in a ‘#define’ directive.
       In particular, the definition is truncated by embedded newline
       characters.
  
*************** single-letter options may _not_ be group
*** 4133,4244 ****
       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 should 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.
  
! '-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'.
  
! '-undef'
       Do not predefine any system-specific or GCC-specific macros.  The
       standard predefined macros remain defined.  *Note Standard
       Predefined Macros::.
  
! '-pthread'
       Define additional macros required for using the POSIX threads
       library.  You should use this option consistently for both
       compilation and linking.  This option is supported on GNU/Linux
       targets, most other Unix derivatives, and also on x86 Cygwin and
       MinGW targets.
  
! '-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 is still 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 appears in '-MM' dependency output.
  
! '-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 send preprocessed
       output.
  
!      When used with the driver options '-MD' or '-MMD', '-MF' overrides
       the default dependency output file.
  
!      If FILE is '-', then the dependencies are written to 'stdout'.
  
! '-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.
  
! '-Mno-modules'
       Disable dependency generation for compiled module interfaces.
  
! '-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:
  
--- 4133,4244 ----
       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 should 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.
  
! ‘-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’.
  
! ‘-undef’
       Do not predefine any system-specific or GCC-specific macros.  The
       standard predefined macros remain defined.  *Note Standard
       Predefined Macros::.
  
! ‘-pthread’
       Define additional macros required for using the POSIX threads
       library.  You should use this option consistently for both
       compilation and linking.  This option is supported on GNU/Linux
       targets, most other Unix derivatives, and also on x86 Cygwin and
       MinGW targets.
  
! ‘-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 is still 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 appears in ‘-MM’ dependency output.
  
! ‘-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 send preprocessed
       output.
  
!      When used with the driver options ‘-MD’ or ‘-MMD’, ‘-MF’ overrides
       the default dependency output file.
  
!      If FILE is ‘-’, then the dependencies are written to ‘stdout’.
  
! ‘-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.
  
! ‘-Mno-modules’
       Disable dependency generation for compiled module interfaces.
  
! ‘-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:
  
*************** single-letter options may _not_ be group
*** 4246,4393 ****
  
            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 sets 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.
  
! '-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'.
  
! '-fdirectives-only'
       When preprocessing, handle directives, but do not expand macros.
  
!      The option's behavior depends on the '-E' and '-fpreprocessed'
       options.
  
!      With '-E', preprocessing is limited to the handling of directives
!      such as '#define', '#ifdef', and '#error'.  Other preprocessor
       operations, such as macro expansion and trigraph conversion are not
!      performed.  In addition, the '-dD' option is implicitly enabled.
  
!      With '-fpreprocessed', predefinition of command line and most
!      builtin macros is disabled.  Macros such as '__LINE__', which are
       contextually dependent, are handled normally.  This enables
!      compilation of files previously preprocessed with '-E
!      -fdirectives-only'.
  
!      With both '-E' and '-fpreprocessed', the rules for '-fpreprocessed'
       take precedence.  This enables full preprocessing of files
!      previously preprocessed with '-E -fdirectives-only'.
  
! '-fdollars-in-identifiers'
!      Accept '$' in identifiers.  *Note Identifier characters::.
  
! '-fextended-identifiers'
       Accept universal character names and extended characters in
       identifiers.  This option is enabled by default for C99 (and later
       C standard versions) and C++.
  
! '-fno-canonical-system-headers'
       When preprocessing, do not shorten system header paths with
       canonicalization.
  
! '-fmax-include-depth=DEPTH'
       Set the maximum depth of the nested #include.  The default is 200.
  
! '-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.
  
! '-ftrack-macro-expansion[=LEVEL]'
       Track locations of tokens across macro expansions.  This allows the
       compiler to emit diagnostic about the current macro expansion stack
       when a compilation error occurs in a macro expansion.  Using this
       option makes the preprocessor and the compiler consume more memory.
       The LEVEL parameter can be used to choose the level of precision of
       token location tracking thus decreasing the memory consumption if
!      necessary.  Value '0' of LEVEL de-activates this option.  Value '1'
       tracks tokens locations in a degraded mode for the sake of minimal
       memory overhead.  In this mode all tokens resulting from the
       expansion of an argument of a function-like macro have the same
!      location.  Value '2' tracks tokens locations completely.  This
       value is the most memory hungry.  When this option is given no
!      argument, the default parameter value is '2'.
  
!      Note that '-ftrack-macro-expansion=2' is activated by default.
  
! '-fmacro-prefix-map=OLD=NEW'
!      When preprocessing files residing in directory 'OLD', expand the
!      '__FILE__' and '__BASE_FILE__' macros as if the files resided in
!      directory 'NEW' instead.  This can be used to change an absolute
!      path to a relative path by using '.' for NEW which can result in
       more reproducible builds that are location independent.  This
!      option also affects '__builtin_FILE()' during compilation.  See
!      also '-ffile-prefix-map' and '-fcanon-prefix-map'.
  
! '-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 one of UTF-32BE, UTF-32LE,
       UTF-16BE, or UTF-16LE, whichever corresponds to the width of
!      'wchar_t' and the big-endian or little-endian byte order being used
!      for code generation.  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
--- 4246,4393 ----
  
            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 sets 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.
  
! ‘-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’.
  
! ‘-fdirectives-only’
       When preprocessing, handle directives, but do not expand macros.
  
!      The option's behavior depends on the ‘-E’ and ‘-fpreprocessed’
       options.
  
!      With ‘-E’, preprocessing is limited to the handling of directives
!      such as ‘#define’, ‘#ifdef’, and ‘#error’.  Other preprocessor
       operations, such as macro expansion and trigraph conversion are not
!      performed.  In addition, the ‘-dD’ option is implicitly enabled.
  
!      With ‘-fpreprocessed’, predefinition of command line and most
!      builtin macros is disabled.  Macros such as ‘__LINE__’, which are
       contextually dependent, are handled normally.  This enables
!      compilation of files previously preprocessed with ‘-E
!      -fdirectives-only’.
  
!      With both ‘-E’ and ‘-fpreprocessed’, the rules for ‘-fpreprocessed’
       take precedence.  This enables full preprocessing of files
!      previously preprocessed with ‘-E -fdirectives-only’.
  
! ‘-fdollars-in-identifiers’
!      Accept ‘$’ in identifiers.  *Note Identifier characters::.
  
! ‘-fextended-identifiers’
       Accept universal character names and extended characters in
       identifiers.  This option is enabled by default for C99 (and later
       C standard versions) and C++.
  
! ‘-fno-canonical-system-headers’
       When preprocessing, do not shorten system header paths with
       canonicalization.
  
! ‘-fmax-include-depth=DEPTH’
       Set the maximum depth of the nested #include.  The default is 200.
  
! ‘-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.
  
! ‘-ftrack-macro-expansion[=LEVEL]’
       Track locations of tokens across macro expansions.  This allows the
       compiler to emit diagnostic about the current macro expansion stack
       when a compilation error occurs in a macro expansion.  Using this
       option makes the preprocessor and the compiler consume more memory.
       The LEVEL parameter can be used to choose the level of precision of
       token location tracking thus decreasing the memory consumption if
!      necessary.  Value ‘0’ of LEVEL de-activates this option.  Value ‘1’
       tracks tokens locations in a degraded mode for the sake of minimal
       memory overhead.  In this mode all tokens resulting from the
       expansion of an argument of a function-like macro have the same
!      location.  Value ‘2’ tracks tokens locations completely.  This
       value is the most memory hungry.  When this option is given no
!      argument, the default parameter value is ‘2’.
  
!      Note that ‘-ftrack-macro-expansion=2’ is activated by default.
  
! ‘-fmacro-prefix-map=OLD=NEW’
!      When preprocessing files residing in directory ‘OLD’, expand the
!      ‘__FILE__’ and ‘__BASE_FILE__’ macros as if the files resided in
!      directory ‘NEW’ instead.  This can be used to change an absolute
!      path to a relative path by using ‘.’ for NEW which can result in
       more reproducible builds that are location independent.  This
!      option also affects ‘__builtin_FILE()’ during compilation.  See
!      also ‘-ffile-prefix-map’ and ‘-fcanon-prefix-map’.
  
! ‘-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 one of UTF-32BE, UTF-32LE,
       UTF-16BE, or UTF-16LE, whichever corresponds to the width of
!      ‘wchar_t’ and the big-endian or little-endian byte order being used
!      for code generation.  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
*************** single-letter options may _not_ be group
*** 4395,4403 ****
       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
       let the compiler know the current working directory at the time of
       preprocessing.  When this option is enabled, the preprocessor
--- 4395,4403 ----
       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
       let the compiler know the current working directory at the time of
       preprocessing.  When this option is enabled, the preprocessor
*************** single-letter options may _not_ be group
*** 4407,4487 ****
       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.
  
! '-A PREDICATE=ANSWER'
       Make an assertion with the predicate PREDICATE and answer ANSWER.
!      This form is preferred to the older form '-A PREDICATE(ANSWER)',
       which is still supported, because it does not use shell special
       characters.  *Note Obsolete Features::.
  
! '-A -PREDICATE=ANSWER'
       Cancel an assertion with the predicate PREDICATE and answer ANSWER.
  
! '-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.
  
! '-P'
       Inhibit generation of linemarkers in the output from the
       preprocessor.  This might be useful when running the preprocessor
       on something that is not C code, and will be sent to a program
       which might be confused by the linemarkers.  *Note Preprocessor
       Output::.
  
! '-traditional'
! '-traditional-cpp'
  
       Try to imitate the behavior of pre-standard C preprocessors, as
       opposed to ISO C preprocessors.  *Note Traditional Mode::.
  
       Note that GCC does not otherwise attempt to emulate a pre-standard
!      C compiler, and these options are only supported with the '-E'
       switch, or when invoking CPP explicitly.
  
! '-trigraphs'
       Support ISO C trigraphs.  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.  *Note Initial processing::.
  
       By default, GCC ignores trigraphs, but in standard-conforming modes
!      it converts them.  See the '-std' and '-ansi' options.
  
! '-remap'
       Enable special code to work around file systems which only permit
       very short file names, such as MS-DOS.
  
! '-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 '...!' .
  
! '-dLETTERS'
       Says to make debugging dumps during compilation as specified by
       LETTERS.  The flags documented here are those relevant to the
       preprocessor.  Other LETTERS are interpreted by the compiler
--- 4407,4487 ----
       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.
  
! ‘-A PREDICATE=ANSWER’
       Make an assertion with the predicate PREDICATE and answer ANSWER.
!      This form is preferred to the older form ‘-A PREDICATE(ANSWER)’,
       which is still supported, because it does not use shell special
       characters.  *Note Obsolete Features::.
  
! ‘-A -PREDICATE=ANSWER’
       Cancel an assertion with the predicate PREDICATE and answer ANSWER.
  
! ‘-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.
  
! ‘-P’
       Inhibit generation of linemarkers in the output from the
       preprocessor.  This might be useful when running the preprocessor
       on something that is not C code, and will be sent to a program
       which might be confused by the linemarkers.  *Note Preprocessor
       Output::.
  
! ‘-traditional’
! ‘-traditional-cpp’
  
       Try to imitate the behavior of pre-standard C preprocessors, as
       opposed to ISO C preprocessors.  *Note Traditional Mode::.
  
       Note that GCC does not otherwise attempt to emulate a pre-standard
!      C compiler, and these options are only supported with the ‘-E’
       switch, or when invoking CPP explicitly.
  
! ‘-trigraphs’
       Support ISO C trigraphs.  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.  *Note Initial processing::.
  
       By default, GCC ignores trigraphs, but in standard-conforming modes
!      it converts them.  See the ‘-std’ and ‘-ansi’ options.
  
! ‘-remap’
       Enable special code to work around file systems which only permit
       very short file names, such as MS-DOS.
  
! ‘-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 ‘...!’ .
  
! ‘-dLETTERS’
       Says to make debugging dumps during compilation as specified by
       LETTERS.  The flags documented here are those relevant to the
       preprocessor.  Other LETTERS are interpreted by the compiler
*************** single-letter options may _not_ be group
*** 4489,4547 ****
       ignored.  If you specify LETTERS whose behavior conflicts, the
       result is undefined.
  
!      '-dM'
!           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
  
            shows all the predefined macros.
  
!      '-dD'
!           Like '-dM' 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.
  
!      '-dN'
!           Like '-dD', but emit only the macro names, not their
            expansions.
  
!      '-dI'
!           Output '#include' directives in addition to the result of
            preprocessing.
  
!      '-dU'
!           Like '-dD' 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.
  
! '-fdebug-cpp'
       This option is only useful for debugging GCC. When used from CPP or
!      with '-E', it dumps debugging information about location maps.
       Every token in the output is preceded by the dump of the map its
       location belongs to.
  
!      When used from GCC without '-E', this option has no effect.
  
! '-I DIR'
! '-iquote DIR'
! '-isystem DIR'
! '-idirafter DIR'
       Add the directory DIR to the list of directories to be searched for
       header files during preprocessing.  *Note Search Path::.  If DIR
!      begins with '=' or '$SYSROOT', then the '=' or '$SYSROOT' is
!      replaced by the sysroot prefix; see '--sysroot' and '-isysroot'.
  
!      Directories specified with '-iquote' apply only to the quote form
!      of the directive, '#include "FILE"'.  Directories specified with
!      '-I', '-isystem', or '-idirafter' apply to lookup for both the
!      '#include "FILE"' and '#include ' directives.
  
       You can specify any number or combination of these options on the
       command line to search for header files in several directories.
--- 4489,4547 ----
       ignored.  If you specify LETTERS whose behavior conflicts, the
       result is undefined.
  
!      ‘-dM’
!           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
  
            shows all the predefined macros.
  
!      ‘-dD’
!           Like ‘-dM’ 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.
  
!      ‘-dN’
!           Like ‘-dD’, but emit only the macro names, not their
            expansions.
  
!      ‘-dI’
!           Output ‘#include’ directives in addition to the result of
            preprocessing.
  
!      ‘-dU’
!           Like ‘-dD’ 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.
  
! ‘-fdebug-cpp’
       This option is only useful for debugging GCC. When used from CPP or
!      with ‘-E’, it dumps debugging information about location maps.
       Every token in the output is preceded by the dump of the map its
       location belongs to.
  
!      When used from GCC without ‘-E’, this option has no effect.
  
! ‘-I DIR’
! ‘-iquote DIR’
! ‘-isystem DIR’
! ‘-idirafter DIR’
       Add the directory DIR to the list of directories to be searched for
       header files during preprocessing.  *Note Search Path::.  If DIR
!      begins with ‘=’ or ‘$SYSROOT’, then the ‘=’ or ‘$SYSROOT’ is
!      replaced by the sysroot prefix; see ‘--sysroot’ and ‘-isysroot’.
  
!      Directories specified with ‘-iquote’ apply only to the quote form
!      of the directive, ‘#include "FILE"’.  Directories specified with
!      ‘-I’, ‘-isystem’, or ‘-idirafter’ apply to lookup for both the
!      ‘#include "FILE"’ and ‘#include ’ directives.
  
       You can specify any number or combination of these options on the
       command line to search for header files in several directories.
*************** single-letter options may _not_ be group
*** 4551,4669 ****
            the current file is searched first.
  
         2. For the quote form of the include directive, the directories
!           specified by '-iquote' options are searched in left-to-right
            order, as they appear on the command line.
  
!        3. Directories specified with '-I' options are scanned in
            left-to-right order.
  
!        4. Directories specified with '-isystem' options are scanned in
            left-to-right order.
  
         5. Standard system directories are scanned.
  
!        6. Directories specified with '-idirafter' options are scanned in
            left-to-right order.
  
!      You can use '-I' to override a system header file, substituting
       your own version, since these directories are searched before the
       standard 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.
  
!      The '-isystem' and '-idirafter' options also mark the directory as
       a system directory, so that it gets the same special treatment that
       is applied to the standard system directories.  *Note System
       Headers::.
  
       If a standard system include directory, or a directory specified
!      with '-isystem', is also specified with '-I', the '-I' option is
       ignored.  The directory is still searched but as a system directory
       at its normal position in the system include chain.  This is to
       ensure that GCC's procedure to fix buggy system headers and the
!      ordering for the '#include_next' directive are not inadvertently
       changed.  If you really need to change the search order for system
!      directories, use the '-nostdinc' and/or '-isystem' options.  *Note
       System Headers::.
  
! '-I-'
       Split the include path.  This option has been deprecated.  Please
!      use '-iquote' instead for '-I' directories before the '-I-' and
!      remove the '-I-' option.
  
!      Any directories specified with '-I' options before '-I-' are
!      searched only for headers requested with '#include "FILE"'; they
!      are not searched for '#include '.  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"'.
!      There is no way to override this effect of '-I-'.  *Note Search
       Path::.
  
! '-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.
  
! '-nostdinc'
       Do not search the standard system directories for header files.
!      Only the directories explicitly specified with '-I', '-iquote',
!      '-isystem', and/or '-idirafter' 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.)
  
! '-Wcomment'
! '-Wcomments'
!      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'.
  
! '-Wtrigraphs'
       Warn if any trigraphs are encountered that might change the meaning
       of the program.  Trigraphs within comments are not warned about,
       except those that would form escaped newlines.
  
!      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'.
  
! '-Wundef'
!      Warn if an undefined identifier is evaluated in an '#if' directive.
       Such identifiers are replaced with zero.
  
! '-Wexpansion-to-defined'
!      Warn whenever 'defined' is encountered in the expansion of a macro
!      (including the case where the macro is expanded by an '#if'
       directive).  Such usage is not portable.  This warning is also
!      enabled by '-Wpedantic' and '-Wextra'.
  
! '-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 also warns if the macro has not been used
       at the time it is redefined or undefined.
  
--- 4551,4669 ----
            the current file is searched first.
  
         2. For the quote form of the include directive, the directories
!           specified by ‘-iquote’ options are searched in left-to-right
            order, as they appear on the command line.
  
!        3. Directories specified with ‘-I’ options are scanned in
            left-to-right order.
  
!        4. Directories specified with ‘-isystem’ options are scanned in
            left-to-right order.
  
         5. Standard system directories are scanned.
  
!        6. Directories specified with ‘-idirafter’ options are scanned in
            left-to-right order.
  
!      You can use ‘-I’ to override a system header file, substituting
       your own version, since these directories are searched before the
       standard 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.
  
!      The ‘-isystem’ and ‘-idirafter’ options also mark the directory as
       a system directory, so that it gets the same special treatment that
       is applied to the standard system directories.  *Note System
       Headers::.
  
       If a standard system include directory, or a directory specified
!      with ‘-isystem’, is also specified with ‘-I’, the ‘-I’ option is
       ignored.  The directory is still searched but as a system directory
       at its normal position in the system include chain.  This is to
       ensure that GCC's procedure to fix buggy system headers and the
!      ordering for the ‘#include_next’ directive are not inadvertently
       changed.  If you really need to change the search order for system
!      directories, use the ‘-nostdinc’ and/or ‘-isystem’ options.  *Note
       System Headers::.
  
! ‘-I-’
       Split the include path.  This option has been deprecated.  Please
!      use ‘-iquote’ instead for ‘-I’ directories before the ‘-I-’ and
!      remove the ‘-I-’ option.
  
!      Any directories specified with ‘-I’ options before ‘-I-’ are
!      searched only for headers requested with ‘#include "FILE"’; they
!      are not searched for ‘#include ’.  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"’.
!      There is no way to override this effect of ‘-I-’.  *Note Search
       Path::.
  
! ‘-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.
  
! ‘-nostdinc’
       Do not search the standard system directories for header files.
!      Only the directories explicitly specified with ‘-I’, ‘-iquote’,
!      ‘-isystem’, and/or ‘-idirafter’ 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.)
  
! ‘-Wcomment’
! ‘-Wcomments’
!      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’.
  
! ‘-Wtrigraphs’
       Warn if any trigraphs are encountered that might change the meaning
       of the program.  Trigraphs within comments are not warned about,
       except those that would form escaped newlines.
  
!      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’.
  
! ‘-Wundef’
!      Warn if an undefined identifier is evaluated in an ‘#if’ directive.
       Such identifiers are replaced with zero.
  
! ‘-Wexpansion-to-defined’
!      Warn whenever ‘defined’ is encountered in the expansion of a macro
!      (including the case where the macro is expanded by an ‘#if’
       directive).  Such usage is not portable.  This warning is also
!      enabled by ‘-Wpedantic’ and ‘-Wextra’.
  
! ‘-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 also warns if the macro has not been used
       at the time it is redefined or undefined.
  
*************** single-letter options may _not_ be group
*** 4680,4687 ****
            #if defined the_macro_causing_the_warning
            #endif
  
! '-Wno-endif-labels'
!      Do not warn whenever an '#else' or an '#endif' are followed by
       text.  This sometimes happens in older programs with code of the
       form
  
--- 4680,4687 ----
            #if defined the_macro_causing_the_warning
            #endif
  
! ‘-Wno-endif-labels’
!      Do not warn whenever an ‘#else’ or an ‘#endif’ are followed by
       text.  This sometimes happens in older programs with code of the
       form
  
*************** single-letter options may _not_ be group
*** 4691,4697 ****
            ...
            #endif FOO
  
!      The second and third 'FOO' should be in comments.  This warning is
       on by default.
  
  
--- 4691,4697 ----
            ...
            #endif FOO
  
!      The second and third ‘FOO’ should be in comments.  This warning is
       on by default.
  
  
*************** operates.  You can use them to specify d
*** 4705,4776 ****
  when searching for include files, or to control dependency output.
  
     Note that you can also specify places to search using options such as
! '-I', and control dependency output with options like '-M' (*note
  Invocation::).  These take precedence over environment variables, which
  in turn take precedence over the configuration of GCC.
  
! 'CPATH'
! 'C_INCLUDE_PATH'
! 'CPLUS_INCLUDE_PATH'
! 'OBJC_INCLUDE_PATH'
       Each variable's value is a list of directories separated by a
!      special character, much like 'PATH', in which to look for header
!      files.  The special character, 'PATH_SEPARATOR', is
       target-dependent and determined at GCC build time.  For Microsoft
       Windows-based targets it is a semicolon, and for almost all other
       targets it is a colon.
  
!      'CPATH' specifies a list of directories to be searched as if
!      specified with '-I', but after any paths given with '-I' options on
       the command line.  This environment variable is used regardless of
       which language is being preprocessed.
  
       The remaining environment variables apply only when preprocessing
       the particular language indicated.  Each specifies a list of
!      directories to be searched as if specified with '-isystem', but
!      after any paths given with '-isystem' options on the command line.
  
       In all these variables, an empty element instructs the compiler to
       search its current working directory.  Empty elements can appear at
       the beginning or end of a path.  For instance, if the value of
!      'CPATH' is ':/special/include', that has the same effect as
!      '-I. -I/special/include'.
  
       See also *note Search Path::.
  
! 'DEPENDENCIES_OUTPUT'
       If this variable is set, its value specifies how to output
       dependencies for Make based on the non-system header files
       processed by the compiler.  System header files are ignored in the
       dependency output.
  
!      The value of 'DEPENDENCIES_OUTPUT' can be just a file name, in
       which case the Make rules are written to that file, guessing the
       target name from the source file name.  Or the value can have the
!      form 'FILE TARGET', in which case the rules are written to file
       FILE using TARGET as the target name.
  
       In other words, this environment variable is equivalent to
!      combining the options '-MM' and '-MF' (*note Invocation::), with an
!      optional '-MT' switch too.
  
! 'SUNPRO_DEPENDENCIES'
!      This variable is the same as 'DEPENDENCIES_OUTPUT' (see above),
!      except that system header files are not ignored, so it implies '-M'
!      rather than '-MM'.  However, the dependence on the main input file
       is omitted.  *Note Invocation::.
  
! 'SOURCE_DATE_EPOCH'
       If this variable is set, its value specifies a UNIX timestamp to be
!      used in replacement of the current date and time in the '__DATE__'
!      and '__TIME__' macros, so that the embedded timestamps become
       reproducible.
  
!      The value of 'SOURCE_DATE_EPOCH' must be a UNIX timestamp, defined
       as the number of seconds (excluding leap seconds) since 01 Jan 1970
!      00:00:00 represented in ASCII; identical to the output of 'date
!      +%s' on GNU/Linux and other systems that support the '%s' extension
!      in the 'date' command.
  
       The value should be a known timestamp such as the last modification
       time of the source or package and it should be set by the build
--- 4705,4776 ----
  when searching for include files, or to control dependency output.
  
     Note that you can also specify places to search using options such as
! ‘-I’, and control dependency output with options like ‘-M’ (*note
  Invocation::).  These take precedence over environment variables, which
  in turn take precedence over the configuration of GCC.
  
! ‘CPATH’
! ‘C_INCLUDE_PATH’
! ‘CPLUS_INCLUDE_PATH’
! ‘OBJC_INCLUDE_PATH’
       Each variable's value is a list of directories separated by a
!      special character, much like ‘PATH’, in which to look for header
!      files.  The special character, ‘PATH_SEPARATOR’, is
       target-dependent and determined at GCC build time.  For Microsoft
       Windows-based targets it is a semicolon, and for almost all other
       targets it is a colon.
  
!      ‘CPATH’ specifies a list of directories to be searched as if
!      specified with ‘-I’, but after any paths given with ‘-I’ options on
       the command line.  This environment variable is used regardless of
       which language is being preprocessed.
  
       The remaining environment variables apply only when preprocessing
       the particular language indicated.  Each specifies a list of
!      directories to be searched as if specified with ‘-isystem’, but
!      after any paths given with ‘-isystem’ options on the command line.
  
       In all these variables, an empty element instructs the compiler to
       search its current working directory.  Empty elements can appear at
       the beginning or end of a path.  For instance, if the value of
!      ‘CPATH’ is ‘:/special/include’, that has the same effect as
!      ‘-I. -I/special/include’.
  
       See also *note Search Path::.
  
! ‘DEPENDENCIES_OUTPUT’
       If this variable is set, its value specifies how to output
       dependencies for Make based on the non-system header files
       processed by the compiler.  System header files are ignored in the
       dependency output.
  
!      The value of ‘DEPENDENCIES_OUTPUT’ can be just a file name, in
       which case the Make rules are written to that file, guessing the
       target name from the source file name.  Or the value can have the
!      form ‘FILE TARGET’, in which case the rules are written to file
       FILE using TARGET as the target name.
  
       In other words, this environment variable is equivalent to
!      combining the options ‘-MM’ and ‘-MF’ (*note Invocation::), with an
!      optional ‘-MT’ switch too.
  
! ‘SUNPRO_DEPENDENCIES’
!      This variable is the same as ‘DEPENDENCIES_OUTPUT’ (see above),
!      except that system header files are not ignored, so it implies ‘-M’
!      rather than ‘-MM’.  However, the dependence on the main input file
       is omitted.  *Note Invocation::.
  
! ‘SOURCE_DATE_EPOCH’
       If this variable is set, its value specifies a UNIX timestamp to be
!      used in replacement of the current date and time in the ‘__DATE__’
!      and ‘__TIME__’ macros, so that the embedded timestamps become
       reproducible.
  
!      The value of ‘SOURCE_DATE_EPOCH’ must be a UNIX timestamp, defined
       as the number of seconds (excluding leap seconds) since 01 Jan 1970
!      00:00:00 represented in ASCII; identical to the output of ‘date
!      +%s’ on GNU/Linux and other systems that support the ‘%s’ extension
!      in the ‘date’ command.
  
       The value should be a known timestamp such as the last modification
       time of the source or package and it should be set by the build
*************** GNU Free Documentation License
*** 4784,4790 ****
  
                       Version 1.3, 3 November 2008
  
!      Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
--- 4784,4790 ----
  
                       Version 1.3, 3 November 2008
  
!      Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
*************** GNU Free Documentation License
*** 4793,4799 ****
    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
--- 4793,4799 ----
    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
*************** Option Index
*** 5304,5323 ****
  ************
  
  CPP's command-line options and environment variables are indexed here
! without any initial '-' or '--'.
  
  [index]
  * Menu:
  
  * A:                                     Invocation.          (line 336)
  * C:                                     Invocation.          (line 345)
  * CC:                                    Invocation.          (line 357)
  * CPATH:                                 Environment Variables.
                                                                (line  15)
  * CPLUS_INCLUDE_PATH:                    Environment Variables.
                                                                (line  17)
- * C_INCLUDE_PATH:                        Environment Variables.
-                                                               (line  16)
  * D:                                     Invocation.          (line  42)
  * d:                                     Invocation.          (line 406)
  * dD:                                    Invocation.          (line 425)
--- 5304,5323 ----
  ************
  
  CPP's command-line options and environment variables are indexed here
! without any initial ‘-’ or ‘--’.
  
  [index]
  * Menu:
  
  * A:                                     Invocation.          (line 336)
  * C:                                     Invocation.          (line 345)
+ * C_INCLUDE_PATH:                        Environment Variables.
+                                                               (line  16)
  * CC:                                    Invocation.          (line 357)
  * CPATH:                                 Environment Variables.
                                                                (line  15)
  * CPLUS_INCLUDE_PATH:                    Environment Variables.
                                                                (line  17)
  * D:                                     Invocation.          (line  42)
  * d:                                     Invocation.          (line 406)
  * dD:                                    Invocation.          (line 425)
*************** Concept Index
*** 5400,5413 ****
  [index]
  * Menu:
  
- * # operator:                            Stringizing.         (line   6)
- * ## operator:                           Concatenation.       (line   6)
- * _Pragma:                               Pragmas.             (line  13)
  * __has_attribute:                       __has_attribute.     (line   6)
  * __has_builtin:                         __has_builtin.       (line   6)
- * __has_cpp_attribute:                   __has_cpp_attribute. (line   6)
  * __has_c_attribute:                     __has_c_attribute.   (line   6)
  * __has_include:                         __has_include.       (line   6)
  * alternative tokens:                    Tokenization.        (line 100)
  * arguments:                             Macro Arguments.     (line   6)
  * arguments in macro definitions:        Macro Arguments.     (line   6)
--- 5400,5413 ----
  [index]
  * Menu:
  
  * __has_attribute:                       __has_attribute.     (line   6)
  * __has_builtin:                         __has_builtin.       (line   6)
  * __has_c_attribute:                     __has_c_attribute.   (line   6)
+ * __has_cpp_attribute:                   __has_cpp_attribute. (line   6)
  * __has_include:                         __has_include.       (line   6)
+ * _Pragma:                               Pragmas.             (line  13)
+ * # operator:                            Stringizing.         (line   6)
+ * ## operator:                           Concatenation.       (line   6)
  * alternative tokens:                    Tokenization.        (line 100)
  * arguments:                             Macro Arguments.     (line   6)
  * arguments in macro definitions:        Macro Arguments.     (line   6)
*************** Concept Index
*** 5545,5628 ****
  
  
  Tag Table:
! Node: Top945
! Node: Overview3506
! Node: Character sets6344
! Ref: Character sets-Footnote-18516
! Node: Initial processing8697
! Ref: trigraphs10256
! Node: Tokenization14456
! Ref: Tokenization-Footnote-121286
! Node: The preprocessing language21397
! Node: Header Files24276
! Node: Include Syntax26192
! Node: Include Operation27829
! Node: Search Path29677
! Node: Once-Only Headers31899
! Node: Alternatives to Wrapper #ifndef33558
! Node: Computed Includes35207
! Node: Wrapper Headers38365
! Node: System Headers40788
! Node: Macros42389
! Node: Object-like Macros43526
! Node: Function-like Macros47116
! Node: Macro Arguments48732
! Node: Stringizing52871
! Node: Concatenation56032
! Node: Variadic Macros59129
! Node: Predefined Macros64081
! Node: Standard Predefined Macros64669
! Node: Common Predefined Macros71043
! Node: System-specific Predefined Macros93679
! Node: C++ Named Operators95702
! Node: Undefining and Redefining Macros96666
! Node: Directives Within Macro Arguments98764
! Node: Macro Pitfalls99705
! Node: Misnesting100238
! Node: Operator Precedence Problems101350
! Node: Swallowing the Semicolon103216
! Node: Duplication of Side Effects105239
! Node: Self-Referential Macros107422
! Node: Argument Prescan109831
! Node: Newlines in Arguments113582
! Node: Conditionals114533
! Node: Conditional Uses116229
! Node: Conditional Syntax117587
! Node: Ifdef118009
! Node: If121166
! Node: Defined123470
! Node: Else124863
! Node: Elif125433
! Node: __has_attribute126746
! Node: __has_cpp_attribute128340
! Node: __has_c_attribute129230
! Node: __has_builtin130003
! Node: __has_include131136
! Node: Deleted Code132725
! Node: Diagnostics133972
! Node: Line Control135521
! Node: Pragmas137799
! Node: Other Directives142311
! Node: Preprocessor Output143361
! Node: Traditional Mode146514
! Node: Traditional lexical analysis147651
! Node: Traditional macros150154
! Node: Traditional miscellany153951
! Node: Traditional warnings154947
! Node: Implementation Details157144
! Node: Implementation-defined behavior157707
! Ref: Identifier characters158457
! Node: Implementation limits161506
! Node: Obsolete Features164179
! Node: Invocation167023
! Ref: dashMF173058
! Ref: fdollars-in-identifiers177720
! Ref: Wtrigraphs191991
! Node: Environment Variables194046
! Node: GNU Free Documentation License197737
! Node: Index of Directives222887
! Node: Option Index225186
! Node: Concept Index231288
  
  End Tag Table
  
--- 5545,5628 ----
  
  
  Tag Table:
! Node: Top944
! Node: Overview3504
! Node: Character sets6382
! Ref: Character sets-Footnote-18590
! Node: Initial processing8775
! Ref: trigraphs10346
! Node: Tokenization14626
! Ref: Tokenization-Footnote-121620
! Node: The preprocessing language21739
! Node: Header Files24692
! Node: Include Syntax26624
! Node: Include Operation28313
! Node: Search Path30185
! Node: Once-Only Headers32471
! Node: Alternatives to Wrapper #ifndef34170
! Node: Computed Includes35887
! Node: Wrapper Headers39121
! Node: System Headers41608
! Node: Macros43245
! Node: Object-like Macros44402
! Node: Function-like Macros48096
! Node: Macro Arguments49728
! Node: Stringizing53921
! Node: Concatenation57162
! Node: Variadic Macros60343
! Node: Predefined Macros65395
! Node: Standard Predefined Macros65983
! Node: Common Predefined Macros72609
! Node: System-specific Predefined Macros96809
! Node: C++ Named Operators98880
! Node: Undefining and Redefining Macros99940
! Node: Directives Within Macro Arguments102074
! Node: Macro Pitfalls103015
! Node: Misnesting103548
! Node: Operator Precedence Problems104660
! Node: Swallowing the Semicolon106550
! Node: Duplication of Side Effects108609
! Node: Self-Referential Macros110864
! Node: Argument Prescan113373
! Node: Newlines in Arguments117210
! Node: Conditionals118165
! Node: Conditional Uses119885
! Node: Conditional Syntax121249
! Node: Ifdef121687
! Node: If124932
! Node: Defined127304
! Node: Else128765
! Node: Elif129351
! Node: __has_attribute130736
! Node: __has_cpp_attribute132370
! Node: __has_c_attribute133288
! Node: __has_builtin134097
! Node: __has_include135258
! Node: Deleted Code136887
! Node: Diagnostics138178
! Node: Line Control139767
! Node: Pragmas142109
! Node: Other Directives146773
! Node: Preprocessor Output147851
! Node: Traditional Mode151076
! Node: Traditional lexical analysis152217
! Node: Traditional macros154744
! Node: Traditional miscellany158561
! Node: Traditional warnings159595
! Node: Implementation Details161862
! Node: Implementation-defined behavior162425
! Ref: Identifier characters163195
! Node: Implementation limits166322
! Node: Obsolete Features169027
! Node: Invocation171927
! Ref: dashMF178198
! Ref: fdollars-in-identifiers183128
! Ref: Wtrigraphs197999
! Node: Environment Variables200122
! Node: GNU Free Documentation License203945
! Node: Index of Directives229098
! Node: Option Index231397
! Node: Concept Index237507
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/doc/cppinternals.info gcc-13.5.0-RC-20260904/gcc/doc/cppinternals.info
*** gcc-13.4.0/gcc/doc/cppinternals.info	Thu Jun  5 16:21:55 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/cppinternals.info	Fri Sep  4 07:50:36 2026
***************
*** 1,4 ****
! This is cppinternals.info, produced by makeinfo version 6.8 from
  cppinternals.texi.
  
  INFO-DIR-SECTION Software development
--- 1,4 ----
! This is cppinternals.info, produced by makeinfo version 7.1 from
  cppinternals.texi.
  
  INFO-DIR-SECTION Software development
*************** The GNU C Preprocessor Internals
*** 44,50 ****
  1 Cpplib--the GNU C Preprocessor
  ********************************
  
! The GNU C preprocessor is implemented as a library, "cpplib", so it can
  be easily shared between a stand-alone preprocessor, and a preprocessor
  integrated with the C, C++ and Objective-C front ends.  It is also
  available for use by other programs, though this is not recommended as
--- 44,50 ----
  1 Cpplib--the GNU C Preprocessor
  ********************************
  
! The GNU C preprocessor is implemented as a library, “cpplib”, so it can
  be easily shared between a stand-alone preprocessor, and a preprocessor
  integrated with the C, C++ and Objective-C front ends.  It is also
  available for use by other programs, though this is not recommended as
*************** cpplib has two interfaces--one is expose
*** 85,97 ****
  is for both internal and external use.
  
     The convention is that functions and types that are exposed to
! multiple files internally are prefixed with '_cpp_', and are to be found
! in the file 'internal.h'.  Functions and types exposed to external
! clients are in 'cpplib.h', and prefixed with 'cpp_'.  For historical
  reasons this is no longer quite true, but we should strive to stick to
  it.
  
!    We are striving to reduce the information exposed in 'cpplib.h' to
  the bare minimum necessary, and then to keep it there.  This makes clear
  exactly what external clients are entitled to assume, and allows us to
  change internals in the future without worrying whether library clients
--- 85,97 ----
  is for both internal and external use.
  
     The convention is that functions and types that are exposed to
! multiple files internally are prefixed with ‘_cpp_’, and are to be found
! in the file ‘internal.h’.  Functions and types exposed to external
! clients are in ‘cpplib.h’, and prefixed with ‘cpp_’.  For historical
  reasons this is no longer quite true, but we should strive to stick to
  it.
  
!    We are striving to reduce the information exposed in ‘cpplib.h’ to
  the bare minimum necessary, and then to keep it there.  This makes clear
  exactly what external clients are entitled to assume, and allows us to
  change internals in the future without worrying whether library clients
*************** The Lexer
*** 107,113 ****
  Overview
  ========
  
! The lexer is contained in the file 'lex.cc'.  It is a hand-coded lexer,
  and not implemented as a state machine.  It can understand C, C++ and
  Objective-C source code, and has been extended to allow reasonably
  successful preprocessing of assembly language.  The lexer does not make
--- 107,113 ----
  Overview
  ========
  
! The lexer is contained in the file ‘lex.cc’.  It is a hand-coded lexer,
  and not implemented as a state machine.  It can understand C, C++ and
  Objective-C source code, and has been extended to allow reasonably
  successful preprocessing of assembly language.  The lexer does not make
*************** them as they are encountered in a single
*** 116,132 ****
  returns preprocessing tokens individually, not a line at a time.
  
     It is mostly transparent to users of the library, since the library's
! interface for obtaining the next token, 'cpp_get_token', takes care of
  lexing new tokens, handling directives, and expanding macros as
  necessary.  However, the lexer does expose some functionality so that
  clients of the library can easily spell a given token, such as
! 'cpp_spell_token' and 'cpp_token_len'.  These functions are useful when
  generating diagnostics, and for emitting the preprocessed output.
  
  Lexing a token
  ==============
  
! Lexing of an individual token is handled by '_cpp_lex_direct' and its
  subroutines.  In its current form the code is quite complicated, with
  read ahead characters and such-like, since it strives to not step back
  in the character stream in preparation for handling non-ASCII file
--- 116,132 ----
  returns preprocessing tokens individually, not a line at a time.
  
     It is mostly transparent to users of the library, since the library's
! interface for obtaining the next token, ‘cpp_get_token’, takes care of
  lexing new tokens, handling directives, and expanding macros as
  necessary.  However, the lexer does expose some functionality so that
  clients of the library can easily spell a given token, such as
! ‘cpp_spell_token’ and ‘cpp_token_len’.  These functions are useful when
  generating diagnostics, and for emitting the preprocessed output.
  
  Lexing a token
  ==============
  
! Lexing of an individual token is handled by ‘_cpp_lex_direct’ and its
  subroutines.  In its current form the code is quite complicated, with
  read ahead characters and such-like, since it strives to not step back
  in the character stream in preparation for handling non-ASCII file
*************** encodings.  The current plan is to conve
*** 134,140 ****
  before processing them.  This complexity is therefore unnecessary and
  will be removed, so I'll not discuss it further here.
  
!    The job of '_cpp_lex_direct' is simply to lex a token.  It is not
  responsible for issues like directive handling, returning lookahead
  tokens directly, multiple-include optimization, or conditional block
  skipping.  It necessarily has a minor rôle to play in memory management
--- 134,140 ----
  before processing them.  This complexity is therefore unnecessary and
  will be removed, so I'll not discuss it further here.
  
!    The job of ‘_cpp_lex_direct’ is simply to lex a token.  It is not
  responsible for issues like directive handling, returning lookahead
  tokens directly, multiple-include optimization, or conditional block
  skipping.  It necessarily has a minor rôle to play in memory management
*************** of lexed lines.  I discuss these issues
*** 142,199 ****
  Lexing a line::).
  
     The lexer places the token it lexes into storage pointed to by the
! variable 'cur_token', and then increments it.  This variable is
  important for correct diagnostic positioning.  Unless a specific line
  and column are passed to the diagnostic routines, they will examine the
! 'line' and 'col' values of the token just before the location that
! 'cur_token' points to, and use that location to report the diagnostic.
  
     The lexer does not consider whitespace to be a token in its own
  right.  If whitespace (other than a new line) precedes a token, it sets
! the 'PREV_WHITE' bit in the token's flags.  Each token has its 'line'
! and 'col' variables set to the line and column of the first character of
  the token.  This line number is the line number in the translation unit,
  and can be converted to a source (file, line) pair using the line map
  code.
  
!    The first token on a logical, i.e. unescaped, line has the flag 'BOL'
  set for beginning-of-line.  This flag is intended for internal use, both
! to distinguish a '#' that begins a directive from one that doesn't, and
  to generate a call-back to clients that want to be notified about the
  start of every non-directive line with tokens on it.  Clients cannot
  reliably determine this for themselves: the first token might be a
! macro, and the tokens of a macro expansion do not have the 'BOL' flag
  set.  The macro expansion may even be empty, and the next token on the
! line certainly won't have the 'BOL' flag set.
  
     New lines are treated specially; exactly how the lexer handles them
  is context-dependent.  The C standard mandates that directives are
  terminated by the first unescaped newline character, even if it appears
  in the middle of a macro expansion.  Therefore, if the state variable
! 'in_directive' is set, the lexer returns a 'CPP_EOF' token, which is
  normally used to indicate end-of-file, to indicate end-of-directive.  In
! a directive a 'CPP_EOF' token never means end-of-file.  Conveniently, if
! the caller was 'collect_args', it already handles 'CPP_EOF' as if it
  were end-of-file, and reports an error about an unterminated macro
  argument list.
  
     The C standard also specifies that a new line in the middle of the
  arguments to a macro is treated as whitespace.  This white space is
  important in case the macro argument is stringized.  The state variable
! 'parsing_args' is nonzero when the preprocessor is collecting the
  arguments to a macro call.  It is set to 1 when looking for the opening
  parenthesis to a function-like macro, and 2 when collecting the actual
  arguments up to the closing parenthesis, since these two cases need to
  be distinguished sometimes.  One such time is here: the lexer sets the
! 'PREV_WHITE' flag of a token if it meets a new line when 'parsing_args'
  is set to 2.  It doesn't set it if it meets a new line when
! 'parsing_args' is 1, since then code like
  
       #define foo() bar
       foo
       baz
  
! would be output with an erroneous space before 'baz':
  
       foo
        baz
--- 142,199 ----
  Lexing a line::).
  
     The lexer places the token it lexes into storage pointed to by the
! variable ‘cur_token’, and then increments it.  This variable is
  important for correct diagnostic positioning.  Unless a specific line
  and column are passed to the diagnostic routines, they will examine the
! ‘line’ and ‘col’ values of the token just before the location that
! ‘cur_token’ points to, and use that location to report the diagnostic.
  
     The lexer does not consider whitespace to be a token in its own
  right.  If whitespace (other than a new line) precedes a token, it sets
! the ‘PREV_WHITE’ bit in the token's flags.  Each token has its ‘line’
! and ‘col’ variables set to the line and column of the first character of
  the token.  This line number is the line number in the translation unit,
  and can be converted to a source (file, line) pair using the line map
  code.
  
!    The first token on a logical, i.e. unescaped, line has the flag ‘BOL’
  set for beginning-of-line.  This flag is intended for internal use, both
! to distinguish a ‘#’ that begins a directive from one that doesn't, and
  to generate a call-back to clients that want to be notified about the
  start of every non-directive line with tokens on it.  Clients cannot
  reliably determine this for themselves: the first token might be a
! macro, and the tokens of a macro expansion do not have the ‘BOL’ flag
  set.  The macro expansion may even be empty, and the next token on the
! line certainly won't have the ‘BOL’ flag set.
  
     New lines are treated specially; exactly how the lexer handles them
  is context-dependent.  The C standard mandates that directives are
  terminated by the first unescaped newline character, even if it appears
  in the middle of a macro expansion.  Therefore, if the state variable
! ‘in_directive’ is set, the lexer returns a ‘CPP_EOF’ token, which is
  normally used to indicate end-of-file, to indicate end-of-directive.  In
! a directive a ‘CPP_EOF’ token never means end-of-file.  Conveniently, if
! the caller was ‘collect_args’, it already handles ‘CPP_EOF’ as if it
  were end-of-file, and reports an error about an unterminated macro
  argument list.
  
     The C standard also specifies that a new line in the middle of the
  arguments to a macro is treated as whitespace.  This white space is
  important in case the macro argument is stringized.  The state variable
! ‘parsing_args’ is nonzero when the preprocessor is collecting the
  arguments to a macro call.  It is set to 1 when looking for the opening
  parenthesis to a function-like macro, and 2 when collecting the actual
  arguments up to the closing parenthesis, since these two cases need to
  be distinguished sometimes.  One such time is here: the lexer sets the
! ‘PREV_WHITE’ flag of a token if it meets a new line when ‘parsing_args’
  is set to 2.  It doesn't set it if it meets a new line when
! ‘parsing_args’ is 1, since then code like
  
       #define foo() bar
       foo
       baz
  
! would be output with an erroneous space before ‘baz’:
  
       foo
        baz
*************** would be output with an erroneous space
*** 202,214 ****
  correct in the preprocessor; there are plenty of tests in the testsuite
  for corner cases like this.
  
!    The lexer is written to treat each of '\r', '\n', '\r\n' and '\n\r'
  as a single new line indicator.  This allows it to transparently
  preprocess MS-DOS, Macintosh and Unix files without their needing to
  pass through a special filter beforehand.
  
!    We also decided to treat a backslash, either '\' or the trigraph
! '??/', separated from one of the above newline indicators by non-comment
  whitespace only, as intending to escape the newline.  It tends to be a
  typing mistake, and cannot reasonably be mistaken for anything else in
  any of the C-family grammars.  Since handling it this way is not
--- 202,214 ----
  correct in the preprocessor; there are plenty of tests in the testsuite
  for corner cases like this.
  
!    The lexer is written to treat each of ‘\r’, ‘\n’, ‘\r\n’ and ‘\n\r’
  as a single new line indicator.  This allows it to transparently
  preprocess MS-DOS, Macintosh and Unix files without their needing to
  pass through a special filter beforehand.
  
!    We also decided to treat a backslash, either ‘\’ or the trigraph
! ‘??/’, separated from one of the above newline indicators by non-comment
  whitespace only, as intending to escape the newline.  It tends to be a
  typing mistake, and cannot reasonably be mistaken for anything else in
  any of the C-family grammars.  Since handling it this way is not
*************** strictly conforming to the ISO standard,
*** 216,288 ****
  wherever it encounters it.
  
     Handling newlines like this is made simpler by doing it in one place
! only.  The function 'handle_newline' takes care of all newline
! characters, and 'skip_escaped_newlines' takes care of arbitrarily long
! sequences of escaped newlines, deferring to 'handle_newline' to handle
  the newlines themselves.
  
     The most painful aspect of lexing ISO-standard C and C++ is handling
  trigraphs and backlash-escaped newlines.  Trigraphs are processed before
  any interpretation of the meaning of a character is made, and
  unfortunately there is a trigraph representation for a backslash, so it
! is possible for the trigraph '??/' to introduce an escaped newline.
  
     Escaped newlines are tedious because theoretically they can occur
! anywhere--between the '+' and '=' of the '+=' token, within the
! characters of an identifier, and even between the '*' and '/' that
  terminates a comment.  Moreover, you cannot be sure there is just
  one--there might be an arbitrarily long sequence of them.
  
!    So, for example, the routine that lexes a number, 'parse_number',
  cannot assume that it can scan forwards until the first non-number
! character and be done with it, because this could be the '\' introducing
! an escaped newline, or the '?' introducing the trigraph sequence that
! represents the '\' of an escaped newline.  If it encounters a '?' or
! '\', it calls 'skip_escaped_newlines' to skip over any potential escaped
  newlines before checking whether the number has been finished.
  
!    Similarly code in the main body of '_cpp_lex_direct' cannot simply
! check for a '=' after a '+' character to determine whether it has a '+='
  token; it needs to be prepared for an escaped newline of some sort.
! Such cases use the function 'get_effective_char', which returns the
  first character after any intervening escaped newlines.
  
     The lexer needs to keep track of the correct column position,
! including counting tabs as specified by the '-ftabstop=' option.  This
  should be done even within C-style comments; they can appear in the
  middle of a line, and we want to report diagnostics in the correct
  position for text appearing after the end of the comment.
  
!    Some identifiers, such as '__VA_ARGS__' and poisoned identifiers, may
  be invalid and require a diagnostic.  However, if they appear in a macro
  expansion we don't want to complain with each use of the macro.  It is
  therefore best to catch them during the lexing stage, in
! 'parse_identifier'.  In both cases, whether a diagnostic is needed or
  not is dependent upon the lexer's state.  For example, we don't want to
  issue a diagnostic for re-poisoning a poisoned identifier, or for using
! '__VA_ARGS__' in the expansion of a variable-argument macro.  Therefore
! 'parse_identifier' makes use of state flags to determine whether a
  diagnostic is appropriate.  Since we change state on a per-token basis,
  and don't lex whole lines at a time, this is not a problem.
  
     Another place where state flags are used to change behavior is whilst
! lexing header names.  Normally, a '<' would be lexed as a single token.
! After a '#include' directive, though, it should be lexed as a single
! token as far as the nearest '>' character.  Note that we don't allow the
! terminators of header names to be escaped; the first '"' or '>'
  terminates the header name.
  
     Interpretation of some character sequences depends upon whether we
  are lexing C, C++ or Objective-C, and on the revision of the standard in
! force.  For example, '::' is a single token in C++, but in C it is two
! separate ':' tokens and almost certainly a syntax error.  Such cases are
! handled by '_cpp_lex_direct' based upon command-line flags stored in the
! 'cpp_options' structure.
  
     Once a token has been lexed, it leads an independent existence.  The
  spelling of numbers, identifiers and strings is copied to permanent
  storage from the original input buffer, so a token remains valid and
! correct even if its source buffer is freed with '_cpp_pop_buffer'.  The
  storage holding the spellings of such tokens remains until the client
  program calls cpp_destroy, probably at the end of the translation unit.
  
--- 216,288 ----
  wherever it encounters it.
  
     Handling newlines like this is made simpler by doing it in one place
! only.  The function ‘handle_newline’ takes care of all newline
! characters, and ‘skip_escaped_newlines’ takes care of arbitrarily long
! sequences of escaped newlines, deferring to ‘handle_newline’ to handle
  the newlines themselves.
  
     The most painful aspect of lexing ISO-standard C and C++ is handling
  trigraphs and backlash-escaped newlines.  Trigraphs are processed before
  any interpretation of the meaning of a character is made, and
  unfortunately there is a trigraph representation for a backslash, so it
! is possible for the trigraph ‘??/’ to introduce an escaped newline.
  
     Escaped newlines are tedious because theoretically they can occur
! anywhere--between the ‘+’ and ‘=’ of the ‘+=’ token, within the
! characters of an identifier, and even between the ‘*’ and ‘/’ that
  terminates a comment.  Moreover, you cannot be sure there is just
  one--there might be an arbitrarily long sequence of them.
  
!    So, for example, the routine that lexes a number, ‘parse_number’,
  cannot assume that it can scan forwards until the first non-number
! character and be done with it, because this could be the ‘\’ introducing
! an escaped newline, or the ‘?’ introducing the trigraph sequence that
! represents the ‘\’ of an escaped newline.  If it encounters a ‘?’ or
! ‘\’, it calls ‘skip_escaped_newlines’ to skip over any potential escaped
  newlines before checking whether the number has been finished.
  
!    Similarly code in the main body of ‘_cpp_lex_direct’ cannot simply
! check for a ‘=’ after a ‘+’ character to determine whether it has a ‘+=’
  token; it needs to be prepared for an escaped newline of some sort.
! Such cases use the function ‘get_effective_char’, which returns the
  first character after any intervening escaped newlines.
  
     The lexer needs to keep track of the correct column position,
! including counting tabs as specified by the ‘-ftabstop=’ option.  This
  should be done even within C-style comments; they can appear in the
  middle of a line, and we want to report diagnostics in the correct
  position for text appearing after the end of the comment.
  
!    Some identifiers, such as ‘__VA_ARGS__’ and poisoned identifiers, may
  be invalid and require a diagnostic.  However, if they appear in a macro
  expansion we don't want to complain with each use of the macro.  It is
  therefore best to catch them during the lexing stage, in
! ‘parse_identifier’.  In both cases, whether a diagnostic is needed or
  not is dependent upon the lexer's state.  For example, we don't want to
  issue a diagnostic for re-poisoning a poisoned identifier, or for using
! ‘__VA_ARGS__’ in the expansion of a variable-argument macro.  Therefore
! ‘parse_identifier’ makes use of state flags to determine whether a
  diagnostic is appropriate.  Since we change state on a per-token basis,
  and don't lex whole lines at a time, this is not a problem.
  
     Another place where state flags are used to change behavior is whilst
! lexing header names.  Normally, a ‘<’ would be lexed as a single token.
! After a ‘#include’ directive, though, it should be lexed as a single
! token as far as the nearest ‘>’ character.  Note that we don't allow the
! terminators of header names to be escaped; the first ‘"’ or ‘>’
  terminates the header name.
  
     Interpretation of some character sequences depends upon whether we
  are lexing C, C++ or Objective-C, and on the revision of the standard in
! force.  For example, ‘::’ is a single token in C++, but in C it is two
! separate ‘:’ tokens and almost certainly a syntax error.  Such cases are
! handled by ‘_cpp_lex_direct’ based upon command-line flags stored in the
! ‘cpp_options’ structure.
  
     Once a token has been lexed, it leads an independent existence.  The
  spelling of numbers, identifiers and strings is copied to permanent
  storage from the original input buffer, so a token remains valid and
! correct even if its source buffer is freed with ‘_cpp_pop_buffer’.  The
  storage holding the spellings of such tokens remains until the client
  program calls cpp_destroy, probably at the end of the translation unit.
  
*************** to cpplib itself internally.
*** 299,307 ****
  token stream.  For example, after the name of a function-like macro, it
  wants to check the next token to see if it is an opening parenthesis.
  Another example is that, after reading the first few tokens of a
! '#pragma' directive and not recognizing it as a registered pragma, it
  wants to backtrack and allow the user-defined handler for unknown
! pragmas to access the full '#pragma' token stream.  The stand-alone
  preprocessor wants to be able to test the current token with the
  previous one to see if a space needs to be inserted to preserve their
  separate tokenization upon re-lexing (paste avoidance), so it needs to
--- 299,307 ----
  token stream.  For example, after the name of a function-like macro, it
  wants to check the next token to see if it is an opening parenthesis.
  Another example is that, after reading the first few tokens of a
! ‘#pragma’ directive and not recognizing it as a registered pragma, it
  wants to backtrack and allow the user-defined handler for unknown
! pragmas to access the full ‘#pragma’ token stream.  The stand-alone
  preprocessor wants to be able to test the current token with the
  previous one to see if a space needs to be inserted to preserve their
  separate tokenization upon re-lexing (paste avoidance), so it needs to
*************** to jump back to a prior position in that
*** 312,321 ****
  
     The rule I chose, which is fairly natural, is to arrange that the
  preprocessor lex all tokens on a line consecutively into a token buffer,
! which I call a "token run", and when meeting an unescaped new line
  (newlines within comments do not count either), to start lexing back at
  the beginning of the run.  Note that we do _not_ lex a line of tokens at
! once; if we did that 'parse_identifier' would not have state flags
  available to warn about invalid identifiers (*note Invalid
  identifiers::).
  
--- 312,321 ----
  
     The rule I chose, which is fairly natural, is to arrange that the
  preprocessor lex all tokens on a line consecutively into a token buffer,
! which I call a “token run”, and when meeting an unescaped new line
  (newlines within comments do not count either), to start lexing back at
  the beginning of the run.  Note that we do _not_ lex a line of tokens at
! once; if we did that ‘parse_identifier’ would not have state flags
  available to warn about invalid identifiers (*note Invalid
  identifiers::).
  
*************** identifiers::).
*** 323,329 ****
  line is valid, but since each logical line overwrites the tokens of the
  previous line, tokens from prior lines are unavailable.  In particular,
  since a directive only occupies a single logical line, this means that
! the directive handlers like the '#pragma' handler can jump around in the
  directive's tokens if necessary.
  
     Two issues remain: what about tokens that arise from macro
--- 323,329 ----
  line is valid, but since each logical line overwrites the tokens of the
  previous line, tokens from prior lines are unavailable.  In particular,
  since a directive only occupies a single logical line, this means that
! the directive handlers like the ‘#pragma’ handler can jump around in the
  directive's tokens if necessary.
  
     Two issues remain: what about tokens that arise from macro
*************** line, we cannot reallocate the run.  Ins
*** 336,347 ****
  by chaining a new token run on to the end of the existing one.
  
     The tokens forming a macro's replacement list are collected by the
! '#define' handler, and placed in storage that is only freed by
! 'cpp_destroy'.  So if a macro is expanded in the line of tokens, the
  pointers to the tokens of its expansion that are returned will always
  remain valid.  However, macros are a little trickier than that, since
  they give rise to three sources of fresh tokens.  They are the built-in
! macros like '__LINE__', and the '#' and '##' operators for stringizing
  and token pasting.  I handled this by allocating space for these tokens
  from the lexer's token run chain.  This means they automatically receive
  the same lifetime guarantees as lexed tokens, and we don't need to
--- 336,347 ----
  by chaining a new token run on to the end of the existing one.
  
     The tokens forming a macro's replacement list are collected by the
! ‘#define’ handler, and placed in storage that is only freed by
! ‘cpp_destroy’.  So if a macro is expanded in the line of tokens, the
  pointers to the tokens of its expansion that are returned will always
  remain valid.  However, macros are a little trickier than that, since
  they give rise to three sources of fresh tokens.  They are the built-in
! macros like ‘__LINE__’, and the ‘#’ and ‘##’ operators for stringizing
  and token pasting.  I handled this by allocating space for these tokens
  from the lexer's token run chain.  This means they automatically receive
  the same lifetime guarantees as lexed tokens, and we don't need to
*************** management issues, but not all.  The ope
*** 352,358 ****
  function-like macro name might lie on a different line, and the front
  ends definitely want the ability to look ahead past the end of the
  current line.  So cpplib only moves back to the start of the token run
! at the end of a line if the variable 'keep_tokens' is zero.
  Line-buffering is quite natural for the preprocessor, and as a result
  the only time cpplib needs to increment this variable is whilst looking
  for the opening parenthesis to, and reading the arguments of, a
--- 352,358 ----
  function-like macro name might lie on a different line, and the front
  ends definitely want the ability to look ahead past the end of the
  current line.  So cpplib only moves back to the start of the token run
! at the end of a line if the variable ‘keep_tokens’ is zero.
  Line-buffering is quite natural for the preprocessor, and as a result
  the only time cpplib needs to increment this variable is whilst looking
  for the opening parenthesis to, and reading the arguments of, a
*************** function-like macro.  In the near future
*** 360,371 ****
  to increment and decrement this variable, so that clients can share full
  control over the lifetime of token pointers too.
  
!    The routine '_cpp_lex_token' handles moving to new token runs,
! calling '_cpp_lex_direct' to lex new tokens, or returning
  previously-lexed tokens if we stepped back in the token stream.  It also
! checks each token for the 'BOL' flag, which might indicate a directive
  that needs to be handled, or require a start-of-line call-back to be
! made.  '_cpp_lex_token' also handles skipping over tokens in failed
  conditional blocks, and invalidates the control macro of the
  multiple-include optimization if a token was successfully lexed outside
  a directive.  In other words, its callers do not need to concern
--- 360,371 ----
  to increment and decrement this variable, so that clients can share full
  control over the lifetime of token pointers too.
  
!    The routine ‘_cpp_lex_token’ handles moving to new token runs,
! calling ‘_cpp_lex_direct’ to lex new tokens, or returning
  previously-lexed tokens if we stepped back in the token stream.  It also
! checks each token for the ‘BOL’ flag, which might indicate a directive
  that needs to be handled, or require a start-of-line call-back to be
! made.  ‘_cpp_lex_token’ also handles skipping over tokens in failed
  conditional blocks, and invalidates the control macro of the
  multiple-include optimization if a token was successfully lexed outside
  a directive.  In other words, its callers do not need to concern
*************** Hash Nodes
*** 379,397 ****
  
  When cpplib encounters an "identifier", it generates a hash code for it
  and stores it in the hash table.  By "identifier" we mean tokens with
! type 'CPP_NAME'; this includes identifiers in the usual C sense, as well
  as keywords, directive names, macro names and so on.  For example, all
! of 'pragma', 'int', 'foo' and '__GNUC__' are identifiers and hashed when
  lexed.
  
     Each node in the hash table contain various information about the
  identifier it represents.  For example, its length and type.  At any one
  time, each identifier falls into exactly one of three categories:
  
!    * Macros
  
       These have been declared to be macros, either on the command line
!      or with '#define'.  A few, such as '__TIME__' are built-ins entered
       in the hash table during initialization.  The hash node for a
       normal macro points to a structure with more information about the
       macro, such as whether it is function-like, how many arguments it
--- 379,397 ----
  
  When cpplib encounters an "identifier", it generates a hash code for it
  and stores it in the hash table.  By "identifier" we mean tokens with
! type ‘CPP_NAME’; this includes identifiers in the usual C sense, as well
  as keywords, directive names, macro names and so on.  For example, all
! of ‘pragma’, ‘int’, ‘foo’ and ‘__GNUC__’ are identifiers and hashed when
  lexed.
  
     Each node in the hash table contain various information about the
  identifier it represents.  For example, its length and type.  At any one
  time, each identifier falls into exactly one of three categories:
  
!    • Macros
  
       These have been declared to be macros, either on the command line
!      or with ‘#define’.  A few, such as ‘__TIME__’ are built-ins entered
       in the hash table during initialization.  The hash node for a
       normal macro points to a structure with more information about the
       macro, such as whether it is function-like, how many arguments it
*************** time, each identifier falls into exactly
*** 399,435 ****
       and instead contain an enum indicating which of the various
       built-in macros it is.
  
!    * Assertions
  
       Assertions are in a separate namespace to macros.  To enforce this,
!      cpp actually prepends a '#' character before hashing and entering
       it in the hash table.  An assertion's node points to a chain of
       answers to that assertion.
  
!    * Void
  
       Everything else falls into this category--an identifier that is not
       currently a macro, or a macro that has since been undefined with
!      '#undef'.
  
       When preprocessing C++, this category also includes the named
!      operators, such as 'xor'.  In expressions these behave like the
       operators they represent, but in contexts where the spelling of a
       token matters they are spelt differently.  This spelling
       distinction is relevant when they are operands of the stringizing
!      and pasting macro operators '#' and '##'.  Named operator hash
       nodes are flagged, both to catch the spelling distinction and to
       prevent them from being defined as macros.
  
     The same identifiers share the same hash node.  Since each identifier
  token, after lexing, contains a pointer to its hash node, this is used
  to provide rapid lookup of various information.  For example, when
! parsing a '#define' statement, CPP flags each argument's identifier hash
  node with the index of that argument.  This makes duplicated argument
  checking an O(1) operation for each argument.  Similarly, for each
  identifier in the macro's expansion, lookup to see if it is an argument,
  and which argument it is, is also an O(1) operation.  Further, each
! directive name, such as 'endif', has an associated directive enum stored
  in its hash node, so that directive lookup is also O(1).
  
  
--- 399,435 ----
       and instead contain an enum indicating which of the various
       built-in macros it is.
  
!    • Assertions
  
       Assertions are in a separate namespace to macros.  To enforce this,
!      cpp actually prepends a ‘#’ character before hashing and entering
       it in the hash table.  An assertion's node points to a chain of
       answers to that assertion.
  
!    • Void
  
       Everything else falls into this category--an identifier that is not
       currently a macro, or a macro that has since been undefined with
!      ‘#undef’.
  
       When preprocessing C++, this category also includes the named
!      operators, such as ‘xor’.  In expressions these behave like the
       operators they represent, but in contexts where the spelling of a
       token matters they are spelt differently.  This spelling
       distinction is relevant when they are operands of the stringizing
!      and pasting macro operators ‘#’ and ‘##’.  Named operator hash
       nodes are flagged, both to catch the spelling distinction and to
       prevent them from being defined as macros.
  
     The same identifiers share the same hash node.  Since each identifier
  token, after lexing, contains a pointer to its hash node, this is used
  to provide rapid lookup of various information.  For example, when
! parsing a ‘#define’ statement, CPP flags each argument's identifier hash
  node with the index of that argument.  This makes duplicated argument
  checking an O(1) operation for each argument.  Similarly, for each
  identifier in the macro's expansion, lookup to see if it is an argument,
  and which argument it is, is also an O(1) operation.  Further, each
! directive name, such as ‘endif’, has an associated directive enum stored
  in its hash node, so that directive lookup is also O(1).
  
  
*************** to get the replacement list of a macro.
*** 461,487 ****
  its parameters, in the form of an ordered list of pointers to the hash
  table entry of each parameter's identifier.  Further, in the macro's
  stored expansion each occurrence of a parameter is replaced with a
! special token of type 'CPP_MACRO_ARG'.  Each such token holds the index
  of the parameter it represents in the parameter list, which allows rapid
  replacement of parameters with their arguments during expansion.
  Despite this optimization it is still necessary to store the original
! parameters to the macro, both for dumping with e.g., '-dD', and to warn
  about non-trivial macro redefinitions when the parameter names have
  changed.
  
  Macro expansion overview
  ========================
  
! The preprocessor maintains a "context stack", implemented as a linked
! list of 'cpp_context' structures, which together represent the macro
! expansion state at any one time.  The 'struct cpp_reader' member
! variable 'context' points to the current top of this stack.  The top
  normally holds the unexpanded replacement list of the innermost macro
  under expansion, except when cpplib is about to pre-expand an argument,
  in which case it holds that argument's unexpanded tokens.
  
!    When there are no macros under expansion, cpplib is in "base
! context".  All contexts other than the base context contain a contiguous
  list of tokens delimited by a starting and ending token.  When not in
  base context, cpplib obtains the next token from the list of the top
  context.  If there are no tokens left in the list, it pops that context
--- 461,487 ----
  its parameters, in the form of an ordered list of pointers to the hash
  table entry of each parameter's identifier.  Further, in the macro's
  stored expansion each occurrence of a parameter is replaced with a
! special token of type ‘CPP_MACRO_ARG’.  Each such token holds the index
  of the parameter it represents in the parameter list, which allows rapid
  replacement of parameters with their arguments during expansion.
  Despite this optimization it is still necessary to store the original
! parameters to the macro, both for dumping with e.g., ‘-dD’, and to warn
  about non-trivial macro redefinitions when the parameter names have
  changed.
  
  Macro expansion overview
  ========================
  
! The preprocessor maintains a “context stack”, implemented as a linked
! list of ‘cpp_context’ structures, which together represent the macro
! expansion state at any one time.  The ‘struct cpp_reader’ member
! variable ‘context’ points to the current top of this stack.  The top
  normally holds the unexpanded replacement list of the innermost macro
  under expansion, except when cpplib is about to pre-expand an argument,
  in which case it holds that argument's unexpanded tokens.
  
!    When there are no macros under expansion, cpplib is in “base
! context”.  All contexts other than the base context contain a contiguous
  list of tokens delimited by a starting and ending token.  When not in
  base context, cpplib obtains the next token from the list of the top
  context.  If there are no tokens left in the list, it pops that context
*************** reads tokens directly from the lexer.
*** 491,514 ****
  
     If it encounters an identifier that is both a macro and enabled for
  expansion, cpplib prepares to push a new context for that macro on the
! stack by calling the routine 'enter_macro_context'.  When this routine
  returns, the new context will contain the unexpanded tokens of the
  replacement list of that macro.  In the case of function-like macros,
! 'enter_macro_context' also replaces any parameters in the replacement
! list, stored as 'CPP_MACRO_ARG' tokens, with the appropriate macro
  argument.  If the standard requires that the parameter be replaced with
  its expanded argument, the argument will have been fully macro expanded
  first.
  
!    'enter_macro_context' also handles special macros like '__LINE__'.
  Although these macros expand to a single token which cannot contain any
  further macros, for reasons of token spacing (*note Token Spacing::) and
  simplicity of implementation, cpplib handles these special macros by
  pushing a context containing just that one token.
  
!    The final thing that 'enter_macro_context' does before returning is
  to mark the macro disabled for expansion (except for special macros like
! '__TIME__').  The macro is re-enabled when its context is later popped
  from the context stack, as described above.  This strict ordering
  ensures that a macro is disabled whilst its expansion is being scanned,
  but that it is _not_ disabled whilst any arguments to it are being
--- 491,514 ----
  
     If it encounters an identifier that is both a macro and enabled for
  expansion, cpplib prepares to push a new context for that macro on the
! stack by calling the routine ‘enter_macro_context’.  When this routine
  returns, the new context will contain the unexpanded tokens of the
  replacement list of that macro.  In the case of function-like macros,
! ‘enter_macro_context’ also replaces any parameters in the replacement
! list, stored as ‘CPP_MACRO_ARG’ tokens, with the appropriate macro
  argument.  If the standard requires that the parameter be replaced with
  its expanded argument, the argument will have been fully macro expanded
  first.
  
!    ‘enter_macro_context’ also handles special macros like ‘__LINE__’.
  Although these macros expand to a single token which cannot contain any
  further macros, for reasons of token spacing (*note Token Spacing::) and
  simplicity of implementation, cpplib handles these special macros by
  pushing a context containing just that one token.
  
!    The final thing that ‘enter_macro_context’ does before returning is
  to mark the macro disabled for expansion (except for special macros like
! ‘__TIME__’).  The macro is re-enabled when its context is later popped
  from the context stack, as described above.  This strict ordering
  ensures that a macro is disabled whilst its expansion is being scanned,
  but that it is _not_ disabled whilst any arguments to it are being
*************** which illustrates many of the points abo
*** 547,567 ****
       #define foo(x) bar x
       foo(foo) (2)
  
! which fully expands to 'bar foo (2)'.  During pre-expansion of the
! argument, 'foo' does not expand even though the macro is enabled, since
  it has no following parenthesis [pre-expansion of an argument only uses
  tokens from that argument; it cannot take tokens from whatever follows
! the macro invocation].  This still leaves the argument token 'foo'
  eligible for future expansion.  Then, when re-scanning after argument
! replacement, the token 'foo' is rejected for expansion, and marked
  ineligible for future expansion, since the macro is now disabled.  It is
! disabled because the replacement list 'bar foo' of the macro is still on
  the context stack.
  
     If instead the algorithm looked for an opening parenthesis first and
  then tested whether the macro were disabled it would be subtly wrong.
! In the example above, the replacement list of 'foo' would be popped in
! the process of finding the parenthesis, re-enabling 'foo' and expanding
  it a second time.
  
  Looking for a function-like macro's opening parenthesis
--- 547,567 ----
       #define foo(x) bar x
       foo(foo) (2)
  
! which fully expands to ‘bar foo (2)’.  During pre-expansion of the
! argument, ‘foo’ does not expand even though the macro is enabled, since
  it has no following parenthesis [pre-expansion of an argument only uses
  tokens from that argument; it cannot take tokens from whatever follows
! the macro invocation].  This still leaves the argument token ‘foo’
  eligible for future expansion.  Then, when re-scanning after argument
! replacement, the token ‘foo’ is rejected for expansion, and marked
  ineligible for future expansion, since the macro is now disabled.  It is
! disabled because the replacement list ‘bar foo’ of the macro is still on
  the context stack.
  
     If instead the algorithm looked for an opening parenthesis first and
  then tested whether the macro were disabled it would be subtly wrong.
! In the example above, the replacement list of ‘foo’ would be popped in
! the process of finding the parenthesis, re-enabling ‘foo’ and expanding
  it a second time.
  
  Looking for a function-like macro's opening parenthesis
*************** padding tokens.
*** 579,585 ****
  permitted by cpplib, because in general it might involve issues like
  restoring popped contexts onto the context stack, which are too hard.
  Instead, searching for the parenthesis is handled by a special function,
! 'funlike_invocation_p', which remembers padding information as it reads
  tokens.  If the next real token is not an opening parenthesis, it backs
  up that one token, and then pushes an extra context just containing the
  padding information if necessary.
--- 579,585 ----
  permitted by cpplib, because in general it might involve issues like
  restoring popped contexts onto the context stack, which are too hard.
  Instead, searching for the parenthesis is handled by a special function,
! ‘funlike_invocation_p’, which remembers padding information as it reads
  tokens.  If the next real token is not an opening parenthesis, it backs
  up that one token, and then pushes an extra context just containing the
  padding information if necessary.
*************** Marking tokens ineligible for future exp
*** 590,601 ****
  As discussed above, cpplib needs a way of marking tokens as
  unexpandable.  Since the tokens cpplib handles are read-only once they
  have been lexed, it instead makes a copy of the token and adds the flag
! 'NO_EXPAND' to the copy.
  
     For efficiency and to simplify memory management by avoiding having
  to remember to free these tokens, they are allocated as temporary tokens
  from the lexer's current token run (*note Lexing a line::) using the
! function '_cpp_temp_token'.  The tokens are then re-used once the
  current line of tokens has been read in.
  
     This might sound unsafe.  However, tokens runs are not re-used at the
--- 590,601 ----
  As discussed above, cpplib needs a way of marking tokens as
  unexpandable.  Since the tokens cpplib handles are read-only once they
  have been lexed, it instead makes a copy of the token and adds the flag
! ‘NO_EXPAND’ to the copy.
  
     For efficiency and to simplify memory management by avoiding having
  to remember to free these tokens, they are allocated as temporary tokens
  from the lexer's current token run (*note Lexing a line::) using the
! function ‘_cpp_temp_token’.  The tokens are then re-used once the
  current line of tokens has been read in.
  
     This might sound unsafe.  However, tokens runs are not re-used at the
*************** substitution.  For example:
*** 620,628 ****
       #define EMPTY
       #define f(x) =x=
       +PLUS -EMPTY- PLUS+ f(=)
!              ==> + + - - + + = = =
       _not_
!              ==> ++ -- ++ ===
  
     One solution would be to simply insert a space between all adjacent
  tokens.  However, we would like to keep space insertion to a minimum,
--- 620,628 ----
       #define EMPTY
       #define f(x) =x=
       +PLUS -EMPTY- PLUS+ f(=)
!              ↦ + + - - + + = = =
       _not_
!              ↦ ++ -- ++ ===
  
     One solution would be to simply insert a space between all adjacent
  tokens.  However, we would like to keep space insertion to a minimum,
*************** still try to abuse the preprocessor for
*** 631,646 ****
  Makefiles.
  
     For now, just notice that when tokens are added (or removed, as shown
! by the 'EMPTY' example) from the original lexed token stream, we need to
! check for accidental token pasting.  We call this "paste avoidance".
  Token addition and removal can only occur because of macro expansion,
  but accidental pasting can occur in many places: both before and after
  each macro replacement, each argument replacement, and additionally each
! token created by the '#' and '##' operators.
  
     Look at how the preprocessor gets whitespace output correct normally.
! The 'cpp_token' structure contains a flags byte, and one of those flags
! is 'PREV_WHITE'.  This is flagged by the lexer, and indicates that the
  token was preceded by whitespace of some form other than a new line.
  The stand-alone preprocessor can use this flag to decide whether to
  insert a space between tokens in the output.
--- 631,646 ----
  Makefiles.
  
     For now, just notice that when tokens are added (or removed, as shown
! by the ‘EMPTY’ example) from the original lexed token stream, we need to
! check for accidental token pasting.  We call this “paste avoidance”.
  Token addition and removal can only occur because of macro expansion,
  but accidental pasting can occur in many places: both before and after
  each macro replacement, each argument replacement, and additionally each
! token created by the ‘#’ and ‘##’ operators.
  
     Look at how the preprocessor gets whitespace output correct normally.
! The ‘cpp_token’ structure contains a flags byte, and one of those flags
! is ‘PREV_WHITE’.  This is flagged by the lexer, and indicates that the
  token was preceded by whitespace of some form other than a new line.
  The stand-alone preprocessor can use this flag to decide whether to
  insert a space between tokens in the output.
*************** insert a space between tokens in the out
*** 649,675 ****
  
       #define add(x, y, z) x + y +z;
       sum = add (1,2, 3);
!              ==> sum = 1 + 2 +3;
  
!    The interesting thing here is that the tokens '1' and '2' are output
! with a preceding space, and '3' is output without a preceding space, but
  when lexed none of these tokens had that property.  Careful
! consideration reveals that '1' gets its preceding whitespace from the
! space preceding 'add' in the macro invocation, _not_ replacement list.
! '2' gets its whitespace from the space preceding the parameter 'y' in
! the macro replacement list, and '3' has no preceding space because
! parameter 'z' has none in the replacement list.
  
     Once lexed, tokens are effectively fixed and cannot be altered, since
  pointers to them might be held in many places, in particular by
  in-progress macro expansions.  So instead of modifying the two tokens
! above, the preprocessor inserts a special token, which I call a "padding
! token", into the token stream to indicate that spacing of the subsequent
  token is special.  The preprocessor inserts padding tokens in front of
  every macro expansion and expanded macro argument.  These point to a
! "source token" from which the subsequent real token should inherit its
! spacing.  In the above example, the source tokens are 'add' in the macro
! invocation, and 'y' and 'z' in the macro replacement list, respectively.
  
     It is quite easy to get multiple padding tokens in a row, for example
  if a macro's first replacement token expands straight into another
--- 649,675 ----
  
       #define add(x, y, z) x + y +z;
       sum = add (1,2, 3);
!              ↦ sum = 1 + 2 +3;
  
!    The interesting thing here is that the tokens ‘1’ and ‘2’ are output
! with a preceding space, and ‘3’ is output without a preceding space, but
  when lexed none of these tokens had that property.  Careful
! consideration reveals that ‘1’ gets its preceding whitespace from the
! space preceding ‘add’ in the macro invocation, _not_ replacement list.
! ‘2’ gets its whitespace from the space preceding the parameter ‘y’ in
! the macro replacement list, and ‘3’ has no preceding space because
! parameter ‘z’ has none in the replacement list.
  
     Once lexed, tokens are effectively fixed and cannot be altered, since
  pointers to them might be held in many places, in particular by
  in-progress macro expansions.  So instead of modifying the two tokens
! above, the preprocessor inserts a special token, which I call a “padding
! token”, into the token stream to indicate that spacing of the subsequent
  token is special.  The preprocessor inserts padding tokens in front of
  every macro expansion and expanded macro argument.  These point to a
! “source token” from which the subsequent real token should inherit its
! spacing.  In the above example, the source tokens are ‘add’ in the macro
! invocation, and ‘y’ and ‘z’ in the macro replacement list, respectively.
  
     It is quite easy to get multiple padding tokens in a row, for example
  if a macro's first replacement token expands straight into another
*************** macro.
*** 678,687 ****
       #define foo bar
       #define bar baz
       [foo]
!              ==> [baz]
  
!    Here, two padding tokens are generated with sources the 'foo' token
! between the brackets, and the 'bar' token from foo's replacement list,
  respectively.  Clearly the first padding token is the one to use, so the
  output code should contain a rule that the first padding token in a
  sequence is the one that matters.
--- 678,687 ----
       #define foo bar
       #define bar baz
       [foo]
!              ↦ [baz]
  
!    Here, two padding tokens are generated with sources the ‘foo’ token
! between the brackets, and the ‘bar’ token from foo's replacement list,
  respectively.  Clearly the first padding token is the one to use, so the
  output code should contain a rule that the first padding token in a
  sequence is the one that matters.
*************** slightly:
*** 693,707 ****
       #define bar EMPTY baz
       #define EMPTY
       [foo] EMPTY;
!              ==> [ baz] ;
  
!    As shown, now there should be a space before 'baz' and the semicolon
  in the output.
  
!    The rules we decided above fail for 'baz': we generate three padding
! tokens, one per macro invocation, before the token 'baz'.  We would then
  have it take its spacing from the first of these, which carries source
! token 'foo' with no leading space.
  
     It is vital that cpplib get spacing correct in these examples since
  any of these macro expansions could be stringized, where spacing
--- 693,707 ----
       #define bar EMPTY baz
       #define EMPTY
       [foo] EMPTY;
!              ↦ [ baz] ;
  
!    As shown, now there should be a space before ‘baz’ and the semicolon
  in the output.
  
!    The rules we decided above fail for ‘baz’: we generate three padding
! tokens, one per macro invocation, before the token ‘baz’.  We would then
  have it take its spacing from the first of these, which carries source
! token ‘foo’ with no leading space.
  
     It is vital that cpplib get spacing correct in these examples since
  any of these macro expansions could be stringized, where spacing
*************** matters.
*** 709,719 ****
  
     So, this demonstrates that not just entering macro and argument
  expansions, but leaving them requires special handling too.  I made
! cpplib insert a padding token with a 'NULL' source token when leaving
  macro expansions, as well as after each replaced argument in a macro's
  replacement list.  It also inserts appropriate padding tokens on either
! side of tokens created by the '#' and '##' operators.  I expanded the
! rule so that, if we see a padding token with a 'NULL' source token,
  _and_ that source token has no leading space, then we behave as if we
  have seen no padding tokens at all.  A quick check shows this rule will
  then get the above example correct as well.
--- 709,719 ----
  
     So, this demonstrates that not just entering macro and argument
  expansions, but leaving them requires special handling too.  I made
! cpplib insert a padding token with a ‘NULL’ source token when leaving
  macro expansions, as well as after each replaced argument in a macro's
  replacement list.  It also inserts appropriate padding tokens on either
! side of tokens created by the ‘#’ and ‘##’ operators.  I expanded the
! rule so that, if we see a padding token with a ‘NULL’ source token,
  _and_ that source token has no leading space, then we behave as if we
  have seen no padding tokens at all.  A quick check shows this rule will
  then get the above example correct as well.
*************** implementation of paste avoidance easy:
*** 725,731 ****
  preprocessor is fixing up spacing because of padding tokens, and it
  turns out that no space is needed, it has to take the extra step to
  check that a space is not needed after all to avoid an accidental paste.
! The function 'cpp_avoid_paste' advises whether a space is required
  between two consecutive tokens.  To avoid excessive spacing, it tries
  hard to only require a space if one is likely to be necessary, but for
  reasons of efficiency it is slightly conservative and might recommend a
--- 725,731 ----
  preprocessor is fixing up spacing because of padding tokens, and it
  turns out that no space is needed, it has to take the extra step to
  check that a space is not needed after all to avoid an accidental paste.
! The function ‘cpp_avoid_paste’ advises whether a space is required
  between two consecutive tokens.  To avoid excessive spacing, it tries
  hard to only require a space if one is likely to be necessary, but for
  reasons of efficiency it is slightly conservative and might recommend a
*************** Just which line number anyway?
*** 743,771 ****
  There are three reasonable requirements a cpplib client might have for
  the line number of a token passed to it:
  
!    * The source line it was lexed on.
!    * The line it is output on.  This can be different to the line it was
       lexed on if, for example, there are intervening escaped newlines or
       C-style comments.  For example:
  
            foo /* A long
            comment */ bar \
            baz
!           =>
            foo bar baz
  
!    * If the token results from a macro expansion, the line of the macro
       name, or possibly the line of the closing parenthesis in the case
       of function-like macro expansion.
  
!    The 'cpp_token' structure contains 'line' and 'col' members.  The
  lexer fills these in with the line and column of the first character of
  the token.  Consequently, but maybe unexpectedly, a token from the
  replacement list of a macro expansion carries the location of the token
! within the '#define' directive, because cpplib expands a macro by
  returning pointers to the tokens in its replacement list.  The current
  implementation of cpplib assigns tokens created from built-in macros and
! the '#' and '##' operators the location of the most recently lexed
  token.  This is a because they are allocated from the lexer's token
  runs, and because of the way the diagnostic routines infer the
  appropriate location to report.
--- 743,771 ----
  There are three reasonable requirements a cpplib client might have for
  the line number of a token passed to it:
  
!    • The source line it was lexed on.
!    • The line it is output on.  This can be different to the line it was
       lexed on if, for example, there are intervening escaped newlines or
       C-style comments.  For example:
  
            foo /* A long
            comment */ bar \
            baz
!           ⇒
            foo bar baz
  
!    • If the token results from a macro expansion, the line of the macro
       name, or possibly the line of the closing parenthesis in the case
       of function-like macro expansion.
  
!    The ‘cpp_token’ structure contains ‘line’ and ‘col’ members.  The
  lexer fills these in with the line and column of the first character of
  the token.  Consequently, but maybe unexpectedly, a token from the
  replacement list of a macro expansion carries the location of the token
! within the ‘#define’ directive, because cpplib expands a macro by
  returning pointers to the tokens in its replacement list.  The current
  implementation of cpplib assigns tokens created from built-in macros and
! the ‘#’ and ‘##’ operators the location of the most recently lexed
  token.  This is a because they are allocated from the lexer's token
  runs, and because of the way the diagnostic routines infer the
  appropriate location to report.
*************** line other than the first.
*** 787,793 ****
  
     To solve these issues, cpplib provides a callback that is generated
  whenever it lexes a preprocessing token that starts a new logical line
! other than a directive.  It passes this token (which may be a 'CPP_EOF'
  token indicating the end of the translation unit) to the callback
  routine, which can then use the line and column of this token to produce
  correct output.
--- 787,793 ----
  
     To solve these issues, cpplib provides a callback that is generated
  whenever it lexes a preprocessing token that starts a new logical line
! other than a directive.  It passes this token (which may be a ‘CPP_EOF’
  token indicating the end of the translation unit) to the callback
  routine, which can then use the line and column of this token to produce
  correct output.
*************** starts counting from one.
*** 810,821 ****
  translation unit.  With some simple infrastructure, it is straight
  forward to map from this to the original source file and line number
  pair, saving space whenever line number information needs to be saved.
! The code the implements this mapping lies in the files 'line-map.cc' and
! 'line-map.h'.
  
     Command-line macros and assertions are implemented by pushing a
! buffer containing the right hand side of an equivalent '#define' or
! '#assert' directive.  Some built-in macros are handled similarly.  Since
  these are all processed before the first line of the main input file, it
  will typically have an assigned line closer to twenty than to one.
  
--- 810,821 ----
  translation unit.  With some simple infrastructure, it is straight
  forward to map from this to the original source file and line number
  pair, saving space whenever line number information needs to be saved.
! The code the implements this mapping lies in the files ‘line-map.cc’ and
! ‘line-map.h’.
  
     Command-line macros and assertions are implemented by pushing a
! buffer containing the right hand side of an equivalent ‘#define’ or
! ‘#assert’ directive.  Some built-in macros are handled similarly.  Since
  these are all processed before the first line of the main input file, it
  will typically have an assigned line closer to twenty than to one.
  
*************** Header files are often of the form
*** 834,843 ****
  
  to prevent the compiler from processing them more than once.  The
  preprocessor notices such header files, so that if the header file
! appears in a subsequent '#include' directive and 'FOO' is defined, then
  it is ignored and it doesn't preprocess or even re-open the file a
! second time.  This is referred to as the "multiple include
! optimization".
  
     Under what circumstances is such an optimization valid?  If the file
  were included a second time, it can only be optimized away if that
--- 834,843 ----
  
  to prevent the compiler from processing them more than once.  The
  preprocessor notices such header files, so that if the header file
! appears in a subsequent ‘#include’ directive and ‘FOO’ is defined, then
  it is ignored and it doesn't preprocess or even re-open the file a
! second time.  This is referred to as the “multiple include
! optimization”.
  
     Under what circumstances is such an optimization valid?  If the file
  were included a second time, it can only be optimized away if that
*************** inclusion would result in no tokens to r
*** 845,856 ****
  directives to process.  Therefore the current implementation imposes
  requirements and makes some allowances as follows:
  
!   1. There must be no tokens outside the controlling '#if'-'#endif'
       pair, but whitespace and comments are permitted.
  
    2. There must be no directives outside the controlling directive pair,
!      but the "null directive" (a line containing nothing other than a
!      single '#' and possibly whitespace) is permitted.
  
    3. The opening directive must be of the form
  
--- 845,856 ----
  directives to process.  Therefore the current implementation imposes
  requirements and makes some allowances as follows:
  
!   1. There must be no tokens outside the controlling ‘#if’-‘#endif’
       pair, but whitespace and comments are permitted.
  
    2. There must be no directives outside the controlling directive pair,
!      but the “null directive” (a line containing nothing other than a
!      single ‘#’ and possibly whitespace) is permitted.
  
    3. The opening directive must be of the form
  
*************** requirements and makes some allowances a
*** 860,927 ****
  
            #if !defined FOO     [equivalently, #if !defined(FOO)]
  
!   4. In the second form above, the tokens forming the '#if' expression
       must have come directly from the source file--no macro expansion
       must have been involved.  This is because macro definitions can
       change, and tracking whether or not a relevant change has been made
       is not worth the implementation cost.
  
!   5. There can be no '#else' or '#elif' directives at the outer
       conditional block level, because they would probably contain
       something of interest to a subsequent pass.
  
     First, when pushing a new file on the buffer stack,
! '_stack_include_file' sets the controlling macro 'mi_cmacro' to 'NULL',
! and sets 'mi_valid' to 'true'.  This indicates that the preprocessor has
  not yet encountered anything that would invalidate the multiple-include
  optimization.  As described in the next few paragraphs, these two
  variables having these values effectively indicates top-of-file.
  
     When about to return a token that is not part of a directive,
! '_cpp_lex_token' sets 'mi_valid' to 'false'.  This enforces the
  constraint that tokens outside the controlling conditional block
  invalidate the optimization.
  
!    The 'do_if', when appropriate, and 'do_ifndef' directive handlers
! pass the controlling macro to the function 'push_conditional'.  cpplib
  maintains a stack of nested conditional blocks, and after processing
! every opening conditional this function pushes an 'if_stack' structure
  onto the stack.  In this structure it records the controlling macro for
  the block, provided there is one and we're at top-of-file (as described
! above).  If an '#elif' or '#else' directive is encountered, the
! controlling macro for that block is cleared to 'NULL'.  Otherwise, it
! survives until the '#endif' closing the block, upon which 'do_endif'
! sets 'mi_valid' to true and stores the controlling macro in 'mi_cmacro'.
  
!    '_cpp_handle_directive' clears 'mi_valid' when processing any
  directive other than an opening conditional and the null directive.
  With this, and requiring top-of-file to record a controlling macro, and
! no '#else' or '#elif' for it to survive and be copied to 'mi_cmacro' by
! 'do_endif', we have enforced the absence of directives outside the main
  conditional block for the optimization to be on.
  
!    Note that whilst we are inside the conditional block, 'mi_valid' is
! likely to be reset to 'false', but this does not matter since the
! closing '#endif' restores it to 'true' if appropriate.
  
!    Finally, since '_cpp_lex_direct' pops the file off the buffer stack
! at 'EOF' without returning a token, if the '#endif' directive was not
! followed by any tokens, 'mi_valid' is 'true' and '_cpp_pop_file_buffer'
  remembers the controlling macro associated with the file.  Subsequent
! calls to 'stack_include_file' result in no buffer being pushed if the
  controlling macro is defined, effecting the optimization.
  
     A quick word on how we handle the
  
       #if !defined FOO
  
! case.  '_cpp_parse_expr' and 'parse_defined' take steps to see whether
! the three stages '!', 'defined-expression' and 'end-of-directive' occur
! in order in a '#if' expression.  If so, they return the guard macro to
! 'do_if' in the variable 'mi_ind_cmacro', and otherwise set it to 'NULL'.
! 'enter_macro_context' sets 'mi_valid' to false, so if a macro was
  expanded whilst parsing any part of the expression, then the top-of-file
! test in 'push_conditional' fails and the optimization is turned off.
  
  
  File: cppinternals.info,  Node: Files,  Next: Concept Index,  Prev: Guard Macros,  Up: Top
--- 860,927 ----
  
            #if !defined FOO     [equivalently, #if !defined(FOO)]
  
!   4. In the second form above, the tokens forming the ‘#if’ expression
       must have come directly from the source file--no macro expansion
       must have been involved.  This is because macro definitions can
       change, and tracking whether or not a relevant change has been made
       is not worth the implementation cost.
  
!   5. There can be no ‘#else’ or ‘#elif’ directives at the outer
       conditional block level, because they would probably contain
       something of interest to a subsequent pass.
  
     First, when pushing a new file on the buffer stack,
! ‘_stack_include_file’ sets the controlling macro ‘mi_cmacro’ to ‘NULL’,
! and sets ‘mi_valid’ to ‘true’.  This indicates that the preprocessor has
  not yet encountered anything that would invalidate the multiple-include
  optimization.  As described in the next few paragraphs, these two
  variables having these values effectively indicates top-of-file.
  
     When about to return a token that is not part of a directive,
! ‘_cpp_lex_token’ sets ‘mi_valid’ to ‘false’.  This enforces the
  constraint that tokens outside the controlling conditional block
  invalidate the optimization.
  
!    The ‘do_if’, when appropriate, and ‘do_ifndef’ directive handlers
! pass the controlling macro to the function ‘push_conditional’.  cpplib
  maintains a stack of nested conditional blocks, and after processing
! every opening conditional this function pushes an ‘if_stack’ structure
  onto the stack.  In this structure it records the controlling macro for
  the block, provided there is one and we're at top-of-file (as described
! above).  If an ‘#elif’ or ‘#else’ directive is encountered, the
! controlling macro for that block is cleared to ‘NULL’.  Otherwise, it
! survives until the ‘#endif’ closing the block, upon which ‘do_endif’
! sets ‘mi_valid’ to true and stores the controlling macro in ‘mi_cmacro’.
  
!    ‘_cpp_handle_directive’ clears ‘mi_valid’ when processing any
  directive other than an opening conditional and the null directive.
  With this, and requiring top-of-file to record a controlling macro, and
! no ‘#else’ or ‘#elif’ for it to survive and be copied to ‘mi_cmacro’ by
! ‘do_endif’, we have enforced the absence of directives outside the main
  conditional block for the optimization to be on.
  
!    Note that whilst we are inside the conditional block, ‘mi_valid’ is
! likely to be reset to ‘false’, but this does not matter since the
! closing ‘#endif’ restores it to ‘true’ if appropriate.
  
!    Finally, since ‘_cpp_lex_direct’ pops the file off the buffer stack
! at ‘EOF’ without returning a token, if the ‘#endif’ directive was not
! followed by any tokens, ‘mi_valid’ is ‘true’ and ‘_cpp_pop_file_buffer’
  remembers the controlling macro associated with the file.  Subsequent
! calls to ‘stack_include_file’ result in no buffer being pushed if the
  controlling macro is defined, effecting the optimization.
  
     A quick word on how we handle the
  
       #if !defined FOO
  
! case.  ‘_cpp_parse_expr’ and ‘parse_defined’ take steps to see whether
! the three stages ‘!’, ‘defined-expression’ and ‘end-of-directive’ occur
! in order in a ‘#if’ expression.  If so, they return the guard macro to
! ‘do_if’ in the variable ‘mi_ind_cmacro’, and otherwise set it to ‘NULL’.
! ‘enter_macro_context’ sets ‘mi_valid’ to false, so if a macro was
  expanded whilst parsing any part of the expression, then the top-of-file
! test in ‘push_conditional’ fails and the optimization is turned off.
  
  
  File: cppinternals.info,  Node: Files,  Next: Concept Index,  Prev: Guard Macros,  Up: Top
*************** File Handling
*** 930,942 ****
  *************
  
  Fairly obviously, the file handling code of cpplib resides in the file
! 'files.cc'.  It takes care of the details of file searching, opening,
  reading and caching, for both the main source file and all the headers
  it recursively includes.
  
     The basic strategy is to minimize the number of system calls.  On
! many systems, the basic 'open ()' and 'fstat ()' system calls can be
! quite expensive.  For every '#include'-d file, we need to try all the
  directories in the search path until we find a match.  Some projects,
  such as glibc, pass twenty or thirty include paths on the command line,
  so this can rapidly become time consuming.
--- 930,942 ----
  *************
  
  Fairly obviously, the file handling code of cpplib resides in the file
! ‘files.cc’.  It takes care of the details of file searching, opening,
  reading and caching, for both the main source file and all the headers
  it recursively includes.
  
     The basic strategy is to minimize the number of system calls.  On
! many systems, the basic ‘open ()’ and ‘fstat ()’ system calls can be
! quite expensive.  For every ‘#include’-d file, we need to try all the
  directories in the search path until we find a match.  Some projects,
  such as glibc, pass twenty or thirty include paths on the command line,
  so this can rapidly become time consuming.
*************** repeating the filesystem queries whilst
*** 948,992 ****
  
     For each file we try to open, we store the constructed path in a
  splay tree.  This path first undergoes simplification by the function
! '_cpp_simplify_pathname'.  For example, '/usr/include/bits/../foo.h' is
! simplified to '/usr/include/foo.h' before we enter it in the splay tree
! and try to 'open ()' the file.  CPP will then find subsequent uses of
! 'foo.h', even as '/usr/include/foo.h', in the splay tree and save system
  calls.
  
     Further, it is likely the file contents have also been cached, saving
! a 'read ()' system call.  We don't bother caching the contents of header
  files that are re-inclusion protected, and whose re-inclusion macro is
  defined when we leave the header file for the first time.  If the host
  supports it, we try to map suitably large files into memory, rather than
  reading them in directly.
  
     The include paths are internally stored on a null-terminated
! singly-linked list, starting with the '"header.h"' directory search
! chain, which then links into the '' directory chain.
  
!    Files included with the '' syntax start the lookup directly in
  the second half of this chain.  However, files included with the
! '"foo.h"' syntax start at the beginning of the chain, but with one extra
  directory prepended.  This is the directory of the current file; the one
! containing the '#include' directive.  Prepending this directory on a
! per-file basis is handled by the function 'search_from'.
  
     Note that a header included with a directory component, such as
! '#include "mydir/foo.h"' and opened as '/usr/local/include/mydir/foo.h',
! will have the complete path minus the basename 'foo.h' as the current
  directory.
  
     Enough information is stored in the splay tree that CPP can
  immediately tell whether it can skip the header file because of the
  multiple include optimization, whether the file didn't exist or couldn't
  be opened for some reason, or whether the header was flagged not to be
! re-used, as it is with the obsolete '#import' directive.
  
     For the benefit of MS-DOS filesystems with an 8.3 filename
  limitation, CPP offers the ability to treat various include file names
  as aliases for the real header files with shorter names.  The map from
! one to the other is found in a special file called 'header.gcc', stored
  in the command line (or system) include directories to which the mapping
  applies.  This may be higher up the directory tree than the full path to
  the file minus the base name.
--- 948,992 ----
  
     For each file we try to open, we store the constructed path in a
  splay tree.  This path first undergoes simplification by the function
! ‘_cpp_simplify_pathname’.  For example, ‘/usr/include/bits/../foo.h’ is
! simplified to ‘/usr/include/foo.h’ before we enter it in the splay tree
! and try to ‘open ()’ the file.  CPP will then find subsequent uses of
! ‘foo.h’, even as ‘/usr/include/foo.h’, in the splay tree and save system
  calls.
  
     Further, it is likely the file contents have also been cached, saving
! a ‘read ()’ system call.  We don't bother caching the contents of header
  files that are re-inclusion protected, and whose re-inclusion macro is
  defined when we leave the header file for the first time.  If the host
  supports it, we try to map suitably large files into memory, rather than
  reading them in directly.
  
     The include paths are internally stored on a null-terminated
! singly-linked list, starting with the ‘"header.h"’ directory search
! chain, which then links into the ‘’ directory chain.
  
!    Files included with the ‘’ syntax start the lookup directly in
  the second half of this chain.  However, files included with the
! ‘"foo.h"’ syntax start at the beginning of the chain, but with one extra
  directory prepended.  This is the directory of the current file; the one
! containing the ‘#include’ directive.  Prepending this directory on a
! per-file basis is handled by the function ‘search_from’.
  
     Note that a header included with a directory component, such as
! ‘#include "mydir/foo.h"’ and opened as ‘/usr/local/include/mydir/foo.h’,
! will have the complete path minus the basename ‘foo.h’ as the current
  directory.
  
     Enough information is stored in the splay tree that CPP can
  immediately tell whether it can skip the header file because of the
  multiple include optimization, whether the file didn't exist or couldn't
  be opened for some reason, or whether the header was flagged not to be
! re-used, as it is with the obsolete ‘#import’ directive.
  
     For the benefit of MS-DOS filesystems with an 8.3 filename
  limitation, CPP offers the ability to treat various include file names
  as aliases for the real header files with shorter names.  The map from
! one to the other is found in a special file called ‘header.gcc’, stored
  in the command line (or system) include directories to which the mapping
  applies.  This may be higher up the directory tree than the full path to
  the file minus the base name.
*************** Concept Index
*** 1026,1042 ****
  
  Tag Table:
  Node: Top905
! Node: Conventions2743
! Node: Lexer3685
! Ref: Invalid identifiers11600
! Ref: Lexing a line13550
! Node: Hash Nodes18319
! Node: Macro Expansion21198
! Node: Token Spacing30142
! Node: Line Numbering35998
! Node: Guard Macros40084
! Node: Files44875
! Node: Concept Index48342
  
  End Tag Table
  
--- 1026,1042 ----
  
  Tag Table:
  Node: Top905
! Node: Conventions2747
! Node: Lexer3709
! Ref: Invalid identifiers11844
! Ref: Lexing a line13850
! Node: Hash Nodes18679
! Node: Macro Expansion21620
! Node: Token Spacing30660
! Node: Line Numbering36640
! Node: Guard Macros40777
! Node: Files45800
! Node: Concept Index49355
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/doc/fsf-funding.7 gcc-13.5.0-RC-20260904/gcc/doc/fsf-funding.7
*** gcc-13.4.0/gcc/doc/fsf-funding.7	Thu Jun  5 16:06:29 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/fsf-funding.7	Fri Sep  4 07:36:30 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,146 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "FSF-FUNDING 7"
! .TH FSF-FUNDING 7 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  fsf\-funding \- Funding Free Software
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
  .SS "Funding Free Software"
  .IX Subsection "Funding Free Software"
--- 53,71 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "FSF-FUNDING 7"
! .TH FSF-FUNDING 7 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  fsf\-funding \- Funding Free Software
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
  .SS "Funding Free Software"
  .IX Subsection "Funding Free Software"
*************** development.  The most effective approac
*** 150,156 ****
  commercial redistributors to donate.
  .PP
  Users of free software systems can boost the pace of development by
! encouraging for-a-fee distributors to donate part of their selling price
  to free software developers\-\-\-the Free Software Foundation, and others.
  .PP
  The way to convince distributors to do this is to demand it and expect
--- 75,81 ----
  commercial redistributors to donate.
  .PP
  Users of free software systems can boost the pace of development by
! encouraging for\-a\-fee distributors to donate part of their selling price
  to free software developers\-\-\-the Free Software Foundation, and others.
  .PP
  The way to convince distributors to do this is to demand it and expect
*************** how much they give to free software deve
*** 159,170 ****
  they must compete to be the one who gives the most.
  .PP
  To make this approach work, you must insist on numbers that you can
! compare, such as, \*(L"We will donate ten dollars to the Frobnitz project
! for each disk sold.\*(R"  Don't be satisfied with a vague promise, such as
! \&\*(L"A portion of the profits are donated,\*(R" since it doesn't give a basis
  for comparison.
  .PP
! Even a precise fraction \*(L"of the profits from this disk\*(R" is not very
  meaningful, since creative accounting and unrelated business decisions
  can greatly alter what fraction of the sales price counts as profit.
  If the price you pay is \f(CW$50\fR, ten percent of the profit is probably
--- 84,95 ----
  they must compete to be the one who gives the most.
  .PP
  To make this approach work, you must insist on numbers that you can
! compare, such as, "We will donate ten dollars to the Frobnitz project
! for each disk sold."  Don\*(Aqt be satisfied with a vague promise, such as
! "A portion of the profits are donated," since it doesn\*(Aqt give a basis
  for comparison.
  .PP
! 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 \f(CW$50\fR, ten percent of the profit is probably
*************** less than a dollar; it might be a few ce
*** 172,192 ****
  .PP
  Some redistributors do development work themselves.  This is useful too;
  but to keep everyone honest, you need to inquire how much they do, and
! what kind.  Some kinds of development make much more long-term
  difference than others.  For example, maintaining a separate version of
  a program contributes very little; maintaining the standard version of a
  program for the whole community contributes much.  Easy new ports
  contribute little, since someone else would surely do them; difficult
! ports such as adding a new \s-1CPU\s0 to the \s-1GNU\s0 Compiler Collection contribute more;
  major new features or packages contribute the most.
  .PP
! By establishing the idea that supporting further development is \*(L"the
! proper thing to do\*(R" when distributing free software for a fee, we can
  assure a steady flow of resources into making more free software.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7).
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 1994 Free Software Foundation, Inc.
  Verbatim copying and redistribution of this section is permitted
--- 97,117 ----
  .PP
  Some redistributors do development work themselves.  This is useful too;
  but to keep everyone honest, you need to inquire how much they do, and
! what kind.  Some kinds of development make much more long\-term
  difference than others.  For example, maintaining a separate version of
  a program contributes very little; maintaining the standard version of a
  program for the whole community contributes much.  Easy new ports
  contribute little, since someone else would surely do them; difficult
! ports such as adding a new CPU to the GNU Compiler Collection contribute more;
  major new features or packages contribute the most.
  .PP
! 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.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7).
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 1994 Free Software Foundation, Inc.
  Verbatim copying and redistribution of this section is permitted
diff -Nrcpad gcc-13.4.0/gcc/doc/g++.1 gcc-13.5.0-RC-20260904/gcc/doc/g++.1
*** gcc-13.4.0/gcc/doc/g++.1	Thu Jun  5 16:21:57 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/g++.1	Fri Sep  4 07:50:37 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,161 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GCC 1"
! .TH GCC 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gcc \- GNU project C and C++ compiler
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
  gcc [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR] [\fB\-std=\fR\fIstandard\fR]
      [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
      [\fB\-W\fR\fIwarn\fR...] [\fB\-Wpedantic\fR]
      [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
      [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
!     [\fB\-f\fR\fIoption\fR...] [\fB\-m\fR\fImachine-option\fR...]
      [\fB\-o\fR \fIoutfile\fR] [@\fIfile\fR] \fIinfile\fR...
  .PP
  Only the most useful options are listed here; see below for the
  remainder.  \fBg++\fR accepts mostly the same options as \fBgcc\fR.
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
! When you invoke \s-1GCC,\s0 it normally does preprocessing, compilation,
! assembly and linking.  The \*(L"overall options\*(R" allow you to stop this
  process at an intermediate stage.  For example, the \fB\-c\fR option
  says not to run the linker.  Then the output consists of object files
  output by the assembler.
--- 53,86 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GCC 1"
! .TH GCC 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gcc \- GNU project C and C++ compiler
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
  gcc [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR] [\fB\-std=\fR\fIstandard\fR]
      [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
      [\fB\-W\fR\fIwarn\fR...] [\fB\-Wpedantic\fR]
      [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
      [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
!     [\fB\-f\fR\fIoption\fR...] [\fB\-m\fR\fImachine\-option\fR...]
      [\fB\-o\fR \fIoutfile\fR] [@\fIfile\fR] \fIinfile\fR...
  .PP
  Only the most useful options are listed here; see below for the
  remainder.  \fBg++\fR accepts mostly the same options as \fBgcc\fR.
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
! When you invoke 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 \fB\-c\fR option
  says not to run the linker.  Then the output consists of object files
  output by the assembler.
*************** control the preprocessor and others the
*** 165,188 ****
  options control the assembler and linker; most of these are not
  documented here, since you rarely need to use any of them.
  .PP
! Most of the command-line options that you can use with \s-1GCC\s0 are useful
  for C programs; when an option is only useful with another language
! (usually \*(C+), the explanation says so explicitly.  If the description
  for a particular option does not mention a source language, you can use
  that option with all supported languages.
  .PP
! The usual way to run \s-1GCC\s0 is to run the executable called \fBgcc\fR, or
! \&\fImachine\fR\fB\-gcc\fR when cross-compiling, or
! \&\fImachine\fR\fB\-gcc\-\fR\fIversion\fR to run a specific version of \s-1GCC.\s0
! When you compile \*(C+ programs, you should invoke \s-1GCC\s0 as \fBg++\fR 
  instead.
  .PP
  The \fBgcc\fR program accepts options and file names as operands.  Many
! options have multi-letter names; therefore multiple single-letter options
  may \fInot\fR be grouped: \fB\-dv\fR is very different from \fB\-d\ \-v\fR.
  .PP
  You can mix options and other arguments.  For the most part, the order
! you use doesn't matter.  Order does matter when you use several
  options of the same kind; for example, if you specify \fB\-L\fR more
  than once, the directories are searched in the order specified.  Also,
  the placement of the \fB\-l\fR option is significant.
--- 90,113 ----
  options control the assembler and linker; most of these are not
  documented here, since you rarely need to use any of them.
  .PP
! Most of the command\-line options that you can use with 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.
  .PP
! The usual way to run GCC is to run the executable called \fBgcc\fR, or
! \&\fImachine\fR\fB\-gcc\fR when cross\-compiling, or
! \&\fImachine\fR\fB\-gcc\-\fR\fIversion\fR to run a specific version of GCC.
! When you compile C++ programs, you should invoke GCC as \fBg++\fR 
  instead.
  .PP
  The \fBgcc\fR program accepts options and file names as operands.  Many
! options have multi\-letter names; therefore multiple single\-letter options
  may \fInot\fR be grouped: \fB\-dv\fR is very different from \fB\-d\ \-v\fR.
  .PP
  You can mix options and other arguments.  For the most part, the order
! you use doesn\*(Aqt matter.  Order does matter when you use several
  options of the same kind; for example, if you specify \fB\-L\fR more
  than once, the directories are searched in the order specified.  Also,
  the placement of the \fB\-l\fR option is significant.
*************** integers followed by a byte size suffix
*** 205,214 ****
  such as \f(CW\*(C`kB\*(C'\fR and \f(CW\*(C`KiB\*(C'\fR for kilobyte and kibibyte, respectively,
  \&\f(CW\*(C`MB\*(C'\fR and \f(CW\*(C`MiB\*(C'\fR for megabyte and mebibyte, \f(CW\*(C`GB\*(C'\fR and
  \&\f(CW\*(C`GiB\*(C'\fR for gigabyte and gigibyte, and so on.  Such arguments are
! designated by \fIbyte-size\fR in the following text.  Refer to the \s-1NIST,
! IEC,\s0 and other relevant national and international standards for the full
  listing and explanation of the binary and decimal byte size prefixes.
! .SH "OPTIONS"
  .IX Header "OPTIONS"
  .SS "Option Summary"
  .IX Subsection "Option Summary"
--- 130,139 ----
  such as \f(CW\*(C`kB\*(C'\fR and \f(CW\*(C`KiB\*(C'\fR for kilobyte and kibibyte, respectively,
  \&\f(CW\*(C`MB\*(C'\fR and \f(CW\*(C`MiB\*(C'\fR for megabyte and mebibyte, \f(CW\*(C`GB\*(C'\fR and
  \&\f(CW\*(C`GiB\*(C'\fR for gigabyte and gigibyte, and so on.  Such arguments are
! designated by \fIbyte\-size\fR in the following text.  Refer to the NIST,
! IEC, and other relevant national and international standards for the full
  listing and explanation of the binary and decimal byte size prefixes.
! .SH OPTIONS
  .IX Header "OPTIONS"
  .SS "Option Summary"
  .IX Subsection "Option Summary"
*************** in the following sections.
*** 233,245 ****
  \&\-flax\-vector\-conversions  \-fms\-extensions
  \&\-foffload=\fR\fIarg\fR  \fB\-foffload\-options=\fR\fIarg\fR
  \&\fB\-fopenacc  \-fopenacc\-dim=\fR\fIgeom\fR
! \&\fB\-fopenmp  \-fopenmp\-simd  \-fopenmp\-target\-simd\-clone\fR[\fB=\fR\fIdevice-type\fR]
  \&\fB\-fpermitted\-flt\-eval\-methods=\fR\fIstandard\fR
  \&\fB\-fplan9\-extensions  \-fsigned\-bitfields  \-funsigned\-bitfields
  \&\-fsigned\-char  \-funsigned\-char \-fstrict\-flex\-arrays[=\fR\fIn\fR\fB]
  \&\-fsso\-struct=\fR\fIendianness\fR
! .IP "\fI\*(C+ Language Options\fR" 4
! .IX Item " Language Options"
  \&\fB\-fabi\-version=\fR\fIn\fR  \fB\-fno\-access\-control
  \&\-faligned\-new=\fR\fIn\fR  \fB\-fargs\-in\-order=\fR\fIn\fR  \fB\-fchar8_t  \-fcheck\-new
  \&\-fconstexpr\-depth=\fR\fIn\fR  \fB\-fconstexpr\-cache\-depth=\fR\fIn\fR
--- 158,170 ----
  \&\-flax\-vector\-conversions  \-fms\-extensions
  \&\-foffload=\fR\fIarg\fR  \fB\-foffload\-options=\fR\fIarg\fR
  \&\fB\-fopenacc  \-fopenacc\-dim=\fR\fIgeom\fR
! \&\fB\-fopenmp  \-fopenmp\-simd  \-fopenmp\-target\-simd\-clone\fR[\fB=\fR\fIdevice\-type\fR]
  \&\fB\-fpermitted\-flt\-eval\-methods=\fR\fIstandard\fR
  \&\fB\-fplan9\-extensions  \-fsigned\-bitfields  \-funsigned\-bitfields
  \&\-fsigned\-char  \-funsigned\-char \-fstrict\-flex\-arrays[=\fR\fIn\fR\fB]
  \&\-fsso\-struct=\fR\fIendianness\fR
! .IP "\fIC++ Language Options\fR" 4
! .IX Item "C++ Language Options"
  \&\fB\-fabi\-version=\fR\fIn\fR  \fB\-fno\-access\-control
  \&\-faligned\-new=\fR\fIn\fR  \fB\-fargs\-in\-order=\fR\fIn\fR  \fB\-fchar8_t  \-fcheck\-new
  \&\-fconstexpr\-depth=\fR\fIn\fR  \fB\-fconstexpr\-cache\-depth=\fR\fIn\fR
*************** in the following sections.
*** 300,308 ****
  \&\-Wno\-terminate  \-Wuseless\-cast  \-Wno\-vexing\-parse
  \&\-Wvirtual\-inheritance
  \&\-Wno\-virtual\-move\-assign  \-Wvolatile  \-Wzero\-as\-null\-pointer\-constant\fR
! .IP "\fIObjective-C and Objective\-\*(C+ Language Options\fR" 4
! .IX Item "Objective-C and Objective- Language Options"
! \&\fB\-fconstant\-string\-class=\fR\fIclass-name\fR
  \&\fB\-fgnu\-runtime  \-fnext\-runtime
  \&\-fno\-nil\-receivers
  \&\-fobjc\-abi\-version=\fR\fIn\fR
--- 225,233 ----
  \&\-Wno\-terminate  \-Wuseless\-cast  \-Wno\-vexing\-parse
  \&\-Wvirtual\-inheritance
  \&\-Wno\-virtual\-move\-assign  \-Wvolatile  \-Wzero\-as\-null\-pointer\-constant\fR
! .IP "\fIObjective\-C and Objective\-C++ Language Options\fR" 4
! .IX Item "Objective-C and Objective-C++ Language Options"
! \&\fB\-fconstant\-string\-class=\fR\fIclass\-name\fR
  \&\fB\-fgnu\-runtime  \-fnext\-runtime
  \&\-fno\-nil\-receivers
  \&\-fobjc\-abi\-version=\fR\fIn\fR
*************** in the following sections.
*** 325,334 ****
  .IX Item "Diagnostic Message Formatting Options"
  \&\fB\-fmessage\-length=\fR\fIn\fR
  \&\fB\-fdiagnostics\-plain\-output
! \&\-fdiagnostics\-show\-location=\fR[\fBonce\fR|\fBevery-line\fR]
  \&\fB\-fdiagnostics\-color=\fR[\fBauto\fR|\fBnever\fR|\fBalways\fR]
  \&\fB\-fdiagnostics\-urls=\fR[\fBauto\fR|\fBnever\fR|\fBalways\fR]
! \&\fB\-fdiagnostics\-format=\fR[\fBtext\fR|\fBsarif-stderr\fR|\fBsarif-file\fR|\fBjson\fR|\fBjson-stderr\fR|\fBjson-file\fR]
  \&\fB\-fno\-diagnostics\-show\-option  \-fno\-diagnostics\-show\-caret
  \&\-fno\-diagnostics\-show\-labels  \-fno\-diagnostics\-show\-line\-numbers
  \&\-fno\-diagnostics\-show\-cwe
--- 250,259 ----
  .IX Item "Diagnostic Message Formatting Options"
  \&\fB\-fmessage\-length=\fR\fIn\fR
  \&\fB\-fdiagnostics\-plain\-output
! \&\-fdiagnostics\-show\-location=\fR[\fBonce\fR|\fBevery\-line\fR]
  \&\fB\-fdiagnostics\-color=\fR[\fBauto\fR|\fBnever\fR|\fBalways\fR]
  \&\fB\-fdiagnostics\-urls=\fR[\fBauto\fR|\fBnever\fR|\fBalways\fR]
! \&\fB\-fdiagnostics\-format=\fR[\fBtext\fR|\fBsarif\-stderr\fR|\fBsarif\-file\fR|\fBjson\fR|\fBjson\-stderr\fR|\fBjson\-file\fR]
  \&\fB\-fno\-diagnostics\-show\-option  \-fno\-diagnostics\-show\-caret
  \&\-fno\-diagnostics\-show\-labels  \-fno\-diagnostics\-show\-line\-numbers
  \&\-fno\-diagnostics\-show\-cwe
*************** in the following sections.
*** 336,342 ****
  \&\-fdiagnostics\-minimum\-margin\-width=\fR\fIwidth\fR
  \&\fB\-fdiagnostics\-parseable\-fixits  \-fdiagnostics\-generate\-patch
  \&\-fdiagnostics\-show\-template\-tree  \-fno\-elide\-type
! \&\-fdiagnostics\-path\-format=\fR[\fBnone\fR|\fBseparate-events\fR|\fBinline-events\fR]
  \&\fB\-fdiagnostics\-show\-path\-depths
  \&\-fno\-show\-column
  \&\-fdiagnostics\-column\-unit=\fR[\fBdisplay\fR|\fBbyte\fR]
--- 261,267 ----
  \&\-fdiagnostics\-minimum\-margin\-width=\fR\fIwidth\fR
  \&\fB\-fdiagnostics\-parseable\-fixits  \-fdiagnostics\-generate\-patch
  \&\-fdiagnostics\-show\-template\-tree  \-fno\-elide\-type
! \&\-fdiagnostics\-path\-format=\fR[\fBnone\fR|\fBseparate\-events\fR|\fBinline\-events\fR]
  \&\fB\-fdiagnostics\-show\-path\-depths
  \&\-fno\-show\-column
  \&\-fdiagnostics\-column\-unit=\fR[\fBdisplay\fR|\fBbyte\fR]
*************** in the following sections.
*** 348,355 ****
  \&\-pedantic\-errors
  \&\-w  \-Wextra  \-Wall  \-Wabi=\fR\fIn\fR
  \&\fB\-Waddress  \-Wno\-address\-of\-packed\-member  \-Waggregate\-return
! \&\-Walloc\-size\-larger\-than=\fR\fIbyte-size\fR  \fB\-Walloc\-zero
! \&\-Walloca  \-Walloca\-larger\-than=\fR\fIbyte-size\fR
  \&\fB\-Wno\-aggressive\-loop\-optimizations
  \&\-Warith\-conversion
  \&\-Warray\-bounds  \-Warray\-bounds=\fR\fIn\fR  \fB\-Warray\-compare
--- 273,280 ----
  \&\-pedantic\-errors
  \&\-w  \-Wextra  \-Wall  \-Wabi=\fR\fIn\fR
  \&\fB\-Waddress  \-Wno\-address\-of\-packed\-member  \-Waggregate\-return
! \&\-Walloc\-size\-larger\-than=\fR\fIbyte\-size\fR  \fB\-Walloc\-zero
! \&\-Walloca  \-Walloca\-larger\-than=\fR\fIbyte\-size\fR
  \&\fB\-Wno\-aggressive\-loop\-optimizations
  \&\-Warith\-conversion
  \&\-Warray\-bounds  \-Warray\-bounds=\fR\fIn\fR  \fB\-Warray\-compare
*************** in the following sections.
*** 384,390 ****
  \&\-Wformat\-nonliteral  \-Wformat\-overflow=\fR\fIn\fR
  \&\fB\-Wformat\-security  \-Wformat\-signedness  \-Wformat\-truncation=\fR\fIn\fR
  \&\fB\-Wformat\-y2k  \-Wframe\-address
! \&\-Wframe\-larger\-than=\fR\fIbyte-size\fR  \fB\-Wno\-free\-nonheap\-object
  \&\-Wno\-if\-not\-aligned  \-Wno\-ignored\-attributes
  \&\-Wignored\-qualifiers  \-Wno\-incompatible\-pointer\-types
  \&\-Wimplicit  \-Wimplicit\-fallthrough  \-Wimplicit\-fallthrough=\fR\fIn\fR
--- 309,315 ----
  \&\-Wformat\-nonliteral  \-Wformat\-overflow=\fR\fIn\fR
  \&\fB\-Wformat\-security  \-Wformat\-signedness  \-Wformat\-truncation=\fR\fIn\fR
  \&\fB\-Wformat\-y2k  \-Wframe\-address
! \&\-Wframe\-larger\-than=\fR\fIbyte\-size\fR  \fB\-Wno\-free\-nonheap\-object
  \&\-Wno\-if\-not\-aligned  \-Wno\-ignored\-attributes
  \&\-Wignored\-qualifiers  \-Wno\-incompatible\-pointer\-types
  \&\-Wimplicit  \-Wimplicit\-fallthrough  \-Wimplicit\-fallthrough=\fR\fIn\fR
*************** in the following sections.
*** 393,399 ****
  \&\-Winit\-self  \-Winline  \-Wno\-int\-conversion  \-Wint\-in\-bool\-context
  \&\-Wno\-int\-to\-pointer\-cast  \-Wno\-invalid\-memory\-model
  \&\-Winvalid\-pch  \-Winvalid\-utf8  \-Wno\-unicode  \-Wjump\-misses\-init
! \&\-Wlarger\-than=\fR\fIbyte-size\fR  \fB\-Wlogical\-not\-parentheses  \-Wlogical\-op
  \&\-Wlong\-long  \-Wno\-lto\-type\-mismatch \-Wmain  \-Wmaybe\-uninitialized
  \&\-Wmemset\-elt\-size  \-Wmemset\-transposed\-args
  \&\-Wmisleading\-indentation  \-Wmissing\-attributes  \-Wmissing\-braces
--- 318,324 ----
  \&\-Winit\-self  \-Winline  \-Wno\-int\-conversion  \-Wint\-in\-bool\-context
  \&\-Wno\-int\-to\-pointer\-cast  \-Wno\-invalid\-memory\-model
  \&\-Winvalid\-pch  \-Winvalid\-utf8  \-Wno\-unicode  \-Wjump\-misses\-init
! \&\-Wlarger\-than=\fR\fIbyte\-size\fR  \fB\-Wlogical\-not\-parentheses  \-Wlogical\-op
  \&\-Wlong\-long  \-Wno\-lto\-type\-mismatch \-Wmain  \-Wmaybe\-uninitialized
  \&\-Wmemset\-elt\-size  \-Wmemset\-transposed\-args
  \&\-Wmisleading\-indentation  \-Wmissing\-attributes  \-Wmissing\-braces
*************** in the following sections.
*** 419,425 ****
  \&\-Wno\-sizeof\-array\-argument
  \&\-Wsizeof\-array\-div
  \&\-Wsizeof\-pointer\-div  \-Wsizeof\-pointer\-memaccess
! \&\-Wstack\-protector  \-Wstack\-usage=\fR\fIbyte-size\fR  \fB\-Wstrict\-aliasing
  \&\-Wstrict\-aliasing=n  \-Wstrict\-overflow  \-Wstrict\-overflow=\fR\fIn\fR
  \&\fB\-Wstring\-compare
  \&\-Wno\-stringop\-overflow \-Wno\-stringop\-overread
--- 344,350 ----
  \&\-Wno\-sizeof\-array\-argument
  \&\-Wsizeof\-array\-div
  \&\-Wsizeof\-pointer\-div  \-Wsizeof\-pointer\-memaccess
! \&\-Wstack\-protector  \-Wstack\-usage=\fR\fIbyte\-size\fR  \fB\-Wstrict\-aliasing
  \&\-Wstrict\-aliasing=n  \-Wstrict\-overflow  \-Wstrict\-overflow=\fR\fIn\fR
  \&\fB\-Wstring\-compare
  \&\-Wno\-stringop\-overflow \-Wno\-stringop\-overread
*************** in the following sections.
*** 439,445 ****
  \&\-Wunused\-value  \-Wunused\-variable
  \&\-Wno\-varargs  \-Wvariadic\-macros
  \&\-Wvector\-operation\-performance
! \&\-Wvla  \-Wvla\-larger\-than=\fR\fIbyte-size\fR  \fB\-Wno\-vla\-larger\-than
  \&\-Wvolatile\-register\-var  \-Wwrite\-strings
  \&\-Wxor\-used\-as\-pow
  \&\-Wzero\-length\-bounds\fR
--- 364,370 ----
  \&\-Wunused\-value  \-Wunused\-variable
  \&\-Wno\-varargs  \-Wvariadic\-macros
  \&\-Wvector\-operation\-performance
! \&\-Wvla  \-Wvla\-larger\-than=\fR\fIbyte\-size\fR  \fB\-Wno\-vla\-larger\-than
  \&\-Wvolatile\-register\-var  \-Wwrite\-strings
  \&\-Wxor\-used\-as\-pow
  \&\-Wzero\-length\-bounds\fR
*************** in the following sections.
*** 515,521 ****
  \&\-Wno\-analyzer\-va\-list\-use\-after\-va\-end
  \&\-Wno\-analyzer\-write\-to\-const
  \&\-Wno\-analyzer\-write\-to\-string\-literal\fR
! .IP "\fIC and Objective-C-only Warning Options\fR" 4
  .IX Item "C and Objective-C-only Warning Options"
  \&\fB\-Wbad\-function\-cast  \-Wmissing\-declarations
  \&\-Wmissing\-parameter\-type  \-Wmissing\-prototypes  \-Wnested\-externs
--- 440,446 ----
  \&\-Wno\-analyzer\-va\-list\-use\-after\-va\-end
  \&\-Wno\-analyzer\-write\-to\-const
  \&\-Wno\-analyzer\-write\-to\-string\-literal\fR
! .IP "\fIC and Objective\-C\-only Warning Options\fR" 4
  .IX Item "C and Objective-C-only Warning Options"
  \&\fB\-Wbad\-function\-cast  \-Wmissing\-declarations
  \&\-Wmissing\-parameter\-type  \-Wmissing\-prototypes  \-Wnested\-externs
*************** in the following sections.
*** 540,546 ****
  \&\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR  \fB\-fdebug\-types\-section
  \&\-fno\-eliminate\-unused\-debug\-types
  \&\-femit\-struct\-debug\-baseonly  \-femit\-struct\-debug\-reduced
! \&\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR]
  \&\fB\-fno\-eliminate\-unused\-debug\-symbols  \-femit\-class\-debug\-always
  \&\-fno\-merge\-debug\-strings  \-fno\-dwarf2\-cfi\-asm
  \&\-fvar\-tracking  \-fvar\-tracking\-assignments\fR
--- 465,471 ----
  \&\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR  \fB\-fdebug\-types\-section
  \&\-fno\-eliminate\-unused\-debug\-types
  \&\-femit\-struct\-debug\-baseonly  \-femit\-struct\-debug\-reduced
! \&\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec\-list\fR]
  \&\fB\-fno\-eliminate\-unused\-debug\-symbols  \-femit\-class\-debug\-always
  \&\-fno\-merge\-debug\-strings  \-fno\-dwarf2\-cfi\-asm
  \&\-fvar\-tracking  \-fvar\-tracking\-assignments\fR
*************** in the following sections.
*** 646,652 ****
  \&\fB\-fprofile\-note=\fR\fIpath\fR \fB\-fprofile\-prefix\-path=\fR\fIpath\fR
  \&\fB\-fprofile\-update=\fR\fImethod\fR \fB\-fprofile\-filter\-files=\fR\fIregex\fR
  \&\fB\-fprofile\-exclude\-files=\fR\fIregex\fR
! \&\fB\-fprofile\-reproducible=\fR[\fBmultithreaded\fR|\fBparallel-runs\fR|\fBserial\fR]
  \&\fB\-fsanitize=\fR\fIstyle\fR  \fB\-fsanitize\-recover  \-fsanitize\-recover=\fR\fIstyle\fR
  \&\fB\-fsanitize\-trap   \-fsanitize\-trap=\fR\fIstyle\fR
  \&\fB\-fasan\-shadow\-offset=\fR\fInumber\fR  \fB\-fsanitize\-sections=\fR\fIs1\fR\fB,\fR\fIs2\fR\fB,...
--- 571,577 ----
  \&\fB\-fprofile\-note=\fR\fIpath\fR \fB\-fprofile\-prefix\-path=\fR\fIpath\fR
  \&\fB\-fprofile\-update=\fR\fImethod\fR \fB\-fprofile\-filter\-files=\fR\fIregex\fR
  \&\fB\-fprofile\-exclude\-files=\fR\fIregex\fR
! \&\fB\-fprofile\-reproducible=\fR[\fBmultithreaded\fR|\fBparallel\-runs\fR|\fBserial\fR]
  \&\fB\-fsanitize=\fR\fIstyle\fR  \fB\-fsanitize\-recover  \-fsanitize\-recover=\fR\fIstyle\fR
  \&\fB\-fsanitize\-trap   \-fsanitize\-trap=\fR\fIstyle\fR
  \&\fB\-fasan\-shadow\-offset=\fR\fInumber\fR  \fB\-fsanitize\-sections=\fR\fIs1\fR\fB,\fR\fIs2\fR\fB,...
*************** in the following sections.
*** 687,693 ****
  \&\fB\-Wa,\fR\fIoption\fR  \fB\-Xassembler\fR \fIoption\fR
  .IP "\fILinker Options\fR" 4
  .IX Item "Linker Options"
! \&\fIobject-file-name\fR  \fB\-fuse\-ld=\fR\fIlinker\fR  \fB\-l\fR\fIlibrary\fR
  \&\fB\-nostartfiles  \-nodefaultlibs  \-nolibc  \-nostdlib  \-nostdlib++
  \&\-e\fR \fIentry\fR  \fB\-\-entry=\fR\fIentry\fR
  \&\fB\-pie  \-pthread  \-r  \-rdynamic
--- 612,618 ----
  \&\fB\-Wa,\fR\fIoption\fR  \fB\-Xassembler\fR \fIoption\fR
  .IP "\fILinker Options\fR" 4
  .IX Item "Linker Options"
! \&\fIobject\-file\-name\fR  \fB\-fuse\-ld=\fR\fIlinker\fR  \fB\-l\fR\fIlibrary\fR
  \&\fB\-nostartfiles  \-nodefaultlibs  \-nolibc  \-nostdlib  \-nostdlib++
  \&\-e\fR \fIentry\fR  \fB\-\-entry=\fR\fIentry\fR
  \&\fB\-pie  \-pthread  \-r  \-rdynamic
*************** in the following sections.
*** 729,740 ****
  \&\fB\-d\fR\fIletters\fR  \fB\-dumpspecs  \-dumpmachine  \-dumpversion
  \&\-dumpfullversion  \-fcallgraph\-info\fR[\fB=su,da\fR]
  \&\fB\-fchecking  \-fchecking=\fR\fIn\fR
! \&\fB\-fdbg\-cnt\-list  \-fdbg\-cnt=\fR\fIcounter-value-list\fR
  \&\fB\-fdisable\-ipa\-\fR\fIpass_name\fR
  \&\fB\-fdisable\-rtl\-\fR\fIpass_name\fR
! \&\fB\-fdisable\-rtl\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR
  \&\fB\-fdisable\-tree\-\fR\fIpass_name\fR
! \&\fB\-fdisable\-tree\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR
  \&\fB\-fdump\-debug  \-fdump\-earlydebug
  \&\-fdump\-noaddr  \-fdump\-unnumbered  \-fdump\-unnumbered\-links
  \&\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR]
--- 654,665 ----
  \&\fB\-d\fR\fIletters\fR  \fB\-dumpspecs  \-dumpmachine  \-dumpversion
  \&\-dumpfullversion  \-fcallgraph\-info\fR[\fB=su,da\fR]
  \&\fB\-fchecking  \-fchecking=\fR\fIn\fR
! \&\fB\-fdbg\-cnt\-list  \-fdbg\-cnt=\fR\fIcounter\-value\-list\fR
  \&\fB\-fdisable\-ipa\-\fR\fIpass_name\fR
  \&\fB\-fdisable\-rtl\-\fR\fIpass_name\fR
! \&\fB\-fdisable\-rtl\-\fR\fIpass\-name\fR\fB=\fR\fIrange\-list\fR
  \&\fB\-fdisable\-tree\-\fR\fIpass_name\fR
! \&\fB\-fdisable\-tree\-\fR\fIpass\-name\fR\fB=\fR\fIrange\-list\fR
  \&\fB\-fdump\-debug  \-fdump\-earlydebug
  \&\-fdump\-noaddr  \-fdump\-unnumbered  \-fdump\-unnumbered\-links
  \&\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR]
*************** in the following sections.
*** 752,758 ****
  \&\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR
  \&\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]  \fB\-fcompare\-debug\-second
  \&\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR
! \&\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR
  \&\fB\-fira\-verbose=\fR\fIn\fR
  \&\fB\-flto\-report  \-flto\-report\-wpa  \-fmem\-report\-wpa
  \&\-fmem\-report  \-fpre\-ipa\-mem\-report  \-fpost\-ipa\-mem\-report
--- 677,683 ----
  \&\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR
  \&\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]  \fB\-fcompare\-debug\-second
  \&\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR
! \&\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR
  \&\fB\-fira\-verbose=\fR\fIn\fR
  \&\fB\-flto\-report  \-flto\-report\-wpa  \-fmem\-report\-wpa
  \&\-fmem\-report  \-fpre\-ipa\-mem\-report  \-fpost\-ipa\-mem\-report
*************** in the following sections.
*** 767,773 ****
  \&\-print\-prog\-name=\fR\fIprogram\fR  \fB\-print\-search\-dirs  \-Q
  \&\-print\-sysroot  \-print\-sysroot\-headers\-suffix
  \&\-save\-temps  \-save\-temps=cwd  \-save\-temps=obj  \-time\fR[\fB=\fR\fIfile\fR]
! .IP "\fIMachine-Dependent Options\fR" 4
  .IX Item "Machine-Dependent Options"
  \&\fIAArch64 Options\fR
  \&\fB\-mabi=\fR\fIname\fR  \fB\-mbig\-endian  \-mlittle\-endian
--- 692,698 ----
  \&\-print\-prog\-name=\fR\fIprogram\fR  \fB\-print\-search\-dirs  \-Q
  \&\-print\-sysroot  \-print\-sysroot\-headers\-suffix
  \&\-save\-temps  \-save\-temps=cwd  \-save\-temps=obj  \-time\fR[\fB=\fR\fIfile\fR]
! .IP "\fIMachine\-Dependent Options\fR" 4
  .IX Item "Machine-Dependent Options"
  \&\fIAArch64 Options\fR
  \&\fB\-mabi=\fR\fIname\fR  \fB\-mbig\-endian  \-mlittle\-endian
*************** in the following sections.
*** 781,787 ****
  \&\-mlow\-precision\-recip\-sqrt  \-mlow\-precision\-sqrt  \-mlow\-precision\-div
  \&\-mpc\-relative\-literal\-loads
  \&\-msign\-return\-address=\fR\fIscope\fR
! \&\fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR
  \&\fB+\fR\fIb\-key\fR\fB]|\fR\fIbti\fR
  \&\fB\-mharden\-sls=\fR\fIopts\fR
  \&\fB\-march=\fR\fIname\fR  \fB\-mcpu=\fR\fIname\fR  \fB\-mtune=\fR\fIname\fR
--- 706,712 ----
  \&\-mlow\-precision\-recip\-sqrt  \-mlow\-precision\-sqrt  \-mlow\-precision\-div
  \&\-mpc\-relative\-literal\-loads
  \&\-msign\-return\-address=\fR\fIscope\fR
! \&\fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR
  \&\fB+\fR\fIb\-key\fR\fB]|\fR\fIbti\fR
  \&\fB\-mharden\-sls=\fR\fIopts\fR
  \&\fB\-march=\fR\fIname\fR  \fB\-mcpu=\fR\fIname\fR  \fB\-mtune=\fR\fIname\fR
*************** in the following sections.
*** 798,807 ****
  \&\-mfp\-mode=\fR\fImode\fR  \fB\-mvect\-double  \-max\-vect\-align=\fR\fInum\fR
  \&\fB\-msplit\-vecmove\-early  \-m1reg\-\fR\fIreg\fR
  .Sp
! \&\fI\s-1AMD GCN\s0 Options\fR
  \&\fB\-march=\fR\fIgpu\fR \fB\-mtune=\fR\fIgpu\fR \fB\-mstack\-size=\fR\fIbytes\fR
  .Sp
! \&\fI\s-1ARC\s0 Options\fR
  \&\fB\-mbarrel\-shifter  \-mjli\-always
  \&\-mcpu=\fR\fIcpu\fR  \fB\-mA6  \-mARC600  \-mA7  \-mARC700
  \&\-mdpfp  \-mdpfp\-compact  \-mdpfp\-fast  \-mno\-dpfp\-lrsr
--- 723,732 ----
  \&\-mfp\-mode=\fR\fImode\fR  \fB\-mvect\-double  \-max\-vect\-align=\fR\fInum\fR
  \&\fB\-msplit\-vecmove\-early  \-m1reg\-\fR\fIreg\fR
  .Sp
! \&\fIAMD GCN Options\fR
  \&\fB\-march=\fR\fIgpu\fR \fB\-mtune=\fR\fIgpu\fR \fB\-mstack\-size=\fR\fIbytes\fR
  .Sp
! \&\fIARC Options\fR
  \&\fB\-mbarrel\-shifter  \-mjli\-always
  \&\-mcpu=\fR\fIcpu\fR  \fB\-mA6  \-mARC600  \-mA7  \-mARC700
  \&\-mdpfp  \-mdpfp\-compact  \-mdpfp\-fast  \-mno\-dpfp\-lrsr
*************** in the following sections.
*** 821,827 ****
  \&\-munalign\-prob\-threshold=\fR\fIprobability\fR  \fB\-mmpy\-option=\fR\fImulto\fR
  \&\fB\-mdiv\-rem  \-mcode\-density  \-mll64  \-mfpu=\fR\fIfpu\fR  \fB\-mrf16  \-mbranch\-index\fR
  .Sp
! \&\fI\s-1ARM\s0 Options\fR
  \&\fB\-mapcs\-frame  \-mno\-apcs\-frame
  \&\-mabi=\fR\fIname\fR
  \&\fB\-mapcs\-stack\-check  \-mno\-apcs\-stack\-check
--- 746,752 ----
  \&\-munalign\-prob\-threshold=\fR\fIprobability\fR  \fB\-mmpy\-option=\fR\fImulto\fR
  \&\fB\-mdiv\-rem  \-mcode\-density  \-mll64  \-mfpu=\fR\fIfpu\fR  \fB\-mrf16  \-mbranch\-index\fR
  .Sp
! \&\fIARM Options\fR
  \&\fB\-mapcs\-frame  \-mno\-apcs\-frame
  \&\-mabi=\fR\fIname\fR
  \&\fB\-mapcs\-stack\-check  \-mno\-apcs\-stack\-check
*************** in the following sections.
*** 861,870 ****
  \&\-mfix\-cmse\-cve\-2021\-35465
  \&\-mstack\-protector\-guard=\fR\fIguard\fR \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR
  \&\fB\-mfdpic
! \&\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR\fB]
! [+\fR\fIbti\fR\fB]|\fR\fIbti\fR\fB[+\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR\fB]]\fR
  .Sp
! \&\fI\s-1AVR\s0 Options\fR
  \&\fB\-mmcu=\fR\fImcu\fR  \fB\-mabsdata  \-maccumulate\-args
  \&\-mbranch\-cost=\fR\fIcost\fR
  \&\fB\-mcall\-prologues  \-mgas\-isr\-prologues  \-mint8
--- 786,795 ----
  \&\-mfix\-cmse\-cve\-2021\-35465
  \&\-mstack\-protector\-guard=\fR\fIguard\fR \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR
  \&\fB\-mfdpic
! \&\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR\fB]
! [+\fR\fIbti\fR\fB]|\fR\fIbti\fR\fB[+\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR\fB]]\fR
  .Sp
! \&\fIAVR Options\fR
  \&\fB\-mmcu=\fR\fImcu\fR  \fB\-mabsdata  \-maccumulate\-args
  \&\-mbranch\-cost=\fR\fIcost\fR
  \&\fB\-mcall\-prologues  \-mgas\-isr\-prologues  \-mint8
*************** in the following sections.
*** 888,896 ****
  .Sp
  \&\fIC6X Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian  \-march=\fR\fIcpu\fR
! \&\fB\-msim  \-msdata=\fR\fIsdata-type\fR
  .Sp
! \&\fI\s-1CRIS\s0 Options\fR
  \&\fB\-mcpu=\fR\fIcpu\fR  \fB\-march=\fR\fIcpu\fR
  \&\fB\-mtune=\fR\fIcpu\fR \fB\-mmax\-stack\-frame=\fR\fIn\fR
  \&\fB\-metrax4  \-metrax100  \-mpdebug  \-mcc\-init  \-mno\-side\-effects
--- 813,821 ----
  .Sp
  \&\fIC6X Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian  \-march=\fR\fIcpu\fR
! \&\fB\-msim  \-msdata=\fR\fIsdata\-type\fR
  .Sp
! \&\fICRIS Options\fR
  \&\fB\-mcpu=\fR\fIcpu\fR  \fB\-march=\fR\fIcpu\fR
  \&\fB\-mtune=\fR\fIcpu\fR \fB\-mmax\-stack\-frame=\fR\fIn\fR
  \&\fB\-metrax4  \-metrax100  \-mpdebug  \-mcc\-init  \-mno\-side\-effects
*************** in the following sections.
*** 937,948 ****
  \&\-whatsloaded  \-F  \-gused  \-gfull  \-mmacosx\-version\-min=\fR\fIversion\fR
  \&\fB\-mkernel  \-mone\-byte\-bool\fR
  .Sp
! \&\fI\s-1DEC\s0 Alpha Options\fR
  \&\fB\-mno\-fp\-regs  \-msoft\-float
  \&\-mieee  \-mieee\-with\-inexact  \-mieee\-conformant
  \&\-mfp\-trap\-mode=\fR\fImode\fR  \fB\-mfp\-rounding\-mode=\fR\fImode\fR
  \&\fB\-mtrap\-precision=\fR\fImode\fR  \fB\-mbuild\-constants
! \&\-mcpu=\fR\fIcpu-type\fR  \fB\-mtune=\fR\fIcpu-type\fR
  \&\fB\-mbwx  \-mmax  \-mfix  \-mcix
  \&\-mfloat\-vax  \-mfloat\-ieee
  \&\-mexplicit\-relocs  \-msmall\-data  \-mlarge\-data
--- 862,873 ----
  \&\-whatsloaded  \-F  \-gused  \-gfull  \-mmacosx\-version\-min=\fR\fIversion\fR
  \&\fB\-mkernel  \-mone\-byte\-bool\fR
  .Sp
! \&\fIDEC Alpha Options\fR
  \&\fB\-mno\-fp\-regs  \-msoft\-float
  \&\-mieee  \-mieee\-with\-inexact  \-mieee\-conformant
  \&\-mfp\-trap\-mode=\fR\fImode\fR  \fB\-mfp\-rounding\-mode=\fR\fImode\fR
  \&\fB\-mtrap\-precision=\fR\fImode\fR  \fB\-mbuild\-constants
! \&\-mcpu=\fR\fIcpu\-type\fR  \fB\-mtune=\fR\fIcpu\-type\fR
  \&\fB\-mbwx  \-mmax  \-mfix  \-mcix
  \&\-mfloat\-vax  \-mfloat\-ieee
  \&\-mexplicit\-relocs  \-msmall\-data  \-mlarge\-data
*************** in the following sections.
*** 954,966 ****
  \&\fB\-mframe\-limit=\fR\fIbytes\fR \fB\-mxbpf \-mco\-re \-mno\-co\-re
  \&\-mjmpext \-mjmp32 \-malu32 \-mcpu=\fR\fIversion\fR
  .Sp
! \&\fI\s-1FR30\s0 Options\fR
  \&\fB\-msmall\-model  \-mno\-lsim\fR
  .Sp
! \&\fI\s-1FT32\s0 Options\fR
  \&\fB\-msim  \-mlra  \-mnodiv  \-mft32b  \-mcompress  \-mnopm\fR
  .Sp
! \&\fI\s-1FRV\s0 Options\fR
  \&\fB\-mgpr\-32  \-mgpr\-64  \-mfpr\-32  \-mfpr\-64
  \&\-mhard\-float  \-msoft\-float
  \&\-malloc\-cc  \-mfixed\-cc  \-mdword  \-mno\-dword
--- 879,891 ----
  \&\fB\-mframe\-limit=\fR\fIbytes\fR \fB\-mxbpf \-mco\-re \-mno\-co\-re
  \&\-mjmpext \-mjmp32 \-malu32 \-mcpu=\fR\fIversion\fR
  .Sp
! \&\fIFR30 Options\fR
  \&\fB\-msmall\-model  \-mno\-lsim\fR
  .Sp
! \&\fIFT32 Options\fR
  \&\fB\-msim  \-mlra  \-mnodiv  \-mft32b  \-mcompress  \-mnopm\fR
  .Sp
! \&\fIFRV Options\fR
  \&\fB\-mgpr\-32  \-mgpr\-64  \-mfpr\-32  \-mfpr\-64
  \&\-mhard\-float  \-msoft\-float
  \&\-malloc\-cc  \-mfixed\-cc  \-mdword  \-mno\-dword
*************** in the following sections.
*** 985,996 ****
  \&\fIH8/300 Options\fR
  \&\fB\-mrelax  \-mh  \-ms  \-mn  \-mexr  \-mno\-exr  \-mint32  \-malign\-300\fR
  .Sp
! \&\fI\s-1HPPA\s0 Options\fR
! \&\fB\-march=\fR\fIarchitecture-type\fR
  \&\fB\-matomic\-libcalls  \-mbig\-switch
  \&\-mcaller\-copies  \-mdisable\-fpregs  \-mdisable\-indexing
  \&\-mordered  \-mfast\-indirect\-calls  \-mgas  \-mgnu\-ld   \-mhp\-ld
! \&\-mfixed\-range=\fR\fIregister-range\fR
  \&\fB\-mcoherent\-ldcw \-mjump\-in\-delay  \-mlinker\-opt  \-mlong\-calls
  \&\-mlong\-load\-store  \-mno\-atomic\-libcalls  \-mno\-disable\-fpregs
  \&\-mno\-disable\-indexing  \-mno\-fast\-indirect\-calls  \-mno\-gas
--- 910,921 ----
  \&\fIH8/300 Options\fR
  \&\fB\-mrelax  \-mh  \-ms  \-mn  \-mexr  \-mno\-exr  \-mint32  \-malign\-300\fR
  .Sp
! \&\fIHPPA Options\fR
! \&\fB\-march=\fR\fIarchitecture\-type\fR
  \&\fB\-matomic\-libcalls  \-mbig\-switch
  \&\-mcaller\-copies  \-mdisable\-fpregs  \-mdisable\-indexing
  \&\-mordered  \-mfast\-indirect\-calls  \-mgas  \-mgnu\-ld   \-mhp\-ld
! \&\-mfixed\-range=\fR\fIregister\-range\fR
  \&\fB\-mcoherent\-ldcw \-mjump\-in\-delay  \-mlinker\-opt  \-mlong\-calls
  \&\-mlong\-load\-store  \-mno\-atomic\-libcalls  \-mno\-disable\-fpregs
  \&\-mno\-disable\-indexing  \-mno\-fast\-indirect\-calls  \-mno\-gas
*************** in the following sections.
*** 998,1007 ****
  \&\-mno\-portable\-runtime  \-mno\-soft\-float
  \&\-mno\-space\-regs  \-msoft\-float  \-mpa\-risc\-1\-0
  \&\-mpa\-risc\-1\-1  \-mpa\-risc\-2\-0  \-mportable\-runtime
! \&\-mschedule=\fR\fIcpu-type\fR  \fB\-mspace\-regs  \-msoft\-mult  \-msio  \-mwsio
! \&\-munix=\fR\fIunix-std\fR  \fB\-nolibdld  \-static  \-threads\fR
  .Sp
! \&\fI\s-1IA\-64\s0 Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian  \-mgnu\-as  \-mgnu\-ld  \-mno\-pic
  \&\-mvolatile\-asm\-stop  \-mregister\-names  \-msdata  \-mno\-sdata
  \&\-mconstant\-gp  \-mauto\-pic  \-mfused\-madd
--- 923,932 ----
  \&\-mno\-portable\-runtime  \-mno\-soft\-float
  \&\-mno\-space\-regs  \-msoft\-float  \-mpa\-risc\-1\-0
  \&\-mpa\-risc\-1\-1  \-mpa\-risc\-2\-0  \-mportable\-runtime
! \&\-mschedule=\fR\fIcpu\-type\fR  \fB\-mspace\-regs  \-msoft\-mult  \-msio  \-mwsio
! \&\-munix=\fR\fIunix\-std\fR  \fB\-nolibdld  \-static  \-threads\fR
  .Sp
! \&\fIIA\-64 Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian  \-mgnu\-as  \-mgnu\-ld  \-mno\-pic
  \&\-mvolatile\-asm\-stop  \-mregister\-names  \-msdata  \-mno\-sdata
  \&\-mconstant\-gp  \-mauto\-pic  \-mfused\-madd
*************** in the following sections.
*** 1014,1036 ****
  \&\-minline\-sqrt\-min\-latency  \-minline\-sqrt\-max\-throughput
  \&\-mno\-inline\-sqrt
  \&\-mdwarf2\-asm  \-mearly\-stop\-bits
! \&\-mfixed\-range=\fR\fIregister-range\fR  \fB\-mtls\-size=\fR\fItls-size\fR
! \&\fB\-mtune=\fR\fIcpu-type\fR  \fB\-milp32  \-mlp64
  \&\-msched\-br\-data\-spec  \-msched\-ar\-data\-spec  \-msched\-control\-spec
  \&\-msched\-br\-in\-data\-spec  \-msched\-ar\-in\-data\-spec  \-msched\-in\-control\-spec
  \&\-msched\-spec\-ldc  \-msched\-spec\-control\-ldc
  \&\-msched\-prefer\-non\-data\-spec\-insns  \-msched\-prefer\-non\-control\-spec\-insns
  \&\-msched\-stop\-bits\-after\-every\-cycle  \-msched\-count\-spec\-in\-critical\-path
  \&\-msel\-sched\-dont\-check\-control\-spec  \-msched\-fp\-mem\-deps\-zero\-cost
! \&\-msched\-max\-memory\-insns\-hard\-limit  \-msched\-max\-memory\-insns=\fR\fImax-insns\fR
  .Sp
! \&\fI\s-1LM32\s0 Options\fR
  \&\fB\-mbarrel\-shift\-enabled  \-mdivide\-enabled  \-mmultiply\-enabled
  \&\-msign\-extend\-enabled  \-muser\-enabled\fR
  .Sp
  \&\fILoongArch Options\fR
! \&\fB\-march=\fR\fIcpu-type\fR  \fB\-mtune=\fR\fIcpu-type\fR \fB\-mabi=\fR\fIbase-abi-type\fR
! \&\fB\-mfpu=\fR\fIfpu-type\fR \fB\-msoft\-float \-msingle\-float \-mdouble\-float
  \&\-mbranch\-cost=\fR\fIn\fR  \fB\-mcheck\-zero\-division \-mno\-check\-zero\-division
  \&\-mcond\-move\-int  \-mno\-cond\-move\-int
  \&\-mcond\-move\-float  \-mno\-cond\-move\-float
--- 939,961 ----
  \&\-minline\-sqrt\-min\-latency  \-minline\-sqrt\-max\-throughput
  \&\-mno\-inline\-sqrt
  \&\-mdwarf2\-asm  \-mearly\-stop\-bits
! \&\-mfixed\-range=\fR\fIregister\-range\fR  \fB\-mtls\-size=\fR\fItls\-size\fR
! \&\fB\-mtune=\fR\fIcpu\-type\fR  \fB\-milp32  \-mlp64
  \&\-msched\-br\-data\-spec  \-msched\-ar\-data\-spec  \-msched\-control\-spec
  \&\-msched\-br\-in\-data\-spec  \-msched\-ar\-in\-data\-spec  \-msched\-in\-control\-spec
  \&\-msched\-spec\-ldc  \-msched\-spec\-control\-ldc
  \&\-msched\-prefer\-non\-data\-spec\-insns  \-msched\-prefer\-non\-control\-spec\-insns
  \&\-msched\-stop\-bits\-after\-every\-cycle  \-msched\-count\-spec\-in\-critical\-path
  \&\-msel\-sched\-dont\-check\-control\-spec  \-msched\-fp\-mem\-deps\-zero\-cost
! \&\-msched\-max\-memory\-insns\-hard\-limit  \-msched\-max\-memory\-insns=\fR\fImax\-insns\fR
  .Sp
! \&\fILM32 Options\fR
  \&\fB\-mbarrel\-shift\-enabled  \-mdivide\-enabled  \-mmultiply\-enabled
  \&\-msign\-extend\-enabled  \-muser\-enabled\fR
  .Sp
  \&\fILoongArch Options\fR
! \&\fB\-march=\fR\fIcpu\-type\fR  \fB\-mtune=\fR\fIcpu\-type\fR \fB\-mabi=\fR\fIbase\-abi\-type\fR
! \&\fB\-mfpu=\fR\fIfpu\-type\fR \fB\-msoft\-float \-msingle\-float \-mdouble\-float
  \&\-mbranch\-cost=\fR\fIn\fR  \fB\-mcheck\-zero\-division \-mno\-check\-zero\-division
  \&\-mcond\-move\-int  \-mno\-cond\-move\-int
  \&\-mcond\-move\-float  \-mno\-cond\-move\-float
*************** in the following sections.
*** 1038,1044 ****
  \&\-mmax\-inline\-memcpy\-size=\fR\fIn\fR
  \&\fB\-mexplicit\-relocs \-mno\-explicit\-relocs
  \&\-mdirect\-extern\-access \-mno\-direct\-extern\-access
! \&\-mcmodel=\fR\fIcode-model\fR \fB\-mrelax \-mpass\-mrelax\-to\-as\fR
  .Sp
  \&\fIM32R/D Options\fR
  \&\fB\-m32r2  \-m32rx  \-m32r
--- 963,969 ----
  \&\-mmax\-inline\-memcpy\-size=\fR\fIn\fR
  \&\fB\-mexplicit\-relocs \-mno\-explicit\-relocs
  \&\-mdirect\-extern\-access \-mno\-direct\-extern\-access
! \&\-mcmodel=\fR\fIcode\-model\fR \fB\-mrelax \-mpass\-mrelax\-to\-as\fR
  .Sp
  \&\fIM32R/D Options\fR
  \&\fB\-m32r2  \-m32rx  \-m32r
*************** in the following sections.
*** 1046,1053 ****
  \&\-malign\-loops  \-mno\-align\-loops
  \&\-missue\-rate=\fR\fInumber\fR
  \&\fB\-mbranch\-cost=\fR\fInumber\fR
! \&\fB\-mmodel=\fR\fIcode-size-model-type\fR
! \&\fB\-msdata=\fR\fIsdata-type\fR
  \&\fB\-mno\-flush\-func  \-mflush\-func=\fR\fIname\fR
  \&\fB\-mno\-flush\-trap  \-mflush\-trap=\fR\fInumber\fR
  \&\fB\-G\fR \fInum\fR
--- 971,978 ----
  \&\-malign\-loops  \-mno\-align\-loops
  \&\-missue\-rate=\fR\fInumber\fR
  \&\fB\-mbranch\-cost=\fR\fInumber\fR
! \&\fB\-mmodel=\fR\fIcode\-size\-model\-type\fR
! \&\fB\-msdata=\fR\fIsdata\-type\fR
  \&\fB\-mno\-flush\-func  \-mflush\-func=\fR\fIname\fR
  \&\fB\-mno\-flush\-trap  \-mflush\-trap=\fR\fInumber\fR
  \&\fB\-G\fR \fInum\fR
*************** in the following sections.
*** 1078,1087 ****
  \&\fB\-mmemcpy  \-mxl\-soft\-mul  \-mxl\-soft\-div  \-mxl\-barrel\-shift
  \&\-mxl\-pattern\-compare  \-mxl\-stack\-check  \-mxl\-gp\-opt  \-mno\-clearbss
  \&\-mxl\-multiply\-high  \-mxl\-float\-convert  \-mxl\-float\-sqrt
! \&\-mbig\-endian  \-mlittle\-endian  \-mxl\-reorder  \-mxl\-mode\-\fR\fIapp-model\fR
  \&\fB\-mpic\-data\-is\-text\-relative\fR
  .Sp
! \&\fI\s-1MIPS\s0 Options\fR
  \&\fB\-EL  \-EB  \-march=\fR\fIarch\fR  \fB\-mtune=\fR\fIarch\fR
  \&\fB\-mips1  \-mips2  \-mips3  \-mips4  \-mips32  \-mips32r2  \-mips32r3  \-mips32r5
  \&\-mips32r6  \-mips64  \-mips64r2  \-mips64r3  \-mips64r5  \-mips64r6
--- 1003,1012 ----
  \&\fB\-mmemcpy  \-mxl\-soft\-mul  \-mxl\-soft\-div  \-mxl\-barrel\-shift
  \&\-mxl\-pattern\-compare  \-mxl\-stack\-check  \-mxl\-gp\-opt  \-mno\-clearbss
  \&\-mxl\-multiply\-high  \-mxl\-float\-convert  \-mxl\-float\-sqrt
! \&\-mbig\-endian  \-mlittle\-endian  \-mxl\-reorder  \-mxl\-mode\-\fR\fIapp\-model\fR
  \&\fB\-mpic\-data\-is\-text\-relative\fR
  .Sp
! \&\fIMIPS Options\fR
  \&\fB\-EL  \-EB  \-march=\fR\fIarch\fR  \fB\-mtune=\fR\fIarch\fR
  \&\fB\-mips1  \-mips2  \-mips3  \-mips4  \-mips32  \-mips32r2  \-mips32r3  \-mips32r5
  \&\-mips32r6  \-mips64  \-mips64r2  \-mips64r3  \-mips64r5  \-mips64r6
*************** in the following sections.
*** 1106,1112 ****
  \&\-mloongson\-mmi  \-mno\-loongson\-mmi
  \&\-mloongson\-ext  \-mno\-loongson\-ext
  \&\-mloongson\-ext2  \-mno\-loongson\-ext2
! \&\-mfpu=\fR\fIfpu-type\fR
  \&\fB\-msmartmips  \-mno\-smartmips
  \&\-mpaired\-single  \-mno\-paired\-single  \-mdmx  \-mno\-mdmx
  \&\-mips3d  \-mno\-mips3d  \-mmt  \-mno\-mt  \-mllsc  \-mno\-llsc
--- 1031,1037 ----
  \&\-mloongson\-mmi  \-mno\-loongson\-mmi
  \&\-mloongson\-ext  \-mno\-loongson\-ext
  \&\-mloongson\-ext2  \-mno\-loongson\-ext2
! \&\-mfpu=\fR\fIfpu\-type\fR
  \&\fB\-msmartmips  \-mno\-smartmips
  \&\-mpaired\-single  \-mno\-paired\-single  \-mdmx  \-mno\-mdmx
  \&\-mips3d  \-mno\-mips3d  \-mmt  \-mno\-mt  \-mllsc  \-mno\-llsc
*************** in the following sections.
*** 1139,1168 ****
  \&\-mrelax\-pic\-calls  \-mno\-relax\-pic\-calls  \-mmcount\-ra\-address
  \&\-mframe\-header\-opt  \-mno\-frame\-header\-opt\fR
  .Sp
! \&\fI\s-1MMIX\s0 Options\fR
  \&\fB\-mlibfuncs  \-mno\-libfuncs  \-mepsilon  \-mno\-epsilon  \-mabi=gnu
  \&\-mabi=mmixware  \-mzero\-extend  \-mknuthdiv  \-mtoplevel\-symbols
  \&\-melf  \-mbranch\-predict  \-mno\-branch\-predict  \-mbase\-addresses
  \&\-mno\-base\-addresses  \-msingle\-exit  \-mno\-single\-exit\fR
  .Sp
! \&\fI\s-1MN10300\s0 Options\fR
  \&\fB\-mmult\-bug  \-mno\-mult\-bug
  \&\-mno\-am33  \-mam33  \-mam33\-2  \-mam34
! \&\-mtune=\fR\fIcpu-type\fR
  \&\fB\-mreturn\-pointer\-on\-d0
  \&\-mno\-crt0  \-mrelax  \-mliw  \-msetlb\fR
  .Sp
  \&\fIMoxie Options\fR
  \&\fB\-meb  \-mel  \-mmul.x  \-mno\-crt0\fR
  .Sp
! \&\fI\s-1MSP430\s0 Options\fR
  \&\fB\-msim  \-masm\-hex  \-mmcu=  \-mcpu=  \-mlarge  \-msmall  \-mrelax
  \&\-mwarn\-mcu
  \&\-mcode\-region=  \-mdata\-region=
  \&\-msilicon\-errata=  \-msilicon\-errata\-warn=
  \&\-mhwmult=  \-minrt  \-mtiny\-printf  \-mmax\-inline\-shift=\fR
  .Sp
! \&\fI\s-1NDS32\s0 Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian
  \&\-mreduced\-regs  \-mfull\-regs
  \&\-mcmov  \-mno\-cmov
--- 1064,1093 ----
  \&\-mrelax\-pic\-calls  \-mno\-relax\-pic\-calls  \-mmcount\-ra\-address
  \&\-mframe\-header\-opt  \-mno\-frame\-header\-opt\fR
  .Sp
! \&\fIMMIX Options\fR
  \&\fB\-mlibfuncs  \-mno\-libfuncs  \-mepsilon  \-mno\-epsilon  \-mabi=gnu
  \&\-mabi=mmixware  \-mzero\-extend  \-mknuthdiv  \-mtoplevel\-symbols
  \&\-melf  \-mbranch\-predict  \-mno\-branch\-predict  \-mbase\-addresses
  \&\-mno\-base\-addresses  \-msingle\-exit  \-mno\-single\-exit\fR
  .Sp
! \&\fIMN10300 Options\fR
  \&\fB\-mmult\-bug  \-mno\-mult\-bug
  \&\-mno\-am33  \-mam33  \-mam33\-2  \-mam34
! \&\-mtune=\fR\fIcpu\-type\fR
  \&\fB\-mreturn\-pointer\-on\-d0
  \&\-mno\-crt0  \-mrelax  \-mliw  \-msetlb\fR
  .Sp
  \&\fIMoxie Options\fR
  \&\fB\-meb  \-mel  \-mmul.x  \-mno\-crt0\fR
  .Sp
! \&\fIMSP430 Options\fR
  \&\fB\-msim  \-masm\-hex  \-mmcu=  \-mcpu=  \-mlarge  \-msmall  \-mrelax
  \&\-mwarn\-mcu
  \&\-mcode\-region=  \-mdata\-region=
  \&\-msilicon\-errata=  \-msilicon\-errata\-warn=
  \&\-mhwmult=  \-minrt  \-mtiny\-printf  \-mmax\-inline\-shift=\fR
  .Sp
! \&\fINDS32 Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian
  \&\-mreduced\-regs  \-mfull\-regs
  \&\-mcmov  \-mno\-cmov
*************** in the following sections.
*** 1174,1183 ****
  \&\-misr\-vector\-size=\fR\fInum\fR
  \&\fB\-mcache\-block\-size=\fR\fInum\fR
  \&\fB\-march=\fR\fIarch\fR
! \&\fB\-mcmodel=\fR\fIcode-model\fR
  \&\fB\-mctor\-dtor  \-mrelax\fR
  .Sp
! \&\fINios \s-1II\s0 Options\fR
  \&\fB\-G\fR \fInum\fR  \fB\-mgpopt=\fR\fIoption\fR  \fB\-mgpopt  \-mno\-gpopt
  \&\-mgprel\-sec=\fR\fIregexp\fR  \fB\-mr0rel\-sec=\fR\fIregexp\fR
  \&\fB\-mel  \-meb
--- 1099,1108 ----
  \&\-misr\-vector\-size=\fR\fInum\fR
  \&\fB\-mcache\-block\-size=\fR\fInum\fR
  \&\fB\-march=\fR\fIarch\fR
! \&\fB\-mcmodel=\fR\fIcode\-model\fR
  \&\fB\-mctor\-dtor  \-mrelax\fR
  .Sp
! \&\fINios II Options\fR
  \&\fB\-G\fR \fInum\fR  \fB\-mgpopt=\fR\fIoption\fR  \fB\-mgpopt  \-mno\-gpopt
  \&\-mgprel\-sec=\fR\fIregexp\fR  \fB\-mr0rel\-sec=\fR\fIregexp\fR
  \&\fB\-mel  \-meb
*************** in the following sections.
*** 1190,1196 ****
  \&\fB\-mhal  \-msmallc  \-msys\-crt0=\fR\fIname\fR  \fB\-msys\-lib=\fR\fIname\fR
  \&\fB\-march=\fR\fIarch\fR  \fB\-mbmx  \-mno\-bmx  \-mcdx  \-mno\-cdx\fR
  .Sp
! \&\fINvidia \s-1PTX\s0 Options\fR
  \&\fB\-m64  \-mmainkernel  \-moptimize\fR
  .Sp
  \&\fIOpenRISC Options\fR
--- 1115,1121 ----
  \&\fB\-mhal  \-msmallc  \-msys\-crt0=\fR\fIname\fR  \fB\-msys\-lib=\fR\fIname\fR
  \&\fB\-march=\fR\fIarch\fR  \fB\-mbmx  \-mno\-bmx  \-mcdx  \-mno\-cdx\fR
  .Sp
! \&\fINvidia PTX Options\fR
  \&\fB\-m64  \-mmainkernel  \-moptimize\fR
  .Sp
  \&\fIOpenRISC Options\fR
*************** in the following sections.
*** 1198,1226 ****
  \&\-msoft\-mul  \-msoft\-div
  \&\-msoft\-float  \-mhard\-float  \-mdouble\-float \-munordered\-float
  \&\-mcmov  \-mror  \-mrori  \-msext  \-msfimm  \-mshftimm
! \&\-mcmodel=\fR\fIcode-model\fR
  .Sp
! \&\fI\s-1PDP\-11\s0 Options\fR
  \&\fB\-mfpu  \-msoft\-float  \-mac0  \-mno\-ac0  \-m40  \-m45  \-m10
  \&\-mint32  \-mno\-int16  \-mint16  \-mno\-int32
  \&\-msplit  \-munix\-asm  \-mdec\-asm  \-mgnu\-asm  \-mlra\fR
  .Sp
  \&\fIPowerPC Options\fR
! See \s-1RS/6000\s0 and PowerPC Options.
  .Sp
! \&\fI\s-1PRU\s0 Options\fR
  \&\fB\-mmcu=\fR\fImcu\fR  \fB\-minrt  \-mno\-relax  \-mloop
  \&\-mabi=\fR\fIvariant\fR
  .Sp
! \&\fIRISC-V Options\fR
  \&\fB\-mbranch\-cost=\fR\fIN\-instruction\fR
  \&\fB\-mplt  \-mno\-plt
! \&\-mabi=\fR\fIABI-string\fR
  \&\fB\-mfdiv  \-mno\-fdiv
  \&\-mdiv  \-mno\-div
! \&\-misa\-spec=\fR\fIISA-spec-string\fR
! \&\fB\-march=\fR\fIISA-string\fR
! \&\fB\-mtune=\fR\fIprocessor-string\fR
  \&\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR
  \&\fB\-msmall\-data\-limit=\fR\fIN\-bytes\fR
  \&\fB\-msave\-restore  \-mno\-save\-restore
--- 1123,1151 ----
  \&\-msoft\-mul  \-msoft\-div
  \&\-msoft\-float  \-mhard\-float  \-mdouble\-float \-munordered\-float
  \&\-mcmov  \-mror  \-mrori  \-msext  \-msfimm  \-mshftimm
! \&\-mcmodel=\fR\fIcode\-model\fR
  .Sp
! \&\fIPDP\-11 Options\fR
  \&\fB\-mfpu  \-msoft\-float  \-mac0  \-mno\-ac0  \-m40  \-m45  \-m10
  \&\-mint32  \-mno\-int16  \-mint16  \-mno\-int32
  \&\-msplit  \-munix\-asm  \-mdec\-asm  \-mgnu\-asm  \-mlra\fR
  .Sp
  \&\fIPowerPC Options\fR
! See RS/6000 and PowerPC Options.
  .Sp
! \&\fIPRU Options\fR
  \&\fB\-mmcu=\fR\fImcu\fR  \fB\-minrt  \-mno\-relax  \-mloop
  \&\-mabi=\fR\fIvariant\fR
  .Sp
! \&\fIRISC\-V Options\fR
  \&\fB\-mbranch\-cost=\fR\fIN\-instruction\fR
  \&\fB\-mplt  \-mno\-plt
! \&\-mabi=\fR\fIABI\-string\fR
  \&\fB\-mfdiv  \-mno\-fdiv
  \&\-mdiv  \-mno\-div
! \&\-misa\-spec=\fR\fIISA\-spec\-string\fR
! \&\fB\-march=\fR\fIISA\-string\fR
! \&\fB\-mtune=\fR\fIprocessor\-string\fR
  \&\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR
  \&\fB\-msmall\-data\-limit=\fR\fIN\-bytes\fR
  \&\fB\-msave\-restore  \-mno\-save\-restore
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1237,1251 ****
  \&\fB\-mcsr\-check \-mno\-csr\-check
  \&\-minline\-atomics  \-mno\-inline\-atomics\fR
  .Sp
! \&\fI\s-1RL78\s0 Options\fR
  \&\fB\-msim  \-mmul=none  \-mmul=g13  \-mmul=g14  \-mallregs
  \&\-mcpu=g10  \-mcpu=g13  \-mcpu=g14  \-mg10  \-mg13  \-mg14
  \&\-m64bit\-doubles  \-m32bit\-doubles  \-msave\-mduc\-in\-interrupts\fR
  .Sp
! \&\fI\s-1RS/6000\s0 and PowerPC Options\fR
! \&\fB\-mcpu=\fR\fIcpu-type\fR
! \&\fB\-mtune=\fR\fIcpu-type\fR
! \&\fB\-mcmodel=\fR\fIcode-model\fR
  \&\fB\-mpowerpc64
  \&\-maltivec  \-mno\-altivec
  \&\-mpowerpc\-gpopt  \-mno\-powerpc\-gpopt
--- 1162,1176 ----
  \&\fB\-mcsr\-check \-mno\-csr\-check
  \&\-minline\-atomics  \-mno\-inline\-atomics\fR
  .Sp
! \&\fIRL78 Options\fR
  \&\fB\-msim  \-mmul=none  \-mmul=g13  \-mmul=g14  \-mallregs
  \&\-mcpu=g10  \-mcpu=g13  \-mcpu=g14  \-mg10  \-mg13  \-mg14
  \&\-m64bit\-doubles  \-m32bit\-doubles  \-msave\-mduc\-in\-interrupts\fR
  .Sp
! \&\fIRS/6000 and PowerPC Options\fR
! \&\fB\-mcpu=\fR\fIcpu\-type\fR
! \&\fB\-mtune=\fR\fIcpu\-type\fR
! \&\fB\-mcmodel=\fR\fIcode\-model\fR
  \&\fB\-mpowerpc64
  \&\-maltivec  \-mno\-altivec
  \&\-mpowerpc\-gpopt  \-mno\-powerpc\-gpopt
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1272,1278 ****
  \&\-mcall\-sysv  \-mcall\-sysv\-eabi  \-mcall\-sysv\-noeabi
  \&\-mtraceback=\fR\fItraceback_type\fR
  \&\fB\-maix\-struct\-return  \-msvr4\-struct\-return
! \&\-mabi=\fR\fIabi-type\fR  \fB\-msecure\-plt  \-mbss\-plt
  \&\-mlongcall  \-mno\-longcall  \-mpltseq  \-mno\-pltseq
  \&\-mblock\-move\-inline\-limit=\fR\fInum\fR
  \&\fB\-mblock\-compare\-inline\-limit=\fR\fInum\fR
--- 1197,1203 ----
  \&\-mcall\-sysv  \-mcall\-sysv\-eabi  \-mcall\-sysv\-noeabi
  \&\-mtraceback=\fR\fItraceback_type\fR
  \&\fB\-maix\-struct\-return  \-msvr4\-struct\-return
! \&\-mabi=\fR\fIabi\-type\fR  \fB\-msecure\-plt  \-mbss\-plt
  \&\-mlongcall  \-mno\-longcall  \-mpltseq  \-mno\-pltseq
  \&\-mblock\-move\-inline\-limit=\fR\fInum\fR
  \&\fB\-mblock\-compare\-inline\-limit=\fR\fInum\fR
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1303,1309 ****
  \&\-mpcrel \-mno\-pcrel \-mmma \-mno\-mmma \-mrop\-protect \-mno\-rop\-protect
  \&\-mprivileged \-mno\-privileged\fR
  .Sp
! \&\fI\s-1RX\s0 Options\fR
  \&\fB\-m64bit\-doubles  \-m32bit\-doubles  \-fpu  \-nofpu
  \&\-mcpu=
  \&\-mbig\-endian\-data  \-mlittle\-endian\-data
--- 1228,1234 ----
  \&\-mpcrel \-mno\-pcrel \-mmma \-mno\-mmma \-mrop\-protect \-mno\-rop\-protect
  \&\-mprivileged \-mno\-privileged\fR
  .Sp
! \&\fIRX Options\fR
  \&\fB\-m64bit\-doubles  \-m32bit\-doubles  \-fpu  \-nofpu
  \&\-mcpu=
  \&\-mbig\-endian\-data  \-mlittle\-endian\-data
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1320,1326 ****
  \&\-msave\-acc\-in\-interrupts\fR
  .Sp
  \&\fIS/390 and zSeries Options\fR
! \&\fB\-mtune=\fR\fIcpu-type\fR  \fB\-march=\fR\fIcpu-type\fR
  \&\fB\-mhard\-float  \-msoft\-float  \-mhard\-dfp  \-mno\-hard\-dfp
  \&\-mlong\-double\-64  \-mlong\-double\-128
  \&\-mbackchain  \-mno\-backchain  \-mpacked\-stack  \-mno\-packed\-stack
--- 1245,1251 ----
  \&\-msave\-acc\-in\-interrupts\fR
  .Sp
  \&\fIS/390 and zSeries Options\fR
! \&\fB\-mtune=\fR\fIcpu\-type\fR  \fB\-march=\fR\fIcpu\-type\fR
  \&\fB\-mhard\-float  \-msoft\-float  \-mhard\-dfp  \-mno\-hard\-dfp
  \&\-mlong\-double\-64  \-mlong\-double\-128
  \&\-mbackchain  \-mno\-backchain  \-mpacked\-stack  \-mno\-packed\-stack
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1332,1338 ****
  \&\-mwarn\-framesize  \-mwarn\-dynamicstack  \-mstack\-size  \-mstack\-guard
  \&\-mhotpatch=\fR\fIhalfwords\fR\fB,\fR\fIhalfwords\fR
  .Sp
! \&\fI\s-1SH\s0 Options\fR
  \&\fB\-m1  \-m2  \-m2e
  \&\-m2a\-nofpu  \-m2a\-single\-only  \-m2a\-single  \-m2a
  \&\-m3  \-m3e
--- 1257,1263 ----
  \&\-mwarn\-framesize  \-mwarn\-dynamicstack  \-mstack\-size  \-mstack\-guard
  \&\-mhotpatch=\fR\fIhalfwords\fR\fB,\fR\fIhalfwords\fR
  .Sp
! \&\fISH Options\fR
  \&\fB\-m1  \-m2  \-m2e
  \&\-m2a\-nofpu  \-m2a\-single\-only  \-m2a\-single  \-m2a
  \&\-m3  \-m3e
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1342,1350 ****
  \&\-mbigtable  \-mfmovd  \-mrenesas  \-mno\-renesas  \-mnomacsave
  \&\-mieee  \-mno\-ieee  \-mbitops  \-misize  \-minline\-ic_invalidate  \-mpadstruct
  \&\-mprefergot  \-musermode  \-multcost=\fR\fInumber\fR  \fB\-mdiv=\fR\fIstrategy\fR
! \&\fB\-mdivsi3_libfunc=\fR\fIname\fR  \fB\-mfixed\-range=\fR\fIregister-range\fR
  \&\fB\-maccumulate\-outgoing\-args
! \&\-matomic\-model=\fR\fIatomic-model\fR
  \&\fB\-mbranch\-cost=\fR\fInum\fR  \fB\-mzdcbranch  \-mno\-zdcbranch
  \&\-mcbranch\-force\-delay\-slot
  \&\-mfused\-madd  \-mno\-fused\-madd  \-mfsca  \-mno\-fsca  \-mfsrra  \-mno\-fsrra
--- 1267,1275 ----
  \&\-mbigtable  \-mfmovd  \-mrenesas  \-mno\-renesas  \-mnomacsave
  \&\-mieee  \-mno\-ieee  \-mbitops  \-misize  \-minline\-ic_invalidate  \-mpadstruct
  \&\-mprefergot  \-musermode  \-multcost=\fR\fInumber\fR  \fB\-mdiv=\fR\fIstrategy\fR
! \&\fB\-mdivsi3_libfunc=\fR\fIname\fR  \fB\-mfixed\-range=\fR\fIregister\-range\fR
  \&\fB\-maccumulate\-outgoing\-args
! \&\-matomic\-model=\fR\fIatomic\-model\fR
  \&\fB\-mbranch\-cost=\fR\fInum\fR  \fB\-mzdcbranch  \-mno\-zdcbranch
  \&\-mcbranch\-force\-delay\-slot
  \&\-mfused\-madd  \-mno\-fused\-madd  \-mfsca  \-mno\-fsca  \-mfsrra  \-mno\-fsrra
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1354,1364 ****
  \&\fB\-mclear\-hwcap  \-mno\-clear\-hwcap  \-mimpure\-text  \-mno\-impure\-text
  \&\-pthreads\fR
  .Sp
! \&\fI\s-1SPARC\s0 Options\fR
! \&\fB\-mcpu=\fR\fIcpu-type\fR
! \&\fB\-mtune=\fR\fIcpu-type\fR
! \&\fB\-mcmodel=\fR\fIcode-model\fR
! \&\fB\-mmemory\-model=\fR\fImem-model\fR
  \&\fB\-m32  \-m64  \-mapp\-regs  \-mno\-app\-regs
  \&\-mfaster\-structs  \-mno\-faster\-structs  \-mflat  \-mno\-flat
  \&\-mfpu  \-mno\-fpu  \-mhard\-float  \-msoft\-float
--- 1279,1289 ----
  \&\fB\-mclear\-hwcap  \-mno\-clear\-hwcap  \-mimpure\-text  \-mno\-impure\-text
  \&\-pthreads\fR
  .Sp
! \&\fISPARC Options\fR
! \&\fB\-mcpu=\fR\fIcpu\-type\fR
! \&\fB\-mtune=\fR\fIcpu\-type\fR
! \&\fB\-mcmodel=\fR\fIcode\-model\fR
! \&\fB\-mmemory\-model=\fR\fImem\-model\fR
  \&\fB\-m32  \-m64  \-mapp\-regs  \-mno\-app\-regs
  \&\-mfaster\-structs  \-mno\-faster\-structs  \-mflat  \-mno\-flat
  \&\-mfpu  \-mno\-fpu  \-mhard\-float  \-msoft\-float
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1395,1408 ****
  \&\-mrh850\-abi
  \&\-mbig\-switch\fR
  .Sp
! \&\fI\s-1VAX\s0 Options\fR
  \&\fB\-mg  \-mgnu  \-munix  \-mlra\fR
  .Sp
  \&\fIVisium Options\fR
  \&\fB\-mdebug  \-msim  \-mfpu  \-mno\-fpu  \-mhard\-float  \-msoft\-float
! \&\-mcpu=\fR\fIcpu-type\fR  \fB\-mtune=\fR\fIcpu-type\fR  \fB\-msv\-mode  \-muser\-mode\fR
  .Sp
! \&\fI\s-1VMS\s0 Options\fR
  \&\fB\-mvms\-return\-codes  \-mdebug\-main=\fR\fIprefix\fR  \fB\-mmalloc64
  \&\-mpointer\-size=\fR\fIsize\fR
  .Sp
--- 1320,1333 ----
  \&\-mrh850\-abi
  \&\-mbig\-switch\fR
  .Sp
! \&\fIVAX Options\fR
  \&\fB\-mg  \-mgnu  \-munix  \-mlra\fR
  .Sp
  \&\fIVisium Options\fR
  \&\fB\-mdebug  \-msim  \-mfpu  \-mno\-fpu  \-mhard\-float  \-msoft\-float
! \&\-mcpu=\fR\fIcpu\-type\fR  \fB\-mtune=\fR\fIcpu\-type\fR  \fB\-msv\-mode  \-muser\-mode\fR
  .Sp
! \&\fIVMS Options\fR
  \&\fB\-mvms\-return\-codes  \-mdebug\-main=\fR\fIprefix\fR  \fB\-mmalloc64
  \&\-mpointer\-size=\fR\fIsize\fR
  .Sp
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1411,1418 ****
  \&\-Xbind\-lazy  \-Xbind\-now\fR
  .Sp
  \&\fIx86 Options\fR
! \&\fB\-mtune=\fR\fIcpu-type\fR  \fB\-march=\fR\fIcpu-type\fR
! \&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR  \fB\-mdump\-tune\-features  \-mno\-default
  \&\-mfpmath=\fR\fIunit\fR
  \&\fB\-masm=\fR\fIdialect\fR  \fB\-mno\-fancy\-math\-387
  \&\-mno\-fp\-ret\-in\-387  \-m80387  \-mhard\-float  \-msoft\-float
--- 1336,1343 ----
  \&\-Xbind\-lazy  \-Xbind\-now\fR
  .Sp
  \&\fIx86 Options\fR
! \&\fB\-mtune=\fR\fIcpu\-type\fR  \fB\-march=\fR\fIcpu\-type\fR
! \&\fB\-mtune\-ctrl=\fR\fIfeature\-list\fR  \fB\-mdump\-tune\-features  \-mno\-default
  \&\-mfpmath=\fR\fIunit\fR
  \&\fB\-masm=\fR\fIdialect\fR  \fB\-mno\-fancy\-math\-387
  \&\-mno\-fp\-ret\-in\-387  \-m80387  \-mhard\-float  \-msoft\-float
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1449,1455 ****
  \&\-mveclibabi=\fR\fItype\fR  \fB\-mvect8\-ret\-in\-mem
  \&\-mpc32  \-mpc64  \-mpc80  \-mdaz\-ftz \-mstackrealign
  \&\-momit\-leaf\-frame\-pointer  \-mno\-red\-zone  \-mno\-tls\-direct\-seg\-refs
! \&\-mcmodel=\fR\fIcode-model\fR  \fB\-mabi=\fR\fIname\fR  \fB\-maddress\-mode=\fR\fImode\fR
  \&\fB\-m32  \-m64  \-mx32  \-m16  \-miamcu  \-mlarge\-data\-threshold=\fR\fInum\fR
  \&\fB\-msse2avx  \-mfentry  \-mrecord\-mcount  \-mnop\-mcount  \-m8bit\-idiv
  \&\-minstrument\-return=\fR\fItype\fR \fB\-mfentry\-name=\fR\fIname\fR \fB\-mfentry\-section=\fR\fIname\fR
--- 1374,1380 ----
  \&\-mveclibabi=\fR\fItype\fR  \fB\-mvect8\-ret\-in\-mem
  \&\-mpc32  \-mpc64  \-mpc80  \-mdaz\-ftz \-mstackrealign
  \&\-momit\-leaf\-frame\-pointer  \-mno\-red\-zone  \-mno\-tls\-direct\-seg\-refs
! \&\-mcmodel=\fR\fIcode\-model\fR  \fB\-mabi=\fR\fIname\fR  \fB\-maddress\-mode=\fR\fImode\fR
  \&\fB\-m32  \-m64  \-mx32  \-m16  \-miamcu  \-mlarge\-data\-threshold=\fR\fInum\fR
  \&\fB\-msse2avx  \-mfentry  \-mrecord\-mcount  \-mnop\-mcount  \-m8bit\-idiv
  \&\-minstrument\-return=\fR\fItype\fR \fB\-mfentry\-name=\fR\fIname\fR \fB\-mfentry\-section=\fR\fIname\fR
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1481,1487 ****
  \&\-mauto\-litpools  \-mno\-auto\-litpools
  \&\-mtarget\-align  \-mno\-target\-align
  \&\-mlongcalls  \-mno\-longcalls
! \&\-mabi=\fR\fIabi-type\fR
  \&\fB\-mextra\-l32r\-costs=\fR\fIcycles\fR
  .Sp
  \&\fIzSeries Options\fR
--- 1406,1412 ----
  \&\-mauto\-litpools  \-mno\-auto\-litpools
  \&\-mtarget\-align  \-mno\-target\-align
  \&\-mlongcalls  \-mno\-longcalls
! \&\-mabi=\fR\fIabi\-type\fR
  \&\fB\-mextra\-l32r\-costs=\fR\fIcycles\fR
  .Sp
  \&\fIzSeries Options\fR
*************** See S/390 and zSeries Options.
*** 1489,1495 ****
  .SS "Options Controlling the Kind of Output"
  .IX Subsection "Options Controlling the Kind of Output"
  Compilation can involve up to four stages: preprocessing, compilation
! proper, assembly and linking, always in that order.  \s-1GCC\s0 is capable of
  preprocessing and compiling several files either into several
  assembler input files, or into one assembler input file; then each
  assembler input file produces an object file, and linking combines all
--- 1414,1420 ----
  .SS "Options Controlling the Kind of Output"
  .IX Subsection "Options Controlling the Kind of Output"
  Compilation can involve up to four stages: preprocessing, compilation
! proper, assembly and linking, always in that order.  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
*************** into an executable file.
*** 1498,1664 ****
  .PP
  For any given input file, the file name suffix determines what kind of
  compilation is done:
! .IP "\fIfile\fR\fB.c\fR" 4
  .IX Item "file.c"
  C source code that must be preprocessed.
! .IP "\fIfile\fR\fB.i\fR" 4
  .IX Item "file.i"
  C source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.ii\fR" 4
  .IX Item "file.ii"
! \&\*(C+ source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.m\fR" 4
  .IX Item "file.m"
! Objective-C source code.  Note that you must link with the \fIlibobjc\fR
! library to make an Objective-C program work.
! .IP "\fIfile\fR\fB.mi\fR" 4
  .IX Item "file.mi"
! Objective-C source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.mm\fR" 4
  .IX Item "file.mm"
  .PD 0
! .IP "\fIfile\fR\fB.M\fR" 4
  .IX Item "file.M"
  .PD
! Objective\-\*(C+ source code.  Note that you must link with the \fIlibobjc\fR
! library to make an Objective\-\*(C+ program work.  Note that \fB.M\fR refers
  to a literal capital M.
! .IP "\fIfile\fR\fB.mii\fR" 4
  .IX Item "file.mii"
! Objective\-\*(C+ source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.h\fR" 4
  .IX Item "file.h"
! C, \*(C+, Objective-C or Objective\-\*(C+ header file to be turned into a
! precompiled header (default), or C, \*(C+ header file to be turned into an
  Ada spec (via the \fB\-fdump\-ada\-spec\fR switch).
! .IP "\fIfile\fR\fB.cc\fR" 4
  .IX Item "file.cc"
  .PD 0
! .IP "\fIfile\fR\fB.cp\fR" 4
  .IX Item "file.cp"
! .IP "\fIfile\fR\fB.cxx\fR" 4
  .IX Item "file.cxx"
! .IP "\fIfile\fR\fB.cpp\fR" 4
  .IX Item "file.cpp"
! .IP "\fIfile\fR\fB.CPP\fR" 4
  .IX Item "file.CPP"
! .IP "\fIfile\fR\fB.c++\fR" 4
  .IX Item "file.c++"
! .IP "\fIfile\fR\fB.C\fR" 4
  .IX Item "file.C"
  .PD
! \&\*(C+ source code that must be preprocessed.  Note that in \fB.cxx\fR,
  the last two letters must both be literally \fBx\fR.  Likewise,
  \&\fB.C\fR refers to a literal capital C.
! .IP "\fIfile\fR\fB.mm\fR" 4
  .IX Item "file.mm"
  .PD 0
! .IP "\fIfile\fR\fB.M\fR" 4
  .IX Item "file.M"
  .PD
! Objective\-\*(C+ source code that must be preprocessed.
! .IP "\fIfile\fR\fB.mii\fR" 4
  .IX Item "file.mii"
! Objective\-\*(C+ source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.hh\fR" 4
  .IX Item "file.hh"
  .PD 0
! .IP "\fIfile\fR\fB.H\fR" 4
  .IX Item "file.H"
! .IP "\fIfile\fR\fB.hp\fR" 4
  .IX Item "file.hp"
! .IP "\fIfile\fR\fB.hxx\fR" 4
  .IX Item "file.hxx"
! .IP "\fIfile\fR\fB.hpp\fR" 4
  .IX Item "file.hpp"
! .IP "\fIfile\fR\fB.HPP\fR" 4
  .IX Item "file.HPP"
! .IP "\fIfile\fR\fB.h++\fR" 4
  .IX Item "file.h++"
! .IP "\fIfile\fR\fB.tcc\fR" 4
  .IX Item "file.tcc"
  .PD
! \&\*(C+ header file to be turned into a precompiled header or Ada spec.
! .IP "\fIfile\fR\fB.f\fR" 4
  .IX Item "file.f"
  .PD 0
! .IP "\fIfile\fR\fB.for\fR" 4
  .IX Item "file.for"
! .IP "\fIfile\fR\fB.ftn\fR" 4
  .IX Item "file.ftn"
  .PD
  Fixed form Fortran source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.F\fR" 4
  .IX Item "file.F"
  .PD 0
! .IP "\fIfile\fR\fB.FOR\fR" 4
  .IX Item "file.FOR"
! .IP "\fIfile\fR\fB.fpp\fR" 4
  .IX Item "file.fpp"
! .IP "\fIfile\fR\fB.FPP\fR" 4
  .IX Item "file.FPP"
! .IP "\fIfile\fR\fB.FTN\fR" 4
  .IX Item "file.FTN"
  .PD
  Fixed form Fortran source code that must be preprocessed (with the traditional
  preprocessor).
! .IP "\fIfile\fR\fB.f90\fR" 4
  .IX Item "file.f90"
  .PD 0
! .IP "\fIfile\fR\fB.f95\fR" 4
  .IX Item "file.f95"
! .IP "\fIfile\fR\fB.f03\fR" 4
  .IX Item "file.f03"
! .IP "\fIfile\fR\fB.f08\fR" 4
  .IX Item "file.f08"
  .PD
  Free form Fortran source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.F90\fR" 4
  .IX Item "file.F90"
  .PD 0
! .IP "\fIfile\fR\fB.F95\fR" 4
  .IX Item "file.F95"
! .IP "\fIfile\fR\fB.F03\fR" 4
  .IX Item "file.F03"
! .IP "\fIfile\fR\fB.F08\fR" 4
  .IX Item "file.F08"
  .PD
  Free form Fortran source code that must be preprocessed (with the
  traditional preprocessor).
! .IP "\fIfile\fR\fB.go\fR" 4
  .IX Item "file.go"
  Go source code.
! .IP "\fIfile\fR\fB.d\fR" 4
  .IX Item "file.d"
  D source code.
! .IP "\fIfile\fR\fB.di\fR" 4
  .IX Item "file.di"
  D interface file.
! .IP "\fIfile\fR\fB.dd\fR" 4
  .IX Item "file.dd"
  D documentation code (Ddoc).
! .IP "\fIfile\fR\fB.ads\fR" 4
  .IX Item "file.ads"
  Ada source code file that contains a library unit declaration (a
  declaration of a package, subprogram, or generic, or a generic
  instantiation), or a library unit renaming declaration (a package,
  generic, or subprogram renaming declaration).  Such files are also
  called \fIspecs\fR.
! .IP "\fIfile\fR\fB.adb\fR" 4
  .IX Item "file.adb"
  Ada source code file containing a library unit body (a subprogram or
  package body).  Such files are also called \fIbodies\fR.
! .IP "\fIfile\fR\fB.s\fR" 4
  .IX Item "file.s"
  Assembler code.
! .IP "\fIfile\fR\fB.S\fR" 4
  .IX Item "file.S"
  .PD 0
! .IP "\fIfile\fR\fB.sx\fR" 4
  .IX Item "file.sx"
  .PD
  Assembler code that must be preprocessed.
! .IP "\fIother\fR" 4
  .IX Item "other"
  An object file to be fed straight into linking.
  Any file name with no recognized suffix is treated this way.
--- 1423,1589 ----
  .PP
  For any given input file, the file name suffix determines what kind of
  compilation is done:
! .IP \fIfile\fR\fB.c\fR 4
  .IX Item "file.c"
  C source code that must be preprocessed.
! .IP \fIfile\fR\fB.i\fR 4
  .IX Item "file.i"
  C source code that should not be preprocessed.
! .IP \fIfile\fR\fB.ii\fR 4
  .IX Item "file.ii"
! C++ source code that should not be preprocessed.
! .IP \fIfile\fR\fB.m\fR 4
  .IX Item "file.m"
! Objective\-C source code.  Note that you must link with the \fIlibobjc\fR
! library to make an Objective\-C program work.
! .IP \fIfile\fR\fB.mi\fR 4
  .IX Item "file.mi"
! Objective\-C source code that should not be preprocessed.
! .IP \fIfile\fR\fB.mm\fR 4
  .IX Item "file.mm"
  .PD 0
! .IP \fIfile\fR\fB.M\fR 4
  .IX Item "file.M"
  .PD
! Objective\-C++ source code.  Note that you must link with the \fIlibobjc\fR
! library to make an Objective\-C++ program work.  Note that \fB.M\fR refers
  to a literal capital M.
! .IP \fIfile\fR\fB.mii\fR 4
  .IX Item "file.mii"
! Objective\-C++ source code that should not be preprocessed.
! .IP \fIfile\fR\fB.h\fR 4
  .IX Item "file.h"
! C, C++, Objective\-C or Objective\-C++ header file to be turned into a
! precompiled header (default), or C, C++ header file to be turned into an
  Ada spec (via the \fB\-fdump\-ada\-spec\fR switch).
! .IP \fIfile\fR\fB.cc\fR 4
  .IX Item "file.cc"
  .PD 0
! .IP \fIfile\fR\fB.cp\fR 4
  .IX Item "file.cp"
! .IP \fIfile\fR\fB.cxx\fR 4
  .IX Item "file.cxx"
! .IP \fIfile\fR\fB.cpp\fR 4
  .IX Item "file.cpp"
! .IP \fIfile\fR\fB.CPP\fR 4
  .IX Item "file.CPP"
! .IP \fIfile\fR\fB.c++\fR 4
  .IX Item "file.c++"
! .IP \fIfile\fR\fB.C\fR 4
  .IX Item "file.C"
  .PD
! C++ source code that must be preprocessed.  Note that in \fB.cxx\fR,
  the last two letters must both be literally \fBx\fR.  Likewise,
  \&\fB.C\fR refers to a literal capital C.
! .IP \fIfile\fR\fB.mm\fR 4
  .IX Item "file.mm"
  .PD 0
! .IP \fIfile\fR\fB.M\fR 4
  .IX Item "file.M"
  .PD
! Objective\-C++ source code that must be preprocessed.
! .IP \fIfile\fR\fB.mii\fR 4
  .IX Item "file.mii"
! Objective\-C++ source code that should not be preprocessed.
! .IP \fIfile\fR\fB.hh\fR 4
  .IX Item "file.hh"
  .PD 0
! .IP \fIfile\fR\fB.H\fR 4
  .IX Item "file.H"
! .IP \fIfile\fR\fB.hp\fR 4
  .IX Item "file.hp"
! .IP \fIfile\fR\fB.hxx\fR 4
  .IX Item "file.hxx"
! .IP \fIfile\fR\fB.hpp\fR 4
  .IX Item "file.hpp"
! .IP \fIfile\fR\fB.HPP\fR 4
  .IX Item "file.HPP"
! .IP \fIfile\fR\fB.h++\fR 4
  .IX Item "file.h++"
! .IP \fIfile\fR\fB.tcc\fR 4
  .IX Item "file.tcc"
  .PD
! C++ header file to be turned into a precompiled header or Ada spec.
! .IP \fIfile\fR\fB.f\fR 4
  .IX Item "file.f"
  .PD 0
! .IP \fIfile\fR\fB.for\fR 4
  .IX Item "file.for"
! .IP \fIfile\fR\fB.ftn\fR 4
  .IX Item "file.ftn"
  .PD
  Fixed form Fortran source code that should not be preprocessed.
! .IP \fIfile\fR\fB.F\fR 4
  .IX Item "file.F"
  .PD 0
! .IP \fIfile\fR\fB.FOR\fR 4
  .IX Item "file.FOR"
! .IP \fIfile\fR\fB.fpp\fR 4
  .IX Item "file.fpp"
! .IP \fIfile\fR\fB.FPP\fR 4
  .IX Item "file.FPP"
! .IP \fIfile\fR\fB.FTN\fR 4
  .IX Item "file.FTN"
  .PD
  Fixed form Fortran source code that must be preprocessed (with the traditional
  preprocessor).
! .IP \fIfile\fR\fB.f90\fR 4
  .IX Item "file.f90"
  .PD 0
! .IP \fIfile\fR\fB.f95\fR 4
  .IX Item "file.f95"
! .IP \fIfile\fR\fB.f03\fR 4
  .IX Item "file.f03"
! .IP \fIfile\fR\fB.f08\fR 4
  .IX Item "file.f08"
  .PD
  Free form Fortran source code that should not be preprocessed.
! .IP \fIfile\fR\fB.F90\fR 4
  .IX Item "file.F90"
  .PD 0
! .IP \fIfile\fR\fB.F95\fR 4
  .IX Item "file.F95"
! .IP \fIfile\fR\fB.F03\fR 4
  .IX Item "file.F03"
! .IP \fIfile\fR\fB.F08\fR 4
  .IX Item "file.F08"
  .PD
  Free form Fortran source code that must be preprocessed (with the
  traditional preprocessor).
! .IP \fIfile\fR\fB.go\fR 4
  .IX Item "file.go"
  Go source code.
! .IP \fIfile\fR\fB.d\fR 4
  .IX Item "file.d"
  D source code.
! .IP \fIfile\fR\fB.di\fR 4
  .IX Item "file.di"
  D interface file.
! .IP \fIfile\fR\fB.dd\fR 4
  .IX Item "file.dd"
  D documentation code (Ddoc).
! .IP \fIfile\fR\fB.ads\fR 4
  .IX Item "file.ads"
  Ada source code file that contains a library unit declaration (a
  declaration of a package, subprogram, or generic, or a generic
  instantiation), or a library unit renaming declaration (a package,
  generic, or subprogram renaming declaration).  Such files are also
  called \fIspecs\fR.
! .IP \fIfile\fR\fB.adb\fR 4
  .IX Item "file.adb"
  Ada source code file containing a library unit body (a subprogram or
  package body).  Such files are also called \fIbodies\fR.
! .IP \fIfile\fR\fB.s\fR 4
  .IX Item "file.s"
  Assembler code.
! .IP \fIfile\fR\fB.S\fR 4
  .IX Item "file.S"
  .PD 0
! .IP \fIfile\fR\fB.sx\fR 4
  .IX Item "file.sx"
  .PD
  Assembler code that must be preprocessed.
! .IP \fIother\fR 4
  .IX Item "other"
  An object file to be fed straight into linking.
  Any file name with no recognized suffix is treated this way.
*************** Specify explicitly the \fIlanguage\fR fo
*** 1671,1686 ****
  name suffix).  This option applies to all following input files until
  the next \fB\-x\fR option.  Possible values for \fIlanguage\fR are:
  .Sp
! .Vb 9
  \&        c  c\-header  cpp\-output
  \&        c++  c++\-header  c++\-system\-header c++\-user\-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
  \&        d
! \&        f77  f77\-cpp\-input f95  f95\-cpp\-input
  \&        go
  .Ve
  .IP "\fB\-x none\fR" 4
  .IX Item "-x none"
--- 1596,1615 ----
  name suffix).  This option applies to all following input files until
  the next \fB\-x\fR option.  Possible values for \fIlanguage\fR are:
  .Sp
! .Vb 10
  \&        c  c\-header  cpp\-output
  \&        c++  c++\-header  c++\-system\-header c++\-user\-header c++\-cpp\-output
! \&        objective\-c  objective\-c\-header  objective\-c\-cpp\-output  objc\-cpp\-output
! \&        objective\-c++  objective\-c++\-header  objective\-c++\-cpp\-output
! \&        objc++\-cpp\-output
  \&        assembler  assembler\-with\-cpp
! \&        ada  adascil  adawhy
  \&        d
! \&        f77  f77\-cpp\-input  f95  f95\-cpp\-input
  \&        go
+ \&        modula\-2  modula\-2\-cpp\-output
+ \&        rust
+ \&        lto
  .Ve
  .IP "\fB\-x none\fR" 4
  .IX Item "-x none"
*************** If you only want some of the stages of c
*** 1692,1699 ****
  \&\fB\-x\fR (or filename suffixes) to tell \fBgcc\fR where to start, and
  one of the options \fB\-c\fR, \fB\-S\fR, or \fB\-E\fR to say where
  \&\fBgcc\fR is to stop.  Note that some combinations (for example,
! \&\fB\-x cpp-output \-E\fR) instruct \fBgcc\fR to do nothing at all.
! .IP "\fB\-c\fR" 4
  .IX Item "-c"
  Compile or assemble the source files, but do not link.  The linking
  stage simply is not done.  The ultimate output is in the form of an
--- 1621,1628 ----
  \&\fB\-x\fR (or filename suffixes) to tell \fBgcc\fR where to start, and
  one of the options \fB\-c\fR, \fB\-S\fR, or \fB\-E\fR to say where
  \&\fBgcc\fR is to stop.  Note that some combinations (for example,
! \&\fB\-x cpp\-output \-E\fR) instruct \fBgcc\fR to do nothing at all.
! .IP \fB\-c\fR 4
  .IX Item "-c"
  Compile or assemble the source files, but do not link.  The linking
  stage simply is not done.  The ultimate output is in the form of an
*************** the suffix \fB.c\fR, \fB.i\fR, \fB.s\fR,
*** 1704,1726 ****
  .Sp
  Unrecognized input files, not requiring compilation or assembly, are
  ignored.
! .IP "\fB\-S\fR" 4
  .IX Item "-S"
  Stop after the stage of compilation proper; do not assemble.  The output
! is in the form of an assembler code file for each non-assembler input
  file specified.
  .Sp
  By default, the assembler file name for a source file is made by
  replacing the suffix \fB.c\fR, \fB.i\fR, etc., with \fB.s\fR.
  .Sp
! Input files that don't require compilation are ignored.
! .IP "\fB\-E\fR" 4
  .IX Item "-E"
  Stop after the preprocessing stage; do not run the compiler proper.  The
  output is in the form of preprocessed source code, which is sent to the
  standard output.
  .Sp
! Input files that don't require preprocessing are ignored.
  .IP "\fB\-o\fR \fIfile\fR" 4
  .IX Item "-o file"
  Place the primary output in file \fIfile\fR.  This applies to whatever
--- 1633,1655 ----
  .Sp
  Unrecognized input files, not requiring compilation or assembly, are
  ignored.
! .IP \fB\-S\fR 4
  .IX Item "-S"
  Stop after the stage of compilation proper; do not assemble.  The output
! is in the form of an assembler code file for each non\-assembler input
  file specified.
  .Sp
  By default, the assembler file name for a source file is made by
  replacing the suffix \fB.c\fR, \fB.i\fR, etc., with \fB.s\fR.
  .Sp
! Input files that don\*(Aqt require compilation are ignored.
! .IP \fB\-E\fR 4
  .IX Item "-E"
  Stop after the preprocessing stage; do not run the compiler proper.  The
  output is in the form of preprocessed source code, which is sent to the
  standard output.
  .Sp
! Input files that don\*(Aqt require preprocessing are ignored.
  .IP "\fB\-o\fR \fIfile\fR" 4
  .IX Item "-o file"
  Place the primary output in file \fIfile\fR.  This applies to whatever
*************** object file, an assembler file or prepro
*** 1729,1737 ****
  .Sp
  If \fB\-o\fR is not specified, the default is to put an executable
  file in \fIa.out\fR, the object file for
! \&\fI\fIsource\fI.\fIsuffix\fI\fR in \fI\fIsource\fI.o\fR, its
! assembler file in \fI\fIsource\fI.s\fR, a precompiled header file in
! \&\fI\fIsource\fI.\fIsuffix\fI.gch\fR, and all preprocessed C source on
  standard output.
  .Sp
  Though \fB\-o\fR names only the primary output, it also affects the
--- 1658,1666 ----
  .Sp
  If \fB\-o\fR is not specified, the default is to put an executable
  file in \fIa.out\fR, the object file for
! \&\fIsource.suffix\fR in \fIsource.o\fR, its
! assembler file in \fIsource.s\fR, a precompiled header file in
! \&\fIsource.suffix.gch\fR, and all preprocessed C source on
  standard output.
  .Sp
  Though \fB\-o\fR names only the primary output, it also affects the
*************** dumps next to it, e.g., aux file \fIfoo.
*** 1756,1762 ****
  \&\fB\-gsplit\-dwarf\fR, and dump file \fIfoo.c.???r.final\fR for
  \&\fB\-fdump\-rtl\-final\fR.
  .Sp
! If a non-linker output file is explicitly specified, aux and dump files
  by default take the same base name:
  .Sp
  .Vb 1
--- 1685,1691 ----
  \&\fB\-gsplit\-dwarf\fR, and dump file \fIfoo.c.???r.final\fR for
  \&\fB\-fdump\-rtl\-final\fR.
  .Sp
! If a non\-linker output file is explicitly specified, aux and dump files
  by default take the same base name:
  .Sp
  .Vb 1
*************** an intermediate, thus auxiliary output),
*** 1813,1826 ****
  (implied) output file \fIfoo.o\fR.
  .Sp
  Absent this option, dump and aux files take their names from the input
! file, or from the (non-linker) output file, if one is explicitly
  specified: dump output files (e.g. those requested by \fB\-fdump\-*\fR
  options) with the input name suffix, and aux output files (those
! requested by other non-dump options, e.g. \f(CW\*(C`\-save\-temps\*(C'\fR,
  \&\f(CW\*(C`\-gsplit\-dwarf\*(C'\fR, \f(CW\*(C`\-fcallgraph\-info\*(C'\fR) without it.
  .Sp
  Similar suffix differentiation of dump and aux outputs can be attained
! for explicitly-given \fB\-dumpbase basename.suf\fR by also specifying
  \&\fB\-dumpbase\-ext .suf\fR.
  .Sp
  If \fIdumpbase\fR is explicitly specified with any directory component,
--- 1742,1755 ----
  (implied) output file \fIfoo.o\fR.
  .Sp
  Absent this option, dump and aux files take their names from the input
! file, or from the (non\-linker) output file, if one is explicitly
  specified: dump output files (e.g. those requested by \fB\-fdump\-*\fR
  options) with the input name suffix, and aux output files (those
! requested by other non\-dump options, e.g. \f(CW\*(C`\-save\-temps\*(C'\fR,
  \&\f(CW\*(C`\-gsplit\-dwarf\*(C'\fR, \f(CW\*(C`\-fcallgraph\-info\*(C'\fR) without it.
  .Sp
  Similar suffix differentiation of dump and aux outputs can be attained
! for explicitly\-given \fB\-dumpbase basename.suf\fR by also specifying
  \&\fB\-dumpbase\-ext .suf\fR.
  .Sp
  If \fIdumpbase\fR is explicitly specified with any directory component,
*************** will name aux outputs \fIdir/foo.*\fR an
*** 1865,1871 ****
  \&\fIdir/foo.c.*\fR.  Note how their basenames are taken from the input
  name, but the directory still defaults to that of the output.
  .Sp
! The empty-string dumpbase does not prevent the use of the output
  basename for outputs during linking:
  .Sp
  .Vb 1
--- 1794,1800 ----
  \&\fIdir/foo.c.*\fR.  Note how their basenames are taken from the input
  name, but the directory still defaults to that of the output.
  .Sp
! The empty\-string dumpbase does not prevent the use of the output
  basename for outputs during linking:
  .Sp
  .Vb 1
*************** basename for outputs during linking:
*** 1874,1880 ****
  .Sp
  The compilation of the source files will name auxiliary outputs
  \&\fIdir/foo.*\fR and \fIdir/bar.*\fR, and dump outputs
! \&\fIdir/foo.c.*\fR and \fIdir/bar.c.*\fR.  \s-1LTO\s0 recompilation during
  linking will use \fIdir/foobar.\fR as the prefix for dumps and
  auxiliary files.
  .IP "\fB\-dumpbase\-ext\fR \fIauxdropsuf\fR" 4
--- 1803,1809 ----
  .Sp
  The compilation of the source files will name auxiliary outputs
  \&\fIdir/foo.*\fR and \fIdir/bar.*\fR, and dump outputs
! \&\fIdir/foo.c.*\fR and \fIdir/bar.c.*\fR.  LTO recompilation during
  linking will use \fIdir/foobar.\fR as the prefix for dumps and
  auxiliary files.
  .IP "\fB\-dumpbase\-ext\fR \fIauxdropsuf\fR" 4
*************** When compiling from multiple input files
*** 1957,1963 ****
  specified, \fIdumpbase\fR, minus a \fIauxdropsuf\fR suffix, and a dash
  are appended to (or override, if containing any directory components) an
  explicit or defaulted \fIdumppfx\fR, so that each of the multiple
! compilations gets differently-named aux and dump outputs.
  .Sp
  .Vb 1
  \&        gcc foo.c bar.c \-c \-dumpdir dir/pfx\- \-dumpbase main ...
--- 1886,1892 ----
  specified, \fIdumpbase\fR, minus a \fIauxdropsuf\fR suffix, and a dash
  are appended to (or override, if containing any directory components) an
  explicit or defaulted \fIdumppfx\fR, so that each of the multiple
! compilations gets differently\-named aux and dump outputs.
  .Sp
  .Vb 1
  \&        gcc foo.c bar.c \-c \-dumpdir dir/pfx\- \-dumpbase main ...
*************** outputs auxiliary dumps to \fIdir/pfx\-m
*** 1967,1973 ****
  \&\fIdir/pfx\-main\-bar.*\fR, appending \fIdumpbase\fR\- to \fIdumppfx\fR.
  Dump outputs retain the input file suffix: \fIdir/pfx\-main\-foo.c.*\fR
  and \fIdir/pfx\-main\-bar.c.*\fR, respectively.  Contrast with the
! single-input compilation:
  .Sp
  .Vb 1
  \&        gcc foo.c \-c \-dumpdir dir/pfx\- \-dumpbase main ...
--- 1896,1902 ----
  \&\fIdir/pfx\-main\-bar.*\fR, appending \fIdumpbase\fR\- to \fIdumppfx\fR.
  Dump outputs retain the input file suffix: \fIdir/pfx\-main\-foo.c.*\fR
  and \fIdir/pfx\-main\-bar.c.*\fR, respectively.  Contrast with the
! single\-input compilation:
  .Sp
  .Vb 1
  \&        gcc foo.c \-c \-dumpdir dir/pfx\- \-dumpbase main ...
*************** instead.  Note, however, that unlike ear
*** 1992,2006 ****
  .Sp
  does not append the output name \fImain\fR to \fIdumppfx\fR, because
  \&\fB\-dumpdir\fR is explicitly specified.  The goal is that the
! explicitly-specified \fIdumppfx\fR may contain the specified output name
! as part of the prefix, if desired; only an explicitly-specified
  \&\fB\-dumpbase\fR would be combined with it, in order to avoid simply
  discarding a meaningful option.
  .Sp
  When compiling and then linking from a single input file, the linker
  output base name will only be appended to the default \fIdumppfx\fR as
  above if it does not share the base name with the single input file
! name.  This has been covered in single-input linking cases above, but
  not with an explicit \fB\-dumpdir\fR that inhibits the combination,
  even if overridden by \fB\-save\-temps=*\fR:
  .Sp
--- 1921,1935 ----
  .Sp
  does not append the output name \fImain\fR to \fIdumppfx\fR, because
  \&\fB\-dumpdir\fR is explicitly specified.  The goal is that the
! explicitly\-specified \fIdumppfx\fR may contain the specified output name
! as part of the prefix, if desired; only an explicitly\-specified
  \&\fB\-dumpbase\fR would be combined with it, in order to avoid simply
  discarding a meaningful option.
  .Sp
  When compiling and then linking from a single input file, the linker
  output base name will only be appended to the default \fIdumppfx\fR as
  above if it does not share the base name with the single input file
! name.  This has been covered in single\-input linking cases above, but
  not with an explicit \fB\-dumpdir\fR that inhibits the combination,
  even if overridden by \fB\-save\-temps=*\fR:
  .Sp
*************** for each input are formed by combining \
*** 2023,2118 ****
  minus suffix, and the auxiliary output suffix; dump output names are
  only different in that the suffix from \fIdumpbase\fR is retained.
  .Sp
! When it comes to auxiliary and dump outputs created during \s-1LTO\s0
  recompilation, a combination of \fIdumppfx\fR and \fIdumpbase\fR, as
  given or as derived from the linker output name but not from inputs,
  even in cases in which this combination would not otherwise be used as
! such, is passed down with a trailing period replacing the compiler-added
! dash, if any, as a \fB\-dumpdir\fR option to \fBlto-wrapper\fR;
  being involved in linking, this program does not normally get any
  \&\fB\-dumpbase\fR and \fB\-dumpbase\-ext\fR, and it ignores them.
  .Sp
! When running sub-compilers, \fBlto-wrapper\fR appends \s-1LTO\s0 stage
  names to the received \fIdumppfx\fR, ensures it contains a directory
  component so that it overrides any \fB\-dumpdir\fR, and passes that as
! \&\fB\-dumpbase\fR to sub-compilers.
! .IP "\fB\-v\fR" 4
  .IX Item "-v"
  Print (on standard error output) the commands executed to run the stages
  of compilation.  Also print the version number of the compiler driver
  program and of the preprocessor and the compiler proper.
! .IP "\fB\-###\fR" 4
  .IX Item "-###"
  Like \fB\-v\fR except the commands are not executed and arguments
  are quoted unless they contain only alphanumeric characters or \f(CW\*(C`./\-_\*(C'\fR.
! This is useful for shell scripts to capture the driver-generated command lines.
! .IP "\fB\-\-help\fR" 4
  .IX Item "--help"
! Print (on the standard output) a description of the command-line options
  understood by \fBgcc\fR.  If the \fB\-v\fR option is also specified
  then \fB\-\-help\fR is also passed on to the various processes
! invoked by \fBgcc\fR, so that they can display the command-line options
  they accept.  If the \fB\-Wextra\fR option has also been specified
! (prior to the \fB\-\-help\fR option), then command-line options that
  have no documentation associated with them are also displayed.
! .IP "\fB\-\-target\-help\fR" 4
  .IX Item "--target-help"
! Print (on the standard output) a description of target-specific command-line
! options for each tool.  For some targets extra target-specific
  information may also be printed.
! .IP "\fB\-\-help={\fR\fIclass\fR|[\fB^\fR]\fIqualifier\fR\fB}\fR[\fB,...\fR]" 4
  .IX Item "--help={class|[^]qualifier}[,...]"
! Print (on the standard output) a description of the command-line
  options understood by the compiler that fit into all specified classes
  and qualifiers.  These are the supported classes:
  .RS 4
! .IP "\fBoptimizers\fR" 4
  .IX Item "optimizers"
  Display all of the optimization options supported by the
  compiler.
! .IP "\fBwarnings\fR" 4
  .IX Item "warnings"
  Display all of the options controlling warning messages
  produced by the compiler.
! .IP "\fBtarget\fR" 4
  .IX Item "target"
! Display target-specific options.  Unlike the
! \&\fB\-\-target\-help\fR option however, target-specific options of the
  linker and assembler are not displayed.  This is because those
  tools do not currently support the extended \fB\-\-help=\fR syntax.
! .IP "\fBparams\fR" 4
  .IX Item "params"
  Display the values recognized by the \fB\-\-param\fR
  option.
! .IP "\fIlanguage\fR" 4
  .IX Item "language"
  Display the options supported for \fIlanguage\fR, where
  \&\fIlanguage\fR is the name of one of the languages supported in this
! version of \s-1GCC.\s0  If an option is supported by all languages, one needs
  to select \fBcommon\fR class.
! .IP "\fBcommon\fR" 4
  .IX Item "common"
  Display the options that are common to all languages.
  .RE
  .RS 4
  .Sp
  These are the supported qualifiers:
! .IP "\fBundocumented\fR" 4
  .IX Item "undocumented"
  Display only those options that are undocumented.
! .IP "\fBjoined\fR" 4
  .IX Item "joined"
  Display options taking an argument that appears after an equal
  sign in the same continuous piece of text, such as:
  \&\fB\-\-help=target\fR.
! .IP "\fBseparate\fR" 4
  .IX Item "separate"
  Display options taking an argument that appears as a separate word
! following the original option, such as: \fB\-o output-file\fR.
  .RE
  .RS 4
  .Sp
! Thus for example to display all the undocumented target-specific
  switches supported by the compiler, use:
  .Sp
  .Vb 1
--- 1952,2047 ----
  minus suffix, and the auxiliary output suffix; dump output names are
  only different in that the suffix from \fIdumpbase\fR is retained.
  .Sp
! When it comes to auxiliary and dump outputs created during LTO
  recompilation, a combination of \fIdumppfx\fR and \fIdumpbase\fR, as
  given or as derived from the linker output name but not from inputs,
  even in cases in which this combination would not otherwise be used as
! such, is passed down with a trailing period replacing the compiler\-added
! dash, if any, as a \fB\-dumpdir\fR option to \fBlto\-wrapper\fR;
  being involved in linking, this program does not normally get any
  \&\fB\-dumpbase\fR and \fB\-dumpbase\-ext\fR, and it ignores them.
  .Sp
! When running sub\-compilers, \fBlto\-wrapper\fR appends LTO stage
  names to the received \fIdumppfx\fR, ensures it contains a directory
  component so that it overrides any \fB\-dumpdir\fR, and passes that as
! \&\fB\-dumpbase\fR to sub\-compilers.
! .IP \fB\-v\fR 4
  .IX Item "-v"
  Print (on standard error output) the commands executed to run the stages
  of compilation.  Also print the version number of the compiler driver
  program and of the preprocessor and the compiler proper.
! .IP \fB\-###\fR 4
  .IX Item "-###"
  Like \fB\-v\fR except the commands are not executed and arguments
  are quoted unless they contain only alphanumeric characters or \f(CW\*(C`./\-_\*(C'\fR.
! This is useful for shell scripts to capture the driver\-generated command lines.
! .IP \fB\-\-help\fR 4
  .IX Item "--help"
! Print (on the standard output) a description of the command\-line options
  understood by \fBgcc\fR.  If the \fB\-v\fR option is also specified
  then \fB\-\-help\fR is also passed on to the various processes
! invoked by \fBgcc\fR, so that they can display the command\-line options
  they accept.  If the \fB\-Wextra\fR option has also been specified
! (prior to the \fB\-\-help\fR option), then command\-line options that
  have no documentation associated with them are also displayed.
! .IP \fB\-\-target\-help\fR 4
  .IX Item "--target-help"
! Print (on the standard output) a description of target\-specific command\-line
! options for each tool.  For some targets extra target\-specific
  information may also be printed.
! .IP \fB\-\-help={\fR\fIclass\fR|[\fB^\fR]\fIqualifier\fR\fB}\fR[\fB,...\fR] 4
  .IX Item "--help={class|[^]qualifier}[,...]"
! Print (on the standard output) a description of the command\-line
  options understood by the compiler that fit into all specified classes
  and qualifiers.  These are the supported classes:
  .RS 4
! .IP \fBoptimizers\fR 4
  .IX Item "optimizers"
  Display all of the optimization options supported by the
  compiler.
! .IP \fBwarnings\fR 4
  .IX Item "warnings"
  Display all of the options controlling warning messages
  produced by the compiler.
! .IP \fBtarget\fR 4
  .IX Item "target"
! Display target\-specific options.  Unlike the
! \&\fB\-\-target\-help\fR option however, target\-specific options of the
  linker and assembler are not displayed.  This is because those
  tools do not currently support the extended \fB\-\-help=\fR syntax.
! .IP \fBparams\fR 4
  .IX Item "params"
  Display the values recognized by the \fB\-\-param\fR
  option.
! .IP \fIlanguage\fR 4
  .IX Item "language"
  Display the options supported for \fIlanguage\fR, where
  \&\fIlanguage\fR is the name of one of the languages supported in this
! version of GCC.  If an option is supported by all languages, one needs
  to select \fBcommon\fR class.
! .IP \fBcommon\fR 4
  .IX Item "common"
  Display the options that are common to all languages.
  .RE
  .RS 4
  .Sp
  These are the supported qualifiers:
! .IP \fBundocumented\fR 4
  .IX Item "undocumented"
  Display only those options that are undocumented.
! .IP \fBjoined\fR 4
  .IX Item "joined"
  Display options taking an argument that appears after an equal
  sign in the same continuous piece of text, such as:
  \&\fB\-\-help=target\fR.
! .IP \fBseparate\fR 4
  .IX Item "separate"
  Display options taking an argument that appears as a separate word
! following the original option, such as: \fB\-o output\-file\fR.
  .RE
  .RS 4
  .Sp
! Thus for example to display all the undocumented target\-specific
  switches supported by the compiler, use:
  .Sp
  .Vb 1
*************** qualifiers.
*** 2134,2140 ****
  Combining several classes is possible, although this usually
  restricts the output so much that there is nothing to display.  One
  case where it does work, however, is when one of the classes is
! \&\fItarget\fR.  For example, to display all the target-specific
  optimization options, use:
  .Sp
  .Vb 1
--- 2063,2069 ----
  Combining several classes is possible, although this usually
  restricts the output so much that there is nothing to display.  One
  case where it does work, however, is when one of the classes is
! \&\fItarget\fR.  For example, to display all the target\-specific
  optimization options, use:
  .Sp
  .Vb 1
*************** options, an indication is given as to wh
*** 2154,2160 ****
  disabled or set to a specific value (assuming that the compiler
  knows this at the point where the \fB\-\-help=\fR option is used).
  .Sp
! Here is a truncated example from the \s-1ARM\s0 port of \fBgcc\fR:
  .Sp
  .Vb 5
  \&          % gcc \-Q \-mabi=2 \-\-help=target \-c
--- 2083,2089 ----
  disabled or set to a specific value (assuming that the compiler
  knows this at the point where the \fB\-\-help=\fR option is used).
  .Sp
! Here is a truncated example from the ARM port of \fBgcc\fR:
  .Sp
  .Vb 5
  \&          % gcc \-Q \-mabi=2 \-\-help=target \-c
*************** Here is a truncated example from the \s-
*** 2164,2170 ****
  \&          \-mapcs                                [disabled]
  .Ve
  .Sp
! The output is sensitive to the effects of previous command-line
  options, so for example it is possible to find out which optimizations
  are enabled at \fB\-O2\fR by using:
  .Sp
--- 2093,2099 ----
  \&          \-mapcs                                [disabled]
  .Ve
  .Sp
! The output is sensitive to the effects of previous command\-line
  options, so for example it is possible to find out which optimizations
  are enabled at \fB\-O2\fR by using:
  .Sp
*************** by \fB\-O3\fR by using:
*** 2181,2204 ****
  \&        diff /tmp/O2\-opts /tmp/O3\-opts | grep enabled
  .Ve
  .RE
! .IP "\fB\-\-version\fR" 4
  .IX Item "--version"
! Display the version number and copyrights of the invoked \s-1GCC.\s0
! .IP "\fB\-pass\-exit\-codes\fR" 4
  .IX Item "-pass-exit-codes"
  Normally the \fBgcc\fR program exits with the code of 1 if any
! phase of the compiler returns a non-success return code.  If you specify
  \&\fB\-pass\-exit\-codes\fR, the \fBgcc\fR program instead returns with
  the numerically highest error produced by any phase returning an error
! indication.  The C, \*(C+, and Fortran front ends return 4 if an internal
  compiler error is encountered.
! .IP "\fB\-pipe\fR" 4
  .IX Item "-pipe"
  Use pipes rather than temporary files for communication between the
  various stages of compilation.  This fails to work on some systems where
! the assembler is unable to read from a pipe; but the \s-1GNU\s0 assembler has
  no trouble.
! .IP "\fB\-specs=\fR\fIfile\fR" 4
  .IX Item "-specs=file"
  Process \fIfile\fR after the compiler reads in the standard \fIspecs\fR
  file, in order to override the defaults which the \fBgcc\fR driver
--- 2110,2133 ----
  \&        diff /tmp/O2\-opts /tmp/O3\-opts | grep enabled
  .Ve
  .RE
! .IP \fB\-\-version\fR 4
  .IX Item "--version"
! Display the version number and copyrights of the invoked GCC.
! .IP \fB\-pass\-exit\-codes\fR 4
  .IX Item "-pass-exit-codes"
  Normally the \fBgcc\fR program exits with the code of 1 if any
! phase of the compiler returns a non\-success return code.  If you specify
  \&\fB\-pass\-exit\-codes\fR, the \fBgcc\fR program instead returns with
  the numerically highest error produced by any phase returning an error
! indication.  The C, C++, and Fortran front ends return 4 if an internal
  compiler error is encountered.
! .IP \fB\-pipe\fR 4
  .IX Item "-pipe"
  Use pipes rather than temporary files for communication between the
  various stages of compilation.  This fails to work on some systems where
! the assembler is unable to read from a pipe; but the GNU assembler has
  no trouble.
! .IP \fB\-specs=\fR\fIfile\fR 4
  .IX Item "-specs=file"
  Process \fIfile\fR after the compiler reads in the standard \fIspecs\fR
  file, in order to override the defaults which the \fBgcc\fR driver
*************** program uses when determining what switc
*** 2206,2212 ****
  \&\fBcc1plus\fR, \fBas\fR, \fBld\fR, etc.  More than one
  \&\fB\-specs=\fR\fIfile\fR can be specified on the command line, and they
  are processed in order, from left to right.
! .IP "\fB\-wrapper\fR" 4
  .IX Item "-wrapper"
  Invoke all subcommands under a wrapper program.  The name of the
  wrapper program and its parameters are passed as a comma separated
--- 2135,2141 ----
  \&\fBcc1plus\fR, \fBas\fR, \fBld\fR, etc.  More than one
  \&\fB\-specs=\fR\fIfile\fR can be specified on the command line, and they
  are processed in order, from left to right.
! .IP \fB\-wrapper\fR 4
  .IX Item "-wrapper"
  Invoke all subcommands under a wrapper program.  The name of the
  wrapper program and its parameters are passed as a comma separated
*************** list.
*** 2219,2275 ****
  This invokes all subprograms of \fBgcc\fR under
  \&\fBgdb \-\-args\fR, thus the invocation of \fBcc1\fR is
  \&\fBgdb \-\-args cc1 ...\fR.
! .IP "\fB\-ffile\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
  .IX Item "-ffile-prefix-map=old=new"
! When compiling files residing in directory \fI\fIold\fI\fR, record
  any references to them in the result of the compilation as if the
! files resided in directory \fI\fInew\fI\fR instead.  Specifying this
  option is equivalent to specifying all the individual
  \&\fB\-f*\-prefix\-map\fR options.  This can be used to make reproducible
  builds that are location independent.  Directories referenced by
  directives are not affected by these options.  See also
  \&\fB\-fmacro\-prefix\-map\fR, \fB\-fdebug\-prefix\-map\fR,
  \&\fB\-fprofile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP "\fB\-fcanon\-prefix\-map\fR" 4
  .IX Item "-fcanon-prefix-map"
  For the \fB\-f*\-prefix\-map\fR options normally comparison
! of \fI\fIold\fI\fR prefix against the filename that would be normally
  referenced in the result of the compilation is done using textual
  comparison of the prefixes, or ignoring character case for case insensitive
! filesystems and considering slashes and backslashes as equal on \s-1DOS\s0 based
  filesystems.  The \fB\-fcanon\-prefix\-map\fR causes such comparisons
! to be done on canonicalized paths of \fI\fIold\fI\fR
  and the referenced filename.
! .IP "\fB\-fplugin=\fR\fIname\fR\fB.so\fR" 4
  .IX Item "-fplugin=name.so"
  Load the plugin code in file \fIname\fR.so, assumed to be a
! shared object to be dlopen'd by the compiler.  The base name of
  the shared object file is used to identify the plugin for the
  purposes of argument parsing (See
  \&\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR below).
  Each plugin should define the callback functions specified in the
! Plugins \s-1API.\s0
! .IP "\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR" 4
  .IX Item "-fplugin-arg-name-key=value"
  Define an argument called \fIkey\fR with a value of \fIvalue\fR
  for the plugin called \fIname\fR.
! .IP "\fB\-fdump\-ada\-spec\fR[\fB\-slim\fR]" 4
  .IX Item "-fdump-ada-spec[-slim]"
! For C and \*(C+ source and include files, generate corresponding Ada specs.
! .IP "\fB\-fada\-spec\-parent=\fR\fIunit\fR" 4
  .IX Item "-fada-spec-parent=unit"
  In conjunction with \fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] above, generate
  Ada specs as child units of parent \fIunit\fR.
! .IP "\fB\-fdump\-go\-spec=\fR\fIfile\fR" 4
  .IX Item "-fdump-go-spec=file"
  For input files in any language, generate corresponding Go
  declarations in \fIfile\fR.  This generates Go \f(CW\*(C`const\*(C'\fR,
  \&\f(CW\*(C`type\*(C'\fR, \f(CW\*(C`var\*(C'\fR, and \f(CW\*(C`func\*(C'\fR declarations which may be a
  useful way to start writing a Go interface to code written in some
  other language.
! .IP "\fB@\fR\fIfile\fR" 4
  .IX Item "@file"
! Read command-line options from \fIfile\fR.  The options read are
  inserted in place of the original @\fIfile\fR option.  If \fIfile\fR
  does not exist, or cannot be read, then the option will be treated
  literally, and not removed.
--- 2148,2204 ----
  This invokes all subprograms of \fBgcc\fR under
  \&\fBgdb \-\-args\fR, thus the invocation of \fBcc1\fR is
  \&\fBgdb \-\-args cc1 ...\fR.
! .IP \fB\-ffile\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 4
  .IX Item "-ffile-prefix-map=old=new"
! When compiling files residing in directory \fIold\fR, record
  any references to them in the result of the compilation as if the
! files resided in directory \fInew\fR instead.  Specifying this
  option is equivalent to specifying all the individual
  \&\fB\-f*\-prefix\-map\fR options.  This can be used to make reproducible
  builds that are location independent.  Directories referenced by
  directives are not affected by these options.  See also
  \&\fB\-fmacro\-prefix\-map\fR, \fB\-fdebug\-prefix\-map\fR,
  \&\fB\-fprofile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP \fB\-fcanon\-prefix\-map\fR 4
  .IX Item "-fcanon-prefix-map"
  For the \fB\-f*\-prefix\-map\fR options normally comparison
! of \fIold\fR prefix against the filename that would be normally
  referenced in the result of the compilation is done using textual
  comparison of the prefixes, or ignoring character case for case insensitive
! filesystems and considering slashes and backslashes as equal on DOS based
  filesystems.  The \fB\-fcanon\-prefix\-map\fR causes such comparisons
! to be done on canonicalized paths of \fIold\fR
  and the referenced filename.
! .IP \fB\-fplugin=\fR\fIname\fR\fB.so\fR 4
  .IX Item "-fplugin=name.so"
  Load the plugin code in file \fIname\fR.so, assumed to be a
! shared object to be dlopen\*(Aqd by the compiler.  The base name of
  the shared object file is used to identify the plugin for the
  purposes of argument parsing (See
  \&\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR below).
  Each plugin should define the callback functions specified in the
! Plugins API.
! .IP \fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR 4
  .IX Item "-fplugin-arg-name-key=value"
  Define an argument called \fIkey\fR with a value of \fIvalue\fR
  for the plugin called \fIname\fR.
! .IP \fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] 4
  .IX Item "-fdump-ada-spec[-slim]"
! For C and C++ source and include files, generate corresponding Ada specs.
! .IP \fB\-fada\-spec\-parent=\fR\fIunit\fR 4
  .IX Item "-fada-spec-parent=unit"
  In conjunction with \fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] above, generate
  Ada specs as child units of parent \fIunit\fR.
! .IP \fB\-fdump\-go\-spec=\fR\fIfile\fR 4
  .IX Item "-fdump-go-spec=file"
  For input files in any language, generate corresponding Go
  declarations in \fIfile\fR.  This generates Go \f(CW\*(C`const\*(C'\fR,
  \&\f(CW\*(C`type\*(C'\fR, \f(CW\*(C`var\*(C'\fR, and \f(CW\*(C`func\*(C'\fR declarations which may be a
  useful way to start writing a Go interface to code written in some
  other language.
! .IP \fB@\fR\fIfile\fR 4
  .IX Item "@file"
! Read command\-line options from \fIfile\fR.  The options read are
  inserted in place of the original @\fIfile\fR option.  If \fIfile\fR
  does not exist, or cannot be read, then the option will be treated
  literally, and not removed.
*************** option in either single or double quotes
*** 2280,2569 ****
  backslash) may be included by prefixing the character to be included
  with a backslash.  The \fIfile\fR may itself contain additional
  @\fIfile\fR options; any such options will be processed recursively.
! .SS "Compiling \*(C+ Programs"
! .IX Subsection "Compiling Programs"
! \&\*(C+ source files conventionally use one of the suffixes \fB.C\fR,
  \&\fB.cc\fR, \fB.cpp\fR, \fB.CPP\fR, \fB.c++\fR, \fB.cp\fR, or
! \&\fB.cxx\fR; \*(C+ header files often use \fB.hh\fR, \fB.hpp\fR,
  \&\fB.H\fR, or (for shared template code) \fB.tcc\fR; and
! preprocessed \*(C+ files use the suffix \fB.ii\fR.  \s-1GCC\s0 recognizes
! files with these names and compiles them as \*(C+ programs even if you
  call the compiler the same way as for compiling C programs (usually
  with the name \fBgcc\fR).
  .PP
! However, the use of \fBgcc\fR does not add the \*(C+ library.
! \&\fBg++\fR is a program that calls \s-1GCC\s0 and automatically specifies linking
! against the \*(C+ library.  It treats \fB.c\fR,
! \&\fB.h\fR and \fB.i\fR files as \*(C+ source files instead of C source
  files unless \fB\-x\fR is used.  This program is also useful when
! precompiling a C header file with a \fB.h\fR extension for use in \*(C+
  compilations.  On many systems, \fBg++\fR is also installed with
  the name \fBc++\fR.
  .PP
! When you compile \*(C+ programs, you may specify many of the same
! command-line options that you use for compiling programs in any
! language; or command-line options meaningful for C and related
! languages; or options that are meaningful only for \*(C+ programs.
  .SS "Options Controlling C Dialect"
  .IX Subsection "Options Controlling C Dialect"
  The following options control the dialect of C (or languages derived
! from C, such as \*(C+, Objective-C and Objective\-\*(C+) that the compiler
  accepts:
! .IP "\fB\-ansi\fR" 4
  .IX Item "-ansi"
! In C mode, this is equivalent to \fB\-std=c90\fR. In \*(C+ mode, it is
  equivalent to \fB\-std=c++98\fR.
  .Sp
! This turns off certain features of \s-1GCC\s0 that are incompatible with \s-1ISO
! C90\s0 (when compiling C code), or of standard \*(C+ (when compiling \*(C+ code),
  such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, and
  predefined macros such as \f(CW\*(C`unix\*(C'\fR and \f(CW\*(C`vax\*(C'\fR that identify the
  type of system you are using.  It also enables the undesirable and
! rarely used \s-1ISO\s0 trigraph feature.  For the C compiler,
! it disables recognition of \*(C+ style \fB//\fR comments as well as
  the \f(CW\*(C`inline\*(C'\fR keyword.
  .Sp
  The alternate keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_extension_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR continue to work despite
! \&\fB\-ansi\fR.  You would not want to use them in an \s-1ISO C\s0 program, of
  course, but it is useful to put them in header files that might be included
  in compilations done with \fB\-ansi\fR.  Alternate predefined macros
  such as \f(CW\*(C`_\|_unix_\|_\*(C'\fR and \f(CW\*(C`_\|_vax_\|_\*(C'\fR are also available, with or
  without \fB\-ansi\fR.
  .Sp
! The \fB\-ansi\fR option does not cause non-ISO programs to be
  rejected gratuitously.  For that, \fB\-Wpedantic\fR is required in
  addition to \fB\-ansi\fR.
  .Sp
  The macro \f(CW\*(C`_\|_STRICT_ANSI_\|_\*(C'\fR is predefined when the \fB\-ansi\fR
  option is used.  Some header files may notice this macro and refrain
  from declaring certain functions or defining certain macros that the
! \&\s-1ISO\s0 standard doesn't call for; this is to avoid interfering with any
  programs that might use these names for other things.
  .Sp
  Functions that are normally built in but do not have semantics
! defined by \s-1ISO C\s0 (such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built-in
  functions when \fB\-ansi\fR is used.
! .IP "\fB\-std=\fR" 4
  .IX Item "-std="
  Determine the language standard.   This option
! is currently only supported when compiling C or \*(C+.
  .Sp
  The compiler can accept several base standards, such as \fBc90\fR or
! \&\fBc++98\fR, and \s-1GNU\s0 dialects of those standards, such as
  \&\fBgnu90\fR or \fBgnu++98\fR.  When a base standard is specified, the
  compiler accepts all programs following that standard plus those
! using \s-1GNU\s0 extensions that do not contradict it.  For example,
! \&\fB\-std=c90\fR turns off certain features of \s-1GCC\s0 that are
! incompatible with \s-1ISO C90,\s0 such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR
! keywords, but not other \s-1GNU\s0 extensions that do not have a meaning in
! \&\s-1ISO C90,\s0 such as omitting the middle term of a \f(CW\*(C`?:\*(C'\fR
! expression. On the other hand, when a \s-1GNU\s0 dialect of a standard is
  specified, all features supported by the compiler are enabled, even when
  those features change the meaning of the base standard.  As a result, some
! strict-conforming programs may be rejected.  The particular standard
! is used by \fB\-Wpedantic\fR to identify which features are \s-1GNU\s0
  extensions given that version of the standard. For example
! \&\fB\-std=gnu90 \-Wpedantic\fR warns about \*(C+ style \fB//\fR
  comments, while \fB\-std=gnu99 \-Wpedantic\fR does not.
  .Sp
  A value for this option must be provided; possible values are
  .RS 4
! .IP "\fBc90\fR" 4
  .IX Item "c90"
  .PD 0
! .IP "\fBc89\fR" 4
  .IX Item "c89"
! .IP "\fBiso9899:1990\fR" 4
  .IX Item "iso9899:1990"
  .PD
! Support all \s-1ISO C90\s0 programs (certain \s-1GNU\s0 extensions that conflict
! with \s-1ISO C90\s0 are disabled). Same as \fB\-ansi\fR for C code.
! .IP "\fBiso9899:199409\fR" 4
  .IX Item "iso9899:199409"
! \&\s-1ISO C90\s0 as modified in amendment 1.
! .IP "\fBc99\fR" 4
  .IX Item "c99"
  .PD 0
! .IP "\fBc9x\fR" 4
  .IX Item "c9x"
! .IP "\fBiso9899:1999\fR" 4
  .IX Item "iso9899:1999"
! .IP "\fBiso9899:199x\fR" 4
  .IX Item "iso9899:199x"
  .PD
! \&\s-1ISO C99.\s0  This standard is substantially completely supported, modulo
! bugs and floating-point issues
  (mainly but not entirely relating to optional C99 features from
  Annexes F and G).  See
  <\fBhttps://gcc.gnu.org/c99status.html\fR> for more information.  The
  names \fBc9x\fR and \fBiso9899:199x\fR are deprecated.
! .IP "\fBc11\fR" 4
  .IX Item "c11"
  .PD 0
! .IP "\fBc1x\fR" 4
  .IX Item "c1x"
! .IP "\fBiso9899:2011\fR" 4
  .IX Item "iso9899:2011"
  .PD
! \&\s-1ISO C11,\s0 the 2011 revision of the \s-1ISO C\s0 standard.  This standard is
! substantially completely supported, modulo bugs, floating-point issues
  (mainly but not entirely relating to optional C11 features from
! Annexes F and G) and the optional Annexes K (Bounds-checking
  interfaces) and L (Analyzability).  The name \fBc1x\fR is deprecated.
! .IP "\fBc17\fR" 4
  .IX Item "c17"
  .PD 0
! .IP "\fBc18\fR" 4
  .IX Item "c18"
! .IP "\fBiso9899:2017\fR" 4
  .IX Item "iso9899:2017"
! .IP "\fBiso9899:2018\fR" 4
  .IX Item "iso9899:2018"
  .PD
! \&\s-1ISO C17,\s0 the 2017 revision of the \s-1ISO C\s0 standard
  (published in 2018).  This standard is
  same as C11 except for corrections of defects (all of which are also
  applied with \fB\-std=c11\fR) and a new value of
  \&\f(CW\*(C`_\|_STDC_VERSION_\|_\*(C'\fR, and so is supported to the same extent as C11.
! .IP "\fBc2x\fR" 4
  .IX Item "c2x"
! The next version of the \s-1ISO C\s0 standard, still under development.  The
  support for this version is experimental and incomplete.
! .IP "\fBgnu90\fR" 4
  .IX Item "gnu90"
  .PD 0
! .IP "\fBgnu89\fR" 4
  .IX Item "gnu89"
  .PD
! \&\s-1GNU\s0 dialect of \s-1ISO C90\s0 (including some C99 features).
! .IP "\fBgnu99\fR" 4
  .IX Item "gnu99"
  .PD 0
! .IP "\fBgnu9x\fR" 4
  .IX Item "gnu9x"
  .PD
! \&\s-1GNU\s0 dialect of \s-1ISO C99.\s0  The name \fBgnu9x\fR is deprecated.
! .IP "\fBgnu11\fR" 4
  .IX Item "gnu11"
  .PD 0
! .IP "\fBgnu1x\fR" 4
  .IX Item "gnu1x"
  .PD
! \&\s-1GNU\s0 dialect of \s-1ISO C11.\s0
  The name \fBgnu1x\fR is deprecated.
! .IP "\fBgnu17\fR" 4
  .IX Item "gnu17"
  .PD 0
! .IP "\fBgnu18\fR" 4
  .IX Item "gnu18"
  .PD
! \&\s-1GNU\s0 dialect of \s-1ISO C17.\s0  This is the default for C code.
! .IP "\fBgnu2x\fR" 4
  .IX Item "gnu2x"
! The next version of the \s-1ISO C\s0 standard, still under development, plus
! \&\s-1GNU\s0 extensions.  The support for this version is experimental and
  incomplete.
! .IP "\fBc++98\fR" 4
  .IX Item "c++98"
  .PD 0
! .IP "\fBc++03\fR" 4
  .IX Item "c++03"
  .PD
! The 1998 \s-1ISO \*(C+\s0 standard plus the 2003 technical corrigendum and some
! additional defect reports. Same as \fB\-ansi\fR for \*(C+ code.
! .IP "\fBgnu++98\fR" 4
  .IX Item "gnu++98"
  .PD 0
! .IP "\fBgnu++03\fR" 4
  .IX Item "gnu++03"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++98\fR.
! .IP "\fBc++11\fR" 4
  .IX Item "c++11"
  .PD 0
! .IP "\fBc++0x\fR" 4
  .IX Item "c++0x"
  .PD
! The 2011 \s-1ISO \*(C+\s0 standard plus amendments.
  The name \fBc++0x\fR is deprecated.
! .IP "\fBgnu++11\fR" 4
  .IX Item "gnu++11"
  .PD 0
! .IP "\fBgnu++0x\fR" 4
  .IX Item "gnu++0x"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++11\fR.
  The name \fBgnu++0x\fR is deprecated.
! .IP "\fBc++14\fR" 4
  .IX Item "c++14"
  .PD 0
! .IP "\fBc++1y\fR" 4
  .IX Item "c++1y"
  .PD
! The 2014 \s-1ISO \*(C+\s0 standard plus amendments.
  The name \fBc++1y\fR is deprecated.
! .IP "\fBgnu++14\fR" 4
  .IX Item "gnu++14"
  .PD 0
! .IP "\fBgnu++1y\fR" 4
  .IX Item "gnu++1y"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++14\fR.
  The name \fBgnu++1y\fR is deprecated.
! .IP "\fBc++17\fR" 4
  .IX Item "c++17"
  .PD 0
! .IP "\fBc++1z\fR" 4
  .IX Item "c++1z"
  .PD
! The 2017 \s-1ISO \*(C+\s0 standard plus amendments.
  The name \fBc++1z\fR is deprecated.
! .IP "\fBgnu++17\fR" 4
  .IX Item "gnu++17"
  .PD 0
! .IP "\fBgnu++1z\fR" 4
  .IX Item "gnu++1z"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++17\fR.
! This is the default for \*(C+ code.
  The name \fBgnu++1z\fR is deprecated.
! .IP "\fBc++20\fR" 4
  .IX Item "c++20"
  .PD 0
! .IP "\fBc++2a\fR" 4
  .IX Item "c++2a"
  .PD
! The 2020 \s-1ISO \*(C+\s0 standard plus amendments.
  Support is experimental, and could change in incompatible ways in
  future releases.
  The name \fBc++2a\fR is deprecated.
! .IP "\fBgnu++20\fR" 4
  .IX Item "gnu++20"
  .PD 0
! .IP "\fBgnu++2a\fR" 4
  .IX Item "gnu++2a"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++20\fR.
  Support is experimental, and could change in incompatible ways in
  future releases.
  The name \fBgnu++2a\fR is deprecated.
! .IP "\fBc++2b\fR" 4
  .IX Item "c++2b"
  .PD 0
! .IP "\fBc++23\fR" 4
  .IX Item "c++23"
  .PD
! The next revision of the \s-1ISO \*(C+\s0 standard, planned for
  2023.  Support is highly experimental, and will almost certainly
  change in incompatible ways in future releases.
! .IP "\fBgnu++2b\fR" 4
  .IX Item "gnu++2b"
  .PD 0
! .IP "\fBgnu++23\fR" 4
  .IX Item "gnu++23"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++2b\fR.  Support is highly experimental,
  and will almost certainly change in incompatible ways in future
  releases.
  .RE
--- 2209,2498 ----
  backslash) may be included by prefixing the character to be included
  with a backslash.  The \fIfile\fR may itself contain additional
  @\fIfile\fR options; any such options will be processed recursively.
! .SS "Compiling C++ Programs"
! .IX Subsection "Compiling C++ Programs"
! C++ source files conventionally use one of the suffixes \fB.C\fR,
  \&\fB.cc\fR, \fB.cpp\fR, \fB.CPP\fR, \fB.c++\fR, \fB.cp\fR, or
! \&\fB.cxx\fR; C++ header files often use \fB.hh\fR, \fB.hpp\fR,
  \&\fB.H\fR, or (for shared template code) \fB.tcc\fR; and
! preprocessed C++ files use the suffix \fB.ii\fR.  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 \fBgcc\fR).
  .PP
! However, the use of \fBgcc\fR does not add the C++ library.
! \&\fBg++\fR is a program that calls GCC and automatically specifies linking
! against the C++ library.  It treats \fB.c\fR,
! \&\fB.h\fR and \fB.i\fR files as C++ source files instead of C source
  files unless \fB\-x\fR is used.  This program is also useful when
! precompiling a C header file with a \fB.h\fR extension for use in C++
  compilations.  On many systems, \fBg++\fR is also installed with
  the name \fBc++\fR.
  .PP
! When you compile C++ programs, you may specify many of the same
! command\-line options that you use for compiling programs in any
! language; or command\-line options meaningful for C and related
! languages; or options that are meaningful only for C++ programs.
  .SS "Options Controlling C Dialect"
  .IX Subsection "Options Controlling C Dialect"
  The following options control the dialect of C (or languages derived
! from C, such as C++, Objective\-C and Objective\-C++) that the compiler
  accepts:
! .IP \fB\-ansi\fR 4
  .IX Item "-ansi"
! In C mode, this is equivalent to \fB\-std=c90\fR. In C++ mode, it is
  equivalent to \fB\-std=c++98\fR.
  .Sp
! This turns off certain features of GCC that are incompatible with ISO
! C90 (when compiling C code), or of standard C++ (when compiling C++ code),
  such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, and
  predefined macros such as \f(CW\*(C`unix\*(C'\fR and \f(CW\*(C`vax\*(C'\fR that identify the
  type of system you are using.  It also enables the undesirable and
! rarely used ISO trigraph feature.  For the C compiler,
! it disables recognition of C++ style \fB//\fR comments as well as
  the \f(CW\*(C`inline\*(C'\fR keyword.
  .Sp
  The alternate keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_extension_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR continue to work despite
! \&\fB\-ansi\fR.  You would not want to use them in an ISO C program, of
  course, but it is useful to put them in header files that might be included
  in compilations done with \fB\-ansi\fR.  Alternate predefined macros
  such as \f(CW\*(C`_\|_unix_\|_\*(C'\fR and \f(CW\*(C`_\|_vax_\|_\*(C'\fR are also available, with or
  without \fB\-ansi\fR.
  .Sp
! The \fB\-ansi\fR option does not cause non\-ISO programs to be
  rejected gratuitously.  For that, \fB\-Wpedantic\fR is required in
  addition to \fB\-ansi\fR.
  .Sp
  The macro \f(CW\*(C`_\|_STRICT_ANSI_\|_\*(C'\fR is predefined when the \fB\-ansi\fR
  option is used.  Some header files may notice this macro and refrain
  from declaring certain functions or defining certain macros that the
! ISO standard doesn\*(Aqt call for; this is to avoid interfering with any
  programs that might use these names for other things.
  .Sp
  Functions that are normally built in but do not have semantics
! defined by ISO C (such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built\-in
  functions when \fB\-ansi\fR is used.
! .IP \fB\-std=\fR 4
  .IX Item "-std="
  Determine the language standard.   This option
! is currently only supported when compiling C or C++.
  .Sp
  The compiler can accept several base standards, such as \fBc90\fR or
! \&\fBc++98\fR, and GNU dialects of those standards, such as
  \&\fBgnu90\fR or \fBgnu++98\fR.  When a base standard is specified, the
  compiler accepts all programs following that standard plus those
! using GNU extensions that do not contradict it.  For example,
! \&\fB\-std=c90\fR turns off certain features of GCC that are
! incompatible with ISO C90, such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR
! keywords, but not other GNU extensions that do not have a meaning in
! ISO C90, such as omitting the middle term of a \f(CW\*(C`?:\*(C'\fR
! expression. On the other hand, when a GNU dialect of a standard is
  specified, all features supported by the compiler are enabled, even when
  those features change the meaning of the base standard.  As a result, some
! strict\-conforming programs may be rejected.  The particular standard
! is used by \fB\-Wpedantic\fR to identify which features are GNU
  extensions given that version of the standard. For example
! \&\fB\-std=gnu90 \-Wpedantic\fR warns about C++ style \fB//\fR
  comments, while \fB\-std=gnu99 \-Wpedantic\fR does not.
  .Sp
  A value for this option must be provided; possible values are
  .RS 4
! .IP \fBc90\fR 4
  .IX Item "c90"
  .PD 0
! .IP \fBc89\fR 4
  .IX Item "c89"
! .IP \fBiso9899:1990\fR 4
  .IX Item "iso9899:1990"
  .PD
! Support all ISO C90 programs (certain GNU extensions that conflict
! with ISO C90 are disabled). Same as \fB\-ansi\fR for C code.
! .IP \fBiso9899:199409\fR 4
  .IX Item "iso9899:199409"
! ISO C90 as modified in amendment 1.
! .IP \fBc99\fR 4
  .IX Item "c99"
  .PD 0
! .IP \fBc9x\fR 4
  .IX Item "c9x"
! .IP \fBiso9899:1999\fR 4
  .IX Item "iso9899:1999"
! .IP \fBiso9899:199x\fR 4
  .IX Item "iso9899:199x"
  .PD
! ISO C99.  This standard is substantially completely supported, modulo
! bugs and floating\-point issues
  (mainly but not entirely relating to optional C99 features from
  Annexes F and G).  See
  <\fBhttps://gcc.gnu.org/c99status.html\fR> for more information.  The
  names \fBc9x\fR and \fBiso9899:199x\fR are deprecated.
! .IP \fBc11\fR 4
  .IX Item "c11"
  .PD 0
! .IP \fBc1x\fR 4
  .IX Item "c1x"
! .IP \fBiso9899:2011\fR 4
  .IX Item "iso9899:2011"
  .PD
! ISO C11, the 2011 revision of the ISO C standard.  This standard is
! substantially completely supported, modulo bugs, floating\-point issues
  (mainly but not entirely relating to optional C11 features from
! Annexes F and G) and the optional Annexes K (Bounds\-checking
  interfaces) and L (Analyzability).  The name \fBc1x\fR is deprecated.
! .IP \fBc17\fR 4
  .IX Item "c17"
  .PD 0
! .IP \fBc18\fR 4
  .IX Item "c18"
! .IP \fBiso9899:2017\fR 4
  .IX Item "iso9899:2017"
! .IP \fBiso9899:2018\fR 4
  .IX Item "iso9899:2018"
  .PD
! ISO C17, the 2017 revision of the ISO C standard
  (published in 2018).  This standard is
  same as C11 except for corrections of defects (all of which are also
  applied with \fB\-std=c11\fR) and a new value of
  \&\f(CW\*(C`_\|_STDC_VERSION_\|_\*(C'\fR, and so is supported to the same extent as C11.
! .IP \fBc2x\fR 4
  .IX Item "c2x"
! The next version of the ISO C standard, still under development.  The
  support for this version is experimental and incomplete.
! .IP \fBgnu90\fR 4
  .IX Item "gnu90"
  .PD 0
! .IP \fBgnu89\fR 4
  .IX Item "gnu89"
  .PD
! GNU dialect of ISO C90 (including some C99 features).
! .IP \fBgnu99\fR 4
  .IX Item "gnu99"
  .PD 0
! .IP \fBgnu9x\fR 4
  .IX Item "gnu9x"
  .PD
! GNU dialect of ISO C99.  The name \fBgnu9x\fR is deprecated.
! .IP \fBgnu11\fR 4
  .IX Item "gnu11"
  .PD 0
! .IP \fBgnu1x\fR 4
  .IX Item "gnu1x"
  .PD
! GNU dialect of ISO C11.
  The name \fBgnu1x\fR is deprecated.
! .IP \fBgnu17\fR 4
  .IX Item "gnu17"
  .PD 0
! .IP \fBgnu18\fR 4
  .IX Item "gnu18"
  .PD
! GNU dialect of ISO C17.  This is the default for C code.
! .IP \fBgnu2x\fR 4
  .IX Item "gnu2x"
! The next version of the ISO C standard, still under development, plus
! GNU extensions.  The support for this version is experimental and
  incomplete.
! .IP \fBc++98\fR 4
  .IX Item "c++98"
  .PD 0
! .IP \fBc++03\fR 4
  .IX Item "c++03"
  .PD
! The 1998 ISO C++ standard plus the 2003 technical corrigendum and some
! additional defect reports. Same as \fB\-ansi\fR for C++ code.
! .IP \fBgnu++98\fR 4
  .IX Item "gnu++98"
  .PD 0
! .IP \fBgnu++03\fR 4
  .IX Item "gnu++03"
  .PD
! GNU dialect of \fB\-std=c++98\fR.
! .IP \fBc++11\fR 4
  .IX Item "c++11"
  .PD 0
! .IP \fBc++0x\fR 4
  .IX Item "c++0x"
  .PD
! The 2011 ISO C++ standard plus amendments.
  The name \fBc++0x\fR is deprecated.
! .IP \fBgnu++11\fR 4
  .IX Item "gnu++11"
  .PD 0
! .IP \fBgnu++0x\fR 4
  .IX Item "gnu++0x"
  .PD
! GNU dialect of \fB\-std=c++11\fR.
  The name \fBgnu++0x\fR is deprecated.
! .IP \fBc++14\fR 4
  .IX Item "c++14"
  .PD 0
! .IP \fBc++1y\fR 4
  .IX Item "c++1y"
  .PD
! The 2014 ISO C++ standard plus amendments.
  The name \fBc++1y\fR is deprecated.
! .IP \fBgnu++14\fR 4
  .IX Item "gnu++14"
  .PD 0
! .IP \fBgnu++1y\fR 4
  .IX Item "gnu++1y"
  .PD
! GNU dialect of \fB\-std=c++14\fR.
  The name \fBgnu++1y\fR is deprecated.
! .IP \fBc++17\fR 4
  .IX Item "c++17"
  .PD 0
! .IP \fBc++1z\fR 4
  .IX Item "c++1z"
  .PD
! The 2017 ISO C++ standard plus amendments.
  The name \fBc++1z\fR is deprecated.
! .IP \fBgnu++17\fR 4
  .IX Item "gnu++17"
  .PD 0
! .IP \fBgnu++1z\fR 4
  .IX Item "gnu++1z"
  .PD
! GNU dialect of \fB\-std=c++17\fR.
! This is the default for C++ code.
  The name \fBgnu++1z\fR is deprecated.
! .IP \fBc++20\fR 4
  .IX Item "c++20"
  .PD 0
! .IP \fBc++2a\fR 4
  .IX Item "c++2a"
  .PD
! The 2020 ISO C++ standard plus amendments.
  Support is experimental, and could change in incompatible ways in
  future releases.
  The name \fBc++2a\fR is deprecated.
! .IP \fBgnu++20\fR 4
  .IX Item "gnu++20"
  .PD 0
! .IP \fBgnu++2a\fR 4
  .IX Item "gnu++2a"
  .PD
! GNU dialect of \fB\-std=c++20\fR.
  Support is experimental, and could change in incompatible ways in
  future releases.
  The name \fBgnu++2a\fR is deprecated.
! .IP \fBc++2b\fR 4
  .IX Item "c++2b"
  .PD 0
! .IP \fBc++23\fR 4
  .IX Item "c++23"
  .PD
! The next revision of the ISO C++ standard, planned for
  2023.  Support is highly experimental, and will almost certainly
  change in incompatible ways in future releases.
! .IP \fBgnu++2b\fR 4
  .IX Item "gnu++2b"
  .PD 0
! .IP \fBgnu++23\fR 4
  .IX Item "gnu++23"
  .PD
! GNU dialect of \fB\-std=c++2b\fR.  Support is highly experimental,
  and will almost certainly change in incompatible ways in future
  releases.
  .RE
*************** definition (\fBC\fR or \fBF\fR, respecti
*** 2584,2622 ****
  character).  In the case of function definitions, a K&R\-style list of
  arguments followed by their declarations is also provided, inside
  comments, after the declaration.
! .IP "\fB\-fno\-asm\fR" 4
  .IX Item "-fno-asm"
  Do not recognize \f(CW\*(C`asm\*(C'\fR, \f(CW\*(C`inline\*(C'\fR or \f(CW\*(C`typeof\*(C'\fR as a
  keyword, so that code can use these words as identifiers.  You can use
  the keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR
  instead.  In C, \fB\-ansi\fR implies \fB\-fno\-asm\fR.
  .Sp
! In \*(C+, \f(CW\*(C`inline\*(C'\fR is a standard keyword and is not affected by
  this switch.  You may want to use the \fB\-fno\-gnu\-keywords\fR flag
  instead, which disables \f(CW\*(C`typeof\*(C'\fR but not \f(CW\*(C`asm\*(C'\fR and
  \&\f(CW\*(C`inline\*(C'\fR.  In C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR),
  this switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords,
! since \f(CW\*(C`inline\*(C'\fR is a standard keyword in \s-1ISO C99.\s0  In C2X mode
  (\fB\-std=c2x\fR or \fB\-std=gnu2x\fR), this switch only affects
  the \f(CW\*(C`asm\*(C'\fR keyword, since \f(CW\*(C`typeof\*(C'\fR is a standard keyword in
! \&\s-1ISO C2X.\s0
! .IP "\fB\-fno\-builtin\fR" 4
  .IX Item "-fno-builtin"
  .PD 0
! .IP "\fB\-fno\-builtin\-\fR\fIfunction\fR" 4
  .IX Item "-fno-builtin-function"
  .PD
! Don't recognize built-in functions that do not begin with
  \&\fB_\|_builtin_\fR as prefix.
  .Sp
! \&\s-1GCC\s0 normally generates special code to handle certain built-in functions
  more efficiently; for instance, calls to \f(CW\*(C`alloca\*(C'\fR may become single
  instructions which adjust the stack directly, and calls to \f(CW\*(C`memcpy\*(C'\fR
  may become inline copy loops.  The resulting code is often both smaller
  and faster, but since the function calls no longer appear as such, you
  cannot set a breakpoint on those calls, nor can you change the behavior
  of the functions by linking with a different library.  In addition,
! when a function is recognized as a built-in function, \s-1GCC\s0 may use
  information about that function to warn about problems with calls to
  that function, or to generate more efficient code, even if the
  resulting code still contains calls to that function.  For example,
--- 2513,2551 ----
  character).  In the case of function definitions, a K&R\-style list of
  arguments followed by their declarations is also provided, inside
  comments, after the declaration.
! .IP \fB\-fno\-asm\fR 4
  .IX Item "-fno-asm"
  Do not recognize \f(CW\*(C`asm\*(C'\fR, \f(CW\*(C`inline\*(C'\fR or \f(CW\*(C`typeof\*(C'\fR as a
  keyword, so that code can use these words as identifiers.  You can use
  the keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR
  instead.  In C, \fB\-ansi\fR implies \fB\-fno\-asm\fR.
  .Sp
! In C++, \f(CW\*(C`inline\*(C'\fR is a standard keyword and is not affected by
  this switch.  You may want to use the \fB\-fno\-gnu\-keywords\fR flag
  instead, which disables \f(CW\*(C`typeof\*(C'\fR but not \f(CW\*(C`asm\*(C'\fR and
  \&\f(CW\*(C`inline\*(C'\fR.  In C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR),
  this switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords,
! since \f(CW\*(C`inline\*(C'\fR is a standard keyword in ISO C99.  In C2X mode
  (\fB\-std=c2x\fR or \fB\-std=gnu2x\fR), this switch only affects
  the \f(CW\*(C`asm\*(C'\fR keyword, since \f(CW\*(C`typeof\*(C'\fR is a standard keyword in
! ISO C2X.
! .IP \fB\-fno\-builtin\fR 4
  .IX Item "-fno-builtin"
  .PD 0
! .IP \fB\-fno\-builtin\-\fR\fIfunction\fR 4
  .IX Item "-fno-builtin-function"
  .PD
! Don\*(Aqt recognize built\-in functions that do not begin with
  \&\fB_\|_builtin_\fR as prefix.
  .Sp
! GCC normally generates special code to handle certain built\-in functions
  more efficiently; for instance, calls to \f(CW\*(C`alloca\*(C'\fR may become single
  instructions which adjust the stack directly, and calls to \f(CW\*(C`memcpy\*(C'\fR
  may become inline copy loops.  The resulting code is often both smaller
  and faster, but since the function calls no longer appear as such, you
  cannot set a breakpoint on those calls, nor can you change the behavior
  of the functions by linking with a different library.  In addition,
! when a function is recognized as a built\-in function, 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 \fB\-Wformat\fR
*** 2625,2681 ****
  known not to modify global memory.
  .Sp
  With the \fB\-fno\-builtin\-\fR\fIfunction\fR option
! only the built-in function \fIfunction\fR is
  disabled.  \fIfunction\fR must not begin with \fB_\|_builtin_\fR.  If a
! function is named that is not built-in in this version of \s-1GCC,\s0 this
  option is ignored.  There is no corresponding
  \&\fB\-fbuiltin\-\fR\fIfunction\fR option; if you wish to enable
! built-in functions selectively when using \fB\-fno\-builtin\fR or
  \&\fB\-ffreestanding\fR, you may define macros such as:
  .Sp
  .Vb 2
  \&        #define abs(n)          _\|_builtin_abs ((n))
  \&        #define strcpy(d, s)    _\|_builtin_strcpy ((d), (s))
  .Ve
! .IP "\fB\-fcond\-mismatch\fR" 4
  .IX Item "-fcond-mismatch"
  Allow conditional expressions with mismatched types in the second and
  third arguments.  The value of such an expression is void.  This option
! is not supported for \*(C+.
! .IP "\fB\-ffreestanding\fR" 4
  .IX Item "-ffreestanding"
  Assert that compilation targets a freestanding environment.  This
  implies \fB\-fno\-builtin\fR.  A freestanding environment
  is one in which the standard library may not exist, and program startup may
! not necessarily be at \f(CW\*(C`main\*(C'\fR.  The most obvious example is an \s-1OS\s0 kernel.
  This is equivalent to \fB\-fno\-hosted\fR.
! .IP "\fB\-fgimple\fR" 4
  .IX Item "-fgimple"
  Enable parsing of function definitions marked with \f(CW\*(C`_\|_GIMPLE\*(C'\fR.
! This is an experimental feature that allows unit testing of \s-1GIMPLE\s0
  passes.
! .IP "\fB\-fgnu\-tm\fR" 4
  .IX Item "-fgnu-tm"
  When the option \fB\-fgnu\-tm\fR is specified, the compiler
! generates code for the Linux variant of Intel's current Transactional
! Memory \s-1ABI\s0 specification document (Revision 1.1, May 6 2009).  This is
  an experimental feature whose interface may change in future versions
! of \s-1GCC,\s0 as the official specification changes.  Please note that not
  all architectures are supported for this feature.
  .Sp
! For more information on \s-1GCC\s0's support for transactional memory,
  .Sp
  Note that the transactional memory feature is not supported with
! non-call exceptions (\fB\-fnon\-call\-exceptions\fR).
! .IP "\fB\-fgnu89\-inline\fR" 4
  .IX Item "-fgnu89-inline"
! The option \fB\-fgnu89\-inline\fR tells \s-1GCC\s0 to use the traditional
! \&\s-1GNU\s0 semantics for \f(CW\*(C`inline\*(C'\fR functions when in C99 mode.
  .Sp
  Using this option is roughly equivalent to adding the
  \&\f(CW\*(C`gnu_inline\*(C'\fR function attribute to all inline functions.
  .Sp
! The option \fB\-fno\-gnu89\-inline\fR explicitly tells \s-1GCC\s0 to use the
  C99 semantics for \f(CW\*(C`inline\*(C'\fR when in C99 or gnu99 mode (i.e., it
  specifies the default behavior).
  This option is not supported in \fB\-std=c90\fR or
--- 2554,2610 ----
  known not to modify global memory.
  .Sp
  With the \fB\-fno\-builtin\-\fR\fIfunction\fR option
! only the built\-in function \fIfunction\fR is
  disabled.  \fIfunction\fR must not begin with \fB_\|_builtin_\fR.  If a
! function is named that is not built\-in in this version of GCC, this
  option is ignored.  There is no corresponding
  \&\fB\-fbuiltin\-\fR\fIfunction\fR option; if you wish to enable
! built\-in functions selectively when using \fB\-fno\-builtin\fR or
  \&\fB\-ffreestanding\fR, you may define macros such as:
  .Sp
  .Vb 2
  \&        #define abs(n)          _\|_builtin_abs ((n))
  \&        #define strcpy(d, s)    _\|_builtin_strcpy ((d), (s))
  .Ve
! .IP \fB\-fcond\-mismatch\fR 4
  .IX Item "-fcond-mismatch"
  Allow conditional expressions with mismatched types in the second and
  third arguments.  The value of such an expression is void.  This option
! is not supported for C++.
! .IP \fB\-ffreestanding\fR 4
  .IX Item "-ffreestanding"
  Assert that compilation targets a freestanding environment.  This
  implies \fB\-fno\-builtin\fR.  A freestanding environment
  is one in which the standard library may not exist, and program startup may
! not necessarily be at \f(CW\*(C`main\*(C'\fR.  The most obvious example is an OS kernel.
  This is equivalent to \fB\-fno\-hosted\fR.
! .IP \fB\-fgimple\fR 4
  .IX Item "-fgimple"
  Enable parsing of function definitions marked with \f(CW\*(C`_\|_GIMPLE\*(C'\fR.
! This is an experimental feature that allows unit testing of GIMPLE
  passes.
! .IP \fB\-fgnu\-tm\fR 4
  .IX Item "-fgnu-tm"
  When the option \fB\-fgnu\-tm\fR is specified, the compiler
! generates code for the Linux variant of Intel\*(Aqs current Transactional
! Memory ABI specification document (Revision 1.1, May 6 2009).  This is
  an experimental feature whose interface may change in future versions
! of GCC, as the official specification changes.  Please note that not
  all architectures are supported for this feature.
  .Sp
! For more information on GCC\*(Aqs support for transactional memory,
  .Sp
  Note that the transactional memory feature is not supported with
! non\-call exceptions (\fB\-fnon\-call\-exceptions\fR).
! .IP \fB\-fgnu89\-inline\fR 4
  .IX Item "-fgnu89-inline"
! The option \fB\-fgnu89\-inline\fR tells GCC to use the traditional
! GNU semantics for \f(CW\*(C`inline\*(C'\fR functions when in C99 mode.
  .Sp
  Using this option is roughly equivalent to adding the
  \&\f(CW\*(C`gnu_inline\*(C'\fR function attribute to all inline functions.
  .Sp
! The option \fB\-fno\-gnu89\-inline\fR explicitly tells GCC to use the
  C99 semantics for \f(CW\*(C`inline\*(C'\fR when in C99 or gnu99 mode (i.e., it
  specifies the default behavior).
  This option is not supported in \fB\-std=c90\fR or
*************** This option is not supported in \fB\-std
*** 2684,2706 ****
  The preprocessor macros \f(CW\*(C`_\|_GNUC_GNU_INLINE_\|_\*(C'\fR and
  \&\f(CW\*(C`_\|_GNUC_STDC_INLINE_\|_\*(C'\fR may be used to check which semantics are
  in effect for \f(CW\*(C`inline\*(C'\fR functions.
! .IP "\fB\-fhosted\fR" 4
  .IX Item "-fhosted"
  Assert that compilation targets a hosted environment.  This implies
  \&\fB\-fbuiltin\fR.  A hosted environment is one in which the
  entire standard library is available, and in which \f(CW\*(C`main\*(C'\fR has a return
  type of \f(CW\*(C`int\*(C'\fR.  Examples are nearly everything except a kernel.
  This is equivalent to \fB\-fno\-freestanding\fR.
! .IP "\fB\-flax\-vector\-conversions\fR" 4
  .IX Item "-flax-vector-conversions"
  Allow implicit conversions between vectors with differing numbers of
  elements and/or incompatible element types.  This option should not be
  used for new code.
! .IP "\fB\-fms\-extensions\fR" 4
  .IX Item "-fms-extensions"
! Accept some non-standard constructs used in Microsoft header files.
  .Sp
! In \*(C+ code, this allows member names in structures to be similar
  to previous types declarations.
  .Sp
  .Vb 4
--- 2613,2635 ----
  The preprocessor macros \f(CW\*(C`_\|_GNUC_GNU_INLINE_\|_\*(C'\fR and
  \&\f(CW\*(C`_\|_GNUC_STDC_INLINE_\|_\*(C'\fR may be used to check which semantics are
  in effect for \f(CW\*(C`inline\*(C'\fR functions.
! .IP \fB\-fhosted\fR 4
  .IX Item "-fhosted"
  Assert that compilation targets a hosted environment.  This implies
  \&\fB\-fbuiltin\fR.  A hosted environment is one in which the
  entire standard library is available, and in which \f(CW\*(C`main\*(C'\fR has a return
  type of \f(CW\*(C`int\*(C'\fR.  Examples are nearly everything except a kernel.
  This is equivalent to \fB\-fno\-freestanding\fR.
! .IP \fB\-flax\-vector\-conversions\fR 4
  .IX Item "-flax-vector-conversions"
  Allow implicit conversions between vectors with differing numbers of
  elements and/or incompatible element types.  This option should not be
  used for new code.
! .IP \fB\-fms\-extensions\fR 4
  .IX Item "-fms-extensions"
! Accept some non\-standard constructs used in Microsoft header files.
  .Sp
! In C++ code, this allows member names in structures to be similar
  to previous types declarations.
  .Sp
  .Vb 4
*************** Some cases of unnamed fields in structur
*** 2714,2749 ****
  accepted with this option.
  .Sp
  Note that this option is off for all targets except for x86
! targets using ms-abi.
! .IP "\fB\-foffload=disable\fR" 4
  .IX Item "-foffload=disable"
  .PD 0
! .IP "\fB\-foffload=default\fR" 4
  .IX Item "-foffload=default"
! .IP "\fB\-foffload=\fR\fItarget-list\fR" 4
  .IX Item "-foffload=target-list"
  .PD
  Specify for which OpenMP and OpenACC offload targets code should be generated.
  The default behavior, equivalent to \fB\-foffload=default\fR, is to generate
  code for all supported offload targets.  The \fB\-foffload=disable\fR form
  generates code only for the host fallback, while
! \&\fB\-foffload=\fR\fItarget-list\fR generates code only for the specified
! comma-separated list of offload targets.
  .Sp
! Offload targets are specified in \s-1GCC\s0's internal target-triplet format. You can
  run the compiler with \fB\-v\fR to show the list of configured offload targets
  under \f(CW\*(C`OFFLOAD_TARGET_NAMES\*(C'\fR.
! .IP "\fB\-foffload\-options=\fR\fIoptions\fR" 4
  .IX Item "-foffload-options=options"
  .PD 0
! .IP "\fB\-foffload\-options=\fR\fItarget-triplet-list\fR\fB=\fR\fIoptions\fR" 4
  .IX Item "-foffload-options=target-triplet-list=options"
  .PD
! With \fB\-foffload\-options=\fR\fIoptions\fR, \s-1GCC\s0 passes the specified
  \&\fIoptions\fR to the compilers for all enabled offloading targets.  You can
  specify options that apply only to a specific target or targets by using
! the \fB\-foffload\-options=\fR\fItarget-list\fR\fB=\fR\fIoptions\fR form.  The
! \&\fItarget-list\fR is a comma-separated list in the same format as for the
  \&\fB\-foffload=\fR option.
  .Sp
  Typical command lines are
--- 2643,2678 ----
  accepted with this option.
  .Sp
  Note that this option is off for all targets except for x86
! targets using ms\-abi.
! .IP \fB\-foffload=disable\fR 4
  .IX Item "-foffload=disable"
  .PD 0
! .IP \fB\-foffload=default\fR 4
  .IX Item "-foffload=default"
! .IP \fB\-foffload=\fR\fItarget\-list\fR 4
  .IX Item "-foffload=target-list"
  .PD
  Specify for which OpenMP and OpenACC offload targets code should be generated.
  The default behavior, equivalent to \fB\-foffload=default\fR, is to generate
  code for all supported offload targets.  The \fB\-foffload=disable\fR form
  generates code only for the host fallback, while
! \&\fB\-foffload=\fR\fItarget\-list\fR generates code only for the specified
! comma\-separated list of offload targets.
  .Sp
! Offload targets are specified in GCC\*(Aqs internal target\-triplet format. You can
  run the compiler with \fB\-v\fR to show the list of configured offload targets
  under \f(CW\*(C`OFFLOAD_TARGET_NAMES\*(C'\fR.
! .IP \fB\-foffload\-options=\fR\fIoptions\fR 4
  .IX Item "-foffload-options=options"
  .PD 0
! .IP \fB\-foffload\-options=\fR\fItarget\-triplet\-list\fR\fB=\fR\fIoptions\fR 4
  .IX Item "-foffload-options=target-triplet-list=options"
  .PD
! With \fB\-foffload\-options=\fR\fIoptions\fR, GCC passes the specified
  \&\fIoptions\fR to the compilers for all enabled offloading targets.  You can
  specify options that apply only to a specific target or targets by using
! the \fB\-foffload\-options=\fR\fItarget\-list\fR\fB=\fR\fIoptions\fR form.  The
! \&\fItarget\-list\fR is a comma\-separated list in the same format as for the
  \&\fB\-foffload=\fR option.
  .Sp
  Typical command lines are
*************** Typical command lines are
*** 2753,2801 ****
  \&        \-foffload\-options="\-lgfortran \-lm" \-foffload\-options=nvptx\-none=\-latomic
  \&        \-foffload\-options=amdgcn\-amdhsa=\-march=gfx906 \-foffload\-options=\-lm
  .Ve
! .IP "\fB\-fopenacc\fR" 4
  .IX Item "-fopenacc"
! Enable handling of OpenACC directives \f(CW\*(C`#pragma acc\*(C'\fR in C/\*(C+ and
  \&\f(CW\*(C`!$acc\*(C'\fR in Fortran.  When \fB\-fopenacc\fR is specified, the
  compiler generates accelerated code according to the OpenACC Application
  Programming Interface v2.6 <\fBhttps://www.openacc.org\fR>.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets that
  have support for \fB\-pthread\fR.
! .IP "\fB\-fopenacc\-dim=\fR\fIgeom\fR" 4
  .IX Item "-fopenacc-dim=geom"
  Specify default compute dimensions for parallel offload regions that do
  not explicitly specify.  The \fIgeom\fR value is a triple of
! \&':'\-separated sizes, in order 'gang', 'worker' and, 'vector'.  A size
! can be omitted, to use a target-specific default value.
! .IP "\fB\-fopenmp\fR" 4
  .IX Item "-fopenmp"
! Enable handling of OpenMP directives \f(CW\*(C`#pragma omp\*(C'\fR in C/\*(C+,
! \&\f(CW\*(C`[[omp::directive(...)]]\*(C'\fR and \f(CW\*(C`[[omp::sequence(...)]]\*(C'\fR in \*(C+ and
  \&\f(CW\*(C`!$omp\*(C'\fR in Fortran.  When \fB\-fopenmp\fR is specified, the
  compiler generates parallel code according to the OpenMP Application
  Program Interface v4.5 <\fBhttps://www.openmp.org\fR>.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets that
  have support for \fB\-pthread\fR. \fB\-fopenmp\fR implies
  \&\fB\-fopenmp\-simd\fR.
! .IP "\fB\-fopenmp\-simd\fR" 4
  .IX Item "-fopenmp-simd"
! Enable handling of OpenMP's \f(CW\*(C`simd\*(C'\fR, \f(CW\*(C`declare simd\*(C'\fR,
  \&\f(CW\*(C`declare reduction\*(C'\fR, \f(CW\*(C`assume\*(C'\fR, \f(CW\*(C`ordered\*(C'\fR, \f(CW\*(C`scan\*(C'\fR,
  \&\f(CW\*(C`loop\*(C'\fR directives and combined or composite directives with
! \&\f(CW\*(C`simd\*(C'\fR as constituent with \f(CW\*(C`#pragma omp\*(C'\fR in C/\*(C+,
! \&\f(CW\*(C`[[omp::directive(...)]]\*(C'\fR and \f(CW\*(C`[[omp::sequence(...)]]\*(C'\fR in \*(C+
  and \f(CW\*(C`!$omp\*(C'\fR in Fortran.  Other OpenMP directives are ignored.
! .IP "\fB\-fopenmp\-target\-simd\-clone\fR" 4
  .IX Item "-fopenmp-target-simd-clone"
  .PD 0
! .IP "\fB\-fopenmp\-target\-simd\-clone=\fR\fIdevice-type\fR" 4
  .IX Item "-fopenmp-target-simd-clone=device-type"
  .PD
! In addition to generating \s-1SIMD\s0 clones for functions marked with the
! \&\f(CW\*(C`declare simd\*(C'\fR directive, \s-1GCC\s0 also generates clones
  for functions marked with the OpenMP \f(CW\*(C`declare target\*(C'\fR directive
  that are suitable for vectorization when this option is in effect.  The
! \&\fIdevice-type\fR may be one of \f(CW\*(C`none\*(C'\fR, \f(CW\*(C`host\*(C'\fR, \f(CW\*(C`nohost\*(C'\fR,
  and \f(CW\*(C`any\*(C'\fR, which correspond to keywords for the \f(CW\*(C`device_type\*(C'\fR
  clause of the \f(CW\*(C`declare target\*(C'\fR directive; clones are generated for
  the intersection of devices specified.
--- 2682,2730 ----
  \&        \-foffload\-options="\-lgfortran \-lm" \-foffload\-options=nvptx\-none=\-latomic
  \&        \-foffload\-options=amdgcn\-amdhsa=\-march=gfx906 \-foffload\-options=\-lm
  .Ve
! .IP \fB\-fopenacc\fR 4
  .IX Item "-fopenacc"
! Enable handling of OpenACC directives \f(CW\*(C`#pragma acc\*(C'\fR in C/C++ and
  \&\f(CW\*(C`!$acc\*(C'\fR in Fortran.  When \fB\-fopenacc\fR is specified, the
  compiler generates accelerated code according to the OpenACC Application
  Programming Interface v2.6 <\fBhttps://www.openacc.org\fR>.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets that
  have support for \fB\-pthread\fR.
! .IP \fB\-fopenacc\-dim=\fR\fIgeom\fR 4
  .IX Item "-fopenacc-dim=geom"
  Specify default compute dimensions for parallel offload regions that do
  not explicitly specify.  The \fIgeom\fR value is a triple of
! \&\*(Aq:\*(Aq\-separated sizes, in order \*(Aqgang\*(Aq, \*(Aqworker\*(Aq and, \*(Aqvector\*(Aq.  A size
! can be omitted, to use a target\-specific default value.
! .IP \fB\-fopenmp\fR 4
  .IX Item "-fopenmp"
! Enable handling of OpenMP directives \f(CW\*(C`#pragma omp\*(C'\fR in C/C++,
! \&\f(CW\*(C`[[omp::directive(...)]]\*(C'\fR and \f(CW\*(C`[[omp::sequence(...)]]\*(C'\fR in C++ and
  \&\f(CW\*(C`!$omp\*(C'\fR in Fortran.  When \fB\-fopenmp\fR is specified, the
  compiler generates parallel code according to the OpenMP Application
  Program Interface v4.5 <\fBhttps://www.openmp.org\fR>.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets that
  have support for \fB\-pthread\fR. \fB\-fopenmp\fR implies
  \&\fB\-fopenmp\-simd\fR.
! .IP \fB\-fopenmp\-simd\fR 4
  .IX Item "-fopenmp-simd"
! Enable handling of OpenMP\*(Aqs \f(CW\*(C`simd\*(C'\fR, \f(CW\*(C`declare simd\*(C'\fR,
  \&\f(CW\*(C`declare reduction\*(C'\fR, \f(CW\*(C`assume\*(C'\fR, \f(CW\*(C`ordered\*(C'\fR, \f(CW\*(C`scan\*(C'\fR,
  \&\f(CW\*(C`loop\*(C'\fR directives and combined or composite directives with
! \&\f(CW\*(C`simd\*(C'\fR as constituent with \f(CW\*(C`#pragma omp\*(C'\fR in C/C++,
! \&\f(CW\*(C`[[omp::directive(...)]]\*(C'\fR and \f(CW\*(C`[[omp::sequence(...)]]\*(C'\fR in C++
  and \f(CW\*(C`!$omp\*(C'\fR in Fortran.  Other OpenMP directives are ignored.
! .IP \fB\-fopenmp\-target\-simd\-clone\fR 4
  .IX Item "-fopenmp-target-simd-clone"
  .PD 0
! .IP \fB\-fopenmp\-target\-simd\-clone=\fR\fIdevice\-type\fR 4
  .IX Item "-fopenmp-target-simd-clone=device-type"
  .PD
! In addition to generating SIMD clones for functions marked with the
! \&\f(CW\*(C`declare simd\*(C'\fR directive, GCC also generates clones
  for functions marked with the OpenMP \f(CW\*(C`declare target\*(C'\fR directive
  that are suitable for vectorization when this option is in effect.  The
! \&\fIdevice\-type\fR may be one of \f(CW\*(C`none\*(C'\fR, \f(CW\*(C`host\*(C'\fR, \f(CW\*(C`nohost\*(C'\fR,
  and \f(CW\*(C`any\*(C'\fR, which correspond to keywords for the \f(CW\*(C`device_type\*(C'\fR
  clause of the \f(CW\*(C`declare target\*(C'\fR directive; clones are generated for
  the intersection of devices specified.
*************** the intersection of devices specified.
*** 2807,2815 ****
  At \fB\-O2\fR and higher (but not \fB\-Os\fR or \fB\-Og\fR) this
  optimization defaults to \fB\-fopenmp\-target\-simd\-clone=nohost\fR; otherwise
  it is disabled by default.
! .IP "\fB\-fpermitted\-flt\-eval\-methods=\fR\fIstyle\fR" 4
  .IX Item "-fpermitted-flt-eval-methods=style"
! \&\s-1ISO/IEC TS 18661\-3\s0 defines new permissible values for
  \&\f(CW\*(C`FLT_EVAL_METHOD\*(C'\fR that indicate that operations and constants with
  a semantic type that is an interchange or extended format should be
  evaluated to the precision and range of that type.  These new values are
--- 2736,2744 ----
  At \fB\-O2\fR and higher (but not \fB\-Os\fR or \fB\-Og\fR) this
  optimization defaults to \fB\-fopenmp\-target\-simd\-clone=nohost\fR; otherwise
  it is disabled by default.
! .IP \fB\-fpermitted\-flt\-eval\-methods=\fR\fIstyle\fR 4
  .IX Item "-fpermitted-flt-eval-methods=style"
! ISO/IEC TS 18661\-3 defines new permissible values for
  \&\f(CW\*(C`FLT_EVAL_METHOD\*(C'\fR that indicate that operations and constants with
  a semantic type that is an interchange or extended format should be
  evaluated to the precision and range of that type.  These new values are
*************** the new values.
*** 2820,2864 ****
  .Sp
  \&\fB\-fpermitted\-flt\-eval\-methods\fR specifies whether the compiler
  should allow only the values of \f(CW\*(C`FLT_EVAL_METHOD\*(C'\fR specified in C99/C11,
! or the extended set of values specified in \s-1ISO/IEC TS 18661\-3.\s0
  .Sp
  \&\fIstyle\fR is either \f(CW\*(C`c11\*(C'\fR or \f(CW\*(C`ts\-18661\-3\*(C'\fR as appropriate.
  .Sp
  The default when in a standards compliant mode (\fB\-std=c11\fR or similar)
! is \fB\-fpermitted\-flt\-eval\-methods=c11\fR.  The default when in a \s-1GNU\s0
  dialect (\fB\-std=gnu11\fR or similar) is
  \&\fB\-fpermitted\-flt\-eval\-methods=ts\-18661\-3\fR.
! .IP "\fB\-fplan9\-extensions\fR" 4
  .IX Item "-fplan9-extensions"
! Accept some non-standard constructs used in Plan 9 code.
  .Sp
  This enables \fB\-fms\-extensions\fR, permits passing pointers to
  structures with anonymous fields to functions that expect pointers to
  elements of the type of the field, and permits referring to anonymous
  fields declared using a typedef.    This is only
! supported for C, not \*(C+.
! .IP "\fB\-fsigned\-bitfields\fR" 4
  .IX Item "-fsigned-bitfields"
  .PD 0
! .IP "\fB\-funsigned\-bitfields\fR" 4
  .IX Item "-funsigned-bitfields"
! .IP "\fB\-fno\-signed\-bitfields\fR" 4
  .IX Item "-fno-signed-bitfields"
! .IP "\fB\-fno\-unsigned\-bitfields\fR" 4
  .IX Item "-fno-unsigned-bitfields"
  .PD
! These options control whether a bit-field is signed or unsigned, when the
  declaration does not use either \f(CW\*(C`signed\*(C'\fR or \f(CW\*(C`unsigned\*(C'\fR.  By
! default, such a bit-field is signed, because this is consistent: the
  basic integer types such as \f(CW\*(C`int\*(C'\fR are signed types.
! .IP "\fB\-fsigned\-char\fR" 4
  .IX Item "-fsigned-char"
  Let the type \f(CW\*(C`char\*(C'\fR be signed, like \f(CW\*(C`signed char\*(C'\fR.
  .Sp
  Note that this is equivalent to \fB\-fno\-unsigned\-char\fR, which is
  the negative form of \fB\-funsigned\-char\fR.  Likewise, the option
  \&\fB\-fno\-signed\-char\fR is equivalent to \fB\-funsigned\-char\fR.
! .IP "\fB\-funsigned\-char\fR" 4
  .IX Item "-funsigned-char"
  Let the type \f(CW\*(C`char\*(C'\fR be unsigned, like \f(CW\*(C`unsigned char\*(C'\fR.
  .Sp
--- 2749,2793 ----
  .Sp
  \&\fB\-fpermitted\-flt\-eval\-methods\fR specifies whether the compiler
  should allow only the values of \f(CW\*(C`FLT_EVAL_METHOD\*(C'\fR specified in C99/C11,
! or the extended set of values specified in ISO/IEC TS 18661\-3.
  .Sp
  \&\fIstyle\fR is either \f(CW\*(C`c11\*(C'\fR or \f(CW\*(C`ts\-18661\-3\*(C'\fR as appropriate.
  .Sp
  The default when in a standards compliant mode (\fB\-std=c11\fR or similar)
! is \fB\-fpermitted\-flt\-eval\-methods=c11\fR.  The default when in a GNU
  dialect (\fB\-std=gnu11\fR or similar) is
  \&\fB\-fpermitted\-flt\-eval\-methods=ts\-18661\-3\fR.
! .IP \fB\-fplan9\-extensions\fR 4
  .IX Item "-fplan9-extensions"
! Accept some non\-standard constructs used in Plan 9 code.
  .Sp
  This enables \fB\-fms\-extensions\fR, permits passing pointers to
  structures with anonymous fields to functions that expect pointers to
  elements of the type of the field, and permits referring to anonymous
  fields declared using a typedef.    This is only
! supported for C, not C++.
! .IP \fB\-fsigned\-bitfields\fR 4
  .IX Item "-fsigned-bitfields"
  .PD 0
! .IP \fB\-funsigned\-bitfields\fR 4
  .IX Item "-funsigned-bitfields"
! .IP \fB\-fno\-signed\-bitfields\fR 4
  .IX Item "-fno-signed-bitfields"
! .IP \fB\-fno\-unsigned\-bitfields\fR 4
  .IX Item "-fno-unsigned-bitfields"
  .PD
! These options control whether a bit\-field is signed or unsigned, when the
  declaration does not use either \f(CW\*(C`signed\*(C'\fR or \f(CW\*(C`unsigned\*(C'\fR.  By
! default, such a bit\-field is signed, because this is consistent: the
  basic integer types such as \f(CW\*(C`int\*(C'\fR are signed types.
! .IP \fB\-fsigned\-char\fR 4
  .IX Item "-fsigned-char"
  Let the type \f(CW\*(C`char\*(C'\fR be signed, like \f(CW\*(C`signed char\*(C'\fR.
  .Sp
  Note that this is equivalent to \fB\-fno\-unsigned\-char\fR, which is
  the negative form of \fB\-funsigned\-char\fR.  Likewise, the option
  \&\fB\-fno\-signed\-char\fR is equivalent to \fB\-funsigned\-char\fR.
! .IP \fB\-funsigned\-char\fR 4
  .IX Item "-funsigned-char"
  Let the type \f(CW\*(C`char\*(C'\fR be unsigned, like \f(CW\*(C`unsigned char\*(C'\fR.
  .Sp
*************** make such a program work with the opposi
*** 2876,2882 ****
  The type \f(CW\*(C`char\*(C'\fR is always a distinct type from each of
  \&\f(CW\*(C`signed char\*(C'\fR or \f(CW\*(C`unsigned char\*(C'\fR, even though its behavior
  is always just like one of those two.
! .IP "\fB\-fstrict\-flex\-arrays\fR" 4
  .IX Item "-fstrict-flex-arrays"
  Control when to treat the trailing array of a structure as a flexible array
  member for the purpose of accessing the elements of such an array.
--- 2805,2811 ----
  The type \f(CW\*(C`char\*(C'\fR is always a distinct type from each of
  \&\f(CW\*(C`signed char\*(C'\fR or \f(CW\*(C`unsigned char\*(C'\fR, even though its behavior
  is always just like one of those two.
! .IP \fB\-fstrict\-flex\-arrays\fR 4
  .IX Item "-fstrict-flex-arrays"
  Control when to treat the trailing array of a structure as a flexible array
  member for the purpose of accessing the elements of such an array.
*************** is declared as a flexible array member p
*** 2886,2892 ****
  The negative form is equivalent to \fB\-fstrict\-flex\-arrays=0\fR, which is the
  least strict.  All trailing arrays of structures are treated as flexible array
  members.
! .IP "\fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR" 4
  .IX Item "-fstrict-flex-arrays=level"
  Control when to treat the trailing array of a structure as a flexible array
  member for the purpose of accessing the elements of such an array.  The value
--- 2815,2821 ----
  The negative form is equivalent to \fB\-fstrict\-flex\-arrays=0\fR, which is the
  least strict.  All trailing arrays of structures are treated as flexible array
  members.
! .IP \fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR 4
  .IX Item "-fstrict-flex-arrays=level"
  Control when to treat the trailing array of a structure as a flexible array
  member for the purpose of accessing the elements of such an array.  The value
*************** The possible values of \fIlevel\fR are t
*** 2897,2916 ****
  .Sp
  You can control this behavior for a specific trailing array field of a
  structure by using the variable attribute \f(CW\*(C`strict_flex_array\*(C'\fR attribute.
! .IP "\fB\-fsso\-struct=\fR\fIendianness\fR" 4
  .IX Item "-fsso-struct=endianness"
  Set the default scalar storage order of structures and unions to the
! specified endianness.  The accepted values are \fBbig-endian\fR,
! \&\fBlittle-endian\fR and \fBnative\fR for the native endianness of
! the target (the default).  This option is not supported for \*(C+.
  .Sp
! \&\fBWarning:\fR the \fB\-fsso\-struct\fR switch causes \s-1GCC\s0 to generate
  code that is not binary compatible with code generated without it if the
  specified endianness is not the native endianness of the target.
! .SS "Options Controlling \*(C+ Dialect"
! .IX Subsection "Options Controlling Dialect"
! This section describes the command-line options that are only meaningful
! for \*(C+ programs.  You can also use most of the \s-1GNU\s0 compiler options
  regardless of what language your program is in.  For example, you
  might compile a file \fIfirstClass.C\fR like this:
  .PP
--- 2826,2845 ----
  .Sp
  You can control this behavior for a specific trailing array field of a
  structure by using the variable attribute \f(CW\*(C`strict_flex_array\*(C'\fR attribute.
! .IP \fB\-fsso\-struct=\fR\fIendianness\fR 4
  .IX Item "-fsso-struct=endianness"
  Set the default scalar storage order of structures and unions to the
! specified endianness.  The accepted values are \fBbig\-endian\fR,
! \&\fBlittle\-endian\fR and \fBnative\fR for the native endianness of
! the target (the default).  This option is not supported for C++.
  .Sp
! \&\fBWarning:\fR the \fB\-fsso\-struct\fR switch causes GCC to generate
  code that is not binary compatible with code generated without it if the
  specified endianness is not the native endianness of the target.
! .SS "Options Controlling C++ Dialect"
! .IX Subsection "Options Controlling C++ Dialect"
! This section describes the command\-line options that are only meaningful
! for C++ programs.  You can also use most of the GNU compiler options
  regardless of what language your program is in.  For example, you
  might compile a file \fIfirstClass.C\fR like this:
  .PP
*************** might compile a file \fIfirstClass.C\fR
*** 2919,2942 ****
  .Ve
  .PP
  In this example, only \fB\-fstrict\-enums\fR is an option meant
! only for \*(C+ programs; you can use the other options with any
! language supported by \s-1GCC.\s0
  .PP
  Some options for compiling C programs, such as \fB\-std\fR, are also
! relevant for \*(C+ programs.
  .PP
! Here is a list of options that are \fIonly\fR for compiling \*(C+ programs:
! .IP "\fB\-fabi\-version=\fR\fIn\fR" 4
  .IX Item "-fabi-version=n"
! Use version \fIn\fR of the \*(C+ \s-1ABI.\s0  The default is version 0.
  .Sp
  Version 0 refers to the version conforming most closely to
! the \*(C+ \s-1ABI\s0 specification.  Therefore, the \s-1ABI\s0 obtained using version 0
! will change in different versions of G++ as \s-1ABI\s0 bugs are fixed.
  .Sp
! Version 1 is the version of the \*(C+ \s-1ABI\s0 that first appeared in G++ 3.2.
  .Sp
! Version 2 is the version of the \*(C+ \s-1ABI\s0 that first appeared in G++
  3.4, and was the default through G++ 4.9.
  .Sp
  Version 3 corrects an error in mangling a constant address as a
--- 2848,2871 ----
  .Ve
  .PP
  In this example, only \fB\-fstrict\-enums\fR is an option meant
! only for C++ programs; you can use the other options with any
! language supported by GCC.
  .PP
  Some options for compiling C programs, such as \fB\-std\fR, are also
! relevant for C++ programs.
  .PP
! Here is a list of options that are \fIonly\fR for compiling C++ programs:
! .IP \fB\-fabi\-version=\fR\fIn\fR 4
  .IX Item "-fabi-version=n"
! Use version \fIn\fR of the C++ ABI.  The default is version 0.
  .Sp
  Version 0 refers to the version conforming most closely to
! the C++ ABI specification.  Therefore, the ABI obtained using version 0
! will change in different versions of G++ as ABI bugs are fixed.
  .Sp
! Version 1 is the version of the C++ ABI that first appeared in G++ 3.2.
  .Sp
! Version 2 is the version of the C++ ABI that first appeared in G++
  3.4, and was the default through G++ 4.9.
  .Sp
  Version 3 corrects an error in mangling a constant address as a
*************** plain decl, and use of a function parame
*** 2951,2957 ****
  another parameter.
  .Sp
  Version 6, which first appeared in G++ 4.7, corrects the promotion
! behavior of \*(C+11 scoped enums and the mangling of template argument
  packs, const/static_cast, prefix ++ and \-\-, and a class scope function
  used as a template argument.
  .Sp
--- 2880,2886 ----
  another parameter.
  .Sp
  Version 6, which first appeared in G++ 4.7, corrects the promotion
! behavior of C++11 scoped enums and the mangling of template argument
  packs, const/static_cast, prefix ++ and \-\-, and a class scope function
  used as a template argument.
  .Sp
*************** builtin type and corrects the mangling o
*** 2960,2966 ****
  scope.
  .Sp
  Version 8, which first appeared in G++ 4.9, corrects the substitution
! behavior of function types with function-cv-qualifiers.
  .Sp
  Version 9, which first appeared in G++ 5.2, corrects the alignment of
  \&\f(CW\*(C`nullptr_t\*(C'\fR.
--- 2889,2895 ----
  scope.
  .Sp
  Version 8, which first appeared in G++ 4.9, corrects the substitution
! behavior of function types with function\-cv\-qualifiers.
  .Sp
  Version 9, which first appeared in G++ 5.2, corrects the alignment of
  \&\f(CW\*(C`nullptr_t\*(C'\fR.
*************** change in version 12.
*** 2987,2993 ****
  Version 14, which first appeared in G++ 10, corrects the mangling of
  the nullptr expression.
  .Sp
! Version 15, which first appeared in G++ 10.3, corrects G++ 10 \s-1ABI\s0
  tag regression.
  .Sp
  Version 16, which first appeared in G++ 11, changes the mangling of
--- 2916,2922 ----
  Version 14, which first appeared in G++ 10, corrects the mangling of
  the nullptr expression.
  .Sp
! Version 15, which first appeared in G++ 10.3, corrects G++ 10 ABI
  tag regression.
  .Sp
  Version 16, which first appeared in G++ 11, changes the mangling of
*************** dependent operator names.
*** 2996,3050 ****
  .Sp
  Version 17, which first appeared in G++ 12, fixes layout of classes
  that inherit from aggregate classes with default member initializers
! in \*(C+14 and up.
  .Sp
  Version 18, which first appeard in G++ 13, fixes manglings of lambdas
  that have additional context.
  .Sp
  See also \fB\-Wabi\fR.
! .IP "\fB\-fabi\-compat\-version=\fR\fIn\fR" 4
  .IX Item "-fabi-compat-version=n"
  On targets that support strong aliases, G++
  works around mangling changes by creating an alias with the correct
  mangled name when defining a symbol with an incorrect mangled name.
! This switch specifies which \s-1ABI\s0 version to use for the alias.
  .Sp
! With \fB\-fabi\-version=0\fR (the default), this defaults to 13 (\s-1GCC 8.2\s0
! compatibility).  If another \s-1ABI\s0 version is explicitly selected, this
! defaults to 0.  For compatibility with \s-1GCC\s0 versions 3.2 through 4.9,
  use \fB\-fabi\-compat\-version=2\fR.
  .Sp
  If this option is not provided but \fB\-Wabi=\fR\fIn\fR is, that
  version is used for compatibility aliases.  If this option is provided
  along with \fB\-Wabi\fR (without the version), the version from this
  option is used for the warning.
! .IP "\fB\-fno\-access\-control\fR" 4
  .IX Item "-fno-access-control"
  Turn off all access checking.  This switch is mainly useful for working
  around bugs in the access control code.
! .IP "\fB\-faligned\-new\fR" 4
  .IX Item "-faligned-new"
! Enable support for \*(C+17 \f(CW\*(C`new\*(C'\fR of types that require more
  alignment than \f(CW\*(C`void* ::operator new(std::size_t)\*(C'\fR provides.  A
  numeric argument such as \f(CW\*(C`\-faligned\-new=32\*(C'\fR can be used to
  specify how much alignment (in bytes) is provided by that function,
  but few users will need to override the default of
! \&\f(CW\*(C`alignof(std::max_align_t)\*(C'\fR.
  .Sp
  This flag is enabled by default for \fB\-std=c++17\fR.
! .IP "\fB\-fchar8_t\fR" 4
  .IX Item "-fchar8_t"
  .PD 0
! .IP "\fB\-fno\-char8_t\fR" 4
  .IX Item "-fno-char8_t"
  .PD
! Enable support for \f(CW\*(C`char8_t\*(C'\fR as adopted for \*(C+20.  This includes
  the addition of a new \f(CW\*(C`char8_t\*(C'\fR fundamental type, changes to the
! types of \s-1UTF\-8\s0 string and character literals, new signatures for
! user-defined literals, associated standard library updates, and new
  \&\f(CW\*(C`_\|_cpp_char8_t\*(C'\fR and \f(CW\*(C`_\|_cpp_lib_char8_t\*(C'\fR feature test macros.
  .Sp
! This option enables functions to be overloaded for ordinary and \s-1UTF\-8\s0
  strings:
  .Sp
  .Vb 4
--- 2925,2979 ----
  .Sp
  Version 17, which first appeared in G++ 12, fixes layout of classes
  that inherit from aggregate classes with default member initializers
! in C++14 and up.
  .Sp
  Version 18, which first appeard in G++ 13, fixes manglings of lambdas
  that have additional context.
  .Sp
  See also \fB\-Wabi\fR.
! .IP \fB\-fabi\-compat\-version=\fR\fIn\fR 4
  .IX Item "-fabi-compat-version=n"
  On targets that support strong aliases, G++
  works around mangling changes by creating an alias with the correct
  mangled name when defining a symbol with an incorrect mangled name.
! This switch specifies which ABI version to use for the alias.
  .Sp
! With \fB\-fabi\-version=0\fR (the default), this defaults to 13 (GCC 8.2
! compatibility).  If another ABI version is explicitly selected, this
! defaults to 0.  For compatibility with GCC versions 3.2 through 4.9,
  use \fB\-fabi\-compat\-version=2\fR.
  .Sp
  If this option is not provided but \fB\-Wabi=\fR\fIn\fR is, that
  version is used for compatibility aliases.  If this option is provided
  along with \fB\-Wabi\fR (without the version), the version from this
  option is used for the warning.
! .IP \fB\-fno\-access\-control\fR 4
  .IX Item "-fno-access-control"
  Turn off all access checking.  This switch is mainly useful for working
  around bugs in the access control code.
! .IP \fB\-faligned\-new\fR 4
  .IX Item "-faligned-new"
! Enable support for C++17 \f(CW\*(C`new\*(C'\fR of types that require more
  alignment than \f(CW\*(C`void* ::operator new(std::size_t)\*(C'\fR provides.  A
  numeric argument such as \f(CW\*(C`\-faligned\-new=32\*(C'\fR can be used to
  specify how much alignment (in bytes) is provided by that function,
  but few users will need to override the default of
! \&\f(CWalignof(std::max_align_t)\fR.
  .Sp
  This flag is enabled by default for \fB\-std=c++17\fR.
! .IP \fB\-fchar8_t\fR 4
  .IX Item "-fchar8_t"
  .PD 0
! .IP \fB\-fno\-char8_t\fR 4
  .IX Item "-fno-char8_t"
  .PD
! Enable support for \f(CW\*(C`char8_t\*(C'\fR as adopted for C++20.  This includes
  the addition of a new \f(CW\*(C`char8_t\*(C'\fR fundamental type, changes to the
! types of UTF\-8 string and character literals, new signatures for
! user\-defined literals, associated standard library updates, and new
  \&\f(CW\*(C`_\|_cpp_char8_t\*(C'\fR and \f(CW\*(C`_\|_cpp_lib_char8_t\*(C'\fR feature test macros.
  .Sp
! This option enables functions to be overloaded for ordinary and UTF\-8
  strings:
  .Sp
  .Vb 4
*************** strings:
*** 3054,3060 ****
  \&        int v2 = f(u8"text");   // Calls #2
  .Ve
  .Sp
! and introduces new signatures for user-defined literals:
  .Sp
  .Vb 6
  \&        int operator""_udl1(char8_t);
--- 2983,2989 ----
  \&        int v2 = f(u8"text");   // Calls #2
  .Ve
  .Sp
! and introduces new signatures for user\-defined literals:
  .Sp
  .Vb 6
  \&        int operator""_udl1(char8_t);
*************** and introduces new signatures for user-d
*** 3065,3073 ****
  \&        int v5 = u8"text"_udl3;
  .Ve
  .Sp
! The change to the types of \s-1UTF\-8\s0 string and character literals introduces
! incompatibilities with \s-1ISO \*(C+11\s0 and later standards.  For example, the
! following code is well-formed under \s-1ISO \*(C+11,\s0 but is ill-formed when
  \&\fB\-fchar8_t\fR is specified.
  .Sp
  .Vb 11
--- 2994,3002 ----
  \&        int v5 = u8"text"_udl3;
  .Ve
  .Sp
! The change to the types of UTF\-8 string and character literals introduces
! incompatibilities with ISO C++11 and later standards.  For example, the
! following code is well\-formed under ISO C++11, but is ill\-formed when
  \&\fB\-fchar8_t\fR is specified.
  .Sp
  .Vb 11
*************** following code is well-formed under \s-1
*** 3083,3122 ****
  \&                                //        \`basic_string\*(Aq to non\-scalar
  \&                                //        type \`basic_string\*(Aq requested
  .Ve
! .IP "\fB\-fcheck\-new\fR" 4
  .IX Item "-fcheck-new"
! Check that the pointer returned by \f(CW\*(C`operator new\*(C'\fR is non-null
  before attempting to modify the storage allocated.  This check is
! normally unnecessary because the \*(C+ standard specifies that
  \&\f(CW\*(C`operator new\*(C'\fR only returns \f(CW0\fR if it is declared
! \&\f(CW\*(C`throw()\*(C'\fR, in which case the compiler always checks the
  return value even without this option.  In all other cases, when
! \&\f(CW\*(C`operator new\*(C'\fR has a non-empty exception specification, memory
  exhaustion is signalled by throwing \f(CW\*(C`std::bad_alloc\*(C'\fR.  See also
  \&\fBnew (nothrow)\fR.
! .IP "\fB\-fconcepts\fR" 4
  .IX Item "-fconcepts"
  .PD 0
! .IP "\fB\-fconcepts\-ts\fR" 4
  .IX Item "-fconcepts-ts"
  .PD
! Enable support for the \*(C+ Concepts feature for constraining template
  arguments.  With \fB\-std=c++20\fR and above, Concepts are part of
  the language standard, so \fB\-fconcepts\fR defaults to on.
  .Sp
! Some constructs that were allowed by the earlier \*(C+ Extensions for
! Concepts Technical Specification, \s-1ISO 19217\s0 (2015), but didn't make it
  into the standard, can additionally be enabled by
  \&\fB\-fconcepts\-ts\fR.
! .IP "\fB\-fconstexpr\-depth=\fR\fIn\fR" 4
  .IX Item "-fconstexpr-depth=n"
! Set the maximum nested evaluation depth for \*(C+11 constexpr functions
  to \fIn\fR.  A limit is needed to detect endless recursion during
  constant expression evaluation.  The minimum specified by the standard
  is 512.
! .IP "\fB\-fconstexpr\-cache\-depth=\fR\fIn\fR" 4
  .IX Item "-fconstexpr-cache-depth=n"
! Set the maximum level of nested evaluation depth for \*(C+11 constexpr
  functions that will be cached to \fIn\fR.  This is a heuristic that
  trades off compilation speed (when the cache avoids repeated
  calculations) against memory consumption (when the cache grows very
--- 3012,3051 ----
  \&                                //        \`basic_string\*(Aq to non\-scalar
  \&                                //        type \`basic_string\*(Aq requested
  .Ve
! .IP \fB\-fcheck\-new\fR 4
  .IX Item "-fcheck-new"
! Check that the pointer returned by \f(CW\*(C`operator new\*(C'\fR is non\-null
  before attempting to modify the storage allocated.  This check is
! normally unnecessary because the C++ standard specifies that
  \&\f(CW\*(C`operator new\*(C'\fR only returns \f(CW0\fR if it is declared
! \&\f(CWthrow()\fR, in which case the compiler always checks the
  return value even without this option.  In all other cases, when
! \&\f(CW\*(C`operator new\*(C'\fR has a non\-empty exception specification, memory
  exhaustion is signalled by throwing \f(CW\*(C`std::bad_alloc\*(C'\fR.  See also
  \&\fBnew (nothrow)\fR.
! .IP \fB\-fconcepts\fR 4
  .IX Item "-fconcepts"
  .PD 0
! .IP \fB\-fconcepts\-ts\fR 4
  .IX Item "-fconcepts-ts"
  .PD
! Enable support for the C++ Concepts feature for constraining template
  arguments.  With \fB\-std=c++20\fR and above, Concepts are part of
  the language standard, so \fB\-fconcepts\fR defaults to on.
  .Sp
! Some constructs that were allowed by the earlier C++ Extensions for
! Concepts Technical Specification, ISO 19217 (2015), but didn\*(Aqt make it
  into the standard, can additionally be enabled by
  \&\fB\-fconcepts\-ts\fR.
! .IP \fB\-fconstexpr\-depth=\fR\fIn\fR 4
  .IX Item "-fconstexpr-depth=n"
! Set the maximum nested evaluation depth for C++11 constexpr functions
  to \fIn\fR.  A limit is needed to detect endless recursion during
  constant expression evaluation.  The minimum specified by the standard
  is 512.
! .IP \fB\-fconstexpr\-cache\-depth=\fR\fIn\fR 4
  .IX Item "-fconstexpr-cache-depth=n"
! Set the maximum level of nested evaluation depth for C++11 constexpr
  functions that will be cached to \fIn\fR.  This is a heuristic that
  trades off compilation speed (when the cache avoids repeated
  calculations) against memory consumption (when the cache grows very
*************** large from highly recursive evaluations)
*** 3124,3135 ****
  users are likely to want to adjust it, but if your code does heavy
  constexpr calculations you might want to experiment to find which
  value works best for you.
! .IP "\fB\-fconstexpr\-fp\-except\fR" 4
  .IX Item "-fconstexpr-fp-except"
! Annex F of the C standard specifies that \s-1IEC559\s0 floating point
  exceptions encountered at compile time should not stop compilation.
! \&\*(C+ compilers have historically not followed this guidance, instead
! treating floating point division by zero as non-constant even though
  it has a well defined value.  This flag tells the compiler to give
  Annex F priority over other rules saying that a particular operation
  is undefined.
--- 3053,3064 ----
  users are likely to want to adjust it, but if your code does heavy
  constexpr calculations you might want to experiment to find which
  value works best for you.
! .IP \fB\-fconstexpr\-fp\-except\fR 4
  .IX Item "-fconstexpr-fp-except"
! Annex F of the C standard specifies that IEC559 floating point
  exceptions encountered at compile time should not stop compilation.
! C++ compilers have historically not followed this guidance, instead
! treating floating point division by zero as non\-constant even though
  it has a well defined value.  This flag tells the compiler to give
  Annex F priority over other rules saying that a particular operation
  is undefined.
*************** is undefined.
*** 3137,3148 ****
  .Vb 1
  \&        constexpr float inf = 1./0.; // OK with \-fconstexpr\-fp\-except
  .Ve
! .IP "\fB\-fconstexpr\-loop\-limit=\fR\fIn\fR" 4
  .IX Item "-fconstexpr-loop-limit=n"
! Set the maximum number of iterations for a loop in \*(C+14 constexpr functions
  to \fIn\fR.  A limit is needed to detect infinite loops during
  constant expression evaluation.  The default is 262144 (1<<18).
! .IP "\fB\-fconstexpr\-ops\-limit=\fR\fIn\fR" 4
  .IX Item "-fconstexpr-ops-limit=n"
  Set the maximum number of operations during a single constexpr evaluation.
  Even when number of iterations of a single loop is limited with the above limit,
--- 3066,3077 ----
  .Vb 1
  \&        constexpr float inf = 1./0.; // OK with \-fconstexpr\-fp\-except
  .Ve
! .IP \fB\-fconstexpr\-loop\-limit=\fR\fIn\fR 4
  .IX Item "-fconstexpr-loop-limit=n"
! Set the maximum number of iterations for a loop in C++14 constexpr functions
  to \fIn\fR.  A limit is needed to detect infinite loops during
  constant expression evaluation.  The default is 262144 (1<<18).
! .IP \fB\-fconstexpr\-ops\-limit=\fR\fIn\fR 4
  .IX Item "-fconstexpr-ops-limit=n"
  Set the maximum number of operations during a single constexpr evaluation.
  Even when number of iterations of a single loop is limited with the above limit,
*************** smaller than the above limit, or if in a
*** 3151,3164 ****
  of a loop too many expressions need to be evaluated, the resulting constexpr
  evaluation might take too long.
  The default is 33554432 (1<<25).
! .IP "\fB\-fcontracts\fR" 4
  .IX Item "-fcontracts"
! Enable experimental support for the \*(C+ Contracts feature, as briefly
! added to and then removed from the \*(C+20 working paper (N4820).  The
  implementation also includes proposed enhancements from papers P1290,
  P1332, and P1429.  This functionality is intended mostly for those
  interested in experimentation towards refining the feature to get it
! into shape for a future \*(C+ standard.
  .Sp
  On violation of a checked contract, the violation handler is called.
  Users can replace the violation handler by defining
--- 3080,3093 ----
  of a loop too many expressions need to be evaluated, the resulting constexpr
  evaluation might take too long.
  The default is 33554432 (1<<25).
! .IP \fB\-fcontracts\fR 4
  .IX Item "-fcontracts"
! Enable experimental support for the C++ Contracts feature, as briefly
! added to and then removed from the C++20 working paper (N4820).  The
  implementation also includes proposed enhancements from papers P1290,
  P1332, and P1429.  This functionality is intended mostly for those
  interested in experimentation towards refining the feature to get it
! into shape for a future C++ standard.
  .Sp
  On violation of a checked contract, the violation handler is called.
  Users can replace the violation handler by defining
*************** to specify which contracts will be check
*** 3173,3204 ****
  contracts, P1332 contracts, or P1429 contracts; these sets cannot be
  used together.
  .RS 4
! .IP "\fB\-fcontract\-mode=[on|off]\fR" 4
  .IX Item "-fcontract-mode=[on|off]"
  Control whether any contracts have any semantics at all.  Defaults to on.
! .IP "\fB\-fcontract\-assumption\-mode=[on|off]\fR" 4
  .IX Item "-fcontract-assumption-mode=[on|off]"
  [N4820] Control whether contracts with level \fBaxiom\fR
  should have the assume semantic.  Defaults to on.
! .IP "\fB\-fcontract\-build\-level=[off|default|audit]\fR" 4
  .IX Item "-fcontract-build-level=[off|default|audit]"
  [N4820] Specify which level of contracts to generate checks
  for.  Defaults to \fBdefault\fR.
! .IP "\fB\-fcontract\-continuation\-mode=[on|off]\fR" 4
  .IX Item "-fcontract-continuation-mode=[on|off]"
  [N4820] Control whether to allow the program to continue executing
  after a contract violation.  That is, do checked contracts have the
  \&\fBmaybe\fR semantic described below rather than the \fBnever\fR
  semantic.  Defaults to off.
! .IP "\fB\-fcontract\-role=:,,\fR" 4
  .IX Item "-fcontract-role=:,,"
  [P1332] Specify the concrete semantics for each contract level
  of a particular contract role.
! .IP "\fB\-fcontract\-semantic=[default|audit|axiom]:\fR" 4
  .IX Item "-fcontract-semantic=[default|audit|axiom]:"
  [P1429] Specify the concrete semantic for a particular
  contract level.
! .IP "\fB\-fcontract\-strict\-declarations=[on|off]\fR" 4
  .IX Item "-fcontract-strict-declarations=[on|off]"
  Control whether to reject adding contracts to a function after its
  first declaration.  Defaults to off.
--- 3102,3133 ----
  contracts, P1332 contracts, or P1429 contracts; these sets cannot be
  used together.
  .RS 4
! .IP \fB\-fcontract\-mode=[on|off]\fR 4
  .IX Item "-fcontract-mode=[on|off]"
  Control whether any contracts have any semantics at all.  Defaults to on.
! .IP \fB\-fcontract\-assumption\-mode=[on|off]\fR 4
  .IX Item "-fcontract-assumption-mode=[on|off]"
  [N4820] Control whether contracts with level \fBaxiom\fR
  should have the assume semantic.  Defaults to on.
! .IP \fB\-fcontract\-build\-level=[off|default|audit]\fR 4
  .IX Item "-fcontract-build-level=[off|default|audit]"
  [N4820] Specify which level of contracts to generate checks
  for.  Defaults to \fBdefault\fR.
! .IP \fB\-fcontract\-continuation\-mode=[on|off]\fR 4
  .IX Item "-fcontract-continuation-mode=[on|off]"
  [N4820] Control whether to allow the program to continue executing
  after a contract violation.  That is, do checked contracts have the
  \&\fBmaybe\fR semantic described below rather than the \fBnever\fR
  semantic.  Defaults to off.
! .IP \fB\-fcontract\-role=:,,\fR 4
  .IX Item "-fcontract-role=:,,"
  [P1332] Specify the concrete semantics for each contract level
  of a particular contract role.
! .IP \fB\-fcontract\-semantic=[default|audit|axiom]:\fR 4
  .IX Item "-fcontract-semantic=[default|audit|axiom]:"
  [P1429] Specify the concrete semantic for a particular
  contract level.
! .IP \fB\-fcontract\-strict\-declarations=[on|off]\fR 4
  .IX Item "-fcontract-strict-declarations=[on|off]"
  Control whether to reject adding contracts to a function after its
  first declaration.  Defaults to off.
*************** first declaration.  Defaults to off.
*** 3208,3239 ****
  The possible concrete semantics for that can be specified with
  \&\fB\-fcontract\-role\fR or \fB\-fcontract\-semantic\fR are:
  .ie n .IP """ignore""" 4
! .el .IP "\f(CWignore\fR" 4
  .IX Item "ignore"
  This contract has no effect.
  .ie n .IP """assume""" 4
! .el .IP "\f(CWassume\fR" 4
  .IX Item "assume"
! This contract is treated like \*(C+23 \f(CW\*(C`[[assume]]\*(C'\fR.
  .ie n .IP """check_never_continue""" 4
! .el .IP "\f(CWcheck_never_continue\fR" 4
  .IX Item "check_never_continue"
  .PD 0
  .ie n .IP """never""" 4
! .el .IP "\f(CWnever\fR" 4
  .IX Item "never"
  .ie n .IP """abort""" 4
! .el .IP "\f(CWabort\fR" 4
  .IX Item "abort"
  .PD
  This contract is checked.  If it fails, the violation handler is
  called.  If the handler returns, \f(CW\*(C`std::terminate\*(C'\fR is called.
  .ie n .IP """check_maybe_continue""" 4
! .el .IP "\f(CWcheck_maybe_continue\fR" 4
  .IX Item "check_maybe_continue"
  .PD 0
  .ie n .IP """maybe""" 4
! .el .IP "\f(CWmaybe\fR" 4
  .IX Item "maybe"
  .PD
  This contract is checked.  If it fails, the violation handler is
--- 3137,3168 ----
  The possible concrete semantics for that can be specified with
  \&\fB\-fcontract\-role\fR or \fB\-fcontract\-semantic\fR are:
  .ie n .IP """ignore""" 4
! .el .IP \f(CWignore\fR 4
  .IX Item "ignore"
  This contract has no effect.
  .ie n .IP """assume""" 4
! .el .IP \f(CWassume\fR 4
  .IX Item "assume"
! This contract is treated like C++23 \f(CW\*(C`[[assume]]\*(C'\fR.
  .ie n .IP """check_never_continue""" 4
! .el .IP \f(CWcheck_never_continue\fR 4
  .IX Item "check_never_continue"
  .PD 0
  .ie n .IP """never""" 4
! .el .IP \f(CWnever\fR 4
  .IX Item "never"
  .ie n .IP """abort""" 4
! .el .IP \f(CWabort\fR 4
  .IX Item "abort"
  .PD
  This contract is checked.  If it fails, the violation handler is
  called.  If the handler returns, \f(CW\*(C`std::terminate\*(C'\fR is called.
  .ie n .IP """check_maybe_continue""" 4
! .el .IP \f(CWcheck_maybe_continue\fR 4
  .IX Item "check_maybe_continue"
  .PD 0
  .ie n .IP """maybe""" 4
! .el .IP \f(CWmaybe\fR 4
  .IX Item "maybe"
  .PD
  This contract is checked.  If it fails, the violation handler is
*************** called.  If the handler returns, executi
*** 3241,3529 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-fcoroutines\fR" 4
  .IX Item "-fcoroutines"
! Enable support for the \*(C+ coroutines extension (experimental).
! .IP "\fB\-fno\-elide\-constructors\fR" 4
  .IX Item "-fno-elide-constructors"
! The \*(C+ standard allows an implementation to omit creating a temporary
  that is only used to initialize another object of the same type.
  Specifying this option disables that optimization, and forces G++ to
  call the copy constructor in all cases.  This option also causes G++
  to call trivial member functions which otherwise would be expanded inline.
  .Sp
! In \*(C+17, the compiler is required to omit these temporaries, but this
  option still affects trivial member functions.
! .IP "\fB\-fno\-enforce\-eh\-specs\fR" 4
  .IX Item "-fno-enforce-eh-specs"
! Don't generate code to check for violation of exception specifications
! at run time.  This option violates the \*(C+ standard, but may be useful
  for reducing code size in production builds, much like defining
  \&\f(CW\*(C`NDEBUG\*(C'\fR.  This does not give user code permission to throw
  exceptions in violation of the exception specifications; the compiler
  still optimizes based on the specifications, so throwing an
  unexpected exception results in undefined behavior at run time.
! .IP "\fB\-fextern\-tls\-init\fR" 4
  .IX Item "-fextern-tls-init"
  .PD 0
! .IP "\fB\-fno\-extern\-tls\-init\fR" 4
  .IX Item "-fno-extern-tls-init"
  .PD
! The \*(C+11 and OpenMP standards allow \f(CW\*(C`thread_local\*(C'\fR and
  \&\f(CW\*(C`threadprivate\*(C'\fR variables to have dynamic (runtime)
  initialization.  To support this, any use of such a variable goes
  through a wrapper function that performs any necessary initialization.
  When the use and definition of the variable are in the same
  translation unit, this overhead can be optimized away, but when the
  use is in a different translation unit there is significant overhead
! even if the variable doesn't actually need dynamic initialization.  If
  the programmer can be sure that no use of the variable in a
! non-defining \s-1TU\s0 needs to trigger dynamic initialization (either
  because the variable is statically initialized, or a use of the
! variable in the defining \s-1TU\s0 will be executed before any uses in
! another \s-1TU\s0), they can avoid this overhead with the
  \&\fB\-fno\-extern\-tls\-init\fR option.
  .Sp
  On targets that support symbol aliases, the default is
  \&\fB\-fextern\-tls\-init\fR.  On targets that do not support symbol
  aliases, the default is \fB\-fno\-extern\-tls\-init\fR.
! .IP "\fB\-ffold\-simple\-inlines\fR" 4
  .IX Item "-ffold-simple-inlines"
  .PD 0
! .IP "\fB\-fno\-fold\-simple\-inlines\fR" 4
  .IX Item "-fno-fold-simple-inlines"
  .PD
! Permit the \*(C+ frontend to fold calls to \f(CW\*(C`std::move\*(C'\fR, \f(CW\*(C`std::forward\*(C'\fR,
  \&\f(CW\*(C`std::addressof\*(C'\fR and \f(CW\*(C`std::as_const\*(C'\fR.  In contrast to inlining, this
  means no debug information will be generated for such calls.  Since these
  functions are rarely interesting to debug, this flag is enabled by default
  unless \fB\-fno\-inline\fR is active.
! .IP "\fB\-fno\-gnu\-keywords\fR" 4
  .IX Item "-fno-gnu-keywords"
  Do not recognize \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use this
  word as an identifier.  You can use the keyword \f(CW\*(C`_\|_typeof_\|_\*(C'\fR instead.
! This option is implied by the strict \s-1ISO \*(C+\s0 dialects: \fB\-ansi\fR,
  \&\fB\-std=c++98\fR, \fB\-std=c++11\fR, etc.
! .IP "\fB\-fimplicit\-constexpr\fR" 4
  .IX Item "-fimplicit-constexpr"
  Make inline functions implicitly constexpr, if they satisfy the
  requirements for a constexpr function.  This option can be used in
! \&\*(C+14 mode or later.  This can result in initialization changing from
  dynamic to static and other optimizations.
! .IP "\fB\-fno\-implicit\-templates\fR" 4
  .IX Item "-fno-implicit-templates"
! Never emit code for non-inline templates that are instantiated
  implicitly (i.e. by use); only emit code for explicit instantiations.
  If you use this option, you must take care to structure your code to
  include all the necessary explicit instantiations to avoid getting
  undefined symbols at link time.
! .IP "\fB\-fno\-implicit\-inline\-templates\fR" 4
  .IX Item "-fno-implicit-inline-templates"
! Don't emit code for implicit instantiations of inline templates, either.
  The default is to handle inlines differently so that compiles with and
  without optimization need the same set of explicit instantiations.
! .IP "\fB\-fno\-implement\-inlines\fR" 4
  .IX Item "-fno-implement-inlines"
! To save space, do not emit out-of-line copies of inline functions
  controlled by \f(CW\*(C`#pragma implementation\*(C'\fR.  This causes linker
  errors if these functions are not inlined everywhere they are called.
! .IP "\fB\-fmodules\-ts\fR" 4
  .IX Item "-fmodules-ts"
  .PD 0
! .IP "\fB\-fno\-modules\-ts\fR" 4
  .IX Item "-fno-modules-ts"
  .PD
! Enable support for \*(C+20 modules.  The
  \&\fB\-fno\-modules\-ts\fR is usually not needed, as that is the
! default.  Even though this is a \*(C+20 feature, it is not currently
  implicitly enabled by selecting that standard version.
! .IP "\fB\-fmodule\-header\fR" 4
  .IX Item "-fmodule-header"
  .PD 0
! .IP "\fB\-fmodule\-header=user\fR" 4
  .IX Item "-fmodule-header=user"
! .IP "\fB\-fmodule\-header=system\fR" 4
  .IX Item "-fmodule-header=system"
  .PD
  Compile a header file to create an importable header unit.
! .IP "\fB\-fmodule\-implicit\-inline\fR" 4
  .IX Item "-fmodule-implicit-inline"
  Member functions defined in their class definitions are not implicitly
! inline for modular code.  This is different to traditional \*(C+
  behavior, for good reasons.  However, it may result in a difficulty
  during code porting.  This option makes such function definitions
! implicitly inline.  It does however generate an \s-1ABI\s0 incompatibility,
  so you must use it everywhere or nowhere.  (Such definitions outside
  of a named module remain implicitly inline, regardless.)
! .IP "\fB\-fno\-module\-lazy\fR" 4
  .IX Item "-fno-module-lazy"
  Disable lazy module importing and module mapper creation.
! .IP "\fB\-fmodule\-mapper=\fR[\fIhostname\fR]\fB:\fR\fIport\fR[\fB?\fR\fIident\fR]" 4
  .IX Item "-fmodule-mapper=[hostname]:port[?ident]"
  .PD 0
  .IP "\fB\-fmodule\-mapper=|\fR\fIprogram\fR[\fB?\fR\fIident\fR]\fB \fR\fIargs...\fR" 4
  .IX Item "-fmodule-mapper=|program[?ident] args..."
! .IP "\fB\-fmodule\-mapper==\fR\fIsocket\fR[\fB?\fR\fIident\fR]" 4
  .IX Item "-fmodule-mapper==socket[?ident]"
! .IP "\fB\-fmodule\-mapper=<>\fR[\fIinout\fR][\fB?\fR\fIident\fR]" 4
  .IX Item "-fmodule-mapper=<>[inout][?ident]"
! .IP "\fB\-fmodule\-mapper=<\fR\fIin\fR\fB>\fR\fIout\fR[\fB?\fR\fIident\fR]" 4
  .IX Item "-fmodule-mapper=out[?ident]"
! .IP "\fB\-fmodule\-mapper=\fR\fIfile\fR[\fB?\fR\fIident\fR]" 4
  .IX Item "-fmodule-mapper=file[?ident]"
  .PD
  An oracle to query for module name to filename mappings.  If
! unspecified the \fB\s-1CXX_MODULE_MAPPER\s0\fR environment variable is used,
! and if that is unset, an in-process default is provided.
! .IP "\fB\-fmodule\-only\fR" 4
  .IX Item "-fmodule-only"
  Only emit the Compiled Module Interface, inhibiting any object file.
! .IP "\fB\-fms\-extensions\fR" 4
  .IX Item "-fms-extensions"
! Disable Wpedantic warnings about constructs used in \s-1MFC,\s0 such as implicit
! int and getting a pointer to member function via non-standard syntax.
! .IP "\fB\-fnew\-inheriting\-ctors\fR" 4
  .IX Item "-fnew-inheriting-ctors"
! Enable the P0136 adjustment to the semantics of \*(C+11 constructor
! inheritance.  This is part of \*(C+17 but also considered to be a Defect
! Report against \*(C+11 and \*(C+14.  This flag is enabled by default
  unless \fB\-fabi\-version=10\fR or lower is specified.
! .IP "\fB\-fnew\-ttp\-matching\fR" 4
  .IX Item "-fnew-ttp-matching"
  Enable the P0522 resolution to Core issue 150, template template
  parameters and default arguments: this allows a template with default
  template arguments as an argument for a template template parameter
  with fewer template parameters.  This flag is enabled by default for
  \&\fB\-std=c++17\fR.
! .IP "\fB\-fno\-nonansi\-builtins\fR" 4
  .IX Item "-fno-nonansi-builtins"
! Disable built-in declarations of functions that are not mandated by
! \&\s-1ANSI/ISO C.\s0  These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR,
  \&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions.
! .IP "\fB\-fnothrow\-opt\fR" 4
  .IX Item "-fnothrow-opt"
! Treat a \f(CW\*(C`throw()\*(C'\fR exception specification as if it were a
  \&\f(CW\*(C`noexcept\*(C'\fR specification to reduce or eliminate the text size
  overhead relative to a function with no exception specification.  If
! the function has local variables of types with non-trivial
  destructors, the exception specification actually makes the
! function smaller because the \s-1EH\s0 cleanups for those variables can be
  optimized away.  The semantic effect is that an exception thrown out of
  a function with such an exception specification results in a call
  to \f(CW\*(C`terminate\*(C'\fR rather than \f(CW\*(C`unexpected\*(C'\fR.
! .IP "\fB\-fno\-operator\-names\fR" 4
  .IX Item "-fno-operator-names"
  Do not treat the operator name keywords \f(CW\*(C`and\*(C'\fR, \f(CW\*(C`bitand\*(C'\fR,
  \&\f(CW\*(C`bitor\*(C'\fR, \f(CW\*(C`compl\*(C'\fR, \f(CW\*(C`not\*(C'\fR, \f(CW\*(C`or\*(C'\fR and \f(CW\*(C`xor\*(C'\fR as
  synonyms as keywords.
! .IP "\fB\-fno\-optional\-diags\fR" 4
  .IX Item "-fno-optional-diags"
  Disable diagnostics that the standard says a compiler does not need to
  issue.  Currently, the only such diagnostic issued by G++ is the one for
  a name having multiple meanings within a class.
! .IP "\fB\-fpermissive\fR" 4
  .IX Item "-fpermissive"
  Downgrade some diagnostics about nonconformant code from errors to
  warnings.  Thus, using \fB\-fpermissive\fR allows some
  nonconforming code to compile.
! .IP "\fB\-fno\-pretty\-templates\fR" 4
  .IX Item "-fno-pretty-templates"
  When an error message refers to a specialization of a function
  template, the compiler normally prints the signature of the
  template followed by the template arguments and any typedefs or
  typenames in the signature (e.g. \f(CW\*(C`void f(T) [with T = int]\*(C'\fR
! rather than \f(CW\*(C`void f(int)\*(C'\fR) so that it's clear which template is
  involved.  When an error message refers to a specialization of a class
  template, the compiler omits any template arguments that match
  the default template arguments for that template.  If either of these
  behaviors make it harder to understand the error message rather than
  easier, you can use \fB\-fno\-pretty\-templates\fR to disable them.
! .IP "\fB\-fno\-rtti\fR" 4
  .IX Item "-fno-rtti"
  Disable generation of information about every class with virtual
! functions for use by the \*(C+ run-time type identification features
! (\f(CW\*(C`dynamic_cast\*(C'\fR and \f(CW\*(C`typeid\*(C'\fR).  If you don't use those parts
  of the language, you can save some space by using this flag.  Note that
  exception handling uses the same information, but G++ generates it as
  needed. The \f(CW\*(C`dynamic_cast\*(C'\fR operator can still be used for casts that
! do not require run-time type information, i.e. casts to \f(CW\*(C`void *\*(C'\fR or to
  unambiguous base classes.
  .Sp
  Mixing code compiled with \fB\-frtti\fR with that compiled with
  \&\fB\-fno\-rtti\fR may not work.  For example, programs may
  fail to link if a class compiled with \fB\-fno\-rtti\fR is used as a base 
  for a class compiled with \fB\-frtti\fR.
! .IP "\fB\-fsized\-deallocation\fR" 4
  .IX Item "-fsized-deallocation"
! Enable the built-in global declarations
  .Sp
  .Vb 2
  \&        void operator delete (void *, std::size_t) noexcept;
  \&        void operator delete[] (void *, std::size_t) noexcept;
  .Ve
  .Sp
! as introduced in \*(C+14.  This is useful for user-defined replacement
  deallocation functions that, for example, use the size of the object
  to make deallocation faster.  Enabled by default under
  \&\fB\-std=c++14\fR and above.  The flag \fB\-Wsized\-deallocation\fR
  warns about places that might want to add a definition.
! .IP "\fB\-fstrict\-enums\fR" 4
  .IX Item "-fstrict-enums"
  Allow the compiler to optimize using the assumption that a value of
  enumerated type can only be one of the values of the enumeration (as
! defined in the \*(C+ standard; basically, a value that can be
  represented in the minimum number of bits needed to represent all the
  enumerators).  This assumption may not be valid if the program uses a
  cast to convert an arbitrary integer value to the enumerated type.
! .IP "\fB\-fstrong\-eval\-order\fR" 4
  .IX Item "-fstrong-eval-order"
  Evaluate member access, array subscripting, and shift expressions in
! left-to-right order, and evaluate assignment in right-to-left order,
! as adopted for \*(C+17.  Enabled by default with \fB\-std=c++17\fR.
  \&\fB\-fstrong\-eval\-order=some\fR enables just the ordering of member
  access and shift expressions, and is the default without
  \&\fB\-std=c++17\fR.
! .IP "\fB\-ftemplate\-backtrace\-limit=\fR\fIn\fR" 4
  .IX Item "-ftemplate-backtrace-limit=n"
  Set the maximum number of template instantiation notes for a single
  warning or error to \fIn\fR.  The default value is 10.
! .IP "\fB\-ftemplate\-depth=\fR\fIn\fR" 4
  .IX Item "-ftemplate-depth=n"
  Set the maximum instantiation depth for template classes to \fIn\fR.
  A limit on the template instantiation depth is needed to detect
! endless recursions during template class instantiation.  \s-1ANSI/ISO \*(C+\s0
  conforming programs must not rely on a maximum depth greater than 17
! (changed to 1024 in \*(C+11).  The default value is 900, as the compiler
  can run out of stack space before hitting 1024 in some situations.
! .IP "\fB\-fno\-threadsafe\-statics\fR" 4
  .IX Item "-fno-threadsafe-statics"
! Do not emit the extra code to use the routines specified in the \*(C+
! \&\s-1ABI\s0 for thread-safe initialization of local statics.  You can use this
! option to reduce code size slightly in code that doesn't need to be
! thread-safe.
! .IP "\fB\-fuse\-cxa\-atexit\fR" 4
  .IX Item "-fuse-cxa-atexit"
  Register destructors for objects with static storage duration with the
  \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR function rather than the \f(CW\*(C`atexit\*(C'\fR function.
! This option is required for fully standards-compliant handling of static
  destructors, but only works if your C library supports
  \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR.
! .IP "\fB\-fno\-use\-cxa\-get\-exception\-ptr\fR" 4
  .IX Item "-fno-use-cxa-get-exception-ptr"
! Don't use the \f(CW\*(C`_\|_cxa_get_exception_ptr\*(C'\fR runtime routine.  This
  causes \f(CW\*(C`std::uncaught_exception\*(C'\fR to be incorrect, but is necessary
  if the runtime routine is not available.
! .IP "\fB\-fvisibility\-inlines\-hidden\fR" 4
  .IX Item "-fvisibility-inlines-hidden"
  This switch declares that the user does not attempt to compare
  pointers to inline functions or methods where the addresses of the two functions
  are taken in different shared objects.
  .Sp
! The effect of this is that \s-1GCC\s0 may, effectively, mark inline methods with
  \&\f(CW\*(C`_\|_attribute_\|_ ((visibility ("hidden")))\*(C'\fR so that they do not
! appear in the export table of a \s-1DSO\s0 and do not require a \s-1PLT\s0 indirection
! when used within the \s-1DSO.\s0  Enabling this option can have a dramatic effect
! on load and link times of a \s-1DSO\s0 as it massively reduces the size of the
  dynamic export table when the library makes heavy use of templates.
  .Sp
  The behavior of this switch is not quite the same as marking the
--- 3170,3458 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-fcoroutines\fR 4
  .IX Item "-fcoroutines"
! Enable support for the C++ coroutines extension (experimental).
! .IP \fB\-fno\-elide\-constructors\fR 4
  .IX Item "-fno-elide-constructors"
! The C++ standard allows an implementation to omit creating a temporary
  that is only used to initialize another object of the same type.
  Specifying this option disables that optimization, and forces G++ to
  call the copy constructor in all cases.  This option also causes G++
  to call trivial member functions which otherwise would be expanded inline.
  .Sp
! In C++17, the compiler is required to omit these temporaries, but this
  option still affects trivial member functions.
! .IP \fB\-fno\-enforce\-eh\-specs\fR 4
  .IX Item "-fno-enforce-eh-specs"
! Don\*(Aqt generate code to check for violation of exception specifications
! at run time.  This option violates the C++ standard, but may be useful
  for reducing code size in production builds, much like defining
  \&\f(CW\*(C`NDEBUG\*(C'\fR.  This does not give user code permission to throw
  exceptions in violation of the exception specifications; the compiler
  still optimizes based on the specifications, so throwing an
  unexpected exception results in undefined behavior at run time.
! .IP \fB\-fextern\-tls\-init\fR 4
  .IX Item "-fextern-tls-init"
  .PD 0
! .IP \fB\-fno\-extern\-tls\-init\fR 4
  .IX Item "-fno-extern-tls-init"
  .PD
! The C++11 and OpenMP standards allow \f(CW\*(C`thread_local\*(C'\fR and
  \&\f(CW\*(C`threadprivate\*(C'\fR variables to have dynamic (runtime)
  initialization.  To support this, any use of such a variable goes
  through a wrapper function that performs any necessary initialization.
  When the use and definition of the variable are in the same
  translation unit, this overhead can be optimized away, but when the
  use is in a different translation unit there is significant overhead
! even if the variable doesn\*(Aqt actually need dynamic initialization.  If
  the programmer can be sure that no use of the variable in a
! non\-defining TU needs to trigger dynamic initialization (either
  because the variable is statically initialized, or a use of the
! variable in the defining TU will be executed before any uses in
! another TU), they can avoid this overhead with the
  \&\fB\-fno\-extern\-tls\-init\fR option.
  .Sp
  On targets that support symbol aliases, the default is
  \&\fB\-fextern\-tls\-init\fR.  On targets that do not support symbol
  aliases, the default is \fB\-fno\-extern\-tls\-init\fR.
! .IP \fB\-ffold\-simple\-inlines\fR 4
  .IX Item "-ffold-simple-inlines"
  .PD 0
! .IP \fB\-fno\-fold\-simple\-inlines\fR 4
  .IX Item "-fno-fold-simple-inlines"
  .PD
! Permit the C++ frontend to fold calls to \f(CW\*(C`std::move\*(C'\fR, \f(CW\*(C`std::forward\*(C'\fR,
  \&\f(CW\*(C`std::addressof\*(C'\fR and \f(CW\*(C`std::as_const\*(C'\fR.  In contrast to inlining, this
  means no debug information will be generated for such calls.  Since these
  functions are rarely interesting to debug, this flag is enabled by default
  unless \fB\-fno\-inline\fR is active.
! .IP \fB\-fno\-gnu\-keywords\fR 4
  .IX Item "-fno-gnu-keywords"
  Do not recognize \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use this
  word as an identifier.  You can use the keyword \f(CW\*(C`_\|_typeof_\|_\*(C'\fR instead.
! This option is implied by the strict ISO C++ dialects: \fB\-ansi\fR,
  \&\fB\-std=c++98\fR, \fB\-std=c++11\fR, etc.
! .IP \fB\-fimplicit\-constexpr\fR 4
  .IX Item "-fimplicit-constexpr"
  Make inline functions implicitly constexpr, if they satisfy the
  requirements for a constexpr function.  This option can be used in
! C++14 mode or later.  This can result in initialization changing from
  dynamic to static and other optimizations.
! .IP \fB\-fno\-implicit\-templates\fR 4
  .IX Item "-fno-implicit-templates"
! Never emit code for non\-inline templates that are instantiated
  implicitly (i.e. by use); only emit code for explicit instantiations.
  If you use this option, you must take care to structure your code to
  include all the necessary explicit instantiations to avoid getting
  undefined symbols at link time.
! .IP \fB\-fno\-implicit\-inline\-templates\fR 4
  .IX Item "-fno-implicit-inline-templates"
! Don\*(Aqt emit code for implicit instantiations of inline templates, either.
  The default is to handle inlines differently so that compiles with and
  without optimization need the same set of explicit instantiations.
! .IP \fB\-fno\-implement\-inlines\fR 4
  .IX Item "-fno-implement-inlines"
! To save space, do not emit out\-of\-line copies of inline functions
  controlled by \f(CW\*(C`#pragma implementation\*(C'\fR.  This causes linker
  errors if these functions are not inlined everywhere they are called.
! .IP \fB\-fmodules\-ts\fR 4
  .IX Item "-fmodules-ts"
  .PD 0
! .IP \fB\-fno\-modules\-ts\fR 4
  .IX Item "-fno-modules-ts"
  .PD
! Enable support for C++20 modules.  The
  \&\fB\-fno\-modules\-ts\fR is usually not needed, as that is the
! default.  Even though this is a C++20 feature, it is not currently
  implicitly enabled by selecting that standard version.
! .IP \fB\-fmodule\-header\fR 4
  .IX Item "-fmodule-header"
  .PD 0
! .IP \fB\-fmodule\-header=user\fR 4
  .IX Item "-fmodule-header=user"
! .IP \fB\-fmodule\-header=system\fR 4
  .IX Item "-fmodule-header=system"
  .PD
  Compile a header file to create an importable header unit.
! .IP \fB\-fmodule\-implicit\-inline\fR 4
  .IX Item "-fmodule-implicit-inline"
  Member functions defined in their class definitions are not implicitly
! inline for modular code.  This is different to traditional C++
  behavior, for good reasons.  However, it may result in a difficulty
  during code porting.  This option makes such function definitions
! implicitly inline.  It does however generate an ABI incompatibility,
  so you must use it everywhere or nowhere.  (Such definitions outside
  of a named module remain implicitly inline, regardless.)
! .IP \fB\-fno\-module\-lazy\fR 4
  .IX Item "-fno-module-lazy"
  Disable lazy module importing and module mapper creation.
! .IP \fB\-fmodule\-mapper=\fR[\fIhostname\fR]\fB:\fR\fIport\fR[\fB?\fR\fIident\fR] 4
  .IX Item "-fmodule-mapper=[hostname]:port[?ident]"
  .PD 0
  .IP "\fB\-fmodule\-mapper=|\fR\fIprogram\fR[\fB?\fR\fIident\fR]\fB \fR\fIargs...\fR" 4
  .IX Item "-fmodule-mapper=|program[?ident] args..."
! .IP \fB\-fmodule\-mapper==\fR\fIsocket\fR[\fB?\fR\fIident\fR] 4
  .IX Item "-fmodule-mapper==socket[?ident]"
! .IP \fB\-fmodule\-mapper=<>\fR[\fIinout\fR][\fB?\fR\fIident\fR] 4
  .IX Item "-fmodule-mapper=<>[inout][?ident]"
! .IP \fB\-fmodule\-mapper=<\fR\fIin\fR\fB>\fR\fIout\fR[\fB?\fR\fIident\fR] 4
  .IX Item "-fmodule-mapper=out[?ident]"
! .IP \fB\-fmodule\-mapper=\fR\fIfile\fR[\fB?\fR\fIident\fR] 4
  .IX Item "-fmodule-mapper=file[?ident]"
  .PD
  An oracle to query for module name to filename mappings.  If
! unspecified the \fBCXX_MODULE_MAPPER\fR environment variable is used,
! and if that is unset, an in\-process default is provided.
! .IP \fB\-fmodule\-only\fR 4
  .IX Item "-fmodule-only"
  Only emit the Compiled Module Interface, inhibiting any object file.
! .IP \fB\-fms\-extensions\fR 4
  .IX Item "-fms-extensions"
! Disable Wpedantic warnings about constructs used in MFC, such as implicit
! int and getting a pointer to member function via non\-standard syntax.
! .IP \fB\-fnew\-inheriting\-ctors\fR 4
  .IX Item "-fnew-inheriting-ctors"
! Enable the P0136 adjustment to the semantics of C++11 constructor
! inheritance.  This is part of C++17 but also considered to be a Defect
! Report against C++11 and C++14.  This flag is enabled by default
  unless \fB\-fabi\-version=10\fR or lower is specified.
! .IP \fB\-fnew\-ttp\-matching\fR 4
  .IX Item "-fnew-ttp-matching"
  Enable the P0522 resolution to Core issue 150, template template
  parameters and default arguments: this allows a template with default
  template arguments as an argument for a template template parameter
  with fewer template parameters.  This flag is enabled by default for
  \&\fB\-std=c++17\fR.
! .IP \fB\-fno\-nonansi\-builtins\fR 4
  .IX Item "-fno-nonansi-builtins"
! Disable built\-in declarations of functions that are not mandated by
! ANSI/ISO C.  These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR,
  \&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions.
! .IP \fB\-fnothrow\-opt\fR 4
  .IX Item "-fnothrow-opt"
! Treat a \f(CWthrow()\fR exception specification as if it were a
  \&\f(CW\*(C`noexcept\*(C'\fR specification to reduce or eliminate the text size
  overhead relative to a function with no exception specification.  If
! the function has local variables of types with non\-trivial
  destructors, the exception specification actually makes the
! function smaller because the EH cleanups for those variables can be
  optimized away.  The semantic effect is that an exception thrown out of
  a function with such an exception specification results in a call
  to \f(CW\*(C`terminate\*(C'\fR rather than \f(CW\*(C`unexpected\*(C'\fR.
! .IP \fB\-fno\-operator\-names\fR 4
  .IX Item "-fno-operator-names"
  Do not treat the operator name keywords \f(CW\*(C`and\*(C'\fR, \f(CW\*(C`bitand\*(C'\fR,
  \&\f(CW\*(C`bitor\*(C'\fR, \f(CW\*(C`compl\*(C'\fR, \f(CW\*(C`not\*(C'\fR, \f(CW\*(C`or\*(C'\fR and \f(CW\*(C`xor\*(C'\fR as
  synonyms as keywords.
! .IP \fB\-fno\-optional\-diags\fR 4
  .IX Item "-fno-optional-diags"
  Disable diagnostics that the standard says a compiler does not need to
  issue.  Currently, the only such diagnostic issued by G++ is the one for
  a name having multiple meanings within a class.
! .IP \fB\-fpermissive\fR 4
  .IX Item "-fpermissive"
  Downgrade some diagnostics about nonconformant code from errors to
  warnings.  Thus, using \fB\-fpermissive\fR allows some
  nonconforming code to compile.
! .IP \fB\-fno\-pretty\-templates\fR 4
  .IX Item "-fno-pretty-templates"
  When an error message refers to a specialization of a function
  template, the compiler normally prints the signature of the
  template followed by the template arguments and any typedefs or
  typenames in the signature (e.g. \f(CW\*(C`void f(T) [with T = int]\*(C'\fR
! rather than \f(CW\*(C`void f(int)\*(C'\fR) so that it\*(Aqs clear which template is
  involved.  When an error message refers to a specialization of a class
  template, the compiler omits any template arguments that match
  the default template arguments for that template.  If either of these
  behaviors make it harder to understand the error message rather than
  easier, you can use \fB\-fno\-pretty\-templates\fR to disable them.
! .IP \fB\-fno\-rtti\fR 4
  .IX Item "-fno-rtti"
  Disable generation of information about every class with virtual
! functions for use by the C++ run\-time type identification features
! (\f(CW\*(C`dynamic_cast\*(C'\fR and \f(CW\*(C`typeid\*(C'\fR).  If you don\*(Aqt use those parts
  of the language, you can save some space by using this flag.  Note that
  exception handling uses the same information, but G++ generates it as
  needed. The \f(CW\*(C`dynamic_cast\*(C'\fR operator can still be used for casts that
! do not require run\-time type information, i.e. casts to \f(CW\*(C`void *\*(C'\fR or to
  unambiguous base classes.
  .Sp
  Mixing code compiled with \fB\-frtti\fR with that compiled with
  \&\fB\-fno\-rtti\fR may not work.  For example, programs may
  fail to link if a class compiled with \fB\-fno\-rtti\fR is used as a base 
  for a class compiled with \fB\-frtti\fR.
! .IP \fB\-fsized\-deallocation\fR 4
  .IX Item "-fsized-deallocation"
! Enable the built\-in global declarations
  .Sp
  .Vb 2
  \&        void operator delete (void *, std::size_t) noexcept;
  \&        void operator delete[] (void *, std::size_t) noexcept;
  .Ve
  .Sp
! as introduced in C++14.  This is useful for user\-defined replacement
  deallocation functions that, for example, use the size of the object
  to make deallocation faster.  Enabled by default under
  \&\fB\-std=c++14\fR and above.  The flag \fB\-Wsized\-deallocation\fR
  warns about places that might want to add a definition.
! .IP \fB\-fstrict\-enums\fR 4
  .IX Item "-fstrict-enums"
  Allow the compiler to optimize using the assumption that a value of
  enumerated type can only be one of the values of the enumeration (as
! defined in the C++ standard; basically, a value that can be
  represented in the minimum number of bits needed to represent all the
  enumerators).  This assumption may not be valid if the program uses a
  cast to convert an arbitrary integer value to the enumerated type.
! .IP \fB\-fstrong\-eval\-order\fR 4
  .IX Item "-fstrong-eval-order"
  Evaluate member access, array subscripting, and shift expressions in
! left\-to\-right order, and evaluate assignment in right\-to\-left order,
! as adopted for C++17.  Enabled by default with \fB\-std=c++17\fR.
  \&\fB\-fstrong\-eval\-order=some\fR enables just the ordering of member
  access and shift expressions, and is the default without
  \&\fB\-std=c++17\fR.
! .IP \fB\-ftemplate\-backtrace\-limit=\fR\fIn\fR 4
  .IX Item "-ftemplate-backtrace-limit=n"
  Set the maximum number of template instantiation notes for a single
  warning or error to \fIn\fR.  The default value is 10.
! .IP \fB\-ftemplate\-depth=\fR\fIn\fR 4
  .IX Item "-ftemplate-depth=n"
  Set the maximum instantiation depth for template classes to \fIn\fR.
  A limit on the template instantiation depth is needed to detect
! endless recursions during template class instantiation.  ANSI/ISO C++
  conforming programs must not rely on a maximum depth greater than 17
! (changed to 1024 in C++11).  The default value is 900, as the compiler
  can run out of stack space before hitting 1024 in some situations.
! .IP \fB\-fno\-threadsafe\-statics\fR 4
  .IX Item "-fno-threadsafe-statics"
! Do not emit the extra code to use the routines specified in the C++
! ABI for thread\-safe initialization of local statics.  You can use this
! option to reduce code size slightly in code that doesn\*(Aqt need to be
! thread\-safe.
! .IP \fB\-fuse\-cxa\-atexit\fR 4
  .IX Item "-fuse-cxa-atexit"
  Register destructors for objects with static storage duration with the
  \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR function rather than the \f(CW\*(C`atexit\*(C'\fR function.
! This option is required for fully standards\-compliant handling of static
  destructors, but only works if your C library supports
  \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR.
! .IP \fB\-fno\-use\-cxa\-get\-exception\-ptr\fR 4
  .IX Item "-fno-use-cxa-get-exception-ptr"
! Don\*(Aqt use the \f(CW\*(C`_\|_cxa_get_exception_ptr\*(C'\fR runtime routine.  This
  causes \f(CW\*(C`std::uncaught_exception\*(C'\fR to be incorrect, but is necessary
  if the runtime routine is not available.
! .IP \fB\-fvisibility\-inlines\-hidden\fR 4
  .IX Item "-fvisibility-inlines-hidden"
  This switch declares that the user does not attempt to compare
  pointers to inline functions or methods where the addresses of the two functions
  are taken in different shared objects.
  .Sp
! The effect of this is that GCC may, effectively, mark inline methods with
  \&\f(CW\*(C`_\|_attribute_\|_ ((visibility ("hidden")))\*(C'\fR so that they do not
! appear in the export table of a 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.
  .Sp
  The behavior of this switch is not quite the same as marking the
*************** visibility has no effect.
*** 3539,3559 ****
  .Sp
  Explicitly instantiated inline methods are unaffected by this option
  as their linkage might otherwise cross a shared library boundary.
! .IP "\fB\-fvisibility\-ms\-compat\fR" 4
  .IX Item "-fvisibility-ms-compat"
! This flag attempts to use visibility settings to make \s-1GCC\s0's \*(C+
  linkage model compatible with that of Microsoft Visual Studio.
  .Sp
! The flag makes these changes to \s-1GCC\s0's linkage model:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  It sets the default visibility to \f(CW\*(C`hidden\*(C'\fR, like
  \&\fB\-fvisibility=hidden\fR.
! .IP "2." 4
  .IX Item "2."
  Types, but not their members, are not hidden by default.
! .IP "3." 4
  .IX Item "3."
  The One Definition Rule is relaxed for types without explicit
  visibility specifications that are defined in more than one
--- 3468,3488 ----
  .Sp
  Explicitly instantiated inline methods are unaffected by this option
  as their linkage might otherwise cross a shared library boundary.
! .IP \fB\-fvisibility\-ms\-compat\fR 4
  .IX Item "-fvisibility-ms-compat"
! This flag attempts to use visibility settings to make GCC\*(Aqs C++
  linkage model compatible with that of Microsoft Visual Studio.
  .Sp
! The flag makes these changes to GCC\*(Aqs linkage model:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  It sets the default visibility to \f(CW\*(C`hidden\*(C'\fR, like
  \&\fB\-fvisibility=hidden\fR.
! .IP 2. 4
  .IX Item "2."
  Types, but not their members, are not hidden by default.
! .IP 3. 4
  .IX Item "3."
  The One Definition Rule is relaxed for types without explicit
  visibility specifications that are defined in more than one
*************** of the same type with the same name but
*** 3572,3608 ****
  objects are different, so changing one does not change the other;
  and that pointers to function members defined in different shared
  objects may not compare equal.  When this flag is given, it is a
! violation of the \s-1ODR\s0 to define types with the same name differently.
  .RE
! .IP "\fB\-fno\-weak\fR" 4
  .IX Item "-fno-weak"
  Do not use weak symbol support, even if it is provided by the linker.
  By default, G++ uses weak symbols if they are available.  This
! option exists only for testing, and should not be used by end-users;
  it results in inferior code and has no benefits.  This option may
  be removed in a future release of G++.
! .IP "\fB\-fext\-numeric\-literals\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-fext-numeric-literals ( and Objective- only)"
! Accept imaginary, fixed-point, or machine-defined
! literal number suffixes as \s-1GNU\s0 extensions.
  When this option is turned off these suffixes are treated
! as \*(C+11 user-defined literal numeric suffixes.
! This is on by default for all pre\-\*(C+11 dialects and all \s-1GNU\s0 dialects:
  \&\fB\-std=c++98\fR, \fB\-std=gnu++98\fR, \fB\-std=gnu++11\fR,
  \&\fB\-std=gnu++14\fR.
  This option is off by default
! for \s-1ISO \*(C+11\s0 onwards (\fB\-std=c++11\fR, ...).
! .IP "\fB\-nostdinc++\fR" 4
  .IX Item "-nostdinc++"
  Do not search for header files in the standard directories specific to
! \&\*(C+, but do still search the other standard directories.  (This option
! is used when building the \*(C+ library.)
! .IP "\fB\-flang\-info\-include\-translate\fR" 4
  .IX Item "-flang-info-include-translate"
  .PD 0
! .IP "\fB\-flang\-info\-include\-translate\-not\fR" 4
  .IX Item "-flang-info-include-translate-not"
! .IP "\fB\-flang\-info\-include\-translate=\fR\fIheader\fR" 4
  .IX Item "-flang-info-include-translate=header"
  .PD
  Inform of include translation events.  The first will note accepted
--- 3501,3537 ----
  objects are different, so changing one does not change the other;
  and that pointers to function members defined in different shared
  objects may not compare equal.  When this flag is given, it is a
! violation of the ODR to define types with the same name differently.
  .RE
! .IP \fB\-fno\-weak\fR 4
  .IX Item "-fno-weak"
  Do not use weak symbol support, even if it is provided by the linker.
  By default, G++ uses weak symbols if they are available.  This
! option exists only for testing, and should not be used by end\-users;
  it results in inferior code and has no benefits.  This option may
  be removed in a future release of G++.
! .IP "\fB\-fext\-numeric\-literals\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-fext-numeric-literals (C++ and Objective-C++ only)"
! Accept imaginary, fixed\-point, or machine\-defined
! literal number suffixes as GNU extensions.
  When this option is turned off these suffixes are treated
! as C++11 user\-defined literal numeric suffixes.
! This is on by default for all pre\-C++11 dialects and all GNU dialects:
  \&\fB\-std=c++98\fR, \fB\-std=gnu++98\fR, \fB\-std=gnu++11\fR,
  \&\fB\-std=gnu++14\fR.
  This option is off by default
! for ISO C++11 onwards (\fB\-std=c++11\fR, ...).
! .IP \fB\-nostdinc++\fR 4
  .IX Item "-nostdinc++"
  Do not search for header files in the standard directories specific to
! C++, but do still search the other standard directories.  (This option
! is used when building the C++ library.)
! .IP \fB\-flang\-info\-include\-translate\fR 4
  .IX Item "-flang-info-include-translate"
  .PD 0
! .IP \fB\-flang\-info\-include\-translate\-not\fR 4
  .IX Item "-flang-info-include-translate-not"
! .IP \fB\-flang\-info\-include\-translate=\fR\fIheader\fR 4
  .IX Item "-flang-info-include-translate=header"
  .PD
  Inform of include translation events.  The first will note accepted
*************** translations.  The \fIheader\fR form wil
*** 3611,3647 ****
  translations relating to that specific header.  If \fIheader\fR is of
  the form \f(CW"user"\fR or \f(CW\*(C`\*(C'\fR it will be resolved to a
  specific user or system header using the include path.
! .IP "\fB\-flang\-info\-module\-cmi\fR" 4
  .IX Item "-flang-info-module-cmi"
  .PD 0
! .IP "\fB\-flang\-info\-module\-cmi=\fR\fImodule\fR" 4
  .IX Item "-flang-info-module-cmi=module"
  .PD
  Inform of Compiled Module Interface pathnames.  The first will note
! all read \s-1CMI\s0 pathnames.  The \fImodule\fR form will not reading a
! specific module's \s-1CMI.\s0  \fImodule\fR may be a named module or a
! header-unit (the latter indicated by either being a pathname containing
  directory separators or enclosed in \f(CW\*(C`<>\*(C'\fR or \f(CW""\fR).
! .IP "\fB\-stdlib=\fR\fIlibstdc++,libc++\fR" 4
  .IX Item "-stdlib=libstdc++,libc++"
  When G++ is configured to support this option, it allows specification of
! alternate \*(C+ runtime libraries.  Two options are available: \fIlibstdc++\fR
! (the default, native \*(C+ runtime for G++) and \fIlibc++\fR which is the
! \&\*(C+ runtime installed on some operating systems (e.g. Darwin versions from
  Darwin11 onwards).  The option switches G++ to use the headers from the
  specified library and to emit \f(CW\*(C`\-lstdc++\*(C'\fR or \f(CW\*(C`\-lc++\*(C'\fR respectively,
! when a \*(C+ runtime is required for linking.
  .PP
! In addition, these warning options have meanings only for \*(C+ programs:
! .IP "\fB\-Wabi\-tag\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wabi-tag ( and Objective- only)"
! Warn when a type with an \s-1ABI\s0 tag is used in a context that does not
! have that \s-1ABI\s0 tag.  See \fB\*(C+ Attributes\fR for more information
! about \s-1ABI\s0 tags.
! .IP "\fB\-Wcomma\-subscript\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wcomma-subscript ( and Objective- only)"
  Warn about uses of a comma expression within a subscripting expression.
! This usage was deprecated in \*(C+20 and is going to be removed in \*(C+23.
  However, a comma expression wrapped in \f(CW\*(C`( )\*(C'\fR is not deprecated.  Example:
  .Sp
  .Vb 4
--- 3540,3576 ----
  translations relating to that specific header.  If \fIheader\fR is of
  the form \f(CW"user"\fR or \f(CW\*(C`\*(C'\fR it will be resolved to a
  specific user or system header using the include path.
! .IP \fB\-flang\-info\-module\-cmi\fR 4
  .IX Item "-flang-info-module-cmi"
  .PD 0
! .IP \fB\-flang\-info\-module\-cmi=\fR\fImodule\fR 4
  .IX Item "-flang-info-module-cmi=module"
  .PD
  Inform of Compiled Module Interface pathnames.  The first will note
! all read CMI pathnames.  The \fImodule\fR form will not reading a
! specific module\*(Aqs CMI.  \fImodule\fR may be a named module or a
! header\-unit (the latter indicated by either being a pathname containing
  directory separators or enclosed in \f(CW\*(C`<>\*(C'\fR or \f(CW""\fR).
! .IP \fB\-stdlib=\fR\fIlibstdc++,libc++\fR 4
  .IX Item "-stdlib=libstdc++,libc++"
  When G++ is configured to support this option, it allows specification of
! alternate C++ runtime libraries.  Two options are available: \fIlibstdc++\fR
! (the default, native C++ runtime for G++) and \fIlibc++\fR which is the
! C++ runtime installed on some operating systems (e.g. Darwin versions from
  Darwin11 onwards).  The option switches G++ to use the headers from the
  specified library and to emit \f(CW\*(C`\-lstdc++\*(C'\fR or \f(CW\*(C`\-lc++\*(C'\fR respectively,
! when a C++ runtime is required for linking.
  .PP
! In addition, these warning options have meanings only for C++ programs:
! .IP "\fB\-Wabi\-tag\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wabi-tag (C++ and Objective-C++ only)"
! Warn when a type with an ABI tag is used in a context that does not
! have that ABI tag.  See \fBC++ Attributes\fR for more information
! about ABI tags.
! .IP "\fB\-Wcomma\-subscript\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wcomma-subscript (C++ and Objective-C++ only)"
  Warn about uses of a comma expression within a subscripting expression.
! This usage was deprecated in C++20 and is going to be removed in C++23.
  However, a comma expression wrapped in \f(CW\*(C`( )\*(C'\fR is not deprecated.  Example:
  .Sp
  .Vb 4
*************** However, a comma expression wrapped in \
*** 3651,3673 ****
  \&        }
  .Ve
  .Sp
! In \*(C+23 it is valid to have comma separated expressions in a subscript
  when an overloaded subscript operator is found and supports the right
  number and types of arguments.  G++ will accept the formerly valid syntax
! for code that is not valid in \*(C+23 but used to be valid but deprecated
! in \*(C+20 with a pedantic warning that can be disabled with
  \&\fB\-Wno\-comma\-subscript\fR.
  .Sp
  Enabled by default with \fB\-std=c++20\fR unless \fB\-Wno\-deprecated\fR,
  and with \fB\-std=c++23\fR regardless of \fB\-Wno\-deprecated\fR.
! .IP "\fB\-Wctad\-maybe\-unsupported\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wctad-maybe-unsupported ( and Objective- only)"
! Warn when performing class template argument deduction (\s-1CTAD\s0) on a type with
  no explicitly written deduction guides.  This warning will point out cases
! where \s-1CTAD\s0 succeeded only because the compiler synthesized the implicit
  deduction guides, which might not be what the programmer intended.  Certain
! style guides allow \s-1CTAD\s0 only on types that specifically \*(L"opt-in\*(R"; i.e., on
! types that are designed to support \s-1CTAD.\s0  This warning can be suppressed with
  the following pattern:
  .Sp
  .Vb 6
--- 3580,3602 ----
  \&        }
  .Ve
  .Sp
! In C++23 it is valid to have comma separated expressions in a subscript
  when an overloaded subscript operator is found and supports the right
  number and types of arguments.  G++ will accept the formerly valid syntax
! for code that is not valid in C++23 but used to be valid but deprecated
! in C++20 with a pedantic warning that can be disabled with
  \&\fB\-Wno\-comma\-subscript\fR.
  .Sp
  Enabled by default with \fB\-std=c++20\fR unless \fB\-Wno\-deprecated\fR,
  and with \fB\-std=c++23\fR regardless of \fB\-Wno\-deprecated\fR.
! .IP "\fB\-Wctad\-maybe\-unsupported\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wctad-maybe-unsupported (C++ and Objective-C++ only)"
! Warn when performing class template argument deduction (CTAD) on a type with
  no explicitly written deduction guides.  This warning will point out cases
! where CTAD succeeded only because the compiler synthesized the implicit
  deduction guides, which might not be what the programmer intended.  Certain
! style guides allow CTAD only on types that specifically "opt\-in"; i.e., on
! types that are designed to support CTAD.  This warning can be suppressed with
  the following pattern:
  .Sp
  .Vb 6
*************** the following pattern:
*** 3678,3692 ****
  \&        // Guide with incomplete parameter type will never be considered.
  \&        S(allow_ctad_t) \-> S;
  .Ve
! .IP "\fB\-Wctor\-dtor\-privacy\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wctor-dtor-privacy ( and Objective- only)"
  Warn when a class seems unusable because all the constructors or
  destructors in that class are private, and it has neither friends nor
! public static member functions.  Also warn if there are no non-private
! methods, and there's at least one private member function that isn't
  a constructor or destructor.
! .IP "\fB\-Wdangling\-reference\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wdangling-reference ( and Objective- only)"
  Warn when a reference is bound to a temporary whose lifetime has ended.
  For example:
  .Sp
--- 3607,3621 ----
  \&        // Guide with incomplete parameter type will never be considered.
  \&        S(allow_ctad_t) \-> S;
  .Ve
! .IP "\fB\-Wctor\-dtor\-privacy\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wctor-dtor-privacy (C++ and Objective-C++ only)"
  Warn when a class seems unusable because all the constructors or
  destructors in that class are private, and it has neither friends nor
! public static member functions.  Also warn if there are no non\-private
! methods, and there\*(Aqs at least one private member function that isn\*(Aqt
  a constructor or destructor.
! .IP "\fB\-Wdangling\-reference\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wdangling-reference (C++ and Objective-C++ only)"
  Warn when a reference is bound to a temporary whose lifetime has ended.
  For example:
  .Sp
*************** Member functions are checked as well, bu
*** 3719,3725 ****
  .Ve
  .Sp
  Certain functions are safe in this respect, for example \f(CW\*(C`std::use_facet\*(C'\fR:
! they take and return a reference, but they don't return one of its arguments,
  which can fool the warning.  Such functions can be excluded from the warning
  by wrapping them in a \f(CW\*(C`#pragma\*(C'\fR:
  .Sp
--- 3648,3654 ----
  .Ve
  .Sp
  Certain functions are safe in this respect, for example \f(CW\*(C`std::use_facet\*(C'\fR:
! they take and return a reference, but they don\*(Aqt return one of its arguments,
  which can fool the warning.  Such functions can be excluded from the warning
  by wrapping them in a \f(CW\*(C`#pragma\*(C'\fR:
  .Sp
*************** both references dangle after the end of
*** 3741,3766 ****
  the call to \f(CW\*(C`std::minmax\*(C'\fR.
  .Sp
  This warning is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wdelete\-non\-virtual\-dtor\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wdelete-non-virtual-dtor ( and Objective- only)"
  Warn when \f(CW\*(C`delete\*(C'\fR is used to destroy an instance of a class that
! has virtual functions and non-virtual destructor. It is unsafe to delete
  an instance of a derived class through a pointer to a base class if the
  base class does not have a virtual destructor.  This warning is enabled
  by \fB\-Wall\fR.
! .IP "\fB\-Wdeprecated\-copy\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wdeprecated-copy ( and Objective- only)"
  Warn that the implicit declaration of a copy constructor or copy
! assignment operator is deprecated if the class has a user-provided
! copy constructor or copy assignment operator, in \*(C+11 and up.  This
  warning is enabled by \fB\-Wextra\fR.  With
  \&\fB\-Wdeprecated\-copy\-dtor\fR, also deprecate if the class has a
! user-provided destructor.
! .IP "\fB\-Wno\-deprecated\-enum\-enum\-conversion\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-deprecated-enum-enum-conversion ( and Objective- only)"
  Disable the warning about the case when the usual arithmetic conversions
  are applied on operands where one is of enumeration type and the other is
! of a different enumeration type.  This conversion was deprecated in \*(C+20.
  For example:
  .Sp
  .Vb 3
--- 3670,3695 ----
  the call to \f(CW\*(C`std::minmax\*(C'\fR.
  .Sp
  This warning is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wdelete\-non\-virtual\-dtor\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wdelete-non-virtual-dtor (C++ and Objective-C++ only)"
  Warn when \f(CW\*(C`delete\*(C'\fR is used to destroy an instance of a class that
! has virtual functions and non\-virtual destructor. It is unsafe to delete
  an instance of a derived class through a pointer to a base class if the
  base class does not have a virtual destructor.  This warning is enabled
  by \fB\-Wall\fR.
! .IP "\fB\-Wdeprecated\-copy\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wdeprecated-copy (C++ and Objective-C++ only)"
  Warn that the implicit declaration of a copy constructor or copy
! assignment operator is deprecated if the class has a user\-provided
! copy constructor or copy assignment operator, in C++11 and up.  This
  warning is enabled by \fB\-Wextra\fR.  With
  \&\fB\-Wdeprecated\-copy\-dtor\fR, also deprecate if the class has a
! user\-provided destructor.
! .IP "\fB\-Wno\-deprecated\-enum\-enum\-conversion\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-deprecated-enum-enum-conversion (C++ and Objective-C++ only)"
  Disable the warning about the case when the usual arithmetic conversions
  are applied on operands where one is of enumeration type and the other is
! of a different enumeration type.  This conversion was deprecated in C++20.
  For example:
  .Sp
  .Vb 3
*************** For example:
*** 3770,3782 ****
  .Ve
  .Sp
  \&\fB\-Wdeprecated\-enum\-enum\-conversion\fR is enabled by default with
! \&\fB\-std=c++20\fR.  In pre\-\*(C+20 dialects, this warning can be enabled
  by \fB\-Wenum\-conversion\fR.
! .IP "\fB\-Wno\-deprecated\-enum\-float\-conversion\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-deprecated-enum-float-conversion ( and Objective- only)"
  Disable the warning about the case when the usual arithmetic conversions
  are applied on operands where one is of enumeration type and the other is
! of a floating-point type.  This conversion was deprecated in \*(C+20.  For
  example:
  .Sp
  .Vb 3
--- 3699,3711 ----
  .Ve
  .Sp
  \&\fB\-Wdeprecated\-enum\-enum\-conversion\fR is enabled by default with
! \&\fB\-std=c++20\fR.  In pre\-C++20 dialects, this warning can be enabled
  by \fB\-Wenum\-conversion\fR.
! .IP "\fB\-Wno\-deprecated\-enum\-float\-conversion\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-deprecated-enum-float-conversion (C++ and Objective-C++ only)"
  Disable the warning about the case when the usual arithmetic conversions
  are applied on operands where one is of enumeration type and the other is
! of a floating\-point type.  This conversion was deprecated in C++20.  For
  example:
  .Sp
  .Vb 3
*************** example:
*** 3786,3814 ****
  .Ve
  .Sp
  \&\fB\-Wdeprecated\-enum\-float\-conversion\fR is enabled by default with
! \&\fB\-std=c++20\fR.  In pre\-\*(C+20 dialects, this warning can be enabled
  by \fB\-Wenum\-conversion\fR.
! .IP "\fB\-Wno\-init\-list\-lifetime\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-init-list-lifetime ( and Objective- only)"
  Do not warn about uses of \f(CW\*(C`std::initializer_list\*(C'\fR that are likely
  to result in dangling pointers.  Since the underlying array for an
! \&\f(CW\*(C`initializer_list\*(C'\fR is handled like a normal \*(C+ temporary object,
  it is easy to inadvertently keep a pointer to the array past the end
! of the array's lifetime.  For example:
  .RS 4
! .IP "*" 4
  If a function returns a temporary \f(CW\*(C`initializer_list\*(C'\fR, or a local
! \&\f(CW\*(C`initializer_list\*(C'\fR variable, the array's lifetime ends at the end
  of the return statement, so the value returned has a dangling pointer.
! .IP "*" 4
! If a new-expression creates an \f(CW\*(C`initializer_list\*(C'\fR, the array only
! lives until the end of the enclosing full-expression, so the
  \&\f(CW\*(C`initializer_list\*(C'\fR in the heap has a dangling pointer.
! .IP "*" 4
  When an \f(CW\*(C`initializer_list\*(C'\fR variable is assigned from a
! brace-enclosed initializer list, the temporary array created for the
  right side of the assignment only lives until the end of the
! full-expression, so at the next statement the \f(CW\*(C`initializer_list\*(C'\fR
  variable has a dangling pointer.
  .Sp
  .Vb 6
--- 3715,3743 ----
  .Ve
  .Sp
  \&\fB\-Wdeprecated\-enum\-float\-conversion\fR is enabled by default with
! \&\fB\-std=c++20\fR.  In pre\-C++20 dialects, this warning can be enabled
  by \fB\-Wenum\-conversion\fR.
! .IP "\fB\-Wno\-init\-list\-lifetime\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-init-list-lifetime (C++ and Objective-C++ only)"
  Do not warn about uses of \f(CW\*(C`std::initializer_list\*(C'\fR that are likely
  to result in dangling pointers.  Since the underlying array for an
! \&\f(CW\*(C`initializer_list\*(C'\fR is handled like a normal C++ temporary object,
  it is easy to inadvertently keep a pointer to the array past the end
! of the array\*(Aqs lifetime.  For example:
  .RS 4
! .IP * 4
  If a function returns a temporary \f(CW\*(C`initializer_list\*(C'\fR, or a local
! \&\f(CW\*(C`initializer_list\*(C'\fR variable, the array\*(Aqs lifetime ends at the end
  of the return statement, so the value returned has a dangling pointer.
! .IP * 4
! If a new\-expression creates an \f(CW\*(C`initializer_list\*(C'\fR, the array only
! lives until the end of the enclosing full\-expression, so the
  \&\f(CW\*(C`initializer_list\*(C'\fR in the heap has a dangling pointer.
! .IP * 4
  When an \f(CW\*(C`initializer_list\*(C'\fR variable is assigned from a
! brace\-enclosed initializer list, the temporary array created for the
  right side of the assignment only lives until the end of the
! full\-expression, so at the next statement the \f(CW\*(C`initializer_list\*(C'\fR
  variable has a dangling pointer.
  .Sp
  .Vb 6
*************** variable has a dangling pointer.
*** 3819,3846 ****
  \&        // now the temporary is gone and li has a dangling pointer
  \&        int i = li.begin()[0] // undefined behavior
  .Ve
! .IP "*" 4
  When a list constructor stores the \f(CW\*(C`begin\*(C'\fR pointer from the
! \&\f(CW\*(C`initializer_list\*(C'\fR argument, this doesn't extend the lifetime of
  the array, so if a class variable is constructed from a temporary
  \&\f(CW\*(C`initializer_list\*(C'\fR, the pointer is left dangling by the end of
  the variable declaration statement.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Winvalid\-constexpr\fR" 4
  .IX Item "-Winvalid-constexpr"
! Warn when a function never produces a constant expression.  In \*(C+20
  and earlier, for every \f(CW\*(C`constexpr\*(C'\fR function and function template,
  there must be at least one set of function arguments in at least one
  instantiation such that an invocation of the function or constructor
  could be an evaluated subexpression of a core constant expression.
! \&\*(C+23 removed this restriction, so it's possible to have a function
  or a function template marked \f(CW\*(C`constexpr\*(C'\fR for which no invocation
  satisfies the requirements of a core constant expression.
  .Sp
! This warning is enabled as a pedantic warning by default in \*(C+20 and
! earlier.  In \*(C+23, \fB\-Winvalid\-constexpr\fR can be turned on, in
  which case it will be an ordinary warning.  For example:
  .Sp
  .Vb 7
--- 3748,3775 ----
  \&        // now the temporary is gone and li has a dangling pointer
  \&        int i = li.begin()[0] // undefined behavior
  .Ve
! .IP * 4
  When a list constructor stores the \f(CW\*(C`begin\*(C'\fR pointer from the
! \&\f(CW\*(C`initializer_list\*(C'\fR argument, this doesn\*(Aqt extend the lifetime of
  the array, so if a class variable is constructed from a temporary
  \&\f(CW\*(C`initializer_list\*(C'\fR, the pointer is left dangling by the end of
  the variable declaration statement.
  .RE
  .RS 4
  .RE
! .IP \fB\-Winvalid\-constexpr\fR 4
  .IX Item "-Winvalid-constexpr"
! Warn when a function never produces a constant expression.  In C++20
  and earlier, for every \f(CW\*(C`constexpr\*(C'\fR function and function template,
  there must be at least one set of function arguments in at least one
  instantiation such that an invocation of the function or constructor
  could be an evaluated subexpression of a core constant expression.
! C++23 removed this restriction, so it\*(Aqs possible to have a function
  or a function template marked \f(CW\*(C`constexpr\*(C'\fR for which no invocation
  satisfies the requirements of a core constant expression.
  .Sp
! This warning is enabled as a pedantic warning by default in C++20 and
! earlier.  In C++23, \fB\-Winvalid\-constexpr\fR can be turned on, in
  which case it will be an ordinary warning.  For example:
  .Sp
  .Vb 7
*************** which case it will be an ordinary warnin
*** 3852,3868 ****
  \&          f(i);
  \&        }
  .Ve
! .IP "\fB\-Winvalid\-imported\-macros\fR" 4
  .IX Item "-Winvalid-imported-macros"
  Verify all imported macro definitions are valid at the end of
  compilation.  This is not enabled by default, as it requires
  additional processing to determine.  It may be useful when preparing
! sets of header-units to ensure consistent macros.
! .IP "\fB\-Wno\-literal\-suffix\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-literal-suffix ( and Objective- only)"
  Do not warn when a string or character literal is followed by a
! ud-suffix which does not begin with an underscore.  As a conforming
! extension, \s-1GCC\s0 treats such suffixes as separate preprocessing tokens
  in order to maintain backwards compatibility with code that uses
  formatting macros from \f(CW\*(C`\*(C'\fR.  For example:
  .Sp
--- 3781,3797 ----
  \&          f(i);
  \&        }
  .Ve
! .IP \fB\-Winvalid\-imported\-macros\fR 4
  .IX Item "-Winvalid-imported-macros"
  Verify all imported macro definitions are valid at the end of
  compilation.  This is not enabled by default, as it requires
  additional processing to determine.  It may be useful when preparing
! sets of header\-units to ensure consistent macros.
! .IP "\fB\-Wno\-literal\-suffix\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-literal-suffix (C++ and Objective-C++ only)"
  Do not warn when a string or character literal is followed by a
! ud\-suffix which does not begin with an underscore.  As a conforming
! extension, GCC treats such suffixes as separate preprocessing tokens
  in order to maintain backwards compatibility with code that uses
  formatting macros from \f(CW\*(C`\*(C'\fR.  For example:
  .Sp
*************** formatting macros from \f(CW\*(C`\*(C'\fR, but in
! \&\*(C+17 it calls \f(CW\*(C`f\*(C'\fR.
! .IP "\fB\-Wclass\-memaccess\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wclass-memaccess ( and Objective- only)"
  Warn when the destination of a call to a raw memory function such as
  \&\f(CW\*(C`memset\*(C'\fR or \f(CW\*(C`memcpy\*(C'\fR is an object of class type, and when writing
! into such an object might bypass the class non-trivial or deleted constructor
! or copy assignment, violate const-correctness or encapsulation, or corrupt
  virtual table pointers.  Modifying the representation of such objects may
  violate invariants maintained by member functions of the class.  For example,
! the call to \f(CW\*(C`memset\*(C'\fR below is undefined because it modifies a non-trivial
  class object and is, therefore, diagnosed.  The safe way to either initialize
  or clear the storage of objects of such types is by using the appropriate
  constructor or assignment operator, if one is available.
--- 3852,3868 ----
  \&        void h() { f(g); }
  .Ve
  .Sp
! In C++14, \f(CW\*(C`f\*(C'\fR calls \f(CW\*(C`f\*(C'\fR, but in
! C++17 it calls \f(CW\*(C`f\*(C'\fR.
! .IP "\fB\-Wclass\-memaccess\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wclass-memaccess (C++ and Objective-C++ only)"
  Warn when the destination of a call to a raw memory function such as
  \&\f(CW\*(C`memset\*(C'\fR or \f(CW\*(C`memcpy\*(C'\fR is an object of class type, and when writing
! into such an object might bypass the class non\-trivial or deleted constructor
! or copy assignment, violate const\-correctness or encapsulation, or corrupt
  virtual table pointers.  Modifying the representation of such objects may
  violate invariants maintained by member functions of the class.  For example,
! the call to \f(CW\*(C`memset\*(C'\fR below is undefined because it modifies a non\-trivial
  class object and is, therefore, diagnosed.  The safe way to either initialize
  or clear the storage of objects of such types is by using the appropriate
  constructor or assignment operator, if one is available.
*************** The \fB\-Wclass\-memaccess\fR option is
*** 3947,3955 ****
  Explicitly casting the pointer to the class object to \f(CW\*(C`void *\*(C'\fR or
  to a type that can be safely accessed by the raw memory function suppresses
  the warning.
! .IP "\fB\-Wnon\-virtual\-dtor\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wnon-virtual-dtor ( and Objective- only)"
! Warn when a class has virtual functions and an accessible non-virtual
  destructor itself or in an accessible polymorphic base class, in which
  case it is possible but unsafe to delete an instance of a derived
  class through a pointer to the class itself or base class.  This
--- 3876,3884 ----
  Explicitly casting the pointer to the class object to \f(CW\*(C`void *\*(C'\fR or
  to a type that can be safely accessed by the raw memory function suppresses
  the warning.
! .IP "\fB\-Wnon\-virtual\-dtor\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wnon-virtual-dtor (C++ and Objective-C++ only)"
! Warn when a class has virtual functions and an accessible non\-virtual
  destructor itself or in an accessible polymorphic base class, in which
  case it is possible but unsafe to delete an instance of a derived
  class through a pointer to the class itself or base class.  This
*************** warning is automatically enabled if \fB\
*** 3957,3971 ****
  The \fB\-Wdelete\-non\-virtual\-dtor\fR option (enabled by \fB\-Wall\fR)
  should be preferred because it warns about the unsafe cases without false
  positives.
! .IP "\fB\-Wregister\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wregister ( and Objective- only)"
  Warn on uses of the \f(CW\*(C`register\*(C'\fR storage class specifier, except
! when it is part of the \s-1GNU\s0 \fBExplicit Register Variables\fR extension.
  The use of the \f(CW\*(C`register\*(C'\fR keyword as storage class specifier has
! been deprecated in \*(C+11 and removed in \*(C+17.
  Enabled by default with \fB\-std=c++17\fR.
! .IP "\fB\-Wreorder\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wreorder ( and Objective- only)"
  Warn when the order of member initializers given in the code does not
  match the order in which they must be executed.  For instance:
  .Sp
--- 3886,3900 ----
  The \fB\-Wdelete\-non\-virtual\-dtor\fR option (enabled by \fB\-Wall\fR)
  should be preferred because it warns about the unsafe cases without false
  positives.
! .IP "\fB\-Wregister\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wregister (C++ and Objective-C++ only)"
  Warn on uses of the \f(CW\*(C`register\*(C'\fR storage class specifier, except
! when it is part of the GNU \fBExplicit Register Variables\fR extension.
  The use of the \f(CW\*(C`register\*(C'\fR keyword as storage class specifier has
! been deprecated in C++11 and removed in C++17.
  Enabled by default with \fB\-std=c++17\fR.
! .IP "\fB\-Wreorder\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-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:
  .Sp
*************** match the order in which they must be ex
*** 3980,3991 ****
  The compiler rearranges the member initializers for \f(CW\*(C`i\*(C'\fR
  and \f(CW\*(C`j\*(C'\fR to match the declaration order of the members, emitting
  a warning to that effect.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-pessimizing\-move\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-pessimizing-move ( and Objective- only)"
  This warning warns when a call to \f(CW\*(C`std::move\*(C'\fR prevents copy
  elision.  A typical scenario when copy elision can occur is when returning in
  a function with a class return type, when the expression being returned is the
! name of a non-volatile automatic object, and is not a function parameter, and
  has the same type as the function return type.
  .Sp
  .Vb 9
--- 3909,3920 ----
  The compiler rearranges the member initializers for \f(CW\*(C`i\*(C'\fR
  and \f(CW\*(C`j\*(C'\fR to match the declaration order of the members, emitting
  a warning to that effect.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-pessimizing\-move\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-pessimizing-move (C++ and Objective-C++ only)"
  This warning warns when a call to \f(CW\*(C`std::move\*(C'\fR prevents copy
  elision.  A typical scenario when copy elision can occur is when returning in
  a function with a class return type, when the expression being returned is the
! name of a non\-volatile automatic object, and is not a function parameter, and
  has the same type as the function return type.
  .Sp
  .Vb 9
*************** has the same type as the function return
*** 4003,4015 ****
  But in this example, the \f(CW\*(C`std::move\*(C'\fR call prevents copy elision.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-redundant\-move\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-redundant-move ( and Objective- only)"
  This warning warns about redundant calls to \f(CW\*(C`std::move\*(C'\fR; that is, when
  a move operation would have been performed even without the \f(CW\*(C`std::move\*(C'\fR
  call.  This happens because the compiler is forced to treat the object as if
  it were an rvalue in certain situations such as returning a local variable,
! where copy elision isn't applicable.  Consider:
  .Sp
  .Vb 8
  \&        struct T {
--- 3932,3944 ----
  But in this example, the \f(CW\*(C`std::move\*(C'\fR call prevents copy elision.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-redundant\-move\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-redundant-move (C++ and Objective-C++ only)"
  This warning warns about redundant calls to \f(CW\*(C`std::move\*(C'\fR; that is, when
  a move operation would have been performed even without the \f(CW\*(C`std::move\*(C'\fR
  call.  This happens because the compiler is forced to treat the object as if
  it were an rvalue in certain situations such as returning a local variable,
! where copy elision isn\*(Aqt applicable.  Consider:
  .Sp
  .Vb 8
  \&        struct T {
*************** Issue 1579, another example is:
*** 4040,4053 ****
  \&        }
  .Ve
  .Sp
! In this example, copy elision isn't applicable because the type of the
  expression being returned and the function return type differ, yet G++
  treats the return value as if it were designated by an rvalue.
  .Sp
  This warning is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wrange\-loop\-construct\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wrange-loop-construct ( and Objective- only)"
! This warning warns when a \*(C+ range-based for-loop is creating an unnecessary
  copy.  This can happen when the range declaration is not a reference, but
  probably should be.  For example:
  .Sp
--- 3969,3982 ----
  \&        }
  .Ve
  .Sp
! In this example, copy elision isn\*(Aqt applicable because the type of the
  expression being returned and the function return type differ, yet G++
  treats the return value as if it were designated by an rvalue.
  .Sp
  This warning is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wrange\-loop\-construct\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wrange-loop-construct (C++ and Objective-C++ only)"
! This warning warns when a C++ range\-based for\-loop is creating an unnecessary
  copy.  This can happen when the range declaration is not a reference, but
  probably should be.  For example:
  .Sp
*************** probably should be.  For example:
*** 4059,4068 ****
  \&        }
  .Ve
  .Sp
! It does not warn when the type being copied is a trivially-copyable type whose
  size is less than 64 bytes.
  .Sp
! This warning also warns when a loop variable in a range-based for-loop is
  initialized with a value of a different type resulting in a copy.  For example:
  .Sp
  .Vb 4
--- 3988,3997 ----
  \&        }
  .Ve
  .Sp
! It does not warn when the type being copied is a trivially\-copyable type whose
  size is less than 64 bytes.
  .Sp
! This warning also warns when a loop variable in a range\-based for\-loop is
  initialized with a value of a different type resulting in a copy.  For example:
  .Sp
  .Vb 4
*************** type \f(CW\*(C`double\*(C'\fR is created
*** 4077,4085 ****
  \&\f(CW\*(C`const double &\*(C'\fR is bound.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wredundant\-tags\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wredundant-tags ( and Objective- only)"
! Warn about redundant class-key and enum-key in references to class types
  and enumerated types in contexts where the key can be eliminated without
  causing an ambiguity.  For example:
  .Sp
--- 4006,4014 ----
  \&\f(CW\*(C`const double &\*(C'\fR is bound.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wredundant\-tags\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wredundant-tags (C++ and Objective-C++ only)"
! Warn about redundant class\-key and enum\-key in references to class types
  and enumerated types in contexts where the key can be eliminated without
  causing an ambiguity.  For example:
  .Sp
*************** On the other hand, in this example there
*** 4095,4174 ****
  \&        void foo ();   // "hides" struct foo
  \&        void bar (struct foo&);  // no warning, keyword struct is necessary
  .Ve
! .IP "\fB\-Wno\-subobject\-linkage\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-subobject-linkage ( and Objective- only)"
  Do not warn
  if a class type has a base or a field whose type uses the anonymous
  namespace or depends on a type with no linkage.  If a type A depends on
  a type B with no or internal linkage, defining it in multiple
! translation units would be an \s-1ODR\s0 violation because the meaning of B
  is different in each translation unit.  If A only appears in a single
  translation unit, the best way to silence the warning is to give it
  internal linkage by putting it in an anonymous namespace as well.  The
! compiler doesn't give this warning for types defined in the main .C
  file, as those are unlikely to have multiple definitions.
  \&\fB\-Wsubobject\-linkage\fR is enabled by default.
! .IP "\fB\-Weffc++\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Weffc++ ( and Objective- only)"
! Warn about violations of the following style guidelines from Scott Meyers'
! \&\fIEffective \*(C+\fR series of books:
  .RS 4
! .IP "*" 4
  Define a copy constructor and an assignment operator for classes
! with dynamically-allocated memory.
! .IP "*" 4
  Prefer initialization to assignment in constructors.
! .IP "*" 4
  Have \f(CW\*(C`operator=\*(C'\fR return a reference to \f(CW*this\fR.
! .IP "*" 4
! Don't try to return a reference when you must return an object.
! .IP "*" 4
  Distinguish between prefix and postfix forms of increment and
  decrement operators.
! .IP "*" 4
  Never overload \f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, or \f(CW\*(C`,\*(C'\fR.
  .RE
  .RS 4
  .Sp
  This option also enables \fB\-Wnon\-virtual\-dtor\fR, which is also
! one of the effective \*(C+ recommendations.  However, the check is
  extended to warn about the lack of virtual destructor in accessible
! non-polymorphic bases classes too.
  .Sp
  When selecting this option, be aware that the standard library
  headers do not obey all of these guidelines; use \fBgrep \-v\fR
  to filter out those warnings.
  .RE
! .IP "\fB\-Wno\-exceptions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-exceptions ( and Objective- only)"
  Disable the warning about the case when an exception handler is shadowed by
  another handler, which can point out a wrong ordering of exception handlers.
! .IP "\fB\-Wstrict\-null\-sentinel\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wstrict-null-sentinel ( and Objective- only)"
  Warn about the use of an uncasted \f(CW\*(C`NULL\*(C'\fR as sentinel.  When
! compiling only with \s-1GCC\s0 this is a valid sentinel, as \f(CW\*(C`NULL\*(C'\fR is defined
  to \f(CW\*(C`_\|_null\*(C'\fR.  Although it is a null pointer constant rather than a
  null pointer, it is guaranteed to be of the same size as a pointer.
  But this use is not portable across different compilers.
! .IP "\fB\-Wno\-non\-template\-friend\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-non-template-friend ( and Objective- only)"
! Disable warnings when non-template friend functions are declared
! within a template.  In very old versions of \s-1GCC\s0 that predate implementation
! of the \s-1ISO\s0 standard, declarations such as 
! \&\fBfriend int foo(int)\fR, where the name of the friend is an unqualified-id,
  could be interpreted as a particular specialization of a template
  function; the warning exists to diagnose compatibility problems, 
  and is enabled by default.
! .IP "\fB\-Wold\-style\-cast\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wold-style-cast ( and Objective- only)"
! Warn if an old-style (C\-style) cast to a non-void type is used within
! a \*(C+ program.  The new-style casts (\f(CW\*(C`dynamic_cast\*(C'\fR,
  \&\f(CW\*(C`static_cast\*(C'\fR, \f(CW\*(C`reinterpret_cast\*(C'\fR, and \f(CW\*(C`const_cast\*(C'\fR) are
  less vulnerable to unintended effects and much easier to search for.
! .IP "\fB\-Woverloaded\-virtual\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Woverloaded-virtual ( and Objective- only)"
  .PD 0
! .IP "\fB\-Woverloaded\-virtual=\fR\fIn\fR" 4
  .IX Item "-Woverloaded-virtual=n"
  .PD
  Warn when a function declaration hides virtual functions from a
--- 4024,4103 ----
  \&        void foo ();   // "hides" struct foo
  \&        void bar (struct foo&);  // no warning, keyword struct is necessary
  .Ve
! .IP "\fB\-Wno\-subobject\-linkage\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-subobject-linkage (C++ and Objective-C++ only)"
  Do not warn
  if a class type has a base or a field whose type uses the anonymous
  namespace or depends on a type with no linkage.  If a type A depends on
  a type B with no or internal linkage, defining it in multiple
! translation units would be an ODR violation because the meaning of B
  is different in each translation unit.  If A only appears in a single
  translation unit, the best way to silence the warning is to give it
  internal linkage by putting it in an anonymous namespace as well.  The
! compiler doesn\*(Aqt give this warning for types defined in the main .C
  file, as those are unlikely to have multiple definitions.
  \&\fB\-Wsubobject\-linkage\fR is enabled by default.
! .IP "\fB\-Weffc++\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Weffc++ (C++ and Objective-C++ only)"
! Warn about violations of the following style guidelines from Scott Meyers\*(Aq
! \&\fIEffective C++\fR series of books:
  .RS 4
! .IP * 4
  Define a copy constructor and an assignment operator for classes
! with dynamically\-allocated memory.
! .IP * 4
  Prefer initialization to assignment in constructors.
! .IP * 4
  Have \f(CW\*(C`operator=\*(C'\fR return a reference to \f(CW*this\fR.
! .IP * 4
! Don\*(Aqt try to return a reference when you must return an object.
! .IP * 4
  Distinguish between prefix and postfix forms of increment and
  decrement operators.
! .IP * 4
  Never overload \f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, or \f(CW\*(C`,\*(C'\fR.
  .RE
  .RS 4
  .Sp
  This option also enables \fB\-Wnon\-virtual\-dtor\fR, which is also
! one of the effective C++ recommendations.  However, the check is
  extended to warn about the lack of virtual destructor in accessible
! non\-polymorphic bases classes too.
  .Sp
  When selecting this option, be aware that the standard library
  headers do not obey all of these guidelines; use \fBgrep \-v\fR
  to filter out those warnings.
  .RE
! .IP "\fB\-Wno\-exceptions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-exceptions (C++ and Objective-C++ only)"
  Disable the warning about the case when an exception handler is shadowed by
  another handler, which can point out a wrong ordering of exception handlers.
! .IP "\fB\-Wstrict\-null\-sentinel\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wstrict-null-sentinel (C++ and Objective-C++ only)"
  Warn about the use of an uncasted \f(CW\*(C`NULL\*(C'\fR as sentinel.  When
! compiling only with GCC this is a valid sentinel, as \f(CW\*(C`NULL\*(C'\fR is defined
  to \f(CW\*(C`_\|_null\*(C'\fR.  Although it is a null pointer constant rather than a
  null pointer, it is guaranteed to be of the same size as a pointer.
  But this use is not portable across different compilers.
! .IP "\fB\-Wno\-non\-template\-friend\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-non-template-friend (C++ and Objective-C++ only)"
! Disable warnings when non\-template friend functions are declared
! within a template.  In very old versions of GCC that predate implementation
! of the ISO standard, declarations such as 
! \&\fBfriend int foo(int)\fR, where the name of the friend is an unqualified\-id,
  could be interpreted as a particular specialization of a template
  function; the warning exists to diagnose compatibility problems, 
  and is enabled by default.
! .IP "\fB\-Wold\-style\-cast\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-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 (\f(CW\*(C`dynamic_cast\*(C'\fR,
  \&\f(CW\*(C`static_cast\*(C'\fR, \f(CW\*(C`reinterpret_cast\*(C'\fR, and \f(CW\*(C`const_cast\*(C'\fR) are
  less vulnerable to unintended effects and much easier to search for.
! .IP "\fB\-Woverloaded\-virtual\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Woverloaded-virtual (C++ and Objective-C++ only)"
  .PD 0
! .IP \fB\-Woverloaded\-virtual=\fR\fIn\fR 4
  .IX Item "-Woverloaded-virtual=n"
  .PD
  Warn when a function declaration hides virtual functions from a
*************** like:
*** 4195,4202 ****
  fails to compile.
  .Sp
  In cases where the different signatures are not an accident, the
! simplest solution is to add a using-declaration to the derived class
! to un-hide the base function, e.g. add \f(CW\*(C`using A::f;\*(C'\fR to \f(CW\*(C`B\*(C'\fR.
  .Sp
  The optional level suffix controls the behavior when all the
  declarations in the derived class override virtual functions in the
--- 4124,4131 ----
  fails to compile.
  .Sp
  In cases where the different signatures are not an accident, the
! simplest solution is to add a using\-declaration to the derived class
! to un\-hide the base function, e.g. add \f(CW\*(C`using A::f;\*(C'\fR to \f(CW\*(C`B\*(C'\fR.
  .Sp
  The optional level suffix controls the behavior when all the
  declarations in the derived class override virtual functions in the
*************** for some of the overloads are fine.
*** 4220,4255 ****
  At level 1, this case does not warn; at level 2, it does.
  \&\fB\-Woverloaded\-virtual\fR by itself selects level 2.  Level 1 is
  included in \fB\-Wall\fR.
! .IP "\fB\-Wno\-pmf\-conversions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-pmf-conversions ( and Objective- only)"
  Disable the diagnostic for converting a bound pointer to member function
  to a plain pointer.
! .IP "\fB\-Wsign\-promo\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wsign-promo ( and Objective- only)"
  Warn when overload resolution chooses a promotion from unsigned or
  enumerated type to a signed type, over a conversion to an unsigned type of
  the same size.  Previous versions of G++ tried to preserve
  unsignedness, but the standard mandates the current behavior.
! .IP "\fB\-Wtemplates\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wtemplates ( and Objective- only)"
  Warn when a primary template declaration is encountered.  Some coding
  rules disallow templates, and this may be used to enforce that rule.
! The warning is inactive inside a system header file, such as the \s-1STL,\s0 so
! one can still use the \s-1STL.\s0  One may also instantiate or specialize
  templates.
! .IP "\fB\-Wmismatched\-new\-delete\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wmismatched-new-delete ( and Objective- only)"
  Warn for mismatches between calls to \f(CW\*(C`operator new\*(C'\fR or \f(CW\*(C`operator
  delete\*(C'\fR and the corresponding call to the allocation or deallocation function.
! This includes invocations of \*(C+ \f(CW\*(C`operator delete\*(C'\fR with pointers
  returned from either mismatched forms of \f(CW\*(C`operator new\*(C'\fR, or from other
! functions that allocate objects for which the \f(CW\*(C`operator delete\*(C'\fR isn't
  a suitable deallocator, as well as calls to other deallocation functions
  with pointers returned from \f(CW\*(C`operator new\*(C'\fR for which the deallocation
! function isn't suitable.
  .Sp
  For example, the \f(CW\*(C`delete\*(C'\fR expression in the function below is diagnosed
! because it doesn't match the array form of the \f(CW\*(C`new\*(C'\fR expression
  the pointer argument was returned from.  Similarly, the call to \f(CW\*(C`free\*(C'\fR
  is also diagnosed.
  .Sp
--- 4149,4184 ----
  At level 1, this case does not warn; at level 2, it does.
  \&\fB\-Woverloaded\-virtual\fR by itself selects level 2.  Level 1 is
  included in \fB\-Wall\fR.
! .IP "\fB\-Wno\-pmf\-conversions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-pmf-conversions (C++ and Objective-C++ only)"
  Disable the diagnostic for converting a bound pointer to member function
  to a plain pointer.
! .IP "\fB\-Wsign\-promo\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wsign-promo (C++ and Objective-C++ only)"
  Warn when overload resolution chooses a promotion from unsigned or
  enumerated type to a signed type, over a conversion to an unsigned type of
  the same size.  Previous versions of G++ tried to preserve
  unsignedness, but the standard mandates the current behavior.
! .IP "\fB\-Wtemplates\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wtemplates (C++ and Objective-C++ only)"
  Warn when a primary template declaration is encountered.  Some coding
  rules disallow templates, and this may be used to enforce that rule.
! The warning is inactive inside a system header file, such as the STL, so
! one can still use the STL.  One may also instantiate or specialize
  templates.
! .IP "\fB\-Wmismatched\-new\-delete\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wmismatched-new-delete (C++ and Objective-C++ only)"
  Warn for mismatches between calls to \f(CW\*(C`operator new\*(C'\fR or \f(CW\*(C`operator
  delete\*(C'\fR and the corresponding call to the allocation or deallocation function.
! This includes invocations of C++ \f(CW\*(C`operator delete\*(C'\fR with pointers
  returned from either mismatched forms of \f(CW\*(C`operator new\*(C'\fR, or from other
! functions that allocate objects for which the \f(CW\*(C`operator delete\*(C'\fR isn\*(Aqt
  a suitable deallocator, as well as calls to other deallocation functions
  with pointers returned from \f(CW\*(C`operator new\*(C'\fR for which the deallocation
! function isn\*(Aqt suitable.
  .Sp
  For example, the \f(CW\*(C`delete\*(C'\fR expression in the function below is diagnosed
! because it doesn\*(Aqt match the array form of the \f(CW\*(C`new\*(C'\fR expression
  the pointer argument was returned from.  Similarly, the call to \f(CW\*(C`free\*(C'\fR
  is also diagnosed.
  .Sp
*************** involving allocation and deallocation fu
*** 4269,4283 ****
  new\*(C'\fR and \f(CW\*(C`operator delete\*(C'\fR.
  .Sp
  \&\fB\-Wmismatched\-new\-delete\fR is included in \fB\-Wall\fR.
! .IP "\fB\-Wmismatched\-tags\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wmismatched-tags ( and Objective- only)"
  Warn for declarations of structs, classes, and class templates and their
! specializations with a class-key that does not match either the definition
  or the first declaration if no definition is provided.
  .Sp
  For example, the declaration of \f(CW\*(C`struct Object\*(C'\fR in the argument list
  of \f(CW\*(C`draw\*(C'\fR triggers the warning.  To avoid it, either remove the redundant
! class-key \f(CW\*(C`struct\*(C'\fR or replace it with \f(CW\*(C`class\*(C'\fR to match its definition.
  .Sp
  .Vb 5
  \&        class Object {
--- 4198,4212 ----
  new\*(C'\fR and \f(CW\*(C`operator delete\*(C'\fR.
  .Sp
  \&\fB\-Wmismatched\-new\-delete\fR is included in \fB\-Wall\fR.
! .IP "\fB\-Wmismatched\-tags\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wmismatched-tags (C++ and Objective-C++ only)"
  Warn for declarations of structs, classes, and class templates and their
! specializations with a class\-key that does not match either the definition
  or the first declaration if no definition is provided.
  .Sp
  For example, the declaration of \f(CW\*(C`struct Object\*(C'\fR in the argument list
  of \f(CW\*(C`draw\*(C'\fR triggers the warning.  To avoid it, either remove the redundant
! class\-key \f(CW\*(C`struct\*(C'\fR or replace it with \f(CW\*(C`class\*(C'\fR to match its definition.
  .Sp
  .Vb 5
  \&        class Object {
*************** class-key \f(CW\*(C`struct\*(C'\fR or re
*** 4287,4336 ****
  \&        void draw (struct Object*);
  .Ve
  .Sp
! It is not wrong to declare a class with the class-key \f(CW\*(C`struct\*(C'\fR as
  the example above shows.  The \fB\-Wmismatched\-tags\fR option is intended
  to help achieve a consistent style of class declarations.  In code that is
! intended to be portable to Windows-based compilers the warning helps prevent
  unresolved references due to the difference in the mangling of symbols
! declared with different class-keys.  The option can be used either on its
  own or in conjunction with \fB\-Wredundant\-tags\fR.
! .IP "\fB\-Wmultiple\-inheritance\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wmultiple-inheritance ( and Objective- only)"
  Warn when a class is defined with multiple direct base classes.  Some
  coding rules disallow multiple inheritance, and this may be used to
  enforce that rule.  The warning is inactive inside a system header file,
! such as the \s-1STL,\s0 so one can still use the \s-1STL.\s0  One may also define
  classes that indirectly use multiple inheritance.
! .IP "\fB\-Wvirtual\-inheritance\fR" 4
  .IX Item "-Wvirtual-inheritance"
  Warn when a class is defined with a virtual direct base class.  Some
  coding rules disallow multiple inheritance, and this may be used to
  enforce that rule.  The warning is inactive inside a system header file,
! such as the \s-1STL,\s0 so one can still use the \s-1STL.\s0  One may also define
  classes that indirectly use virtual inheritance.
! .IP "\fB\-Wno\-virtual\-move\-assign\fR" 4
  .IX Item "-Wno-virtual-move-assign"
  Suppress warnings about inheriting from a virtual base with a
! non-trivial \*(C+11 move assignment operator.  This is dangerous because
  if the virtual base is reachable along more than one path, it is
  moved multiple times, which can mean both objects end up in the
! moved-from state.  If the move assignment operator is written to avoid
! moving from a moved-from object, this warning can be disabled.
! .IP "\fB\-Wnamespaces\fR" 4
  .IX Item "-Wnamespaces"
  Warn when a namespace definition is opened.  Some coding rules disallow
  namespaces, and this may be used to enforce that rule.  The warning is
! inactive inside a system header file, such as the \s-1STL,\s0 so one can still
! use the \s-1STL.\s0  One may also use using directives and qualified names.
! .IP "\fB\-Wno\-terminate\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-terminate ( and Objective- only)"
! Disable the warning about a throw-expression that will immediately
  result in a call to \f(CW\*(C`terminate\*(C'\fR.
! .IP "\fB\-Wno\-vexing\-parse\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-vexing-parse ( and Objective- only)"
  Warn about the most vexing parse syntactic ambiguity.  This warns about
  the cases when a declaration looks like a variable definition, but the
! \&\*(C+ language requires it to be interpreted as a function declaration.
  For instance:
  .Sp
  .Vb 4
--- 4216,4265 ----
  \&        void draw (struct Object*);
  .Ve
  .Sp
! It is not wrong to declare a class with the class\-key \f(CW\*(C`struct\*(C'\fR as
  the example above shows.  The \fB\-Wmismatched\-tags\fR option is intended
  to help achieve a consistent style of class declarations.  In code that is
! intended to be portable to Windows\-based compilers the warning helps prevent
  unresolved references due to the difference in the mangling of symbols
! declared with different class\-keys.  The option can be used either on its
  own or in conjunction with \fB\-Wredundant\-tags\fR.
! .IP "\fB\-Wmultiple\-inheritance\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wmultiple-inheritance (C++ and Objective-C++ only)"
  Warn when a class is defined with multiple direct base classes.  Some
  coding rules disallow multiple inheritance, and this may be used to
  enforce that rule.  The warning is inactive inside a system header file,
! such as the STL, so one can still use the STL.  One may also define
  classes that indirectly use multiple inheritance.
! .IP \fB\-Wvirtual\-inheritance\fR 4
  .IX Item "-Wvirtual-inheritance"
  Warn when a class is defined with a virtual direct base class.  Some
  coding rules disallow multiple inheritance, and this may be used to
  enforce that rule.  The warning is inactive inside a system header file,
! such as the STL, so one can still use the STL.  One may also define
  classes that indirectly use virtual inheritance.
! .IP \fB\-Wno\-virtual\-move\-assign\fR 4
  .IX Item "-Wno-virtual-move-assign"
  Suppress warnings about inheriting from a virtual base with a
! non\-trivial C++11 move assignment operator.  This is dangerous because
  if the virtual base is reachable along more than one path, it is
  moved multiple times, which can mean both objects end up in the
! moved\-from state.  If the move assignment operator is written to avoid
! moving from a moved\-from object, this warning can be disabled.
! .IP \fB\-Wnamespaces\fR 4
  .IX Item "-Wnamespaces"
  Warn when a namespace definition is opened.  Some coding rules disallow
  namespaces, and this may be used to enforce that rule.  The warning is
! inactive inside a system header file, such as the STL, so one can still
! use the STL.  One may also use using directives and qualified names.
! .IP "\fB\-Wno\-terminate\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-terminate (C++ and Objective-C++ only)"
! Disable the warning about a throw\-expression that will immediately
  result in a call to \f(CW\*(C`terminate\*(C'\fR.
! .IP "\fB\-Wno\-vexing\-parse\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-vexing-parse (C++ and Objective-C++ only)"
  Warn about the most vexing parse syntactic ambiguity.  This warns about
  the cases when a declaration looks like a variable definition, but the
! C++ language requires it to be interpreted as a function declaration.
  For instance:
  .Sp
  .Vb 4
*************** The warning will suggest options how to
*** 4355,4395 ****
  it can suggest removing the parentheses or using braces instead.
  .Sp
  This warning is enabled by default.
! .IP "\fB\-Wno\-class\-conversion\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-class-conversion ( and Objective- only)"
  Do not warn when a conversion function converts an
  object to the same type, to a base class of that type, or to void; such
  a conversion function will never be called.
! .IP "\fB\-Wvolatile\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wvolatile ( and Objective- only)"
  Warn about deprecated uses of the \f(CW\*(C`volatile\*(C'\fR qualifier.  This includes
  postfix and prefix \f(CW\*(C`++\*(C'\fR and \f(CW\*(C`\-\-\*(C'\fR expressions of
  \&\f(CW\*(C`volatile\*(C'\fR\-qualified types, using simple assignments where the left
! operand is a \f(CW\*(C`volatile\*(C'\fR\-qualified non-class type for their value,
  compound assignments where the left operand is a \f(CW\*(C`volatile\*(C'\fR\-qualified
! non-class type, \f(CW\*(C`volatile\*(C'\fR\-qualified function return type,
  \&\f(CW\*(C`volatile\*(C'\fR\-qualified parameter type, and structured bindings of a
! \&\f(CW\*(C`volatile\*(C'\fR\-qualified type.  This usage was deprecated in \*(C+20.
  .Sp
  Enabled by default with \fB\-std=c++20\fR.
! .IP "\fB\-Wzero\-as\-null\-pointer\-constant\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wzero-as-null-pointer-constant ( and Objective- only)"
  Warn when a literal \fB0\fR is used as null pointer constant.  This can
! be useful to facilitate the conversion to \f(CW\*(C`nullptr\*(C'\fR in \*(C+11.
! .IP "\fB\-Waligned\-new\fR" 4
  .IX Item "-Waligned-new"
! Warn about a new-expression of a type that requires greater alignment
! than the \f(CW\*(C`alignof(std::max_align_t)\*(C'\fR but uses an allocation
  function without an explicit alignment parameter. This option is
  enabled by \fB\-Wall\fR.
  .Sp
  Normally this only warns about global allocation functions, but
  \&\fB\-Waligned\-new=all\fR also warns about class member allocation
  functions.
! .IP "\fB\-Wno\-placement\-new\fR" 4
  .IX Item "-Wno-placement-new"
  .PD 0
! .IP "\fB\-Wplacement\-new=\fR\fIn\fR" 4
  .IX Item "-Wplacement-new=n"
  .PD
  Warn about placement new expressions with undefined behavior, such as
--- 4284,4324 ----
  it can suggest removing the parentheses or using braces instead.
  .Sp
  This warning is enabled by default.
! .IP "\fB\-Wno\-class\-conversion\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-class-conversion (C++ and Objective-C++ only)"
  Do not warn when a conversion function converts an
  object to the same type, to a base class of that type, or to void; such
  a conversion function will never be called.
! .IP "\fB\-Wvolatile\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wvolatile (C++ and Objective-C++ only)"
  Warn about deprecated uses of the \f(CW\*(C`volatile\*(C'\fR qualifier.  This includes
  postfix and prefix \f(CW\*(C`++\*(C'\fR and \f(CW\*(C`\-\-\*(C'\fR expressions of
  \&\f(CW\*(C`volatile\*(C'\fR\-qualified types, using simple assignments where the left
! operand is a \f(CW\*(C`volatile\*(C'\fR\-qualified non\-class type for their value,
  compound assignments where the left operand is a \f(CW\*(C`volatile\*(C'\fR\-qualified
! non\-class type, \f(CW\*(C`volatile\*(C'\fR\-qualified function return type,
  \&\f(CW\*(C`volatile\*(C'\fR\-qualified parameter type, and structured bindings of a
! \&\f(CW\*(C`volatile\*(C'\fR\-qualified type.  This usage was deprecated in C++20.
  .Sp
  Enabled by default with \fB\-std=c++20\fR.
! .IP "\fB\-Wzero\-as\-null\-pointer\-constant\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wzero-as-null-pointer-constant (C++ and Objective-C++ only)"
  Warn when a literal \fB0\fR is used as null pointer constant.  This can
! be useful to facilitate the conversion to \f(CW\*(C`nullptr\*(C'\fR in C++11.
! .IP \fB\-Waligned\-new\fR 4
  .IX Item "-Waligned-new"
! Warn about a new\-expression of a type that requires greater alignment
! than the \f(CWalignof(std::max_align_t)\fR but uses an allocation
  function without an explicit alignment parameter. This option is
  enabled by \fB\-Wall\fR.
  .Sp
  Normally this only warns about global allocation functions, but
  \&\fB\-Waligned\-new=all\fR also warns about class member allocation
  functions.
! .IP \fB\-Wno\-placement\-new\fR 4
  .IX Item "-Wno-placement-new"
  .PD 0
! .IP \fB\-Wplacement\-new=\fR\fIn\fR 4
  .IX Item "-Wplacement-new=n"
  .PD
  Warn about placement new expressions with undefined behavior, such as
*************** because it attempts to construct an arra
*** 4405,4425 ****
  .Sp
  This warning is enabled by default.
  .RS 4
! .IP "\fB\-Wplacement\-new=1\fR" 4
  .IX Item "-Wplacement-new=1"
  This is the default warning level of \fB\-Wplacement\-new\fR.  At this
  level the warning is not issued for some strictly undefined constructs that
! \&\s-1GCC\s0 allows as extensions for compatibility with legacy code.  For example,
  the following \f(CW\*(C`new\*(C'\fR expression is not diagnosed at this level even
! though it has undefined behavior according to the \*(C+ standard because
! it writes past the end of the one-element array.
  .Sp
  .Vb 3
  \&        struct S { int n, a[1]; };
  \&        S *s = (S *)malloc (sizeof *s + 31 * sizeof s\->a[0]);
  \&        new (s\->a)int [32]();
  .Ve
! .IP "\fB\-Wplacement\-new=2\fR" 4
  .IX Item "-Wplacement-new=2"
  At this level, in addition to diagnosing all the same constructs as at level
  1, a diagnostic is also issued for placement new expressions that construct
--- 4334,4354 ----
  .Sp
  This warning is enabled by default.
  .RS 4
! .IP \fB\-Wplacement\-new=1\fR 4
  .IX Item "-Wplacement-new=1"
  This is the default warning level of \fB\-Wplacement\-new\fR.  At this
  level the warning is not issued for some strictly undefined constructs that
! GCC allows as extensions for compatibility with legacy code.  For example,
  the following \f(CW\*(C`new\*(C'\fR expression is not diagnosed at this level even
! though it has undefined behavior according to the C++ standard because
! it writes past the end of the one\-element array.
  .Sp
  .Vb 3
  \&        struct S { int n, a[1]; };
  \&        S *s = (S *)malloc (sizeof *s + 31 * sizeof s\->a[0]);
  \&        new (s\->a)int [32]();
  .Ve
! .IP \fB\-Wplacement\-new=2\fR 4
  .IX Item "-Wplacement-new=2"
  At this level, in addition to diagnosing all the same constructs as at level
  1, a diagnostic is also issued for placement new expressions that construct
*************** use of the flexible member array extensi
*** 4436,4446 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wcatch\-value\fR" 4
  .IX Item "-Wcatch-value"
  .PD 0
! .IP "\fB\-Wcatch\-value=\fR\fIn\fR\fB \fR(\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wcatch-value=n ( and Objective- only)"
  .PD
  Warn about catch handlers that do not catch via reference.
  With \fB\-Wcatch\-value=1\fR (or \fB\-Wcatch\-value\fR for short)
--- 4365,4375 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wcatch\-value\fR 4
  .IX Item "-Wcatch-value"
  .PD 0
! .IP "\fB\-Wcatch\-value=\fR\fIn\fR\fB \fR(C++ and Objective\-C++ only)" 4
! .IX Item "-Wcatch-value=n (C++ and Objective-C++ only)"
  .PD
  Warn about catch handlers that do not catch via reference.
  With \fB\-Wcatch\-value=1\fR (or \fB\-Wcatch\-value\fR for short)
*************** warn about polymorphic class types that
*** 4448,4465 ****
  With \fB\-Wcatch\-value=2\fR warn about all class types that are caught
  by value. With \fB\-Wcatch\-value=3\fR warn about all types that are
  not caught by reference. \fB\-Wcatch\-value\fR is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wconditionally\-supported\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wconditionally-supported ( and Objective- only)"
! Warn for conditionally-supported (\*(C+11 [intro.defs]) constructs.
! .IP "\fB\-Wno\-delete\-incomplete\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-delete-incomplete ( and Objective- only)"
  Do not warn when deleting a pointer to incomplete type, which may cause
  undefined behavior at runtime.  This warning is enabled by default.
! .IP "\fB\-Wextra\-semi\fR (\*(C+, Objective\-\*(C+ only)" 4
! .IX Item "-Wextra-semi (, Objective- only)"
! Warn about redundant semicolons after in-class function definitions.
! .IP "\fB\-Wno\-inaccessible\-base\fR (\*(C+, Objective\-\*(C+ only)" 4
! .IX Item "-Wno-inaccessible-base (, Objective- only)"
  This option controls warnings
  when a base class is inaccessible in a class derived from it due to
  ambiguity.  The warning is enabled by default.
--- 4377,4394 ----
  With \fB\-Wcatch\-value=2\fR warn about all class types that are caught
  by value. With \fB\-Wcatch\-value=3\fR warn about all types that are
  not caught by reference. \fB\-Wcatch\-value\fR is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wconditionally\-supported\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wconditionally-supported (C++ and Objective-C++ only)"
! Warn for conditionally\-supported (C++11 [intro.defs]) constructs.
! .IP "\fB\-Wno\-delete\-incomplete\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-delete-incomplete (C++ and Objective-C++ only)"
  Do not warn when deleting a pointer to incomplete type, which may cause
  undefined behavior at runtime.  This warning is enabled by default.
! .IP "\fB\-Wextra\-semi\fR (C++, Objective\-C++ only)" 4
! .IX Item "-Wextra-semi (C++, Objective-C++ only)"
! Warn about redundant semicolons after in\-class function definitions.
! .IP "\fB\-Wno\-inaccessible\-base\fR (C++, Objective\-C++ only)" 4
! .IX Item "-Wno-inaccessible-base (C++, Objective-C++ only)"
  This option controls warnings
  when a base class is inaccessible in a class derived from it due to
  ambiguity.  The warning is enabled by default.
*************** bases is enabled by the \fB\-Wextra\fR o
*** 4473,4497 ****
  \&        
  \&        struct C : B, A { };
  .Ve
! .IP "\fB\-Wno\-inherited\-variadic\-ctor\fR" 4
  .IX Item "-Wno-inherited-variadic-ctor"
! Suppress warnings about use of \*(C+11 inheriting constructors when the
  base class inherited from has a C variadic constructor; the warning is
  on by default because the ellipsis is not inherited.
! .IP "\fB\-Wno\-invalid\-offsetof\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-invalid-offsetof ( and Objective- only)"
! Suppress warnings from applying the \f(CW\*(C`offsetof\*(C'\fR macro to a non-POD
! type.  According to the 2014 \s-1ISO \*(C+\s0 standard, applying \f(CW\*(C`offsetof\*(C'\fR
! to a non-standard-layout type is undefined.  In existing \*(C+ implementations,
  however, \f(CW\*(C`offsetof\*(C'\fR typically gives meaningful results.
  This flag is for users who are aware that they are
  writing nonportable code and who have deliberately chosen to ignore the
  warning about it.
  .Sp
  The restrictions on \f(CW\*(C`offsetof\*(C'\fR may be relaxed in a future version
! of the \*(C+ standard.
! .IP "\fB\-Wsized\-deallocation\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wsized-deallocation ( and Objective- only)"
  Warn about a definition of an unsized deallocation function
  .Sp
  .Vb 2
--- 4402,4426 ----
  \&        
  \&        struct C : B, A { };
  .Ve
! .IP \fB\-Wno\-inherited\-variadic\-ctor\fR 4
  .IX Item "-Wno-inherited-variadic-ctor"
! Suppress warnings about use of C++11 inheriting constructors when the
  base class inherited from has a C variadic constructor; the warning is
  on by default because the ellipsis is not inherited.
! .IP "\fB\-Wno\-invalid\-offsetof\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-invalid-offsetof (C++ and Objective-C++ only)"
! Suppress warnings from applying the \f(CW\*(C`offsetof\*(C'\fR macro to a non\-POD
! type.  According to the 2014 ISO C++ standard, applying \f(CW\*(C`offsetof\*(C'\fR
! to a non\-standard\-layout type is undefined.  In existing C++ implementations,
  however, \f(CW\*(C`offsetof\*(C'\fR typically gives meaningful results.
  This flag is for users who are aware that they are
  writing nonportable code and who have deliberately chosen to ignore the
  warning about it.
  .Sp
  The restrictions on \f(CW\*(C`offsetof\*(C'\fR may be relaxed in a future version
! of the C++ standard.
! .IP "\fB\-Wsized\-deallocation\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wsized-deallocation (C++ and Objective-C++ only)"
  Warn about a definition of an unsized deallocation function
  .Sp
  .Vb 2
*************** without a definition of the correspondin
*** 4508,4542 ****
  .Sp
  or vice versa.  Enabled by \fB\-Wextra\fR along with
  \&\fB\-fsized\-deallocation\fR.
! .IP "\fB\-Wsuggest\-final\-types\fR" 4
  .IX Item "-Wsuggest-final-types"
  Warn about types with virtual methods where code quality would be improved
! if the type were declared with the \*(C+11 \f(CW\*(C`final\*(C'\fR specifier,
  or, if possible,
! declared in an anonymous namespace. This allows \s-1GCC\s0 to more aggressively
  devirtualize the polymorphic calls. This warning is more effective with
! link-time optimization,
  where the information about the class hierarchy graph is
  more complete.
! .IP "\fB\-Wsuggest\-final\-methods\fR" 4
  .IX Item "-Wsuggest-final-methods"
  Warn about virtual methods where code quality would be improved if the method
! were declared with the \*(C+11 \f(CW\*(C`final\*(C'\fR specifier,
  or, if possible, its type were
  declared in an anonymous namespace or with the \f(CW\*(C`final\*(C'\fR specifier.
  This warning is
! more effective with link-time optimization, where the information about the
  class hierarchy graph is more complete. It is recommended to first consider
  suggestions of \fB\-Wsuggest\-final\-types\fR and then rebuild with new
  annotations.
! .IP "\fB\-Wsuggest\-override\fR" 4
  .IX Item "-Wsuggest-override"
  Warn about overriding virtual functions that are not marked with the
  \&\f(CW\*(C`override\*(C'\fR keyword.
! .IP "\fB\-Wuse\-after\-free\fR" 4
  .IX Item "-Wuse-after-free"
  .PD 0
! .IP "\fB\-Wuse\-after\-free=\fR\fIn\fR" 4
  .IX Item "-Wuse-after-free=n"
  .PD
  Warn about uses of pointers to dynamically allocated objects that have
--- 4437,4471 ----
  .Sp
  or vice versa.  Enabled by \fB\-Wextra\fR along with
  \&\fB\-fsized\-deallocation\fR.
! .IP \fB\-Wsuggest\-final\-types\fR 4
  .IX Item "-Wsuggest-final-types"
  Warn about types with virtual methods where code quality would be improved
! if the type were declared with the C++11 \f(CW\*(C`final\*(C'\fR specifier,
  or, if possible,
! declared in an anonymous namespace. This allows GCC to more aggressively
  devirtualize the polymorphic calls. This warning is more effective with
! link\-time optimization,
  where the information about the class hierarchy graph is
  more complete.
! .IP \fB\-Wsuggest\-final\-methods\fR 4
  .IX Item "-Wsuggest-final-methods"
  Warn about virtual methods where code quality would be improved if the method
! were declared with the C++11 \f(CW\*(C`final\*(C'\fR specifier,
  or, if possible, its type were
  declared in an anonymous namespace or with the \f(CW\*(C`final\*(C'\fR specifier.
  This warning is
! more effective with link\-time optimization, where the information about the
  class hierarchy graph is more complete. It is recommended to first consider
  suggestions of \fB\-Wsuggest\-final\-types\fR and then rebuild with new
  annotations.
! .IP \fB\-Wsuggest\-override\fR 4
  .IX Item "-Wsuggest-override"
  Warn about overriding virtual functions that are not marked with the
  \&\f(CW\*(C`override\*(C'\fR keyword.
! .IP \fB\-Wuse\-after\-free\fR 4
  .IX Item "-Wuse-after-free"
  .PD 0
! .IP \fB\-Wuse\-after\-free=\fR\fIn\fR 4
  .IX Item "-Wuse-after-free=n"
  .PD
  Warn about uses of pointers to dynamically allocated objects that have
*************** been rendered indeterminate by a call to
*** 4544,4550 ****
  The warning is enabled at all optimization levels but may yield different
  results with optimization than without.
  .RS 4
! .IP "\fB\-Wuse\-after\-free=1\fR" 4
  .IX Item "-Wuse-after-free=1"
  At level 1 the warning attempts to diagnose only unconditional uses
  of pointers made indeterminate by a deallocation call or a successful
--- 4473,4479 ----
  The warning is enabled at all optimization levels but may yield different
  results with optimization than without.
  .RS 4
! .IP \fB\-Wuse\-after\-free=1\fR 4
  .IX Item "-Wuse-after-free=1"
  At level 1 the warning attempts to diagnose only unconditional uses
  of pointers made indeterminate by a deallocation call or a successful
*************** in an actual reallocatio of memory.  Thi
*** 4553,4559 ****
  calls as well as uses in arithmetic and relational expressions.  Although
  undefined, uses of indeterminate pointers in equality (or inequality)
  expressions are not diagnosed at this level.
! .IP "\fB\-Wuse\-after\-free=2\fR" 4
  .IX Item "-Wuse-after-free=2"
  At level 2, in addition to unconditional uses, the warning also diagnoses
  conditional uses of pointers made indeterminate by a deallocation call.
--- 4482,4488 ----
  calls as well as uses in arithmetic and relational expressions.  Although
  undefined, uses of indeterminate pointers in equality (or inequality)
  expressions are not diagnosed at this level.
! .IP \fB\-Wuse\-after\-free=2\fR 4
  .IX Item "-Wuse-after-free=2"
  At level 2, in addition to unconditional uses, the warning also diagnoses
  conditional uses of pointers made indeterminate by a deallocation call.
*************** function is diagnosed at this level:
*** 4572,4578 ****
  \&            free (p\->data);   // warning: p may be used after free
  \&        }
  .Ve
! .IP "\fB\-Wuse\-after\-free=3\fR" 4
  .IX Item "-Wuse-after-free=3"
  At level 3, the warning also diagnoses uses of indeterminate pointers in
  equality expressions.  All uses of indeterminate pointers are undefined
--- 4501,4507 ----
  \&            free (p\->data);   // warning: p may be used after free
  \&        }
  .Ve
! .IP \fB\-Wuse\-after\-free=3\fR 4
  .IX Item "-Wuse-after-free=3"
  At level 3, the warning also diagnoses uses of indeterminate pointers in
  equality expressions.  All uses of indeterminate pointers are undefined
*************** pointers after reallocation.
*** 4602,4611 ****
  .Sp
  \&\fB\-Wuse\-after\-free=2\fR is included in \fB\-Wall\fR.
  .RE
! .IP "\fB\-Wuseless\-cast\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wuseless-cast ( and Objective- only)"
  Warn when an expression is cast to its own type.  This warning does not
! occur when a class object is converted to a non-reference type as that
  is a way to create a temporary:
  .Sp
  .Vb 6
--- 4531,4540 ----
  .Sp
  \&\fB\-Wuse\-after\-free=2\fR is included in \fB\-Wall\fR.
  .RE
! .IP "\fB\-Wuseless\-cast\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wuseless-cast (C++ and Objective-C++ only)"
  Warn when an expression is cast to its own type.  This warning does not
! occur when a class object is converted to a non\-reference type as that
  is a way to create a temporary:
  .Sp
  .Vb 6
*************** is a way to create a temporary:
*** 4616,4633 ****
  \&          g (S(arg)); // make arg prvalue so that it can bind to S&&
  \&        }
  .Ve
! .IP "\fB\-Wno\-conversion\-null\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-conversion-null ( and Objective- only)"
! Do not warn for conversions between \f(CW\*(C`NULL\*(C'\fR and non-pointer
  types. \fB\-Wconversion\-null\fR is enabled by default.
! .SS "Options Controlling Objective-C and Objective\-\*(C+ Dialects"
! .IX Subsection "Options Controlling Objective-C and Objective- Dialects"
! (\s-1NOTE:\s0 This manual does not describe the Objective-C and Objective\-\*(C+
  languages themselves.
  .PP
! This section describes the command-line options that are only meaningful
! for Objective-C and Objective\-\*(C+ programs.  You can also use most of
! the language-independent \s-1GNU\s0 compiler options.
  For example, you might compile a file \fIsome_class.m\fR like this:
  .PP
  .Vb 1
--- 4545,4562 ----
  \&          g (S(arg)); // make arg prvalue so that it can bind to S&&
  \&        }
  .Ve
! .IP "\fB\-Wno\-conversion\-null\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-conversion-null (C++ and Objective-C++ only)"
! Do not warn for conversions between \f(CW\*(C`NULL\*(C'\fR and non\-pointer
  types. \fB\-Wconversion\-null\fR is enabled by default.
! .SS "Options Controlling Objective\-C and Objective\-C++ Dialects"
! .IX Subsection "Options Controlling Objective-C and Objective-C++ Dialects"
! (NOTE: This manual does not describe the Objective\-C and Objective\-C++
  languages themselves.
  .PP
! This section describes the command\-line options that are only meaningful
! for Objective\-C and Objective\-C++ programs.  You can also use most of
! the language\-independent GNU compiler options.
  For example, you might compile a file \fIsome_class.m\fR like this:
  .PP
  .Vb 1
*************** For example, you might compile a file \f
*** 4635,4798 ****
  .Ve
  .PP
  In this example, \fB\-fgnu\-runtime\fR is an option meant only for
! Objective-C and Objective\-\*(C+ programs; you can use the other options with
! any language supported by \s-1GCC.\s0
  .PP
! Note that since Objective-C is an extension of the C language, Objective-C
! compilations may also use options specific to the C front-end (e.g.,
! \&\fB\-Wtraditional\fR).  Similarly, Objective\-\*(C+ compilations may use
! \&\*(C+\-specific options (e.g., \fB\-Wabi\fR).
  .PP
! Here is a list of options that are \fIonly\fR for compiling Objective-C
! and Objective\-\*(C+ programs:
! .IP "\fB\-fconstant\-string\-class=\fR\fIclass-name\fR" 4
  .IX Item "-fconstant-string-class=class-name"
! Use \fIclass-name\fR as the name of the class to instantiate for each
  literal string specified with the syntax \f(CW\*(C`@"..."\*(C'\fR.  The default
! class name is \f(CW\*(C`NXConstantString\*(C'\fR if the \s-1GNU\s0 runtime is being used, and
  \&\f(CW\*(C`NSConstantString\*(C'\fR if the NeXT runtime is being used (see below).  On
  Darwin (macOS, MacOS X) platforms, the \fB\-fconstant\-cfstrings\fR option, if
  also present, overrides the \fB\-fconstant\-string\-class\fR setting and cause
  \&\f(CW\*(C`@"..."\*(C'\fR literals to be laid out as constant CoreFoundation strings.
! Note that \fB\-fconstant\-cfstrings\fR is an alias for the target-specific
  \&\fB\-mconstant\-cfstrings\fR equivalent.
! .IP "\fB\-fgnu\-runtime\fR" 4
  .IX Item "-fgnu-runtime"
! Generate object code compatible with the standard \s-1GNU\s0 Objective-C
  runtime.  This is the default for most types of systems.
! .IP "\fB\-fnext\-runtime\fR" 4
  .IX Item "-fnext-runtime"
  Generate output compatible with the NeXT runtime.  This is the default
! for NeXT-based systems, including Darwin and Mac \s-1OS X.\s0  The macro
  \&\f(CW\*(C`_\|_NEXT_RUNTIME_\|_\*(C'\fR is predefined if (and only if) this option is
  used.
! .IP "\fB\-fno\-nil\-receivers\fR" 4
  .IX Item "-fno-nil-receivers"
! Assume that all Objective-C message dispatches (\f(CW\*(C`[receiver
  message:arg]\*(C'\fR) in this translation unit ensure that the receiver is
  not \f(CW\*(C`nil\*(C'\fR.  This allows for more efficient entry points in the
  runtime to be used.  This option is only available in conjunction with
! the NeXT runtime and \s-1ABI\s0 version 0 or 1.
! .IP "\fB\-fobjc\-abi\-version=\fR\fIn\fR" 4
  .IX Item "-fobjc-abi-version=n"
! Use version \fIn\fR of the Objective-C \s-1ABI\s0 for the selected runtime.
  This option is currently supported only for the NeXT runtime.  In that
! case, Version 0 is the traditional (32\-bit) \s-1ABI\s0 without support for
! properties and other Objective-C 2.0 additions.  Version 1 is the
! traditional (32\-bit) \s-1ABI\s0 with support for properties and other
! Objective-C 2.0 additions.  Version 2 is the modern (64\-bit) \s-1ABI.\s0  If
  nothing is specified, the default is Version 0 on 32\-bit target
  machines, and Version 2 on 64\-bit target machines.
! .IP "\fB\-fobjc\-call\-cxx\-cdtors\fR" 4
  .IX Item "-fobjc-call-cxx-cdtors"
! For each Objective-C class, check if any of its instance variables is a
! \&\*(C+ object with a non-trivial default constructor.  If so, synthesize a
  special \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR instance method which runs
! non-trivial default constructors on any such instance variables, in order,
  and then return \f(CW\*(C`self\*(C'\fR.  Similarly, check if any instance variable
! is a \*(C+ object with a non-trivial destructor, and if so, synthesize a
  special \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR method which runs
  all such default destructors, in reverse order.
  .Sp
  The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR
  methods thusly generated only operate on instance variables
! declared in the current Objective-C class, and not those inherited
! from superclasses.  It is the responsibility of the Objective-C
! runtime to invoke all such methods in an object's inheritance
  hierarchy.  The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR methods are invoked
  by the runtime immediately after a new object instance is allocated;
  the \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods are invoked immediately
  before the runtime deallocates an object instance.
  .Sp
! As of this writing, only the NeXT runtime on Mac \s-1OS X 10.4\s0 and later has
  support for invoking the \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and
  \&\f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods.
! .IP "\fB\-fobjc\-direct\-dispatch\fR" 4
  .IX Item "-fobjc-direct-dispatch"
  Allow fast jumps to the message dispatcher.  On Darwin this is
  accomplished via the comm page.
! .IP "\fB\-fobjc\-exceptions\fR" 4
  .IX Item "-fobjc-exceptions"
  Enable syntactic support for structured exception handling in
! Objective-C, similar to what is offered by \*(C+.  This option
! is required to use the Objective-C keywords \f(CW@try\fR,
  \&\f(CW@throw\fR, \f(CW@catch\fR, \f(CW@finally\fR and
! \&\f(CW@synchronized\fR.  This option is available with both the \s-1GNU\s0
  runtime and the NeXT runtime (but not available in conjunction with
! the NeXT runtime on Mac \s-1OS X 10.2\s0 and earlier).
! .IP "\fB\-fobjc\-gc\fR" 4
  .IX Item "-fobjc-gc"
! Enable garbage collection (\s-1GC\s0) in Objective-C and Objective\-\*(C+
  programs.  This option is only available with the NeXT runtime; the
! \&\s-1GNU\s0 runtime has a different garbage collection implementation that
  does not require special compiler flags.
! .IP "\fB\-fobjc\-nilcheck\fR" 4
  .IX Item "-fobjc-nilcheck"
! For the NeXT runtime with version 2 of the \s-1ABI,\s0 check for a nil
  receiver in method invocations before doing the actual method call.
  This is the default and can be disabled using
  \&\fB\-fno\-objc\-nilcheck\fR.  Class methods and super calls are never
  checked for nil in this way no matter what this flag is set to.
! Currently this flag does nothing when the \s-1GNU\s0 runtime, or an older
! version of the NeXT runtime \s-1ABI,\s0 is used.
! .IP "\fB\-fobjc\-std=objc1\fR" 4
  .IX Item "-fobjc-std=objc1"
! Conform to the language syntax of Objective-C 1.0, the language
! recognized by \s-1GCC 4.0.\s0  This only affects the Objective-C additions to
! the C/\*(C+ language; it does not affect conformance to C/\*(C+ standards,
! which is controlled by the separate C/\*(C+ dialect option flags.  When
! this option is used with the Objective-C or Objective\-\*(C+ compiler,
! any Objective-C syntax that is not recognized by \s-1GCC 4.0\s0 is rejected.
! This is useful if you need to make sure that your Objective-C code can
! be compiled with older versions of \s-1GCC.\s0
! .IP "\fB\-freplace\-objc\-classes\fR" 4
  .IX Item "-freplace-objc-classes"
! Emit a special marker instructing \fB\fBld\fB\|(1)\fR not to statically link in
! the resulting object file, and allow \fB\fBdyld\fB\|(1)\fR to load it in at
! run time instead.  This is used in conjunction with the Fix-and-Continue
  debugging mode, where the object file in question may be recompiled and
  dynamically reloaded in the course of program execution, without the need
! to restart the program itself.  Currently, Fix-and-Continue functionality
! is only available in conjunction with the NeXT runtime on Mac \s-1OS X 10.3\s0
  and later.
! .IP "\fB\-fzero\-link\fR" 4
  .IX Item "-fzero-link"
  When compiling for the NeXT runtime, the compiler ordinarily replaces calls
! to \f(CW\*(C`objc_getClass("...")\*(C'\fR (when the name of the class is known at
  compile time) with static class references that get initialized at load time,
! which improves run-time performance.  Specifying the \fB\-fzero\-link\fR flag
! suppresses this behavior and causes calls to \f(CW\*(C`objc_getClass("...")\*(C'\fR
! to be retained.  This is useful in Zero-Link debugging mode, since it allows
  for individual class implementations to be modified during program execution.
! The \s-1GNU\s0 runtime currently always retains calls to \f(CW\*(C`objc_get_class("...")\*(C'\fR
! regardless of command-line options.
! .IP "\fB\-fno\-local\-ivars\fR" 4
  .IX Item "-fno-local-ivars"
! By default instance variables in Objective-C can be accessed as if
! they were local variables from within the methods of the class they're
  declared in.  This can lead to shadowing between instance variables
  and other variables declared either locally inside a class method or
  globally with the same name.  Specifying the \fB\-fno\-local\-ivars\fR
  flag disables this behavior thus avoiding variable shadowing issues.
! .IP "\fB\-fivar\-visibility=\fR[\fBpublic\fR|\fBprotected\fR|\fBprivate\fR|\fBpackage\fR]" 4
  .IX Item "-fivar-visibility=[public|protected|private|package]"
  Set the default instance variable visibility to the specified option
  so that instance variables declared outside the scope of any access
  modifier directives default to the specified visibility.
! .IP "\fB\-gen\-decls\fR" 4
  .IX Item "-gen-decls"
  Dump interface declarations for all classes seen in the source file to a
! file named \fI\fIsourcename\fI.decl\fR.
! .IP "\fB\-Wassign\-intercept\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wassign-intercept (Objective-C and Objective- only)"
! Warn whenever an Objective-C assignment is being intercepted by the
  garbage collector.
! .IP "\fB\-Wno\-property\-assign\-default\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-property-assign-default (Objective-C and Objective- only)"
! Do not warn if a property for an Objective-C object has no assign
  semantics specified.
! .IP "\fB\-Wno\-protocol\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-protocol (Objective-C and Objective- only)"
  If a class is declared to implement a protocol, a warning is issued for
  every method in the protocol that is not implemented by the class.  The
  default behavior is to issue a warning for every method not explicitly
--- 4564,4727 ----
  .Ve
  .PP
  In this example, \fB\-fgnu\-runtime\fR is an option meant only for
! Objective\-C and Objective\-C++ programs; you can use the other options with
! any language supported by GCC.
  .PP
! Note that since Objective\-C is an extension of the C language, Objective\-C
! compilations may also use options specific to the C front\-end (e.g.,
! \&\fB\-Wtraditional\fR).  Similarly, Objective\-C++ compilations may use
! C++\-specific options (e.g., \fB\-Wabi\fR).
  .PP
! Here is a list of options that are \fIonly\fR for compiling Objective\-C
! and Objective\-C++ programs:
! .IP \fB\-fconstant\-string\-class=\fR\fIclass\-name\fR 4
  .IX Item "-fconstant-string-class=class-name"
! Use \fIclass\-name\fR as the name of the class to instantiate for each
  literal string specified with the syntax \f(CW\*(C`@"..."\*(C'\fR.  The default
! class name is \f(CW\*(C`NXConstantString\*(C'\fR if the GNU runtime is being used, and
  \&\f(CW\*(C`NSConstantString\*(C'\fR if the NeXT runtime is being used (see below).  On
  Darwin (macOS, MacOS X) platforms, the \fB\-fconstant\-cfstrings\fR option, if
  also present, overrides the \fB\-fconstant\-string\-class\fR setting and cause
  \&\f(CW\*(C`@"..."\*(C'\fR literals to be laid out as constant CoreFoundation strings.
! Note that \fB\-fconstant\-cfstrings\fR is an alias for the target\-specific
  \&\fB\-mconstant\-cfstrings\fR equivalent.
! .IP \fB\-fgnu\-runtime\fR 4
  .IX Item "-fgnu-runtime"
! Generate object code compatible with the standard GNU Objective\-C
  runtime.  This is the default for most types of systems.
! .IP \fB\-fnext\-runtime\fR 4
  .IX Item "-fnext-runtime"
  Generate output compatible with the NeXT runtime.  This is the default
! for NeXT\-based systems, including Darwin and Mac OS X.  The macro
  \&\f(CW\*(C`_\|_NEXT_RUNTIME_\|_\*(C'\fR is predefined if (and only if) this option is
  used.
! .IP \fB\-fno\-nil\-receivers\fR 4
  .IX Item "-fno-nil-receivers"
! Assume that all Objective\-C message dispatches (\f(CW\*(C`[receiver
  message:arg]\*(C'\fR) in this translation unit ensure that the receiver is
  not \f(CW\*(C`nil\*(C'\fR.  This allows for more efficient entry points in the
  runtime to be used.  This option is only available in conjunction with
! the NeXT runtime and ABI version 0 or 1.
! .IP \fB\-fobjc\-abi\-version=\fR\fIn\fR 4
  .IX Item "-fobjc-abi-version=n"
! Use version \fIn\fR of the Objective\-C 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.
! .IP \fB\-fobjc\-call\-cxx\-cdtors\fR 4
  .IX Item "-fobjc-call-cxx-cdtors"
! For each Objective\-C class, check if any of its instance variables is a
! C++ object with a non\-trivial default constructor.  If so, synthesize a
  special \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR instance method which runs
! non\-trivial default constructors on any such instance variables, in order,
  and then return \f(CW\*(C`self\*(C'\fR.  Similarly, check if any instance variable
! is a C++ object with a non\-trivial destructor, and if so, synthesize a
  special \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR method which runs
  all such default destructors, in reverse order.
  .Sp
  The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR
  methods thusly generated only operate on instance variables
! declared in the current Objective\-C class, and not those inherited
! from superclasses.  It is the responsibility of the Objective\-C
! runtime to invoke all such methods in an object\*(Aqs inheritance
  hierarchy.  The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR methods are invoked
  by the runtime immediately after a new object instance is allocated;
  the \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods are invoked immediately
  before the runtime deallocates an object instance.
  .Sp
! As of this writing, only the NeXT runtime on Mac OS X 10.4 and later has
  support for invoking the \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and
  \&\f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods.
! .IP \fB\-fobjc\-direct\-dispatch\fR 4
  .IX Item "-fobjc-direct-dispatch"
  Allow fast jumps to the message dispatcher.  On Darwin this is
  accomplished via the comm page.
! .IP \fB\-fobjc\-exceptions\fR 4
  .IX Item "-fobjc-exceptions"
  Enable syntactic support for structured exception handling in
! Objective\-C, similar to what is offered by C++.  This option
! is required to use the Objective\-C keywords \f(CW@try\fR,
  \&\f(CW@throw\fR, \f(CW@catch\fR, \f(CW@finally\fR and
! \&\f(CW@synchronized\fR.  This option is available with both the GNU
  runtime and the NeXT runtime (but not available in conjunction with
! the NeXT runtime on Mac OS X 10.2 and earlier).
! .IP \fB\-fobjc\-gc\fR 4
  .IX Item "-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.
! .IP \fB\-fobjc\-nilcheck\fR 4
  .IX Item "-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
  \&\fB\-fno\-objc\-nilcheck\fR.  Class methods and super calls are never
  checked for nil in this way no matter what this flag is set to.
! Currently this flag does nothing when the GNU runtime, or an older
! version of the NeXT runtime ABI, is used.
! .IP \fB\-fobjc\-std=objc1\fR 4
  .IX Item "-fobjc-std=objc1"
! Conform to the language syntax of Objective\-C 1.0, the language
! recognized by 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.
! .IP \fB\-freplace\-objc\-classes\fR 4
  .IX Item "-freplace-objc-classes"
! Emit a special marker instructing \fBld\|(1)\fR not to statically link in
! the resulting object file, and allow \fBdyld\|(1)\fR to load it in at
! run time instead.  This is used in conjunction with the Fix\-and\-Continue
  debugging mode, where the object file in question may be recompiled and
  dynamically reloaded in the course of program execution, without the need
! to restart the program itself.  Currently, Fix\-and\-Continue functionality
! is only available in conjunction with the NeXT runtime on Mac OS X 10.3
  and later.
! .IP \fB\-fzero\-link\fR 4
  .IX Item "-fzero-link"
  When compiling for the NeXT runtime, the compiler ordinarily replaces calls
! to \f(CWobjc_getClass("...")\fR (when the name of the class is known at
  compile time) with static class references that get initialized at load time,
! which improves run\-time performance.  Specifying the \fB\-fzero\-link\fR flag
! suppresses this behavior and causes calls to \f(CWobjc_getClass("...")\fR
! to be retained.  This is useful in Zero\-Link debugging mode, since it allows
  for individual class implementations to be modified during program execution.
! The GNU runtime currently always retains calls to \f(CWobjc_get_class("...")\fR
! regardless of command\-line options.
! .IP \fB\-fno\-local\-ivars\fR 4
  .IX Item "-fno-local-ivars"
! By default instance variables in Objective\-C can be accessed as if
! they were local variables from within the methods of the class they\*(Aqre
  declared in.  This can lead to shadowing between instance variables
  and other variables declared either locally inside a class method or
  globally with the same name.  Specifying the \fB\-fno\-local\-ivars\fR
  flag disables this behavior thus avoiding variable shadowing issues.
! .IP \fB\-fivar\-visibility=\fR[\fBpublic\fR|\fBprotected\fR|\fBprivate\fR|\fBpackage\fR] 4
  .IX Item "-fivar-visibility=[public|protected|private|package]"
  Set the default instance variable visibility to the specified option
  so that instance variables declared outside the scope of any access
  modifier directives default to the specified visibility.
! .IP \fB\-gen\-decls\fR 4
  .IX Item "-gen-decls"
  Dump interface declarations for all classes seen in the source file to a
! file named \fIsourcename.decl\fR.
! .IP "\fB\-Wassign\-intercept\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wassign-intercept (Objective-C and Objective-C++ only)"
! Warn whenever an Objective\-C assignment is being intercepted by the
  garbage collector.
! .IP "\fB\-Wno\-property\-assign\-default\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wno-property-assign-default (Objective-C and Objective-C++ only)"
! Do not warn if a property for an Objective\-C object has no assign
  semantics specified.
! .IP "\fB\-Wno\-protocol\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-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 meth
*** 4800,4868 ****
  from the superclass.  If you use the \fB\-Wno\-protocol\fR option, then
  methods inherited from the superclass are considered to be implemented,
  and no warning is issued for them.
! .IP "\fB\-Wobjc\-root\-class\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wobjc-root-class (Objective-C and Objective- only)"
  Warn if a class interface lacks a superclass. Most classes will inherit
  from \f(CW\*(C`NSObject\*(C'\fR (or \f(CW\*(C`Object\*(C'\fR) for example.  When declaring
  classes intended to be root classes, the warning can be suppressed by
  marking their interfaces with \f(CW\*(C`_\|_attribute_\|_((objc_root_class))\*(C'\fR.
! .IP "\fB\-Wselector\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wselector (Objective-C and Objective- only)"
  Warn if multiple methods of different types for the same selector are
  found during compilation.  The check is performed on the list of methods
  in the final stage of compilation.  Additionally, a check is performed
! for each selector appearing in a \f(CW\*(C`@selector(...)\*(C'\fR
  expression, and a corresponding method for that selector has been found
  during compilation.  Because these checks scan the method table only at
  the end of compilation, these warnings are not produced if the final
  stage of compilation is not reached, for example because an error is
  found during compilation, or because the \fB\-fsyntax\-only\fR option is
  being used.
! .IP "\fB\-Wstrict\-selector\-match\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wstrict-selector-match (Objective-C and Objective- only)"
  Warn if multiple methods with differing argument and/or return types are
  found for a given selector when attempting to send a message using this
  selector to a receiver of type \f(CW\*(C`id\*(C'\fR or \f(CW\*(C`Class\*(C'\fR.  When this flag
  is off (which is the default behavior), the compiler omits such warnings
  if any differences found are confined to types that share the same size
  and alignment.
! .IP "\fB\-Wundeclared\-selector\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wundeclared-selector (Objective-C and Objective- only)"
! Warn if a \f(CW\*(C`@selector(...)\*(C'\fR expression referring to an
  undeclared selector is found.  A selector is considered undeclared if no
  method with that name has been declared before the
! \&\f(CW\*(C`@selector(...)\*(C'\fR expression, either explicitly in an
  \&\f(CW@interface\fR or \f(CW@protocol\fR declaration, or implicitly in
  an \f(CW@implementation\fR section.  This option always performs its
! checks as soon as a \f(CW\*(C`@selector(...)\*(C'\fR expression is found,
  while \fB\-Wselector\fR only performs its checks in the final stage of
  compilation.  This also enforces the coding style convention
  that methods and selectors must be declared before being used.
! .IP "\fB\-print\-objc\-runtime\-info\fR" 4
  .IX Item "-print-objc-runtime-info"
  Generate C header describing the largest structure that is passed by
  value, if any.
  .SS "Options to Control Diagnostic Messages Formatting"
  .IX Subsection "Options to Control Diagnostic Messages Formatting"
  Traditionally, diagnostic messages have been formatted irrespective of
! the output device's aspect (e.g. its width, ...).  You can use the
  options described below
  to control the formatting algorithm for diagnostic messages, 
  e.g. how many characters per line, how often source location
  information should be reported.  Note that some language front ends may not
  honor these options.
! .IP "\fB\-fmessage\-length=\fR\fIn\fR" 4
  .IX Item "-fmessage-length=n"
  Try to format error messages so that they fit on lines of about
! \&\fIn\fR characters.  If \fIn\fR is zero, then no line-wrapping is
  done; each error message appears on a single line.  This is the
  default for all front ends.
  .Sp
  Note \- this option also affects the display of the \fB#error\fR and
! \&\fB#warning\fR pre-processor directives, and the \fBdeprecated\fR
  function/type/variable attribute.  It does not however affect the
! \&\fBpragma \s-1GCC\s0 warning\fR and \fBpragma \s-1GCC\s0 error\fR pragmas.
! .IP "\fB\-fdiagnostics\-plain\-output\fR" 4
  .IX Item "-fdiagnostics-plain-output"
  This option requests that diagnostic output look as plain as possible, which
  may be useful when running \fBdejagnu\fR or other utilities that need to
--- 4729,4797 ----
  from the superclass.  If you use the \fB\-Wno\-protocol\fR option, then
  methods inherited from the superclass are considered to be implemented,
  and no warning is issued for them.
! .IP "\fB\-Wobjc\-root\-class\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wobjc-root-class (Objective-C and Objective-C++ only)"
  Warn if a class interface lacks a superclass. Most classes will inherit
  from \f(CW\*(C`NSObject\*(C'\fR (or \f(CW\*(C`Object\*(C'\fR) for example.  When declaring
  classes intended to be root classes, the warning can be suppressed by
  marking their interfaces with \f(CW\*(C`_\|_attribute_\|_((objc_root_class))\*(C'\fR.
! .IP "\fB\-Wselector\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-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 \f(CW@selector(...)\fR
  expression, and a corresponding method for that selector has been found
  during compilation.  Because these checks scan the method table only at
  the end of compilation, these warnings are not produced if the final
  stage of compilation is not reached, for example because an error is
  found during compilation, or because the \fB\-fsyntax\-only\fR option is
  being used.
! .IP "\fB\-Wstrict\-selector\-match\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wstrict-selector-match (Objective-C and Objective-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 \f(CW\*(C`id\*(C'\fR or \f(CW\*(C`Class\*(C'\fR.  When this flag
  is off (which is the default behavior), the compiler omits such warnings
  if any differences found are confined to types that share the same size
  and alignment.
! .IP "\fB\-Wundeclared\-selector\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wundeclared-selector (Objective-C and Objective-C++ only)"
! Warn if a \f(CW@selector(...)\fR expression referring to an
  undeclared selector is found.  A selector is considered undeclared if no
  method with that name has been declared before the
! \&\f(CW@selector(...)\fR expression, either explicitly in an
  \&\f(CW@interface\fR or \f(CW@protocol\fR declaration, or implicitly in
  an \f(CW@implementation\fR section.  This option always performs its
! checks as soon as a \f(CW@selector(...)\fR expression is found,
  while \fB\-Wselector\fR only performs its checks in the final stage of
  compilation.  This also enforces the coding style convention
  that methods and selectors must be declared before being used.
! .IP \fB\-print\-objc\-runtime\-info\fR 4
  .IX Item "-print-objc-runtime-info"
  Generate C header describing the largest structure that is passed by
  value, if any.
  .SS "Options to Control Diagnostic Messages Formatting"
  .IX Subsection "Options to Control Diagnostic Messages Formatting"
  Traditionally, diagnostic messages have been formatted irrespective of
! the output device\*(Aqs aspect (e.g. its width, ...).  You can use the
  options described below
  to control the formatting algorithm for diagnostic messages, 
  e.g. how many characters per line, how often source location
  information should be reported.  Note that some language front ends may not
  honor these options.
! .IP \fB\-fmessage\-length=\fR\fIn\fR 4
  .IX Item "-fmessage-length=n"
  Try to format error messages so that they fit on lines of about
! \&\fIn\fR characters.  If \fIn\fR is zero, then no line\-wrapping is
  done; each error message appears on a single line.  This is the
  default for all front ends.
  .Sp
  Note \- this option also affects the display of the \fB#error\fR and
! \&\fB#warning\fR pre\-processor directives, and the \fBdeprecated\fR
  function/type/variable attribute.  It does not however affect the
! \&\fBpragma GCC warning\fR and \fBpragma GCC error\fR pragmas.
! .IP \fB\-fdiagnostics\-plain\-output\fR 4
  .IX Item "-fdiagnostics-plain-output"
  This option requests that diagnostic output look as plain as possible, which
  may be useful when running \fBdejagnu\fR or other utilities that need to
*************** options:
*** 4874,4915 ****
  \&\-fdiagnostics\-color=never
  \&\-fdiagnostics\-urls=never
  \&\-fdiagnostics\-path\-format=separate\-events\fR
! In the future, if \s-1GCC\s0 changes the default appearance of its diagnostics, the
  corresponding option to disable the new behavior will be added to this list.
! .IP "\fB\-fdiagnostics\-show\-location=once\fR" 4
  .IX Item "-fdiagnostics-show-location=once"
! Only meaningful in line-wrapping mode.  Instructs the diagnostic messages
  reporter to emit source location information \fIonce\fR; that is, in
  case the message is too long to fit on a single physical line and has to
! be wrapped, the source location won't be emitted (as prefix) again,
  over and over, in subsequent continuation lines.  This is the default
  behavior.
! .IP "\fB\-fdiagnostics\-show\-location=every\-line\fR" 4
  .IX Item "-fdiagnostics-show-location=every-line"
! Only meaningful in line-wrapping mode.  Instructs the diagnostic
  messages reporter to emit the same source location information (as
  prefix) for physical lines that result from the process of breaking
  a message which is too long to fit on a single line.
! .IP "\fB\-fdiagnostics\-color[=\fR\fI\s-1WHEN\s0\fR\fB]\fR" 4
  .IX Item "-fdiagnostics-color[=WHEN]"
  .PD 0
! .IP "\fB\-fno\-diagnostics\-color\fR" 4
  .IX Item "-fno-diagnostics-color"
  .PD
! Use color in diagnostics.  \fI\s-1WHEN\s0\fR is \fBnever\fR, \fBalways\fR,
  or \fBauto\fR.  The default depends on how the compiler has been configured,
! it can be any of the above \fI\s-1WHEN\s0\fR options or also \fBnever\fR
! if \fB\s-1GCC_COLORS\s0\fR environment variable isn't present in the environment,
  and \fBauto\fR otherwise.
! \&\fBauto\fR makes \s-1GCC\s0 use color only when the standard error is a terminal,
  and when not executing in an emacs shell.
  The forms \fB\-fdiagnostics\-color\fR and \fB\-fno\-diagnostics\-color\fR are
  aliases for \fB\-fdiagnostics\-color=always\fR and
  \&\fB\-fdiagnostics\-color=never\fR, respectively.
  .Sp
! The colors are defined by the environment variable \fB\s-1GCC_COLORS\s0\fR.
! Its value is a colon-separated list of capabilities and Select Graphic
! Rendition (\s-1SGR\s0) substrings. \s-1SGR\s0 commands are interpreted by the
  terminal or terminal emulator.  (See the section in the documentation
  of your text terminal for permitted values and their meanings as
  character attributes.)  These substring values are integers in decimal
--- 4803,4844 ----
  \&\-fdiagnostics\-color=never
  \&\-fdiagnostics\-urls=never
  \&\-fdiagnostics\-path\-format=separate\-events\fR
! In the future, if GCC changes the default appearance of its diagnostics, the
  corresponding option to disable the new behavior will be added to this list.
! .IP \fB\-fdiagnostics\-show\-location=once\fR 4
  .IX Item "-fdiagnostics-show-location=once"
! Only meaningful in line\-wrapping mode.  Instructs the diagnostic messages
  reporter to emit source location information \fIonce\fR; that is, in
  case the message is too long to fit on a single physical line and has to
! be wrapped, the source location won\*(Aqt be emitted (as prefix) again,
  over and over, in subsequent continuation lines.  This is the default
  behavior.
! .IP \fB\-fdiagnostics\-show\-location=every\-line\fR 4
  .IX Item "-fdiagnostics-show-location=every-line"
! Only meaningful in line\-wrapping mode.  Instructs the diagnostic
  messages reporter to emit the same source location information (as
  prefix) for physical lines that result from the process of breaking
  a message which is too long to fit on a single line.
! .IP \fB\-fdiagnostics\-color[=\fR\fIWHEN\fR\fB]\fR 4
  .IX Item "-fdiagnostics-color[=WHEN]"
  .PD 0
! .IP \fB\-fno\-diagnostics\-color\fR 4
  .IX Item "-fno-diagnostics-color"
  .PD
! Use color in diagnostics.  \fIWHEN\fR is \fBnever\fR, \fBalways\fR,
  or \fBauto\fR.  The default depends on how the compiler has been configured,
! it can be any of the above \fIWHEN\fR options or also \fBnever\fR
! if \fBGCC_COLORS\fR environment variable isn\*(Aqt present in the environment,
  and \fBauto\fR otherwise.
! \&\fBauto\fR makes GCC use color only when the standard error is a terminal,
  and when not executing in an emacs shell.
  The forms \fB\-fdiagnostics\-color\fR and \fB\-fno\-diagnostics\-color\fR are
  aliases for \fB\-fdiagnostics\-color=always\fR and
  \&\fB\-fdiagnostics\-color=never\fR, respectively.
  .Sp
! The colors are defined by the environment variable \fBGCC_COLORS\fR.
! Its value is a colon\-separated list of capabilities and Select Graphic
! Rendition (SGR) substrings. SGR commands are interpreted by the
  terminal or terminal emulator.  (See the section in the documentation
  of your text terminal for permitted values and their meanings as
  character attributes.)  These substring values are integers in decimal
*************** for 88\-color and 256\-color modes foreg
*** 4930,4936 ****
  and \fB48;5;0\fR to \fB48;5;255\fR
  for 88\-color and 256\-color modes background colors.
  .Sp
! The default \fB\s-1GCC_COLORS\s0\fR is
  .Sp
  .Vb 4
  \&        error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\e
--- 4859,4865 ----
  and \fB48;5;0\fR to \fB48;5;255\fR
  for 88\-color and 256\-color modes background colors.
  .Sp
! The default \fBGCC_COLORS\fR is
  .Sp
  .Vb 4
  \&        error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\e
*************** The default \fB\s-1GCC_COLORS\s0\fR is
*** 4942,5082 ****
  where \fB01;31\fR is bold red, \fB01;35\fR is bold magenta,
  \&\fB01;36\fR is bold cyan, \fB32\fR is green, \fB34\fR is blue,
  \&\fB01\fR is bold, and \fB31\fR is red.
! Setting \fB\s-1GCC_COLORS\s0\fR to the empty string disables colors.
  Supported capabilities are as follows.
  .RS 4
  .ie n .IP """error=""" 4
! .el .IP "\f(CWerror=\fR" 4
  .IX Item "error="
! \&\s-1SGR\s0 substring for error: markers.
  .ie n .IP """warning=""" 4
! .el .IP "\f(CWwarning=\fR" 4
  .IX Item "warning="
! \&\s-1SGR\s0 substring for warning: markers.
  .ie n .IP """note=""" 4
! .el .IP "\f(CWnote=\fR" 4
  .IX Item "note="
! \&\s-1SGR\s0 substring for note: markers.
  .ie n .IP """path=""" 4
! .el .IP "\f(CWpath=\fR" 4
  .IX Item "path="
! \&\s-1SGR\s0 substring for colorizing paths of control-flow events as printed
  via \fB\-fdiagnostics\-path\-format=\fR, such as the identifiers of
  individual events and lines indicating interprocedural calls and returns.
  .ie n .IP """range1=""" 4
! .el .IP "\f(CWrange1=\fR" 4
  .IX Item "range1="
! \&\s-1SGR\s0 substring for first additional range.
  .ie n .IP """range2=""" 4
! .el .IP "\f(CWrange2=\fR" 4
  .IX Item "range2="
! \&\s-1SGR\s0 substring for second additional range.
  .ie n .IP """locus=""" 4
! .el .IP "\f(CWlocus=\fR" 4
  .IX Item "locus="
! \&\s-1SGR\s0 substring for location information, \fBfile:line\fR or
  \&\fBfile:line:column\fR etc.
  .ie n .IP """quote=""" 4
! .el .IP "\f(CWquote=\fR" 4
  .IX Item "quote="
! \&\s-1SGR\s0 substring for information printed within quotes.
  .ie n .IP """fnname=""" 4
! .el .IP "\f(CWfnname=\fR" 4
  .IX Item "fnname="
! \&\s-1SGR\s0 substring for names of \*(C+ functions.
  .ie n .IP """targs=""" 4
! .el .IP "\f(CWtargs=\fR" 4
  .IX Item "targs="
! \&\s-1SGR\s0 substring for \*(C+ function template parameter bindings.
  .ie n .IP """fixit\-insert=""" 4
! .el .IP "\f(CWfixit\-insert=\fR" 4
  .IX Item "fixit-insert="
! \&\s-1SGR\s0 substring for fix-it hints suggesting text to
  be inserted or replaced.
  .ie n .IP """fixit\-delete=""" 4
! .el .IP "\f(CWfixit\-delete=\fR" 4
  .IX Item "fixit-delete="
! \&\s-1SGR\s0 substring for fix-it hints suggesting text to
  be deleted.
  .ie n .IP """diff\-filename=""" 4
! .el .IP "\f(CWdiff\-filename=\fR" 4
  .IX Item "diff-filename="
! \&\s-1SGR\s0 substring for filename headers within generated patches.
  .ie n .IP """diff\-hunk=""" 4
! .el .IP "\f(CWdiff\-hunk=\fR" 4
  .IX Item "diff-hunk="
! \&\s-1SGR\s0 substring for the starts of hunks within generated patches.
  .ie n .IP """diff\-delete=""" 4
! .el .IP "\f(CWdiff\-delete=\fR" 4
  .IX Item "diff-delete="
! \&\s-1SGR\s0 substring for deleted lines within generated patches.
  .ie n .IP """diff\-insert=""" 4
! .el .IP "\f(CWdiff\-insert=\fR" 4
  .IX Item "diff-insert="
! \&\s-1SGR\s0 substring for inserted lines within generated patches.
  .ie n .IP """type\-diff=""" 4
! .el .IP "\f(CWtype\-diff=\fR" 4
  .IX Item "type-diff="
! \&\s-1SGR\s0 substring for highlighting mismatching types within template
! arguments in the \*(C+ frontend.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdiagnostics\-urls[=\fR\fI\s-1WHEN\s0\fR\fB]\fR" 4
  .IX Item "-fdiagnostics-urls[=WHEN]"
  Use escape sequences to embed URLs in diagnostics.  For example, when
! \&\fB\-fdiagnostics\-show\-option\fR emits text showing the command-line
! option controlling a diagnostic, embed a \s-1URL\s0 for documentation of that
  option.
  .Sp
! \&\fI\s-1WHEN\s0\fR is \fBnever\fR, \fBalways\fR, or \fBauto\fR.
! \&\fBauto\fR makes \s-1GCC\s0 use \s-1URL\s0 escape sequences only when the standard error
  is a terminal, and when not executing in an emacs shell or any graphical
  terminal which is known to be incompatible with this feature, see below.
  .Sp
  The default depends on how the compiler has been configured.
! It can be any of the above \fI\s-1WHEN\s0\fR options.
  .Sp
! \&\s-1GCC\s0 can also be configured (via the
! \&\fB\-\-with\-diagnostics\-urls=auto\-if\-env\fR configure-time option)
  so that the default is affected by environment variables.
! Under such a configuration, \s-1GCC\s0 defaults to using \fBauto\fR
! if either \fB\s-1GCC_URLS\s0\fR or \fB\s-1TERM_URLS\s0\fR environment variables are
! present and non-empty in the environment of the compiler, or \fBnever\fR
  if neither are.
  .Sp
  However, even with \fB\-fdiagnostics\-urls=always\fR the behavior is
  dependent on those environment variables:
! If \fB\s-1GCC_URLS\s0\fR is set to empty or \fBno\fR, do not embed URLs in
! diagnostics.  If set to \fBst\fR, URLs use \s-1ST\s0 escape sequences.
! If set to \fBbel\fR, the default, URLs use \s-1BEL\s0 escape sequences.
! Any other non-empty value enables the feature.
! If \fB\s-1GCC_URLS\s0\fR is not set, use \fB\s-1TERM_URLS\s0\fR as a fallback.
! Note: \s-1ST\s0 is an \s-1ANSI\s0 escape sequence, string terminator \fB\s-1ESC\s0 \e\fR,
! \&\s-1BEL\s0 is an \s-1ASCII\s0 character, CTRL-G that usually sounds like a beep.
  .Sp
! At this time \s-1GCC\s0 tries to detect also a few terminals that are known to
! not implement the \s-1URL\s0 feature, and have bugs or at least had bugs in
! some versions that are still in use, where the \s-1URL\s0 escapes are likely
  to misbehave, i.e. print garbage on the screen.
  That list is currently xfce4\-terminal, certain known to be buggy
! gnome-terminal versions, the linux console, and mingw.
  This check can be skipped with the \fB\-fdiagnostics\-urls=always\fR.
! .IP "\fB\-fno\-diagnostics\-show\-option\fR" 4
  .IX Item "-fno-diagnostics-show-option"
  By default, each diagnostic emitted includes text indicating the
! command-line option that directly controls the diagnostic (if such an
  option is known to the diagnostic machinery).  Specifying the
  \&\fB\-fno\-diagnostics\-show\-option\fR flag suppresses that behavior.
! .IP "\fB\-fno\-diagnostics\-show\-caret\fR" 4
  .IX Item "-fno-diagnostics-show-caret"
  By default, each diagnostic emitted includes the original source line
  and a caret \fB^\fR indicating the column.  This option suppresses this
  information.  The source line is truncated to \fIn\fR characters, if
  the \fB\-fmessage\-length=n\fR option is given.  When the output is done
  to the terminal, the width is limited to the width given by the
! \&\fB\s-1COLUMNS\s0\fR environment variable or, if not set, to the terminal width.
! .IP "\fB\-fno\-diagnostics\-show\-labels\fR" 4
  .IX Item "-fno-diagnostics-show-labels"
  By default, when printing source code (via \fB\-fdiagnostics\-show\-caret\fR),
  diagnostics can label ranges of source code with pertinent information, such
--- 4871,5011 ----
  where \fB01;31\fR is bold red, \fB01;35\fR is bold magenta,
  \&\fB01;36\fR is bold cyan, \fB32\fR is green, \fB34\fR is blue,
  \&\fB01\fR is bold, and \fB31\fR is red.
! Setting \fBGCC_COLORS\fR to the empty string disables colors.
  Supported capabilities are as follows.
  .RS 4
  .ie n .IP """error=""" 4
! .el .IP \f(CWerror=\fR 4
  .IX Item "error="
! SGR substring for error: markers.
  .ie n .IP """warning=""" 4
! .el .IP \f(CWwarning=\fR 4
  .IX Item "warning="
! SGR substring for warning: markers.
  .ie n .IP """note=""" 4
! .el .IP \f(CWnote=\fR 4
  .IX Item "note="
! SGR substring for note: markers.
  .ie n .IP """path=""" 4
! .el .IP \f(CWpath=\fR 4
  .IX Item "path="
! SGR substring for colorizing paths of control\-flow events as printed
  via \fB\-fdiagnostics\-path\-format=\fR, such as the identifiers of
  individual events and lines indicating interprocedural calls and returns.
  .ie n .IP """range1=""" 4
! .el .IP \f(CWrange1=\fR 4
  .IX Item "range1="
! SGR substring for first additional range.
  .ie n .IP """range2=""" 4
! .el .IP \f(CWrange2=\fR 4
  .IX Item "range2="
! SGR substring for second additional range.
  .ie n .IP """locus=""" 4
! .el .IP \f(CWlocus=\fR 4
  .IX Item "locus="
! SGR substring for location information, \fBfile:line\fR or
  \&\fBfile:line:column\fR etc.
  .ie n .IP """quote=""" 4
! .el .IP \f(CWquote=\fR 4
  .IX Item "quote="
! SGR substring for information printed within quotes.
  .ie n .IP """fnname=""" 4
! .el .IP \f(CWfnname=\fR 4
  .IX Item "fnname="
! SGR substring for names of C++ functions.
  .ie n .IP """targs=""" 4
! .el .IP \f(CWtargs=\fR 4
  .IX Item "targs="
! SGR substring for C++ function template parameter bindings.
  .ie n .IP """fixit\-insert=""" 4
! .el .IP \f(CWfixit\-insert=\fR 4
  .IX Item "fixit-insert="
! SGR substring for fix\-it hints suggesting text to
  be inserted or replaced.
  .ie n .IP """fixit\-delete=""" 4
! .el .IP \f(CWfixit\-delete=\fR 4
  .IX Item "fixit-delete="
! SGR substring for fix\-it hints suggesting text to
  be deleted.
  .ie n .IP """diff\-filename=""" 4
! .el .IP \f(CWdiff\-filename=\fR 4
  .IX Item "diff-filename="
! SGR substring for filename headers within generated patches.
  .ie n .IP """diff\-hunk=""" 4
! .el .IP \f(CWdiff\-hunk=\fR 4
  .IX Item "diff-hunk="
! SGR substring for the starts of hunks within generated patches.
  .ie n .IP """diff\-delete=""" 4
! .el .IP \f(CWdiff\-delete=\fR 4
  .IX Item "diff-delete="
! SGR substring for deleted lines within generated patches.
  .ie n .IP """diff\-insert=""" 4
! .el .IP \f(CWdiff\-insert=\fR 4
  .IX Item "diff-insert="
! SGR substring for inserted lines within generated patches.
  .ie n .IP """type\-diff=""" 4
! .el .IP \f(CWtype\-diff=\fR 4
  .IX Item "type-diff="
! SGR substring for highlighting mismatching types within template
! arguments in the C++ frontend.
  .RE
  .RS 4
  .RE
! .IP \fB\-fdiagnostics\-urls[=\fR\fIWHEN\fR\fB]\fR 4
  .IX Item "-fdiagnostics-urls[=WHEN]"
  Use escape sequences to embed URLs in diagnostics.  For example, when
! \&\fB\-fdiagnostics\-show\-option\fR emits text showing the command\-line
! option controlling a diagnostic, embed a URL for documentation of that
  option.
  .Sp
! \&\fIWHEN\fR is \fBnever\fR, \fBalways\fR, or \fBauto\fR.
! \&\fBauto\fR makes GCC use URL escape sequences only when the standard error
  is a terminal, and when not executing in an emacs shell or any graphical
  terminal which is known to be incompatible with this feature, see below.
  .Sp
  The default depends on how the compiler has been configured.
! It can be any of the above \fIWHEN\fR options.
  .Sp
! GCC can also be configured (via the
! \&\fB\-\-with\-diagnostics\-urls=auto\-if\-env\fR configure\-time option)
  so that the default is affected by environment variables.
! Under such a configuration, GCC defaults to using \fBauto\fR
! if either \fBGCC_URLS\fR or \fBTERM_URLS\fR environment variables are
! present and non\-empty in the environment of the compiler, or \fBnever\fR
  if neither are.
  .Sp
  However, even with \fB\-fdiagnostics\-urls=always\fR the behavior is
  dependent on those environment variables:
! If \fBGCC_URLS\fR is set to empty or \fBno\fR, do not embed URLs in
! diagnostics.  If set to \fBst\fR, URLs use ST escape sequences.
! If set to \fBbel\fR, the default, URLs use BEL escape sequences.
! Any other non\-empty value enables the feature.
! If \fBGCC_URLS\fR is not set, use \fBTERM_URLS\fR as a fallback.
! Note: ST is an ANSI escape sequence, string terminator \fBESC \e\fR,
! BEL is an ASCII character, CTRL\-G that usually sounds like a beep.
  .Sp
! At this time GCC tries to detect also a few terminals that are known to
! not implement the URL feature, and have bugs or at least had bugs in
! some versions that are still in use, where the URL escapes are likely
  to misbehave, i.e. print garbage on the screen.
  That list is currently xfce4\-terminal, certain known to be buggy
! gnome\-terminal versions, the linux console, and mingw.
  This check can be skipped with the \fB\-fdiagnostics\-urls=always\fR.
! .IP \fB\-fno\-diagnostics\-show\-option\fR 4
  .IX Item "-fno-diagnostics-show-option"
  By default, each diagnostic emitted includes text indicating the
! command\-line option that directly controls the diagnostic (if such an
  option is known to the diagnostic machinery).  Specifying the
  \&\fB\-fno\-diagnostics\-show\-option\fR flag suppresses that behavior.
! .IP \fB\-fno\-diagnostics\-show\-caret\fR 4
  .IX Item "-fno-diagnostics-show-caret"
  By default, each diagnostic emitted includes the original source line
  and a caret \fB^\fR indicating the column.  This option suppresses this
  information.  The source line is truncated to \fIn\fR characters, if
  the \fB\-fmessage\-length=n\fR option is given.  When the output is done
  to the terminal, the width is limited to the width given by the
! \&\fBCOLUMNS\fR environment variable or, if not set, to the terminal width.
! .IP \fB\-fno\-diagnostics\-show\-labels\fR 4
  .IX Item "-fno-diagnostics-show-labels"
  By default, when printing source code (via \fB\-fdiagnostics\-show\-caret\fR),
  diagnostics can label ranges of source code with pertinent information, such
*************** as the types of expressions:
*** 5090,5133 ****
  .Ve
  .Sp
  This option suppresses the printing of these labels (in the example above,
! the vertical bars and the \*(L"char *\*(R" and \*(L"long int\*(R" text).
! .IP "\fB\-fno\-diagnostics\-show\-cwe\fR" 4
  .IX Item "-fno-diagnostics-show-cwe"
  Diagnostic messages can optionally have an associated
!  \s-1CWE\s0 (\f(CW\*(C`https://cwe.mitre.org/index.html\*(C'\fR) identifier.
! \&\s-1GCC\s0 itself only provides such metadata for some of the \fB\-fanalyzer\fR
! diagnostics.  \s-1GCC\s0 plugins may also provide diagnostics with such metadata.
  By default, if this information is present, it will be printed with
  the diagnostic.  This option suppresses the printing of this metadata.
! .IP "\fB\-fno\-diagnostics\-show\-rules\fR" 4
  .IX Item "-fno-diagnostics-show-rules"
  Diagnostic messages can optionally have rules associated with them, such
  as from a coding standard, or a specification.
! \&\s-1GCC\s0 itself does not do this for any of its diagnostics, but plugins may do so.
  By default, if this information is present, it will be printed with
  the diagnostic.  This option suppresses the printing of this metadata.
! .IP "\fB\-fno\-diagnostics\-show\-line\-numbers\fR" 4
  .IX Item "-fno-diagnostics-show-line-numbers"
  By default, when printing source code (via \fB\-fdiagnostics\-show\-caret\fR),
  a left margin is printed, showing line numbers.  This option suppresses this
  left margin.
! .IP "\fB\-fdiagnostics\-minimum\-margin\-width=\fR\fIwidth\fR" 4
  .IX Item "-fdiagnostics-minimum-margin-width=width"
  This option controls the minimum width of the left margin printed by
  \&\fB\-fdiagnostics\-show\-line\-numbers\fR.  It defaults to 6.
! .IP "\fB\-fdiagnostics\-parseable\-fixits\fR" 4
  .IX Item "-fdiagnostics-parseable-fixits"
! Emit fix-it hints in a machine-parseable format, suitable for consumption
! by IDEs.  For each fix-it, a line will be printed after the relevant
! diagnostic, starting with the string \*(L"fix-it:\*(R".  For example:
  .Sp
  .Vb 1
  \&        fix\-it:"test.c":{45:3\-45:21}:"gtk_widget_show_all"
  .Ve
  .Sp
! The location is expressed as a half-open range, expressed as a count of
  bytes, starting at byte 1 for the initial column.  In the above example,
! bytes 3 through 20 of line 45 of \*(L"test.c\*(R" are to be replaced with the
  given string:
  .Sp
  .Vb 5
--- 5019,5062 ----
  .Ve
  .Sp
  This option suppresses the printing of these labels (in the example above,
! the vertical bars and the "char *" and "long int" text).
! .IP \fB\-fno\-diagnostics\-show\-cwe\fR 4
  .IX Item "-fno-diagnostics-show-cwe"
  Diagnostic messages can optionally have an associated
!  CWE (\f(CW\*(C`https://cwe.mitre.org/index.html\*(C'\fR) identifier.
! GCC itself only provides such metadata for some of the \fB\-fanalyzer\fR
! diagnostics.  GCC plugins may also provide diagnostics with such metadata.
  By default, if this information is present, it will be printed with
  the diagnostic.  This option suppresses the printing of this metadata.
! .IP \fB\-fno\-diagnostics\-show\-rules\fR 4
  .IX Item "-fno-diagnostics-show-rules"
  Diagnostic messages can optionally have rules associated with them, such
  as from a coding standard, or a specification.
! GCC itself does not do this for any of its diagnostics, but plugins may do so.
  By default, if this information is present, it will be printed with
  the diagnostic.  This option suppresses the printing of this metadata.
! .IP \fB\-fno\-diagnostics\-show\-line\-numbers\fR 4
  .IX Item "-fno-diagnostics-show-line-numbers"
  By default, when printing source code (via \fB\-fdiagnostics\-show\-caret\fR),
  a left margin is printed, showing line numbers.  This option suppresses this
  left margin.
! .IP \fB\-fdiagnostics\-minimum\-margin\-width=\fR\fIwidth\fR 4
  .IX Item "-fdiagnostics-minimum-margin-width=width"
  This option controls the minimum width of the left margin printed by
  \&\fB\-fdiagnostics\-show\-line\-numbers\fR.  It defaults to 6.
! .IP \fB\-fdiagnostics\-parseable\-fixits\fR 4
  .IX Item "-fdiagnostics-parseable-fixits"
! Emit fix\-it hints in a machine\-parseable format, suitable for consumption
! by IDEs.  For each fix\-it, a line will be printed after the relevant
! diagnostic, starting with the string "fix\-it:".  For example:
  .Sp
  .Vb 1
  \&        fix\-it:"test.c":{45:3\-45:21}:"gtk_widget_show_all"
  .Ve
  .Sp
! The location is expressed as a half\-open range, expressed as a count of
  bytes, starting at byte 1 for the initial column.  In the above example,
! bytes 3 through 20 of line 45 of "test.c" are to be replaced with the
  given string:
  .Sp
  .Vb 5
*************** given string:
*** 5138,5153 ****
  \&          gtk_widget_show_all
  .Ve
  .Sp
! The filename and replacement string escape backslash as \*(L"\e\e\*(R", tab as \*(L"\et\*(R",
! newline as \*(L"\en\*(R", double quotes as \*(L"\e\*(R"\*(L", non-printable characters as octal
! (e.g. vertical tab as \*(R"\e013").
  .Sp
  An empty replacement string indicates that the given range is to be removed.
! An empty range (e.g. \*(L"45:3\-45:3\*(R") indicates that the string is to
  be inserted at the given position.
! .IP "\fB\-fdiagnostics\-generate\-patch\fR" 4
  .IX Item "-fdiagnostics-generate-patch"
! Print fix-it hints to stderr in unified diff format, after any diagnostics
  are printed.  For example:
  .Sp
  .Vb 3
--- 5067,5082 ----
  \&          gtk_widget_show_all
  .Ve
  .Sp
! The filename and replacement string escape backslash as "\e\e", tab as "\et",
! newline as "\en", double quotes as "\e"", non\-printable characters as octal
! (e.g. vertical tab as "\e013").
  .Sp
  An empty replacement string indicates that the given range is to be removed.
! An empty range (e.g. "45:3\-45:3") indicates that the string is to
  be inserted at the given position.
! .IP \fB\-fdiagnostics\-generate\-patch\fR 4
  .IX Item "-fdiagnostics-generate-patch"
! Print fix\-it hints to stderr in unified diff format, after any diagnostics
  are printed.  For example:
  .Sp
  .Vb 3
*************** are printed.  For example:
*** 5164,5172 ****
  .Sp
  The diff may or may not be colorized, following the same rules
  as for diagnostics (see \fB\-fdiagnostics\-color\fR).
! .IP "\fB\-fdiagnostics\-show\-template\-tree\fR" 4
  .IX Item "-fdiagnostics-show-template-tree"
! In the \*(C+ frontend, when printing diagnostics showing mismatching
  template types, such as:
  .Sp
  .Vb 2
--- 5093,5101 ----
  .Sp
  The diff may or may not be colorized, following the same rules
  as for diagnostics (see \fB\-fdiagnostics\-color\fR).
! .IP \fB\-fdiagnostics\-show\-template\-tree\fR 4
  .IX Item "-fdiagnostics-show-template-tree"
! In the C++ frontend, when printing diagnostics showing mismatching
  template types, such as:
  .Sp
  .Vb 2
*************** template types, such as:
*** 5175,5181 ****
  .Ve
  .Sp
  the \fB\-fdiagnostics\-show\-template\-tree\fR flag enables printing a
! tree-like structure showing the common and differing parts of the types,
  such as:
  .Sp
  .Vb 4
--- 5104,5110 ----
  .Ve
  .Sp
  the \fB\-fdiagnostics\-show\-template\-tree\fR flag enables printing a
! tree\-like structure showing the common and differing parts of the types,
  such as:
  .Sp
  .Vb 4
*************** such as:
*** 5185,5196 ****
  \&              [double != float]>>
  .Ve
  .Sp
! The parts that differ are highlighted with color (\*(L"double\*(R" and
! \&\*(L"float\*(R" in this case).
! .IP "\fB\-fno\-elide\-type\fR" 4
  .IX Item "-fno-elide-type"
! By default when the \*(C+ frontend prints diagnostics showing mismatching
! template types, common parts of the types are printed as \*(L"[...]\*(R" to
  simplify the error message.  For example:
  .Sp
  .Vb 2
--- 5114,5125 ----
  \&              [double != float]>>
  .Ve
  .Sp
! The parts that differ are highlighted with color ("double" and
! "float" in this case).
! .IP \fB\-fno\-elide\-type\fR 4
  .IX Item "-fno-elide-type"
! By default when the C++ frontend prints diagnostics showing mismatching
! template types, common parts of the types are printed as "[...]" to
  simplify the error message.  For example:
  .Sp
  .Vb 2
*************** simplify the error message.  For example
*** 5201,5217 ****
  Specifying the \fB\-fno\-elide\-type\fR flag suppresses that behavior.
  This flag also affects the output of the
  \&\fB\-fdiagnostics\-show\-template\-tree\fR flag.
! .IP "\fB\-fdiagnostics\-path\-format=\fR\fI\s-1KIND\s0\fR" 4
  .IX Item "-fdiagnostics-path-format=KIND"
! Specify how to print paths of control-flow events for diagnostics that
  have such a path associated with them.
  .Sp
! \&\fI\s-1KIND\s0\fR is \fBnone\fR, \fBseparate-events\fR, or \fBinline-events\fR,
  the default.
  .Sp
  \&\fBnone\fR means to not print diagnostic paths.
  .Sp
! \&\fBseparate-events\fR means to print a separate \*(L"note\*(R" diagnostic for
  each event within the diagnostic.  For example:
  .Sp
  .Vb 4
--- 5130,5146 ----
  Specifying the \fB\-fno\-elide\-type\fR flag suppresses that behavior.
  This flag also affects the output of the
  \&\fB\-fdiagnostics\-show\-template\-tree\fR flag.
! .IP \fB\-fdiagnostics\-path\-format=\fR\fIKIND\fR 4
  .IX Item "-fdiagnostics-path-format=KIND"
! Specify how to print paths of control\-flow events for diagnostics that
  have such a path associated with them.
  .Sp
! \&\fIKIND\fR is \fBnone\fR, \fBseparate\-events\fR, or \fBinline\-events\fR,
  the default.
  .Sp
  \&\fBnone\fR means to not print diagnostic paths.
  .Sp
! \&\fBseparate\-events\fR means to print a separate "note" diagnostic for
  each event within the diagnostic.  For example:
  .Sp
  .Vb 4
*************** each event within the diagnostic.  For e
*** 5221,5229 ****
  \&        test.c:29:5: note: (3) when calling \*(AqPyList_Append\*(Aq, passing NULL from (1) as argument 1
  .Ve
  .Sp
! \&\fBinline-events\fR means to print the events \*(L"inline\*(R" within the source
  code.  This view attempts to consolidate the events into runs of
! sufficiently-close events, printing them as labelled ranges within the source.
  .Sp
  For example, the same events as above might be printed as:
  .Sp
--- 5150,5158 ----
  \&        test.c:29:5: note: (3) when calling \*(AqPyList_Append\*(Aq, passing NULL from (1) as argument 1
  .Ve
  .Sp
! \&\fBinline\-events\fR means to print the events "inline" within the source
  code.  This view attempts to consolidate the events into runs of
! sufficiently\-close events, printing them as labelled ranges within the source.
  .Sp
  For example, the same events as above might be printed as:
  .Sp
*************** For example:
*** 5297,5305 ****
  \&            |
  \&        (etc)
  .Ve
! .IP "\fB\-fdiagnostics\-show\-path\-depths\fR" 4
  .IX Item "-fdiagnostics-show-path-depths"
! This option provides additional information when printing control-flow paths
  associated with a diagnostic.
  .Sp
  If this is option is provided then the stack depth will be printed for
--- 5226,5234 ----
  \&            |
  \&        (etc)
  .Ve
! .IP \fB\-fdiagnostics\-show\-path\-depths\fR 4
  .IX Item "-fdiagnostics-show-path-depths"
! This option provides additional information when printing control\-flow paths
  associated with a diagnostic.
  .Sp
  If this is option is provided then the stack depth will be printed for
*************** If provided with \fB\-fdiagnostics\-path
*** 5308,5393 ****
  the stack depth and function declaration will be appended when printing
  each event.
  .Sp
! This is intended for use by \s-1GCC\s0 developers and plugin developers when
  debugging diagnostics that report interprocedural control flow.
! .IP "\fB\-fno\-show\-column\fR" 4
  .IX Item "-fno-show-column"
  Do not print column numbers in diagnostics.  This may be necessary if
  diagnostics are being scanned by a program that does not understand the
  column numbers, such as \fBdejagnu\fR.
! .IP "\fB\-fdiagnostics\-column\-unit=\fR\fI\s-1UNIT\s0\fR" 4
  .IX Item "-fdiagnostics-column-unit=UNIT"
  Select the units for the column number.  This affects traditional diagnostics
! (in the absence of \fB\-fno\-show\-column\fR), as well as \s-1JSON\s0 format
  diagnostics if requested.
  .Sp
! The default \fI\s-1UNIT\s0\fR, \fBdisplay\fR, considers the number of display
  columns occupied by each character.  This may be larger than the number
  of bytes required to encode the character, in the case of tab
  characters, or it may be smaller, in the case of multibyte characters.
! For example, the character \*(L"\s-1GREEK SMALL LETTER PI\s0 (U+03C0)\*(R" occupies one
! display column, and its \s-1UTF\-8\s0 encoding requires two bytes; the character
! \&\*(L"\s-1SLIGHTLY SMILING FACE\s0 (U+1F642)\*(R" occupies two display columns, and
! its \s-1UTF\-8\s0 encoding requires four bytes.
  .Sp
! Setting \fI\s-1UNIT\s0\fR to \fBbyte\fR changes the column number to the raw byte
! count in all cases, as was traditionally output by \s-1GCC\s0 prior to version 11.1.0.
! .IP "\fB\-fdiagnostics\-column\-origin=\fR\fI\s-1ORIGIN\s0\fR" 4
  .IX Item "-fdiagnostics-column-origin=ORIGIN"
  Select the origin for column numbers, i.e. the column number assigned to the
! first column.  The default value of 1 corresponds to traditional \s-1GCC\s0
! behavior and to the \s-1GNU\s0 style guide.  Some utilities may perform better with an
! origin of 0; any non-negative value may be specified.
! .IP "\fB\-fdiagnostics\-escape\-format=\fR\fI\s-1FORMAT\s0\fR" 4
  .IX Item "-fdiagnostics-escape-format=FORMAT"
! When \s-1GCC\s0 prints pertinent source lines for a diagnostic it normally attempts
  to print the source bytes directly.  However, some diagnostics relate to encoding
! issues in the source file, such as malformed \s-1UTF\-8,\s0 or issues with Unicode
! normalization.  These diagnostics are flagged so that \s-1GCC\s0 will escape bytes
! that are not printable \s-1ASCII\s0 when printing their pertinent source lines.
  .Sp
  This option controls how such bytes should be escaped.
  .Sp
! The default \fI\s-1FORMAT\s0\fR, \fBunicode\fR displays Unicode characters that
! are not printable \s-1ASCII\s0 in the form \fB\fR, and bytes that do not
! correspond to a Unicode character validly-encoded in UTF\-8\-encoded will be
! displayed as hexadecimal in the form \fB<\s-1XX\s0>\fR.
  .Sp
  For example, a source line containing the string \fBbefore\fR followed by the
! Unicode character U+03C0 (\*(L"\s-1GREEK SMALL LETTER PI\*(R",\s0 with \s-1UTF\-8\s0 encoding
! 0xCF 0x80) followed by the byte 0xBF (a stray \s-1UTF\-8\s0 trailing byte), followed by
  the string \fBafter\fR will be printed for such a diagnostic as:
  .Sp
  .Vb 1
  \&         beforeafter
  .Ve
  .Sp
! Setting \fI\s-1FORMAT\s0\fR to \fBbytes\fR will display all non-printable-ASCII bytes
! in the form \fB<\s-1XX\s0>\fR, thus showing the underlying encoding of non-ASCII
  Unicode characters.  For the example above, the following will be printed:
  .Sp
  .Vb 1
  \&         before<80>after
  .Ve
! .IP "\fB\-fdiagnostics\-format=\fR\fI\s-1FORMAT\s0\fR" 4
  .IX Item "-fdiagnostics-format=FORMAT"
  Select a different format for printing diagnostics.
! \&\fI\s-1FORMAT\s0\fR is \fBtext\fR, \fBsarif-stderr\fR, \fBsarif-file\fR,
! \&\fBjson\fR, \fBjson-stderr\fR, or \fBjson-file\fR.
  .Sp
  The default is \fBtext\fR.
  .Sp
! The \fBsarif-stderr\fR and \fBsarif-file\fR formats both emit
! diagnostics in \s-1SARIF\s0 Version 2.1.0 format, either to stderr, or to a file
! named \fI\fIsource\fI.sarif\fR, respectively.
  .Sp
! The \fBjson\fR format is a synonym for \fBjson-stderr\fR.
! The \fBjson-stderr\fR and \fBjson-file\fR formats are identical, apart from
! where the \s-1JSON\s0 is emitted to \- with the former, the \s-1JSON\s0 is emitted to stderr,
! whereas with \fBjson-file\fR it is written to \fI\fIsource\fI.gcc.json\fR.
  .Sp
! The emitted \s-1JSON\s0 consists of a top-level \s-1JSON\s0 array containing \s-1JSON\s0 objects
! representing the diagnostics.  The \s-1JSON\s0 is emitted as one line, without
  formatting; the examples below have been formatted for clarity.
  .Sp
  Diagnostics can have child diagnostics.  For example, this error and note:
--- 5237,5322 ----
  the stack depth and function declaration will be appended when printing
  each event.
  .Sp
! This is intended for use by GCC developers and plugin developers when
  debugging diagnostics that report interprocedural control flow.
! .IP \fB\-fno\-show\-column\fR 4
  .IX Item "-fno-show-column"
  Do not print column numbers in diagnostics.  This may be necessary if
  diagnostics are being scanned by a program that does not understand the
  column numbers, such as \fBdejagnu\fR.
! .IP \fB\-fdiagnostics\-column\-unit=\fR\fIUNIT\fR 4
  .IX Item "-fdiagnostics-column-unit=UNIT"
  Select the units for the column number.  This affects traditional diagnostics
! (in the absence of \fB\-fno\-show\-column\fR), as well as JSON format
  diagnostics if requested.
  .Sp
! The default \fIUNIT\fR, \fBdisplay\fR, considers the number of display
  columns occupied by each character.  This may be larger than the number
  of bytes required to encode the character, in the case of tab
  characters, or it may be smaller, in the case of multibyte characters.
! For example, the character "GREEK SMALL LETTER PI (U+03C0)" occupies one
! display column, and its UTF\-8 encoding requires two bytes; the character
! "SLIGHTLY SMILING FACE (U+1F642)" occupies two display columns, and
! its UTF\-8 encoding requires four bytes.
  .Sp
! Setting \fIUNIT\fR to \fBbyte\fR changes the column number to the raw byte
! count in all cases, as was traditionally output by GCC prior to version 11.1.0.
! .IP \fB\-fdiagnostics\-column\-origin=\fR\fIORIGIN\fR 4
  .IX Item "-fdiagnostics-column-origin=ORIGIN"
  Select the origin for column numbers, i.e. the column number assigned to the
! first column.  The default value of 1 corresponds to traditional GCC
! behavior and to the GNU style guide.  Some utilities may perform better with an
! origin of 0; any non\-negative value may be specified.
! .IP \fB\-fdiagnostics\-escape\-format=\fR\fIFORMAT\fR 4
  .IX Item "-fdiagnostics-escape-format=FORMAT"
! When GCC prints pertinent source lines for a diagnostic it normally attempts
  to print the source bytes directly.  However, some diagnostics relate to encoding
! issues in the source file, such as malformed UTF\-8, or issues with Unicode
! normalization.  These diagnostics are flagged so that GCC will escape bytes
! that are not printable ASCII when printing their pertinent source lines.
  .Sp
  This option controls how such bytes should be escaped.
  .Sp
! The default \fIFORMAT\fR, \fBunicode\fR displays Unicode characters that
! are not printable ASCII in the form \fB\fR, and bytes that do not
! correspond to a Unicode character validly\-encoded in UTF\-8\-encoded will be
! displayed as hexadecimal in the form \fB\fR.
  .Sp
  For example, a source line containing the string \fBbefore\fR followed by the
! Unicode character U+03C0 ("GREEK SMALL LETTER PI", with UTF\-8 encoding
! 0xCF 0x80) followed by the byte 0xBF (a stray UTF\-8 trailing byte), followed by
  the string \fBafter\fR will be printed for such a diagnostic as:
  .Sp
  .Vb 1
  \&         beforeafter
  .Ve
  .Sp
! Setting \fIFORMAT\fR to \fBbytes\fR will display all non\-printable\-ASCII bytes
! in the form \fB\fR, thus showing the underlying encoding of non\-ASCII
  Unicode characters.  For the example above, the following will be printed:
  .Sp
  .Vb 1
  \&         before<80>after
  .Ve
! .IP \fB\-fdiagnostics\-format=\fR\fIFORMAT\fR 4
  .IX Item "-fdiagnostics-format=FORMAT"
  Select a different format for printing diagnostics.
! \&\fIFORMAT\fR is \fBtext\fR, \fBsarif\-stderr\fR, \fBsarif\-file\fR,
! \&\fBjson\fR, \fBjson\-stderr\fR, or \fBjson\-file\fR.
  .Sp
  The default is \fBtext\fR.
  .Sp
! The \fBsarif\-stderr\fR and \fBsarif\-file\fR formats both emit
! diagnostics in SARIF Version 2.1.0 format, either to stderr, or to a file
! named \fIsource.sarif\fR, respectively.
  .Sp
! The \fBjson\fR format is a synonym for \fBjson\-stderr\fR.
! The \fBjson\-stderr\fR and \fBjson\-file\fR formats are identical, apart from
! where the JSON is emitted to \- with the former, the JSON is emitted to stderr,
! whereas with \fBjson\-file\fR it is written to \fIsource.gcc.json\fR.
  .Sp
! The emitted JSON consists of a top\-level JSON array containing JSON objects
! representing the diagnostics.  The JSON is emitted as one line, without
  formatting; the examples below have been formatted for clarity.
  .Sp
  Diagnostics can have child diagnostics.  For example, this error and note:
*************** Diagnostics can have child diagnostics.
*** 5403,5409 ****
  \&              |     ^
  .Ve
  .Sp
! might be printed in \s-1JSON\s0 form (after formatting) like this:
  .Sp
  .Vb 10
  \&        [
--- 5332,5338 ----
  \&              |     ^
  .Ve
  .Sp
! might be printed in JSON form (after formatting) like this:
  .Sp
  .Vb 10
  \&        [
*************** might be printed in \s-1JSON\s0 form (af
*** 5457,5463 ****
  where the \f(CW\*(C`note\*(C'\fR is a child of the \f(CW\*(C`warning\*(C'\fR.
  .Sp
  A diagnostic has a \f(CW\*(C`kind\*(C'\fR.  If this is \f(CW\*(C`warning\*(C'\fR, then there is
! an \f(CW\*(C`option\*(C'\fR key describing the command-line option controlling the
  warning.
  .Sp
  A diagnostic can contain zero or more locations.  Each location has an
--- 5386,5392 ----
  where the \f(CW\*(C`note\*(C'\fR is a child of the \f(CW\*(C`warning\*(C'\fR.
  .Sp
  A diagnostic has a \f(CW\*(C`kind\*(C'\fR.  If this is \f(CW\*(C`warning\*(C'\fR, then there is
! an \f(CW\*(C`option\*(C'\fR key describing the command\-line option controlling the
  warning.
  .Sp
  A diagnostic can contain zero or more locations.  Each location has an
*************** optional \f(CW\*(C`label\*(C'\fR string
*** 5466,5477 ****
  A position is described by a \f(CW\*(C`file\*(C'\fR name, a \f(CW\*(C`line\*(C'\fR number, and
  three numbers indicating a column position:
  .RS 4
! .IP "*" 4
  \&\f(CW\*(C`display\-column\*(C'\fR counts display columns, accounting for tabs and
  multibyte characters.
! .IP "*" 4
  \&\f(CW\*(C`byte\-column\*(C'\fR counts raw bytes.
! .IP "*" 4
  \&\f(CW\*(C`column\*(C'\fR is equal to one of
  the previous two, as dictated by the \fB\-fdiagnostics\-column\-unit\fR
  option.
--- 5395,5406 ----
  A position is described by a \f(CW\*(C`file\*(C'\fR name, a \f(CW\*(C`line\*(C'\fR number, and
  three numbers indicating a column position:
  .RS 4
! .IP * 4
  \&\f(CW\*(C`display\-column\*(C'\fR counts display columns, accounting for tabs and
  multibyte characters.
! .IP * 4
  \&\f(CW\*(C`byte\-column\*(C'\fR counts raw bytes.
! .IP * 4
  \&\f(CW\*(C`column\*(C'\fR is equal to one of
  the previous two, as dictated by the \fB\-fdiagnostics\-column\-unit\fR
  option.
*************** option.
*** 5481,5487 ****
  All three columns are relative to the origin specified by
  \&\fB\-fdiagnostics\-column\-origin\fR, which is typically equal to 1 but may
  be set, for instance, to 0 for compatibility with other utilities that
! number columns from 0.  The column origin is recorded in the \s-1JSON\s0 output in
  the \f(CW\*(C`column\-origin\*(C'\fR tag.  In the remaining examples below, the extra
  column number outputs have been omitted for brevity.
  .Sp
--- 5410,5416 ----
  All three columns are relative to the origin specified by
  \&\fB\-fdiagnostics\-column\-origin\fR, which is typically equal to 1 but may
  be set, for instance, to 0 for compatibility with other utilities that
! number columns from 0.  The column origin is recorded in the JSON output in
  the \f(CW\*(C`column\-origin\*(C'\fR tag.  In the remaining examples below, the extra
  column number outputs have been omitted for brevity.
  .Sp
*************** For example, this error:
*** 5497,5505 ****
  \&              |          S {aka struct s}
  .Ve
  .Sp
! has three locations.  Its primary location is at the \*(L"+\*(R" token at column
! 23.  It has two secondary locations, describing the left and right-hand sides
! of the expression, which have labels.  It might be printed in \s-1JSON\s0 form as:
  .Sp
  .Vb 10
  \&            {
--- 5426,5434 ----
  \&              |          S {aka struct s}
  .Ve
  .Sp
! has three locations.  Its primary location is at the "+" token at column
! 23.  It has two secondary locations, describing the left and right\-hand sides
! of the expression, which have labels.  It might be printed in JSON form as:
  .Sp
  .Vb 10
  \&            {
*************** of the expression, which have labels.  I
*** 5535,5544 ****
  \&            }
  .Ve
  .Sp
! If a diagnostic contains fix-it hints, it has a \f(CW\*(C`fixits\*(C'\fR array,
! consisting of half-open intervals, similar to the output of
  \&\fB\-fdiagnostics\-parseable\-fixits\fR.  For example, this diagnostic
! with a replacement fix-it hint:
  .Sp
  .Vb 5
  \&        demo.c:8:15: error: \*(Aqstruct s\*(Aq has no member named \*(Aqcolour\*(Aq; did you
--- 5464,5473 ----
  \&            }
  .Ve
  .Sp
! If a diagnostic contains fix\-it hints, it has a \f(CW\*(C`fixits\*(C'\fR array,
! consisting of half\-open intervals, similar to the output of
  \&\fB\-fdiagnostics\-parseable\-fixits\fR.  For example, this diagnostic
! with a replacement fix\-it hint:
  .Sp
  .Vb 5
  \&        demo.c:8:15: error: \*(Aqstruct s\*(Aq has no member named \*(Aqcolour\*(Aq; did you
*************** with a replacement fix-it hint:
*** 5548,5554 ****
  \&              |               color
  .Ve
  .Sp
! might be printed in \s-1JSON\s0 form as:
  .Sp
  .Vb 10
  \&            {
--- 5477,5483 ----
  \&              |               color
  .Ve
  .Sp
! might be printed in JSON form as:
  .Sp
  .Vb 10
  \&            {
*************** might be printed in \s-1JSON\s0 form as:
*** 5588,5599 ****
  \&            }
  .Ve
  .Sp
! where the fix-it hint suggests replacing the text from \f(CW\*(C`start\*(C'\fR up
! to but not including \f(CW\*(C`next\*(C'\fR with \f(CW\*(C`string\*(C'\fR's value.  Deletions
  are expressed via an empty value for \f(CW\*(C`string\*(C'\fR, insertions by
  having \f(CW\*(C`start\*(C'\fR equal \f(CW\*(C`next\*(C'\fR.
  .Sp
! If the diagnostic has a path of control-flow events associated with it,
  it has a \f(CW\*(C`path\*(C'\fR array of objects representing the events.  Each
  event object has a \f(CW\*(C`description\*(C'\fR string, a \f(CW\*(C`location\*(C'\fR object,
  along with a \f(CW\*(C`function\*(C'\fR string and a \f(CW\*(C`depth\*(C'\fR number for
--- 5517,5528 ----
  \&            }
  .Ve
  .Sp
! where the fix\-it hint suggests replacing the text from \f(CW\*(C`start\*(C'\fR up
! to but not including \f(CW\*(C`next\*(C'\fR with \f(CW\*(C`string\*(C'\fR\*(Aqs value.  Deletions
  are expressed via an empty value for \f(CW\*(C`string\*(C'\fR, insertions by
  having \f(CW\*(C`start\*(C'\fR equal \f(CW\*(C`next\*(C'\fR.
  .Sp
! If the diagnostic has a path of control\-flow events associated with it,
  it has a \f(CW\*(C`path\*(C'\fR array of objects representing the events.  Each
  event object has a \f(CW\*(C`description\*(C'\fR string, a \f(CW\*(C`location\*(C'\fR object,
  along with a \f(CW\*(C`function\*(C'\fR string and a \f(CW\*(C`depth\*(C'\fR number for
*************** stack depth relative to some baseline: t
*** 5603,5609 ****
  within the stack.
  .Sp
  For example, the intraprocedural example shown for
! \&\fB\-fdiagnostics\-path\-format=\fR might have this \s-1JSON\s0 for its path:
  .Sp
  .Vb 10
  \&            "path": [
--- 5532,5538 ----
  within the stack.
  .Sp
  For example, the intraprocedural example shown for
! \&\fB\-fdiagnostics\-path\-format=\fR might have this JSON for its path:
  .Sp
  .Vb 10
  \&            "path": [
*************** For example, the intraprocedural example
*** 5641,5647 ****
  .Ve
  .Sp
  Diagnostics have a boolean attribute \f(CW\*(C`escape\-source\*(C'\fR, hinting whether
! non-ASCII bytes should be escaped when printing the pertinent lines of
  source code (\f(CW\*(C`true\*(C'\fR for diagnostics involving source encoding issues).
  .RE
  .SS "Options to Request or Suppress Warnings"
--- 5570,5576 ----
  .Ve
  .Sp
  Diagnostics have a boolean attribute \f(CW\*(C`escape\-source\*(C'\fR, hinting whether
! non\-ASCII bytes should be escaped when printing the pertinent lines of
  source code (\f(CW\*(C`true\*(C'\fR for diagnostics involving source encoding issues).
  .RE
  .SS "Options to Request or Suppress Warnings"
*************** Warnings are diagnostic messages that re
*** 5650,5675 ****
  are not inherently erroneous but that are risky or suggest there
  may have been an error.
  .PP
! The following language-independent options do not enable specific
! warnings but control the kinds of diagnostics produced by \s-1GCC.\s0
! .IP "\fB\-fsyntax\-only\fR" 4
  .IX Item "-fsyntax-only"
! Check the code for syntax errors, but don't do anything beyond that.
! .IP "\fB\-fmax\-errors=\fR\fIn\fR" 4
  .IX Item "-fmax-errors=n"
  Limits the maximum number of error messages to \fIn\fR, at which point
! \&\s-1GCC\s0 bails out rather than attempting to continue processing the source
  code.  If \fIn\fR is 0 (the default), there is no limit on the number
  of error messages produced.  If \fB\-Wfatal\-errors\fR is also
  specified, then \fB\-Wfatal\-errors\fR takes precedence over this
  option.
! .IP "\fB\-w\fR" 4
  .IX Item "-w"
  Inhibit all warning messages.
! .IP "\fB\-Werror\fR" 4
  .IX Item "-Werror"
  Make all warnings into errors.
! .IP "\fB\-Werror=\fR" 4
  .IX Item "-Werror="
  Make the specified warning into an error.  The specifier for a warning
  is appended; for example \fB\-Werror=switch\fR turns the warnings
--- 5579,5604 ----
  are not inherently erroneous but that are risky or suggest there
  may have been an error.
  .PP
! The following language\-independent options do not enable specific
! warnings but control the kinds of diagnostics produced by GCC.
! .IP \fB\-fsyntax\-only\fR 4
  .IX Item "-fsyntax-only"
! Check the code for syntax errors, but don\*(Aqt do anything beyond that.
! .IP \fB\-fmax\-errors=\fR\fIn\fR 4
  .IX Item "-fmax-errors=n"
  Limits the maximum number of error messages to \fIn\fR, at which point
! GCC bails out rather than attempting to continue processing the source
  code.  If \fIn\fR is 0 (the default), there is no limit on the number
  of error messages produced.  If \fB\-Wfatal\-errors\fR is also
  specified, then \fB\-Wfatal\-errors\fR takes precedence over this
  option.
! .IP \fB\-w\fR 4
  .IX Item "-w"
  Inhibit all warning messages.
! .IP \fB\-Werror\fR 4
  .IX Item "-Werror"
  Make all warnings into errors.
! .IP \fB\-Werror=\fR 4
  .IX Item "-Werror="
  Make the specified warning into an error.  The specifier for a warning
  is appended; for example \fB\-Werror=switch\fR turns the warnings
*************** option that controls the warning.  That
*** 5688,5694 ****
  Note that specifying \fB\-Werror=\fR\fIfoo\fR automatically implies
  \&\fB\-W\fR\fIfoo\fR.  However, \fB\-Wno\-error=\fR\fIfoo\fR does not
  imply anything.
! .IP "\fB\-Wfatal\-errors\fR" 4
  .IX Item "-Wfatal-errors"
  This option causes the compiler to abort compilation on the first error
  occurred rather than trying to keep going and printing further error
--- 5617,5623 ----
  Note that specifying \fB\-Werror=\fR\fIfoo\fR automatically implies
  \&\fB\-W\fR\fIfoo\fR.  However, \fB\-Wno\-error=\fR\fIfoo\fR does not
  imply anything.
! .IP \fB\-Wfatal\-errors\fR 4
  .IX Item "-Wfatal-errors"
  This option causes the compiler to abort compilation on the first error
  occurred rather than trying to keep going and printing further error
*************** implicit declarations.  Each of these sp
*** 5700,5720 ****
  has a negative form beginning \fB\-Wno\-\fR to turn off warnings; for
  example, \fB\-Wno\-implicit\fR.  This manual lists only one of the
  two forms, whichever is not the default.  For further
! language-specific options also refer to \fB\*(C+ Dialect Options\fR and
! \&\fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
  Additional warnings can be produced by enabling the static analyzer;
  .PP
  Some options, such as \fB\-Wall\fR and \fB\-Wextra\fR, turn on other
  options, such as \fB\-Wunused\fR, which may turn on further options,
  such as \fB\-Wunused\-value\fR. The combined effect of positive and
  negative forms is that more specific options have priority over less
! specific ones, independently of their position in the command-line. For
  options of the same specificity, the last one takes effect. Options
  enabled or disabled via pragmas take effect
! as if they appeared at the end of the command-line.
  .PP
  When an unrecognized warning option is requested (e.g.,
! \&\fB\-Wunknown\-warning\fR), \s-1GCC\s0 emits a diagnostic stating
  that the option is not recognized.  However, if the \fB\-Wno\-\fR form
  is used, the behavior is slightly different: no diagnostic is
  produced for \fB\-Wno\-unknown\-warning\fR unless other diagnostics
--- 5629,5649 ----
  has a negative form beginning \fB\-Wno\-\fR to turn off warnings; for
  example, \fB\-Wno\-implicit\fR.  This manual lists only one of the
  two forms, whichever is not the default.  For further
! language\-specific options also refer to \fBC++ Dialect Options\fR and
! \&\fBObjective\-C and Objective\-C++ Dialect Options\fR.
  Additional warnings can be produced by enabling the static analyzer;
  .PP
  Some options, such as \fB\-Wall\fR and \fB\-Wextra\fR, turn on other
  options, such as \fB\-Wunused\fR, which may turn on further options,
  such as \fB\-Wunused\-value\fR. The combined effect of positive and
  negative forms is that more specific options have priority over less
! specific ones, independently of their position in the command\-line. For
  options of the same specificity, the last one takes effect. Options
  enabled or disabled via pragmas take effect
! as if they appeared at the end of the command\-line.
  .PP
  When an unrecognized warning option is requested (e.g.,
! \&\fB\-Wunknown\-warning\fR), GCC emits a diagnostic stating
  that the option is not recognized.  However, if the \fB\-Wno\-\fR form
  is used, the behavior is slightly different: no diagnostic is
  produced for \fB\-Wno\-unknown\-warning\fR unless other diagnostics
*************** warns that an unrecognized option is pre
*** 5724,5843 ****
  .PP
  The effectiveness of some warnings depends on optimizations also being
  enabled. For example \fB\-Wsuggest\-final\-types\fR is more effective
! with link-time optimization and some instances of other warnings may
  not be issued at all unless optimization is enabled.  While optimization
  in general improves the efficacy of control and data flow sensitive
  warnings, in some cases it may also cause false positives.
! .IP "\fB\-Wpedantic\fR" 4
  .IX Item "-Wpedantic"
  .PD 0
! .IP "\fB\-pedantic\fR" 4
  .IX Item "-pedantic"
  .PD
! Issue all the warnings demanded by strict \s-1ISO C\s0 and \s-1ISO \*(C+\s0;
  reject all programs that use forbidden extensions, and some other
! programs that do not follow \s-1ISO C\s0 and \s-1ISO \*(C+.\s0  For \s-1ISO C,\s0 follows the
! version of the \s-1ISO C\s0 standard specified by any \fB\-std\fR option used.
  .Sp
! Valid \s-1ISO C\s0 and \s-1ISO \*(C+\s0 programs should compile properly with or without
  this option (though a rare few require \fB\-ansi\fR or a
! \&\fB\-std\fR option specifying the required version of \s-1ISO C\s0).  However,
! without this option, certain \s-1GNU\s0 extensions and traditional C and \*(C+
  features are supported as well.  With this option, they are rejected.
  .Sp
  \&\fB\-Wpedantic\fR does not cause warning messages for use of the
  alternate keywords whose names begin and end with \fB_\|_\fR.  This alternate
! format can also be used to disable warnings for non-ISO \fB_\|_intN\fR types,
  i.e. \fB_\|_intN_\|_\fR.
  Pedantic warnings are also disabled in the expression that follows
  \&\f(CW\*(C`_\|_extension_\|_\*(C'\fR.  However, only system header files should use
  these escape routes; application programs should avoid them.
  .Sp
! Some users try to use \fB\-Wpedantic\fR to check programs for strict \s-1ISO
! C\s0 conformance.  They soon find that it does not do quite what they want:
! it finds some non-ISO practices, but not all\-\-\-only those for which
! \&\s-1ISO C\s0 \fIrequires\fR a diagnostic, and some others for which
  diagnostics have been added.
  .Sp
! A feature to report any failure to conform to \s-1ISO C\s0 might be useful in
  some instances, but would require considerable additional work and would
! be quite different from \fB\-Wpedantic\fR.  We don't have plans to
  support such a feature in the near future.
  .Sp
! Where the standard specified with \fB\-std\fR represents a \s-1GNU\s0
  extended dialect of C, such as \fBgnu90\fR or \fBgnu99\fR, there is a
! corresponding \fIbase standard\fR, the version of \s-1ISO C\s0 on which the \s-1GNU\s0
  extended dialect is based.  Warnings from \fB\-Wpedantic\fR are given
  where they are required by the base standard.  (It does not make sense
! for such warnings to be given only for features not in the specified \s-1GNU
! C\s0 dialect, since by definition the \s-1GNU\s0 dialects of C include all
  features the compiler supports with the given option, and there would be
  nothing to warn about.)
! .IP "\fB\-pedantic\-errors\fR" 4
  .IX Item "-pedantic-errors"
  Give an error whenever the \fIbase standard\fR (see \fB\-Wpedantic\fR)
  requires a diagnostic, in some cases where there is undefined behavior
! at compile-time and in some other cases that do not prevent compilation
  of programs that are valid according to the standard. This is not
  equivalent to \fB\-Werror=pedantic\fR, since there are errors enabled
  by this option and not enabled by the latter and vice versa.
! .IP "\fB\-Wall\fR" 4
  .IX Item "-Wall"
  This enables all the warnings about constructions that some users
  consider questionable, and that are easy to avoid (or modify to
  prevent the warning), even in conjunction with macros.  This also
! enables some language-specific warnings described in \fB\*(C+ Dialect
! Options\fR and \fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
  .Sp
  \&\fB\-Wall\fR turns on the following warning flags:
  .Sp
  \&\fB\-Waddress
  \&\-Warray\-bounds=1\fR (only with\fB \fR\fB\-O2\fR)
  \&\fB\-Warray\-compare
! \&\-Warray\-parameter=2\fR (C and Objective-C only)
  \&\fB\-Wbool\-compare
  \&\-Wbool\-operation
  \&\-Wc++11\-compat  \-Wc++14\-compat
! \&\-Wcatch\-value\fR (\*(C+ and Objective\-\*(C+ only)
  \&\fB\-Wchar\-subscripts
  \&\-Wcomment
  \&\-Wdangling\-pointer=2
! \&\-Wduplicate\-decl\-specifier\fR (C and Objective-C only)
! \&\fB\-Wenum\-compare\fR (in C/ObjC; this is on by default in \*(C+)
! \&\fB\-Wenum\-int\-mismatch\fR (C and Objective-C only)
  \&\fB\-Wformat
  \&\-Wformat\-overflow
  \&\-Wformat\-truncation
  \&\-Wint\-in\-bool\-context
! \&\-Wimplicit\fR (C and Objective-C only)
! \&\fB\-Wimplicit\-int\fR (C and Objective-C only)
! \&\fB\-Wimplicit\-function\-declaration\fR (C and Objective-C only)
! \&\fB\-Winit\-self\fR (only for \*(C+)
  \&\fB\-Wlogical\-not\-parentheses
  \&\-Wmain\fR (only for C/ObjC and unless\fB \fR\fB\-ffreestanding\fR)
  \&\fB\-Wmaybe\-uninitialized
  \&\-Wmemset\-elt\-size
  \&\-Wmemset\-transposed\-args
! \&\-Wmisleading\-indentation\fR (only for C/\*(C+)
  \&\fB\-Wmismatched\-dealloc
! \&\-Wmismatched\-new\-delete\fR (only for C/\*(C+)
  \&\fB\-Wmissing\-attributes
  \&\-Wmissing\-braces\fR (only for C/ObjC)
  \&\fB\-Wmultistatement\-macros
! \&\-Wnarrowing\fR (only for \*(C+)
  \&\fB\-Wnonnull
  \&\-Wnonnull\-compare
  \&\-Wopenmp\-simd
  \&\-Wparentheses
! \&\-Wpessimizing\-move\fR (only for \*(C+)
  \&\fB\-Wpointer\-sign
! \&\-Wrange\-loop\-construct\fR (only for \*(C+)
  \&\fB\-Wreorder
  \&\-Wrestrict
  \&\-Wreturn\-type
! \&\-Wself\-move\fR (only for \*(C+)
  \&\fB\-Wsequence\-point
! \&\-Wsign\-compare\fR (only in \*(C+)
  \&\fB\-Wsizeof\-array\-div
  \&\-Wsizeof\-pointer\-div
  \&\-Wsizeof\-pointer\-memaccess
--- 5653,5772 ----
  .PP
  The effectiveness of some warnings depends on optimizations also being
  enabled. For example \fB\-Wsuggest\-final\-types\fR is more effective
! with link\-time optimization and some instances of other warnings may
  not be issued at all unless optimization is enabled.  While optimization
  in general improves the efficacy of control and data flow sensitive
  warnings, in some cases it may also cause false positives.
! .IP \fB\-Wpedantic\fR 4
  .IX Item "-Wpedantic"
  .PD 0
! .IP \fB\-pedantic\fR 4
  .IX Item "-pedantic"
  .PD
! Issue all the warnings demanded by strict 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 \fB\-std\fR option used.
  .Sp
! Valid ISO C and ISO C++ programs should compile properly with or without
  this option (though a rare few require \fB\-ansi\fR or a
! \&\fB\-std\fR option specifying the required version of 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.
  .Sp
  \&\fB\-Wpedantic\fR does not cause warning messages for use of the
  alternate keywords whose names begin and end with \fB_\|_\fR.  This alternate
! format can also be used to disable warnings for non\-ISO \fB_\|_intN\fR types,
  i.e. \fB_\|_intN_\|_\fR.
  Pedantic warnings are also disabled in the expression that follows
  \&\f(CW\*(C`_\|_extension_\|_\*(C'\fR.  However, only system header files should use
  these escape routes; application programs should avoid them.
  .Sp
! Some users try to use \fB\-Wpedantic\fR to check programs for strict 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 \fIrequires\fR a diagnostic, and some others for which
  diagnostics have been added.
  .Sp
! 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 \fB\-Wpedantic\fR.  We don\*(Aqt have plans to
  support such a feature in the near future.
  .Sp
! Where the standard specified with \fB\-std\fR represents a GNU
  extended dialect of C, such as \fBgnu90\fR or \fBgnu99\fR, there is a
! corresponding \fIbase standard\fR, the version of ISO C on which the GNU
  extended dialect is based.  Warnings from \fB\-Wpedantic\fR are given
  where they are required by the base standard.  (It does not make sense
! for such warnings to be given only for features not in the specified 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.)
! .IP \fB\-pedantic\-errors\fR 4
  .IX Item "-pedantic-errors"
  Give an error whenever the \fIbase standard\fR (see \fB\-Wpedantic\fR)
  requires a diagnostic, in some cases where there is undefined behavior
! at compile\-time and in some other cases that do not prevent compilation
  of programs that are valid according to the standard. This is not
  equivalent to \fB\-Werror=pedantic\fR, since there are errors enabled
  by this option and not enabled by the latter and vice versa.
! .IP \fB\-Wall\fR 4
  .IX Item "-Wall"
  This enables all the warnings about constructions that some users
  consider questionable, and that are easy to avoid (or modify to
  prevent the warning), even in conjunction with macros.  This also
! enables some language\-specific warnings described in \fBC++ Dialect
! Options\fR and \fBObjective\-C and Objective\-C++ Dialect Options\fR.
  .Sp
  \&\fB\-Wall\fR turns on the following warning flags:
  .Sp
  \&\fB\-Waddress
  \&\-Warray\-bounds=1\fR (only with\fB \fR\fB\-O2\fR)
  \&\fB\-Warray\-compare
! \&\-Warray\-parameter=2\fR (C and Objective\-C only)
  \&\fB\-Wbool\-compare
  \&\-Wbool\-operation
  \&\-Wc++11\-compat  \-Wc++14\-compat
! \&\-Wcatch\-value\fR (C++ and Objective\-C++ only)
  \&\fB\-Wchar\-subscripts
  \&\-Wcomment
  \&\-Wdangling\-pointer=2
! \&\-Wduplicate\-decl\-specifier\fR (C and Objective\-C only)
! \&\fB\-Wenum\-compare\fR (in C/ObjC; this is on by default in C++)
! \&\fB\-Wenum\-int\-mismatch\fR (C and Objective\-C only)
  \&\fB\-Wformat
  \&\-Wformat\-overflow
  \&\-Wformat\-truncation
  \&\-Wint\-in\-bool\-context
! \&\-Wimplicit\fR (C and Objective\-C only)
! \&\fB\-Wimplicit\-int\fR (C and Objective\-C only)
! \&\fB\-Wimplicit\-function\-declaration\fR (C and Objective\-C only)
! \&\fB\-Winit\-self\fR (only for C++)
  \&\fB\-Wlogical\-not\-parentheses
  \&\-Wmain\fR (only for C/ObjC and unless\fB \fR\fB\-ffreestanding\fR)
  \&\fB\-Wmaybe\-uninitialized
  \&\-Wmemset\-elt\-size
  \&\-Wmemset\-transposed\-args
! \&\-Wmisleading\-indentation\fR (only for C/C++)
  \&\fB\-Wmismatched\-dealloc
! \&\-Wmismatched\-new\-delete\fR (only for C/C++)
  \&\fB\-Wmissing\-attributes
  \&\-Wmissing\-braces\fR (only for C/ObjC)
  \&\fB\-Wmultistatement\-macros
! \&\-Wnarrowing\fR (only for C++)
  \&\fB\-Wnonnull
  \&\-Wnonnull\-compare
  \&\-Wopenmp\-simd
  \&\-Wparentheses
! \&\-Wpessimizing\-move\fR (only for C++)
  \&\fB\-Wpointer\-sign
! \&\-Wrange\-loop\-construct\fR (only for C++)
  \&\fB\-Wreorder
  \&\-Wrestrict
  \&\-Wreturn\-type
! \&\-Wself\-move\fR (only for C++)
  \&\fB\-Wsequence\-point
! \&\-Wsign\-compare\fR (only in C++)
  \&\fB\-Wsizeof\-array\-div
  \&\-Wsizeof\-pointer\-div
  \&\-Wsizeof\-pointer\-memaccess
*************** Options\fR and \fBObjective-C and Object
*** 5853,5859 ****
  \&\-Wunused\-value
  \&\-Wunused\-variable
  \&\-Wuse\-after\-free=2
! \&\-Wvla\-parameter\fR (C and Objective-C only)
  \&\fB\-Wvolatile\-register\-var
  \&\-Wzero\-length\-bounds\fR
  .Sp
--- 5782,5788 ----
  \&\-Wunused\-value
  \&\-Wunused\-variable
  \&\-Wuse\-after\-free=2
! \&\-Wvla\-parameter\fR (C and Objective\-C only)
  \&\fB\-Wvolatile\-register\-var
  \&\-Wzero\-length\-bounds\fR
  .Sp
*************** others warn about constructions that are
*** 5864,5870 ****
  some cases, and there is no simple way to modify the code to suppress
  the warning. Some of them are enabled by \fB\-Wextra\fR but many of
  them must be enabled individually.
! .IP "\fB\-Wextra\fR" 4
  .IX Item "-Wextra"
  This enables some extra warning flags that are not enabled by
  \&\fB\-Wall\fR. (This option used to be called \fB\-W\fR.  The older
--- 5793,5799 ----
  some cases, and there is no simple way to modify the code to suppress
  the warning. Some of them are enabled by \fB\-Wextra\fR but many of
  them must be enabled individually.
! .IP \fB\-Wextra\fR 4
  .IX Item "-Wextra"
  This enables some extra warning flags that are not enabled by
  \&\fB\-Wall\fR. (This option used to be called \fB\-W\fR.  The older
*************** name is still supported, but the newer n
*** 5872,5879 ****
  .Sp
  \&\fB\-Wclobbered
  \&\-Wcast\-function\-type
! \&\-Wdangling\-reference\fR (\*(C+ only)
! \&\fB\-Wdeprecated\-copy\fR (\*(C+ only)
  \&\fB\-Wempty\-body
  \&\-Wenum\-conversion\fR (C only)
  \&\fB\-Wignored\-qualifiers
--- 5801,5808 ----
  .Sp
  \&\fB\-Wclobbered
  \&\-Wcast\-function\-type
! \&\-Wdangling\-reference\fR (C++ only)
! \&\fB\-Wdeprecated\-copy\fR (C++ only)
  \&\fB\-Wempty\-body
  \&\-Wenum\-conversion\fR (C only)
  \&\fB\-Wignored\-qualifiers
*************** name is still supported, but the newer n
*** 5884,5933 ****
  \&\fB\-Woverride\-init
  \&\-Wsign\-compare\fR (C only)
  \&\fB\-Wstring\-compare
! \&\-Wredundant\-move\fR (only for \*(C+)
  \&\fB\-Wtype\-limits
  \&\-Wuninitialized
! \&\-Wshift\-negative\-value\fR (in \*(C+11 to \*(C+17 and in C99 and newer)
  \&\fB\-Wunused\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)
  \&\fB\-Wunused\-but\-set\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)
  .Sp
  The option \fB\-Wextra\fR also prints warning messages for the
  following cases:
  .RS 4
! .IP "*" 4
  A pointer is compared against integer zero with \f(CW\*(C`<\*(C'\fR, \f(CW\*(C`<=\*(C'\fR,
  \&\f(CW\*(C`>\*(C'\fR, or \f(CW\*(C`>=\*(C'\fR.
! .IP "*" 4
! (\*(C+ only) An enumerator and a non-enumerator both appear in a
  conditional expression.
! .IP "*" 4
! (\*(C+ only) Ambiguous virtual bases.
! .IP "*" 4
! (\*(C+ only) Subscripting an array that has been declared \f(CW\*(C`register\*(C'\fR.
! .IP "*" 4
! (\*(C+ only) Taking the address of a variable that has been declared
  \&\f(CW\*(C`register\*(C'\fR.
! .IP "*" 4
! (\*(C+ only) A base class is not initialized in the copy constructor
  of a derived class.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wabi\fR (C, Objective-C, \*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wabi (C, Objective-C, and Objective- only)"
! Warn about code affected by \s-1ABI\s0 changes.  This includes code that may
! not be compatible with the vendor-neutral \*(C+ \s-1ABI\s0 as well as the psABI
  for the particular target.
  .Sp
! Since G++ now defaults to updating the \s-1ABI\s0 with each major release,
! normally \fB\-Wabi\fR warns only about \*(C+ \s-1ABI\s0 compatibility
  problems if there is a check added later in a release series for an
! \&\s-1ABI\s0 issue discovered since the initial release.  \fB\-Wabi\fR warns
! about more things if an older \s-1ABI\s0 version is selected (with
  \&\fB\-fabi\-version=\fR\fIn\fR).
  .Sp
  \&\fB\-Wabi\fR can also be used with an explicit version number to
! warn about \*(C+ \s-1ABI\s0 compatibility with a particular \fB\-fabi\-version\fR
  level, e.g. \fB\-Wabi=2\fR to warn about changes relative to
  \&\fB\-fabi\-version=2\fR.
  .Sp
--- 5813,5862 ----
  \&\fB\-Woverride\-init
  \&\-Wsign\-compare\fR (C only)
  \&\fB\-Wstring\-compare
! \&\-Wredundant\-move\fR (only for C++)
  \&\fB\-Wtype\-limits
  \&\-Wuninitialized
! \&\-Wshift\-negative\-value\fR (in C++11 to C++17 and in C99 and newer)
  \&\fB\-Wunused\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)
  \&\fB\-Wunused\-but\-set\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)
  .Sp
  The option \fB\-Wextra\fR also prints warning messages for the
  following cases:
  .RS 4
! .IP * 4
  A pointer is compared against integer zero with \f(CW\*(C`<\*(C'\fR, \f(CW\*(C`<=\*(C'\fR,
  \&\f(CW\*(C`>\*(C'\fR, or \f(CW\*(C`>=\*(C'\fR.
! .IP * 4
! (C++ only) An enumerator and a non\-enumerator both appear in a
  conditional expression.
! .IP * 4
! (C++ only) Ambiguous virtual bases.
! .IP * 4
! (C++ only) Subscripting an array that has been declared \f(CW\*(C`register\*(C'\fR.
! .IP * 4
! (C++ only) Taking the address of a variable that has been declared
  \&\f(CW\*(C`register\*(C'\fR.
! .IP * 4
! (C++ only) A base class is not initialized in the copy constructor
  of a derived class.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wabi\fR (C, Objective\-C, C++ and Objective\-C++ only)" 4
! .IX Item "-Wabi (C, Objective-C, C++ and Objective-C++ only)"
! Warn about code affected by ABI changes.  This includes code that may
! not be compatible with the vendor\-neutral C++ ABI as well as the psABI
  for the particular target.
  .Sp
! Since G++ now defaults to updating the ABI with each major release,
! normally \fB\-Wabi\fR warns only about C++ ABI compatibility
  problems if there is a check added later in a release series for an
! ABI issue discovered since the initial release.  \fB\-Wabi\fR warns
! about more things if an older ABI version is selected (with
  \&\fB\-fabi\-version=\fR\fIn\fR).
  .Sp
  \&\fB\-Wabi\fR can also be used with an explicit version number to
! warn about C++ ABI compatibility with a particular \fB\-fabi\-version\fR
  level, e.g. \fB\-Wabi=2\fR to warn about changes relative to
  \&\fB\-fabi\-version=2\fR.
  .Sp
*************** If an explicit version number is provide
*** 5936,5942 ****
  from this option is used for compatibility aliases.  If no explicit
  version number is provided with this option, but
  \&\fB\-fabi\-compat\-version\fR is specified, that version number is
! used for \*(C+ \s-1ABI\s0 warnings.
  .Sp
  Although an effort has been made to warn about
  all such cases, there are probably some cases that are not warned about,
--- 5865,5871 ----
  from this option is used for compatibility aliases.  If no explicit
  version number is provided with this option, but
  \&\fB\-fabi\-compat\-version\fR is specified, that version number is
! used for C++ ABI warnings.
  .Sp
  Although an effort has been made to warn about
  all such cases, there are probably some cases that are not warned about,
*************** concerned about the fact that code gener
*** 5949,5958 ****
  compatible with code generated by other compilers.
  .Sp
  Known incompatibilities in \fB\-fabi\-version=2\fR (which was the
! default from \s-1GCC 3.4\s0 to 4.9) include:
  .RS 4
! .IP "*" 4
! A template with a non-type template parameter of reference type was
  mangled incorrectly:
  .Sp
  .Vb 3
--- 5878,5887 ----
  compatible with code generated by other compilers.
  .Sp
  Known incompatibilities in \fB\-fabi\-version=2\fR (which was the
! default from GCC 3.4 to 4.9) include:
  .RS 4
! .IP * 4
! A template with a non\-type template parameter of reference type was
  mangled incorrectly:
  .Sp
  .Vb 3
*************** mangled incorrectly:
*** 5962,6022 ****
  .Ve
  .Sp
  This was fixed in \fB\-fabi\-version=3\fR.
! .IP "*" 4
! \&\s-1SIMD\s0 vector types declared using \f(CW\*(C`_\|_attribute ((vector_size))\*(C'\fR were
! mangled in a non-standard way that does not allow for overloading of
  functions taking vectors of different sizes.
  .Sp
  The mangling was changed in \fB\-fabi\-version=4\fR.
! .IP "*" 4
  \&\f(CW\*(C`_\|_attribute ((const))\*(C'\fR and \f(CW\*(C`noreturn\*(C'\fR were mangled as type
  qualifiers, and \f(CW\*(C`decltype\*(C'\fR of a plain declaration was folded away.
  .Sp
  These mangling issues were fixed in \fB\-fabi\-version=5\fR.
! .IP "*" 4
  Scoped enumerators passed as arguments to a variadic function are
  promoted like unscoped enumerators, causing \f(CW\*(C`va_arg\*(C'\fR to complain.
  On most targets this does not actually affect the parameter passing
! \&\s-1ABI,\s0 as there is no way to pass an argument smaller than \f(CW\*(C`int\*(C'\fR.
  .Sp
! Also, the \s-1ABI\s0 changed the mangling of template argument packs,
  \&\f(CW\*(C`const_cast\*(C'\fR, \f(CW\*(C`static_cast\*(C'\fR, prefix increment/decrement, and
  a class scope function used as a template argument.
  .Sp
  These issues were corrected in \fB\-fabi\-version=6\fR.
! .IP "*" 4
  Lambdas in default argument scope were mangled incorrectly, and the
! \&\s-1ABI\s0 changed the mangling of \f(CW\*(C`nullptr_t\*(C'\fR.
  .Sp
  These issues were corrected in \fB\-fabi\-version=7\fR.
! .IP "*" 4
! When mangling a function type with function-cv-qualifiers, the
! un-qualified function type was incorrectly treated as a substitution
  candidate.
  .Sp
! This was fixed in \fB\-fabi\-version=8\fR, the default for \s-1GCC 5.1.\s0
! .IP "*" 4
! \&\f(CW\*(C`decltype(nullptr)\*(C'\fR incorrectly had an alignment of 1, leading to
! unaligned accesses.  Note that this did not affect the \s-1ABI\s0 of a
  function with a \f(CW\*(C`nullptr_t\*(C'\fR parameter, as parameters have a
  minimum alignment.
  .Sp
! This was fixed in \fB\-fabi\-version=9\fR, the default for \s-1GCC 5.2.\s0
! .IP "*" 4
! Target-specific attributes that affect the identity of a type, such as
  ia32 calling conventions on a function type (stdcall, regparm, etc.),
  did not affect the mangled name, leading to name collisions when
  function pointers were used as template arguments.
  .Sp
! This was fixed in \fB\-fabi\-version=10\fR, the default for \s-1GCC 6.1.\s0
  .RE
  .RS 4
  .Sp
! This option also enables warnings about psABI-related changes.
  The known psABI changes at this point include:
! .IP "*" 4
  For SysV/x86\-64, unions with \f(CW\*(C`long double\*(C'\fR members are
! passed in memory as specified in psABI.  Prior to \s-1GCC 4.4,\s0 this was not
  the case.  For example:
  .Sp
  .Vb 4
--- 5891,5951 ----
  .Ve
  .Sp
  This was fixed in \fB\-fabi\-version=3\fR.
! .IP * 4
! SIMD vector types declared using \f(CW\*(C`_\|_attribute ((vector_size))\*(C'\fR were
! mangled in a non\-standard way that does not allow for overloading of
  functions taking vectors of different sizes.
  .Sp
  The mangling was changed in \fB\-fabi\-version=4\fR.
! .IP * 4
  \&\f(CW\*(C`_\|_attribute ((const))\*(C'\fR and \f(CW\*(C`noreturn\*(C'\fR were mangled as type
  qualifiers, and \f(CW\*(C`decltype\*(C'\fR of a plain declaration was folded away.
  .Sp
  These mangling issues were fixed in \fB\-fabi\-version=5\fR.
! .IP * 4
  Scoped enumerators passed as arguments to a variadic function are
  promoted like unscoped enumerators, causing \f(CW\*(C`va_arg\*(C'\fR to complain.
  On most targets this does not actually affect the parameter passing
! ABI, as there is no way to pass an argument smaller than \f(CW\*(C`int\*(C'\fR.
  .Sp
! Also, the ABI changed the mangling of template argument packs,
  \&\f(CW\*(C`const_cast\*(C'\fR, \f(CW\*(C`static_cast\*(C'\fR, prefix increment/decrement, and
  a class scope function used as a template argument.
  .Sp
  These issues were corrected in \fB\-fabi\-version=6\fR.
! .IP * 4
  Lambdas in default argument scope were mangled incorrectly, and the
! ABI changed the mangling of \f(CW\*(C`nullptr_t\*(C'\fR.
  .Sp
  These issues were corrected in \fB\-fabi\-version=7\fR.
! .IP * 4
! When mangling a function type with function\-cv\-qualifiers, the
! un\-qualified function type was incorrectly treated as a substitution
  candidate.
  .Sp
! This was fixed in \fB\-fabi\-version=8\fR, the default for GCC 5.1.
! .IP * 4
! \&\f(CWdecltype(nullptr)\fR incorrectly had an alignment of 1, leading to
! unaligned accesses.  Note that this did not affect the ABI of a
  function with a \f(CW\*(C`nullptr_t\*(C'\fR parameter, as parameters have a
  minimum alignment.
  .Sp
! This was fixed in \fB\-fabi\-version=9\fR, the default for GCC 5.2.
! .IP * 4
! Target\-specific attributes that affect the identity of a type, such as
  ia32 calling conventions on a function type (stdcall, regparm, etc.),
  did not affect the mangled name, leading to name collisions when
  function pointers were used as template arguments.
  .Sp
! This was fixed in \fB\-fabi\-version=10\fR, the default for GCC 6.1.
  .RE
  .RS 4
  .Sp
! This option also enables warnings about psABI\-related changes.
  The known psABI changes at this point include:
! .IP * 4
  For SysV/x86\-64, unions with \f(CW\*(C`long double\*(C'\fR members are
! passed in memory as specified in psABI.  Prior to GCC 4.4, this was not
  the case.  For example:
  .Sp
  .Vb 4
*************** the case.  For example:
*** 6030,6040 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wno\-changes\-meaning\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-changes-meaning ( and Objective- only)"
! \&\*(C+ requires that unqualified uses of a name within a class have the
  same meaning in the complete scope of the class, so declaring the name
! after using it is ill-formed:
  .Sp
  .Vb 3
  \&        struct A;
--- 5959,5969 ----
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wno\-changes\-meaning\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-changes-meaning (C++ and Objective-C++ only)"
! C++ requires that unqualified uses of a name within a class have the
  same meaning in the complete scope of the class, so declaring the name
! after using it is ill\-formed:
  .Sp
  .Vb 3
  \&        struct A;
*************** error case can be reduced to a warning w
*** 6049,6075 ****
  \&\fB\-Wno\-error=changes\-meaning\fR or \fB\-fpermissive\fR.
  .Sp
  Both diagnostics are also suppressed by \fB\-fms\-extensions\fR.
! .IP "\fB\-Wchar\-subscripts\fR" 4
  .IX Item "-Wchar-subscripts"
  Warn if an array subscript has type \f(CW\*(C`char\*(C'\fR.  This is a common cause
  of error, as programmers often forget that this type is signed on some
  machines.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-coverage\-mismatch\fR" 4
  .IX Item "-Wno-coverage-mismatch"
  Warn if feedback profiles do not match when using the
  \&\fB\-fprofile\-use\fR option.
  If a source file is changed between compiling with \fB\-fprofile\-generate\fR
  and with \fB\-fprofile\-use\fR, the files with the profile feedback can fail
! to match the source file and \s-1GCC\s0 cannot use the profile feedback
  information.  By default, this warning is enabled and is treated as an
  error.  \fB\-Wno\-coverage\-mismatch\fR can be used to disable the
  warning or \fB\-Wno\-error=coverage\-mismatch\fR can be used to
  disable the error.  Disabling the error for this warning can result in
  poorly optimized code and is useful only in the
! case of very minor changes such as bug fixes to an existing code-base.
  Completely disabling the warning is not recommended.
! .IP "\fB\-Wno\-coverage\-invalid\-line\-number\fR" 4
  .IX Item "-Wno-coverage-invalid-line-number"
  Warn in case a function ends earlier than it begins due
  to an invalid linenum macros.  The warning is emitted only
--- 5978,6004 ----
  \&\fB\-Wno\-error=changes\-meaning\fR or \fB\-fpermissive\fR.
  .Sp
  Both diagnostics are also suppressed by \fB\-fms\-extensions\fR.
! .IP \fB\-Wchar\-subscripts\fR 4
  .IX Item "-Wchar-subscripts"
  Warn if an array subscript has type \f(CW\*(C`char\*(C'\fR.  This is a common cause
  of error, as programmers often forget that this type is signed on some
  machines.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wno\-coverage\-mismatch\fR 4
  .IX Item "-Wno-coverage-mismatch"
  Warn if feedback profiles do not match when using the
  \&\fB\-fprofile\-use\fR option.
  If a source file is changed between compiling with \fB\-fprofile\-generate\fR
  and with \fB\-fprofile\-use\fR, the files with the profile feedback can fail
! to match the source file and GCC cannot use the profile feedback
  information.  By default, this warning is enabled and is treated as an
  error.  \fB\-Wno\-coverage\-mismatch\fR can be used to disable the
  warning or \fB\-Wno\-error=coverage\-mismatch\fR can be used to
  disable the error.  Disabling the error for this warning can result in
  poorly optimized code and is useful only in the
! case of very minor changes such as bug fixes to an existing code\-base.
  Completely disabling the warning is not recommended.
! .IP \fB\-Wno\-coverage\-invalid\-line\-number\fR 4
  .IX Item "-Wno-coverage-invalid-line-number"
  Warn in case a function ends earlier than it begins due
  to an invalid linenum macros.  The warning is emitted only
*************** By default, this warning is enabled and
*** 6079,6098 ****
  error.  \fB\-Wno\-coverage\-invalid\-line\-number\fR can be used to disable the
  warning or \fB\-Wno\-error=coverage\-invalid\-line\-number\fR can be used to
  disable the error.
! .IP "\fB\-Wno\-cpp\fR (C, Objective-C, \*(C+, Objective\-\*(C+ and Fortran only)" 4
! .IX Item "-Wno-cpp (C, Objective-C, , Objective- and Fortran only)"
  Suppress warning messages emitted by \f(CW\*(C`#warning\*(C'\fR directives.
! .IP "\fB\-Wdouble\-promotion\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wdouble-promotion (C, , Objective-C and Objective- only)"
  Give a warning when a value of type \f(CW\*(C`float\*(C'\fR is implicitly
! promoted to \f(CW\*(C`double\*(C'\fR.  CPUs with a 32\-bit \*(L"single-precision\*(R"
! floating-point unit implement \f(CW\*(C`float\*(C'\fR in hardware, but emulate
  \&\f(CW\*(C`double\*(C'\fR in software.  On such a machine, doing computations
  using \f(CW\*(C`double\*(C'\fR values is much more expensive because of the
  overhead required for software emulation.
  .Sp
  It is easy to accidentally do computations with \f(CW\*(C`double\*(C'\fR because
! floating-point literals are implicitly of type \f(CW\*(C`double\*(C'\fR.  For
  example, in:
  .Sp
  .Vb 4
--- 6008,6027 ----
  error.  \fB\-Wno\-coverage\-invalid\-line\-number\fR can be used to disable the
  warning or \fB\-Wno\-error=coverage\-invalid\-line\-number\fR can be used to
  disable the error.
! .IP "\fB\-Wno\-cpp\fR (C, Objective\-C, C++, Objective\-C++ and Fortran only)" 4
! .IX Item "-Wno-cpp (C, Objective-C, C++, Objective-C++ and Fortran only)"
  Suppress warning messages emitted by \f(CW\*(C`#warning\*(C'\fR directives.
! .IP "\fB\-Wdouble\-promotion\fR (C, C++, Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wdouble-promotion (C, C++, Objective-C and Objective-C++ only)"
  Give a warning when a value of type \f(CW\*(C`float\*(C'\fR is implicitly
! promoted to \f(CW\*(C`double\*(C'\fR.  CPUs with a 32\-bit "single\-precision"
! floating\-point unit implement \f(CW\*(C`float\*(C'\fR in hardware, but emulate
  \&\f(CW\*(C`double\*(C'\fR in software.  On such a machine, doing computations
  using \f(CW\*(C`double\*(C'\fR values is much more expensive because of the
  overhead required for software emulation.
  .Sp
  It is easy to accidentally do computations with \f(CW\*(C`double\*(C'\fR because
! floating\-point literals are implicitly of type \f(CW\*(C`double\*(C'\fR.  For
  example, in:
  .Sp
  .Vb 4
*************** example, in:
*** 6103,6118 ****
  .Ve
  .Sp
  the compiler performs the entire computation with \f(CW\*(C`double\*(C'\fR
! because the floating-point literal is a \f(CW\*(C`double\*(C'\fR.
! .IP "\fB\-Wduplicate\-decl\-specifier\fR (C and Objective-C only)" 4
  .IX Item "-Wduplicate-decl-specifier (C and Objective-C only)"
  Warn if a declaration has duplicate \f(CW\*(C`const\*(C'\fR, \f(CW\*(C`volatile\*(C'\fR,
  \&\f(CW\*(C`restrict\*(C'\fR or \f(CW\*(C`_Atomic\*(C'\fR specifier.  This warning is enabled by
  \&\fB\-Wall\fR.
! .IP "\fB\-Wformat\fR" 4
  .IX Item "-Wformat"
  .PD 0
! .IP "\fB\-Wformat=\fR\fIn\fR" 4
  .IX Item "-Wformat=n"
  .PD
  Check calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR, etc., to make sure that
--- 6032,6047 ----
  .Ve
  .Sp
  the compiler performs the entire computation with \f(CW\*(C`double\*(C'\fR
! because the floating\-point literal is a \f(CW\*(C`double\*(C'\fR.
! .IP "\fB\-Wduplicate\-decl\-specifier\fR (C and Objective\-C only)" 4
  .IX Item "-Wduplicate-decl-specifier (C and Objective-C only)"
  Warn if a declaration has duplicate \f(CW\*(C`const\*(C'\fR, \f(CW\*(C`volatile\*(C'\fR,
  \&\f(CW\*(C`restrict\*(C'\fR or \f(CW\*(C`_Atomic\*(C'\fR specifier.  This warning is enabled by
  \&\fB\-Wall\fR.
! .IP \fB\-Wformat\fR 4
  .IX Item "-Wformat"
  .PD 0
! .IP \fB\-Wformat=\fR\fIn\fR 4
  .IX Item "-Wformat=n"
  .PD
  Check calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR, etc., to make sure that
*************** specified, and that the conversions spec
*** 6121,6146 ****
  sense.  This includes standard functions, and others specified by format
  attributes, in the \f(CW\*(C`printf\*(C'\fR,
  \&\f(CW\*(C`scanf\*(C'\fR, \f(CW\*(C`strftime\*(C'\fR and \f(CW\*(C`strfmon\*(C'\fR (an X/Open extension,
! not in the C standard) families (or other target-specific families).
  Which functions are checked without format attributes having been
  specified depends on the standard version selected, and such checks of
  functions without the attribute specified are disabled by
  \&\fB\-ffreestanding\fR or \fB\-fno\-builtin\fR.
  .Sp
! The formats are checked against the format features supported by \s-1GNU\s0
! libc version 2.2.  These include all \s-1ISO C90\s0 and C99 features, as well
! as features from the Single Unix Specification and some \s-1BSD\s0 and \s-1GNU\s0
  extensions.  Other library implementations may not support all these
! features; \s-1GCC\s0 does not support warning about features that go beyond a
! particular library's limitations.  However, if \fB\-Wpedantic\fR is used
  with \fB\-Wformat\fR, warnings are given about format features not
  in the selected standard version (but not for \f(CW\*(C`strfmon\*(C'\fR formats,
  since those are not in any version of the C standard).
  .RS 4
! .IP "\fB\-Wformat=1\fR" 4
  .IX Item "-Wformat=1"
  .PD 0
! .IP "\fB\-Wformat\fR" 4
  .IX Item "-Wformat"
  .PD
  Option \fB\-Wformat\fR is equivalent to \fB\-Wformat=1\fR, and
--- 6050,6075 ----
  sense.  This includes standard functions, and others specified by format
  attributes, in the \f(CW\*(C`printf\*(C'\fR,
  \&\f(CW\*(C`scanf\*(C'\fR, \f(CW\*(C`strftime\*(C'\fR and \f(CW\*(C`strfmon\*(C'\fR (an X/Open extension,
! not in the C standard) families (or other target\-specific families).
  Which functions are checked without format attributes having been
  specified depends on the standard version selected, and such checks of
  functions without the attribute specified are disabled by
  \&\fB\-ffreestanding\fR or \fB\-fno\-builtin\fR.
  .Sp
! The formats are checked against the format features supported by 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\*(Aqs limitations.  However, if \fB\-Wpedantic\fR is used
  with \fB\-Wformat\fR, warnings are given about format features not
  in the selected standard version (but not for \f(CW\*(C`strfmon\*(C'\fR formats,
  since those are not in any version of the C standard).
  .RS 4
! .IP \fB\-Wformat=1\fR 4
  .IX Item "-Wformat=1"
  .PD 0
! .IP \fB\-Wformat\fR 4
  .IX Item "-Wformat"
  .PD
  Option \fB\-Wformat\fR is equivalent to \fB\-Wformat=1\fR, and
*************** aspects of this level of format checking
*** 6151,6157 ****
  options: \fB\-Wno\-format\-contains\-nul\fR,
  \&\fB\-Wno\-format\-extra\-args\fR, and \fB\-Wno\-format\-zero\-length\fR.
  \&\fB\-Wformat\fR is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wformat=2\fR" 4
  .IX Item "-Wformat=2"
  Enable \fB\-Wformat\fR plus additional format checks.  Currently
  equivalent to \fB\-Wformat \-Wformat\-nonliteral \-Wformat\-security
--- 6080,6086 ----
  options: \fB\-Wno\-format\-contains\-nul\fR,
  \&\fB\-Wno\-format\-extra\-args\fR, and \fB\-Wno\-format\-zero\-length\fR.
  \&\fB\-Wformat\fR is enabled by \fB\-Wall\fR.
! .IP \fB\-Wformat=2\fR 4
  .IX Item "-Wformat=2"
  Enable \fB\-Wformat\fR plus additional format checks.  Currently
  equivalent to \fB\-Wformat \-Wformat\-nonliteral \-Wformat\-security
*************** equivalent to \fB\-Wformat \-Wformat\-no
*** 6159,6169 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wno\-format\-contains\-nul\fR" 4
  .IX Item "-Wno-format-contains-nul"
  If \fB\-Wformat\fR is specified, do not warn about format strings that
! contain \s-1NUL\s0 bytes.
! .IP "\fB\-Wno\-format\-extra\-args\fR" 4
  .IX Item "-Wno-format-extra-args"
  If \fB\-Wformat\fR is specified, do not warn about excess arguments to a
  \&\f(CW\*(C`printf\*(C'\fR or \f(CW\*(C`scanf\*(C'\fR format function.  The C standard specifies
--- 6088,6098 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wno\-format\-contains\-nul\fR 4
  .IX Item "-Wno-format-contains-nul"
  If \fB\-Wformat\fR is specified, do not warn about format strings that
! contain NUL bytes.
! .IP \fB\-Wno\-format\-extra\-args\fR 4
  .IX Item "-Wno-format-extra-args"
  If \fB\-Wformat\fR is specified, do not warn about excess arguments to a
  \&\f(CW\*(C`printf\*(C'\fR or \f(CW\*(C`scanf\*(C'\fR format function.  The C standard specifies
*************** type to pass to \f(CW\*(C`va_arg\*(C'\fR
*** 6176,6199 ****
  in the case of \f(CW\*(C`scanf\*(C'\fR formats, this option suppresses the
  warning if the unused arguments are all pointers, since the Single
  Unix Specification says that such unused arguments are allowed.
! .IP "\fB\-Wformat\-overflow\fR" 4
  .IX Item "-Wformat-overflow"
  .PD 0
! .IP "\fB\-Wformat\-overflow=\fR\fIlevel\fR" 4
  .IX Item "-Wformat-overflow=level"
  .PD
  Warn about calls to formatted input/output functions such as \f(CW\*(C`sprintf\*(C'\fR
  and \f(CW\*(C`vsprintf\*(C'\fR that might overflow the destination buffer.  When the
  exact number of bytes written by a format directive cannot be determined
! at compile-time it is estimated based on heuristics that depend on the
  \&\fIlevel\fR argument and on optimization.  While enabling optimization
  will in most cases improve the accuracy of the warning, it may also
  result in false positives.
  .RS 4
! .IP "\fB\-Wformat\-overflow\fR" 4
  .IX Item "-Wformat-overflow"
  .PD 0
! .IP "\fB\-Wformat\-overflow=1\fR" 4
  .IX Item "-Wformat-overflow=1"
  .PD
  Level \fI1\fR of \fB\-Wformat\-overflow\fR enabled by \fB\-Wformat\fR
--- 6105,6128 ----
  in the case of \f(CW\*(C`scanf\*(C'\fR formats, this option suppresses the
  warning if the unused arguments are all pointers, since the Single
  Unix Specification says that such unused arguments are allowed.
! .IP \fB\-Wformat\-overflow\fR 4
  .IX Item "-Wformat-overflow"
  .PD 0
! .IP \fB\-Wformat\-overflow=\fR\fIlevel\fR 4
  .IX Item "-Wformat-overflow=level"
  .PD
  Warn about calls to formatted input/output functions such as \f(CW\*(C`sprintf\*(C'\fR
  and \f(CW\*(C`vsprintf\*(C'\fR that might overflow the destination buffer.  When the
  exact number of bytes written by a format directive cannot be determined
! at compile\-time it is estimated based on heuristics that depend on the
  \&\fIlevel\fR argument and on optimization.  While enabling optimization
  will in most cases improve the accuracy of the warning, it may also
  result in false positives.
  .RS 4
! .IP \fB\-Wformat\-overflow\fR 4
  .IX Item "-Wformat-overflow"
  .PD 0
! .IP \fB\-Wformat\-overflow=1\fR 4
  .IX Item "-Wformat-overflow=1"
  .PD
  Level \fI1\fR of \fB\-Wformat\-overflow\fR enabled by \fB\-Wformat\fR
*************** likely overflow the buffer.  At this lev
*** 6202,6212 ****
  directives with unknown values are assumed to have the value of one, and
  strings of unknown length to be empty.  Numeric arguments that are known
  to be bounded to a subrange of their type, or string arguments whose output
! is bounded either by their directive's precision or by a finite set of
  string literals, are assumed to take on the value within the range that
  results in the most bytes on output.  For example, the call to \f(CW\*(C`sprintf\*(C'\fR
  below is diagnosed because even with both \fIa\fR and \fIb\fR equal to zero,
! the terminating \s-1NUL\s0 character (\f(CW\*(Aq\e0\*(Aq\fR) appended by the function
  to the destination buffer will be written past its end.  Increasing
  the size of the buffer by a single byte is sufficient to avoid the
  warning, though it may not be sufficient to avoid the overflow.
--- 6131,6141 ----
  directives with unknown values are assumed to have the value of one, and
  strings of unknown length to be empty.  Numeric arguments that are known
  to be bounded to a subrange of their type, or string arguments whose output
! is bounded either by their directive\*(Aqs precision or by a finite set of
  string literals, are assumed to take on the value within the range that
  results in the most bytes on output.  For example, the call to \f(CW\*(C`sprintf\*(C'\fR
  below is diagnosed because even with both \fIa\fR and \fIb\fR equal to zero,
! the terminating NUL character (\f(CW\*(Aq\e0\*(Aq\fR) appended by the function
  to the destination buffer will be written past its end.  Increasing
  the size of the buffer by a single byte is sufficient to avoid the
  warning, though it may not be sufficient to avoid the overflow.
*************** warning, though it may not be sufficient
*** 6218,6231 ****
  \&          sprintf (buf, "a = %i, b = %i\en", a, b);
  \&        }
  .Ve
! .IP "\fB\-Wformat\-overflow=2\fR" 4
  .IX Item "-Wformat-overflow=2"
  Level \fI2\fR warns also about calls that might overflow the destination
  buffer given an argument of sufficient length or magnitude.  At level
  \&\fI2\fR, unknown numeric arguments are assumed to have the minimum
  representable value for signed types with a precision greater than 1, and
  the maximum representable value otherwise.  Unknown string arguments whose
! length cannot be assumed to be bounded either by the directive's precision,
  or by a finite set of string literals they may evaluate to, or the character
  array they may point to, are assumed to be 1 character long.
  .Sp
--- 6147,6160 ----
  \&          sprintf (buf, "a = %i, b = %i\en", a, b);
  \&        }
  .Ve
! .IP \fB\-Wformat\-overflow=2\fR 4
  .IX Item "-Wformat-overflow=2"
  Level \fI2\fR warns also about calls that might overflow the destination
  buffer given an argument of sufficient length or magnitude.  At level
  \&\fI2\fR, unknown numeric arguments are assumed to have the minimum
  representable value for signed types with a precision greater than 1, and
  the maximum representable value otherwise.  Unknown string arguments whose
! length cannot be assumed to be bounded either by the directive\*(Aqs precision,
  or by a finite set of string literals they may evaluate to, or the character
  array they may point to, are assumed to be 1 character long.
  .Sp
*************** this time because with \fIa\fR equal to
*** 6234,6240 ****
  \&\f(CW%i\fR directive will write some of its digits beyond the end of
  the destination buffer.  To make the call safe regardless of the values
  of the two variables, the size of the destination buffer must be increased
! to at least 34 bytes.  \s-1GCC\s0 includes the minimum size of the buffer in
  an informational note following the warning.
  .Sp
  An alternative to increasing the size of the destination buffer is to
--- 6163,6169 ----
  \&\f(CW%i\fR directive will write some of its digits beyond the end of
  the destination buffer.  To make the call safe regardless of the values
  of the two variables, the size of the destination buffer must be increased
! to at least 34 bytes.  GCC includes the minimum size of the buffer in
  an informational note following the warning.
  .Sp
  An alternative to increasing the size of the destination buffer is to
*************** required size of the buffer to 24 bytes.
*** 6259,6314 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wno\-format\-zero\-length\fR" 4
  .IX Item "-Wno-format-zero-length"
! If \fB\-Wformat\fR is specified, do not warn about zero-length formats.
! The C standard specifies that zero-length formats are allowed.
! .IP "\fB\-Wformat\-nonliteral\fR" 4
  .IX Item "-Wformat-nonliteral"
  If \fB\-Wformat\fR is specified, also warn if the format string is not a
  string literal and so cannot be checked, unless the format function
  takes its format arguments as a \f(CW\*(C`va_list\*(C'\fR.
! .IP "\fB\-Wformat\-security\fR" 4
  .IX Item "-Wformat-security"
  If \fB\-Wformat\fR is specified, also warn about uses of format
  functions that represent possible security problems.  At present, this
  warns about calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR functions where the
  format string is not a string literal and there are no format arguments,
  as in \f(CW\*(C`printf (foo);\*(C'\fR.  This may be a security hole if the format
! string came from untrusted input and contains \fB\f(CB%n\fB\fR.  (This is
  currently a subset of what \fB\-Wformat\-nonliteral\fR warns about, but
  in future warnings may be added to \fB\-Wformat\-security\fR that are not
  included in \fB\-Wformat\-nonliteral\fR.)
! .IP "\fB\-Wformat\-signedness\fR" 4
  .IX Item "-Wformat-signedness"
  If \fB\-Wformat\fR is specified, also warn if the format string
  requires an unsigned argument and the argument is signed and vice versa.
! .IP "\fB\-Wformat\-truncation\fR" 4
  .IX Item "-Wformat-truncation"
  .PD 0
! .IP "\fB\-Wformat\-truncation=\fR\fIlevel\fR" 4
  .IX Item "-Wformat-truncation=level"
  .PD
  Warn about calls to formatted input/output functions such as \f(CW\*(C`snprintf\*(C'\fR
  and \f(CW\*(C`vsnprintf\*(C'\fR that might result in output truncation.  When the exact
  number of bytes written by a format directive cannot be determined at
! compile-time it is estimated based on heuristics that depend on
  the \fIlevel\fR argument and on optimization.  While enabling optimization
  will in most cases improve the accuracy of the warning, it may also result
  in false positives.  Except as noted otherwise, the option uses the same
  logic \fB\-Wformat\-overflow\fR.
  .RS 4
! .IP "\fB\-Wformat\-truncation\fR" 4
  .IX Item "-Wformat-truncation"
  .PD 0
! .IP "\fB\-Wformat\-truncation=1\fR" 4
  .IX Item "-Wformat-truncation=1"
  .PD
  Level \fI1\fR of \fB\-Wformat\-truncation\fR enabled by \fB\-Wformat\fR
  employs a conservative approach that warns only about calls to bounded
  functions whose return value is unused and that will most likely result
  in output truncation.
! .IP "\fB\-Wformat\-truncation=2\fR" 4
  .IX Item "-Wformat-truncation=2"
  Level \fI2\fR warns also about calls to bounded functions whose return
  value is used and that might result in truncation given an argument of
--- 6188,6243 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wno\-format\-zero\-length\fR 4
  .IX Item "-Wno-format-zero-length"
! If \fB\-Wformat\fR is specified, do not warn about zero\-length formats.
! The C standard specifies that zero\-length formats are allowed.
! .IP \fB\-Wformat\-nonliteral\fR 4
  .IX Item "-Wformat-nonliteral"
  If \fB\-Wformat\fR is specified, also warn if the format string is not a
  string literal and so cannot be checked, unless the format function
  takes its format arguments as a \f(CW\*(C`va_list\*(C'\fR.
! .IP \fB\-Wformat\-security\fR 4
  .IX Item "-Wformat-security"
  If \fB\-Wformat\fR is specified, also warn about uses of format
  functions that represent possible security problems.  At present, this
  warns about calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR functions where the
  format string is not a string literal and there are no format arguments,
  as in \f(CW\*(C`printf (foo);\*(C'\fR.  This may be a security hole if the format
! string came from untrusted input and contains \fR\f(CB%n\fR\fB\fR.  (This is
  currently a subset of what \fB\-Wformat\-nonliteral\fR warns about, but
  in future warnings may be added to \fB\-Wformat\-security\fR that are not
  included in \fB\-Wformat\-nonliteral\fR.)
! .IP \fB\-Wformat\-signedness\fR 4
  .IX Item "-Wformat-signedness"
  If \fB\-Wformat\fR is specified, also warn if the format string
  requires an unsigned argument and the argument is signed and vice versa.
! .IP \fB\-Wformat\-truncation\fR 4
  .IX Item "-Wformat-truncation"
  .PD 0
! .IP \fB\-Wformat\-truncation=\fR\fIlevel\fR 4
  .IX Item "-Wformat-truncation=level"
  .PD
  Warn about calls to formatted input/output functions such as \f(CW\*(C`snprintf\*(C'\fR
  and \f(CW\*(C`vsnprintf\*(C'\fR that might result in output truncation.  When the exact
  number of bytes written by a format directive cannot be determined at
! compile\-time it is estimated based on heuristics that depend on
  the \fIlevel\fR argument and on optimization.  While enabling optimization
  will in most cases improve the accuracy of the warning, it may also result
  in false positives.  Except as noted otherwise, the option uses the same
  logic \fB\-Wformat\-overflow\fR.
  .RS 4
! .IP \fB\-Wformat\-truncation\fR 4
  .IX Item "-Wformat-truncation"
  .PD 0
! .IP \fB\-Wformat\-truncation=1\fR 4
  .IX Item "-Wformat-truncation=1"
  .PD
  Level \fI1\fR of \fB\-Wformat\-truncation\fR enabled by \fB\-Wformat\fR
  employs a conservative approach that warns only about calls to bounded
  functions whose return value is unused and that will most likely result
  in output truncation.
! .IP \fB\-Wformat\-truncation=2\fR 4
  .IX Item "-Wformat-truncation=2"
  Level \fI2\fR warns also about calls to bounded functions whose return
  value is used and that might result in truncation given an argument of
*************** sufficient length or magnitude.
*** 6316,6347 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wformat\-y2k\fR" 4
  .IX Item "-Wformat-y2k"
  If \fB\-Wformat\fR is specified, also warn about \f(CW\*(C`strftime\*(C'\fR
! formats that may yield only a two-digit year.
! .IP "\fB\-Wnonnull\fR" 4
  .IX Item "-Wnonnull"
  Warn about passing a null pointer for arguments marked as
! requiring a non-null value by the \f(CW\*(C`nonnull\*(C'\fR function attribute.
  .Sp
  \&\fB\-Wnonnull\fR is included in \fB\-Wall\fR and \fB\-Wformat\fR.  It
  can be disabled with the \fB\-Wno\-nonnull\fR option.
! .IP "\fB\-Wnonnull\-compare\fR" 4
  .IX Item "-Wnonnull-compare"
  Warn when comparing an argument marked with the \f(CW\*(C`nonnull\*(C'\fR
  function attribute against null inside the function.
  .Sp
  \&\fB\-Wnonnull\-compare\fR is included in \fB\-Wall\fR.  It
  can be disabled with the \fB\-Wno\-nonnull\-compare\fR option.
! .IP "\fB\-Wnull\-dereference\fR" 4
  .IX Item "-Wnull-dereference"
  Warn if the compiler detects paths that trigger erroneous or
  undefined behavior due to dereferencing a null pointer.  This option
  is only active when \fB\-fdelete\-null\-pointer\-checks\fR is active,
  which is enabled by optimizations in most targets.  The precision of
  the warnings depends on the optimization options used.
! .IP "\fB\-Winfinite\-recursion\fR" 4
  .IX Item "-Winfinite-recursion"
  Warn about infinitely recursive calls.  The warning is effective at all
  optimization levels but requires optimization in order to detect infinite
--- 6245,6276 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wformat\-y2k\fR 4
  .IX Item "-Wformat-y2k"
  If \fB\-Wformat\fR is specified, also warn about \f(CW\*(C`strftime\*(C'\fR
! formats that may yield only a two\-digit year.
! .IP \fB\-Wnonnull\fR 4
  .IX Item "-Wnonnull"
  Warn about passing a null pointer for arguments marked as
! requiring a non\-null value by the \f(CW\*(C`nonnull\*(C'\fR function attribute.
  .Sp
  \&\fB\-Wnonnull\fR is included in \fB\-Wall\fR and \fB\-Wformat\fR.  It
  can be disabled with the \fB\-Wno\-nonnull\fR option.
! .IP \fB\-Wnonnull\-compare\fR 4
  .IX Item "-Wnonnull-compare"
  Warn when comparing an argument marked with the \f(CW\*(C`nonnull\*(C'\fR
  function attribute against null inside the function.
  .Sp
  \&\fB\-Wnonnull\-compare\fR is included in \fB\-Wall\fR.  It
  can be disabled with the \fB\-Wno\-nonnull\-compare\fR option.
! .IP \fB\-Wnull\-dereference\fR 4
  .IX Item "-Wnull-dereference"
  Warn if the compiler detects paths that trigger erroneous or
  undefined behavior due to dereferencing a null pointer.  This option
  is only active when \fB\-fdelete\-null\-pointer\-checks\fR is active,
  which is enabled by optimizations in most targets.  The precision of
  the warnings depends on the optimization options used.
! .IP \fB\-Winfinite\-recursion\fR 4
  .IX Item "-Winfinite-recursion"
  Warn about infinitely recursive calls.  The warning is effective at all
  optimization levels but requires optimization in order to detect infinite
*************** recursion in calls between two or more f
*** 6351,6362 ****
  Compare with \fB\-Wanalyzer\-infinite\-recursion\fR which provides a
  similar diagnostic, but is implemented in a different way (as part of
  \&\fB\-fanalyzer\fR).
! .IP "\fB\-Winit\-self\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Winit-self (C, , Objective-C and Objective- only)"
  Warn about uninitialized variables that are initialized with themselves.
  Note this option can only be used with the \fB\-Wuninitialized\fR option.
  .Sp
! For example, \s-1GCC\s0 warns about \f(CW\*(C`i\*(C'\fR being uninitialized in the
  following snippet only when \fB\-Winit\-self\fR has been specified:
  .Sp
  .Vb 5
--- 6280,6291 ----
  Compare with \fB\-Wanalyzer\-infinite\-recursion\fR which provides a
  similar diagnostic, but is implemented in a different way (as part of
  \&\fB\-fanalyzer\fR).
! .IP "\fB\-Winit\-self\fR (C, C++, Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Winit-self (C, C++, Objective-C and Objective-C++ only)"
  Warn about uninitialized variables that are initialized with themselves.
  Note this option can only be used with the \fB\-Wuninitialized\fR option.
  .Sp
! For example, GCC warns about \f(CW\*(C`i\*(C'\fR being uninitialized in the
  following snippet only when \fB\-Winit\-self\fR has been specified:
  .Sp
  .Vb 5
*************** following snippet only when \fB\-Winit\-
*** 6367,6394 ****
  \&        }
  .Ve
  .Sp
! This warning is enabled by \fB\-Wall\fR in \*(C+.
! .IP "\fB\-Wno\-implicit\-int\fR (C and Objective-C only)" 4
  .IX Item "-Wno-implicit-int (C and Objective-C only)"
  This option controls warnings when a declaration does not specify a type.
  This warning is enabled by default in C99 and later dialects of C,
  and also by \fB\-Wall\fR.
! .IP "\fB\-Wno\-implicit\-function\-declaration\fR (C and Objective-C only)" 4
  .IX Item "-Wno-implicit-function-declaration (C and Objective-C only)"
  This option controls warnings when a function is used before being declared.
  This warning is enabled by default in C99 and later dialects of C,
  and also by \fB\-Wall\fR.
  The warning is made into an error by \fB\-pedantic\-errors\fR.
! .IP "\fB\-Wimplicit\fR (C and Objective-C only)" 4
  .IX Item "-Wimplicit (C and Objective-C only)"
  Same as \fB\-Wimplicit\-int\fR and \fB\-Wimplicit\-function\-declaration\fR.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wimplicit\-fallthrough\fR" 4
  .IX Item "-Wimplicit-fallthrough"
  \&\fB\-Wimplicit\-fallthrough\fR is the same as \fB\-Wimplicit\-fallthrough=3\fR
  and \fB\-Wno\-implicit\-fallthrough\fR is the same as
  \&\fB\-Wimplicit\-fallthrough=0\fR.
! .IP "\fB\-Wimplicit\-fallthrough=\fR\fIn\fR" 4
  .IX Item "-Wimplicit-fallthrough=n"
  Warn when a switch case falls through.  For example:
  .Sp
--- 6296,6323 ----
  \&        }
  .Ve
  .Sp
! This warning is enabled by \fB\-Wall\fR in C++.
! .IP "\fB\-Wno\-implicit\-int\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-implicit-int (C and Objective-C only)"
  This option controls warnings when a declaration does not specify a type.
  This warning is enabled by default in C99 and later dialects of C,
  and also by \fB\-Wall\fR.
! .IP "\fB\-Wno\-implicit\-function\-declaration\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-implicit-function-declaration (C and Objective-C only)"
  This option controls warnings when a function is used before being declared.
  This warning is enabled by default in C99 and later dialects of C,
  and also by \fB\-Wall\fR.
  The warning is made into an error by \fB\-pedantic\-errors\fR.
! .IP "\fB\-Wimplicit\fR (C and Objective\-C only)" 4
  .IX Item "-Wimplicit (C and Objective-C only)"
  Same as \fB\-Wimplicit\-int\fR and \fB\-Wimplicit\-function\-declaration\fR.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wimplicit\-fallthrough\fR 4
  .IX Item "-Wimplicit-fallthrough"
  \&\fB\-Wimplicit\-fallthrough\fR is the same as \fB\-Wimplicit\-fallthrough=3\fR
  and \fB\-Wno\-implicit\-fallthrough\fR is the same as
  \&\fB\-Wimplicit\-fallthrough=0\fR.
! .IP \fB\-Wimplicit\-fallthrough=\fR\fIn\fR 4
  .IX Item "-Wimplicit-fallthrough=n"
  Warn when a switch case falls through.  For example:
  .Sp
*************** warns when appropriate.  E.g.
*** 6429,6435 ****
  .Ve
  .Sp
  Since there are occasions where a switch case fall through is desirable,
! \&\s-1GCC\s0 provides an attribute, \f(CW\*(C`_\|_attribute_\|_ ((fallthrough))\*(C'\fR, that is
  to be used along with a null statement to suppress this warning that
  would normally occur:
  .Sp
--- 6358,6364 ----
  .Ve
  .Sp
  Since there are occasions where a switch case fall through is desirable,
! GCC provides an attribute, \f(CW\*(C`_\|_attribute_\|_ ((fallthrough))\*(C'\fR, that is
  to be used along with a null statement to suppress this warning that
  would normally occur:
  .Sp
*************** would normally occur:
*** 6444,6454 ****
  \&          }
  .Ve
  .Sp
! \&\*(C+17 provides a standard way to suppress the \fB\-Wimplicit\-fallthrough\fR
! warning using \f(CW\*(C`[[fallthrough]];\*(C'\fR instead of the \s-1GNU\s0 attribute.  In \*(C+11
! or \*(C+14 users can use \f(CW\*(C`[[gnu::fallthrough]];\*(C'\fR, which is a \s-1GNU\s0 extension.
  Instead of these attributes, it is also possible to add a fallthrough comment
! to silence the warning.  The whole body of the C or \*(C+ style comment should
  match the given regular expressions listed below.  The option argument \fIn\fR
  specifies what kind of comments are accepted:
  .RS 4
--- 6373,6383 ----
  \&          }
  .Ve
  .Sp
! C++17 provides a standard way to suppress the \fB\-Wimplicit\-fallthrough\fR
! warning using \f(CW\*(C`[[fallthrough]];\*(C'\fR instead of the GNU attribute.  In C++11
! or C++14 users can use \f(CW\*(C`[[gnu::fallthrough]];\*(C'\fR, which is a GNU extension.
  Instead of these attributes, it is also possible to add a fallthrough comment
! to silence the warning.  The whole body of the C or C++ style comment should
  match the given regular expressions listed below.  The option argument \fIn\fR
  specifies what kind of comments are accepted:
  .RS 4
*************** expression, any comment is used as fallt
*** 6468,6478 ****
  following regular expressions:
  .RS 4
  .ie n .IP "*<""\-fallthrough"">" 4
! .el .IP "*<\f(CW\-fallthrough\fR>" 4
  .IX Item "*<-fallthrough>"
  .PD 0
  .ie n .IP "*<""@fallthrough@"">" 4
! .el .IP "*<\f(CW@fallthrough@\fR>" 4
  .IX Item "*<@fallthrough@>"
  .ie n .IP "*<""lint \-fallthrough[ \et]*"">" 4
  .el .IP "*<\f(CWlint \-fallthrough[ \et]*\fR>" 4
--- 6397,6407 ----
  following regular expressions:
  .RS 4
  .ie n .IP "*<""\-fallthrough"">" 4
! .el .IP *<\f(CW\-fallthrough\fR> 4
  .IX Item "*<-fallthrough>"
  .PD 0
  .ie n .IP "*<""@fallthrough@"">" 4
! .el .IP *<\f(CW@fallthrough@\fR> 4
  .IX Item "*<@fallthrough@>"
  .ie n .IP "*<""lint \-fallthrough[ \et]*"">" 4
  .el .IP "*<\f(CWlint \-fallthrough[ \et]*\fR>" 4
*************** following regular expressions:
*** 6486,6505 ****
  .ie n .IP "*<""[ \et.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |\-)?thr(ough|u)[ \et.!]*(\-[^\en\er]*)?"">" 4
  .el .IP "*<\f(CW[ \et.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |\-)?thr(ough|u)[ \et.!]*(\-[^\en\er]*)?\fR>" 4
  .IX Item "*<[ t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |-)?thr(ough|u)[ t.!]*(-[^nr]*)?>"
  .RE
  .RS 4
  .RE
  .IP "*<\fB\-Wimplicit\-fallthrough=4\fR case sensitively matches one of the>" 4
  .IX Item "*<-Wimplicit-fallthrough=4 case sensitively matches one of the>"
- .PD
  following regular expressions:
  .RS 4
  .ie n .IP "*<""\-fallthrough"">" 4
! .el .IP "*<\f(CW\-fallthrough\fR>" 4
  .IX Item "*<-fallthrough>"
  .PD 0
  .ie n .IP "*<""@fallthrough@"">" 4
! .el .IP "*<\f(CW@fallthrough@\fR>" 4
  .IX Item "*<@fallthrough@>"
  .ie n .IP "*<""lint \-fallthrough[ \et]*"">" 4
  .el .IP "*<\f(CWlint \-fallthrough[ \et]*\fR>" 4
--- 6415,6434 ----
  .ie n .IP "*<""[ \et.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |\-)?thr(ough|u)[ \et.!]*(\-[^\en\er]*)?"">" 4
  .el .IP "*<\f(CW[ \et.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |\-)?thr(ough|u)[ \et.!]*(\-[^\en\er]*)?\fR>" 4
  .IX Item "*<[ t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |-)?thr(ough|u)[ t.!]*(-[^nr]*)?>"
+ .PD
  .RE
  .RS 4
  .RE
  .IP "*<\fB\-Wimplicit\-fallthrough=4\fR case sensitively matches one of the>" 4
  .IX Item "*<-Wimplicit-fallthrough=4 case sensitively matches one of the>"
  following regular expressions:
  .RS 4
  .ie n .IP "*<""\-fallthrough"">" 4
! .el .IP *<\f(CW\-fallthrough\fR> 4
  .IX Item "*<-fallthrough>"
  .PD 0
  .ie n .IP "*<""@fallthrough@"">" 4
! .el .IP *<\f(CW@fallthrough@\fR> 4
  .IX Item "*<@fallthrough@>"
  .ie n .IP "*<""lint \-fallthrough[ \et]*"">" 4
  .el .IP "*<\f(CWlint \-fallthrough[ \et]*\fR>" 4
*************** following regular expressions:
*** 6507,6518 ****
  .ie n .IP "*<""[ \et]*FALLTHR(OUGH|U)[ \et]*"">" 4
  .el .IP "*<\f(CW[ \et]*FALLTHR(OUGH|U)[ \et]*\fR>" 4
  .IX Item "*<[ t]*FALLTHR(OUGH|U)[ t]*>"
  .RE
  .RS 4
  .RE
! .IP "*<\fB\-Wimplicit\-fallthrough=5\fR doesn't recognize any comments as>" 4
  .IX Item "*<-Wimplicit-fallthrough=5 doesn't recognize any comments as>"
- .PD
  fallthrough comments, only attributes disable the warning.
  .RE
  .RS 4
--- 6436,6447 ----
  .ie n .IP "*<""[ \et]*FALLTHR(OUGH|U)[ \et]*"">" 4
  .el .IP "*<\f(CW[ \et]*FALLTHR(OUGH|U)[ \et]*\fR>" 4
  .IX Item "*<[ t]*FALLTHR(OUGH|U)[ t]*>"
+ .PD
  .RE
  .RS 4
  .RE
! .IP "*<\fB\-Wimplicit\-fallthrough=5\fR doesn\*(Aqt recognize any comments as>" 4
  .IX Item "*<-Wimplicit-fallthrough=5 doesn't recognize any comments as>"
  fallthrough comments, only attributes disable the warning.
  .RE
  .RS 4
*************** by \f(CW\*(C`case\*(C'\fR or \f(CW\*(C`d
*** 6534,6577 ****
  .Sp
  The \fB\-Wimplicit\-fallthrough=3\fR warning is enabled by \fB\-Wextra\fR.
  .RE
! .IP "\fB\-Wno\-if\-not\-aligned\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-if-not-aligned (C, , Objective-C and Objective- only)"
  Control if warnings triggered by the \f(CW\*(C`warn_if_not_aligned\*(C'\fR attribute
  should be issued.  These warnings are enabled by default.
! .IP "\fB\-Wignored\-qualifiers\fR (C and \*(C+ only)" 4
! .IX Item "-Wignored-qualifiers (C and only)"
  Warn if the return type of a function has a type qualifier
! such as \f(CW\*(C`const\*(C'\fR.  For \s-1ISO C\s0 such a type qualifier has no effect,
  since the value returned by a function is not an lvalue.
! For \*(C+, the warning is only emitted for scalar types or \f(CW\*(C`void\*(C'\fR.
! \&\s-1ISO C\s0 prohibits qualified \f(CW\*(C`void\*(C'\fR return types on function
  definitions, so such return types always receive a warning
  even without this option.
  .Sp
  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wno\-ignored\-attributes\fR (C and \*(C+ only)" 4
! .IX Item "-Wno-ignored-attributes (C and only)"
  This option controls warnings when an attribute is ignored.
  This is different from the
  \&\fB\-Wattributes\fR option in that it warns whenever the compiler decides
  to drop an attribute, not that the attribute is either unknown, used in a
  wrong place, etc.  This warning is enabled by default.
! .IP "\fB\-Wmain\fR" 4
  .IX Item "-Wmain"
  Warn if the type of \f(CW\*(C`main\*(C'\fR is suspicious.  \f(CW\*(C`main\*(C'\fR should be
  a function with external linkage, returning int, taking either zero
  arguments, two, or three arguments of appropriate types.  This warning
! is enabled by default in \*(C+ and is enabled by either \fB\-Wall\fR
  or \fB\-Wpedantic\fR.
! .IP "\fB\-Wmisleading\-indentation\fR (C and \*(C+ only)" 4
! .IX Item "-Wmisleading-indentation (C and only)"
  Warn when the indentation of the code does not reflect the block structure.
  Specifically, a warning is issued for \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR, \f(CW\*(C`while\*(C'\fR, and
  \&\f(CW\*(C`for\*(C'\fR clauses with a guarded statement that does not use braces,
  followed by an unguarded statement with the same indentation.
  .Sp
! In the following example, the call to \*(L"bar\*(R" is misleadingly indented as
! if it were guarded by the \*(L"if\*(R" conditional.
  .Sp
  .Vb 3
  \&          if (some_condition ())
--- 6463,6506 ----
  .Sp
  The \fB\-Wimplicit\-fallthrough=3\fR warning is enabled by \fB\-Wextra\fR.
  .RE
! .IP "\fB\-Wno\-if\-not\-aligned\fR (C, C++, Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wno-if-not-aligned (C, C++, Objective-C and Objective-C++ only)"
  Control if warnings triggered by the \f(CW\*(C`warn_if_not_aligned\*(C'\fR attribute
  should be issued.  These warnings are enabled by default.
! .IP "\fB\-Wignored\-qualifiers\fR (C and C++ only)" 4
! .IX Item "-Wignored-qualifiers (C and C++ only)"
  Warn if the return type of a function has a type qualifier
! such as \f(CW\*(C`const\*(C'\fR.  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 \f(CW\*(C`void\*(C'\fR.
! ISO C prohibits qualified \f(CW\*(C`void\*(C'\fR return types on function
  definitions, so such return types always receive a warning
  even without this option.
  .Sp
  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wno\-ignored\-attributes\fR (C and C++ only)" 4
! .IX Item "-Wno-ignored-attributes (C and C++ only)"
  This option controls warnings when an attribute is ignored.
  This is different from the
  \&\fB\-Wattributes\fR option in that it warns whenever the compiler decides
  to drop an attribute, not that the attribute is either unknown, used in a
  wrong place, etc.  This warning is enabled by default.
! .IP \fB\-Wmain\fR 4
  .IX Item "-Wmain"
  Warn if the type of \f(CW\*(C`main\*(C'\fR is suspicious.  \f(CW\*(C`main\*(C'\fR should be
  a function with external linkage, returning int, taking either zero
  arguments, two, or three arguments of appropriate types.  This warning
! is enabled by default in C++ and is enabled by either \fB\-Wall\fR
  or \fB\-Wpedantic\fR.
! .IP "\fB\-Wmisleading\-indentation\fR (C and C++ only)" 4
! .IX Item "-Wmisleading-indentation (C and C++ only)"
  Warn when the indentation of the code does not reflect the block structure.
  Specifically, a warning is issued for \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR, \f(CW\*(C`while\*(C'\fR, and
  \&\f(CW\*(C`for\*(C'\fR clauses with a guarded statement that does not use braces,
  followed by an unguarded statement with the same indentation.
  .Sp
! In the following example, the call to "bar" is misleadingly indented as
! if it were guarded by the "if" conditional.
  .Sp
  .Vb 3
  \&          if (some_condition ())
*************** The warning is not issued after a \f(CW\
*** 6599,6606 ****
  typically indicates autogenerated code, and no assumptions can be made
  about the layout of the file that the directive references.
  .Sp
! This warning is enabled by \fB\-Wall\fR in C and \*(C+.
! .IP "\fB\-Wmissing\-attributes\fR" 4
  .IX Item "-Wmissing-attributes"
  Warn when a declaration of a function is missing one or more attributes
  that a related function is declared with and whose absence may adversely
--- 6528,6535 ----
  typically indicates autogenerated code, and no assumptions can be made
  about the layout of the file that the directive references.
  .Sp
! This warning is enabled by \fB\-Wall\fR in C and C++.
! .IP \fB\-Wmissing\-attributes\fR 4
  .IX Item "-Wmissing-attributes"
  Warn when a declaration of a function is missing one or more attributes
  that a related function is declared with and whose absence may adversely
*************** Attributes considered include \f(CW\*(C`
*** 6616,6622 ****
  \&\f(CW\*(C`nonnull\*(C'\fR, \f(CW\*(C`noreturn\*(C'\fR, \f(CW\*(C`nothrow\*(C'\fR, \f(CW\*(C`pure\*(C'\fR,
  \&\f(CW\*(C`returns_nonnull\*(C'\fR, and \f(CW\*(C`returns_twice\*(C'\fR.
  .Sp
! In \*(C+, the warning is issued when an explicit specialization of a primary
  template declared with attribute \f(CW\*(C`alloc_align\*(C'\fR, \f(CW\*(C`alloc_size\*(C'\fR,
  \&\f(CW\*(C`assume_aligned\*(C'\fR, \f(CW\*(C`format\*(C'\fR, \f(CW\*(C`format_arg\*(C'\fR, \f(CW\*(C`malloc\*(C'\fR,
  or \f(CW\*(C`nonnull\*(C'\fR is declared without it.  Attributes \f(CW\*(C`deprecated\*(C'\fR,
--- 6545,6551 ----
  \&\f(CW\*(C`nonnull\*(C'\fR, \f(CW\*(C`noreturn\*(C'\fR, \f(CW\*(C`nothrow\*(C'\fR, \f(CW\*(C`pure\*(C'\fR,
  \&\f(CW\*(C`returns_nonnull\*(C'\fR, and \f(CW\*(C`returns_twice\*(C'\fR.
  .Sp
! In C++, the warning is issued when an explicit specialization of a primary
  template declared with attribute \f(CW\*(C`alloc_align\*(C'\fR, \f(CW\*(C`alloc_size\*(C'\fR,
  \&\f(CW\*(C`assume_aligned\*(C'\fR, \f(CW\*(C`format\*(C'\fR, \f(CW\*(C`format_arg\*(C'\fR, \f(CW\*(C`malloc\*(C'\fR,
  or \f(CW\*(C`nonnull\*(C'\fR is declared without it.  Attributes \f(CW\*(C`deprecated\*(C'\fR,
*************** diagnosed because it is missing one of t
*** 6644,6650 ****
  \&        void* _\|_attribute_\|_ ((malloc))   // missing alloc_size
  \&        allocate (size_t);
  .Ve
! .IP "\fB\-Wmissing\-braces\fR" 4
  .IX Item "-Wmissing-braces"
  Warn if an aggregate or union initializer is not fully bracketed.  In
  the following example, the initializer for \f(CW\*(C`a\*(C'\fR is not fully
--- 6573,6579 ----
  \&        void* _\|_attribute_\|_ ((malloc))   // missing alloc_size
  \&        allocate (size_t);
  .Ve
! .IP \fB\-Wmissing\-braces\fR 4
  .IX Item "-Wmissing-braces"
  Warn if an aggregate or union initializer is not fully bracketed.  In
  the following example, the initializer for \f(CW\*(C`a\*(C'\fR is not fully
*************** bracketed, but that for \f(CW\*(C`b\*(C'
*** 6656,6667 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wmissing\-include\-dirs\fR (C, \*(C+, Objective-C, Objective\-\*(C+ and Fortran only)" 4
! .IX Item "-Wmissing-include-dirs (C, , Objective-C, Objective- and Fortran only)"
! Warn if a user-supplied include directory does not exist. This option is disabled
! by default for C, \*(C+, Objective-C and Objective\-\*(C+. For Fortran, it is partially
  enabled by default by warning for \-I and \-J, only.
! .IP "\fB\-Wno\-missing\-profile\fR" 4
  .IX Item "-Wno-missing-profile"
  This option controls warnings if feedback profiles are missing when using the
  \&\fB\-fprofile\-use\fR option.
--- 6585,6596 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wmissing\-include\-dirs\fR (C, C++, Objective\-C, Objective\-C++ and Fortran only)" 4
! .IX Item "-Wmissing-include-dirs (C, C++, Objective-C, Objective-C++ and Fortran only)"
! Warn if a user\-supplied include directory does not exist. This option is disabled
! by default for C, C++, Objective\-C and Objective\-C++. For Fortran, it is partially
  enabled by default by warning for \-I and \-J, only.
! .IP \fB\-Wno\-missing\-profile\fR 4
  .IX Item "-Wno-missing-profile"
  This option controls warnings if feedback profiles are missing when using the
  \&\fB\-fprofile\-use\fR option.
*************** between compiling with \fB\-fprofile\-ge
*** 6671,6692 ****
  In these cases, the profile feedback data files do not contain any
  profile feedback information for
  the newly added function or file respectively.  Also, in the case when profile
! count data (.gcda) files are removed, \s-1GCC\s0 cannot use any profile feedback
  information.  In all these cases, warnings are issued to inform you that a
  profile generation step is due.
  Ignoring the warning can result in poorly optimized code.
  \&\fB\-Wno\-missing\-profile\fR can be used to
  disable the warning, but this is not recommended and should be done only
! when non-existent profile data is justified.
! .IP "\fB\-Wmismatched\-dealloc\fR" 4
  .IX Item "-Wmismatched-dealloc"
  Warn for calls to deallocation functions with pointer arguments returned
! from from allocations functions for which the former isn't a suitable
  deallocator.  A pair of functions can be associated as matching allocators
  and deallocators by use of attribute \f(CW\*(C`malloc\*(C'\fR.  Unless disabled by
  the \fB\-fno\-builtin\fR option the standard functions \f(CW\*(C`calloc\*(C'\fR,
  \&\f(CW\*(C`malloc\*(C'\fR, \f(CW\*(C`realloc\*(C'\fR, and \f(CW\*(C`free\*(C'\fR, as well as the corresponding
! forms of \*(C+ \f(CW\*(C`operator new\*(C'\fR and \f(CW\*(C`operator delete\*(C'\fR are implicitly
  associated as matching allocators and deallocators.  In the following
  example \f(CW\*(C`mydealloc\*(C'\fR is the deallocator for pointers returned from
  \&\f(CW\*(C`myalloc\*(C'\fR.
--- 6600,6621 ----
  In these cases, the profile feedback data files do not contain any
  profile feedback information for
  the newly added function or file respectively.  Also, in the case when profile
! count data (.gcda) files are removed, GCC cannot use any profile feedback
  information.  In all these cases, warnings are issued to inform you that a
  profile generation step is due.
  Ignoring the warning can result in poorly optimized code.
  \&\fB\-Wno\-missing\-profile\fR can be used to
  disable the warning, but this is not recommended and should be done only
! when non\-existent profile data is justified.
! .IP \fB\-Wmismatched\-dealloc\fR 4
  .IX Item "-Wmismatched-dealloc"
  Warn for calls to deallocation functions with pointer arguments returned
! from from allocations functions for which the former isn\*(Aqt a suitable
  deallocator.  A pair of functions can be associated as matching allocators
  and deallocators by use of attribute \f(CW\*(C`malloc\*(C'\fR.  Unless disabled by
  the \fB\-fno\-builtin\fR option the standard functions \f(CW\*(C`calloc\*(C'\fR,
  \&\f(CW\*(C`malloc\*(C'\fR, \f(CW\*(C`realloc\*(C'\fR, and \f(CW\*(C`free\*(C'\fR, as well as the corresponding
! forms of C++ \f(CW\*(C`operator new\*(C'\fR and \f(CW\*(C`operator delete\*(C'\fR are implicitly
  associated as matching allocators and deallocators.  In the following
  example \f(CW\*(C`mydealloc\*(C'\fR is the deallocator for pointers returned from
  \&\f(CW\*(C`myalloc\*(C'\fR.
*************** example \f(CW\*(C`mydealloc\*(C'\fR is t
*** 6706,6716 ****
  \&        }
  .Ve
  .Sp
! In \*(C+, the related option \fB\-Wmismatched\-new\-delete\fR diagnoses
  mismatches involving either \f(CW\*(C`operator new\*(C'\fR or \f(CW\*(C`operator delete\*(C'\fR.
  .Sp
  Option \fB\-Wmismatched\-dealloc\fR is included in \fB\-Wall\fR.
! .IP "\fB\-Wmultistatement\-macros\fR" 4
  .IX Item "-Wmultistatement-macros"
  Warn about unsafe multiple statement macros that appear to be guarded
  by a clause such as \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR, \f(CW\*(C`for\*(C'\fR, \f(CW\*(C`switch\*(C'\fR, or
--- 6635,6645 ----
  \&        }
  .Ve
  .Sp
! In C++, the related option \fB\-Wmismatched\-new\-delete\fR diagnoses
  mismatches involving either \f(CW\*(C`operator new\*(C'\fR or \f(CW\*(C`operator delete\*(C'\fR.
  .Sp
  Option \fB\-Wmismatched\-dealloc\fR is included in \fB\-Wall\fR.
! .IP \fB\-Wmultistatement\-macros\fR 4
  .IX Item "-Wmultistatement-macros"
  Warn about unsafe multiple statement macros that appear to be guarded
  by a clause such as \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR, \f(CW\*(C`for\*(C'\fR, \f(CW\*(C`switch\*(C'\fR, or
*************** For example:
*** 6726,6732 ****
  .Ve
  .Sp
  will increment \f(CW\*(C`y\*(C'\fR unconditionally, not just when \f(CW\*(C`c\*(C'\fR holds.
! The can usually be fixed by wrapping the macro in a do-while loop:
  .Sp
  .Vb 3
  \&        #define DOIT do { x++; y++; } while (0)
--- 6655,6661 ----
  .Ve
  .Sp
  will increment \f(CW\*(C`y\*(C'\fR unconditionally, not just when \f(CW\*(C`c\*(C'\fR holds.
! The can usually be fixed by wrapping the macro in a do\-while loop:
  .Sp
  .Vb 3
  \&        #define DOIT do { x++; y++; } while (0)
*************** The can usually be fixed by wrapping the
*** 6734,6741 ****
  \&          DOIT;
  .Ve
  .Sp
! This warning is enabled by \fB\-Wall\fR in C and \*(C+.
! .IP "\fB\-Wparentheses\fR" 4
  .IX Item "-Wparentheses"
  Warn if parentheses are omitted in certain contexts, such
  as when there is an assignment in a context where a truth value
--- 6663,6670 ----
  \&          DOIT;
  .Ve
  .Sp
! This warning is enabled by \fB\-Wall\fR in C and C++.
! .IP \fB\-Wparentheses\fR 4
  .IX Item "-Wparentheses"
  Warn if parentheses are omitted in certain contexts, such
  as when there is an assignment in a context where a truth value
*************** Also warn if a comparison like \f(CW\*(C
*** 6746,6758 ****
  equivalent to \f(CW\*(C`(x<=y ? 1 : 0) <= z\*(C'\fR, which is a different
  interpretation from that of ordinary mathematical notation.
  .Sp
! Also warn for dangerous uses of the \s-1GNU\s0 extension to
  \&\f(CW\*(C`?:\*(C'\fR with omitted middle operand. When the condition
  in the \f(CW\*(C`?\*(C'\fR: operator is a boolean expression, the omitted value is
  always 1.  Often programmers expect it to be a value computed
  inside the conditional expression instead.
  .Sp
! For \*(C+ this also warns for some cases of unnecessary parentheses in
  declarations, which can indicate an attempt at a function call instead
  of a declaration:
  .Sp
--- 6675,6687 ----
  equivalent to \f(CW\*(C`(x<=y ? 1 : 0) <= z\*(C'\fR, which is a different
  interpretation from that of ordinary mathematical notation.
  .Sp
! Also warn for dangerous uses of the GNU extension to
  \&\f(CW\*(C`?:\*(C'\fR with omitted middle operand. When the condition
  in the \f(CW\*(C`?\*(C'\fR: operator is a boolean expression, the omitted value is
  always 1.  Often programmers expect it to be a value computed
  inside the conditional expression instead.
  .Sp
! For C++ this also warns for some cases of unnecessary parentheses in
  declarations, which can indicate an attempt at a function call instead
  of a declaration:
  .Sp
*************** of a declaration:
*** 6765,6772 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-self\-move\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-self-move ( and Objective- only)"
  This warning warns when a value is moved to itself with \f(CW\*(C`std::move\*(C'\fR.
  Such a \f(CW\*(C`std::move\*(C'\fR typically has no effect.
  .Sp
--- 6694,6701 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-self\-move\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-self-move (C++ and Objective-C++ only)"
  This warning warns when a value is moved to itself with \f(CW\*(C`std::move\*(C'\fR.
  Such a \f(CW\*(C`std::move\*(C'\fR typically has no effect.
  .Sp
*************** Such a \f(CW\*(C`std::move\*(C'\fR typic
*** 6783,6794 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wsequence\-point\fR" 4
  .IX Item "-Wsequence-point"
  Warn about code that may have undefined semantics because of violations
! of sequence point rules in the C and \*(C+ standards.
  .Sp
! The C and \*(C+ standards define the order in which expressions in a C/\*(C+
  program are evaluated in terms of \fIsequence points\fR, which represent
  a partial ordering between the execution of parts of the program: those
  executed before the sequence point, and those executed after it.  These
--- 6712,6723 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wsequence\-point\fR 4
  .IX Item "-Wsequence-point"
  Warn about code that may have undefined semantics because of violations
! of sequence point rules in the C and C++ standards.
  .Sp
! The C and C++ standards define the order in which expressions in a C/C++
  program are evaluated in terms of \fIsequence points\fR, which represent
  a partial ordering between the execution of parts of the program: those
  executed before the sequence point, and those executed after it.  These
*************** ruled that function calls do not overlap
*** 6807,6817 ****
  .Sp
  It is not specified when between sequence points modifications to the
  values of objects take effect.  Programs whose behavior depends on this
! have undefined behavior; the C and \*(C+ standards specify that \*(L"Between
  the previous and next sequence point an object shall have its stored
  value modified at most once by the evaluation of an expression.
  Furthermore, the prior value shall be read only to determine the value
! to be stored.\*(R".  If a program breaks these rules, the results on any
  particular implementation are entirely unpredictable.
  .Sp
  Examples of code with undefined behavior are \f(CW\*(C`a = a++;\*(C'\fR, \f(CW\*(C`a[n]
--- 6736,6746 ----
  .Sp
  It is not specified when between sequence points modifications to the
  values of objects take effect.  Programs whose behavior depends on this
! have undefined behavior; the C and C++ standards specify that "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.
  .Sp
  Examples of code with undefined behavior are \f(CW\*(C`a = a++;\*(C'\fR, \f(CW\*(C`a[n]
*************** diagnosed by this option, and it may giv
*** 6820,6844 ****
  result, but in general it has been found fairly effective at detecting
  this sort of problem in programs.
  .Sp
! The \*(C+17 standard will define the order of evaluation of operands in
! more cases: in particular it requires that the right-hand side of an
! assignment be evaluated before the left-hand side, so the above
  examples are no longer undefined.  But this option will still warn
  about them, to help people avoid writing code that is undefined in C
! and earlier revisions of \*(C+.
  .Sp
  The standard is worded confusingly, therefore there is some debate
  over the precise meaning of the sequence point rules in subtle cases.
  Links to discussions of the problem, including proposed formal
! definitions, may be found on the \s-1GCC\s0 readings page, at
  <\fBhttps://gcc.gnu.org/readings.html\fR>.
  .Sp
! This warning is enabled by \fB\-Wall\fR for C and \*(C+.
! .IP "\fB\-Wno\-return\-local\-addr\fR" 4
  .IX Item "-Wno-return-local-addr"
! Do not warn about returning a pointer (or in \*(C+, a reference) to a
  variable that goes out of scope after the function returns.
! .IP "\fB\-Wreturn\-type\fR" 4
  .IX Item "-Wreturn-type"
  Warn whenever a function is defined with a return type that defaults
  to \f(CW\*(C`int\*(C'\fR.  Also warn about any \f(CW\*(C`return\*(C'\fR statement with no
--- 6749,6773 ----
  result, but in general it has been found fairly effective at detecting
  this sort of problem in programs.
  .Sp
! The C++17 standard will define the order of evaluation of operands in
! more cases: in particular it requires that the right\-hand side of an
! assignment be evaluated before the left\-hand side, so the above
  examples are no longer undefined.  But this option will still warn
  about them, to help people avoid writing code that is undefined in C
! and earlier revisions of C++.
  .Sp
  The standard is worded confusingly, therefore there is some debate
  over the precise meaning of the sequence point rules in subtle cases.
  Links to discussions of the problem, including proposed formal
! definitions, may be found on the GCC readings page, at
  <\fBhttps://gcc.gnu.org/readings.html\fR>.
  .Sp
! This warning is enabled by \fB\-Wall\fR for C and C++.
! .IP \fB\-Wno\-return\-local\-addr\fR 4
  .IX Item "-Wno-return-local-addr"
! Do not warn about returning a pointer (or in C++, a reference) to a
  variable that goes out of scope after the function returns.
! .IP \fB\-Wreturn\-type\fR 4
  .IX Item "-Wreturn-type"
  Warn whenever a function is defined with a return type that defaults
  to \f(CW\*(C`int\*(C'\fR.  Also warn about any \f(CW\*(C`return\*(C'\fR statement with no
*************** without a value).
*** 6848,6900 ****
  .Sp
  For C only, warn about a \f(CW\*(C`return\*(C'\fR statement with an expression in a
  function whose return type is \f(CW\*(C`void\*(C'\fR, unless the expression type is
! also \f(CW\*(C`void\*(C'\fR.  As a \s-1GNU\s0 extension, the latter case is accepted
  without a warning unless \fB\-Wpedantic\fR is used.  Attempting
  to use the return value of a non\-\f(CW\*(C`void\*(C'\fR function other than \f(CW\*(C`main\*(C'\fR
  that flows off the end by reaching the closing curly brace that terminates
  the function is undefined.
  .Sp
! Unlike in C, in \*(C+, flowing off the end of a non\-\f(CW\*(C`void\*(C'\fR function other
  than \f(CW\*(C`main\*(C'\fR results in undefined behavior even when the value of
  the function is not used.
  .Sp
! This warning is enabled by default in \*(C+ and by \fB\-Wall\fR otherwise.
! .IP "\fB\-Wno\-shift\-count\-negative\fR" 4
  .IX Item "-Wno-shift-count-negative"
  Controls warnings if a shift count is negative.
  This warning is enabled by default.
! .IP "\fB\-Wno\-shift\-count\-overflow\fR" 4
  .IX Item "-Wno-shift-count-overflow"
  Controls warnings if a shift count is greater than or equal to the bit width
  of the type.  This warning is enabled by default.
! .IP "\fB\-Wshift\-negative\-value\fR" 4
  .IX Item "-Wshift-negative-value"
  Warn if left shifting a negative value.  This warning is enabled by
! \&\fB\-Wextra\fR in C99 (and newer) and \*(C+11 to \*(C+17 modes.
! .IP "\fB\-Wno\-shift\-overflow\fR" 4
  .IX Item "-Wno-shift-overflow"
  .PD 0
! .IP "\fB\-Wshift\-overflow=\fR\fIn\fR" 4
  .IX Item "-Wshift-overflow=n"
  .PD
  These options control warnings about left shift overflows.
  .RS 4
! .IP "\fB\-Wshift\-overflow=1\fR" 4
  .IX Item "-Wshift-overflow=1"
  This is the warning level of \fB\-Wshift\-overflow\fR and is enabled
! by default in C99 and \*(C+11 modes (and newer).  This warning level does
! not warn about left-shifting 1 into the sign bit.  (However, in C, such
  an overflow is still rejected in contexts where an integer constant expression
! is required.)  No warning is emitted in \*(C+20 mode (and newer), as signed left
  shifts always wrap.
! .IP "\fB\-Wshift\-overflow=2\fR" 4
  .IX Item "-Wshift-overflow=2"
! This warning level also warns about left-shifting 1 into the sign bit,
! unless \*(C+14 mode (or newer) is active.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wswitch\fR" 4
  .IX Item "-Wswitch"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
  and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
--- 6777,6829 ----
  .Sp
  For C only, warn about a \f(CW\*(C`return\*(C'\fR statement with an expression in a
  function whose return type is \f(CW\*(C`void\*(C'\fR, unless the expression type is
! also \f(CW\*(C`void\*(C'\fR.  As a GNU extension, the latter case is accepted
  without a warning unless \fB\-Wpedantic\fR is used.  Attempting
  to use the return value of a non\-\f(CW\*(C`void\*(C'\fR function other than \f(CW\*(C`main\*(C'\fR
  that flows off the end by reaching the closing curly brace that terminates
  the function is undefined.
  .Sp
! Unlike in C, in C++, flowing off the end of a non\-\f(CW\*(C`void\*(C'\fR function other
  than \f(CW\*(C`main\*(C'\fR results in undefined behavior even when the value of
  the function is not used.
  .Sp
! This warning is enabled by default in C++ and by \fB\-Wall\fR otherwise.
! .IP \fB\-Wno\-shift\-count\-negative\fR 4
  .IX Item "-Wno-shift-count-negative"
  Controls warnings if a shift count is negative.
  This warning is enabled by default.
! .IP \fB\-Wno\-shift\-count\-overflow\fR 4
  .IX Item "-Wno-shift-count-overflow"
  Controls warnings if a shift count is greater than or equal to the bit width
  of the type.  This warning is enabled by default.
! .IP \fB\-Wshift\-negative\-value\fR 4
  .IX Item "-Wshift-negative-value"
  Warn if left shifting a negative value.  This warning is enabled by
! \&\fB\-Wextra\fR in C99 (and newer) and C++11 to C++17 modes.
! .IP \fB\-Wno\-shift\-overflow\fR 4
  .IX Item "-Wno-shift-overflow"
  .PD 0
! .IP \fB\-Wshift\-overflow=\fR\fIn\fR 4
  .IX Item "-Wshift-overflow=n"
  .PD
  These options control warnings about left shift overflows.
  .RS 4
! .IP \fB\-Wshift\-overflow=1\fR 4
  .IX Item "-Wshift-overflow=1"
  This is the warning level of \fB\-Wshift\-overflow\fR and is enabled
! by default in C99 and C++11 modes (and newer).  This warning level does
! not warn about left\-shifting 1 into the sign bit.  (However, in C, such
  an overflow is still rejected in contexts where an integer constant expression
! is required.)  No warning is emitted in C++20 mode (and newer), as signed left
  shifts always wrap.
! .IP \fB\-Wshift\-overflow=2\fR 4
  .IX Item "-Wshift-overflow=2"
! This warning level also warns about left\-shifting 1 into the sign bit,
! unless C++14 mode (or newer) is active.
  .RE
  .RS 4
  .RE
! .IP \fB\-Wswitch\fR 4
  .IX Item "-Wswitch"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
  and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
*************** warning.)  \f(CW\*(C`case\*(C'\fR labels
*** 6903,6913 ****
  provoke warnings when this option is used (even if there is a
  \&\f(CW\*(C`default\*(C'\fR label).
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wswitch\-default\fR" 4
  .IX Item "-Wswitch-default"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement does not have a \f(CW\*(C`default\*(C'\fR
  case.
! .IP "\fB\-Wswitch\-enum\fR" 4
  .IX Item "-Wswitch-enum"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
  and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
--- 6832,6842 ----
  provoke warnings when this option is used (even if there is a
  \&\f(CW\*(C`default\*(C'\fR label).
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wswitch\-default\fR 4
  .IX Item "-Wswitch-default"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement does not have a \f(CW\*(C`default\*(C'\fR
  case.
! .IP \fB\-Wswitch\-enum\fR 4
  .IX Item "-Wswitch-enum"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
  and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
*************** provoke warnings when this option is use
*** 6916,6922 ****
  between \fB\-Wswitch\fR and this option is that this option gives a
  warning about an omitted enumeration code even if there is a
  \&\f(CW\*(C`default\*(C'\fR label.
! .IP "\fB\-Wno\-switch\-bool\fR" 4
  .IX Item "-Wno-switch-bool"
  Do not warn when a \f(CW\*(C`switch\*(C'\fR statement has an index of boolean type
  and the case values are outside the range of a boolean type.
--- 6845,6851 ----
  between \fB\-Wswitch\fR and this option is that this option gives a
  warning about an omitted enumeration code even if there is a
  \&\f(CW\*(C`default\*(C'\fR label.
! .IP \fB\-Wno\-switch\-bool\fR 4
  .IX Item "-Wno-switch-bool"
  Do not warn when a \f(CW\*(C`switch\*(C'\fR statement has an index of boolean type
  and the case values are outside the range of a boolean type.
*************** expression to a type other than \f(CW\*(
*** 6930,6943 ****
  \&          }
  .Ve
  .Sp
! This warning is enabled by default for C and \*(C+ programs.
! .IP "\fB\-Wno\-switch\-outside\-range\fR" 4
  .IX Item "-Wno-switch-outside-range"
  This option controls warnings when a \f(CW\*(C`switch\*(C'\fR case has a value
  that is outside of its
  respective type range.  This warning is enabled by default for
! C and \*(C+ programs.
! .IP "\fB\-Wno\-switch\-unreachable\fR" 4
  .IX Item "-Wno-switch-unreachable"
  Do not warn when a \f(CW\*(C`switch\*(C'\fR statement contains statements between the
  controlling expression and the first case label, which will never be
--- 6859,6872 ----
  \&          }
  .Ve
  .Sp
! This warning is enabled by default for C and C++ programs.
! .IP \fB\-Wno\-switch\-outside\-range\fR 4
  .IX Item "-Wno-switch-outside-range"
  This option controls warnings when a \f(CW\*(C`switch\*(C'\fR case has a value
  that is outside of its
  respective type range.  This warning is enabled by default for
! C and C++ programs.
! .IP \fB\-Wno\-switch\-unreachable\fR 4
  .IX Item "-Wno-switch-unreachable"
  Do not warn when a \f(CW\*(C`switch\*(C'\fR statement contains statements between the
  controlling expression and the first case label, which will never be
*************** controlling expression and the first cas
*** 6967,6984 ****
  \&          }
  .Ve
  .Sp
! This warning is enabled by default for C and \*(C+ programs.
! .IP "\fB\-Wsync\-nand\fR (C and \*(C+ only)" 4
! .IX Item "-Wsync-nand (C and only)"
  Warn when \f(CW\*(C`_\|_sync_fetch_and_nand\*(C'\fR and \f(CW\*(C`_\|_sync_nand_and_fetch\*(C'\fR
! built-in functions are used.  These functions changed semantics in \s-1GCC 4.4.\s0
! .IP "\fB\-Wtrivial\-auto\-var\-init\fR" 4
  .IX Item "-Wtrivial-auto-var-init"
  Warn when \f(CW\*(C`\-ftrivial\-auto\-var\-init\*(C'\fR cannot initialize the automatic
  variable.  A common situation is an automatic variable that is declared
  between the controlling expression and the first case label of a \f(CW\*(C`switch\*(C'\fR
  statement.
! .IP "\fB\-Wunused\-but\-set\-parameter\fR" 4
  .IX Item "-Wunused-but-set-parameter"
  Warn whenever a function parameter is assigned to, but otherwise unused
  (aside from its declaration).
--- 6896,6913 ----
  \&          }
  .Ve
  .Sp
! This warning is enabled by default for C and C++ programs.
! .IP "\fB\-Wsync\-nand\fR (C and C++ only)" 4
! .IX Item "-Wsync-nand (C and C++ only)"
  Warn when \f(CW\*(C`_\|_sync_fetch_and_nand\*(C'\fR and \f(CW\*(C`_\|_sync_nand_and_fetch\*(C'\fR
! built\-in functions are used.  These functions changed semantics in GCC 4.4.
! .IP \fB\-Wtrivial\-auto\-var\-init\fR 4
  .IX Item "-Wtrivial-auto-var-init"
  Warn when \f(CW\*(C`\-ftrivial\-auto\-var\-init\*(C'\fR cannot initialize the automatic
  variable.  A common situation is an automatic variable that is declared
  between the controlling expression and the first case label of a \f(CW\*(C`switch\*(C'\fR
  statement.
! .IP \fB\-Wunused\-but\-set\-parameter\fR 4
  .IX Item "-Wunused-but-set-parameter"
  Warn whenever a function parameter is assigned to, but otherwise unused
  (aside from its declaration).
*************** To suppress this warning use the \f(CW\*
*** 6987,6993 ****
  .Sp
  This warning is also enabled by \fB\-Wunused\fR together with
  \&\fB\-Wextra\fR.
! .IP "\fB\-Wunused\-but\-set\-variable\fR" 4
  .IX Item "-Wunused-but-set-variable"
  Warn whenever a local variable is assigned to, but otherwise unused
  (aside from its declaration).
--- 6916,6922 ----
  .Sp
  This warning is also enabled by \fB\-Wunused\fR together with
  \&\fB\-Wextra\fR.
! .IP \fB\-Wunused\-but\-set\-variable\fR 4
  .IX Item "-Wunused-but-set-variable"
  Warn whenever a local variable is assigned to, but otherwise unused
  (aside from its declaration).
*************** To suppress this warning use the \f(CW\*
*** 6997,7089 ****
  .Sp
  This warning is also enabled by \fB\-Wunused\fR, which is enabled
  by \fB\-Wall\fR.
! .IP "\fB\-Wunused\-function\fR" 4
  .IX Item "-Wunused-function"
  Warn whenever a static function is declared but not defined or a
! non-inline static function is unused.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wunused\-label\fR" 4
  .IX Item "-Wunused-label"
  Warn whenever a label is declared but not used.
  This warning is enabled by \fB\-Wall\fR.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP "\fB\-Wunused\-local\-typedefs\fR (C, Objective-C, \*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wunused-local-typedefs (C, Objective-C, and Objective- only)"
  Warn when a typedef locally defined in a function is not used.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wunused\-parameter\fR" 4
  .IX Item "-Wunused-parameter"
  Warn whenever a function parameter is unused aside from its declaration.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP "\fB\-Wno\-unused\-result\fR" 4
  .IX Item "-Wno-unused-result"
  Do not warn if a caller of a function marked with attribute
  \&\f(CW\*(C`warn_unused_result\*(C'\fR does not use
  its return value. The default is \fB\-Wunused\-result\fR.
! .IP "\fB\-Wunused\-variable\fR" 4
  .IX Item "-Wunused-variable"
  Warn whenever a local or static variable is unused aside from its
  declaration. This option implies \fB\-Wunused\-const\-variable=1\fR for C,
! but not for \*(C+. This warning is enabled by \fB\-Wall\fR.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP "\fB\-Wunused\-const\-variable\fR" 4
  .IX Item "-Wunused-const-variable"
  .PD 0
! .IP "\fB\-Wunused\-const\-variable=\fR\fIn\fR" 4
  .IX Item "-Wunused-const-variable=n"
  .PD
  Warn whenever a constant static variable is unused aside from its declaration.
  \&\fB\-Wunused\-const\-variable=1\fR is enabled by \fB\-Wunused\-variable\fR
! for C, but not for \*(C+. In C this declares variable storage, but in \*(C+ this
  is not an error since const variables take the place of \f(CW\*(C`#define\*(C'\fRs.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
  .RS 4
! .IP "\fB\-Wunused\-const\-variable=1\fR" 4
  .IX Item "-Wunused-const-variable=1"
  This is the warning level that is enabled by \fB\-Wunused\-variable\fR for
  C.  It warns only about unused static const variables defined in the main
  compilation unit, but not about static const variables declared in any
  header included.
! .IP "\fB\-Wunused\-const\-variable=2\fR" 4
  .IX Item "-Wunused-const-variable=2"
  This warning level also warns for unused constant static variables in
  headers (excluding system headers).  This is the warning level of
  \&\fB\-Wunused\-const\-variable\fR and must be explicitly requested since
! in \*(C+ this isn't an error and in C it might be harder to clean up all
  headers included.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wunused\-value\fR" 4
  .IX Item "-Wunused-value"
  Warn whenever a statement computes a result that is explicitly not
  used. To suppress this warning cast the unused expression to
! \&\f(CW\*(C`void\*(C'\fR. This includes an expression-statement or the left-hand
  side of a comma expression that contains no side effects. For example,
  an expression such as \f(CW\*(C`x[i,j]\*(C'\fR causes a warning, while
  \&\f(CW\*(C`x[(void)i,j]\*(C'\fR does not.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wunused\fR" 4
  .IX Item "-Wunused"
  All the above \fB\-Wunused\fR options combined.
  .Sp
  In order to get a warning about an unused function parameter, you must
  either specify \fB\-Wextra \-Wunused\fR (note that \fB\-Wall\fR implies
  \&\fB\-Wunused\fR), or separately specify \fB\-Wunused\-parameter\fR.
! .IP "\fB\-Wuninitialized\fR" 4
  .IX Item "-Wuninitialized"
  Warn if an object with automatic or allocated storage duration is used
! without having been initialized.  In \*(C+, also warn if a non-static
! reference or non-static \f(CW\*(C`const\*(C'\fR member appears in a class without
  constructors.
  .Sp
! In addition, passing a pointer (or in \*(C+, a reference) to an uninitialized
! object to a \f(CW\*(C`const\*(C'\fR\-qualified argument of a built-in function known to
  read the object is also diagnosed by this warning.
  (\fB\-Wmaybe\-uninitialized\fR is issued for ordinary functions.)
  .Sp
--- 6926,7018 ----
  .Sp
  This warning is also enabled by \fB\-Wunused\fR, which is enabled
  by \fB\-Wall\fR.
! .IP \fB\-Wunused\-function\fR 4
  .IX Item "-Wunused-function"
  Warn whenever a static function is declared but not defined or a
! non\-inline static function is unused.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wunused\-label\fR 4
  .IX Item "-Wunused-label"
  Warn whenever a label is declared but not used.
  This warning is enabled by \fB\-Wall\fR.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP "\fB\-Wunused\-local\-typedefs\fR (C, Objective\-C, C++ and Objective\-C++ only)" 4
! .IX Item "-Wunused-local-typedefs (C, Objective-C, C++ and Objective-C++ only)"
  Warn when a typedef locally defined in a function is not used.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wunused\-parameter\fR 4
  .IX Item "-Wunused-parameter"
  Warn whenever a function parameter is unused aside from its declaration.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP \fB\-Wno\-unused\-result\fR 4
  .IX Item "-Wno-unused-result"
  Do not warn if a caller of a function marked with attribute
  \&\f(CW\*(C`warn_unused_result\*(C'\fR does not use
  its return value. The default is \fB\-Wunused\-result\fR.
! .IP \fB\-Wunused\-variable\fR 4
  .IX Item "-Wunused-variable"
  Warn whenever a local or static variable is unused aside from its
  declaration. This option implies \fB\-Wunused\-const\-variable=1\fR for C,
! but not for C++. This warning is enabled by \fB\-Wall\fR.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP \fB\-Wunused\-const\-variable\fR 4
  .IX Item "-Wunused-const-variable"
  .PD 0
! .IP \fB\-Wunused\-const\-variable=\fR\fIn\fR 4
  .IX Item "-Wunused-const-variable=n"
  .PD
  Warn whenever a constant static variable is unused aside from its declaration.
  \&\fB\-Wunused\-const\-variable=1\fR is enabled by \fB\-Wunused\-variable\fR
! for C, but not for C++. In C this declares variable storage, but in C++ this
  is not an error since const variables take the place of \f(CW\*(C`#define\*(C'\fRs.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
  .RS 4
! .IP \fB\-Wunused\-const\-variable=1\fR 4
  .IX Item "-Wunused-const-variable=1"
  This is the warning level that is enabled by \fB\-Wunused\-variable\fR for
  C.  It warns only about unused static const variables defined in the main
  compilation unit, but not about static const variables declared in any
  header included.
! .IP \fB\-Wunused\-const\-variable=2\fR 4
  .IX Item "-Wunused-const-variable=2"
  This warning level also warns for unused constant static variables in
  headers (excluding system headers).  This is the warning level of
  \&\fB\-Wunused\-const\-variable\fR and must be explicitly requested since
! in C++ this isn\*(Aqt an error and in C it might be harder to clean up all
  headers included.
  .RE
  .RS 4
  .RE
! .IP \fB\-Wunused\-value\fR 4
  .IX Item "-Wunused-value"
  Warn whenever a statement computes a result that is explicitly not
  used. To suppress this warning cast the unused expression to
! \&\f(CW\*(C`void\*(C'\fR. This includes an expression\-statement or the left\-hand
  side of a comma expression that contains no side effects. For example,
  an expression such as \f(CW\*(C`x[i,j]\*(C'\fR causes a warning, while
  \&\f(CW\*(C`x[(void)i,j]\*(C'\fR does not.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wunused\fR 4
  .IX Item "-Wunused"
  All the above \fB\-Wunused\fR options combined.
  .Sp
  In order to get a warning about an unused function parameter, you must
  either specify \fB\-Wextra \-Wunused\fR (note that \fB\-Wall\fR implies
  \&\fB\-Wunused\fR), or separately specify \fB\-Wunused\-parameter\fR.
! .IP \fB\-Wuninitialized\fR 4
  .IX Item "-Wuninitialized"
  Warn if an object with automatic or allocated storage duration is used
! without having been initialized.  In C++, also warn if a non\-static
! reference or non\-static \f(CW\*(C`const\*(C'\fR member appears in a class without
  constructors.
  .Sp
! In addition, passing a pointer (or in C++, a reference) to an uninitialized
! object to a \f(CW\*(C`const\*(C'\fR\-qualified argument of a built\-in function known to
  read the object is also diagnosed by this warning.
  (\fB\-Wmaybe\-uninitialized\fR is issued for ordinary functions.)
  .Sp
*************** structure, union or array variables as w
*** 7095,7101 ****
  uninitialized as a whole.  They do not occur for variables or elements
  declared \f(CW\*(C`volatile\*(C'\fR.  Because these warnings depend on
  optimization, the exact variables or elements for which there are
! warnings depend on the precise optimization options and version of \s-1GCC\s0
  used.
  .Sp
  Note that there may be no warning about a variable that is used only
--- 7024,7030 ----
  uninitialized as a whole.  They do not occur for variables or elements
  declared \f(CW\*(C`volatile\*(C'\fR.  Because these warnings depend on
  optimization, the exact variables or elements for which there are
! warnings depend on the precise optimization options and version of GCC
  used.
  .Sp
  Note that there may be no warning about a variable that is used only
*************** to compute a value that itself is never
*** 7103,7110 ****
  computations may be deleted by data flow analysis before the warnings
  are printed.
  .Sp
! In \*(C+, this warning also warns about using uninitialized objects in
! member-initializer-lists.  For example, \s-1GCC\s0 warns about \f(CW\*(C`b\*(C'\fR being
  uninitialized in the following snippet:
  .Sp
  .Vb 5
--- 7032,7039 ----
  computations may be deleted by data flow analysis before the warnings
  are printed.
  .Sp
! In C++, this warning also warns about using uninitialized objects in
! member\-initializer\-lists.  For example, GCC warns about \f(CW\*(C`b\*(C'\fR being
  uninitialized in the following snippet:
  .Sp
  .Vb 5
*************** uninitialized in the following snippet:
*** 7114,7127 ****
  \&          A() : a(b) { }
  \&        };
  .Ve
! .IP "\fB\-Wno\-invalid\-memory\-model\fR" 4
  .IX Item "-Wno-invalid-memory-model"
  This option controls warnings
  for invocations of \fB_\|_atomic Builtins\fR, \fB_\|_sync Builtins\fR,
  and the C11 atomic generic functions with a memory consistency argument
  that is either invalid for the operation or outside the range of values
  of the \f(CW\*(C`memory_order\*(C'\fR enumeration.  For example, since the
! \&\f(CW\*(C`_\|_atomic_store\*(C'\fR and \f(CW\*(C`_\|_atomic_store_n\*(C'\fR built-ins are only
  defined for the relaxed, release, and sequentially consistent memory
  orders the following code is diagnosed:
  .Sp
--- 7043,7056 ----
  \&          A() : a(b) { }
  \&        };
  .Ve
! .IP \fB\-Wno\-invalid\-memory\-model\fR 4
  .IX Item "-Wno-invalid-memory-model"
  This option controls warnings
  for invocations of \fB_\|_atomic Builtins\fR, \fB_\|_sync Builtins\fR,
  and the C11 atomic generic functions with a memory consistency argument
  that is either invalid for the operation or outside the range of values
  of the \f(CW\*(C`memory_order\*(C'\fR enumeration.  For example, since the
! \&\f(CW\*(C`_\|_atomic_store\*(C'\fR and \f(CW\*(C`_\|_atomic_store_n\*(C'\fR built\-ins are only
  defined for the relaxed, release, and sequentially consistent memory
  orders the following code is diagnosed:
  .Sp
*************** orders the following code is diagnosed:
*** 7133,7139 ****
  .Ve
  .Sp
  \&\fB\-Winvalid\-memory\-model\fR is enabled by default.
! .IP "\fB\-Wmaybe\-uninitialized\fR" 4
  .IX Item "-Wmaybe-uninitialized"
  For an object with automatic or allocated storage duration, if there exists
  a path from the function entry to a use of the object that is initialized,
--- 7062,7068 ----
  .Ve
  .Sp
  \&\fB\-Winvalid\-memory\-model\fR is enabled by default.
! .IP \fB\-Wmaybe\-uninitialized\fR 4
  .IX Item "-Wmaybe-uninitialized"
  For an object with automatic or allocated storage duration, if there exists
  a path from the function entry to a use of the object that is initialized,
*************** but there exist some other paths for whi
*** 7141,7157 ****
  the compiler emits a warning if it cannot prove the uninitialized paths
  are not executed at run time.
  .Sp
! In addition, passing a pointer (or in \*(C+, a reference) to an uninitialized
  object to a \f(CW\*(C`const\*(C'\fR\-qualified function argument is also diagnosed by
! this warning.  (\fB\-Wuninitialized\fR is issued for built-in functions
  known to read the object.)  Annotating the function with attribute
! \&\f(CW\*(C`access (none)\*(C'\fR indicates that the argument isn't used to access
  the object and avoids the warning.
  .Sp
  These warnings are only possible in optimizing compilation, because otherwise
! \&\s-1GCC\s0 does not keep track of the state of variables.
  .Sp
! These warnings are made optional because \s-1GCC\s0 may not be able to determine when
  the code is correct in spite of appearing to have an error.  Here is one
  example of how this can happen:
  .Sp
--- 7070,7086 ----
  the compiler emits a warning if it cannot prove the uninitialized paths
  are not executed at run time.
  .Sp
! In addition, passing a pointer (or in C++, a reference) to an uninitialized
  object to a \f(CW\*(C`const\*(C'\fR\-qualified function argument is also diagnosed by
! this warning.  (\fB\-Wuninitialized\fR is issued for built\-in functions
  known to read the object.)  Annotating the function with attribute
! \&\f(CW\*(C`access (none)\*(C'\fR indicates that the argument isn\*(Aqt used to access
  the object and avoids the warning.
  .Sp
  These warnings are only possible in optimizing compilation, because otherwise
! GCC does not keep track of the state of variables.
  .Sp
! These warnings are made optional because GCC may not be able to determine when
  the code is correct in spite of appearing to have an error.  Here is one
  example of how this can happen:
  .Sp
*************** example of how this can happen:
*** 7171,7181 ****
  .Ve
  .Sp
  If the value of \f(CW\*(C`y\*(C'\fR is always 1, 2 or 3, then \f(CW\*(C`x\*(C'\fR is
! always initialized, but \s-1GCC\s0 doesn't know this. To suppress the
  warning, you need to provide a default case with \fBassert\fR\|(0) or
  similar code.
  .Sp
! This option also warns when a non-volatile automatic variable might be
  changed by a call to \f(CW\*(C`longjmp\*(C'\fR.
  The compiler sees only the calls to \f(CW\*(C`setjmp\*(C'\fR.  It cannot know
  where \f(CW\*(C`longjmp\*(C'\fR will be called; in fact, a signal handler could
--- 7100,7110 ----
  .Ve
  .Sp
  If the value of \f(CW\*(C`y\*(C'\fR is always 1, 2 or 3, then \f(CW\*(C`x\*(C'\fR is
! always initialized, but GCC doesn\*(Aqt know this. To suppress the
  warning, you need to provide a default case with \fBassert\fR\|(0) or
  similar code.
  .Sp
! This option also warns when a non\-volatile automatic variable might be
  changed by a call to \f(CW\*(C`longjmp\*(C'\fR.
  The compiler sees only the calls to \f(CW\*(C`setjmp\*(C'\fR.  It cannot know
  where \f(CW\*(C`longjmp\*(C'\fR will be called; in fact, a signal handler could
*************** Some spurious warnings can be avoided if
*** 7187,7204 ****
  you use that never return as \f(CW\*(C`noreturn\*(C'\fR.
  .Sp
  This warning is enabled by \fB\-Wall\fR or \fB\-Wextra\fR.
! .IP "\fB\-Wunknown\-pragmas\fR" 4
  .IX Item "-Wunknown-pragmas"
  Warn when a \f(CW\*(C`#pragma\*(C'\fR directive is encountered that is not understood by 
! \&\s-1GCC.\s0  If this command-line option is used, warnings are even issued
  for unknown pragmas in system header files.  This is not the case if
! the warnings are only enabled by the \fB\-Wall\fR command-line option.
! .IP "\fB\-Wno\-pragmas\fR" 4
  .IX Item "-Wno-pragmas"
  Do not warn about misuses of pragmas, such as incorrect parameters,
  invalid syntax, or conflicts between pragmas.  See also
  \&\fB\-Wunknown\-pragmas\fR.
! .IP "\fB\-Wno\-prio\-ctor\-dtor\fR" 4
  .IX Item "-Wno-prio-ctor-dtor"
  Do not warn if a priority from 0 to 100 is used for constructor or destructor.
  The use of constructor and destructor attributes allow you to assign a
--- 7116,7133 ----
  you use that never return as \f(CW\*(C`noreturn\*(C'\fR.
  .Sp
  This warning is enabled by \fB\-Wall\fR or \fB\-Wextra\fR.
! .IP \fB\-Wunknown\-pragmas\fR 4
  .IX Item "-Wunknown-pragmas"
  Warn when a \f(CW\*(C`#pragma\*(C'\fR directive is encountered that is not understood by 
! GCC.  If this command\-line option is used, warnings are even issued
  for unknown pragmas in system header files.  This is not the case if
! the warnings are only enabled by the \fB\-Wall\fR command\-line option.
! .IP \fB\-Wno\-pragmas\fR 4
  .IX Item "-Wno-pragmas"
  Do not warn about misuses of pragmas, such as incorrect parameters,
  invalid syntax, or conflicts between pragmas.  See also
  \&\fB\-Wunknown\-pragmas\fR.
! .IP \fB\-Wno\-prio\-ctor\-dtor\fR 4
  .IX Item "-Wno-prio-ctor-dtor"
  Do not warn if a priority from 0 to 100 is used for constructor or destructor.
  The use of constructor and destructor attributes allow you to assign a
*************** priority to the constructor/destructor t
*** 7206,7212 ****
  before \f(CW\*(C`main\*(C'\fR is called or after it returns.  The priority values must be
  greater than 100 as the compiler reserves priority values between 0\-\-100 for
  the implementation.
! .IP "\fB\-Wstrict\-aliasing\fR" 4
  .IX Item "-Wstrict-aliasing"
  This option is only active when \fB\-fstrict\-aliasing\fR is active.
  It warns about code that might break the strict aliasing rules that the
--- 7135,7141 ----
  before \f(CW\*(C`main\*(C'\fR is called or after it returns.  The priority values must be
  greater than 100 as the compiler reserves priority values between 0\-\-100 for
  the implementation.
! .IP \fB\-Wstrict\-aliasing\fR 4
  .IX Item "-Wstrict-aliasing"
  This option is only active when \fB\-fstrict\-aliasing\fR is active.
  It warns about code that might break the strict aliasing rules that the
*************** compiler is using for optimization.  The
*** 7214,7220 ****
  cases, but does attempt to catch the more common pitfalls.  It is
  included in \fB\-Wall\fR.
  It is equivalent to \fB\-Wstrict\-aliasing=3\fR
! .IP "\fB\-Wstrict\-aliasing=n\fR" 4
  .IX Item "-Wstrict-aliasing=n"
  This option is only active when \fB\-fstrict\-aliasing\fR is active.
  It warns about code that might break the strict aliasing rules that the
--- 7143,7149 ----
  cases, but does attempt to catch the more common pitfalls.  It is
  included in \fB\-Wall\fR.
  It is equivalent to \fB\-Wstrict\-aliasing=3\fR
! .IP \fB\-Wstrict\-aliasing=n\fR 4
  .IX Item "-Wstrict-aliasing=n"
  This option is only active when \fB\-fstrict\-aliasing\fR is active.
  It warns about code that might break the strict aliasing rules that the
*************** negatives.  Slightly slower than levels
*** 7243,7255 ****
  Takes care of the common pun+dereference pattern in the front end:
  \&\f(CW\*(C`*(int*)&some_float\*(C'\fR.
  If optimization is enabled, it also runs in the back end, where it deals
! with multiple statement cases using flow-sensitive points-to information.
  Only warns when the converted pointer is dereferenced.
  Does not warn about incomplete types.
! .IP "\fB\-Wstrict\-overflow\fR" 4
  .IX Item "-Wstrict-overflow"
  .PD 0
! .IP "\fB\-Wstrict\-overflow=\fR\fIn\fR" 4
  .IX Item "-Wstrict-overflow=n"
  .PD
  This option is only active when signed overflow is undefined.
--- 7172,7184 ----
  Takes care of the common pun+dereference pattern in the front end:
  \&\f(CW\*(C`*(int*)&some_float\*(C'\fR.
  If optimization is enabled, it also runs in the back end, where it deals
! with multiple statement cases using flow\-sensitive points\-to information.
  Only warns when the converted pointer is dereferenced.
  Does not warn about incomplete types.
! .IP \fB\-Wstrict\-overflow\fR 4
  .IX Item "-Wstrict-overflow"
  .PD 0
! .IP \fB\-Wstrict\-overflow=\fR\fIn\fR 4
  .IX Item "-Wstrict-overflow=n"
  .PD
  This option is only active when signed overflow is undefined.
*************** undefined signed overflow when estimatin
*** 7269,7282 ****
  requires, in particular when determining whether a loop will be
  executed at all.
  .RS 4
! .IP "\fB\-Wstrict\-overflow=1\fR" 4
  .IX Item "-Wstrict-overflow=1"
  Warn about cases that are both questionable and easy to avoid.  For
  example the compiler simplifies
  \&\f(CW\*(C`x + 1 > x\*(C'\fR to \f(CW1\fR.  This level of
  \&\fB\-Wstrict\-overflow\fR is enabled by \fB\-Wall\fR; higher levels
  are not, and must be explicitly requested.
! .IP "\fB\-Wstrict\-overflow=2\fR" 4
  .IX Item "-Wstrict-overflow=2"
  Also warn about other cases where a comparison is simplified to a
  constant.  For example: \f(CW\*(C`abs (x) >= 0\*(C'\fR.  This can only be
--- 7198,7211 ----
  requires, in particular when determining whether a loop will be
  executed at all.
  .RS 4
! .IP \fB\-Wstrict\-overflow=1\fR 4
  .IX Item "-Wstrict-overflow=1"
  Warn about cases that are both questionable and easy to avoid.  For
  example the compiler simplifies
  \&\f(CW\*(C`x + 1 > x\*(C'\fR to \f(CW1\fR.  This level of
  \&\fB\-Wstrict\-overflow\fR is enabled by \fB\-Wall\fR; higher levels
  are not, and must be explicitly requested.
! .IP \fB\-Wstrict\-overflow=2\fR 4
  .IX Item "-Wstrict-overflow=2"
  Also warn about other cases where a comparison is simplified to a
  constant.  For example: \f(CW\*(C`abs (x) >= 0\*(C'\fR.  This can only be
*************** simplified when signed integer overflow
*** 7284,7298 ****
  \&\f(CW\*(C`abs (INT_MIN)\*(C'\fR overflows to \f(CW\*(C`INT_MIN\*(C'\fR, which is less than
  zero.  \fB\-Wstrict\-overflow\fR (with no level) is the same as
  \&\fB\-Wstrict\-overflow=2\fR.
! .IP "\fB\-Wstrict\-overflow=3\fR" 4
  .IX Item "-Wstrict-overflow=3"
  Also warn about other cases where a comparison is simplified.  For
  example: \f(CW\*(C`x + 1 > 1\*(C'\fR is simplified to \f(CW\*(C`x > 0\*(C'\fR.
! .IP "\fB\-Wstrict\-overflow=4\fR" 4
  .IX Item "-Wstrict-overflow=4"
  Also warn about other simplifications not covered by the above cases.
  For example: \f(CW\*(C`(x * 10) / 5\*(C'\fR is simplified to \f(CW\*(C`x * 2\*(C'\fR.
! .IP "\fB\-Wstrict\-overflow=5\fR" 4
  .IX Item "-Wstrict-overflow=5"
  Also warn about cases where the compiler reduces the magnitude of a
  constant involved in a comparison.  For example: \f(CW\*(C`x + 2 > y\*(C'\fR is
--- 7213,7227 ----
  \&\f(CW\*(C`abs (INT_MIN)\*(C'\fR overflows to \f(CW\*(C`INT_MIN\*(C'\fR, which is less than
  zero.  \fB\-Wstrict\-overflow\fR (with no level) is the same as
  \&\fB\-Wstrict\-overflow=2\fR.
! .IP \fB\-Wstrict\-overflow=3\fR 4
  .IX Item "-Wstrict-overflow=3"
  Also warn about other cases where a comparison is simplified.  For
  example: \f(CW\*(C`x + 1 > 1\*(C'\fR is simplified to \f(CW\*(C`x > 0\*(C'\fR.
! .IP \fB\-Wstrict\-overflow=4\fR 4
  .IX Item "-Wstrict-overflow=4"
  Also warn about other simplifications not covered by the above cases.
  For example: \f(CW\*(C`(x * 10) / 5\*(C'\fR is simplified to \f(CW\*(C`x * 2\*(C'\fR.
! .IP \fB\-Wstrict\-overflow=5\fR 4
  .IX Item "-Wstrict-overflow=5"
  Also warn about cases where the compiler reduces the magnitude of a
  constant involved in a comparison.  For example: \f(CW\*(C`x + 2 > y\*(C'\fR is
*************** false positives.
*** 7303,7317 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wstring\-compare\fR" 4
  .IX Item "-Wstring-compare"
  Warn for calls to \f(CW\*(C`strcmp\*(C'\fR and \f(CW\*(C`strncmp\*(C'\fR whose result is
! determined to be either zero or non-zero in tests for such equality
  owing to the length of one argument being greater than the size of
  the array the other argument is stored in (or the bound in the case
  of \f(CW\*(C`strncmp\*(C'\fR).  Such calls could be mistakes.  For example,
  the call to \f(CW\*(C`strcmp\*(C'\fR below is diagnosed because its result is
! necessarily non-zero irrespective of the contents of the array \f(CW\*(C`a\*(C'\fR.
  .Sp
  .Vb 8
  \&        extern char a[4];
--- 7232,7246 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wstring\-compare\fR 4
  .IX Item "-Wstring-compare"
  Warn for calls to \f(CW\*(C`strcmp\*(C'\fR and \f(CW\*(C`strncmp\*(C'\fR whose result is
! determined to be either zero or non\-zero in tests for such equality
  owing to the length of one argument being greater than the size of
  the array the other argument is stored in (or the bound in the case
  of \f(CW\*(C`strncmp\*(C'\fR).  Such calls could be mistakes.  For example,
  the call to \f(CW\*(C`strcmp\*(C'\fR below is diagnosed because its result is
! necessarily non\-zero irrespective of the contents of the array \f(CW\*(C`a\*(C'\fR.
  .Sp
  .Vb 8
  \&        extern char a[4];
*************** necessarily non-zero irrespective of the
*** 7325,7336 ****
  .Ve
  .Sp
  \&\fB\-Wstring\-compare\fR is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wno\-stringop\-overflow\fR" 4
  .IX Item "-Wno-stringop-overflow"
  .PD 0
! .IP "\fB\-Wstringop\-overflow\fR" 4
  .IX Item "-Wstringop-overflow"
! .IP "\fB\-Wstringop\-overflow=\fR\fItype\fR" 4
  .IX Item "-Wstringop-overflow=type"
  .PD
  Warn for calls to string manipulation functions such as \f(CW\*(C`memcpy\*(C'\fR and
--- 7254,7265 ----
  .Ve
  .Sp
  \&\fB\-Wstring\-compare\fR is enabled by \fB\-Wextra\fR.
! .IP \fB\-Wno\-stringop\-overflow\fR 4
  .IX Item "-Wno-stringop-overflow"
  .PD 0
! .IP \fB\-Wstringop\-overflow\fR 4
  .IX Item "-Wstringop-overflow"
! .IP \fB\-Wstringop\-overflow=\fR\fItype\fR 4
  .IX Item "-Wstringop-overflow=type"
  .PD
  Warn for calls to string manipulation functions such as \f(CW\*(C`memcpy\*(C'\fR and
*************** of Object Size type\-0.  The option also
*** 7343,7354 ****
  in excess of the largest possible object or at most \f(CW\*(C`SIZE_MAX / 2\*(C'\fR bytes.
  The option produces the best results with optimization enabled but can detect
  a small subset of simple buffer overflows even without optimization in
! calls to the \s-1GCC\s0 built-in functions like \f(CW\*(C`_\|_builtin_memcpy\*(C'\fR that
  correspond to the standard functions.  In any case, the option warns about
  just a subset of buffer overflows detected by the corresponding overflow
! checking built-ins.  For example, the option issues a warning for
  the \f(CW\*(C`strcpy\*(C'\fR call below because it copies at least 5 characters
! (the string \f(CW"blue"\fR including the terminating \s-1NUL\s0) into the buffer
  of size 4.
  .Sp
  .Vb 11
--- 7272,7283 ----
  in excess of the largest possible object or at most \f(CW\*(C`SIZE_MAX / 2\*(C'\fR bytes.
  The option produces the best results with optimization enabled but can detect
  a small subset of simple buffer overflows even without optimization in
! calls to the GCC built\-in functions like \f(CW\*(C`_\|_builtin_memcpy\*(C'\fR that
  correspond to the standard functions.  In any case, the option warns about
  just a subset of buffer overflows detected by the corresponding overflow
! checking built\-ins.  For example, the option issues a warning for
  the \f(CW\*(C`strcpy\*(C'\fR call below because it copies at least 5 characters
! (the string \f(CW"blue"\fR including the terminating NUL) into the buffer
  of size 4.
  .Sp
  .Vb 11
*************** of size 4.
*** 7370,7408 ****
  .Sp
  Option \fB\-Wstringop\-overflow=2\fR is enabled by default.
  .RS 4
! .IP "\fB\-Wstringop\-overflow\fR" 4
  .IX Item "-Wstringop-overflow"
  .PD 0
! .IP "\fB\-Wstringop\-overflow=1\fR" 4
  .IX Item "-Wstringop-overflow=1"
  .PD
! The \fB\-Wstringop\-overflow=1\fR option uses type-zero Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  does not warn for writes past the end of subobjects of larger objects accessed
  by pointers unless the size of the largest surrounding object is known.  When
  the destination may be one of several objects it is assumed to be the largest
  one of them.  On Linux systems, when optimization is enabled at this setting
  the option warns for the same code as when the \f(CW\*(C`_FORTIFY_SOURCE\*(C'\fR macro
! is defined to a non-zero value.
! .IP "\fB\-Wstringop\-overflow=2\fR" 4
  .IX Item "-Wstringop-overflow=2"
! The \fB\-Wstringop\-overflow=2\fR option uses type-one Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflows when writing to members of the largest complete
  objects whose exact size is known.  However, it does not warn for excessive
  writes to the same members of unknown objects referenced by pointers since
  they may point to arrays containing unknown numbers of elements.  This is
  the default setting of the option.
! .IP "\fB\-Wstringop\-overflow=3\fR" 4
  .IX Item "-Wstringop-overflow=3"
! The \fB\-Wstringop\-overflow=3\fR option uses type-two Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflowing the smallest object or data member.  This is the
  most restrictive setting of the option that may result in warnings for safe
  code.
! .IP "\fB\-Wstringop\-overflow=4\fR" 4
  .IX Item "-Wstringop-overflow=4"
! The \fB\-Wstringop\-overflow=4\fR option uses type-three Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflowing any data members, and when the destination is
  one of several objects it uses the size of the largest of them to decide
--- 7299,7337 ----
  .Sp
  Option \fB\-Wstringop\-overflow=2\fR is enabled by default.
  .RS 4
! .IP \fB\-Wstringop\-overflow\fR 4
  .IX Item "-Wstringop-overflow"
  .PD 0
! .IP \fB\-Wstringop\-overflow=1\fR 4
  .IX Item "-Wstringop-overflow=1"
  .PD
! The \fB\-Wstringop\-overflow=1\fR option uses type\-zero Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  does not warn for writes past the end of subobjects of larger objects accessed
  by pointers unless the size of the largest surrounding object is known.  When
  the destination may be one of several objects it is assumed to be the largest
  one of them.  On Linux systems, when optimization is enabled at this setting
  the option warns for the same code as when the \f(CW\*(C`_FORTIFY_SOURCE\*(C'\fR macro
! is defined to a non\-zero value.
! .IP \fB\-Wstringop\-overflow=2\fR 4
  .IX Item "-Wstringop-overflow=2"
! The \fB\-Wstringop\-overflow=2\fR option uses type\-one Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflows when writing to members of the largest complete
  objects whose exact size is known.  However, it does not warn for excessive
  writes to the same members of unknown objects referenced by pointers since
  they may point to arrays containing unknown numbers of elements.  This is
  the default setting of the option.
! .IP \fB\-Wstringop\-overflow=3\fR 4
  .IX Item "-Wstringop-overflow=3"
! The \fB\-Wstringop\-overflow=3\fR option uses type\-two Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflowing the smallest object or data member.  This is the
  most restrictive setting of the option that may result in warnings for safe
  code.
! .IP \fB\-Wstringop\-overflow=4\fR 4
  .IX Item "-Wstringop-overflow=4"
! The \fB\-Wstringop\-overflow=4\fR option uses type\-three Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflowing any data members, and when the destination is
  one of several objects it uses the size of the largest of them to decide
*************** setting of the option may result in warn
*** 7411,7424 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wno\-stringop\-overread\fR" 4
  .IX Item "-Wno-stringop-overread"
  Warn for calls to string manipulation functions such as \f(CW\*(C`memchr\*(C'\fR, or
  \&\f(CW\*(C`strcpy\*(C'\fR that are determined to read past the end of the source
  sequence.
  .Sp
  Option \fB\-Wstringop\-overread\fR is enabled by default.
! .IP "\fB\-Wno\-stringop\-truncation\fR" 4
  .IX Item "-Wno-stringop-truncation"
  Do not warn for calls to bounded string manipulation functions
  such as \f(CW\*(C`strncat\*(C'\fR,
--- 7340,7353 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wno\-stringop\-overread\fR 4
  .IX Item "-Wno-stringop-overread"
  Warn for calls to string manipulation functions such as \f(CW\*(C`memchr\*(C'\fR, or
  \&\f(CW\*(C`strcpy\*(C'\fR that are determined to read past the end of the source
  sequence.
  .Sp
  Option \fB\-Wstringop\-overread\fR is enabled by default.
! .IP \fB\-Wno\-stringop\-truncation\fR 4
  .IX Item "-Wno-stringop-truncation"
  Do not warn for calls to bounded string manipulation functions
  such as \f(CW\*(C`strncat\*(C'\fR,
*************** warning use \f(CW\*(C`bufsize \- strlen
*** 7438,7448 ****
  .Ve
  .Sp
  As another example, the following call to \f(CW\*(C`strncpy\*(C'\fR results in copying
! to \f(CW\*(C`d\*(C'\fR just the characters preceding the terminating \s-1NUL,\s0 without
! appending the \s-1NUL\s0 to the end.  Assuming the result of \f(CW\*(C`strncpy\*(C'\fR is
! necessarily a NUL-terminated string is a common mistake, and so the call
  is diagnosed.  To avoid the warning when the result is not expected to be
! NUL-terminated, call \f(CW\*(C`memcpy\*(C'\fR instead.
  .Sp
  .Vb 4
  \&        void copy (char *d, const char *s)
--- 7367,7377 ----
  .Ve
  .Sp
  As another example, the following call to \f(CW\*(C`strncpy\*(C'\fR results in copying
! to \f(CW\*(C`d\*(C'\fR just the characters preceding the terminating NUL, without
! appending the NUL to the end.  Assuming the result of \f(CW\*(C`strncpy\*(C'\fR is
! necessarily a NUL\-terminated string is a common mistake, and so the call
  is diagnosed.  To avoid the warning when the result is not expected to be
! NUL\-terminated, call \f(CW\*(C`memcpy\*(C'\fR instead.
  .Sp
  .Vb 4
  \&        void copy (char *d, const char *s)
*************** NUL-terminated, call \f(CW\*(C`memcpy\*(
*** 7454,7460 ****
  In the following example, the call to \f(CW\*(C`strncpy\*(C'\fR specifies the size
  of the destination buffer as the bound.  If the length of the source
  string is equal to or greater than this size the result of the copy will
! not be NUL-terminated.  Therefore, the call is also diagnosed.  To avoid
  the warning, specify \f(CW\*(C`sizeof buf \- 1\*(C'\fR as the bound and set the last
  element of the buffer to \f(CW\*(C`NUL\*(C'\fR.
  .Sp
--- 7383,7389 ----
  In the following example, the call to \f(CW\*(C`strncpy\*(C'\fR specifies the size
  of the destination buffer as the bound.  If the length of the source
  string is equal to or greater than this size the result of the copy will
! not be NUL\-terminated.  Therefore, the call is also diagnosed.  To avoid
  the warning, specify \f(CW\*(C`sizeof buf \- 1\*(C'\fR as the bound and set the last
  element of the buffer to \f(CW\*(C`NUL\*(C'\fR.
  .Sp
*************** of bytes with no terminating \f(CW\*(C`N
*** 7472,7484 ****
  with attribute \f(CW\*(C`nonstring\*(C'\fR to avoid this warning.  Such arrays,
  however, are not suitable arguments to functions that expect
  \&\f(CW\*(C`NUL\*(C'\fR\-terminated strings.  To help detect accidental misuses of
! such arrays \s-1GCC\s0 issues warnings unless it can prove that the use is
  safe.
! .IP "\fB\-Wstrict\-flex\-arrays\fR" 4
  .IX Item "-Wstrict-flex-arrays"
  Warn about inproper usages of flexible array members
! according to the \fIlevel\fR of the \f(CW\*(C`strict_flex_array (\f(CIlevel\f(CW)\*(C'\fR
! attribute attached to the trailing array field of a structure if it's
  available, otherwise according to the \fIlevel\fR of the option
  \&\fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR.
  .Sp
--- 7401,7413 ----
  with attribute \f(CW\*(C`nonstring\*(C'\fR to avoid this warning.  Such arrays,
  however, are not suitable arguments to functions that expect
  \&\f(CW\*(C`NUL\*(C'\fR\-terminated strings.  To help detect accidental misuses of
! such arrays GCC issues warnings unless it can prove that the use is
  safe.
! .IP \fB\-Wstrict\-flex\-arrays\fR 4
  .IX Item "-Wstrict-flex-arrays"
  Warn about inproper usages of flexible array members
! according to the \fIlevel\fR of the \f(CW\*(C`strict_flex_array (\fR\f(CIlevel\fR\f(CW)\*(C'\fR
! attribute attached to the trailing array field of a structure if it\*(Aqs
  available, otherwise according to the \fIlevel\fR of the option
  \&\fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR.
  .Sp
*************** of a structure that have 2 or more eleme
*** 7490,7592 ****
  as a flexible array member.
  .Sp
  when \fIlevel\fR=2, in addition to \fIlevel\fR=1, additional warnings will be
! issued for a trailing one-element array reference of a structure
  if the array is referenced as a flexible array member.
  .Sp
  when \fIlevel\fR=3, in addition to \fIlevel\fR=2, additional warnings will be
! issued for a trailing zero-length array reference of a structure
  if the array is referenced as a flexible array member.
! .IP "\fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR|\fBformat\fR|\fBcold\fR|\fBmalloc\fR]" 4
  .IX Item "-Wsuggest-attribute=[pure|const|noreturn|format|cold|malloc]"
  Warn for cases where adding an attribute may be beneficial. The
  attributes currently supported are listed below.
  .RS 4
! .IP "\fB\-Wsuggest\-attribute=pure\fR" 4
  .IX Item "-Wsuggest-attribute=pure"
  .PD 0
! .IP "\fB\-Wsuggest\-attribute=const\fR" 4
  .IX Item "-Wsuggest-attribute=const"
! .IP "\fB\-Wsuggest\-attribute=noreturn\fR" 4
  .IX Item "-Wsuggest-attribute=noreturn"
! .IP "\fB\-Wmissing\-noreturn\fR" 4
  .IX Item "-Wmissing-noreturn"
! .IP "\fB\-Wsuggest\-attribute=malloc\fR" 4
  .IX Item "-Wsuggest-attribute=malloc"
  .PD
  Warn about functions that might be candidates for attributes
  \&\f(CW\*(C`pure\*(C'\fR, \f(CW\*(C`const\*(C'\fR or \f(CW\*(C`noreturn\*(C'\fR or \f(CW\*(C`malloc\*(C'\fR. The compiler
  only warns for functions visible in other compilation units or (in the case of
  \&\f(CW\*(C`pure\*(C'\fR and \f(CW\*(C`const\*(C'\fR) if it cannot prove that the function returns
! normally. A function returns normally if it doesn't contain an infinite loop or
  return abnormally by throwing, calling \f(CW\*(C`abort\*(C'\fR or trapping.  This analysis
  requires option \fB\-fipa\-pure\-const\fR, which is enabled by default at
  \&\fB\-O\fR and higher.  Higher optimization levels improve the accuracy
  of the analysis.
! .IP "\fB\-Wsuggest\-attribute=format\fR" 4
  .IX Item "-Wsuggest-attribute=format"
  .PD 0
! .IP "\fB\-Wmissing\-format\-attribute\fR" 4
  .IX Item "-Wmissing-format-attribute"
  .PD
  Warn about function pointers that might be candidates for \f(CW\*(C`format\*(C'\fR
  attributes.  Note these are only possible candidates, not absolute ones.
! \&\s-1GCC\s0 guesses that function pointers with \f(CW\*(C`format\*(C'\fR attributes that
  are used in assignment, initialization, parameter passing or return
  statements should have a corresponding \f(CW\*(C`format\*(C'\fR attribute in the
! resulting type.  I.e. the left-hand side of the assignment or
  initialization, the type of the parameter variable, or the return type
  of the containing function respectively should also have a \f(CW\*(C`format\*(C'\fR
  attribute to avoid the warning.
  .Sp
! \&\s-1GCC\s0 also warns about function definitions that might be
  candidates for \f(CW\*(C`format\*(C'\fR attributes.  Again, these are only
! possible candidates.  \s-1GCC\s0 guesses that \f(CW\*(C`format\*(C'\fR attributes
  might be appropriate for any function that calls a function like
  \&\f(CW\*(C`vprintf\*(C'\fR or \f(CW\*(C`vscanf\*(C'\fR, but this might not always be the
  case, and some functions for which \f(CW\*(C`format\*(C'\fR attributes are
  appropriate may not be detected.
! .IP "\fB\-Wsuggest\-attribute=cold\fR" 4
  .IX Item "-Wsuggest-attribute=cold"
  Warn about functions that might be candidates for \f(CW\*(C`cold\*(C'\fR attribute.  This
  is based on static detection and generally only warns about functions which
  always leads to a call to another \f(CW\*(C`cold\*(C'\fR function such as wrappers of
! \&\*(C+ \f(CW\*(C`throw\*(C'\fR or fatal error reporting functions leading to \f(CW\*(C`abort\*(C'\fR.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Walloc\-zero\fR" 4
  .IX Item "-Walloc-zero"
  Warn about calls to allocation functions decorated with attribute
! \&\f(CW\*(C`alloc_size\*(C'\fR that specify zero bytes, including those to the built-in
  forms of the functions \f(CW\*(C`aligned_alloc\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`calloc\*(C'\fR,
  \&\f(CW\*(C`malloc\*(C'\fR, and \f(CW\*(C`realloc\*(C'\fR.  Because the behavior of these functions
  when called with a zero size differs among implementations (and in the case
  of \f(CW\*(C`realloc\*(C'\fR has been deprecated) relying on it may result in subtle
  portability bugs and should be avoided.
! .IP "\fB\-Walloc\-size\-larger\-than=\fR\fIbyte-size\fR" 4
  .IX Item "-Walloc-size-larger-than=byte-size"
  Warn about calls to functions decorated with attribute \f(CW\*(C`alloc_size\*(C'\fR
  that attempt to allocate objects larger than the specified number of bytes,
  or where the result of the size computation in an integer type with infinite
! precision would exceed the value of \fB\s-1PTRDIFF_MAX\s0\fR on the target.
! \&\fB\-Walloc\-size\-larger\-than=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte-size\fR of \fB\s-1SIZE_MAX\s0\fR or more or by
  \&\fB\-Wno\-alloc\-size\-larger\-than\fR.
! .IP "\fB\-Wno\-alloc\-size\-larger\-than\fR" 4
  .IX Item "-Wno-alloc-size-larger-than"
  Disable \fB\-Walloc\-size\-larger\-than=\fR warnings.  The option is
! equivalent to \fB\-Walloc\-size\-larger\-than=\fR\fB\s-1SIZE_MAX\s0\fR or
  larger.
! .IP "\fB\-Walloca\fR" 4
  .IX Item "-Walloca"
  This option warns on all uses of \f(CW\*(C`alloca\*(C'\fR in the source.
! .IP "\fB\-Walloca\-larger\-than=\fR\fIbyte-size\fR" 4
  .IX Item "-Walloca-larger-than=byte-size"
  This option warns on calls to \f(CW\*(C`alloca\*(C'\fR with an integer argument whose
  value is either zero, or that is not bounded by a controlling predicate
! that limits its value to at most \fIbyte-size\fR.  It also warns for calls
! to \f(CW\*(C`alloca\*(C'\fR where the bound value is unknown.  Arguments of non-integer
  types are considered unbounded even if they appear to be constrained to
  the expected range.
  .Sp
--- 7419,7521 ----
  as a flexible array member.
  .Sp
  when \fIlevel\fR=2, in addition to \fIlevel\fR=1, additional warnings will be
! issued for a trailing one\-element array reference of a structure
  if the array is referenced as a flexible array member.
  .Sp
  when \fIlevel\fR=3, in addition to \fIlevel\fR=2, additional warnings will be
! issued for a trailing zero\-length array reference of a structure
  if the array is referenced as a flexible array member.
! .IP \fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR|\fBformat\fR|\fBcold\fR|\fBmalloc\fR] 4
  .IX Item "-Wsuggest-attribute=[pure|const|noreturn|format|cold|malloc]"
  Warn for cases where adding an attribute may be beneficial. The
  attributes currently supported are listed below.
  .RS 4
! .IP \fB\-Wsuggest\-attribute=pure\fR 4
  .IX Item "-Wsuggest-attribute=pure"
  .PD 0
! .IP \fB\-Wsuggest\-attribute=const\fR 4
  .IX Item "-Wsuggest-attribute=const"
! .IP \fB\-Wsuggest\-attribute=noreturn\fR 4
  .IX Item "-Wsuggest-attribute=noreturn"
! .IP \fB\-Wmissing\-noreturn\fR 4
  .IX Item "-Wmissing-noreturn"
! .IP \fB\-Wsuggest\-attribute=malloc\fR 4
  .IX Item "-Wsuggest-attribute=malloc"
  .PD
  Warn about functions that might be candidates for attributes
  \&\f(CW\*(C`pure\*(C'\fR, \f(CW\*(C`const\*(C'\fR or \f(CW\*(C`noreturn\*(C'\fR or \f(CW\*(C`malloc\*(C'\fR. The compiler
  only warns for functions visible in other compilation units or (in the case of
  \&\f(CW\*(C`pure\*(C'\fR and \f(CW\*(C`const\*(C'\fR) if it cannot prove that the function returns
! normally. A function returns normally if it doesn\*(Aqt contain an infinite loop or
  return abnormally by throwing, calling \f(CW\*(C`abort\*(C'\fR or trapping.  This analysis
  requires option \fB\-fipa\-pure\-const\fR, which is enabled by default at
  \&\fB\-O\fR and higher.  Higher optimization levels improve the accuracy
  of the analysis.
! .IP \fB\-Wsuggest\-attribute=format\fR 4
  .IX Item "-Wsuggest-attribute=format"
  .PD 0
! .IP \fB\-Wmissing\-format\-attribute\fR 4
  .IX Item "-Wmissing-format-attribute"
  .PD
  Warn about function pointers that might be candidates for \f(CW\*(C`format\*(C'\fR
  attributes.  Note these are only possible candidates, not absolute ones.
! GCC guesses that function pointers with \f(CW\*(C`format\*(C'\fR attributes that
  are used in assignment, initialization, parameter passing or return
  statements should have a corresponding \f(CW\*(C`format\*(C'\fR attribute in the
! resulting type.  I.e. the left\-hand side of the assignment or
  initialization, the type of the parameter variable, or the return type
  of the containing function respectively should also have a \f(CW\*(C`format\*(C'\fR
  attribute to avoid the warning.
  .Sp
! GCC also warns about function definitions that might be
  candidates for \f(CW\*(C`format\*(C'\fR attributes.  Again, these are only
! possible candidates.  GCC guesses that \f(CW\*(C`format\*(C'\fR attributes
  might be appropriate for any function that calls a function like
  \&\f(CW\*(C`vprintf\*(C'\fR or \f(CW\*(C`vscanf\*(C'\fR, but this might not always be the
  case, and some functions for which \f(CW\*(C`format\*(C'\fR attributes are
  appropriate may not be detected.
! .IP \fB\-Wsuggest\-attribute=cold\fR 4
  .IX Item "-Wsuggest-attribute=cold"
  Warn about functions that might be candidates for \f(CW\*(C`cold\*(C'\fR attribute.  This
  is based on static detection and generally only warns about functions which
  always leads to a call to another \f(CW\*(C`cold\*(C'\fR function such as wrappers of
! C++ \f(CW\*(C`throw\*(C'\fR or fatal error reporting functions leading to \f(CW\*(C`abort\*(C'\fR.
  .RE
  .RS 4
  .RE
! .IP \fB\-Walloc\-zero\fR 4
  .IX Item "-Walloc-zero"
  Warn about calls to allocation functions decorated with attribute
! \&\f(CW\*(C`alloc_size\*(C'\fR that specify zero bytes, including those to the built\-in
  forms of the functions \f(CW\*(C`aligned_alloc\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`calloc\*(C'\fR,
  \&\f(CW\*(C`malloc\*(C'\fR, and \f(CW\*(C`realloc\*(C'\fR.  Because the behavior of these functions
  when called with a zero size differs among implementations (and in the case
  of \f(CW\*(C`realloc\*(C'\fR has been deprecated) relying on it may result in subtle
  portability bugs and should be avoided.
! .IP \fB\-Walloc\-size\-larger\-than=\fR\fIbyte\-size\fR 4
  .IX Item "-Walloc-size-larger-than=byte-size"
  Warn about calls to functions decorated with attribute \f(CW\*(C`alloc_size\*(C'\fR
  that attempt to allocate objects larger than the specified number of bytes,
  or where the result of the size computation in an integer type with infinite
! precision would exceed the value of \fBPTRDIFF_MAX\fR on the target.
! \&\fB\-Walloc\-size\-larger\-than=\fR\fBPTRDIFF_MAX\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte\-size\fR of \fBSIZE_MAX\fR or more or by
  \&\fB\-Wno\-alloc\-size\-larger\-than\fR.
! .IP \fB\-Wno\-alloc\-size\-larger\-than\fR 4
  .IX Item "-Wno-alloc-size-larger-than"
  Disable \fB\-Walloc\-size\-larger\-than=\fR warnings.  The option is
! equivalent to \fB\-Walloc\-size\-larger\-than=\fR\fBSIZE_MAX\fR or
  larger.
! .IP \fB\-Walloca\fR 4
  .IX Item "-Walloca"
  This option warns on all uses of \f(CW\*(C`alloca\*(C'\fR in the source.
! .IP \fB\-Walloca\-larger\-than=\fR\fIbyte\-size\fR 4
  .IX Item "-Walloca-larger-than=byte-size"
  This option warns on calls to \f(CW\*(C`alloca\*(C'\fR with an integer argument whose
  value is either zero, or that is not bounded by a controlling predicate
! that limits its value to at most \fIbyte\-size\fR.  It also warns for calls
! to \f(CW\*(C`alloca\*(C'\fR where the bound value is unknown.  Arguments of non\-integer
  types are considered unbounded even if they appear to be constrained to
  the expected range.
  .Sp
*************** expected argument to be implicitly cast
*** 7642,7657 ****
  .Sp
  This option also warns when \f(CW\*(C`alloca\*(C'\fR is used in a loop.
  .Sp
! \&\fB\-Walloca\-larger\-than=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default
  but is usually only effective  when \fB\-ftree\-vrp\fR is active (default
  for \fB\-O2\fR and above).
  .Sp
! See also \fB\-Wvla\-larger\-than=\fR\fBbyte-size\fR.
! .IP "\fB\-Wno\-alloca\-larger\-than\fR" 4
  .IX Item "-Wno-alloca-larger-than"
  Disable \fB\-Walloca\-larger\-than=\fR warnings.  The option is
! equivalent to \fB\-Walloca\-larger\-than=\fR\fB\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Warith\-conversion\fR" 4
  .IX Item "-Warith-conversion"
  Do warn about implicit conversions from arithmetic operations even
  when conversion of the operands to the same type cannot change their
--- 7571,7586 ----
  .Sp
  This option also warns when \f(CW\*(C`alloca\*(C'\fR is used in a loop.
  .Sp
! \&\fB\-Walloca\-larger\-than=\fR\fBPTRDIFF_MAX\fR is enabled by default
  but is usually only effective  when \fB\-ftree\-vrp\fR is active (default
  for \fB\-O2\fR and above).
  .Sp
! See also \fB\-Wvla\-larger\-than=\fR\fBbyte\-size\fR.
! .IP \fB\-Wno\-alloca\-larger\-than\fR 4
  .IX Item "-Wno-alloca-larger-than"
  Disable \fB\-Walloca\-larger\-than=\fR warnings.  The option is
! equivalent to \fB\-Walloca\-larger\-than=\fR\fBSIZE_MAX\fR or larger.
! .IP \fB\-Warith\-conversion\fR 4
  .IX Item "-Warith-conversion"
  Do warn about implicit conversions from arithmetic operations even
  when conversion of the operands to the same type cannot change their
*************** values.  This affects warnings from \fB\
*** 7665,7674 ****
  \&          c = c + 1; // only warns with B<\-Warith\-conversion>
  \&        }
  .Ve
! .IP "\fB\-Warray\-bounds\fR" 4
  .IX Item "-Warray-bounds"
  .PD 0
! .IP "\fB\-Warray\-bounds=\fR\fIn\fR" 4
  .IX Item "-Warray-bounds=n"
  .PD
  Warn about out of bounds subscripts or offsets into arrays.  This warning
--- 7594,7603 ----
  \&          c = c + 1; // only warns with B<\-Warith\-conversion>
  \&        }
  .Ve
! .IP \fB\-Warray\-bounds\fR 4
  .IX Item "-Warray-bounds"
  .PD 0
! .IP \fB\-Warray\-bounds=\fR\fIn\fR 4
  .IX Item "-Warray-bounds=n"
  .PD
  Warn about out of bounds subscripts or offsets into arrays.  This warning
*************** are issued even without optimization.
*** 7679,7687 ****
  By default, the trailing array of a structure will be treated as a flexible
  array member by \fB\-Warray\-bounds\fR or \fB\-Warray\-bounds=\fR\fIn\fR
  if it is declared as either a flexible array member per C99 standard onwards
! (\fB[]\fR), a \s-1GCC\s0 zero-length array extension (\fB[0]\fR), or an one-element
  array (\fB[1]\fR). As a result, out of bounds subscripts or offsets into
! zero-length arrays or one-element arrays are not warned by default.
  .Sp
  You can add the option \fB\-fstrict\-flex\-arrays\fR or
  \&\fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR to control how this
--- 7608,7616 ----
  By default, the trailing array of a structure will be treated as a flexible
  array member by \fB\-Warray\-bounds\fR or \fB\-Warray\-bounds=\fR\fIn\fR
  if it is declared as either a flexible array member per C99 standard onwards
! (\fB[]\fR), a GCC zero\-length array extension (\fB[0]\fR), or an one\-element
  array (\fB[1]\fR). As a result, out of bounds subscripts or offsets into
! zero\-length arrays or one\-element arrays are not warned by default.
  .Sp
  You can add the option \fB\-fstrict\-flex\-arrays\fR or
  \&\fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR to control how this
*************** option treat trailing array of a structu
*** 7690,7705 ****
  when \fIlevel\fR<=1, no change to the default behavior.
  .Sp
  when \fIlevel\fR=2, additional warnings will be issued for out of bounds
! subscripts or offsets into one-element arrays;
  .Sp
  when \fIlevel\fR=3, in addition to \fIlevel\fR=2, additional warnings will be
! issued for out of bounds subscripts or offsets into zero-length arrays.
  .RS 4
! .IP "\fB\-Warray\-bounds=1\fR" 4
  .IX Item "-Warray-bounds=1"
  This is the default warning level of \fB\-Warray\-bounds\fR and is enabled
  by \fB\-Wall\fR; higher levels are not, and must be explicitly requested.
! .IP "\fB\-Warray\-bounds=2\fR" 4
  .IX Item "-Warray-bounds=2"
  This warning level also warns about the intermediate results of pointer
  arithmetic that may yield out of bounds values. This warning level may
--- 7619,7634 ----
  when \fIlevel\fR<=1, no change to the default behavior.
  .Sp
  when \fIlevel\fR=2, additional warnings will be issued for out of bounds
! subscripts or offsets into one\-element arrays;
  .Sp
  when \fIlevel\fR=3, in addition to \fIlevel\fR=2, additional warnings will be
! issued for out of bounds subscripts or offsets into zero\-length arrays.
  .RS 4
! .IP \fB\-Warray\-bounds=1\fR 4
  .IX Item "-Warray-bounds=1"
  This is the default warning level of \fB\-Warray\-bounds\fR and is enabled
  by \fB\-Wall\fR; higher levels are not, and must be explicitly requested.
! .IP \fB\-Warray\-bounds=2\fR 4
  .IX Item "-Warray-bounds=2"
  This warning level also warns about the intermediate results of pointer
  arithmetic that may yield out of bounds values. This warning level may
*************** give a larger number of false positives
*** 7707,7716 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Warray\-compare\fR" 4
  .IX Item "-Warray-compare"
  Warn about equality and relational comparisons between two operands of array
! type.  This comparison was deprecated in \*(C+20.  For example:
  .Sp
  .Vb 3
  \&        int arr1[5];
--- 7636,7645 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Warray\-compare\fR 4
  .IX Item "-Warray-compare"
  Warn about equality and relational comparisons between two operands of array
! type.  This comparison was deprecated in C++20.  For example:
  .Sp
  .Vb 3
  \&        int arr1[5];
*************** type.  This comparison was deprecated in
*** 7719,7733 ****
  .Ve
  .Sp
  \&\fB\-Warray\-compare\fR is enabled by \fB\-Wall\fR.
! .IP "\fB\-Warray\-parameter\fR" 4
  .IX Item "-Warray-parameter"
  .PD 0
! .IP "\fB\-Warray\-parameter=\fR\fIn\fR" 4
  .IX Item "-Warray-parameter=n"
  .PD
  Warn about redeclarations of functions involving arguments of array or
  pointer types of inconsistent kinds or forms, and enable the detection
! of out-of-bounds accesses to such parameters by warnings such as
  \&\fB\-Warray\-bounds\fR.
  .Sp
  If the first function declaration uses the array form the bound specified
--- 7648,7662 ----
  .Ve
  .Sp
  \&\fB\-Warray\-compare\fR is enabled by \fB\-Wall\fR.
! .IP \fB\-Warray\-parameter\fR 4
  .IX Item "-Warray-parameter"
  .PD 0
! .IP \fB\-Warray\-parameter=\fR\fIn\fR 4
  .IX Item "-Warray-parameter=n"
  .PD
  Warn about redeclarations of functions involving arguments of array or
  pointer types of inconsistent kinds or forms, and enable the detection
! of out\-of\-bounds accesses to such parameters by warnings such as
  \&\fB\-Warray\-bounds\fR.
  .Sp
  If the first function declaration uses the array form the bound specified
*************** not trigger a warning.
*** 7769,7789 ****
  \&\fB\-Warray\-parameter=2\fR is included in \fB\-Wall\fR.  The
  \&\fB\-Wvla\-parameter\fR option triggers warnings for similar inconsistencies
  involving Variable Length Array arguments.
! .IP "\fB\-Wattribute\-alias=\fR\fIn\fR" 4
  .IX Item "-Wattribute-alias=n"
  .PD 0
! .IP "\fB\-Wno\-attribute\-alias\fR" 4
  .IX Item "-Wno-attribute-alias"
  .PD
  Warn about declarations using the \f(CW\*(C`alias\*(C'\fR and similar attributes whose
  target is incompatible with the type of the alias.
  .RS 4
! .IP "\fB\-Wattribute\-alias=1\fR" 4
  .IX Item "-Wattribute-alias=1"
  The default warning level of the \fB\-Wattribute\-alias\fR option diagnoses
  incompatibilities between the type of the alias declaration and that of its
  target.  Such incompatibilities are typically indicative of bugs.
! .IP "\fB\-Wattribute\-alias=2\fR" 4
  .IX Item "-Wattribute-alias=2"
  At this level \fB\-Wattribute\-alias\fR also diagnoses cases where
  the attributes of the alias declaration are more restrictive than the
--- 7698,7718 ----
  \&\fB\-Warray\-parameter=2\fR is included in \fB\-Wall\fR.  The
  \&\fB\-Wvla\-parameter\fR option triggers warnings for similar inconsistencies
  involving Variable Length Array arguments.
! .IP \fB\-Wattribute\-alias=\fR\fIn\fR 4
  .IX Item "-Wattribute-alias=n"
  .PD 0
! .IP \fB\-Wno\-attribute\-alias\fR 4
  .IX Item "-Wno-attribute-alias"
  .PD
  Warn about declarations using the \f(CW\*(C`alias\*(C'\fR and similar attributes whose
  target is incompatible with the type of the alias.
  .RS 4
! .IP \fB\-Wattribute\-alias=1\fR 4
  .IX Item "-Wattribute-alias=1"
  The default warning level of the \fB\-Wattribute\-alias\fR option diagnoses
  incompatibilities between the type of the alias declaration and that of its
  target.  Such incompatibilities are typically indicative of bugs.
! .IP \fB\-Wattribute\-alias=2\fR 4
  .IX Item "-Wattribute-alias=2"
  At this level \fB\-Wattribute\-alias\fR also diagnoses cases where
  the attributes of the alias declaration are more restrictive than the
*************** Attributes considered include \f(CW\*(C`
*** 7805,7820 ****
  This is the default.  You can disable these warnings with either
  \&\fB\-Wno\-attribute\-alias\fR or \fB\-Wattribute\-alias=0\fR.
  .RE
! .IP "\fB\-Wbidi\-chars=\fR[\fBnone\fR|\fBunpaired\fR|\fBany\fR|\fBucn\fR]" 4
  .IX Item "-Wbidi-chars=[none|unpaired|any|ucn]"
! Warn about possibly misleading \s-1UTF\-8\s0 bidirectional control characters in
  comments, string literals, character constants, and identifiers.  Such
! characters can change left-to-right writing direction into right-to-left
  (and vice versa), which can cause confusion between the logical order and
  visual order.  This may be dangerous; for instance, it may seem that a piece
  of code is not commented out, whereas it in fact is.
  .Sp
! There are three levels of warning supported by \s-1GCC.\s0  The default is
  \&\fB\-Wbidi\-chars=unpaired\fR, which warns about improperly terminated
  bidi contexts.  \fB\-Wbidi\-chars=none\fR turns the warning off.
  \&\fB\-Wbidi\-chars=any\fR warns about any use of bidirectional control
--- 7734,7749 ----
  This is the default.  You can disable these warnings with either
  \&\fB\-Wno\-attribute\-alias\fR or \fB\-Wattribute\-alias=0\fR.
  .RE
! .IP \fB\-Wbidi\-chars=\fR[\fBnone\fR|\fBunpaired\fR|\fBany\fR|\fBucn\fR] 4
  .IX Item "-Wbidi-chars=[none|unpaired|any|ucn]"
! Warn about possibly misleading UTF\-8 bidirectional control characters in
  comments, string literals, character constants, and identifiers.  Such
! characters can change left\-to\-right writing direction into right\-to\-left
  (and vice versa), which can cause confusion between the logical order and
  visual order.  This may be dangerous; for instance, it may seem that a piece
  of code is not commented out, whereas it in fact is.
  .Sp
! There are three levels of warning supported by GCC.  The default is
  \&\fB\-Wbidi\-chars=unpaired\fR, which warns about improperly terminated
  bidi contexts.  \fB\-Wbidi\-chars=none\fR turns the warning off.
  \&\fB\-Wbidi\-chars=any\fR warns about any use of bidirectional control
*************** to turn on such checking by using \fB\-W
*** 7825,7831 ****
  \&\fB\-Wbidi\-chars=any,ucn\fR.  Using \fB\-Wbidi\-chars=ucn\fR is valid,
  and is equivalent to \fB\-Wbidi\-chars=unpaired,ucn\fR, if no previous
  \&\fB\-Wbidi\-chars=any\fR was specified.
! .IP "\fB\-Wbool\-compare\fR" 4
  .IX Item "-Wbool-compare"
  Warn about boolean expression compared with an integer value different from
  \&\f(CW\*(C`true\*(C'\fR/\f(CW\*(C`false\*(C'\fR.  For instance, the following comparison is
--- 7754,7760 ----
  \&\fB\-Wbidi\-chars=any,ucn\fR.  Using \fB\-Wbidi\-chars=ucn\fR is valid,
  and is equivalent to \fB\-Wbidi\-chars=unpaired,ucn\fR, if no previous
  \&\fB\-Wbidi\-chars=any\fR was specified.
! .IP \fB\-Wbool\-compare\fR 4
  .IX Item "-Wbool-compare"
  Warn about boolean expression compared with an integer value different from
  \&\f(CW\*(C`true\*(C'\fR/\f(CW\*(C`false\*(C'\fR.  For instance, the following comparison is
*************** always false:
*** 7838,7855 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wbool\-operation\fR" 4
  .IX Item "-Wbool-operation"
  Warn about suspicious operations on expressions of a boolean type.  For
  instance, bitwise negation of a boolean is very likely a bug in the program.
  For C, this warning also warns about incrementing or decrementing a boolean,
! which rarely makes sense.  (In \*(C+, decrementing a boolean is always invalid.
! Incrementing a boolean is invalid in \*(C+17, and deprecated otherwise.)
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wduplicated\-branches\fR" 4
  .IX Item "-Wduplicated-branches"
! Warn when an if-else has identical branches.  This warning detects cases like
  .Sp
  .Vb 4
  \&        if (p != NULL)
--- 7767,7784 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wbool\-operation\fR 4
  .IX Item "-Wbool-operation"
  Warn about suspicious operations on expressions of a boolean type.  For
  instance, bitwise negation of a boolean is very likely a bug in the program.
  For C, this warning also warns about incrementing or decrementing a boolean,
! which rarely makes sense.  (In C++, decrementing a boolean is always invalid.
! Incrementing a boolean is invalid in C++17, and deprecated otherwise.)
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wduplicated\-branches\fR 4
  .IX Item "-Wduplicated-branches"
! Warn when an if\-else has identical branches.  This warning detects cases like
  .Sp
  .Vb 4
  \&        if (p != NULL)
*************** Warn when an if-else has identical branc
*** 7858,7912 ****
  \&          return 0;
  .Ve
  .Sp
! It doesn't warn when both branches contain just a null statement.  This warning
  also warn for conditional operators:
  .Sp
  .Vb 1
  \&          int i = x ? *p : *p;
  .Ve
! .IP "\fB\-Wduplicated\-cond\fR" 4
  .IX Item "-Wduplicated-cond"
! Warn about duplicated conditions in an if-else-if chain.  For instance,
  warn for the following code:
  .Sp
  .Vb 2
  \&        if (p\->q != NULL) { ... }
  \&        else if (p\->q != NULL) { ... }
  .Ve
! .IP "\fB\-Wframe\-address\fR" 4
  .IX Item "-Wframe-address"
  Warn when the \fB_\|_builtin_frame_address\fR or \fB_\|_builtin_return_address\fR
  is called with an argument greater than 0.  Such calls may return indeterminate
  values or crash the program.  The warning is included in \fB\-Wall\fR.
! .IP "\fB\-Wno\-discarded\-qualifiers\fR (C and Objective-C only)" 4
  .IX Item "-Wno-discarded-qualifiers (C and Objective-C only)"
  Do not warn if type qualifiers on pointers are being discarded.
  Typically, the compiler warns if a \f(CW\*(C`const char *\*(C'\fR variable is
  passed to a function that takes a \f(CW\*(C`char *\*(C'\fR parameter.  This option
  can be used to suppress such a warning.
! .IP "\fB\-Wno\-discarded\-array\-qualifiers\fR (C and Objective-C only)" 4
  .IX Item "-Wno-discarded-array-qualifiers (C and Objective-C only)"
  Do not warn if type qualifiers on arrays which are pointer targets
  are being discarded.  Typically, the compiler warns if a
  \&\f(CW\*(C`const int (*)[]\*(C'\fR variable is passed to a function that
  takes a \f(CW\*(C`int (*)[]\*(C'\fR parameter.  This option can be used to
  suppress such a warning.
! .IP "\fB\-Wno\-incompatible\-pointer\-types\fR (C and Objective-C only)" 4
  .IX Item "-Wno-incompatible-pointer-types (C and Objective-C only)"
  Do not warn when there is a conversion between pointers that have incompatible
  types.  This warning is for cases not covered by \fB\-Wno\-pointer\-sign\fR,
  which warns for pointer argument passing or assignment with different
  signedness.
! .IP "\fB\-Wno\-int\-conversion\fR (C and Objective-C only)" 4
  .IX Item "-Wno-int-conversion (C and Objective-C only)"
  Do not warn about incompatible integer to pointer and pointer to integer
  conversions.  This warning is about implicit conversions; for explicit
  conversions the warnings \fB\-Wno\-int\-to\-pointer\-cast\fR and
  \&\fB\-Wno\-pointer\-to\-int\-cast\fR may be used.
! .IP "\fB\-Wzero\-length\-bounds\fR" 4
  .IX Item "-Wzero-length-bounds"
! Warn about accesses to elements of zero-length array members that might
! overlap other members of the same object.  Declaring interior zero-length
  arrays is discouraged because accesses to them are undefined.
  .Sp
  For example, the first two stores in function \f(CW\*(C`bad\*(C'\fR are diagnosed
--- 7787,7841 ----
  \&          return 0;
  .Ve
  .Sp
! It doesn\*(Aqt warn when both branches contain just a null statement.  This warning
  also warn for conditional operators:
  .Sp
  .Vb 1
  \&          int i = x ? *p : *p;
  .Ve
! .IP \fB\-Wduplicated\-cond\fR 4
  .IX Item "-Wduplicated-cond"
! Warn about duplicated conditions in an if\-else\-if chain.  For instance,
  warn for the following code:
  .Sp
  .Vb 2
  \&        if (p\->q != NULL) { ... }
  \&        else if (p\->q != NULL) { ... }
  .Ve
! .IP \fB\-Wframe\-address\fR 4
  .IX Item "-Wframe-address"
  Warn when the \fB_\|_builtin_frame_address\fR or \fB_\|_builtin_return_address\fR
  is called with an argument greater than 0.  Such calls may return indeterminate
  values or crash the program.  The warning is included in \fB\-Wall\fR.
! .IP "\fB\-Wno\-discarded\-qualifiers\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-discarded-qualifiers (C and Objective-C only)"
  Do not warn if type qualifiers on pointers are being discarded.
  Typically, the compiler warns if a \f(CW\*(C`const char *\*(C'\fR variable is
  passed to a function that takes a \f(CW\*(C`char *\*(C'\fR parameter.  This option
  can be used to suppress such a warning.
! .IP "\fB\-Wno\-discarded\-array\-qualifiers\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-discarded-array-qualifiers (C and Objective-C only)"
  Do not warn if type qualifiers on arrays which are pointer targets
  are being discarded.  Typically, the compiler warns if a
  \&\f(CW\*(C`const int (*)[]\*(C'\fR variable is passed to a function that
  takes a \f(CW\*(C`int (*)[]\*(C'\fR parameter.  This option can be used to
  suppress such a warning.
! .IP "\fB\-Wno\-incompatible\-pointer\-types\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-incompatible-pointer-types (C and Objective-C only)"
  Do not warn when there is a conversion between pointers that have incompatible
  types.  This warning is for cases not covered by \fB\-Wno\-pointer\-sign\fR,
  which warns for pointer argument passing or assignment with different
  signedness.
! .IP "\fB\-Wno\-int\-conversion\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-int-conversion (C and Objective-C only)"
  Do not warn about incompatible integer to pointer and pointer to integer
  conversions.  This warning is about implicit conversions; for explicit
  conversions the warnings \fB\-Wno\-int\-to\-pointer\-cast\fR and
  \&\fB\-Wno\-pointer\-to\-int\-cast\fR may be used.
! .IP \fB\-Wzero\-length\-bounds\fR 4
  .IX Item "-Wzero-length-bounds"
! Warn about accesses to elements of zero\-length array members that might
! overlap other members of the same object.  Declaring interior zero\-length
  arrays is discouraged because accesses to them are undefined.
  .Sp
  For example, the first two stores in function \f(CW\*(C`bad\*(C'\fR are diagnosed
*************** because it is beyond the bounds of the e
*** 7927,7950 ****
  .Ve
  .Sp
  Option \fB\-Wzero\-length\-bounds\fR is enabled by \fB\-Warray\-bounds\fR.
! .IP "\fB\-Wno\-div\-by\-zero\fR" 4
  .IX Item "-Wno-div-by-zero"
! Do not warn about compile-time integer division by zero.  Floating-point
  division by zero is not warned about, as it can be a legitimate way of
  obtaining infinities and NaNs.
! .IP "\fB\-Wsystem\-headers\fR" 4
  .IX Item "-Wsystem-headers"
  Print warning messages for constructs found in system header files.
  Warnings from system headers are normally suppressed, on the assumption
  that they usually do not indicate real problems and would only make the
! compiler output harder to read.  Using this command-line option tells
! \&\s-1GCC\s0 to emit warnings from system headers as if they occurred in user
  code.  However, note that using \fB\-Wall\fR in conjunction with this
  option does \fInot\fR warn about unknown pragmas in system
  headers\-\-\-for that, \fB\-Wunknown\-pragmas\fR must also be used.
! .IP "\fB\-Wtautological\-compare\fR" 4
  .IX Item "-Wtautological-compare"
! Warn if a self-comparison always evaluates to true or false.  This
  warning detects various mistakes such as:
  .Sp
  .Vb 3
--- 7856,7879 ----
  .Ve
  .Sp
  Option \fB\-Wzero\-length\-bounds\fR is enabled by \fB\-Warray\-bounds\fR.
! .IP \fB\-Wno\-div\-by\-zero\fR 4
  .IX Item "-Wno-div-by-zero"
! Do not warn about compile\-time integer division by zero.  Floating\-point
  division by zero is not warned about, as it can be a legitimate way of
  obtaining infinities and NaNs.
! .IP \fB\-Wsystem\-headers\fR 4
  .IX Item "-Wsystem-headers"
  Print warning messages for constructs found in system header files.
  Warnings from system headers are normally suppressed, on the assumption
  that they usually do not indicate real problems and would only make the
! compiler output harder to read.  Using this command\-line option tells
! GCC to emit warnings from system headers as if they occurred in user
  code.  However, note that using \fB\-Wall\fR in conjunction with this
  option does \fInot\fR warn about unknown pragmas in system
  headers\-\-\-for that, \fB\-Wunknown\-pragmas\fR must also be used.
! .IP \fB\-Wtautological\-compare\fR 4
  .IX Item "-Wtautological-compare"
! Warn if a self\-comparison always evaluates to true or false.  This
  warning detects various mistakes such as:
  .Sp
  .Vb 3
*************** to true or false, for instance:
*** 7963,7969 ****
  will always be false.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wtrampolines\fR" 4
  .IX Item "-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
--- 7892,7898 ----
  will always be false.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wtrampolines\fR 4
  .IX Item "-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
*************** used to call the nested function indirec
*** 7972,8002 ****
  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.
! .IP "\fB\-Wfloat\-equal\fR" 4
  .IX Item "-Wfloat-equal"
! Warn if floating-point values are used in equality comparisons.
  .Sp
  The idea behind this is that sometimes it is convenient (for the
! programmer) to consider floating-point values as approximations to
  infinitely precise real numbers.  If you are doing this, then you need
  to compute (by analyzing the code, or in some other way) the maximum or
  likely maximum error that the computation introduces, and allow for it
! when performing comparisons (and when producing output, but that's a
  different problem).  In particular, instead of testing for equality, you
  should check to see whether the two values have ranges that overlap; and
  this is done with the relational operators, so equality comparisons are
  probably mistaken.
! .IP "\fB\-Wtraditional\fR (C and Objective-C only)" 4
  .IX Item "-Wtraditional (C and Objective-C only)"
  Warn about certain constructs that behave differently in traditional and
! \&\s-1ISO C.\s0  Also warn about \s-1ISO C\s0 constructs that have no traditional C
  equivalent, and/or problematic constructs that should be avoided.
  .RS 4
! .IP "*" 4
  Macro parameters that appear within string literals in the macro body.
  In traditional C macro replacement takes place within string literals,
! but in \s-1ISO C\s0 it does not.
! .IP "*" 4
  In traditional C, some preprocessor directives did not exist.
  Traditional preprocessors only considered a line to be a directive
  if the \fB#\fR appeared in column 1 on the line.  Therefore
--- 7901,7931 ----
  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.
! .IP \fB\-Wfloat\-equal\fR 4
  .IX Item "-Wfloat-equal"
! Warn if floating\-point values are used in equality comparisons.
  .Sp
  The idea behind this is that sometimes it is convenient (for the
! programmer) to consider floating\-point values as approximations to
  infinitely precise real numbers.  If you are doing this, then you need
  to compute (by analyzing the code, or in some other way) the maximum or
  likely maximum error that the computation introduces, and allow for it
! when performing comparisons (and when producing output, but that\*(Aqs a
  different problem).  In particular, instead of testing for equality, you
  should check to see whether the two values have ranges that overlap; and
  this is done with the relational operators, so equality comparisons are
  probably mistaken.
! .IP "\fB\-Wtraditional\fR (C and Objective\-C only)" 4
  .IX Item "-Wtraditional (C and Objective-C only)"
  Warn about certain constructs that behave differently in traditional and
! ISO C.  Also warn about ISO C constructs that have no traditional C
  equivalent, and/or problematic constructs that should be avoided.
  .RS 4
! .IP * 4
  Macro parameters that appear within string literals in the macro body.
  In traditional C macro replacement takes place within string literals,
! but in ISO C it does not.
! .IP * 4
  In traditional C, some preprocessor directives did not exist.
  Traditional preprocessors only considered a line to be a directive
  if the \fB#\fR appeared in column 1 on the line.  Therefore
*************** first character on the line.  It also su
*** 8006,8104 ****
  \&\f(CW\*(C`#pragma\*(C'\fR not understood by traditional C by indenting them.  Some
  traditional implementations do not recognize \f(CW\*(C`#elif\*(C'\fR, so this option
  suggests avoiding it altogether.
! .IP "*" 4
! A function-like macro that appears without arguments.
! .IP "*" 4
  The unary plus operator.
! .IP "*" 4
! The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating-point
  constant suffixes.  (Traditional C does support the \fBL\fR suffix on integer
  constants.)  Note, these suffixes appear in macros defined in the system
  headers of most modern systems, e.g. the \fB_MIN\fR/\fB_MAX\fR macros in \f(CW\*(C`\*(C'\fR.
  Use of these macros in user code might normally lead to spurious
! warnings, however \s-1GCC\s0's integrated preprocessor has enough context to
  avoid warning in these cases.
! .IP "*" 4
  A function declared external in one block and then used after the end of
  the block.
! .IP "*" 4
  A \f(CW\*(C`switch\*(C'\fR statement has an operand of type \f(CW\*(C`long\*(C'\fR.
! .IP "*" 4
  A non\-\f(CW\*(C`static\*(C'\fR function declaration follows a \f(CW\*(C`static\*(C'\fR one.
  This construct is not accepted by some traditional C compilers.
! .IP "*" 4
! The \s-1ISO\s0 type of an integer constant has a different width or
  signedness from its traditional type.  This warning is only issued if
  the base of the constant is ten.  I.e. hexadecimal or octal values, which
  typically represent bit patterns, are not warned about.
! .IP "*" 4
! Usage of \s-1ISO\s0 string concatenation is detected.
! .IP "*" 4
  Initialization of automatic aggregates.
! .IP "*" 4
  Identifier conflicts with labels.  Traditional C lacks a separate
  namespace for labels.
! .IP "*" 4
  Initialization of unions.  If the initializer is zero, the warning is
  omitted.  This is done under the assumption that the zero initializer in
  user code appears conditioned on e.g. \f(CW\*(C`_\|_STDC_\|_\*(C'\fR to avoid missing
  initializer warnings and relies on default initialization to zero in the
  traditional C case.
! .IP "*" 4
  Conversions by prototypes between fixed/floating\-point values and vice
  versa.  The absence of these prototypes when compiling with traditional
  C causes serious problems.  This is a subset of the possible
  conversion warnings; for the full set use \fB\-Wtraditional\-conversion\fR.
! .IP "*" 4
! Use of \s-1ISO C\s0 style function definitions.  This warning intentionally is
  \&\fInot\fR issued for prototype declarations or variadic functions
! because these \s-1ISO C\s0 features appear in your code when using
! libiberty's traditional C compatibility macros, \f(CW\*(C`PARAMS\*(C'\fR and
  \&\f(CW\*(C`VPARAMS\*(C'\fR.  This warning is also bypassed for nested functions
! because that feature is already a \s-1GCC\s0 extension and thus not relevant to
  traditional C compatibility.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wtraditional\-conversion\fR (C and Objective-C only)" 4
  .IX Item "-Wtraditional-conversion (C and Objective-C only)"
  Warn if a prototype causes a type conversion that is different from what
  would happen to the same argument in the absence of a prototype.  This
  includes conversions of fixed point to floating and vice versa, and
! conversions changing the width or signedness of a fixed-point argument
  except when the same as the default promotion.
! .IP "\fB\-Wdeclaration\-after\-statement\fR (C and Objective-C only)" 4
  .IX Item "-Wdeclaration-after-statement (C and Objective-C only)"
  Warn when a declaration is found after a statement in a block.  This
! construct, known from \*(C+, was introduced with \s-1ISO C99\s0 and is by default
! allowed in \s-1GCC.\s0  It is not supported by \s-1ISO C90.\s0
! .IP "\fB\-Wshadow\fR" 4
  .IX Item "-Wshadow"
  Warn whenever a local variable or type declaration shadows another
! variable, parameter, type, class member (in \*(C+), or instance variable
! (in Objective-C) or whenever a built-in function is shadowed.  Note
! that in \*(C+, the compiler warns if a local variable shadows an
  explicit typedef, but not if it shadows a struct/class/enum.
  If this warning is enabled, it includes also all instances of
  local shadowing.  This means that \fB\-Wno\-shadow=local\fR
  and \fB\-Wno\-shadow=compatible\-local\fR are ignored when
  \&\fB\-Wshadow\fR is used.
  Same as \fB\-Wshadow=global\fR.
! .IP "\fB\-Wno\-shadow\-ivar\fR (Objective-C only)" 4
  .IX Item "-Wno-shadow-ivar (Objective-C only)"
  Do not warn whenever a local variable shadows an instance variable in an
! Objective-C method.
! .IP "\fB\-Wshadow=global\fR" 4
  .IX Item "-Wshadow=global"
  Warn for any shadowing.
  Same as \fB\-Wshadow\fR.
! .IP "\fB\-Wshadow=local\fR" 4
  .IX Item "-Wshadow=local"
  Warn when a local variable shadows another local variable or parameter.
! .IP "\fB\-Wshadow=compatible\-local\fR" 4
  .IX Item "-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 \fB\-Wshadow=local\fR) is based on the idea that when
--- 7935,8033 ----
  \&\f(CW\*(C`#pragma\*(C'\fR not understood by traditional C by indenting them.  Some
  traditional implementations do not recognize \f(CW\*(C`#elif\*(C'\fR, so this option
  suggests avoiding it altogether.
! .IP * 4
! A function\-like macro that appears without arguments.
! .IP * 4
  The unary plus operator.
! .IP * 4
! The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating\-point
  constant suffixes.  (Traditional C does support the \fBL\fR suffix on integer
  constants.)  Note, these suffixes appear in macros defined in the system
  headers of most modern systems, e.g. the \fB_MIN\fR/\fB_MAX\fR macros in \f(CW\*(C`\*(C'\fR.
  Use of these macros in user code might normally lead to spurious
! warnings, however GCC\*(Aqs integrated preprocessor has enough context to
  avoid warning in these cases.
! .IP * 4
  A function declared external in one block and then used after the end of
  the block.
! .IP * 4
  A \f(CW\*(C`switch\*(C'\fR statement has an operand of type \f(CW\*(C`long\*(C'\fR.
! .IP * 4
  A non\-\f(CW\*(C`static\*(C'\fR function declaration follows a \f(CW\*(C`static\*(C'\fR one.
  This construct is not accepted by some traditional C compilers.
! .IP * 4
! 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.
! .IP * 4
! Usage of ISO string concatenation is detected.
! .IP * 4
  Initialization of automatic aggregates.
! .IP * 4
  Identifier conflicts with labels.  Traditional C lacks a separate
  namespace for labels.
! .IP * 4
  Initialization of unions.  If the initializer is zero, the warning is
  omitted.  This is done under the assumption that the zero initializer in
  user code appears conditioned on e.g. \f(CW\*(C`_\|_STDC_\|_\*(C'\fR to avoid missing
  initializer warnings and relies on default initialization to zero in the
  traditional C case.
! .IP * 4
  Conversions by prototypes between fixed/floating\-point values and vice
  versa.  The absence of these prototypes when compiling with traditional
  C causes serious problems.  This is a subset of the possible
  conversion warnings; for the full set use \fB\-Wtraditional\-conversion\fR.
! .IP * 4
! Use of ISO C style function definitions.  This warning intentionally is
  \&\fInot\fR issued for prototype declarations or variadic functions
! because these ISO C features appear in your code when using
! libiberty\*(Aqs traditional C compatibility macros, \f(CW\*(C`PARAMS\*(C'\fR and
  \&\f(CW\*(C`VPARAMS\*(C'\fR.  This warning is also bypassed for nested functions
! because that feature is already a GCC extension and thus not relevant to
  traditional C compatibility.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wtraditional\-conversion\fR (C and Objective\-C only)" 4
  .IX Item "-Wtraditional-conversion (C and Objective-C only)"
  Warn if a prototype causes a type conversion that is different from what
  would happen to the same argument in the absence of a prototype.  This
  includes conversions of fixed point to floating and vice versa, and
! conversions changing the width or signedness of a fixed\-point argument
  except when the same as the default promotion.
! .IP "\fB\-Wdeclaration\-after\-statement\fR (C and Objective\-C only)" 4
  .IX Item "-Wdeclaration-after-statement (C and Objective-C only)"
  Warn when a declaration is found after a statement in a block.  This
! construct, known from C++, was introduced with ISO C99 and is by default
! allowed in GCC.  It is not supported by ISO C90.
! .IP \fB\-Wshadow\fR 4
  .IX Item "-Wshadow"
  Warn whenever a local variable or type declaration shadows another
! variable, parameter, type, class member (in C++), or instance variable
! (in Objective\-C) or whenever a built\-in function is shadowed.  Note
! that in C++, the compiler warns if a local variable shadows an
  explicit typedef, but not if it shadows a struct/class/enum.
  If this warning is enabled, it includes also all instances of
  local shadowing.  This means that \fB\-Wno\-shadow=local\fR
  and \fB\-Wno\-shadow=compatible\-local\fR are ignored when
  \&\fB\-Wshadow\fR is used.
  Same as \fB\-Wshadow=global\fR.
! .IP "\fB\-Wno\-shadow\-ivar\fR (Objective\-C only)" 4
  .IX Item "-Wno-shadow-ivar (Objective-C only)"
  Do not warn whenever a local variable shadows an instance variable in an
! Objective\-C method.
! .IP \fB\-Wshadow=global\fR 4
  .IX Item "-Wshadow=global"
  Warn for any shadowing.
  Same as \fB\-Wshadow\fR.
! .IP \fB\-Wshadow=local\fR 4
  .IX Item "-Wshadow=local"
  Warn when a local variable shadows another local variable or parameter.
! .IP \fB\-Wshadow=compatible\-local\fR 4
  .IX Item "-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 \fB\-Wshadow=local\fR) is based on the idea that when
*************** Note that this also means that shadowing
*** 8126,8165 ****
  \&\f(CW\*(C`char *i\*(C'\fR does not emit a warning.
  .Sp
  This warning is also enabled by \fB\-Wshadow=local\fR.
! .IP "\fB\-Wlarger\-than=\fR\fIbyte-size\fR" 4
  .IX Item "-Wlarger-than=byte-size"
! Warn whenever an object is defined whose size exceeds \fIbyte-size\fR.
! \&\fB\-Wlarger\-than=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte-size\fR of \fB\s-1SIZE_MAX\s0\fR or more or by \fB\-Wno\-larger\-than\fR.
  .Sp
  Also warn for calls to bounded functions such as \f(CW\*(C`memchr\*(C'\fR or
  \&\f(CW\*(C`strnlen\*(C'\fR that specify a bound greater than the largest possible
! object, which is \fB\s-1PTRDIFF_MAX\s0\fR bytes by default.  These warnings
  can only be disabled by \fB\-Wno\-larger\-than\fR.
! .IP "\fB\-Wno\-larger\-than\fR" 4
  .IX Item "-Wno-larger-than"
  Disable \fB\-Wlarger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wlarger\-than=\fR\fB\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Wframe\-larger\-than=\fR\fIbyte-size\fR" 4
  .IX Item "-Wframe-larger-than=byte-size"
! Warn if the size of a function frame exceeds \fIbyte-size\fR.
  The computation done to determine the stack frame size is approximate
  and not conservative.
! The actual requirements may be somewhat greater than \fIbyte-size\fR
  even if you do not get a warning.  In addition, any space allocated
! via \f(CW\*(C`alloca\*(C'\fR, variable-length arrays, or related constructs
  is not included by the compiler when determining
  whether or not to issue a warning.
! \&\fB\-Wframe\-larger\-than=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte-size\fR of \fB\s-1SIZE_MAX\s0\fR or more or by
  \&\fB\-Wno\-frame\-larger\-than\fR.
! .IP "\fB\-Wno\-frame\-larger\-than\fR" 4
  .IX Item "-Wno-frame-larger-than"
  Disable \fB\-Wframe\-larger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wframe\-larger\-than=\fR\fB\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Wfree\-nonheap\-object\fR" 4
  .IX Item "-Wfree-nonheap-object"
  Warn when attempting to deallocate an object that was either not allocated
  on the heap, or by using a pointer that was not returned from a prior call
--- 8055,8094 ----
  \&\f(CW\*(C`char *i\*(C'\fR does not emit a warning.
  .Sp
  This warning is also enabled by \fB\-Wshadow=local\fR.
! .IP \fB\-Wlarger\-than=\fR\fIbyte\-size\fR 4
  .IX Item "-Wlarger-than=byte-size"
! Warn whenever an object is defined whose size exceeds \fIbyte\-size\fR.
! \&\fB\-Wlarger\-than=\fR\fBPTRDIFF_MAX\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte\-size\fR of \fBSIZE_MAX\fR or more or by \fB\-Wno\-larger\-than\fR.
  .Sp
  Also warn for calls to bounded functions such as \f(CW\*(C`memchr\*(C'\fR or
  \&\f(CW\*(C`strnlen\*(C'\fR that specify a bound greater than the largest possible
! object, which is \fBPTRDIFF_MAX\fR bytes by default.  These warnings
  can only be disabled by \fB\-Wno\-larger\-than\fR.
! .IP \fB\-Wno\-larger\-than\fR 4
  .IX Item "-Wno-larger-than"
  Disable \fB\-Wlarger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wlarger\-than=\fR\fBSIZE_MAX\fR or larger.
! .IP \fB\-Wframe\-larger\-than=\fR\fIbyte\-size\fR 4
  .IX Item "-Wframe-larger-than=byte-size"
! Warn if the size of a function frame exceeds \fIbyte\-size\fR.
  The computation done to determine the stack frame size is approximate
  and not conservative.
! The actual requirements may be somewhat greater than \fIbyte\-size\fR
  even if you do not get a warning.  In addition, any space allocated
! via \f(CW\*(C`alloca\*(C'\fR, variable\-length arrays, or related constructs
  is not included by the compiler when determining
  whether or not to issue a warning.
! \&\fB\-Wframe\-larger\-than=\fR\fBPTRDIFF_MAX\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte\-size\fR of \fBSIZE_MAX\fR or more or by
  \&\fB\-Wno\-frame\-larger\-than\fR.
! .IP \fB\-Wno\-frame\-larger\-than\fR 4
  .IX Item "-Wno-frame-larger-than"
  Disable \fB\-Wframe\-larger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wframe\-larger\-than=\fR\fBSIZE_MAX\fR or larger.
! .IP \fB\-Wfree\-nonheap\-object\fR 4
  .IX Item "-Wfree-nonheap-object"
  Warn when attempting to deallocate an object that was either not allocated
  on the heap, or by using a pointer that was not returned from a prior call
*************** diagnosed.
*** 8178,8207 ****
  .Ve
  .Sp
  \&\fB\-Wfree\-nonheap\-object\fR is included in \fB\-Wall\fR.
! .IP "\fB\-Wstack\-usage=\fR\fIbyte-size\fR" 4
  .IX Item "-Wstack-usage=byte-size"
! Warn if the stack usage of a function might exceed \fIbyte-size\fR.
  The computation done to determine the stack usage is conservative.
! Any space allocated via \f(CW\*(C`alloca\*(C'\fR, variable-length arrays, or related
  constructs is included by the compiler when determining whether or not to
  issue a warning.
  .Sp
  The message is in keeping with the output of \fB\-fstack\-usage\fR.
  .RS 4
! .IP "*" 4
! If the stack usage is fully static but exceeds the specified amount, it's:
  .Sp
  .Vb 1
  \&          warning: stack usage is 1120 bytes
  .Ve
! .IP "*" 4
! If the stack usage is (partly) dynamic but bounded, it's:
  .Sp
  .Vb 1
  \&          warning: stack usage might be 1648 bytes
  .Ve
! .IP "*" 4
! If the stack usage is (partly) dynamic and not bounded, it's:
  .Sp
  .Vb 1
  \&          warning: stack usage might be unbounded
--- 8107,8136 ----
  .Ve
  .Sp
  \&\fB\-Wfree\-nonheap\-object\fR is included in \fB\-Wall\fR.
! .IP \fB\-Wstack\-usage=\fR\fIbyte\-size\fR 4
  .IX Item "-Wstack-usage=byte-size"
! Warn if the stack usage of a function might exceed \fIbyte\-size\fR.
  The computation done to determine the stack usage is conservative.
! Any space allocated via \f(CW\*(C`alloca\*(C'\fR, variable\-length arrays, or related
  constructs is included by the compiler when determining whether or not to
  issue a warning.
  .Sp
  The message is in keeping with the output of \fB\-fstack\-usage\fR.
  .RS 4
! .IP * 4
! If the stack usage is fully static but exceeds the specified amount, it\*(Aqs:
  .Sp
  .Vb 1
  \&          warning: stack usage is 1120 bytes
  .Ve
! .IP * 4
! If the stack usage is (partly) dynamic but bounded, it\*(Aqs:
  .Sp
  .Vb 1
  \&          warning: stack usage might be 1648 bytes
  .Ve
! .IP * 4
! If the stack usage is (partly) dynamic and not bounded, it\*(Aqs:
  .Sp
  .Vb 1
  \&          warning: stack usage might be unbounded
*************** If the stack usage is (partly) dynamic a
*** 8209,8224 ****
  .RE
  .RS 4
  .Sp
! \&\fB\-Wstack\-usage=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte-size\fR of \fB\s-1SIZE_MAX\s0\fR or more or by
  \&\fB\-Wno\-stack\-usage\fR.
  .RE
! .IP "\fB\-Wno\-stack\-usage\fR" 4
  .IX Item "-Wno-stack-usage"
  Disable \fB\-Wstack\-usage=\fR warnings.  The option is equivalent
! to \fB\-Wstack\-usage=\fR\fB\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Wunsafe\-loop\-optimizations\fR" 4
  .IX Item "-Wunsafe-loop-optimizations"
  Warn if the loop cannot be optimized because the compiler cannot
  assume anything on the bounds of the loop indices.  With
--- 8138,8153 ----
  .RE
  .RS 4
  .Sp
! \&\fB\-Wstack\-usage=\fR\fBPTRDIFF_MAX\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte\-size\fR of \fBSIZE_MAX\fR or more or by
  \&\fB\-Wno\-stack\-usage\fR.
  .RE
! .IP \fB\-Wno\-stack\-usage\fR 4
  .IX Item "-Wno-stack-usage"
  Disable \fB\-Wstack\-usage=\fR warnings.  The option is equivalent
! to \fB\-Wstack\-usage=\fR\fBSIZE_MAX\fR or larger.
! .IP \fB\-Wunsafe\-loop\-optimizations\fR 4
  .IX Item "-Wunsafe-loop-optimizations"
  Warn if the loop cannot be optimized because the compiler cannot
  assume anything on the bounds of the loop indices.  With
*************** such assumptions.
*** 8227,8244 ****
  .IP "\fB\-Wno\-pedantic\-ms\-format\fR (MinGW targets only)" 4
  .IX Item "-Wno-pedantic-ms-format (MinGW targets only)"
  When used in combination with \fB\-Wformat\fR
! and \fB\-pedantic\fR without \s-1GNU\s0 extensions, this option
! disables the warnings about non-ISO \f(CW\*(C`printf\*(C'\fR / \f(CW\*(C`scanf\*(C'\fR format
  width specifiers \f(CW\*(C`I32\*(C'\fR, \f(CW\*(C`I64\*(C'\fR, and \f(CW\*(C`I\*(C'\fR used on Windows targets,
! which depend on the \s-1MS\s0 runtime.
! .IP "\fB\-Wpointer\-arith\fR" 4
  .IX Item "-Wpointer-arith"
! Warn about anything that depends on the \*(L"size of\*(R" a function type or
! of \f(CW\*(C`void\*(C'\fR.  \s-1GNU C\s0 assigns these types a size of 1, for
  convenience in calculations with \f(CW\*(C`void *\*(C'\fR pointers and pointers
! to functions.  In \*(C+, warn also when an arithmetic operation involves
  \&\f(CW\*(C`NULL\*(C'\fR.  This warning is also enabled by \fB\-Wpedantic\fR.
! .IP "\fB\-Wno\-pointer\-compare\fR" 4
  .IX Item "-Wno-pointer-compare"
  Do not warn if a pointer is compared with a zero character constant.
  This usually
--- 8156,8173 ----
  .IP "\fB\-Wno\-pedantic\-ms\-format\fR (MinGW targets only)" 4
  .IX Item "-Wno-pedantic-ms-format (MinGW targets only)"
  When used in combination with \fB\-Wformat\fR
! and \fB\-pedantic\fR without GNU extensions, this option
! disables the warnings about non\-ISO \f(CW\*(C`printf\*(C'\fR / \f(CW\*(C`scanf\*(C'\fR format
  width specifiers \f(CW\*(C`I32\*(C'\fR, \f(CW\*(C`I64\*(C'\fR, and \f(CW\*(C`I\*(C'\fR used on Windows targets,
! which depend on the MS runtime.
! .IP \fB\-Wpointer\-arith\fR 4
  .IX Item "-Wpointer-arith"
! Warn about anything that depends on the "size of" a function type or
! of \f(CW\*(C`void\*(C'\fR.  GNU C assigns these types a size of 1, for
  convenience in calculations with \f(CW\*(C`void *\*(C'\fR pointers and pointers
! to functions.  In C++, warn also when an arithmetic operation involves
  \&\f(CW\*(C`NULL\*(C'\fR.  This warning is also enabled by \fB\-Wpedantic\fR.
! .IP \fB\-Wno\-pointer\-compare\fR 4
  .IX Item "-Wno-pointer-compare"
  Do not warn if a pointer is compared with a zero character constant.
  This usually
*************** means that the pointer was meant to be d
*** 8250,8259 ****
  \&          return 42;
  .Ve
  .Sp
! Note that the code above is invalid in \*(C+11.
  .Sp
  This warning is enabled by default.
! .IP "\fB\-Wtsan\fR" 4
  .IX Item "-Wtsan"
  Warn about unsupported features in ThreadSanitizer.
  .Sp
--- 8179,8188 ----
  \&          return 42;
  .Ve
  .Sp
! Note that the code above is invalid in C++11.
  .Sp
  This warning is enabled by default.
! .IP \fB\-Wtsan\fR 4
  .IX Item "-Wtsan"
  Warn about unsupported features in ThreadSanitizer.
  .Sp
*************** ThreadSanitizer does not support \f(CW\*
*** 8261,8293 ****
  can report false positives.
  .Sp
  This warning is enabled by default.
! .IP "\fB\-Wtype\-limits\fR" 4
  .IX Item "-Wtype-limits"
  Warn if a comparison is always true or always false due to the limited
  range of the data type, but do not warn for constant expressions.  For
  example, warn if an unsigned variable is compared against zero with
  \&\f(CW\*(C`<\*(C'\fR or \f(CW\*(C`>=\*(C'\fR.  This warning is also enabled by
  \&\fB\-Wextra\fR.
! .IP "\fB\-Wabsolute\-value\fR (C and Objective-C only)" 4
  .IX Item "-Wabsolute-value (C and Objective-C only)"
  Warn for calls to standard functions that compute the absolute value
  of an argument when a more appropriate standard function is available.
! For example, calling \f(CW\*(C`abs(3.14)\*(C'\fR triggers the warning because the
  appropriate function to call to compute the absolute value of a double
  argument is \f(CW\*(C`fabs\*(C'\fR.  The option also triggers warnings when the
  argument in a call to such a function has an unsigned type.  This
  warning can be suppressed with an explicit type cast and it is also
  enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wcomment\fR" 4
  .IX Item "-Wcomment"
  .PD 0
! .IP "\fB\-Wcomments\fR" 4
  .IX Item "-Wcomments"
  .PD
! Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
! comment, or whenever a backslash-newline appears in a \fB//\fR comment.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wtrigraphs\fR" 4
  .IX Item "-Wtrigraphs"
  Warn if any trigraphs are encountered that might change the meaning of
  the program.  Trigraphs within comments are not warned about,
--- 8190,8222 ----
  can report false positives.
  .Sp
  This warning is enabled by default.
! .IP \fB\-Wtype\-limits\fR 4
  .IX Item "-Wtype-limits"
  Warn if a comparison is always true or always false due to the limited
  range of the data type, but do not warn for constant expressions.  For
  example, warn if an unsigned variable is compared against zero with
  \&\f(CW\*(C`<\*(C'\fR or \f(CW\*(C`>=\*(C'\fR.  This warning is also enabled by
  \&\fB\-Wextra\fR.
! .IP "\fB\-Wabsolute\-value\fR (C and Objective\-C only)" 4
  .IX Item "-Wabsolute-value (C and Objective-C only)"
  Warn for calls to standard functions that compute the absolute value
  of an argument when a more appropriate standard function is available.
! For example, calling \f(CWabs(3.14)\fR triggers the warning because the
  appropriate function to call to compute the absolute value of a double
  argument is \f(CW\*(C`fabs\*(C'\fR.  The option also triggers warnings when the
  argument in a call to such a function has an unsigned type.  This
  warning can be suppressed with an explicit type cast and it is also
  enabled by \fB\-Wextra\fR.
! .IP \fB\-Wcomment\fR 4
  .IX Item "-Wcomment"
  .PD 0
! .IP \fB\-Wcomments\fR 4
  .IX Item "-Wcomments"
  .PD
! Warn whenever a comment\-start sequence \fB/*\fR appears in a \fB/*\fR
! comment, or whenever a backslash\-newline appears in a \fB//\fR comment.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wtrigraphs\fR 4
  .IX Item "-Wtrigraphs"
  Warn if any trigraphs are encountered that might change the meaning of
  the program.  Trigraphs within comments are not warned about,
*************** This option is implied by \fB\-Wall\fR.
*** 8297,8325 ****
  given, this option is still enabled unless trigraphs are enabled.  To
  get trigraph conversion without warnings, but get the other
  \&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
! .IP "\fB\-Wundef\fR" 4
  .IX Item "-Wundef"
  Warn if an undefined identifier is evaluated in an \f(CW\*(C`#if\*(C'\fR directive.
  Such identifiers are replaced with zero.
! .IP "\fB\-Wexpansion\-to\-defined\fR" 4
  .IX Item "-Wexpansion-to-defined"
  Warn whenever \fBdefined\fR is encountered in the expansion of a macro
  (including the case where the macro is expanded by an \fB#if\fR directive).
  Such usage is not portable.
  This warning is also enabled by \fB\-Wpedantic\fR and \fB\-Wextra\fR.
! .IP "\fB\-Wunused\-macros\fR" 4
  .IX Item "-Wunused-macros"
  Warn about macros defined in the main file that are unused.  A macro
  is \fIused\fR if it is expanded or tested for existence at least once.
  The preprocessor also warns if the macro has not been used at the
  time it is redefined or undefined.
  .Sp
! Built-in macros, macros defined on the command line, and macros
  defined in include files are not warned about.
  .Sp
  \&\fINote:\fR If a macro is actually used, but only used in skipped
  conditional blocks, then the preprocessor reports it as unused.  To avoid the
! warning in such a case, you might improve the scope of the macro's
  definition by, for example, moving it into the first skipped block.
  Alternatively, you could provide a dummy use with something like:
  .Sp
--- 8226,8254 ----
  given, this option is still enabled unless trigraphs are enabled.  To
  get trigraph conversion without warnings, but get the other
  \&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
! .IP \fB\-Wundef\fR 4
  .IX Item "-Wundef"
  Warn if an undefined identifier is evaluated in an \f(CW\*(C`#if\*(C'\fR directive.
  Such identifiers are replaced with zero.
! .IP \fB\-Wexpansion\-to\-defined\fR 4
  .IX Item "-Wexpansion-to-defined"
  Warn whenever \fBdefined\fR is encountered in the expansion of a macro
  (including the case where the macro is expanded by an \fB#if\fR directive).
  Such usage is not portable.
  This warning is also enabled by \fB\-Wpedantic\fR and \fB\-Wextra\fR.
! .IP \fB\-Wunused\-macros\fR 4
  .IX Item "-Wunused-macros"
  Warn about macros defined in the main file that are unused.  A macro
  is \fIused\fR if it is expanded or tested for existence at least once.
  The preprocessor also warns if the macro has not been used at the
  time it is redefined or undefined.
  .Sp
! Built\-in macros, macros defined on the command line, and macros
  defined in include files are not warned about.
  .Sp
  \&\fINote:\fR If a macro is actually used, but only used in skipped
  conditional blocks, then the preprocessor reports it as unused.  To avoid the
! warning in such a case, you might improve the scope of the macro\*(Aqs
  definition by, for example, moving it into the first skipped block.
  Alternatively, you could provide a dummy use with something like:
  .Sp
*************** Alternatively, you could provide a dummy
*** 8327,8333 ****
  \&        #if defined the_macro_causing_the_warning
  \&        #endif
  .Ve
! .IP "\fB\-Wno\-endif\-labels\fR" 4
  .IX Item "-Wno-endif-labels"
  Do not warn whenever an \f(CW\*(C`#else\*(C'\fR or an \f(CW\*(C`#endif\*(C'\fR are followed by text.
  This sometimes happens in older programs with code of the form
--- 8256,8262 ----
  \&        #if defined the_macro_causing_the_warning
  \&        #endif
  .Ve
! .IP \fB\-Wno\-endif\-labels\fR 4
  .IX Item "-Wno-endif-labels"
  Do not warn whenever an \f(CW\*(C`#else\*(C'\fR or an \f(CW\*(C`#endif\*(C'\fR are followed by text.
  This sometimes happens in older programs with code of the form
*************** This sometimes happens in older programs
*** 8342,8424 ****
  .Sp
  The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments.
  This warning is on by default.
! .IP "\fB\-Wbad\-function\-cast\fR (C and Objective-C only)" 4
  .IX Item "-Wbad-function-cast (C and Objective-C only)"
! Warn when a function call is cast to a non-matching type.
  For example, warn if a call to a function returning an integer type 
  is cast to a pointer type.
! .IP "\fB\-Wc90\-c99\-compat\fR (C and Objective-C only)" 4
  .IX Item "-Wc90-c99-compat (C and Objective-C only)"
! Warn about features not present in \s-1ISO C90,\s0 but present in \s-1ISO C99.\s0
  For instance, warn about use of variable length arrays, \f(CW\*(C`long long\*(C'\fR
  type, \f(CW\*(C`bool\*(C'\fR type, compound literals, designated initializers, and so
  on.  This option is independent of the standards mode.  Warnings are disabled
  in the expression that follows \f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc99\-c11\-compat\fR (C and Objective-C only)" 4
  .IX Item "-Wc99-c11-compat (C and Objective-C only)"
! Warn about features not present in \s-1ISO C99,\s0 but present in \s-1ISO C11.\s0
  For instance, warn about use of anonymous structures and unions,
! \&\f(CW\*(C`_Atomic\*(C'\fR type qualifier, \f(CW\*(C`_Thread_local\*(C'\fR storage-class specifier,
  \&\f(CW\*(C`_Alignas\*(C'\fR specifier, \f(CW\*(C`Alignof\*(C'\fR operator, \f(CW\*(C`_Generic\*(C'\fR keyword,
  and so on.  This option is independent of the standards mode.  Warnings are
  disabled in the expression that follows \f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc11\-c2x\-compat\fR (C and Objective-C only)" 4
  .IX Item "-Wc11-c2x-compat (C and Objective-C only)"
! Warn about features not present in \s-1ISO C11,\s0 but present in \s-1ISO C2X.\s0
  For instance, warn about omitting the string in \f(CW\*(C`_Static_assert\*(C'\fR,
  use of \fB[[]]\fR syntax for attributes, use of decimal
! floating-point types, and so on.  This option is independent of the
  standards mode.  Warnings are disabled in the expression that follows
  \&\f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc++\-compat\fR (C and Objective-C only)" 4
  .IX Item "-Wc++-compat (C and Objective-C only)"
! Warn about \s-1ISO C\s0 constructs that are outside of the common subset of
! \&\s-1ISO C\s0 and \s-1ISO \*(C+,\s0 e.g. request for implicit conversion from
  \&\f(CW\*(C`void *\*(C'\fR to a pointer to non\-\f(CW\*(C`void\*(C'\fR type.
! .IP "\fB\-Wc++11\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wc++11-compat ( and Objective- only)"
! Warn about \*(C+ constructs whose meaning differs between \s-1ISO \*(C+ 1998\s0
! and \s-1ISO \*(C+ 2011,\s0 e.g., identifiers in \s-1ISO \*(C+ 1998\s0 that are keywords
! in \s-1ISO \*(C+ 2011.\s0  This warning turns on \fB\-Wnarrowing\fR and is
  enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++14\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wc++14-compat ( and Objective- only)"
! Warn about \*(C+ constructs whose meaning differs between \s-1ISO \*(C+ 2011\s0
! and \s-1ISO \*(C+ 2014.\s0  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++17\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wc++17-compat ( and Objective- only)"
! Warn about \*(C+ constructs whose meaning differs between \s-1ISO \*(C+ 2014\s0
! and \s-1ISO \*(C+ 2017.\s0  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++20\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wc++20-compat ( and Objective- only)"
! Warn about \*(C+ constructs whose meaning differs between \s-1ISO \*(C+ 2017\s0
! and \s-1ISO \*(C+ 2020.\s0  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-c++11\-extensions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-c++11-extensions ( and Objective- only)"
! Do not warn about \*(C+11 constructs in code being compiled using
! an older \*(C+ standard.  Even without this option, some \*(C+11 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++14\-extensions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-c++14-extensions ( and Objective- only)"
! Do not warn about \*(C+14 constructs in code being compiled using
! an older \*(C+ standard.  Even without this option, some \*(C+14 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++17\-extensions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-c++17-extensions ( and Objective- only)"
! Do not warn about \*(C+17 constructs in code being compiled using
! an older \*(C+ standard.  Even without this option, some \*(C+17 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++20\-extensions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-c++20-extensions ( and Objective- only)"
! Do not warn about \*(C+20 constructs in code being compiled using
! an older \*(C+ standard.  Even without this option, some \*(C+20 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++23\-extensions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-c++23-extensions ( and Objective- only)"
! Do not warn about \*(C+23 constructs in code being compiled using
! an older \*(C+ standard.  Even without this option, some \*(C+23 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wcast\-qual\fR" 4
  .IX Item "-Wcast-qual"
  Warn whenever a pointer is cast so as to remove a type qualifier from
  the target type.  For example, warn if a \f(CW\*(C`const char *\*(C'\fR is cast
--- 8271,8353 ----
  .Sp
  The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments.
  This warning is on by default.
! .IP "\fB\-Wbad\-function\-cast\fR (C and Objective\-C only)" 4
  .IX Item "-Wbad-function-cast (C and Objective-C only)"
! Warn when a function call is cast to a non\-matching type.
  For example, warn if a call to a function returning an integer type 
  is cast to a pointer type.
! .IP "\fB\-Wc90\-c99\-compat\fR (C and Objective\-C only)" 4
  .IX Item "-Wc90-c99-compat (C and Objective-C only)"
! Warn about features not present in ISO C90, but present in ISO C99.
  For instance, warn about use of variable length arrays, \f(CW\*(C`long long\*(C'\fR
  type, \f(CW\*(C`bool\*(C'\fR type, compound literals, designated initializers, and so
  on.  This option is independent of the standards mode.  Warnings are disabled
  in the expression that follows \f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc99\-c11\-compat\fR (C and Objective\-C only)" 4
  .IX Item "-Wc99-c11-compat (C and Objective-C only)"
! Warn about features not present in ISO C99, but present in ISO C11.
  For instance, warn about use of anonymous structures and unions,
! \&\f(CW\*(C`_Atomic\*(C'\fR type qualifier, \f(CW\*(C`_Thread_local\*(C'\fR storage\-class specifier,
  \&\f(CW\*(C`_Alignas\*(C'\fR specifier, \f(CW\*(C`Alignof\*(C'\fR operator, \f(CW\*(C`_Generic\*(C'\fR keyword,
  and so on.  This option is independent of the standards mode.  Warnings are
  disabled in the expression that follows \f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc11\-c2x\-compat\fR (C and Objective\-C only)" 4
  .IX Item "-Wc11-c2x-compat (C and Objective-C only)"
! Warn about features not present in ISO C11, but present in ISO C2X.
  For instance, warn about omitting the string in \f(CW\*(C`_Static_assert\*(C'\fR,
  use of \fB[[]]\fR syntax for attributes, use of decimal
! floating\-point types, and so on.  This option is independent of the
  standards mode.  Warnings are disabled in the expression that follows
  \&\f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc++\-compat\fR (C and Objective\-C only)" 4
  .IX Item "-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
  \&\f(CW\*(C`void *\*(C'\fR to a pointer to non\-\f(CW\*(C`void\*(C'\fR type.
! .IP "\fB\-Wc++11\-compat\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wc++11-compat (C++ and Objective-C++ only)"
! Warn about C++ constructs whose meaning differs between ISO C++ 1998
! and ISO C++ 2011, e.g., identifiers in ISO C++ 1998 that are keywords
! in ISO C++ 2011.  This warning turns on \fB\-Wnarrowing\fR and is
  enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++14\-compat\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wc++14-compat (C++ and Objective-C++ only)"
! Warn about C++ constructs whose meaning differs between ISO C++ 2011
! and ISO C++ 2014.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++17\-compat\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wc++17-compat (C++ and Objective-C++ only)"
! Warn about C++ constructs whose meaning differs between ISO C++ 2014
! and ISO C++ 2017.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++20\-compat\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wc++20-compat (C++ and Objective-C++ only)"
! Warn about C++ constructs whose meaning differs between ISO C++ 2017
! and ISO C++ 2020.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-c++11\-extensions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-c++11-extensions (C++ and Objective-C++ only)"
! Do not warn about C++11 constructs in code being compiled using
! an older C++ standard.  Even without this option, some C++11 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++14\-extensions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-c++14-extensions (C++ and Objective-C++ only)"
! Do not warn about C++14 constructs in code being compiled using
! an older C++ standard.  Even without this option, some C++14 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++17\-extensions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-c++17-extensions (C++ and Objective-C++ only)"
! Do not warn about C++17 constructs in code being compiled using
! an older C++ standard.  Even without this option, some C++17 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++20\-extensions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-c++20-extensions (C++ and Objective-C++ only)"
! Do not warn about C++20 constructs in code being compiled using
! an older C++ standard.  Even without this option, some C++20 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++23\-extensions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-c++23-extensions (C++ and Objective-C++ only)"
! Do not warn about C++23 constructs in code being compiled using
! an older C++ standard.  Even without this option, some C++23 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP \fB\-Wcast\-qual\fR 4
  .IX Item "-Wcast-qual"
  Warn whenever a pointer is cast so as to remove a type qualifier from
  the target type.  For example, warn if a \f(CW\*(C`const char *\*(C'\fR is cast
*************** is unsafe, as in this example:
*** 8436,8469 ****
  \&          /* Now char** pointer points to read\-only memory.  */
  \&          **p = \*(Aqb\*(Aq;
  .Ve
! .IP "\fB\-Wcast\-align\fR" 4
  .IX Item "-Wcast-align"
  Warn whenever a pointer is cast such that the required alignment of the
  target is increased.  For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
  an \f(CW\*(C`int *\*(C'\fR on machines where integers can only be accessed at
! two\- or four-byte boundaries.
! .IP "\fB\-Wcast\-align=strict\fR" 4
  .IX Item "-Wcast-align=strict"
  Warn whenever a pointer is cast such that the required alignment of the
  target is increased.  For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
  an \f(CW\*(C`int *\*(C'\fR regardless of the target machine.
! .IP "\fB\-Wcast\-function\-type\fR" 4
  .IX Item "-Wcast-function-type"
  Warn when a function pointer is cast to an incompatible function pointer.
  In a cast involving function types with a variable argument list only
  the types of initial arguments that are provided are considered.
! Any parameter of pointer-type matches any other pointer-type.  Any benign
  differences in integral types are ignored, like \f(CW\*(C`int\*(C'\fR vs. \f(CW\*(C`long\*(C'\fR
! on \s-1ILP32\s0 targets.  Likewise type qualifiers are ignored.  The function
  type \f(CW\*(C`void (*) (void)\*(C'\fR is special and matches everything, which can
  be used to suppress this warning.
  In a cast involving pointer to member types this warning warns whenever
  the type cast is changing the pointer to member type.
  This warning is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wwrite\-strings\fR" 4
  .IX Item "-Wwrite-strings"
  When compiling C, give string constants the type \f(CW\*(C`const
! char[\f(CIlength\f(CW]\*(C'\fR so that copying the address of one into a
  non\-\f(CW\*(C`const\*(C'\fR \f(CW\*(C`char *\*(C'\fR pointer produces a warning.  These
  warnings help you find at compile time code that can try to write
  into a string constant, but only if you have been very careful about
--- 8365,8398 ----
  \&          /* Now char** pointer points to read\-only memory.  */
  \&          **p = \*(Aqb\*(Aq;
  .Ve
! .IP \fB\-Wcast\-align\fR 4
  .IX Item "-Wcast-align"
  Warn whenever a pointer is cast such that the required alignment of the
  target is increased.  For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
  an \f(CW\*(C`int *\*(C'\fR on machines where integers can only be accessed at
! two\- or four\-byte boundaries.
! .IP \fB\-Wcast\-align=strict\fR 4
  .IX Item "-Wcast-align=strict"
  Warn whenever a pointer is cast such that the required alignment of the
  target is increased.  For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
  an \f(CW\*(C`int *\*(C'\fR regardless of the target machine.
! .IP \fB\-Wcast\-function\-type\fR 4
  .IX Item "-Wcast-function-type"
  Warn when a function pointer is cast to an incompatible function pointer.
  In a cast involving function types with a variable argument list only
  the types of initial arguments that are provided are considered.
! Any parameter of pointer\-type matches any other pointer\-type.  Any benign
  differences in integral types are ignored, like \f(CW\*(C`int\*(C'\fR vs. \f(CW\*(C`long\*(C'\fR
! on ILP32 targets.  Likewise type qualifiers are ignored.  The function
  type \f(CW\*(C`void (*) (void)\*(C'\fR is special and matches everything, which can
  be used to suppress this warning.
  In a cast involving pointer to member types this warning warns whenever
  the type cast is changing the pointer to member type.
  This warning is enabled by \fB\-Wextra\fR.
! .IP \fB\-Wwrite\-strings\fR 4
  .IX Item "-Wwrite-strings"
  When compiling C, give string constants the type \f(CW\*(C`const
! char[\fR\f(CIlength\fR\f(CW]\*(C'\fR so that copying the address of one into a
  non\-\f(CW\*(C`const\*(C'\fR \f(CW\*(C`char *\*(C'\fR pointer produces a warning.  These
  warnings help you find at compile time code that can try to write
  into a string constant, but only if you have been very careful about
*************** using \f(CW\*(C`const\*(C'\fR in declara
*** 8471,8486 ****
  just a nuisance. This is why we did not make \fB\-Wall\fR request
  these warnings.
  .Sp
! When compiling \*(C+, warn about the deprecated conversion from string
! literals to \f(CW\*(C`char *\*(C'\fR.  This warning is enabled by default for \*(C+
  programs.
! .IP "\fB\-Wclobbered\fR" 4
  .IX Item "-Wclobbered"
  Warn for variables that might be changed by \f(CW\*(C`longjmp\*(C'\fR or
  \&\f(CW\*(C`vfork\*(C'\fR.  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wno\-complain\-wrong\-lang\fR" 4
  .IX Item "-Wno-complain-wrong-lang"
! By default, language front ends complain when a command-line option is
  valid, but not applicable to that front end.
  This may be disabled with \fB\-Wno\-complain\-wrong\-lang\fR,
  which is mostly useful when invoking a single compiler driver for
--- 8400,8415 ----
  just a nuisance. This is why we did not make \fB\-Wall\fR request
  these warnings.
  .Sp
! When compiling C++, warn about the deprecated conversion from string
! literals to \f(CW\*(C`char *\*(C'\fR.  This warning is enabled by default for C++
  programs.
! .IP \fB\-Wclobbered\fR 4
  .IX Item "-Wclobbered"
  Warn for variables that might be changed by \f(CW\*(C`longjmp\*(C'\fR or
  \&\f(CW\*(C`vfork\*(C'\fR.  This warning is also enabled by \fB\-Wextra\fR.
! .IP \fB\-Wno\-complain\-wrong\-lang\fR 4
  .IX Item "-Wno-complain-wrong-lang"
! By default, language front ends complain when a command\-line option is
  valid, but not applicable to that front end.
  This may be disabled with \fB\-Wno\-complain\-wrong\-lang\fR,
  which is mostly useful when invoking a single compiler driver for
*************** multiple source files written in differe
*** 8490,8501 ****
  \&        $ g++ \-fno\-rtti a.cc b.f90
  .Ve
  .Sp
! The driver \fIg++\fR invokes the \*(C+ front end to compile \fIa.cc\fR
  and the Fortran front end to compile \fIb.f90\fR.
  The latter front end diagnoses
! \&\fBf951: Warning: command-line option '\-fno\-rtti' is valid for \*(C+/D/ObjC++ but not for Fortran\fR,
  which may be disabled with \fB\-Wno\-complain\-wrong\-lang\fR.
! .IP "\fB\-Wconversion\fR" 4
  .IX Item "-Wconversion"
  Warn for implicit conversions that may alter a value. This includes
  conversions between real and integer, like \f(CW\*(C`abs (x)\*(C'\fR when
--- 8419,8430 ----
  \&        $ g++ \-fno\-rtti a.cc b.f90
  .Ve
  .Sp
! The driver \fIg++\fR invokes the C++ front end to compile \fIa.cc\fR
  and the Fortran front end to compile \fIb.f90\fR.
  The latter front end diagnoses
! \&\fBf951: Warning: command\-line option \*(Aq\-fno\-rtti\*(Aq is valid for C++/D/ObjC++ but not for Fortran\fR,
  which may be disabled with \fB\-Wno\-complain\-wrong\-lang\fR.
! .IP \fB\-Wconversion\fR 4
  .IX Item "-Wconversion"
  Warn for implicit conversions that may alter a value. This includes
  conversions between real and integer, like \f(CW\*(C`abs (x)\*(C'\fR when
*************** changed by the conversion like in \f(CW\
*** 8507,8522 ****
  conversions between signed and unsigned integers can be disabled by
  using \fB\-Wno\-sign\-conversion\fR.
  .Sp
! For \*(C+, also warn for confusing overload resolution for user-defined
  conversions; and conversions that never use a type conversion
  operator: conversions to \f(CW\*(C`void\*(C'\fR, the same type, a base class or a
  reference to them. Warnings about conversions between signed and
! unsigned integers are disabled by default in \*(C+ unless
  \&\fB\-Wsign\-conversion\fR is explicitly enabled.
  .Sp
  Warnings about conversion from arithmetic on a small type back to that
  type are only given with \fB\-Warith\-conversion\fR.
! .IP "\fB\-Wdangling\-else\fR" 4
  .IX Item "-Wdangling-else"
  Warn about constructions where there may be confusion to which
  \&\f(CW\*(C`if\*(C'\fR statement an \f(CW\*(C`else\*(C'\fR branch belongs.  Here is an example of
--- 8436,8451 ----
  conversions between signed and unsigned integers can be disabled by
  using \fB\-Wno\-sign\-conversion\fR.
  .Sp
! For C++, also warn for confusing overload resolution for user\-defined
  conversions; and conversions that never use a type conversion
  operator: conversions to \f(CW\*(C`void\*(C'\fR, the same type, a base class or a
  reference to them. Warnings about conversions between signed and
! unsigned integers are disabled by default in C++ unless
  \&\fB\-Wsign\-conversion\fR is explicitly enabled.
  .Sp
  Warnings about conversion from arithmetic on a small type back to that
  type are only given with \fB\-Warith\-conversion\fR.
! .IP \fB\-Wdangling\-else\fR 4
  .IX Item "-Wdangling-else"
  Warn about constructions where there may be confusion to which
  \&\f(CW\*(C`if\*(C'\fR statement an \f(CW\*(C`else\*(C'\fR branch belongs.  Here is an example of
*************** such a case:
*** 8532,8542 ****
  \&        }
  .Ve
  .Sp
! In C/\*(C+, every \f(CW\*(C`else\*(C'\fR branch belongs to the innermost possible
  \&\f(CW\*(C`if\*(C'\fR statement, which in this example is \f(CW\*(C`if (b)\*(C'\fR.  This is
  often not what the programmer expected, as illustrated in the above
  example by indentation the programmer chose.  When there is the
! potential for this confusion, \s-1GCC\s0 issues a warning when this flag
  is specified.  To eliminate the warning, add explicit braces around
  the innermost \f(CW\*(C`if\*(C'\fR statement so there is no way the \f(CW\*(C`else\*(C'\fR
  can belong to the enclosing \f(CW\*(C`if\*(C'\fR.  The resulting code
--- 8461,8471 ----
  \&        }
  .Ve
  .Sp
! In C/C++, every \f(CW\*(C`else\*(C'\fR branch belongs to the innermost possible
  \&\f(CW\*(C`if\*(C'\fR statement, which in this example is \f(CW\*(C`if (b)\*(C'\fR.  This is
  often not what the programmer expected, as illustrated in the above
  example by indentation the programmer chose.  When there is the
! potential for this confusion, GCC issues a warning when this flag
  is specified.  To eliminate the warning, add explicit braces around
  the innermost \f(CW\*(C`if\*(C'\fR statement so there is no way the \f(CW\*(C`else\*(C'\fR
  can belong to the enclosing \f(CW\*(C`if\*(C'\fR.  The resulting code
*************** looks like this:
*** 8555,8574 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wparentheses\fR.
! .IP "\fB\-Wdangling\-pointer\fR" 4
  .IX Item "-Wdangling-pointer"
  .PD 0
! .IP "\fB\-Wdangling\-pointer=\fR\fIn\fR" 4
  .IX Item "-Wdangling-pointer=n"
  .PD
! Warn about uses of pointers (or \*(C+ references) to objects with automatic
  storage duration after their lifetime has ended.  This includes local
  variables declared in nested blocks, compound literals and other unnamed
  temporary objects.  In addition, warn about storing the address of such
  objects in escaped pointers.  The warning is enabled at all optimization
  levels but may yield different results with optimization than without.
  .RS 4
! .IP "\fB\-Wdangling\-pointer=1\fR" 4
  .IX Item "-Wdangling-pointer=1"
  At level 1 the warning diagnoses only unconditional uses of dangling pointers.
  For example
--- 8484,8503 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wparentheses\fR.
! .IP \fB\-Wdangling\-pointer\fR 4
  .IX Item "-Wdangling-pointer"
  .PD 0
! .IP \fB\-Wdangling\-pointer=\fR\fIn\fR 4
  .IX Item "-Wdangling-pointer=n"
  .PD
! Warn about uses of pointers (or C++ references) to objects with automatic
  storage duration after their lifetime has ended.  This includes local
  variables declared in nested blocks, compound literals and other unnamed
  temporary objects.  In addition, warn about storing the address of such
  objects in escaped pointers.  The warning is enabled at all optimization
  levels but may yield different results with optimization than without.
  .RS 4
! .IP \fB\-Wdangling\-pointer=1\fR 4
  .IX Item "-Wdangling-pointer=1"
  At level 1 the warning diagnoses only unconditional uses of dangling pointers.
  For example
*************** In the following function the store of t
*** 8593,8599 ****
  \&          *p = &x;
  \&        }
  .Ve
! .IP "\fB\-Wdangling\-pointer=2\fR" 4
  .IX Item "-Wdangling-pointer=2"
  At level 2, in addition to unconditional uses the warning also diagnoses
  conditional uses of dangling pointers.
--- 8522,8528 ----
  \&          *p = &x;
  \&        }
  .Ve
! .IP \fB\-Wdangling\-pointer=2\fR 4
  .IX Item "-Wdangling-pointer=2"
  At level 2, in addition to unconditional uses the warning also diagnoses
  conditional uses of dangling pointers.
*************** triggers at this level.
*** 8620,8649 ****
  .Sp
  \&\fB\-Wdangling\-pointer=2\fR is included in \fB\-Wall\fR.
  .RE
! .IP "\fB\-Wdate\-time\fR" 4
  .IX Item "-Wdate-time"
  Warn when macros \f(CW\*(C`_\|_TIME_\|_\*(C'\fR, \f(CW\*(C`_\|_DATE_\|_\*(C'\fR or \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR
! are encountered as they might prevent bit-wise-identical reproducible
  compilations.
! .IP "\fB\-Wempty\-body\fR" 4
  .IX Item "-Wempty-body"
  Warn if an empty body occurs in an \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR or \f(CW\*(C`do
  while\*(C'\fR statement.  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wno\-endif\-labels\fR" 4
  .IX Item "-Wno-endif-labels"
  Do not warn about stray tokens after \f(CW\*(C`#else\*(C'\fR and \f(CW\*(C`#endif\*(C'\fR.
! .IP "\fB\-Wenum\-compare\fR" 4
  .IX Item "-Wenum-compare"
  Warn about a comparison between values of different enumerated types.
! In \*(C+ enumerated type mismatches in conditional expressions are also
  diagnosed and the warning is enabled by default.  In C this warning is 
  enabled by \fB\-Wall\fR.
! .IP "\fB\-Wenum\-conversion\fR" 4
  .IX Item "-Wenum-conversion"
  Warn when a value of enumerated type is implicitly converted to a 
  different enumerated type.  This warning is enabled by \fB\-Wextra\fR
  in C.
! .IP "\fB\-Wenum\-int\-mismatch\fR (C and Objective-C only)" 4
  .IX Item "-Wenum-int-mismatch (C and Objective-C only)"
  Warn about mismatches between an enumerated type and an integer type in
  declarations.  For example:
--- 8549,8578 ----
  .Sp
  \&\fB\-Wdangling\-pointer=2\fR is included in \fB\-Wall\fR.
  .RE
! .IP \fB\-Wdate\-time\fR 4
  .IX Item "-Wdate-time"
  Warn when macros \f(CW\*(C`_\|_TIME_\|_\*(C'\fR, \f(CW\*(C`_\|_DATE_\|_\*(C'\fR or \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR
! are encountered as they might prevent bit\-wise\-identical reproducible
  compilations.
! .IP \fB\-Wempty\-body\fR 4
  .IX Item "-Wempty-body"
  Warn if an empty body occurs in an \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR or \f(CW\*(C`do
  while\*(C'\fR statement.  This warning is also enabled by \fB\-Wextra\fR.
! .IP \fB\-Wno\-endif\-labels\fR 4
  .IX Item "-Wno-endif-labels"
  Do not warn about stray tokens after \f(CW\*(C`#else\*(C'\fR and \f(CW\*(C`#endif\*(C'\fR.
! .IP \fB\-Wenum\-compare\fR 4
  .IX Item "-Wenum-compare"
  Warn about a comparison between values of different enumerated types.
! In C++ enumerated type mismatches in conditional expressions are also
  diagnosed and the warning is enabled by default.  In C this warning is 
  enabled by \fB\-Wall\fR.
! .IP \fB\-Wenum\-conversion\fR 4
  .IX Item "-Wenum-conversion"
  Warn when a value of enumerated type is implicitly converted to a 
  different enumerated type.  This warning is enabled by \fB\-Wextra\fR
  in C.
! .IP "\fB\-Wenum\-int\-mismatch\fR (C and Objective\-C only)" 4
  .IX Item "-Wenum-int-mismatch (C and Objective-C only)"
  Warn about mismatches between an enumerated type and an integer type in
  declarations.  For example:
*************** declarations.  For example:
*** 8656,8698 ****
  .Sp
  In C, an enumerated type is compatible with \f(CW\*(C`char\*(C'\fR, a signed
  integer type, or an unsigned integer type.  However, since the choice
! of the underlying type of an enumerated type is implementation-defined,
! such mismatches may cause portability issues.  In \*(C+, such mismatches
  are an error.  In C, this warning is enabled by \fB\-Wall\fR and
  \&\fB\-Wc++\-compat\fR.
! .IP "\fB\-Wjump\-misses\-init\fR (C, Objective-C only)" 4
  .IX Item "-Wjump-misses-init (C, Objective-C only)"
  Warn if a \f(CW\*(C`goto\*(C'\fR statement or a \f(CW\*(C`switch\*(C'\fR statement jumps
  forward across the initialization of a variable, or jumps backward to a
  label after the variable has been initialized.  This only warns about
  variables that are initialized when they are declared.  This warning is
! only supported for C and Objective-C; in \*(C+ this sort of branch is an
  error in any case.
  .Sp
  \&\fB\-Wjump\-misses\-init\fR is included in \fB\-Wc++\-compat\fR.  It
  can be disabled with the \fB\-Wno\-jump\-misses\-init\fR option.
! .IP "\fB\-Wsign\-compare\fR" 4
  .IX Item "-Wsign-compare"
  Warn when a comparison between signed and unsigned values could produce
  an incorrect result when the signed value is converted to unsigned.
! In \*(C+, this warning is also enabled by \fB\-Wall\fR.  In C, it is
  also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wsign\-conversion\fR" 4
  .IX Item "-Wsign-conversion"
  Warn for implicit conversions that may change the sign of an integer
  value, like assigning a signed integer expression to an unsigned
  integer variable. An explicit cast silences the warning. In C, this
  option is enabled also by \fB\-Wconversion\fR.
! .IP "\fB\-Wfloat\-conversion\fR" 4
  .IX Item "-Wfloat-conversion"
  Warn for implicit conversions that reduce the precision of a real value.
  This includes conversions from real to integer, and from higher precision
  real to lower precision real values.  This option is also enabled by
  \&\fB\-Wconversion\fR.
! .IP "\fB\-Wno\-scalar\-storage\-order\fR" 4
  .IX Item "-Wno-scalar-storage-order"
  Do not warn on suspicious constructs involving reverse scalar storage order.
! .IP "\fB\-Wsizeof\-array\-div\fR" 4
  .IX Item "-Wsizeof-array-div"
  Warn about divisions of two sizeof operators when the first one is applied
  to an array and the divisor does not equal the size of the array element.
--- 8585,8627 ----
  .Sp
  In C, an enumerated type is compatible with \f(CW\*(C`char\*(C'\fR, a signed
  integer type, or an unsigned integer type.  However, since the choice
! of the underlying type of an enumerated type is implementation\-defined,
! such mismatches may cause portability issues.  In C++, such mismatches
  are an error.  In C, this warning is enabled by \fB\-Wall\fR and
  \&\fB\-Wc++\-compat\fR.
! .IP "\fB\-Wjump\-misses\-init\fR (C, Objective\-C only)" 4
  .IX Item "-Wjump-misses-init (C, Objective-C only)"
  Warn if a \f(CW\*(C`goto\*(C'\fR statement or a \f(CW\*(C`switch\*(C'\fR statement jumps
  forward across the initialization of a variable, or jumps backward to a
  label after the variable has been initialized.  This only warns about
  variables that are initialized when they are declared.  This warning is
! only supported for C and Objective\-C; in C++ this sort of branch is an
  error in any case.
  .Sp
  \&\fB\-Wjump\-misses\-init\fR is included in \fB\-Wc++\-compat\fR.  It
  can be disabled with the \fB\-Wno\-jump\-misses\-init\fR option.
! .IP \fB\-Wsign\-compare\fR 4
  .IX Item "-Wsign-compare"
  Warn when a comparison between signed and unsigned values could produce
  an incorrect result when the signed value is converted to unsigned.
! In C++, this warning is also enabled by \fB\-Wall\fR.  In C, it is
  also enabled by \fB\-Wextra\fR.
! .IP \fB\-Wsign\-conversion\fR 4
  .IX Item "-Wsign-conversion"
  Warn for implicit conversions that may change the sign of an integer
  value, like assigning a signed integer expression to an unsigned
  integer variable. An explicit cast silences the warning. In C, this
  option is enabled also by \fB\-Wconversion\fR.
! .IP \fB\-Wfloat\-conversion\fR 4
  .IX Item "-Wfloat-conversion"
  Warn for implicit conversions that reduce the precision of a real value.
  This includes conversions from real to integer, and from higher precision
  real to lower precision real values.  This option is also enabled by
  \&\fB\-Wconversion\fR.
! .IP \fB\-Wno\-scalar\-storage\-order\fR 4
  .IX Item "-Wno-scalar-storage-order"
  Do not warn on suspicious constructs involving reverse scalar storage order.
! .IP \fB\-Wsizeof\-array\-div\fR 4
  .IX Item "-Wsizeof-array-div"
  Warn about divisions of two sizeof operators when the first one is applied
  to an array and the divisor does not equal the size of the array element.
*************** array, which is likely what the user int
*** 8708,8723 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wsizeof\-pointer\-div\fR" 4
  .IX Item "-Wsizeof-pointer-div"
  Warn for suspicious divisions of two sizeof expressions that divide
  the pointer size by the element size, which is the usual way to compute
! the array size but won't work out correctly with pointers.  This warning
  warns e.g. about \f(CW\*(C`sizeof (ptr) / sizeof (ptr[0])\*(C'\fR if \f(CW\*(C`ptr\*(C'\fR is
  not an array, but a pointer.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wsizeof\-pointer\-memaccess\fR" 4
  .IX Item "-Wsizeof-pointer-memaccess"
! Warn for suspicious length parameters to certain string and memory built-in
  functions if the argument uses \f(CW\*(C`sizeof\*(C'\fR.  This warning triggers for
  example for \f(CW\*(C`memset (ptr, 0, sizeof (ptr));\*(C'\fR if \f(CW\*(C`ptr\*(C'\fR is not
  an array, but a pointer, and suggests a possible fix, or about
--- 8637,8652 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wsizeof\-pointer\-div\fR 4
  .IX Item "-Wsizeof-pointer-div"
  Warn for suspicious divisions of two sizeof expressions that divide
  the pointer size by the element size, which is the usual way to compute
! the array size but won\*(Aqt work out correctly with pointers.  This warning
  warns e.g. about \f(CW\*(C`sizeof (ptr) / sizeof (ptr[0])\*(C'\fR if \f(CW\*(C`ptr\*(C'\fR is
  not an array, but a pointer.  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wsizeof\-pointer\-memaccess\fR 4
  .IX Item "-Wsizeof-pointer-memaccess"
! Warn for suspicious length parameters to certain string and memory built\-in
  functions if the argument uses \f(CW\*(C`sizeof\*(C'\fR.  This warning triggers for
  example for \f(CW\*(C`memset (ptr, 0, sizeof (ptr));\*(C'\fR if \f(CW\*(C`ptr\*(C'\fR is not
  an array, but a pointer, and suggests a possible fix, or about
*************** is almost certainly a mistake and so the
*** 8739,8759 ****
  .Ve
  .Sp
  The \fB\-Wsizeof\-pointer\-memaccess\fR option is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-sizeof\-array\-argument\fR" 4
  .IX Item "-Wno-sizeof-array-argument"
  Do not warn when the \f(CW\*(C`sizeof\*(C'\fR operator is applied to a parameter that is
  declared as an array in a function definition.  This warning is enabled by
! default for C and \*(C+ programs.
! .IP "\fB\-Wmemset\-elt\-size\fR" 4
  .IX Item "-Wmemset-elt-size"
! Warn for suspicious calls to the \f(CW\*(C`memset\*(C'\fR built-in function, if the
  first argument references an array, and the third argument is a number
  equal to the number of elements, but not equal to the size of the array
  in memory.  This indicates that the user has omitted a multiplication by
  the element size.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wmemset\-transposed\-args\fR" 4
  .IX Item "-Wmemset-transposed-args"
! Warn for suspicious calls to the \f(CW\*(C`memset\*(C'\fR built-in function where
  the second argument is not zero and the third argument is zero.  For
  example, the call \f(CW\*(C`memset (buf, sizeof buf, 0)\*(C'\fR is diagnosed because
  \&\f(CW\*(C`memset (buf, 0, sizeof buf)\*(C'\fR was meant instead.  The diagnostic
--- 8668,8688 ----
  .Ve
  .Sp
  The \fB\-Wsizeof\-pointer\-memaccess\fR option is enabled by \fB\-Wall\fR.
! .IP \fB\-Wno\-sizeof\-array\-argument\fR 4
  .IX Item "-Wno-sizeof-array-argument"
  Do not warn when the \f(CW\*(C`sizeof\*(C'\fR operator is applied to a parameter that is
  declared as an array in a function definition.  This warning is enabled by
! default for C and C++ programs.
! .IP \fB\-Wmemset\-elt\-size\fR 4
  .IX Item "-Wmemset-elt-size"
! Warn for suspicious calls to the \f(CW\*(C`memset\*(C'\fR built\-in function, if the
  first argument references an array, and the third argument is a number
  equal to the number of elements, but not equal to the size of the array
  in memory.  This indicates that the user has omitted a multiplication by
  the element size.  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wmemset\-transposed\-args\fR 4
  .IX Item "-Wmemset-transposed-args"
! Warn for suspicious calls to the \f(CW\*(C`memset\*(C'\fR built\-in function where
  the second argument is not zero and the third argument is zero.  For
  example, the call \f(CW\*(C`memset (buf, sizeof buf, 0)\*(C'\fR is diagnosed because
  \&\f(CW\*(C`memset (buf, 0, sizeof buf)\*(C'\fR was meant instead.  The diagnostic
*************** it is an expression that is folded to ze
*** 8762,8768 ****
  type, it is far less likely that the arguments have been mistakenly
  transposed and no warning is emitted.  This warning is enabled
  by \fB\-Wall\fR.
! .IP "\fB\-Waddress\fR" 4
  .IX Item "-Waddress"
  Warn about suspicious uses of address expressions. These include comparing
  the address of a function or a declared object to the null pointer constant
--- 8691,8697 ----
  type, it is far less likely that the arguments have been mistakenly
  transposed and no warning is emitted.  This warning is enabled
  by \fB\-Wall\fR.
! .IP \fB\-Waddress\fR 4
  .IX Item "-Waddress"
  Warn about suspicious uses of address expressions. These include comparing
  the address of a function or a declared object to the null pointer constant
*************** and are not portable, and suggest the in
*** 8809,8831 ****
  The warning is suppressed if the suspicious expression is the result
  of macro expansion.
  \&\fB\-Waddress\fR warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-address\-of\-packed\-member\fR" 4
  .IX Item "-Wno-address-of-packed-member"
  Do not warn when the address of packed member of struct or union is taken,
  which usually results in an unaligned pointer value.  This is
  enabled by default.
! .IP "\fB\-Wlogical\-op\fR" 4
  .IX Item "-Wlogical-op"
  Warn about suspicious uses of logical operators in expressions.
  This includes using logical operators in contexts where a
! bit-wise operator is likely to be expected.  Also warns when
  the operands of a logical operator are the same:
  .Sp
  .Vb 2
  \&        extern int a;
  \&        if (a < 0 && a < 0) { ... }
  .Ve
! .IP "\fB\-Wlogical\-not\-parentheses\fR" 4
  .IX Item "-Wlogical-not-parentheses"
  Warn about logical not used on the left hand side operand of a comparison.
  This option does not warn if the right operand is considered to be a boolean
--- 8738,8760 ----
  The warning is suppressed if the suspicious expression is the result
  of macro expansion.
  \&\fB\-Waddress\fR warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wno\-address\-of\-packed\-member\fR 4
  .IX Item "-Wno-address-of-packed-member"
  Do not warn when the address of packed member of struct or union is taken,
  which usually results in an unaligned pointer value.  This is
  enabled by default.
! .IP \fB\-Wlogical\-op\fR 4
  .IX Item "-Wlogical-op"
  Warn about suspicious uses of logical operators in expressions.
  This includes using logical operators in contexts where a
! bit\-wise operator is likely to be expected.  Also warns when
  the operands of a logical operator are the same:
  .Sp
  .Vb 2
  \&        extern int a;
  \&        if (a < 0 && a < 0) { ... }
  .Ve
! .IP \fB\-Wlogical\-not\-parentheses\fR 4
  .IX Item "-Wlogical-not-parentheses"
  Warn about logical not used on the left hand side operand of a comparison.
  This option does not warn if the right operand is considered to be a boolean
*************** expression.  Its purpose is to detect su
*** 8837,8843 ****
  \&        if (!a > 1) { ... }
  .Ve
  .Sp
! It is possible to suppress the warning by wrapping the \s-1LHS\s0 into
  parentheses:
  .Sp
  .Vb 1
--- 8766,8772 ----
  \&        if (!a > 1) { ... }
  .Ve
  .Sp
! It is possible to suppress the warning by wrapping the LHS into
  parentheses:
  .Sp
  .Vb 1
*************** parentheses:
*** 8845,8860 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Waggregate\-return\fR" 4
  .IX Item "-Waggregate-return"
  Warn if any functions that return structures or unions are defined or
  called.  (In languages where you can return an array, this also elicits
  a warning.)
! .IP "\fB\-Wno\-aggressive\-loop\-optimizations\fR" 4
  .IX Item "-Wno-aggressive-loop-optimizations"
  Warn if in a loop with constant number of iterations the compiler detects
  undefined behavior in some statement during one or more of the iterations.
! .IP "\fB\-Wno\-attributes\fR" 4
  .IX Item "-Wno-attributes"
  Do not warn if an unexpected \f(CW\*(C`_\|_attribute_\|_\*(C'\fR is used, such as
  unrecognized attributes, function attributes applied to variables,
--- 8774,8789 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Waggregate\-return\fR 4
  .IX Item "-Waggregate-return"
  Warn if any functions that return structures or unions are defined or
  called.  (In languages where you can return an array, this also elicits
  a warning.)
! .IP \fB\-Wno\-aggressive\-loop\-optimizations\fR 4
  .IX Item "-Wno-aggressive-loop-optimizations"
  Warn if in a loop with constant number of iterations the compiler detects
  undefined behavior in some statement during one or more of the iterations.
! .IP \fB\-Wno\-attributes\fR 4
  .IX Item "-Wno-attributes"
  Do not warn if an unexpected \f(CW\*(C`_\|_attribute_\|_\*(C'\fR is used, such as
  unrecognized attributes, function attributes applied to variables,
*************** etc.  This does not stop errors for inco
*** 8862,8868 ****
  attributes.
  .Sp
  Additionally, using \fB\-Wno\-attributes=\fR, it is possible to suppress
! warnings about unknown scoped attributes (in \*(C+11 and C2X).  For example,
  \&\fB\-Wno\-attributes=vendor::attr\fR disables warning about the following
  declaration:
  .Sp
--- 8791,8797 ----
  attributes.
  .Sp
  Additionally, using \fB\-Wno\-attributes=\fR, it is possible to suppress
! warnings about unknown scoped attributes (in C++11 and C2X).  For example,
  \&\fB\-Wno\-attributes=vendor::attr\fR disables warning about the following
  declaration:
  .Sp
*************** of these declarations:
*** 8880,8895 ****
  .Ve
  .Sp
  Note that \fB\-Wno\-attributes=\fR does not imply \fB\-Wno\-attributes\fR.
! .IP "\fB\-Wno\-builtin\-declaration\-mismatch\fR" 4
  .IX Item "-Wno-builtin-declaration-mismatch"
! Warn if a built-in function is declared with an incompatible signature
! or as a non-function, or when a built-in function declared with a type
  that does not include a prototype is called with arguments whose promoted
  types do not match those expected by the function.  When \fB\-Wextra\fR
! is specified, also warn when a built-in function that takes arguments is
  declared without a prototype.  The \fB\-Wbuiltin\-declaration\-mismatch\fR
  warning is enabled by default.  To avoid the warning include the appropriate
! header to bring the prototypes of built-in functions into scope.
  .Sp
  For example, the call to \f(CW\*(C`memset\*(C'\fR below is diagnosed by the warning
  because the function expects a value of type \f(CW\*(C`size_t\*(C'\fR as its argument
--- 8809,8824 ----
  .Ve
  .Sp
  Note that \fB\-Wno\-attributes=\fR does not imply \fB\-Wno\-attributes\fR.
! .IP \fB\-Wno\-builtin\-declaration\-mismatch\fR 4
  .IX Item "-Wno-builtin-declaration-mismatch"
! Warn if a built\-in function is declared with an incompatible signature
! or as a non\-function, or when a built\-in function declared with a type
  that does not include a prototype is called with arguments whose promoted
  types do not match those expected by the function.  When \fB\-Wextra\fR
! is specified, also warn when a built\-in function that takes arguments is
  declared without a prototype.  The \fB\-Wbuiltin\-declaration\-mismatch\fR
  warning is enabled by default.  To avoid the warning include the appropriate
! header to bring the prototypes of built\-in functions into scope.
  .Sp
  For example, the call to \f(CW\*(C`memset\*(C'\fR below is diagnosed by the warning
  because the function expects a value of type \f(CW\*(C`size_t\*(C'\fR as its argument
*************** the declaration of the function is diagn
*** 8903,8933 ****
  \&          memset (d, \*(Aq\e0\*(Aq, 32);
  \&        }
  .Ve
! .IP "\fB\-Wno\-builtin\-macro\-redefined\fR" 4
  .IX Item "-Wno-builtin-macro-redefined"
! Do not warn if certain built-in macros are redefined.  This suppresses
  warnings for redefinition of \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR, \f(CW\*(C`_\|_TIME_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_DATE_\|_\*(C'\fR, \f(CW\*(C`_\|_FILE_\|_\*(C'\fR, and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR.
! .IP "\fB\-Wstrict\-prototypes\fR (C and Objective-C only)" 4
  .IX Item "-Wstrict-prototypes (C and Objective-C only)"
  Warn if a function is declared or defined without specifying the
! argument types.  (An old-style function definition is permitted without
  a warning if preceded by a declaration that specifies the argument
  types.)
! .IP "\fB\-Wold\-style\-declaration\fR (C and Objective-C only)" 4
  .IX Item "-Wold-style-declaration (C and Objective-C only)"
  Warn for obsolescent usages, according to the C Standard, in a
! declaration. For example, warn if storage-class specifiers like
  \&\f(CW\*(C`static\*(C'\fR are not the first things in a declaration.  This warning
  is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wold\-style\-definition\fR (C and Objective-C only)" 4
  .IX Item "-Wold-style-definition (C and Objective-C only)"
! Warn if an old-style function definition is used.  A warning is given
  even if there is a previous prototype.  A definition using \fB()\fR
! is not considered an old-style definition in C2X mode, because it is
  equivalent to \fB(void)\fR in that case, but is considered an
! old-style definition for older standards.
! .IP "\fB\-Wmissing\-parameter\-type\fR (C and Objective-C only)" 4
  .IX Item "-Wmissing-parameter-type (C and Objective-C only)"
  A function parameter is declared without a type specifier in K&R\-style
  functions:
--- 8832,8862 ----
  \&          memset (d, \*(Aq\e0\*(Aq, 32);
  \&        }
  .Ve
! .IP \fB\-Wno\-builtin\-macro\-redefined\fR 4
  .IX Item "-Wno-builtin-macro-redefined"
! Do not warn if certain built\-in macros are redefined.  This suppresses
  warnings for redefinition of \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR, \f(CW\*(C`_\|_TIME_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_DATE_\|_\*(C'\fR, \f(CW\*(C`_\|_FILE_\|_\*(C'\fR, and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR.
! .IP "\fB\-Wstrict\-prototypes\fR (C and Objective\-C only)" 4
  .IX Item "-Wstrict-prototypes (C and Objective-C only)"
  Warn if a function is declared or defined without specifying the
! argument types.  (An old\-style function definition is permitted without
  a warning if preceded by a declaration that specifies the argument
  types.)
! .IP "\fB\-Wold\-style\-declaration\fR (C and Objective\-C only)" 4
  .IX Item "-Wold-style-declaration (C and Objective-C only)"
  Warn for obsolescent usages, according to the C Standard, in a
! declaration. For example, warn if storage\-class specifiers like
  \&\f(CW\*(C`static\*(C'\fR are not the first things in a declaration.  This warning
  is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wold\-style\-definition\fR (C and Objective\-C only)" 4
  .IX Item "-Wold-style-definition (C and Objective-C only)"
! Warn if an old\-style function definition is used.  A warning is given
  even if there is a previous prototype.  A definition using \fB()\fR
! is not considered an old\-style definition in C2X mode, because it is
  equivalent to \fB(void)\fR in that case, but is considered an
! old\-style definition for older standards.
! .IP "\fB\-Wmissing\-parameter\-type\fR (C and Objective\-C only)" 4
  .IX Item "-Wmissing-parameter-type (C and Objective-C only)"
  A function parameter is declared without a type specifier in K&R\-style
  functions:
*************** functions:
*** 8937,8964 ****
  .Ve
  .Sp
  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wmissing\-prototypes\fR (C and Objective-C only)" 4
  .IX Item "-Wmissing-prototypes (C and Objective-C only)"
  Warn if a global function is defined without a previous prototype
  declaration.  This warning is issued even if the definition itself
  provides a prototype.  Use this option to detect global functions
  that do not have a matching prototype declaration in a header file.
! This option is not valid for \*(C+ because all function declarations
! provide prototypes and a non-matching declaration declares an
  overload rather than conflict with an earlier declaration.
! Use \fB\-Wmissing\-declarations\fR to detect missing declarations in \*(C+.
! .IP "\fB\-Wmissing\-declarations\fR" 4
  .IX Item "-Wmissing-declarations"
  Warn if a global function is defined without a previous declaration.
  Do so even if the definition itself provides a prototype.
  Use this option to detect global functions that are not declared in
  header files.  In C, no warnings are issued for functions with previous
! non-prototype declarations; use \fB\-Wmissing\-prototypes\fR to detect
! missing prototypes.  In \*(C+, no warnings are issued for function templates,
  or for inline functions, or for functions in anonymous namespaces.
! .IP "\fB\-Wmissing\-field\-initializers\fR" 4
  .IX Item "-Wmissing-field-initializers"
! Warn if a structure's initializer has some fields missing.  For
  example, the following code causes such a warning, because
  \&\f(CW\*(C`x.h\*(C'\fR is implicitly zero:
  .Sp
--- 8866,8893 ----
  .Ve
  .Sp
  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wmissing\-prototypes\fR (C and Objective\-C only)" 4
  .IX Item "-Wmissing-prototypes (C and Objective-C only)"
  Warn if a global function is defined without a previous prototype
  declaration.  This warning is issued even if the definition itself
  provides a prototype.  Use this option to detect global functions
  that do not have a matching prototype declaration in a header file.
! This option is not valid for C++ because all function declarations
! provide prototypes and a non\-matching declaration declares an
  overload rather than conflict with an earlier declaration.
! Use \fB\-Wmissing\-declarations\fR to detect missing declarations in C++.
! .IP \fB\-Wmissing\-declarations\fR 4
  .IX Item "-Wmissing-declarations"
  Warn if a global function is defined without a previous declaration.
  Do so even if the definition itself provides a prototype.
  Use this option to detect global functions that are not declared in
  header files.  In C, no warnings are issued for functions with previous
! non\-prototype declarations; use \fB\-Wmissing\-prototypes\fR to detect
! missing prototypes.  In C++, no warnings are issued for function templates,
  or for inline functions, or for functions in anonymous namespaces.
! .IP \fB\-Wmissing\-field\-initializers\fR 4
  .IX Item "-Wmissing-field-initializers"
! Warn if a structure\*(Aqs initializer has some fields missing.  For
  example, the following code causes such a warning, because
  \&\f(CW\*(C`x.h\*(C'\fR is implicitly zero:
  .Sp
*************** In C this option does not warn about the
*** 8983,8989 ****
  \&        struct s x = { 0 };
  .Ve
  .Sp
! Likewise, in \*(C+ this option does not warn about the empty { }
  initializer, for example:
  .Sp
  .Vb 2
--- 8912,8918 ----
  \&        struct s x = { 0 };
  .Ve
  .Sp
! Likewise, in C++ this option does not warn about the empty { }
  initializer, for example:
  .Sp
  .Vb 2
*************** initializer, for example:
*** 8993,9001 ****
  .Sp
  This warning is included in \fB\-Wextra\fR.  To get other \fB\-Wextra\fR
  warnings without this one, use \fB\-Wextra \-Wno\-missing\-field\-initializers\fR.
! .IP "\fB\-Wno\-missing\-requires\fR" 4
  .IX Item "-Wno-missing-requires"
! By default, the compiler warns about a concept-id appearing as a \*(C+20 simple-requirement:
  .Sp
  .Vb 1
  \&        bool satisfied = requires { C };
--- 8922,8930 ----
  .Sp
  This warning is included in \fB\-Wextra\fR.  To get other \fB\-Wextra\fR
  warnings without this one, use \fB\-Wextra \-Wno\-missing\-field\-initializers\fR.
! .IP \fB\-Wno\-missing\-requires\fR 4
  .IX Item "-Wno-missing-requires"
! By default, the compiler warns about a concept\-id appearing as a C++20 simple\-requirement:
  .Sp
  .Vb 1
  \&        bool satisfied = requires { C };
*************** so \fBsatisfied\fR is only true if conce
*** 9012,9018 ****
  type \fBT\fR.
  .Sp
  This warning can be disabled with \fB\-Wno\-missing\-requires\fR.
! .IP "\fB\-Wno\-missing\-template\-keyword\fR" 4
  .IX Item "-Wno-missing-template-keyword"
  The member access tokens ., \-> and :: must be followed by the \f(CW\*(C`template\*(C'\fR
  keyword if the parent object is dependent and the member being named is a
--- 8941,8947 ----
  type \fBT\fR.
  .Sp
  This warning can be disabled with \fB\-Wno\-missing\-requires\fR.
! .IP \fB\-Wno\-missing\-template\-keyword\fR 4
  .IX Item "-Wno-missing-template-keyword"
  The member access tokens ., \-> and :: must be followed by the \f(CW\*(C`template\*(C'\fR
  keyword if the parent object is dependent and the member being named is a
*************** template, even where m and N are integer
*** 9042,9073 ****
  .Ve
  .Sp
  This warning can be disabled with \fB\-Wno\-missing\-template\-keyword\fR.
! .IP "\fB\-Wno\-multichar\fR" 4
  .IX Item "-Wno-multichar"
! Do not warn if a multicharacter constant (\fB'\s-1FOOF\s0'\fR) is used.
! Usually they indicate a typo in the user's code, as they have
! implementation-defined values, and should not be used in portable code.
! .IP "\fB\-Wnormalized=\fR[\fBnone\fR|\fBid\fR|\fBnfc\fR|\fBnfkc\fR]" 4
  .IX Item "-Wnormalized=[none|id|nfc|nfkc]"
! In \s-1ISO C\s0 and \s-1ISO \*(C+,\s0 two identifiers are different if they are
  different sequences of characters.  However, sometimes when characters
! outside the basic \s-1ASCII\s0 character set are used, you can have two
  different character sequences that look the same.  To avoid confusion,
! the \s-1ISO 10646\s0 standard sets out some \fInormalization rules\fR which
  when applied ensure that two sequences that look the same are turned into
! the same sequence.  \s-1GCC\s0 can warn you if you are using identifiers that
  have not been normalized; this option controls that warning.
  .Sp
! There are four levels of warning supported by \s-1GCC.\s0  The default is
  \&\fB\-Wnormalized=nfc\fR, which warns about any identifier that is
! not in the \s-1ISO 10646 \*(L"C\*(R"\s0 normalized form, \fI\s-1NFC\s0\fR.  \s-1NFC\s0 is the
  recommended form for most uses.  It is equivalent to
  \&\fB\-Wnormalized\fR.
  .Sp
  Unfortunately, there are some characters allowed in identifiers by
! \&\s-1ISO C\s0 and \s-1ISO \*(C+\s0 that, when turned into \s-1NFC,\s0 are not allowed in 
! identifiers.  That is, there's no way to use these symbols in portable
! \&\s-1ISO C\s0 or \*(C+ and have all your identifiers in \s-1NFC.\s0
  \&\fB\-Wnormalized=id\fR suppresses the warning for these characters.
  It is hoped that future versions of the standards involved will correct
  this, which is why this option is not the default.
--- 8971,9002 ----
  .Ve
  .Sp
  This warning can be disabled with \fB\-Wno\-missing\-template\-keyword\fR.
! .IP \fB\-Wno\-multichar\fR 4
  .IX Item "-Wno-multichar"
! Do not warn if a multicharacter constant (\fB\*(AqFOOF\*(Aq\fR) is used.
! Usually they indicate a typo in the user\*(Aqs code, as they have
! implementation\-defined values, and should not be used in portable code.
! .IP \fB\-Wnormalized=\fR[\fBnone\fR|\fBid\fR|\fBnfc\fR|\fBnfkc\fR] 4
  .IX Item "-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 \fInormalization rules\fR which
  when applied ensure that two sequences that look the same are turned into
! the same sequence.  GCC can warn you if you are using identifiers that
  have not been normalized; this option controls that warning.
  .Sp
! There are four levels of warning supported by GCC.  The default is
  \&\fB\-Wnormalized=nfc\fR, which warns about any identifier that is
! not in the ISO 10646 "C" normalized form, \fINFC\fR.  NFC is the
  recommended form for most uses.  It is equivalent to
  \&\fB\-Wnormalized\fR.
  .Sp
  Unfortunately, there are some characters allowed in identifiers by
! ISO C and ISO C++ that, when turned into NFC, are not allowed in 
! identifiers.  That is, there\*(Aqs no way to use these symbols in portable
! ISO C or C++ and have all your identifiers in NFC.
  \&\fB\-Wnormalized=id\fR suppresses the warning for these characters.
  It is hoped that future versions of the standards involved will correct
  this, which is why this option is not the default.
*************** this, which is why this option is not th
*** 9075,9126 ****
  You can switch the warning off for all characters by writing
  \&\fB\-Wnormalized=none\fR or \fB\-Wno\-normalized\fR.  You should
  only do this if you are using some other normalization scheme (like
! \&\*(L"D\*(R"), because otherwise you can easily create bugs that are
  literally impossible to see.
  .Sp
! Some characters in \s-1ISO 10646\s0 have distinct meanings but look identical
  in some fonts or display methodologies, especially once formatting has
! been applied.  For instance \f(CW\*(C`\eu207F\*(C'\fR, \*(L"\s-1SUPERSCRIPT LATIN SMALL
! LETTER N\*(R",\s0 displays just like a regular \f(CW\*(C`n\*(C'\fR that has been
! placed in a superscript.  \s-1ISO 10646\s0 defines the \fI\s-1NFKC\s0\fR
  normalization scheme to convert all these into a standard form as
! well, and \s-1GCC\s0 warns if your code is not in \s-1NFKC\s0 if you use
  \&\fB\-Wnormalized=nfkc\fR.  This warning is comparable to warning
  about every identifier that contains the letter O because it might be
  confused with the digit 0, and so is not the default, but may be
  useful as a local coding convention if the programming environment 
  cannot be fixed to display these characters distinctly.
! .IP "\fB\-Wno\-attribute\-warning\fR" 4
  .IX Item "-Wno-attribute-warning"
  Do not warn about usage of functions
  declared with \f(CW\*(C`warning\*(C'\fR attribute.  By default, this warning is
  enabled.  \fB\-Wno\-attribute\-warning\fR can be used to disable the
  warning or \fB\-Wno\-error=attribute\-warning\fR can be used to
  disable the error when compiled with \fB\-Werror\fR flag.
! .IP "\fB\-Wno\-deprecated\fR" 4
  .IX Item "-Wno-deprecated"
  Do not warn about usage of deprecated features.
! .IP "\fB\-Wno\-deprecated\-declarations\fR" 4
  .IX Item "-Wno-deprecated-declarations"
  Do not warn about uses of functions,
  variables, and types marked as deprecated by using the \f(CW\*(C`deprecated\*(C'\fR
  attribute.
! .IP "\fB\-Wno\-overflow\fR" 4
  .IX Item "-Wno-overflow"
! Do not warn about compile-time overflow in constant expressions.
! .IP "\fB\-Wno\-odr\fR" 4
  .IX Item "-Wno-odr"
! Warn about One Definition Rule violations during link-time optimization.
  Enabled by default.
! .IP "\fB\-Wopenacc\-parallelism\fR" 4
  .IX Item "-Wopenacc-parallelism"
  Warn about potentially suboptimal choices related to OpenACC parallelism.
! .IP "\fB\-Wopenmp\-simd\fR" 4
  .IX Item "-Wopenmp-simd"
  Warn if the vectorizer cost model overrides the OpenMP
  simd directive set by user.  The \fB\-fsimd\-cost\-model=unlimited\fR
  option can be used to relax the cost model.
! .IP "\fB\-Woverride\-init\fR (C and Objective-C only)" 4
  .IX Item "-Woverride-init (C and Objective-C only)"
  Warn if an initialized field without side effects is overridden when
  using designated initializers.
--- 9004,9055 ----
  You can switch the warning off for all characters by writing
  \&\fB\-Wnormalized=none\fR or \fB\-Wno\-normalized\fR.  You should
  only do this if you are using some other normalization scheme (like
! "D"), because otherwise you can easily create bugs that are
  literally impossible to see.
  .Sp
! 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 \f(CW\*(C`\eu207F\*(C'\fR, "SUPERSCRIPT LATIN SMALL
! LETTER N", displays just like a regular \f(CW\*(C`n\*(C'\fR that has been
! placed in a superscript.  ISO 10646 defines the \fINFKC\fR
  normalization scheme to convert all these into a standard form as
! well, and GCC warns if your code is not in NFKC if you use
  \&\fB\-Wnormalized=nfkc\fR.  This warning is comparable to warning
  about every identifier that contains the letter O because it might be
  confused with the digit 0, and so is not the default, but may be
  useful as a local coding convention if the programming environment 
  cannot be fixed to display these characters distinctly.
! .IP \fB\-Wno\-attribute\-warning\fR 4
  .IX Item "-Wno-attribute-warning"
  Do not warn about usage of functions
  declared with \f(CW\*(C`warning\*(C'\fR attribute.  By default, this warning is
  enabled.  \fB\-Wno\-attribute\-warning\fR can be used to disable the
  warning or \fB\-Wno\-error=attribute\-warning\fR can be used to
  disable the error when compiled with \fB\-Werror\fR flag.
! .IP \fB\-Wno\-deprecated\fR 4
  .IX Item "-Wno-deprecated"
  Do not warn about usage of deprecated features.
! .IP \fB\-Wno\-deprecated\-declarations\fR 4
  .IX Item "-Wno-deprecated-declarations"
  Do not warn about uses of functions,
  variables, and types marked as deprecated by using the \f(CW\*(C`deprecated\*(C'\fR
  attribute.
! .IP \fB\-Wno\-overflow\fR 4
  .IX Item "-Wno-overflow"
! Do not warn about compile\-time overflow in constant expressions.
! .IP \fB\-Wno\-odr\fR 4
  .IX Item "-Wno-odr"
! Warn about One Definition Rule violations during link\-time optimization.
  Enabled by default.
! .IP \fB\-Wopenacc\-parallelism\fR 4
  .IX Item "-Wopenacc-parallelism"
  Warn about potentially suboptimal choices related to OpenACC parallelism.
! .IP \fB\-Wopenmp\-simd\fR 4
  .IX Item "-Wopenmp-simd"
  Warn if the vectorizer cost model overrides the OpenMP
  simd directive set by user.  The \fB\-fsimd\-cost\-model=unlimited\fR
  option can be used to relax the cost model.
! .IP "\fB\-Woverride\-init\fR (C and Objective\-C only)" 4
  .IX Item "-Woverride-init (C and Objective-C only)"
  Warn if an initialized field without side effects is overridden when
  using designated initializers.
*************** using designated initializers.
*** 9128,9142 ****
  This warning is included in \fB\-Wextra\fR.  To get other
  \&\fB\-Wextra\fR warnings without this one, use \fB\-Wextra
  \&\-Wno\-override\-init\fR.
! .IP "\fB\-Wno\-override\-init\-side\-effects\fR (C and Objective-C only)" 4
  .IX Item "-Wno-override-init-side-effects (C and Objective-C only)"
  Do not warn if an initialized field with side effects is overridden when
  using designated initializers.  This warning is enabled by default.
! .IP "\fB\-Wpacked\fR" 4
  .IX Item "-Wpacked"
  Warn if a structure is given the packed attribute, but the packed
  attribute has no effect on the layout or size of the structure.
! Such structures may be mis-aligned for little benefit.  For
  instance, in this code, the variable \f(CW\*(C`f.x\*(C'\fR in \f(CW\*(C`struct bar\*(C'\fR
  is misaligned even though \f(CW\*(C`struct bar\*(C'\fR does not itself
  have the packed attribute:
--- 9057,9071 ----
  This warning is included in \fB\-Wextra\fR.  To get other
  \&\fB\-Wextra\fR warnings without this one, use \fB\-Wextra
  \&\-Wno\-override\-init\fR.
! .IP "\fB\-Wno\-override\-init\-side\-effects\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-override-init-side-effects (C and Objective-C only)"
  Do not warn if an initialized field with side effects is overridden when
  using designated initializers.  This warning is enabled by default.
! .IP \fB\-Wpacked\fR 4
  .IX Item "-Wpacked"
  Warn if a structure is given the packed attribute, but the packed
  attribute has no effect on the layout or size of the structure.
! Such structures may be mis\-aligned for little benefit.  For
  instance, in this code, the variable \f(CW\*(C`f.x\*(C'\fR in \f(CW\*(C`struct bar\*(C'\fR
  is misaligned even though \f(CW\*(C`struct bar\*(C'\fR does not itself
  have the packed attribute:
*************** have the packed attribute:
*** 9151,9162 ****
  \&          struct foo f;
  \&        };
  .Ve
! .IP "\fB\-Wnopacked\-bitfield\-compat\fR" 4
  .IX Item "-Wnopacked-bitfield-compat"
! The 4.1, 4.2 and 4.3 series of \s-1GCC\s0 ignore the \f(CW\*(C`packed\*(C'\fR attribute
! on bit-fields of type \f(CW\*(C`char\*(C'\fR.  This was fixed in \s-1GCC 4.4\s0 but
! the change can lead to differences in the structure layout.  \s-1GCC\s0
! informs you when the offset of such a field has changed in \s-1GCC 4.4.\s0
  For example there is no longer a 4\-bit padding between field \f(CW\*(C`a\*(C'\fR
  and \f(CW\*(C`b\*(C'\fR in this structure:
  .Sp
--- 9080,9091 ----
  \&          struct foo f;
  \&        };
  .Ve
! .IP \fB\-Wnopacked\-bitfield\-compat\fR 4
  .IX Item "-Wnopacked-bitfield-compat"
! The 4.1, 4.2 and 4.3 series of GCC ignore the \f(CW\*(C`packed\*(C'\fR attribute
! on bit\-fields of type \f(CW\*(C`char\*(C'\fR.  This was 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 \f(CW\*(C`a\*(C'\fR
  and \f(CW\*(C`b\*(C'\fR in this structure:
  .Sp
*************** and \f(CW\*(C`b\*(C'\fR in this structur
*** 9170,9177 ****
  .Sp
  This warning is enabled by default.  Use
  \&\fB\-Wno\-packed\-bitfield\-compat\fR to disable this warning.
! .IP "\fB\-Wpacked\-not\-aligned\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wpacked-not-aligned (C, , Objective-C and Objective- only)"
  Warn if a structure field with explicitly specified alignment in a
  packed struct or union is misaligned.  For example, a warning will
  be issued on \f(CW\*(C`struct S\*(C'\fR, like, \f(CW\*(C`warning: alignment 1 of
--- 9099,9106 ----
  .Sp
  This warning is enabled by default.  Use
  \&\fB\-Wno\-packed\-bitfield\-compat\fR to disable this warning.
! .IP "\fB\-Wpacked\-not\-aligned\fR (C, C++, Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wpacked-not-aligned (C, C++, Objective-C and Objective-C++ only)"
  Warn if a structure field with explicitly specified alignment in a
  packed struct or union is misaligned.  For example, a warning will
  be issued on \f(CW\*(C`struct S\*(C'\fR, like, \f(CW\*(C`warning: alignment 1 of
*************** be issued on \f(CW\*(C`struct S\*(C'\fR,
*** 9185,9208 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wpadded\fR" 4
  .IX Item "-Wpadded"
  Warn if padding is included in a structure, either to align an element
  of the structure or to align the whole structure.  Sometimes when this
  happens it is possible to rearrange the fields of the structure to
  reduce the padding and so make the structure smaller.
! .IP "\fB\-Wredundant\-decls\fR" 4
  .IX Item "-Wredundant-decls"
  Warn if anything is declared more than once in the same scope, even in
  cases where multiple declaration is valid and changes nothing.
! .IP "\fB\-Wrestrict\fR" 4
  .IX Item "-Wrestrict"
  Warn when an object referenced by a \f(CW\*(C`restrict\*(C'\fR\-qualified parameter
! (or, in \*(C+, a \f(CW\*(C`_\|_restrict\*(C'\fR\-qualified parameter) is aliased by another
  argument, or when copies between such objects overlap.  For example,
  the call to the \f(CW\*(C`strcpy\*(C'\fR function below attempts to truncate the string
  by replacing its initial characters with the last four.  However, because
! the call writes the terminating \s-1NUL\s0 into \f(CW\*(C`a[4]\*(C'\fR, the copies overlap and
  the call is diagnosed.
  .Sp
  .Vb 6
--- 9114,9137 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wpadded\fR 4
  .IX Item "-Wpadded"
  Warn if padding is included in a structure, either to align an element
  of the structure or to align the whole structure.  Sometimes when this
  happens it is possible to rearrange the fields of the structure to
  reduce the padding and so make the structure smaller.
! .IP \fB\-Wredundant\-decls\fR 4
  .IX Item "-Wredundant-decls"
  Warn if anything is declared more than once in the same scope, even in
  cases where multiple declaration is valid and changes nothing.
! .IP \fB\-Wrestrict\fR 4
  .IX Item "-Wrestrict"
  Warn when an object referenced by a \f(CW\*(C`restrict\*(C'\fR\-qualified parameter
! (or, in C++, a \f(CW\*(C`_\|_restrict\*(C'\fR\-qualified parameter) is aliased by another
  argument, or when copies between such objects overlap.  For example,
  the call to the \f(CW\*(C`strcpy\*(C'\fR function below attempts to truncate the string
  by replacing its initial characters with the last four.  However, because
! the call writes the terminating NUL into \f(CW\*(C`a[4]\*(C'\fR, the copies overlap and
  the call is diagnosed.
  .Sp
  .Vb 6
*************** the call is diagnosed.
*** 9217,9226 ****
  The \fB\-Wrestrict\fR option detects some instances of simple overlap
  even without optimization but works best at \fB\-O2\fR and above.  It
  is included in \fB\-Wall\fR.
! .IP "\fB\-Wnested\-externs\fR (C and Objective-C only)" 4
  .IX Item "-Wnested-externs (C and Objective-C only)"
  Warn if an \f(CW\*(C`extern\*(C'\fR declaration is encountered within a function.
! .IP "\fB\-Winline\fR" 4
  .IX Item "-Winline"
  Warn if a function that is declared as inline cannot be inlined.
  Even with this option, the compiler does not warn about failures to
--- 9146,9155 ----
  The \fB\-Wrestrict\fR option detects some instances of simple overlap
  even without optimization but works best at \fB\-O2\fR and above.  It
  is included in \fB\-Wall\fR.
! .IP "\fB\-Wnested\-externs\fR (C and Objective\-C only)" 4
  .IX Item "-Wnested-externs (C and Objective-C only)"
  Warn if an \f(CW\*(C`extern\*(C'\fR declaration is encountered within a function.
! .IP \fB\-Winline\fR 4
  .IX Item "-Winline"
  Warn if a function that is declared as inline cannot be inlined.
  Even with this option, the compiler does not warn about failures to
*************** the size of the function being inlined a
*** 9232,9241 ****
  that has already been done in the current function.  Therefore,
  seemingly insignificant changes in the source program can cause the
  warnings produced by \fB\-Winline\fR to appear or disappear.
! .IP "\fB\-Winterference\-size\fR" 4
  .IX Item "-Winterference-size"
! Warn about use of \*(C+17 \f(CW\*(C`std::hardware_destructive_interference_size\*(C'\fR
! without specifying its value with \fB\-\-param destructive-interference-size\fR.
  Also warn about questionable values for that option.
  .Sp
  This variable is intended to be used for controlling class layout, to
--- 9161,9170 ----
  that has already been done in the current function.  Therefore,
  seemingly insignificant changes in the source program can cause the
  warnings produced by \fB\-Winline\fR to appear or disappear.
! .IP \fB\-Winterference\-size\fR 4
  .IX Item "-Winterference-size"
! Warn about use of C++17 \f(CW\*(C`std::hardware_destructive_interference_size\*(C'\fR
! without specifying its value with \fB\-\-param destructive\-interference\-size\fR.
  Also warn about questionable values for that option.
  .Sp
  This variable is intended to be used for controlling class layout, to
*************** avoid false sharing in concurrent code:
*** 9251,9323 ****
  .Ve
  .Sp
  Here \fBone\fR and \fBtwo\fR are intended to be far enough apart
! that stores to one won't require accesses to the other to reload the
  cache line.
  .Sp
! By default, \fB\-\-param destructive-interference-size\fR and
! \&\fB\-\-param constructive-interference-size\fR are set based on the
  current \fB\-mtune\fR option, typically to the L1 cache line size
! for the particular target \s-1CPU,\s0 sometimes to a range if tuning for a
! generic target.  So all translation units that depend on \s-1ABI\s0
  compatibility for the use of these variables must be compiled with
  the same \fB\-mtune\fR (or \fB\-mcpu\fR).
  .Sp
! If \s-1ABI\s0 stability is important, such as if the use is in a header for a
  library, you should probably not use the hardware interference size
  variables at all.  Alternatively, you can force a particular value
  with \fB\-\-param\fR.
  .Sp
! If you are confident that your use of the variable does not affect \s-1ABI\s0
  outside a single build of your project, you can turn off the warning
  with \fB\-Wno\-interference\-size\fR.
! .IP "\fB\-Wint\-in\-bool\-context\fR" 4
  .IX Item "-Wint-in-bool-context"
  Warn for suspicious use of integer values where boolean values are expected,
! such as conditional expressions (?:) using non-boolean integer constants in
  boolean context, like \f(CW\*(C`if (a <= b ? 2 : 3)\*(C'\fR.  Or left shifting of signed
  integers in boolean context, like \f(CW\*(C`for (a = 0; 1 << a; a++);\*(C'\fR.  Likewise
  for all kinds of multiplications regardless of the data type.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-int\-to\-pointer\-cast\fR" 4
  .IX Item "-Wno-int-to-pointer-cast"
  Suppress warnings from casts to pointer type of an integer of a
! different size. In \*(C+, casting to a pointer type of smaller size is
! an error. \fBWint-to-pointer-cast\fR is enabled by default.
! .IP "\fB\-Wno\-pointer\-to\-int\-cast\fR (C and Objective-C only)" 4
  .IX Item "-Wno-pointer-to-int-cast (C and Objective-C only)"
  Suppress warnings from casts from a pointer to an integer type of a
  different size.
! .IP "\fB\-Winvalid\-pch\fR" 4
  .IX Item "-Winvalid-pch"
  Warn if a precompiled header is found in
  the search path but cannot be used.
! .IP "\fB\-Winvalid\-utf8\fR" 4
  .IX Item "-Winvalid-utf8"
! Warn if an invalid \s-1UTF\-8\s0 character is found.
! This warning is on by default for \*(C+23 if \fB\-finput\-charset=UTF\-8\fR
  is used and turned into error with \fB\-pedantic\-errors\fR.
! .IP "\fB\-Wno\-unicode\fR" 4
  .IX Item "-Wno-unicode"
! Don't diagnose invalid forms of delimited or named escape sequences which are
  treated as separate tokens.  \fBWunicode\fR is enabled by default.
! .IP "\fB\-Wlong\-long\fR" 4
  .IX Item "-Wlong-long"
  Warn if \f(CW\*(C`long long\*(C'\fR type is used.  This is enabled by either
! \&\fB\-Wpedantic\fR or \fB\-Wtraditional\fR in \s-1ISO C90\s0 and \*(C+98
  modes.  To inhibit the warning messages, use \fB\-Wno\-long\-long\fR.
! .IP "\fB\-Wvariadic\-macros\fR" 4
  .IX Item "-Wvariadic-macros"
! Warn if variadic macros are used in \s-1ISO C90\s0 mode, or if the \s-1GNU\s0
! alternate syntax is used in \s-1ISO C99\s0 mode.  This is enabled by either
  \&\fB\-Wpedantic\fR or \fB\-Wtraditional\fR.  To inhibit the warning
  messages, use \fB\-Wno\-variadic\-macros\fR.
! .IP "\fB\-Wno\-varargs\fR" 4
  .IX Item "-Wno-varargs"
  Do not warn upon questionable usage of the macros used to handle variable
  arguments like \f(CW\*(C`va_start\*(C'\fR.  These warnings are enabled by default.
! .IP "\fB\-Wvector\-operation\-performance\fR" 4
  .IX Item "-Wvector-operation-performance"
! Warn if vector operation is not implemented via \s-1SIMD\s0 capabilities of the
  architecture.  Mainly useful for the performance tuning.
  Vector operation can be implemented \f(CW\*(C`piecewise\*(C'\fR, which means that the
  scalar operation is performed on every vector element; 
--- 9180,9252 ----
  .Ve
  .Sp
  Here \fBone\fR and \fBtwo\fR are intended to be far enough apart
! that stores to one won\*(Aqt require accesses to the other to reload the
  cache line.
  .Sp
! By default, \fB\-\-param destructive\-interference\-size\fR and
! \&\fB\-\-param constructive\-interference\-size\fR are set based on the
  current \fB\-mtune\fR option, typically to the L1 cache line size
! for the particular target CPU, sometimes to a range if tuning for a
! generic target.  So all translation units that depend on ABI
  compatibility for the use of these variables must be compiled with
  the same \fB\-mtune\fR (or \fB\-mcpu\fR).
  .Sp
! If ABI stability is important, such as if the use is in a header for a
  library, you should probably not use the hardware interference size
  variables at all.  Alternatively, you can force a particular value
  with \fB\-\-param\fR.
  .Sp
! If you are confident that your use of the variable does not affect ABI
  outside a single build of your project, you can turn off the warning
  with \fB\-Wno\-interference\-size\fR.
! .IP \fB\-Wint\-in\-bool\-context\fR 4
  .IX Item "-Wint-in-bool-context"
  Warn for suspicious use of integer values where boolean values are expected,
! such as conditional expressions (?:) using non\-boolean integer constants in
  boolean context, like \f(CW\*(C`if (a <= b ? 2 : 3)\*(C'\fR.  Or left shifting of signed
  integers in boolean context, like \f(CW\*(C`for (a = 0; 1 << a; a++);\*(C'\fR.  Likewise
  for all kinds of multiplications regardless of the data type.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wno\-int\-to\-pointer\-cast\fR 4
  .IX Item "-Wno-int-to-pointer-cast"
  Suppress warnings from casts to pointer type of an integer of a
! different size. In C++, casting to a pointer type of smaller size is
! an error. \fBWint\-to\-pointer\-cast\fR is enabled by default.
! .IP "\fB\-Wno\-pointer\-to\-int\-cast\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-pointer-to-int-cast (C and Objective-C only)"
  Suppress warnings from casts from a pointer to an integer type of a
  different size.
! .IP \fB\-Winvalid\-pch\fR 4
  .IX Item "-Winvalid-pch"
  Warn if a precompiled header is found in
  the search path but cannot be used.
! .IP \fB\-Winvalid\-utf8\fR 4
  .IX Item "-Winvalid-utf8"
! Warn if an invalid UTF\-8 character is found.
! This warning is on by default for C++23 if \fB\-finput\-charset=UTF\-8\fR
  is used and turned into error with \fB\-pedantic\-errors\fR.
! .IP \fB\-Wno\-unicode\fR 4
  .IX Item "-Wno-unicode"
! Don\*(Aqt diagnose invalid forms of delimited or named escape sequences which are
  treated as separate tokens.  \fBWunicode\fR is enabled by default.
! .IP \fB\-Wlong\-long\fR 4
  .IX Item "-Wlong-long"
  Warn if \f(CW\*(C`long long\*(C'\fR type is used.  This is enabled by either
! \&\fB\-Wpedantic\fR or \fB\-Wtraditional\fR in ISO C90 and C++98
  modes.  To inhibit the warning messages, use \fB\-Wno\-long\-long\fR.
! .IP \fB\-Wvariadic\-macros\fR 4
  .IX Item "-Wvariadic-macros"
! Warn if variadic macros are used in ISO C90 mode, or if the GNU
! alternate syntax is used in ISO C99 mode.  This is enabled by either
  \&\fB\-Wpedantic\fR or \fB\-Wtraditional\fR.  To inhibit the warning
  messages, use \fB\-Wno\-variadic\-macros\fR.
! .IP \fB\-Wno\-varargs\fR 4
  .IX Item "-Wno-varargs"
  Do not warn upon questionable usage of the macros used to handle variable
  arguments like \f(CW\*(C`va_start\*(C'\fR.  These warnings are enabled by default.
! .IP \fB\-Wvector\-operation\-performance\fR 4
  .IX Item "-Wvector-operation-performance"
! Warn if vector operation is not implemented via SIMD capabilities of the
  architecture.  Mainly useful for the performance tuning.
  Vector operation can be implemented \f(CW\*(C`piecewise\*(C'\fR, which means that the
  scalar operation is performed on every vector element; 
*************** scalar operation is performed on every v
*** 9325,9364 ****
  using scalars of wider type, which normally is more performance efficient;
  and \f(CW\*(C`as a single scalar\*(C'\fR, which means that vector fits into a
  scalar type.
! .IP "\fB\-Wvla\fR" 4
  .IX Item "-Wvla"
! Warn if a variable-length array is used in the code.
  \&\fB\-Wno\-vla\fR prevents the \fB\-Wpedantic\fR warning of
! the variable-length array.
! .IP "\fB\-Wvla\-larger\-than=\fR\fIbyte-size\fR" 4
  .IX Item "-Wvla-larger-than=byte-size"
  If this option is used, the compiler warns for declarations of
! variable-length arrays whose size is either unbounded, or bounded
! by an argument that allows the array size to exceed \fIbyte-size\fR
! bytes.  This is similar to how \fB\-Walloca\-larger\-than=\fR\fIbyte-size\fR
! works, but with variable-length arrays.
  .Sp
! Note that \s-1GCC\s0 may optimize small variable-length arrays of a known
  value into plain arrays, so this warning may not get triggered for
  such arrays.
  .Sp
! \&\fB\-Wvla\-larger\-than=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default but
  is typically only effective when \fB\-ftree\-vrp\fR is active (default
  for \fB\-O2\fR and above).
  .Sp
! See also \fB\-Walloca\-larger\-than=\fR\fIbyte-size\fR.
! .IP "\fB\-Wno\-vla\-larger\-than\fR" 4
  .IX Item "-Wno-vla-larger-than"
  Disable \fB\-Wvla\-larger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wvla\-larger\-than=\fR\fB\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Wvla\-parameter\fR" 4
  .IX Item "-Wvla-parameter"
  Warn about redeclarations of functions involving arguments of Variable
  Length Array types of inconsistent kinds or forms, and enable the detection
! of out-of-bounds accesses to such parameters by warnings such as
  \&\fB\-Warray\-bounds\fR.
  .Sp
! If the first function declaration uses the \s-1VLA\s0 form the bound specified
  in the array is assumed to be the minimum number of elements expected to
  be provided in calls to the function and the maximum number of elements
  accessed by it.  Failing to provide arguments of sufficient size or
--- 9254,9293 ----
  using scalars of wider type, which normally is more performance efficient;
  and \f(CW\*(C`as a single scalar\*(C'\fR, which means that vector fits into a
  scalar type.
! .IP \fB\-Wvla\fR 4
  .IX Item "-Wvla"
! Warn if a variable\-length array is used in the code.
  \&\fB\-Wno\-vla\fR prevents the \fB\-Wpedantic\fR warning of
! the variable\-length array.
! .IP \fB\-Wvla\-larger\-than=\fR\fIbyte\-size\fR 4
  .IX Item "-Wvla-larger-than=byte-size"
  If this option is used, the compiler warns for declarations of
! variable\-length arrays whose size is either unbounded, or bounded
! by an argument that allows the array size to exceed \fIbyte\-size\fR
! bytes.  This is similar to how \fB\-Walloca\-larger\-than=\fR\fIbyte\-size\fR
! works, but with variable\-length arrays.
  .Sp
! Note that GCC may optimize small variable\-length arrays of a known
  value into plain arrays, so this warning may not get triggered for
  such arrays.
  .Sp
! \&\fB\-Wvla\-larger\-than=\fR\fBPTRDIFF_MAX\fR is enabled by default but
  is typically only effective when \fB\-ftree\-vrp\fR is active (default
  for \fB\-O2\fR and above).
  .Sp
! See also \fB\-Walloca\-larger\-than=\fR\fIbyte\-size\fR.
! .IP \fB\-Wno\-vla\-larger\-than\fR 4
  .IX Item "-Wno-vla-larger-than"
  Disable \fB\-Wvla\-larger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wvla\-larger\-than=\fR\fBSIZE_MAX\fR or larger.
! .IP \fB\-Wvla\-parameter\fR 4
  .IX Item "-Wvla-parameter"
  Warn about redeclarations of functions involving arguments of Variable
  Length Array types of inconsistent kinds or forms, and enable the detection
! of out\-of\-bounds accesses to such parameters by warnings such as
  \&\fB\-Warray\-bounds\fR.
  .Sp
! If the first function declaration uses the VLA form the bound specified
  in the array is assumed to be the minimum number of elements expected to
  be provided in calls to the function and the maximum number of elements
  accessed by it.  Failing to provide arguments of sufficient size or
*************** accessing more than the maximum number o
*** 9367,9374 ****
  For example, the warning triggers for the following redeclarations because
  the first one allows an array of any size to be passed to \f(CW\*(C`f\*(C'\fR while
  the second one specifies that the array argument must have at least \f(CW\*(C`n\*(C'\fR
! elements.  In addition, calling \f(CW\*(C`f\*(C'\fR with the associated \s-1VLA\s0 bound
! parameter in excess of the actual \s-1VLA\s0 bound triggers a warning as well.
  .Sp
  .Vb 3
  \&        void f (int n, int[n]);
--- 9296,9303 ----
  For example, the warning triggers for the following redeclarations because
  the first one allows an array of any size to be passed to \f(CW\*(C`f\*(C'\fR while
  the second one specifies that the array argument must have at least \f(CW\*(C`n\*(C'\fR
! elements.  In addition, calling \f(CW\*(C`f\*(C'\fR with the associated VLA bound
! parameter in excess of the actual VLA bound triggers a warning as well.
  .Sp
  .Vb 3
  \&        void f (int n, int[n]);
*************** parameter in excess of the actual \s-1VL
*** 9389,9475 ****
  \&\fB\-Wvla\-parameter\fR is included in \fB\-Wall\fR.  The
  \&\fB\-Warray\-parameter\fR option triggers warnings for similar problems
  involving ordinary array arguments.
! .IP "\fB\-Wvolatile\-register\-var\fR" 4
  .IX Item "-Wvolatile-register-var"
  Warn if a register variable is declared volatile.  The volatile
  modifier does not inhibit all optimizations that may eliminate reads
  and/or writes to register variables.  This warning is enabled by
  \&\fB\-Wall\fR.
! .IP "\fB\-Wxor\-used\-as\-pow\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wxor-used-as-pow (C, , Objective-C and Objective- only)"
  Warn about uses of \f(CW\*(C`^\*(C'\fR, the exclusive or operator, where it appears
  the user meant exponentiation.  Specifically, the warning occurs when the
! left-hand side is the decimal constant 2 or 10 and the right-hand side
  is also a decimal constant.
  .Sp
! In C and \*(C+, \f(CW\*(C`^\*(C'\fR means exclusive or, whereas in some other languages
! (e.g. TeX and some versions of \s-1BASIC\s0) it means exponentiation.
  .Sp
  This warning is enabled by default.  It can be silenced by converting one
  of the operands to hexadecimal.
! .IP "\fB\-Wdisabled\-optimization\fR" 4
  .IX Item "-Wdisabled-optimization"
  Warn if a requested optimization pass is disabled.  This warning does
  not generally indicate that there is anything wrong with your code; it
! merely indicates that \s-1GCC\s0's optimizers are unable to handle the code
  effectively.  Often, the problem is that your code is too big or too
! complex; \s-1GCC\s0 refuses to optimize programs when the optimization
  itself is likely to take inordinate amounts of time.
! .IP "\fB\-Wpointer\-sign\fR (C and Objective-C only)" 4
  .IX Item "-Wpointer-sign (C and Objective-C only)"
  Warn for pointer argument passing or assignment with different signedness.
! This option is only supported for C and Objective-C.  It is implied by
  \&\fB\-Wall\fR and by \fB\-Wpedantic\fR, which can be disabled with
  \&\fB\-Wno\-pointer\-sign\fR.
! .IP "\fB\-Wstack\-protector\fR" 4
  .IX Item "-Wstack-protector"
  This option is only active when \fB\-fstack\-protector\fR is active.  It
  warns about functions that are not protected against stack smashing.
! .IP "\fB\-Woverlength\-strings\fR" 4
  .IX Item "-Woverlength-strings"
! Warn about string constants that are longer than the \*(L"minimum
! maximum\*(R" length specified in the C standard.  Modern compilers
  generally allow string constants that are much longer than the
! standard's minimum limit, but very portable programs should avoid
  using longer strings.
  .Sp
  The limit applies \fIafter\fR string constant concatenation, and does
! not count the trailing \s-1NUL.\s0  In C90, the limit was 509 characters; in
! C99, it was raised to 4095.  \*(C+98 does not specify a normative
! minimum maximum, so we do not diagnose overlength strings in \*(C+.
  .Sp
  This option is implied by \fB\-Wpedantic\fR, and can be disabled with
  \&\fB\-Wno\-overlength\-strings\fR.
! .IP "\fB\-Wunsuffixed\-float\-constants\fR (C and Objective-C only)" 4
  .IX Item "-Wunsuffixed-float-constants (C and Objective-C only)"
  Issue a warning for any floating constant that does not have
  a suffix.  When used together with \fB\-Wsystem\-headers\fR it
  warns about such constants in system header files.  This can be useful
  when preparing code to use with the \f(CW\*(C`FLOAT_CONST_DECIMAL64\*(C'\fR pragma
! from the decimal floating-point extension to C99.
! .IP "\fB\-Wno\-lto\-type\-mismatch\fR" 4
  .IX Item "-Wno-lto-type-mismatch"
! During the link-time optimization, do not warn about type mismatches in
  global declarations from different compilation units.
  Requires \fB\-flto\fR to be enabled.  Enabled by default.
! .IP "\fB\-Wno\-designated\-init\fR (C and Objective-C only)" 4
  .IX Item "-Wno-designated-init (C and Objective-C only)"
  Suppress warnings when a positional initializer is used to initialize
  a structure that has been marked with the \f(CW\*(C`designated_init\*(C'\fR
  attribute.
  .SS "Options That Control Static Analysis"
  .IX Subsection "Options That Control Static Analysis"
! .IP "\fB\-fanalyzer\fR" 4
  .IX Item "-fanalyzer"
  This option enables an static analysis of program flow which looks
! for \*(L"interesting\*(R" interprocedural paths through the
  code, and issues warnings for problems found on them.
  .Sp
! This analysis is much more expensive than other \s-1GCC\s0 warnings.
  .Sp
! In technical terms, it performs coverage-guided symbolic execution of
  the code being compiled.  It is neither sound nor complete: it can
! have false positives and false negatives.  It is a bug-finding tool,
  rather than a tool for proving program correctness.
  .Sp
  The analyzer is only suitable for use on C code in this release.
--- 9318,9404 ----
  \&\fB\-Wvla\-parameter\fR is included in \fB\-Wall\fR.  The
  \&\fB\-Warray\-parameter\fR option triggers warnings for similar problems
  involving ordinary array arguments.
! .IP \fB\-Wvolatile\-register\-var\fR 4
  .IX Item "-Wvolatile-register-var"
  Warn if a register variable is declared volatile.  The volatile
  modifier does not inhibit all optimizations that may eliminate reads
  and/or writes to register variables.  This warning is enabled by
  \&\fB\-Wall\fR.
! .IP "\fB\-Wxor\-used\-as\-pow\fR (C, C++, Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wxor-used-as-pow (C, C++, Objective-C and Objective-C++ only)"
  Warn about uses of \f(CW\*(C`^\*(C'\fR, the exclusive or operator, where it appears
  the user meant exponentiation.  Specifically, the warning occurs when the
! left\-hand side is the decimal constant 2 or 10 and the right\-hand side
  is also a decimal constant.
  .Sp
! In C and C++, \f(CW\*(C`^\*(C'\fR means exclusive or, whereas in some other languages
! (e.g. TeX and some versions of BASIC) it means exponentiation.
  .Sp
  This warning is enabled by default.  It can be silenced by converting one
  of the operands to hexadecimal.
! .IP \fB\-Wdisabled\-optimization\fR 4
  .IX Item "-Wdisabled-optimization"
  Warn if a requested optimization pass is disabled.  This warning does
  not generally indicate that there is anything wrong with your code; it
! merely indicates that GCC\*(Aqs optimizers are unable to handle the code
  effectively.  Often, the problem is that your code is too big or too
! complex; GCC refuses to optimize programs when the optimization
  itself is likely to take inordinate amounts of time.
! .IP "\fB\-Wpointer\-sign\fR (C and Objective\-C only)" 4
  .IX Item "-Wpointer-sign (C and Objective-C only)"
  Warn for pointer argument passing or assignment with different signedness.
! This option is only supported for C and Objective\-C.  It is implied by
  \&\fB\-Wall\fR and by \fB\-Wpedantic\fR, which can be disabled with
  \&\fB\-Wno\-pointer\-sign\fR.
! .IP \fB\-Wstack\-protector\fR 4
  .IX Item "-Wstack-protector"
  This option is only active when \fB\-fstack\-protector\fR is active.  It
  warns about functions that are not protected against stack smashing.
! .IP \fB\-Woverlength\-strings\fR 4
  .IX Item "-Woverlength-strings"
! Warn about string constants that are longer than the "minimum
! maximum" length specified in the C standard.  Modern compilers
  generally allow string constants that are much longer than the
! standard\*(Aqs minimum limit, but very portable programs should avoid
  using longer strings.
  .Sp
  The limit applies \fIafter\fR string constant concatenation, and does
! not count the trailing 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++.
  .Sp
  This option is implied by \fB\-Wpedantic\fR, and can be disabled with
  \&\fB\-Wno\-overlength\-strings\fR.
! .IP "\fB\-Wunsuffixed\-float\-constants\fR (C and Objective\-C only)" 4
  .IX Item "-Wunsuffixed-float-constants (C and Objective-C only)"
  Issue a warning for any floating constant that does not have
  a suffix.  When used together with \fB\-Wsystem\-headers\fR it
  warns about such constants in system header files.  This can be useful
  when preparing code to use with the \f(CW\*(C`FLOAT_CONST_DECIMAL64\*(C'\fR pragma
! from the decimal floating\-point extension to C99.
! .IP \fB\-Wno\-lto\-type\-mismatch\fR 4
  .IX Item "-Wno-lto-type-mismatch"
! During the link\-time optimization, do not warn about type mismatches in
  global declarations from different compilation units.
  Requires \fB\-flto\fR to be enabled.  Enabled by default.
! .IP "\fB\-Wno\-designated\-init\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-designated-init (C and Objective-C only)"
  Suppress warnings when a positional initializer is used to initialize
  a structure that has been marked with the \f(CW\*(C`designated_init\*(C'\fR
  attribute.
  .SS "Options That Control Static Analysis"
  .IX Subsection "Options That Control Static Analysis"
! .IP \fB\-fanalyzer\fR 4
  .IX Item "-fanalyzer"
  This option enables an static analysis of program flow which looks
! for "interesting" interprocedural paths through the
  code, and issues warnings for problems found on them.
  .Sp
! This analysis is much more expensive than other GCC warnings.
  .Sp
! In technical terms, it performs coverage\-guided symbolic execution of
  the code being compiled.  It is neither sound nor complete: it can
! have false positives and false negatives.  It is a bug\-finding tool,
  rather than a tool for proving program correctness.
  .Sp
  The analyzer is only suitable for use on C code in this release.
*************** Enabling this option effectively enables
*** 9516,9524 ****
  \&\-Wanalyzer\-write\-to\-const
  \&\-Wanalyzer\-write\-to\-string\-literal\fR
  .Sp
! This option is only available if \s-1GCC\s0 was configured with analyzer
  support enabled.
! .IP "\fB\-Wanalyzer\-too\-complex\fR" 4
  .IX Item "-Wanalyzer-too-complex"
  If \fB\-fanalyzer\fR is enabled, the analyzer uses various heuristics
  to attempt to explore the control flow and data flow in the program,
--- 9445,9453 ----
  \&\-Wanalyzer\-write\-to\-const
  \&\-Wanalyzer\-write\-to\-string\-literal\fR
  .Sp
! This option is only available if GCC was configured with analyzer
  support enabled.
! .IP \fB\-Wanalyzer\-too\-complex\fR 4
  .IX Item "-Wanalyzer-too-complex"
  If \fB\-fanalyzer\fR is enabled, the analyzer uses various heuristics
  to attempt to explore the control flow and data flow in the program,
*************** but these can be defeated by sufficientl
*** 9527,9533 ****
  By default, the analysis silently stops if the code is too
  complicated for the analyzer to fully explore and it reaches an internal
  limit.  The \fB\-Wanalyzer\-too\-complex\fR option warns if this occurs.
! .IP "\fB\-Wno\-analyzer\-allocation\-size\fR" 4
  .IX Item "-Wno-analyzer-allocation-size"
  This warning requires \fB\-fanalyzer\fR, which enables it;
  to disable it, use \fB\-Wno\-analyzer\-allocation\-size\fR.
--- 9456,9462 ----
  By default, the analysis silently stops if the code is too
  complicated for the analyzer to fully explore and it reaches an internal
  limit.  The \fB\-Wanalyzer\-too\-complex\fR option warns if this occurs.
! .IP \fB\-Wno\-analyzer\-allocation\-size\fR 4
  .IX Item "-Wno-analyzer-allocation-size"
  This warning requires \fB\-fanalyzer\fR, which enables it;
  to disable it, use \fB\-Wno\-analyzer\-allocation\-size\fR.
*************** This diagnostic warns for paths through
*** 9536,9543 ****
  a buffer is assigned to point at a buffer with a size that is not a
  multiple of \f(CW\*(C`sizeof (*pointer)\*(C'\fR.
  .Sp
! See  \s-1CWE\-131:\s0 Incorrect Calculation of Buffer Size (\f(CW\*(C`https://cwe.mitre.org/data/definitions/131.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-deref\-before\-check\fR" 4
  .IX Item "-Wno-analyzer-deref-before-check"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-deref\-before\-check\fR
--- 9465,9472 ----
  a buffer is assigned to point at a buffer with a size that is not a
  multiple of \f(CW\*(C`sizeof (*pointer)\*(C'\fR.
  .Sp
! See  CWE\-131: Incorrect Calculation of Buffer Size (\f(CW\*(C`https://cwe.mitre.org/data/definitions/131.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-deref\-before\-check\fR 4
  .IX Item "-Wno-analyzer-deref-before-check"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-deref\-before\-check\fR
*************** to disable it.
*** 9545,9565 ****
  .Sp
  This diagnostic warns for paths through the code in which a pointer
  is checked for \f(CW\*(C`NULL\*(C'\fR *after* it has already been
! dereferenced, suggesting that the pointer could have been \s-1NULL.\s0
! Such cases suggest that the check for \s-1NULL\s0 is either redundant,
  or that it needs to be moved to before the pointer is dereferenced.
  .Sp
  This diagnostic also considers values passed to a function argument
! marked with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non-NULL
  value, and thus will complain if such values are checked for \f(CW\*(C`NULL\*(C'\fR
  after returning from such a function call.
  .Sp
  This diagnostic is unlikely to be reported when any level of optimization
! is enabled, as \s-1GCC\s0's optimization logic will typically consider such
! checks for \s-1NULL\s0 as being redundant, and optimize them away before the
! analyzer \*(L"sees\*(R" them.  Hence optimization should be disabled when
  attempting to trigger this diagnostic.
! .IP "\fB\-Wno\-analyzer\-double\-fclose\fR" 4
  .IX Item "-Wno-analyzer-double-fclose"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-double\-fclose\fR to disable it.
--- 9474,9494 ----
  .Sp
  This diagnostic warns for paths through the code in which a pointer
  is checked for \f(CW\*(C`NULL\*(C'\fR *after* it has already been
! dereferenced, suggesting that the pointer could have been NULL.
! Such cases suggest that the check for NULL is either redundant,
  or that it needs to be moved to before the pointer is dereferenced.
  .Sp
  This diagnostic also considers values passed to a function argument
! marked with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non\-NULL
  value, and thus will complain if such values are checked for \f(CW\*(C`NULL\*(C'\fR
  after returning from such a function call.
  .Sp
  This diagnostic is unlikely to be reported when any level of optimization
! is enabled, as GCC\*(Aqs optimization logic will typically consider such
! checks for NULL as being redundant, and optimize them away before the
! analyzer "sees" them.  Hence optimization should be disabled when
  attempting to trigger this diagnostic.
! .IP \fB\-Wno\-analyzer\-double\-fclose\fR 4
  .IX Item "-Wno-analyzer-double-fclose"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-double\-fclose\fR to disable it.
*************** This warning requires \fB\-fanalyzer\fR,
*** 9567,9574 ****
  This diagnostic warns for paths through the code in which a \f(CW\*(C`FILE *\*(C'\fR
  can have \f(CW\*(C`fclose\*(C'\fR called on it more than once.
  .Sp
! See  \s-1CWE\-1341:\s0 Multiple Releases of Same Resource or Handle (\f(CW\*(C`https://cwe.mitre.org/data/definitions/1341.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-double\-free\fR" 4
  .IX Item "-Wno-analyzer-double-free"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-double\-free\fR to disable it.
--- 9496,9503 ----
  This diagnostic warns for paths through the code in which a \f(CW\*(C`FILE *\*(C'\fR
  can have \f(CW\*(C`fclose\*(C'\fR called on it more than once.
  .Sp
! See  CWE\-1341: Multiple Releases of Same Resource or Handle (\f(CW\*(C`https://cwe.mitre.org/data/definitions/1341.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-double\-free\fR 4
  .IX Item "-Wno-analyzer-double-free"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-double\-free\fR to disable it.
*************** This diagnostic warns for paths through
*** 9577,9621 ****
  can have a deallocator called on it more than once, either \f(CW\*(C`free\*(C'\fR,
  or a deallocator referenced by attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  \s-1CWE\-415:\s0 Double Free (\f(CW\*(C`https://cwe.mitre.org/data/definitions/415.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-exposure\-through\-output\-file\fR" 4
  .IX Item "-Wno-analyzer-exposure-through-output-file"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-exposure\-through\-output\-file\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! security-sensitive value is written to an output file
  (such as writing a password to a log file).
  .Sp
! See  \s-1CWE\-532:\s0 Information Exposure Through Log Files (\f(CW\*(C`https://cwe.mitre.org/data/definitions/532.html\*(C'\fR).
! .IP "\fB\-Wanalyzer\-exposure\-through\-uninit\-copy\fR" 4
  .IX Item "-Wanalyzer-exposure-through-uninit-copy"
  This warning requires both \fB\-fanalyzer\fR and the use of a plugin
! to specify a function that copies across a \*(L"trust boundary\*(R".  Use
  \&\fB\-Wno\-analyzer\-exposure\-through\-uninit\-copy\fR to disable it.
  .Sp
! This diagnostic warns for \*(L"infoleaks\*(R" \- paths through the code in which
  uninitialized values are copied across a security boundary
! (such as code within an \s-1OS\s0 kernel that copies a partially-initialized
  struct on the stack to user space).
  .Sp
! See  \s-1CWE\-200:\s0 Exposure of Sensitive Information to an Unauthorized Actor (\f(CW\*(C`https://cwe.mitre.org/data/definitions/200.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-fd\-access\-mode\-mismatch\fR" 4
  .IX Item "-Wno-analyzer-fd-access-mode-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-access\-mode\-mismatch\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through code in which a
! \&\f(CW\*(C`read\*(C'\fR on a write-only file descriptor is attempted, or vice versa.
  .Sp
  This diagnostic also warns for code paths in a which a function with attribute
  \&\f(CW\*(C`fd_arg_read (N)\*(C'\fR is called with a file descriptor opened with
  \&\f(CW\*(C`O_WRONLY\*(C'\fR at referenced argument \f(CW\*(C`N\*(C'\fR or a function with attribute
  \&\f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a file descriptor opened with
  \&\f(CW\*(C`O_RDONLY\*(C'\fR at referenced argument \fIN\fR.
! .IP "\fB\-Wno\-analyzer\-fd\-double\-close\fR" 4
  .IX Item "-Wno-analyzer-fd-double-close"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-double\-close\fR
--- 9506,9550 ----
  can have a deallocator called on it more than once, either \f(CW\*(C`free\*(C'\fR,
  or a deallocator referenced by attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  CWE\-415: Double Free (\f(CW\*(C`https://cwe.mitre.org/data/definitions/415.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-exposure\-through\-output\-file\fR 4
  .IX Item "-Wno-analyzer-exposure-through-output-file"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-exposure\-through\-output\-file\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! security\-sensitive value is written to an output file
  (such as writing a password to a log file).
  .Sp
! See  CWE\-532: Information Exposure Through Log Files (\f(CW\*(C`https://cwe.mitre.org/data/definitions/532.html\*(C'\fR).
! .IP \fB\-Wanalyzer\-exposure\-through\-uninit\-copy\fR 4
  .IX Item "-Wanalyzer-exposure-through-uninit-copy"
  This warning requires both \fB\-fanalyzer\fR and the use of a plugin
! to specify a function that copies across a "trust boundary".  Use
  \&\fB\-Wno\-analyzer\-exposure\-through\-uninit\-copy\fR to disable it.
  .Sp
! This diagnostic warns for "infoleaks" \- paths through the code in which
  uninitialized values are copied across a security boundary
! (such as code within an OS kernel that copies a partially\-initialized
  struct on the stack to user space).
  .Sp
! See  CWE\-200: Exposure of Sensitive Information to an Unauthorized Actor (\f(CW\*(C`https://cwe.mitre.org/data/definitions/200.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-fd\-access\-mode\-mismatch\fR 4
  .IX Item "-Wno-analyzer-fd-access-mode-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-access\-mode\-mismatch\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through code in which a
! \&\f(CW\*(C`read\*(C'\fR on a write\-only file descriptor is attempted, or vice versa.
  .Sp
  This diagnostic also warns for code paths in a which a function with attribute
  \&\f(CW\*(C`fd_arg_read (N)\*(C'\fR is called with a file descriptor opened with
  \&\f(CW\*(C`O_WRONLY\*(C'\fR at referenced argument \f(CW\*(C`N\*(C'\fR or a function with attribute
  \&\f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a file descriptor opened with
  \&\f(CW\*(C`O_RDONLY\*(C'\fR at referenced argument \fIN\fR.
! .IP \fB\-Wno\-analyzer\-fd\-double\-close\fR 4
  .IX Item "-Wno-analyzer-fd-double-close"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-double\-close\fR
*************** to disable it.
*** 9624,9631 ****
  This diagnostic warns for paths through code in which a
  file descriptor can be closed more than once.
  .Sp
! See  \s-1CWE\-1341:\s0 Multiple Releases of Same Resource or Handle (\f(CW\*(C`https://cwe.mitre.org/data/definitions/1341.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-fd\-leak\fR" 4
  .IX Item "-Wno-analyzer-fd-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-leak\fR
--- 9553,9560 ----
  This diagnostic warns for paths through code in which a
  file descriptor can be closed more than once.
  .Sp
! See  CWE\-1341: Multiple Releases of Same Resource or Handle (\f(CW\*(C`https://cwe.mitre.org/data/definitions/1341.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-fd\-leak\fR 4
  .IX Item "-Wno-analyzer-fd-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-leak\fR
*************** to disable it.
*** 9634,9653 ****
  This diagnostic warns for paths through code in which an
  open file descriptor is leaked.
  .Sp
! See  \s-1CWE\-775:\s0 Missing Release of File Descriptor or Handle after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/775.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-fd\-phase\-mismatch\fR" 4
  .IX Item "-Wno-analyzer-fd-phase-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-phase\-mismatch\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through code in which an operation is
! attempted in the wrong phase of a file descriptor's lifetime.
  For example, it will warn on attempts to call \f(CW\*(C`accept\*(C'\fR on a stream
  socket that has not yet had \f(CW\*(C`listen\*(C'\fR successfully called on it.
  .Sp
! See  \s-1CWE\-666:\s0 Operation on Resource in Wrong Phase of Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/666.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-fd\-type\-mismatch\fR" 4
  .IX Item "-Wno-analyzer-fd-type-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-type\-mismatch\fR
--- 9563,9582 ----
  This diagnostic warns for paths through code in which an
  open file descriptor is leaked.
  .Sp
! See  CWE\-775: Missing Release of File Descriptor or Handle after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/775.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-fd\-phase\-mismatch\fR 4
  .IX Item "-Wno-analyzer-fd-phase-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-phase\-mismatch\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through code in which an operation is
! attempted in the wrong phase of a file descriptor\*(Aqs lifetime.
  For example, it will warn on attempts to call \f(CW\*(C`accept\*(C'\fR on a stream
  socket that has not yet had \f(CW\*(C`listen\*(C'\fR successfully called on it.
  .Sp
! See  CWE\-666: Operation on Resource in Wrong Phase of Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/666.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-fd\-type\-mismatch\fR 4
  .IX Item "-Wno-analyzer-fd-type-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-type\-mismatch\fR
*************** operation is attempted on the wrong type
*** 9658,9664 ****
  For example, it will warn on attempts to use socket operations
  on a file descriptor obtained via \f(CW\*(C`open\*(C'\fR, or when attempting
  to use a stream socket operation on a datagram socket.
! .IP "\fB\-Wno\-analyzer\-fd\-use\-after\-close\fR" 4
  .IX Item "-Wno-analyzer-fd-use-after-close"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-use\-after\-close\fR
--- 9587,9593 ----
  For example, it will warn on attempts to use socket operations
  on a file descriptor obtained via \f(CW\*(C`open\*(C'\fR, or when attempting
  to use a stream socket operation on a datagram socket.
! .IP \fB\-Wno\-analyzer\-fd\-use\-after\-close\fR 4
  .IX Item "-Wno-analyzer-fd-use-after-close"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-use\-after\-close\fR
*************** This diagnostic also warns for paths thr
*** 9671,9677 ****
  a function with attribute \f(CW\*(C`fd_arg (N)\*(C'\fR or \f(CW\*(C`fd_arg_read (N)\*(C'\fR
  or \f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a closed file descriptor at
  referenced argument \f(CW\*(C`N\*(C'\fR.
! .IP "\fB\-Wno\-analyzer\-fd\-use\-without\-check\fR" 4
  .IX Item "-Wno-analyzer-fd-use-without-check"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-use\-without\-check\fR
--- 9600,9606 ----
  a function with attribute \f(CW\*(C`fd_arg (N)\*(C'\fR or \f(CW\*(C`fd_arg_read (N)\*(C'\fR
  or \f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a closed file descriptor at
  referenced argument \f(CW\*(C`N\*(C'\fR.
! .IP \fB\-Wno\-analyzer\-fd\-use\-without\-check\fR 4
  .IX Item "-Wno-analyzer-fd-use-without-check"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-use\-without\-check\fR
*************** This diagnostic also warns for paths thr
*** 9684,9690 ****
  a function with attribute \f(CW\*(C`fd_arg (N)\*(C'\fR or \f(CW\*(C`fd_arg_read (N)\*(C'\fR
  or \f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a file descriptor, at referenced
  argument \f(CW\*(C`N\*(C'\fR, without being checked for validity.
! .IP "\fB\-Wno\-analyzer\-file\-leak\fR" 4
  .IX Item "-Wno-analyzer-file-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-file\-leak\fR
--- 9613,9619 ----
  a function with attribute \f(CW\*(C`fd_arg (N)\*(C'\fR or \f(CW\*(C`fd_arg_read (N)\*(C'\fR
  or \f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a file descriptor, at referenced
  argument \f(CW\*(C`N\*(C'\fR, without being checked for validity.
! .IP \fB\-Wno\-analyzer\-file\-leak\fR 4
  .IX Item "-Wno-analyzer-file-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-file\-leak\fR
*************** to disable it.
*** 9693,9720 ****
  This diagnostic warns for paths through the code in which a
  \&\f(CW\*(C`\*(C'\fR \f(CW\*(C`FILE *\*(C'\fR stream object is leaked.
  .Sp
! See  \s-1CWE\-775:\s0 Missing Release of File Descriptor or Handle after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/775.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-free\-of\-non\-heap\fR" 4
  .IX Item "-Wno-analyzer-free-of-non-heap"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-free\-of\-non\-heap\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through the code in which \f(CW\*(C`free\*(C'\fR
! is called on a non-heap pointer (e.g. an on-stack buffer, or a global).
  .Sp
! See  \s-1CWE\-590:\s0 Free of Memory not on the Heap (\f(CW\*(C`https://cwe.mitre.org/data/definitions/590.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-imprecise\-fp\-arithmetic\fR" 4
  .IX Item "-Wno-analyzer-imprecise-fp-arithmetic"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-imprecise\-fp\-arithmetic\fR
  to disable it.
  .Sp
! This diagnostic warns for paths through the code in which floating-point
  arithmetic is used in locations where precise computation is needed.  This
! diagnostic only warns on use of floating-point operands inside the
  calculation of an allocation size at the moment.
! .IP "\fB\-Wno\-analyzer\-infinite\-recursion\fR" 4
  .IX Item "-Wno-analyzer-infinite-recursion"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-infinite\-recursion\fR to disable it.
--- 9622,9649 ----
  This diagnostic warns for paths through the code in which a
  \&\f(CW\*(C`\*(C'\fR \f(CW\*(C`FILE *\*(C'\fR stream object is leaked.
  .Sp
! See  CWE\-775: Missing Release of File Descriptor or Handle after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/775.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-free\-of\-non\-heap\fR 4
  .IX Item "-Wno-analyzer-free-of-non-heap"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-free\-of\-non\-heap\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through the code in which \f(CW\*(C`free\*(C'\fR
! is called on a non\-heap pointer (e.g. an on\-stack buffer, or a global).
  .Sp
! See  CWE\-590: Free of Memory not on the Heap (\f(CW\*(C`https://cwe.mitre.org/data/definitions/590.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-imprecise\-fp\-arithmetic\fR 4
  .IX Item "-Wno-analyzer-imprecise-fp-arithmetic"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-imprecise\-fp\-arithmetic\fR
  to disable it.
  .Sp
! This diagnostic warns for paths through the code in which floating\-point
  arithmetic is used in locations where precise computation is needed.  This
! diagnostic only warns on use of floating\-point operands inside the
  calculation of an allocation size at the moment.
! .IP \fB\-Wno\-analyzer\-infinite\-recursion\fR 4
  .IX Item "-Wno-analyzer-infinite-recursion"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-infinite\-recursion\fR to disable it.
*************** This warning requires \fB\-fanalyzer\fR,
*** 9722,9728 ****
  This diagnostics warns for paths through the code which appear to
  lead to infinite recursion.
  .Sp
! Specifically, when the analyzer \*(L"sees\*(R" a recursive call, it will compare
  the state of memory at the entry to the new frame with that at the entry
  to the previous frame of that function on the stack.  The warning is
  issued if nothing in memory appears to be changing; any changes observed
--- 9651,9657 ----
  This diagnostics warns for paths through the code which appear to
  lead to infinite recursion.
  .Sp
! Specifically, when the analyzer "sees" a recursive call, it will compare
  the state of memory at the entry to the new frame with that at the entry
  to the previous frame of that function on the stack.  The warning is
  issued if nothing in memory appears to be changing; any changes observed
*************** to parameters or globals are assumed to
*** 9730,9742 ****
  recursion and thus suppress the warning.
  .Sp
  This diagnostic is likely to miss cases of infinite recursion that
! are convered to iteration by the optimizer before the analyzer \*(L"sees\*(R"
  them.  Hence optimization should be disabled when attempting to trigger
  this diagnostic.
  .Sp
  Compare with \fB\-Winfinite\-recursion\fR, which provides a similar
  diagnostic, but is implemented in a different way.
! .IP "\fB\-Wno\-analyzer\-jump\-through\-null\fR" 4
  .IX Item "-Wno-analyzer-jump-through-null"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-jump\-through\-null\fR
--- 9659,9671 ----
  recursion and thus suppress the warning.
  .Sp
  This diagnostic is likely to miss cases of infinite recursion that
! are convered to iteration by the optimizer before the analyzer "sees"
  them.  Hence optimization should be disabled when attempting to trigger
  this diagnostic.
  .Sp
  Compare with \fB\-Winfinite\-recursion\fR, which provides a similar
  diagnostic, but is implemented in a different way.
! .IP \fB\-Wno\-analyzer\-jump\-through\-null\fR 4
  .IX Item "-Wno-analyzer-jump-through-null"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-jump\-through\-null\fR
*************** to disable it.
*** 9744,9750 ****
  .Sp
  This diagnostic warns for paths through the code in which a \f(CW\*(C`NULL\*(C'\fR
  function pointer is called.
! .IP "\fB\-Wno\-analyzer\-malloc\-leak\fR" 4
  .IX Item "-Wno-analyzer-malloc-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-malloc\-leak\fR
--- 9673,9679 ----
  .Sp
  This diagnostic warns for paths through the code in which a \f(CW\*(C`NULL\*(C'\fR
  function pointer is called.
! .IP \fB\-Wno\-analyzer\-malloc\-leak\fR 4
  .IX Item "-Wno-analyzer-malloc-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-malloc\-leak\fR
*************** This diagnostic warns for paths through
*** 9754,9761 ****
  pointer allocated via an allocator is leaked: either \f(CW\*(C`malloc\*(C'\fR,
  or a function marked with attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  \s-1CWE\-401:\s0 Missing Release of Memory after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/401.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-mismatching\-deallocation\fR" 4
  .IX Item "-Wno-analyzer-mismatching-deallocation"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-mismatching\-deallocation\fR
--- 9683,9690 ----
  pointer allocated via an allocator is leaked: either \f(CW\*(C`malloc\*(C'\fR,
  or a function marked with attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  CWE\-401: Missing Release of Memory after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/401.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-mismatching\-deallocation\fR 4
  .IX Item "-Wno-analyzer-mismatching-deallocation"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-mismatching\-deallocation\fR
*************** will warn about mismatches between \f(CW
*** 9768,9838 ****
  and vector \f(CW\*(C`delete[]\*(C'\fR, and those marked as allocator/deallocator
  pairs using attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  \s-1CWE\-762:\s0 Mismatched Memory Management Routines (\f(CW\*(C`https://cwe.mitre.org/data/definitions/762.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-out\-of\-bounds\fR" 4
  .IX Item "-Wno-analyzer-out-of-bounds"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-out\-of\-bounds\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a buffer is
! definitely read or written out-of-bounds.  The diagnostic applies for
  cases where the analyzer is able to determine a constant offset and for
  accesses past the end of a buffer, also a constant capacity.  Further,
  the diagnostic does limited checking for accesses past the end when the
  offset as well as the capacity is symbolic.
  .Sp
! See  \s-1CWE\-119:\s0 Improper Restriction of Operations within the Bounds of a Memory Buffer (\f(CW\*(C`https://cwe.mitre.org/data/definitions/119.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-possible\-null\-argument\fR" 4
  .IX Item "-Wno-analyzer-possible-null-argument"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-possible\-null\-argument\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! possibly-NULL value is passed to a function argument marked
! with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non-NULL
  value.
  .Sp
! See  \s-1CWE\-690:\s0 Unchecked Return Value to \s-1NULL\s0 Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/690.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-possible\-null\-dereference\fR" 4
  .IX Item "-Wno-analyzer-possible-null-dereference"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-possible\-null\-dereference\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! possibly-NULL value is dereferenced.
  .Sp
! See  \s-1CWE\-690:\s0 Unchecked Return Value to \s-1NULL\s0 Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/690.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-null\-argument\fR" 4
  .IX Item "-Wno-analyzer-null-argument"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-null\-argument\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! value known to be \s-1NULL\s0 is passed to a function argument marked
! with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non-NULL
  value.
  .Sp
! See  \s-1CWE\-476: NULL\s0 Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/476.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-null\-dereference\fR" 4
  .IX Item "-Wno-analyzer-null-dereference"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-null\-dereference\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! value known to be \s-1NULL\s0 is dereferenced.
  .Sp
! See  \s-1CWE\-476: NULL\s0 Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/476.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-putenv\-of\-auto\-var\fR" 4
  .IX Item "-Wno-analyzer-putenv-of-auto-var"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-putenv\-of\-auto\-var\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
  call to \f(CW\*(C`putenv\*(C'\fR is passed a pointer to an automatic variable
! or an on-stack buffer.
  .Sp
! See  \s-1POS34\-C.\s0 Do not call \fBputenv()\fR with a pointer to an automatic variable as the argument (\f(CW\*(C`https://wiki.sei.cmu.edu/confluence/x/6NYxBQ\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-shift\-count\-negative\fR" 4
  .IX Item "-Wno-analyzer-shift-count-negative"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-shift\-count\-negative\fR to disable it.
--- 9697,9767 ----
  and vector \f(CW\*(C`delete[]\*(C'\fR, and those marked as allocator/deallocator
  pairs using attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  CWE\-762: Mismatched Memory Management Routines (\f(CW\*(C`https://cwe.mitre.org/data/definitions/762.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-out\-of\-bounds\fR 4
  .IX Item "-Wno-analyzer-out-of-bounds"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-out\-of\-bounds\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a buffer is
! definitely read or written out\-of\-bounds.  The diagnostic applies for
  cases where the analyzer is able to determine a constant offset and for
  accesses past the end of a buffer, also a constant capacity.  Further,
  the diagnostic does limited checking for accesses past the end when the
  offset as well as the capacity is symbolic.
  .Sp
! See  CWE\-119: Improper Restriction of Operations within the Bounds of a Memory Buffer (\f(CW\*(C`https://cwe.mitre.org/data/definitions/119.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-possible\-null\-argument\fR 4
  .IX Item "-Wno-analyzer-possible-null-argument"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-possible\-null\-argument\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! possibly\-NULL value is passed to a function argument marked
! with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non\-NULL
  value.
  .Sp
! See  CWE\-690: Unchecked Return Value to NULL Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/690.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-possible\-null\-dereference\fR 4
  .IX Item "-Wno-analyzer-possible-null-dereference"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-possible\-null\-dereference\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! possibly\-NULL value is dereferenced.
  .Sp
! See  CWE\-690: Unchecked Return Value to NULL Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/690.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-null\-argument\fR 4
  .IX Item "-Wno-analyzer-null-argument"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-null\-argument\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! value known to be NULL is passed to a function argument marked
! with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non\-NULL
  value.
  .Sp
! See  CWE\-476: NULL Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/476.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-null\-dereference\fR 4
  .IX Item "-Wno-analyzer-null-dereference"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-null\-dereference\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! value known to be NULL is dereferenced.
  .Sp
! See  CWE\-476: NULL Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/476.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-putenv\-of\-auto\-var\fR 4
  .IX Item "-Wno-analyzer-putenv-of-auto-var"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-putenv\-of\-auto\-var\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
  call to \f(CW\*(C`putenv\*(C'\fR is passed a pointer to an automatic variable
! or an on\-stack buffer.
  .Sp
! See  POS34\-C. Do not call \fBputenv()\fR with a pointer to an automatic variable as the argument (\f(CW\*(C`https://wiki.sei.cmu.edu/confluence/x/6NYxBQ\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-shift\-count\-negative\fR 4
  .IX Item "-Wno-analyzer-shift-count-negative"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-shift\-count\-negative\fR to disable it.
*************** This warning requires \fB\-fanalyzer\fR,
*** 9840,9863 ****
  This diagnostic warns for paths through the code in which a
  shift is attempted with a negative count.  It is analogous to
  the \fB\-Wshift\-count\-negative\fR diagnostic implemented in
! the C/\*(C+ front ends, but is implemented based on analyzing
  interprocedural paths, rather than merely parsing the syntax tree.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP "\fB\-Wno\-analyzer\-shift\-count\-overflow\fR" 4
  .IX Item "-Wno-analyzer-shift-count-overflow"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-shift\-count\-overflow\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
  shift is attempted with a count greater than or equal to the
! precision of the operand's type.  It is analogous to
  the \fB\-Wshift\-count\-overflow\fR diagnostic implemented in
! the C/\*(C+ front ends, but is implemented based on analyzing
  interprocedural paths, rather than merely parsing the syntax tree.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP "\fB\-Wno\-analyzer\-stale\-setjmp\-buffer\fR" 4
  .IX Item "-Wno-analyzer-stale-setjmp-buffer"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-stale\-setjmp\-buffer\fR to disable it.
--- 9769,9792 ----
  This diagnostic warns for paths through the code in which a
  shift is attempted with a negative count.  It is analogous to
  the \fB\-Wshift\-count\-negative\fR diagnostic implemented in
! the C/C++ front ends, but is implemented based on analyzing
  interprocedural paths, rather than merely parsing the syntax tree.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP \fB\-Wno\-analyzer\-shift\-count\-overflow\fR 4
  .IX Item "-Wno-analyzer-shift-count-overflow"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-shift\-count\-overflow\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
  shift is attempted with a count greater than or equal to the
! precision of the operand\*(Aqs type.  It is analogous to
  the \fB\-Wshift\-count\-overflow\fR diagnostic implemented in
! the C/C++ front ends, but is implemented based on analyzing
  interprocedural paths, rather than merely parsing the syntax tree.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP \fB\-Wno\-analyzer\-stale\-setjmp\-buffer\fR 4
  .IX Item "-Wno-analyzer-stale-setjmp-buffer"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-stale\-setjmp\-buffer\fR to disable it.
*************** location, it records the stack frame.  T
*** 9871,9897 ****
  when the function containing the \f(CW\*(C`setjmp\*(C'\fR call returns.  Attempting
  to rewind to it via \f(CW\*(C`longjmp\*(C'\fR would reference a stack frame that
  no longer exists, and likely lead to a crash (or worse).
! .IP "\fB\-Wno\-analyzer\-tainted\-allocation\-size\fR" 4
  .IX Item "-Wno-analyzer-tainted-allocation-size"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-allocation\-size\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as the size
  of an allocation without being sanitized, so that an attacker could
  inject an excessively large allocation and potentially cause a denial
  of service attack.
  .Sp
! See  \s-1CWE\-789:\s0 Memory Allocation with Excessive Size Value (\f(CW\*(C`https://cwe.mitre.org/data/definitions/789.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-tainted\-assertion\fR" 4
  .IX Item "-Wno-analyzer-tainted-assertion"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-assertion\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as part of a
  condition without being first sanitized, and that condition guards a
  call to a function marked with attribute \f(CW\*(C`noreturn\*(C'\fR
  (such as the function \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR).  Such functions
--- 9800,9826 ----
  when the function containing the \f(CW\*(C`setjmp\*(C'\fR call returns.  Attempting
  to rewind to it via \f(CW\*(C`longjmp\*(C'\fR would reference a stack frame that
  no longer exists, and likely lead to a crash (or worse).
! .IP \fB\-Wno\-analyzer\-tainted\-allocation\-size\fR 4
  .IX Item "-Wno-analyzer-tainted-allocation-size"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-allocation\-size\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as the size
  of an allocation without being sanitized, so that an attacker could
  inject an excessively large allocation and potentially cause a denial
  of service attack.
  .Sp
! See  CWE\-789: Memory Allocation with Excessive Size Value (\f(CW\*(C`https://cwe.mitre.org/data/definitions/789.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-tainted\-assertion\fR 4
  .IX Item "-Wno-analyzer-tainted-assertion"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-assertion\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as part of a
  condition without being first sanitized, and that condition guards a
  call to a function marked with attribute \f(CW\*(C`noreturn\*(C'\fR
  (such as the function \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR).  Such functions
*************** assertion failure handlers.  For example
*** 9904,9932 ****
  .Sp
  In such cases:
  .RS 4
! .IP "*" 4
! when assertion-checking is enabled: an attacker could trigger
  a denial of service by injecting an assertion failure
! .IP "*" 4
! when assertion-checking is disabled, such as by defining \f(CW\*(C`NDEBUG\*(C'\fR,
  an attacker could inject data that subverts the process, since it
  presumably violates a precondition that is being assumed by the code.
  .RE
  .RS 4
  .Sp
! Note that when assertion-checking is disabled, the assertions are
  typically removed by the preprocessor before the analyzer has a chance
! to \*(L"see\*(R" them, so this diagnostic can only generate warnings on builds
! in which assertion-checking is enabled.
  .Sp
  For the purpose of this warning, any function marked with attribute
  \&\f(CW\*(C`noreturn\*(C'\fR is considered as a possible assertion failure
  handler, including \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR.  Note that these functions
! are sometimes removed by the optimizer before the analyzer \*(L"sees\*(R" them.
  Hence optimization should be disabled when attempting to trigger this
  diagnostic.
  .Sp
! See  \s-1CWE\-617:\s0 Reachable Assertion (\f(CW\*(C`https://cwe.mitre.org/data/definitions/617.html\*(C'\fR).
  .Sp
  The warning can also report problematic constructions such as
  .Sp
--- 9833,9861 ----
  .Sp
  In such cases:
  .RS 4
! .IP * 4
! when assertion\-checking is enabled: an attacker could trigger
  a denial of service by injecting an assertion failure
! .IP * 4
! when assertion\-checking is disabled, such as by defining \f(CW\*(C`NDEBUG\*(C'\fR,
  an attacker could inject data that subverts the process, since it
  presumably violates a precondition that is being assumed by the code.
  .RE
  .RS 4
  .Sp
! Note that when assertion\-checking is disabled, the assertions are
  typically removed by the preprocessor before the analyzer has a chance
! to "see" them, so this diagnostic can only generate warnings on builds
! in which assertion\-checking is enabled.
  .Sp
  For the purpose of this warning, any function marked with attribute
  \&\f(CW\*(C`noreturn\*(C'\fR is considered as a possible assertion failure
  handler, including \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR.  Note that these functions
! are sometimes removed by the optimizer before the analyzer "sees" them.
  Hence optimization should be disabled when attempting to trigger this
  diagnostic.
  .Sp
! See  CWE\-617: Reachable Assertion (\f(CW\*(C`https://cwe.mitre.org/data/definitions/617.html\*(C'\fR).
  .Sp
  The warning can also report problematic constructions such as
  .Sp
*************** The warning can also report problematic
*** 9943,10007 ****
  .Sp
  despite the above not being an assertion failure, strictly speaking.
  .RE
! .IP "\fB\-Wno\-analyzer\-tainted\-array\-index\fR" 4
  .IX Item "-Wno-analyzer-tainted-array-index"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-array\-index\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as the index
  of an array access without being sanitized, so that an attacker
! could inject an out-of-bounds access.
  .Sp
! See  \s-1CWE\-129:\s0 Improper Validation of Array Index (\f(CW\*(C`https://cwe.mitre.org/data/definitions/129.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-tainted\-divisor\fR" 4
  .IX Item "-Wno-analyzer-tainted-divisor"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-divisor\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as the divisor
  in a division or modulus operation without being sanitized, so that
! an attacker could inject a division-by-zero.
  .Sp
! See  \s-1CWE\-369:\s0 Divide By Zero (\f(CW\*(C`https://cwe.mitre.org/data/definitions/369.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-tainted\-offset\fR" 4
  .IX Item "-Wno-analyzer-tainted-offset"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-offset\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as a pointer offset
! without being sanitized, so that an attacker could inject an out-of-bounds
  access.
  .Sp
! See  \s-1CWE\-823:\s0 Use of Out-of-range Pointer Offset (\f(CW\*(C`https://cwe.mitre.org/data/definitions/823.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-tainted\-size\fR" 4
  .IX Item "-Wno-analyzer-tainted-size"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-size\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as the size of
  an operation such as \f(CW\*(C`memset\*(C'\fR without being sanitized, so that an
! attacker could inject an out-of-bounds access.
  .Sp
! See  \s-1CWE\-129:\s0 Improper Validation of Array Index (\f(CW\*(C`https://cwe.mitre.org/data/definitions/129.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-unsafe\-call\-within\-signal\-handler\fR" 4
  .IX Item "-Wno-analyzer-unsafe-call-within-signal-handler"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-unsafe\-call\-within\-signal\-handler\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! function known to be async-signal-unsafe (such as \f(CW\*(C`fprintf\*(C'\fR) is
  called from a signal handler.
  .Sp
! See  \s-1CWE\-479:\s0 Signal Handler Use of a Non-reentrant Function (\f(CW\*(C`https://cwe.mitre.org/data/definitions/479.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-use\-after\-free\fR" 4
  .IX Item "-Wno-analyzer-use-after-free"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-after\-free\fR to disable it.
--- 9872,9936 ----
  .Sp
  despite the above not being an assertion failure, strictly speaking.
  .RE
! .IP \fB\-Wno\-analyzer\-tainted\-array\-index\fR 4
  .IX Item "-Wno-analyzer-tainted-array-index"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-array\-index\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as the index
  of an array access without being sanitized, so that an attacker
! could inject an out\-of\-bounds access.
  .Sp
! See  CWE\-129: Improper Validation of Array Index (\f(CW\*(C`https://cwe.mitre.org/data/definitions/129.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-tainted\-divisor\fR 4
  .IX Item "-Wno-analyzer-tainted-divisor"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-divisor\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as the divisor
  in a division or modulus operation without being sanitized, so that
! an attacker could inject a division\-by\-zero.
  .Sp
! See  CWE\-369: Divide By Zero (\f(CW\*(C`https://cwe.mitre.org/data/definitions/369.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-tainted\-offset\fR 4
  .IX Item "-Wno-analyzer-tainted-offset"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-offset\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as a pointer offset
! without being sanitized, so that an attacker could inject an out\-of\-bounds
  access.
  .Sp
! See  CWE\-823: Use of Out\-of\-range Pointer Offset (\f(CW\*(C`https://cwe.mitre.org/data/definitions/823.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-tainted\-size\fR 4
  .IX Item "-Wno-analyzer-tainted-size"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-size\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as the size of
  an operation such as \f(CW\*(C`memset\*(C'\fR without being sanitized, so that an
! attacker could inject an out\-of\-bounds access.
  .Sp
! See  CWE\-129: Improper Validation of Array Index (\f(CW\*(C`https://cwe.mitre.org/data/definitions/129.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-unsafe\-call\-within\-signal\-handler\fR 4
  .IX Item "-Wno-analyzer-unsafe-call-within-signal-handler"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-unsafe\-call\-within\-signal\-handler\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! function known to be async\-signal\-unsafe (such as \f(CW\*(C`fprintf\*(C'\fR) is
  called from a signal handler.
  .Sp
! See  CWE\-479: Signal Handler Use of a Non\-reentrant Function (\f(CW\*(C`https://cwe.mitre.org/data/definitions/479.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-use\-after\-free\fR 4
  .IX Item "-Wno-analyzer-use-after-free"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-after\-free\fR to disable it.
*************** This diagnostic warns for paths through
*** 10010,10017 ****
  pointer is used after a deallocator is called on it: either \f(CW\*(C`free\*(C'\fR,
  or a deallocator referenced by attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  \s-1CWE\-416:\s0 Use After Free (\f(CW\*(C`https://cwe.mitre.org/data/definitions/416.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR" 4
  .IX Item "-Wno-analyzer-use-of-pointer-in-stale-stack-frame"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR
--- 9939,9946 ----
  pointer is used after a deallocator is called on it: either \f(CW\*(C`free\*(C'\fR,
  or a deallocator referenced by attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  CWE\-416: Use After Free (\f(CW\*(C`https://cwe.mitre.org/data/definitions/416.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR 4
  .IX Item "-Wno-analyzer-use-of-pointer-in-stale-stack-frame"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR
*************** to disable it.
*** 10019,10025 ****
  .Sp
  This diagnostic warns for paths through the code in which a pointer
  is dereferenced that points to a variable in a stale stack frame.
! .IP "\fB\-Wno\-analyzer\-va\-arg\-type\-mismatch\fR" 4
  .IX Item "-Wno-analyzer-va-arg-type-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-arg\-type\-mismatch\fR
--- 9948,9954 ----
  .Sp
  This diagnostic warns for paths through the code in which a pointer
  is dereferenced that points to a variable in a stale stack frame.
! .IP \fB\-Wno\-analyzer\-va\-arg\-type\-mismatch\fR 4
  .IX Item "-Wno-analyzer-va-arg-type-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-arg\-type\-mismatch\fR
*************** the analyzer detects an attempt to use \
*** 10030,10037 ****
  passed to a variadic call, but uses a type that does not match that of
  the expression passed to the call.
  .Sp
! See  \s-1CWE\-686:\s0 Function Call With Incorrect Argument Type (\f(CW\*(C`https://cwe.mitre.org/data/definitions/686.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-va\-list\-exhausted\fR" 4
  .IX Item "-Wno-analyzer-va-list-exhausted"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-exhausted\fR
--- 9959,9966 ----
  passed to a variadic call, but uses a type that does not match that of
  the expression passed to the call.
  .Sp
! See  CWE\-686: Function Call With Incorrect Argument Type (\f(CW\*(C`https://cwe.mitre.org/data/definitions/686.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-va\-list\-exhausted\fR 4
  .IX Item "-Wno-analyzer-va-list-exhausted"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-exhausted\fR
*************** the analyzer detects an attempt to use \
*** 10042,10049 ****
  value passed to a variadic call, but all of the values in the
  \&\f(CW\*(C`va_list\*(C'\fR have already been consumed.
  .Sp
! See  \s-1CWE\-685:\s0 Function Call With Incorrect Number of Arguments (\f(CW\*(C`https://cwe.mitre.org/data/definitions/685.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-va\-list\-leak\fR" 4
  .IX Item "-Wno-analyzer-va-list-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-leak\fR
--- 9971,9978 ----
  value passed to a variadic call, but all of the values in the
  \&\f(CW\*(C`va_list\*(C'\fR have already been consumed.
  .Sp
! See  CWE\-685: Function Call With Incorrect Number of Arguments (\f(CW\*(C`https://cwe.mitre.org/data/definitions/685.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-va\-list\-leak\fR 4
  .IX Item "-Wno-analyzer-va-list-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-leak\fR
*************** to disable it.
*** 10052,10058 ****
  This diagnostic warns for interprocedural paths through the code for which
  the analyzer detects that \f(CW\*(C`va_start\*(C'\fR or \f(CW\*(C`va_copy\*(C'\fR has been called
  on a \f(CW\*(C`va_list\*(C'\fR without a corresponding call to \f(CW\*(C`va_end\*(C'\fR.
! .IP "\fB\-Wno\-analyzer\-va\-list\-use\-after\-va\-end\fR" 4
  .IX Item "-Wno-analyzer-va-list-use-after-va-end"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-use\-after\-va\-end\fR
--- 9981,9987 ----
  This diagnostic warns for interprocedural paths through the code for which
  the analyzer detects that \f(CW\*(C`va_start\*(C'\fR or \f(CW\*(C`va_copy\*(C'\fR has been called
  on a \f(CW\*(C`va_list\*(C'\fR without a corresponding call to \f(CW\*(C`va_end\*(C'\fR.
! .IP \fB\-Wno\-analyzer\-va\-list\-use\-after\-va\-end\fR 4
  .IX Item "-Wno-analyzer-va-list-use-after-va-end"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-use\-after\-va\-end\fR
*************** This diagnostic warns for interprocedura
*** 10062,10068 ****
  the analyzer detects an attempt to use a \f(CW\*(C`va_list\*(C'\fR  after
  \&\f(CW\*(C`va_end\*(C'\fR has been called on it.
  \&\f(CW\*(C`va_list\*(C'\fR.
! .IP "\fB\-Wno\-analyzer\-write\-to\-const\fR" 4
  .IX Item "-Wno-analyzer-write-to-const"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-write\-to\-const\fR
--- 9991,9997 ----
  the analyzer detects an attempt to use a \f(CW\*(C`va_list\*(C'\fR  after
  \&\f(CW\*(C`va_end\*(C'\fR has been called on it.
  \&\f(CW\*(C`va_list\*(C'\fR.
! .IP \fB\-Wno\-analyzer\-write\-to\-const\fR 4
  .IX Item "-Wno-analyzer-write-to-const"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-write\-to\-const\fR
*************** This diagnostic warns for paths through
*** 10072,10078 ****
  detects an attempt to write through a pointer to a \f(CW\*(C`const\*(C'\fR object.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP "\fB\-Wno\-analyzer\-write\-to\-string\-literal\fR" 4
  .IX Item "-Wno-analyzer-write-to-string-literal"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-write\-to\-string\-literal\fR
--- 10001,10007 ----
  detects an attempt to write through a pointer to a \f(CW\*(C`const\*(C'\fR object.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP \fB\-Wno\-analyzer\-write\-to\-string\-literal\fR 4
  .IX Item "-Wno-analyzer-write-to-string-literal"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-write\-to\-string\-literal\fR
*************** This diagnostic warns for paths through
*** 10082,10088 ****
  detects an attempt to write through a pointer to a string literal.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP "\fB\-Wno\-analyzer\-use\-of\-uninitialized\-value\fR" 4
  .IX Item "-Wno-analyzer-use-of-uninitialized-value"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-of\-uninitialized\-value\fR to disable it.
--- 10011,10017 ----
  detects an attempt to write through a pointer to a string literal.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP \fB\-Wno\-analyzer\-use\-of\-uninitialized\-value\fR 4
  .IX Item "-Wno-analyzer-use-of-uninitialized-value"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-of\-uninitialized\-value\fR to disable it.
*************** This warning requires \fB\-fanalyzer\fR,
*** 10090,10105 ****
  This diagnostic warns for paths through the code in which an uninitialized
  value is used.
  .Sp
! See  \s-1CWE\-457:\s0 Use of Uninitialized Variable (\f(CW\*(C`https://cwe.mitre.org/data/definitions/457.html\*(C'\fR).
  .PP
  The analyzer has hardcoded knowledge about the behavior of the following
! memory-management functions:
  .ie n .IP "*<""alloca"">" 4
! .el .IP "*<\f(CWalloca\fR>" 4
  .IX Item "*"
  .PD 0
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  .PD
  \&\f(CW\*(C`_\|_builtin_alloc_with_align\*(C'\fR, \f(CW@item\fR \f(CW\*(C`_\|_builtin_calloc\*(C'\fR,
--- 10019,10034 ----
  This diagnostic warns for paths through the code in which an uninitialized
  value is used.
  .Sp
! See  CWE\-457: Use of Uninitialized Variable (\f(CW\*(C`https://cwe.mitre.org/data/definitions/457.html\*(C'\fR).
  .PP
  The analyzer has hardcoded knowledge about the behavior of the following
! memory\-management functions:
  .ie n .IP "*<""alloca"">" 4
! .el .IP *<\f(CWalloca\fR> 4
  .IX Item "*"
  .PD 0
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  .PD
  \&\f(CW\*(C`_\|_builtin_alloc_with_align\*(C'\fR, \f(CW@item\fR \f(CW\*(C`_\|_builtin_calloc\*(C'\fR,
*************** memory-management functions:
*** 10108,10124 ****
  \&\f(CW\*(C`_\|_builtin_memset_chk\*(C'\fR, \f(CW\*(C`_\|_builtin_realloc\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_stack_restore\*(C'\fR, and \f(CW\*(C`_\|_builtin_stack_save\*(C'\fR
  .ie n .IP "*<""calloc"">" 4
! .el .IP "*<\f(CWcalloc\fR>" 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""free"">" 4
! .el .IP "*<\f(CWfree\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""malloc"">" 4
! .el .IP "*<\f(CWmalloc\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""memset"">" 4
! .el .IP "*<\f(CWmemset\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""operator delete"">" 4
  .el .IP "*<\f(CWoperator delete\fR>" 4
--- 10037,10053 ----
  \&\f(CW\*(C`_\|_builtin_memset_chk\*(C'\fR, \f(CW\*(C`_\|_builtin_realloc\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_stack_restore\*(C'\fR, and \f(CW\*(C`_\|_builtin_stack_save\*(C'\fR
  .ie n .IP "*<""calloc"">" 4
! .el .IP *<\f(CWcalloc\fR> 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""free"">" 4
! .el .IP *<\f(CWfree\fR> 4
  .IX Item "*"
  .ie n .IP "*<""malloc"">" 4
! .el .IP *<\f(CWmalloc\fR> 4
  .IX Item "*"
  .ie n .IP "*<""memset"">" 4
! .el .IP *<\f(CWmemset\fR> 4
  .IX Item "*"
  .ie n .IP "*<""operator delete"">" 4
  .el .IP "*<\f(CWoperator delete\fR>" 4
*************** memory-management functions:
*** 10133,10173 ****
  .el .IP "*<\f(CWoperator new []\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""realloc"">" 4
! .el .IP "*<\f(CWrealloc\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""strdup"">" 4
! .el .IP "*<\f(CWstrdup\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""strndup"">" 4
! .el .IP "*<\f(CWstrndup\fR>" 4
  .IX Item "*"
  .PD
  .PP
  of the following functions for working with file descriptors:
  .ie n .IP "*<""open"">" 4
! .el .IP "*<\f(CWopen\fR>" 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""close"">" 4
! .el .IP "*<\f(CWclose\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""creat"">" 4
! .el .IP "*<\f(CWcreat\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""dup"", ""dup2"" and ""dup3"">" 4
  .el .IP "*<\f(CWdup\fR, \f(CWdup2\fR and \f(CWdup3\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""isatty"">" 4
! .el .IP "*<\f(CWisatty\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""pipe"", and ""pipe2"">" 4
  .el .IP "*<\f(CWpipe\fR, and \f(CWpipe2\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""read"">" 4
! .el .IP "*<\f(CWread\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""write"">" 4
! .el .IP "*<\f(CWwrite\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""socket"", ""bind"", ""listen"", ""accept"", and ""connect"">" 4
  .el .IP "*<\f(CWsocket\fR, \f(CWbind\fR, \f(CWlisten\fR, \f(CWaccept\fR, and \f(CWconnect\fR>" 4
--- 10062,10102 ----
  .el .IP "*<\f(CWoperator new []\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""realloc"">" 4
! .el .IP *<\f(CWrealloc\fR> 4
  .IX Item "*"
  .ie n .IP "*<""strdup"">" 4
! .el .IP *<\f(CWstrdup\fR> 4
  .IX Item "*"
  .ie n .IP "*<""strndup"">" 4
! .el .IP *<\f(CWstrndup\fR> 4
  .IX Item "*"
  .PD
  .PP
  of the following functions for working with file descriptors:
  .ie n .IP "*<""open"">" 4
! .el .IP *<\f(CWopen\fR> 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""close"">" 4
! .el .IP *<\f(CWclose\fR> 4
  .IX Item "*"
  .ie n .IP "*<""creat"">" 4
! .el .IP *<\f(CWcreat\fR> 4
  .IX Item "*"
  .ie n .IP "*<""dup"", ""dup2"" and ""dup3"">" 4
  .el .IP "*<\f(CWdup\fR, \f(CWdup2\fR and \f(CWdup3\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""isatty"">" 4
! .el .IP *<\f(CWisatty\fR> 4
  .IX Item "*"
  .ie n .IP "*<""pipe"", and ""pipe2"">" 4
  .el .IP "*<\f(CWpipe\fR, and \f(CWpipe2\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""read"">" 4
! .el .IP *<\f(CWread\fR> 4
  .IX Item "*"
  .ie n .IP "*<""write"">" 4
! .el .IP *<\f(CWwrite\fR> 4
  .IX Item "*"
  .ie n .IP "*<""socket"", ""bind"", ""listen"", ""accept"", and ""connect"">" 4
  .el .IP "*<\f(CWsocket\fR, \f(CWbind\fR, \f(CWlisten\fR, \f(CWaccept\fR, and \f(CWconnect\fR>" 4
*************** of the following functions for working w
*** 10175,10182 ****
  .PD
  .PP
  of the following functions for working with \f(CW\*(C`\*(C'\fR streams:
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  \&\f(CW\*(C`_\|_builtin_fprintf_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_fputc\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_fputc_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_fputs\*(C'\fR,
--- 10104,10111 ----
  .PD
  .PP
  of the following functions for working with \f(CW\*(C`\*(C'\fR streams:
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  \&\f(CW\*(C`_\|_builtin_fprintf_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_fputc\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_fputc_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_fputs\*(C'\fR,
*************** of the following functions for working w
*** 10188,10274 ****
  \&\f(CW\*(C`_\|_builtin_puts_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_vfprintf\*(C'\fR, and
  \&\f(CW\*(C`_\|_builtin_vprintf\*(C'\fR
  .ie n .IP "*<""fopen"">" 4
! .el .IP "*<\f(CWfopen\fR>" 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""fclose"">" 4
! .el .IP "*<\f(CWfclose\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""ferror"">" 4
! .el .IP "*<\f(CWferror\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fgets"">" 4
! .el .IP "*<\f(CWfgets\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fgets_unlocked"">" 4
! .el .IP "*<\f(CWfgets_unlocked\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fileno"">" 4
! .el .IP "*<\f(CWfileno\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fread"">" 4
! .el .IP "*<\f(CWfread\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""getc"">" 4
! .el .IP "*<\f(CWgetc\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""getchar"">" 4
! .el .IP "*<\f(CWgetchar\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fprintf"">" 4
! .el .IP "*<\f(CWfprintf\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""printf"">" 4
! .el .IP "*<\f(CWprintf\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fwrite"">" 4
! .el .IP "*<\f(CWfwrite\fR>" 4
  .IX Item "*"
  .PD
  .PP
  and of the following functions:
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  \&\f(CW\*(C`_\|_builtin_expect_with_probability\*(C'\fR, \f(CW\*(C`_\|_builtin_strchr\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_strcpy\*(C'\fR, \f(CW\*(C`_\|_builtin_strcpy_chk\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_strlen\*(C'\fR, \f(CW\*(C`_\|_builtin_va_copy\*(C'\fR, and
  \&\f(CW\*(C`_\|_builtin_va_start\*(C'\fR
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""getpass"">" 4
! .el .IP "*<\f(CWgetpass\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""longjmp"">" 4
! .el .IP "*<\f(CWlongjmp\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""putenv"">" 4
! .el .IP "*<\f(CWputenv\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""setjmp"">" 4
! .el .IP "*<\f(CWsetjmp\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""siglongjmp"">" 4
! .el .IP "*<\f(CWsiglongjmp\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""signal"">" 4
! .el .IP "*<\f(CWsignal\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""sigsetjmp"">" 4
! .el .IP "*<\f(CWsigsetjmp\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""strchr"">" 4
! .el .IP "*<\f(CWstrchr\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""strlen"">" 4
! .el .IP "*<\f(CWstrlen\fR>" 4
  .IX Item "*"
  .PD
  .PP
  In addition, various functions with an \f(CW\*(C`_\|_analyzer_\*(C'\fR prefix have
! special meaning to the analyzer, described in the \s-1GCC\s0 Internals manual.
  .PP
  Pertinent parameters for controlling the exploration are:
  .IP "*<\fB\-\-param analyzer\-bb\-explosion\-factor=\fR\fIvalue\fR>" 4
--- 10117,10203 ----
  \&\f(CW\*(C`_\|_builtin_puts_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_vfprintf\*(C'\fR, and
  \&\f(CW\*(C`_\|_builtin_vprintf\*(C'\fR
  .ie n .IP "*<""fopen"">" 4
! .el .IP *<\f(CWfopen\fR> 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""fclose"">" 4
! .el .IP *<\f(CWfclose\fR> 4
  .IX Item "*"
  .ie n .IP "*<""ferror"">" 4
! .el .IP *<\f(CWferror\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fgets"">" 4
! .el .IP *<\f(CWfgets\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fgets_unlocked"">" 4
! .el .IP *<\f(CWfgets_unlocked\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fileno"">" 4
! .el .IP *<\f(CWfileno\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fread"">" 4
! .el .IP *<\f(CWfread\fR> 4
  .IX Item "*"
  .ie n .IP "*<""getc"">" 4
! .el .IP *<\f(CWgetc\fR> 4
  .IX Item "*"
  .ie n .IP "*<""getchar"">" 4
! .el .IP *<\f(CWgetchar\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fprintf"">" 4
! .el .IP *<\f(CWfprintf\fR> 4
  .IX Item "*"
  .ie n .IP "*<""printf"">" 4
! .el .IP *<\f(CWprintf\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fwrite"">" 4
! .el .IP *<\f(CWfwrite\fR> 4
  .IX Item "*"
  .PD
  .PP
  and of the following functions:
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  \&\f(CW\*(C`_\|_builtin_expect_with_probability\*(C'\fR, \f(CW\*(C`_\|_builtin_strchr\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_strcpy\*(C'\fR, \f(CW\*(C`_\|_builtin_strcpy_chk\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_strlen\*(C'\fR, \f(CW\*(C`_\|_builtin_va_copy\*(C'\fR, and
  \&\f(CW\*(C`_\|_builtin_va_start\*(C'\fR
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""getpass"">" 4
! .el .IP *<\f(CWgetpass\fR> 4
  .IX Item "*"
  .ie n .IP "*<""longjmp"">" 4
! .el .IP *<\f(CWlongjmp\fR> 4
  .IX Item "*"
  .ie n .IP "*<""putenv"">" 4
! .el .IP *<\f(CWputenv\fR> 4
  .IX Item "*"
  .ie n .IP "*<""setjmp"">" 4
! .el .IP *<\f(CWsetjmp\fR> 4
  .IX Item "*"
  .ie n .IP "*<""siglongjmp"">" 4
! .el .IP *<\f(CWsiglongjmp\fR> 4
  .IX Item "*"
  .ie n .IP "*<""signal"">" 4
! .el .IP *<\f(CWsignal\fR> 4
  .IX Item "*"
  .ie n .IP "*<""sigsetjmp"">" 4
! .el .IP *<\f(CWsigsetjmp\fR> 4
  .IX Item "*"
  .ie n .IP "*<""strchr"">" 4
! .el .IP *<\f(CWstrchr\fR> 4
  .IX Item "*"
  .ie n .IP "*<""strlen"">" 4
! .el .IP *<\f(CWstrlen\fR> 4
  .IX Item "*"
  .PD
  .PP
  In addition, various functions with an \f(CW\*(C`_\|_analyzer_\*(C'\fR prefix have
! special meaning to the analyzer, described in the GCC Internals manual.
  .PP
  Pertinent parameters for controlling the exploration are:
  .IP "*<\fB\-\-param analyzer\-bb\-explosion\-factor=\fR\fIvalue\fR>" 4
*************** Pertinent parameters for controlling the
*** 10283,10289 ****
  .PD
  .PP
  The following options control the analyzer.
! .IP "\fB\-fanalyzer\-call\-summaries\fR" 4
  .IX Item "-fanalyzer-call-summaries"
  Simplify interprocedural analysis by computing the effect of certain calls,
  rather than exploring all paths through the function from callsite to each
--- 10212,10218 ----
  .PD
  .PP
  The following options control the analyzer.
! .IP \fB\-fanalyzer\-call\-summaries\fR 4
  .IX Item "-fanalyzer-call-summaries"
  Simplify interprocedural analysis by computing the effect of certain calls,
  rather than exploring all paths through the function from callsite to each
*************** possible return.
*** 10292,10298 ****
  If enabled, call summaries are only used for functions with more than one
  call site, and that are sufficiently complicated (as per
  \&\fB\-\-param analyzer\-min\-snodes\-for\-call\-summary=\fR\fIvalue\fR).
! .IP "\fB\-fanalyzer\-checker=\fR\fIname\fR" 4
  .IX Item "-fanalyzer-checker=name"
  Restrict the analyzer to run just the named checker, and enable it.
  .Sp
--- 10221,10227 ----
  If enabled, call summaries are only used for functions with more than one
  call site, and that are sufficiently complicated (as per
  \&\fB\-\-param analyzer\-min\-snodes\-for\-call\-summary=\fR\fIvalue\fR).
! .IP \fB\-fanalyzer\-checker=\fR\fIname\fR 4
  .IX Item "-fanalyzer-checker=name"
  Restrict the analyzer to run just the named checker, and enable it.
  .Sp
*************** following warnings from \fB\-fanalyzer\f
*** 10325,10331 ****
  \&\-Wanalyzer\-use\-after\-free
  \&\-Wanalyzer\-va\-list\-leak
  \&\-Wanalyzer\-va\-list\-use\-after\-va\-end\fR
! .IP "\fB\-fno\-analyzer\-feasibility\fR" 4
  .IX Item "-fno-analyzer-feasibility"
  This option is intended for analyzer developers.
  .Sp
--- 10254,10260 ----
  \&\-Wanalyzer\-use\-after\-free
  \&\-Wanalyzer\-va\-list\-leak
  \&\-Wanalyzer\-va\-list\-use\-after\-va\-end\fR
! .IP \fB\-fno\-analyzer\-feasibility\fR 4
  .IX Item "-fno-analyzer-feasibility"
  This option is intended for analyzer developers.
  .Sp
*************** for each diagnostic it emits: that the c
*** 10334,10408 ****
  exclusive.  Diagnostics for which no feasible path can be found are rejected.
  This filtering can be suppressed with \fB\-fno\-analyzer\-feasibility\fR, for
  debugging issues in this code.
! .IP "\fB\-fanalyzer\-fine\-grained\fR" 4
  .IX Item "-fanalyzer-fine-grained"
  This option is intended for analyzer developers.
  .Sp
! Internally the analyzer builds an \*(L"exploded graph\*(R" that combines
  control flow graphs with data flow information.
  .Sp
  By default, an edge in this graph can contain the effects of a run
  of multiple statements within a basic block.  With
  \&\fB\-fanalyzer\-fine\-grained\fR, each statement gets its own edge.
! .IP "\fB\-fanalyzer\-show\-duplicate\-count\fR" 4
  .IX Item "-fanalyzer-show-duplicate-count"
  This option is intended for analyzer developers: if multiple diagnostics
  have been detected as being duplicates of each other, it emits a note when
  reporting the best diagnostic, giving the number of additional diagnostics
  that were suppressed by the deduplication logic.
! .IP "\fB\-fno\-analyzer\-state\-merge\fR" 4
  .IX Item "-fno-analyzer-state-merge"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer attempts to simplify analysis by merging
  sufficiently similar states at each program point as it builds its
! \&\*(L"exploded graph\*(R".  With \fB\-fno\-analyzer\-state\-merge\fR this
! merging can be suppressed, for debugging state-handling issues.
! .IP "\fB\-fno\-analyzer\-state\-purge\fR" 4
  .IX Item "-fno-analyzer-state-purge"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer attempts to simplify analysis by purging
  aspects of state at a program point that appear to no longer be relevant
! e.g. the values of locals that aren't accessed later in the function
! and which aren't relevant to leak analysis.
  .Sp
  With \fB\-fno\-analyzer\-state\-purge\fR this purging of state can
! be suppressed, for debugging state-handling issues.
! .IP "\fB\-fno\-analyzer\-suppress\-followups\fR" 4
  .IX Item "-fno-analyzer-suppress-followups"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer will stop exploring an execution path after
  encountering certain diagnostics, in order to avoid potentially issuing a
! cascade of follow-up diagnostics.
  .Sp
  The diagnostics that terminate analysis along a path are:
  .RS 4
! .IP "*<\fB\-Wanalyzer\-null\-argument\fR>" 4
  .IX Item "*<-Wanalyzer-null-argument>"
  .PD 0
! .IP "*<\fB\-Wanalyzer\-null\-dereference\fR>" 4
  .IX Item "*<-Wanalyzer-null-dereference>"
! .IP "*<\fB\-Wanalyzer\-use\-after\-free\fR>" 4
  .IX Item "*<-Wanalyzer-use-after-free>"
! .IP "*<\fB\-Wanalyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR>" 4
  .IX Item "*<-Wanalyzer-use-of-pointer-in-stale-stack-frame>"
! .IP "*<\fB\-Wanalyzer\-use\-of\-uninitialized\-value\fR>" 4
  .IX Item "*<-Wanalyzer-use-of-uninitialized-value>"
  .RE
  .RS 4
- .PD
  .Sp
  With \fB\-fno\-analyzer\-suppress\-followups\fR the analyzer will
  continue to explore such paths even after such diagnostics, which may
  be helpful for debugging issues in the analyzer, or for microbenchmarks
  for detecting undefined behavior.
  .RE
! .IP "\fB\-fanalyzer\-transitivity\fR" 4
  .IX Item "-fanalyzer-transitivity"
  This option enables transitivity of constraints within the analyzer.
! .IP "\fB\-fno\-analyzer\-undo\-inlining\fR" 4
  .IX Item "-fno-analyzer-undo-inlining"
  This option is intended for analyzer developers.
  .Sp
--- 10263,10337 ----
  exclusive.  Diagnostics for which no feasible path can be found are rejected.
  This filtering can be suppressed with \fB\-fno\-analyzer\-feasibility\fR, for
  debugging issues in this code.
! .IP \fB\-fanalyzer\-fine\-grained\fR 4
  .IX Item "-fanalyzer-fine-grained"
  This option is intended for analyzer developers.
  .Sp
! Internally the analyzer builds an "exploded graph" that combines
  control flow graphs with data flow information.
  .Sp
  By default, an edge in this graph can contain the effects of a run
  of multiple statements within a basic block.  With
  \&\fB\-fanalyzer\-fine\-grained\fR, each statement gets its own edge.
! .IP \fB\-fanalyzer\-show\-duplicate\-count\fR 4
  .IX Item "-fanalyzer-show-duplicate-count"
  This option is intended for analyzer developers: if multiple diagnostics
  have been detected as being duplicates of each other, it emits a note when
  reporting the best diagnostic, giving the number of additional diagnostics
  that were suppressed by the deduplication logic.
! .IP \fB\-fno\-analyzer\-state\-merge\fR 4
  .IX Item "-fno-analyzer-state-merge"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer attempts to simplify analysis by merging
  sufficiently similar states at each program point as it builds its
! "exploded graph".  With \fB\-fno\-analyzer\-state\-merge\fR this
! merging can be suppressed, for debugging state\-handling issues.
! .IP \fB\-fno\-analyzer\-state\-purge\fR 4
  .IX Item "-fno-analyzer-state-purge"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer attempts to simplify analysis by purging
  aspects of state at a program point that appear to no longer be relevant
! e.g. the values of locals that aren\*(Aqt accessed later in the function
! and which aren\*(Aqt relevant to leak analysis.
  .Sp
  With \fB\-fno\-analyzer\-state\-purge\fR this purging of state can
! be suppressed, for debugging state\-handling issues.
! .IP \fB\-fno\-analyzer\-suppress\-followups\fR 4
  .IX Item "-fno-analyzer-suppress-followups"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer will stop exploring an execution path after
  encountering certain diagnostics, in order to avoid potentially issuing a
! cascade of follow\-up diagnostics.
  .Sp
  The diagnostics that terminate analysis along a path are:
  .RS 4
! .IP *<\fB\-Wanalyzer\-null\-argument\fR> 4
  .IX Item "*<-Wanalyzer-null-argument>"
  .PD 0
! .IP *<\fB\-Wanalyzer\-null\-dereference\fR> 4
  .IX Item "*<-Wanalyzer-null-dereference>"
! .IP *<\fB\-Wanalyzer\-use\-after\-free\fR> 4
  .IX Item "*<-Wanalyzer-use-after-free>"
! .IP *<\fB\-Wanalyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR> 4
  .IX Item "*<-Wanalyzer-use-of-pointer-in-stale-stack-frame>"
! .IP *<\fB\-Wanalyzer\-use\-of\-uninitialized\-value\fR> 4
  .IX Item "*<-Wanalyzer-use-of-uninitialized-value>"
+ .PD
  .RE
  .RS 4
  .Sp
  With \fB\-fno\-analyzer\-suppress\-followups\fR the analyzer will
  continue to explore such paths even after such diagnostics, which may
  be helpful for debugging issues in the analyzer, or for microbenchmarks
  for detecting undefined behavior.
  .RE
! .IP \fB\-fanalyzer\-transitivity\fR 4
  .IX Item "-fanalyzer-transitivity"
  This option enables transitivity of constraints within the analyzer.
! .IP \fB\-fno\-analyzer\-undo\-inlining\fR 4
  .IX Item "-fno-analyzer-undo-inlining"
  This option is intended for analyzer developers.
  .Sp
*************** This option is intended for analyzer dev
*** 10410,10416 ****
  tools, and some optimizations have already been applied to the code.  In
  particular function inlining may have occurred, leading to the
  interprocedural execution paths emitted by the analyzer containing
! function frames that don't correspond to those in the original source
  code.
  .Sp
  By default the analyzer attempts to reconstruct the original function
--- 10339,10345 ----
  tools, and some optimizations have already been applied to the code.  In
  particular function inlining may have occurred, leading to the
  interprocedural execution paths emitted by the analyzer containing
! function frames that don\*(Aqt correspond to those in the original source
  code.
  .Sp
  By default the analyzer attempts to reconstruct the original function
*************** frames, and to emit events showing the i
*** 10419,10541 ****
  With \fB\-fno\-analyzer\-undo\-inlining\fR this attempt to reconstruct
  the original frame information can be be disabled, which may be of help
  when debugging issues in the analyzer.
! .IP "\fB\-fanalyzer\-verbose\-edges\fR" 4
  .IX Item "-fanalyzer-verbose-edges"
  This option is intended for analyzer developers.  It enables more
! verbose, lower-level detail in the descriptions of control flow
  within diagnostic paths.
! .IP "\fB\-fanalyzer\-verbose\-state\-changes\fR" 4
  .IX Item "-fanalyzer-verbose-state-changes"
  This option is intended for analyzer developers.  It enables more
! verbose, lower-level detail in the descriptions of events relating
  to state machines within diagnostic paths.
! .IP "\fB\-fanalyzer\-verbosity=\fR\fIlevel\fR" 4
  .IX Item "-fanalyzer-verbosity=level"
  This option controls the complexity of the control flow paths that are
  emitted for analyzer diagnostics.
  .Sp
  The \fIlevel\fR can be one of:
  .RS 4
! .IP "\fB0\fR" 4
  .IX Item "0"
  At this level, interprocedural call and return events are displayed,
! along with the most pertinent state-change events relating to
  a diagnostic.  For example, for a double\-\f(CW\*(C`free\*(C'\fR diagnostic,
  both calls to \f(CW\*(C`free\*(C'\fR will be shown.
! .IP "\fB1\fR" 4
  .IX Item "1"
  As per the previous level, but also show events for the entry
  to each function.
! .IP "\fB2\fR" 4
  .IX Item "2"
  As per the previous level, but also show events relating to
  control flow that are significant to triggering the issue
! (e.g. \*(L"true path taken\*(R" at a conditional).
  .Sp
  This level is the default.
! .IP "\fB3\fR" 4
  .IX Item "3"
  As per the previous level, but show all control flow events, not
  just significant ones.
! .IP "\fB4\fR" 4
  .IX Item "4"
  This level is intended for analyzer developers; it adds various
  other events intended for debugging the analyzer.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdump\-analyzer\fR" 4
  .IX Item "-fdump-analyzer"
  Dump internal details about what the analyzer is doing to
! \&\fI\fIfile\fI.analyzer.txt\fR.
  \&\fB\-fdump\-analyzer\-stderr\fR overrides this option.
! .IP "\fB\-fdump\-analyzer\-stderr\fR" 4
  .IX Item "-fdump-analyzer-stderr"
  Dump internal details about what the analyzer is doing to stderr.
  This option overrides \fB\-fdump\-analyzer\fR.
! .IP "\fB\-fdump\-analyzer\-callgraph\fR" 4
  .IX Item "-fdump-analyzer-callgraph"
  Dump a representation of the call graph suitable for viewing with
! GraphViz to \fI\fIfile\fI.callgraph.dot\fR.
! .IP "\fB\-fdump\-analyzer\-exploded\-graph\fR" 4
  .IX Item "-fdump-analyzer-exploded-graph"
! Dump a representation of the \*(L"exploded graph\*(R" suitable for viewing with
! GraphViz to \fI\fIfile\fI.eg.dot\fR.
! Nodes are color-coded based on state-machine states to emphasize
  state changes.
! .IP "\fB\-fdump\-analyzer\-exploded\-nodes\fR" 4
  .IX Item "-fdump-analyzer-exploded-nodes"
! Emit diagnostics showing where nodes in the \*(L"exploded graph\*(R" are
  in relation to the program source.
! .IP "\fB\-fdump\-analyzer\-exploded\-nodes\-2\fR" 4
  .IX Item "-fdump-analyzer-exploded-nodes-2"
! Dump a textual representation of the \*(L"exploded graph\*(R" to
! \&\fI\fIfile\fI.eg.txt\fR.
! .IP "\fB\-fdump\-analyzer\-exploded\-nodes\-3\fR" 4
  .IX Item "-fdump-analyzer-exploded-nodes-3"
! Dump a textual representation of the \*(L"exploded graph\*(R" to
! one dump file per node, to \fI\fIfile\fI.eg\-\fIid\fI.txt\fR.
  This is typically a large number of dump files.
! .IP "\fB\-fdump\-analyzer\-exploded\-paths\fR" 4
  .IX Item "-fdump-analyzer-exploded-paths"
! Dump a textual representation of the \*(L"exploded path\*(R" for each
! diagnostic to \fI\fIfile\fI.\fIidx\fI.\fIkind\fI.epath.txt\fR.
! .IP "\fB\-fdump\-analyzer\-feasibility\fR" 4
  .IX Item "-fdump-analyzer-feasibility"
! Dump internal details about the analyzer's search for feasible paths.
  The details are written in a form suitable for viewing with GraphViz
! to filenames of the form \fI\fIfile\fI.*.fg.dot\fR,
! \&\fI\fIfile\fI.*.tg.dot\fR, and \fI\fIfile\fI.*.fpath.txt\fR.
! .IP "\fB\-fdump\-analyzer\-json\fR" 4
  .IX Item "-fdump-analyzer-json"
! Dump a compressed \s-1JSON\s0 representation of analyzer internals to
! \&\fI\fIfile\fI.analyzer.json.gz\fR.  The precise format is subject
  to change.
! .IP "\fB\-fdump\-analyzer\-state\-purge\fR" 4
  .IX Item "-fdump-analyzer-state-purge"
  As per \fB\-fdump\-analyzer\-supergraph\fR, dump a representation of the
! \&\*(L"supergraph\*(R" suitable for viewing with GraphViz, but annotate the
  graph with information on what state will be purged at each node.
! The graph is written to \fI\fIfile\fI.state\-purge.dot\fR.
! .IP "\fB\-fdump\-analyzer\-supergraph\fR" 4
  .IX Item "-fdump-analyzer-supergraph"
! Dump representations of the \*(L"supergraph\*(R" suitable for viewing with
! GraphViz to \fI\fIfile\fI.supergraph.dot\fR and to
! \&\fI\fIfile\fI.supergraph\-eg.dot\fR.  These show all of the
  control flow graphs in the program, with interprocedural edges for
  calls and returns.  The second dump contains annotations showing nodes
! in the \*(L"exploded graph\*(R" and diagnostics associated with them.
! .IP "\fB\-fdump\-analyzer\-untracked\fR" 4
  .IX Item "-fdump-analyzer-untracked"
  Emit custom warnings with internal details intended for analyzer developers.
  .SS "Options for Debugging Your Program"
  .IX Subsection "Options for Debugging Your Program"
! To tell \s-1GCC\s0 to emit extra information for use by a debugger, in almost 
  all cases you need only to add \fB\-g\fR to your other options.  Some debug
! formats can co-exist (like \s-1DWARF\s0 with \s-1CTF\s0) when each of them is enabled
  explicitly by adding the respective command line option to your other options.
  .PP
! \&\s-1GCC\s0 allows you to use \fB\-g\fR with
  \&\fB\-O\fR.  The shortcuts taken by optimized code may occasionally
  be surprising: some variables you declared may not exist
  at all; flow of control may briefly move where you did not expect it;
--- 10348,10470 ----
  With \fB\-fno\-analyzer\-undo\-inlining\fR this attempt to reconstruct
  the original frame information can be be disabled, which may be of help
  when debugging issues in the analyzer.
! .IP \fB\-fanalyzer\-verbose\-edges\fR 4
  .IX Item "-fanalyzer-verbose-edges"
  This option is intended for analyzer developers.  It enables more
! verbose, lower\-level detail in the descriptions of control flow
  within diagnostic paths.
! .IP \fB\-fanalyzer\-verbose\-state\-changes\fR 4
  .IX Item "-fanalyzer-verbose-state-changes"
  This option is intended for analyzer developers.  It enables more
! verbose, lower\-level detail in the descriptions of events relating
  to state machines within diagnostic paths.
! .IP \fB\-fanalyzer\-verbosity=\fR\fIlevel\fR 4
  .IX Item "-fanalyzer-verbosity=level"
  This option controls the complexity of the control flow paths that are
  emitted for analyzer diagnostics.
  .Sp
  The \fIlevel\fR can be one of:
  .RS 4
! .IP \fB0\fR 4
  .IX Item "0"
  At this level, interprocedural call and return events are displayed,
! along with the most pertinent state\-change events relating to
  a diagnostic.  For example, for a double\-\f(CW\*(C`free\*(C'\fR diagnostic,
  both calls to \f(CW\*(C`free\*(C'\fR will be shown.
! .IP \fB1\fR 4
  .IX Item "1"
  As per the previous level, but also show events for the entry
  to each function.
! .IP \fB2\fR 4
  .IX Item "2"
  As per the previous level, but also show events relating to
  control flow that are significant to triggering the issue
! (e.g. "true path taken" at a conditional).
  .Sp
  This level is the default.
! .IP \fB3\fR 4
  .IX Item "3"
  As per the previous level, but show all control flow events, not
  just significant ones.
! .IP \fB4\fR 4
  .IX Item "4"
  This level is intended for analyzer developers; it adds various
  other events intended for debugging the analyzer.
  .RE
  .RS 4
  .RE
! .IP \fB\-fdump\-analyzer\fR 4
  .IX Item "-fdump-analyzer"
  Dump internal details about what the analyzer is doing to
! \&\fIfile.analyzer.txt\fR.
  \&\fB\-fdump\-analyzer\-stderr\fR overrides this option.
! .IP \fB\-fdump\-analyzer\-stderr\fR 4
  .IX Item "-fdump-analyzer-stderr"
  Dump internal details about what the analyzer is doing to stderr.
  This option overrides \fB\-fdump\-analyzer\fR.
! .IP \fB\-fdump\-analyzer\-callgraph\fR 4
  .IX Item "-fdump-analyzer-callgraph"
  Dump a representation of the call graph suitable for viewing with
! GraphViz to \fIfile.callgraph.dot\fR.
! .IP \fB\-fdump\-analyzer\-exploded\-graph\fR 4
  .IX Item "-fdump-analyzer-exploded-graph"
! Dump a representation of the "exploded graph" suitable for viewing with
! GraphViz to \fIfile.eg.dot\fR.
! Nodes are color\-coded based on state\-machine states to emphasize
  state changes.
! .IP \fB\-fdump\-analyzer\-exploded\-nodes\fR 4
  .IX Item "-fdump-analyzer-exploded-nodes"
! Emit diagnostics showing where nodes in the "exploded graph" are
  in relation to the program source.
! .IP \fB\-fdump\-analyzer\-exploded\-nodes\-2\fR 4
  .IX Item "-fdump-analyzer-exploded-nodes-2"
! Dump a textual representation of the "exploded graph" to
! \&\fIfile.eg.txt\fR.
! .IP \fB\-fdump\-analyzer\-exploded\-nodes\-3\fR 4
  .IX Item "-fdump-analyzer-exploded-nodes-3"
! Dump a textual representation of the "exploded graph" to
! one dump file per node, to \fIfile.eg\-id.txt\fR.
  This is typically a large number of dump files.
! .IP \fB\-fdump\-analyzer\-exploded\-paths\fR 4
  .IX Item "-fdump-analyzer-exploded-paths"
! Dump a textual representation of the "exploded path" for each
! diagnostic to \fIfile.idx.kind.epath.txt\fR.
! .IP \fB\-fdump\-analyzer\-feasibility\fR 4
  .IX Item "-fdump-analyzer-feasibility"
! Dump internal details about the analyzer\*(Aqs search for feasible paths.
  The details are written in a form suitable for viewing with GraphViz
! to filenames of the form \fIfile.*.fg.dot\fR,
! \&\fIfile.*.tg.dot\fR, and \fIfile.*.fpath.txt\fR.
! .IP \fB\-fdump\-analyzer\-json\fR 4
  .IX Item "-fdump-analyzer-json"
! Dump a compressed JSON representation of analyzer internals to
! \&\fIfile.analyzer.json.gz\fR.  The precise format is subject
  to change.
! .IP \fB\-fdump\-analyzer\-state\-purge\fR 4
  .IX Item "-fdump-analyzer-state-purge"
  As per \fB\-fdump\-analyzer\-supergraph\fR, dump a representation of the
! "supergraph" suitable for viewing with GraphViz, but annotate the
  graph with information on what state will be purged at each node.
! The graph is written to \fIfile.state\-purge.dot\fR.
! .IP \fB\-fdump\-analyzer\-supergraph\fR 4
  .IX Item "-fdump-analyzer-supergraph"
! Dump representations of the "supergraph" suitable for viewing with
! GraphViz to \fIfile.supergraph.dot\fR and to
! \&\fIfile.supergraph\-eg.dot\fR.  These show all of the
  control flow graphs in the program, with interprocedural edges for
  calls and returns.  The second dump contains annotations showing nodes
! in the "exploded graph" and diagnostics associated with them.
! .IP \fB\-fdump\-analyzer\-untracked\fR 4
  .IX Item "-fdump-analyzer-untracked"
  Emit custom warnings with internal details intended for analyzer developers.
  .SS "Options for Debugging Your Program"
  .IX Subsection "Options for Debugging Your Program"
! To tell GCC to emit extra information for use by a debugger, in almost 
  all cases you need only to add \fB\-g\fR to your other options.  Some debug
! formats can co\-exist (like DWARF with CTF) when each of them is enabled
  explicitly by adding the respective command line option to your other options.
  .PP
! GCC allows you to use \fB\-g\fR with
  \&\fB\-O\fR.  The shortcuts taken by optimized code may occasionally
  be surprising: some variables you declared may not exist
  at all; flow of control may briefly move where you did not expect it;
*************** using \fB\-Og\fR with \fB\-g\fR.
*** 10550,10633 ****
  With no \fB\-O\fR option at all, some compiler passes that collect
  information useful for debugging do not run at all, so that
  \&\fB\-Og\fR may result in a better debugging experience.
! .IP "\fB\-g\fR" 4
  .IX Item "-g"
! Produce debugging information in the operating system's native format
! (stabs, \s-1COFF, XCOFF,\s0 or \s-1DWARF\s0).  \s-1GDB\s0 can work with this debugging
  information.
  .Sp
  On most systems that use stabs format, \fB\-g\fR enables use of extra
! debugging information that only \s-1GDB\s0 can use; this extra information
! makes debugging work better in \s-1GDB\s0 but probably makes other debuggers
  crash or refuse to read the program.  If you want to control for certain whether
  to generate the extra information, use \fB\-gvms\fR (see below).
! .IP "\fB\-ggdb\fR" 4
  .IX Item "-ggdb"
! Produce debugging information for use by \s-1GDB.\s0  This means to use the
! most expressive format available (\s-1DWARF,\s0 stabs, or the native format
! if neither of those are supported), including \s-1GDB\s0 extensions if at all
  possible.
! .IP "\fB\-gdwarf\fR" 4
  .IX Item "-gdwarf"
  .PD 0
! .IP "\fB\-gdwarf\-\fR\fIversion\fR" 4
  .IX Item "-gdwarf-version"
  .PD
! Produce debugging information in \s-1DWARF\s0 format (if that is supported).
  The value of \fIversion\fR may be either 2, 3, 4 or 5; the default
! version for most targets is 5 (with the exception of VxWorks, \s-1TPF\s0 and
! Darwin/Mac \s-1OS X,\s0 which default to version 2, and \s-1AIX,\s0 which defaults
  to version 4).
  .Sp
! Note that with \s-1DWARF\s0 Version 2, some ports require and always
! use some non-conflicting \s-1DWARF 3\s0 extensions in the unwind tables.
  .Sp
! Version 4 may require \s-1GDB 7.0\s0 and \fB\-fvar\-tracking\-assignments\fR
! for maximum benefit. Version 5 requires \s-1GDB 8.0\s0 or higher.
  .Sp
! \&\s-1GCC\s0 no longer supports \s-1DWARF\s0 Version 1, which is substantially
  different than Version 2 and later.  For historical reasons, some
! other DWARF-related options such as
! \&\fB\-fno\-dwarf2\-cfi\-asm\fR) retain a reference to \s-1DWARF\s0 Version 2
! in their names, but apply to all currently-supported versions of \s-1DWARF.\s0
! .IP "\fB\-gbtf\fR" 4
  .IX Item "-gbtf"
! Request \s-1BTF\s0 debug information.  \s-1BTF\s0 is the default debugging format for the
! eBPF target.  On other targets, like x86, \s-1BTF\s0 debug information can be
! generated along with \s-1DWARF\s0 debug information when both of the debug formats are
  enabled explicitly via their respective command line options.
! .IP "\fB\-gctf\fR" 4
  .IX Item "-gctf"
  .PD 0
! .IP "\fB\-gctf\fR\fIlevel\fR" 4
  .IX Item "-gctflevel"
  .PD
! Request \s-1CTF\s0 debug information and use level to specify how much \s-1CTF\s0 debug
  information should be produced.  If \fB\-gctf\fR is specified
! without a value for level, the default level of \s-1CTF\s0 debug information is 2.
  .Sp
! \&\s-1CTF\s0 debug information can be generated along with \s-1DWARF\s0 debug information when
  both of the debug formats are enabled explicitly via their respective command
  line options.
  .Sp
! Level 0 produces no \s-1CTF\s0 debug information at all.  Thus, \fB\-gctf0\fR
  negates \fB\-gctf\fR.
  .Sp
! Level 1 produces \s-1CTF\s0 information for tracebacks only.  This includes callsite
  information, but does not include type information.
  .Sp
  Level 2 produces type information for entities (functions, data objects etc.)
! at file-scope or global-scope only.
! .IP "\fB\-gvms\fR" 4
  .IX Item "-gvms"
  Produce debugging information in Alpha/VMS debug format (if that is
! supported).  This is the format used by \s-1DEBUG\s0 on Alpha/VMS systems.
! .IP "\fB\-g\fR\fIlevel\fR" 4
  .IX Item "-glevel"
  .PD 0
! .IP "\fB\-ggdb\fR\fIlevel\fR" 4
  .IX Item "-ggdblevel"
! .IP "\fB\-gvms\fR\fIlevel\fR" 4
  .IX Item "-gvmslevel"
  .PD
  Request debugging information and also use \fIlevel\fR to specify how
--- 10479,10562 ----
  With no \fB\-O\fR option at all, some compiler passes that collect
  information useful for debugging do not run at all, so that
  \&\fB\-Og\fR may result in a better debugging experience.
! .IP \fB\-g\fR 4
  .IX Item "-g"
! Produce debugging information in the operating system\*(Aqs native format
! (stabs, COFF, XCOFF, or DWARF).  GDB can work with this debugging
  information.
  .Sp
  On most systems that use stabs format, \fB\-g\fR enables use of extra
! debugging information that only GDB can use; this extra information
! makes debugging work better in GDB but probably makes other debuggers
  crash or refuse to read the program.  If you want to control for certain whether
  to generate the extra information, use \fB\-gvms\fR (see below).
! .IP \fB\-ggdb\fR 4
  .IX Item "-ggdb"
! Produce debugging information for use by GDB.  This means to use the
! most expressive format available (DWARF, stabs, or the native format
! if neither of those are supported), including GDB extensions if at all
  possible.
! .IP \fB\-gdwarf\fR 4
  .IX Item "-gdwarf"
  .PD 0
! .IP \fB\-gdwarf\-\fR\fIversion\fR 4
  .IX Item "-gdwarf-version"
  .PD
! Produce debugging information in DWARF format (if that is supported).
  The value of \fIversion\fR may be either 2, 3, 4 or 5; the default
! version for most targets is 5 (with the exception of VxWorks, TPF and
! Darwin/Mac OS X, which default to version 2, and AIX, which defaults
  to version 4).
  .Sp
! Note that with DWARF Version 2, some ports require and always
! use some non\-conflicting DWARF 3 extensions in the unwind tables.
  .Sp
! Version 4 may require GDB 7.0 and \fB\-fvar\-tracking\-assignments\fR
! for maximum benefit. Version 5 requires GDB 8.0 or higher.
  .Sp
! GCC no longer supports DWARF Version 1, which is substantially
  different than Version 2 and later.  For historical reasons, some
! other DWARF\-related options such as
! \&\fB\-fno\-dwarf2\-cfi\-asm\fR) retain a reference to DWARF Version 2
! in their names, but apply to all currently\-supported versions of DWARF.
! .IP \fB\-gbtf\fR 4
  .IX Item "-gbtf"
! Request BTF debug information.  BTF is the default debugging format for the
! eBPF target.  On other targets, like x86, BTF debug information can be
! generated along with DWARF debug information when both of the debug formats are
  enabled explicitly via their respective command line options.
! .IP \fB\-gctf\fR 4
  .IX Item "-gctf"
  .PD 0
! .IP \fB\-gctf\fR\fIlevel\fR 4
  .IX Item "-gctflevel"
  .PD
! Request CTF debug information and use level to specify how much CTF debug
  information should be produced.  If \fB\-gctf\fR is specified
! without a value for level, the default level of CTF debug information is 2.
  .Sp
! CTF debug information can be generated along with DWARF debug information when
  both of the debug formats are enabled explicitly via their respective command
  line options.
  .Sp
! Level 0 produces no CTF debug information at all.  Thus, \fB\-gctf0\fR
  negates \fB\-gctf\fR.
  .Sp
! Level 1 produces CTF information for tracebacks only.  This includes callsite
  information, but does not include type information.
  .Sp
  Level 2 produces type information for entities (functions, data objects etc.)
! at file\-scope or global\-scope only.
! .IP \fB\-gvms\fR 4
  .IX Item "-gvms"
  Produce debugging information in Alpha/VMS debug format (if that is
! supported).  This is the format used by DEBUG on Alpha/VMS systems.
! .IP \fB\-g\fR\fIlevel\fR 4
  .IX Item "-glevel"
  .PD 0
! .IP \fB\-ggdb\fR\fIlevel\fR 4
  .IX Item "-ggdblevel"
! .IP \fB\-gvms\fR\fIlevel\fR 4
  .IX Item "-gvmslevel"
  .PD
  Request debugging information and also use \fIlevel\fR to specify how
*************** Level 0 produces no debug information at
*** 10637,10643 ****
  \&\fB\-g\fR.
  .Sp
  Level 1 produces minimal information, enough for making backtraces in
! parts of the program that you don't plan to debug.  This includes
  descriptions of functions and external variables, and line number
  tables, but no information about local variables.
  .Sp
--- 10566,10572 ----
  \&\fB\-g\fR.
  .Sp
  Level 1 produces minimal information, enough for making backtraces in
! parts of the program that you don\*(Aqt plan to debug.  This includes
  descriptions of functions and external variables, and line number
  tables, but no information about local variables.
  .Sp
*************** the last such option is the one that is
*** 10651,10688 ****
  \&\fB\-gdwarf\fR does not accept a concatenated debug level, to avoid
  confusion with \fB\-gdwarf\-\fR\fIlevel\fR.
  Instead use an additional \fB\-g\fR\fIlevel\fR option to change the
! debug level for \s-1DWARF.\s0
! .IP "\fB\-fno\-eliminate\-unused\-debug\-symbols\fR" 4
  .IX Item "-fno-eliminate-unused-debug-symbols"
  By default, no debug information is produced for symbols that are not actually
  used. Use this option if you want debug information for all symbols.
! .IP "\fB\-femit\-class\-debug\-always\fR" 4
  .IX Item "-femit-class-debug-always"
! Instead of emitting debugging information for a \*(C+ class in only one
  object file, emit it in all object files using the class.  This option
! should be used only with debuggers that are unable to handle the way \s-1GCC\s0
  normally emits debugging information for classes because using this
  option increases the size of debugging information by as much as a
  factor of two.
! .IP "\fB\-fno\-merge\-debug\-strings\fR" 4
  .IX Item "-fno-merge-debug-strings"
  Direct the linker to not merge together strings in the debugging
  information that are identical in different object files.  Merging is
  not supported by all assemblers or linkers.  Merging decreases the size
  of the debug information in the output file at the cost of increasing
  link processing time.  Merging is enabled by default.
! .IP "\fB\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
  .IX Item "-fdebug-prefix-map=old=new"
! When compiling files residing in directory \fI\fIold\fI\fR, record
  debugging information describing them as if the files resided in
! directory \fI\fInew\fI\fR instead.  This can be used to replace a
! build-time path with an install-time path in the debug info.  It can
  also be used to change an absolute path to a relative path by using
  \&\fI.\fR for \fInew\fR.  This can give more reproducible builds, which
! are location independent, but may require an extra command to tell \s-1GDB\s0
  where to find the source files. See also \fB\-ffile\-prefix\-map\fR
  and \fB\-fcanon\-prefix\-map\fR.
! .IP "\fB\-fvar\-tracking\fR" 4
  .IX Item "-fvar-tracking"
  Run variable tracking pass.  It computes where variables are stored at each
  position in code.  Better debugging information is then generated
--- 10580,10617 ----
  \&\fB\-gdwarf\fR does not accept a concatenated debug level, to avoid
  confusion with \fB\-gdwarf\-\fR\fIlevel\fR.
  Instead use an additional \fB\-g\fR\fIlevel\fR option to change the
! debug level for DWARF.
! .IP \fB\-fno\-eliminate\-unused\-debug\-symbols\fR 4
  .IX Item "-fno-eliminate-unused-debug-symbols"
  By default, no debug information is produced for symbols that are not actually
  used. Use this option if you want debug information for all symbols.
! .IP \fB\-femit\-class\-debug\-always\fR 4
  .IX Item "-femit-class-debug-always"
! Instead of emitting debugging information for a C++ class in only one
  object file, emit it in all object files using the class.  This option
! should be used only with debuggers that are unable to handle the way GCC
  normally emits debugging information for classes because using this
  option increases the size of debugging information by as much as a
  factor of two.
! .IP \fB\-fno\-merge\-debug\-strings\fR 4
  .IX Item "-fno-merge-debug-strings"
  Direct the linker to not merge together strings in the debugging
  information that are identical in different object files.  Merging is
  not supported by all assemblers or linkers.  Merging decreases the size
  of the debug information in the output file at the cost of increasing
  link processing time.  Merging is enabled by default.
! .IP \fB\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 4
  .IX Item "-fdebug-prefix-map=old=new"
! When compiling files residing in directory \fIold\fR, record
  debugging information describing them as if the files resided in
! directory \fInew\fR instead.  This can be used to replace a
! build\-time path with an install\-time path in the debug info.  It can
  also be used to change an absolute path to a relative path by using
  \&\fI.\fR for \fInew\fR.  This can give more reproducible builds, which
! are location independent, but may require an extra command to tell GDB
  where to find the source files. See also \fB\-ffile\-prefix\-map\fR
  and \fB\-fcanon\-prefix\-map\fR.
! .IP \fB\-fvar\-tracking\fR 4
  .IX Item "-fvar-tracking"
  Run variable tracking pass.  It computes where variables are stored at each
  position in code.  Better debugging information is then generated
*************** position in code.  Better debugging info
*** 10691,10826 ****
  It is enabled by default when compiling with optimization (\fB\-Os\fR,
  \&\fB\-O\fR, \fB\-O2\fR, ...), debugging information (\fB\-g\fR) and
  the debug info format supports it.
! .IP "\fB\-fvar\-tracking\-assignments\fR" 4
  .IX Item "-fvar-tracking-assignments"
  Annotate assignments to user variables early in the compilation and
  attempt to carry the annotations over throughout the compilation all the
  way to the end, in an attempt to improve debug information while
  optimizing.  Use of \fB\-gdwarf\-4\fR is recommended along with it.
  .Sp
! It can be enabled even if var-tracking is disabled, in which case
  annotations are created and maintained, but discarded at the end.
  By default, this flag is enabled together with \fB\-fvar\-tracking\fR,
  except when selective scheduling is enabled.
! .IP "\fB\-gsplit\-dwarf\fR" 4
  .IX Item "-gsplit-dwarf"
! If \s-1DWARF\s0 debugging information is enabled, separate as much debugging
  information as possible into a separate output file with the extension
  \&\fI.dwo\fR.  This option allows the build system to avoid linking files with
  debug information.  To be useful, this option requires a debugger capable of
  reading \fI.dwo\fR files.
! .IP "\fB\-gdwarf32\fR" 4
  .IX Item "-gdwarf32"
  .PD 0
! .IP "\fB\-gdwarf64\fR" 4
  .IX Item "-gdwarf64"
  .PD
! If \s-1DWARF\s0 debugging information is enabled, the \fB\-gdwarf32\fR selects
! the 32\-bit \s-1DWARF\s0 format and the \fB\-gdwarf64\fR selects the 64\-bit
! \&\s-1DWARF\s0 format.  The default is target specific, on most targets it is
! \&\fB\-gdwarf32\fR though.  The 32\-bit \s-1DWARF\s0 format is smaller, but
! can't support more than 2GiB of debug information in any of the \s-1DWARF\s0
! debug information sections.  The 64\-bit \s-1DWARF\s0 format allows larger debug
  information and might not be well supported by all consumers yet.
! .IP "\fB\-gdescribe\-dies\fR" 4
  .IX Item "-gdescribe-dies"
! Add description attributes to some \s-1DWARF\s0 DIEs that have no name attribute,
  such as artificial variables, external references and call site
  parameter DIEs.
! .IP "\fB\-gpubnames\fR" 4
  .IX Item "-gpubnames"
! Generate \s-1DWARF\s0 \f(CW\*(C`.debug_pubnames\*(C'\fR and \f(CW\*(C`.debug_pubtypes\*(C'\fR sections.
! .IP "\fB\-ggnu\-pubnames\fR" 4
  .IX Item "-ggnu-pubnames"
  Generate \f(CW\*(C`.debug_pubnames\*(C'\fR and \f(CW\*(C`.debug_pubtypes\*(C'\fR sections in a format
! suitable for conversion into a \s-1GDB\s0 index.  This option is only useful
! with a linker that can produce \s-1GDB\s0 index version 7.
! .IP "\fB\-fdebug\-types\-section\fR" 4
  .IX Item "-fdebug-types-section"
! When using \s-1DWARF\s0 Version 4 or higher, type DIEs can be put into
  their own \f(CW\*(C`.debug_types\*(C'\fR section instead of making them part of the
  \&\f(CW\*(C`.debug_info\*(C'\fR section.  It is more efficient to put them in a separate
  comdat section since the linker can then remove duplicates.
! But not all \s-1DWARF\s0 consumers support \f(CW\*(C`.debug_types\*(C'\fR sections yet
  and on some objects \f(CW\*(C`.debug_types\*(C'\fR produces larger instead of smaller
  debugging information.
! .IP "\fB\-grecord\-gcc\-switches\fR" 4
  .IX Item "-grecord-gcc-switches"
  .PD 0
! .IP "\fB\-gno\-record\-gcc\-switches\fR" 4
  .IX Item "-gno-record-gcc-switches"
  .PD
! This switch causes the command-line options used to invoke the
  compiler that may affect code generation to be appended to the
! DW_AT_producer attribute in \s-1DWARF\s0 debugging information.  The options
  are concatenated with spaces separating them from each other and from
  the compiler version.  
  It is enabled by default.
  See also \fB\-frecord\-gcc\-switches\fR for another
  way of storing compiler options into the object file.
! .IP "\fB\-gstrict\-dwarf\fR" 4
  .IX Item "-gstrict-dwarf"
! Disallow using extensions of later \s-1DWARF\s0 standard version than selected
! with \fB\-gdwarf\-\fR\fIversion\fR.  On most targets using non-conflicting
! \&\s-1DWARF\s0 extensions from later standard versions is allowed.
! .IP "\fB\-gno\-strict\-dwarf\fR" 4
  .IX Item "-gno-strict-dwarf"
! Allow using extensions of later \s-1DWARF\s0 standard version than selected with
  \&\fB\-gdwarf\-\fR\fIversion\fR.
! .IP "\fB\-gas\-loc\-support\fR" 4
  .IX Item "-gas-loc-support"
  Inform the compiler that the assembler supports \f(CW\*(C`.loc\*(C'\fR directives.
! It may then use them for the assembler to generate \s-1DWARF2+\s0 line number
  tables.
  .Sp
! This is generally desirable, because assembler-generated line-number
  tables are a lot more compact than those the compiler can generate
  itself.
  .Sp
! This option will be enabled by default if, at \s-1GCC\s0 configure time, the
  assembler was found to support such directives.
! .IP "\fB\-gno\-as\-loc\-support\fR" 4
  .IX Item "-gno-as-loc-support"
! Force \s-1GCC\s0 to generate \s-1DWARF2+\s0 line number tables internally, if \s-1DWARF2+\s0
  line number tables are to be generated.
! .IP "\fB\-gas\-locview\-support\fR" 4
  .IX Item "-gas-locview-support"
  Inform the compiler that the assembler supports \f(CW\*(C`view\*(C'\fR assignment
  and reset assertion checking in \f(CW\*(C`.loc\*(C'\fR directives.
  .Sp
! This option will be enabled by default if, at \s-1GCC\s0 configure time, the
  assembler was found to support them.
! .IP "\fB\-gno\-as\-locview\-support\fR" 4
  .IX Item "-gno-as-locview-support"
! Force \s-1GCC\s0 to assign view numbers internally, if
  \&\fB\-gvariable\-location\-views\fR are explicitly requested.
! .IP "\fB\-gcolumn\-info\fR" 4
  .IX Item "-gcolumn-info"
  .PD 0
! .IP "\fB\-gno\-column\-info\fR" 4
  .IX Item "-gno-column-info"
  .PD
! Emit location column information into \s-1DWARF\s0 debugging information, rather
  than just file and line.
  This option is enabled by default.
! .IP "\fB\-gstatement\-frontiers\fR" 4
  .IX Item "-gstatement-frontiers"
  .PD 0
! .IP "\fB\-gno\-statement\-frontiers\fR" 4
  .IX Item "-gno-statement-frontiers"
  .PD
! This option causes \s-1GCC\s0 to create markers in the internal representation
  at the beginning of statements, and to keep them roughly in place
  throughout compilation, using them to guide the output of \f(CW\*(C`is_stmt\*(C'\fR
  markers in the line number table.  This is enabled by default when
  compiling with optimization (\fB\-Os\fR, \fB\-O1\fR, \fB\-O2\fR,
! \&...), and outputting \s-1DWARF 2\s0 debug information at the normal level.
! .IP "\fB\-gvariable\-location\-views\fR" 4
  .IX Item "-gvariable-location-views"
  .PD 0
! .IP "\fB\-gvariable\-location\-views=incompat5\fR" 4
  .IX Item "-gvariable-location-views=incompat5"
! .IP "\fB\-gno\-variable\-location\-views\fR" 4
  .IX Item "-gno-variable-location-views"
  .PD
  Augment variable location lists with progressive view numbers implied
--- 10620,10755 ----
  It is enabled by default when compiling with optimization (\fB\-Os\fR,
  \&\fB\-O\fR, \fB\-O2\fR, ...), debugging information (\fB\-g\fR) and
  the debug info format supports it.
! .IP \fB\-fvar\-tracking\-assignments\fR 4
  .IX Item "-fvar-tracking-assignments"
  Annotate assignments to user variables early in the compilation and
  attempt to carry the annotations over throughout the compilation all the
  way to the end, in an attempt to improve debug information while
  optimizing.  Use of \fB\-gdwarf\-4\fR is recommended along with it.
  .Sp
! It can be enabled even if var\-tracking is disabled, in which case
  annotations are created and maintained, but discarded at the end.
  By default, this flag is enabled together with \fB\-fvar\-tracking\fR,
  except when selective scheduling is enabled.
! .IP \fB\-gsplit\-dwarf\fR 4
  .IX Item "-gsplit-dwarf"
! If DWARF debugging information is enabled, separate as much debugging
  information as possible into a separate output file with the extension
  \&\fI.dwo\fR.  This option allows the build system to avoid linking files with
  debug information.  To be useful, this option requires a debugger capable of
  reading \fI.dwo\fR files.
! .IP \fB\-gdwarf32\fR 4
  .IX Item "-gdwarf32"
  .PD 0
! .IP \fB\-gdwarf64\fR 4
  .IX Item "-gdwarf64"
  .PD
! If DWARF debugging information is enabled, the \fB\-gdwarf32\fR selects
! the 32\-bit DWARF format and the \fB\-gdwarf64\fR selects the 64\-bit
! DWARF format.  The default is target specific, on most targets it is
! \&\fB\-gdwarf32\fR though.  The 32\-bit DWARF format is smaller, but
! can\*(Aqt support more than 2GiB of debug information in any of the DWARF
! debug information sections.  The 64\-bit DWARF format allows larger debug
  information and might not be well supported by all consumers yet.
! .IP \fB\-gdescribe\-dies\fR 4
  .IX Item "-gdescribe-dies"
! Add description attributes to some DWARF DIEs that have no name attribute,
  such as artificial variables, external references and call site
  parameter DIEs.
! .IP \fB\-gpubnames\fR 4
  .IX Item "-gpubnames"
! Generate DWARF \f(CW\*(C`.debug_pubnames\*(C'\fR and \f(CW\*(C`.debug_pubtypes\*(C'\fR sections.
! .IP \fB\-ggnu\-pubnames\fR 4
  .IX Item "-ggnu-pubnames"
  Generate \f(CW\*(C`.debug_pubnames\*(C'\fR and \f(CW\*(C`.debug_pubtypes\*(C'\fR sections in a format
! suitable for conversion into a GDB index.  This option is only useful
! with a linker that can produce GDB index version 7.
! .IP \fB\-fdebug\-types\-section\fR 4
  .IX Item "-fdebug-types-section"
! When using DWARF Version 4 or higher, type DIEs can be put into
  their own \f(CW\*(C`.debug_types\*(C'\fR section instead of making them part of the
  \&\f(CW\*(C`.debug_info\*(C'\fR section.  It is more efficient to put them in a separate
  comdat section since the linker can then remove duplicates.
! But not all DWARF consumers support \f(CW\*(C`.debug_types\*(C'\fR sections yet
  and on some objects \f(CW\*(C`.debug_types\*(C'\fR produces larger instead of smaller
  debugging information.
! .IP \fB\-grecord\-gcc\-switches\fR 4
  .IX Item "-grecord-gcc-switches"
  .PD 0
! .IP \fB\-gno\-record\-gcc\-switches\fR 4
  .IX Item "-gno-record-gcc-switches"
  .PD
! This switch causes the command\-line options used to invoke the
  compiler that may affect code generation to be appended to the
! DW_AT_producer attribute in DWARF debugging information.  The options
  are concatenated with spaces separating them from each other and from
  the compiler version.  
  It is enabled by default.
  See also \fB\-frecord\-gcc\-switches\fR for another
  way of storing compiler options into the object file.
! .IP \fB\-gstrict\-dwarf\fR 4
  .IX Item "-gstrict-dwarf"
! Disallow using extensions of later DWARF standard version than selected
! with \fB\-gdwarf\-\fR\fIversion\fR.  On most targets using non\-conflicting
! DWARF extensions from later standard versions is allowed.
! .IP \fB\-gno\-strict\-dwarf\fR 4
  .IX Item "-gno-strict-dwarf"
! Allow using extensions of later DWARF standard version than selected with
  \&\fB\-gdwarf\-\fR\fIversion\fR.
! .IP \fB\-gas\-loc\-support\fR 4
  .IX Item "-gas-loc-support"
  Inform the compiler that the assembler supports \f(CW\*(C`.loc\*(C'\fR directives.
! It may then use them for the assembler to generate DWARF2+ line number
  tables.
  .Sp
! This is generally desirable, because assembler\-generated line\-number
  tables are a lot more compact than those the compiler can generate
  itself.
  .Sp
! This option will be enabled by default if, at GCC configure time, the
  assembler was found to support such directives.
! .IP \fB\-gno\-as\-loc\-support\fR 4
  .IX Item "-gno-as-loc-support"
! Force GCC to generate DWARF2+ line number tables internally, if DWARF2+
  line number tables are to be generated.
! .IP \fB\-gas\-locview\-support\fR 4
  .IX Item "-gas-locview-support"
  Inform the compiler that the assembler supports \f(CW\*(C`view\*(C'\fR assignment
  and reset assertion checking in \f(CW\*(C`.loc\*(C'\fR directives.
  .Sp
! This option will be enabled by default if, at GCC configure time, the
  assembler was found to support them.
! .IP \fB\-gno\-as\-locview\-support\fR 4
  .IX Item "-gno-as-locview-support"
! Force GCC to assign view numbers internally, if
  \&\fB\-gvariable\-location\-views\fR are explicitly requested.
! .IP \fB\-gcolumn\-info\fR 4
  .IX Item "-gcolumn-info"
  .PD 0
! .IP \fB\-gno\-column\-info\fR 4
  .IX Item "-gno-column-info"
  .PD
! Emit location column information into DWARF debugging information, rather
  than just file and line.
  This option is enabled by default.
! .IP \fB\-gstatement\-frontiers\fR 4
  .IX Item "-gstatement-frontiers"
  .PD 0
! .IP \fB\-gno\-statement\-frontiers\fR 4
  .IX Item "-gno-statement-frontiers"
  .PD
! This option causes GCC to create markers in the internal representation
  at the beginning of statements, and to keep them roughly in place
  throughout compilation, using them to guide the output of \f(CW\*(C`is_stmt\*(C'\fR
  markers in the line number table.  This is enabled by default when
  compiling with optimization (\fB\-Os\fR, \fB\-O1\fR, \fB\-O2\fR,
! \&...), and outputting DWARF 2 debug information at the normal level.
! .IP \fB\-gvariable\-location\-views\fR 4
  .IX Item "-gvariable-location-views"
  .PD 0
! .IP \fB\-gvariable\-location\-views=incompat5\fR 4
  .IX Item "-gvariable-location-views=incompat5"
! .IP \fB\-gno\-variable\-location\-views\fR 4
  .IX Item "-gno-variable-location-views"
  .PD
  Augment variable location lists with progressive view numbers implied
*************** associated with the corresponding source
*** 10830,10894 ****
  point.  If the assembler lacks support for view numbers in line number
  tables, this will cause the compiler to emit the line number table,
  which generally makes them somewhat less compact.  The augmented line
! number tables and location lists are fully backward-compatible, so they
  can be consumed by debug information consumers that are not aware of
! these augmentations, but they won't derive any benefit from them either.
  .Sp
! This is enabled by default when outputting \s-1DWARF 2\s0 debug information at
  the normal level, as long as there is assembler support,
  \&\fB\-fvar\-tracking\-assignments\fR is enabled and
  \&\fB\-gstrict\-dwarf\fR is not.  When assembler support is not
! available, this may still be enabled, but it will force \s-1GCC\s0 to output
  internal line number tables, and if
  \&\fB\-ginternal\-reset\-location\-views\fR is not enabled, that will most
  certainly lead to silently mismatching location views.
  .Sp
  There is a proposed representation for view numbers that is not backward
! compatible with the location list format introduced in \s-1DWARF 5,\s0 that can
  be enabled with \fB\-gvariable\-location\-views=incompat5\fR.  This
  option may be removed in the future, is only provided as a reference
  implementation of the proposed representation.  Debug information
  consumers are not expected to support this extended format, and they
  would be rendered unable to decode location lists using it.
! .IP "\fB\-ginternal\-reset\-location\-views\fR" 4
  .IX Item "-ginternal-reset-location-views"
  .PD 0
! .IP "\fB\-gno\-internal\-reset\-location\-views\fR" 4
  .IX Item "-gno-internal-reset-location-views"
  .PD
  Attempt to determine location views that can be omitted from location
  view lists.  This requires the compiler to have very accurate insn
! length estimates, which isn't always the case, and it may cause
  incorrect view lists to be generated silently when using an assembler
! that does not support location view lists.  The \s-1GNU\s0 assembler will flag
  any such error as a \f(CW\*(C`view number mismatch\*(C'\fR.  This is only enabled
  on ports that define a reliable estimation function.
! .IP "\fB\-ginline\-points\fR" 4
  .IX Item "-ginline-points"
  .PD 0
! .IP "\fB\-gno\-inline\-points\fR" 4
  .IX Item "-gno-inline-points"
  .PD
  Generate extended debug information for inlined functions.  Location
  view tracking markers are inserted at inlined entry points, so that
  address and view numbers can be computed and output in debug
  information.  This can be enabled independently of location views, in
! which case the view numbers won't be output, but it can only be enabled
  along with statement frontiers, and it is only enabled by default if
  location views are enabled.
! .IP "\fB\-gz\fR[\fB=\fR\fItype\fR]" 4
  .IX Item "-gz[=type]"
! Produce compressed debug sections in \s-1DWARF\s0 format, if that is supported.
  If \fItype\fR is not given, the default type depends on the capabilities
  of the assembler and linker used.  \fItype\fR may be one of
! \&\fBnone\fR (don't compress debug sections), or \fBzlib\fR (use zlib
! compression in \s-1ELF\s0 gABI format).  If the linker doesn't support writing
  compressed debug sections, the option is rejected.  Otherwise, if the
  assembler does not support them, \fB\-gz\fR is silently ignored when
  producing object files.
! .IP "\fB\-femit\-struct\-debug\-baseonly\fR" 4
  .IX Item "-femit-struct-debug-baseonly"
! Emit debug information for struct-like types
  only when the base name of the compilation source file
  matches the base name of file in which the struct is defined.
  .Sp
--- 10759,10823 ----
  point.  If the assembler lacks support for view numbers in line number
  tables, this will cause the compiler to emit the line number table,
  which generally makes them somewhat less compact.  The augmented line
! number tables and location lists are fully backward\-compatible, so they
  can be consumed by debug information consumers that are not aware of
! these augmentations, but they won\*(Aqt derive any benefit from them either.
  .Sp
! This is enabled by default when outputting DWARF 2 debug information at
  the normal level, as long as there is assembler support,
  \&\fB\-fvar\-tracking\-assignments\fR is enabled and
  \&\fB\-gstrict\-dwarf\fR is not.  When assembler support is not
! available, this may still be enabled, but it will force GCC to output
  internal line number tables, and if
  \&\fB\-ginternal\-reset\-location\-views\fR is not enabled, that will most
  certainly lead to silently mismatching location views.
  .Sp
  There is a proposed representation for view numbers that is not backward
! compatible with the location list format introduced in DWARF 5, that can
  be enabled with \fB\-gvariable\-location\-views=incompat5\fR.  This
  option may be removed in the future, is only provided as a reference
  implementation of the proposed representation.  Debug information
  consumers are not expected to support this extended format, and they
  would be rendered unable to decode location lists using it.
! .IP \fB\-ginternal\-reset\-location\-views\fR 4
  .IX Item "-ginternal-reset-location-views"
  .PD 0
! .IP \fB\-gno\-internal\-reset\-location\-views\fR 4
  .IX Item "-gno-internal-reset-location-views"
  .PD
  Attempt to determine location views that can be omitted from location
  view lists.  This requires the compiler to have very accurate insn
! length estimates, which isn\*(Aqt always the case, and it may cause
  incorrect view lists to be generated silently when using an assembler
! that does not support location view lists.  The GNU assembler will flag
  any such error as a \f(CW\*(C`view number mismatch\*(C'\fR.  This is only enabled
  on ports that define a reliable estimation function.
! .IP \fB\-ginline\-points\fR 4
  .IX Item "-ginline-points"
  .PD 0
! .IP \fB\-gno\-inline\-points\fR 4
  .IX Item "-gno-inline-points"
  .PD
  Generate extended debug information for inlined functions.  Location
  view tracking markers are inserted at inlined entry points, so that
  address and view numbers can be computed and output in debug
  information.  This can be enabled independently of location views, in
! which case the view numbers won\*(Aqt be output, but it can only be enabled
  along with statement frontiers, and it is only enabled by default if
  location views are enabled.
! .IP \fB\-gz\fR[\fB=\fR\fItype\fR] 4
  .IX Item "-gz[=type]"
! Produce compressed debug sections in DWARF format, if that is supported.
  If \fItype\fR is not given, the default type depends on the capabilities
  of the assembler and linker used.  \fItype\fR may be one of
! \&\fBnone\fR (don\*(Aqt compress debug sections), or \fBzlib\fR (use zlib
! compression in ELF gABI format).  If the linker doesn\*(Aqt support writing
  compressed debug sections, the option is rejected.  Otherwise, if the
  assembler does not support them, \fB\-gz\fR is silently ignored when
  producing object files.
! .IP \fB\-femit\-struct\-debug\-baseonly\fR 4
  .IX Item "-femit-struct-debug-baseonly"
! Emit debug information for struct\-like types
  only when the base name of the compilation source file
  matches the base name of file in which the struct is defined.
  .Sp
*************** but at significant potential loss in typ
*** 10897,10906 ****
  See \fB\-femit\-struct\-debug\-reduced\fR for a less aggressive option.
  See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
  .Sp
! This option works only with \s-1DWARF\s0 debug output.
! .IP "\fB\-femit\-struct\-debug\-reduced\fR" 4
  .IX Item "-femit-struct-debug-reduced"
! Emit debug information for struct-like types
  only when the base name of the compilation source file
  matches the base name of file in which the type is defined,
  unless the struct is a template or defined in a system header.
--- 10826,10835 ----
  See \fB\-femit\-struct\-debug\-reduced\fR for a less aggressive option.
  See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
  .Sp
! This option works only with DWARF debug output.
! .IP \fB\-femit\-struct\-debug\-reduced\fR 4
  .IX Item "-femit-struct-debug-reduced"
! Emit debug information for struct\-like types
  only when the base name of the compilation source file
  matches the base name of file in which the type is defined,
  unless the struct is a template or defined in a system header.
*************** with some potential loss in type informa
*** 10910,10919 ****
  See \fB\-femit\-struct\-debug\-baseonly\fR for a more aggressive option.
  See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
  .Sp
! This option works only with \s-1DWARF\s0 debug output.
! .IP "\fB\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR]" 4
  .IX Item "-femit-struct-debug-detailed[=spec-list]"
! Specify the struct-like types
  for which the compiler generates debug information.
  The intent is to reduce duplicate struct debug information
  between different object files within the same program.
--- 10839,10848 ----
  See \fB\-femit\-struct\-debug\-baseonly\fR for a more aggressive option.
  See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
  .Sp
! This option works only with DWARF debug output.
! .IP \fB\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec\-list\fR] 4
  .IX Item "-femit-struct-debug-detailed[=spec-list]"
! Specify the struct\-like types
  for which the compiler generates debug information.
  The intent is to reduce duplicate struct debug information
  between different object files within the same program.
*************** An example is
*** 10935,10942 ****
  The optional second word limits the specification to
  ordinary structs (\fBord:\fR) or generic structs (\fBgen:\fR).
  Generic structs are a bit complicated to explain.
! For \*(C+, these are non-explicit specializations of template classes,
! or non-template classes within the above.
  Other programming languages have generics,
  but \fB\-femit\-struct\-debug\-detailed\fR does not yet implement them.
  .Sp
--- 10864,10871 ----
  The optional second word limits the specification to
  ordinary structs (\fBord:\fR) or generic structs (\fBgen:\fR).
  Generic structs are a bit complicated to explain.
! For C++, these are non\-explicit specializations of template classes,
! or non\-template classes within the above.
  Other programming languages have generics,
  but \fB\-femit\-struct\-debug\-detailed\fR does not yet implement them.
  .Sp
*************** You may need to experiment to determine
*** 10956,10971 ****
  .Sp
  The default is \fB\-femit\-struct\-debug\-detailed=all\fR.
  .Sp
! This option works only with \s-1DWARF\s0 debug output.
! .IP "\fB\-fno\-dwarf2\-cfi\-asm\fR" 4
  .IX Item "-fno-dwarf2-cfi-asm"
! Emit \s-1DWARF\s0 unwind info as compiler generated \f(CW\*(C`.eh_frame\*(C'\fR section
! instead of using \s-1GAS\s0 \f(CW\*(C`.cfi_*\*(C'\fR directives.
! .IP "\fB\-fno\-eliminate\-unused\-debug\-types\fR" 4
  .IX Item "-fno-eliminate-unused-debug-types"
! Normally, when producing \s-1DWARF\s0 output, \s-1GCC\s0 avoids producing debug symbol 
  output for types that are nowhere used in the source file being compiled.
! Sometimes it is useful to have \s-1GCC\s0 emit debugging
  information for all types declared in a compilation
  unit, regardless of whether or not they are actually used
  in that compilation unit, for example 
--- 10885,10900 ----
  .Sp
  The default is \fB\-femit\-struct\-debug\-detailed=all\fR.
  .Sp
! This option works only with DWARF debug output.
! .IP \fB\-fno\-dwarf2\-cfi\-asm\fR 4
  .IX Item "-fno-dwarf2-cfi-asm"
! Emit DWARF unwind info as compiler generated \f(CW\*(C`.eh_frame\*(C'\fR section
! instead of using GAS \f(CW\*(C`.cfi_*\*(C'\fR directives.
! .IP \fB\-fno\-eliminate\-unused\-debug\-types\fR 4
  .IX Item "-fno-eliminate-unused-debug-types"
! Normally, when producing DWARF output, GCC avoids producing debug symbol 
  output for types that are nowhere used in the source file being compiled.
! Sometimes it is useful to have GCC emit debugging
  information for all types declared in a compilation
  unit, regardless of whether or not they are actually used
  in that compilation unit, for example 
*************** however, this results in a significant a
*** 10976,10982 ****
  .IX Subsection "Options That Control Optimization"
  These options control various sorts of optimizations.
  .PP
! Without any optimization option, the compiler's goal is to reduce the
  cost of compilation and to make debugging produce the expected
  results.  Statements are independent: if you stop the program with a
  breakpoint between statements, you can then assign a new value to any
--- 10905,10911 ----
  .IX Subsection "Options That Control Optimization"
  These options control various sorts of optimizations.
  .PP
! Without any optimization option, the compiler\*(Aqs 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
*************** Most optimizations are completely disabl
*** 11001,11014 ****
  optimization flags are specified.  Similarly, \fB\-Og\fR suppresses
  many optimization passes.
  .PP
! Depending on the target and how \s-1GCC\s0 was configured, a slightly different
  set of optimizations may be enabled at each \fB\-O\fR level than
! those listed here.  You can invoke \s-1GCC\s0 with \fB\-Q \-\-help=optimizers\fR
  to find out the exact set of optimizations that are enabled at each level.
! .IP "\fB\-O\fR" 4
  .IX Item "-O"
  .PD 0
! .IP "\fB\-O1\fR" 4
  .IX Item "-O1"
  .PD
  Optimize.  Optimizing compilation takes somewhat more time, and a lot
--- 10930,10943 ----
  optimization flags are specified.  Similarly, \fB\-Og\fR suppresses
  many optimization passes.
  .PP
! Depending on the target and how GCC was configured, a slightly different
  set of optimizations may be enabled at each \fB\-O\fR level than
! those listed here.  You can invoke GCC with \fB\-Q \-\-help=optimizers\fR
  to find out the exact set of optimizations that are enabled at each level.
! .IP \fB\-O\fR 4
  .IX Item "-O"
  .PD 0
! .IP \fB\-O1\fR 4
  .IX Item "-O1"
  .PD
  Optimize.  Optimizing compilation takes somewhat more time, and a lot
*************** compilation time.
*** 11067,11076 ****
  \&\-ftree\-sra
  \&\-ftree\-ter
  \&\-funit\-at\-a\-time\fR
! .IP "\fB\-O2\fR" 4
  .IX Item "-O2"
! Optimize even more.  \s-1GCC\s0 performs nearly all supported optimizations
! that do not involve a space-speed tradeoff.
  As compared to \fB\-O\fR, this option increases both compilation time
  and the performance of the generated code.
  .Sp
--- 10996,11005 ----
  \&\-ftree\-sra
  \&\-ftree\-ter
  \&\-funit\-at\-a\-time\fR
! .IP \fB\-O2\fR 4
  .IX Item "-O2"
! Optimize even more.  GCC performs nearly all supported optimizations
! that do not involve a space\-speed tradeoff.
  As compared to \fB\-O\fR, this option increases both compilation time
  and the performance of the generated code.
  .Sp
*************** also turns on the following optimization
*** 11118,11124 ****
  .Sp
  Please note the warning under \fB\-fgcse\fR about
  invoking \fB\-O2\fR on programs that use computed gotos.
! .IP "\fB\-O3\fR" 4
  .IX Item "-O3"
  Optimize yet more.  \fB\-O3\fR turns on all optimizations specified
  by \fB\-O2\fR and also turns on the following optimization flags:
--- 11047,11053 ----
  .Sp
  Please note the warning under \fB\-fgcse\fR about
  invoking \fB\-O2\fR on programs that use computed gotos.
! .IP \fB\-O3\fR 4
  .IX Item "-O3"
  Optimize yet more.  \fB\-O3\fR turns on all optimizations specified
  by \fB\-O2\fR and also turns on the following optimization flags:
*************** by \fB\-O2\fR and also turns on the foll
*** 11136,11146 ****
  \&\-funswitch\-loops
  \&\-fvect\-cost\-model=dynamic
  \&\-fversion\-loops\-for\-strides\fR
! .IP "\fB\-O0\fR" 4
  .IX Item "-O0"
  Reduce compilation time and make debugging produce the expected
  results.  This is the default.
! .IP "\fB\-Os\fR" 4
  .IX Item "-Os"
  Optimize for size.  \fB\-Os\fR enables all \fB\-O2\fR optimizations 
  except those that often increase code size:
--- 11065,11075 ----
  \&\-funswitch\-loops
  \&\-fvect\-cost\-model=dynamic
  \&\-fversion\-loops\-for\-strides\fR
! .IP \fB\-O0\fR 4
  .IX Item "-O0"
  Reduce compilation time and make debugging produce the expected
  results.  This is the default.
! .IP \fB\-Os\fR 4
  .IX Item "-Os"
  Optimize for size.  \fB\-Os\fR enables all \fB\-O2\fR optimizations 
  except those that often increase code size:
*************** except those that often increase code si
*** 11152,11170 ****
  It also enables \fB\-finline\-functions\fR, causes the compiler to tune for
  code size rather than execution speed, and performs further optimizations
  designed to reduce code size.
! .IP "\fB\-Ofast\fR" 4
  .IX Item "-Ofast"
  Disregard strict standards compliance.  \fB\-Ofast\fR enables all
  \&\fB\-O3\fR optimizations.  It also enables optimizations that are not
! valid for all standard-compliant programs.
  It turns on \fB\-ffast\-math\fR, \fB\-fallow\-store\-data\-races\fR
! and the Fortran-specific \fB\-fstack\-arrays\fR, unless
  \&\fB\-fmax\-stack\-var\-size\fR is specified, and \fB\-fno\-protect\-parens\fR.
  It turns off \fB\-fsemantic\-interposition\fR.
! .IP "\fB\-Og\fR" 4
  .IX Item "-Og"
  Optimize debugging experience.  \fB\-Og\fR should be the optimization
! level of choice for the standard edit-compile-debug cycle, offering
  a reasonable level of optimization while maintaining fast compilation
  and a good debugging experience.  It is a better choice than \fB\-O0\fR
  for producing debuggable code because some compiler passes
--- 11081,11099 ----
  It also enables \fB\-finline\-functions\fR, causes the compiler to tune for
  code size rather than execution speed, and performs further optimizations
  designed to reduce code size.
! .IP \fB\-Ofast\fR 4
  .IX Item "-Ofast"
  Disregard strict standards compliance.  \fB\-Ofast\fR enables all
  \&\fB\-O3\fR optimizations.  It also enables optimizations that are not
! valid for all standard\-compliant programs.
  It turns on \fB\-ffast\-math\fR, \fB\-fallow\-store\-data\-races\fR
! and the Fortran\-specific \fB\-fstack\-arrays\fR, unless
  \&\fB\-fmax\-stack\-var\-size\fR is specified, and \fB\-fno\-protect\-parens\fR.
  It turns off \fB\-fsemantic\-interposition\fR.
! .IP \fB\-Og\fR 4
  .IX Item "-Og"
  Optimize debugging experience.  \fB\-Og\fR should be the optimization
! level of choice for the standard edit\-compile\-debug cycle, offering
  a reasonable level of optimization while maintaining fast compilation
  and a good debugging experience.  It is a better choice than \fB\-O0\fR
  for producing debuggable code because some compiler passes
*************** optimization flags except for those that
*** 11180,11186 ****
  \&\-finline\-functions\-called\-once
  \&\-fmove\-loop\-invariants  \-fmove\-loop\-stores  \-fssa\-phiopt
  \&\-ftree\-bit\-ccp  \-ftree\-dse  \-ftree\-pta  \-ftree\-sra\fR
! .IP "\fB\-Oz\fR" 4
  .IX Item "-Oz"
  Optimize aggressively for size rather than speed.  This may increase
  the number of instructions executed if those instructions require
--- 11109,11115 ----
  \&\-finline\-functions\-called\-once
  \&\-fmove\-loop\-invariants  \-fmove\-loop\-stores  \-fssa\-phiopt
  \&\-ftree\-bit\-ccp  \-ftree\-dse  \-ftree\-pta  \-ftree\-sra\fR
! .IP \fB\-Oz\fR 4
  .IX Item "-Oz"
  Optimize aggressively for size rather than speed.  This may increase
  the number of instructions executed if those instructions require
*************** including enabling most \fB\-O2\fR optim
*** 11190,11196 ****
  If you use multiple \fB\-O\fR options, with or without level numbers,
  the last such option is the one that is effective.
  .PP
! Options of the form \fB\-f\fR\fIflag\fR specify machine-independent
  flags.  Most flags have both positive and negative forms; the negative
  form of \fB\-ffoo\fR is \fB\-fno\-foo\fR.  In the table
  below, only one of the forms is listed\-\-\-the one you typically 
--- 11119,11125 ----
  If you use multiple \fB\-O\fR options, with or without level numbers,
  the last such option is the one that is effective.
  .PP
! Options of the form \fB\-f\fR\fIflag\fR specify machine\-independent
  flags.  Most flags have both positive and negative forms; the negative
  form of \fB\-ffoo\fR is \fB\-fno\-foo\fR.  In the table
  below, only one of the forms is listed\-\-\-the one you typically 
*************** or adding it.
*** 11199,11260 ****
  .PP
  The following options control specific optimizations.  They are either
  activated by \fB\-O\fR options or are related to ones that are.  You
! can use the following flags in the rare cases when \*(L"fine-tuning\*(R" of
  optimizations to be performed is desired.
! .IP "\fB\-fno\-defer\-pop\fR" 4
  .IX Item "-fno-defer-pop"
  For machines that must pop arguments after a function call, always pop 
  the arguments as soon as each function returns.  
  At levels \fB\-O1\fR and higher, \fB\-fdefer\-pop\fR is the default;
  this allows the compiler to let arguments accumulate on the stack for several
  function calls and pop them all at once.
! .IP "\fB\-fforward\-propagate\fR" 4
  .IX Item "-fforward-propagate"
! Perform a forward propagation pass on \s-1RTL.\s0  The pass tries to combine two
  instructions and checks if the result can be simplified.  If loop unrolling
  is active, two passes are performed and the second is scheduled after
  loop unrolling.
  .Sp
  This option is enabled by default at optimization levels \fB\-O1\fR,
  \&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-ffp\-contract=\fR\fIstyle\fR" 4
  .IX Item "-ffp-contract=style"
! \&\fB\-ffp\-contract=off\fR disables floating-point expression contraction.
! \&\fB\-ffp\-contract=fast\fR enables floating-point expression contraction
! such as forming of fused multiply-add operations if the target has
  native support for them.
! \&\fB\-ffp\-contract=on\fR enables floating-point expression contraction
  if allowed by the language standard.  This is currently not implemented
  and treated equal to \fB\-ffp\-contract=off\fR.
  .Sp
  The default is \fB\-ffp\-contract=fast\fR.
! .IP "\fB\-fomit\-frame\-pointer\fR" 4
  .IX Item "-fomit-frame-pointer"
! Omit the frame pointer in functions that don't need one.  This avoids the
  instructions to save, set up and restore the frame pointer; on many targets
  it also makes an extra register available.
  .Sp
  On some targets this flag has no effect because the standard calling sequence
  always uses a frame pointer, so it cannot be omitted.
  .Sp
! Note that \fB\-fno\-omit\-frame\-pointer\fR doesn't guarantee the frame pointer
  is used in all functions.  Several targets always omit the frame pointer in
  leaf functions.
  .Sp
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-foptimize\-sibling\-calls\fR" 4
  .IX Item "-foptimize-sibling-calls"
  Optimize sibling and tail recursive calls.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-foptimize\-strlen\fR" 4
  .IX Item "-foptimize-strlen"
  Optimize various standard C string functions (e.g. \f(CW\*(C`strlen\*(C'\fR,
  \&\f(CW\*(C`strchr\*(C'\fR or \f(CW\*(C`strcpy\*(C'\fR) and
  their \f(CW\*(C`_FORTIFY_SOURCE\*(C'\fR counterparts into faster alternatives.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-fno\-inline\fR" 4
  .IX Item "-fno-inline"
  Do not expand any functions inline apart from those marked with
  the \f(CW\*(C`always_inline\*(C'\fR attribute.  This is the default when not
--- 11128,11189 ----
  .PP
  The following options control specific optimizations.  They are either
  activated by \fB\-O\fR options or are related to ones that are.  You
! can use the following flags in the rare cases when "fine\-tuning" of
  optimizations to be performed is desired.
! .IP \fB\-fno\-defer\-pop\fR 4
  .IX Item "-fno-defer-pop"
  For machines that must pop arguments after a function call, always pop 
  the arguments as soon as each function returns.  
  At levels \fB\-O1\fR and higher, \fB\-fdefer\-pop\fR is the default;
  this allows the compiler to let arguments accumulate on the stack for several
  function calls and pop them all at once.
! .IP \fB\-fforward\-propagate\fR 4
  .IX Item "-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.
  .Sp
  This option is enabled by default at optimization levels \fB\-O1\fR,
  \&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-ffp\-contract=\fR\fIstyle\fR 4
  .IX Item "-ffp-contract=style"
! \&\fB\-ffp\-contract=off\fR disables floating\-point expression contraction.
! \&\fB\-ffp\-contract=fast\fR enables floating\-point expression contraction
! such as forming of fused multiply\-add operations if the target has
  native support for them.
! \&\fB\-ffp\-contract=on\fR enables floating\-point expression contraction
  if allowed by the language standard.  This is currently not implemented
  and treated equal to \fB\-ffp\-contract=off\fR.
  .Sp
  The default is \fB\-ffp\-contract=fast\fR.
! .IP \fB\-fomit\-frame\-pointer\fR 4
  .IX Item "-fomit-frame-pointer"
! Omit the frame pointer in functions that don\*(Aqt need one.  This avoids the
  instructions to save, set up and restore the frame pointer; on many targets
  it also makes an extra register available.
  .Sp
  On some targets this flag has no effect because the standard calling sequence
  always uses a frame pointer, so it cannot be omitted.
  .Sp
! Note that \fB\-fno\-omit\-frame\-pointer\fR doesn\*(Aqt guarantee the frame pointer
  is used in all functions.  Several targets always omit the frame pointer in
  leaf functions.
  .Sp
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-foptimize\-sibling\-calls\fR 4
  .IX Item "-foptimize-sibling-calls"
  Optimize sibling and tail recursive calls.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-foptimize\-strlen\fR 4
  .IX Item "-foptimize-strlen"
  Optimize various standard C string functions (e.g. \f(CW\*(C`strlen\*(C'\fR,
  \&\f(CW\*(C`strchr\*(C'\fR or \f(CW\*(C`strcpy\*(C'\fR) and
  their \f(CW\*(C`_FORTIFY_SOURCE\*(C'\fR counterparts into faster alternatives.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-fno\-inline\fR 4
  .IX Item "-fno-inline"
  Do not expand any functions inline apart from those marked with
  the \f(CW\*(C`always_inline\*(C'\fR attribute.  This is the default when not
*************** optimizing.
*** 11262,11268 ****
  .Sp
  Single functions can be exempted from inlining by marking them
  with the \f(CW\*(C`noinline\*(C'\fR attribute.
! .IP "\fB\-finline\-small\-functions\fR" 4
  .IX Item "-finline-small-functions"
  Integrate functions into their callers when their body is smaller than expected
  function call code (so overall size of program gets smaller).  The compiler
--- 11191,11197 ----
  .Sp
  Single functions can be exempted from inlining by marking them
  with the \f(CW\*(C`noinline\*(C'\fR attribute.
! .IP \fB\-finline\-small\-functions\fR 4
  .IX Item "-finline-small-functions"
  Integrate functions into their callers when their body is smaller than expected
  function call code (so overall size of program gets smaller).  The compiler
*************** in this way.  This inlining applies to a
*** 11271,11277 ****
  inline.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-findirect\-inlining\fR" 4
  .IX Item "-findirect-inlining"
  Inline also indirect calls that are discovered to be known at compile
  time thanks to previous inlining.  This option has any effect only
--- 11200,11206 ----
  inline.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-findirect\-inlining\fR 4
  .IX Item "-findirect-inlining"
  Inline also indirect calls that are discovered to be known at compile
  time thanks to previous inlining.  This option has any effect only
*************** when inlining itself is turned on by the
*** 11279,11285 ****
  or \fB\-finline\-small\-functions\fR options.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-finline\-functions\fR" 4
  .IX Item "-finline-functions"
  Consider all functions for inlining, even if they are not declared inline.
  The compiler heuristically decides which functions are worth integrating
--- 11208,11214 ----
  or \fB\-finline\-small\-functions\fR options.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-finline\-functions\fR 4
  .IX Item "-finline-functions"
  Consider all functions for inlining, even if they are not declared inline.
  The compiler heuristically decides which functions are worth integrating
*************** assembler code in its own right.
*** 11291,11297 ****
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.  Also enabled
  by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-finline\-functions\-called\-once\fR" 4
  .IX Item "-finline-functions-called-once"
  Consider all \f(CW\*(C`static\*(C'\fR functions called once for inlining into their
  caller even if they are not marked \f(CW\*(C`inline\*(C'\fR.  If a call to a given
--- 11220,11226 ----
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.  Also enabled
  by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-finline\-functions\-called\-once\fR 4
  .IX Item "-finline-functions-called-once"
  Consider all \f(CW\*(C`static\*(C'\fR functions called once for inlining into their
  caller even if they are not marked \f(CW\*(C`inline\*(C'\fR.  If a call to a given
*************** in its own right.
*** 11300,11306 ****
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR,
  but not \fB\-Og\fR.
! .IP "\fB\-fearly\-inlining\fR" 4
  .IX Item "-fearly-inlining"
  Inline functions marked by \f(CW\*(C`always_inline\*(C'\fR and functions whose body seems
  smaller than the function call overhead early before doing
--- 11229,11235 ----
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR,
  but not \fB\-Og\fR.
! .IP \fB\-fearly\-inlining\fR 4
  .IX Item "-fearly-inlining"
  Inline functions marked by \f(CW\*(C`always_inline\*(C'\fR and functions whose body seems
  smaller than the function call overhead early before doing
*************** makes profiling significantly cheaper an
*** 11309,11324 ****
  having large chains of nested wrapper functions.
  .Sp
  Enabled by default.
! .IP "\fB\-fipa\-sra\fR" 4
  .IX Item "-fipa-sra"
  Perform interprocedural scalar replacement of aggregates, removal of
  unused parameters and replacement of parameters passed by reference
  by parameters passed by value.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
! .IP "\fB\-finline\-limit=\fR\fIn\fR" 4
  .IX Item "-finline-limit=n"
! By default, \s-1GCC\s0 limits the size of functions that can be inlined.  This flag
  allows coarse control of this limit.  \fIn\fR is the size of functions that
  can be inlined in number of pseudo instructions.
  .Sp
--- 11238,11253 ----
  having large chains of nested wrapper functions.
  .Sp
  Enabled by default.
! .IP \fB\-fipa\-sra\fR 4
  .IX Item "-fipa-sra"
  Perform interprocedural scalar replacement of aggregates, removal of
  unused parameters and replacement of parameters passed by reference
  by parameters passed by value.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
! .IP \fB\-finline\-limit=\fR\fIn\fR 4
  .IX Item "-finline-limit=n"
! By default, GCC limits the size of functions that can be inlined.  This flag
  allows coarse control of this limit.  \fIn\fR is the size of functions that
  can be inlined in number of pseudo instructions.
  .Sp
*************** specified individually by using \fB\-\-p
*** 11327,11336 ****
  The \fB\-finline\-limit=\fR\fIn\fR option sets some of these parameters
  as follows:
  .RS 4
! .IP "\fBmax-inline-insns-single\fR" 4
  .IX Item "max-inline-insns-single"
  is set to \fIn\fR/2.
! .IP "\fBmax-inline-insns-auto\fR" 4
  .IX Item "max-inline-insns-auto"
  is set to \fIn\fR/2.
  .RE
--- 11256,11265 ----
  The \fB\-finline\-limit=\fR\fIn\fR option sets some of these parameters
  as follows:
  .RS 4
! .IP \fBmax\-inline\-insns\-single\fR 4
  .IX Item "max-inline-insns-single"
  is set to \fIn\fR/2.
! .IP \fBmax\-inline\-insns\-auto\fR 4
  .IX Item "max-inline-insns-auto"
  is set to \fIn\fR/2.
  .RE
*************** parameters controlling inlining and for
*** 11343,11379 ****
  in default behavior.
  .Sp
  \&\fINote:\fR pseudo instruction represents, in this particular context, an
! abstract measurement of function's size.  In no way does it represent a count
  of assembly instructions and as such its exact meaning might change from one
  release to an another.
  .RE
! .IP "\fB\-fno\-keep\-inline\-dllexport\fR" 4
  .IX Item "-fno-keep-inline-dllexport"
! This is a more fine-grained version of \fB\-fkeep\-inline\-functions\fR,
  which applies only to functions that are declared using the \f(CW\*(C`dllexport\*(C'\fR
  attribute or declspec.
! .IP "\fB\-fkeep\-inline\-functions\fR" 4
  .IX Item "-fkeep-inline-functions"
  In C, emit \f(CW\*(C`static\*(C'\fR functions that are declared \f(CW\*(C`inline\*(C'\fR
  into the object file, even if the function has been inlined into all
  of its callers.  This switch does not affect functions using the
! \&\f(CW\*(C`extern inline\*(C'\fR extension in \s-1GNU C90.\s0  In \*(C+, emit any and all
  inline functions into the object file.
! .IP "\fB\-fkeep\-static\-functions\fR" 4
  .IX Item "-fkeep-static-functions"
  Emit \f(CW\*(C`static\*(C'\fR functions into the object file, even if the function
  is never used.
! .IP "\fB\-fkeep\-static\-consts\fR" 4
  .IX Item "-fkeep-static-consts"
! Emit variables declared \f(CW\*(C`static const\*(C'\fR when optimization isn't turned
! on, even if the variables aren't referenced.
  .Sp
! \&\s-1GCC\s0 enables this option by default.  If you want to force the compiler to
  check if a variable is referenced, regardless of whether or not
  optimization is turned on, use the \fB\-fno\-keep\-static\-consts\fR option.
! .IP "\fB\-fmerge\-constants\fR" 4
  .IX Item "-fmerge-constants"
! Attempt to merge identical constants (string constants and floating-point
  constants) across compilation units.
  .Sp
  This option is the default for optimized compilation if the assembler and
--- 11272,11308 ----
  in default behavior.
  .Sp
  \&\fINote:\fR pseudo instruction represents, in this particular context, an
! abstract measurement of function\*(Aqs size.  In no way does it represent a count
  of assembly instructions and as such its exact meaning might change from one
  release to an another.
  .RE
! .IP \fB\-fno\-keep\-inline\-dllexport\fR 4
  .IX Item "-fno-keep-inline-dllexport"
! This is a more fine\-grained version of \fB\-fkeep\-inline\-functions\fR,
  which applies only to functions that are declared using the \f(CW\*(C`dllexport\*(C'\fR
  attribute or declspec.
! .IP \fB\-fkeep\-inline\-functions\fR 4
  .IX Item "-fkeep-inline-functions"
  In C, emit \f(CW\*(C`static\*(C'\fR functions that are declared \f(CW\*(C`inline\*(C'\fR
  into the object file, even if the function has been inlined into all
  of its callers.  This switch does not affect functions using the
! \&\f(CW\*(C`extern inline\*(C'\fR extension in GNU C90.  In C++, emit any and all
  inline functions into the object file.
! .IP \fB\-fkeep\-static\-functions\fR 4
  .IX Item "-fkeep-static-functions"
  Emit \f(CW\*(C`static\*(C'\fR functions into the object file, even if the function
  is never used.
! .IP \fB\-fkeep\-static\-consts\fR 4
  .IX Item "-fkeep-static-consts"
! Emit variables declared \f(CW\*(C`static const\*(C'\fR when optimization isn\*(Aqt turned
! on, even if the variables aren\*(Aqt referenced.
  .Sp
! GCC enables this option by default.  If you want to force the compiler to
  check if a variable is referenced, regardless of whether or not
  optimization is turned on, use the \fB\-fno\-keep\-static\-consts\fR option.
! .IP \fB\-fmerge\-constants\fR 4
  .IX Item "-fmerge-constants"
! Attempt to merge identical constants (string constants and floating\-point
  constants) across compilation units.
  .Sp
  This option is the default for optimized compilation if the assembler and
*************** linker support it.  Use \fB\-fno\-merge\
*** 11381,11436 ****
  behavior.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fmerge\-all\-constants\fR" 4
  .IX Item "-fmerge-all-constants"
  Attempt to merge identical constants and identical variables.
  .Sp
  This option implies \fB\-fmerge\-constants\fR.  In addition to
  \&\fB\-fmerge\-constants\fR this considers e.g. even constant initialized
! arrays or initialized constant variables with integral or floating-point
! types.  Languages like C or \*(C+ require each variable, including multiple
  instances of the same variable in recursive calls, to have distinct locations,
! so using this option results in non-conforming
  behavior.
! .IP "\fB\-fmodulo\-sched\fR" 4
  .IX Item "-fmodulo-sched"
  Perform swing modulo scheduling immediately before the first scheduling
  pass.  This pass looks at innermost loops and reorders their
  instructions by overlapping different iterations.
! .IP "\fB\-fmodulo\-sched\-allow\-regmoves\fR" 4
  .IX Item "-fmodulo-sched-allow-regmoves"
! Perform more aggressive SMS-based modulo scheduling with register moves
! allowed.  By setting this flag certain anti-dependences edges are
! deleted, which triggers the generation of reg-moves based on the
! life-range analysis.  This option is effective only with
  \&\fB\-fmodulo\-sched\fR enabled.
! .IP "\fB\-fno\-branch\-count\-reg\fR" 4
  .IX Item "-fno-branch-count-reg"
  Disable the optimization pass that scans for opportunities to use 
! \&\*(L"decrement and branch\*(R" instructions on a count register instead of
  instruction sequences that decrement a register, compare it against zero, and
  then branch based upon the result.  This option is only meaningful on
  architectures that support such instructions, which include x86, PowerPC,
! \&\s-1IA\-64\s0 and S/390.  Note that the \fB\-fno\-branch\-count\-reg\fR option
! doesn't remove the decrement and branch instructions from the generated
  instruction stream introduced by other optimization passes.
  .Sp
  The default is \fB\-fbranch\-count\-reg\fR at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP "\fB\-fno\-function\-cse\fR" 4
  .IX Item "-fno-function-cse"
  Do not put function addresses in registers; make each instruction that
! calls a constant function contain the function's address explicitly.
  .Sp
  This option results in less efficient code, but some strange hacks
  that alter the assembler output may be confused by the optimizations
  performed when this option is not used.
  .Sp
  The default is \fB\-ffunction\-cse\fR
! .IP "\fB\-fno\-zero\-initialized\-in\-bss\fR" 4
  .IX Item "-fno-zero-initialized-in-bss"
! If the target supports a \s-1BSS\s0 section, \s-1GCC\s0 by default puts variables that
! are initialized to zero into \s-1BSS.\s0  This can save space in the resulting
  code.
  .Sp
  This option turns off this behavior because some programs explicitly
--- 11310,11365 ----
  behavior.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fmerge\-all\-constants\fR 4
  .IX Item "-fmerge-all-constants"
  Attempt to merge identical constants and identical variables.
  .Sp
  This option implies \fB\-fmerge\-constants\fR.  In addition to
  \&\fB\-fmerge\-constants\fR this considers e.g. even constant initialized
! arrays or initialized constant variables with integral or floating\-point
! types.  Languages like C or C++ require each variable, including multiple
  instances of the same variable in recursive calls, to have distinct locations,
! so using this option results in non\-conforming
  behavior.
! .IP \fB\-fmodulo\-sched\fR 4
  .IX Item "-fmodulo-sched"
  Perform swing modulo scheduling immediately before the first scheduling
  pass.  This pass looks at innermost loops and reorders their
  instructions by overlapping different iterations.
! .IP \fB\-fmodulo\-sched\-allow\-regmoves\fR 4
  .IX Item "-fmodulo-sched-allow-regmoves"
! Perform more aggressive SMS\-based modulo scheduling with register moves
! allowed.  By setting this flag certain anti\-dependences edges are
! deleted, which triggers the generation of reg\-moves based on the
! life\-range analysis.  This option is effective only with
  \&\fB\-fmodulo\-sched\fR enabled.
! .IP \fB\-fno\-branch\-count\-reg\fR 4
  .IX Item "-fno-branch-count-reg"
  Disable the optimization pass that scans for opportunities to use 
! "decrement and branch" instructions on a count register instead of
  instruction sequences that decrement a register, compare it against zero, and
  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.  Note that the \fB\-fno\-branch\-count\-reg\fR option
! doesn\*(Aqt remove the decrement and branch instructions from the generated
  instruction stream introduced by other optimization passes.
  .Sp
  The default is \fB\-fbranch\-count\-reg\fR at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP \fB\-fno\-function\-cse\fR 4
  .IX Item "-fno-function-cse"
  Do not put function addresses in registers; make each instruction that
! calls a constant function contain the function\*(Aqs address explicitly.
  .Sp
  This option results in less efficient code, but some strange hacks
  that alter the assembler output may be confused by the optimizations
  performed when this option is not used.
  .Sp
  The default is \fB\-ffunction\-cse\fR
! .IP \fB\-fno\-zero\-initialized\-in\-bss\fR 4
  .IX Item "-fno-zero-initialized-in-bss"
! If the target supports a BSS section, GCC by default puts variables that
! are initialized to zero into BSS.  This can save space in the resulting
  code.
  .Sp
  This option turns off this behavior because some programs explicitly
*************** resulting executable can find the beginn
*** 11439,11445 ****
  assumptions based on that.
  .Sp
  The default is \fB\-fzero\-initialized\-in\-bss\fR.
! .IP "\fB\-fthread\-jumps\fR" 4
  .IX Item "-fthread-jumps"
  Perform optimizations that check to see if a jump branches to a
  location where another comparison subsumed by the first is found.  If
--- 11368,11374 ----
  assumptions based on that.
  .Sp
  The default is \fB\-fzero\-initialized\-in\-bss\fR.
! .IP \fB\-fthread\-jumps\fR 4
  .IX Item "-fthread-jumps"
  Perform optimizations that check to see if a jump branches to a
  location where another comparison subsumed by the first is found.  If
*************** second branch or a point immediately fol
*** 11448,11454 ****
  the condition is known to be true or false.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fsplit\-wide\-types\fR" 4
  .IX Item "-fsplit-wide-types"
  When using a type that occupies multiple registers, such as \f(CW\*(C`long
  long\*(C'\fR on a 32\-bit system, split the registers apart and allocate them
--- 11377,11383 ----
  the condition is known to be true or false.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fsplit\-wide\-types\fR 4
  .IX Item "-fsplit-wide-types"
  When using a type that occupies multiple registers, such as \f(CW\*(C`long
  long\*(C'\fR on a 32\-bit system, split the registers apart and allocate them
*************** but may make debugging more difficult.
*** 11457,11504 ****
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR,
  \&\fB\-Os\fR.
! .IP "\fB\-fsplit\-wide\-types\-early\fR" 4
  .IX Item "-fsplit-wide-types-early"
  Fully split wide types early, instead of very late.
  This option has no effect unless \fB\-fsplit\-wide\-types\fR is turned on.
  .Sp
  This is the default on some targets.
! .IP "\fB\-fcse\-follow\-jumps\fR" 4
  .IX Item "-fcse-follow-jumps"
! In common subexpression elimination (\s-1CSE\s0), scan through jump instructions
  when the target of the jump is not reached by any other path.  For
! example, when \s-1CSE\s0 encounters an \f(CW\*(C`if\*(C'\fR statement with an
! \&\f(CW\*(C`else\*(C'\fR clause, \s-1CSE\s0 follows the jump when the condition
  tested is false.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fcse\-skip\-blocks\fR" 4
  .IX Item "-fcse-skip-blocks"
! This is similar to \fB\-fcse\-follow\-jumps\fR, but causes \s-1CSE\s0 to
! follow jumps that conditionally skip over blocks.  When \s-1CSE\s0
  encounters a simple \f(CW\*(C`if\*(C'\fR statement with no else clause,
! \&\fB\-fcse\-skip\-blocks\fR causes \s-1CSE\s0 to follow the jump around the
  body of the \f(CW\*(C`if\*(C'\fR.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-frerun\-cse\-after\-loop\fR" 4
  .IX Item "-frerun-cse-after-loop"
! Re-run common subexpression elimination after loop optimizations are
  performed.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fgcse\fR" 4
  .IX Item "-fgcse"
  Perform a global common subexpression elimination pass.
  This pass also performs global constant and copy propagation.
  .Sp
! \&\fINote:\fR When compiling a program using computed gotos, a \s-1GCC\s0
! extension, you may get better run-time performance if you disable
  the global common subexpression elimination pass by adding
  \&\fB\-fno\-gcse\fR to the command line.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fgcse\-lm\fR" 4
  .IX Item "-fgcse-lm"
  When \fB\-fgcse\-lm\fR is enabled, global common subexpression elimination
  attempts to move loads that are only killed by stores into themselves.  This
--- 11386,11433 ----
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR,
  \&\fB\-Os\fR.
! .IP \fB\-fsplit\-wide\-types\-early\fR 4
  .IX Item "-fsplit-wide-types-early"
  Fully split wide types early, instead of very late.
  This option has no effect unless \fB\-fsplit\-wide\-types\fR is turned on.
  .Sp
  This is the default on some targets.
! .IP \fB\-fcse\-follow\-jumps\fR 4
  .IX Item "-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 \f(CW\*(C`if\*(C'\fR statement with an
! \&\f(CW\*(C`else\*(C'\fR clause, CSE follows the jump when the condition
  tested is false.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fcse\-skip\-blocks\fR 4
  .IX Item "-fcse-skip-blocks"
! This is similar to \fB\-fcse\-follow\-jumps\fR, but causes CSE to
! follow jumps that conditionally skip over blocks.  When CSE
  encounters a simple \f(CW\*(C`if\*(C'\fR statement with no else clause,
! \&\fB\-fcse\-skip\-blocks\fR causes CSE to follow the jump around the
  body of the \f(CW\*(C`if\*(C'\fR.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-frerun\-cse\-after\-loop\fR 4
  .IX Item "-frerun-cse-after-loop"
! Re\-run common subexpression elimination after loop optimizations are
  performed.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fgcse\fR 4
  .IX Item "-fgcse"
  Perform a global common subexpression elimination pass.
  This pass also performs global constant and copy propagation.
  .Sp
! \&\fINote:\fR When compiling a program using computed gotos, a GCC
! extension, you may get better run\-time performance if you disable
  the global common subexpression elimination pass by adding
  \&\fB\-fno\-gcse\fR to the command line.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fgcse\-lm\fR 4
  .IX Item "-fgcse-lm"
  When \fB\-fgcse\-lm\fR is enabled, global common subexpression elimination
  attempts to move loads that are only killed by stores into themselves.  This
*************** allows a loop containing a load/store se
*** 11506,11512 ****
  the loop, and a copy/store within the loop.
  .Sp
  Enabled by default when \fB\-fgcse\fR is enabled.
! .IP "\fB\-fgcse\-sm\fR" 4
  .IX Item "-fgcse-sm"
  When \fB\-fgcse\-sm\fR is enabled, a store motion pass is run after
  global common subexpression elimination.  This pass attempts to move
--- 11435,11441 ----
  the loop, and a copy/store within the loop.
  .Sp
  Enabled by default when \fB\-fgcse\fR is enabled.
! .IP \fB\-fgcse\-sm\fR 4
  .IX Item "-fgcse-sm"
  When \fB\-fgcse\-sm\fR is enabled, a store motion pass is run after
  global common subexpression elimination.  This pass attempts to move
*************** loops containing a load/store sequence c
*** 11515,11588 ****
  the loop and a store after the loop.
  .Sp
  Not enabled at any optimization level.
! .IP "\fB\-fgcse\-las\fR" 4
  .IX Item "-fgcse-las"
  When \fB\-fgcse\-las\fR is enabled, the global common subexpression
  elimination pass eliminates redundant loads that come after stores to the
  same memory location (both partial and full redundancies).
  .Sp
  Not enabled at any optimization level.
! .IP "\fB\-fgcse\-after\-reload\fR" 4
  .IX Item "-fgcse-after-reload"
  When \fB\-fgcse\-after\-reload\fR is enabled, a redundant load elimination
  pass is performed after reload.  The purpose of this pass is to clean up
  redundant spilling.
  .Sp
  Enabled by \fB\-O3\fR, \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-faggressive\-loop\-optimizations\fR" 4
  .IX Item "-faggressive-loop-optimizations"
  This option tells the loop optimizer to use language constraints to
  derive bounds for the number of iterations of a loop.  This assumes that
  loop code does not invoke undefined behavior by for example causing signed
! integer overflows or out-of-bound array accesses.  The bounds for the
  number of iterations of a loop are used to guide loop unrolling and peeling
  and loop exit test optimizations.
  This option is enabled by default.
! .IP "\fB\-funconstrained\-commons\fR" 4
  .IX Item "-funconstrained-commons"
  This option tells the compiler that variables declared in common blocks
  (e.g. Fortran) may later be overridden with longer trailing arrays. This
  prevents certain optimizations that depend on knowing the array bounds.
! .IP "\fB\-fcrossjumping\fR" 4
  .IX Item "-fcrossjumping"
! Perform cross-jumping transformation.
  This transformation unifies equivalent code and saves code size.  The
! resulting code may or may not perform better than without cross-jumping.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fauto\-inc\-dec\fR" 4
  .IX Item "-fauto-inc-dec"
  Combine increments or decrements of addresses with memory accesses.
  This pass is always skipped on architectures that do not have
  instructions to support this.  Enabled by default at \fB\-O1\fR and
  higher on architectures that support this.
! .IP "\fB\-fdce\fR" 4
  .IX Item "-fdce"
! Perform dead code elimination (\s-1DCE\s0) on \s-1RTL.\s0
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fdse\fR" 4
  .IX Item "-fdse"
! Perform dead store elimination (\s-1DSE\s0) on \s-1RTL.\s0
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fif\-conversion\fR" 4
  .IX Item "-fif-conversion"
! Attempt to transform conditional jumps into branch-less equivalents.  This
  includes use of conditional moves, min, max, set flags and abs instructions, and
  some tricks doable by standard arithmetics.  The use of conditional execution
  on chips where it is available is controlled by \fB\-fif\-conversion2\fR.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, but
  not with \fB\-Og\fR.
! .IP "\fB\-fif\-conversion2\fR" 4
  .IX Item "-fif-conversion2"
  Use conditional execution (where available) to transform conditional jumps into
! branch-less equivalents.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, but
  not with \fB\-Og\fR.
! .IP "\fB\-fdeclone\-ctor\-dtor\fR" 4
  .IX Item "-fdeclone-ctor-dtor"
! The \*(C+ \s-1ABI\s0 requires multiple entry points for constructors and
  destructors: one for a base subobject, one for a complete object, and
  one for a virtual destructor that calls operator delete afterwards.
  For a hierarchy with virtual bases, the base and complete variants are
--- 11444,11517 ----
  the loop and a store after the loop.
  .Sp
  Not enabled at any optimization level.
! .IP \fB\-fgcse\-las\fR 4
  .IX Item "-fgcse-las"
  When \fB\-fgcse\-las\fR is enabled, the global common subexpression
  elimination pass eliminates redundant loads that come after stores to the
  same memory location (both partial and full redundancies).
  .Sp
  Not enabled at any optimization level.
! .IP \fB\-fgcse\-after\-reload\fR 4
  .IX Item "-fgcse-after-reload"
  When \fB\-fgcse\-after\-reload\fR is enabled, a redundant load elimination
  pass is performed after reload.  The purpose of this pass is to clean up
  redundant spilling.
  .Sp
  Enabled by \fB\-O3\fR, \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-faggressive\-loop\-optimizations\fR 4
  .IX Item "-faggressive-loop-optimizations"
  This option tells the loop optimizer to use language constraints to
  derive bounds for the number of iterations of a loop.  This assumes that
  loop code does not invoke undefined behavior by for example causing signed
! integer overflows or out\-of\-bound array accesses.  The bounds for the
  number of iterations of a loop are used to guide loop unrolling and peeling
  and loop exit test optimizations.
  This option is enabled by default.
! .IP \fB\-funconstrained\-commons\fR 4
  .IX Item "-funconstrained-commons"
  This option tells the compiler that variables declared in common blocks
  (e.g. Fortran) may later be overridden with longer trailing arrays. This
  prevents certain optimizations that depend on knowing the array bounds.
! .IP \fB\-fcrossjumping\fR 4
  .IX Item "-fcrossjumping"
! Perform cross\-jumping transformation.
  This transformation unifies equivalent code and saves code size.  The
! resulting code may or may not perform better than without cross\-jumping.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fauto\-inc\-dec\fR 4
  .IX Item "-fauto-inc-dec"
  Combine increments or decrements of addresses with memory accesses.
  This pass is always skipped on architectures that do not have
  instructions to support this.  Enabled by default at \fB\-O1\fR and
  higher on architectures that support this.
! .IP \fB\-fdce\fR 4
  .IX Item "-fdce"
! Perform dead code elimination (DCE) on RTL.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fdse\fR 4
  .IX Item "-fdse"
! Perform dead store elimination (DSE) on RTL.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fif\-conversion\fR 4
  .IX Item "-fif-conversion"
! Attempt to transform conditional jumps into branch\-less equivalents.  This
  includes use of conditional moves, min, max, set flags and abs instructions, and
  some tricks doable by standard arithmetics.  The use of conditional execution
  on chips where it is available is controlled by \fB\-fif\-conversion2\fR.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, but
  not with \fB\-Og\fR.
! .IP \fB\-fif\-conversion2\fR 4
  .IX Item "-fif-conversion2"
  Use conditional execution (where available) to transform conditional jumps into
! branch\-less equivalents.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, but
  not with \fB\-Og\fR.
! .IP \fB\-fdeclone\-ctor\-dtor\fR 4
  .IX Item "-fdeclone-ctor-dtor"
! The C++ ABI requires multiple entry points for constructors and
  destructors: one for a base subobject, one for a complete object, and
  one for a virtual destructor that calls operator delete afterwards.
  For a hierarchy with virtual bases, the base and complete variants are
*************** base and complete variants are changed t
*** 11591,11603 ****
  implementation.
  .Sp
  Enabled by \fB\-Os\fR.
! .IP "\fB\-fdelete\-null\-pointer\-checks\fR" 4
  .IX Item "-fdelete-null-pointer-checks"
  Assume that programs cannot safely dereference null pointers, and that
  no code or data element resides at address zero.
  This option enables simple constant
  folding optimizations at all optimization levels.  In addition, other
! optimization passes in \s-1GCC\s0 use this flag to control global dataflow
  analyses that eliminate useless checks for null pointers; these assume
  that a memory access to address zero always results in a trap, so
  that if a pointer is checked after it has already been dereferenced,
--- 11520,11532 ----
  implementation.
  .Sp
  Enabled by \fB\-Os\fR.
! .IP \fB\-fdelete\-null\-pointer\-checks\fR 4
  .IX Item "-fdelete-null-pointer-checks"
  Assume that programs cannot safely dereference null pointers, and that
  no code or data element resides at address zero.
  This option 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 a memory access to address zero always results in a trap, so
  that if a pointer is checked after it has already been dereferenced,
*************** Note however that in some environments t
*** 11607,11625 ****
  Use \fB\-fno\-delete\-null\-pointer\-checks\fR to disable this optimization
  for programs that depend on that behavior.
  .Sp
! This option is enabled by default on most targets.  On Nios \s-1II ELF,\s0 it
! defaults to off.  On \s-1AVR\s0 and \s-1MSP430,\s0 this option is completely disabled.
  .Sp
  Passes that use the dataflow information
  are enabled independently at different optimization levels.
! .IP "\fB\-fdevirtualize\fR" 4
  .IX Item "-fdevirtualize"
  Attempt to convert calls to virtual functions to direct calls.  This
  is done both within a procedure and interprocedurally as part of
  indirect inlining (\fB\-findirect\-inlining\fR) and interprocedural constant
  propagation (\fB\-fipa\-cp\fR).
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fdevirtualize\-speculatively\fR" 4
  .IX Item "-fdevirtualize-speculatively"
  Attempt to convert calls to virtual functions to speculative direct calls.
  Based on the analysis of the type inheritance graph, determine for a given call
--- 11536,11554 ----
  Use \fB\-fno\-delete\-null\-pointer\-checks\fR to disable this optimization
  for programs that depend on that behavior.
  .Sp
! This option is enabled by default on most targets.  On Nios II ELF, it
! defaults to off.  On AVR and MSP430, this option is completely disabled.
  .Sp
  Passes that use the dataflow information
  are enabled independently at different optimization levels.
! .IP \fB\-fdevirtualize\fR 4
  .IX Item "-fdevirtualize"
  Attempt to convert calls to virtual functions to direct calls.  This
  is done both within a procedure and interprocedurally as part of
  indirect inlining (\fB\-findirect\-inlining\fR) and interprocedural constant
  propagation (\fB\-fipa\-cp\fR).
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fdevirtualize\-speculatively\fR 4
  .IX Item "-fdevirtualize-speculatively"
  Attempt to convert calls to virtual functions to speculative direct calls.
  Based on the analysis of the type inheritance graph, determine for a given call
*************** the set of likely targets. If the set is
*** 11627,11655 ****
  the call into a conditional deciding between direct and indirect calls.  The
  speculative calls enable more optimizations, such as inlining.  When they seem
  useless after further optimization, they are converted back into original form.
! .IP "\fB\-fdevirtualize\-at\-ltrans\fR" 4
  .IX Item "-fdevirtualize-at-ltrans"
  Stream extra information needed for aggressive devirtualization when running
! the link-time optimizer in local transformation mode.  
  This option enables more devirtualization but
  significantly increases the size of streamed data. For this reason it is
  disabled by default.
! .IP "\fB\-fexpensive\-optimizations\fR" 4
  .IX Item "-fexpensive-optimizations"
  Perform a number of minor optimizations that are relatively expensive.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-free\fR" 4
  .IX Item "-free"
  Attempt to remove redundant extension instructions.  This is especially
! helpful for the x86\-64 architecture, which implicitly zero-extends in 64\-bit
  registers after writing to their lower 32\-bit half.
  .Sp
  Enabled for Alpha, AArch64 and x86 at levels \fB\-O2\fR,
  \&\fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fno\-lifetime\-dse\fR" 4
  .IX Item "-fno-lifetime-dse"
! In \*(C+ the value of an object is only affected by changes within its
  lifetime: when the constructor begins, the object has an indeterminate
  value, and any changes during the lifetime of the object are dead when
  the object is destroyed.  Normally dead store elimination will take
--- 11556,11584 ----
  the call into a conditional deciding between direct and indirect calls.  The
  speculative calls enable more optimizations, such as inlining.  When they seem
  useless after further optimization, they are converted back into original form.
! .IP \fB\-fdevirtualize\-at\-ltrans\fR 4
  .IX Item "-fdevirtualize-at-ltrans"
  Stream extra information needed for aggressive devirtualization when running
! the link\-time optimizer in local transformation mode.  
  This option enables more devirtualization but
  significantly increases the size of streamed data. For this reason it is
  disabled by default.
! .IP \fB\-fexpensive\-optimizations\fR 4
  .IX Item "-fexpensive-optimizations"
  Perform a number of minor optimizations that are relatively expensive.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-free\fR 4
  .IX Item "-free"
  Attempt to remove redundant extension instructions.  This is especially
! helpful for the x86\-64 architecture, which implicitly zero\-extends in 64\-bit
  registers after writing to their lower 32\-bit half.
  .Sp
  Enabled for Alpha, AArch64 and x86 at levels \fB\-O2\fR,
  \&\fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fno\-lifetime\-dse\fR 4
  .IX Item "-fno-lifetime-dse"
! In C++ the value of an object is only affected by changes within its
  lifetime: when the constructor begins, the object has an indeterminate
  value, and any changes during the lifetime of the object are dead when
  the object is destroyed.  Normally dead store elimination will take
*************** storage) but still treat the object as d
*** 11661,11697 ****
  can use \fB\-flifetime\-dse=1\fR.  The default behavior can be
  explicitly selected with \fB\-flifetime\-dse=2\fR.
  \&\fB\-flifetime\-dse=0\fR is equivalent to \fB\-fno\-lifetime\-dse\fR.
! .IP "\fB\-flive\-range\-shrinkage\fR" 4
  .IX Item "-flive-range-shrinkage"
  Attempt to decrease register pressure through register live range
  shrinkage.  This is helpful for fast processors with small or moderate
  size register sets.
! .IP "\fB\-fira\-algorithm=\fR\fIalgorithm\fR" 4
  .IX Item "-fira-algorithm=algorithm"
  Use the specified coloring algorithm for the integrated register
  allocator.  The \fIalgorithm\fR argument can be \fBpriority\fR, which
! specifies Chow's priority coloring, or \fB\s-1CB\s0\fR, which specifies
! Chaitin-Briggs coloring.  Chaitin-Briggs coloring is not implemented
  for all architectures, but for those targets that do support it, it is
  the default because it generates better code.
! .IP "\fB\-fira\-region=\fR\fIregion\fR" 4
  .IX Item "-fira-region=region"
  Use specified regions for the integrated register allocator.  The
  \&\fIregion\fR argument should be one of the following:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
  Use all loops as register allocation regions.
  This can give the best results for machines with a small and/or
  irregular register set.
! .IP "\fBmixed\fR" 4
  .IX Item "mixed"
  Use all loops except for loops with small register pressure 
  as the regions.  This value usually gives
  the best results in most cases and for most architectures,
  and is enabled by default when compiling with optimization for speed
  (\fB\-O\fR, \fB\-O2\fR, ...).
! .IP "\fBone\fR" 4
  .IX Item "one"
  Use all functions as a single region.  
  This typically results in the smallest code size, and is enabled by default for
--- 11590,11626 ----
  can use \fB\-flifetime\-dse=1\fR.  The default behavior can be
  explicitly selected with \fB\-flifetime\-dse=2\fR.
  \&\fB\-flifetime\-dse=0\fR is equivalent to \fB\-fno\-lifetime\-dse\fR.
! .IP \fB\-flive\-range\-shrinkage\fR 4
  .IX Item "-flive-range-shrinkage"
  Attempt to decrease register pressure through register live range
  shrinkage.  This is helpful for fast processors with small or moderate
  size register sets.
! .IP \fB\-fira\-algorithm=\fR\fIalgorithm\fR 4
  .IX Item "-fira-algorithm=algorithm"
  Use the specified coloring algorithm for the integrated register
  allocator.  The \fIalgorithm\fR argument can be \fBpriority\fR, which
! specifies Chow\*(Aqs priority coloring, or \fBCB\fR, which specifies
! Chaitin\-Briggs coloring.  Chaitin\-Briggs coloring is not implemented
  for all architectures, but for those targets that do support it, it is
  the default because it generates better code.
! .IP \fB\-fira\-region=\fR\fIregion\fR 4
  .IX Item "-fira-region=region"
  Use specified regions for the integrated register allocator.  The
  \&\fIregion\fR argument should be one of the following:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
  Use all loops as register allocation regions.
  This can give the best results for machines with a small and/or
  irregular register set.
! .IP \fBmixed\fR 4
  .IX Item "mixed"
  Use all loops except for loops with small register pressure 
  as the regions.  This value usually gives
  the best results in most cases and for most architectures,
  and is enabled by default when compiling with optimization for speed
  (\fB\-O\fR, \fB\-O2\fR, ...).
! .IP \fBone\fR 4
  .IX Item "one"
  Use all functions as a single region.  
  This typically results in the smallest code size, and is enabled by default for
*************** This typically results in the smallest c
*** 11699,11738 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-fira\-hoist\-pressure\fR" 4
  .IX Item "-fira-hoist-pressure"
! Use \s-1IRA\s0 to evaluate register pressure in the code hoisting pass for
  decisions to hoist expressions.  This option usually results in smaller
  code, but it can slow the compiler down.
  .Sp
  This option is enabled at level \fB\-Os\fR for all targets.
! .IP "\fB\-fira\-loop\-pressure\fR" 4
  .IX Item "-fira-loop-pressure"
! Use \s-1IRA\s0 to evaluate register pressure in loops for decisions to move
  loop invariants.  This option usually results in generation
  of faster and smaller code on machines with large register files (>= 32
  registers), but it can slow the compiler down.
  .Sp
  This option is enabled at level \fB\-O3\fR for some targets.
! .IP "\fB\-fno\-ira\-share\-save\-slots\fR" 4
  .IX Item "-fno-ira-share-save-slots"
! Disable sharing of stack slots used for saving call-used hard
  registers living through a call.  Each hard register gets a
  separate stack slot, and as a result function stack frames are
  larger.
! .IP "\fB\-fno\-ira\-share\-spill\-slots\fR" 4
  .IX Item "-fno-ira-share-spill-slots"
! Disable sharing of stack slots allocated for pseudo-registers.  Each
! pseudo-register that does not get a hard register gets a separate
  stack slot, and as a result function stack frames are larger.
! .IP "\fB\-flra\-remat\fR" 4
  .IX Item "-flra-remat"
! Enable CFG-sensitive rematerialization in \s-1LRA.\s0  Instead of loading
! values of spilled pseudos, \s-1LRA\s0 tries to rematerialize (recalculate)
  values if it is profitable.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fdelayed\-branch\fR" 4
  .IX Item "-fdelayed-branch"
  If supported for the target machine, attempt to reorder instructions
  to exploit instruction slots available after delayed branch
--- 11628,11667 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-fira\-hoist\-pressure\fR 4
  .IX Item "-fira-hoist-pressure"
! Use IRA to evaluate register pressure in the code hoisting pass for
  decisions to hoist expressions.  This option usually results in smaller
  code, but it can slow the compiler down.
  .Sp
  This option is enabled at level \fB\-Os\fR for all targets.
! .IP \fB\-fira\-loop\-pressure\fR 4
  .IX Item "-fira-loop-pressure"
! Use IRA to evaluate register pressure in loops for decisions to move
  loop invariants.  This option usually results in generation
  of faster and smaller code on machines with large register files (>= 32
  registers), but it can slow the compiler down.
  .Sp
  This option is enabled at level \fB\-O3\fR for some targets.
! .IP \fB\-fno\-ira\-share\-save\-slots\fR 4
  .IX Item "-fno-ira-share-save-slots"
! Disable sharing of stack slots used for saving call\-used hard
  registers living through a call.  Each hard register gets a
  separate stack slot, and as a result function stack frames are
  larger.
! .IP \fB\-fno\-ira\-share\-spill\-slots\fR 4
  .IX Item "-fno-ira-share-spill-slots"
! Disable sharing of stack slots allocated for pseudo\-registers.  Each
! pseudo\-register that does not get a hard register gets a separate
  stack slot, and as a result function stack frames are larger.
! .IP \fB\-flra\-remat\fR 4
  .IX Item "-flra-remat"
! Enable CFG\-sensitive rematerialization in LRA.  Instead of loading
! values of spilled pseudos, LRA tries to rematerialize (recalculate)
  values if it is profitable.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fdelayed\-branch\fR 4
  .IX Item "-fdelayed-branch"
  If supported for the target machine, attempt to reorder instructions
  to exploit instruction slots available after delayed branch
*************** instructions.
*** 11740,11755 ****
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR,
  but not at \fB\-Og\fR.
! .IP "\fB\-fschedule\-insns\fR" 4
  .IX Item "-fschedule-insns"
  If supported for the target machine, attempt to reorder instructions to
  eliminate execution stalls due to required data being unavailable.  This
  helps machines that have slow floating point or memory load instructions
  by allowing other instructions to be issued until the result of the load
! or floating-point instruction is required.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-fschedule\-insns2\fR" 4
  .IX Item "-fschedule-insns2"
  Similar to \fB\-fschedule\-insns\fR, but requests an additional pass of
  instruction scheduling after register allocation has been done.  This is
--- 11669,11684 ----
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR,
  but not at \fB\-Og\fR.
! .IP \fB\-fschedule\-insns\fR 4
  .IX Item "-fschedule-insns"
  If supported for the target machine, attempt to reorder instructions to
  eliminate execution stalls due to required data being unavailable.  This
  helps machines that have slow floating point or memory load instructions
  by allowing other instructions to be issued until the result of the load
! or floating\-point instruction is required.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-fschedule\-insns2\fR 4
  .IX Item "-fschedule-insns2"
  Similar to \fB\-fschedule\-insns\fR, but requests an additional pass of
  instruction scheduling after register allocation has been done.  This is
*************** especially useful on machines with a rel
*** 11757,11773 ****
  registers and where memory load instructions take more than one cycle.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fno\-sched\-interblock\fR" 4
  .IX Item "-fno-sched-interblock"
  Disable instruction scheduling across basic blocks, which
  is normally enabled when scheduling before register allocation, i.e.
  with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fno\-sched\-spec\fR" 4
  .IX Item "-fno-sched-spec"
! Disable speculative motion of non-load instructions, which
  is normally enabled when scheduling before register allocation, i.e.
  with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-pressure\fR" 4
  .IX Item "-fsched-pressure"
  Enable register pressure sensitive insn scheduling before register
  allocation.  This only makes sense when scheduling before register
--- 11686,11702 ----
  registers and where memory load instructions take more than one cycle.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fno\-sched\-interblock\fR 4
  .IX Item "-fno-sched-interblock"
  Disable instruction scheduling across basic blocks, which
  is normally enabled when scheduling before register allocation, i.e.
  with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fno\-sched\-spec\fR 4
  .IX Item "-fno-sched-spec"
! Disable speculative motion of non\-load instructions, which
  is normally enabled when scheduling before register allocation, i.e.
  with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-pressure\fR 4
  .IX Item "-fsched-pressure"
  Enable register pressure sensitive insn scheduling before register
  allocation.  This only makes sense when scheduling before register
*************** allocation is enabled, i.e. with \fB\-fs
*** 11776,11795 ****
  generated code and decrease its size by preventing register pressure
  increase above the number of available hard registers and subsequent
  spills in register allocation.
! .IP "\fB\-fsched\-spec\-load\fR" 4
  .IX Item "-fsched-spec-load"
  Allow speculative motion of some load instructions.  This only makes
  sense when scheduling before register allocation, i.e. with
  \&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-spec\-load\-dangerous\fR" 4
  .IX Item "-fsched-spec-load-dangerous"
  Allow speculative motion of more load instructions.  This only makes
  sense when scheduling before register allocation, i.e. with
  \&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-stalled\-insns\fR" 4
  .IX Item "-fsched-stalled-insns"
  .PD 0
! .IP "\fB\-fsched\-stalled\-insns=\fR\fIn\fR" 4
  .IX Item "-fsched-stalled-insns=n"
  .PD
  Define how many insns (if any) can be moved prematurely from the queue
--- 11705,11724 ----
  generated code and decrease its size by preventing register pressure
  increase above the number of available hard registers and subsequent
  spills in register allocation.
! .IP \fB\-fsched\-spec\-load\fR 4
  .IX Item "-fsched-spec-load"
  Allow speculative motion of some load instructions.  This only makes
  sense when scheduling before register allocation, i.e. with
  \&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-spec\-load\-dangerous\fR 4
  .IX Item "-fsched-spec-load-dangerous"
  Allow speculative motion of more load instructions.  This only makes
  sense when scheduling before register allocation, i.e. with
  \&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-stalled\-insns\fR 4
  .IX Item "-fsched-stalled-insns"
  .PD 0
! .IP \fB\-fsched\-stalled\-insns=\fR\fIn\fR 4
  .IX Item "-fsched-stalled-insns=n"
  .PD
  Define how many insns (if any) can be moved prematurely from the queue
*************** prematurely, \fB\-fsched\-stalled\-insns
*** 11799,11808 ****
  on how many queued insns can be moved prematurely.
  \&\fB\-fsched\-stalled\-insns\fR without a value is equivalent to
  \&\fB\-fsched\-stalled\-insns=1\fR.
! .IP "\fB\-fsched\-stalled\-insns\-dep\fR" 4
  .IX Item "-fsched-stalled-insns-dep"
  .PD 0
! .IP "\fB\-fsched\-stalled\-insns\-dep=\fR\fIn\fR" 4
  .IX Item "-fsched-stalled-insns-dep=n"
  .PD
  Define how many insn groups (cycles) are examined for a dependency
--- 11728,11737 ----
  on how many queued insns can be moved prematurely.
  \&\fB\-fsched\-stalled\-insns\fR without a value is equivalent to
  \&\fB\-fsched\-stalled\-insns=1\fR.
! .IP \fB\-fsched\-stalled\-insns\-dep\fR 4
  .IX Item "-fsched-stalled-insns-dep"
  .PD 0
! .IP \fB\-fsched\-stalled\-insns\-dep=\fR\fIn\fR 4
  .IX Item "-fsched-stalled-insns-dep=n"
  .PD
  Define how many insn groups (cycles) are examined for a dependency
*************** and only if \fB\-fsched\-stalled\-insns\
*** 11813,11895 ****
  \&\fB\-fsched\-stalled\-insns\-dep=0\fR.
  \&\fB\-fsched\-stalled\-insns\-dep\fR without a value is equivalent to
  \&\fB\-fsched\-stalled\-insns\-dep=1\fR.
! .IP "\fB\-fsched2\-use\-superblocks\fR" 4
  .IX Item "-fsched2-use-superblocks"
  When scheduling after register allocation, use superblock scheduling.
  This allows motion across basic block boundaries,
  resulting in faster schedules.  This option is experimental, as not all machine
! descriptions used by \s-1GCC\s0 model the \s-1CPU\s0 closely enough to avoid unreliable
  results from the algorithm.
  .Sp
  This only makes sense when scheduling after register allocation, i.e. with
  \&\fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-group\-heuristic\fR" 4
  .IX Item "-fsched-group-heuristic"
  Enable the group heuristic in the scheduler.  This heuristic favors
  the instruction that belongs to a schedule group.  This is enabled
  by default when scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
  or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-critical\-path\-heuristic\fR" 4
  .IX Item "-fsched-critical-path-heuristic"
! Enable the critical-path heuristic in the scheduler.  This heuristic favors
  instructions on the critical path.  This is enabled by default when
  scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
  or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-spec\-insn\-heuristic\fR" 4
  .IX Item "-fsched-spec-insn-heuristic"
  Enable the speculative instruction heuristic in the scheduler.  This
  heuristic favors speculative instructions with greater dependency weakness.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR
  or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-rank\-heuristic\fR" 4
  .IX Item "-fsched-rank-heuristic"
  Enable the rank heuristic in the scheduler.  This heuristic favors
  the instruction belonging to a basic block with greater size or frequency.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-last\-insn\-heuristic\fR" 4
  .IX Item "-fsched-last-insn-heuristic"
! Enable the last-instruction heuristic in the scheduler.  This heuristic
  favors the instruction that is less dependent on the last instruction
  scheduled.  This is enabled by default when scheduling is enabled,
  i.e. with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-dep\-count\-heuristic\fR" 4
  .IX Item "-fsched-dep-count-heuristic"
! Enable the dependent-count heuristic in the scheduler.  This heuristic
  favors the instruction that has more instructions depending on it.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP "\fB\-freschedule\-modulo\-scheduled\-loops\fR" 4
  .IX Item "-freschedule-modulo-scheduled-loops"
  Modulo scheduling is performed before traditional scheduling.  If a loop
  is modulo scheduled, later scheduling passes may change its schedule.  
  Use this option to control that behavior.
! .IP "\fB\-fselective\-scheduling\fR" 4
  .IX Item "-fselective-scheduling"
  Schedule instructions using selective scheduling algorithm.  Selective
  scheduling runs instead of the first scheduler pass.
! .IP "\fB\-fselective\-scheduling2\fR" 4
  .IX Item "-fselective-scheduling2"
  Schedule instructions using selective scheduling algorithm.  Selective
  scheduling runs instead of the second scheduler pass.
! .IP "\fB\-fsel\-sched\-pipelining\fR" 4
  .IX Item "-fsel-sched-pipelining"
  Enable software pipelining of innermost loops during selective scheduling.
  This option has no effect unless one of \fB\-fselective\-scheduling\fR or
  \&\fB\-fselective\-scheduling2\fR is turned on.
! .IP "\fB\-fsel\-sched\-pipelining\-outer\-loops\fR" 4
  .IX Item "-fsel-sched-pipelining-outer-loops"
  When pipelining loops during selective scheduling, also pipeline outer loops.
  This option has no effect unless \fB\-fsel\-sched\-pipelining\fR is turned on.
! .IP "\fB\-fsemantic\-interposition\fR" 4
  .IX Item "-fsemantic-interposition"
! Some object formats, like \s-1ELF,\s0 allow interposing of symbols by the 
  dynamic linker.
! This means that for symbols exported from the \s-1DSO,\s0 the compiler cannot perform
  interprocedural propagation, inlining and other optimizations in anticipation
  that the function or variable in question may change. While this feature is
  useful, for example, to rewrite memory allocation functions by a debugging
--- 11742,11824 ----
  \&\fB\-fsched\-stalled\-insns\-dep=0\fR.
  \&\fB\-fsched\-stalled\-insns\-dep\fR without a value is equivalent to
  \&\fB\-fsched\-stalled\-insns\-dep=1\fR.
! .IP \fB\-fsched2\-use\-superblocks\fR 4
  .IX Item "-fsched2-use-superblocks"
  When scheduling after register allocation, use superblock scheduling.
  This allows motion across basic block boundaries,
  resulting in faster schedules.  This option is experimental, as not all machine
! descriptions used by GCC model the CPU closely enough to avoid unreliable
  results from the algorithm.
  .Sp
  This only makes sense when scheduling after register allocation, i.e. with
  \&\fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-group\-heuristic\fR 4
  .IX Item "-fsched-group-heuristic"
  Enable the group heuristic in the scheduler.  This heuristic favors
  the instruction that belongs to a schedule group.  This is enabled
  by default when scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
  or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-critical\-path\-heuristic\fR 4
  .IX Item "-fsched-critical-path-heuristic"
! Enable the critical\-path heuristic in the scheduler.  This heuristic favors
  instructions on the critical path.  This is enabled by default when
  scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
  or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-spec\-insn\-heuristic\fR 4
  .IX Item "-fsched-spec-insn-heuristic"
  Enable the speculative instruction heuristic in the scheduler.  This
  heuristic favors speculative instructions with greater dependency weakness.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR
  or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-rank\-heuristic\fR 4
  .IX Item "-fsched-rank-heuristic"
  Enable the rank heuristic in the scheduler.  This heuristic favors
  the instruction belonging to a basic block with greater size or frequency.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-last\-insn\-heuristic\fR 4
  .IX Item "-fsched-last-insn-heuristic"
! Enable the last\-instruction heuristic in the scheduler.  This heuristic
  favors the instruction that is less dependent on the last instruction
  scheduled.  This is enabled by default when scheduling is enabled,
  i.e. with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-dep\-count\-heuristic\fR 4
  .IX Item "-fsched-dep-count-heuristic"
! Enable the dependent\-count heuristic in the scheduler.  This heuristic
  favors the instruction that has more instructions depending on it.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP \fB\-freschedule\-modulo\-scheduled\-loops\fR 4
  .IX Item "-freschedule-modulo-scheduled-loops"
  Modulo scheduling is performed before traditional scheduling.  If a loop
  is modulo scheduled, later scheduling passes may change its schedule.  
  Use this option to control that behavior.
! .IP \fB\-fselective\-scheduling\fR 4
  .IX Item "-fselective-scheduling"
  Schedule instructions using selective scheduling algorithm.  Selective
  scheduling runs instead of the first scheduler pass.
! .IP \fB\-fselective\-scheduling2\fR 4
  .IX Item "-fselective-scheduling2"
  Schedule instructions using selective scheduling algorithm.  Selective
  scheduling runs instead of the second scheduler pass.
! .IP \fB\-fsel\-sched\-pipelining\fR 4
  .IX Item "-fsel-sched-pipelining"
  Enable software pipelining of innermost loops during selective scheduling.
  This option has no effect unless one of \fB\-fselective\-scheduling\fR or
  \&\fB\-fselective\-scheduling2\fR is turned on.
! .IP \fB\-fsel\-sched\-pipelining\-outer\-loops\fR 4
  .IX Item "-fsel-sched-pipelining-outer-loops"
  When pipelining loops during selective scheduling, also pipeline outer loops.
  This option has no effect unless \fB\-fsel\-sched\-pipelining\fR is turned on.
! .IP \fB\-fsemantic\-interposition\fR 4
  .IX Item "-fsemantic-interposition"
! Some object formats, like ELF, allow interposing of symbols by the 
  dynamic linker.
! This means that for symbols exported from the DSO, the compiler cannot perform
  interprocedural propagation, inlining and other optimizations in anticipation
  that the function or variable in question may change. While this feature is
  useful, for example, to rewrite memory allocation functions by a debugging
*************** for variables, the constructor of the va
*** 11902,11919 ****
  has no effect for functions explicitly declared inline 
  (where it is never allowed for interposition to change semantics) 
  and for symbols explicitly declared weak.
! .IP "\fB\-fshrink\-wrap\fR" 4
  .IX Item "-fshrink-wrap"
  Emit function prologues only before parts of the function that need it,
  rather than at the top of the function.  This flag is enabled by default at
  \&\fB\-O\fR and higher.
! .IP "\fB\-fshrink\-wrap\-separate\fR" 4
  .IX Item "-fshrink-wrap-separate"
! Shrink-wrap separate parts of the prologue and epilogue separately, so that
  those parts are only executed when needed.
  This option is on by default, but has no effect unless \fB\-fshrink\-wrap\fR
  is also turned on and the target supports this.
! .IP "\fB\-fcaller\-saves\fR" 4
  .IX Item "-fcaller-saves"
  Enable allocation of values to registers that are clobbered by
  function calls, by emitting extra instructions to save and restore the
--- 11831,11848 ----
  has no effect for functions explicitly declared inline 
  (where it is never allowed for interposition to change semantics) 
  and for symbols explicitly declared weak.
! .IP \fB\-fshrink\-wrap\fR 4
  .IX Item "-fshrink-wrap"
  Emit function prologues only before parts of the function that need it,
  rather than at the top of the function.  This flag is enabled by default at
  \&\fB\-O\fR and higher.
! .IP \fB\-fshrink\-wrap\-separate\fR 4
  .IX Item "-fshrink-wrap-separate"
! Shrink\-wrap separate parts of the prologue and epilogue separately, so that
  those parts are only executed when needed.
  This option is on by default, but has no effect unless \fB\-fshrink\-wrap\fR
  is also turned on and the target supports this.
! .IP \fB\-fcaller\-saves\fR 4
  .IX Item "-fcaller-saves"
  Enable allocation of values to registers that are clobbered by
  function calls, by emitting extra instructions to save and restore the
*************** registers around such calls.  Such alloc
*** 11921,11936 ****
  seems to result in better code.
  .Sp
  This option is always enabled by default on certain machines, usually
! those which have no call-preserved registers to use instead.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fcombine\-stack\-adjustments\fR" 4
  .IX Item "-fcombine-stack-adjustments"
  Tracks stack adjustments (pushes and pops) and stack memory references
  and then tries to find ways to combine them.
  .Sp
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-ra\fR" 4
  .IX Item "-fipa-ra"
  Use caller save registers for allocation if those registers are not used by
  any called function.  In that case it is not necessary to save and restore
--- 11850,11865 ----
  seems to result in better code.
  .Sp
  This option is always enabled by default on certain machines, usually
! those which have no call\-preserved registers to use instead.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fcombine\-stack\-adjustments\fR 4
  .IX Item "-fcombine-stack-adjustments"
  Tracks stack adjustments (pushes and pops) and stack memory references
  and then tries to find ways to combine them.
  .Sp
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-ra\fR 4
  .IX Item "-fipa-ra"
  Use caller save registers for allocation if those registers are not used by
  any called function.  In that case it is not necessary to save and restore
*************** same compilation unit as current functio
*** 11939,12022 ****
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, however the option
  is disabled if generated code will be instrumented for profiling
! (\fB\-p\fR, or \fB\-pg\fR) or if callee's register usage cannot be known
  exactly (this happens on targets that do not expose prologues
! and epilogues in \s-1RTL\s0).
! .IP "\fB\-fconserve\-stack\fR" 4
  .IX Item "-fconserve-stack"
  Attempt to minimize stack usage.  The compiler attempts to use less
  stack space, even if that makes the program slower.  This option
! implies setting the \fBlarge-stack-frame\fR parameter to 100
! and the \fBlarge-stack-frame-growth\fR parameter to 400.
! .IP "\fB\-ftree\-reassoc\fR" 4
  .IX Item "-ftree-reassoc"
  Perform reassociation on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP "\fB\-fcode\-hoisting\fR" 4
  .IX Item "-fcode-hoisting"
  Perform code hoisting.  Code hoisting tries to move the
  evaluation of expressions executed on all paths to the function exit
  as early as possible.  This is especially useful as a code size
  optimization, but it often helps for code speed as well.
  This flag is enabled by default at \fB\-O2\fR and higher.
! .IP "\fB\-ftree\-pre\fR" 4
  .IX Item "-ftree-pre"
! Perform partial redundancy elimination (\s-1PRE\s0) on trees.  This flag is
  enabled by default at \fB\-O2\fR and \fB\-O3\fR.
! .IP "\fB\-ftree\-partial\-pre\fR" 4
  .IX Item "-ftree-partial-pre"
! Make partial redundancy elimination (\s-1PRE\s0) more aggressive.  This flag is
  enabled by default at \fB\-O3\fR.
! .IP "\fB\-ftree\-forwprop\fR" 4
  .IX Item "-ftree-forwprop"
  Perform forward propagation on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-fre\fR" 4
  .IX Item "-ftree-fre"
! Perform full redundancy elimination (\s-1FRE\s0) on trees.  The difference
! between \s-1FRE\s0 and \s-1PRE\s0 is that \s-1FRE\s0 only considers expressions
  that are computed on all paths leading to the redundant computation.
! This analysis is faster than \s-1PRE,\s0 though it exposes fewer redundancies.
  This flag is enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-phiprop\fR" 4
  .IX Item "-ftree-phiprop"
  Perform hoisting of loads from conditional pointers on trees.  This
  pass is enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fhoist\-adjacent\-loads\fR" 4
  .IX Item "-fhoist-adjacent-loads"
! Speculatively hoist loads from both branches of an if-then-else if the
  loads are from adjacent locations in the same structure and the target
  architecture has a conditional move instruction.  This flag is enabled
  by default at \fB\-O2\fR and higher.
! .IP "\fB\-ftree\-copy\-prop\fR" 4
  .IX Item "-ftree-copy-prop"
  Perform copy propagation on trees.  This pass eliminates unnecessary
  copy operations.  This flag is enabled by default at \fB\-O1\fR and
  higher.
! .IP "\fB\-fipa\-pure\-const\fR" 4
  .IX Item "-fipa-pure-const"
  Discover which functions are pure or constant.
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-reference\fR" 4
  .IX Item "-fipa-reference"
  Discover which static variables do not escape the
  compilation unit.
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-reference\-addressable\fR" 4
  .IX Item "-fipa-reference-addressable"
! Discover read-only, write-only and non-addressable static variables.
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-stack\-alignment\fR" 4
  .IX Item "-fipa-stack-alignment"
  Reduce stack alignment on call sites if possible.
  Enabled by default.
! .IP "\fB\-fipa\-pta\fR" 4
  .IX Item "-fipa-pta"
  Perform interprocedural pointer analysis and interprocedural modification
  and reference analysis.  This option can cause excessive memory and
! compile-time usage on large compilation units.  It is not enabled by
  default at any optimization level.
! .IP "\fB\-fipa\-profile\fR" 4
  .IX Item "-fipa-profile"
  Perform interprocedural profile propagation.  The functions called only from
  cold functions are marked as cold. Also functions executed once (such as
--- 11868,11951 ----
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, however the option
  is disabled if generated code will be instrumented for profiling
! (\fB\-p\fR, or \fB\-pg\fR) or if callee\*(Aqs register usage cannot be known
  exactly (this happens on targets that do not expose prologues
! and epilogues in RTL).
! .IP \fB\-fconserve\-stack\fR 4
  .IX Item "-fconserve-stack"
  Attempt to minimize stack usage.  The compiler attempts to use less
  stack space, even if that makes the program slower.  This option
! implies setting the \fBlarge\-stack\-frame\fR parameter to 100
! and the \fBlarge\-stack\-frame\-growth\fR parameter to 400.
! .IP \fB\-ftree\-reassoc\fR 4
  .IX Item "-ftree-reassoc"
  Perform reassociation on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP \fB\-fcode\-hoisting\fR 4
  .IX Item "-fcode-hoisting"
  Perform code hoisting.  Code hoisting tries to move the
  evaluation of expressions executed on all paths to the function exit
  as early as possible.  This is especially useful as a code size
  optimization, but it often helps for code speed as well.
  This flag is enabled by default at \fB\-O2\fR and higher.
! .IP \fB\-ftree\-pre\fR 4
  .IX Item "-ftree-pre"
! Perform partial redundancy elimination (PRE) on trees.  This flag is
  enabled by default at \fB\-O2\fR and \fB\-O3\fR.
! .IP \fB\-ftree\-partial\-pre\fR 4
  .IX Item "-ftree-partial-pre"
! Make partial redundancy elimination (PRE) more aggressive.  This flag is
  enabled by default at \fB\-O3\fR.
! .IP \fB\-ftree\-forwprop\fR 4
  .IX Item "-ftree-forwprop"
  Perform forward propagation on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-fre\fR 4
  .IX Item "-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 \fB\-O1\fR and higher.
! .IP \fB\-ftree\-phiprop\fR 4
  .IX Item "-ftree-phiprop"
  Perform hoisting of loads from conditional pointers on trees.  This
  pass is enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fhoist\-adjacent\-loads\fR 4
  .IX Item "-fhoist-adjacent-loads"
! Speculatively hoist loads from both branches of an if\-then\-else if the
  loads are from adjacent locations in the same structure and the target
  architecture has a conditional move instruction.  This flag is enabled
  by default at \fB\-O2\fR and higher.
! .IP \fB\-ftree\-copy\-prop\fR 4
  .IX Item "-ftree-copy-prop"
  Perform copy propagation on trees.  This pass eliminates unnecessary
  copy operations.  This flag is enabled by default at \fB\-O1\fR and
  higher.
! .IP \fB\-fipa\-pure\-const\fR 4
  .IX Item "-fipa-pure-const"
  Discover which functions are pure or constant.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-reference\fR 4
  .IX Item "-fipa-reference"
  Discover which static variables do not escape the
  compilation unit.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-reference\-addressable\fR 4
  .IX Item "-fipa-reference-addressable"
! Discover read\-only, write\-only and non\-addressable static variables.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-stack\-alignment\fR 4
  .IX Item "-fipa-stack-alignment"
  Reduce stack alignment on call sites if possible.
  Enabled by default.
! .IP \fB\-fipa\-pta\fR 4
  .IX Item "-fipa-pta"
  Perform interprocedural pointer analysis and interprocedural modification
  and reference analysis.  This option can cause excessive memory and
! compile\-time usage on large compilation units.  It is not enabled by
  default at any optimization level.
! .IP \fB\-fipa\-profile\fR 4
  .IX Item "-fipa-profile"
  Perform interprocedural profile propagation.  The functions called only from
  cold functions are marked as cold. Also functions executed once (such as
*************** cold functions are marked as cold. Also
*** 12024,12036 ****
  identified. Cold functions and loop less parts of functions executed once are
  then optimized for size.
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-modref\fR" 4
  .IX Item "-fipa-modref"
  Perform interprocedural mod/ref analysis.  This optimization analyzes the side
  effects of functions (memory locations that are modified or referenced) and
  enables better optimization across the function call boundary.  This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-cp\fR" 4
  .IX Item "-fipa-cp"
  Perform interprocedural constant propagation.
  This optimization analyzes the program to determine when values passed
--- 11953,11965 ----
  identified. Cold functions and loop less parts of functions executed once are
  then optimized for size.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-modref\fR 4
  .IX Item "-fipa-modref"
  Perform interprocedural mod/ref analysis.  This optimization analyzes the side
  effects of functions (memory locations that are modified or referenced) and
  enables better optimization across the function call boundary.  This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-cp\fR 4
  .IX Item "-fipa-cp"
  Perform interprocedural constant propagation.
  This optimization analyzes the program to determine when values passed
*************** This optimization can substantially incr
*** 12039,12045 ****
  if the application has constants passed to functions.
  This flag is enabled by default at \fB\-O2\fR, \fB\-Os\fR and \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-fipa\-cp\-clone\fR" 4
  .IX Item "-fipa-cp-clone"
  Perform function cloning to make interprocedural constant propagation stronger.
  When enabled, interprocedural constant propagation performs function cloning
--- 11968,11974 ----
  if the application has constants passed to functions.
  This flag is enabled by default at \fB\-O2\fR, \fB\-Os\fR and \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-fipa\-cp\-clone\fR 4
  .IX Item "-fipa-cp-clone"
  Perform function cloning to make interprocedural constant propagation stronger.
  When enabled, interprocedural constant propagation performs function cloning
*************** it may significantly increase code size
*** 12049,12105 ****
  (see \fB\-\-param ipa\-cp\-unit\-growth=\fR\fIvalue\fR).
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-fipa\-bit\-cp\fR" 4
  .IX Item "-fipa-bit-cp"
  When enabled, perform interprocedural bitwise constant
  propagation. This flag is enabled by default at \fB\-O2\fR and
  by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
  It requires that \fB\-fipa\-cp\fR is enabled.
! .IP "\fB\-fipa\-vrp\fR" 4
  .IX Item "-fipa-vrp"
  When enabled, perform interprocedural propagation of value
  ranges. This flag is enabled by default at \fB\-O2\fR. It requires
  that \fB\-fipa\-cp\fR is enabled.
! .IP "\fB\-fipa\-icf\fR" 4
  .IX Item "-fipa-icf"
! Perform Identical Code Folding for functions and read-only variables.
  The optimization reduces code size and may disturb unwind stacks by replacing
  a function by equivalent one with a different name. The optimization works
! more effectively with link-time optimization enabled.
  .Sp
! Although the behavior is similar to the Gold Linker's \s-1ICF\s0 optimization, \s-1GCC ICF\s0
  works on different levels and thus the optimizations are not same \- there are
! equivalences that are found only by \s-1GCC\s0 and equivalences found only by Gold.
  .Sp
  This flag is enabled by default at \fB\-O2\fR and \fB\-Os\fR.
! .IP "\fB\-flive\-patching=\fR\fIlevel\fR" 4
  .IX Item "-flive-patching=level"
! Control \s-1GCC\s0's optimizations to produce output suitable for live-patching.
  .Sp
! If the compiler's optimization uses a function's body or information extracted
  from its body to optimize/change another function, the latter is called an
  impacted function of the former.  If a function is patched, its impacted
  functions should be patched too.
  .Sp
! The impacted functions are determined by the compiler's interprocedural
  optimizations.  For example, a caller is impacted when inlining a function
  into its caller,
  cloning a function and changing its caller to call this new clone,
! or extracting a function's pureness/constness information to optimize
  its direct or indirect callers, etc.
  .Sp
! Usually, the more \s-1IPA\s0 optimizations enabled, the larger the number of
  impacted functions for each function.  In order to control the number of
  impacted functions and more easily compute the list of impacted function,
! \&\s-1IPA\s0 optimizations can be partially enabled at two different levels.
  .Sp
  The \fIlevel\fR argument should be one of the following:
  .RS 4
! .IP "\fBinline-clone\fR" 4
  .IX Item "inline-clone"
  Only enable inlining and cloning optimizations, which includes inlining,
  cloning, interprocedural scalar replacement of aggregates and partial inlining.
! As a result, when patching a function, all its callers and its clones'
  callers are impacted, therefore need to be patched as well.
  .Sp
  \&\fB\-flive\-patching=inline\-clone\fR disables the following optimization flags:
--- 11978,12034 ----
  (see \fB\-\-param ipa\-cp\-unit\-growth=\fR\fIvalue\fR).
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-fipa\-bit\-cp\fR 4
  .IX Item "-fipa-bit-cp"
  When enabled, perform interprocedural bitwise constant
  propagation. This flag is enabled by default at \fB\-O2\fR and
  by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
  It requires that \fB\-fipa\-cp\fR is enabled.
! .IP \fB\-fipa\-vrp\fR 4
  .IX Item "-fipa-vrp"
  When enabled, perform interprocedural propagation of value
  ranges. This flag is enabled by default at \fB\-O2\fR. It requires
  that \fB\-fipa\-cp\fR is enabled.
! .IP \fB\-fipa\-icf\fR 4
  .IX Item "-fipa-icf"
! Perform Identical Code Folding for functions and read\-only variables.
  The optimization reduces code size and may disturb unwind stacks by replacing
  a function by equivalent one with a different name. The optimization works
! more effectively with link\-time optimization enabled.
  .Sp
! Although the behavior is similar to the Gold Linker\*(Aqs ICF optimization, GCC ICF
  works on different levels and thus the optimizations are not same \- there are
! equivalences that are found only by GCC and equivalences found only by Gold.
  .Sp
  This flag is enabled by default at \fB\-O2\fR and \fB\-Os\fR.
! .IP \fB\-flive\-patching=\fR\fIlevel\fR 4
  .IX Item "-flive-patching=level"
! Control GCC\*(Aqs optimizations to produce output suitable for live\-patching.
  .Sp
! If the compiler\*(Aqs optimization uses a function\*(Aqs body or information extracted
  from its body to optimize/change another function, the latter is called an
  impacted function of the former.  If a function is patched, its impacted
  functions should be patched too.
  .Sp
! The impacted functions are determined by the compiler\*(Aqs interprocedural
  optimizations.  For example, a caller is impacted when inlining a function
  into its caller,
  cloning a function and changing its caller to call this new clone,
! or extracting a function\*(Aqs pureness/constness information to optimize
  its direct or indirect callers, etc.
  .Sp
! Usually, the more IPA optimizations enabled, the larger the number of
  impacted functions for each function.  In order to control the number of
  impacted functions and more easily compute the list of impacted function,
! IPA optimizations can be partially enabled at two different levels.
  .Sp
  The \fIlevel\fR argument should be one of the following:
  .RS 4
! .IP \fBinline\-clone\fR 4
  .IX Item "inline-clone"
  Only enable inlining and cloning optimizations, which includes inlining,
  cloning, interprocedural scalar replacement of aggregates and partial inlining.
! As a result, when patching a function, all its callers and its clones\*(Aq
  callers are impacted, therefore need to be patched as well.
  .Sp
  \&\fB\-flive\-patching=inline\-clone\fR disables the following optimization flags:
*************** callers are impacted, therefore need to
*** 12108,12114 ****
  \&\-fipa\-bit\-cp  \-fipa\-vrp  \-fipa\-pure\-const
  \&\-fipa\-reference\-addressable
  \&\-fipa\-stack\-alignment \-fipa\-modref\fR
! .IP "\fBinline-only-static\fR" 4
  .IX Item "inline-only-static"
  Only enable inlining of static functions.
  As a result, when patching a static function, all its callers are impacted
--- 12037,12043 ----
  \&\-fipa\-bit\-cp  \-fipa\-vrp  \-fipa\-pure\-const
  \&\-fipa\-reference\-addressable
  \&\-fipa\-stack\-alignment \-fipa\-modref\fR
! .IP \fBinline\-only\-static\fR 4
  .IX Item "inline-only-static"
  Only enable inlining of static functions.
  As a result, when patching a static function, all its callers are impacted
*************** optimization flags:
*** 12123,12279 ****
  .RS 4
  .Sp
  When \fB\-flive\-patching\fR is specified without any value, the default value
! is \fIinline-clone\fR.
  .Sp
  This flag is disabled by default.
  .Sp
! Note that \fB\-flive\-patching\fR is not supported with link-time optimization
  (\fB\-flto\fR).
  .RE
! .IP "\fB\-fisolate\-erroneous\-paths\-dereference\fR" 4
  .IX Item "-fisolate-erroneous-paths-dereference"
  Detect paths that trigger erroneous or undefined behavior due to
  dereferencing a null pointer.  Isolate those paths from the main control
  flow and turn the statement with erroneous or undefined behavior into a trap.
  This flag is enabled by default at \fB\-O2\fR and higher and depends on
  \&\fB\-fdelete\-null\-pointer\-checks\fR also being enabled.
! .IP "\fB\-fisolate\-erroneous\-paths\-attribute\fR" 4
  .IX Item "-fisolate-erroneous-paths-attribute"
  Detect paths that trigger erroneous or undefined behavior due to a null value
  being used in a way forbidden by a \f(CW\*(C`returns_nonnull\*(C'\fR or \f(CW\*(C`nonnull\*(C'\fR
  attribute.  Isolate those paths from the main control flow and turn the
  statement with erroneous or undefined behavior into a trap.  This is not
  currently enabled, but may be enabled by \fB\-O2\fR in the future.
! .IP "\fB\-ftree\-sink\fR" 4
  .IX Item "-ftree-sink"
  Perform forward store motion on trees.  This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-bit\-ccp\fR" 4
  .IX Item "-ftree-bit-ccp"
  Perform sparse conditional bit constant propagation on trees and propagate
  pointer alignment information.
  This pass only operates on local scalar variables and is enabled by default
  at \fB\-O1\fR and higher, except for \fB\-Og\fR.
  It requires that \fB\-ftree\-ccp\fR is enabled.
! .IP "\fB\-ftree\-ccp\fR" 4
  .IX Item "-ftree-ccp"
! Perform sparse conditional constant propagation (\s-1CCP\s0) on trees.  This
  pass only operates on local scalar variables and is enabled by default
  at \fB\-O1\fR and higher.
! .IP "\fB\-fssa\-backprop\fR" 4
  .IX Item "-fssa-backprop"
  Propagate information about uses of a value up the definition chain
  in order to simplify the definitions.  For example, this pass strips
  sign operations if the sign of a value never matters.  The flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fssa\-phiopt\fR" 4
  .IX Item "-fssa-phiopt"
! Perform pattern matching on \s-1SSA PHI\s0 nodes to optimize conditional
  code.  This pass is enabled by default at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP "\fB\-ftree\-switch\-conversion\fR" 4
  .IX Item "-ftree-switch-conversion"
  Perform conversion of simple initializations in a switch to
  initializations from a scalar array.  This flag is enabled by default
  at \fB\-O2\fR and higher.
! .IP "\fB\-ftree\-tail\-merge\fR" 4
  .IX Item "-ftree-tail-merge"
  Look for identical code sequences.  When found, replace one with a jump to the
  other.  This optimization is known as tail merging or cross jumping.  This flag
  is enabled by default at \fB\-O2\fR and higher.  The compilation time
  in this pass can
! be limited using \fBmax-tail-merge-comparisons\fR parameter and
! \&\fBmax-tail-merge-iterations\fR parameter.
! .IP "\fB\-ftree\-dce\fR" 4
  .IX Item "-ftree-dce"
! Perform dead code elimination (\s-1DCE\s0) on trees.  This flag is enabled by
  default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-builtin\-call\-dce\fR" 4
  .IX Item "-ftree-builtin-call-dce"
! Perform conditional dead code elimination (\s-1DCE\s0) for calls to built-in functions
  that may set \f(CW\*(C`errno\*(C'\fR but are otherwise free of side effects.  This flag is
  enabled by default at \fB\-O2\fR and higher if \fB\-Os\fR is not also
  specified.
! .IP "\fB\-ffinite\-loops\fR" 4
  .IX Item "-ffinite-loops"
  Assume that a loop with an exit will eventually take the exit and not loop
  indefinitely.  This allows the compiler to remove loops that otherwise have
! no side-effects, not considering eventual endless looping as such.
  .Sp
! This option is enabled by default at \fB\-O2\fR for \*(C+ with \-std=c++11
  or higher.
! .IP "\fB\-ftree\-dominator\-opts\fR" 4
  .IX Item "-ftree-dominator-opts"
  Perform a variety of simple scalar cleanups (constant/copy
  propagation, redundancy elimination, range propagation and expression
  simplification) based on a dominator tree traversal.  This also
  performs jump threading (to reduce jumps to jumps). This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-dse\fR" 4
  .IX Item "-ftree-dse"
! Perform dead store elimination (\s-1DSE\s0) on trees.  A dead store is a store into
  a memory location that is later overwritten by another store without
  any intervening loads.  In this case the earlier store can be deleted.  This
  flag is enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-ch\fR" 4
  .IX Item "-ftree-ch"
  Perform loop header copying on trees.  This is beneficial since it increases
  effectiveness of code motion optimizations.  It also saves one jump.  This flag
  is enabled by default at \fB\-O1\fR and higher.  It is not enabled
  for \fB\-Os\fR, since it usually increases code size.
! .IP "\fB\-ftree\-loop\-optimize\fR" 4
  .IX Item "-ftree-loop-optimize"
  Perform loop optimizations on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-loop\-linear\fR" 4
  .IX Item "-ftree-loop-linear"
  .PD 0
! .IP "\fB\-floop\-strip\-mine\fR" 4
  .IX Item "-floop-strip-mine"
! .IP "\fB\-floop\-block\fR" 4
  .IX Item "-floop-block"
  .PD
  Perform loop nest optimizations.  Same as
! \&\fB\-floop\-nest\-optimize\fR.  To use this code transformation, \s-1GCC\s0 has
  to be configured with \fB\-\-with\-isl\fR to enable the Graphite loop
  transformation infrastructure.
! .IP "\fB\-fgraphite\-identity\fR" 4
  .IX Item "-fgraphite-identity"
  Enable the identity transformation for graphite.  For every SCoP we generate
  the polyhedral representation and transform it back to gimple.  Using
  \&\fB\-fgraphite\-identity\fR we can check the costs or benefits of the
! \&\s-1GIMPLE\s0 \-> \s-1GRAPHITE\s0 \-> \s-1GIMPLE\s0 transformation.  Some minimal optimizations
  are also performed by the code generator isl, like index splitting and
  dead code elimination in loops.
! .IP "\fB\-floop\-nest\-optimize\fR" 4
  .IX Item "-floop-nest-optimize"
  Enable the isl based loop nest optimizer.  This is a generic loop nest
  optimizer based on the Pluto optimization algorithms.  It calculates a loop
! structure optimized for data-locality and parallelism.  This option
  is experimental.
! .IP "\fB\-floop\-parallelize\-all\fR" 4
  .IX Item "-floop-parallelize-all"
  Use the Graphite data dependence analysis to identify loops that can
  be parallelized.  Parallelize all the loops that can be analyzed to
  not contain loop carried dependences without checking that it is
  profitable to parallelize the loops.
! .IP "\fB\-ftree\-coalesce\-vars\fR" 4
  .IX Item "-ftree-coalesce-vars"
! While transforming the program out of the \s-1SSA\s0 representation, attempt to
! reduce copying by coalescing versions of different user-defined
  variables, instead of just compiler temporaries.  This may severely
  limit the ability to debug an optimized program compiled with
  \&\fB\-fno\-var\-tracking\-assignments\fR.  In the negated form, this flag
! prevents \s-1SSA\s0 coalescing of user variables.  This option is enabled by
  default if optimization is enabled, and it does very little otherwise.
! .IP "\fB\-ftree\-loop\-if\-convert\fR" 4
  .IX Item "-ftree-loop-if-convert"
  Attempt to transform conditional jumps in the innermost loops to
! branch-less equivalents.  The intent is to remove control-flow from
  the innermost loops in order to improve the ability of the
  vectorization pass to handle these loops.  This is enabled by default
  if vectorization is enabled.
! .IP "\fB\-ftree\-loop\-distribution\fR" 4
  .IX Item "-ftree-loop-distribution"
  Perform loop distribution.  This flag can improve cache performance on
  big loop bodies and allow further loop optimizations, like
--- 12052,12208 ----
  .RS 4
  .Sp
  When \fB\-flive\-patching\fR is specified without any value, the default value
! is \fIinline\-clone\fR.
  .Sp
  This flag is disabled by default.
  .Sp
! Note that \fB\-flive\-patching\fR is not supported with link\-time optimization
  (\fB\-flto\fR).
  .RE
! .IP \fB\-fisolate\-erroneous\-paths\-dereference\fR 4
  .IX Item "-fisolate-erroneous-paths-dereference"
  Detect paths that trigger erroneous or undefined behavior due to
  dereferencing a null pointer.  Isolate those paths from the main control
  flow and turn the statement with erroneous or undefined behavior into a trap.
  This flag is enabled by default at \fB\-O2\fR and higher and depends on
  \&\fB\-fdelete\-null\-pointer\-checks\fR also being enabled.
! .IP \fB\-fisolate\-erroneous\-paths\-attribute\fR 4
  .IX Item "-fisolate-erroneous-paths-attribute"
  Detect paths that trigger erroneous or undefined behavior due to a null value
  being used in a way forbidden by a \f(CW\*(C`returns_nonnull\*(C'\fR or \f(CW\*(C`nonnull\*(C'\fR
  attribute.  Isolate those paths from the main control flow and turn the
  statement with erroneous or undefined behavior into a trap.  This is not
  currently enabled, but may be enabled by \fB\-O2\fR in the future.
! .IP \fB\-ftree\-sink\fR 4
  .IX Item "-ftree-sink"
  Perform forward store motion on trees.  This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-bit\-ccp\fR 4
  .IX Item "-ftree-bit-ccp"
  Perform sparse conditional bit constant propagation on trees and propagate
  pointer alignment information.
  This pass only operates on local scalar variables and is enabled by default
  at \fB\-O1\fR and higher, except for \fB\-Og\fR.
  It requires that \fB\-ftree\-ccp\fR is enabled.
! .IP \fB\-ftree\-ccp\fR 4
  .IX Item "-ftree-ccp"
! Perform sparse conditional constant propagation (CCP) on trees.  This
  pass only operates on local scalar variables and is enabled by default
  at \fB\-O1\fR and higher.
! .IP \fB\-fssa\-backprop\fR 4
  .IX Item "-fssa-backprop"
  Propagate information about uses of a value up the definition chain
  in order to simplify the definitions.  For example, this pass strips
  sign operations if the sign of a value never matters.  The flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fssa\-phiopt\fR 4
  .IX Item "-fssa-phiopt"
! Perform pattern matching on SSA PHI nodes to optimize conditional
  code.  This pass is enabled by default at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP \fB\-ftree\-switch\-conversion\fR 4
  .IX Item "-ftree-switch-conversion"
  Perform conversion of simple initializations in a switch to
  initializations from a scalar array.  This flag is enabled by default
  at \fB\-O2\fR and higher.
! .IP \fB\-ftree\-tail\-merge\fR 4
  .IX Item "-ftree-tail-merge"
  Look for identical code sequences.  When found, replace one with a jump to the
  other.  This optimization is known as tail merging or cross jumping.  This flag
  is enabled by default at \fB\-O2\fR and higher.  The compilation time
  in this pass can
! be limited using \fBmax\-tail\-merge\-comparisons\fR parameter and
! \&\fBmax\-tail\-merge\-iterations\fR parameter.
! .IP \fB\-ftree\-dce\fR 4
  .IX Item "-ftree-dce"
! Perform dead code elimination (DCE) on trees.  This flag is enabled by
  default at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-builtin\-call\-dce\fR 4
  .IX Item "-ftree-builtin-call-dce"
! Perform conditional dead code elimination (DCE) for calls to built\-in functions
  that may set \f(CW\*(C`errno\*(C'\fR but are otherwise free of side effects.  This flag is
  enabled by default at \fB\-O2\fR and higher if \fB\-Os\fR is not also
  specified.
! .IP \fB\-ffinite\-loops\fR 4
  .IX Item "-ffinite-loops"
  Assume that a loop with an exit will eventually take the exit and not loop
  indefinitely.  This allows the compiler to remove loops that otherwise have
! no side\-effects, not considering eventual endless looping as such.
  .Sp
! This option is enabled by default at \fB\-O2\fR for C++ with \-std=c++11
  or higher.
! .IP \fB\-ftree\-dominator\-opts\fR 4
  .IX Item "-ftree-dominator-opts"
  Perform a variety of simple scalar cleanups (constant/copy
  propagation, redundancy elimination, range propagation and expression
  simplification) based on a dominator tree traversal.  This also
  performs jump threading (to reduce jumps to jumps). This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-dse\fR 4
  .IX Item "-ftree-dse"
! Perform dead store elimination (DSE) on trees.  A dead store is a store into
  a memory location that is later overwritten by another store without
  any intervening loads.  In this case the earlier store can be deleted.  This
  flag is enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-ch\fR 4
  .IX Item "-ftree-ch"
  Perform loop header copying on trees.  This is beneficial since it increases
  effectiveness of code motion optimizations.  It also saves one jump.  This flag
  is enabled by default at \fB\-O1\fR and higher.  It is not enabled
  for \fB\-Os\fR, since it usually increases code size.
! .IP \fB\-ftree\-loop\-optimize\fR 4
  .IX Item "-ftree-loop-optimize"
  Perform loop optimizations on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-loop\-linear\fR 4
  .IX Item "-ftree-loop-linear"
  .PD 0
! .IP \fB\-floop\-strip\-mine\fR 4
  .IX Item "-floop-strip-mine"
! .IP \fB\-floop\-block\fR 4
  .IX Item "-floop-block"
  .PD
  Perform loop nest optimizations.  Same as
! \&\fB\-floop\-nest\-optimize\fR.  To use this code transformation, GCC has
  to be configured with \fB\-\-with\-isl\fR to enable the Graphite loop
  transformation infrastructure.
! .IP \fB\-fgraphite\-identity\fR 4
  .IX Item "-fgraphite-identity"
  Enable the identity transformation for graphite.  For every SCoP we generate
  the polyhedral representation and transform it back to gimple.  Using
  \&\fB\-fgraphite\-identity\fR we can check the costs or benefits of the
! GIMPLE \-> GRAPHITE \-> GIMPLE transformation.  Some minimal optimizations
  are also performed by the code generator isl, like index splitting and
  dead code elimination in loops.
! .IP \fB\-floop\-nest\-optimize\fR 4
  .IX Item "-floop-nest-optimize"
  Enable the isl based loop nest optimizer.  This is a generic loop nest
  optimizer based on the Pluto optimization algorithms.  It calculates a loop
! structure optimized for data\-locality and parallelism.  This option
  is experimental.
! .IP \fB\-floop\-parallelize\-all\fR 4
  .IX Item "-floop-parallelize-all"
  Use the Graphite data dependence analysis to identify loops that can
  be parallelized.  Parallelize all the loops that can be analyzed to
  not contain loop carried dependences without checking that it is
  profitable to parallelize the loops.
! .IP \fB\-ftree\-coalesce\-vars\fR 4
  .IX Item "-ftree-coalesce-vars"
! While transforming the program out of the SSA representation, attempt to
! reduce copying by coalescing versions of different user\-defined
  variables, instead of just compiler temporaries.  This may severely
  limit the ability to debug an optimized program compiled with
  \&\fB\-fno\-var\-tracking\-assignments\fR.  In the negated form, this flag
! prevents SSA coalescing of user variables.  This option is enabled by
  default if optimization is enabled, and it does very little otherwise.
! .IP \fB\-ftree\-loop\-if\-convert\fR 4
  .IX Item "-ftree-loop-if-convert"
  Attempt to transform conditional jumps in the innermost loops to
! branch\-less equivalents.  The intent is to remove control\-flow from
  the innermost loops in order to improve the ability of the
  vectorization pass to handle these loops.  This is enabled by default
  if vectorization is enabled.
! .IP \fB\-ftree\-loop\-distribution\fR 4
  .IX Item "-ftree-loop-distribution"
  Perform loop distribution.  This flag can improve cache performance on
  big loop bodies and allow further loop optimizations, like
*************** is transformed to
*** 12299,12305 ****
  .Sp
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-ftree\-loop\-distribute\-patterns\fR" 4
  .IX Item "-ftree-loop-distribute-patterns"
  Perform loop distribution of patterns that can be code generated with
  calls to a library.  This flag is enabled by default at \fB\-O2\fR and
--- 12228,12234 ----
  .Sp
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-ftree\-loop\-distribute\-patterns\fR 4
  .IX Item "-ftree-loop-distribute-patterns"
  Perform loop distribution of patterns that can be code generated with
  calls to a library.  This flag is enabled by default at \fB\-O2\fR and
*************** is transformed to
*** 12329,12335 ****
  and the initialization loop is transformed into a call to memset zero.
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-floop\-interchange\fR" 4
  .IX Item "-floop-interchange"
  Perform loop interchange outside of graphite.  This flag can improve cache
  performance on loop nest and allow further loop optimizations, like
--- 12258,12264 ----
  and the initialization loop is transformed into a call to memset zero.
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-floop\-interchange\fR 4
  .IX Item "-floop-interchange"
  Perform loop interchange outside of graphite.  This flag can improve cache
  performance on loop nest and allow further loop optimizations, like
*************** is transformed to
*** 12353,12379 ****
  .Sp
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-floop\-unroll\-and\-jam\fR" 4
  .IX Item "-floop-unroll-and-jam"
  Apply unroll and jam transformations on feasible loops.  In a loop
  nest this unrolls the outer loop by some factor and fuses the resulting
  multiple inner loops.  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-ftree\-loop\-im\fR" 4
  .IX Item "-ftree-loop-im"
  Perform loop invariant motion on trees.  This pass moves only invariants that
! are hard to handle at \s-1RTL\s0 level (function calls, operations that expand to
  nontrivial sequences of insns).  With \fB\-funswitch\-loops\fR it also moves
  operands of conditions that are invariant out of the loop, so that we can use
  just trivial invariantness analysis in loop unswitching.  The pass also includes
  store motion.
! .IP "\fB\-ftree\-loop\-ivcanon\fR" 4
  .IX Item "-ftree-loop-ivcanon"
  Create a canonical counter for number of iterations in loops for which
  determining number of iterations requires complicated analysis.  Later
  optimizations then may determine the number easily.  Useful especially
  in connection with unrolling.
! .IP "\fB\-ftree\-scev\-cprop\fR" 4
  .IX Item "-ftree-scev-cprop"
  Perform final value replacement.  If a variable is modified in a loop
  in such a way that its value when exiting the loop can be determined using
--- 12282,12308 ----
  .Sp
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-floop\-unroll\-and\-jam\fR 4
  .IX Item "-floop-unroll-and-jam"
  Apply unroll and jam transformations on feasible loops.  In a loop
  nest this unrolls the outer loop by some factor and fuses the resulting
  multiple inner loops.  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-ftree\-loop\-im\fR 4
  .IX Item "-ftree-loop-im"
  Perform loop invariant motion on trees.  This pass moves only invariants that
! are hard to handle at RTL level (function calls, operations that expand to
  nontrivial sequences of insns).  With \fB\-funswitch\-loops\fR it also moves
  operands of conditions that are invariant out of the loop, so that we can use
  just trivial invariantness analysis in loop unswitching.  The pass also includes
  store motion.
! .IP \fB\-ftree\-loop\-ivcanon\fR 4
  .IX Item "-ftree-loop-ivcanon"
  Create a canonical counter for number of iterations in loops for which
  determining number of iterations requires complicated analysis.  Later
  optimizations then may determine the number easily.  Useful especially
  in connection with unrolling.
! .IP \fB\-ftree\-scev\-cprop\fR 4
  .IX Item "-ftree-scev-cprop"
  Perform final value replacement.  If a variable is modified in a loop
  in such a way that its value when exiting the loop can be determined using
*************** only its initial value and the number of
*** 12381,12453 ****
  the final value by such a computation, provided it is sufficiently cheap.
  This reduces data dependencies and may allow further simplifications.
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fivopts\fR" 4
  .IX Item "-fivopts"
  Perform induction variable optimizations (strength reduction, induction
  variable merging and induction variable elimination) on trees.
! .IP "\fB\-ftree\-parallelize\-loops=n\fR" 4
  .IX Item "-ftree-parallelize-loops=n"
  Parallelize loops, i.e., split their iteration space to run in n threads.
  This is only possible for loops whose iterations are independent
  and can be arbitrarily reordered.  The optimization is only
! profitable on multiprocessor machines, for loops that are CPU-intensive,
  rather than constrained e.g. by memory bandwidth.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets
  that have support for \fB\-pthread\fR.
! .IP "\fB\-ftree\-pta\fR" 4
  .IX Item "-ftree-pta"
! Perform function-local points-to analysis on trees.  This flag is
  enabled by default at \fB\-O1\fR and higher, except for \fB\-Og\fR.
! .IP "\fB\-ftree\-sra\fR" 4
  .IX Item "-ftree-sra"
  Perform scalar replacement of aggregates.  This pass replaces structure
  references with scalars to prevent committing structures to memory too
  early.  This flag is enabled by default at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP "\fB\-fstore\-merging\fR" 4
  .IX Item "-fstore-merging"
  Perform merging of narrow stores to consecutive memory addresses.  This pass
  merges contiguous stores of immediate values narrower than a word into fewer
  wider stores to reduce the number of instructions.  This is enabled by default
  at \fB\-O2\fR and higher as well as \fB\-Os\fR.
! .IP "\fB\-ftree\-ter\fR" 4
  .IX Item "-ftree-ter"
! Perform temporary expression replacement during the \s-1SSA\-\s0>normal phase.  Single
  use/single def temporaries are replaced at their use location with their
! defining expression.  This results in non-GIMPLE code, but gives the expanders
! much more complex trees to work on resulting in better \s-1RTL\s0 generation.  This is
  enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-slsr\fR" 4
  .IX Item "-ftree-slsr"
! Perform straight-line strength reduction on trees.  This recognizes related
  expressions involving multiplications and replaces them by less expensive
  calculations when possible.  This is enabled by default at \fB\-O1\fR and
  higher.
! .IP "\fB\-ftree\-vectorize\fR" 4
  .IX Item "-ftree-vectorize"
  Perform vectorization on trees. This flag enables \fB\-ftree\-loop\-vectorize\fR
  and \fB\-ftree\-slp\-vectorize\fR if not explicitly specified.
! .IP "\fB\-ftree\-loop\-vectorize\fR" 4
  .IX Item "-ftree-loop-vectorize"
  Perform loop vectorization on trees. This flag is enabled by default at
  \&\fB\-O2\fR and by \fB\-ftree\-vectorize\fR, \fB\-fprofile\-use\fR,
  and \fB\-fauto\-profile\fR.
! .IP "\fB\-ftree\-slp\-vectorize\fR" 4
  .IX Item "-ftree-slp-vectorize"
  Perform basic block vectorization on trees. This flag is enabled by default at
  \&\fB\-O2\fR and by \fB\-ftree\-vectorize\fR, \fB\-fprofile\-use\fR,
  and \fB\-fauto\-profile\fR.
! .IP "\fB\-ftrivial\-auto\-var\-init=\fR\fIchoice\fR" 4
  .IX Item "-ftrivial-auto-var-init=choice"
  Initialize automatic variables with either a pattern or with zeroes to increase
  the security and predictability of a program by preventing uninitialized memory
  disclosure and use.
! \&\s-1GCC\s0 still considers an automatic variable that doesn't have an explicit
  initializer as uninitialized, \fB\-Wuninitialized\fR and
  \&\fB\-Wanalyzer\-use\-of\-uninitialized\-value\fR will still report
  warning messages on such automatic variables and the compiler will
  perform optimization as if the variable were uninitialized.
! With this option, \s-1GCC\s0 will also initialize any padding of automatic variables
  that have structure or union types to zeroes.
  However, the current implementation cannot initialize automatic variables that
  are declared between the controlling expression and the first case of a
--- 12310,12382 ----
  the final value by such a computation, provided it is sufficiently cheap.
  This reduces data dependencies and may allow further simplifications.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fivopts\fR 4
  .IX Item "-fivopts"
  Perform induction variable optimizations (strength reduction, induction
  variable merging and induction variable elimination) on trees.
! .IP \fB\-ftree\-parallelize\-loops=n\fR 4
  .IX Item "-ftree-parallelize-loops=n"
  Parallelize loops, i.e., split their iteration space to run in n threads.
  This is only possible for loops whose iterations are independent
  and can be arbitrarily reordered.  The optimization is only
! profitable on multiprocessor machines, for loops that are CPU\-intensive,
  rather than constrained e.g. by memory bandwidth.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets
  that have support for \fB\-pthread\fR.
! .IP \fB\-ftree\-pta\fR 4
  .IX Item "-ftree-pta"
! Perform function\-local points\-to analysis on trees.  This flag is
  enabled by default at \fB\-O1\fR and higher, except for \fB\-Og\fR.
! .IP \fB\-ftree\-sra\fR 4
  .IX Item "-ftree-sra"
  Perform scalar replacement of aggregates.  This pass replaces structure
  references with scalars to prevent committing structures to memory too
  early.  This flag is enabled by default at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP \fB\-fstore\-merging\fR 4
  .IX Item "-fstore-merging"
  Perform merging of narrow stores to consecutive memory addresses.  This pass
  merges contiguous stores of immediate values narrower than a word into fewer
  wider stores to reduce the number of instructions.  This is enabled by default
  at \fB\-O2\fR and higher as well as \fB\-Os\fR.
! .IP \fB\-ftree\-ter\fR 4
  .IX Item "-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 \fB\-O1\fR and higher.
! .IP \fB\-ftree\-slsr\fR 4
  .IX Item "-ftree-slsr"
! Perform straight\-line strength reduction on trees.  This recognizes related
  expressions involving multiplications and replaces them by less expensive
  calculations when possible.  This is enabled by default at \fB\-O1\fR and
  higher.
! .IP \fB\-ftree\-vectorize\fR 4
  .IX Item "-ftree-vectorize"
  Perform vectorization on trees. This flag enables \fB\-ftree\-loop\-vectorize\fR
  and \fB\-ftree\-slp\-vectorize\fR if not explicitly specified.
! .IP \fB\-ftree\-loop\-vectorize\fR 4
  .IX Item "-ftree-loop-vectorize"
  Perform loop vectorization on trees. This flag is enabled by default at
  \&\fB\-O2\fR and by \fB\-ftree\-vectorize\fR, \fB\-fprofile\-use\fR,
  and \fB\-fauto\-profile\fR.
! .IP \fB\-ftree\-slp\-vectorize\fR 4
  .IX Item "-ftree-slp-vectorize"
  Perform basic block vectorization on trees. This flag is enabled by default at
  \&\fB\-O2\fR and by \fB\-ftree\-vectorize\fR, \fB\-fprofile\-use\fR,
  and \fB\-fauto\-profile\fR.
! .IP \fB\-ftrivial\-auto\-var\-init=\fR\fIchoice\fR 4
  .IX Item "-ftrivial-auto-var-init=choice"
  Initialize automatic variables with either a pattern or with zeroes to increase
  the security and predictability of a program by preventing uninitialized memory
  disclosure and use.
! GCC still considers an automatic variable that doesn\*(Aqt have an explicit
  initializer as uninitialized, \fB\-Wuninitialized\fR and
  \&\fB\-Wanalyzer\-use\-of\-uninitialized\-value\fR will still report
  warning messages on such automatic variables and the compiler will
  perform optimization as if the variable were uninitialized.
! With this option, GCC will also initialize any padding of automatic variables
  that have structure or union types to zeroes.
  However, the current implementation cannot initialize automatic variables that
  are declared between the controlling expression and the first case of a
*************** such cases.
*** 12456,12472 ****
  .Sp
  The three values of \fIchoice\fR are:
  .RS 4
! .IP "*" 4
! \&\fBuninitialized\fR doesn't initialize any automatic variables.
! This is C and \*(C+'s default.
! .IP "*" 4
  \&\fBpattern\fR Initialize automatic variables with values which will likely
  transform logic bugs into crashes down the line, are easily recognized in a
  crash dump and without being values that programmers can rely on for useful
  program semantics.
! The current value is byte-repeatable pattern with byte \*(L"0xFE\*(R".
  The values used for pattern initialization might be changed in the future.
! .IP "*" 4
  \&\fBzero\fR Initialize automatic variables with zeroes.
  .RE
  .RS 4
--- 12385,12401 ----
  .Sp
  The three values of \fIchoice\fR are:
  .RS 4
! .IP * 4
! \&\fBuninitialized\fR doesn\*(Aqt initialize any automatic variables.
! This is C and C++\*(Aqs default.
! .IP * 4
  \&\fBpattern\fR Initialize automatic variables with values which will likely
  transform logic bugs into crashes down the line, are easily recognized in a
  crash dump and without being values that programmers can rely on for useful
  program semantics.
! The current value is byte\-repeatable pattern with byte "0xFE".
  The values used for pattern initialization might be changed in the future.
! .IP * 4
  \&\fBzero\fR Initialize automatic variables with zeroes.
  .RE
  .RS 4
*************** The default is \fBuninitialized\fR.
*** 12476,12511 ****
  You can control this behavior for a specific variable by using the variable
  attribute \f(CW\*(C`uninitialized\*(C'\fR.
  .RE
! .IP "\fB\-fvect\-cost\-model=\fR\fImodel\fR" 4
  .IX Item "-fvect-cost-model=model"
  Alter the cost model used for vectorization.  The \fImodel\fR argument
  should be one of \fBunlimited\fR, \fBdynamic\fR, \fBcheap\fR or
! \&\fBvery-cheap\fR.
! With the \fBunlimited\fR model the vectorized code-path is assumed
  to be profitable while with the \fBdynamic\fR model a runtime check
! guards the vectorized code-path to enable it only for iteration
  counts that will likely execute faster than when executing the original
  scalar loop.  The \fBcheap\fR model disables vectorization of
  loops where doing so would be cost prohibitive for example due to
  required runtime checks for data dependence or alignment but otherwise
! is equal to the \fBdynamic\fR model.  The \fBvery-cheap\fR model only
  allows vectorization if the vector code would entirely replace the
  scalar code that is being vectorized.  For example, if each iteration
  of a vectorized loop would only be able to handle exactly four iterations
! of the scalar loop, the \fBvery-cheap\fR model would only allow
  vectorization if the scalar iteration count is known to be a multiple
  of four.
  .Sp
  The default cost model depends on other optimization flags and is
  either \fBdynamic\fR or \fBcheap\fR.
! .IP "\fB\-fsimd\-cost\-model=\fR\fImodel\fR" 4
  .IX Item "-fsimd-cost-model=model"
  Alter the cost model used for vectorization of loops marked with the OpenMP
  simd directive.  The \fImodel\fR argument should be one of
  \&\fBunlimited\fR, \fBdynamic\fR, \fBcheap\fR.  All values of \fImodel\fR
  have the same meaning as described in \fB\-fvect\-cost\-model\fR and by
  default a cost model defined with \fB\-fvect\-cost\-model\fR is used.
! .IP "\fB\-ftree\-vrp\fR" 4
  .IX Item "-ftree-vrp"
  Perform Value Range Propagation on trees.  This is similar to the
  constant propagation pass, but instead of values, ranges of values are
--- 12405,12440 ----
  You can control this behavior for a specific variable by using the variable
  attribute \f(CW\*(C`uninitialized\*(C'\fR.
  .RE
! .IP \fB\-fvect\-cost\-model=\fR\fImodel\fR 4
  .IX Item "-fvect-cost-model=model"
  Alter the cost model used for vectorization.  The \fImodel\fR argument
  should be one of \fBunlimited\fR, \fBdynamic\fR, \fBcheap\fR or
! \&\fBvery\-cheap\fR.
! With the \fBunlimited\fR model the vectorized code\-path is assumed
  to be profitable while with the \fBdynamic\fR model a runtime check
! guards the vectorized code\-path to enable it only for iteration
  counts that will likely execute faster than when executing the original
  scalar loop.  The \fBcheap\fR model disables vectorization of
  loops where doing so would be cost prohibitive for example due to
  required runtime checks for data dependence or alignment but otherwise
! is equal to the \fBdynamic\fR model.  The \fBvery\-cheap\fR model only
  allows vectorization if the vector code would entirely replace the
  scalar code that is being vectorized.  For example, if each iteration
  of a vectorized loop would only be able to handle exactly four iterations
! of the scalar loop, the \fBvery\-cheap\fR model would only allow
  vectorization if the scalar iteration count is known to be a multiple
  of four.
  .Sp
  The default cost model depends on other optimization flags and is
  either \fBdynamic\fR or \fBcheap\fR.
! .IP \fB\-fsimd\-cost\-model=\fR\fImodel\fR 4
  .IX Item "-fsimd-cost-model=model"
  Alter the cost model used for vectorization of loops marked with the OpenMP
  simd directive.  The \fImodel\fR argument should be one of
  \&\fBunlimited\fR, \fBdynamic\fR, \fBcheap\fR.  All values of \fImodel\fR
  have the same meaning as described in \fB\-fvect\-cost\-model\fR and by
  default a cost model defined with \fB\-fvect\-cost\-model\fR is used.
! .IP \fB\-ftree\-vrp\fR 4
  .IX Item "-ftree-vrp"
  Perform Value Range Propagation on trees.  This is similar to the
  constant propagation pass, but instead of values, ranges of values are
*************** checks like array bound checks and null
*** 12514,12551 ****
  enabled by default at \fB\-O2\fR and higher.  Null pointer check
  elimination is only done if \fB\-fdelete\-null\-pointer\-checks\fR is
  enabled.
! .IP "\fB\-fsplit\-paths\fR" 4
  .IX Item "-fsplit-paths"
  Split paths leading to loop backedges.  This can improve dead code
  elimination and common subexpression elimination.  This is enabled by
  default at \fB\-O3\fR and above.
! .IP "\fB\-fsplit\-ivs\-in\-unroller\fR" 4
  .IX Item "-fsplit-ivs-in-unroller"
  Enables expression of values of induction variables in later iterations
  of the unrolled loop using the value in the first iteration.  This breaks
  long dependency chains, thus improving efficiency of the scheduling passes.
  .Sp
! A combination of \fB\-fweb\fR and \s-1CSE\s0 is often sufficient to obtain the
  same effect.  However, that is not reliable in cases where the loop body
  is more complicated than a single basic block.  It also does not work at all
! on some architectures due to restrictions in the \s-1CSE\s0 pass.
  .Sp
  This optimization is enabled by default.
! .IP "\fB\-fvariable\-expansion\-in\-unroller\fR" 4
  .IX Item "-fvariable-expansion-in-unroller"
  With this option, the compiler creates multiple copies of some
  local variables when unrolling a loop, which can result in superior code.
  .Sp
  This optimization is enabled by default for PowerPC targets, but disabled
  by default otherwise.
! .IP "\fB\-fpartial\-inlining\fR" 4
  .IX Item "-fpartial-inlining"
  Inline parts of functions.  This option has any effect only
  when inlining itself is turned on by the \fB\-finline\-functions\fR
  or \fB\-finline\-small\-functions\fR options.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fpredictive\-commoning\fR" 4
  .IX Item "-fpredictive-commoning"
  Perform predictive commoning optimization, i.e., reusing computations
  (especially memory loads and stores) performed in previous
--- 12443,12480 ----
  enabled by default at \fB\-O2\fR and higher.  Null pointer check
  elimination is only done if \fB\-fdelete\-null\-pointer\-checks\fR is
  enabled.
! .IP \fB\-fsplit\-paths\fR 4
  .IX Item "-fsplit-paths"
  Split paths leading to loop backedges.  This can improve dead code
  elimination and common subexpression elimination.  This is enabled by
  default at \fB\-O3\fR and above.
! .IP \fB\-fsplit\-ivs\-in\-unroller\fR 4
  .IX Item "-fsplit-ivs-in-unroller"
  Enables expression of values of induction variables in later iterations
  of the unrolled loop using the value in the first iteration.  This breaks
  long dependency chains, thus improving efficiency of the scheduling passes.
  .Sp
! A combination of \fB\-fweb\fR and CSE is often sufficient to obtain the
  same effect.  However, that is not reliable in cases where the loop body
  is more complicated than a single basic block.  It also does not work at all
! on some architectures due to restrictions in the CSE pass.
  .Sp
  This optimization is enabled by default.
! .IP \fB\-fvariable\-expansion\-in\-unroller\fR 4
  .IX Item "-fvariable-expansion-in-unroller"
  With this option, the compiler creates multiple copies of some
  local variables when unrolling a loop, which can result in superior code.
  .Sp
  This optimization is enabled by default for PowerPC targets, but disabled
  by default otherwise.
! .IP \fB\-fpartial\-inlining\fR 4
  .IX Item "-fpartial-inlining"
  Inline parts of functions.  This option has any effect only
  when inlining itself is turned on by the \fB\-finline\-functions\fR
  or \fB\-finline\-small\-functions\fR options.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fpredictive\-commoning\fR 4
  .IX Item "-fpredictive-commoning"
  Perform predictive commoning optimization, i.e., reusing computations
  (especially memory loads and stores) performed in previous
*************** iterations of loops.
*** 12553,12559 ****
  .Sp
  This option is enabled at level \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-fprefetch\-loop\-arrays\fR" 4
  .IX Item "-fprefetch-loop-arrays"
  If supported by the target machine, generate instructions to prefetch
  memory to improve the performance of loops that access large arrays.
--- 12482,12488 ----
  .Sp
  This option is enabled at level \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-fprefetch\-loop\-arrays\fR 4
  .IX Item "-fprefetch-loop-arrays"
  If supported by the target machine, generate instructions to prefetch
  memory to improve the performance of loops that access large arrays.
*************** This option may generate better or worse
*** 12562,12573 ****
  dependent on the structure of loops within the source code.
  .Sp
  Disabled at level \fB\-Os\fR.
! .IP "\fB\-fno\-printf\-return\-value\fR" 4
  .IX Item "-fno-printf-return-value"
  Do not substitute constants for known return value of formatted output
  functions such as \f(CW\*(C`sprintf\*(C'\fR, \f(CW\*(C`snprintf\*(C'\fR, \f(CW\*(C`vsprintf\*(C'\fR, and
  \&\f(CW\*(C`vsnprintf\*(C'\fR (but not \f(CW\*(C`printf\*(C'\fR of \f(CW\*(C`fprintf\*(C'\fR).  This
! transformation allows \s-1GCC\s0 to optimize or even eliminate branches based
  on the known return value of these functions called with arguments that
  are either constant, or whose values are known to be in a range that
  makes determining the exact return value possible.  For example, when
--- 12491,12502 ----
  dependent on the structure of loops within the source code.
  .Sp
  Disabled at level \fB\-Os\fR.
! .IP \fB\-fno\-printf\-return\-value\fR 4
  .IX Item "-fno-printf-return-value"
  Do not substitute constants for known return value of formatted output
  functions such as \f(CW\*(C`sprintf\*(C'\fR, \f(CW\*(C`snprintf\*(C'\fR, \f(CW\*(C`vsprintf\*(C'\fR, and
  \&\f(CW\*(C`vsnprintf\*(C'\fR (but not \f(CW\*(C`printf\*(C'\fR of \f(CW\*(C`fprintf\*(C'\fR).  This
! transformation allows GCC to optimize or even eliminate branches based
  on the known return value of these functions called with arguments that
  are either constant, or whose values are known to be in a range that
  makes determining the exact return value possible.  For example, when
*************** The \fB\-fprintf\-return\-value\fR optio
*** 12586,12609 ****
  and yields best results with \fB\-O2\fR and above.  It works in tandem
  with the \fB\-Wformat\-overflow\fR and \fB\-Wformat\-truncation\fR
  options.  The \fB\-fprintf\-return\-value\fR option is enabled by default.
! .IP "\fB\-fno\-peephole\fR" 4
  .IX Item "-fno-peephole"
  .PD 0
! .IP "\fB\-fno\-peephole2\fR" 4
  .IX Item "-fno-peephole2"
  .PD
! Disable any machine-specific peephole optimizations.  The difference
  between \fB\-fno\-peephole\fR and \fB\-fno\-peephole2\fR is in how they
  are implemented in the compiler; some targets use one, some use the
  other, a few use both.
  .Sp
  \&\fB\-fpeephole\fR is enabled by default.
  \&\fB\-fpeephole2\fR enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fno\-guess\-branch\-probability\fR" 4
  .IX Item "-fno-guess-branch-probability"
  Do not guess branch probabilities using heuristics.
  .Sp
! \&\s-1GCC\s0 uses heuristics to guess branch probabilities if they are
  not provided by profiling feedback (\fB\-fprofile\-arcs\fR).  These
  heuristics are based on the control flow graph.  If some branch probabilities
  are specified by \f(CW\*(C`_\|_builtin_expect\*(C'\fR, then the heuristics are
--- 12515,12538 ----
  and yields best results with \fB\-O2\fR and above.  It works in tandem
  with the \fB\-Wformat\-overflow\fR and \fB\-Wformat\-truncation\fR
  options.  The \fB\-fprintf\-return\-value\fR option is enabled by default.
! .IP \fB\-fno\-peephole\fR 4
  .IX Item "-fno-peephole"
  .PD 0
! .IP \fB\-fno\-peephole2\fR 4
  .IX Item "-fno-peephole2"
  .PD
! Disable any machine\-specific peephole optimizations.  The difference
  between \fB\-fno\-peephole\fR and \fB\-fno\-peephole2\fR is in how they
  are implemented in the compiler; some targets use one, some use the
  other, a few use both.
  .Sp
  \&\fB\-fpeephole\fR is enabled by default.
  \&\fB\-fpeephole2\fR enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fno\-guess\-branch\-probability\fR 4
  .IX Item "-fno-guess-branch-probability"
  Do not guess branch probabilities using heuristics.
  .Sp
! GCC uses heuristics to guess branch probabilities if they are
  not provided by profiling feedback (\fB\-fprofile\-arcs\fR).  These
  heuristics are based on the control flow graph.  If some branch probabilities
  are specified by \f(CW\*(C`_\|_builtin_expect\*(C'\fR, then the heuristics are
*************** some cases, it may be useful to disable
*** 12614,12641 ****
  of \f(CW\*(C`_\|_builtin_expect\*(C'\fR are easier to understand.
  .Sp
  It is also possible to specify expected probability of the expression
! with \f(CW\*(C`_\|_builtin_expect_with_probability\*(C'\fR built-in function.
  .Sp
  The default is \fB\-fguess\-branch\-probability\fR at levels
  \&\fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-freorder\-blocks\fR" 4
  .IX Item "-freorder-blocks"
  Reorder basic blocks in the compiled function in order to reduce number of
  taken branches and improve code locality.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-freorder\-blocks\-algorithm=\fR\fIalgorithm\fR" 4
  .IX Item "-freorder-blocks-algorithm=algorithm"
  Use the specified algorithm for basic block reordering.  The
  \&\fIalgorithm\fR argument can be \fBsimple\fR, which does not increase
  code size (except sometimes due to secondary effects like alignment),
! or \fBstc\fR, the \*(L"software trace cache\*(R" algorithm, which tries to
  put all often executed code together, minimizing the number of branches
  executed by making extra copies of code.
  .Sp
  The default is \fBsimple\fR at levels \fB\-O1\fR, \fB\-Os\fR, and
  \&\fBstc\fR at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-freorder\-blocks\-and\-partition\fR" 4
  .IX Item "-freorder-blocks-and-partition"
  In addition to reordering basic blocks in the compiled function, in order
  to reduce number of taken branches, partitions hot and cold basic blocks
--- 12543,12570 ----
  of \f(CW\*(C`_\|_builtin_expect\*(C'\fR are easier to understand.
  .Sp
  It is also possible to specify expected probability of the expression
! with \f(CW\*(C`_\|_builtin_expect_with_probability\*(C'\fR built\-in function.
  .Sp
  The default is \fB\-fguess\-branch\-probability\fR at levels
  \&\fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-freorder\-blocks\fR 4
  .IX Item "-freorder-blocks"
  Reorder basic blocks in the compiled function in order to reduce number of
  taken branches and improve code locality.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-freorder\-blocks\-algorithm=\fR\fIalgorithm\fR 4
  .IX Item "-freorder-blocks-algorithm=algorithm"
  Use the specified algorithm for basic block reordering.  The
  \&\fIalgorithm\fR argument can be \fBsimple\fR, which does not increase
  code size (except sometimes due to secondary effects like alignment),
! or \fBstc\fR, the "software trace cache" algorithm, which tries to
  put all often executed code together, minimizing the number of branches
  executed by making extra copies of code.
  .Sp
  The default is \fBsimple\fR at levels \fB\-O1\fR, \fB\-Os\fR, and
  \&\fBstc\fR at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-freorder\-blocks\-and\-partition\fR 4
  .IX Item "-freorder-blocks-and-partition"
  In addition to reordering basic blocks in the compiled function, in order
  to reduce number of taken branches, partitions hot and cold basic blocks
*************** into separate sections of the assembly a
*** 12643,12656 ****
  paging and cache locality performance.
  .Sp
  This optimization is automatically turned off in the presence of
! exception handling or unwind tables (on targets using setjump/longjump or target specific scheme), for linkonce sections, for functions with a user-defined
  section attribute and on any architecture that does not support named
  sections.  When \fB\-fsplit\-stack\fR is used this option is not
  enabled by default (to avoid linker errors), but may be enabled
  explicitly (if using a working linker).
  .Sp
  Enabled for x86 at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-freorder\-functions\fR" 4
  .IX Item "-freorder-functions"
  Reorder functions in the object file in order to
  improve code locality.  This is implemented by using special
--- 12572,12585 ----
  paging and cache locality performance.
  .Sp
  This optimization is automatically turned off in the presence of
! exception handling or unwind tables (on targets using setjump/longjump or target specific scheme), for linkonce sections, for functions with a user\-defined
  section attribute and on any architecture that does not support named
  sections.  When \fB\-fsplit\-stack\fR is used this option is not
  enabled by default (to avoid linker errors), but may be enabled
  explicitly (if using a working linker).
  .Sp
  Enabled for x86 at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-freorder\-functions\fR 4
  .IX Item "-freorder-functions"
  Reorder functions in the object file in order to
  improve code locality.  This is implemented by using special
*************** subsections \f(CW\*(C`.text.hot\*(C'\fR
*** 12659,12673 ****
  the linker so object file format must support named sections and linker must
  place them in a reasonable way.
  .Sp
! This option isn't effective unless you either provide profile feedback
  (see \fB\-fprofile\-arcs\fR for details) or manually annotate functions with 
  \&\f(CW\*(C`hot\*(C'\fR or \f(CW\*(C`cold\*(C'\fR attributes.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fstrict\-aliasing\fR" 4
  .IX Item "-fstrict-aliasing"
  Allow the compiler to assume the strictest aliasing rules applicable to
! the language being compiled.  For C (and \*(C+), this activates
  optimizations based on the type of expressions.  In particular, an
  object of one type is assumed never to reside at the same address as an
  object of a different type, unless the types are almost the same.  For
--- 12588,12602 ----
  the linker so object file format must support named sections and linker must
  place them in a reasonable way.
  .Sp
! This option isn\*(Aqt effective unless you either provide profile feedback
  (see \fB\-fprofile\-arcs\fR for details) or manually annotate functions with 
  \&\f(CW\*(C`hot\*(C'\fR or \f(CW\*(C`cold\*(C'\fR attributes.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fstrict\-aliasing\fR 4
  .IX Item "-fstrict-aliasing"
  Allow the compiler to assume the strictest aliasing rules applicable to
! the language being compiled.  For C (and C++), this activates
  optimizations based on the type of expressions.  In particular, an
  object of one type is assumed never to reside at the same address as an
  object of a different type, unless the types are almost the same.  For
*************** Pay special attention to code like this:
*** 12691,12698 ****
  .Ve
  .Sp
  The practice of reading from a different union member than the one most
! recently written to (called \*(L"type-punning\*(R") is common.  Even with
! \&\fB\-fstrict\-aliasing\fR, type-punning is allowed, provided the memory
  is accessed through the union type.  So, the code above works as
  expected.    However, this code might not:
  .Sp
--- 12620,12627 ----
  .Ve
  .Sp
  The practice of reading from a different union member than the one most
! recently written to (called "type\-punning") is common.  Even with
! \&\fB\-fstrict\-aliasing\fR, type\-punning is allowed, provided the memory
  is accessed through the union type.  So, the code above works as
  expected.    However, this code might not:
  .Sp
*************** uses a union type, e.g.:
*** 12719,12725 ****
  .Sp
  The \fB\-fstrict\-aliasing\fR option is enabled at levels
  \&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fipa\-strict\-aliasing\fR" 4
  .IX Item "-fipa-strict-aliasing"
  Controls whether rules of \fB\-fstrict\-aliasing\fR are applied across
  function boundaries.  Note that if multiple functions gets inlined into a
--- 12648,12654 ----
  .Sp
  The \fB\-fstrict\-aliasing\fR option is enabled at levels
  \&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fipa\-strict\-aliasing\fR 4
  .IX Item "-fipa-strict-aliasing"
  Controls whether rules of \fB\-fstrict\-aliasing\fR are applied across
  function boundaries.  Note that if multiple functions gets inlined into a
*************** function boundary.
*** 12728,12748 ****
  .Sp
  The \fB\-fipa\-strict\-aliasing\fR option is enabled by default and is
  effective only in combination with \fB\-fstrict\-aliasing\fR.
! .IP "\fB\-falign\-functions\fR" 4
  .IX Item "-falign-functions"
  .PD 0
! .IP "\fB\-falign\-functions=\fR\fIn\fR" 4
  .IX Item "-falign-functions=n"
! .IP "\fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR" 4
  .IX Item "-falign-functions=n:m"
! .IP "\fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR" 4
  .IX Item "-falign-functions=n:m:n2"
! .IP "\fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR" 4
  .IX Item "-falign-functions=n:m:n2:m2"
  .PD
! Align the start of functions to the next power-of-two greater than or
  equal to \fIn\fR, skipping up to \fIm\fR\-1 bytes.  This ensures that at
! least the first \fIm\fR bytes of the function can be fetched by the \s-1CPU\s0
  without crossing an \fIn\fR\-byte alignment boundary.
  .Sp
  If \fIm\fR is not specified, it defaults to \fIn\fR.
--- 12657,12677 ----
  .Sp
  The \fB\-fipa\-strict\-aliasing\fR option is enabled by default and is
  effective only in combination with \fB\-fstrict\-aliasing\fR.
! .IP \fB\-falign\-functions\fR 4
  .IX Item "-falign-functions"
  .PD 0
! .IP \fB\-falign\-functions=\fR\fIn\fR 4
  .IX Item "-falign-functions=n"
! .IP \fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR 4
  .IX Item "-falign-functions=n:m"
! .IP \fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR 4
  .IX Item "-falign-functions=n:m:n2"
! .IP \fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR 4
  .IX Item "-falign-functions=n:m:n2:m2"
  .PD
! Align the start of functions to the next power\-of\-two greater than or
  equal to \fIn\fR, skipping up to \fIm\fR\-1 bytes.  This ensures that at
! least the first \fIm\fR bytes of the function can be fetched by the CPU
  without crossing an \fIn\fR\-byte alignment boundary.
  .Sp
  If \fIm\fR is not specified, it defaults to \fIn\fR.
*************** in that case, it is rounded up.
*** 12766,12794 ****
  \&\fB\-fno\-align\-functions\fR and \fB\-falign\-functions=1\fR are
  equivalent and mean that functions are not aligned.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine-dependent default.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-flimit\-function\-alignment\fR" 4
  .IX Item "-flimit-function-alignment"
  If this option is enabled, the compiler tries to avoid unnecessarily
  overaligning functions. It attempts to instruct the assembler to align
  by the amount specified by \fB\-falign\-functions\fR, but not to
  skip more bytes than the size of the function.
! .IP "\fB\-falign\-labels\fR" 4
  .IX Item "-falign-labels"
  .PD 0
! .IP "\fB\-falign\-labels=\fR\fIn\fR" 4
  .IX Item "-falign-labels=n"
! .IP "\fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR" 4
  .IX Item "-falign-labels=n:m"
! .IP "\fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR" 4
  .IX Item "-falign-labels=n:m:n2"
! .IP "\fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR" 4
  .IX Item "-falign-labels=n:m:n2:m2"
  .PD
! Align all branch targets to a power-of-two boundary.
  .Sp
  Parameters of this option are analogous to the \fB\-falign\-functions\fR option.
  \&\fB\-fno\-align\-labels\fR and \fB\-falign\-labels=1\fR are
--- 12695,12723 ----
  \&\fB\-fno\-align\-functions\fR and \fB\-falign\-functions=1\fR are
  equivalent and mean that functions are not aligned.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine\-dependent default.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-flimit\-function\-alignment\fR 4
  .IX Item "-flimit-function-alignment"
  If this option is enabled, the compiler tries to avoid unnecessarily
  overaligning functions. It attempts to instruct the assembler to align
  by the amount specified by \fB\-falign\-functions\fR, but not to
  skip more bytes than the size of the function.
! .IP \fB\-falign\-labels\fR 4
  .IX Item "-falign-labels"
  .PD 0
! .IP \fB\-falign\-labels=\fR\fIn\fR 4
  .IX Item "-falign-labels=n"
! .IP \fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR 4
  .IX Item "-falign-labels=n:m"
! .IP \fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR 4
  .IX Item "-falign-labels=n:m:n2"
! .IP \fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR 4
  .IX Item "-falign-labels=n:m:n2:m2"
  .PD
! Align all branch targets to a power\-of\-two boundary.
  .Sp
  Parameters of this option are analogous to the \fB\-falign\-functions\fR option.
  \&\fB\-fno\-align\-labels\fR and \fB\-falign\-labels=1\fR are
*************** equivalent and mean that labels are not
*** 12797,12820 ****
  If \fB\-falign\-loops\fR or \fB\-falign\-jumps\fR are applicable and
  are greater than this value, then their values are used instead.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine-dependent default
  which is very likely to be \fB1\fR, meaning no alignment.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-falign\-loops\fR" 4
  .IX Item "-falign-loops"
  .PD 0
! .IP "\fB\-falign\-loops=\fR\fIn\fR" 4
  .IX Item "-falign-loops=n"
! .IP "\fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR" 4
  .IX Item "-falign-loops=n:m"
! .IP "\fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR" 4
  .IX Item "-falign-loops=n:m:n2"
! .IP "\fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR" 4
  .IX Item "-falign-loops=n:m:n2:m2"
  .PD
! Align loops to a power-of-two boundary.  If the loops are executed
  many times, this makes up for any execution of the dummy padding
  instructions.
  .Sp
--- 12726,12749 ----
  If \fB\-falign\-loops\fR or \fB\-falign\-jumps\fR are applicable and
  are greater than this value, then their values are used instead.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine\-dependent default
  which is very likely to be \fB1\fR, meaning no alignment.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-falign\-loops\fR 4
  .IX Item "-falign-loops"
  .PD 0
! .IP \fB\-falign\-loops=\fR\fIn\fR 4
  .IX Item "-falign-loops=n"
! .IP \fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR 4
  .IX Item "-falign-loops=n:m"
! .IP \fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR 4
  .IX Item "-falign-loops=n:m:n2"
! .IP \fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR 4
  .IX Item "-falign-loops=n:m:n2:m2"
  .PD
! Align loops to a power\-of\-two boundary.  If the loops are executed
  many times, this makes up for any execution of the dummy padding
  instructions.
  .Sp
*************** Parameters of this option are analogous
*** 12826,12847 ****
  equivalent and mean that loops are not aligned.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine-dependent default.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-falign\-jumps\fR" 4
  .IX Item "-falign-jumps"
  .PD 0
! .IP "\fB\-falign\-jumps=\fR\fIn\fR" 4
  .IX Item "-falign-jumps=n"
! .IP "\fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR" 4
  .IX Item "-falign-jumps=n:m"
! .IP "\fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR" 4
  .IX Item "-falign-jumps=n:m:n2"
! .IP "\fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR" 4
  .IX Item "-falign-jumps=n:m:n2:m2"
  .PD
! Align branch targets to a power-of-two boundary, for branch targets
  where the targets can only be reached by jumping.  In this case,
  no dummy operations need be executed.
  .Sp
--- 12755,12776 ----
  equivalent and mean that loops are not aligned.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine\-dependent default.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-falign\-jumps\fR 4
  .IX Item "-falign-jumps"
  .PD 0
! .IP \fB\-falign\-jumps=\fR\fIn\fR 4
  .IX Item "-falign-jumps=n"
! .IP \fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR 4
  .IX Item "-falign-jumps=n:m"
! .IP \fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR 4
  .IX Item "-falign-jumps=n:m:n2"
! .IP \fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR 4
  .IX Item "-falign-jumps=n:m:n2:m2"
  .PD
! Align branch targets to a power\-of\-two boundary, for branch targets
  where the targets can only be reached by jumping.  In this case,
  no dummy operations need be executed.
  .Sp
*************** Parameters of this option are analogous
*** 12852,12865 ****
  \&\fB\-fno\-align\-jumps\fR and \fB\-falign\-jumps=1\fR are
  equivalent and mean that loops are not aligned.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine-dependent default.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-fno\-allocation\-dce\fR" 4
  .IX Item "-fno-allocation-dce"
! Do not remove unused \*(C+ allocations in dead code elimination.
! .IP "\fB\-fallow\-store\-data\-races\fR" 4
  .IX Item "-fallow-store-data-races"
  Allow the compiler to perform optimizations that may introduce new data races
  on stores, without proving that the variable cannot be concurrently accessed
--- 12781,12794 ----
  \&\fB\-fno\-align\-jumps\fR and \fB\-falign\-jumps=1\fR are
  equivalent and mean that loops are not aligned.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine\-dependent default.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-fno\-allocation\-dce\fR 4
  .IX Item "-fno-allocation-dce"
! Do not remove unused C++ allocations in dead code elimination.
! .IP \fB\-fallow\-store\-data\-races\fR 4
  .IX Item "-fallow-store-data-races"
  Allow the compiler to perform optimizations that may introduce new data races
  on stores, without proving that the variable cannot be concurrently accessed
*************** use this option if it is known that glob
*** 12868,12890 ****
  multiple threads.
  .Sp
  Examples of optimizations enabled by \fB\-fallow\-store\-data\-races\fR include
! hoisting or if-conversions that may cause a value that was already in memory
! to be re-written with that same value.  Such re-writing is safe in a single
! threaded context but may be unsafe in a multi-threaded context.  Note that on
! some processors, if-conversions may be required in order to enable
  vectorization.
  .Sp
  Enabled at level \fB\-Ofast\fR.
! .IP "\fB\-funit\-at\-a\-time\fR" 4
  .IX Item "-funit-at-a-time"
  This option is left for compatibility reasons. \fB\-funit\-at\-a\-time\fR
  has no effect, while \fB\-fno\-unit\-at\-a\-time\fR implies
  \&\fB\-fno\-toplevel\-reorder\fR and \fB\-fno\-section\-anchors\fR.
  .Sp
  Enabled by default.
! .IP "\fB\-fno\-toplevel\-reorder\fR" 4
  .IX Item "-fno-toplevel-reorder"
! Do not reorder top-level functions, variables, and \f(CW\*(C`asm\*(C'\fR
  statements.  Output them in the same order that they appear in the
  input file.  When this option is used, unreferenced static variables
  are not removed.  This option is intended to support existing code
--- 12797,12819 ----
  multiple threads.
  .Sp
  Examples of optimizations enabled by \fB\-fallow\-store\-data\-races\fR include
! hoisting or if\-conversions that may cause a value that was already in memory
! to be re\-written with that same value.  Such re\-writing is safe in a single
! threaded context but may be unsafe in a multi\-threaded context.  Note that on
! some processors, if\-conversions may be required in order to enable
  vectorization.
  .Sp
  Enabled at level \fB\-Ofast\fR.
! .IP \fB\-funit\-at\-a\-time\fR 4
  .IX Item "-funit-at-a-time"
  This option is left for compatibility reasons. \fB\-funit\-at\-a\-time\fR
  has no effect, while \fB\-fno\-unit\-at\-a\-time\fR implies
  \&\fB\-fno\-toplevel\-reorder\fR and \fB\-fno\-section\-anchors\fR.
  .Sp
  Enabled by default.
! .IP \fB\-fno\-toplevel\-reorder\fR 4
  .IX Item "-fno-toplevel-reorder"
! Do not reorder top\-level functions, variables, and \f(CW\*(C`asm\*(C'\fR
  statements.  Output them in the same order that they appear in the
  input file.  When this option is used, unreferenced static variables
  are not removed.  This option is intended to support existing code
*************** use attributes when possible.
*** 12895,12901 ****
  also at \fB\-O0\fR if \fB\-fsection\-anchors\fR is explicitly requested.
  Additionally \fB\-fno\-toplevel\-reorder\fR implies
  \&\fB\-fno\-section\-anchors\fR.
! .IP "\fB\-funreachable\-traps\fR" 4
  .IX Item "-funreachable-traps"
  With this option, the compiler turns calls to
  \&\f(CW\*(C`_\|_builtin_unreachable\*(C'\fR into traps, instead of using them for
--- 12824,12830 ----
  also at \fB\-O0\fR if \fB\-fsection\-anchors\fR is explicitly requested.
  Additionally \fB\-fno\-toplevel\-reorder\fR implies
  \&\fB\-fno\-section\-anchors\fR.
! .IP \fB\-funreachable\-traps\fR 4
  .IX Item "-funreachable-traps"
  With this option, the compiler turns calls to
  \&\f(CW\*(C`_\|_builtin_unreachable\*(C'\fR into traps, instead of using them for
*************** options.  If \fB\-fsanitize=unreachable\
*** 12908,12924 ****
  takes priority over this one.
  .Sp
  This option is enabled by default at \fB\-O0\fR and \fB\-Og\fR.
! .IP "\fB\-fweb\fR" 4
  .IX Item "-fweb"
  Constructs webs as commonly used for register allocation purposes and assign
  each web individual pseudo register.  This allows the register allocation pass
  to operate on pseudos directly, but also strengthens several other optimization
! passes, such as \s-1CSE,\s0 loop optimizer and trivial dead code remover.  It can,
  however, make debugging impossible, since variables no longer stay in a
! \&\*(L"home register\*(R".
  .Sp
  Enabled by default with \fB\-funroll\-loops\fR.
! .IP "\fB\-fwhole\-program\fR" 4
  .IX Item "-fwhole-program"
  Assume that the current compilation unit represents the whole program being
  compiled.  All public functions and variables with the exception of \f(CW\*(C`main\*(C'\fR
--- 12837,12853 ----
  takes priority over this one.
  .Sp
  This option is enabled by default at \fB\-O0\fR and \fB\-Og\fR.
! .IP \fB\-fweb\fR 4
  .IX Item "-fweb"
  Constructs webs as commonly used for register allocation purposes and assign
  each web individual pseudo register.  This allows the register allocation pass
  to operate on pseudos directly, but also strengthens several other optimization
! passes, such as CSE, loop optimizer and trivial dead code remover.  It can,
  however, make debugging impossible, since variables no longer stay in a
! "home register".
  .Sp
  Enabled by default with \fB\-funroll\-loops\fR.
! .IP \fB\-fwhole\-program\fR 4
  .IX Item "-fwhole-program"
  Assume that the current compilation unit represents the whole program being
  compiled.  All public functions and variables with the exception of \f(CW\*(C`main\*(C'\fR
*************** and in effect are optimized more aggress
*** 12927,12946 ****
  .Sp
  With \fB\-flto\fR this option has a limited use.  In most cases the
  precise list of symbols used or exported from the binary is known the
! resolution info passed to the link-time optimizer by the linker plugin.  It is
  still useful if no linker plugin is used or during incremental link step when
  final code is produced (with \fB\-flto\fR
  \&\fB\-flinker\-output=nolto\-rel\fR).
! .IP "\fB\-flto[=\fR\fIn\fR\fB]\fR" 4
  .IX Item "-flto[=n]"
! This option runs the standard link-time optimizer.  When invoked
! with source code, it generates \s-1GIMPLE\s0 (one of \s-1GCC\s0's internal
! representations) and writes it to special \s-1ELF\s0 sections in the object
  file.  When the object files are linked together, all the function
! bodies are read from these \s-1ELF\s0 sections and instantiated as if they
  had been part of the same translation unit.
  .Sp
! To use the link-time optimizer, \fB\-flto\fR and optimization
  options should be specified at compile time and during the final link.
  It is recommended that you compile all the files participating in the
  same link with the same options and also specify those options at
--- 12856,12875 ----
  .Sp
  With \fB\-flto\fR this option has a limited use.  In most cases the
  precise list of symbols used or exported from the binary is known the
! resolution info passed to the link\-time optimizer by the linker plugin.  It is
  still useful if no linker plugin is used or during incremental link step when
  final code is produced (with \fB\-flto\fR
  \&\fB\-flinker\-output=nolto\-rel\fR).
! .IP \fB\-flto[=\fR\fIn\fR\fB]\fR 4
  .IX Item "-flto[=n]"
! This option runs the standard link\-time optimizer.  When invoked
! with source code, it generates GIMPLE (one of GCC\*(Aqs 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.
  .Sp
! To use the link\-time optimizer, \fB\-flto\fR and optimization
  options should be specified at compile time and during the final link.
  It is recommended that you compile all the files participating in the
  same link with the same options and also specify those options at
*************** For example:
*** 12953,12991 ****
  \&        gcc \-o myprog \-flto \-O2 foo.o bar.o
  .Ve
  .Sp
! The first two invocations to \s-1GCC\s0 save a bytecode representation
! of \s-1GIMPLE\s0 into special \s-1ELF\s0 sections inside \fIfoo.o\fR and
! \&\fIbar.o\fR.  The final invocation reads the \s-1GIMPLE\s0 bytecode from
  \&\fIfoo.o\fR and \fIbar.o\fR, merges the two files into a single
  internal image, and compiles the result as usual.  Since both
  \&\fIfoo.o\fR and \fIbar.o\fR are merged into a single image, this
! causes all the interprocedural analyses and optimizations in \s-1GCC\s0 to
  work across the two files as if they were a single one.  This means,
  for example, that the inliner is able to inline functions in
! \&\fIbar.o\fR into functions in \fIfoo.o\fR and vice-versa.
  .Sp
! Another (simpler) way to enable link-time optimization is:
  .Sp
  .Vb 1
  \&        gcc \-o myprog \-flto \-O2 foo.c bar.c
  .Ve
  .Sp
  The above generates bytecode for \fIfoo.c\fR and \fIbar.c\fR,
! merges them together into a single \s-1GIMPLE\s0 representation and optimizes
  them as usual to produce \fImyprog\fR.
  .Sp
! The important thing to keep in mind is that to enable link-time
! optimizations you need to use the \s-1GCC\s0 driver to perform the link step.
! \&\s-1GCC\s0 automatically performs link-time optimization if any of the
! objects involved were compiled with the \fB\-flto\fR command-line option.  
  You can always override
! the automatic decision to do link-time optimization
  by passing \fB\-fno\-lto\fR to the link command.
  .Sp
  To make whole program optimization effective, it is necessary to make
  certain whole program assumptions.  The compiler needs to know
  what functions and variables can be accessed by libraries and runtime
! outside of the link-time optimized unit.  When supported by the linker,
  the linker plugin (see \fB\-fuse\-linker\-plugin\fR) passes information
  to the compiler about used and externally visible symbols.  When
  the linker plugin is not available, \fB\-fwhole\-program\fR should be
--- 12882,12920 ----
  \&        gcc \-o myprog \-flto \-O2 foo.o bar.o
  .Ve
  .Sp
! The first two invocations to GCC save a bytecode representation
! of GIMPLE into special ELF sections inside \fIfoo.o\fR and
! \&\fIbar.o\fR.  The final invocation reads the GIMPLE bytecode from
  \&\fIfoo.o\fR and \fIbar.o\fR, merges the two files into a single
  internal image, and compiles the result as usual.  Since both
  \&\fIfoo.o\fR and \fIbar.o\fR are merged into a single image, this
! causes all the interprocedural analyses and optimizations in 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
! \&\fIbar.o\fR into functions in \fIfoo.o\fR and vice\-versa.
  .Sp
! Another (simpler) way to enable link\-time optimization is:
  .Sp
  .Vb 1
  \&        gcc \-o myprog \-flto \-O2 foo.c bar.c
  .Ve
  .Sp
  The above generates bytecode for \fIfoo.c\fR and \fIbar.c\fR,
! merges them together into a single GIMPLE representation and optimizes
  them as usual to produce \fImyprog\fR.
  .Sp
! The important thing to keep in mind is that to enable link\-time
! optimizations you need to use the GCC driver to perform the link step.
! GCC automatically performs link\-time optimization if any of the
! objects involved were compiled with the \fB\-flto\fR command\-line option.  
  You can always override
! the automatic decision to do link\-time optimization
  by passing \fB\-fno\-lto\fR to the link command.
  .Sp
  To make whole program optimization effective, it is necessary to make
  certain whole program assumptions.  The compiler needs to know
  what functions and variables can be accessed by libraries and runtime
! outside of the link\-time optimized unit.  When supported by the linker,
  the linker plugin (see \fB\-fuse\-linker\-plugin\fR) passes information
  to the compiler about used and externally visible symbols.  When
  the linker plugin is not available, \fB\-fwhole\-program\fR should be
*************** to more aggressive optimization decision
*** 12994,13020 ****
  .Sp
  When a file is compiled with \fB\-flto\fR without
  \&\fB\-fuse\-linker\-plugin\fR, the generated object file is larger than
! a regular object file because it contains \s-1GIMPLE\s0 bytecodes and the usual
  final code (see \fB\-ffat\-lto\-objects\fR).  This means that
! object files with \s-1LTO\s0 information can be linked as normal object
  files; if \fB\-fno\-lto\fR is passed to the linker, no
  interprocedural optimizations are applied.  Note that when
  \&\fB\-fno\-fat\-lto\-objects\fR is enabled the compile stage is faster
! but you cannot perform a regular, non-LTO link on them.
  .Sp
! When producing the final binary, \s-1GCC\s0 only
! applies link-time optimizations to those files that contain bytecode.
  Therefore, you can mix and match object files and libraries with
! \&\s-1GIMPLE\s0 bytecodes and final object code.  \s-1GCC\s0 automatically selects
! which files to optimize in \s-1LTO\s0 mode and which files to link without
  further processing.
  .Sp
  Generally, options specified at link time override those
! specified at compile time, although in some cases \s-1GCC\s0 attempts to infer
! link-time options from the settings used to compile the input files.
  .Sp
  If you do not specify an optimization level option \fB\-O\fR at
! link time, then \s-1GCC\s0 uses the highest optimization level 
  used when compiling the object files.  Note that it is generally 
  ineffective to specify an optimization level option only at link time and 
  not at compile time, for two reasons.  First, compiling without 
--- 12923,12949 ----
  .Sp
  When a file is compiled with \fB\-flto\fR without
  \&\fB\-fuse\-linker\-plugin\fR, the generated object file is larger than
! a regular object file because it contains GIMPLE bytecodes and the usual
  final code (see \fB\-ffat\-lto\-objects\fR).  This means that
! object files with LTO information can be linked as normal object
  files; if \fB\-fno\-lto\fR is passed to the linker, no
  interprocedural optimizations are applied.  Note that when
  \&\fB\-fno\-fat\-lto\-objects\fR is enabled the compile stage is faster
! but you cannot perform a regular, non\-LTO link on them.
  .Sp
! When producing the final binary, GCC only
! applies link\-time optimizations to those files that contain bytecode.
  Therefore, you can mix and match object files and libraries with
! GIMPLE bytecodes and final object code.  GCC automatically selects
! which files to optimize in LTO mode and which files to link without
  further processing.
  .Sp
  Generally, options specified at link time override those
! specified at compile time, although in some cases GCC attempts to infer
! link\-time options from the settings used to compile the input files.
  .Sp
  If you do not specify an optimization level option \fB\-O\fR at
! link time, then GCC uses the highest optimization level 
  used when compiling the object files.  Note that it is generally 
  ineffective to specify an optimization level option only at link time and 
  not at compile time, for two reasons.  First, compiling without 
*************** needed for effective optimization at lin
*** 13023,13029 ****
  optimization passes can be performed only at compile time and 
  not at link time.
  .Sp
! There are some code generation flags preserved by \s-1GCC\s0 when
  generating bytecodes, as they need to be used during the final link.
  Currently, the following options and their settings are taken from
  the first object file that explicitly specifies them: 
--- 12952,12958 ----
  optimization passes can be performed only at compile time and 
  not at link time.
  .Sp
! There are some code generation flags preserved by GCC when
  generating bytecodes, as they need to be used during the final link.
  Currently, the following options and their settings are taken from
  the first object file that explicitly specifies them: 
*************** The following options \fB\-fPIC\fR, \fB\
*** 13042,13048 ****
  \&        B<\-fPIC/\-fpic> + B<\-fpie> = B<\-fpie>
  .Ve
  .Sp
! Certain ABI-changing flags are required to match in all compilation units,
  and trying to override this at link time with a conflicting value
  is ignored.  This includes options such as \fB\-freg\-struct\-return\fR
  and \fB\-fpcc\-struct\-return\fR.
--- 12971,12977 ----
  \&        B<\-fPIC/\-fpic> + B<\-fpie> = B<\-fpie>
  .Ve
  .Sp
! Certain ABI\-changing flags are required to match in all compilation units,
  and trying to override this at link time with a conflicting value
  is ignored.  This includes options such as \fB\-freg\-struct\-return\fR
  and \fB\-fpcc\-struct\-return\fR.
*************** over \fB\-ffp\-contract=fast\fR.  You ca
*** 13057,13063 ****
  .Sp
  Diagnostic options such as \fB\-Wstringop\-overflow\fR are passed
  through to the link stage and their setting matches that of the
! compile-step at function granularity.  Note that this matters only
  for diagnostics emitted during optimization.  Note that code
  transforms such as inlining can lead to warnings being enabled
  or disabled for regions if code not consistent with the setting
--- 12986,12992 ----
  .Sp
  Diagnostic options such as \fB\-Wstringop\-overflow\fR are passed
  through to the link stage and their setting matches that of the
! compile\-step at function granularity.  Note that this matters only
  for diagnostics emitted during optimization.  Note that code
  transforms such as inlining can lead to warnings being enabled
  or disabled for regions if code not consistent with the setting
*************** When you need to pass options to the ass
*** 13067,13073 ****
  \&\fB\-Xassembler\fR make sure to either compile such translation
  units with \fB\-fno\-lto\fR or consistently use the same assembler
  options on all translation units.  You can alternatively also
! specify assembler options at \s-1LTO\s0 link time.
  .Sp
  To enable debug info generation you need to supply \fB\-g\fR at
  compile time.  If any of the input files at link time were built
--- 12996,13002 ----
  \&\fB\-Xassembler\fR make sure to either compile such translation
  units with \fB\-fno\-lto\fR or consistently use the same assembler
  options on all translation units.  You can alternatively also
! specify assembler options at LTO link time.
  .Sp
  To enable debug info generation you need to supply \fB\-g\fR at
  compile time.  If any of the input files at link time were built
*************** like the dwarf level \fB\-gdwarf\-5\fR n
*** 13077,13089 ****
  at the linker command line and mixing different settings in different
  translation units is discouraged.
  .Sp
! If \s-1LTO\s0 encounters objects with C linkage declared with incompatible
  types in separate translation units to be linked together (undefined
! behavior according to \s-1ISO C99 6.2.7\s0), a non-fatal diagnostic may be
  issued.  The behavior is still undefined at run time.  Similar
  diagnostics may be raised for other languages.
  .Sp
! Another feature of \s-1LTO\s0 is that it is possible to apply interprocedural
  optimizations on files written in different languages:
  .Sp
  .Vb 4
--- 13006,13018 ----
  at the linker command line and mixing different settings in different
  translation units is discouraged.
  .Sp
! If LTO encounters objects with C linkage declared with incompatible
  types in separate translation units to be linked together (undefined
! behavior according to ISO C99 6.2.7), a non\-fatal diagnostic may be
  issued.  The behavior is still undefined at run time.  Similar
  diagnostics may be raised for other languages.
  .Sp
! Another feature of LTO is that it is possible to apply interprocedural
  optimizations on files written in different languages:
  .Sp
  .Vb 4
*************** optimizations on files written in differ
*** 13093,13131 ****
  \&        g++ \-o myprog \-flto \-O3 foo.o bar.o baz.o \-lgfortran
  .Ve
  .Sp
! Notice that the final link is done with \fBg++\fR to get the \*(C+
  runtime libraries and \fB\-lgfortran\fR is added to get the Fortran
! runtime libraries.  In general, when mixing languages in \s-1LTO\s0 mode, you
  should use the same link command options as when mixing languages in a
! regular (non-LTO) compilation.
  .Sp
! If object files containing \s-1GIMPLE\s0 bytecode are stored in a library archive, say
! \&\fIlibfoo.a\fR, it is possible to extract and use them in an \s-1LTO\s0 link if you
  are using a linker with plugin support.  To create static libraries suitable
! for \s-1LTO,\s0 use \fBgcc-ar\fR and \fBgcc-ranlib\fR instead of \fBar\fR
  and \fBranlib\fR; 
! to show the symbols of object files with \s-1GIMPLE\s0 bytecode, use
! \&\fBgcc-nm\fR.  Those commands require that \fBar\fR, \fBranlib\fR
  and \fBnm\fR have been compiled with plugin support.  At link time, use the
  flag \fB\-fuse\-linker\-plugin\fR to ensure that the library participates in
! the \s-1LTO\s0 optimization process:
  .Sp
  .Vb 1
  \&        gcc \-o myprog \-O2 \-flto \-fuse\-linker\-plugin a.o b.o \-lfoo
  .Ve
  .Sp
  With the linker plugin enabled, the linker extracts the needed
! \&\s-1GIMPLE\s0 files from \fIlibfoo.a\fR and passes them on to the running \s-1GCC\s0
! to make them part of the aggregated \s-1GIMPLE\s0 image to be optimized.
  .Sp
  If you are not using a linker with plugin support and/or do not
  enable the linker plugin, then the objects inside \fIlibfoo.a\fR
  are extracted and linked as usual, but they do not participate
! in the \s-1LTO\s0 optimization process.  In order to make a static library suitable
! for both \s-1LTO\s0 optimization and usual linkage, compile its object files with
  \&\fB\-flto\fR \fB\-ffat\-lto\-objects\fR.
  .Sp
! Link-time optimizations do not require the presence of the whole program to
  operate.  If the program does not require any symbols to be exported, it is
  possible to combine \fB\-flto\fR and \fB\-fwhole\-program\fR to allow
  the interprocedural optimizers to use more aggressive assumptions which may
--- 13022,13060 ----
  \&        g++ \-o myprog \-flto \-O3 foo.o bar.o baz.o \-lgfortran
  .Ve
  .Sp
! Notice that the final link is done with \fBg++\fR to get the C++
  runtime libraries and \fB\-lgfortran\fR is added to get the Fortran
! runtime libraries.  In general, when mixing languages in LTO mode, you
  should use the same link command options as when mixing languages in a
! regular (non\-LTO) compilation.
  .Sp
! If object files containing GIMPLE bytecode are stored in a library archive, say
! \&\fIlibfoo.a\fR, it is possible to extract and use them in an LTO link if you
  are using a linker with plugin support.  To create static libraries suitable
! for LTO, use \fBgcc\-ar\fR and \fBgcc\-ranlib\fR instead of \fBar\fR
  and \fBranlib\fR; 
! to show the symbols of object files with GIMPLE bytecode, use
! \&\fBgcc\-nm\fR.  Those commands require that \fBar\fR, \fBranlib\fR
  and \fBnm\fR have been compiled with plugin support.  At link time, use the
  flag \fB\-fuse\-linker\-plugin\fR to ensure that the library participates in
! the LTO optimization process:
  .Sp
  .Vb 1
  \&        gcc \-o myprog \-O2 \-flto \-fuse\-linker\-plugin a.o b.o \-lfoo
  .Ve
  .Sp
  With the linker plugin enabled, the linker extracts the needed
! GIMPLE files from \fIlibfoo.a\fR and passes them on to the running GCC
! to make them part of the aggregated GIMPLE image to be optimized.
  .Sp
  If you are not using a linker with plugin support and/or do not
  enable the linker plugin, then the objects inside \fIlibfoo.a\fR
  are extracted and linked as usual, but they do not participate
! in the LTO optimization process.  In order to make a static library suitable
! for both LTO optimization and usual linkage, compile its object files with
  \&\fB\-flto\fR \fB\-ffat\-lto\-objects\fR.
  .Sp
! Link\-time optimizations do not require the presence of the whole program to
  operate.  If the program does not require any symbols to be exported, it is
  possible to combine \fB\-flto\fR and \fB\-fwhole\-program\fR to allow
  the interprocedural optimizers to use more aggressive assumptions which may
*************** lead to improved optimization opportunit
*** 13133,13168 ****
  Use of \fB\-fwhole\-program\fR is not needed when linker plugin is
  active (see \fB\-fuse\-linker\-plugin\fR).
  .Sp
! The current implementation of \s-1LTO\s0 makes no
  attempt to generate bytecode that is portable between different
  types of hosts.  The bytecode files are versioned and there is a
  strict version check, so bytecode files generated in one version of
! \&\s-1GCC\s0 do not work with an older or newer version of \s-1GCC.\s0
  .Sp
! Link-time optimization does not work well with generation of debugging
! information on systems other than those using a combination of \s-1ELF\s0 and
! \&\s-1DWARF.\s0
  .Sp
  If you specify the optional \fIn\fR, the optimization and code
  generation done at link time is executed in parallel using \fIn\fR
  parallel jobs by utilizing an installed \fBmake\fR program.  The
! environment variable \fB\s-1MAKE\s0\fR may be used to override the program
  used.
  .Sp
! You can also specify \fB\-flto=jobserver\fR to use \s-1GNU\s0 make's
  job server mode to determine the number of parallel jobs. This
! is useful when the Makefile calling \s-1GCC\s0 is already executing in parallel.
  You must prepend a \fB+\fR to the command recipe in the parent Makefile
! for this to work.  This option likely only works if \fB\s-1MAKE\s0\fR is
! \&\s-1GNU\s0 make.  Even without the option value, \s-1GCC\s0 tries to automatically
! detect a running \s-1GNU\s0 make's job server.
  .Sp
! Use \fB\-flto=auto\fR to use \s-1GNU\s0 make's job server, if available,
! or otherwise fall back to autodetection of the number of \s-1CPU\s0 threads
  present in your system.
! .IP "\fB\-flto\-partition=\fR\fIalg\fR" 4
  .IX Item "-flto-partition=alg"
! Specify the partitioning algorithm used by the link-time optimizer.
  The value is either \fB1to1\fR to specify a partitioning mirroring
  the original source files or \fBbalanced\fR to specify partitioning
  into equally sized chunks (whenever possible) or \fBmax\fR to create
--- 13062,13097 ----
  Use of \fB\-fwhole\-program\fR is not needed when linker plugin is
  active (see \fB\-fuse\-linker\-plugin\fR).
  .Sp
! The current implementation of 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 do not work with an older or newer version of GCC.
  .Sp
! Link\-time optimization does not work well with generation of debugging
! information on systems other than those using a combination of ELF and
! DWARF.
  .Sp
  If you specify the optional \fIn\fR, the optimization and code
  generation done at link time is executed in parallel using \fIn\fR
  parallel jobs by utilizing an installed \fBmake\fR program.  The
! environment variable \fBMAKE\fR may be used to override the program
  used.
  .Sp
! You can also specify \fB\-flto=jobserver\fR to use GNU make\*(Aqs
  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 \fB+\fR to the command recipe in the parent Makefile
! for this to work.  This option likely only works if \fBMAKE\fR is
! GNU make.  Even without the option value, GCC tries to automatically
! detect a running GNU make\*(Aqs job server.
  .Sp
! Use \fB\-flto=auto\fR to use GNU make\*(Aqs job server, if available,
! or otherwise fall back to autodetection of the number of CPU threads
  present in your system.
! .IP \fB\-flto\-partition=\fR\fIalg\fR 4
  .IX Item "-flto-partition=alg"
! Specify the partitioning algorithm used by the link\-time optimizer.
  The value is either \fB1to1\fR to specify a partitioning mirroring
  the original source files or \fBbalanced\fR to specify partitioning
  into equally sized chunks (whenever possible) or \fBmax\fR to create
*************** as an workaround for various code orderi
*** 13173,13233 ****
  partitioning is intended for internal testing only.
  The value \fBone\fR specifies that exactly one partition should be
  used while the value \fBnone\fR bypasses partitioning and executes
! the link-time optimization step directly from the \s-1WPA\s0 phase.
! .IP "\fB\-flto\-compression\-level=\fR\fIn\fR" 4
  .IX Item "-flto-compression-level=n"
  This option specifies the level of compression used for intermediate
! language written to \s-1LTO\s0 object files, and is only meaningful in
! conjunction with \s-1LTO\s0 mode (\fB\-flto\fR).  \s-1GCC\s0 currently supports two
! \&\s-1LTO\s0 compression algorithms. For zstd, valid values are 0 (no compression)
  to 19 (maximum compression), while zlib supports values from 0 to 9.
  Values outside this range are clamped to either minimum or maximum
  of the supported values.  If the option is not given,
  a default balanced compression setting is used.
! .IP "\fB\-fuse\-linker\-plugin\fR" 4
  .IX Item "-fuse-linker-plugin"
! Enables the use of a linker plugin during link-time optimization.  This
  option relies on plugin support in the linker, which is available in gold
! or in \s-1GNU\s0 ld 2.21 or newer.
  .Sp
! This option enables the extraction of object files with \s-1GIMPLE\s0 bytecode out
  of library archives. This improves the quality of optimization by exposing
! more code to the link-time optimizer.  This information specifies what
! symbols can be accessed externally (by non-LTO object or during dynamic
  linking).  Resulting code quality improvements on binaries (and shared
  libraries that use hidden visibility) are similar to \fB\-fwhole\-program\fR.
  See \fB\-flto\fR for a description of the effect of this flag and how to
  use it.
  .Sp
! This option is enabled by default when \s-1LTO\s0 support in \s-1GCC\s0 is enabled
! and \s-1GCC\s0 was configured for use with
! a linker supporting plugins (\s-1GNU\s0 ld 2.21 or newer or gold).
! .IP "\fB\-ffat\-lto\-objects\fR" 4
  .IX Item "-ffat-lto-objects"
! Fat \s-1LTO\s0 objects are object files that contain both the intermediate language
! and the object code. This makes them usable for both \s-1LTO\s0 linking and normal
  linking. This option is effective only when compiling with \fB\-flto\fR
  and is ignored at link time.
  .Sp
! \&\fB\-fno\-fat\-lto\-objects\fR improves compilation time over plain \s-1LTO,\s0 but
! requires the complete toolchain to be aware of \s-1LTO.\s0 It requires a linker with
  linker plugin support for basic functionality.  Additionally,
  \&\fBnm\fR, \fBar\fR and \fBranlib\fR
! need to support linker plugins to allow a full-featured build environment
! (capable of building static libraries etc).  \s-1GCC\s0 provides the \fBgcc-ar\fR,
! \&\fBgcc-nm\fR, \fBgcc-ranlib\fR wrappers to pass the right options
! to these tools. With non fat \s-1LTO\s0 makefiles need to be modified to use them.
  .Sp
! Note that modern binutils provide plugin auto-load mechanism.
! Installing the linker plugin into \fI\f(CI$libdir\fI/bfd\-plugins\fR has the same
! effect as usage of the command wrappers (\fBgcc-ar\fR, \fBgcc-nm\fR and
! \&\fBgcc-ranlib\fR).
  .Sp
  The default is \fB\-fno\-fat\-lto\-objects\fR on targets with linker plugin
  support.
! .IP "\fB\-fcompare\-elim\fR" 4
  .IX Item "-fcompare-elim"
! After register allocation and post-register allocation instruction splitting,
  identify arithmetic instructions that compute processor flags similar to a
  comparison operation based on that arithmetic.  If possible, eliminate the
  explicit comparison operation.
--- 13102,13162 ----
  partitioning is intended for internal testing only.
  The value \fBone\fR specifies that exactly one partition should be
  used while the value \fBnone\fR bypasses partitioning and executes
! the link\-time optimization step directly from the WPA phase.
! .IP \fB\-flto\-compression\-level=\fR\fIn\fR 4
  .IX Item "-flto-compression-level=n"
  This option specifies the level of compression used for intermediate
! language written to LTO object files, and is only meaningful in
! conjunction with LTO mode (\fB\-flto\fR).  GCC currently supports two
! LTO compression algorithms. For zstd, valid values are 0 (no compression)
  to 19 (maximum compression), while zlib supports values from 0 to 9.
  Values outside this range are clamped to either minimum or maximum
  of the supported values.  If the option is not given,
  a default balanced compression setting is used.
! .IP \fB\-fuse\-linker\-plugin\fR 4
  .IX Item "-fuse-linker-plugin"
! Enables the use of a linker plugin during link\-time optimization.  This
  option relies on plugin support in the linker, which is available in gold
! or in GNU ld 2.21 or newer.
  .Sp
! 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 \fB\-fwhole\-program\fR.
  See \fB\-flto\fR for a description of the effect of this flag and how to
  use it.
  .Sp
! This option is enabled by default when 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).
! .IP \fB\-ffat\-lto\-objects\fR 4
  .IX Item "-ffat-lto-objects"
! Fat LTO objects are object files that contain both the intermediate language
! and the object code. This makes them usable for both LTO linking and normal
  linking. This option is effective only when compiling with \fB\-flto\fR
  and is ignored at link time.
  .Sp
! \&\fB\-fno\-fat\-lto\-objects\fR improves compilation time over plain LTO, but
! requires the complete toolchain to be aware of LTO. It requires a linker with
  linker plugin support for basic functionality.  Additionally,
  \&\fBnm\fR, \fBar\fR and \fBranlib\fR
! need to support linker plugins to allow a full\-featured build environment
! (capable of building static libraries etc).  GCC provides the \fBgcc\-ar\fR,
! \&\fBgcc\-nm\fR, \fBgcc\-ranlib\fR wrappers to pass the right options
! to these tools. With non fat LTO makefiles need to be modified to use them.
  .Sp
! Note that modern binutils provide plugin auto\-load mechanism.
! Installing the linker plugin into \fR\f(CI$libdir\fR\fI/bfd\-plugins\fR has the same
! effect as usage of the command wrappers (\fBgcc\-ar\fR, \fBgcc\-nm\fR and
! \&\fBgcc\-ranlib\fR).
  .Sp
  The default is \fB\-fno\-fat\-lto\-objects\fR on targets with linker plugin
  support.
! .IP \fB\-fcompare\-elim\fR 4
  .IX Item "-fcompare-elim"
! After register allocation and post\-register allocation instruction splitting,
  identify arithmetic instructions that compute processor flags similar to a
  comparison operation based on that arithmetic.  If possible, eliminate the
  explicit comparison operation.
*************** This pass only applies to certain target
*** 13236,13257 ****
  the comparison operation before register allocation is complete.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fcprop\-registers\fR" 4
  .IX Item "-fcprop-registers"
! After register allocation and post-register allocation instruction splitting,
! perform a copy-propagation pass to try to reduce scheduling dependencies
  and occasionally eliminate the copy.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fprofile\-correction\fR" 4
  .IX Item "-fprofile-correction"
! Profiles collected using an instrumented binary for multi-threaded programs may
  be inconsistent due to missed counter updates. When this option is specified,
! \&\s-1GCC\s0 uses heuristics to correct or smooth out such inconsistencies. By
! default, \s-1GCC\s0 emits an error message when an inconsistent profile is detected.
  .Sp
  This option is enabled by \fB\-fauto\-profile\fR.
! .IP "\fB\-fprofile\-partial\-training\fR" 4
  .IX Item "-fprofile-partial-training"
  With \f(CW\*(C`\-fprofile\-use\*(C'\fR all portions of programs not executed during train
  run are optimized agressively for size rather than speed.  In some cases it is
--- 13165,13186 ----
  the comparison operation before register allocation is complete.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fcprop\-registers\fR 4
  .IX Item "-fcprop-registers"
! After register allocation and post\-register allocation instruction splitting,
! perform a copy\-propagation pass to try to reduce scheduling dependencies
  and occasionally eliminate the copy.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fprofile\-correction\fR 4
  .IX Item "-fprofile-correction"
! Profiles collected using an instrumented binary for multi\-threaded programs may
  be inconsistent due to missed counter updates. When this option is specified,
! GCC uses heuristics to correct or smooth out such inconsistencies. By
! default, GCC emits an error message when an inconsistent profile is detected.
  .Sp
  This option is enabled by \fB\-fauto\-profile\fR.
! .IP \fB\-fprofile\-partial\-training\fR 4
  .IX Item "-fprofile-partial-training"
  With \f(CW\*(C`\-fprofile\-use\*(C'\fR all portions of programs not executed during train
  run are optimized agressively for size rather than speed.  In some cases it is
*************** functions not executed during the train
*** 13263,13275 ****
  they were compiled without profile feedback. This leads to better performance
  when train run is not representative but also leads to significantly bigger
  code.
! .IP "\fB\-fprofile\-use\fR" 4
  .IX Item "-fprofile-use"
  .PD 0
! .IP "\fB\-fprofile\-use=\fR\fIpath\fR" 4
  .IX Item "-fprofile-use=path"
  .PD
! Enable profile feedback-directed optimizations, 
  and the following optimizations, many of which
  are generally profitable only with profile feedback available:
  .Sp
--- 13192,13204 ----
  they were compiled without profile feedback. This leads to better performance
  when train run is not representative but also leads to significantly bigger
  code.
! .IP \fB\-fprofile\-use\fR 4
  .IX Item "-fprofile-use"
  .PD 0
! .IP \fB\-fprofile\-use=\fR\fIpath\fR 4
  .IX Item "-fprofile-use=path"
  .PD
! Enable profile feedback\-directed optimizations, 
  and the following optimizations, many of which
  are generally profitable only with profile feedback available:
  .Sp
*************** are generally profitable only with profi
*** 13283,13303 ****
  .Sp
  Before you can use this option, you must first generate profiling information.
  .Sp
! By default, \s-1GCC\s0 emits an error message if the feedback profiles do not
  match the source code.  This error can be turned into a warning by using
  \&\fB\-Wno\-error=coverage\-mismatch\fR.  Note this may result in poorly
! optimized code.  Additionally, by default, \s-1GCC\s0 also emits a warning message if
  the feedback profiles do not exist (see \fB\-Wmissing\-profile\fR).
  .Sp
! If \fIpath\fR is specified, \s-1GCC\s0 looks at the \fIpath\fR to find
  the profile feedback data files. See \fB\-fprofile\-dir\fR.
! .IP "\fB\-fauto\-profile\fR" 4
  .IX Item "-fauto-profile"
  .PD 0
! .IP "\fB\-fauto\-profile=\fR\fIpath\fR" 4
  .IX Item "-fauto-profile=path"
  .PD
! Enable sampling-based feedback-directed optimizations, 
  and the following optimizations,
  many of which are generally profitable only with profile feedback available:
  .Sp
--- 13212,13232 ----
  .Sp
  Before you can use this option, you must first generate profiling information.
  .Sp
! 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
  \&\fB\-Wno\-error=coverage\-mismatch\fR.  Note this may result in poorly
! optimized code.  Additionally, by default, GCC also emits a warning message if
  the feedback profiles do not exist (see \fB\-Wmissing\-profile\fR).
  .Sp
! If \fIpath\fR is specified, GCC looks at the \fIpath\fR to find
  the profile feedback data files. See \fB\-fprofile\-dir\fR.
! .IP \fB\-fauto\-profile\fR 4
  .IX Item "-fauto-profile"
  .PD 0
! .IP \fB\-fauto\-profile=\fR\fIpath\fR 4
  .IX Item "-fauto-profile=path"
  .PD
! Enable sampling\-based feedback\-directed optimizations, 
  and the following optimizations,
  many of which are generally profitable only with profile feedback available:
  .Sp
*************** E.g.
*** 13324,13330 ****
  .Ve
  .Sp
  Then use the \fBcreate_gcov\fR tool to convert the raw profile data
! to a format that can be used by \s-1GCC.\s0  You must also supply the 
  unstripped binary for your program to this tool.  
  See <\fBhttps://github.com/google/autofdo\fR>.
  .Sp
--- 13253,13259 ----
  .Ve
  .Sp
  Then use the \fBcreate_gcov\fR tool to convert the raw profile data
! to a format that can be used by GCC.  You must also supply the 
  unstripped binary for your program to this tool.  
  See <\fBhttps://github.com/google/autofdo\fR>.
  .Sp
*************** E.g.
*** 13335,13380 ****
  \&            \-\-gcov=profile.afdo
  .Ve
  .PP
! The following options control compiler behavior regarding floating-point 
  arithmetic.  These options trade off between speed and
  correctness.  All must be specifically enabled.
! .IP "\fB\-ffloat\-store\fR" 4
  .IX Item "-ffloat-store"
! Do not store floating-point variables in registers, and inhibit other
! options that might change whether a floating-point value is taken from a
  register or memory.
  .Sp
  This option prevents undesirable excess precision on machines such as
  the 68000 where the floating registers (of the 68881) keep more
  precision than a \f(CW\*(C`double\*(C'\fR is supposed to have.  Similarly for the
  x86 architecture.  For most programs, the excess precision does only
! good, but a few programs rely on the precise definition of \s-1IEEE\s0 floating
  point.  Use \fB\-ffloat\-store\fR for such programs, after modifying
  them to store all pertinent intermediate computations into variables.
! .IP "\fB\-fexcess\-precision=\fR\fIstyle\fR" 4
  .IX Item "-fexcess-precision=style"
  This option allows further control over excess precision on machines
! where floating-point operations occur in a format with more precision or
! range than the \s-1IEEE\s0 standard and interchange floating-point types.  By
  default, \fB\-fexcess\-precision=fast\fR is in effect; this means that
  operations may be carried out in a wider precision than the types specified
  in the source if that would result in faster code, and it is unpredictable
  when rounding to the types specified in the source code takes place.
! When compiling C or \*(C+, if \fB\-fexcess\-precision=standard\fR is specified
! then excess precision follows the rules specified in \s-1ISO C99\s0 or \*(C+; in particular,
  both casts and assignments cause values to be rounded to their
  semantic types (whereas \fB\-ffloat\-store\fR only affects
! assignments).  This option is enabled by default for C or \*(C+ if a strict
  conformance option such as \fB\-std=c99\fR or \fB\-std=c++17\fR is used.
  \&\fB\-ffast\-math\fR enables \fB\-fexcess\-precision=fast\fR by default
  regardless of whether a strict conformance option is used.
  .Sp
  \&\fB\-fexcess\-precision=standard\fR is not implemented for languages
! other than C or \*(C+.  On the x86, it has no effect if \fB\-mfpmath=sse\fR
! or \fB\-mfpmath=sse+387\fR is specified; in the former case, \s-1IEEE\s0
  semantics apply without excess precision, and in the latter, rounding
  is unpredictable.
! .IP "\fB\-ffast\-math\fR" 4
  .IX Item "-ffast-math"
  Sets the options \fB\-fno\-math\-errno\fR, \fB\-funsafe\-math\-optimizations\fR,
  \&\fB\-ffinite\-math\-only\fR, \fB\-fno\-rounding\-math\fR,
--- 13264,13309 ----
  \&            \-\-gcov=profile.afdo
  .Ve
  .PP
! The following options control compiler behavior regarding floating\-point 
  arithmetic.  These options trade off between speed and
  correctness.  All must be specifically enabled.
! .IP \fB\-ffloat\-store\fR 4
  .IX Item "-ffloat-store"
! Do not store floating\-point variables in registers, and inhibit other
! options that might change whether a floating\-point value is taken from a
  register or memory.
  .Sp
  This option prevents undesirable excess precision on machines such as
  the 68000 where the floating registers (of the 68881) keep more
  precision than a \f(CW\*(C`double\*(C'\fR is supposed to have.  Similarly for the
  x86 architecture.  For most programs, the excess precision does only
! good, but a few programs rely on the precise definition of IEEE floating
  point.  Use \fB\-ffloat\-store\fR for such programs, after modifying
  them to store all pertinent intermediate computations into variables.
! .IP \fB\-fexcess\-precision=\fR\fIstyle\fR 4
  .IX Item "-fexcess-precision=style"
  This option allows further control over excess precision on machines
! where floating\-point operations occur in a format with more precision or
! range than the IEEE standard and interchange floating\-point types.  By
  default, \fB\-fexcess\-precision=fast\fR is in effect; this means that
  operations may be carried out in a wider precision than the types specified
  in the source if that would result in faster code, and it is unpredictable
  when rounding to the types specified in the source code takes place.
! When compiling C or C++, if \fB\-fexcess\-precision=standard\fR is specified
! then excess precision follows the rules specified in ISO C99 or C++; in particular,
  both casts and assignments cause values to be rounded to their
  semantic types (whereas \fB\-ffloat\-store\fR only affects
! assignments).  This option is enabled by default for C or C++ if a strict
  conformance option such as \fB\-std=c99\fR or \fB\-std=c++17\fR is used.
  \&\fB\-ffast\-math\fR enables \fB\-fexcess\-precision=fast\fR by default
  regardless of whether a strict conformance option is used.
  .Sp
  \&\fB\-fexcess\-precision=standard\fR is not implemented for languages
! other than C or C++.  On the x86, it has no effect if \fB\-mfpmath=sse\fR
! or \fB\-mfpmath=sse+387\fR is specified; in the former case, IEEE
  semantics apply without excess precision, and in the latter, rounding
  is unpredictable.
! .IP \fB\-ffast\-math\fR 4
  .IX Item "-ffast-math"
  Sets the options \fB\-fno\-math\-errno\fR, \fB\-funsafe\-math\-optimizations\fR,
  \&\fB\-ffinite\-math\-only\fR, \fB\-fno\-rounding\-math\fR,
*************** This option causes the preprocessor macr
*** 13385,13403 ****
  .Sp
  This option is not turned on by any \fB\-O\fR option besides
  \&\fB\-Ofast\fR since it can result in incorrect output for programs
! that depend on an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications
  for math functions. It may, however, yield faster code for programs
  that do not require the guarantees of these specifications.
! .IP "\fB\-fno\-math\-errno\fR" 4
  .IX Item "-fno-math-errno"
  Do not set \f(CW\*(C`errno\*(C'\fR after calling math functions that are executed
  with a single instruction, e.g., \f(CW\*(C`sqrt\*(C'\fR.  A program that relies on
! \&\s-1IEEE\s0 exceptions for math error handling may want to use this flag
! for speed while maintaining \s-1IEEE\s0 arithmetic compatibility.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
  math functions. It may, however, yield faster code for programs
  that do not require the guarantees of these specifications.
  .Sp
--- 13314,13332 ----
  .Sp
  This option is not turned on by any \fB\-O\fR option besides
  \&\fB\-Ofast\fR since it can result in incorrect output for programs
! that depend on an exact implementation of 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.
! .IP \fB\-fno\-math\-errno\fR 4
  .IX Item "-fno-math-errno"
  Do not set \f(CW\*(C`errno\*(C'\fR after calling math functions that are executed
  with a single instruction, e.g., \f(CW\*(C`sqrt\*(C'\fR.  A program that relies on
! IEEE exceptions for math error handling may want to use this flag
! for speed while maintaining IEEE arithmetic compatibility.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of 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.
  .Sp
*************** The default is \fB\-fmath\-errno\fR.
*** 13406,13445 ****
  On Darwin systems, the math library never sets \f(CW\*(C`errno\*(C'\fR.  There is
  therefore no reason for the compiler to consider the possibility that
  it might, and \fB\-fno\-math\-errno\fR is the default.
! .IP "\fB\-funsafe\-math\-optimizations\fR" 4
  .IX Item "-funsafe-math-optimizations"
! Allow optimizations for floating-point arithmetic that (a) assume
! that arguments and results are valid and (b) may violate \s-1IEEE\s0 or
! \&\s-1ANSI\s0 standards.  When used at link time, it may include libraries
! or startup files that change the default \s-1FPU\s0 control word or other
  similar optimizations.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
  math functions. It may, however, yield faster code for programs
  that do not require the guarantees of these specifications.
  Enables \fB\-fno\-signed\-zeros\fR, \fB\-fno\-trapping\-math\fR,
  \&\fB\-fassociative\-math\fR and \fB\-freciprocal\-math\fR.
  .Sp
  The default is \fB\-fno\-unsafe\-math\-optimizations\fR.
! .IP "\fB\-fassociative\-math\fR" 4
  .IX Item "-fassociative-math"
! Allow re-association of operands in series of floating-point operations.
! This violates the \s-1ISO C\s0 and \*(C+ language standard by possibly changing
! computation result.  \s-1NOTE:\s0 re-ordering may change the sign of zero as
  well as ignore NaNs and inhibit or create underflow or overflow (and
  thus cannot be used on code that relies on rounding behavior like
! \&\f(CW\*(C`(x + 2**52) \- 2**52\*(C'\fR.  May also reorder floating-point comparisons
  and thus may not be used when ordered comparisons are required.
  This option requires that both \fB\-fno\-signed\-zeros\fR and
! \&\fB\-fno\-trapping\-math\fR be in effect.  Moreover, it doesn't make
  much sense with \fB\-frounding\-math\fR. For Fortran the option
  is automatically enabled when both \fB\-fno\-signed\-zeros\fR and
  \&\fB\-fno\-trapping\-math\fR are in effect.
  .Sp
  The default is \fB\-fno\-associative\-math\fR.
! .IP "\fB\-freciprocal\-math\fR" 4
  .IX Item "-freciprocal-math"
  Allow the reciprocal of a value to be used instead of dividing by
  the value if this enables optimizations.  For example \f(CW\*(C`x / y\*(C'\fR
--- 13335,13374 ----
  On Darwin systems, the math library never sets \f(CW\*(C`errno\*(C'\fR.  There is
  therefore no reason for the compiler to consider the possibility that
  it might, and \fB\-fno\-math\-errno\fR is the default.
! .IP \fB\-funsafe\-math\-optimizations\fR 4
  .IX Item "-funsafe-math-optimizations"
! Allow optimizations for floating\-point arithmetic that (a) assume
! that arguments and results are valid and (b) may violate 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.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of 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 \fB\-fno\-signed\-zeros\fR, \fB\-fno\-trapping\-math\fR,
  \&\fB\-fassociative\-math\fR and \fB\-freciprocal\-math\fR.
  .Sp
  The default is \fB\-fno\-unsafe\-math\-optimizations\fR.
! .IP \fB\-fassociative\-math\fR 4
  .IX Item "-fassociative-math"
! Allow re\-association of operands in series of floating\-point operations.
! This violates the ISO C and C++ language standard by possibly changing
! computation result.  NOTE: re\-ordering may change the sign of zero as
  well as ignore NaNs and inhibit or create underflow or overflow (and
  thus cannot be used on code that relies on rounding behavior like
! \&\f(CW\*(C`(x + 2**52) \- 2**52\*(C'\fR.  May also reorder floating\-point comparisons
  and thus may not be used when ordered comparisons are required.
  This option requires that both \fB\-fno\-signed\-zeros\fR and
! \&\fB\-fno\-trapping\-math\fR be in effect.  Moreover, it doesn\*(Aqt make
  much sense with \fB\-frounding\-math\fR. For Fortran the option
  is automatically enabled when both \fB\-fno\-signed\-zeros\fR and
  \&\fB\-fno\-trapping\-math\fR are in effect.
  .Sp
  The default is \fB\-fno\-associative\-math\fR.
! .IP \fB\-freciprocal\-math\fR 4
  .IX Item "-freciprocal-math"
  Allow the reciprocal of a value to be used instead of dividing by
  the value if this enables optimizations.  For example \f(CW\*(C`x / y\*(C'\fR
*************** is subject to common subexpression elimi
*** 13448,13517 ****
  precision and increases the number of flops operating on the value.
  .Sp
  The default is \fB\-fno\-reciprocal\-math\fR.
! .IP "\fB\-ffinite\-math\-only\fR" 4
  .IX Item "-ffinite-math-only"
! Allow optimizations for floating-point arithmetic that assume
  that arguments and results are not NaNs or +\-Infs.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
  math functions. It may, however, yield faster code for programs
  that do not require the guarantees of these specifications.
  .Sp
  The default is \fB\-fno\-finite\-math\-only\fR.
! .IP "\fB\-fno\-signed\-zeros\fR" 4
  .IX Item "-fno-signed-zeros"
! Allow optimizations for floating-point arithmetic that ignore the
! signedness of zero.  \s-1IEEE\s0 arithmetic specifies the behavior of
  distinct +0.0 and \-0.0 values, which then prohibits simplification
  of expressions such as x+0.0 or 0.0*x (even with \fB\-ffinite\-math\-only\fR).
! This option implies that the sign of a zero result isn't significant.
  .Sp
  The default is \fB\-fsigned\-zeros\fR.
! .IP "\fB\-fno\-trapping\-math\fR" 4
  .IX Item "-fno-trapping-math"
! Compile code assuming that floating-point operations cannot generate
! user-visible traps.  These traps include division by zero, overflow,
  underflow, inexact result and invalid operation.  This option requires
  that \fB\-fno\-signaling\-nans\fR be in effect.  Setting this option may
! allow faster code if one relies on \*(L"non-stop\*(R" \s-1IEEE\s0 arithmetic, for example.
  .Sp
  This option should never be turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
  math functions.
  .Sp
  The default is \fB\-ftrapping\-math\fR.
  .Sp
! Future versions of \s-1GCC\s0 may provide finer control of this setting
! using C99's \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma.  This command-line option
  will be used along with \fB\-frounding\-math\fR to specify the
  default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
! .IP "\fB\-frounding\-math\fR" 4
  .IX Item "-frounding-math"
! Disable transformations and optimizations that assume default floating-point
! rounding behavior.  This is round-to-zero for all floating point
! to integer conversions, and round-to-nearest for all other arithmetic
  truncations.  This option should be specified for programs that change
! the \s-1FP\s0 rounding mode dynamically, or that may be executed with a
! non-default rounding mode.  This option disables constant folding of
! floating-point expressions at compile time (which may be affected by
  rounding mode) and arithmetic transformations that are unsafe in the
! presence of sign-dependent rounding modes.
  .Sp
  The default is \fB\-fno\-rounding\-math\fR.
  .Sp
  This option is experimental and does not currently guarantee to
! disable all \s-1GCC\s0 optimizations that are affected by rounding mode.
! Future versions of \s-1GCC\s0 may provide finer control of this setting
! using C99's \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma.  This command-line option
  will be used along with \fB\-ftrapping\-math\fR to specify the
  default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
! .IP "\fB\-fsignaling\-nans\fR" 4
  .IX Item "-fsignaling-nans"
! Compile code assuming that \s-1IEEE\s0 signaling NaNs may generate user-visible
! traps during floating-point operations.  Setting this option disables
  optimizations that may change the number of exceptions visible with
  signaling NaNs.  This option implies \fB\-ftrapping\-math\fR.
  .Sp
--- 13377,13446 ----
  precision and increases the number of flops operating on the value.
  .Sp
  The default is \fB\-fno\-reciprocal\-math\fR.
! .IP \fB\-ffinite\-math\-only\fR 4
  .IX Item "-ffinite-math-only"
! Allow optimizations for floating\-point arithmetic that assume
  that arguments and results are not NaNs or +\-Infs.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of 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.
  .Sp
  The default is \fB\-fno\-finite\-math\-only\fR.
! .IP \fB\-fno\-signed\-zeros\fR 4
  .IX Item "-fno-signed-zeros"
! Allow optimizations for floating\-point arithmetic that ignore the
! signedness of zero.  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 \fB\-ffinite\-math\-only\fR).
! This option implies that the sign of a zero result isn\*(Aqt significant.
  .Sp
  The default is \fB\-fsigned\-zeros\fR.
! .IP \fB\-fno\-trapping\-math\fR 4
  .IX Item "-fno-trapping-math"
! Compile code assuming that floating\-point operations cannot generate
! user\-visible traps.  These traps include division by zero, overflow,
  underflow, inexact result and invalid operation.  This option requires
  that \fB\-fno\-signaling\-nans\fR be in effect.  Setting this option may
! allow faster code if one relies on "non\-stop" IEEE arithmetic, for example.
  .Sp
  This option should never be turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of IEEE or ISO rules/specifications for
  math functions.
  .Sp
  The default is \fB\-ftrapping\-math\fR.
  .Sp
! Future versions of GCC may provide finer control of this setting
! using C99\*(Aqs \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma.  This command\-line option
  will be used along with \fB\-frounding\-math\fR to specify the
  default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
! .IP \fB\-frounding\-math\fR 4
  .IX Item "-frounding-math"
! Disable transformations and optimizations that assume default floating\-point
! rounding behavior.  This is round\-to\-zero for all floating point
! to integer conversions, and round\-to\-nearest for all other arithmetic
  truncations.  This option should be specified for programs that change
! the 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.
  .Sp
  The default is \fB\-fno\-rounding\-math\fR.
  .Sp
  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\*(Aqs \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma.  This command\-line option
  will be used along with \fB\-ftrapping\-math\fR to specify the
  default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
! .IP \fB\-fsignaling\-nans\fR 4
  .IX Item "-fsignaling-nans"
! Compile code assuming that 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 \fB\-ftrapping\-math\fR.
  .Sp
*************** be defined.
*** 13521,13549 ****
  The default is \fB\-fno\-signaling\-nans\fR.
  .Sp
  This option is experimental and does not currently guarantee to
! disable all \s-1GCC\s0 optimizations that affect signaling NaN behavior.
! .IP "\fB\-fno\-fp\-int\-builtin\-inexact\fR" 4
  .IX Item "-fno-fp-int-builtin-inexact"
! Do not allow the built-in functions \f(CW\*(C`ceil\*(C'\fR, \f(CW\*(C`floor\*(C'\fR,
  \&\f(CW\*(C`round\*(C'\fR and \f(CW\*(C`trunc\*(C'\fR, and their \f(CW\*(C`float\*(C'\fR and \f(CW\*(C`long
! double\*(C'\fR variants, to generate code that raises the \*(L"inexact\*(R"
! floating-point exception for noninteger arguments.  \s-1ISO C99\s0 and C11
! allow these functions to raise the \*(L"inexact\*(R" exception, but \s-1ISO/IEC
! TS 18661\-1:2014,\s0 the C bindings to \s-1IEEE 754\-2008,\s0 as integrated into
! \&\s-1ISO C2X,\s0 does not allow these functions to do so.
  .Sp
  The default is \fB\-ffp\-int\-builtin\-inexact\fR, allowing the
  exception to be raised, unless C2X or a later C standard is selected.
  This option does nothing unless \fB\-ftrapping\-math\fR is in effect.
  .Sp
  Even if \fB\-fno\-fp\-int\-builtin\-inexact\fR is used, if the functions
! generate a call to a library function then the \*(L"inexact\*(R" exception
! may be raised if the library implementation does not follow \s-1TS 18661.\s0
! .IP "\fB\-fsingle\-precision\-constant\fR" 4
  .IX Item "-fsingle-precision-constant"
! Treat floating-point constants as single precision instead of
! implicitly converting them to double-precision constants.
! .IP "\fB\-fcx\-limited\-range\fR" 4
  .IX Item "-fcx-limited-range"
  When enabled, this option states that a range reduction step is not
  needed when performing complex division.  Also, there is no checking
--- 13450,13478 ----
  The default is \fB\-fno\-signaling\-nans\fR.
  .Sp
  This option is experimental and does not currently guarantee to
! disable all GCC optimizations that affect signaling NaN behavior.
! .IP \fB\-fno\-fp\-int\-builtin\-inexact\fR 4
  .IX Item "-fno-fp-int-builtin-inexact"
! Do not allow the built\-in functions \f(CW\*(C`ceil\*(C'\fR, \f(CW\*(C`floor\*(C'\fR,
  \&\f(CW\*(C`round\*(C'\fR and \f(CW\*(C`trunc\*(C'\fR, and their \f(CW\*(C`float\*(C'\fR and \f(CW\*(C`long
! double\*(C'\fR variants, to generate code that raises the "inexact"
! floating\-point exception for noninteger arguments.  ISO C99 and C11
! allow these functions to raise the "inexact" exception, but ISO/IEC
! TS 18661\-1:2014, the C bindings to IEEE 754\-2008, as integrated into
! ISO C2X, does not allow these functions to do so.
  .Sp
  The default is \fB\-ffp\-int\-builtin\-inexact\fR, allowing the
  exception to be raised, unless C2X or a later C standard is selected.
  This option does nothing unless \fB\-ftrapping\-math\fR is in effect.
  .Sp
  Even if \fB\-fno\-fp\-int\-builtin\-inexact\fR is used, if the functions
! generate a call to a library function then the "inexact" exception
! may be raised if the library implementation does not follow TS 18661.
! .IP \fB\-fsingle\-precision\-constant\fR 4
  .IX Item "-fsingle-precision-constant"
! Treat floating\-point constants as single precision instead of
! implicitly converting them to double\-precision constants.
! .IP \fB\-fcx\-limited\-range\fR 4
  .IX Item "-fcx-limited-range"
  When enabled, this option states that a range reduction step is not
  needed when performing complex division.  Also, there is no checking
*************** whether the result of a complex multipli
*** 13552,13561 ****
  default is \fB\-fno\-cx\-limited\-range\fR, but is enabled by
  \&\fB\-ffast\-math\fR.
  .Sp
! This option controls the default setting of the \s-1ISO C99\s0
  \&\f(CW\*(C`CX_LIMITED_RANGE\*(C'\fR pragma.  Nevertheless, the option applies to
  all languages.
! .IP "\fB\-fcx\-fortran\-rules\fR" 4
  .IX Item "-fcx-fortran-rules"
  Complex multiplication and division follow Fortran rules.  Range
  reduction is done as part of complex division, but there is no checking
--- 13481,13490 ----
  default is \fB\-fno\-cx\-limited\-range\fR, but is enabled by
  \&\fB\-ffast\-math\fR.
  .Sp
! This option controls the default setting of the ISO C99
  \&\f(CW\*(C`CX_LIMITED_RANGE\*(C'\fR pragma.  Nevertheless, the option applies to
  all languages.
! .IP \fB\-fcx\-fortran\-rules\fR 4
  .IX Item "-fcx-fortran-rules"
  Complex multiplication and division follow Fortran rules.  Range
  reduction is done as part of complex division, but there is no checking
*************** The default is \fB\-fno\-cx\-fortran\-ru
*** 13567,13594 ****
  The following options control optimizations that may improve
  performance, but are not enabled by any \fB\-O\fR options.  This
  section includes experimental options that may produce broken code.
! .IP "\fB\-fbranch\-probabilities\fR" 4
  .IX Item "-fbranch-probabilities"
  After running a program compiled with \fB\-fprofile\-arcs\fR,
  you can compile it a second time using
  \&\fB\-fbranch\-probabilities\fR, to improve optimizations based on
  the number of times each branch was taken.  When a program
  compiled with \fB\-fprofile\-arcs\fR exits, it saves arc execution
! counts to a file called \fI\fIsourcename\fI.gcda\fR for each source
  file.  The information in this data file is very dependent on the
  structure of the generated code, so you must use the same source code
  and the same optimization options for both compilations.
  See details about the file naming in \fB\-fprofile\-arcs\fR.
  .Sp
! With \fB\-fbranch\-probabilities\fR, \s-1GCC\s0 puts a
! \&\fB\s-1REG_BR_PROB\s0\fR note on each \fB\s-1JUMP_INSN\s0\fR and \fB\s-1CALL_INSN\s0\fR.
  These can be used to improve optimization.  Currently, they are only
  used in one place: in \fIreorg.cc\fR, instead of guessing which path a
! branch is most likely to take, the \fB\s-1REG_BR_PROB\s0\fR values are used to
  exactly determine which path is taken more often.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-fprofile\-values\fR" 4
  .IX Item "-fprofile-values"
  If combined with \fB\-fprofile\-arcs\fR, it adds code so that some
  data about values of expressions in the program is gathered.
--- 13496,13523 ----
  The following options control optimizations that may improve
  performance, but are not enabled by any \fB\-O\fR options.  This
  section includes experimental options that may produce broken code.
! .IP \fB\-fbranch\-probabilities\fR 4
  .IX Item "-fbranch-probabilities"
  After running a program compiled with \fB\-fprofile\-arcs\fR,
  you can compile it a second time using
  \&\fB\-fbranch\-probabilities\fR, to improve optimizations based on
  the number of times each branch was taken.  When a program
  compiled with \fB\-fprofile\-arcs\fR exits, it saves arc execution
! counts to a file called \fIsourcename.gcda\fR for each source
  file.  The information in this data file is very dependent on the
  structure of the generated code, so you must use the same source code
  and the same optimization options for both compilations.
  See details about the file naming in \fB\-fprofile\-arcs\fR.
  .Sp
! With \fB\-fbranch\-probabilities\fR, GCC puts a
! \&\fBREG_BR_PROB\fR note on each \fBJUMP_INSN\fR and \fBCALL_INSN\fR.
  These can be used to improve optimization.  Currently, they are only
  used in one place: in \fIreorg.cc\fR, instead of guessing which path a
! branch is most likely to take, the \fBREG_BR_PROB\fR values are used to
  exactly determine which path is taken more often.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-fprofile\-values\fR 4
  .IX Item "-fprofile-values"
  If combined with \fB\-fprofile\-arcs\fR, it adds code so that some
  data about values of expressions in the program is gathered.
*************** from profiling values of expressions for
*** 13598,13611 ****
  .Sp
  Enabled by \fB\-fprofile\-generate\fR, \fB\-fprofile\-use\fR, and
  \&\fB\-fauto\-profile\fR.
! .IP "\fB\-fprofile\-reorder\-functions\fR" 4
  .IX Item "-fprofile-reorder-functions"
  Function reordering based on profile instrumentation collects
  first time of execution of a function and orders these functions
  in ascending order.
  .Sp
  Enabled with \fB\-fprofile\-use\fR.
! .IP "\fB\-fvpt\fR" 4
  .IX Item "-fvpt"
  If combined with \fB\-fprofile\-arcs\fR, this option instructs the compiler
  to add code to gather information about values of expressions.
--- 13527,13540 ----
  .Sp
  Enabled by \fB\-fprofile\-generate\fR, \fB\-fprofile\-use\fR, and
  \&\fB\-fauto\-profile\fR.
! .IP \fB\-fprofile\-reorder\-functions\fR 4
  .IX Item "-fprofile-reorder-functions"
  Function reordering based on profile instrumentation collects
  first time of execution of a function and orders these functions
  in ascending order.
  .Sp
  Enabled with \fB\-fprofile\-use\fR.
! .IP \fB\-fvpt\fR 4
  .IX Item "-fvpt"
  If combined with \fB\-fprofile\-arcs\fR, this option instructs the compiler
  to add code to gather information about values of expressions.
*************** Currently the optimizations include spec
*** 13616,13646 ****
  using the knowledge about the value of the denominator.
  .Sp
  Enabled with \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-frename\-registers\fR" 4
  .IX Item "-frename-registers"
  Attempt to avoid false dependencies in scheduled code by making use
  of registers left over after register allocation.  This optimization
  most benefits processors with lots of registers.  Depending on the
  debug information format adopted by the target, however, it can
  make debugging impossible, since variables no longer stay in
! a \*(L"home register\*(R".
  .Sp
  Enabled by default with \fB\-funroll\-loops\fR.
! .IP "\fB\-fschedule\-fusion\fR" 4
  .IX Item "-fschedule-fusion"
  Performs a target dependent pass over the instruction stream to schedule
  instructions of same type together because target machine can execute them
  more efficiently if they are adjacent to each other in the instruction flow.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-ftracer\fR" 4
  .IX Item "-ftracer"
  Perform tail duplication to enlarge superblock size.  This transformation
  simplifies the control flow of the function allowing other optimizations to do
  a better job.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-funroll\-loops\fR" 4
  .IX Item "-funroll-loops"
  Unroll loops whose number of iterations can be determined at compile time or
  upon entry to the loop.  \fB\-funroll\-loops\fR implies
--- 13545,13575 ----
  using the knowledge about the value of the denominator.
  .Sp
  Enabled with \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-frename\-registers\fR 4
  .IX Item "-frename-registers"
  Attempt to avoid false dependencies in scheduled code by making use
  of registers left over after register allocation.  This optimization
  most benefits processors with lots of registers.  Depending on the
  debug information format adopted by the target, however, it can
  make debugging impossible, since variables no longer stay in
! a "home register".
  .Sp
  Enabled by default with \fB\-funroll\-loops\fR.
! .IP \fB\-fschedule\-fusion\fR 4
  .IX Item "-fschedule-fusion"
  Performs a target dependent pass over the instruction stream to schedule
  instructions of same type together because target machine can execute them
  more efficiently if they are adjacent to each other in the instruction flow.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-ftracer\fR 4
  .IX Item "-ftracer"
  Perform tail duplication to enlarge superblock size.  This transformation
  simplifies the control flow of the function allowing other optimizations to do
  a better job.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-funroll\-loops\fR 4
  .IX Item "-funroll-loops"
  Unroll loops whose number of iterations can be determined at compile time or
  upon entry to the loop.  \fB\-funroll\-loops\fR implies
*************** a small constant number of iterations).
*** 13650,13662 ****
  or may not make it run faster.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-funroll\-all\-loops\fR" 4
  .IX Item "-funroll-all-loops"
  Unroll all loops, even if their number of iterations is uncertain when
  the loop is entered.  This usually makes programs run more slowly.
  \&\fB\-funroll\-all\-loops\fR implies the same options as
  \&\fB\-funroll\-loops\fR.
! .IP "\fB\-fpeel\-loops\fR" 4
  .IX Item "-fpeel-loops"
  Peels loops for which there is enough information that they do not
  roll much (from profile feedback or static analysis).  It also turns on
--- 13579,13591 ----
  or may not make it run faster.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-funroll\-all\-loops\fR 4
  .IX Item "-funroll-all-loops"
  Unroll all loops, even if their number of iterations is uncertain when
  the loop is entered.  This usually makes programs run more slowly.
  \&\fB\-funroll\-all\-loops\fR implies the same options as
  \&\fB\-funroll\-loops\fR.
! .IP \fB\-fpeel\-loops\fR 4
  .IX Item "-fpeel-loops"
  Peels loops for which there is enough information that they do not
  roll much (from profile feedback or static analysis).  It also turns on
*************** complete loop peeling (i.e. complete rem
*** 13664,13694 ****
  number of iterations).
  .Sp
  Enabled by \fB\-O3\fR, \fB\-fprofile\-use\fR, and \fB\-fauto\-profile\fR.
! .IP "\fB\-fmove\-loop\-invariants\fR" 4
  .IX Item "-fmove-loop-invariants"
! Enables the loop invariant motion pass in the \s-1RTL\s0 loop optimizer.  Enabled
  at level \fB\-O1\fR and higher, except for \fB\-Og\fR.
! .IP "\fB\-fmove\-loop\-stores\fR" 4
  .IX Item "-fmove-loop-stores"
! Enables the loop store motion pass in the \s-1GIMPLE\s0 loop optimizer.  This
  moves invariant stores to after the end of the loop in exchange for
  carrying the stored value in a register across the iteration.
  Note for this option to have an effect \fB\-ftree\-loop\-im\fR has to
  be enabled as well.  Enabled at level \fB\-O1\fR and higher, except
  for \fB\-Og\fR.
! .IP "\fB\-fsplit\-loops\fR" 4
  .IX Item "-fsplit-loops"
! Split a loop into two if it contains a condition that's always true
  for one side of the iteration space and false for the other.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-funswitch\-loops\fR" 4
  .IX Item "-funswitch-loops"
  Move branches with loop invariant conditions out of the loop, with duplicates
  of the loop on both branches (modified according to result of the condition).
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-fversion\-loops\-for\-strides\fR" 4
  .IX Item "-fversion-loops-for-strides"
  If a loop iterates over an array with a variable stride, create another
  version of the loop that assumes the stride is always one.  For example:
--- 13593,13623 ----
  number of iterations).
  .Sp
  Enabled by \fB\-O3\fR, \fB\-fprofile\-use\fR, and \fB\-fauto\-profile\fR.
! .IP \fB\-fmove\-loop\-invariants\fR 4
  .IX Item "-fmove-loop-invariants"
! Enables the loop invariant motion pass in the RTL loop optimizer.  Enabled
  at level \fB\-O1\fR and higher, except for \fB\-Og\fR.
! .IP \fB\-fmove\-loop\-stores\fR 4
  .IX Item "-fmove-loop-stores"
! Enables the loop store motion pass in the GIMPLE loop optimizer.  This
  moves invariant stores to after the end of the loop in exchange for
  carrying the stored value in a register across the iteration.
  Note for this option to have an effect \fB\-ftree\-loop\-im\fR has to
  be enabled as well.  Enabled at level \fB\-O1\fR and higher, except
  for \fB\-Og\fR.
! .IP \fB\-fsplit\-loops\fR 4
  .IX Item "-fsplit-loops"
! Split a loop into two if it contains a condition that\*(Aqs always true
  for one side of the iteration space and false for the other.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-funswitch\-loops\fR 4
  .IX Item "-funswitch-loops"
  Move branches with loop invariant conditions out of the loop, with duplicates
  of the loop on both branches (modified according to result of the condition).
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-fversion\-loops\-for\-strides\fR 4
  .IX Item "-fversion-loops-for-strides"
  If a loop iterates over an array with a variable stride, create another
  version of the loop that assumes the stride is always one.  For example:
*************** becomes:
*** 13709,13740 ****
  \&            x[i * stride] = ...;
  .Ve
  .Sp
! This is particularly useful for assumed-shape arrays in Fortran where
  (for example) it allows better vectorization assuming contiguous accesses.
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-ffunction\-sections\fR" 4
  .IX Item "-ffunction-sections"
  .PD 0
! .IP "\fB\-fdata\-sections\fR" 4
  .IX Item "-fdata-sections"
  .PD
  Place each function or data item into its own section in the output
  file if the target supports arbitrary sections.  The name of the
! function or the name of the data item determines the section's name
  in the output file.
  .Sp
  Use these options on systems where the linker can perform optimizations to
  improve locality of reference in the instruction space.  Most systems using the
! \&\s-1ELF\s0 object format have linkers with such optimizations.  On \s-1AIX,\s0 the linker
  rearranges sections (CSECTs) based on the call graph.  The performance impact
  varies.
  .Sp
  Together with a linker garbage collection (linker \fB\-\-gc\-sections\fR
! option) these options may lead to smaller statically-linked executables (after
  stripping).
  .Sp
! On \s-1ELF/DWARF\s0 systems these options do not degenerate the quality of the debug
  information.  There could be issues with other object files/debug info formats.
  .Sp
  Only use these options when there are significant benefits from doing so.  When
--- 13638,13669 ----
  \&            x[i * stride] = ...;
  .Ve
  .Sp
! This is particularly useful for assumed\-shape arrays in Fortran where
  (for example) it allows better vectorization assuming contiguous accesses.
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-ffunction\-sections\fR 4
  .IX Item "-ffunction-sections"
  .PD 0
! .IP \fB\-fdata\-sections\fR 4
  .IX Item "-fdata-sections"
  .PD
  Place each function or data item into its own section in the output
  file if the target supports arbitrary sections.  The name of the
! function or the name of the data item determines the section\*(Aqs name
  in the output file.
  .Sp
  Use these options on systems where the linker can perform optimizations to
  improve locality of reference in the instruction space.  Most systems using the
! ELF object format have linkers with such optimizations.  On AIX, the linker
  rearranges sections (CSECTs) based on the call graph.  The performance impact
  varies.
  .Sp
  Together with a linker garbage collection (linker \fB\-\-gc\-sections\fR
! option) these options may lead to smaller statically\-linked executables (after
  stripping).
  .Sp
! On ELF/DWARF systems these options do not degenerate the quality of the debug
  information.  There could be issues with other object files/debug info formats.
  .Sp
  Only use these options when there are significant benefits from doing so.  When
*************** They prevent optimizations by the compil
*** 13744,13758 ****
  locations inside a translation unit since the locations are unknown until
  link time.  An example of such an optimization is relaxing calls to short call
  instructions.
! .IP "\fB\-fstdarg\-opt\fR" 4
  .IX Item "-fstdarg-opt"
  Optimize the prologue of variadic argument functions with respect to usage of
  those arguments.
! .IP "\fB\-fsection\-anchors\fR" 4
  .IX Item "-fsection-anchors"
  Try to reduce the number of symbolic address calculations by using
! shared \*(L"anchor\*(R" symbols to address nearby objects.  This transformation
! can help to reduce the number of \s-1GOT\s0 entries and \s-1GOT\s0 accesses on some
  targets.
  .Sp
  For example, the implementation of the following function \f(CW\*(C`foo\*(C'\fR:
--- 13673,13687 ----
  locations inside a translation unit since the locations are unknown until
  link time.  An example of such an optimization is relaxing calls to short call
  instructions.
! .IP \fB\-fstdarg\-opt\fR 4
  .IX Item "-fstdarg-opt"
  Optimize the prologue of variadic argument functions with respect to usage of
  those arguments.
! .IP \fB\-fsection\-anchors\fR 4
  .IX Item "-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.
  .Sp
  For example, the implementation of the following function \f(CW\*(C`foo\*(C'\fR:
*************** For example, the implementation of the f
*** 13765,13771 ****
  usually calculates the addresses of all three variables, but if you
  compile it with \fB\-fsection\-anchors\fR, it accesses the variables
  from a common anchor point instead.  The effect is similar to the
! following pseudocode (which isn't valid C):
  .Sp
  .Vb 5
  \&        int foo (void)
--- 13694,13700 ----
  usually calculates the addresses of all three variables, but if you
  compile it with \fB\-fsection\-anchors\fR, it accesses the variables
  from a common anchor point instead.  The effect is similar to the
! following pseudocode (which isn\*(Aqt valid C):
  .Sp
  .Vb 5
  \&        int foo (void)
*************** following pseudocode (which isn't valid
*** 13776,13785 ****
  .Ve
  .Sp
  Not all targets support this option.
! .IP "\fB\-fzero\-call\-used\-regs=\fR\fIchoice\fR" 4
  .IX Item "-fzero-call-used-regs=choice"
! Zero call-used registers at function return to increase program
! security by either mitigating Return-Oriented Programming (\s-1ROP\s0)
  attacks or preventing information leakage through registers.
  .Sp
  The possible values of \fIchoice\fR are the same as for the
--- 13705,13714 ----
  .Ve
  .Sp
  Not all targets support this option.
! .IP \fB\-fzero\-call\-used\-regs=\fR\fIchoice\fR 4
  .IX Item "-fzero-call-used-regs=choice"
! Zero call\-used registers at function return to increase program
! security by either mitigating Return\-Oriented Programming (ROP)
  attacks or preventing information leakage through registers.
  .Sp
  The possible values of \fIchoice\fR are the same as for the
*************** You can control this behavior for a spec
*** 13790,13797 ****
  attribute \f(CW\*(C`zero_call_used_regs\*(C'\fR.
  .IP "\fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR" 4
  .IX Item "--param name=value"
! In some places, \s-1GCC\s0 uses various constants to control the amount of
! optimization that is done.  For example, \s-1GCC\s0 does not inline functions
  that contain more than a certain number of instructions.  You can
  control some of these constants on the command line using the
  \&\fB\-\-param\fR option.
--- 13719,13726 ----
  attribute \f(CW\*(C`zero_call_used_regs\*(C'\fR.
  .IP "\fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR" 4
  .IX Item "--param name=value"
! In some places, GCC uses various constants to control the amount of
! optimization that is done.  For example, GCC does not inline functions
  that contain more than a certain number of instructions.  You can
  control some of these constants on the command line using the
  \&\fB\-\-param\fR option.
*************** use the \fB\-\-help=param \-Q\fR options
*** 13806,13859 ****
  In each case, the \fIvalue\fR is an integer.  The following choices
  of \fIname\fR are recognized for all targets:
  .RS 4
! .IP "\fBpredictable-branch-outcome\fR" 4
  .IX Item "predictable-branch-outcome"
  When branch is predicted to be taken with probability lower than this threshold
  (in percent), then it is considered well predictable.
! .IP "\fBmax-rtl-if-conversion-insns\fR" 4
  .IX Item "max-rtl-if-conversion-insns"
! \&\s-1RTL\s0 if-conversion tries to remove conditional branches around a block and
  replace them with conditionally executed instructions.  This parameter
  gives the maximum number of instructions in a block which should be
! considered for if-conversion.  The compiler will
! also use other heuristics to decide whether if-conversion is likely to be
  profitable.
! .IP "\fBmax-rtl-if-conversion-predictable-cost\fR" 4
  .IX Item "max-rtl-if-conversion-predictable-cost"
! \&\s-1RTL\s0 if-conversion will try to remove conditional branches around a block
  and replace them with conditionally executed instructions.  These parameters
  give the maximum permissible cost for the sequence that would be generated
! by if-conversion depending on whether the branch is statically determined
  to be predictable or not.  The units for this parameter are the same as
! those for the \s-1GCC\s0 internal seq_cost metric.  The compiler will try to
! provide a reasonable default for this parameter using the \s-1BRANCH_COST\s0
  target macro.
! .IP "\fBmax-crossjump-edges\fR" 4
  .IX Item "max-crossjump-edges"
! The maximum number of incoming edges to consider for cross-jumping.
  The algorithm used by \fB\-fcrossjumping\fR is O(N^2) in
  the number of edges incoming to each block.  Increasing values mean
  more aggressive optimization, making the compilation time increase with
  probably small improvement in executable size.
! .IP "\fBmin-crossjump-insns\fR" 4
  .IX Item "min-crossjump-insns"
  The minimum number of instructions that must be matched at the end
! of two blocks before cross-jumping is performed on them.  This
  value is ignored in the case where all instructions in the block being
! cross-jumped from are matched.
! .IP "\fBmax-grow-copy-bb-insns\fR" 4
  .IX Item "max-grow-copy-bb-insns"
  The maximum code size expansion factor when copying basic blocks
  instead of jumping.  The expansion is relative to a jump instruction.
! .IP "\fBmax-goto-duplication-insns\fR" 4
  .IX Item "max-goto-duplication-insns"
  The maximum number of instructions to duplicate to a block that jumps
  to a computed goto.  To avoid O(N^2) behavior in a number of
! passes, \s-1GCC\s0 factors computed gotos early in the compilation process,
  and unfactors them as late as possible.  Only computed jumps at the
! end of a basic blocks with no more than max-goto-duplication-insns are
  unfactored.
! .IP "\fBmax-delay-slot-insn-search\fR" 4
  .IX Item "max-delay-slot-insn-search"
  The maximum number of instructions to consider when looking for an
  instruction to fill a delay slot.  If more than this arbitrary number of
--- 13735,13788 ----
  In each case, the \fIvalue\fR is an integer.  The following choices
  of \fIname\fR are recognized for all targets:
  .RS 4
! .IP \fBpredictable\-branch\-outcome\fR 4
  .IX Item "predictable-branch-outcome"
  When branch is predicted to be taken with probability lower than this threshold
  (in percent), then it is considered well predictable.
! .IP \fBmax\-rtl\-if\-conversion\-insns\fR 4
  .IX Item "max-rtl-if-conversion-insns"
! RTL if\-conversion tries to remove conditional branches around a block and
  replace them with conditionally executed instructions.  This parameter
  gives the maximum number of instructions in a block which should be
! considered for if\-conversion.  The compiler will
! also use other heuristics to decide whether if\-conversion is likely to be
  profitable.
! .IP \fBmax\-rtl\-if\-conversion\-predictable\-cost\fR 4
  .IX Item "max-rtl-if-conversion-predictable-cost"
! RTL if\-conversion will try to remove conditional branches around a block
  and replace them with conditionally executed instructions.  These parameters
  give the maximum permissible cost for the sequence that would be generated
! by if\-conversion depending on whether the branch is statically determined
  to be predictable or not.  The units for this parameter are the same as
! those for the GCC internal seq_cost metric.  The compiler will try to
! provide a reasonable default for this parameter using the BRANCH_COST
  target macro.
! .IP \fBmax\-crossjump\-edges\fR 4
  .IX Item "max-crossjump-edges"
! The maximum number of incoming edges to consider for cross\-jumping.
  The algorithm used by \fB\-fcrossjumping\fR is O(N^2) in
  the number of edges incoming to each block.  Increasing values mean
  more aggressive optimization, making the compilation time increase with
  probably small improvement in executable size.
! .IP \fBmin\-crossjump\-insns\fR 4
  .IX Item "min-crossjump-insns"
  The minimum number of instructions that must be matched at the end
! of two blocks before cross\-jumping is performed on them.  This
  value is ignored in the case where all instructions in the block being
! cross\-jumped from are matched.
! .IP \fBmax\-grow\-copy\-bb\-insns\fR 4
  .IX Item "max-grow-copy-bb-insns"
  The maximum code size expansion factor when copying basic blocks
  instead of jumping.  The expansion is relative to a jump instruction.
! .IP \fBmax\-goto\-duplication\-insns\fR 4
  .IX Item "max-goto-duplication-insns"
  The maximum number of instructions to duplicate to a block that jumps
  to a computed goto.  To avoid O(N^2) behavior in a number of
! passes, 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.
! .IP \fBmax\-delay\-slot\-insn\-search\fR 4
  .IX Item "max-delay-slot-insn-search"
  The maximum number of instructions to consider when looking for an
  instruction to fill a delay slot.  If more than this arbitrary number of
*************** instructions are searched, the time savi
*** 13861,14032 ****
  are minimal, so stop searching.  Increasing values mean more
  aggressive optimization, making the compilation time increase with probably
  small improvement in execution time.
! .IP "\fBmax-delay-slot-live-search\fR" 4
  .IX Item "max-delay-slot-live-search"
  When trying to fill delay slots, the maximum number of instructions to
  consider when searching for a block with valid live register
  information.  Increasing this arbitrarily chosen value means more
  aggressive optimization, increasing the compilation time.  This parameter
  should be removed when the delay slot code is rewritten to maintain the
! control-flow graph.
! .IP "\fBmax-gcse-memory\fR" 4
  .IX Item "max-gcse-memory"
  The approximate maximum amount of memory in \f(CW\*(C`kB\*(C'\fR that can be allocated in
  order to perform the global common subexpression elimination
  optimization.  If more memory than specified is required, the
  optimization is not done.
! .IP "\fBmax-gcse-insertion-ratio\fR" 4
  .IX Item "max-gcse-insertion-ratio"
  If the ratio of expression insertions to deletions is larger than this value
! for any expression, then \s-1RTL PRE\s0 inserts or removes the expression and thus
  leaves partially redundant computations in the instruction stream.
! .IP "\fBmax-pending-list-length\fR" 4
  .IX Item "max-pending-list-length"
  The maximum number of pending dependencies scheduling allows
  before flushing the current state and starting over.  Large functions
  with few branches or calls can create excessively large lists which
  needlessly consume memory and resources.
! .IP "\fBmax-modulo-backtrack-attempts\fR" 4
  .IX Item "max-modulo-backtrack-attempts"
  The maximum number of backtrack attempts the scheduler should make
  when modulo scheduling a loop.  Larger values can exponentially increase
  compilation time.
! .IP "\fBmax-inline-functions-called-once-loop-depth\fR" 4
  .IX Item "max-inline-functions-called-once-loop-depth"
  Maximal loop depth of a call considered by inline heuristics that tries to
  inline all functions called once.
! .IP "\fBmax-inline-functions-called-once-insns\fR" 4
  .IX Item "max-inline-functions-called-once-insns"
  Maximal estimated size of functions produced while inlining functions called
  once.
! .IP "\fBmax-inline-insns-single\fR" 4
  .IX Item "max-inline-insns-single"
! Several parameters control the tree inliner used in \s-1GCC.\s0  This number sets the
! maximum number of instructions (counted in \s-1GCC\s0's internal representation) in a
  single function that the tree inliner considers for inlining.  This only
  affects functions declared inline and methods implemented in a class
! declaration (\*(C+).
! .IP "\fBmax-inline-insns-auto\fR" 4
  .IX Item "max-inline-insns-auto"
  When you use \fB\-finline\-functions\fR (included in \fB\-O3\fR),
  a lot of functions that would otherwise not be considered for inlining
  by the compiler are investigated.  To those functions, a different
  (more restrictive) limit compared to functions declared inline can
! be applied (\fB\-\-param max-inline-insns-auto\fR).
! .IP "\fBmax-inline-insns-small\fR" 4
  .IX Item "max-inline-insns-small"
  This is bound applied to calls which are considered relevant with
  \&\fB\-finline\-small\-functions\fR.
! .IP "\fBmax-inline-insns-size\fR" 4
  .IX Item "max-inline-insns-size"
  This is bound applied to calls which are optimized for size. Small growth
  may be desirable to anticipate optimization oppurtunities exposed by inlining.
! .IP "\fBuninlined-function-insns\fR" 4
  .IX Item "uninlined-function-insns"
  Number of instructions accounted by inliner for function overhead such as
  function prologue and epilogue.
! .IP "\fBuninlined-function-time\fR" 4
  .IX Item "uninlined-function-time"
  Extra time accounted by inliner for function overhead such as time needed to
  execute function prologue and epilogue.
! .IP "\fBinline-heuristics-hint-percent\fR" 4
  .IX Item "inline-heuristics-hint-percent"
! The scale (in percents) applied to \fBinline-insns-single\fR,
! \&\fBinline\-insns\-single\-O2\fR, \fBinline-insns-auto\fR
  when inline heuristics hints that inlining is
  very profitable (will enable later optimizations).
! .IP "\fBuninlined-thunk-insns\fR" 4
  .IX Item "uninlined-thunk-insns"
  .PD 0
! .IP "\fBuninlined-thunk-time\fR" 4
  .IX Item "uninlined-thunk-time"
  .PD
! Same as \fB\-\-param uninlined-function-insns\fR and
! \&\fB\-\-param uninlined-function-time\fR but applied to function thunks.
! .IP "\fBinline-min-speedup\fR" 4
  .IX Item "inline-min-speedup"
  When estimated performance improvement of caller + callee runtime exceeds this
  threshold (in percent), the function can be inlined regardless of the limit on
! \&\fB\-\-param max-inline-insns-single\fR and \fB\-\-param
! max-inline-insns-auto\fR.
! .IP "\fBlarge-function-insns\fR" 4
  .IX Item "large-function-insns"
  The limit specifying really large functions.  For functions larger than this
  limit after inlining, inlining is constrained by
! \&\fB\-\-param large-function-growth\fR.  This parameter is useful primarily
! to avoid extreme compilation time caused by non-linear algorithms used by the
  back end.
! .IP "\fBlarge-function-growth\fR" 4
  .IX Item "large-function-growth"
  Specifies maximal growth of large function caused by inlining in percents.
  For example, parameter value 100 limits large function growth to 2.0 times
  the original size.
! .IP "\fBlarge-unit-insns\fR" 4
  .IX Item "large-unit-insns"
  The limit specifying large translation unit.  Growth caused by inlining of
! units larger than this limit is limited by \fB\-\-param inline-unit-growth\fR.
  For small units this might be too tight.
  For example, consider a unit consisting of function A
  that is inline and B that just calls A three times.  If B is small relative to
  A, the growth of unit is 300\e% and yet such inlining is very sane.  For very
  large units consisting of small inlineable functions, however, the overall unit
  growth limit is needed to avoid exponential explosion of code size.  Thus for
! smaller units, the size is increased to \fB\-\-param large-unit-insns\fR
! before applying \fB\-\-param inline-unit-growth\fR.
! .IP "\fBlazy-modules\fR" 4
  .IX Item "lazy-modules"
! Maximum number of concurrently open \*(C+ module files when lazy loading.
! .IP "\fBinline-unit-growth\fR" 4
  .IX Item "inline-unit-growth"
  Specifies maximal overall growth of the compilation unit caused by inlining.
  For example, parameter value 20 limits unit growth to 1.2 times the original
  size. Cold functions (either marked cold via an attribute or by profile
  feedback) are not accounted into the unit size.
! .IP "\fBipa-cp-unit-growth\fR" 4
  .IX Item "ipa-cp-unit-growth"
  Specifies maximal overall growth of the compilation unit caused by
  interprocedural constant propagation.  For example, parameter value 10 limits
  unit growth to 1.1 times the original size.
! .IP "\fBipa-cp-large-unit-insns\fR" 4
  .IX Item "ipa-cp-large-unit-insns"
! The size of translation unit that IPA-CP pass considers large.
! .IP "\fBlarge-stack-frame\fR" 4
  .IX Item "large-stack-frame"
  The limit specifying large stack frames.  While inlining the algorithm is trying
  to not grow past this limit too much.
! .IP "\fBlarge-stack-frame-growth\fR" 4
  .IX Item "large-stack-frame-growth"
  Specifies maximal growth of large stack frames caused by inlining in percents.
  For example, parameter value 1000 limits large stack frame growth to 11 times
  the original size.
! .IP "\fBmax-inline-insns-recursive\fR" 4
  .IX Item "max-inline-insns-recursive"
  .PD 0
! .IP "\fBmax-inline-insns-recursive-auto\fR" 4
  .IX Item "max-inline-insns-recursive-auto"
  .PD
! Specifies the maximum number of instructions an out-of-line copy of a
! self-recursive inline
  function can grow into by performing recursive inlining.
  .Sp
! \&\fB\-\-param max-inline-insns-recursive\fR applies to functions
  declared inline.
  For functions not declared inline, recursive inlining
  happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
! enabled; \fB\-\-param max-inline-insns-recursive-auto\fR applies instead.
! .IP "\fBmax-inline-recursive-depth\fR" 4
  .IX Item "max-inline-recursive-depth"
  .PD 0
! .IP "\fBmax-inline-recursive-depth-auto\fR" 4
  .IX Item "max-inline-recursive-depth-auto"
  .PD
  Specifies the maximum recursion depth used for recursive inlining.
  .Sp
! \&\fB\-\-param max-inline-recursive-depth\fR applies to functions
  declared inline.  For functions not declared inline, recursive inlining
  happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
! enabled; \fB\-\-param max-inline-recursive-depth-auto\fR applies instead.
! .IP "\fBmin-inline-recursive-probability\fR" 4
  .IX Item "min-inline-recursive-probability"
  Recursive inlining is profitable only for function having deep recursion
  in average and can hurt for function having little recursion depth by
--- 13790,13961 ----
  are minimal, so stop searching.  Increasing values mean more
  aggressive optimization, making the compilation time increase with probably
  small improvement in execution time.
! .IP \fBmax\-delay\-slot\-live\-search\fR 4
  .IX Item "max-delay-slot-live-search"
  When trying to fill delay slots, the maximum number of instructions to
  consider when searching for a block with valid live register
  information.  Increasing this arbitrarily chosen value means more
  aggressive optimization, increasing the compilation time.  This parameter
  should be removed when the delay slot code is rewritten to maintain the
! control\-flow graph.
! .IP \fBmax\-gcse\-memory\fR 4
  .IX Item "max-gcse-memory"
  The approximate maximum amount of memory in \f(CW\*(C`kB\*(C'\fR that can be allocated in
  order to perform the global common subexpression elimination
  optimization.  If more memory than specified is required, the
  optimization is not done.
! .IP \fBmax\-gcse\-insertion\-ratio\fR 4
  .IX Item "max-gcse-insertion-ratio"
  If the ratio of expression insertions to deletions is larger than this value
! for any expression, then RTL PRE inserts or removes the expression and thus
  leaves partially redundant computations in the instruction stream.
! .IP \fBmax\-pending\-list\-length\fR 4
  .IX Item "max-pending-list-length"
  The maximum number of pending dependencies scheduling allows
  before flushing the current state and starting over.  Large functions
  with few branches or calls can create excessively large lists which
  needlessly consume memory and resources.
! .IP \fBmax\-modulo\-backtrack\-attempts\fR 4
  .IX Item "max-modulo-backtrack-attempts"
  The maximum number of backtrack attempts the scheduler should make
  when modulo scheduling a loop.  Larger values can exponentially increase
  compilation time.
! .IP \fBmax\-inline\-functions\-called\-once\-loop\-depth\fR 4
  .IX Item "max-inline-functions-called-once-loop-depth"
  Maximal loop depth of a call considered by inline heuristics that tries to
  inline all functions called once.
! .IP \fBmax\-inline\-functions\-called\-once\-insns\fR 4
  .IX Item "max-inline-functions-called-once-insns"
  Maximal estimated size of functions produced while inlining functions called
  once.
! .IP \fBmax\-inline\-insns\-single\fR 4
  .IX Item "max-inline-insns-single"
! Several parameters control the tree inliner used in GCC.  This number sets the
! maximum number of instructions (counted in GCC\*(Aqs internal representation) in a
  single function that the tree inliner considers for inlining.  This only
  affects functions declared inline and methods implemented in a class
! declaration (C++).
! .IP \fBmax\-inline\-insns\-auto\fR 4
  .IX Item "max-inline-insns-auto"
  When you use \fB\-finline\-functions\fR (included in \fB\-O3\fR),
  a lot of functions that would otherwise not be considered for inlining
  by the compiler are investigated.  To those functions, a different
  (more restrictive) limit compared to functions declared inline can
! be applied (\fB\-\-param max\-inline\-insns\-auto\fR).
! .IP \fBmax\-inline\-insns\-small\fR 4
  .IX Item "max-inline-insns-small"
  This is bound applied to calls which are considered relevant with
  \&\fB\-finline\-small\-functions\fR.
! .IP \fBmax\-inline\-insns\-size\fR 4
  .IX Item "max-inline-insns-size"
  This is bound applied to calls which are optimized for size. Small growth
  may be desirable to anticipate optimization oppurtunities exposed by inlining.
! .IP \fBuninlined\-function\-insns\fR 4
  .IX Item "uninlined-function-insns"
  Number of instructions accounted by inliner for function overhead such as
  function prologue and epilogue.
! .IP \fBuninlined\-function\-time\fR 4
  .IX Item "uninlined-function-time"
  Extra time accounted by inliner for function overhead such as time needed to
  execute function prologue and epilogue.
! .IP \fBinline\-heuristics\-hint\-percent\fR 4
  .IX Item "inline-heuristics-hint-percent"
! The scale (in percents) applied to \fBinline\-insns\-single\fR,
! \&\fBinline\-insns\-single\-O2\fR, \fBinline\-insns\-auto\fR
  when inline heuristics hints that inlining is
  very profitable (will enable later optimizations).
! .IP \fBuninlined\-thunk\-insns\fR 4
  .IX Item "uninlined-thunk-insns"
  .PD 0
! .IP \fBuninlined\-thunk\-time\fR 4
  .IX Item "uninlined-thunk-time"
  .PD
! Same as \fB\-\-param uninlined\-function\-insns\fR and
! \&\fB\-\-param uninlined\-function\-time\fR but applied to function thunks.
! .IP \fBinline\-min\-speedup\fR 4
  .IX Item "inline-min-speedup"
  When estimated performance improvement of caller + callee runtime exceeds this
  threshold (in percent), the function can be inlined regardless of the limit on
! \&\fB\-\-param max\-inline\-insns\-single\fR and \fB\-\-param
! max\-inline\-insns\-auto\fR.
! .IP \fBlarge\-function\-insns\fR 4
  .IX Item "large-function-insns"
  The limit specifying really large functions.  For functions larger than this
  limit after inlining, inlining is constrained by
! \&\fB\-\-param large\-function\-growth\fR.  This parameter is useful primarily
! to avoid extreme compilation time caused by non\-linear algorithms used by the
  back end.
! .IP \fBlarge\-function\-growth\fR 4
  .IX Item "large-function-growth"
  Specifies maximal growth of large function caused by inlining in percents.
  For example, parameter value 100 limits large function growth to 2.0 times
  the original size.
! .IP \fBlarge\-unit\-insns\fR 4
  .IX Item "large-unit-insns"
  The limit specifying large translation unit.  Growth caused by inlining of
! units larger than this limit is limited by \fB\-\-param inline\-unit\-growth\fR.
  For small units this might be too tight.
  For example, consider a unit consisting of function A
  that is inline and B that just calls A three times.  If B is small relative to
  A, the growth of unit is 300\e% and yet such inlining is very sane.  For very
  large units consisting of small inlineable functions, however, the overall unit
  growth limit is needed to avoid exponential explosion of code size.  Thus for
! smaller units, the size is increased to \fB\-\-param large\-unit\-insns\fR
! before applying \fB\-\-param inline\-unit\-growth\fR.
! .IP \fBlazy\-modules\fR 4
  .IX Item "lazy-modules"
! Maximum number of concurrently open C++ module files when lazy loading.
! .IP \fBinline\-unit\-growth\fR 4
  .IX Item "inline-unit-growth"
  Specifies maximal overall growth of the compilation unit caused by inlining.
  For example, parameter value 20 limits unit growth to 1.2 times the original
  size. Cold functions (either marked cold via an attribute or by profile
  feedback) are not accounted into the unit size.
! .IP \fBipa\-cp\-unit\-growth\fR 4
  .IX Item "ipa-cp-unit-growth"
  Specifies maximal overall growth of the compilation unit caused by
  interprocedural constant propagation.  For example, parameter value 10 limits
  unit growth to 1.1 times the original size.
! .IP \fBipa\-cp\-large\-unit\-insns\fR 4
  .IX Item "ipa-cp-large-unit-insns"
! The size of translation unit that IPA\-CP pass considers large.
! .IP \fBlarge\-stack\-frame\fR 4
  .IX Item "large-stack-frame"
  The limit specifying large stack frames.  While inlining the algorithm is trying
  to not grow past this limit too much.
! .IP \fBlarge\-stack\-frame\-growth\fR 4
  .IX Item "large-stack-frame-growth"
  Specifies maximal growth of large stack frames caused by inlining in percents.
  For example, parameter value 1000 limits large stack frame growth to 11 times
  the original size.
! .IP \fBmax\-inline\-insns\-recursive\fR 4
  .IX Item "max-inline-insns-recursive"
  .PD 0
! .IP \fBmax\-inline\-insns\-recursive\-auto\fR 4
  .IX Item "max-inline-insns-recursive-auto"
  .PD
! Specifies the maximum number of instructions an out\-of\-line copy of a
! self\-recursive inline
  function can grow into by performing recursive inlining.
  .Sp
! \&\fB\-\-param max\-inline\-insns\-recursive\fR applies to functions
  declared inline.
  For functions not declared inline, recursive inlining
  happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
! enabled; \fB\-\-param max\-inline\-insns\-recursive\-auto\fR applies instead.
! .IP \fBmax\-inline\-recursive\-depth\fR 4
  .IX Item "max-inline-recursive-depth"
  .PD 0
! .IP \fBmax\-inline\-recursive\-depth\-auto\fR 4
  .IX Item "max-inline-recursive-depth-auto"
  .PD
  Specifies the maximum recursion depth used for recursive inlining.
  .Sp
! \&\fB\-\-param max\-inline\-recursive\-depth\fR applies to functions
  declared inline.  For functions not declared inline, recursive inlining
  happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
! enabled; \fB\-\-param max\-inline\-recursive\-depth\-auto\fR applies instead.
! .IP \fBmin\-inline\-recursive\-probability\fR 4
  .IX Item "min-inline-recursive-probability"
  Recursive inlining is profitable only for function having deep recursion
  in average and can hurt for function having little recursion depth by
*************** When profile feedback is available (see
*** 14037,14255 ****
  recursion depth can be guessed from the probability that function recurses
  via a given call expression.  This parameter limits inlining only to call
  expressions whose probability exceeds the given threshold (in percents).
! .IP "\fBearly-inlining-insns\fR" 4
  .IX Item "early-inlining-insns"
  Specify growth that the early inliner can make.  In effect it increases
  the amount of inlining for code having a large abstraction penalty.
! .IP "\fBmax-early-inliner-iterations\fR" 4
  .IX Item "max-early-inliner-iterations"
  Limit of iterations of the early inliner.  This basically bounds
  the number of nested indirect calls the early inliner can resolve.
  Deeper chains are still handled by late inlining.
! .IP "\fBcomdat-sharing-probability\fR" 4
  .IX Item "comdat-sharing-probability"
! Probability (in percent) that \*(C+ inline function with comdat visibility
  are shared across multiple compilation units.
! .IP "\fBmodref-max-bases\fR" 4
  .IX Item "modref-max-bases"
  .PD 0
! .IP "\fBmodref-max-refs\fR" 4
  .IX Item "modref-max-refs"
! .IP "\fBmodref-max-accesses\fR" 4
  .IX Item "modref-max-accesses"
  .PD
  Specifies the maximal number of base pointers, references and accesses stored
  for a single function by mod/ref analysis.
! .IP "\fBmodref-max-tests\fR" 4
  .IX Item "modref-max-tests"
  Specifies the maxmal number of tests alias oracle can perform to disambiguate
  memory locations using the mod/ref information.  This parameter ought to be
! bigger than \fB\-\-param modref-max-bases\fR and \fB\-\-param
! modref-max-refs\fR.
! .IP "\fBmodref-max-depth\fR" 4
  .IX Item "modref-max-depth"
! Specifies the maximum depth of \s-1DFS\s0 walk used by modref escape analysis.
  Setting to 0 disables the analysis completely.
! .IP "\fBmodref-max-escape-points\fR" 4
  .IX Item "modref-max-escape-points"
! Specifies the maximum number of escape points tracked by modref per SSA-name.
! .IP "\fBmodref-max-adjustments\fR" 4
  .IX Item "modref-max-adjustments"
  Specifies the maximum number the access range is enlarged during modref dataflow
  analysis.
! .IP "\fBprofile-func-internal-id\fR" 4
  .IX Item "profile-func-internal-id"
  A parameter to control whether to use function internal id in profile
  database lookup. If the value is 0, the compiler uses an id that
  is based on function assembler name and filename, which makes old profile
  data more tolerant to source changes such as function reordering etc.
! .IP "\fBmin-vect-loop-bound\fR" 4
  .IX Item "min-vect-loop-bound"
  The minimum number of iterations under which loops are not vectorized
  when \fB\-ftree\-vectorize\fR is used.  The number of iterations after
  vectorization needs to be greater than the value specified by this option
  to allow vectorization.
! .IP "\fBgcse-cost-distance-ratio\fR" 4
  .IX Item "gcse-cost-distance-ratio"
  Scaling factor in calculation of maximum distance an expression
! can be moved by \s-1GCSE\s0 optimizations.  This is currently supported only in the
  code hoisting pass.  The bigger the ratio, the more aggressive code hoisting
  is with simple expressions, i.e., the expressions that have cost
! less than \fBgcse-unrestricted-cost\fR.  Specifying 0 disables
  hoisting of simple expressions.
! .IP "\fBgcse-unrestricted-cost\fR" 4
  .IX Item "gcse-unrestricted-cost"
  Cost, roughly measured as the cost of a single typical machine
! instruction, at which \s-1GCSE\s0 optimizations do not constrain
  the distance an expression can travel.  This is currently
  supported only in the code hoisting pass.  The lesser the cost,
  the more aggressive code hoisting is.  Specifying 0 
  allows all expressions to travel unrestricted distances.
! .IP "\fBmax-hoist-depth\fR" 4
  .IX Item "max-hoist-depth"
  The depth of search in the dominator tree for expressions to hoist.
  This is used to avoid quadratic behavior in hoisting algorithm.
  The value of 0 does not limit on the search, but may slow down compilation
  of huge functions.
! .IP "\fBmax-tail-merge-comparisons\fR" 4
  .IX Item "max-tail-merge-comparisons"
  The maximum amount of similar bbs to compare a bb with.  This is used to
  avoid quadratic behavior in tree tail merging.
! .IP "\fBmax-tail-merge-iterations\fR" 4
  .IX Item "max-tail-merge-iterations"
  The maximum amount of iterations of the pass over the function.  This is used to
  limit compilation time in tree tail merging.
! .IP "\fBstore-merging-allow-unaligned\fR" 4
  .IX Item "store-merging-allow-unaligned"
  Allow the store merging pass to introduce unaligned stores if it is legal to
  do so.
! .IP "\fBmax-stores-to-merge\fR" 4
  .IX Item "max-stores-to-merge"
  The maximum number of stores to attempt to merge into wider stores in the store
  merging pass.
! .IP "\fBmax-store-chains-to-track\fR" 4
  .IX Item "max-store-chains-to-track"
  The maximum number of store chains to track at the same time in the attempt
  to merge them into wider stores in the store merging pass.
! .IP "\fBmax-stores-to-track\fR" 4
  .IX Item "max-stores-to-track"
  The maximum number of stores to track at the same time in the attemt to
  to merge them into wider stores in the store merging pass.
! .IP "\fBmax-unrolled-insns\fR" 4
  .IX Item "max-unrolled-insns"
  The maximum number of instructions that a loop may have to be unrolled.
  If a loop is unrolled, this parameter also determines how many times
  the loop code is unrolled.
! .IP "\fBmax-average-unrolled-insns\fR" 4
  .IX Item "max-average-unrolled-insns"
  The maximum number of instructions biased by probabilities of their execution
  that a loop may have to be unrolled.  If a loop is unrolled,
  this parameter also determines how many times the loop code is unrolled.
! .IP "\fBmax-unroll-times\fR" 4
  .IX Item "max-unroll-times"
  The maximum number of unrollings of a single loop.
! .IP "\fBmax-peeled-insns\fR" 4
  .IX Item "max-peeled-insns"
  The maximum number of instructions that a loop may have to be peeled.
  If a loop is peeled, this parameter also determines how many times
  the loop code is peeled.
! .IP "\fBmax-peel-times\fR" 4
  .IX Item "max-peel-times"
  The maximum number of peelings of a single loop.
! .IP "\fBmax-peel-branches\fR" 4
  .IX Item "max-peel-branches"
  The maximum number of branches on the hot path through the peeled sequence.
! .IP "\fBmax-completely-peeled-insns\fR" 4
  .IX Item "max-completely-peeled-insns"
  The maximum number of insns of a completely peeled loop.
! .IP "\fBmax-completely-peel-times\fR" 4
  .IX Item "max-completely-peel-times"
  The maximum number of iterations of a loop to be suitable for complete peeling.
! .IP "\fBmax-completely-peel-loop-nest-depth\fR" 4
  .IX Item "max-completely-peel-loop-nest-depth"
  The maximum depth of a loop nest suitable for complete peeling.
! .IP "\fBmax-unswitch-insns\fR" 4
  .IX Item "max-unswitch-insns"
  The maximum number of insns of an unswitched loop.
! .IP "\fBmax-unswitch-depth\fR" 4
  .IX Item "max-unswitch-depth"
  The maximum depth of a loop nest to be unswitched.
! .IP "\fBlim-expensive\fR" 4
  .IX Item "lim-expensive"
  The minimum cost of an expensive expression in the loop invariant motion.
! .IP "\fBmin-loop-cond-split-prob\fR" 4
  .IX Item "min-loop-cond-split-prob"
! When \s-1FDO\s0 profile information is available, \fBmin-loop-cond-split-prob\fR
! specifies minimum threshold for probability of semi-invariant condition
  statement to trigger loop split.
! .IP "\fBiv-consider-all-candidates-bound\fR" 4
  .IX Item "iv-consider-all-candidates-bound"
  Bound on number of candidates for induction variables, below which
  all candidates are considered for each use in induction variable
  optimizations.  If there are more candidates than this,
  only the most relevant ones are considered to avoid quadratic time complexity.
! .IP "\fBiv-max-considered-uses\fR" 4
  .IX Item "iv-max-considered-uses"
  The induction variable optimizations give up on loops that contain more
  induction variable uses.
! .IP "\fBiv-always-prune-cand-set-bound\fR" 4
  .IX Item "iv-always-prune-cand-set-bound"
  If the number of candidates in the set is smaller than this value,
  always try to remove unnecessary ivs from the set
  when adding a new one.
! .IP "\fBavg-loop-niter\fR" 4
  .IX Item "avg-loop-niter"
  Average number of iterations of a loop.
! .IP "\fBdse-max-object-size\fR" 4
  .IX Item "dse-max-object-size"
  Maximum size (in bytes) of objects tracked bytewise by dead store elimination.
  Larger values may result in larger compilation times.
! .IP "\fBdse-max-alias-queries-per-store\fR" 4
  .IX Item "dse-max-alias-queries-per-store"
  Maximum number of queries into the alias oracle per store.
  Larger values result in larger compilation times and may result in more
  removed dead stores.
! .IP "\fBscev-max-expr-size\fR" 4
  .IX Item "scev-max-expr-size"
  Bound on size of expressions used in the scalar evolutions analyzer.
  Large expressions slow the analyzer.
! .IP "\fBscev-max-expr-complexity\fR" 4
  .IX Item "scev-max-expr-complexity"
  Bound on the complexity of the expressions in the scalar evolutions analyzer.
  Complex expressions slow the analyzer.
! .IP "\fBmax-tree-if-conversion-phi-args\fR" 4
  .IX Item "max-tree-if-conversion-phi-args"
! Maximum number of arguments in a \s-1PHI\s0 supported by \s-1TREE\s0 if conversion
  unless the loop is marked with simd pragma.
! .IP "\fBvect-max-layout-candidates\fR" 4
  .IX Item "vect-max-layout-candidates"
  The maximum number of possible vector layouts (such as permutations)
! to consider when optimizing to-be-vectorized code.
! .IP "\fBvect-max-version-for-alignment-checks\fR" 4
  .IX Item "vect-max-version-for-alignment-checks"
! The maximum number of run-time checks that can be performed when
  doing loop versioning for alignment in the vectorizer.
! .IP "\fBvect-max-version-for-alias-checks\fR" 4
  .IX Item "vect-max-version-for-alias-checks"
! The maximum number of run-time checks that can be performed when
  doing loop versioning for alias in the vectorizer.
! .IP "\fBvect-max-peeling-for-alignment\fR" 4
  .IX Item "vect-max-peeling-for-alignment"
  The maximum number of loop peels to enhance access alignment
  for vectorizer. Value \-1 means no limit.
! .IP "\fBmax-iterations-to-track\fR" 4
  .IX Item "max-iterations-to-track"
! The maximum number of iterations of a loop the brute-force algorithm
  for analysis of the number of iterations of the loop tries to evaluate.
! .IP "\fBhot-bb-count-fraction\fR" 4
  .IX Item "hot-bb-count-fraction"
  The denominator n of fraction 1/n of the maximal execution count of a
  basic block in the entire program that a basic block needs to at least
  have in order to be considered hot.  The default is 10000, which means
  that a basic block is considered hot if its execution count is greater
  than 1/10000 of the maximal execution count.  0 means that it is never
! considered hot.  Used in non-LTO mode.
! .IP "\fBhot-bb-count-ws-permille\fR" 4
  .IX Item "hot-bb-count-ws-permille"
  The number of most executed permilles, ranging from 0 to 1000, of the
  profiled execution of the entire program to which the execution count
--- 13966,14184 ----
  recursion depth can be guessed from the probability that function recurses
  via a given call expression.  This parameter limits inlining only to call
  expressions whose probability exceeds the given threshold (in percents).
! .IP \fBearly\-inlining\-insns\fR 4
  .IX Item "early-inlining-insns"
  Specify growth that the early inliner can make.  In effect it increases
  the amount of inlining for code having a large abstraction penalty.
! .IP \fBmax\-early\-inliner\-iterations\fR 4
  .IX Item "max-early-inliner-iterations"
  Limit of iterations of the early inliner.  This basically bounds
  the number of nested indirect calls the early inliner can resolve.
  Deeper chains are still handled by late inlining.
! .IP \fBcomdat\-sharing\-probability\fR 4
  .IX Item "comdat-sharing-probability"
! Probability (in percent) that C++ inline function with comdat visibility
  are shared across multiple compilation units.
! .IP \fBmodref\-max\-bases\fR 4
  .IX Item "modref-max-bases"
  .PD 0
! .IP \fBmodref\-max\-refs\fR 4
  .IX Item "modref-max-refs"
! .IP \fBmodref\-max\-accesses\fR 4
  .IX Item "modref-max-accesses"
  .PD
  Specifies the maximal number of base pointers, references and accesses stored
  for a single function by mod/ref analysis.
! .IP \fBmodref\-max\-tests\fR 4
  .IX Item "modref-max-tests"
  Specifies the maxmal number of tests alias oracle can perform to disambiguate
  memory locations using the mod/ref information.  This parameter ought to be
! bigger than \fB\-\-param modref\-max\-bases\fR and \fB\-\-param
! modref\-max\-refs\fR.
! .IP \fBmodref\-max\-depth\fR 4
  .IX Item "modref-max-depth"
! Specifies the maximum depth of DFS walk used by modref escape analysis.
  Setting to 0 disables the analysis completely.
! .IP \fBmodref\-max\-escape\-points\fR 4
  .IX Item "modref-max-escape-points"
! Specifies the maximum number of escape points tracked by modref per SSA\-name.
! .IP \fBmodref\-max\-adjustments\fR 4
  .IX Item "modref-max-adjustments"
  Specifies the maximum number the access range is enlarged during modref dataflow
  analysis.
! .IP \fBprofile\-func\-internal\-id\fR 4
  .IX Item "profile-func-internal-id"
  A parameter to control whether to use function internal id in profile
  database lookup. If the value is 0, the compiler uses an id that
  is based on function assembler name and filename, which makes old profile
  data more tolerant to source changes such as function reordering etc.
! .IP \fBmin\-vect\-loop\-bound\fR 4
  .IX Item "min-vect-loop-bound"
  The minimum number of iterations under which loops are not vectorized
  when \fB\-ftree\-vectorize\fR is used.  The number of iterations after
  vectorization needs to be greater than the value specified by this option
  to allow vectorization.
! .IP \fBgcse\-cost\-distance\-ratio\fR 4
  .IX Item "gcse-cost-distance-ratio"
  Scaling factor in calculation of maximum distance an expression
! can be moved by GCSE optimizations.  This is currently supported only in the
  code hoisting pass.  The bigger the ratio, the more aggressive code hoisting
  is with simple expressions, i.e., the expressions that have cost
! less than \fBgcse\-unrestricted\-cost\fR.  Specifying 0 disables
  hoisting of simple expressions.
! .IP \fBgcse\-unrestricted\-cost\fR 4
  .IX Item "gcse-unrestricted-cost"
  Cost, roughly measured as the cost of a single typical machine
! instruction, at which GCSE optimizations do not constrain
  the distance an expression can travel.  This is currently
  supported only in the code hoisting pass.  The lesser the cost,
  the more aggressive code hoisting is.  Specifying 0 
  allows all expressions to travel unrestricted distances.
! .IP \fBmax\-hoist\-depth\fR 4
  .IX Item "max-hoist-depth"
  The depth of search in the dominator tree for expressions to hoist.
  This is used to avoid quadratic behavior in hoisting algorithm.
  The value of 0 does not limit on the search, but may slow down compilation
  of huge functions.
! .IP \fBmax\-tail\-merge\-comparisons\fR 4
  .IX Item "max-tail-merge-comparisons"
  The maximum amount of similar bbs to compare a bb with.  This is used to
  avoid quadratic behavior in tree tail merging.
! .IP \fBmax\-tail\-merge\-iterations\fR 4
  .IX Item "max-tail-merge-iterations"
  The maximum amount of iterations of the pass over the function.  This is used to
  limit compilation time in tree tail merging.
! .IP \fBstore\-merging\-allow\-unaligned\fR 4
  .IX Item "store-merging-allow-unaligned"
  Allow the store merging pass to introduce unaligned stores if it is legal to
  do so.
! .IP \fBmax\-stores\-to\-merge\fR 4
  .IX Item "max-stores-to-merge"
  The maximum number of stores to attempt to merge into wider stores in the store
  merging pass.
! .IP \fBmax\-store\-chains\-to\-track\fR 4
  .IX Item "max-store-chains-to-track"
  The maximum number of store chains to track at the same time in the attempt
  to merge them into wider stores in the store merging pass.
! .IP \fBmax\-stores\-to\-track\fR 4
  .IX Item "max-stores-to-track"
  The maximum number of stores to track at the same time in the attemt to
  to merge them into wider stores in the store merging pass.
! .IP \fBmax\-unrolled\-insns\fR 4
  .IX Item "max-unrolled-insns"
  The maximum number of instructions that a loop may have to be unrolled.
  If a loop is unrolled, this parameter also determines how many times
  the loop code is unrolled.
! .IP \fBmax\-average\-unrolled\-insns\fR 4
  .IX Item "max-average-unrolled-insns"
  The maximum number of instructions biased by probabilities of their execution
  that a loop may have to be unrolled.  If a loop is unrolled,
  this parameter also determines how many times the loop code is unrolled.
! .IP \fBmax\-unroll\-times\fR 4
  .IX Item "max-unroll-times"
  The maximum number of unrollings of a single loop.
! .IP \fBmax\-peeled\-insns\fR 4
  .IX Item "max-peeled-insns"
  The maximum number of instructions that a loop may have to be peeled.
  If a loop is peeled, this parameter also determines how many times
  the loop code is peeled.
! .IP \fBmax\-peel\-times\fR 4
  .IX Item "max-peel-times"
  The maximum number of peelings of a single loop.
! .IP \fBmax\-peel\-branches\fR 4
  .IX Item "max-peel-branches"
  The maximum number of branches on the hot path through the peeled sequence.
! .IP \fBmax\-completely\-peeled\-insns\fR 4
  .IX Item "max-completely-peeled-insns"
  The maximum number of insns of a completely peeled loop.
! .IP \fBmax\-completely\-peel\-times\fR 4
  .IX Item "max-completely-peel-times"
  The maximum number of iterations of a loop to be suitable for complete peeling.
! .IP \fBmax\-completely\-peel\-loop\-nest\-depth\fR 4
  .IX Item "max-completely-peel-loop-nest-depth"
  The maximum depth of a loop nest suitable for complete peeling.
! .IP \fBmax\-unswitch\-insns\fR 4
  .IX Item "max-unswitch-insns"
  The maximum number of insns of an unswitched loop.
! .IP \fBmax\-unswitch\-depth\fR 4
  .IX Item "max-unswitch-depth"
  The maximum depth of a loop nest to be unswitched.
! .IP \fBlim\-expensive\fR 4
  .IX Item "lim-expensive"
  The minimum cost of an expensive expression in the loop invariant motion.
! .IP \fBmin\-loop\-cond\-split\-prob\fR 4
  .IX Item "min-loop-cond-split-prob"
! When FDO profile information is available, \fBmin\-loop\-cond\-split\-prob\fR
! specifies minimum threshold for probability of semi\-invariant condition
  statement to trigger loop split.
! .IP \fBiv\-consider\-all\-candidates\-bound\fR 4
  .IX Item "iv-consider-all-candidates-bound"
  Bound on number of candidates for induction variables, below which
  all candidates are considered for each use in induction variable
  optimizations.  If there are more candidates than this,
  only the most relevant ones are considered to avoid quadratic time complexity.
! .IP \fBiv\-max\-considered\-uses\fR 4
  .IX Item "iv-max-considered-uses"
  The induction variable optimizations give up on loops that contain more
  induction variable uses.
! .IP \fBiv\-always\-prune\-cand\-set\-bound\fR 4
  .IX Item "iv-always-prune-cand-set-bound"
  If the number of candidates in the set is smaller than this value,
  always try to remove unnecessary ivs from the set
  when adding a new one.
! .IP \fBavg\-loop\-niter\fR 4
  .IX Item "avg-loop-niter"
  Average number of iterations of a loop.
! .IP \fBdse\-max\-object\-size\fR 4
  .IX Item "dse-max-object-size"
  Maximum size (in bytes) of objects tracked bytewise by dead store elimination.
  Larger values may result in larger compilation times.
! .IP \fBdse\-max\-alias\-queries\-per\-store\fR 4
  .IX Item "dse-max-alias-queries-per-store"
  Maximum number of queries into the alias oracle per store.
  Larger values result in larger compilation times and may result in more
  removed dead stores.
! .IP \fBscev\-max\-expr\-size\fR 4
  .IX Item "scev-max-expr-size"
  Bound on size of expressions used in the scalar evolutions analyzer.
  Large expressions slow the analyzer.
! .IP \fBscev\-max\-expr\-complexity\fR 4
  .IX Item "scev-max-expr-complexity"
  Bound on the complexity of the expressions in the scalar evolutions analyzer.
  Complex expressions slow the analyzer.
! .IP \fBmax\-tree\-if\-conversion\-phi\-args\fR 4
  .IX Item "max-tree-if-conversion-phi-args"
! Maximum number of arguments in a PHI supported by TREE if conversion
  unless the loop is marked with simd pragma.
! .IP \fBvect\-max\-layout\-candidates\fR 4
  .IX Item "vect-max-layout-candidates"
  The maximum number of possible vector layouts (such as permutations)
! to consider when optimizing to\-be\-vectorized code.
! .IP \fBvect\-max\-version\-for\-alignment\-checks\fR 4
  .IX Item "vect-max-version-for-alignment-checks"
! The maximum number of run\-time checks that can be performed when
  doing loop versioning for alignment in the vectorizer.
! .IP \fBvect\-max\-version\-for\-alias\-checks\fR 4
  .IX Item "vect-max-version-for-alias-checks"
! The maximum number of run\-time checks that can be performed when
  doing loop versioning for alias in the vectorizer.
! .IP \fBvect\-max\-peeling\-for\-alignment\fR 4
  .IX Item "vect-max-peeling-for-alignment"
  The maximum number of loop peels to enhance access alignment
  for vectorizer. Value \-1 means no limit.
! .IP \fBmax\-iterations\-to\-track\fR 4
  .IX Item "max-iterations-to-track"
! The maximum number of iterations of a loop the brute\-force algorithm
  for analysis of the number of iterations of the loop tries to evaluate.
! .IP \fBhot\-bb\-count\-fraction\fR 4
  .IX Item "hot-bb-count-fraction"
  The denominator n of fraction 1/n of the maximal execution count of a
  basic block in the entire program that a basic block needs to at least
  have in order to be considered hot.  The default is 10000, which means
  that a basic block is considered hot if its execution count is greater
  than 1/10000 of the maximal execution count.  0 means that it is never
! considered hot.  Used in non\-LTO mode.
! .IP \fBhot\-bb\-count\-ws\-permille\fR 4
  .IX Item "hot-bb-count-ws-permille"
  The number of most executed permilles, ranging from 0 to 1000, of the
  profiled execution of the entire program to which the execution count
*************** of a basic block must be part of in orde
*** 14257,14264 ****
  default is 990, which means that a basic block is considered hot if
  its execution count contributes to the upper 990 permilles, or 99.0%,
  of the profiled execution of the entire program.  0 means that it is
! never considered hot.  Used in \s-1LTO\s0 mode.
! .IP "\fBhot-bb-frequency-fraction\fR" 4
  .IX Item "hot-bb-frequency-fraction"
  The denominator n of fraction 1/n of the execution frequency of the
  entry block of a function that a basic block of this function needs
--- 14186,14193 ----
  default is 990, which means that a basic block is considered hot if
  its execution count contributes to the upper 990 permilles, or 99.0%,
  of the profiled execution of the entire program.  0 means that it is
! never considered hot.  Used in LTO mode.
! .IP \fBhot\-bb\-frequency\-fraction\fR 4
  .IX Item "hot-bb-frequency-fraction"
  The denominator n of fraction 1/n of the execution frequency of the
  entry block of a function that a basic block of this function needs
*************** to at least have in order to be consider
*** 14266,14272 ****
  which means that a basic block is considered hot in a function if it
  is executed more frequently than 1/1000 of the frequency of the entry
  block of the function.  0 means that it is never considered hot.
! .IP "\fBunlikely-bb-count-fraction\fR" 4
  .IX Item "unlikely-bb-count-fraction"
  The denominator n of fraction 1/n of the number of profiled runs of
  the entire program below which the execution count of a basic block
--- 14195,14201 ----
  which means that a basic block is considered hot in a function if it
  is executed more frequently than 1/1000 of the frequency of the entry
  block of the function.  0 means that it is never considered hot.
! .IP \fBunlikely\-bb\-count\-fraction\fR 4
  .IX Item "unlikely-bb-count-fraction"
  The denominator n of fraction 1/n of the number of profiled runs of
  the entire program below which the execution count of a basic block
*************** must be in order for the basic block to
*** 14274,14280 ****
  The default is 20, which means that a basic block is considered unlikely
  executed if it is executed in fewer than 1/20, or 5%, of the runs of
  the program.  0 means that it is always considered unlikely executed.
! .IP "\fBmax-predicted-iterations\fR" 4
  .IX Item "max-predicted-iterations"
  The maximum number of loop iterations we predict statically.  This is useful
  in cases where a function contains a single loop with known bound and
--- 14203,14209 ----
  The default is 20, which means that a basic block is considered unlikely
  executed if it is executed in fewer than 1/20, or 5%, of the runs of
  the program.  0 means that it is always considered unlikely executed.
! .IP \fBmax\-predicted\-iterations\fR 4
  .IX Item "max-predicted-iterations"
  The maximum number of loop iterations we predict statically.  This is useful
  in cases where a function contains a single loop with known bound and
*************** another loop with unknown bound.
*** 14282,14529 ****
  The known number of iterations is predicted correctly, while
  the unknown number of iterations average to roughly 10.  This means that the
  loop without bounds appears artificially cold relative to the other one.
! .IP "\fBbuiltin-expect-probability\fR" 4
  .IX Item "builtin-expect-probability"
  Control the probability of the expression having the specified value. This
  parameter takes a percentage (i.e. 0 ... 100) as input.
! .IP "\fBbuiltin-string-cmp-inline-length\fR" 4
  .IX Item "builtin-string-cmp-inline-length"
  The maximum length of a constant string for a builtin string cmp call 
  eligible for inlining.
! .IP "\fBalign-threshold\fR" 4
  .IX Item "align-threshold"
  Select fraction of the maximal frequency of executions of a basic block in
  a function to align the basic block.
! .IP "\fBalign-loop-iterations\fR" 4
  .IX Item "align-loop-iterations"
  A loop expected to iterate at least the selected number of iterations is
  aligned.
! .IP "\fBtracer-dynamic-coverage\fR" 4
  .IX Item "tracer-dynamic-coverage"
  .PD 0
! .IP "\fBtracer-dynamic-coverage-feedback\fR" 4
  .IX Item "tracer-dynamic-coverage-feedback"
  .PD
  This value is used to limit superblock formation once the given percentage of
  executed instructions is covered.  This limits unnecessary code size
  expansion.
  .Sp
! The \fBtracer-dynamic-coverage-feedback\fR parameter
  is used only when profile
  feedback is available.  The real profiles (as opposed to statically estimated
  ones) are much less balanced allowing the threshold to be larger value.
! .IP "\fBtracer-max-code-growth\fR" 4
  .IX Item "tracer-max-code-growth"
  Stop tail duplication once code growth has reached given percentage.  This is
  a rather artificial limit, as most of the duplicates are eliminated later in
  cross jumping, so it may be set to much higher values than is the desired code
  growth.
! .IP "\fBtracer-min-branch-ratio\fR" 4
  .IX Item "tracer-min-branch-ratio"
  Stop reverse growth when the reverse probability of best edge is less than this
  threshold (in percent).
! .IP "\fBtracer-min-branch-probability\fR" 4
  .IX Item "tracer-min-branch-probability"
  .PD 0
! .IP "\fBtracer-min-branch-probability-feedback\fR" 4
  .IX Item "tracer-min-branch-probability-feedback"
  .PD
  Stop forward growth if the best edge has probability lower than this
  threshold.
  .Sp
! Similarly to \fBtracer-dynamic-coverage\fR two parameters are
! provided.  \fBtracer-min-branch-probability-feedback\fR is used for
! compilation with profile feedback and \fBtracer-min-branch-probability\fR
  compilation without.  The value for compilation with profile feedback
  needs to be more conservative (higher) in order to make tracer
  effective.
! .IP "\fBstack-clash-protection-guard-size\fR" 4
  .IX Item "stack-clash-protection-guard-size"
  Specify the size of the operating system provided stack guard as
  2 raised to \fInum\fR bytes.  Higher values may reduce the
  number of explicit probes, but a value larger than the operating system
  provided guard will leave code vulnerable to stack clash style attacks.
! .IP "\fBstack-clash-protection-probe-interval\fR" 4
  .IX Item "stack-clash-protection-probe-interval"
  Stack clash protection involves probing stack space as it is allocated.  This
  param controls the maximum distance between probes into the stack as 2 raised
  to \fInum\fR bytes.  Higher values may reduce the number of explicit probes, but a value
  larger than the operating system provided guard will leave code vulnerable to
  stack clash style attacks.
! .IP "\fBmax-cse-path-length\fR" 4
  .IX Item "max-cse-path-length"
! The maximum number of basic blocks on path that \s-1CSE\s0 considers.
! .IP "\fBmax-cse-insns\fR" 4
  .IX Item "max-cse-insns"
! The maximum number of instructions \s-1CSE\s0 processes before flushing.
! .IP "\fBggc-min-expand\fR" 4
  .IX Item "ggc-min-expand"
! \&\s-1GCC\s0 uses a garbage collector to manage its own memory allocation.  This
  parameter specifies the minimum percentage by which the garbage
! collector's heap should be allowed to expand between collections.
  Tuning this may improve compilation speed; it has no effect on code
  generation.
  .Sp
! The default is 30% + 70% * (\s-1RAM/1GB\s0) with an upper bound of 100% when
! \&\s-1RAM\s0 >= 1GB.  If \f(CW\*(C`getrlimit\*(C'\fR is available, the notion of \*(L"\s-1RAM\*(R"\s0 is
! the smallest of actual \s-1RAM\s0 and \f(CW\*(C`RLIMIT_DATA\*(C'\fR or \f(CW\*(C`RLIMIT_AS\*(C'\fR.  If
! \&\s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a particular platform, the lower
  bound of 30% is used.  Setting this parameter and
! \&\fBggc-min-heapsize\fR to zero causes a full collection to occur at
  every opportunity.  This is extremely slow, but can be useful for
  debugging.
! .IP "\fBggc-min-heapsize\fR" 4
  .IX Item "ggc-min-heapsize"
! Minimum size of the garbage collector's heap before it begins bothering
  to collect garbage.  The first collection occurs after the heap expands
! by \fBggc-min-expand\fR% beyond \fBggc-min-heapsize\fR.  Again,
  tuning this may improve compilation speed, and has no effect on code
  generation.
  .Sp
! The default is the smaller of \s-1RAM/8, RLIMIT_RSS,\s0 or a limit that
! tries to ensure that \s-1RLIMIT_DATA\s0 or \s-1RLIMIT_AS\s0 are not exceeded, but
  with a lower bound of 4096 (four megabytes) and an upper bound of
! 131072 (128 megabytes).  If \s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a
  particular platform, the lower bound is used.  Setting this parameter
  very large effectively disables garbage collection.  Setting this
! parameter and \fBggc-min-expand\fR to zero causes a full collection
  to occur at every opportunity.
! .IP "\fBmax-reload-search-insns\fR" 4
  .IX Item "max-reload-search-insns"
  The maximum number of instruction reload should look backward for equivalent
  register.  Increasing values mean more aggressive optimization, making the
  compilation time increase with probably slightly better performance.
! .IP "\fBmax-cselib-memory-locations\fR" 4
  .IX Item "max-cselib-memory-locations"
  The maximum number of memory locations cselib should take into account.
  Increasing values mean more aggressive optimization, making the compilation time
  increase with probably slightly better performance.
! .IP "\fBmax-sched-ready-insns\fR" 4
  .IX Item "max-sched-ready-insns"
  The maximum number of instructions ready to be issued the scheduler should
  consider at any given time during the first scheduling pass.  Increasing
  values mean more thorough searches, making the compilation time increase
  with probably little benefit.
! .IP "\fBmax-sched-region-blocks\fR" 4
  .IX Item "max-sched-region-blocks"
  The maximum number of blocks in a region to be considered for
  interblock scheduling.
! .IP "\fBmax-pipeline-region-blocks\fR" 4
  .IX Item "max-pipeline-region-blocks"
  The maximum number of blocks in a region to be considered for
  pipelining in the selective scheduler.
! .IP "\fBmax-sched-region-insns\fR" 4
  .IX Item "max-sched-region-insns"
  The maximum number of insns in a region to be considered for
  interblock scheduling.
! .IP "\fBmax-pipeline-region-insns\fR" 4
  .IX Item "max-pipeline-region-insns"
  The maximum number of insns in a region to be considered for
  pipelining in the selective scheduler.
! .IP "\fBmin-spec-prob\fR" 4
  .IX Item "min-spec-prob"
  The minimum probability (in percents) of reaching a source block
  for interblock speculative scheduling.
! .IP "\fBmax-sched-extend-regions-iters\fR" 4
  .IX Item "max-sched-extend-regions-iters"
! The maximum number of iterations through \s-1CFG\s0 to extend regions.
  A value of 0 disables region extensions.
! .IP "\fBmax-sched-insn-conflict-delay\fR" 4
  .IX Item "max-sched-insn-conflict-delay"
  The maximum conflict delay for an insn to be considered for speculative motion.
! .IP "\fBsched-spec-prob-cutoff\fR" 4
  .IX Item "sched-spec-prob-cutoff"
  The minimal probability of speculation success (in percents), so that
  speculative insns are scheduled.
! .IP "\fBsched-state-edge-prob-cutoff\fR" 4
  .IX Item "sched-state-edge-prob-cutoff"
  The minimum probability an edge must have for the scheduler to save its
  state across it.
! .IP "\fBsched-mem-true-dep-cost\fR" 4
  .IX Item "sched-mem-true-dep-cost"
! Minimal distance (in \s-1CPU\s0 cycles) between store and load targeting same
  memory locations.
! .IP "\fBselsched-max-lookahead\fR" 4
  .IX Item "selsched-max-lookahead"
  The maximum size of the lookahead window of selective scheduling.  It is a
  depth of search for available instructions.
! .IP "\fBselsched-max-sched-times\fR" 4
  .IX Item "selsched-max-sched-times"
  The maximum number of times that an instruction is scheduled during
  selective scheduling.  This is the limit on the number of iterations
  through which the instruction may be pipelined.
! .IP "\fBselsched-insns-to-rename\fR" 4
  .IX Item "selsched-insns-to-rename"
  The maximum number of best instructions in the ready list that are considered
  for renaming in the selective scheduler.
! .IP "\fBsms-min-sc\fR" 4
  .IX Item "sms-min-sc"
  The minimum value of stage count that swing modulo scheduler
  generates.
! .IP "\fBmax-last-value-rtl\fR" 4
  .IX Item "max-last-value-rtl"
  The maximum size measured as number of RTLs that can be recorded in an expression
  in combiner for a pseudo register as last known value of that register.
! .IP "\fBmax-combine-insns\fR" 4
  .IX Item "max-combine-insns"
! The maximum number of instructions the \s-1RTL\s0 combiner tries to combine.
! .IP "\fBinteger-share-limit\fR" 4
  .IX Item "integer-share-limit"
  Small integer constants can use a shared data structure, reducing the
! compiler's memory usage and increasing its speed.  This sets the maximum
  value of a shared integer constant.
! .IP "\fBssp-buffer-size\fR" 4
  .IX Item "ssp-buffer-size"
  The minimum size of buffers (i.e. arrays) that receive stack smashing
  protection when \fB\-fstack\-protector\fR is used.
! .IP "\fBmin-size-for-stack-sharing\fR" 4
  .IX Item "min-size-for-stack-sharing"
  The minimum size of variables taking part in stack slot sharing when not
  optimizing.
! .IP "\fBmax-jump-thread-duplication-stmts\fR" 4
  .IX Item "max-jump-thread-duplication-stmts"
  Maximum number of statements allowed in a block that needs to be
  duplicated when threading jumps.
! .IP "\fBmax-jump-thread-paths\fR" 4
  .IX Item "max-jump-thread-paths"
  The maximum number of paths to consider when searching for jump threading
  opportunities.  When arriving at a block, incoming edges are only considered
  if the number of paths to be searched so far multiplied by the number of
  incoming edges does not exhaust the specified maximum number of paths to
  consider.
! .IP "\fBmax-fields-for-field-sensitive\fR" 4
  .IX Item "max-fields-for-field-sensitive"
  Maximum number of fields in a structure treated in
  a field sensitive manner during pointer analysis.
! .IP "\fBprefetch-latency\fR" 4
  .IX Item "prefetch-latency"
  Estimate on average number of instructions that are executed before
  prefetch finishes.  The distance prefetched ahead is proportional
  to this constant.  Increasing this number may also lead to less
! streams being prefetched (see \fBsimultaneous-prefetches\fR).
! .IP "\fBsimultaneous-prefetches\fR" 4
  .IX Item "simultaneous-prefetches"
  Maximum number of prefetches that can run at the same time.
! .IP "\fBl1\-cache\-line\-size\fR" 4
  .IX Item "l1-cache-line-size"
  The size of cache line in L1 data cache, in bytes.
! .IP "\fBl1\-cache\-size\fR" 4
  .IX Item "l1-cache-size"
  The size of L1 data cache, in kilobytes.
! .IP "\fBl2\-cache\-size\fR" 4
  .IX Item "l2-cache-size"
  The size of L2 data cache, in kilobytes.
! .IP "\fBprefetch-dynamic-strides\fR" 4
  .IX Item "prefetch-dynamic-strides"
  Whether the loop array prefetch pass should issue software prefetch hints
! for strides that are non-constant.  In some cases this may be
! beneficial, though the fact the stride is non-constant may make it
  hard to predict when there is clear benefit to issuing these hints.
  .Sp
! Set to 1 if the prefetch hints should be issued for non-constant
  strides.  Set to 0 if prefetch hints should be issued only for strides that
! are known to be constant and below \fBprefetch-minimum-stride\fR.
! .IP "\fBprefetch-minimum-stride\fR" 4
  .IX Item "prefetch-minimum-stride"
  Minimum constant stride, in bytes, to start using prefetch hints for.  If
  the stride is less than this threshold, prefetch hints will not be issued.
--- 14211,14458 ----
  The known number of iterations is predicted correctly, while
  the unknown number of iterations average to roughly 10.  This means that the
  loop without bounds appears artificially cold relative to the other one.
! .IP \fBbuiltin\-expect\-probability\fR 4
  .IX Item "builtin-expect-probability"
  Control the probability of the expression having the specified value. This
  parameter takes a percentage (i.e. 0 ... 100) as input.
! .IP \fBbuiltin\-string\-cmp\-inline\-length\fR 4
  .IX Item "builtin-string-cmp-inline-length"
  The maximum length of a constant string for a builtin string cmp call 
  eligible for inlining.
! .IP \fBalign\-threshold\fR 4
  .IX Item "align-threshold"
  Select fraction of the maximal frequency of executions of a basic block in
  a function to align the basic block.
! .IP \fBalign\-loop\-iterations\fR 4
  .IX Item "align-loop-iterations"
  A loop expected to iterate at least the selected number of iterations is
  aligned.
! .IP \fBtracer\-dynamic\-coverage\fR 4
  .IX Item "tracer-dynamic-coverage"
  .PD 0
! .IP \fBtracer\-dynamic\-coverage\-feedback\fR 4
  .IX Item "tracer-dynamic-coverage-feedback"
  .PD
  This value is used to limit superblock formation once the given percentage of
  executed instructions is covered.  This limits unnecessary code size
  expansion.
  .Sp
! The \fBtracer\-dynamic\-coverage\-feedback\fR parameter
  is used only when profile
  feedback is available.  The real profiles (as opposed to statically estimated
  ones) are much less balanced allowing the threshold to be larger value.
! .IP \fBtracer\-max\-code\-growth\fR 4
  .IX Item "tracer-max-code-growth"
  Stop tail duplication once code growth has reached given percentage.  This is
  a rather artificial limit, as most of the duplicates are eliminated later in
  cross jumping, so it may be set to much higher values than is the desired code
  growth.
! .IP \fBtracer\-min\-branch\-ratio\fR 4
  .IX Item "tracer-min-branch-ratio"
  Stop reverse growth when the reverse probability of best edge is less than this
  threshold (in percent).
! .IP \fBtracer\-min\-branch\-probability\fR 4
  .IX Item "tracer-min-branch-probability"
  .PD 0
! .IP \fBtracer\-min\-branch\-probability\-feedback\fR 4
  .IX Item "tracer-min-branch-probability-feedback"
  .PD
  Stop forward growth if the best edge has probability lower than this
  threshold.
  .Sp
! Similarly to \fBtracer\-dynamic\-coverage\fR two parameters are
! provided.  \fBtracer\-min\-branch\-probability\-feedback\fR is used for
! compilation with profile feedback and \fBtracer\-min\-branch\-probability\fR
  compilation without.  The value for compilation with profile feedback
  needs to be more conservative (higher) in order to make tracer
  effective.
! .IP \fBstack\-clash\-protection\-guard\-size\fR 4
  .IX Item "stack-clash-protection-guard-size"
  Specify the size of the operating system provided stack guard as
  2 raised to \fInum\fR bytes.  Higher values may reduce the
  number of explicit probes, but a value larger than the operating system
  provided guard will leave code vulnerable to stack clash style attacks.
! .IP \fBstack\-clash\-protection\-probe\-interval\fR 4
  .IX Item "stack-clash-protection-probe-interval"
  Stack clash protection involves probing stack space as it is allocated.  This
  param controls the maximum distance between probes into the stack as 2 raised
  to \fInum\fR bytes.  Higher values may reduce the number of explicit probes, but a value
  larger than the operating system provided guard will leave code vulnerable to
  stack clash style attacks.
! .IP \fBmax\-cse\-path\-length\fR 4
  .IX Item "max-cse-path-length"
! The maximum number of basic blocks on path that CSE considers.
! .IP \fBmax\-cse\-insns\fR 4
  .IX Item "max-cse-insns"
! The maximum number of instructions CSE processes before flushing.
! .IP \fBggc\-min\-expand\fR 4
  .IX Item "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\*(Aqs heap should be allowed to expand between collections.
  Tuning this may improve compilation speed; it has no effect on code
  generation.
  .Sp
! The default is 30% + 70% * (RAM/1GB) with an upper bound of 100% when
! RAM >= 1GB.  If \f(CW\*(C`getrlimit\*(C'\fR is available, the notion of "RAM" is
! the smallest of actual RAM and \f(CW\*(C`RLIMIT_DATA\*(C'\fR or \f(CW\*(C`RLIMIT_AS\*(C'\fR.  If
! GCC is not able to calculate RAM on a particular platform, the lower
  bound of 30% is used.  Setting this parameter and
! \&\fBggc\-min\-heapsize\fR to zero causes a full collection to occur at
  every opportunity.  This is extremely slow, but can be useful for
  debugging.
! .IP \fBggc\-min\-heapsize\fR 4
  .IX Item "ggc-min-heapsize"
! Minimum size of the garbage collector\*(Aqs heap before it begins bothering
  to collect garbage.  The first collection occurs after the heap expands
! by \fBggc\-min\-expand\fR% beyond \fBggc\-min\-heapsize\fR.  Again,
  tuning this may improve compilation speed, and has no effect on code
  generation.
  .Sp
! The default is the smaller of RAM/8, RLIMIT_RSS, or a limit that
! tries to ensure that RLIMIT_DATA or RLIMIT_AS are not exceeded, but
  with a lower bound of 4096 (four megabytes) and an upper bound of
! 131072 (128 megabytes).  If GCC is not able to calculate RAM on a
  particular platform, the lower bound is used.  Setting this parameter
  very large effectively disables garbage collection.  Setting this
! parameter and \fBggc\-min\-expand\fR to zero causes a full collection
  to occur at every opportunity.
! .IP \fBmax\-reload\-search\-insns\fR 4
  .IX Item "max-reload-search-insns"
  The maximum number of instruction reload should look backward for equivalent
  register.  Increasing values mean more aggressive optimization, making the
  compilation time increase with probably slightly better performance.
! .IP \fBmax\-cselib\-memory\-locations\fR 4
  .IX Item "max-cselib-memory-locations"
  The maximum number of memory locations cselib should take into account.
  Increasing values mean more aggressive optimization, making the compilation time
  increase with probably slightly better performance.
! .IP \fBmax\-sched\-ready\-insns\fR 4
  .IX Item "max-sched-ready-insns"
  The maximum number of instructions ready to be issued the scheduler should
  consider at any given time during the first scheduling pass.  Increasing
  values mean more thorough searches, making the compilation time increase
  with probably little benefit.
! .IP \fBmax\-sched\-region\-blocks\fR 4
  .IX Item "max-sched-region-blocks"
  The maximum number of blocks in a region to be considered for
  interblock scheduling.
! .IP \fBmax\-pipeline\-region\-blocks\fR 4
  .IX Item "max-pipeline-region-blocks"
  The maximum number of blocks in a region to be considered for
  pipelining in the selective scheduler.
! .IP \fBmax\-sched\-region\-insns\fR 4
  .IX Item "max-sched-region-insns"
  The maximum number of insns in a region to be considered for
  interblock scheduling.
! .IP \fBmax\-pipeline\-region\-insns\fR 4
  .IX Item "max-pipeline-region-insns"
  The maximum number of insns in a region to be considered for
  pipelining in the selective scheduler.
! .IP \fBmin\-spec\-prob\fR 4
  .IX Item "min-spec-prob"
  The minimum probability (in percents) of reaching a source block
  for interblock speculative scheduling.
! .IP \fBmax\-sched\-extend\-regions\-iters\fR 4
  .IX Item "max-sched-extend-regions-iters"
! The maximum number of iterations through CFG to extend regions.
  A value of 0 disables region extensions.
! .IP \fBmax\-sched\-insn\-conflict\-delay\fR 4
  .IX Item "max-sched-insn-conflict-delay"
  The maximum conflict delay for an insn to be considered for speculative motion.
! .IP \fBsched\-spec\-prob\-cutoff\fR 4
  .IX Item "sched-spec-prob-cutoff"
  The minimal probability of speculation success (in percents), so that
  speculative insns are scheduled.
! .IP \fBsched\-state\-edge\-prob\-cutoff\fR 4
  .IX Item "sched-state-edge-prob-cutoff"
  The minimum probability an edge must have for the scheduler to save its
  state across it.
! .IP \fBsched\-mem\-true\-dep\-cost\fR 4
  .IX Item "sched-mem-true-dep-cost"
! Minimal distance (in CPU cycles) between store and load targeting same
  memory locations.
! .IP \fBselsched\-max\-lookahead\fR 4
  .IX Item "selsched-max-lookahead"
  The maximum size of the lookahead window of selective scheduling.  It is a
  depth of search for available instructions.
! .IP \fBselsched\-max\-sched\-times\fR 4
  .IX Item "selsched-max-sched-times"
  The maximum number of times that an instruction is scheduled during
  selective scheduling.  This is the limit on the number of iterations
  through which the instruction may be pipelined.
! .IP \fBselsched\-insns\-to\-rename\fR 4
  .IX Item "selsched-insns-to-rename"
  The maximum number of best instructions in the ready list that are considered
  for renaming in the selective scheduler.
! .IP \fBsms\-min\-sc\fR 4
  .IX Item "sms-min-sc"
  The minimum value of stage count that swing modulo scheduler
  generates.
! .IP \fBmax\-last\-value\-rtl\fR 4
  .IX Item "max-last-value-rtl"
  The maximum size measured as number of RTLs that can be recorded in an expression
  in combiner for a pseudo register as last known value of that register.
! .IP \fBmax\-combine\-insns\fR 4
  .IX Item "max-combine-insns"
! The maximum number of instructions the RTL combiner tries to combine.
! .IP \fBinteger\-share\-limit\fR 4
  .IX Item "integer-share-limit"
  Small integer constants can use a shared data structure, reducing the
! compiler\*(Aqs memory usage and increasing its speed.  This sets the maximum
  value of a shared integer constant.
! .IP \fBssp\-buffer\-size\fR 4
  .IX Item "ssp-buffer-size"
  The minimum size of buffers (i.e. arrays) that receive stack smashing
  protection when \fB\-fstack\-protector\fR is used.
! .IP \fBmin\-size\-for\-stack\-sharing\fR 4
  .IX Item "min-size-for-stack-sharing"
  The minimum size of variables taking part in stack slot sharing when not
  optimizing.
! .IP \fBmax\-jump\-thread\-duplication\-stmts\fR 4
  .IX Item "max-jump-thread-duplication-stmts"
  Maximum number of statements allowed in a block that needs to be
  duplicated when threading jumps.
! .IP \fBmax\-jump\-thread\-paths\fR 4
  .IX Item "max-jump-thread-paths"
  The maximum number of paths to consider when searching for jump threading
  opportunities.  When arriving at a block, incoming edges are only considered
  if the number of paths to be searched so far multiplied by the number of
  incoming edges does not exhaust the specified maximum number of paths to
  consider.
! .IP \fBmax\-fields\-for\-field\-sensitive\fR 4
  .IX Item "max-fields-for-field-sensitive"
  Maximum number of fields in a structure treated in
  a field sensitive manner during pointer analysis.
! .IP \fBprefetch\-latency\fR 4
  .IX Item "prefetch-latency"
  Estimate on average number of instructions that are executed before
  prefetch finishes.  The distance prefetched ahead is proportional
  to this constant.  Increasing this number may also lead to less
! streams being prefetched (see \fBsimultaneous\-prefetches\fR).
! .IP \fBsimultaneous\-prefetches\fR 4
  .IX Item "simultaneous-prefetches"
  Maximum number of prefetches that can run at the same time.
! .IP \fBl1\-cache\-line\-size\fR 4
  .IX Item "l1-cache-line-size"
  The size of cache line in L1 data cache, in bytes.
! .IP \fBl1\-cache\-size\fR 4
  .IX Item "l1-cache-size"
  The size of L1 data cache, in kilobytes.
! .IP \fBl2\-cache\-size\fR 4
  .IX Item "l2-cache-size"
  The size of L2 data cache, in kilobytes.
! .IP \fBprefetch\-dynamic\-strides\fR 4
  .IX Item "prefetch-dynamic-strides"
  Whether the loop array prefetch pass should issue software prefetch hints
! for strides that are non\-constant.  In some cases this may be
! beneficial, though the fact the stride is non\-constant may make it
  hard to predict when there is clear benefit to issuing these hints.
  .Sp
! Set to 1 if the prefetch hints should be issued for non\-constant
  strides.  Set to 0 if prefetch hints should be issued only for strides that
! are known to be constant and below \fBprefetch\-minimum\-stride\fR.
! .IP \fBprefetch\-minimum\-stride\fR 4
  .IX Item "prefetch-minimum-stride"
  Minimum constant stride, in bytes, to start using prefetch hints for.  If
  the stride is less than this threshold, prefetch hints will not be issued.
*************** the software prefetchers.  If the hardwa
*** 14534,14554 ****
  stride they can handle, it should be used here to improve the use of
  software prefetchers.
  .Sp
! A value of \-1 means we don't have a threshold and therefore
  prefetch hints can be issued for any constant stride.
  .Sp
  This setting is only useful for strides that are known and constant.
! .IP "\fBdestructive-interference-size\fR" 4
  .IX Item "destructive-interference-size"
  .PD 0
! .IP "\fBconstructive-interference-size\fR" 4
  .IX Item "constructive-interference-size"
  .PD
! The values for the \*(C+17 variables
  \&\f(CW\*(C`std::hardware_destructive_interference_size\*(C'\fR and
  \&\f(CW\*(C`std::hardware_constructive_interference_size\*(C'\fR.  The destructive
  interference size is the minimum recommended offset between two
! independent concurrently-accessed objects; the constructive
  interference size is the maximum recommended size of contiguous memory
  accessed together.  Typically both will be the size of an L1 cache
  line for the target, in bytes.  For a generic target covering a range of L1
--- 14463,14483 ----
  stride they can handle, it should be used here to improve the use of
  software prefetchers.
  .Sp
! A value of \-1 means we don\*(Aqt have a threshold and therefore
  prefetch hints can be issued for any constant stride.
  .Sp
  This setting is only useful for strides that are known and constant.
! .IP \fBdestructive\-interference\-size\fR 4
  .IX Item "destructive-interference-size"
  .PD 0
! .IP \fBconstructive\-interference\-size\fR 4
  .IX Item "constructive-interference-size"
  .PD
! The values for the C++17 variables
  \&\f(CW\*(C`std::hardware_destructive_interference_size\*(C'\fR and
  \&\f(CW\*(C`std::hardware_constructive_interference_size\*(C'\fR.  The destructive
  interference size is the minimum recommended offset between two
! independent concurrently\-accessed objects; the constructive
  interference size is the maximum recommended size of contiguous memory
  accessed together.  Typically both will be the size of an L1 cache
  line for the target, in bytes.  For a generic target covering a range of L1
*************** the small end of the range and the destr
*** 14557,14565 ****
  end.
  .Sp
  The destructive interference size is intended to be used for layout,
! and thus has \s-1ABI\s0 impact.  The default value is not expected to be
  stable, and on some targets varies with \fB\-mtune\fR, so use of
! this variable in a context where \s-1ABI\s0 stability is important, such as
  the public interface of a library, is strongly discouraged; if it is
  used in that context, users can stabilize the value using this
  option.
--- 14486,14494 ----
  end.
  .Sp
  The destructive interference size is intended to be used for layout,
! and thus has ABI impact.  The default value is not expected to be
  stable, and on some targets varies with \fB\-mtune\fR, so use of
! this variable in a context where ABI stability is important, such as
  the public interface of a library, is strongly discouraged; if it is
  used in that context, users can stabilize the value using this
  option.
*************** typically only used in a \fBstatic_asser
*** 14569,14601 ****
  fits within a cache line.
  .Sp
  See also \fB\-Winterference\-size\fR.
! .IP "\fBloop-interchange-max-num-stmts\fR" 4
  .IX Item "loop-interchange-max-num-stmts"
  The maximum number of stmts in a loop to be interchanged.
! .IP "\fBloop-interchange-stride-ratio\fR" 4
  .IX Item "loop-interchange-stride-ratio"
  The minimum ratio between stride of two loops for interchange to be profitable.
! .IP "\fBmin-insn-to-prefetch-ratio\fR" 4
  .IX Item "min-insn-to-prefetch-ratio"
  The minimum ratio between the number of instructions and the
  number of prefetches to enable prefetching in a loop.
! .IP "\fBprefetch-min-insn-to-mem-ratio\fR" 4
  .IX Item "prefetch-min-insn-to-mem-ratio"
  The minimum ratio between the number of instructions and the
  number of memory references to enable prefetching in a loop.
! .IP "\fBuse-canonical-types\fR" 4
  .IX Item "use-canonical-types"
! Whether the compiler should use the \*(L"canonical\*(R" type system.
  Should always be 1, which uses a more efficient internal
! mechanism for comparing types in \*(C+ and Objective\-\*(C+.  However, if
  bugs in the canonical type system are causing compilation failures,
  set this value to 0 to disable canonical types.
! .IP "\fBswitch-conversion-max-branch-ratio\fR" 4
  .IX Item "switch-conversion-max-branch-ratio"
  Switch initialization conversion refuses to create arrays that are
! bigger than \fBswitch-conversion-max-branch-ratio\fR times the number of
  branches in the switch.
! .IP "\fBmax-partial-antic-length\fR" 4
  .IX Item "max-partial-antic-length"
  Maximum length of the partial antic set computed during the tree
  partial redundancy elimination optimization (\fB\-ftree\-pre\fR) when
--- 14498,14530 ----
  fits within a cache line.
  .Sp
  See also \fB\-Winterference\-size\fR.
! .IP \fBloop\-interchange\-max\-num\-stmts\fR 4
  .IX Item "loop-interchange-max-num-stmts"
  The maximum number of stmts in a loop to be interchanged.
! .IP \fBloop\-interchange\-stride\-ratio\fR 4
  .IX Item "loop-interchange-stride-ratio"
  The minimum ratio between stride of two loops for interchange to be profitable.
! .IP \fBmin\-insn\-to\-prefetch\-ratio\fR 4
  .IX Item "min-insn-to-prefetch-ratio"
  The minimum ratio between the number of instructions and the
  number of prefetches to enable prefetching in a loop.
! .IP \fBprefetch\-min\-insn\-to\-mem\-ratio\fR 4
  .IX Item "prefetch-min-insn-to-mem-ratio"
  The minimum ratio between the number of instructions and the
  number of memory references to enable prefetching in a loop.
! .IP \fBuse\-canonical\-types\fR 4
  .IX Item "use-canonical-types"
! Whether the compiler should use the "canonical" type system.
  Should always be 1, which uses a more efficient internal
! mechanism for comparing types in C++ and Objective\-C++.  However, if
  bugs in the canonical type system are causing compilation failures,
  set this value to 0 to disable canonical types.
! .IP \fBswitch\-conversion\-max\-branch\-ratio\fR 4
  .IX Item "switch-conversion-max-branch-ratio"
  Switch initialization conversion refuses to create arrays that are
! bigger than \fBswitch\-conversion\-max\-branch\-ratio\fR times the number of
  branches in the switch.
! .IP \fBmax\-partial\-antic\-length\fR 4
  .IX Item "max-partial-antic-length"
  Maximum length of the partial antic set computed during the tree
  partial redundancy elimination optimization (\fB\-ftree\-pre\fR) when
*************** consuming all of the memory available on
*** 14605,14678 ****
  parameter sets a limit on the length of the sets that are computed,
  which prevents the runaway behavior.  Setting a value of 0 for
  this parameter allows an unlimited set length.
! .IP "\fBrpo-vn-max-loop-depth\fR" 4
  .IX Item "rpo-vn-max-loop-depth"
! Maximum loop depth that is value-numbered optimistically.
  When the limit hits the innermost
! \&\fIrpo-vn-max-loop-depth\fR loops and the outermost loop in the
! loop nest are value-numbered optimistically and the remaining ones not.
! .IP "\fBsccvn-max-alias-queries-per-access\fR" 4
  .IX Item "sccvn-max-alias-queries-per-access"
! Maximum number of alias-oracle queries we perform when looking for
  redundancies for loads and stores.  If this limit is hit the search
  is aborted and the load or store is not considered redundant.  The
  number of queries is algorithmically limited to the number of
  stores on all paths from the load to the function entry.
! .IP "\fBira-max-loops-num\fR" 4
  .IX Item "ira-max-loops-num"
! \&\s-1IRA\s0 uses regional register allocation by default.  If a function
  contains more loops than the number given by this parameter, only at most
! the given number of the most frequently-executed loops form regions
  for regional register allocation.
! .IP "\fBira-max-conflict-table-size\fR" 4
  .IX Item "ira-max-conflict-table-size"
! Although \s-1IRA\s0 uses a sophisticated algorithm to compress the conflict
  table, the table can still require excessive amounts of memory for
  huge functions.  If the conflict table for a function could be more
! than the size in \s-1MB\s0 given by this parameter, the register allocator
! instead uses a faster, simpler, and lower-quality
! algorithm that does not require building a pseudo-register conflict table.
! .IP "\fBira-loop-reserved-regs\fR" 4
  .IX Item "ira-loop-reserved-regs"
! \&\s-1IRA\s0 can be used to evaluate more accurate register pressure in loops
  for decisions to move loop invariants (see \fB\-O3\fR).  The number
  of available registers reserved for some other purposes is given
  by this parameter.  Default of the parameter
  is the best found from numerous experiments.
! .IP "\fBira-consider-dup-in-all-alts\fR" 4
  .IX Item "ira-consider-dup-in-all-alts"
! Make \s-1IRA\s0 to consider matching constraint (duplicated operand number)
  heavily in all available alternatives for preferred register class.
! If it is set as zero, it means \s-1IRA\s0 only respects the matching
! constraint when it's in the only available alternative with an
! appropriate register class.  Otherwise, it means \s-1IRA\s0 will check all
  available alternatives for preferred register class even if it has
  found some choice with an appropriate register class and respect the
  found qualified matching constraint.
! .IP "\fBira-simple-lra-insn-threshold\fR" 4
  .IX Item "ira-simple-lra-insn-threshold"
! Approximate function insn number in 1K units triggering simple local \s-1RA.\s0
! .IP "\fBlra-inheritance-ebb-probability-cutoff\fR" 4
  .IX Item "lra-inheritance-ebb-probability-cutoff"
! \&\s-1LRA\s0 tries to reuse values reloaded in registers in subsequent insns.
! This optimization is called inheritance.  \s-1EBB\s0 is used as a region to
! do this optimization.  The parameter defines a minimal fall-through
! edge probability in percentage used to add \s-1BB\s0 to inheritance \s-1EBB\s0 in
! \&\s-1LRA.\s0  The default value was chosen
! from numerous runs of \s-1SPEC2000\s0 on x86\-64.
! .IP "\fBloop-invariant-max-bbs-in-loop\fR" 4
  .IX Item "loop-invariant-max-bbs-in-loop"
  Loop invariant motion can be very expensive, both in compilation time and
! in amount of needed compile-time memory, with very large loops.  Loops
! with more basic blocks than this parameter won't have loop invariant
  motion optimization performed on them.
! .IP "\fBloop-max-datarefs-for-datadeps\fR" 4
  .IX Item "loop-max-datarefs-for-datadeps"
  Building data dependencies is expensive for very large loops.  This
  parameter limits the number of data references in loops that are
  considered for data dependence analysis.  These large loops are no
  handled by the optimizations using loop data dependencies.
! .IP "\fBmax-vartrack-size\fR" 4
  .IX Item "max-vartrack-size"
  Sets a maximum number of hash table slots to use during variable
  tracking dataflow analysis of any function.  If this limit is exceeded
--- 14534,14607 ----
  parameter sets a limit on the length of the sets that are computed,
  which prevents the runaway behavior.  Setting a value of 0 for
  this parameter allows an unlimited set length.
! .IP \fBrpo\-vn\-max\-loop\-depth\fR 4
  .IX Item "rpo-vn-max-loop-depth"
! Maximum loop depth that is value\-numbered optimistically.
  When the limit hits the innermost
! \&\fIrpo\-vn\-max\-loop\-depth\fR loops and the outermost loop in the
! loop nest are value\-numbered optimistically and the remaining ones not.
! .IP \fBsccvn\-max\-alias\-queries\-per\-access\fR 4
  .IX Item "sccvn-max-alias-queries-per-access"
! Maximum number of alias\-oracle queries we perform when looking for
  redundancies for loads and stores.  If this limit is hit the search
  is aborted and the load or store is not considered redundant.  The
  number of queries is algorithmically limited to the number of
  stores on all paths from the load to the function entry.
! .IP \fBira\-max\-loops\-num\fR 4
  .IX Item "ira-max-loops-num"
! IRA uses regional register allocation by default.  If a function
  contains more loops than the number given by this parameter, only at most
! the given number of the most frequently\-executed loops form regions
  for regional register allocation.
! .IP \fBira\-max\-conflict\-table\-size\fR 4
  .IX Item "ira-max-conflict-table-size"
! Although IRA uses a sophisticated algorithm to compress the conflict
  table, the table can still require excessive amounts of memory for
  huge functions.  If the conflict table for a function could be more
! than the size in MB given by this parameter, the register allocator
! instead uses a faster, simpler, and lower\-quality
! algorithm that does not require building a pseudo\-register conflict table.
! .IP \fBira\-loop\-reserved\-regs\fR 4
  .IX Item "ira-loop-reserved-regs"
! IRA can be used to evaluate more accurate register pressure in loops
  for decisions to move loop invariants (see \fB\-O3\fR).  The number
  of available registers reserved for some other purposes is given
  by this parameter.  Default of the parameter
  is the best found from numerous experiments.
! .IP \fBira\-consider\-dup\-in\-all\-alts\fR 4
  .IX Item "ira-consider-dup-in-all-alts"
! Make IRA to consider matching constraint (duplicated operand number)
  heavily in all available alternatives for preferred register class.
! If it is set as zero, it means IRA only respects the matching
! constraint when it\*(Aqs in the only available alternative with an
! appropriate register class.  Otherwise, it means IRA will check all
  available alternatives for preferred register class even if it has
  found some choice with an appropriate register class and respect the
  found qualified matching constraint.
! .IP \fBira\-simple\-lra\-insn\-threshold\fR 4
  .IX Item "ira-simple-lra-insn-threshold"
! Approximate function insn number in 1K units triggering simple local RA.
! .IP \fBlra\-inheritance\-ebb\-probability\-cutoff\fR 4
  .IX Item "lra-inheritance-ebb-probability-cutoff"
! LRA tries to reuse values reloaded in registers in subsequent insns.
! This optimization is called inheritance.  EBB is used as a region to
! do this optimization.  The parameter defines a minimal fall\-through
! edge probability in percentage used to add BB to inheritance EBB in
! LRA.  The default value was chosen
! from numerous runs of SPEC2000 on x86\-64.
! .IP \fBloop\-invariant\-max\-bbs\-in\-loop\fR 4
  .IX Item "loop-invariant-max-bbs-in-loop"
  Loop invariant motion can be very expensive, both in compilation time and
! in amount of needed compile\-time memory, with very large loops.  Loops
! with more basic blocks than this parameter won\*(Aqt have loop invariant
  motion optimization performed on them.
! .IP \fBloop\-max\-datarefs\-for\-datadeps\fR 4
  .IX Item "loop-max-datarefs-for-datadeps"
  Building data dependencies is expensive for very large loops.  This
  parameter limits the number of data references in loops that are
  considered for data dependence analysis.  These large loops are no
  handled by the optimizations using loop data dependencies.
! .IP \fBmax\-vartrack\-size\fR 4
  .IX Item "max-vartrack-size"
  Sets a maximum number of hash table slots to use during variable
  tracking dataflow analysis of any function.  If this limit is exceeded
*************** function is retried without it, after re
*** 14681,14687 ****
  the function.  If the limit is exceeded even without debug insns, var
  tracking analysis is completely disabled for the function.  Setting
  the parameter to zero makes it unlimited.
! .IP "\fBmax-vartrack-expr-depth\fR" 4
  .IX Item "max-vartrack-expr-depth"
  Sets a maximum number of recursion levels when attempting to map
  variable names or debug temporaries to value expressions.  This trades
--- 14610,14616 ----
  the function.  If the limit is exceeded even without debug insns, var
  tracking analysis is completely disabled for the function.  Setting
  the parameter to zero makes it unlimited.
! .IP \fBmax\-vartrack\-expr\-depth\fR 4
  .IX Item "max-vartrack-expr-depth"
  Sets a maximum number of recursion levels when attempting to map
  variable names or debug temporaries to value expressions.  This trades
*************** low, value expressions that are availabl
*** 14690,14896 ****
  debug information may end up not being used; setting this higher may
  enable the compiler to find more complex debug expressions, but compile
  time and memory use may grow.
! .IP "\fBmax-debug-marker-count\fR" 4
  .IX Item "max-debug-marker-count"
  Sets a threshold on the number of debug markers (e.g. begin stmt
! markers) to avoid complexity explosion at inlining or expanding to \s-1RTL.\s0
  If a function has more such gimple stmts than the set limit, such stmts
! will be dropped from the inlined copy of a function, and from its \s-1RTL\s0
  expansion.
! .IP "\fBmin-nondebug-insn-uid\fR" 4
  .IX Item "min-nondebug-insn-uid"
  Use uids starting at this parameter for nondebug insns.  The range below
  the parameter is reserved exclusively for debug insns created by
  \&\fB\-fvar\-tracking\-assignments\fR, but debug insns may get
! (non-overlapping) uids above it if the reserved range is exhausted.
! .IP "\fBipa-sra-deref-prob-threshold\fR" 4
  .IX Item "ipa-sra-deref-prob-threshold"
! IPA-SRA replaces a pointer which is known not be \s-1NULL\s0 with one or more
  new parameters only when the probability (in percent, relative to
  function entry) of it being dereferenced is higher than this parameter.
! .IP "\fBipa-sra-ptr-growth-factor\fR" 4
  .IX Item "ipa-sra-ptr-growth-factor"
! IPA-SRA replaces a pointer to an aggregate with one or more new
  parameters only when their cumulative size is less or equal to
! \&\fBipa-sra-ptr-growth-factor\fR times the size of the original
  pointer parameter.
! .IP "\fBipa-sra-ptrwrap-growth-factor\fR" 4
  .IX Item "ipa-sra-ptrwrap-growth-factor"
  Additional maximum allowed growth of total size of new parameters
! that ipa-sra replaces a pointer to an aggregate with,
  if it points to a local variable that the caller only writes to and
  passes it as an argument to other functions.
! .IP "\fBipa-sra-max-replacements\fR" 4
  .IX Item "ipa-sra-max-replacements"
! Maximum pieces of an aggregate that IPA-SRA tracks.  As a
  consequence, it is also the maximum number of replacements of a formal
  parameter.
! .IP "\fBsra-max-scalarization-size-Ospeed\fR" 4
  .IX Item "sra-max-scalarization-size-Ospeed"
  .PD 0
! .IP "\fBsra-max-scalarization-size-Osize\fR" 4
  .IX Item "sra-max-scalarization-size-Osize"
  .PD
! The two Scalar Reduction of Aggregates passes (\s-1SRA\s0 and IPA-SRA) aim to
  replace scalar parts of aggregates with uses of independent scalar
  variables.  These parameters control the maximum size, in storage units,
  of aggregate which is considered for replacement when compiling for
  speed
! (\fBsra-max-scalarization-size-Ospeed\fR) or size
! (\fBsra-max-scalarization-size-Osize\fR) respectively.
! .IP "\fBsra-max-propagations\fR" 4
  .IX Item "sra-max-propagations"
  The maximum number of artificial accesses that Scalar Replacement of
! Aggregates (\s-1SRA\s0) will track, per one local variable, in order to
  facilitate copy propagation.
! .IP "\fBtm-max-aggregate-size\fR" 4
  .IX Item "tm-max-aggregate-size"
! When making copies of thread-local variables in a transaction, this
  parameter specifies the size in bytes after which variables are
  saved with the logging functions as opposed to save/restore code
  sequence pairs.  This option only applies when using
  \&\fB\-fgnu\-tm\fR.
! .IP "\fBgraphite-max-nb-scop-params\fR" 4
  .IX Item "graphite-max-nb-scop-params"
  To avoid exponential effects in the Graphite loop transforms, the
  number of parameters in a Static Control Part (SCoP) is bounded.
  A value of zero can be used to lift
  the bound.  A variable whose value is unknown at compilation time and
  defined outside a SCoP is a parameter of the SCoP.
! .IP "\fBloop-block-tile-size\fR" 4
  .IX Item "loop-block-tile-size"
  Loop blocking or strip mining transforms, enabled with
  \&\fB\-floop\-block\fR or \fB\-floop\-strip\-mine\fR, strip mine each
  loop in the loop nest by a given number of iterations.  The strip
! length can be changed using the \fBloop-block-tile-size\fR
  parameter.
! .IP "\fBipa-jump-function-lookups\fR" 4
  .IX Item "ipa-jump-function-lookups"
  Specifies number of statements visited during jump function offset discovery.
! .IP "\fBipa-cp-value-list-size\fR" 4
  .IX Item "ipa-cp-value-list-size"
! IPA-CP attempts to track all possible values and types passed to a function's
  parameter in order to propagate them and perform devirtualization.
! \&\fBipa-cp-value-list-size\fR is the maximum number of values and types it
  stores per one formal parameter of a function.
! .IP "\fBipa-cp-eval-threshold\fR" 4
  .IX Item "ipa-cp-eval-threshold"
! IPA-CP calculates its own score of cloning profitability heuristics
  and performs those cloning opportunities with scores that exceed
! \&\fBipa-cp-eval-threshold\fR.
! .IP "\fBipa-cp-max-recursive-depth\fR" 4
  .IX Item "ipa-cp-max-recursive-depth"
! Maximum depth of recursive cloning for self-recursive function.
! .IP "\fBipa-cp-min-recursive-probability\fR" 4
  .IX Item "ipa-cp-min-recursive-probability"
  Recursive cloning only when the probability of call being executed exceeds
  the parameter.
! .IP "\fBipa-cp-profile-count-base\fR" 4
  .IX Item "ipa-cp-profile-count-base"
! When using \fB\-fprofile\-use\fR option, IPA-CP will consider the measured
  execution count of a call graph edge at this percentage position in their
  histogram as the basis for its heuristics calculation.
! .IP "\fBipa-cp-recursive-freq-factor\fR" 4
  .IX Item "ipa-cp-recursive-freq-factor"
  The number of times interprocedural copy propagation expects recursive
  functions to call themselves.
! .IP "\fBipa-cp-recursion-penalty\fR" 4
  .IX Item "ipa-cp-recursion-penalty"
  Percentage penalty the recursive functions will receive when they
  are evaluated for cloning.
! .IP "\fBipa-cp-single-call-penalty\fR" 4
  .IX Item "ipa-cp-single-call-penalty"
  Percentage penalty functions containing a single call to another
  function will receive when they are evaluated for cloning.
! .IP "\fBipa-max-agg-items\fR" 4
  .IX Item "ipa-max-agg-items"
! IPA-CP is also capable to propagate a number of scalar values passed
! in an aggregate. \fBipa-max-agg-items\fR controls the maximum
  number of such values per one parameter.
! .IP "\fBipa-cp-loop-hint-bonus\fR" 4
  .IX Item "ipa-cp-loop-hint-bonus"
! When IPA-CP determines that a cloning candidate would make the number
  of iterations of a loop known, it adds a bonus of
! \&\fBipa-cp-loop-hint-bonus\fR to the profitability score of
  the candidate.
! .IP "\fBipa-max-loop-predicates\fR" 4
  .IX Item "ipa-max-loop-predicates"
! The maximum number of different predicates \s-1IPA\s0 will use to describe when
  loops in a function have known properties.
! .IP "\fBipa-max-aa-steps\fR" 4
  .IX Item "ipa-max-aa-steps"
! During its analysis of function bodies, IPA-CP employs alias analysis
  in order to track values pointed to by function parameters.  In order
  not spend too much time analyzing huge functions, it gives up and
  consider all memory clobbered after examining
! \&\fBipa-max-aa-steps\fR statements modifying memory.
! .IP "\fBipa-max-switch-predicate-bounds\fR" 4
  .IX Item "ipa-max-switch-predicate-bounds"
  Maximal number of boundary endpoints of case ranges of switch statement.
! For switch exceeding this limit, IPA-CP will not construct cloning cost
  predicate, which is used to estimate cloning benefit, for default case
  of the switch statement.
! .IP "\fBipa-max-param-expr-ops\fR" 4
  .IX Item "ipa-max-param-expr-ops"
! IPA-CP will analyze conditional statement that references some function
  parameter to estimate benefit for cloning upon certain constant value.
  But if number of operations in a parameter expression exceeds
! \&\fBipa-max-param-expr-ops\fR, the expression is treated as complicated
! one, and is not handled by \s-1IPA\s0 analysis.
! .IP "\fBlto-partitions\fR" 4
  .IX Item "lto-partitions"
! Specify desired number of partitions produced during \s-1WHOPR\s0 compilation.
  The number of partitions should exceed the number of CPUs used for compilation.
! .IP "\fBlto-min-partition\fR" 4
  .IX Item "lto-min-partition"
! Size of minimal partition for \s-1WHOPR\s0 (in estimated instructions).
  This prevents expenses of splitting very small programs into too many
  partitions.
! .IP "\fBlto-max-partition\fR" 4
  .IX Item "lto-max-partition"
! Size of max partition for \s-1WHOPR\s0 (in estimated instructions).
  to provide an upper bound for individual size of partition.
  Meant to be used only with balanced partitioning.
! .IP "\fBlto-max-streaming-parallelism\fR" 4
  .IX Item "lto-max-streaming-parallelism"
! Maximal number of parallel processes used for \s-1LTO\s0 streaming.
! .IP "\fBcxx-max-namespaces-for-diagnostic-help\fR" 4
  .IX Item "cxx-max-namespaces-for-diagnostic-help"
! The maximum number of namespaces to consult for suggestions when \*(C+
  name lookup fails for an identifier.
! .IP "\fBsink-frequency-threshold\fR" 4
  .IX Item "sink-frequency-threshold"
  The maximum relative execution frequency (in percents) of the target block
! relative to a statement's original block to allow statement sinking of a
  statement.  Larger numbers result in more aggressive statement sinking.
  A small positive adjustment is applied for
  statements with memory operands as those are even more profitable so sink.
! .IP "\fBmax-stores-to-sink\fR" 4
  .IX Item "max-stores-to-sink"
  The maximum number of conditional store pairs that can be sunk.  Set to 0
! if either vectorization (\fB\-ftree\-vectorize\fR) or if-conversion
  (\fB\-ftree\-loop\-if\-convert\fR) is disabled.
! .IP "\fBcase-values-threshold\fR" 4
  .IX Item "case-values-threshold"
  The smallest number of different values for which it is best to use a
! jump-table instead of a tree of conditional branches.  If the value is
  0, use the default for the machine.
! .IP "\fBjump-table-max-growth-ratio-for-size\fR" 4
  .IX Item "jump-table-max-growth-ratio-for-size"
  The maximum code size growth ratio when expanding
  into a jump table (in percent).  The parameter is used when
  optimizing for size.
! .IP "\fBjump-table-max-growth-ratio-for-speed\fR" 4
  .IX Item "jump-table-max-growth-ratio-for-speed"
  The maximum code size growth ratio when expanding
  into a jump table (in percent).  The parameter is used when
  optimizing for speed.
! .IP "\fBtree-reassoc-width\fR" 4
  .IX Item "tree-reassoc-width"
  Set the maximum number of instructions executed in parallel in
  reassociated tree. This parameter overrides target dependent
  heuristics used by default if has non zero value.
! .IP "\fBsched-pressure-algorithm\fR" 4
  .IX Item "sched-pressure-algorithm"
  Choose between the two available implementations of
  \&\fB\-fsched\-pressure\fR.  Algorithm 1 is the original implementation
--- 14619,14825 ----
  debug information may end up not being used; setting this higher may
  enable the compiler to find more complex debug expressions, but compile
  time and memory use may grow.
! .IP \fBmax\-debug\-marker\-count\fR 4
  .IX Item "max-debug-marker-count"
  Sets a threshold on the number of debug markers (e.g. begin stmt
! markers) to avoid complexity explosion at inlining or expanding to RTL.
  If a function has more such gimple stmts than the set limit, such stmts
! will be dropped from the inlined copy of a function, and from its RTL
  expansion.
! .IP \fBmin\-nondebug\-insn\-uid\fR 4
  .IX Item "min-nondebug-insn-uid"
  Use uids starting at this parameter for nondebug insns.  The range below
  the parameter is reserved exclusively for debug insns created by
  \&\fB\-fvar\-tracking\-assignments\fR, but debug insns may get
! (non\-overlapping) uids above it if the reserved range is exhausted.
! .IP \fBipa\-sra\-deref\-prob\-threshold\fR 4
  .IX Item "ipa-sra-deref-prob-threshold"
! IPA\-SRA replaces a pointer which is known not be NULL with one or more
  new parameters only when the probability (in percent, relative to
  function entry) of it being dereferenced is higher than this parameter.
! .IP \fBipa\-sra\-ptr\-growth\-factor\fR 4
  .IX Item "ipa-sra-ptr-growth-factor"
! IPA\-SRA replaces a pointer to an aggregate with one or more new
  parameters only when their cumulative size is less or equal to
! \&\fBipa\-sra\-ptr\-growth\-factor\fR times the size of the original
  pointer parameter.
! .IP \fBipa\-sra\-ptrwrap\-growth\-factor\fR 4
  .IX Item "ipa-sra-ptrwrap-growth-factor"
  Additional maximum allowed growth of total size of new parameters
! that ipa\-sra replaces a pointer to an aggregate with,
  if it points to a local variable that the caller only writes to and
  passes it as an argument to other functions.
! .IP \fBipa\-sra\-max\-replacements\fR 4
  .IX Item "ipa-sra-max-replacements"
! Maximum pieces of an aggregate that IPA\-SRA tracks.  As a
  consequence, it is also the maximum number of replacements of a formal
  parameter.
! .IP \fBsra\-max\-scalarization\-size\-Ospeed\fR 4
  .IX Item "sra-max-scalarization-size-Ospeed"
  .PD 0
! .IP \fBsra\-max\-scalarization\-size\-Osize\fR 4
  .IX Item "sra-max-scalarization-size-Osize"
  .PD
! The two Scalar Reduction of Aggregates passes (SRA and IPA\-SRA) aim to
  replace scalar parts of aggregates with uses of independent scalar
  variables.  These parameters control the maximum size, in storage units,
  of aggregate which is considered for replacement when compiling for
  speed
! (\fBsra\-max\-scalarization\-size\-Ospeed\fR) or size
! (\fBsra\-max\-scalarization\-size\-Osize\fR) respectively.
! .IP \fBsra\-max\-propagations\fR 4
  .IX Item "sra-max-propagations"
  The maximum number of artificial accesses that Scalar Replacement of
! Aggregates (SRA) will track, per one local variable, in order to
  facilitate copy propagation.
! .IP \fBtm\-max\-aggregate\-size\fR 4
  .IX Item "tm-max-aggregate-size"
! When making copies of thread\-local variables in a transaction, this
  parameter specifies the size in bytes after which variables are
  saved with the logging functions as opposed to save/restore code
  sequence pairs.  This option only applies when using
  \&\fB\-fgnu\-tm\fR.
! .IP \fBgraphite\-max\-nb\-scop\-params\fR 4
  .IX Item "graphite-max-nb-scop-params"
  To avoid exponential effects in the Graphite loop transforms, the
  number of parameters in a Static Control Part (SCoP) is bounded.
  A value of zero can be used to lift
  the bound.  A variable whose value is unknown at compilation time and
  defined outside a SCoP is a parameter of the SCoP.
! .IP \fBloop\-block\-tile\-size\fR 4
  .IX Item "loop-block-tile-size"
  Loop blocking or strip mining transforms, enabled with
  \&\fB\-floop\-block\fR or \fB\-floop\-strip\-mine\fR, strip mine each
  loop in the loop nest by a given number of iterations.  The strip
! length can be changed using the \fBloop\-block\-tile\-size\fR
  parameter.
! .IP \fBipa\-jump\-function\-lookups\fR 4
  .IX Item "ipa-jump-function-lookups"
  Specifies number of statements visited during jump function offset discovery.
! .IP \fBipa\-cp\-value\-list\-size\fR 4
  .IX Item "ipa-cp-value-list-size"
! IPA\-CP attempts to track all possible values and types passed to a function\*(Aqs
  parameter in order to propagate them and perform devirtualization.
! \&\fBipa\-cp\-value\-list\-size\fR is the maximum number of values and types it
  stores per one formal parameter of a function.
! .IP \fBipa\-cp\-eval\-threshold\fR 4
  .IX Item "ipa-cp-eval-threshold"
! IPA\-CP calculates its own score of cloning profitability heuristics
  and performs those cloning opportunities with scores that exceed
! \&\fBipa\-cp\-eval\-threshold\fR.
! .IP \fBipa\-cp\-max\-recursive\-depth\fR 4
  .IX Item "ipa-cp-max-recursive-depth"
! Maximum depth of recursive cloning for self\-recursive function.
! .IP \fBipa\-cp\-min\-recursive\-probability\fR 4
  .IX Item "ipa-cp-min-recursive-probability"
  Recursive cloning only when the probability of call being executed exceeds
  the parameter.
! .IP \fBipa\-cp\-profile\-count\-base\fR 4
  .IX Item "ipa-cp-profile-count-base"
! When using \fB\-fprofile\-use\fR option, IPA\-CP will consider the measured
  execution count of a call graph edge at this percentage position in their
  histogram as the basis for its heuristics calculation.
! .IP \fBipa\-cp\-recursive\-freq\-factor\fR 4
  .IX Item "ipa-cp-recursive-freq-factor"
  The number of times interprocedural copy propagation expects recursive
  functions to call themselves.
! .IP \fBipa\-cp\-recursion\-penalty\fR 4
  .IX Item "ipa-cp-recursion-penalty"
  Percentage penalty the recursive functions will receive when they
  are evaluated for cloning.
! .IP \fBipa\-cp\-single\-call\-penalty\fR 4
  .IX Item "ipa-cp-single-call-penalty"
  Percentage penalty functions containing a single call to another
  function will receive when they are evaluated for cloning.
! .IP \fBipa\-max\-agg\-items\fR 4
  .IX Item "ipa-max-agg-items"
! IPA\-CP is also capable to propagate a number of scalar values passed
! in an aggregate. \fBipa\-max\-agg\-items\fR controls the maximum
  number of such values per one parameter.
! .IP \fBipa\-cp\-loop\-hint\-bonus\fR 4
  .IX Item "ipa-cp-loop-hint-bonus"
! When IPA\-CP determines that a cloning candidate would make the number
  of iterations of a loop known, it adds a bonus of
! \&\fBipa\-cp\-loop\-hint\-bonus\fR to the profitability score of
  the candidate.
! .IP \fBipa\-max\-loop\-predicates\fR 4
  .IX Item "ipa-max-loop-predicates"
! The maximum number of different predicates IPA will use to describe when
  loops in a function have known properties.
! .IP \fBipa\-max\-aa\-steps\fR 4
  .IX Item "ipa-max-aa-steps"
! During its analysis of function bodies, IPA\-CP employs alias analysis
  in order to track values pointed to by function parameters.  In order
  not spend too much time analyzing huge functions, it gives up and
  consider all memory clobbered after examining
! \&\fBipa\-max\-aa\-steps\fR statements modifying memory.
! .IP \fBipa\-max\-switch\-predicate\-bounds\fR 4
  .IX Item "ipa-max-switch-predicate-bounds"
  Maximal number of boundary endpoints of case ranges of switch statement.
! For switch exceeding this limit, IPA\-CP will not construct cloning cost
  predicate, which is used to estimate cloning benefit, for default case
  of the switch statement.
! .IP \fBipa\-max\-param\-expr\-ops\fR 4
  .IX Item "ipa-max-param-expr-ops"
! IPA\-CP will analyze conditional statement that references some function
  parameter to estimate benefit for cloning upon certain constant value.
  But if number of operations in a parameter expression exceeds
! \&\fBipa\-max\-param\-expr\-ops\fR, the expression is treated as complicated
! one, and is not handled by IPA analysis.
! .IP \fBlto\-partitions\fR 4
  .IX Item "lto-partitions"
! Specify desired number of partitions produced during WHOPR compilation.
  The number of partitions should exceed the number of CPUs used for compilation.
! .IP \fBlto\-min\-partition\fR 4
  .IX Item "lto-min-partition"
! Size of minimal partition for WHOPR (in estimated instructions).
  This prevents expenses of splitting very small programs into too many
  partitions.
! .IP \fBlto\-max\-partition\fR 4
  .IX Item "lto-max-partition"
! Size of max partition for WHOPR (in estimated instructions).
  to provide an upper bound for individual size of partition.
  Meant to be used only with balanced partitioning.
! .IP \fBlto\-max\-streaming\-parallelism\fR 4
  .IX Item "lto-max-streaming-parallelism"
! Maximal number of parallel processes used for LTO streaming.
! .IP \fBcxx\-max\-namespaces\-for\-diagnostic\-help\fR 4
  .IX Item "cxx-max-namespaces-for-diagnostic-help"
! The maximum number of namespaces to consult for suggestions when C++
  name lookup fails for an identifier.
! .IP \fBsink\-frequency\-threshold\fR 4
  .IX Item "sink-frequency-threshold"
  The maximum relative execution frequency (in percents) of the target block
! relative to a statement\*(Aqs original block to allow statement sinking of a
  statement.  Larger numbers result in more aggressive statement sinking.
  A small positive adjustment is applied for
  statements with memory operands as those are even more profitable so sink.
! .IP \fBmax\-stores\-to\-sink\fR 4
  .IX Item "max-stores-to-sink"
  The maximum number of conditional store pairs that can be sunk.  Set to 0
! if either vectorization (\fB\-ftree\-vectorize\fR) or if\-conversion
  (\fB\-ftree\-loop\-if\-convert\fR) is disabled.
! .IP \fBcase\-values\-threshold\fR 4
  .IX Item "case-values-threshold"
  The smallest number of different values for which it is best to use a
! jump\-table instead of a tree of conditional branches.  If the value is
  0, use the default for the machine.
! .IP \fBjump\-table\-max\-growth\-ratio\-for\-size\fR 4
  .IX Item "jump-table-max-growth-ratio-for-size"
  The maximum code size growth ratio when expanding
  into a jump table (in percent).  The parameter is used when
  optimizing for size.
! .IP \fBjump\-table\-max\-growth\-ratio\-for\-speed\fR 4
  .IX Item "jump-table-max-growth-ratio-for-speed"
  The maximum code size growth ratio when expanding
  into a jump table (in percent).  The parameter is used when
  optimizing for speed.
! .IP \fBtree\-reassoc\-width\fR 4
  .IX Item "tree-reassoc-width"
  Set the maximum number of instructions executed in parallel in
  reassociated tree. This parameter overrides target dependent
  heuristics used by default if has non zero value.
! .IP \fBsched\-pressure\-algorithm\fR 4
  .IX Item "sched-pressure-algorithm"
  Choose between the two available implementations of
  \&\fB\-fsched\-pressure\fR.  Algorithm 1 is the original implementation
*************** Algorithm 2 was designed to be a comprom
*** 14899,14971 ****
  conservative approach taken by algorithm 1 and the rather aggressive
  approach taken by the default scheduler.  It relies more heavily on
  having a regular register file and accurate register pressure classes.
! See \fIhaifa\-sched.cc\fR in the \s-1GCC\s0 sources for more details.
  .Sp
  The default choice depends on the target.
! .IP "\fBmax-slsr-cand-scan\fR" 4
  .IX Item "max-slsr-cand-scan"
  Set the maximum number of existing candidates that are considered when
! seeking a basis for a new straight-line strength reduction candidate.
! .IP "\fBasan-globals\fR" 4
  .IX Item "asan-globals"
  Enable buffer overflow detection for global objects.  This kind
  of protection is enabled by default if you are using
  \&\fB\-fsanitize=address\fR option.
  To disable global objects protection use \fB\-\-param asan\-globals=0\fR.
! .IP "\fBasan-stack\fR" 4
  .IX Item "asan-stack"
  Enable buffer overflow detection for stack objects.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable stack protection use \fB\-\-param asan\-stack=0\fR option.
! .IP "\fBasan-instrument-reads\fR" 4
  .IX Item "asan-instrument-reads"
  Enable buffer overflow detection for memory reads.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable memory reads protection use
  \&\fB\-\-param asan\-instrument\-reads=0\fR.
! .IP "\fBasan-instrument-writes\fR" 4
  .IX Item "asan-instrument-writes"
  Enable buffer overflow detection for memory writes.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable memory writes protection use
  \&\fB\-\-param asan\-instrument\-writes=0\fR option.
! .IP "\fBasan-memintrin\fR" 4
  .IX Item "asan-memintrin"
! Enable detection for built-in functions.  This kind of protection
  is enabled by default when using \fB\-fsanitize=address\fR.
! To disable built-in functions protection use
  \&\fB\-\-param asan\-memintrin=0\fR.
! .IP "\fBasan-use-after-return\fR" 4
  .IX Item "asan-use-after-return"
! Enable detection of use-after-return.  This kind of protection
  is enabled by default when using the \fB\-fsanitize=address\fR option.
  To disable it use \fB\-\-param asan\-use\-after\-return=0\fR.
  .Sp
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_stack_use_after_return=1\*(C'\fR to the environment variable
! \&\fB\s-1ASAN_OPTIONS\s0\fR.
! .IP "\fBasan-instrumentation-with-call-threshold\fR" 4
  .IX Item "asan-instrumentation-with-call-threshold"
  If number of memory accesses in function being instrumented
  is greater or equal to this number, use callbacks instead of inline checks.
  E.g. to disable inline code use
  \&\fB\-\-param asan\-instrumentation\-with\-call\-threshold=0\fR.
! .IP "\fBasan-kernel-mem-intrinsic-prefix\fR" 4
  .IX Item "asan-kernel-mem-intrinsic-prefix"
  If nonzero, prefix calls to \f(CW\*(C`memcpy\*(C'\fR, \f(CW\*(C`memset\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR
  with \fB_\|_asan_\fR or \fB_\|_hwasan_\fR
  for \fB\-fsanitize=kernel\-address\fR or \fB\-fsanitize=kernel\-hwaddress\fR,
  respectively.
! .IP "\fBhwasan-instrument-stack\fR" 4
  .IX Item "hwasan-instrument-stack"
! Enable hwasan instrumentation of statically sized stack-allocated variables.
  This kind of instrumentation is enabled by default when using
  \&\fB\-fsanitize=hwaddress\fR and disabled by default when using
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable stack instrumentation use
  \&\fB\-\-param hwasan\-instrument\-stack=0\fR, and to enable it use
  \&\fB\-\-param hwasan\-instrument\-stack=1\fR.
! .IP "\fBhwasan-random-frame-tag\fR" 4
  .IX Item "hwasan-random-frame-tag"
  When using stack instrumentation, decide tags for stack variables using a
  deterministic sequence beginning at a random tag for each frame.  With this
--- 14828,14900 ----
  conservative approach taken by algorithm 1 and the rather aggressive
  approach taken by the default scheduler.  It relies more heavily on
  having a regular register file and accurate register pressure classes.
! See \fIhaifa\-sched.cc\fR in the GCC sources for more details.
  .Sp
  The default choice depends on the target.
! .IP \fBmax\-slsr\-cand\-scan\fR 4
  .IX Item "max-slsr-cand-scan"
  Set the maximum number of existing candidates that are considered when
! seeking a basis for a new straight\-line strength reduction candidate.
! .IP \fBasan\-globals\fR 4
  .IX Item "asan-globals"
  Enable buffer overflow detection for global objects.  This kind
  of protection is enabled by default if you are using
  \&\fB\-fsanitize=address\fR option.
  To disable global objects protection use \fB\-\-param asan\-globals=0\fR.
! .IP \fBasan\-stack\fR 4
  .IX Item "asan-stack"
  Enable buffer overflow detection for stack objects.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable stack protection use \fB\-\-param asan\-stack=0\fR option.
! .IP \fBasan\-instrument\-reads\fR 4
  .IX Item "asan-instrument-reads"
  Enable buffer overflow detection for memory reads.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable memory reads protection use
  \&\fB\-\-param asan\-instrument\-reads=0\fR.
! .IP \fBasan\-instrument\-writes\fR 4
  .IX Item "asan-instrument-writes"
  Enable buffer overflow detection for memory writes.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable memory writes protection use
  \&\fB\-\-param asan\-instrument\-writes=0\fR option.
! .IP \fBasan\-memintrin\fR 4
  .IX Item "asan-memintrin"
! Enable detection for built\-in functions.  This kind of protection
  is enabled by default when using \fB\-fsanitize=address\fR.
! To disable built\-in functions protection use
  \&\fB\-\-param asan\-memintrin=0\fR.
! .IP \fBasan\-use\-after\-return\fR 4
  .IX Item "asan-use-after-return"
! Enable detection of use\-after\-return.  This kind of protection
  is enabled by default when using the \fB\-fsanitize=address\fR option.
  To disable it use \fB\-\-param asan\-use\-after\-return=0\fR.
  .Sp
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_stack_use_after_return=1\*(C'\fR to the environment variable
! \&\fBASAN_OPTIONS\fR.
! .IP \fBasan\-instrumentation\-with\-call\-threshold\fR 4
  .IX Item "asan-instrumentation-with-call-threshold"
  If number of memory accesses in function being instrumented
  is greater or equal to this number, use callbacks instead of inline checks.
  E.g. to disable inline code use
  \&\fB\-\-param asan\-instrumentation\-with\-call\-threshold=0\fR.
! .IP \fBasan\-kernel\-mem\-intrinsic\-prefix\fR 4
  .IX Item "asan-kernel-mem-intrinsic-prefix"
  If nonzero, prefix calls to \f(CW\*(C`memcpy\*(C'\fR, \f(CW\*(C`memset\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR
  with \fB_\|_asan_\fR or \fB_\|_hwasan_\fR
  for \fB\-fsanitize=kernel\-address\fR or \fB\-fsanitize=kernel\-hwaddress\fR,
  respectively.
! .IP \fBhwasan\-instrument\-stack\fR 4
  .IX Item "hwasan-instrument-stack"
! Enable hwasan instrumentation of statically sized stack\-allocated variables.
  This kind of instrumentation is enabled by default when using
  \&\fB\-fsanitize=hwaddress\fR and disabled by default when using
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable stack instrumentation use
  \&\fB\-\-param hwasan\-instrument\-stack=0\fR, and to enable it use
  \&\fB\-\-param hwasan\-instrument\-stack=1\fR.
! .IP \fBhwasan\-random\-frame\-tag\fR 4
  .IX Item "hwasan-random-frame-tag"
  When using stack instrumentation, decide tags for stack variables using a
  deterministic sequence beginning at a random tag for each frame.  With this
*************** parameter unset tags are chosen using th
*** 14973,15099 ****
  This is enabled by default for \fB\-fsanitize=hwaddress\fR and unavailable
  for \fB\-fsanitize=kernel\-hwaddress\fR.
  To disable it use \fB\-\-param hwasan\-random\-frame\-tag=0\fR.
! .IP "\fBhwasan-instrument-allocas\fR" 4
  .IX Item "hwasan-instrument-allocas"
! Enable hwasan instrumentation of dynamically sized stack-allocated variables.
  This kind of instrumentation is enabled by default when using
  \&\fB\-fsanitize=hwaddress\fR and disabled by default when using
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable instrumentation of such variables use
  \&\fB\-\-param hwasan\-instrument\-allocas=0\fR, and to enable it use
  \&\fB\-\-param hwasan\-instrument\-allocas=1\fR.
! .IP "\fBhwasan-instrument-reads\fR" 4
  .IX Item "hwasan-instrument-reads"
  Enable hwasan checks on memory reads.  Instrumentation of reads is enabled by
  default for both \fB\-fsanitize=hwaddress\fR and
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable checking memory reads use
  \&\fB\-\-param hwasan\-instrument\-reads=0\fR.
! .IP "\fBhwasan-instrument-writes\fR" 4
  .IX Item "hwasan-instrument-writes"
  Enable hwasan checks on memory writes.  Instrumentation of writes is enabled by
  default for both \fB\-fsanitize=hwaddress\fR and
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable checking memory writes use
  \&\fB\-\-param hwasan\-instrument\-writes=0\fR.
! .IP "\fBhwasan-instrument-mem-intrinsics\fR" 4
  .IX Item "hwasan-instrument-mem-intrinsics"
  Enable hwasan instrumentation of builtin functions.  Instrumentation of these
  builtin functions is enabled by default for both \fB\-fsanitize=hwaddress\fR
  and \fB\-fsanitize=kernel\-hwaddress\fR.
  To disable instrumentation of builtin functions use
  \&\fB\-\-param hwasan\-instrument\-mem\-intrinsics=0\fR.
! .IP "\fBuse-after-scope-direct-emission-threshold\fR" 4
  .IX Item "use-after-scope-direct-emission-threshold"
  If the size of a local variable in bytes is smaller or equal to this
  number, directly poison (or unpoison) shadow memory instead of using
! run-time callbacks.
! .IP "\fBtsan-distinguish-volatile\fR" 4
  .IX Item "tsan-distinguish-volatile"
  Emit special instrumentation for accesses to volatiles.
! .IP "\fBtsan-instrument-func-entry-exit\fR" 4
  .IX Item "tsan-instrument-func-entry-exit"
  Emit instrumentation calls to _\|\fB_tsan_func_entry()\fR and _\|\fB_tsan_func_exit()\fR.
! .IP "\fBmax-fsm-thread-path-insns\fR" 4
  .IX Item "max-fsm-thread-path-insns"
  Maximum number of instructions to copy when duplicating blocks on a
  finite state automaton jump thread path.
! .IP "\fBthreader-debug\fR" 4
  .IX Item "threader-debug"
  threader\-debug=[none|all] Enables verbose dumping of the threader solver.
! .IP "\fBparloops-chunk-size\fR" 4
  .IX Item "parloops-chunk-size"
  Chunk size of omp schedule for loops parallelized by parloops.
! .IP "\fBparloops-schedule\fR" 4
  .IX Item "parloops-schedule"
  Schedule type of omp schedule for loops parallelized by parloops (static,
  dynamic, guided, auto, runtime).
! .IP "\fBparloops-min-per-thread\fR" 4
  .IX Item "parloops-min-per-thread"
  The minimum number of iterations per thread of an innermost parallelized
  loop for which the parallelized variant is preferred over the single threaded
  one.  Note that for a parallelized loop nest the
  minimum number of iterations of the outermost loop per thread is two.
! .IP "\fBmax-ssa-name-query-depth\fR" 4
  .IX Item "max-ssa-name-query-depth"
! Maximum depth of recursion when querying properties of \s-1SSA\s0 names in things
  like fold routines.  One level of recursion corresponds to following a
! use-def chain.
! .IP "\fBmax-speculative-devirt-maydefs\fR" 4
  .IX Item "max-speculative-devirt-maydefs"
! The maximum number of may-defs we analyze when looking for a must-def
  specifying the dynamic type of an object that invokes a virtual call
  we may be able to devirtualize speculatively.
! .IP "\fBevrp-sparse-threshold\fR" 4
  .IX Item "evrp-sparse-threshold"
! Maximum number of basic blocks before \s-1EVRP\s0 uses a sparse cache.
! .IP "\fBranger-debug\fR" 4
  .IX Item "ranger-debug"
  Specifies the type of debug output to be issued for ranges.
! .IP "\fBevrp-switch-limit\fR" 4
  .IX Item "evrp-switch-limit"
! Specifies the maximum number of switch cases before \s-1EVRP\s0 ignores a switch.
! .IP "\fBunroll-jam-min-percent\fR" 4
  .IX Item "unroll-jam-min-percent"
  The minimum percentage of memory references that must be optimized
! away for the unroll-and-jam transformation to be considered profitable.
! .IP "\fBunroll-jam-max-unroll\fR" 4
  .IX Item "unroll-jam-max-unroll"
  The maximum number of times the outer loop should be unrolled by
! the unroll-and-jam transformation.
! .IP "\fBmax-rtl-if-conversion-unpredictable-cost\fR" 4
  .IX Item "max-rtl-if-conversion-unpredictable-cost"
  Maximum permissible cost for the sequence that would be generated
! by the \s-1RTL\s0 if-conversion pass for a branch that is considered unpredictable.
! .IP "\fBmax-variable-expansions-in-unroller\fR" 4
  .IX Item "max-variable-expansions-in-unroller"
  If \fB\-fvariable\-expansion\-in\-unroller\fR is used, the maximum number
  of times that an individual variable will be expanded during loop unrolling.
! .IP "\fBpartial-inlining-entry-probability\fR" 4
  .IX Item "partial-inlining-entry-probability"
! Maximum probability of the entry \s-1BB\s0 of split region
! (in percent relative to entry \s-1BB\s0 of the function)
  to make partial inlining happen.
! .IP "\fBmax-tracked-strlens\fR" 4
  .IX Item "max-tracked-strlens"
  Maximum number of strings for which strlen optimization pass will
  track string lengths.
! .IP "\fBgcse-after-reload-partial-fraction\fR" 4
  .IX Item "gcse-after-reload-partial-fraction"
  The threshold ratio for performing partial redundancy
  elimination after reload.
! .IP "\fBgcse-after-reload-critical-fraction\fR" 4
  .IX Item "gcse-after-reload-critical-fraction"
  The threshold ratio of critical edges execution count that
  permit performing redundancy elimination after reload.
! .IP "\fBmax-loop-header-insns\fR" 4
  .IX Item "max-loop-header-insns"
  The maximum number of insns in loop header duplicated
  by the copy loop headers pass.
! .IP "\fBvect-epilogues-nomask\fR" 4
  .IX Item "vect-epilogues-nomask"
  Enable loop epilogue vectorization using smaller vector size.
! .IP "\fBvect-partial-vector-usage\fR" 4
  .IX Item "vect-partial-vector-usage"
  Controls when the loop vectorizer considers using partial vector loads
  and stores as an alternative to falling back to scalar code.  0 stops
--- 14902,15028 ----
  This is enabled by default for \fB\-fsanitize=hwaddress\fR and unavailable
  for \fB\-fsanitize=kernel\-hwaddress\fR.
  To disable it use \fB\-\-param hwasan\-random\-frame\-tag=0\fR.
! .IP \fBhwasan\-instrument\-allocas\fR 4
  .IX Item "hwasan-instrument-allocas"
! Enable hwasan instrumentation of dynamically sized stack\-allocated variables.
  This kind of instrumentation is enabled by default when using
  \&\fB\-fsanitize=hwaddress\fR and disabled by default when using
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable instrumentation of such variables use
  \&\fB\-\-param hwasan\-instrument\-allocas=0\fR, and to enable it use
  \&\fB\-\-param hwasan\-instrument\-allocas=1\fR.
! .IP \fBhwasan\-instrument\-reads\fR 4
  .IX Item "hwasan-instrument-reads"
  Enable hwasan checks on memory reads.  Instrumentation of reads is enabled by
  default for both \fB\-fsanitize=hwaddress\fR and
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable checking memory reads use
  \&\fB\-\-param hwasan\-instrument\-reads=0\fR.
! .IP \fBhwasan\-instrument\-writes\fR 4
  .IX Item "hwasan-instrument-writes"
  Enable hwasan checks on memory writes.  Instrumentation of writes is enabled by
  default for both \fB\-fsanitize=hwaddress\fR and
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable checking memory writes use
  \&\fB\-\-param hwasan\-instrument\-writes=0\fR.
! .IP \fBhwasan\-instrument\-mem\-intrinsics\fR 4
  .IX Item "hwasan-instrument-mem-intrinsics"
  Enable hwasan instrumentation of builtin functions.  Instrumentation of these
  builtin functions is enabled by default for both \fB\-fsanitize=hwaddress\fR
  and \fB\-fsanitize=kernel\-hwaddress\fR.
  To disable instrumentation of builtin functions use
  \&\fB\-\-param hwasan\-instrument\-mem\-intrinsics=0\fR.
! .IP \fBuse\-after\-scope\-direct\-emission\-threshold\fR 4
  .IX Item "use-after-scope-direct-emission-threshold"
  If the size of a local variable in bytes is smaller or equal to this
  number, directly poison (or unpoison) shadow memory instead of using
! run\-time callbacks.
! .IP \fBtsan\-distinguish\-volatile\fR 4
  .IX Item "tsan-distinguish-volatile"
  Emit special instrumentation for accesses to volatiles.
! .IP \fBtsan\-instrument\-func\-entry\-exit\fR 4
  .IX Item "tsan-instrument-func-entry-exit"
  Emit instrumentation calls to _\|\fB_tsan_func_entry()\fR and _\|\fB_tsan_func_exit()\fR.
! .IP \fBmax\-fsm\-thread\-path\-insns\fR 4
  .IX Item "max-fsm-thread-path-insns"
  Maximum number of instructions to copy when duplicating blocks on a
  finite state automaton jump thread path.
! .IP \fBthreader\-debug\fR 4
  .IX Item "threader-debug"
  threader\-debug=[none|all] Enables verbose dumping of the threader solver.
! .IP \fBparloops\-chunk\-size\fR 4
  .IX Item "parloops-chunk-size"
  Chunk size of omp schedule for loops parallelized by parloops.
! .IP \fBparloops\-schedule\fR 4
  .IX Item "parloops-schedule"
  Schedule type of omp schedule for loops parallelized by parloops (static,
  dynamic, guided, auto, runtime).
! .IP \fBparloops\-min\-per\-thread\fR 4
  .IX Item "parloops-min-per-thread"
  The minimum number of iterations per thread of an innermost parallelized
  loop for which the parallelized variant is preferred over the single threaded
  one.  Note that for a parallelized loop nest the
  minimum number of iterations of the outermost loop per thread is two.
! .IP \fBmax\-ssa\-name\-query\-depth\fR 4
  .IX Item "max-ssa-name-query-depth"
! Maximum depth of recursion when querying properties of SSA names in things
  like fold routines.  One level of recursion corresponds to following a
! use\-def chain.
! .IP \fBmax\-speculative\-devirt\-maydefs\fR 4
  .IX Item "max-speculative-devirt-maydefs"
! The maximum number of may\-defs we analyze when looking for a must\-def
  specifying the dynamic type of an object that invokes a virtual call
  we may be able to devirtualize speculatively.
! .IP \fBevrp\-sparse\-threshold\fR 4
  .IX Item "evrp-sparse-threshold"
! Maximum number of basic blocks before EVRP uses a sparse cache.
! .IP \fBranger\-debug\fR 4
  .IX Item "ranger-debug"
  Specifies the type of debug output to be issued for ranges.
! .IP \fBevrp\-switch\-limit\fR 4
  .IX Item "evrp-switch-limit"
! Specifies the maximum number of switch cases before EVRP ignores a switch.
! .IP \fBunroll\-jam\-min\-percent\fR 4
  .IX Item "unroll-jam-min-percent"
  The minimum percentage of memory references that must be optimized
! away for the unroll\-and\-jam transformation to be considered profitable.
! .IP \fBunroll\-jam\-max\-unroll\fR 4
  .IX Item "unroll-jam-max-unroll"
  The maximum number of times the outer loop should be unrolled by
! the unroll\-and\-jam transformation.
! .IP \fBmax\-rtl\-if\-conversion\-unpredictable\-cost\fR 4
  .IX Item "max-rtl-if-conversion-unpredictable-cost"
  Maximum permissible cost for the sequence that would be generated
! by the RTL if\-conversion pass for a branch that is considered unpredictable.
! .IP \fBmax\-variable\-expansions\-in\-unroller\fR 4
  .IX Item "max-variable-expansions-in-unroller"
  If \fB\-fvariable\-expansion\-in\-unroller\fR is used, the maximum number
  of times that an individual variable will be expanded during loop unrolling.
! .IP \fBpartial\-inlining\-entry\-probability\fR 4
  .IX Item "partial-inlining-entry-probability"
! Maximum probability of the entry BB of split region
! (in percent relative to entry BB of the function)
  to make partial inlining happen.
! .IP \fBmax\-tracked\-strlens\fR 4
  .IX Item "max-tracked-strlens"
  Maximum number of strings for which strlen optimization pass will
  track string lengths.
! .IP \fBgcse\-after\-reload\-partial\-fraction\fR 4
  .IX Item "gcse-after-reload-partial-fraction"
  The threshold ratio for performing partial redundancy
  elimination after reload.
! .IP \fBgcse\-after\-reload\-critical\-fraction\fR 4
  .IX Item "gcse-after-reload-critical-fraction"
  The threshold ratio of critical edges execution count that
  permit performing redundancy elimination after reload.
! .IP \fBmax\-loop\-header\-insns\fR 4
  .IX Item "max-loop-header-insns"
  The maximum number of insns in loop header duplicated
  by the copy loop headers pass.
! .IP \fBvect\-epilogues\-nomask\fR 4
  .IX Item "vect-epilogues-nomask"
  Enable loop epilogue vectorization using smaller vector size.
! .IP \fBvect\-partial\-vector\-usage\fR 4
  .IX Item "vect-partial-vector-usage"
  Controls when the loop vectorizer considers using partial vector loads
  and stores as an alternative to falling back to scalar code.  0 stops
*************** partial vector loads and stores if vecto
*** 15102,15369 ****
  code to iterate.  2 allows partial vector loads and stores in all loops.
  The parameter only has an effect on targets that support partial
  vector loads and stores.
! .IP "\fBvect-inner-loop-cost-factor\fR" 4
  .IX Item "vect-inner-loop-cost-factor"
  The maximum factor which the loop vectorizer applies to the cost of statements
  in an inner loop relative to the loop being vectorized.  The factor applied
  is the maximum of the estimated number of iterations of the inner loop and
  this parameter.  The default value of this parameter is 50.
! .IP "\fBvect-induction-float\fR" 4
  .IX Item "vect-induction-float"
  Enable loop vectorization of floating point inductions.
! .IP "\fBavoid-fma-max-bits\fR" 4
  .IX Item "avoid-fma-max-bits"
  Maximum number of bits for which we avoid creating FMAs.
! .IP "\fBsms-loop-average-count-threshold\fR" 4
  .IX Item "sms-loop-average-count-threshold"
  A threshold on the average loop count considered by the swing modulo scheduler.
! .IP "\fBsms-dfa-history\fR" 4
  .IX Item "sms-dfa-history"
  The number of cycles the swing modulo scheduler considers when checking
! conflicts using \s-1DFA.\s0
! .IP "\fBgraphite-allow-codegen-errors\fR" 4
  .IX Item "graphite-allow-codegen-errors"
  Whether codegen errors should be ICEs when \fB\-fchecking\fR.
! .IP "\fBsms-max-ii-factor\fR" 4
  .IX Item "sms-max-ii-factor"
  A factor for tuning the upper bound that swing modulo scheduler
  uses for scheduling a loop.
! .IP "\fBlra-max-considered-reload-pseudos\fR" 4
  .IX Item "lra-max-considered-reload-pseudos"
  The max number of reload pseudos which are considered during
! spilling a non-reload pseudo.
! .IP "\fBmax-pow-sqrt-depth\fR" 4
  .IX Item "max-pow-sqrt-depth"
  Maximum depth of sqrt chains to use when synthesizing exponentiation
  by a real constant.
! .IP "\fBmax-dse-active-local-stores\fR" 4
  .IX Item "max-dse-active-local-stores"
! Maximum number of active local stores in \s-1RTL\s0 dead store elimination.
! .IP "\fBasan-instrument-allocas\fR" 4
  .IX Item "asan-instrument-allocas"
  Enable asan allocas/VLAs protection.
! .IP "\fBmax-iterations-computation-cost\fR" 4
  .IX Item "max-iterations-computation-cost"
  Bound on the cost of an expression to compute the number of iterations.
! .IP "\fBmax-isl-operations\fR" 4
  .IX Item "max-isl-operations"
  Maximum number of isl operations, 0 means unlimited.
! .IP "\fBgraphite-max-arrays-per-scop\fR" 4
  .IX Item "graphite-max-arrays-per-scop"
  Maximum number of arrays per scop.
! .IP "\fBmax-vartrack-reverse-op-size\fR" 4
  .IX Item "max-vartrack-reverse-op-size"
  Max. size of loc list for which reverse ops should be added.
! .IP "\fBfsm-scale-path-stmts\fR" 4
  .IX Item "fsm-scale-path-stmts"
  Scale factor to apply to the number of statements in a threading path
  crossing a loop backedge when comparing to
  \&\fB\-\-param=max\-jump\-thread\-duplication\-stmts\fR.
! .IP "\fBuninit-control-dep-attempts\fR" 4
  .IX Item "uninit-control-dep-attempts"
  Maximum number of nested calls to search for control dependencies
  during uninitialized variable analysis.
! .IP "\fBuninit-max-chain-len\fR" 4
  .IX Item "uninit-max-chain-len"
  Maximum number of predicates anded for each predicate ored in the normalized
  predicate chain.
! .IP "\fBuninit-max-num-chains\fR" 4
  .IX Item "uninit-max-num-chains"
  Maximum number of predicates ored in the normalized predicate chain.
! .IP "\fBsched-autopref-queue-depth\fR" 4
  .IX Item "sched-autopref-queue-depth"
  Hardware autoprefetcher scheduler model control flag.
! Number of lookahead cycles the model looks into; at '
! \&' only enable instruction sorting heuristic.
! .IP "\fBloop-versioning-max-inner-insns\fR" 4
  .IX Item "loop-versioning-max-inner-insns"
  The maximum number of instructions that an inner loop can have
  before the loop versioning pass considers it too big to copy.
! .IP "\fBloop-versioning-max-outer-insns\fR" 4
  .IX Item "loop-versioning-max-outer-insns"
  The maximum number of instructions that an outer loop can have
  before the loop versioning pass considers it too big to copy,
  discounting any instructions in inner loops that directly benefit
  from versioning.
! .IP "\fBssa-name-def-chain-limit\fR" 4
  .IX Item "ssa-name-def-chain-limit"
! The maximum number of \s-1SSA_NAME\s0 assignments to follow in determining
  a property of a variable such as its value.  This limits the number
! of iterations or recursive calls \s-1GCC\s0 performs when optimizing certain
  statements or when determining their validity prior to issuing
  diagnostics.
! .IP "\fBstore-merging-max-size\fR" 4
  .IX Item "store-merging-max-size"
  Maximum size of a single store merging region in bytes.
! .IP "\fBhash-table-verification-limit\fR" 4
  .IX Item "hash-table-verification-limit"
  The number of elements for which hash table verification is done
  for each searched element.
! .IP "\fBmax-find-base-term-values\fR" 4
  .IX Item "max-find-base-term-values"
  Maximum number of VALUEs handled during a single find_base_term call.
! .IP "\fBanalyzer-max-enodes-per-program-point\fR" 4
  .IX Item "analyzer-max-enodes-per-program-point"
  The maximum number of exploded nodes per program point within
  the analyzer, before terminating analysis of that point.
! .IP "\fBanalyzer-max-constraints\fR" 4
  .IX Item "analyzer-max-constraints"
  The maximum number of constraints per state.
! .IP "\fBanalyzer-min-snodes-for-call-summary\fR" 4
  .IX Item "analyzer-min-snodes-for-call-summary"
  The minimum number of supernodes within a function for the
  analyzer to consider summarizing its effects at call sites.
! .IP "\fBanalyzer-max-enodes-for-full-dump\fR" 4
  .IX Item "analyzer-max-enodes-for-full-dump"
  The maximum depth of exploded nodes that should appear in a dot dump
  before switching to a less verbose format.
! .IP "\fBanalyzer-max-recursion-depth\fR" 4
  .IX Item "analyzer-max-recursion-depth"
  The maximum number of times a callsite can appear in a call stack
  within the analyzer, before terminating analysis of a call that would
  recurse deeper.
! .IP "\fBanalyzer-max-svalue-depth\fR" 4
  .IX Item "analyzer-max-svalue-depth"
  The maximum depth of a symbolic value, before approximating
  the value as unknown.
! .IP "\fBanalyzer-max-infeasible-edges\fR" 4
  .IX Item "analyzer-max-infeasible-edges"
  The maximum number of infeasible edges to reject before declaring
  a diagnostic as infeasible.
! .IP "\fBgimple-fe-computed-hot-bb-threshold\fR" 4
  .IX Item "gimple-fe-computed-hot-bb-threshold"
  The number of executions of a basic block which is considered hot.
! The parameter is used only in \s-1GIMPLE FE.\s0
! .IP "\fBanalyzer-bb-explosion-factor\fR" 4
  .IX Item "analyzer-bb-explosion-factor"
! The maximum number of 'after supernode' exploded nodes within the analyzer
  per supernode, before terminating analysis.
! .IP "\fBranger-logical-depth\fR" 4
  .IX Item "ranger-logical-depth"
  Maximum depth of logical expression evaluation ranger will look through
  when evaluating outgoing edge ranges.
! .IP "\fBranger-recompute-depth\fR" 4
  .IX Item "ranger-recompute-depth"
  Maximum depth of instruction chains to consider for recomputation
  in the outgoing range calculator.
! .IP "\fBrelation-block-limit\fR" 4
  .IX Item "relation-block-limit"
  Maximum number of relations the oracle will register in a basic block.
! .IP "\fBmin-pagesize\fR" 4
  .IX Item "min-pagesize"
  Minimum page size for warning purposes.
! .IP "\fBopenacc-kernels\fR" 4
  .IX Item "openacc-kernels"
! Specify mode of OpenACC `kernels' constructs handling.
! With \fB\-\-param=openacc\-kernels=decompose\fR, OpenACC `kernels'
  constructs are decomposed into parts, a sequence of compute
  constructs, each then handled individually.
  This is work in progress.
! With \fB\-\-param=openacc\-kernels=parloops\fR, OpenACC `kernels'
  constructs are handled by the \fBparloops\fR pass, en bloc.
  This is the current default.
! .IP "\fBopenacc-privatization\fR" 4
  .IX Item "openacc-privatization"
  Control whether the \fB\-fopt\-info\-omp\-note\fR and applicable
  \&\fB\-fdump\-tree\-*\-details\fR options emit OpenACC privatization diagnostics.
! With \fB\-\-param=openacc\-privatization=quiet\fR, don't diagnose.
  This is the current default.
  With \fB\-\-param=openacc\-privatization=noisy\fR, do diagnose.
  .RE
  .RS 4
  .Sp
  The following choices of \fIname\fR are available on AArch64 targets:
! .IP "\fBaarch64\-sve\-compare\-costs\fR" 4
  .IX Item "aarch64-sve-compare-costs"
! When vectorizing for \s-1SVE,\s0 consider using \*(L"unpacked\*(R" vectors for
  smaller elements and use the cost model to pick the cheapest approach.
! Also use the cost model to choose between \s-1SVE\s0 and Advanced \s-1SIMD\s0 vectorization.
  .Sp
  Using unpacked vectors includes storing smaller elements in larger
  containers and accessing elements with extending loads and truncating
  stores.
! .IP "\fBaarch64\-float\-recp\-precision\fR" 4
  .IX Item "aarch64-float-recp-precision"
  The number of Newton iterations for calculating the reciprocal for float type.
  The precision of division is proportional to this param when division
  approximation is enabled.  The default value is 1.
! .IP "\fBaarch64\-double\-recp\-precision\fR" 4
  .IX Item "aarch64-double-recp-precision"
  The number of Newton iterations for calculating the reciprocal for double type.
  The precision of division is propotional to this param when division
  approximation is enabled.  The default value is 2.
! .IP "\fBaarch64\-autovec\-preference\fR" 4
  .IX Item "aarch64-autovec-preference"
! Force an \s-1ISA\s0 selection strategy for auto-vectorization.  Accepts values from
  0 to 4, inclusive.
  .RS 4
! .IP "\fB0\fR" 4
  .IX Item "0"
  Use the default heuristics.
! .IP "\fB1\fR" 4
  .IX Item "1"
! Use only Advanced \s-1SIMD\s0 for auto-vectorization.
! .IP "\fB2\fR" 4
  .IX Item "2"
! Use only \s-1SVE\s0 for auto-vectorization.
! .IP "\fB3\fR" 4
  .IX Item "3"
! Use both Advanced \s-1SIMD\s0 and \s-1SVE.\s0  Prefer Advanced \s-1SIMD\s0 when the costs are
  deemed equal.
! .IP "\fB4\fR" 4
  .IX Item "4"
! Use both Advanced \s-1SIMD\s0 and \s-1SVE.\s0  Prefer \s-1SVE\s0 when the costs are deemed equal.
  .RE
  .RS 4
  .Sp
  The default value is 0.
  .RE
! .IP "\fBaarch64\-loop\-vect\-issue\-rate\-niters\fR" 4
  .IX Item "aarch64-loop-vect-issue-rate-niters"
  The tuning for some AArch64 CPUs tries to take both latencies and issue
  rates into account when deciding whether a loop should be vectorized
! using \s-1SVE,\s0 vectorized using Advanced \s-1SIMD,\s0 or not vectorized at all.
! If this parameter is set to \fIn\fR, \s-1GCC\s0 will not use this heuristic
  for loops that are known to execute in fewer than \fIn\fR Advanced
! \&\s-1SIMD\s0 iterations.
! .IP "\fBaarch64\-vect\-unroll\-limit\fR" 4
  .IX Item "aarch64-vect-unroll-limit"
  The vectorizer will use available tuning information to determine whether it
  would be beneficial to unroll the main vectorized loop and by how much.  This
! parameter set's the upper bound of how much the vectorizer will unroll the main
  loop.  The default value is four.
  .RE
  .RS 4
  .Sp
  The following choices of \fIname\fR are available on i386 and x86_64 targets:
! .IP "\fBx86\-stlf\-window\-ninsns\fR" 4
  .IX Item "x86-stlf-window-ninsns"
! Instructions number above which \s-1STFL\s0 stall penalty can be compensated.
! .IP "\fBx86\-stv\-max\-visits\fR" 4
  .IX Item "x86-stv-max-visits"
! The maximum number of use and def visits when discovering a \s-1STV\s0 chain before
  the discovery is aborted.
  .RE
  .RS 4
  .RE
  .SS "Program Instrumentation Options"
  .IX Subsection "Program Instrumentation Options"
! \&\s-1GCC\s0 supports a number of command-line options that control adding
! run-time instrumentation to the code it normally generates.  
  For example, one purpose of instrumentation is collect profiling
  statistics for use in finding program hot spots, code coverage
! analysis, or profile-guided optimizations.
! Another class of program instrumentation is adding run-time checking 
  to detect programming errors like invalid pointer
! dereferences or out-of-bounds array accesses, as well as deliberately
! hostile attacks such as stack smashing or \*(C+ vtable hijacking.
  There is also a general hook which can be used to implement other
! forms of tracing or function-level instrumentation for debug or
  program analysis purposes.
! .IP "\fB\-p\fR" 4
  .IX Item "-p"
  .PD 0
! .IP "\fB\-pg\fR" 4
  .IX Item "-pg"
  .PD
  Generate extra code to write profile information suitable for the
--- 15031,15298 ----
  code to iterate.  2 allows partial vector loads and stores in all loops.
  The parameter only has an effect on targets that support partial
  vector loads and stores.
! .IP \fBvect\-inner\-loop\-cost\-factor\fR 4
  .IX Item "vect-inner-loop-cost-factor"
  The maximum factor which the loop vectorizer applies to the cost of statements
  in an inner loop relative to the loop being vectorized.  The factor applied
  is the maximum of the estimated number of iterations of the inner loop and
  this parameter.  The default value of this parameter is 50.
! .IP \fBvect\-induction\-float\fR 4
  .IX Item "vect-induction-float"
  Enable loop vectorization of floating point inductions.
! .IP \fBavoid\-fma\-max\-bits\fR 4
  .IX Item "avoid-fma-max-bits"
  Maximum number of bits for which we avoid creating FMAs.
! .IP \fBsms\-loop\-average\-count\-threshold\fR 4
  .IX Item "sms-loop-average-count-threshold"
  A threshold on the average loop count considered by the swing modulo scheduler.
! .IP \fBsms\-dfa\-history\fR 4
  .IX Item "sms-dfa-history"
  The number of cycles the swing modulo scheduler considers when checking
! conflicts using DFA.
! .IP \fBgraphite\-allow\-codegen\-errors\fR 4
  .IX Item "graphite-allow-codegen-errors"
  Whether codegen errors should be ICEs when \fB\-fchecking\fR.
! .IP \fBsms\-max\-ii\-factor\fR 4
  .IX Item "sms-max-ii-factor"
  A factor for tuning the upper bound that swing modulo scheduler
  uses for scheduling a loop.
! .IP \fBlra\-max\-considered\-reload\-pseudos\fR 4
  .IX Item "lra-max-considered-reload-pseudos"
  The max number of reload pseudos which are considered during
! spilling a non\-reload pseudo.
! .IP \fBmax\-pow\-sqrt\-depth\fR 4
  .IX Item "max-pow-sqrt-depth"
  Maximum depth of sqrt chains to use when synthesizing exponentiation
  by a real constant.
! .IP \fBmax\-dse\-active\-local\-stores\fR 4
  .IX Item "max-dse-active-local-stores"
! Maximum number of active local stores in RTL dead store elimination.
! .IP \fBasan\-instrument\-allocas\fR 4
  .IX Item "asan-instrument-allocas"
  Enable asan allocas/VLAs protection.
! .IP \fBmax\-iterations\-computation\-cost\fR 4
  .IX Item "max-iterations-computation-cost"
  Bound on the cost of an expression to compute the number of iterations.
! .IP \fBmax\-isl\-operations\fR 4
  .IX Item "max-isl-operations"
  Maximum number of isl operations, 0 means unlimited.
! .IP \fBgraphite\-max\-arrays\-per\-scop\fR 4
  .IX Item "graphite-max-arrays-per-scop"
  Maximum number of arrays per scop.
! .IP \fBmax\-vartrack\-reverse\-op\-size\fR 4
  .IX Item "max-vartrack-reverse-op-size"
  Max. size of loc list for which reverse ops should be added.
! .IP \fBfsm\-scale\-path\-stmts\fR 4
  .IX Item "fsm-scale-path-stmts"
  Scale factor to apply to the number of statements in a threading path
  crossing a loop backedge when comparing to
  \&\fB\-\-param=max\-jump\-thread\-duplication\-stmts\fR.
! .IP \fBuninit\-control\-dep\-attempts\fR 4
  .IX Item "uninit-control-dep-attempts"
  Maximum number of nested calls to search for control dependencies
  during uninitialized variable analysis.
! .IP \fBuninit\-max\-chain\-len\fR 4
  .IX Item "uninit-max-chain-len"
  Maximum number of predicates anded for each predicate ored in the normalized
  predicate chain.
! .IP \fBuninit\-max\-num\-chains\fR 4
  .IX Item "uninit-max-num-chains"
  Maximum number of predicates ored in the normalized predicate chain.
! .IP \fBsched\-autopref\-queue\-depth\fR 4
  .IX Item "sched-autopref-queue-depth"
  Hardware autoprefetcher scheduler model control flag.
! Number of lookahead cycles the model looks into; at \*(Aq
! \&\*(Aq only enable instruction sorting heuristic.
! .IP \fBloop\-versioning\-max\-inner\-insns\fR 4
  .IX Item "loop-versioning-max-inner-insns"
  The maximum number of instructions that an inner loop can have
  before the loop versioning pass considers it too big to copy.
! .IP \fBloop\-versioning\-max\-outer\-insns\fR 4
  .IX Item "loop-versioning-max-outer-insns"
  The maximum number of instructions that an outer loop can have
  before the loop versioning pass considers it too big to copy,
  discounting any instructions in inner loops that directly benefit
  from versioning.
! .IP \fBssa\-name\-def\-chain\-limit\fR 4
  .IX Item "ssa-name-def-chain-limit"
! The maximum number of SSA_NAME assignments to follow in determining
  a property of a variable such as its value.  This limits the number
! of iterations or recursive calls GCC performs when optimizing certain
  statements or when determining their validity prior to issuing
  diagnostics.
! .IP \fBstore\-merging\-max\-size\fR 4
  .IX Item "store-merging-max-size"
  Maximum size of a single store merging region in bytes.
! .IP \fBhash\-table\-verification\-limit\fR 4
  .IX Item "hash-table-verification-limit"
  The number of elements for which hash table verification is done
  for each searched element.
! .IP \fBmax\-find\-base\-term\-values\fR 4
  .IX Item "max-find-base-term-values"
  Maximum number of VALUEs handled during a single find_base_term call.
! .IP \fBanalyzer\-max\-enodes\-per\-program\-point\fR 4
  .IX Item "analyzer-max-enodes-per-program-point"
  The maximum number of exploded nodes per program point within
  the analyzer, before terminating analysis of that point.
! .IP \fBanalyzer\-max\-constraints\fR 4
  .IX Item "analyzer-max-constraints"
  The maximum number of constraints per state.
! .IP \fBanalyzer\-min\-snodes\-for\-call\-summary\fR 4
  .IX Item "analyzer-min-snodes-for-call-summary"
  The minimum number of supernodes within a function for the
  analyzer to consider summarizing its effects at call sites.
! .IP \fBanalyzer\-max\-enodes\-for\-full\-dump\fR 4
  .IX Item "analyzer-max-enodes-for-full-dump"
  The maximum depth of exploded nodes that should appear in a dot dump
  before switching to a less verbose format.
! .IP \fBanalyzer\-max\-recursion\-depth\fR 4
  .IX Item "analyzer-max-recursion-depth"
  The maximum number of times a callsite can appear in a call stack
  within the analyzer, before terminating analysis of a call that would
  recurse deeper.
! .IP \fBanalyzer\-max\-svalue\-depth\fR 4
  .IX Item "analyzer-max-svalue-depth"
  The maximum depth of a symbolic value, before approximating
  the value as unknown.
! .IP \fBanalyzer\-max\-infeasible\-edges\fR 4
  .IX Item "analyzer-max-infeasible-edges"
  The maximum number of infeasible edges to reject before declaring
  a diagnostic as infeasible.
! .IP \fBgimple\-fe\-computed\-hot\-bb\-threshold\fR 4
  .IX Item "gimple-fe-computed-hot-bb-threshold"
  The number of executions of a basic block which is considered hot.
! The parameter is used only in GIMPLE FE.
! .IP \fBanalyzer\-bb\-explosion\-factor\fR 4
  .IX Item "analyzer-bb-explosion-factor"
! The maximum number of \*(Aqafter supernode\*(Aq exploded nodes within the analyzer
  per supernode, before terminating analysis.
! .IP \fBranger\-logical\-depth\fR 4
  .IX Item "ranger-logical-depth"
  Maximum depth of logical expression evaluation ranger will look through
  when evaluating outgoing edge ranges.
! .IP \fBranger\-recompute\-depth\fR 4
  .IX Item "ranger-recompute-depth"
  Maximum depth of instruction chains to consider for recomputation
  in the outgoing range calculator.
! .IP \fBrelation\-block\-limit\fR 4
  .IX Item "relation-block-limit"
  Maximum number of relations the oracle will register in a basic block.
! .IP \fBmin\-pagesize\fR 4
  .IX Item "min-pagesize"
  Minimum page size for warning purposes.
! .IP \fBopenacc\-kernels\fR 4
  .IX Item "openacc-kernels"
! Specify mode of OpenACC \`kernels\*(Aq constructs handling.
! With \fB\-\-param=openacc\-kernels=decompose\fR, OpenACC \`kernels\*(Aq
  constructs are decomposed into parts, a sequence of compute
  constructs, each then handled individually.
  This is work in progress.
! With \fB\-\-param=openacc\-kernels=parloops\fR, OpenACC \`kernels\*(Aq
  constructs are handled by the \fBparloops\fR pass, en bloc.
  This is the current default.
! .IP \fBopenacc\-privatization\fR 4
  .IX Item "openacc-privatization"
  Control whether the \fB\-fopt\-info\-omp\-note\fR and applicable
  \&\fB\-fdump\-tree\-*\-details\fR options emit OpenACC privatization diagnostics.
! With \fB\-\-param=openacc\-privatization=quiet\fR, don\*(Aqt diagnose.
  This is the current default.
  With \fB\-\-param=openacc\-privatization=noisy\fR, do diagnose.
  .RE
  .RS 4
  .Sp
  The following choices of \fIname\fR are available on AArch64 targets:
! .IP \fBaarch64\-sve\-compare\-costs\fR 4
  .IX Item "aarch64-sve-compare-costs"
! When vectorizing for SVE, consider using "unpacked" vectors for
  smaller elements and use the cost model to pick the cheapest approach.
! Also use the cost model to choose between SVE and Advanced SIMD vectorization.
  .Sp
  Using unpacked vectors includes storing smaller elements in larger
  containers and accessing elements with extending loads and truncating
  stores.
! .IP \fBaarch64\-float\-recp\-precision\fR 4
  .IX Item "aarch64-float-recp-precision"
  The number of Newton iterations for calculating the reciprocal for float type.
  The precision of division is proportional to this param when division
  approximation is enabled.  The default value is 1.
! .IP \fBaarch64\-double\-recp\-precision\fR 4
  .IX Item "aarch64-double-recp-precision"
  The number of Newton iterations for calculating the reciprocal for double type.
  The precision of division is propotional to this param when division
  approximation is enabled.  The default value is 2.
! .IP \fBaarch64\-autovec\-preference\fR 4
  .IX Item "aarch64-autovec-preference"
! Force an ISA selection strategy for auto\-vectorization.  Accepts values from
  0 to 4, inclusive.
  .RS 4
! .IP \fB0\fR 4
  .IX Item "0"
  Use the default heuristics.
! .IP \fB1\fR 4
  .IX Item "1"
! Use only Advanced SIMD for auto\-vectorization.
! .IP \fB2\fR 4
  .IX Item "2"
! Use only SVE for auto\-vectorization.
! .IP \fB3\fR 4
  .IX Item "3"
! Use both Advanced SIMD and SVE.  Prefer Advanced SIMD when the costs are
  deemed equal.
! .IP \fB4\fR 4
  .IX Item "4"
! Use both Advanced SIMD and SVE.  Prefer SVE when the costs are deemed equal.
  .RE
  .RS 4
  .Sp
  The default value is 0.
  .RE
! .IP \fBaarch64\-loop\-vect\-issue\-rate\-niters\fR 4
  .IX Item "aarch64-loop-vect-issue-rate-niters"
  The tuning for some AArch64 CPUs tries to take both latencies and issue
  rates into account when deciding whether a loop should be vectorized
! using SVE, vectorized using Advanced SIMD, or not vectorized at all.
! If this parameter is set to \fIn\fR, GCC will not use this heuristic
  for loops that are known to execute in fewer than \fIn\fR Advanced
! SIMD iterations.
! .IP \fBaarch64\-vect\-unroll\-limit\fR 4
  .IX Item "aarch64-vect-unroll-limit"
  The vectorizer will use available tuning information to determine whether it
  would be beneficial to unroll the main vectorized loop and by how much.  This
! parameter set\*(Aqs the upper bound of how much the vectorizer will unroll the main
  loop.  The default value is four.
  .RE
  .RS 4
  .Sp
  The following choices of \fIname\fR are available on i386 and x86_64 targets:
! .IP \fBx86\-stlf\-window\-ninsns\fR 4
  .IX Item "x86-stlf-window-ninsns"
! Instructions number above which STFL stall penalty can be compensated.
! .IP \fBx86\-stv\-max\-visits\fR 4
  .IX Item "x86-stv-max-visits"
! The maximum number of use and def visits when discovering a STV chain before
  the discovery is aborted.
  .RE
  .RS 4
  .RE
  .SS "Program Instrumentation Options"
  .IX Subsection "Program Instrumentation Options"
! GCC supports a number of command\-line options that control adding
! run\-time instrumentation to the code it normally generates.  
  For example, one purpose of instrumentation is collect profiling
  statistics for use in finding program hot spots, code coverage
! analysis, or profile\-guided optimizations.
! Another class of program instrumentation is adding run\-time checking 
  to detect programming errors like invalid pointer
! dereferences or out\-of\-bounds array accesses, as well as deliberately
! hostile attacks such as stack smashing or C++ vtable hijacking.
  There is also a general hook which can be used to implement other
! forms of tracing or function\-level instrumentation for debug or
  program analysis purposes.
! .IP \fB\-p\fR 4
  .IX Item "-p"
  .PD 0
! .IP \fB\-pg\fR 4
  .IX Item "-pg"
  .PD
  Generate extra code to write profile information suitable for the
*************** linking.
*** 15374,15393 ****
  .Sp
  You can use the function attribute \f(CW\*(C`no_instrument_function\*(C'\fR to
  suppress profiling of individual functions when compiling with these options.
! .IP "\fB\-fprofile\-arcs\fR" 4
  .IX Item "-fprofile-arcs"
  Add code so that program flow \fIarcs\fR are instrumented.  During
  execution the program records how many times each branch and call is
  executed and how many times it is taken or returns.  On targets that support
  constructors with priority support, profiling properly handles constructors,
! destructors and \*(C+ constructors (and destructors) of classes which are used
  as a type of a global variable.
  .Sp
  When the compiled
  program exits it saves this data to a file called
! \&\fI\fIauxname\fI.gcda\fR for each source file.  The data may be used for
! profile-directed optimizations (\fB\-fbranch\-probabilities\fR), or for
! test coverage analysis (\fB\-ftest\-coverage\fR).  Each object file's
  \&\fIauxname\fR is generated from the name of the output file, if
  explicitly specified and it is not the final executable, otherwise it is
  the basename of the source file.  In both cases any suffix is removed
--- 15303,15322 ----
  .Sp
  You can use the function attribute \f(CW\*(C`no_instrument_function\*(C'\fR to
  suppress profiling of individual functions when compiling with these options.
! .IP \fB\-fprofile\-arcs\fR 4
  .IX Item "-fprofile-arcs"
  Add code so that program flow \fIarcs\fR are instrumented.  During
  execution the program records how many times each branch and call is
  executed and how many times it is taken or returns.  On targets that support
  constructors with priority support, profiling properly handles constructors,
! destructors and C++ constructors (and destructors) of classes which are used
  as a type of a global variable.
  .Sp
  When the compiled
  program exits it saves this data to a file called
! \&\fIauxname.gcda\fR for each source file.  The data may be used for
! profile\-directed optimizations (\fB\-fbranch\-probabilities\fR), or for
! test coverage analysis (\fB\-ftest\-coverage\fR).  Each object file\*(Aqs
  \&\fIauxname\fR is generated from the name of the output file, if
  explicitly specified and it is not the final executable, otherwise it is
  the basename of the source file.  In both cases any suffix is removed
*************** Note that if a command line directly lin
*** 15398,15446 ****
  \&\fI.gcda\fR files will be prefixed with the unsuffixed name of the output file.
  E.g. \f(CW\*(C`gcc a.c b.c \-o binary\*(C'\fR would generate \fIbinary\-a.gcda\fR and
  \&\fIbinary\-b.gcda\fR files.
! .IP "\fB\-\-coverage\fR" 4
  .IX Item "--coverage"
  This option is used to compile and link code instrumented for coverage
  analysis.  The option is a synonym for \fB\-fprofile\-arcs\fR
  \&\fB\-ftest\-coverage\fR (when compiling) and \fB\-lgcov\fR (when
  linking).  See the documentation for those options for more details.
  .RS 4
! .IP "*" 4
  Compile the source files with \fB\-fprofile\-arcs\fR plus optimization
  and code generation options.  For test coverage analysis, use the
  additional \fB\-ftest\-coverage\fR option.  You do not need to profile
  every source file in a program.
! .IP "*" 4
  Compile the source files additionally with \fB\-fprofile\-abs\-path\fR
  to create absolute path names in the \fI.gcno\fR files.  This allows
  \&\fBgcov\fR to find the correct sources in projects where compilations
  occur with different working directories.
! .IP "*" 4
  Link your object files with \fB\-lgcov\fR or \fB\-fprofile\-arcs\fR
  (the latter implies the former).
! .IP "*" 4
  Run the program on a representative workload to generate the arc profile
  information.  This may be repeated any number of times.  You can run
  concurrent instances of your program, and provided that the file system
  supports locking, the data files will be correctly updated.  Unless
! a strict \s-1ISO C\s0 dialect option is in effect, \f(CW\*(C`fork\*(C'\fR calls are
  detected and correctly handled without double counting.
  .Sp
  Moreover, an object file can be recompiled multiple times
  and the corresponding \fI.gcda\fR file merges as long as
  the source file and the compiler options are unchanged.
! .IP "*" 4
! For profile-directed optimizations, compile the source files again with
  the same optimization and code generation options plus
  \&\fB\-fbranch\-probabilities\fR.
! .IP "*" 4
  For test coverage analysis, use \fBgcov\fR to produce human readable
  information from the \fI.gcno\fR and \fI.gcda\fR files.  Refer to the
  \&\fBgcov\fR documentation for further information.
  .RE
  .RS 4
  .Sp
! With \fB\-fprofile\-arcs\fR, for each function of your program \s-1GCC\s0
  creates a program flow graph, then finds a spanning tree for the graph.
  Only arcs that are not on the spanning tree have to be instrumented: the
  compiler adds code to count the number of times that these arcs are
--- 15327,15375 ----
  \&\fI.gcda\fR files will be prefixed with the unsuffixed name of the output file.
  E.g. \f(CW\*(C`gcc a.c b.c \-o binary\*(C'\fR would generate \fIbinary\-a.gcda\fR and
  \&\fIbinary\-b.gcda\fR files.
! .IP \fB\-\-coverage\fR 4
  .IX Item "--coverage"
  This option is used to compile and link code instrumented for coverage
  analysis.  The option is a synonym for \fB\-fprofile\-arcs\fR
  \&\fB\-ftest\-coverage\fR (when compiling) and \fB\-lgcov\fR (when
  linking).  See the documentation for those options for more details.
  .RS 4
! .IP * 4
  Compile the source files with \fB\-fprofile\-arcs\fR plus optimization
  and code generation options.  For test coverage analysis, use the
  additional \fB\-ftest\-coverage\fR option.  You do not need to profile
  every source file in a program.
! .IP * 4
  Compile the source files additionally with \fB\-fprofile\-abs\-path\fR
  to create absolute path names in the \fI.gcno\fR files.  This allows
  \&\fBgcov\fR to find the correct sources in projects where compilations
  occur with different working directories.
! .IP * 4
  Link your object files with \fB\-lgcov\fR or \fB\-fprofile\-arcs\fR
  (the latter implies the former).
! .IP * 4
  Run the program on a representative workload to generate the arc profile
  information.  This may be repeated any number of times.  You can run
  concurrent instances of your program, and provided that the file system
  supports locking, the data files will be correctly updated.  Unless
! a strict ISO C dialect option is in effect, \f(CW\*(C`fork\*(C'\fR calls are
  detected and correctly handled without double counting.
  .Sp
  Moreover, an object file can be recompiled multiple times
  and the corresponding \fI.gcda\fR file merges as long as
  the source file and the compiler options are unchanged.
! .IP * 4
! For profile\-directed optimizations, compile the source files again with
  the same optimization and code generation options plus
  \&\fB\-fbranch\-probabilities\fR.
! .IP * 4
  For test coverage analysis, use \fBgcov\fR to produce human readable
  information from the \fI.gcno\fR and \fI.gcda\fR files.  Refer to the
  \&\fBgcov\fR documentation for further information.
  .RE
  .RS 4
  .Sp
! With \fB\-fprofile\-arcs\fR, for each function of your program 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
*** 15448,15499 ****
  instrumentation code can be added to the block; otherwise, a new basic
  block must be created to hold the instrumentation code.
  .RE
! .IP "\fB\-ftest\-coverage\fR" 4
  .IX Item "-ftest-coverage"
! Produce a notes file that the \fBgcov\fR code-coverage utility can use to
! show program coverage.  Each source file's note file is called
! \&\fI\fIauxname\fI.gcno\fR.  Refer to the \fB\-fprofile\-arcs\fR option
  above for a description of \fIauxname\fR and instructions on how to
  generate test coverage data.  Coverage data matches the source files
  more closely if you do not optimize.
! .IP "\fB\-fprofile\-abs\-path\fR" 4
  .IX Item "-fprofile-abs-path"
  Automatically convert relative source file names to absolute path names
  in the \fI.gcno\fR files.  This allows \fBgcov\fR to find the correct
  sources in projects where compilations occur with different working
  directories.
! .IP "\fB\-fprofile\-dir=\fR\fIpath\fR" 4
  .IX Item "-fprofile-dir=path"
  Set the directory to search for the profile data files in to \fIpath\fR.
  This option affects only the profile data generated by
  \&\fB\-fprofile\-generate\fR, \fB\-ftest\-coverage\fR, \fB\-fprofile\-arcs\fR
  and used by \fB\-fprofile\-use\fR and \fB\-fbranch\-probabilities\fR
  and its related options.  Both absolute and relative paths can be used.
! By default, \s-1GCC\s0 uses the current directory as \fIpath\fR, thus the
  profile data file appears in the same directory as the object file.
  In order to prevent the file name clashing, if the object file name is
  not an absolute path, we mangle the absolute path of the
! \&\fI\fIsourcename\fI.gcda\fR file and use it as the file name of a
  \&\fI.gcda\fR file.  See details about the file naming in \fB\-fprofile\-arcs\fR.
  See similar option \fB\-fprofile\-note\fR.
  .Sp
  When an executable is run in a massive parallel environment, it is recommended
  to save profile to different folders.  That can be done with variables
! in \fIpath\fR that are exported during run-time:
  .RS 4
! .IP "\fB\f(CB%p\fB\fR" 4
  .IX Item "%p"
! process \s-1ID.\s0
! .IP "\fB\f(CB%q\fB{\s-1VAR\s0}\fR" 4
  .IX Item "%q{VAR}"
! value of environment variable \fI\s-1VAR\s0\fR
  .RE
  .RS 4
  .RE
! .IP "\fB\-fprofile\-generate\fR" 4
  .IX Item "-fprofile-generate"
  .PD 0
! .IP "\fB\-fprofile\-generate=\fR\fIpath\fR" 4
  .IX Item "-fprofile-generate=path"
  .PD
  Enable options usually used for instrumenting application to produce
--- 15377,15430 ----
  instrumentation code can be added to the block; otherwise, a new basic
  block must be created to hold the instrumentation code.
  .RE
! .IP \fB\-ftest\-coverage\fR 4
  .IX Item "-ftest-coverage"
! Produce a notes file that the \fBgcov\fR code\-coverage utility can use to
! show program coverage.  Each source file\*(Aqs note file is called
! \&\fIauxname.gcno\fR.  Refer to the \fB\-fprofile\-arcs\fR option
  above for a description of \fIauxname\fR and instructions on how to
  generate test coverage data.  Coverage data matches the source files
  more closely if you do not optimize.
! .IP \fB\-fprofile\-abs\-path\fR 4
  .IX Item "-fprofile-abs-path"
  Automatically convert relative source file names to absolute path names
  in the \fI.gcno\fR files.  This allows \fBgcov\fR to find the correct
  sources in projects where compilations occur with different working
  directories.
! .IP \fB\-fprofile\-dir=\fR\fIpath\fR 4
  .IX Item "-fprofile-dir=path"
  Set the directory to search for the profile data files in to \fIpath\fR.
  This option affects only the profile data generated by
  \&\fB\-fprofile\-generate\fR, \fB\-ftest\-coverage\fR, \fB\-fprofile\-arcs\fR
  and used by \fB\-fprofile\-use\fR and \fB\-fbranch\-probabilities\fR
  and its related options.  Both absolute and relative paths can be used.
! By default, GCC uses the current directory as \fIpath\fR, thus the
  profile data file appears in the same directory as the object file.
  In order to prevent the file name clashing, if the object file name is
  not an absolute path, we mangle the absolute path of the
! \&\fIsourcename.gcda\fR file and use it as the file name of a
  \&\fI.gcda\fR file.  See details about the file naming in \fB\-fprofile\-arcs\fR.
  See similar option \fB\-fprofile\-note\fR.
  .Sp
  When an executable is run in a massive parallel environment, it is recommended
  to save profile to different folders.  That can be done with variables
! in \fIpath\fR that are exported during run\-time:
  .RS 4
! .ie n .IP \fR\fB%p\fR\fB\fR 4
! .el .IP \fR\f(CB%p\fR\fB\fR 4
  .IX Item "%p"
! process ID.
! .ie n .IP \fR\fB%q\fR\fB{VAR}\fR 4
! .el .IP \fR\f(CB%q\fR\fB{VAR}\fR 4
  .IX Item "%q{VAR}"
! value of environment variable \fIVAR\fR
  .RE
  .RS 4
  .RE
! .IP \fB\-fprofile\-generate\fR 4
  .IX Item "-fprofile-generate"
  .PD 0
! .IP \fB\-fprofile\-generate=\fR\fIpath\fR 4
  .IX Item "-fprofile-generate=path"
  .PD
  Enable options usually used for instrumenting application to produce
*************** The following options are enabled:
*** 15505,15519 ****
  \&\fB\-fprofile\-arcs\fR, \fB\-fprofile\-values\fR,
  \&\fB\-finline\-functions\fR, and \fB\-fipa\-bit\-cp\fR.
  .Sp
! If \fIpath\fR is specified, \s-1GCC\s0 looks at the \fIpath\fR to find
  the profile feedback data files. See \fB\-fprofile\-dir\fR.
  .Sp
  To optimize the program based on the collected profile information, use
  \&\fB\-fprofile\-use\fR.
! .IP "\fB\-fprofile\-info\-section\fR" 4
  .IX Item "-fprofile-info-section"
  .PD 0
! .IP "\fB\-fprofile\-info\-section=\fR\fIname\fR" 4
  .IX Item "-fprofile-info-section=name"
  .PD
  Register the profile information in the specified section instead of using a
--- 15436,15450 ----
  \&\fB\-fprofile\-arcs\fR, \fB\-fprofile\-values\fR,
  \&\fB\-finline\-functions\fR, and \fB\-fipa\-bit\-cp\fR.
  .Sp
! If \fIpath\fR is specified, GCC looks at the \fIpath\fR to find
  the profile feedback data files. See \fB\-fprofile\-dir\fR.
  .Sp
  To optimize the program based on the collected profile information, use
  \&\fB\-fprofile\-use\fR.
! .IP \fB\-fprofile\-info\-section\fR 4
  .IX Item "-fprofile-info-section"
  .PD 0
! .IP \fB\-fprofile\-info\-section=\fR\fIname\fR 4
  .IX Item "-fprofile-info-section=name"
  .PD
  Register the profile information in the specified section instead of using a
*************** environments (for example embedded syste
*** 15528,15534 ****
  support constructors/destructors or the C library file I/O.
  .Sp
  The linker could collect the input sections in a continuous memory block and
! define start and end symbols.  A \s-1GNU\s0 linker script example which defines a
  linker output section follows:
  .Sp
  .Vb 6
--- 15459,15465 ----
  support constructors/destructors or the C library file I/O.
  .Sp
  The linker could collect the input sections in a continuous memory block and
! define start and end symbols.  A GNU linker script example which defines a
  linker output section follows:
  .Sp
  .Vb 6
*************** for example like this:
*** 15598,15617 ****
  \&        }
  .Ve
  .Sp
! The \fBmerge-stream\fR subcommand of \fBgcov-tool\fR may be used to
  deserialize the data stream generated by the \f(CW\*(C`_\|_gcov_filename_to_gcfn\*(C'\fR and
  \&\f(CW\*(C`_\|_gcov_info_to_gcda\*(C'\fR functions and merge the profile information into
  \&\fI.gcda\fR files on the host filesystem.
! .IP "\fB\-fprofile\-note=\fR\fIpath\fR" 4
  .IX Item "-fprofile-note=path"
! If \fIpath\fR is specified, \s-1GCC\s0 saves \fI.gcno\fR file into \fIpath\fR
  location.  If you combine the option with multiple source files,
  the \fI.gcno\fR file will be overwritten.
! .IP "\fB\-fprofile\-prefix\-path=\fR\fIpath\fR" 4
  .IX Item "-fprofile-prefix-path=path"
  This option can be used in combination with
  \&\fBprofile\-generate=\fR\fIprofile_dir\fR and
! \&\fBprofile\-use=\fR\fIprofile_dir\fR to inform \s-1GCC\s0 where is the base
  directory of built source tree.  By default \fIprofile_dir\fR will contain
  files with mangled absolute paths of all object files in the built project.
  This is not desirable when directory used to build the instrumented binary
--- 15529,15548 ----
  \&        }
  .Ve
  .Sp
! The \fBmerge\-stream\fR subcommand of \fBgcov\-tool\fR may be used to
  deserialize the data stream generated by the \f(CW\*(C`_\|_gcov_filename_to_gcfn\*(C'\fR and
  \&\f(CW\*(C`_\|_gcov_info_to_gcda\*(C'\fR functions and merge the profile information into
  \&\fI.gcda\fR files on the host filesystem.
! .IP \fB\-fprofile\-note=\fR\fIpath\fR 4
  .IX Item "-fprofile-note=path"
! If \fIpath\fR is specified, GCC saves \fI.gcno\fR file into \fIpath\fR
  location.  If you combine the option with multiple source files,
  the \fI.gcno\fR file will be overwritten.
! .IP \fB\-fprofile\-prefix\-path=\fR\fIpath\fR 4
  .IX Item "-fprofile-prefix-path=path"
  This option can be used in combination with
  \&\fBprofile\-generate=\fR\fIprofile_dir\fR and
! \&\fBprofile\-use=\fR\fIprofile_dir\fR to inform GCC where is the base
  directory of built source tree.  By default \fIprofile_dir\fR will contain
  files with mangled absolute paths of all object files in the built project.
  This is not desirable when directory used to build the instrumented binary
*************** feedback because the profile data will n
*** 15620,15662 ****
  In such setups \fB\-fprofile\-prefix\-path=\fR\fIpath\fR with \fIpath\fR
  pointing to the base directory of the build can be used to strip the irrelevant
  part of the path and keep all file names relative to the main build directory.
! .IP "\fB\-fprofile\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
  .IX Item "-fprofile-prefix-map=old=new"
! When compiling files residing in directory \fI\fIold\fI\fR, record
  profiling information (with \fB\-\-coverage\fR)
  describing them as if the files resided in
! directory \fI\fInew\fI\fR instead.
  See also \fB\-ffile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP "\fB\-fprofile\-update=\fR\fImethod\fR" 4
  .IX Item "-fprofile-update=method"
  Alter the update method for an application instrumented for profile
  feedback based optimization.  The \fImethod\fR argument should be one of
! \&\fBsingle\fR, \fBatomic\fR or \fBprefer-atomic\fR.
! The first one is useful for single-threaded applications,
! while the second one prevents profile corruption by emitting thread-safe code.
  .Sp
  \&\fBWarning:\fR When an application does not properly join all threads
  (or creates an detached thread), a profile file can be still corrupted.
  .Sp
! Using \fBprefer-atomic\fR would be transformed either to \fBatomic\fR,
! when supported by a target, or to \fBsingle\fR otherwise.  The \s-1GCC\s0 driver
! automatically selects \fBprefer-atomic\fR when \fB\-pthread\fR
  is present in the command line.
! .IP "\fB\-fprofile\-filter\-files=\fR\fIregex\fR" 4
  .IX Item "-fprofile-filter-files=regex"
  Instrument only functions from files whose name matches
! any of the regular expressions (separated by semi-colons).
  .Sp
  For example, \fB\-fprofile\-filter\-files=main\e.c;module.*\e.c\fR will instrument
! only \fImain.c\fR and all C files starting with 'module'.
! .IP "\fB\-fprofile\-exclude\-files=\fR\fIregex\fR" 4
  .IX Item "-fprofile-exclude-files=regex"
  Instrument only functions from files whose name does not match
! any of the regular expressions (separated by semi-colons).
  .Sp
  For example, \fB\-fprofile\-exclude\-files=/usr/.*\fR will prevent instrumentation
  of all files that are located in the \fI/usr/\fR folder.
! .IP "\fB\-fprofile\-reproducible=\fR[\fBmultithreaded\fR|\fBparallel-runs\fR|\fBserial\fR]" 4
  .IX Item "-fprofile-reproducible=[multithreaded|parallel-runs|serial]"
  Control level of reproducibility of profile gathered by
  \&\f(CW\*(C`\-fprofile\-generate\*(C'\fR.  This makes it possible to rebuild program
--- 15551,15593 ----
  In such setups \fB\-fprofile\-prefix\-path=\fR\fIpath\fR with \fIpath\fR
  pointing to the base directory of the build can be used to strip the irrelevant
  part of the path and keep all file names relative to the main build directory.
! .IP \fB\-fprofile\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 4
  .IX Item "-fprofile-prefix-map=old=new"
! When compiling files residing in directory \fIold\fR, record
  profiling information (with \fB\-\-coverage\fR)
  describing them as if the files resided in
! directory \fInew\fR instead.
  See also \fB\-ffile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP \fB\-fprofile\-update=\fR\fImethod\fR 4
  .IX Item "-fprofile-update=method"
  Alter the update method for an application instrumented for profile
  feedback based optimization.  The \fImethod\fR argument should be one of
! \&\fBsingle\fR, \fBatomic\fR or \fBprefer\-atomic\fR.
! The first one is useful for single\-threaded applications,
! while the second one prevents profile corruption by emitting thread\-safe code.
  .Sp
  \&\fBWarning:\fR When an application does not properly join all threads
  (or creates an detached thread), a profile file can be still corrupted.
  .Sp
! Using \fBprefer\-atomic\fR would be transformed either to \fBatomic\fR,
! when supported by a target, or to \fBsingle\fR otherwise.  The GCC driver
! automatically selects \fBprefer\-atomic\fR when \fB\-pthread\fR
  is present in the command line.
! .IP \fB\-fprofile\-filter\-files=\fR\fIregex\fR 4
  .IX Item "-fprofile-filter-files=regex"
  Instrument only functions from files whose name matches
! any of the regular expressions (separated by semi\-colons).
  .Sp
  For example, \fB\-fprofile\-filter\-files=main\e.c;module.*\e.c\fR will instrument
! only \fImain.c\fR and all C files starting with \*(Aqmodule\*(Aq.
! .IP \fB\-fprofile\-exclude\-files=\fR\fIregex\fR 4
  .IX Item "-fprofile-exclude-files=regex"
  Instrument only functions from files whose name does not match
! any of the regular expressions (separated by semi\-colons).
  .Sp
  For example, \fB\-fprofile\-exclude\-files=/usr/.*\fR will prevent instrumentation
  of all files that are located in the \fI/usr/\fR folder.
! .IP \fB\-fprofile\-reproducible=\fR[\fBmultithreaded\fR|\fBparallel\-runs\fR|\fBserial\fR] 4
  .IX Item "-fprofile-reproducible=[multithreaded|parallel-runs|serial]"
  Control level of reproducibility of profile gathered by
  \&\f(CW\*(C`\-fprofile\-generate\*(C'\fR.  This makes it possible to rebuild program
*************** packages.
*** 15666,15680 ****
  With \fB\-fprofile\-reproducible=serial\fR the profile gathered by
  \&\fB\-fprofile\-generate\fR is reproducible provided the trained program
  behaves the same at each invocation of the train run, it is not
! multi-threaded and profile data streaming is always done in the same
  order.  Note that profile streaming happens at the end of program run but
  also before \f(CW\*(C`fork\*(C'\fR function is invoked.
  .Sp
  Note that it is quite common that execution counts of some part of
  programs depends, for example, on length of temporary file names or
! memory space randomization (that may affect hash-table collision rate).
! Such non-reproducible part of programs may be annotated by
! \&\f(CW\*(C`no_instrument_function\*(C'\fR function attribute. \fBgcov-dump\fR with
  \&\fB\-l\fR can be used to dump gathered data and verify that they are
  indeed reproducible.
  .Sp
--- 15597,15611 ----
  With \fB\-fprofile\-reproducible=serial\fR the profile gathered by
  \&\fB\-fprofile\-generate\fR is reproducible provided the trained program
  behaves the same at each invocation of the train run, it is not
! multi\-threaded and profile data streaming is always done in the same
  order.  Note that profile streaming happens at the end of program run but
  also before \f(CW\*(C`fork\*(C'\fR function is invoked.
  .Sp
  Note that it is quite common that execution counts of some part of
  programs depends, for example, on length of temporary file names or
! memory space randomization (that may affect hash\-table collision rate).
! Such non\-reproducible part of programs may be annotated by
! \&\f(CW\*(C`no_instrument_function\*(C'\fR function attribute. \fBgcov\-dump\fR with
  \&\fB\-l\fR can be used to dump gathered data and verify that they are
  indeed reproducible.
  .Sp
*************** gcda files.  This setting makes it possi
*** 15684,15698 ****
  instrumented program in parallel (such as with \f(CW\*(C`make \-j\*(C'\fR). This
  reduces quality of gathered data, in particular of indirect call
  profiling.
! .IP "\fB\-fsanitize=address\fR" 4
  .IX Item "-fsanitize=address"
  Enable AddressSanitizer, a fast memory error detector.
  Memory access instructions are instrumented to detect
! out-of-bounds and use-after-free bugs.
  The option enables \fB\-fsanitize\-address\-use\-after\-scope\fR.
  See <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizer\fR> for
! more details.  The run-time behavior can be influenced using the
! \&\fB\s-1ASAN_OPTIONS\s0\fR environment variable.  When set to \f(CW\*(C`help=1\*(C'\fR,
  the available options are shown at startup of the instrumented program.  See
  <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run\-time\-flags\fR>
  for a list of supported options.
--- 15615,15629 ----
  instrumented program in parallel (such as with \f(CW\*(C`make \-j\*(C'\fR). This
  reduces quality of gathered data, in particular of indirect call
  profiling.
! .IP \fB\-fsanitize=address\fR 4
  .IX Item "-fsanitize=address"
  Enable AddressSanitizer, a fast memory error detector.
  Memory access instructions are instrumented to detect
! out\-of\-bounds and use\-after\-free bugs.
  The option enables \fB\-fsanitize\-address\-use\-after\-scope\fR.
  See <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizer\fR> for
! more details.  The run\-time behavior can be influenced using the
! \&\fBASAN_OPTIONS\fR environment variable.  When set to \f(CW\*(C`help=1\*(C'\fR,
  the available options are shown at startup of the instrumented program.  See
  <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run\-time\-flags\fR>
  for a list of supported options.
*************** most function inlining), \fB\-fno\-optim
*** 15708,15738 ****
  optimizing sibling and tail recursive calls; this option is implicit for
  \&\fB\-O0\fR, \fB\-O1\fR, or \fB\-Og\fR), or \fB\-fno\-ipa\-icf\fR (which
  disables Identical Code Folding for functions).  Since multiple runs of the
! program may yield backtraces with different addresses due to \s-1ASLR\s0 (Address
! Space Layout Randomization), it may be desirable to turn \s-1ASLR\s0 off.  On Linux,
! this can be achieved with \fBsetarch `uname \-m` \-R ./prog\fR.
! .IP "\fB\-fsanitize=kernel\-address\fR" 4
  .IX Item "-fsanitize=kernel-address"
  Enable AddressSanitizer for Linux kernel.
  See <\fBhttps://github.com/google/kernel\-sanitizers\fR> for more details.
! .IP "\fB\-fsanitize=hwaddress\fR" 4
  .IX Item "-fsanitize=hwaddress"
! Enable Hardware-assisted AddressSanitizer, which uses a hardware ability to
  ignore the top byte of a pointer to allow the detection of memory errors with
  a low memory overhead.
! Memory access instructions are instrumented to detect out-of-bounds and
! use-after-free bugs.
  The option enables \fB\-fsanitize\-address\-use\-after\-scope\fR.
  See
  <\fBhttps://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html\fR>
! for more details.  The run-time behavior can be influenced using the
! \&\fB\s-1HWASAN_OPTIONS\s0\fR environment variable.  When set to \f(CW\*(C`help=1\*(C'\fR,
  the available options are shown at startup of the instrumented program.
  The option cannot be combined with \fB\-fsanitize=thread\fR or
  \&\fB\-fsanitize=address\fR, and is currently only available on AArch64.
! .IP "\fB\-fsanitize=kernel\-hwaddress\fR" 4
  .IX Item "-fsanitize=kernel-hwaddress"
! Enable Hardware-assisted AddressSanitizer for compilation of the Linux kernel.
  Similar to \fB\-fsanitize=kernel\-address\fR but using an alternate
  instrumentation method, and similar to \fB\-fsanitize=hwaddress\fR but with
  instrumentation differences necessary for compiling the Linux kernel.
--- 15639,15669 ----
  optimizing sibling and tail recursive calls; this option is implicit for
  \&\fB\-O0\fR, \fB\-O1\fR, or \fB\-Og\fR), or \fB\-fno\-ipa\-icf\fR (which
  disables Identical Code Folding for functions).  Since multiple runs of the
! program may yield backtraces with different addresses due to ASLR (Address
! Space Layout Randomization), it may be desirable to turn ASLR off.  On Linux,
! this can be achieved with \fBsetarch \`uname \-m\` \-R ./prog\fR.
! .IP \fB\-fsanitize=kernel\-address\fR 4
  .IX Item "-fsanitize=kernel-address"
  Enable AddressSanitizer for Linux kernel.
  See <\fBhttps://github.com/google/kernel\-sanitizers\fR> for more details.
! .IP \fB\-fsanitize=hwaddress\fR 4
  .IX Item "-fsanitize=hwaddress"
! Enable Hardware\-assisted AddressSanitizer, which uses a hardware ability to
  ignore the top byte of a pointer to allow the detection of memory errors with
  a low memory overhead.
! Memory access instructions are instrumented to detect out\-of\-bounds and
! use\-after\-free bugs.
  The option enables \fB\-fsanitize\-address\-use\-after\-scope\fR.
  See
  <\fBhttps://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html\fR>
! for more details.  The run\-time behavior can be influenced using the
! \&\fBHWASAN_OPTIONS\fR environment variable.  When set to \f(CW\*(C`help=1\*(C'\fR,
  the available options are shown at startup of the instrumented program.
  The option cannot be combined with \fB\-fsanitize=thread\fR or
  \&\fB\-fsanitize=address\fR, and is currently only available on AArch64.
! .IP \fB\-fsanitize=kernel\-hwaddress\fR 4
  .IX Item "-fsanitize=kernel-hwaddress"
! Enable Hardware\-assisted AddressSanitizer for compilation of the Linux kernel.
  Similar to \fB\-fsanitize=kernel\-address\fR but using an alternate
  instrumentation method, and similar to \fB\-fsanitize=hwaddress\fR but with
  instrumentation differences necessary for compiling the Linux kernel.
*************** account for the stack pointer having a d
*** 15741,15751 ****
  .Sp
  \&\fINote:\fR This option has different defaults to the \fB\-fsanitize=hwaddress\fR.
  Instrumenting the stack and alloca calls are not on by default but are still
! possible by specifying the command-line options
  \&\fB\-\-param hwasan\-instrument\-stack=1\fR and
  \&\fB\-\-param hwasan\-instrument\-allocas=1\fR respectively. Using a random frame
  tag is not implemented for kernel instrumentation.
! .IP "\fB\-fsanitize=pointer\-compare\fR" 4
  .IX Item "-fsanitize=pointer-compare"
  Instrument comparison operation (<, <=, >, >=) with pointer operands.
  The option must be combined with either \fB\-fsanitize=kernel\-address\fR or
--- 15672,15682 ----
  .Sp
  \&\fINote:\fR This option has different defaults to the \fB\-fsanitize=hwaddress\fR.
  Instrumenting the stack and alloca calls are not on by default but are still
! possible by specifying the command\-line options
  \&\fB\-\-param hwasan\-instrument\-stack=1\fR and
  \&\fB\-\-param hwasan\-instrument\-allocas=1\fR respectively. Using a random frame
  tag is not implemented for kernel instrumentation.
! .IP \fB\-fsanitize=pointer\-compare\fR 4
  .IX Item "-fsanitize=pointer-compare"
  Instrument comparison operation (<, <=, >, >=) with pointer operands.
  The option must be combined with either \fB\-fsanitize=kernel\-address\fR or
*************** The option must be combined with either
*** 15753,15761 ****
  The option cannot be combined with \fB\-fsanitize=thread\fR.
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_invalid_pointer_pairs=2\*(C'\fR to the environment variable
! \&\fB\s-1ASAN_OPTIONS\s0\fR. Using \f(CW\*(C`detect_invalid_pointer_pairs=1\*(C'\fR detects
! invalid operation only when both pointers are non-null.
! .IP "\fB\-fsanitize=pointer\-subtract\fR" 4
  .IX Item "-fsanitize=pointer-subtract"
  Instrument subtraction with pointer operands.
  The option must be combined with either \fB\-fsanitize=kernel\-address\fR or
--- 15684,15692 ----
  The option cannot be combined with \fB\-fsanitize=thread\fR.
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_invalid_pointer_pairs=2\*(C'\fR to the environment variable
! \&\fBASAN_OPTIONS\fR. Using \f(CW\*(C`detect_invalid_pointer_pairs=1\*(C'\fR detects
! invalid operation only when both pointers are non\-null.
! .IP \fB\-fsanitize=pointer\-subtract\fR 4
  .IX Item "-fsanitize=pointer-subtract"
  Instrument subtraction with pointer operands.
  The option must be combined with either \fB\-fsanitize=kernel\-address\fR or
*************** The option must be combined with either
*** 15763,15785 ****
  The option cannot be combined with \fB\-fsanitize=thread\fR.
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_invalid_pointer_pairs=2\*(C'\fR to the environment variable
! \&\fB\s-1ASAN_OPTIONS\s0\fR. Using \f(CW\*(C`detect_invalid_pointer_pairs=1\*(C'\fR detects
! invalid operation only when both pointers are non-null.
! .IP "\fB\-fsanitize=shadow\-call\-stack\fR" 4
  .IX Item "-fsanitize=shadow-call-stack"
  Enable ShadowCallStack, a security enhancement mechanism used to protect
  programs against return address overwrites (e.g. stack buffer overflows.)
! It works by saving a function's return address to a separately allocated
  shadow call stack in the function prologue and restoring the return address
  from the shadow call stack in the function epilogue.  Instrumentation only
  occurs in functions that need to save the return address to the stack.
  .Sp
  Currently it only supports the aarch64 platform.  It is specifically
! designed for linux kernels that enable the \s-1CONFIG_SHADOW_CALL_STACK\s0 option.
  For the user space programs, runtime support is not currently provided
  in libc and libgcc.  Users who want to use this feature in user space need
  to provide their own support for the runtime.  It should be noted that
! this may cause the \s-1ABI\s0 rules to be broken.
  .Sp
  On aarch64, the instrumentation makes use of the platform register \f(CW\*(C`x18\*(C'\fR.
  This generally means that any code that may run on the same thread as code
--- 15694,15716 ----
  The option cannot be combined with \fB\-fsanitize=thread\fR.
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_invalid_pointer_pairs=2\*(C'\fR to the environment variable
! \&\fBASAN_OPTIONS\fR. Using \f(CW\*(C`detect_invalid_pointer_pairs=1\*(C'\fR detects
! invalid operation only when both pointers are non\-null.
! .IP \fB\-fsanitize=shadow\-call\-stack\fR 4
  .IX Item "-fsanitize=shadow-call-stack"
  Enable ShadowCallStack, a security enhancement mechanism used to protect
  programs against return address overwrites (e.g. stack buffer overflows.)
! It works by saving a function\*(Aqs return address to a separately allocated
  shadow call stack in the function prologue and restoring the return address
  from the shadow call stack in the function epilogue.  Instrumentation only
  occurs in functions that need to save the return address to the stack.
  .Sp
  Currently it only supports the aarch64 platform.  It is specifically
! designed for linux kernels that enable the CONFIG_SHADOW_CALL_STACK option.
  For the user space programs, runtime support is not currently provided
  in libc and libgcc.  Users who want to use this feature in user space need
  to provide their own support for the runtime.  It should be noted that
! this may cause the ABI rules to be broken.
  .Sp
  On aarch64, the instrumentation makes use of the platform register \f(CW\*(C`x18\*(C'\fR.
  This generally means that any code that may run on the same thread as code
*************** to turn off exceptions.
*** 15794,15805 ****
  .Sp
  See <\fBhttps://clang.llvm.org/docs/ShadowCallStack.html\fR> for more
  details.
! .IP "\fB\-fsanitize=thread\fR" 4
  .IX Item "-fsanitize=thread"
  Enable ThreadSanitizer, a fast data race detector.
  Memory access instructions are instrumented to detect
  data race bugs.  See <\fBhttps://github.com/google/sanitizers/wiki#threadsanitizer\fR> for more
! details. The run-time behavior can be influenced using the \fB\s-1TSAN_OPTIONS\s0\fR
  environment variable; see
  <\fBhttps://github.com/google/sanitizers/wiki/ThreadSanitizerFlags\fR> for a list of
  supported options.
--- 15725,15736 ----
  .Sp
  See <\fBhttps://clang.llvm.org/docs/ShadowCallStack.html\fR> for more
  details.
! .IP \fB\-fsanitize=thread\fR 4
  .IX Item "-fsanitize=thread"
  Enable ThreadSanitizer, a fast data race detector.
  Memory access instructions are instrumented to detect
  data race bugs.  See <\fBhttps://github.com/google/sanitizers/wiki#threadsanitizer\fR> for more
! details. The run\-time behavior can be influenced using the \fBTSAN_OPTIONS\fR
  environment variable; see
  <\fBhttps://github.com/google/sanitizers/wiki/ThreadSanitizerFlags\fR> for a list of
  supported options.
*************** The option cannot be combined with \fB\-
*** 15807,15875 ****
  \&\fB\-fsanitize=leak\fR.
  .Sp
  Note that sanitized atomic builtins cannot throw exceptions when
! operating on invalid memory addresses with non-call exceptions
  (\fB\-fnon\-call\-exceptions\fR).
! .IP "\fB\-fsanitize=leak\fR" 4
  .IX Item "-fsanitize=leak"
  Enable LeakSanitizer, a memory leak detector.
  This option only matters for linking of executables.
  The executable is linked against a library that overrides \f(CW\*(C`malloc\*(C'\fR
  and other allocator functions.  See
  <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer\fR> for more
! details.  The run-time behavior can be influenced using the
! \&\fB\s-1LSAN_OPTIONS\s0\fR environment variable.
  The option cannot be combined with \fB\-fsanitize=thread\fR.
! .IP "\fB\-fsanitize=undefined\fR" 4
  .IX Item "-fsanitize=undefined"
  Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector.
  Various computations are instrumented to detect undefined behavior
! at runtime.  See <\fBhttps://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html\fR> for more details.   The run-time behavior can be influenced using the
! \&\fB\s-1UBSAN_OPTIONS\s0\fR environment variable.  Current suboptions are:
  .RS 4
! .IP "\fB\-fsanitize=shift\fR" 4
  .IX Item "-fsanitize=shift"
  This option enables checking that the result of a shift operation is
  not undefined.  Note that what exactly is considered undefined differs
! slightly between C and \*(C+, as well as between \s-1ISO C90\s0 and C99, etc.
  This option has two suboptions, \fB\-fsanitize=shift\-base\fR and
  \&\fB\-fsanitize=shift\-exponent\fR.
! .IP "\fB\-fsanitize=shift\-exponent\fR" 4
  .IX Item "-fsanitize=shift-exponent"
  This option enables checking that the second argument of a shift operation
  is not negative and is smaller than the precision of the promoted first
  argument.
! .IP "\fB\-fsanitize=shift\-base\fR" 4
  .IX Item "-fsanitize=shift-base"
  If the second argument of a shift operation is within range, check that the
  result of a shift operation is not undefined.  Note that what exactly is
! considered undefined differs slightly between C and \*(C+, as well as between
! \&\s-1ISO C90\s0 and C99, etc.
! .IP "\fB\-fsanitize=integer\-divide\-by\-zero\fR" 4
  .IX Item "-fsanitize=integer-divide-by-zero"
  Detect integer division by zero.
! .IP "\fB\-fsanitize=unreachable\fR" 4
  .IX Item "-fsanitize=unreachable"
  With this option, the compiler turns the \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR
  call into a diagnostics message call instead.  When reaching the
  \&\f(CW\*(C`_\|_builtin_unreachable\*(C'\fR call, the behavior is undefined.
! .IP "\fB\-fsanitize=vla\-bound\fR" 4
  .IX Item "-fsanitize=vla-bound"
  This option instructs the compiler to check that the size of a variable
  length array is positive.
! .IP "\fB\-fsanitize=null\fR" 4
  .IX Item "-fsanitize=null"
  This option enables pointer checking.  Particularly, the application
  built with this option turned on will issue an error message when it
! tries to dereference a \s-1NULL\s0 pointer, or if a reference (possibly an
! rvalue reference) is bound to a \s-1NULL\s0 pointer, or if a method is invoked
! on an object pointed by a \s-1NULL\s0 pointer.
! .IP "\fB\-fsanitize=return\fR" 4
  .IX Item "-fsanitize=return"
  This option enables return statement checking.  Programs
  built with this option turned on will issue an error message
! when the end of a non-void function is reached without actually
! returning a value.  This option works in \*(C+ only.
! .IP "\fB\-fsanitize=signed\-integer\-overflow\fR" 4
  .IX Item "-fsanitize=signed-integer-overflow"
  This option enables signed integer overflow checking.  We check that
  the result of \f(CW\*(C`+\*(C'\fR, \f(CW\*(C`*\*(C'\fR, and both unary and binary \f(CW\*(C`\-\*(C'\fR
--- 15738,15806 ----
  \&\fB\-fsanitize=leak\fR.
  .Sp
  Note that sanitized atomic builtins cannot throw exceptions when
! operating on invalid memory addresses with non\-call exceptions
  (\fB\-fnon\-call\-exceptions\fR).
! .IP \fB\-fsanitize=leak\fR 4
  .IX Item "-fsanitize=leak"
  Enable LeakSanitizer, a memory leak detector.
  This option only matters for linking of executables.
  The executable is linked against a library that overrides \f(CW\*(C`malloc\*(C'\fR
  and other allocator functions.  See
  <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer\fR> for more
! details.  The run\-time behavior can be influenced using the
! \&\fBLSAN_OPTIONS\fR environment variable.
  The option cannot be combined with \fB\-fsanitize=thread\fR.
! .IP \fB\-fsanitize=undefined\fR 4
  .IX Item "-fsanitize=undefined"
  Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector.
  Various computations are instrumented to detect undefined behavior
! at runtime.  See <\fBhttps://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html\fR> for more details.   The run\-time behavior can be influenced using the
! \&\fBUBSAN_OPTIONS\fR environment variable.  Current suboptions are:
  .RS 4
! .IP \fB\-fsanitize=shift\fR 4
  .IX Item "-fsanitize=shift"
  This option enables checking that the result of a shift operation is
  not undefined.  Note that what exactly is considered undefined differs
! slightly between C and C++, as well as between ISO C90 and C99, etc.
  This option has two suboptions, \fB\-fsanitize=shift\-base\fR and
  \&\fB\-fsanitize=shift\-exponent\fR.
! .IP \fB\-fsanitize=shift\-exponent\fR 4
  .IX Item "-fsanitize=shift-exponent"
  This option enables checking that the second argument of a shift operation
  is not negative and is smaller than the precision of the promoted first
  argument.
! .IP \fB\-fsanitize=shift\-base\fR 4
  .IX Item "-fsanitize=shift-base"
  If the second argument of a shift operation is within range, check that the
  result of a shift operation is not undefined.  Note that what exactly is
! considered undefined differs slightly between C and C++, as well as between
! ISO C90 and C99, etc.
! .IP \fB\-fsanitize=integer\-divide\-by\-zero\fR 4
  .IX Item "-fsanitize=integer-divide-by-zero"
  Detect integer division by zero.
! .IP \fB\-fsanitize=unreachable\fR 4
  .IX Item "-fsanitize=unreachable"
  With this option, the compiler turns the \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR
  call into a diagnostics message call instead.  When reaching the
  \&\f(CW\*(C`_\|_builtin_unreachable\*(C'\fR call, the behavior is undefined.
! .IP \fB\-fsanitize=vla\-bound\fR 4
  .IX Item "-fsanitize=vla-bound"
  This option instructs the compiler to check that the size of a variable
  length array is positive.
! .IP \fB\-fsanitize=null\fR 4
  .IX Item "-fsanitize=null"
  This option enables pointer checking.  Particularly, the application
  built with this option turned on will issue an error message when it
! tries to dereference a NULL pointer, or if a reference (possibly an
! rvalue reference) is bound to a NULL pointer, or if a method is invoked
! on an object pointed by a NULL pointer.
! .IP \fB\-fsanitize=return\fR 4
  .IX Item "-fsanitize=return"
  This option enables return statement checking.  Programs
  built with this option turned on will issue an error message
! when the end of a non\-void function is reached without actually
! returning a value.  This option works in C++ only.
! .IP \fB\-fsanitize=signed\-integer\-overflow\fR 4
  .IX Item "-fsanitize=signed-integer-overflow"
  This option enables signed integer overflow checking.  We check that
  the result of \f(CW\*(C`+\*(C'\fR, \f(CW\*(C`*\*(C'\fR, and both unary and binary \f(CW\*(C`\-\*(C'\fR
*************** overflow:
*** 15882,15956 ****
  \&        signed char a = SCHAR_MAX;
  \&        a++;
  .Ve
! .IP "\fB\-fsanitize=bounds\fR" 4
  .IX Item "-fsanitize=bounds"
  This option enables instrumentation of array bounds.  Various out of bounds
! accesses are detected.  Flexible array members, flexible array member-like
  arrays, and initializers of variables with static storage are not
! instrumented, with the exception of flexible array member-like arrays
  for which \f(CW\*(C`\-fstrict\-flex\-arrays\*(C'\fR or \f(CW\*(C`\-fstrict\-flex\-arrays=\*(C'\fR
! options or \f(CW\*(C`strict_flex_array\*(C'\fR attributes say they shouldn't be treated
! like flexible array member-like arrays.
! .IP "\fB\-fsanitize=bounds\-strict\fR" 4
  .IX Item "-fsanitize=bounds-strict"
  This option enables strict instrumentation of array bounds.  Most out of bounds
! accesses are detected, including flexible array member-like arrays.
  Initializers of variables with static storage are not instrumented.
! .IP "\fB\-fsanitize=alignment\fR" 4
  .IX Item "-fsanitize=alignment"
  This option enables checking of alignment of pointers when they are
  dereferenced, or when a reference is bound to insufficiently aligned target,
  or when a method or constructor is invoked on insufficiently aligned object.
! .IP "\fB\-fsanitize=object\-size\fR" 4
  .IX Item "-fsanitize=object-size"
  This option enables instrumentation of memory references using the
  \&\f(CW\*(C`_\|_builtin_dynamic_object_size\*(C'\fR function.  Various out of bounds
  pointer accesses are detected.
! .IP "\fB\-fsanitize=float\-divide\-by\-zero\fR" 4
  .IX Item "-fsanitize=float-divide-by-zero"
! Detect floating-point division by zero.  Unlike other similar options,
  \&\fB\-fsanitize=float\-divide\-by\-zero\fR is not enabled by
! \&\fB\-fsanitize=undefined\fR, since floating-point division by zero can
  be a legitimate way of obtaining infinities and NaNs.
! .IP "\fB\-fsanitize=float\-cast\-overflow\fR" 4
  .IX Item "-fsanitize=float-cast-overflow"
! This option enables floating-point type to integer conversion checking.
  We check that the result of the conversion does not overflow.
  Unlike other similar options, \fB\-fsanitize=float\-cast\-overflow\fR is
  not enabled by \fB\-fsanitize=undefined\fR.
  This option does not work well with \f(CW\*(C`FE_INVALID\*(C'\fR exceptions enabled.
! .IP "\fB\-fsanitize=nonnull\-attribute\fR" 4
  .IX Item "-fsanitize=nonnull-attribute"
  This option enables instrumentation of calls, checking whether null values
! are not passed to arguments marked as requiring a non-null value by the
  \&\f(CW\*(C`nonnull\*(C'\fR function attribute.
! .IP "\fB\-fsanitize=returns\-nonnull\-attribute\fR" 4
  .IX Item "-fsanitize=returns-nonnull-attribute"
  This option enables instrumentation of return statements in functions
  marked with \f(CW\*(C`returns_nonnull\*(C'\fR function attribute, to detect returning
  of null values from such functions.
! .IP "\fB\-fsanitize=bool\fR" 4
  .IX Item "-fsanitize=bool"
  This option enables instrumentation of loads from bool.  If a value other
! than 0/1 is loaded, a run-time error is issued.
! .IP "\fB\-fsanitize=enum\fR" 4
  .IX Item "-fsanitize=enum"
  This option enables instrumentation of loads from an enum type.  If
  a value outside the range of values for the enum type is loaded,
! a run-time error is issued.
! .IP "\fB\-fsanitize=vptr\fR" 4
  .IX Item "-fsanitize=vptr"
! This option enables instrumentation of \*(C+ member function calls, member
  accesses and some conversions between pointers to base and derived classes,
  to verify the referenced object has the correct dynamic type.
! .IP "\fB\-fsanitize=pointer\-overflow\fR" 4
  .IX Item "-fsanitize=pointer-overflow"
  This option enables instrumentation of pointer arithmetics.  If the pointer
! arithmetics overflows, a run-time error is issued.
! .IP "\fB\-fsanitize=builtin\fR" 4
  .IX Item "-fsanitize=builtin"
  This option enables instrumentation of arguments to selected builtin
! functions.  If an invalid value is passed to such arguments, a run-time
  error is issued.  E.g. passing 0 as the argument to \f(CW\*(C`_\|_builtin_ctz\*(C'\fR
  or \f(CW\*(C`_\|_builtin_clz\*(C'\fR invokes undefined behavior and is diagnosed
  by this option.
--- 15813,15887 ----
  \&        signed char a = SCHAR_MAX;
  \&        a++;
  .Ve
! .IP \fB\-fsanitize=bounds\fR 4
  .IX Item "-fsanitize=bounds"
  This option enables instrumentation of array bounds.  Various out of bounds
! accesses are detected.  Flexible array members, flexible array member\-like
  arrays, and initializers of variables with static storage are not
! instrumented, with the exception of flexible array member\-like arrays
  for which \f(CW\*(C`\-fstrict\-flex\-arrays\*(C'\fR or \f(CW\*(C`\-fstrict\-flex\-arrays=\*(C'\fR
! options or \f(CW\*(C`strict_flex_array\*(C'\fR attributes say they shouldn\*(Aqt be treated
! like flexible array member\-like arrays.
! .IP \fB\-fsanitize=bounds\-strict\fR 4
  .IX Item "-fsanitize=bounds-strict"
  This option enables strict instrumentation of array bounds.  Most out of bounds
! accesses are detected, including flexible array member\-like arrays.
  Initializers of variables with static storage are not instrumented.
! .IP \fB\-fsanitize=alignment\fR 4
  .IX Item "-fsanitize=alignment"
  This option enables checking of alignment of pointers when they are
  dereferenced, or when a reference is bound to insufficiently aligned target,
  or when a method or constructor is invoked on insufficiently aligned object.
! .IP \fB\-fsanitize=object\-size\fR 4
  .IX Item "-fsanitize=object-size"
  This option enables instrumentation of memory references using the
  \&\f(CW\*(C`_\|_builtin_dynamic_object_size\*(C'\fR function.  Various out of bounds
  pointer accesses are detected.
! .IP \fB\-fsanitize=float\-divide\-by\-zero\fR 4
  .IX Item "-fsanitize=float-divide-by-zero"
! Detect floating\-point division by zero.  Unlike other similar options,
  \&\fB\-fsanitize=float\-divide\-by\-zero\fR is not enabled by
! \&\fB\-fsanitize=undefined\fR, since floating\-point division by zero can
  be a legitimate way of obtaining infinities and NaNs.
! .IP \fB\-fsanitize=float\-cast\-overflow\fR 4
  .IX Item "-fsanitize=float-cast-overflow"
! This option enables floating\-point type to integer conversion checking.
  We check that the result of the conversion does not overflow.
  Unlike other similar options, \fB\-fsanitize=float\-cast\-overflow\fR is
  not enabled by \fB\-fsanitize=undefined\fR.
  This option does not work well with \f(CW\*(C`FE_INVALID\*(C'\fR exceptions enabled.
! .IP \fB\-fsanitize=nonnull\-attribute\fR 4
  .IX Item "-fsanitize=nonnull-attribute"
  This option enables instrumentation of calls, checking whether null values
! are not passed to arguments marked as requiring a non\-null value by the
  \&\f(CW\*(C`nonnull\*(C'\fR function attribute.
! .IP \fB\-fsanitize=returns\-nonnull\-attribute\fR 4
  .IX Item "-fsanitize=returns-nonnull-attribute"
  This option enables instrumentation of return statements in functions
  marked with \f(CW\*(C`returns_nonnull\*(C'\fR function attribute, to detect returning
  of null values from such functions.
! .IP \fB\-fsanitize=bool\fR 4
  .IX Item "-fsanitize=bool"
  This option enables instrumentation of loads from bool.  If a value other
! than 0/1 is loaded, a run\-time error is issued.
! .IP \fB\-fsanitize=enum\fR 4
  .IX Item "-fsanitize=enum"
  This option enables instrumentation of loads from an enum type.  If
  a value outside the range of values for the enum type is loaded,
! a run\-time error is issued.
! .IP \fB\-fsanitize=vptr\fR 4
  .IX Item "-fsanitize=vptr"
! This option enables instrumentation of C++ member function calls, member
  accesses and some conversions between pointers to base and derived classes,
  to verify the referenced object has the correct dynamic type.
! .IP \fB\-fsanitize=pointer\-overflow\fR 4
  .IX Item "-fsanitize=pointer-overflow"
  This option enables instrumentation of pointer arithmetics.  If the pointer
! arithmetics overflows, a run\-time error is issued.
! .IP \fB\-fsanitize=builtin\fR 4
  .IX Item "-fsanitize=builtin"
  This option enables instrumentation of arguments to selected builtin
! functions.  If an invalid value is passed to such arguments, a run\-time
  error is issued.  E.g. passing 0 as the argument to \f(CW\*(C`_\|_builtin_ctz\*(C'\fR
  or \f(CW\*(C`_\|_builtin_clz\*(C'\fR invokes undefined behavior and is diagnosed
  by this option.
*************** While \fB\-ftrapv\fR causes traps for si
*** 15966,15989 ****
  \&\fB\-fsanitize=undefined\fR gives a diagnostic message.
  This currently works only for the C family of languages.
  .RE
! .IP "\fB\-fno\-sanitize=all\fR" 4
  .IX Item "-fno-sanitize=all"
  This option disables all previously enabled sanitizers.
  \&\fB\-fsanitize=all\fR is not allowed, as some sanitizers cannot be used
  together.
! .IP "\fB\-fasan\-shadow\-offset=\fR\fInumber\fR" 4
  .IX Item "-fasan-shadow-offset=number"
! This option forces \s-1GCC\s0 to use custom shadow offset in AddressSanitizer checks.
  It is useful for experimenting with different shadow memory layouts in
  Kernel AddressSanitizer.
! .IP "\fB\-fsanitize\-sections=\fR\fIs1\fR\fB,\fR\fIs2\fR\fB,...\fR" 4
  .IX Item "-fsanitize-sections=s1,s2,..."
! Sanitize global variables in selected user-defined sections.  \fIsi\fR may
  contain wildcards.
! .IP "\fB\-fsanitize\-recover\fR[\fB=\fR\fIopts\fR]" 4
  .IX Item "-fsanitize-recover[=opts]"
  \&\fB\-fsanitize\-recover=\fR controls error recovery mode for sanitizers
! mentioned in comma-separated list of \fIopts\fR.  Enabling this option
  for a sanitizer component causes it to attempt to continue
  running the program as if no error happened.  This means multiple
  runtime errors can be reported in a single program run, and the exit
--- 15897,15920 ----
  \&\fB\-fsanitize=undefined\fR gives a diagnostic message.
  This currently works only for the C family of languages.
  .RE
! .IP \fB\-fno\-sanitize=all\fR 4
  .IX Item "-fno-sanitize=all"
  This option disables all previously enabled sanitizers.
  \&\fB\-fsanitize=all\fR is not allowed, as some sanitizers cannot be used
  together.
! .IP \fB\-fasan\-shadow\-offset=\fR\fInumber\fR 4
  .IX Item "-fasan-shadow-offset=number"
! This option forces GCC to use custom shadow offset in AddressSanitizer checks.
  It is useful for experimenting with different shadow memory layouts in
  Kernel AddressSanitizer.
! .IP \fB\-fsanitize\-sections=\fR\fIs1\fR\fB,\fR\fIs2\fR\fB,...\fR 4
  .IX Item "-fsanitize-sections=s1,s2,..."
! Sanitize global variables in selected user\-defined sections.  \fIsi\fR may
  contain wildcards.
! .IP \fB\-fsanitize\-recover\fR[\fB=\fR\fIopts\fR] 4
  .IX Item "-fsanitize-recover[=opts]"
  \&\fB\-fsanitize\-recover=\fR controls error recovery mode for sanitizers
! mentioned in comma\-separated list of \fIopts\fR.  Enabling this option
  for a sanitizer component causes it to attempt to continue
  running the program as if no error happened.  This means multiple
  runtime errors can be reported in a single program run, and the exit
*************** code of the program may indicate success
*** 15991,15997 ****
  have been reported.  The \fB\-fno\-sanitize\-recover=\fR option
  can be used to alter
  this behavior: only the first detected error is reported
! and program then exits with a non-zero exit code.
  .Sp
  Currently this feature only works for \fB\-fsanitize=undefined\fR (and its suboptions
  except for \fB\-fsanitize=unreachable\fR and \fB\-fsanitize=return\fR),
--- 15922,15928 ----
  have been reported.  The \fB\-fno\-sanitize\-recover=\fR option
  can be used to alter
  this behavior: only the first detected error is reported
! and program then exits with a non\-zero exit code.
  .Sp
  Currently this feature only works for \fB\-fsanitize=undefined\fR (and its suboptions
  except for \fB\-fsanitize=unreachable\fR and \fB\-fsanitize=return\fR),
*************** equivalent to specifying an \fIopts\fR l
*** 16017,16030 ****
  .Vb 1
  \&        undefined,float\-cast\-overflow,float\-divide\-by\-zero,bounds\-strict
  .Ve
! .IP "\fB\-fsanitize\-address\-use\-after\-scope\fR" 4
  .IX Item "-fsanitize-address-use-after-scope"
! Enable sanitization of local variables to detect use-after-scope bugs.
  The option sets \fB\-fstack\-reuse\fR to \fBnone\fR.
! .IP "\fB\-fsanitize\-trap\fR[\fB=\fR\fIopts\fR]" 4
  .IX Item "-fsanitize-trap[=opts]"
  The \fB\-fsanitize\-trap=\fR option instructs the compiler to
! report for sanitizers mentioned in comma-separated list of \fIopts\fR
  undefined behavior using \f(CW\*(C`_\|_builtin_trap\*(C'\fR rather than a \f(CW\*(C`libubsan\*(C'\fR
  library routine.  If this option is enabled for certain sanitizer,
  it takes precedence over the \fB\-fsanitizer\-recover=\fR for that
--- 15948,15961 ----
  .Vb 1
  \&        undefined,float\-cast\-overflow,float\-divide\-by\-zero,bounds\-strict
  .Ve
! .IP \fB\-fsanitize\-address\-use\-after\-scope\fR 4
  .IX Item "-fsanitize-address-use-after-scope"
! Enable sanitization of local variables to detect use\-after\-scope bugs.
  The option sets \fB\-fstack\-reuse\fR to \fBnone\fR.
! .IP \fB\-fsanitize\-trap\fR[\fB=\fR\fIopts\fR] 4
  .IX Item "-fsanitize-trap[=opts]"
  The \fB\-fsanitize\-trap=\fR option instructs the compiler to
! report for sanitizers mentioned in comma\-separated list of \fIopts\fR
  undefined behavior using \f(CW\*(C`_\|_builtin_trap\*(C'\fR rather than a \f(CW\*(C`libubsan\*(C'\fR
  library routine.  If this option is enabled for certain sanitizer,
  it takes precedence over the \fB\-fsanitizer\-recover=\fR for that
*************** If \f(CW\*(C`\-fsanitize\-trap=undefined
*** 16046,16060 ****
  and \f(CW\*(C`\-fsanitize=vptr\*(C'\fR is enabled on the command line, the
  instrumentation is silently ignored as the instrumentation always needs
  \&\f(CW\*(C`libubsan\*(C'\fR support, \fB\-fsanitize\-trap=vptr\fR is not allowed.
! .IP "\fB\-fsanitize\-undefined\-trap\-on\-error\fR" 4
  .IX Item "-fsanitize-undefined-trap-on-error"
  The \fB\-fsanitize\-undefined\-trap\-on\-error\fR option is deprecated
  equivalent of \fB\-fsanitize\-trap=all\fR.
! .IP "\fB\-fsanitize\-coverage=trace\-pc\fR" 4
  .IX Item "-fsanitize-coverage=trace-pc"
! Enable coverage-guided fuzzing code instrumentation.
  Inserts a call to \f(CW\*(C`_\|_sanitizer_cov_trace_pc\*(C'\fR into every basic block.
! .IP "\fB\-fsanitize\-coverage=trace\-cmp\fR" 4
  .IX Item "-fsanitize-coverage=trace-cmp"
  Enable dataflow guided fuzzing code instrumentation.
  Inserts a call to \f(CW\*(C`_\|_sanitizer_cov_trace_cmp1\*(C'\fR,
--- 15977,15991 ----
  and \f(CW\*(C`\-fsanitize=vptr\*(C'\fR is enabled on the command line, the
  instrumentation is silently ignored as the instrumentation always needs
  \&\f(CW\*(C`libubsan\*(C'\fR support, \fB\-fsanitize\-trap=vptr\fR is not allowed.
! .IP \fB\-fsanitize\-undefined\-trap\-on\-error\fR 4
  .IX Item "-fsanitize-undefined-trap-on-error"
  The \fB\-fsanitize\-undefined\-trap\-on\-error\fR option is deprecated
  equivalent of \fB\-fsanitize\-trap=all\fR.
! .IP \fB\-fsanitize\-coverage=trace\-pc\fR 4
  .IX Item "-fsanitize-coverage=trace-pc"
! Enable coverage\-guided fuzzing code instrumentation.
  Inserts a call to \f(CW\*(C`_\|_sanitizer_cov_trace_pc\*(C'\fR into every basic block.
! .IP \fB\-fsanitize\-coverage=trace\-cmp\fR 4
  .IX Item "-fsanitize-coverage=trace-cmp"
  Enable dataflow guided fuzzing code instrumentation.
  Inserts a call to \f(CW\*(C`_\|_sanitizer_cov_trace_cmp1\*(C'\fR,
*************** variable or \f(CW\*(C`_\|_sanitizer_cov_
*** 16067,16092 ****
  operand constant, \f(CW\*(C`_\|_sanitizer_cov_trace_cmpf\*(C'\fR or
  \&\f(CW\*(C`_\|_sanitizer_cov_trace_cmpd\*(C'\fR for float or double comparisons and
  \&\f(CW\*(C`_\|_sanitizer_cov_trace_switch\*(C'\fR for switch statements.
! .IP "\fB\-fcf\-protection=\fR[\fBfull\fR|\fBbranch\fR|\fBreturn\fR|\fBnone\fR|\fBcheck\fR]" 4
  .IX Item "-fcf-protection=[full|branch|return|none|check]"
! Enable code instrumentation of control-flow transfers to increase
! program security by checking that target addresses of control-flow
  transfer instructions (such as indirect function call, function return,
  indirect jump) are valid.  This prevents diverting the flow of control
  to an unexpected target.  This is intended to protect against such
! threats as Return-oriented Programming (\s-1ROP\s0), and similarly
! call/jmp\-oriented programming (\s-1COP/JOP\s0).
  .Sp
  The value \f(CW\*(C`branch\*(C'\fR tells the compiler to implement checking of
! validity of control-flow transfer at the point of indirect branch
  instructions, i.e. call/jmp instructions.  The value \f(CW\*(C`return\*(C'\fR
  implements checking of validity at the point of returning from a
  function.  The value \f(CW\*(C`full\*(C'\fR is an alias for specifying both
  \&\f(CW\*(C`branch\*(C'\fR and \f(CW\*(C`return\*(C'\fR. The value \f(CW\*(C`none\*(C'\fR turns off
  instrumentation.
  .Sp
! The value \f(CW\*(C`check\*(C'\fR is used for the final link with link-time
! optimization (\s-1LTO\s0).  An error is issued if \s-1LTO\s0 object files are
  compiled with different \fB\-fcf\-protection\fR values.  The
  value \f(CW\*(C`check\*(C'\fR is ignored at the compile time.
  .Sp
--- 15998,16023 ----
  operand constant, \f(CW\*(C`_\|_sanitizer_cov_trace_cmpf\*(C'\fR or
  \&\f(CW\*(C`_\|_sanitizer_cov_trace_cmpd\*(C'\fR for float or double comparisons and
  \&\f(CW\*(C`_\|_sanitizer_cov_trace_switch\*(C'\fR for switch statements.
! .IP \fB\-fcf\-protection=\fR[\fBfull\fR|\fBbranch\fR|\fBreturn\fR|\fBnone\fR|\fBcheck\fR] 4
  .IX Item "-fcf-protection=[full|branch|return|none|check]"
! Enable code instrumentation of control\-flow transfers to increase
! program security by checking that target addresses of control\-flow
  transfer instructions (such as indirect function call, function return,
  indirect jump) are valid.  This prevents diverting the flow of control
  to an unexpected target.  This is intended to protect against such
! threats as Return\-oriented Programming (ROP), and similarly
! call/jmp\-oriented programming (COP/JOP).
  .Sp
  The value \f(CW\*(C`branch\*(C'\fR tells the compiler to implement checking of
! validity of control\-flow transfer at the point of indirect branch
  instructions, i.e. call/jmp instructions.  The value \f(CW\*(C`return\*(C'\fR
  implements checking of validity at the point of returning from a
  function.  The value \f(CW\*(C`full\*(C'\fR is an alias for specifying both
  \&\f(CW\*(C`branch\*(C'\fR and \f(CW\*(C`return\*(C'\fR. The value \f(CW\*(C`none\*(C'\fR turns off
  instrumentation.
  .Sp
! The value \f(CW\*(C`check\*(C'\fR is used for the final link with link\-time
! optimization (LTO).  An error is issued if LTO object files are
  compiled with different \fB\-fcf\-protection\fR values.  The
  value \f(CW\*(C`check\*(C'\fR is ignored at the compile time.
  .Sp
*************** You can also use the \f(CW\*(C`nocf_chec
*** 16099,16107 ****
  which functions and calls should be skipped from instrumentation.
  .Sp
  Currently the x86 GNU/Linux target provides an implementation based
! on Intel Control-flow Enforcement Technology (\s-1CET\s0) which works for
  i686 processor or newer.
! .IP "\fB\-fharden\-compares\fR" 4
  .IX Item "-fharden-compares"
  For every logical test that survives gimple optimizations and is
  \&\fInot\fR the condition in a conditional branch (for example,
--- 16030,16038 ----
  which functions and calls should be skipped from instrumentation.
  .Sp
  Currently the x86 GNU/Linux target provides an implementation based
! on Intel Control\-flow Enforcement Technology (CET) which works for
  i686 processor or newer.
! .IP \fB\-fharden\-compares\fR 4
  .IX Item "-fharden-compares"
  For every logical test that survives gimple optimizations and is
  \&\fInot\fR the condition in a conditional branch (for example,
*************** variables), emit extra code to compute a
*** 16110,16123 ****
  condition, and to call \f(CW\*(C`_\|_builtin_trap\*(C'\fR if the results do not
  match.  Use with \fB\-fharden\-conditional\-branches\fR to cover all
  conditionals.
! .IP "\fB\-fharden\-conditional\-branches\fR" 4
  .IX Item "-fharden-conditional-branches"
! For every non-vectorized conditional branch that survives gimple
  optimizations, emit extra code to compute and verify the reversed
  condition, and to call \f(CW\*(C`_\|_builtin_trap\*(C'\fR if the result is
  unexpected.  Use with \fB\-fharden\-compares\fR to cover all
  conditionals.
! .IP "\fB\-fstack\-protector\fR" 4
  .IX Item "-fstack-protector"
  Emit extra code to check for buffer overflows, such as stack smashing
  attacks.  This is done by adding a guard variable to functions with
--- 16041,16054 ----
  condition, and to call \f(CW\*(C`_\|_builtin_trap\*(C'\fR if the results do not
  match.  Use with \fB\-fharden\-conditional\-branches\fR to cover all
  conditionals.
! .IP \fB\-fharden\-conditional\-branches\fR 4
  .IX Item "-fharden-conditional-branches"
! For every non\-vectorized conditional branch that survives gimple
  optimizations, emit extra code to compute and verify the reversed
  condition, and to call \f(CW\*(C`_\|_builtin_trap\*(C'\fR if the result is
  unexpected.  Use with \fB\-fharden\-compares\fR to cover all
  conditionals.
! .IP \fB\-fstack\-protector\fR 4
  .IX Item "-fstack-protector"
  Emit extra code to check for buffer overflows, such as stack smashing
  attacks.  This is done by adding a guard variable to functions with
*************** initialized when a function is entered a
*** 16127,16153 ****
  exits.  If a guard check fails, an error message is printed and the program
  exits.  Only variables that are actually allocated on the stack are
  considered, optimized away variables or variables allocated in registers
! don't count.
! .IP "\fB\-fstack\-protector\-all\fR" 4
  .IX Item "-fstack-protector-all"
  Like \fB\-fstack\-protector\fR except that all functions are protected.
! .IP "\fB\-fstack\-protector\-strong\fR" 4
  .IX Item "-fstack-protector-strong"
  Like \fB\-fstack\-protector\fR but includes additional functions to
  be protected \-\-\- those that have local array definitions, or have
  references to local frame addresses.  Only variables that are actually
  allocated on the stack are considered, optimized away variables or variables
! allocated in registers don't count.
! .IP "\fB\-fstack\-protector\-explicit\fR" 4
  .IX Item "-fstack-protector-explicit"
  Like \fB\-fstack\-protector\fR but only protects those functions which
  have the \f(CW\*(C`stack_protect\*(C'\fR attribute.
! .IP "\fB\-fstack\-check\fR" 4
  .IX Item "-fstack-check"
  Generate code to verify that you do not go beyond the boundary of the
  stack.  You should specify this flag if you are running in an
  environment with multiple threads, but you only rarely need to specify it in
! a single-threaded environment since stack overflow is automatically
  detected on nearly all systems if there is only one stack.
  .Sp
  Note that this switch does not actually cause checking to be done; the
--- 16058,16084 ----
  exits.  If a guard check fails, an error message is printed and the program
  exits.  Only variables that are actually allocated on the stack are
  considered, optimized away variables or variables allocated in registers
! don\*(Aqt count.
! .IP \fB\-fstack\-protector\-all\fR 4
  .IX Item "-fstack-protector-all"
  Like \fB\-fstack\-protector\fR except that all functions are protected.
! .IP \fB\-fstack\-protector\-strong\fR 4
  .IX Item "-fstack-protector-strong"
  Like \fB\-fstack\-protector\fR but includes additional functions to
  be protected \-\-\- those that have local array definitions, or have
  references to local frame addresses.  Only variables that are actually
  allocated on the stack are considered, optimized away variables or variables
! allocated in registers don\*(Aqt count.
! .IP \fB\-fstack\-protector\-explicit\fR 4
  .IX Item "-fstack-protector-explicit"
  Like \fB\-fstack\-protector\fR but only protects those functions which
  have the \f(CW\*(C`stack_protect\*(C'\fR attribute.
! .IP \fB\-fstack\-check\fR 4
  .IX Item "-fstack-check"
  Generate code to verify that you do not go beyond the boundary of the
  stack.  You should specify this flag if you are running in an
  environment with multiple threads, but you only rarely need to specify it in
! a single\-threaded environment since stack overflow is automatically
  detected on nearly all systems if there is only one stack.
  .Sp
  Note that this switch does not actually cause checking to be done; the
*************** operating system or the language runtime
*** 16155,16193 ****
  generation of code to ensure that they see the stack being extended.
  .Sp
  You can additionally specify a string parameter: \fBno\fR means no
! checking, \fBgeneric\fR means force the use of old-style checking,
  \&\fBspecific\fR means use the best checking method and is equivalent
  to bare \fB\-fstack\-check\fR.
  .Sp
! Old-style checking is a generic mechanism that requires no specific
  target support in the compiler but comes with the following drawbacks:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  Modified allocation strategy for large objects: they are always
  allocated dynamically if their size exceeds a fixed threshold.  Note this
  may change the semantics of some code.
! .IP "2." 4
  .IX Item "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.
! .IP "3." 4
  .IX Item "3."
  Inefficiency: because of both the modified allocation strategy and the
  generic implementation, code performance is hampered.
  .RE
  .RS 4
  .Sp
! Note that old-style stack checking is also the fallback method for
  \&\fBspecific\fR if no target support has been added in the compiler.
  .Sp
! \&\fB\-fstack\-check=\fR is designed for Ada's needs to detect infinite recursion
  and stack overflows.  \fBspecific\fR is an excellent choice when compiling
! Ada code.  It is not generally sufficient to protect against stack-clash
  attacks.  To protect against those you want \fB\-fstack\-clash\-protection\fR.
  .RE
! .IP "\fB\-fstack\-clash\-protection\fR" 4
  .IX Item "-fstack-clash-protection"
  Generate code to prevent stack clash style attacks.  When this option is
  enabled, the compiler will only allocate one page of stack space at a time
--- 16086,16124 ----
  generation of code to ensure that they see the stack being extended.
  .Sp
  You can additionally specify a string parameter: \fBno\fR means no
! checking, \fBgeneric\fR means force the use of old\-style checking,
  \&\fBspecific\fR means use the best checking method and is equivalent
  to bare \fB\-fstack\-check\fR.
  .Sp
! Old\-style checking is a generic mechanism that requires no specific
  target support in the compiler but comes with the following drawbacks:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  Modified allocation strategy for large objects: they are always
  allocated dynamically if their size exceeds a fixed threshold.  Note this
  may change the semantics of some code.
! .IP 2. 4
  .IX Item "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.
! .IP 3. 4
  .IX Item "3."
  Inefficiency: because of both the modified allocation strategy and the
  generic implementation, code performance is hampered.
  .RE
  .RS 4
  .Sp
! Note that old\-style stack checking is also the fallback method for
  \&\fBspecific\fR if no target support has been added in the compiler.
  .Sp
! \&\fB\-fstack\-check=\fR is designed for Ada\*(Aqs needs to detect infinite recursion
  and stack overflows.  \fBspecific\fR is an excellent choice when compiling
! Ada code.  It is not generally sufficient to protect against stack\-clash
  attacks.  To protect against those you want \fB\-fstack\-clash\-protection\fR.
  .RE
! .IP \fB\-fstack\-clash\-protection\fR 4
  .IX Item "-fstack-clash-protection"
  Generate code to prevent stack clash style attacks.  When this option is
  enabled, the compiler will only allocate one page of stack space at a time
*************** those targets \fB\-fstack\-clash\-protec
*** 16200,16211 ****
  allocations.  \fB\-fstack\-clash\-protection\fR may also provide limited
  protection for static stack allocations if the target supports
  \&\fB\-fstack\-check=specific\fR.
! .IP "\fB\-fstack\-limit\-register=\fR\fIreg\fR" 4
  .IX Item "-fstack-limit-register=reg"
  .PD 0
! .IP "\fB\-fstack\-limit\-symbol=\fR\fIsym\fR" 4
  .IX Item "-fstack-limit-symbol=sym"
! .IP "\fB\-fno\-stack\-limit\fR" 4
  .IX Item "-fno-stack-limit"
  .PD
  Generate code to ensure that the stack does not grow beyond a certain value,
--- 16131,16142 ----
  allocations.  \fB\-fstack\-clash\-protection\fR may also provide limited
  protection for static stack allocations if the target supports
  \&\fB\-fstack\-check=specific\fR.
! .IP \fB\-fstack\-limit\-register=\fR\fIreg\fR 4
  .IX Item "-fstack-limit-register=reg"
  .PD 0
! .IP \fB\-fstack\-limit\-symbol=\fR\fIsym\fR 4
  .IX Item "-fstack-limit-symbol=sym"
! .IP \fB\-fno\-stack\-limit\fR 4
  .IX Item "-fno-stack-limit"
  .PD
  Generate code to ensure that the stack does not grow beyond a certain value,
*************** For instance, if the stack starts at abs
*** 16218,16228 ****
  and grows downwards, you can use the flags
  \&\fB\-fstack\-limit\-symbol=_\|_stack_limit\fR and
  \&\fB\-Wl,\-\-defsym,_\|_stack_limit=0x7ffe0000\fR to enforce a stack limit
! of 128KB.  Note that this may only work with the \s-1GNU\s0 linker.
  .Sp
  You can locally override stack limit checking by using the
  \&\f(CW\*(C`no_stack_limit\*(C'\fR function attribute.
! .IP "\fB\-fsplit\-stack\fR" 4
  .IX Item "-fsplit-stack"
  Generate code to automatically split the stack before it overflows.
  The resulting program has a discontiguous stack which can only
--- 16149,16159 ----
  and grows downwards, you can use the flags
  \&\fB\-fstack\-limit\-symbol=_\|_stack_limit\fR and
  \&\fB\-Wl,\-\-defsym,_\|_stack_limit=0x7ffe0000\fR to enforce a stack limit
! of 128KB.  Note that this may only work with the GNU linker.
  .Sp
  You can locally override stack limit checking by using the
  \&\f(CW\*(C`no_stack_limit\*(C'\fR function attribute.
! .IP \fB\-fsplit\-stack\fR 4
  .IX Item "-fsplit-stack"
  Generate code to automatically split the stack before it overflows.
  The resulting program has a discontiguous stack which can only
*************** available for the latter code to run.  I
*** 16238,16248 ****
  including library code, with \fB\-fsplit\-stack\fR is not an option,
  then the linker can fix up these calls so that the code compiled
  without \fB\-fsplit\-stack\fR always has a large stack.  Support for
! this is implemented in the gold linker in \s-1GNU\s0 binutils release 2.21
  and later.
! .IP "\fB\-fvtable\-verify=\fR[\fBstd\fR|\fBpreinit\fR|\fBnone\fR]" 4
  .IX Item "-fvtable-verify=[std|preinit|none]"
! This option is only available when compiling \*(C+ code.
  It turns on (or off, if using \fB\-fvtable\-verify=none\fR) the security
  feature that verifies at run time, for every virtual call, that
  the vtable pointer through which the call is made is valid for the type of
--- 16169,16179 ----
  including library code, with \fB\-fsplit\-stack\fR is not an option,
  then the linker can fix up these calls so that the code compiled
  without \fB\-fsplit\-stack\fR always has a large stack.  Support for
! this is implemented in the gold linker in GNU binutils release 2.21
  and later.
! .IP \fB\-fvtable\-verify=\fR[\fBstd\fR|\fBpreinit\fR|\fBnone\fR] 4
  .IX Item "-fvtable-verify=[std|preinit|none]"
! This option is only available when compiling C++ code.
  It turns on (or off, if using \fB\-fvtable\-verify=none\fR) the security
  feature that verifies at run time, for every virtual call, that
  the vtable pointer through which the call is made is valid for the type of
*************** the object, and has not been corrupted o
*** 16250,16256 ****
  pointer is detected at run time, an error is reported and execution of the
  program is immediately halted.
  .Sp
! This option causes run-time data structures to be built at program startup,
  which are used for verifying the vtable pointers.  
  The options \fBstd\fR and \fBpreinit\fR
  control the timing of when these data structures are built.  In both cases the
--- 16181,16187 ----
  pointer is detected at run time, an error is reported and execution of the
  program is immediately halted.
  .Sp
! This option causes run\-time data structures to be built at program startup,
  which are used for verifying the vtable pointers.  
  The options \fBstd\fR and \fBpreinit\fR
  control the timing of when these data structures are built.  In both cases the
*************** libraries have been loaded and initializ
*** 16263,16269 ****
  If this option appears multiple times in the command line with different
  values specified, \fBnone\fR takes highest priority over both \fBstd\fR and
  \&\fBpreinit\fR; \fBpreinit\fR takes priority over \fBstd\fR.
! .IP "\fB\-fvtv\-debug\fR" 4
  .IX Item "-fvtv-debug"
  When used in conjunction with \fB\-fvtable\-verify=std\fR or 
  \&\fB\-fvtable\-verify=preinit\fR, causes debug versions of the 
--- 16194,16200 ----
  If this option appears multiple times in the command line with different
  values specified, \fBnone\fR takes highest priority over both \fBstd\fR and
  \&\fBpreinit\fR; \fBpreinit\fR takes priority over \fBstd\fR.
! .IP \fB\-fvtv\-debug\fR 4
  .IX Item "-fvtv-debug"
  When used in conjunction with \fB\-fvtable\-verify=std\fR or 
  \&\fB\-fvtable\-verify=preinit\fR, causes debug versions of the 
*************** runtime functions for the vtable verific
*** 16271,16299 ****
  This flag also causes the compiler to log information about which 
  vtable pointers it finds for each class.
  This information is written to a file named \fIvtv_set_ptr_data.log\fR 
! in the directory named by the environment variable \fB\s-1VTV_LOGS_DIR\s0\fR 
  if that is defined or the current working directory otherwise.
  .Sp
  Note:  This feature \fIappends\fR data to the log file. If you want a fresh log
  file, be sure to delete any existing one.
! .IP "\fB\-fvtv\-counts\fR" 4
  .IX Item "-fvtv-counts"
  This is a debugging flag.  When used in conjunction with
  \&\fB\-fvtable\-verify=std\fR or \fB\-fvtable\-verify=preinit\fR, this
  causes the compiler to keep track of the total number of virtual calls
  it encounters and the number of verifications it inserts.  It also
! counts the number of calls to certain run-time library functions
  that it inserts and logs this information for each compilation unit.
  The compiler writes this information to a file named
  \&\fIvtv_count_data.log\fR in the directory named by the environment
! variable \fB\s-1VTV_LOGS_DIR\s0\fR if that is defined or the current working
  directory otherwise.  It also counts the size of the vtable pointer sets
  for each class, and writes this information to \fIvtv_class_set_sizes.log\fR
  in the same directory.
  .Sp
  Note:  This feature \fIappends\fR data to the log files.  To get fresh log
  files, be sure to delete any existing ones.
! .IP "\fB\-finstrument\-functions\fR" 4
  .IX Item "-finstrument-functions"
  Generate instrumentation calls for entry and exit to functions.  Just
  after function entry and just before function exit, the following
--- 16202,16230 ----
  This flag also causes the compiler to log information about which 
  vtable pointers it finds for each class.
  This information is written to a file named \fIvtv_set_ptr_data.log\fR 
! in the directory named by the environment variable \fBVTV_LOGS_DIR\fR 
  if that is defined or the current working directory otherwise.
  .Sp
  Note:  This feature \fIappends\fR data to the log file. If you want a fresh log
  file, be sure to delete any existing one.
! .IP \fB\-fvtv\-counts\fR 4
  .IX Item "-fvtv-counts"
  This is a debugging flag.  When used in conjunction with
  \&\fB\-fvtable\-verify=std\fR or \fB\-fvtable\-verify=preinit\fR, this
  causes the compiler to keep track of the total number of virtual calls
  it encounters and the number of verifications it inserts.  It also
! counts the number of calls to certain run\-time library functions
  that it inserts and logs this information for each compilation unit.
  The compiler writes this information to a file named
  \&\fIvtv_count_data.log\fR in the directory named by the environment
! variable \fBVTV_LOGS_DIR\fR if that is defined or the current working
  directory otherwise.  It also counts the size of the vtable pointer sets
  for each class, and writes this information to \fIvtv_class_set_sizes.log\fR
  in the same directory.
  .Sp
  Note:  This feature \fIappends\fR data to the log files.  To get fresh log
  files, be sure to delete any existing ones.
! .IP \fB\-finstrument\-functions\fR 4
  .IX Item "-finstrument-functions"
  Generate instrumentation calls for entry and exit to functions.  Just
  after function entry and just before function exit, the following
*************** providing static copies.)
*** 16326,16336 ****
  .Sp
  A function may be given the attribute \f(CW\*(C`no_instrument_function\*(C'\fR, in
  which case this instrumentation is not done.  This can be used, for
! example, for the profiling functions listed above, high-priority
  interrupt routines, and any functions from which the profiling functions
  cannot safely be called (perhaps signal handlers, if the profiling
  routines generate output or allocate memory).
! .IP "\fB\-finstrument\-functions\-once\fR" 4
  .IX Item "-finstrument-functions-once"
  This is similar to \fB\-finstrument\-functions\fR, but the profiling
  functions are called only once per instrumented function, i.e. the first
--- 16257,16267 ----
  .Sp
  A function may be given the attribute \f(CW\*(C`no_instrument_function\*(C'\fR, in
  which case this instrumentation is not done.  This can be used, for
! example, for the profiling functions listed above, high\-priority
  interrupt routines, and any functions from which the profiling functions
  cannot safely be called (perhaps signal handlers, if the profiling
  routines generate output or allocate memory).
! .IP \fB\-finstrument\-functions\-once\fR 4
  .IX Item "-finstrument-functions-once"
  This is similar to \fB\-finstrument\-functions\fR, but the profiling
  functions are called only once per instrumented function, i.e. the first
*************** functions are called at \fIleast\fR once
*** 16345,16351 ****
  once per thread, but the calls are always paired, that is to say, if a
  thread calls the first function, then it will call the second function,
  unless it never reaches the exit of the instrumented function.
! .IP "\fB\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,...\fR" 4
  .IX Item "-finstrument-functions-exclude-file-list=file,file,..."
  Set the list of functions that are excluded from instrumentation (see
  the description of \fB\-finstrument\-functions\fR).  If the file that
--- 16276,16282 ----
  once per thread, but the calls are always paired, that is to say, if a
  thread calls the first function, then it will call the second function,
  unless it never reaches the exit of the instrumented function.
! .IP \fB\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,...\fR 4
  .IX Item "-finstrument-functions-exclude-file-list=file,file,..."
  Set the list of functions that are excluded from instrumentation (see
  the description of \fB\-finstrument\-functions\fR).  If the file that
*************** contain \fI/bits/stl\fR or \fIinclude/sy
*** 16365,16415 ****
  .Sp
  If, for some reason, you want to include letter \fB,\fR in one of
  \&\fIsym\fR, write \fB,\fR. For example,
! \&\fB\-finstrument\-functions\-exclude\-file\-list=',,tmp'\fR
  (note the single quote surrounding the option).
! .IP "\fB\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,...\fR" 4
  .IX Item "-finstrument-functions-exclude-function-list=sym,sym,..."
  This is similar to \fB\-finstrument\-functions\-exclude\-file\-list\fR,
  but this option sets the list of function names to be excluded from
! instrumentation.  The function name to be matched is its user-visible
  name, such as \f(CW\*(C`vector blah(const vector &)\*(C'\fR, not the
  internal mangled name (e.g., \f(CW\*(C`_Z4blahRSt6vectorIiSaIiEE\*(C'\fR).  The
  match is done on substrings: if the \fIsym\fR parameter is a substring
! of the function name, it is considered to be a match.  For C99 and \*(C+
! extended identifiers, the function name must be given in \s-1UTF\-8,\s0 not
  using universal character names.
! .IP "\fB\-fpatchable\-function\-entry=\fR\fIN\fR\fB[,\fR\fIM\fR\fB]\fR" 4
  .IX Item "-fpatchable-function-entry=N[,M]"
  Generate \fIN\fR NOPs right at the beginning
! of each function, with the function entry point before the \fIM\fRth \s-1NOP.\s0
  If \fIM\fR is omitted, it defaults to \f(CW0\fR so the
! function entry points to the address just at the first \s-1NOP.\s0
! The \s-1NOP\s0 instructions reserve extra space which can be used to patch in
  any desired instrumentation at run time, provided that the code segment
  is writable.  The amount of space is controllable indirectly via
! the number of NOPs; the \s-1NOP\s0 instruction used corresponds to the instruction
! emitted by the internal \s-1GCC\s0 back-end interface \f(CW\*(C`gen_nop\*(C'\fR.  This behavior
! is target-specific and may also depend on the architecture variant and/or
  other compilation options.
  .Sp
! For run-time identification, the starting addresses of these areas,
  which correspond to their respective function entries minus \fIM\fR,
  are additionally collected in the \f(CW\*(C`_\|_patchable_function_entries\*(C'\fR
  section of the resulting binary.
  .Sp
  Note that the value of \f(CW\*(C`_\|_attribute_\|_ ((patchable_function_entry
! (N,M)))\*(C'\fR takes precedence over command-line option
  \&\fB\-fpatchable\-function\-entry=N,M\fR.  This can be used to increase
  the area size or to remove it completely on a single function.
  If \f(CW\*(C`N=0\*(C'\fR, no pad location is recorded.
  .Sp
! The \s-1NOP\s0 instructions are inserted at\-\-\-and maybe before, depending on
  \&\fIM\fR\-\-\-the function entry address, even before the prologue.  On
! PowerPC with the ELFv2 \s-1ABI,\s0 for a function with dual entry points,
  the local entry point is this function entry address.
  .Sp
  The maximum value of \fIN\fR and \fIM\fR is 65535.  On PowerPC with the
! ELFv2 \s-1ABI,\s0 for a function with dual entry points, the supported values
  for \fIM\fR are 0, 2, 6 and 14.
  .SS "Options Controlling the Preprocessor"
  .IX Subsection "Options Controlling the Preprocessor"
--- 16296,16346 ----
  .Sp
  If, for some reason, you want to include letter \fB,\fR in one of
  \&\fIsym\fR, write \fB,\fR. For example,
! \&\fB\-finstrument\-functions\-exclude\-file\-list=\*(Aq,,tmp\*(Aq\fR
  (note the single quote surrounding the option).
! .IP \fB\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,...\fR 4
  .IX Item "-finstrument-functions-exclude-function-list=sym,sym,..."
  This is similar to \fB\-finstrument\-functions\-exclude\-file\-list\fR,
  but this option sets the list of function names to be excluded from
! instrumentation.  The function name to be matched is its user\-visible
  name, such as \f(CW\*(C`vector blah(const vector &)\*(C'\fR, not the
  internal mangled name (e.g., \f(CW\*(C`_Z4blahRSt6vectorIiSaIiEE\*(C'\fR).  The
  match is done on substrings: if the \fIsym\fR parameter is a substring
! of the function name, it is considered to be a match.  For C99 and C++
! extended identifiers, the function name must be given in UTF\-8, not
  using universal character names.
! .IP \fB\-fpatchable\-function\-entry=\fR\fIN\fR\fB[,\fR\fIM\fR\fB]\fR 4
  .IX Item "-fpatchable-function-entry=N[,M]"
  Generate \fIN\fR NOPs right at the beginning
! of each function, with the function entry point before the \fIM\fRth NOP.
  If \fIM\fR is omitted, it defaults to \f(CW0\fR so the
! function entry points to the address just at the first NOP.
! The NOP instructions reserve extra space which can be used to patch in
  any desired instrumentation at run time, provided that the code segment
  is writable.  The amount of space is controllable indirectly via
! the number of NOPs; the NOP instruction used corresponds to the instruction
! emitted by the internal GCC back\-end interface \f(CW\*(C`gen_nop\*(C'\fR.  This behavior
! is target\-specific and may also depend on the architecture variant and/or
  other compilation options.
  .Sp
! For run\-time identification, the starting addresses of these areas,
  which correspond to their respective function entries minus \fIM\fR,
  are additionally collected in the \f(CW\*(C`_\|_patchable_function_entries\*(C'\fR
  section of the resulting binary.
  .Sp
  Note that the value of \f(CW\*(C`_\|_attribute_\|_ ((patchable_function_entry
! (N,M)))\*(C'\fR takes precedence over command\-line option
  \&\fB\-fpatchable\-function\-entry=N,M\fR.  This can be used to increase
  the area size or to remove it completely on a single function.
  If \f(CW\*(C`N=0\*(C'\fR, no pad location is recorded.
  .Sp
! The NOP instructions are inserted at\-\-\-and maybe before, depending on
  \&\fIM\fR\-\-\-the function entry address, even before the prologue.  On
! PowerPC with the ELFv2 ABI, for a function with dual entry points,
  the local entry point is this function entry address.
  .Sp
  The maximum value of \fIN\fR and \fIM\fR is 65535.  On PowerPC with the
! ELFv2 ABI, for a function with dual entry points, the supported values
  for \fIM\fR are 0, 2, 6 and 14.
  .SS "Options Controlling the Preprocessor"
  .IX Subsection "Options Controlling the Preprocessor"
*************** they appeared during translation phase t
*** 16436,16450 ****
  directive.  In particular, the definition is truncated by
  embedded newline characters.
  .Sp
! If you are invoking the preprocessor from a shell or shell-like
! program you may need to use the shell's quoting syntax to protect
  characters such as spaces that have a meaning in the shell syntax.
  .Sp
! If you wish to define a function-like macro on the command line, write
  its argument list with surrounding parentheses before the equals sign
  (if any).  Parentheses are meaningful to most shells, so you should
  quote the option.  With \fBsh\fR and \fBcsh\fR,
! \&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works.
  .Sp
  \&\fB\-D\fR and \fB\-U\fR options are processed in the order they
  are given on the command line.  All \fB\-imacros\fR \fIfile\fR and
--- 16367,16381 ----
  directive.  In particular, the definition is truncated by
  embedded newline characters.
  .Sp
! If you are invoking the preprocessor from a shell or shell\-like
! program you may need to use the shell\*(Aqs quoting syntax to protect
  characters such as spaces that have a meaning in the shell syntax.
  .Sp
! If you wish to define a function\-like macro on the command line, write
  its argument list with surrounding parentheses before the equals sign
  (if any).  Parentheses are meaningful to most shells, so you should
  quote the option.  With \fBsh\fR and \fBcsh\fR,
! \&\fB\-D\*(Aq\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB\*(Aq\fR works.
  .Sp
  \&\fB\-D\fR and \fB\-U\fR options are processed in the order they
  are given on the command line.  All \fB\-imacros\fR \fIfile\fR and
*************** provided with a \fB\-D\fR option.
*** 16458,16464 ****
  .IX Item "-include file"
  Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
  line of the primary source file.  However, the first directory searched
! for \fIfile\fR is the preprocessor's working directory \fIinstead of\fR
  the directory containing the main source file.  If not found there, it
  is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
  chain as normal.
--- 16389,16395 ----
  .IX Item "-include file"
  Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
  line of the primary source file.  However, the first directory searched
! for \fIfile\fR is the preprocessor\*(Aqs working directory \fIinstead of\fR
  the directory containing the main source file.  If not found there, it
  is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
  chain as normal.
*************** processing its declarations.
*** 16474,16497 ****
  .Sp
  All files specified by \fB\-imacros\fR are processed before all files
  specified by \fB\-include\fR.
! .IP "\fB\-undef\fR" 4
  .IX Item "-undef"
! Do not predefine any system-specific or GCC-specific macros.  The
  standard predefined macros remain defined.
! .IP "\fB\-pthread\fR" 4
  .IX Item "-pthread"
! Define additional macros required for using the \s-1POSIX\s0 threads library.
  You should use this option consistently for both compilation and linking.
  This option is supported on GNU/Linux targets, most other Unix derivatives,
  and also on x86 Cygwin and MinGW targets.
! .IP "\fB\-M\fR" 4
  .IX Item "-M"
  Instead of outputting the result of preprocessing, output a rule
  suitable for \fBmake\fR describing the dependencies of the main
  source file.  The preprocessor outputs one \fBmake\fR rule containing
  the object file name for that source file, a colon, and the names of all
  the included files, including those coming from \fB\-include\fR or
! \&\fB\-imacros\fR command-line options.
  .Sp
  Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
  object file name consists of the name of the source file with any
--- 16405,16428 ----
  .Sp
  All files specified by \fB\-imacros\fR are processed before all files
  specified by \fB\-include\fR.
! .IP \fB\-undef\fR 4
  .IX Item "-undef"
! Do not predefine any system\-specific or GCC\-specific macros.  The
  standard predefined macros remain defined.
! .IP \fB\-pthread\fR 4
  .IX Item "-pthread"
! Define additional macros required for using the POSIX threads library.
  You should use this option consistently for both compilation and linking.
  This option is supported on GNU/Linux targets, most other Unix derivatives,
  and also on x86 Cygwin and MinGW targets.
! .IP \fB\-M\fR 4
  .IX Item "-M"
  Instead of outputting the result of preprocessing, output a rule
  suitable for \fBmake\fR describing the dependencies of the main
  source file.  The preprocessor outputs one \fBmake\fR rule containing
  the object file name for that source file, a colon, and the names of all
  the included files, including those coming from \fB\-include\fR or
! \&\fB\-imacros\fR command\-line options.
  .Sp
  Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
  object file name consists of the name of the source file with any
*************** parts removed.  If there are many includ
*** 16500,16515 ****
  split into several lines using \fB\e\fR\-newline.  The rule has no
  commands.
  .Sp
! This option does not suppress the preprocessor's debug output, such as
  \&\fB\-dM\fR.  To avoid mixing such debug output with the dependency
  rules you should explicitly specify the dependency output file with
  \&\fB\-MF\fR, or use an environment variable like
! \&\fB\s-1DEPENDENCIES_OUTPUT\s0\fR.  Debug output
  is still sent to the regular output stream as normal.
  .Sp
  Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
  warnings with an implicit \fB\-w\fR.
! .IP "\fB\-MM\fR" 4
  .IX Item "-MM"
  Like \fB\-M\fR but do not mention header files that are found in
  system header directories, nor header files that are included,
--- 16431,16446 ----
  split into several lines using \fB\e\fR\-newline.  The rule has no
  commands.
  .Sp
! This option does not suppress the preprocessor\*(Aqs debug output, such as
  \&\fB\-dM\fR.  To avoid mixing such debug output with the dependency
  rules you should explicitly specify the dependency output file with
  \&\fB\-MF\fR, or use an environment variable like
! \&\fBDEPENDENCIES_OUTPUT\fR.  Debug output
  is still sent to the regular output stream as normal.
  .Sp
  Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
  warnings with an implicit \fB\-w\fR.
! .IP \fB\-MM\fR 4
  .IX Item "-MM"
  Like \fB\-M\fR but do not mention header files that are found in
  system header directories, nor header files that are included,
*************** When used with the driver options \fB\-M
*** 16529,16535 ****
  \&\fB\-MF\fR overrides the default dependency output file.
  .Sp
  If \fIfile\fR is \fI\-\fR, then the dependencies are written to \fIstdout\fR.
! .IP "\fB\-MG\fR" 4
  .IX Item "-MG"
  In conjunction with an option such as \fB\-M\fR requesting
  dependency generation, \fB\-MG\fR assumes missing header files are
--- 16460,16466 ----
  \&\fB\-MF\fR overrides the default dependency output file.
  .Sp
  If \fIfile\fR is \fI\-\fR, then the dependencies are written to \fIstdout\fR.
! .IP \fB\-MG\fR 4
  .IX Item "-MG"
  In conjunction with an option such as \fB\-M\fR requesting
  dependency generation, \fB\-MG\fR assumes missing header files are
*************** also suppresses preprocessed output, as
*** 16540,16551 ****
  this useless.
  .Sp
  This feature is used in automatic updating of makefiles.
! .IP "\fB\-Mno\-modules\fR" 4
  .IX Item "-Mno-modules"
  Disable dependency generation for compiled module interfaces.
! .IP "\fB\-MP\fR" 4
  .IX Item "-MP"
! This option instructs \s-1CPP\s0 to add a phony target for each dependency
  other than the main file, causing each to depend on nothing.  These
  dummy rules work around errors \fBmake\fR gives if you remove header
  files without updating the \fIMakefile\fR to match.
--- 16471,16482 ----
  this useless.
  .Sp
  This feature is used in automatic updating of makefiles.
! .IP \fB\-Mno\-modules\fR 4
  .IX Item "-Mno-modules"
  Disable dependency generation for compiled module interfaces.
! .IP \fB\-MP\fR 4
  .IX Item "-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 \fBmake\fR gives if you remove header
  files without updating the \fIMakefile\fR to match.
*************** This is typical output:
*** 16560,16574 ****
  .IP "\fB\-MT\fR \fItarget\fR" 4
  .IX Item "-MT target"
  Change the target of the rule emitted by dependency generation.  By
! default \s-1CPP\s0 takes the name of the main input file, deletes any
  directory components and any file suffix such as \fB.c\fR, and
! appends the platform's usual object suffix.  The result is the target.
  .Sp
  An \fB\-MT\fR option sets the target to be exactly the string you
  specify.  If you want multiple targets, you can specify them as a single
  argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
  .Sp
! For example, \fB\-MT\ '$(objpfx)foo.o'\fR might give
  .Sp
  .Vb 1
  \&        $(objpfx)foo.o: foo.c
--- 16491,16505 ----
  .IP "\fB\-MT\fR \fItarget\fR" 4
  .IX Item "-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 \fB.c\fR, and
! appends the platform\*(Aqs usual object suffix.  The result is the target.
  .Sp
  An \fB\-MT\fR option sets the target to be exactly the string you
  specify.  If you want multiple targets, you can specify them as a single
  argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
  .Sp
! For example, \fB\-MT\ \*(Aq$(objpfx)foo.o\*(Aq\fR might give
  .Sp
  .Vb 1
  \&        $(objpfx)foo.o: foo.c
*************** For example, \fB\-MT\ '$(objpfx)foo.o'\f
*** 16576,16582 ****
  .IP "\fB\-MQ\fR \fItarget\fR" 4
  .IX Item "-MQ target"
  Same as \fB\-MT\fR, but it quotes any characters which are special to
! Make.  \fB\-MQ\ '$(objpfx)foo.o'\fR gives
  .Sp
  .Vb 1
  \&        $$(objpfx)foo.o: foo.c
--- 16507,16513 ----
  .IP "\fB\-MQ\fR \fItarget\fR" 4
  .IX Item "-MQ target"
  Same as \fB\-MT\fR, but it quotes any characters which are special to
! Make.  \fB\-MQ\ \*(Aq$(objpfx)foo.o\*(Aq\fR gives
  .Sp
  .Vb 1
  \&        $$(objpfx)foo.o: foo.c
*************** Make.  \fB\-MQ\ '$(objpfx)foo.o'\fR give
*** 16584,16590 ****
  .Sp
  The default target is automatically quoted, as if it were given with
  \&\fB\-MQ\fR.
! .IP "\fB\-MD\fR" 4
  .IX Item "-MD"
  \&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
  \&\fB\-E\fR is not implied.  The driver determines \fIfile\fR based on
--- 16515,16521 ----
  .Sp
  The default target is automatically quoted, as if it were given with
  \&\fB\-MQ\fR.
! .IP \fB\-MD\fR 4
  .IX Item "-MD"
  \&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
  \&\fB\-E\fR is not implied.  The driver determines \fIfile\fR based on
*************** is understood to specify a target object
*** 16599,16609 ****
  .Sp
  Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
  a dependency output file as a side effect of the compilation process.
! .IP "\fB\-MMD\fR" 4
  .IX Item "-MMD"
  Like \fB\-MD\fR except mention only user header files, not system
  header files.
! .IP "\fB\-fpreprocessed\fR" 4
  .IX Item "-fpreprocessed"
  Indicate to the preprocessor that the input file has already been
  preprocessed.  This suppresses things like macro expansion, trigraph
--- 16530,16540 ----
  .Sp
  Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
  a dependency output file as a side effect of the compilation process.
! .IP \fB\-MMD\fR 4
  .IX Item "-MMD"
  Like \fB\-MD\fR except mention only user header files, not system
  header files.
! .IP \fB\-fpreprocessed\fR 4
  .IX Item "-fpreprocessed"
  Indicate to the preprocessor that the input file has already been
  preprocessed.  This suppresses things like macro expansion, trigraph
*************** a tokenizer for the front ends.
*** 16615,16627 ****
  .Sp
  \&\fB\-fpreprocessed\fR is implicit if the input file has one of the
  extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR.  These are the
! extensions that \s-1GCC\s0 uses for preprocessed files created by
  \&\fB\-save\-temps\fR.
! .IP "\fB\-fdirectives\-only\fR" 4
  .IX Item "-fdirectives-only"
  When preprocessing, handle directives, but do not expand macros.
  .Sp
! The option's behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
  options.
  .Sp
  With \fB\-E\fR, preprocessing is limited to the handling of directives
--- 16546,16558 ----
  .Sp
  \&\fB\-fpreprocessed\fR is implicit if the input file has one of the
  extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR.  These are the
! extensions that GCC uses for preprocessed files created by
  \&\fB\-save\-temps\fR.
! .IP \fB\-fdirectives\-only\fR 4
  .IX Item "-fdirectives-only"
  When preprocessing, handle directives, but do not expand macros.
  .Sp
! The option\*(Aqs behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
  options.
  .Sp
  With \fB\-E\fR, preprocessing is limited to the handling of directives
*************** files previously preprocessed with \f(CW
*** 16638,16664 ****
  With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
  \&\fB\-fpreprocessed\fR take precedence.  This enables full preprocessing of
  files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
! .IP "\fB\-fdollars\-in\-identifiers\fR" 4
  .IX Item "-fdollars-in-identifiers"
  Accept \fB$\fR in identifiers.
! .IP "\fB\-fextended\-identifiers\fR" 4
  .IX Item "-fextended-identifiers"
  Accept universal character names and extended characters in
  identifiers.  This option is enabled by default for C99 (and later C
! standard versions) and \*(C+.
! .IP "\fB\-fno\-canonical\-system\-headers\fR" 4
  .IX Item "-fno-canonical-system-headers"
  When preprocessing, do not shorten system header paths with canonicalization.
! .IP "\fB\-fmax\-include\-depth=\fR\fIdepth\fR" 4
  .IX Item "-fmax-include-depth=depth"
  Set the maximum depth of the nested #include. The default is 200.
! .IP "\fB\-ftabstop=\fR\fIwidth\fR" 4
  .IX Item "-ftabstop=width"
  Set the distance between tab stops.  This helps the preprocessor report
  correct column numbers in warnings or errors, even if tabs appear on the
  line.  If the value is less than 1 or greater than 100, the option is
  ignored.  The default is 8.
! .IP "\fB\-ftrack\-macro\-expansion\fR[\fB=\fR\fIlevel\fR]" 4
  .IX Item "-ftrack-macro-expansion[=level]"
  Track locations of tokens across macro expansions. This allows the
  compiler to emit diagnostic about the current macro expansion stack
--- 16569,16595 ----
  With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
  \&\fB\-fpreprocessed\fR take precedence.  This enables full preprocessing of
  files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
! .IP \fB\-fdollars\-in\-identifiers\fR 4
  .IX Item "-fdollars-in-identifiers"
  Accept \fB$\fR in identifiers.
! .IP \fB\-fextended\-identifiers\fR 4
  .IX Item "-fextended-identifiers"
  Accept universal character names and extended characters in
  identifiers.  This option is enabled by default for C99 (and later C
! standard versions) and C++.
! .IP \fB\-fno\-canonical\-system\-headers\fR 4
  .IX Item "-fno-canonical-system-headers"
  When preprocessing, do not shorten system header paths with canonicalization.
! .IP \fB\-fmax\-include\-depth=\fR\fIdepth\fR 4
  .IX Item "-fmax-include-depth=depth"
  Set the maximum depth of the nested #include. The default is 200.
! .IP \fB\-ftabstop=\fR\fIwidth\fR 4
  .IX Item "-ftabstop=width"
  Set the distance between tab stops.  This helps the preprocessor report
  correct column numbers in warnings or errors, even if tabs appear on the
  line.  If the value is less than 1 or greater than 100, the option is
  ignored.  The default is 8.
! .IP \fB\-ftrack\-macro\-expansion\fR[\fB=\fR\fIlevel\fR] 4
  .IX Item "-ftrack-macro-expansion[=level]"
  Track locations of tokens across macro expansions. This allows the
  compiler to emit diagnostic about the current macro expansion stack
*************** when a compilation error occurs in a mac
*** 16666,16746 ****
  option makes the preprocessor and the compiler consume more
  memory. The \fIlevel\fR parameter can be used to choose the level of
  precision of token location tracking thus decreasing the memory
! consumption if necessary. Value \fB0\fR of \fIlevel\fR de-activates
  this option. Value \fB1\fR tracks tokens locations in a
  degraded mode for the sake of minimal memory overhead. In this mode
  all tokens resulting from the expansion of an argument of a
! function-like macro have the same location. Value \fB2\fR tracks
  tokens locations completely. This value is the most memory hungry.
  When this option is given no argument, the default parameter value is
  \&\fB2\fR.
  .Sp
  Note that \f(CW\*(C`\-ftrack\-macro\-expansion=2\*(C'\fR is activated by default.
! .IP "\fB\-fmacro\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
  .IX Item "-fmacro-prefix-map=old=new"
! When preprocessing files residing in directory \fI\fIold\fI\fR,
  expand the \f(CW\*(C`_\|_FILE_\|_\*(C'\fR and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR macros as if the
! files resided in directory \fI\fInew\fI\fR instead.  This can be used
  to change an absolute path to a relative path by using \fI.\fR for
  \&\fInew\fR which can result in more reproducible builds that are
  location independent.  This option also affects
  \&\f(CW\*(C`_\|_builtin_FILE()\*(C'\fR during compilation.  See also
  \&\fB\-ffile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP "\fB\-fexec\-charset=\fR\fIcharset\fR" 4
  .IX Item "-fexec-charset=charset"
  Set the execution character set, used for string and character
! constants.  The default is \s-1UTF\-8.\s0  \fIcharset\fR can be any encoding
! supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP "\fB\-fwide\-exec\-charset=\fR\fIcharset\fR" 4
  .IX Item "-fwide-exec-charset=charset"
  Set the wide execution character set, used for wide string and
! character constants.  The default is one of \s-1UTF\-32BE, UTF\-32LE, UTF\-16BE,\s0
! or \s-1UTF\-16LE,\s0 whichever corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR and the
! big-endian or little-endian byte order being used for code generation.  As
  with \fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
! by the system's \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
  problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
! .IP "\fB\-finput\-charset=\fR\fIcharset\fR" 4
  .IX Item "-finput-charset=charset"
  Set the input character set, used for translation from the character
! set of the input file to the source character set used by \s-1GCC.\s0  If the
! locale does not specify, or \s-1GCC\s0 cannot get this information from the
! locale, the default is \s-1UTF\-8.\s0  This can be overridden by either the locale
! or this command-line option.  Currently the command-line option takes
! precedence if there's a conflict.  \fIcharset\fR can be any encoding
! supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP "\fB\-fpch\-deps\fR" 4
  .IX Item "-fpch-deps"
  When using precompiled headers, this flag
! causes the dependency-output flags to also list the files from the
! precompiled header's dependencies.  If not specified, only the
  precompiled header are listed and not the files that were used to
  create it, because those files are not consulted when a precompiled
  header is used.
! .IP "\fB\-fpch\-preprocess\fR" 4
  .IX Item "-fpch-preprocess"
  This option allows use of a precompiled header together with \fB\-E\fR.  It inserts a special \f(CW\*(C`#pragma\*(C'\fR,
! \&\f(CW\*(C`#pragma GCC pch_preprocess "\f(CIfilename\f(CW"\*(C'\fR in the output to mark
  the place where the precompiled header was found, and its \fIfilename\fR.
! When \fB\-fpreprocessed\fR is in use, \s-1GCC\s0 recognizes this \f(CW\*(C`#pragma\*(C'\fR
! and loads the \s-1PCH.\s0
  .Sp
  This option is off by default, because the resulting preprocessed output
! is only really suitable as input to \s-1GCC.\s0  It is switched on by
  \&\fB\-save\-temps\fR.
  .Sp
  You should not write this \f(CW\*(C`#pragma\*(C'\fR in your own code, but it is
! safe to edit the filename if the \s-1PCH\s0 file is available in a different
! location.  The filename may be absolute or it may be relative to \s-1GCC\s0's
  current directory.
! .IP "\fB\-fworking\-directory\fR" 4
  .IX Item "-fworking-directory"
  Enable generation of linemarkers in the preprocessor output that
  let the compiler know the current working directory at the time of
  preprocessing.  When this option is enabled, the preprocessor
  emits, after the initial linemarker, a second linemarker with the
! current working directory followed by two slashes.  \s-1GCC\s0 uses 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
--- 16597,16677 ----
  option makes the preprocessor and the compiler consume more
  memory. The \fIlevel\fR parameter can be used to choose the level of
  precision of token location tracking thus decreasing the memory
! consumption if necessary. Value \fB0\fR of \fIlevel\fR de\-activates
  this option. Value \fB1\fR tracks tokens locations in a
  degraded mode for the sake of minimal memory overhead. In this mode
  all tokens resulting from the expansion of an argument of a
! function\-like macro have the same location. Value \fB2\fR tracks
  tokens locations completely. This value is the most memory hungry.
  When this option is given no argument, the default parameter value is
  \&\fB2\fR.
  .Sp
  Note that \f(CW\*(C`\-ftrack\-macro\-expansion=2\*(C'\fR is activated by default.
! .IP \fB\-fmacro\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 4
  .IX Item "-fmacro-prefix-map=old=new"
! When preprocessing files residing in directory \fIold\fR,
  expand the \f(CW\*(C`_\|_FILE_\|_\*(C'\fR and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR macros as if the
! files resided in directory \fInew\fR instead.  This can be used
  to change an absolute path to a relative path by using \fI.\fR for
  \&\fInew\fR which can result in more reproducible builds that are
  location independent.  This option also affects
  \&\f(CW\*(C`_\|_builtin_FILE()\*(C'\fR during compilation.  See also
  \&\fB\-ffile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP \fB\-fexec\-charset=\fR\fIcharset\fR 4
  .IX Item "-fexec-charset=charset"
  Set the execution character set, used for string and character
! constants.  The default is UTF\-8.  \fIcharset\fR can be any encoding
! supported by the system\*(Aqs \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP \fB\-fwide\-exec\-charset=\fR\fIcharset\fR 4
  .IX Item "-fwide-exec-charset=charset"
  Set the wide execution character set, used for wide string and
! character constants.  The default is one of UTF\-32BE, UTF\-32LE, UTF\-16BE,
! or UTF\-16LE, whichever corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR and the
! big\-endian or little\-endian byte order being used for code generation.  As
  with \fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
! by the system\*(Aqs \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
  problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
! .IP \fB\-finput\-charset=\fR\fIcharset\fR 4
  .IX Item "-finput-charset=charset"
  Set the input character set, used for translation from the character
! set of the input file to the source character set used by 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\*(Aqs a conflict.  \fIcharset\fR can be any encoding
! supported by the system\*(Aqs \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP \fB\-fpch\-deps\fR 4
  .IX Item "-fpch-deps"
  When using precompiled headers, this flag
! causes the dependency\-output flags to also list the files from the
! precompiled header\*(Aqs dependencies.  If not specified, only the
  precompiled header are listed and not the files that were used to
  create it, because those files are not consulted when a precompiled
  header is used.
! .IP \fB\-fpch\-preprocess\fR 4
  .IX Item "-fpch-preprocess"
  This option allows use of a precompiled header together with \fB\-E\fR.  It inserts a special \f(CW\*(C`#pragma\*(C'\fR,
! \&\f(CW\*(C`#pragma GCC pch_preprocess "\fR\f(CIfilename\fR\f(CW"\*(C'\fR in the output to mark
  the place where the precompiled header was found, and its \fIfilename\fR.
! When \fB\-fpreprocessed\fR is in use, GCC recognizes this \f(CW\*(C`#pragma\*(C'\fR
! and loads the PCH.
  .Sp
  This option is off by default, because the resulting preprocessed output
! is only really suitable as input to GCC.  It is switched on by
  \&\fB\-save\-temps\fR.
  .Sp
  You should not write this \f(CW\*(C`#pragma\*(C'\fR in your own code, but it is
! safe to edit the filename if the PCH file is available in a different
! location.  The filename may be absolute or it may be relative to GCC\*(Aqs
  current directory.
! .IP \fB\-fworking\-directory\fR 4
  .IX Item "-fworking-directory"
  Enable generation of linemarkers in the preprocessor output that
  let the compiler know the current working directory at the time of
  preprocessing.  When this option is enabled, the preprocessor
  emits, after the initial linemarker, a second linemarker with the
! current working directory followed by two slashes.  GCC uses this
! directory, when it\*(Aqs 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
*************** it does not use shell special characters
*** 16757,16763 ****
  .IX Item "-A -predicate=answer"
  Cancel an assertion with the predicate \fIpredicate\fR and answer
  \&\fIanswer\fR.
! .IP "\fB\-C\fR" 4
  .IX Item "-C"
  Do not discard comments.  All comments are passed through to the output
  file, except for comments in processed directives, which are deleted
--- 16688,16694 ----
  .IX Item "-A -predicate=answer"
  Cancel an assertion with the predicate \fIpredicate\fR and answer
  \&\fIanswer\fR.
! .IP \fB\-C\fR 4
  .IX Item "-C"
  Do not discard comments.  All comments are passed through to the output
  file, except for comments in processed directives, which are deleted
*************** causes the preprocessor to treat comment
*** 16768,16811 ****
  For example, comments appearing at the start of what would be a
  directive line have the effect of turning that line into an ordinary
  source line, since the first token on the line is no longer a \fB#\fR.
! .IP "\fB\-CC\fR" 4
  .IX Item "-CC"
  Do not discard comments, including during macro expansion.  This is
  like \fB\-C\fR, except that comments contained within macros are
  also passed through to the output file where the macro is expanded.
  .Sp
  In addition to the side effects of the \fB\-C\fR option, the
! \&\fB\-CC\fR option causes all \*(C+\-style comments inside a macro
  to be converted to C\-style comments.  This is to prevent later use
  of that macro from inadvertently commenting out the remainder of
  the source line.
  .Sp
  The \fB\-CC\fR option is generally used to support lint comments.
! .IP "\fB\-P\fR" 4
  .IX Item "-P"
  Inhibit generation of linemarkers in the output from the preprocessor.
  This might be useful when running the preprocessor on something that is
  not C code, and will be sent to a program which might be confused by the
  linemarkers.
! .IP "\fB\-traditional\fR" 4
  .IX Item "-traditional"
  .PD 0
! .IP "\fB\-traditional\-cpp\fR" 4
  .IX Item "-traditional-cpp"
  .PD
! Try to imitate the behavior of pre-standard C preprocessors, as
! opposed to \s-1ISO C\s0 preprocessors.
! See the \s-1GNU CPP\s0 manual for details.
  .Sp
! Note that \s-1GCC\s0 does not otherwise attempt to emulate a pre-standard 
  C compiler, and these options are only supported with the \fB\-E\fR 
! switch, or when invoking \s-1CPP\s0 explicitly.
! .IP "\fB\-trigraphs\fR" 4
  .IX Item "-trigraphs"
! Support \s-1ISO C\s0 trigraphs.
! These are three-character sequences, all starting with \fB??\fR, that
! are defined by \s-1ISO C\s0 to stand for single characters.  For example,
! \&\fB??/\fR stands for \fB\e\fR, so \fB'??/n'\fR is a character
  constant for a newline.
  .Sp
  The nine trigraphs and their replacements are
--- 16699,16742 ----
  For example, comments appearing at the start of what would be a
  directive line have the effect of turning that line into an ordinary
  source line, since the first token on the line is no longer a \fB#\fR.
! .IP \fB\-CC\fR 4
  .IX Item "-CC"
  Do not discard comments, including during macro expansion.  This is
  like \fB\-C\fR, except that comments contained within macros are
  also passed through to the output file where the macro is expanded.
  .Sp
  In addition to the side effects of the \fB\-C\fR option, the
! \&\fB\-CC\fR option causes all C++\-style comments inside a macro
  to be converted to C\-style comments.  This is to prevent later use
  of that macro from inadvertently commenting out the remainder of
  the source line.
  .Sp
  The \fB\-CC\fR option is generally used to support lint comments.
! .IP \fB\-P\fR 4
  .IX Item "-P"
  Inhibit generation of linemarkers in the output from the preprocessor.
  This might be useful when running the preprocessor on something that is
  not C code, and will be sent to a program which might be confused by the
  linemarkers.
! .IP \fB\-traditional\fR 4
  .IX Item "-traditional"
  .PD 0
! .IP \fB\-traditional\-cpp\fR 4
  .IX Item "-traditional-cpp"
  .PD
! Try to imitate the behavior of pre\-standard C preprocessors, as
! opposed to ISO C preprocessors.
! See the GNU CPP manual for details.
  .Sp
! Note that GCC does not otherwise attempt to emulate a pre\-standard 
  C compiler, and these options are only supported with the \fB\-E\fR 
! switch, or when invoking CPP explicitly.
! .IP \fB\-trigraphs\fR 4
  .IX Item "-trigraphs"
! Support ISO C trigraphs.
! These are three\-character sequences, all starting with \fB??\fR, that
! are defined by ISO C to stand for single characters.  For example,
! \&\fB??/\fR stands for \fB\e\fR, so \fB\*(Aq??/n\*(Aq\fR is a character
  constant for a newline.
  .Sp
  The nine trigraphs and their replacements are
*************** The nine trigraphs and their replacement
*** 16815,16844 ****
  \&        Replacement:      [    ]    {    }    #    \e    ^    |    ~
  .Ve
  .Sp
! By default, \s-1GCC\s0 ignores trigraphs, but in
! standard-conforming modes it converts them.  See the \fB\-std\fR and
  \&\fB\-ansi\fR options.
! .IP "\fB\-remap\fR" 4
  .IX Item "-remap"
  Enable special code to work around file systems which only permit very
! short file names, such as MS-DOS.
! .IP "\fB\-H\fR" 4
  .IX Item "-H"
  Print the name of each header file used, in addition to other normal
  activities.  Each name is indented to show how deep in the
  \&\fB#include\fR stack it is.  Precompiled header files are also
  printed, even if they are found to be invalid; an invalid precompiled
  header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
! .IP "\fB\-d\fR\fIletters\fR" 4
  .IX Item "-dletters"
  Says to make debugging dumps during compilation as specified by
  \&\fIletters\fR.  The flags documented here are those relevant to the
  preprocessor.  Other \fIletters\fR are interpreted
! by the compiler proper, or reserved for future versions of \s-1GCC,\s0 and so
  are silently ignored.  If you specify \fIletters\fR whose behavior
  conflicts, the result is undefined.
  .RS 4
! .IP "\fB\-dM\fR" 4
  .IX Item "-dM"
  Instead of the normal output, generate a list of \fB#define\fR
  directives for all the macros defined during the execution of the
--- 16746,16775 ----
  \&        Replacement:      [    ]    {    }    #    \e    ^    |    ~
  .Ve
  .Sp
! By default, GCC ignores trigraphs, but in
! standard\-conforming modes it converts them.  See the \fB\-std\fR and
  \&\fB\-ansi\fR options.
! .IP \fB\-remap\fR 4
  .IX Item "-remap"
  Enable special code to work around file systems which only permit very
! short file names, such as MS\-DOS.
! .IP \fB\-H\fR 4
  .IX Item "-H"
  Print the name of each header file used, in addition to other normal
  activities.  Each name is indented to show how deep in the
  \&\fB#include\fR stack it is.  Precompiled header files are also
  printed, even if they are found to be invalid; an invalid precompiled
  header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
! .IP \fB\-d\fR\fIletters\fR 4
  .IX Item "-dletters"
  Says to make debugging dumps during compilation as specified by
  \&\fIletters\fR.  The flags documented here are those relevant to the
  preprocessor.  Other \fIletters\fR are interpreted
! by the compiler proper, or reserved for future versions of GCC, and so
  are silently ignored.  If you specify \fIletters\fR whose behavior
  conflicts, the result is undefined.
  .RS 4
! .IP \fB\-dM\fR 4
  .IX Item "-dM"
  Instead of the normal output, generate a list of \fB#define\fR
  directives for all the macros defined during the execution of the
*************** shows all the predefined macros.
*** 16854,16873 ****
  .Sp
  If you use \fB\-dM\fR without the \fB\-E\fR option, \fB\-dM\fR is
  interpreted as a synonym for \fB\-fdump\-rtl\-mach\fR.
! .IP "\fB\-dD\fR" 4
  .IX Item "-dD"
  Like \fB\-dM\fR except in two respects: it does \fInot\fR include the
  predefined macros, and it outputs \fIboth\fR the \fB#define\fR
  directives and the result of preprocessing.  Both kinds of output go to
  the standard output file.
! .IP "\fB\-dN\fR" 4
  .IX Item "-dN"
  Like \fB\-dD\fR, but emit only the macro names, not their expansions.
! .IP "\fB\-dI\fR" 4
  .IX Item "-dI"
  Output \fB#include\fR directives in addition to the result of
  preprocessing.
! .IP "\fB\-dU\fR" 4
  .IX Item "-dU"
  Like \fB\-dD\fR except that only macros that are expanded, or whose
  definedness is tested in preprocessor directives, are output; the
--- 16785,16804 ----
  .Sp
  If you use \fB\-dM\fR without the \fB\-E\fR option, \fB\-dM\fR is
  interpreted as a synonym for \fB\-fdump\-rtl\-mach\fR.
! .IP \fB\-dD\fR 4
  .IX Item "-dD"
  Like \fB\-dM\fR except in two respects: it does \fInot\fR include the
  predefined macros, and it outputs \fIboth\fR the \fB#define\fR
  directives and the result of preprocessing.  Both kinds of output go to
  the standard output file.
! .IP \fB\-dN\fR 4
  .IX Item "-dN"
  Like \fB\-dD\fR, but emit only the macro names, not their expansions.
! .IP \fB\-dI\fR 4
  .IX Item "-dI"
  Output \fB#include\fR directives in addition to the result of
  preprocessing.
! .IP \fB\-dU\fR 4
  .IX Item "-dU"
  Like \fB\-dD\fR except that only macros that are expanded, or whose
  definedness is tested in preprocessor directives, are output; the
*************** undefined at the time.
*** 16877,16929 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdebug\-cpp\fR" 4
  .IX Item "-fdebug-cpp"
! This option is only useful for debugging \s-1GCC.\s0  When used from \s-1CPP\s0 or with
  \&\fB\-E\fR, it dumps debugging information about location maps.  Every
  token in the output is preceded by the dump of the map its location
  belongs to.
  .Sp
! When used from \s-1GCC\s0 without \fB\-E\fR, this option has no effect.
! .IP "\fB\-Wp,\fR\fIoption\fR" 4
  .IX Item "-Wp,option"
  You can use \fB\-Wp,\fR\fIoption\fR to bypass the compiler driver
  and pass \fIoption\fR directly through to the preprocessor.  If
  \&\fIoption\fR contains commas, it is split into multiple options at the
  commas.  However, many options are modified, translated or interpreted
  by the compiler driver before being passed to the preprocessor, and
! \&\fB\-Wp\fR forcibly bypasses this phase.  The preprocessor's direct
  interface is undocumented and subject to change, so whenever possible
  you should avoid using \fB\-Wp\fR and let the driver handle the
  options instead.
  .IP "\fB\-Xpreprocessor\fR \fIoption\fR" 4
  .IX Item "-Xpreprocessor option"
  Pass \fIoption\fR as an option to the preprocessor.  You can use this to
! supply system-specific preprocessor options that \s-1GCC\s0 does not 
  recognize.
  .Sp
  If you want to pass an option that takes an argument, you must use
  \&\fB\-Xpreprocessor\fR twice, once for the option and once for the argument.
! .IP "\fB\-no\-integrated\-cpp\fR" 4
  .IX Item "-no-integrated-cpp"
  Perform preprocessing as a separate pass before compilation.
! By default, \s-1GCC\s0 performs preprocessing as an integrated part of
  input tokenization and parsing.
  If this option is provided, the appropriate language front end
! (\fBcc1\fR, \fBcc1plus\fR, or \fBcc1obj\fR for C, \*(C+,
! and Objective-C, respectively) is instead invoked twice,
  once for preprocessing only and once for actual compilation
  of the preprocessed input.
  This option may be useful in conjunction with the \fB\-B\fR or
  \&\fB\-wrapper\fR options to specify an alternate preprocessor or
  perform additional processing of the program source between
  normal preprocessing and compilation.
! .IP "\fB\-flarge\-source\-files\fR" 4
  .IX Item "-flarge-source-files"
! Adjust \s-1GCC\s0 to expect large source files, at the expense of slower
  compilation and higher memory usage.
  .Sp
! Specifically, \s-1GCC\s0 normally tracks both column numbers and line numbers
  within source files and it normally prints both of these numbers in
  diagnostics.  However, once it has processed a certain number of source
  lines, it stops tracking column numbers and only tracks line numbers.
--- 16808,16860 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-fdebug\-cpp\fR 4
  .IX Item "-fdebug-cpp"
! This option is only useful for debugging GCC.  When used from CPP or with
  \&\fB\-E\fR, it dumps debugging information about location maps.  Every
  token in the output is preceded by the dump of the map its location
  belongs to.
  .Sp
! When used from GCC without \fB\-E\fR, this option has no effect.
! .IP \fB\-Wp,\fR\fIoption\fR 4
  .IX Item "-Wp,option"
  You can use \fB\-Wp,\fR\fIoption\fR to bypass the compiler driver
  and pass \fIoption\fR directly through to the preprocessor.  If
  \&\fIoption\fR contains commas, it is split into multiple options at the
  commas.  However, many options are modified, translated or interpreted
  by the compiler driver before being passed to the preprocessor, and
! \&\fB\-Wp\fR forcibly bypasses this phase.  The preprocessor\*(Aqs direct
  interface is undocumented and subject to change, so whenever possible
  you should avoid using \fB\-Wp\fR and let the driver handle the
  options instead.
  .IP "\fB\-Xpreprocessor\fR \fIoption\fR" 4
  .IX Item "-Xpreprocessor option"
  Pass \fIoption\fR as an option to the preprocessor.  You can use this to
! supply system\-specific preprocessor options that GCC does not 
  recognize.
  .Sp
  If you want to pass an option that takes an argument, you must use
  \&\fB\-Xpreprocessor\fR twice, once for the option and once for the argument.
! .IP \fB\-no\-integrated\-cpp\fR 4
  .IX Item "-no-integrated-cpp"
  Perform preprocessing as a separate pass before compilation.
! By default, GCC performs preprocessing as an integrated part of
  input tokenization and parsing.
  If this option is provided, the appropriate language front end
! (\fBcc1\fR, \fBcc1plus\fR, or \fBcc1obj\fR for C, C++,
! and Objective\-C, respectively) is instead invoked twice,
  once for preprocessing only and once for actual compilation
  of the preprocessed input.
  This option may be useful in conjunction with the \fB\-B\fR or
  \&\fB\-wrapper\fR options to specify an alternate preprocessor or
  perform additional processing of the program source between
  normal preprocessing and compilation.
! .IP \fB\-flarge\-source\-files\fR 4
  .IX Item "-flarge-source-files"
! Adjust GCC to expect large source files, at the expense of slower
  compilation and higher memory usage.
  .Sp
! Specifically, GCC normally tracks both column numbers and line numbers
  within source files and it normally prints both of these numbers in
  diagnostics.  However, once it has processed a certain number of source
  lines, it stops tracking column numbers and only tracks line numbers.
*************** This means that diagnostics for later li
*** 16931,16948 ****
  It also means that options like \fB\-Wmisleading\-indentation\fR cease to work
  at that point, although the compiler prints a note if this happens.
  Passing \fB\-flarge\-source\-files\fR significantly increases the number
! of source lines that \s-1GCC\s0 can process before it stops tracking columns.
  .SS "Passing Options to the Assembler"
  .IX Subsection "Passing Options to the Assembler"
  You can pass options to the assembler.
! .IP "\fB\-Wa,\fR\fIoption\fR" 4
  .IX Item "-Wa,option"
  Pass \fIoption\fR as an option to the assembler.  If \fIoption\fR
  contains commas, it is split into multiple options at the commas.
  .IP "\fB\-Xassembler\fR \fIoption\fR" 4
  .IX Item "-Xassembler option"
  Pass \fIoption\fR as an option to the assembler.  You can use this to
! supply system-specific assembler options that \s-1GCC\s0 does not
  recognize.
  .Sp
  If you want to pass an option that takes an argument, you must use
--- 16862,16879 ----
  It also means that options like \fB\-Wmisleading\-indentation\fR cease to work
  at that point, although the compiler prints a note if this happens.
  Passing \fB\-flarge\-source\-files\fR significantly increases the number
! of source lines that GCC can process before it stops tracking columns.
  .SS "Passing Options to the Assembler"
  .IX Subsection "Passing Options to the Assembler"
  You can pass options to the assembler.
! .IP \fB\-Wa,\fR\fIoption\fR 4
  .IX Item "-Wa,option"
  Pass \fIoption\fR as an option to the assembler.  If \fIoption\fR
  contains commas, it is split into multiple options at the commas.
  .IP "\fB\-Xassembler\fR \fIoption\fR" 4
  .IX Item "-Xassembler option"
  Pass \fIoption\fR as an option to the assembler.  You can use this to
! supply system\-specific assembler options that GCC does not
  recognize.
  .Sp
  If you want to pass an option that takes an argument, you must use
*************** If you want to pass an option that takes
*** 16952,16980 ****
  These options come into play when the compiler links object files into
  an executable output file.  They are meaningless if the compiler is
  not doing a link step.
! .IP "\fIobject-file-name\fR" 4
  .IX Item "object-file-name"
  A file name that does not end in a special recognized suffix is
  considered to name an object file or library.  (Object files are
  distinguished from libraries by the linker according to the file
  contents.)  If linking is done, these object files are used as input
  to the linker.
! .IP "\fB\-c\fR" 4
  .IX Item "-c"
  .PD 0
! .IP "\fB\-S\fR" 4
  .IX Item "-S"
! .IP "\fB\-E\fR" 4
  .IX Item "-E"
  .PD
  If any of these options is used, then the linker is not run, and
  object file names should not be used as arguments.
! .IP "\fB\-flinker\-output=\fR\fItype\fR" 4
  .IX Item "-flinker-output=type"
! This option controls code generation of the link-time optimizer.  By
  default the linker output is automatically determined by the linker
  plugin.  For debugging the compiler and if incremental linking with a 
! non-LTO object file is desired, it may be useful to control the type
  manually.
  .Sp
  If \fItype\fR is \fBexec\fR, code generation produces a static
--- 16883,16911 ----
  These options come into play when the compiler links object files into
  an executable output file.  They are meaningless if the compiler is
  not doing a link step.
! .IP \fIobject\-file\-name\fR 4
  .IX Item "object-file-name"
  A file name that does not end in a special recognized suffix is
  considered to name an object file or library.  (Object files are
  distinguished from libraries by the linker according to the file
  contents.)  If linking is done, these object files are used as input
  to the linker.
! .IP \fB\-c\fR 4
  .IX Item "-c"
  .PD 0
! .IP \fB\-S\fR 4
  .IX Item "-S"
! .IP \fB\-E\fR 4
  .IX Item "-E"
  .PD
  If any of these options is used, then the linker is not run, and
  object file names should not be used as arguments.
! .IP \fB\-flinker\-output=\fR\fItype\fR 4
  .IX Item "-flinker-output=type"
! This option controls code generation of the link\-time optimizer.  By
  default the linker output is automatically determined by the linker
  plugin.  For debugging the compiler and if incremental linking with a 
! non\-LTO object file is desired, it may be useful to control the type
  manually.
  .Sp
  If \fItype\fR is \fBexec\fR, code generation produces a static
*************** disabled.
*** 16984,16990 ****
  If \fItype\fR is \fBdyn\fR, code generation produces a shared
  library.  In this case \fB\-fpic\fR or \fB\-fPIC\fR is preserved,
  but not enabled automatically.  This allows to build shared libraries
! without position-independent code on architectures where this is
  possible, i.e. on x86.
  .Sp
  If \fItype\fR is \fBpie\fR, code generation produces an \fB\-fpie\fR
--- 16915,16921 ----
  If \fItype\fR is \fBdyn\fR, code generation produces a shared
  library.  In this case \fB\-fpic\fR or \fB\-fPIC\fR is preserved,
  but not enabled automatically.  This allows to build shared libraries
! without position\-independent code on architectures where this is
  possible, i.e. on x86.
  .Sp
  If \fItype\fR is \fBpie\fR, code generation produces an \fB\-fpie\fR
*************** except that \fB\-fpie\fR is not disabled
*** 16993,17034 ****
  time.
  .Sp
  If \fItype\fR is \fBrel\fR, the compiler assumes that incremental linking is
! done.  The sections containing intermediate code for link-time optimization are
! merged, pre-optimized, and output to the resulting object file. In addition, if
  \&\fB\-ffat\-lto\-objects\fR is specified, binary code is produced for future
! non-LTO linking. The object file produced by incremental linking is smaller
  than a static library produced from the same object files.  At link time the
  result of incremental linking also loads faster than a static
  library assuming that the majority of objects in the library are used.
  .Sp
! Finally \fBnolto-rel\fR configures the compiler for incremental linking where
  code generation is forced, a final binary is produced, and the intermediate
! code for later link-time optimization is stripped. When multiple object files
  are linked together the resulting code is better optimized than with
! link-time optimizations disabled (for example, cross-module inlining 
  happens), but most of benefits of whole program optimizations are lost.
  .Sp
  During the incremental link (by \fB\-r\fR) the linker plugin defaults to
! \&\fBrel\fR. With current interfaces to \s-1GNU\s0 Binutils it is however not
! possible to incrementally link \s-1LTO\s0 objects and non-LTO objects into a single
  mixed object file.  If any of object files in incremental link cannot
! be used for link-time optimization, the linker plugin issues a warning and
! uses \fBnolto-rel\fR. To maintain whole program optimization, it is
  recommended to link such objects into static library instead. Alternatively it
! is possible to use H.J. Lu's binutils with support for mixed objects.
! .IP "\fB\-fuse\-ld=bfd\fR" 4
  .IX Item "-fuse-ld=bfd"
  Use the \fBbfd\fR linker instead of the default linker.
! .IP "\fB\-fuse\-ld=gold\fR" 4
  .IX Item "-fuse-ld=gold"
  Use the \fBgold\fR linker instead of the default linker.
! .IP "\fB\-fuse\-ld=lld\fR" 4
  .IX Item "-fuse-ld=lld"
! Use the \s-1LLVM\s0 \fBlld\fR linker instead of the default linker.
! .IP "\fB\-fuse\-ld=mold\fR" 4
  .IX Item "-fuse-ld=mold"
  Use the Modern Linker (\fBmold\fR) instead of the default linker.
! .IP "\fB\-l\fR\fIlibrary\fR" 4
  .IX Item "-llibrary"
  .PD 0
  .IP "\fB\-l\fR \fIlibrary\fR" 4
--- 16924,16965 ----
  time.
  .Sp
  If \fItype\fR is \fBrel\fR, the compiler assumes that incremental linking is
! done.  The sections containing intermediate code for link\-time optimization are
! merged, pre\-optimized, and output to the resulting object file. In addition, if
  \&\fB\-ffat\-lto\-objects\fR is specified, binary code is produced for future
! non\-LTO linking. The object file produced by incremental linking is smaller
  than a static library produced from the same object files.  At link time the
  result of incremental linking also loads faster than a static
  library assuming that the majority of objects in the library are used.
  .Sp
! Finally \fBnolto\-rel\fR configures the compiler for incremental linking where
  code generation is forced, a final binary is produced, and the intermediate
! code for later link\-time optimization is stripped. When multiple object files
  are linked together the resulting code is better optimized than with
! link\-time optimizations disabled (for example, cross\-module inlining 
  happens), but most of benefits of whole program optimizations are lost.
  .Sp
  During the incremental link (by \fB\-r\fR) the linker plugin defaults to
! \&\fBrel\fR. With current interfaces to GNU Binutils it is however not
! possible to incrementally link LTO objects and non\-LTO objects into a single
  mixed object file.  If any of object files in incremental link cannot
! be used for link\-time optimization, the linker plugin issues a warning and
! uses \fBnolto\-rel\fR. To maintain whole program optimization, it is
  recommended to link such objects into static library instead. Alternatively it
! is possible to use H.J. Lu\*(Aqs binutils with support for mixed objects.
! .IP \fB\-fuse\-ld=bfd\fR 4
  .IX Item "-fuse-ld=bfd"
  Use the \fBbfd\fR linker instead of the default linker.
! .IP \fB\-fuse\-ld=gold\fR 4
  .IX Item "-fuse-ld=gold"
  Use the \fBgold\fR linker instead of the default linker.
! .IP \fB\-fuse\-ld=lld\fR 4
  .IX Item "-fuse-ld=lld"
! Use the LLVM \fBlld\fR linker instead of the default linker.
! .IP \fB\-fuse\-ld=mold\fR 4
  .IX Item "-fuse-ld=mold"
  Use the Modern Linker (\fBmold\fR) instead of the default linker.
! .IP \fB\-l\fR\fIlibrary\fR 4
  .IX Item "-llibrary"
  .PD 0
  .IP "\fB\-l\fR \fIlibrary\fR" 4
*************** Use the Modern Linker (\fBmold\fR) inste
*** 17036,17054 ****
  .PD
  Search the library named \fIlibrary\fR when linking.  (The second
  alternative with the library as a separate argument is only for
! \&\s-1POSIX\s0 compliance and is not recommended.)
  .Sp
! The \fB\-l\fR option is passed directly to the linker by \s-1GCC.\s0  Refer
  to your linker documentation for exact details.  The general
! description below applies to the \s-1GNU\s0 linker.
  .Sp
  The linker searches a standard list of directories for the library.
  The directories searched include several standard system directories
  plus any that you specify with \fB\-L\fR.
  .Sp
  Static libraries are archives of object files, and have file names
! like \fIlib\fIlibrary\fI.a\fR.  Some targets also support shared
! libraries, which typically have names like \fIlib\fIlibrary\fI.so\fR.
  If both static and shared libraries are found, the linker gives
  preference to linking with the shared library unless the
  \&\fB\-static\fR option is used.
--- 16967,16985 ----
  .PD
  Search the library named \fIlibrary\fR when linking.  (The second
  alternative with the library as a separate argument is only for
! POSIX compliance and is not recommended.)
  .Sp
! The \fB\-l\fR option is passed directly to the linker by GCC.  Refer
  to your linker documentation for exact details.  The general
! description below applies to the GNU linker.
  .Sp
  The linker searches a standard list of directories for the library.
  The directories searched include several standard system directories
  plus any that you specify with \fB\-L\fR.
  .Sp
  Static libraries are archives of object files, and have file names
! like \fIliblibrary.a\fR.  Some targets also support shared
! libraries, which typically have names like \fIliblibrary.so\fR.
  If both static and shared libraries are found, the linker gives
  preference to linking with the shared library unless the
  \&\fB\-static\fR option is used.
*************** linker searches and processes libraries
*** 17058,17073 ****
  are specified.  Thus, \fBfoo.o \-lz bar.o\fR searches library \fBz\fR
  after file \fIfoo.o\fR but before \fIbar.o\fR.  If \fIbar.o\fR refers
  to functions in \fBz\fR, those functions may not be loaded.
! .IP "\fB\-lobjc\fR" 4
  .IX Item "-lobjc"
  You need this special case of the \fB\-l\fR option in order to
! link an Objective-C or Objective\-\*(C+ program.
! .IP "\fB\-nostartfiles\fR" 4
  .IX Item "-nostartfiles"
  Do not use the standard system startup files when linking.
  The standard system libraries are used normally, unless \fB\-nostdlib\fR,
  \&\fB\-nolibc\fR, or \fB\-nodefaultlibs\fR is used.
! .IP "\fB\-nodefaultlibs\fR" 4
  .IX Item "-nodefaultlibs"
  Do not use the standard system libraries when linking.
  Only the libraries you specify are passed to the linker, and options
--- 16989,17004 ----
  are specified.  Thus, \fBfoo.o \-lz bar.o\fR searches library \fBz\fR
  after file \fIfoo.o\fR but before \fIbar.o\fR.  If \fIbar.o\fR refers
  to functions in \fBz\fR, those functions may not be loaded.
! .IP \fB\-lobjc\fR 4
  .IX Item "-lobjc"
  You need this special case of the \fB\-l\fR option in order to
! link an Objective\-C or Objective\-C++ program.
! .IP \fB\-nostartfiles\fR 4
  .IX Item "-nostartfiles"
  Do not use the standard system startup files when linking.
  The standard system libraries are used normally, unless \fB\-nostdlib\fR,
  \&\fB\-nolibc\fR, or \fB\-nodefaultlibs\fR is used.
! .IP \fB\-nodefaultlibs\fR 4
  .IX Item "-nodefaultlibs"
  Do not use the standard system libraries when linking.
  Only the libraries you specify are passed to the linker, and options
*************** The compiler may generate calls to \f(CW
*** 17081,17087 ****
  These entries are usually resolved by entries in
  libc.  These entry points should be supplied through some other
  mechanism when this option is specified.
! .IP "\fB\-nolibc\fR" 4
  .IX Item "-nolibc"
  Do not use the C library or system libraries tightly coupled with it when
  linking.  Still link with the startup files, \fIlibgcc\fR or toolchain
--- 17012,17018 ----
  These entries are usually resolved by entries in
  libc.  These entry points should be supplied through some other
  mechanism when this option is specified.
! .IP \fB\-nolibc\fR 4
  .IX Item "-nolibc"
  Do not use the C library or system libraries tightly coupled with it when
  linking.  Still link with the startup files, \fIlibgcc\fR or toolchain
*************** or \fIlibstdc++\fR unless options preven
*** 17090,17098 ****
  well.  This typically removes \fB\-lc\fR from the link command line, as well
  as system libraries that normally go with it and become meaningless when
  absence of a C library is assumed, for example \fB\-lpthread\fR or
! \&\fB\-lm\fR in some configurations.  This is intended for bare-board
  targets when there is indeed no C library available.
! .IP "\fB\-nostdlib\fR" 4
  .IX Item "-nostdlib"
  Do not use the standard system startup files or libraries when linking.
  No startup files and only the libraries you specify are passed to
--- 17021,17029 ----
  well.  This typically removes \fB\-lc\fR from the link command line, as well
  as system libraries that normally go with it and become meaningless when
  absence of a C library is assumed, for example \fB\-lpthread\fR or
! \&\fB\-lm\fR in some configurations.  This is intended for bare\-board
  targets when there is indeed no C library available.
! .IP \fB\-nostdlib\fR 4
  .IX Item "-nostdlib"
  Do not use the standard system startup files or libraries when linking.
  No startup files and only the libraries you specify are passed to
*************** mechanism when this option is specified.
*** 17107,17144 ****
  .Sp
  One of the standard libraries bypassed by \fB\-nostdlib\fR and
  \&\fB\-nodefaultlibs\fR is \fIlibgcc.a\fR, a library of internal subroutines
! which \s-1GCC\s0 uses to overcome shortcomings of particular machines, or special
  needs for some languages.
  .Sp
  In most cases, you need \fIlibgcc.a\fR even when you want to avoid
  other standard libraries.  In other words, when you specify \fB\-nostdlib\fR
  or \fB\-nodefaultlibs\fR you should usually specify \fB\-lgcc\fR as well.
! This ensures that you have no unresolved references to internal \s-1GCC\s0
  library subroutines.
! (An example of such an internal subroutine is \f(CW\*(C`_\|_main\*(C'\fR, used to ensure \*(C+
  constructors are called.)
! .IP "\fB\-nostdlib++\fR" 4
  .IX Item "-nostdlib++"
! Do not implicitly link with standard \*(C+ libraries.
  .IP "\fB\-e\fR \fIentry\fR" 4
  .IX Item "-e entry"
  .PD 0
! .IP "\fB\-\-entry=\fR\fIentry\fR" 4
  .IX Item "--entry=entry"
  .PD
  Specify that the program entry point is \fIentry\fR.  The argument is
! interpreted by the linker; the \s-1GNU\s0 linker accepts either a symbol name
  or an address.
! .IP "\fB\-pie\fR" 4
  .IX Item "-pie"
  Produce a dynamically linked position independent executable on targets
  that support it.  For predictable results, you must also specify the same
  set of options used for compilation (\fB\-fpie\fR, \fB\-fPIE\fR,
  or model suboptions) when you specify this linker option.
! .IP "\fB\-no\-pie\fR" 4
  .IX Item "-no-pie"
! Don't produce a dynamically linked position independent executable.
! .IP "\fB\-static\-pie\fR" 4
  .IX Item "-static-pie"
  Produce a static position independent executable on targets that support
  it.  A static position independent executable is similar to a static
--- 17038,17075 ----
  .Sp
  One of the standard libraries bypassed by \fB\-nostdlib\fR and
  \&\fB\-nodefaultlibs\fR is \fIlibgcc.a\fR, a library of internal subroutines
! which GCC uses to overcome shortcomings of particular machines, or special
  needs for some languages.
  .Sp
  In most cases, you need \fIlibgcc.a\fR even when you want to avoid
  other standard libraries.  In other words, when you specify \fB\-nostdlib\fR
  or \fB\-nodefaultlibs\fR you should usually specify \fB\-lgcc\fR as well.
! This ensures that you have no unresolved references to internal GCC
  library subroutines.
! (An example of such an internal subroutine is \f(CW\*(C`_\|_main\*(C'\fR, used to ensure C++
  constructors are called.)
! .IP \fB\-nostdlib++\fR 4
  .IX Item "-nostdlib++"
! Do not implicitly link with standard C++ libraries.
  .IP "\fB\-e\fR \fIentry\fR" 4
  .IX Item "-e entry"
  .PD 0
! .IP \fB\-\-entry=\fR\fIentry\fR 4
  .IX Item "--entry=entry"
  .PD
  Specify that the program entry point is \fIentry\fR.  The argument is
! interpreted by the linker; the GNU linker accepts either a symbol name
  or an address.
! .IP \fB\-pie\fR 4
  .IX Item "-pie"
  Produce a dynamically linked position independent executable on targets
  that support it.  For predictable results, you must also specify the same
  set of options used for compilation (\fB\-fpie\fR, \fB\-fPIE\fR,
  or model suboptions) when you specify this linker option.
! .IP \fB\-no\-pie\fR 4
  .IX Item "-no-pie"
! Don\*(Aqt produce a dynamically linked position independent executable.
! .IP \fB\-static\-pie\fR 4
  .IX Item "-static-pie"
  Produce a static position independent executable on targets that support
  it.  A static position independent executable is similar to a static
*************** executable, but can be loaded at any add
*** 17146,17188 ****
  For predictable results, you must also specify the same set of options
  used for compilation (\fB\-fpie\fR, \fB\-fPIE\fR, or model
  suboptions) when you specify this linker option.
! .IP "\fB\-pthread\fR" 4
  .IX Item "-pthread"
! Link with the \s-1POSIX\s0 threads library.  This option is supported on 
  GNU/Linux targets, most other Unix derivatives, and also on 
  x86 Cygwin and MinGW targets.  On some targets this option also sets 
  flags for the preprocessor, so it should be used consistently for both
  compilation and linking.
! .IP "\fB\-r\fR" 4
  .IX Item "-r"
  Produce a relocatable object as output.  This is also known as partial
  linking.
! .IP "\fB\-rdynamic\fR" 4
  .IX Item "-rdynamic"
! Pass the flag \fB\-export\-dynamic\fR to the \s-1ELF\s0 linker, on targets
  that support it. This instructs the linker to add all symbols, not
  only used ones, to the dynamic symbol table. This option is needed
  for some uses of \f(CW\*(C`dlopen\*(C'\fR or to allow obtaining backtraces
  from within a program.
! .IP "\fB\-s\fR" 4
  .IX Item "-s"
  Remove all symbol table and relocation information from the executable.
! .IP "\fB\-static\fR" 4
  .IX Item "-static"
  On systems that support dynamic linking, this overrides \fB\-pie\fR
  and prevents linking with the shared libraries.  On other systems, this
  option has no effect.
! .IP "\fB\-shared\fR" 4
  .IX Item "-shared"
  Produce a shared object which can then be linked with other objects to
  form an executable.  Not all systems support this option.  For predictable
  results, you must also specify the same set of options used for compilation
  (\fB\-fpic\fR, \fB\-fPIC\fR, or model suboptions) when
  you specify this linker option.[1]
! .IP "\fB\-shared\-libgcc\fR" 4
  .IX Item "-shared-libgcc"
  .PD 0
! .IP "\fB\-static\-libgcc\fR" 4
  .IX Item "-static-libgcc"
  .PD
  On systems that provide \fIlibgcc\fR as a shared library, these options
--- 17077,17119 ----
  For predictable results, you must also specify the same set of options
  used for compilation (\fB\-fpie\fR, \fB\-fPIE\fR, or model
  suboptions) when you specify this linker option.
! .IP \fB\-pthread\fR 4
  .IX Item "-pthread"
! Link with the POSIX threads library.  This option is supported on 
  GNU/Linux targets, most other Unix derivatives, and also on 
  x86 Cygwin and MinGW targets.  On some targets this option also sets 
  flags for the preprocessor, so it should be used consistently for both
  compilation and linking.
! .IP \fB\-r\fR 4
  .IX Item "-r"
  Produce a relocatable object as output.  This is also known as partial
  linking.
! .IP \fB\-rdynamic\fR 4
  .IX Item "-rdynamic"
! Pass the flag \fB\-export\-dynamic\fR 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 \f(CW\*(C`dlopen\*(C'\fR or to allow obtaining backtraces
  from within a program.
! .IP \fB\-s\fR 4
  .IX Item "-s"
  Remove all symbol table and relocation information from the executable.
! .IP \fB\-static\fR 4
  .IX Item "-static"
  On systems that support dynamic linking, this overrides \fB\-pie\fR
  and prevents linking with the shared libraries.  On other systems, this
  option has no effect.
! .IP \fB\-shared\fR 4
  .IX Item "-shared"
  Produce a shared object which can then be linked with other objects to
  form an executable.  Not all systems support this option.  For predictable
  results, you must also specify the same set of options used for compilation
  (\fB\-fpic\fR, \fB\-fPIC\fR, or model suboptions) when
  you specify this linker option.[1]
! .IP \fB\-shared\-libgcc\fR 4
  .IX Item "-shared-libgcc"
  .PD 0
! .IP \fB\-static\-libgcc\fR 4
  .IX Item "-static-libgcc"
  .PD
  On systems that provide \fIlibgcc\fR as a shared library, these options
*************** across different shared libraries.  In t
*** 17197,17209 ****
  as well as the application itself should use the shared \fIlibgcc\fR.
  .Sp
  Therefore, the G++ driver automatically adds \fB\-shared\-libgcc\fR
! whenever you build a shared library or a main executable, because \*(C+
  programs typically use exceptions, so this is the right thing to do.
  .Sp
! If, instead, you use the \s-1GCC\s0 driver to create shared libraries, you may
  find that they are not always linked with the shared \fIlibgcc\fR.
! If \s-1GCC\s0 finds, at its configuration time, that you have a non-GNU linker
! or a \s-1GNU\s0 linker that does not support option \fB\-\-eh\-frame\-hdr\fR,
  it links the shared version of \fIlibgcc\fR into shared libraries
  by default.  Otherwise, it takes advantage of the linker and optimizes
  away the linking with the shared version of \fIlibgcc\fR, linking with
--- 17128,17140 ----
  as well as the application itself should use the shared \fIlibgcc\fR.
  .Sp
  Therefore, the G++ driver automatically adds \fB\-shared\-libgcc\fR
! whenever you build a shared library or a main executable, because C++
  programs typically use exceptions, so this is the right thing to do.
  .Sp
! If, instead, you use the GCC driver to create shared libraries, you may
  find that they are not always linked with the shared \fIlibgcc\fR.
! If GCC finds, at its configuration time, that you have a non\-GNU linker
! or a GNU linker that does not support option \fB\-\-eh\-frame\-hdr\fR,
  it links the shared version of \fIlibgcc\fR into shared libraries
  by default.  Otherwise, it takes advantage of the linker and optimizes
  away the linking with the shared version of \fIlibgcc\fR, linking with
*************** However, if a library or main executable
*** 17215,17259 ****
  exceptions, you must link it using the G++ driver, or using the option
  \&\fB\-shared\-libgcc\fR, such that it is linked with the shared
  \&\fIlibgcc\fR.
! .IP "\fB\-static\-libasan\fR" 4
  .IX Item "-static-libasan"
  When the \fB\-fsanitize=address\fR option is used to link a program,
! the \s-1GCC\s0 driver automatically links against \fBlibasan\fR.  If
  \&\fIlibasan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibasan\fR.  The \fB\-static\-libasan\fR option directs the \s-1GCC\s0
  driver to link \fIlibasan\fR statically, without necessarily linking
  other libraries statically.
! .IP "\fB\-static\-libtsan\fR" 4
  .IX Item "-static-libtsan"
  When the \fB\-fsanitize=thread\fR option is used to link a program,
! the \s-1GCC\s0 driver automatically links against \fBlibtsan\fR.  If
  \&\fIlibtsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibtsan\fR.  The \fB\-static\-libtsan\fR option directs the \s-1GCC\s0
  driver to link \fIlibtsan\fR statically, without necessarily linking
  other libraries statically.
! .IP "\fB\-static\-liblsan\fR" 4
  .IX Item "-static-liblsan"
  When the \fB\-fsanitize=leak\fR option is used to link a program,
! the \s-1GCC\s0 driver automatically links against \fBliblsan\fR.  If
  \&\fIliblsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIliblsan\fR.  The \fB\-static\-liblsan\fR option directs the \s-1GCC\s0
  driver to link \fIliblsan\fR statically, without necessarily linking
  other libraries statically.
! .IP "\fB\-static\-libubsan\fR" 4
  .IX Item "-static-libubsan"
  When the \fB\-fsanitize=undefined\fR option is used to link a program,
! the \s-1GCC\s0 driver automatically links against \fBlibubsan\fR.  If
  \&\fIlibubsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibubsan\fR.  The \fB\-static\-libubsan\fR option directs the \s-1GCC\s0
  driver to link \fIlibubsan\fR statically, without necessarily linking
  other libraries statically.
! .IP "\fB\-static\-libstdc++\fR" 4
  .IX Item "-static-libstdc++"
! When the \fBg++\fR program is used to link a \*(C+ program, it
  normally automatically links against \fBlibstdc++\fR.  If
  \&\fIlibstdc++\fR is available as a shared library, and the
  \&\fB\-static\fR option is not used, then this links against the
--- 17146,17190 ----
  exceptions, you must link it using the G++ driver, or using the option
  \&\fB\-shared\-libgcc\fR, such that it is linked with the shared
  \&\fIlibgcc\fR.
! .IP \fB\-static\-libasan\fR 4
  .IX Item "-static-libasan"
  When the \fB\-fsanitize=address\fR option is used to link a program,
! the GCC driver automatically links against \fBlibasan\fR.  If
  \&\fIlibasan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibasan\fR.  The \fB\-static\-libasan\fR option directs the GCC
  driver to link \fIlibasan\fR statically, without necessarily linking
  other libraries statically.
! .IP \fB\-static\-libtsan\fR 4
  .IX Item "-static-libtsan"
  When the \fB\-fsanitize=thread\fR option is used to link a program,
! the GCC driver automatically links against \fBlibtsan\fR.  If
  \&\fIlibtsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibtsan\fR.  The \fB\-static\-libtsan\fR option directs the GCC
  driver to link \fIlibtsan\fR statically, without necessarily linking
  other libraries statically.
! .IP \fB\-static\-liblsan\fR 4
  .IX Item "-static-liblsan"
  When the \fB\-fsanitize=leak\fR option is used to link a program,
! the GCC driver automatically links against \fBliblsan\fR.  If
  \&\fIliblsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIliblsan\fR.  The \fB\-static\-liblsan\fR option directs the GCC
  driver to link \fIliblsan\fR statically, without necessarily linking
  other libraries statically.
! .IP \fB\-static\-libubsan\fR 4
  .IX Item "-static-libubsan"
  When the \fB\-fsanitize=undefined\fR option is used to link a program,
! the GCC driver automatically links against \fBlibubsan\fR.  If
  \&\fIlibubsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibubsan\fR.  The \fB\-static\-libubsan\fR option directs the GCC
  driver to link \fIlibubsan\fR statically, without necessarily linking
  other libraries statically.
! .IP \fB\-static\-libstdc++\fR 4
  .IX Item "-static-libstdc++"
! When the \fBg++\fR program is used to link a C++ program, it
  normally automatically links against \fBlibstdc++\fR.  If
  \&\fIlibstdc++\fR is available as a shared library, and the
  \&\fB\-static\fR option is not used, then this links against the
*************** the program without going all the way to
*** 17263,17269 ****
  \&\fB\-static\-libstdc++\fR option directs the \fBg++\fR driver to
  link \fIlibstdc++\fR statically, without necessarily linking other
  libraries statically.
! .IP "\fB\-symbolic\fR" 4
  .IX Item "-symbolic"
  Bind references to global symbols when building a shared object.  Warn
  about any unresolved references (unless overridden by the link editor
--- 17194,17200 ----
  \&\fB\-static\-libstdc++\fR option directs the \fBg++\fR driver to
  link \fIlibstdc++\fR statically, without necessarily linking other
  libraries statically.
! .IP \fB\-symbolic\fR 4
  .IX Item "-symbolic"
  Bind references to global symbols when building a shared object.  Warn
  about any unresolved references (unless overridden by the link editor
*************** this option.
*** 17272,17305 ****
  .IP "\fB\-T\fR \fIscript\fR" 4
  .IX Item "-T script"
  Use \fIscript\fR as the linker script.  This option is supported by most
! systems using the \s-1GNU\s0 linker.  On some targets, such as bare-board
  targets without an operating system, the \fB\-T\fR option may be required
  when linking to avoid references to undefined symbols.
  .IP "\fB\-Xlinker\fR \fIoption\fR" 4
  .IX Item "-Xlinker option"
  Pass \fIoption\fR as an option to the linker.  You can use this to
! supply system-specific linker options that \s-1GCC\s0 does not recognize.
  .Sp
  If you want to pass an option that takes a separate argument, you must use
  \&\fB\-Xlinker\fR twice, once for the option and once for the argument.
  For example, to pass \fB\-assert definitions\fR, you must write
  \&\fB\-Xlinker \-assert \-Xlinker definitions\fR.  It does not work to write
! \&\fB\-Xlinker \*(L"\-assert definitions\*(R"\fR, because this passes the entire
  string as a single argument, which is not what the linker expects.
  .Sp
! When using the \s-1GNU\s0 linker, it is usually more convenient to pass
  arguments to linker options using the \fIoption\fR\fB=\fR\fIvalue\fR
  syntax than as separate arguments.  For example, you can specify
  \&\fB\-Xlinker \-Map=output.map\fR rather than
  \&\fB\-Xlinker \-Map \-Xlinker output.map\fR.  Other linkers may not support
! this syntax for command-line options.
! .IP "\fB\-Wl,\fR\fIoption\fR" 4
  .IX Item "-Wl,option"
  Pass \fIoption\fR as an option to the linker.  If \fIoption\fR contains
  commas, it is split into multiple options at the commas.  You can use this
  syntax to pass an argument to the option.
  For example, \fB\-Wl,\-Map,output.map\fR passes \fB\-Map output.map\fR to the
! linker.  When using the \s-1GNU\s0 linker, you can also get the same effect with
  \&\fB\-Wl,\-Map=output.map\fR.
  .IP "\fB\-u\fR \fIsymbol\fR" 4
  .IX Item "-u symbol"
--- 17203,17236 ----
  .IP "\fB\-T\fR \fIscript\fR" 4
  .IX Item "-T script"
  Use \fIscript\fR as the linker script.  This option is supported by most
! systems using the GNU linker.  On some targets, such as bare\-board
  targets without an operating system, the \fB\-T\fR option may be required
  when linking to avoid references to undefined symbols.
  .IP "\fB\-Xlinker\fR \fIoption\fR" 4
  .IX Item "-Xlinker option"
  Pass \fIoption\fR as an option to the linker.  You can use this to
! supply system\-specific linker options that GCC does not recognize.
  .Sp
  If you want to pass an option that takes a separate argument, you must use
  \&\fB\-Xlinker\fR twice, once for the option and once for the argument.
  For example, to pass \fB\-assert definitions\fR, you must write
  \&\fB\-Xlinker \-assert \-Xlinker definitions\fR.  It does not work to write
! \&\fB\-Xlinker "\-assert definitions"\fR, because this passes the entire
  string as a single argument, which is not what the linker expects.
  .Sp
! When using the GNU linker, it is usually more convenient to pass
  arguments to linker options using the \fIoption\fR\fB=\fR\fIvalue\fR
  syntax than as separate arguments.  For example, you can specify
  \&\fB\-Xlinker \-Map=output.map\fR rather than
  \&\fB\-Xlinker \-Map \-Xlinker output.map\fR.  Other linkers may not support
! this syntax for command\-line options.
! .IP \fB\-Wl,\fR\fIoption\fR 4
  .IX Item "-Wl,option"
  Pass \fIoption\fR as an option to the linker.  If \fIoption\fR contains
  commas, it is split into multiple options at the commas.  You can use this
  syntax to pass an argument to the option.
  For example, \fB\-Wl,\-Map,output.map\fR passes \fB\-Map output.map\fR to the
! linker.  When using the GNU linker, you can also get the same effect with
  \&\fB\-Wl,\-Map=output.map\fR.
  .IP "\fB\-u\fR \fIsymbol\fR" 4
  .IX Item "-u symbol"
*************** or \f(CW$SYSROOT\fR is replaced by the s
*** 17332,17371 ****
  \&\fB\-\-sysroot\fR and \fB\-isysroot\fR.
  .Sp
  Directories specified with \fB\-iquote\fR apply only to the quote 
! form of the directive, \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.
  Directories specified with \fB\-I\fR, \fB\-isystem\fR, 
  or \fB\-idirafter\fR apply to lookup for both the
! \&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR and
! \&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR directives.
  .Sp
  You can specify any number or combination of these options on the 
  command line to search for header files in several directories.  
  The lookup order is as follows:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  For the quote form of the include directive, the directory of the current
  file is searched first.
! .IP "2." 4
  .IX Item "2."
  For the quote form of the include directive, the directories specified
! by \fB\-iquote\fR options are searched in left-to-right order,
  as they appear on the command line.
! .IP "3." 4
  .IX Item "3."
  Directories specified with \fB\-I\fR options are scanned in
! left-to-right order.
! .IP "4." 4
  .IX Item "4."
  Directories specified with \fB\-isystem\fR options are scanned in
! left-to-right order.
! .IP "5." 4
  .IX Item "5."
  Standard system directories are scanned.
! .IP "6." 4
  .IX Item "6."
  Directories specified with \fB\-idirafter\fR options are scanned in
! left-to-right order.
  .RE
  .RS 4
  .Sp
--- 17263,17302 ----
  \&\fB\-\-sysroot\fR and \fB\-isysroot\fR.
  .Sp
  Directories specified with \fB\-iquote\fR apply only to the quote 
! form of the directive, \f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR.
  Directories specified with \fB\-I\fR, \fB\-isystem\fR, 
  or \fB\-idirafter\fR apply to lookup for both the
! \&\f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR and
! \&\f(CW\*(C`#include\ <\fR\f(CIfile\fR\f(CW>\*(C'\fR directives.
  .Sp
  You can specify any number or combination of these options on the 
  command line to search for header files in several directories.  
  The lookup order is as follows:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  For the quote form of the include directive, the directory of the current
  file is searched first.
! .IP 2. 4
  .IX Item "2."
  For the quote form of the include directive, the directories specified
! by \fB\-iquote\fR options are searched in left\-to\-right order,
  as they appear on the command line.
! .IP 3. 4
  .IX Item "3."
  Directories specified with \fB\-I\fR options are scanned in
! left\-to\-right order.
! .IP 4. 4
  .IX Item "4."
  Directories specified with \fB\-isystem\fR options are scanned in
! left\-to\-right order.
! .IP 5. 4
  .IX Item "5."
  Standard system directories are scanned.
! .IP 6. 4
  .IX Item "6."
  Directories specified with \fB\-idirafter\fR options are scanned in
! left\-to\-right order.
  .RE
  .RS 4
  .Sp
*************** You can use \fB\-I\fR to override a syst
*** 17373,17379 ****
  file, substituting your own version, since these directories are
  searched before the standard system header file directories.  
  However, you should
! not use this option to add directories that contain vendor-supplied
  system header files; use \fB\-isystem\fR for that.
  .Sp
  The \fB\-isystem\fR and \fB\-idirafter\fR options also mark the directory
--- 17304,17310 ----
  file, substituting your own version, since these directories are
  searched before the standard system header file directories.  
  However, you should
! not use this option to add directories that contain vendor\-supplied
  system header files; use \fB\-isystem\fR for that.
  .Sp
  The \fB\-isystem\fR and \fB\-idirafter\fR options also mark the directory
*************** If a standard system include directory,
*** 17384,17396 ****
  \&\fB\-isystem\fR, is also specified with \fB\-I\fR, the \fB\-I\fR
  option is ignored.  The directory is still searched but as a
  system directory at its normal position in the system include chain.
! This is to ensure that \s-1GCC\s0's procedure to fix buggy system headers and
  the ordering for the \f(CW\*(C`#include_next\*(C'\fR directive are not inadvertently
  changed.
  If you really need to change the search order for system directories,
  use the \fB\-nostdinc\fR and/or \fB\-isystem\fR options.
  .RE
! .IP "\fB\-I\-\fR" 4
  .IX Item "-I-"
  Split the include path.
  This option has been deprecated.  Please use \fB\-iquote\fR instead for
--- 17315,17327 ----
  \&\fB\-isystem\fR, is also specified with \fB\-I\fR, the \fB\-I\fR
  option is ignored.  The directory is still searched but as a
  system directory at its normal position in the system include chain.
! This is to ensure that GCC\*(Aqs procedure to fix buggy system headers and
  the ordering for the \f(CW\*(C`#include_next\*(C'\fR directive are not inadvertently
  changed.
  If you really need to change the search order for system directories,
  use the \fB\-nostdinc\fR and/or \fB\-isystem\fR options.
  .RE
! .IP \fB\-I\-\fR 4
  .IX Item "-I-"
  Split the include path.
  This option has been deprecated.  Please use \fB\-iquote\fR instead for
*************** option.
*** 17399,17411 ****
  .Sp
  Any directories specified with \fB\-I\fR
  options before \fB\-I\-\fR are searched only for headers requested with
! \&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
! \&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR.  If additional directories are
  specified with \fB\-I\fR options after the \fB\-I\-\fR, those
  directories are searched for all \fB#include\fR directives.
  .Sp
  In addition, \fB\-I\-\fR inhibits the use of the directory of the current
! file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.  There is no way to override this effect of \fB\-I\-\fR.
  .IP "\fB\-iprefix\fR \fIprefix\fR" 4
  .IX Item "-iprefix prefix"
  Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
--- 17330,17342 ----
  .Sp
  Any directories specified with \fB\-I\fR
  options before \fB\-I\-\fR are searched only for headers requested with
! \&\f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR; they are not searched for
! \&\f(CW\*(C`#include\ <\fR\f(CIfile\fR\f(CW>\*(C'\fR.  If additional directories are
  specified with \fB\-I\fR options after the \fB\-I\-\fR, those
  directories are searched for all \fB#include\fR directives.
  .Sp
  In addition, \fB\-I\-\fR inhibits the use of the directory of the current
! file directory as the first search directory for \f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR.  There is no way to override this effect of \fB\-I\-\fR.
  .IP "\fB\-iprefix\fR \fIprefix\fR" 4
  .IX Item "-iprefix prefix"
  Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
*************** information.
*** 17430,17459 ****
  .IP "\fB\-imultilib\fR \fIdir\fR" 4
  .IX Item "-imultilib dir"
  Use \fIdir\fR as a subdirectory of the directory containing
! target-specific \*(C+ headers.
! .IP "\fB\-nostdinc\fR" 4
  .IX Item "-nostdinc"
  Do not search the standard system directories for header files.
  Only the directories explicitly specified with \fB\-I\fR,
  \&\fB\-iquote\fR, \fB\-isystem\fR, and/or \fB\-idirafter\fR
  options (and the directory of the current file, if appropriate) 
  are searched.
! .IP "\fB\-nostdinc++\fR" 4
  .IX Item "-nostdinc++"
! Do not search for header files in the \*(C+\-specific standard directories,
  but do still search the other standard directories.  (This option is
! used when building the \*(C+ library.)
! .IP "\fB\-iplugindir=\fR\fIdir\fR" 4
  .IX Item "-iplugindir=dir"
  Set the directory to search for plugins that are passed
  by \fB\-fplugin=\fR\fIname\fR instead of
  \&\fB\-fplugin=\fR\fIpath\fR\fB/\fR\fIname\fR\fB.so\fR.  This option is not meant
  to be used by the user, but only passed by the driver.
! .IP "\fB\-L\fR\fIdir\fR" 4
  .IX Item "-Ldir"
  Add directory \fIdir\fR to the list of directories to be searched
  for \fB\-l\fR.
! .IP "\fB\-B\fR\fIprefix\fR" 4
  .IX Item "-Bprefix"
  This option specifies where to find the executables, libraries,
  include files, and data files of the compiler itself.
--- 17361,17390 ----
  .IP "\fB\-imultilib\fR \fIdir\fR" 4
  .IX Item "-imultilib dir"
  Use \fIdir\fR as a subdirectory of the directory containing
! target\-specific C++ headers.
! .IP \fB\-nostdinc\fR 4
  .IX Item "-nostdinc"
  Do not search the standard system directories for header files.
  Only the directories explicitly specified with \fB\-I\fR,
  \&\fB\-iquote\fR, \fB\-isystem\fR, and/or \fB\-idirafter\fR
  options (and the directory of the current file, if appropriate) 
  are searched.
! .IP \fB\-nostdinc++\fR 4
  .IX Item "-nostdinc++"
! Do not search for header files in the C++\-specific standard directories,
  but do still search the other standard directories.  (This option is
! used when building the C++ library.)
! .IP \fB\-iplugindir=\fR\fIdir\fR 4
  .IX Item "-iplugindir=dir"
  Set the directory to search for plugins that are passed
  by \fB\-fplugin=\fR\fIname\fR instead of
  \&\fB\-fplugin=\fR\fIpath\fR\fB/\fR\fIname\fR\fB.so\fR.  This option is not meant
  to be used by the user, but only passed by the driver.
! .IP \fB\-L\fR\fIdir\fR 4
  .IX Item "-Ldir"
  Add directory \fIdir\fR to the list of directories to be searched
  for \fB\-l\fR.
! .IP \fB\-B\fR\fIprefix\fR 4
  .IX Item "-Bprefix"
  This option specifies where to find the executables, libraries,
  include files, and data files of the compiler itself.
*************** is not specified, the driver tries two s
*** 17470,17476 ****
  \&\fI/usr/lib/gcc/\fR and \fI/usr/local/lib/gcc/\fR.  If neither of
  those results in a file name that is found, the unmodified program
  name is searched for using the directories specified in your
! \&\fB\s-1PATH\s0\fR environment variable.
  .Sp
  The compiler checks to see if the path provided by \fB\-B\fR
  refers to a directory, and if necessary it adds a directory
--- 17401,17407 ----
  \&\fI/usr/lib/gcc/\fR and \fI/usr/local/lib/gcc/\fR.  If neither of
  those results in a file name that is found, the unmodified program
  name is searched for using the directories specified in your
! \&\fBPATH\fR environment variable.
  .Sp
  The compiler checks to see if the path provided by \fB\-B\fR
  refers to a directory, and if necessary it adds a directory
*************** standard prefixes above are tried, and t
*** 17489,17531 ****
  out of the link if it is not found by those means.
  .Sp
  Another way to specify a prefix much like the \fB\-B\fR prefix is to use
! the environment variable \fB\s-1GCC_EXEC_PREFIX\s0\fR.
  .Sp
  As a special kludge, if the path provided by \fB\-B\fR is
! \&\fI[dir/]stage\fIN\fI/\fR, where \fIN\fR is a number in the range 0 to
  9, then it is replaced by \fI[dir/]include\fR.  This is to help
! with boot-strapping the compiler.
! .IP "\fB\-no\-canonical\-prefixes\fR" 4
  .IX Item "-no-canonical-prefixes"
  Do not expand any symbolic links, resolve references to \fB/../\fR
  or \fB/./\fR, or make the path absolute when generating a relative
  prefix.
! .IP "\fB\-\-sysroot=\fR\fIdir\fR" 4
  .IX Item "--sysroot=dir"
  Use \fIdir\fR as the logical root directory for headers and libraries.
  For example, if the compiler normally searches for headers in
  \&\fI/usr/include\fR and libraries in \fI/usr/lib\fR, it instead
! searches \fI\fIdir\fI/usr/include\fR and \fI\fIdir\fI/usr/lib\fR.
  .Sp
  If you use both this option and the \fB\-isysroot\fR option, then
  the \fB\-\-sysroot\fR option applies to libraries, but the
  \&\fB\-isysroot\fR option applies to header files.
  .Sp
! The \s-1GNU\s0 linker (beginning with version 2.16) has the necessary support
  for this option.  If your linker does not support this option, the
  header file aspect of \fB\-\-sysroot\fR still works, but the
  library aspect does not.
! .IP "\fB\-\-no\-sysroot\-suffix\fR" 4
  .IX Item "--no-sysroot-suffix"
  For some targets, a suffix is added to the root directory specified
  with \fB\-\-sysroot\fR, depending on the other options used, so that
  headers may for example be found in
! \&\fI\fIdir\fI/\fIsuffix\fI/usr/include\fR instead of
! \&\fI\fIdir\fI/usr/include\fR.  This option disables the addition of
  such a suffix.
  .SS "Options for Code Generation Conventions"
  .IX Subsection "Options for Code Generation Conventions"
! These machine-independent options control the interface conventions
  used in code generation.
  .PP
  Most of them have both positive and negative forms; the negative form
--- 17420,17462 ----
  out of the link if it is not found by those means.
  .Sp
  Another way to specify a prefix much like the \fB\-B\fR prefix is to use
! the environment variable \fBGCC_EXEC_PREFIX\fR.
  .Sp
  As a special kludge, if the path provided by \fB\-B\fR is
! \&\fI[dir/]stageN/\fR, where \fIN\fR is a number in the range 0 to
  9, then it is replaced by \fI[dir/]include\fR.  This is to help
! with boot\-strapping the compiler.
! .IP \fB\-no\-canonical\-prefixes\fR 4
  .IX Item "-no-canonical-prefixes"
  Do not expand any symbolic links, resolve references to \fB/../\fR
  or \fB/./\fR, or make the path absolute when generating a relative
  prefix.
! .IP \fB\-\-sysroot=\fR\fIdir\fR 4
  .IX Item "--sysroot=dir"
  Use \fIdir\fR as the logical root directory for headers and libraries.
  For example, if the compiler normally searches for headers in
  \&\fI/usr/include\fR and libraries in \fI/usr/lib\fR, it instead
! searches \fIdir/usr/include\fR and \fIdir/usr/lib\fR.
  .Sp
  If you use both this option and the \fB\-isysroot\fR option, then
  the \fB\-\-sysroot\fR option applies to libraries, but the
  \&\fB\-isysroot\fR option applies to header files.
  .Sp
! The 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 \fB\-\-sysroot\fR still works, but the
  library aspect does not.
! .IP \fB\-\-no\-sysroot\-suffix\fR 4
  .IX Item "--no-sysroot-suffix"
  For some targets, a suffix is added to the root directory specified
  with \fB\-\-sysroot\fR, depending on the other options used, so that
  headers may for example be found in
! \&\fIdir/suffix/usr/include\fR instead of
! \&\fIdir/usr/include\fR.  This option disables the addition of
  such a suffix.
  .SS "Options for Code Generation Conventions"
  .IX Subsection "Options for Code Generation Conventions"
! These machine\-independent options control the interface conventions
  used in code generation.
  .PP
  Most of them have both positive and negative forms; the negative form
*************** of \fB\-ffoo\fR is \fB\-fno\-foo\fR.  In
*** 17533,17539 ****
  one of the forms is listed\-\-\-the one that is not the default.  You
  can figure out the other form by either removing \fBno\-\fR or adding
  it.
! .IP "\fB\-fstack\-reuse=\fR\fIreuse-level\fR" 4
  .IX Item "-fstack-reuse=reuse-level"
  This option controls stack space reuse for user declared local/auto variables
  and compiler generated temporaries.  \fIreuse_level\fR can be \fBall\fR,
--- 17464,17470 ----
  one of the forms is listed\-\-\-the one that is not the default.  You
  can figure out the other form by either removing \fBno\-\fR or adding
  it.
! .IP \fB\-fstack\-reuse=\fR\fIreuse\-level\fR 4
  .IX Item "-fstack-reuse=reuse-level"
  This option controls stack space reuse for user declared local/auto variables
  and compiler generated temporaries.  \fIreuse_level\fR can be \fBall\fR,
*************** Another example:
*** 17601,17689 ****
  \&           }
  .Ve
  .Sp
! The lifetime of a compiler generated temporary is well defined by the \*(C+
  standard. When a lifetime of a temporary ends, and if the temporary lives
  in memory, the optimizing compiler has the freedom to reuse its stack
  space with other temporaries or scoped local variables whose live range
  does not overlap with it. However some of the legacy code relies on
! the behavior of older compilers in which temporaries' stack space is
  not reused, the aggressive stack reuse can lead to runtime errors. This
  option is used to control the temporary stack reuse optimization.
! .IP "\fB\-ftrapv\fR" 4
  .IX Item "-ftrapv"
  This option generates traps for signed overflow on addition, subtraction,
  multiplication operations.
  The options \fB\-ftrapv\fR and \fB\-fwrapv\fR override each other, so using
! \&\fB\-ftrapv\fR \fB\-fwrapv\fR on the command-line results in
  \&\fB\-fwrapv\fR being effective.  Note that only active options override, so
! using \fB\-ftrapv\fR \fB\-fwrapv\fR \fB\-fno\-wrapv\fR on the command-line
  results in \fB\-ftrapv\fR being effective.
! .IP "\fB\-fwrapv\fR" 4
  .IX Item "-fwrapv"
  This option instructs the compiler to assume that signed arithmetic
  overflow of addition, subtraction and multiplication wraps around
! using twos-complement representation.  This flag enables some optimizations
  and disables others.
  The options \fB\-ftrapv\fR and \fB\-fwrapv\fR override each other, so using
! \&\fB\-ftrapv\fR \fB\-fwrapv\fR on the command-line results in
  \&\fB\-fwrapv\fR being effective.  Note that only active options override, so
! using \fB\-ftrapv\fR \fB\-fwrapv\fR \fB\-fno\-wrapv\fR on the command-line
  results in \fB\-ftrapv\fR being effective.
! .IP "\fB\-fwrapv\-pointer\fR" 4
  .IX Item "-fwrapv-pointer"
  This option instructs the compiler to assume that pointer arithmetic
! overflow on addition and subtraction wraps around using twos-complement
  representation.  This flag disables some optimizations which assume
  pointer overflow is invalid.
! .IP "\fB\-fstrict\-overflow\fR" 4
  .IX Item "-fstrict-overflow"
  This option implies \fB\-fno\-wrapv\fR \fB\-fno\-wrapv\-pointer\fR and when
  negated implies \fB\-fwrapv\fR \fB\-fwrapv\-pointer\fR.
! .IP "\fB\-fexceptions\fR" 4
  .IX Item "-fexceptions"
  Enable exception handling.  Generates extra code needed to propagate
! exceptions.  For some targets, this implies \s-1GCC\s0 generates frame
  unwind information for all functions, which can produce significant data
  size overhead, although it does not affect execution.  If you do not
! specify this option, \s-1GCC\s0 enables it by default for languages like
! \&\*(C+ that normally require exception handling, and disables it for
  languages like C that do not normally require it.  However, you may need
  to enable this option when compiling C code that needs to interoperate
! properly with exception handlers written in \*(C+.  You may also wish to
! disable this option if you are compiling older \*(C+ programs that don't
  use exception handling.
! .IP "\fB\-fnon\-call\-exceptions\fR" 4
  .IX Item "-fnon-call-exceptions"
  Generate code that allows trapping instructions to throw exceptions.
! Note that this requires platform-specific runtime support that does
  not exist everywhere.  Moreover, it only allows \fItrapping\fR
! instructions to throw exceptions, i.e. memory references or floating-point
  instructions.  It does not allow exceptions to be thrown from
  arbitrary signal handlers such as \f(CW\*(C`SIGALRM\*(C'\fR.  This enables
  \&\fB\-fexceptions\fR.
! .IP "\fB\-fdelete\-dead\-exceptions\fR" 4
  .IX Item "-fdelete-dead-exceptions"
! Consider that instructions that may throw exceptions but don't otherwise
  contribute to the execution of the program can be optimized away.
  This does not affect calls to functions except those with the
  \&\f(CW\*(C`pure\*(C'\fR or \f(CW\*(C`const\*(C'\fR attributes.
! This option is enabled by default for the Ada and \*(C+ compilers, as permitted by
  the language specifications.
  Optimization passes that cause dead exceptions to be removed are enabled independently at different optimization levels.
! .IP "\fB\-funwind\-tables\fR" 4
  .IX Item "-funwind-tables"
  Similar to \fB\-fexceptions\fR, except that it just generates any needed
  static data, but does not affect the generated code in any other way.
  You normally do not need to enable this option; instead, a language processor
  that needs this handling enables it on your behalf.
! .IP "\fB\-fasynchronous\-unwind\-tables\fR" 4
  .IX Item "-fasynchronous-unwind-tables"
! Generate unwind table in \s-1DWARF\s0 format, if supported by target machine.  The
  table is exact at each instruction boundary, so it can be used for stack
  unwinding from asynchronous events (such as debugger or garbage collector).
! .IP "\fB\-fno\-gnu\-unique\fR" 4
  .IX Item "-fno-gnu-unique"
! On systems with recent \s-1GNU\s0 assembler and C library, the \*(C+ compiler
  uses the \f(CW\*(C`STB_GNU_UNIQUE\*(C'\fR binding to make sure that definitions
  of template static data members and static local variables in inline
  functions are unique even in the presence of \f(CW\*(C`RTLD_LOCAL\*(C'\fR; this
--- 17532,17620 ----
  \&           }
  .Ve
  .Sp
! The lifetime of a compiler generated temporary is well defined by the C++
  standard. When a lifetime of a temporary ends, and if the temporary lives
  in memory, the optimizing compiler has the freedom to reuse its stack
  space with other temporaries or scoped local variables whose live range
  does not overlap with it. However some of the legacy code relies on
! the behavior of older compilers in which temporaries\*(Aq stack space is
  not reused, the aggressive stack reuse can lead to runtime errors. This
  option is used to control the temporary stack reuse optimization.
! .IP \fB\-ftrapv\fR 4
  .IX Item "-ftrapv"
  This option generates traps for signed overflow on addition, subtraction,
  multiplication operations.
  The options \fB\-ftrapv\fR and \fB\-fwrapv\fR override each other, so using
! \&\fB\-ftrapv\fR \fB\-fwrapv\fR on the command\-line results in
  \&\fB\-fwrapv\fR being effective.  Note that only active options override, so
! using \fB\-ftrapv\fR \fB\-fwrapv\fR \fB\-fno\-wrapv\fR on the command\-line
  results in \fB\-ftrapv\fR being effective.
! .IP \fB\-fwrapv\fR 4
  .IX Item "-fwrapv"
  This option instructs the compiler to assume that signed arithmetic
  overflow of addition, subtraction and multiplication wraps around
! using twos\-complement representation.  This flag enables some optimizations
  and disables others.
  The options \fB\-ftrapv\fR and \fB\-fwrapv\fR override each other, so using
! \&\fB\-ftrapv\fR \fB\-fwrapv\fR on the command\-line results in
  \&\fB\-fwrapv\fR being effective.  Note that only active options override, so
! using \fB\-ftrapv\fR \fB\-fwrapv\fR \fB\-fno\-wrapv\fR on the command\-line
  results in \fB\-ftrapv\fR being effective.
! .IP \fB\-fwrapv\-pointer\fR 4
  .IX Item "-fwrapv-pointer"
  This option instructs the compiler to assume that pointer arithmetic
! overflow on addition and subtraction wraps around using twos\-complement
  representation.  This flag disables some optimizations which assume
  pointer overflow is invalid.
! .IP \fB\-fstrict\-overflow\fR 4
  .IX Item "-fstrict-overflow"
  This option implies \fB\-fno\-wrapv\fR \fB\-fno\-wrapv\-pointer\fR and when
  negated implies \fB\-fwrapv\fR \fB\-fwrapv\-pointer\fR.
! .IP \fB\-fexceptions\fR 4
  .IX Item "-fexceptions"
  Enable exception handling.  Generates extra code needed to propagate
! exceptions.  For some targets, this implies GCC generates frame
  unwind information for all functions, which can produce significant data
  size overhead, although it does not affect execution.  If you do not
! specify this option, GCC enables it by default for languages like
! C++ that normally require exception handling, and disables it for
  languages like C that do not normally require it.  However, you may need
  to enable this option when compiling C code that needs to interoperate
! properly with exception handlers written in C++.  You may also wish to
! disable this option if you are compiling older C++ programs that don\*(Aqt
  use exception handling.
! .IP \fB\-fnon\-call\-exceptions\fR 4
  .IX Item "-fnon-call-exceptions"
  Generate code that allows trapping instructions to throw exceptions.
! Note that this requires platform\-specific runtime support that does
  not exist everywhere.  Moreover, it only allows \fItrapping\fR
! instructions to throw exceptions, i.e. memory references or floating\-point
  instructions.  It does not allow exceptions to be thrown from
  arbitrary signal handlers such as \f(CW\*(C`SIGALRM\*(C'\fR.  This enables
  \&\fB\-fexceptions\fR.
! .IP \fB\-fdelete\-dead\-exceptions\fR 4
  .IX Item "-fdelete-dead-exceptions"
! Consider that instructions that may throw exceptions but don\*(Aqt otherwise
  contribute to the execution of the program can be optimized away.
  This does not affect calls to functions except those with the
  \&\f(CW\*(C`pure\*(C'\fR or \f(CW\*(C`const\*(C'\fR attributes.
! This option is enabled by default for the Ada and C++ compilers, as permitted by
  the language specifications.
  Optimization passes that cause dead exceptions to be removed are enabled independently at different optimization levels.
! .IP \fB\-funwind\-tables\fR 4
  .IX Item "-funwind-tables"
  Similar to \fB\-fexceptions\fR, except that it just generates any needed
  static data, but does not affect the generated code in any other way.
  You normally do not need to enable this option; instead, a language processor
  that needs this handling enables it on your behalf.
! .IP \fB\-fasynchronous\-unwind\-tables\fR 4
  .IX Item "-fasynchronous-unwind-tables"
! Generate unwind table in DWARF format, if supported by target machine.  The
  table is exact at each instruction boundary, so it can be used for stack
  unwinding from asynchronous events (such as debugger or garbage collector).
! .IP \fB\-fno\-gnu\-unique\fR 4
  .IX Item "-fno-gnu-unique"
! On systems with recent GNU assembler and C library, the C++ compiler
  uses the \f(CW\*(C`STB_GNU_UNIQUE\*(C'\fR binding to make sure that definitions
  of template static data members and static local variables in inline
  functions are unique even in the presence of \f(CW\*(C`RTLD_LOCAL\*(C'\fR; this
*************** is necessary to avoid problems with a li
*** 17691,17705 ****
  \&\f(CW\*(C`RTLD_LOCAL\*(C'\fR plugins depending on a definition in one of them and
  therefore disagreeing with the other one about the binding of the
  symbol.  But this causes \f(CW\*(C`dlclose\*(C'\fR to be ignored for affected
! DSOs; if your program relies on reinitialization of a \s-1DSO\s0 via
  \&\f(CW\*(C`dlclose\*(C'\fR and \f(CW\*(C`dlopen\*(C'\fR, you can use
  \&\fB\-fno\-gnu\-unique\fR.
! .IP "\fB\-fpcc\-struct\-return\fR" 4
  .IX Item "-fpcc-struct-return"
! Return \*(L"short\*(R" \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in memory like
  longer ones, rather than in registers.  This convention is less
  efficient, but it has the advantage of allowing intercallability between
! GCC-compiled files and files compiled with other compilers, particularly
  the Portable C Compiler (pcc).
  .Sp
  The precise convention for returning structures in memory depends
--- 17622,17636 ----
  \&\f(CW\*(C`RTLD_LOCAL\*(C'\fR plugins depending on a definition in one of them and
  therefore disagreeing with the other one about the binding of the
  symbol.  But this causes \f(CW\*(C`dlclose\*(C'\fR to be ignored for affected
! DSOs; if your program relies on reinitialization of a DSO via
  \&\f(CW\*(C`dlclose\*(C'\fR and \f(CW\*(C`dlopen\*(C'\fR, you can use
  \&\fB\-fno\-gnu\-unique\fR.
! .IP \fB\-fpcc\-struct\-return\fR 4
  .IX Item "-fpcc-struct-return"
! Return "short" \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in memory like
  longer ones, rather than in registers.  This convention is less
  efficient, but it has the advantage of allowing intercallability between
! GCC\-compiled files and files compiled with other compilers, particularly
  the Portable C Compiler (pcc).
  .Sp
  The precise convention for returning structures in memory depends
*************** that of some integer type.
*** 17711,17753 ****
  \&\fBWarning:\fR code compiled with the \fB\-fpcc\-struct\-return\fR
  switch is not binary compatible with code compiled with the
  \&\fB\-freg\-struct\-return\fR switch.
! Use it to conform to a non-default application binary interface.
! .IP "\fB\-freg\-struct\-return\fR" 4
  .IX Item "-freg-struct-return"
  Return \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in registers when possible.
  This is more efficient for small structures than
  \&\fB\-fpcc\-struct\-return\fR.
  .Sp
  If you specify neither \fB\-fpcc\-struct\-return\fR nor
! \&\fB\-freg\-struct\-return\fR, \s-1GCC\s0 defaults to whichever convention is
! standard for the target.  If there is no standard convention, \s-1GCC\s0
! defaults to \fB\-fpcc\-struct\-return\fR, except on targets where \s-1GCC\s0 is
  the principal compiler.  In those cases, we can choose the standard, and
  we chose the more efficient register return alternative.
  .Sp
  \&\fBWarning:\fR code compiled with the \fB\-freg\-struct\-return\fR
  switch is not binary compatible with code compiled with the
  \&\fB\-fpcc\-struct\-return\fR switch.
! Use it to conform to a non-default application binary interface.
! .IP "\fB\-fshort\-enums\fR" 4
  .IX Item "-fshort-enums"
  Allocate to an \f(CW\*(C`enum\*(C'\fR type only as many bytes as it needs for the
  declared range of possible values.  Specifically, the \f(CW\*(C`enum\*(C'\fR type
  is equivalent to the smallest integer type that has enough room.
  .Sp
! \&\fBWarning:\fR the \fB\-fshort\-enums\fR switch causes \s-1GCC\s0 to generate
  code that is not binary compatible with code generated without that switch.
! Use it to conform to a non-default application binary interface.
! .IP "\fB\-fshort\-wchar\fR" 4
  .IX Item "-fshort-wchar"
  Override the underlying type for \f(CW\*(C`wchar_t\*(C'\fR to be \f(CW\*(C`short
  unsigned int\*(C'\fR instead of the default for the target.  This option is
! useful for building programs to run under \s-1WINE.\s0
  .Sp
! \&\fBWarning:\fR the \fB\-fshort\-wchar\fR switch causes \s-1GCC\s0 to generate
  code that is not binary compatible with code generated without that switch.
! Use it to conform to a non-default application binary interface.
! .IP "\fB\-fcommon\fR" 4
  .IX Item "-fcommon"
  In C code, this option controls the placement of global variables
  defined without an initializer, known as \fItentative definitions\fR
--- 17642,17684 ----
  \&\fBWarning:\fR code compiled with the \fB\-fpcc\-struct\-return\fR
  switch is not binary compatible with code compiled with the
  \&\fB\-freg\-struct\-return\fR switch.
! Use it to conform to a non\-default application binary interface.
! .IP \fB\-freg\-struct\-return\fR 4
  .IX Item "-freg-struct-return"
  Return \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in registers when possible.
  This is more efficient for small structures than
  \&\fB\-fpcc\-struct\-return\fR.
  .Sp
  If you specify neither \fB\-fpcc\-struct\-return\fR nor
! \&\fB\-freg\-struct\-return\fR, GCC defaults to whichever convention is
! standard for the target.  If there is no standard convention, GCC
! defaults to \fB\-fpcc\-struct\-return\fR, 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.
  .Sp
  \&\fBWarning:\fR code compiled with the \fB\-freg\-struct\-return\fR
  switch is not binary compatible with code compiled with the
  \&\fB\-fpcc\-struct\-return\fR switch.
! Use it to conform to a non\-default application binary interface.
! .IP \fB\-fshort\-enums\fR 4
  .IX Item "-fshort-enums"
  Allocate to an \f(CW\*(C`enum\*(C'\fR type only as many bytes as it needs for the
  declared range of possible values.  Specifically, the \f(CW\*(C`enum\*(C'\fR type
  is equivalent to the smallest integer type that has enough room.
  .Sp
! \&\fBWarning:\fR the \fB\-fshort\-enums\fR switch causes 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.
! .IP \fB\-fshort\-wchar\fR 4
  .IX Item "-fshort-wchar"
  Override the underlying type for \f(CW\*(C`wchar_t\*(C'\fR to be \f(CW\*(C`short
  unsigned int\*(C'\fR instead of the default for the target.  This option is
! useful for building programs to run under WINE.
  .Sp
! \&\fBWarning:\fR the \fB\-fshort\-wchar\fR 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.
! .IP \fB\-fcommon\fR 4
  .IX Item "-fcommon"
  In C code, this option controls the placement of global variables
  defined without an initializer, known as \fItentative definitions\fR
*************** in the C standard.  Tentative definition
*** 17755,17782 ****
  of a variable with the \f(CW\*(C`extern\*(C'\fR keyword, which do not allocate storage.
  .Sp
  The default is \fB\-fno\-common\fR, which specifies that the compiler places
! uninitialized global variables in the \s-1BSS\s0 section of the object file.
  This inhibits the merging of tentative definitions by the linker so you get a
! multiple-definition error if the same variable is accidentally defined in more
  than one compilation unit.
  .Sp
  The \fB\-fcommon\fR places uninitialized global variables in a common block.
  This allows the linker to resolve all tentative definitions of the same variable
! in different compilation units to the same object, or to a non-tentative
! definition.  This behavior is inconsistent with \*(C+, and on many targets implies
  a speed and code size penalty on global variable references.  It is mainly
  useful to enable legacy code to link without errors.
! .IP "\fB\-fno\-ident\fR" 4
  .IX Item "-fno-ident"
  Ignore the \f(CW\*(C`#ident\*(C'\fR directive.
! .IP "\fB\-finhibit\-size\-directive\fR" 4
  .IX Item "-finhibit-size-directive"
! Don't output a \f(CW\*(C`.size\*(C'\fR assembler directive, or anything else that
  would cause trouble if the function is split in the middle, and the
  two halves are placed at locations far apart in memory.  This option is
  used when compiling \fIcrtstuff.c\fR; you should not need to use it
  for anything else.
! .IP "\fB\-fverbose\-asm\fR" 4
  .IX Item "-fverbose-asm"
  Put extra commentary information in the generated assembly code to
  make it more readable.  This option is generally only of use to those
--- 17686,17713 ----
  of a variable with the \f(CW\*(C`extern\*(C'\fR keyword, which do not allocate storage.
  .Sp
  The default is \fB\-fno\-common\fR, which specifies that the compiler places
! uninitialized global variables in the BSS section of the object file.
  This inhibits the merging of tentative definitions by the linker so you get a
! multiple\-definition error if the same variable is accidentally defined in more
  than one compilation unit.
  .Sp
  The \fB\-fcommon\fR places uninitialized global variables in a common block.
  This allows the linker to resolve all tentative definitions of the same variable
! in different compilation units to the same object, or to a non\-tentative
! definition.  This behavior is inconsistent with C++, and on many targets implies
  a speed and code size penalty on global variable references.  It is mainly
  useful to enable legacy code to link without errors.
! .IP \fB\-fno\-ident\fR 4
  .IX Item "-fno-ident"
  Ignore the \f(CW\*(C`#ident\*(C'\fR directive.
! .IP \fB\-finhibit\-size\-directive\fR 4
  .IX Item "-finhibit-size-directive"
! Don\*(Aqt output a \f(CW\*(C`.size\*(C'\fR assembler directive, or anything else that
  would cause trouble if the function is split in the middle, and the
  two halves are placed at locations far apart in memory.  This option is
  used when compiling \fIcrtstuff.c\fR; you should not need to use it
  for anything else.
! .IP \fB\-fverbose\-asm\fR 4
  .IX Item "-fverbose-asm"
  Put extra commentary information in the generated assembly code to
  make it more readable.  This option is generally only of use to those
*************** files.
*** 17789,17801 ****
  .Sp
  The added comments include:
  .RS 4
! .IP "*" 4
! information on the compiler version and command-line options,
! .IP "*" 4
  the source code lines associated with the assembly instructions,
! in the form \s-1FILENAME:LINENUMBER:CONTENT OF LINE,\s0
! .IP "*" 4
! hints on which high-level expressions correspond to
  the various assembly instruction operands.
  .RE
  .RS 4
--- 17720,17732 ----
  .Sp
  The added comments include:
  .RS 4
! .IP * 4
! information on the compiler version and command\-line options,
! .IP * 4
  the source code lines associated with the assembly instructions,
! in the form FILENAME:LINENUMBER:CONTENT OF LINE,
! .IP * 4
! hints on which high\-level expressions correspond to
  the various assembly instruction operands.
  .RE
  .RS 4
*************** gives output similar to this:
*** 17866,17970 ****
  The comments are intended for humans rather than machines and hence the
  precise format of the comments is subject to change.
  .RE
! .IP "\fB\-frecord\-gcc\-switches\fR" 4
  .IX Item "-frecord-gcc-switches"
  This switch causes the command line used to invoke the
  compiler to be recorded into the object file that is being created.
  This switch is only implemented on some targets and the exact format
  of the recording is target and binary file format dependent, but it
! usually takes the form of a section containing \s-1ASCII\s0 text.  This
  switch is related to the \fB\-fverbose\-asm\fR switch, but that
  switch only records information in the assembler output file as
  comments, so it never reaches the object file.
  See also \fB\-grecord\-gcc\-switches\fR for another
  way of storing compiler options into the object file.
! .IP "\fB\-fpic\fR" 4
  .IX Item "-fpic"
! Generate position-independent code (\s-1PIC\s0) suitable for use in a shared
  library, if supported for the target machine.  Such code accesses all
! constant addresses through a global offset table (\s-1GOT\s0).  The dynamic
! loader resolves the \s-1GOT\s0 entries when the program starts (the dynamic
! loader is not part of \s-1GCC\s0; it is part of the operating system).  If
! the \s-1GOT\s0 size for the linked executable exceeds a machine-specific
  maximum size, you get an error message from the linker indicating that
  \&\fB\-fpic\fR does not work; in that case, recompile with \fB\-fPIC\fR
! instead.  (These maximums are 8k on the \s-1SPARC,\s0 28k on AArch64 and 32k
! on the m68k and \s-1RS/6000.\s0  The x86 has no such limit.)
  .Sp
! Position-independent code requires special support, and therefore works
! only on certain machines.  For the x86, \s-1GCC\s0 supports \s-1PIC\s0 for System V
! but not for the Sun 386i.  Code generated for the \s-1IBM RS/6000\s0 is always
! position-independent.
  .Sp
  When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
  are defined to 1.
! .IP "\fB\-fPIC\fR" 4
  .IX Item "-fPIC"
! If supported for the target machine, emit position-independent code,
  suitable for dynamic linking and avoiding any limit on the size of the
  global offset table.  This option makes a difference on AArch64, m68k,
! PowerPC and \s-1SPARC.\s0
  .Sp
! Position-independent code requires special support, and therefore works
  only on certain machines.
  .Sp
  When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
  are defined to 2.
! .IP "\fB\-fpie\fR" 4
  .IX Item "-fpie"
  .PD 0
! .IP "\fB\-fPIE\fR" 4
  .IX Item "-fPIE"
  .PD
  These options are similar to \fB\-fpic\fR and \fB\-fPIC\fR, but the
! generated position-independent code can be only linked into executables.
  Usually these options are used to compile code that will be linked using
! the \fB\-pie\fR \s-1GCC\s0 option.
  .Sp
  \&\fB\-fpie\fR and \fB\-fPIE\fR both define the macros
  \&\f(CW\*(C`_\|_pie_\|_\*(C'\fR and \f(CW\*(C`_\|_PIE_\|_\*(C'\fR.  The macros have the value 1
  for \fB\-fpie\fR and 2 for \fB\-fPIE\fR.
! .IP "\fB\-fno\-plt\fR" 4
  .IX Item "-fno-plt"
! Do not use the \s-1PLT\s0 for external function calls in position-independent code.
! Instead, load the callee address at call sites from the \s-1GOT\s0 and branch to it.
! This leads to more efficient code by eliminating \s-1PLT\s0 stubs and exposing
! \&\s-1GOT\s0 loads to optimizations.  On architectures such as 32\-bit x86 where
! \&\s-1PLT\s0 stubs expect the \s-1GOT\s0 pointer in a specific register, this gives more
  register allocation freedom to the compiler.
! Lazy binding requires use of the \s-1PLT\s0; 
  with \fB\-fno\-plt\fR all external symbols are resolved at load time.
  .Sp
  Alternatively, the function attribute \f(CW\*(C`noplt\*(C'\fR can be used to avoid calls
! through the \s-1PLT\s0 for specific external functions.
  .Sp
! In position-dependent code, a few targets also convert calls to
! functions that are marked to not use the \s-1PLT\s0 to use the \s-1GOT\s0 instead.
! .IP "\fB\-fno\-jump\-tables\fR" 4
  .IX Item "-fno-jump-tables"
  Do not use jump tables for switch statements even where it would be
  more efficient than other code generation strategies.  This option is
  of use in conjunction with \fB\-fpic\fR or \fB\-fPIC\fR for
  building code that forms part of a dynamic linker and cannot
  reference the address of a jump table.  On some targets, jump tables
! do not require a \s-1GOT\s0 and this option is not needed.
! .IP "\fB\-fno\-bit\-tests\fR" 4
  .IX Item "-fno-bit-tests"
  Do not use bit tests for switch statements even where it would be
  more efficient than other code generation strategies.
! .IP "\fB\-ffixed\-\fR\fIreg\fR" 4
  .IX Item "-ffixed-reg"
  Treat the register named \fIreg\fR as a fixed register; generated code
  should never refer to it (except perhaps as a stack pointer, frame
  pointer or in some other fixed role).
  .Sp
  \&\fIreg\fR must be the name of a register.  The register names accepted
! are machine-specific and are defined in the \f(CW\*(C`REGISTER_NAMES\*(C'\fR
  macro in the machine description macro file.
  .Sp
  This flag does not have a negative form, because it specifies a
! three-way choice.
! .IP "\fB\-fcall\-used\-\fR\fIreg\fR" 4
  .IX Item "-fcall-used-reg"
  Treat the register named \fIreg\fR as an allocable register that is
  clobbered by function calls.  It may be allocated for temporaries or
--- 17797,17901 ----
  The comments are intended for humans rather than machines and hence the
  precise format of the comments is subject to change.
  .RE
! .IP \fB\-frecord\-gcc\-switches\fR 4
  .IX Item "-frecord-gcc-switches"
  This switch causes the command line used to invoke the
  compiler to be recorded into the object file that is being created.
  This switch is only implemented on some targets and the exact format
  of the recording is target and binary file format dependent, but it
! usually takes the form of a section containing ASCII text.  This
  switch is related to the \fB\-fverbose\-asm\fR switch, but that
  switch only records information in the assembler output file as
  comments, so it never reaches the object file.
  See also \fB\-grecord\-gcc\-switches\fR for another
  way of storing compiler options into the object file.
! .IP \fB\-fpic\fR 4
  .IX Item "-fpic"
! Generate position\-independent code (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
  \&\fB\-fpic\fR does not work; in that case, recompile with \fB\-fPIC\fR
! instead.  (These maximums are 8k on the SPARC, 28k on AArch64 and 32k
! on the m68k and RS/6000.  The x86 has no such limit.)
  .Sp
! Position\-independent code requires special support, and therefore works
! only on certain machines.  For the x86, GCC supports PIC for System V
! but not for the Sun 386i.  Code generated for the IBM RS/6000 is always
! position\-independent.
  .Sp
  When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
  are defined to 1.
! .IP \fB\-fPIC\fR 4
  .IX Item "-fPIC"
! If supported for the target machine, emit position\-independent code,
  suitable for dynamic linking and avoiding any limit on the size of the
  global offset table.  This option makes a difference on AArch64, m68k,
! PowerPC and SPARC.
  .Sp
! Position\-independent code requires special support, and therefore works
  only on certain machines.
  .Sp
  When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
  are defined to 2.
! .IP \fB\-fpie\fR 4
  .IX Item "-fpie"
  .PD 0
! .IP \fB\-fPIE\fR 4
  .IX Item "-fPIE"
  .PD
  These options are similar to \fB\-fpic\fR and \fB\-fPIC\fR, but the
! generated position\-independent code can be only linked into executables.
  Usually these options are used to compile code that will be linked using
! the \fB\-pie\fR GCC option.
  .Sp
  \&\fB\-fpie\fR and \fB\-fPIE\fR both define the macros
  \&\f(CW\*(C`_\|_pie_\|_\*(C'\fR and \f(CW\*(C`_\|_PIE_\|_\*(C'\fR.  The macros have the value 1
  for \fB\-fpie\fR and 2 for \fB\-fPIE\fR.
! .IP \fB\-fno\-plt\fR 4
  .IX Item "-fno-plt"
! Do not use the PLT for external function calls in position\-independent code.
! Instead, load the callee address at call sites from the GOT and branch to it.
! This leads to more efficient code by eliminating PLT stubs and exposing
! GOT loads to optimizations.  On architectures such as 32\-bit x86 where
! PLT stubs expect the GOT pointer in a specific register, this gives more
  register allocation freedom to the compiler.
! Lazy binding requires use of the PLT; 
  with \fB\-fno\-plt\fR all external symbols are resolved at load time.
  .Sp
  Alternatively, the function attribute \f(CW\*(C`noplt\*(C'\fR can be used to avoid calls
! through the PLT for specific external functions.
  .Sp
! In position\-dependent code, a few targets also convert calls to
! functions that are marked to not use the PLT to use the GOT instead.
! .IP \fB\-fno\-jump\-tables\fR 4
  .IX Item "-fno-jump-tables"
  Do not use jump tables for switch statements even where it would be
  more efficient than other code generation strategies.  This option is
  of use in conjunction with \fB\-fpic\fR or \fB\-fPIC\fR for
  building code that forms part of a dynamic linker and cannot
  reference the address of a jump table.  On some targets, jump tables
! do not require a GOT and this option is not needed.
! .IP \fB\-fno\-bit\-tests\fR 4
  .IX Item "-fno-bit-tests"
  Do not use bit tests for switch statements even where it would be
  more efficient than other code generation strategies.
! .IP \fB\-ffixed\-\fR\fIreg\fR 4
  .IX Item "-ffixed-reg"
  Treat the register named \fIreg\fR as a fixed register; generated code
  should never refer to it (except perhaps as a stack pointer, frame
  pointer or in some other fixed role).
  .Sp
  \&\fIreg\fR must be the name of a register.  The register names accepted
! are machine\-specific and are defined in the \f(CW\*(C`REGISTER_NAMES\*(C'\fR
  macro in the machine description macro file.
  .Sp
  This flag does not have a negative form, because it specifies a
! three\-way choice.
! .IP \fB\-fcall\-used\-\fR\fIreg\fR 4
  .IX Item "-fcall-used-reg"
  Treat the register named \fIreg\fR as an allocable register that is
  clobbered by function calls.  It may be allocated for temporaries or
*************** do not save and restore the register \fI
*** 17973,17983 ****
  .Sp
  It is an error to use this flag with the frame pointer or stack pointer.
  Use of this flag for other registers that have fixed pervasive roles in
! the machine's execution model produces disastrous results.
  .Sp
  This flag does not have a negative form, because it specifies a
! three-way choice.
! .IP "\fB\-fcall\-saved\-\fR\fIreg\fR" 4
  .IX Item "-fcall-saved-reg"
  Treat the register named \fIreg\fR as an allocable register saved by
  functions.  It may be allocated even for temporaries or variables that
--- 17904,17914 ----
  .Sp
  It is an error to use this flag with the frame pointer or stack pointer.
  Use of this flag for other registers that have fixed pervasive roles in
! the machine\*(Aqs execution model produces disastrous results.
  .Sp
  This flag does not have a negative form, because it specifies a
! three\-way choice.
! .IP \fB\-fcall\-saved\-\fR\fIreg\fR 4
  .IX Item "-fcall-saved-reg"
  Treat the register named \fIreg\fR as an allocable register saved by
  functions.  It may be allocated even for temporaries or variables that
*************** the register \fIreg\fR if they use it.
*** 17986,17999 ****
  .Sp
  It is an error to use this flag with the frame pointer or stack pointer.
  Use of this flag for other registers that have fixed pervasive roles in
! the machine's execution model produces disastrous results.
  .Sp
  A different sort of disaster results from the use of this flag for
  a register in which function values may be returned.
  .Sp
  This flag does not have a negative form, because it specifies a
! three-way choice.
! .IP "\fB\-fpack\-struct[=\fR\fIn\fR\fB]\fR" 4
  .IX Item "-fpack-struct[=n]"
  Without a value specified, pack all structure members together without
  holes.  When a value is specified (which must be a small power of two), pack
--- 17917,17930 ----
  .Sp
  It is an error to use this flag with the frame pointer or stack pointer.
  Use of this flag for other registers that have fixed pervasive roles in
! the machine\*(Aqs execution model produces disastrous results.
  .Sp
  A different sort of disaster results from the use of this flag for
  a register in which function values may be returned.
  .Sp
  This flag does not have a negative form, because it specifies a
! three\-way choice.
! .IP \fB\-fpack\-struct[=\fR\fIn\fR\fB]\fR 4
  .IX Item "-fpack-struct[=n]"
  Without a value specified, pack all structure members together without
  holes.  When a value is specified (which must be a small power of two), pack
*************** structure members according to this valu
*** 18001,18036 ****
  alignment (that is, objects with default alignment requirements larger than
  this are output potentially unaligned at the next fitting location.
  .Sp
! \&\fBWarning:\fR the \fB\-fpack\-struct\fR switch causes \s-1GCC\s0 to generate
  code that is not binary compatible with code generated without that switch.
  Additionally, it makes the code suboptimal.
! Use it to conform to a non-default application binary interface.
! .IP "\fB\-fleading\-underscore\fR" 4
  .IX Item "-fleading-underscore"
  This option and its counterpart, \fB\-fno\-leading\-underscore\fR, forcibly
  change the way C symbols are represented in the object file.  One use
  is to help link with legacy assembly code.
  .Sp
! \&\fBWarning:\fR the \fB\-fleading\-underscore\fR switch causes \s-1GCC\s0 to
  generate code that is not binary compatible with code generated without that
! switch.  Use it to conform to a non-default application binary interface.
  Not all targets provide complete support for this switch.
! .IP "\fB\-ftls\-model=\fR\fImodel\fR" 4
  .IX Item "-ftls-model=model"
! Alter the thread-local storage model to be used.
! The \fImodel\fR argument should be one of \fBglobal-dynamic\fR,
! \&\fBlocal-dynamic\fR, \fBinitial-exec\fR or \fBlocal-exec\fR.
  Note that the choice is subject to optimization: the compiler may use
  a more efficient model for symbols not visible outside of the translation
  unit, or if \fB\-fpic\fR is not given on the command line.
  .Sp
! The default without \fB\-fpic\fR is \fBinitial-exec\fR; with
! \&\fB\-fpic\fR the default is \fBglobal-dynamic\fR.
! .IP "\fB\-ftrampolines\fR" 4
  .IX Item "-ftrampolines"
  For targets that normally need trampolines for nested functions, always
  generate them instead of using descriptors.  Otherwise, for targets that
! do not need them, like for example HP-PA or \s-1IA\-64,\s0 do nothing.
  .Sp
  A trampoline is a small piece of code that is created at run time on the
  stack when the address of a nested function is taken, and is used to call
--- 17932,17967 ----
  alignment (that is, objects with default alignment requirements larger than
  this are output potentially unaligned at the next fitting location.
  .Sp
! \&\fBWarning:\fR the \fB\-fpack\-struct\fR switch causes 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.
! .IP \fB\-fleading\-underscore\fR 4
  .IX Item "-fleading-underscore"
  This option and its counterpart, \fB\-fno\-leading\-underscore\fR, forcibly
  change the way C symbols are represented in the object file.  One use
  is to help link with legacy assembly code.
  .Sp
! \&\fBWarning:\fR the \fB\-fleading\-underscore\fR switch causes 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.
! .IP \fB\-ftls\-model=\fR\fImodel\fR 4
  .IX Item "-ftls-model=model"
! Alter the thread\-local storage model to be used.
! The \fImodel\fR argument should be one of \fBglobal\-dynamic\fR,
! \&\fBlocal\-dynamic\fR, \fBinitial\-exec\fR or \fBlocal\-exec\fR.
  Note that the choice is subject to optimization: the compiler may use
  a more efficient model for symbols not visible outside of the translation
  unit, or if \fB\-fpic\fR is not given on the command line.
  .Sp
! The default without \fB\-fpic\fR is \fBinitial\-exec\fR; with
! \&\fB\-fpic\fR the default is \fBglobal\-dynamic\fR.
! .IP \fB\-ftrampolines\fR 4
  .IX Item "-ftrampolines"
  For targets that normally need trampolines for nested functions, always
  generate them instead of using descriptors.  Otherwise, for targets that
! do not need them, like for example HP\-PA or IA\-64, do nothing.
  .Sp
  A trampoline is a small piece of code that is created at run time on the
  stack when the address of a nested function is taken, and is used to call
*************** writing, \fB\-fno\-trampolines\fR is ena
*** 18045,18077 ****
  .Sp
  Moreover, code compiled with \fB\-ftrampolines\fR and code compiled with
  \&\fB\-fno\-trampolines\fR are not binary compatible if nested functions are
! present.  This option must therefore be used on a program-wide basis and be
  manipulated with extreme care.
  .Sp
  For languages other than Ada, the \f(CW\*(C`\-ftrampolines\*(C'\fR and
  \&\f(CW\*(C`\-fno\-trampolines\*(C'\fR options currently have no effect, and
  trampolines are always generated on platforms that need them
  for nested functions.
! .IP "\fB\-fvisibility=\fR[\fBdefault\fR|\fBinternal\fR|\fBhidden\fR|\fBprotected\fR]" 4
  .IX Item "-fvisibility=[default|internal|hidden|protected]"
! Set the default \s-1ELF\s0 image symbol visibility to the specified option\-\-\-all
  symbols are marked with this unless overridden within the code.
  Using this feature can very substantially improve linking and
  load times of shared object libraries, produce more optimized
! code, provide near-perfect \s-1API\s0 export and prevent symbol clashes.
  It is \fBstrongly\fR recommended that you use this in any shared objects
  you distribute.
  .Sp
  Despite the nomenclature, \fBdefault\fR always means public; i.e.,
  available to be linked against from outside the shared object.
! \&\fBprotected\fR and \fBinternal\fR are pretty useless in real-world
  usage so the only other commonly used option is \fBhidden\fR.
! The default if \fB\-fvisibility\fR isn't specified is
  \&\fBdefault\fR, i.e., make every symbol public.
  .Sp
! A good explanation of the benefits offered by ensuring \s-1ELF\s0
! symbols have the correct visibility is given by \*(L"How To Write
! Shared Libraries\*(R" by Ulrich Drepper (which can be found at
  <\fBhttps://www.akkadia.org/drepper/\fR>)\-\-\-however a superior
  solution made possible by this option to marking things hidden when
  the default is public is to make the default hidden and mark things
--- 17976,18008 ----
  .Sp
  Moreover, code compiled with \fB\-ftrampolines\fR and code compiled with
  \&\fB\-fno\-trampolines\fR are not binary compatible if nested functions are
! present.  This option must therefore be used on a program\-wide basis and be
  manipulated with extreme care.
  .Sp
  For languages other than Ada, the \f(CW\*(C`\-ftrampolines\*(C'\fR and
  \&\f(CW\*(C`\-fno\-trampolines\*(C'\fR options currently have no effect, and
  trampolines are always generated on platforms that need them
  for nested functions.
! .IP \fB\-fvisibility=\fR[\fBdefault\fR|\fBinternal\fR|\fBhidden\fR|\fBprotected\fR] 4
  .IX Item "-fvisibility=[default|internal|hidden|protected]"
! Set the default ELF image symbol visibility to the specified option\-\-\-all
  symbols are marked with this unless overridden within the code.
  Using this feature can very substantially improve linking and
  load times of shared object libraries, produce more optimized
! code, provide near\-perfect API export and prevent symbol clashes.
  It is \fBstrongly\fR recommended that you use this in any shared objects
  you distribute.
  .Sp
  Despite the nomenclature, \fBdefault\fR always means public; i.e.,
  available to be linked against from outside the shared object.
! \&\fBprotected\fR and \fBinternal\fR are pretty useless in real\-world
  usage so the only other commonly used option is \fBhidden\fR.
! The default if \fB\-fvisibility\fR isn\*(Aqt specified is
  \&\fBdefault\fR, i.e., make every symbol public.
  .Sp
! 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
  <\fBhttps://www.akkadia.org/drepper/\fR>)\-\-\-however a superior
  solution made possible by this option to marking things hidden when
  the default is public is to make the default hidden and mark things
*************** public.  This is the norm with DLLs on W
*** 18079,18085 ****
  and \f(CW\*(C`_\|_attribute_\|_ ((visibility("default")))\*(C'\fR instead of
  \&\f(CW\*(C`_\|_declspec(dllexport)\*(C'\fR you get almost identical semantics with
  identical syntax.  This is a great boon to those working with
! cross-platform projects.
  .Sp
  For those adding visibility support to existing code, you may find
  \&\f(CW\*(C`#pragma GCC visibility\*(C'\fR of use.  This works by you enclosing
--- 18010,18016 ----
  and \f(CW\*(C`_\|_attribute_\|_ ((visibility("default")))\*(C'\fR instead of
  \&\f(CW\*(C`_\|_declspec(dllexport)\*(C'\fR you get almost identical semantics with
  identical syntax.  This is a great boon to those working with
! cross\-platform projects.
  .Sp
  For those adding visibility support to existing code, you may find
  \&\f(CW\*(C`#pragma GCC visibility\*(C'\fR of use.  This works by you enclosing
*************** the declarations you wish to set visibil
*** 18087,18098 ****
  \&\f(CW\*(C`#pragma GCC visibility push(hidden)\*(C'\fR and
  \&\f(CW\*(C`#pragma GCC visibility pop\*(C'\fR.
  Bear in mind that symbol visibility should be viewed \fBas
! part of the \s-1API\s0 interface contract\fR and thus all new code should
  always specify visibility when it is not the default; i.e., declarations
! only for use within the local \s-1DSO\s0 should \fBalways\fR be marked explicitly
! as hidden as so to avoid \s-1PLT\s0 indirection overheads\-\-\-making this
! abundantly clear also aids readability and self-documentation of the code.
! Note that due to \s-1ISO \*(C+\s0 specification requirements, \f(CW\*(C`operator new\*(C'\fR and
  \&\f(CW\*(C`operator delete\*(C'\fR must always be of default visibility.
  .Sp
  Be aware that headers from outside your project, in particular system
--- 18018,18029 ----
  \&\f(CW\*(C`#pragma GCC visibility push(hidden)\*(C'\fR and
  \&\f(CW\*(C`#pragma GCC visibility pop\*(C'\fR.
  Bear in mind that symbol visibility should be viewed \fBas
! part of the API interface contract\fR and thus all new code should
  always specify visibility when it is not the default; i.e., declarations
! only for use within the local DSO should \fBalways\fR 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, \f(CW\*(C`operator new\*(C'\fR and
  \&\f(CW\*(C`operator delete\*(C'\fR must always be of default visibility.
  .Sp
  Be aware that headers from outside your project, in particular system
*************** before including any such headers.
*** 18104,18115 ****
  \&\f(CW\*(C`extern\*(C'\fR declarations are not affected by \fB\-fvisibility\fR, so
  a lot of code can be recompiled with \fB\-fvisibility=hidden\fR with
  no modifications.  However, this means that calls to \f(CW\*(C`extern\*(C'\fR
! functions with no explicit visibility use the \s-1PLT,\s0 so it is more
  effective to use \f(CW\*(C`_\|_attribute ((visibility))\*(C'\fR and/or
  \&\f(CW\*(C`#pragma GCC visibility\*(C'\fR to tell the compiler which \f(CW\*(C`extern\*(C'\fR
  declarations should be treated as hidden.
  .Sp
! Note that \fB\-fvisibility\fR does affect \*(C+ vague linkage
  entities. This means that, for instance, an exception class that is
  be thrown between DSOs must be explicitly marked with default
  visibility so that the \fBtype_info\fR nodes are unified between
--- 18035,18046 ----
  \&\f(CW\*(C`extern\*(C'\fR declarations are not affected by \fB\-fvisibility\fR, so
  a lot of code can be recompiled with \fB\-fvisibility=hidden\fR with
  no modifications.  However, this means that calls to \f(CW\*(C`extern\*(C'\fR
! functions with no explicit visibility use the PLT, so it is more
  effective to use \f(CW\*(C`_\|_attribute ((visibility))\*(C'\fR and/or
  \&\f(CW\*(C`#pragma GCC visibility\*(C'\fR to tell the compiler which \f(CW\*(C`extern\*(C'\fR
  declarations should be treated as hidden.
  .Sp
! Note that \fB\-fvisibility\fR does affect C++ vague linkage
  entities. This means that, for instance, an exception class that is
  be thrown between DSOs must be explicitly marked with default
  visibility so that the \fBtype_info\fR nodes are unified between
*************** the DSOs.
*** 18117,18174 ****
  .Sp
  An overview of these techniques, their benefits and how to use them
  is at <\fBhttps://gcc.gnu.org/wiki/Visibility\fR>.
! .IP "\fB\-fstrict\-volatile\-bitfields\fR" 4
  .IX Item "-fstrict-volatile-bitfields"
! This option should be used if accesses to volatile bit-fields (or other
  structure fields, although the compiler usually honors those types
  anyway) should use a single access of the width of the
! field's type, aligned to a natural alignment if possible.  For
! example, targets with memory-mapped peripheral registers might require
  all such accesses to be 16 bits wide; with this flag you can
! declare all peripheral bit-fields as \f(CW\*(C`unsigned short\*(C'\fR (assuming short
! is 16 bits on these targets) to force \s-1GCC\s0 to use 16\-bit accesses
  instead of, perhaps, a more efficient 32\-bit access.
  .Sp
  If this option is disabled, the compiler uses the most efficient
  instruction.  In the previous example, that might be a 32\-bit load
  instruction, even though that accesses bytes that do not contain
! any portion of the bit-field, or memory-mapped registers unrelated to
  the one being updated.
  .Sp
  In some cases, such as when the \f(CW\*(C`packed\*(C'\fR attribute is applied to a 
  structure field, it may not be possible to access the field with a single
  read or write that is correctly aligned for the target machine.  In this
! case \s-1GCC\s0 falls back to generating multiple accesses rather than code that 
  will fault or truncate the result at run time.
  .Sp
! Note:  Due to restrictions of the C/\*(C+11 memory model, write accesses are
! not allowed to touch non bit-field members.  It is therefore recommended
! to define all bits of the field's type as bit-field members.
  .Sp
  The default value of this option is determined by the application binary
  interface for the target processor.
! .IP "\fB\-fsync\-libcalls\fR" 4
  .IX Item "-fsync-libcalls"
! This option controls whether any out-of-line instance of the \f(CW\*(C`_\|_sync\*(C'\fR
! family of functions may be used to implement the \*(C+11 \f(CW\*(C`_\|_atomic\*(C'\fR
  family of functions.
  .Sp
  The default value of this option is enabled, thus the only useful form
  of the option is \fB\-fno\-sync\-libcalls\fR.  This option is used in
  the implementation of the \fIlibatomic\fR runtime library.
! .SS "\s-1GCC\s0 Developer Options"
  .IX Subsection "GCC Developer Options"
! This section describes command-line options that are primarily of
! interest to \s-1GCC\s0 developers, including options to support compiler
! testing and investigation of compiler bugs and compile-time
  performance problems.  This includes options that produce debug dumps
  at various points in the compilation; that print statistics such as
! memory use and execution time; and that print information about \s-1GCC\s0's
  configuration, such as where it searches for libraries.  You should
  rarely need to use any of these options for ordinary compilation and
  linking tasks.
  .PP
! Many developer options that cause \s-1GCC\s0 to dump output to a file take an
  optional \fB=\fR\fIfilename\fR suffix. You can specify \fBstdout\fR
  or \fB\-\fR to dump to standard output, and \fBstderr\fR for standard
  error.
--- 18048,18105 ----
  .Sp
  An overview of these techniques, their benefits and how to use them
  is at <\fBhttps://gcc.gnu.org/wiki/Visibility\fR>.
! .IP \fB\-fstrict\-volatile\-bitfields\fR 4
  .IX Item "-fstrict-volatile-bitfields"
! This option should be used if accesses to volatile bit\-fields (or other
  structure fields, although the compiler usually honors those types
  anyway) should use a single access of the width of the
! field\*(Aqs type, aligned to a natural alignment if possible.  For
! example, targets with memory\-mapped peripheral registers might require
  all such accesses to be 16 bits wide; with this flag you can
! declare all peripheral bit\-fields as \f(CW\*(C`unsigned short\*(C'\fR (assuming short
! is 16 bits on these targets) to force GCC to use 16\-bit accesses
  instead of, perhaps, a more efficient 32\-bit access.
  .Sp
  If this option is disabled, the compiler uses the most efficient
  instruction.  In the previous example, that might be a 32\-bit load
  instruction, even though that accesses bytes that do not contain
! any portion of the bit\-field, or memory\-mapped registers unrelated to
  the one being updated.
  .Sp
  In some cases, such as when the \f(CW\*(C`packed\*(C'\fR attribute is applied to a 
  structure field, it may not be possible to access the field with a single
  read or write that is correctly aligned for the target machine.  In this
! case GCC falls back to generating multiple accesses rather than code that 
  will fault or truncate the result at run time.
  .Sp
! Note:  Due to restrictions of the C/C++11 memory model, write accesses are
! not allowed to touch non bit\-field members.  It is therefore recommended
! to define all bits of the field\*(Aqs type as bit\-field members.
  .Sp
  The default value of this option is determined by the application binary
  interface for the target processor.
! .IP \fB\-fsync\-libcalls\fR 4
  .IX Item "-fsync-libcalls"
! This option controls whether any out\-of\-line instance of the \f(CW\*(C`_\|_sync\*(C'\fR
! family of functions may be used to implement the C++11 \f(CW\*(C`_\|_atomic\*(C'\fR
  family of functions.
  .Sp
  The default value of this option is enabled, thus the only useful form
  of the option is \fB\-fno\-sync\-libcalls\fR.  This option is used in
  the implementation of the \fIlibatomic\fR runtime library.
! .SS "GCC Developer Options"
  .IX Subsection "GCC Developer Options"
! This section describes command\-line options that are primarily of
! interest to GCC developers, including options to support compiler
! testing and investigation of compiler bugs and compile\-time
  performance problems.  This includes options that produce debug dumps
  at various points in the compilation; that print statistics such as
! memory use and execution time; and that print information about GCC\*(Aqs
  configuration, such as where it searches for libraries.  You should
  rarely need to use any of these options for ordinary compilation and
  linking tasks.
  .PP
! Many developer options that cause GCC to dump output to a file take an
  optional \fB=\fR\fIfilename\fR suffix. You can specify \fBstdout\fR
  or \fB\-\fR to dump to standard output, and \fBstderr\fR for standard
  error.
*************** phase letter, and pass name.  The base d
*** 18179,18202 ****
  output file produced by the compiler if explicitly specified and not
  an executable; otherwise it is the source file name.
  The pass number is determined by the order passes are registered with
! the compiler's pass manager. 
  This is generally the same as the order of execution, but passes
! registered by plugins, target-specific passes, or passes that are
  otherwise registered late are numbered higher than the pass named
  \&\fBfinal\fR, even if they are executed earlier.  The phase letter is
! one of \fBi\fR (inter-procedural analysis), \fBl\fR
! (language-specific), \fBr\fR (\s-1RTL\s0), or \fBt\fR (tree). 
  The files are created in the directory of the output file.
! .IP "\fB\-fcallgraph\-info\fR" 4
  .IX Item "-fcallgraph-info"
  .PD 0
! .IP "\fB\-fcallgraph\-info=\fR\fI\s-1MARKERS\s0\fR" 4
  .IX Item "-fcallgraph-info=MARKERS"
  .PD
  Makes the compiler output callgraph information for the program, on a
! per-object-file basis.  The information is generated in the common \s-1VCG\s0
! format.  It can be decorated with additional, per-node and/or per-edge
! information, if a list of comma-separated markers is additionally
  specified.  When the \f(CW\*(C`su\*(C'\fR marker is specified, the callgraph is
  decorated with stack usage information; it is equivalent to
  \&\fB\-fstack\-usage\fR.  When the \f(CW\*(C`da\*(C'\fR marker is specified, the
--- 18110,18133 ----
  output file produced by the compiler if explicitly specified and not
  an executable; otherwise it is the source file name.
  The pass number is determined by the order passes are registered with
! the compiler\*(Aqs pass manager. 
  This is generally the same as the order of execution, but passes
! registered by plugins, target\-specific passes, or passes that are
  otherwise registered late are numbered higher than the pass named
  \&\fBfinal\fR, even if they are executed earlier.  The phase letter is
! one of \fBi\fR (inter\-procedural analysis), \fBl\fR
! (language\-specific), \fBr\fR (RTL), or \fBt\fR (tree). 
  The files are created in the directory of the output file.
! .IP \fB\-fcallgraph\-info\fR 4
  .IX Item "-fcallgraph-info"
  .PD 0
! .IP \fB\-fcallgraph\-info=\fR\fIMARKERS\fR 4
  .IX Item "-fcallgraph-info=MARKERS"
  .PD
  Makes the compiler output callgraph information for the program, on a
! per\-object\-file basis.  The information is generated in the common VCG
! format.  It can be decorated with additional, per\-node and/or per\-edge
! information, if a list of comma\-separated markers is additionally
  specified.  When the \f(CW\*(C`su\*(C'\fR marker is specified, the callgraph is
  decorated with stack usage information; it is equivalent to
  \&\fB\-fstack\-usage\fR.  When the \f(CW\*(C`da\*(C'\fR marker is specified, the
*************** callgraph is decorated with information
*** 18204,18222 ****
  objects.
  .Sp
  When compiling with \fB\-flto\fR, no callgraph information is output
! along with the object file.  At \s-1LTO\s0 link time, \fB\-fcallgraph\-info\fR
  may generate multiple callgraph information files next to intermediate
! \&\s-1LTO\s0 output files.
! .IP "\fB\-d\fR\fIletters\fR" 4
  .IX Item "-dletters"
  .PD 0
! .IP "\fB\-fdump\-rtl\-\fR\fIpass\fR" 4
  .IX Item "-fdump-rtl-pass"
! .IP "\fB\-fdump\-rtl\-\fR\fIpass\fR\fB=\fR\fIfilename\fR" 4
  .IX Item "-fdump-rtl-pass=filename"
  .PD
  Says to make debugging dumps during compilation at times specified by
! \&\fIletters\fR.  This is used for debugging the RTL-based passes of the
  compiler.
  .Sp
  Some \fB\-d\fR\fIletters\fR switches have different meaning when
--- 18135,18153 ----
  objects.
  .Sp
  When compiling with \fB\-flto\fR, no callgraph information is output
! along with the object file.  At LTO link time, \fB\-fcallgraph\-info\fR
  may generate multiple callgraph information files next to intermediate
! LTO output files.
! .IP \fB\-d\fR\fIletters\fR 4
  .IX Item "-dletters"
  .PD 0
! .IP \fB\-fdump\-rtl\-\fR\fIpass\fR 4
  .IX Item "-fdump-rtl-pass"
! .IP \fB\-fdump\-rtl\-\fR\fIpass\fR\fB=\fR\fIfilename\fR 4
  .IX Item "-fdump-rtl-pass=filename"
  .PD
  Says to make debugging dumps during compilation at times specified by
! \&\fIletters\fR.  This is used for debugging the RTL\-based passes of the
  compiler.
  .Sp
  Some \fB\-d\fR\fIletters\fR switches have different meaning when
*************** Debug dumps can be enabled with a \fB\-f
*** 18226,18530 ****
  \&\fB\-d\fR option \fIletters\fR.  Here are the possible
  letters for use in \fIpass\fR and \fIletters\fR, and their meanings:
  .RS 4
! .IP "\fB\-fdump\-rtl\-alignments\fR" 4
  .IX Item "-fdump-rtl-alignments"
  Dump after branch alignments have been computed.
! .IP "\fB\-fdump\-rtl\-asmcons\fR" 4
  .IX Item "-fdump-rtl-asmcons"
  Dump after fixing rtl statements that have unsatisfied in/out constraints.
! .IP "\fB\-fdump\-rtl\-auto_inc_dec\fR" 4
  .IX Item "-fdump-rtl-auto_inc_dec"
! Dump after auto-inc-dec discovery.  This pass is only run on
  architectures that have auto inc or auto dec instructions.
! .IP "\fB\-fdump\-rtl\-barriers\fR" 4
  .IX Item "-fdump-rtl-barriers"
  Dump after cleaning up the barrier instructions.
! .IP "\fB\-fdump\-rtl\-bbpart\fR" 4
  .IX Item "-fdump-rtl-bbpart"
  Dump after partitioning hot and cold basic blocks.
! .IP "\fB\-fdump\-rtl\-bbro\fR" 4
  .IX Item "-fdump-rtl-bbro"
  Dump after block reordering.
! .IP "\fB\-fdump\-rtl\-btl1\fR" 4
  .IX Item "-fdump-rtl-btl1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-btl2\fR" 4
  .IX Item "-fdump-rtl-btl2"
  .PD
  \&\fB\-fdump\-rtl\-btl1\fR and \fB\-fdump\-rtl\-btl2\fR enable dumping
  after the two branch
  target load optimization passes.
! .IP "\fB\-fdump\-rtl\-bypass\fR" 4
  .IX Item "-fdump-rtl-bypass"
  Dump after jump bypassing and control flow optimizations.
! .IP "\fB\-fdump\-rtl\-combine\fR" 4
  .IX Item "-fdump-rtl-combine"
! Dump after the \s-1RTL\s0 instruction combination pass.
! .IP "\fB\-fdump\-rtl\-compgotos\fR" 4
  .IX Item "-fdump-rtl-compgotos"
  Dump after duplicating the computed gotos.
! .IP "\fB\-fdump\-rtl\-ce1\fR" 4
  .IX Item "-fdump-rtl-ce1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-ce2\fR" 4
  .IX Item "-fdump-rtl-ce2"
! .IP "\fB\-fdump\-rtl\-ce3\fR" 4
  .IX Item "-fdump-rtl-ce3"
  .PD
  \&\fB\-fdump\-rtl\-ce1\fR, \fB\-fdump\-rtl\-ce2\fR, and
  \&\fB\-fdump\-rtl\-ce3\fR enable dumping after the three
  if conversion passes.
! .IP "\fB\-fdump\-rtl\-cprop_hardreg\fR" 4
  .IX Item "-fdump-rtl-cprop_hardreg"
  Dump after hard register copy propagation.
! .IP "\fB\-fdump\-rtl\-csa\fR" 4
  .IX Item "-fdump-rtl-csa"
  Dump after combining stack adjustments.
! .IP "\fB\-fdump\-rtl\-cse1\fR" 4
  .IX Item "-fdump-rtl-cse1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-cse2\fR" 4
  .IX Item "-fdump-rtl-cse2"
  .PD
  \&\fB\-fdump\-rtl\-cse1\fR and \fB\-fdump\-rtl\-cse2\fR enable dumping after
  the two common subexpression elimination passes.
! .IP "\fB\-fdump\-rtl\-dce\fR" 4
  .IX Item "-fdump-rtl-dce"
  Dump after the standalone dead code elimination passes.
! .IP "\fB\-fdump\-rtl\-dbr\fR" 4
  .IX Item "-fdump-rtl-dbr"
  Dump after delayed branch scheduling.
! .IP "\fB\-fdump\-rtl\-dce1\fR" 4
  .IX Item "-fdump-rtl-dce1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-dce2\fR" 4
  .IX Item "-fdump-rtl-dce2"
  .PD
  \&\fB\-fdump\-rtl\-dce1\fR and \fB\-fdump\-rtl\-dce2\fR enable dumping after
  the two dead store elimination passes.
! .IP "\fB\-fdump\-rtl\-eh\fR" 4
  .IX Item "-fdump-rtl-eh"
! Dump after finalization of \s-1EH\s0 handling code.
! .IP "\fB\-fdump\-rtl\-eh_ranges\fR" 4
  .IX Item "-fdump-rtl-eh_ranges"
! Dump after conversion of \s-1EH\s0 handling range regions.
! .IP "\fB\-fdump\-rtl\-expand\fR" 4
  .IX Item "-fdump-rtl-expand"
! Dump after \s-1RTL\s0 generation.
! .IP "\fB\-fdump\-rtl\-fwprop1\fR" 4
  .IX Item "-fdump-rtl-fwprop1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-fwprop2\fR" 4
  .IX Item "-fdump-rtl-fwprop2"
  .PD
  \&\fB\-fdump\-rtl\-fwprop1\fR and \fB\-fdump\-rtl\-fwprop2\fR enable
  dumping after the two forward propagation passes.
! .IP "\fB\-fdump\-rtl\-gcse1\fR" 4
  .IX Item "-fdump-rtl-gcse1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-gcse2\fR" 4
  .IX Item "-fdump-rtl-gcse2"
  .PD
  \&\fB\-fdump\-rtl\-gcse1\fR and \fB\-fdump\-rtl\-gcse2\fR enable dumping
  after global common subexpression elimination.
! .IP "\fB\-fdump\-rtl\-init\-regs\fR" 4
  .IX Item "-fdump-rtl-init-regs"
  Dump after the initialization of the registers.
! .IP "\fB\-fdump\-rtl\-initvals\fR" 4
  .IX Item "-fdump-rtl-initvals"
  Dump after the computation of the initial value sets.
! .IP "\fB\-fdump\-rtl\-into_cfglayout\fR" 4
  .IX Item "-fdump-rtl-into_cfglayout"
  Dump after converting to cfglayout mode.
! .IP "\fB\-fdump\-rtl\-ira\fR" 4
  .IX Item "-fdump-rtl-ira"
  Dump after iterated register allocation.
! .IP "\fB\-fdump\-rtl\-jump\fR" 4
  .IX Item "-fdump-rtl-jump"
  Dump after the second jump optimization.
! .IP "\fB\-fdump\-rtl\-loop2\fR" 4
  .IX Item "-fdump-rtl-loop2"
  \&\fB\-fdump\-rtl\-loop2\fR enables dumping after the rtl
  loop optimization passes.
! .IP "\fB\-fdump\-rtl\-mach\fR" 4
  .IX Item "-fdump-rtl-mach"
  Dump after performing the machine dependent reorganization pass, if that
  pass exists.
! .IP "\fB\-fdump\-rtl\-mode_sw\fR" 4
  .IX Item "-fdump-rtl-mode_sw"
  Dump after removing redundant mode switches.
! .IP "\fB\-fdump\-rtl\-rnreg\fR" 4
  .IX Item "-fdump-rtl-rnreg"
  Dump after register renumbering.
! .IP "\fB\-fdump\-rtl\-outof_cfglayout\fR" 4
  .IX Item "-fdump-rtl-outof_cfglayout"
  Dump after converting from cfglayout mode.
! .IP "\fB\-fdump\-rtl\-peephole2\fR" 4
  .IX Item "-fdump-rtl-peephole2"
  Dump after the peephole pass.
! .IP "\fB\-fdump\-rtl\-postreload\fR" 4
  .IX Item "-fdump-rtl-postreload"
! Dump after post-reload optimizations.
! .IP "\fB\-fdump\-rtl\-pro_and_epilogue\fR" 4
  .IX Item "-fdump-rtl-pro_and_epilogue"
  Dump after generating the function prologues and epilogues.
! .IP "\fB\-fdump\-rtl\-sched1\fR" 4
  .IX Item "-fdump-rtl-sched1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-sched2\fR" 4
  .IX Item "-fdump-rtl-sched2"
  .PD
  \&\fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR enable dumping
  after the basic block scheduling passes.
! .IP "\fB\-fdump\-rtl\-ree\fR" 4
  .IX Item "-fdump-rtl-ree"
  Dump after sign/zero extension elimination.
! .IP "\fB\-fdump\-rtl\-seqabstr\fR" 4
  .IX Item "-fdump-rtl-seqabstr"
  Dump after common sequence discovery.
! .IP "\fB\-fdump\-rtl\-shorten\fR" 4
  .IX Item "-fdump-rtl-shorten"
  Dump after shortening branches.
! .IP "\fB\-fdump\-rtl\-sibling\fR" 4
  .IX Item "-fdump-rtl-sibling"
  Dump after sibling call optimizations.
! .IP "\fB\-fdump\-rtl\-split1\fR" 4
  .IX Item "-fdump-rtl-split1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-split2\fR" 4
  .IX Item "-fdump-rtl-split2"
! .IP "\fB\-fdump\-rtl\-split3\fR" 4
  .IX Item "-fdump-rtl-split3"
! .IP "\fB\-fdump\-rtl\-split4\fR" 4
  .IX Item "-fdump-rtl-split4"
! .IP "\fB\-fdump\-rtl\-split5\fR" 4
  .IX Item "-fdump-rtl-split5"
  .PD
  These options enable dumping after five rounds of
  instruction splitting.
! .IP "\fB\-fdump\-rtl\-sms\fR" 4
  .IX Item "-fdump-rtl-sms"
  Dump after modulo scheduling.  This pass is only run on some
  architectures.
! .IP "\fB\-fdump\-rtl\-stack\fR" 4
  .IX Item "-fdump-rtl-stack"
! Dump after conversion from \s-1GCC\s0's \*(L"flat register file\*(R" registers to the
! x87's stack-like registers.  This pass is only run on x86 variants.
! .IP "\fB\-fdump\-rtl\-subreg1\fR" 4
  .IX Item "-fdump-rtl-subreg1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-subreg2\fR" 4
  .IX Item "-fdump-rtl-subreg2"
  .PD
  \&\fB\-fdump\-rtl\-subreg1\fR and \fB\-fdump\-rtl\-subreg2\fR enable dumping after
  the two subreg expansion passes.
! .IP "\fB\-fdump\-rtl\-unshare\fR" 4
  .IX Item "-fdump-rtl-unshare"
  Dump after all rtl has been unshared.
! .IP "\fB\-fdump\-rtl\-vartrack\fR" 4
  .IX Item "-fdump-rtl-vartrack"
  Dump after variable tracking.
! .IP "\fB\-fdump\-rtl\-vregs\fR" 4
  .IX Item "-fdump-rtl-vregs"
  Dump after converting virtual registers to hard registers.
! .IP "\fB\-fdump\-rtl\-web\fR" 4
  .IX Item "-fdump-rtl-web"
  Dump after live range splitting.
! .IP "\fB\-fdump\-rtl\-regclass\fR" 4
  .IX Item "-fdump-rtl-regclass"
  .PD 0
! .IP "\fB\-fdump\-rtl\-subregs_of_mode_init\fR" 4
  .IX Item "-fdump-rtl-subregs_of_mode_init"
! .IP "\fB\-fdump\-rtl\-subregs_of_mode_finish\fR" 4
  .IX Item "-fdump-rtl-subregs_of_mode_finish"
! .IP "\fB\-fdump\-rtl\-dfinit\fR" 4
  .IX Item "-fdump-rtl-dfinit"
! .IP "\fB\-fdump\-rtl\-dfinish\fR" 4
  .IX Item "-fdump-rtl-dfinish"
  .PD
  These dumps are defined but always produce empty files.
! .IP "\fB\-da\fR" 4
  .IX Item "-da"
  .PD 0
! .IP "\fB\-fdump\-rtl\-all\fR" 4
  .IX Item "-fdump-rtl-all"
  .PD
  Produce all the dumps listed above.
! .IP "\fB\-dA\fR" 4
  .IX Item "-dA"
  Annotate the assembler output with miscellaneous debugging information.
! .IP "\fB\-dD\fR" 4
  .IX Item "-dD"
  Dump all macro definitions, at the end of preprocessing, in addition to
  normal output.
! .IP "\fB\-dH\fR" 4
  .IX Item "-dH"
  Produce a core dump whenever an error occurs.
! .IP "\fB\-dp\fR" 4
  .IX Item "-dp"
  Annotate the assembler output with a comment indicating which
  pattern and alternative is used.  The length and cost of each instruction are
  also printed.
! .IP "\fB\-dP\fR" 4
  .IX Item "-dP"
! Dump the \s-1RTL\s0 in the assembler output as a comment before each instruction.
  Also turns on \fB\-dp\fR annotation.
! .IP "\fB\-dx\fR" 4
  .IX Item "-dx"
! Just generate \s-1RTL\s0 for a function instead of compiling it.  Usually used
  with \fB\-fdump\-rtl\-expand\fR.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdump\-debug\fR" 4
  .IX Item "-fdump-debug"
  Dump debugging information generated during the debug
  generation phase.
! .IP "\fB\-fdump\-earlydebug\fR" 4
  .IX Item "-fdump-earlydebug"
  Dump debugging information generated during the early debug
  generation phase.
! .IP "\fB\-fdump\-noaddr\fR" 4
  .IX Item "-fdump-noaddr"
  When doing debugging dumps, suppress address output.  This makes it more
  feasible to use diff on debugging dumps for compiler invocations with
  different compiler binaries and/or different
  text / bss / data / heap / stack / dso start locations.
! .IP "\fB\-freport\-bug\fR" 4
  .IX Item "-freport-bug"
  Collect and dump debug information into a temporary file if an
! internal compiler error (\s-1ICE\s0) occurs.
! .IP "\fB\-fdump\-unnumbered\fR" 4
  .IX Item "-fdump-unnumbered"
  When doing debugging dumps, suppress instruction numbers and address output.
  This makes it more feasible to use diff on debugging dumps for compiler
  invocations with different options, in particular with and without
  \&\fB\-g\fR.
! .IP "\fB\-fdump\-unnumbered\-links\fR" 4
  .IX Item "-fdump-unnumbered-links"
  When doing debugging dumps (see \fB\-d\fR option above), suppress
  instruction numbers for the links to the previous and next instructions
  in a sequence.
! .IP "\fB\-fdump\-ipa\-\fR\fIswitch\fR" 4
  .IX Item "-fdump-ipa-switch"
  .PD 0
! .IP "\fB\-fdump\-ipa\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR" 4
  .IX Item "-fdump-ipa-switch-options"
  .PD
! Control the dumping at various stages of inter-procedural analysis
  language tree to a file.  The file name is generated by appending a
  switch specific suffix to the source file name, and the file is created
  in the same directory as the output file.  The following dumps are
  possible:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
! Enables all inter-procedural analysis dumps.
! .IP "\fBcgraph\fR" 4
  .IX Item "cgraph"
! Dumps information about call-graph optimization, unused function removal,
  and inlining decisions.
! .IP "\fBinline\fR" 4
  .IX Item "inline"
  Dump after function inlining.
  .RE
--- 18157,18461 ----
  \&\fB\-d\fR option \fIletters\fR.  Here are the possible
  letters for use in \fIpass\fR and \fIletters\fR, and their meanings:
  .RS 4
! .IP \fB\-fdump\-rtl\-alignments\fR 4
  .IX Item "-fdump-rtl-alignments"
  Dump after branch alignments have been computed.
! .IP \fB\-fdump\-rtl\-asmcons\fR 4
  .IX Item "-fdump-rtl-asmcons"
  Dump after fixing rtl statements that have unsatisfied in/out constraints.
! .IP \fB\-fdump\-rtl\-auto_inc_dec\fR 4
  .IX Item "-fdump-rtl-auto_inc_dec"
! Dump after auto\-inc\-dec discovery.  This pass is only run on
  architectures that have auto inc or auto dec instructions.
! .IP \fB\-fdump\-rtl\-barriers\fR 4
  .IX Item "-fdump-rtl-barriers"
  Dump after cleaning up the barrier instructions.
! .IP \fB\-fdump\-rtl\-bbpart\fR 4
  .IX Item "-fdump-rtl-bbpart"
  Dump after partitioning hot and cold basic blocks.
! .IP \fB\-fdump\-rtl\-bbro\fR 4
  .IX Item "-fdump-rtl-bbro"
  Dump after block reordering.
! .IP \fB\-fdump\-rtl\-btl1\fR 4
  .IX Item "-fdump-rtl-btl1"
  .PD 0
! .IP \fB\-fdump\-rtl\-btl2\fR 4
  .IX Item "-fdump-rtl-btl2"
  .PD
  \&\fB\-fdump\-rtl\-btl1\fR and \fB\-fdump\-rtl\-btl2\fR enable dumping
  after the two branch
  target load optimization passes.
! .IP \fB\-fdump\-rtl\-bypass\fR 4
  .IX Item "-fdump-rtl-bypass"
  Dump after jump bypassing and control flow optimizations.
! .IP \fB\-fdump\-rtl\-combine\fR 4
  .IX Item "-fdump-rtl-combine"
! Dump after the RTL instruction combination pass.
! .IP \fB\-fdump\-rtl\-compgotos\fR 4
  .IX Item "-fdump-rtl-compgotos"
  Dump after duplicating the computed gotos.
! .IP \fB\-fdump\-rtl\-ce1\fR 4
  .IX Item "-fdump-rtl-ce1"
  .PD 0
! .IP \fB\-fdump\-rtl\-ce2\fR 4
  .IX Item "-fdump-rtl-ce2"
! .IP \fB\-fdump\-rtl\-ce3\fR 4
  .IX Item "-fdump-rtl-ce3"
  .PD
  \&\fB\-fdump\-rtl\-ce1\fR, \fB\-fdump\-rtl\-ce2\fR, and
  \&\fB\-fdump\-rtl\-ce3\fR enable dumping after the three
  if conversion passes.
! .IP \fB\-fdump\-rtl\-cprop_hardreg\fR 4
  .IX Item "-fdump-rtl-cprop_hardreg"
  Dump after hard register copy propagation.
! .IP \fB\-fdump\-rtl\-csa\fR 4
  .IX Item "-fdump-rtl-csa"
  Dump after combining stack adjustments.
! .IP \fB\-fdump\-rtl\-cse1\fR 4
  .IX Item "-fdump-rtl-cse1"
  .PD 0
! .IP \fB\-fdump\-rtl\-cse2\fR 4
  .IX Item "-fdump-rtl-cse2"
  .PD
  \&\fB\-fdump\-rtl\-cse1\fR and \fB\-fdump\-rtl\-cse2\fR enable dumping after
  the two common subexpression elimination passes.
! .IP \fB\-fdump\-rtl\-dce\fR 4
  .IX Item "-fdump-rtl-dce"
  Dump after the standalone dead code elimination passes.
! .IP \fB\-fdump\-rtl\-dbr\fR 4
  .IX Item "-fdump-rtl-dbr"
  Dump after delayed branch scheduling.
! .IP \fB\-fdump\-rtl\-dce1\fR 4
  .IX Item "-fdump-rtl-dce1"
  .PD 0
! .IP \fB\-fdump\-rtl\-dce2\fR 4
  .IX Item "-fdump-rtl-dce2"
  .PD
  \&\fB\-fdump\-rtl\-dce1\fR and \fB\-fdump\-rtl\-dce2\fR enable dumping after
  the two dead store elimination passes.
! .IP \fB\-fdump\-rtl\-eh\fR 4
  .IX Item "-fdump-rtl-eh"
! Dump after finalization of EH handling code.
! .IP \fB\-fdump\-rtl\-eh_ranges\fR 4
  .IX Item "-fdump-rtl-eh_ranges"
! Dump after conversion of EH handling range regions.
! .IP \fB\-fdump\-rtl\-expand\fR 4
  .IX Item "-fdump-rtl-expand"
! Dump after RTL generation.
! .IP \fB\-fdump\-rtl\-fwprop1\fR 4
  .IX Item "-fdump-rtl-fwprop1"
  .PD 0
! .IP \fB\-fdump\-rtl\-fwprop2\fR 4
  .IX Item "-fdump-rtl-fwprop2"
  .PD
  \&\fB\-fdump\-rtl\-fwprop1\fR and \fB\-fdump\-rtl\-fwprop2\fR enable
  dumping after the two forward propagation passes.
! .IP \fB\-fdump\-rtl\-gcse1\fR 4
  .IX Item "-fdump-rtl-gcse1"
  .PD 0
! .IP \fB\-fdump\-rtl\-gcse2\fR 4
  .IX Item "-fdump-rtl-gcse2"
  .PD
  \&\fB\-fdump\-rtl\-gcse1\fR and \fB\-fdump\-rtl\-gcse2\fR enable dumping
  after global common subexpression elimination.
! .IP \fB\-fdump\-rtl\-init\-regs\fR 4
  .IX Item "-fdump-rtl-init-regs"
  Dump after the initialization of the registers.
! .IP \fB\-fdump\-rtl\-initvals\fR 4
  .IX Item "-fdump-rtl-initvals"
  Dump after the computation of the initial value sets.
! .IP \fB\-fdump\-rtl\-into_cfglayout\fR 4
  .IX Item "-fdump-rtl-into_cfglayout"
  Dump after converting to cfglayout mode.
! .IP \fB\-fdump\-rtl\-ira\fR 4
  .IX Item "-fdump-rtl-ira"
  Dump after iterated register allocation.
! .IP \fB\-fdump\-rtl\-jump\fR 4
  .IX Item "-fdump-rtl-jump"
  Dump after the second jump optimization.
! .IP \fB\-fdump\-rtl\-loop2\fR 4
  .IX Item "-fdump-rtl-loop2"
  \&\fB\-fdump\-rtl\-loop2\fR enables dumping after the rtl
  loop optimization passes.
! .IP \fB\-fdump\-rtl\-mach\fR 4
  .IX Item "-fdump-rtl-mach"
  Dump after performing the machine dependent reorganization pass, if that
  pass exists.
! .IP \fB\-fdump\-rtl\-mode_sw\fR 4
  .IX Item "-fdump-rtl-mode_sw"
  Dump after removing redundant mode switches.
! .IP \fB\-fdump\-rtl\-rnreg\fR 4
  .IX Item "-fdump-rtl-rnreg"
  Dump after register renumbering.
! .IP \fB\-fdump\-rtl\-outof_cfglayout\fR 4
  .IX Item "-fdump-rtl-outof_cfglayout"
  Dump after converting from cfglayout mode.
! .IP \fB\-fdump\-rtl\-peephole2\fR 4
  .IX Item "-fdump-rtl-peephole2"
  Dump after the peephole pass.
! .IP \fB\-fdump\-rtl\-postreload\fR 4
  .IX Item "-fdump-rtl-postreload"
! Dump after post\-reload optimizations.
! .IP \fB\-fdump\-rtl\-pro_and_epilogue\fR 4
  .IX Item "-fdump-rtl-pro_and_epilogue"
  Dump after generating the function prologues and epilogues.
! .IP \fB\-fdump\-rtl\-sched1\fR 4
  .IX Item "-fdump-rtl-sched1"
  .PD 0
! .IP \fB\-fdump\-rtl\-sched2\fR 4
  .IX Item "-fdump-rtl-sched2"
  .PD
  \&\fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR enable dumping
  after the basic block scheduling passes.
! .IP \fB\-fdump\-rtl\-ree\fR 4
  .IX Item "-fdump-rtl-ree"
  Dump after sign/zero extension elimination.
! .IP \fB\-fdump\-rtl\-seqabstr\fR 4
  .IX Item "-fdump-rtl-seqabstr"
  Dump after common sequence discovery.
! .IP \fB\-fdump\-rtl\-shorten\fR 4
  .IX Item "-fdump-rtl-shorten"
  Dump after shortening branches.
! .IP \fB\-fdump\-rtl\-sibling\fR 4
  .IX Item "-fdump-rtl-sibling"
  Dump after sibling call optimizations.
! .IP \fB\-fdump\-rtl\-split1\fR 4
  .IX Item "-fdump-rtl-split1"
  .PD 0
! .IP \fB\-fdump\-rtl\-split2\fR 4
  .IX Item "-fdump-rtl-split2"
! .IP \fB\-fdump\-rtl\-split3\fR 4
  .IX Item "-fdump-rtl-split3"
! .IP \fB\-fdump\-rtl\-split4\fR 4
  .IX Item "-fdump-rtl-split4"
! .IP \fB\-fdump\-rtl\-split5\fR 4
  .IX Item "-fdump-rtl-split5"
  .PD
  These options enable dumping after five rounds of
  instruction splitting.
! .IP \fB\-fdump\-rtl\-sms\fR 4
  .IX Item "-fdump-rtl-sms"
  Dump after modulo scheduling.  This pass is only run on some
  architectures.
! .IP \fB\-fdump\-rtl\-stack\fR 4
  .IX Item "-fdump-rtl-stack"
! Dump after conversion from GCC\*(Aqs "flat register file" registers to the
! x87\*(Aqs stack\-like registers.  This pass is only run on x86 variants.
! .IP \fB\-fdump\-rtl\-subreg1\fR 4
  .IX Item "-fdump-rtl-subreg1"
  .PD 0
! .IP \fB\-fdump\-rtl\-subreg2\fR 4
  .IX Item "-fdump-rtl-subreg2"
  .PD
  \&\fB\-fdump\-rtl\-subreg1\fR and \fB\-fdump\-rtl\-subreg2\fR enable dumping after
  the two subreg expansion passes.
! .IP \fB\-fdump\-rtl\-unshare\fR 4
  .IX Item "-fdump-rtl-unshare"
  Dump after all rtl has been unshared.
! .IP \fB\-fdump\-rtl\-vartrack\fR 4
  .IX Item "-fdump-rtl-vartrack"
  Dump after variable tracking.
! .IP \fB\-fdump\-rtl\-vregs\fR 4
  .IX Item "-fdump-rtl-vregs"
  Dump after converting virtual registers to hard registers.
! .IP \fB\-fdump\-rtl\-web\fR 4
  .IX Item "-fdump-rtl-web"
  Dump after live range splitting.
! .IP \fB\-fdump\-rtl\-regclass\fR 4
  .IX Item "-fdump-rtl-regclass"
  .PD 0
! .IP \fB\-fdump\-rtl\-subregs_of_mode_init\fR 4
  .IX Item "-fdump-rtl-subregs_of_mode_init"
! .IP \fB\-fdump\-rtl\-subregs_of_mode_finish\fR 4
  .IX Item "-fdump-rtl-subregs_of_mode_finish"
! .IP \fB\-fdump\-rtl\-dfinit\fR 4
  .IX Item "-fdump-rtl-dfinit"
! .IP \fB\-fdump\-rtl\-dfinish\fR 4
  .IX Item "-fdump-rtl-dfinish"
  .PD
  These dumps are defined but always produce empty files.
! .IP \fB\-da\fR 4
  .IX Item "-da"
  .PD 0
! .IP \fB\-fdump\-rtl\-all\fR 4
  .IX Item "-fdump-rtl-all"
  .PD
  Produce all the dumps listed above.
! .IP \fB\-dA\fR 4
  .IX Item "-dA"
  Annotate the assembler output with miscellaneous debugging information.
! .IP \fB\-dD\fR 4
  .IX Item "-dD"
  Dump all macro definitions, at the end of preprocessing, in addition to
  normal output.
! .IP \fB\-dH\fR 4
  .IX Item "-dH"
  Produce a core dump whenever an error occurs.
! .IP \fB\-dp\fR 4
  .IX Item "-dp"
  Annotate the assembler output with a comment indicating which
  pattern and alternative is used.  The length and cost of each instruction are
  also printed.
! .IP \fB\-dP\fR 4
  .IX Item "-dP"
! Dump the RTL in the assembler output as a comment before each instruction.
  Also turns on \fB\-dp\fR annotation.
! .IP \fB\-dx\fR 4
  .IX Item "-dx"
! Just generate RTL for a function instead of compiling it.  Usually used
  with \fB\-fdump\-rtl\-expand\fR.
  .RE
  .RS 4
  .RE
! .IP \fB\-fdump\-debug\fR 4
  .IX Item "-fdump-debug"
  Dump debugging information generated during the debug
  generation phase.
! .IP \fB\-fdump\-earlydebug\fR 4
  .IX Item "-fdump-earlydebug"
  Dump debugging information generated during the early debug
  generation phase.
! .IP \fB\-fdump\-noaddr\fR 4
  .IX Item "-fdump-noaddr"
  When doing debugging dumps, suppress address output.  This makes it more
  feasible to use diff on debugging dumps for compiler invocations with
  different compiler binaries and/or different
  text / bss / data / heap / stack / dso start locations.
! .IP \fB\-freport\-bug\fR 4
  .IX Item "-freport-bug"
  Collect and dump debug information into a temporary file if an
! internal compiler error (ICE) occurs.
! .IP \fB\-fdump\-unnumbered\fR 4
  .IX Item "-fdump-unnumbered"
  When doing debugging dumps, suppress instruction numbers and address output.
  This makes it more feasible to use diff on debugging dumps for compiler
  invocations with different options, in particular with and without
  \&\fB\-g\fR.
! .IP \fB\-fdump\-unnumbered\-links\fR 4
  .IX Item "-fdump-unnumbered-links"
  When doing debugging dumps (see \fB\-d\fR option above), suppress
  instruction numbers for the links to the previous and next instructions
  in a sequence.
! .IP \fB\-fdump\-ipa\-\fR\fIswitch\fR 4
  .IX Item "-fdump-ipa-switch"
  .PD 0
! .IP \fB\-fdump\-ipa\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR 4
  .IX Item "-fdump-ipa-switch-options"
  .PD
! Control the dumping at various stages of inter\-procedural analysis
  language tree to a file.  The file name is generated by appending a
  switch specific suffix to the source file name, and the file is created
  in the same directory as the output file.  The following dumps are
  possible:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
! Enables all inter\-procedural analysis dumps.
! .IP \fBcgraph\fR 4
  .IX Item "cgraph"
! Dumps information about call\-graph optimization, unused function removal,
  and inlining decisions.
! .IP \fBinline\fR 4
  .IX Item "inline"
  Dump after function inlining.
  .RE
*************** that were not inlined.
*** 18540,18554 ****
  .Sp
  By default, the dump will contain messages about successful
  optimizations (equivalent to \fB\-optimized\fR) together with
! low-level details about the analysis.
  .RE
! .IP "\fB\-fdump\-ipa\-clones\fR" 4
  .IX Item "-fdump-ipa-clones"
  Create a dump file containing information about creation of call graph
! node clones and removals of call graph nodes during inter-procedural
  optimizations and transformations.  Its main intended use is that tools
! that create live-patches can determine the set of functions that need to
! be live-patched to completely replace a particular function (see
  \&\fB\-flive\-patching\fR).  The file name is generated by appending
  suffix \f(CW\*(C`ipa\-clones\*(C'\fR to the source file name, and the file is
  created in the same directory as the output file.  Each entry in the
--- 18471,18485 ----
  .Sp
  By default, the dump will contain messages about successful
  optimizations (equivalent to \fB\-optimized\fR) together with
! low\-level details about the analysis.
  .RE
! .IP \fB\-fdump\-ipa\-clones\fR 4
  .IX Item "-fdump-ipa-clones"
  Create a dump file containing information about creation of call graph
! node clones and removals of call graph nodes during inter\-procedural
  optimizations and transformations.  Its main intended use is that tools
! that create live\-patches can determine the set of functions that need to
! be live\-patched to completely replace a particular function (see
  \&\fB\-flive\-patching\fR).  The file name is generated by appending
  suffix \f(CW\*(C`ipa\-clones\*(C'\fR to the source file name, and the file is
  created in the same directory as the output file.  Each entry in the
*************** file is on a separate line containing se
*** 18556,18677 ****
  .Sp
  In the case of call graph clone creation, the individual fields are:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  String \f(CW\*(C`Callgraph clone\*(C'\fR.
! .IP "2." 4
  .IX Item "2."
  Name of the function being cloned as it is presented to the assembler.
! .IP "3." 4
  .IX Item "3."
  A number that uniquely represents the function being cloned in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole-program analysis but is likely to be different in the two
  phases.
! .IP "4." 4
  .IX Item "4."
  The file name of the source file where the function is defined.
! .IP "5." 4
  .IX Item "5."
  The line on which the function definition is located.
! .IP "6." 4
  .IX Item "6."
  The column where the function definition is located.
! .IP "7." 4
  .IX Item "7."
  Name of the new function clone as it is presented to the assembler.
! .IP "8." 4
  .IX Item "8."
  A number that uniquely represents the new function clone in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole-program analysis but is likely to be different in the two
  phases.
! .IP "9." 4
  .IX Item "9."
  The file name of the source file where the source code location of the
  new clone points to.
! .IP "10." 4
  .IX Item "10."
  The line to which the source code location of the new clone points to.
! .IP "11." 4
  .IX Item "11."
  The column to which the source code location of the new clone points to.
! .IP "12." 4
  .IX Item "12."
  A string that determines the reason for cloning.
  .RE
  .RS 4
  .Sp
  In the case of call graph clone removal, the individual fields are:
! .IP "1." 4
  .IX Item "1."
  String \f(CW\*(C`Callgraph removal\*(C'\fR.
! .IP "2." 4
  .IX Item "2."
  Name of the function being removed as it would be presented to the assembler.
! .IP "3." 4
  .IX Item "3."
  A number that uniquely represents the function being cloned in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole-program analysis but is likely to be different in the two
  phases.
! .IP "4." 4
  .IX Item "4."
  The file name of the source file where the function is defined.
! .IP "5." 4
  .IX Item "5."
  The line on which the function definition is located.
! .IP "6." 4
  .IX Item "6."
  The column where the function definition is located.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdump\-lang\fR" 4
  .IX Item "-fdump-lang"
! Dump language-specific information.  The file name is made by appending
  \&\fI.lang\fR to the source file name.
! .IP "\fB\-fdump\-lang\-all\fR" 4
  .IX Item "-fdump-lang-all"
  .PD 0
! .IP "\fB\-fdump\-lang\-\fR\fIswitch\fR" 4
  .IX Item "-fdump-lang-switch"
! .IP "\fB\-fdump\-lang\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR" 4
  .IX Item "-fdump-lang-switch-options"
! .IP "\fB\-fdump\-lang\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR" 4
  .IX Item "-fdump-lang-switch-options=filename"
  .PD
! Control the dumping of language-specific information.  The \fIoptions\fR
  and \fIfilename\fR portions behave as described in the
  \&\fB\-fdump\-tree\fR option.  The following \fIswitch\fR values are
  accepted:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
! Enable all language-specific dumps.
! .IP "\fBclass\fR" 4
  .IX Item "class"
  Dump class hierarchy information.  Virtual table information is emitted
! unless '\fBslim\fR' is specified.  This option is applicable to \*(C+ only.
! .IP "\fBmodule\fR" 4
  .IX Item "module"
  Dump module information.  Options \fBlineno\fR (locations),
  \&\fBgraph\fR (reachability), \fBblocks\fR (clusters),
  \&\fBuid\fR (serialization), \fBalias\fR (mergeable),
  \&\fBasmname\fR (Elrond), \fBeh\fR (mapper) & \fBvops\fR
  (macros) may provide additional information.  This option is
! applicable to \*(C+ only.
! .IP "\fBraw\fR" 4
  .IX Item "raw"
! Dump the raw internal tree data.  This option is applicable to \*(C+ only.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdump\-passes\fR" 4
  .IX Item "-fdump-passes"
  Print on \fIstderr\fR the list of optimization passes that are turned
! on and off by the current command-line options.
! .IP "\fB\-fdump\-statistics\-\fR\fIoption\fR" 4
  .IX Item "-fdump-statistics-option"
  Enable and control dumping of pass statistics in a separate file.  The
  file name is generated by appending a suffix ending in
--- 18487,18608 ----
  .Sp
  In the case of call graph clone creation, the individual fields are:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  String \f(CW\*(C`Callgraph clone\*(C'\fR.
! .IP 2. 4
  .IX Item "2."
  Name of the function being cloned as it is presented to the assembler.
! .IP 3. 4
  .IX Item "3."
  A number that uniquely represents the function being cloned in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole\-program analysis but is likely to be different in the two
  phases.
! .IP 4. 4
  .IX Item "4."
  The file name of the source file where the function is defined.
! .IP 5. 4
  .IX Item "5."
  The line on which the function definition is located.
! .IP 6. 4
  .IX Item "6."
  The column where the function definition is located.
! .IP 7. 4
  .IX Item "7."
  Name of the new function clone as it is presented to the assembler.
! .IP 8. 4
  .IX Item "8."
  A number that uniquely represents the new function clone in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole\-program analysis but is likely to be different in the two
  phases.
! .IP 9. 4
  .IX Item "9."
  The file name of the source file where the source code location of the
  new clone points to.
! .IP 10. 4
  .IX Item "10."
  The line to which the source code location of the new clone points to.
! .IP 11. 4
  .IX Item "11."
  The column to which the source code location of the new clone points to.
! .IP 12. 4
  .IX Item "12."
  A string that determines the reason for cloning.
  .RE
  .RS 4
  .Sp
  In the case of call graph clone removal, the individual fields are:
! .IP 1. 4
  .IX Item "1."
  String \f(CW\*(C`Callgraph removal\*(C'\fR.
! .IP 2. 4
  .IX Item "2."
  Name of the function being removed as it would be presented to the assembler.
! .IP 3. 4
  .IX Item "3."
  A number that uniquely represents the function being cloned in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole\-program analysis but is likely to be different in the two
  phases.
! .IP 4. 4
  .IX Item "4."
  The file name of the source file where the function is defined.
! .IP 5. 4
  .IX Item "5."
  The line on which the function definition is located.
! .IP 6. 4
  .IX Item "6."
  The column where the function definition is located.
  .RE
  .RS 4
  .RE
! .IP \fB\-fdump\-lang\fR 4
  .IX Item "-fdump-lang"
! Dump language\-specific information.  The file name is made by appending
  \&\fI.lang\fR to the source file name.
! .IP \fB\-fdump\-lang\-all\fR 4
  .IX Item "-fdump-lang-all"
  .PD 0
! .IP \fB\-fdump\-lang\-\fR\fIswitch\fR 4
  .IX Item "-fdump-lang-switch"
! .IP \fB\-fdump\-lang\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR 4
  .IX Item "-fdump-lang-switch-options"
! .IP \fB\-fdump\-lang\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR 4
  .IX Item "-fdump-lang-switch-options=filename"
  .PD
! Control the dumping of language\-specific information.  The \fIoptions\fR
  and \fIfilename\fR portions behave as described in the
  \&\fB\-fdump\-tree\fR option.  The following \fIswitch\fR values are
  accepted:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
! Enable all language\-specific dumps.
! .IP \fBclass\fR 4
  .IX Item "class"
  Dump class hierarchy information.  Virtual table information is emitted
! unless \*(Aq\fBslim\fR\*(Aq is specified.  This option is applicable to C++ only.
! .IP \fBmodule\fR 4
  .IX Item "module"
  Dump module information.  Options \fBlineno\fR (locations),
  \&\fBgraph\fR (reachability), \fBblocks\fR (clusters),
  \&\fBuid\fR (serialization), \fBalias\fR (mergeable),
  \&\fBasmname\fR (Elrond), \fBeh\fR (mapper) & \fBvops\fR
  (macros) may provide additional information.  This option is
! applicable to C++ only.
! .IP \fBraw\fR 4
  .IX Item "raw"
! Dump the raw internal tree data.  This option is applicable to C++ only.
  .RE
  .RS 4
  .RE
! .IP \fB\-fdump\-passes\fR 4
  .IX Item "-fdump-passes"
  Print on \fIstderr\fR the list of optimization passes that are turned
! on and off by the current command\-line options.
! .IP \fB\-fdump\-statistics\-\fR\fIoption\fR 4
  .IX Item "-fdump-statistics-option"
  Enable and control dumping of pass statistics in a separate file.  The
  file name is generated by appending a suffix ending in
*************** form is used, \fB\-stats\fR causes count
*** 18681,18694 ****
  whole compilation unit while \fB\-details\fR dumps every event as
  the passes generate them.  The default with no option is to sum
  counters for each function compiled.
! .IP "\fB\-fdump\-tree\-all\fR" 4
  .IX Item "-fdump-tree-all"
  .PD 0
! .IP "\fB\-fdump\-tree\-\fR\fIswitch\fR" 4
  .IX Item "-fdump-tree-switch"
! .IP "\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR" 4
  .IX Item "-fdump-tree-switch-options"
! .IP "\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR" 4
  .IX Item "-fdump-tree-switch-options=filename"
  .PD
  Control the dumping at various stages of processing the intermediate
--- 18612,18625 ----
  whole compilation unit while \fB\-details\fR dumps every event as
  the passes generate them.  The default with no option is to sum
  counters for each function compiled.
! .IP \fB\-fdump\-tree\-all\fR 4
  .IX Item "-fdump-tree-all"
  .PD 0
! .IP \fB\-fdump\-tree\-\fR\fIswitch\fR 4
  .IX Item "-fdump-tree-switch"
! .IP \fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR 4
  .IX Item "-fdump-tree-switch-options"
! .IP \fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR 4
  .IX Item "-fdump-tree-switch-options=filename"
  .PD
  Control the dumping at various stages of processing the intermediate
*************** which control the details of the dump.
*** 18698,18785 ****
  to all dumps; those that are not meaningful are ignored.  The
  following options are available
  .RS 4
! .IP "\fBaddress\fR" 4
  .IX Item "address"
  Print the address of each node.  Usually this is not meaningful as it
  changes according to the environment and source file.  Its primary use
  is for tying up a dump file with a debug environment.
! .IP "\fBasmname\fR" 4
  .IX Item "asmname"
  If \f(CW\*(C`DECL_ASSEMBLER_NAME\*(C'\fR has been set for a given decl, use that
  in the dump instead of \f(CW\*(C`DECL_NAME\*(C'\fR.  Its primary use is ease of
  use working backward from mangled names in the assembly file.
! .IP "\fBslim\fR" 4
  .IX Item "slim"
! When dumping front-end intermediate representations, inhibit dumping
  of members of a scope or body of a function merely because that scope
  has been reached.  Only dump such items when they are directly reachable
  by some other path.
  .Sp
! When dumping pretty-printed trees, this option inhibits dumping the
  bodies of control structures.
  .Sp
! When dumping \s-1RTL,\s0 print the \s-1RTL\s0 in slim (condensed) form instead of
! the default LISP-like representation.
! .IP "\fBraw\fR" 4
  .IX Item "raw"
  Print a raw representation of the tree.  By default, trees are
! pretty-printed into a C\-like representation.
! .IP "\fBdetails\fR" 4
  .IX Item "details"
  Enable more detailed dumps (not honored by every dump option). Also
  include information from the optimization passes.
! .IP "\fBstats\fR" 4
  .IX Item "stats"
  Enable dumping various statistics about the pass (not honored by every dump
  option).
! .IP "\fBblocks\fR" 4
  .IX Item "blocks"
  Enable showing basic block boundaries (disabled in raw dumps).
! .IP "\fBgraph\fR" 4
  .IX Item "graph"
  For each of the other indicated dump files (\fB\-fdump\-rtl\-\fR\fIpass\fR),
  dump a representation of the control flow graph suitable for viewing with
! GraphViz to \fI\fIfile\fI.\fIpassid\fI.\fIpass\fI.dot\fR.  Each function in
! the file is pretty-printed as a subgraph, so that GraphViz can render them
  all in a single plot.
  .Sp
! This option currently only works for \s-1RTL\s0 dumps, and the \s-1RTL\s0 is always
  dumped in slim form.
! .IP "\fBvops\fR" 4
  .IX Item "vops"
  Enable showing virtual operands for every statement.
! .IP "\fBlineno\fR" 4
  .IX Item "lineno"
  Enable showing line numbers for statements.
! .IP "\fBuid\fR" 4
  .IX Item "uid"
! Enable showing the unique \s-1ID\s0 (\f(CW\*(C`DECL_UID\*(C'\fR) for each variable.
! .IP "\fBverbose\fR" 4
  .IX Item "verbose"
  Enable showing the tree dump for each statement.
! .IP "\fBeh\fR" 4
  .IX Item "eh"
! Enable showing the \s-1EH\s0 region number holding each statement.
! .IP "\fBscev\fR" 4
  .IX Item "scev"
  Enable showing scalar evolution analysis details.
! .IP "\fBoptimized\fR" 4
  .IX Item "optimized"
  Enable showing optimization information (only available in certain
  passes).
! .IP "\fBmissed\fR" 4
  .IX Item "missed"
  Enable showing missed optimization information (only available in certain
  passes).
! .IP "\fBnote\fR" 4
  .IX Item "note"
  Enable other detailed optimization information (only available in
  certain passes).
! .IP "\fBall\fR" 4
  .IX Item "all"
  Turn on all options, except \fBraw\fR, \fBslim\fR, \fBverbose\fR
  and \fBlineno\fR.
! .IP "\fBoptall\fR" 4
  .IX Item "optall"
  Turn on all optimization options, i.e., \fBoptimized\fR,
  \&\fBmissed\fR, and \fBnote\fR.
--- 18629,18716 ----
  to all dumps; those that are not meaningful are ignored.  The
  following options are available
  .RS 4
! .IP \fBaddress\fR 4
  .IX Item "address"
  Print the address of each node.  Usually this is not meaningful as it
  changes according to the environment and source file.  Its primary use
  is for tying up a dump file with a debug environment.
! .IP \fBasmname\fR 4
  .IX Item "asmname"
  If \f(CW\*(C`DECL_ASSEMBLER_NAME\*(C'\fR has been set for a given decl, use that
  in the dump instead of \f(CW\*(C`DECL_NAME\*(C'\fR.  Its primary use is ease of
  use working backward from mangled names in the assembly file.
! .IP \fBslim\fR 4
  .IX Item "slim"
! When dumping front\-end intermediate representations, inhibit dumping
  of members of a scope or body of a function merely because that scope
  has been reached.  Only dump such items when they are directly reachable
  by some other path.
  .Sp
! When dumping pretty\-printed trees, this option inhibits dumping the
  bodies of control structures.
  .Sp
! When dumping RTL, print the RTL in slim (condensed) form instead of
! the default LISP\-like representation.
! .IP \fBraw\fR 4
  .IX Item "raw"
  Print a raw representation of the tree.  By default, trees are
! pretty\-printed into a C\-like representation.
! .IP \fBdetails\fR 4
  .IX Item "details"
  Enable more detailed dumps (not honored by every dump option). Also
  include information from the optimization passes.
! .IP \fBstats\fR 4
  .IX Item "stats"
  Enable dumping various statistics about the pass (not honored by every dump
  option).
! .IP \fBblocks\fR 4
  .IX Item "blocks"
  Enable showing basic block boundaries (disabled in raw dumps).
! .IP \fBgraph\fR 4
  .IX Item "graph"
  For each of the other indicated dump files (\fB\-fdump\-rtl\-\fR\fIpass\fR),
  dump a representation of the control flow graph suitable for viewing with
! GraphViz to \fIfile.passid.pass.dot\fR.  Each function in
! the file is pretty\-printed as a subgraph, so that GraphViz can render them
  all in a single plot.
  .Sp
! This option currently only works for RTL dumps, and the RTL is always
  dumped in slim form.
! .IP \fBvops\fR 4
  .IX Item "vops"
  Enable showing virtual operands for every statement.
! .IP \fBlineno\fR 4
  .IX Item "lineno"
  Enable showing line numbers for statements.
! .IP \fBuid\fR 4
  .IX Item "uid"
! Enable showing the unique ID (\f(CW\*(C`DECL_UID\*(C'\fR) for each variable.
! .IP \fBverbose\fR 4
  .IX Item "verbose"
  Enable showing the tree dump for each statement.
! .IP \fBeh\fR 4
  .IX Item "eh"
! Enable showing the EH region number holding each statement.
! .IP \fBscev\fR 4
  .IX Item "scev"
  Enable showing scalar evolution analysis details.
! .IP \fBoptimized\fR 4
  .IX Item "optimized"
  Enable showing optimization information (only available in certain
  passes).
! .IP \fBmissed\fR 4
  .IX Item "missed"
  Enable showing missed optimization information (only available in certain
  passes).
! .IP \fBnote\fR 4
  .IX Item "note"
  Enable other detailed optimization information (only available in
  certain passes).
! .IP \fBall\fR 4
  .IX Item "all"
  Turn on all options, except \fBraw\fR, \fBslim\fR, \fBverbose\fR
  and \fBlineno\fR.
! .IP \fBoptall\fR 4
  .IX Item "optall"
  Turn on all optimization options, i.e., \fBoptimized\fR,
  \&\fBmissed\fR, and \fBnote\fR.
*************** Turn on all optimization options, i.e.,
*** 18788,18827 ****
  .Sp
  To determine what tree dumps are available or find the dump for a pass
  of interest follow the steps below.
! .IP "1." 4
  .IX Item "1."
! Invoke \s-1GCC\s0 with \fB\-fdump\-passes\fR and in the \fIstderr\fR output
  look for a code that corresponds to the pass you are interested in.
  For example, the codes \f(CW\*(C`tree\-evrp\*(C'\fR, \f(CW\*(C`tree\-vrp1\*(C'\fR, and
  \&\f(CW\*(C`tree\-vrp2\*(C'\fR correspond to the three Value Range Propagation passes.
  The number at the end distinguishes distinct invocations of the same pass.
! .IP "2." 4
  .IX Item "2."
  To enable the creation of the dump file, append the pass code to
! the \fB\-fdump\-\fR option prefix and invoke \s-1GCC\s0 with it.  For example,
  to enable the dump from the Early Value Range Propagation pass, invoke
! \&\s-1GCC\s0 with the \fB\-fdump\-tree\-evrp\fR option.  Optionally, you may
! specify the name of the dump file.  If you don't specify one, \s-1GCC\s0
  creates as described below.
! .IP "3." 4
  .IX Item "3."
  Find the pass dump in a file whose name is composed of three components
! separated by a period: the name of the source file \s-1GCC\s0 was invoked to
  compile, a numeric suffix indicating the pass number followed by the
! letter \fBt\fR for tree passes (and the letter \fBr\fR for \s-1RTL\s0 passes),
! and finally the pass code.  For example, the Early \s-1VRP\s0 pass dump might
  be in a file named \fImyfile.c.038t.evrp\fR in the current working
  directory.  Note that the numeric codes are not stable and may change
! from one version of \s-1GCC\s0 to another.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fopt\-info\fR" 4
  .IX Item "-fopt-info"
  .PD 0
! .IP "\fB\-fopt\-info\-\fR\fIoptions\fR" 4
  .IX Item "-fopt-info-options"
! .IP "\fB\-fopt\-info\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR" 4
  .IX Item "-fopt-info-options=filename"
  .PD
  Controls optimization dumps from various optimization passes. If the
--- 18719,18758 ----
  .Sp
  To determine what tree dumps are available or find the dump for a pass
  of interest follow the steps below.
! .IP 1. 4
  .IX Item "1."
! Invoke GCC with \fB\-fdump\-passes\fR and in the \fIstderr\fR output
  look for a code that corresponds to the pass you are interested in.
  For example, the codes \f(CW\*(C`tree\-evrp\*(C'\fR, \f(CW\*(C`tree\-vrp1\*(C'\fR, and
  \&\f(CW\*(C`tree\-vrp2\*(C'\fR correspond to the three Value Range Propagation passes.
  The number at the end distinguishes distinct invocations of the same pass.
! .IP 2. 4
  .IX Item "2."
  To enable the creation of the dump file, append the pass code to
! the \fB\-fdump\-\fR option prefix and invoke GCC with it.  For example,
  to enable the dump from the Early Value Range Propagation pass, invoke
! GCC with the \fB\-fdump\-tree\-evrp\fR option.  Optionally, you may
! specify the name of the dump file.  If you don\*(Aqt specify one, GCC
  creates as described below.
! .IP 3. 4
  .IX Item "3."
  Find the pass dump in a file whose name is composed of three components
! separated by a period: the name of the source file GCC was invoked to
  compile, a numeric suffix indicating the pass number followed by the
! letter \fBt\fR for tree passes (and the letter \fBr\fR for RTL passes),
! and finally the pass code.  For example, the Early VRP pass dump might
  be in a file named \fImyfile.c.038t.evrp\fR in the current working
  directory.  Note that the numeric codes are not stable and may change
! from one version of GCC to another.
  .RE
  .RS 4
  .RE
! .IP \fB\-fopt\-info\fR 4
  .IX Item "-fopt-info"
  .PD 0
! .IP \fB\-fopt\-info\-\fR\fIoptions\fR 4
  .IX Item "-fopt-info-options"
! .IP \fB\-fopt\-info\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR 4
  .IX Item "-fopt-info-options=filename"
  .PD
  Controls optimization dumps from various optimization passes. If the
*************** optimizations.
*** 18831,18869 ****
  .Sp
  The \fIoptions\fR can be divided into three groups:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  options describing what kinds of messages should be emitted,
! .IP "2." 4
  .IX Item "2."
  options describing the verbosity of the dump, and
! .IP "3." 4
  .IX Item "3."
  options describing which optimizations should be included.
  .RE
  .RS 4
  .Sp
  The options from each group can be freely mixed as they are
! non-overlapping. However, in case of any conflicts,
  the later options override the earlier options on the command
  line.
  .Sp
  The following options control which kinds of messages should be emitted:
! .IP "\fBoptimized\fR" 4
  .IX Item "optimized"
  Print information when an optimization is successfully applied. It is
  up to a pass to decide which information is relevant. For example, the
  vectorizer passes print the source location of loops which are
  successfully vectorized.
! .IP "\fBmissed\fR" 4
  .IX Item "missed"
  Print information about missed optimizations. Individual passes
  control which information to include in the output.
! .IP "\fBnote\fR" 4
  .IX Item "note"
  Print verbose information about optimizations, such as certain
  transformations, more detailed messages about decisions etc.
! .IP "\fBall\fR" 4
  .IX Item "all"
  Print detailed optimization information. This includes
  \&\fBoptimized\fR, \fBmissed\fR, and \fBnote\fR.
--- 18762,18800 ----
  .Sp
  The \fIoptions\fR can be divided into three groups:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  options describing what kinds of messages should be emitted,
! .IP 2. 4
  .IX Item "2."
  options describing the verbosity of the dump, and
! .IP 3. 4
  .IX Item "3."
  options describing which optimizations should be included.
  .RE
  .RS 4
  .Sp
  The options from each group can be freely mixed as they are
! non\-overlapping. However, in case of any conflicts,
  the later options override the earlier options on the command
  line.
  .Sp
  The following options control which kinds of messages should be emitted:
! .IP \fBoptimized\fR 4
  .IX Item "optimized"
  Print information when an optimization is successfully applied. It is
  up to a pass to decide which information is relevant. For example, the
  vectorizer passes print the source location of loops which are
  successfully vectorized.
! .IP \fBmissed\fR 4
  .IX Item "missed"
  Print information about missed optimizations. Individual passes
  control which information to include in the output.
! .IP \fBnote\fR 4
  .IX Item "note"
  Print verbose information about optimizations, such as certain
  transformations, more detailed messages about decisions etc.
! .IP \fBall\fR 4
  .IX Item "all"
  Print detailed optimization information. This includes
  \&\fBoptimized\fR, \fBmissed\fR, and \fBnote\fR.
*************** Print detailed optimization information.
*** 18871,18902 ****
  .RS 4
  .Sp
  The following option controls the dump verbosity:
! .IP "\fBinternals\fR" 4
  .IX Item "internals"
! By default, only \*(L"high-level\*(R" messages are emitted. This option enables
  additional, more detailed, messages, which are likely to only be of interest
! to \s-1GCC\s0 developers.
  .RE
  .RS 4
  .Sp
  One or more of the following option keywords can be used to describe a
  group of optimizations:
! .IP "\fBipa\fR" 4
  .IX Item "ipa"
  Enable dumps from all interprocedural optimizations.
! .IP "\fBloop\fR" 4
  .IX Item "loop"
  Enable dumps from all loop optimizations.
! .IP "\fBinline\fR" 4
  .IX Item "inline"
  Enable dumps from all inlining optimizations.
! .IP "\fBomp\fR" 4
  .IX Item "omp"
! Enable dumps from all \s-1OMP\s0 (Offloading and Multi Processing) optimizations.
! .IP "\fBvec\fR" 4
  .IX Item "vec"
  Enable dumps from all vectorization optimizations.
! .IP "\fBoptall\fR" 4
  .IX Item "optall"
  Enable dumps from all optimizations. This is a superset of
  the optimization groups listed above.
--- 18802,18833 ----
  .RS 4
  .Sp
  The following option controls the dump verbosity:
! .IP \fBinternals\fR 4
  .IX Item "internals"
! By default, only "high\-level" messages are emitted. This option enables
  additional, more detailed, messages, which are likely to only be of interest
! to GCC developers.
  .RE
  .RS 4
  .Sp
  One or more of the following option keywords can be used to describe a
  group of optimizations:
! .IP \fBipa\fR 4
  .IX Item "ipa"
  Enable dumps from all interprocedural optimizations.
! .IP \fBloop\fR 4
  .IX Item "loop"
  Enable dumps from all loop optimizations.
! .IP \fBinline\fR 4
  .IX Item "inline"
  Enable dumps from all inlining optimizations.
! .IP \fBomp\fR 4
  .IX Item "omp"
! Enable dumps from all OMP (Offloading and Multi Processing) optimizations.
! .IP \fBvec\fR 4
  .IX Item "vec"
  Enable dumps from all vectorization optimizations.
! .IP \fBoptall\fR 4
  .IX Item "optall"
  Enable dumps from all optimizations. This is a superset of
  the optimization groups listed above.
*************** the optimization groups listed above.
*** 18904,18912 ****
  .RS 4
  .Sp
  If \fIoptions\fR is
! omitted, it defaults to \fBoptimized-optall\fR, which means to dump messages
  about successful optimizations from all the passes, omitting messages
! that are treated as \*(L"internals\*(R".
  .Sp
  If the \fIfilename\fR is provided, then the dumps from all the
  applicable optimizations are concatenated into the \fIfilename\fR.
--- 18835,18843 ----
  .RS 4
  .Sp
  If \fIoptions\fR is
! omitted, it defaults to \fBoptimized\-optall\fR, which means to dump messages
  about successful optimizations from all the passes, omitting messages
! that are treated as "internals".
  .Sp
  If the \fIfilename\fR is provided, then the dumps from all the
  applicable optimizations are concatenated into the \fIfilename\fR.
*************** the first option takes effect and the su
*** 18968,19004 ****
  ignored. Thus only \fIvec.miss\fR is produced which contains
  dumps from the vectorizer about missed opportunities.
  .RE
! .IP "\fB\-fsave\-optimization\-record\fR" 4
  .IX Item "-fsave-optimization-record"
! Write a \s-1SRCFILE\s0.opt\-record.json.gz file detailing what optimizations
  were performed, for those optimizations that support \fB\-fopt\-info\fR.
  .Sp
  This option is experimental and the format of the data within the
! compressed \s-1JSON\s0 file is subject to change.
  .Sp
! It is roughly equivalent to a machine-readable version of
  \&\fB\-fopt\-info\-all\fR, as a collection of messages with source file,
  line number and column number, with the following additional data for
  each message:
  .RS 4
! .IP "*" 4
  the execution count of the code being optimized, along with metadata about
  whether this was from actual profile data, or just an estimate, allowing
  consumers to prioritize messages by code hotness,
! .IP "*" 4
  the function name of the code being optimized, where applicable,
! .IP "*" 4
! the \*(L"inlining chain\*(R" for the code being optimized, so that when
  a function is inlined into several different places (which might
  themselves be inlined), the reader can distinguish between the copies,
! .IP "*" 4
  objects identifying those parts of the message that refer to expressions,
! statements or symbol-table nodes, which of these categories they are, and,
  when available, their source code location,
! .IP "*" 4
! the \s-1GCC\s0 pass that emitted the message, and
! .IP "*" 4
! the location in \s-1GCC\s0's own code from which the message was emitted
  .RE
  .RS 4
  .Sp
--- 18899,18935 ----
  ignored. Thus only \fIvec.miss\fR is produced which contains
  dumps from the vectorizer about missed opportunities.
  .RE
! .IP \fB\-fsave\-optimization\-record\fR 4
  .IX Item "-fsave-optimization-record"
! Write a SRCFILE.opt\-record.json.gz file detailing what optimizations
  were performed, for those optimizations that support \fB\-fopt\-info\fR.
  .Sp
  This option is experimental and the format of the data within the
! compressed JSON file is subject to change.
  .Sp
! It is roughly equivalent to a machine\-readable version of
  \&\fB\-fopt\-info\-all\fR, as a collection of messages with source file,
  line number and column number, with the following additional data for
  each message:
  .RS 4
! .IP * 4
  the execution count of the code being optimized, along with metadata about
  whether this was from actual profile data, or just an estimate, allowing
  consumers to prioritize messages by code hotness,
! .IP * 4
  the function name of the code being optimized, where applicable,
! .IP * 4
! the "inlining chain" for the code being optimized, so that when
  a function is inlined into several different places (which might
  themselves be inlined), the reader can distinguish between the copies,
! .IP * 4
  objects identifying those parts of the message that refer to expressions,
! statements or symbol\-table nodes, which of these categories they are, and,
  when available, their source code location,
! .IP * 4
! the GCC pass that emitted the message, and
! .IP * 4
! the location in GCC\*(Aqs own code from which the message was emitted
  .RE
  .RS 4
  .Sp
*************** Additionally, some messages are logicall
*** 19006,19012 ****
  messages, reflecting implementation details of the optimization
  passes.
  .RE
! .IP "\fB\-fsched\-verbose=\fR\fIn\fR" 4
  .IX Item "-fsched-verbose=n"
  On targets that use instruction scheduling, this option controls the
  amount of debugging output the scheduler prints to the dump files.
--- 18937,18943 ----
  messages, reflecting implementation details of the optimization
  passes.
  .RE
! .IP \fB\-fsched\-verbose=\fR\fIn\fR 4
  .IX Item "-fsched-verbose=n"
  On targets that use instruction scheduling, this option controls the
  amount of debugging output the scheduler prints to the dump files.
*************** For \fIn\fR greater than zero, \fB\-fsch
*** 19015,19080 ****
  same information as \fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR.
  For \fIn\fR greater than one, it also output basic block probabilities,
  detailed ready list information and unit/insn info.  For \fIn\fR greater
! than two, it includes \s-1RTL\s0 at abort point, control-flow and regions info.
  And for \fIn\fR over four, \fB\-fsched\-verbose\fR also includes
  dependence info.
! .IP "\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR" 4
  .IX Item "-fenable-kind-pass"
  .PD 0
! .IP "\fB\-fdisable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
  .IX Item "-fdisable-kind-pass=range-list"
  .PD
  This is a set of options that are used to explicitly disable/enable
! optimization passes.  These options are intended for use for debugging \s-1GCC.\s0
  Compiler users should use regular options for enabling/disabling
  passes instead.
  .RS 4
! .IP "\fB\-fdisable\-ipa\-\fR\fIpass\fR" 4
  .IX Item "-fdisable-ipa-pass"
! Disable \s-1IPA\s0 pass \fIpass\fR. \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
  appended with a sequential number starting from 1.
! .IP "\fB\-fdisable\-rtl\-\fR\fIpass\fR" 4
  .IX Item "-fdisable-rtl-pass"
  .PD 0
! .IP "\fB\-fdisable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
  .IX Item "-fdisable-rtl-pass=range-list"
  .PD
! Disable \s-1RTL\s0 pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
! appended with a sequential number starting from 1.  \fIrange-list\fR is a 
! comma-separated list of function ranges or assembler names.  Each range is a number
  pair separated by a colon.  The range is inclusive in both ends.  If the range
  is trivial, the number pair can be simplified as a single number.  If the
! function's call graph node's \fIuid\fR falls within one of the specified ranges,
  the \fIpass\fR is disabled for that function.  The \fIuid\fR is shown in the
  function header of a dump file, and the pass names can be dumped by using
  option \fB\-fdump\-passes\fR.
! .IP "\fB\-fdisable\-tree\-\fR\fIpass\fR" 4
  .IX Item "-fdisable-tree-pass"
  .PD 0
! .IP "\fB\-fdisable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
  .IX Item "-fdisable-tree-pass=range-list"
  .PD
  Disable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description of
  option arguments.
! .IP "\fB\-fenable\-ipa\-\fR\fIpass\fR" 4
  .IX Item "-fenable-ipa-pass"
! Enable \s-1IPA\s0 pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
  appended with a sequential number starting from 1.
! .IP "\fB\-fenable\-rtl\-\fR\fIpass\fR" 4
  .IX Item "-fenable-rtl-pass"
  .PD 0
! .IP "\fB\-fenable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
  .IX Item "-fenable-rtl-pass=range-list"
  .PD
! Enable \s-1RTL\s0 pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for option argument
  description and examples.
! .IP "\fB\-fenable\-tree\-\fR\fIpass\fR" 4
  .IX Item "-fenable-tree-pass"
  .PD 0
! .IP "\fB\-fenable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
  .IX Item "-fenable-tree-pass=range-list"
  .PD
  Enable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description
--- 18946,19011 ----
  same information as \fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR.
  For \fIn\fR greater than one, it also output basic block probabilities,
  detailed ready list information and unit/insn info.  For \fIn\fR greater
! than two, it includes RTL at abort point, control\-flow and regions info.
  And for \fIn\fR over four, \fB\-fsched\-verbose\fR also includes
  dependence info.
! .IP \fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR 4
  .IX Item "-fenable-kind-pass"
  .PD 0
! .IP \fB\-fdisable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR 4
  .IX Item "-fdisable-kind-pass=range-list"
  .PD
  This is a set of options that are used to explicitly disable/enable
! optimization passes.  These options are intended for use for debugging GCC.
  Compiler users should use regular options for enabling/disabling
  passes instead.
  .RS 4
! .IP \fB\-fdisable\-ipa\-\fR\fIpass\fR 4
  .IX Item "-fdisable-ipa-pass"
! Disable IPA pass \fIpass\fR. \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
  appended with a sequential number starting from 1.
! .IP \fB\-fdisable\-rtl\-\fR\fIpass\fR 4
  .IX Item "-fdisable-rtl-pass"
  .PD 0
! .IP \fB\-fdisable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR 4
  .IX Item "-fdisable-rtl-pass=range-list"
  .PD
! Disable RTL pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
! appended with a sequential number starting from 1.  \fIrange\-list\fR is a 
! comma\-separated list of function ranges or assembler names.  Each range is a number
  pair separated by a colon.  The range is inclusive in both ends.  If the range
  is trivial, the number pair can be simplified as a single number.  If the
! function\*(Aqs call graph node\*(Aqs \fIuid\fR falls within one of the specified ranges,
  the \fIpass\fR is disabled for that function.  The \fIuid\fR is shown in the
  function header of a dump file, and the pass names can be dumped by using
  option \fB\-fdump\-passes\fR.
! .IP \fB\-fdisable\-tree\-\fR\fIpass\fR 4
  .IX Item "-fdisable-tree-pass"
  .PD 0
! .IP \fB\-fdisable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR 4
  .IX Item "-fdisable-tree-pass=range-list"
  .PD
  Disable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description of
  option arguments.
! .IP \fB\-fenable\-ipa\-\fR\fIpass\fR 4
  .IX Item "-fenable-ipa-pass"
! Enable IPA pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
  appended with a sequential number starting from 1.
! .IP \fB\-fenable\-rtl\-\fR\fIpass\fR 4
  .IX Item "-fenable-rtl-pass"
  .PD 0
! .IP \fB\-fenable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR 4
  .IX Item "-fenable-rtl-pass=range-list"
  .PD
! Enable RTL pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for option argument
  description and examples.
! .IP \fB\-fenable\-tree\-\fR\fIpass\fR 4
  .IX Item "-fenable-tree-pass"
  .PD 0
! .IP \fB\-fenable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR 4
  .IX Item "-fenable-tree-pass=range-list"
  .PD
  Enable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description
*************** Here are some examples showing uses of t
*** 19101,19118 ****
  \&           \-fenable\-tree\-unroll
  .Ve
  .RE
! .IP "\fB\-fchecking\fR" 4
  .IX Item "-fchecking"
  .PD 0
! .IP "\fB\-fchecking=\fR\fIn\fR" 4
  .IX Item "-fchecking=n"
  .PD
  Enable internal consistency checking.  The default depends on
  the compiler configuration.  \fB\-fchecking=2\fR enables further
  internal consistency checking that might affect code generation.
! .IP "\fB\-frandom\-seed=\fR\fIstring\fR" 4
  .IX Item "-frandom-seed=string"
! This option provides a seed that \s-1GCC\s0 uses in place of
  random numbers in generating certain symbol names
  that have to be different in every compiled file.  It is also used to
  place unique stamps in coverage data files and the object files that
--- 19032,19049 ----
  \&           \-fenable\-tree\-unroll
  .Ve
  .RE
! .IP \fB\-fchecking\fR 4
  .IX Item "-fchecking"
  .PD 0
! .IP \fB\-fchecking=\fR\fIn\fR 4
  .IX Item "-fchecking=n"
  .PD
  Enable internal consistency checking.  The default depends on
  the compiler configuration.  \fB\-fchecking=2\fR enables further
  internal consistency checking that might affect code generation.
! .IP \fB\-frandom\-seed=\fR\fIstring\fR 4
  .IX Item "-frandom-seed=string"
! This option provides a seed that GCC uses in place of
  random numbers in generating certain symbol names
  that have to be different in every compiled file.  It is also used to
  place unique stamps in coverage data files and the object files that
*************** produce them.  You can use the \fB\-fran
*** 19120,19153 ****
  reproducibly identical object files.
  .Sp
  The \fIstring\fR can either be a number (decimal, octal or hex) or an
! arbitrary string (in which case it's converted to a number by
! computing \s-1CRC32\s0).
  .Sp
  The \fIstring\fR should be different for every file you compile.
! .IP "\fB\-save\-temps\fR" 4
  .IX Item "-save-temps"
! Store the usual \*(L"temporary\*(R" intermediate files permanently; name them
  as auxiliary output files, as specified described under
  \&\fB\-dumpbase\fR and \fB\-dumpdir\fR.
  .Sp
! When used in combination with the \fB\-x\fR command-line option,
  \&\fB\-save\-temps\fR is sensible enough to avoid overwriting an
  input source file with the same extension as an intermediate file.
  The corresponding intermediate file may be obtained by renaming the
  source file before using \fB\-save\-temps\fR.
! .IP "\fB\-save\-temps=cwd\fR" 4
  .IX Item "-save-temps=cwd"
  Equivalent to \fB\-save\-temps \-dumpdir ./\fR.
! .IP "\fB\-save\-temps=obj\fR" 4
  .IX Item "-save-temps=obj"
! Equivalent to \fB\-save\-temps \-dumpdir \f(BIoutdir/\fB\fR, where
  \&\fIoutdir/\fR is the directory of the output file specified after the
  \&\fB\-o\fR option, including any directory separators.  If the
  \&\fB\-o\fR option is not used, the \fB\-save\-temps=obj\fR switch
  behaves like \fB\-save\-temps=cwd\fR.
! .IP "\fB\-time\fR[\fB=\fR\fIfile\fR]" 4
  .IX Item "-time[=file]"
! Report the \s-1CPU\s0 time taken by each subprocess in the compilation
  sequence.  For C source files, this is the compiler proper and assembler
  (plus the linker if linking is done).
  .Sp
--- 19051,19084 ----
  reproducibly identical object files.
  .Sp
  The \fIstring\fR can either be a number (decimal, octal or hex) or an
! arbitrary string (in which case it\*(Aqs converted to a number by
! computing CRC32).
  .Sp
  The \fIstring\fR should be different for every file you compile.
! .IP \fB\-save\-temps\fR 4
  .IX Item "-save-temps"
! Store the usual "temporary" intermediate files permanently; name them
  as auxiliary output files, as specified described under
  \&\fB\-dumpbase\fR and \fB\-dumpdir\fR.
  .Sp
! When used in combination with the \fB\-x\fR command\-line option,
  \&\fB\-save\-temps\fR is sensible enough to avoid overwriting an
  input source file with the same extension as an intermediate file.
  The corresponding intermediate file may be obtained by renaming the
  source file before using \fB\-save\-temps\fR.
! .IP \fB\-save\-temps=cwd\fR 4
  .IX Item "-save-temps=cwd"
  Equivalent to \fB\-save\-temps \-dumpdir ./\fR.
! .IP \fB\-save\-temps=obj\fR 4
  .IX Item "-save-temps=obj"
! Equivalent to \fB\-save\-temps \-dumpdir \fR\f(BIoutdir/\fR, where
  \&\fIoutdir/\fR is the directory of the output file specified after the
  \&\fB\-o\fR option, including any directory separators.  If the
  \&\fB\-o\fR option is not used, the \fB\-save\-temps=obj\fR switch
  behaves like \fB\-save\-temps=cwd\fR.
! .IP \fB\-time\fR[\fB=\fR\fIfile\fR] 4
  .IX Item "-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).
  .Sp
*************** Without the specification of an output f
*** 19158,19165 ****
  \&        # as 0.00 0.01
  .Ve
  .Sp
! The first number on each line is the \*(L"user time\*(R", that is time spent
! executing the program itself.  The second number is \*(L"system time\*(R",
  time spent executing operating system routines on behalf of the program.
  Both numbers are in seconds.
  .Sp
--- 19089,19096 ----
  \&        # as 0.00 0.01
  .Ve
  .Sp
! 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.
  .Sp
*************** named file, and it looks like this:
*** 19171,19186 ****
  \&        0.00 0.01 as 
  .Ve
  .Sp
! The \*(L"user time\*(R" and the \*(L"system time\*(R" are moved before the program
  name, and the options passed to the program are displayed, so that one
  can later tell what file was being compiled, and with which options.
! .IP "\fB\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR]" 4
  .IX Item "-fdump-final-insns[=file]"
! Dump the final internal representation (\s-1RTL\s0) to \fIfile\fR.  If the
  optional argument is omitted (or if \fIfile\fR is \f(CW\*(C`.\*(C'\fR), the name
  of the dump file is determined by appending \f(CW\*(C`.gkd\*(C'\fR to the
  dump base name, see \fB\-dumpbase\fR.
! .IP "\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]" 4
  .IX Item "-fcompare-debug[=opts]"
  If no error occurs during compilation, run the compiler a second time,
  adding \fIopts\fR and \fB\-fcompare\-debug\-second\fR to the arguments
--- 19102,19117 ----
  \&        0.00 0.01 as 
  .Ve
  .Sp
! 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.
! .IP \fB\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR] 4
  .IX Item "-fdump-final-insns[=file]"
! Dump the final internal representation (RTL) to \fIfile\fR.  If the
  optional argument is omitted (or if \fIfile\fR is \f(CW\*(C`.\*(C'\fR), the name
  of the dump file is determined by appending \f(CW\*(C`.gkd\*(C'\fR to the
  dump base name, see \fB\-dumpbase\fR.
! .IP \fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR] 4
  .IX Item "-fcompare-debug[=opts]"
  If no error occurs during compilation, run the compiler a second time,
  adding \fIopts\fR and \fB\-fcompare\-debug\-second\fR to the arguments
*************** representation in both compilations, and
*** 19189,19212 ****
  .Sp
  If the equal sign is omitted, the default \fB\-gtoggle\fR is used.
  .Sp
! The environment variable \fB\s-1GCC_COMPARE_DEBUG\s0\fR, if defined, non-empty
  and nonzero, implicitly enables \fB\-fcompare\-debug\fR.  If
! \&\fB\s-1GCC_COMPARE_DEBUG\s0\fR is defined to a string starting with a dash,
  then it is used for \fIopts\fR, otherwise the default \fB\-gtoggle\fR
  is used.
  .Sp
  \&\fB\-fcompare\-debug=\fR, with the equal sign but without \fIopts\fR,
  is equivalent to \fB\-fno\-compare\-debug\fR, which disables the dumping
  of the final representation and the second compilation, preventing even
! \&\fB\s-1GCC_COMPARE_DEBUG\s0\fR from taking effect.
  .Sp
  To verify full coverage during \fB\-fcompare\-debug\fR testing, set
! \&\fB\s-1GCC_COMPARE_DEBUG\s0\fR to say \fB\-fcompare\-debug\-not\-overridden\fR,
! which \s-1GCC\s0 rejects as an invalid option in any actual compilation
  (rather than preprocessing, assembly or linking).  To get just a
! warning, setting \fB\s-1GCC_COMPARE_DEBUG\s0\fR to \fB\-w%n\-fcompare\-debug
  not overridden\fR will do.
! .IP "\fB\-fcompare\-debug\-second\fR" 4
  .IX Item "-fcompare-debug-second"
  This option is implicitly passed to the compiler for the second
  compilation requested by \fB\-fcompare\-debug\fR, along with options to
--- 19120,19143 ----
  .Sp
  If the equal sign is omitted, the default \fB\-gtoggle\fR is used.
  .Sp
! The environment variable \fBGCC_COMPARE_DEBUG\fR, if defined, non\-empty
  and nonzero, implicitly enables \fB\-fcompare\-debug\fR.  If
! \&\fBGCC_COMPARE_DEBUG\fR is defined to a string starting with a dash,
  then it is used for \fIopts\fR, otherwise the default \fB\-gtoggle\fR
  is used.
  .Sp
  \&\fB\-fcompare\-debug=\fR, with the equal sign but without \fIopts\fR,
  is equivalent to \fB\-fno\-compare\-debug\fR, which disables the dumping
  of the final representation and the second compilation, preventing even
! \&\fBGCC_COMPARE_DEBUG\fR from taking effect.
  .Sp
  To verify full coverage during \fB\-fcompare\-debug\fR testing, set
! \&\fBGCC_COMPARE_DEBUG\fR to say \fB\-fcompare\-debug\-not\-overridden\fR,
! which GCC rejects as an invalid option in any actual compilation
  (rather than preprocessing, assembly or linking).  To get just a
! warning, setting \fBGCC_COMPARE_DEBUG\fR to \fB\-w%n\-fcompare\-debug
  not overridden\fR will do.
! .IP \fB\-fcompare\-debug\-second\fR 4
  .IX Item "-fcompare-debug-second"
  This option is implicitly passed to the compiler for the second
  compilation requested by \fB\-fcompare\-debug\fR, along with options to
*************** overwriting those generated by the first
*** 19219,19225 ****
  When this option is passed to the compiler driver, it causes the
  \&\fIfirst\fR compilation to be skipped, which makes it useful for little
  other than debugging the compiler proper.
! .IP "\fB\-gtoggle\fR" 4
  .IX Item "-gtoggle"
  Turn off generation of debug info, if leaving out this option
  generates it, or turn it on at level 2 otherwise.  The position of this
--- 19150,19156 ----
  When this option is passed to the compiler driver, it causes the
  \&\fIfirst\fR compilation to be skipped, which makes it useful for little
  other than debugging the compiler proper.
! .IP \fB\-gtoggle\fR 4
  .IX Item "-gtoggle"
  Turn off generation of debug info, if leaving out this option
  generates it, or turn it on at level 2 otherwise.  The position of this
*************** argument in the command line does not ma
*** 19227,19289 ****
  other options are processed, and it does so only once, no matter how
  many times it is given.  This is mainly intended to be used with
  \&\fB\-fcompare\-debug\fR.
! .IP "\fB\-fvar\-tracking\-assignments\-toggle\fR" 4
  .IX Item "-fvar-tracking-assignments-toggle"
  Toggle \fB\-fvar\-tracking\-assignments\fR, in the same way that
  \&\fB\-gtoggle\fR toggles \fB\-g\fR.
! .IP "\fB\-Q\fR" 4
  .IX Item "-Q"
  Makes the compiler print out each function name as it is compiled, and
  print some statistics about each pass when it finishes.
! .IP "\fB\-ftime\-report\fR" 4
  .IX Item "-ftime-report"
  Makes the compiler print some statistics about the time consumed by each
  pass when it finishes.
! .IP "\fB\-ftime\-report\-details\fR" 4
  .IX Item "-ftime-report-details"
  Record the time consumed by infrastructure parts separately for each pass.
! .IP "\fB\-fira\-verbose=\fR\fIn\fR" 4
  .IX Item "-fira-verbose=n"
  Control the verbosity of the dump file for the integrated register allocator.
  The default value is 5.  If the value \fIn\fR is greater or equal to 10,
  the dump output is sent to stderr using the same format as \fIn\fR minus 10.
! .IP "\fB\-flto\-report\fR" 4
  .IX Item "-flto-report"
! Prints a report with internal details on the workings of the link-time
  optimizer.  The contents of this report vary from version to version.
! It is meant to be useful to \s-1GCC\s0 developers when processing object
! files in \s-1LTO\s0 mode (via \fB\-flto\fR).
  .Sp
  Disabled by default.
! .IP "\fB\-flto\-report\-wpa\fR" 4
  .IX Item "-flto-report-wpa"
! Like \fB\-flto\-report\fR, but only print for the \s-1WPA\s0 phase of link-time
  optimization.
! .IP "\fB\-fmem\-report\fR" 4
  .IX Item "-fmem-report"
  Makes the compiler print some statistics about permanent memory
  allocation when it finishes.
! .IP "\fB\-fmem\-report\-wpa\fR" 4
  .IX Item "-fmem-report-wpa"
  Makes the compiler print some statistics about permanent memory
! allocation for the \s-1WPA\s0 phase only.
! .IP "\fB\-fpre\-ipa\-mem\-report\fR" 4
  .IX Item "-fpre-ipa-mem-report"
  .PD 0
! .IP "\fB\-fpost\-ipa\-mem\-report\fR" 4
  .IX Item "-fpost-ipa-mem-report"
  .PD
  Makes the compiler print some statistics about permanent memory
  allocation before or after interprocedural optimization.
! .IP "\fB\-fmultiflags\fR" 4
  .IX Item "-fmultiflags"
! This option enables multilib-aware \f(CW\*(C`TFLAGS\*(C'\fR to be used to build
  target libraries with options different from those the compiler is
  configured to use by default, through the use of specs
  .Sp
  Like \f(CW\*(C`TFLAGS\*(C'\fR, this allows the target libraries to be built for
  portable baseline environments, while the compiler defaults to more
! demanding ones.  That's useful because users can easily override the
  defaults the compiler is configured to use to build their own programs,
  if the defaults are not ideal for their target environment, whereas
  rebuilding the runtime libraries is usually not as easy or desirable.
--- 19158,19220 ----
  other options are processed, and it does so only once, no matter how
  many times it is given.  This is mainly intended to be used with
  \&\fB\-fcompare\-debug\fR.
! .IP \fB\-fvar\-tracking\-assignments\-toggle\fR 4
  .IX Item "-fvar-tracking-assignments-toggle"
  Toggle \fB\-fvar\-tracking\-assignments\fR, in the same way that
  \&\fB\-gtoggle\fR toggles \fB\-g\fR.
! .IP \fB\-Q\fR 4
  .IX Item "-Q"
  Makes the compiler print out each function name as it is compiled, and
  print some statistics about each pass when it finishes.
! .IP \fB\-ftime\-report\fR 4
  .IX Item "-ftime-report"
  Makes the compiler print some statistics about the time consumed by each
  pass when it finishes.
! .IP \fB\-ftime\-report\-details\fR 4
  .IX Item "-ftime-report-details"
  Record the time consumed by infrastructure parts separately for each pass.
! .IP \fB\-fira\-verbose=\fR\fIn\fR 4
  .IX Item "-fira-verbose=n"
  Control the verbosity of the dump file for the integrated register allocator.
  The default value is 5.  If the value \fIn\fR is greater or equal to 10,
  the dump output is sent to stderr using the same format as \fIn\fR minus 10.
! .IP \fB\-flto\-report\fR 4
  .IX Item "-flto-report"
! Prints a report with internal details on the workings of the link\-time
  optimizer.  The contents of this report vary from version to version.
! It is meant to be useful to GCC developers when processing object
! files in LTO mode (via \fB\-flto\fR).
  .Sp
  Disabled by default.
! .IP \fB\-flto\-report\-wpa\fR 4
  .IX Item "-flto-report-wpa"
! Like \fB\-flto\-report\fR, but only print for the WPA phase of link\-time
  optimization.
! .IP \fB\-fmem\-report\fR 4
  .IX Item "-fmem-report"
  Makes the compiler print some statistics about permanent memory
  allocation when it finishes.
! .IP \fB\-fmem\-report\-wpa\fR 4
  .IX Item "-fmem-report-wpa"
  Makes the compiler print some statistics about permanent memory
! allocation for the WPA phase only.
! .IP \fB\-fpre\-ipa\-mem\-report\fR 4
  .IX Item "-fpre-ipa-mem-report"
  .PD 0
! .IP \fB\-fpost\-ipa\-mem\-report\fR 4
  .IX Item "-fpost-ipa-mem-report"
  .PD
  Makes the compiler print some statistics about permanent memory
  allocation before or after interprocedural optimization.
! .IP \fB\-fmultiflags\fR 4
  .IX Item "-fmultiflags"
! This option enables multilib\-aware \f(CW\*(C`TFLAGS\*(C'\fR to be used to build
  target libraries with options different from those the compiler is
  configured to use by default, through the use of specs
  .Sp
  Like \f(CW\*(C`TFLAGS\*(C'\fR, this allows the target libraries to be built for
  portable baseline environments, while the compiler defaults to more
! demanding ones.  That\*(Aqs useful because users can easily override the
  defaults the compiler is configured to use to build their own programs,
  if the defaults are not ideal for their target environment, whereas
  rebuilding the runtime libraries is usually not as easy or desirable.
*************** selected for different multilibs.  The w
*** 19293,19323 ****
  build with \fBmake TFLAGS=\-fmultiflags\fR, after configuring
  \&\fB\-\-with\-specs=%{fmultiflags:...}\fR.
  .Sp
! This option is discarded by the driver once it's done processing driver
  self spec.
  .Sp
  It is also useful to check that \f(CW\*(C`TFLAGS\*(C'\fR are being used to build
! all target libraries, by configuring a non-bootstrap compiler
! \&\fB\-\-with\-specs='%{!fmultiflags:%emissing \s-1TFLAGS\s0}'\fR and building
  the compiler and target libraries.
! .IP "\fB\-fprofile\-report\fR" 4
  .IX Item "-fprofile-report"
  Makes the compiler print some statistics about consistency of the
  (estimated) profile and effect of individual passes.
! .IP "\fB\-fstack\-usage\fR" 4
  .IX Item "-fstack-usage"
  Makes the compiler output stack usage information for the program, on a
! per-function basis.  The filename for the dump is made by appending
  \&\fI.su\fR to the \fIauxname\fR.  \fIauxname\fR is generated from the name of
  the output file, if explicitly specified and it is not an executable,
  otherwise it is the basename of the source file.  An entry is made up
  of three fields:
  .RS 4
! .IP "*" 4
  The name of the function.
! .IP "*" 4
  A number of bytes.
! .IP "*" 4
  One or more qualifiers: \f(CW\*(C`static\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR, \f(CW\*(C`bounded\*(C'\fR.
  .RE
  .RS 4
--- 19224,19254 ----
  build with \fBmake TFLAGS=\-fmultiflags\fR, after configuring
  \&\fB\-\-with\-specs=%{fmultiflags:...}\fR.
  .Sp
! This option is discarded by the driver once it\*(Aqs done processing driver
  self spec.
  .Sp
  It is also useful to check that \f(CW\*(C`TFLAGS\*(C'\fR are being used to build
! all target libraries, by configuring a non\-bootstrap compiler
! \&\fB\-\-with\-specs=\*(Aq%{!fmultiflags:%emissing TFLAGS}\*(Aq\fR and building
  the compiler and target libraries.
! .IP \fB\-fprofile\-report\fR 4
  .IX Item "-fprofile-report"
  Makes the compiler print some statistics about consistency of the
  (estimated) profile and effect of individual passes.
! .IP \fB\-fstack\-usage\fR 4
  .IX Item "-fstack-usage"
  Makes the compiler output stack usage information for the program, on a
! per\-function basis.  The filename for the dump is made by appending
  \&\fI.su\fR to the \fIauxname\fR.  \fIauxname\fR is generated from the name of
  the output file, if explicitly specified and it is not an executable,
  otherwise it is the basename of the source file.  An entry is made up
  of three fields:
  .RS 4
! .IP * 4
  The name of the function.
! .IP * 4
  A number of bytes.
! .IP * 4
  One or more qualifiers: \f(CW\*(C`static\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR, \f(CW\*(C`bounded\*(C'\fR.
  .RE
  .RS 4
*************** the function.  If it is not present, the
*** 19337,19397 ****
  not bounded at compile time and the second field only represents the
  bounded part.
  .RE
! .IP "\fB\-fstats\fR" 4
  .IX Item "-fstats"
! Emit statistics about front-end processing at the end of the compilation.
! This option is supported only by the \*(C+ front end, and
  the information is generally only useful to the G++ development team.
! .IP "\fB\-fdbg\-cnt\-list\fR" 4
  .IX Item "-fdbg-cnt-list"
  Print the name and the counter upper bound for all debug counters.
! .IP "\fB\-fdbg\-cnt=\fR\fIcounter-value-list\fR" 4
  .IX Item "-fdbg-cnt=counter-value-list"
! Set the internal debug counter lower and upper bound.  \fIcounter-value-list\fR
! is a comma-separated list of \fIname\fR:\fIlower_bound1\fR\-\fIupper_bound1\fR
  [:\fIlower_bound2\fR\-\fIupper_bound2\fR...] tuples which sets
  the name of the counter and list of closed intervals.
  The \fIlower_bound\fR is optional and is zero
  initialized if not set.
  For example, with \fB\-fdbg\-cnt=dce:2\-4:10\-11,tail_call:10\fR,
! \&\f(CW\*(C`dbg_cnt(dce)\*(C'\fR returns true only for second, third, fourth, tenth and
  eleventh invocation.
! For \f(CW\*(C`dbg_cnt(tail_call)\*(C'\fR true is returned for first 10 invocations.
! .IP "\fB\-print\-file\-name=\fR\fIlibrary\fR" 4
  .IX Item "-print-file-name=library"
  Print the full absolute name of the library file \fIlibrary\fR that
! would be used when linking\-\-\-and don't do anything else.  With this
! option, \s-1GCC\s0 does not compile or link anything; it just prints the
  file name.
! .IP "\fB\-print\-multi\-directory\fR" 4
  .IX Item "-print-multi-directory"
  Print the directory name corresponding to the multilib selected by any
  other switches present in the command line.  This directory is supposed
! to exist in \fB\s-1GCC_EXEC_PREFIX\s0\fR.
! .IP "\fB\-print\-multi\-lib\fR" 4
  .IX Item "-print-multi-lib"
  Print the mapping from multilib directory names to compiler switches
  that enable them.  The directory name is separated from the switches by
  \&\fB;\fR, and each switch starts with an \fB@\fR instead of the
  \&\fB\-\fR, without spaces between multiple switches.  This is supposed to
  ease shell processing.
! .IP "\fB\-print\-multi\-os\-directory\fR" 4
  .IX Item "-print-multi-os-directory"
! Print the path to \s-1OS\s0 libraries for the selected
! multilib, relative to some \fIlib\fR subdirectory.  If \s-1OS\s0 libraries are
  present in the \fIlib\fR subdirectory and no multilibs are used, this is
! usually just \fI.\fR, if \s-1OS\s0 libraries are present in \fIlib\fIsuffix\fI\fR
  sibling directories this prints e.g. \fI../lib64\fR, \fI../lib\fR or
! \&\fI../lib32\fR, or if \s-1OS\s0 libraries are present in \fIlib/\fIsubdir\fI\fR
  subdirectories it prints e.g. \fIamd64\fR, \fIsparcv9\fR or \fIev6\fR.
! .IP "\fB\-print\-multiarch\fR" 4
  .IX Item "-print-multiarch"
! Print the path to \s-1OS\s0 libraries for the selected multiarch,
  relative to some \fIlib\fR subdirectory.
! .IP "\fB\-print\-prog\-name=\fR\fIprogram\fR" 4
  .IX Item "-print-prog-name=program"
  Like \fB\-print\-file\-name\fR, but searches for a program such as \fBcpp\fR.
! .IP "\fB\-print\-libgcc\-file\-name\fR" 4
  .IX Item "-print-libgcc-file-name"
  Same as \fB\-print\-file\-name=libgcc.a\fR.
  .Sp
--- 19268,19328 ----
  not bounded at compile time and the second field only represents the
  bounded part.
  .RE
! .IP \fB\-fstats\fR 4
  .IX Item "-fstats"
! Emit statistics about front\-end processing at the end of the compilation.
! This option is supported only by the C++ front end, and
  the information is generally only useful to the G++ development team.
! .IP \fB\-fdbg\-cnt\-list\fR 4
  .IX Item "-fdbg-cnt-list"
  Print the name and the counter upper bound for all debug counters.
! .IP \fB\-fdbg\-cnt=\fR\fIcounter\-value\-list\fR 4
  .IX Item "-fdbg-cnt=counter-value-list"
! Set the internal debug counter lower and upper bound.  \fIcounter\-value\-list\fR
! is a comma\-separated list of \fIname\fR:\fIlower_bound1\fR\-\fIupper_bound1\fR
  [:\fIlower_bound2\fR\-\fIupper_bound2\fR...] tuples which sets
  the name of the counter and list of closed intervals.
  The \fIlower_bound\fR is optional and is zero
  initialized if not set.
  For example, with \fB\-fdbg\-cnt=dce:2\-4:10\-11,tail_call:10\fR,
! \&\f(CWdbg_cnt(dce)\fR returns true only for second, third, fourth, tenth and
  eleventh invocation.
! For \f(CWdbg_cnt(tail_call)\fR true is returned for first 10 invocations.
! .IP \fB\-print\-file\-name=\fR\fIlibrary\fR 4
  .IX Item "-print-file-name=library"
  Print the full absolute name of the library file \fIlibrary\fR that
! would be used when linking\-\-\-and don\*(Aqt do anything else.  With this
! option, GCC does not compile or link anything; it just prints the
  file name.
! .IP \fB\-print\-multi\-directory\fR 4
  .IX Item "-print-multi-directory"
  Print the directory name corresponding to the multilib selected by any
  other switches present in the command line.  This directory is supposed
! to exist in \fBGCC_EXEC_PREFIX\fR.
! .IP \fB\-print\-multi\-lib\fR 4
  .IX Item "-print-multi-lib"
  Print the mapping from multilib directory names to compiler switches
  that enable them.  The directory name is separated from the switches by
  \&\fB;\fR, and each switch starts with an \fB@\fR instead of the
  \&\fB\-\fR, without spaces between multiple switches.  This is supposed to
  ease shell processing.
! .IP \fB\-print\-multi\-os\-directory\fR 4
  .IX Item "-print-multi-os-directory"
! Print the path to OS libraries for the selected
! multilib, relative to some \fIlib\fR subdirectory.  If OS libraries are
  present in the \fIlib\fR subdirectory and no multilibs are used, this is
! usually just \fI.\fR, if OS libraries are present in \fIlibsuffix\fR
  sibling directories this prints e.g. \fI../lib64\fR, \fI../lib\fR or
! \&\fI../lib32\fR, or if OS libraries are present in \fIlib/subdir\fR
  subdirectories it prints e.g. \fIamd64\fR, \fIsparcv9\fR or \fIev6\fR.
! .IP \fB\-print\-multiarch\fR 4
  .IX Item "-print-multiarch"
! Print the path to OS libraries for the selected multiarch,
  relative to some \fIlib\fR subdirectory.
! .IP \fB\-print\-prog\-name=\fR\fIprogram\fR 4
  .IX Item "-print-prog-name=program"
  Like \fB\-print\-file\-name\fR, but searches for a program such as \fBcpp\fR.
! .IP \fB\-print\-libgcc\-file\-name\fR 4
  .IX Item "-print-libgcc-file-name"
  Same as \fB\-print\-file\-name=libgcc.a\fR.
  .Sp
*************** but you do want to link with \fIlibgcc.a
*** 19401,19458 ****
  .Vb 1
  \&        gcc \-nostdlib ... \`gcc \-print\-libgcc\-file\-name\`
  .Ve
! .IP "\fB\-print\-search\-dirs\fR" 4
  .IX Item "-print-search-dirs"
  Print the name of the configured installation directory and a list of
! program and library directories \fBgcc\fR searches\-\-\-and don't do anything else.
  .Sp
  This is useful when \fBgcc\fR prints the error message
  \&\fBinstallation problem, cannot exec cpp0: No such file or directory\fR.
  To resolve this you either need to put \fIcpp0\fR and the other compiler
  components where \fBgcc\fR expects to find them, or you can set the environment
! variable \fB\s-1GCC_EXEC_PREFIX\s0\fR to the directory where you installed them.
! Don't forget the trailing \fB/\fR.
! .IP "\fB\-print\-sysroot\fR" 4
  .IX Item "-print-sysroot"
  Print the target sysroot directory that is used during
  compilation.  This is the target sysroot specified either at configure
  time or using the \fB\-\-sysroot\fR option, possibly with an extra
  suffix that depends on compilation options.  If no target sysroot is
  specified, the option prints nothing.
! .IP "\fB\-print\-sysroot\-headers\-suffix\fR" 4
  .IX Item "-print-sysroot-headers-suffix"
  Print the suffix added to the target sysroot when searching for
  headers, or give an error if the compiler is not configured with such
! a suffix\-\-\-and don't do anything else.
! .IP "\fB\-dumpmachine\fR" 4
  .IX Item "-dumpmachine"
! Print the compiler's target machine (for example,
! \&\fBi686\-pc\-linux\-gnu\fR)\-\-\-and don't do anything else.
! .IP "\fB\-dumpversion\fR" 4
  .IX Item "-dumpversion"
! Print the compiler version (for example, \f(CW3.0\fR, \f(CW6.3.0\fR or \f(CW7\fR)\-\-\-and don't do
  anything else.  This is the compiler version used in filesystem paths and
  specs. Depending on how the compiler has been configured it can be just
  a single number (major version), two numbers separated by a dot (major and
  minor version) or three numbers separated by dots (major, minor and patchlevel
  version).
! .IP "\fB\-dumpfullversion\fR" 4
  .IX Item "-dumpfullversion"
! Print the full compiler version\-\-\-and don't do anything else. The output is
  always three numbers separated by dots, major, minor and patchlevel version.
! .IP "\fB\-dumpspecs\fR" 4
  .IX Item "-dumpspecs"
! Print the compiler's built-in specs\-\-\-and don't do anything else.  (This
! is used when \s-1GCC\s0 itself is being built.)
! .SS "Machine-Dependent Options"
  .IX Subsection "Machine-Dependent Options"
! Each target machine supported by \s-1GCC\s0 can have its own options\-\-\-for
  example, to allow you to compile for a particular processor variant or
! \&\s-1ABI,\s0 or to control optimizations specific to that machine.  By
! convention, the names of machine-specific options start with
  \&\fB\-m\fR.
  .PP
! Some configurations of the compiler also support additional target-specific
  options, usually for compatibility with other compilers on the same
  platform.
  .PP
--- 19332,19389 ----
  .Vb 1
  \&        gcc \-nostdlib ... \`gcc \-print\-libgcc\-file\-name\`
  .Ve
! .IP \fB\-print\-search\-dirs\fR 4
  .IX Item "-print-search-dirs"
  Print the name of the configured installation directory and a list of
! program and library directories \fBgcc\fR searches\-\-\-and don\*(Aqt do anything else.
  .Sp
  This is useful when \fBgcc\fR prints the error message
  \&\fBinstallation problem, cannot exec cpp0: No such file or directory\fR.
  To resolve this you either need to put \fIcpp0\fR and the other compiler
  components where \fBgcc\fR expects to find them, or you can set the environment
! variable \fBGCC_EXEC_PREFIX\fR to the directory where you installed them.
! Don\*(Aqt forget the trailing \fB/\fR.
! .IP \fB\-print\-sysroot\fR 4
  .IX Item "-print-sysroot"
  Print the target sysroot directory that is used during
  compilation.  This is the target sysroot specified either at configure
  time or using the \fB\-\-sysroot\fR option, possibly with an extra
  suffix that depends on compilation options.  If no target sysroot is
  specified, the option prints nothing.
! .IP \fB\-print\-sysroot\-headers\-suffix\fR 4
  .IX Item "-print-sysroot-headers-suffix"
  Print the suffix added to the target sysroot when searching for
  headers, or give an error if the compiler is not configured with such
! a suffix\-\-\-and don\*(Aqt do anything else.
! .IP \fB\-dumpmachine\fR 4
  .IX Item "-dumpmachine"
! Print the compiler\*(Aqs target machine (for example,
! \&\fBi686\-pc\-linux\-gnu\fR)\-\-\-and don\*(Aqt do anything else.
! .IP \fB\-dumpversion\fR 4
  .IX Item "-dumpversion"
! Print the compiler version (for example, \f(CW3.0\fR, \f(CW6.3.0\fR or \f(CW7\fR)\-\-\-and don\*(Aqt do
  anything else.  This is the compiler version used in filesystem paths and
  specs. Depending on how the compiler has been configured it can be just
  a single number (major version), two numbers separated by a dot (major and
  minor version) or three numbers separated by dots (major, minor and patchlevel
  version).
! .IP \fB\-dumpfullversion\fR 4
  .IX Item "-dumpfullversion"
! Print the full compiler version\-\-\-and don\*(Aqt do anything else. The output is
  always three numbers separated by dots, major, minor and patchlevel version.
! .IP \fB\-dumpspecs\fR 4
  .IX Item "-dumpspecs"
! Print the compiler\*(Aqs built\-in specs\-\-\-and don\*(Aqt do anything else.  (This
! is used when GCC itself is being built.)
! .SS "Machine\-Dependent Options"
  .IX Subsection "Machine-Dependent Options"
! Each target machine supported by GCC can have its own options\-\-\-for
  example, to allow you to compile for a particular processor variant or
! ABI, or to control optimizations specific to that machine.  By
! convention, the names of machine\-specific options start with
  \&\fB\-m\fR.
  .PP
! Some configurations of the compiler also support additional target\-specific
  options, usually for compatibility with other compilers on the same
  platform.
  .PP
*************** platform.
*** 19460,19526 ****
  .IX Subsection "AArch64 Options"
  .PP
  These options are defined for AArch64 implementations:
! .IP "\fB\-mabi=\fR\fIname\fR" 4
  .IX Item "-mabi=name"
  Generate code for the specified data model.  Permissible values
! are \fBilp32\fR for SysV-like data model where int, long int and pointers
! are 32 bits, and \fBlp64\fR for SysV-like data model where int is 32 bits,
  but long int and pointers are 64 bits.
  .Sp
  The default depends on the specific target configuration.  Note that
! the \s-1LP64\s0 and \s-1ILP32\s0 ABIs are not link-compatible; you must compile your
! entire program with the same \s-1ABI,\s0 and link with a compatible set of libraries.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate big-endian code.  This is the default when \s-1GCC\s0 is configured for an
  \&\fBaarch64_be\-*\-*\fR target.
! .IP "\fB\-mgeneral\-regs\-only\fR" 4
  .IX Item "-mgeneral-regs-only"
! Generate code which uses only the general-purpose registers.  This will prevent
! the compiler from using floating-point and Advanced \s-1SIMD\s0 registers but will not
  impose any restrictions on the assembler.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate little-endian code.  This is the default when \s-1GCC\s0 is configured for an
  \&\fBaarch64\-*\-*\fR but not an \fBaarch64_be\-*\-*\fR target.
! .IP "\fB\-mcmodel=tiny\fR" 4
  .IX Item "-mcmodel=tiny"
  Generate code for the tiny code model.  The program and its statically defined
  symbols must be within 1MB of each other.  Programs can be statically or
  dynamically linked.
! .IP "\fB\-mcmodel=small\fR" 4
  .IX Item "-mcmodel=small"
  Generate code for the small code model.  The program and its statically defined
  symbols must be within 4GB of each other.  Programs can be statically or
  dynamically linked.  This is the default code model.
! .IP "\fB\-mcmodel=large\fR" 4
  .IX Item "-mcmodel=large"
  Generate code for the large code model.  This makes no assumptions about
  addresses and sizes of sections.  Programs can be statically linked only.  The
  \&\fB\-mcmodel=large\fR option is incompatible with \fB\-mabi=ilp32\fR,
  \&\fB\-fpic\fR and \fB\-fPIC\fR.
! .IP "\fB\-mstrict\-align\fR" 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP "\fB\-mno\-strict\-align\fR" 4
  .IX Item "-mno-strict-align"
  .PD
  Avoid or allow generating memory accesses that may not be aligned on a natural
  object boundary as described in the architecture specification.
! .IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
  .IX Item "-momit-leaf-frame-pointer"
  .PD 0
! .IP "\fB\-mno\-omit\-leaf\-frame\-pointer\fR" 4
  .IX Item "-mno-omit-leaf-frame-pointer"
  .PD
  Omit or keep the frame pointer in leaf functions.  The former behavior is the
  default.
! .IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP "\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR" 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP "\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR" 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
--- 19391,19457 ----
  .IX Subsection "AArch64 Options"
  .PP
  These options are defined for AArch64 implementations:
! .IP \fB\-mabi=\fR\fIname\fR 4
  .IX Item "-mabi=name"
  Generate code for the specified data model.  Permissible values
! are \fBilp32\fR for SysV\-like data model where int, long int and pointers
! are 32 bits, and \fBlp64\fR for SysV\-like data model where int is 32 bits,
  but long int and pointers are 64 bits.
  .Sp
  The default depends on the specific target configuration.  Note that
! the LP64 and ILP32 ABIs are not link\-compatible; you must compile your
! entire program with the same ABI, and link with a compatible set of libraries.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate big\-endian code.  This is the default when GCC is configured for an
  \&\fBaarch64_be\-*\-*\fR target.
! .IP \fB\-mgeneral\-regs\-only\fR 4
  .IX Item "-mgeneral-regs-only"
! Generate code which uses only the general\-purpose registers.  This will prevent
! the compiler from using floating\-point and Advanced SIMD registers but will not
  impose any restrictions on the assembler.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate little\-endian code.  This is the default when GCC is configured for an
  \&\fBaarch64\-*\-*\fR but not an \fBaarch64_be\-*\-*\fR target.
! .IP \fB\-mcmodel=tiny\fR 4
  .IX Item "-mcmodel=tiny"
  Generate code for the tiny code model.  The program and its statically defined
  symbols must be within 1MB of each other.  Programs can be statically or
  dynamically linked.
! .IP \fB\-mcmodel=small\fR 4
  .IX Item "-mcmodel=small"
  Generate code for the small code model.  The program and its statically defined
  symbols must be within 4GB of each other.  Programs can be statically or
  dynamically linked.  This is the default code model.
! .IP \fB\-mcmodel=large\fR 4
  .IX Item "-mcmodel=large"
  Generate code for the large code model.  This makes no assumptions about
  addresses and sizes of sections.  Programs can be statically linked only.  The
  \&\fB\-mcmodel=large\fR option is incompatible with \fB\-mabi=ilp32\fR,
  \&\fB\-fpic\fR and \fB\-fPIC\fR.
! .IP \fB\-mstrict\-align\fR 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP \fB\-mno\-strict\-align\fR 4
  .IX Item "-mno-strict-align"
  .PD
  Avoid or allow generating memory accesses that may not be aligned on a natural
  object boundary as described in the architecture specification.
! .IP \fB\-momit\-leaf\-frame\-pointer\fR 4
  .IX Item "-momit-leaf-frame-pointer"
  .PD 0
! .IP \fB\-mno\-omit\-leaf\-frame\-pointer\fR 4
  .IX Item "-mno-omit-leaf-frame-pointer"
  .PD
  Omit or keep the frame pointer in leaf functions.  The former behavior is the
  default.
! .IP \fB\-mstack\-protector\-guard=\fR\fIguard\fR 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP \fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
*************** which system register to use as base reg
*** 19534,19573 ****
  and from what offset from that base register. There is no default
  register or offset as this is entirely for use within the Linux
  kernel.
! .IP "\fB\-mtls\-dialect=desc\fR" 4
  .IX Item "-mtls-dialect=desc"
! Use \s-1TLS\s0 descriptors as the thread-local storage mechanism for dynamic accesses
! of \s-1TLS\s0 variables.  This is the default.
! .IP "\fB\-mtls\-dialect=traditional\fR" 4
  .IX Item "-mtls-dialect=traditional"
! Use traditional \s-1TLS\s0 as the thread-local storage mechanism for dynamic accesses
! of \s-1TLS\s0 variables.
! .IP "\fB\-mtls\-size=\fR\fIsize\fR" 4
  .IX Item "-mtls-size=size"
! Specify bit size of immediate \s-1TLS\s0 offsets.  Valid values are 12, 24, 32, 48.
  This option requires binutils 2.26 or newer.
! .IP "\fB\-mfix\-cortex\-a53\-835769\fR" 4
  .IX Item "-mfix-cortex-a53-835769"
  .PD 0
! .IP "\fB\-mno\-fix\-cortex\-a53\-835769\fR" 4
  .IX Item "-mno-fix-cortex-a53-835769"
  .PD
! Enable or disable the workaround for the \s-1ARM\s0 Cortex\-A53 erratum number 835769.
! This involves inserting a \s-1NOP\s0 instruction between memory instructions and
! 64\-bit integer multiply-accumulate instructions.
! .IP "\fB\-mfix\-cortex\-a53\-843419\fR" 4
  .IX Item "-mfix-cortex-a53-843419"
  .PD 0
! .IP "\fB\-mno\-fix\-cortex\-a53\-843419\fR" 4
  .IX Item "-mno-fix-cortex-a53-843419"
  .PD
! Enable or disable the workaround for the \s-1ARM\s0 Cortex\-A53 erratum number 843419.
  This erratum workaround is made at link time and this will only pass the
  corresponding flag to the linker.
! .IP "\fB\-mlow\-precision\-recip\-sqrt\fR" 4
  .IX Item "-mlow-precision-recip-sqrt"
  .PD 0
! .IP "\fB\-mno\-low\-precision\-recip\-sqrt\fR" 4
  .IX Item "-mno-low-precision-recip-sqrt"
  .PD
  Enable or disable the reciprocal square root approximation.
--- 19465,19504 ----
  and from what offset from that base register. There is no default
  register or offset as this is entirely for use within the Linux
  kernel.
! .IP \fB\-mtls\-dialect=desc\fR 4
  .IX Item "-mtls-dialect=desc"
! Use TLS descriptors as the thread\-local storage mechanism for dynamic accesses
! of TLS variables.  This is the default.
! .IP \fB\-mtls\-dialect=traditional\fR 4
  .IX Item "-mtls-dialect=traditional"
! Use traditional TLS as the thread\-local storage mechanism for dynamic accesses
! of TLS variables.
! .IP \fB\-mtls\-size=\fR\fIsize\fR 4
  .IX Item "-mtls-size=size"
! Specify bit size of immediate TLS offsets.  Valid values are 12, 24, 32, 48.
  This option requires binutils 2.26 or newer.
! .IP \fB\-mfix\-cortex\-a53\-835769\fR 4
  .IX Item "-mfix-cortex-a53-835769"
  .PD 0
! .IP \fB\-mno\-fix\-cortex\-a53\-835769\fR 4
  .IX Item "-mno-fix-cortex-a53-835769"
  .PD
! Enable or disable the workaround for the ARM Cortex\-A53 erratum number 835769.
! This involves inserting a NOP instruction between memory instructions and
! 64\-bit integer multiply\-accumulate instructions.
! .IP \fB\-mfix\-cortex\-a53\-843419\fR 4
  .IX Item "-mfix-cortex-a53-843419"
  .PD 0
! .IP \fB\-mno\-fix\-cortex\-a53\-843419\fR 4
  .IX Item "-mno-fix-cortex-a53-843419"
  .PD
! Enable or disable the workaround for the ARM Cortex\-A53 erratum number 843419.
  This erratum workaround is made at link time and this will only pass the
  corresponding flag to the linker.
! .IP \fB\-mlow\-precision\-recip\-sqrt\fR 4
  .IX Item "-mlow-precision-recip-sqrt"
  .PD 0
! .IP \fB\-mno\-low\-precision\-recip\-sqrt\fR 4
  .IX Item "-mno-low-precision-recip-sqrt"
  .PD
  Enable or disable the reciprocal square root approximation.
*************** This option only has an effect if \fB\-f
*** 19575,19584 ****
  \&\fB\-funsafe\-math\-optimizations\fR is used as well.  Enabling this reduces
  precision of reciprocal square root results to about 16 bits for
  single precision and to 32 bits for double precision.
! .IP "\fB\-mlow\-precision\-sqrt\fR" 4
  .IX Item "-mlow-precision-sqrt"
  .PD 0
! .IP "\fB\-mno\-low\-precision\-sqrt\fR" 4
  .IX Item "-mno-low-precision-sqrt"
  .PD
  Enable or disable the square root approximation.
--- 19506,19515 ----
  \&\fB\-funsafe\-math\-optimizations\fR is used as well.  Enabling this reduces
  precision of reciprocal square root results to about 16 bits for
  single precision and to 32 bits for double precision.
! .IP \fB\-mlow\-precision\-sqrt\fR 4
  .IX Item "-mlow-precision-sqrt"
  .PD 0
! .IP \fB\-mno\-low\-precision\-sqrt\fR 4
  .IX Item "-mno-low-precision-sqrt"
  .PD
  Enable or disable the square root approximation.
*************** This option only has an effect if \fB\-f
*** 19587,19596 ****
  precision of square root results to about 16 bits for
  single precision and to 32 bits for double precision.
  If enabled, it implies \fB\-mlow\-precision\-recip\-sqrt\fR.
! .IP "\fB\-mlow\-precision\-div\fR" 4
  .IX Item "-mlow-precision-div"
  .PD 0
! .IP "\fB\-mno\-low\-precision\-div\fR" 4
  .IX Item "-mno-low-precision-div"
  .PD
  Enable or disable the division approximation.
--- 19518,19527 ----
  precision of square root results to about 16 bits for
  single precision and to 32 bits for double precision.
  If enabled, it implies \fB\-mlow\-precision\-recip\-sqrt\fR.
! .IP \fB\-mlow\-precision\-div\fR 4
  .IX Item "-mlow-precision-div"
  .PD 0
! .IP \fB\-mno\-low\-precision\-div\fR 4
  .IX Item "-mno-low-precision-div"
  .PD
  Enable or disable the division approximation.
*************** This option only has an effect if \fB\-f
*** 19598,19607 ****
  \&\fB\-funsafe\-math\-optimizations\fR is used as well.  Enabling this reduces
  precision of division results to about 16 bits for
  single precision and to 32 bits for double precision.
! .IP "\fB\-mtrack\-speculation\fR" 4
  .IX Item "-mtrack-speculation"
  .PD 0
! .IP "\fB\-mno\-track\-speculation\fR" 4
  .IX Item "-mno-track-speculation"
  .PD
  Enable or disable generation of additional code to track speculative
--- 19529,19538 ----
  \&\fB\-funsafe\-math\-optimizations\fR is used as well.  Enabling this reduces
  precision of division results to about 16 bits for
  single precision and to 32 bits for double precision.
! .IP \fB\-mtrack\-speculation\fR 4
  .IX Item "-mtrack-speculation"
  .PD 0
! .IP \fB\-mno\-track\-speculation\fR 4
  .IX Item "-mno-track-speculation"
  .PD
  Enable or disable generation of additional code to track speculative
*************** execution through conditional branches.
*** 19609,19624 ****
  be used by the compiler when expanding calls to
  \&\f(CW\*(C`_\|_builtin_speculation_safe_copy\*(C'\fR to permit a more efficient code
  sequence to be generated.
! .IP "\fB\-moutline\-atomics\fR" 4
  .IX Item "-moutline-atomics"
  .PD 0
! .IP "\fB\-mno\-outline\-atomics\fR" 4
  .IX Item "-mno-outline-atomics"
  .PD
! Enable or disable calls to out-of-line helpers to implement atomic operations.
! These helpers will, at runtime, determine if the \s-1LSE\s0 instructions from
  ARMv8.1\-A can be used; if not, they will use the load/store\-exclusive
! instructions that are present in the base ARMv8.0 \s-1ISA.\s0
  .Sp
  This option is only applicable when compiling for the base ARMv8.0
  instruction set.  If using a later revision, e.g. \fB\-march=armv8.1\-a\fR
--- 19540,19555 ----
  be used by the compiler when expanding calls to
  \&\f(CW\*(C`_\|_builtin_speculation_safe_copy\*(C'\fR to permit a more efficient code
  sequence to be generated.
! .IP \fB\-moutline\-atomics\fR 4
  .IX Item "-moutline-atomics"
  .PD 0
! .IP \fB\-mno\-outline\-atomics\fR 4
  .IX Item "-mno-outline-atomics"
  .PD
! Enable or disable calls to out\-of\-line helpers to implement atomic operations.
! These helpers will, at runtime, determine if the LSE instructions from
  ARMv8.1\-A can be used; if not, they will use the load/store\-exclusive
! instructions that are present in the base ARMv8.0 ISA.
  .Sp
  This option is only applicable when compiling for the base ARMv8.0
  instruction set.  If using a later revision, e.g. \fB\-march=armv8.1\-a\fR
*************** or \fB\-march=armv8\-a+lse\fR, the ARMv8
*** 19626,19632 ****
  used directly.  The same applies when using \fB\-mcpu=\fR when the
  selected cpu supports the \fBlse\fR feature.
  This option is on by default.
! .IP "\fB\-march=\fR\fIname\fR" 4
  .IX Item "-march=name"
  Specify the name of the target architecture and, optionally, one or
  more feature modifiers.  This option has the form
--- 19557,19563 ----
  used directly.  The same applies when using \fB\-mcpu=\fR when the
  selected cpu supports the \fBlse\fR feature.
  This option is on by default.
! .IP \fB\-march=\fR\fIname\fR 4
  .IX Item "-march=name"
  Specify the name of the target architecture and, optionally, one or
  more feature modifiers.  This option has the form
*************** and the features that they enable by def
*** 19666,19694 ****
  .IX Item "armv9.3-a : Armv9.3-A : armv9.2-a, +mops"
  .IP "\fBarmv8\-r\fR : Armv8\-R : \fBarmv8\-r\fR" 4
  .IX Item "armv8-r : Armv8-R : armv8-r"
  .RE
  .RS 4
- .PD
  .Sp
  The value \fBnative\fR is available on native AArch64 GNU/Linux and
  causes the compiler to pick the architecture of the host system.  This
  option has no effect if the compiler is unable to recognize the
  architecture of the host system,
  .Sp
! The permissible values for \fIfeature\fR are listed in the sub-section
  on \fBaarch64\-feature\-modifiers,,\fR\fB\-march\fR \fBand\fR \fB\-mcpu\fR
  \&\fBFeature Modifiers\fR.  Where conflicting feature modifiers are
! specified, the right-most feature is used.
  .Sp
! \&\s-1GCC\s0 uses \fIname\fR to determine what kind of instructions it can emit
  when generating assembly code.  If \fB\-march\fR is specified
  without either of \fB\-mtune\fR or \fB\-mcpu\fR also being
  specified, the code is tuned to perform well across a range of target
  processors implementing the target architecture.
  .RE
! .IP "\fB\-mtune=\fR\fIname\fR" 4
  .IX Item "-mtune=name"
! Specify the name of the target processor for which \s-1GCC\s0 should tune the
  performance of the code.  Permissible values for this option are:
  \&\fBgeneric\fR, \fBcortex\-a35\fR, \fBcortex\-a53\fR, \fBcortex\-a55\fR,
  \&\fBcortex\-a57\fR, \fBcortex\-a72\fR, \fBcortex\-a73\fR, \fBcortex\-a75\fR,
--- 19597,19625 ----
  .IX Item "armv9.3-a : Armv9.3-A : armv9.2-a, +mops"
  .IP "\fBarmv8\-r\fR : Armv8\-R : \fBarmv8\-r\fR" 4
  .IX Item "armv8-r : Armv8-R : armv8-r"
+ .PD
  .RE
  .RS 4
  .Sp
  The value \fBnative\fR is available on native AArch64 GNU/Linux and
  causes the compiler to pick the architecture of the host system.  This
  option has no effect if the compiler is unable to recognize the
  architecture of the host system,
  .Sp
! The permissible values for \fIfeature\fR are listed in the sub\-section
  on \fBaarch64\-feature\-modifiers,,\fR\fB\-march\fR \fBand\fR \fB\-mcpu\fR
  \&\fBFeature Modifiers\fR.  Where conflicting feature modifiers are
! specified, the right\-most feature is used.
  .Sp
! GCC uses \fIname\fR to determine what kind of instructions it can emit
  when generating assembly code.  If \fB\-march\fR is specified
  without either of \fB\-mtune\fR or \fB\-mcpu\fR also being
  specified, the code is tuned to perform well across a range of target
  processors implementing the target architecture.
  .RE
! .IP \fB\-mtune=\fR\fIname\fR 4
  .IX Item "-mtune=name"
! Specify the name of the target processor for which GCC should tune the
  performance of the code.  Permissible values for this option are:
  \&\fBgeneric\fR, \fBcortex\-a35\fR, \fBcortex\-a53\fR, \fBcortex\-a55\fR,
  \&\fBcortex\-a57\fR, \fBcortex\-a72\fR, \fBcortex\-a73\fR, \fBcortex\-a75\fR,
*************** performance of the code.  Permissible va
*** 19716,19730 ****
  .Sp
  The values \fBcortex\-a57.cortex\-a53\fR, \fBcortex\-a72.cortex\-a53\fR,
  \&\fBcortex\-a73.cortex\-a35\fR, \fBcortex\-a73.cortex\-a53\fR,
! \&\fBcortex\-a75.cortex\-a55\fR, \fBcortex\-a76.cortex\-a55\fR specify that \s-1GCC\s0
  should tune for a big.LITTLE system.
  .Sp
! The value \fBneoverse\-512tvb\fR specifies that \s-1GCC\s0 should tune
! for Neoverse cores that (a) implement \s-1SVE\s0 and (b) have a total vector
! bandwidth of 512 bits per cycle.  In other words, the option tells \s-1GCC\s0 to
! tune for Neoverse cores that can execute 4 128\-bit Advanced \s-1SIMD\s0 arithmetic
! instructions a cycle and that can execute an equivalent number of \s-1SVE\s0
! arithmetic instructions per cycle (2 for 256\-bit \s-1SVE, 4\s0 for 128\-bit \s-1SVE\s0).
  This is more general than tuning for a specific core like Neoverse V1
  but is more specific than the default tuning described below.
  .Sp
--- 19647,19661 ----
  .Sp
  The values \fBcortex\-a57.cortex\-a53\fR, \fBcortex\-a72.cortex\-a53\fR,
  \&\fBcortex\-a73.cortex\-a35\fR, \fBcortex\-a73.cortex\-a53\fR,
! \&\fBcortex\-a75.cortex\-a55\fR, \fBcortex\-a76.cortex\-a55\fR specify that GCC
  should tune for a big.LITTLE system.
  .Sp
! The value \fBneoverse\-512tvb\fR specifies that GCC should tune
! for Neoverse cores that (a) implement SVE and (b) have a total vector
! bandwidth of 512 bits per cycle.  In other words, the option tells GCC to
! tune for Neoverse cores that can execute 4 128\-bit Advanced SIMD arithmetic
! instructions a cycle and that can execute an equivalent number of SVE
! arithmetic instructions per cycle (2 for 256\-bit SVE, 4 for 128\-bit SVE).
  This is more general than tuning for a specific core like Neoverse V1
  but is more specific than the default tuning described below.
  .Sp
*************** are specified, the code is tuned to perf
*** 19737,19755 ****
  of target processors.
  .Sp
  This option cannot be suffixed by feature modifiers.
! .IP "\fB\-mcpu=\fR\fIname\fR" 4
  .IX Item "-mcpu=name"
  Specify the name of the target processor, optionally suffixed by one
  or more feature modifiers.  This option has the form
  \&\fB\-mcpu=\fR\fIcpu\fR{\fB+\fR[\fBno\fR]\fIfeature\fR}*, where
  the permissible values for \fIcpu\fR are the same as those available
  for \fB\-mtune\fR.  The permissible values for \fIfeature\fR are
! documented in the sub-section on
  \&\fBaarch64\-feature\-modifiers,,\fR\fB\-march\fR \fBand\fR \fB\-mcpu\fR
  \&\fBFeature Modifiers\fR.  Where conflicting feature modifiers are
! specified, the right-most feature is used.
  .Sp
! \&\s-1GCC\s0 uses \fIname\fR to determine what kind of instructions it can emit when
  generating assembly code (as if by \fB\-march\fR) and to determine
  the target processor for which to tune for performance (as if
  by \fB\-mtune\fR).  Where this option is used in conjunction
--- 19668,19686 ----
  of target processors.
  .Sp
  This option cannot be suffixed by feature modifiers.
! .IP \fB\-mcpu=\fR\fIname\fR 4
  .IX Item "-mcpu=name"
  Specify the name of the target processor, optionally suffixed by one
  or more feature modifiers.  This option has the form
  \&\fB\-mcpu=\fR\fIcpu\fR{\fB+\fR[\fBno\fR]\fIfeature\fR}*, where
  the permissible values for \fIcpu\fR are the same as those available
  for \fB\-mtune\fR.  The permissible values for \fIfeature\fR are
! documented in the sub\-section on
  \&\fBaarch64\-feature\-modifiers,,\fR\fB\-march\fR \fBand\fR \fB\-mcpu\fR
  \&\fBFeature Modifiers\fR.  Where conflicting feature modifiers are
! specified, the right\-most feature is used.
  .Sp
! GCC uses \fIname\fR to determine what kind of instructions it can emit when
  generating assembly code (as if by \fB\-march\fR) and to determine
  the target processor for which to tune for performance (as if
  by \fB\-mtune\fR).  Where this option is used in conjunction
*************** over the appropriate part of this option
*** 19758,19801 ****
  .Sp
  \&\fB\-mcpu=neoverse\-512tvb\fR is special in that it does not refer
  to a specific core, but instead refers to all Neoverse cores that
! (a) implement \s-1SVE\s0 and (b) have a total vector bandwidth of 512 bits
  a cycle.  Unless overridden by \fB\-march\fR,
  \&\fB\-mcpu=neoverse\-512tvb\fR generates code that can run on a
  Neoverse V1 core, since Neoverse V1 is the first Neoverse core with
  these properties.  Unless overridden by \fB\-mtune\fR,
  \&\fB\-mcpu=neoverse\-512tvb\fR tunes code in the same way as for
  \&\fB\-mtune=neoverse\-512tvb\fR.
! .IP "\fB\-moverride=\fR\fIstring\fR" 4
  .IX Item "-moverride=string"
! Override tuning decisions made by the back-end in response to a
  \&\fB\-mtune=\fR switch.  The syntax, semantics, and accepted values
  for \fIstring\fR in this option are not guaranteed to be consistent
  across releases.
  .Sp
! This option is only intended to be useful when developing \s-1GCC.\s0
! .IP "\fB\-mverbose\-cost\-dump\fR" 4
  .IX Item "-mverbose-cost-dump"
  Enable verbose cost model dumping in the debug dump files.  This option is
  provided for use in debugging the compiler.
! .IP "\fB\-mpc\-relative\-literal\-loads\fR" 4
  .IX Item "-mpc-relative-literal-loads"
  .PD 0
! .IP "\fB\-mno\-pc\-relative\-literal\-loads\fR" 4
  .IX Item "-mno-pc-relative-literal-loads"
  .PD
! Enable or disable PC-relative literal loads.  With this option literal pools are
  accessed using a single instruction and emitted after each function.  This
  limits the maximum size of functions to 1MB.  This is enabled by default for
  \&\fB\-mcmodel=tiny\fR.
! .IP "\fB\-msign\-return\-address=\fR\fIscope\fR" 4
  .IX Item "-msign-return-address=scope"
  Select the function scope on which return address signing will be applied.
  Permissible values are \fBnone\fR, which disables return address signing,
! \&\fBnon-leaf\fR, which enables pointer signing for functions which are not leaf
  functions, and \fBall\fR, which enables pointer signing for all functions.  The
  default value is \fBnone\fR. This option has been deprecated by
  \&\-mbranch\-protection.
! .IP "\fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR\fB+\fR\fIb\-key\fR\fB]|\fR\fIbti\fR" 4
  .IX Item "-mbranch-protection=none|standard|pac-ret[+leaf+b-key]|bti"
  Select the branch protection features to use.
  \&\fBnone\fR is the default and turns off all types of branch protection.
--- 19689,19732 ----
  .Sp
  \&\fB\-mcpu=neoverse\-512tvb\fR is special in that it does not refer
  to a specific core, but instead refers to all Neoverse cores that
! (a) implement SVE and (b) have a total vector bandwidth of 512 bits
  a cycle.  Unless overridden by \fB\-march\fR,
  \&\fB\-mcpu=neoverse\-512tvb\fR generates code that can run on a
  Neoverse V1 core, since Neoverse V1 is the first Neoverse core with
  these properties.  Unless overridden by \fB\-mtune\fR,
  \&\fB\-mcpu=neoverse\-512tvb\fR tunes code in the same way as for
  \&\fB\-mtune=neoverse\-512tvb\fR.
! .IP \fB\-moverride=\fR\fIstring\fR 4
  .IX Item "-moverride=string"
! Override tuning decisions made by the back\-end in response to a
  \&\fB\-mtune=\fR switch.  The syntax, semantics, and accepted values
  for \fIstring\fR in this option are not guaranteed to be consistent
  across releases.
  .Sp
! This option is only intended to be useful when developing GCC.
! .IP \fB\-mverbose\-cost\-dump\fR 4
  .IX Item "-mverbose-cost-dump"
  Enable verbose cost model dumping in the debug dump files.  This option is
  provided for use in debugging the compiler.
! .IP \fB\-mpc\-relative\-literal\-loads\fR 4
  .IX Item "-mpc-relative-literal-loads"
  .PD 0
! .IP \fB\-mno\-pc\-relative\-literal\-loads\fR 4
  .IX Item "-mno-pc-relative-literal-loads"
  .PD
! Enable or disable PC\-relative literal loads.  With this option literal pools are
  accessed using a single instruction and emitted after each function.  This
  limits the maximum size of functions to 1MB.  This is enabled by default for
  \&\fB\-mcmodel=tiny\fR.
! .IP \fB\-msign\-return\-address=\fR\fIscope\fR 4
  .IX Item "-msign-return-address=scope"
  Select the function scope on which return address signing will be applied.
  Permissible values are \fBnone\fR, which disables return address signing,
! \&\fBnon\-leaf\fR, which enables pointer signing for functions which are not leaf
  functions, and \fBall\fR, which enables pointer signing for all functions.  The
  default value is \fBnone\fR. This option has been deprecated by
  \&\-mbranch\-protection.
! .IP \fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR\fB+\fR\fIb\-key\fR\fB]|\fR\fIbti\fR 4
  .IX Item "-mbranch-protection=none|standard|pac-ret[+leaf+b-key]|bti"
  Select the branch protection features to use.
  \&\fBnone\fR is the default and turns off all types of branch protection.
*************** Select the branch protection features to
*** 19803,20003 ****
  has additional tuning options, then \fBstandard\fR sets it to its standard
  level.
  \&\fBpac\-ret[+\fR\fIleaf\fR\fB]\fR turns on return address signing to its standard
! level: signing functions that save the return address to memory (non-leaf
  functions will practically always do this) using the a\-key.  The optional
  argument \fBleaf\fR can be used to extend the signing to include leaf
  functions.  The optional argument \fBb\-key\fR can be used to sign the functions
  with the B\-key instead of the A\-key.
  \&\fBbti\fR turns on branch target identification mechanism.
! .IP "\fB\-mharden\-sls=\fR\fIopts\fR" 4
  .IX Item "-mharden-sls=opts"
! Enable compiler hardening against straight line speculation (\s-1SLS\s0).
! \&\fIopts\fR is a comma-separated list of the following options:
  .RS 4
! .IP "\fBretbr\fR" 4
  .IX Item "retbr"
  .PD 0
! .IP "\fBblr\fR" 4
  .IX Item "blr"
  .RE
  .RS 4
- .PD
  .Sp
! In addition, \fB\-mharden\-sls=all\fR enables all \s-1SLS\s0 hardening while
! \&\fB\-mharden\-sls=none\fR disables all \s-1SLS\s0 hardening.
  .RE
! .IP "\fB\-msve\-vector\-bits=\fR\fIbits\fR" 4
  .IX Item "-msve-vector-bits=bits"
! Specify the number of bits in an \s-1SVE\s0 vector register.  This option only has
! an effect when \s-1SVE\s0 is enabled.
  .Sp
! \&\s-1GCC\s0 supports two forms of \s-1SVE\s0 code generation: \*(L"vector-length
! agnostic\*(R" output that works with any size of vector register and
! \&\*(L"vector-length specific\*(R" output that allows \s-1GCC\s0 to make assumptions
  about the vector length when it is useful for optimization reasons.
  The possible values of \fBbits\fR are: \fBscalable\fR, \fB128\fR,
  \&\fB256\fR, \fB512\fR, \fB1024\fR and \fB2048\fR.
! Specifying \fBscalable\fR selects vector-length agnostic
! output.  At present \fB\-msve\-vector\-bits=128\fR also generates vector-length
! agnostic output for big-endian targets.  All other values generate
! vector-length specific code.  The behavior of these values may change
  in future releases and no value except \fBscalable\fR should be
  relied on for producing code that is portable across different
! hardware \s-1SVE\s0 vector lengths.
  .Sp
  The default is \fB\-msve\-vector\-bits=scalable\fR, which produces
! vector-length agnostic code.
  .PP
  \fB\-march\fR and \fB\-mcpu\fR Feature Modifiers
  .IX Subsection "-march and -mcpu Feature Modifiers"
  .PP
  Feature modifiers used with \fB\-march\fR and \fB\-mcpu\fR can be any of
  the following and their inverses \fBno\fR\fIfeature\fR:
! .IP "\fBcrc\fR" 4
  .IX Item "crc"
! Enable \s-1CRC\s0 extension.  This is on by default for
  \&\fB\-march=armv8.1\-a\fR.
! .IP "\fBcrypto\fR" 4
  .IX Item "crypto"
! Enable Crypto extension.  This also enables Advanced \s-1SIMD\s0 and floating-point
  instructions.
! .IP "\fBfp\fR" 4
  .IX Item "fp"
! Enable floating-point instructions.  This is on by default for all possible
  values for options \fB\-march\fR and \fB\-mcpu\fR.
! .IP "\fBsimd\fR" 4
  .IX Item "simd"
! Enable Advanced \s-1SIMD\s0 instructions.  This also enables floating-point
  instructions.  This is on by default for all possible values for options
  \&\fB\-march\fR and \fB\-mcpu\fR.
! .IP "\fBsve\fR" 4
  .IX Item "sve"
  Enable Scalable Vector Extension instructions.  This also enables Advanced
! \&\s-1SIMD\s0 and floating-point instructions.
! .IP "\fBlse\fR" 4
  .IX Item "lse"
  Enable Large System Extension instructions.  This is on by default for
  \&\fB\-march=armv8.1\-a\fR.
! .IP "\fBrdma\fR" 4
  .IX Item "rdma"
  Enable Round Double Multiply Accumulate instructions.  This is on by default
  for \fB\-march=armv8.1\-a\fR.
! .IP "\fBfp16\fR" 4
  .IX Item "fp16"
! Enable \s-1FP16\s0 extension.  This also enables floating-point instructions.
! .IP "\fBfp16fml\fR" 4
  .IX Item "fp16fml"
! Enable \s-1FP16\s0 fmla extension.  This also enables \s-1FP16\s0 extensions and
! floating-point instructions. This option is enabled by default for \fB\-march=armv8.4\-a\fR. Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP "\fBrcpc\fR" 4
  .IX Item "rcpc"
! Enable the RCpc extension.  This enables the use of the \s-1LDAPR\s0 instructions for
! load-acquire atomic semantics, and passes it on to the assembler, enabling
  inline asm statements to use instructions from the RCpc extension.
! .IP "\fBdotprod\fR" 4
  .IX Item "dotprod"
! Enable the Dot Product extension.  This also enables Advanced \s-1SIMD\s0 instructions.
! .IP "\fBaes\fR" 4
  .IX Item "aes"
  Enable the Armv8\-a aes and pmull crypto extension.  This also enables Advanced
! \&\s-1SIMD\s0 instructions.
! .IP "\fBsha2\fR" 4
  .IX Item "sha2"
! Enable the Armv8\-a sha2 crypto extension.  This also enables Advanced \s-1SIMD\s0 instructions.
! .IP "\fBsha3\fR" 4
  .IX Item "sha3"
! Enable the sha512 and sha3 crypto extension.  This also enables Advanced \s-1SIMD\s0
  instructions. Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP "\fBsm4\fR" 4
  .IX Item "sm4"
! Enable the sm3 and sm4 crypto extension.  This also enables Advanced \s-1SIMD\s0 instructions.
  Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP "\fBprofile\fR" 4
  .IX Item "profile"
  Enable the Statistical Profiling extension.  This option is only to enable the
  extension at the assembler level and does not affect code generation.
! .IP "\fBrng\fR" 4
  .IX Item "rng"
  Enable the Armv8.5\-a Random Number instructions.  This option is only to
  enable the extension at the assembler level and does not affect code
  generation.
! .IP "\fBmemtag\fR" 4
  .IX Item "memtag"
  Enable the Armv8.5\-a Memory Tagging Extensions.
  Use of this option with architectures prior to Armv8.5\-A is not supported.
! .IP "\fBsb\fR" 4
  .IX Item "sb"
  Enable the Armv8\-a Speculation Barrier instruction.  This option is only to
  enable the extension at the assembler level and does not affect code
  generation.  This option is enabled by default for \fB\-march=armv8.5\-a\fR.
! .IP "\fBssbs\fR" 4
  .IX Item "ssbs"
  Enable the Armv8\-a Speculative Store Bypass Safe instruction.  This option
  is only to enable the extension at the assembler level and does not affect code
  generation.  This option is enabled by default for \fB\-march=armv8.5\-a\fR.
! .IP "\fBpredres\fR" 4
  .IX Item "predres"
  Enable the Armv8\-a Execution and Data Prediction Restriction instructions.
  This option is only to enable the extension at the assembler level and does
  not affect code generation.  This option is enabled by default for
  \&\fB\-march=armv8.5\-a\fR.
! .IP "\fBsve2\fR" 4
  .IX Item "sve2"
! Enable the Armv8\-a Scalable Vector Extension 2.  This also enables \s-1SVE\s0
  instructions.
! .IP "\fBsve2\-bitperm\fR" 4
  .IX Item "sve2-bitperm"
! Enable \s-1SVE2\s0 bitperm instructions.  This also enables \s-1SVE2\s0 instructions.
! .IP "\fBsve2\-sm4\fR" 4
  .IX Item "sve2-sm4"
! Enable \s-1SVE2\s0 sm4 instructions.  This also enables \s-1SVE2\s0 instructions.
! .IP "\fBsve2\-aes\fR" 4
  .IX Item "sve2-aes"
! Enable \s-1SVE2\s0 aes instructions.  This also enables \s-1SVE2\s0 instructions.
! .IP "\fBsve2\-sha3\fR" 4
  .IX Item "sve2-sha3"
! Enable \s-1SVE2\s0 sha3 instructions.  This also enables \s-1SVE2\s0 instructions.
! .IP "\fBtme\fR" 4
  .IX Item "tme"
  Enable the Transactional Memory Extension.
! .IP "\fBi8mm\fR" 4
  .IX Item "i8mm"
  Enable 8\-bit Integer Matrix Multiply instructions.  This also enables
! Advanced \s-1SIMD\s0 and floating-point instructions.  This option is enabled by
  default for \fB\-march=armv8.6\-a\fR.  Use of this option with architectures
  prior to Armv8.2\-A is not supported.
! .IP "\fBf32mm\fR" 4
  .IX Item "f32mm"
  Enable 32\-bit Floating point Matrix Multiply instructions.  This also enables
! \&\s-1SVE\s0 instructions.  Use of this option with architectures prior to Armv8.2\-A is
  not supported.
! .IP "\fBf64mm\fR" 4
  .IX Item "f64mm"
  Enable 64\-bit Floating point Matrix Multiply instructions.  This also enables
! \&\s-1SVE\s0 instructions.  Use of this option with architectures prior to Armv8.2\-A is
  not supported.
! .IP "\fBbf16\fR" 4
  .IX Item "bf16"
! Enable brain half-precision floating-point instructions.  This also enables
! Advanced \s-1SIMD\s0 and floating-point instructions.  This option is enabled by
  default for \fB\-march=armv8.6\-a\fR.  Use of this option with architectures
  prior to Armv8.2\-A is not supported.
! .IP "\fBls64\fR" 4
  .IX Item "ls64"
  Enable the 64\-byte atomic load and store instructions for accelerators.
  This option is enabled by default for \fB\-march=armv8.7\-a\fR.
! .IP "\fBmops\fR" 4
  .IX Item "mops"
  Enable the instructions to accelerate memory operations like \f(CW\*(C`memcpy\*(C'\fR,
  \&\f(CW\*(C`memmove\*(C'\fR, \f(CW\*(C`memset\*(C'\fR.  This option is enabled by default for
  \&\fB\-march=armv8.8\-a\fR
! .IP "\fBflagm\fR" 4
  .IX Item "flagm"
  Enable the Flag Manipulation instructions Extension.
! .IP "\fBpauth\fR" 4
  .IX Item "pauth"
  Enable the Pointer Authentication Extension.
! .IP "\fBcssc\fR" 4
  .IX Item "cssc"
  Enable the Common Short Sequence Compression instructions.
  .PP
--- 19734,19934 ----
  has additional tuning options, then \fBstandard\fR sets it to its standard
  level.
  \&\fBpac\-ret[+\fR\fIleaf\fR\fB]\fR turns on return address signing to its standard
! level: signing functions that save the return address to memory (non\-leaf
  functions will practically always do this) using the a\-key.  The optional
  argument \fBleaf\fR can be used to extend the signing to include leaf
  functions.  The optional argument \fBb\-key\fR can be used to sign the functions
  with the B\-key instead of the A\-key.
  \&\fBbti\fR turns on branch target identification mechanism.
! .IP \fB\-mharden\-sls=\fR\fIopts\fR 4
  .IX Item "-mharden-sls=opts"
! Enable compiler hardening against straight line speculation (SLS).
! \&\fIopts\fR is a comma\-separated list of the following options:
  .RS 4
! .IP \fBretbr\fR 4
  .IX Item "retbr"
  .PD 0
! .IP \fBblr\fR 4
  .IX Item "blr"
+ .PD
  .RE
  .RS 4
  .Sp
! In addition, \fB\-mharden\-sls=all\fR enables all SLS hardening while
! \&\fB\-mharden\-sls=none\fR disables all SLS hardening.
  .RE
! .IP \fB\-msve\-vector\-bits=\fR\fIbits\fR 4
  .IX Item "-msve-vector-bits=bits"
! Specify the number of bits in an SVE vector register.  This option only has
! an effect when SVE is enabled.
  .Sp
! GCC supports two forms of SVE code generation: "vector\-length
! agnostic" output that works with any size of vector register and
! "vector\-length specific" output that allows GCC to make assumptions
  about the vector length when it is useful for optimization reasons.
  The possible values of \fBbits\fR are: \fBscalable\fR, \fB128\fR,
  \&\fB256\fR, \fB512\fR, \fB1024\fR and \fB2048\fR.
! Specifying \fBscalable\fR selects vector\-length agnostic
! output.  At present \fB\-msve\-vector\-bits=128\fR also generates vector\-length
! agnostic output for big\-endian targets.  All other values generate
! vector\-length specific code.  The behavior of these values may change
  in future releases and no value except \fBscalable\fR should be
  relied on for producing code that is portable across different
! hardware SVE vector lengths.
  .Sp
  The default is \fB\-msve\-vector\-bits=scalable\fR, which produces
! vector\-length agnostic code.
  .PP
  \fB\-march\fR and \fB\-mcpu\fR Feature Modifiers
  .IX Subsection "-march and -mcpu Feature Modifiers"
  .PP
  Feature modifiers used with \fB\-march\fR and \fB\-mcpu\fR can be any of
  the following and their inverses \fBno\fR\fIfeature\fR:
! .IP \fBcrc\fR 4
  .IX Item "crc"
! Enable CRC extension.  This is on by default for
  \&\fB\-march=armv8.1\-a\fR.
! .IP \fBcrypto\fR 4
  .IX Item "crypto"
! Enable Crypto extension.  This also enables Advanced SIMD and floating\-point
  instructions.
! .IP \fBfp\fR 4
  .IX Item "fp"
! Enable floating\-point instructions.  This is on by default for all possible
  values for options \fB\-march\fR and \fB\-mcpu\fR.
! .IP \fBsimd\fR 4
  .IX Item "simd"
! Enable Advanced SIMD instructions.  This also enables floating\-point
  instructions.  This is on by default for all possible values for options
  \&\fB\-march\fR and \fB\-mcpu\fR.
! .IP \fBsve\fR 4
  .IX Item "sve"
  Enable Scalable Vector Extension instructions.  This also enables Advanced
! SIMD and floating\-point instructions.
! .IP \fBlse\fR 4
  .IX Item "lse"
  Enable Large System Extension instructions.  This is on by default for
  \&\fB\-march=armv8.1\-a\fR.
! .IP \fBrdma\fR 4
  .IX Item "rdma"
  Enable Round Double Multiply Accumulate instructions.  This is on by default
  for \fB\-march=armv8.1\-a\fR.
! .IP \fBfp16\fR 4
  .IX Item "fp16"
! Enable FP16 extension.  This also enables floating\-point instructions.
! .IP \fBfp16fml\fR 4
  .IX Item "fp16fml"
! Enable FP16 fmla extension.  This also enables FP16 extensions and
! floating\-point instructions. This option is enabled by default for \fB\-march=armv8.4\-a\fR. Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP \fBrcpc\fR 4
  .IX Item "rcpc"
! Enable the RCpc extension.  This enables the use of the LDAPR instructions for
! load\-acquire atomic semantics, and passes it on to the assembler, enabling
  inline asm statements to use instructions from the RCpc extension.
! .IP \fBdotprod\fR 4
  .IX Item "dotprod"
! Enable the Dot Product extension.  This also enables Advanced SIMD instructions.
! .IP \fBaes\fR 4
  .IX Item "aes"
  Enable the Armv8\-a aes and pmull crypto extension.  This also enables Advanced
! SIMD instructions.
! .IP \fBsha2\fR 4
  .IX Item "sha2"
! Enable the Armv8\-a sha2 crypto extension.  This also enables Advanced SIMD instructions.
! .IP \fBsha3\fR 4
  .IX Item "sha3"
! Enable the sha512 and sha3 crypto extension.  This also enables Advanced SIMD
  instructions. Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP \fBsm4\fR 4
  .IX Item "sm4"
! Enable the sm3 and sm4 crypto extension.  This also enables Advanced SIMD instructions.
  Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP \fBprofile\fR 4
  .IX Item "profile"
  Enable the Statistical Profiling extension.  This option is only to enable the
  extension at the assembler level and does not affect code generation.
! .IP \fBrng\fR 4
  .IX Item "rng"
  Enable the Armv8.5\-a Random Number instructions.  This option is only to
  enable the extension at the assembler level and does not affect code
  generation.
! .IP \fBmemtag\fR 4
  .IX Item "memtag"
  Enable the Armv8.5\-a Memory Tagging Extensions.
  Use of this option with architectures prior to Armv8.5\-A is not supported.
! .IP \fBsb\fR 4
  .IX Item "sb"
  Enable the Armv8\-a Speculation Barrier instruction.  This option is only to
  enable the extension at the assembler level and does not affect code
  generation.  This option is enabled by default for \fB\-march=armv8.5\-a\fR.
! .IP \fBssbs\fR 4
  .IX Item "ssbs"
  Enable the Armv8\-a Speculative Store Bypass Safe instruction.  This option
  is only to enable the extension at the assembler level and does not affect code
  generation.  This option is enabled by default for \fB\-march=armv8.5\-a\fR.
! .IP \fBpredres\fR 4
  .IX Item "predres"
  Enable the Armv8\-a Execution and Data Prediction Restriction instructions.
  This option is only to enable the extension at the assembler level and does
  not affect code generation.  This option is enabled by default for
  \&\fB\-march=armv8.5\-a\fR.
! .IP \fBsve2\fR 4
  .IX Item "sve2"
! Enable the Armv8\-a Scalable Vector Extension 2.  This also enables SVE
  instructions.
! .IP \fBsve2\-bitperm\fR 4
  .IX Item "sve2-bitperm"
! Enable SVE2 bitperm instructions.  This also enables SVE2 instructions.
! .IP \fBsve2\-sm4\fR 4
  .IX Item "sve2-sm4"
! Enable SVE2 sm4 instructions.  This also enables SVE2 instructions.
! .IP \fBsve2\-aes\fR 4
  .IX Item "sve2-aes"
! Enable SVE2 aes instructions.  This also enables SVE2 instructions.
! .IP \fBsve2\-sha3\fR 4
  .IX Item "sve2-sha3"
! Enable SVE2 sha3 instructions.  This also enables SVE2 instructions.
! .IP \fBtme\fR 4
  .IX Item "tme"
  Enable the Transactional Memory Extension.
! .IP \fBi8mm\fR 4
  .IX Item "i8mm"
  Enable 8\-bit Integer Matrix Multiply instructions.  This also enables
! Advanced SIMD and floating\-point instructions.  This option is enabled by
  default for \fB\-march=armv8.6\-a\fR.  Use of this option with architectures
  prior to Armv8.2\-A is not supported.
! .IP \fBf32mm\fR 4
  .IX Item "f32mm"
  Enable 32\-bit Floating point Matrix Multiply instructions.  This also enables
! SVE instructions.  Use of this option with architectures prior to Armv8.2\-A is
  not supported.
! .IP \fBf64mm\fR 4
  .IX Item "f64mm"
  Enable 64\-bit Floating point Matrix Multiply instructions.  This also enables
! SVE instructions.  Use of this option with architectures prior to Armv8.2\-A is
  not supported.
! .IP \fBbf16\fR 4
  .IX Item "bf16"
! Enable brain half\-precision floating\-point instructions.  This also enables
! Advanced SIMD and floating\-point instructions.  This option is enabled by
  default for \fB\-march=armv8.6\-a\fR.  Use of this option with architectures
  prior to Armv8.2\-A is not supported.
! .IP \fBls64\fR 4
  .IX Item "ls64"
  Enable the 64\-byte atomic load and store instructions for accelerators.
  This option is enabled by default for \fB\-march=armv8.7\-a\fR.
! .IP \fBmops\fR 4
  .IX Item "mops"
  Enable the instructions to accelerate memory operations like \f(CW\*(C`memcpy\*(C'\fR,
  \&\f(CW\*(C`memmove\*(C'\fR, \f(CW\*(C`memset\*(C'\fR.  This option is enabled by default for
  \&\fB\-march=armv8.8\-a\fR
! .IP \fBflagm\fR 4
  .IX Item "flagm"
  Enable the Flag Manipulation instructions Extension.
! .IP \fBpauth\fR 4
  .IX Item "pauth"
  Enable the Pointer Authentication Extension.
! .IP \fBcssc\fR 4
  .IX Item "cssc"
  Enable the Common Short Sequence Compression instructions.
  .PP
*************** Conversely, \fBnofp\fR implies \fBnosimd
*** 20010,20143 ****
  .IX Subsection "Adapteva Epiphany Options"
  .PP
  These \fB\-m\fR options are defined for Adapteva Epiphany:
! .IP "\fB\-mhalf\-reg\-file\fR" 4
  .IX Item "-mhalf-reg-file"
! Don't allocate any register in the range \f(CW\*(C`r32\*(C'\fR...\f(CW\*(C`r63\*(C'\fR.
  That allows code to run on hardware variants that lack these registers.
! .IP "\fB\-mprefer\-short\-insn\-regs\fR" 4
  .IX Item "-mprefer-short-insn-regs"
  Preferentially allocate registers that allow short instruction generation.
  This can result in increased instruction count, so this may either reduce or
  increase overall code size.
! .IP "\fB\-mbranch\-cost=\fR\fInum\fR" 4
  .IX Item "-mbranch-cost=num"
! Set the cost of branches to roughly \fInum\fR \*(L"simple\*(R" instructions.
  This cost is only a heuristic and is not guaranteed to produce
  consistent results across releases.
! .IP "\fB\-mcmove\fR" 4
  .IX Item "-mcmove"
  Enable the generation of conditional moves.
! .IP "\fB\-mnops=\fR\fInum\fR" 4
  .IX Item "-mnops=num"
  Emit \fInum\fR NOPs before every other generated instruction.
! .IP "\fB\-mno\-soft\-cmpsf\fR" 4
  .IX Item "-mno-soft-cmpsf"
! For single-precision floating-point comparisons, emit an \f(CW\*(C`fsub\*(C'\fR instruction
  and test the flags.  This is faster than a software comparison, but can
  get incorrect results in the presence of NaNs, or when two different small
  numbers are compared such that their difference is calculated as zero.
! The default is \fB\-msoft\-cmpsf\fR, which uses slower, but IEEE-compliant,
  software comparisons.
! .IP "\fB\-mstack\-offset=\fR\fInum\fR" 4
  .IX Item "-mstack-offset=num"
  Set the offset between the top of the stack and the stack pointer.
  E.g., a value of 8 means that the eight bytes in the range \f(CW\*(C`sp+0...sp+7\*(C'\fR
  can be used by leaf functions without stack allocation.
  Values other than \fB8\fR or \fB16\fR are untested and unlikely to work.
! Note also that this option changes the \s-1ABI\s0; compiling a program with a
  different stack offset than the libraries have been compiled with
  generally does not work.
  This option can be useful if you want to evaluate if a different stack
  offset would give you better code, but to actually use a different stack
  offset to build working programs, it is recommended to configure the
  toolchain with the appropriate \fB\-\-with\-stack\-offset=\fR\fInum\fR option.
! .IP "\fB\-mno\-round\-nearest\fR" 4
  .IX Item "-mno-round-nearest"
  Make the scheduler assume that the rounding mode has been set to
  truncating.  The default is \fB\-mround\-nearest\fR.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  If not otherwise specified by an attribute, assume all calls might be beyond
  the offset range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, and therefore load the
  function address into a register before performing a (otherwise direct) call.
  This is the default.
! .IP "\fB\-mshort\-calls\fR" 4
  .IX Item "-mshort-calls"
  If not otherwise specified by an attribute, assume all direct calls are
  in the range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, so use these instructions
  for direct calls.  The default is \fB\-mlong\-calls\fR.
! .IP "\fB\-msmall16\fR" 4
  .IX Item "-msmall16"
  Assume addresses can be loaded as 16\-bit unsigned values.  This does not
  apply to function addresses for which \fB\-mlong\-calls\fR semantics
  are in effect.
! .IP "\fB\-mfp\-mode=\fR\fImode\fR" 4
  .IX Item "-mfp-mode=mode"
! Set the prevailing mode of the floating-point unit.
! This determines the floating-point mode that is provided and expected
  at function call and return time.  Making this mode match the mode you
  predominantly need at function start can make your programs smaller and
  faster by avoiding unnecessary mode switches.
  .Sp
  \&\fImode\fR can be set to one the following values:
  .RS 4
! .IP "\fBcaller\fR" 4
  .IX Item "caller"
  Any mode at function entry is valid, and retained or restored when
  the function returns, and when it calls other functions.
  This mode is useful for compiling libraries or other compilation units
  you might want to incorporate into different programs with different
! prevailing \s-1FPU\s0 modes, and the convenience of being able to use a single
  object file outweighs the size and speed overhead for any extra
  mode switching that might be needed, compared with what would be needed
! with a more specific choice of prevailing \s-1FPU\s0 mode.
! .IP "\fBtruncate\fR" 4
  .IX Item "truncate"
! This is the mode used for floating-point calculations with
  truncating (i.e. round towards zero) rounding mode.  That includes
  conversion from floating point to integer.
! .IP "\fBround-nearest\fR" 4
  .IX Item "round-nearest"
! This is the mode used for floating-point calculations with
! round-to-nearest-or-even rounding mode.
! .IP "\fBint\fR" 4
  .IX Item "int"
! This is the mode used to perform integer calculations in the \s-1FPU,\s0 e.g.
! integer multiply, or integer multiply-and-accumulate.
  .RE
  .RS 4
  .Sp
  The default is \fB\-mfp\-mode=caller\fR
  .RE
! .IP "\fB\-mno\-split\-lohi\fR" 4
  .IX Item "-mno-split-lohi"
  .PD 0
! .IP "\fB\-mno\-postinc\fR" 4
  .IX Item "-mno-postinc"
! .IP "\fB\-mno\-postmodify\fR" 4
  .IX Item "-mno-postmodify"
  .PD
  Code generation tweaks that disable, respectively, splitting of 32\-bit
! loads, generation of post-increment addresses, and generation of
! post-modify addresses.  The defaults are \fBmsplit-lohi\fR,
  \&\fB\-mpost\-inc\fR, and \fB\-mpost\-modify\fR.
! .IP "\fB\-mnovect\-double\fR" 4
  .IX Item "-mnovect-double"
! Change the preferred \s-1SIMD\s0 mode to SImode.  The default is
! \&\fB\-mvect\-double\fR, which uses DImode as preferred \s-1SIMD\s0 mode.
! .IP "\fB\-max\-vect\-align=\fR\fInum\fR" 4
  .IX Item "-max-vect-align=num"
! The maximum alignment for \s-1SIMD\s0 vector mode types.
  \&\fInum\fR may be 4 or 8.  The default is 8.
! Note that this is an \s-1ABI\s0 change, even though many library function
! interfaces are unaffected if they don't use \s-1SIMD\s0 vector modes
  in places that affect size and/or alignment of relevant types.
! .IP "\fB\-msplit\-vecmove\-early\fR" 4
  .IX Item "-msplit-vecmove-early"
  Split vector moves into single word moves before reload.  In theory this
  can give better register allocation, but so far the reverse seems to be
  generally the case.
! .IP "\fB\-m1reg\-\fR\fIreg\fR" 4
  .IX Item "-m1reg-reg"
  Specify a register to hold the constant \-1, which makes loading small negative
  constants and certain bitmasks faster.
--- 19941,20074 ----
  .IX Subsection "Adapteva Epiphany Options"
  .PP
  These \fB\-m\fR options are defined for Adapteva Epiphany:
! .IP \fB\-mhalf\-reg\-file\fR 4
  .IX Item "-mhalf-reg-file"
! Don\*(Aqt allocate any register in the range \f(CW\*(C`r32\*(C'\fR...\f(CW\*(C`r63\*(C'\fR.
  That allows code to run on hardware variants that lack these registers.
! .IP \fB\-mprefer\-short\-insn\-regs\fR 4
  .IX Item "-mprefer-short-insn-regs"
  Preferentially allocate registers that allow short instruction generation.
  This can result in increased instruction count, so this may either reduce or
  increase overall code size.
! .IP \fB\-mbranch\-cost=\fR\fInum\fR 4
  .IX Item "-mbranch-cost=num"
! Set the cost of branches to roughly \fInum\fR "simple" instructions.
  This cost is only a heuristic and is not guaranteed to produce
  consistent results across releases.
! .IP \fB\-mcmove\fR 4
  .IX Item "-mcmove"
  Enable the generation of conditional moves.
! .IP \fB\-mnops=\fR\fInum\fR 4
  .IX Item "-mnops=num"
  Emit \fInum\fR NOPs before every other generated instruction.
! .IP \fB\-mno\-soft\-cmpsf\fR 4
  .IX Item "-mno-soft-cmpsf"
! For single\-precision floating\-point comparisons, emit an \f(CW\*(C`fsub\*(C'\fR instruction
  and test the flags.  This is faster than a software comparison, but can
  get incorrect results in the presence of NaNs, or when two different small
  numbers are compared such that their difference is calculated as zero.
! The default is \fB\-msoft\-cmpsf\fR, which uses slower, but IEEE\-compliant,
  software comparisons.
! .IP \fB\-mstack\-offset=\fR\fInum\fR 4
  .IX Item "-mstack-offset=num"
  Set the offset between the top of the stack and the stack pointer.
  E.g., a value of 8 means that the eight bytes in the range \f(CW\*(C`sp+0...sp+7\*(C'\fR
  can be used by leaf functions without stack allocation.
  Values other than \fB8\fR or \fB16\fR are untested and unlikely to work.
! Note also that this option changes the ABI; compiling a program with a
  different stack offset than the libraries have been compiled with
  generally does not work.
  This option can be useful if you want to evaluate if a different stack
  offset would give you better code, but to actually use a different stack
  offset to build working programs, it is recommended to configure the
  toolchain with the appropriate \fB\-\-with\-stack\-offset=\fR\fInum\fR option.
! .IP \fB\-mno\-round\-nearest\fR 4
  .IX Item "-mno-round-nearest"
  Make the scheduler assume that the rounding mode has been set to
  truncating.  The default is \fB\-mround\-nearest\fR.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  If not otherwise specified by an attribute, assume all calls might be beyond
  the offset range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, and therefore load the
  function address into a register before performing a (otherwise direct) call.
  This is the default.
! .IP \fB\-mshort\-calls\fR 4
  .IX Item "-mshort-calls"
  If not otherwise specified by an attribute, assume all direct calls are
  in the range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, so use these instructions
  for direct calls.  The default is \fB\-mlong\-calls\fR.
! .IP \fB\-msmall16\fR 4
  .IX Item "-msmall16"
  Assume addresses can be loaded as 16\-bit unsigned values.  This does not
  apply to function addresses for which \fB\-mlong\-calls\fR semantics
  are in effect.
! .IP \fB\-mfp\-mode=\fR\fImode\fR 4
  .IX Item "-mfp-mode=mode"
! Set the prevailing mode of the floating\-point unit.
! This determines the floating\-point mode that is provided and expected
  at function call and return time.  Making this mode match the mode you
  predominantly need at function start can make your programs smaller and
  faster by avoiding unnecessary mode switches.
  .Sp
  \&\fImode\fR can be set to one the following values:
  .RS 4
! .IP \fBcaller\fR 4
  .IX Item "caller"
  Any mode at function entry is valid, and retained or restored when
  the function returns, and when it calls other functions.
  This mode is useful for compiling libraries or other compilation units
  you might want to incorporate into different programs with different
! prevailing FPU modes, and the convenience of being able to use a single
  object file outweighs the size and speed overhead for any extra
  mode switching that might be needed, compared with what would be needed
! with a more specific choice of prevailing FPU mode.
! .IP \fBtruncate\fR 4
  .IX Item "truncate"
! This is the mode used for floating\-point calculations with
  truncating (i.e. round towards zero) rounding mode.  That includes
  conversion from floating point to integer.
! .IP \fBround\-nearest\fR 4
  .IX Item "round-nearest"
! This is the mode used for floating\-point calculations with
! round\-to\-nearest\-or\-even rounding mode.
! .IP \fBint\fR 4
  .IX Item "int"
! This is the mode used to perform integer calculations in the FPU, e.g.
! integer multiply, or integer multiply\-and\-accumulate.
  .RE
  .RS 4
  .Sp
  The default is \fB\-mfp\-mode=caller\fR
  .RE
! .IP \fB\-mno\-split\-lohi\fR 4
  .IX Item "-mno-split-lohi"
  .PD 0
! .IP \fB\-mno\-postinc\fR 4
  .IX Item "-mno-postinc"
! .IP \fB\-mno\-postmodify\fR 4
  .IX Item "-mno-postmodify"
  .PD
  Code generation tweaks that disable, respectively, splitting of 32\-bit
! loads, generation of post\-increment addresses, and generation of
! post\-modify addresses.  The defaults are \fBmsplit\-lohi\fR,
  \&\fB\-mpost\-inc\fR, and \fB\-mpost\-modify\fR.
! .IP \fB\-mnovect\-double\fR 4
  .IX Item "-mnovect-double"
! Change the preferred SIMD mode to SImode.  The default is
! \&\fB\-mvect\-double\fR, which uses DImode as preferred SIMD mode.
! .IP \fB\-max\-vect\-align=\fR\fInum\fR 4
  .IX Item "-max-vect-align=num"
! The maximum alignment for SIMD vector mode types.
  \&\fInum\fR may be 4 or 8.  The default is 8.
! Note that this is an ABI change, even though many library function
! interfaces are unaffected if they don\*(Aqt use SIMD vector modes
  in places that affect size and/or alignment of relevant types.
! .IP \fB\-msplit\-vecmove\-early\fR 4
  .IX Item "-msplit-vecmove-early"
  Split vector moves into single word moves before reload.  In theory this
  can give better register allocation, but so far the reverse seems to be
  generally the case.
! .IP \fB\-m1reg\-\fR\fIreg\fR 4
  .IX Item "-m1reg-reg"
  Specify a register to hold the constant \-1, which makes loading small negative
  constants and certain bitmasks faster.
*************** which specify use of that register as a
*** 20146,20656 ****
  and \fBnone\fR, which means that no register is used for this
  purpose.  The default is \fB\-m1reg\-none\fR.
  .PP
! \fI\s-1AMD GCN\s0 Options\fR
  .IX Subsection "AMD GCN Options"
  .PP
! These options are defined specifically for the \s-1AMD GCN\s0 port.
! .IP "\fB\-march=\fR\fIgpu\fR" 4
  .IX Item "-march=gpu"
  .PD 0
! .IP "\fB\-mtune=\fR\fIgpu\fR" 4
  .IX Item "-mtune=gpu"
  .PD
  Set architecture type or tuning for \fIgpu\fR. Supported values for \fIgpu\fR
  are
  .RS 4
! .IP "\fBfiji\fR" 4
  .IX Item "fiji"
! Compile for \s-1GCN3\s0 Fiji devices (gfx803).
! .IP "\fBgfx900\fR" 4
  .IX Item "gfx900"
! Compile for \s-1GCN5\s0 Vega 10 devices (gfx900).
! .IP "\fBgfx906\fR" 4
  .IX Item "gfx906"
! Compile for \s-1GCN5\s0 Vega 20 devices (gfx906).
! .IP "\fBgfx908\fR" 4
  .IX Item "gfx908"
! Compile for \s-1CDNA1\s0 Instinct \s-1MI100\s0 series devices (gfx908).
! .IP "\fBgfx90a\fR" 4
  .IX Item "gfx90a"
! Compile for \s-1CDNA2\s0 Instinct \s-1MI200\s0 series devices (gfx90a).
  .RE
  .RS 4
  .RE
! .IP "\fB\-msram\-ecc=on\fR" 4
  .IX Item "-msram-ecc=on"
  .PD 0
! .IP "\fB\-msram\-ecc=off\fR" 4
  .IX Item "-msram-ecc=off"
! .IP "\fB\-msram\-ecc=any\fR" 4
  .IX Item "-msram-ecc=any"
  .PD
! Compile binaries suitable for devices with the SRAM-ECC feature enabled,
! disabled, or either mode.  This feature can be enabled per-process on some
  devices.  The compiled code must match the device mode. The default is
  \&\fBany\fR, for devices that support it.
! .IP "\fB\-mstack\-size=\fR\fIbytes\fR" 4
  .IX Item "-mstack-size=bytes"
! Specify how many \fIbytes\fR of stack space will be requested for each \s-1GPU\s0
! thread (wave-front).  Beware that there may be many threads and limited memory
  available.  The size of the stack allocation may also have an impact on
! run-time performance.  The default is 32KB when using OpenACC or OpenMP, and
  1MB otherwise.
! .IP "\fB\-mxnack\fR" 4
  .IX Item "-mxnack"
! Compile binaries suitable for devices with the \s-1XNACK\s0 feature enabled.  Some
! devices always require \s-1XNACK\s0 and some allow the user to configure \s-1XNACK.\s0  The
  compiled code must match the device mode.  The default is \fB\-mno\-xnack\fR.
  At present this option is a placeholder for support that is not yet
  implemented.
  .PP
! \fI\s-1ARC\s0 Options\fR
  .IX Subsection "ARC Options"
  .PP
  The following options control the architecture variant for which code
  is being compiled:
! .IP "\fB\-mbarrel\-shifter\fR" 4
  .IX Item "-mbarrel-shifter"
  Generate instructions supported by barrel shifter.  This is the default
  unless \fB\-mcpu=ARC601\fR or \fB\-mcpu=ARCEM\fR is in effect.
! .IP "\fB\-mjli\-always\fR" 4
  .IX Item "-mjli-always"
  Force to call a function using jli_s instruction.  This option is
  valid only for ARCv2 architecture.
! .IP "\fB\-mcpu=\fR\fIcpu\fR" 4
  .IX Item "-mcpu=cpu"
  Set architecture type, register usage, and instruction scheduling
  parameters for \fIcpu\fR.  There are also shortcut alias options
  available for backward compatibility and convenience.  Supported
  values for \fIcpu\fR are
  .RS 4
! .IP "\fBarc600\fR" 4
  .IX Item "arc600"
! Compile for \s-1ARC600.\s0  Aliases: \fB\-mA6\fR, \fB\-mARC600\fR.
! .IP "\fBarc601\fR" 4
  .IX Item "arc601"
! Compile for \s-1ARC601.\s0  Alias: \fB\-mARC601\fR.
! .IP "\fBarc700\fR" 4
  .IX Item "arc700"
! Compile for \s-1ARC700.\s0  Aliases: \fB\-mA7\fR, \fB\-mARC700\fR.
  This is the default when configured with \fB\-\-with\-cpu=arc700\fR.
! .IP "\fBarcem\fR" 4
  .IX Item "arcem"
! Compile for \s-1ARC EM.\s0
! .IP "\fBarchs\fR" 4
  .IX Item "archs"
! Compile for \s-1ARC HS.\s0
! .IP "\fBem\fR" 4
  .IX Item "em"
! Compile for \s-1ARC EM CPU\s0 with no hardware extensions.
! .IP "\fBem4\fR" 4
  .IX Item "em4"
! Compile for \s-1ARC EM4 CPU.\s0
! .IP "\fBem4_dmips\fR" 4
  .IX Item "em4_dmips"
! Compile for \s-1ARC EM4 DMIPS CPU.\s0
! .IP "\fBem4_fpus\fR" 4
  .IX Item "em4_fpus"
! Compile for \s-1ARC EM4 DMIPS CPU\s0 with the single-precision floating-point
  extension.
! .IP "\fBem4_fpuda\fR" 4
  .IX Item "em4_fpuda"
! Compile for \s-1ARC EM4 DMIPS CPU\s0 with single-precision floating-point and
  double assist instructions.
! .IP "\fBhs\fR" 4
  .IX Item "hs"
! Compile for \s-1ARC HS CPU\s0 with no hardware extensions except the atomic
  instructions.
! .IP "\fBhs34\fR" 4
  .IX Item "hs34"
! Compile for \s-1ARC HS34 CPU.\s0
! .IP "\fBhs38\fR" 4
  .IX Item "hs38"
! Compile for \s-1ARC HS38 CPU.\s0
! .IP "\fBhs38_linux\fR" 4
  .IX Item "hs38_linux"
! Compile for \s-1ARC HS38 CPU\s0 with all hardware extensions on.
! .IP "\fBhs4x\fR" 4
  .IX Item "hs4x"
! Compile for \s-1ARC\s0 HS4x \s-1CPU.\s0
! .IP "\fBhs4xd\fR" 4
  .IX Item "hs4xd"
! Compile for \s-1ARC\s0 HS4xD \s-1CPU.\s0
! .IP "\fBhs4x_rel31\fR" 4
  .IX Item "hs4x_rel31"
! Compile for \s-1ARC\s0 HS4x \s-1CPU\s0 release 3.10a.
! .IP "\fBarc600_norm\fR" 4
  .IX Item "arc600_norm"
! Compile for \s-1ARC 600 CPU\s0 with \f(CW\*(C`norm\*(C'\fR instructions enabled.
! .IP "\fBarc600_mul32x16\fR" 4
  .IX Item "arc600_mul32x16"
! Compile for \s-1ARC 600 CPU\s0 with \f(CW\*(C`norm\*(C'\fR and 32x16\-bit multiply 
  instructions enabled.
! .IP "\fBarc600_mul64\fR" 4
  .IX Item "arc600_mul64"
! Compile for \s-1ARC 600 CPU\s0 with \f(CW\*(C`norm\*(C'\fR and \f(CW\*(C`mul64\*(C'\fR\-family 
  instructions enabled.
! .IP "\fBarc601_norm\fR" 4
  .IX Item "arc601_norm"
! Compile for \s-1ARC 601 CPU\s0 with \f(CW\*(C`norm\*(C'\fR instructions enabled.
! .IP "\fBarc601_mul32x16\fR" 4
  .IX Item "arc601_mul32x16"
! Compile for \s-1ARC 601 CPU\s0 with \f(CW\*(C`norm\*(C'\fR and 32x16\-bit multiply
  instructions enabled.
! .IP "\fBarc601_mul64\fR" 4
  .IX Item "arc601_mul64"
! Compile for \s-1ARC 601 CPU\s0 with \f(CW\*(C`norm\*(C'\fR and \f(CW\*(C`mul64\*(C'\fR\-family
  instructions enabled.
! .IP "\fBnps400\fR" 4
  .IX Item "nps400"
! Compile for \s-1ARC 700\s0 on \s-1NPS400\s0 chip.
! .IP "\fBem_mini\fR" 4
  .IX Item "em_mini"
! Compile for \s-1ARC EM\s0 minimalist configuration featuring reduced register
  set.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mdpfp\fR" 4
  .IX Item "-mdpfp"
  .PD 0
! .IP "\fB\-mdpfp\-compact\fR" 4
  .IX Item "-mdpfp-compact"
  .PD
! Generate double-precision \s-1FPX\s0 instructions, tuned for the compact
  implementation.
! .IP "\fB\-mdpfp\-fast\fR" 4
  .IX Item "-mdpfp-fast"
! Generate double-precision \s-1FPX\s0 instructions, tuned for the fast
  implementation.
! .IP "\fB\-mno\-dpfp\-lrsr\fR" 4
  .IX Item "-mno-dpfp-lrsr"
! Disable \f(CW\*(C`lr\*(C'\fR and \f(CW\*(C`sr\*(C'\fR instructions from using \s-1FPX\s0 extension
  aux registers.
! .IP "\fB\-mea\fR" 4
  .IX Item "-mea"
  Generate extended arithmetic instructions.  Currently only
  \&\f(CW\*(C`divaw\*(C'\fR, \f(CW\*(C`adds\*(C'\fR, \f(CW\*(C`subs\*(C'\fR, and \f(CW\*(C`sat16\*(C'\fR are
  supported.  Only valid for \fB\-mcpu=ARC700\fR.
! .IP "\fB\-mno\-mpy\fR" 4
  .IX Item "-mno-mpy"
! Do not generate \f(CW\*(C`mpy\*(C'\fR\-family instructions for \s-1ARC700.\s0  This option is
  deprecated.
! .IP "\fB\-mmul32x16\fR" 4
  .IX Item "-mmul32x16"
! Generate 32x16\-bit multiply and multiply-accumulate instructions.
! .IP "\fB\-mmul64\fR" 4
  .IX Item "-mmul64"
  Generate \f(CW\*(C`mul64\*(C'\fR and \f(CW\*(C`mulu64\*(C'\fR instructions.  
  Only valid for \fB\-mcpu=ARC600\fR.
! .IP "\fB\-mnorm\fR" 4
  .IX Item "-mnorm"
  Generate \f(CW\*(C`norm\*(C'\fR instructions.  This is the default if \fB\-mcpu=ARC700\fR
  is in effect.
! .IP "\fB\-mspfp\fR" 4
  .IX Item "-mspfp"
  .PD 0
! .IP "\fB\-mspfp\-compact\fR" 4
  .IX Item "-mspfp-compact"
  .PD
! Generate single-precision \s-1FPX\s0 instructions, tuned for the compact
  implementation.
! .IP "\fB\-mspfp\-fast\fR" 4
  .IX Item "-mspfp-fast"
! Generate single-precision \s-1FPX\s0 instructions, tuned for the fast
  implementation.
! .IP "\fB\-msimd\fR" 4
  .IX Item "-msimd"
! Enable generation of \s-1ARC SIMD\s0 instructions via target-specific
  builtins.  Only valid for \fB\-mcpu=ARC700\fR.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  This option ignored; it is provided for compatibility purposes only.
! Software floating-point code is emitted by default, and this default
! can overridden by \s-1FPX\s0 options; \fB\-mspfp\fR, \fB\-mspfp\-compact\fR, or
  \&\fB\-mspfp\-fast\fR for single precision, and \fB\-mdpfp\fR,
  \&\fB\-mdpfp\-compact\fR, or \fB\-mdpfp\-fast\fR for double precision.
! .IP "\fB\-mswap\fR" 4
  .IX Item "-mswap"
  Generate \f(CW\*(C`swap\*(C'\fR instructions.
! .IP "\fB\-matomic\fR" 4
  .IX Item "-matomic"
  This enables use of the locked load/store conditional extension to implement
! atomic memory built-in functions.  Not available for \s-1ARC\s0 6xx or \s-1ARC
! EM\s0 cores.
! .IP "\fB\-mdiv\-rem\fR" 4
  .IX Item "-mdiv-rem"
  Enable \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`rem\*(C'\fR instructions for ARCv2 cores.
! .IP "\fB\-mcode\-density\fR" 4
  .IX Item "-mcode-density"
! Enable code density instructions for \s-1ARC EM.\s0  
! This option is on by default for \s-1ARC HS.\s0
! .IP "\fB\-mll64\fR" 4
  .IX Item "-mll64"
! Enable double load/store operations for \s-1ARC HS\s0 cores.
! .IP "\fB\-mtp\-regno=\fR\fIregno\fR" 4
  .IX Item "-mtp-regno=regno"
  Specify thread pointer register number.
! .IP "\fB\-mmpy\-option=\fR\fImulto\fR" 4
  .IX Item "-mmpy-option=multo"
  Compile ARCv2 code with a multiplier design option.  You can specify 
  the option using either a string or numeric value for \fImulto\fR.  
  \&\fBwlh1\fR is the default value.  The recognized values are:
  .RS 4
! .IP "\fB0\fR" 4
  .IX Item "0"
  .PD 0
! .IP "\fBnone\fR" 4
  .IX Item "none"
  .PD
  No multiplier available.
! .IP "\fB1\fR" 4
  .IX Item "1"
  .PD 0
! .IP "\fBw\fR" 4
  .IX Item "w"
  .PD
  16x16 multiplier, fully pipelined.
  The following instructions are enabled: \f(CW\*(C`mpyw\*(C'\fR and \f(CW\*(C`mpyuw\*(C'\fR.
! .IP "\fB2\fR" 4
  .IX Item "2"
  .PD 0
! .IP "\fBwlh1\fR" 4
  .IX Item "wlh1"
  .PD
  32x32 multiplier, fully
  pipelined (1 stage).  The following instructions are additionally
  enabled: \f(CW\*(C`mpy\*(C'\fR, \f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP "\fB3\fR" 4
  .IX Item "3"
  .PD 0
! .IP "\fBwlh2\fR" 4
  .IX Item "wlh2"
  .PD
  32x32 multiplier, fully pipelined
  (2 stages).  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP "\fB4\fR" 4
  .IX Item "4"
  .PD 0
! .IP "\fBwlh3\fR" 4
  .IX Item "wlh3"
  .PD
  Two 16x16 multipliers, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP "\fB5\fR" 4
  .IX Item "5"
  .PD 0
! .IP "\fBwlh4\fR" 4
  .IX Item "wlh4"
  .PD
  One 16x16 multiplier, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP "\fB6\fR" 4
  .IX Item "6"
  .PD 0
! .IP "\fBwlh5\fR" 4
  .IX Item "wlh5"
  .PD
  One 32x4 multiplier, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP "\fB7\fR" 4
  .IX Item "7"
  .PD 0
! .IP "\fBplus_dmpy\fR" 4
  .IX Item "plus_dmpy"
  .PD
! \&\s-1ARC HS SIMD\s0 support.
! .IP "\fB8\fR" 4
  .IX Item "8"
  .PD 0
! .IP "\fBplus_macd\fR" 4
  .IX Item "plus_macd"
  .PD
! \&\s-1ARC HS SIMD\s0 support.
! .IP "\fB9\fR" 4
  .IX Item "9"
  .PD 0
! .IP "\fBplus_qmacw\fR" 4
  .IX Item "plus_qmacw"
  .PD
! \&\s-1ARC HS SIMD\s0 support.
  .RE
  .RS 4
  .Sp
  This option is only available for ARCv2 cores.
  .RE
! .IP "\fB\-mfpu=\fR\fIfpu\fR" 4
  .IX Item "-mfpu=fpu"
! Enables support for specific floating-point hardware extensions for ARCv2
  cores.  Supported values for \fIfpu\fR are:
  .RS 4
! .IP "\fBfpus\fR" 4
  .IX Item "fpus"
! Enables support for single-precision floating-point hardware
  extensions.
! .IP "\fBfpud\fR" 4
  .IX Item "fpud"
! Enables support for double-precision floating-point hardware
! extensions.  The single-precision floating-point extension is also
! enabled.  Not available for \s-1ARC EM.\s0
! .IP "\fBfpuda\fR" 4
  .IX Item "fpuda"
! Enables support for double-precision floating-point hardware
! extensions using double-precision assist instructions.  The single-precision
! floating-point extension is also enabled.  This option is
! only available for \s-1ARC EM.\s0
! .IP "\fBfpuda_div\fR" 4
  .IX Item "fpuda_div"
! Enables support for double-precision floating-point hardware
! extensions using double-precision assist instructions.
! The single-precision floating-point, square-root, and divide 
  extensions are also enabled.  This option is
! only available for \s-1ARC EM.\s0
! .IP "\fBfpuda_fma\fR" 4
  .IX Item "fpuda_fma"
! Enables support for double-precision floating-point hardware
! extensions using double-precision assist instructions.
! The single-precision floating-point and fused multiply and add 
  hardware extensions are also enabled.  This option is
! only available for \s-1ARC EM.\s0
! .IP "\fBfpuda_all\fR" 4
  .IX Item "fpuda_all"
! Enables support for double-precision floating-point hardware
! extensions using double-precision assist instructions.
! All single-precision floating-point hardware extensions are also
! enabled.  This option is only available for \s-1ARC EM.\s0
! .IP "\fBfpus_div\fR" 4
  .IX Item "fpus_div"
! Enables support for single-precision floating-point, square-root and divide 
  hardware extensions.
! .IP "\fBfpud_div\fR" 4
  .IX Item "fpud_div"
! Enables support for double-precision floating-point, square-root and divide 
  hardware extensions.  This option
! includes option \fBfpus_div\fR. Not available for \s-1ARC EM.\s0
! .IP "\fBfpus_fma\fR" 4
  .IX Item "fpus_fma"
! Enables support for single-precision floating-point and 
  fused multiply and add hardware extensions.
! .IP "\fBfpud_fma\fR" 4
  .IX Item "fpud_fma"
! Enables support for double-precision floating-point and 
  fused multiply and add hardware extensions.  This option
! includes option \fBfpus_fma\fR.  Not available for \s-1ARC EM.\s0
! .IP "\fBfpus_all\fR" 4
  .IX Item "fpus_all"
! Enables support for all single-precision floating-point hardware
  extensions.
! .IP "\fBfpud_all\fR" 4
  .IX Item "fpud_all"
! Enables support for all single\- and double-precision floating-point
! hardware extensions.  Not available for \s-1ARC EM.\s0
  .RE
  .RS 4
  .RE
! .IP "\fB\-mirq\-ctrl\-saved=\fR\fIregister-range\fR\fB,\fR \fIblink\fR\fB,\fR \fIlp_count\fR" 4
  .IX Item "-mirq-ctrl-saved=register-range, blink, lp_count"
! Specifies general-purposes registers that the processor automatically
! saves/restores on interrupt entry and exit.  \fIregister-range\fR is
  specified as two registers separated by a dash.  The register range
  always starts with \f(CW\*(C`r0\*(C'\fR, the upper limit is \f(CW\*(C`fp\*(C'\fR register.
  \&\fIblink\fR and \fIlp_count\fR are optional.  This option is only
! valid for \s-1ARC EM\s0 and \s-1ARC HS\s0 cores.
! .IP "\fB\-mrgf\-banked\-regs=\fR\fInumber\fR" 4
  .IX Item "-mrgf-banked-regs=number"
  Specifies the number of registers replicated in second register bank
  on entry to fast interrupt.  Fast interrupts are interrupts with the
! highest priority level P0.  These interrupts save only \s-1PC\s0 and \s-1STATUS32\s0
  registers to avoid memory transactions during interrupt entry and exit
  sequences.  Use this option when you are using fast interrupts in an
! \&\s-1ARC V2\s0 family processor.  Permitted values are 4, 8, 16, and 32.
! .IP "\fB\-mlpc\-width=\fR\fIwidth\fR" 4
  .IX Item "-mlpc-width=width"
  Specify the width of the \f(CW\*(C`lp_count\*(C'\fR register.  Valid values for
  \&\fIwidth\fR are 8, 16, 20, 24, 28 and 32 bits.  The default width is
  fixed to 32 bits.  If the width is less than 32, the compiler does not
! attempt to transform loops in your program to use the zero-delay loop
  mechanism unless it is known that the \f(CW\*(C`lp_count\*(C'\fR register can
! hold the required loop-counter value.  Depending on the width
! specified, the compiler and run-time library might continue to use the
  loop mechanism for various needs.  This option defines macro
  \&\f(CW\*(C`_\|_ARC_LPC_WIDTH_\|_\*(C'\fR with the value of \fIwidth\fR.
! .IP "\fB\-mrf16\fR" 4
  .IX Item "-mrf16"
  This option instructs the compiler to generate code for a 16\-entry
  register file.  This option defines the \f(CW\*(C`_\|_ARC_RF16_\|_\*(C'\fR
  preprocessor macro.
! .IP "\fB\-mbranch\-index\fR" 4
  .IX Item "-mbranch-index"
  Enable use of \f(CW\*(C`bi\*(C'\fR or \f(CW\*(C`bih\*(C'\fR instructions to implement jump
  tables.
  .PP
  The following options are passed through to the assembler, and also
  define preprocessor macro symbols.
! .IP "\fB\-mdsp\-packa\fR" 4
  .IX Item "-mdsp-packa"
! Passed down to the assembler to enable the \s-1DSP\s0 Pack A extensions.
  Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdsp_packa\*(C'\fR.  This option is
  deprecated.
! .IP "\fB\-mdvbf\fR" 4
  .IX Item "-mdvbf"
  Passed down to the assembler to enable the dual Viterbi butterfly
  extension.  Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdvbf\*(C'\fR.  This
  option is deprecated.
! .IP "\fB\-mlock\fR" 4
  .IX Item "-mlock"
  Passed down to the assembler to enable the locked load/store
  conditional extension.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xlock\*(C'\fR.
! .IP "\fB\-mmac\-d16\fR" 4
  .IX Item "-mmac-d16"
  Passed down to the assembler.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xxmac_d16\*(C'\fR.  This option is deprecated.
! .IP "\fB\-mmac\-24\fR" 4
  .IX Item "-mmac-24"
  Passed down to the assembler.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xxmac_24\*(C'\fR.  This option is deprecated.
! .IP "\fB\-mrtsc\fR" 4
  .IX Item "-mrtsc"
! Passed down to the assembler to enable the 64\-bit time-stamp counter
  extension instruction.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xrtsc\*(C'\fR.  This option is deprecated.
! .IP "\fB\-mswape\fR" 4
  .IX Item "-mswape"
  Passed down to the assembler to enable the swap byte ordering
  extension instruction.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xswape\*(C'\fR.
! .IP "\fB\-mtelephony\fR" 4
  .IX Item "-mtelephony"
! Passed down to the assembler to enable dual\- and single-operand
  instructions for telephony.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xtelephony\*(C'\fR.  This option is deprecated.
! .IP "\fB\-mxy\fR" 4
  .IX Item "-mxy"
! Passed down to the assembler to enable the \s-1XY\s0 memory extension.  Also
  sets the preprocessor symbol \f(CW\*(C`_\|_Xxy\*(C'\fR.
  .PP
  The following options control how the assembly code is annotated:
! .IP "\fB\-misize\fR" 4
  .IX Item "-misize"
  Annotate assembler instructions with estimated addresses.
! .IP "\fB\-mannotate\-align\fR" 4
  .IX Item "-mannotate-align"
  Explain what alignment considerations lead to the decision to make an
  instruction short or long.
  .PP
  The following options are passed through to the linker:
! .IP "\fB\-marclinux\fR" 4
  .IX Item "-marclinux"
  Passed through to the linker, to specify use of the \f(CW\*(C`arclinux\*(C'\fR emulation.
  This option is enabled by default in tool chains built for
  \&\f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets
  when profiling is not requested.
! .IP "\fB\-marclinux_prof\fR" 4
  .IX Item "-marclinux_prof"
  Passed through to the linker, to specify use of the
  \&\f(CW\*(C`arclinux_prof\*(C'\fR emulation.  This option is enabled by default in
--- 20077,20587 ----
  and \fBnone\fR, which means that no register is used for this
  purpose.  The default is \fB\-m1reg\-none\fR.
  .PP
! \fIAMD GCN Options\fR
  .IX Subsection "AMD GCN Options"
  .PP
! These options are defined specifically for the AMD GCN port.
! .IP \fB\-march=\fR\fIgpu\fR 4
  .IX Item "-march=gpu"
  .PD 0
! .IP \fB\-mtune=\fR\fIgpu\fR 4
  .IX Item "-mtune=gpu"
  .PD
  Set architecture type or tuning for \fIgpu\fR. Supported values for \fIgpu\fR
  are
  .RS 4
! .IP \fBfiji\fR 4
  .IX Item "fiji"
! Compile for GCN3 Fiji devices (gfx803).
! .IP \fBgfx900\fR 4
  .IX Item "gfx900"
! Compile for GCN5 Vega 10 devices (gfx900).
! .IP \fBgfx906\fR 4
  .IX Item "gfx906"
! Compile for GCN5 Vega 20 devices (gfx906).
! .IP \fBgfx908\fR 4
  .IX Item "gfx908"
! Compile for CDNA1 Instinct MI100 series devices (gfx908).
! .IP \fBgfx90a\fR 4
  .IX Item "gfx90a"
! Compile for CDNA2 Instinct MI200 series devices (gfx90a).
  .RE
  .RS 4
  .RE
! .IP \fB\-msram\-ecc=on\fR 4
  .IX Item "-msram-ecc=on"
  .PD 0
! .IP \fB\-msram\-ecc=off\fR 4
  .IX Item "-msram-ecc=off"
! .IP \fB\-msram\-ecc=any\fR 4
  .IX Item "-msram-ecc=any"
  .PD
! Compile binaries suitable for devices with the SRAM\-ECC feature enabled,
! disabled, or either mode.  This feature can be enabled per\-process on some
  devices.  The compiled code must match the device mode. The default is
  \&\fBany\fR, for devices that support it.
! .IP \fB\-mstack\-size=\fR\fIbytes\fR 4
  .IX Item "-mstack-size=bytes"
! Specify how many \fIbytes\fR of stack space will be requested for each GPU
! thread (wave\-front).  Beware that there may be many threads and limited memory
  available.  The size of the stack allocation may also have an impact on
! run\-time performance.  The default is 32KB when using OpenACC or OpenMP, and
  1MB otherwise.
! .IP \fB\-mxnack\fR 4
  .IX Item "-mxnack"
! Compile binaries suitable for devices with the XNACK feature enabled.  Some
! devices always require XNACK and some allow the user to configure XNACK.  The
  compiled code must match the device mode.  The default is \fB\-mno\-xnack\fR.
  At present this option is a placeholder for support that is not yet
  implemented.
  .PP
! \fIARC Options\fR
  .IX Subsection "ARC Options"
  .PP
  The following options control the architecture variant for which code
  is being compiled:
! .IP \fB\-mbarrel\-shifter\fR 4
  .IX Item "-mbarrel-shifter"
  Generate instructions supported by barrel shifter.  This is the default
  unless \fB\-mcpu=ARC601\fR or \fB\-mcpu=ARCEM\fR is in effect.
! .IP \fB\-mjli\-always\fR 4
  .IX Item "-mjli-always"
  Force to call a function using jli_s instruction.  This option is
  valid only for ARCv2 architecture.
! .IP \fB\-mcpu=\fR\fIcpu\fR 4
  .IX Item "-mcpu=cpu"
  Set architecture type, register usage, and instruction scheduling
  parameters for \fIcpu\fR.  There are also shortcut alias options
  available for backward compatibility and convenience.  Supported
  values for \fIcpu\fR are
  .RS 4
! .IP \fBarc600\fR 4
  .IX Item "arc600"
! Compile for ARC600.  Aliases: \fB\-mA6\fR, \fB\-mARC600\fR.
! .IP \fBarc601\fR 4
  .IX Item "arc601"
! Compile for ARC601.  Alias: \fB\-mARC601\fR.
! .IP \fBarc700\fR 4
  .IX Item "arc700"
! Compile for ARC700.  Aliases: \fB\-mA7\fR, \fB\-mARC700\fR.
  This is the default when configured with \fB\-\-with\-cpu=arc700\fR.
! .IP \fBarcem\fR 4
  .IX Item "arcem"
! Compile for ARC EM.
! .IP \fBarchs\fR 4
  .IX Item "archs"
! Compile for ARC HS.
! .IP \fBem\fR 4
  .IX Item "em"
! Compile for ARC EM CPU with no hardware extensions.
! .IP \fBem4\fR 4
  .IX Item "em4"
! Compile for ARC EM4 CPU.
! .IP \fBem4_dmips\fR 4
  .IX Item "em4_dmips"
! Compile for ARC EM4 DMIPS CPU.
! .IP \fBem4_fpus\fR 4
  .IX Item "em4_fpus"
! Compile for ARC EM4 DMIPS CPU with the single\-precision floating\-point
  extension.
! .IP \fBem4_fpuda\fR 4
  .IX Item "em4_fpuda"
! Compile for ARC EM4 DMIPS CPU with single\-precision floating\-point and
  double assist instructions.
! .IP \fBhs\fR 4
  .IX Item "hs"
! Compile for ARC HS CPU with no hardware extensions except the atomic
  instructions.
! .IP \fBhs34\fR 4
  .IX Item "hs34"
! Compile for ARC HS34 CPU.
! .IP \fBhs38\fR 4
  .IX Item "hs38"
! Compile for ARC HS38 CPU.
! .IP \fBhs38_linux\fR 4
  .IX Item "hs38_linux"
! Compile for ARC HS38 CPU with all hardware extensions on.
! .IP \fBhs4x\fR 4
  .IX Item "hs4x"
! Compile for ARC HS4x CPU.
! .IP \fBhs4xd\fR 4
  .IX Item "hs4xd"
! Compile for ARC HS4xD CPU.
! .IP \fBhs4x_rel31\fR 4
  .IX Item "hs4x_rel31"
! Compile for ARC HS4x CPU release 3.10a.
! .IP \fBarc600_norm\fR 4
  .IX Item "arc600_norm"
! Compile for ARC 600 CPU with \f(CW\*(C`norm\*(C'\fR instructions enabled.
! .IP \fBarc600_mul32x16\fR 4
  .IX Item "arc600_mul32x16"
! Compile for ARC 600 CPU with \f(CW\*(C`norm\*(C'\fR and 32x16\-bit multiply 
  instructions enabled.
! .IP \fBarc600_mul64\fR 4
  .IX Item "arc600_mul64"
! Compile for ARC 600 CPU with \f(CW\*(C`norm\*(C'\fR and \f(CW\*(C`mul64\*(C'\fR\-family 
  instructions enabled.
! .IP \fBarc601_norm\fR 4
  .IX Item "arc601_norm"
! Compile for ARC 601 CPU with \f(CW\*(C`norm\*(C'\fR instructions enabled.
! .IP \fBarc601_mul32x16\fR 4
  .IX Item "arc601_mul32x16"
! Compile for ARC 601 CPU with \f(CW\*(C`norm\*(C'\fR and 32x16\-bit multiply
  instructions enabled.
! .IP \fBarc601_mul64\fR 4
  .IX Item "arc601_mul64"
! Compile for ARC 601 CPU with \f(CW\*(C`norm\*(C'\fR and \f(CW\*(C`mul64\*(C'\fR\-family
  instructions enabled.
! .IP \fBnps400\fR 4
  .IX Item "nps400"
! Compile for ARC 700 on NPS400 chip.
! .IP \fBem_mini\fR 4
  .IX Item "em_mini"
! Compile for ARC EM minimalist configuration featuring reduced register
  set.
  .RE
  .RS 4
  .RE
! .IP \fB\-mdpfp\fR 4
  .IX Item "-mdpfp"
  .PD 0
! .IP \fB\-mdpfp\-compact\fR 4
  .IX Item "-mdpfp-compact"
  .PD
! Generate double\-precision FPX instructions, tuned for the compact
  implementation.
! .IP \fB\-mdpfp\-fast\fR 4
  .IX Item "-mdpfp-fast"
! Generate double\-precision FPX instructions, tuned for the fast
  implementation.
! .IP \fB\-mno\-dpfp\-lrsr\fR 4
  .IX Item "-mno-dpfp-lrsr"
! Disable \f(CW\*(C`lr\*(C'\fR and \f(CW\*(C`sr\*(C'\fR instructions from using FPX extension
  aux registers.
! .IP \fB\-mea\fR 4
  .IX Item "-mea"
  Generate extended arithmetic instructions.  Currently only
  \&\f(CW\*(C`divaw\*(C'\fR, \f(CW\*(C`adds\*(C'\fR, \f(CW\*(C`subs\*(C'\fR, and \f(CW\*(C`sat16\*(C'\fR are
  supported.  Only valid for \fB\-mcpu=ARC700\fR.
! .IP \fB\-mno\-mpy\fR 4
  .IX Item "-mno-mpy"
! Do not generate \f(CW\*(C`mpy\*(C'\fR\-family instructions for ARC700.  This option is
  deprecated.
! .IP \fB\-mmul32x16\fR 4
  .IX Item "-mmul32x16"
! Generate 32x16\-bit multiply and multiply\-accumulate instructions.
! .IP \fB\-mmul64\fR 4
  .IX Item "-mmul64"
  Generate \f(CW\*(C`mul64\*(C'\fR and \f(CW\*(C`mulu64\*(C'\fR instructions.  
  Only valid for \fB\-mcpu=ARC600\fR.
! .IP \fB\-mnorm\fR 4
  .IX Item "-mnorm"
  Generate \f(CW\*(C`norm\*(C'\fR instructions.  This is the default if \fB\-mcpu=ARC700\fR
  is in effect.
! .IP \fB\-mspfp\fR 4
  .IX Item "-mspfp"
  .PD 0
! .IP \fB\-mspfp\-compact\fR 4
  .IX Item "-mspfp-compact"
  .PD
! Generate single\-precision FPX instructions, tuned for the compact
  implementation.
! .IP \fB\-mspfp\-fast\fR 4
  .IX Item "-mspfp-fast"
! Generate single\-precision FPX instructions, tuned for the fast
  implementation.
! .IP \fB\-msimd\fR 4
  .IX Item "-msimd"
! Enable generation of ARC SIMD instructions via target\-specific
  builtins.  Only valid for \fB\-mcpu=ARC700\fR.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  This option ignored; it is provided for compatibility purposes only.
! Software floating\-point code is emitted by default, and this default
! can overridden by FPX options; \fB\-mspfp\fR, \fB\-mspfp\-compact\fR, or
  \&\fB\-mspfp\-fast\fR for single precision, and \fB\-mdpfp\fR,
  \&\fB\-mdpfp\-compact\fR, or \fB\-mdpfp\-fast\fR for double precision.
! .IP \fB\-mswap\fR 4
  .IX Item "-mswap"
  Generate \f(CW\*(C`swap\*(C'\fR instructions.
! .IP \fB\-matomic\fR 4
  .IX Item "-matomic"
  This enables use of the locked load/store conditional extension to implement
! atomic memory built\-in functions.  Not available for ARC 6xx or ARC
! EM cores.
! .IP \fB\-mdiv\-rem\fR 4
  .IX Item "-mdiv-rem"
  Enable \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`rem\*(C'\fR instructions for ARCv2 cores.
! .IP \fB\-mcode\-density\fR 4
  .IX Item "-mcode-density"
! Enable code density instructions for ARC EM.  
! This option is on by default for ARC HS.
! .IP \fB\-mll64\fR 4
  .IX Item "-mll64"
! Enable double load/store operations for ARC HS cores.
! .IP \fB\-mtp\-regno=\fR\fIregno\fR 4
  .IX Item "-mtp-regno=regno"
  Specify thread pointer register number.
! .IP \fB\-mmpy\-option=\fR\fImulto\fR 4
  .IX Item "-mmpy-option=multo"
  Compile ARCv2 code with a multiplier design option.  You can specify 
  the option using either a string or numeric value for \fImulto\fR.  
  \&\fBwlh1\fR is the default value.  The recognized values are:
  .RS 4
! .IP \fB0\fR 4
  .IX Item "0"
  .PD 0
! .IP \fBnone\fR 4
  .IX Item "none"
  .PD
  No multiplier available.
! .IP \fB1\fR 4
  .IX Item "1"
  .PD 0
! .IP \fBw\fR 4
  .IX Item "w"
  .PD
  16x16 multiplier, fully pipelined.
  The following instructions are enabled: \f(CW\*(C`mpyw\*(C'\fR and \f(CW\*(C`mpyuw\*(C'\fR.
! .IP \fB2\fR 4
  .IX Item "2"
  .PD 0
! .IP \fBwlh1\fR 4
  .IX Item "wlh1"
  .PD
  32x32 multiplier, fully
  pipelined (1 stage).  The following instructions are additionally
  enabled: \f(CW\*(C`mpy\*(C'\fR, \f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP \fB3\fR 4
  .IX Item "3"
  .PD 0
! .IP \fBwlh2\fR 4
  .IX Item "wlh2"
  .PD
  32x32 multiplier, fully pipelined
  (2 stages).  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP \fB4\fR 4
  .IX Item "4"
  .PD 0
! .IP \fBwlh3\fR 4
  .IX Item "wlh3"
  .PD
  Two 16x16 multipliers, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP \fB5\fR 4
  .IX Item "5"
  .PD 0
! .IP \fBwlh4\fR 4
  .IX Item "wlh4"
  .PD
  One 16x16 multiplier, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP \fB6\fR 4
  .IX Item "6"
  .PD 0
! .IP \fBwlh5\fR 4
  .IX Item "wlh5"
  .PD
  One 32x4 multiplier, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP \fB7\fR 4
  .IX Item "7"
  .PD 0
! .IP \fBplus_dmpy\fR 4
  .IX Item "plus_dmpy"
  .PD
! ARC HS SIMD support.
! .IP \fB8\fR 4
  .IX Item "8"
  .PD 0
! .IP \fBplus_macd\fR 4
  .IX Item "plus_macd"
  .PD
! ARC HS SIMD support.
! .IP \fB9\fR 4
  .IX Item "9"
  .PD 0
! .IP \fBplus_qmacw\fR 4
  .IX Item "plus_qmacw"
  .PD
! ARC HS SIMD support.
  .RE
  .RS 4
  .Sp
  This option is only available for ARCv2 cores.
  .RE
! .IP \fB\-mfpu=\fR\fIfpu\fR 4
  .IX Item "-mfpu=fpu"
! Enables support for specific floating\-point hardware extensions for ARCv2
  cores.  Supported values for \fIfpu\fR are:
  .RS 4
! .IP \fBfpus\fR 4
  .IX Item "fpus"
! Enables support for single\-precision floating\-point hardware
  extensions.
! .IP \fBfpud\fR 4
  .IX Item "fpud"
! Enables support for double\-precision floating\-point hardware
! extensions.  The single\-precision floating\-point extension is also
! enabled.  Not available for ARC EM.
! .IP \fBfpuda\fR 4
  .IX Item "fpuda"
! Enables support for double\-precision floating\-point hardware
! extensions using double\-precision assist instructions.  The single\-precision
! floating\-point extension is also enabled.  This option is
! only available for ARC EM.
! .IP \fBfpuda_div\fR 4
  .IX Item "fpuda_div"
! Enables support for double\-precision floating\-point hardware
! extensions using double\-precision assist instructions.
! The single\-precision floating\-point, square\-root, and divide 
  extensions are also enabled.  This option is
! only available for ARC EM.
! .IP \fBfpuda_fma\fR 4
  .IX Item "fpuda_fma"
! Enables support for double\-precision floating\-point hardware
! extensions using double\-precision assist instructions.
! The single\-precision floating\-point and fused multiply and add 
  hardware extensions are also enabled.  This option is
! only available for ARC EM.
! .IP \fBfpuda_all\fR 4
  .IX Item "fpuda_all"
! Enables support for double\-precision floating\-point hardware
! extensions using double\-precision assist instructions.
! All single\-precision floating\-point hardware extensions are also
! enabled.  This option is only available for ARC EM.
! .IP \fBfpus_div\fR 4
  .IX Item "fpus_div"
! Enables support for single\-precision floating\-point, square\-root and divide 
  hardware extensions.
! .IP \fBfpud_div\fR 4
  .IX Item "fpud_div"
! Enables support for double\-precision floating\-point, square\-root and divide 
  hardware extensions.  This option
! includes option \fBfpus_div\fR. Not available for ARC EM.
! .IP \fBfpus_fma\fR 4
  .IX Item "fpus_fma"
! Enables support for single\-precision floating\-point and 
  fused multiply and add hardware extensions.
! .IP \fBfpud_fma\fR 4
  .IX Item "fpud_fma"
! Enables support for double\-precision floating\-point and 
  fused multiply and add hardware extensions.  This option
! includes option \fBfpus_fma\fR.  Not available for ARC EM.
! .IP \fBfpus_all\fR 4
  .IX Item "fpus_all"
! Enables support for all single\-precision floating\-point hardware
  extensions.
! .IP \fBfpud_all\fR 4
  .IX Item "fpud_all"
! Enables support for all single\- and double\-precision floating\-point
! hardware extensions.  Not available for ARC EM.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mirq\-ctrl\-saved=\fR\fIregister\-range\fR\fB,\fR \fIblink\fR\fB,\fR \fIlp_count\fR" 4
  .IX Item "-mirq-ctrl-saved=register-range, blink, lp_count"
! Specifies general\-purposes registers that the processor automatically
! saves/restores on interrupt entry and exit.  \fIregister\-range\fR is
  specified as two registers separated by a dash.  The register range
  always starts with \f(CW\*(C`r0\*(C'\fR, the upper limit is \f(CW\*(C`fp\*(C'\fR register.
  \&\fIblink\fR and \fIlp_count\fR are optional.  This option is only
! valid for ARC EM and ARC HS cores.
! .IP \fB\-mrgf\-banked\-regs=\fR\fInumber\fR 4
  .IX Item "-mrgf-banked-regs=number"
  Specifies the number of registers replicated in second register bank
  on entry to fast interrupt.  Fast interrupts are interrupts with the
! highest priority level P0.  These interrupts save only PC and STATUS32
  registers to avoid memory transactions during interrupt entry and exit
  sequences.  Use this option when you are using fast interrupts in an
! ARC V2 family processor.  Permitted values are 4, 8, 16, and 32.
! .IP \fB\-mlpc\-width=\fR\fIwidth\fR 4
  .IX Item "-mlpc-width=width"
  Specify the width of the \f(CW\*(C`lp_count\*(C'\fR register.  Valid values for
  \&\fIwidth\fR are 8, 16, 20, 24, 28 and 32 bits.  The default width is
  fixed to 32 bits.  If the width is less than 32, the compiler does not
! attempt to transform loops in your program to use the zero\-delay loop
  mechanism unless it is known that the \f(CW\*(C`lp_count\*(C'\fR register can
! hold the required loop\-counter value.  Depending on the width
! specified, the compiler and run\-time library might continue to use the
  loop mechanism for various needs.  This option defines macro
  \&\f(CW\*(C`_\|_ARC_LPC_WIDTH_\|_\*(C'\fR with the value of \fIwidth\fR.
! .IP \fB\-mrf16\fR 4
  .IX Item "-mrf16"
  This option instructs the compiler to generate code for a 16\-entry
  register file.  This option defines the \f(CW\*(C`_\|_ARC_RF16_\|_\*(C'\fR
  preprocessor macro.
! .IP \fB\-mbranch\-index\fR 4
  .IX Item "-mbranch-index"
  Enable use of \f(CW\*(C`bi\*(C'\fR or \f(CW\*(C`bih\*(C'\fR instructions to implement jump
  tables.
  .PP
  The following options are passed through to the assembler, and also
  define preprocessor macro symbols.
! .IP \fB\-mdsp\-packa\fR 4
  .IX Item "-mdsp-packa"
! Passed down to the assembler to enable the DSP Pack A extensions.
  Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdsp_packa\*(C'\fR.  This option is
  deprecated.
! .IP \fB\-mdvbf\fR 4
  .IX Item "-mdvbf"
  Passed down to the assembler to enable the dual Viterbi butterfly
  extension.  Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdvbf\*(C'\fR.  This
  option is deprecated.
! .IP \fB\-mlock\fR 4
  .IX Item "-mlock"
  Passed down to the assembler to enable the locked load/store
  conditional extension.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xlock\*(C'\fR.
! .IP \fB\-mmac\-d16\fR 4
  .IX Item "-mmac-d16"
  Passed down to the assembler.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xxmac_d16\*(C'\fR.  This option is deprecated.
! .IP \fB\-mmac\-24\fR 4
  .IX Item "-mmac-24"
  Passed down to the assembler.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xxmac_24\*(C'\fR.  This option is deprecated.
! .IP \fB\-mrtsc\fR 4
  .IX Item "-mrtsc"
! Passed down to the assembler to enable the 64\-bit time\-stamp counter
  extension instruction.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xrtsc\*(C'\fR.  This option is deprecated.
! .IP \fB\-mswape\fR 4
  .IX Item "-mswape"
  Passed down to the assembler to enable the swap byte ordering
  extension instruction.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xswape\*(C'\fR.
! .IP \fB\-mtelephony\fR 4
  .IX Item "-mtelephony"
! Passed down to the assembler to enable dual\- and single\-operand
  instructions for telephony.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xtelephony\*(C'\fR.  This option is deprecated.
! .IP \fB\-mxy\fR 4
  .IX Item "-mxy"
! Passed down to the assembler to enable the XY memory extension.  Also
  sets the preprocessor symbol \f(CW\*(C`_\|_Xxy\*(C'\fR.
  .PP
  The following options control how the assembly code is annotated:
! .IP \fB\-misize\fR 4
  .IX Item "-misize"
  Annotate assembler instructions with estimated addresses.
! .IP \fB\-mannotate\-align\fR 4
  .IX Item "-mannotate-align"
  Explain what alignment considerations lead to the decision to make an
  instruction short or long.
  .PP
  The following options are passed through to the linker:
! .IP \fB\-marclinux\fR 4
  .IX Item "-marclinux"
  Passed through to the linker, to specify use of the \f(CW\*(C`arclinux\*(C'\fR emulation.
  This option is enabled by default in tool chains built for
  \&\f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets
  when profiling is not requested.
! .IP \fB\-marclinux_prof\fR 4
  .IX Item "-marclinux_prof"
  Passed through to the linker, to specify use of the
  \&\f(CW\*(C`arclinux_prof\*(C'\fR emulation.  This option is enabled by default in
*************** tool chains built for \f(CW\*(C`arc\-lin
*** 20658,20727 ****
  \&\f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets when profiling is requested.
  .PP
  The following options control the semantics of generated code:
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  Generate calls as register indirect calls, thus providing access
  to the full 32\-bit address range.
! .IP "\fB\-mmedium\-calls\fR" 4
  .IX Item "-mmedium-calls"
! Don't use less than 25\-bit addressing range for calls, which is the
! offset available for an unconditional branch-and-link
  instruction.  Conditional execution of function calls is suppressed, to
  allow use of the 25\-bit range, rather than the 21\-bit range with
! conditional branch-and-link.  This is the default for tool chains built
  for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
! Put definitions of externally-visible data in a small data section if
  that data is no bigger than \fInum\fR bytes.  The default value of
! \&\fInum\fR is 4 for any \s-1ARC\s0 configuration, or 8 when we have double
  load/store operations.
! .IP "\fB\-mno\-sdata\fR" 4
  .IX Item "-mno-sdata"
  Do not generate sdata references.  This is the default for tool chains
  built for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR
  targets.
! .IP "\fB\-mvolatile\-cache\fR" 4
  .IX Item "-mvolatile-cache"
  Use ordinarily cached memory accesses for volatile references.  This is the
  default.
! .IP "\fB\-mno\-volatile\-cache\fR" 4
  .IX Item "-mno-volatile-cache"
  Enable cache bypass for volatile references.
  .PP
  The following options fine tune code generation:
! .IP "\fB\-malign\-call\fR" 4
  .IX Item "-malign-call"
  Does nothing.  Preserved for backward compatibility.
! .IP "\fB\-mauto\-modify\-reg\fR" 4
  .IX Item "-mauto-modify-reg"
  Enable the use of pre/post modify with register displacement.
! .IP "\fB\-mbbit\-peephole\fR" 4
  .IX Item "-mbbit-peephole"
  Enable bbit peephole2.
! .IP "\fB\-mno\-brcc\fR" 4
  .IX Item "-mno-brcc"
! This option disables a target-specific pass in \fIarc_reorg\fR to
! generate compare-and-branch (\f(CW\*(C`br\f(CIcc\f(CW\*(C'\fR) instructions.  
  It has no effect on
  generation of these instructions driven by the combiner pass.
! .IP "\fB\-mcase\-vector\-pcrel\fR" 4
  .IX Item "-mcase-vector-pcrel"
! Use PC-relative switch case tables to enable case table shortening.
  This is the default for \fB\-Os\fR.
! .IP "\fB\-mcompact\-casesi\fR" 4
  .IX Item "-mcompact-casesi"
  Enable compact \f(CW\*(C`casesi\*(C'\fR pattern.  This is the default for \fB\-Os\fR,
  and only available for ARCv1 cores.  This option is deprecated.
! .IP "\fB\-mno\-cond\-exec\fR" 4
  .IX Item "-mno-cond-exec"
! Disable the ARCompact-specific pass to generate conditional 
  execution instructions.
  .Sp
  Due to delay slot scheduling and interactions between operand numbers,
  literal sizes, instruction lengths, and the support for conditional execution,
! the target-independent pass to generate conditional execution is often lacking,
! so the \s-1ARC\s0 port has kept a special pass around that tries to find more
  conditional execution generation opportunities after register allocation,
  branch shortening, and delay slot scheduling have been done.  This pass
  generally, but not always, improves performance and code size, at the cost of
--- 20589,20658 ----
  \&\f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets when profiling is requested.
  .PP
  The following options control the semantics of generated code:
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  Generate calls as register indirect calls, thus providing access
  to the full 32\-bit address range.
! .IP \fB\-mmedium\-calls\fR 4
  .IX Item "-mmedium-calls"
! Don\*(Aqt use less than 25\-bit addressing range for calls, which is the
! offset available for an unconditional branch\-and\-link
  instruction.  Conditional execution of function calls is suppressed, to
  allow use of the 25\-bit range, rather than the 21\-bit range with
! conditional branch\-and\-link.  This is the default for tool chains built
  for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
! Put definitions of externally\-visible data in a small data section if
  that data is no bigger than \fInum\fR bytes.  The default value of
! \&\fInum\fR is 4 for any ARC configuration, or 8 when we have double
  load/store operations.
! .IP \fB\-mno\-sdata\fR 4
  .IX Item "-mno-sdata"
  Do not generate sdata references.  This is the default for tool chains
  built for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR
  targets.
! .IP \fB\-mvolatile\-cache\fR 4
  .IX Item "-mvolatile-cache"
  Use ordinarily cached memory accesses for volatile references.  This is the
  default.
! .IP \fB\-mno\-volatile\-cache\fR 4
  .IX Item "-mno-volatile-cache"
  Enable cache bypass for volatile references.
  .PP
  The following options fine tune code generation:
! .IP \fB\-malign\-call\fR 4
  .IX Item "-malign-call"
  Does nothing.  Preserved for backward compatibility.
! .IP \fB\-mauto\-modify\-reg\fR 4
  .IX Item "-mauto-modify-reg"
  Enable the use of pre/post modify with register displacement.
! .IP \fB\-mbbit\-peephole\fR 4
  .IX Item "-mbbit-peephole"
  Enable bbit peephole2.
! .IP \fB\-mno\-brcc\fR 4
  .IX Item "-mno-brcc"
! This option disables a target\-specific pass in \fIarc_reorg\fR to
! generate compare\-and\-branch (\f(CW\*(C`br\fR\f(CIcc\fR\f(CW\*(C'\fR) instructions.  
  It has no effect on
  generation of these instructions driven by the combiner pass.
! .IP \fB\-mcase\-vector\-pcrel\fR 4
  .IX Item "-mcase-vector-pcrel"
! Use PC\-relative switch case tables to enable case table shortening.
  This is the default for \fB\-Os\fR.
! .IP \fB\-mcompact\-casesi\fR 4
  .IX Item "-mcompact-casesi"
  Enable compact \f(CW\*(C`casesi\*(C'\fR pattern.  This is the default for \fB\-Os\fR,
  and only available for ARCv1 cores.  This option is deprecated.
! .IP \fB\-mno\-cond\-exec\fR 4
  .IX Item "-mno-cond-exec"
! Disable the ARCompact\-specific pass to generate conditional 
  execution instructions.
  .Sp
  Due to delay slot scheduling and interactions between operand numbers,
  literal sizes, instruction lengths, and the support for conditional execution,
! the target\-independent pass to generate conditional execution is often lacking,
! so the ARC port has kept a special pass around that tries to find more
  conditional execution generation opportunities after register allocation,
  branch shortening, and delay slot scheduling have been done.  This pass
  generally, but not always, improves performance and code size, at the cost of
*************** extra compilation time, which is why the
*** 20729,20761 ****
  If you have a problem with call instructions exceeding their allowable
  offset range because they are conditionalized, you should consider using
  \&\fB\-mmedium\-calls\fR instead.
! .IP "\fB\-mearly\-cbranchsi\fR" 4
  .IX Item "-mearly-cbranchsi"
! Enable pre-reload use of the \f(CW\*(C`cbranchsi\*(C'\fR pattern.
! .IP "\fB\-mexpand\-adddi\fR" 4
  .IX Item "-mexpand-adddi"
! Expand \f(CW\*(C`adddi3\*(C'\fR and \f(CW\*(C`subdi3\*(C'\fR at \s-1RTL\s0 generation time into
  \&\f(CW\*(C`add.f\*(C'\fR, \f(CW\*(C`adc\*(C'\fR etc.  This option is deprecated.
! .IP "\fB\-mindexed\-loads\fR" 4
  .IX Item "-mindexed-loads"
  Enable the use of indexed loads.  This can be problematic because some
  optimizers then assume that indexed stores exist, which is not
  the case.
! .IP "\fB\-mlra\fR" 4
  .IX Item "-mlra"
! Enable Local Register Allocation.  This is still experimental for \s-1ARC,\s0
  so by default the compiler uses standard reload
  (i.e. \fB\-mno\-lra\fR).
! .IP "\fB\-mlra\-priority\-none\fR" 4
  .IX Item "-mlra-priority-none"
! Don't indicate any priority for target registers.
! .IP "\fB\-mlra\-priority\-compact\fR" 4
  .IX Item "-mlra-priority-compact"
  Indicate target register priority for r0..r3 / r12..r15.
! .IP "\fB\-mlra\-priority\-noncompact\fR" 4
  .IX Item "-mlra-priority-noncompact"
  Reduce target register priority for r0..r3 / r12..r15.
! .IP "\fB\-mmillicode\fR" 4
  .IX Item "-mmillicode"
  When optimizing for size (using \fB\-Os\fR), prologues and epilogues
  that have to save or restore a large number of registers are often
--- 20660,20692 ----
  If you have a problem with call instructions exceeding their allowable
  offset range because they are conditionalized, you should consider using
  \&\fB\-mmedium\-calls\fR instead.
! .IP \fB\-mearly\-cbranchsi\fR 4
  .IX Item "-mearly-cbranchsi"
! Enable pre\-reload use of the \f(CW\*(C`cbranchsi\*(C'\fR pattern.
! .IP \fB\-mexpand\-adddi\fR 4
  .IX Item "-mexpand-adddi"
! Expand \f(CW\*(C`adddi3\*(C'\fR and \f(CW\*(C`subdi3\*(C'\fR at RTL generation time into
  \&\f(CW\*(C`add.f\*(C'\fR, \f(CW\*(C`adc\*(C'\fR etc.  This option is deprecated.
! .IP \fB\-mindexed\-loads\fR 4
  .IX Item "-mindexed-loads"
  Enable the use of indexed loads.  This can be problematic because some
  optimizers then assume that indexed stores exist, which is not
  the case.
! .IP \fB\-mlra\fR 4
  .IX Item "-mlra"
! Enable Local Register Allocation.  This is still experimental for ARC,
  so by default the compiler uses standard reload
  (i.e. \fB\-mno\-lra\fR).
! .IP \fB\-mlra\-priority\-none\fR 4
  .IX Item "-mlra-priority-none"
! Don\*(Aqt indicate any priority for target registers.
! .IP \fB\-mlra\-priority\-compact\fR 4
  .IX Item "-mlra-priority-compact"
  Indicate target register priority for r0..r3 / r12..r15.
! .IP \fB\-mlra\-priority\-noncompact\fR 4
  .IX Item "-mlra-priority-noncompact"
  Reduce target register priority for r0..r3 / r12..r15.
! .IP \fB\-mmillicode\fR 4
  .IX Item "-mmillicode"
  When optimizing for size (using \fB\-Os\fR), prologues and epilogues
  that have to save or restore a large number of registers are often
*************** referred to as a \fImillicode\fR call.
*** 20764,20802 ****
  performance issues, and/or cause linking issues when linking in a
  nonstandard way, this option is provided to turn on or off millicode
  call generation.
! .IP "\fB\-mcode\-density\-frame\fR" 4
  .IX Item "-mcode-density-frame"
  This option enable the compiler to emit \f(CW\*(C`enter\*(C'\fR and \f(CW\*(C`leave\*(C'\fR
  instructions.  These instructions are only valid for CPUs with
! code-density feature.
! .IP "\fB\-mmixed\-code\fR" 4
  .IX Item "-mmixed-code"
  Does nothing.  Preserved for backward compatibility.
! .IP "\fB\-mq\-class\fR" 4
  .IX Item "-mq-class"
  Ths option is deprecated.  Enable \fBq\fR instruction alternatives.
  This is the default for \fB\-Os\fR.
! .IP "\fB\-mRcq\fR" 4
  .IX Item "-mRcq"
  Does nothing.  Preserved for backward compatibility.
! .IP "\fB\-mRcw\fR" 4
  .IX Item "-mRcw"
  Does nothing.  Preserved for backward compatibility.
! .IP "\fB\-msize\-level=\fR\fIlevel\fR" 4
  .IX Item "-msize-level=level"
! Fine-tune size optimization with regards to instruction lengths and alignment.
  The recognized values for \fIlevel\fR are:
  .RS 4
! .IP "\fB0\fR" 4
  .IX Item "0"
  No size optimization.  This level is deprecated and treated like \fB1\fR.
! .IP "\fB1\fR" 4
  .IX Item "1"
  Short instructions are used opportunistically.
! .IP "\fB2\fR" 4
  .IX Item "2"
  In addition, alignment of loops and of code after barriers are dropped.
! .IP "\fB3\fR" 4
  .IX Item "3"
  In addition, optional data alignment is dropped, and the option \fBOs\fR is enabled.
  .RE
--- 20695,20733 ----
  performance issues, and/or cause linking issues when linking in a
  nonstandard way, this option is provided to turn on or off millicode
  call generation.
! .IP \fB\-mcode\-density\-frame\fR 4
  .IX Item "-mcode-density-frame"
  This option enable the compiler to emit \f(CW\*(C`enter\*(C'\fR and \f(CW\*(C`leave\*(C'\fR
  instructions.  These instructions are only valid for CPUs with
! code\-density feature.
! .IP \fB\-mmixed\-code\fR 4
  .IX Item "-mmixed-code"
  Does nothing.  Preserved for backward compatibility.
! .IP \fB\-mq\-class\fR 4
  .IX Item "-mq-class"
  Ths option is deprecated.  Enable \fBq\fR instruction alternatives.
  This is the default for \fB\-Os\fR.
! .IP \fB\-mRcq\fR 4
  .IX Item "-mRcq"
  Does nothing.  Preserved for backward compatibility.
! .IP \fB\-mRcw\fR 4
  .IX Item "-mRcw"
  Does nothing.  Preserved for backward compatibility.
! .IP \fB\-msize\-level=\fR\fIlevel\fR 4
  .IX Item "-msize-level=level"
! Fine\-tune size optimization with regards to instruction lengths and alignment.
  The recognized values for \fIlevel\fR are:
  .RS 4
! .IP \fB0\fR 4
  .IX Item "0"
  No size optimization.  This level is deprecated and treated like \fB1\fR.
! .IP \fB1\fR 4
  .IX Item "1"
  Short instructions are used opportunistically.
! .IP \fB2\fR 4
  .IX Item "2"
  In addition, alignment of loops and of code after barriers are dropped.
! .IP \fB3\fR 4
  .IX Item "3"
  In addition, optional data alignment is dropped, and the option \fBOs\fR is enabled.
  .RE
*************** In addition, optional data alignment is
*** 20805,20993 ****
  This defaults to \fB3\fR when \fB\-Os\fR is in effect.  Otherwise,
  the behavior when this is not set is equivalent to level \fB1\fR.
  .RE
! .IP "\fB\-mtune=\fR\fIcpu\fR" 4
  .IX Item "-mtune=cpu"
  Set instruction scheduling parameters for \fIcpu\fR, overriding any implied
  by \fB\-mcpu=\fR.
  .Sp
  Supported values for \fIcpu\fR are
  .RS 4
! .IP "\fB\s-1ARC600\s0\fR" 4
  .IX Item "ARC600"
! Tune for \s-1ARC600 CPU.\s0
! .IP "\fB\s-1ARC601\s0\fR" 4
  .IX Item "ARC601"
! Tune for \s-1ARC601 CPU.\s0
! .IP "\fB\s-1ARC700\s0\fR" 4
  .IX Item "ARC700"
! Tune for \s-1ARC700 CPU\s0 with standard multiplier block.
! .IP "\fBARC700\-xmac\fR" 4
  .IX Item "ARC700-xmac"
! Tune for \s-1ARC700 CPU\s0 with \s-1XMAC\s0 block.
! .IP "\fB\s-1ARC725D\s0\fR" 4
  .IX Item "ARC725D"
! Tune for \s-1ARC725D CPU.\s0
! .IP "\fB\s-1ARC750D\s0\fR" 4
  .IX Item "ARC750D"
! Tune for \s-1ARC750D CPU.\s0
! .IP "\fBcore3\fR" 4
  .IX Item "core3"
! Tune for ARCv2 core3 type \s-1CPU.\s0  This option enable usage of
  \&\f(CW\*(C`dbnz\*(C'\fR instruction.
! .IP "\fBrelease31a\fR" 4
  .IX Item "release31a"
  Tune for ARC4x release 3.10a.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mmultcost=\fR\fInum\fR" 4
  .IX Item "-mmultcost=num"
  Cost to assume for a multiply instruction, with \fB4\fR being equal to a
  normal instruction.
! .IP "\fB\-munalign\-prob\-threshold=\fR\fIprobability\fR" 4
  .IX Item "-munalign-prob-threshold=probability"
  Does nothing.  Preserved for backward compatibility.
  .PP
  The following options are maintained for backward compatibility, but
  are now deprecated and will be removed in a future release:
! .IP "\fB\-margonaut\fR" 4
  .IX Item "-margonaut"
! Obsolete \s-1FPX.\s0
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
  .PD 0
! .IP "\fB\-EB\fR" 4
  .IX Item "-EB"
  .PD
! Compile code for big-endian targets.  Use of these options is now
! deprecated.  Big-endian code is supported by configuring \s-1GCC\s0 to build
  \&\f(CW\*(C`arceb\-elf32\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets,
  for which big endian is the default.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
  .PD 0
! .IP "\fB\-EL\fR" 4
  .IX Item "-EL"
  .PD
! Compile code for little-endian targets.  Use of these options is now
! deprecated.  Little-endian code is supported by configuring \s-1GCC\s0 to build 
  \&\f(CW\*(C`arc\-elf32\*(C'\fR and \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR targets,
  for which little endian is the default.
! .IP "\fB\-mbarrel_shifter\fR" 4
  .IX Item "-mbarrel_shifter"
  Replaced by \fB\-mbarrel\-shifter\fR.
! .IP "\fB\-mdpfp_compact\fR" 4
  .IX Item "-mdpfp_compact"
  Replaced by \fB\-mdpfp\-compact\fR.
! .IP "\fB\-mdpfp_fast\fR" 4
  .IX Item "-mdpfp_fast"
  Replaced by \fB\-mdpfp\-fast\fR.
! .IP "\fB\-mdsp_packa\fR" 4
  .IX Item "-mdsp_packa"
  Replaced by \fB\-mdsp\-packa\fR.
! .IP "\fB\-mEA\fR" 4
  .IX Item "-mEA"
  Replaced by \fB\-mea\fR.
! .IP "\fB\-mmac_24\fR" 4
  .IX Item "-mmac_24"
  Replaced by \fB\-mmac\-24\fR.
! .IP "\fB\-mmac_d16\fR" 4
  .IX Item "-mmac_d16"
  Replaced by \fB\-mmac\-d16\fR.
! .IP "\fB\-mspfp_compact\fR" 4
  .IX Item "-mspfp_compact"
  Replaced by \fB\-mspfp\-compact\fR.
! .IP "\fB\-mspfp_fast\fR" 4
  .IX Item "-mspfp_fast"
  Replaced by \fB\-mspfp\-fast\fR.
! .IP "\fB\-mtune=\fR\fIcpu\fR" 4
  .IX Item "-mtune=cpu"
  Values \fBarc600\fR, \fBarc601\fR, \fBarc700\fR and
! \&\fBarc700\-xmac\fR for \fIcpu\fR are replaced by \fB\s-1ARC600\s0\fR,
! \&\fB\s-1ARC601\s0\fR, \fB\s-1ARC700\s0\fR and \fBARC700\-xmac\fR respectively.
! .IP "\fB\-multcost=\fR\fInum\fR" 4
  .IX Item "-multcost=num"
  Replaced by \fB\-mmultcost\fR.
  .PP
! \fI\s-1ARM\s0 Options\fR
  .IX Subsection "ARM Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1ARM\s0 port:
! .IP "\fB\-mabi=\fR\fIname\fR" 4
  .IX Item "-mabi=name"
! Generate code for the specified \s-1ABI.\s0  Permissible values are: \fBapcs-gnu\fR,
! \&\fBatpcs\fR, \fBaapcs\fR, \fBaapcs-linux\fR and \fBiwmmxt\fR.
! .IP "\fB\-mapcs\-frame\fR" 4
  .IX Item "-mapcs-frame"
! Generate a stack frame that is compliant with the \s-1ARM\s0 Procedure Call
  Standard for all functions, even if this is not strictly necessary for
  correct execution of the code.  Specifying \fB\-fomit\-frame\-pointer\fR
  with this option causes the stack frames not to be generated for
  leaf functions.  The default is \fB\-mno\-apcs\-frame\fR.
  This option is deprecated.
! .IP "\fB\-mapcs\fR" 4
  .IX Item "-mapcs"
  This is a synonym for \fB\-mapcs\-frame\fR and is deprecated.
! .IP "\fB\-mthumb\-interwork\fR" 4
  .IX Item "-mthumb-interwork"
! Generate code that supports calling between the \s-1ARM\s0 and Thumb
  instruction sets.  Without this option, on pre\-v5 architectures, the
  two instruction sets cannot be reliably used inside one program.  The
  default is \fB\-mno\-thumb\-interwork\fR, since slightly larger code
! is generated when \fB\-mthumb\-interwork\fR is specified.  In \s-1AAPCS\s0
  configurations this option is meaningless.
! .IP "\fB\-mno\-sched\-prolog\fR" 4
  .IX Item "-mno-sched-prolog"
  Prevent the reordering of instructions in the function prologue, or the
! merging of those instruction with the instructions in the function's
  body.  This means that all functions start with a recognizable set
  of instructions (or in fact one of a choice from a small set of
  different function prologues), and this information can be used to
  locate the start of functions inside an executable piece of code.  The
  default is \fB\-msched\-prolog\fR.
! .IP "\fB\-mfloat\-abi=\fR\fIname\fR" 4
  .IX Item "-mfloat-abi=name"
! Specifies which floating-point \s-1ABI\s0 to use.  Permissible values
  are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
  .Sp
! Specifying \fBsoft\fR causes \s-1GCC\s0 to generate output containing
! library calls for floating-point operations.
! \&\fBsoftfp\fR allows the generation of code using hardware floating-point
! instructions, but still uses the soft-float calling conventions.
! \&\fBhard\fR allows generation of floating-point instructions
! and uses FPU-specific calling conventions.
  .Sp
  The default depends on the specific target configuration.  Note that
! the hard-float and soft-float ABIs are not link-compatible; you must
! compile your entire program with the same \s-1ABI,\s0 and link with a
  compatible set of libraries.
! .IP "\fB\-mgeneral\-regs\-only\fR" 4
  .IX Item "-mgeneral-regs-only"
! Generate code which uses only the general-purpose registers.  This will prevent
! the compiler from using floating-point and Advanced \s-1SIMD\s0 registers but will not
  impose any restrictions on the assembler.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code for a processor running in little-endian mode.  This is
  the default for all standard configurations.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code for a processor running in big-endian mode; the default is
! to compile code for a little-endian processor.
! .IP "\fB\-mbe8\fR" 4
  .IX Item "-mbe8"
  .PD 0
! .IP "\fB\-mbe32\fR" 4
  .IX Item "-mbe32"
  .PD
! When linking a big-endian image select between \s-1BE8\s0 and \s-1BE32\s0 formats.
! The option has no effect for little-endian images and is ignored.  The
  default is dependent on the selected target architecture.  For ARMv6
! and later architectures the default is \s-1BE8,\s0 for older architectures
! the default is \s-1BE32.\s0  \s-1BE32\s0 format has been deprecated by \s-1ARM.\s0
! .IP "\fB\-march=\fR\fIname\fR[\fB+extension...\fR]" 4
  .IX Item "-march=name[+extension...]"
! This specifies the name of the target \s-1ARM\s0 architecture.  \s-1GCC\s0 uses this
  name to determine what kind of instructions it can emit when generating
  assembly code.  This option can be used in conjunction with or instead
  of the \fB\-mcpu=\fR option.
--- 20736,20924 ----
  This defaults to \fB3\fR when \fB\-Os\fR is in effect.  Otherwise,
  the behavior when this is not set is equivalent to level \fB1\fR.
  .RE
! .IP \fB\-mtune=\fR\fIcpu\fR 4
  .IX Item "-mtune=cpu"
  Set instruction scheduling parameters for \fIcpu\fR, overriding any implied
  by \fB\-mcpu=\fR.
  .Sp
  Supported values for \fIcpu\fR are
  .RS 4
! .IP \fBARC600\fR 4
  .IX Item "ARC600"
! Tune for ARC600 CPU.
! .IP \fBARC601\fR 4
  .IX Item "ARC601"
! Tune for ARC601 CPU.
! .IP \fBARC700\fR 4
  .IX Item "ARC700"
! Tune for ARC700 CPU with standard multiplier block.
! .IP \fBARC700\-xmac\fR 4
  .IX Item "ARC700-xmac"
! Tune for ARC700 CPU with XMAC block.
! .IP \fBARC725D\fR 4
  .IX Item "ARC725D"
! Tune for ARC725D CPU.
! .IP \fBARC750D\fR 4
  .IX Item "ARC750D"
! Tune for ARC750D CPU.
! .IP \fBcore3\fR 4
  .IX Item "core3"
! Tune for ARCv2 core3 type CPU.  This option enable usage of
  \&\f(CW\*(C`dbnz\*(C'\fR instruction.
! .IP \fBrelease31a\fR 4
  .IX Item "release31a"
  Tune for ARC4x release 3.10a.
  .RE
  .RS 4
  .RE
! .IP \fB\-mmultcost=\fR\fInum\fR 4
  .IX Item "-mmultcost=num"
  Cost to assume for a multiply instruction, with \fB4\fR being equal to a
  normal instruction.
! .IP \fB\-munalign\-prob\-threshold=\fR\fIprobability\fR 4
  .IX Item "-munalign-prob-threshold=probability"
  Does nothing.  Preserved for backward compatibility.
  .PP
  The following options are maintained for backward compatibility, but
  are now deprecated and will be removed in a future release:
! .IP \fB\-margonaut\fR 4
  .IX Item "-margonaut"
! Obsolete FPX.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
  .PD 0
! .IP \fB\-EB\fR 4
  .IX Item "-EB"
  .PD
! Compile code for big\-endian targets.  Use of these options is now
! deprecated.  Big\-endian code is supported by configuring GCC to build
  \&\f(CW\*(C`arceb\-elf32\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets,
  for which big endian is the default.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
  .PD 0
! .IP \fB\-EL\fR 4
  .IX Item "-EL"
  .PD
! Compile code for little\-endian targets.  Use of these options is now
! deprecated.  Little\-endian code is supported by configuring GCC to build 
  \&\f(CW\*(C`arc\-elf32\*(C'\fR and \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR targets,
  for which little endian is the default.
! .IP \fB\-mbarrel_shifter\fR 4
  .IX Item "-mbarrel_shifter"
  Replaced by \fB\-mbarrel\-shifter\fR.
! .IP \fB\-mdpfp_compact\fR 4
  .IX Item "-mdpfp_compact"
  Replaced by \fB\-mdpfp\-compact\fR.
! .IP \fB\-mdpfp_fast\fR 4
  .IX Item "-mdpfp_fast"
  Replaced by \fB\-mdpfp\-fast\fR.
! .IP \fB\-mdsp_packa\fR 4
  .IX Item "-mdsp_packa"
  Replaced by \fB\-mdsp\-packa\fR.
! .IP \fB\-mEA\fR 4
  .IX Item "-mEA"
  Replaced by \fB\-mea\fR.
! .IP \fB\-mmac_24\fR 4
  .IX Item "-mmac_24"
  Replaced by \fB\-mmac\-24\fR.
! .IP \fB\-mmac_d16\fR 4
  .IX Item "-mmac_d16"
  Replaced by \fB\-mmac\-d16\fR.
! .IP \fB\-mspfp_compact\fR 4
  .IX Item "-mspfp_compact"
  Replaced by \fB\-mspfp\-compact\fR.
! .IP \fB\-mspfp_fast\fR 4
  .IX Item "-mspfp_fast"
  Replaced by \fB\-mspfp\-fast\fR.
! .IP \fB\-mtune=\fR\fIcpu\fR 4
  .IX Item "-mtune=cpu"
  Values \fBarc600\fR, \fBarc601\fR, \fBarc700\fR and
! \&\fBarc700\-xmac\fR for \fIcpu\fR are replaced by \fBARC600\fR,
! \&\fBARC601\fR, \fBARC700\fR and \fBARC700\-xmac\fR respectively.
! .IP \fB\-multcost=\fR\fInum\fR 4
  .IX Item "-multcost=num"
  Replaced by \fB\-mmultcost\fR.
  .PP
! \fIARM Options\fR
  .IX Subsection "ARM Options"
  .PP
! These \fB\-m\fR options are defined for the ARM port:
! .IP \fB\-mabi=\fR\fIname\fR 4
  .IX Item "-mabi=name"
! Generate code for the specified ABI.  Permissible values are: \fBapcs\-gnu\fR,
! \&\fBatpcs\fR, \fBaapcs\fR, \fBaapcs\-linux\fR and \fBiwmmxt\fR.
! .IP \fB\-mapcs\-frame\fR 4
  .IX Item "-mapcs-frame"
! Generate a stack frame that is compliant with the ARM Procedure Call
  Standard for all functions, even if this is not strictly necessary for
  correct execution of the code.  Specifying \fB\-fomit\-frame\-pointer\fR
  with this option causes the stack frames not to be generated for
  leaf functions.  The default is \fB\-mno\-apcs\-frame\fR.
  This option is deprecated.
! .IP \fB\-mapcs\fR 4
  .IX Item "-mapcs"
  This is a synonym for \fB\-mapcs\-frame\fR and is deprecated.
! .IP \fB\-mthumb\-interwork\fR 4
  .IX Item "-mthumb-interwork"
! Generate code that supports calling between the ARM and Thumb
  instruction sets.  Without this option, on pre\-v5 architectures, the
  two instruction sets cannot be reliably used inside one program.  The
  default is \fB\-mno\-thumb\-interwork\fR, since slightly larger code
! is generated when \fB\-mthumb\-interwork\fR is specified.  In AAPCS
  configurations this option is meaningless.
! .IP \fB\-mno\-sched\-prolog\fR 4
  .IX Item "-mno-sched-prolog"
  Prevent the reordering of instructions in the function prologue, or the
! merging of those instruction with the instructions in the function\*(Aqs
  body.  This means that all functions start with a recognizable set
  of instructions (or in fact one of a choice from a small set of
  different function prologues), and this information can be used to
  locate the start of functions inside an executable piece of code.  The
  default is \fB\-msched\-prolog\fR.
! .IP \fB\-mfloat\-abi=\fR\fIname\fR 4
  .IX Item "-mfloat-abi=name"
! Specifies which floating\-point ABI to use.  Permissible values
  are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
  .Sp
! Specifying \fBsoft\fR causes GCC to generate output containing
! library calls for floating\-point operations.
! \&\fBsoftfp\fR allows the generation of code using hardware floating\-point
! instructions, but still uses the soft\-float calling conventions.
! \&\fBhard\fR allows generation of floating\-point instructions
! and uses FPU\-specific calling conventions.
  .Sp
  The default depends on the specific target configuration.  Note that
! the hard\-float and soft\-float ABIs are not link\-compatible; you must
! compile your entire program with the same ABI, and link with a
  compatible set of libraries.
! .IP \fB\-mgeneral\-regs\-only\fR 4
  .IX Item "-mgeneral-regs-only"
! Generate code which uses only the general\-purpose registers.  This will prevent
! the compiler from using floating\-point and Advanced SIMD registers but will not
  impose any restrictions on the assembler.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code for a processor running in little\-endian mode.  This is
  the default for all standard configurations.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code for a processor running in big\-endian mode; the default is
! to compile code for a little\-endian processor.
! .IP \fB\-mbe8\fR 4
  .IX Item "-mbe8"
  .PD 0
! .IP \fB\-mbe32\fR 4
  .IX Item "-mbe32"
  .PD
! When linking a big\-endian image select between BE8 and BE32 formats.
! The option has no effect for little\-endian images and is ignored.  The
  default is dependent on the selected target architecture.  For ARMv6
! and later architectures the default is BE8, for older architectures
! the default is BE32.  BE32 format has been deprecated by ARM.
! .IP \fB\-march=\fR\fIname\fR[\fB+extension...\fR] 4
  .IX Item "-march=name[+extension...]"
! 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 \fB\-mcpu=\fR option.
*************** Most extension names are generically nam
*** 21034,21574 ****
  dependent upon the architecture to which it is applied.  For example,
  the \fB+simd\fR option can be applied to both \fBarmv7\-a\fR and
  \&\fBarmv8\-a\fR architectures, but will enable the original ARMv7\-A
! Advanced \s-1SIMD\s0 (Neon) extensions for \fBarmv7\-a\fR and the ARMv8\-A
  variant for \fBarmv8\-a\fR.
  .Sp
  The table below lists the supported extensions for each architecture.
  Architectures not mentioned do not support any extensions.
  .RS 4
! .IP "\fBarmv5te\fR" 4
  .IX Item "armv5te"
  .PD 0
! .IP "\fBarmv6\fR" 4
  .IX Item "armv6"
! .IP "\fBarmv6j\fR" 4
  .IX Item "armv6j"
! .IP "\fBarmv6k\fR" 4
  .IX Item "armv6k"
! .IP "\fBarmv6kz\fR" 4
  .IX Item "armv6kz"
! .IP "\fBarmv6t2\fR" 4
  .IX Item "armv6t2"
! .IP "\fBarmv6z\fR" 4
  .IX Item "armv6z"
! .IP "\fBarmv6zk\fR" 4
  .IX Item "armv6zk"
  .RS 4
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
  .PD
! The VFPv2 floating-point instructions.  The extension \fB+vfpv2\fR can be
  used as an alias for this extension.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv7\fR" 4
  .IX Item "armv7"
  The common subset of the ARMv7\-A, ARMv7\-R and ARMv7\-M architectures.
  .RS 4
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The VFPv3 floating-point instructions, with 16 double-precision
  registers.  The extension \fB+vfpv3\-d16\fR can be used as an alias
! for this extension.  Note that floating-point is not supported by the
  base ARMv7\-M architecture, but is compatible with both the ARMv7\-A and
  ARMv7\-R architectures.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv7\-a\fR" 4
  .IX Item "armv7-a"
  .RS 4
  .PD 0
! .IP "\fB+mp\fR" 4
  .IX Item "+mp"
  .PD
  The multiprocessing extension.
! .IP "\fB+sec\fR" 4
  .IX Item "+sec"
  The security extension.
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The VFPv3 floating-point instructions, with 16 double-precision
  registers.  The extension \fB+vfpv3\-d16\fR can be used as an alias
  for this extension.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The Advanced \s-1SIMD\s0 (Neon) v1 and the VFPv3 floating-point instructions.
  The extensions \fB+neon\fR and \fB+neon\-vfpv3\fR can be used as aliases
  for this extension.
! .IP "\fB+vfpv3\fR" 4
  .IX Item "+vfpv3"
! The VFPv3 floating-point instructions, with 32 double-precision
  registers.
! .IP "\fB+vfpv3\-d16\-fp16\fR" 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating-point instructions, with 16 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+vfpv3\-fp16\fR" 4
  .IX Item "+vfpv3-fp16"
! The VFPv3 floating-point instructions, with 32 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+vfpv4\-d16\fR" 4
  .IX Item "+vfpv4-d16"
! The VFPv4 floating-point instructions, with 16 double-precision
  registers.
! .IP "\fB+vfpv4\fR" 4
  .IX Item "+vfpv4"
! The VFPv4 floating-point instructions, with 32 double-precision
  registers.
! .IP "\fB+neon\-fp16\fR" 4
  .IX Item "+neon-fp16"
! The Advanced \s-1SIMD\s0 (Neon) v1 and the VFPv3 floating-point instructions, with
! the half-precision floating-point conversion operations.
! .IP "\fB+neon\-vfpv4\fR" 4
  .IX Item "+neon-vfpv4"
! The Advanced \s-1SIMD\s0 (Neon) v2 and the VFPv4 floating-point instructions.
! .IP "\fB+nosimd\fR" 4
  .IX Item "+nosimd"
! Disable the Advanced \s-1SIMD\s0 instructions (does not disable floating point).
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point and Advanced \s-1SIMD\s0 instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv7ve\fR" 4
  .IX Item "armv7ve"
  The extended version of the ARMv7\-A architecture with support for
  virtualization.
  .RS 4
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The VFPv4 floating-point instructions, with 16 double-precision registers.
  The extension \fB+vfpv4\-d16\fR can be used as an alias for this extension.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The Advanced \s-1SIMD\s0 (Neon) v2 and the VFPv4 floating-point instructions.  The
  extension \fB+neon\-vfpv4\fR can be used as an alias for this extension.
! .IP "\fB+vfpv3\-d16\fR" 4
  .IX Item "+vfpv3-d16"
! The VFPv3 floating-point instructions, with 16 double-precision
  registers.
! .IP "\fB+vfpv3\fR" 4
  .IX Item "+vfpv3"
! The VFPv3 floating-point instructions, with 32 double-precision
  registers.
! .IP "\fB+vfpv3\-d16\-fp16\fR" 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating-point instructions, with 16 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+vfpv3\-fp16\fR" 4
  .IX Item "+vfpv3-fp16"
! The VFPv3 floating-point instructions, with 32 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+vfpv4\-d16\fR" 4
  .IX Item "+vfpv4-d16"
! The VFPv4 floating-point instructions, with 16 double-precision
  registers.
! .IP "\fB+vfpv4\fR" 4
  .IX Item "+vfpv4"
! The VFPv4 floating-point instructions, with 32 double-precision
  registers.
! .IP "\fB+neon\fR" 4
  .IX Item "+neon"
! The Advanced \s-1SIMD\s0 (Neon) v1 and the VFPv3 floating-point instructions.
  The extension \fB+neon\-vfpv3\fR can be used as an alias for this extension.
! .IP "\fB+neon\-fp16\fR" 4
  .IX Item "+neon-fp16"
! The Advanced \s-1SIMD\s0 (Neon) v1 and the VFPv3 floating-point instructions, with
! the half-precision floating-point conversion operations.
! .IP "\fB+nosimd\fR" 4
  .IX Item "+nosimd"
! Disable the Advanced \s-1SIMD\s0 instructions (does not disable floating point).
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point and Advanced \s-1SIMD\s0 instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8\-a\fR" 4
  .IX Item "armv8-a"
  .RS 4
  .PD 0
! .IP "\fB+crc\fR" 4
  .IX Item "+crc"
  .PD
! The Cyclic Redundancy Check (\s-1CRC\s0) instructions.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8\-A Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
  The cryptographic instructions.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+sb\fR" 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP "\fB+predres\fR" 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.1\-a\fR" 4
  .IX Item "armv8.1-a"
  .RS 4
  .PD 0
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
  .PD
! The ARMv8.1\-A Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced \s-1SIMD\s0 and
! floating-point instructions.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+sb\fR" 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP "\fB+predres\fR" 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.2\-a\fR" 4
  .IX Item "armv8.2-a"
  .PD 0
! .IP "\fBarmv8.3\-a\fR" 4
  .IX Item "armv8.3-a"
  .RS 4
! .IP "\fB+fp16\fR" 4
  .IX Item "+fp16"
  .PD
! The half-precision floating-point data processing instructions.
! This also enables the Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+fp16fml\fR" 4
  .IX Item "+fp16fml"
! The half-precision floating-point fmla extension.  This also enables
! the half-precision floating-point extension and Advanced \s-1SIMD\s0 and
! floating-point instructions.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8.1\-A Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced \s-1SIMD\s0 and
! floating-point instructions.
! .IP "\fB+dotprod\fR" 4
  .IX Item "+dotprod"
! Enable the Dot Product extension.  This also enables Advanced \s-1SIMD\s0 instructions.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+sb\fR" 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP "\fB+predres\fR" 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
! .IP "\fB+i8mm\fR" 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+bf16\fR" 4
  .IX Item "+bf16"
! Brain half-precision floating-point instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.4\-a\fR" 4
  .IX Item "armv8.4-a"
  .RS 4
  .PD 0
! .IP "\fB+fp16\fR" 4
  .IX Item "+fp16"
  .PD
! The half-precision floating-point data processing instructions.
! This also enables the Advanced \s-1SIMD\s0 and floating-point instructions as well
! as the Dot Product extension and the half-precision floating-point fmla
  extension.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced \s-1SIMD\s0 and floating-point instructions as well as the
  Dot Product extension.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced \s-1SIMD\s0 and
! floating-point instructions as well as the Dot Product extension.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+sb\fR" 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP "\fB+predres\fR" 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
! .IP "\fB+i8mm\fR" 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+bf16\fR" 4
  .IX Item "+bf16"
! Brain half-precision floating-point instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.5\-a\fR" 4
  .IX Item "armv8.5-a"
  .RS 4
  .PD 0
! .IP "\fB+fp16\fR" 4
  .IX Item "+fp16"
  .PD
! The half-precision floating-point data processing instructions.
! This also enables the Advanced \s-1SIMD\s0 and floating-point instructions as well
! as the Dot Product extension and the half-precision floating-point fmla
  extension.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced \s-1SIMD\s0 and floating-point instructions as well as the
  Dot Product extension.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced \s-1SIMD\s0 and
! floating-point instructions as well as the Dot Product extension.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+i8mm\fR" 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+bf16\fR" 4
  .IX Item "+bf16"
! Brain half-precision floating-point instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.6\-a\fR" 4
  .IX Item "armv8.6-a"
  .RS 4
  .PD 0
! .IP "\fB+fp16\fR" 4
  .IX Item "+fp16"
  .PD
! The half-precision floating-point data processing instructions.
! This also enables the Advanced \s-1SIMD\s0 and floating-point instructions as well
! as the Dot Product extension and the half-precision floating-point fmla
  extension.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced \s-1SIMD\s0 and floating-point instructions as well as the
  Dot Product extension.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced \s-1SIMD\s0 and
! floating-point instructions as well as the Dot Product extension.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+i8mm\fR" 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+bf16\fR" 4
  .IX Item "+bf16"
! Brain half-precision floating-point instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv7\-r\fR" 4
  .IX Item "armv7-r"
  .RS 4
  .PD 0
! .IP "\fB+fp.sp\fR" 4
  .IX Item "+fp.sp"
  .PD
! The single-precision VFPv3 floating-point instructions.  The extension
  \&\fB+vfpv3xd\fR can be used as an alias for this extension.
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The VFPv3 floating-point instructions with 16 double-precision registers.
  The extension +vfpv3\-d16 can be used as an alias for this extension.
! .IP "\fB+vfpv3xd\-d16\-fp16\fR" 4
  .IX Item "+vfpv3xd-d16-fp16"
! The single-precision VFPv3 floating-point instructions with 16 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+vfpv3\-d16\-fp16\fR" 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating-point instructions with 16 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point extension.
! .IP "\fB+idiv\fR" 4
  .IX Item "+idiv"
! The ARM-state integer division instructions.
! .IP "\fB+noidiv\fR" 4
  .IX Item "+noidiv"
! Disable the ARM-state integer division extension.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv7e\-m\fR" 4
  .IX Item "armv7e-m"
  .RS 4
  .PD 0
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
  .PD
! The single-precision VFPv4 floating-point instructions.
! .IP "\fB+fpv5\fR" 4
  .IX Item "+fpv5"
! The single-precision FPv5 floating-point instructions.
! .IP "\fB+fp.dp\fR" 4
  .IX Item "+fp.dp"
! The single\- and double-precision FPv5 floating-point instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point extensions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.1\-m.main\fR" 4
  .IX Item "armv8.1-m.main"
  .RS 4
  .PD 0
! .IP "\fB+dsp\fR" 4
  .IX Item "+dsp"
  .PD
! The \s-1DSP\s0 instructions.
! .IP "\fB+mve\fR" 4
  .IX Item "+mve"
! The M\-Profile Vector Extension (\s-1MVE\s0) integer instructions.
! .IP "\fB+mve.fp\fR" 4
  .IX Item "+mve.fp"
! The M\-Profile Vector Extension (\s-1MVE\s0) integer and single precision
! floating-point instructions.
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The single-precision floating-point instructions.
! .IP "\fB+fp.dp\fR" 4
  .IX Item "+fp.dp"
! The single\- and double-precision floating-point instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point extension.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (\s-1CDE\s0) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7.
! .IP "\fB+pacbti\fR" 4
  .IX Item "+pacbti"
  Enable the Pointer Authentication and Branch Target Identification Extension.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8\-m.main\fR" 4
  .IX Item "armv8-m.main"
  .RS 4
  .PD 0
! .IP "\fB+dsp\fR" 4
  .IX Item "+dsp"
  .PD
! The \s-1DSP\s0 instructions.
! .IP "\fB+nodsp\fR" 4
  .IX Item "+nodsp"
! Disable the \s-1DSP\s0 extension.
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The single-precision floating-point instructions.
! .IP "\fB+fp.dp\fR" 4
  .IX Item "+fp.dp"
! The single\- and double-precision floating-point instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point extension.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (\s-1CDE\s0) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8\-r\fR" 4
  .IX Item "armv8-r"
  .RS 4
  .PD 0
! .IP "\fB+crc\fR" 4
  .IX Item "+crc"
  .PD
! The Cyclic Redundancy Check (\s-1CRC\s0) instructions.
! .IP "\fB+fp.sp\fR" 4
  .IX Item "+fp.sp"
! The single-precision FPv5 floating-point instructions.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8\-A Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
  The cryptographic instructions.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
  .RE
  .RS 4
  .RE
  .RE
  .RS 4
  .Sp
! \&\fB\-march=native\fR causes the compiler to auto-detect the architecture
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto-detect
  is unsuccessful the option has no effect.
  .RE
! .IP "\fB\-mtune=\fR\fIname\fR" 4
  .IX Item "-mtune=name"
! This option specifies the name of the target \s-1ARM\s0 processor for
! which \s-1GCC\s0 should tune the performance of the code.
! For some \s-1ARM\s0 implementations better performance can be obtained by using
  this option.
  Permissible names are: \fBarm7tdmi\fR, \fBarm7tdmi\-s\fR, \fBarm710t\fR,
  \&\fBarm720t\fR, \fBarm740t\fR, \fBstrongarm\fR, \fBstrongarm110\fR,
--- 20965,21505 ----
  dependent upon the architecture to which it is applied.  For example,
  the \fB+simd\fR option can be applied to both \fBarmv7\-a\fR and
  \&\fBarmv8\-a\fR architectures, but will enable the original ARMv7\-A
! Advanced SIMD (Neon) extensions for \fBarmv7\-a\fR and the ARMv8\-A
  variant for \fBarmv8\-a\fR.
  .Sp
  The table below lists the supported extensions for each architecture.
  Architectures not mentioned do not support any extensions.
  .RS 4
! .IP \fBarmv5te\fR 4
  .IX Item "armv5te"
  .PD 0
! .IP \fBarmv6\fR 4
  .IX Item "armv6"
! .IP \fBarmv6j\fR 4
  .IX Item "armv6j"
! .IP \fBarmv6k\fR 4
  .IX Item "armv6k"
! .IP \fBarmv6kz\fR 4
  .IX Item "armv6kz"
! .IP \fBarmv6t2\fR 4
  .IX Item "armv6t2"
! .IP \fBarmv6z\fR 4
  .IX Item "armv6z"
! .IP \fBarmv6zk\fR 4
  .IX Item "armv6zk"
  .RS 4
! .IP \fB+fp\fR 4
  .IX Item "+fp"
  .PD
! The VFPv2 floating\-point instructions.  The extension \fB+vfpv2\fR can be
  used as an alias for this extension.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv7\fR 4
  .IX Item "armv7"
  The common subset of the ARMv7\-A, ARMv7\-R and ARMv7\-M architectures.
  .RS 4
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The VFPv3 floating\-point instructions, with 16 double\-precision
  registers.  The extension \fB+vfpv3\-d16\fR can be used as an alias
! for this extension.  Note that floating\-point is not supported by the
  base ARMv7\-M architecture, but is compatible with both the ARMv7\-A and
  ARMv7\-R architectures.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv7\-a\fR 4
  .IX Item "armv7-a"
  .RS 4
  .PD 0
! .IP \fB+mp\fR 4
  .IX Item "+mp"
  .PD
  The multiprocessing extension.
! .IP \fB+sec\fR 4
  .IX Item "+sec"
  The security extension.
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The VFPv3 floating\-point instructions, with 16 double\-precision
  registers.  The extension \fB+vfpv3\-d16\fR can be used as an alias
  for this extension.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The Advanced SIMD (Neon) v1 and the VFPv3 floating\-point instructions.
  The extensions \fB+neon\fR and \fB+neon\-vfpv3\fR can be used as aliases
  for this extension.
! .IP \fB+vfpv3\fR 4
  .IX Item "+vfpv3"
! The VFPv3 floating\-point instructions, with 32 double\-precision
  registers.
! .IP \fB+vfpv3\-d16\-fp16\fR 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating\-point instructions, with 16 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+vfpv3\-fp16\fR 4
  .IX Item "+vfpv3-fp16"
! The VFPv3 floating\-point instructions, with 32 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+vfpv4\-d16\fR 4
  .IX Item "+vfpv4-d16"
! The VFPv4 floating\-point instructions, with 16 double\-precision
  registers.
! .IP \fB+vfpv4\fR 4
  .IX Item "+vfpv4"
! The VFPv4 floating\-point instructions, with 32 double\-precision
  registers.
! .IP \fB+neon\-fp16\fR 4
  .IX Item "+neon-fp16"
! The Advanced SIMD (Neon) v1 and the VFPv3 floating\-point instructions, with
! the half\-precision floating\-point conversion operations.
! .IP \fB+neon\-vfpv4\fR 4
  .IX Item "+neon-vfpv4"
! The Advanced SIMD (Neon) v2 and the VFPv4 floating\-point instructions.
! .IP \fB+nosimd\fR 4
  .IX Item "+nosimd"
! Disable the Advanced SIMD instructions (does not disable floating point).
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point and Advanced SIMD instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv7ve\fR 4
  .IX Item "armv7ve"
  The extended version of the ARMv7\-A architecture with support for
  virtualization.
  .RS 4
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The VFPv4 floating\-point instructions, with 16 double\-precision registers.
  The extension \fB+vfpv4\-d16\fR can be used as an alias for this extension.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The Advanced SIMD (Neon) v2 and the VFPv4 floating\-point instructions.  The
  extension \fB+neon\-vfpv4\fR can be used as an alias for this extension.
! .IP \fB+vfpv3\-d16\fR 4
  .IX Item "+vfpv3-d16"
! The VFPv3 floating\-point instructions, with 16 double\-precision
  registers.
! .IP \fB+vfpv3\fR 4
  .IX Item "+vfpv3"
! The VFPv3 floating\-point instructions, with 32 double\-precision
  registers.
! .IP \fB+vfpv3\-d16\-fp16\fR 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating\-point instructions, with 16 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+vfpv3\-fp16\fR 4
  .IX Item "+vfpv3-fp16"
! The VFPv3 floating\-point instructions, with 32 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+vfpv4\-d16\fR 4
  .IX Item "+vfpv4-d16"
! The VFPv4 floating\-point instructions, with 16 double\-precision
  registers.
! .IP \fB+vfpv4\fR 4
  .IX Item "+vfpv4"
! The VFPv4 floating\-point instructions, with 32 double\-precision
  registers.
! .IP \fB+neon\fR 4
  .IX Item "+neon"
! The Advanced SIMD (Neon) v1 and the VFPv3 floating\-point instructions.
  The extension \fB+neon\-vfpv3\fR can be used as an alias for this extension.
! .IP \fB+neon\-fp16\fR 4
  .IX Item "+neon-fp16"
! The Advanced SIMD (Neon) v1 and the VFPv3 floating\-point instructions, with
! the half\-precision floating\-point conversion operations.
! .IP \fB+nosimd\fR 4
  .IX Item "+nosimd"
! Disable the Advanced SIMD instructions (does not disable floating point).
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point and Advanced SIMD instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8\-a\fR 4
  .IX Item "armv8-a"
  .RS 4
  .PD 0
! .IP \fB+crc\fR 4
  .IX Item "+crc"
  .PD
! The Cyclic Redundancy Check (CRC) instructions.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8\-A Advanced SIMD and floating\-point instructions.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
  The cryptographic instructions.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+sb\fR 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP \fB+predres\fR 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.1\-a\fR 4
  .IX Item "armv8.1-a"
  .RS 4
  .PD 0
! .IP \fB+simd\fR 4
  .IX Item "+simd"
  .PD
! The ARMv8.1\-A Advanced SIMD and floating\-point instructions.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced SIMD and
! floating\-point instructions.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+sb\fR 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP \fB+predres\fR 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.2\-a\fR 4
  .IX Item "armv8.2-a"
  .PD 0
! .IP \fBarmv8.3\-a\fR 4
  .IX Item "armv8.3-a"
  .RS 4
! .IP \fB+fp16\fR 4
  .IX Item "+fp16"
  .PD
! The half\-precision floating\-point data processing instructions.
! This also enables the Advanced SIMD and floating\-point instructions.
! .IP \fB+fp16fml\fR 4
  .IX Item "+fp16fml"
! The half\-precision floating\-point fmla extension.  This also enables
! the half\-precision floating\-point extension and Advanced SIMD and
! floating\-point instructions.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8.1\-A Advanced SIMD and floating\-point instructions.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced SIMD and
! floating\-point instructions.
! .IP \fB+dotprod\fR 4
  .IX Item "+dotprod"
! Enable the Dot Product extension.  This also enables Advanced SIMD instructions.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+sb\fR 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP \fB+predres\fR 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
! .IP \fB+i8mm\fR 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced SIMD and floating\-point instructions.
! .IP \fB+bf16\fR 4
  .IX Item "+bf16"
! Brain half\-precision floating\-point instructions.
! This also enables Advanced SIMD and floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.4\-a\fR 4
  .IX Item "armv8.4-a"
  .RS 4
  .PD 0
! .IP \fB+fp16\fR 4
  .IX Item "+fp16"
  .PD
! The half\-precision floating\-point data processing instructions.
! This also enables the Advanced SIMD and floating\-point instructions as well
! as the Dot Product extension and the half\-precision floating\-point fmla
  extension.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced SIMD and floating\-point instructions as well as the
  Dot Product extension.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced SIMD and
! floating\-point instructions as well as the Dot Product extension.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+sb\fR 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP \fB+predres\fR 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
! .IP \fB+i8mm\fR 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced SIMD and floating\-point instructions.
! .IP \fB+bf16\fR 4
  .IX Item "+bf16"
! Brain half\-precision floating\-point instructions.
! This also enables Advanced SIMD and floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.5\-a\fR 4
  .IX Item "armv8.5-a"
  .RS 4
  .PD 0
! .IP \fB+fp16\fR 4
  .IX Item "+fp16"
  .PD
! The half\-precision floating\-point data processing instructions.
! This also enables the Advanced SIMD and floating\-point instructions as well
! as the Dot Product extension and the half\-precision floating\-point fmla
  extension.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced SIMD and floating\-point instructions as well as the
  Dot Product extension.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced SIMD and
! floating\-point instructions as well as the Dot Product extension.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+i8mm\fR 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced SIMD and floating\-point instructions.
! .IP \fB+bf16\fR 4
  .IX Item "+bf16"
! Brain half\-precision floating\-point instructions.
! This also enables Advanced SIMD and floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.6\-a\fR 4
  .IX Item "armv8.6-a"
  .RS 4
  .PD 0
! .IP \fB+fp16\fR 4
  .IX Item "+fp16"
  .PD
! The half\-precision floating\-point data processing instructions.
! This also enables the Advanced SIMD and floating\-point instructions as well
! as the Dot Product extension and the half\-precision floating\-point fmla
  extension.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced SIMD and floating\-point instructions as well as the
  Dot Product extension.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced SIMD and
! floating\-point instructions as well as the Dot Product extension.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+i8mm\fR 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced SIMD and floating\-point instructions.
! .IP \fB+bf16\fR 4
  .IX Item "+bf16"
! Brain half\-precision floating\-point instructions.
! This also enables Advanced SIMD and floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv7\-r\fR 4
  .IX Item "armv7-r"
  .RS 4
  .PD 0
! .IP \fB+fp.sp\fR 4
  .IX Item "+fp.sp"
  .PD
! The single\-precision VFPv3 floating\-point instructions.  The extension
  \&\fB+vfpv3xd\fR can be used as an alias for this extension.
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The VFPv3 floating\-point instructions with 16 double\-precision registers.
  The extension +vfpv3\-d16 can be used as an alias for this extension.
! .IP \fB+vfpv3xd\-d16\-fp16\fR 4
  .IX Item "+vfpv3xd-d16-fp16"
! The single\-precision VFPv3 floating\-point instructions with 16 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+vfpv3\-d16\-fp16\fR 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating\-point instructions with 16 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point extension.
! .IP \fB+idiv\fR 4
  .IX Item "+idiv"
! The ARM\-state integer division instructions.
! .IP \fB+noidiv\fR 4
  .IX Item "+noidiv"
! Disable the ARM\-state integer division extension.
  .RE
  .RS 4
  .RE
! .IP \fBarmv7e\-m\fR 4
  .IX Item "armv7e-m"
  .RS 4
  .PD 0
! .IP \fB+fp\fR 4
  .IX Item "+fp"
  .PD
! The single\-precision VFPv4 floating\-point instructions.
! .IP \fB+fpv5\fR 4
  .IX Item "+fpv5"
! The single\-precision FPv5 floating\-point instructions.
! .IP \fB+fp.dp\fR 4
  .IX Item "+fp.dp"
! The single\- and double\-precision FPv5 floating\-point instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point extensions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.1\-m.main\fR 4
  .IX Item "armv8.1-m.main"
  .RS 4
  .PD 0
! .IP \fB+dsp\fR 4
  .IX Item "+dsp"
  .PD
! The DSP instructions.
! .IP \fB+mve\fR 4
  .IX Item "+mve"
! The M\-Profile Vector Extension (MVE) integer instructions.
! .IP \fB+mve.fp\fR 4
  .IX Item "+mve.fp"
! The M\-Profile Vector Extension (MVE) integer and single precision
! floating\-point instructions.
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The single\-precision floating\-point instructions.
! .IP \fB+fp.dp\fR 4
  .IX Item "+fp.dp"
! The single\- and double\-precision floating\-point instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point extension.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (CDE) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7.
! .IP \fB+pacbti\fR 4
  .IX Item "+pacbti"
  Enable the Pointer Authentication and Branch Target Identification Extension.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8\-m.main\fR 4
  .IX Item "armv8-m.main"
  .RS 4
  .PD 0
! .IP \fB+dsp\fR 4
  .IX Item "+dsp"
  .PD
! The DSP instructions.
! .IP \fB+nodsp\fR 4
  .IX Item "+nodsp"
! Disable the DSP extension.
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The single\-precision floating\-point instructions.
! .IP \fB+fp.dp\fR 4
  .IX Item "+fp.dp"
! The single\- and double\-precision floating\-point instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point extension.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (CDE) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8\-r\fR 4
  .IX Item "armv8-r"
  .RS 4
  .PD 0
! .IP \fB+crc\fR 4
  .IX Item "+crc"
  .PD
! The Cyclic Redundancy Check (CRC) instructions.
! .IP \fB+fp.sp\fR 4
  .IX Item "+fp.sp"
! The single\-precision FPv5 floating\-point instructions.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8\-A Advanced SIMD and floating\-point instructions.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
  The cryptographic instructions.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
  .RE
  .RS 4
  .RE
  .RE
  .RS 4
  .Sp
! \&\fB\-march=native\fR causes the compiler to auto\-detect the architecture
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto\-detect
  is unsuccessful the option has no effect.
  .RE
! .IP \fB\-mtune=\fR\fIname\fR 4
  .IX Item "-mtune=name"
! This option specifies the name of the target ARM processor for
! which GCC should tune the performance of the code.
! For some ARM implementations better performance can be obtained by using
  this option.
  Permissible names are: \fBarm7tdmi\fR, \fBarm7tdmi\-s\fR, \fBarm710t\fR,
  \&\fBarm720t\fR, \fBarm740t\fR, \fBstrongarm\fR, \fBstrongarm110\fR,
*************** Permissible names are: \fBarm7tdmi\fR, \
*** 21597,21628 ****
  \&\fBfa606te\fR, \fBfa626te\fR, \fBfmp626\fR, \fBfa726te\fR, \fBstar\-mc1\fR,
  \&\fBxgene1\fR.
  .Sp
! Additionally, this option can specify that \s-1GCC\s0 should tune the performance
  of the code for a big.LITTLE system.  Permissible names are:
  \&\fBcortex\-a15.cortex\-a7\fR, \fBcortex\-a17.cortex\-a7\fR,
  \&\fBcortex\-a57.cortex\-a53\fR, \fBcortex\-a72.cortex\-a53\fR,
  \&\fBcortex\-a72.cortex\-a35\fR, \fBcortex\-a73.cortex\-a53\fR,
  \&\fBcortex\-a75.cortex\-a55\fR, \fBcortex\-a76.cortex\-a55\fR.
  .Sp
! \&\fB\-mtune=generic\-\fR\fIarch\fR specifies that \s-1GCC\s0 should tune the
  performance for a blend of processors within architecture \fIarch\fR.
  The aim is to generate code that run well on the current most popular
  processors, balancing between optimizations that benefit some CPUs in the
  range, and avoiding performance pitfalls of other CPUs.  The effects of
! this option may change in future \s-1GCC\s0 versions as \s-1CPU\s0 models come and go.
  .Sp
  \&\fB\-mtune\fR permits the same extension options as \fB\-mcpu\fR, but
  the extension options do not affect the tuning of the generated code.
  .Sp
! \&\fB\-mtune=native\fR causes the compiler to auto-detect the \s-1CPU\s0
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto-detect is
  unsuccessful the option has no effect.
! .IP "\fB\-mcpu=\fR\fIname\fR[\fB+extension...\fR]" 4
  .IX Item "-mcpu=name[+extension...]"
! This specifies the name of the target \s-1ARM\s0 processor.  \s-1GCC\s0 uses this name
! to derive the name of the target \s-1ARM\s0 architecture (as if specified
! by \fB\-march\fR) and the \s-1ARM\s0 processor type for which to tune for
  performance (as if specified by \fB\-mtune\fR).  Where this option
  is used in conjunction with \fB\-march\fR or \fB\-mtune\fR,
  those options take precedence over the appropriate part of this option.
--- 21528,21559 ----
  \&\fBfa606te\fR, \fBfa626te\fR, \fBfmp626\fR, \fBfa726te\fR, \fBstar\-mc1\fR,
  \&\fBxgene1\fR.
  .Sp
! Additionally, this option can specify that GCC should tune the performance
  of the code for a big.LITTLE system.  Permissible names are:
  \&\fBcortex\-a15.cortex\-a7\fR, \fBcortex\-a17.cortex\-a7\fR,
  \&\fBcortex\-a57.cortex\-a53\fR, \fBcortex\-a72.cortex\-a53\fR,
  \&\fBcortex\-a72.cortex\-a35\fR, \fBcortex\-a73.cortex\-a53\fR,
  \&\fBcortex\-a75.cortex\-a55\fR, \fBcortex\-a76.cortex\-a55\fR.
  .Sp
! \&\fB\-mtune=generic\-\fR\fIarch\fR specifies that GCC should tune the
  performance for a blend of processors within architecture \fIarch\fR.
  The aim is to generate code that run well on the current most popular
  processors, balancing between optimizations that benefit some CPUs in the
  range, and avoiding performance pitfalls of other CPUs.  The effects of
! this option may change in future GCC versions as CPU models come and go.
  .Sp
  \&\fB\-mtune\fR permits the same extension options as \fB\-mcpu\fR, but
  the extension options do not affect the tuning of the generated code.
  .Sp
! \&\fB\-mtune=native\fR causes the compiler to auto\-detect the CPU
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto\-detect is
  unsuccessful the option has no effect.
! .IP \fB\-mcpu=\fR\fIname\fR[\fB+extension...\fR] 4
  .IX Item "-mcpu=name[+extension...]"
! This specifies the name of the target ARM processor.  GCC uses this name
! to derive the name of the target ARM architecture (as if specified
! by \fB\-march\fR) and the ARM processor type for which to tune for
  performance (as if specified by \fB\-mtune\fR).  Where this option
  is used in conjunction with \fB\-march\fR or \fB\-mtune\fR,
  those options take precedence over the appropriate part of this option.
*************** Many of the supported CPUs implement opt
*** 21631,21649 ****
  extensions.  Where this is so the architectural extensions are
  normally enabled by default.  If implementations that lack the
  extension exist, then the extension syntax can be used to disable
! those extensions that have been omitted.  For floating-point and
! Advanced \s-1SIMD\s0 (Neon) instructions, the settings of the options
  \&\fB\-mfloat\-abi\fR and \fB\-mfpu\fR must also be considered:
! floating-point and Advanced \s-1SIMD\s0 instructions will only be used if
  \&\fB\-mfloat\-abi\fR is not set to \fBsoft\fR; and any setting of
  \&\fB\-mfpu\fR other than \fBauto\fR will override the available
! floating-point and \s-1SIMD\s0 extension instructions.
  .Sp
  For example, \fBcortex\-a9\fR can be found in three major
! configurations: integer only, with just a floating-point unit or with
! floating-point and Advanced \s-1SIMD.\s0  The default is to enable all the
  instructions, but the extensions \fB+nosimd\fR and \fB+nofp\fR can
! be used to disable just the \s-1SIMD\s0 or both the \s-1SIMD\s0 and floating-point
  instructions respectively.
  .Sp
  Permissible names for this option are the same as those for
--- 21562,21580 ----
  extensions.  Where this is so the architectural extensions are
  normally enabled by default.  If implementations that lack the
  extension exist, then the extension syntax can be used to disable
! those extensions that have been omitted.  For floating\-point and
! Advanced SIMD (Neon) instructions, the settings of the options
  \&\fB\-mfloat\-abi\fR and \fB\-mfpu\fR must also be considered:
! floating\-point and Advanced SIMD instructions will only be used if
  \&\fB\-mfloat\-abi\fR is not set to \fBsoft\fR; and any setting of
  \&\fB\-mfpu\fR other than \fBauto\fR will override the available
! floating\-point and SIMD extension instructions.
  .Sp
  For example, \fBcortex\-a9\fR can be found in three major
! configurations: integer only, with just a floating\-point unit or with
! floating\-point and Advanced SIMD.  The default is to enable all the
  instructions, but the extensions \fB+nosimd\fR and \fB+nofp\fR can
! be used to disable just the SIMD or both the SIMD and floating\-point
  instructions respectively.
  .Sp
  Permissible names for this option are the same as those for
*************** Permissible names for this option are th
*** 21651,21704 ****
  .Sp
  The following extension options are common to the listed CPUs:
  .RS 4
! .IP "\fB+nodsp\fR" 4
  .IX Item "+nodsp"
! Disable the \s-1DSP\s0 instructions on \fBcortex\-m33\fR, \fBcortex\-m35p\fR,
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR. Also disable the M\-Profile Vector
! Extension (\s-1MVE\s0) integer and single precision floating-point instructions on
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR.
! .IP "\fB+nopacbti\fR" 4
  .IX Item "+nopacbti"
  Disable the Pointer Authentication and Branch Target Identification Extension
  on \fBcortex\-m85\fR.
! .IP "\fB+nomve\fR" 4
  .IX Item "+nomve"
! Disable the M\-Profile Vector Extension (\s-1MVE\s0) integer and single precision
! floating-point instructions on \fBcortex\-m55\fR and \fBcortex\-m85\fR.
! .IP "\fB+nomve.fp\fR" 4
  .IX Item "+nomve.fp"
! Disable the M\-Profile Vector Extension (\s-1MVE\s0) single precision floating-point
  instructions on \fBcortex\-m55\fR and \fBcortex\-m85\fR.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (\s-1CDE\s0) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7 on \fBcortex\-m55\fR.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disables the floating-point instructions on \fBarm9e\fR,
  \&\fBarm946e\-s\fR, \fBarm966e\-s\fR, \fBarm968e\-s\fR, \fBarm10e\fR,
  \&\fBarm1020e\fR, \fBarm1022e\fR, \fBarm926ej\-s\fR,
  \&\fBarm1026ej\-s\fR, \fBcortex\-r5\fR, \fBcortex\-r7\fR, \fBcortex\-r8\fR,
  \&\fBcortex\-m4\fR, \fBcortex\-m7\fR, \fBcortex\-m33\fR, \fBcortex\-m35p\fR
  \&\fBcortex\-m4\fR, \fBcortex\-m7\fR, \fBcortex\-m33\fR, \fBcortex\-m35p\fR,
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR.
! Disables the floating-point and \s-1SIMD\s0 instructions on
  \&\fBgeneric\-armv7\-a\fR, \fBcortex\-a5\fR, \fBcortex\-a7\fR,
  \&\fBcortex\-a8\fR, \fBcortex\-a9\fR, \fBcortex\-a12\fR,
  \&\fBcortex\-a15\fR, \fBcortex\-a17\fR, \fBcortex\-a15.cortex\-a7\fR,
  \&\fBcortex\-a17.cortex\-a7\fR, \fBcortex\-a32\fR, \fBcortex\-a35\fR,
  \&\fBcortex\-a53\fR and \fBcortex\-a55\fR.
! .IP "\fB+nofp.dp\fR" 4
  .IX Item "+nofp.dp"
! Disables the double-precision component of the floating-point instructions
  on \fBcortex\-r5\fR, \fBcortex\-r7\fR, \fBcortex\-r8\fR, \fBcortex\-r52\fR,
  \&\fBcortex\-r52plus\fR and \fBcortex\-m7\fR.
! .IP "\fB+nosimd\fR" 4
  .IX Item "+nosimd"
! Disables the \s-1SIMD\s0 (but not floating-point) instructions on
  \&\fBgeneric\-armv7\-a\fR, \fBcortex\-a5\fR, \fBcortex\-a7\fR
  and \fBcortex\-a9\fR.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
  Enables the cryptographic instructions on \fBcortex\-a32\fR,
  \&\fBcortex\-a35\fR, \fBcortex\-a53\fR, \fBcortex\-a55\fR, \fBcortex\-a57\fR,
--- 21582,21635 ----
  .Sp
  The following extension options are common to the listed CPUs:
  .RS 4
! .IP \fB+nodsp\fR 4
  .IX Item "+nodsp"
! Disable the DSP instructions on \fBcortex\-m33\fR, \fBcortex\-m35p\fR,
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR. Also disable the M\-Profile Vector
! Extension (MVE) integer and single precision floating\-point instructions on
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR.
! .IP \fB+nopacbti\fR 4
  .IX Item "+nopacbti"
  Disable the Pointer Authentication and Branch Target Identification Extension
  on \fBcortex\-m85\fR.
! .IP \fB+nomve\fR 4
  .IX Item "+nomve"
! Disable the M\-Profile Vector Extension (MVE) integer and single precision
! floating\-point instructions on \fBcortex\-m55\fR and \fBcortex\-m85\fR.
! .IP \fB+nomve.fp\fR 4
  .IX Item "+nomve.fp"
! Disable the M\-Profile Vector Extension (MVE) single precision floating\-point
  instructions on \fBcortex\-m55\fR and \fBcortex\-m85\fR.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (CDE) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7 on \fBcortex\-m55\fR.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disables the floating\-point instructions on \fBarm9e\fR,
  \&\fBarm946e\-s\fR, \fBarm966e\-s\fR, \fBarm968e\-s\fR, \fBarm10e\fR,
  \&\fBarm1020e\fR, \fBarm1022e\fR, \fBarm926ej\-s\fR,
  \&\fBarm1026ej\-s\fR, \fBcortex\-r5\fR, \fBcortex\-r7\fR, \fBcortex\-r8\fR,
  \&\fBcortex\-m4\fR, \fBcortex\-m7\fR, \fBcortex\-m33\fR, \fBcortex\-m35p\fR
  \&\fBcortex\-m4\fR, \fBcortex\-m7\fR, \fBcortex\-m33\fR, \fBcortex\-m35p\fR,
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR.
! Disables the floating\-point and SIMD instructions on
  \&\fBgeneric\-armv7\-a\fR, \fBcortex\-a5\fR, \fBcortex\-a7\fR,
  \&\fBcortex\-a8\fR, \fBcortex\-a9\fR, \fBcortex\-a12\fR,
  \&\fBcortex\-a15\fR, \fBcortex\-a17\fR, \fBcortex\-a15.cortex\-a7\fR,
  \&\fBcortex\-a17.cortex\-a7\fR, \fBcortex\-a32\fR, \fBcortex\-a35\fR,
  \&\fBcortex\-a53\fR and \fBcortex\-a55\fR.
! .IP \fB+nofp.dp\fR 4
  .IX Item "+nofp.dp"
! Disables the double\-precision component of the floating\-point instructions
  on \fBcortex\-r5\fR, \fBcortex\-r7\fR, \fBcortex\-r8\fR, \fBcortex\-r52\fR,
  \&\fBcortex\-r52plus\fR and \fBcortex\-m7\fR.
! .IP \fB+nosimd\fR 4
  .IX Item "+nosimd"
! Disables the SIMD (but not floating\-point) instructions on
  \&\fBgeneric\-armv7\-a\fR, \fBcortex\-a5\fR, \fBcortex\-a7\fR
  and \fBcortex\-a9\fR.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
  Enables the cryptographic instructions on \fBcortex\-a32\fR,
  \&\fBcortex\-a35\fR, \fBcortex\-a53\fR, \fBcortex\-a55\fR, \fBcortex\-a57\fR,
*************** Enables the cryptographic instructions o
*** 21710,21716 ****
  .RS 4
  .Sp
  Additionally the \fBgeneric\-armv7\-a\fR pseudo target defaults to
! VFPv3 with 16 double-precision registers.  It supports the following
  extension options: \fBmp\fR, \fBsec\fR, \fBvfpv3\-d16\fR,
  \&\fBvfpv3\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3\-fp16\fR,
  \&\fBvfpv4\-d16\fR, \fBvfpv4\fR, \fBneon\fR, \fBneon\-vfpv3\fR,
--- 21641,21647 ----
  .RS 4
  .Sp
  Additionally the \fBgeneric\-armv7\-a\fR pseudo target defaults to
! VFPv3 with 16 double\-precision registers.  It supports the following
  extension options: \fBmp\fR, \fBsec\fR, \fBvfpv3\-d16\fR,
  \&\fBvfpv3\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3\-fp16\fR,
  \&\fBvfpv4\-d16\fR, \fBvfpv4\fR, \fBneon\fR, \fBneon\-vfpv3\fR,
*************** the extensions to \fB\-march=armv7\-a\fR
*** 21721,21734 ****
  equivalent to \fB\-march=\fR\fIarch\fR \fB\-mtune=generic\-\fR\fIarch\fR.
  See \fB\-mtune\fR for more information.
  .Sp
! \&\fB\-mcpu=native\fR causes the compiler to auto-detect the \s-1CPU\s0
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto-detect
  is unsuccessful the option has no effect.
  .RE
! .IP "\fB\-mfpu=\fR\fIname\fR" 4
  .IX Item "-mfpu=name"
! This specifies what floating-point hardware (or hardware emulation) is
  available on the target.  Permissible names are: \fBauto\fR, \fBvfpv2\fR,
  \&\fBvfpv3\fR,
  \&\fBvfpv3\-fp16\fR, \fBvfpv3\-d16\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3xd\fR,
--- 21652,21665 ----
  equivalent to \fB\-march=\fR\fIarch\fR \fB\-mtune=generic\-\fR\fIarch\fR.
  See \fB\-mtune\fR for more information.
  .Sp
! \&\fB\-mcpu=native\fR causes the compiler to auto\-detect the CPU
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto\-detect
  is unsuccessful the option has no effect.
  .RE
! .IP \fB\-mfpu=\fR\fIname\fR 4
  .IX Item "-mfpu=name"
! This specifies what floating\-point hardware (or hardware emulation) is
  available on the target.  Permissible names are: \fBauto\fR, \fBvfpv2\fR,
  \&\fBvfpv3\fR,
  \&\fBvfpv3\-fp16\fR, \fBvfpv3\-d16\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3xd\fR,
*************** Note that \fBneon\fR is an alias for \fB
*** 21740,21770 ****
  is an alias for \fBvfpv2\fR.
  .Sp
  The setting \fBauto\fR is the default and is special.  It causes the
! compiler to select the floating-point and Advanced \s-1SIMD\s0 instructions
  based on the settings of \fB\-mcpu\fR and \fB\-march\fR.
  .Sp
! If the selected floating-point hardware includes the \s-1NEON\s0 extension
! (e.g. \fB\-mfpu=neon\fR), note that floating-point
! operations are not generated by \s-1GCC\s0's auto-vectorization pass unless
  \&\fB\-funsafe\-math\-optimizations\fR is also specified.  This is
! because \s-1NEON\s0 hardware does not fully implement the \s-1IEEE 754\s0 standard for
! floating-point arithmetic (in particular denormal values are treated as
! zero), so the use of \s-1NEON\s0 instructions may lead to a loss of precision.
  .Sp
! You can also set the fpu name at function level by using the \f(CW\*(C`target("fpu=")\*(C'\fR function attributes or pragmas.
! .IP "\fB\-mfp16\-format=\fR\fIname\fR" 4
  .IX Item "-mfp16-format=name"
! Specify the format of the \f(CW\*(C`_\|_fp16\*(C'\fR half-precision floating-point type.
  Permissible names are \fBnone\fR, \fBieee\fR, and \fBalternative\fR;
  the default is \fBnone\fR, in which case the \f(CW\*(C`_\|_fp16\*(C'\fR type is not
  defined.
! .IP "\fB\-mstructure\-size\-boundary=\fR\fIn\fR" 4
  .IX Item "-mstructure-size-boundary=n"
  The sizes of all structures and unions are rounded up to a multiple
  of the number of bits set by this option.  Permissible values are 8, 32
! and 64.  The default value varies for different toolchains.  For the \s-1COFF\s0
  targeted toolchain the default value is 8.  A value of 64 is only allowed
! if the underlying \s-1ABI\s0 supports it.
  .Sp
  Specifying a larger number can produce faster, more efficient code, but
  can also increase the size of the program.  Different values are potentially
--- 21671,21701 ----
  is an alias for \fBvfpv2\fR.
  .Sp
  The setting \fBauto\fR is the default and is special.  It causes the
! compiler to select the floating\-point and Advanced SIMD instructions
  based on the settings of \fB\-mcpu\fR and \fB\-march\fR.
  .Sp
! If the selected floating\-point hardware includes the NEON extension
! (e.g. \fB\-mfpu=neon\fR), note that floating\-point
! operations are not generated by GCC\*(Aqs auto\-vectorization pass unless
  \&\fB\-funsafe\-math\-optimizations\fR 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.
  .Sp
! You can also set the fpu name at function level by using the \f(CWtarget("fpu=")\fR function attributes or pragmas.
! .IP \fB\-mfp16\-format=\fR\fIname\fR 4
  .IX Item "-mfp16-format=name"
! Specify the format of the \f(CW\*(C`_\|_fp16\*(C'\fR half\-precision floating\-point type.
  Permissible names are \fBnone\fR, \fBieee\fR, and \fBalternative\fR;
  the default is \fBnone\fR, in which case the \f(CW\*(C`_\|_fp16\*(C'\fR type is not
  defined.
! .IP \fB\-mstructure\-size\-boundary=\fR\fIn\fR 4
  .IX Item "-mstructure-size-boundary=n"
  The sizes of all structures and unions are rounded up to a multiple
  of the number of bits set by this option.  Permissible values are 8, 32
! and 64.  The default value varies for different toolchains.  For the COFF
  targeted toolchain the default value is 8.  A value of 64 is only allowed
! if the underlying ABI supports it.
  .Sp
  Specifying a larger number can produce faster, more efficient code, but
  can also increase the size of the program.  Different values are potentially
*************** work with code or libraries compiled wit
*** 21773,21793 ****
  information using structures or unions.
  .Sp
  This option is deprecated.
! .IP "\fB\-mabort\-on\-noreturn\fR" 4
  .IX Item "-mabort-on-noreturn"
  Generate a call to the function \f(CW\*(C`abort\*(C'\fR at the end of a
  \&\f(CW\*(C`noreturn\*(C'\fR function.  It is executed if the function tries to
  return.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP "\fB\-mno\-long\-calls\fR" 4
  .IX Item "-mno-long-calls"
  .PD
  Tells the compiler to perform function calls by first loading the
  address of the function into a register and then performing a subroutine
  call on this register.  This switch is needed if the target function
! lies outside of the 64\-megabyte addressing range of the offset-based
  version of subroutine call instruction.
  .Sp
  Even if this switch is enabled, not all function calls are turned
--- 21704,21724 ----
  information using structures or unions.
  .Sp
  This option is deprecated.
! .IP \fB\-mabort\-on\-noreturn\fR 4
  .IX Item "-mabort-on-noreturn"
  Generate a call to the function \f(CW\*(C`abort\*(C'\fR at the end of a
  \&\f(CW\*(C`noreturn\*(C'\fR function.  It is executed if the function tries to
  return.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP \fB\-mno\-long\-calls\fR 4
  .IX Item "-mno-long-calls"
  .PD
  Tells the compiler to perform function calls by first loading the
  address of the function into a register and then performing a subroutine
  call on this register.  This switch is needed if the target function
! lies outside of the 64\-megabyte addressing range of the offset\-based
  version of subroutine call instruction.
  .Sp
  Even if this switch is enabled, not all function calls are turned
*************** placing the function calls within the sc
*** 21807,21834 ****
  long_calls_off\*(C'\fR directive.  Note these switches have no effect on how
  the compiler generates code to handle function calls via function
  pointers.
! .IP "\fB\-msingle\-pic\-base\fR" 4
  .IX Item "-msingle-pic-base"
! Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
  loading it in the prologue for each function.  The runtime system is
  responsible for initializing this register with an appropriate value
  before execution begins.
! .IP "\fB\-mpic\-register=\fR\fIreg\fR" 4
  .IX Item "-mpic-register=reg"
! Specify the register to be used for \s-1PIC\s0 addressing.
! For standard \s-1PIC\s0 base case, the default is any suitable register
! determined by compiler.  For single \s-1PIC\s0 base case, the default is
! \&\fBR9\fR if target is \s-1EABI\s0 based or stack-checking is enabled,
  otherwise the default is \fBR10\fR.
! .IP "\fB\-mpic\-data\-is\-text\-relative\fR" 4
  .IX Item "-mpic-data-is-text-relative"
  Assume that the displacement between the text and data segments is fixed
! at static link time.  This permits using PC-relative addressing
  operations to access data known to be in the data segment.  For
! non-VxWorks \s-1RTP\s0 targets, this option is enabled by default.  When
  disabled on such targets, it will enable \fB\-msingle\-pic\-base\fR by
  default.
! .IP "\fB\-mpoke\-function\-name\fR" 4
  .IX Item "-mpoke-function-name"
  Write the name of each function into the text section, directly
  preceding the function prologue.  The generated code is similar to this:
--- 21738,21765 ----
  long_calls_off\*(C'\fR directive.  Note these switches have no effect on how
  the compiler generates code to handle function calls via function
  pointers.
! .IP \fB\-msingle\-pic\-base\fR 4
  .IX Item "-msingle-pic-base"
! Treat the register used for PIC addressing as read\-only, rather than
  loading it in the prologue for each function.  The runtime system is
  responsible for initializing this register with an appropriate value
  before execution begins.
! .IP \fB\-mpic\-register=\fR\fIreg\fR 4
  .IX Item "-mpic-register=reg"
! Specify the register to be used for PIC addressing.
! For standard PIC base case, the default is any suitable register
! determined by compiler.  For single PIC base case, the default is
! \&\fBR9\fR if target is EABI based or stack\-checking is enabled,
  otherwise the default is \fBR10\fR.
! .IP \fB\-mpic\-data\-is\-text\-relative\fR 4
  .IX Item "-mpic-data-is-text-relative"
  Assume that the displacement between the text and data segments is fixed
! at static link time.  This permits using PC\-relative addressing
  operations to access data known to be in the data segment.  For
! non\-VxWorks RTP targets, this option is enabled by default.  When
  disabled on such targets, it will enable \fB\-msingle\-pic\-base\fR by
  default.
! .IP \fB\-mpoke\-function\-name\fR 4
  .IX Item "-mpoke-function-name"
  Write the name of each function into the text section, directly
  preceding the function prologue.  The generated code is similar to this:
*************** When performing a stack backtrace, code
*** 21850,21900 ****
  location \f(CW\*(C`pc \- 12\*(C'\fR and the top 8 bits are set, then we know that
  there is a function name embedded immediately preceding this location
  and has length \f(CW\*(C`((pc[\-3]) & 0xff000000)\*(C'\fR.
! .IP "\fB\-mthumb\fR" 4
  .IX Item "-mthumb"
  .PD 0
! .IP "\fB\-marm\fR" 4
  .IX Item "-marm"
  .PD
! Select between generating code that executes in \s-1ARM\s0 and Thumb
  states.  The default for most configurations is to generate code
! that executes in \s-1ARM\s0 state, but the default can be changed by
! configuring \s-1GCC\s0 with the \fB\-\-with\-mode=\fR\fIstate\fR
  configure option.
  .Sp
! You can also override the \s-1ARM\s0 and Thumb mode for each function
! by using the \f(CW\*(C`target("thumb")\*(C'\fR and \f(CW\*(C`target("arm")\*(C'\fR function attributes or pragmas.
! .IP "\fB\-mflip\-thumb\fR" 4
  .IX Item "-mflip-thumb"
  Switch ARM/Thumb modes on alternating functions.
  This option is provided for regression testing of mixed Thumb/ARM code
  generation, and is not intended for ordinary use in compiling code.
! .IP "\fB\-mtpcs\-frame\fR" 4
  .IX Item "-mtpcs-frame"
  Generate a stack frame that is compliant with the Thumb Procedure Call
! Standard for all non-leaf functions.  (A leaf function is one that does
  not call any other functions.)  The default is \fB\-mno\-tpcs\-frame\fR.
! .IP "\fB\-mtpcs\-leaf\-frame\fR" 4
  .IX Item "-mtpcs-leaf-frame"
  Generate a stack frame that is compliant with the Thumb Procedure Call
  Standard for all leaf functions.  (A leaf function is one that does
  not call any other functions.)  The default is \fB\-mno\-apcs\-leaf\-frame\fR.
! .IP "\fB\-mcallee\-super\-interworking\fR" 4
  .IX Item "-mcallee-super-interworking"
! Gives all externally visible functions in the file being compiled an \s-1ARM\s0
  instruction set header which switches to Thumb mode before executing the
  rest of the function.  This allows these functions to be called from
! non-interworking code.  This option is not valid in \s-1AAPCS\s0 configurations
  because interworking is enabled by default.
! .IP "\fB\-mcaller\-super\-interworking\fR" 4
  .IX Item "-mcaller-super-interworking"
  Allows calls via function pointers (including virtual functions) to
  execute correctly regardless of whether the target code has been
  compiled for interworking or not.  There is a small overhead in the cost
  of executing a function pointer if this option is enabled.  This option
! is not valid in \s-1AAPCS\s0 configurations because interworking is enabled
  by default.
! .IP "\fB\-mtp=\fR\fIname\fR" 4
  .IX Item "-mtp=name"
  Specify the access model for the thread local storage pointer.  The valid
  models are \fBsoft\fR, which generates calls to \f(CW\*(C`_\|_aeabi_read_tp\*(C'\fR,
--- 21781,21831 ----
  location \f(CW\*(C`pc \- 12\*(C'\fR and the top 8 bits are set, then we know that
  there is a function name embedded immediately preceding this location
  and has length \f(CW\*(C`((pc[\-3]) & 0xff000000)\*(C'\fR.
! .IP \fB\-mthumb\fR 4
  .IX Item "-mthumb"
  .PD 0
! .IP \fB\-marm\fR 4
  .IX Item "-marm"
  .PD
! Select between generating code that executes in ARM and Thumb
  states.  The default for most configurations is to generate code
! that executes in ARM state, but the default can be changed by
! configuring GCC with the \fB\-\-with\-mode=\fR\fIstate\fR
  configure option.
  .Sp
! You can also override the ARM and Thumb mode for each function
! by using the \f(CWtarget("thumb")\fR and \f(CWtarget("arm")\fR function attributes or pragmas.
! .IP \fB\-mflip\-thumb\fR 4
  .IX Item "-mflip-thumb"
  Switch ARM/Thumb modes on alternating functions.
  This option is provided for regression testing of mixed Thumb/ARM code
  generation, and is not intended for ordinary use in compiling code.
! .IP \fB\-mtpcs\-frame\fR 4
  .IX Item "-mtpcs-frame"
  Generate a stack frame that is compliant with the Thumb Procedure Call
! Standard for all non\-leaf functions.  (A leaf function is one that does
  not call any other functions.)  The default is \fB\-mno\-tpcs\-frame\fR.
! .IP \fB\-mtpcs\-leaf\-frame\fR 4
  .IX Item "-mtpcs-leaf-frame"
  Generate a stack frame that is compliant with the Thumb Procedure Call
  Standard for all leaf functions.  (A leaf function is one that does
  not call any other functions.)  The default is \fB\-mno\-apcs\-leaf\-frame\fR.
! .IP \fB\-mcallee\-super\-interworking\fR 4
  .IX Item "-mcallee-super-interworking"
! Gives all externally visible functions in the file being compiled an 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.
! .IP \fB\-mcaller\-super\-interworking\fR 4
  .IX Item "-mcaller-super-interworking"
  Allows calls via function pointers (including virtual functions) to
  execute correctly regardless of whether the target code has been
  compiled for interworking or not.  There is a small overhead in the cost
  of executing a function pointer if this option is enabled.  This option
! is not valid in AAPCS configurations because interworking is enabled
  by default.
! .IP \fB\-mtp=\fR\fIname\fR 4
  .IX Item "-mtp=name"
  Specify the access model for the thread local storage pointer.  The valid
  models are \fBsoft\fR, which generates calls to \f(CW\*(C`_\|_aeabi_read_tp\*(C'\fR,
*************** models are \fBsoft\fR, which generates c
*** 21902,21948 ****
  (supported in the arm6k architecture), and \fBauto\fR, which uses the
  best available method for the selected processor.  The default setting is
  \&\fBauto\fR.
! .IP "\fB\-mtls\-dialect=\fR\fIdialect\fR" 4
  .IX Item "-mtls-dialect=dialect"
  Specify the dialect to use for accessing thread local storage.  Two
  \&\fIdialect\fRs are supported\-\-\-\fBgnu\fR and \fBgnu2\fR.  The
! \&\fBgnu\fR dialect selects the original \s-1GNU\s0 scheme for supporting
! local and global dynamic \s-1TLS\s0 models.  The \fBgnu2\fR dialect
! selects the \s-1GNU\s0 descriptor scheme, which provides better performance
! for shared libraries.  The \s-1GNU\s0 descriptor scheme is compatible with
  the original scheme, but does require new assembler, linker and
! library support.  Initial and local exec \s-1TLS\s0 models are unaffected by
  this option and always use the original scheme.
! .IP "\fB\-mword\-relocations\fR" 4
  .IX Item "-mword-relocations"
! Only generate absolute relocations on word-sized values (i.e. R_ARM_ABS32).
  This is enabled by default on targets (uClinux, SymbianOS) where the runtime
  loader imposes this restriction, and when \fB\-fpic\fR or \fB\-fPIC\fR
  is specified. This option conflicts with \fB\-mslow\-flash\-data\fR.
! .IP "\fB\-mfix\-cortex\-m3\-ldrd\fR" 4
  .IX Item "-mfix-cortex-m3-ldrd"
  Some Cortex\-M3 cores can cause data corruption when \f(CW\*(C`ldrd\*(C'\fR instructions
  with overlapping destination and base registers are used.  This option avoids
  generating these instructions.  This option is enabled by default when
  \&\fB\-mcpu=cortex\-m3\fR is specified.
! .IP "\fB\-mfix\-cortex\-a57\-aes\-1742098\fR" 4
  .IX Item "-mfix-cortex-a57-aes-1742098"
  .PD 0
! .IP "\fB\-mno\-fix\-cortex\-a57\-aes\-1742098\fR" 4
  .IX Item "-mno-fix-cortex-a57-aes-1742098"
! .IP "\fB\-mfix\-cortex\-a72\-aes\-1655431\fR" 4
  .IX Item "-mfix-cortex-a72-aes-1655431"
! .IP "\fB\-mno\-fix\-cortex\-a72\-aes\-1655431\fR" 4
  .IX Item "-mno-fix-cortex-a72-aes-1655431"
  .PD
  Enable (disable) mitigation for an erratum on Cortex\-A57 and
! Cortex\-A72 that affects the \s-1AES\s0 cryptographic instructions.  This
  option is enabled by default when either \fB\-mcpu=cortex\-a57\fR or
  \&\fB\-mcpu=cortex\-a72\fR is specified.
! .IP "\fB\-munaligned\-access\fR" 4
  .IX Item "-munaligned-access"
  .PD 0
! .IP "\fB\-mno\-unaligned\-access\fR" 4
  .IX Item "-mno-unaligned-access"
  .PD
  Enables (or disables) reading and writing of 16\- and 32\- bit values
--- 21833,21879 ----
  (supported in the arm6k architecture), and \fBauto\fR, which uses the
  best available method for the selected processor.  The default setting is
  \&\fBauto\fR.
! .IP \fB\-mtls\-dialect=\fR\fIdialect\fR 4
  .IX Item "-mtls-dialect=dialect"
  Specify the dialect to use for accessing thread local storage.  Two
  \&\fIdialect\fRs are supported\-\-\-\fBgnu\fR and \fBgnu2\fR.  The
! \&\fBgnu\fR dialect selects the original GNU scheme for supporting
! local and global dynamic TLS models.  The \fBgnu2\fR dialect
! selects the GNU descriptor scheme, which provides better performance
! for shared libraries.  The GNU descriptor scheme is compatible with
  the original scheme, but does require new assembler, linker and
! library support.  Initial and local exec TLS models are unaffected by
  this option and always use the original scheme.
! .IP \fB\-mword\-relocations\fR 4
  .IX Item "-mword-relocations"
! Only generate absolute relocations on word\-sized values (i.e. R_ARM_ABS32).
  This is enabled by default on targets (uClinux, SymbianOS) where the runtime
  loader imposes this restriction, and when \fB\-fpic\fR or \fB\-fPIC\fR
  is specified. This option conflicts with \fB\-mslow\-flash\-data\fR.
! .IP \fB\-mfix\-cortex\-m3\-ldrd\fR 4
  .IX Item "-mfix-cortex-m3-ldrd"
  Some Cortex\-M3 cores can cause data corruption when \f(CW\*(C`ldrd\*(C'\fR instructions
  with overlapping destination and base registers are used.  This option avoids
  generating these instructions.  This option is enabled by default when
  \&\fB\-mcpu=cortex\-m3\fR is specified.
! .IP \fB\-mfix\-cortex\-a57\-aes\-1742098\fR 4
  .IX Item "-mfix-cortex-a57-aes-1742098"
  .PD 0
! .IP \fB\-mno\-fix\-cortex\-a57\-aes\-1742098\fR 4
  .IX Item "-mno-fix-cortex-a57-aes-1742098"
! .IP \fB\-mfix\-cortex\-a72\-aes\-1655431\fR 4
  .IX Item "-mfix-cortex-a72-aes-1655431"
! .IP \fB\-mno\-fix\-cortex\-a72\-aes\-1655431\fR 4
  .IX Item "-mno-fix-cortex-a72-aes-1655431"
  .PD
  Enable (disable) mitigation for an erratum on Cortex\-A57 and
! Cortex\-A72 that affects the AES cryptographic instructions.  This
  option is enabled by default when either \fB\-mcpu=cortex\-a57\fR or
  \&\fB\-mcpu=cortex\-a72\fR is specified.
! .IP \fB\-munaligned\-access\fR 4
  .IX Item "-munaligned-access"
  .PD 0
! .IP \fB\-mno\-unaligned\-access\fR 4
  .IX Item "-mno-unaligned-access"
  .PD
  Enables (or disables) reading and writing of 16\- and 32\- bit values
*************** ARMv8\-M Baseline architectures, and ena
*** 21952,22044 ****
  architectures.  If unaligned access is not enabled then words in packed
  data structures are accessed a byte at a time.
  .Sp
! The \s-1ARM\s0 attribute \f(CW\*(C`Tag_CPU_unaligned_access\*(C'\fR is set in the
  generated object file to either true or false, depending upon the
  setting of this option.  If unaligned access is enabled then the
  preprocessor symbol \f(CW\*(C`_\|_ARM_FEATURE_UNALIGNED\*(C'\fR is also
  defined.
! .IP "\fB\-mneon\-for\-64bits\fR" 4
  .IX Item "-mneon-for-64bits"
  This option is deprecated and has no effect.
! .IP "\fB\-mslow\-flash\-data\fR" 4
  .IX Item "-mslow-flash-data"
  Assume loading data from flash is slower than fetching instruction.
  Therefore literal load is minimized for better performance.
  This option is only supported when compiling for ARMv7 M\-profile and
  off by default. It conflicts with \fB\-mword\-relocations\fR.
! .IP "\fB\-masm\-syntax\-unified\fR" 4
  .IX Item "-masm-syntax-unified"
  Assume inline assembler is using unified asm syntax.  The default is
  currently off which implies divided syntax.  This option has no impact
! on Thumb2. However, this may change in future releases of \s-1GCC.\s0
  Divided syntax should be considered deprecated.
! .IP "\fB\-mrestrict\-it\fR" 4
  .IX Item "-mrestrict-it"
! Restricts generation of \s-1IT\s0 blocks to conform to the rules of ARMv8\-A.
! \&\s-1IT\s0 blocks can only contain a single 16\-bit instruction from a select
  set of instructions. This option is on by default for ARMv8\-A Thumb mode.
! .IP "\fB\-mprint\-tune\-info\fR" 4
  .IX Item "-mprint-tune-info"
! Print \s-1CPU\s0 tuning information as comment in assembler file.  This is
  an option used only for regression testing of the compiler and not
  intended for ordinary use in compiling code.  This option is disabled
  by default.
! .IP "\fB\-mverbose\-cost\-dump\fR" 4
  .IX Item "-mverbose-cost-dump"
  Enable verbose cost model dumping in the debug dump files.  This option is
  provided for use in debugging the compiler.
! .IP "\fB\-mpure\-code\fR" 4
  .IX Item "-mpure-code"
  Do not allow constant data to be placed in code sections.
! Additionally, when compiling for \s-1ELF\s0 object format give all text sections the
! \&\s-1ELF\s0 processor-specific section attribute \f(CW\*(C`SHF_ARM_PURECODE\*(C'\fR.  This option
! is only available when generating non-pic code for M\-profile targets.
! .IP "\fB\-mcmse\fR" 4
  .IX Item "-mcmse"
! Generate secure code as per the \*(L"ARMv8\-M Security Extensions: Requirements on
! Development Tools Engineering Specification\*(R", which can be found on
  <\fBhttps://developer.arm.com/documentation/ecm0359818/latest/\fR>.
! .IP "\fB\-mfix\-cmse\-cve\-2021\-35465\fR" 4
  .IX Item "-mfix-cmse-cve-2021-35465"
  Mitigate against a potential security issue with the \f(CW\*(C`VLLDM\*(C'\fR instruction
! in some M\-profile devices when using \s-1CMSE\s0 (\s-1CVE\-2021\-365465\s0).  This option is
  enabled by default when the option \fB\-mcpu=\fR is used with
  \&\f(CW\*(C`cortex\-m33\*(C'\fR, \f(CW\*(C`cortex\-m35p\*(C'\fR, \f(CW\*(C`cortex\-m55\*(C'\fR, \f(CW\*(C`cortex\-m85\*(C'\fR
  or \f(CW\*(C`star\-mc1\*(C'\fR. The option \fB\-mno\-fix\-cmse\-cve\-2021\-35465\fR can be used
  to disable the mitigation.
! .IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP "\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR" 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
  locations are \fBglobal\fR for a global canary or \fBtls\fR for a
! canary accessible via the \s-1TLS\s0 register. The option
  \&\fB\-mstack\-protector\-guard\-offset=\fR is for use with
! \&\fB\-fstack\-protector\-guard=tls\fR and not for use in user-land code.
! .IP "\fB\-mfdpic\fR" 4
  .IX Item "-mfdpic"
  .PD 0
! .IP "\fB\-mno\-fdpic\fR" 4
  .IX Item "-mno-fdpic"
  .PD
! Select the \s-1FDPIC ABI,\s0 which uses 64\-bit function descriptors to
  represent pointers to functions.  When the compiler is configured for
  \&\f(CW\*(C`arm\-*\-uclinuxfdpiceabi\*(C'\fR targets, this option is on by default
  and implies \fB\-fPIE\fR if none of the PIC/PIE\-related options is
! provided.  On other targets, it only enables the FDPIC-specific code
  generation features, and the user should explicitly provide the
  PIC/PIE\-related options as needed.
  .Sp
  Note that static linking is not supported because it would still
! involve the dynamic linker when the program self-relocates.  If such
  behavior is acceptable, use \-static and \-Wl,\-dynamic\-linker options.
  .Sp
  The opposite \fB\-mno\-fdpic\fR option is useful (and required) to
  build the Linux kernel using the same (\f(CW\*(C`arm\-*\-uclinuxfdpiceabi\*(C'\fR)
  toolchain as the one used to build the userland programs.
! .IP "\fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR\fB][+\fR\fIbti\fR\fB]|\fR\fIbti\fR\fB[+\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR\fB]]\fR" 4
  .IX Item "-mbranch-protection=none|standard|pac-ret[+leaf][+bti]|bti[+pac-ret[+leaf]]"
  Enable branch protection features (armv8.1\-m.main only).
  \&\fBnone\fR generate code without branch protection or return address
--- 21883,21975 ----
  architectures.  If unaligned access is not enabled then words in packed
  data structures are accessed a byte at a time.
  .Sp
! The ARM attribute \f(CW\*(C`Tag_CPU_unaligned_access\*(C'\fR is set in the
  generated object file to either true or false, depending upon the
  setting of this option.  If unaligned access is enabled then the
  preprocessor symbol \f(CW\*(C`_\|_ARM_FEATURE_UNALIGNED\*(C'\fR is also
  defined.
! .IP \fB\-mneon\-for\-64bits\fR 4
  .IX Item "-mneon-for-64bits"
  This option is deprecated and has no effect.
! .IP \fB\-mslow\-flash\-data\fR 4
  .IX Item "-mslow-flash-data"
  Assume loading data from flash is slower than fetching instruction.
  Therefore literal load is minimized for better performance.
  This option is only supported when compiling for ARMv7 M\-profile and
  off by default. It conflicts with \fB\-mword\-relocations\fR.
! .IP \fB\-masm\-syntax\-unified\fR 4
  .IX Item "-masm-syntax-unified"
  Assume inline assembler is using unified asm syntax.  The default is
  currently off which implies divided syntax.  This option has no impact
! on Thumb2. However, this may change in future releases of GCC.
  Divided syntax should be considered deprecated.
! .IP \fB\-mrestrict\-it\fR 4
  .IX Item "-mrestrict-it"
! Restricts generation of IT blocks to conform to the rules of ARMv8\-A.
! IT blocks can only contain a single 16\-bit instruction from a select
  set of instructions. This option is on by default for ARMv8\-A Thumb mode.
! .IP \fB\-mprint\-tune\-info\fR 4
  .IX Item "-mprint-tune-info"
! Print CPU tuning information as comment in assembler file.  This is
  an option used only for regression testing of the compiler and not
  intended for ordinary use in compiling code.  This option is disabled
  by default.
! .IP \fB\-mverbose\-cost\-dump\fR 4
  .IX Item "-mverbose-cost-dump"
  Enable verbose cost model dumping in the debug dump files.  This option is
  provided for use in debugging the compiler.
! .IP \fB\-mpure\-code\fR 4
  .IX Item "-mpure-code"
  Do not allow constant data to be placed in code sections.
! Additionally, when compiling for ELF object format give all text sections the
! ELF processor\-specific section attribute \f(CW\*(C`SHF_ARM_PURECODE\*(C'\fR.  This option
! is only available when generating non\-pic code for M\-profile targets.
! .IP \fB\-mcmse\fR 4
  .IX Item "-mcmse"
! Generate secure code as per the "ARMv8\-M Security Extensions: Requirements on
! Development Tools Engineering Specification", which can be found on
  <\fBhttps://developer.arm.com/documentation/ecm0359818/latest/\fR>.
! .IP \fB\-mfix\-cmse\-cve\-2021\-35465\fR 4
  .IX Item "-mfix-cmse-cve-2021-35465"
  Mitigate against a potential security issue with the \f(CW\*(C`VLLDM\*(C'\fR instruction
! in some M\-profile devices when using CMSE (CVE\-2021\-365465).  This option is
  enabled by default when the option \fB\-mcpu=\fR is used with
  \&\f(CW\*(C`cortex\-m33\*(C'\fR, \f(CW\*(C`cortex\-m35p\*(C'\fR, \f(CW\*(C`cortex\-m55\*(C'\fR, \f(CW\*(C`cortex\-m85\*(C'\fR
  or \f(CW\*(C`star\-mc1\*(C'\fR. The option \fB\-mno\-fix\-cmse\-cve\-2021\-35465\fR can be used
  to disable the mitigation.
! .IP \fB\-mstack\-protector\-guard=\fR\fIguard\fR 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
  locations are \fBglobal\fR for a global canary or \fBtls\fR for a
! canary accessible via the TLS register. The option
  \&\fB\-mstack\-protector\-guard\-offset=\fR is for use with
! \&\fB\-fstack\-protector\-guard=tls\fR and not for use in user\-land code.
! .IP \fB\-mfdpic\fR 4
  .IX Item "-mfdpic"
  .PD 0
! .IP \fB\-mno\-fdpic\fR 4
  .IX Item "-mno-fdpic"
  .PD
! Select the FDPIC ABI, which uses 64\-bit function descriptors to
  represent pointers to functions.  When the compiler is configured for
  \&\f(CW\*(C`arm\-*\-uclinuxfdpiceabi\*(C'\fR targets, this option is on by default
  and implies \fB\-fPIE\fR if none of the PIC/PIE\-related options is
! provided.  On other targets, it only enables the FDPIC\-specific code
  generation features, and the user should explicitly provide the
  PIC/PIE\-related options as needed.
  .Sp
  Note that static linking is not supported because it would still
! involve the dynamic linker when the program self\-relocates.  If such
  behavior is acceptable, use \-static and \-Wl,\-dynamic\-linker options.
  .Sp
  The opposite \fB\-mno\-fdpic\fR option is useful (and required) to
  build the Linux kernel using the same (\f(CW\*(C`arm\-*\-uclinuxfdpiceabi\*(C'\fR)
  toolchain as the one used to build the userland programs.
! .IP \fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR\fB][+\fR\fIbti\fR\fB]|\fR\fIbti\fR\fB[+\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR\fB]]\fR 4
  .IX Item "-mbranch-protection=none|standard|pac-ret[+leaf][+bti]|bti[+pac-ret[+leaf]]"
  Enable branch protection features (armv8.1\-m.main only).
  \&\fBnone\fR generate code without branch protection or return address
*************** set to its standard level, which is to s
*** 22050,22067 ****
  the return address to memory.
  \&\fBleaf\fR When return address signing is enabled, also sign leaf
  functions even if they do not write the return address to memory.
! +\fBbti\fR Add landing-pad instructions at the permitted targets of
  indirect branch instructions.
  .Sp
  If the \fB+pacbti\fR architecture extension is not enabled, then all
  branch protection and return address signing operations are
  constrained to use only the instructions defined in the
! architectural-NOP space. The generated code will remain
! backwards-compatible with earlier versions of the architecture, but
  the additional security can be enabled at run time on processors that
! support the \fB\s-1PACBTI\s0\fR extension.
  .Sp
! Branch target enforcement using \s-1BTI\s0 can only be enabled at runtime if
  all code in the application has been compiled with at least
  \&\fB\-mbranch\-protection=bti\fR.
  .Sp
--- 21981,21998 ----
  the return address to memory.
  \&\fBleaf\fR When return address signing is enabled, also sign leaf
  functions even if they do not write the return address to memory.
! +\fBbti\fR Add landing\-pad instructions at the permitted targets of
  indirect branch instructions.
  .Sp
  If the \fB+pacbti\fR architecture extension is not enabled, then all
  branch protection and return address signing operations are
  constrained to use only the instructions defined in the
! architectural\-NOP space. The generated code will remain
! backwards\-compatible with earlier versions of the architecture, but
  the additional security can be enabled at run time on processors that
! support the \fBPACBTI\fR extension.
  .Sp
! Branch target enforcement using BTI can only be enabled at runtime if
  all code in the application has been compiled with at least
  \&\fB\-mbranch\-protection=bti\fR.
  .Sp
*************** or later.
*** 22071,22191 ****
  The default is to generate code without branch protection or return
  address signing.
  .PP
! \fI\s-1AVR\s0 Options\fR
  .IX Subsection "AVR Options"
  .PP
! These options are defined for \s-1AVR\s0 implementations:
! .IP "\fB\-mmcu=\fR\fImcu\fR" 4
  .IX Item "-mmcu=mcu"
! Specify the \s-1AVR\s0 instruction set architecture (\s-1ISA\s0) or device type.
  The default for this option is \f(CW\*(C`avr2\*(C'\fR.
  .Sp
! The following \s-1AVR\s0 devices and ISAs are supported.
  \&\fINote:\fR A complete device support consists of
! startup code \f(CW\*(C`crt\f(CImcu\f(CW.o\*(C'\fR, a device header \f(CW\*(C`avr/io*.h\*(C'\fR,
! a device library \f(CW\*(C`lib\f(CImcu\f(CW.a\*(C'\fR and a
! device-specs (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#spec\-files\*(C'\fR) file
! \&\f(CW\*(C`specs\-\f(CImcu\f(CW\*(C'\fR. Only the latter is provided by the compiler
! according the supported \f(CW\*(C`\f(CImcu\f(CW\*(C'\fRs below.  The rest is supported
! by AVR-LibC (\f(CW\*(C`https://www.nongnu.org/avr\-libc/\*(C'\fR), or by means of
  \&\f(CW\*(C`atpack\*(C'\fR (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#atpack\*(C'\fR) files
  from the hardware manufacturer.
  .RS 4
  .ie n .IP """avr2""" 4
! .el .IP "\f(CWavr2\fR" 4
  .IX Item "avr2"
! \&\*(L"Classic\*(R" devices with up to 8 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`attiny22\*(C'\fR, \f(CW\*(C`attiny26\*(C'\fR, \f(CW\*(C`at90s2313\*(C'\fR, \f(CW\*(C`at90s2323\*(C'\fR, \f(CW\*(C`at90s2333\*(C'\fR, \f(CW\*(C`at90s2343\*(C'\fR, \f(CW\*(C`at90s4414\*(C'\fR, \f(CW\*(C`at90s4433\*(C'\fR, \f(CW\*(C`at90s4434\*(C'\fR, \f(CW\*(C`at90c8534\*(C'\fR, \f(CW\*(C`at90s8515\*(C'\fR, \f(CW\*(C`at90s8535\*(C'\fR.
  .ie n .IP """avr25""" 4
! .el .IP "\f(CWavr25\fR" 4
  .IX Item "avr25"
! \&\*(L"Classic\*(R" devices with up to 8 KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
  \&\fImcu\fR = \f(CW\*(C`attiny13\*(C'\fR, \f(CW\*(C`attiny13a\*(C'\fR, \f(CW\*(C`attiny24\*(C'\fR, \f(CW\*(C`attiny24a\*(C'\fR, \f(CW\*(C`attiny25\*(C'\fR, \f(CW\*(C`attiny261\*(C'\fR, \f(CW\*(C`attiny261a\*(C'\fR, \f(CW\*(C`attiny2313\*(C'\fR, \f(CW\*(C`attiny2313a\*(C'\fR, \f(CW\*(C`attiny43u\*(C'\fR, \f(CW\*(C`attiny44\*(C'\fR, \f(CW\*(C`attiny44a\*(C'\fR, \f(CW\*(C`attiny45\*(C'\fR, \f(CW\*(C`attiny48\*(C'\fR, \f(CW\*(C`attiny441\*(C'\fR, \f(CW\*(C`attiny461\*(C'\fR, \f(CW\*(C`attiny461a\*(C'\fR, \f(CW\*(C`attiny4313\*(C'\fR, \f(CW\*(C`attiny84\*(C'\fR, \f(CW\*(C`attiny84a\*(C'\fR, \f(CW\*(C`attiny85\*(C'\fR, \f(CW\*(C`attiny87\*(C'\fR, \f(CW\*(C`attiny88\*(C'\fR, \f(CW\*(C`attiny828\*(C'\fR, \f(CW\*(C`attiny841\*(C'\fR, \f(CW\*(C`attiny861\*(C'\fR, \f(CW\*(C`attiny861a\*(C'\fR, \f(CW\*(C`ata5272\*(C'\fR, \f(CW\*(C`ata6616c\*(C'\fR, \f(CW\*(C`at86rf401\*(C'\fR.
  .ie n .IP """avr3""" 4
! .el .IP "\f(CWavr3\fR" 4
  .IX Item "avr3"
! \&\*(L"Classic\*(R" devices with 16 KiB up to 64 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`at76c711\*(C'\fR, \f(CW\*(C`at43usb355\*(C'\fR.
  .ie n .IP """avr31""" 4
! .el .IP "\f(CWavr31\fR" 4
  .IX Item "avr31"
! \&\*(L"Classic\*(R" devices with 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega103\*(C'\fR, \f(CW\*(C`at43usb320\*(C'\fR.
  .ie n .IP """avr35""" 4
! .el .IP "\f(CWavr35\fR" 4
  .IX Item "avr35"
! \&\*(L"Classic\*(R" devices with 16 KiB up to 64 KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
  \&\fImcu\fR = \f(CW\*(C`attiny167\*(C'\fR, \f(CW\*(C`attiny1634\*(C'\fR, \f(CW\*(C`atmega8u2\*(C'\fR, \f(CW\*(C`atmega16u2\*(C'\fR, \f(CW\*(C`atmega32u2\*(C'\fR, \f(CW\*(C`ata5505\*(C'\fR, \f(CW\*(C`ata6617c\*(C'\fR, \f(CW\*(C`ata664251\*(C'\fR, \f(CW\*(C`at90usb82\*(C'\fR, \f(CW\*(C`at90usb162\*(C'\fR.
  .ie n .IP """avr4""" 4
! .el .IP "\f(CWavr4\fR" 4
  .IX Item "avr4"
! \&\*(L"Enhanced\*(R" devices with up to 8 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega48\*(C'\fR, \f(CW\*(C`atmega48a\*(C'\fR, \f(CW\*(C`atmega48p\*(C'\fR, \f(CW\*(C`atmega48pa\*(C'\fR, \f(CW\*(C`atmega48pb\*(C'\fR, \f(CW\*(C`atmega8\*(C'\fR, \f(CW\*(C`atmega8a\*(C'\fR, \f(CW\*(C`atmega8hva\*(C'\fR, \f(CW\*(C`atmega88\*(C'\fR, \f(CW\*(C`atmega88a\*(C'\fR, \f(CW\*(C`atmega88p\*(C'\fR, \f(CW\*(C`atmega88pa\*(C'\fR, \f(CW\*(C`atmega88pb\*(C'\fR, \f(CW\*(C`atmega8515\*(C'\fR, \f(CW\*(C`atmega8535\*(C'\fR, \f(CW\*(C`ata5795\*(C'\fR, \f(CW\*(C`ata6285\*(C'\fR, \f(CW\*(C`ata6286\*(C'\fR, \f(CW\*(C`ata6289\*(C'\fR, \f(CW\*(C`ata6612c\*(C'\fR, \f(CW\*(C`at90pwm1\*(C'\fR, \f(CW\*(C`at90pwm2\*(C'\fR, \f(CW\*(C`at90pwm2b\*(C'\fR, \f(CW\*(C`at90pwm3\*(C'\fR, \f(CW\*(C`at90pwm3b\*(C'\fR, \f(CW\*(C`at90pwm81\*(C'\fR.
  .ie n .IP """avr5""" 4
! .el .IP "\f(CWavr5\fR" 4
  .IX Item "avr5"
! \&\*(L"Enhanced\*(R" devices with 16 KiB up to 64 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega16\*(C'\fR, \f(CW\*(C`atmega16a\*(C'\fR, \f(CW\*(C`atmega16hva\*(C'\fR, \f(CW\*(C`atmega16hva2\*(C'\fR, \f(CW\*(C`atmega16hvb\*(C'\fR, \f(CW\*(C`atmega16hvbrevb\*(C'\fR, \f(CW\*(C`atmega16m1\*(C'\fR, \f(CW\*(C`atmega16u4\*(C'\fR, \f(CW\*(C`atmega161\*(C'\fR, \f(CW\*(C`atmega162\*(C'\fR, \f(CW\*(C`atmega163\*(C'\fR, \f(CW\*(C`atmega164a\*(C'\fR, \f(CW\*(C`atmega164p\*(C'\fR, \f(CW\*(C`atmega164pa\*(C'\fR, \f(CW\*(C`atmega165\*(C'\fR, \f(CW\*(C`atmega165a\*(C'\fR, \f(CW\*(C`atmega165p\*(C'\fR, \f(CW\*(C`atmega165pa\*(C'\fR, \f(CW\*(C`atmega168\*(C'\fR, \f(CW\*(C`atmega168a\*(C'\fR, \f(CW\*(C`atmega168p\*(C'\fR, \f(CW\*(C`atmega168pa\*(C'\fR, \f(CW\*(C`atmega168pb\*(C'\fR, \f(CW\*(C`atmega169\*(C'\fR, \f(CW\*(C`atmega169a\*(C'\fR, \f(CW\*(C`atmega169p\*(C'\fR, \f(CW\*(C`atmega169pa\*(C'\fR, \f(CW\*(C`atmega32\*(C'\fR, \f(CW\*(C`atmega32a\*(C'\fR, \f(CW\*(C`atmega32c1\*(C'\fR, \f(CW\*(C`atmega32hvb\*(C'\fR, \f(CW\*(C`atmega32hvbrevb\*(C'\fR, \f(CW\*(C`atmega32m1\*(C'\fR, \f(CW\*(C`atmega32u4\*(C'\fR, \f(CW\*(C`atmega32u6\*(C'\fR, \f(CW\*(C`atmega323\*(C'\fR, \f(CW\*(C`atmega324a\*(C'\fR, \f(CW\*(C`atmega324p\*(C'\fR, \f(CW\*(C`atmega324pa\*(C'\fR, \f(CW\*(C`atmega324pb\*(C'\fR, \f(CW\*(C`atmega325\*(C'\fR, \f(CW\*(C`atmega325a\*(C'\fR, \f(CW\*(C`atmega325p\*(C'\fR, \f(CW\*(C`atmega325pa\*(C'\fR, \f(CW\*(C`atmega328\*(C'\fR, \f(CW\*(C`atmega328p\*(C'\fR, \f(CW\*(C`atmega328pb\*(C'\fR, \f(CW\*(C`atmega329\*(C'\fR, \f(CW\*(C`atmega329a\*(C'\fR, \f(CW\*(C`atmega329p\*(C'\fR, \f(CW\*(C`atmega329pa\*(C'\fR, \f(CW\*(C`atmega3250\*(C'\fR, \f(CW\*(C`atmega3250a\*(C'\fR, \f(CW\*(C`atmega3250p\*(C'\fR, \f(CW\*(C`atmega3250pa\*(C'\fR, \f(CW\*(C`atmega3290\*(C'\fR, \f(CW\*(C`atmega3290a\*(C'\fR, \f(CW\*(C`atmega3290p\*(C'\fR, \f(CW\*(C`atmega3290pa\*(C'\fR, \f(CW\*(C`atmega406\*(C'\fR, \f(CW\*(C`atmega64\*(C'\fR, \f(CW\*(C`atmega64a\*(C'\fR, \f(CW\*(C`atmega64c1\*(C'\fR, \f(CW\*(C`atmega64hve\*(C'\fR, \f(CW\*(C`atmega64hve2\*(C'\fR, \f(CW\*(C`atmega64m1\*(C'\fR, \f(CW\*(C`atmega64rfr2\*(C'\fR, \f(CW\*(C`atmega640\*(C'\fR, \f(CW\*(C`atmega644\*(C'\fR, \f(CW\*(C`atmega644a\*(C'\fR, \f(CW\*(C`atmega644p\*(C'\fR, \f(CW\*(C`atmega644pa\*(C'\fR, \f(CW\*(C`atmega644rfr2\*(C'\fR, \f(CW\*(C`atmega645\*(C'\fR, \f(CW\*(C`atmega645a\*(C'\fR, \f(CW\*(C`atmega645p\*(C'\fR, \f(CW\*(C`atmega649\*(C'\fR, \f(CW\*(C`atmega649a\*(C'\fR, \f(CW\*(C`atmega649p\*(C'\fR, \f(CW\*(C`atmega6450\*(C'\fR, \f(CW\*(C`atmega6450a\*(C'\fR, \f(CW\*(C`atmega6450p\*(C'\fR, \f(CW\*(C`atmega6490\*(C'\fR, \f(CW\*(C`atmega6490a\*(C'\fR, \f(CW\*(C`atmega6490p\*(C'\fR, \f(CW\*(C`ata5790\*(C'\fR, \f(CW\*(C`ata5790n\*(C'\fR, \f(CW\*(C`ata5791\*(C'\fR, \f(CW\*(C`ata6613c\*(C'\fR, \f(CW\*(C`ata6614q\*(C'\fR, \f(CW\*(C`ata5782\*(C'\fR, \f(CW\*(C`ata5831\*(C'\fR, \f(CW\*(C`ata8210\*(C'\fR, \f(CW\*(C`ata8510\*(C'\fR, \f(CW\*(C`ata5787\*(C'\fR, \f(CW\*(C`ata5835\*(C'\fR, \f(CW\*(C`ata5700m322\*(C'\fR, \f(CW\*(C`ata5702m322\*(C'\fR, \f(CW\*(C`at90pwm161\*(C'\fR, \f(CW\*(C`at90pwm216\*(C'\fR, \f(CW\*(C`at90pwm316\*(C'\fR, \f(CW\*(C`at90can32\*(C'\fR, \f(CW\*(C`at90can64\*(C'\fR, \f(CW\*(C`at90scr100\*(C'\fR, \f(CW\*(C`at90usb646\*(C'\fR, \f(CW\*(C`at90usb647\*(C'\fR, \f(CW\*(C`at94k\*(C'\fR, \f(CW\*(C`m3000\*(C'\fR.
  .ie n .IP """avr51""" 4
! .el .IP "\f(CWavr51\fR" 4
  .IX Item "avr51"
! \&\*(L"Enhanced\*(R" devices with 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega128\*(C'\fR, \f(CW\*(C`atmega128a\*(C'\fR, \f(CW\*(C`atmega128rfa1\*(C'\fR, \f(CW\*(C`atmega128rfr2\*(C'\fR, \f(CW\*(C`atmega1280\*(C'\fR, \f(CW\*(C`atmega1281\*(C'\fR, \f(CW\*(C`atmega1284\*(C'\fR, \f(CW\*(C`atmega1284p\*(C'\fR, \f(CW\*(C`atmega1284rfr2\*(C'\fR, \f(CW\*(C`at90can128\*(C'\fR, \f(CW\*(C`at90usb1286\*(C'\fR, \f(CW\*(C`at90usb1287\*(C'\fR.
  .ie n .IP """avr6""" 4
! .el .IP "\f(CWavr6\fR" 4
  .IX Item "avr6"
! \&\*(L"Enhanced\*(R" devices with 3\-byte \s-1PC,\s0 i.e. with more than 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega256rfr2\*(C'\fR, \f(CW\*(C`atmega2560\*(C'\fR, \f(CW\*(C`atmega2561\*(C'\fR, \f(CW\*(C`atmega2564rfr2\*(C'\fR.
  .ie n .IP """avrxmega2""" 4
! .el .IP "\f(CWavrxmega2\fR" 4
  .IX Item "avrxmega2"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 8 KiB and up to 64 KiB of program memory.
! \&\fImcu\fR = \f(CW\*(C`atxmega8e5\*(C'\fR, \f(CW\*(C`atxmega16a4\*(C'\fR, \f(CW\*(C`atxmega16a4u\*(C'\fR, \f(CW\*(C`atxmega16c4\*(C'\fR, \f(CW\*(C`atxmega16d4\*(C'\fR, \f(CW\*(C`atxmega16e5\*(C'\fR, \f(CW\*(C`atxmega32a4\*(C'\fR, \f(CW\*(C`atxmega32a4u\*(C'\fR, \f(CW\*(C`atxmega32c3\*(C'\fR, \f(CW\*(C`atxmega32c4\*(C'\fR, \f(CW\*(C`atxmega32d3\*(C'\fR, \f(CW\*(C`atxmega32d4\*(C'\fR, \f(CW\*(C`atxmega32e5\*(C'\fR, \f(CW\*(C`avr64da28\*(C'\fR, \f(CW\*(C`avr64da32\*(C'\fR, \f(CW\*(C`avr64da48\*(C'\fR, \f(CW\*(C`avr64da64\*(C'\fR, \f(CW\*(C`avr64db28\*(C'\fR, \f(CW\*(C`avr64db32\*(C'\fR, \f(CW\*(C`avr64db48\*(C'\fR, \f(CW\*(C`avr64db64\*(C'\fR, \f(CW\*(C`avr64dd14\*(C'\fR, \f(CW\*(C`avr64dd20\*(C'\fR, \f(CW\*(C`avr64dd28\*(C'\fR, \f(CW\*(C`avr64dd32\*(C'\fR, \f(CW\*(C`avr64du28\*(C'\fR, \f(CW\*(C`avr64du32\*(C'\fR, \f(CW\*(C`avr64ea28\*(C'\fR, \f(CW\*(C`avr64ea32\*(C'\fR, \f(CW\*(C`avr64ea48\*(C'\fR, \f(CW\*(C`avr64sd28\*(C'\fR, \f(CW\*(C`avr64sd32\*(C'\fR, \f(CW\*(C`avr64sd48\*(C'\fR.
  .ie n .IP """avrxmega3""" 4
! .el .IP "\f(CWavrxmega3\fR" 4
  .IX Item "avrxmega3"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with up to 64 KiB of combined program memory and \s-1RAM,\s0 and with program memory visible in the \s-1RAM\s0 address space.
! \&\fImcu\fR = \f(CW\*(C`attiny202\*(C'\fR, \f(CW\*(C`attiny204\*(C'\fR, \f(CW\*(C`attiny212\*(C'\fR, \f(CW\*(C`attiny214\*(C'\fR, \f(CW\*(C`attiny402\*(C'\fR, \f(CW\*(C`attiny404\*(C'\fR, \f(CW\*(C`attiny406\*(C'\fR, \f(CW\*(C`attiny412\*(C'\fR, \f(CW\*(C`attiny414\*(C'\fR, \f(CW\*(C`attiny416\*(C'\fR, \f(CW\*(C`attiny416auto\*(C'\fR, \f(CW\*(C`attiny417\*(C'\fR, \f(CW\*(C`attiny424\*(C'\fR, \f(CW\*(C`attiny426\*(C'\fR, \f(CW\*(C`attiny427\*(C'\fR, \f(CW\*(C`attiny804\*(C'\fR, \f(CW\*(C`attiny806\*(C'\fR, \f(CW\*(C`attiny807\*(C'\fR, \f(CW\*(C`attiny814\*(C'\fR, \f(CW\*(C`attiny816\*(C'\fR, \f(CW\*(C`attiny817\*(C'\fR, \f(CW\*(C`attiny824\*(C'\fR, \f(CW\*(C`attiny826\*(C'\fR, \f(CW\*(C`attiny827\*(C'\fR, \f(CW\*(C`attiny1604\*(C'\fR, \f(CW\*(C`attiny1606\*(C'\fR, \f(CW\*(C`attiny1607\*(C'\fR, \f(CW\*(C`attiny1614\*(C'\fR, \f(CW\*(C`attiny1616\*(C'\fR, \f(CW\*(C`attiny1617\*(C'\fR, \f(CW\*(C`attiny1624\*(C'\fR, \f(CW\*(C`attiny1626\*(C'\fR, \f(CW\*(C`attiny1627\*(C'\fR, \f(CW\*(C`attiny3214\*(C'\fR, \f(CW\*(C`attiny3216\*(C'\fR, \f(CW\*(C`attiny3217\*(C'\fR, \f(CW\*(C`attiny3224\*(C'\fR, \f(CW\*(C`attiny3226\*(C'\fR, \f(CW\*(C`attiny3227\*(C'\fR, \f(CW\*(C`atmega808\*(C'\fR, \f(CW\*(C`atmega809\*(C'\fR, \f(CW\*(C`atmega1608\*(C'\fR, \f(CW\*(C`atmega1609\*(C'\fR, \f(CW\*(C`atmega3208\*(C'\fR, \f(CW\*(C`atmega3209\*(C'\fR, \f(CW\*(C`atmega4808\*(C'\fR, \f(CW\*(C`atmega4809\*(C'\fR, \f(CW\*(C`avr16dd14\*(C'\fR, \f(CW\*(C`avr16dd20\*(C'\fR, \f(CW\*(C`avr16dd28\*(C'\fR, \f(CW\*(C`avr16dd32\*(C'\fR, \f(CW\*(C`avr16du14\*(C'\fR, \f(CW\*(C`avr16du20\*(C'\fR, \f(CW\*(C`avr16du28\*(C'\fR, \f(CW\*(C`avr16du32\*(C'\fR, \f(CW\*(C`avr16ea28\*(C'\fR, \f(CW\*(C`avr16ea32\*(C'\fR, \f(CW\*(C`avr16ea48\*(C'\fR, \f(CW\*(C`avr16eb14\*(C'\fR, \f(CW\*(C`avr16eb20\*(C'\fR, \f(CW\*(C`avr16eb28\*(C'\fR, \f(CW\*(C`avr16eb32\*(C'\fR, \f(CW\*(C`avr32da28\*(C'\fR, \f(CW\*(C`avr32da32\*(C'\fR, \f(CW\*(C`avr32da48\*(C'\fR, \f(CW\*(C`avr32db28\*(C'\fR, \f(CW\*(C`avr32db32\*(C'\fR, \f(CW\*(C`avr32db48\*(C'\fR, \f(CW\*(C`avr32dd14\*(C'\fR, \f(CW\*(C`avr32dd20\*(C'\fR, \f(CW\*(C`avr32dd28\*(C'\fR, \f(CW\*(C`avr32dd32\*(C'\fR, \f(CW\*(C`avr32du14\*(C'\fR, \f(CW\*(C`avr32du20\*(C'\fR, \f(CW\*(C`avr32du28\*(C'\fR, \f(CW\*(C`avr32du32\*(C'\fR, \f(CW\*(C`avr32ea28\*(C'\fR, \f(CW\*(C`avr32ea32\*(C'\fR, \f(CW\*(C`avr32ea48\*(C'\fR, \f(CW\*(C`avr32sd20\*(C'\fR, \f(CW\*(C`avr32sd28\*(C'\fR, \f(CW\*(C`avr32sd32\*(C'\fR.
  .ie n .IP """avrxmega4""" 4
! .el .IP "\f(CWavrxmega4\fR" 4
  .IX Item "avrxmega4"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 64 KiB and up to 128 KiB of program memory.
! \&\fImcu\fR = \f(CW\*(C`atxmega64a3\*(C'\fR, \f(CW\*(C`atxmega64a3u\*(C'\fR, \f(CW\*(C`atxmega64a4u\*(C'\fR, \f(CW\*(C`atxmega64b1\*(C'\fR, \f(CW\*(C`atxmega64b3\*(C'\fR, \f(CW\*(C`atxmega64c3\*(C'\fR, \f(CW\*(C`atxmega64d3\*(C'\fR, \f(CW\*(C`atxmega64d4\*(C'\fR, \f(CW\*(C`avr128da28\*(C'\fR, \f(CW\*(C`avr128da32\*(C'\fR, \f(CW\*(C`avr128da48\*(C'\fR, \f(CW\*(C`avr128da64\*(C'\fR, \f(CW\*(C`avr128db28\*(C'\fR, \f(CW\*(C`avr128db32\*(C'\fR, \f(CW\*(C`avr128db48\*(C'\fR, \f(CW\*(C`avr128db64\*(C'\fR.
  .ie n .IP """avrxmega5""" 4
! .el .IP "\f(CWavrxmega5\fR" 4
  .IX Item "avrxmega5"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 64 KiB and up to 128 KiB of program memory and more than 64 KiB of \s-1RAM.\s0
  \&\fImcu\fR = \f(CW\*(C`atxmega64a1\*(C'\fR, \f(CW\*(C`atxmega64a1u\*(C'\fR.
  .ie n .IP """avrxmega6""" 4
! .el .IP "\f(CWavrxmega6\fR" 4
  .IX Item "avrxmega6"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atxmega128a3\*(C'\fR, \f(CW\*(C`atxmega128a3u\*(C'\fR, \f(CW\*(C`atxmega128b1\*(C'\fR, \f(CW\*(C`atxmega128b3\*(C'\fR, \f(CW\*(C`atxmega128c3\*(C'\fR, \f(CW\*(C`atxmega128d3\*(C'\fR, \f(CW\*(C`atxmega128d4\*(C'\fR, \f(CW\*(C`atxmega192a3\*(C'\fR, \f(CW\*(C`atxmega192a3u\*(C'\fR, \f(CW\*(C`atxmega192c3\*(C'\fR, \f(CW\*(C`atxmega192d3\*(C'\fR, \f(CW\*(C`atxmega256a3\*(C'\fR, \f(CW\*(C`atxmega256a3b\*(C'\fR, \f(CW\*(C`atxmega256a3bu\*(C'\fR, \f(CW\*(C`atxmega256a3u\*(C'\fR, \f(CW\*(C`atxmega256c3\*(C'\fR, \f(CW\*(C`atxmega256d3\*(C'\fR, \f(CW\*(C`atxmega384c3\*(C'\fR, \f(CW\*(C`atxmega384d3\*(C'\fR.
  .ie n .IP """avrxmega7""" 4
! .el .IP "\f(CWavrxmega7\fR" 4
  .IX Item "avrxmega7"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 128 KiB of program memory and more than 64 KiB of \s-1RAM.\s0
  \&\fImcu\fR = \f(CW\*(C`atxmega128a1\*(C'\fR, \f(CW\*(C`atxmega128a1u\*(C'\fR, \f(CW\*(C`atxmega128a4u\*(C'\fR.
  .ie n .IP """avrtiny""" 4
! .el .IP "\f(CWavrtiny\fR" 4
  .IX Item "avrtiny"
! \&\*(L"\s-1TINY\*(R"\s0 Tiny core devices with 512 B up to 4 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`attiny4\*(C'\fR, \f(CW\*(C`attiny5\*(C'\fR, \f(CW\*(C`attiny9\*(C'\fR, \f(CW\*(C`attiny10\*(C'\fR, \f(CW\*(C`attiny102\*(C'\fR, \f(CW\*(C`attiny104\*(C'\fR, \f(CW\*(C`attiny20\*(C'\fR, \f(CW\*(C`attiny40\*(C'\fR.
  .ie n .IP """avr1""" 4
! .el .IP "\f(CWavr1\fR" 4
  .IX Item "avr1"
! This \s-1ISA\s0 is implemented by the minimal \s-1AVR\s0 core and supported for assembler only.
  \&\fImcu\fR = \f(CW\*(C`attiny11\*(C'\fR, \f(CW\*(C`attiny12\*(C'\fR, \f(CW\*(C`attiny15\*(C'\fR, \f(CW\*(C`attiny28\*(C'\fR, \f(CW\*(C`at90s1200\*(C'\fR.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mabsdata\fR" 4
  .IX Item "-mabsdata"
! Assume that all data in static storage can be accessed by \s-1LDS / STS\s0
  instructions.  This option has only an effect on reduced Tiny devices like
  ATtiny40.  See also the \f(CW\*(C`absdata\*(C'\fR
! \&\fB\s-1AVR\s0 Variable Attributes,variable attribute\fR.
! .IP "\fB\-maccumulate\-args\fR" 4
  .IX Item "-maccumulate-args"
  Accumulate outgoing function arguments and acquire/release the needed
  stack space for outgoing function arguments once in function
--- 22002,22122 ----
  The default is to generate code without branch protection or return
  address signing.
  .PP
! \fIAVR Options\fR
  .IX Subsection "AVR Options"
  .PP
! These options are defined for AVR implementations:
! .IP \fB\-mmcu=\fR\fImcu\fR 4
  .IX Item "-mmcu=mcu"
! Specify the AVR instruction set architecture (ISA) or device type.
  The default for this option is \f(CW\*(C`avr2\*(C'\fR.
  .Sp
! The following AVR devices and ISAs are supported.
  \&\fINote:\fR A complete device support consists of
! startup code \f(CW\*(C`crt\fR\f(CImcu\fR\f(CW.o\*(C'\fR, a device header \f(CW\*(C`avr/io*.h\*(C'\fR,
! a device library \f(CW\*(C`lib\fR\f(CImcu\fR\f(CW.a\*(C'\fR and a
! device\-specs (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#spec\-files\*(C'\fR) file
! \&\f(CW\*(C`specs\-\fR\f(CImcu\fR\f(CW\*(C'\fR. Only the latter is provided by the compiler
! according the supported \f(CW\*(C`\fR\f(CImcu\fR\f(CW\*(C'\fRs below.  The rest is supported
! by AVR\-LibC (\f(CW\*(C`https://www.nongnu.org/avr\-libc/\*(C'\fR), or by means of
  \&\f(CW\*(C`atpack\*(C'\fR (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#atpack\*(C'\fR) files
  from the hardware manufacturer.
  .RS 4
  .ie n .IP """avr2""" 4
! .el .IP \f(CWavr2\fR 4
  .IX Item "avr2"
! "Classic" devices with up to 8 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`attiny22\*(C'\fR, \f(CW\*(C`attiny26\*(C'\fR, \f(CW\*(C`at90s2313\*(C'\fR, \f(CW\*(C`at90s2323\*(C'\fR, \f(CW\*(C`at90s2333\*(C'\fR, \f(CW\*(C`at90s2343\*(C'\fR, \f(CW\*(C`at90s4414\*(C'\fR, \f(CW\*(C`at90s4433\*(C'\fR, \f(CW\*(C`at90s4434\*(C'\fR, \f(CW\*(C`at90c8534\*(C'\fR, \f(CW\*(C`at90s8515\*(C'\fR, \f(CW\*(C`at90s8535\*(C'\fR.
  .ie n .IP """avr25""" 4
! .el .IP \f(CWavr25\fR 4
  .IX Item "avr25"
! "Classic" devices with up to 8 KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
  \&\fImcu\fR = \f(CW\*(C`attiny13\*(C'\fR, \f(CW\*(C`attiny13a\*(C'\fR, \f(CW\*(C`attiny24\*(C'\fR, \f(CW\*(C`attiny24a\*(C'\fR, \f(CW\*(C`attiny25\*(C'\fR, \f(CW\*(C`attiny261\*(C'\fR, \f(CW\*(C`attiny261a\*(C'\fR, \f(CW\*(C`attiny2313\*(C'\fR, \f(CW\*(C`attiny2313a\*(C'\fR, \f(CW\*(C`attiny43u\*(C'\fR, \f(CW\*(C`attiny44\*(C'\fR, \f(CW\*(C`attiny44a\*(C'\fR, \f(CW\*(C`attiny45\*(C'\fR, \f(CW\*(C`attiny48\*(C'\fR, \f(CW\*(C`attiny441\*(C'\fR, \f(CW\*(C`attiny461\*(C'\fR, \f(CW\*(C`attiny461a\*(C'\fR, \f(CW\*(C`attiny4313\*(C'\fR, \f(CW\*(C`attiny84\*(C'\fR, \f(CW\*(C`attiny84a\*(C'\fR, \f(CW\*(C`attiny85\*(C'\fR, \f(CW\*(C`attiny87\*(C'\fR, \f(CW\*(C`attiny88\*(C'\fR, \f(CW\*(C`attiny828\*(C'\fR, \f(CW\*(C`attiny841\*(C'\fR, \f(CW\*(C`attiny861\*(C'\fR, \f(CW\*(C`attiny861a\*(C'\fR, \f(CW\*(C`ata5272\*(C'\fR, \f(CW\*(C`ata6616c\*(C'\fR, \f(CW\*(C`at86rf401\*(C'\fR.
  .ie n .IP """avr3""" 4
! .el .IP \f(CWavr3\fR 4
  .IX Item "avr3"
! "Classic" devices with 16 KiB up to 64 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`at76c711\*(C'\fR, \f(CW\*(C`at43usb355\*(C'\fR.
  .ie n .IP """avr31""" 4
! .el .IP \f(CWavr31\fR 4
  .IX Item "avr31"
! "Classic" devices with 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega103\*(C'\fR, \f(CW\*(C`at43usb320\*(C'\fR.
  .ie n .IP """avr35""" 4
! .el .IP \f(CWavr35\fR 4
  .IX Item "avr35"
! "Classic" devices with 16 KiB up to 64 KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
  \&\fImcu\fR = \f(CW\*(C`attiny167\*(C'\fR, \f(CW\*(C`attiny1634\*(C'\fR, \f(CW\*(C`atmega8u2\*(C'\fR, \f(CW\*(C`atmega16u2\*(C'\fR, \f(CW\*(C`atmega32u2\*(C'\fR, \f(CW\*(C`ata5505\*(C'\fR, \f(CW\*(C`ata6617c\*(C'\fR, \f(CW\*(C`ata664251\*(C'\fR, \f(CW\*(C`at90usb82\*(C'\fR, \f(CW\*(C`at90usb162\*(C'\fR.
  .ie n .IP """avr4""" 4
! .el .IP \f(CWavr4\fR 4
  .IX Item "avr4"
! "Enhanced" devices with up to 8 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega48\*(C'\fR, \f(CW\*(C`atmega48a\*(C'\fR, \f(CW\*(C`atmega48p\*(C'\fR, \f(CW\*(C`atmega48pa\*(C'\fR, \f(CW\*(C`atmega48pb\*(C'\fR, \f(CW\*(C`atmega8\*(C'\fR, \f(CW\*(C`atmega8a\*(C'\fR, \f(CW\*(C`atmega8hva\*(C'\fR, \f(CW\*(C`atmega88\*(C'\fR, \f(CW\*(C`atmega88a\*(C'\fR, \f(CW\*(C`atmega88p\*(C'\fR, \f(CW\*(C`atmega88pa\*(C'\fR, \f(CW\*(C`atmega88pb\*(C'\fR, \f(CW\*(C`atmega8515\*(C'\fR, \f(CW\*(C`atmega8535\*(C'\fR, \f(CW\*(C`ata5795\*(C'\fR, \f(CW\*(C`ata6285\*(C'\fR, \f(CW\*(C`ata6286\*(C'\fR, \f(CW\*(C`ata6289\*(C'\fR, \f(CW\*(C`ata6612c\*(C'\fR, \f(CW\*(C`at90pwm1\*(C'\fR, \f(CW\*(C`at90pwm2\*(C'\fR, \f(CW\*(C`at90pwm2b\*(C'\fR, \f(CW\*(C`at90pwm3\*(C'\fR, \f(CW\*(C`at90pwm3b\*(C'\fR, \f(CW\*(C`at90pwm81\*(C'\fR.
  .ie n .IP """avr5""" 4
! .el .IP \f(CWavr5\fR 4
  .IX Item "avr5"
! "Enhanced" devices with 16 KiB up to 64 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega16\*(C'\fR, \f(CW\*(C`atmega16a\*(C'\fR, \f(CW\*(C`atmega16hva\*(C'\fR, \f(CW\*(C`atmega16hva2\*(C'\fR, \f(CW\*(C`atmega16hvb\*(C'\fR, \f(CW\*(C`atmega16hvbrevb\*(C'\fR, \f(CW\*(C`atmega16m1\*(C'\fR, \f(CW\*(C`atmega16u4\*(C'\fR, \f(CW\*(C`atmega161\*(C'\fR, \f(CW\*(C`atmega162\*(C'\fR, \f(CW\*(C`atmega163\*(C'\fR, \f(CW\*(C`atmega164a\*(C'\fR, \f(CW\*(C`atmega164p\*(C'\fR, \f(CW\*(C`atmega164pa\*(C'\fR, \f(CW\*(C`atmega165\*(C'\fR, \f(CW\*(C`atmega165a\*(C'\fR, \f(CW\*(C`atmega165p\*(C'\fR, \f(CW\*(C`atmega165pa\*(C'\fR, \f(CW\*(C`atmega168\*(C'\fR, \f(CW\*(C`atmega168a\*(C'\fR, \f(CW\*(C`atmega168p\*(C'\fR, \f(CW\*(C`atmega168pa\*(C'\fR, \f(CW\*(C`atmega168pb\*(C'\fR, \f(CW\*(C`atmega169\*(C'\fR, \f(CW\*(C`atmega169a\*(C'\fR, \f(CW\*(C`atmega169p\*(C'\fR, \f(CW\*(C`atmega169pa\*(C'\fR, \f(CW\*(C`atmega32\*(C'\fR, \f(CW\*(C`atmega32a\*(C'\fR, \f(CW\*(C`atmega32c1\*(C'\fR, \f(CW\*(C`atmega32hvb\*(C'\fR, \f(CW\*(C`atmega32hvbrevb\*(C'\fR, \f(CW\*(C`atmega32m1\*(C'\fR, \f(CW\*(C`atmega32u4\*(C'\fR, \f(CW\*(C`atmega32u6\*(C'\fR, \f(CW\*(C`atmega323\*(C'\fR, \f(CW\*(C`atmega324a\*(C'\fR, \f(CW\*(C`atmega324p\*(C'\fR, \f(CW\*(C`atmega324pa\*(C'\fR, \f(CW\*(C`atmega324pb\*(C'\fR, \f(CW\*(C`atmega325\*(C'\fR, \f(CW\*(C`atmega325a\*(C'\fR, \f(CW\*(C`atmega325p\*(C'\fR, \f(CW\*(C`atmega325pa\*(C'\fR, \f(CW\*(C`atmega328\*(C'\fR, \f(CW\*(C`atmega328p\*(C'\fR, \f(CW\*(C`atmega328pb\*(C'\fR, \f(CW\*(C`atmega329\*(C'\fR, \f(CW\*(C`atmega329a\*(C'\fR, \f(CW\*(C`atmega329p\*(C'\fR, \f(CW\*(C`atmega329pa\*(C'\fR, \f(CW\*(C`atmega3250\*(C'\fR, \f(CW\*(C`atmega3250a\*(C'\fR, \f(CW\*(C`atmega3250p\*(C'\fR, \f(CW\*(C`atmega3250pa\*(C'\fR, \f(CW\*(C`atmega3290\*(C'\fR, \f(CW\*(C`atmega3290a\*(C'\fR, \f(CW\*(C`atmega3290p\*(C'\fR, \f(CW\*(C`atmega3290pa\*(C'\fR, \f(CW\*(C`atmega406\*(C'\fR, \f(CW\*(C`atmega64\*(C'\fR, \f(CW\*(C`atmega64a\*(C'\fR, \f(CW\*(C`atmega64c1\*(C'\fR, \f(CW\*(C`atmega64hve\*(C'\fR, \f(CW\*(C`atmega64hve2\*(C'\fR, \f(CW\*(C`atmega64m1\*(C'\fR, \f(CW\*(C`atmega64rfr2\*(C'\fR, \f(CW\*(C`atmega640\*(C'\fR, \f(CW\*(C`atmega644\*(C'\fR, \f(CW\*(C`atmega644a\*(C'\fR, \f(CW\*(C`atmega644p\*(C'\fR, \f(CW\*(C`atmega644pa\*(C'\fR, \f(CW\*(C`atmega644rfr2\*(C'\fR, \f(CW\*(C`atmega645\*(C'\fR, \f(CW\*(C`atmega645a\*(C'\fR, \f(CW\*(C`atmega645p\*(C'\fR, \f(CW\*(C`atmega649\*(C'\fR, \f(CW\*(C`atmega649a\*(C'\fR, \f(CW\*(C`atmega649p\*(C'\fR, \f(CW\*(C`atmega6450\*(C'\fR, \f(CW\*(C`atmega6450a\*(C'\fR, \f(CW\*(C`atmega6450p\*(C'\fR, \f(CW\*(C`atmega6490\*(C'\fR, \f(CW\*(C`atmega6490a\*(C'\fR, \f(CW\*(C`atmega6490p\*(C'\fR, \f(CW\*(C`ata5790\*(C'\fR, \f(CW\*(C`ata5790n\*(C'\fR, \f(CW\*(C`ata5791\*(C'\fR, \f(CW\*(C`ata6613c\*(C'\fR, \f(CW\*(C`ata6614q\*(C'\fR, \f(CW\*(C`ata5782\*(C'\fR, \f(CW\*(C`ata5831\*(C'\fR, \f(CW\*(C`ata8210\*(C'\fR, \f(CW\*(C`ata8510\*(C'\fR, \f(CW\*(C`ata5787\*(C'\fR, \f(CW\*(C`ata5835\*(C'\fR, \f(CW\*(C`ata5700m322\*(C'\fR, \f(CW\*(C`ata5702m322\*(C'\fR, \f(CW\*(C`at90pwm161\*(C'\fR, \f(CW\*(C`at90pwm216\*(C'\fR, \f(CW\*(C`at90pwm316\*(C'\fR, \f(CW\*(C`at90can32\*(C'\fR, \f(CW\*(C`at90can64\*(C'\fR, \f(CW\*(C`at90scr100\*(C'\fR, \f(CW\*(C`at90usb646\*(C'\fR, \f(CW\*(C`at90usb647\*(C'\fR, \f(CW\*(C`at94k\*(C'\fR, \f(CW\*(C`m3000\*(C'\fR.
  .ie n .IP """avr51""" 4
! .el .IP \f(CWavr51\fR 4
  .IX Item "avr51"
! "Enhanced" devices with 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega128\*(C'\fR, \f(CW\*(C`atmega128a\*(C'\fR, \f(CW\*(C`atmega128rfa1\*(C'\fR, \f(CW\*(C`atmega128rfr2\*(C'\fR, \f(CW\*(C`atmega1280\*(C'\fR, \f(CW\*(C`atmega1281\*(C'\fR, \f(CW\*(C`atmega1284\*(C'\fR, \f(CW\*(C`atmega1284p\*(C'\fR, \f(CW\*(C`atmega1284rfr2\*(C'\fR, \f(CW\*(C`at90can128\*(C'\fR, \f(CW\*(C`at90usb1286\*(C'\fR, \f(CW\*(C`at90usb1287\*(C'\fR.
  .ie n .IP """avr6""" 4
! .el .IP \f(CWavr6\fR 4
  .IX Item "avr6"
! "Enhanced" devices with 3\-byte PC, i.e. with more than 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega256rfr2\*(C'\fR, \f(CW\*(C`atmega2560\*(C'\fR, \f(CW\*(C`atmega2561\*(C'\fR, \f(CW\*(C`atmega2564rfr2\*(C'\fR.
  .ie n .IP """avrxmega2""" 4
! .el .IP \f(CWavrxmega2\fR 4
  .IX Item "avrxmega2"
! "XMEGA" devices with more than 8 KiB and up to 64 KiB of program memory.
! \&\fImcu\fR = \f(CW\*(C`atxmega8e5\*(C'\fR, \f(CW\*(C`atxmega16a4\*(C'\fR, \f(CW\*(C`atxmega16a4u\*(C'\fR, \f(CW\*(C`atxmega16c4\*(C'\fR, \f(CW\*(C`atxmega16d4\*(C'\fR, \f(CW\*(C`atxmega16e5\*(C'\fR, \f(CW\*(C`atxmega32a4\*(C'\fR, \f(CW\*(C`atxmega32a4u\*(C'\fR, \f(CW\*(C`atxmega32c3\*(C'\fR, \f(CW\*(C`atxmega32c4\*(C'\fR, \f(CW\*(C`atxmega32d3\*(C'\fR, \f(CW\*(C`atxmega32d4\*(C'\fR, \f(CW\*(C`atxmega32e5\*(C'\fR, \f(CW\*(C`avr64da28\*(C'\fR, \f(CW\*(C`avr64da28s\*(C'\fR, \f(CW\*(C`avr64da32\*(C'\fR, \f(CW\*(C`avr64da32s\*(C'\fR, \f(CW\*(C`avr64da48\*(C'\fR, \f(CW\*(C`avr64da48s\*(C'\fR, \f(CW\*(C`avr64da64\*(C'\fR, \f(CW\*(C`avr64da64s\*(C'\fR, \f(CW\*(C`avr64db28\*(C'\fR, \f(CW\*(C`avr64db32\*(C'\fR, \f(CW\*(C`avr64db48\*(C'\fR, \f(CW\*(C`avr64db64\*(C'\fR, \f(CW\*(C`avr64dd14\*(C'\fR, \f(CW\*(C`avr64dd20\*(C'\fR, \f(CW\*(C`avr64dd28\*(C'\fR, \f(CW\*(C`avr64dd32\*(C'\fR, \f(CW\*(C`avr64du28\*(C'\fR, \f(CW\*(C`avr64du32\*(C'\fR, \f(CW\*(C`avr64ea28\*(C'\fR, \f(CW\*(C`avr64ea32\*(C'\fR, \f(CW\*(C`avr64ea48\*(C'\fR, \f(CW\*(C`avr64sd28\*(C'\fR, \f(CW\*(C`avr64sd32\*(C'\fR, \f(CW\*(C`avr64sd48\*(C'\fR.
  .ie n .IP """avrxmega3""" 4
! .el .IP \f(CWavrxmega3\fR 4
  .IX Item "avrxmega3"
! "XMEGA" devices with up to 64 KiB of combined program memory and RAM, and with program memory visible in the RAM address space.
! \&\fImcu\fR = \f(CW\*(C`attiny202\*(C'\fR, \f(CW\*(C`attiny204\*(C'\fR, \f(CW\*(C`attiny212\*(C'\fR, \f(CW\*(C`attiny214\*(C'\fR, \f(CW\*(C`attiny402\*(C'\fR, \f(CW\*(C`attiny404\*(C'\fR, \f(CW\*(C`attiny406\*(C'\fR, \f(CW\*(C`attiny412\*(C'\fR, \f(CW\*(C`attiny414\*(C'\fR, \f(CW\*(C`attiny416\*(C'\fR, \f(CW\*(C`attiny416auto\*(C'\fR, \f(CW\*(C`attiny417\*(C'\fR, \f(CW\*(C`attiny424\*(C'\fR, \f(CW\*(C`attiny426\*(C'\fR, \f(CW\*(C`attiny427\*(C'\fR, \f(CW\*(C`attiny804\*(C'\fR, \f(CW\*(C`attiny806\*(C'\fR, \f(CW\*(C`attiny807\*(C'\fR, \f(CW\*(C`attiny814\*(C'\fR, \f(CW\*(C`attiny816\*(C'\fR, \f(CW\*(C`attiny817\*(C'\fR, \f(CW\*(C`attiny824\*(C'\fR, \f(CW\*(C`attiny826\*(C'\fR, \f(CW\*(C`attiny827\*(C'\fR, \f(CW\*(C`attiny1604\*(C'\fR, \f(CW\*(C`attiny1606\*(C'\fR, \f(CW\*(C`attiny1607\*(C'\fR, \f(CW\*(C`attiny1614\*(C'\fR, \f(CW\*(C`attiny1616\*(C'\fR, \f(CW\*(C`attiny1617\*(C'\fR, \f(CW\*(C`attiny1624\*(C'\fR, \f(CW\*(C`attiny1626\*(C'\fR, \f(CW\*(C`attiny1627\*(C'\fR, \f(CW\*(C`attiny3214\*(C'\fR, \f(CW\*(C`attiny3216\*(C'\fR, \f(CW\*(C`attiny3217\*(C'\fR, \f(CW\*(C`attiny3224\*(C'\fR, \f(CW\*(C`attiny3226\*(C'\fR, \f(CW\*(C`attiny3227\*(C'\fR, \f(CW\*(C`atmega808\*(C'\fR, \f(CW\*(C`atmega809\*(C'\fR, \f(CW\*(C`atmega1608\*(C'\fR, \f(CW\*(C`atmega1609\*(C'\fR, \f(CW\*(C`atmega3208\*(C'\fR, \f(CW\*(C`atmega3209\*(C'\fR, \f(CW\*(C`atmega4808\*(C'\fR, \f(CW\*(C`atmega4809\*(C'\fR, \f(CW\*(C`avr16dd14\*(C'\fR, \f(CW\*(C`avr16dd20\*(C'\fR, \f(CW\*(C`avr16dd28\*(C'\fR, \f(CW\*(C`avr16dd32\*(C'\fR, \f(CW\*(C`avr16du14\*(C'\fR, \f(CW\*(C`avr16du20\*(C'\fR, \f(CW\*(C`avr16du28\*(C'\fR, \f(CW\*(C`avr16du32\*(C'\fR, \f(CW\*(C`avr16ea28\*(C'\fR, \f(CW\*(C`avr16ea32\*(C'\fR, \f(CW\*(C`avr16ea48\*(C'\fR, \f(CW\*(C`avr16eb14\*(C'\fR, \f(CW\*(C`avr16eb20\*(C'\fR, \f(CW\*(C`avr16eb28\*(C'\fR, \f(CW\*(C`avr16eb32\*(C'\fR, \f(CW\*(C`avr16la14\*(C'\fR, \f(CW\*(C`avr16la20\*(C'\fR, \f(CW\*(C`avr16la28\*(C'\fR, \f(CW\*(C`avr16la32\*(C'\fR, \f(CW\*(C`avr32da28\*(C'\fR, \f(CW\*(C`avr32da28s\*(C'\fR, \f(CW\*(C`avr32da32\*(C'\fR, \f(CW\*(C`avr32da32s\*(C'\fR, \f(CW\*(C`avr32da48\*(C'\fR, \f(CW\*(C`avr32da48s\*(C'\fR, \f(CW\*(C`avr32db28\*(C'\fR, \f(CW\*(C`avr32db32\*(C'\fR, \f(CW\*(C`avr32db48\*(C'\fR, \f(CW\*(C`avr32dd14\*(C'\fR, \f(CW\*(C`avr32dd20\*(C'\fR, \f(CW\*(C`avr32dd28\*(C'\fR, \f(CW\*(C`avr32dd32\*(C'\fR, \f(CW\*(C`avr32du14\*(C'\fR, \f(CW\*(C`avr32du20\*(C'\fR, \f(CW\*(C`avr32du28\*(C'\fR, \f(CW\*(C`avr32du32\*(C'\fR, \f(CW\*(C`avr32ea28\*(C'\fR, \f(CW\*(C`avr32ea32\*(C'\fR, \f(CW\*(C`avr32ea48\*(C'\fR, \f(CW\*(C`avr32eb14\*(C'\fR, \f(CW\*(C`avr32eb20\*(C'\fR, \f(CW\*(C`avr32eb28\*(C'\fR, \f(CW\*(C`avr32eb32\*(C'\fR, \f(CW\*(C`avr32la14\*(C'\fR, \f(CW\*(C`avr32la20\*(C'\fR, \f(CW\*(C`avr32la28\*(C'\fR, \f(CW\*(C`avr32la32\*(C'\fR, \f(CW\*(C`avr32sd20\*(C'\fR, \f(CW\*(C`avr32sd28\*(C'\fR, \f(CW\*(C`avr32sd32\*(C'\fR.
  .ie n .IP """avrxmega4""" 4
! .el .IP \f(CWavrxmega4\fR 4
  .IX Item "avrxmega4"
! "XMEGA" devices with more than 64 KiB and up to 128 KiB of program memory.
! \&\fImcu\fR = \f(CW\*(C`atxmega64a3\*(C'\fR, \f(CW\*(C`atxmega64a3u\*(C'\fR, \f(CW\*(C`atxmega64a4u\*(C'\fR, \f(CW\*(C`atxmega64b1\*(C'\fR, \f(CW\*(C`atxmega64b3\*(C'\fR, \f(CW\*(C`atxmega64c3\*(C'\fR, \f(CW\*(C`atxmega64d3\*(C'\fR, \f(CW\*(C`atxmega64d4\*(C'\fR, \f(CW\*(C`avr128da28\*(C'\fR, \f(CW\*(C`avr128da28s\*(C'\fR, \f(CW\*(C`avr128da32\*(C'\fR, \f(CW\*(C`avr128da32s\*(C'\fR, \f(CW\*(C`avr128da48\*(C'\fR, \f(CW\*(C`avr128da48s\*(C'\fR, \f(CW\*(C`avr128da64\*(C'\fR, \f(CW\*(C`avr128da64s\*(C'\fR, \f(CW\*(C`avr128db28\*(C'\fR, \f(CW\*(C`avr128db32\*(C'\fR, \f(CW\*(C`avr128db48\*(C'\fR, \f(CW\*(C`avr128db64\*(C'\fR.
  .ie n .IP """avrxmega5""" 4
! .el .IP \f(CWavrxmega5\fR 4
  .IX Item "avrxmega5"
! "XMEGA" devices with more than 64 KiB and up to 128 KiB of program memory and more than 64 KiB of RAM.
  \&\fImcu\fR = \f(CW\*(C`atxmega64a1\*(C'\fR, \f(CW\*(C`atxmega64a1u\*(C'\fR.
  .ie n .IP """avrxmega6""" 4
! .el .IP \f(CWavrxmega6\fR 4
  .IX Item "avrxmega6"
! "XMEGA" devices with more than 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atxmega128a3\*(C'\fR, \f(CW\*(C`atxmega128a3u\*(C'\fR, \f(CW\*(C`atxmega128b1\*(C'\fR, \f(CW\*(C`atxmega128b3\*(C'\fR, \f(CW\*(C`atxmega128c3\*(C'\fR, \f(CW\*(C`atxmega128d3\*(C'\fR, \f(CW\*(C`atxmega128d4\*(C'\fR, \f(CW\*(C`atxmega192a3\*(C'\fR, \f(CW\*(C`atxmega192a3u\*(C'\fR, \f(CW\*(C`atxmega192c3\*(C'\fR, \f(CW\*(C`atxmega192d3\*(C'\fR, \f(CW\*(C`atxmega256a3\*(C'\fR, \f(CW\*(C`atxmega256a3b\*(C'\fR, \f(CW\*(C`atxmega256a3bu\*(C'\fR, \f(CW\*(C`atxmega256a3u\*(C'\fR, \f(CW\*(C`atxmega256c3\*(C'\fR, \f(CW\*(C`atxmega256d3\*(C'\fR, \f(CW\*(C`atxmega384c3\*(C'\fR, \f(CW\*(C`atxmega384d3\*(C'\fR.
  .ie n .IP """avrxmega7""" 4
! .el .IP \f(CWavrxmega7\fR 4
  .IX Item "avrxmega7"
! "XMEGA" devices with more than 128 KiB of program memory and more than 64 KiB of RAM.
  \&\fImcu\fR = \f(CW\*(C`atxmega128a1\*(C'\fR, \f(CW\*(C`atxmega128a1u\*(C'\fR, \f(CW\*(C`atxmega128a4u\*(C'\fR.
  .ie n .IP """avrtiny""" 4
! .el .IP \f(CWavrtiny\fR 4
  .IX Item "avrtiny"
! "TINY" Tiny core devices with 512 B up to 4 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`attiny4\*(C'\fR, \f(CW\*(C`attiny5\*(C'\fR, \f(CW\*(C`attiny9\*(C'\fR, \f(CW\*(C`attiny10\*(C'\fR, \f(CW\*(C`attiny102\*(C'\fR, \f(CW\*(C`attiny104\*(C'\fR, \f(CW\*(C`attiny20\*(C'\fR, \f(CW\*(C`attiny40\*(C'\fR.
  .ie n .IP """avr1""" 4
! .el .IP \f(CWavr1\fR 4
  .IX Item "avr1"
! This ISA is implemented by the minimal AVR core and supported for assembler only.
  \&\fImcu\fR = \f(CW\*(C`attiny11\*(C'\fR, \f(CW\*(C`attiny12\*(C'\fR, \f(CW\*(C`attiny15\*(C'\fR, \f(CW\*(C`attiny28\*(C'\fR, \f(CW\*(C`at90s1200\*(C'\fR.
  .RE
  .RS 4
  .RE
! .IP \fB\-mabsdata\fR 4
  .IX Item "-mabsdata"
! Assume that all data in static storage can be accessed by LDS / STS
  instructions.  This option has only an effect on reduced Tiny devices like
  ATtiny40.  See also the \f(CW\*(C`absdata\*(C'\fR
! \&\fBAVR Variable Attributes,variable attribute\fR.
! .IP \fB\-maccumulate\-args\fR 4
  .IX Item "-maccumulate-args"
  Accumulate outgoing function arguments and acquire/release the needed
  stack space for outgoing function arguments once in function
*************** prologue/epilogue.  Without this option,
*** 22193,22218 ****
  before calling a function and popped afterwards.
  .Sp
  Popping the arguments after the function call can be expensive on
! \&\s-1AVR\s0 so that accumulating the stack space might lead to smaller
  executables because arguments need not be removed from the
  stack after such a function call.
  .Sp
  This option can lead to reduced code size for functions that perform
  several calls to functions that get their arguments on the stack like
! calls to printf-like functions.
! .IP "\fB\-mbranch\-cost=\fR\fIcost\fR" 4
  .IX Item "-mbranch-cost=cost"
  Set the branch costs for conditional branch instructions to
! \&\fIcost\fR.  Reasonable values for \fIcost\fR are small, non-negative
  integers. The default branch cost is 0.
! .IP "\fB\-mcall\-prologues\fR" 4
  .IX Item "-mcall-prologues"
  Functions prologues/epilogues are expanded as calls to appropriate
  subroutines.  Code size is smaller.
! .IP "\fB\-mdouble=\fR\fIbits\fR" 4
  .IX Item "-mdouble=bits"
  .PD 0
! .IP "\fB\-mlong\-double=\fR\fIbits\fR" 4
  .IX Item "-mlong-double=bits"
  .PD
  Set the size (in bits) of the \f(CW\*(C`double\*(C'\fR or \f(CW\*(C`long double\*(C'\fR type,
--- 22124,22149 ----
  before calling a function and popped afterwards.
  .Sp
  Popping the arguments after the function call can be expensive on
! AVR so that accumulating the stack space might lead to smaller
  executables because arguments need not be removed from the
  stack after such a function call.
  .Sp
  This option can lead to reduced code size for functions that perform
  several calls to functions that get their arguments on the stack like
! calls to printf\-like functions.
! .IP \fB\-mbranch\-cost=\fR\fIcost\fR 4
  .IX Item "-mbranch-cost=cost"
  Set the branch costs for conditional branch instructions to
! \&\fIcost\fR.  Reasonable values for \fIcost\fR are small, non\-negative
  integers. The default branch cost is 0.
! .IP \fB\-mcall\-prologues\fR 4
  .IX Item "-mcall-prologues"
  Functions prologues/epilogues are expanded as calls to appropriate
  subroutines.  Code size is smaller.
! .IP \fB\-mdouble=\fR\fIbits\fR 4
  .IX Item "-mdouble=bits"
  .PD 0
! .IP \fB\-mlong\-double=\fR\fIbits\fR 4
  .IX Item "-mlong-double=bits"
  .PD
  Set the size (in bits) of the \f(CW\*(C`double\*(C'\fR or \f(CW\*(C`long double\*(C'\fR type,
*************** Whether or not a specific value for \fIb
*** 22221,22258 ****
  the \f(CW\*(C`\-\-with\-double=\*(C'\fR and \f(CW\*(C`\-\-with\-long\-double=\*(C'\fR
  configure\ options (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR),
  and the same applies for the default values of the options.
! .IP "\fB\-mgas\-isr\-prologues\fR" 4
  .IX Item "-mgas-isr-prologues"
  Interrupt service routines (ISRs) may use the \f(CW\*(C`_\|_gcc_isr\*(C'\fR pseudo
! instruction supported by \s-1GNU\s0 Binutils.
  If this option is on, the feature can still be disabled for individual
! ISRs by means of the \fB\s-1AVR\s0 Function Attributes,,\f(CB\*(C`no_gccisr\*(C'\fB\fR
  function attribute.  This feature is activated per default
  if optimization is on (but not with \fB\-Og\fR, \f(CW@pxref\fR{Optimize Options}),
! and if \s-1GNU\s0 Binutils support \s-1PR21683\s0 (\f(CW\*(C`https://sourceware.org/PR21683\*(C'\fR).
! .IP "\fB\-mint8\fR" 4
  .IX Item "-mint8"
  Assume \f(CW\*(C`int\*(C'\fR to be 8\-bit integer.  This affects the sizes of all types: a
  \&\f(CW\*(C`char\*(C'\fR is 1 byte, an \f(CW\*(C`int\*(C'\fR is 1 byte, a \f(CW\*(C`long\*(C'\fR is 2 bytes,
  and \f(CW\*(C`long long\*(C'\fR is 4 bytes.  Please note that this option does not
  conform to the C standards, but it results in smaller code
  size.
! .IP "\fB\-mmain\-is\-OS_task\fR" 4
  .IX Item "-mmain-is-OS_task"
  Do not save registers in \f(CW\*(C`main\*(C'\fR.  The effect is the same like
! attaching attribute \fB\s-1AVR\s0 Function Attributes,,\f(CB\*(C`OS_task\*(C'\fB\fR
  to \f(CW\*(C`main\*(C'\fR. It is activated per default if optimization is on.
! .IP "\fB\-mno\-interrupts\fR" 4
  .IX Item "-mno-interrupts"
  Generated code is not compatible with hardware interrupts.
  Code size is smaller.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Try to replace \f(CW\*(C`CALL\*(C'\fR resp. \f(CW\*(C`JMP\*(C'\fR instruction by the shorter
  \&\f(CW\*(C`RCALL\*(C'\fR resp. \f(CW\*(C`RJMP\*(C'\fR instruction if applicable.
  Setting \fB\-mrelax\fR just adds the \fB\-\-mlink\-relax\fR option to
! the assembler's command line and the \fB\-\-relax\fR option to the
! linker's command line.
  .Sp
  Jump relaxing is performed by the linker because jump offsets are not
  known before code is located. Therefore, the assembler code generated by the
--- 22152,22189 ----
  the \f(CW\*(C`\-\-with\-double=\*(C'\fR and \f(CW\*(C`\-\-with\-long\-double=\*(C'\fR
  configure\ options (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR),
  and the same applies for the default values of the options.
! .IP \fB\-mgas\-isr\-prologues\fR 4
  .IX Item "-mgas-isr-prologues"
  Interrupt service routines (ISRs) may use the \f(CW\*(C`_\|_gcc_isr\*(C'\fR pseudo
! instruction supported by GNU Binutils.
  If this option is on, the feature can still be disabled for individual
! ISRs by means of the \fBAVR Function Attributes,,\fR\f(CB\*(C`no_gccisr\*(C'\fR
  function attribute.  This feature is activated per default
  if optimization is on (but not with \fB\-Og\fR, \f(CW@pxref\fR{Optimize Options}),
! and if GNU Binutils support PR21683 (\f(CW\*(C`https://sourceware.org/PR21683\*(C'\fR).
! .IP \fB\-mint8\fR 4
  .IX Item "-mint8"
  Assume \f(CW\*(C`int\*(C'\fR to be 8\-bit integer.  This affects the sizes of all types: a
  \&\f(CW\*(C`char\*(C'\fR is 1 byte, an \f(CW\*(C`int\*(C'\fR is 1 byte, a \f(CW\*(C`long\*(C'\fR is 2 bytes,
  and \f(CW\*(C`long long\*(C'\fR is 4 bytes.  Please note that this option does not
  conform to the C standards, but it results in smaller code
  size.
! .IP \fB\-mmain\-is\-OS_task\fR 4
  .IX Item "-mmain-is-OS_task"
  Do not save registers in \f(CW\*(C`main\*(C'\fR.  The effect is the same like
! attaching attribute \fBAVR Function Attributes,,\fR\f(CB\*(C`OS_task\*(C'\fR
  to \f(CW\*(C`main\*(C'\fR. It is activated per default if optimization is on.
! .IP \fB\-mno\-interrupts\fR 4
  .IX Item "-mno-interrupts"
  Generated code is not compatible with hardware interrupts.
  Code size is smaller.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Try to replace \f(CW\*(C`CALL\*(C'\fR resp. \f(CW\*(C`JMP\*(C'\fR instruction by the shorter
  \&\f(CW\*(C`RCALL\*(C'\fR resp. \f(CW\*(C`RJMP\*(C'\fR instruction if applicable.
  Setting \fB\-mrelax\fR just adds the \fB\-\-mlink\-relax\fR option to
! the assembler\*(Aqs command line and the \fB\-\-relax\fR option to the
! linker\*(Aqs command line.
  .Sp
  Jump relaxing is performed by the linker because jump offsets are not
  known before code is located. Therefore, the assembler code generated by the
*************** differ from instructions in the assemble
*** 22261,22277 ****
  .Sp
  Relaxing must be turned on if linker stubs are needed, see the
  section on \f(CW\*(C`EIND\*(C'\fR and linker stubs below.
! .IP "\fB\-mstrict\-X\fR" 4
  .IX Item "-mstrict-X"
  Use address register \f(CW\*(C`X\*(C'\fR in a way proposed by the hardware.  This means
! that \f(CW\*(C`X\*(C'\fR is only used in indirect, post-increment or
! pre-decrement addressing.
  .Sp
  Without this option, the \f(CW\*(C`X\*(C'\fR register may be used in the same way
  as \f(CW\*(C`Y\*(C'\fR or \f(CW\*(C`Z\*(C'\fR which then is emulated by additional
  instructions.  
  For example, loading a value with \f(CW\*(C`X+const\*(C'\fR addressing with a
! small non-negative \f(CW\*(C`const < 64\*(C'\fR to a register \fIRn\fR is
  performed as
  .Sp
  .Vb 3
--- 22192,22208 ----
  .Sp
  Relaxing must be turned on if linker stubs are needed, see the
  section on \f(CW\*(C`EIND\*(C'\fR and linker stubs below.
! .IP \fB\-mstrict\-X\fR 4
  .IX Item "-mstrict-X"
  Use address register \f(CW\*(C`X\*(C'\fR in a way proposed by the hardware.  This means
! that \f(CW\*(C`X\*(C'\fR is only used in indirect, post\-increment or
! pre\-decrement addressing.
  .Sp
  Without this option, the \f(CW\*(C`X\*(C'\fR register may be used in the same way
  as \f(CW\*(C`Y\*(C'\fR or \f(CW\*(C`Z\*(C'\fR which then is emulated by additional
  instructions.  
  For example, loading a value with \f(CW\*(C`X+const\*(C'\fR addressing with a
! small non\-negative \f(CW\*(C`const < 64\*(C'\fR to a register \fIRn\fR is
  performed as
  .Sp
  .Vb 3
*************** performed as
*** 22279,22313 ****
  \&        ld   , X        ;  = *X
  \&        sbiw r26, const   ; X \-= const
  .Ve
! .IP "\fB\-mtiny\-stack\fR" 4
  .IX Item "-mtiny-stack"
  Only change the lower 8 bits of the stack pointer.
! .IP "\fB\-mfract\-convert\-truncate\fR" 4
  .IX Item "-mfract-convert-truncate"
! Allow to use truncation instead of rounding towards zero for fractional fixed-point types.
! .IP "\fB\-nodevicelib\fR" 4
  .IX Item "-nodevicelib"
! Don't link against AVR-LibC's device specific library \f(CW\*(C`lib.a\*(C'\fR.
! .IP "\fB\-nodevicespecs\fR" 4
  .IX Item "-nodevicespecs"
! Don't add \fB\-specs=device\-specs/specs\-\fR\fImcu\fR to the compiler driver's
! command line.  The user takes responsibility for supplying the sub-processes
  like compiler proper, assembler and linker with appropriate command line
  options.  This means that the user has to supply her private device specs
! file by means of \fB\-specs=\fR\fIpath-to-specs-file\fR.  There is no
  more need for option \fB\-mmcu=\fR\fImcu\fR.
  .Sp
  This option can also serve as a replacement for the older way of
! specifying custom device-specs files that needed \fB\-B\fR \fIsome-path\fR to point to a directory
  which contains a folder named \f(CW\*(C`device\-specs\*(C'\fR which contains a specs file named
! \&\f(CW\*(C`specs\-\f(CImcu\f(CW\*(C'\fR, where \fImcu\fR was specified by \fB\-mmcu=\fR\fImcu\fR.
! .IP "\fB\-Waddr\-space\-convert\fR" 4
  .IX Item "-Waddr-space-convert"
  Warn about conversions between address spaces in the case where the
  resulting address space is not contained in the incoming address space.
! .IP "\fB\-Wmisspelled\-isr\fR" 4
  .IX Item "-Wmisspelled-isr"
! Warn if the \s-1ISR\s0 is misspelled, i.e. without _\|_vector prefix.
  Enabled by default.
  .PP
  \f(CW\*(C`EIND\*(C'\fR and Devices with More Than 128 Ki Bytes of Flash
--- 22210,22244 ----
  \&        ld   , X        ;  = *X
  \&        sbiw r26, const   ; X \-= const
  .Ve
! .IP \fB\-mtiny\-stack\fR 4
  .IX Item "-mtiny-stack"
  Only change the lower 8 bits of the stack pointer.
! .IP \fB\-mfract\-convert\-truncate\fR 4
  .IX Item "-mfract-convert-truncate"
! Allow to use truncation instead of rounding towards zero for fractional fixed\-point types.
! .IP \fB\-nodevicelib\fR 4
  .IX Item "-nodevicelib"
! Don\*(Aqt link against AVR\-LibC\*(Aqs device specific library \f(CW\*(C`lib.a\*(C'\fR.
! .IP \fB\-nodevicespecs\fR 4
  .IX Item "-nodevicespecs"
! Don\*(Aqt add \fB\-specs=device\-specs/specs\-\fR\fImcu\fR to the compiler driver\*(Aqs
! command line.  The user takes responsibility for supplying the sub\-processes
  like compiler proper, assembler and linker with appropriate command line
  options.  This means that the user has to supply her private device specs
! file by means of \fB\-specs=\fR\fIpath\-to\-specs\-file\fR.  There is no
  more need for option \fB\-mmcu=\fR\fImcu\fR.
  .Sp
  This option can also serve as a replacement for the older way of
! specifying custom device\-specs files that needed \fB\-B\fR \fIsome\-path\fR to point to a directory
  which contains a folder named \f(CW\*(C`device\-specs\*(C'\fR which contains a specs file named
! \&\f(CW\*(C`specs\-\fR\f(CImcu\fR\f(CW\*(C'\fR, where \fImcu\fR was specified by \fB\-mmcu=\fR\fImcu\fR.
! .IP \fB\-Waddr\-space\-convert\fR 4
  .IX Item "-Waddr-space-convert"
  Warn about conversions between address spaces in the case where the
  resulting address space is not contained in the incoming address space.
! .IP \fB\-Wmisspelled\-isr\fR 4
  .IX Item "-Wmisspelled-isr"
! Warn if the ISR is misspelled, i.e. without _\|_vector prefix.
  Enabled by default.
  .PP
  \f(CW\*(C`EIND\*(C'\fR and Devices with More Than 128 Ki Bytes of Flash
*************** when \f(CW\*(C`EICALL\*(C'\fR or \f(CW\*
*** 22325,22369 ****
  .PP
  Indirect jumps and calls on these devices are handled as follows by
  the compiler and are subject to some limitations:
! .IP "*" 4
  The compiler never sets \f(CW\*(C`EIND\*(C'\fR.
! .IP "*" 4
  The compiler uses \f(CW\*(C`EIND\*(C'\fR implicitly in \f(CW\*(C`EICALL\*(C'\fR/\f(CW\*(C`EIJMP\*(C'\fR
  instructions or might read \f(CW\*(C`EIND\*(C'\fR directly in order to emulate an
  indirect call/jump by means of a \f(CW\*(C`RET\*(C'\fR instruction.
! .IP "*" 4
  The compiler assumes that \f(CW\*(C`EIND\*(C'\fR never changes during the startup
  code or during the application. In particular, \f(CW\*(C`EIND\*(C'\fR is not
  saved/restored in function or interrupt service routine
  prologue/epilogue.
! .IP "*" 4
  For indirect calls to functions and computed goto, the linker
  generates \fIstubs\fR. Stubs are jump pads sometimes also called
  \&\fItrampolines\fR. Thus, the indirect call/jump jumps to such a stub.
  The stub contains a direct jump to the desired address.
! .IP "*" 4
  Linker relaxation must be turned on so that the linker generates
  the stubs correctly in all situations. See the compiler option
  \&\fB\-mrelax\fR and the linker option \fB\-\-relax\fR.
  There are corner cases where the linker is supposed to generate stubs
  but aborts without relaxation and without a helpful error message.
! .IP "*" 4
  The default linker script is arranged for code with \f(CW\*(C`EIND = 0\*(C'\fR.
  If code is supposed to work for a setup with \f(CW\*(C`EIND != 0\*(C'\fR, a custom
  linker script has to be used in order to place the sections whose
  name start with \f(CW\*(C`.trampolines\*(C'\fR into the segment where \f(CW\*(C`EIND\*(C'\fR
  points to.
! .IP "*" 4
  The startup code from libgcc never sets \f(CW\*(C`EIND\*(C'\fR.
! Notice that startup code is a blend of code from libgcc and AVR-LibC.
! For the impact of AVR-LibC on \f(CW\*(C`EIND\*(C'\fR, see the
! AVR-LibC\ user\ manual (\f(CW\*(C`https://www.nongnu.org/avr\-libc/user\-manual/\*(C'\fR).
! .IP "*" 4
! It is legitimate for user-specific startup code to set up \f(CW\*(C`EIND\*(C'\fR
  early, for example by means of initialization code located in
  section \f(CW\*(C`.init3\*(C'\fR. Such code runs prior to general startup code
! that initializes \s-1RAM\s0 and calls constructors, but after the bit
! of startup code from AVR-LibC that sets \f(CW\*(C`EIND\*(C'\fR to the segment
  where the vector table is located.
  .Sp
  .Vb 1
--- 22256,22300 ----
  .PP
  Indirect jumps and calls on these devices are handled as follows by
  the compiler and are subject to some limitations:
! .IP * 4
  The compiler never sets \f(CW\*(C`EIND\*(C'\fR.
! .IP * 4
  The compiler uses \f(CW\*(C`EIND\*(C'\fR implicitly in \f(CW\*(C`EICALL\*(C'\fR/\f(CW\*(C`EIJMP\*(C'\fR
  instructions or might read \f(CW\*(C`EIND\*(C'\fR directly in order to emulate an
  indirect call/jump by means of a \f(CW\*(C`RET\*(C'\fR instruction.
! .IP * 4
  The compiler assumes that \f(CW\*(C`EIND\*(C'\fR never changes during the startup
  code or during the application. In particular, \f(CW\*(C`EIND\*(C'\fR is not
  saved/restored in function or interrupt service routine
  prologue/epilogue.
! .IP * 4
  For indirect calls to functions and computed goto, the linker
  generates \fIstubs\fR. Stubs are jump pads sometimes also called
  \&\fItrampolines\fR. Thus, the indirect call/jump jumps to such a stub.
  The stub contains a direct jump to the desired address.
! .IP * 4
  Linker relaxation must be turned on so that the linker generates
  the stubs correctly in all situations. See the compiler option
  \&\fB\-mrelax\fR and the linker option \fB\-\-relax\fR.
  There are corner cases where the linker is supposed to generate stubs
  but aborts without relaxation and without a helpful error message.
! .IP * 4
  The default linker script is arranged for code with \f(CW\*(C`EIND = 0\*(C'\fR.
  If code is supposed to work for a setup with \f(CW\*(C`EIND != 0\*(C'\fR, a custom
  linker script has to be used in order to place the sections whose
  name start with \f(CW\*(C`.trampolines\*(C'\fR into the segment where \f(CW\*(C`EIND\*(C'\fR
  points to.
! .IP * 4
  The startup code from libgcc never sets \f(CW\*(C`EIND\*(C'\fR.
! Notice that startup code is a blend of code from libgcc and AVR\-LibC.
! For the impact of AVR\-LibC on \f(CW\*(C`EIND\*(C'\fR, see the
! AVR\-LibC\ user\ manual (\f(CW\*(C`https://www.nongnu.org/avr\-libc/user\-manual/\*(C'\fR).
! .IP * 4
! It is legitimate for user\-specific startup code to set up \f(CW\*(C`EIND\*(C'\fR
  early, for example by means of initialization code located in
  section \f(CW\*(C`.init3\*(C'\fR. Such code runs prior to general startup code
! that initializes RAM and calls constructors, but after the bit
! of startup code from AVR\-LibC that sets \f(CW\*(C`EIND\*(C'\fR to the segment
  where the vector table is located.
  .Sp
  .Vb 1
*************** where the vector table is located.
*** 22379,22385 ****
  .Ve
  .Sp
  The \f(CW\*(C`_\|_trampolines_start\*(C'\fR symbol is defined in the linker script.
! .IP "*" 4
  Stubs are generated automatically by the linker if
  the following two conditions are met:
  .RS 4
--- 22310,22316 ----
  .Ve
  .Sp
  The \f(CW\*(C`_\|_trampolines_start\*(C'\fR symbol is defined in the linker script.
! .IP * 4
  Stubs are generated automatically by the linker if
  the following two conditions are met:
  .RS 4
*************** the following two conditions are met:
*** 22398,22404 ****
  .RE
  .RS 4
  .RE
! .IP "*" 4
  The compiler emits such \f(CW\*(C`gs\*(C'\fR modifiers for code labels in the
  following situations:
  .RS 4
--- 22329,22335 ----
  .RE
  .RS 4
  .RE
! .IP * 4
  The compiler emits such \f(CW\*(C`gs\*(C'\fR modifiers for code labels in the
  following situations:
  .RS 4
*************** following situations:
*** 22407,22431 ****
  .PD 0
  .IP "\-" 4
  .IX Item "-"
! .IP "\-" 4
  .IX Item "-"
  .PD
! command-line option.
  .IP "\-" 4
  .IX Item "-"
! tables you can specify the \fB\-fno\-jump\-tables\fR command-line option.
! .IP "\-" 4
! .IX Item "-"
  .PD 0
! .ie n .IP "\-" 4
  .el .IP "\-" 4
  .IX Item "-"
  .RE
  .RS 4
  .RE
! .IP "*" 4
! .PD
! Jumping to non-symbolic addresses like so is \fInot\fR supported:
  .Sp
  .Vb 5
  \&        int main (void)
--- 22338,22362 ----
  .PD 0
  .IP "\-" 4
  .IX Item "-"
! .IP "\-" 4
  .IX Item "-"
  .PD
! command\-line option.
  .IP "\-" 4
  .IX Item "-"
! tables you can specify the \fB\-fno\-jump\-tables\fR command\-line option.
! .IP "\-" 4
! .IX Item "-"
  .PD 0
! .ie n .IP "\-" 4
  .el .IP "\-" 4
  .IX Item "-"
+ .PD
  .RE
  .RS 4
  .RE
! .IP * 4
! Jumping to non\-symbolic addresses like so is \fInot\fR supported:
  .Sp
  .Vb 5
  \&        int main (void)
*************** Alternatively, \f(CW\*(C`func_4\*(C'\fR
*** 22454,22460 ****
  Handling of the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR and \f(CW\*(C`RAMPZ\*(C'\fR Special Function Registers
  .IX Subsection "Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers"
  .PP
! Some \s-1AVR\s0 devices support memories larger than the 64 KiB range
  that can be accessed with 16\-bit pointers.  To access memory locations
  outside this 64 KiB range, the content of a \f(CW\*(C`RAMP\*(C'\fR
  register is used as high part of the address:
--- 22385,22391 ----
  Handling of the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR and \f(CW\*(C`RAMPZ\*(C'\fR Special Function Registers
  .IX Subsection "Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers"
  .PP
! Some AVR devices support memories larger than the 64 KiB range
  that can be accessed with 16\-bit pointers.  To access memory locations
  outside this 64 KiB range, the content of a \f(CW\*(C`RAMP\*(C'\fR
  register is used as high part of the address:
*************** The \f(CW\*(C`X\*(C'\fR, \f(CW\*(C`Y\*(C
*** 22462,22502 ****
  with the \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR, \f(CW\*(C`RAMPZ\*(C'\fR special function
  register, respectively, to get a wide address. Similarly,
  \&\f(CW\*(C`RAMPD\*(C'\fR is used together with direct addressing.
! .IP "*" 4
  The startup code initializes the \f(CW\*(C`RAMP\*(C'\fR special function
  registers with zero.
! .IP "*" 4
! If a \fB\s-1AVR\s0 Named Address Spaces,named address space\fR other than
  generic or \f(CW\*(C`_\|_flash\*(C'\fR is used, then \f(CW\*(C`RAMPZ\*(C'\fR is set
  as needed before the operation.
! .IP "*" 4
! If the device supports \s-1RAM\s0 larger than 64 KiB and the compiler
  needs to change \f(CW\*(C`RAMPZ\*(C'\fR to accomplish an operation, \f(CW\*(C`RAMPZ\*(C'\fR
  is reset to zero after the operation.
! .IP "*" 4
! If the device comes with a specific \f(CW\*(C`RAMP\*(C'\fR register, the \s-1ISR\s0
! prologue/epilogue saves/restores that \s-1SFR\s0 and initializes it with
! zero in case the \s-1ISR\s0 code might (implicitly) use it.
! .IP "*" 4
! \&\s-1RAM\s0 larger than 64 KiB is not supported by \s-1GCC\s0 for \s-1AVR\s0 targets.
  If you use inline assembler to read from locations outside the
  16\-bit address range and change one of the \f(CW\*(C`RAMP\*(C'\fR registers,
  you must reset it to zero after the access.
  .PP
! \s-1AVR\s0 Built-in Macros
  .IX Subsection "AVR Built-in Macros"
  .PP
! \&\s-1GCC\s0 defines several built-in macros so that the user code can test
  for the presence or absence of features.  Almost any of the following
! built-in macros are deduced from device capabilities and thus
! triggered by the \fB\-mmcu=\fR command-line option.
  .PP
! For even more AVR-specific built-in macros see
! \&\fB\s-1AVR\s0 Named Address Spaces\fR and \fB\s-1AVR\s0 Built-in Functions\fR.
  .ie n .IP """_\|_AVR_ARCH_\|_""" 4
! .el .IP "\f(CW_\|_AVR_ARCH_\|_\fR" 4
  .IX Item "__AVR_ARCH__"
! Build-in macro that resolves to a decimal number that identifies the
  architecture and depends on the \fB\-mmcu=\fR\fImcu\fR option.
  Possible values are:
  .Sp
--- 22393,22433 ----
  with the \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR, \f(CW\*(C`RAMPZ\*(C'\fR special function
  register, respectively, to get a wide address. Similarly,
  \&\f(CW\*(C`RAMPD\*(C'\fR is used together with direct addressing.
! .IP * 4
  The startup code initializes the \f(CW\*(C`RAMP\*(C'\fR special function
  registers with zero.
! .IP * 4
! If a \fBAVR Named Address Spaces,named address space\fR other than
  generic or \f(CW\*(C`_\|_flash\*(C'\fR is used, then \f(CW\*(C`RAMPZ\*(C'\fR is set
  as needed before the operation.
! .IP * 4
! If the device supports RAM larger than 64 KiB and the compiler
  needs to change \f(CW\*(C`RAMPZ\*(C'\fR to accomplish an operation, \f(CW\*(C`RAMPZ\*(C'\fR
  is reset to zero after the operation.
! .IP * 4
! If the device comes with a specific \f(CW\*(C`RAMP\*(C'\fR register, the ISR
! prologue/epilogue saves/restores that SFR and initializes it with
! zero in case the ISR code might (implicitly) use it.
! .IP * 4
! RAM larger than 64 KiB is not supported by GCC for AVR targets.
  If you use inline assembler to read from locations outside the
  16\-bit address range and change one of the \f(CW\*(C`RAMP\*(C'\fR registers,
  you must reset it to zero after the access.
  .PP
! AVR Built\-in Macros
  .IX Subsection "AVR Built-in Macros"
  .PP
! GCC defines several built\-in macros so that the user code can test
  for the presence or absence of features.  Almost any of the following
! built\-in macros are deduced from device capabilities and thus
! triggered by the \fB\-mmcu=\fR command\-line option.
  .PP
! For even more AVR\-specific built\-in macros see
! \&\fBAVR Named Address Spaces\fR and \fBAVR Built\-in Functions\fR.
  .ie n .IP """_\|_AVR_ARCH_\|_""" 4
! .el .IP \f(CW_\|_AVR_ARCH_\|_\fR 4
  .IX Item "__AVR_ARCH__"
! Build\-in macro that resolves to a decimal number that identifies the
  architecture and depends on the \fB\-mmcu=\fR\fImcu\fR option.
  Possible values are:
  .Sp
*************** respectively and
*** 22515,22778 ****
  for \fImcu\fR=\f(CW\*(C`avrtiny\*(C'\fR,
  \&\f(CW\*(C`avrxmega2\*(C'\fR, \f(CW\*(C`avrxmega3\*(C'\fR, \f(CW\*(C`avrxmega4\*(C'\fR,
  \&\f(CW\*(C`avrxmega5\*(C'\fR, \f(CW\*(C`avrxmega6\*(C'\fR, \f(CW\*(C`avrxmega7\*(C'\fR, respectively.
! If \fImcu\fR specifies a device, this built-in macro is set
  accordingly. For example, with \fB\-mmcu=atmega8\fR the macro is
  defined to \f(CW4\fR.
! .ie n .IP """_\|_AVR_\fIDevice\fP_\|_""" 4
! .el .IP "\f(CW_\|_AVR_\f(CIDevice\f(CW_\|_\fR" 4
  .IX Item "__AVR_Device__"
! Setting \fB\-mmcu=\fR\fIdevice\fR defines this built-in macro which reflects
! the device's name. For example, \fB\-mmcu=atmega8\fR defines the
! built-in macro \f(CW\*(C`_\|_AVR_ATmega8_\|_\*(C'\fR, \fB\-mmcu=attiny261a\fR defines
  \&\f(CW\*(C`_\|_AVR_ATtiny261A_\|_\*(C'\fR, etc.
  .Sp
! The built-in macros' names follow
! the scheme \f(CW\*(C`_\|_AVR_\f(CIDevice\f(CW_\|_\*(C'\fR where \fIDevice\fR is
! the device name as from the \s-1AVR\s0 user manual. The difference between
! \&\fIDevice\fR in the built-in macro and \fIdevice\fR in
  \&\fB\-mmcu=\fR\fIdevice\fR is that the latter is always lowercase.
  .Sp
  If \fIdevice\fR is not a device but only a core architecture like
  \&\fBavr51\fR, this macro is not defined.
  .ie n .IP """_\|_AVR_DEVICE_NAME_\|_""" 4
! .el .IP "\f(CW_\|_AVR_DEVICE_NAME_\|_\fR" 4
  .IX Item "__AVR_DEVICE_NAME__"
! Setting \fB\-mmcu=\fR\fIdevice\fR defines this built-in macro to
! the device's name. For example, with \fB\-mmcu=atmega8\fR the macro
  is defined to \f(CW\*(C`atmega8\*(C'\fR.
  .Sp
  If \fIdevice\fR is not a device but only a core architecture like
  \&\fBavr51\fR, this macro is not defined.
  .ie n .IP """_\|_AVR_XMEGA_\|_""" 4
! .el .IP "\f(CW_\|_AVR_XMEGA_\|_\fR" 4
  .IX Item "__AVR_XMEGA__"
! The device / architecture belongs to the \s-1XMEGA\s0 family of devices.
  .ie n .IP """_\|_AVR_HAVE_ADIW_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_ADIW_\|_\fR" 4
  .IX Item "__AVR_HAVE_ADIW__"
  The device has the \f(CW\*(C`ADIW\*(C'\fR and \f(CW\*(C`SBIW\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_ELPM_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_ELPM_\|_\fR" 4
  .IX Item "__AVR_HAVE_ELPM__"
  The device has the \f(CW\*(C`ELPM\*(C'\fR instruction.
  .ie n .IP """_\|_AVR_HAVE_ELPMX_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_ELPMX_\|_\fR" 4
  .IX Item "__AVR_HAVE_ELPMX__"
! The device has the \f(CW\*(C`ELPM R\f(CIn\f(CW,Z\*(C'\fR and \f(CW\*(C`ELPM
! R\f(CIn\f(CW,Z+\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_LPMX_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_LPMX_\|_\fR" 4
  .IX Item "__AVR_HAVE_LPMX__"
! The device has the \f(CW\*(C`LPM R\f(CIn\f(CW,Z\*(C'\fR and
! \&\f(CW\*(C`LPM R\f(CIn\f(CW,Z+\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_MOVW_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_MOVW_\|_\fR" 4
  .IX Item "__AVR_HAVE_MOVW__"
  The device has the \f(CW\*(C`MOVW\*(C'\fR instruction to perform 16\-bit
! register-register moves.
  .ie n .IP """_\|_AVR_HAVE_MUL_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_MUL_\|_\fR" 4
  .IX Item "__AVR_HAVE_MUL__"
  The device has a hardware multiplier.
  .ie n .IP """_\|_AVR_HAVE_JMP_CALL_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_JMP_CALL_\|_\fR" 4
  .IX Item "__AVR_HAVE_JMP_CALL__"
  The device has the \f(CW\*(C`JMP\*(C'\fR and \f(CW\*(C`CALL\*(C'\fR instructions.
  This is the case for devices with more than 8 KiB of program
  memory.
  .ie n .IP """_\|_AVR_HAVE_EIJMP_EICALL_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_EIJMP_EICALL_\|_\fR" 4
  .IX Item "__AVR_HAVE_EIJMP_EICALL__"
  .PD 0
  .ie n .IP """_\|_AVR_3_BYTE_PC_\|_""" 4
! .el .IP "\f(CW_\|_AVR_3_BYTE_PC_\|_\fR" 4
  .IX Item "__AVR_3_BYTE_PC__"
  .PD
  The device has the \f(CW\*(C`EIJMP\*(C'\fR and \f(CW\*(C`EICALL\*(C'\fR instructions.
  This is the case for devices with more than 128 KiB of program memory.
  This also means that the program counter
! (\s-1PC\s0) is 3 bytes wide.
  .ie n .IP """_\|_AVR_2_BYTE_PC_\|_""" 4
! .el .IP "\f(CW_\|_AVR_2_BYTE_PC_\|_\fR" 4
  .IX Item "__AVR_2_BYTE_PC__"
! The program counter (\s-1PC\s0) is 2 bytes wide. This is the case for devices
  with up to 128 KiB of program memory.
  .ie n .IP """_\|_AVR_HAVE_8BIT_SP_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_8BIT_SP_\|_\fR" 4
  .IX Item "__AVR_HAVE_8BIT_SP__"
  .PD 0
  .ie n .IP """_\|_AVR_HAVE_16BIT_SP_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_16BIT_SP_\|_\fR" 4
  .IX Item "__AVR_HAVE_16BIT_SP__"
  .PD
! The stack pointer (\s-1SP\s0) register is treated as 8\-bit respectively
  16\-bit register by the compiler.
  The definition of these macros is affected by \fB\-mtiny\-stack\fR.
  .ie n .IP """_\|_AVR_HAVE_SPH_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_SPH_\|_\fR" 4
  .IX Item "__AVR_HAVE_SPH__"
  .PD 0
  .ie n .IP """_\|_AVR_SP8_\|_""" 4
! .el .IP "\f(CW_\|_AVR_SP8_\|_\fR" 4
  .IX Item "__AVR_SP8__"
  .PD
! The device has the \s-1SPH\s0 (high part of stack pointer) special function
  register or has an 8\-bit stack pointer, respectively.
  The definition of these macros is affected by \fB\-mmcu=\fR and
  in the cases of \fB\-mmcu=avr2\fR and \fB\-mmcu=avr25\fR also
  by \fB\-msp8\fR.
  .ie n .IP """_\|_AVR_HAVE_RAMPD_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_RAMPD_\|_\fR" 4
  .IX Item "__AVR_HAVE_RAMPD__"
  .PD 0
  .ie n .IP """_\|_AVR_HAVE_RAMPX_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_RAMPX_\|_\fR" 4
  .IX Item "__AVR_HAVE_RAMPX__"
  .ie n .IP """_\|_AVR_HAVE_RAMPY_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_RAMPY_\|_\fR" 4
  .IX Item "__AVR_HAVE_RAMPY__"
  .ie n .IP """_\|_AVR_HAVE_RAMPZ_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_RAMPZ_\|_\fR" 4
  .IX Item "__AVR_HAVE_RAMPZ__"
  .PD
  The device has the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR,
  \&\f(CW\*(C`RAMPZ\*(C'\fR special function register, respectively.
  .ie n .IP """_\|_NO_INTERRUPTS_\|_""" 4
! .el .IP "\f(CW_\|_NO_INTERRUPTS_\|_\fR" 4
  .IX Item "__NO_INTERRUPTS__"
! This macro reflects the \fB\-mno\-interrupts\fR command-line option.
  .ie n .IP """_\|_AVR_ERRATA_SKIP_\|_""" 4
! .el .IP "\f(CW_\|_AVR_ERRATA_SKIP_\|_\fR" 4
  .IX Item "__AVR_ERRATA_SKIP__"
  .PD 0
  .ie n .IP """_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_""" 4
! .el .IP "\f(CW_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_\fR" 4
  .IX Item "__AVR_ERRATA_SKIP_JMP_CALL__"
  .PD
! Some \s-1AVR\s0 devices (\s-1AT90S8515,\s0 ATmega103) must not skip 32\-bit
  instructions because of a hardware erratum.  Skip instructions are
  \&\f(CW\*(C`SBRS\*(C'\fR, \f(CW\*(C`SBRC\*(C'\fR, \f(CW\*(C`SBIS\*(C'\fR, \f(CW\*(C`SBIC\*(C'\fR and \f(CW\*(C`CPSE\*(C'\fR.
  The second macro is only defined if \f(CW\*(C`_\|_AVR_HAVE_JMP_CALL_\|_\*(C'\fR is also
  set.
  .ie n .IP """_\|_AVR_ISA_RMW_\|_""" 4
! .el .IP "\f(CW_\|_AVR_ISA_RMW_\|_\fR" 4
  .IX Item "__AVR_ISA_RMW__"
! The device has Read-Modify-Write instructions (\s-1XCH, LAC, LAS\s0 and \s-1LAT\s0).
! .ie n .IP """_\|_AVR_SFR_OFFSET_\|_=\fIoffset\fP""" 4
! .el .IP "\f(CW_\|_AVR_SFR_OFFSET_\|_=\f(CIoffset\f(CW\fR" 4
  .IX Item "__AVR_SFR_OFFSET__=offset"
  Instructions that can address I/O special function registers directly
  like \f(CW\*(C`IN\*(C'\fR, \f(CW\*(C`OUT\*(C'\fR, \f(CW\*(C`SBI\*(C'\fR, etc. may use a different
! address as if addressed by an instruction to access \s-1RAM\s0 like \f(CW\*(C`LD\*(C'\fR
  or \f(CW\*(C`STS\*(C'\fR. This offset depends on the device architecture and has
! to be subtracted from the \s-1RAM\s0 address in order to get the
  respective I/O address.
  .ie n .IP """_\|_AVR_SHORT_CALLS_\|_""" 4
! .el .IP "\f(CW_\|_AVR_SHORT_CALLS_\|_\fR" 4
  .IX Item "__AVR_SHORT_CALLS__"
  The \fB\-mshort\-calls\fR command line option is set.
! .ie n .IP """_\|_AVR_PM_BASE_ADDRESS_\|_=\fIaddr\fP""" 4
! .el .IP "\f(CW_\|_AVR_PM_BASE_ADDRESS_\|_=\f(CIaddr\f(CW\fR" 4
  .IX Item "__AVR_PM_BASE_ADDRESS__=addr"
  Some devices support reading from flash memory by means of \f(CW\*(C`LD*\*(C'\fR
  instructions.  The flash memory is seen in the data address space
  at an offset of \f(CW\*(C`_\|_AVR_PM_BASE_ADDRESS_\|_\*(C'\fR.  If this macro
  is not defined, this feature is not available.  If defined,
  the address space is linear and there is no need to put
! \&\f(CW\*(C`.rodata\*(C'\fR into \s-1RAM.\s0  This is handled by the default linker
  description file, and is currently available for
  \&\f(CW\*(C`avrtiny\*(C'\fR and \f(CW\*(C`avrxmega3\*(C'\fR.  Even more convenient,
  there is no need to use address spaces like \f(CW\*(C`_\|_flash\*(C'\fR or
  features like attribute \f(CW\*(C`progmem\*(C'\fR and \f(CW\*(C`pgm_read_*\*(C'\fR.
  .ie n .IP """_\|_WITH_AVRLIBC_\|_""" 4
! .el .IP "\f(CW_\|_WITH_AVRLIBC_\|_\fR" 4
  .IX Item "__WITH_AVRLIBC__"
! The compiler is configured to be used together with AVR-Libc.
  See the \fB\-\-with\-avrlibc\fR configure option.
  .ie n .IP """_\|_HAVE_DOUBLE_MULTILIB_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_DOUBLE_MULTILIB_\|_\fR" 4
  .IX Item "__HAVE_DOUBLE_MULTILIB__"
  Defined if \fB\-mdouble=\fR acts as a multilib option.
  .ie n .IP """_\|_HAVE_DOUBLE32_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_DOUBLE32_\|_\fR" 4
  .IX Item "__HAVE_DOUBLE32__"
  .PD 0
  .ie n .IP """_\|_HAVE_DOUBLE64_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_DOUBLE64_\|_\fR" 4
  .IX Item "__HAVE_DOUBLE64__"
  .PD
  Defined if the compiler supports 32\-bit double resp. 64\-bit double.
  The actual layout is specified by option \fB\-mdouble=\fR.
  .ie n .IP """_\|_DEFAULT_DOUBLE_\|_""" 4
! .el .IP "\f(CW_\|_DEFAULT_DOUBLE_\|_\fR" 4
  .IX Item "__DEFAULT_DOUBLE__"
  The size in bits of \f(CW\*(C`double\*(C'\fR if \fB\-mdouble=\fR is not set.
! To test the layout of \f(CW\*(C`double\*(C'\fR in a program, use the built-in
  macro \f(CW\*(C`_\|_SIZEOF_DOUBLE_\|_\*(C'\fR.
  .ie n .IP """_\|_HAVE_LONG_DOUBLE32_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_LONG_DOUBLE32_\|_\fR" 4
  .IX Item "__HAVE_LONG_DOUBLE32__"
  .PD 0
  .ie n .IP """_\|_HAVE_LONG_DOUBLE64_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_LONG_DOUBLE64_\|_\fR" 4
  .IX Item "__HAVE_LONG_DOUBLE64__"
  .ie n .IP """_\|_HAVE_LONG_DOUBLE_MULTILIB_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_LONG_DOUBLE_MULTILIB_\|_\fR" 4
  .IX Item "__HAVE_LONG_DOUBLE_MULTILIB__"
  .ie n .IP """_\|_DEFAULT_LONG_DOUBLE_\|_""" 4
! .el .IP "\f(CW_\|_DEFAULT_LONG_DOUBLE_\|_\fR" 4
  .IX Item "__DEFAULT_LONG_DOUBLE__"
  .PD
  Same as above, but for \f(CW\*(C`long double\*(C'\fR instead of \f(CW\*(C`double\*(C'\fR.
  .ie n .IP """_\|_WITH_DOUBLE_COMPARISON_\|_""" 4
! .el .IP "\f(CW_\|_WITH_DOUBLE_COMPARISON_\|_\fR" 4
  .IX Item "__WITH_DOUBLE_COMPARISON__"
  Reflects the \f(CW\*(C`\-\-with\-double\-comparison={tristate|bool|libf7}\*(C'\fR
  configure\ option (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR)
  and is defined to \f(CW2\fR or \f(CW3\fR.
  .ie n .IP """_\|_WITH_LIBF7_LIBGCC_\|_""" 4
! .el .IP "\f(CW_\|_WITH_LIBF7_LIBGCC_\|_\fR" 4
  .IX Item "__WITH_LIBF7_LIBGCC__"
  .PD 0
  .ie n .IP """_\|_WITH_LIBF7_MATH_\|_""" 4
! .el .IP "\f(CW_\|_WITH_LIBF7_MATH_\|_\fR" 4
  .IX Item "__WITH_LIBF7_MATH__"
  .ie n .IP """_\|_WITH_LIBF7_MATH_SYMBOLS_\|_""" 4
! .el .IP "\f(CW_\|_WITH_LIBF7_MATH_SYMBOLS_\|_\fR" 4
  .IX Item "__WITH_LIBF7_MATH_SYMBOLS__"
  .PD
  Reflects the \f(CW\*(C`\-\-with\-libf7={libgcc|math|math\-symbols}\*(C'\fR
  configure\ option (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR).
  .PP
! \s-1AVR\s0 Internal Options
  .IX Subsection "AVR Internal Options"
  .PP
  The following options are used internally by the compiler and to communicate
! between device specs files and the compiler proper. You don't need to set these
  options by hand, in particular they are not optimization options.
! Using these options in the wrong way may lead to sub-optimal or wrong code.
  They are documented for completeness, and in order to get a better
  understanding of
  device\ specs (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#spec\-files\*(C'\fR)
  files.
! .IP "\fB\-mn\-flash=\fR\fInum\fR" 4
  .IX Item "-mn-flash=num"
  Assume that the flash memory has a size of \fInum\fR times 64 KiB.
! This determines which \f(CW\*(C`_\|_flash\f(CIN\f(CW\*(C'\fR address spaces are available.
! .IP "\fB\-mrmw\fR" 4
  .IX Item "-mrmw"
! Assume that the device supports the Read-Modify-Write
  instructions \f(CW\*(C`XCH\*(C'\fR, \f(CW\*(C`LAC\*(C'\fR, \f(CW\*(C`LAS\*(C'\fR and \f(CW\*(C`LAT\*(C'\fR.
! .IP "\fB\-mshort\-calls\fR" 4
  .IX Item "-mshort-calls"
  Assume that \f(CW\*(C`RJMP\*(C'\fR and \f(CW\*(C`RCALL\*(C'\fR can target the whole
  program memory. This option is used for multilib generation and selection
  for the devices from architecture \f(CW\*(C`avrxmega3\*(C'\fR.
! .IP "\fB\-mskip\-bug\fR" 4
  .IX Item "-mskip-bug"
  Generate code without skips (\f(CW\*(C`CPSE\*(C'\fR, \f(CW\*(C`SBRS\*(C'\fR,
  \&\f(CW\*(C`SBRC\*(C'\fR, \f(CW\*(C`SBIS\*(C'\fR, \f(CW\*(C`SBIC\*(C'\fR) over 32\-bit instructions.
! .IP "\fB\-msp8\fR" 4
  .IX Item "-msp8"
  Treat the stack pointer register as an 8\-bit register,
  i.e. assume the high byte of the stack pointer is zero.
--- 22446,22709 ----
  for \fImcu\fR=\f(CW\*(C`avrtiny\*(C'\fR,
  \&\f(CW\*(C`avrxmega2\*(C'\fR, \f(CW\*(C`avrxmega3\*(C'\fR, \f(CW\*(C`avrxmega4\*(C'\fR,
  \&\f(CW\*(C`avrxmega5\*(C'\fR, \f(CW\*(C`avrxmega6\*(C'\fR, \f(CW\*(C`avrxmega7\*(C'\fR, respectively.
! If \fImcu\fR specifies a device, this built\-in macro is set
  accordingly. For example, with \fB\-mmcu=atmega8\fR the macro is
  defined to \f(CW4\fR.
! .ie n .IP """_\|_AVR_\fIDevice\fR_\|_""" 4
! .el .IP \f(CW_\|_AVR_\fR\f(CIDevice\fR\f(CW_\|_\fR 4
  .IX Item "__AVR_Device__"
! Setting \fB\-mmcu=\fR\fIdevice\fR defines this built\-in macro which reflects
! the device\*(Aqs name. For example, \fB\-mmcu=atmega8\fR defines the
! built\-in macro \f(CW\*(C`_\|_AVR_ATmega8_\|_\*(C'\fR, \fB\-mmcu=attiny261a\fR defines
  \&\f(CW\*(C`_\|_AVR_ATtiny261A_\|_\*(C'\fR, etc.
  .Sp
! The built\-in macros\*(Aq names follow
! the scheme \f(CW\*(C`_\|_AVR_\fR\f(CIDevice\fR\f(CW_\|_\*(C'\fR where \fIDevice\fR is
! the device name as from the AVR user manual. The difference between
! \&\fIDevice\fR in the built\-in macro and \fIdevice\fR in
  \&\fB\-mmcu=\fR\fIdevice\fR is that the latter is always lowercase.
  .Sp
  If \fIdevice\fR is not a device but only a core architecture like
  \&\fBavr51\fR, this macro is not defined.
  .ie n .IP """_\|_AVR_DEVICE_NAME_\|_""" 4
! .el .IP \f(CW_\|_AVR_DEVICE_NAME_\|_\fR 4
  .IX Item "__AVR_DEVICE_NAME__"
! Setting \fB\-mmcu=\fR\fIdevice\fR defines this built\-in macro to
! the device\*(Aqs name. For example, with \fB\-mmcu=atmega8\fR the macro
  is defined to \f(CW\*(C`atmega8\*(C'\fR.
  .Sp
  If \fIdevice\fR is not a device but only a core architecture like
  \&\fBavr51\fR, this macro is not defined.
  .ie n .IP """_\|_AVR_XMEGA_\|_""" 4
! .el .IP \f(CW_\|_AVR_XMEGA_\|_\fR 4
  .IX Item "__AVR_XMEGA__"
! The device / architecture belongs to the XMEGA family of devices.
  .ie n .IP """_\|_AVR_HAVE_ADIW_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_ADIW_\|_\fR 4
  .IX Item "__AVR_HAVE_ADIW__"
  The device has the \f(CW\*(C`ADIW\*(C'\fR and \f(CW\*(C`SBIW\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_ELPM_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_ELPM_\|_\fR 4
  .IX Item "__AVR_HAVE_ELPM__"
  The device has the \f(CW\*(C`ELPM\*(C'\fR instruction.
  .ie n .IP """_\|_AVR_HAVE_ELPMX_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_ELPMX_\|_\fR 4
  .IX Item "__AVR_HAVE_ELPMX__"
! The device has the \f(CW\*(C`ELPM R\fR\f(CIn\fR\f(CW,Z\*(C'\fR and \f(CW\*(C`ELPM
! R\fR\f(CIn\fR\f(CW,Z+\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_LPMX_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_LPMX_\|_\fR 4
  .IX Item "__AVR_HAVE_LPMX__"
! The device has the \f(CW\*(C`LPM R\fR\f(CIn\fR\f(CW,Z\*(C'\fR and
! \&\f(CW\*(C`LPM R\fR\f(CIn\fR\f(CW,Z+\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_MOVW_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_MOVW_\|_\fR 4
  .IX Item "__AVR_HAVE_MOVW__"
  The device has the \f(CW\*(C`MOVW\*(C'\fR instruction to perform 16\-bit
! register\-register moves.
  .ie n .IP """_\|_AVR_HAVE_MUL_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_MUL_\|_\fR 4
  .IX Item "__AVR_HAVE_MUL__"
  The device has a hardware multiplier.
  .ie n .IP """_\|_AVR_HAVE_JMP_CALL_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_JMP_CALL_\|_\fR 4
  .IX Item "__AVR_HAVE_JMP_CALL__"
  The device has the \f(CW\*(C`JMP\*(C'\fR and \f(CW\*(C`CALL\*(C'\fR instructions.
  This is the case for devices with more than 8 KiB of program
  memory.
  .ie n .IP """_\|_AVR_HAVE_EIJMP_EICALL_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_EIJMP_EICALL_\|_\fR 4
  .IX Item "__AVR_HAVE_EIJMP_EICALL__"
  .PD 0
  .ie n .IP """_\|_AVR_3_BYTE_PC_\|_""" 4
! .el .IP \f(CW_\|_AVR_3_BYTE_PC_\|_\fR 4
  .IX Item "__AVR_3_BYTE_PC__"
  .PD
  The device has the \f(CW\*(C`EIJMP\*(C'\fR and \f(CW\*(C`EICALL\*(C'\fR instructions.
  This is the case for devices with more than 128 KiB of program memory.
  This also means that the program counter
! (PC) is 3 bytes wide.
  .ie n .IP """_\|_AVR_2_BYTE_PC_\|_""" 4
! .el .IP \f(CW_\|_AVR_2_BYTE_PC_\|_\fR 4
  .IX Item "__AVR_2_BYTE_PC__"
! The program counter (PC) is 2 bytes wide. This is the case for devices
  with up to 128 KiB of program memory.
  .ie n .IP """_\|_AVR_HAVE_8BIT_SP_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_8BIT_SP_\|_\fR 4
  .IX Item "__AVR_HAVE_8BIT_SP__"
  .PD 0
  .ie n .IP """_\|_AVR_HAVE_16BIT_SP_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_16BIT_SP_\|_\fR 4
  .IX Item "__AVR_HAVE_16BIT_SP__"
  .PD
! The stack pointer (SP) register is treated as 8\-bit respectively
  16\-bit register by the compiler.
  The definition of these macros is affected by \fB\-mtiny\-stack\fR.
  .ie n .IP """_\|_AVR_HAVE_SPH_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_SPH_\|_\fR 4
  .IX Item "__AVR_HAVE_SPH__"
  .PD 0
  .ie n .IP """_\|_AVR_SP8_\|_""" 4
! .el .IP \f(CW_\|_AVR_SP8_\|_\fR 4
  .IX Item "__AVR_SP8__"
  .PD
! The device has the SPH (high part of stack pointer) special function
  register or has an 8\-bit stack pointer, respectively.
  The definition of these macros is affected by \fB\-mmcu=\fR and
  in the cases of \fB\-mmcu=avr2\fR and \fB\-mmcu=avr25\fR also
  by \fB\-msp8\fR.
  .ie n .IP """_\|_AVR_HAVE_RAMPD_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_RAMPD_\|_\fR 4
  .IX Item "__AVR_HAVE_RAMPD__"
  .PD 0
  .ie n .IP """_\|_AVR_HAVE_RAMPX_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_RAMPX_\|_\fR 4
  .IX Item "__AVR_HAVE_RAMPX__"
  .ie n .IP """_\|_AVR_HAVE_RAMPY_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_RAMPY_\|_\fR 4
  .IX Item "__AVR_HAVE_RAMPY__"
  .ie n .IP """_\|_AVR_HAVE_RAMPZ_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_RAMPZ_\|_\fR 4
  .IX Item "__AVR_HAVE_RAMPZ__"
  .PD
  The device has the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR,
  \&\f(CW\*(C`RAMPZ\*(C'\fR special function register, respectively.
  .ie n .IP """_\|_NO_INTERRUPTS_\|_""" 4
! .el .IP \f(CW_\|_NO_INTERRUPTS_\|_\fR 4
  .IX Item "__NO_INTERRUPTS__"
! This macro reflects the \fB\-mno\-interrupts\fR command\-line option.
  .ie n .IP """_\|_AVR_ERRATA_SKIP_\|_""" 4
! .el .IP \f(CW_\|_AVR_ERRATA_SKIP_\|_\fR 4
  .IX Item "__AVR_ERRATA_SKIP__"
  .PD 0
  .ie n .IP """_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_""" 4
! .el .IP \f(CW_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_\fR 4
  .IX Item "__AVR_ERRATA_SKIP_JMP_CALL__"
  .PD
! Some AVR devices (AT90S8515, ATmega103) must not skip 32\-bit
  instructions because of a hardware erratum.  Skip instructions are
  \&\f(CW\*(C`SBRS\*(C'\fR, \f(CW\*(C`SBRC\*(C'\fR, \f(CW\*(C`SBIS\*(C'\fR, \f(CW\*(C`SBIC\*(C'\fR and \f(CW\*(C`CPSE\*(C'\fR.
  The second macro is only defined if \f(CW\*(C`_\|_AVR_HAVE_JMP_CALL_\|_\*(C'\fR is also
  set.
  .ie n .IP """_\|_AVR_ISA_RMW_\|_""" 4
! .el .IP \f(CW_\|_AVR_ISA_RMW_\|_\fR 4
  .IX Item "__AVR_ISA_RMW__"
! The device has Read\-Modify\-Write instructions (XCH, LAC, LAS and LAT).
! .ie n .IP """_\|_AVR_SFR_OFFSET_\|_=\fIoffset\fR""" 4
! .el .IP \f(CW_\|_AVR_SFR_OFFSET_\|_=\fR\f(CIoffset\fR\f(CW\fR 4
  .IX Item "__AVR_SFR_OFFSET__=offset"
  Instructions that can address I/O special function registers directly
  like \f(CW\*(C`IN\*(C'\fR, \f(CW\*(C`OUT\*(C'\fR, \f(CW\*(C`SBI\*(C'\fR, etc. may use a different
! address as if addressed by an instruction to access RAM like \f(CW\*(C`LD\*(C'\fR
  or \f(CW\*(C`STS\*(C'\fR. This offset depends on the device architecture and has
! to be subtracted from the RAM address in order to get the
  respective I/O address.
  .ie n .IP """_\|_AVR_SHORT_CALLS_\|_""" 4
! .el .IP \f(CW_\|_AVR_SHORT_CALLS_\|_\fR 4
  .IX Item "__AVR_SHORT_CALLS__"
  The \fB\-mshort\-calls\fR command line option is set.
! .ie n .IP """_\|_AVR_PM_BASE_ADDRESS_\|_=\fIaddr\fR""" 4
! .el .IP \f(CW_\|_AVR_PM_BASE_ADDRESS_\|_=\fR\f(CIaddr\fR\f(CW\fR 4
  .IX Item "__AVR_PM_BASE_ADDRESS__=addr"
  Some devices support reading from flash memory by means of \f(CW\*(C`LD*\*(C'\fR
  instructions.  The flash memory is seen in the data address space
  at an offset of \f(CW\*(C`_\|_AVR_PM_BASE_ADDRESS_\|_\*(C'\fR.  If this macro
  is not defined, this feature is not available.  If defined,
  the address space is linear and there is no need to put
! \&\f(CW\*(C`.rodata\*(C'\fR into RAM.  This is handled by the default linker
  description file, and is currently available for
  \&\f(CW\*(C`avrtiny\*(C'\fR and \f(CW\*(C`avrxmega3\*(C'\fR.  Even more convenient,
  there is no need to use address spaces like \f(CW\*(C`_\|_flash\*(C'\fR or
  features like attribute \f(CW\*(C`progmem\*(C'\fR and \f(CW\*(C`pgm_read_*\*(C'\fR.
  .ie n .IP """_\|_WITH_AVRLIBC_\|_""" 4
! .el .IP \f(CW_\|_WITH_AVRLIBC_\|_\fR 4
  .IX Item "__WITH_AVRLIBC__"
! The compiler is configured to be used together with AVR\-Libc.
  See the \fB\-\-with\-avrlibc\fR configure option.
  .ie n .IP """_\|_HAVE_DOUBLE_MULTILIB_\|_""" 4
! .el .IP \f(CW_\|_HAVE_DOUBLE_MULTILIB_\|_\fR 4
  .IX Item "__HAVE_DOUBLE_MULTILIB__"
  Defined if \fB\-mdouble=\fR acts as a multilib option.
  .ie n .IP """_\|_HAVE_DOUBLE32_\|_""" 4
! .el .IP \f(CW_\|_HAVE_DOUBLE32_\|_\fR 4
  .IX Item "__HAVE_DOUBLE32__"
  .PD 0
  .ie n .IP """_\|_HAVE_DOUBLE64_\|_""" 4
! .el .IP \f(CW_\|_HAVE_DOUBLE64_\|_\fR 4
  .IX Item "__HAVE_DOUBLE64__"
  .PD
  Defined if the compiler supports 32\-bit double resp. 64\-bit double.
  The actual layout is specified by option \fB\-mdouble=\fR.
  .ie n .IP """_\|_DEFAULT_DOUBLE_\|_""" 4
! .el .IP \f(CW_\|_DEFAULT_DOUBLE_\|_\fR 4
  .IX Item "__DEFAULT_DOUBLE__"
  The size in bits of \f(CW\*(C`double\*(C'\fR if \fB\-mdouble=\fR is not set.
! To test the layout of \f(CW\*(C`double\*(C'\fR in a program, use the built\-in
  macro \f(CW\*(C`_\|_SIZEOF_DOUBLE_\|_\*(C'\fR.
  .ie n .IP """_\|_HAVE_LONG_DOUBLE32_\|_""" 4
! .el .IP \f(CW_\|_HAVE_LONG_DOUBLE32_\|_\fR 4
  .IX Item "__HAVE_LONG_DOUBLE32__"
  .PD 0
  .ie n .IP """_\|_HAVE_LONG_DOUBLE64_\|_""" 4
! .el .IP \f(CW_\|_HAVE_LONG_DOUBLE64_\|_\fR 4
  .IX Item "__HAVE_LONG_DOUBLE64__"
  .ie n .IP """_\|_HAVE_LONG_DOUBLE_MULTILIB_\|_""" 4
! .el .IP \f(CW_\|_HAVE_LONG_DOUBLE_MULTILIB_\|_\fR 4
  .IX Item "__HAVE_LONG_DOUBLE_MULTILIB__"
  .ie n .IP """_\|_DEFAULT_LONG_DOUBLE_\|_""" 4
! .el .IP \f(CW_\|_DEFAULT_LONG_DOUBLE_\|_\fR 4
  .IX Item "__DEFAULT_LONG_DOUBLE__"
  .PD
  Same as above, but for \f(CW\*(C`long double\*(C'\fR instead of \f(CW\*(C`double\*(C'\fR.
  .ie n .IP """_\|_WITH_DOUBLE_COMPARISON_\|_""" 4
! .el .IP \f(CW_\|_WITH_DOUBLE_COMPARISON_\|_\fR 4
  .IX Item "__WITH_DOUBLE_COMPARISON__"
  Reflects the \f(CW\*(C`\-\-with\-double\-comparison={tristate|bool|libf7}\*(C'\fR
  configure\ option (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR)
  and is defined to \f(CW2\fR or \f(CW3\fR.
  .ie n .IP """_\|_WITH_LIBF7_LIBGCC_\|_""" 4
! .el .IP \f(CW_\|_WITH_LIBF7_LIBGCC_\|_\fR 4
  .IX Item "__WITH_LIBF7_LIBGCC__"
  .PD 0
  .ie n .IP """_\|_WITH_LIBF7_MATH_\|_""" 4
! .el .IP \f(CW_\|_WITH_LIBF7_MATH_\|_\fR 4
  .IX Item "__WITH_LIBF7_MATH__"
  .ie n .IP """_\|_WITH_LIBF7_MATH_SYMBOLS_\|_""" 4
! .el .IP \f(CW_\|_WITH_LIBF7_MATH_SYMBOLS_\|_\fR 4
  .IX Item "__WITH_LIBF7_MATH_SYMBOLS__"
  .PD
  Reflects the \f(CW\*(C`\-\-with\-libf7={libgcc|math|math\-symbols}\*(C'\fR
  configure\ option (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR).
  .PP
! AVR Internal Options
  .IX Subsection "AVR Internal Options"
  .PP
  The following options are used internally by the compiler and to communicate
! between device specs files and the compiler proper. You don\*(Aqt need to set these
  options by hand, in particular they are not optimization options.
! Using these options in the wrong way may lead to sub\-optimal or wrong code.
  They are documented for completeness, and in order to get a better
  understanding of
  device\ specs (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#spec\-files\*(C'\fR)
  files.
! .IP \fB\-mn\-flash=\fR\fInum\fR 4
  .IX Item "-mn-flash=num"
  Assume that the flash memory has a size of \fInum\fR times 64 KiB.
! This determines which \f(CW\*(C`_\|_flash\fR\f(CIN\fR\f(CW\*(C'\fR address spaces are available.
! .IP \fB\-mrmw\fR 4
  .IX Item "-mrmw"
! Assume that the device supports the Read\-Modify\-Write
  instructions \f(CW\*(C`XCH\*(C'\fR, \f(CW\*(C`LAC\*(C'\fR, \f(CW\*(C`LAS\*(C'\fR and \f(CW\*(C`LAT\*(C'\fR.
! .IP \fB\-mshort\-calls\fR 4
  .IX Item "-mshort-calls"
  Assume that \f(CW\*(C`RJMP\*(C'\fR and \f(CW\*(C`RCALL\*(C'\fR can target the whole
  program memory. This option is used for multilib generation and selection
  for the devices from architecture \f(CW\*(C`avrxmega3\*(C'\fR.
! .IP \fB\-mskip\-bug\fR 4
  .IX Item "-mskip-bug"
  Generate code without skips (\f(CW\*(C`CPSE\*(C'\fR, \f(CW\*(C`SBRS\*(C'\fR,
  \&\f(CW\*(C`SBRC\*(C'\fR, \f(CW\*(C`SBIS\*(C'\fR, \f(CW\*(C`SBIC\*(C'\fR) over 32\-bit instructions.
! .IP \fB\-msp8\fR 4
  .IX Item "-msp8"
  Treat the stack pointer register as an 8\-bit register,
  i.e. assume the high byte of the stack pointer is zero.
*************** These architectures mix devices with and
*** 22782,22788 ****
  .PP
  \fIBlackfin Options\fR
  .IX Subsection "Blackfin Options"
! .IP "\fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR]" 4
  .IX Item "-mcpu=cpu[-sirevision]"
  Specifies the name of the target Blackfin processor.  Currently, \fIcpu\fR
  can be one of \fBbf512\fR, \fBbf514\fR, \fBbf516\fR, \fBbf518\fR,
--- 22713,22719 ----
  .PP
  \fIBlackfin Options\fR
  .IX Subsection "Blackfin Options"
! .IP \fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR] 4
  .IX Item "-mcpu=cpu[-sirevision]"
  Specifies the name of the target Blackfin processor.  Currently, \fIcpu\fR
  can be one of \fBbf512\fR, \fBbf514\fR, \fBbf516\fR, \fBbf518\fR,
*************** hexadecimal digits representing the majo
*** 22802,22920 ****
  revision.  If \fIsirevision\fR is \fBnone\fR, the \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR
  is not defined.  If \fIsirevision\fR is \fBany\fR, the
  \&\f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR is defined to be \f(CW0xffff\fR.
! If this optional \fIsirevision\fR is not used, \s-1GCC\s0 assumes the latest known
  silicon revision of the targeted Blackfin processor.
  .Sp
! \&\s-1GCC\s0 defines a preprocessor macro for the specified \fIcpu\fR.
! For the \fBbfin-elf\fR toolchain, this option causes the hardware \s-1BSP\s0
  provided by libgloss to be linked in if \fB\-msim\fR is not given.
  .Sp
  Without this option, \fBbf532\fR is used as the processor by default.
  .Sp
  Note that support for \fBbf561\fR is incomplete.  For \fBbf561\fR,
  only the preprocessor macro is defined.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
! the simulator \s-1BSP\s0 provided by libgloss to be linked in.  This option
! has effect only for \fBbfin-elf\fR toolchain.
  Certain other options, such as \fB\-mid\-shared\-library\fR and
  \&\fB\-mfdpic\fR, imply \fB\-msim\fR.
! .IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
  .IX Item "-momit-leaf-frame-pointer"
! Don't keep the frame pointer in a register for leaf functions.  This
  avoids the instructions to save, set up and restore frame pointers and
  makes an extra register available in leaf functions.
! .IP "\fB\-mspecld\-anomaly\fR" 4
  .IX Item "-mspecld-anomaly"
  When enabled, the compiler ensures that the generated code does not
  contain speculative loads after jump instructions. If this option is used,
  \&\f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_LOADS\*(C'\fR is defined.
! .IP "\fB\-mno\-specld\-anomaly\fR" 4
  .IX Item "-mno-specld-anomaly"
! Don't generate extra code to prevent speculative loads from occurring.
! .IP "\fB\-mcsync\-anomaly\fR" 4
  .IX Item "-mcsync-anomaly"
  When enabled, the compiler ensures that the generated code does not
! contain \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions too soon after conditional branches.
  If this option is used, \f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_SYNCS\*(C'\fR is defined.
! .IP "\fB\-mno\-csync\-anomaly\fR" 4
  .IX Item "-mno-csync-anomaly"
! Don't generate extra code to prevent \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions from
  occurring too soon after a conditional branch.
! .IP "\fB\-mlow64k\fR" 4
  .IX Item "-mlow64k"
  When enabled, the compiler is free to take advantage of the knowledge that
  the entire program fits into the low 64k of memory.
! .IP "\fB\-mno\-low64k\fR" 4
  .IX Item "-mno-low64k"
  Assume that the program is arbitrarily large.  This is the default.
! .IP "\fB\-mstack\-check\-l1\fR" 4
  .IX Item "-mstack-check-l1"
  Do stack checking using information placed into L1 scratchpad memory by the
  uClinux kernel.
! .IP "\fB\-mid\-shared\-library\fR" 4
  .IX Item "-mid-shared-library"
! Generate code that supports shared libraries via the library \s-1ID\s0 method.
  This allows for execute in place and shared libraries in an environment
  without virtual memory management.  This option implies \fB\-fPIC\fR.
! With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
! .IP "\fB\-mno\-id\-shared\-library\fR" 4
  .IX Item "-mno-id-shared-library"
! Generate code that doesn't assume ID-based shared libraries are being used.
  This is the default.
! .IP "\fB\-mleaf\-id\-shared\-library\fR" 4
  .IX Item "-mleaf-id-shared-library"
! Generate code that supports shared libraries via the library \s-1ID\s0 method,
! but assumes that this library or executable won't link against any other
! \&\s-1ID\s0 shared libraries.  That allows the compiler to use faster code for jumps
  and calls.
! .IP "\fB\-mno\-leaf\-id\-shared\-library\fR" 4
  .IX Item "-mno-leaf-id-shared-library"
! Do not assume that the code being compiled won't link against any \s-1ID\s0 shared
  libraries.  Slower code is generated for jump and call insns.
! .IP "\fB\-mshared\-library\-id=n\fR" 4
  .IX Item "-mshared-library-id=n"
! Specifies the identification number of the ID-based shared library being
  compiled.  Specifying a value of 0 generates more compact code; specifying
  other values forces the allocation of that number to the current
! library but is no more space\- or time-efficient than omitting this option.
! .IP "\fB\-msep\-data\fR" 4
  .IX Item "-msep-data"
  Generate code that allows the data segment to be located in a different
  area of memory from the text segment.  This allows for execute in place in
  an environment without virtual memory management by eliminating relocations
  against the text section.
! .IP "\fB\-mno\-sep\-data\fR" 4
  .IX Item "-mno-sep-data"
  Generate code that assumes that the data segment follows the text segment.
  This is the default.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP "\fB\-mno\-long\-calls\fR" 4
  .IX Item "-mno-long-calls"
  .PD
  Tells the compiler to perform function calls by first loading the
  address of the function into a register and then performing a subroutine
  call on this register.  This switch is needed if the target function
! lies outside of the 24\-bit addressing range of the offset-based
  version of subroutine call instruction.
  .Sp
  This feature is not enabled by default.  Specifying
  \&\fB\-mno\-long\-calls\fR restores the default behavior.  Note these
  switches have no effect on how the compiler generates code to handle
  function calls via function pointers.
! .IP "\fB\-mfast\-fp\fR" 4
  .IX Item "-mfast-fp"
! Link with the fast floating-point library. This library relaxes some of
! the \s-1IEEE\s0 floating-point standard's rules for checking inputs against
! Not-a-Number (\s-1NAN\s0), in the interest of performance.
! .IP "\fB\-minline\-plt\fR" 4
  .IX Item "-minline-plt"
! Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
  not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
! .IP "\fB\-mmulticore\fR" 4
  .IX Item "-mmulticore"
  Build a standalone application for multicore Blackfin processors. 
  This option causes proper start files and link scripts supporting 
--- 22733,22851 ----
  revision.  If \fIsirevision\fR is \fBnone\fR, the \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR
  is not defined.  If \fIsirevision\fR is \fBany\fR, the
  \&\f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR is defined to be \f(CW0xffff\fR.
! If this optional \fIsirevision\fR is not used, GCC assumes the latest known
  silicon revision of the targeted Blackfin processor.
  .Sp
! GCC defines a preprocessor macro for the specified \fIcpu\fR.
! For the \fBbfin\-elf\fR toolchain, this option causes the hardware BSP
  provided by libgloss to be linked in if \fB\-msim\fR is not given.
  .Sp
  Without this option, \fBbf532\fR is used as the processor by default.
  .Sp
  Note that support for \fBbf561\fR is incomplete.  For \fBbf561\fR,
  only the preprocessor macro is defined.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
! the simulator BSP provided by libgloss to be linked in.  This option
! has effect only for \fBbfin\-elf\fR toolchain.
  Certain other options, such as \fB\-mid\-shared\-library\fR and
  \&\fB\-mfdpic\fR, imply \fB\-msim\fR.
! .IP \fB\-momit\-leaf\-frame\-pointer\fR 4
  .IX Item "-momit-leaf-frame-pointer"
! Don\*(Aqt 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.
! .IP \fB\-mspecld\-anomaly\fR 4
  .IX Item "-mspecld-anomaly"
  When enabled, the compiler ensures that the generated code does not
  contain speculative loads after jump instructions. If this option is used,
  \&\f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_LOADS\*(C'\fR is defined.
! .IP \fB\-mno\-specld\-anomaly\fR 4
  .IX Item "-mno-specld-anomaly"
! Don\*(Aqt generate extra code to prevent speculative loads from occurring.
! .IP \fB\-mcsync\-anomaly\fR 4
  .IX Item "-mcsync-anomaly"
  When enabled, the compiler ensures that the generated code does not
! contain CSYNC or SSYNC instructions too soon after conditional branches.
  If this option is used, \f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_SYNCS\*(C'\fR is defined.
! .IP \fB\-mno\-csync\-anomaly\fR 4
  .IX Item "-mno-csync-anomaly"
! Don\*(Aqt generate extra code to prevent CSYNC or SSYNC instructions from
  occurring too soon after a conditional branch.
! .IP \fB\-mlow64k\fR 4
  .IX Item "-mlow64k"
  When enabled, the compiler is free to take advantage of the knowledge that
  the entire program fits into the low 64k of memory.
! .IP \fB\-mno\-low64k\fR 4
  .IX Item "-mno-low64k"
  Assume that the program is arbitrarily large.  This is the default.
! .IP \fB\-mstack\-check\-l1\fR 4
  .IX Item "-mstack-check-l1"
  Do stack checking using information placed into L1 scratchpad memory by the
  uClinux kernel.
! .IP \fB\-mid\-shared\-library\fR 4
  .IX Item "-mid-shared-library"
! Generate code that supports shared libraries via the library ID method.
  This allows for execute in place and shared libraries in an environment
  without virtual memory management.  This option implies \fB\-fPIC\fR.
! With a \fBbfin\-elf\fR target, this option implies \fB\-msim\fR.
! .IP \fB\-mno\-id\-shared\-library\fR 4
  .IX Item "-mno-id-shared-library"
! Generate code that doesn\*(Aqt assume ID\-based shared libraries are being used.
  This is the default.
! .IP \fB\-mleaf\-id\-shared\-library\fR 4
  .IX Item "-mleaf-id-shared-library"
! Generate code that supports shared libraries via the library ID method,
! but assumes that this library or executable won\*(Aqt link against any other
! ID shared libraries.  That allows the compiler to use faster code for jumps
  and calls.
! .IP \fB\-mno\-leaf\-id\-shared\-library\fR 4
  .IX Item "-mno-leaf-id-shared-library"
! Do not assume that the code being compiled won\*(Aqt link against any ID shared
  libraries.  Slower code is generated for jump and call insns.
! .IP \fB\-mshared\-library\-id=n\fR 4
  .IX Item "-mshared-library-id=n"
! Specifies the identification number of the ID\-based shared library being
  compiled.  Specifying a value of 0 generates more compact code; specifying
  other values forces the allocation of that number to the current
! library but is no more space\- or time\-efficient than omitting this option.
! .IP \fB\-msep\-data\fR 4
  .IX Item "-msep-data"
  Generate code that allows the data segment to be located in a different
  area of memory from the text segment.  This allows for execute in place in
  an environment without virtual memory management by eliminating relocations
  against the text section.
! .IP \fB\-mno\-sep\-data\fR 4
  .IX Item "-mno-sep-data"
  Generate code that assumes that the data segment follows the text segment.
  This is the default.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP \fB\-mno\-long\-calls\fR 4
  .IX Item "-mno-long-calls"
  .PD
  Tells the compiler to perform function calls by first loading the
  address of the function into a register and then performing a subroutine
  call on this register.  This switch is needed if the target function
! lies outside of the 24\-bit addressing range of the offset\-based
  version of subroutine call instruction.
  .Sp
  This feature is not enabled by default.  Specifying
  \&\fB\-mno\-long\-calls\fR restores the default behavior.  Note these
  switches have no effect on how the compiler generates code to handle
  function calls via function pointers.
! .IP \fB\-mfast\-fp\fR 4
  .IX Item "-mfast-fp"
! Link with the fast floating\-point library. This library relaxes some of
! the IEEE floating\-point standard\*(Aqs rules for checking inputs against
! Not\-a\-Number (NAN), in the interest of performance.
! .IP \fB\-minline\-plt\fR 4
  .IX Item "-minline-plt"
! Enable inlining of PLT entries in function calls to functions that are
  not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
! .IP \fB\-mmulticore\fR 4
  .IX Item "-mmulticore"
  Build a standalone application for multicore Blackfin processors. 
  This option causes proper start files and link scripts supporting 
*************** multicore to be used, and defines the ma
*** 22922,22956 ****
  It can only be used with \fB\-mcpu=bf561\fR[\fB\-\fR\fIsirevision\fR].
  .Sp
  This option can be used with \fB\-mcorea\fR or \fB\-mcoreb\fR, which
! selects the one-application-per-core programming model.  Without
  \&\fB\-mcorea\fR or \fB\-mcoreb\fR, the single\-application/dual\-core
  programming model is used. In this model, the main function of Core B
  should be named as \f(CW\*(C`coreb_main\*(C'\fR.
  .Sp
! If this option is not used, the single-core application programming
  model is used.
! .IP "\fB\-mcorea\fR" 4
  .IX Item "-mcorea"
! Build a standalone application for Core A of \s-1BF561\s0 when using
! the one-application-per-core programming model. Proper start files
  and link scripts are used to support Core A, and the macro
  \&\f(CW\*(C`_\|_BFIN_COREA\*(C'\fR is defined.
  This option can only be used in conjunction with \fB\-mmulticore\fR.
! .IP "\fB\-mcoreb\fR" 4
  .IX Item "-mcoreb"
! Build a standalone application for Core B of \s-1BF561\s0 when using
! the one-application-per-core programming model. Proper start files
  and link scripts are used to support Core B, and the macro
  \&\f(CW\*(C`_\|_BFIN_COREB\*(C'\fR is defined. When this option is used, \f(CW\*(C`coreb_main\*(C'\fR
  should be used instead of \f(CW\*(C`main\*(C'\fR. 
  This option can only be used in conjunction with \fB\-mmulticore\fR.
! .IP "\fB\-msdram\fR" 4
  .IX Item "-msdram"
! Build a standalone application for \s-1SDRAM.\s0 Proper start files and
! link scripts are used to put the application into \s-1SDRAM,\s0 and the macro
  \&\f(CW\*(C`_\|_BFIN_SDRAM\*(C'\fR is defined.
! The loader should initialize \s-1SDRAM\s0 before loading the application.
! .IP "\fB\-micplb\fR" 4
  .IX Item "-micplb"
  Assume that ICPLBs are enabled at run time.  This has an effect on certain
  anomaly workarounds.  For Linux targets, the default is to assume ICPLBs
--- 22853,22887 ----
  It can only be used with \fB\-mcpu=bf561\fR[\fB\-\fR\fIsirevision\fR].
  .Sp
  This option can be used with \fB\-mcorea\fR or \fB\-mcoreb\fR, which
! selects the one\-application\-per\-core programming model.  Without
  \&\fB\-mcorea\fR or \fB\-mcoreb\fR, the single\-application/dual\-core
  programming model is used. In this model, the main function of Core B
  should be named as \f(CW\*(C`coreb_main\*(C'\fR.
  .Sp
! If this option is not used, the single\-core application programming
  model is used.
! .IP \fB\-mcorea\fR 4
  .IX Item "-mcorea"
! Build a standalone application for Core A of BF561 when using
! the one\-application\-per\-core programming model. Proper start files
  and link scripts are used to support Core A, and the macro
  \&\f(CW\*(C`_\|_BFIN_COREA\*(C'\fR is defined.
  This option can only be used in conjunction with \fB\-mmulticore\fR.
! .IP \fB\-mcoreb\fR 4
  .IX Item "-mcoreb"
! Build a standalone application for Core B of BF561 when using
! the one\-application\-per\-core programming model. Proper start files
  and link scripts are used to support Core B, and the macro
  \&\f(CW\*(C`_\|_BFIN_COREB\*(C'\fR is defined. When this option is used, \f(CW\*(C`coreb_main\*(C'\fR
  should be used instead of \f(CW\*(C`main\*(C'\fR. 
  This option can only be used in conjunction with \fB\-mmulticore\fR.
! .IP \fB\-msdram\fR 4
  .IX Item "-msdram"
! Build a standalone application for SDRAM. Proper start files and
! link scripts are used to put the application into SDRAM, and the macro
  \&\f(CW\*(C`_\|_BFIN_SDRAM\*(C'\fR is defined.
! The loader should initialize SDRAM before loading the application.
! .IP \fB\-micplb\fR 4
  .IX Item "-micplb"
  Assume that ICPLBs are enabled at run time.  This has an effect on certain
  anomaly workarounds.  For Linux targets, the default is to assume ICPLBs
*************** are enabled; for standalone applications
*** 22958,22992 ****
  .PP
  \fIC6X Options\fR
  .IX Subsection "C6X Options"
! .IP "\fB\-march=\fR\fIname\fR" 4
  .IX Item "-march=name"
! This specifies the name of the target architecture.  \s-1GCC\s0 uses this
  name to determine what kind of instructions it can emit when generating
  assembly code.  Permissible names are: \fBc62x\fR,
  \&\fBc64x\fR, \fBc64x+\fR, \fBc67x\fR, \fBc67x+\fR, \fBc674x\fR.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code for a big-endian target.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code for a little-endian target.  This is the default.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Choose startup files and linker script suitable for the simulator.
! .IP "\fB\-msdata=default\fR" 4
  .IX Item "-msdata=default"
  Put small global and static data in the \f(CW\*(C`.neardata\*(C'\fR section,
  which is pointed to by register \f(CW\*(C`B14\*(C'\fR.  Put small uninitialized
  global and static data in the \f(CW\*(C`.bss\*(C'\fR section, which is adjacent
! to the \f(CW\*(C`.neardata\*(C'\fR section.  Put small read-only data into the
  \&\f(CW\*(C`.rodata\*(C'\fR section.  The corresponding sections used for large
  pieces of data are \f(CW\*(C`.fardata\*(C'\fR, \f(CW\*(C`.far\*(C'\fR and \f(CW\*(C`.const\*(C'\fR.
! .IP "\fB\-msdata=all\fR" 4
  .IX Item "-msdata=all"
  Put all data, not just small objects, into the sections reserved for
  small data, and use addressing relative to the \f(CW\*(C`B14\*(C'\fR register to
  access them.
! .IP "\fB\-msdata=none\fR" 4
  .IX Item "-msdata=none"
  Make no use of the sections reserved for small data, and use absolute
  addresses to access all data.  Put all initialized global and static
--- 22889,22923 ----
  .PP
  \fIC6X Options\fR
  .IX Subsection "C6X Options"
! .IP \fB\-march=\fR\fIname\fR 4
  .IX Item "-march=name"
! This specifies the name of the target architecture.  GCC uses this
  name to determine what kind of instructions it can emit when generating
  assembly code.  Permissible names are: \fBc62x\fR,
  \&\fBc64x\fR, \fBc64x+\fR, \fBc67x\fR, \fBc67x+\fR, \fBc674x\fR.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code for a big\-endian target.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code for a little\-endian target.  This is the default.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Choose startup files and linker script suitable for the simulator.
! .IP \fB\-msdata=default\fR 4
  .IX Item "-msdata=default"
  Put small global and static data in the \f(CW\*(C`.neardata\*(C'\fR section,
  which is pointed to by register \f(CW\*(C`B14\*(C'\fR.  Put small uninitialized
  global and static data in the \f(CW\*(C`.bss\*(C'\fR section, which is adjacent
! to the \f(CW\*(C`.neardata\*(C'\fR section.  Put small read\-only data into the
  \&\f(CW\*(C`.rodata\*(C'\fR section.  The corresponding sections used for large
  pieces of data are \f(CW\*(C`.fardata\*(C'\fR, \f(CW\*(C`.far\*(C'\fR and \f(CW\*(C`.const\*(C'\fR.
! .IP \fB\-msdata=all\fR 4
  .IX Item "-msdata=all"
  Put all data, not just small objects, into the sections reserved for
  small data, and use addressing relative to the \f(CW\*(C`B14\*(C'\fR register to
  access them.
! .IP \fB\-msdata=none\fR 4
  .IX Item "-msdata=none"
  Make no use of the sections reserved for small data, and use absolute
  addresses to access all data.  Put all initialized global and static
*************** data in the \f(CW\*(C`.fardata\*(C'\fR s
*** 22994,23117 ****
  \&\f(CW\*(C`.far\*(C'\fR section.  Put all constant data into the \f(CW\*(C`.const\*(C'\fR
  section.
  .PP
! \fI\s-1CRIS\s0 Options\fR
  .IX Subsection "CRIS Options"
  .PP
! These options are defined specifically for the \s-1CRIS\s0 ports.
! .IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
  .IX Item "-march=architecture-type"
  .PD 0
! .IP "\fB\-mcpu=\fR\fIarchitecture-type\fR" 4
  .IX Item "-mcpu=architecture-type"
  .PD
  Generate code for the specified architecture.  The choices for
! \&\fIarchitecture-type\fR are \fBv3\fR, \fBv8\fR and \fBv10\fR for
! respectively \s-1ETRAX\s0\ 4, \s-1ETRAX\s0\ 100, and \s-1ETRAX\s0\ 100\ \s-1LX.\s0
  Default is \fBv0\fR.
! .IP "\fB\-mtune=\fR\fIarchitecture-type\fR" 4
  .IX Item "-mtune=architecture-type"
! Tune to \fIarchitecture-type\fR everything applicable about the generated
! code, except for the \s-1ABI\s0 and the set of available instructions.  The
! choices for \fIarchitecture-type\fR are the same as for
! \&\fB\-march=\fR\fIarchitecture-type\fR.
! .IP "\fB\-mmax\-stack\-frame=\fR\fIn\fR" 4
  .IX Item "-mmax-stack-frame=n"
  Warn when the stack frame of a function exceeds \fIn\fR bytes.
! .IP "\fB\-metrax4\fR" 4
  .IX Item "-metrax4"
  .PD 0
! .IP "\fB\-metrax100\fR" 4
  .IX Item "-metrax100"
  .PD
  The options \fB\-metrax4\fR and \fB\-metrax100\fR are synonyms for
  \&\fB\-march=v3\fR and \fB\-march=v8\fR respectively.
! .IP "\fB\-mmul\-bug\-workaround\fR" 4
  .IX Item "-mmul-bug-workaround"
  .PD 0
! .IP "\fB\-mno\-mul\-bug\-workaround\fR" 4
  .IX Item "-mno-mul-bug-workaround"
  .PD
! Work around a bug in the \f(CW\*(C`muls\*(C'\fR and \f(CW\*(C`mulu\*(C'\fR instructions for \s-1CPU\s0
  models where it applies.  This option is disabled by default.
! .IP "\fB\-mpdebug\fR" 4
  .IX Item "-mpdebug"
! Enable CRIS-specific verbose debug-related information in the assembly
  code.  This option also has the effect of turning off the \fB#NO_APP\fR
! formatted-code indicator to the assembler at the beginning of the
  assembly file.
! .IP "\fB\-mcc\-init\fR" 4
  .IX Item "-mcc-init"
! Do not use condition-code results from previous instruction; always emit
  compare and test instructions before use of condition codes.
! .IP "\fB\-mno\-side\-effects\fR" 4
  .IX Item "-mno-side-effects"
  Do not emit instructions with side effects in addressing modes other than
! post-increment.
! .IP "\fB\-mstack\-align\fR" 4
  .IX Item "-mstack-align"
  .PD 0
! .IP "\fB\-mno\-stack\-align\fR" 4
  .IX Item "-mno-stack-align"
! .IP "\fB\-mdata\-align\fR" 4
  .IX Item "-mdata-align"
! .IP "\fB\-mno\-data\-align\fR" 4
  .IX Item "-mno-data-align"
! .IP "\fB\-mconst\-align\fR" 4
  .IX Item "-mconst-align"
! .IP "\fB\-mno\-const\-align\fR" 4
  .IX Item "-mno-const-align"
  .PD
  These options (\fBno\-\fR options) arrange (eliminate arrangements) for the
  stack frame, individual data and constants to be aligned for the maximum
! single data access size for the chosen \s-1CPU\s0 model.  The default is to
! arrange for 32\-bit alignment.  \s-1ABI\s0 details such as structure layout are
  not affected by these options.
! .IP "\fB\-m32\-bit\fR" 4
  .IX Item "-m32-bit"
  .PD 0
! .IP "\fB\-m16\-bit\fR" 4
  .IX Item "-m16-bit"
! .IP "\fB\-m8\-bit\fR" 4
  .IX Item "-m8-bit"
  .PD
! Similar to the stack\- data\- and const-align options above, these options
  arrange for stack frame, writable data and constants to all be 32\-bit,
  16\-bit or 8\-bit aligned.  The default is 32\-bit alignment.
! .IP "\fB\-mno\-prologue\-epilogue\fR" 4
  .IX Item "-mno-prologue-epilogue"
  .PD 0
! .IP "\fB\-mprologue\-epilogue\fR" 4
  .IX Item "-mprologue-epilogue"
  .PD
  With \fB\-mno\-prologue\-epilogue\fR, the normal function prologue and
  epilogue which set up the stack frame are omitted and no return
  instructions or return sequences are generated in the code.  Use this
  option only together with visual inspection of the compiled code: no
! warnings or errors are generated when call-saved registers must be saved,
  or storage for local variables needs to be allocated.
! .IP "\fB\-melf\fR" 4
  .IX Item "-melf"
! Legacy no-op option.
! .IP "\fB\-sim\fR" 4
  .IX Item "-sim"
  This option arranges
! to link with input-output functions from a simulator library.  Code,
! initialized data and zero-initialized data are allocated consecutively.
! .IP "\fB\-sim2\fR" 4
  .IX Item "-sim2"
  Like \fB\-sim\fR, but pass linker options to locate initialized data at
! 0x40000000 and zero-initialized data at 0x80000000.
  .PP
  \fIC\-SKY Options\fR
  .IX Subsection "C-SKY Options"
  .PP
! \&\s-1GCC\s0 supports these options when compiling for C\-SKY V2 processors.
! .IP "\fB\-march=\fR\fIarch\fR" 4
  .IX Item "-march=arch"
  Specify the C\-SKY target architecture.  Valid values for \fIarch\fR are:
  \&\fBck801\fR, \fBck802\fR, \fBck803\fR, \fBck807\fR, and \fBck810\fR.
  The default is \fBck810\fR.
! .IP "\fB\-mcpu=\fR\fIcpu\fR" 4
  .IX Item "-mcpu=cpu"
  Specify the C\-SKY target processor.  Valid values for \fIcpu\fR are:
  \&\fBck801\fR, \fBck801t\fR,
--- 22925,23048 ----
  \&\f(CW\*(C`.far\*(C'\fR section.  Put all constant data into the \f(CW\*(C`.const\*(C'\fR
  section.
  .PP
! \fICRIS Options\fR
  .IX Subsection "CRIS Options"
  .PP
! These options are defined specifically for the CRIS ports.
! .IP \fB\-march=\fR\fIarchitecture\-type\fR 4
  .IX Item "-march=architecture-type"
  .PD 0
! .IP \fB\-mcpu=\fR\fIarchitecture\-type\fR 4
  .IX Item "-mcpu=architecture-type"
  .PD
  Generate code for the specified architecture.  The choices for
! \&\fIarchitecture\-type\fR are \fBv3\fR, \fBv8\fR and \fBv10\fR for
! respectively ETRAX\ 4, ETRAX\ 100, and ETRAX\ 100\ LX.
  Default is \fBv0\fR.
! .IP \fB\-mtune=\fR\fIarchitecture\-type\fR 4
  .IX Item "-mtune=architecture-type"
! Tune to \fIarchitecture\-type\fR everything applicable about the generated
! code, except for the ABI and the set of available instructions.  The
! choices for \fIarchitecture\-type\fR are the same as for
! \&\fB\-march=\fR\fIarchitecture\-type\fR.
! .IP \fB\-mmax\-stack\-frame=\fR\fIn\fR 4
  .IX Item "-mmax-stack-frame=n"
  Warn when the stack frame of a function exceeds \fIn\fR bytes.
! .IP \fB\-metrax4\fR 4
  .IX Item "-metrax4"
  .PD 0
! .IP \fB\-metrax100\fR 4
  .IX Item "-metrax100"
  .PD
  The options \fB\-metrax4\fR and \fB\-metrax100\fR are synonyms for
  \&\fB\-march=v3\fR and \fB\-march=v8\fR respectively.
! .IP \fB\-mmul\-bug\-workaround\fR 4
  .IX Item "-mmul-bug-workaround"
  .PD 0
! .IP \fB\-mno\-mul\-bug\-workaround\fR 4
  .IX Item "-mno-mul-bug-workaround"
  .PD
! Work around a bug in the \f(CW\*(C`muls\*(C'\fR and \f(CW\*(C`mulu\*(C'\fR instructions for CPU
  models where it applies.  This option is disabled by default.
! .IP \fB\-mpdebug\fR 4
  .IX Item "-mpdebug"
! Enable CRIS\-specific verbose debug\-related information in the assembly
  code.  This option also has the effect of turning off the \fB#NO_APP\fR
! formatted\-code indicator to the assembler at the beginning of the
  assembly file.
! .IP \fB\-mcc\-init\fR 4
  .IX Item "-mcc-init"
! Do not use condition\-code results from previous instruction; always emit
  compare and test instructions before use of condition codes.
! .IP \fB\-mno\-side\-effects\fR 4
  .IX Item "-mno-side-effects"
  Do not emit instructions with side effects in addressing modes other than
! post\-increment.
! .IP \fB\-mstack\-align\fR 4
  .IX Item "-mstack-align"
  .PD 0
! .IP \fB\-mno\-stack\-align\fR 4
  .IX Item "-mno-stack-align"
! .IP \fB\-mdata\-align\fR 4
  .IX Item "-mdata-align"
! .IP \fB\-mno\-data\-align\fR 4
  .IX Item "-mno-data-align"
! .IP \fB\-mconst\-align\fR 4
  .IX Item "-mconst-align"
! .IP \fB\-mno\-const\-align\fR 4
  .IX Item "-mno-const-align"
  .PD
  These options (\fBno\-\fR options) arrange (eliminate arrangements) for the
  stack frame, individual data and constants to be aligned for the maximum
! single data access size for the chosen CPU model.  The default is to
! arrange for 32\-bit alignment.  ABI details such as structure layout are
  not affected by these options.
! .IP \fB\-m32\-bit\fR 4
  .IX Item "-m32-bit"
  .PD 0
! .IP \fB\-m16\-bit\fR 4
  .IX Item "-m16-bit"
! .IP \fB\-m8\-bit\fR 4
  .IX Item "-m8-bit"
  .PD
! Similar to the stack\- data\- and const\-align options above, these options
  arrange for stack frame, writable data and constants to all be 32\-bit,
  16\-bit or 8\-bit aligned.  The default is 32\-bit alignment.
! .IP \fB\-mno\-prologue\-epilogue\fR 4
  .IX Item "-mno-prologue-epilogue"
  .PD 0
! .IP \fB\-mprologue\-epilogue\fR 4
  .IX Item "-mprologue-epilogue"
  .PD
  With \fB\-mno\-prologue\-epilogue\fR, the normal function prologue and
  epilogue which set up the stack frame are omitted and no return
  instructions or return sequences are generated in the code.  Use this
  option only together with visual inspection of the compiled code: no
! warnings or errors are generated when call\-saved registers must be saved,
  or storage for local variables needs to be allocated.
! .IP \fB\-melf\fR 4
  .IX Item "-melf"
! Legacy no\-op option.
! .IP \fB\-sim\fR 4
  .IX Item "-sim"
  This option arranges
! to link with input\-output functions from a simulator library.  Code,
! initialized data and zero\-initialized data are allocated consecutively.
! .IP \fB\-sim2\fR 4
  .IX Item "-sim2"
  Like \fB\-sim\fR, but pass linker options to locate initialized data at
! 0x40000000 and zero\-initialized data at 0x80000000.
  .PP
  \fIC\-SKY Options\fR
  .IX Subsection "C-SKY Options"
  .PP
! GCC supports these options when compiling for C\-SKY V2 processors.
! .IP \fB\-march=\fR\fIarch\fR 4
  .IX Item "-march=arch"
  Specify the C\-SKY target architecture.  Valid values for \fIarch\fR are:
  \&\fBck801\fR, \fBck802\fR, \fBck803\fR, \fBck807\fR, and \fBck810\fR.
  The default is \fBck810\fR.
! .IP \fB\-mcpu=\fR\fIcpu\fR 4
  .IX Item "-mcpu=cpu"
  Specify the C\-SKY target processor.  Valid values for \fIcpu\fR are:
  \&\fBck801\fR, \fBck801t\fR,
*************** Specify the C\-SKY target processor.  Va
*** 23130,23334 ****
  \&\fBck810e\fR, \fBck810et\fR, \fBck810ef\fR, \fBck810eft\fR,
  \&\fBck810\fR, \fBck810v\fR, \fBck810f\fR, \fBck810t\fR, \fBck810fv\fR,
  \&\fBck810tv\fR, \fBck810ft\fR, and \fBck810ftv\fR.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
  .PD 0
! .IP "\fB\-EB\fR" 4
  .IX Item "-EB"
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! .IP "\fB\-EL\fR" 4
  .IX Item "-EL"
  .PD
! Select big\- or little-endian code.  The default is little-endian.
! .IP "\fB\-mfloat\-abi=\fR\fIname\fR" 4
  .IX Item "-mfloat-abi=name"
! Specifies which floating-point \s-1ABI\s0 to use.  Permissible values
  are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
  .Sp
! Specifying \fBsoft\fR causes \s-1GCC\s0 to generate output containing
! library calls for floating-point operations.
! \&\fBsoftfp\fR allows the generation of code using hardware floating-point
! instructions, but still uses the soft-float calling conventions.
! \&\fBhard\fR allows generation of floating-point instructions
! and uses FPU-specific calling conventions.
  .Sp
  The default depends on the specific target configuration.  Note that
! the hard-float and soft-float ABIs are not link-compatible; you must
! compile your entire program with the same \s-1ABI,\s0 and link with a
  compatible set of libraries.
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
! Select hardware or software floating-point implementations.
  The default is soft float.
! .IP "\fB\-mdouble\-float\fR" 4
  .IX Item "-mdouble-float"
  .PD 0
! .IP "\fB\-mno\-double\-float\fR" 4
  .IX Item "-mno-double-float"
  .PD
  When \fB\-mhard\-float\fR is in effect, enable generation of
! double-precision float instructions.  This is the default except
! when compiling for \s-1CK803.\s0
! .IP "\fB\-mfdivdu\fR" 4
  .IX Item "-mfdivdu"
  .PD 0
! .IP "\fB\-mno\-fdivdu\fR" 4
  .IX Item "-mno-fdivdu"
  .PD
  When \fB\-mhard\-float\fR is in effect, enable generation of
  \&\f(CW\*(C`frecipd\*(C'\fR, \f(CW\*(C`fsqrtd\*(C'\fR, and \f(CW\*(C`fdivd\*(C'\fR instructions.
! This is the default except when compiling for \s-1CK803.\s0
! .IP "\fB\-mfpu=\fR\fIfpu\fR" 4
  .IX Item "-mfpu=fpu"
! Select the floating-point processor.  This option can only be used with
  \&\fB\-mhard\-float\fR.
  Values for \fIfpu\fR are
  \&\fBfpv2_sf\fR (equivalent to \fB\-mno\-double\-float \-mno\-fdivdu\fR),
  \&\fBfpv2\fR (\fB\-mdouble\-float \-mno\-divdu\fR), and
  \&\fBfpv2_divd\fR (\fB\-mdouble\-float \-mdivdu\fR).
! .IP "\fB\-melrw\fR" 4
  .IX Item "-melrw"
  .PD 0
! .IP "\fB\-mno\-elrw\fR" 4
  .IX Item "-mno-elrw"
  .PD
  Enable the extended \f(CW\*(C`lrw\*(C'\fR instruction.  This option defaults to on
! for \s-1CK801\s0 and off otherwise.
! .IP "\fB\-mistack\fR" 4
  .IX Item "-mistack"
  .PD 0
! .IP "\fB\-mno\-istack\fR" 4
  .IX Item "-mno-istack"
  .PD
  Enable interrupt stack instructions; the default is off.
  .Sp
  The \fB\-mistack\fR option is required to handle the
  \&\f(CW\*(C`interrupt\*(C'\fR and \f(CW\*(C`isr\*(C'\fR function attributes.
! .IP "\fB\-mmp\fR" 4
  .IX Item "-mmp"
  Enable multiprocessor instructions; the default is off.
! .IP "\fB\-mcp\fR" 4
  .IX Item "-mcp"
  Enable coprocessor instructions; the default is off.
! .IP "\fB\-mcache\fR" 4
  .IX Item "-mcache"
  Enable coprocessor instructions; the default is off.
! .IP "\fB\-msecurity\fR" 4
  .IX Item "-msecurity"
  Enable C\-SKY security instructions; the default is off.
! .IP "\fB\-mtrust\fR" 4
  .IX Item "-mtrust"
  Enable C\-SKY trust instructions; the default is off.
! .IP "\fB\-mdsp\fR" 4
  .IX Item "-mdsp"
  .PD 0
! .IP "\fB\-medsp\fR" 4
  .IX Item "-medsp"
! .IP "\fB\-mvdsp\fR" 4
  .IX Item "-mvdsp"
  .PD
! Enable C\-SKY \s-1DSP,\s0 Enhanced \s-1DSP,\s0 or Vector \s-1DSP\s0 instructions, respectively.
  All of these options default to off.
! .IP "\fB\-mdiv\fR" 4
  .IX Item "-mdiv"
  .PD 0
! .IP "\fB\-mno\-div\fR" 4
  .IX Item "-mno-div"
  .PD
  Generate divide instructions.  Default is off.
! .IP "\fB\-msmart\fR" 4
  .IX Item "-msmart"
  .PD 0
! .IP "\fB\-mno\-smart\fR" 4
  .IX Item "-mno-smart"
  .PD
  Generate code for Smart Mode, using only registers numbered 0\-7 to allow
! use of 16\-bit instructions.  This option is ignored for \s-1CK801\s0 where this
! is the required behavior, and it defaults to on for \s-1CK802.\s0
  For other targets, the default is off.
! .IP "\fB\-mhigh\-registers\fR" 4
  .IX Item "-mhigh-registers"
  .PD 0
! .IP "\fB\-mno\-high\-registers\fR" 4
  .IX Item "-mno-high-registers"
  .PD
  Generate code using the high registers numbered 16\-31.  This option
! is not supported on \s-1CK801, CK802,\s0 or \s-1CK803,\s0 and is enabled by default
  for other processors.
! .IP "\fB\-manchor\fR" 4
  .IX Item "-manchor"
  .PD 0
! .IP "\fB\-mno\-anchor\fR" 4
  .IX Item "-mno-anchor"
  .PD
  Generate code using global anchor symbol addresses.
! .IP "\fB\-mpushpop\fR" 4
  .IX Item "-mpushpop"
  .PD 0
! .IP "\fB\-mno\-pushpop\fR" 4
  .IX Item "-mno-pushpop"
  .PD
  Generate code using \f(CW\*(C`push\*(C'\fR and \f(CW\*(C`pop\*(C'\fR instructions.  This option
  defaults to on.
! .IP "\fB\-mmultiple\-stld\fR" 4
  .IX Item "-mmultiple-stld"
  .PD 0
! .IP "\fB\-mstm\fR" 4
  .IX Item "-mstm"
! .IP "\fB\-mno\-multiple\-stld\fR" 4
  .IX Item "-mno-multiple-stld"
! .IP "\fB\-mno\-stm\fR" 4
  .IX Item "-mno-stm"
  .PD
  Generate code using \f(CW\*(C`stm\*(C'\fR and \f(CW\*(C`ldm\*(C'\fR instructions.  This option
! isn't supported on \s-1CK801\s0 but is enabled by default on other processors.
! .IP "\fB\-mconstpool\fR" 4
  .IX Item "-mconstpool"
  .PD 0
! .IP "\fB\-mno\-constpool\fR" 4
  .IX Item "-mno-constpool"
  .PD
  Create constant pools in the compiler instead of deferring it to the
  assembler.  This option is the default and required for correct code
! generation on \s-1CK801\s0 and \s-1CK802,\s0 and is optional on other processors.
! .IP "\fB\-mstack\-size\fR" 4
  .IX Item "-mstack-size"
  .PD 0
! .IP "\fB\-mno\-stack\-size\fR" 4
  .IX Item "-mno-stack-size"
  .PD
  Emit \f(CW\*(C`.stack_size\*(C'\fR directives for each function in the assembly
  output.  This option defaults to off.
! .IP "\fB\-mccrt\fR" 4
  .IX Item "-mccrt"
  .PD 0
! .IP "\fB\-mno\-ccrt\fR" 4
  .IX Item "-mno-ccrt"
  .PD
  Generate code for the C\-SKY compiler runtime instead of libgcc.  This
  option defaults to off.
! .IP "\fB\-mbranch\-cost=\fR\fIn\fR" 4
  .IX Item "-mbranch-cost=n"
  Set the branch costs to roughly \f(CW\*(C`n\*(C'\fR instructions.  The default is 1.
! .IP "\fB\-msched\-prolog\fR" 4
  .IX Item "-msched-prolog"
  .PD 0
! .IP "\fB\-mno\-sched\-prolog\fR" 4
  .IX Item "-mno-sched-prolog"
  .PD
  Permit scheduling of function prologue and epilogue sequences.  Using
! this option can result in code that is not compliant with the C\-SKY V2 \s-1ABI\s0
  prologue requirements and that cannot be debugged or backtraced.
  It is disabled by default.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Links the library libsemi.a which is in compatible with simulator. Applicable
! to \s-1ELF\s0 compiler only.
  .PP
  \fIDarwin Options\fR
  .IX Subsection "Darwin Options"
--- 23061,23265 ----
  \&\fBck810e\fR, \fBck810et\fR, \fBck810ef\fR, \fBck810eft\fR,
  \&\fBck810\fR, \fBck810v\fR, \fBck810f\fR, \fBck810t\fR, \fBck810fv\fR,
  \&\fBck810tv\fR, \fBck810ft\fR, and \fBck810ftv\fR.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
  .PD 0
! .IP \fB\-EB\fR 4
  .IX Item "-EB"
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! .IP \fB\-EL\fR 4
  .IX Item "-EL"
  .PD
! Select big\- or little\-endian code.  The default is little\-endian.
! .IP \fB\-mfloat\-abi=\fR\fIname\fR 4
  .IX Item "-mfloat-abi=name"
! Specifies which floating\-point ABI to use.  Permissible values
  are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
  .Sp
! Specifying \fBsoft\fR causes GCC to generate output containing
! library calls for floating\-point operations.
! \&\fBsoftfp\fR allows the generation of code using hardware floating\-point
! instructions, but still uses the soft\-float calling conventions.
! \&\fBhard\fR allows generation of floating\-point instructions
! and uses FPU\-specific calling conventions.
  .Sp
  The default depends on the specific target configuration.  Note that
! the hard\-float and soft\-float ABIs are not link\-compatible; you must
! compile your entire program with the same ABI, and link with a
  compatible set of libraries.
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
! Select hardware or software floating\-point implementations.
  The default is soft float.
! .IP \fB\-mdouble\-float\fR 4
  .IX Item "-mdouble-float"
  .PD 0
! .IP \fB\-mno\-double\-float\fR 4
  .IX Item "-mno-double-float"
  .PD
  When \fB\-mhard\-float\fR is in effect, enable generation of
! double\-precision float instructions.  This is the default except
! when compiling for CK803.
! .IP \fB\-mfdivdu\fR 4
  .IX Item "-mfdivdu"
  .PD 0
! .IP \fB\-mno\-fdivdu\fR 4
  .IX Item "-mno-fdivdu"
  .PD
  When \fB\-mhard\-float\fR is in effect, enable generation of
  \&\f(CW\*(C`frecipd\*(C'\fR, \f(CW\*(C`fsqrtd\*(C'\fR, and \f(CW\*(C`fdivd\*(C'\fR instructions.
! This is the default except when compiling for CK803.
! .IP \fB\-mfpu=\fR\fIfpu\fR 4
  .IX Item "-mfpu=fpu"
! Select the floating\-point processor.  This option can only be used with
  \&\fB\-mhard\-float\fR.
  Values for \fIfpu\fR are
  \&\fBfpv2_sf\fR (equivalent to \fB\-mno\-double\-float \-mno\-fdivdu\fR),
  \&\fBfpv2\fR (\fB\-mdouble\-float \-mno\-divdu\fR), and
  \&\fBfpv2_divd\fR (\fB\-mdouble\-float \-mdivdu\fR).
! .IP \fB\-melrw\fR 4
  .IX Item "-melrw"
  .PD 0
! .IP \fB\-mno\-elrw\fR 4
  .IX Item "-mno-elrw"
  .PD
  Enable the extended \f(CW\*(C`lrw\*(C'\fR instruction.  This option defaults to on
! for CK801 and off otherwise.
! .IP \fB\-mistack\fR 4
  .IX Item "-mistack"
  .PD 0
! .IP \fB\-mno\-istack\fR 4
  .IX Item "-mno-istack"
  .PD
  Enable interrupt stack instructions; the default is off.
  .Sp
  The \fB\-mistack\fR option is required to handle the
  \&\f(CW\*(C`interrupt\*(C'\fR and \f(CW\*(C`isr\*(C'\fR function attributes.
! .IP \fB\-mmp\fR 4
  .IX Item "-mmp"
  Enable multiprocessor instructions; the default is off.
! .IP \fB\-mcp\fR 4
  .IX Item "-mcp"
  Enable coprocessor instructions; the default is off.
! .IP \fB\-mcache\fR 4
  .IX Item "-mcache"
  Enable coprocessor instructions; the default is off.
! .IP \fB\-msecurity\fR 4
  .IX Item "-msecurity"
  Enable C\-SKY security instructions; the default is off.
! .IP \fB\-mtrust\fR 4
  .IX Item "-mtrust"
  Enable C\-SKY trust instructions; the default is off.
! .IP \fB\-mdsp\fR 4
  .IX Item "-mdsp"
  .PD 0
! .IP \fB\-medsp\fR 4
  .IX Item "-medsp"
! .IP \fB\-mvdsp\fR 4
  .IX Item "-mvdsp"
  .PD
! Enable C\-SKY DSP, Enhanced DSP, or Vector DSP instructions, respectively.
  All of these options default to off.
! .IP \fB\-mdiv\fR 4
  .IX Item "-mdiv"
  .PD 0
! .IP \fB\-mno\-div\fR 4
  .IX Item "-mno-div"
  .PD
  Generate divide instructions.  Default is off.
! .IP \fB\-msmart\fR 4
  .IX Item "-msmart"
  .PD 0
! .IP \fB\-mno\-smart\fR 4
  .IX Item "-mno-smart"
  .PD
  Generate code for Smart Mode, using only registers numbered 0\-7 to allow
! use of 16\-bit instructions.  This option is ignored for CK801 where this
! is the required behavior, and it defaults to on for CK802.
  For other targets, the default is off.
! .IP \fB\-mhigh\-registers\fR 4
  .IX Item "-mhigh-registers"
  .PD 0
! .IP \fB\-mno\-high\-registers\fR 4
  .IX Item "-mno-high-registers"
  .PD
  Generate code using the high registers numbered 16\-31.  This option
! is not supported on CK801, CK802, or CK803, and is enabled by default
  for other processors.
! .IP \fB\-manchor\fR 4
  .IX Item "-manchor"
  .PD 0
! .IP \fB\-mno\-anchor\fR 4
  .IX Item "-mno-anchor"
  .PD
  Generate code using global anchor symbol addresses.
! .IP \fB\-mpushpop\fR 4
  .IX Item "-mpushpop"
  .PD 0
! .IP \fB\-mno\-pushpop\fR 4
  .IX Item "-mno-pushpop"
  .PD
  Generate code using \f(CW\*(C`push\*(C'\fR and \f(CW\*(C`pop\*(C'\fR instructions.  This option
  defaults to on.
! .IP \fB\-mmultiple\-stld\fR 4
  .IX Item "-mmultiple-stld"
  .PD 0
! .IP \fB\-mstm\fR 4
  .IX Item "-mstm"
! .IP \fB\-mno\-multiple\-stld\fR 4
  .IX Item "-mno-multiple-stld"
! .IP \fB\-mno\-stm\fR 4
  .IX Item "-mno-stm"
  .PD
  Generate code using \f(CW\*(C`stm\*(C'\fR and \f(CW\*(C`ldm\*(C'\fR instructions.  This option
! isn\*(Aqt supported on CK801 but is enabled by default on other processors.
! .IP \fB\-mconstpool\fR 4
  .IX Item "-mconstpool"
  .PD 0
! .IP \fB\-mno\-constpool\fR 4
  .IX Item "-mno-constpool"
  .PD
  Create constant pools in the compiler instead of deferring it to the
  assembler.  This option is the default and required for correct code
! generation on CK801 and CK802, and is optional on other processors.
! .IP \fB\-mstack\-size\fR 4
  .IX Item "-mstack-size"
  .PD 0
! .IP \fB\-mno\-stack\-size\fR 4
  .IX Item "-mno-stack-size"
  .PD
  Emit \f(CW\*(C`.stack_size\*(C'\fR directives for each function in the assembly
  output.  This option defaults to off.
! .IP \fB\-mccrt\fR 4
  .IX Item "-mccrt"
  .PD 0
! .IP \fB\-mno\-ccrt\fR 4
  .IX Item "-mno-ccrt"
  .PD
  Generate code for the C\-SKY compiler runtime instead of libgcc.  This
  option defaults to off.
! .IP \fB\-mbranch\-cost=\fR\fIn\fR 4
  .IX Item "-mbranch-cost=n"
  Set the branch costs to roughly \f(CW\*(C`n\*(C'\fR instructions.  The default is 1.
! .IP \fB\-msched\-prolog\fR 4
  .IX Item "-msched-prolog"
  .PD 0
! .IP \fB\-mno\-sched\-prolog\fR 4
  .IX Item "-mno-sched-prolog"
  .PD
  Permit scheduling of function prologue and epilogue sequences.  Using
! this option can result in code that is not compliant with the C\-SKY V2 ABI
  prologue requirements and that cannot be debugged or backtraced.
  It is disabled by default.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Links the library libsemi.a which is in compatible with simulator. Applicable
! to ELF compiler only.
  .PP
  \fIDarwin Options\fR
  .IX Subsection "Darwin Options"
*************** to \s-1ELF\s0 compiler only.
*** 23336,23354 ****
  These options are defined for all architectures running the Darwin operating
  system.
  .PP
! \&\s-1FSF GCC\s0 on Darwin does not create \*(L"fat\*(R" object files; it creates
! an object file for the single architecture that \s-1GCC\s0 was built to
! target.  Apple's \s-1GCC\s0 on Darwin does create \*(L"fat\*(R" files if multiple
  \&\fB\-arch\fR options are used; it does so by running the compiler or
  linker multiple times and joining the results together with
  \&\fIlipo\fR.
  .PP
  The subtype of the file created (like \fBppc7400\fR or \fBppc970\fR or
! \&\fBi686\fR) is determined by the flags that specify the \s-1ISA\s0
! that \s-1GCC\s0 is targeting, like \fB\-mcpu\fR or \fB\-march\fR.  The
  \&\fB\-force_cpusubtype_ALL\fR option can be used to override this.
  .PP
! The Darwin tools vary in their behavior when presented with an \s-1ISA\s0
  mismatch.  The assembler, \fIas\fR, only permits instructions to
  be used that are valid for the subtype of the file it is generating,
  so you cannot put 64\-bit instructions in a \fBppc750\fR object file.
--- 23267,23285 ----
  These options are defined for all architectures running the Darwin operating
  system.
  .PP
! FSF GCC on Darwin does not create "fat" object files; it creates
! an object file for the single architecture that GCC was built to
! target.  Apple\*(Aqs GCC on Darwin does create "fat" files if multiple
  \&\fB\-arch\fR options are used; it does so by running the compiler or
  linker multiple times and joining the results together with
  \&\fIlipo\fR.
  .PP
  The subtype of the file created (like \fBppc7400\fR or \fBppc970\fR or
! \&\fBi686\fR) is determined by the flags that specify the ISA
! that GCC is targeting, like \fB\-mcpu\fR or \fB\-march\fR.  The
  \&\fB\-force_cpusubtype_ALL\fR option can be used to override this.
  .PP
! The Darwin tools vary in their behavior when presented with an ISA
  mismatch.  The assembler, \fIas\fR, only permits instructions to
  be used that are valid for the subtype of the file it is generating,
  so you cannot put 64\-bit instructions in a \fBppc750\fR object file.
*************** restrictive subtype than its input files
*** 23358,23369 ****
  a \fBppc970\fR object file in a \fBppc7400\fR library).  The linker
  for executables, \fBld\fR, quietly gives the executable the most
  restrictive subtype of any of its input files.
! .IP "\fB\-F\fR\fIdir\fR" 4
  .IX Item "-Fdir"
  Add the framework directory \fIdir\fR to the head of the list of
  directories to be searched for header files.  These directories are
  interleaved with those specified by \fB\-I\fR options and are
! scanned in a left-to-right order.
  .Sp
  A framework directory is a directory with frameworks in it.  A
  framework is a directory with a \fIHeaders\fR and/or
--- 23289,23300 ----
  a \fBppc970\fR object file in a \fBppc7400\fR library).  The linker
  for executables, \fBld\fR, quietly gives the executable the most
  restrictive subtype of any of its input files.
! .IP \fB\-F\fR\fIdir\fR 4
  .IX Item "-Fdir"
  Add the framework directory \fIdir\fR to the head of the list of
  directories to be searched for header files.  These directories are
  interleaved with those specified by \fB\-I\fR options and are
! scanned in a left\-to\-right order.
  .Sp
  A framework directory is a directory with frameworks in it.  A
  framework is a directory with a \fIHeaders\fR and/or
*************** in \fI.framework\fR.  The name of a fram
*** 23372,23378 ****
  directory excluding the \fI.framework\fR.  Headers associated with
  the framework are found in one of those two directories, with
  \&\fIHeaders\fR being searched first.  A subframework is a framework
! directory that is in a framework's \fIFrameworks\fR directory.
  Includes of subframework headers can only appear in a header of a
  framework that contains the subframework, or in a sibling subframework
  header.  Two subframeworks are siblings if they occur in the same
--- 23303,23309 ----
  directory excluding the \fI.framework\fR.  Headers associated with
  the framework are found in one of those two directories, with
  \&\fIHeaders\fR being searched first.  A subframework is a framework
! directory that is in a framework\*(Aqs \fIFrameworks\fR directory.
  Includes of subframework headers can only appear in a header of a
  framework that contains the subframework, or in a sibling subframework
  header.  Two subframeworks are siblings if they occur in the same
*************** in \fI/System/Library/Frameworks\fR and
*** 23385,23424 ****
  \&\f(CW\*(C`#include \*(C'\fR, where \fIFramework\fR denotes
  the name of the framework and \fIheader.h\fR is found in the
  \&\fIPrivateHeaders\fR or \fIHeaders\fR directory.
! .IP "\fB\-iframework\fR\fIdir\fR" 4
  .IX Item "-iframeworkdir"
  Like \fB\-F\fR except the directory is a treated as a system
  directory.  The main difference between this \fB\-iframework\fR and
  \&\fB\-F\fR is that with \fB\-iframework\fR the compiler does not
  warn about constructs contained within header files found via
  \&\fIdir\fR.  This option is valid only for the C family of languages.
! .IP "\fB\-gused\fR" 4
  .IX Item "-gused"
  Emit debugging information for symbols that are used.  For stabs
  debugging format, this enables \fB\-feliminate\-unused\-debug\-symbols\fR.
! This is by default \s-1ON.\s0
! .IP "\fB\-gfull\fR" 4
  .IX Item "-gfull"
  Emit debugging information for all symbols and types.
! .IP "\fB\-fconstant\-cfstrings\fR" 4
  .IX Item "-fconstant-cfstrings"
  The \fB\-fconstant\-cfstrings\fR is an alias for \fB\-mconstant\-cfstrings\fR.
! .IP "\fB\-mconstant\-cfstrings\fR" 4
  .IX Item "-mconstant-cfstrings"
  When the NeXT runtime is being used (the default on these systems), override
  any \fB\-fconstant\-string\-class\fR setting and cause \f(CW\*(C`@"..."\*(C'\fR
  literals to be laid out as constant CoreFoundation strings.
! .IP "\fB\-mmacosx\-version\-min=\fR\fIversion\fR" 4
  .IX Item "-mmacosx-version-min=version"
  The earliest version of MacOS X that this executable will run on is
  \&\fIversion\fR.  Typical values supported for \fIversion\fR include \f(CW12\fR,
  \&\f(CW10.12\fR, and \f(CW10.5.8\fR.
  .Sp
! If the compiler was built to use the system's headers by default,
  then the default for this option is the system version on which the
  compiler is running, otherwise the default is to make choices that
  are compatible with as many systems and code bases as possible.
! .IP "\fB\-mkernel\fR" 4
  .IX Item "-mkernel"
  Enable kernel development mode.  The \fB\-mkernel\fR option sets
  \&\fB\-static\fR, \fB\-fno\-common\fR, \fB\-fno\-use\-cxa\-atexit\fR,
--- 23316,23355 ----
  \&\f(CW\*(C`#include \*(C'\fR, where \fIFramework\fR denotes
  the name of the framework and \fIheader.h\fR is found in the
  \&\fIPrivateHeaders\fR or \fIHeaders\fR directory.
! .IP \fB\-iframework\fR\fIdir\fR 4
  .IX Item "-iframeworkdir"
  Like \fB\-F\fR except the directory is a treated as a system
  directory.  The main difference between this \fB\-iframework\fR and
  \&\fB\-F\fR is that with \fB\-iframework\fR the compiler does not
  warn about constructs contained within header files found via
  \&\fIdir\fR.  This option is valid only for the C family of languages.
! .IP \fB\-gused\fR 4
  .IX Item "-gused"
  Emit debugging information for symbols that are used.  For stabs
  debugging format, this enables \fB\-feliminate\-unused\-debug\-symbols\fR.
! This is by default ON.
! .IP \fB\-gfull\fR 4
  .IX Item "-gfull"
  Emit debugging information for all symbols and types.
! .IP \fB\-fconstant\-cfstrings\fR 4
  .IX Item "-fconstant-cfstrings"
  The \fB\-fconstant\-cfstrings\fR is an alias for \fB\-mconstant\-cfstrings\fR.
! .IP \fB\-mconstant\-cfstrings\fR 4
  .IX Item "-mconstant-cfstrings"
  When the NeXT runtime is being used (the default on these systems), override
  any \fB\-fconstant\-string\-class\fR setting and cause \f(CW\*(C`@"..."\*(C'\fR
  literals to be laid out as constant CoreFoundation strings.
! .IP \fB\-mmacosx\-version\-min=\fR\fIversion\fR 4
  .IX Item "-mmacosx-version-min=version"
  The earliest version of MacOS X that this executable will run on is
  \&\fIversion\fR.  Typical values supported for \fIversion\fR include \f(CW12\fR,
  \&\f(CW10.12\fR, and \f(CW10.5.8\fR.
  .Sp
! If the compiler was built to use the system\*(Aqs headers by default,
  then the default for this option is the system version on which the
  compiler is running, otherwise the default is to make choices that
  are compatible with as many systems and code bases as possible.
! .IP \fB\-mkernel\fR 4
  .IX Item "-mkernel"
  Enable kernel development mode.  The \fB\-mkernel\fR option sets
  \&\fB\-static\fR, \fB\-fno\-common\fR, \fB\-fno\-use\-cxa\-atexit\fR,
*************** Enable kernel development mode.  The \fB
*** 23427,23712 ****
  applicable.  This mode also sets \fB\-mno\-altivec\fR,
  \&\fB\-msoft\-float\fR, \fB\-fno\-builtin\fR and
  \&\fB\-mlong\-branch\fR for PowerPC targets.
! .IP "\fB\-mone\-byte\-bool\fR" 4
  .IX Item "-mone-byte-bool"
  Override the defaults for \f(CW\*(C`bool\*(C'\fR so that \f(CW\*(C`sizeof(bool)==1\*(C'\fR.
! By default \f(CW\*(C`sizeof(bool)\*(C'\fR is \f(CW4\fR when compiling for
  Darwin/PowerPC and \f(CW1\fR when compiling for Darwin/x86, so this
  option has no effect on x86.
  .Sp
! \&\fBWarning:\fR The \fB\-mone\-byte\-bool\fR switch causes \s-1GCC\s0
  to generate code that is not binary compatible with code generated
  without that switch.  Using this switch may require recompiling all
  other modules in a program, including system libraries.  Use this
! switch to conform to a non-default data model.
! .IP "\fB\-mfix\-and\-continue\fR" 4
  .IX Item "-mfix-and-continue"
  .PD 0
! .IP "\fB\-ffix\-and\-continue\fR" 4
  .IX Item "-ffix-and-continue"
! .IP "\fB\-findirect\-data\fR" 4
  .IX Item "-findirect-data"
  .PD
  Generate code suitable for fast turnaround development, such as to
! allow \s-1GDB\s0 to dynamically load \fI.o\fR files into already-running
  programs.  \fB\-findirect\-data\fR and \fB\-ffix\-and\-continue\fR
  are provided for backwards compatibility.
! .IP "\fB\-all_load\fR" 4
  .IX Item "-all_load"
  Loads all members of static archive libraries.
  See man \fBld\fR\|(1) for more information.
! .IP "\fB\-arch_errors_fatal\fR" 4
  .IX Item "-arch_errors_fatal"
  Cause the errors having to do with files that have the wrong architecture
  to be fatal.
! .IP "\fB\-bind_at_load\fR" 4
  .IX Item "-bind_at_load"
  Causes the output file to be marked such that the dynamic linker will
  bind all undefined references when the file is loaded or launched.
! .IP "\fB\-bundle\fR" 4
  .IX Item "-bundle"
! Produce a Mach-o bundle format file.
  See man \fBld\fR\|(1) for more information.
  .IP "\fB\-bundle_loader\fR \fIexecutable\fR" 4
  .IX Item "-bundle_loader executable"
  This option specifies the \fIexecutable\fR that will load the build
  output file being linked.  See man \fBld\fR\|(1) for more information.
! .IP "\fB\-dynamiclib\fR" 4
  .IX Item "-dynamiclib"
! When passed this option, \s-1GCC\s0 produces a dynamic library instead of
  an executable when linking, using the Darwin \fIlibtool\fR command.
! .IP "\fB\-force_cpusubtype_ALL\fR" 4
  .IX Item "-force_cpusubtype_ALL"
! This causes \s-1GCC\s0's output file to have the \fB\s-1ALL\s0\fR subtype, instead of
  one controlled by the \fB\-mcpu\fR or \fB\-march\fR option.
  .IP "\fB\-allowable_client\fR  \fIclient_name\fR" 4
  .IX Item "-allowable_client client_name"
  .PD 0
! .IP "\fB\-client_name\fR" 4
  .IX Item "-client_name"
! .IP "\fB\-compatibility_version\fR" 4
  .IX Item "-compatibility_version"
! .IP "\fB\-current_version\fR" 4
  .IX Item "-current_version"
! .IP "\fB\-dead_strip\fR" 4
  .IX Item "-dead_strip"
! .IP "\fB\-dependency\-file\fR" 4
  .IX Item "-dependency-file"
! .IP "\fB\-dylib_file\fR" 4
  .IX Item "-dylib_file"
! .IP "\fB\-dylinker_install_name\fR" 4
  .IX Item "-dylinker_install_name"
! .IP "\fB\-dynamic\fR" 4
  .IX Item "-dynamic"
! .IP "\fB\-exported_symbols_list\fR" 4
  .IX Item "-exported_symbols_list"
! .IP "\fB\-filelist\fR" 4
  .IX Item "-filelist"
! .IP "\fB\-flat_namespace\fR" 4
  .IX Item "-flat_namespace"
! .IP "\fB\-force_flat_namespace\fR" 4
  .IX Item "-force_flat_namespace"
! .IP "\fB\-headerpad_max_install_names\fR" 4
  .IX Item "-headerpad_max_install_names"
! .IP "\fB\-image_base\fR" 4
  .IX Item "-image_base"
! .IP "\fB\-init\fR" 4
  .IX Item "-init"
! .IP "\fB\-install_name\fR" 4
  .IX Item "-install_name"
! .IP "\fB\-keep_private_externs\fR" 4
  .IX Item "-keep_private_externs"
! .IP "\fB\-multi_module\fR" 4
  .IX Item "-multi_module"
! .IP "\fB\-multiply_defined\fR" 4
  .IX Item "-multiply_defined"
! .IP "\fB\-multiply_defined_unused\fR" 4
  .IX Item "-multiply_defined_unused"
! .IP "\fB\-noall_load\fR" 4
  .IX Item "-noall_load"
! .IP "\fB\-no_dead_strip_inits_and_terms\fR" 4
  .IX Item "-no_dead_strip_inits_and_terms"
! .IP "\fB\-nofixprebinding\fR" 4
  .IX Item "-nofixprebinding"
! .IP "\fB\-nomultidefs\fR" 4
  .IX Item "-nomultidefs"
! .IP "\fB\-noprebind\fR" 4
  .IX Item "-noprebind"
! .IP "\fB\-noseglinkedit\fR" 4
  .IX Item "-noseglinkedit"
! .IP "\fB\-pagezero_size\fR" 4
  .IX Item "-pagezero_size"
! .IP "\fB\-prebind\fR" 4
  .IX Item "-prebind"
! .IP "\fB\-prebind_all_twolevel_modules\fR" 4
  .IX Item "-prebind_all_twolevel_modules"
! .IP "\fB\-private_bundle\fR" 4
  .IX Item "-private_bundle"
! .IP "\fB\-read_only_relocs\fR" 4
  .IX Item "-read_only_relocs"
! .IP "\fB\-sectalign\fR" 4
  .IX Item "-sectalign"
! .IP "\fB\-sectobjectsymbols\fR" 4
  .IX Item "-sectobjectsymbols"
! .IP "\fB\-whyload\fR" 4
  .IX Item "-whyload"
! .IP "\fB\-seg1addr\fR" 4
  .IX Item "-seg1addr"
! .IP "\fB\-sectcreate\fR" 4
  .IX Item "-sectcreate"
! .IP "\fB\-sectobjectsymbols\fR" 4
  .IX Item "-sectobjectsymbols"
! .IP "\fB\-sectorder\fR" 4
  .IX Item "-sectorder"
! .IP "\fB\-segaddr\fR" 4
  .IX Item "-segaddr"
! .IP "\fB\-segs_read_only_addr\fR" 4
  .IX Item "-segs_read_only_addr"
! .IP "\fB\-segs_read_write_addr\fR" 4
  .IX Item "-segs_read_write_addr"
! .IP "\fB\-seg_addr_table\fR" 4
  .IX Item "-seg_addr_table"
! .IP "\fB\-seg_addr_table_filename\fR" 4
  .IX Item "-seg_addr_table_filename"
! .IP "\fB\-seglinkedit\fR" 4
  .IX Item "-seglinkedit"
! .IP "\fB\-segprot\fR" 4
  .IX Item "-segprot"
! .IP "\fB\-segs_read_only_addr\fR" 4
  .IX Item "-segs_read_only_addr"
! .IP "\fB\-segs_read_write_addr\fR" 4
  .IX Item "-segs_read_write_addr"
! .IP "\fB\-single_module\fR" 4
  .IX Item "-single_module"
! .IP "\fB\-static\fR" 4
  .IX Item "-static"
! .IP "\fB\-sub_library\fR" 4
  .IX Item "-sub_library"
! .IP "\fB\-sub_umbrella\fR" 4
  .IX Item "-sub_umbrella"
! .IP "\fB\-twolevel_namespace\fR" 4
  .IX Item "-twolevel_namespace"
! .IP "\fB\-umbrella\fR" 4
  .IX Item "-umbrella"
! .IP "\fB\-undefined\fR" 4
  .IX Item "-undefined"
! .IP "\fB\-unexported_symbols_list\fR" 4
  .IX Item "-unexported_symbols_list"
! .IP "\fB\-weak_reference_mismatches\fR" 4
  .IX Item "-weak_reference_mismatches"
! .IP "\fB\-whatsloaded\fR" 4
  .IX Item "-whatsloaded"
  .PD
  These options are passed to the Darwin linker.  The Darwin linker man page
  describes them in detail.
  .PP
! \fI\s-1DEC\s0 Alpha Options\fR
  .IX Subsection "DEC Alpha Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1DEC\s0 Alpha implementations:
! .IP "\fB\-mno\-soft\-float\fR" 4
  .IX Item "-mno-soft-float"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
! Use (do not use) the hardware floating-point instructions for
! floating-point operations.  When \fB\-msoft\-float\fR is specified,
! functions in \fIlibgcc.a\fR are used to perform floating-point
  operations.  Unless they are replaced by routines that emulate the
! floating-point operations, or compiled in such a way as to call such
! emulations routines, these routines issue floating-point
! operations.   If you are compiling for an Alpha without floating-point
  operations, you must ensure that the library is built so as not to call
  them.
  .Sp
! Note that Alpha implementations without floating-point operations are
! required to have floating-point registers.
! .IP "\fB\-mfp\-reg\fR" 4
  .IX Item "-mfp-reg"
  .PD 0
! .IP "\fB\-mno\-fp\-regs\fR" 4
  .IX Item "-mno-fp-regs"
  .PD
! Generate code that uses (does not use) the floating-point register set.
! \&\fB\-mno\-fp\-regs\fR implies \fB\-msoft\-float\fR.  If the floating-point
! register set is not used, floating-point operands are passed in integer
! registers as if they were integers and floating-point results are passed
! in \f(CW$0\fR instead of \f(CW$f0\fR.  This is a non-standard calling sequence,
! so any function with a floating-point argument or return value called by code
  compiled with \fB\-mno\-fp\-regs\fR must also be compiled with that
  option.
  .Sp
  A typical use of this option is building a kernel that does not use,
! and hence need not save and restore, any floating-point registers.
! .IP "\fB\-mieee\fR" 4
  .IX Item "-mieee"
! The Alpha architecture implements floating-point hardware optimized for
! maximum performance.  It is mostly compliant with the \s-1IEEE\s0 floating-point
  standard.  However, for full compliance, software assistance is
! required.  This option generates code fully IEEE-compliant code
! \&\fIexcept\fR that the \fIinexact-flag\fR is not maintained (see below).
  If this option is turned on, the preprocessor macro \f(CW\*(C`_IEEE_FP\*(C'\fR is
  defined during compilation.  The resulting code is less efficient but is
! able to correctly support denormalized numbers and exceptional \s-1IEEE\s0
! values such as not-a-number and plus/minus infinity.  Other Alpha
  compilers call this option \fB\-ieee_with_no_inexact\fR.
! .IP "\fB\-mieee\-with\-inexact\fR" 4
  .IX Item "-mieee-with-inexact"
  This is like \fB\-mieee\fR except the generated code also maintains
! the \s-1IEEE\s0 \fIinexact-flag\fR.  Turning on this option causes the
! generated code to implement fully-compliant \s-1IEEE\s0 math.  In addition to
  \&\f(CW\*(C`_IEEE_FP\*(C'\fR, \f(CW\*(C`_IEEE_FP_EXACT\*(C'\fR is defined as a preprocessor
  macro.  On some Alpha implementations the resulting code may execute
  significantly slower than the code generated by default.  Since there is
! very little code that depends on the \fIinexact-flag\fR, you should
  normally not specify this option.  Other Alpha compilers call this
  option \fB\-ieee_with_inexact\fR.
! .IP "\fB\-mfp\-trap\-mode=\fR\fItrap-mode\fR" 4
  .IX Item "-mfp-trap-mode=trap-mode"
! This option controls what floating-point related traps are enabled.
! Other Alpha compilers call this option \fB\-fptm\fR \fItrap-mode\fR.
  The trap mode can be set to one of four values:
  .RS 4
! .IP "\fBn\fR" 4
  .IX Item "n"
  This is the default (normal) setting.  The only traps that are enabled
  are the ones that cannot be disabled in software (e.g., division by zero
  trap).
! .IP "\fBu\fR" 4
  .IX Item "u"
  In addition to the traps enabled by \fBn\fR, underflow traps are enabled
  as well.
! .IP "\fBsu\fR" 4
  .IX Item "su"
  Like \fBu\fR, but the instructions are marked to be safe for software
  completion (see Alpha architecture manual for details).
! .IP "\fBsui\fR" 4
  .IX Item "sui"
  Like \fBsu\fR, but inexact traps are enabled as well.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mfp\-rounding\-mode=\fR\fIrounding-mode\fR" 4
  .IX Item "-mfp-rounding-mode=rounding-mode"
! Selects the \s-1IEEE\s0 rounding mode.  Other Alpha compilers call this option
! \&\fB\-fprm\fR \fIrounding-mode\fR.  The \fIrounding-mode\fR can be one
  of:
  .RS 4
! .IP "\fBn\fR" 4
  .IX Item "n"
! Normal \s-1IEEE\s0 rounding mode.  Floating-point numbers are rounded towards
  the nearest machine number or towards the even machine number in case
  of a tie.
! .IP "\fBm\fR" 4
  .IX Item "m"
  Round towards minus infinity.
! .IP "\fBc\fR" 4
  .IX Item "c"
! Chopped rounding mode.  Floating-point numbers are rounded towards zero.
! .IP "\fBd\fR" 4
  .IX Item "d"
! Dynamic rounding mode.  A field in the floating-point control register
  (\fIfpcr\fR, see Alpha architecture reference manual) controls the
  rounding mode in effect.  The C library initializes this register for
  rounding towards plus infinity.  Thus, unless your program modifies the
--- 23358,23643 ----
  applicable.  This mode also sets \fB\-mno\-altivec\fR,
  \&\fB\-msoft\-float\fR, \fB\-fno\-builtin\fR and
  \&\fB\-mlong\-branch\fR for PowerPC targets.
! .IP \fB\-mone\-byte\-bool\fR 4
  .IX Item "-mone-byte-bool"
  Override the defaults for \f(CW\*(C`bool\*(C'\fR so that \f(CW\*(C`sizeof(bool)==1\*(C'\fR.
! By default \f(CWsizeof(bool)\fR is \f(CW4\fR when compiling for
  Darwin/PowerPC and \f(CW1\fR when compiling for Darwin/x86, so this
  option has no effect on x86.
  .Sp
! \&\fBWarning:\fR The \fB\-mone\-byte\-bool\fR switch causes 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.
! .IP \fB\-mfix\-and\-continue\fR 4
  .IX Item "-mfix-and-continue"
  .PD 0
! .IP \fB\-ffix\-and\-continue\fR 4
  .IX Item "-ffix-and-continue"
! .IP \fB\-findirect\-data\fR 4
  .IX Item "-findirect-data"
  .PD
  Generate code suitable for fast turnaround development, such as to
! allow GDB to dynamically load \fI.o\fR files into already\-running
  programs.  \fB\-findirect\-data\fR and \fB\-ffix\-and\-continue\fR
  are provided for backwards compatibility.
! .IP \fB\-all_load\fR 4
  .IX Item "-all_load"
  Loads all members of static archive libraries.
  See man \fBld\fR\|(1) for more information.
! .IP \fB\-arch_errors_fatal\fR 4
  .IX Item "-arch_errors_fatal"
  Cause the errors having to do with files that have the wrong architecture
  to be fatal.
! .IP \fB\-bind_at_load\fR 4
  .IX Item "-bind_at_load"
  Causes the output file to be marked such that the dynamic linker will
  bind all undefined references when the file is loaded or launched.
! .IP \fB\-bundle\fR 4
  .IX Item "-bundle"
! Produce a Mach\-o bundle format file.
  See man \fBld\fR\|(1) for more information.
  .IP "\fB\-bundle_loader\fR \fIexecutable\fR" 4
  .IX Item "-bundle_loader executable"
  This option specifies the \fIexecutable\fR that will load the build
  output file being linked.  See man \fBld\fR\|(1) for more information.
! .IP \fB\-dynamiclib\fR 4
  .IX Item "-dynamiclib"
! When passed this option, GCC produces a dynamic library instead of
  an executable when linking, using the Darwin \fIlibtool\fR command.
! .IP \fB\-force_cpusubtype_ALL\fR 4
  .IX Item "-force_cpusubtype_ALL"
! This causes GCC\*(Aqs output file to have the \fBALL\fR subtype, instead of
  one controlled by the \fB\-mcpu\fR or \fB\-march\fR option.
  .IP "\fB\-allowable_client\fR  \fIclient_name\fR" 4
  .IX Item "-allowable_client client_name"
  .PD 0
! .IP \fB\-client_name\fR 4
  .IX Item "-client_name"
! .IP \fB\-compatibility_version\fR 4
  .IX Item "-compatibility_version"
! .IP \fB\-current_version\fR 4
  .IX Item "-current_version"
! .IP \fB\-dead_strip\fR 4
  .IX Item "-dead_strip"
! .IP \fB\-dependency\-file\fR 4
  .IX Item "-dependency-file"
! .IP \fB\-dylib_file\fR 4
  .IX Item "-dylib_file"
! .IP \fB\-dylinker_install_name\fR 4
  .IX Item "-dylinker_install_name"
! .IP \fB\-dynamic\fR 4
  .IX Item "-dynamic"
! .IP \fB\-exported_symbols_list\fR 4
  .IX Item "-exported_symbols_list"
! .IP \fB\-filelist\fR 4
  .IX Item "-filelist"
! .IP \fB\-flat_namespace\fR 4
  .IX Item "-flat_namespace"
! .IP \fB\-force_flat_namespace\fR 4
  .IX Item "-force_flat_namespace"
! .IP \fB\-headerpad_max_install_names\fR 4
  .IX Item "-headerpad_max_install_names"
! .IP \fB\-image_base\fR 4
  .IX Item "-image_base"
! .IP \fB\-init\fR 4
  .IX Item "-init"
! .IP \fB\-install_name\fR 4
  .IX Item "-install_name"
! .IP \fB\-keep_private_externs\fR 4
  .IX Item "-keep_private_externs"
! .IP \fB\-multi_module\fR 4
  .IX Item "-multi_module"
! .IP \fB\-multiply_defined\fR 4
  .IX Item "-multiply_defined"
! .IP \fB\-multiply_defined_unused\fR 4
  .IX Item "-multiply_defined_unused"
! .IP \fB\-noall_load\fR 4
  .IX Item "-noall_load"
! .IP \fB\-no_dead_strip_inits_and_terms\fR 4
  .IX Item "-no_dead_strip_inits_and_terms"
! .IP \fB\-nofixprebinding\fR 4
  .IX Item "-nofixprebinding"
! .IP \fB\-nomultidefs\fR 4
  .IX Item "-nomultidefs"
! .IP \fB\-noprebind\fR 4
  .IX Item "-noprebind"
! .IP \fB\-noseglinkedit\fR 4
  .IX Item "-noseglinkedit"
! .IP \fB\-pagezero_size\fR 4
  .IX Item "-pagezero_size"
! .IP \fB\-prebind\fR 4
  .IX Item "-prebind"
! .IP \fB\-prebind_all_twolevel_modules\fR 4
  .IX Item "-prebind_all_twolevel_modules"
! .IP \fB\-private_bundle\fR 4
  .IX Item "-private_bundle"
! .IP \fB\-read_only_relocs\fR 4
  .IX Item "-read_only_relocs"
! .IP \fB\-sectalign\fR 4
  .IX Item "-sectalign"
! .IP \fB\-sectobjectsymbols\fR 4
  .IX Item "-sectobjectsymbols"
! .IP \fB\-whyload\fR 4
  .IX Item "-whyload"
! .IP \fB\-seg1addr\fR 4
  .IX Item "-seg1addr"
! .IP \fB\-sectcreate\fR 4
  .IX Item "-sectcreate"
! .IP \fB\-sectobjectsymbols\fR 4
  .IX Item "-sectobjectsymbols"
! .IP \fB\-sectorder\fR 4
  .IX Item "-sectorder"
! .IP \fB\-segaddr\fR 4
  .IX Item "-segaddr"
! .IP \fB\-segs_read_only_addr\fR 4
  .IX Item "-segs_read_only_addr"
! .IP \fB\-segs_read_write_addr\fR 4
  .IX Item "-segs_read_write_addr"
! .IP \fB\-seg_addr_table\fR 4
  .IX Item "-seg_addr_table"
! .IP \fB\-seg_addr_table_filename\fR 4
  .IX Item "-seg_addr_table_filename"
! .IP \fB\-seglinkedit\fR 4
  .IX Item "-seglinkedit"
! .IP \fB\-segprot\fR 4
  .IX Item "-segprot"
! .IP \fB\-segs_read_only_addr\fR 4
  .IX Item "-segs_read_only_addr"
! .IP \fB\-segs_read_write_addr\fR 4
  .IX Item "-segs_read_write_addr"
! .IP \fB\-single_module\fR 4
  .IX Item "-single_module"
! .IP \fB\-static\fR 4
  .IX Item "-static"
! .IP \fB\-sub_library\fR 4
  .IX Item "-sub_library"
! .IP \fB\-sub_umbrella\fR 4
  .IX Item "-sub_umbrella"
! .IP \fB\-twolevel_namespace\fR 4
  .IX Item "-twolevel_namespace"
! .IP \fB\-umbrella\fR 4
  .IX Item "-umbrella"
! .IP \fB\-undefined\fR 4
  .IX Item "-undefined"
! .IP \fB\-unexported_symbols_list\fR 4
  .IX Item "-unexported_symbols_list"
! .IP \fB\-weak_reference_mismatches\fR 4
  .IX Item "-weak_reference_mismatches"
! .IP \fB\-whatsloaded\fR 4
  .IX Item "-whatsloaded"
  .PD
  These options are passed to the Darwin linker.  The Darwin linker man page
  describes them in detail.
  .PP
! \fIDEC Alpha Options\fR
  .IX Subsection "DEC Alpha Options"
  .PP
! These \fB\-m\fR options are defined for the DEC Alpha implementations:
! .IP \fB\-mno\-soft\-float\fR 4
  .IX Item "-mno-soft-float"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
! Use (do not use) the hardware floating\-point instructions for
! floating\-point operations.  When \fB\-msoft\-float\fR is specified,
! functions in \fIlibgcc.a\fR are used to perform floating\-point
  operations.  Unless they are replaced by routines that emulate the
! floating\-point operations, or compiled in such a way as to call such
! emulations routines, these routines issue floating\-point
! operations.   If you are compiling for an Alpha without floating\-point
  operations, you must ensure that the library is built so as not to call
  them.
  .Sp
! Note that Alpha implementations without floating\-point operations are
! required to have floating\-point registers.
! .IP \fB\-mfp\-reg\fR 4
  .IX Item "-mfp-reg"
  .PD 0
! .IP \fB\-mno\-fp\-regs\fR 4
  .IX Item "-mno-fp-regs"
  .PD
! Generate code that uses (does not use) the floating\-point register set.
! \&\fB\-mno\-fp\-regs\fR implies \fB\-msoft\-float\fR.  If the floating\-point
! register set is not used, floating\-point operands are passed in integer
! registers as if they were integers and floating\-point results are passed
! in \f(CW$0\fR instead of \f(CW$f0\fR.  This is a non\-standard calling sequence,
! so any function with a floating\-point argument or return value called by code
  compiled with \fB\-mno\-fp\-regs\fR must also be compiled with that
  option.
  .Sp
  A typical use of this option is building a kernel that does not use,
! and hence need not save and restore, any floating\-point registers.
! .IP \fB\-mieee\fR 4
  .IX Item "-mieee"
! The Alpha architecture implements floating\-point hardware optimized for
! maximum performance.  It is mostly compliant with the IEEE floating\-point
  standard.  However, for full compliance, software assistance is
! required.  This option generates code fully IEEE\-compliant code
! \&\fIexcept\fR that the \fIinexact\-flag\fR is not maintained (see below).
  If this option is turned on, the preprocessor macro \f(CW\*(C`_IEEE_FP\*(C'\fR is
  defined during compilation.  The resulting code is less efficient but is
! able to correctly support denormalized numbers and exceptional IEEE
! values such as not\-a\-number and plus/minus infinity.  Other Alpha
  compilers call this option \fB\-ieee_with_no_inexact\fR.
! .IP \fB\-mieee\-with\-inexact\fR 4
  .IX Item "-mieee-with-inexact"
  This is like \fB\-mieee\fR except the generated code also maintains
! the IEEE \fIinexact\-flag\fR.  Turning on this option causes the
! generated code to implement fully\-compliant IEEE math.  In addition to
  \&\f(CW\*(C`_IEEE_FP\*(C'\fR, \f(CW\*(C`_IEEE_FP_EXACT\*(C'\fR is defined as a preprocessor
  macro.  On some Alpha implementations the resulting code may execute
  significantly slower than the code generated by default.  Since there is
! very little code that depends on the \fIinexact\-flag\fR, you should
  normally not specify this option.  Other Alpha compilers call this
  option \fB\-ieee_with_inexact\fR.
! .IP \fB\-mfp\-trap\-mode=\fR\fItrap\-mode\fR 4
  .IX Item "-mfp-trap-mode=trap-mode"
! This option controls what floating\-point related traps are enabled.
! Other Alpha compilers call this option \fB\-fptm\fR \fItrap\-mode\fR.
  The trap mode can be set to one of four values:
  .RS 4
! .IP \fBn\fR 4
  .IX Item "n"
  This is the default (normal) setting.  The only traps that are enabled
  are the ones that cannot be disabled in software (e.g., division by zero
  trap).
! .IP \fBu\fR 4
  .IX Item "u"
  In addition to the traps enabled by \fBn\fR, underflow traps are enabled
  as well.
! .IP \fBsu\fR 4
  .IX Item "su"
  Like \fBu\fR, but the instructions are marked to be safe for software
  completion (see Alpha architecture manual for details).
! .IP \fBsui\fR 4
  .IX Item "sui"
  Like \fBsu\fR, but inexact traps are enabled as well.
  .RE
  .RS 4
  .RE
! .IP \fB\-mfp\-rounding\-mode=\fR\fIrounding\-mode\fR 4
  .IX Item "-mfp-rounding-mode=rounding-mode"
! Selects the IEEE rounding mode.  Other Alpha compilers call this option
! \&\fB\-fprm\fR \fIrounding\-mode\fR.  The \fIrounding\-mode\fR can be one
  of:
  .RS 4
! .IP \fBn\fR 4
  .IX Item "n"
! Normal IEEE rounding mode.  Floating\-point numbers are rounded towards
  the nearest machine number or towards the even machine number in case
  of a tie.
! .IP \fBm\fR 4
  .IX Item "m"
  Round towards minus infinity.
! .IP \fBc\fR 4
  .IX Item "c"
! Chopped rounding mode.  Floating\-point numbers are rounded towards zero.
! .IP \fBd\fR 4
  .IX Item "d"
! Dynamic rounding mode.  A field in the floating\-point control register
  (\fIfpcr\fR, see Alpha architecture reference manual) controls the
  rounding mode in effect.  The C library initializes this register for
  rounding towards plus infinity.  Thus, unless your program modifies the
*************** rounding towards plus infinity.  Thus, u
*** 23714,23818 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-mtrap\-precision=\fR\fItrap-precision\fR" 4
  .IX Item "-mtrap-precision=trap-precision"
! In the Alpha architecture, floating-point traps are imprecise.  This
  means without software assistance it is impossible to recover from a
  floating trap and program execution normally needs to be terminated.
! \&\s-1GCC\s0 can generate code that can assist operating system trap handlers
! in determining the exact location that caused a floating-point trap.
  Depending on the requirements of an application, different levels of
  precisions can be selected:
  .RS 4
! .IP "\fBp\fR" 4
  .IX Item "p"
  Program precision.  This option is the default and means a trap handler
! can only identify which program caused a floating-point exception.
! .IP "\fBf\fR" 4
  .IX Item "f"
  Function precision.  The trap handler can determine the function that
! caused a floating-point exception.
! .IP "\fBi\fR" 4
  .IX Item "i"
  Instruction precision.  The trap handler can determine the exact
! instruction that caused a floating-point exception.
  .RE
  .RS 4
  .Sp
  Other Alpha compilers provide the equivalent options called
  \&\fB\-scope_safe\fR and \fB\-resumption_safe\fR.
  .RE
! .IP "\fB\-mieee\-conformant\fR" 4
  .IX Item "-mieee-conformant"
! This option marks the generated code as \s-1IEEE\s0 conformant.  You must not
  use this option unless you also specify \fB\-mtrap\-precision=i\fR and either
  \&\fB\-mfp\-trap\-mode=su\fR or \fB\-mfp\-trap\-mode=sui\fR.  Its only effect
  is to emit the line \fB.eflag 48\fR in the function prologue of the
  generated assembly file.
! .IP "\fB\-mbuild\-constants\fR" 4
  .IX Item "-mbuild-constants"
! Normally \s-1GCC\s0 examines a 32\- or 64\-bit integer constant to
  see if it can construct it from smaller constants in two or three
  instructions.  If it cannot, it outputs the constant as a literal and
  generates code to load it from the data segment at run time.
  .Sp
! Use this option to require \s-1GCC\s0 to construct \fIall\fR integer constants
  using code, even if it takes more instructions (the maximum is six).
  .Sp
  You typically use this option to build a shared library dynamic
  loader.  Itself a shared library, it must relocate itself in memory
  before it can find the variables and constants in its own data segment.
! .IP "\fB\-mbwx\fR" 4
  .IX Item "-mbwx"
  .PD 0
! .IP "\fB\-mno\-bwx\fR" 4
  .IX Item "-mno-bwx"
! .IP "\fB\-mcix\fR" 4
  .IX Item "-mcix"
! .IP "\fB\-mno\-cix\fR" 4
  .IX Item "-mno-cix"
! .IP "\fB\-mfix\fR" 4
  .IX Item "-mfix"
! .IP "\fB\-mno\-fix\fR" 4
  .IX Item "-mno-fix"
! .IP "\fB\-mmax\fR" 4
  .IX Item "-mmax"
! .IP "\fB\-mno\-max\fR" 4
  .IX Item "-mno-max"
  .PD
! Indicate whether \s-1GCC\s0 should generate code to use the optional \s-1BWX,
! CIX, FIX\s0 and \s-1MAX\s0 instruction sets.  The default is to use the instruction
! sets supported by the \s-1CPU\s0 type specified via \fB\-mcpu=\fR option or that
! of the \s-1CPU\s0 on which \s-1GCC\s0 was built if none is specified.
! .IP "\fB\-mfloat\-vax\fR" 4
  .IX Item "-mfloat-vax"
  .PD 0
! .IP "\fB\-mfloat\-ieee\fR" 4
  .IX Item "-mfloat-ieee"
  .PD
! Generate code that uses (does not use) \s-1VAX F\s0 and G floating-point
! arithmetic instead of \s-1IEEE\s0 single and double precision.
! .IP "\fB\-mexplicit\-relocs\fR" 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP "\fB\-mno\-explicit\-relocs\fR" 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Older Alpha assemblers provided no way to generate symbol relocations
  except via assembler macros.  Use of these macros does not allow
! optimal instruction scheduling.  \s-1GNU\s0 binutils as of version 2.12
  supports a new syntax that allows the compiler to explicitly mark
  which relocations should apply to which instructions.  This option
! is mostly useful for debugging, as \s-1GCC\s0 detects the capabilities of
  the assembler when it is built and sets the default accordingly.
! .IP "\fB\-msmall\-data\fR" 4
  .IX Item "-msmall-data"
  .PD 0
! .IP "\fB\-mlarge\-data\fR" 4
  .IX Item "-mlarge-data"
  .PD
  When \fB\-mexplicit\-relocs\fR is in effect, static data is
! accessed via \fIgp-relative\fR relocations.  When \fB\-msmall\-data\fR
  is used, objects 8 bytes long or smaller are placed in a \fIsmall data area\fR
  (the \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR sections) and are accessed via
  16\-bit relocations off of the \f(CW$gp\fR register.  This limits the
--- 23645,23749 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-mtrap\-precision=\fR\fItrap\-precision\fR 4
  .IX Item "-mtrap-precision=trap-precision"
! In the Alpha architecture, floating\-point traps are imprecise.  This
  means without software assistance it is impossible to recover from a
  floating trap and program execution normally needs to be terminated.
! 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:
  .RS 4
! .IP \fBp\fR 4
  .IX Item "p"
  Program precision.  This option is the default and means a trap handler
! can only identify which program caused a floating\-point exception.
! .IP \fBf\fR 4
  .IX Item "f"
  Function precision.  The trap handler can determine the function that
! caused a floating\-point exception.
! .IP \fBi\fR 4
  .IX Item "i"
  Instruction precision.  The trap handler can determine the exact
! instruction that caused a floating\-point exception.
  .RE
  .RS 4
  .Sp
  Other Alpha compilers provide the equivalent options called
  \&\fB\-scope_safe\fR and \fB\-resumption_safe\fR.
  .RE
! .IP \fB\-mieee\-conformant\fR 4
  .IX Item "-mieee-conformant"
! This option marks the generated code as IEEE conformant.  You must not
  use this option unless you also specify \fB\-mtrap\-precision=i\fR and either
  \&\fB\-mfp\-trap\-mode=su\fR or \fB\-mfp\-trap\-mode=sui\fR.  Its only effect
  is to emit the line \fB.eflag 48\fR in the function prologue of the
  generated assembly file.
! .IP \fB\-mbuild\-constants\fR 4
  .IX Item "-mbuild-constants"
! Normally GCC examines a 32\- or 64\-bit integer constant to
  see if it can construct it from smaller constants in two or three
  instructions.  If it cannot, it outputs the constant as a literal and
  generates code to load it from the data segment at run time.
  .Sp
! Use this option to require GCC to construct \fIall\fR integer constants
  using code, even if it takes more instructions (the maximum is six).
  .Sp
  You typically use this option to build a shared library dynamic
  loader.  Itself a shared library, it must relocate itself in memory
  before it can find the variables and constants in its own data segment.
! .IP \fB\-mbwx\fR 4
  .IX Item "-mbwx"
  .PD 0
! .IP \fB\-mno\-bwx\fR 4
  .IX Item "-mno-bwx"
! .IP \fB\-mcix\fR 4
  .IX Item "-mcix"
! .IP \fB\-mno\-cix\fR 4
  .IX Item "-mno-cix"
! .IP \fB\-mfix\fR 4
  .IX Item "-mfix"
! .IP \fB\-mno\-fix\fR 4
  .IX Item "-mno-fix"
! .IP \fB\-mmax\fR 4
  .IX Item "-mmax"
! .IP \fB\-mno\-max\fR 4
  .IX Item "-mno-max"
  .PD
! Indicate whether 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 \fB\-mcpu=\fR option or that
! of the CPU on which GCC was built if none is specified.
! .IP \fB\-mfloat\-vax\fR 4
  .IX Item "-mfloat-vax"
  .PD 0
! .IP \fB\-mfloat\-ieee\fR 4
  .IX Item "-mfloat-ieee"
  .PD
! Generate code that uses (does not use) VAX F and G floating\-point
! arithmetic instead of IEEE single and double precision.
! .IP \fB\-mexplicit\-relocs\fR 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP \fB\-mno\-explicit\-relocs\fR 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Older Alpha assemblers provided no way to generate symbol relocations
  except via assembler macros.  Use of these macros does not allow
! optimal instruction scheduling.  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.
! .IP \fB\-msmall\-data\fR 4
  .IX Item "-msmall-data"
  .PD 0
! .IP \fB\-mlarge\-data\fR 4
  .IX Item "-mlarge-data"
  .PD
  When \fB\-mexplicit\-relocs\fR is in effect, static data is
! accessed via \fIgp\-relative\fR relocations.  When \fB\-msmall\-data\fR
  is used, objects 8 bytes long or smaller are placed in a \fIsmall data area\fR
  (the \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR sections) and are accessed via
  16\-bit relocations off of the \f(CW$gp\fR register.  This limits the
*************** directly accessed via a single instructi
*** 23822,23835 ****
  The default is \fB\-mlarge\-data\fR.  With this option the data area
  is limited to just below 2GB.  Programs that require more than 2GB of
  data must use \f(CW\*(C`malloc\*(C'\fR or \f(CW\*(C`mmap\*(C'\fR to allocate the data in the
! heap instead of in the program's data segment.
  .Sp
  When generating code for shared libraries, \fB\-fpic\fR implies
  \&\fB\-msmall\-data\fR and \fB\-fPIC\fR implies \fB\-mlarge\-data\fR.
! .IP "\fB\-msmall\-text\fR" 4
  .IX Item "-msmall-text"
  .PD 0
! .IP "\fB\-mlarge\-text\fR" 4
  .IX Item "-mlarge-text"
  .PD
  When \fB\-msmall\-text\fR is used, the compiler assumes that the
--- 23753,23766 ----
  The default is \fB\-mlarge\-data\fR.  With this option the data area
  is limited to just below 2GB.  Programs that require more than 2GB of
  data must use \f(CW\*(C`malloc\*(C'\fR or \f(CW\*(C`mmap\*(C'\fR to allocate the data in the
! heap instead of in the program\*(Aqs data segment.
  .Sp
  When generating code for shared libraries, \fB\-fpic\fR implies
  \&\fB\-msmall\-data\fR and \fB\-fPIC\fR implies \fB\-mlarge\-data\fR.
! .IP \fB\-msmall\-text\fR 4
  .IX Item "-msmall-text"
  .PD 0
! .IP \fB\-mlarge\-text\fR 4
  .IX Item "-mlarge-text"
  .PD
  When \fB\-msmall\-text\fR is used, the compiler assumes that the
*************** same \f(CW$gp\fR value, and thus reduce
*** 23840,23921 ****
  required for a function call from 4 to 1.
  .Sp
  The default is \fB\-mlarge\-text\fR.
! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set and instruction scheduling parameters for
! machine type \fIcpu_type\fR.  You can specify either the \fB\s-1EV\s0\fR
! style name or the corresponding chip number.  \s-1GCC\s0 supports scheduling
! parameters for the \s-1EV4, EV5\s0 and \s-1EV6\s0 family of processors and
  chooses the default values for the instruction set from the processor
! you specify.  If you do not specify a processor type, \s-1GCC\s0 defaults
  to the processor on which the compiler was built.
  .Sp
  Supported values for \fIcpu_type\fR are
  .RS 4
! .IP "\fBev4\fR" 4
  .IX Item "ev4"
  .PD 0
! .IP "\fBev45\fR" 4
  .IX Item "ev45"
! .IP "\fB21064\fR" 4
  .IX Item "21064"
  .PD
! Schedules as an \s-1EV4\s0 and has no instruction set extensions.
! .IP "\fBev5\fR" 4
  .IX Item "ev5"
  .PD 0
! .IP "\fB21164\fR" 4
  .IX Item "21164"
  .PD
! Schedules as an \s-1EV5\s0 and has no instruction set extensions.
! .IP "\fBev56\fR" 4
  .IX Item "ev56"
  .PD 0
! .IP "\fB21164a\fR" 4
  .IX Item "21164a"
  .PD
! Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 extension.
! .IP "\fBpca56\fR" 4
  .IX Item "pca56"
  .PD 0
! .IP "\fB21164pc\fR" 4
  .IX Item "21164pc"
! .IP "\fB21164PC\fR" 4
  .IX Item "21164PC"
  .PD
! Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 and \s-1MAX\s0 extensions.
! .IP "\fBev6\fR" 4
  .IX Item "ev6"
  .PD 0
! .IP "\fB21264\fR" 4
  .IX Item "21264"
  .PD
! Schedules as an \s-1EV6\s0 and supports the \s-1BWX, FIX,\s0 and \s-1MAX\s0 extensions.
! .IP "\fBev67\fR" 4
  .IX Item "ev67"
  .PD 0
! .IP "\fB21264a\fR" 4
  .IX Item "21264a"
  .PD
! Schedules as an \s-1EV6\s0 and supports the \s-1BWX, CIX, FIX,\s0 and \s-1MAX\s0 extensions.
  .RE
  .RS 4
  .Sp
  Native toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize
  the processor.
  .RE
! .IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
  .IX Item "-mtune=cpu_type"
  Set only the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR.  The instruction set is not changed.
  .Sp
  Native toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mtune=native\fR has no effect if \s-1GCC\s0 does not recognize
  the processor.
! .IP "\fB\-mmemory\-latency=\fR\fItime\fR" 4
  .IX Item "-mmemory-latency=time"
  Sets the latency the scheduler should assume for typical memory
  references as seen by the application.  This number is highly
--- 23771,23852 ----
  required for a function call from 4 to 1.
  .Sp
  The default is \fB\-mlarge\-text\fR.
! .IP \fB\-mcpu=\fR\fIcpu_type\fR 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set and instruction scheduling parameters for
! machine type \fIcpu_type\fR.  You can specify either the \fBEV\fR
! style name or the corresponding chip number.  GCC supports scheduling
! parameters for the EV4, EV5 and EV6 family of processors and
  chooses the default values for the instruction set from the processor
! you specify.  If you do not specify a processor type, GCC defaults
  to the processor on which the compiler was built.
  .Sp
  Supported values for \fIcpu_type\fR are
  .RS 4
! .IP \fBev4\fR 4
  .IX Item "ev4"
  .PD 0
! .IP \fBev45\fR 4
  .IX Item "ev45"
! .IP \fB21064\fR 4
  .IX Item "21064"
  .PD
! Schedules as an EV4 and has no instruction set extensions.
! .IP \fBev5\fR 4
  .IX Item "ev5"
  .PD 0
! .IP \fB21164\fR 4
  .IX Item "21164"
  .PD
! Schedules as an EV5 and has no instruction set extensions.
! .IP \fBev56\fR 4
  .IX Item "ev56"
  .PD 0
! .IP \fB21164a\fR 4
  .IX Item "21164a"
  .PD
! Schedules as an EV5 and supports the BWX extension.
! .IP \fBpca56\fR 4
  .IX Item "pca56"
  .PD 0
! .IP \fB21164pc\fR 4
  .IX Item "21164pc"
! .IP \fB21164PC\fR 4
  .IX Item "21164PC"
  .PD
! Schedules as an EV5 and supports the BWX and MAX extensions.
! .IP \fBev6\fR 4
  .IX Item "ev6"
  .PD 0
! .IP \fB21264\fR 4
  .IX Item "21264"
  .PD
! Schedules as an EV6 and supports the BWX, FIX, and MAX extensions.
! .IP \fBev67\fR 4
  .IX Item "ev67"
  .PD 0
! .IP \fB21264a\fR 4
  .IX Item "21264a"
  .PD
! Schedules as an EV6 and supports the BWX, CIX, FIX, and MAX extensions.
  .RE
  .RS 4
  .Sp
  Native toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mcpu=native\fR has no effect if GCC does not recognize
  the processor.
  .RE
! .IP \fB\-mtune=\fR\fIcpu_type\fR 4
  .IX Item "-mtune=cpu_type"
  Set only the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR.  The instruction set is not changed.
  .Sp
  Native toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mtune=native\fR has no effect if GCC does not recognize
  the processor.
! .IP \fB\-mmemory\-latency=\fR\fItime\fR 4
  .IX Item "-mmemory-latency=time"
  Sets the latency the scheduler should assume for typical memory
  references as seen by the application.  This number is highly
*************** and the size of the external cache on th
*** 23924,23962 ****
  .Sp
  Valid options for \fItime\fR are
  .RS 4
! .IP "\fInumber\fR" 4
  .IX Item "number"
  A decimal number representing clock cycles.
! .IP "\fBL1\fR" 4
  .IX Item "L1"
  .PD 0
! .IP "\fBL2\fR" 4
  .IX Item "L2"
! .IP "\fBL3\fR" 4
  .IX Item "L3"
! .IP "\fBmain\fR" 4
  .IX Item "main"
  .PD
  The compiler contains estimates of the number of clock cycles for
! \&\*(L"typical\*(R" \s-1EV4 & EV5\s0 hardware for the Level 1, 2 & 3 caches
  (also called Dcache, Scache, and Bcache), as well as to main memory.
! Note that L3 is only valid for \s-1EV5.\s0
  .RE
  .RS 4
  .RE
  .PP
  \fIeBPF Options\fR
  .IX Subsection "eBPF Options"
! .IP "\fB\-mframe\-limit=\fR\fIbytes\fR" 4
  .IX Item "-mframe-limit=bytes"
  This specifies the hard limit for frame sizes, in bytes.  Currently,
  the value that can be specified should be less than or equal to
  \&\fB32767\fR.  Defaults to whatever limit is imposed by the version of
  the Linux kernel targeted.
! .IP "\fB\-mkernel=\fR\fIversion\fR" 4
  .IX Item "-mkernel=version"
  This specifies the minimum version of the kernel that will run the
! compiled program.  \s-1GCC\s0 uses this version to determine which
  instructions to use, what kernel helpers to allow, etc.  Currently,
  \&\fIversion\fR can be one of \fB4.0\fR, \fB4.1\fR, \fB4.2\fR,
  \&\fB4.3\fR, \fB4.4\fR, \fB4.5\fR, \fB4.6\fR, \fB4.7\fR,
--- 23855,23893 ----
  .Sp
  Valid options for \fItime\fR are
  .RS 4
! .IP \fInumber\fR 4
  .IX Item "number"
  A decimal number representing clock cycles.
! .IP \fBL1\fR 4
  .IX Item "L1"
  .PD 0
! .IP \fBL2\fR 4
  .IX Item "L2"
! .IP \fBL3\fR 4
  .IX Item "L3"
! .IP \fBmain\fR 4
  .IX Item "main"
  .PD
  The compiler contains estimates of the number of clock cycles for
! "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.
  .RE
  .RS 4
  .RE
  .PP
  \fIeBPF Options\fR
  .IX Subsection "eBPF Options"
! .IP \fB\-mframe\-limit=\fR\fIbytes\fR 4
  .IX Item "-mframe-limit=bytes"
  This specifies the hard limit for frame sizes, in bytes.  Currently,
  the value that can be specified should be less than or equal to
  \&\fB32767\fR.  Defaults to whatever limit is imposed by the version of
  the Linux kernel targeted.
! .IP \fB\-mkernel=\fR\fIversion\fR 4
  .IX Item "-mkernel=version"
  This specifies the minimum version of the kernel that will run the
! compiled program.  GCC uses this version to determine which
  instructions to use, what kernel helpers to allow, etc.  Currently,
  \&\fIversion\fR can be one of \fB4.0\fR, \fB4.1\fR, \fB4.2\fR,
  \&\fB4.3\fR, \fB4.4\fR, \fB4.5\fR, \fB4.6\fR, \fB4.7\fR,
*************** instructions to use, what kernel helpers
*** 23964,24287 ****
  \&\fB4.13\fR, \fB4.14\fR, \fB4.15\fR, \fB4.16\fR, \fB4.17\fR,
  \&\fB4.18\fR, \fB4.19\fR, \fB4.20\fR, \fB5.0\fR, \fB5.1\fR,
  \&\fB5.2\fR, \fBlatest\fR and \fBnative\fR.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code for a big-endian target.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code for a little-endian target.  This is the default.
! .IP "\fB\-mjmpext\fR" 4
  .IX Item "-mjmpext"
! Enable generation of extra conditional-branch instructions.
! Enabled for \s-1CPU\s0 v2 and above.
! .IP "\fB\-mjmp32\fR" 4
  .IX Item "-mjmp32"
! Enable 32\-bit jump instructions. Enabled for \s-1CPU\s0 v3 and above.
! .IP "\fB\-malu32\fR" 4
  .IX Item "-malu32"
! Enable 32\-bit \s-1ALU\s0 instructions. Enabled for \s-1CPU\s0 v3 and above.
! .IP "\fB\-mcpu=\fR\fIversion\fR" 4
  .IX Item "-mcpu=version"
! This specifies which version of the eBPF \s-1ISA\s0 to target. Newer versions
  may not be supported by all kernels. The default is \fBv3\fR.
  .Sp
  Supported values for \fIversion\fR are:
  .RS 4
! .IP "\fBv1\fR" 4
  .IX Item "v1"
! The first stable eBPF \s-1ISA\s0 with no special features or extensions.
! .IP "\fBv2\fR" 4
  .IX Item "v2"
  Supports the jump extensions, as in \fB\-mjmpext\fR.
! .IP "\fBv3\fR" 4
  .IX Item "v3"
  All features of v2, plus:
  .RS 4
  .IP "\-<32\-bit jump operations, as in \fB\-mjmp32\fR>" 4
  .IX Item "-<32-bit jump operations, as in -mjmp32>"
  .PD 0
! .IP "\-<32\-bit \s-1ALU\s0 operations, as in \fB\-malu32\fR>" 4
  .IX Item "-<32-bit ALU operations, as in -malu32>"
  .RE
  .RS 4
  .RE
  .RE
  .RS 4
  .RE
! .IP "\fB\-mco\-re\fR" 4
  .IX Item "-mco-re"
! .PD
! Enable \s-1BPF\s0 Compile Once \- Run Everywhere (CO-RE) support. Requires and
  is implied by \fB\-gbtf\fR.
! .IP "\fB\-mno\-co\-re\fR" 4
  .IX Item "-mno-co-re"
! Disable \s-1BPF\s0 Compile Once \- Run Everywhere (CO-RE) support. \s-1BPF\s0 CO-RE
! support is enabled by default when generating \s-1BTF\s0 debug information for
! the \s-1BPF\s0 target.
! .IP "\fB\-mxbpf\fR" 4
  .IX Item "-mxbpf"
! Generate code for an expanded version of \s-1BPF,\s0 which relaxes some of
! the restrictions imposed by the \s-1BPF\s0 architecture:
  .RS 4
! .IP "\-" 4
  .IX Item "-"
  exit, respectively.
  .RE
  .RS 4
  .RE
  .PP
! \fI\s-1FR30\s0 Options\fR
  .IX Subsection "FR30 Options"
  .PP
! These options are defined specifically for the \s-1FR30\s0 port.
! .IP "\fB\-msmall\-model\fR" 4
  .IX Item "-msmall-model"
  Use the small address space model.  This can produce smaller code, but
  it does assume that all symbolic values and addresses fit into a
  20\-bit range.
! .IP "\fB\-mno\-lsim\fR" 4
  .IX Item "-mno-lsim"
  Assume that runtime support has been provided and so there is no need
  to include the simulator library (\fIlibsim.a\fR) on the linker
  command line.
  .PP
! \fI\s-1FT32\s0 Options\fR
  .IX Subsection "FT32 Options"
  .PP
! These options are defined specifically for the \s-1FT32\s0 port.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
  an alternate runtime startup and library to be linked.
  You must not use this option when generating programs that will run on
  real hardware; you must provide your own runtime library for whatever
  I/O functions are needed.
! .IP "\fB\-mlra\fR" 4
  .IX Item "-mlra"
! Enable Local Register Allocation.  This is still experimental for \s-1FT32,\s0
  so by default the compiler uses standard reload.
! .IP "\fB\-mnodiv\fR" 4
  .IX Item "-mnodiv"
  Do not use div and mod instructions.
! .IP "\fB\-mft32b\fR" 4
  .IX Item "-mft32b"
! Enable use of the extended instructions of the \s-1FT32B\s0 processor.
! .IP "\fB\-mcompress\fR" 4
  .IX Item "-mcompress"
  Compress all code using the Ft32B code compression scheme.
! .IP "\fB\-mnopm\fR" 4
  .IX Item "-mnopm"
  Do not generate code that reads program memory.
  .PP
! \fI\s-1FRV\s0 Options\fR
  .IX Subsection "FRV Options"
! .IP "\fB\-mgpr\-32\fR" 4
  .IX Item "-mgpr-32"
! Only use the first 32 general-purpose registers.
! .IP "\fB\-mgpr\-64\fR" 4
  .IX Item "-mgpr-64"
! Use all 64 general-purpose registers.
! .IP "\fB\-mfpr\-32\fR" 4
  .IX Item "-mfpr-32"
! Use only the first 32 floating-point registers.
! .IP "\fB\-mfpr\-64\fR" 4
  .IX Item "-mfpr-64"
! Use all 64 floating-point registers.
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
! Use hardware instructions for floating-point operations.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
! Use library routines for floating-point operations.
! .IP "\fB\-malloc\-cc\fR" 4
  .IX Item "-malloc-cc"
  Dynamically allocate condition code registers.
! .IP "\fB\-mfixed\-cc\fR" 4
  .IX Item "-mfixed-cc"
  Do not try to dynamically allocate condition code registers, only
  use \f(CW\*(C`icc0\*(C'\fR and \f(CW\*(C`fcc0\*(C'\fR.
! .IP "\fB\-mdword\fR" 4
  .IX Item "-mdword"
! Change \s-1ABI\s0 to use double word insns.
! .IP "\fB\-mno\-dword\fR" 4
  .IX Item "-mno-dword"
  Do not use double word instructions.
! .IP "\fB\-mdouble\fR" 4
  .IX Item "-mdouble"
! Use floating-point double instructions.
! .IP "\fB\-mno\-double\fR" 4
  .IX Item "-mno-double"
! Do not use floating-point double instructions.
! .IP "\fB\-mmedia\fR" 4
  .IX Item "-mmedia"
  Use media instructions.
! .IP "\fB\-mno\-media\fR" 4
  .IX Item "-mno-media"
  Do not use media instructions.
! .IP "\fB\-mmuladd\fR" 4
  .IX Item "-mmuladd"
  Use multiply and add/subtract instructions.
! .IP "\fB\-mno\-muladd\fR" 4
  .IX Item "-mno-muladd"
  Do not use multiply and add/subtract instructions.
! .IP "\fB\-mfdpic\fR" 4
  .IX Item "-mfdpic"
! Select the \s-1FDPIC ABI,\s0 which uses function descriptors to represent
  pointers to functions.  Without any PIC/PIE\-related options, it
  implies \fB\-fPIE\fR.  With \fB\-fpic\fR or \fB\-fpie\fR, it
! assumes \s-1GOT\s0 entries and small data are within a 12\-bit range from the
! \&\s-1GOT\s0 base address; with \fB\-fPIC\fR or \fB\-fPIE\fR, \s-1GOT\s0 offsets
  are computed with 32 bits.
! With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
! .IP "\fB\-minline\-plt\fR" 4
  .IX Item "-minline-plt"
! Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
  not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
! It's enabled by default if optimizing for speed and compiling for
  shared libraries (i.e., \fB\-fPIC\fR or \fB\-fpic\fR), or when an
  optimization option such as \fB\-O3\fR or above is present in the
  command line.
! .IP "\fB\-mTLS\fR" 4
  .IX Item "-mTLS"
! Assume a large \s-1TLS\s0 segment when generating thread-local code.
! .IP "\fB\-mtls\fR" 4
  .IX Item "-mtls"
! Do not assume a large \s-1TLS\s0 segment when generating thread-local code.
! .IP "\fB\-mgprel\-ro\fR" 4
  .IX Item "-mgprel-ro"
! Enable the use of \f(CW\*(C`GPREL\*(C'\fR relocations in the \s-1FDPIC ABI\s0 for data
! that is known to be in read-only sections.  It's enabled by default,
  except for \fB\-fpic\fR or \fB\-fpie\fR: even though it may help
  make the global offset table smaller, it trades 1 instruction for 4.
  With \fB\-fPIC\fR or \fB\-fPIE\fR, it trades 3 instructions for 4,
  one of which may be shared by multiple symbols, and it avoids the need
! for a \s-1GOT\s0 entry for the referenced symbol, so it's more likely to be a
  win.  If it is not, \fB\-mno\-gprel\-ro\fR can be used to disable it.
! .IP "\fB\-multilib\-library\-pic\fR" 4
  .IX Item "-multilib-library-pic"
! Link with the (library, not \s-1FD\s0) pic libraries.  It's implied by
  \&\fB\-mlibrary\-pic\fR, as well as by \fB\-fPIC\fR and
  \&\fB\-fpic\fR without \fB\-mfdpic\fR.  You should never have to use
  it explicitly.
! .IP "\fB\-mlinked\-fp\fR" 4
  .IX Item "-mlinked-fp"
! Follow the \s-1EABI\s0 requirement of always creating a frame pointer whenever
  a stack frame is allocated.  This option is enabled by default and can
  be disabled with \fB\-mno\-linked\-fp\fR.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  Use indirect addressing to call functions outside the current
  compilation unit.  This allows the functions to be placed anywhere
  within the 32\-bit address space.
! .IP "\fB\-malign\-labels\fR" 4
  .IX Item "-malign-labels"
  Try to align labels to an 8\-byte boundary by inserting NOPs into the
! previous packet.  This option only has an effect when \s-1VLIW\s0 packing
! is enabled.  It doesn't create new packets; it merely adds NOPs to
  existing ones.
! .IP "\fB\-mlibrary\-pic\fR" 4
  .IX Item "-mlibrary-pic"
! Generate position-independent \s-1EABI\s0 code.
! .IP "\fB\-macc\-4\fR" 4
  .IX Item "-macc-4"
  Use only the first four media accumulator registers.
! .IP "\fB\-macc\-8\fR" 4
  .IX Item "-macc-8"
  Use all eight media accumulator registers.
! .IP "\fB\-mpack\fR" 4
  .IX Item "-mpack"
! Pack \s-1VLIW\s0 instructions.
! .IP "\fB\-mno\-pack\fR" 4
  .IX Item "-mno-pack"
! Do not pack \s-1VLIW\s0 instructions.
! .IP "\fB\-mno\-eflags\fR" 4
  .IX Item "-mno-eflags"
! Do not mark \s-1ABI\s0 switches in e_flags.
! .IP "\fB\-mcond\-move\fR" 4
  .IX Item "-mcond-move"
! Enable the use of conditional-move instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-cond\-move\fR" 4
  .IX Item "-mno-cond-move"
! Disable the use of conditional-move instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mscc\fR" 4
  .IX Item "-mscc"
  Enable the use of conditional set instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-scc\fR" 4
  .IX Item "-mno-scc"
  Disable the use of conditional set instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mcond\-exec\fR" 4
  .IX Item "-mcond-exec"
  Enable the use of conditional execution (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-cond\-exec\fR" 4
  .IX Item "-mno-cond-exec"
  Disable the use of conditional execution.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mvliw\-branch\fR" 4
  .IX Item "-mvliw-branch"
! Run a pass to pack branches into \s-1VLIW\s0 instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-vliw\-branch\fR" 4
  .IX Item "-mno-vliw-branch"
! Do not run a pass to pack branches into \s-1VLIW\s0 instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mmulti\-cond\-exec\fR" 4
  .IX Item "-mmulti-cond-exec"
  Enable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution
  (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-multi\-cond\-exec\fR" 4
  .IX Item "-mno-multi-cond-exec"
  Disable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mnested\-cond\-exec\fR" 4
  .IX Item "-mnested-cond-exec"
  Enable nested conditional execution optimizations (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-nested\-cond\-exec\fR" 4
  .IX Item "-mno-nested-cond-exec"
  Disable nested conditional execution optimizations.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-moptimize\-membar\fR" 4
  .IX Item "-moptimize-membar"
  This switch removes redundant \f(CW\*(C`membar\*(C'\fR instructions from the
! compiler-generated code.  It is enabled by default.
! .IP "\fB\-mno\-optimize\-membar\fR" 4
  .IX Item "-mno-optimize-membar"
  This switch disables the automatic removal of redundant \f(CW\*(C`membar\*(C'\fR
  instructions from the generated code.
! .IP "\fB\-mtomcat\-stats\fR" 4
  .IX Item "-mtomcat-stats"
  Cause gas to print out tomcat statistics.
! .IP "\fB\-mcpu=\fR\fIcpu\fR" 4
  .IX Item "-mcpu=cpu"
  Select the processor type for which to generate code.  Possible values are
  \&\fBfrv\fR, \fBfr550\fR, \fBtomcat\fR, \fBfr500\fR, \fBfr450\fR,
--- 23895,24218 ----
  \&\fB4.13\fR, \fB4.14\fR, \fB4.15\fR, \fB4.16\fR, \fB4.17\fR,
  \&\fB4.18\fR, \fB4.19\fR, \fB4.20\fR, \fB5.0\fR, \fB5.1\fR,
  \&\fB5.2\fR, \fBlatest\fR and \fBnative\fR.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code for a big\-endian target.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code for a little\-endian target.  This is the default.
! .IP \fB\-mjmpext\fR 4
  .IX Item "-mjmpext"
! Enable generation of extra conditional\-branch instructions.
! Enabled for CPU v2 and above.
! .IP \fB\-mjmp32\fR 4
  .IX Item "-mjmp32"
! Enable 32\-bit jump instructions. Enabled for CPU v3 and above.
! .IP \fB\-malu32\fR 4
  .IX Item "-malu32"
! Enable 32\-bit ALU instructions. Enabled for CPU v3 and above.
! .IP \fB\-mcpu=\fR\fIversion\fR 4
  .IX Item "-mcpu=version"
! This specifies which version of the eBPF ISA to target. Newer versions
  may not be supported by all kernels. The default is \fBv3\fR.
  .Sp
  Supported values for \fIversion\fR are:
  .RS 4
! .IP \fBv1\fR 4
  .IX Item "v1"
! The first stable eBPF ISA with no special features or extensions.
! .IP \fBv2\fR 4
  .IX Item "v2"
  Supports the jump extensions, as in \fB\-mjmpext\fR.
! .IP \fBv3\fR 4
  .IX Item "v3"
  All features of v2, plus:
  .RS 4
  .IP "\-<32\-bit jump operations, as in \fB\-mjmp32\fR>" 4
  .IX Item "-<32-bit jump operations, as in -mjmp32>"
  .PD 0
! .IP "\-<32\-bit ALU operations, as in \fB\-malu32\fR>" 4
  .IX Item "-<32-bit ALU operations, as in -malu32>"
+ .PD
  .RE
  .RS 4
  .RE
  .RE
  .RS 4
  .RE
! .IP \fB\-mco\-re\fR 4
  .IX Item "-mco-re"
! Enable BPF Compile Once \- Run Everywhere (CO\-RE) support. Requires and
  is implied by \fB\-gbtf\fR.
! .IP \fB\-mno\-co\-re\fR 4
  .IX Item "-mno-co-re"
! Disable BPF Compile Once \- Run Everywhere (CO\-RE) support. BPF CO\-RE
! support is enabled by default when generating BTF debug information for
! the BPF target.
! .IP \fB\-mxbpf\fR 4
  .IX Item "-mxbpf"
! Generate code for an expanded version of BPF, which relaxes some of
! the restrictions imposed by the BPF architecture:
  .RS 4
! .IP "\-" 4
  .IX Item "-"
  exit, respectively.
  .RE
  .RS 4
  .RE
  .PP
! \fIFR30 Options\fR
  .IX Subsection "FR30 Options"
  .PP
! These options are defined specifically for the FR30 port.
! .IP \fB\-msmall\-model\fR 4
  .IX Item "-msmall-model"
  Use the small address space model.  This can produce smaller code, but
  it does assume that all symbolic values and addresses fit into a
  20\-bit range.
! .IP \fB\-mno\-lsim\fR 4
  .IX Item "-mno-lsim"
  Assume that runtime support has been provided and so there is no need
  to include the simulator library (\fIlibsim.a\fR) on the linker
  command line.
  .PP
! \fIFT32 Options\fR
  .IX Subsection "FT32 Options"
  .PP
! These options are defined specifically for the FT32 port.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
  an alternate runtime startup and library to be linked.
  You must not use this option when generating programs that will run on
  real hardware; you must provide your own runtime library for whatever
  I/O functions are needed.
! .IP \fB\-mlra\fR 4
  .IX Item "-mlra"
! Enable Local Register Allocation.  This is still experimental for FT32,
  so by default the compiler uses standard reload.
! .IP \fB\-mnodiv\fR 4
  .IX Item "-mnodiv"
  Do not use div and mod instructions.
! .IP \fB\-mft32b\fR 4
  .IX Item "-mft32b"
! Enable use of the extended instructions of the FT32B processor.
! .IP \fB\-mcompress\fR 4
  .IX Item "-mcompress"
  Compress all code using the Ft32B code compression scheme.
! .IP \fB\-mnopm\fR 4
  .IX Item "-mnopm"
  Do not generate code that reads program memory.
  .PP
! \fIFRV Options\fR
  .IX Subsection "FRV Options"
! .IP \fB\-mgpr\-32\fR 4
  .IX Item "-mgpr-32"
! Only use the first 32 general\-purpose registers.
! .IP \fB\-mgpr\-64\fR 4
  .IX Item "-mgpr-64"
! Use all 64 general\-purpose registers.
! .IP \fB\-mfpr\-32\fR 4
  .IX Item "-mfpr-32"
! Use only the first 32 floating\-point registers.
! .IP \fB\-mfpr\-64\fR 4
  .IX Item "-mfpr-64"
! Use all 64 floating\-point registers.
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
! Use hardware instructions for floating\-point operations.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
! Use library routines for floating\-point operations.
! .IP \fB\-malloc\-cc\fR 4
  .IX Item "-malloc-cc"
  Dynamically allocate condition code registers.
! .IP \fB\-mfixed\-cc\fR 4
  .IX Item "-mfixed-cc"
  Do not try to dynamically allocate condition code registers, only
  use \f(CW\*(C`icc0\*(C'\fR and \f(CW\*(C`fcc0\*(C'\fR.
! .IP \fB\-mdword\fR 4
  .IX Item "-mdword"
! Change ABI to use double word insns.
! .IP \fB\-mno\-dword\fR 4
  .IX Item "-mno-dword"
  Do not use double word instructions.
! .IP \fB\-mdouble\fR 4
  .IX Item "-mdouble"
! Use floating\-point double instructions.
! .IP \fB\-mno\-double\fR 4
  .IX Item "-mno-double"
! Do not use floating\-point double instructions.
! .IP \fB\-mmedia\fR 4
  .IX Item "-mmedia"
  Use media instructions.
! .IP \fB\-mno\-media\fR 4
  .IX Item "-mno-media"
  Do not use media instructions.
! .IP \fB\-mmuladd\fR 4
  .IX Item "-mmuladd"
  Use multiply and add/subtract instructions.
! .IP \fB\-mno\-muladd\fR 4
  .IX Item "-mno-muladd"
  Do not use multiply and add/subtract instructions.
! .IP \fB\-mfdpic\fR 4
  .IX Item "-mfdpic"
! Select the FDPIC ABI, which uses function descriptors to represent
  pointers to functions.  Without any PIC/PIE\-related options, it
  implies \fB\-fPIE\fR.  With \fB\-fpic\fR or \fB\-fpie\fR, it
! assumes GOT entries and small data are within a 12\-bit range from the
! GOT base address; with \fB\-fPIC\fR or \fB\-fPIE\fR, GOT offsets
  are computed with 32 bits.
! With a \fBbfin\-elf\fR target, this option implies \fB\-msim\fR.
! .IP \fB\-minline\-plt\fR 4
  .IX Item "-minline-plt"
! Enable inlining of PLT entries in function calls to functions that are
  not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
! It\*(Aqs enabled by default if optimizing for speed and compiling for
  shared libraries (i.e., \fB\-fPIC\fR or \fB\-fpic\fR), or when an
  optimization option such as \fB\-O3\fR or above is present in the
  command line.
! .IP \fB\-mTLS\fR 4
  .IX Item "-mTLS"
! Assume a large TLS segment when generating thread\-local code.
! .IP \fB\-mtls\fR 4
  .IX Item "-mtls"
! Do not assume a large TLS segment when generating thread\-local code.
! .IP \fB\-mgprel\-ro\fR 4
  .IX Item "-mgprel-ro"
! Enable the use of \f(CW\*(C`GPREL\*(C'\fR relocations in the FDPIC ABI for data
! that is known to be in read\-only sections.  It\*(Aqs enabled by default,
  except for \fB\-fpic\fR or \fB\-fpie\fR: even though it may help
  make the global offset table smaller, it trades 1 instruction for 4.
  With \fB\-fPIC\fR or \fB\-fPIE\fR, it trades 3 instructions for 4,
  one of which may be shared by multiple symbols, and it avoids the need
! for a GOT entry for the referenced symbol, so it\*(Aqs more likely to be a
  win.  If it is not, \fB\-mno\-gprel\-ro\fR can be used to disable it.
! .IP \fB\-multilib\-library\-pic\fR 4
  .IX Item "-multilib-library-pic"
! Link with the (library, not FD) pic libraries.  It\*(Aqs implied by
  \&\fB\-mlibrary\-pic\fR, as well as by \fB\-fPIC\fR and
  \&\fB\-fpic\fR without \fB\-mfdpic\fR.  You should never have to use
  it explicitly.
! .IP \fB\-mlinked\-fp\fR 4
  .IX Item "-mlinked-fp"
! Follow the 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 \fB\-mno\-linked\-fp\fR.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  Use indirect addressing to call functions outside the current
  compilation unit.  This allows the functions to be placed anywhere
  within the 32\-bit address space.
! .IP \fB\-malign\-labels\fR 4
  .IX Item "-malign-labels"
  Try to align labels to an 8\-byte boundary by inserting NOPs into the
! previous packet.  This option only has an effect when VLIW packing
! is enabled.  It doesn\*(Aqt create new packets; it merely adds NOPs to
  existing ones.
! .IP \fB\-mlibrary\-pic\fR 4
  .IX Item "-mlibrary-pic"
! Generate position\-independent EABI code.
! .IP \fB\-macc\-4\fR 4
  .IX Item "-macc-4"
  Use only the first four media accumulator registers.
! .IP \fB\-macc\-8\fR 4
  .IX Item "-macc-8"
  Use all eight media accumulator registers.
! .IP \fB\-mpack\fR 4
  .IX Item "-mpack"
! Pack VLIW instructions.
! .IP \fB\-mno\-pack\fR 4
  .IX Item "-mno-pack"
! Do not pack VLIW instructions.
! .IP \fB\-mno\-eflags\fR 4
  .IX Item "-mno-eflags"
! Do not mark ABI switches in e_flags.
! .IP \fB\-mcond\-move\fR 4
  .IX Item "-mcond-move"
! Enable the use of conditional\-move instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-cond\-move\fR 4
  .IX Item "-mno-cond-move"
! Disable the use of conditional\-move instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mscc\fR 4
  .IX Item "-mscc"
  Enable the use of conditional set instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-scc\fR 4
  .IX Item "-mno-scc"
  Disable the use of conditional set instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mcond\-exec\fR 4
  .IX Item "-mcond-exec"
  Enable the use of conditional execution (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-cond\-exec\fR 4
  .IX Item "-mno-cond-exec"
  Disable the use of conditional execution.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mvliw\-branch\fR 4
  .IX Item "-mvliw-branch"
! Run a pass to pack branches into VLIW instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-vliw\-branch\fR 4
  .IX Item "-mno-vliw-branch"
! Do not run a pass to pack branches into VLIW instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mmulti\-cond\-exec\fR 4
  .IX Item "-mmulti-cond-exec"
  Enable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution
  (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-multi\-cond\-exec\fR 4
  .IX Item "-mno-multi-cond-exec"
  Disable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mnested\-cond\-exec\fR 4
  .IX Item "-mnested-cond-exec"
  Enable nested conditional execution optimizations (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-nested\-cond\-exec\fR 4
  .IX Item "-mno-nested-cond-exec"
  Disable nested conditional execution optimizations.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-moptimize\-membar\fR 4
  .IX Item "-moptimize-membar"
  This switch removes redundant \f(CW\*(C`membar\*(C'\fR instructions from the
! compiler\-generated code.  It is enabled by default.
! .IP \fB\-mno\-optimize\-membar\fR 4
  .IX Item "-mno-optimize-membar"
  This switch disables the automatic removal of redundant \f(CW\*(C`membar\*(C'\fR
  instructions from the generated code.
! .IP \fB\-mtomcat\-stats\fR 4
  .IX Item "-mtomcat-stats"
  Cause gas to print out tomcat statistics.
! .IP \fB\-mcpu=\fR\fIcpu\fR 4
  .IX Item "-mcpu=cpu"
  Select the processor type for which to generate code.  Possible values are
  \&\fBfrv\fR, \fBfr550\fR, \fBtomcat\fR, \fBfr500\fR, \fBfr450\fR,
*************** Select the processor type for which to g
*** 24291,24329 ****
  .IX Subsection "GNU/Linux Options"
  .PP
  These \fB\-m\fR options are defined for GNU/Linux targets:
! .IP "\fB\-mglibc\fR" 4
  .IX Item "-mglibc"
! Use the \s-1GNU C\s0 library.  This is the default except
  on \fB*\-*\-linux\-*uclibc*\fR, \fB*\-*\-linux\-*musl*\fR and
  \&\fB*\-*\-linux\-*android*\fR targets.
! .IP "\fB\-muclibc\fR" 4
  .IX Item "-muclibc"
  Use uClibc C library.  This is the default on
  \&\fB*\-*\-linux\-*uclibc*\fR targets.
! .IP "\fB\-mmusl\fR" 4
  .IX Item "-mmusl"
  Use the musl C library.  This is the default on
  \&\fB*\-*\-linux\-*musl*\fR targets.
! .IP "\fB\-mbionic\fR" 4
  .IX Item "-mbionic"
  Use Bionic C library.  This is the default on
  \&\fB*\-*\-linux\-*android*\fR targets.
! .IP "\fB\-mandroid\fR" 4
  .IX Item "-mandroid"
  Compile code compatible with Android platform.  This is the default on
  \&\fB*\-*\-linux\-*android*\fR targets.
  .Sp
  When compiling, this option enables \fB\-mbionic\fR, \fB\-fPIC\fR,
  \&\fB\-fno\-exceptions\fR and \fB\-fno\-rtti\fR by default.  When linking,
! this option makes the \s-1GCC\s0 driver pass Android-specific options to the linker.
  Finally, this option causes the preprocessor macro \f(CW\*(C`_\|_ANDROID_\|_\*(C'\fR
  to be defined.
! .IP "\fB\-tno\-android\-cc\fR" 4
  .IX Item "-tno-android-cc"
  Disable compilation effects of \fB\-mandroid\fR, i.e., do not enable
  \&\fB\-mbionic\fR, \fB\-fPIC\fR, \fB\-fno\-exceptions\fR and
  \&\fB\-fno\-rtti\fR by default.
! .IP "\fB\-tno\-android\-ld\fR" 4
  .IX Item "-tno-android-ld"
  Disable linking effects of \fB\-mandroid\fR, i.e., pass standard Linux
  linking options to the linker.
--- 24222,24260 ----
  .IX Subsection "GNU/Linux Options"
  .PP
  These \fB\-m\fR options are defined for GNU/Linux targets:
! .IP \fB\-mglibc\fR 4
  .IX Item "-mglibc"
! Use the GNU C library.  This is the default except
  on \fB*\-*\-linux\-*uclibc*\fR, \fB*\-*\-linux\-*musl*\fR and
  \&\fB*\-*\-linux\-*android*\fR targets.
! .IP \fB\-muclibc\fR 4
  .IX Item "-muclibc"
  Use uClibc C library.  This is the default on
  \&\fB*\-*\-linux\-*uclibc*\fR targets.
! .IP \fB\-mmusl\fR 4
  .IX Item "-mmusl"
  Use the musl C library.  This is the default on
  \&\fB*\-*\-linux\-*musl*\fR targets.
! .IP \fB\-mbionic\fR 4
  .IX Item "-mbionic"
  Use Bionic C library.  This is the default on
  \&\fB*\-*\-linux\-*android*\fR targets.
! .IP \fB\-mandroid\fR 4
  .IX Item "-mandroid"
  Compile code compatible with Android platform.  This is the default on
  \&\fB*\-*\-linux\-*android*\fR targets.
  .Sp
  When compiling, this option enables \fB\-mbionic\fR, \fB\-fPIC\fR,
  \&\fB\-fno\-exceptions\fR and \fB\-fno\-rtti\fR by default.  When linking,
! this option makes the GCC driver pass Android\-specific options to the linker.
  Finally, this option causes the preprocessor macro \f(CW\*(C`_\|_ANDROID_\|_\*(C'\fR
  to be defined.
! .IP \fB\-tno\-android\-cc\fR 4
  .IX Item "-tno-android-cc"
  Disable compilation effects of \fB\-mandroid\fR, i.e., do not enable
  \&\fB\-mbionic\fR, \fB\-fPIC\fR, \fB\-fno\-exceptions\fR and
  \&\fB\-fno\-rtti\fR by default.
! .IP \fB\-tno\-android\-ld\fR 4
  .IX Item "-tno-android-ld"
  Disable linking effects of \fB\-mandroid\fR, i.e., pass standard Linux
  linking options to the linker.
*************** linking options to the linker.
*** 24332,24368 ****
  .IX Subsection "H8/300 Options"
  .PP
  These \fB\-m\fR options are defined for the H8/300 implementations:
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Shorten some address references at link time, when possible; uses the
  linker option \fB\-relax\fR.
! .IP "\fB\-mh\fR" 4
  .IX Item "-mh"
  Generate code for the H8/300H.
! .IP "\fB\-ms\fR" 4
  .IX Item "-ms"
  Generate code for the H8S.
! .IP "\fB\-mn\fR" 4
  .IX Item "-mn"
  Generate code for the H8S and H8/300H in the normal mode.  This switch
  must be used either with \fB\-mh\fR or \fB\-ms\fR.
! .IP "\fB\-ms2600\fR" 4
  .IX Item "-ms2600"
  Generate code for the H8S/2600.  This switch must be used with \fB\-ms\fR.
! .IP "\fB\-mexr\fR" 4
  .IX Item "-mexr"
  Extended registers are stored on stack before execution of function
  with monitor attribute. Default option is \fB\-mexr\fR.
  This option is valid only for H8S targets.
! .IP "\fB\-mno\-exr\fR" 4
  .IX Item "-mno-exr"
  Extended registers are not stored on stack before execution of function 
  with monitor attribute. Default option is \fB\-mno\-exr\fR. 
  This option is valid only for H8S targets.
! .IP "\fB\-mint32\fR" 4
  .IX Item "-mint32"
  Make \f(CW\*(C`int\*(C'\fR data 32 bits by default.
! .IP "\fB\-malign\-300\fR" 4
  .IX Item "-malign-300"
  On the H8/300H and H8S, use the same alignment rules as for the H8/300.
  The default for the H8/300H and H8S is to align longs and floats on
--- 24263,24299 ----
  .IX Subsection "H8/300 Options"
  .PP
  These \fB\-m\fR options are defined for the H8/300 implementations:
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Shorten some address references at link time, when possible; uses the
  linker option \fB\-relax\fR.
! .IP \fB\-mh\fR 4
  .IX Item "-mh"
  Generate code for the H8/300H.
! .IP \fB\-ms\fR 4
  .IX Item "-ms"
  Generate code for the H8S.
! .IP \fB\-mn\fR 4
  .IX Item "-mn"
  Generate code for the H8S and H8/300H in the normal mode.  This switch
  must be used either with \fB\-mh\fR or \fB\-ms\fR.
! .IP \fB\-ms2600\fR 4
  .IX Item "-ms2600"
  Generate code for the H8S/2600.  This switch must be used with \fB\-ms\fR.
! .IP \fB\-mexr\fR 4
  .IX Item "-mexr"
  Extended registers are stored on stack before execution of function
  with monitor attribute. Default option is \fB\-mexr\fR.
  This option is valid only for H8S targets.
! .IP \fB\-mno\-exr\fR 4
  .IX Item "-mno-exr"
  Extended registers are not stored on stack before execution of function 
  with monitor attribute. Default option is \fB\-mno\-exr\fR. 
  This option is valid only for H8S targets.
! .IP \fB\-mint32\fR 4
  .IX Item "-mint32"
  Make \f(CW\*(C`int\*(C'\fR data 32 bits by default.
! .IP \fB\-malign\-300\fR 4
  .IX Item "-malign-300"
  On the H8/300H and H8S, use the same alignment rules as for the H8/300.
  The default for the H8/300H and H8S is to align longs and floats on
*************** The default for the H8/300H and H8S is t
*** 24370,24402 ****
  \&\fB\-malign\-300\fR causes them to be aligned on 2\-byte boundaries.
  This option has no effect on the H8/300.
  .PP
! \fI\s-1HPPA\s0 Options\fR
  .IX Subsection "HPPA Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1HPPA\s0 family of computers:
! .IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
  .IX Item "-march=architecture-type"
  Generate code for the specified architecture.  The choices for
! \&\fIarchitecture-type\fR are \fB1.0\fR for \s-1PA 1.0,\s0 \fB1.1\fR for \s-1PA
! 1.1,\s0 and \fB2.0\fR for \s-1PA 2.0\s0 processors.  Refer to
! \&\fI/usr/lib/sched.models\fR on an HP-UX system to determine the proper
  architecture option for your machine.  Code compiled for lower numbered
  architectures runs on higher numbered architectures, but not the
  other way around.
! .IP "\fB\-mpa\-risc\-1\-0\fR" 4
  .IX Item "-mpa-risc-1-0"
  .PD 0
! .IP "\fB\-mpa\-risc\-1\-1\fR" 4
  .IX Item "-mpa-risc-1-1"
! .IP "\fB\-mpa\-risc\-2\-0\fR" 4
  .IX Item "-mpa-risc-2-0"
  .PD
  Synonyms for \fB\-march=1.0\fR, \fB\-march=1.1\fR, and \fB\-march=2.0\fR respectively.
! .IP "\fB\-matomic\-libcalls\fR" 4
  .IX Item "-matomic-libcalls"
  Generate libcalls for atomic loads and stores when sync libcalls are disabled.
  This option is enabled by default.  It only affects the generation of
! atomic libcalls by the \s-1HPPA\s0 backend.
  .Sp
  Both the sync and \fIlibatomic\fR libcall implementations use locking.
  As a result, processor stores are not atomic with respect to other
--- 24301,24333 ----
  \&\fB\-malign\-300\fR causes them to be aligned on 2\-byte boundaries.
  This option has no effect on the H8/300.
  .PP
! \fIHPPA Options\fR
  .IX Subsection "HPPA Options"
  .PP
! These \fB\-m\fR options are defined for the HPPA family of computers:
! .IP \fB\-march=\fR\fIarchitecture\-type\fR 4
  .IX Item "-march=architecture-type"
  Generate code for the specified architecture.  The choices for
! \&\fIarchitecture\-type\fR are \fB1.0\fR for PA 1.0, \fB1.1\fR for PA
! 1.1, and \fB2.0\fR for PA 2.0 processors.  Refer to
! \&\fI/usr/lib/sched.models\fR on an HP\-UX system to determine the proper
  architecture option for your machine.  Code compiled for lower numbered
  architectures runs on higher numbered architectures, but not the
  other way around.
! .IP \fB\-mpa\-risc\-1\-0\fR 4
  .IX Item "-mpa-risc-1-0"
  .PD 0
! .IP \fB\-mpa\-risc\-1\-1\fR 4
  .IX Item "-mpa-risc-1-1"
! .IP \fB\-mpa\-risc\-2\-0\fR 4
  .IX Item "-mpa-risc-2-0"
  .PD
  Synonyms for \fB\-march=1.0\fR, \fB\-march=1.1\fR, and \fB\-march=2.0\fR respectively.
! .IP \fB\-matomic\-libcalls\fR 4
  .IX Item "-matomic-libcalls"
  Generate libcalls for atomic loads and stores when sync libcalls are disabled.
  This option is enabled by default.  It only affects the generation of
! atomic libcalls by the HPPA backend.
  .Sp
  Both the sync and \fIlibatomic\fR libcall implementations use locking.
  As a result, processor stores are not atomic with respect to other
*************** atomic operations.  Processor loads up t
*** 24404,24410 ****
  respect to other atomic operations provided they are implemented as
  a single access.
  .Sp
! The PA-RISC architecture does not support any atomic operations in
  hardware except for the \f(CW\*(C`ldcw\*(C'\fR instruction.  Thus, all atomic
  support is implemented using sync and atomic libcalls.  Sync libcall
  support is in \fIlibgcc.a\fR.  Atomic libcall support is in
--- 24335,24341 ----
  respect to other atomic operations provided they are implemented as
  a single access.
  .Sp
! The PA\-RISC architecture does not support any atomic operations in
  hardware except for the \f(CW\*(C`ldcw\*(C'\fR instruction.  Thus, all atomic
  support is implemented using sync and atomic libcalls.  Sync libcall
  support is in \fIlibgcc.a\fR.  Atomic libcall support is in
*************** support is in \fIlibgcc.a\fR.  Atomic li
*** 24413,24488 ****
  This option generates \f(CW\*(C`_\|_atomic_exchange\*(C'\fR calls for atomic stores.
  It also provides special handling for atomic DImode accesses on 32\-bit
  targets.
! .IP "\fB\-mbig\-switch\fR" 4
  .IX Item "-mbig-switch"
  Does nothing.  Preserved for backward compatibility.
! .IP "\fB\-mcaller\-copies\fR" 4
  .IX Item "-mcaller-copies"
  The caller copies function arguments passed by hidden reference.  This
  option should be used with care as it is not compatible with the default
  32\-bit runtime.  However, only aggregates larger than eight bytes are
  passed by hidden reference and the option provides better compatibility
  with OpenMP.
! .IP "\fB\-mcoherent\-ldcw\fR" 4
  .IX Item "-mcoherent-ldcw"
! Use ldcw/ldcd coherent cache-control hint.
! .IP "\fB\-mdisable\-fpregs\fR" 4
  .IX Item "-mdisable-fpregs"
! Disable floating-point registers.  Equivalent to \f(CW\*(C`\-msoft\-float\*(C'\fR.
! .IP "\fB\-mdisable\-indexing\fR" 4
  .IX Item "-mdisable-indexing"
  Prevent the compiler from using indexing address modes.  This avoids some
! rather obscure problems when compiling \s-1MIG\s0 generated code under \s-1MACH.\s0
! .IP "\fB\-mfast\-indirect\-calls\fR" 4
  .IX Item "-mfast-indirect-calls"
  Generate code that assumes calls never cross space boundaries.  This
! allows \s-1GCC\s0 to emit code that performs faster indirect calls.
  .Sp
  This option does not work in the presence of shared libraries or nested
  functions.
! .IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP "\fB\-mgas\fR" 4
  .IX Item "-mgas"
! Enable the use of assembler directives only \s-1GAS\s0 understands.
! .IP "\fB\-mgnu\-ld\fR" 4
  .IX Item "-mgnu-ld"
! Use options specific to \s-1GNU\s0 \fBld\fR.
  This passes \fB\-shared\fR to \fBld\fR when
! building a shared library.  It is the default when \s-1GCC\s0 is configured,
! explicitly or implicitly, with the \s-1GNU\s0 linker.  This option does not
  affect which \fBld\fR is called; it only changes what parameters
  are passed to that \fBld\fR.
  The \fBld\fR that is called is determined by the
! \&\fB\-\-with\-ld\fR configure option, \s-1GCC\s0's program search path, and
! finally by the user's \fB\s-1PATH\s0\fR.  The linker used by \s-1GCC\s0 can be printed
! using \fBwhich `gcc \-print\-prog\-name=ld`\fR.  This option is only available
! on the 64\-bit HP-UX \s-1GCC,\s0 i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
! .IP "\fB\-mhp\-ld\fR" 4
  .IX Item "-mhp-ld"
! Use options specific to \s-1HP\s0 \fBld\fR.
  This passes \fB\-b\fR to \fBld\fR when building
  a shared library and passes \fB+Accept TypeMismatch\fR to \fBld\fR on all
! links.  It is the default when \s-1GCC\s0 is configured, explicitly or
! implicitly, with the \s-1HP\s0 linker.  This option does not affect
  which \fBld\fR is called; it only changes what parameters are passed to that
  \&\fBld\fR.
  The \fBld\fR that is called is determined by the \fB\-\-with\-ld\fR
! configure option, \s-1GCC\s0's program search path, and finally by the user's
! \&\fB\s-1PATH\s0\fR.  The linker used by \s-1GCC\s0 can be printed using \fBwhich
! `gcc \-print\-prog\-name=ld`\fR.  This option is only available on the 64\-bit
! HP-UX \s-1GCC,\s0 i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
! .IP "\fB\-mlinker\-opt\fR" 4
  .IX Item "-mlinker-opt"
! Enable the optimization pass in the HP-UX linker.  Note this makes symbolic
! debugging impossible.  It also triggers a bug in the HP-UX 8 and HP-UX 9
  linkers in which they give bogus error messages when linking some programs.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  Generate code that uses long call sequences.  This ensures that a call
  is always able to reach linker generated stubs.  The default is to generate
--- 24344,24419 ----
  This option generates \f(CW\*(C`_\|_atomic_exchange\*(C'\fR calls for atomic stores.
  It also provides special handling for atomic DImode accesses on 32\-bit
  targets.
! .IP \fB\-mbig\-switch\fR 4
  .IX Item "-mbig-switch"
  Does nothing.  Preserved for backward compatibility.
! .IP \fB\-mcaller\-copies\fR 4
  .IX Item "-mcaller-copies"
  The caller copies function arguments passed by hidden reference.  This
  option should be used with care as it is not compatible with the default
  32\-bit runtime.  However, only aggregates larger than eight bytes are
  passed by hidden reference and the option provides better compatibility
  with OpenMP.
! .IP \fB\-mcoherent\-ldcw\fR 4
  .IX Item "-mcoherent-ldcw"
! Use ldcw/ldcd coherent cache\-control hint.
! .IP \fB\-mdisable\-fpregs\fR 4
  .IX Item "-mdisable-fpregs"
! Disable floating\-point registers.  Equivalent to \f(CW\*(C`\-msoft\-float\*(C'\fR.
! .IP \fB\-mdisable\-indexing\fR 4
  .IX Item "-mdisable-indexing"
  Prevent the compiler from using indexing address modes.  This avoids some
! rather obscure problems when compiling MIG generated code under MACH.
! .IP \fB\-mfast\-indirect\-calls\fR 4
  .IX Item "-mfast-indirect-calls"
  Generate code that assumes calls never cross space boundaries.  This
! allows GCC to emit code that performs faster indirect calls.
  .Sp
  This option does not work in the presence of shared libraries or nested
  functions.
! .IP \fB\-mfixed\-range=\fR\fIregister\-range\fR 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP \fB\-mgas\fR 4
  .IX Item "-mgas"
! Enable the use of assembler directives only GAS understands.
! .IP \fB\-mgnu\-ld\fR 4
  .IX Item "-mgnu-ld"
! Use options specific to GNU \fBld\fR.
  This passes \fB\-shared\fR to \fBld\fR when
! building a shared library.  It is the default when GCC is configured,
! explicitly or implicitly, with the GNU linker.  This option does not
  affect which \fBld\fR is called; it only changes what parameters
  are passed to that \fBld\fR.
  The \fBld\fR that is called is determined by the
! \&\fB\-\-with\-ld\fR configure option, GCC\*(Aqs program search path, and
! finally by the user\*(Aqs \fBPATH\fR.  The linker used by GCC can be printed
! using \fBwhich \`gcc \-print\-prog\-name=ld\`\fR.  This option is only available
! on the 64\-bit HP\-UX GCC, i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
! .IP \fB\-mhp\-ld\fR 4
  .IX Item "-mhp-ld"
! Use options specific to HP \fBld\fR.
  This passes \fB\-b\fR to \fBld\fR when building
  a shared library and passes \fB+Accept TypeMismatch\fR to \fBld\fR on all
! links.  It is the default when GCC is configured, explicitly or
! implicitly, with the HP linker.  This option does not affect
  which \fBld\fR is called; it only changes what parameters are passed to that
  \&\fBld\fR.
  The \fBld\fR that is called is determined by the \fB\-\-with\-ld\fR
! configure option, GCC\*(Aqs program search path, and finally by the user\*(Aqs
! \&\fBPATH\fR.  The linker used by GCC can be printed using \fBwhich
! \&\`gcc \-print\-prog\-name=ld\`\fR.  This option is only available on the 64\-bit
! HP\-UX GCC, i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
! .IP \fB\-mlinker\-opt\fR 4
  .IX Item "-mlinker-opt"
! Enable the optimization pass in the HP\-UX linker.  Note this makes symbolic
! debugging impossible.  It also triggers a bug in the HP\-UX 8 and HP\-UX 9
  linkers in which they give bogus error messages when linking some programs.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  Generate code that uses long call sequences.  This ensures that a call
  is always able to reach linker generated stubs.  The default is to generate
*************** long calls only when the distance from t
*** 24490,24502 ****
  of the function or translation unit, as the case may be, exceeds a
  predefined limit set by the branch type being used.  The limits for
  normal calls are 7,600,000 and 240,000 bytes, respectively for the
! \&\s-1PA 2.0\s0 and \s-1PA 1.X\s0 architectures.  Sibcalls are always limited at
  240,000 bytes.
  .Sp
  Distances are measured from the beginning of functions when using the
  \&\fB\-ffunction\-sections\fR option, or when using the \fB\-mgas\fR
! and \fB\-mno\-portable\-runtime\fR options together under HP-UX with
! the \s-1SOM\s0 linker.
  .Sp
  It is normally not desirable to use this option as it degrades
  performance.  However, it may be useful in large applications,
--- 24421,24433 ----
  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.
  .Sp
  Distances are measured from the beginning of functions when using the
  \&\fB\-ffunction\-sections\fR option, or when using the \fB\-mgas\fR
! and \fB\-mno\-portable\-runtime\fR options together under HP\-UX with
! the SOM linker.
  .Sp
  It is normally not desirable to use this option as it degrades
  performance.  However, it may be useful in large applications,
*************** particularly when partial linking is use
*** 24505,24577 ****
  The types of long calls used depends on the capabilities of the
  assembler and linker, and the type of code being generated.  The
  impact on systems that support long absolute calls, and long pic
! symbol-difference or pc-relative calls should be relatively small.
! However, an indirect call is used on 32\-bit \s-1ELF\s0 systems in pic code
  and it is quite long.
! .IP "\fB\-mlong\-load\-store\fR" 4
  .IX Item "-mlong-load-store"
  Generate 3\-instruction load and store sequences as sometimes required by
! the HP-UX 10 linker.  This is equivalent to the \fB+k\fR option to
! the \s-1HP\s0 compilers.
! .IP "\fB\-mjump\-in\-delay\fR" 4
  .IX Item "-mjump-in-delay"
  This option is ignored and provided for compatibility purposes only.
! .IP "\fB\-mno\-space\-regs\fR" 4
  .IX Item "-mno-space-regs"
  Generate code that assumes the target has no space registers.  This allows
! \&\s-1GCC\s0 to generate faster indirect calls and use unscaled index address modes.
  .Sp
! Such code is suitable for level 0 \s-1PA\s0 systems and kernels.
! .IP "\fB\-mordered\fR" 4
  .IX Item "-mordered"
  Assume memory references are ordered and barriers are not needed.
! .IP "\fB\-mportable\-runtime\fR" 4
  .IX Item "-mportable-runtime"
! Use the portable calling conventions proposed by \s-1HP\s0 for \s-1ELF\s0 systems.
! .IP "\fB\-mschedule=\fR\fIcpu-type\fR" 4
  .IX Item "-mschedule=cpu-type"
  Schedule code according to the constraints for the machine type
! \&\fIcpu-type\fR.  The choices for \fIcpu-type\fR are \fB700\fR
  \&\fB7100\fR, \fB7100LC\fR, \fB7200\fR, \fB7300\fR and \fB8000\fR.  Refer
! to \fI/usr/lib/sched.models\fR on an HP-UX system to determine the
  proper scheduling option for your machine.  The default scheduling is
  \&\fB8000\fR.
! .IP "\fB\-msio\fR" 4
  .IX Item "-msio"
! Generate the predefine, \f(CW\*(C`_SIO\*(C'\fR, for server \s-1IO.\s0  The default is
  \&\fB\-mwsio\fR.  This generates the predefines, \f(CW\*(C`_\|_hp9000s700\*(C'\fR,
! \&\f(CW\*(C`_\|_hp9000s700_\|_\*(C'\fR and \f(CW\*(C`_WSIO\*(C'\fR, for workstation \s-1IO.\s0  These
! options are available under HP-UX and HI-UX.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  Generate output containing library calls for floating point.
! \&\fBWarning:\fR the requisite libraries are not available for all \s-1HPPA\s0
! targets.  Normally the facilities of the machine's usual C compiler are
! used, but this cannot be done directly in cross-compilation.  You must make
  your own arrangements to provide suitable library functions for
! cross-compilation.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with \s-1GCC,\s0 with \fB\-msoft\-float\fR in order for
  this to work.
! .IP "\fB\-msoft\-mult\fR" 4
  .IX Item "-msoft-mult"
  Use software integer multiplication.
  .Sp
  This disables the use of the \f(CW\*(C`xmpyu\*(C'\fR instruction.
! .IP "\fB\-munix=\fR\fIunix-std\fR" 4
  .IX Item "-munix=unix-std"
  Generate compiler predefines and select a startfile for the specified
! \&\s-1UNIX\s0 standard.  The choices for \fIunix-std\fR are \fB93\fR, \fB95\fR
! and \fB98\fR.  \fB93\fR is supported on all HP-UX versions.  \fB95\fR
! is available on HP-UX 10.10 and later.  \fB98\fR is available on HP-UX
! 11.11 and later.  The default values are \fB93\fR for HP-UX 10.00,
! \&\fB95\fR for HP-UX 10.10 though to 11.00, and \fB98\fR for HP-UX 11.11
  and later.
  .Sp
! \&\fB\-munix=93\fR provides the same predefines as \s-1GCC 3.3\s0 and 3.4.
  \&\fB\-munix=95\fR provides additional predefines for \f(CW\*(C`XOPEN_UNIX\*(C'\fR
  and \f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, and the startfile \fIunix95.o\fR.
  \&\fB\-munix=98\fR provides additional predefines for \f(CW\*(C`_XOPEN_UNIX\*(C'\fR,
--- 24436,24508 ----
  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.
! .IP \fB\-mlong\-load\-store\fR 4
  .IX Item "-mlong-load-store"
  Generate 3\-instruction load and store sequences as sometimes required by
! the HP\-UX 10 linker.  This is equivalent to the \fB+k\fR option to
! the HP compilers.
! .IP \fB\-mjump\-in\-delay\fR 4
  .IX Item "-mjump-in-delay"
  This option is ignored and provided for compatibility purposes only.
! .IP \fB\-mno\-space\-regs\fR 4
  .IX Item "-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.
  .Sp
! Such code is suitable for level 0 PA systems and kernels.
! .IP \fB\-mordered\fR 4
  .IX Item "-mordered"
  Assume memory references are ordered and barriers are not needed.
! .IP \fB\-mportable\-runtime\fR 4
  .IX Item "-mportable-runtime"
! Use the portable calling conventions proposed by HP for ELF systems.
! .IP \fB\-mschedule=\fR\fIcpu\-type\fR 4
  .IX Item "-mschedule=cpu-type"
  Schedule code according to the constraints for the machine type
! \&\fIcpu\-type\fR.  The choices for \fIcpu\-type\fR are \fB700\fR
  \&\fB7100\fR, \fB7100LC\fR, \fB7200\fR, \fB7300\fR and \fB8000\fR.  Refer
! to \fI/usr/lib/sched.models\fR on an HP\-UX system to determine the
  proper scheduling option for your machine.  The default scheduling is
  \&\fB8000\fR.
! .IP \fB\-msio\fR 4
  .IX Item "-msio"
! Generate the predefine, \f(CW\*(C`_SIO\*(C'\fR, for server IO.  The default is
  \&\fB\-mwsio\fR.  This generates the predefines, \f(CW\*(C`_\|_hp9000s700\*(C'\fR,
! \&\f(CW\*(C`_\|_hp9000s700_\|_\*(C'\fR and \f(CW\*(C`_WSIO\*(C'\fR, for workstation IO.  These
! options are available under HP\-UX and HI\-UX.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  Generate output containing library calls for floating point.
! \&\fBWarning:\fR the requisite libraries are not available for all HPPA
! targets.  Normally the facilities of the machine\*(Aqs usual C compiler are
! used, but this cannot be done directly in cross\-compilation.  You must make
  your own arrangements to provide suitable library functions for
! cross\-compilation.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with GCC, with \fB\-msoft\-float\fR in order for
  this to work.
! .IP \fB\-msoft\-mult\fR 4
  .IX Item "-msoft-mult"
  Use software integer multiplication.
  .Sp
  This disables the use of the \f(CW\*(C`xmpyu\*(C'\fR instruction.
! .IP \fB\-munix=\fR\fIunix\-std\fR 4
  .IX Item "-munix=unix-std"
  Generate compiler predefines and select a startfile for the specified
! UNIX standard.  The choices for \fIunix\-std\fR are \fB93\fR, \fB95\fR
! and \fB98\fR.  \fB93\fR is supported on all HP\-UX versions.  \fB95\fR
! is available on HP\-UX 10.10 and later.  \fB98\fR is available on HP\-UX
! 11.11 and later.  The default values are \fB93\fR for HP\-UX 10.00,
! \&\fB95\fR for HP\-UX 10.10 though to 11.00, and \fB98\fR for HP\-UX 11.11
  and later.
  .Sp
! \&\fB\-munix=93\fR provides the same predefines as GCC 3.3 and 3.4.
  \&\fB\-munix=95\fR provides additional predefines for \f(CW\*(C`XOPEN_UNIX\*(C'\fR
  and \f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, and the startfile \fIunix95.o\fR.
  \&\fB\-munix=98\fR provides additional predefines for \f(CW\*(C`_XOPEN_UNIX\*(C'\fR,
*************** for various library routines.  It also a
*** 24583,24783 ****
  of the C library.  Thus, \fIextreme\fR care is needed in using this
  option.
  .Sp
! Library code that is intended to operate with more than one \s-1UNIX\s0
  standard must test, set and restore the variable \f(CW\*(C`_\|_xpg4_extended_mask\*(C'\fR
! as appropriate.  Most \s-1GNU\s0 software doesn't provide this capability.
! .IP "\fB\-nolibdld\fR" 4
  .IX Item "-nolibdld"
  Suppress the generation of link options to search libdld.sl when the
! \&\fB\-static\fR option is specified on HP-UX 10 and later.
! .IP "\fB\-static\fR" 4
  .IX Item "-static"
! The HP-UX implementation of setlocale in libc has a dependency on
! libdld.sl.  There isn't an archive version of libdld.sl.  Thus,
  when the \fB\-static\fR option is specified, special link options
  are needed to resolve this dependency.
  .Sp
! On HP-UX 10 and later, the \s-1GCC\s0 driver adds the necessary options to
  link with libdld.sl when the \fB\-static\fR option is specified.
  This causes the resulting binary to be dynamic.  On the 64\-bit port,
  the linkers generate dynamic binaries by default in any case.  The
! \&\fB\-nolibdld\fR option can be used to prevent the \s-1GCC\s0 driver from
  adding these link options.
! .IP "\fB\-threads\fR" 4
  .IX Item "-threads"
  Add support for multithreading with the \fIdce thread\fR library
! under HP-UX.  This option sets flags for both the preprocessor and
  linker.
  .PP
! \fI\s-1IA\-64\s0 Options\fR
  .IX Subsection "IA-64 Options"
  .PP
! These are the \fB\-m\fR options defined for the Intel \s-1IA\-64\s0 architecture.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code for a big-endian target.  This is the default for HP-UX.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code for a little-endian target.  This is the default for \s-1AIX5\s0
  and GNU/Linux.
! .IP "\fB\-mgnu\-as\fR" 4
  .IX Item "-mgnu-as"
  .PD 0
! .IP "\fB\-mno\-gnu\-as\fR" 4
  .IX Item "-mno-gnu-as"
  .PD
! Generate (or don't) code for the \s-1GNU\s0 assembler.  This is the default.
! .IP "\fB\-mgnu\-ld\fR" 4
  .IX Item "-mgnu-ld"
  .PD 0
! .IP "\fB\-mno\-gnu\-ld\fR" 4
  .IX Item "-mno-gnu-ld"
  .PD
! Generate (or don't) code for the \s-1GNU\s0 linker.  This is the default.
! .IP "\fB\-mno\-pic\fR" 4
  .IX Item "-mno-pic"
  Generate code that does not use a global pointer register.  The result
! is not position independent code, and violates the \s-1IA\-64 ABI.\s0
! .IP "\fB\-mvolatile\-asm\-stop\fR" 4
  .IX Item "-mvolatile-asm-stop"
  .PD 0
! .IP "\fB\-mno\-volatile\-asm\-stop\fR" 4
  .IX Item "-mno-volatile-asm-stop"
  .PD
! Generate (or don't) a stop bit immediately before and after volatile asm
  statements.
! .IP "\fB\-mregister\-names\fR" 4
  .IX Item "-mregister-names"
  .PD 0
! .IP "\fB\-mno\-register\-names\fR" 4
  .IX Item "-mno-register-names"
  .PD
! Generate (or don't) \fBin\fR, \fBloc\fR, and \fBout\fR register names for
  the stacked registers.  This may make assembler output more readable.
! .IP "\fB\-mno\-sdata\fR" 4
  .IX Item "-mno-sdata"
  .PD 0
! .IP "\fB\-msdata\fR" 4
  .IX Item "-msdata"
  .PD
  Disable (or enable) optimizations that use the small data section.  This may
  be useful for working around optimizer bugs.
! .IP "\fB\-mconstant\-gp\fR" 4
  .IX Item "-mconstant-gp"
  Generate code that uses a single constant global pointer value.  This is
  useful when compiling kernel code.
! .IP "\fB\-mauto\-pic\fR" 4
  .IX Item "-mauto-pic"
! Generate code that is self-relocatable.  This implies \fB\-mconstant\-gp\fR.
  This is useful when compiling firmware code.
! .IP "\fB\-minline\-float\-divide\-min\-latency\fR" 4
  .IX Item "-minline-float-divide-min-latency"
! Generate code for inline divides of floating-point values
  using the minimum latency algorithm.
! .IP "\fB\-minline\-float\-divide\-max\-throughput\fR" 4
  .IX Item "-minline-float-divide-max-throughput"
! Generate code for inline divides of floating-point values
  using the maximum throughput algorithm.
! .IP "\fB\-mno\-inline\-float\-divide\fR" 4
  .IX Item "-mno-inline-float-divide"
! Do not generate inline code for divides of floating-point values.
! .IP "\fB\-minline\-int\-divide\-min\-latency\fR" 4
  .IX Item "-minline-int-divide-min-latency"
  Generate code for inline divides of integer values
  using the minimum latency algorithm.
! .IP "\fB\-minline\-int\-divide\-max\-throughput\fR" 4
  .IX Item "-minline-int-divide-max-throughput"
  Generate code for inline divides of integer values
  using the maximum throughput algorithm.
! .IP "\fB\-mno\-inline\-int\-divide\fR" 4
  .IX Item "-mno-inline-int-divide"
  Do not generate inline code for divides of integer values.
! .IP "\fB\-minline\-sqrt\-min\-latency\fR" 4
  .IX Item "-minline-sqrt-min-latency"
  Generate code for inline square roots
  using the minimum latency algorithm.
! .IP "\fB\-minline\-sqrt\-max\-throughput\fR" 4
  .IX Item "-minline-sqrt-max-throughput"
  Generate code for inline square roots
  using the maximum throughput algorithm.
! .IP "\fB\-mno\-inline\-sqrt\fR" 4
  .IX Item "-mno-inline-sqrt"
  Do not generate inline code for \f(CW\*(C`sqrt\*(C'\fR.
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
! Do (don't) generate code that uses the fused multiply/add or multiply/subtract
  instructions.  The default is to use these instructions.
! .IP "\fB\-mno\-dwarf2\-asm\fR" 4
  .IX Item "-mno-dwarf2-asm"
  .PD 0
! .IP "\fB\-mdwarf2\-asm\fR" 4
  .IX Item "-mdwarf2-asm"
  .PD
! Don't (or do) generate assembler code for the \s-1DWARF\s0 line number debugging
! info.  This may be useful when not using the \s-1GNU\s0 assembler.
! .IP "\fB\-mearly\-stop\-bits\fR" 4
  .IX Item "-mearly-stop-bits"
  .PD 0
! .IP "\fB\-mno\-early\-stop\-bits\fR" 4
  .IX Item "-mno-early-stop-bits"
  .PD
  Allow stop bits to be placed earlier than immediately preceding the
  instruction that triggered the stop bit.  This can improve instruction
  scheduling, but does not always do so.
! .IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP "\fB\-mtls\-size=\fR\fItls-size\fR" 4
  .IX Item "-mtls-size=tls-size"
! Specify bit size of immediate \s-1TLS\s0 offsets.  Valid values are 14, 22, and
  64.
! .IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
  .IX Item "-mtune=cpu-type"
! Tune the instruction scheduling for a particular \s-1CPU,\s0 Valid values are
  \&\fBitanium\fR, \fBitanium1\fR, \fBmerced\fR, \fBitanium2\fR,
  and \fBmckinley\fR.
! .IP "\fB\-milp32\fR" 4
  .IX Item "-milp32"
  .PD 0
! .IP "\fB\-mlp64\fR" 4
  .IX Item "-mlp64"
  .PD
  Generate code for a 32\-bit or 64\-bit environment.
  The 32\-bit environment sets int, long and pointer to 32 bits.
  The 64\-bit environment sets int to 32 bits and long and pointer
! to 64 bits.  These are HP-UX specific flags.
! .IP "\fB\-mno\-sched\-br\-data\-spec\fR" 4
  .IX Item "-mno-sched-br-data-spec"
  .PD 0
! .IP "\fB\-msched\-br\-data\-spec\fR" 4
  .IX Item "-msched-br-data-spec"
  .PD
  (Dis/En)able data speculative scheduling before reload.
  This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
  the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
  The default setting is disabled.
! .IP "\fB\-msched\-ar\-data\-spec\fR" 4
  .IX Item "-msched-ar-data-spec"
  .PD 0
! .IP "\fB\-mno\-sched\-ar\-data\-spec\fR" 4
  .IX Item "-mno-sched-ar-data-spec"
  .PD
  (En/Dis)able data speculative scheduling after reload.
  This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
  the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
  The default setting is enabled.
! .IP "\fB\-mno\-sched\-control\-spec\fR" 4
  .IX Item "-mno-sched-control-spec"
  .PD 0
! .IP "\fB\-msched\-control\-spec\fR" 4
  .IX Item "-msched-control-spec"
  .PD
  (Dis/En)able control speculative scheduling.  This feature is
--- 24514,24714 ----
  of the C library.  Thus, \fIextreme\fR care is needed in using this
  option.
  .Sp
! Library code that is intended to operate with more than one UNIX
  standard must test, set and restore the variable \f(CW\*(C`_\|_xpg4_extended_mask\*(C'\fR
! as appropriate.  Most GNU software doesn\*(Aqt provide this capability.
! .IP \fB\-nolibdld\fR 4
  .IX Item "-nolibdld"
  Suppress the generation of link options to search libdld.sl when the
! \&\fB\-static\fR option is specified on HP\-UX 10 and later.
! .IP \fB\-static\fR 4
  .IX Item "-static"
! The HP\-UX implementation of setlocale in libc has a dependency on
! libdld.sl.  There isn\*(Aqt an archive version of libdld.sl.  Thus,
  when the \fB\-static\fR option is specified, special link options
  are needed to resolve this dependency.
  .Sp
! On HP\-UX 10 and later, the GCC driver adds the necessary options to
  link with libdld.sl when the \fB\-static\fR option is specified.
  This causes the resulting binary to be dynamic.  On the 64\-bit port,
  the linkers generate dynamic binaries by default in any case.  The
! \&\fB\-nolibdld\fR option can be used to prevent the GCC driver from
  adding these link options.
! .IP \fB\-threads\fR 4
  .IX Item "-threads"
  Add support for multithreading with the \fIdce thread\fR library
! under HP\-UX.  This option sets flags for both the preprocessor and
  linker.
  .PP
! \fIIA\-64 Options\fR
  .IX Subsection "IA-64 Options"
  .PP
! These are the \fB\-m\fR options defined for the Intel IA\-64 architecture.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code for a big\-endian target.  This is the default for HP\-UX.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code for a little\-endian target.  This is the default for AIX5
  and GNU/Linux.
! .IP \fB\-mgnu\-as\fR 4
  .IX Item "-mgnu-as"
  .PD 0
! .IP \fB\-mno\-gnu\-as\fR 4
  .IX Item "-mno-gnu-as"
  .PD
! Generate (or don\*(Aqt) code for the GNU assembler.  This is the default.
! .IP \fB\-mgnu\-ld\fR 4
  .IX Item "-mgnu-ld"
  .PD 0
! .IP \fB\-mno\-gnu\-ld\fR 4
  .IX Item "-mno-gnu-ld"
  .PD
! Generate (or don\*(Aqt) code for the GNU linker.  This is the default.
! .IP \fB\-mno\-pic\fR 4
  .IX Item "-mno-pic"
  Generate code that does not use a global pointer register.  The result
! is not position independent code, and violates the IA\-64 ABI.
! .IP \fB\-mvolatile\-asm\-stop\fR 4
  .IX Item "-mvolatile-asm-stop"
  .PD 0
! .IP \fB\-mno\-volatile\-asm\-stop\fR 4
  .IX Item "-mno-volatile-asm-stop"
  .PD
! Generate (or don\*(Aqt) a stop bit immediately before and after volatile asm
  statements.
! .IP \fB\-mregister\-names\fR 4
  .IX Item "-mregister-names"
  .PD 0
! .IP \fB\-mno\-register\-names\fR 4
  .IX Item "-mno-register-names"
  .PD
! Generate (or don\*(Aqt) \fBin\fR, \fBloc\fR, and \fBout\fR register names for
  the stacked registers.  This may make assembler output more readable.
! .IP \fB\-mno\-sdata\fR 4
  .IX Item "-mno-sdata"
  .PD 0
! .IP \fB\-msdata\fR 4
  .IX Item "-msdata"
  .PD
  Disable (or enable) optimizations that use the small data section.  This may
  be useful for working around optimizer bugs.
! .IP \fB\-mconstant\-gp\fR 4
  .IX Item "-mconstant-gp"
  Generate code that uses a single constant global pointer value.  This is
  useful when compiling kernel code.
! .IP \fB\-mauto\-pic\fR 4
  .IX Item "-mauto-pic"
! Generate code that is self\-relocatable.  This implies \fB\-mconstant\-gp\fR.
  This is useful when compiling firmware code.
! .IP \fB\-minline\-float\-divide\-min\-latency\fR 4
  .IX Item "-minline-float-divide-min-latency"
! Generate code for inline divides of floating\-point values
  using the minimum latency algorithm.
! .IP \fB\-minline\-float\-divide\-max\-throughput\fR 4
  .IX Item "-minline-float-divide-max-throughput"
! Generate code for inline divides of floating\-point values
  using the maximum throughput algorithm.
! .IP \fB\-mno\-inline\-float\-divide\fR 4
  .IX Item "-mno-inline-float-divide"
! Do not generate inline code for divides of floating\-point values.
! .IP \fB\-minline\-int\-divide\-min\-latency\fR 4
  .IX Item "-minline-int-divide-min-latency"
  Generate code for inline divides of integer values
  using the minimum latency algorithm.
! .IP \fB\-minline\-int\-divide\-max\-throughput\fR 4
  .IX Item "-minline-int-divide-max-throughput"
  Generate code for inline divides of integer values
  using the maximum throughput algorithm.
! .IP \fB\-mno\-inline\-int\-divide\fR 4
  .IX Item "-mno-inline-int-divide"
  Do not generate inline code for divides of integer values.
! .IP \fB\-minline\-sqrt\-min\-latency\fR 4
  .IX Item "-minline-sqrt-min-latency"
  Generate code for inline square roots
  using the minimum latency algorithm.
! .IP \fB\-minline\-sqrt\-max\-throughput\fR 4
  .IX Item "-minline-sqrt-max-throughput"
  Generate code for inline square roots
  using the maximum throughput algorithm.
! .IP \fB\-mno\-inline\-sqrt\fR 4
  .IX Item "-mno-inline-sqrt"
  Do not generate inline code for \f(CW\*(C`sqrt\*(C'\fR.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
! Do (don\*(Aqt) generate code that uses the fused multiply/add or multiply/subtract
  instructions.  The default is to use these instructions.
! .IP \fB\-mno\-dwarf2\-asm\fR 4
  .IX Item "-mno-dwarf2-asm"
  .PD 0
! .IP \fB\-mdwarf2\-asm\fR 4
  .IX Item "-mdwarf2-asm"
  .PD
! Don\*(Aqt (or do) generate assembler code for the DWARF line number debugging
! info.  This may be useful when not using the GNU assembler.
! .IP \fB\-mearly\-stop\-bits\fR 4
  .IX Item "-mearly-stop-bits"
  .PD 0
! .IP \fB\-mno\-early\-stop\-bits\fR 4
  .IX Item "-mno-early-stop-bits"
  .PD
  Allow stop bits to be placed earlier than immediately preceding the
  instruction that triggered the stop bit.  This can improve instruction
  scheduling, but does not always do so.
! .IP \fB\-mfixed\-range=\fR\fIregister\-range\fR 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP \fB\-mtls\-size=\fR\fItls\-size\fR 4
  .IX Item "-mtls-size=tls-size"
! Specify bit size of immediate TLS offsets.  Valid values are 14, 22, and
  64.
! .IP \fB\-mtune=\fR\fIcpu\-type\fR 4
  .IX Item "-mtune=cpu-type"
! Tune the instruction scheduling for a particular CPU, Valid values are
  \&\fBitanium\fR, \fBitanium1\fR, \fBmerced\fR, \fBitanium2\fR,
  and \fBmckinley\fR.
! .IP \fB\-milp32\fR 4
  .IX Item "-milp32"
  .PD 0
! .IP \fB\-mlp64\fR 4
  .IX Item "-mlp64"
  .PD
  Generate code for a 32\-bit or 64\-bit environment.
  The 32\-bit environment sets int, long and pointer to 32 bits.
  The 64\-bit environment sets int to 32 bits and long and pointer
! to 64 bits.  These are HP\-UX specific flags.
! .IP \fB\-mno\-sched\-br\-data\-spec\fR 4
  .IX Item "-mno-sched-br-data-spec"
  .PD 0
! .IP \fB\-msched\-br\-data\-spec\fR 4
  .IX Item "-msched-br-data-spec"
  .PD
  (Dis/En)able data speculative scheduling before reload.
  This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
  the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
  The default setting is disabled.
! .IP \fB\-msched\-ar\-data\-spec\fR 4
  .IX Item "-msched-ar-data-spec"
  .PD 0
! .IP \fB\-mno\-sched\-ar\-data\-spec\fR 4
  .IX Item "-mno-sched-ar-data-spec"
  .PD
  (En/Dis)able data speculative scheduling after reload.
  This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
  the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
  The default setting is enabled.
! .IP \fB\-mno\-sched\-control\-spec\fR 4
  .IX Item "-mno-sched-control-spec"
  .PD 0
! .IP \fB\-msched\-control\-spec\fR 4
  .IX Item "-msched-control-spec"
  .PD
  (Dis/En)able control speculative scheduling.  This feature is
*************** available only during region scheduling
*** 24785,25077 ****
  This results in generation of the \f(CW\*(C`ld.s\*(C'\fR instructions and
  the corresponding check instructions \f(CW\*(C`chk.s\*(C'\fR.
  The default setting is disabled.
! .IP "\fB\-msched\-br\-in\-data\-spec\fR" 4
  .IX Item "-msched-br-in-data-spec"
  .PD 0
! .IP "\fB\-mno\-sched\-br\-in\-data\-spec\fR" 4
  .IX Item "-mno-sched-br-in-data-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the data speculative loads before reload.
  This is effective only with \fB\-msched\-br\-data\-spec\fR enabled.
  The default setting is enabled.
! .IP "\fB\-msched\-ar\-in\-data\-spec\fR" 4
  .IX Item "-msched-ar-in-data-spec"
  .PD 0
! .IP "\fB\-mno\-sched\-ar\-in\-data\-spec\fR" 4
  .IX Item "-mno-sched-ar-in-data-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the data speculative loads after reload.
  This is effective only with \fB\-msched\-ar\-data\-spec\fR enabled.
  The default setting is enabled.
! .IP "\fB\-msched\-in\-control\-spec\fR" 4
  .IX Item "-msched-in-control-spec"
  .PD 0
! .IP "\fB\-mno\-sched\-in\-control\-spec\fR" 4
  .IX Item "-mno-sched-in-control-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the control speculative loads.
  This is effective only with \fB\-msched\-control\-spec\fR enabled.
  The default setting is enabled.
! .IP "\fB\-mno\-sched\-prefer\-non\-data\-spec\-insns\fR" 4
  .IX Item "-mno-sched-prefer-non-data-spec-insns"
  .PD 0
! .IP "\fB\-msched\-prefer\-non\-data\-spec\-insns\fR" 4
  .IX Item "-msched-prefer-non-data-spec-insns"
  .PD
! If enabled, data-speculative instructions are chosen for schedule
  only if there are no other choices at the moment.  This makes
  the use of the data speculation much more conservative.
  The default setting is disabled.
! .IP "\fB\-mno\-sched\-prefer\-non\-control\-spec\-insns\fR" 4
  .IX Item "-mno-sched-prefer-non-control-spec-insns"
  .PD 0
! .IP "\fB\-msched\-prefer\-non\-control\-spec\-insns\fR" 4
  .IX Item "-msched-prefer-non-control-spec-insns"
  .PD
! If enabled, control-speculative instructions are chosen for schedule
  only if there are no other choices at the moment.  This makes
  the use of the control speculation much more conservative.
  The default setting is disabled.
! .IP "\fB\-mno\-sched\-count\-spec\-in\-critical\-path\fR" 4
  .IX Item "-mno-sched-count-spec-in-critical-path"
  .PD 0
! .IP "\fB\-msched\-count\-spec\-in\-critical\-path\fR" 4
  .IX Item "-msched-count-spec-in-critical-path"
  .PD
  If enabled, speculative dependencies are considered during
  computation of the instructions priorities.  This makes the use of the
  speculation a bit more conservative.
  The default setting is disabled.
! .IP "\fB\-msched\-spec\-ldc\fR" 4
  .IX Item "-msched-spec-ldc"
  Use a simple data speculation check.  This option is on by default.
! .IP "\fB\-msched\-control\-spec\-ldc\fR" 4
  .IX Item "-msched-control-spec-ldc"
  Use a simple check for control speculation.  This option is on by default.
! .IP "\fB\-msched\-stop\-bits\-after\-every\-cycle\fR" 4
  .IX Item "-msched-stop-bits-after-every-cycle"
  Place a stop bit after every cycle when scheduling.  This option is on
  by default.
! .IP "\fB\-msched\-fp\-mem\-deps\-zero\-cost\fR" 4
  .IX Item "-msched-fp-mem-deps-zero-cost"
! Assume that floating-point stores and loads are not likely to cause a conflict
  when placed into the same instruction group.  This option is disabled by
  default.
! .IP "\fB\-msel\-sched\-dont\-check\-control\-spec\fR" 4
  .IX Item "-msel-sched-dont-check-control-spec"
  Generate checks for control speculation in selective scheduling.
  This flag is disabled by default.
! .IP "\fB\-msched\-max\-memory\-insns=\fR\fImax-insns\fR" 4
  .IX Item "-msched-max-memory-insns=max-insns"
  Limit on the number of memory insns per instruction group, giving lower
  priority to subsequent memory insns attempting to schedule in the same
  instruction group. Frequently useful to prevent cache bank conflicts.
  The default value is 1.
! .IP "\fB\-msched\-max\-memory\-insns\-hard\-limit\fR" 4
  .IX Item "-msched-max-memory-insns-hard-limit"
! Makes the limit specified by \fBmsched-max-memory-insns\fR a hard limit,
  disallowing more than that number in an instruction group.
! Otherwise, the limit is \*(L"soft\*(R", meaning that non-memory operations
  are preferred when the limit is reached, but memory operations may still
  be scheduled.
  .PP
! \fI\s-1LM32\s0 Options\fR
  .IX Subsection "LM32 Options"
  .PP
  These \fB\-m\fR options are defined for the LatticeMico32 architecture:
! .IP "\fB\-mbarrel\-shift\-enabled\fR" 4
  .IX Item "-mbarrel-shift-enabled"
! Enable barrel-shift instructions.
! .IP "\fB\-mdivide\-enabled\fR" 4
  .IX Item "-mdivide-enabled"
  Enable divide and modulus instructions.
! .IP "\fB\-mmultiply\-enabled\fR" 4
  .IX Item "-mmultiply-enabled"
  Enable multiply instructions.
! .IP "\fB\-msign\-extend\-enabled\fR" 4
  .IX Item "-msign-extend-enabled"
  Enable sign extend instructions.
! .IP "\fB\-muser\-enabled\fR" 4
  .IX Item "-muser-enabled"
! Enable user-defined instructions.
  .PP
  \fILoongArch Options\fR
  .IX Subsection "LoongArch Options"
  .PP
! These command-line options are defined for LoongArch targets:
! .IP "\fB\-march=\fR\fIcpu-type\fR" 4
  .IX Item "-march=cpu-type"
! Generate instructions for the machine type \fIcpu-type\fR.  In contrast to
! \&\fB\-mtune=\fR\fIcpu-type\fR, which merely tunes the generated code
! for the specified \fIcpu-type\fR, \fB\-march=\fR\fIcpu-type\fR allows \s-1GCC\s0
  to generate code that may not run at all on processors other than the one
! indicated.  Specifying \fB\-march=\fR\fIcpu-type\fR implies
! \&\fB\-mtune=\fR\fIcpu-type\fR, except where noted otherwise.
  .Sp
! The choices for \fIcpu-type\fR are:
  .RS 4
! .IP "\fBnative\fR" 4
  .IX Item "native"
! This selects the \s-1CPU\s0 to generate code for at compilation time by determining
  the processor type of the compiling machine.  Using \fB\-march=native\fR
  enables all instruction subsets supported by the local machine (hence
  the result might not run on different machines).  Using \fB\-mtune=native\fR
  produces code optimized for the local machine under the constraints
  of the selected instruction set.
! .IP "\fBloongarch64\fR" 4
  .IX Item "loongarch64"
! A generic \s-1CPU\s0 with 64\-bit extensions.
! .IP "\fBla464\fR" 4
  .IX Item "la464"
! LoongArch \s-1LA464 CPU\s0 with \s-1LBT, LSX, LASX, LVZ.\s0
  .RE
  .RS 4
  .RE
! .IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
  .IX Item "-mtune=cpu-type"
  Optimize the output for the given processor, specified by microarchitecture
  name.
! .IP "\fB\-mabi=\fR\fIbase-abi-type\fR" 4
  .IX Item "-mabi=base-abi-type"
  Generate code for the specified calling convention.
! \&\fIbase-abi-type\fR can be one of:
  .RS 4
! .IP "\fBlp64d\fR" 4
  .IX Item "lp64d"
! Uses 64\-bit general purpose registers and 32/64\-bit floating-point
! registers for parameter passing.  Data model is \s-1LP64,\s0 where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
! .IP "\fBlp64f\fR" 4
  .IX Item "lp64f"
! Uses 64\-bit general purpose registers and 32\-bit floating-point
! registers for parameter passing.  Data model is \s-1LP64,\s0 where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
! .IP "\fBlp64s\fR" 4
  .IX Item "lp64s"
! Uses 64\-bit general purpose registers and no floating-point
! registers for parameter passing.  Data model is \s-1LP64,\s0 where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mfpu=\fR\fIfpu-type\fR" 4
  .IX Item "-mfpu=fpu-type"
! Generate code for the specified \s-1FPU\s0 type, which can be one of:
  .RS 4
! .IP "\fB64\fR" 4
  .IX Item "64"
! Allow the use of hardware floating-point instructions for 32\-bit
  and 64\-bit operations.
! .IP "\fB32\fR" 4
  .IX Item "32"
! Allow the use of hardware floating-point instructions for 32\-bit
  operations.
! .IP "\fBnone\fR" 4
  .IX Item "none"
  .PD 0
! .IP "\fB0\fR" 4
  .IX Item "0"
  .PD
! Prevent the use of hardware floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
! Force \fB\-mfpu=none\fR and prevents the use of floating-point
  registers for parameter passing.  This option may change the target
! \&\s-1ABI.\s0
! .IP "\fB\-msingle\-float\fR" 4
  .IX Item "-msingle-float"
! Force \fB\-mfpu=32\fR and allow the use of 32\-bit floating-point
  registers for parameter passing.  This option may change the target
! \&\s-1ABI.\s0
! .IP "\fB\-mdouble\-float\fR" 4
  .IX Item "-mdouble-float"
! Force \fB\-mfpu=64\fR and allow the use of 32/64\-bit floating-point
  registers for parameter passing.  This option may change the target
! \&\s-1ABI.\s0
! .IP "\fB\-mbranch\-cost=\fR\fIn\fR" 4
  .IX Item "-mbranch-cost=n"
  Set the cost of branches to roughly \fIn\fR instructions.
! .IP "\fB\-mcheck\-zero\-division\fR" 4
  .IX Item "-mcheck-zero-division"
  .PD 0
! .IP "\fB\-mno\-check\-zero\-divison\fR" 4
  .IX Item "-mno-check-zero-divison"
  .PD
  Trap (do not trap) on integer division by zero.  The default is
  \&\fB\-mcheck\-zero\-division\fR for \fB\-O0\fR or \fB\-Og\fR, and
  \&\fB\-mno\-check\-zero\-division\fR for other optimization levels.
! .IP "\fB\-mcond\-move\-int\fR" 4
  .IX Item "-mcond-move-int"
  .PD 0
! .IP "\fB\-mno\-cond\-move\-int\fR" 4
  .IX Item "-mno-cond-move-int"
  .PD
! Conditional moves for integral data in general-purpose registers
  are enabled (disabled).  The default is \fB\-mcond\-move\-int\fR.
! .IP "\fB\-mcond\-move\-float\fR" 4
  .IX Item "-mcond-move-float"
  .PD 0
! .IP "\fB\-mno\-cond\-move\-float\fR" 4
  .IX Item "-mno-cond-move-float"
  .PD
! Conditional moves for floating-point registers are enabled (disabled).
  The default is \fB\-mcond\-move\-float\fR.
! .IP "\fB\-mmemcpy\fR" 4
  .IX Item "-mmemcpy"
  .PD 0
! .IP "\fB\-mno\-memcpy\fR" 4
  .IX Item "-mno-memcpy"
  .PD
! Force (do not force) the use of \f(CW\*(C`memcpy\*(C'\fR for non-trivial block moves.
! The default is \fB\-mno\-memcpy\fR, which allows \s-1GCC\s0 to inline most
! constant-sized copies.  Setting optimization level to \fB\-Os\fR also
  forces the use of \f(CW\*(C`memcpy\*(C'\fR, but \fB\-mno\-memcpy\fR may override this
  behavior if explicitly specified, regardless of the order these options on
  the command line.
! .IP "\fB\-mstrict\-align\fR" 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP "\fB\-mno\-strict\-align\fR" 4
  .IX Item "-mno-strict-align"
  .PD
  Avoid or allow generating memory accesses that may not be aligned on a natural
  object boundary as described in the architecture specification. The default is
  \&\fB\-mno\-strict\-align\fR.
! .IP "\fB\-msmall\-data\-limit=\fR\fInumber\fR" 4
  .IX Item "-msmall-data-limit=number"
  Put global and static data smaller than \fInumber\fR bytes into a special
  section (on some targets).  The default value is 0.
! .IP "\fB\-mmax\-inline\-memcpy\-size=\fR\fIn\fR" 4
  .IX Item "-mmax-inline-memcpy-size=n"
  Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure copies)
  less than or equal to \fIn\fR bytes.  The default value of \fIn\fR is 1024.
! .IP "\fB\-mcmodel=\fR\fIcode-model\fR" 4
  .IX Item "-mcmodel=code-model"
  Set the code model to one of:
  .RS 4
! .IP "\fBtiny-static (Not implemented yet)\fR" 4
  .IX Item "tiny-static (Not implemented yet)"
  .PD 0
  .IP "\fBtiny (Not implemented yet)\fR" 4
  .IX Item "tiny (Not implemented yet)"
! .IP "\fBnormal\fR" 4
  .IX Item "normal"
  .PD
  The text segment must be within 128MB addressing space.  The data segment must
  be within 2GB addressing space.
! .IP "\fBmedium\fR" 4
  .IX Item "medium"
  The text segment and data segment must be within 2GB addressing space.
  .IP "\fBlarge (Not implemented yet)\fR" 4
  .IX Item "large (Not implemented yet)"
  .PD 0
! .IP "\fBextreme\fR" 4
  .IX Item "extreme"
  .PD
  This mode does not limit the size of the code segment and data segment.
--- 24716,25008 ----
  This results in generation of the \f(CW\*(C`ld.s\*(C'\fR instructions and
  the corresponding check instructions \f(CW\*(C`chk.s\*(C'\fR.
  The default setting is disabled.
! .IP \fB\-msched\-br\-in\-data\-spec\fR 4
  .IX Item "-msched-br-in-data-spec"
  .PD 0
! .IP \fB\-mno\-sched\-br\-in\-data\-spec\fR 4
  .IX Item "-mno-sched-br-in-data-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the data speculative loads before reload.
  This is effective only with \fB\-msched\-br\-data\-spec\fR enabled.
  The default setting is enabled.
! .IP \fB\-msched\-ar\-in\-data\-spec\fR 4
  .IX Item "-msched-ar-in-data-spec"
  .PD 0
! .IP \fB\-mno\-sched\-ar\-in\-data\-spec\fR 4
  .IX Item "-mno-sched-ar-in-data-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the data speculative loads after reload.
  This is effective only with \fB\-msched\-ar\-data\-spec\fR enabled.
  The default setting is enabled.
! .IP \fB\-msched\-in\-control\-spec\fR 4
  .IX Item "-msched-in-control-spec"
  .PD 0
! .IP \fB\-mno\-sched\-in\-control\-spec\fR 4
  .IX Item "-mno-sched-in-control-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the control speculative loads.
  This is effective only with \fB\-msched\-control\-spec\fR enabled.
  The default setting is enabled.
! .IP \fB\-mno\-sched\-prefer\-non\-data\-spec\-insns\fR 4
  .IX Item "-mno-sched-prefer-non-data-spec-insns"
  .PD 0
! .IP \fB\-msched\-prefer\-non\-data\-spec\-insns\fR 4
  .IX Item "-msched-prefer-non-data-spec-insns"
  .PD
! If enabled, data\-speculative instructions are chosen for schedule
  only if there are no other choices at the moment.  This makes
  the use of the data speculation much more conservative.
  The default setting is disabled.
! .IP \fB\-mno\-sched\-prefer\-non\-control\-spec\-insns\fR 4
  .IX Item "-mno-sched-prefer-non-control-spec-insns"
  .PD 0
! .IP \fB\-msched\-prefer\-non\-control\-spec\-insns\fR 4
  .IX Item "-msched-prefer-non-control-spec-insns"
  .PD
! If enabled, control\-speculative instructions are chosen for schedule
  only if there are no other choices at the moment.  This makes
  the use of the control speculation much more conservative.
  The default setting is disabled.
! .IP \fB\-mno\-sched\-count\-spec\-in\-critical\-path\fR 4
  .IX Item "-mno-sched-count-spec-in-critical-path"
  .PD 0
! .IP \fB\-msched\-count\-spec\-in\-critical\-path\fR 4
  .IX Item "-msched-count-spec-in-critical-path"
  .PD
  If enabled, speculative dependencies are considered during
  computation of the instructions priorities.  This makes the use of the
  speculation a bit more conservative.
  The default setting is disabled.
! .IP \fB\-msched\-spec\-ldc\fR 4
  .IX Item "-msched-spec-ldc"
  Use a simple data speculation check.  This option is on by default.
! .IP \fB\-msched\-control\-spec\-ldc\fR 4
  .IX Item "-msched-control-spec-ldc"
  Use a simple check for control speculation.  This option is on by default.
! .IP \fB\-msched\-stop\-bits\-after\-every\-cycle\fR 4
  .IX Item "-msched-stop-bits-after-every-cycle"
  Place a stop bit after every cycle when scheduling.  This option is on
  by default.
! .IP \fB\-msched\-fp\-mem\-deps\-zero\-cost\fR 4
  .IX Item "-msched-fp-mem-deps-zero-cost"
! Assume that floating\-point stores and loads are not likely to cause a conflict
  when placed into the same instruction group.  This option is disabled by
  default.
! .IP \fB\-msel\-sched\-dont\-check\-control\-spec\fR 4
  .IX Item "-msel-sched-dont-check-control-spec"
  Generate checks for control speculation in selective scheduling.
  This flag is disabled by default.
! .IP \fB\-msched\-max\-memory\-insns=\fR\fImax\-insns\fR 4
  .IX Item "-msched-max-memory-insns=max-insns"
  Limit on the number of memory insns per instruction group, giving lower
  priority to subsequent memory insns attempting to schedule in the same
  instruction group. Frequently useful to prevent cache bank conflicts.
  The default value is 1.
! .IP \fB\-msched\-max\-memory\-insns\-hard\-limit\fR 4
  .IX Item "-msched-max-memory-insns-hard-limit"
! Makes the limit specified by \fBmsched\-max\-memory\-insns\fR a hard limit,
  disallowing more than that number in an instruction group.
! Otherwise, the limit is "soft", meaning that non\-memory operations
  are preferred when the limit is reached, but memory operations may still
  be scheduled.
  .PP
! \fILM32 Options\fR
  .IX Subsection "LM32 Options"
  .PP
  These \fB\-m\fR options are defined for the LatticeMico32 architecture:
! .IP \fB\-mbarrel\-shift\-enabled\fR 4
  .IX Item "-mbarrel-shift-enabled"
! Enable barrel\-shift instructions.
! .IP \fB\-mdivide\-enabled\fR 4
  .IX Item "-mdivide-enabled"
  Enable divide and modulus instructions.
! .IP \fB\-mmultiply\-enabled\fR 4
  .IX Item "-mmultiply-enabled"
  Enable multiply instructions.
! .IP \fB\-msign\-extend\-enabled\fR 4
  .IX Item "-msign-extend-enabled"
  Enable sign extend instructions.
! .IP \fB\-muser\-enabled\fR 4
  .IX Item "-muser-enabled"
! Enable user\-defined instructions.
  .PP
  \fILoongArch Options\fR
  .IX Subsection "LoongArch Options"
  .PP
! These command\-line options are defined for LoongArch targets:
! .IP \fB\-march=\fR\fIcpu\-type\fR 4
  .IX Item "-march=cpu-type"
! Generate instructions for the machine type \fIcpu\-type\fR.  In contrast to
! \&\fB\-mtune=\fR\fIcpu\-type\fR, which merely tunes the generated code
! for the specified \fIcpu\-type\fR, \fB\-march=\fR\fIcpu\-type\fR allows GCC
  to generate code that may not run at all on processors other than the one
! indicated.  Specifying \fB\-march=\fR\fIcpu\-type\fR implies
! \&\fB\-mtune=\fR\fIcpu\-type\fR, except where noted otherwise.
  .Sp
! The choices for \fIcpu\-type\fR are:
  .RS 4
! .IP \fBnative\fR 4
  .IX Item "native"
! This selects the CPU to generate code for at compilation time by determining
  the processor type of the compiling machine.  Using \fB\-march=native\fR
  enables all instruction subsets supported by the local machine (hence
  the result might not run on different machines).  Using \fB\-mtune=native\fR
  produces code optimized for the local machine under the constraints
  of the selected instruction set.
! .IP \fBloongarch64\fR 4
  .IX Item "loongarch64"
! A generic CPU with 64\-bit extensions.
! .IP \fBla464\fR 4
  .IX Item "la464"
! LoongArch LA464 CPU with LBT, LSX, LASX, LVZ.
  .RE
  .RS 4
  .RE
! .IP \fB\-mtune=\fR\fIcpu\-type\fR 4
  .IX Item "-mtune=cpu-type"
  Optimize the output for the given processor, specified by microarchitecture
  name.
! .IP \fB\-mabi=\fR\fIbase\-abi\-type\fR 4
  .IX Item "-mabi=base-abi-type"
  Generate code for the specified calling convention.
! \&\fIbase\-abi\-type\fR can be one of:
  .RS 4
! .IP \fBlp64d\fR 4
  .IX Item "lp64d"
! Uses 64\-bit general purpose registers and 32/64\-bit floating\-point
! registers for parameter passing.  Data model is LP64, where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
! .IP \fBlp64f\fR 4
  .IX Item "lp64f"
! Uses 64\-bit general purpose registers and 32\-bit floating\-point
! registers for parameter passing.  Data model is LP64, where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
! .IP \fBlp64s\fR 4
  .IX Item "lp64s"
! Uses 64\-bit general purpose registers and no floating\-point
! registers for parameter passing.  Data model is LP64, where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
  .RE
  .RS 4
  .RE
! .IP \fB\-mfpu=\fR\fIfpu\-type\fR 4
  .IX Item "-mfpu=fpu-type"
! Generate code for the specified FPU type, which can be one of:
  .RS 4
! .IP \fB64\fR 4
  .IX Item "64"
! Allow the use of hardware floating\-point instructions for 32\-bit
  and 64\-bit operations.
! .IP \fB32\fR 4
  .IX Item "32"
! Allow the use of hardware floating\-point instructions for 32\-bit
  operations.
! .IP \fBnone\fR 4
  .IX Item "none"
  .PD 0
! .IP \fB0\fR 4
  .IX Item "0"
  .PD
! Prevent the use of hardware floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
! Force \fB\-mfpu=none\fR and prevents the use of floating\-point
  registers for parameter passing.  This option may change the target
! ABI.
! .IP \fB\-msingle\-float\fR 4
  .IX Item "-msingle-float"
! Force \fB\-mfpu=32\fR and allow the use of 32\-bit floating\-point
  registers for parameter passing.  This option may change the target
! ABI.
! .IP \fB\-mdouble\-float\fR 4
  .IX Item "-mdouble-float"
! Force \fB\-mfpu=64\fR and allow the use of 32/64\-bit floating\-point
  registers for parameter passing.  This option may change the target
! ABI.
! .IP \fB\-mbranch\-cost=\fR\fIn\fR 4
  .IX Item "-mbranch-cost=n"
  Set the cost of branches to roughly \fIn\fR instructions.
! .IP \fB\-mcheck\-zero\-division\fR 4
  .IX Item "-mcheck-zero-division"
  .PD 0
! .IP \fB\-mno\-check\-zero\-divison\fR 4
  .IX Item "-mno-check-zero-divison"
  .PD
  Trap (do not trap) on integer division by zero.  The default is
  \&\fB\-mcheck\-zero\-division\fR for \fB\-O0\fR or \fB\-Og\fR, and
  \&\fB\-mno\-check\-zero\-division\fR for other optimization levels.
! .IP \fB\-mcond\-move\-int\fR 4
  .IX Item "-mcond-move-int"
  .PD 0
! .IP \fB\-mno\-cond\-move\-int\fR 4
  .IX Item "-mno-cond-move-int"
  .PD
! Conditional moves for integral data in general\-purpose registers
  are enabled (disabled).  The default is \fB\-mcond\-move\-int\fR.
! .IP \fB\-mcond\-move\-float\fR 4
  .IX Item "-mcond-move-float"
  .PD 0
! .IP \fB\-mno\-cond\-move\-float\fR 4
  .IX Item "-mno-cond-move-float"
  .PD
! Conditional moves for floating\-point registers are enabled (disabled).
  The default is \fB\-mcond\-move\-float\fR.
! .IP \fB\-mmemcpy\fR 4
  .IX Item "-mmemcpy"
  .PD 0
! .IP \fB\-mno\-memcpy\fR 4
  .IX Item "-mno-memcpy"
  .PD
! Force (do not force) the use of \f(CW\*(C`memcpy\*(C'\fR for non\-trivial block moves.
! The default is \fB\-mno\-memcpy\fR, which allows GCC to inline most
! constant\-sized copies.  Setting optimization level to \fB\-Os\fR also
  forces the use of \f(CW\*(C`memcpy\*(C'\fR, but \fB\-mno\-memcpy\fR may override this
  behavior if explicitly specified, regardless of the order these options on
  the command line.
! .IP \fB\-mstrict\-align\fR 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP \fB\-mno\-strict\-align\fR 4
  .IX Item "-mno-strict-align"
  .PD
  Avoid or allow generating memory accesses that may not be aligned on a natural
  object boundary as described in the architecture specification. The default is
  \&\fB\-mno\-strict\-align\fR.
! .IP \fB\-msmall\-data\-limit=\fR\fInumber\fR 4
  .IX Item "-msmall-data-limit=number"
  Put global and static data smaller than \fInumber\fR bytes into a special
  section (on some targets).  The default value is 0.
! .IP \fB\-mmax\-inline\-memcpy\-size=\fR\fIn\fR 4
  .IX Item "-mmax-inline-memcpy-size=n"
  Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure copies)
  less than or equal to \fIn\fR bytes.  The default value of \fIn\fR is 1024.
! .IP \fB\-mcmodel=\fR\fIcode\-model\fR 4
  .IX Item "-mcmodel=code-model"
  Set the code model to one of:
  .RS 4
! .IP "\fBtiny\-static (Not implemented yet)\fR" 4
  .IX Item "tiny-static (Not implemented yet)"
  .PD 0
  .IP "\fBtiny (Not implemented yet)\fR" 4
  .IX Item "tiny (Not implemented yet)"
! .IP \fBnormal\fR 4
  .IX Item "normal"
  .PD
  The text segment must be within 128MB addressing space.  The data segment must
  be within 2GB addressing space.
! .IP \fBmedium\fR 4
  .IX Item "medium"
  The text segment and data segment must be within 2GB addressing space.
  .IP "\fBlarge (Not implemented yet)\fR" 4
  .IX Item "large (Not implemented yet)"
  .PD 0
! .IP \fBextreme\fR 4
  .IX Item "extreme"
  .PD
  This mode does not limit the size of the code segment and data segment.
*************** The \fB\-mcmodel=extreme\fR option is in
*** 25082,25184 ****
  .Sp
  The default code model is \f(CW\*(C`normal\*(C'\fR.
  .RE
! .IP "\fB\-mexplicit\-relocs\fR" 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP "\fB\-mno\-explicit\-relocs\fR" 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Use or do not use assembler relocation operators when dealing with symbolic
  addresses.  The alternative is to use assembler macros instead, which may
  limit instruction scheduling but allow linker relaxation.  The default
  value for the option is determined with the assembler capability detected
! during \s-1GCC\s0 build-time and the setting of \f(CW\*(C`\-mrelax\*(C'\fR:
  \&\f(CW\*(C`\-mexplicit\-relocs\*(C'\fR if the assembler supports relocation operators
  but \f(CW\*(C`\-mrelax\*(C'\fR is not enabled, \f(CW\*(C`\-mno\-explicit\-relocs\*(C'\fR otherwise.
! .IP "\fB\-mdirect\-extern\-access\fR" 4
  .IX Item "-mdirect-extern-access"
  .PD 0
! .IP "\fB\-mno\-direct\-extern\-access\fR" 4
  .IX Item "-mno-direct-extern-access"
  .PD
! Do not use or use \s-1GOT\s0 to access external symbols.  The default is
! \&\fB\-mno\-direct\-extern\-access\fR: \s-1GOT\s0 is used for external symbols with
  default visibility, but not used for other external symbols.
  .Sp
! With \fB\-mdirect\-extern\-access\fR, \s-1GOT\s0 is not used and all external
! symbols are PC-relatively addressed.  It is \fBonly\fR suitable for
! environments where no dynamic link is performed, like firmwares, \s-1OS\s0
  kernels, executables linked with \fB\-static\fR or \fB\-static\-pie\fR.
  \&\fB\-mdirect\-extern\-access\fR is not compatible with \fB\-fPIC\fR or
  \&\fB\-fpic\fR.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  .PD 0
! .IP "\fB\-mno\-relax\fR" 4
  .IX Item "-mno-relax"
  .PD
  Take (do not take) advantage of linker relaxations.  If
  \&\fB\-mpass\-mrelax\-to\-as\fR is enabled, this option is also passed to
! the assembler.  The default is determined during \s-1GCC\s0 build-time by
  detecting corresponding assembler support:
  \&\fB\-mrelax\fR if the assembler supports both the \fB\-mrelax\fR
! option and the conditional branch relaxation (it's required or the
  \&\f(CW\*(C`.align\*(C'\fR directives and conditional branch instructions in the
! assembly code outputted by \s-1GCC\s0 may be rejected by the assembler because
  of a relocation overflow), \fB\-mno\-relax\fR otherwise.
! .IP "\fB\-mpass\-mrelax\-to\-as\fR" 4
  .IX Item "-mpass-mrelax-to-as"
  .PD 0
! .IP "\fB\-mno\-pass\-mrelax\-to\-as\fR" 4
  .IX Item "-mno-pass-mrelax-to-as"
  .PD
  Pass (do not pass) the \fB\-mrelax\fR or \fB\-mno\-relax\fR option
! to the assembler.  The default is determined during \s-1GCC\s0 build-time by
  detecting corresponding assembler support:
  \&\fB\-mpass\-mrelax\-to\-as\fR if the assembler supports the
  \&\fB\-mrelax\fR option, \fB\-mno\-pass\-mrelax\-to\-as\fR otherwise.
  This option is mostly useful for debugging, or interoperation with
! assemblers different from the build-time one.
  .PP
  \fIM32C Options\fR
  .IX Subsection "M32C Options"
! .IP "\fB\-mcpu=\fR\fIname\fR" 4
  .IX Item "-mcpu=name"
! Select the \s-1CPU\s0 for which code is generated.  \fIname\fR may be one of
  \&\fBr8c\fR for the R8C/Tiny series, \fBm16c\fR for the M16C (up to
  /60) series, \fBm32cm\fR for the M16C/80 series, or \fBm32c\fR for
  the M32C/80 series.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
  an alternate runtime library to be linked in which supports, for
  example, file I/O.  You must not use this option when generating
  programs that will run on real hardware; you must provide your own
  runtime library for whatever I/O functions are needed.
! .IP "\fB\-memregs=\fR\fInumber\fR" 4
  .IX Item "-memregs=number"
! Specifies the number of memory-based pseudo-registers \s-1GCC\s0 uses
! during code generation.  These pseudo-registers are used like real
! registers, so there is a tradeoff between \s-1GCC\s0's ability to fit the
  code into available registers, and the performance penalty of using
  memory instead of registers.  Note that all modules in a program must
  be compiled with the same value for this option.  Because of that, you
! must not use this option with \s-1GCC\s0's default runtime libraries.
  .PP
  \fIM32R/D Options\fR
  .IX Subsection "M32R/D Options"
  .PP
  These \fB\-m\fR options are defined for Renesas M32R/D architectures:
! .IP "\fB\-m32r2\fR" 4
  .IX Item "-m32r2"
  Generate code for the M32R/2.
! .IP "\fB\-m32rx\fR" 4
  .IX Item "-m32rx"
  Generate code for the M32R/X.
! .IP "\fB\-m32r\fR" 4
  .IX Item "-m32r"
  Generate code for the M32R.  This is the default.
! .IP "\fB\-mmodel=small\fR" 4
  .IX Item "-mmodel=small"
  Assume all objects live in the lower 16MB of memory (so that their addresses
  can be loaded with the \f(CW\*(C`ld24\*(C'\fR instruction), and assume all subroutines
--- 25013,25115 ----
  .Sp
  The default code model is \f(CW\*(C`normal\*(C'\fR.
  .RE
! .IP \fB\-mexplicit\-relocs\fR 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP \fB\-mno\-explicit\-relocs\fR 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Use or do not use assembler relocation operators when dealing with symbolic
  addresses.  The alternative is to use assembler macros instead, which may
  limit instruction scheduling but allow linker relaxation.  The default
  value for the option is determined with the assembler capability detected
! during GCC build\-time and the setting of \f(CW\*(C`\-mrelax\*(C'\fR:
  \&\f(CW\*(C`\-mexplicit\-relocs\*(C'\fR if the assembler supports relocation operators
  but \f(CW\*(C`\-mrelax\*(C'\fR is not enabled, \f(CW\*(C`\-mno\-explicit\-relocs\*(C'\fR otherwise.
! .IP \fB\-mdirect\-extern\-access\fR 4
  .IX Item "-mdirect-extern-access"
  .PD 0
! .IP \fB\-mno\-direct\-extern\-access\fR 4
  .IX Item "-mno-direct-extern-access"
  .PD
! Do not use or use GOT to access external symbols.  The default is
! \&\fB\-mno\-direct\-extern\-access\fR: GOT is used for external symbols with
  default visibility, but not used for other external symbols.
  .Sp
! With \fB\-mdirect\-extern\-access\fR, GOT is not used and all external
! symbols are PC\-relatively addressed.  It is \fBonly\fR suitable for
! environments where no dynamic link is performed, like firmwares, OS
  kernels, executables linked with \fB\-static\fR or \fB\-static\-pie\fR.
  \&\fB\-mdirect\-extern\-access\fR is not compatible with \fB\-fPIC\fR or
  \&\fB\-fpic\fR.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  .PD 0
! .IP \fB\-mno\-relax\fR 4
  .IX Item "-mno-relax"
  .PD
  Take (do not take) advantage of linker relaxations.  If
  \&\fB\-mpass\-mrelax\-to\-as\fR is enabled, this option is also passed to
! the assembler.  The default is determined during GCC build\-time by
  detecting corresponding assembler support:
  \&\fB\-mrelax\fR if the assembler supports both the \fB\-mrelax\fR
! option and the conditional branch relaxation (it\*(Aqs required or the
  \&\f(CW\*(C`.align\*(C'\fR directives and conditional branch instructions in the
! assembly code outputted by GCC may be rejected by the assembler because
  of a relocation overflow), \fB\-mno\-relax\fR otherwise.
! .IP \fB\-mpass\-mrelax\-to\-as\fR 4
  .IX Item "-mpass-mrelax-to-as"
  .PD 0
! .IP \fB\-mno\-pass\-mrelax\-to\-as\fR 4
  .IX Item "-mno-pass-mrelax-to-as"
  .PD
  Pass (do not pass) the \fB\-mrelax\fR or \fB\-mno\-relax\fR option
! to the assembler.  The default is determined during GCC build\-time by
  detecting corresponding assembler support:
  \&\fB\-mpass\-mrelax\-to\-as\fR if the assembler supports the
  \&\fB\-mrelax\fR option, \fB\-mno\-pass\-mrelax\-to\-as\fR otherwise.
  This option is mostly useful for debugging, or interoperation with
! assemblers different from the build\-time one.
  .PP
  \fIM32C Options\fR
  .IX Subsection "M32C Options"
! .IP \fB\-mcpu=\fR\fIname\fR 4
  .IX Item "-mcpu=name"
! Select the CPU for which code is generated.  \fIname\fR may be one of
  \&\fBr8c\fR for the R8C/Tiny series, \fBm16c\fR for the M16C (up to
  /60) series, \fBm32cm\fR for the M16C/80 series, or \fBm32c\fR for
  the M32C/80 series.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
  an alternate runtime library to be linked in which supports, for
  example, file I/O.  You must not use this option when generating
  programs that will run on real hardware; you must provide your own
  runtime library for whatever I/O functions are needed.
! .IP \fB\-memregs=\fR\fInumber\fR 4
  .IX Item "-memregs=number"
! Specifies the number of memory\-based pseudo\-registers GCC uses
! during code generation.  These pseudo\-registers are used like real
! registers, so there is a tradeoff between GCC\*(Aqs ability to fit the
  code into available registers, and the performance penalty of using
  memory instead of registers.  Note that all modules in a program must
  be compiled with the same value for this option.  Because of that, you
! must not use this option with GCC\*(Aqs default runtime libraries.
  .PP
  \fIM32R/D Options\fR
  .IX Subsection "M32R/D Options"
  .PP
  These \fB\-m\fR options are defined for Renesas M32R/D architectures:
! .IP \fB\-m32r2\fR 4
  .IX Item "-m32r2"
  Generate code for the M32R/2.
! .IP \fB\-m32rx\fR 4
  .IX Item "-m32rx"
  Generate code for the M32R/X.
! .IP \fB\-m32r\fR 4
  .IX Item "-m32r"
  Generate code for the M32R.  This is the default.
! .IP \fB\-mmodel=small\fR 4
  .IX Item "-mmodel=small"
  Assume all objects live in the lower 16MB of memory (so that their addresses
  can be loaded with the \f(CW\*(C`ld24\*(C'\fR instruction), and assume all subroutines
*************** This is the default.
*** 25187,25205 ****
  .Sp
  The addressability of a particular object can be set with the
  \&\f(CW\*(C`model\*(C'\fR attribute.
! .IP "\fB\-mmodel=medium\fR" 4
  .IX Item "-mmodel=medium"
  Assume objects may be anywhere in the 32\-bit address space (the compiler
  generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
  assume all subroutines are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
! .IP "\fB\-mmodel=large\fR" 4
  .IX Item "-mmodel=large"
  Assume objects may be anywhere in the 32\-bit address space (the compiler
  generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
  assume subroutines may not be reachable with the \f(CW\*(C`bl\*(C'\fR instruction
  (the compiler generates the much slower \f(CW\*(C`seth/add3/jl\*(C'\fR
  instruction sequence).
! .IP "\fB\-msdata=none\fR" 4
  .IX Item "-msdata=none"
  Disable use of the small data area.  Variables are put into
  one of \f(CW\*(C`.data\*(C'\fR, \f(CW\*(C`.bss\*(C'\fR, or \f(CW\*(C`.rodata\*(C'\fR (unless the
--- 25118,25136 ----
  .Sp
  The addressability of a particular object can be set with the
  \&\f(CW\*(C`model\*(C'\fR attribute.
! .IP \fB\-mmodel=medium\fR 4
  .IX Item "-mmodel=medium"
  Assume objects may be anywhere in the 32\-bit address space (the compiler
  generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
  assume all subroutines are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
! .IP \fB\-mmodel=large\fR 4
  .IX Item "-mmodel=large"
  Assume objects may be anywhere in the 32\-bit address space (the compiler
  generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
  assume subroutines may not be reachable with the \f(CW\*(C`bl\*(C'\fR instruction
  (the compiler generates the much slower \f(CW\*(C`seth/add3/jl\*(C'\fR
  instruction sequence).
! .IP \fB\-msdata=none\fR 4
  .IX Item "-msdata=none"
  Disable use of the small data area.  Variables are put into
  one of \f(CW\*(C`.data\*(C'\fR, \f(CW\*(C`.bss\*(C'\fR, or \f(CW\*(C`.rodata\*(C'\fR (unless the
*************** This is the default.
*** 25209,25267 ****
  The small data area consists of sections \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR.
  Objects may be explicitly put in the small data area with the
  \&\f(CW\*(C`section\*(C'\fR attribute using one of these sections.
! .IP "\fB\-msdata=sdata\fR" 4
  .IX Item "-msdata=sdata"
  Put small global and static data in the small data area, but do not
  generate special code to reference them.
! .IP "\fB\-msdata=use\fR" 4
  .IX Item "-msdata=use"
  Put small global and static data in the small data area, and generate
  special instructions to reference them.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  Put global and static objects less than or equal to \fInum\fR bytes
! into the small data or \s-1BSS\s0 sections instead of the normal data or \s-1BSS\s0
  sections.  The default value of \fInum\fR is 8.
  The \fB\-msdata\fR option must be set to one of \fBsdata\fR or \fBuse\fR
  for this option to have any effect.
  .Sp
  All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
  Compiling with different values of \fInum\fR may or may not work; if it
! doesn't the linker gives an error message\-\-\-incorrect code is not
  generated.
! .IP "\fB\-mdebug\fR" 4
  .IX Item "-mdebug"
  Makes the M32R\-specific code in the compiler display some statistics
  that might help in debugging programs.
! .IP "\fB\-malign\-loops\fR" 4
  .IX Item "-malign-loops"
  Align all loops to a 32\-byte boundary.
! .IP "\fB\-mno\-align\-loops\fR" 4
  .IX Item "-mno-align-loops"
  Do not enforce a 32\-byte alignment for loops.  This is the default.
! .IP "\fB\-missue\-rate=\fR\fInumber\fR" 4
  .IX Item "-missue-rate=number"
  Issue \fInumber\fR instructions per cycle.  \fInumber\fR can only be 1
  or 2.
! .IP "\fB\-mbranch\-cost=\fR\fInumber\fR" 4
  .IX Item "-mbranch-cost=number"
  \&\fInumber\fR can only be 1 or 2.  If it is 1 then branches are
  preferred over conditional code, if it is 2, then the opposite applies.
! .IP "\fB\-mflush\-trap=\fR\fInumber\fR" 4
  .IX Item "-mflush-trap=number"
  Specifies the trap number to use to flush the cache.  The default is
  12.  Valid numbers are between 0 and 15 inclusive.
! .IP "\fB\-mno\-flush\-trap\fR" 4
  .IX Item "-mno-flush-trap"
  Specifies that the cache cannot be flushed by using a trap.
! .IP "\fB\-mflush\-func=\fR\fIname\fR" 4
  .IX Item "-mflush-func=name"
  Specifies the name of the operating system function to call to flush
  the cache.  The default is \fB_flush_cache\fR, but a function call
  is only used if a trap is not available.
! .IP "\fB\-mno\-flush\-func\fR" 4
  .IX Item "-mno-flush-func"
! Indicates that there is no \s-1OS\s0 function for flushing the cache.
  .PP
  \fIM680x0 Options\fR
  .IX Subsection "M680x0 Options"
--- 25140,25198 ----
  The small data area consists of sections \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR.
  Objects may be explicitly put in the small data area with the
  \&\f(CW\*(C`section\*(C'\fR attribute using one of these sections.
! .IP \fB\-msdata=sdata\fR 4
  .IX Item "-msdata=sdata"
  Put small global and static data in the small data area, but do not
  generate special code to reference them.
! .IP \fB\-msdata=use\fR 4
  .IX Item "-msdata=use"
  Put small global and static data in the small data area, and generate
  special instructions to reference them.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  Put global and static objects less than or equal to \fInum\fR bytes
! into the small data or BSS sections instead of the normal data or BSS
  sections.  The default value of \fInum\fR is 8.
  The \fB\-msdata\fR option must be set to one of \fBsdata\fR or \fBuse\fR
  for this option to have any effect.
  .Sp
  All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
  Compiling with different values of \fInum\fR may or may not work; if it
! doesn\*(Aqt the linker gives an error message\-\-\-incorrect code is not
  generated.
! .IP \fB\-mdebug\fR 4
  .IX Item "-mdebug"
  Makes the M32R\-specific code in the compiler display some statistics
  that might help in debugging programs.
! .IP \fB\-malign\-loops\fR 4
  .IX Item "-malign-loops"
  Align all loops to a 32\-byte boundary.
! .IP \fB\-mno\-align\-loops\fR 4
  .IX Item "-mno-align-loops"
  Do not enforce a 32\-byte alignment for loops.  This is the default.
! .IP \fB\-missue\-rate=\fR\fInumber\fR 4
  .IX Item "-missue-rate=number"
  Issue \fInumber\fR instructions per cycle.  \fInumber\fR can only be 1
  or 2.
! .IP \fB\-mbranch\-cost=\fR\fInumber\fR 4
  .IX Item "-mbranch-cost=number"
  \&\fInumber\fR can only be 1 or 2.  If it is 1 then branches are
  preferred over conditional code, if it is 2, then the opposite applies.
! .IP \fB\-mflush\-trap=\fR\fInumber\fR 4
  .IX Item "-mflush-trap=number"
  Specifies the trap number to use to flush the cache.  The default is
  12.  Valid numbers are between 0 and 15 inclusive.
! .IP \fB\-mno\-flush\-trap\fR 4
  .IX Item "-mno-flush-trap"
  Specifies that the cache cannot be flushed by using a trap.
! .IP \fB\-mflush\-func=\fR\fIname\fR 4
  .IX Item "-mflush-func=name"
  Specifies the name of the operating system function to call to flush
  the cache.  The default is \fB_flush_cache\fR, but a function call
  is only used if a trap is not available.
! .IP \fB\-mno\-flush\-func\fR 4
  .IX Item "-mno-flush-func"
! Indicates that there is no OS function for flushing the cache.
  .PP
  \fIM680x0 Options\fR
  .IX Subsection "M680x0 Options"
*************** These are the \fB\-m\fR options defined
*** 25270,25293 ****
  The default settings depend on which architecture was selected when
  the compiler was configured; the defaults for the most common choices
  are given below.
! .IP "\fB\-march=\fR\fIarch\fR" 4
  .IX Item "-march=arch"
  Generate code for a specific M680x0 or ColdFire instruction set
  architecture.  Permissible values of \fIarch\fR for M680x0
  architectures are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
  \&\fB68030\fR, \fB68040\fR, \fB68060\fR and \fBcpu32\fR.  ColdFire
! architectures are selected according to Freescale's \s-1ISA\s0 classification
  and the permissible values are: \fBisaa\fR, \fBisaaplus\fR,
  \&\fBisab\fR and \fBisac\fR.
  .Sp
! \&\s-1GCC\s0 defines a macro \f(CW\*(C`_\|_mcf\f(CIarch\f(CW_\|_\*(C'\fR whenever it is generating
  code for a ColdFire target.  The \fIarch\fR in this macro is one of the
  \&\fB\-march\fR arguments given above.
  .Sp
  When used together, \fB\-march\fR and \fB\-mtune\fR select code
  that runs on a family of similar processors but that is optimized
  for a particular microarchitecture.
! .IP "\fB\-mcpu=\fR\fIcpu\fR" 4
  .IX Item "-mcpu=cpu"
  Generate code for a specific M680x0 or ColdFire processor.
  The M680x0 \fIcpu\fRs are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
--- 25201,25224 ----
  The default settings depend on which architecture was selected when
  the compiler was configured; the defaults for the most common choices
  are given below.
! .IP \fB\-march=\fR\fIarch\fR 4
  .IX Item "-march=arch"
  Generate code for a specific M680x0 or ColdFire instruction set
  architecture.  Permissible values of \fIarch\fR for M680x0
  architectures are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
  \&\fB68030\fR, \fB68040\fR, \fB68060\fR and \fBcpu32\fR.  ColdFire
! architectures are selected according to Freescale\*(Aqs ISA classification
  and the permissible values are: \fBisaa\fR, \fBisaaplus\fR,
  \&\fBisab\fR and \fBisac\fR.
  .Sp
! GCC defines a macro \f(CW\*(C`_\|_mcf\fR\f(CIarch\fR\f(CW_\|_\*(C'\fR whenever it is generating
  code for a ColdFire target.  The \fIarch\fR in this macro is one of the
  \&\fB\-march\fR arguments given above.
  .Sp
  When used together, \fB\-march\fR and \fB\-mtune\fR select code
  that runs on a family of similar processors but that is optimized
  for a particular microarchitecture.
! .IP \fB\-mcpu=\fR\fIcpu\fR 4
  .IX Item "-mcpu=cpu"
  Generate code for a specific M680x0 or ColdFire processor.
  The M680x0 \fIcpu\fRs are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
*************** below, which also classifies the CPUs in
*** 25344,25362 ****
  .IX Item "5407 : 5407"
  .IP "\fB5475\fR : \fB5470\fR \fB5471\fR \fB5472\fR \fB5473\fR \fB5474\fR \fB5475\fR \fB547x\fR \fB5480\fR \fB5481\fR \fB5482\fR \fB5483\fR \fB5484\fR \fB5485\fR" 4
  .IX Item "5475 : 5470 5471 5472 5473 5474 5475 547x 5480 5481 5482 5483 5484 5485"
  .RE
  .RS 4
- .PD
  .Sp
  \&\fB\-mcpu=\fR\fIcpu\fR overrides \fB\-march=\fR\fIarch\fR if
  \&\fIarch\fR is compatible with \fIcpu\fR.  Other combinations of
  \&\fB\-mcpu\fR and \fB\-march\fR are rejected.
  .Sp
! \&\s-1GCC\s0 defines the macro \f(CW\*(C`_\|_mcf_cpu_\f(CIcpu\f(CW\*(C'\fR when ColdFire target
! \&\fIcpu\fR is selected.  It also defines \f(CW\*(C`_\|_mcf_family_\f(CIfamily\f(CW\*(C'\fR,
  where the value of \fIfamily\fR is given by the table above.
  .RE
! .IP "\fB\-mtune=\fR\fItune\fR" 4
  .IX Item "-mtune=tune"
  Tune the code for a particular microarchitecture within the
  constraints set by \fB\-march\fR and \fB\-mcpu\fR.
--- 25275,25293 ----
  .IX Item "5407 : 5407"
  .IP "\fB5475\fR : \fB5470\fR \fB5471\fR \fB5472\fR \fB5473\fR \fB5474\fR \fB5475\fR \fB547x\fR \fB5480\fR \fB5481\fR \fB5482\fR \fB5483\fR \fB5484\fR \fB5485\fR" 4
  .IX Item "5475 : 5470 5471 5472 5473 5474 5475 547x 5480 5481 5482 5483 5484 5485"
+ .PD
  .RE
  .RS 4
  .Sp
  \&\fB\-mcpu=\fR\fIcpu\fR overrides \fB\-march=\fR\fIarch\fR if
  \&\fIarch\fR is compatible with \fIcpu\fR.  Other combinations of
  \&\fB\-mcpu\fR and \fB\-march\fR are rejected.
  .Sp
! GCC defines the macro \f(CW\*(C`_\|_mcf_cpu_\fR\f(CIcpu\fR\f(CW\*(C'\fR when ColdFire target
! \&\fIcpu\fR is selected.  It also defines \f(CW\*(C`_\|_mcf_family_\fR\f(CIfamily\fR\f(CW\*(C'\fR,
  where the value of \fIfamily\fR is given by the table above.
  .RE
! .IP \fB\-mtune=\fR\fItune\fR 4
  .IX Item "-mtune=tune"
  Tune the code for a particular microarchitecture within the
  constraints set by \fB\-march\fR and \fB\-mcpu\fR.
*************** to run relatively well on 68020, 68030 a
*** 25371,25418 ****
  as well.  These two options select the same tuning decisions as
  \&\fB\-m68020\-40\fR and \fB\-m68020\-60\fR respectively.
  .Sp
! \&\s-1GCC\s0 defines the macros \f(CW\*(C`_\|_mc\f(CIarch\f(CW\*(C'\fR and \f(CW\*(C`_\|_mc\f(CIarch\f(CW_\|_\*(C'\fR
  when tuning for 680x0 architecture \fIarch\fR.  It also defines
! \&\f(CW\*(C`mc\f(CIarch\f(CW\*(C'\fR unless either \fB\-ansi\fR or a non-GNU \fB\-std\fR
! option is used.  If \s-1GCC\s0 is tuning for a range of architectures,
  as selected by \fB\-mtune=68020\-40\fR or \fB\-mtune=68020\-60\fR,
  it defines the macros for every architecture in the range.
  .Sp
! \&\s-1GCC\s0 also defines the macro \f(CW\*(C`_\|_m\f(CIuarch\f(CW_\|_\*(C'\fR when tuning for
  ColdFire microarchitecture \fIuarch\fR, where \fIuarch\fR is one
  of the arguments given above.
! .IP "\fB\-m68000\fR" 4
  .IX Item "-m68000"
  .PD 0
! .IP "\fB\-mc68000\fR" 4
  .IX Item "-mc68000"
  .PD
  Generate output for a 68000.  This is the default
  when the compiler is configured for 68000\-based systems.
  It is equivalent to \fB\-march=68000\fR.
  .Sp
! Use this option for microcontrollers with a 68000 or \s-1EC000\s0 core,
  including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
! .IP "\fB\-m68010\fR" 4
  .IX Item "-m68010"
  Generate output for a 68010.  This is the default
  when the compiler is configured for 68010\-based systems.
  It is equivalent to \fB\-march=68010\fR.
! .IP "\fB\-m68020\fR" 4
  .IX Item "-m68020"
  .PD 0
! .IP "\fB\-mc68020\fR" 4
  .IX Item "-mc68020"
  .PD
  Generate output for a 68020.  This is the default
  when the compiler is configured for 68020\-based systems.
  It is equivalent to \fB\-march=68020\fR.
! .IP "\fB\-m68030\fR" 4
  .IX Item "-m68030"
  Generate output for a 68030.  This is the default when the compiler is
  configured for 68030\-based systems.  It is equivalent to
  \&\fB\-march=68030\fR.
! .IP "\fB\-m68040\fR" 4
  .IX Item "-m68040"
  Generate output for a 68040.  This is the default when the compiler is
  configured for 68040\-based systems.  It is equivalent to
--- 25302,25349 ----
  as well.  These two options select the same tuning decisions as
  \&\fB\-m68020\-40\fR and \fB\-m68020\-60\fR respectively.
  .Sp
! GCC defines the macros \f(CW\*(C`_\|_mc\fR\f(CIarch\fR\f(CW\*(C'\fR and \f(CW\*(C`_\|_mc\fR\f(CIarch\fR\f(CW_\|_\*(C'\fR
  when tuning for 680x0 architecture \fIarch\fR.  It also defines
! \&\f(CW\*(C`mc\fR\f(CIarch\fR\f(CW\*(C'\fR unless either \fB\-ansi\fR or a non\-GNU \fB\-std\fR
! option is used.  If GCC is tuning for a range of architectures,
  as selected by \fB\-mtune=68020\-40\fR or \fB\-mtune=68020\-60\fR,
  it defines the macros for every architecture in the range.
  .Sp
! GCC also defines the macro \f(CW\*(C`_\|_m\fR\f(CIuarch\fR\f(CW_\|_\*(C'\fR when tuning for
  ColdFire microarchitecture \fIuarch\fR, where \fIuarch\fR is one
  of the arguments given above.
! .IP \fB\-m68000\fR 4
  .IX Item "-m68000"
  .PD 0
! .IP \fB\-mc68000\fR 4
  .IX Item "-mc68000"
  .PD
  Generate output for a 68000.  This is the default
  when the compiler is configured for 68000\-based systems.
  It is equivalent to \fB\-march=68000\fR.
  .Sp
! Use this option for microcontrollers with a 68000 or EC000 core,
  including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
! .IP \fB\-m68010\fR 4
  .IX Item "-m68010"
  Generate output for a 68010.  This is the default
  when the compiler is configured for 68010\-based systems.
  It is equivalent to \fB\-march=68010\fR.
! .IP \fB\-m68020\fR 4
  .IX Item "-m68020"
  .PD 0
! .IP \fB\-mc68020\fR 4
  .IX Item "-mc68020"
  .PD
  Generate output for a 68020.  This is the default
  when the compiler is configured for 68020\-based systems.
  It is equivalent to \fB\-march=68020\fR.
! .IP \fB\-m68030\fR 4
  .IX Item "-m68030"
  Generate output for a 68030.  This is the default when the compiler is
  configured for 68030\-based systems.  It is equivalent to
  \&\fB\-march=68030\fR.
! .IP \fB\-m68040\fR 4
  .IX Item "-m68040"
  Generate output for a 68040.  This is the default when the compiler is
  configured for 68040\-based systems.  It is equivalent to
*************** configured for 68040\-based systems.  It
*** 25421,25427 ****
  This option inhibits the use of 68881/68882 instructions that have to be
  emulated by software on the 68040.  Use this option if your 68040 does not
  have code to emulate those instructions.
! .IP "\fB\-m68060\fR" 4
  .IX Item "-m68060"
  Generate output for a 68060.  This is the default when the compiler is
  configured for 68060\-based systems.  It is equivalent to
--- 25352,25358 ----
  This option inhibits the use of 68881/68882 instructions that have to be
  emulated by software on the 68040.  Use this option if your 68040 does not
  have code to emulate those instructions.
! .IP \fB\-m68060\fR 4
  .IX Item "-m68060"
  Generate output for a 68060.  This is the default when the compiler is
  configured for 68060\-based systems.  It is equivalent to
*************** configured for 68060\-based systems.  It
*** 25430,25477 ****
  This option inhibits the use of 68020 and 68881/68882 instructions that
  have to be emulated by software on the 68060.  Use this option if your 68060
  does not have code to emulate those instructions.
! .IP "\fB\-mcpu32\fR" 4
  .IX Item "-mcpu32"
! Generate output for a \s-1CPU32.\s0  This is the default
  when the compiler is configured for CPU32\-based systems.
  It is equivalent to \fB\-march=cpu32\fR.
  .Sp
  Use this option for microcontrollers with a
! \&\s-1CPU32\s0 or \s-1CPU32+\s0 core, including the 68330, 68331, 68332, 68333, 68334,
  68336, 68340, 68341, 68349 and 68360.
! .IP "\fB\-m5200\fR" 4
  .IX Item "-m5200"
! Generate output for a 520X ColdFire \s-1CPU.\s0  This is the default
  when the compiler is configured for 520X\-based systems.
  It is equivalent to \fB\-mcpu=5206\fR, and is now deprecated
  in favor of that option.
  .Sp
  Use this option for microcontroller with a 5200 core, including
! the \s-1MCF5202, MCF5203, MCF5204\s0 and \s-1MCF5206.\s0
! .IP "\fB\-m5206e\fR" 4
  .IX Item "-m5206e"
! Generate output for a 5206e ColdFire \s-1CPU.\s0  The option is now
  deprecated in favor of the equivalent \fB\-mcpu=5206e\fR.
! .IP "\fB\-m528x\fR" 4
  .IX Item "-m528x"
  Generate output for a member of the ColdFire 528X family.
  The option is now deprecated in favor of the equivalent
  \&\fB\-mcpu=528x\fR.
! .IP "\fB\-m5307\fR" 4
  .IX Item "-m5307"
! Generate output for a ColdFire 5307 \s-1CPU.\s0  The option is now deprecated
  in favor of the equivalent \fB\-mcpu=5307\fR.
! .IP "\fB\-m5407\fR" 4
  .IX Item "-m5407"
! Generate output for a ColdFire 5407 \s-1CPU.\s0  The option is now deprecated
  in favor of the equivalent \fB\-mcpu=5407\fR.
! .IP "\fB\-mcfv4e\fR" 4
  .IX Item "-mcfv4e"
! Generate output for a ColdFire V4e family \s-1CPU\s0 (e.g. 547x/548x).
! This includes use of hardware floating-point instructions.
  The option is equivalent to \fB\-mcpu=547x\fR, and is now
  deprecated in favor of that option.
! .IP "\fB\-m68020\-40\fR" 4
  .IX Item "-m68020-40"
  Generate output for a 68040, without using any of the new instructions.
  This results in code that can run relatively efficiently on either a
--- 25361,25408 ----
  This option inhibits the use of 68020 and 68881/68882 instructions that
  have to be emulated by software on the 68060.  Use this option if your 68060
  does not have code to emulate those instructions.
! .IP \fB\-mcpu32\fR 4
  .IX Item "-mcpu32"
! Generate output for a CPU32.  This is the default
  when the compiler is configured for CPU32\-based systems.
  It is equivalent to \fB\-march=cpu32\fR.
  .Sp
  Use this option for microcontrollers with a
! CPU32 or CPU32+ core, including the 68330, 68331, 68332, 68333, 68334,
  68336, 68340, 68341, 68349 and 68360.
! .IP \fB\-m5200\fR 4
  .IX Item "-m5200"
! Generate output for a 520X ColdFire CPU.  This is the default
  when the compiler is configured for 520X\-based systems.
  It is equivalent to \fB\-mcpu=5206\fR, and is now deprecated
  in favor of that option.
  .Sp
  Use this option for microcontroller with a 5200 core, including
! the MCF5202, MCF5203, MCF5204 and MCF5206.
! .IP \fB\-m5206e\fR 4
  .IX Item "-m5206e"
! Generate output for a 5206e ColdFire CPU.  The option is now
  deprecated in favor of the equivalent \fB\-mcpu=5206e\fR.
! .IP \fB\-m528x\fR 4
  .IX Item "-m528x"
  Generate output for a member of the ColdFire 528X family.
  The option is now deprecated in favor of the equivalent
  \&\fB\-mcpu=528x\fR.
! .IP \fB\-m5307\fR 4
  .IX Item "-m5307"
! Generate output for a ColdFire 5307 CPU.  The option is now deprecated
  in favor of the equivalent \fB\-mcpu=5307\fR.
! .IP \fB\-m5407\fR 4
  .IX Item "-m5407"
! Generate output for a ColdFire 5407 CPU.  The option is now deprecated
  in favor of the equivalent \fB\-mcpu=5407\fR.
! .IP \fB\-mcfv4e\fR 4
  .IX Item "-mcfv4e"
! Generate output for a ColdFire V4e family CPU (e.g. 547x/548x).
! This includes use of hardware floating\-point instructions.
  The option is equivalent to \fB\-mcpu=547x\fR, and is now
  deprecated in favor of that option.
! .IP \fB\-m68020\-40\fR 4
  .IX Item "-m68020-40"
  Generate output for a 68040, without using any of the new instructions.
  This results in code that can run relatively efficiently on either a
*************** This results in code that can run relati
*** 25479,25485 ****
  68881 instructions that are emulated on the 68040.
  .Sp
  The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-40\fR.
! .IP "\fB\-m68020\-60\fR" 4
  .IX Item "-m68020-60"
  Generate output for a 68060, without using any of the new instructions.
  This results in code that can run relatively efficiently on either a
--- 25410,25416 ----
  68881 instructions that are emulated on the 68040.
  .Sp
  The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-40\fR.
! .IP \fB\-m68020\-60\fR 4
  .IX Item "-m68020-60"
  Generate output for a 68060, without using any of the new instructions.
  This results in code that can run relatively efficiently on either a
*************** This results in code that can run relati
*** 25487,25546 ****
  68881 instructions that are emulated on the 68060.
  .Sp
  The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-60\fR.
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD 0
! .IP "\fB\-m68881\fR" 4
  .IX Item "-m68881"
  .PD
! Generate floating-point instructions.  This is the default for 68020
! and above, and for ColdFire devices that have an \s-1FPU.\s0  It defines the
  macro \f(CW\*(C`_\|_HAVE_68881_\|_\*(C'\fR on M680x0 targets and \f(CW\*(C`_\|_mcffpu_\|_\*(C'\fR
  on ColdFire targets.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
! Do not generate floating-point instructions; use library calls instead.
  This is the default for 68000, 68010, and 68832 targets.  It is also
! the default for ColdFire devices that have no \s-1FPU.\s0
! .IP "\fB\-mdiv\fR" 4
  .IX Item "-mdiv"
  .PD 0
! .IP "\fB\-mno\-div\fR" 4
  .IX Item "-mno-div"
  .PD
  Generate (do not generate) ColdFire hardware divide and remainder
  instructions.  If \fB\-march\fR is used without \fB\-mcpu\fR,
! the default is \*(L"on\*(R" for ColdFire architectures and \*(L"off\*(R" for M680x0
! architectures.  Otherwise, the default is taken from the target \s-1CPU\s0
! (either the default \s-1CPU,\s0 or the one specified by \fB\-mcpu\fR).  For
! example, the default is \*(L"off\*(R" for \fB\-mcpu=5206\fR and \*(L"on\*(R" for
  \&\fB\-mcpu=5206e\fR.
  .Sp
! \&\s-1GCC\s0 defines the macro \f(CW\*(C`_\|_mcfhwdiv_\|_\*(C'\fR when this option is enabled.
! .IP "\fB\-mshort\fR" 4
  .IX Item "-mshort"
  Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR.
  Additionally, parameters passed on the stack are also aligned to a
! 16\-bit boundary even on targets whose \s-1API\s0 mandates promotion to 32\-bit.
! .IP "\fB\-mno\-short\fR" 4
  .IX Item "-mno-short"
  Do not consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide.  This is the default.
! .IP "\fB\-mnobitfield\fR" 4
  .IX Item "-mnobitfield"
  .PD 0
! .IP "\fB\-mno\-bitfield\fR" 4
  .IX Item "-mno-bitfield"
  .PD
! Do not use the bit-field instructions.  The \fB\-m68000\fR, \fB\-mcpu32\fR
  and \fB\-m5200\fR options imply \fB\-mnobitfield\fR.
! .IP "\fB\-mbitfield\fR" 4
  .IX Item "-mbitfield"
! Do use the bit-field instructions.  The \fB\-m68020\fR option implies
  \&\fB\-mbitfield\fR.  This is the default if you use a configuration
  designed for a 68020.
! .IP "\fB\-mrtd\fR" 4
  .IX Item "-mrtd"
! Use a different function-calling convention, in which functions
  that take a fixed number of arguments return with the \f(CW\*(C`rtd\*(C'\fR
  instruction, which pops their arguments while returning.  This
  saves one instruction in the caller since there is no need to pop
--- 25418,25477 ----
  68881 instructions that are emulated on the 68060.
  .Sp
  The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-60\fR.
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD 0
! .IP \fB\-m68881\fR 4
  .IX Item "-m68881"
  .PD
! Generate floating\-point instructions.  This is the default for 68020
! and above, and for ColdFire devices that have an FPU.  It defines the
  macro \f(CW\*(C`_\|_HAVE_68881_\|_\*(C'\fR on M680x0 targets and \f(CW\*(C`_\|_mcffpu_\|_\*(C'\fR
  on ColdFire targets.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
! Do not generate floating\-point instructions; use library calls instead.
  This is the default for 68000, 68010, and 68832 targets.  It is also
! the default for ColdFire devices that have no FPU.
! .IP \fB\-mdiv\fR 4
  .IX Item "-mdiv"
  .PD 0
! .IP \fB\-mno\-div\fR 4
  .IX Item "-mno-div"
  .PD
  Generate (do not generate) ColdFire hardware divide and remainder
  instructions.  If \fB\-march\fR is used without \fB\-mcpu\fR,
! the default is "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 \fB\-mcpu\fR).  For
! example, the default is "off" for \fB\-mcpu=5206\fR and "on" for
  \&\fB\-mcpu=5206e\fR.
  .Sp
! GCC defines the macro \f(CW\*(C`_\|_mcfhwdiv_\|_\*(C'\fR when this option is enabled.
! .IP \fB\-mshort\fR 4
  .IX Item "-mshort"
  Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR.
  Additionally, parameters passed on the stack are also aligned to a
! 16\-bit boundary even on targets whose API mandates promotion to 32\-bit.
! .IP \fB\-mno\-short\fR 4
  .IX Item "-mno-short"
  Do not consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide.  This is the default.
! .IP \fB\-mnobitfield\fR 4
  .IX Item "-mnobitfield"
  .PD 0
! .IP \fB\-mno\-bitfield\fR 4
  .IX Item "-mno-bitfield"
  .PD
! Do not use the bit\-field instructions.  The \fB\-m68000\fR, \fB\-mcpu32\fR
  and \fB\-m5200\fR options imply \fB\-mnobitfield\fR.
! .IP \fB\-mbitfield\fR 4
  .IX Item "-mbitfield"
! Do use the bit\-field instructions.  The \fB\-m68020\fR option implies
  \&\fB\-mbitfield\fR.  This is the default if you use a configuration
  designed for a 68020.
! .IP \fB\-mrtd\fR 4
  .IX Item "-mrtd"
! Use a different function\-calling convention, in which functions
  that take a fixed number of arguments return with the \f(CW\*(C`rtd\*(C'\fR
  instruction, which pops their arguments while returning.  This
  saves one instruction in the caller since there is no need to pop
*************** function with too many arguments.  (Norm
*** 25560,25635 ****
  harmlessly ignored.)
  .Sp
  The \f(CW\*(C`rtd\*(C'\fR instruction is supported by the 68010, 68020, 68030,
! 68040, 68060 and \s-1CPU32\s0 processors, but not by the 68000 or 5200.
  .Sp
  The default is \fB\-mno\-rtd\fR.
! .IP "\fB\-malign\-int\fR" 4
  .IX Item "-malign-int"
  .PD 0
! .IP "\fB\-mno\-align\-int\fR" 4
  .IX Item "-mno-align-int"
  .PD
! Control whether \s-1GCC\s0 aligns \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`long long\*(C'\fR,
  \&\f(CW\*(C`float\*(C'\fR, \f(CW\*(C`double\*(C'\fR, and \f(CW\*(C`long double\*(C'\fR variables on a 32\-bit
  boundary (\fB\-malign\-int\fR) or a 16\-bit boundary (\fB\-mno\-align\-int\fR).
  Aligning variables on 32\-bit boundaries produces code that runs somewhat
  faster on processors with 32\-bit busses at the expense of more memory.
  .Sp
! \&\fBWarning:\fR if you use the \fB\-malign\-int\fR switch, \s-1GCC\s0
  aligns structures containing the above types differently than
  most published application binary interface specifications for the m68k.
  .Sp
! Use the pc-relative addressing mode of the 68000 directly, instead of
  using a global offset table.  At present, this option implies \fB\-fpic\fR,
! allowing at most a 16\-bit offset for pc-relative addressing.  \fB\-fPIC\fR is
  not presently supported with \fB\-mpcrel\fR, though this could be supported for
  68020 and higher processors.
! .IP "\fB\-mno\-strict\-align\fR" 4
  .IX Item "-mno-strict-align"
  .PD 0
! .IP "\fB\-mstrict\-align\fR" 4
  .IX Item "-mstrict-align"
  .PD
  Do not (do) assume that unaligned memory references are handled by
  the system.
! .IP "\fB\-msep\-data\fR" 4
  .IX Item "-msep-data"
  Generate code that allows the data segment to be located in a different
! area of memory from the text segment.  This allows for execute-in-place in
  an environment without virtual memory management.  This option implies
  \&\fB\-fPIC\fR.
! .IP "\fB\-mno\-sep\-data\fR" 4
  .IX Item "-mno-sep-data"
  Generate code that assumes that the data segment follows the text segment.
  This is the default.
! .IP "\fB\-mid\-shared\-library\fR" 4
  .IX Item "-mid-shared-library"
! Generate code that supports shared libraries via the library \s-1ID\s0 method.
! This allows for execute-in-place and shared libraries in an environment
  without virtual memory management.  This option implies \fB\-fPIC\fR.
! .IP "\fB\-mno\-id\-shared\-library\fR" 4
  .IX Item "-mno-id-shared-library"
! Generate code that doesn't assume ID-based shared libraries are being used.
  This is the default.
! .IP "\fB\-mshared\-library\-id=n\fR" 4
  .IX Item "-mshared-library-id=n"
! Specifies the identification number of the ID-based shared library being
  compiled.  Specifying a value of 0 generates more compact code; specifying
  other values forces the allocation of that number to the current
! library, but is no more space\- or time-efficient than omitting this option.
! .IP "\fB\-mxgot\fR" 4
  .IX Item "-mxgot"
  .PD 0
! .IP "\fB\-mno\-xgot\fR" 4
  .IX Item "-mno-xgot"
  .PD
! When generating position-independent code for ColdFire, generate code
! that works if the \s-1GOT\s0 has more than 8192 entries.  This code is
  larger and slower than code generated without this option.  On M680x0
  processors, this option is not needed; \fB\-fPIC\fR suffices.
  .Sp
! \&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT.\s0
! While this is relatively efficient, it only works if the \s-1GOT\s0
  is smaller than about 64k.  Anything larger causes the linker
  to report an error such as:
  .Sp
--- 25491,25566 ----
  harmlessly ignored.)
  .Sp
  The \f(CW\*(C`rtd\*(C'\fR instruction is supported by the 68010, 68020, 68030,
! 68040, 68060 and CPU32 processors, but not by the 68000 or 5200.
  .Sp
  The default is \fB\-mno\-rtd\fR.
! .IP \fB\-malign\-int\fR 4
  .IX Item "-malign-int"
  .PD 0
! .IP \fB\-mno\-align\-int\fR 4
  .IX Item "-mno-align-int"
  .PD
! Control whether GCC aligns \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`long long\*(C'\fR,
  \&\f(CW\*(C`float\*(C'\fR, \f(CW\*(C`double\*(C'\fR, and \f(CW\*(C`long double\*(C'\fR variables on a 32\-bit
  boundary (\fB\-malign\-int\fR) or a 16\-bit boundary (\fB\-mno\-align\-int\fR).
  Aligning variables on 32\-bit boundaries produces code that runs somewhat
  faster on processors with 32\-bit busses at the expense of more memory.
  .Sp
! \&\fBWarning:\fR if you use the \fB\-malign\-int\fR switch, GCC
  aligns structures containing the above types differently than
  most published application binary interface specifications for the m68k.
  .Sp
! Use the pc\-relative addressing mode of the 68000 directly, instead of
  using a global offset table.  At present, this option implies \fB\-fpic\fR,
! allowing at most a 16\-bit offset for pc\-relative addressing.  \fB\-fPIC\fR is
  not presently supported with \fB\-mpcrel\fR, though this could be supported for
  68020 and higher processors.
! .IP \fB\-mno\-strict\-align\fR 4
  .IX Item "-mno-strict-align"
  .PD 0
! .IP \fB\-mstrict\-align\fR 4
  .IX Item "-mstrict-align"
  .PD
  Do not (do) assume that unaligned memory references are handled by
  the system.
! .IP \fB\-msep\-data\fR 4
  .IX Item "-msep-data"
  Generate code that allows the data segment to be located in a different
! area of memory from the text segment.  This allows for execute\-in\-place in
  an environment without virtual memory management.  This option implies
  \&\fB\-fPIC\fR.
! .IP \fB\-mno\-sep\-data\fR 4
  .IX Item "-mno-sep-data"
  Generate code that assumes that the data segment follows the text segment.
  This is the default.
! .IP \fB\-mid\-shared\-library\fR 4
  .IX Item "-mid-shared-library"
! Generate code that supports shared libraries via the library ID method.
! This allows for execute\-in\-place and shared libraries in an environment
  without virtual memory management.  This option implies \fB\-fPIC\fR.
! .IP \fB\-mno\-id\-shared\-library\fR 4
  .IX Item "-mno-id-shared-library"
! Generate code that doesn\*(Aqt assume ID\-based shared libraries are being used.
  This is the default.
! .IP \fB\-mshared\-library\-id=n\fR 4
  .IX Item "-mshared-library-id=n"
! Specifies the identification number of the ID\-based shared library being
  compiled.  Specifying a value of 0 generates more compact code; specifying
  other values forces the allocation of that number to the current
! library, but is no more space\- or time\-efficient than omitting this option.
! .IP \fB\-mxgot\fR 4
  .IX Item "-mxgot"
  .PD 0
! .IP \fB\-mno\-xgot\fR 4
  .IX Item "-mno-xgot"
  .PD
! When generating position\-independent code for ColdFire, generate code
! that works if the 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; \fB\-fPIC\fR suffices.
  .Sp
! 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:
  .Sp
*************** It should then work with very large GOTs
*** 25642,25655 ****
  \&\fB\-mxgot\fR is less efficient, since it takes 4 instructions to fetch
  the value of a global symbol.
  .Sp
! Note that some linkers, including newer versions of the \s-1GNU\s0 linker,
! can create multiple GOTs and sort \s-1GOT\s0 entries.  If you have such a linker,
  you should only need to use \fB\-mxgot\fR when compiling a single
! object file that accesses more than 8192 \s-1GOT\s0 entries.  Very few do.
  .Sp
! These options have no effect unless \s-1GCC\s0 is generating
! position-independent code.
! .IP "\fB\-mlong\-jump\-table\-offsets\fR" 4
  .IX Item "-mlong-jump-table-offsets"
  Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables.  The default is to use
  16\-bit offsets.
--- 25573,25586 ----
  \&\fB\-mxgot\fR is less efficient, since it takes 4 instructions to fetch
  the value of a global symbol.
  .Sp
! Note that some linkers, including newer versions of the GNU linker,
! can create multiple GOTs and sort GOT entries.  If you have such a linker,
  you should only need to use \fB\-mxgot\fR when compiling a single
! object file that accesses more than 8192 GOT entries.  Very few do.
  .Sp
! These options have no effect unless GCC is generating
! position\-independent code.
! .IP \fB\-mlong\-jump\-table\-offsets\fR 4
  .IX Item "-mlong-jump-table-offsets"
  Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables.  The default is to use
  16\-bit offsets.
*************** Use 32\-bit offsets in \f(CW\*(C`switch\
*** 25659,25733 ****
  .PP
  These are the \fB\-m\fR options defined for the Motorola M*Core
  processors.
! .IP "\fB\-mhardlit\fR" 4
  .IX Item "-mhardlit"
  .PD 0
! .IP "\fB\-mno\-hardlit\fR" 4
  .IX Item "-mno-hardlit"
  .PD
  Inline constants into the code stream if it can be done in two
  instructions or less.
! .IP "\fB\-mdiv\fR" 4
  .IX Item "-mdiv"
  .PD 0
! .IP "\fB\-mno\-div\fR" 4
  .IX Item "-mno-div"
  .PD
  Use the divide instruction.  (Enabled by default).
! .IP "\fB\-mrelax\-immediate\fR" 4
  .IX Item "-mrelax-immediate"
  .PD 0
! .IP "\fB\-mno\-relax\-immediate\fR" 4
  .IX Item "-mno-relax-immediate"
  .PD
! Allow arbitrary-sized immediates in bit operations.
! .IP "\fB\-mwide\-bitfields\fR" 4
  .IX Item "-mwide-bitfields"
  .PD 0
! .IP "\fB\-mno\-wide\-bitfields\fR" 4
  .IX Item "-mno-wide-bitfields"
  .PD
! Always treat bit-fields as \f(CW\*(C`int\*(C'\fR\-sized.
! .IP "\fB\-m4byte\-functions\fR" 4
  .IX Item "-m4byte-functions"
  .PD 0
! .IP "\fB\-mno\-4byte\-functions\fR" 4
  .IX Item "-mno-4byte-functions"
  .PD
  Force all functions to be aligned to a 4\-byte boundary.
! .IP "\fB\-mcallgraph\-data\fR" 4
  .IX Item "-mcallgraph-data"
  .PD 0
! .IP "\fB\-mno\-callgraph\-data\fR" 4
  .IX Item "-mno-callgraph-data"
  .PD
  Emit callgraph information.
! .IP "\fB\-mslow\-bytes\fR" 4
  .IX Item "-mslow-bytes"
  .PD 0
! .IP "\fB\-mno\-slow\-bytes\fR" 4
  .IX Item "-mno-slow-bytes"
  .PD
  Prefer word access when reading byte quantities.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
  .PD 0
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
  .PD
! Generate code for a little-endian target.
! .IP "\fB\-m210\fR" 4
  .IX Item "-m210"
  .PD 0
! .IP "\fB\-m340\fR" 4
  .IX Item "-m340"
  .PD
  Generate code for the 210 processor.
! .IP "\fB\-mno\-lsim\fR" 4
  .IX Item "-mno-lsim"
  Assume that runtime support has been provided and so omit the
  simulator library (\fIlibsim.a)\fR from the linker command line.
! .IP "\fB\-mstack\-increment=\fR\fIsize\fR" 4
  .IX Item "-mstack-increment=size"
  Set the maximum amount for a single stack increment operation.  Large
  values can increase the speed of programs that contain functions
--- 25590,25664 ----
  .PP
  These are the \fB\-m\fR options defined for the Motorola M*Core
  processors.
! .IP \fB\-mhardlit\fR 4
  .IX Item "-mhardlit"
  .PD 0
! .IP \fB\-mno\-hardlit\fR 4
  .IX Item "-mno-hardlit"
  .PD
  Inline constants into the code stream if it can be done in two
  instructions or less.
! .IP \fB\-mdiv\fR 4
  .IX Item "-mdiv"
  .PD 0
! .IP \fB\-mno\-div\fR 4
  .IX Item "-mno-div"
  .PD
  Use the divide instruction.  (Enabled by default).
! .IP \fB\-mrelax\-immediate\fR 4
  .IX Item "-mrelax-immediate"
  .PD 0
! .IP \fB\-mno\-relax\-immediate\fR 4
  .IX Item "-mno-relax-immediate"
  .PD
! Allow arbitrary\-sized immediates in bit operations.
! .IP \fB\-mwide\-bitfields\fR 4
  .IX Item "-mwide-bitfields"
  .PD 0
! .IP \fB\-mno\-wide\-bitfields\fR 4
  .IX Item "-mno-wide-bitfields"
  .PD
! Always treat bit\-fields as \f(CW\*(C`int\*(C'\fR\-sized.
! .IP \fB\-m4byte\-functions\fR 4
  .IX Item "-m4byte-functions"
  .PD 0
! .IP \fB\-mno\-4byte\-functions\fR 4
  .IX Item "-mno-4byte-functions"
  .PD
  Force all functions to be aligned to a 4\-byte boundary.
! .IP \fB\-mcallgraph\-data\fR 4
  .IX Item "-mcallgraph-data"
  .PD 0
! .IP \fB\-mno\-callgraph\-data\fR 4
  .IX Item "-mno-callgraph-data"
  .PD
  Emit callgraph information.
! .IP \fB\-mslow\-bytes\fR 4
  .IX Item "-mslow-bytes"
  .PD 0
! .IP \fB\-mno\-slow\-bytes\fR 4
  .IX Item "-mno-slow-bytes"
  .PD
  Prefer word access when reading byte quantities.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
  .PD 0
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
  .PD
! Generate code for a little\-endian target.
! .IP \fB\-m210\fR 4
  .IX Item "-m210"
  .PD 0
! .IP \fB\-m340\fR 4
  .IX Item "-m340"
  .PD
  Generate code for the 210 processor.
! .IP \fB\-mno\-lsim\fR 4
  .IX Item "-mno-lsim"
  Assume that runtime support has been provided and so omit the
  simulator library (\fIlibsim.a)\fR from the linker command line.
! .IP \fB\-mstack\-increment=\fR\fIsize\fR 4
  .IX Item "-mstack-increment=size"
  Set the maximum amount for a single stack increment operation.  Large
  values can increase the speed of programs that contain functions
*************** value is 0x1000.
*** 25737,25819 ****
  .PP
  \fIMicroBlaze Options\fR
  .IX Subsection "MicroBlaze Options"
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  Use software emulation for floating point (default).
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
! Use hardware floating-point instructions.
! .IP "\fB\-mmemcpy\fR" 4
  .IX Item "-mmemcpy"
  Do not optimize block moves, use \f(CW\*(C`memcpy\*(C'\fR.
! .IP "\fB\-mno\-clearbss\fR" 4
  .IX Item "-mno-clearbss"
  This option is deprecated.  Use \fB\-fno\-zero\-initialized\-in\-bss\fR instead.
! .IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
  .IX Item "-mcpu=cpu-type"
! Use features of, and schedule code for, the given \s-1CPU.\s0
! Supported values are in the format \fBv\fR\fIX\fR\fB.\fR\fI\s-1YY\s0\fR\fB.\fR\fIZ\fR,
! where \fIX\fR is a major version, \fI\s-1YY\s0\fR is the minor version, and
  \&\fIZ\fR is compatibility code.  Example values are \fBv3.00.a\fR,
  \&\fBv4.00.b\fR, \fBv5.00.a\fR, \fBv5.00.b\fR, \fBv6.00.a\fR.
! .IP "\fB\-mxl\-soft\-mul\fR" 4
  .IX Item "-mxl-soft-mul"
  Use software multiply emulation (default).
! .IP "\fB\-mxl\-soft\-div\fR" 4
  .IX Item "-mxl-soft-div"
  Use software emulation for divides (default).
! .IP "\fB\-mxl\-barrel\-shift\fR" 4
  .IX Item "-mxl-barrel-shift"
  Use the hardware barrel shifter.
! .IP "\fB\-mxl\-pattern\-compare\fR" 4
  .IX Item "-mxl-pattern-compare"
  Use pattern compare instructions.
! .IP "\fB\-msmall\-divides\fR" 4
  .IX Item "-msmall-divides"
  Use table lookup optimization for small signed integer divisions.
! .IP "\fB\-mxl\-stack\-check\fR" 4
  .IX Item "-mxl-stack-check"
  This option is deprecated.  Use \fB\-fstack\-check\fR instead.
! .IP "\fB\-mxl\-gp\-opt\fR" 4
  .IX Item "-mxl-gp-opt"
! Use GP-relative \f(CW\*(C`.sdata\*(C'\fR/\f(CW\*(C`.sbss\*(C'\fR sections.
! .IP "\fB\-mxl\-multiply\-high\fR" 4
  .IX Item "-mxl-multiply-high"
  Use multiply high instructions for high part of 32x32 multiply.
! .IP "\fB\-mxl\-float\-convert\fR" 4
  .IX Item "-mxl-float-convert"
! Use hardware floating-point conversion instructions.
! .IP "\fB\-mxl\-float\-sqrt\fR" 4
  .IX Item "-mxl-float-sqrt"
! Use hardware floating-point square root instruction.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code for a big-endian target.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code for a little-endian target.
! .IP "\fB\-mxl\-reorder\fR" 4
  .IX Item "-mxl-reorder"
  Use reorder instructions (swap and byte reversed load/store).
! .IP "\fB\-mxl\-mode\-\fR\fIapp-model\fR" 4
  .IX Item "-mxl-mode-app-model"
! Select application model \fIapp-model\fR.  Valid models are
  .RS 4
! .IP "\fBexecutable\fR" 4
  .IX Item "executable"
  normal executable (default), uses startup code \fIcrt0.o\fR.
! .IP "\fBxmdstub\fR" 4
  .IX Item "xmdstub"
! for use with Xilinx Microprocessor Debugger (\s-1XMD\s0) based
  software intrusive debug agent called xmdstub. This uses startup file
  \&\fIcrt1.o\fR and sets the start address of the program to 0x800.
! .IP "\fBbootstrap\fR" 4
  .IX Item "bootstrap"
  for applications that are loaded using a bootloader.
  This model uses startup file \fIcrt2.o\fR which does not contain a processor
  reset vector handler. This is suitable for transferring control on a
  processor reset to the bootloader rather than the application.
! .IP "\fBnovectors\fR" 4
  .IX Item "novectors"
  for applications that do not require any of the
  MicroBlaze vectors. This option may be useful for applications running
--- 25668,25750 ----
  .PP
  \fIMicroBlaze Options\fR
  .IX Subsection "MicroBlaze Options"
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  Use software emulation for floating point (default).
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
! Use hardware floating\-point instructions.
! .IP \fB\-mmemcpy\fR 4
  .IX Item "-mmemcpy"
  Do not optimize block moves, use \f(CW\*(C`memcpy\*(C'\fR.
! .IP \fB\-mno\-clearbss\fR 4
  .IX Item "-mno-clearbss"
  This option is deprecated.  Use \fB\-fno\-zero\-initialized\-in\-bss\fR instead.
! .IP \fB\-mcpu=\fR\fIcpu\-type\fR 4
  .IX Item "-mcpu=cpu-type"
! Use features of, and schedule code for, the given CPU.
! Supported values are in the format \fBv\fR\fIX\fR\fB.\fR\fIYY\fR\fB.\fR\fIZ\fR,
! where \fIX\fR is a major version, \fIYY\fR is the minor version, and
  \&\fIZ\fR is compatibility code.  Example values are \fBv3.00.a\fR,
  \&\fBv4.00.b\fR, \fBv5.00.a\fR, \fBv5.00.b\fR, \fBv6.00.a\fR.
! .IP \fB\-mxl\-soft\-mul\fR 4
  .IX Item "-mxl-soft-mul"
  Use software multiply emulation (default).
! .IP \fB\-mxl\-soft\-div\fR 4
  .IX Item "-mxl-soft-div"
  Use software emulation for divides (default).
! .IP \fB\-mxl\-barrel\-shift\fR 4
  .IX Item "-mxl-barrel-shift"
  Use the hardware barrel shifter.
! .IP \fB\-mxl\-pattern\-compare\fR 4
  .IX Item "-mxl-pattern-compare"
  Use pattern compare instructions.
! .IP \fB\-msmall\-divides\fR 4
  .IX Item "-msmall-divides"
  Use table lookup optimization for small signed integer divisions.
! .IP \fB\-mxl\-stack\-check\fR 4
  .IX Item "-mxl-stack-check"
  This option is deprecated.  Use \fB\-fstack\-check\fR instead.
! .IP \fB\-mxl\-gp\-opt\fR 4
  .IX Item "-mxl-gp-opt"
! Use GP\-relative \f(CW\*(C`.sdata\*(C'\fR/\f(CW\*(C`.sbss\*(C'\fR sections.
! .IP \fB\-mxl\-multiply\-high\fR 4
  .IX Item "-mxl-multiply-high"
  Use multiply high instructions for high part of 32x32 multiply.
! .IP \fB\-mxl\-float\-convert\fR 4
  .IX Item "-mxl-float-convert"
! Use hardware floating\-point conversion instructions.
! .IP \fB\-mxl\-float\-sqrt\fR 4
  .IX Item "-mxl-float-sqrt"
! Use hardware floating\-point square root instruction.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code for a big\-endian target.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code for a little\-endian target.
! .IP \fB\-mxl\-reorder\fR 4
  .IX Item "-mxl-reorder"
  Use reorder instructions (swap and byte reversed load/store).
! .IP \fB\-mxl\-mode\-\fR\fIapp\-model\fR 4
  .IX Item "-mxl-mode-app-model"
! Select application model \fIapp\-model\fR.  Valid models are
  .RS 4
! .IP \fBexecutable\fR 4
  .IX Item "executable"
  normal executable (default), uses startup code \fIcrt0.o\fR.
! .IP \fBxmdstub\fR 4
  .IX Item "xmdstub"
! for use with Xilinx Microprocessor Debugger (XMD) based
  software intrusive debug agent called xmdstub. This uses startup file
  \&\fIcrt1.o\fR and sets the start address of the program to 0x800.
! .IP \fBbootstrap\fR 4
  .IX Item "bootstrap"
  for applications that are loaded using a bootloader.
  This model uses startup file \fIcrt2.o\fR which does not contain a processor
  reset vector handler. This is suitable for transferring control on a
  processor reset to the bootloader rather than the application.
! .IP \fBnovectors\fR 4
  .IX Item "novectors"
  for applications that do not require any of the
  MicroBlaze vectors. This option may be useful for applications running
*************** within a monitoring application. This mo
*** 25821,25849 ****
  .RE
  .RS 4
  .Sp
! Option \fB\-xl\-mode\-\fR\fIapp-model\fR is a deprecated alias for
! \&\fB\-mxl\-mode\-\fR\fIapp-model\fR.
  .RE
! .IP "\fB\-mpic\-data\-is\-text\-relative\fR" 4
  .IX Item "-mpic-data-is-text-relative"
  Assume that the displacement between the text and data segments is fixed
  at static link time.  This allows data to be referenced by offset from start of
! text address instead of \s-1GOT\s0 since PC-relative addressing is not supported.
  .PP
! \fI\s-1MIPS\s0 Options\fR
  .IX Subsection "MIPS Options"
! .IP "\fB\-EB\fR" 4
  .IX Item "-EB"
! Generate big-endian code.
! .IP "\fB\-EL\fR" 4
  .IX Item "-EL"
! Generate little-endian code.  This is the default for \fBmips*el\-*\-*\fR
  configurations.
! .IP "\fB\-march=\fR\fIarch\fR" 4
  .IX Item "-march=arch"
  Generate code that runs on \fIarch\fR, which can be the name of a
! generic \s-1MIPS ISA,\s0 or the name of a particular processor.
! The \s-1ISA\s0 names are:
  \&\fBmips1\fR, \fBmips2\fR, \fBmips3\fR, \fBmips4\fR,
  \&\fBmips32\fR, \fBmips32r2\fR, \fBmips32r3\fR, \fBmips32r5\fR,
  \&\fBmips32r6\fR, \fBmips64\fR, \fBmips64r2\fR, \fBmips64r3\fR,
--- 25752,25780 ----
  .RE
  .RS 4
  .Sp
! Option \fB\-xl\-mode\-\fR\fIapp\-model\fR is a deprecated alias for
! \&\fB\-mxl\-mode\-\fR\fIapp\-model\fR.
  .RE
! .IP \fB\-mpic\-data\-is\-text\-relative\fR 4
  .IX Item "-mpic-data-is-text-relative"
  Assume that the displacement between the text and data segments is fixed
  at static link time.  This allows data to be referenced by offset from start of
! text address instead of GOT since PC\-relative addressing is not supported.
  .PP
! \fIMIPS Options\fR
  .IX Subsection "MIPS Options"
! .IP \fB\-EB\fR 4
  .IX Item "-EB"
! Generate big\-endian code.
! .IP \fB\-EL\fR 4
  .IX Item "-EL"
! Generate little\-endian code.  This is the default for \fBmips*el\-*\-*\fR
  configurations.
! .IP \fB\-march=\fR\fIarch\fR 4
  .IX Item "-march=arch"
  Generate code that runs on \fIarch\fR, which can be the name of a
! generic MIPS ISA, or the name of a particular processor.
! The ISA names are:
  \&\fBmips1\fR, \fBmips2\fR, \fBmips3\fR, \fBmips4\fR,
  \&\fBmips32\fR, \fBmips32r2\fR, \fBmips32r3\fR, \fBmips32r5\fR,
  \&\fBmips32r6\fR, \fBmips64\fR, \fBmips64r2\fR, \fBmips64r3\fR,
*************** The processor names are:
*** 25878,25890 ****
  \&\fBvr4100\fR, \fBvr4111\fR, \fBvr4120\fR, \fBvr4130\fR, \fBvr4300\fR,
  \&\fBvr5000\fR, \fBvr5400\fR, \fBvr5500\fR,
  \&\fBxlr\fR and \fBxlp\fR.
! The special value \fBfrom-abi\fR selects the
! most compatible architecture for the selected \s-1ABI\s0 (that is,
  \&\fBmips1\fR for 32\-bit ABIs and \fBmips3\fR for 64\-bit ABIs).
  .Sp
  The native Linux/GNU toolchain also supports the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-march=native\fR has no effect if \s-1GCC\s0 does not recognize
  the processor.
  .Sp
  In processor names, a final \fB000\fR can be abbreviated as \fBk\fR
--- 25809,25821 ----
  \&\fBvr4100\fR, \fBvr4111\fR, \fBvr4120\fR, \fBvr4130\fR, \fBvr4300\fR,
  \&\fBvr5000\fR, \fBvr5400\fR, \fBvr5500\fR,
  \&\fBxlr\fR and \fBxlp\fR.
! The special value \fBfrom\-abi\fR selects the
! most compatible architecture for the selected ABI (that is,
  \&\fBmips1\fR for 32\-bit ABIs and \fBmips3\fR for 64\-bit ABIs).
  .Sp
  The native Linux/GNU toolchain also supports the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-march=native\fR has no effect if GCC does not recognize
  the processor.
  .Sp
  In processor names, a final \fB000\fR can be abbreviated as \fBk\fR
*************** For compatibility reasons, \fIn\fR\fBf\f
*** 25900,26115 ****
  for \fIn\fR\fBf2_1\fR while \fIn\fR\fBx\fR and \fIb\fR\fBfx\fR are
  accepted as synonyms for \fIn\fR\fBf1_1\fR.
  .Sp
! \&\s-1GCC\s0 defines two macros based on the value of this option.  The first
  is \f(CW\*(C`_MIPS_ARCH\*(C'\fR, which gives the name of target architecture, as
! a string.  The second has the form \f(CW\*(C`_MIPS_ARCH_\f(CIfoo\f(CW\*(C'\fR,
  where \fIfoo\fR is the capitalized value of \f(CW\*(C`_MIPS_ARCH\*(C'\fR.
  For example, \fB\-march=r2000\fR sets \f(CW\*(C`_MIPS_ARCH\*(C'\fR
  to \f(CW"r2000"\fR and defines the macro \f(CW\*(C`_MIPS_ARCH_R2000\*(C'\fR.
  .Sp
  Note that the \f(CW\*(C`_MIPS_ARCH\*(C'\fR macro uses the processor names given
  above.  In other words, it has the full prefix and does not
! abbreviate \fB000\fR as \fBk\fR.  In the case of \fBfrom-abi\fR,
  the macro names the resolved architecture (either \f(CW"mips1"\fR or
  \&\f(CW"mips3"\fR).  It names the default architecture when no
  \&\fB\-march\fR option is given.
! .IP "\fB\-mtune=\fR\fIarch\fR" 4
  .IX Item "-mtune=arch"
  Optimize for \fIarch\fR.  Among other things, this option controls
  the way instructions are scheduled, and the perceived cost of arithmetic
  operations.  The list of \fIarch\fR values is the same as for
  \&\fB\-march\fR.
  .Sp
! When this option is not used, \s-1GCC\s0 optimizes for the processor
  specified by \fB\-march\fR.  By using \fB\-march\fR and
  \&\fB\-mtune\fR together, it is possible to generate code that
  runs on a family of processors, but optimize the code for one
  particular member of that family.
  .Sp
  \&\fB\-mtune\fR defines the macros \f(CW\*(C`_MIPS_TUNE\*(C'\fR and
! \&\f(CW\*(C`_MIPS_TUNE_\f(CIfoo\f(CW\*(C'\fR, which work in the same way as the
  \&\fB\-march\fR ones described above.
! .IP "\fB\-mips1\fR" 4
  .IX Item "-mips1"
  Equivalent to \fB\-march=mips1\fR.
! .IP "\fB\-mips2\fR" 4
  .IX Item "-mips2"
  Equivalent to \fB\-march=mips2\fR.
! .IP "\fB\-mips3\fR" 4
  .IX Item "-mips3"
  Equivalent to \fB\-march=mips3\fR.
! .IP "\fB\-mips4\fR" 4
  .IX Item "-mips4"
  Equivalent to \fB\-march=mips4\fR.
! .IP "\fB\-mips32\fR" 4
  .IX Item "-mips32"
  Equivalent to \fB\-march=mips32\fR.
! .IP "\fB\-mips32r3\fR" 4
  .IX Item "-mips32r3"
  Equivalent to \fB\-march=mips32r3\fR.
! .IP "\fB\-mips32r5\fR" 4
  .IX Item "-mips32r5"
  Equivalent to \fB\-march=mips32r5\fR.
! .IP "\fB\-mips32r6\fR" 4
  .IX Item "-mips32r6"
  Equivalent to \fB\-march=mips32r6\fR.
! .IP "\fB\-mips64\fR" 4
  .IX Item "-mips64"
  Equivalent to \fB\-march=mips64\fR.
! .IP "\fB\-mips64r2\fR" 4
  .IX Item "-mips64r2"
  Equivalent to \fB\-march=mips64r2\fR.
! .IP "\fB\-mips64r3\fR" 4
  .IX Item "-mips64r3"
  Equivalent to \fB\-march=mips64r3\fR.
! .IP "\fB\-mips64r5\fR" 4
  .IX Item "-mips64r5"
  Equivalent to \fB\-march=mips64r5\fR.
! .IP "\fB\-mips64r6\fR" 4
  .IX Item "-mips64r6"
  Equivalent to \fB\-march=mips64r6\fR.
! .IP "\fB\-mips16\fR" 4
  .IX Item "-mips16"
  .PD 0
! .IP "\fB\-mno\-mips16\fR" 4
  .IX Item "-mno-mips16"
  .PD
! Generate (do not generate) \s-1MIPS16\s0 code.  If \s-1GCC\s0 is targeting a
! \&\s-1MIPS32\s0 or \s-1MIPS64\s0 architecture, it makes use of the MIPS16e \s-1ASE.\s0
  .Sp
! \&\s-1MIPS16\s0 code generation can also be controlled on a per-function basis
  by means of \f(CW\*(C`mips16\*(C'\fR and \f(CW\*(C`nomips16\*(C'\fR attributes.
! .IP "\fB\-mflip\-mips16\fR" 4
  .IX Item "-mflip-mips16"
! Generate \s-1MIPS16\s0 code on alternating functions.  This option is provided
  for regression testing of mixed MIPS16/non\-MIPS16 code generation, and is
  not intended for ordinary use in compiling user code.
! .IP "\fB\-minterlink\-compressed\fR" 4
  .IX Item "-minterlink-compressed"
  .PD 0
! .IP "\fB\-mno\-interlink\-compressed\fR" 4
  .IX Item "-mno-interlink-compressed"
  .PD
! Require (do not require) that code using the standard (uncompressed) \s-1MIPS ISA\s0
! be link-compatible with \s-1MIPS16\s0 and microMIPS code, and vice versa.
  .Sp
! For example, code using the standard \s-1ISA\s0 encoding cannot jump directly
! to \s-1MIPS16\s0 or microMIPS code; it must either use a call or an indirect jump.
! \&\fB\-minterlink\-compressed\fR therefore disables direct jumps unless \s-1GCC\s0
  knows that the target of the jump is not compressed.
! .IP "\fB\-minterlink\-mips16\fR" 4
  .IX Item "-minterlink-mips16"
  .PD 0
! .IP "\fB\-mno\-interlink\-mips16\fR" 4
  .IX Item "-mno-interlink-mips16"
  .PD
  Aliases of \fB\-minterlink\-compressed\fR and
! \&\fB\-mno\-interlink\-compressed\fR.  These options predate the microMIPS \s-1ASE\s0
  and are retained for backwards compatibility.
! .IP "\fB\-mabi=32\fR" 4
  .IX Item "-mabi=32"
  .PD 0
! .IP "\fB\-mabi=o64\fR" 4
  .IX Item "-mabi=o64"
! .IP "\fB\-mabi=n32\fR" 4
  .IX Item "-mabi=n32"
! .IP "\fB\-mabi=64\fR" 4
  .IX Item "-mabi=64"
! .IP "\fB\-mabi=eabi\fR" 4
  .IX Item "-mabi=eabi"
  .PD
! Generate code for the given \s-1ABI.\s0
  .Sp
! Note that the \s-1EABI\s0 has a 32\-bit and a 64\-bit variant.  \s-1GCC\s0 normally
  generates 64\-bit code when you select a 64\-bit architecture, but you
  can use \fB\-mgp32\fR to get 32\-bit code instead.
  .Sp
! For information about the O64 \s-1ABI,\s0 see
  <\fBhttps://gcc.gnu.org/projects/mipso64\-abi.html\fR>.
  .Sp
! \&\s-1GCC\s0 supports a variant of the o32 \s-1ABI\s0 in which floating-point registers
  are 64 rather than 32 bits wide.  You can select this combination with
! \&\fB\-mabi=32\fR \fB\-mfp64\fR.  This \s-1ABI\s0 relies on the \f(CW\*(C`mthc1\*(C'\fR
  and \f(CW\*(C`mfhc1\*(C'\fR instructions and is therefore only supported for
! \&\s-1MIPS32R2, MIPS32R3\s0 and \s-1MIPS32R5\s0 processors.
  .Sp
  The register assignments for arguments and return values remain the
  same, but each scalar value is passed in a single 64\-bit register
  rather than a pair of 32\-bit registers.  For example, scalar
! floating-point values are returned in \fB\f(CB$f0\fB\fR only, not a
! \&\fB\f(CB$f0\fB\fR/\fB\f(CB$f1\fB\fR pair.  The set of call-saved registers also
! remains the same in that the even-numbered double-precision registers
  are saved.
  .Sp
! Two additional variants of the o32 \s-1ABI\s0 are supported to enable
! a transition from 32\-bit to 64\-bit registers.  These are \s-1FPXX\s0
! (\fB\-mfpxx\fR) and \s-1FP64A\s0 (\fB\-mfp64\fR \fB\-mno\-odd\-spreg\fR).
! The \s-1FPXX\s0 extension mandates that all code must execute correctly
  when run using 32\-bit or 64\-bit registers.  The code can be interlinked
! with either \s-1FP32\s0 or \s-1FP64,\s0 but not both.
! The \s-1FP64A\s0 extension is similar to the \s-1FP64\s0 extension but forbids the
! use of odd-numbered single-precision registers.  This can be used
! in conjunction with the \f(CW\*(C`FRE\*(C'\fR mode of FPUs in \s-1MIPS32R5\s0
! processors and allows both \s-1FP32\s0 and \s-1FP64A\s0 code to interlink and
! run in the same process without changing \s-1FPU\s0 modes.
! .IP "\fB\-mabicalls\fR" 4
  .IX Item "-mabicalls"
  .PD 0
! .IP "\fB\-mno\-abicalls\fR" 4
  .IX Item "-mno-abicalls"
  .PD
  Generate (do not generate) code that is suitable for SVR4\-style
  dynamic objects.  \fB\-mabicalls\fR is the default for SVR4\-based
  systems.
! .IP "\fB\-mshared\fR" 4
  .IX Item "-mshared"
  .PD 0
! .IP "\fB\-mno\-shared\fR" 4
  .IX Item "-mno-shared"
  .PD
! Generate (do not generate) code that is fully position-independent,
  and that can therefore be linked into shared libraries.  This option
  only affects \fB\-mabicalls\fR.
  .Sp
! All \fB\-mabicalls\fR code has traditionally been position-independent,
  regardless of options like \fB\-fPIC\fR and \fB\-fpic\fR.  However,
! as an extension, the \s-1GNU\s0 toolchain allows executables to use absolute
! accesses for locally-binding symbols.  It can also use shorter \s-1GP\s0
! initialization sequences and generate direct calls to locally-defined
  functions.  This mode is selected by \fB\-mno\-shared\fR.
  .Sp
  \&\fB\-mno\-shared\fR depends on binutils 2.16 or higher and generates
! objects that can only be linked by the \s-1GNU\s0 linker.  However, the option
! does not affect the \s-1ABI\s0 of the final executable; it only affects the \s-1ABI\s0
  of relocatable objects.  Using \fB\-mno\-shared\fR generally makes
  executables both smaller and quicker.
  .Sp
  \&\fB\-mshared\fR is the default.
! .IP "\fB\-mplt\fR" 4
  .IX Item "-mplt"
  .PD 0
! .IP "\fB\-mno\-plt\fR" 4
  .IX Item "-mno-plt"
  .PD
  Assume (do not assume) that the static and dynamic linkers
  support PLTs and copy relocations.  This option only affects
! \&\fB\-mno\-shared \-mabicalls\fR.  For the n64 \s-1ABI,\s0 this option
  has no effect without \fB\-msym32\fR.
  .Sp
  You can make \fB\-mplt\fR the default by configuring
! \&\s-1GCC\s0 with \fB\-\-with\-mips\-plt\fR.  The default is
  \&\fB\-mno\-plt\fR otherwise.
! .IP "\fB\-mxgot\fR" 4
  .IX Item "-mxgot"
  .PD 0
! .IP "\fB\-mno\-xgot\fR" 4
  .IX Item "-mno-xgot"
  .PD
  Lift (do not lift) the usual restrictions on the size of the global
  offset table.
  .Sp
! \&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT.\s0
! While this is relatively efficient, it only works if the \s-1GOT\s0
  is smaller than about 64k.  Anything larger causes the linker
  to report an error such as:
  .Sp
--- 25831,26046 ----
  for \fIn\fR\fBf2_1\fR while \fIn\fR\fBx\fR and \fIb\fR\fBfx\fR are
  accepted as synonyms for \fIn\fR\fBf1_1\fR.
  .Sp
! GCC defines two macros based on the value of this option.  The first
  is \f(CW\*(C`_MIPS_ARCH\*(C'\fR, which gives the name of target architecture, as
! a string.  The second has the form \f(CW\*(C`_MIPS_ARCH_\fR\f(CIfoo\fR\f(CW\*(C'\fR,
  where \fIfoo\fR is the capitalized value of \f(CW\*(C`_MIPS_ARCH\*(C'\fR.
  For example, \fB\-march=r2000\fR sets \f(CW\*(C`_MIPS_ARCH\*(C'\fR
  to \f(CW"r2000"\fR and defines the macro \f(CW\*(C`_MIPS_ARCH_R2000\*(C'\fR.
  .Sp
  Note that the \f(CW\*(C`_MIPS_ARCH\*(C'\fR macro uses the processor names given
  above.  In other words, it has the full prefix and does not
! abbreviate \fB000\fR as \fBk\fR.  In the case of \fBfrom\-abi\fR,
  the macro names the resolved architecture (either \f(CW"mips1"\fR or
  \&\f(CW"mips3"\fR).  It names the default architecture when no
  \&\fB\-march\fR option is given.
! .IP \fB\-mtune=\fR\fIarch\fR 4
  .IX Item "-mtune=arch"
  Optimize for \fIarch\fR.  Among other things, this option controls
  the way instructions are scheduled, and the perceived cost of arithmetic
  operations.  The list of \fIarch\fR values is the same as for
  \&\fB\-march\fR.
  .Sp
! When this option is not used, GCC optimizes for the processor
  specified by \fB\-march\fR.  By using \fB\-march\fR and
  \&\fB\-mtune\fR together, it is possible to generate code that
  runs on a family of processors, but optimize the code for one
  particular member of that family.
  .Sp
  \&\fB\-mtune\fR defines the macros \f(CW\*(C`_MIPS_TUNE\*(C'\fR and
! \&\f(CW\*(C`_MIPS_TUNE_\fR\f(CIfoo\fR\f(CW\*(C'\fR, which work in the same way as the
  \&\fB\-march\fR ones described above.
! .IP \fB\-mips1\fR 4
  .IX Item "-mips1"
  Equivalent to \fB\-march=mips1\fR.
! .IP \fB\-mips2\fR 4
  .IX Item "-mips2"
  Equivalent to \fB\-march=mips2\fR.
! .IP \fB\-mips3\fR 4
  .IX Item "-mips3"
  Equivalent to \fB\-march=mips3\fR.
! .IP \fB\-mips4\fR 4
  .IX Item "-mips4"
  Equivalent to \fB\-march=mips4\fR.
! .IP \fB\-mips32\fR 4
  .IX Item "-mips32"
  Equivalent to \fB\-march=mips32\fR.
! .IP \fB\-mips32r3\fR 4
  .IX Item "-mips32r3"
  Equivalent to \fB\-march=mips32r3\fR.
! .IP \fB\-mips32r5\fR 4
  .IX Item "-mips32r5"
  Equivalent to \fB\-march=mips32r5\fR.
! .IP \fB\-mips32r6\fR 4
  .IX Item "-mips32r6"
  Equivalent to \fB\-march=mips32r6\fR.
! .IP \fB\-mips64\fR 4
  .IX Item "-mips64"
  Equivalent to \fB\-march=mips64\fR.
! .IP \fB\-mips64r2\fR 4
  .IX Item "-mips64r2"
  Equivalent to \fB\-march=mips64r2\fR.
! .IP \fB\-mips64r3\fR 4
  .IX Item "-mips64r3"
  Equivalent to \fB\-march=mips64r3\fR.
! .IP \fB\-mips64r5\fR 4
  .IX Item "-mips64r5"
  Equivalent to \fB\-march=mips64r5\fR.
! .IP \fB\-mips64r6\fR 4
  .IX Item "-mips64r6"
  Equivalent to \fB\-march=mips64r6\fR.
! .IP \fB\-mips16\fR 4
  .IX Item "-mips16"
  .PD 0
! .IP \fB\-mno\-mips16\fR 4
  .IX Item "-mno-mips16"
  .PD
! Generate (do not generate) MIPS16 code.  If GCC is targeting a
! MIPS32 or MIPS64 architecture, it makes use of the MIPS16e ASE.
  .Sp
! MIPS16 code generation can also be controlled on a per\-function basis
  by means of \f(CW\*(C`mips16\*(C'\fR and \f(CW\*(C`nomips16\*(C'\fR attributes.
! .IP \fB\-mflip\-mips16\fR 4
  .IX Item "-mflip-mips16"
! Generate 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.
! .IP \fB\-minterlink\-compressed\fR 4
  .IX Item "-minterlink-compressed"
  .PD 0
! .IP \fB\-mno\-interlink\-compressed\fR 4
  .IX Item "-mno-interlink-compressed"
  .PD
! Require (do not require) that code using the standard (uncompressed) MIPS ISA
! be link\-compatible with MIPS16 and microMIPS code, and vice versa.
  .Sp
! For example, code using the standard ISA encoding cannot jump directly
! to MIPS16 or microMIPS code; it must either use a call or an indirect jump.
! \&\fB\-minterlink\-compressed\fR therefore disables direct jumps unless GCC
  knows that the target of the jump is not compressed.
! .IP \fB\-minterlink\-mips16\fR 4
  .IX Item "-minterlink-mips16"
  .PD 0
! .IP \fB\-mno\-interlink\-mips16\fR 4
  .IX Item "-mno-interlink-mips16"
  .PD
  Aliases of \fB\-minterlink\-compressed\fR and
! \&\fB\-mno\-interlink\-compressed\fR.  These options predate the microMIPS ASE
  and are retained for backwards compatibility.
! .IP \fB\-mabi=32\fR 4
  .IX Item "-mabi=32"
  .PD 0
! .IP \fB\-mabi=o64\fR 4
  .IX Item "-mabi=o64"
! .IP \fB\-mabi=n32\fR 4
  .IX Item "-mabi=n32"
! .IP \fB\-mabi=64\fR 4
  .IX Item "-mabi=64"
! .IP \fB\-mabi=eabi\fR 4
  .IX Item "-mabi=eabi"
  .PD
! Generate code for the given ABI.
  .Sp
! 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 \fB\-mgp32\fR to get 32\-bit code instead.
  .Sp
! For information about the O64 ABI, see
  <\fBhttps://gcc.gnu.org/projects/mipso64\-abi.html\fR>.
  .Sp
! 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
! \&\fB\-mabi=32\fR \fB\-mfp64\fR.  This ABI relies on the \f(CW\*(C`mthc1\*(C'\fR
  and \f(CW\*(C`mfhc1\*(C'\fR instructions and is therefore only supported for
! MIPS32R2, MIPS32R3 and MIPS32R5 processors.
  .Sp
  The register assignments for arguments and return values remain the
  same, but each scalar value is passed in a single 64\-bit register
  rather than a pair of 32\-bit registers.  For example, scalar
! floating\-point values are returned in \fR\f(CB$f0\fR\fB\fR only, not a
! \&\fB\fR\f(CB$f0\fR\fB\fR/\fB\fR\f(CB$f1\fR\fB\fR pair.  The set of call\-saved registers also
! remains the same in that the even\-numbered double\-precision registers
  are saved.
  .Sp
! Two additional variants of the o32 ABI are supported to enable
! a transition from 32\-bit to 64\-bit registers.  These are FPXX
! (\fB\-mfpxx\fR) and FP64A (\fB\-mfp64\fR \fB\-mno\-odd\-spreg\fR).
! The FPXX extension mandates that all code must execute correctly
  when run using 32\-bit or 64\-bit registers.  The code can be interlinked
! with either FP32 or FP64, but not both.
! The FP64A extension is similar to the FP64 extension but forbids the
! use of odd\-numbered single\-precision registers.  This can be used
! in conjunction with the \f(CW\*(C`FRE\*(C'\fR mode of FPUs in MIPS32R5
! processors and allows both FP32 and FP64A code to interlink and
! run in the same process without changing FPU modes.
! .IP \fB\-mabicalls\fR 4
  .IX Item "-mabicalls"
  .PD 0
! .IP \fB\-mno\-abicalls\fR 4
  .IX Item "-mno-abicalls"
  .PD
  Generate (do not generate) code that is suitable for SVR4\-style
  dynamic objects.  \fB\-mabicalls\fR is the default for SVR4\-based
  systems.
! .IP \fB\-mshared\fR 4
  .IX Item "-mshared"
  .PD 0
! .IP \fB\-mno\-shared\fR 4
  .IX Item "-mno-shared"
  .PD
! Generate (do not generate) code that is fully position\-independent,
  and that can therefore be linked into shared libraries.  This option
  only affects \fB\-mabicalls\fR.
  .Sp
! All \fB\-mabicalls\fR code has traditionally been position\-independent,
  regardless of options like \fB\-fPIC\fR and \fB\-fpic\fR.  However,
! as an extension, the 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 \fB\-mno\-shared\fR.
  .Sp
  \&\fB\-mno\-shared\fR depends on binutils 2.16 or higher and generates
! objects that can only be linked by the GNU linker.  However, the option
! does not affect the ABI of the final executable; it only affects the ABI
  of relocatable objects.  Using \fB\-mno\-shared\fR generally makes
  executables both smaller and quicker.
  .Sp
  \&\fB\-mshared\fR is the default.
! .IP \fB\-mplt\fR 4
  .IX Item "-mplt"
  .PD 0
! .IP \fB\-mno\-plt\fR 4
  .IX Item "-mno-plt"
  .PD
  Assume (do not assume) that the static and dynamic linkers
  support PLTs and copy relocations.  This option only affects
! \&\fB\-mno\-shared \-mabicalls\fR.  For the n64 ABI, this option
  has no effect without \fB\-msym32\fR.
  .Sp
  You can make \fB\-mplt\fR the default by configuring
! GCC with \fB\-\-with\-mips\-plt\fR.  The default is
  \&\fB\-mno\-plt\fR otherwise.
! .IP \fB\-mxgot\fR 4
  .IX Item "-mxgot"
  .PD 0
! .IP \fB\-mno\-xgot\fR 4
  .IX Item "-mno-xgot"
  .PD
  Lift (do not lift) the usual restrictions on the size of the global
  offset table.
  .Sp
! 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:
  .Sp
*************** value of a global symbol.
*** 26124,26413 ****
  .Sp
  Note that some linkers can create multiple GOTs.  If you have such a
  linker, you should only need to use \fB\-mxgot\fR when a single object
! file accesses more than 64k's worth of \s-1GOT\s0 entries.  Very few do.
  .Sp
! These options have no effect unless \s-1GCC\s0 is generating position
  independent code.
! .IP "\fB\-mgp32\fR" 4
  .IX Item "-mgp32"
! Assume that general-purpose registers are 32 bits wide.
! .IP "\fB\-mgp64\fR" 4
  .IX Item "-mgp64"
! Assume that general-purpose registers are 64 bits wide.
! .IP "\fB\-mfp32\fR" 4
  .IX Item "-mfp32"
! Assume that floating-point registers are 32 bits wide.
! .IP "\fB\-mfp64\fR" 4
  .IX Item "-mfp64"
! Assume that floating-point registers are 64 bits wide.
! .IP "\fB\-mfpxx\fR" 4
  .IX Item "-mfpxx"
! Do not assume the width of floating-point registers.
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
! Use floating-point coprocessor instructions.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
! Do not use floating-point coprocessor instructions.  Implement
! floating-point calculations using library calls instead.
! .IP "\fB\-mno\-float\fR" 4
  .IX Item "-mno-float"
  Equivalent to \fB\-msoft\-float\fR, but additionally asserts that the
! program being compiled does not perform any floating-point operations.
! This option is presently supported only by some bare-metal \s-1MIPS\s0
  configurations, where it may select a special set of libraries
! that lack all floating-point support (including, for example, the
! floating-point \f(CW\*(C`printf\*(C'\fR formats).  
  If code compiled with \fB\-mno\-float\fR accidentally contains
! floating-point operations, it is likely to suffer a link-time
! or run-time failure.
! .IP "\fB\-msingle\-float\fR" 4
  .IX Item "-msingle-float"
! Assume that the floating-point coprocessor only supports single-precision
  operations.
! .IP "\fB\-mdouble\-float\fR" 4
  .IX Item "-mdouble-float"
! Assume that the floating-point coprocessor supports double-precision
  operations.  This is the default.
! .IP "\fB\-modd\-spreg\fR" 4
  .IX Item "-modd-spreg"
  .PD 0
! .IP "\fB\-mno\-odd\-spreg\fR" 4
  .IX Item "-mno-odd-spreg"
  .PD
! Enable the use of odd-numbered single-precision floating-point registers
! for the o32 \s-1ABI.\s0  This is the default for processors that are known to
! support these registers.  When using the o32 \s-1FPXX ABI,\s0 \fB\-mno\-odd\-spreg\fR
  is set by default.
! .IP "\fB\-mabs=2008\fR" 4
  .IX Item "-mabs=2008"
  .PD 0
! .IP "\fB\-mabs=legacy\fR" 4
  .IX Item "-mabs=legacy"
  .PD
! These options control the treatment of the special not-a-number (NaN)
! \&\s-1IEEE 754\s0 floating-point data with the \f(CW\*(C`abs.\f(CIfmt\f(CW\*(C'\fR and
! \&\f(CW\*(C`neg.\f(CIfmt\f(CW\*(C'\fR machine instructions.
  .Sp
  By default or when \fB\-mabs=legacy\fR is used the legacy
  treatment is selected.  In this case these instructions are considered
  arithmetic and avoided where correct operation is required and the
  input operand might be a NaN.  A longer sequence of instructions that
! manipulate the sign bit of floating-point datum manually is used
  instead unless the \fB\-ffinite\-math\-only\fR option has also been
  specified.
  .Sp
! The \fB\-mabs=2008\fR option selects the \s-1IEEE 754\-2008\s0 treatment.  In
! this case these instructions are considered non-arithmetic and therefore
  operating correctly in all cases, including in particular where the
  input operand is a NaN.  These instructions are therefore always used
  for the respective operations.
! .IP "\fB\-mnan=2008\fR" 4
  .IX Item "-mnan=2008"
  .PD 0
! .IP "\fB\-mnan=legacy\fR" 4
  .IX Item "-mnan=legacy"
  .PD
! These options control the encoding of the special not-a-number (NaN)
! \&\s-1IEEE 754\s0 floating-point data.
  .Sp
  The \fB\-mnan=legacy\fR option selects the legacy encoding.  In this
  case quiet NaNs (qNaNs) are denoted by the first bit of their trailing
  significand field being 0, whereas signaling NaNs (sNaNs) are denoted
  by the first bit of their trailing significand field being 1.
  .Sp
! The \fB\-mnan=2008\fR option selects the \s-1IEEE 754\-2008\s0 encoding.  In
  this case qNaNs are denoted by the first bit of their trailing
  significand field being 1, whereas sNaNs are denoted by the first bit of
  their trailing significand field being 0.
  .Sp
! The default is \fB\-mnan=legacy\fR unless \s-1GCC\s0 has been configured with
  \&\fB\-\-with\-nan=2008\fR.
! .IP "\fB\-mllsc\fR" 4
  .IX Item "-mllsc"
  .PD 0
! .IP "\fB\-mno\-llsc\fR" 4
  .IX Item "-mno-llsc"
  .PD
  Use (do not use) \fBll\fR, \fBsc\fR, and \fBsync\fR instructions to
! implement atomic memory built-in functions.  When neither option is
! specified, \s-1GCC\s0 uses the instructions if the target architecture
  supports them.
  .Sp
  \&\fB\-mllsc\fR is useful if the runtime environment can emulate the
  instructions and \fB\-mno\-llsc\fR can be useful when compiling for
  nonstandard ISAs.  You can make either option the default by
! configuring \s-1GCC\s0 with \fB\-\-with\-llsc\fR and \fB\-\-without\-llsc\fR
  respectively.  \fB\-\-with\-llsc\fR is the default for some
  configurations; see the installation documentation for details.
! .IP "\fB\-mdsp\fR" 4
  .IX Item "-mdsp"
  .PD 0
! .IP "\fB\-mno\-dsp\fR" 4
  .IX Item "-mno-dsp"
  .PD
! Use (do not use) revision 1 of the \s-1MIPS DSP ASE.\s0
    This option defines the
  preprocessor macro \f(CW\*(C`_\|_mips_dsp\*(C'\fR.  It also defines
  \&\f(CW\*(C`_\|_mips_dsp_rev\*(C'\fR to 1.
! .IP "\fB\-mdspr2\fR" 4
  .IX Item "-mdspr2"
  .PD 0
! .IP "\fB\-mno\-dspr2\fR" 4
  .IX Item "-mno-dspr2"
  .PD
! Use (do not use) revision 2 of the \s-1MIPS DSP ASE.\s0
    This option defines the
  preprocessor macros \f(CW\*(C`_\|_mips_dsp\*(C'\fR and \f(CW\*(C`_\|_mips_dspr2\*(C'\fR.
  It also defines \f(CW\*(C`_\|_mips_dsp_rev\*(C'\fR to 2.
! .IP "\fB\-msmartmips\fR" 4
  .IX Item "-msmartmips"
  .PD 0
! .IP "\fB\-mno\-smartmips\fR" 4
  .IX Item "-mno-smartmips"
  .PD
! Use (do not use) the \s-1MIPS\s0 SmartMIPS \s-1ASE.\s0
! .IP "\fB\-mpaired\-single\fR" 4
  .IX Item "-mpaired-single"
  .PD 0
! .IP "\fB\-mno\-paired\-single\fR" 4
  .IX Item "-mno-paired-single"
  .PD
! Use (do not use) paired-single floating-point instructions.
    This option requires
! hardware floating-point support to be enabled.
! .IP "\fB\-mdmx\fR" 4
  .IX Item "-mdmx"
  .PD 0
! .IP "\fB\-mno\-mdmx\fR" 4
  .IX Item "-mno-mdmx"
  .PD
! Use (do not use) \s-1MIPS\s0 Digital Media Extension instructions.
  This option can only be used when generating 64\-bit code and requires
! hardware floating-point support to be enabled.
! .IP "\fB\-mips3d\fR" 4
  .IX Item "-mips3d"
  .PD 0
! .IP "\fB\-mno\-mips3d\fR" 4
  .IX Item "-mno-mips3d"
  .PD
! Use (do not use) the \s-1MIPS\-3D ASE.\s0  
  The option \fB\-mips3d\fR implies \fB\-mpaired\-single\fR.
! .IP "\fB\-mmicromips\fR" 4
  .IX Item "-mmicromips"
  .PD 0
! .IP "\fB\-mno\-micromips\fR" 4
  .IX Item "-mno-micromips"
  .PD
  Generate (do not generate) microMIPS code.
  .Sp
! MicroMIPS code generation can also be controlled on a per-function basis
  by means of \f(CW\*(C`micromips\*(C'\fR and \f(CW\*(C`nomicromips\*(C'\fR attributes.
! .IP "\fB\-mmt\fR" 4
  .IX Item "-mmt"
  .PD 0
! .IP "\fB\-mno\-mt\fR" 4
  .IX Item "-mno-mt"
  .PD
! Use (do not use) \s-1MT\s0 Multithreading instructions.
! .IP "\fB\-mmcu\fR" 4
  .IX Item "-mmcu"
  .PD 0
! .IP "\fB\-mno\-mcu\fR" 4
  .IX Item "-mno-mcu"
  .PD
! Use (do not use) the \s-1MIPS MCU ASE\s0 instructions.
! .IP "\fB\-meva\fR" 4
  .IX Item "-meva"
  .PD 0
! .IP "\fB\-mno\-eva\fR" 4
  .IX Item "-mno-eva"
  .PD
! Use (do not use) the \s-1MIPS\s0 Enhanced Virtual Addressing instructions.
! .IP "\fB\-mvirt\fR" 4
  .IX Item "-mvirt"
  .PD 0
! .IP "\fB\-mno\-virt\fR" 4
  .IX Item "-mno-virt"
  .PD
! Use (do not use) the \s-1MIPS\s0 Virtualization (\s-1VZ\s0) instructions.
! .IP "\fB\-mxpa\fR" 4
  .IX Item "-mxpa"
  .PD 0
! .IP "\fB\-mno\-xpa\fR" 4
  .IX Item "-mno-xpa"
  .PD
! Use (do not use) the \s-1MIPS\s0 eXtended Physical Address (\s-1XPA\s0) instructions.
! .IP "\fB\-mcrc\fR" 4
  .IX Item "-mcrc"
  .PD 0
! .IP "\fB\-mno\-crc\fR" 4
  .IX Item "-mno-crc"
  .PD
! Use (do not use) the \s-1MIPS\s0 Cyclic Redundancy Check (\s-1CRC\s0) instructions.
! .IP "\fB\-mginv\fR" 4
  .IX Item "-mginv"
  .PD 0
! .IP "\fB\-mno\-ginv\fR" 4
  .IX Item "-mno-ginv"
  .PD
! Use (do not use) the \s-1MIPS\s0 Global INValidate (\s-1GINV\s0) instructions.
! .IP "\fB\-mloongson\-mmi\fR" 4
  .IX Item "-mloongson-mmi"
  .PD 0
! .IP "\fB\-mno\-loongson\-mmi\fR" 4
  .IX Item "-mno-loongson-mmi"
  .PD
! Use (do not use) the \s-1MIPS\s0 Loongson MultiMedia extensions Instructions (\s-1MMI\s0).
! .IP "\fB\-mloongson\-ext\fR" 4
  .IX Item "-mloongson-ext"
  .PD 0
! .IP "\fB\-mno\-loongson\-ext\fR" 4
  .IX Item "-mno-loongson-ext"
  .PD
! Use (do not use) the \s-1MIPS\s0 Loongson EXTensions (\s-1EXT\s0) instructions.
! .IP "\fB\-mloongson\-ext2\fR" 4
  .IX Item "-mloongson-ext2"
  .PD 0
! .IP "\fB\-mno\-loongson\-ext2\fR" 4
  .IX Item "-mno-loongson-ext2"
  .PD
! Use (do not use) the \s-1MIPS\s0 Loongson EXTensions r2 (\s-1EXT2\s0) instructions.
! .IP "\fB\-mlong64\fR" 4
  .IX Item "-mlong64"
  Force \f(CW\*(C`long\*(C'\fR types to be 64 bits wide.  See \fB\-mlong32\fR for
  an explanation of the default and the way that the pointer size is
  determined.
! .IP "\fB\-mlong32\fR" 4
  .IX Item "-mlong32"
  Force \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`int\*(C'\fR, and pointer types to be 32 bits wide.
  .Sp
  The default size of \f(CW\*(C`int\*(C'\fRs, \f(CW\*(C`long\*(C'\fRs and pointers depends on
! the \s-1ABI.\s0  All the supported ABIs use 32\-bit \f(CW\*(C`int\*(C'\fRs.  The n64 \s-1ABI\s0
! uses 64\-bit \f(CW\*(C`long\*(C'\fRs, as does the 64\-bit \s-1EABI\s0; the others use
  32\-bit \f(CW\*(C`long\*(C'\fRs.  Pointers are the same size as \f(CW\*(C`long\*(C'\fRs,
  or the same size as integer registers, whichever is smaller.
! .IP "\fB\-msym32\fR" 4
  .IX Item "-msym32"
  .PD 0
! .IP "\fB\-mno\-sym32\fR" 4
  .IX Item "-mno-sym32"
  .PD
  Assume (do not assume) that all symbols have 32\-bit values, regardless
! of the selected \s-1ABI.\s0  This option is useful in combination with
! \&\fB\-mabi=64\fR and \fB\-mno\-abicalls\fR because it allows \s-1GCC\s0
  to generate shorter and faster references to symbolic addresses.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
! Put definitions of externally-visible data in a small data section
! if that data is no bigger than \fInum\fR bytes.  \s-1GCC\s0 can then generate
  more efficient accesses to the data; see \fB\-mgpopt\fR for details.
  .Sp
  The default \fB\-G\fR option depends on the configuration.
! .IP "\fB\-mlocal\-sdata\fR" 4
  .IX Item "-mlocal-sdata"
  .PD 0
! .IP "\fB\-mno\-local\-sdata\fR" 4
  .IX Item "-mno-local-sdata"
  .PD
  Extend (do not extend) the \fB\-G\fR behavior to local data too,
--- 26055,26344 ----
  .Sp
  Note that some linkers can create multiple GOTs.  If you have such a
  linker, you should only need to use \fB\-mxgot\fR when a single object
! file accesses more than 64k\*(Aqs worth of GOT entries.  Very few do.
  .Sp
! These options have no effect unless GCC is generating position
  independent code.
! .IP \fB\-mgp32\fR 4
  .IX Item "-mgp32"
! Assume that general\-purpose registers are 32 bits wide.
! .IP \fB\-mgp64\fR 4
  .IX Item "-mgp64"
! Assume that general\-purpose registers are 64 bits wide.
! .IP \fB\-mfp32\fR 4
  .IX Item "-mfp32"
! Assume that floating\-point registers are 32 bits wide.
! .IP \fB\-mfp64\fR 4
  .IX Item "-mfp64"
! Assume that floating\-point registers are 64 bits wide.
! .IP \fB\-mfpxx\fR 4
  .IX Item "-mfpxx"
! Do not assume the width of floating\-point registers.
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
! Use floating\-point coprocessor instructions.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
! Do not use floating\-point coprocessor instructions.  Implement
! floating\-point calculations using library calls instead.
! .IP \fB\-mno\-float\fR 4
  .IX Item "-mno-float"
  Equivalent to \fB\-msoft\-float\fR, but additionally asserts that the
! program being compiled does not perform any floating\-point operations.
! This option is presently supported only by some bare\-metal MIPS
  configurations, where it may select a special set of libraries
! that lack all floating\-point support (including, for example, the
! floating\-point \f(CW\*(C`printf\*(C'\fR formats).  
  If code compiled with \fB\-mno\-float\fR accidentally contains
! floating\-point operations, it is likely to suffer a link\-time
! or run\-time failure.
! .IP \fB\-msingle\-float\fR 4
  .IX Item "-msingle-float"
! Assume that the floating\-point coprocessor only supports single\-precision
  operations.
! .IP \fB\-mdouble\-float\fR 4
  .IX Item "-mdouble-float"
! Assume that the floating\-point coprocessor supports double\-precision
  operations.  This is the default.
! .IP \fB\-modd\-spreg\fR 4
  .IX Item "-modd-spreg"
  .PD 0
! .IP \fB\-mno\-odd\-spreg\fR 4
  .IX Item "-mno-odd-spreg"
  .PD
! Enable the use of odd\-numbered single\-precision floating\-point registers
! for the o32 ABI.  This is the default for processors that are known to
! support these registers.  When using the o32 FPXX ABI, \fB\-mno\-odd\-spreg\fR
  is set by default.
! .IP \fB\-mabs=2008\fR 4
  .IX Item "-mabs=2008"
  .PD 0
! .IP \fB\-mabs=legacy\fR 4
  .IX Item "-mabs=legacy"
  .PD
! These options control the treatment of the special not\-a\-number (NaN)
! IEEE 754 floating\-point data with the \f(CW\*(C`abs.\fR\f(CIfmt\fR\f(CW\*(C'\fR and
! \&\f(CW\*(C`neg.\fR\f(CIfmt\fR\f(CW\*(C'\fR machine instructions.
  .Sp
  By default or when \fB\-mabs=legacy\fR is used the legacy
  treatment is selected.  In this case these instructions are considered
  arithmetic and avoided where correct operation is required and the
  input operand might be a NaN.  A longer sequence of instructions that
! manipulate the sign bit of floating\-point datum manually is used
  instead unless the \fB\-ffinite\-math\-only\fR option has also been
  specified.
  .Sp
! The \fB\-mabs=2008\fR option selects the IEEE 754\-2008 treatment.  In
! this case these instructions are considered non\-arithmetic and therefore
  operating correctly in all cases, including in particular where the
  input operand is a NaN.  These instructions are therefore always used
  for the respective operations.
! .IP \fB\-mnan=2008\fR 4
  .IX Item "-mnan=2008"
  .PD 0
! .IP \fB\-mnan=legacy\fR 4
  .IX Item "-mnan=legacy"
  .PD
! These options control the encoding of the special not\-a\-number (NaN)
! IEEE 754 floating\-point data.
  .Sp
  The \fB\-mnan=legacy\fR option selects the legacy encoding.  In this
  case quiet NaNs (qNaNs) are denoted by the first bit of their trailing
  significand field being 0, whereas signaling NaNs (sNaNs) are denoted
  by the first bit of their trailing significand field being 1.
  .Sp
! The \fB\-mnan=2008\fR option selects the IEEE 754\-2008 encoding.  In
  this case qNaNs are denoted by the first bit of their trailing
  significand field being 1, whereas sNaNs are denoted by the first bit of
  their trailing significand field being 0.
  .Sp
! The default is \fB\-mnan=legacy\fR unless GCC has been configured with
  \&\fB\-\-with\-nan=2008\fR.
! .IP \fB\-mllsc\fR 4
  .IX Item "-mllsc"
  .PD 0
! .IP \fB\-mno\-llsc\fR 4
  .IX Item "-mno-llsc"
  .PD
  Use (do not use) \fBll\fR, \fBsc\fR, and \fBsync\fR instructions to
! implement atomic memory built\-in functions.  When neither option is
! specified, GCC uses the instructions if the target architecture
  supports them.
  .Sp
  \&\fB\-mllsc\fR is useful if the runtime environment can emulate the
  instructions and \fB\-mno\-llsc\fR can be useful when compiling for
  nonstandard ISAs.  You can make either option the default by
! configuring GCC with \fB\-\-with\-llsc\fR and \fB\-\-without\-llsc\fR
  respectively.  \fB\-\-with\-llsc\fR is the default for some
  configurations; see the installation documentation for details.
! .IP \fB\-mdsp\fR 4
  .IX Item "-mdsp"
  .PD 0
! .IP \fB\-mno\-dsp\fR 4
  .IX Item "-mno-dsp"
  .PD
! Use (do not use) revision 1 of the MIPS DSP ASE.
    This option defines the
  preprocessor macro \f(CW\*(C`_\|_mips_dsp\*(C'\fR.  It also defines
  \&\f(CW\*(C`_\|_mips_dsp_rev\*(C'\fR to 1.
! .IP \fB\-mdspr2\fR 4
  .IX Item "-mdspr2"
  .PD 0
! .IP \fB\-mno\-dspr2\fR 4
  .IX Item "-mno-dspr2"
  .PD
! Use (do not use) revision 2 of the MIPS DSP ASE.
    This option defines the
  preprocessor macros \f(CW\*(C`_\|_mips_dsp\*(C'\fR and \f(CW\*(C`_\|_mips_dspr2\*(C'\fR.
  It also defines \f(CW\*(C`_\|_mips_dsp_rev\*(C'\fR to 2.
! .IP \fB\-msmartmips\fR 4
  .IX Item "-msmartmips"
  .PD 0
! .IP \fB\-mno\-smartmips\fR 4
  .IX Item "-mno-smartmips"
  .PD
! Use (do not use) the MIPS SmartMIPS ASE.
! .IP \fB\-mpaired\-single\fR 4
  .IX Item "-mpaired-single"
  .PD 0
! .IP \fB\-mno\-paired\-single\fR 4
  .IX Item "-mno-paired-single"
  .PD
! Use (do not use) paired\-single floating\-point instructions.
    This option requires
! hardware floating\-point support to be enabled.
! .IP \fB\-mdmx\fR 4
  .IX Item "-mdmx"
  .PD 0
! .IP \fB\-mno\-mdmx\fR 4
  .IX Item "-mno-mdmx"
  .PD
! Use (do not use) 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.
! .IP \fB\-mips3d\fR 4
  .IX Item "-mips3d"
  .PD 0
! .IP \fB\-mno\-mips3d\fR 4
  .IX Item "-mno-mips3d"
  .PD
! Use (do not use) the MIPS\-3D ASE.  
  The option \fB\-mips3d\fR implies \fB\-mpaired\-single\fR.
! .IP \fB\-mmicromips\fR 4
  .IX Item "-mmicromips"
  .PD 0
! .IP \fB\-mno\-micromips\fR 4
  .IX Item "-mno-micromips"
  .PD
  Generate (do not generate) microMIPS code.
  .Sp
! MicroMIPS code generation can also be controlled on a per\-function basis
  by means of \f(CW\*(C`micromips\*(C'\fR and \f(CW\*(C`nomicromips\*(C'\fR attributes.
! .IP \fB\-mmt\fR 4
  .IX Item "-mmt"
  .PD 0
! .IP \fB\-mno\-mt\fR 4
  .IX Item "-mno-mt"
  .PD
! Use (do not use) MT Multithreading instructions.
! .IP \fB\-mmcu\fR 4
  .IX Item "-mmcu"
  .PD 0
! .IP \fB\-mno\-mcu\fR 4
  .IX Item "-mno-mcu"
  .PD
! Use (do not use) the MIPS MCU ASE instructions.
! .IP \fB\-meva\fR 4
  .IX Item "-meva"
  .PD 0
! .IP \fB\-mno\-eva\fR 4
  .IX Item "-mno-eva"
  .PD
! Use (do not use) the MIPS Enhanced Virtual Addressing instructions.
! .IP \fB\-mvirt\fR 4
  .IX Item "-mvirt"
  .PD 0
! .IP \fB\-mno\-virt\fR 4
  .IX Item "-mno-virt"
  .PD
! Use (do not use) the MIPS Virtualization (VZ) instructions.
! .IP \fB\-mxpa\fR 4
  .IX Item "-mxpa"
  .PD 0
! .IP \fB\-mno\-xpa\fR 4
  .IX Item "-mno-xpa"
  .PD
! Use (do not use) the MIPS eXtended Physical Address (XPA) instructions.
! .IP \fB\-mcrc\fR 4
  .IX Item "-mcrc"
  .PD 0
! .IP \fB\-mno\-crc\fR 4
  .IX Item "-mno-crc"
  .PD
! Use (do not use) the MIPS Cyclic Redundancy Check (CRC) instructions.
! .IP \fB\-mginv\fR 4
  .IX Item "-mginv"
  .PD 0
! .IP \fB\-mno\-ginv\fR 4
  .IX Item "-mno-ginv"
  .PD
! Use (do not use) the MIPS Global INValidate (GINV) instructions.
! .IP \fB\-mloongson\-mmi\fR 4
  .IX Item "-mloongson-mmi"
  .PD 0
! .IP \fB\-mno\-loongson\-mmi\fR 4
  .IX Item "-mno-loongson-mmi"
  .PD
! Use (do not use) the MIPS Loongson MultiMedia extensions Instructions (MMI).
! .IP \fB\-mloongson\-ext\fR 4
  .IX Item "-mloongson-ext"
  .PD 0
! .IP \fB\-mno\-loongson\-ext\fR 4
  .IX Item "-mno-loongson-ext"
  .PD
! Use (do not use) the MIPS Loongson EXTensions (EXT) instructions.
! .IP \fB\-mloongson\-ext2\fR 4
  .IX Item "-mloongson-ext2"
  .PD 0
! .IP \fB\-mno\-loongson\-ext2\fR 4
  .IX Item "-mno-loongson-ext2"
  .PD
! Use (do not use) the MIPS Loongson EXTensions r2 (EXT2) instructions.
! .IP \fB\-mlong64\fR 4
  .IX Item "-mlong64"
  Force \f(CW\*(C`long\*(C'\fR types to be 64 bits wide.  See \fB\-mlong32\fR for
  an explanation of the default and the way that the pointer size is
  determined.
! .IP \fB\-mlong32\fR 4
  .IX Item "-mlong32"
  Force \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`int\*(C'\fR, and pointer types to be 32 bits wide.
  .Sp
  The default size of \f(CW\*(C`int\*(C'\fRs, \f(CW\*(C`long\*(C'\fRs and pointers depends on
! the ABI.  All the supported ABIs use 32\-bit \f(CW\*(C`int\*(C'\fRs.  The n64 ABI
! uses 64\-bit \f(CW\*(C`long\*(C'\fRs, as does the 64\-bit EABI; the others use
  32\-bit \f(CW\*(C`long\*(C'\fRs.  Pointers are the same size as \f(CW\*(C`long\*(C'\fRs,
  or the same size as integer registers, whichever is smaller.
! .IP \fB\-msym32\fR 4
  .IX Item "-msym32"
  .PD 0
! .IP \fB\-mno\-sym32\fR 4
  .IX Item "-mno-sym32"
  .PD
  Assume (do not assume) that all symbols have 32\-bit values, regardless
! of the selected ABI.  This option is useful in combination with
! \&\fB\-mabi=64\fR and \fB\-mno\-abicalls\fR because it allows GCC
  to generate shorter and faster references to symbolic addresses.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
! Put definitions of externally\-visible data in a small data section
! if that data is no bigger than \fInum\fR bytes.  GCC can then generate
  more efficient accesses to the data; see \fB\-mgpopt\fR for details.
  .Sp
  The default \fB\-G\fR option depends on the configuration.
! .IP \fB\-mlocal\-sdata\fR 4
  .IX Item "-mlocal-sdata"
  .PD 0
! .IP \fB\-mno\-local\-sdata\fR 4
  .IX Item "-mno-local-sdata"
  .PD
  Extend (do not extend) the \fB\-G\fR behavior to local data too,
*************** such as to static variables in C.  \fB\-
*** 26415,26431 ****
  default for all configurations.
  .Sp
  If the linker complains that an application is using too much small data,
! you might want to try rebuilding the less performance-critical parts with
  \&\fB\-mno\-local\-sdata\fR.  You might also want to build large
  libraries with \fB\-mno\-local\-sdata\fR, so that the libraries leave
  more room for the main program.
! .IP "\fB\-mextern\-sdata\fR" 4
  .IX Item "-mextern-sdata"
  .PD 0
! .IP "\fB\-mno\-extern\-sdata\fR" 4
  .IX Item "-mno-extern-sdata"
  .PD
! Assume (do not assume) that externally-defined data is in
  a small data section if the size of that data is within the \fB\-G\fR limit.
  \&\fB\-mextern\-sdata\fR is the default for all configurations.
  .Sp
--- 26346,26362 ----
  default for all configurations.
  .Sp
  If the linker complains that an application is using too much small data,
! you might want to try rebuilding the less performance\-critical parts with
  \&\fB\-mno\-local\-sdata\fR.  You might also want to build large
  libraries with \fB\-mno\-local\-sdata\fR, so that the libraries leave
  more room for the main program.
! .IP \fB\-mextern\-sdata\fR 4
  .IX Item "-mextern-sdata"
  .PD 0
! .IP \fB\-mno\-extern\-sdata\fR 4
  .IX Item "-mno-extern-sdata"
  .PD
! Assume (do not assume) that externally\-defined data is in
  a small data section if the size of that data is within the \fB\-G\fR limit.
  \&\fB\-mextern\-sdata\fR is the default for all configurations.
  .Sp
*************** If you compile a module \fIMod\fR with \
*** 26433,26442 ****
  \&\fInum\fR \fB\-mgpopt\fR, and \fIMod\fR references a variable \fIVar\fR
  that is no bigger than \fInum\fR bytes, you must make sure that \fIVar\fR
  is placed in a small data section.  If \fIVar\fR is defined by another
! module, you must either compile that module with a high-enough
! \&\fB\-G\fR setting or attach a \f(CW\*(C`section\*(C'\fR attribute to \fIVar\fR's
  definition.  If \fIVar\fR is common, you must link the application
! with a high-enough \fB\-G\fR setting.
  .Sp
  The easiest way of satisfying these restrictions is to compile
  and link every module with the same \fB\-G\fR option.  However,
--- 26364,26373 ----
  \&\fInum\fR \fB\-mgpopt\fR, and \fIMod\fR references a variable \fIVar\fR
  that is no bigger than \fInum\fR bytes, you must make sure that \fIVar\fR
  is placed in a small data section.  If \fIVar\fR is defined by another
! module, you must either compile that module with a high\-enough
! \&\fB\-G\fR setting or attach a \f(CW\*(C`section\*(C'\fR attribute to \fIVar\fR\*(Aqs
  definition.  If \fIVar\fR is common, you must link the application
! with a high\-enough \fB\-G\fR setting.
  .Sp
  The easiest way of satisfying these restrictions is to compile
  and link every module with the same \fB\-G\fR option.  However,
*************** you may wish to build a library that sup
*** 26444,26457 ****
  small data limits.  You can do this by compiling the library with
  the highest supported \fB\-G\fR setting and additionally using
  \&\fB\-mno\-extern\-sdata\fR to stop the library from making assumptions
! about externally-defined data.
! .IP "\fB\-mgpopt\fR" 4
  .IX Item "-mgpopt"
  .PD 0
! .IP "\fB\-mno\-gpopt\fR" 4
  .IX Item "-mno-gpopt"
  .PD
! Use (do not use) GP-relative accesses for symbols that are known to be
  in a small data section; see \fB\-G\fR, \fB\-mlocal\-sdata\fR and
  \&\fB\-mextern\-sdata\fR.  \fB\-mgpopt\fR is the default for all
  configurations.
--- 26375,26388 ----
  small data limits.  You can do this by compiling the library with
  the highest supported \fB\-G\fR setting and additionally using
  \&\fB\-mno\-extern\-sdata\fR to stop the library from making assumptions
! about externally\-defined data.
! .IP \fB\-mgpopt\fR 4
  .IX Item "-mgpopt"
  .PD 0
! .IP \fB\-mno\-gpopt\fR 4
  .IX Item "-mno-gpopt"
  .PD
! Use (do not use) GP\-relative accesses for symbols that are known to be
  in a small data section; see \fB\-G\fR, \fB\-mlocal\-sdata\fR and
  \&\fB\-mextern\-sdata\fR.  \fB\-mgpopt\fR is the default for all
  configurations.
*************** with \fB\-G0\fR.)
*** 26465,26553 ****
  .Sp
  \&\fB\-mno\-gpopt\fR implies \fB\-mno\-local\-sdata\fR and
  \&\fB\-mno\-extern\-sdata\fR.
! .IP "\fB\-membedded\-data\fR" 4
  .IX Item "-membedded-data"
  .PD 0
! .IP "\fB\-mno\-embedded\-data\fR" 4
  .IX Item "-mno-embedded-data"
  .PD
! Allocate variables to the read-only data section first if possible, then
  next in the small data section if possible, otherwise in data.  This gives
! slightly slower code than the default, but reduces the amount of \s-1RAM\s0 required
  when executing, and thus may be preferred for some embedded systems.
! .IP "\fB\-muninit\-const\-in\-rodata\fR" 4
  .IX Item "-muninit-const-in-rodata"
  .PD 0
! .IP "\fB\-mno\-uninit\-const\-in\-rodata\fR" 4
  .IX Item "-mno-uninit-const-in-rodata"
  .PD
! Put uninitialized \f(CW\*(C`const\*(C'\fR variables in the read-only data section.
  This option is only meaningful in conjunction with \fB\-membedded\-data\fR.
! .IP "\fB\-mcode\-readable=\fR\fIsetting\fR" 4
  .IX Item "-mcode-readable=setting"
! Specify whether \s-1GCC\s0 may generate code that reads from executable sections.
  There are three possible settings:
  .RS 4
! .IP "\fB\-mcode\-readable=yes\fR" 4
  .IX Item "-mcode-readable=yes"
  Instructions may freely access executable sections.  This is the
  default setting.
! .IP "\fB\-mcode\-readable=pcrel\fR" 4
  .IX Item "-mcode-readable=pcrel"
! \&\s-1MIPS16\s0 PC-relative load instructions can access executable sections,
  but other instructions must not do so.  This option is useful on 4KSc
  and 4KSd processors when the code TLBs have the Read Inhibit bit set.
  It is also useful on processors that can be configured to have a dual
! instruction/data \s-1SRAM\s0 interface and that, like the M4K, automatically
! redirect PC-relative loads to the instruction \s-1RAM.\s0
! .IP "\fB\-mcode\-readable=no\fR" 4
  .IX Item "-mcode-readable=no"
  Instructions must not access executable sections.  This option can be
  useful on targets that are configured to have a dual instruction/data
! \&\s-1SRAM\s0 interface but that (unlike the M4K) do not automatically redirect
! PC-relative loads to the instruction \s-1RAM.\s0
  .RE
  .RS 4
  .RE
! .IP "\fB\-msplit\-addresses\fR" 4
  .IX Item "-msplit-addresses"
  .PD 0
! .IP "\fB\-mno\-split\-addresses\fR" 4
  .IX Item "-mno-split-addresses"
  .PD
! Enable (disable) use of the \f(CW\*(C`%hi()\*(C'\fR and \f(CW\*(C`%lo()\*(C'\fR assembler
  relocation operators.  This option has been superseded by
  \&\fB\-mexplicit\-relocs\fR but is retained for backwards compatibility.
! .IP "\fB\-mexplicit\-relocs\fR" 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP "\fB\-mno\-explicit\-relocs\fR" 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Use (do not use) assembler relocation operators when dealing with symbolic
  addresses.  The alternative, selected by \fB\-mno\-explicit\-relocs\fR,
  is to use assembler macros instead.
  .Sp
! \&\fB\-mexplicit\-relocs\fR is the default if \s-1GCC\s0 was configured
  to use an assembler that supports relocation operators.
! .IP "\fB\-mcheck\-zero\-division\fR" 4
  .IX Item "-mcheck-zero-division"
  .PD 0
! .IP "\fB\-mno\-check\-zero\-division\fR" 4
  .IX Item "-mno-check-zero-division"
  .PD
  Trap (do not trap) on integer division by zero.
  .Sp
  The default is \fB\-mcheck\-zero\-division\fR.
! .IP "\fB\-mdivide\-traps\fR" 4
  .IX Item "-mdivide-traps"
  .PD 0
! .IP "\fB\-mdivide\-breaks\fR" 4
  .IX Item "-mdivide-breaks"
  .PD
! \&\s-1MIPS\s0 systems check for division by zero by generating either a
  conditional trap or a break instruction.  Using traps results in
! smaller code, but is only supported on \s-1MIPS II\s0 and later.  Also, some
  versions of the Linux kernel have a bug that prevents trap from
  generating the proper signal (\f(CW\*(C`SIGFPE\*(C'\fR).  Use \fB\-mdivide\-traps\fR to
  allow conditional traps on architectures that support them and
--- 26396,26484 ----
  .Sp
  \&\fB\-mno\-gpopt\fR implies \fB\-mno\-local\-sdata\fR and
  \&\fB\-mno\-extern\-sdata\fR.
! .IP \fB\-membedded\-data\fR 4
  .IX Item "-membedded-data"
  .PD 0
! .IP \fB\-mno\-embedded\-data\fR 4
  .IX Item "-mno-embedded-data"
  .PD
! Allocate variables to the read\-only data section first if possible, then
  next in the small data section if possible, otherwise in data.  This gives
! slightly slower code than the default, but reduces the amount of RAM required
  when executing, and thus may be preferred for some embedded systems.
! .IP \fB\-muninit\-const\-in\-rodata\fR 4
  .IX Item "-muninit-const-in-rodata"
  .PD 0
! .IP \fB\-mno\-uninit\-const\-in\-rodata\fR 4
  .IX Item "-mno-uninit-const-in-rodata"
  .PD
! Put uninitialized \f(CW\*(C`const\*(C'\fR variables in the read\-only data section.
  This option is only meaningful in conjunction with \fB\-membedded\-data\fR.
! .IP \fB\-mcode\-readable=\fR\fIsetting\fR 4
  .IX Item "-mcode-readable=setting"
! Specify whether GCC may generate code that reads from executable sections.
  There are three possible settings:
  .RS 4
! .IP \fB\-mcode\-readable=yes\fR 4
  .IX Item "-mcode-readable=yes"
  Instructions may freely access executable sections.  This is the
  default setting.
! .IP \fB\-mcode\-readable=pcrel\fR 4
  .IX Item "-mcode-readable=pcrel"
! 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.
! .IP \fB\-mcode\-readable=no\fR 4
  .IX Item "-mcode-readable=no"
  Instructions must not access executable sections.  This option can be
  useful on targets that are configured to have a dual instruction/data
! SRAM interface but that (unlike the M4K) do not automatically redirect
! PC\-relative loads to the instruction RAM.
  .RE
  .RS 4
  .RE
! .IP \fB\-msplit\-addresses\fR 4
  .IX Item "-msplit-addresses"
  .PD 0
! .IP \fB\-mno\-split\-addresses\fR 4
  .IX Item "-mno-split-addresses"
  .PD
! Enable (disable) use of the \f(CW%hi()\fR and \f(CW%lo()\fR assembler
  relocation operators.  This option has been superseded by
  \&\fB\-mexplicit\-relocs\fR but is retained for backwards compatibility.
! .IP \fB\-mexplicit\-relocs\fR 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP \fB\-mno\-explicit\-relocs\fR 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Use (do not use) assembler relocation operators when dealing with symbolic
  addresses.  The alternative, selected by \fB\-mno\-explicit\-relocs\fR,
  is to use assembler macros instead.
  .Sp
! \&\fB\-mexplicit\-relocs\fR is the default if GCC was configured
  to use an assembler that supports relocation operators.
! .IP \fB\-mcheck\-zero\-division\fR 4
  .IX Item "-mcheck-zero-division"
  .PD 0
! .IP \fB\-mno\-check\-zero\-division\fR 4
  .IX Item "-mno-check-zero-division"
  .PD
  Trap (do not trap) on integer division by zero.
  .Sp
  The default is \fB\-mcheck\-zero\-division\fR.
! .IP \fB\-mdivide\-traps\fR 4
  .IX Item "-mdivide-traps"
  .PD 0
! .IP \fB\-mdivide\-breaks\fR 4
  .IX Item "-mdivide-breaks"
  .PD
! 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 (\f(CW\*(C`SIGFPE\*(C'\fR).  Use \fB\-mdivide\-traps\fR to
  allow conditional traps on architectures that support them and
*************** allow conditional traps on architectures
*** 26555,26595 ****
  .Sp
  The default is usually \fB\-mdivide\-traps\fR, but this can be
  overridden at configure time using \fB\-\-with\-divide=breaks\fR.
! Divide-by-zero checks can be completely disabled using
  \&\fB\-mno\-check\-zero\-division\fR.
! .IP "\fB\-mload\-store\-pairs\fR" 4
  .IX Item "-mload-store-pairs"
  .PD 0
! .IP "\fB\-mno\-load\-store\-pairs\fR" 4
  .IX Item "-mno-load-store-pairs"
  .PD
  Enable (disable) an optimization that pairs consecutive load or store
  instructions to enable load/store bonding.  This option is enabled by
  default but only takes effect when the selected architecture is known
  to support bonding.
! .IP "\fB\-munaligned\-access\fR" 4
  .IX Item "-munaligned-access"
  .PD 0
! .IP "\fB\-mno\-unaligned\-access\fR" 4
  .IX Item "-mno-unaligned-access"
  .PD
! Enable (disable) direct unaligned access for \s-1MIPS\s0 Release 6.
! MIPSr6 requires load/store unaligned-access support,
  by hardware or trap&emulate.
  So \fB\-mno\-unaligned\-access\fR may be needed by kernel.
! .IP "\fB\-mmemcpy\fR" 4
  .IX Item "-mmemcpy"
  .PD 0
! .IP "\fB\-mno\-memcpy\fR" 4
  .IX Item "-mno-memcpy"
  .PD
! Force (do not force) the use of \f(CW\*(C`memcpy\*(C'\fR for non-trivial block
! moves.  The default is \fB\-mno\-memcpy\fR, which allows \s-1GCC\s0 to inline
! most constant-sized copies.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP "\fB\-mno\-long\-calls\fR" 4
  .IX Item "-mno-long-calls"
  .PD
  Disable (do not disable) use of the \f(CW\*(C`jal\*(C'\fR instruction.  Calling
--- 26486,26526 ----
  .Sp
  The default is usually \fB\-mdivide\-traps\fR, but this can be
  overridden at configure time using \fB\-\-with\-divide=breaks\fR.
! Divide\-by\-zero checks can be completely disabled using
  \&\fB\-mno\-check\-zero\-division\fR.
! .IP \fB\-mload\-store\-pairs\fR 4
  .IX Item "-mload-store-pairs"
  .PD 0
! .IP \fB\-mno\-load\-store\-pairs\fR 4
  .IX Item "-mno-load-store-pairs"
  .PD
  Enable (disable) an optimization that pairs consecutive load or store
  instructions to enable load/store bonding.  This option is enabled by
  default but only takes effect when the selected architecture is known
  to support bonding.
! .IP \fB\-munaligned\-access\fR 4
  .IX Item "-munaligned-access"
  .PD 0
! .IP \fB\-mno\-unaligned\-access\fR 4
  .IX Item "-mno-unaligned-access"
  .PD
! Enable (disable) direct unaligned access for MIPS Release 6.
! MIPSr6 requires load/store unaligned\-access support,
  by hardware or trap&emulate.
  So \fB\-mno\-unaligned\-access\fR may be needed by kernel.
! .IP \fB\-mmemcpy\fR 4
  .IX Item "-mmemcpy"
  .PD 0
! .IP \fB\-mno\-memcpy\fR 4
  .IX Item "-mno-memcpy"
  .PD
! Force (do not force) the use of \f(CW\*(C`memcpy\*(C'\fR for non\-trivial block
! moves.  The default is \fB\-mno\-memcpy\fR, which allows GCC to inline
! most constant\-sized copies.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP \fB\-mno\-long\-calls\fR 4
  .IX Item "-mno-long-calls"
  .PD
  Disable (do not disable) use of the \f(CW\*(C`jal\*(C'\fR instruction.  Calling
*************** and callee to be in the same 256 megabyt
*** 26598,26706 ****
  .Sp
  This option has no effect on abicalls code.  The default is
  \&\fB\-mno\-long\-calls\fR.
! .IP "\fB\-mmad\fR" 4
  .IX Item "-mmad"
  .PD 0
! .IP "\fB\-mno\-mad\fR" 4
  .IX Item "-mno-mad"
  .PD
  Enable (disable) use of the \f(CW\*(C`mad\*(C'\fR, \f(CW\*(C`madu\*(C'\fR and \f(CW\*(C`mul\*(C'\fR
! instructions, as provided by the R4650 \s-1ISA.\s0
! .IP "\fB\-mimadd\fR" 4
  .IX Item "-mimadd"
  .PD 0
! .IP "\fB\-mno\-imadd\fR" 4
  .IX Item "-mno-imadd"
  .PD
  Enable (disable) use of the \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR integer
  instructions.  The default is \fB\-mimadd\fR on architectures
  that support \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR except for the 74k 
  architecture where it was found to generate slower code.
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
! Enable (disable) use of the floating-point multiply-accumulate
  instructions, when they are available.  The default is
  \&\fB\-mfused\-madd\fR.
  .Sp
! On the R8000 \s-1CPU\s0 when multiply-accumulate instructions are used,
  the intermediate product is calculated to infinite precision
! and is not subject to the \s-1FCSR\s0 Flush to Zero bit.  This may be
  undesirable in some circumstances.  On other processors the result
  is numerically identical to the equivalent computation using
  separate multiply, add, subtract and negate instructions.
! .IP "\fB\-nocpp\fR" 4
  .IX Item "-nocpp"
! Tell the \s-1MIPS\s0 assembler to not run its preprocessor over user
  assembler files (with a \fB.s\fR suffix) when assembling them.
! .IP "\fB\-mfix\-24k\fR" 4
  .IX Item "-mfix-24k"
  .PD 0
! .IP "\fB\-mno\-fix\-24k\fR" 4
  .IX Item "-mno-fix-24k"
  .PD
  Work around the 24K E48 (lost data on stores during refill) errata.
! The workarounds are implemented by the assembler rather than by \s-1GCC.\s0
! .IP "\fB\-mfix\-r4000\fR" 4
  .IX Item "-mfix-r4000"
  .PD 0
! .IP "\fB\-mno\-fix\-r4000\fR" 4
  .IX Item "-mno-fix-r4000"
  .PD
! Work around certain R4000 \s-1CPU\s0 errata:
  .RS 4
! .IP "\-" 4
! A double-word or a variable shift may give an incorrect result if executed
  immediately after starting an integer division.
! .IP "\-" 4
! A double-word or a variable shift may give an incorrect result if executed
  while an integer multiplication is in progress.
! .IP "\-" 4
  An integer division may give an incorrect result if started in a delay slot
  of a taken branch or a jump.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mfix\-r4400\fR" 4
  .IX Item "-mfix-r4400"
  .PD 0
! .IP "\fB\-mno\-fix\-r4400\fR" 4
  .IX Item "-mno-fix-r4400"
  .PD
! Work around certain R4400 \s-1CPU\s0 errata:
  .RS 4
! .IP "\-" 4
! A double-word or a variable shift may give an incorrect result if executed
  immediately after starting an integer division.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mfix\-r10000\fR" 4
  .IX Item "-mfix-r10000"
  .PD 0
! .IP "\fB\-mno\-fix\-r10000\fR" 4
  .IX Item "-mno-fix-r10000"
  .PD
  Work around certain R10000 errata:
  .RS 4
! .IP "\-" 4
  \&\f(CW\*(C`ll\*(C'\fR/\f(CW\*(C`sc\*(C'\fR sequences may not behave atomically on revisions
  prior to 3.0.  They may deadlock on revisions 2.6 and earlier.
  .RE
  .RS 4
  .Sp
  This option can only be used if the target architecture supports
! branch-likely instructions.  \fB\-mfix\-r10000\fR is the default when
  \&\fB\-march=r10000\fR is used; \fB\-mno\-fix\-r10000\fR is the default
  otherwise.
  .RE
! .IP "\fB\-mfix\-r5900\fR" 4
  .IX Item "-mfix-r5900"
  .PD 0
! .IP "\fB\-mno\-fix\-r5900\fR" 4
  .IX Item "-mno-fix-r5900"
  .PD
  Do not attempt to schedule the preceding instruction into the delay slot
--- 26529,26637 ----
  .Sp
  This option has no effect on abicalls code.  The default is
  \&\fB\-mno\-long\-calls\fR.
! .IP \fB\-mmad\fR 4
  .IX Item "-mmad"
  .PD 0
! .IP \fB\-mno\-mad\fR 4
  .IX Item "-mno-mad"
  .PD
  Enable (disable) use of the \f(CW\*(C`mad\*(C'\fR, \f(CW\*(C`madu\*(C'\fR and \f(CW\*(C`mul\*(C'\fR
! instructions, as provided by the R4650 ISA.
! .IP \fB\-mimadd\fR 4
  .IX Item "-mimadd"
  .PD 0
! .IP \fB\-mno\-imadd\fR 4
  .IX Item "-mno-imadd"
  .PD
  Enable (disable) use of the \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR integer
  instructions.  The default is \fB\-mimadd\fR on architectures
  that support \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR except for the 74k 
  architecture where it was found to generate slower code.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
! Enable (disable) use of the floating\-point multiply\-accumulate
  instructions, when they are available.  The default is
  \&\fB\-mfused\-madd\fR.
  .Sp
! On the R8000 CPU when multiply\-accumulate instructions are used,
  the intermediate product is calculated to infinite precision
! and is not subject to the FCSR Flush to Zero bit.  This may be
  undesirable in some circumstances.  On other processors the result
  is numerically identical to the equivalent computation using
  separate multiply, add, subtract and negate instructions.
! .IP \fB\-nocpp\fR 4
  .IX Item "-nocpp"
! Tell the MIPS assembler to not run its preprocessor over user
  assembler files (with a \fB.s\fR suffix) when assembling them.
! .IP \fB\-mfix\-24k\fR 4
  .IX Item "-mfix-24k"
  .PD 0
! .IP \fB\-mno\-fix\-24k\fR 4
  .IX Item "-mno-fix-24k"
  .PD
  Work around the 24K E48 (lost data on stores during refill) errata.
! The workarounds are implemented by the assembler rather than by GCC.
! .IP \fB\-mfix\-r4000\fR 4
  .IX Item "-mfix-r4000"
  .PD 0
! .IP \fB\-mno\-fix\-r4000\fR 4
  .IX Item "-mno-fix-r4000"
  .PD
! Work around certain R4000 CPU errata:
  .RS 4
! .IP \- 4
! A double\-word or a variable shift may give an incorrect result if executed
  immediately after starting an integer division.
! .IP \- 4
! A double\-word or a variable shift may give an incorrect result if executed
  while an integer multiplication is in progress.
! .IP \- 4
  An integer division may give an incorrect result if started in a delay slot
  of a taken branch or a jump.
  .RE
  .RS 4
  .RE
! .IP \fB\-mfix\-r4400\fR 4
  .IX Item "-mfix-r4400"
  .PD 0
! .IP \fB\-mno\-fix\-r4400\fR 4
  .IX Item "-mno-fix-r4400"
  .PD
! Work around certain R4400 CPU errata:
  .RS 4
! .IP \- 4
! A double\-word or a variable shift may give an incorrect result if executed
  immediately after starting an integer division.
  .RE
  .RS 4
  .RE
! .IP \fB\-mfix\-r10000\fR 4
  .IX Item "-mfix-r10000"
  .PD 0
! .IP \fB\-mno\-fix\-r10000\fR 4
  .IX Item "-mno-fix-r10000"
  .PD
  Work around certain R10000 errata:
  .RS 4
! .IP \- 4
  \&\f(CW\*(C`ll\*(C'\fR/\f(CW\*(C`sc\*(C'\fR sequences may not behave atomically on revisions
  prior to 3.0.  They may deadlock on revisions 2.6 and earlier.
  .RE
  .RS 4
  .Sp
  This option can only be used if the target architecture supports
! branch\-likely instructions.  \fB\-mfix\-r10000\fR is the default when
  \&\fB\-march=r10000\fR is used; \fB\-mno\-fix\-r10000\fR is the default
  otherwise.
  .RE
! .IP \fB\-mfix\-r5900\fR 4
  .IX Item "-mfix-r5900"
  .PD 0
! .IP \fB\-mno\-fix\-r5900\fR 4
  .IX Item "-mno-fix-r5900"
  .PD
  Do not attempt to schedule the preceding instruction into the delay slot
*************** of a branch instruction placed at the en
*** 26708,26733 ****
  instructions or fewer and always schedule a \f(CW\*(C`nop\*(C'\fR instruction there
  instead.  The short loop bug under certain conditions causes loops to
  execute only once or twice, due to a hardware bug in the R5900 chip.  The
! workaround is implemented by the assembler rather than by \s-1GCC.\s0
! .IP "\fB\-mfix\-rm7000\fR" 4
  .IX Item "-mfix-rm7000"
  .PD 0
! .IP "\fB\-mno\-fix\-rm7000\fR" 4
  .IX Item "-mno-fix-rm7000"
  .PD
! Work around the \s-1RM7000\s0 \f(CW\*(C`dmult\*(C'\fR/\f(CW\*(C`dmultu\*(C'\fR errata.  The
! workarounds are implemented by the assembler rather than by \s-1GCC.\s0
! .IP "\fB\-mfix\-vr4120\fR" 4
  .IX Item "-mfix-vr4120"
  .PD 0
! .IP "\fB\-mno\-fix\-vr4120\fR" 4
  .IX Item "-mno-fix-vr4120"
  .PD
! Work around certain \s-1VR4120\s0 errata:
  .RS 4
! .IP "\-" 4
  \&\f(CW\*(C`dmultu\*(C'\fR does not always produce the correct result.
! .IP "\-" 4
  \&\f(CW\*(C`div\*(C'\fR and \f(CW\*(C`ddiv\*(C'\fR do not always produce the correct result if one
  of the operands is negative.
  .RE
--- 26639,26664 ----
  instructions or fewer and always schedule a \f(CW\*(C`nop\*(C'\fR instruction there
  instead.  The short loop bug under certain conditions causes loops to
  execute only once or twice, due to a hardware bug in the R5900 chip.  The
! workaround is implemented by the assembler rather than by GCC.
! .IP \fB\-mfix\-rm7000\fR 4
  .IX Item "-mfix-rm7000"
  .PD 0
! .IP \fB\-mno\-fix\-rm7000\fR 4
  .IX Item "-mno-fix-rm7000"
  .PD
! Work around the RM7000 \f(CW\*(C`dmult\*(C'\fR/\f(CW\*(C`dmultu\*(C'\fR errata.  The
! workarounds are implemented by the assembler rather than by GCC.
! .IP \fB\-mfix\-vr4120\fR 4
  .IX Item "-mfix-vr4120"
  .PD 0
! .IP \fB\-mno\-fix\-vr4120\fR 4
  .IX Item "-mno-fix-vr4120"
  .PD
! Work around certain VR4120 errata:
  .RS 4
! .IP \- 4
  \&\f(CW\*(C`dmultu\*(C'\fR does not always produce the correct result.
! .IP \- 4
  \&\f(CW\*(C`div\*(C'\fR and \f(CW\*(C`ddiv\*(C'\fR do not always produce the correct result if one
  of the operands is negative.
  .RE
*************** The workarounds for the division errata
*** 26737,26800 ****
  \&\fIlibgcc.a\fR.  At present, these functions are only provided by
  the \f(CW\*(C`mips64vr*\-elf\*(C'\fR configurations.
  .Sp
! Other \s-1VR4120\s0 errata require a \s-1NOP\s0 to be inserted between certain pairs of
! instructions.  These errata are handled by the assembler, not by \s-1GCC\s0 itself.
  .RE
! .IP "\fB\-mfix\-vr4130\fR" 4
  .IX Item "-mfix-vr4130"
! Work around the \s-1VR4130\s0 \f(CW\*(C`mflo\*(C'\fR/\f(CW\*(C`mfhi\*(C'\fR errata.  The
! workarounds are implemented by the assembler rather than by \s-1GCC,\s0
! although \s-1GCC\s0 avoids using \f(CW\*(C`mflo\*(C'\fR and \f(CW\*(C`mfhi\*(C'\fR if the
! \&\s-1VR4130\s0 \f(CW\*(C`macc\*(C'\fR, \f(CW\*(C`macchi\*(C'\fR, \f(CW\*(C`dmacc\*(C'\fR and \f(CW\*(C`dmacchi\*(C'\fR
  instructions are available instead.
! .IP "\fB\-mfix\-sb1\fR" 4
  .IX Item "-mfix-sb1"
  .PD 0
! .IP "\fB\-mno\-fix\-sb1\fR" 4
  .IX Item "-mno-fix-sb1"
  .PD
! Work around certain \s-1SB\-1 CPU\s0 core errata.
! (This flag currently works around the \s-1SB\-1\s0 revision 2
! \&\*(L"F1\*(R" and \*(L"F2\*(R" floating-point errata.)
! .IP "\fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR" 4
  .IX Item "-mr10k-cache-barrier=setting"
! Specify whether \s-1GCC\s0 should insert cache barriers to avoid the
  side effects of speculation on R10K processors.
  .Sp
  In common with many processors, the R10K tries to predict the outcome
  of a conditional branch and speculatively executes instructions from
! the \*(L"taken\*(R" branch.  It later aborts these instructions if the
  predicted outcome is wrong.  However, on the R10K, even aborted
  instructions can have side effects.
  .Sp
  This problem only affects kernel stores and, depending on the system,
! kernel loads.  As an example, a speculatively-executed store may load
  the target memory into cache and mark the cache line as dirty, even if
! the store itself is later aborted.  If a \s-1DMA\s0 operation writes to the
! same area of memory before the \*(L"dirty\*(R" line is flushed, the cached
! data overwrites the DMA-ed data.  See the R10K processor manual
  for a full description, including other potential problems.
  .Sp
  One workaround is to insert cache barrier instructions before every memory
  access that might be speculatively executed and that might have side
  effects even if aborted.  \fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR
! controls \s-1GCC\s0's implementation of this workaround.  It assumes that
  aborted accesses to any byte in the following regions does not have
  side effects:
  .RS 4
! .IP "1." 4
  .IX Item "1."
! the memory occupied by the current function's stack frame;
! .IP "2." 4
  .IX Item "2."
  the memory occupied by an incoming stack argument;
! .IP "3." 4
  .IX Item "3."
! the memory occupied by an object with a link-time-constant address.
  .RE
  .RS 4
  .Sp
! It is the kernel's responsibility to ensure that speculative
  accesses to these regions are indeed safe.
  .Sp
  If the input program contains a function declaration such as:
--- 26668,26731 ----
  \&\fIlibgcc.a\fR.  At present, these functions are only provided by
  the \f(CW\*(C`mips64vr*\-elf\*(C'\fR configurations.
  .Sp
! 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.
  .RE
! .IP \fB\-mfix\-vr4130\fR 4
  .IX Item "-mfix-vr4130"
! Work around the VR4130 \f(CW\*(C`mflo\*(C'\fR/\f(CW\*(C`mfhi\*(C'\fR errata.  The
! workarounds are implemented by the assembler rather than by GCC,
! although GCC avoids using \f(CW\*(C`mflo\*(C'\fR and \f(CW\*(C`mfhi\*(C'\fR if the
! VR4130 \f(CW\*(C`macc\*(C'\fR, \f(CW\*(C`macchi\*(C'\fR, \f(CW\*(C`dmacc\*(C'\fR and \f(CW\*(C`dmacchi\*(C'\fR
  instructions are available instead.
! .IP \fB\-mfix\-sb1\fR 4
  .IX Item "-mfix-sb1"
  .PD 0
! .IP \fB\-mno\-fix\-sb1\fR 4
  .IX Item "-mno-fix-sb1"
  .PD
! Work around certain SB\-1 CPU core errata.
! (This flag currently works around the SB\-1 revision 2
! "F1" and "F2" floating\-point errata.)
! .IP \fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR 4
  .IX Item "-mr10k-cache-barrier=setting"
! Specify whether GCC should insert cache barriers to avoid the
  side effects of speculation on R10K processors.
  .Sp
  In common with many processors, the R10K tries to predict the outcome
  of a conditional branch and speculatively executes instructions from
! the "taken" branch.  It later aborts these instructions if the
  predicted outcome is wrong.  However, on the R10K, even aborted
  instructions can have side effects.
  .Sp
  This problem only affects kernel stores and, depending on the system,
! kernel loads.  As an example, a speculatively\-executed store may load
  the target memory into cache and mark the cache line as dirty, even if
! the store itself is later aborted.  If a DMA operation writes to the
! same area of memory before the "dirty" line is flushed, the cached
! data overwrites the DMA\-ed data.  See the R10K processor manual
  for a full description, including other potential problems.
  .Sp
  One workaround is to insert cache barrier instructions before every memory
  access that might be speculatively executed and that might have side
  effects even if aborted.  \fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR
! controls GCC\*(Aqs implementation of this workaround.  It assumes that
  aborted accesses to any byte in the following regions does not have
  side effects:
  .RS 4
! .IP 1. 4
  .IX Item "1."
! the memory occupied by the current function\*(Aqs stack frame;
! .IP 2. 4
  .IX Item "2."
  the memory occupied by an incoming stack argument;
! .IP 3. 4
  .IX Item "3."
! the memory occupied by an object with a link\-time\-constant address.
  .RE
  .RS 4
  .Sp
! It is the kernel\*(Aqs responsibility to ensure that speculative
  accesses to these regions are indeed safe.
  .Sp
  If the input program contains a function declaration such as:
*************** If the input program contains a function
*** 26804,26833 ****
  .Ve
  .Sp
  then the implementation of \f(CW\*(C`foo\*(C'\fR must allow \f(CW\*(C`j foo\*(C'\fR and
! \&\f(CW\*(C`jal foo\*(C'\fR to be executed speculatively.  \s-1GCC\s0 honors this
! restriction for functions it compiles itself.  It expects non-GCC
! functions (such as hand-written assembly code) to do the same.
  .Sp
  The option has three forms:
! .IP "\fB\-mr10k\-cache\-barrier=load\-store\fR" 4
  .IX Item "-mr10k-cache-barrier=load-store"
  Insert a cache barrier before a load or store that might be
  speculatively executed and that might have side effects even
  if aborted.
! .IP "\fB\-mr10k\-cache\-barrier=store\fR" 4
  .IX Item "-mr10k-cache-barrier=store"
  Insert a cache barrier before a store that might be speculatively
  executed and that might have side effects even if aborted.
! .IP "\fB\-mr10k\-cache\-barrier=none\fR" 4
  .IX Item "-mr10k-cache-barrier=none"
  Disable the insertion of cache barriers.  This is the default setting.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mflush\-func=\fR\fIfunc\fR" 4
  .IX Item "-mflush-func=func"
  .PD 0
! .IP "\fB\-mno\-flush\-func\fR" 4
  .IX Item "-mno-flush-func"
  .PD
  Specifies the function to call to flush the I and D caches, or to not
--- 26735,26764 ----
  .Ve
  .Sp
  then the implementation of \f(CW\*(C`foo\*(C'\fR must allow \f(CW\*(C`j foo\*(C'\fR and
! \&\f(CW\*(C`jal foo\*(C'\fR to be executed speculatively.  GCC honors this
! restriction for functions it compiles itself.  It expects non\-GCC
! functions (such as hand\-written assembly code) to do the same.
  .Sp
  The option has three forms:
! .IP \fB\-mr10k\-cache\-barrier=load\-store\fR 4
  .IX Item "-mr10k-cache-barrier=load-store"
  Insert a cache barrier before a load or store that might be
  speculatively executed and that might have side effects even
  if aborted.
! .IP \fB\-mr10k\-cache\-barrier=store\fR 4
  .IX Item "-mr10k-cache-barrier=store"
  Insert a cache barrier before a store that might be speculatively
  executed and that might have side effects even if aborted.
! .IP \fB\-mr10k\-cache\-barrier=none\fR 4
  .IX Item "-mr10k-cache-barrier=none"
  Disable the insertion of cache barriers.  This is the default setting.
  .RE
  .RS 4
  .RE
! .IP \fB\-mflush\-func=\fR\fIfunc\fR 4
  .IX Item "-mflush-func=func"
  .PD 0
! .IP \fB\-mno\-flush\-func\fR 4
  .IX Item "-mno-flush-func"
  .PD
  Specifies the function to call to flush the I and D caches, or to not
*************** call any such function.  If called, the
*** 26835,26867 ****
  arguments as the common \f(CW\*(C`_flush_func\*(C'\fR, that is, the address of the
  memory range for which the cache is being flushed, the size of the
  memory range, and the number 3 (to flush both caches).  The default
! depends on the target \s-1GCC\s0 was configured for, but commonly is either
  \&\f(CW\*(C`_flush_func\*(C'\fR or \f(CW\*(C`_\|_cpu_flush\*(C'\fR.
! .IP "\fBmbranch\-cost=\fR\fInum\fR" 4
  .IX Item "mbranch-cost=num"
! Set the cost of branches to roughly \fInum\fR \*(L"simple\*(R" instructions.
  This cost is only a heuristic and is not guaranteed to produce
  consistent results across releases.  A zero cost redundantly selects
  the default, which is based on the \fB\-mtune\fR setting.
! .IP "\fB\-mbranch\-likely\fR" 4
  .IX Item "-mbranch-likely"
  .PD 0
! .IP "\fB\-mno\-branch\-likely\fR" 4
  .IX Item "-mno-branch-likely"
  .PD
  Enable or disable use of Branch Likely instructions, regardless of the
  default for the selected architecture.  By default, Branch Likely
  instructions may be generated if they are supported by the selected
! architecture.  An exception is for the \s-1MIPS32\s0 and \s-1MIPS64\s0 architectures
  and processors that implement those architectures; for those, Branch
! Likely instructions are not be generated by default because the \s-1MIPS32\s0
! and \s-1MIPS64\s0 architectures specifically deprecate their use.
! .IP "\fB\-mcompact\-branches=never\fR" 4
  .IX Item "-mcompact-branches=never"
  .PD 0
! .IP "\fB\-mcompact\-branches=optimal\fR" 4
  .IX Item "-mcompact-branches=optimal"
! .IP "\fB\-mcompact\-branches=always\fR" 4
  .IX Item "-mcompact-branches=always"
  .PD
  These options control which form of branches will be generated.  The
--- 26766,26798 ----
  arguments as the common \f(CW\*(C`_flush_func\*(C'\fR, that is, the address of the
  memory range for which the cache is being flushed, the size of the
  memory range, and the number 3 (to flush both caches).  The default
! depends on the target GCC was configured for, but commonly is either
  \&\f(CW\*(C`_flush_func\*(C'\fR or \f(CW\*(C`_\|_cpu_flush\*(C'\fR.
! .IP \fBmbranch\-cost=\fR\fInum\fR 4
  .IX Item "mbranch-cost=num"
! Set the cost of branches to roughly \fInum\fR "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 \fB\-mtune\fR setting.
! .IP \fB\-mbranch\-likely\fR 4
  .IX Item "-mbranch-likely"
  .PD 0
! .IP \fB\-mno\-branch\-likely\fR 4
  .IX Item "-mno-branch-likely"
  .PD
  Enable or disable use of Branch Likely instructions, regardless of the
  default for the selected architecture.  By default, Branch Likely
  instructions may be generated if they are supported by the selected
! architecture.  An exception is for the MIPS32 and MIPS64 architectures
  and processors that implement those architectures; for those, Branch
! Likely instructions are not be generated by default because the MIPS32
! and MIPS64 architectures specifically deprecate their use.
! .IP \fB\-mcompact\-branches=never\fR 4
  .IX Item "-mcompact-branches=never"
  .PD 0
! .IP \fB\-mcompact\-branches=optimal\fR 4
  .IX Item "-mcompact-branches=optimal"
! .IP \fB\-mcompact\-branches=always\fR 4
  .IX Item "-mcompact-branches=always"
  .PD
  These options control which form of branches will be generated.  The
*************** The \fB\-mcompact\-branches=never\fR opt
*** 26871,26877 ****
  instructions will never be generated.
  .Sp
  The \fB\-mcompact\-branches=always\fR option ensures that a compact
! branch instruction will be generated if available for \s-1MIPS\s0 Release 6 onwards.
  If a compact branch instruction is not available (or pre\-R6),
  a delay slot form of the branch will be used instead.
  .Sp
--- 26802,26808 ----
  instructions will never be generated.
  .Sp
  The \fB\-mcompact\-branches=always\fR option ensures that a compact
! branch instruction will be generated if available for MIPS Release 6 onwards.
  If a compact branch instruction is not available (or pre\-R6),
  a delay slot form of the branch will be used instead.
  .Sp
*************** The behaviour for MIPS16/microMIPS may c
*** 26880,26920 ****
  since they do have some compact branch instructions.
  .Sp
  The \fB\-mcompact\-branches=optimal\fR option will cause a delay slot
! branch to be used if one is available in the current \s-1ISA\s0 and the delay
  slot is successfully filled.  If the delay slot is not filled, a compact
  branch will be chosen if one is available.
! .IP "\fB\-mfp\-exceptions\fR" 4
  .IX Item "-mfp-exceptions"
  .PD 0
! .IP "\fB\-mno\-fp\-exceptions\fR" 4
  .IX Item "-mno-fp-exceptions"
  .PD
! Specifies whether \s-1FP\s0 exceptions are enabled.  This affects how
! \&\s-1FP\s0 instructions are scheduled for some processors.
! The default is that \s-1FP\s0 exceptions are
  enabled.
  .Sp
! For instance, on the \s-1SB\-1,\s0 if \s-1FP\s0 exceptions are disabled, and we are emitting
! 64\-bit code, then we can use both \s-1FP\s0 pipes.  Otherwise, we can only use one
! \&\s-1FP\s0 pipe.
! .IP "\fB\-mvr4130\-align\fR" 4
  .IX Item "-mvr4130-align"
  .PD 0
! .IP "\fB\-mno\-vr4130\-align\fR" 4
  .IX Item "-mno-vr4130-align"
  .PD
! The \s-1VR4130\s0 pipeline is two-way superscalar, but can only issue two
  instructions together if the first one is 8\-byte aligned.  When this
! option is enabled, \s-1GCC\s0 aligns pairs of instructions that it
  thinks should execute in parallel.
  .Sp
! This option only has an effect when optimizing for the \s-1VR4130.\s0
  It normally makes code faster, but at the expense of making it bigger.
  It is enabled by default at optimization level \fB\-O3\fR.
! .IP "\fB\-msynci\fR" 4
  .IX Item "-msynci"
  .PD 0
! .IP "\fB\-mno\-synci\fR" 4
  .IX Item "-mno-synci"
  .PD
  Enable (disable) generation of \f(CW\*(C`synci\*(C'\fR instructions on
--- 26811,26851 ----
  since they do have some compact branch instructions.
  .Sp
  The \fB\-mcompact\-branches=optimal\fR option will cause a delay slot
! branch to be used if one is available in the current ISA and the delay
  slot is successfully filled.  If the delay slot is not filled, a compact
  branch will be chosen if one is available.
! .IP \fB\-mfp\-exceptions\fR 4
  .IX Item "-mfp-exceptions"
  .PD 0
! .IP \fB\-mno\-fp\-exceptions\fR 4
  .IX Item "-mno-fp-exceptions"
  .PD
! Specifies whether FP exceptions are enabled.  This affects how
! FP instructions are scheduled for some processors.
! The default is that FP exceptions are
  enabled.
  .Sp
! 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.
! .IP \fB\-mvr4130\-align\fR 4
  .IX Item "-mvr4130-align"
  .PD 0
! .IP \fB\-mno\-vr4130\-align\fR 4
  .IX Item "-mno-vr4130-align"
  .PD
! The VR4130 pipeline is two\-way superscalar, but can only issue two
  instructions together if the first one is 8\-byte aligned.  When this
! option is enabled, GCC aligns pairs of instructions that it
  thinks should execute in parallel.
  .Sp
! 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 \fB\-O3\fR.
! .IP \fB\-msynci\fR 4
  .IX Item "-msynci"
  .PD 0
! .IP \fB\-mno\-synci\fR 4
  .IX Item "-mno-synci"
  .PD
  Enable (disable) generation of \f(CW\*(C`synci\*(C'\fR instructions on
*************** enabled) are generated when \f(CW\*(C`_\
*** 26923,27075 ****
  compiled.
  .Sp
  This option defaults to \fB\-mno\-synci\fR, but the default can be
! overridden by configuring \s-1GCC\s0 with \fB\-\-with\-synci\fR.
  .Sp
  When compiling code for single processor systems, it is generally safe
! to use \f(CW\*(C`synci\*(C'\fR.  However, on many multi-core (\s-1SMP\s0) systems, it
  does not invalidate the instruction caches on all cores and may lead
  to undefined behavior.
! .IP "\fB\-mrelax\-pic\-calls\fR" 4
  .IX Item "-mrelax-pic-calls"
  .PD 0
! .IP "\fB\-mno\-relax\-pic\-calls\fR" 4
  .IX Item "-mno-relax-pic-calls"
  .PD
! Try to turn \s-1PIC\s0 calls that are normally dispatched via register
  \&\f(CW$25\fR into direct calls.  This is only possible if the linker can
  resolve the destination at link time and if the destination is within
  range for a direct call.
  .Sp
! \&\fB\-mrelax\-pic\-calls\fR is the default if \s-1GCC\s0 was configured to use
  an assembler and a linker that support the \f(CW\*(C`.reloc\*(C'\fR assembly
  directive and \fB\-mexplicit\-relocs\fR is in effect.  With
  \&\fB\-mno\-explicit\-relocs\fR, this optimization can be performed by the
  assembler and the linker alone without help from the compiler.
! .IP "\fB\-mmcount\-ra\-address\fR" 4
  .IX Item "-mmcount-ra-address"
  .PD 0
! .IP "\fB\-mno\-mcount\-ra\-address\fR" 4
  .IX Item "-mno-mcount-ra-address"
  .PD
  Emit (do not emit) code that allows \f(CW\*(C`_mcount\*(C'\fR to modify the
! calling function's return address.  When enabled, this option extends
! the usual \f(CW\*(C`_mcount\*(C'\fR interface with a new \fIra-address\fR
  parameter, which has type \f(CW\*(C`intptr_t *\*(C'\fR and is passed in register
  \&\f(CW$12\fR.  \f(CW\*(C`_mcount\*(C'\fR can then modify the return address by
  doing both of the following:
  .RS 4
! .IP "*" 4
  Returning the new address in register \f(CW$31\fR.
! .IP "*" 4
! Storing the new address in \f(CW\*(C`*\f(CIra\-address\f(CW\*(C'\fR,
! if \fIra-address\fR is nonnull.
  .RE
  .RS 4
  .Sp
  The default is \fB\-mno\-mcount\-ra\-address\fR.
  .RE
! .IP "\fB\-mframe\-header\-opt\fR" 4
  .IX Item "-mframe-header-opt"
  .PD 0
! .IP "\fB\-mno\-frame\-header\-opt\fR" 4
  .IX Item "-mno-frame-header-opt"
  .PD
! Enable (disable) frame header optimization in the o32 \s-1ABI.\s0  When using the
! o32 \s-1ABI,\s0 calling functions will allocate 16 bytes on the stack for the called
  function to write out register arguments.  When enabled, this optimization
  will suppress the allocation of the frame header if it can be determined that
  it is unused.
  .Sp
  This optimization is off by default at all optimization levels.
! .IP "\fB\-mlxc1\-sxc1\fR" 4
  .IX Item "-mlxc1-sxc1"
  .PD 0
! .IP "\fB\-mno\-lxc1\-sxc1\fR" 4
  .IX Item "-mno-lxc1-sxc1"
  .PD
  When applicable, enable (disable) the generation of \f(CW\*(C`lwxc1\*(C'\fR,
  \&\f(CW\*(C`swxc1\*(C'\fR, \f(CW\*(C`ldxc1\*(C'\fR, \f(CW\*(C`sdxc1\*(C'\fR instructions.  Enabled by default.
! .IP "\fB\-mmadd4\fR" 4
  .IX Item "-mmadd4"
  .PD 0
! .IP "\fB\-mno\-madd4\fR" 4
  .IX Item "-mno-madd4"
  .PD
  When applicable, enable (disable) the generation of 4\-operand \f(CW\*(C`madd.s\*(C'\fR,
  \&\f(CW\*(C`madd.d\*(C'\fR and related instructions.  Enabled by default.
  .PP
! \fI\s-1MMIX\s0 Options\fR
  .IX Subsection "MMIX Options"
  .PP
! These options are defined for the \s-1MMIX:\s0
! .IP "\fB\-mlibfuncs\fR" 4
  .IX Item "-mlibfuncs"
  .PD 0
! .IP "\fB\-mno\-libfuncs\fR" 4
  .IX Item "-mno-libfuncs"
  .PD
  Specify that intrinsic library functions are being compiled, passing all
  values in registers, no matter the size.
! .IP "\fB\-mepsilon\fR" 4
  .IX Item "-mepsilon"
  .PD 0
! .IP "\fB\-mno\-epsilon\fR" 4
  .IX Item "-mno-epsilon"
  .PD
! Generate floating-point comparison instructions that compare with respect
  to the \f(CW\*(C`rE\*(C'\fR epsilon register.
! .IP "\fB\-mabi=mmixware\fR" 4
  .IX Item "-mabi=mmixware"
  .PD 0
! .IP "\fB\-mabi=gnu\fR" 4
  .IX Item "-mabi=gnu"
  .PD
  Generate code that passes function parameters and return values that (in
  the called function) are seen as registers \f(CW$0\fR and up, as opposed to
! the \s-1GNU ABI\s0 which uses global registers \f(CW$231\fR and up.
! .IP "\fB\-mzero\-extend\fR" 4
  .IX Item "-mzero-extend"
  .PD 0
! .IP "\fB\-mno\-zero\-extend\fR" 4
  .IX Item "-mno-zero-extend"
  .PD
  When reading data from memory in sizes shorter than 64 bits, use (do not
! use) zero-extending load instructions by default, rather than
! sign-extending ones.
! .IP "\fB\-mknuthdiv\fR" 4
  .IX Item "-mknuthdiv"
  .PD 0
! .IP "\fB\-mno\-knuthdiv\fR" 4
  .IX Item "-mno-knuthdiv"
  .PD
  Make the result of a division yielding a remainder have the same sign as
  the divisor.  With the default, \fB\-mno\-knuthdiv\fR, the sign of the
  remainder follows the sign of the dividend.  Both methods are
  arithmetically valid, the latter being almost exclusively used.
! .IP "\fB\-mtoplevel\-symbols\fR" 4
  .IX Item "-mtoplevel-symbols"
  .PD 0
! .IP "\fB\-mno\-toplevel\-symbols\fR" 4
  .IX Item "-mno-toplevel-symbols"
  .PD
  Prepend (do not prepend) a \fB:\fR to all global symbols, so the assembly
  code can be used with the \f(CW\*(C`PREFIX\*(C'\fR assembly directive.
! .IP "\fB\-melf\fR" 4
  .IX Item "-melf"
! Generate an executable in the \s-1ELF\s0 format, rather than the default
  \&\fBmmo\fR format used by the \fBmmix\fR simulator.
! .IP "\fB\-mbranch\-predict\fR" 4
  .IX Item "-mbranch-predict"
  .PD 0
! .IP "\fB\-mno\-branch\-predict\fR" 4
  .IX Item "-mno-branch-predict"
  .PD
! Use (do not use) the probable-branch instructions, when static branch
  prediction indicates a probable branch.
! .IP "\fB\-mbase\-addresses\fR" 4
  .IX Item "-mbase-addresses"
  .PD 0
! .IP "\fB\-mno\-base\-addresses\fR" 4
  .IX Item "-mno-base-addresses"
  .PD
  Generate (do not generate) code that uses \fIbase addresses\fR.  Using a
--- 26854,27006 ----
  compiled.
  .Sp
  This option defaults to \fB\-mno\-synci\fR, but the default can be
! overridden by configuring GCC with \fB\-\-with\-synci\fR.
  .Sp
  When compiling code for single processor systems, it is generally safe
! to use \f(CW\*(C`synci\*(C'\fR.  However, on many multi\-core (SMP) systems, it
  does not invalidate the instruction caches on all cores and may lead
  to undefined behavior.
! .IP \fB\-mrelax\-pic\-calls\fR 4
  .IX Item "-mrelax-pic-calls"
  .PD 0
! .IP \fB\-mno\-relax\-pic\-calls\fR 4
  .IX Item "-mno-relax-pic-calls"
  .PD
! Try to turn PIC calls that are normally dispatched via register
  \&\f(CW$25\fR into direct calls.  This is only possible if the linker can
  resolve the destination at link time and if the destination is within
  range for a direct call.
  .Sp
! \&\fB\-mrelax\-pic\-calls\fR is the default if GCC was configured to use
  an assembler and a linker that support the \f(CW\*(C`.reloc\*(C'\fR assembly
  directive and \fB\-mexplicit\-relocs\fR is in effect.  With
  \&\fB\-mno\-explicit\-relocs\fR, this optimization can be performed by the
  assembler and the linker alone without help from the compiler.
! .IP \fB\-mmcount\-ra\-address\fR 4
  .IX Item "-mmcount-ra-address"
  .PD 0
! .IP \fB\-mno\-mcount\-ra\-address\fR 4
  .IX Item "-mno-mcount-ra-address"
  .PD
  Emit (do not emit) code that allows \f(CW\*(C`_mcount\*(C'\fR to modify the
! calling function\*(Aqs return address.  When enabled, this option extends
! the usual \f(CW\*(C`_mcount\*(C'\fR interface with a new \fIra\-address\fR
  parameter, which has type \f(CW\*(C`intptr_t *\*(C'\fR and is passed in register
  \&\f(CW$12\fR.  \f(CW\*(C`_mcount\*(C'\fR can then modify the return address by
  doing both of the following:
  .RS 4
! .IP * 4
  Returning the new address in register \f(CW$31\fR.
! .IP * 4
! Storing the new address in \f(CW\*(C`*\fR\f(CIra\-address\fR\f(CW\*(C'\fR,
! if \fIra\-address\fR is nonnull.
  .RE
  .RS 4
  .Sp
  The default is \fB\-mno\-mcount\-ra\-address\fR.
  .RE
! .IP \fB\-mframe\-header\-opt\fR 4
  .IX Item "-mframe-header-opt"
  .PD 0
! .IP \fB\-mno\-frame\-header\-opt\fR 4
  .IX Item "-mno-frame-header-opt"
  .PD
! Enable (disable) frame header optimization in the o32 ABI.  When using the
! o32 ABI, calling functions will allocate 16 bytes on the stack for the called
  function to write out register arguments.  When enabled, this optimization
  will suppress the allocation of the frame header if it can be determined that
  it is unused.
  .Sp
  This optimization is off by default at all optimization levels.
! .IP \fB\-mlxc1\-sxc1\fR 4
  .IX Item "-mlxc1-sxc1"
  .PD 0
! .IP \fB\-mno\-lxc1\-sxc1\fR 4
  .IX Item "-mno-lxc1-sxc1"
  .PD
  When applicable, enable (disable) the generation of \f(CW\*(C`lwxc1\*(C'\fR,
  \&\f(CW\*(C`swxc1\*(C'\fR, \f(CW\*(C`ldxc1\*(C'\fR, \f(CW\*(C`sdxc1\*(C'\fR instructions.  Enabled by default.
! .IP \fB\-mmadd4\fR 4
  .IX Item "-mmadd4"
  .PD 0
! .IP \fB\-mno\-madd4\fR 4
  .IX Item "-mno-madd4"
  .PD
  When applicable, enable (disable) the generation of 4\-operand \f(CW\*(C`madd.s\*(C'\fR,
  \&\f(CW\*(C`madd.d\*(C'\fR and related instructions.  Enabled by default.
  .PP
! \fIMMIX Options\fR
  .IX Subsection "MMIX Options"
  .PP
! These options are defined for the MMIX:
! .IP \fB\-mlibfuncs\fR 4
  .IX Item "-mlibfuncs"
  .PD 0
! .IP \fB\-mno\-libfuncs\fR 4
  .IX Item "-mno-libfuncs"
  .PD
  Specify that intrinsic library functions are being compiled, passing all
  values in registers, no matter the size.
! .IP \fB\-mepsilon\fR 4
  .IX Item "-mepsilon"
  .PD 0
! .IP \fB\-mno\-epsilon\fR 4
  .IX Item "-mno-epsilon"
  .PD
! Generate floating\-point comparison instructions that compare with respect
  to the \f(CW\*(C`rE\*(C'\fR epsilon register.
! .IP \fB\-mabi=mmixware\fR 4
  .IX Item "-mabi=mmixware"
  .PD 0
! .IP \fB\-mabi=gnu\fR 4
  .IX Item "-mabi=gnu"
  .PD
  Generate code that passes function parameters and return values that (in
  the called function) are seen as registers \f(CW$0\fR and up, as opposed to
! the GNU ABI which uses global registers \f(CW$231\fR and up.
! .IP \fB\-mzero\-extend\fR 4
  .IX Item "-mzero-extend"
  .PD 0
! .IP \fB\-mno\-zero\-extend\fR 4
  .IX Item "-mno-zero-extend"
  .PD
  When reading data from memory in sizes shorter than 64 bits, use (do not
! use) zero\-extending load instructions by default, rather than
! sign\-extending ones.
! .IP \fB\-mknuthdiv\fR 4
  .IX Item "-mknuthdiv"
  .PD 0
! .IP \fB\-mno\-knuthdiv\fR 4
  .IX Item "-mno-knuthdiv"
  .PD
  Make the result of a division yielding a remainder have the same sign as
  the divisor.  With the default, \fB\-mno\-knuthdiv\fR, the sign of the
  remainder follows the sign of the dividend.  Both methods are
  arithmetically valid, the latter being almost exclusively used.
! .IP \fB\-mtoplevel\-symbols\fR 4
  .IX Item "-mtoplevel-symbols"
  .PD 0
! .IP \fB\-mno\-toplevel\-symbols\fR 4
  .IX Item "-mno-toplevel-symbols"
  .PD
  Prepend (do not prepend) a \fB:\fR to all global symbols, so the assembly
  code can be used with the \f(CW\*(C`PREFIX\*(C'\fR assembly directive.
! .IP \fB\-melf\fR 4
  .IX Item "-melf"
! Generate an executable in the ELF format, rather than the default
  \&\fBmmo\fR format used by the \fBmmix\fR simulator.
! .IP \fB\-mbranch\-predict\fR 4
  .IX Item "-mbranch-predict"
  .PD 0
! .IP \fB\-mno\-branch\-predict\fR 4
  .IX Item "-mno-branch-predict"
  .PD
! Use (do not use) the probable\-branch instructions, when static branch
  prediction indicates a probable branch.
! .IP \fB\-mbase\-addresses\fR 4
  .IX Item "-mbase-addresses"
  .PD 0
! .IP \fB\-mno\-base\-addresses\fR 4
  .IX Item "-mno-base-addresses"
  .PD
  Generate (do not generate) code that uses \fIbase addresses\fR.  Using a
*************** to 255 from the value held in the regist
*** 27080,27214 ****
  and fast code, but the number of different data items that can be
  addressed is limited.  This means that a program that uses lots of static
  data may require \fB\-mno\-base\-addresses\fR.
! .IP "\fB\-msingle\-exit\fR" 4
  .IX Item "-msingle-exit"
  .PD 0
! .IP "\fB\-mno\-single\-exit\fR" 4
  .IX Item "-mno-single-exit"
  .PD
  Force (do not force) generated code to have a single exit point in each
  function.
  .PP
! \fI\s-1MN10300\s0 Options\fR
  .IX Subsection "MN10300 Options"
  .PP
! These \fB\-m\fR options are defined for Matsushita \s-1MN10300\s0 architectures:
! .IP "\fB\-mmult\-bug\fR" 4
  .IX Item "-mmult-bug"
! Generate code to avoid bugs in the multiply instructions for the \s-1MN10300\s0
  processors.  This is the default.
! .IP "\fB\-mno\-mult\-bug\fR" 4
  .IX Item "-mno-mult-bug"
  Do not generate code to avoid bugs in the multiply instructions for the
! \&\s-1MN10300\s0 processors.
! .IP "\fB\-mam33\fR" 4
  .IX Item "-mam33"
! Generate code using features specific to the \s-1AM33\s0 processor.
! .IP "\fB\-mno\-am33\fR" 4
  .IX Item "-mno-am33"
! Do not generate code using features specific to the \s-1AM33\s0 processor.  This
  is the default.
! .IP "\fB\-mam33\-2\fR" 4
  .IX Item "-mam33-2"
! Generate code using features specific to the \s-1AM33/2.0\s0 processor.
! .IP "\fB\-mam34\fR" 4
  .IX Item "-mam34"
! Generate code using features specific to the \s-1AM34\s0 processor.
! .IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
  .IX Item "-mtune=cpu-type"
! Use the timing characteristics of the indicated \s-1CPU\s0 type when
  scheduling instructions.  This does not change the targeted processor
! type.  The \s-1CPU\s0 type must be one of \fBmn10300\fR, \fBam33\fR,
  \&\fBam33\-2\fR or \fBam34\fR.
! .IP "\fB\-mreturn\-pointer\-on\-d0\fR" 4
  .IX Item "-mreturn-pointer-on-d0"
  When generating a function that returns a pointer, return the pointer
  in both \f(CW\*(C`a0\*(C'\fR and \f(CW\*(C`d0\*(C'\fR.  Otherwise, the pointer is returned
  only in \f(CW\*(C`a0\*(C'\fR, and attempts to call such functions without a prototype
  result in errors.  Note that this option is on by default; use
  \&\fB\-mno\-return\-pointer\-on\-d0\fR to disable it.
! .IP "\fB\-mno\-crt0\fR" 4
  .IX Item "-mno-crt0"
! Do not link in the C run-time initialization object file.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Indicate to the linker that it should perform a relaxation optimization pass
  to shorten branches, calls and absolute memory addresses.  This option only
  has an effect when used on the command line for the final link step.
  .Sp
  This option makes symbolic debugging impossible.
! .IP "\fB\-mliw\fR" 4
  .IX Item "-mliw"
  Allow the compiler to generate \fILong Instruction Word\fR
! instructions if the target is the \fB\s-1AM33\s0\fR or later.  This is the
  default.  This option defines the preprocessor macro \f(CW\*(C`_\|_LIW_\|_\*(C'\fR.
! .IP "\fB\-mno\-liw\fR" 4
  .IX Item "-mno-liw"
  Do not allow the compiler to generate \fILong Instruction Word\fR
  instructions.  This option defines the preprocessor macro
  \&\f(CW\*(C`_\|_NO_LIW_\|_\*(C'\fR.
! .IP "\fB\-msetlb\fR" 4
  .IX Item "-msetlb"
! Allow the compiler to generate the \fI\s-1SETLB\s0\fR and \fILcc\fR
! instructions if the target is the \fB\s-1AM33\s0\fR or later.  This is the
  default.  This option defines the preprocessor macro \f(CW\*(C`_\|_SETLB_\|_\*(C'\fR.
! .IP "\fB\-mno\-setlb\fR" 4
  .IX Item "-mno-setlb"
! Do not allow the compiler to generate \fI\s-1SETLB\s0\fR or \fILcc\fR
  instructions.  This option defines the preprocessor macro
  \&\f(CW\*(C`_\|_NO_SETLB_\|_\*(C'\fR.
  .PP
  \fIMoxie Options\fR
  .IX Subsection "Moxie Options"
! .IP "\fB\-meb\fR" 4
  .IX Item "-meb"
! Generate big-endian code.  This is the default for \fBmoxie\-*\-*\fR
  configurations.
! .IP "\fB\-mel\fR" 4
  .IX Item "-mel"
! Generate little-endian code.
! .IP "\fB\-mmul.x\fR" 4
  .IX Item "-mmul.x"
  Generate mul.x and umul.x instructions.  This is the default for
  \&\fBmoxiebox\-*\-*\fR configurations.
! .IP "\fB\-mno\-crt0\fR" 4
  .IX Item "-mno-crt0"
! Do not link in the C run-time initialization object file.
  .PP
! \fI\s-1MSP430\s0 Options\fR
  .IX Subsection "MSP430 Options"
  .PP
! These options are defined for the \s-1MSP430:\s0
! .IP "\fB\-masm\-hex\fR" 4
  .IX Item "-masm-hex"
  Force assembly output to always use hex constants.  Normally such
  constants are signed decimals, but this option is available for
  testsuite and/or aesthetic purposes.
! .IP "\fB\-mmcu=\fR" 4
  .IX Item "-mmcu="
! Select the \s-1MCU\s0 to target.  This is used to create a C preprocessor
! symbol based upon the \s-1MCU\s0 name, converted to upper case and pre\- and
! post-fixed with \fB_\|_\fR.  This in turn is used by the
! \&\fImsp430.h\fR header file to select an MCU-specific supplementary
  header file.
  .Sp
! The option also sets the \s-1ISA\s0 to use.  If the \s-1MCU\s0 name is one that is
! known to only support the 430 \s-1ISA\s0 then that is selected, otherwise the
! 430X \s-1ISA\s0 is selected.  A generic \s-1MCU\s0 name of \fBmsp430\fR can also be
! used to select the 430 \s-1ISA.\s0  Similarly the generic \fBmsp430x\fR \s-1MCU\s0
! name selects the 430X \s-1ISA.\s0
  .Sp
! In addition an MCU-specific linker script is added to the linker
! command line.  The script's name is the name of the \s-1MCU\s0 with
  \&\fI.ld\fR appended.  Thus specifying \fB\-mmcu=xxx\fR on the \fBgcc\fR
  command line defines the C preprocessor symbol \f(CW\*(C`_\|_XXX_\|_\*(C'\fR and
  cause the linker to search for a script called \fIxxx.ld\fR.
  .Sp
! The \s-1ISA\s0 and hardware multiply supported for the different MCUs is hard-coded
! into \s-1GCC.\s0  However, an external \fBdevices.csv\fR file can be used to
! extend device support beyond those that have been hard-coded.
  .Sp
! \&\s-1GCC\s0 searches for the \fBdevices.csv\fR file using the following methods in the
  given precedence order, where the first method takes precendence over the
  second which takes precedence over the third.
  .RS 4
--- 27011,27145 ----
  and fast code, but the number of different data items that can be
  addressed is limited.  This means that a program that uses lots of static
  data may require \fB\-mno\-base\-addresses\fR.
! .IP \fB\-msingle\-exit\fR 4
  .IX Item "-msingle-exit"
  .PD 0
! .IP \fB\-mno\-single\-exit\fR 4
  .IX Item "-mno-single-exit"
  .PD
  Force (do not force) generated code to have a single exit point in each
  function.
  .PP
! \fIMN10300 Options\fR
  .IX Subsection "MN10300 Options"
  .PP
! These \fB\-m\fR options are defined for Matsushita MN10300 architectures:
! .IP \fB\-mmult\-bug\fR 4
  .IX Item "-mmult-bug"
! Generate code to avoid bugs in the multiply instructions for the MN10300
  processors.  This is the default.
! .IP \fB\-mno\-mult\-bug\fR 4
  .IX Item "-mno-mult-bug"
  Do not generate code to avoid bugs in the multiply instructions for the
! MN10300 processors.
! .IP \fB\-mam33\fR 4
  .IX Item "-mam33"
! Generate code using features specific to the AM33 processor.
! .IP \fB\-mno\-am33\fR 4
  .IX Item "-mno-am33"
! Do not generate code using features specific to the AM33 processor.  This
  is the default.
! .IP \fB\-mam33\-2\fR 4
  .IX Item "-mam33-2"
! Generate code using features specific to the AM33/2.0 processor.
! .IP \fB\-mam34\fR 4
  .IX Item "-mam34"
! Generate code using features specific to the AM34 processor.
! .IP \fB\-mtune=\fR\fIcpu\-type\fR 4
  .IX Item "-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 \fBmn10300\fR, \fBam33\fR,
  \&\fBam33\-2\fR or \fBam34\fR.
! .IP \fB\-mreturn\-pointer\-on\-d0\fR 4
  .IX Item "-mreturn-pointer-on-d0"
  When generating a function that returns a pointer, return the pointer
  in both \f(CW\*(C`a0\*(C'\fR and \f(CW\*(C`d0\*(C'\fR.  Otherwise, the pointer is returned
  only in \f(CW\*(C`a0\*(C'\fR, and attempts to call such functions without a prototype
  result in errors.  Note that this option is on by default; use
  \&\fB\-mno\-return\-pointer\-on\-d0\fR to disable it.
! .IP \fB\-mno\-crt0\fR 4
  .IX Item "-mno-crt0"
! Do not link in the C run\-time initialization object file.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Indicate to the linker that it should perform a relaxation optimization pass
  to shorten branches, calls and absolute memory addresses.  This option only
  has an effect when used on the command line for the final link step.
  .Sp
  This option makes symbolic debugging impossible.
! .IP \fB\-mliw\fR 4
  .IX Item "-mliw"
  Allow the compiler to generate \fILong Instruction Word\fR
! instructions if the target is the \fBAM33\fR or later.  This is the
  default.  This option defines the preprocessor macro \f(CW\*(C`_\|_LIW_\|_\*(C'\fR.
! .IP \fB\-mno\-liw\fR 4
  .IX Item "-mno-liw"
  Do not allow the compiler to generate \fILong Instruction Word\fR
  instructions.  This option defines the preprocessor macro
  \&\f(CW\*(C`_\|_NO_LIW_\|_\*(C'\fR.
! .IP \fB\-msetlb\fR 4
  .IX Item "-msetlb"
! Allow the compiler to generate the \fISETLB\fR and \fILcc\fR
! instructions if the target is the \fBAM33\fR or later.  This is the
  default.  This option defines the preprocessor macro \f(CW\*(C`_\|_SETLB_\|_\*(C'\fR.
! .IP \fB\-mno\-setlb\fR 4
  .IX Item "-mno-setlb"
! Do not allow the compiler to generate \fISETLB\fR or \fILcc\fR
  instructions.  This option defines the preprocessor macro
  \&\f(CW\*(C`_\|_NO_SETLB_\|_\*(C'\fR.
  .PP
  \fIMoxie Options\fR
  .IX Subsection "Moxie Options"
! .IP \fB\-meb\fR 4
  .IX Item "-meb"
! Generate big\-endian code.  This is the default for \fBmoxie\-*\-*\fR
  configurations.
! .IP \fB\-mel\fR 4
  .IX Item "-mel"
! Generate little\-endian code.
! .IP \fB\-mmul.x\fR 4
  .IX Item "-mmul.x"
  Generate mul.x and umul.x instructions.  This is the default for
  \&\fBmoxiebox\-*\-*\fR configurations.
! .IP \fB\-mno\-crt0\fR 4
  .IX Item "-mno-crt0"
! Do not link in the C run\-time initialization object file.
  .PP
! \fIMSP430 Options\fR
  .IX Subsection "MSP430 Options"
  .PP
! These options are defined for the MSP430:
! .IP \fB\-masm\-hex\fR 4
  .IX Item "-masm-hex"
  Force assembly output to always use hex constants.  Normally such
  constants are signed decimals, but this option is available for
  testsuite and/or aesthetic purposes.
! .IP \fB\-mmcu=\fR 4
  .IX Item "-mmcu="
! Select the MCU to target.  This is used to create a C preprocessor
! symbol based upon the MCU name, converted to upper case and pre\- and
! post\-fixed with \fB_\|_\fR.  This in turn is used by the
! \&\fImsp430.h\fR header file to select an MCU\-specific supplementary
  header file.
  .Sp
! The option also sets the ISA to use.  If the MCU name is one that is
! known to only support the 430 ISA then that is selected, otherwise the
! 430X ISA is selected.  A generic MCU name of \fBmsp430\fR can also be
! used to select the 430 ISA.  Similarly the generic \fBmsp430x\fR MCU
! name selects the 430X ISA.
  .Sp
! In addition an MCU\-specific linker script is added to the linker
! command line.  The script\*(Aqs name is the name of the MCU with
  \&\fI.ld\fR appended.  Thus specifying \fB\-mmcu=xxx\fR on the \fBgcc\fR
  command line defines the C preprocessor symbol \f(CW\*(C`_\|_XXX_\|_\*(C'\fR and
  cause the linker to search for a script called \fIxxx.ld\fR.
  .Sp
! The ISA and hardware multiply supported for the different MCUs is hard\-coded
! into GCC.  However, an external \fBdevices.csv\fR file can be used to
! extend device support beyond those that have been hard\-coded.
  .Sp
! GCC searches for the \fBdevices.csv\fR file using the following methods in the
  given precedence order, where the first method takes precendence over the
  second which takes precedence over the third.
  .RS 4
*************** second which takes precedence over the t
*** 27217,27286 ****
  .IX Item "Include path specified with -I and -L"
  \&\fBdevices.csv\fR will be searched for in each of the directories specified by
  include paths and linker library search paths.
! .IP "Path specified by the environment variable \fB\s-1MSP430_GCC_INCLUDE_DIR\s0\fR" 4
  .IX Item "Path specified by the environment variable MSP430_GCC_INCLUDE_DIR"
  Define the value of the global environment variable
! \&\fB\s-1MSP430_GCC_INCLUDE_DIR\s0\fR
! to the full path to the directory containing devices.csv, and \s-1GCC\s0 will search
  this directory for devices.csv.  If devices.csv is found, this directory will
  also be registered as an include path, and linker library path.  Header files
  and linker scripts in this directory can therefore be used without manually
  specifying \f(CW\*(C`\-I\*(C'\fR and \f(CW\*(C`\-L\*(C'\fR on the command line.
  .IP "The \fBmsp430\-elf{,bare}/include/devices\fR directory" 4
  .IX Item "The msp430-elf{,bare}/include/devices directory"
! Finally, \s-1GCC\s0 will examine \fBmsp430\-elf{,bare}/include/devices\fR from the
  toolchain root directory.  This directory does not exist in a default
  installation, but if the user has created it and copied \fBdevices.csv\fR
! there, then the \s-1MCU\s0 data will be read.  As above, this directory will
  also be registered as an include path, and linker library path.
  .RE
  .RS 4
  .Sp
  If none of the above search methods find \fBdevices.csv\fR, then the
! hard-coded \s-1MCU\s0 data is used.
  .RE
! .IP "\fB\-mwarn\-mcu\fR" 4
  .IX Item "-mwarn-mcu"
  .PD 0
! .IP "\fB\-mno\-warn\-mcu\fR" 4
  .IX Item "-mno-warn-mcu"
  .PD
  This option enables or disables warnings about conflicts between the
! \&\s-1MCU\s0 name specified by the \fB\-mmcu\fR option and the \s-1ISA\s0 set by the
  \&\fB\-mcpu\fR option and/or the hardware multiply support set by the
  \&\fB\-mhwmult\fR option.  It also toggles warnings about unrecognized
! \&\s-1MCU\s0 names.  This option is on by default.
! .IP "\fB\-mcpu=\fR" 4
  .IX Item "-mcpu="
! Specifies the \s-1ISA\s0 to use.  Accepted values are \fBmsp430\fR,
  \&\fBmsp430x\fR and \fBmsp430xv2\fR.  This option is deprecated.  The
! \&\fB\-mmcu=\fR option should be used to select the \s-1ISA.\s0
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Link to the simulator runtime libraries and linker script.  Overrides
  any scripts that would be selected by the \fB\-mmcu=\fR option.
! .IP "\fB\-mlarge\fR" 4
  .IX Item "-mlarge"
! Use large-model addressing (20\-bit pointers, 20\-bit \f(CW\*(C`size_t\*(C'\fR).
! .IP "\fB\-msmall\fR" 4
  .IX Item "-msmall"
! Use small-model addressing (16\-bit pointers, 16\-bit \f(CW\*(C`size_t\*(C'\fR).
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  This option is passed to the assembler and linker, and allows the
  linker to perform certain optimizations that cannot be done until
  the final link.
! .IP "\fBmhwmult=\fR" 4
  .IX Item "mhwmult="
  Describes the type of hardware multiply supported by the target.
  Accepted values are \fBnone\fR for no hardware multiply, \fB16bit\fR
  for the original 16\-bit\-only multiply supported by early MCUs.
  \&\fB32bit\fR for the 16/32\-bit multiply supported by later MCUs and
  \&\fBf5series\fR for the 16/32\-bit multiply supported by F5\-series MCUs.
! A value of \fBauto\fR can also be given.  This tells \s-1GCC\s0 to deduce
! the hardware multiply support based upon the \s-1MCU\s0 name provided by the
  \&\fB\-mmcu\fR option.  If no \fB\-mmcu\fR option is specified or if
! the \s-1MCU\s0 name is not recognized then no hardware multiply support is
  assumed.  \f(CW\*(C`auto\*(C'\fR is the default setting.
  .Sp
  Hardware multiplies are normally performed by calling a library
--- 27148,27217 ----
  .IX Item "Include path specified with -I and -L"
  \&\fBdevices.csv\fR will be searched for in each of the directories specified by
  include paths and linker library search paths.
! .IP "Path specified by the environment variable \fBMSP430_GCC_INCLUDE_DIR\fR" 4
  .IX Item "Path specified by the environment variable MSP430_GCC_INCLUDE_DIR"
  Define the value of the global environment variable
! \&\fBMSP430_GCC_INCLUDE_DIR\fR
! to the full path to the directory containing devices.csv, and GCC will search
  this directory for devices.csv.  If devices.csv is found, this directory will
  also be registered as an include path, and linker library path.  Header files
  and linker scripts in this directory can therefore be used without manually
  specifying \f(CW\*(C`\-I\*(C'\fR and \f(CW\*(C`\-L\*(C'\fR on the command line.
  .IP "The \fBmsp430\-elf{,bare}/include/devices\fR directory" 4
  .IX Item "The msp430-elf{,bare}/include/devices directory"
! Finally, GCC will examine \fBmsp430\-elf{,bare}/include/devices\fR from the
  toolchain root directory.  This directory does not exist in a default
  installation, but if the user has created it and copied \fBdevices.csv\fR
! there, then the MCU data will be read.  As above, this directory will
  also be registered as an include path, and linker library path.
  .RE
  .RS 4
  .Sp
  If none of the above search methods find \fBdevices.csv\fR, then the
! hard\-coded MCU data is used.
  .RE
! .IP \fB\-mwarn\-mcu\fR 4
  .IX Item "-mwarn-mcu"
  .PD 0
! .IP \fB\-mno\-warn\-mcu\fR 4
  .IX Item "-mno-warn-mcu"
  .PD
  This option enables or disables warnings about conflicts between the
! MCU name specified by the \fB\-mmcu\fR option and the ISA set by the
  \&\fB\-mcpu\fR option and/or the hardware multiply support set by the
  \&\fB\-mhwmult\fR option.  It also toggles warnings about unrecognized
! MCU names.  This option is on by default.
! .IP \fB\-mcpu=\fR 4
  .IX Item "-mcpu="
! Specifies the ISA to use.  Accepted values are \fBmsp430\fR,
  \&\fBmsp430x\fR and \fBmsp430xv2\fR.  This option is deprecated.  The
! \&\fB\-mmcu=\fR option should be used to select the ISA.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Link to the simulator runtime libraries and linker script.  Overrides
  any scripts that would be selected by the \fB\-mmcu=\fR option.
! .IP \fB\-mlarge\fR 4
  .IX Item "-mlarge"
! Use large\-model addressing (20\-bit pointers, 20\-bit \f(CW\*(C`size_t\*(C'\fR).
! .IP \fB\-msmall\fR 4
  .IX Item "-msmall"
! Use small\-model addressing (16\-bit pointers, 16\-bit \f(CW\*(C`size_t\*(C'\fR).
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  This option is passed to the assembler and linker, and allows the
  linker to perform certain optimizations that cannot be done until
  the final link.
! .IP \fBmhwmult=\fR 4
  .IX Item "mhwmult="
  Describes the type of hardware multiply supported by the target.
  Accepted values are \fBnone\fR for no hardware multiply, \fB16bit\fR
  for the original 16\-bit\-only multiply supported by early MCUs.
  \&\fB32bit\fR for the 16/32\-bit multiply supported by later MCUs and
  \&\fBf5series\fR for the 16/32\-bit multiply supported by F5\-series MCUs.
! A value of \fBauto\fR can also be given.  This tells GCC to deduce
! the hardware multiply support based upon the MCU name provided by the
  \&\fB\-mmcu\fR option.  If no \fB\-mmcu\fR option is specified or if
! the MCU name is not recognized then no hardware multiply support is
  assumed.  \f(CW\*(C`auto\*(C'\fR is the default setting.
  .Sp
  Hardware multiplies are normally performed by calling a library
*************** inline.  This makes for bigger, but fast
*** 27291,27315 ****
  The hardware multiply routines disable interrupts whilst running and
  restore the previous interrupt state when they finish.  This makes
  them safe to use inside interrupt handlers as well as in normal code.
! .IP "\fB\-minrt\fR" 4
  .IX Item "-minrt"
  Enable the use of a minimum runtime environment \- no static
! initializers or constructors.  This is intended for memory-constrained
  devices.  The compiler includes special symbols in some objects
  that tell the linker and runtime which code fragments are required.
! .IP "\fB\-mtiny\-printf\fR" 4
  .IX Item "-mtiny-printf"
  Enable reduced code size \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`puts\*(C'\fR library functions.
  The \fBtiny\fR implementations of these functions are not reentrant, so
! must be used with caution in multi-threaded applications.
  .Sp
  Support for streams has been removed and the string to be printed will
  always be sent to stdout via the \f(CW\*(C`write\*(C'\fR syscall.  The string is not
  buffered before it is sent to write.
  .Sp
! This option requires Newlib Nano \s-1IO,\s0 so \s-1GCC\s0 must be configured with
  \&\fB\-\-enable\-newlib\-nano\-formatted\-io\fR.
! .IP "\fB\-mmax\-inline\-shift=\fR" 4
  .IX Item "-mmax-inline-shift="
  This option takes an integer between 0 and 64 inclusive, and sets
  the maximum number of inline shift instructions which should be emitted to
--- 27222,27246 ----
  The hardware multiply routines disable interrupts whilst running and
  restore the previous interrupt state when they finish.  This makes
  them safe to use inside interrupt handlers as well as in normal code.
! .IP \fB\-minrt\fR 4
  .IX Item "-minrt"
  Enable the use of a minimum runtime environment \- no static
! initializers or constructors.  This is intended for memory\-constrained
  devices.  The compiler includes special symbols in some objects
  that tell the linker and runtime which code fragments are required.
! .IP \fB\-mtiny\-printf\fR 4
  .IX Item "-mtiny-printf"
  Enable reduced code size \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`puts\*(C'\fR library functions.
  The \fBtiny\fR implementations of these functions are not reentrant, so
! must be used with caution in multi\-threaded applications.
  .Sp
  Support for streams has been removed and the string to be printed will
  always be sent to stdout via the \f(CW\*(C`write\*(C'\fR syscall.  The string is not
  buffered before it is sent to write.
  .Sp
! This option requires Newlib Nano IO, so GCC must be configured with
  \&\fB\-\-enable\-newlib\-nano\-formatted\-io\fR.
! .IP \fB\-mmax\-inline\-shift=\fR 4
  .IX Item "-mmax-inline-shift="
  This option takes an integer between 0 and 64 inclusive, and sets
  the maximum number of inline shift instructions which should be emitted to
*************** perform a shift operation by a constant
*** 27317,27330 ****
  exceeded, an mspabi helper function is used instead.  The default value is 4.
  .Sp
  This only affects cases where a shift by multiple positions cannot be
! completed with a single instruction (e.g. all shifts >1 on the 430 \s-1ISA\s0).
  .Sp
  Shifts of a 32\-bit value are at least twice as costly, so the value passed for
  this option is divided by 2 and the resulting value used instead.
! .IP "\fB\-mcode\-region=\fR" 4
  .IX Item "-mcode-region="
  .PD 0
! .IP "\fB\-mdata\-region=\fR" 4
  .IX Item "-mdata-region="
  .PD
  These options tell the compiler where to place functions and data that
--- 27248,27261 ----
  exceeded, an mspabi helper function is used instead.  The default value is 4.
  .Sp
  This only affects cases where a shift by multiple positions cannot be
! completed with a single instruction (e.g. all shifts >1 on the 430 ISA).
  .Sp
  Shifts of a 32\-bit value are at least twice as costly, so the value passed for
  this option is divided by 2 and the resulting value used instead.
! .IP \fB\-mcode\-region=\fR 4
  .IX Item "-mcode-region="
  .PD 0
! .IP \fB\-mdata\-region=\fR 4
  .IX Item "-mdata-region="
  .PD
  These options tell the compiler where to place functions and data that
*************** like the corresponding attribute.  The f
*** 27335,27492 ****
  \&\f(CW\*(C`any\*(C'\fR \- is the default.  It leaves placement entirely up to the
  linker script and how it assigns the standard sections
  (\f(CW\*(C`.text\*(C'\fR, \f(CW\*(C`.data\*(C'\fR, etc) to the memory regions.
! .IP "\fB\-msilicon\-errata=\fR" 4
  .IX Item "-msilicon-errata="
  This option passes on a request to assembler to enable the fixes for
  the named silicon errata.
! .IP "\fB\-msilicon\-errata\-warn=\fR" 4
  .IX Item "-msilicon-errata-warn="
  This option passes on a request to the assembler to enable warning
  messages when a silicon errata might need to be applied.
! .IP "\fB\-mwarn\-devices\-csv\fR" 4
  .IX Item "-mwarn-devices-csv"
  .PD 0
! .IP "\fB\-mno\-warn\-devices\-csv\fR" 4
  .IX Item "-mno-warn-devices-csv"
  .PD
  Warn if \fBdevices.csv\fR is not found or there are problem parsing it
  (default: on).
  .PP
! \fI\s-1NDS32\s0 Options\fR
  .IX Subsection "NDS32 Options"
  .PP
! These options are defined for \s-1NDS32\s0 implementations:
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code in big-endian mode.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code in little-endian mode.
! .IP "\fB\-mreduced\-regs\fR" 4
  .IX Item "-mreduced-regs"
! Use reduced-set registers for register allocation.
! .IP "\fB\-mfull\-regs\fR" 4
  .IX Item "-mfull-regs"
! Use full-set registers for register allocation.
! .IP "\fB\-mcmov\fR" 4
  .IX Item "-mcmov"
  Generate conditional move instructions.
! .IP "\fB\-mno\-cmov\fR" 4
  .IX Item "-mno-cmov"
  Do not generate conditional move instructions.
! .IP "\fB\-mext\-perf\fR" 4
  .IX Item "-mext-perf"
  Generate performance extension instructions.
! .IP "\fB\-mno\-ext\-perf\fR" 4
  .IX Item "-mno-ext-perf"
  Do not generate performance extension instructions.
! .IP "\fB\-mext\-perf2\fR" 4
  .IX Item "-mext-perf2"
  Generate performance extension 2 instructions.
! .IP "\fB\-mno\-ext\-perf2\fR" 4
  .IX Item "-mno-ext-perf2"
  Do not generate performance extension 2 instructions.
! .IP "\fB\-mext\-string\fR" 4
  .IX Item "-mext-string"
  Generate string extension instructions.
! .IP "\fB\-mno\-ext\-string\fR" 4
  .IX Item "-mno-ext-string"
  Do not generate string extension instructions.
! .IP "\fB\-mv3push\fR" 4
  .IX Item "-mv3push"
  Generate v3 push25/pop25 instructions.
! .IP "\fB\-mno\-v3push\fR" 4
  .IX Item "-mno-v3push"
  Do not generate v3 push25/pop25 instructions.
! .IP "\fB\-m16\-bit\fR" 4
  .IX Item "-m16-bit"
  Generate 16\-bit instructions.
! .IP "\fB\-mno\-16\-bit\fR" 4
  .IX Item "-mno-16-bit"
  Do not generate 16\-bit instructions.
! .IP "\fB\-misr\-vector\-size=\fR\fInum\fR" 4
  .IX Item "-misr-vector-size=num"
  Specify the size of each interrupt vector, which must be 4 or 16.
! .IP "\fB\-mcache\-block\-size=\fR\fInum\fR" 4
  .IX Item "-mcache-block-size=num"
  Specify the size of each cache block,
  which must be a power of 2 between 4 and 512.
! .IP "\fB\-march=\fR\fIarch\fR" 4
  .IX Item "-march=arch"
  Specify the name of the target architecture.
! .IP "\fB\-mcmodel=\fR\fIcode-model\fR" 4
  .IX Item "-mcmodel=code-model"
  Set the code model to one of
  .RS 4
! .IP "\fBsmall\fR" 4
  .IX Item "small"
! All the data and read-only data segments must be within 512KB addressing space.
  The text segment must be within 16MB addressing space.
! .IP "\fBmedium\fR" 4
  .IX Item "medium"
! The data segment must be within 512KB while the read-only data segment can be
  within 4GB addressing space.  The text segment should be still within 16MB
  addressing space.
! .IP "\fBlarge\fR" 4
  .IX Item "large"
  All the text and data segments can be within 4GB addressing space.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mctor\-dtor\fR" 4
  .IX Item "-mctor-dtor"
  Enable constructor/destructor feature.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Guide linker to relax instructions.
  .PP
! \fINios \s-1II\s0 Options\fR
  .IX Subsection "Nios II Options"
  .PP
! These are the options defined for the Altera Nios \s-1II\s0 processor.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  Put global and static objects less than or equal to \fInum\fR bytes
! into the small data or \s-1BSS\s0 sections instead of the normal data or \s-1BSS\s0
  sections.  The default value of \fInum\fR is 8.
! .IP "\fB\-mgpopt=\fR\fIoption\fR" 4
  .IX Item "-mgpopt=option"
  .PD 0
! .IP "\fB\-mgpopt\fR" 4
  .IX Item "-mgpopt"
! .IP "\fB\-mno\-gpopt\fR" 4
  .IX Item "-mno-gpopt"
  .PD
! Generate (do not generate) GP-relative accesses.  The following 
  \&\fIoption\fR names are recognized:
  .RS 4
! .IP "\fBnone\fR" 4
  .IX Item "none"
! Do not generate GP-relative accesses.
! .IP "\fBlocal\fR" 4
  .IX Item "local"
! Generate GP-relative accesses for small data objects that are not 
  external, weak, or uninitialized common symbols.  
! Also use GP-relative addressing for objects that
  have been explicitly placed in a small data section via a \f(CW\*(C`section\*(C'\fR
  attribute.
! .IP "\fBglobal\fR" 4
  .IX Item "global"
! As for \fBlocal\fR, but also generate GP-relative accesses for
  small data objects that are external, weak, or common.  If you use this option,
  you must ensure that all parts of your program (including libraries) are
  compiled with the same \fB\-G\fR setting.
! .IP "\fBdata\fR" 4
  .IX Item "data"
! Generate GP-relative accesses for all data objects in the program.  If you
! use this option, the entire data and \s-1BSS\s0 segments
  of your program must fit in 64K of memory and you must use an appropriate
  linker script to allocate them within the addressable range of the
  global pointer.
! .IP "\fBall\fR" 4
  .IX Item "all"
! Generate GP-relative addresses for function pointers as well as data
! pointers.  If you use this option, the entire text, data, and \s-1BSS\s0 segments
  of your program must fit in 64K of memory and you must use an appropriate
  linker script to allocate them within the addressable range of the
  global pointer.
--- 27266,27423 ----
  \&\f(CW\*(C`any\*(C'\fR \- is the default.  It leaves placement entirely up to the
  linker script and how it assigns the standard sections
  (\f(CW\*(C`.text\*(C'\fR, \f(CW\*(C`.data\*(C'\fR, etc) to the memory regions.
! .IP \fB\-msilicon\-errata=\fR 4
  .IX Item "-msilicon-errata="
  This option passes on a request to assembler to enable the fixes for
  the named silicon errata.
! .IP \fB\-msilicon\-errata\-warn=\fR 4
  .IX Item "-msilicon-errata-warn="
  This option passes on a request to the assembler to enable warning
  messages when a silicon errata might need to be applied.
! .IP \fB\-mwarn\-devices\-csv\fR 4
  .IX Item "-mwarn-devices-csv"
  .PD 0
! .IP \fB\-mno\-warn\-devices\-csv\fR 4
  .IX Item "-mno-warn-devices-csv"
  .PD
  Warn if \fBdevices.csv\fR is not found or there are problem parsing it
  (default: on).
  .PP
! \fINDS32 Options\fR
  .IX Subsection "NDS32 Options"
  .PP
! These options are defined for NDS32 implementations:
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code in big\-endian mode.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code in little\-endian mode.
! .IP \fB\-mreduced\-regs\fR 4
  .IX Item "-mreduced-regs"
! Use reduced\-set registers for register allocation.
! .IP \fB\-mfull\-regs\fR 4
  .IX Item "-mfull-regs"
! Use full\-set registers for register allocation.
! .IP \fB\-mcmov\fR 4
  .IX Item "-mcmov"
  Generate conditional move instructions.
! .IP \fB\-mno\-cmov\fR 4
  .IX Item "-mno-cmov"
  Do not generate conditional move instructions.
! .IP \fB\-mext\-perf\fR 4
  .IX Item "-mext-perf"
  Generate performance extension instructions.
! .IP \fB\-mno\-ext\-perf\fR 4
  .IX Item "-mno-ext-perf"
  Do not generate performance extension instructions.
! .IP \fB\-mext\-perf2\fR 4
  .IX Item "-mext-perf2"
  Generate performance extension 2 instructions.
! .IP \fB\-mno\-ext\-perf2\fR 4
  .IX Item "-mno-ext-perf2"
  Do not generate performance extension 2 instructions.
! .IP \fB\-mext\-string\fR 4
  .IX Item "-mext-string"
  Generate string extension instructions.
! .IP \fB\-mno\-ext\-string\fR 4
  .IX Item "-mno-ext-string"
  Do not generate string extension instructions.
! .IP \fB\-mv3push\fR 4
  .IX Item "-mv3push"
  Generate v3 push25/pop25 instructions.
! .IP \fB\-mno\-v3push\fR 4
  .IX Item "-mno-v3push"
  Do not generate v3 push25/pop25 instructions.
! .IP \fB\-m16\-bit\fR 4
  .IX Item "-m16-bit"
  Generate 16\-bit instructions.
! .IP \fB\-mno\-16\-bit\fR 4
  .IX Item "-mno-16-bit"
  Do not generate 16\-bit instructions.
! .IP \fB\-misr\-vector\-size=\fR\fInum\fR 4
  .IX Item "-misr-vector-size=num"
  Specify the size of each interrupt vector, which must be 4 or 16.
! .IP \fB\-mcache\-block\-size=\fR\fInum\fR 4
  .IX Item "-mcache-block-size=num"
  Specify the size of each cache block,
  which must be a power of 2 between 4 and 512.
! .IP \fB\-march=\fR\fIarch\fR 4
  .IX Item "-march=arch"
  Specify the name of the target architecture.
! .IP \fB\-mcmodel=\fR\fIcode\-model\fR 4
  .IX Item "-mcmodel=code-model"
  Set the code model to one of
  .RS 4
! .IP \fBsmall\fR 4
  .IX Item "small"
! All the data and read\-only data segments must be within 512KB addressing space.
  The text segment must be within 16MB addressing space.
! .IP \fBmedium\fR 4
  .IX Item "medium"
! The data segment must be within 512KB while the read\-only data segment can be
  within 4GB addressing space.  The text segment should be still within 16MB
  addressing space.
! .IP \fBlarge\fR 4
  .IX Item "large"
  All the text and data segments can be within 4GB addressing space.
  .RE
  .RS 4
  .RE
! .IP \fB\-mctor\-dtor\fR 4
  .IX Item "-mctor-dtor"
  Enable constructor/destructor feature.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Guide linker to relax instructions.
  .PP
! \fINios II Options\fR
  .IX Subsection "Nios II Options"
  .PP
! These are the options defined for the Altera Nios II processor.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  Put global and static objects less than or equal to \fInum\fR bytes
! into the small data or BSS sections instead of the normal data or BSS
  sections.  The default value of \fInum\fR is 8.
! .IP \fB\-mgpopt=\fR\fIoption\fR 4
  .IX Item "-mgpopt=option"
  .PD 0
! .IP \fB\-mgpopt\fR 4
  .IX Item "-mgpopt"
! .IP \fB\-mno\-gpopt\fR 4
  .IX Item "-mno-gpopt"
  .PD
! Generate (do not generate) GP\-relative accesses.  The following 
  \&\fIoption\fR names are recognized:
  .RS 4
! .IP \fBnone\fR 4
  .IX Item "none"
! Do not generate GP\-relative accesses.
! .IP \fBlocal\fR 4
  .IX Item "local"
! Generate GP\-relative accesses for small data objects that are not 
  external, weak, or uninitialized common symbols.  
! Also use GP\-relative addressing for objects that
  have been explicitly placed in a small data section via a \f(CW\*(C`section\*(C'\fR
  attribute.
! .IP \fBglobal\fR 4
  .IX Item "global"
! As for \fBlocal\fR, but also generate GP\-relative accesses for
  small data objects that are external, weak, or common.  If you use this option,
  you must ensure that all parts of your program (including libraries) are
  compiled with the same \fB\-G\fR setting.
! .IP \fBdata\fR 4
  .IX Item "data"
! Generate GP\-relative accesses for all data objects in the program.  If you
! use this option, the entire data and BSS segments
  of your program must fit in 64K of memory and you must use an appropriate
  linker script to allocate them within the addressable range of the
  global pointer.
! .IP \fBall\fR 4
  .IX Item "all"
! Generate GP\-relative addresses for function pointers as well as data
! pointers.  If you use this option, the entire text, data, and BSS segments
  of your program must fit in 64K of memory and you must use an appropriate
  linker script to allocate them within the addressable range of the
  global pointer.
*************** global pointer.
*** 27497,27632 ****
  \&\fB\-mno\-gpopt\fR is equivalent to \fB\-mgpopt=none\fR.
  .Sp
  The default is \fB\-mgpopt\fR except when \fB\-fpic\fR or
! \&\fB\-fPIC\fR is specified to generate position-independent code.
! Note that the Nios \s-1II ABI\s0 does not permit GP-relative accesses from
  shared libraries.
  .Sp
  You may need to specify \fB\-mno\-gpopt\fR explicitly when building
  programs that include large amounts of small data, including large
! \&\s-1GOT\s0 data sections.  In this case, the 16\-bit offset for GP-relative
  addressing may not be large enough to allow access to the entire 
  small data section.
  .RE
! .IP "\fB\-mgprel\-sec=\fR\fIregexp\fR" 4
  .IX Item "-mgprel-sec=regexp"
  This option specifies additional section names that can be accessed via
! GP-relative addressing.  It is most useful in conjunction with 
  \&\f(CW\*(C`section\*(C'\fR attributes on variable declarations and a custom linker script.  
! The \fIregexp\fR is a \s-1POSIX\s0 Extended Regular Expression.
  .Sp
  This option does not affect the behavior of the \fB\-G\fR option, and 
  the specified sections are in addition to the standard \f(CW\*(C`.sdata\*(C'\fR
! and \f(CW\*(C`.sbss\*(C'\fR small-data sections that are recognized by \fB\-mgpopt\fR.
! .IP "\fB\-mr0rel\-sec=\fR\fIregexp\fR" 4
  .IX Item "-mr0rel-sec=regexp"
  This option specifies names of sections that can be accessed via a 
  16\-bit offset from \f(CW\*(C`r0\*(C'\fR; that is, in the low 32K or high 32K 
  of the 32\-bit address space.  It is most useful in conjunction with 
  \&\f(CW\*(C`section\*(C'\fR attributes on variable declarations and a custom linker script.  
! The \fIregexp\fR is a \s-1POSIX\s0 Extended Regular Expression.
  .Sp
! In contrast to the use of GP-relative addressing for small data, 
! zero-based addressing is never generated by default and there are no 
  conventional section names used in standard linker scripts for sections
  in the low or high areas of memory.
! .IP "\fB\-mel\fR" 4
  .IX Item "-mel"
  .PD 0
! .IP "\fB\-meb\fR" 4
  .IX Item "-meb"
  .PD
! Generate little-endian (default) or big-endian (experimental) code,
  respectively.
! .IP "\fB\-march=\fR\fIarch\fR" 4
  .IX Item "-march=arch"
! This specifies the name of the target Nios \s-1II\s0 architecture.  \s-1GCC\s0 uses this
  name to determine what kind of instructions it can emit when generating
  assembly code.  Permissible names are: \fBr1\fR, \fBr2\fR.
  .Sp
  The preprocessor macro \f(CW\*(C`_\|_nios2_arch_\|_\*(C'\fR is available to programs,
! with value 1 or 2, indicating the targeted \s-1ISA\s0 level.
! .IP "\fB\-mbypass\-cache\fR" 4
  .IX Item "-mbypass-cache"
  .PD 0
! .IP "\fB\-mno\-bypass\-cache\fR" 4
  .IX Item "-mno-bypass-cache"
  .PD
  Force all load and store instructions to always bypass cache by 
  using I/O variants of the instructions. The default is not to
  bypass the cache.
! .IP "\fB\-mno\-cache\-volatile\fR" 4
  .IX Item "-mno-cache-volatile"
  .PD 0
! .IP "\fB\-mcache\-volatile\fR" 4
  .IX Item "-mcache-volatile"
  .PD
  Volatile memory access bypass the cache using the I/O variants of 
  the load and store instructions. The default is not to bypass the cache.
! .IP "\fB\-mno\-fast\-sw\-div\fR" 4
  .IX Item "-mno-fast-sw-div"
  .PD 0
! .IP "\fB\-mfast\-sw\-div\fR" 4
  .IX Item "-mfast-sw-div"
  .PD
! Do not use table-based fast divide for small numbers. The default 
  is to use the fast divide at \fB\-O3\fR and above.
! .IP "\fB\-mno\-hw\-mul\fR" 4
  .IX Item "-mno-hw-mul"
  .PD 0
! .IP "\fB\-mhw\-mul\fR" 4
  .IX Item "-mhw-mul"
! .IP "\fB\-mno\-hw\-mulx\fR" 4
  .IX Item "-mno-hw-mulx"
! .IP "\fB\-mhw\-mulx\fR" 4
  .IX Item "-mhw-mulx"
! .IP "\fB\-mno\-hw\-div\fR" 4
  .IX Item "-mno-hw-div"
! .IP "\fB\-mhw\-div\fR" 4
  .IX Item "-mhw-div"
  .PD
  Enable or disable emitting \f(CW\*(C`mul\*(C'\fR, \f(CW\*(C`mulx\*(C'\fR and \f(CW\*(C`div\*(C'\fR family of 
  instructions by the compiler. The default is to emit \f(CW\*(C`mul\*(C'\fR
  and not emit \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`mulx\*(C'\fR.
! .IP "\fB\-mbmx\fR" 4
  .IX Item "-mbmx"
  .PD 0
! .IP "\fB\-mno\-bmx\fR" 4
  .IX Item "-mno-bmx"
! .IP "\fB\-mcdx\fR" 4
  .IX Item "-mcdx"
! .IP "\fB\-mno\-cdx\fR" 4
  .IX Item "-mno-cdx"
  .PD
! Enable or disable generation of Nios \s-1II R2 BMX\s0 (bit manipulation) and
! \&\s-1CDX\s0 (code density) instructions.  Enabling these instructions also
  requires \fB\-march=r2\fR.  Since these instructions are optional
  extensions to the R2 architecture, the default is not to emit them.
! .IP "\fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR" 4
  .IX Item "-mcustom-insn=N"
  .PD 0
! .IP "\fB\-mno\-custom\-\fR\fIinsn\fR" 4
  .IX Item "-mno-custom-insn"
  .PD
  Each \fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR option enables use of a
  custom instruction with encoding \fIN\fR when generating code that uses 
  \&\fIinsn\fR.  For example, \fB\-mcustom\-fadds=253\fR generates custom
! instruction 253 for single-precision floating-point add operations instead
  of the default behavior of using a library call.
  .Sp
  The following values of \fIinsn\fR are supported.  Except as otherwise
! noted, floating-point operations are expected to be implemented with
! normal \s-1IEEE 754\s0 semantics and correspond directly to the C operators or the
! equivalent \s-1GCC\s0 built-in functions.
  .Sp
! Single-precision floating point:
  .RS 4
  .IP "\fBfadds\fR, \fBfsubs\fR, \fBfdivs\fR, \fBfmuls\fR" 4
  .IX Item "fadds, fsubs, fdivs, fmuls"
  Binary arithmetic operations.
! .IP "\fBfnegs\fR" 4
  .IX Item "fnegs"
  Unary negation.
! .IP "\fBfabss\fR" 4
  .IX Item "fabss"
  Unary absolute value.
  .IP "\fBfcmpeqs\fR, \fBfcmpges\fR, \fBfcmpgts\fR, \fBfcmples\fR, \fBfcmplts\fR, \fBfcmpnes\fR" 4
--- 27428,27563 ----
  \&\fB\-mno\-gpopt\fR is equivalent to \fB\-mgpopt=none\fR.
  .Sp
  The default is \fB\-mgpopt\fR except when \fB\-fpic\fR or
! \&\fB\-fPIC\fR is specified to generate position\-independent code.
! Note that the Nios II ABI does not permit GP\-relative accesses from
  shared libraries.
  .Sp
  You may need to specify \fB\-mno\-gpopt\fR explicitly when building
  programs that include large amounts of small data, including large
! GOT data sections.  In this case, the 16\-bit offset for GP\-relative
  addressing may not be large enough to allow access to the entire 
  small data section.
  .RE
! .IP \fB\-mgprel\-sec=\fR\fIregexp\fR 4
  .IX Item "-mgprel-sec=regexp"
  This option specifies additional section names that can be accessed via
! GP\-relative addressing.  It is most useful in conjunction with 
  \&\f(CW\*(C`section\*(C'\fR attributes on variable declarations and a custom linker script.  
! The \fIregexp\fR is a POSIX Extended Regular Expression.
  .Sp
  This option does not affect the behavior of the \fB\-G\fR option, and 
  the specified sections are in addition to the standard \f(CW\*(C`.sdata\*(C'\fR
! and \f(CW\*(C`.sbss\*(C'\fR small\-data sections that are recognized by \fB\-mgpopt\fR.
! .IP \fB\-mr0rel\-sec=\fR\fIregexp\fR 4
  .IX Item "-mr0rel-sec=regexp"
  This option specifies names of sections that can be accessed via a 
  16\-bit offset from \f(CW\*(C`r0\*(C'\fR; that is, in the low 32K or high 32K 
  of the 32\-bit address space.  It is most useful in conjunction with 
  \&\f(CW\*(C`section\*(C'\fR attributes on variable declarations and a custom linker script.  
! The \fIregexp\fR is a POSIX Extended Regular Expression.
  .Sp
! In contrast to the use of GP\-relative addressing for small data, 
! zero\-based addressing is never generated by default and there are no 
  conventional section names used in standard linker scripts for sections
  in the low or high areas of memory.
! .IP \fB\-mel\fR 4
  .IX Item "-mel"
  .PD 0
! .IP \fB\-meb\fR 4
  .IX Item "-meb"
  .PD
! Generate little\-endian (default) or big\-endian (experimental) code,
  respectively.
! .IP \fB\-march=\fR\fIarch\fR 4
  .IX Item "-march=arch"
! This specifies the name of the target Nios II architecture.  GCC uses this
  name to determine what kind of instructions it can emit when generating
  assembly code.  Permissible names are: \fBr1\fR, \fBr2\fR.
  .Sp
  The preprocessor macro \f(CW\*(C`_\|_nios2_arch_\|_\*(C'\fR is available to programs,
! with value 1 or 2, indicating the targeted ISA level.
! .IP \fB\-mbypass\-cache\fR 4
  .IX Item "-mbypass-cache"
  .PD 0
! .IP \fB\-mno\-bypass\-cache\fR 4
  .IX Item "-mno-bypass-cache"
  .PD
  Force all load and store instructions to always bypass cache by 
  using I/O variants of the instructions. The default is not to
  bypass the cache.
! .IP \fB\-mno\-cache\-volatile\fR 4
  .IX Item "-mno-cache-volatile"
  .PD 0
! .IP \fB\-mcache\-volatile\fR 4
  .IX Item "-mcache-volatile"
  .PD
  Volatile memory access bypass the cache using the I/O variants of 
  the load and store instructions. The default is not to bypass the cache.
! .IP \fB\-mno\-fast\-sw\-div\fR 4
  .IX Item "-mno-fast-sw-div"
  .PD 0
! .IP \fB\-mfast\-sw\-div\fR 4
  .IX Item "-mfast-sw-div"
  .PD
! Do not use table\-based fast divide for small numbers. The default 
  is to use the fast divide at \fB\-O3\fR and above.
! .IP \fB\-mno\-hw\-mul\fR 4
  .IX Item "-mno-hw-mul"
  .PD 0
! .IP \fB\-mhw\-mul\fR 4
  .IX Item "-mhw-mul"
! .IP \fB\-mno\-hw\-mulx\fR 4
  .IX Item "-mno-hw-mulx"
! .IP \fB\-mhw\-mulx\fR 4
  .IX Item "-mhw-mulx"
! .IP \fB\-mno\-hw\-div\fR 4
  .IX Item "-mno-hw-div"
! .IP \fB\-mhw\-div\fR 4
  .IX Item "-mhw-div"
  .PD
  Enable or disable emitting \f(CW\*(C`mul\*(C'\fR, \f(CW\*(C`mulx\*(C'\fR and \f(CW\*(C`div\*(C'\fR family of 
  instructions by the compiler. The default is to emit \f(CW\*(C`mul\*(C'\fR
  and not emit \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`mulx\*(C'\fR.
! .IP \fB\-mbmx\fR 4
  .IX Item "-mbmx"
  .PD 0
! .IP \fB\-mno\-bmx\fR 4
  .IX Item "-mno-bmx"
! .IP \fB\-mcdx\fR 4
  .IX Item "-mcdx"
! .IP \fB\-mno\-cdx\fR 4
  .IX Item "-mno-cdx"
  .PD
! Enable or disable generation of Nios II R2 BMX (bit manipulation) and
! CDX (code density) instructions.  Enabling these instructions also
  requires \fB\-march=r2\fR.  Since these instructions are optional
  extensions to the R2 architecture, the default is not to emit them.
! .IP \fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR 4
  .IX Item "-mcustom-insn=N"
  .PD 0
! .IP \fB\-mno\-custom\-\fR\fIinsn\fR 4
  .IX Item "-mno-custom-insn"
  .PD
  Each \fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR option enables use of a
  custom instruction with encoding \fIN\fR when generating code that uses 
  \&\fIinsn\fR.  For example, \fB\-mcustom\-fadds=253\fR generates custom
! instruction 253 for single\-precision floating\-point add operations instead
  of the default behavior of using a library call.
  .Sp
  The following values of \fIinsn\fR are supported.  Except as otherwise
! noted, floating\-point operations are expected to be implemented with
! normal IEEE 754 semantics and correspond directly to the C operators or the
! equivalent GCC built\-in functions.
  .Sp
! Single\-precision floating point:
  .RS 4
  .IP "\fBfadds\fR, \fBfsubs\fR, \fBfdivs\fR, \fBfmuls\fR" 4
  .IX Item "fadds, fsubs, fdivs, fmuls"
  Binary arithmetic operations.
! .IP \fBfnegs\fR 4
  .IX Item "fnegs"
  Unary negation.
! .IP \fBfabss\fR 4
  .IX Item "fabss"
  Unary absolute value.
  .IP "\fBfcmpeqs\fR, \fBfcmpges\fR, \fBfcmpgts\fR, \fBfcmples\fR, \fBfcmplts\fR, \fBfcmpnes\fR" 4
*************** Unary absolute value.
*** 27634,27659 ****
  Comparison operations.
  .IP "\fBfmins\fR, \fBfmaxs\fR" 4
  .IX Item "fmins, fmaxs"
! Floating-point minimum and maximum.  These instructions are only
  generated if \fB\-ffinite\-math\-only\fR is specified.
! .IP "\fBfsqrts\fR" 4
  .IX Item "fsqrts"
  Unary square root operation.
  .IP "\fBfcoss\fR, \fBfsins\fR, \fBftans\fR, \fBfatans\fR, \fBfexps\fR, \fBflogs\fR" 4
  .IX Item "fcoss, fsins, ftans, fatans, fexps, flogs"
! Floating-point trigonometric and exponential functions.  These instructions
  are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
  .RE
  .RS 4
  .Sp
! Double-precision floating point:
  .IP "\fBfaddd\fR, \fBfsubd\fR, \fBfdivd\fR, \fBfmuld\fR" 4
  .IX Item "faddd, fsubd, fdivd, fmuld"
  Binary arithmetic operations.
! .IP "\fBfnegd\fR" 4
  .IX Item "fnegd"
  Unary negation.
! .IP "\fBfabsd\fR" 4
  .IX Item "fabsd"
  Unary absolute value.
  .IP "\fBfcmpeqd\fR, \fBfcmpged\fR, \fBfcmpgtd\fR, \fBfcmpled\fR, \fBfcmpltd\fR, \fBfcmpned\fR" 4
--- 27565,27590 ----
  Comparison operations.
  .IP "\fBfmins\fR, \fBfmaxs\fR" 4
  .IX Item "fmins, fmaxs"
! Floating\-point minimum and maximum.  These instructions are only
  generated if \fB\-ffinite\-math\-only\fR is specified.
! .IP \fBfsqrts\fR 4
  .IX Item "fsqrts"
  Unary square root operation.
  .IP "\fBfcoss\fR, \fBfsins\fR, \fBftans\fR, \fBfatans\fR, \fBfexps\fR, \fBflogs\fR" 4
  .IX Item "fcoss, fsins, ftans, fatans, fexps, flogs"
! Floating\-point trigonometric and exponential functions.  These instructions
  are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
  .RE
  .RS 4
  .Sp
! Double\-precision floating point:
  .IP "\fBfaddd\fR, \fBfsubd\fR, \fBfdivd\fR, \fBfmuld\fR" 4
  .IX Item "faddd, fsubd, fdivd, fmuld"
  Binary arithmetic operations.
! .IP \fBfnegd\fR 4
  .IX Item "fnegd"
  Unary negation.
! .IP \fBfabsd\fR 4
  .IX Item "fabsd"
  Unary absolute value.
  .IP "\fBfcmpeqd\fR, \fBfcmpged\fR, \fBfcmpgtd\fR, \fBfcmpled\fR, \fBfcmpltd\fR, \fBfcmpned\fR" 4
*************** Unary absolute value.
*** 27661,27737 ****
  Comparison operations.
  .IP "\fBfmind\fR, \fBfmaxd\fR" 4
  .IX Item "fmind, fmaxd"
! Double-precision minimum and maximum.  These instructions are only
  generated if \fB\-ffinite\-math\-only\fR is specified.
! .IP "\fBfsqrtd\fR" 4
  .IX Item "fsqrtd"
  Unary square root operation.
  .IP "\fBfcosd\fR, \fBfsind\fR, \fBftand\fR, \fBfatand\fR, \fBfexpd\fR, \fBflogd\fR" 4
  .IX Item "fcosd, fsind, ftand, fatand, fexpd, flogd"
! Double-precision trigonometric and exponential functions.  These instructions
  are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
  .RE
  .RS 4
  .Sp
  Conversions:
! .IP "\fBfextsd\fR" 4
  .IX Item "fextsd"
  Conversion from single precision to double precision.
! .IP "\fBftruncds\fR" 4
  .IX Item "ftruncds"
  Conversion from double precision to single precision.
  .IP "\fBfixsi\fR, \fBfixsu\fR, \fBfixdi\fR, \fBfixdu\fR" 4
  .IX Item "fixsi, fixsu, fixdi, fixdu"
  Conversion from floating point to signed or unsigned integer types, with
  truncation towards zero.
! .IP "\fBround\fR" 4
  .IX Item "round"
! Conversion from single-precision floating point to signed integer,
  rounding to the nearest integer and ties away from zero.
  This corresponds to the \f(CW\*(C`_\|_builtin_lroundf\*(C'\fR function when
  \&\fB\-fno\-math\-errno\fR is used.
  .IP "\fBfloatis\fR, \fBfloatus\fR, \fBfloatid\fR, \fBfloatud\fR" 4
  .IX Item "floatis, floatus, floatid, floatud"
! Conversion from signed or unsigned integer types to floating-point types.
  .RE
  .RS 4
  .Sp
  In addition, all of the following transfer instructions for internal
! registers X and Y must be provided to use any of the double-precision
! floating-point instructions.  Custom instructions taking two
! double-precision source operands expect the first operand in the
  64\-bit register X.  The other operand (or only operand of a unary
  operation) is given to the custom arithmetic instruction with the
  least significant half in source register \fIsrc1\fR and the most
  significant half in \fIsrc2\fR.  A custom instruction that returns a
! double-precision result returns the most significant 32 bits in the
  destination register and the other half in 32\-bit register Y.  
! \&\s-1GCC\s0 automatically generates the necessary code sequences to write
! register X and/or read register Y when double-precision floating-point
  instructions are used.
! .IP "\fBfwrx\fR" 4
  .IX Item "fwrx"
  Write \fIsrc1\fR into the least significant half of X and \fIsrc2\fR into
  the most significant half of X.
! .IP "\fBfwry\fR" 4
  .IX Item "fwry"
  Write \fIsrc1\fR into Y.
  .IP "\fBfrdxhi\fR, \fBfrdxlo\fR" 4
  .IX Item "frdxhi, frdxlo"
  Read the most or least (respectively) significant half of X and store it in
  \&\fIdest\fR.
! .IP "\fBfrdy\fR" 4
  .IX Item "frdy"
  Read the value of Y and store it into \fIdest\fR.
  .RE
  .RS 4
  .Sp
! Note that you can gain more local control over generation of Nios \s-1II\s0 custom
! instructions by using the \f(CW\*(C`target("custom\-\f(CIinsn\f(CW=\f(CIN\f(CW")\*(C'\fR
! and \f(CW\*(C`target("no\-custom\-\f(CIinsn\f(CW")\*(C'\fR function attributes
  or pragmas.
  .RE
! .IP "\fB\-mcustom\-fpu\-cfg=\fR\fIname\fR" 4
  .IX Item "-mcustom-fpu-cfg=name"
  This option enables a predefined, named set of custom instruction encodings
  (see \fB\-mcustom\-\fR\fIinsn\fR above).  
--- 27592,27668 ----
  Comparison operations.
  .IP "\fBfmind\fR, \fBfmaxd\fR" 4
  .IX Item "fmind, fmaxd"
! Double\-precision minimum and maximum.  These instructions are only
  generated if \fB\-ffinite\-math\-only\fR is specified.
! .IP \fBfsqrtd\fR 4
  .IX Item "fsqrtd"
  Unary square root operation.
  .IP "\fBfcosd\fR, \fBfsind\fR, \fBftand\fR, \fBfatand\fR, \fBfexpd\fR, \fBflogd\fR" 4
  .IX Item "fcosd, fsind, ftand, fatand, fexpd, flogd"
! Double\-precision trigonometric and exponential functions.  These instructions
  are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
  .RE
  .RS 4
  .Sp
  Conversions:
! .IP \fBfextsd\fR 4
  .IX Item "fextsd"
  Conversion from single precision to double precision.
! .IP \fBftruncds\fR 4
  .IX Item "ftruncds"
  Conversion from double precision to single precision.
  .IP "\fBfixsi\fR, \fBfixsu\fR, \fBfixdi\fR, \fBfixdu\fR" 4
  .IX Item "fixsi, fixsu, fixdi, fixdu"
  Conversion from floating point to signed or unsigned integer types, with
  truncation towards zero.
! .IP \fBround\fR 4
  .IX Item "round"
! Conversion from single\-precision floating point to signed integer,
  rounding to the nearest integer and ties away from zero.
  This corresponds to the \f(CW\*(C`_\|_builtin_lroundf\*(C'\fR function when
  \&\fB\-fno\-math\-errno\fR is used.
  .IP "\fBfloatis\fR, \fBfloatus\fR, \fBfloatid\fR, \fBfloatud\fR" 4
  .IX Item "floatis, floatus, floatid, floatud"
! Conversion from signed or unsigned integer types to floating\-point types.
  .RE
  .RS 4
  .Sp
  In addition, all of the following transfer instructions for internal
! registers X and Y must be provided to use any of the double\-precision
! floating\-point instructions.  Custom instructions taking two
! double\-precision source operands expect the first operand in the
  64\-bit register X.  The other operand (or only operand of a unary
  operation) is given to the custom arithmetic instruction with the
  least significant half in source register \fIsrc1\fR and the most
  significant half in \fIsrc2\fR.  A custom instruction that returns a
! double\-precision result returns the most significant 32 bits in the
  destination register and the other half in 32\-bit register Y.  
! GCC automatically generates the necessary code sequences to write
! register X and/or read register Y when double\-precision floating\-point
  instructions are used.
! .IP \fBfwrx\fR 4
  .IX Item "fwrx"
  Write \fIsrc1\fR into the least significant half of X and \fIsrc2\fR into
  the most significant half of X.
! .IP \fBfwry\fR 4
  .IX Item "fwry"
  Write \fIsrc1\fR into Y.
  .IP "\fBfrdxhi\fR, \fBfrdxlo\fR" 4
  .IX Item "frdxhi, frdxlo"
  Read the most or least (respectively) significant half of X and store it in
  \&\fIdest\fR.
! .IP \fBfrdy\fR 4
  .IX Item "frdy"
  Read the value of Y and store it into \fIdest\fR.
  .RE
  .RS 4
  .Sp
! Note that you can gain more local control over generation of Nios II custom
! instructions by using the \f(CWtarget("custom\-\fR\f(CIinsn\fR\f(CW=\fR\f(CIN\fR\f(CW")\fR
! and \f(CWtarget("no\-custom\-\fR\f(CIinsn\fR\f(CW")\fR function attributes
  or pragmas.
  .RE
! .IP \fB\-mcustom\-fpu\-cfg=\fR\fIname\fR 4
  .IX Item "-mcustom-fpu-cfg=name"
  This option enables a predefined, named set of custom instruction encodings
  (see \fB\-mcustom\-\fR\fIinsn\fR above).  
*************** Custom instruction assignments given by
*** 27789,27800 ****
  \&\fB\-mcustom\-fpu\-cfg=\fR, regardless of the
  order of the options on the command line.
  .Sp
! Note that you can gain more local control over selection of a \s-1FPU\s0
! configuration by using the \f(CW\*(C`target("custom\-fpu\-cfg=\f(CIname\f(CW")\*(C'\fR
  function attribute
  or pragma.
  .Sp
! The name \fIfph2\fR is an abbreviation for \fINios \s-1II\s0 Floating Point
  Hardware 2 Component\fR.  Please note that the custom instructions enabled by
  \&\fB\-mcustom\-fmins=233\fR and \fB\-mcustom\-fmaxs=234\fR are only generated
  if \fB\-ffinite\-math\-only\fR is specified.  The custom instruction enabled by
--- 27720,27731 ----
  \&\fB\-mcustom\-fpu\-cfg=\fR, regardless of the
  order of the options on the command line.
  .Sp
! Note that you can gain more local control over selection of a FPU
! configuration by using the \f(CWtarget("custom\-fpu\-cfg=\fR\f(CIname\fR\f(CW")\fR
  function attribute
  or pragma.
  .Sp
! The name \fIfph2\fR is an abbreviation for \fINios II Floating Point
  Hardware 2 Component\fR.  Please note that the custom instructions enabled by
  \&\fB\-mcustom\-fmins=233\fR and \fB\-mcustom\-fmaxs=234\fR are only generated
  if \fB\-ffinite\-math\-only\fR is specified.  The custom instruction enabled by
*************** if \fB\-ffinite\-math\-only\fR is specif
*** 27802,27841 ****
  specified.  In contrast to the other configurations,
  \&\fB\-fsingle\-precision\-constant\fR is not set.
  .PP
! These additional \fB\-m\fR options are available for the Altera Nios \s-1II
! ELF\s0 (bare-metal) target:
! .IP "\fB\-mhal\fR" 4
  .IX Item "-mhal"
! Link with \s-1HAL BSP.\s0  This suppresses linking with the GCC-provided C runtime
  startup and termination code, and is typically used in conjunction with
  \&\fB\-msys\-crt0=\fR to specify the location of the alternate startup code
! provided by the \s-1HAL BSP.\s0
! .IP "\fB\-msmallc\fR" 4
  .IX Item "-msmallc"
  Link with a limited version of the C library, \fB\-lsmallc\fR, rather than
  Newlib.
! .IP "\fB\-msys\-crt0=\fR\fIstartfile\fR" 4
  .IX Item "-msys-crt0=startfile"
  \&\fIstartfile\fR is the file name of the startfile (crt0) to use 
  when linking.  This option is only useful in conjunction with \fB\-mhal\fR.
! .IP "\fB\-msys\-lib=\fR\fIsystemlib\fR" 4
  .IX Item "-msys-lib=systemlib"
  \&\fIsystemlib\fR is the library name of the library that provides
! low-level system calls required by the C library,
  e.g. \f(CW\*(C`read\*(C'\fR and \f(CW\*(C`write\*(C'\fR.
! This option is typically used to link with a library provided by a \s-1HAL BSP.\s0
  .PP
! \fINvidia \s-1PTX\s0 Options\fR
  .IX Subsection "Nvidia PTX Options"
  .PP
! These options are defined for Nvidia \s-1PTX:\s0
! .IP "\fB\-m64\fR" 4
  .IX Item "-m64"
! Ignored, but preserved for backward compatibility.  Only 64\-bit \s-1ABI\s0 is
  supported.
! .IP "\fB\-march=\fR\fIarchitecture-string\fR" 4
  .IX Item "-march=architecture-string"
! Generate code for the specified \s-1PTX ISA\s0 target architecture
  (e.g. \fBsm_35\fR).  Valid architecture strings are \fBsm_30\fR,
  \&\fBsm_35\fR, \fBsm_53\fR, \fBsm_70\fR, \fBsm_75\fR and
  \&\fBsm_80\fR.
--- 27733,27772 ----
  specified.  In contrast to the other configurations,
  \&\fB\-fsingle\-precision\-constant\fR is not set.
  .PP
! These additional \fB\-m\fR options are available for the Altera Nios II
! ELF (bare\-metal) target:
! .IP \fB\-mhal\fR 4
  .IX Item "-mhal"
! Link with HAL BSP.  This suppresses linking with the GCC\-provided C runtime
  startup and termination code, and is typically used in conjunction with
  \&\fB\-msys\-crt0=\fR to specify the location of the alternate startup code
! provided by the HAL BSP.
! .IP \fB\-msmallc\fR 4
  .IX Item "-msmallc"
  Link with a limited version of the C library, \fB\-lsmallc\fR, rather than
  Newlib.
! .IP \fB\-msys\-crt0=\fR\fIstartfile\fR 4
  .IX Item "-msys-crt0=startfile"
  \&\fIstartfile\fR is the file name of the startfile (crt0) to use 
  when linking.  This option is only useful in conjunction with \fB\-mhal\fR.
! .IP \fB\-msys\-lib=\fR\fIsystemlib\fR 4
  .IX Item "-msys-lib=systemlib"
  \&\fIsystemlib\fR is the library name of the library that provides
! low\-level system calls required by the C library,
  e.g. \f(CW\*(C`read\*(C'\fR and \f(CW\*(C`write\*(C'\fR.
! This option is typically used to link with a library provided by a HAL BSP.
  .PP
! \fINvidia PTX Options\fR
  .IX Subsection "Nvidia PTX Options"
  .PP
! These options are defined for Nvidia PTX:
! .IP \fB\-m64\fR 4
  .IX Item "-m64"
! Ignored, but preserved for backward compatibility.  Only 64\-bit ABI is
  supported.
! .IP \fB\-march=\fR\fIarchitecture\-string\fR 4
  .IX Item "-march=architecture-string"
! Generate code for the specified PTX ISA target architecture
  (e.g. \fBsm_35\fR).  Valid architecture strings are \fBsm_30\fR,
  \&\fBsm_35\fR, \fBsm_53\fR, \fBsm_70\fR, \fBsm_75\fR and
  \&\fBsm_80\fR.
*************** The default depends on how the compiler
*** 27845,27904 ****
  This option sets the value of the preprocessor macro
  \&\f(CW\*(C`_\|_PTX_SM_\|_\*(C'\fR; for instance, for \fBsm_35\fR, it has the value
  \&\fB350\fR.
! .IP "\fB\-misa=\fR\fIarchitecture-string\fR" 4
  .IX Item "-misa=architecture-string"
  Alias of \fB\-march=\fR.
! .IP "\fB\-march\-map=\fR\fIarchitecture-string\fR" 4
  .IX Item "-march-map=architecture-string"
  Select the closest available \fB\-march=\fR value that is not more
  capable.  For instance, for \fB\-march\-map=sm_50\fR select
  \&\fB\-march=sm_35\fR, and for \fB\-march\-map=sm_53\fR select
  \&\fB\-march=sm_53\fR.
! .IP "\fB\-mptx=\fR\fIversion-string\fR" 4
  .IX Item "-mptx=version-string"
! Generate code for the specified \s-1PTX ISA\s0 version (e.g. \fB7.0\fR).
  Valid version strings include \fB3.1\fR, \fB6.0\fR, \fB6.3\fR, and
! \&\fB7.0\fR.  The default \s-1PTX ISA\s0 version is 6.0, unless a higher
! version is required for specified \s-1PTX ISA\s0 target architecture via
  option \fB\-march=\fR.
  .Sp
  This option sets the values of the preprocessor macros
  \&\f(CW\*(C`_\|_PTX_ISA_VERSION_MAJOR_\|_\*(C'\fR and \f(CW\*(C`_\|_PTX_ISA_VERSION_MINOR_\|_\*(C'\fR;
  for instance, for \fB3.1\fR the macros have the values \fB3\fR and
  \&\fB1\fR, respectively.
! .IP "\fB\-mmainkernel\fR" 4
  .IX Item "-mmainkernel"
! Link in code for a _\|_main kernel.  This is for stand-alone instead of
  offloading execution.
! .IP "\fB\-moptimize\fR" 4
  .IX Item "-moptimize"
  Apply partitioned execution optimizations.  This is the default when any
  level of optimization is selected.
! .IP "\fB\-msoft\-stack\fR" 4
  .IX Item "-msoft-stack"
  Generate code that does not use \f(CW\*(C`.local\*(C'\fR memory
! directly for stack storage. Instead, a per-warp stack pointer is
! maintained explicitly. This enables variable-length stack allocation (with
! variable-length arrays or \f(CW\*(C`alloca\*(C'\fR), and when global memory is used for
  underlying storage, makes it possible to access automatic variables from other
  threads, or with atomic instructions. This code generation variant is used
  for OpenMP offloading, but the option is exposed on its own for the purpose
  of testing the compiler; to generate code suitable for linking into programs
  using OpenMP offloading, use option \fB\-mgomp\fR.
! .IP "\fB\-muniform\-simt\fR" 4
  .IX Item "-muniform-simt"
  Switch to code generation variant that allows to execute all threads in each
  warp, while maintaining memory state and side effects as if only one thread
! in each warp was active outside of OpenMP \s-1SIMD\s0 regions.  All atomic operations
  and calls to runtime (malloc, free, vprintf) are conditionally executed (iff
  current lane index equals the master lane index), and the register being
  assigned is copied via a shuffle instruction from the master lane.  Outside of
! \&\s-1SIMD\s0 regions lane 0 is the master; inside, each thread sees itself as the
! master.  Shared memory array \f(CW\*(C`int _\|_nvptx_uni[]\*(C'\fR stores all-zeros or
! all-ones bitmasks for each warp, indicating current mode (0 outside of \s-1SIMD\s0
! regions).  Each thread can bitwise-and the bitmask at position \f(CW\*(C`tid.y\*(C'\fR
  with current lane index to compute the master lane index.
! .IP "\fB\-mgomp\fR" 4
  .IX Item "-mgomp"
  Generate code for use in OpenMP offloading: enables \fB\-msoft\-stack\fR and
  \&\fB\-muniform\-simt\fR options, and selects corresponding multilib variant.
--- 27776,27835 ----
  This option sets the value of the preprocessor macro
  \&\f(CW\*(C`_\|_PTX_SM_\|_\*(C'\fR; for instance, for \fBsm_35\fR, it has the value
  \&\fB350\fR.
! .IP \fB\-misa=\fR\fIarchitecture\-string\fR 4
  .IX Item "-misa=architecture-string"
  Alias of \fB\-march=\fR.
! .IP \fB\-march\-map=\fR\fIarchitecture\-string\fR 4
  .IX Item "-march-map=architecture-string"
  Select the closest available \fB\-march=\fR value that is not more
  capable.  For instance, for \fB\-march\-map=sm_50\fR select
  \&\fB\-march=sm_35\fR, and for \fB\-march\-map=sm_53\fR select
  \&\fB\-march=sm_53\fR.
! .IP \fB\-mptx=\fR\fIversion\-string\fR 4
  .IX Item "-mptx=version-string"
! Generate code for the specified PTX ISA version (e.g. \fB7.0\fR).
  Valid version strings include \fB3.1\fR, \fB6.0\fR, \fB6.3\fR, and
! \&\fB7.0\fR.  The default PTX ISA version is 6.0, unless a higher
! version is required for specified PTX ISA target architecture via
  option \fB\-march=\fR.
  .Sp
  This option sets the values of the preprocessor macros
  \&\f(CW\*(C`_\|_PTX_ISA_VERSION_MAJOR_\|_\*(C'\fR and \f(CW\*(C`_\|_PTX_ISA_VERSION_MINOR_\|_\*(C'\fR;
  for instance, for \fB3.1\fR the macros have the values \fB3\fR and
  \&\fB1\fR, respectively.
! .IP \fB\-mmainkernel\fR 4
  .IX Item "-mmainkernel"
! Link in code for a _\|_main kernel.  This is for stand\-alone instead of
  offloading execution.
! .IP \fB\-moptimize\fR 4
  .IX Item "-moptimize"
  Apply partitioned execution optimizations.  This is the default when any
  level of optimization is selected.
! .IP \fB\-msoft\-stack\fR 4
  .IX Item "-msoft-stack"
  Generate code that does not use \f(CW\*(C`.local\*(C'\fR memory
! directly for stack storage. Instead, a per\-warp stack pointer is
! maintained explicitly. This enables variable\-length stack allocation (with
! variable\-length arrays or \f(CW\*(C`alloca\*(C'\fR), and when global memory is used for
  underlying storage, makes it possible to access automatic variables from other
  threads, or with atomic instructions. This code generation variant is used
  for OpenMP offloading, but the option is exposed on its own for the purpose
  of testing the compiler; to generate code suitable for linking into programs
  using OpenMP offloading, use option \fB\-mgomp\fR.
! .IP \fB\-muniform\-simt\fR 4
  .IX Item "-muniform-simt"
  Switch to code generation variant that allows to execute all threads in each
  warp, while maintaining memory state and side effects as if only one thread
! in each warp was active outside of OpenMP SIMD regions.  All atomic operations
  and calls to runtime (malloc, free, vprintf) are conditionally executed (iff
  current lane index equals the master lane index), and the register being
  assigned is copied via a shuffle instruction from the master lane.  Outside of
! SIMD regions lane 0 is the master; inside, each thread sees itself as the
! master.  Shared memory array \f(CW\*(C`int _\|_nvptx_uni[]\*(C'\fR stores all\-zeros or
! all\-ones bitmasks for each warp, indicating current mode (0 outside of SIMD
! regions).  Each thread can bitwise\-and the bitmask at position \f(CW\*(C`tid.y\*(C'\fR
  with current lane index to compute the master lane index.
! .IP \fB\-mgomp\fR 4
  .IX Item "-mgomp"
  Generate code for use in OpenMP offloading: enables \fB\-msoft\-stack\fR and
  \&\fB\-muniform\-simt\fR options, and selects corresponding multilib variant.
*************** Generate code for use in OpenMP offloadi
*** 27907,28045 ****
  .IX Subsection "OpenRISC Options"
  .PP
  These options are defined for OpenRISC:
! .IP "\fB\-mboard=\fR\fIname\fR" 4
  .IX Item "-mboard=name"
  Configure a board specific runtime.  This will be passed to the linker for
  newlib board library linking.  The default is \f(CW\*(C`or1ksim\*(C'\fR.
! .IP "\fB\-mnewlib\fR" 4
  .IX Item "-mnewlib"
  This option is ignored; it is for compatibility purposes only.  This used to
  select linker and preprocessor options for use with newlib.
! .IP "\fB\-msoft\-div\fR" 4
  .IX Item "-msoft-div"
  .PD 0
! .IP "\fB\-mhard\-div\fR" 4
  .IX Item "-mhard-div"
  .PD
  Select software or hardware divide (\f(CW\*(C`l.div\*(C'\fR, \f(CW\*(C`l.divu\*(C'\fR) instructions.
  This default is hardware divide.
! .IP "\fB\-msoft\-mul\fR" 4
  .IX Item "-msoft-mul"
  .PD 0
! .IP "\fB\-mhard\-mul\fR" 4
  .IX Item "-mhard-mul"
  .PD
  Select software or hardware multiply (\f(CW\*(C`l.mul\*(C'\fR, \f(CW\*(C`l.muli\*(C'\fR) instructions.
  This default is hardware multiply.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
  Select software or hardware for floating point operations.
  The default is software.
! .IP "\fB\-mdouble\-float\fR" 4
  .IX Item "-mdouble-float"
! When \fB\-mhard\-float\fR is selected, enables generation of double-precision
  floating point instructions.  By default functions from \fIlibgcc\fR are used
! to perform double-precision floating point operations.
! .IP "\fB\-munordered\-float\fR" 4
  .IX Item "-munordered-float"
  When \fB\-mhard\-float\fR is selected, enables generation of unordered
  floating point compare and set flag (\f(CW\*(C`lf.sfun*\*(C'\fR) instructions.  By default
  functions from \fIlibgcc\fR are used to perform unordered floating point
  compare and set flag operations.
! .IP "\fB\-mcmov\fR" 4
  .IX Item "-mcmov"
  Enable generation of conditional move (\f(CW\*(C`l.cmov\*(C'\fR) instructions.  By
  default the equivalent will be generated using set and branch.
! .IP "\fB\-mror\fR" 4
  .IX Item "-mror"
  Enable generation of rotate right (\f(CW\*(C`l.ror\*(C'\fR) instructions.  By default
  functions from \fIlibgcc\fR are used to perform rotate right operations.
! .IP "\fB\-mrori\fR" 4
  .IX Item "-mrori"
  Enable generation of rotate right with immediate (\f(CW\*(C`l.rori\*(C'\fR) instructions.
  By default functions from \fIlibgcc\fR are used to perform rotate right with
  immediate operations.
! .IP "\fB\-msext\fR" 4
  .IX Item "-msext"
  Enable generation of sign extension (\f(CW\*(C`l.ext*\*(C'\fR) instructions.  By default
  memory loads are used to perform sign extension.
! .IP "\fB\-msfimm\fR" 4
  .IX Item "-msfimm"
  Enable generation of compare and set flag with immediate (\f(CW\*(C`l.sf*i\*(C'\fR)
  instructions.  By default extra instructions will be generated to store the
  immediate to a register first.
! .IP "\fB\-mshftimm\fR" 4
  .IX Item "-mshftimm"
  Enable generation of shift with immediate (\f(CW\*(C`l.srai\*(C'\fR, \f(CW\*(C`l.srli\*(C'\fR,
  \&\f(CW\*(C`l.slli\*(C'\fR) instructions.  By default extra instructions will be generated
  to store the immediate to a register first.
! .IP "\fB\-mcmodel=small\fR" 4
  .IX Item "-mcmodel=small"
! Generate OpenRISC code for the small model: The \s-1GOT\s0 is limited to 64k. This is
  the default model.
! .IP "\fB\-mcmodel=large\fR" 4
  .IX Item "-mcmodel=large"
! Generate OpenRISC code for the large model: The \s-1GOT\s0 may grow up to 4G in size.
  .PP
! \fI\s-1PDP\-11\s0 Options\fR
  .IX Subsection "PDP-11 Options"
  .PP
! These options are defined for the \s-1PDP\-11:\s0
! .IP "\fB\-mfpu\fR" 4
  .IX Item "-mfpu"
! Use hardware \s-1FPP\s0 floating point.  This is the default.  (\s-1FIS\s0 floating
! point on the \s-1PDP\-11/40\s0 is not supported.)  Implies \-m45.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  Do not use hardware floating point.
! .IP "\fB\-mac0\fR" 4
  .IX Item "-mac0"
! Return floating-point results in ac0 (fr0 in Unix assembler syntax).
! .IP "\fB\-mno\-ac0\fR" 4
  .IX Item "-mno-ac0"
! Return floating-point results in memory.  This is the default.
! .IP "\fB\-m40\fR" 4
  .IX Item "-m40"
! Generate code for a \s-1PDP\-11/40.\s0  Implies \-msoft\-float \-mno\-split.
! .IP "\fB\-m45\fR" 4
  .IX Item "-m45"
! Generate code for a \s-1PDP\-11/45.\s0  This is the default.
! .IP "\fB\-m10\fR" 4
  .IX Item "-m10"
! Generate code for a \s-1PDP\-11/10.\s0  Implies \-msoft\-float \-mno\-split.
! .IP "\fB\-mint16\fR" 4
  .IX Item "-mint16"
  .PD 0
! .IP "\fB\-mno\-int32\fR" 4
  .IX Item "-mno-int32"
  .PD
  Use 16\-bit \f(CW\*(C`int\*(C'\fR.  This is the default.
! .IP "\fB\-mint32\fR" 4
  .IX Item "-mint32"
  .PD 0
! .IP "\fB\-mno\-int16\fR" 4
  .IX Item "-mno-int16"
  .PD
  Use 32\-bit \f(CW\*(C`int\*(C'\fR.
! .IP "\fB\-msplit\fR" 4
  .IX Item "-msplit"
  Target has split instruction and data space.  Implies \-m45.
! .IP "\fB\-munix\-asm\fR" 4
  .IX Item "-munix-asm"
  Use Unix assembler syntax.
! .IP "\fB\-mdec\-asm\fR" 4
  .IX Item "-mdec-asm"
! Use \s-1DEC\s0 assembler syntax.
! .IP "\fB\-mgnu\-asm\fR" 4
  .IX Item "-mgnu-asm"
! Use \s-1GNU\s0 assembler syntax.  This is the default.
! .IP "\fB\-mlra\fR" 4
  .IX Item "-mlra"
! Use the new \s-1LRA\s0 register allocator.  By default, the old \*(L"reload\*(R"
  allocator is used.
  .PP
  \fIPowerPC Options\fR
--- 27838,27976 ----
  .IX Subsection "OpenRISC Options"
  .PP
  These options are defined for OpenRISC:
! .IP \fB\-mboard=\fR\fIname\fR 4
  .IX Item "-mboard=name"
  Configure a board specific runtime.  This will be passed to the linker for
  newlib board library linking.  The default is \f(CW\*(C`or1ksim\*(C'\fR.
! .IP \fB\-mnewlib\fR 4
  .IX Item "-mnewlib"
  This option is ignored; it is for compatibility purposes only.  This used to
  select linker and preprocessor options for use with newlib.
! .IP \fB\-msoft\-div\fR 4
  .IX Item "-msoft-div"
  .PD 0
! .IP \fB\-mhard\-div\fR 4
  .IX Item "-mhard-div"
  .PD
  Select software or hardware divide (\f(CW\*(C`l.div\*(C'\fR, \f(CW\*(C`l.divu\*(C'\fR) instructions.
  This default is hardware divide.
! .IP \fB\-msoft\-mul\fR 4
  .IX Item "-msoft-mul"
  .PD 0
! .IP \fB\-mhard\-mul\fR 4
  .IX Item "-mhard-mul"
  .PD
  Select software or hardware multiply (\f(CW\*(C`l.mul\*(C'\fR, \f(CW\*(C`l.muli\*(C'\fR) instructions.
  This default is hardware multiply.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
  Select software or hardware for floating point operations.
  The default is software.
! .IP \fB\-mdouble\-float\fR 4
  .IX Item "-mdouble-float"
! When \fB\-mhard\-float\fR is selected, enables generation of double\-precision
  floating point instructions.  By default functions from \fIlibgcc\fR are used
! to perform double\-precision floating point operations.
! .IP \fB\-munordered\-float\fR 4
  .IX Item "-munordered-float"
  When \fB\-mhard\-float\fR is selected, enables generation of unordered
  floating point compare and set flag (\f(CW\*(C`lf.sfun*\*(C'\fR) instructions.  By default
  functions from \fIlibgcc\fR are used to perform unordered floating point
  compare and set flag operations.
! .IP \fB\-mcmov\fR 4
  .IX Item "-mcmov"
  Enable generation of conditional move (\f(CW\*(C`l.cmov\*(C'\fR) instructions.  By
  default the equivalent will be generated using set and branch.
! .IP \fB\-mror\fR 4
  .IX Item "-mror"
  Enable generation of rotate right (\f(CW\*(C`l.ror\*(C'\fR) instructions.  By default
  functions from \fIlibgcc\fR are used to perform rotate right operations.
! .IP \fB\-mrori\fR 4
  .IX Item "-mrori"
  Enable generation of rotate right with immediate (\f(CW\*(C`l.rori\*(C'\fR) instructions.
  By default functions from \fIlibgcc\fR are used to perform rotate right with
  immediate operations.
! .IP \fB\-msext\fR 4
  .IX Item "-msext"
  Enable generation of sign extension (\f(CW\*(C`l.ext*\*(C'\fR) instructions.  By default
  memory loads are used to perform sign extension.
! .IP \fB\-msfimm\fR 4
  .IX Item "-msfimm"
  Enable generation of compare and set flag with immediate (\f(CW\*(C`l.sf*i\*(C'\fR)
  instructions.  By default extra instructions will be generated to store the
  immediate to a register first.
! .IP \fB\-mshftimm\fR 4
  .IX Item "-mshftimm"
  Enable generation of shift with immediate (\f(CW\*(C`l.srai\*(C'\fR, \f(CW\*(C`l.srli\*(C'\fR,
  \&\f(CW\*(C`l.slli\*(C'\fR) instructions.  By default extra instructions will be generated
  to store the immediate to a register first.
! .IP \fB\-mcmodel=small\fR 4
  .IX Item "-mcmodel=small"
! Generate OpenRISC code for the small model: The GOT is limited to 64k. This is
  the default model.
! .IP \fB\-mcmodel=large\fR 4
  .IX Item "-mcmodel=large"
! Generate OpenRISC code for the large model: The GOT may grow up to 4G in size.
  .PP
! \fIPDP\-11 Options\fR
  .IX Subsection "PDP-11 Options"
  .PP
! These options are defined for the PDP\-11:
! .IP \fB\-mfpu\fR 4
  .IX Item "-mfpu"
! Use hardware FPP floating point.  This is the default.  (FIS floating
! point on the PDP\-11/40 is not supported.)  Implies \-m45.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  Do not use hardware floating point.
! .IP \fB\-mac0\fR 4
  .IX Item "-mac0"
! Return floating\-point results in ac0 (fr0 in Unix assembler syntax).
! .IP \fB\-mno\-ac0\fR 4
  .IX Item "-mno-ac0"
! Return floating\-point results in memory.  This is the default.
! .IP \fB\-m40\fR 4
  .IX Item "-m40"
! Generate code for a PDP\-11/40.  Implies \-msoft\-float \-mno\-split.
! .IP \fB\-m45\fR 4
  .IX Item "-m45"
! Generate code for a PDP\-11/45.  This is the default.
! .IP \fB\-m10\fR 4
  .IX Item "-m10"
! Generate code for a PDP\-11/10.  Implies \-msoft\-float \-mno\-split.
! .IP \fB\-mint16\fR 4
  .IX Item "-mint16"
  .PD 0
! .IP \fB\-mno\-int32\fR 4
  .IX Item "-mno-int32"
  .PD
  Use 16\-bit \f(CW\*(C`int\*(C'\fR.  This is the default.
! .IP \fB\-mint32\fR 4
  .IX Item "-mint32"
  .PD 0
! .IP \fB\-mno\-int16\fR 4
  .IX Item "-mno-int16"
  .PD
  Use 32\-bit \f(CW\*(C`int\*(C'\fR.
! .IP \fB\-msplit\fR 4
  .IX Item "-msplit"
  Target has split instruction and data space.  Implies \-m45.
! .IP \fB\-munix\-asm\fR 4
  .IX Item "-munix-asm"
  Use Unix assembler syntax.
! .IP \fB\-mdec\-asm\fR 4
  .IX Item "-mdec-asm"
! Use DEC assembler syntax.
! .IP \fB\-mgnu\-asm\fR 4
  .IX Item "-mgnu-asm"
! Use GNU assembler syntax.  This is the default.
! .IP \fB\-mlra\fR 4
  .IX Item "-mlra"
! Use the new LRA register allocator.  By default, the old "reload"
  allocator is used.
  .PP
  \fIPowerPC Options\fR
*************** allocator is used.
*** 28047,28090 ****
  .PP
  These are listed under
  .PP
! \fI\s-1PRU\s0 Options\fR
  .IX Subsection "PRU Options"
  .PP
! These command-line options are defined for \s-1PRU\s0 target:
! .IP "\fB\-minrt\fR" 4
  .IX Item "-minrt"
  Link with a minimum runtime environment, with no support for static
  initializers and constructors.  Using this option can significantly reduce
! the size of the final \s-1ELF\s0 binary.  Beware that the compiler could still
  generate code with static initializers and constructors.  It is up to the
  programmer to ensure that the source program will not use those features.
! .IP "\fB\-mmcu=\fR\fImcu\fR" 4
  .IX Item "-mmcu=mcu"
! Specify the \s-1PRU MCU\s0 variant to use.  Check Newlib for the exact list of
  supported MCUs.
! .IP "\fB\-mno\-relax\fR" 4
  .IX Item "-mno-relax"
! Make \s-1GCC\s0 pass the \fB\-\-no\-relax\fR command-line option to the linker
  instead of the \fB\-\-relax\fR option.
! .IP "\fB\-mloop\fR" 4
  .IX Item "-mloop"
! Allow (or do not allow) \s-1GCC\s0 to use the \s-1LOOP\s0 instruction.
! .IP "\fB\-mabi=\fR\fIvariant\fR" 4
  .IX Item "-mabi=variant"
! Specify the \s-1ABI\s0 variant to output code for.  \fB\-mabi=ti\fR selects the
! unmodified \s-1TI ABI\s0 while \fB\-mabi=gnu\fR selects a \s-1GNU\s0 variant that copes
! more naturally with certain \s-1GCC\s0 assumptions.  These are the differences:
  .RS 4
  .IP "\fBFunction Pointer Size\fR" 4
  .IX Item "Function Pointer Size"
! \&\s-1TI ABI\s0 specifies that function (code) pointers are 16\-bit, whereas \s-1GNU\s0
  supports only 32\-bit data and code pointers.
  .IP "\fBOptional Return Value Pointer\fR" 4
  .IX Item "Optional Return Value Pointer"
  Function return values larger than 64 bits are passed by using a hidden
! pointer as the first argument of the function.  \s-1TI ABI,\s0 though, mandates that
! the pointer can be \s-1NULL\s0 in case the caller is not using the returned value.
! \&\s-1GNU\s0 always passes and expects a valid return value pointer.
  .RE
  .RS 4
  .Sp
--- 27978,28021 ----
  .PP
  These are listed under
  .PP
! \fIPRU Options\fR
  .IX Subsection "PRU Options"
  .PP
! These command\-line options are defined for PRU target:
! .IP \fB\-minrt\fR 4
  .IX Item "-minrt"
  Link with a minimum runtime environment, with no support for static
  initializers and constructors.  Using this option can significantly reduce
! the size of the final ELF binary.  Beware that the compiler could still
  generate code with static initializers and constructors.  It is up to the
  programmer to ensure that the source program will not use those features.
! .IP \fB\-mmcu=\fR\fImcu\fR 4
  .IX Item "-mmcu=mcu"
! Specify the PRU MCU variant to use.  Check Newlib for the exact list of
  supported MCUs.
! .IP \fB\-mno\-relax\fR 4
  .IX Item "-mno-relax"
! Make GCC pass the \fB\-\-no\-relax\fR command\-line option to the linker
  instead of the \fB\-\-relax\fR option.
! .IP \fB\-mloop\fR 4
  .IX Item "-mloop"
! Allow (or do not allow) GCC to use the LOOP instruction.
! .IP \fB\-mabi=\fR\fIvariant\fR 4
  .IX Item "-mabi=variant"
! Specify the ABI variant to output code for.  \fB\-mabi=ti\fR selects the
! unmodified TI ABI while \fB\-mabi=gnu\fR selects a GNU variant that copes
! more naturally with certain GCC assumptions.  These are the differences:
  .RS 4
  .IP "\fBFunction Pointer Size\fR" 4
  .IX Item "Function Pointer Size"
! TI ABI specifies that function (code) pointers are 16\-bit, whereas GNU
  supports only 32\-bit data and code pointers.
  .IP "\fBOptional Return Value Pointer\fR" 4
  .IX Item "Optional Return Value Pointer"
  Function return values larger than 64 bits are passed by using a hidden
! pointer as the first argument of the function.  TI ABI, though, mandates that
! the pointer can be NULL in case the caller is not using the returned value.
! GNU always passes and expects a valid return value pointer.
  .RE
  .RS 4
  .Sp
*************** when any of the above code constructs is
*** 28093,28130 ****
  the standard C library cannot be built and it is omitted when linking with
  \&\fB\-mabi=ti\fR.
  .Sp
! Relaxation is a \s-1GNU\s0 feature and for safety reasons is disabled when using
! \&\fB\-mabi=ti\fR.  The \s-1TI\s0 toolchain does not emit relocations for QBBx
! instructions, so the \s-1GNU\s0 linker cannot adjust them when shortening adjacent
! \&\s-1LDI32\s0 pseudo instructions.
  .RE
  .PP
! \fIRISC-V Options\fR
  .IX Subsection "RISC-V Options"
  .PP
! These command-line options are defined for RISC-V targets:
! .IP "\fB\-mbranch\-cost=\fR\fIn\fR" 4
  .IX Item "-mbranch-cost=n"
  Set the cost of branches to roughly \fIn\fR instructions.
! .IP "\fB\-mplt\fR" 4
  .IX Item "-mplt"
  .PD 0
! .IP "\fB\-mno\-plt\fR" 4
  .IX Item "-mno-plt"
  .PD
! When generating \s-1PIC\s0 code, do or don't allow the use of PLTs. Ignored for
! non-PIC.  The default is \fB\-mplt\fR.
! .IP "\fB\-mabi=\fR\fIABI-string\fR" 4
  .IX Item "-mabi=ABI-string"
! Specify integer and floating-point calling convention.  \fIABI-string\fR
  contains two parts: the size of integer types and the registers used for
! floating-point types.  For example \fB\-march=rv64ifd \-mabi=lp64d\fR means that
  \&\fBlong\fR and pointers are 64\-bit (implicitly defining \fBint\fR to be
! 32\-bit), and that floating-point values up to 64 bits wide are passed in F
  registers.  Contrast this with \fB\-march=rv64ifd \-mabi=lp64f\fR, which still
  allows the compiler to generate code that uses the F and D extensions but only
! allows floating-point values up to 32 bits long to be passed in registers; or
! \&\fB\-march=rv64ifd \-mabi=lp64\fR, in which no floating-point arguments will be
  passed in registers.
  .Sp
  The default for this argument is system dependent, users who want a specific
--- 28024,28061 ----
  the standard C library cannot be built and it is omitted when linking with
  \&\fB\-mabi=ti\fR.
  .Sp
! Relaxation is a GNU feature and for safety reasons is disabled when using
! \&\fB\-mabi=ti\fR.  The TI toolchain does not emit relocations for QBBx
! instructions, so the GNU linker cannot adjust them when shortening adjacent
! LDI32 pseudo instructions.
  .RE
  .PP
! \fIRISC\-V Options\fR
  .IX Subsection "RISC-V Options"
  .PP
! These command\-line options are defined for RISC\-V targets:
! .IP \fB\-mbranch\-cost=\fR\fIn\fR 4
  .IX Item "-mbranch-cost=n"
  Set the cost of branches to roughly \fIn\fR instructions.
! .IP \fB\-mplt\fR 4
  .IX Item "-mplt"
  .PD 0
! .IP \fB\-mno\-plt\fR 4
  .IX Item "-mno-plt"
  .PD
! When generating PIC code, do or don\*(Aqt allow the use of PLTs. Ignored for
! non\-PIC.  The default is \fB\-mplt\fR.
! .IP \fB\-mabi=\fR\fIABI\-string\fR 4
  .IX Item "-mabi=ABI-string"
! Specify integer and floating\-point calling convention.  \fIABI\-string\fR
  contains two parts: the size of integer types and the registers used for
! floating\-point types.  For example \fB\-march=rv64ifd \-mabi=lp64d\fR means that
  \&\fBlong\fR and pointers are 64\-bit (implicitly defining \fBint\fR to be
! 32\-bit), and that floating\-point values up to 64 bits wide are passed in F
  registers.  Contrast this with \fB\-march=rv64ifd \-mabi=lp64f\fR, which still
  allows the compiler to generate code that uses the F and D extensions but only
! allows floating\-point values up to 32 bits long to be passed in registers; or
! \&\fB\-march=rv64ifd \-mabi=lp64\fR, in which no floating\-point arguments will be
  passed in registers.
  .Sp
  The default for this argument is system dependent, users who want a specific
*************** calling convention should specify one ex
*** 28132,28187 ****
  conventions are: \fBilp32\fR, \fBilp32f\fR, \fBilp32d\fR, \fBlp64\fR,
  \&\fBlp64f\fR, and \fBlp64d\fR.  Some calling conventions are impossible to
  implement on some ISAs: for example, \fB\-march=rv32if \-mabi=ilp32d\fR is
! invalid because the \s-1ABI\s0 requires 64\-bit values be passed in F registers, but F
! registers are only 32 bits wide.  There is also the \fBilp32e\fR \s-1ABI\s0 that can
! only be used with the \fBrv32e\fR architecture.  This \s-1ABI\s0 is not well
  specified at present, and is subject to change.
! .IP "\fB\-mfdiv\fR" 4
  .IX Item "-mfdiv"
  .PD 0
! .IP "\fB\-mno\-fdiv\fR" 4
  .IX Item "-mno-fdiv"
  .PD
! Do or don't use hardware floating-point divide and square root instructions.
! This requires the F or D extensions for floating-point registers.  The default
  is to use them if the specified architecture has these instructions.
! .IP "\fB\-mdiv\fR" 4
  .IX Item "-mdiv"
  .PD 0
! .IP "\fB\-mno\-div\fR" 4
  .IX Item "-mno-div"
  .PD
! Do or don't use hardware instructions for integer division.  This requires the
  M extension.  The default is to use them if the specified architecture has
  these instructions.
! .IP "\fB\-misa\-spec=\fR\fIISA-spec-string\fR" 4
  .IX Item "-misa-spec=ISA-spec-string"
! Specify the version of the RISC-V Unprivileged (formerly User-Level)
! \&\s-1ISA\s0 specification to produce code conforming to.  The possibilities
! for \fIISA-spec-string\fR are:
  .RS 4
! .ie n .IP "2.2" 4
! .el .IP "\f(CW2.2\fR" 4
  .IX Item "2.2"
  Produce code conforming to version 2.2.
! .ie n .IP "20190608" 4
! .el .IP "\f(CW20190608\fR" 4
  .IX Item "20190608"
  Produce code conforming to version 20190608.
! .ie n .IP "20191213" 4
! .el .IP "\f(CW20191213\fR" 4
  .IX Item "20191213"
  Produce code conforming to version 20191213.
  .RE
  .RS 4
  .Sp
! The default is \fB\-misa\-spec=20191213\fR unless \s-1GCC\s0 has been configured
  with \fB\-\-with\-isa\-spec=\fR specifying a different default version.
  .RE
! .IP "\fB\-march=\fR\fIISA-string\fR" 4
  .IX Item "-march=ISA-string"
! Generate code for given RISC-V \s-1ISA\s0 (e.g. \fBrv64im\fR).  \s-1ISA\s0 strings must be
! lower-case.  Examples include \fBrv64i\fR, \fBrv32g\fR, \fBrv32e\fR, and
  \&\fBrv32imaf\fR.
  .Sp
  When \fB\-march=\fR is not specified, use the setting from \fB\-mcpu\fR.
--- 28063,28118 ----
  conventions are: \fBilp32\fR, \fBilp32f\fR, \fBilp32d\fR, \fBlp64\fR,
  \&\fBlp64f\fR, and \fBlp64d\fR.  Some calling conventions are impossible to
  implement on some ISAs: for example, \fB\-march=rv32if \-mabi=ilp32d\fR is
! invalid because the ABI requires 64\-bit values be passed in F registers, but F
! registers are only 32 bits wide.  There is also the \fBilp32e\fR ABI that can
! only be used with the \fBrv32e\fR architecture.  This ABI is not well
  specified at present, and is subject to change.
! .IP \fB\-mfdiv\fR 4
  .IX Item "-mfdiv"
  .PD 0
! .IP \fB\-mno\-fdiv\fR 4
  .IX Item "-mno-fdiv"
  .PD
! Do or don\*(Aqt use hardware floating\-point divide and square root instructions.
! This requires the F or D extensions for floating\-point registers.  The default
  is to use them if the specified architecture has these instructions.
! .IP \fB\-mdiv\fR 4
  .IX Item "-mdiv"
  .PD 0
! .IP \fB\-mno\-div\fR 4
  .IX Item "-mno-div"
  .PD
! Do or don\*(Aqt use hardware instructions for integer division.  This requires the
  M extension.  The default is to use them if the specified architecture has
  these instructions.
! .IP \fB\-misa\-spec=\fR\fIISA\-spec\-string\fR 4
  .IX Item "-misa-spec=ISA-spec-string"
! Specify the version of the RISC\-V Unprivileged (formerly User\-Level)
! ISA specification to produce code conforming to.  The possibilities
! for \fIISA\-spec\-string\fR are:
  .RS 4
! .ie n .IP 2.2 4
! .el .IP \f(CW2.2\fR 4
  .IX Item "2.2"
  Produce code conforming to version 2.2.
! .ie n .IP 20190608 4
! .el .IP \f(CW20190608\fR 4
  .IX Item "20190608"
  Produce code conforming to version 20190608.
! .ie n .IP 20191213 4
! .el .IP \f(CW20191213\fR 4
  .IX Item "20191213"
  Produce code conforming to version 20191213.
  .RE
  .RS 4
  .Sp
! The default is \fB\-misa\-spec=20191213\fR unless GCC has been configured
  with \fB\-\-with\-isa\-spec=\fR specifying a different default version.
  .RE
! .IP \fB\-march=\fR\fIISA\-string\fR 4
  .IX Item "-march=ISA-string"
! Generate code for given RISC\-V ISA (e.g. \fBrv64im\fR).  ISA strings must be
! lower\-case.  Examples include \fBrv64i\fR, \fBrv32g\fR, \fBrv32e\fR, and
  \&\fBrv32imaf\fR.
  .Sp
  When \fB\-march=\fR is not specified, use the setting from \fB\-mcpu\fR.
*************** When \fB\-march=\fR is not specified, us
*** 28189,28217 ****
  If both \fB\-march\fR and \fB\-mcpu=\fR are not specified, the default for
  this argument is system dependent, users who want a specific architecture
  extensions should specify one explicitly.
! .IP "\fB\-mcpu=\fR\fIprocessor-string\fR" 4
  .IX Item "-mcpu=processor-string"
  Use architecture of and optimize the output for the given processor, specified
! by particular \s-1CPU\s0 name.
  Permissible values for this option are: \fBsifive\-e20\fR, \fBsifive\-e21\fR,
  \&\fBsifive\-e24\fR, \fBsifive\-e31\fR, \fBsifive\-e34\fR, \fBsifive\-e76\fR,
  \&\fBsifive\-s21\fR, \fBsifive\-s51\fR, \fBsifive\-s54\fR, \fBsifive\-s76\fR,
  \&\fBsifive\-u54\fR, and \fBsifive\-u74\fR.
! .IP "\fB\-mtune=\fR\fIprocessor-string\fR" 4
  .IX Item "-mtune=processor-string"
  Optimize the output for the given processor, specified by microarchitecture or
! particular \s-1CPU\s0 name.  Permissible values for this option are: \fBrocket\fR,
  \&\fBsifive\-3\-series\fR, \fBsifive\-5\-series\fR, \fBsifive\-7\-series\fR,
  \&\fBthead\-c906\fR, \fBsize\fR, and all valid options for \fB\-mcpu=\fR.
  .Sp
  When \fB\-mtune=\fR is not specified, use the setting from \fB\-mcpu\fR,
  the default is \fBrocket\fR if both are not specified.
  .Sp
! The \fBsize\fR choice is not intended for use by end-users.  This is used
  when \fB\-Os\fR is specified.  It overrides the instruction cost info
  provided by \fB\-mtune=\fR, but does not override the pipeline info.  This
  helps reduce code size while still giving good performance.
! .IP "\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR" 4
  .IX Item "-mpreferred-stack-boundary=num"
  Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
  byte boundary.  If \fB\-mpreferred\-stack\-boundary\fR is not specified,
--- 28120,28148 ----
  If both \fB\-march\fR and \fB\-mcpu=\fR are not specified, the default for
  this argument is system dependent, users who want a specific architecture
  extensions should specify one explicitly.
! .IP \fB\-mcpu=\fR\fIprocessor\-string\fR 4
  .IX Item "-mcpu=processor-string"
  Use architecture of and optimize the output for the given processor, specified
! by particular CPU name.
  Permissible values for this option are: \fBsifive\-e20\fR, \fBsifive\-e21\fR,
  \&\fBsifive\-e24\fR, \fBsifive\-e31\fR, \fBsifive\-e34\fR, \fBsifive\-e76\fR,
  \&\fBsifive\-s21\fR, \fBsifive\-s51\fR, \fBsifive\-s54\fR, \fBsifive\-s76\fR,
  \&\fBsifive\-u54\fR, and \fBsifive\-u74\fR.
! .IP \fB\-mtune=\fR\fIprocessor\-string\fR 4
  .IX Item "-mtune=processor-string"
  Optimize the output for the given processor, specified by microarchitecture or
! particular CPU name.  Permissible values for this option are: \fBrocket\fR,
  \&\fBsifive\-3\-series\fR, \fBsifive\-5\-series\fR, \fBsifive\-7\-series\fR,
  \&\fBthead\-c906\fR, \fBsize\fR, and all valid options for \fB\-mcpu=\fR.
  .Sp
  When \fB\-mtune=\fR is not specified, use the setting from \fB\-mcpu\fR,
  the default is \fBrocket\fR if both are not specified.
  .Sp
! The \fBsize\fR choice is not intended for use by end\-users.  This is used
  when \fB\-Os\fR is specified.  It overrides the instruction cost info
  provided by \fB\-mtune=\fR, but does not override the pipeline info.  This
  helps reduce code size while still giving good performance.
! .IP \fB\-mpreferred\-stack\-boundary=\fR\fInum\fR 4
  .IX Item "-mpreferred-stack-boundary=num"
  Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
  byte boundary.  If \fB\-mpreferred\-stack\-boundary\fR is not specified,
*************** the default is 4 (16 bytes or 128\-bits)
*** 28220,28341 ****
  \&\fBWarning:\fR If you use this switch, then you must build all modules with
  the same value, including any libraries.  This includes the system libraries
  and startup modules.
! .IP "\fB\-msmall\-data\-limit=\fR\fIn\fR" 4
  .IX Item "-msmall-data-limit=n"
  Put global and static data smaller than \fIn\fR bytes into a special section
  (on some targets).
! .IP "\fB\-msave\-restore\fR" 4
  .IX Item "-msave-restore"
  .PD 0
! .IP "\fB\-mno\-save\-restore\fR" 4
  .IX Item "-mno-save-restore"
  .PD
! Do or don't use smaller but slower prologue and epilogue code that uses
  library function calls.  The default is to use fast inline prologues and
  epilogues.
! .IP "\fB\-minline\-atomics\fR" 4
  .IX Item "-minline-atomics"
  .PD 0
! .IP "\fB\-mno\-inline\-atomics\fR" 4
  .IX Item "-mno-inline-atomics"
  .PD
! Do or don't use smaller but slower subword atomic emulation code that uses
  libatomic function calls.  The default is to use fast inline subword atomics
  that do not require libatomic.
! .IP "\fB\-mshorten\-memrefs\fR" 4
  .IX Item "-mshorten-memrefs"
  .PD 0
! .IP "\fB\-mno\-shorten\-memrefs\fR" 4
  .IX Item "-mno-shorten-memrefs"
  .PD
  Do or do not attempt to make more use of compressed load/store instructions by
! replacing a load/store of 'base register + large offset' with a new load/store
! of 'new base + small offset'.  If the new base gets stored in a compressed
  register, then the new load/store can be compressed.  Currently targets 32\-bit
  integer load/stores only.
! .IP "\fB\-mstrict\-align\fR" 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP "\fB\-mno\-strict\-align\fR" 4
  .IX Item "-mno-strict-align"
  .PD
  Do not or do generate unaligned memory accesses.  The default is set depending
  on whether the processor we are optimizing for supports fast unaligned access
  or not.
! .IP "\fB\-mcmodel=medlow\fR" 4
  .IX Item "-mcmodel=medlow"
! Generate code for the medium-low code model. The program and its statically
  defined symbols must lie within a single 2 GiB address range and must lie
  between absolute addresses \-2 GiB and +2 GiB. Programs can be
  statically or dynamically linked. This is the default code model.
! .IP "\fB\-mcmodel=medany\fR" 4
  .IX Item "-mcmodel=medany"
! Generate code for the medium-any code model. The program and its statically
  defined symbols must be within any single 2 GiB address range. Programs can be
  statically or dynamically linked.
  .Sp
! The code generated by the medium-any code model is position-independent, but is
! not guaranteed to function correctly when linked into position-independent
  executables or libraries.
! .IP "\fB\-mexplicit\-relocs\fR" 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP "\fB\-mno\-exlicit\-relocs\fR" 4
  .IX Item "-mno-exlicit-relocs"
  .PD
  Use or do not use assembler relocation operators when dealing with symbolic
  addresses.  The alternative is to use assembler macros instead, which may
  limit optimization.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  .PD 0
! .IP "\fB\-mno\-relax\fR" 4
  .IX Item "-mno-relax"
  .PD
  Take advantage of linker relaxations to reduce the number of instructions
  required to materialize symbol addresses. The default is to take advantage of
  linker relaxations.
! .IP "\fB\-mriscv\-attribute\fR" 4
  .IX Item "-mriscv-attribute"
  .PD 0
! .IP "\fB\-mno\-riscv\-attribute\fR" 4
  .IX Item "-mno-riscv-attribute"
  .PD
! Emit (do not emit) RISC-V attribute to record extra information into \s-1ELF\s0
  objects.  This feature requires at least binutils 2.32.
! .IP "\fB\-mcsr\-check\fR" 4
  .IX Item "-mcsr-check"
  .PD 0
! .IP "\fB\-mno\-csr\-check\fR" 4
  .IX Item "-mno-csr-check"
  .PD
! Enables or disables the \s-1CSR\s0 checking.
! .IP "\fB\-malign\-data=\fR\fItype\fR" 4
  .IX Item "-malign-data=type"
! Control how \s-1GCC\s0 aligns variables and constants of array, structure, or union
  types.  Supported values for \fItype\fR are \fBxlen\fR which uses x register
  width as the alignment value, and \fBnatural\fR which uses natural alignment.
  \&\fBxlen\fR is the default.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate big-endian code.  This is the default when \s-1GCC\s0 is configured for a
  \&\fBriscv64be\-*\-*\fR or \fBriscv32be\-*\-*\fR target.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate little-endian code.  This is the default when \s-1GCC\s0 is configured for a
  \&\fBriscv64\-*\-*\fR or \fBriscv32\-*\-*\fR but not a \fBriscv64be\-*\-*\fR or
  \&\fBriscv32be\-*\-*\fR target.
! .IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP "\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR" 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP "\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR" 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for a global canary or \fBtls\fR for per-thread
! canary in the \s-1TLS\s0 block.
  .Sp
  With the latter choice the options
  \&\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR and
--- 28151,28272 ----
  \&\fBWarning:\fR If you use this switch, then you must build all modules with
  the same value, including any libraries.  This includes the system libraries
  and startup modules.
! .IP \fB\-msmall\-data\-limit=\fR\fIn\fR 4
  .IX Item "-msmall-data-limit=n"
  Put global and static data smaller than \fIn\fR bytes into a special section
  (on some targets).
! .IP \fB\-msave\-restore\fR 4
  .IX Item "-msave-restore"
  .PD 0
! .IP \fB\-mno\-save\-restore\fR 4
  .IX Item "-mno-save-restore"
  .PD
! Do or don\*(Aqt use smaller but slower prologue and epilogue code that uses
  library function calls.  The default is to use fast inline prologues and
  epilogues.
! .IP \fB\-minline\-atomics\fR 4
  .IX Item "-minline-atomics"
  .PD 0
! .IP \fB\-mno\-inline\-atomics\fR 4
  .IX Item "-mno-inline-atomics"
  .PD
! Do or don\*(Aqt use smaller but slower subword atomic emulation code that uses
  libatomic function calls.  The default is to use fast inline subword atomics
  that do not require libatomic.
! .IP \fB\-mshorten\-memrefs\fR 4
  .IX Item "-mshorten-memrefs"
  .PD 0
! .IP \fB\-mno\-shorten\-memrefs\fR 4
  .IX Item "-mno-shorten-memrefs"
  .PD
  Do or do not attempt to make more use of compressed load/store instructions by
! replacing a load/store of \*(Aqbase register + large offset\*(Aq with a new load/store
! of \*(Aqnew base + small offset\*(Aq.  If the new base gets stored in a compressed
  register, then the new load/store can be compressed.  Currently targets 32\-bit
  integer load/stores only.
! .IP \fB\-mstrict\-align\fR 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP \fB\-mno\-strict\-align\fR 4
  .IX Item "-mno-strict-align"
  .PD
  Do not or do generate unaligned memory accesses.  The default is set depending
  on whether the processor we are optimizing for supports fast unaligned access
  or not.
! .IP \fB\-mcmodel=medlow\fR 4
  .IX Item "-mcmodel=medlow"
! Generate code for the medium\-low code model. The program and its statically
  defined symbols must lie within a single 2 GiB address range and must lie
  between absolute addresses \-2 GiB and +2 GiB. Programs can be
  statically or dynamically linked. This is the default code model.
! .IP \fB\-mcmodel=medany\fR 4
  .IX Item "-mcmodel=medany"
! Generate code for the medium\-any code model. The program and its statically
  defined symbols must be within any single 2 GiB address range. Programs can be
  statically or dynamically linked.
  .Sp
! The code generated by the medium\-any code model is position\-independent, but is
! not guaranteed to function correctly when linked into position\-independent
  executables or libraries.
! .IP \fB\-mexplicit\-relocs\fR 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP \fB\-mno\-exlicit\-relocs\fR 4
  .IX Item "-mno-exlicit-relocs"
  .PD
  Use or do not use assembler relocation operators when dealing with symbolic
  addresses.  The alternative is to use assembler macros instead, which may
  limit optimization.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  .PD 0
! .IP \fB\-mno\-relax\fR 4
  .IX Item "-mno-relax"
  .PD
  Take advantage of linker relaxations to reduce the number of instructions
  required to materialize symbol addresses. The default is to take advantage of
  linker relaxations.
! .IP \fB\-mriscv\-attribute\fR 4
  .IX Item "-mriscv-attribute"
  .PD 0
! .IP \fB\-mno\-riscv\-attribute\fR 4
  .IX Item "-mno-riscv-attribute"
  .PD
! Emit (do not emit) RISC\-V attribute to record extra information into ELF
  objects.  This feature requires at least binutils 2.32.
! .IP \fB\-mcsr\-check\fR 4
  .IX Item "-mcsr-check"
  .PD 0
! .IP \fB\-mno\-csr\-check\fR 4
  .IX Item "-mno-csr-check"
  .PD
! Enables or disables the CSR checking.
! .IP \fB\-malign\-data=\fR\fItype\fR 4
  .IX Item "-malign-data=type"
! Control how GCC aligns variables and constants of array, structure, or union
  types.  Supported values for \fItype\fR are \fBxlen\fR which uses x register
  width as the alignment value, and \fBnatural\fR which uses natural alignment.
  \&\fBxlen\fR is the default.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate big\-endian code.  This is the default when GCC is configured for a
  \&\fBriscv64be\-*\-*\fR or \fBriscv32be\-*\-*\fR target.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate little\-endian code.  This is the default when GCC is configured for a
  \&\fBriscv64\-*\-*\fR or \fBriscv32\-*\-*\fR but not a \fBriscv64be\-*\-*\fR or
  \&\fBriscv32be\-*\-*\fR target.
! .IP \fB\-mstack\-protector\-guard=\fR\fIguard\fR 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP \fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for a global canary or \fBtls\fR for per\-thread
! canary in the TLS block.
  .Sp
  With the latter choice the options
  \&\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR and
*************** and from what offset from that base regi
*** 28345,28392 ****
  register or offset as this is entirely for use within the Linux
  kernel.
  .PP
! \fI\s-1RL78\s0 Options\fR
  .IX Subsection "RL78 Options"
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Links in additional target libraries to support operation within a
  simulator.
! .IP "\fB\-mmul=none\fR" 4
  .IX Item "-mmul=none"
  .PD 0
! .IP "\fB\-mmul=g10\fR" 4
  .IX Item "-mmul=g10"
! .IP "\fB\-mmul=g13\fR" 4
  .IX Item "-mmul=g13"
! .IP "\fB\-mmul=g14\fR" 4
  .IX Item "-mmul=g14"
! .IP "\fB\-mmul=rl78\fR" 4
  .IX Item "-mmul=rl78"
  .PD
  Specifies the type of hardware multiplication and division support to
  be used.  The simplest is \f(CW\*(C`none\*(C'\fR, which uses software for both
  multiplication and division.  This is the default.  The \f(CW\*(C`g13\*(C'\fR
  value is for the hardware multiply/divide peripheral found on the
! \&\s-1RL78/G13\s0 (S2 core) targets.  The \f(CW\*(C`g14\*(C'\fR value selects the use of
! the multiplication and division instructions supported by the \s-1RL78/G14\s0
  (S3 core) parts.  The value \f(CW\*(C`rl78\*(C'\fR is an alias for \f(CW\*(C`g14\*(C'\fR and
  the value \f(CW\*(C`mg10\*(C'\fR is an alias for \f(CW\*(C`none\*(C'\fR.
  .Sp
  In addition a C preprocessor macro is defined, based upon the setting
  of this option.  Possible values are: \f(CW\*(C`_\|_RL78_MUL_NONE_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_RL78_MUL_G13_\|_\*(C'\fR or \f(CW\*(C`_\|_RL78_MUL_G14_\|_\*(C'\fR.
! .IP "\fB\-mcpu=g10\fR" 4
  .IX Item "-mcpu=g10"
  .PD 0
! .IP "\fB\-mcpu=g13\fR" 4
  .IX Item "-mcpu=g13"
! .IP "\fB\-mcpu=g14\fR" 4
  .IX Item "-mcpu=g14"
! .IP "\fB\-mcpu=rl78\fR" 4
  .IX Item "-mcpu=rl78"
  .PD
! Specifies the \s-1RL78\s0 core to target.  The default is the G14 core, also
! known as an S3 core or just \s-1RL78.\s0  The G13 or S2 core does not have
  multiply or divide instructions, instead it uses a hardware peripheral
  for these operations.  The G10 or S1 core does not have register
  banks, so it uses a different calling convention.
--- 28276,28323 ----
  register or offset as this is entirely for use within the Linux
  kernel.
  .PP
! \fIRL78 Options\fR
  .IX Subsection "RL78 Options"
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Links in additional target libraries to support operation within a
  simulator.
! .IP \fB\-mmul=none\fR 4
  .IX Item "-mmul=none"
  .PD 0
! .IP \fB\-mmul=g10\fR 4
  .IX Item "-mmul=g10"
! .IP \fB\-mmul=g13\fR 4
  .IX Item "-mmul=g13"
! .IP \fB\-mmul=g14\fR 4
  .IX Item "-mmul=g14"
! .IP \fB\-mmul=rl78\fR 4
  .IX Item "-mmul=rl78"
  .PD
  Specifies the type of hardware multiplication and division support to
  be used.  The simplest is \f(CW\*(C`none\*(C'\fR, which uses software for both
  multiplication and division.  This is the default.  The \f(CW\*(C`g13\*(C'\fR
  value is for the hardware multiply/divide peripheral found on the
! RL78/G13 (S2 core) targets.  The \f(CW\*(C`g14\*(C'\fR value selects the use of
! the multiplication and division instructions supported by the RL78/G14
  (S3 core) parts.  The value \f(CW\*(C`rl78\*(C'\fR is an alias for \f(CW\*(C`g14\*(C'\fR and
  the value \f(CW\*(C`mg10\*(C'\fR is an alias for \f(CW\*(C`none\*(C'\fR.
  .Sp
  In addition a C preprocessor macro is defined, based upon the setting
  of this option.  Possible values are: \f(CW\*(C`_\|_RL78_MUL_NONE_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_RL78_MUL_G13_\|_\*(C'\fR or \f(CW\*(C`_\|_RL78_MUL_G14_\|_\*(C'\fR.
! .IP \fB\-mcpu=g10\fR 4
  .IX Item "-mcpu=g10"
  .PD 0
! .IP \fB\-mcpu=g13\fR 4
  .IX Item "-mcpu=g13"
! .IP \fB\-mcpu=g14\fR 4
  .IX Item "-mcpu=g14"
! .IP \fB\-mcpu=rl78\fR 4
  .IX Item "-mcpu=rl78"
  .PD
! Specifies the RL78 core to target.  The default is the G14 core, also
! known as an S3 core or just RL78.  The G13 or S2 core does not have
  multiply or divide instructions, instead it uses a hardware peripheral
  for these operations.  The G10 or S1 core does not have register
  banks, so it uses a different calling convention.
*************** support to use, unless this is overridde
*** 28398,28539 ****
  peripheral and specifying \fB\-mcpu=g10\fR disables the use of
  hardware multiplications altogether.
  .Sp
! Note, although the \s-1RL78/G14\s0 core is the default target, specifying
  \&\fB\-mcpu=g14\fR or \fB\-mcpu=rl78\fR on the command line does
  change the behavior of the toolchain since it also enables G14
  hardware multiply support.  If these options are not specified on the
  command line then software multiplication routines will be used even
! though the code targets the \s-1RL78\s0 core.  This is for backwards
  compatibility with older toolchains which did not have hardware
  multiply and divide support.
  .Sp
  In addition a C preprocessor macro is defined, based upon the setting
  of this option.  Possible values are: \f(CW\*(C`_\|_RL78_G10_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_RL78_G13_\|_\*(C'\fR or \f(CW\*(C`_\|_RL78_G14_\|_\*(C'\fR.
! .IP "\fB\-mg10\fR" 4
  .IX Item "-mg10"
  .PD 0
! .IP "\fB\-mg13\fR" 4
  .IX Item "-mg13"
! .IP "\fB\-mg14\fR" 4
  .IX Item "-mg14"
! .IP "\fB\-mrl78\fR" 4
  .IX Item "-mrl78"
  .PD
  These are aliases for the corresponding \fB\-mcpu=\fR option.  They
  are provided for backwards compatibility.
! .IP "\fB\-mallregs\fR" 4
  .IX Item "-mallregs"
  Allow the compiler to use all of the available registers.  By default
  registers \f(CW\*(C`r24..r31\*(C'\fR are reserved for use in interrupt handlers.
  With this option enabled these registers can be used in ordinary
  functions as well.
! .IP "\fB\-m64bit\-doubles\fR" 4
  .IX Item "-m64bit-doubles"
  .PD 0
! .IP "\fB\-m32bit\-doubles\fR" 4
  .IX Item "-m32bit-doubles"
  .PD
  Make the \f(CW\*(C`double\*(C'\fR data type be 64 bits (\fB\-m64bit\-doubles\fR)
  or 32 bits (\fB\-m32bit\-doubles\fR) in size.  The default is
  \&\fB\-m32bit\-doubles\fR.
! .IP "\fB\-msave\-mduc\-in\-interrupts\fR" 4
  .IX Item "-msave-mduc-in-interrupts"
  .PD 0
! .IP "\fB\-mno\-save\-mduc\-in\-interrupts\fR" 4
  .IX Item "-mno-save-mduc-in-interrupts"
  .PD
  Specifies that interrupt handler functions should preserve the
! \&\s-1MDUC\s0 registers.  This is only necessary if normal code might use
! the \s-1MDUC\s0 registers, for example because it performs multiplication
! and division operations.  The default is to ignore the \s-1MDUC\s0 registers
  as this makes the interrupt handlers faster.  The target option \-mg13
  needs to be passed for this to work as this feature is only available
! on the G13 target (S2 core).  The \s-1MDUC\s0 registers will only be saved
  if the interrupt handler performs a multiplication or division
  operation or it calls another function.
  .PP
! \fI\s-1IBM RS/6000\s0 and PowerPC Options\fR
  .IX Subsection "IBM RS/6000 and PowerPC Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1IBM RS/6000\s0 and PowerPC:
! .IP "\fB\-mpowerpc\-gpopt\fR" 4
  .IX Item "-mpowerpc-gpopt"
  .PD 0
! .IP "\fB\-mno\-powerpc\-gpopt\fR" 4
  .IX Item "-mno-powerpc-gpopt"
! .IP "\fB\-mpowerpc\-gfxopt\fR" 4
  .IX Item "-mpowerpc-gfxopt"
! .IP "\fB\-mno\-powerpc\-gfxopt\fR" 4
  .IX Item "-mno-powerpc-gfxopt"
! .IP "\fB\-mpowerpc64\fR" 4
  .IX Item "-mpowerpc64"
! .IP "\fB\-mno\-powerpc64\fR" 4
  .IX Item "-mno-powerpc64"
! .IP "\fB\-mmfcrf\fR" 4
  .IX Item "-mmfcrf"
! .IP "\fB\-mno\-mfcrf\fR" 4
  .IX Item "-mno-mfcrf"
! .IP "\fB\-mpopcntb\fR" 4
  .IX Item "-mpopcntb"
! .IP "\fB\-mno\-popcntb\fR" 4
  .IX Item "-mno-popcntb"
! .IP "\fB\-mpopcntd\fR" 4
  .IX Item "-mpopcntd"
! .IP "\fB\-mno\-popcntd\fR" 4
  .IX Item "-mno-popcntd"
! .IP "\fB\-mfprnd\fR" 4
  .IX Item "-mfprnd"
! .IP "\fB\-mno\-fprnd\fR" 4
  .IX Item "-mno-fprnd"
! .IP "\fB\-mcmpb\fR" 4
  .IX Item "-mcmpb"
! .IP "\fB\-mno\-cmpb\fR" 4
  .IX Item "-mno-cmpb"
! .IP "\fB\-mhard\-dfp\fR" 4
  .IX Item "-mhard-dfp"
! .IP "\fB\-mno\-hard\-dfp\fR" 4
  .IX Item "-mno-hard-dfp"
  .PD
  You use these options to specify which instructions are available on the
  processor you are using.  The default value of these options is
! determined when configuring \s-1GCC.\s0  Specifying the
  \&\fB\-mcpu=\fR\fIcpu_type\fR overrides the specification of these
  options.  We recommend you use the \fB\-mcpu=\fR\fIcpu_type\fR option
  rather than the options listed above.
  .Sp
  Specifying \fB\-mpowerpc\-gpopt\fR allows
! \&\s-1GCC\s0 to use the optional PowerPC architecture instructions in the
! General Purpose group, including floating-point square root.  Specifying
! \&\fB\-mpowerpc\-gfxopt\fR allows \s-1GCC\s0 to
  use the optional PowerPC architecture instructions in the Graphics
! group, including floating-point select.
  .Sp
! The \fB\-mmfcrf\fR option allows \s-1GCC\s0 to generate the move from
! condition register field instruction implemented on the \s-1POWER4\s0
  processor and other processors that support the PowerPC V2.01
  architecture.
! The \fB\-mpopcntb\fR option allows \s-1GCC\s0 to generate the popcount and
! double-precision \s-1FP\s0 reciprocal estimate instruction implemented on the
! \&\s-1POWER5\s0 processor and other processors that support the PowerPC V2.02
  architecture.
! The \fB\-mpopcntd\fR option allows \s-1GCC\s0 to generate the popcount
! instruction implemented on the \s-1POWER7\s0 processor and other processors
  that support the PowerPC V2.06 architecture.
! The \fB\-mfprnd\fR option allows \s-1GCC\s0 to generate the \s-1FP\s0 round to
! integer instructions implemented on the \s-1POWER5+\s0 processor and other
  processors that support the PowerPC V2.03 architecture.
! The \fB\-mcmpb\fR option allows \s-1GCC\s0 to generate the compare bytes
! instruction implemented on the \s-1POWER6\s0 processor and other processors
  that support the PowerPC V2.05 architecture.
! The \fB\-mhard\-dfp\fR option allows \s-1GCC\s0 to generate the decimal
! floating-point instructions implemented on some \s-1POWER\s0 processors.
  .Sp
! The \fB\-mpowerpc64\fR option allows \s-1GCC\s0 to generate the additional
  64\-bit instructions that are found in the full PowerPC64 architecture
! and to treat GPRs as 64\-bit, doubleword quantities.  \s-1GCC\s0 defaults to
  \&\fB\-mno\-powerpc64\fR.
! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
  .IX Item "-mcpu=cpu_type"
  Set architecture type, register usage, and
  instruction scheduling parameters for machine type \fIcpu_type\fR.
--- 28329,28470 ----
  peripheral and specifying \fB\-mcpu=g10\fR disables the use of
  hardware multiplications altogether.
  .Sp
! Note, although the RL78/G14 core is the default target, specifying
  \&\fB\-mcpu=g14\fR or \fB\-mcpu=rl78\fR on the command line does
  change the behavior of the toolchain since it also enables G14
  hardware multiply support.  If these options are not specified on the
  command line then software multiplication routines will be used even
! though the code targets the RL78 core.  This is for backwards
  compatibility with older toolchains which did not have hardware
  multiply and divide support.
  .Sp
  In addition a C preprocessor macro is defined, based upon the setting
  of this option.  Possible values are: \f(CW\*(C`_\|_RL78_G10_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_RL78_G13_\|_\*(C'\fR or \f(CW\*(C`_\|_RL78_G14_\|_\*(C'\fR.
! .IP \fB\-mg10\fR 4
  .IX Item "-mg10"
  .PD 0
! .IP \fB\-mg13\fR 4
  .IX Item "-mg13"
! .IP \fB\-mg14\fR 4
  .IX Item "-mg14"
! .IP \fB\-mrl78\fR 4
  .IX Item "-mrl78"
  .PD
  These are aliases for the corresponding \fB\-mcpu=\fR option.  They
  are provided for backwards compatibility.
! .IP \fB\-mallregs\fR 4
  .IX Item "-mallregs"
  Allow the compiler to use all of the available registers.  By default
  registers \f(CW\*(C`r24..r31\*(C'\fR are reserved for use in interrupt handlers.
  With this option enabled these registers can be used in ordinary
  functions as well.
! .IP \fB\-m64bit\-doubles\fR 4
  .IX Item "-m64bit-doubles"
  .PD 0
! .IP \fB\-m32bit\-doubles\fR 4
  .IX Item "-m32bit-doubles"
  .PD
  Make the \f(CW\*(C`double\*(C'\fR data type be 64 bits (\fB\-m64bit\-doubles\fR)
  or 32 bits (\fB\-m32bit\-doubles\fR) in size.  The default is
  \&\fB\-m32bit\-doubles\fR.
! .IP \fB\-msave\-mduc\-in\-interrupts\fR 4
  .IX Item "-msave-mduc-in-interrupts"
  .PD 0
! .IP \fB\-mno\-save\-mduc\-in\-interrupts\fR 4
  .IX Item "-mno-save-mduc-in-interrupts"
  .PD
  Specifies that interrupt handler functions should preserve the
! MDUC registers.  This is only necessary if normal code might use
! the MDUC registers, for example because it performs multiplication
! and division operations.  The default is to ignore the MDUC registers
  as this makes the interrupt handlers faster.  The target option \-mg13
  needs to be passed for this to work as this feature is only available
! on the G13 target (S2 core).  The MDUC registers will only be saved
  if the interrupt handler performs a multiplication or division
  operation or it calls another function.
  .PP
! \fIIBM RS/6000 and PowerPC Options\fR
  .IX Subsection "IBM RS/6000 and PowerPC Options"
  .PP
! These \fB\-m\fR options are defined for the IBM RS/6000 and PowerPC:
! .IP \fB\-mpowerpc\-gpopt\fR 4
  .IX Item "-mpowerpc-gpopt"
  .PD 0
! .IP \fB\-mno\-powerpc\-gpopt\fR 4
  .IX Item "-mno-powerpc-gpopt"
! .IP \fB\-mpowerpc\-gfxopt\fR 4
  .IX Item "-mpowerpc-gfxopt"
! .IP \fB\-mno\-powerpc\-gfxopt\fR 4
  .IX Item "-mno-powerpc-gfxopt"
! .IP \fB\-mpowerpc64\fR 4
  .IX Item "-mpowerpc64"
! .IP \fB\-mno\-powerpc64\fR 4
  .IX Item "-mno-powerpc64"
! .IP \fB\-mmfcrf\fR 4
  .IX Item "-mmfcrf"
! .IP \fB\-mno\-mfcrf\fR 4
  .IX Item "-mno-mfcrf"
! .IP \fB\-mpopcntb\fR 4
  .IX Item "-mpopcntb"
! .IP \fB\-mno\-popcntb\fR 4
  .IX Item "-mno-popcntb"
! .IP \fB\-mpopcntd\fR 4
  .IX Item "-mpopcntd"
! .IP \fB\-mno\-popcntd\fR 4
  .IX Item "-mno-popcntd"
! .IP \fB\-mfprnd\fR 4
  .IX Item "-mfprnd"
! .IP \fB\-mno\-fprnd\fR 4
  .IX Item "-mno-fprnd"
! .IP \fB\-mcmpb\fR 4
  .IX Item "-mcmpb"
! .IP \fB\-mno\-cmpb\fR 4
  .IX Item "-mno-cmpb"
! .IP \fB\-mhard\-dfp\fR 4
  .IX Item "-mhard-dfp"
! .IP \fB\-mno\-hard\-dfp\fR 4
  .IX Item "-mno-hard-dfp"
  .PD
  You use these options to specify which instructions are available on the
  processor you are using.  The default value of these options is
! determined when configuring GCC.  Specifying the
  \&\fB\-mcpu=\fR\fIcpu_type\fR overrides the specification of these
  options.  We recommend you use the \fB\-mcpu=\fR\fIcpu_type\fR option
  rather than the options listed above.
  .Sp
  Specifying \fB\-mpowerpc\-gpopt\fR allows
! GCC to use the optional PowerPC architecture instructions in the
! General Purpose group, including floating\-point square root.  Specifying
! \&\fB\-mpowerpc\-gfxopt\fR allows GCC to
  use the optional PowerPC architecture instructions in the Graphics
! group, including floating\-point select.
  .Sp
! The \fB\-mmfcrf\fR 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 \fB\-mpopcntb\fR 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 \fB\-mpopcntd\fR option allows GCC to generate the popcount
! instruction implemented on the POWER7 processor and other processors
  that support the PowerPC V2.06 architecture.
! The \fB\-mfprnd\fR 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 \fB\-mcmpb\fR 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 \fB\-mhard\-dfp\fR option allows GCC to generate the decimal
! floating\-point instructions implemented on some POWER processors.
  .Sp
! The \fB\-mpowerpc64\fR 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
  \&\fB\-mno\-powerpc64\fR.
! .IP \fB\-mcpu=\fR\fIcpu_type\fR 4
  .IX Item "-mcpu=cpu_type"
  Set architecture type, register usage, and
  instruction scheduling parameters for machine type \fIcpu_type\fR.
*************** model assumed for scheduling purposes.
*** 28559,28565 ****
  Specifying \fBnative\fR as cpu type detects and selects the
  architecture option that corresponds to the host processor of the
  system performing the compilation.
! \&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize the
  processor.
  .Sp
  The other options specify a specific processor.  Code generated under
--- 28490,28496 ----
  Specifying \fBnative\fR as cpu type detects and selects the
  architecture option that corresponds to the host processor of the
  system performing the compilation.
! \&\fB\-mcpu=native\fR has no effect if GCC does not recognize the
  processor.
  .Sp
  The other options specify a specific processor.  Code generated under
*************** following options:
*** 28578,28596 ****
  \&\-mfloat128\-hardware \-mprefixed \-mpcrel \-mmma
  \&\-mrop\-protect\fR
  .Sp
! The particular options set for any particular \s-1CPU\s0 varies between
  compiler versions, depending on what setting seems to produce optimal
! code for that \s-1CPU\s0; it doesn't necessarily reflect the actual hardware's
  capabilities.  If you wish to set an individual option to a particular
  value, you may specify it after the \fB\-mcpu\fR option, like
  \&\fB\-mcpu=970 \-mno\-altivec\fR.
  .Sp
! On \s-1AIX,\s0 the \fB\-maltivec\fR and \fB\-mpowerpc64\fR options are
  not enabled or disabled by the \fB\-mcpu\fR option at present because
! \&\s-1AIX\s0 does not have full support for these options.  You may still
! enable or disable them individually if you're sure it'll work in your
  environment.
! .IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR, but do not set the architecture type or register usage,
--- 28509,28527 ----
  \&\-mfloat128\-hardware \-mprefixed \-mpcrel \-mmma
  \&\-mrop\-protect\fR
  .Sp
! The particular options set for any particular CPU varies between
  compiler versions, depending on what setting seems to produce optimal
! code for that CPU; it doesn\*(Aqt necessarily reflect the actual hardware\*(Aqs
  capabilities.  If you wish to set an individual option to a particular
  value, you may specify it after the \fB\-mcpu\fR option, like
  \&\fB\-mcpu=970 \-mno\-altivec\fR.
  .Sp
! On AIX, the \fB\-maltivec\fR and \fB\-mpowerpc64\fR options are
  not enabled or disabled by the \fB\-mcpu\fR option at present because
! AIX does not have full support for these options.  You may still
! enable or disable them individually if you\*(Aqre sure it\*(Aqll work in your
  environment.
! .IP \fB\-mtune=\fR\fIcpu_type\fR 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR, but do not set the architecture type or register usage,
*************** values for \fIcpu_type\fR are used for \
*** 28599,28894 ****
  \&\fB\-mcpu\fR.  If both are specified, the code generated uses the
  architecture and registers set by \fB\-mcpu\fR, but the
  scheduling parameters set by \fB\-mtune\fR.
! .IP "\fB\-mcmodel=small\fR" 4
  .IX Item "-mcmodel=small"
! Generate PowerPC64 code for the small model: The \s-1TOC\s0 is limited to
  64k.
! .IP "\fB\-mcmodel=medium\fR" 4
  .IX Item "-mcmodel=medium"
! Generate PowerPC64 code for the medium model: The \s-1TOC\s0 and other static
  data may be up to a total of 4G in size.  This is the default for 64\-bit
  Linux.
! .IP "\fB\-mcmodel=large\fR" 4
  .IX Item "-mcmodel=large"
! Generate PowerPC64 code for the large model: The \s-1TOC\s0 may be up to 4G
  in size.  Other data and code is only limited by the 64\-bit address
  space.
! .IP "\fB\-maltivec\fR" 4
  .IX Item "-maltivec"
  .PD 0
! .IP "\fB\-mno\-altivec\fR" 4
  .IX Item "-mno-altivec"
  .PD
  Generate code that uses (does not use) AltiVec instructions, and also
! enable the use of built-in functions that allow more direct access to
  the AltiVec instruction set.  You may also need to set
! \&\fB\-mabi=altivec\fR to adjust the current \s-1ABI\s0 with AltiVec \s-1ABI\s0
  enhancements.
  .Sp
  When \fB\-maltivec\fR is used, the element order for AltiVec intrinsics
  such as \f(CW\*(C`vec_splat\*(C'\fR, \f(CW\*(C`vec_extract\*(C'\fR, and \f(CW\*(C`vec_insert\*(C'\fR 
  match array element order corresponding to the endianness of the
  target.  That is, element zero identifies the leftmost element in a
! vector register when targeting a big-endian platform, and identifies
  the rightmost element in a vector register when targeting a
! little-endian platform.
! .IP "\fB\-mvrsave\fR" 4
  .IX Item "-mvrsave"
  .PD 0
! .IP "\fB\-mno\-vrsave\fR" 4
  .IX Item "-mno-vrsave"
  .PD
! Generate \s-1VRSAVE\s0 instructions when generating AltiVec code.
! .IP "\fB\-msecure\-plt\fR" 4
  .IX Item "-msecure-plt"
  Generate code that allows \fBld\fR and \fBld.so\fR
  to build executables and shared
! libraries with non-executable \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR sections.
  This is a PowerPC
! 32\-bit \s-1SYSV ABI\s0 option.
! .IP "\fB\-mbss\-plt\fR" 4
  .IX Item "-mbss-plt"
! Generate code that uses a \s-1BSS\s0 \f(CW\*(C`.plt\*(C'\fR section that \fBld.so\fR
  fills in, and
  requires \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR
  sections that are both writable and executable.
! This is a PowerPC 32\-bit \s-1SYSV ABI\s0 option.
! .IP "\fB\-misel\fR" 4
  .IX Item "-misel"
  .PD 0
! .IP "\fB\-mno\-isel\fR" 4
  .IX Item "-mno-isel"
  .PD
! This switch enables or disables the generation of \s-1ISEL\s0 instructions.
! .IP "\fB\-mvsx\fR" 4
  .IX Item "-mvsx"
  .PD 0
! .IP "\fB\-mno\-vsx\fR" 4
  .IX Item "-mno-vsx"
  .PD
! Generate code that uses (does not use) vector/scalar (\s-1VSX\s0)
! instructions, and also enable the use of built-in functions that allow
! more direct access to the \s-1VSX\s0 instruction set.
! .IP "\fB\-mcrypto\fR" 4
  .IX Item "-mcrypto"
  .PD 0
! .IP "\fB\-mno\-crypto\fR" 4
  .IX Item "-mno-crypto"
  .PD
! Enable the use (disable) of the built-in functions that allow direct
  access to the cryptographic instructions that were added in version
! 2.07 of the PowerPC \s-1ISA.\s0
! .IP "\fB\-mhtm\fR" 4
  .IX Item "-mhtm"
  .PD 0
! .IP "\fB\-mno\-htm\fR" 4
  .IX Item "-mno-htm"
  .PD
! Enable (disable) the use of the built-in functions that allow direct
! access to the Hardware Transactional Memory (\s-1HTM\s0) instructions that
! were added in version 2.07 of the PowerPC \s-1ISA.\s0
! .IP "\fB\-mpower8\-fusion\fR" 4
  .IX Item "-mpower8-fusion"
  .PD 0
! .IP "\fB\-mno\-power8\-fusion\fR" 4
  .IX Item "-mno-power8-fusion"
  .PD
  Generate code that keeps (does not keeps) some integer operations
  adjacent so that the instructions can be fused together on power8 and
  later processors.
! .IP "\fB\-mpower8\-vector\fR" 4
  .IX Item "-mpower8-vector"
  .PD 0
! .IP "\fB\-mno\-power8\-vector\fR" 4
  .IX Item "-mno-power8-vector"
  .PD
  Generate code that uses (does not use) the vector and scalar
! instructions that were added in version 2.07 of the PowerPC \s-1ISA.\s0  Also
! enable the use of built-in functions that allow more direct access to
  the vector instructions.
! .IP "\fB\-mquad\-memory\fR" 4
  .IX Item "-mquad-memory"
  .PD 0
! .IP "\fB\-mno\-quad\-memory\fR" 4
  .IX Item "-mno-quad-memory"
  .PD
! Generate code that uses (does not use) the non-atomic quad word memory
  instructions.  The \fB\-mquad\-memory\fR option requires use of
  64\-bit mode.
! .IP "\fB\-mquad\-memory\-atomic\fR" 4
  .IX Item "-mquad-memory-atomic"
  .PD 0
! .IP "\fB\-mno\-quad\-memory\-atomic\fR" 4
  .IX Item "-mno-quad-memory-atomic"
  .PD
  Generate code that uses (does not use) the atomic quad word memory
  instructions.  The \fB\-mquad\-memory\-atomic\fR option requires use of
  64\-bit mode.
! .IP "\fB\-mfloat128\fR" 4
  .IX Item "-mfloat128"
  .PD 0
! .IP "\fB\-mno\-float128\fR" 4
  .IX Item "-mno-float128"
  .PD
! Enable/disable the \fI_\|_float128\fR keyword for \s-1IEEE\s0 128\-bit floating point
! and use either software emulation for \s-1IEEE\s0 128\-bit floating point or
  hardware instructions.
  .Sp
! The \s-1VSX\s0 instruction set (\fB\-mvsx\fR) must be enabled to use the \s-1IEEE\s0
! 128\-bit floating point support.  The \s-1IEEE\s0 128\-bit floating point is only
  supported on Linux.
  .Sp
  The default for \fB\-mfloat128\fR is enabled on PowerPC Linux
! systems using the \s-1VSX\s0 instruction set, and disabled on other systems.
  .Sp
! If you use the \s-1ISA 3.0\s0 instruction set (\fB\-mpower9\-vector\fR or
! \&\fB\-mcpu=power9\fR) on a 64\-bit system, the \s-1IEEE\s0 128\-bit floating
! point support will also enable the generation of \s-1ISA 3.0 IEEE\s0 128\-bit
  floating point instructions.  Otherwise, if you do not specify to
! generate \s-1ISA 3.0\s0 instructions or you are targeting a 32\-bit big endian
! system, \s-1IEEE\s0 128\-bit floating point will be done with software
  emulation.
! .IP "\fB\-mfloat128\-hardware\fR" 4
  .IX Item "-mfloat128-hardware"
  .PD 0
! .IP "\fB\-mno\-float128\-hardware\fR" 4
  .IX Item "-mno-float128-hardware"
  .PD
! Enable/disable using \s-1ISA 3.0\s0 hardware instructions to support the
  \&\fI_\|_float128\fR data type.
  .Sp
  The default for \fB\-mfloat128\-hardware\fR is enabled on PowerPC
! Linux systems using the \s-1ISA 3.0\s0 instruction set, and disabled on other
  systems.
! .IP "\fB\-m32\fR" 4
  .IX Item "-m32"
  .PD 0
! .IP "\fB\-m64\fR" 4
  .IX Item "-m64"
  .PD
! Generate code for 32\-bit or 64\-bit environments of Darwin and \s-1SVR4\s0
  targets (including GNU/Linux).  The 32\-bit environment sets int, long
  and pointer to 32 bits and generates code that runs on any PowerPC
  variant.  The 64\-bit environment sets int to 32 bits and long and
  pointer to 64 bits, and generates code for PowerPC64, as for
  \&\fB\-mpowerpc64\fR.
! .IP "\fB\-mfull\-toc\fR" 4
  .IX Item "-mfull-toc"
  .PD 0
! .IP "\fB\-mno\-fp\-in\-toc\fR" 4
  .IX Item "-mno-fp-in-toc"
! .IP "\fB\-mno\-sum\-in\-toc\fR" 4
  .IX Item "-mno-sum-in-toc"
! .IP "\fB\-mminimal\-toc\fR" 4
  .IX Item "-mminimal-toc"
  .PD
! Modify generation of the \s-1TOC\s0 (Table Of Contents), which is created for
  every executable file.  The \fB\-mfull\-toc\fR option is selected by
! default.  In that case, \s-1GCC\s0 allocates at least one \s-1TOC\s0 entry for
! each unique non-automatic variable reference in your program.  \s-1GCC\s0
! also places floating-point constants in the \s-1TOC.\s0  However, only
! 16,384 entries are available in the \s-1TOC.\s0
  .Sp
  If you receive a linker error message that saying you have overflowed
! the available \s-1TOC\s0 space, you can reduce the amount of \s-1TOC\s0 space used
  with the \fB\-mno\-fp\-in\-toc\fR and \fB\-mno\-sum\-in\-toc\fR options.
! \&\fB\-mno\-fp\-in\-toc\fR prevents \s-1GCC\s0 from putting floating-point
! constants in the \s-1TOC\s0 and \fB\-mno\-sum\-in\-toc\fR forces \s-1GCC\s0 to
  generate code to calculate the sum of an address and a constant at
! run time instead of putting that sum into the \s-1TOC.\s0  You may specify one
! or both of these options.  Each causes \s-1GCC\s0 to produce very slightly
! slower and larger code at the expense of conserving \s-1TOC\s0 space.
  .Sp
! If you still run out of space in the \s-1TOC\s0 even when you specify both of
  these options, specify \fB\-mminimal\-toc\fR instead.  This option causes
! \&\s-1GCC\s0 to make only one \s-1TOC\s0 entry for every file.  When you specify this
! option, \s-1GCC\s0 produces code that is slower and larger but which
! uses extremely little \s-1TOC\s0 space.  You may wish to use this option
! only on files that contain less frequently-executed code.
! .IP "\fB\-maix64\fR" 4
  .IX Item "-maix64"
  .PD 0
! .IP "\fB\-maix32\fR" 4
  .IX Item "-maix32"
  .PD
! Enable 64\-bit \s-1AIX ABI\s0 and calling convention: 64\-bit pointers, 64\-bit
  \&\f(CW\*(C`long\*(C'\fR type, and the infrastructure needed to support them.
  Specifying \fB\-maix64\fR implies \fB\-mpowerpc64\fR,
! while \fB\-maix32\fR disables the 64\-bit \s-1ABI\s0 and
! implies \fB\-mno\-powerpc64\fR.  \s-1GCC\s0 defaults to \fB\-maix32\fR.
! .IP "\fB\-mxl\-compat\fR" 4
  .IX Item "-mxl-compat"
  .PD 0
! .IP "\fB\-mno\-xl\-compat\fR" 4
  .IX Item "-mno-xl-compat"
  .PD
! Produce code that conforms more closely to \s-1IBM XL\s0 compiler semantics
! when using AIX-compatible \s-1ABI.\s0  Pass floating-point arguments to
! prototyped functions beyond the register save area (\s-1RSA\s0) on the stack
  in addition to argument FPRs.  Do not assume that most significant
  double in 128\-bit long double value is properly rounded when comparing
! values and converting to double.  Use \s-1XL\s0 symbol names for long double
  support routines.
  .Sp
! The \s-1AIX\s0 calling convention was extended but not initially documented to
  handle an obscure K&R C case of calling a function that takes the
! address of its arguments with fewer arguments than declared.  \s-1IBM XL\s0
! compilers access floating-point arguments that do not fit in the
! \&\s-1RSA\s0 from the stack when a subroutine is compiled without
! optimization.  Because always storing floating-point arguments on the
  stack is inefficient and rarely needed, this option is not enabled by
! default and only is necessary when calling subroutines compiled by \s-1IBM
! XL\s0 compilers without optimization.
! .IP "\fB\-mpe\fR" 4
  .IX Item "-mpe"
! Support \fI\s-1IBM RS/6000 SP\s0\fR \fIParallel Environment\fR (\s-1PE\s0).  Link an
  application written to use message passing with special startup code to
! enable the application to run.  The system must have \s-1PE\s0 installed in the
  standard location (\fI/usr/lpp/ppe.poe/\fR), or the \fIspecs\fR file
  must be overridden with the \fB\-specs=\fR option to specify the
  appropriate directory location.  The Parallel Environment does not
  support threads, so the \fB\-mpe\fR option and the \fB\-pthread\fR
  option are incompatible.
! .IP "\fB\-malign\-natural\fR" 4
  .IX Item "-malign-natural"
  .PD 0
! .IP "\fB\-malign\-power\fR" 4
  .IX Item "-malign-power"
  .PD
! On \s-1AIX,\s0 32\-bit Darwin, and 64\-bit PowerPC GNU/Linux, the option
! \&\fB\-malign\-natural\fR overrides the ABI-defined alignment of larger
! types, such as floating-point doubles, on their natural size-based boundary.
! The option \fB\-malign\-power\fR instructs \s-1GCC\s0 to follow the ABI-specified
! alignment rules.  \s-1GCC\s0 defaults to the standard alignment defined in the \s-1ABI.\s0
  .Sp
  On 64\-bit Darwin, natural alignment is the default, and \fB\-malign\-power\fR
  is not supported.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
! Generate code that does not use (uses) the floating-point register set.
! Software floating-point emulation is provided if you use the
! \&\fB\-msoft\-float\fR option, and pass the option to \s-1GCC\s0 when linking.
! .IP "\fB\-mmultiple\fR" 4
  .IX Item "-mmultiple"
  .PD 0
! .IP "\fB\-mno\-multiple\fR" 4
  .IX Item "-mno-multiple"
  .PD
  Generate code that uses (does not use) the load multiple word
  instructions and the store multiple word instructions.  These
! instructions are generated by default on \s-1POWER\s0 systems, and not
! generated on PowerPC systems.  Do not use \fB\-mmultiple\fR on little-endian
  PowerPC systems, since those instructions do not work when the
! processor is in little-endian mode.  The exceptions are \s-1PPC740\s0 and
! \&\s-1PPC750\s0 which permit these instructions in little-endian mode.
! .IP "\fB\-mupdate\fR" 4
  .IX Item "-mupdate"
  .PD 0
! .IP "\fB\-mno\-update\fR" 4
  .IX Item "-mno-update"
  .PD
  Generate code that uses (does not use) the load or store instructions
--- 28530,28825 ----
  \&\fB\-mcpu\fR.  If both are specified, the code generated uses the
  architecture and registers set by \fB\-mcpu\fR, but the
  scheduling parameters set by \fB\-mtune\fR.
! .IP \fB\-mcmodel=small\fR 4
  .IX Item "-mcmodel=small"
! Generate PowerPC64 code for the small model: The TOC is limited to
  64k.
! .IP \fB\-mcmodel=medium\fR 4
  .IX Item "-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.  This is the default for 64\-bit
  Linux.
! .IP \fB\-mcmodel=large\fR 4
  .IX Item "-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.
! .IP \fB\-maltivec\fR 4
  .IX Item "-maltivec"
  .PD 0
! .IP \fB\-mno\-altivec\fR 4
  .IX Item "-mno-altivec"
  .PD
  Generate code that uses (does not use) AltiVec instructions, and also
! enable the use of built\-in functions that allow more direct access to
  the AltiVec instruction set.  You may also need to set
! \&\fB\-mabi=altivec\fR to adjust the current ABI with AltiVec ABI
  enhancements.
  .Sp
  When \fB\-maltivec\fR is used, the element order for AltiVec intrinsics
  such as \f(CW\*(C`vec_splat\*(C'\fR, \f(CW\*(C`vec_extract\*(C'\fR, and \f(CW\*(C`vec_insert\*(C'\fR 
  match array element order corresponding to the endianness of the
  target.  That is, element zero identifies the leftmost element in a
! vector register when targeting a big\-endian platform, and identifies
  the rightmost element in a vector register when targeting a
! little\-endian platform.
! .IP \fB\-mvrsave\fR 4
  .IX Item "-mvrsave"
  .PD 0
! .IP \fB\-mno\-vrsave\fR 4
  .IX Item "-mno-vrsave"
  .PD
! Generate VRSAVE instructions when generating AltiVec code.
! .IP \fB\-msecure\-plt\fR 4
  .IX Item "-msecure-plt"
  Generate code that allows \fBld\fR and \fBld.so\fR
  to build executables and shared
! libraries with non\-executable \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR sections.
  This is a PowerPC
! 32\-bit SYSV ABI option.
! .IP \fB\-mbss\-plt\fR 4
  .IX Item "-mbss-plt"
! Generate code that uses a BSS \f(CW\*(C`.plt\*(C'\fR section that \fBld.so\fR
  fills in, and
  requires \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR
  sections that are both writable and executable.
! This is a PowerPC 32\-bit SYSV ABI option.
! .IP \fB\-misel\fR 4
  .IX Item "-misel"
  .PD 0
! .IP \fB\-mno\-isel\fR 4
  .IX Item "-mno-isel"
  .PD
! This switch enables or disables the generation of ISEL instructions.
! .IP \fB\-mvsx\fR 4
  .IX Item "-mvsx"
  .PD 0
! .IP \fB\-mno\-vsx\fR 4
  .IX Item "-mno-vsx"
  .PD
! Generate code that uses (does not use) vector/scalar (VSX)
! instructions, and also enable the use of built\-in functions that allow
! more direct access to the VSX instruction set.
! .IP \fB\-mcrypto\fR 4
  .IX Item "-mcrypto"
  .PD 0
! .IP \fB\-mno\-crypto\fR 4
  .IX Item "-mno-crypto"
  .PD
! Enable the use (disable) of the built\-in functions that allow direct
  access to the cryptographic instructions that were added in version
! 2.07 of the PowerPC ISA.
! .IP \fB\-mhtm\fR 4
  .IX Item "-mhtm"
  .PD 0
! .IP \fB\-mno\-htm\fR 4
  .IX Item "-mno-htm"
  .PD
! Enable (disable) the use of the built\-in functions that allow direct
! access to the Hardware Transactional Memory (HTM) instructions that
! were added in version 2.07 of the PowerPC ISA.
! .IP \fB\-mpower8\-fusion\fR 4
  .IX Item "-mpower8-fusion"
  .PD 0
! .IP \fB\-mno\-power8\-fusion\fR 4
  .IX Item "-mno-power8-fusion"
  .PD
  Generate code that keeps (does not keeps) some integer operations
  adjacent so that the instructions can be fused together on power8 and
  later processors.
! .IP \fB\-mpower8\-vector\fR 4
  .IX Item "-mpower8-vector"
  .PD 0
! .IP \fB\-mno\-power8\-vector\fR 4
  .IX Item "-mno-power8-vector"
  .PD
  Generate code that uses (does not use) the vector and scalar
! instructions that were added in version 2.07 of the PowerPC ISA.  Also
! enable the use of built\-in functions that allow more direct access to
  the vector instructions.
! .IP \fB\-mquad\-memory\fR 4
  .IX Item "-mquad-memory"
  .PD 0
! .IP \fB\-mno\-quad\-memory\fR 4
  .IX Item "-mno-quad-memory"
  .PD
! Generate code that uses (does not use) the non\-atomic quad word memory
  instructions.  The \fB\-mquad\-memory\fR option requires use of
  64\-bit mode.
! .IP \fB\-mquad\-memory\-atomic\fR 4
  .IX Item "-mquad-memory-atomic"
  .PD 0
! .IP \fB\-mno\-quad\-memory\-atomic\fR 4
  .IX Item "-mno-quad-memory-atomic"
  .PD
  Generate code that uses (does not use) the atomic quad word memory
  instructions.  The \fB\-mquad\-memory\-atomic\fR option requires use of
  64\-bit mode.
! .IP \fB\-mfloat128\fR 4
  .IX Item "-mfloat128"
  .PD 0
! .IP \fB\-mno\-float128\fR 4
  .IX Item "-mno-float128"
  .PD
! Enable/disable the \fI_\|_float128\fR keyword for IEEE 128\-bit floating point
! and use either software emulation for IEEE 128\-bit floating point or
  hardware instructions.
  .Sp
! The VSX instruction set (\fB\-mvsx\fR) must be enabled to use the IEEE
! 128\-bit floating point support.  The IEEE 128\-bit floating point is only
  supported on Linux.
  .Sp
  The default for \fB\-mfloat128\fR is enabled on PowerPC Linux
! systems using the VSX instruction set, and disabled on other systems.
  .Sp
! If you use the ISA 3.0 instruction set (\fB\-mpower9\-vector\fR or
! \&\fB\-mcpu=power9\fR) on a 64\-bit system, the IEEE 128\-bit floating
! point support will also enable the generation of ISA 3.0 IEEE 128\-bit
  floating point instructions.  Otherwise, if you do not specify to
! generate ISA 3.0 instructions or you are targeting a 32\-bit big endian
! system, IEEE 128\-bit floating point will be done with software
  emulation.
! .IP \fB\-mfloat128\-hardware\fR 4
  .IX Item "-mfloat128-hardware"
  .PD 0
! .IP \fB\-mno\-float128\-hardware\fR 4
  .IX Item "-mno-float128-hardware"
  .PD
! Enable/disable using ISA 3.0 hardware instructions to support the
  \&\fI_\|_float128\fR data type.
  .Sp
  The default for \fB\-mfloat128\-hardware\fR is enabled on PowerPC
! Linux systems using the ISA 3.0 instruction set, and disabled on other
  systems.
! .IP \fB\-m32\fR 4
  .IX Item "-m32"
  .PD 0
! .IP \fB\-m64\fR 4
  .IX Item "-m64"
  .PD
! Generate code for 32\-bit or 64\-bit environments of Darwin and 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
  \&\fB\-mpowerpc64\fR.
! .IP \fB\-mfull\-toc\fR 4
  .IX Item "-mfull-toc"
  .PD 0
! .IP \fB\-mno\-fp\-in\-toc\fR 4
  .IX Item "-mno-fp-in-toc"
! .IP \fB\-mno\-sum\-in\-toc\fR 4
  .IX Item "-mno-sum-in-toc"
! .IP \fB\-mminimal\-toc\fR 4
  .IX Item "-mminimal-toc"
  .PD
! Modify generation of the TOC (Table Of Contents), which is created for
  every executable file.  The \fB\-mfull\-toc\fR option is selected by
! default.  In that case, GCC allocates at least one TOC entry for
! each unique non\-automatic variable reference in your program.  GCC
! also places floating\-point constants in the TOC.  However, only
! 16,384 entries are available in the TOC.
  .Sp
  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 \fB\-mno\-fp\-in\-toc\fR and \fB\-mno\-sum\-in\-toc\fR options.
! \&\fB\-mno\-fp\-in\-toc\fR prevents GCC from putting floating\-point
! constants in the TOC and \fB\-mno\-sum\-in\-toc\fR 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.
  .Sp
! If you still run out of space in the TOC even when you specify both of
  these options, specify \fB\-mminimal\-toc\fR instead.  This option causes
! GCC to make only one TOC entry for every file.  When you specify this
! option, GCC produces code that is slower and larger but which
! uses extremely little TOC space.  You may wish to use this option
! only on files that contain less frequently\-executed code.
! .IP \fB\-maix64\fR 4
  .IX Item "-maix64"
  .PD 0
! .IP \fB\-maix32\fR 4
  .IX Item "-maix32"
  .PD
! Enable 64\-bit AIX ABI and calling convention: 64\-bit pointers, 64\-bit
  \&\f(CW\*(C`long\*(C'\fR type, and the infrastructure needed to support them.
  Specifying \fB\-maix64\fR implies \fB\-mpowerpc64\fR,
! while \fB\-maix32\fR disables the 64\-bit ABI and
! implies \fB\-mno\-powerpc64\fR.  GCC defaults to \fB\-maix32\fR.
! .IP \fB\-mxl\-compat\fR 4
  .IX Item "-mxl-compat"
  .PD 0
! .IP \fB\-mno\-xl\-compat\fR 4
  .IX Item "-mno-xl-compat"
  .PD
! Produce code that conforms more closely to 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.
  .Sp
! The AIX calling convention was extended but not initially documented to
  handle an obscure K&R C case of calling a function that takes the
! address of its arguments with fewer arguments than declared.  IBM XL
! compilers access floating\-point arguments that do not fit in the
! RSA from the stack when a subroutine is compiled without
! optimization.  Because always storing floating\-point arguments on the
  stack is inefficient and rarely needed, this option is not enabled by
! default and only is necessary when calling subroutines compiled by IBM
! XL compilers without optimization.
! .IP \fB\-mpe\fR 4
  .IX Item "-mpe"
! Support \fIIBM RS/6000 SP\fR \fIParallel Environment\fR (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 (\fI/usr/lpp/ppe.poe/\fR), or the \fIspecs\fR file
  must be overridden with the \fB\-specs=\fR option to specify the
  appropriate directory location.  The Parallel Environment does not
  support threads, so the \fB\-mpe\fR option and the \fB\-pthread\fR
  option are incompatible.
! .IP \fB\-malign\-natural\fR 4
  .IX Item "-malign-natural"
  .PD 0
! .IP \fB\-malign\-power\fR 4
  .IX Item "-malign-power"
  .PD
! On AIX, 32\-bit Darwin, and 64\-bit PowerPC GNU/Linux, the option
! \&\fB\-malign\-natural\fR overrides the ABI\-defined alignment of larger
! types, such as floating\-point doubles, on their natural size\-based boundary.
! The option \fB\-malign\-power\fR instructs GCC to follow the ABI\-specified
! alignment rules.  GCC defaults to the standard alignment defined in the ABI.
  .Sp
  On 64\-bit Darwin, natural alignment is the default, and \fB\-malign\-power\fR
  is not supported.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
! Generate code that does not use (uses) the floating\-point register set.
! Software floating\-point emulation is provided if you use the
! \&\fB\-msoft\-float\fR option, and pass the option to GCC when linking.
! .IP \fB\-mmultiple\fR 4
  .IX Item "-mmultiple"
  .PD 0
! .IP \fB\-mno\-multiple\fR 4
  .IX Item "-mno-multiple"
  .PD
  Generate code that uses (does not use) the load multiple word
  instructions and the store multiple word instructions.  These
! instructions are generated by default on POWER systems, and not
! generated on PowerPC systems.  Do not use \fB\-mmultiple\fR on little\-endian
  PowerPC systems, since those instructions do not work when the
! processor is in little\-endian mode.  The exceptions are PPC740 and
! PPC750 which permit these instructions in little\-endian mode.
! .IP \fB\-mupdate\fR 4
  .IX Item "-mupdate"
  .PD 0
! .IP \fB\-mno\-update\fR 4
  .IX Item "-mno-update"
  .PD
  Generate code that uses (does not use) the load or store instructions
*************** location.  These instructions are genera
*** 28898,28907 ****
  stack pointer is updated and the address of the previous frame is
  stored, which means code that walks the stack frame across interrupts or
  signals may get corrupted data.
! .IP "\fB\-mavoid\-indexed\-addresses\fR" 4
  .IX Item "-mavoid-indexed-addresses"
  .PD 0
! .IP "\fB\-mno\-avoid\-indexed\-addresses\fR" 4
  .IX Item "-mno-avoid-indexed-addresses"
  .PD
  Generate code that tries to avoid (not avoid) the use of indexed load
--- 28829,28838 ----
  stack pointer is updated and the address of the previous frame is
  stored, which means code that walks the stack frame across interrupts or
  signals may get corrupted data.
! .IP \fB\-mavoid\-indexed\-addresses\fR 4
  .IX Item "-mavoid-indexed-addresses"
  .PD 0
! .IP \fB\-mno\-avoid\-indexed\-addresses\fR 4
  .IX Item "-mno-avoid-indexed-addresses"
  .PD
  Generate code that tries to avoid (not avoid) the use of indexed load
*************** or store instructions. These instruction
*** 28909,28972 ****
  penalty on Power6 processors in certain situations, such as when
  stepping through large arrays that cross a 16M boundary.  This option
  is enabled by default when targeting Power6 and disabled otherwise.
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating-point multiply and
  accumulate instructions.  These instructions are generated by default
! if hardware floating point is used.  The machine-dependent
! \&\fB\-mfused\-madd\fR option is now mapped to the machine-independent
  \&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
  mapped to \fB\-ffp\-contract=off\fR.
! .IP "\fB\-mmulhw\fR" 4
  .IX Item "-mmulhw"
  .PD 0
! .IP "\fB\-mno\-mulhw\fR" 4
  .IX Item "-mno-mulhw"
  .PD
! Generate code that uses (does not use) the half-word multiply and
! multiply-accumulate instructions on the \s-1IBM 405, 440, 464\s0 and 476 processors.
  These instructions are generated by default when targeting those
  processors.
! .IP "\fB\-mdlmzb\fR" 4
  .IX Item "-mdlmzb"
  .PD 0
! .IP "\fB\-mno\-dlmzb\fR" 4
  .IX Item "-mno-dlmzb"
  .PD
! Generate code that uses (does not use) the string-search \fBdlmzb\fR
! instruction on the \s-1IBM 405, 440, 464\s0 and 476 processors.  This instruction is
  generated by default when targeting those processors.
! .IP "\fB\-mno\-bit\-align\fR" 4
  .IX Item "-mno-bit-align"
  .PD 0
! .IP "\fB\-mbit\-align\fR" 4
  .IX Item "-mbit-align"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) force structures
! and unions that contain bit-fields to be aligned to the base type of the
! bit-field.
  .Sp
  For example, by default a structure containing nothing but 8
! \&\f(CW\*(C`unsigned\*(C'\fR bit-fields of length 1 is aligned to a 4\-byte
  boundary and has a size of 4 bytes.  By using \fB\-mno\-bit\-align\fR,
  the structure is aligned to a 1\-byte boundary and is 1 byte in
  size.
! .IP "\fB\-mno\-strict\-align\fR" 4
  .IX Item "-mno-strict-align"
  .PD 0
! .IP "\fB\-mstrict\-align\fR" 4
  .IX Item "-mstrict-align"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) assume that
  unaligned memory references are handled by the system.
! .IP "\fB\-mrelocatable\fR" 4
  .IX Item "-mrelocatable"
  .PD 0
! .IP "\fB\-mno\-relocatable\fR" 4
  .IX Item "-mno-relocatable"
  .PD
  Generate code that allows (does not allow) a static executable to be
--- 28840,28903 ----
  penalty on Power6 processors in certain situations, such as when
  stepping through large arrays that cross a 16M boundary.  This option
  is enabled by default when targeting Power6 and disabled otherwise.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating\-point multiply and
  accumulate instructions.  These instructions are generated by default
! if hardware floating point is used.  The machine\-dependent
! \&\fB\-mfused\-madd\fR option is now mapped to the machine\-independent
  \&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
  mapped to \fB\-ffp\-contract=off\fR.
! .IP \fB\-mmulhw\fR 4
  .IX Item "-mmulhw"
  .PD 0
! .IP \fB\-mno\-mulhw\fR 4
  .IX Item "-mno-mulhw"
  .PD
! Generate code that uses (does not use) the half\-word multiply and
! multiply\-accumulate instructions on the IBM 405, 440, 464 and 476 processors.
  These instructions are generated by default when targeting those
  processors.
! .IP \fB\-mdlmzb\fR 4
  .IX Item "-mdlmzb"
  .PD 0
! .IP \fB\-mno\-dlmzb\fR 4
  .IX Item "-mno-dlmzb"
  .PD
! Generate code that uses (does not use) the string\-search \fBdlmzb\fR
! instruction on the IBM 405, 440, 464 and 476 processors.  This instruction is
  generated by default when targeting those processors.
! .IP \fB\-mno\-bit\-align\fR 4
  .IX Item "-mno-bit-align"
  .PD 0
! .IP \fB\-mbit\-align\fR 4
  .IX Item "-mbit-align"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) force structures
! and unions that contain bit\-fields to be aligned to the base type of the
! bit\-field.
  .Sp
  For example, by default a structure containing nothing but 8
! \&\f(CW\*(C`unsigned\*(C'\fR bit\-fields of length 1 is aligned to a 4\-byte
  boundary and has a size of 4 bytes.  By using \fB\-mno\-bit\-align\fR,
  the structure is aligned to a 1\-byte boundary and is 1 byte in
  size.
! .IP \fB\-mno\-strict\-align\fR 4
  .IX Item "-mno-strict-align"
  .PD 0
! .IP \fB\-mstrict\-align\fR 4
  .IX Item "-mstrict-align"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) assume that
  unaligned memory references are handled by the system.
! .IP \fB\-mrelocatable\fR 4
  .IX Item "-mrelocatable"
  .PD 0
! .IP \fB\-mno\-relocatable\fR 4
  .IX Item "-mno-relocatable"
  .PD
  Generate code that allows (does not allow) a static executable to be
*************** a table of 32\-bit addresses generated b
*** 28977,28986 ****
  work, all objects linked together must be compiled with
  \&\fB\-mrelocatable\fR or \fB\-mrelocatable\-lib\fR.
  \&\fB\-mrelocatable\fR code aligns the stack to an 8\-byte boundary.
! .IP "\fB\-mrelocatable\-lib\fR" 4
  .IX Item "-mrelocatable-lib"
  .PD 0
! .IP "\fB\-mno\-relocatable\-lib\fR" 4
  .IX Item "-mno-relocatable-lib"
  .PD
  Like \fB\-mrelocatable\fR, \fB\-mrelocatable\-lib\fR generates a
--- 28908,28917 ----
  work, all objects linked together must be compiled with
  \&\fB\-mrelocatable\fR or \fB\-mrelocatable\-lib\fR.
  \&\fB\-mrelocatable\fR code aligns the stack to an 8\-byte boundary.
! .IP \fB\-mrelocatable\-lib\fR 4
  .IX Item "-mrelocatable-lib"
  .PD 0
! .IP \fB\-mno\-relocatable\-lib\fR 4
  .IX Item "-mno-relocatable-lib"
  .PD
  Like \fB\-mrelocatable\fR, \fB\-mrelocatable\-lib\fR generates a
*************** run time, but \fB\-mrelocatable\-lib\fR
*** 28989,29244 ****
  alignment of \fB\-mrelocatable\fR.  Objects compiled with
  \&\fB\-mrelocatable\-lib\fR may be linked with objects compiled with
  any combination of the \fB\-mrelocatable\fR options.
! .IP "\fB\-mno\-toc\fR" 4
  .IX Item "-mno-toc"
  .PD 0
! .IP "\fB\-mtoc\fR" 4
  .IX Item "-mtoc"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) assume that
  register 2 contains a pointer to a global area pointing to the addresses
  used in the program.
! .IP "\fB\-mlittle\fR" 4
  .IX Item "-mlittle"
  .PD 0
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
  .PD
  On System V.4 and embedded PowerPC systems compile code for the
! processor in little-endian mode.  The \fB\-mlittle\-endian\fR option is
  the same as \fB\-mlittle\fR.
! .IP "\fB\-mbig\fR" 4
  .IX Item "-mbig"
  .PD 0
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
  .PD
  On System V.4 and embedded PowerPC systems compile code for the
! processor in big-endian mode.  The \fB\-mbig\-endian\fR option is
  the same as \fB\-mbig\fR.
! .IP "\fB\-mdynamic\-no\-pic\fR" 4
  .IX Item "-mdynamic-no-pic"
! On Darwin and Mac \s-1OS X\s0 systems, compile code so that it is not
  relocatable, but that its external references are relocatable.  The
  resulting code is suitable for applications, but not shared
  libraries.
! .IP "\fB\-msingle\-pic\-base\fR" 4
  .IX Item "-msingle-pic-base"
! Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
  loading it in the prologue for each function.  The runtime system is
  responsible for initializing this register with an appropriate value
  before execution begins.
! .IP "\fB\-mprioritize\-restricted\-insns=\fR\fIpriority\fR" 4
  .IX Item "-mprioritize-restricted-insns=priority"
  This option controls the priority that is assigned to
! dispatch-slot restricted instructions during the second scheduling
  pass.  The argument \fIpriority\fR takes the value \fB0\fR, \fB1\fR,
! or \fB2\fR to assign no, highest, or second-highest (respectively) 
! priority to dispatch-slot restricted
  instructions.
! .IP "\fB\-msched\-costly\-dep=\fR\fIdependence_type\fR" 4
  .IX Item "-msched-costly-dep=dependence_type"
  This option controls which dependences are considered costly
  by the target during instruction scheduling.  The argument
  \&\fIdependence_type\fR takes one of the following values:
  .RS 4
! .IP "\fBno\fR" 4
  .IX Item "no"
  No dependence is costly.
! .IP "\fBall\fR" 4
  .IX Item "all"
  All dependences are costly.
! .IP "\fBtrue_store_to_load\fR" 4
  .IX Item "true_store_to_load"
  A true dependence from store to load is costly.
! .IP "\fBstore_to_load\fR" 4
  .IX Item "store_to_load"
  Any dependence from store to load is costly.
! .IP "\fInumber\fR" 4
  .IX Item "number"
  Any dependence for which the latency is greater than or equal to 
  \&\fInumber\fR is costly.
  .RE
  .RS 4
  .RE
! .IP "\fB\-minsert\-sched\-nops=\fR\fIscheme\fR" 4
  .IX Item "-minsert-sched-nops=scheme"
! This option controls which \s-1NOP\s0 insertion scheme is used during
  the second scheduling pass.  The argument \fIscheme\fR takes one of the
  following values:
  .RS 4
! .IP "\fBno\fR" 4
  .IX Item "no"
! Don't insert NOPs.
! .IP "\fBpad\fR" 4
  .IX Item "pad"
  Pad with NOPs any dispatch group that has vacant issue slots,
! according to the scheduler's grouping.
! .IP "\fBregroup_exact\fR" 4
  .IX Item "regroup_exact"
  Insert NOPs to force costly dependent insns into
  separate groups.  Insert exactly as many NOPs as needed to force an insn
  to a new group, according to the estimated processor grouping.
! .IP "\fInumber\fR" 4
  .IX Item "number"
  Insert NOPs to force costly dependent insns into
  separate groups.  Insert \fInumber\fR NOPs to force an insn to a new group.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mcall\-sysv\fR" 4
  .IX Item "-mcall-sysv"
  On System V.4 and embedded PowerPC systems compile code using calling
  conventions that adhere to the March 1995 draft of the System V
  Application Binary Interface, PowerPC processor supplement.  This is the
! default unless you configured \s-1GCC\s0 using \fBpowerpc\-*\-eabiaix\fR.
! .IP "\fB\-mcall\-sysv\-eabi\fR" 4
  .IX Item "-mcall-sysv-eabi"
  .PD 0
! .IP "\fB\-mcall\-eabi\fR" 4
  .IX Item "-mcall-eabi"
  .PD
  Specify both \fB\-mcall\-sysv\fR and \fB\-meabi\fR options.
! .IP "\fB\-mcall\-sysv\-noeabi\fR" 4
  .IX Item "-mcall-sysv-noeabi"
  Specify both \fB\-mcall\-sysv\fR and \fB\-mno\-eabi\fR options.
! .IP "\fB\-mcall\-aixdesc\fR" 4
  .IX Item "-mcall-aixdesc"
! On System V.4 and embedded PowerPC systems compile code for the \s-1AIX\s0
  operating system.
! .IP "\fB\-mcall\-linux\fR" 4
  .IX Item "-mcall-linux"
  On System V.4 and embedded PowerPC systems compile code for the
! Linux-based \s-1GNU\s0 system.
! .IP "\fB\-mcall\-freebsd\fR" 4
  .IX Item "-mcall-freebsd"
  On System V.4 and embedded PowerPC systems compile code for the
  FreeBSD operating system.
! .IP "\fB\-mcall\-netbsd\fR" 4
  .IX Item "-mcall-netbsd"
  On System V.4 and embedded PowerPC systems compile code for the
  NetBSD operating system.
! .IP "\fB\-mcall\-openbsd\fR" 4
  .IX Item "-mcall-openbsd"
  On System V.4 and embedded PowerPC systems compile code for the
  OpenBSD operating system.
! .IP "\fB\-mtraceback=\fR\fItraceback_type\fR" 4
  .IX Item "-mtraceback=traceback_type"
  Select the type of traceback table. Valid values for \fItraceback_type\fR
  are \fBfull\fR, \fBpart\fR, and \fBno\fR.
! .IP "\fB\-maix\-struct\-return\fR" 4
  .IX Item "-maix-struct-return"
! Return all structures in memory (as specified by the \s-1AIX ABI\s0).
! .IP "\fB\-msvr4\-struct\-return\fR" 4
  .IX Item "-msvr4-struct-return"
  Return structures smaller than 8 bytes in registers (as specified by the
! \&\s-1SVR4 ABI\s0).
! .IP "\fB\-mabi=\fR\fIabi-type\fR" 4
  .IX Item "-mabi=abi-type"
! Extend the current \s-1ABI\s0 with a particular extension, or remove such extension.
! Valid values are: \fBaltivec\fR, \fBno-altivec\fR,
  \&\fBibmlongdouble\fR, \fBieeelongdouble\fR,
  \&\fBelfv1\fR, \fBelfv2\fR,
! and for \s-1AIX:\s0 \fBvec-extabi\fR, \fBvec-default\fR.
! .IP "\fB\-mabi=ibmlongdouble\fR" 4
  .IX Item "-mabi=ibmlongdouble"
! Change the current \s-1ABI\s0 to use \s-1IBM\s0 extended-precision long double.
! This is not likely to work if your system defaults to using \s-1IEEE\s0
! extended-precision long double.  If you change the long double type
! from \s-1IEEE\s0 extended-precision, the compiler will issue a warning unless
  you use the \fB\-Wno\-psabi\fR option.  Requires \fB\-mlong\-double\-128\fR
  to be enabled.
! .IP "\fB\-mabi=ieeelongdouble\fR" 4
  .IX Item "-mabi=ieeelongdouble"
! Change the current \s-1ABI\s0 to use \s-1IEEE\s0 extended-precision long double.
! This is not likely to work if your system defaults to using \s-1IBM\s0
! extended-precision long double.  If you change the long double type
! from \s-1IBM\s0 extended-precision, the compiler will issue a warning unless
  you use the \fB\-Wno\-psabi\fR option.  Requires \fB\-mlong\-double\-128\fR
  to be enabled.
! .IP "\fB\-mabi=elfv1\fR" 4
  .IX Item "-mabi=elfv1"
! Change the current \s-1ABI\s0 to use the ELFv1 \s-1ABI.\s0
! This is the default \s-1ABI\s0 for big-endian PowerPC 64\-bit Linux.
! Overriding the default \s-1ABI\s0 requires special system support and is
  likely to fail in spectacular ways.
! .IP "\fB\-mabi=elfv2\fR" 4
  .IX Item "-mabi=elfv2"
! Change the current \s-1ABI\s0 to use the ELFv2 \s-1ABI.\s0
! This is the default \s-1ABI\s0 for little-endian PowerPC 64\-bit Linux.
! Overriding the default \s-1ABI\s0 requires special system support and is
  likely to fail in spectacular ways.
! .IP "\fB\-mgnu\-attribute\fR" 4
  .IX Item "-mgnu-attribute"
  .PD 0
! .IP "\fB\-mno\-gnu\-attribute\fR" 4
  .IX Item "-mno-gnu-attribute"
  .PD
  Emit .gnu_attribute assembly directives to set tag/value pairs in a
! \&.gnu.attributes section that specify \s-1ABI\s0 variations in function
  parameters or return values.
! .IP "\fB\-mprototype\fR" 4
  .IX Item "-mprototype"
  .PD 0
! .IP "\fB\-mno\-prototype\fR" 4
  .IX Item "-mno-prototype"
  .PD
  On System V.4 and embedded PowerPC systems assume that all calls to
  variable argument functions are properly prototyped.  Otherwise, the
! compiler must insert an instruction before every non-prototyped call to
  set or clear bit 6 of the condition code register (\f(CW\*(C`CR\*(C'\fR) to
! indicate whether floating-point values are passed in the floating-point
  registers in case the function takes variable arguments.  With
  \&\fB\-mprototype\fR, only calls to prototyped variable argument functions
  set or clear the bit.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIsim\-crt0.o\fR and that the standard C libraries are \fIlibsim.a\fR and
  \&\fIlibc.a\fR.  This is the default for \fBpowerpc\-*\-eabisim\fR
  configurations.
! .IP "\fB\-mmvme\fR" 4
  .IX Item "-mmvme"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibmvme.a\fR and
  \&\fIlibc.a\fR.
! .IP "\fB\-mads\fR" 4
  .IX Item "-mads"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibads.a\fR and
  \&\fIlibc.a\fR.
! .IP "\fB\-myellowknife\fR" 4
  .IX Item "-myellowknife"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibyk.a\fR and
  \&\fIlibc.a\fR.
! .IP "\fB\-mvxworks\fR" 4
  .IX Item "-mvxworks"
  On System V.4 and embedded PowerPC systems, specify that you are
  compiling for a VxWorks system.
! .IP "\fB\-memb\fR" 4
  .IX Item "-memb"
! On embedded PowerPC systems, set the \f(CW\*(C`PPC_EMB\*(C'\fR bit in the \s-1ELF\s0 flags
  header to indicate that \fBeabi\fR extended relocations are used.
! .IP "\fB\-meabi\fR" 4
  .IX Item "-meabi"
  .PD 0
! .IP "\fB\-mno\-eabi\fR" 4
  .IX Item "-mno-eabi"
  .PD
  On System V.4 and embedded PowerPC systems do (do not) adhere to the
! Embedded Applications Binary Interface (\s-1EABI\s0), which is a set of
  modifications to the System V.4 specifications.  Selecting \fB\-meabi\fR
  means that the stack is aligned to an 8\-byte boundary, a function
! \&\f(CW\*(C`_\|_eabi\*(C'\fR is called from \f(CW\*(C`main\*(C'\fR to set up the \s-1EABI\s0
  environment, and the \fB\-msdata\fR option can use both \f(CW\*(C`r2\*(C'\fR and
  \&\f(CW\*(C`r13\*(C'\fR to point to two separate small data areas.  Selecting
  \&\fB\-mno\-eabi\fR means that the stack is aligned to a 16\-byte boundary,
! no \s-1EABI\s0 initialization function is called from \f(CW\*(C`main\*(C'\fR, and the
  \&\fB\-msdata\fR option only uses \f(CW\*(C`r13\*(C'\fR to point to a single
  small data area.  The \fB\-meabi\fR option is on by default if you
! configured \s-1GCC\s0 using one of the \fBpowerpc*\-*\-eabi*\fR options.
! .IP "\fB\-msdata=eabi\fR" 4
  .IX Item "-msdata=eabi"
  On System V.4 and embedded PowerPC systems, put small initialized
  \&\f(CW\*(C`const\*(C'\fR global and static data in the \f(CW\*(C`.sdata2\*(C'\fR section, which
--- 28920,29175 ----
  alignment of \fB\-mrelocatable\fR.  Objects compiled with
  \&\fB\-mrelocatable\-lib\fR may be linked with objects compiled with
  any combination of the \fB\-mrelocatable\fR options.
! .IP \fB\-mno\-toc\fR 4
  .IX Item "-mno-toc"
  .PD 0
! .IP \fB\-mtoc\fR 4
  .IX Item "-mtoc"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) assume that
  register 2 contains a pointer to a global area pointing to the addresses
  used in the program.
! .IP \fB\-mlittle\fR 4
  .IX Item "-mlittle"
  .PD 0
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
  .PD
  On System V.4 and embedded PowerPC systems compile code for the
! processor in little\-endian mode.  The \fB\-mlittle\-endian\fR option is
  the same as \fB\-mlittle\fR.
! .IP \fB\-mbig\fR 4
  .IX Item "-mbig"
  .PD 0
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
  .PD
  On System V.4 and embedded PowerPC systems compile code for the
! processor in big\-endian mode.  The \fB\-mbig\-endian\fR option is
  the same as \fB\-mbig\fR.
! .IP \fB\-mdynamic\-no\-pic\fR 4
  .IX Item "-mdynamic-no-pic"
! On Darwin and Mac 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.
! .IP \fB\-msingle\-pic\-base\fR 4
  .IX Item "-msingle-pic-base"
! Treat the register used for PIC addressing as read\-only, rather than
  loading it in the prologue for each function.  The runtime system is
  responsible for initializing this register with an appropriate value
  before execution begins.
! .IP \fB\-mprioritize\-restricted\-insns=\fR\fIpriority\fR 4
  .IX Item "-mprioritize-restricted-insns=priority"
  This option controls the priority that is assigned to
! dispatch\-slot restricted instructions during the second scheduling
  pass.  The argument \fIpriority\fR takes the value \fB0\fR, \fB1\fR,
! or \fB2\fR to assign no, highest, or second\-highest (respectively) 
! priority to dispatch\-slot restricted
  instructions.
! .IP \fB\-msched\-costly\-dep=\fR\fIdependence_type\fR 4
  .IX Item "-msched-costly-dep=dependence_type"
  This option controls which dependences are considered costly
  by the target during instruction scheduling.  The argument
  \&\fIdependence_type\fR takes one of the following values:
  .RS 4
! .IP \fBno\fR 4
  .IX Item "no"
  No dependence is costly.
! .IP \fBall\fR 4
  .IX Item "all"
  All dependences are costly.
! .IP \fBtrue_store_to_load\fR 4
  .IX Item "true_store_to_load"
  A true dependence from store to load is costly.
! .IP \fBstore_to_load\fR 4
  .IX Item "store_to_load"
  Any dependence from store to load is costly.
! .IP \fInumber\fR 4
  .IX Item "number"
  Any dependence for which the latency is greater than or equal to 
  \&\fInumber\fR is costly.
  .RE
  .RS 4
  .RE
! .IP \fB\-minsert\-sched\-nops=\fR\fIscheme\fR 4
  .IX Item "-minsert-sched-nops=scheme"
! This option controls which NOP insertion scheme is used during
  the second scheduling pass.  The argument \fIscheme\fR takes one of the
  following values:
  .RS 4
! .IP \fBno\fR 4
  .IX Item "no"
! Don\*(Aqt insert NOPs.
! .IP \fBpad\fR 4
  .IX Item "pad"
  Pad with NOPs any dispatch group that has vacant issue slots,
! according to the scheduler\*(Aqs grouping.
! .IP \fBregroup_exact\fR 4
  .IX Item "regroup_exact"
  Insert NOPs to force costly dependent insns into
  separate groups.  Insert exactly as many NOPs as needed to force an insn
  to a new group, according to the estimated processor grouping.
! .IP \fInumber\fR 4
  .IX Item "number"
  Insert NOPs to force costly dependent insns into
  separate groups.  Insert \fInumber\fR NOPs to force an insn to a new group.
  .RE
  .RS 4
  .RE
! .IP \fB\-mcall\-sysv\fR 4
  .IX Item "-mcall-sysv"
  On System V.4 and embedded PowerPC systems compile code using calling
  conventions that adhere to the March 1995 draft of the System V
  Application Binary Interface, PowerPC processor supplement.  This is the
! default unless you configured GCC using \fBpowerpc\-*\-eabiaix\fR.
! .IP \fB\-mcall\-sysv\-eabi\fR 4
  .IX Item "-mcall-sysv-eabi"
  .PD 0
! .IP \fB\-mcall\-eabi\fR 4
  .IX Item "-mcall-eabi"
  .PD
  Specify both \fB\-mcall\-sysv\fR and \fB\-meabi\fR options.
! .IP \fB\-mcall\-sysv\-noeabi\fR 4
  .IX Item "-mcall-sysv-noeabi"
  Specify both \fB\-mcall\-sysv\fR and \fB\-mno\-eabi\fR options.
! .IP \fB\-mcall\-aixdesc\fR 4
  .IX Item "-mcall-aixdesc"
! On System V.4 and embedded PowerPC systems compile code for the AIX
  operating system.
! .IP \fB\-mcall\-linux\fR 4
  .IX Item "-mcall-linux"
  On System V.4 and embedded PowerPC systems compile code for the
! Linux\-based GNU system.
! .IP \fB\-mcall\-freebsd\fR 4
  .IX Item "-mcall-freebsd"
  On System V.4 and embedded PowerPC systems compile code for the
  FreeBSD operating system.
! .IP \fB\-mcall\-netbsd\fR 4
  .IX Item "-mcall-netbsd"
  On System V.4 and embedded PowerPC systems compile code for the
  NetBSD operating system.
! .IP \fB\-mcall\-openbsd\fR 4
  .IX Item "-mcall-openbsd"
  On System V.4 and embedded PowerPC systems compile code for the
  OpenBSD operating system.
! .IP \fB\-mtraceback=\fR\fItraceback_type\fR 4
  .IX Item "-mtraceback=traceback_type"
  Select the type of traceback table. Valid values for \fItraceback_type\fR
  are \fBfull\fR, \fBpart\fR, and \fBno\fR.
! .IP \fB\-maix\-struct\-return\fR 4
  .IX Item "-maix-struct-return"
! Return all structures in memory (as specified by the AIX ABI).
! .IP \fB\-msvr4\-struct\-return\fR 4
  .IX Item "-msvr4-struct-return"
  Return structures smaller than 8 bytes in registers (as specified by the
! SVR4 ABI).
! .IP \fB\-mabi=\fR\fIabi\-type\fR 4
  .IX Item "-mabi=abi-type"
! Extend the current ABI with a particular extension, or remove such extension.
! Valid values are: \fBaltivec\fR, \fBno\-altivec\fR,
  \&\fBibmlongdouble\fR, \fBieeelongdouble\fR,
  \&\fBelfv1\fR, \fBelfv2\fR,
! and for AIX: \fBvec\-extabi\fR, \fBvec\-default\fR.
! .IP \fB\-mabi=ibmlongdouble\fR 4
  .IX Item "-mabi=ibmlongdouble"
! Change the current ABI to use IBM extended\-precision long double.
! This is not likely to work if your system defaults to using IEEE
! extended\-precision long double.  If you change the long double type
! from IEEE extended\-precision, the compiler will issue a warning unless
  you use the \fB\-Wno\-psabi\fR option.  Requires \fB\-mlong\-double\-128\fR
  to be enabled.
! .IP \fB\-mabi=ieeelongdouble\fR 4
  .IX Item "-mabi=ieeelongdouble"
! Change the current ABI to use IEEE extended\-precision long double.
! This is not likely to work if your system defaults to using IBM
! extended\-precision long double.  If you change the long double type
! from IBM extended\-precision, the compiler will issue a warning unless
  you use the \fB\-Wno\-psabi\fR option.  Requires \fB\-mlong\-double\-128\fR
  to be enabled.
! .IP \fB\-mabi=elfv1\fR 4
  .IX Item "-mabi=elfv1"
! Change the current ABI to use the ELFv1 ABI.
! This is the default ABI for big\-endian PowerPC 64\-bit Linux.
! Overriding the default ABI requires special system support and is
  likely to fail in spectacular ways.
! .IP \fB\-mabi=elfv2\fR 4
  .IX Item "-mabi=elfv2"
! Change the current ABI to use the ELFv2 ABI.
! This is the default ABI for little\-endian PowerPC 64\-bit Linux.
! Overriding the default ABI requires special system support and is
  likely to fail in spectacular ways.
! .IP \fB\-mgnu\-attribute\fR 4
  .IX Item "-mgnu-attribute"
  .PD 0
! .IP \fB\-mno\-gnu\-attribute\fR 4
  .IX Item "-mno-gnu-attribute"
  .PD
  Emit .gnu_attribute assembly directives to set tag/value pairs in a
! \&.gnu.attributes section that specify ABI variations in function
  parameters or return values.
! .IP \fB\-mprototype\fR 4
  .IX Item "-mprototype"
  .PD 0
! .IP \fB\-mno\-prototype\fR 4
  .IX Item "-mno-prototype"
  .PD
  On System V.4 and embedded PowerPC systems assume that all calls to
  variable argument functions are properly prototyped.  Otherwise, the
! compiler must insert an instruction before every non\-prototyped call to
  set or clear bit 6 of the condition code register (\f(CW\*(C`CR\*(C'\fR) to
! indicate whether floating\-point values are passed in the floating\-point
  registers in case the function takes variable arguments.  With
  \&\fB\-mprototype\fR, only calls to prototyped variable argument functions
  set or clear the bit.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIsim\-crt0.o\fR and that the standard C libraries are \fIlibsim.a\fR and
  \&\fIlibc.a\fR.  This is the default for \fBpowerpc\-*\-eabisim\fR
  configurations.
! .IP \fB\-mmvme\fR 4
  .IX Item "-mmvme"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibmvme.a\fR and
  \&\fIlibc.a\fR.
! .IP \fB\-mads\fR 4
  .IX Item "-mads"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibads.a\fR and
  \&\fIlibc.a\fR.
! .IP \fB\-myellowknife\fR 4
  .IX Item "-myellowknife"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibyk.a\fR and
  \&\fIlibc.a\fR.
! .IP \fB\-mvxworks\fR 4
  .IX Item "-mvxworks"
  On System V.4 and embedded PowerPC systems, specify that you are
  compiling for a VxWorks system.
! .IP \fB\-memb\fR 4
  .IX Item "-memb"
! On embedded PowerPC systems, set the \f(CW\*(C`PPC_EMB\*(C'\fR bit in the ELF flags
  header to indicate that \fBeabi\fR extended relocations are used.
! .IP \fB\-meabi\fR 4
  .IX Item "-meabi"
  .PD 0
! .IP \fB\-mno\-eabi\fR 4
  .IX Item "-mno-eabi"
  .PD
  On System V.4 and embedded PowerPC systems do (do not) adhere to the
! Embedded Applications Binary Interface (EABI), which is a set of
  modifications to the System V.4 specifications.  Selecting \fB\-meabi\fR
  means that the stack is aligned to an 8\-byte boundary, a function
! \&\f(CW\*(C`_\|_eabi\*(C'\fR is called from \f(CW\*(C`main\*(C'\fR to set up the EABI
  environment, and the \fB\-msdata\fR option can use both \f(CW\*(C`r2\*(C'\fR and
  \&\f(CW\*(C`r13\*(C'\fR to point to two separate small data areas.  Selecting
  \&\fB\-mno\-eabi\fR means that the stack is aligned to a 16\-byte boundary,
! no EABI initialization function is called from \f(CW\*(C`main\*(C'\fR, and the
  \&\fB\-msdata\fR option only uses \f(CW\*(C`r13\*(C'\fR to point to a single
  small data area.  The \fB\-meabi\fR option is on by default if you
! configured GCC using one of the \fBpowerpc*\-*\-eabi*\fR options.
! .IP \fB\-msdata=eabi\fR 4
  .IX Item "-msdata=eabi"
  On System V.4 and embedded PowerPC systems, put small initialized
  \&\f(CW\*(C`const\*(C'\fR global and static data in the \f(CW\*(C`.sdata2\*(C'\fR section, which
*************** global and static data in the \f(CW\*(C`
*** 29249,29255 ****
  the \f(CW\*(C`.sdata\*(C'\fR section.  The \fB\-msdata=eabi\fR option is
  incompatible with the \fB\-mrelocatable\fR option.  The
  \&\fB\-msdata=eabi\fR option also sets the \fB\-memb\fR option.
! .IP "\fB\-msdata=sysv\fR" 4
  .IX Item "-msdata=sysv"
  On System V.4 and embedded PowerPC systems, put small global and static
  data in the \f(CW\*(C`.sdata\*(C'\fR section, which is pointed to by register
--- 29180,29186 ----
  the \f(CW\*(C`.sdata\*(C'\fR section.  The \fB\-msdata=eabi\fR option is
  incompatible with the \fB\-mrelocatable\fR option.  The
  \&\fB\-msdata=eabi\fR option also sets the \fB\-memb\fR option.
! .IP \fB\-msdata=sysv\fR 4
  .IX Item "-msdata=sysv"
  On System V.4 and embedded PowerPC systems, put small global and static
  data in the \f(CW\*(C`.sdata\*(C'\fR section, which is pointed to by register
*************** data in the \f(CW\*(C`.sdata\*(C'\fR sec
*** 29257,29312 ****
  \&\f(CW\*(C`.sbss\*(C'\fR section, which is adjacent to the \f(CW\*(C`.sdata\*(C'\fR section.
  The \fB\-msdata=sysv\fR option is incompatible with the
  \&\fB\-mrelocatable\fR option.
! .IP "\fB\-msdata=default\fR" 4
  .IX Item "-msdata=default"
  .PD 0
! .IP "\fB\-msdata\fR" 4
  .IX Item "-msdata"
  .PD
  On System V.4 and embedded PowerPC systems, if \fB\-meabi\fR is used,
  compile code the same as \fB\-msdata=eabi\fR, otherwise compile code the
  same as \fB\-msdata=sysv\fR.
! .IP "\fB\-msdata=data\fR" 4
  .IX Item "-msdata=data"
  On System V.4 and embedded PowerPC systems, put small global
  data in the \f(CW\*(C`.sdata\*(C'\fR section.  Put small uninitialized global
  data in the \f(CW\*(C`.sbss\*(C'\fR section.  Do not use register \f(CW\*(C`r13\*(C'\fR
  to address small data however.  This is the default behavior unless
  other \fB\-msdata\fR options are used.
! .IP "\fB\-msdata=none\fR" 4
  .IX Item "-msdata=none"
  .PD 0
! .IP "\fB\-mno\-sdata\fR" 4
  .IX Item "-mno-sdata"
  .PD
  On embedded PowerPC systems, put all initialized global and static data
  in the \f(CW\*(C`.data\*(C'\fR section, and all uninitialized data in the
  \&\f(CW\*(C`.bss\*(C'\fR section.
! .IP "\fB\-mreadonly\-in\-sdata\fR" 4
  .IX Item "-mreadonly-in-sdata"
! Put read-only objects in the \f(CW\*(C`.sdata\*(C'\fR section as well.  This is the
  default.
! .IP "\fB\-mblock\-move\-inline\-limit=\fR\fInum\fR" 4
  .IX Item "-mblock-move-inline-limit=num"
  Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure
  copies) less than or equal to \fInum\fR bytes.  The minimum value for
  \&\fInum\fR is 32 bytes on 32\-bit targets and 64 bytes on 64\-bit
! targets.  The default value is target-specific.
! .IP "\fB\-mblock\-compare\-inline\-limit=\fR\fInum\fR" 4
  .IX Item "-mblock-compare-inline-limit=num"
! Generate non-looping inline code for all block compares (such as calls
  to \f(CW\*(C`memcmp\*(C'\fR or structure compares) less than or equal to \fInum\fR
! bytes. If \fInum\fR is 0, all inline expansion (non-loop and loop) of
! block compare is disabled. The default value is target-specific.
! .IP "\fB\-mblock\-compare\-inline\-loop\-limit=\fR\fInum\fR" 4
  .IX Item "-mblock-compare-inline-loop-limit=num"
  Generate an inline expansion using loop code for all block compares that
  are less than or equal to \fInum\fR bytes, but greater than the limit
! for non-loop inline block compare expansion. If the block length is not
  constant, at most \fInum\fR bytes will be compared before \f(CW\*(C`memcmp\*(C'\fR
  is called to compare the remainder of the block. The default value is
! target-specific.
! .IP "\fB\-mstring\-compare\-inline\-limit=\fR\fInum\fR" 4
  .IX Item "-mstring-compare-inline-limit=num"
  Compare at most \fInum\fR string bytes with inline code.
  If the difference or end of string is not found at the
--- 29188,29243 ----
  \&\f(CW\*(C`.sbss\*(C'\fR section, which is adjacent to the \f(CW\*(C`.sdata\*(C'\fR section.
  The \fB\-msdata=sysv\fR option is incompatible with the
  \&\fB\-mrelocatable\fR option.
! .IP \fB\-msdata=default\fR 4
  .IX Item "-msdata=default"
  .PD 0
! .IP \fB\-msdata\fR 4
  .IX Item "-msdata"
  .PD
  On System V.4 and embedded PowerPC systems, if \fB\-meabi\fR is used,
  compile code the same as \fB\-msdata=eabi\fR, otherwise compile code the
  same as \fB\-msdata=sysv\fR.
! .IP \fB\-msdata=data\fR 4
  .IX Item "-msdata=data"
  On System V.4 and embedded PowerPC systems, put small global
  data in the \f(CW\*(C`.sdata\*(C'\fR section.  Put small uninitialized global
  data in the \f(CW\*(C`.sbss\*(C'\fR section.  Do not use register \f(CW\*(C`r13\*(C'\fR
  to address small data however.  This is the default behavior unless
  other \fB\-msdata\fR options are used.
! .IP \fB\-msdata=none\fR 4
  .IX Item "-msdata=none"
  .PD 0
! .IP \fB\-mno\-sdata\fR 4
  .IX Item "-mno-sdata"
  .PD
  On embedded PowerPC systems, put all initialized global and static data
  in the \f(CW\*(C`.data\*(C'\fR section, and all uninitialized data in the
  \&\f(CW\*(C`.bss\*(C'\fR section.
! .IP \fB\-mreadonly\-in\-sdata\fR 4
  .IX Item "-mreadonly-in-sdata"
! Put read\-only objects in the \f(CW\*(C`.sdata\*(C'\fR section as well.  This is the
  default.
! .IP \fB\-mblock\-move\-inline\-limit=\fR\fInum\fR 4
  .IX Item "-mblock-move-inline-limit=num"
  Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure
  copies) less than or equal to \fInum\fR bytes.  The minimum value for
  \&\fInum\fR is 32 bytes on 32\-bit targets and 64 bytes on 64\-bit
! targets.  The default value is target\-specific.
! .IP \fB\-mblock\-compare\-inline\-limit=\fR\fInum\fR 4
  .IX Item "-mblock-compare-inline-limit=num"
! Generate non\-looping inline code for all block compares (such as calls
  to \f(CW\*(C`memcmp\*(C'\fR or structure compares) less than or equal to \fInum\fR
! bytes. If \fInum\fR is 0, all inline expansion (non\-loop and loop) of
! block compare is disabled. The default value is target\-specific.
! .IP \fB\-mblock\-compare\-inline\-loop\-limit=\fR\fInum\fR 4
  .IX Item "-mblock-compare-inline-loop-limit=num"
  Generate an inline expansion using loop code for all block compares that
  are less than or equal to \fInum\fR bytes, but greater than the limit
! for non\-loop inline block compare expansion. If the block length is not
  constant, at most \fInum\fR bytes will be compared before \f(CW\*(C`memcmp\*(C'\fR
  is called to compare the remainder of the block. The default value is
! target\-specific.
! .IP \fB\-mstring\-compare\-inline\-limit=\fR\fInum\fR 4
  .IX Item "-mstring-compare-inline-limit=num"
  Compare at most \fInum\fR string bytes with inline code.
  If the difference or end of string is not found at the
*************** take care of the rest of the comparison.
*** 29315,29336 ****
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  On embedded PowerPC systems, put global and static items less than or
! equal to \fInum\fR bytes into the small data or \s-1BSS\s0 sections instead of
! the normal data or \s-1BSS\s0 section.  By default, \fInum\fR is 8.  The
  \&\fB\-G\fR \fInum\fR switch is also passed to the linker.
  All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
! .IP "\fB\-mregnames\fR" 4
  .IX Item "-mregnames"
  .PD 0
! .IP "\fB\-mno\-regnames\fR" 4
  .IX Item "-mno-regnames"
  .PD
  On System V.4 and embedded PowerPC systems do (do not) emit register
  names in the assembly language output using symbolic forms.
! .IP "\fB\-mlongcall\fR" 4
  .IX Item "-mlongcall"
  .PD 0
! .IP "\fB\-mno\-longcall\fR" 4
  .IX Item "-mno-longcall"
  .PD
  By default assume that all calls are far away so that a longer and more
--- 29246,29267 ----
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  On embedded PowerPC systems, put global and static items less than or
! equal to \fInum\fR bytes into the small data or BSS sections instead of
! the normal data or BSS section.  By default, \fInum\fR is 8.  The
  \&\fB\-G\fR \fInum\fR switch is also passed to the linker.
  All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
! .IP \fB\-mregnames\fR 4
  .IX Item "-mregnames"
  .PD 0
! .IP \fB\-mno\-regnames\fR 4
  .IX Item "-mno-regnames"
  .PD
  On System V.4 and embedded PowerPC systems do (do not) emit register
  names in the assembly language output using symbolic forms.
! .IP \fB\-mlongcall\fR 4
  .IX Item "-mlongcall"
  .PD 0
! .IP \fB\-mno\-longcall\fR 4
  .IX Item "-mno-longcall"
  .PD
  By default assume that all calls are far away so that a longer and more
*************** expensive calling sequence is required.
*** 29338,29480 ****
  farther than 32 megabytes (33,554,432 bytes) from the current location.
  A short call is generated if the compiler knows
  the call cannot be that far away.  This setting can be overridden by
! the \f(CW\*(C`shortcall\*(C'\fR function attribute, or by \f(CW\*(C`#pragma
! longcall(0)\*(C'\fR.
  .Sp
! Some linkers are capable of detecting out-of-range calls and generating
  glue code on the fly.  On these systems, long calls are unnecessary and
! generate slower code.  As of this writing, the \s-1AIX\s0 linker can do this,
! as can the \s-1GNU\s0 linker for PowerPC/64.  It is planned to add this feature
! to the \s-1GNU\s0 linker for 32\-bit PowerPC systems as well.
  .Sp
! On PowerPC64 ELFv2 and 32\-bit PowerPC systems with newer \s-1GNU\s0 linkers,
! \&\s-1GCC\s0 can generate long calls using an inline \s-1PLT\s0 call sequence (see
  \&\fB\-mpltseq\fR).  PowerPC with \fB\-mbss\-plt\fR and PowerPC64
! ELFv1 (big-endian) do not support inline \s-1PLT\s0 calls.
  .Sp
  On Darwin/PPC systems, \f(CW\*(C`#pragma longcall\*(C'\fR generates \f(CW\*(C`jbsr
  callee, L42\*(C'\fR, plus a \fIbranch island\fR (glue code).  The two target
  addresses represent the callee and the branch island.  The
  Darwin/PPC linker prefers the first address and generates a \f(CW\*(C`bl
! callee\*(C'\fR if the \s-1PPC\s0 \f(CW\*(C`bl\*(C'\fR instruction reaches the callee directly;
  otherwise, the linker generates \f(CW\*(C`bl L42\*(C'\fR to call the branch
  island.  The branch island is appended to the body of the
  calling function; it computes the full 32\-bit address of the callee
  and jumps to it.
  .Sp
! On Mach-O (Darwin) systems, this option directs the compiler emit to
  the glue for every direct call, and the Darwin linker decides whether
  to use or discard it.
  .Sp
! In the future, \s-1GCC\s0 may ignore all longcall specifications
  when the linker is known to generate glue.
! .IP "\fB\-mpltseq\fR" 4
  .IX Item "-mpltseq"
  .PD 0
! .IP "\fB\-mno\-pltseq\fR" 4
  .IX Item "-mno-pltseq"
  .PD
  Implement (do not implement) \-fno\-plt and long calls using an inline
! \&\s-1PLT\s0 call sequence that supports lazy linking and long calls to
! functions in dlopen'd shared libraries.  Inline \s-1PLT\s0 calls are only
! supported on PowerPC64 ELFv2 and 32\-bit PowerPC systems with newer \s-1GNU\s0
  linkers, and are enabled by default if the support is detected when
! configuring \s-1GCC,\s0 and, in the case of 32\-bit PowerPC, if \s-1GCC\s0 is
  configured with \fB\-\-enable\-secureplt\fR.  \fB\-mpltseq\fR code
  and \fB\-mbss\-plt\fR 32\-bit PowerPC relocatable objects may not be
  linked together.
! .IP "\fB\-mtls\-markers\fR" 4
  .IX Item "-mtls-markers"
  .PD 0
! .IP "\fB\-mno\-tls\-markers\fR" 4
  .IX Item "-mno-tls-markers"
  .PD
  Mark (do not mark) calls to \f(CW\*(C`_\|_tls_get_addr\*(C'\fR with a relocation
  specifying the function argument.  The relocation allows the linker to
  reliably associate function call with argument setup instructions for
! \&\s-1TLS\s0 optimization, which in turn allows \s-1GCC\s0 to better schedule the
  sequence.
! .IP "\fB\-mrecip\fR" 4
  .IX Item "-mrecip"
  .PD 0
! .IP "\fB\-mno\-recip\fR" 4
  .IX Item "-mno-recip"
  .PD
  This option enables use of the reciprocal estimate and
  reciprocal square root estimate instructions with additional
! Newton-Raphson steps to increase precision instead of doing a divide or
! square root and divide for floating-point arguments.  You should use
  the \fB\-ffast\-math\fR option when using \fB\-mrecip\fR (or at
  least \fB\-funsafe\-math\-optimizations\fR,
  \&\fB\-ffinite\-math\-only\fR, \fB\-freciprocal\-math\fR and
  \&\fB\-fno\-trapping\-math\fR).  Note that while the throughput of the
! sequence is generally higher than the throughput of the non-reciprocal
  instruction, the precision of the sequence can be decreased by up to 2
  ulp (i.e. the inverse of 1.0 equals 0.99999994) for reciprocal square
  roots.
! .IP "\fB\-mrecip=\fR\fIopt\fR" 4
  .IX Item "-mrecip=opt"
  This option controls which reciprocal estimate instructions
! may be used.  \fIopt\fR is a comma-separated list of options, which may
  be preceded by a \f(CW\*(C`!\*(C'\fR to invert the option:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
  Enable all estimate instructions.
! .IP "\fBdefault\fR" 4
  .IX Item "default"
  Enable the default instructions, equivalent to \fB\-mrecip\fR.
! .IP "\fBnone\fR" 4
  .IX Item "none"
  Disable all estimate instructions, equivalent to \fB\-mno\-recip\fR.
! .IP "\fBdiv\fR" 4
  .IX Item "div"
  Enable the reciprocal approximation instructions for both 
  single and double precision.
! .IP "\fBdivf\fR" 4
  .IX Item "divf"
! Enable the single-precision reciprocal approximation instructions.
! .IP "\fBdivd\fR" 4
  .IX Item "divd"
! Enable the double-precision reciprocal approximation instructions.
! .IP "\fBrsqrt\fR" 4
  .IX Item "rsqrt"
  Enable the reciprocal square root approximation instructions for both
  single and double precision.
! .IP "\fBrsqrtf\fR" 4
  .IX Item "rsqrtf"
! Enable the single-precision reciprocal square root approximation instructions.
! .IP "\fBrsqrtd\fR" 4
  .IX Item "rsqrtd"
! Enable the double-precision reciprocal square root approximation instructions.
  .RE
  .RS 4
  .Sp
  So, for example, \fB\-mrecip=all,!rsqrtd\fR enables
  all of the reciprocal estimate instructions, except for the
  \&\f(CW\*(C`FRSQRTE\*(C'\fR, \f(CW\*(C`XSRSQRTEDP\*(C'\fR, and \f(CW\*(C`XVRSQRTEDP\*(C'\fR instructions
! which handle the double-precision reciprocal square root calculations.
  .RE
! .IP "\fB\-mrecip\-precision\fR" 4
  .IX Item "-mrecip-precision"
  .PD 0
! .IP "\fB\-mno\-recip\-precision\fR" 4
  .IX Item "-mno-recip-precision"
  .PD
  Assume (do not assume) that the reciprocal estimate instructions
! provide higher-precision estimates than is mandated by the PowerPC
! \&\s-1ABI.\s0  Selecting \fB\-mcpu=power6\fR, \fB\-mcpu=power7\fR or
  \&\fB\-mcpu=power8\fR automatically selects \fB\-mrecip\-precision\fR.
! The double-precision square root estimate instructions are not generated by
! default on low-precision machines, since they do not provide an
  estimate that converges after three steps.
! .IP "\fB\-mveclibabi=\fR\fItype\fR" 4
  .IX Item "-mveclibabi=type"
! Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
  external library.  The only type supported at present is \fBmass\fR,
! which specifies to use \s-1IBM\s0's Mathematical Acceleration Subsystem
! (\s-1MASS\s0) libraries for vectorizing intrinsics using external libraries.
! \&\s-1GCC\s0 currently emits calls to \f(CW\*(C`acosd2\*(C'\fR, \f(CW\*(C`acosf4\*(C'\fR,
  \&\f(CW\*(C`acoshd2\*(C'\fR, \f(CW\*(C`acoshf4\*(C'\fR, \f(CW\*(C`asind2\*(C'\fR, \f(CW\*(C`asinf4\*(C'\fR,
  \&\f(CW\*(C`asinhd2\*(C'\fR, \f(CW\*(C`asinhf4\*(C'\fR, \f(CW\*(C`atan2d2\*(C'\fR, \f(CW\*(C`atan2f4\*(C'\fR,
  \&\f(CW\*(C`atand2\*(C'\fR, \f(CW\*(C`atanf4\*(C'\fR, \f(CW\*(C`atanhd2\*(C'\fR, \f(CW\*(C`atanhf4\*(C'\fR,
--- 29269,29411 ----
  farther than 32 megabytes (33,554,432 bytes) from the current location.
  A short call is generated if the compiler knows
  the call cannot be that far away.  This setting can be overridden by
! the \f(CW\*(C`shortcall\*(C'\fR function attribute, or by \f(CW#pragma
! longcall(0)\fR.
  .Sp
! Some linkers are capable of detecting out\-of\-range calls and generating
  glue code on the fly.  On these systems, long calls are unnecessary and
! generate slower code.  As of this writing, the 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.
  .Sp
! On PowerPC64 ELFv2 and 32\-bit PowerPC systems with newer GNU linkers,
! GCC can generate long calls using an inline PLT call sequence (see
  \&\fB\-mpltseq\fR).  PowerPC with \fB\-mbss\-plt\fR and PowerPC64
! ELFv1 (big\-endian) do not support inline PLT calls.
  .Sp
  On Darwin/PPC systems, \f(CW\*(C`#pragma longcall\*(C'\fR generates \f(CW\*(C`jbsr
  callee, L42\*(C'\fR, plus a \fIbranch island\fR (glue code).  The two target
  addresses represent the callee and the branch island.  The
  Darwin/PPC linker prefers the first address and generates a \f(CW\*(C`bl
! callee\*(C'\fR if the PPC \f(CW\*(C`bl\*(C'\fR instruction reaches the callee directly;
  otherwise, the linker generates \f(CW\*(C`bl L42\*(C'\fR to call the branch
  island.  The branch island is appended to the body of the
  calling function; it computes the full 32\-bit address of the callee
  and jumps to it.
  .Sp
! On Mach\-O (Darwin) systems, this option directs the compiler emit to
  the glue for every direct call, and the Darwin linker decides whether
  to use or discard it.
  .Sp
! In the future, GCC may ignore all longcall specifications
  when the linker is known to generate glue.
! .IP \fB\-mpltseq\fR 4
  .IX Item "-mpltseq"
  .PD 0
! .IP \fB\-mno\-pltseq\fR 4
  .IX Item "-mno-pltseq"
  .PD
  Implement (do not implement) \-fno\-plt and long calls using an inline
! PLT call sequence that supports lazy linking and long calls to
! functions in dlopen\*(Aqd shared libraries.  Inline PLT calls are only
! supported on PowerPC64 ELFv2 and 32\-bit PowerPC systems with newer GNU
  linkers, and are enabled by default if the support is detected when
! configuring GCC, and, in the case of 32\-bit PowerPC, if GCC is
  configured with \fB\-\-enable\-secureplt\fR.  \fB\-mpltseq\fR code
  and \fB\-mbss\-plt\fR 32\-bit PowerPC relocatable objects may not be
  linked together.
! .IP \fB\-mtls\-markers\fR 4
  .IX Item "-mtls-markers"
  .PD 0
! .IP \fB\-mno\-tls\-markers\fR 4
  .IX Item "-mno-tls-markers"
  .PD
  Mark (do not mark) calls to \f(CW\*(C`_\|_tls_get_addr\*(C'\fR with a relocation
  specifying the function argument.  The relocation allows the linker to
  reliably associate function call with argument setup instructions for
! TLS optimization, which in turn allows GCC to better schedule the
  sequence.
! .IP \fB\-mrecip\fR 4
  .IX Item "-mrecip"
  .PD 0
! .IP \fB\-mno\-recip\fR 4
  .IX Item "-mno-recip"
  .PD
  This option enables use of the reciprocal estimate and
  reciprocal square root estimate instructions with additional
! Newton\-Raphson steps to increase precision instead of doing a divide or
! square root and divide for floating\-point arguments.  You should use
  the \fB\-ffast\-math\fR option when using \fB\-mrecip\fR (or at
  least \fB\-funsafe\-math\-optimizations\fR,
  \&\fB\-ffinite\-math\-only\fR, \fB\-freciprocal\-math\fR and
  \&\fB\-fno\-trapping\-math\fR).  Note that while the throughput of the
! sequence is generally higher than the throughput of the non\-reciprocal
  instruction, the precision of the sequence can be decreased by up to 2
  ulp (i.e. the inverse of 1.0 equals 0.99999994) for reciprocal square
  roots.
! .IP \fB\-mrecip=\fR\fIopt\fR 4
  .IX Item "-mrecip=opt"
  This option controls which reciprocal estimate instructions
! may be used.  \fIopt\fR is a comma\-separated list of options, which may
  be preceded by a \f(CW\*(C`!\*(C'\fR to invert the option:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
  Enable all estimate instructions.
! .IP \fBdefault\fR 4
  .IX Item "default"
  Enable the default instructions, equivalent to \fB\-mrecip\fR.
! .IP \fBnone\fR 4
  .IX Item "none"
  Disable all estimate instructions, equivalent to \fB\-mno\-recip\fR.
! .IP \fBdiv\fR 4
  .IX Item "div"
  Enable the reciprocal approximation instructions for both 
  single and double precision.
! .IP \fBdivf\fR 4
  .IX Item "divf"
! Enable the single\-precision reciprocal approximation instructions.
! .IP \fBdivd\fR 4
  .IX Item "divd"
! Enable the double\-precision reciprocal approximation instructions.
! .IP \fBrsqrt\fR 4
  .IX Item "rsqrt"
  Enable the reciprocal square root approximation instructions for both
  single and double precision.
! .IP \fBrsqrtf\fR 4
  .IX Item "rsqrtf"
! Enable the single\-precision reciprocal square root approximation instructions.
! .IP \fBrsqrtd\fR 4
  .IX Item "rsqrtd"
! Enable the double\-precision reciprocal square root approximation instructions.
  .RE
  .RS 4
  .Sp
  So, for example, \fB\-mrecip=all,!rsqrtd\fR enables
  all of the reciprocal estimate instructions, except for the
  \&\f(CW\*(C`FRSQRTE\*(C'\fR, \f(CW\*(C`XSRSQRTEDP\*(C'\fR, and \f(CW\*(C`XVRSQRTEDP\*(C'\fR instructions
! which handle the double\-precision reciprocal square root calculations.
  .RE
! .IP \fB\-mrecip\-precision\fR 4
  .IX Item "-mrecip-precision"
  .PD 0
! .IP \fB\-mno\-recip\-precision\fR 4
  .IX Item "-mno-recip-precision"
  .PD
  Assume (do not assume) that the reciprocal estimate instructions
! provide higher\-precision estimates than is mandated by the PowerPC
! ABI.  Selecting \fB\-mcpu=power6\fR, \fB\-mcpu=power7\fR or
  \&\fB\-mcpu=power8\fR automatically selects \fB\-mrecip\-precision\fR.
! The double\-precision square root estimate instructions are not generated by
! default on low\-precision machines, since they do not provide an
  estimate that converges after three steps.
! .IP \fB\-mveclibabi=\fR\fItype\fR 4
  .IX Item "-mveclibabi=type"
! Specifies the ABI type to use for vectorizing intrinsics using an
  external library.  The only type supported at present is \fBmass\fR,
! which specifies to use IBM\*(Aqs Mathematical Acceleration Subsystem
! (MASS) libraries for vectorizing intrinsics using external libraries.
! GCC currently emits calls to \f(CW\*(C`acosd2\*(C'\fR, \f(CW\*(C`acosf4\*(C'\fR,
  \&\f(CW\*(C`acoshd2\*(C'\fR, \f(CW\*(C`acoshf4\*(C'\fR, \f(CW\*(C`asind2\*(C'\fR, \f(CW\*(C`asinf4\*(C'\fR,
  \&\f(CW\*(C`asinhd2\*(C'\fR, \f(CW\*(C`asinhf4\*(C'\fR, \f(CW\*(C`atan2d2\*(C'\fR, \f(CW\*(C`atan2f4\*(C'\fR,
  \&\f(CW\*(C`atand2\*(C'\fR, \f(CW\*(C`atanf4\*(C'\fR, \f(CW\*(C`atanhd2\*(C'\fR, \f(CW\*(C`atanhf4\*(C'\fR,
*************** which specifies to use \s-1IBM\s0's Math
*** 29489,29619 ****
  \&\f(CW\*(C`sinhf4\*(C'\fR, \f(CW\*(C`sqrtd2\*(C'\fR, \f(CW\*(C`sqrtf4\*(C'\fR, \f(CW\*(C`tand2\*(C'\fR,
  \&\f(CW\*(C`tanf4\*(C'\fR, \f(CW\*(C`tanhd2\*(C'\fR, and \f(CW\*(C`tanhf4\*(C'\fR when generating code
  for power7.  Both \fB\-ftree\-vectorize\fR and
! \&\fB\-funsafe\-math\-optimizations\fR must also be enabled.  The \s-1MASS\s0
  libraries must be specified at link time.
! .IP "\fB\-mfriz\fR" 4
  .IX Item "-mfriz"
  .PD 0
! .IP "\fB\-mno\-friz\fR" 4
  .IX Item "-mno-friz"
  .PD
  Generate (do not generate) the \f(CW\*(C`friz\*(C'\fR instruction when the
  \&\fB\-funsafe\-math\-optimizations\fR option is used to optimize
! rounding of floating-point values to 64\-bit integer and back to floating
  point.  The \f(CW\*(C`friz\*(C'\fR instruction does not return the same value if
! the floating-point number is too large to fit in an integer.
! .IP "\fB\-mpointers\-to\-nested\-functions\fR" 4
  .IX Item "-mpointers-to-nested-functions"
  .PD 0
! .IP "\fB\-mno\-pointers\-to\-nested\-functions\fR" 4
  .IX Item "-mno-pointers-to-nested-functions"
  .PD
  Generate (do not generate) code to load up the static chain register
! (\f(CW\*(C`r11\*(C'\fR) when calling through a pointer on \s-1AIX\s0 and 64\-bit Linux
  systems where a function pointer points to a 3\-word descriptor giving
! the function address, \s-1TOC\s0 value to be loaded in register \f(CW\*(C`r2\*(C'\fR, and
  static chain value to be loaded in register \f(CW\*(C`r11\*(C'\fR.  The
  \&\fB\-mpointers\-to\-nested\-functions\fR is on by default.  You cannot
  call through pointers to nested functions or pointers
  to functions compiled in other languages that use the static chain if
  you use \fB\-mno\-pointers\-to\-nested\-functions\fR.
! .IP "\fB\-msave\-toc\-indirect\fR" 4
  .IX Item "-msave-toc-indirect"
  .PD 0
! .IP "\fB\-mno\-save\-toc\-indirect\fR" 4
  .IX Item "-mno-save-toc-indirect"
  .PD
! Generate (do not generate) code to save the \s-1TOC\s0 value in the reserved
  stack location in the function prologue if the function calls through
! a pointer on \s-1AIX\s0 and 64\-bit Linux systems.  If the \s-1TOC\s0 value is not
  saved in the prologue, it is saved just before the call through the
  pointer.  The \fB\-mno\-save\-toc\-indirect\fR option is the default.
! .IP "\fB\-mcompat\-align\-parm\fR" 4
  .IX Item "-mcompat-align-parm"
  .PD 0
! .IP "\fB\-mno\-compat\-align\-parm\fR" 4
  .IX Item "-mno-compat-align-parm"
  .PD
  Generate (do not generate) code to pass structure parameters with a
  maximum alignment of 64 bits, for compatibility with older versions
! of \s-1GCC.\s0
  .Sp
! Older versions of \s-1GCC\s0 (prior to 4.9.0) incorrectly did not align a
  structure parameter on a 128\-bit boundary when that structure contained
  a member requiring 128\-bit alignment.  This is corrected in more
! recent versions of \s-1GCC.\s0  This option may be used to generate code
  that is compatible with functions compiled with older versions of
! \&\s-1GCC.\s0
  .Sp
  The \fB\-mno\-compat\-align\-parm\fR option is the default.
! .IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP "\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR" 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP "\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR" 4
  .IX Item "-mstack-protector-guard-offset=offset"
! .IP "\fB\-mstack\-protector\-guard\-symbol=\fR\fIsymbol\fR" 4
  .IX Item "-mstack-protector-guard-symbol=symbol"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for global canary or \fBtls\fR for per-thread
! canary in the \s-1TLS\s0 block (the default with \s-1GNU\s0 libc version 2.4 or later).
  .Sp
  With the latter choice the options
  \&\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR and
  \&\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR furthermore specify
  which register to use as base register for reading the canary, and from what
  offset from that base register. The default for those is as specified in the
! relevant \s-1ABI.\s0  \fB\-mstack\-protector\-guard\-symbol=\fR\fIsymbol\fR overrides
! the offset with a symbol reference to a canary in the \s-1TLS\s0 block.
! .IP "\fB\-mpcrel\fR" 4
  .IX Item "-mpcrel"
  .PD 0
! .IP "\fB\-mno\-pcrel\fR" 4
  .IX Item "-mno-pcrel"
  .PD
! Generate (do not generate) pc-relative addressing.  The \fB\-mpcrel\fR
  option requires that the medium code model (\fB\-mcmodel=medium\fR)
  and prefixed addressing (\fB\-mprefixed\fR) options are enabled.
! .IP "\fB\-mprefixed\fR" 4
  .IX Item "-mprefixed"
  .PD 0
! .IP "\fB\-mno\-prefixed\fR" 4
  .IX Item "-mno-prefixed"
  .PD
  Generate (do not generate) addressing modes using prefixed load and
  store instructions.  The \fB\-mprefixed\fR option requires that
  the option \fB\-mcpu=power10\fR (or later) is enabled.
! .IP "\fB\-mmma\fR" 4
  .IX Item "-mmma"
  .PD 0
! .IP "\fB\-mno\-mma\fR" 4
  .IX Item "-mno-mma"
  .PD
! Generate (do not generate) the \s-1MMA\s0 instructions.  The \fB\-mma\fR
  option requires that the option \fB\-mcpu=power10\fR (or later)
  is enabled.
! .IP "\fB\-mrop\-protect\fR" 4
  .IX Item "-mrop-protect"
  .PD 0
! .IP "\fB\-mno\-rop\-protect\fR" 4
  .IX Item "-mno-rop-protect"
  .PD
! Generate (do not generate) \s-1ROP\s0 protection instructions when the target
! processor supports them.  Currently this option disables the shrink-wrap
  optimization (\fB\-fshrink\-wrap\fR).
! .IP "\fB\-mprivileged\fR" 4
  .IX Item "-mprivileged"
  .PD 0
! .IP "\fB\-mno\-privileged\fR" 4
  .IX Item "-mno-privileged"
  .PD
  Generate (do not generate) code that will run in privileged state.
! .IP "\fB\-mblock\-ops\-unaligned\-vsx\fR" 4
  .IX Item "-mblock-ops-unaligned-vsx"
  .PD 0
! .IP "\fB\-mno\-block\-ops\-unaligned\-vsx\fR" 4
  .IX Item "-mno-block-ops-unaligned-vsx"
  .PD
  Generate (do not generate) unaligned vsx loads and stores for
--- 29420,29550 ----
  \&\f(CW\*(C`sinhf4\*(C'\fR, \f(CW\*(C`sqrtd2\*(C'\fR, \f(CW\*(C`sqrtf4\*(C'\fR, \f(CW\*(C`tand2\*(C'\fR,
  \&\f(CW\*(C`tanf4\*(C'\fR, \f(CW\*(C`tanhd2\*(C'\fR, and \f(CW\*(C`tanhf4\*(C'\fR when generating code
  for power7.  Both \fB\-ftree\-vectorize\fR and
! \&\fB\-funsafe\-math\-optimizations\fR must also be enabled.  The MASS
  libraries must be specified at link time.
! .IP \fB\-mfriz\fR 4
  .IX Item "-mfriz"
  .PD 0
! .IP \fB\-mno\-friz\fR 4
  .IX Item "-mno-friz"
  .PD
  Generate (do not generate) the \f(CW\*(C`friz\*(C'\fR instruction when the
  \&\fB\-funsafe\-math\-optimizations\fR option is used to optimize
! rounding of floating\-point values to 64\-bit integer and back to floating
  point.  The \f(CW\*(C`friz\*(C'\fR instruction does not return the same value if
! the floating\-point number is too large to fit in an integer.
! .IP \fB\-mpointers\-to\-nested\-functions\fR 4
  .IX Item "-mpointers-to-nested-functions"
  .PD 0
! .IP \fB\-mno\-pointers\-to\-nested\-functions\fR 4
  .IX Item "-mno-pointers-to-nested-functions"
  .PD
  Generate (do not generate) code to load up the static chain register
! (\f(CW\*(C`r11\*(C'\fR) when calling through a pointer on AIX and 64\-bit Linux
  systems where a function pointer points to a 3\-word descriptor giving
! the function address, TOC value to be loaded in register \f(CW\*(C`r2\*(C'\fR, and
  static chain value to be loaded in register \f(CW\*(C`r11\*(C'\fR.  The
  \&\fB\-mpointers\-to\-nested\-functions\fR is on by default.  You cannot
  call through pointers to nested functions or pointers
  to functions compiled in other languages that use the static chain if
  you use \fB\-mno\-pointers\-to\-nested\-functions\fR.
! .IP \fB\-msave\-toc\-indirect\fR 4
  .IX Item "-msave-toc-indirect"
  .PD 0
! .IP \fB\-mno\-save\-toc\-indirect\fR 4
  .IX Item "-mno-save-toc-indirect"
  .PD
! Generate (do not generate) code to save the TOC value in the reserved
  stack location in the function prologue if the function calls through
! a pointer on AIX and 64\-bit Linux systems.  If the TOC value is not
  saved in the prologue, it is saved just before the call through the
  pointer.  The \fB\-mno\-save\-toc\-indirect\fR option is the default.
! .IP \fB\-mcompat\-align\-parm\fR 4
  .IX Item "-mcompat-align-parm"
  .PD 0
! .IP \fB\-mno\-compat\-align\-parm\fR 4
  .IX Item "-mno-compat-align-parm"
  .PD
  Generate (do not generate) code to pass structure parameters with a
  maximum alignment of 64 bits, for compatibility with older versions
! of GCC.
  .Sp
! Older versions of GCC (prior to 4.9.0) incorrectly did not align a
  structure parameter on a 128\-bit boundary when that structure contained
  a member requiring 128\-bit alignment.  This is corrected in more
! recent versions of GCC.  This option may be used to generate code
  that is compatible with functions compiled with older versions of
! GCC.
  .Sp
  The \fB\-mno\-compat\-align\-parm\fR option is the default.
! .IP \fB\-mstack\-protector\-guard=\fR\fIguard\fR 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP \fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR 4
  .IX Item "-mstack-protector-guard-offset=offset"
! .IP \fB\-mstack\-protector\-guard\-symbol=\fR\fIsymbol\fR 4
  .IX Item "-mstack-protector-guard-symbol=symbol"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for global canary or \fBtls\fR for per\-thread
! canary in the TLS block (the default with GNU libc version 2.4 or later).
  .Sp
  With the latter choice the options
  \&\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR and
  \&\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR furthermore specify
  which register to use as base register for reading the canary, and from what
  offset from that base register. The default for those is as specified in the
! relevant ABI.  \fB\-mstack\-protector\-guard\-symbol=\fR\fIsymbol\fR overrides
! the offset with a symbol reference to a canary in the TLS block.
! .IP \fB\-mpcrel\fR 4
  .IX Item "-mpcrel"
  .PD 0
! .IP \fB\-mno\-pcrel\fR 4
  .IX Item "-mno-pcrel"
  .PD
! Generate (do not generate) pc\-relative addressing.  The \fB\-mpcrel\fR
  option requires that the medium code model (\fB\-mcmodel=medium\fR)
  and prefixed addressing (\fB\-mprefixed\fR) options are enabled.
! .IP \fB\-mprefixed\fR 4
  .IX Item "-mprefixed"
  .PD 0
! .IP \fB\-mno\-prefixed\fR 4
  .IX Item "-mno-prefixed"
  .PD
  Generate (do not generate) addressing modes using prefixed load and
  store instructions.  The \fB\-mprefixed\fR option requires that
  the option \fB\-mcpu=power10\fR (or later) is enabled.
! .IP \fB\-mmma\fR 4
  .IX Item "-mmma"
  .PD 0
! .IP \fB\-mno\-mma\fR 4
  .IX Item "-mno-mma"
  .PD
! Generate (do not generate) the MMA instructions.  The \fB\-mma\fR
  option requires that the option \fB\-mcpu=power10\fR (or later)
  is enabled.
! .IP \fB\-mrop\-protect\fR 4
  .IX Item "-mrop-protect"
  .PD 0
! .IP \fB\-mno\-rop\-protect\fR 4
  .IX Item "-mno-rop-protect"
  .PD
! Generate (do not generate) ROP protection instructions when the target
! processor supports them.  Currently this option disables the shrink\-wrap
  optimization (\fB\-fshrink\-wrap\fR).
! .IP \fB\-mprivileged\fR 4
  .IX Item "-mprivileged"
  .PD 0
! .IP \fB\-mno\-privileged\fR 4
  .IX Item "-mno-privileged"
  .PD
  Generate (do not generate) code that will run in privileged state.
! .IP \fB\-mblock\-ops\-unaligned\-vsx\fR 4
  .IX Item "-mblock-ops-unaligned-vsx"
  .PD 0
! .IP \fB\-mno\-block\-ops\-unaligned\-vsx\fR 4
  .IX Item "-mno-block-ops-unaligned-vsx"
  .PD
  Generate (do not generate) unaligned vsx loads and stores for
*************** would be beneficial to unroll the main v
*** 29625,29690 ****
  parameter sets the upper bound of how much the vectorizer will unroll the main
  loop.  The default value is four.
  .PP
! \fI\s-1RX\s0 Options\fR
  .IX Subsection "RX Options"
  .PP
! These command-line options are defined for \s-1RX\s0 targets:
! .IP "\fB\-m64bit\-doubles\fR" 4
  .IX Item "-m64bit-doubles"
  .PD 0
! .IP "\fB\-m32bit\-doubles\fR" 4
  .IX Item "-m32bit-doubles"
  .PD
  Make the \f(CW\*(C`double\*(C'\fR data type be 64 bits (\fB\-m64bit\-doubles\fR)
  or 32 bits (\fB\-m32bit\-doubles\fR) in size.  The default is
! \&\fB\-m32bit\-doubles\fR.  \fINote\fR \s-1RX\s0 floating-point hardware only
  works on 32\-bit values, which is why the default is
  \&\fB\-m32bit\-doubles\fR.
! .IP "\fB\-fpu\fR" 4
  .IX Item "-fpu"
  .PD 0
! .IP "\fB\-nofpu\fR" 4
  .IX Item "-nofpu"
  .PD
! Enables (\fB\-fpu\fR) or disables (\fB\-nofpu\fR) the use of \s-1RX\s0
! floating-point hardware.  The default is enabled for the \s-1RX600\s0
! series and disabled for the \s-1RX200\s0 series.
  .Sp
! Floating-point instructions are only generated for 32\-bit floating-point 
! values, however, so the \s-1FPU\s0 hardware is not used for doubles if the
  \&\fB\-m64bit\-doubles\fR option is used.
  .Sp
  \&\fINote\fR If the \fB\-fpu\fR option is enabled then
  \&\fB\-funsafe\-math\-optimizations\fR is also enabled automatically.
! This is because the \s-1RX FPU\s0 instructions are themselves unsafe.
! .IP "\fB\-mcpu=\fR\fIname\fR" 4
  .IX Item "-mcpu=name"
! Selects the type of \s-1RX CPU\s0 to be targeted.  Currently three types are
! supported, the generic \fB\s-1RX600\s0\fR and \fB\s-1RX200\s0\fR series hardware and
! the specific \fB\s-1RX610\s0\fR \s-1CPU.\s0  The default is \fB\s-1RX600\s0\fR.
  .Sp
! The only difference between \fB\s-1RX600\s0\fR and \fB\s-1RX610\s0\fR is that the
! \&\fB\s-1RX610\s0\fR does not support the \f(CW\*(C`MVTIPL\*(C'\fR instruction.
  .Sp
! The \fB\s-1RX200\s0\fR series does not have a hardware floating-point unit
  and so \fB\-nofpu\fR is enabled by default when this type is
  selected.
! .IP "\fB\-mbig\-endian\-data\fR" 4
  .IX Item "-mbig-endian-data"
  .PD 0
! .IP "\fB\-mlittle\-endian\-data\fR" 4
  .IX Item "-mlittle-endian-data"
  .PD
! Store data (but not code) in the big-endian format.  The default is
! \&\fB\-mlittle\-endian\-data\fR, i.e. to store data in the little-endian
  format.
! .IP "\fB\-msmall\-data\-limit=\fR\fIN\fR" 4
  .IX Item "-msmall-data-limit=N"
  Specifies the maximum size in bytes of global and static variables
  which can be placed into the small data area.  Using the small data
  area can lead to smaller and faster code, but the size of area is
  limited and it is up to the programmer to ensure that the area does
! not overflow.  Also when the small data area is used one of the \s-1RX\s0's
  registers (usually \f(CW\*(C`r13\*(C'\fR) is reserved for use pointing to this
  area, so it is no longer available for use by the compiler.  This
  could result in slower and/or larger code if variables are pushed onto
--- 29556,29621 ----
  parameter sets the upper bound of how much the vectorizer will unroll the main
  loop.  The default value is four.
  .PP
! \fIRX Options\fR
  .IX Subsection "RX Options"
  .PP
! These command\-line options are defined for RX targets:
! .IP \fB\-m64bit\-doubles\fR 4
  .IX Item "-m64bit-doubles"
  .PD 0
! .IP \fB\-m32bit\-doubles\fR 4
  .IX Item "-m32bit-doubles"
  .PD
  Make the \f(CW\*(C`double\*(C'\fR data type be 64 bits (\fB\-m64bit\-doubles\fR)
  or 32 bits (\fB\-m32bit\-doubles\fR) in size.  The default is
! \&\fB\-m32bit\-doubles\fR.  \fINote\fR RX floating\-point hardware only
  works on 32\-bit values, which is why the default is
  \&\fB\-m32bit\-doubles\fR.
! .IP \fB\-fpu\fR 4
  .IX Item "-fpu"
  .PD 0
! .IP \fB\-nofpu\fR 4
  .IX Item "-nofpu"
  .PD
! Enables (\fB\-fpu\fR) or disables (\fB\-nofpu\fR) the use of RX
! floating\-point hardware.  The default is enabled for the RX600
! series and disabled for the RX200 series.
  .Sp
! Floating\-point instructions are only generated for 32\-bit floating\-point 
! values, however, so the FPU hardware is not used for doubles if the
  \&\fB\-m64bit\-doubles\fR option is used.
  .Sp
  \&\fINote\fR If the \fB\-fpu\fR option is enabled then
  \&\fB\-funsafe\-math\-optimizations\fR is also enabled automatically.
! This is because the RX FPU instructions are themselves unsafe.
! .IP \fB\-mcpu=\fR\fIname\fR 4
  .IX Item "-mcpu=name"
! Selects the type of RX CPU to be targeted.  Currently three types are
! supported, the generic \fBRX600\fR and \fBRX200\fR series hardware and
! the specific \fBRX610\fR CPU.  The default is \fBRX600\fR.
  .Sp
! The only difference between \fBRX600\fR and \fBRX610\fR is that the
! \&\fBRX610\fR does not support the \f(CW\*(C`MVTIPL\*(C'\fR instruction.
  .Sp
! The \fBRX200\fR series does not have a hardware floating\-point unit
  and so \fB\-nofpu\fR is enabled by default when this type is
  selected.
! .IP \fB\-mbig\-endian\-data\fR 4
  .IX Item "-mbig-endian-data"
  .PD 0
! .IP \fB\-mlittle\-endian\-data\fR 4
  .IX Item "-mlittle-endian-data"
  .PD
! Store data (but not code) in the big\-endian format.  The default is
! \&\fB\-mlittle\-endian\-data\fR, i.e. to store data in the little\-endian
  format.
! .IP \fB\-msmall\-data\-limit=\fR\fIN\fR 4
  .IX Item "-msmall-data-limit=N"
  Specifies the maximum size in bytes of global and static variables
  which can be placed into the small data area.  Using the small data
  area can lead to smaller and faster code, but the size of area is
  limited and it is up to the programmer to ensure that the area does
! not overflow.  Also when the small data area is used one of the RX\*(Aqs
  registers (usually \f(CW\*(C`r13\*(C'\fR) is reserved for use pointing to this
  area, so it is no longer available for use by the compiler.  This
  could result in slower and/or larger code if variables are pushed onto
*************** reserving a register.  It is up to the p
*** 29701,29727 ****
  discover whether this feature is of benefit to their program.  See the
  description of the \fB\-mpid\fR option for a description of how the
  actual register to hold the small data area pointer is chosen.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  .PD 0
! .IP "\fB\-mno\-sim\fR" 4
  .IX Item "-mno-sim"
  .PD
  Use the simulator runtime.  The default is to use the libgloss
! board-specific runtime.
! .IP "\fB\-mas100\-syntax\fR" 4
  .IX Item "-mas100-syntax"
  .PD 0
! .IP "\fB\-mno\-as100\-syntax\fR" 4
  .IX Item "-mno-as100-syntax"
  .PD
  When generating assembler output use a syntax that is compatible with
! Renesas's \s-1AS100\s0 assembler.  This syntax can also be handled by the \s-1GAS\s0
  assembler, but it has some restrictions so it is not generated by default.
! .IP "\fB\-mmax\-constant\-size=\fR\fIN\fR" 4
  .IX Item "-mmax-constant-size=N"
  Specifies the maximum size, in bytes, of a constant that can be used as
! an operand in a \s-1RX\s0 instruction.  Although the \s-1RX\s0 instruction set does
  allow constants of up to 4 bytes in length to be used in instructions,
  a longer value equates to a longer instruction.  Thus in some
  circumstances it can be beneficial to restrict the size of constants
--- 29632,29658 ----
  discover whether this feature is of benefit to their program.  See the
  description of the \fB\-mpid\fR option for a description of how the
  actual register to hold the small data area pointer is chosen.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  .PD 0
! .IP \fB\-mno\-sim\fR 4
  .IX Item "-mno-sim"
  .PD
  Use the simulator runtime.  The default is to use the libgloss
! board\-specific runtime.
! .IP \fB\-mas100\-syntax\fR 4
  .IX Item "-mas100-syntax"
  .PD 0
! .IP \fB\-mno\-as100\-syntax\fR 4
  .IX Item "-mno-as100-syntax"
  .PD
  When generating assembler output use a syntax that is compatible with
! Renesas\*(Aqs AS100 assembler.  This syntax can also be handled by the GAS
  assembler, but it has some restrictions so it is not generated by default.
! .IP \fB\-mmax\-constant\-size=\fR\fIN\fR 4
  .IX Item "-mmax-constant-size=N"
  Specifies the maximum size, in bytes, of a constant that can be used as
! an operand in a 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
*************** placed into a constant pool and referenc
*** 29730,29741 ****
  .Sp
  The value \fIN\fR can be between 0 and 4.  A value of 0 (the default)
  or 4 means that constants of any size are allowed.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Enable linker relaxation.  Linker relaxation is a process whereby the
  linker attempts to reduce the size of a program by finding shorter
  versions of various instructions.  Disabled by default.
! .IP "\fB\-mint\-register=\fR\fIN\fR" 4
  .IX Item "-mint-register=N"
  Specify the number of registers to reserve for fast interrupt handler
  functions.  The value \fIN\fR can be between 0 and 4.  A value of 1
--- 29661,29672 ----
  .Sp
  The value \fIN\fR can be between 0 and 4.  A value of 0 (the default)
  or 4 means that constants of any size are allowed.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Enable linker relaxation.  Linker relaxation is a process whereby the
  linker attempts to reduce the size of a program by finding shorter
  versions of various instructions.  Disabled by default.
! .IP \fB\-mint\-register=\fR\fIN\fR 4
  .IX Item "-mint-register=N"
  Specify the number of registers to reserve for fast interrupt handler
  functions.  The value \fIN\fR can be between 0 and 4.  A value of 1
*************** of fast interrupt handlers.  A value of
*** 29744,29760 ****
  \&\f(CW\*(C`r12\*(C'\fR.  A value of 3 reserves \f(CW\*(C`r13\*(C'\fR, \f(CW\*(C`r12\*(C'\fR and
  \&\f(CW\*(C`r11\*(C'\fR, and a value of 4 reserves \f(CW\*(C`r13\*(C'\fR through \f(CW\*(C`r10\*(C'\fR.
  A value of 0, the default, does not reserve any registers.
! .IP "\fB\-msave\-acc\-in\-interrupts\fR" 4
  .IX Item "-msave-acc-in-interrupts"
  Specifies that interrupt handler functions should preserve the
  accumulator register.  This is only necessary if normal code might use
  the accumulator register, for example because it performs 64\-bit
  multiplications.  The default is to ignore the accumulator as this
  makes the interrupt handlers faster.
! .IP "\fB\-mpid\fR" 4
  .IX Item "-mpid"
  .PD 0
! .IP "\fB\-mno\-pid\fR" 4
  .IX Item "-mno-pid"
  .PD
  Enables the generation of position independent data.  When enabled any
--- 29675,29691 ----
  \&\f(CW\*(C`r12\*(C'\fR.  A value of 3 reserves \f(CW\*(C`r13\*(C'\fR, \f(CW\*(C`r12\*(C'\fR and
  \&\f(CW\*(C`r11\*(C'\fR, and a value of 4 reserves \f(CW\*(C`r13\*(C'\fR through \f(CW\*(C`r10\*(C'\fR.
  A value of 0, the default, does not reserve any registers.
! .IP \fB\-msave\-acc\-in\-interrupts\fR 4
  .IX Item "-msave-acc-in-interrupts"
  Specifies that interrupt handler functions should preserve the
  accumulator register.  This is only necessary if normal code might use
  the accumulator register, for example because it performs 64\-bit
  multiplications.  The default is to ignore the accumulator as this
  makes the interrupt handlers faster.
! .IP \fB\-mpid\fR 4
  .IX Item "-mpid"
  .PD 0
! .IP \fB\-mno\-pid\fR 4
  .IX Item "-mno-pid"
  .PD
  Enables the generation of position independent data.  When enabled any
*************** larger code, especially in complicated f
*** 29771,29777 ****
  .Sp
  The actual register chosen to hold the constant data base address
  depends upon whether the \fB\-msmall\-data\-limit\fR and/or the
! \&\fB\-mint\-register\fR command-line options are enabled.  Starting
  with register \f(CW\*(C`r13\*(C'\fR and proceeding downwards, registers are
  allocated first to satisfy the requirements of \fB\-mint\-register\fR,
  then \fB\-mpid\fR and finally \fB\-msmall\-data\-limit\fR.  Thus it
--- 29702,29708 ----
  .Sp
  The actual register chosen to hold the constant data base address
  depends upon whether the \fB\-msmall\-data\-limit\fR and/or the
! \&\fB\-mint\-register\fR command\-line options are enabled.  Starting
  with register \f(CW\*(C`r13\*(C'\fR and proceeding downwards, registers are
  allocated first to satisfy the requirements of \fB\-mint\-register\fR,
  then \fB\-mpid\fR and finally \fB\-msmall\-data\-limit\fR.  Thus it
*************** is possible for the small data area regi
*** 29780,29823 ****
  command line.
  .Sp
  By default this feature is not enabled.  The default can be restored
! via the \fB\-mno\-pid\fR command-line option.
! .IP "\fB\-mno\-warn\-multiple\-fast\-interrupts\fR" 4
  .IX Item "-mno-warn-multiple-fast-interrupts"
  .PD 0
! .IP "\fB\-mwarn\-multiple\-fast\-interrupts\fR" 4
  .IX Item "-mwarn-multiple-fast-interrupts"
  .PD
! Prevents \s-1GCC\s0 from issuing a warning message if it finds more than one
  fast interrupt handler when it is compiling a file.  The default is to
! issue a warning for each extra fast interrupt handler found, as the \s-1RX\s0
  only supports one such interrupt.
! .IP "\fB\-mallow\-string\-insns\fR" 4
  .IX Item "-mallow-string-insns"
  .PD 0
! .IP "\fB\-mno\-allow\-string\-insns\fR" 4
  .IX Item "-mno-allow-string-insns"
  .PD
  Enables or disables the use of the string manipulation instructions
  \&\f(CW\*(C`SMOVF\*(C'\fR, \f(CW\*(C`SCMPU\*(C'\fR, \f(CW\*(C`SMOVB\*(C'\fR, \f(CW\*(C`SMOVU\*(C'\fR, \f(CW\*(C`SUNTIL\*(C'\fR
  \&\f(CW\*(C`SWHILE\*(C'\fR and also the \f(CW\*(C`RMPA\*(C'\fR instruction.  These
  instructions may prefetch data, which is not safe to do if accessing
! an I/O register.  (See section 12.2.7 of the \s-1RX62N\s0 Group User's Manual
  for more information).
  .Sp
  The default is to allow these instructions, but it is not possible for
! \&\s-1GCC\s0 to reliably detect all circumstances where a string instruction
  might be used to access an I/O register, so their use cannot be
  disabled automatically.  Instead it is reliant upon the programmer to
  use the \fB\-mno\-allow\-string\-insns\fR option if their program
  accesses I/O space.
  .Sp
! When the instructions are enabled \s-1GCC\s0 defines the C preprocessor
  symbol \f(CW\*(C`_\|_RX_ALLOW_STRING_INSNS_\|_\*(C'\fR, otherwise it defines the
  symbol \f(CW\*(C`_\|_RX_DISALLOW_STRING_INSNS_\|_\*(C'\fR.
! .IP "\fB\-mjsr\fR" 4
  .IX Item "-mjsr"
  .PD 0
! .IP "\fB\-mno\-jsr\fR" 4
  .IX Item "-mno-jsr"
  .PD
  Use only (or not only) \f(CW\*(C`JSR\*(C'\fR instructions to access functions.
--- 29711,29754 ----
  command line.
  .Sp
  By default this feature is not enabled.  The default can be restored
! via the \fB\-mno\-pid\fR command\-line option.
! .IP \fB\-mno\-warn\-multiple\-fast\-interrupts\fR 4
  .IX Item "-mno-warn-multiple-fast-interrupts"
  .PD 0
! .IP \fB\-mwarn\-multiple\-fast\-interrupts\fR 4
  .IX Item "-mwarn-multiple-fast-interrupts"
  .PD
! Prevents GCC from issuing a warning message if it finds more than one
  fast interrupt handler when it is compiling a file.  The default is to
! issue a warning for each extra fast interrupt handler found, as the RX
  only supports one such interrupt.
! .IP \fB\-mallow\-string\-insns\fR 4
  .IX Item "-mallow-string-insns"
  .PD 0
! .IP \fB\-mno\-allow\-string\-insns\fR 4
  .IX Item "-mno-allow-string-insns"
  .PD
  Enables or disables the use of the string manipulation instructions
  \&\f(CW\*(C`SMOVF\*(C'\fR, \f(CW\*(C`SCMPU\*(C'\fR, \f(CW\*(C`SMOVB\*(C'\fR, \f(CW\*(C`SMOVU\*(C'\fR, \f(CW\*(C`SUNTIL\*(C'\fR
  \&\f(CW\*(C`SWHILE\*(C'\fR and also the \f(CW\*(C`RMPA\*(C'\fR instruction.  These
  instructions may prefetch data, which is not safe to do if accessing
! an I/O register.  (See section 12.2.7 of the RX62N Group User\*(Aqs Manual
  for more information).
  .Sp
  The default is to allow these instructions, but it is not possible for
! GCC to reliably detect all circumstances where a string instruction
  might be used to access an I/O register, so their use cannot be
  disabled automatically.  Instead it is reliant upon the programmer to
  use the \fB\-mno\-allow\-string\-insns\fR option if their program
  accesses I/O space.
  .Sp
! When the instructions are enabled GCC defines the C preprocessor
  symbol \f(CW\*(C`_\|_RX_ALLOW_STRING_INSNS_\|_\*(C'\fR, otherwise it defines the
  symbol \f(CW\*(C`_\|_RX_DISALLOW_STRING_INSNS_\|_\*(C'\fR.
! .IP \fB\-mjsr\fR 4
  .IX Item "-mjsr"
  .PD 0
! .IP \fB\-mno\-jsr\fR 4
  .IX Item "-mno-jsr"
  .PD
  Use only (or not only) \f(CW\*(C`JSR\*(C'\fR instructions to access functions.
*************** This option can be used when code size e
*** 29825,29892 ****
  instructions.  Note that \fB\-mno\-jsr\fR does not mean to not use
  \&\f(CW\*(C`JSR\*(C'\fR but instead means that any type of branch may be used.
  .PP
! \&\fINote:\fR The generic \s-1GCC\s0 command-line option \fB\-ffixed\-\fR\fIreg\fR
! has special significance to the \s-1RX\s0 port when used with the
  \&\f(CW\*(C`interrupt\*(C'\fR function attribute.  This attribute indicates a
! function intended to process fast interrupts.  \s-1GCC\s0 ensures
  that it only uses the registers \f(CW\*(C`r10\*(C'\fR, \f(CW\*(C`r11\*(C'\fR, \f(CW\*(C`r12\*(C'\fR
  and/or \f(CW\*(C`r13\*(C'\fR and only provided that the normal use of the
  corresponding registers have been restricted via the
! \&\fB\-ffixed\-\fR\fIreg\fR or \fB\-mint\-register\fR command-line
  options.
  .PP
  \fIS/390 and zSeries Options\fR
  .IX Subsection "S/390 and zSeries Options"
  .PP
  These are the \fB\-m\fR options defined for the S/390 and zSeries architecture.
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
! Use (do not use) the hardware floating-point instructions and registers
! for floating-point operations.  When \fB\-msoft\-float\fR is specified,
! functions in \fIlibgcc.a\fR are used to perform floating-point
  operations.  When \fB\-mhard\-float\fR is specified, the compiler
! generates \s-1IEEE\s0 floating-point instructions.  This is the default.
! .IP "\fB\-mhard\-dfp\fR" 4
  .IX Item "-mhard-dfp"
  .PD 0
! .IP "\fB\-mno\-hard\-dfp\fR" 4
  .IX Item "-mno-hard-dfp"
  .PD
! Use (do not use) the hardware decimal-floating-point instructions for
! decimal-floating-point operations.  When \fB\-mno\-hard\-dfp\fR is
  specified, functions in \fIlibgcc.a\fR are used to perform
! decimal-floating-point operations.  When \fB\-mhard\-dfp\fR is
! specified, the compiler generates decimal-floating-point hardware
  instructions.  This is the default for \fB\-march=z9\-ec\fR or higher.
! .IP "\fB\-mlong\-double\-64\fR" 4
  .IX Item "-mlong-double-64"
  .PD 0
! .IP "\fB\-mlong\-double\-128\fR" 4
  .IX Item "-mlong-double-128"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
  of 64 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the \f(CW\*(C`double\*(C'\fR
  type. This is the default.
! .IP "\fB\-mbackchain\fR" 4
  .IX Item "-mbackchain"
  .PD 0
! .IP "\fB\-mno\-backchain\fR" 4
  .IX Item "-mno-backchain"
  .PD
! Store (do not store) the address of the caller's frame as backchain pointer
! into the callee's stack frame.
  A backchain may be needed to allow debugging using tools that do not understand
! \&\s-1DWARF\s0 call frame information.
  When \fB\-mno\-packed\-stack\fR is in effect, the backchain pointer is stored
  at the bottom of the stack frame; when \fB\-mpacked\-stack\fR is in effect,
  the backchain is placed into the topmost word of the 96/160 byte register
  save area.
  .Sp
! In general, code compiled with \fB\-mbackchain\fR is call-compatible with
  code compiled with \fB\-mno\-backchain\fR; however, use of the backchain
  for debugging purposes usually requires that the whole binary is built with
  \&\fB\-mbackchain\fR.  Note that the combination of \fB\-mbackchain\fR,
--- 29756,29823 ----
  instructions.  Note that \fB\-mno\-jsr\fR does not mean to not use
  \&\f(CW\*(C`JSR\*(C'\fR but instead means that any type of branch may be used.
  .PP
! \&\fINote:\fR The generic GCC command\-line option \fB\-ffixed\-\fR\fIreg\fR
! has special significance to the RX port when used with the
  \&\f(CW\*(C`interrupt\*(C'\fR function attribute.  This attribute indicates a
! function intended to process fast interrupts.  GCC ensures
  that it only uses the registers \f(CW\*(C`r10\*(C'\fR, \f(CW\*(C`r11\*(C'\fR, \f(CW\*(C`r12\*(C'\fR
  and/or \f(CW\*(C`r13\*(C'\fR and only provided that the normal use of the
  corresponding registers have been restricted via the
! \&\fB\-ffixed\-\fR\fIreg\fR or \fB\-mint\-register\fR command\-line
  options.
  .PP
  \fIS/390 and zSeries Options\fR
  .IX Subsection "S/390 and zSeries Options"
  .PP
  These are the \fB\-m\fR options defined for the S/390 and zSeries architecture.
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
! Use (do not use) the hardware floating\-point instructions and registers
! for floating\-point operations.  When \fB\-msoft\-float\fR is specified,
! functions in \fIlibgcc.a\fR are used to perform floating\-point
  operations.  When \fB\-mhard\-float\fR is specified, the compiler
! generates IEEE floating\-point instructions.  This is the default.
! .IP \fB\-mhard\-dfp\fR 4
  .IX Item "-mhard-dfp"
  .PD 0
! .IP \fB\-mno\-hard\-dfp\fR 4
  .IX Item "-mno-hard-dfp"
  .PD
! Use (do not use) the hardware decimal\-floating\-point instructions for
! decimal\-floating\-point operations.  When \fB\-mno\-hard\-dfp\fR is
  specified, functions in \fIlibgcc.a\fR are used to perform
! decimal\-floating\-point operations.  When \fB\-mhard\-dfp\fR is
! specified, the compiler generates decimal\-floating\-point hardware
  instructions.  This is the default for \fB\-march=z9\-ec\fR or higher.
! .IP \fB\-mlong\-double\-64\fR 4
  .IX Item "-mlong-double-64"
  .PD 0
! .IP \fB\-mlong\-double\-128\fR 4
  .IX Item "-mlong-double-128"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
  of 64 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the \f(CW\*(C`double\*(C'\fR
  type. This is the default.
! .IP \fB\-mbackchain\fR 4
  .IX Item "-mbackchain"
  .PD 0
! .IP \fB\-mno\-backchain\fR 4
  .IX Item "-mno-backchain"
  .PD
! Store (do not store) the address of the caller\*(Aqs frame as backchain pointer
! into the callee\*(Aqs stack frame.
  A backchain may be needed to allow debugging using tools that do not understand
! DWARF call frame information.
  When \fB\-mno\-packed\-stack\fR is in effect, the backchain pointer is stored
  at the bottom of the stack frame; when \fB\-mpacked\-stack\fR is in effect,
  the backchain is placed into the topmost word of the 96/160 byte register
  save area.
  .Sp
! In general, code compiled with \fB\-mbackchain\fR is call\-compatible with
  code compiled with \fB\-mno\-backchain\fR; however, use of the backchain
  for debugging purposes usually requires that the whole binary is built with
  \&\fB\-mbackchain\fR.  Note that the combination of \fB\-mbackchain\fR,
*************** for debugging purposes usually requires
*** 29894,29903 ****
  to build a linux kernel use \fB\-msoft\-float\fR.
  .Sp
  The default is to not maintain the backchain.
! .IP "\fB\-mpacked\-stack\fR" 4
  .IX Item "-mpacked-stack"
  .PD 0
! .IP "\fB\-mno\-packed\-stack\fR" 4
  .IX Item "-mno-packed-stack"
  .PD
  Use (do not use) the packed stack layout.  When \fB\-mno\-packed\-stack\fR is
--- 29825,29834 ----
  to build a linux kernel use \fB\-msoft\-float\fR.
  .Sp
  The default is to not maintain the backchain.
! .IP \fB\-mpacked\-stack\fR 4
  .IX Item "-mpacked-stack"
  .PD 0
! .IP \fB\-mno\-packed\-stack\fR 4
  .IX Item "-mno-packed-stack"
  .PD
  Use (do not use) the packed stack layout.  When \fB\-mno\-packed\-stack\fR is
*************** the save area is always used to store th
*** 29911,29930 ****
  register is always saved two words below the backchain.
  .Sp
  As long as the stack frame backchain is not used, code generated with
! \&\fB\-mpacked\-stack\fR is call-compatible with code generated with
! \&\fB\-mno\-packed\-stack\fR.  Note that some non-FSF releases of \s-1GCC 2.95\s0 for
  S/390 or zSeries generated code that uses the stack frame backchain at run
! time, not just for debugging purposes.  Such code is not call-compatible
  with code compiled with \fB\-mpacked\-stack\fR.  Also, note that the
  combination of \fB\-mbackchain\fR,
  \&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported.  In order
  to build a linux kernel use \fB\-msoft\-float\fR.
  .Sp
  The default is to not use the packed stack layout.
! .IP "\fB\-msmall\-exec\fR" 4
  .IX Item "-msmall-exec"
  .PD 0
! .IP "\fB\-mno\-small\-exec\fR" 4
  .IX Item "-mno-small-exec"
  .PD
  Generate (or do not generate) code using the \f(CW\*(C`bras\*(C'\fR instruction
--- 29842,29861 ----
  register is always saved two words below the backchain.
  .Sp
  As long as the stack frame backchain is not used, code generated with
! \&\fB\-mpacked\-stack\fR is call\-compatible with code generated with
! \&\fB\-mno\-packed\-stack\fR.  Note that some non\-FSF releases of 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 \fB\-mpacked\-stack\fR.  Also, note that the
  combination of \fB\-mbackchain\fR,
  \&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported.  In order
  to build a linux kernel use \fB\-msoft\-float\fR.
  .Sp
  The default is to not use the packed stack layout.
! .IP \fB\-msmall\-exec\fR 4
  .IX Item "-msmall-exec"
  .PD 0
! .IP \fB\-mno\-small\-exec\fR 4
  .IX Item "-mno-small-exec"
  .PD
  Generate (or do not generate) code using the \f(CW\*(C`bras\*(C'\fR instruction
*************** to do subroutine calls.
*** 29932,30029 ****
  This only works reliably if the total executable size does not
  exceed 64k.  The default is to use the \f(CW\*(C`basr\*(C'\fR instruction instead,
  which does not have this limitation.
! .IP "\fB\-m64\fR" 4
  .IX Item "-m64"
  .PD 0
! .IP "\fB\-m31\fR" 4
  .IX Item "-m31"
  .PD
  When \fB\-m31\fR is specified, generate code compliant to the
! GNU/Linux for S/390 \s-1ABI.\s0  When \fB\-m64\fR is specified, generate
! code compliant to the GNU/Linux for zSeries \s-1ABI.\s0  This allows \s-1GCC\s0 in
  particular to generate 64\-bit instructions.  For the \fBs390\fR
  targets, the default is \fB\-m31\fR, while the \fBs390x\fR
  targets default to \fB\-m64\fR.
! .IP "\fB\-mzarch\fR" 4
  .IX Item "-mzarch"
  .PD 0
! .IP "\fB\-mesa\fR" 4
  .IX Item "-mesa"
  .PD
  When \fB\-mzarch\fR is specified, generate code using the
  instructions available on z/Architecture.
  When \fB\-mesa\fR is specified, generate code using the
! instructions available on \s-1ESA/390.\s0  Note that \fB\-mesa\fR is
  not possible with \fB\-m64\fR.
! When generating code compliant to the GNU/Linux for S/390 \s-1ABI,\s0
  the default is \fB\-mesa\fR.  When generating code compliant
! to the GNU/Linux for zSeries \s-1ABI,\s0 the default is \fB\-mzarch\fR.
! .IP "\fB\-mhtm\fR" 4
  .IX Item "-mhtm"
  .PD 0
! .IP "\fB\-mno\-htm\fR" 4
  .IX Item "-mno-htm"
  .PD
  The \fB\-mhtm\fR option enables a set of builtins making use of
  instructions available with the transactional execution facility
! introduced with the \s-1IBM\s0 zEnterprise \s-1EC12\s0 machine generation
! \&\fBS/390 System z Built-in Functions\fR.
  \&\fB\-mhtm\fR is enabled by default when using \fB\-march=zEC12\fR.
! .IP "\fB\-mvx\fR" 4
  .IX Item "-mvx"
  .PD 0
! .IP "\fB\-mno\-vx\fR" 4
  .IX Item "-mno-vx"
  .PD
  When \fB\-mvx\fR is specified, generate code using the instructions
! available with the vector extension facility introduced with the \s-1IBM\s0
  z13 machine generation.
! This option changes the \s-1ABI\s0 for some vector type values with regard to
  alignment and calling conventions.  In case vector type values are
! being used in an ABI-relevant context a \s-1GAS\s0 \fB.gnu_attribute\fR
! command will be added to mark the resulting binary with the \s-1ABI\s0 used.
  \&\fB\-mvx\fR is enabled by default when using \fB\-march=z13\fR.
! .IP "\fB\-mzvector\fR" 4
  .IX Item "-mzvector"
  .PD 0
! .IP "\fB\-mno\-zvector\fR" 4
  .IX Item "-mno-zvector"
  .PD
  The \fB\-mzvector\fR option enables vector language extensions and
  builtins using instructions available with the vector extension
! facility introduced with the \s-1IBM\s0 z13 machine generation.
  This option adds support for \fBvector\fR to be used as a keyword to
  define vector type variables and arguments.  \fBvector\fR is only
! available when \s-1GNU\s0 extensions are enabled.  It will not be expanded
  when requesting strict standard compliance e.g. with \fB\-std=c99\fR.
! In addition to the \s-1GCC\s0 low-level builtins \fB\-mzvector\fR enables
! a set of builtins added for compatibility with AltiVec-style
  implementations like Power and Cell.  In order to make use of these
  builtins the header file \fIvecintrin.h\fR needs to be included.
  \&\fB\-mzvector\fR is disabled by default.
! .IP "\fB\-mmvcle\fR" 4
  .IX Item "-mmvcle"
  .PD 0
! .IP "\fB\-mno\-mvcle\fR" 4
  .IX Item "-mno-mvcle"
  .PD
  Generate (or do not generate) code using the \f(CW\*(C`mvcle\*(C'\fR instruction
  to perform block moves.  When \fB\-mno\-mvcle\fR is specified,
  use a \f(CW\*(C`mvc\*(C'\fR loop instead.  This is the default unless optimizing for
  size.
! .IP "\fB\-mdebug\fR" 4
  .IX Item "-mdebug"
  .PD 0
! .IP "\fB\-mno\-debug\fR" 4
  .IX Item "-mno-debug"
  .PD
  Print (or do not print) additional debug information when compiling.
  The default is to not print debug information.
! .IP "\fB\-march=\fR\fIcpu-type\fR" 4
  .IX Item "-march=cpu-type"
! Generate code that runs on \fIcpu-type\fR, which is the name of a
  system representing a certain processor type.  Possible values for
! \&\fIcpu-type\fR are \fBz900\fR/\fBarch5\fR, \fBz990\fR/\fBarch6\fR,
  \&\fBz9\-109\fR, \fBz9\-ec\fR/\fBarch7\fR, \fBz10\fR/\fBarch8\fR,
  \&\fBz196\fR/\fBarch9\fR, \fBzEC12\fR, \fBz13\fR/\fBarch11\fR,
  \&\fBz14\fR/\fBarch12\fR, \fBz15\fR/\fBarch13\fR,
--- 29863,29960 ----
  This only works reliably if the total executable size does not
  exceed 64k.  The default is to use the \f(CW\*(C`basr\*(C'\fR instruction instead,
  which does not have this limitation.
! .IP \fB\-m64\fR 4
  .IX Item "-m64"
  .PD 0
! .IP \fB\-m31\fR 4
  .IX Item "-m31"
  .PD
  When \fB\-m31\fR is specified, generate code compliant to the
! GNU/Linux for S/390 ABI.  When \fB\-m64\fR is specified, generate
! code compliant to the GNU/Linux for zSeries ABI.  This allows GCC in
  particular to generate 64\-bit instructions.  For the \fBs390\fR
  targets, the default is \fB\-m31\fR, while the \fBs390x\fR
  targets default to \fB\-m64\fR.
! .IP \fB\-mzarch\fR 4
  .IX Item "-mzarch"
  .PD 0
! .IP \fB\-mesa\fR 4
  .IX Item "-mesa"
  .PD
  When \fB\-mzarch\fR is specified, generate code using the
  instructions available on z/Architecture.
  When \fB\-mesa\fR is specified, generate code using the
! instructions available on ESA/390.  Note that \fB\-mesa\fR is
  not possible with \fB\-m64\fR.
! When generating code compliant to the GNU/Linux for S/390 ABI,
  the default is \fB\-mesa\fR.  When generating code compliant
! to the GNU/Linux for zSeries ABI, the default is \fB\-mzarch\fR.
! .IP \fB\-mhtm\fR 4
  .IX Item "-mhtm"
  .PD 0
! .IP \fB\-mno\-htm\fR 4
  .IX Item "-mno-htm"
  .PD
  The \fB\-mhtm\fR option enables a set of builtins making use of
  instructions available with the transactional execution facility
! introduced with the IBM zEnterprise EC12 machine generation
! \&\fBS/390 System z Built\-in Functions\fR.
  \&\fB\-mhtm\fR is enabled by default when using \fB\-march=zEC12\fR.
! .IP \fB\-mvx\fR 4
  .IX Item "-mvx"
  .PD 0
! .IP \fB\-mno\-vx\fR 4
  .IX Item "-mno-vx"
  .PD
  When \fB\-mvx\fR is specified, generate code using the instructions
! available with the vector extension facility introduced with the IBM
  z13 machine generation.
! This option changes the ABI for some vector type values with regard to
  alignment and calling conventions.  In case vector type values are
! being used in an ABI\-relevant context a GAS \fB.gnu_attribute\fR
! command will be added to mark the resulting binary with the ABI used.
  \&\fB\-mvx\fR is enabled by default when using \fB\-march=z13\fR.
! .IP \fB\-mzvector\fR 4
  .IX Item "-mzvector"
  .PD 0
! .IP \fB\-mno\-zvector\fR 4
  .IX Item "-mno-zvector"
  .PD
  The \fB\-mzvector\fR option enables vector language extensions and
  builtins using instructions available with the vector extension
! facility introduced with the IBM z13 machine generation.
  This option adds support for \fBvector\fR to be used as a keyword to
  define vector type variables and arguments.  \fBvector\fR is only
! available when GNU extensions are enabled.  It will not be expanded
  when requesting strict standard compliance e.g. with \fB\-std=c99\fR.
! In addition to the GCC low\-level builtins \fB\-mzvector\fR enables
! a set of builtins added for compatibility with AltiVec\-style
  implementations like Power and Cell.  In order to make use of these
  builtins the header file \fIvecintrin.h\fR needs to be included.
  \&\fB\-mzvector\fR is disabled by default.
! .IP \fB\-mmvcle\fR 4
  .IX Item "-mmvcle"
  .PD 0
! .IP \fB\-mno\-mvcle\fR 4
  .IX Item "-mno-mvcle"
  .PD
  Generate (or do not generate) code using the \f(CW\*(C`mvcle\*(C'\fR instruction
  to perform block moves.  When \fB\-mno\-mvcle\fR is specified,
  use a \f(CW\*(C`mvc\*(C'\fR loop instead.  This is the default unless optimizing for
  size.
! .IP \fB\-mdebug\fR 4
  .IX Item "-mdebug"
  .PD 0
! .IP \fB\-mno\-debug\fR 4
  .IX Item "-mno-debug"
  .PD
  Print (or do not print) additional debug information when compiling.
  The default is to not print debug information.
! .IP \fB\-march=\fR\fIcpu\-type\fR 4
  .IX Item "-march=cpu-type"
! Generate code that runs on \fIcpu\-type\fR, which is the name of a
  system representing a certain processor type.  Possible values for
! \&\fIcpu\-type\fR are \fBz900\fR/\fBarch5\fR, \fBz990\fR/\fBarch6\fR,
  \&\fBz9\-109\fR, \fBz9\-ec\fR/\fBarch7\fR, \fBz10\fR/\fBarch8\fR,
  \&\fBz196\fR/\fBarch9\fR, \fBzEC12\fR, \fBz13\fR/\fBarch11\fR,
  \&\fBz14\fR/\fBarch12\fR, \fBz15\fR/\fBarch13\fR,
*************** The default is \fB\-march=z900\fR.
*** 30033,30113 ****
  .Sp
  Specifying \fBnative\fR as cpu type can be used to select the best
  architecture option for the host processor.
! \&\fB\-march=native\fR has no effect if \s-1GCC\s0 does not recognize the
  processor.
! .IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
  .IX Item "-mtune=cpu-type"
! Tune to \fIcpu-type\fR everything applicable about the generated code,
! except for the \s-1ABI\s0 and the set of available instructions.
! The list of \fIcpu-type\fR values is the same as for \fB\-march\fR.
  The default is the value used for \fB\-march\fR.
! .IP "\fB\-mtpf\-trace\fR" 4
  .IX Item "-mtpf-trace"
  .PD 0
! .IP "\fB\-mno\-tpf\-trace\fR" 4
  .IX Item "-mno-tpf-trace"
  .PD
! Generate code that adds (does not add) in \s-1TPF OS\s0 specific branches to trace
  routines in the operating system.  This option is off by default, even
! when compiling for the \s-1TPF OS.\s0
! .IP "\fB\-mtpf\-trace\-skip\fR" 4
  .IX Item "-mtpf-trace-skip"
  .PD 0
! .IP "\fB\-mno\-tpf\-trace\-skip\fR" 4
  .IX Item "-mno-tpf-trace-skip"
  .PD
  Generate code that changes (does not change) the default branch
  targets enabled by \fB\-mtpf\-trace\fR to point to specialized trace
  routines providing the ability of selectively skipping function trace
! entries for the \s-1TPF OS.\s0  This option is off by default, even when
! compiling for the \s-1TPF OS\s0 and specifying \fB\-mtpf\-trace\fR.
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating-point multiply and
  accumulate instructions.  These instructions are generated by default if
  hardware floating point is used.
! .IP "\fB\-mwarn\-framesize=\fR\fIframesize\fR" 4
  .IX Item "-mwarn-framesize=framesize"
  Emit a warning if the current function exceeds the given frame size.  Because
! this is a compile-time check it doesn't need to be a real problem when the program
  runs.  It is intended to identify functions that most probably cause
  a stack overflow.  It is useful to be used in an environment with limited stack
  size e.g. the linux kernel.
! .IP "\fB\-mwarn\-dynamicstack\fR" 4
  .IX Item "-mwarn-dynamicstack"
! Emit a warning if the function calls \f(CW\*(C`alloca\*(C'\fR or uses dynamically-sized
  arrays.  This is generally a bad idea with a limited stack size.
! .IP "\fB\-mstack\-guard=\fR\fIstack-guard\fR" 4
  .IX Item "-mstack-guard=stack-guard"
  .PD 0
! .IP "\fB\-mstack\-size=\fR\fIstack-size\fR" 4
  .IX Item "-mstack-size=stack-size"
  .PD
  If these options are provided the S/390 back end emits additional instructions in
! the function prologue that trigger a trap if the stack size is \fIstack-guard\fR
! bytes above the \fIstack-size\fR (remember that the stack on S/390 grows downward).
! If the \fIstack-guard\fR option is omitted the smallest power of 2 larger than
  the frame size of the compiled function is chosen.
  These options are intended to be used to help debugging stack overflow problems.
  The additionally emitted code causes only little overhead and hence can also be
! used in production-like systems without greater performance degradation.  The given
! values have to be exact powers of 2 and \fIstack-size\fR has to be greater than
! \&\fIstack-guard\fR without exceeding 64k.
  In order to be efficient the extra code makes the assumption that the stack starts
! at an address aligned to the value given by \fIstack-size\fR.
! The \fIstack-guard\fR option can only be used in conjunction with \fIstack-size\fR.
! .IP "\fB\-mhotpatch=\fR\fIpre-halfwords\fR\fB,\fR\fIpost-halfwords\fR" 4
  .IX Item "-mhotpatch=pre-halfwords,post-halfwords"
! If the hotpatch option is enabled, a \*(L"hot-patching\*(R" function
  prologue is generated for all functions in the compilation unit.
! The funtion label is prepended with the given number of two-byte
! \&\s-1NOP\s0 instructions (\fIpre-halfwords\fR, maximum 1000000).  After
! the label, 2 * \fIpost-halfwords\fR bytes are appended, using the
! largest \s-1NOP\s0 like instructions the architecture allows (maximum
  1000000).
  .Sp
  If both arguments are zero, hotpatching is disabled.
--- 29964,30044 ----
  .Sp
  Specifying \fBnative\fR as cpu type can be used to select the best
  architecture option for the host processor.
! \&\fB\-march=native\fR has no effect if GCC does not recognize the
  processor.
! .IP \fB\-mtune=\fR\fIcpu\-type\fR 4
  .IX Item "-mtune=cpu-type"
! Tune to \fIcpu\-type\fR everything applicable about the generated code,
! except for the ABI and the set of available instructions.
! The list of \fIcpu\-type\fR values is the same as for \fB\-march\fR.
  The default is the value used for \fB\-march\fR.
! .IP \fB\-mtpf\-trace\fR 4
  .IX Item "-mtpf-trace"
  .PD 0
! .IP \fB\-mno\-tpf\-trace\fR 4
  .IX Item "-mno-tpf-trace"
  .PD
! Generate code that adds (does not add) in TPF OS specific branches to trace
  routines in the operating system.  This option is off by default, even
! when compiling for the TPF OS.
! .IP \fB\-mtpf\-trace\-skip\fR 4
  .IX Item "-mtpf-trace-skip"
  .PD 0
! .IP \fB\-mno\-tpf\-trace\-skip\fR 4
  .IX Item "-mno-tpf-trace-skip"
  .PD
  Generate code that changes (does not change) the default branch
  targets enabled by \fB\-mtpf\-trace\fR to point to specialized trace
  routines providing the ability of selectively skipping function trace
! entries for the TPF OS.  This option is off by default, even when
! compiling for the TPF OS and specifying \fB\-mtpf\-trace\fR.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating\-point multiply and
  accumulate instructions.  These instructions are generated by default if
  hardware floating point is used.
! .IP \fB\-mwarn\-framesize=\fR\fIframesize\fR 4
  .IX Item "-mwarn-framesize=framesize"
  Emit a warning if the current function exceeds the given frame size.  Because
! this is a compile\-time check it doesn\*(Aqt need to be a real problem when the program
  runs.  It is intended to identify functions that most probably cause
  a stack overflow.  It is useful to be used in an environment with limited stack
  size e.g. the linux kernel.
! .IP \fB\-mwarn\-dynamicstack\fR 4
  .IX Item "-mwarn-dynamicstack"
! Emit a warning if the function calls \f(CW\*(C`alloca\*(C'\fR or uses dynamically\-sized
  arrays.  This is generally a bad idea with a limited stack size.
! .IP \fB\-mstack\-guard=\fR\fIstack\-guard\fR 4
  .IX Item "-mstack-guard=stack-guard"
  .PD 0
! .IP \fB\-mstack\-size=\fR\fIstack\-size\fR 4
  .IX Item "-mstack-size=stack-size"
  .PD
  If these options are provided the S/390 back end emits additional instructions in
! the function prologue that trigger a trap if the stack size is \fIstack\-guard\fR
! bytes above the \fIstack\-size\fR (remember that the stack on S/390 grows downward).
! If the \fIstack\-guard\fR option is omitted the smallest power of 2 larger than
  the frame size of the compiled function is chosen.
  These options are intended to be used to help debugging stack overflow problems.
  The additionally emitted code causes only little overhead and hence can also be
! used in production\-like systems without greater performance degradation.  The given
! values have to be exact powers of 2 and \fIstack\-size\fR has to be greater than
! \&\fIstack\-guard\fR without exceeding 64k.
  In order to be efficient the extra code makes the assumption that the stack starts
! at an address aligned to the value given by \fIstack\-size\fR.
! The \fIstack\-guard\fR option can only be used in conjunction with \fIstack\-size\fR.
! .IP \fB\-mhotpatch=\fR\fIpre\-halfwords\fR\fB,\fR\fIpost\-halfwords\fR 4
  .IX Item "-mhotpatch=pre-halfwords,post-halfwords"
! If the hotpatch option is enabled, a "hot\-patching" function
  prologue is generated for all functions in the compilation unit.
! The funtion label is prepended with the given number of two\-byte
! NOP instructions (\fIpre\-halfwords\fR, maximum 1000000).  After
! the label, 2 * \fIpost\-halfwords\fR bytes are appended, using the
! largest NOP like instructions the architecture allows (maximum
  1000000).
  .Sp
  If both arguments are zero, hotpatching is disabled.
*************** If both arguments are zero, hotpatching
*** 30115,30292 ****
  This option can be overridden for individual functions with the
  \&\f(CW\*(C`hotpatch\*(C'\fR attribute.
  .PP
! \fI\s-1SH\s0 Options\fR
  .IX Subsection "SH Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1SH\s0 implementations:
! .IP "\fB\-m1\fR" 4
  .IX Item "-m1"
! Generate code for the \s-1SH1.\s0
! .IP "\fB\-m2\fR" 4
  .IX Item "-m2"
! Generate code for the \s-1SH2.\s0
! .IP "\fB\-m2e\fR" 4
  .IX Item "-m2e"
  Generate code for the SH2e.
! .IP "\fB\-m2a\-nofpu\fR" 4
  .IX Item "-m2a-nofpu"
! Generate code for the SH2a without \s-1FPU,\s0 or for a SH2a\-FPU in such a way
! that the floating-point unit is not used.
! .IP "\fB\-m2a\-single\-only\fR" 4
  .IX Item "-m2a-single-only"
! Generate code for the SH2a\-FPU, in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m2a\-single\fR" 4
  .IX Item "-m2a-single"
! Generate code for the SH2a\-FPU assuming the floating-point unit is in
! single-precision mode by default.
! .IP "\fB\-m2a\fR" 4
  .IX Item "-m2a"
! Generate code for the SH2a\-FPU assuming the floating-point unit is in
! double-precision mode by default.
! .IP "\fB\-m3\fR" 4
  .IX Item "-m3"
! Generate code for the \s-1SH3.\s0
! .IP "\fB\-m3e\fR" 4
  .IX Item "-m3e"
  Generate code for the SH3e.
! .IP "\fB\-m4\-nofpu\fR" 4
  .IX Item "-m4-nofpu"
! Generate code for the \s-1SH4\s0 without a floating-point unit.
! .IP "\fB\-m4\-single\-only\fR" 4
  .IX Item "-m4-single-only"
! Generate code for the \s-1SH4\s0 with a floating-point unit that only
! supports single-precision arithmetic.
! .IP "\fB\-m4\-single\fR" 4
  .IX Item "-m4-single"
! Generate code for the \s-1SH4\s0 assuming the floating-point unit is in
! single-precision mode by default.
! .IP "\fB\-m4\fR" 4
  .IX Item "-m4"
! Generate code for the \s-1SH4.\s0
! .IP "\fB\-m4\-100\fR" 4
  .IX Item "-m4-100"
! Generate code for \s-1SH4\-100.\s0
! .IP "\fB\-m4\-100\-nofpu\fR" 4
  .IX Item "-m4-100-nofpu"
! Generate code for \s-1SH4\-100\s0 in such a way that the
! floating-point unit is not used.
! .IP "\fB\-m4\-100\-single\fR" 4
  .IX Item "-m4-100-single"
! Generate code for \s-1SH4\-100\s0 assuming the floating-point unit is in
! single-precision mode by default.
! .IP "\fB\-m4\-100\-single\-only\fR" 4
  .IX Item "-m4-100-single-only"
! Generate code for \s-1SH4\-100\s0 in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m4\-200\fR" 4
  .IX Item "-m4-200"
! Generate code for \s-1SH4\-200.\s0
! .IP "\fB\-m4\-200\-nofpu\fR" 4
  .IX Item "-m4-200-nofpu"
! Generate code for \s-1SH4\-200\s0 without in such a way that the
! floating-point unit is not used.
! .IP "\fB\-m4\-200\-single\fR" 4
  .IX Item "-m4-200-single"
! Generate code for \s-1SH4\-200\s0 assuming the floating-point unit is in
! single-precision mode by default.
! .IP "\fB\-m4\-200\-single\-only\fR" 4
  .IX Item "-m4-200-single-only"
! Generate code for \s-1SH4\-200\s0 in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m4\-300\fR" 4
  .IX Item "-m4-300"
! Generate code for \s-1SH4\-300.\s0
! .IP "\fB\-m4\-300\-nofpu\fR" 4
  .IX Item "-m4-300-nofpu"
! Generate code for \s-1SH4\-300\s0 without in such a way that the
! floating-point unit is not used.
! .IP "\fB\-m4\-300\-single\fR" 4
  .IX Item "-m4-300-single"
! Generate code for \s-1SH4\-300\s0 in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m4\-300\-single\-only\fR" 4
  .IX Item "-m4-300-single-only"
! Generate code for \s-1SH4\-300\s0 in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m4\-340\fR" 4
  .IX Item "-m4-340"
! Generate code for \s-1SH4\-340\s0 (no \s-1MMU,\s0 no \s-1FPU\s0).
! .IP "\fB\-m4\-500\fR" 4
  .IX Item "-m4-500"
! Generate code for \s-1SH4\-500\s0 (no \s-1FPU\s0).  Passes \fB\-isa=sh4\-nofpu\fR to the
  assembler.
! .IP "\fB\-m4a\-nofpu\fR" 4
  .IX Item "-m4a-nofpu"
  Generate code for the SH4al\-dsp, or for a SH4a in such a way that the
! floating-point unit is not used.
! .IP "\fB\-m4a\-single\-only\fR" 4
  .IX Item "-m4a-single-only"
! Generate code for the SH4a, in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m4a\-single\fR" 4
  .IX Item "-m4a-single"
! Generate code for the SH4a assuming the floating-point unit is in
! single-precision mode by default.
! .IP "\fB\-m4a\fR" 4
  .IX Item "-m4a"
  Generate code for the SH4a.
! .IP "\fB\-m4al\fR" 4
  .IX Item "-m4al"
  Same as \fB\-m4a\-nofpu\fR, except that it implicitly passes
! \&\fB\-dsp\fR to the assembler.  \s-1GCC\s0 doesn't generate any \s-1DSP\s0
  instructions at the moment.
! .IP "\fB\-mb\fR" 4
  .IX Item "-mb"
! Compile code for the processor in big-endian mode.
! .IP "\fB\-ml\fR" 4
  .IX Item "-ml"
! Compile code for the processor in little-endian mode.
! .IP "\fB\-mdalign\fR" 4
  .IX Item "-mdalign"
  Align doubles at 64\-bit boundaries.  Note that this changes the calling
  conventions, and thus some functions from the standard C library do
  not work unless you recompile it first with \fB\-mdalign\fR.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Shorten some address references at link time, when possible; uses the
  linker option \fB\-relax\fR.
! .IP "\fB\-mbigtable\fR" 4
  .IX Item "-mbigtable"
  Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables.  The default is to use
  16\-bit offsets.
! .IP "\fB\-mbitops\fR" 4
  .IX Item "-mbitops"
! Enable the use of bit manipulation instructions on \s-1SH2A.\s0
! .IP "\fB\-mfmovd\fR" 4
  .IX Item "-mfmovd"
  Enable the use of the instruction \f(CW\*(C`fmovd\*(C'\fR.  Check \fB\-mdalign\fR for
  alignment constraints.
! .IP "\fB\-mrenesas\fR" 4
  .IX Item "-mrenesas"
  Comply with the calling conventions defined by Renesas.
! .IP "\fB\-mno\-renesas\fR" 4
  .IX Item "-mno-renesas"
! Comply with the calling conventions defined for \s-1GCC\s0 before the Renesas
  conventions were available.  This option is the default for all
! targets of the \s-1SH\s0 toolchain.
! .IP "\fB\-mnomacsave\fR" 4
  .IX Item "-mnomacsave"
! Mark the \f(CW\*(C`MAC\*(C'\fR register as call-clobbered, even if
  \&\fB\-mrenesas\fR is given.
! .IP "\fB\-mieee\fR" 4
  .IX Item "-mieee"
  .PD 0
! .IP "\fB\-mno\-ieee\fR" 4
  .IX Item "-mno-ieee"
  .PD
! Control the \s-1IEEE\s0 compliance of floating-point comparisons, which affects the
  handling of cases where the result of a comparison is unordered.  By default
  \&\fB\-mieee\fR is implicitly enabled.  If \fB\-ffinite\-math\-only\fR is
  enabled \fB\-mno\-ieee\fR is implicitly set, which results in faster
! floating-point greater-equal and less-equal comparisons.  The implicit settings
  can be overridden by specifying either \fB\-mieee\fR or \fB\-mno\-ieee\fR.
! .IP "\fB\-minline\-ic_invalidate\fR" 4
  .IX Item "-minline-ic_invalidate"
  Inline code to invalidate instruction cache entries after setting up
  nested function trampolines.
--- 30046,30223 ----
  This option can be overridden for individual functions with the
  \&\f(CW\*(C`hotpatch\*(C'\fR attribute.
  .PP
! \fISH Options\fR
  .IX Subsection "SH Options"
  .PP
! These \fB\-m\fR options are defined for the SH implementations:
! .IP \fB\-m1\fR 4
  .IX Item "-m1"
! Generate code for the SH1.
! .IP \fB\-m2\fR 4
  .IX Item "-m2"
! Generate code for the SH2.
! .IP \fB\-m2e\fR 4
  .IX Item "-m2e"
  Generate code for the SH2e.
! .IP \fB\-m2a\-nofpu\fR 4
  .IX Item "-m2a-nofpu"
! Generate code for the SH2a without FPU, or for a SH2a\-FPU in such a way
! that the floating\-point unit is not used.
! .IP \fB\-m2a\-single\-only\fR 4
  .IX Item "-m2a-single-only"
! Generate code for the SH2a\-FPU, in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m2a\-single\fR 4
  .IX Item "-m2a-single"
! Generate code for the SH2a\-FPU assuming the floating\-point unit is in
! single\-precision mode by default.
! .IP \fB\-m2a\fR 4
  .IX Item "-m2a"
! Generate code for the SH2a\-FPU assuming the floating\-point unit is in
! double\-precision mode by default.
! .IP \fB\-m3\fR 4
  .IX Item "-m3"
! Generate code for the SH3.
! .IP \fB\-m3e\fR 4
  .IX Item "-m3e"
  Generate code for the SH3e.
! .IP \fB\-m4\-nofpu\fR 4
  .IX Item "-m4-nofpu"
! Generate code for the SH4 without a floating\-point unit.
! .IP \fB\-m4\-single\-only\fR 4
  .IX Item "-m4-single-only"
! Generate code for the SH4 with a floating\-point unit that only
! supports single\-precision arithmetic.
! .IP \fB\-m4\-single\fR 4
  .IX Item "-m4-single"
! Generate code for the SH4 assuming the floating\-point unit is in
! single\-precision mode by default.
! .IP \fB\-m4\fR 4
  .IX Item "-m4"
! Generate code for the SH4.
! .IP \fB\-m4\-100\fR 4
  .IX Item "-m4-100"
! Generate code for SH4\-100.
! .IP \fB\-m4\-100\-nofpu\fR 4
  .IX Item "-m4-100-nofpu"
! Generate code for SH4\-100 in such a way that the
! floating\-point unit is not used.
! .IP \fB\-m4\-100\-single\fR 4
  .IX Item "-m4-100-single"
! Generate code for SH4\-100 assuming the floating\-point unit is in
! single\-precision mode by default.
! .IP \fB\-m4\-100\-single\-only\fR 4
  .IX Item "-m4-100-single-only"
! Generate code for SH4\-100 in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m4\-200\fR 4
  .IX Item "-m4-200"
! Generate code for SH4\-200.
! .IP \fB\-m4\-200\-nofpu\fR 4
  .IX Item "-m4-200-nofpu"
! Generate code for SH4\-200 without in such a way that the
! floating\-point unit is not used.
! .IP \fB\-m4\-200\-single\fR 4
  .IX Item "-m4-200-single"
! Generate code for SH4\-200 assuming the floating\-point unit is in
! single\-precision mode by default.
! .IP \fB\-m4\-200\-single\-only\fR 4
  .IX Item "-m4-200-single-only"
! Generate code for SH4\-200 in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m4\-300\fR 4
  .IX Item "-m4-300"
! Generate code for SH4\-300.
! .IP \fB\-m4\-300\-nofpu\fR 4
  .IX Item "-m4-300-nofpu"
! Generate code for SH4\-300 without in such a way that the
! floating\-point unit is not used.
! .IP \fB\-m4\-300\-single\fR 4
  .IX Item "-m4-300-single"
! Generate code for SH4\-300 in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m4\-300\-single\-only\fR 4
  .IX Item "-m4-300-single-only"
! Generate code for SH4\-300 in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m4\-340\fR 4
  .IX Item "-m4-340"
! Generate code for SH4\-340 (no MMU, no FPU).
! .IP \fB\-m4\-500\fR 4
  .IX Item "-m4-500"
! Generate code for SH4\-500 (no FPU).  Passes \fB\-isa=sh4\-nofpu\fR to the
  assembler.
! .IP \fB\-m4a\-nofpu\fR 4
  .IX Item "-m4a-nofpu"
  Generate code for the SH4al\-dsp, or for a SH4a in such a way that the
! floating\-point unit is not used.
! .IP \fB\-m4a\-single\-only\fR 4
  .IX Item "-m4a-single-only"
! Generate code for the SH4a, in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m4a\-single\fR 4
  .IX Item "-m4a-single"
! Generate code for the SH4a assuming the floating\-point unit is in
! single\-precision mode by default.
! .IP \fB\-m4a\fR 4
  .IX Item "-m4a"
  Generate code for the SH4a.
! .IP \fB\-m4al\fR 4
  .IX Item "-m4al"
  Same as \fB\-m4a\-nofpu\fR, except that it implicitly passes
! \&\fB\-dsp\fR to the assembler.  GCC doesn\*(Aqt generate any DSP
  instructions at the moment.
! .IP \fB\-mb\fR 4
  .IX Item "-mb"
! Compile code for the processor in big\-endian mode.
! .IP \fB\-ml\fR 4
  .IX Item "-ml"
! Compile code for the processor in little\-endian mode.
! .IP \fB\-mdalign\fR 4
  .IX Item "-mdalign"
  Align doubles at 64\-bit boundaries.  Note that this changes the calling
  conventions, and thus some functions from the standard C library do
  not work unless you recompile it first with \fB\-mdalign\fR.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Shorten some address references at link time, when possible; uses the
  linker option \fB\-relax\fR.
! .IP \fB\-mbigtable\fR 4
  .IX Item "-mbigtable"
  Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables.  The default is to use
  16\-bit offsets.
! .IP \fB\-mbitops\fR 4
  .IX Item "-mbitops"
! Enable the use of bit manipulation instructions on SH2A.
! .IP \fB\-mfmovd\fR 4
  .IX Item "-mfmovd"
  Enable the use of the instruction \f(CW\*(C`fmovd\*(C'\fR.  Check \fB\-mdalign\fR for
  alignment constraints.
! .IP \fB\-mrenesas\fR 4
  .IX Item "-mrenesas"
  Comply with the calling conventions defined by Renesas.
! .IP \fB\-mno\-renesas\fR 4
  .IX Item "-mno-renesas"
! Comply with the calling conventions defined for GCC before the Renesas
  conventions were available.  This option is the default for all
! targets of the SH toolchain.
! .IP \fB\-mnomacsave\fR 4
  .IX Item "-mnomacsave"
! Mark the \f(CW\*(C`MAC\*(C'\fR register as call\-clobbered, even if
  \&\fB\-mrenesas\fR is given.
! .IP \fB\-mieee\fR 4
  .IX Item "-mieee"
  .PD 0
! .IP \fB\-mno\-ieee\fR 4
  .IX Item "-mno-ieee"
  .PD
! Control the IEEE compliance of floating\-point comparisons, which affects the
  handling of cases where the result of a comparison is unordered.  By default
  \&\fB\-mieee\fR is implicitly enabled.  If \fB\-ffinite\-math\-only\fR is
  enabled \fB\-mno\-ieee\fR is implicitly set, which results in faster
! floating\-point greater\-equal and less\-equal comparisons.  The implicit settings
  can be overridden by specifying either \fB\-mieee\fR or \fB\-mno\-ieee\fR.
! .IP \fB\-minline\-ic_invalidate\fR 4
  .IX Item "-minline-ic_invalidate"
  Inline code to invalidate instruction cache entries after setting up
  nested function trampolines.
*************** If the selected code generation option d
*** 30297,30364 ****
  instruction, and \fB\-musermode\fR is not in effect, the inlined code
  manipulates the instruction cache address array directly with an associative
  write.  This not only requires privileged mode at run time, but it also
! fails if the cache line had been mapped via the \s-1TLB\s0 and has become unmapped.
! .IP "\fB\-misize\fR" 4
  .IX Item "-misize"
  Dump instruction size and location in the assembly code.
! .IP "\fB\-mpadstruct\fR" 4
  .IX Item "-mpadstruct"
  This option is deprecated.  It pads structures to multiple of 4 bytes,
! which is incompatible with the \s-1SH ABI.\s0
! .IP "\fB\-matomic\-model=\fR\fImodel\fR" 4
  .IX Item "-matomic-model=model"
  Sets the model of atomic operations and additional parameters as a comma
! separated list.  For details on the atomic built-in functions see
  \&\fB_\|_atomic Builtins\fR.  The following models and parameters are supported:
  .RS 4
! .IP "\fBnone\fR" 4
  .IX Item "none"
  Disable compiler generated atomic sequences and emit library calls for atomic
  operations.  This is the default if the target is not \f(CW\*(C`sh*\-*\-linux*\*(C'\fR.
! .IP "\fBsoft-gusa\fR" 4
  .IX Item "soft-gusa"
  Generate GNU/Linux compatible gUSA software atomic sequences for the atomic
! built-in functions.  The generated atomic sequences require additional support
  from the interrupt/exception handling code of the system and are only suitable
! for SH3* and SH4* single-core systems.  This option is enabled by default when
! the target is \f(CW\*(C`sh*\-*\-linux*\*(C'\fR and SH3* or SH4*.  When the target is \s-1SH4A,\s0
  this option also partially utilizes the hardware atomic instructions
  \&\f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR to create more efficient code, unless
  \&\fBstrict\fR is specified.
! .IP "\fBsoft-tcb\fR" 4
  .IX Item "soft-tcb"
  Generate software atomic sequences that use a variable in the thread control
  block.  This is a variation of the gUSA sequences which can also be used on
  SH1* and SH2* targets.  The generated atomic sequences require additional
  support from the interrupt/exception handling code of the system and are only
! suitable for single-core systems.  When using this model, the \fBgbr\-offset=\fR
  parameter has to be specified as well.
! .IP "\fBsoft-imask\fR" 4
  .IX Item "soft-imask"
  Generate software atomic sequences that temporarily disable interrupts by
  setting \f(CW\*(C`SR.IMASK = 1111\*(C'\fR.  This model works only when the program runs
! in privileged mode and is only suitable for single-core systems.  Additional
  support from the interrupt/exception handling code of the system is not
  required.  This model is enabled by default when the target is
  \&\f(CW\*(C`sh*\-*\-linux*\*(C'\fR and SH1* or SH2*.
! .IP "\fBhard-llcs\fR" 4
  .IX Item "hard-llcs"
  Generate hardware atomic sequences using the \f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR
! instructions only.  This is only available on \s-1SH4A\s0 and is suitable for
! multi-core systems.  Since the hardware instructions support only 32 bit atomic
  variables access to 8 or 16 bit variables is emulated with 32 bit accesses.
  Code compiled with this option is also compatible with other software
! atomic model interrupt/exception handling systems if executed on an \s-1SH4A\s0
  system.  Additional support from the interrupt/exception handling code of the
  system is not required for this model.
! .IP "\fBgbr\-offset=\fR" 4
  .IX Item "gbr-offset="
  This parameter specifies the offset in bytes of the variable in the thread
  control block structure that should be used by the generated atomic sequences
! when the \fBsoft-tcb\fR model has been selected.  For other models this
  parameter is ignored.  The specified value must be an integer multiple of four
  and in the range 0\-1020.
! .IP "\fBstrict\fR" 4
  .IX Item "strict"
  This parameter prevents mixed usage of multiple atomic models, even if they
  are compatible, and makes the compiler generate atomic sequences of the
--- 30228,30295 ----
  instruction, and \fB\-musermode\fR is not in effect, the inlined code
  manipulates the instruction cache address array directly with an associative
  write.  This not only requires privileged mode at run time, but it also
! fails if the cache line had been mapped via the TLB and has become unmapped.
! .IP \fB\-misize\fR 4
  .IX Item "-misize"
  Dump instruction size and location in the assembly code.
! .IP \fB\-mpadstruct\fR 4
  .IX Item "-mpadstruct"
  This option is deprecated.  It pads structures to multiple of 4 bytes,
! which is incompatible with the SH ABI.
! .IP \fB\-matomic\-model=\fR\fImodel\fR 4
  .IX Item "-matomic-model=model"
  Sets the model of atomic operations and additional parameters as a comma
! separated list.  For details on the atomic built\-in functions see
  \&\fB_\|_atomic Builtins\fR.  The following models and parameters are supported:
  .RS 4
! .IP \fBnone\fR 4
  .IX Item "none"
  Disable compiler generated atomic sequences and emit library calls for atomic
  operations.  This is the default if the target is not \f(CW\*(C`sh*\-*\-linux*\*(C'\fR.
! .IP \fBsoft\-gusa\fR 4
  .IX Item "soft-gusa"
  Generate GNU/Linux compatible gUSA software atomic sequences for the atomic
! built\-in functions.  The generated atomic sequences require additional support
  from the interrupt/exception handling code of the system and are only suitable
! for SH3* and SH4* single\-core systems.  This option is enabled by default when
! the target is \f(CW\*(C`sh*\-*\-linux*\*(C'\fR and SH3* or SH4*.  When the target is SH4A,
  this option also partially utilizes the hardware atomic instructions
  \&\f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR to create more efficient code, unless
  \&\fBstrict\fR is specified.
! .IP \fBsoft\-tcb\fR 4
  .IX Item "soft-tcb"
  Generate software atomic sequences that use a variable in the thread control
  block.  This is a variation of the gUSA sequences which can also be used on
  SH1* and SH2* targets.  The generated atomic sequences require additional
  support from the interrupt/exception handling code of the system and are only
! suitable for single\-core systems.  When using this model, the \fBgbr\-offset=\fR
  parameter has to be specified as well.
! .IP \fBsoft\-imask\fR 4
  .IX Item "soft-imask"
  Generate software atomic sequences that temporarily disable interrupts by
  setting \f(CW\*(C`SR.IMASK = 1111\*(C'\fR.  This model works only when the program runs
! in privileged mode and is only suitable for single\-core systems.  Additional
  support from the interrupt/exception handling code of the system is not
  required.  This model is enabled by default when the target is
  \&\f(CW\*(C`sh*\-*\-linux*\*(C'\fR and SH1* or SH2*.
! .IP \fBhard\-llcs\fR 4
  .IX Item "hard-llcs"
  Generate hardware atomic sequences using the \f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR
! instructions only.  This is only available on SH4A and is suitable for
! multi\-core systems.  Since the hardware instructions support only 32 bit atomic
  variables access to 8 or 16 bit variables is emulated with 32 bit accesses.
  Code compiled with this option is also compatible with other software
! atomic model interrupt/exception handling systems if executed on an SH4A
  system.  Additional support from the interrupt/exception handling code of the
  system is not required for this model.
! .IP \fBgbr\-offset=\fR 4
  .IX Item "gbr-offset="
  This parameter specifies the offset in bytes of the variable in the thread
  control block structure that should be used by the generated atomic sequences
! when the \fBsoft\-tcb\fR model has been selected.  For other models this
  parameter is ignored.  The specified value must be an integer multiple of four
  and in the range 0\-1020.
! .IP \fBstrict\fR 4
  .IX Item "strict"
  This parameter prevents mixed usage of multiple atomic models, even if they
  are compatible, and makes the compiler generate atomic sequences of the
*************** specified model only.
*** 30366,30677 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-mtas\fR" 4
  .IX Item "-mtas"
  Generate the \f(CW\*(C`tas.b\*(C'\fR opcode for \f(CW\*(C`_\|_atomic_test_and_set\*(C'\fR.
  Notice that depending on the particular hardware and software configuration
  this can degrade overall performance due to the operand cache line flushes
! that are implied by the \f(CW\*(C`tas.b\*(C'\fR instruction.  On multi-core \s-1SH4A\s0
  processors the \f(CW\*(C`tas.b\*(C'\fR instruction must be used with caution since it
  can result in data corruption for certain cache configurations.
! .IP "\fB\-mprefergot\fR" 4
  .IX Item "-mprefergot"
! When generating position-independent code, emit function calls using
  the Global Offset Table instead of the Procedure Linkage Table.
! .IP "\fB\-musermode\fR" 4
  .IX Item "-musermode"
  .PD 0
! .IP "\fB\-mno\-usermode\fR" 4
  .IX Item "-mno-usermode"
  .PD
! Don't allow (allow) the compiler generating privileged mode code.  Specifying
  \&\fB\-musermode\fR also implies \fB\-mno\-inline\-ic_invalidate\fR if the
  inlined code would not work in user mode.  \fB\-musermode\fR is the default
  when the target is \f(CW\*(C`sh*\-*\-linux*\*(C'\fR.  If the target is SH1* or SH2*
  \&\fB\-musermode\fR has no effect, since there is no user mode.
! .IP "\fB\-multcost=\fR\fInumber\fR" 4
  .IX Item "-multcost=number"
  Set the cost to assume for a multiply insn.
! .IP "\fB\-mdiv=\fR\fIstrategy\fR" 4
  .IX Item "-mdiv=strategy"
  Set the division strategy to be used for integer division operations.
  \&\fIstrategy\fR can be one of:
  .RS 4
! .IP "\fBcall\-div1\fR" 4
  .IX Item "call-div1"
! Calls a library function that uses the single-step division instruction
  \&\f(CW\*(C`div1\*(C'\fR to perform the operation.  Division by zero calculates an
! unspecified result and does not trap.  This is the default except for \s-1SH4,
! SH2A\s0 and SHcompact.
! .IP "\fBcall-fp\fR" 4
  .IX Item "call-fp"
  Calls a library function that performs the operation in double precision
! floating point.  Division by zero causes a floating-point exception.  This is
! the default for SHcompact with \s-1FPU.\s0  Specifying this for targets that do not
! have a double precision \s-1FPU\s0 defaults to \f(CW\*(C`call\-div1\*(C'\fR.
! .IP "\fBcall-table\fR" 4
  .IX Item "call-table"
  Calls a library function that uses a lookup table for small divisors and
  the \f(CW\*(C`div1\*(C'\fR instruction with case distinction for larger divisors.  Division
  by zero calculates an unspecified result and does not trap.  This is the default
! for \s-1SH4.\s0  Specifying this for targets that do not have dynamic shift
  instructions defaults to \f(CW\*(C`call\-div1\*(C'\fR.
  .RE
  .RS 4
  .Sp
  When a division strategy has not been specified the default strategy is
! selected based on the current target.  For \s-1SH2A\s0 the default strategy is to
  use the \f(CW\*(C`divs\*(C'\fR and \f(CW\*(C`divu\*(C'\fR instructions instead of library function
  calls.
  .RE
! .IP "\fB\-maccumulate\-outgoing\-args\fR" 4
  .IX Item "-maccumulate-outgoing-args"
  Reserve space once for outgoing arguments in the function prologue rather
  than around each call.  Generally beneficial for performance and size.  Also
  needed for unwinding to avoid changing the stack frame around conditional code.
! .IP "\fB\-mdivsi3_libfunc=\fR\fIname\fR" 4
  .IX Item "-mdivsi3_libfunc=name"
  Set the name of the library function used for 32\-bit signed division to
  \&\fIname\fR.
  This only affects the name used in the \fBcall\fR division strategies, and
  the compiler still expects the same sets of input/output/clobbered registers as
  if this option were not present.
! .IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP "\fB\-mbranch\-cost=\fR\fInum\fR" 4
  .IX Item "-mbranch-cost=num"
  Assume \fInum\fR to be the cost for a branch instruction.  Higher numbers
! make the compiler try to generate more branch-free code if possible.  
  If not specified the value is selected depending on the processor type that
  is being compiled for.
! .IP "\fB\-mzdcbranch\fR" 4
  .IX Item "-mzdcbranch"
  .PD 0
! .IP "\fB\-mno\-zdcbranch\fR" 4
  .IX Item "-mno-zdcbranch"
  .PD
  Assume (do not assume) that zero displacement conditional branch instructions
  \&\f(CW\*(C`bt\*(C'\fR and \f(CW\*(C`bf\*(C'\fR are fast.  If \fB\-mzdcbranch\fR is specified, the
  compiler prefers zero displacement branch code sequences.  This is
! enabled by default when generating code for \s-1SH4\s0 and \s-1SH4A.\s0  It can be explicitly
  disabled by specifying \fB\-mno\-zdcbranch\fR.
! .IP "\fB\-mcbranch\-force\-delay\-slot\fR" 4
  .IX Item "-mcbranch-force-delay-slot"
  Force the usage of delay slots for conditional branches, which stuffs the delay
  slot with a \f(CW\*(C`nop\*(C'\fR if a suitable instruction cannot be found.  By default
  this option is disabled.  It can be enabled to work around hardware bugs as
! found in the original \s-1SH7055.\s0
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating-point multiply and
  accumulate instructions.  These instructions are generated by default
! if hardware floating point is used.  The machine-dependent
! \&\fB\-mfused\-madd\fR option is now mapped to the machine-independent
  \&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
  mapped to \fB\-ffp\-contract=off\fR.
! .IP "\fB\-mfsca\fR" 4
  .IX Item "-mfsca"
  .PD 0
! .IP "\fB\-mno\-fsca\fR" 4
  .IX Item "-mno-fsca"
  .PD
  Allow or disallow the compiler to emit the \f(CW\*(C`fsca\*(C'\fR instruction for sine
  and cosine approximations.  The option \fB\-mfsca\fR must be used in
  combination with \fB\-funsafe\-math\-optimizations\fR.  It is enabled by default
! when generating code for \s-1SH4A.\s0  Using \fB\-mno\-fsca\fR disables sine and cosine
  approximations even if \fB\-funsafe\-math\-optimizations\fR is in effect.
! .IP "\fB\-mfsrra\fR" 4
  .IX Item "-mfsrra"
  .PD 0
! .IP "\fB\-mno\-fsrra\fR" 4
  .IX Item "-mno-fsrra"
  .PD
  Allow or disallow the compiler to emit the \f(CW\*(C`fsrra\*(C'\fR instruction for
  reciprocal square root approximations.  The option \fB\-mfsrra\fR must be used
  in combination with \fB\-funsafe\-math\-optimizations\fR and
  \&\fB\-ffinite\-math\-only\fR.  It is enabled by default when generating code for
! \&\s-1SH4A.\s0  Using \fB\-mno\-fsrra\fR disables reciprocal square root approximations
  even if \fB\-funsafe\-math\-optimizations\fR and \fB\-ffinite\-math\-only\fR are
  in effect.
! .IP "\fB\-mpretend\-cmove\fR" 4
  .IX Item "-mpretend-cmove"
! Prefer zero-displacement conditional branches for conditional move instruction
! patterns.  This can result in faster code on the \s-1SH4\s0 processor.
! .IP "\fB\-mfdpic\fR" 4
  .IX Item "-mfdpic"
! Generate code using the \s-1FDPIC ABI.\s0
  .PP
  \fISolaris 2 Options\fR
  .IX Subsection "Solaris 2 Options"
  .PP
  These \fB\-m\fR options are supported on Solaris 2:
! .IP "\fB\-mclear\-hwcap\fR" 4
  .IX Item "-mclear-hwcap"
  \&\fB\-mclear\-hwcap\fR tells the compiler to remove the hardware
  capabilities generated by the Solaris assembler.  This is only necessary
! when object files use \s-1ISA\s0 extensions not supported by the current
  machine, but check at runtime whether or not to use them.
! .IP "\fB\-mimpure\-text\fR" 4
  .IX Item "-mimpure-text"
  \&\fB\-mimpure\-text\fR, used in addition to \fB\-shared\fR, tells
  the compiler to not pass \fB\-z text\fR to the linker when linking a
! shared object.  Using this option, you can link position-dependent
  code into a shared object.
  .Sp
! \&\fB\-mimpure\-text\fR suppresses the \*(L"relocations remain against
! allocatable but non-writable sections\*(R" linker error message.
! However, the necessary relocations trigger copy-on-write, and the
  shared object is not actually shared across processes.  Instead of
  using \fB\-mimpure\-text\fR, you should compile all source code with
  \&\fB\-fpic\fR or \fB\-fPIC\fR.
  .PP
  These switches are supported in addition to the above on Solaris 2:
! .IP "\fB\-pthreads\fR" 4
  .IX Item "-pthreads"
  This is a synonym for \fB\-pthread\fR.
  .PP
! \fI\s-1SPARC\s0 Options\fR
  .IX Subsection "SPARC Options"
  .PP
! These \fB\-m\fR options are supported on the \s-1SPARC:\s0
! .IP "\fB\-mno\-app\-regs\fR" 4
  .IX Item "-mno-app-regs"
  .PD 0
! .IP "\fB\-mapp\-regs\fR" 4
  .IX Item "-mapp-regs"
  .PD
  Specify \fB\-mapp\-regs\fR to generate output using the global registers
! 2 through 4, which the \s-1SPARC SVR4 ABI\s0 reserves for applications.  Like the
  global register 1, each global register 2 through 4 is then treated as an
  allocable register that is clobbered by function calls.  This is the default.
  .Sp
! To be fully \s-1SVR4\s0 ABI-compliant at the cost of some performance loss,
  specify \fB\-mno\-app\-regs\fR.  You should compile libraries and system
  software with this option.
! .IP "\fB\-mflat\fR" 4
  .IX Item "-mflat"
  .PD 0
! .IP "\fB\-mno\-flat\fR" 4
  .IX Item "-mno-flat"
  .PD
  With \fB\-mflat\fR, the compiler does not generate save/restore instructions
! and uses a \*(L"flat\*(R" or single register window model.  This model is compatible
  with the regular register window model.  The local registers and the input
! registers (0\-\-5) are still treated as \*(L"call-saved\*(R" registers and are
  saved on the stack as needed.
  .Sp
  With \fB\-mno\-flat\fR (the default), the compiler generates save/restore
  instructions (except for leaf functions).  This is the normal operating mode.
! .IP "\fB\-mfpu\fR" 4
  .IX Item "-mfpu"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
! Generate output containing floating-point instructions.  This is the
  default.
! .IP "\fB\-mno\-fpu\fR" 4
  .IX Item "-mno-fpu"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
  Generate output containing library calls for floating point.
! \&\fBWarning:\fR the requisite libraries are not available for all \s-1SPARC\s0
! targets.  Normally the facilities of the machine's usual C compiler are
! used, but this cannot be done directly in cross-compilation.  You must make
  your own arrangements to provide suitable library functions for
! cross-compilation.  The embedded targets \fBsparc\-*\-aout\fR and
! \&\fBsparclite\-*\-*\fR do provide software floating-point support.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with \s-1GCC,\s0 with \fB\-msoft\-float\fR in order for
  this to work.
! .IP "\fB\-mhard\-quad\-float\fR" 4
  .IX Item "-mhard-quad-float"
! Generate output containing quad-word (long double) floating-point
  instructions.
! .IP "\fB\-msoft\-quad\-float\fR" 4
  .IX Item "-msoft-quad-float"
! Generate output containing library calls for quad-word (long double)
! floating-point instructions.  The functions called are those specified
! in the \s-1SPARC ABI.\s0  This is the default.
  .Sp
! As of this writing, there are no \s-1SPARC\s0 implementations that have hardware
! support for the quad-word floating-point instructions.  They all invoke
  a trap handler for one of these instructions, and then the trap handler
  emulates the effect of the instruction.  Because of the trap handler overhead,
! this is much slower than calling the \s-1ABI\s0 library routines.  Thus the
  \&\fB\-msoft\-quad\-float\fR option is the default.
! .IP "\fB\-mno\-unaligned\-doubles\fR" 4
  .IX Item "-mno-unaligned-doubles"
  .PD 0
! .IP "\fB\-munaligned\-doubles\fR" 4
  .IX Item "-munaligned-doubles"
  .PD
  Assume that doubles have 8\-byte alignment.  This is the default.
  .Sp
! With \fB\-munaligned\-doubles\fR, \s-1GCC\s0 assumes that doubles have 8\-byte
  alignment only if they are contained in another type, or if they have an
  absolute address.  Otherwise, it assumes they have 4\-byte alignment.
  Specifying this option avoids some rare compatibility problems with code
  generated by other compilers.  It is not the default because it results
! in a performance loss, especially for floating-point code.
! .IP "\fB\-muser\-mode\fR" 4
  .IX Item "-muser-mode"
  .PD 0
! .IP "\fB\-mno\-user\-mode\fR" 4
  .IX Item "-mno-user-mode"
  .PD
  Do not generate code that can only run in supervisor mode.  This is relevant
! only for the \f(CW\*(C`casa\*(C'\fR instruction emitted for the \s-1LEON3\s0 processor.  This
  is the default.
! .IP "\fB\-mfaster\-structs\fR" 4
  .IX Item "-mfaster-structs"
  .PD 0
! .IP "\fB\-mno\-faster\-structs\fR" 4
  .IX Item "-mno-faster-structs"
  .PD
  With \fB\-mfaster\-structs\fR, the compiler assumes that structures
  should have 8\-byte alignment.  This enables the use of pairs of
  \&\f(CW\*(C`ldd\*(C'\fR and \f(CW\*(C`std\*(C'\fR instructions for copies in structure
  assignment, in place of twice as many \f(CW\*(C`ld\*(C'\fR and \f(CW\*(C`st\*(C'\fR pairs.
! However, the use of this changed alignment directly violates the \s-1SPARC
! ABI.\s0  Thus, it's intended only for use on targets where the developer
  acknowledges that their resulting code is not directly in line with
! the rules of the \s-1ABI.\s0
! .IP "\fB\-mstd\-struct\-return\fR" 4
  .IX Item "-mstd-struct-return"
  .PD 0
! .IP "\fB\-mno\-std\-struct\-return\fR" 4
  .IX Item "-mno-std-struct-return"
  .PD
  With \fB\-mstd\-struct\-return\fR, the compiler generates checking code
  in functions returning structures or unions to detect size mismatches
! between the two sides of function calls, as per the 32\-bit \s-1ABI.\s0
  .Sp
  The default is \fB\-mno\-std\-struct\-return\fR.  This option has no effect
  in 64\-bit mode.
! .IP "\fB\-mlra\fR" 4
  .IX Item "-mlra"
  .PD 0
! .IP "\fB\-mno\-lra\fR" 4
  .IX Item "-mno-lra"
  .PD
! Enable Local Register Allocation.  This is the default for \s-1SPARC\s0 since \s-1GCC 7\s0
  so \fB\-mno\-lra\fR needs to be passed to get old Reload.
! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set, register set, and instruction scheduling parameters
  for machine type \fIcpu_type\fR.  Supported values for \fIcpu_type\fR are
--- 30297,30608 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-mtas\fR 4
  .IX Item "-mtas"
  Generate the \f(CW\*(C`tas.b\*(C'\fR opcode for \f(CW\*(C`_\|_atomic_test_and_set\*(C'\fR.
  Notice that depending on the particular hardware and software configuration
  this can degrade overall performance due to the operand cache line flushes
! that are implied by the \f(CW\*(C`tas.b\*(C'\fR instruction.  On multi\-core SH4A
  processors the \f(CW\*(C`tas.b\*(C'\fR instruction must be used with caution since it
  can result in data corruption for certain cache configurations.
! .IP \fB\-mprefergot\fR 4
  .IX Item "-mprefergot"
! When generating position\-independent code, emit function calls using
  the Global Offset Table instead of the Procedure Linkage Table.
! .IP \fB\-musermode\fR 4
  .IX Item "-musermode"
  .PD 0
! .IP \fB\-mno\-usermode\fR 4
  .IX Item "-mno-usermode"
  .PD
! Don\*(Aqt allow (allow) the compiler generating privileged mode code.  Specifying
  \&\fB\-musermode\fR also implies \fB\-mno\-inline\-ic_invalidate\fR if the
  inlined code would not work in user mode.  \fB\-musermode\fR is the default
  when the target is \f(CW\*(C`sh*\-*\-linux*\*(C'\fR.  If the target is SH1* or SH2*
  \&\fB\-musermode\fR has no effect, since there is no user mode.
! .IP \fB\-multcost=\fR\fInumber\fR 4
  .IX Item "-multcost=number"
  Set the cost to assume for a multiply insn.
! .IP \fB\-mdiv=\fR\fIstrategy\fR 4
  .IX Item "-mdiv=strategy"
  Set the division strategy to be used for integer division operations.
  \&\fIstrategy\fR can be one of:
  .RS 4
! .IP \fBcall\-div1\fR 4
  .IX Item "call-div1"
! Calls a library function that uses the single\-step division instruction
  \&\f(CW\*(C`div1\*(C'\fR to perform the operation.  Division by zero calculates an
! unspecified result and does not trap.  This is the default except for SH4,
! SH2A and SHcompact.
! .IP \fBcall\-fp\fR 4
  .IX Item "call-fp"
  Calls a library function that performs the operation in double precision
! floating point.  Division by zero causes a floating\-point exception.  This is
! the default for SHcompact with FPU.  Specifying this for targets that do not
! have a double precision FPU defaults to \f(CW\*(C`call\-div1\*(C'\fR.
! .IP \fBcall\-table\fR 4
  .IX Item "call-table"
  Calls a library function that uses a lookup table for small divisors and
  the \f(CW\*(C`div1\*(C'\fR instruction with case distinction for larger divisors.  Division
  by zero calculates an unspecified result and does not trap.  This is the default
! for SH4.  Specifying this for targets that do not have dynamic shift
  instructions defaults to \f(CW\*(C`call\-div1\*(C'\fR.
  .RE
  .RS 4
  .Sp
  When a division strategy has not been specified the default strategy is
! selected based on the current target.  For SH2A the default strategy is to
  use the \f(CW\*(C`divs\*(C'\fR and \f(CW\*(C`divu\*(C'\fR instructions instead of library function
  calls.
  .RE
! .IP \fB\-maccumulate\-outgoing\-args\fR 4
  .IX Item "-maccumulate-outgoing-args"
  Reserve space once for outgoing arguments in the function prologue rather
  than around each call.  Generally beneficial for performance and size.  Also
  needed for unwinding to avoid changing the stack frame around conditional code.
! .IP \fB\-mdivsi3_libfunc=\fR\fIname\fR 4
  .IX Item "-mdivsi3_libfunc=name"
  Set the name of the library function used for 32\-bit signed division to
  \&\fIname\fR.
  This only affects the name used in the \fBcall\fR division strategies, and
  the compiler still expects the same sets of input/output/clobbered registers as
  if this option were not present.
! .IP \fB\-mfixed\-range=\fR\fIregister\-range\fR 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP \fB\-mbranch\-cost=\fR\fInum\fR 4
  .IX Item "-mbranch-cost=num"
  Assume \fInum\fR to be the cost for a branch instruction.  Higher numbers
! make the compiler try to generate more branch\-free code if possible.  
  If not specified the value is selected depending on the processor type that
  is being compiled for.
! .IP \fB\-mzdcbranch\fR 4
  .IX Item "-mzdcbranch"
  .PD 0
! .IP \fB\-mno\-zdcbranch\fR 4
  .IX Item "-mno-zdcbranch"
  .PD
  Assume (do not assume) that zero displacement conditional branch instructions
  \&\f(CW\*(C`bt\*(C'\fR and \f(CW\*(C`bf\*(C'\fR are fast.  If \fB\-mzdcbranch\fR is specified, the
  compiler prefers zero displacement branch code sequences.  This is
! enabled by default when generating code for SH4 and SH4A.  It can be explicitly
  disabled by specifying \fB\-mno\-zdcbranch\fR.
! .IP \fB\-mcbranch\-force\-delay\-slot\fR 4
  .IX Item "-mcbranch-force-delay-slot"
  Force the usage of delay slots for conditional branches, which stuffs the delay
  slot with a \f(CW\*(C`nop\*(C'\fR if a suitable instruction cannot be found.  By default
  this option is disabled.  It can be enabled to work around hardware bugs as
! found in the original SH7055.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating\-point multiply and
  accumulate instructions.  These instructions are generated by default
! if hardware floating point is used.  The machine\-dependent
! \&\fB\-mfused\-madd\fR option is now mapped to the machine\-independent
  \&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
  mapped to \fB\-ffp\-contract=off\fR.
! .IP \fB\-mfsca\fR 4
  .IX Item "-mfsca"
  .PD 0
! .IP \fB\-mno\-fsca\fR 4
  .IX Item "-mno-fsca"
  .PD
  Allow or disallow the compiler to emit the \f(CW\*(C`fsca\*(C'\fR instruction for sine
  and cosine approximations.  The option \fB\-mfsca\fR must be used in
  combination with \fB\-funsafe\-math\-optimizations\fR.  It is enabled by default
! when generating code for SH4A.  Using \fB\-mno\-fsca\fR disables sine and cosine
  approximations even if \fB\-funsafe\-math\-optimizations\fR is in effect.
! .IP \fB\-mfsrra\fR 4
  .IX Item "-mfsrra"
  .PD 0
! .IP \fB\-mno\-fsrra\fR 4
  .IX Item "-mno-fsrra"
  .PD
  Allow or disallow the compiler to emit the \f(CW\*(C`fsrra\*(C'\fR instruction for
  reciprocal square root approximations.  The option \fB\-mfsrra\fR must be used
  in combination with \fB\-funsafe\-math\-optimizations\fR and
  \&\fB\-ffinite\-math\-only\fR.  It is enabled by default when generating code for
! SH4A.  Using \fB\-mno\-fsrra\fR disables reciprocal square root approximations
  even if \fB\-funsafe\-math\-optimizations\fR and \fB\-ffinite\-math\-only\fR are
  in effect.
! .IP \fB\-mpretend\-cmove\fR 4
  .IX Item "-mpretend-cmove"
! Prefer zero\-displacement conditional branches for conditional move instruction
! patterns.  This can result in faster code on the SH4 processor.
! .IP \fB\-mfdpic\fR 4
  .IX Item "-mfdpic"
! Generate code using the FDPIC ABI.
  .PP
  \fISolaris 2 Options\fR
  .IX Subsection "Solaris 2 Options"
  .PP
  These \fB\-m\fR options are supported on Solaris 2:
! .IP \fB\-mclear\-hwcap\fR 4
  .IX Item "-mclear-hwcap"
  \&\fB\-mclear\-hwcap\fR tells the compiler to remove the hardware
  capabilities generated by the Solaris assembler.  This is only necessary
! when object files use ISA extensions not supported by the current
  machine, but check at runtime whether or not to use them.
! .IP \fB\-mimpure\-text\fR 4
  .IX Item "-mimpure-text"
  \&\fB\-mimpure\-text\fR, used in addition to \fB\-shared\fR, tells
  the compiler to not pass \fB\-z text\fR to the linker when linking a
! shared object.  Using this option, you can link position\-dependent
  code into a shared object.
  .Sp
! \&\fB\-mimpure\-text\fR suppresses the "relocations remain against
! allocatable but non\-writable sections" linker error message.
! However, the necessary relocations trigger copy\-on\-write, and the
  shared object is not actually shared across processes.  Instead of
  using \fB\-mimpure\-text\fR, you should compile all source code with
  \&\fB\-fpic\fR or \fB\-fPIC\fR.
  .PP
  These switches are supported in addition to the above on Solaris 2:
! .IP \fB\-pthreads\fR 4
  .IX Item "-pthreads"
  This is a synonym for \fB\-pthread\fR.
  .PP
! \fISPARC Options\fR
  .IX Subsection "SPARC Options"
  .PP
! These \fB\-m\fR options are supported on the SPARC:
! .IP \fB\-mno\-app\-regs\fR 4
  .IX Item "-mno-app-regs"
  .PD 0
! .IP \fB\-mapp\-regs\fR 4
  .IX Item "-mapp-regs"
  .PD
  Specify \fB\-mapp\-regs\fR to generate output using the global registers
! 2 through 4, which the SPARC SVR4 ABI reserves for applications.  Like the
  global register 1, each global register 2 through 4 is then treated as an
  allocable register that is clobbered by function calls.  This is the default.
  .Sp
! To be fully SVR4 ABI\-compliant at the cost of some performance loss,
  specify \fB\-mno\-app\-regs\fR.  You should compile libraries and system
  software with this option.
! .IP \fB\-mflat\fR 4
  .IX Item "-mflat"
  .PD 0
! .IP \fB\-mno\-flat\fR 4
  .IX Item "-mno-flat"
  .PD
  With \fB\-mflat\fR, the compiler does not generate save/restore instructions
! and uses a "flat" or single register window model.  This model is compatible
  with the regular register window model.  The local registers and the input
! registers (0\-\-5) are still treated as "call\-saved" registers and are
  saved on the stack as needed.
  .Sp
  With \fB\-mno\-flat\fR (the default), the compiler generates save/restore
  instructions (except for leaf functions).  This is the normal operating mode.
! .IP \fB\-mfpu\fR 4
  .IX Item "-mfpu"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
! Generate output containing floating\-point instructions.  This is the
  default.
! .IP \fB\-mno\-fpu\fR 4
  .IX Item "-mno-fpu"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
  Generate output containing library calls for floating point.
! \&\fBWarning:\fR the requisite libraries are not available for all SPARC
! targets.  Normally the facilities of the machine\*(Aqs usual C compiler are
! used, but this cannot be done directly in cross\-compilation.  You must make
  your own arrangements to provide suitable library functions for
! cross\-compilation.  The embedded targets \fBsparc\-*\-aout\fR and
! \&\fBsparclite\-*\-*\fR do provide software floating\-point support.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with GCC, with \fB\-msoft\-float\fR in order for
  this to work.
! .IP \fB\-mhard\-quad\-float\fR 4
  .IX Item "-mhard-quad-float"
! Generate output containing quad\-word (long double) floating\-point
  instructions.
! .IP \fB\-msoft\-quad\-float\fR 4
  .IX Item "-msoft-quad-float"
! Generate output containing library calls for quad\-word (long double)
! floating\-point instructions.  The functions called are those specified
! in the SPARC ABI.  This is the default.
  .Sp
! 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
  \&\fB\-msoft\-quad\-float\fR option is the default.
! .IP \fB\-mno\-unaligned\-doubles\fR 4
  .IX Item "-mno-unaligned-doubles"
  .PD 0
! .IP \fB\-munaligned\-doubles\fR 4
  .IX Item "-munaligned-doubles"
  .PD
  Assume that doubles have 8\-byte alignment.  This is the default.
  .Sp
! With \fB\-munaligned\-doubles\fR, 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.
! .IP \fB\-muser\-mode\fR 4
  .IX Item "-muser-mode"
  .PD 0
! .IP \fB\-mno\-user\-mode\fR 4
  .IX Item "-mno-user-mode"
  .PD
  Do not generate code that can only run in supervisor mode.  This is relevant
! only for the \f(CW\*(C`casa\*(C'\fR instruction emitted for the LEON3 processor.  This
  is the default.
! .IP \fB\-mfaster\-structs\fR 4
  .IX Item "-mfaster-structs"
  .PD 0
! .IP \fB\-mno\-faster\-structs\fR 4
  .IX Item "-mno-faster-structs"
  .PD
  With \fB\-mfaster\-structs\fR, the compiler assumes that structures
  should have 8\-byte alignment.  This enables the use of pairs of
  \&\f(CW\*(C`ldd\*(C'\fR and \f(CW\*(C`std\*(C'\fR instructions for copies in structure
  assignment, in place of twice as many \f(CW\*(C`ld\*(C'\fR and \f(CW\*(C`st\*(C'\fR pairs.
! However, the use of this changed alignment directly violates the SPARC
! ABI.  Thus, it\*(Aqs intended only for use on targets where the developer
  acknowledges that their resulting code is not directly in line with
! the rules of the ABI.
! .IP \fB\-mstd\-struct\-return\fR 4
  .IX Item "-mstd-struct-return"
  .PD 0
! .IP \fB\-mno\-std\-struct\-return\fR 4
  .IX Item "-mno-std-struct-return"
  .PD
  With \fB\-mstd\-struct\-return\fR, the compiler generates checking code
  in functions returning structures or unions to detect size mismatches
! between the two sides of function calls, as per the 32\-bit ABI.
  .Sp
  The default is \fB\-mno\-std\-struct\-return\fR.  This option has no effect
  in 64\-bit mode.
! .IP \fB\-mlra\fR 4
  .IX Item "-mlra"
  .PD 0
! .IP \fB\-mno\-lra\fR 4
  .IX Item "-mno-lra"
  .PD
! Enable Local Register Allocation.  This is the default for SPARC since GCC 7
  so \fB\-mno\-lra\fR needs to be passed to get old Reload.
! .IP \fB\-mcpu=\fR\fIcpu_type\fR 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set, register set, and instruction scheduling parameters
  for machine type \fIcpu_type\fR.  Supported values for \fIcpu_type\fR are
*************** for machine type \fIcpu_type\fR.  Suppor
*** 30684,30690 ****
  .Sp
  Native Solaris and GNU/Linux toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize
  the processor.
  .Sp
  Default instruction scheduling parameters are used for values that select
--- 30615,30621 ----
  .Sp
  Native Solaris and GNU/Linux toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mcpu=native\fR has no effect if GCC does not recognize
  the processor.
  .Sp
  Default instruction scheduling parameters are used for values that select
*************** an architecture and not an implementatio
*** 30694,30748 ****
  Here is a list of each supported architecture and their supported
  implementations.
  .RS 4
! .IP "v7" 4
  .IX Item "v7"
  cypress, leon3v7
! .IP "v8" 4
  .IX Item "v8"
  supersparc, hypersparc, leon, leon3, leon5
! .IP "sparclite" 4
  .IX Item "sparclite"
  f930, f934, sparclite86x
! .IP "sparclet" 4
  .IX Item "sparclet"
  tsc701
! .IP "v9" 4
  .IX Item "v9"
  ultrasparc, ultrasparc3, niagara, niagara2, niagara3, niagara4,
  niagara7, m8
  .RE
  .RS 4
  .Sp
! By default (unless configured otherwise), \s-1GCC\s0 generates code for the V7
! variant of the \s-1SPARC\s0 architecture.  With \fB\-mcpu=cypress\fR, the compiler
! additionally optimizes it for the Cypress \s-1CY7C602\s0 chip, as used in the
  SPARCStation/SPARCServer 3xx series.  This is also appropriate for the older
! SPARCStation 1, 2, \s-1IPX\s0 etc.
  .Sp
! With \fB\-mcpu=v8\fR, \s-1GCC\s0 generates code for the V8 variant of the \s-1SPARC\s0
  architecture.  The only difference from V7 code is that the compiler emits
! the integer multiply and integer divide instructions which exist in \s-1SPARC\-V8\s0
! but not in \s-1SPARC\-V7.\s0  With \fB\-mcpu=supersparc\fR, the compiler additionally
  optimizes it for the SuperSPARC chip, as used in the SPARCStation 10, 1000 and
  2000 series.
  .Sp
! With \fB\-mcpu=sparclite\fR, \s-1GCC\s0 generates code for the SPARClite variant of
! the \s-1SPARC\s0 architecture.  This adds the integer multiply, integer divide step
! and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClite but not in \s-1SPARC\-V7.\s0
  With \fB\-mcpu=f930\fR, the compiler additionally optimizes it for the
! Fujitsu \s-1MB86930\s0 chip, which is the original SPARClite, with no \s-1FPU.\s0  With
  \&\fB\-mcpu=f934\fR, the compiler additionally optimizes it for the Fujitsu
! \&\s-1MB86934\s0 chip, which is the more recent SPARClite with \s-1FPU.\s0
  .Sp
! With \fB\-mcpu=sparclet\fR, \s-1GCC\s0 generates code for the SPARClet variant of
! the \s-1SPARC\s0 architecture.  This adds the integer multiply, multiply/accumulate,
  integer divide step and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClet
! but not in \s-1SPARC\-V7.\s0  With \fB\-mcpu=tsc701\fR, the compiler additionally
! optimizes it for the \s-1TEMIC\s0 SPARClet chip.
  .Sp
! With \fB\-mcpu=v9\fR, \s-1GCC\s0 generates code for the V9 variant of the \s-1SPARC\s0
! architecture.  This adds 64\-bit integer and floating-point move instructions,
! 3 additional floating-point condition code registers and conditional move
  instructions.  With \fB\-mcpu=ultrasparc\fR, the compiler additionally
  optimizes it for the Sun UltraSPARC I/II/IIi chips.  With
  \&\fB\-mcpu=ultrasparc3\fR, the compiler additionally optimizes it for the
--- 30625,30679 ----
  Here is a list of each supported architecture and their supported
  implementations.
  .RS 4
! .IP v7 4
  .IX Item "v7"
  cypress, leon3v7
! .IP v8 4
  .IX Item "v8"
  supersparc, hypersparc, leon, leon3, leon5
! .IP sparclite 4
  .IX Item "sparclite"
  f930, f934, sparclite86x
! .IP sparclet 4
  .IX Item "sparclet"
  tsc701
! .IP v9 4
  .IX Item "v9"
  ultrasparc, ultrasparc3, niagara, niagara2, niagara3, niagara4,
  niagara7, m8
  .RE
  .RS 4
  .Sp
! By default (unless configured otherwise), GCC generates code for the V7
! variant of the SPARC architecture.  With \fB\-mcpu=cypress\fR, 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.
  .Sp
! With \fB\-mcpu=v8\fR, 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 \fB\-mcpu=supersparc\fR, the compiler additionally
  optimizes it for the SuperSPARC chip, as used in the SPARCStation 10, 1000 and
  2000 series.
  .Sp
! With \fB\-mcpu=sparclite\fR, GCC generates code for the SPARClite variant of
! the SPARC architecture.  This adds the integer multiply, integer divide step
! and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClite but not in SPARC\-V7.
  With \fB\-mcpu=f930\fR, the compiler additionally optimizes it for the
! Fujitsu MB86930 chip, which is the original SPARClite, with no FPU.  With
  \&\fB\-mcpu=f934\fR, the compiler additionally optimizes it for the Fujitsu
! MB86934 chip, which is the more recent SPARClite with FPU.
  .Sp
! With \fB\-mcpu=sparclet\fR, GCC generates code for the SPARClet variant of
! the SPARC architecture.  This adds the integer multiply, multiply/accumulate,
  integer divide step and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClet
! but not in SPARC\-V7.  With \fB\-mcpu=tsc701\fR, the compiler additionally
! optimizes it for the TEMIC SPARClet chip.
  .Sp
! With \fB\-mcpu=v9\fR, 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 \fB\-mcpu=ultrasparc\fR, the compiler additionally
  optimizes it for the Sun UltraSPARC I/II/IIi chips.  With
  \&\fB\-mcpu=ultrasparc3\fR, the compiler additionally optimizes it for the
*************** additionally optimizes it for Sun UltraS
*** 30754,30763 ****
  UltraSPARC T3 chips.  With \fB\-mcpu=niagara4\fR, the compiler
  additionally optimizes it for Sun UltraSPARC T4 chips.  With
  \&\fB\-mcpu=niagara7\fR, the compiler additionally optimizes it for
! Oracle \s-1SPARC M7\s0 chips.  With \fB\-mcpu=m8\fR, the compiler
  additionally optimizes it for Oracle M8 chips.
  .RE
! .IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR, but do not set the instruction set or register set that the
--- 30685,30694 ----
  UltraSPARC T3 chips.  With \fB\-mcpu=niagara4\fR, the compiler
  additionally optimizes it for Sun UltraSPARC T4 chips.  With
  \&\fB\-mcpu=niagara7\fR, the compiler additionally optimizes it for
! Oracle SPARC M7 chips.  With \fB\-mcpu=m8\fR, the compiler
  additionally optimizes it for Oracle M8 chips.
  .RE
! .IP \fB\-mtune=\fR\fIcpu_type\fR 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR, but do not set the instruction set or register set that the
*************** option \fB\-mcpu=\fR\fIcpu_type\fR does.
*** 30765,30983 ****
  .Sp
  The same values for \fB\-mcpu=\fR\fIcpu_type\fR can be used for
  \&\fB\-mtune=\fR\fIcpu_type\fR, but the only useful values are those
! that select a particular \s-1CPU\s0 implementation.  Those are
  \&\fBcypress\fR, \fBsupersparc\fR, \fBhypersparc\fR, \fBleon\fR,
  \&\fBleon3\fR, \fBleon3v7\fR, \fBleon5\fR, \fBf930\fR, \fBf934\fR,
  \&\fBsparclite86x\fR, \fBtsc701\fR, \fBultrasparc\fR,
  \&\fBultrasparc3\fR, \fBniagara\fR, \fBniagara2\fR, \fBniagara3\fR,
  \&\fBniagara4\fR, \fBniagara7\fR and \fBm8\fR.  With native Solaris
  and GNU/Linux toolchains, \fBnative\fR can also be used.
! .IP "\fB\-mv8plus\fR" 4
  .IX Item "-mv8plus"
  .PD 0
! .IP "\fB\-mno\-v8plus\fR" 4
  .IX Item "-mno-v8plus"
  .PD
! With \fB\-mv8plus\fR, \s-1GCC\s0 generates code for the \s-1SPARC\-V8+ ABI.\s0  The
! difference from the V8 \s-1ABI\s0 is that the global and out registers are
  considered 64 bits wide.  This is enabled by default on Solaris in 32\-bit
! mode for all \s-1SPARC\-V9\s0 processors.
! .IP "\fB\-mvis\fR" 4
  .IX Item "-mvis"
  .PD 0
! .IP "\fB\-mno\-vis\fR" 4
  .IX Item "-mno-vis"
  .PD
! With \fB\-mvis\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
  Visual Instruction Set extensions.  The default is \fB\-mno\-vis\fR.
! .IP "\fB\-mvis2\fR" 4
  .IX Item "-mvis2"
  .PD 0
! .IP "\fB\-mno\-vis2\fR" 4
  .IX Item "-mno-vis2"
  .PD
! With \fB\-mvis2\fR, \s-1GCC\s0 generates code that takes advantage of
  version 2.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis2\fR when targeting a cpu that supports such
! instructions, such as UltraSPARC-III and later.  Setting \fB\-mvis2\fR
  also sets \fB\-mvis\fR.
! .IP "\fB\-mvis3\fR" 4
  .IX Item "-mvis3"
  .PD 0
! .IP "\fB\-mno\-vis3\fR" 4
  .IX Item "-mno-vis3"
  .PD
! With \fB\-mvis3\fR, \s-1GCC\s0 generates code that takes advantage of
  version 3.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis3\fR when targeting a cpu that supports such
  instructions, such as niagara\-3 and later.  Setting \fB\-mvis3\fR
  also sets \fB\-mvis2\fR and \fB\-mvis\fR.
! .IP "\fB\-mvis4\fR" 4
  .IX Item "-mvis4"
  .PD 0
! .IP "\fB\-mno\-vis4\fR" 4
  .IX Item "-mno-vis4"
  .PD
! With \fB\-mvis4\fR, \s-1GCC\s0 generates code that takes advantage of
  version 4.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis4\fR when targeting a cpu that supports such
  instructions, such as niagara\-7 and later.  Setting \fB\-mvis4\fR
  also sets \fB\-mvis3\fR, \fB\-mvis2\fR and \fB\-mvis\fR.
! .IP "\fB\-mvis4b\fR" 4
  .IX Item "-mvis4b"
  .PD 0
! .IP "\fB\-mno\-vis4b\fR" 4
  .IX Item "-mno-vis4b"
  .PD
! With \fB\-mvis4b\fR, \s-1GCC\s0 generates code that takes advantage of
  version 4.0 of the UltraSPARC Visual Instruction Set extensions, plus
! the additional \s-1VIS\s0 instructions introduced in the Oracle \s-1SPARC\s0
  Architecture 2017.  The default is \fB\-mvis4b\fR when targeting a
  cpu that supports such instructions, such as m8 and later.  Setting
  \&\fB\-mvis4b\fR also sets \fB\-mvis4\fR, \fB\-mvis3\fR,
  \&\fB\-mvis2\fR and \fB\-mvis\fR.
! .IP "\fB\-mcbcond\fR" 4
  .IX Item "-mcbcond"
  .PD 0
! .IP "\fB\-mno\-cbcond\fR" 4
  .IX Item "-mno-cbcond"
  .PD
! With \fB\-mcbcond\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
! Compare-and-Branch-on-Condition instructions.  The default is \fB\-mcbcond\fR
! when targeting a \s-1CPU\s0 that supports such instructions, such as Niagara\-4 and
  later.
! .IP "\fB\-mfmaf\fR" 4
  .IX Item "-mfmaf"
  .PD 0
! .IP "\fB\-mno\-fmaf\fR" 4
  .IX Item "-mno-fmaf"
  .PD
! With \fB\-mfmaf\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
! Fused Multiply-Add Floating-point instructions.  The default is \fB\-mfmaf\fR
! when targeting a \s-1CPU\s0 that supports such instructions, such as Niagara\-3 and
  later.
! .IP "\fB\-mfsmuld\fR" 4
  .IX Item "-mfsmuld"
  .PD 0
! .IP "\fB\-mno\-fsmuld\fR" 4
  .IX Item "-mno-fsmuld"
  .PD
! With \fB\-mfsmuld\fR, \s-1GCC\s0 generates code that takes advantage of the
! Floating-point Multiply Single to Double (FsMULd) instruction.  The default is
! \&\fB\-mfsmuld\fR when targeting a \s-1CPU\s0 supporting the architecture versions V8
! or V9 with \s-1FPU\s0 except \fB\-mcpu=leon\fR.
! .IP "\fB\-mpopc\fR" 4
  .IX Item "-mpopc"
  .PD 0
! .IP "\fB\-mno\-popc\fR" 4
  .IX Item "-mno-popc"
  .PD
! With \fB\-mpopc\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
  Population Count instruction.  The default is \fB\-mpopc\fR
! when targeting a \s-1CPU\s0 that supports such an instruction, such as Niagara\-2 and
  later.
! .IP "\fB\-msubxc\fR" 4
  .IX Item "-msubxc"
  .PD 0
! .IP "\fB\-mno\-subxc\fR" 4
  .IX Item "-mno-subxc"
  .PD
! With \fB\-msubxc\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
! Subtract-Extended-with-Carry instruction.  The default is \fB\-msubxc\fR
! when targeting a \s-1CPU\s0 that supports such an instruction, such as Niagara\-7 and
  later.
! .IP "\fB\-mfix\-at697f\fR" 4
  .IX Item "-mfix-at697f"
! Enable the documented workaround for the single erratum of the Atmel \s-1AT697F\s0
! processor (which corresponds to erratum #13 of the \s-1AT697E\s0 processor).
! .IP "\fB\-mfix\-ut699\fR" 4
  .IX Item "-mfix-ut699"
! Enable the documented workarounds for the floating-point errata and the data
! cache nullify errata of the \s-1UT699\s0 processor.
! .IP "\fB\-mfix\-ut700\fR" 4
  .IX Item "-mfix-ut700"
! Enable the documented workaround for the back-to-back store errata of
! the \s-1UT699E/UT700\s0 processor.
! .IP "\fB\-mfix\-gr712rc\fR" 4
  .IX Item "-mfix-gr712rc"
! Enable the documented workaround for the back-to-back store errata of
! the \s-1GR712RC\s0 processor.
  .PP
  These \fB\-m\fR options are supported in addition to the above
! on \s-1SPARC\-V9\s0 processors in 64\-bit environments:
! .IP "\fB\-m32\fR" 4
  .IX Item "-m32"
  .PD 0
! .IP "\fB\-m64\fR" 4
  .IX Item "-m64"
  .PD
  Generate code for a 32\-bit or 64\-bit environment.
  The 32\-bit environment sets int, long and pointer to 32 bits.
  The 64\-bit environment sets int to 32 bits and long and pointer
  to 64 bits.
! .IP "\fB\-mcmodel=\fR\fIwhich\fR" 4
  .IX Item "-mcmodel=which"
  Set the code model to one of
  .RS 4
! .IP "\fBmedlow\fR" 4
  .IX Item "medlow"
  The Medium/Low code model: 64\-bit addresses, programs
  must be linked in the low 32 bits of memory.  Programs can be statically
  or dynamically linked.
! .IP "\fBmedmid\fR" 4
  .IX Item "medmid"
  The Medium/Middle code model: 64\-bit addresses, programs
  must be linked in the low 44 bits of memory, the text and data segments must
  be less than 2GB in size and the data segment must be located within 2GB of
  the text segment.
! .IP "\fBmedany\fR" 4
  .IX Item "medany"
  The Medium/Anywhere code model: 64\-bit addresses, programs
  may be linked anywhere in memory, the text and data segments must be less
  than 2GB in size and the data segment must be located within 2GB of the
  text segment.
! .IP "\fBembmedany\fR" 4
  .IX Item "embmedany"
  The Medium/Anywhere code model for embedded systems:
  64\-bit addresses, the text and data segments must be less than 2GB in
  size, both starting anywhere in memory (determined at link time).  The
  global register \f(CW%g4\fR points to the base of the data segment.  Programs
! are statically linked and \s-1PIC\s0 is not supported.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mmemory\-model=\fR\fImem-model\fR" 4
  .IX Item "-mmemory-model=mem-model"
  Set the memory model in force on the processor to one of
  .RS 4
! .IP "\fBdefault\fR" 4
  .IX Item "default"
  The default memory model for the processor and operating system.
! .IP "\fBrmo\fR" 4
  .IX Item "rmo"
  Relaxed Memory Order
! .IP "\fBpso\fR" 4
  .IX Item "pso"
  Partial Store Order
! .IP "\fBtso\fR" 4
  .IX Item "tso"
  Total Store Order
! .IP "\fBsc\fR" 4
  .IX Item "sc"
  Sequential Consistency
  .RE
  .RS 4
  .Sp
! These memory models are formally defined in Appendix D of the \s-1SPARC\-V9\s0
! architecture manual, as set in the processor's \f(CW\*(C`PSTATE.MM\*(C'\fR field.
  .RE
! .IP "\fB\-mstack\-bias\fR" 4
  .IX Item "-mstack-bias"
  .PD 0
! .IP "\fB\-mno\-stack\-bias\fR" 4
  .IX Item "-mno-stack-bias"
  .PD
! With \fB\-mstack\-bias\fR, \s-1GCC\s0 assumes that the stack pointer, and
  frame pointer if present, are offset by \-2047 which must be added back
  when making stack frame references.  This is the default in 64\-bit mode.
  Otherwise, assume no such offset is present.
--- 30696,30914 ----
  .Sp
  The same values for \fB\-mcpu=\fR\fIcpu_type\fR can be used for
  \&\fB\-mtune=\fR\fIcpu_type\fR, but the only useful values are those
! that select a particular CPU implementation.  Those are
  \&\fBcypress\fR, \fBsupersparc\fR, \fBhypersparc\fR, \fBleon\fR,
  \&\fBleon3\fR, \fBleon3v7\fR, \fBleon5\fR, \fBf930\fR, \fBf934\fR,
  \&\fBsparclite86x\fR, \fBtsc701\fR, \fBultrasparc\fR,
  \&\fBultrasparc3\fR, \fBniagara\fR, \fBniagara2\fR, \fBniagara3\fR,
  \&\fBniagara4\fR, \fBniagara7\fR and \fBm8\fR.  With native Solaris
  and GNU/Linux toolchains, \fBnative\fR can also be used.
! .IP \fB\-mv8plus\fR 4
  .IX Item "-mv8plus"
  .PD 0
! .IP \fB\-mno\-v8plus\fR 4
  .IX Item "-mno-v8plus"
  .PD
! With \fB\-mv8plus\fR, GCC generates code for the SPARC\-V8+ ABI.  The
! difference from the V8 ABI is that the global and out registers are
  considered 64 bits wide.  This is enabled by default on Solaris in 32\-bit
! mode for all SPARC\-V9 processors.
! .IP \fB\-mvis\fR 4
  .IX Item "-mvis"
  .PD 0
! .IP \fB\-mno\-vis\fR 4
  .IX Item "-mno-vis"
  .PD
! With \fB\-mvis\fR, GCC generates code that takes advantage of the UltraSPARC
  Visual Instruction Set extensions.  The default is \fB\-mno\-vis\fR.
! .IP \fB\-mvis2\fR 4
  .IX Item "-mvis2"
  .PD 0
! .IP \fB\-mno\-vis2\fR 4
  .IX Item "-mno-vis2"
  .PD
! With \fB\-mvis2\fR, GCC generates code that takes advantage of
  version 2.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis2\fR when targeting a cpu that supports such
! instructions, such as UltraSPARC\-III and later.  Setting \fB\-mvis2\fR
  also sets \fB\-mvis\fR.
! .IP \fB\-mvis3\fR 4
  .IX Item "-mvis3"
  .PD 0
! .IP \fB\-mno\-vis3\fR 4
  .IX Item "-mno-vis3"
  .PD
! With \fB\-mvis3\fR, GCC generates code that takes advantage of
  version 3.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis3\fR when targeting a cpu that supports such
  instructions, such as niagara\-3 and later.  Setting \fB\-mvis3\fR
  also sets \fB\-mvis2\fR and \fB\-mvis\fR.
! .IP \fB\-mvis4\fR 4
  .IX Item "-mvis4"
  .PD 0
! .IP \fB\-mno\-vis4\fR 4
  .IX Item "-mno-vis4"
  .PD
! With \fB\-mvis4\fR, GCC generates code that takes advantage of
  version 4.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis4\fR when targeting a cpu that supports such
  instructions, such as niagara\-7 and later.  Setting \fB\-mvis4\fR
  also sets \fB\-mvis3\fR, \fB\-mvis2\fR and \fB\-mvis\fR.
! .IP \fB\-mvis4b\fR 4
  .IX Item "-mvis4b"
  .PD 0
! .IP \fB\-mno\-vis4b\fR 4
  .IX Item "-mno-vis4b"
  .PD
! With \fB\-mvis4b\fR, GCC generates code that takes advantage of
  version 4.0 of the UltraSPARC Visual Instruction Set extensions, plus
! the additional VIS instructions introduced in the Oracle SPARC
  Architecture 2017.  The default is \fB\-mvis4b\fR when targeting a
  cpu that supports such instructions, such as m8 and later.  Setting
  \&\fB\-mvis4b\fR also sets \fB\-mvis4\fR, \fB\-mvis3\fR,
  \&\fB\-mvis2\fR and \fB\-mvis\fR.
! .IP \fB\-mcbcond\fR 4
  .IX Item "-mcbcond"
  .PD 0
! .IP \fB\-mno\-cbcond\fR 4
  .IX Item "-mno-cbcond"
  .PD
! With \fB\-mcbcond\fR, GCC generates code that takes advantage of the UltraSPARC
! Compare\-and\-Branch\-on\-Condition instructions.  The default is \fB\-mcbcond\fR
! when targeting a CPU that supports such instructions, such as Niagara\-4 and
  later.
! .IP \fB\-mfmaf\fR 4
  .IX Item "-mfmaf"
  .PD 0
! .IP \fB\-mno\-fmaf\fR 4
  .IX Item "-mno-fmaf"
  .PD
! With \fB\-mfmaf\fR, GCC generates code that takes advantage of the UltraSPARC
! Fused Multiply\-Add Floating\-point instructions.  The default is \fB\-mfmaf\fR
! when targeting a CPU that supports such instructions, such as Niagara\-3 and
  later.
! .IP \fB\-mfsmuld\fR 4
  .IX Item "-mfsmuld"
  .PD 0
! .IP \fB\-mno\-fsmuld\fR 4
  .IX Item "-mno-fsmuld"
  .PD
! With \fB\-mfsmuld\fR, GCC generates code that takes advantage of the
! Floating\-point Multiply Single to Double (FsMULd) instruction.  The default is
! \&\fB\-mfsmuld\fR when targeting a CPU supporting the architecture versions V8
! or V9 with FPU except \fB\-mcpu=leon\fR.
! .IP \fB\-mpopc\fR 4
  .IX Item "-mpopc"
  .PD 0
! .IP \fB\-mno\-popc\fR 4
  .IX Item "-mno-popc"
  .PD
! With \fB\-mpopc\fR, GCC generates code that takes advantage of the UltraSPARC
  Population Count instruction.  The default is \fB\-mpopc\fR
! when targeting a CPU that supports such an instruction, such as Niagara\-2 and
  later.
! .IP \fB\-msubxc\fR 4
  .IX Item "-msubxc"
  .PD 0
! .IP \fB\-mno\-subxc\fR 4
  .IX Item "-mno-subxc"
  .PD
! With \fB\-msubxc\fR, GCC generates code that takes advantage of the UltraSPARC
! Subtract\-Extended\-with\-Carry instruction.  The default is \fB\-msubxc\fR
! when targeting a CPU that supports such an instruction, such as Niagara\-7 and
  later.
! .IP \fB\-mfix\-at697f\fR 4
  .IX Item "-mfix-at697f"
! Enable the documented workaround for the single erratum of the Atmel AT697F
! processor (which corresponds to erratum #13 of the AT697E processor).
! .IP \fB\-mfix\-ut699\fR 4
  .IX Item "-mfix-ut699"
! Enable the documented workarounds for the floating\-point errata and the data
! cache nullify errata of the UT699 processor.
! .IP \fB\-mfix\-ut700\fR 4
  .IX Item "-mfix-ut700"
! Enable the documented workaround for the back\-to\-back store errata of
! the UT699E/UT700 processor.
! .IP \fB\-mfix\-gr712rc\fR 4
  .IX Item "-mfix-gr712rc"
! Enable the documented workaround for the back\-to\-back store errata of
! the GR712RC processor.
  .PP
  These \fB\-m\fR options are supported in addition to the above
! on SPARC\-V9 processors in 64\-bit environments:
! .IP \fB\-m32\fR 4
  .IX Item "-m32"
  .PD 0
! .IP \fB\-m64\fR 4
  .IX Item "-m64"
  .PD
  Generate code for a 32\-bit or 64\-bit environment.
  The 32\-bit environment sets int, long and pointer to 32 bits.
  The 64\-bit environment sets int to 32 bits and long and pointer
  to 64 bits.
! .IP \fB\-mcmodel=\fR\fIwhich\fR 4
  .IX Item "-mcmodel=which"
  Set the code model to one of
  .RS 4
! .IP \fBmedlow\fR 4
  .IX Item "medlow"
  The Medium/Low code model: 64\-bit addresses, programs
  must be linked in the low 32 bits of memory.  Programs can be statically
  or dynamically linked.
! .IP \fBmedmid\fR 4
  .IX Item "medmid"
  The Medium/Middle code model: 64\-bit addresses, programs
  must be linked in the low 44 bits of memory, the text and data segments must
  be less than 2GB in size and the data segment must be located within 2GB of
  the text segment.
! .IP \fBmedany\fR 4
  .IX Item "medany"
  The Medium/Anywhere code model: 64\-bit addresses, programs
  may be linked anywhere in memory, the text and data segments must be less
  than 2GB in size and the data segment must be located within 2GB of the
  text segment.
! .IP \fBembmedany\fR 4
  .IX Item "embmedany"
  The Medium/Anywhere code model for embedded systems:
  64\-bit addresses, the text and data segments must be less than 2GB in
  size, both starting anywhere in memory (determined at link time).  The
  global register \f(CW%g4\fR points to the base of the data segment.  Programs
! are statically linked and PIC is not supported.
  .RE
  .RS 4
  .RE
! .IP \fB\-mmemory\-model=\fR\fImem\-model\fR 4
  .IX Item "-mmemory-model=mem-model"
  Set the memory model in force on the processor to one of
  .RS 4
! .IP \fBdefault\fR 4
  .IX Item "default"
  The default memory model for the processor and operating system.
! .IP \fBrmo\fR 4
  .IX Item "rmo"
  Relaxed Memory Order
! .IP \fBpso\fR 4
  .IX Item "pso"
  Partial Store Order
! .IP \fBtso\fR 4
  .IX Item "tso"
  Total Store Order
! .IP \fBsc\fR 4
  .IX Item "sc"
  Sequential Consistency
  .RE
  .RS 4
  .Sp
! These memory models are formally defined in Appendix D of the SPARC\-V9
! architecture manual, as set in the processor\*(Aqs \f(CW\*(C`PSTATE.MM\*(C'\fR field.
  .RE
! .IP \fB\-mstack\-bias\fR 4
  .IX Item "-mstack-bias"
  .PD 0
! .IP \fB\-mno\-stack\-bias\fR 4
  .IX Item "-mno-stack-bias"
  .PD
! With \fB\-mstack\-bias\fR, 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.
*************** Otherwise, assume no such offset is pres
*** 30987,31009 ****
  .PP
  These additional options are available on System V Release 4 for
  compatibility with other compilers on those systems:
! .IP "\fB\-G\fR" 4
  .IX Item "-G"
  Create a shared object.
  It is recommended that \fB\-symbolic\fR or \fB\-shared\fR be used instead.
! .IP "\fB\-Qy\fR" 4
  .IX Item "-Qy"
  Identify the versions of each tool used by the compiler, in a
  \&\f(CW\*(C`.ident\*(C'\fR assembler directive in the output.
! .IP "\fB\-Qn\fR" 4
  .IX Item "-Qn"
  Refrain from adding \f(CW\*(C`.ident\*(C'\fR directives to the output file (this is
  the default).
! .IP "\fB\-YP,\fR\fIdirs\fR" 4
  .IX Item "-YP,dirs"
  Search the directories \fIdirs\fR, and no others, for libraries
  specified with \fB\-l\fR.
! .IP "\fB\-Ym,\fR\fIdir\fR" 4
  .IX Item "-Ym,dir"
  Look in the directory \fIdir\fR to find the M4 preprocessor.
  The assembler uses this option.
--- 30918,30940 ----
  .PP
  These additional options are available on System V Release 4 for
  compatibility with other compilers on those systems:
! .IP \fB\-G\fR 4
  .IX Item "-G"
  Create a shared object.
  It is recommended that \fB\-symbolic\fR or \fB\-shared\fR be used instead.
! .IP \fB\-Qy\fR 4
  .IX Item "-Qy"
  Identify the versions of each tool used by the compiler, in a
  \&\f(CW\*(C`.ident\*(C'\fR assembler directive in the output.
! .IP \fB\-Qn\fR 4
  .IX Item "-Qn"
  Refrain from adding \f(CW\*(C`.ident\*(C'\fR directives to the output file (this is
  the default).
! .IP \fB\-YP,\fR\fIdirs\fR 4
  .IX Item "-YP,dirs"
  Search the directories \fIdirs\fR, and no others, for libraries
  specified with \fB\-l\fR.
! .IP \fB\-Ym,\fR\fIdir\fR 4
  .IX Item "-Ym,dir"
  Look in the directory \fIdir\fR to find the M4 preprocessor.
  The assembler uses this option.
*************** The assembler uses this option.
*** 31012,31040 ****
  .IX Subsection "V850 Options"
  .PP
  These \fB\-m\fR options are defined for V850 implementations:
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP "\fB\-mno\-long\-calls\fR" 4
  .IX Item "-mno-long-calls"
  .PD
  Treat all calls as being far away (near).  If calls are assumed to be
! far away, the compiler always loads the function's address into a
  register, and calls indirect through the pointer.
! .IP "\fB\-mno\-ep\fR" 4
  .IX Item "-mno-ep"
  .PD 0
! .IP "\fB\-mep\fR" 4
  .IX Item "-mep"
  .PD
  Do not optimize (do optimize) basic blocks that use the same index
  pointer 4 or more times to copy pointer into the \f(CW\*(C`ep\*(C'\fR register, and
  use the shorter \f(CW\*(C`sld\*(C'\fR and \f(CW\*(C`sst\*(C'\fR instructions.  The \fB\-mep\fR
  option is on by default if you optimize.
! .IP "\fB\-mno\-prolog\-function\fR" 4
  .IX Item "-mno-prolog-function"
  .PD 0
! .IP "\fB\-mprolog\-function\fR" 4
  .IX Item "-mprolog-function"
  .PD
  Do not use (do use) external functions to save and restore registers
--- 30943,30971 ----
  .IX Subsection "V850 Options"
  .PP
  These \fB\-m\fR options are defined for V850 implementations:
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP \fB\-mno\-long\-calls\fR 4
  .IX Item "-mno-long-calls"
  .PD
  Treat all calls as being far away (near).  If calls are assumed to be
! far away, the compiler always loads the function\*(Aqs address into a
  register, and calls indirect through the pointer.
! .IP \fB\-mno\-ep\fR 4
  .IX Item "-mno-ep"
  .PD 0
! .IP \fB\-mep\fR 4
  .IX Item "-mep"
  .PD
  Do not optimize (do optimize) basic blocks that use the same index
  pointer 4 or more times to copy pointer into the \f(CW\*(C`ep\*(C'\fR register, and
  use the shorter \f(CW\*(C`sld\*(C'\fR and \f(CW\*(C`sst\*(C'\fR instructions.  The \fB\-mep\fR
  option is on by default if you optimize.
! .IP \fB\-mno\-prolog\-function\fR 4
  .IX Item "-mno-prolog-function"
  .PD 0
! .IP \fB\-mprolog\-function\fR 4
  .IX Item "-mprolog-function"
  .PD
  Do not use (do use) external functions to save and restore registers
*************** at the prologue and epilogue of a functi
*** 31042,31094 ****
  are slower, but use less code space if more than one function saves
  the same number of registers.  The \fB\-mprolog\-function\fR option
  is on by default if you optimize.
! .IP "\fB\-mspace\fR" 4
  .IX Item "-mspace"
  Try to make the code as small as possible.  At present, this just turns
  on the \fB\-mep\fR and \fB\-mprolog\-function\fR options.
! .IP "\fB\-mtda=\fR\fIn\fR" 4
  .IX Item "-mtda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the tiny data area that register \f(CW\*(C`ep\*(C'\fR points to.  The tiny data
  area can hold up to 256 bytes in total (128 bytes for byte references).
! .IP "\fB\-msda=\fR\fIn\fR" 4
  .IX Item "-msda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the small data area that register \f(CW\*(C`gp\*(C'\fR points to.  The small data
  area can hold up to 64 kilobytes.
! .IP "\fB\-mzda=\fR\fIn\fR" 4
  .IX Item "-mzda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the first 32 kilobytes of memory.
! .IP "\fB\-mv850\fR" 4
  .IX Item "-mv850"
  Specify that the target processor is the V850.
! .IP "\fB\-mv850e3v5\fR" 4
  .IX Item "-mv850e3v5"
  Specify that the target processor is the V850E3V5.  The preprocessor
  constant \f(CW\*(C`_\|_v850e3v5_\|_\*(C'\fR is defined if this option is used.
! .IP "\fB\-mv850e2v4\fR" 4
  .IX Item "-mv850e2v4"
  Specify that the target processor is the V850E3V5.  This is an alias for
  the \fB\-mv850e3v5\fR option.
! .IP "\fB\-mv850e2v3\fR" 4
  .IX Item "-mv850e2v3"
  Specify that the target processor is the V850E2V3.  The preprocessor
  constant \f(CW\*(C`_\|_v850e2v3_\|_\*(C'\fR is defined if this option is used.
! .IP "\fB\-mv850e2\fR" 4
  .IX Item "-mv850e2"
  Specify that the target processor is the V850E2.  The preprocessor
  constant \f(CW\*(C`_\|_v850e2_\|_\*(C'\fR is defined if this option is used.
! .IP "\fB\-mv850e1\fR" 4
  .IX Item "-mv850e1"
  Specify that the target processor is the V850E1.  The preprocessor
  constants \f(CW\*(C`_\|_v850e1_\|_\*(C'\fR and \f(CW\*(C`_\|_v850e_\|_\*(C'\fR are defined if
  this option is used.
! .IP "\fB\-mv850es\fR" 4
  .IX Item "-mv850es"
  Specify that the target processor is the V850ES.  This is an alias for
  the \fB\-mv850e1\fR option.
! .IP "\fB\-mv850e\fR" 4
  .IX Item "-mv850e"
  Specify that the target processor is the V850E.  The preprocessor
  constant \f(CW\*(C`_\|_v850e_\|_\*(C'\fR is defined if this option is used.
--- 30973,31025 ----
  are slower, but use less code space if more than one function saves
  the same number of registers.  The \fB\-mprolog\-function\fR option
  is on by default if you optimize.
! .IP \fB\-mspace\fR 4
  .IX Item "-mspace"
  Try to make the code as small as possible.  At present, this just turns
  on the \fB\-mep\fR and \fB\-mprolog\-function\fR options.
! .IP \fB\-mtda=\fR\fIn\fR 4
  .IX Item "-mtda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the tiny data area that register \f(CW\*(C`ep\*(C'\fR points to.  The tiny data
  area can hold up to 256 bytes in total (128 bytes for byte references).
! .IP \fB\-msda=\fR\fIn\fR 4
  .IX Item "-msda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the small data area that register \f(CW\*(C`gp\*(C'\fR points to.  The small data
  area can hold up to 64 kilobytes.
! .IP \fB\-mzda=\fR\fIn\fR 4
  .IX Item "-mzda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the first 32 kilobytes of memory.
! .IP \fB\-mv850\fR 4
  .IX Item "-mv850"
  Specify that the target processor is the V850.
! .IP \fB\-mv850e3v5\fR 4
  .IX Item "-mv850e3v5"
  Specify that the target processor is the V850E3V5.  The preprocessor
  constant \f(CW\*(C`_\|_v850e3v5_\|_\*(C'\fR is defined if this option is used.
! .IP \fB\-mv850e2v4\fR 4
  .IX Item "-mv850e2v4"
  Specify that the target processor is the V850E3V5.  This is an alias for
  the \fB\-mv850e3v5\fR option.
! .IP \fB\-mv850e2v3\fR 4
  .IX Item "-mv850e2v3"
  Specify that the target processor is the V850E2V3.  The preprocessor
  constant \f(CW\*(C`_\|_v850e2v3_\|_\*(C'\fR is defined if this option is used.
! .IP \fB\-mv850e2\fR 4
  .IX Item "-mv850e2"
  Specify that the target processor is the V850E2.  The preprocessor
  constant \f(CW\*(C`_\|_v850e2_\|_\*(C'\fR is defined if this option is used.
! .IP \fB\-mv850e1\fR 4
  .IX Item "-mv850e1"
  Specify that the target processor is the V850E1.  The preprocessor
  constants \f(CW\*(C`_\|_v850e1_\|_\*(C'\fR and \f(CW\*(C`_\|_v850e_\|_\*(C'\fR are defined if
  this option is used.
! .IP \fB\-mv850es\fR 4
  .IX Item "-mv850es"
  Specify that the target processor is the V850ES.  This is an alias for
  the \fB\-mv850e1\fR option.
! .IP \fB\-mv850e\fR 4
  .IX Item "-mv850e"
  Specify that the target processor is the V850E.  The preprocessor
  constant \f(CW\*(C`_\|_v850e_\|_\*(C'\fR is defined if this option is used.
*************** relevant \fB_\|_v850*_\|_\fR preprocesso
*** 31100,31208 ****
  .Sp
  The preprocessor constants \f(CW\*(C`_\|_v850\*(C'\fR and \f(CW\*(C`_\|_v851_\|_\*(C'\fR are always
  defined, regardless of which processor variant is the target.
! .IP "\fB\-mdisable\-callt\fR" 4
  .IX Item "-mdisable-callt"
  .PD 0
! .IP "\fB\-mno\-disable\-callt\fR" 4
  .IX Item "-mno-disable-callt"
  .PD
  This option suppresses generation of the \f(CW\*(C`CALLT\*(C'\fR instruction for the
  v850e, v850e1, v850e2, v850e2v3 and v850e3v5 flavors of the v850
  architecture.
  .Sp
! This option is enabled by default when the \s-1RH850 ABI\s0 is
  in use (see \fB\-mrh850\-abi\fR), and disabled by default when the
! \&\s-1GCC ABI\s0 is in use.  If \f(CW\*(C`CALLT\*(C'\fR instructions are being generated
  then the C preprocessor symbol \f(CW\*(C`_\|_V850_CALLT_\|_\*(C'\fR is defined.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  .PD 0
! .IP "\fB\-mno\-relax\fR" 4
  .IX Item "-mno-relax"
  .PD
! Pass on (or do not pass on) the \fB\-mrelax\fR command-line option
  to the assembler.
! .IP "\fB\-mlong\-jumps\fR" 4
  .IX Item "-mlong-jumps"
  .PD 0
! .IP "\fB\-mno\-long\-jumps\fR" 4
  .IX Item "-mno-long-jumps"
  .PD
! Disable (or re-enable) the generation of PC-relative jump instructions.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
! Disable (or re-enable) the generation of hardware floating point
  instructions.  This option is only significant when the target
  architecture is \fBV850E2V3\fR or higher.  If hardware floating point
  instructions are being generated then the C preprocessor symbol
  \&\f(CW\*(C`_\|_FPU_OK_\|_\*(C'\fR is defined, otherwise the symbol
  \&\f(CW\*(C`_\|_NO_FPU_\|_\*(C'\fR is defined.
! .IP "\fB\-mloop\fR" 4
  .IX Item "-mloop"
! Enables the use of the e3v5 \s-1LOOP\s0 instruction.  The use of this
  instruction is not enabled by default when the e3v5 architecture is
  selected because its use is still experimental.
! .IP "\fB\-mrh850\-abi\fR" 4
  .IX Item "-mrh850-abi"
  .PD 0
! .IP "\fB\-mghs\fR" 4
  .IX Item "-mghs"
  .PD
! Enables support for the \s-1RH850\s0 version of the V850 \s-1ABI.\s0  This is the
! default.  With this version of the \s-1ABI\s0 the following rules apply:
  .RS 4
! .IP "*" 4
  Integer sized structures and unions are returned via a memory pointer
  rather than a register.
! .IP "*" 4
  Large structures and unions (more than 8 bytes in size) are passed by
  value.
! .IP "*" 4
  Functions are aligned to 16\-bit boundaries.
! .IP "*" 4
! The \fB\-m8byte\-align\fR command-line option is supported.
! .IP "*" 4
! The \fB\-mdisable\-callt\fR command-line option is enabled by
! default.  The \fB\-mno\-disable\-callt\fR command-line option is not
  supported.
  .RE
  .RS 4
  .Sp
! When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_RH850_ABI_\|_\*(C'\fR is defined.
  .RE
! .IP "\fB\-mgcc\-abi\fR" 4
  .IX Item "-mgcc-abi"
! Enables support for the old \s-1GCC\s0 version of the V850 \s-1ABI.\s0  With this
! version of the \s-1ABI\s0 the following rules apply:
  .RS 4
! .IP "*" 4
  Integer sized structures and unions are returned in register \f(CW\*(C`r10\*(C'\fR.
! .IP "*" 4
  Large structures and unions (more than 8 bytes in size) are passed by
  reference.
! .IP "*" 4
  Functions are aligned to 32\-bit boundaries, unless optimizing for
  size.
! .IP "*" 4
! The \fB\-m8byte\-align\fR command-line option is not supported.
! .IP "*" 4
! The \fB\-mdisable\-callt\fR command-line option is supported but not
  enabled by default.
  .RE
  .RS 4
  .Sp
! When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_GCC_ABI_\|_\*(C'\fR is defined.
  .RE
! .IP "\fB\-m8byte\-align\fR" 4
  .IX Item "-m8byte-align"
  .PD 0
! .IP "\fB\-mno\-8byte\-align\fR" 4
  .IX Item "-mno-8byte-align"
  .PD
  Enables support for \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long long\*(C'\fR types to be
--- 31031,31139 ----
  .Sp
  The preprocessor constants \f(CW\*(C`_\|_v850\*(C'\fR and \f(CW\*(C`_\|_v851_\|_\*(C'\fR are always
  defined, regardless of which processor variant is the target.
! .IP \fB\-mdisable\-callt\fR 4
  .IX Item "-mdisable-callt"
  .PD 0
! .IP \fB\-mno\-disable\-callt\fR 4
  .IX Item "-mno-disable-callt"
  .PD
  This option suppresses generation of the \f(CW\*(C`CALLT\*(C'\fR instruction for the
  v850e, v850e1, v850e2, v850e2v3 and v850e3v5 flavors of the v850
  architecture.
  .Sp
! This option is enabled by default when the RH850 ABI is
  in use (see \fB\-mrh850\-abi\fR), and disabled by default when the
! GCC ABI is in use.  If \f(CW\*(C`CALLT\*(C'\fR instructions are being generated
  then the C preprocessor symbol \f(CW\*(C`_\|_V850_CALLT_\|_\*(C'\fR is defined.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  .PD 0
! .IP \fB\-mno\-relax\fR 4
  .IX Item "-mno-relax"
  .PD
! Pass on (or do not pass on) the \fB\-mrelax\fR command\-line option
  to the assembler.
! .IP \fB\-mlong\-jumps\fR 4
  .IX Item "-mlong-jumps"
  .PD 0
! .IP \fB\-mno\-long\-jumps\fR 4
  .IX Item "-mno-long-jumps"
  .PD
! Disable (or re\-enable) the generation of PC\-relative jump instructions.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
! Disable (or re\-enable) the generation of hardware floating point
  instructions.  This option is only significant when the target
  architecture is \fBV850E2V3\fR or higher.  If hardware floating point
  instructions are being generated then the C preprocessor symbol
  \&\f(CW\*(C`_\|_FPU_OK_\|_\*(C'\fR is defined, otherwise the symbol
  \&\f(CW\*(C`_\|_NO_FPU_\|_\*(C'\fR is defined.
! .IP \fB\-mloop\fR 4
  .IX Item "-mloop"
! Enables the use of the e3v5 LOOP instruction.  The use of this
  instruction is not enabled by default when the e3v5 architecture is
  selected because its use is still experimental.
! .IP \fB\-mrh850\-abi\fR 4
  .IX Item "-mrh850-abi"
  .PD 0
! .IP \fB\-mghs\fR 4
  .IX Item "-mghs"
  .PD
! Enables support for the RH850 version of the V850 ABI.  This is the
! default.  With this version of the ABI the following rules apply:
  .RS 4
! .IP * 4
  Integer sized structures and unions are returned via a memory pointer
  rather than a register.
! .IP * 4
  Large structures and unions (more than 8 bytes in size) are passed by
  value.
! .IP * 4
  Functions are aligned to 16\-bit boundaries.
! .IP * 4
! The \fB\-m8byte\-align\fR command\-line option is supported.
! .IP * 4
! The \fB\-mdisable\-callt\fR command\-line option is enabled by
! default.  The \fB\-mno\-disable\-callt\fR command\-line option is not
  supported.
  .RE
  .RS 4
  .Sp
! When this version of the ABI is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_RH850_ABI_\|_\*(C'\fR is defined.
  .RE
! .IP \fB\-mgcc\-abi\fR 4
  .IX Item "-mgcc-abi"
! Enables support for the old GCC version of the V850 ABI.  With this
! version of the ABI the following rules apply:
  .RS 4
! .IP * 4
  Integer sized structures and unions are returned in register \f(CW\*(C`r10\*(C'\fR.
! .IP * 4
  Large structures and unions (more than 8 bytes in size) are passed by
  reference.
! .IP * 4
  Functions are aligned to 32\-bit boundaries, unless optimizing for
  size.
! .IP * 4
! The \fB\-m8byte\-align\fR command\-line option is not supported.
! .IP * 4
! The \fB\-mdisable\-callt\fR command\-line option is supported but not
  enabled by default.
  .RE
  .RS 4
  .Sp
! When this version of the ABI is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_GCC_ABI_\|_\*(C'\fR is defined.
  .RE
! .IP \fB\-m8byte\-align\fR 4
  .IX Item "-m8byte-align"
  .PD 0
! .IP \fB\-mno\-8byte\-align\fR 4
  .IX Item "-mno-8byte-align"
  .PD
  Enables support for \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long long\*(C'\fR types to be
*************** aligned on 8\-byte boundaries.  The defa
*** 31210,31288 ****
  alignment of all objects to at most 4\-bytes.  When
  \&\fB\-m8byte\-align\fR is in effect the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_8BYTE_ALIGN_\|_\*(C'\fR is defined.
! .IP "\fB\-mbig\-switch\fR" 4
  .IX Item "-mbig-switch"
  Generate code suitable for big switch tables.  Use this option only if
  the assembler/linker complain about out of range branches within a switch
  table.
! .IP "\fB\-mapp\-regs\fR" 4
  .IX Item "-mapp-regs"
  This option causes r2 and r5 to be used in the code generated by
  the compiler.  This setting is the default.
! .IP "\fB\-mno\-app\-regs\fR" 4
  .IX Item "-mno-app-regs"
  This option causes r2 and r5 to be treated as fixed registers.
  .PP
! \fI\s-1VAX\s0 Options\fR
  .IX Subsection "VAX Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1VAX:\s0
! .IP "\fB\-munix\fR" 4
  .IX Item "-munix"
  Do not output certain jump instructions (\f(CW\*(C`aobleq\*(C'\fR and so on)
! that the Unix assembler for the \s-1VAX\s0 cannot handle across long
  ranges.
! .IP "\fB\-mgnu\fR" 4
  .IX Item "-mgnu"
  Do output those jump instructions, on the assumption that the
! \&\s-1GNU\s0 assembler is being used.
! .IP "\fB\-mg\fR" 4
  .IX Item "-mg"
! Output code for G\-format floating-point numbers instead of D\-format.
! .IP "\fB\-mlra\fR" 4
  .IX Item "-mlra"
  .PD 0
! .IP "\fB\-mno\-lra\fR" 4
  .IX Item "-mno-lra"
  .PD
! Enable Local Register Allocation.  This is still experimental for the \s-1VAX,\s0
  so by default the compiler uses standard reload.
  .PP
  \fIVisium Options\fR
  .IX Subsection "Visium Options"
! .IP "\fB\-mdebug\fR" 4
  .IX Item "-mdebug"
! A program which performs file I/O and is destined to run on an \s-1MCM\s0 target
  should be linked with this option.  It causes the libraries libc.a and
  libdebug.a to be linked.  The program should be run on the target under
! the control of the \s-1GDB\s0 remote debugging stub.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  A program which performs file I/O and is destined to run on the simulator
  should be linked with option.  This causes libraries libc.a and libsim.a to
  be linked.
! .IP "\fB\-mfpu\fR" 4
  .IX Item "-mfpu"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
! Generate code containing floating-point instructions.  This is the
  default.
! .IP "\fB\-mno\-fpu\fR" 4
  .IX Item "-mno-fpu"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
! Generate code containing library calls for floating-point.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with \s-1GCC,\s0 with \fB\-msoft\-float\fR in order for
  this to work.
! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set, register set, and instruction scheduling parameters
  for machine type \fIcpu_type\fR.  Supported values for \fIcpu_type\fR are
--- 31141,31219 ----
  alignment of all objects to at most 4\-bytes.  When
  \&\fB\-m8byte\-align\fR is in effect the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_8BYTE_ALIGN_\|_\*(C'\fR is defined.
! .IP \fB\-mbig\-switch\fR 4
  .IX Item "-mbig-switch"
  Generate code suitable for big switch tables.  Use this option only if
  the assembler/linker complain about out of range branches within a switch
  table.
! .IP \fB\-mapp\-regs\fR 4
  .IX Item "-mapp-regs"
  This option causes r2 and r5 to be used in the code generated by
  the compiler.  This setting is the default.
! .IP \fB\-mno\-app\-regs\fR 4
  .IX Item "-mno-app-regs"
  This option causes r2 and r5 to be treated as fixed registers.
  .PP
! \fIVAX Options\fR
  .IX Subsection "VAX Options"
  .PP
! These \fB\-m\fR options are defined for the VAX:
! .IP \fB\-munix\fR 4
  .IX Item "-munix"
  Do not output certain jump instructions (\f(CW\*(C`aobleq\*(C'\fR and so on)
! that the Unix assembler for the VAX cannot handle across long
  ranges.
! .IP \fB\-mgnu\fR 4
  .IX Item "-mgnu"
  Do output those jump instructions, on the assumption that the
! GNU assembler is being used.
! .IP \fB\-mg\fR 4
  .IX Item "-mg"
! Output code for G\-format floating\-point numbers instead of D\-format.
! .IP \fB\-mlra\fR 4
  .IX Item "-mlra"
  .PD 0
! .IP \fB\-mno\-lra\fR 4
  .IX Item "-mno-lra"
  .PD
! Enable Local Register Allocation.  This is still experimental for the VAX,
  so by default the compiler uses standard reload.
  .PP
  \fIVisium Options\fR
  .IX Subsection "Visium Options"
! .IP \fB\-mdebug\fR 4
  .IX Item "-mdebug"
! A program which performs file I/O and is destined to run on an MCM target
  should be linked with this option.  It causes the libraries libc.a and
  libdebug.a to be linked.  The program should be run on the target under
! the control of the GDB remote debugging stub.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  A program which performs file I/O and is destined to run on the simulator
  should be linked with option.  This causes libraries libc.a and libsim.a to
  be linked.
! .IP \fB\-mfpu\fR 4
  .IX Item "-mfpu"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
! Generate code containing floating\-point instructions.  This is the
  default.
! .IP \fB\-mno\-fpu\fR 4
  .IX Item "-mno-fpu"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
! Generate code containing library calls for floating\-point.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with GCC, with \fB\-msoft\-float\fR in order for
  this to work.
! .IP \fB\-mcpu=\fR\fIcpu_type\fR 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set, register set, and instruction scheduling parameters
  for machine type \fIcpu_type\fR.  Supported values for \fIcpu_type\fR are
*************** for machine type \fIcpu_type\fR.  Suppor
*** 31290,31332 ****
  .Sp
  \&\fBmcm\fR is a synonym of \fBgr5\fR present for backward compatibility.
  .Sp
! By default (unless configured otherwise), \s-1GCC\s0 generates code for the \s-1GR5\s0
  variant of the Visium architecture.
  .Sp
! With \fB\-mcpu=gr6\fR, \s-1GCC\s0 generates code for the \s-1GR6\s0 variant of the Visium
! architecture.  The only difference from \s-1GR5\s0 code is that the compiler will
  generate block move instructions.
! .IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type \fIcpu_type\fR,
  but do not set the instruction set or register set that the option
  \&\fB\-mcpu=\fR\fIcpu_type\fR would.
! .IP "\fB\-msv\-mode\fR" 4
  .IX Item "-msv-mode"
  Generate code for the supervisor mode, where there are no restrictions on
  the access to general registers.  This is the default.
! .IP "\fB\-muser\-mode\fR" 4
  .IX Item "-muser-mode"
  Generate code for the user mode, where the access to some general registers
! is forbidden: on the \s-1GR5,\s0 registers r24 to r31 cannot be accessed in this
! mode; on the \s-1GR6,\s0 only registers r29 to r31 are affected.
  .PP
! \fI\s-1VMS\s0 Options\fR
  .IX Subsection "VMS Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1VMS\s0 implementations:
! .IP "\fB\-mvms\-return\-codes\fR" 4
  .IX Item "-mvms-return-codes"
! Return \s-1VMS\s0 condition codes from \f(CW\*(C`main\*(C'\fR. The default is to return POSIX-style
  condition (e.g. error) codes.
! .IP "\fB\-mdebug\-main=\fR\fIprefix\fR" 4
  .IX Item "-mdebug-main=prefix"
  Flag the first routine whose name starts with \fIprefix\fR as the main
  routine for the debugger.
! .IP "\fB\-mmalloc64\fR" 4
  .IX Item "-mmalloc64"
  Default to 64\-bit memory allocation routines.
! .IP "\fB\-mpointer\-size=\fR\fIsize\fR" 4
  .IX Item "-mpointer-size=size"
  Set the default size of pointers. Possible options for \fIsize\fR are
  \&\fB32\fR or \fBshort\fR for 32 bit pointers, \fB64\fR or \fBlong\fR
--- 31221,31263 ----
  .Sp
  \&\fBmcm\fR is a synonym of \fBgr5\fR present for backward compatibility.
  .Sp
! By default (unless configured otherwise), GCC generates code for the GR5
  variant of the Visium architecture.
  .Sp
! With \fB\-mcpu=gr6\fR, GCC generates code for the GR6 variant of the Visium
! architecture.  The only difference from GR5 code is that the compiler will
  generate block move instructions.
! .IP \fB\-mtune=\fR\fIcpu_type\fR 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type \fIcpu_type\fR,
  but do not set the instruction set or register set that the option
  \&\fB\-mcpu=\fR\fIcpu_type\fR would.
! .IP \fB\-msv\-mode\fR 4
  .IX Item "-msv-mode"
  Generate code for the supervisor mode, where there are no restrictions on
  the access to general registers.  This is the default.
! .IP \fB\-muser\-mode\fR 4
  .IX Item "-muser-mode"
  Generate code for the user mode, where the access to some general registers
! is forbidden: on the GR5, registers r24 to r31 cannot be accessed in this
! mode; on the GR6, only registers r29 to r31 are affected.
  .PP
! \fIVMS Options\fR
  .IX Subsection "VMS Options"
  .PP
! These \fB\-m\fR options are defined for the VMS implementations:
! .IP \fB\-mvms\-return\-codes\fR 4
  .IX Item "-mvms-return-codes"
! Return VMS condition codes from \f(CW\*(C`main\*(C'\fR. The default is to return POSIX\-style
  condition (e.g. error) codes.
! .IP \fB\-mdebug\-main=\fR\fIprefix\fR 4
  .IX Item "-mdebug-main=prefix"
  Flag the first routine whose name starts with \fIprefix\fR as the main
  routine for the debugger.
! .IP \fB\-mmalloc64\fR 4
  .IX Item "-mmalloc64"
  Default to 64\-bit memory allocation routines.
! .IP \fB\-mpointer\-size=\fR\fIsize\fR 4
  .IX Item "-mpointer-size=size"
  Set the default size of pointers. Possible options for \fIsize\fR are
  \&\fB32\fR or \fBshort\fR for 32 bit pointers, \fB64\fR or \fBlong\fR
*************** The later option disables \f(CW\*(C`prag
*** 31339,31368 ****
  The options in this section are defined for all VxWorks targets.
  Options specific to the target hardware are listed with the other
  options for that target.
! .IP "\fB\-mrtp\fR" 4
  .IX Item "-mrtp"
! \&\s-1GCC\s0 can generate code for both VxWorks kernels and real time processes
  (RTPs).  This option switches from the former to the latter.  It also
  defines the preprocessor macro \f(CW\*(C`_\|_RTP_\|_\*(C'\fR.
! .IP "\fB\-non\-static\fR" 4
  .IX Item "-non-static"
! Link an \s-1RTP\s0 executable against shared libraries rather than static
  libraries.  The options \fB\-static\fR and \fB\-shared\fR can
  also be used for RTPs; \fB\-static\fR
  is the default.
! .IP "\fB\-Bstatic\fR" 4
  .IX Item "-Bstatic"
  .PD 0
! .IP "\fB\-Bdynamic\fR" 4
  .IX Item "-Bdynamic"
  .PD
  These options are passed down to the linker.  They are defined for
  compatibility with Diab.
! .IP "\fB\-Xbind\-lazy\fR" 4
  .IX Item "-Xbind-lazy"
  Enable lazy binding of function calls.  This option is equivalent to
  \&\fB\-Wl,\-z,now\fR and is defined for compatibility with Diab.
! .IP "\fB\-Xbind\-now\fR" 4
  .IX Item "-Xbind-now"
  Disable lazy binding of function calls.  This option is the default and
  is defined for compatibility with Diab.
--- 31270,31299 ----
  The options in this section are defined for all VxWorks targets.
  Options specific to the target hardware are listed with the other
  options for that target.
! .IP \fB\-mrtp\fR 4
  .IX Item "-mrtp"
! 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 \f(CW\*(C`_\|_RTP_\|_\*(C'\fR.
! .IP \fB\-non\-static\fR 4
  .IX Item "-non-static"
! Link an RTP executable against shared libraries rather than static
  libraries.  The options \fB\-static\fR and \fB\-shared\fR can
  also be used for RTPs; \fB\-static\fR
  is the default.
! .IP \fB\-Bstatic\fR 4
  .IX Item "-Bstatic"
  .PD 0
! .IP \fB\-Bdynamic\fR 4
  .IX Item "-Bdynamic"
  .PD
  These options are passed down to the linker.  They are defined for
  compatibility with Diab.
! .IP \fB\-Xbind\-lazy\fR 4
  .IX Item "-Xbind-lazy"
  Enable lazy binding of function calls.  This option is equivalent to
  \&\fB\-Wl,\-z,now\fR and is defined for compatibility with Diab.
! .IP \fB\-Xbind\-now\fR 4
  .IX Item "-Xbind-now"
  Disable lazy binding of function calls.  This option is the default and
  is defined for compatibility with Diab.
*************** is defined for compatibility with Diab.
*** 31371,31966 ****
  .IX Subsection "x86 Options"
  .PP
  These \fB\-m\fR options are defined for the x86 family of computers.
! .IP "\fB\-march=\fR\fIcpu-type\fR" 4
  .IX Item "-march=cpu-type"
! Generate instructions for the machine type \fIcpu-type\fR.  In contrast to
! \&\fB\-mtune=\fR\fIcpu-type\fR, which merely tunes the generated code 
! for the specified \fIcpu-type\fR, \fB\-march=\fR\fIcpu-type\fR allows \s-1GCC\s0
  to generate code that may not run at all on processors other than the one
! indicated.  Specifying \fB\-march=\fR\fIcpu-type\fR implies 
! \&\fB\-mtune=\fR\fIcpu-type\fR, except where noted otherwise.
  .Sp
! The choices for \fIcpu-type\fR are:
  .RS 4
! .IP "\fBnative\fR" 4
  .IX Item "native"
! This selects the \s-1CPU\s0 to generate code for at compilation time by determining
  the processor type of the compiling machine.  Using \fB\-march=native\fR
  enables all instruction subsets supported by the local machine (hence
  the result might not run on different machines).  Using \fB\-mtune=native\fR
  produces code optimized for the local machine under the constraints
  of the selected instruction set.
! .IP "\fBx86\-64\fR" 4
  .IX Item "x86-64"
! A generic \s-1CPU\s0 with 64\-bit extensions.
! .IP "\fBx86\-64\-v2\fR" 4
  .IX Item "x86-64-v2"
  .PD 0
! .IP "\fBx86\-64\-v3\fR" 4
  .IX Item "x86-64-v3"
! .IP "\fBx86\-64\-v4\fR" 4
  .IX Item "x86-64-v4"
  .PD
! These choices for \fIcpu-type\fR select the corresponding
! micro-architecture level from the x86\-64 psABI.  On ABIs other than
! the x86\-64 psABI they select the same \s-1CPU\s0 features as the x86\-64 psABI
! documents for the particular micro-architecture level.
  .Sp
! Since these \fIcpu-type\fR values do not have a corresponding
  \&\fB\-mtune\fR setting, using \fB\-march\fR with these values enables
  generic tuning.  Specific tuning can be enabled using the
! \&\fB\-mtune=\fR\fIother-cpu-type\fR option with an appropriate
! \&\fIother-cpu-type\fR value.
! .IP "\fBi386\fR" 4
  .IX Item "i386"
! Original Intel i386 \s-1CPU.\s0
! .IP "\fBi486\fR" 4
  .IX Item "i486"
! Intel i486 \s-1CPU.\s0  (No scheduling is implemented for this chip.)
! .IP "\fBi586\fR" 4
  .IX Item "i586"
  .PD 0
! .IP "\fBpentium\fR" 4
  .IX Item "pentium"
  .PD
! Intel Pentium \s-1CPU\s0 with no \s-1MMX\s0 support.
! .IP "\fBlakemont\fR" 4
  .IX Item "lakemont"
! Intel Lakemont \s-1MCU,\s0 based on Intel Pentium \s-1CPU.\s0
! .IP "\fBpentium-mmx\fR" 4
  .IX Item "pentium-mmx"
! Intel Pentium \s-1MMX CPU,\s0 based on Pentium core with \s-1MMX\s0 instruction set support.
! .IP "\fBpentiumpro\fR" 4
  .IX Item "pentiumpro"
! Intel Pentium Pro \s-1CPU.\s0
! .IP "\fBi686\fR" 4
  .IX Item "i686"
  When used with \fB\-march\fR, the Pentium Pro
  instruction set is used, so the code runs on all i686 family chips.
  When used with \fB\-mtune\fR, it has the same meaning as \fBgeneric\fR.
! .IP "\fBpentium2\fR" 4
  .IX Item "pentium2"
! Intel Pentium \s-1II CPU,\s0 based on Pentium Pro core with \s-1MMX\s0 and \s-1FXSR\s0 instruction
  set support.
! .IP "\fBpentium3\fR" 4
  .IX Item "pentium3"
  .PD 0
! .IP "\fBpentium3m\fR" 4
  .IX Item "pentium3m"
  .PD
! Intel Pentium \s-1III CPU,\s0 based on Pentium Pro core with \s-1MMX, FXSR\s0 and \s-1SSE\s0
  instruction set support.
! .IP "\fBpentium-m\fR" 4
  .IX Item "pentium-m"
! Intel Pentium M; low-power version of Intel Pentium \s-1III CPU\s0
! with \s-1MMX, SSE, SSE2\s0 and \s-1FXSR\s0 instruction set support.  Used by Centrino
  notebooks.
! .IP "\fBpentium4\fR" 4
  .IX Item "pentium4"
  .PD 0
! .IP "\fBpentium4m\fR" 4
  .IX Item "pentium4m"
  .PD
! Intel Pentium 4 \s-1CPU\s0 with \s-1MMX, SSE, SSE2\s0 and \s-1FXSR\s0 instruction set support.
! .IP "\fBprescott\fR" 4
  .IX Item "prescott"
! Improved version of Intel Pentium 4 \s-1CPU\s0 with \s-1MMX, SSE, SSE2, SSE3\s0 and \s-1FXSR\s0
  instruction set support.
! .IP "\fBnocona\fR" 4
  .IX Item "nocona"
! Improved version of Intel Pentium 4 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE,
! SSE2, SSE3\s0 and \s-1FXSR\s0 instruction set support.
! .IP "\fBcore2\fR" 4
  .IX Item "core2"
! Intel Core 2 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3, CX16,
! SAHF\s0 and \s-1FXSR\s0 instruction set support.
! .IP "\fBnehalem\fR" 4
  .IX Item "nehalem"
  .PD 0
! .IP "\fBcorei7\fR" 4
  .IX Item "corei7"
  .PD
! Intel Nehalem \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF\s0 and \s-1FXSR\s0 instruction set support.
! .IP "\fBwestmere\fR" 4
  .IX Item "westmere"
! Intel Westmere \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR\s0 and \s-1PCLMUL\s0 instruction set support.
! .IP "\fBsandybridge\fR" 4
  .IX Item "sandybridge"
  .PD 0
! .IP "\fBcorei7\-avx\fR" 4
  .IX Item "corei7-avx"
  .PD
! Intel Sandy Bridge \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE\s0 and \s-1PCLMUL\s0 instruction set
  support.
! .IP "\fBivybridge\fR" 4
  .IX Item "ivybridge"
  .PD 0
! .IP "\fBcore-avx-i\fR" 4
  .IX Item "core-avx-i"
  .PD
! Intel Ivy Bridge \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND\s0
  and F16C instruction set support.
! .IP "\fBhaswell\fR" 4
  .IX Item "haswell"
  .PD 0
! .IP "\fBcore\-avx2\fR" 4
  .IX Item "core-avx2"
  .PD
! Intel Haswell \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
! F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE\s0 and \s-1HLE\s0 instruction set support.
! .IP "\fBbroadwell\fR" 4
  .IX Item "broadwell"
! Intel Broadwell \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
! F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX\s0 and \s-1PREFETCHW\s0
  instruction set support.
! .IP "\fBskylake\fR" 4
  .IX Item "skylake"
! Intel Skylake \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
! CLFLUSHOPT, XSAVEC, XSAVES\s0 and \s-1SGX\s0 instruction set support.
! .IP "\fBskylake\-avx512\fR" 4
  .IX Item "skylake-avx512"
! Intel Skylake Server \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW,
! AVX512DQ\s0 and \s-1AVX512CD\s0 instruction set support.
! .IP "\fBcascadelake\fR" 4
  .IX Item "cascadelake"
! Intel Cascade Lake \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ,
! AVX512CD\s0 and \s-1AVX512VNNI\s0 instruction set support.
! .IP "\fBcannonlake\fR" 4
  .IX Item "cannonlake"
! Intel Cannon Lake Server \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2,
  SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL,
  FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX,
  PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW,
! AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA\s0 and \s-1SHA\s0 instruction set
  support.
! .IP "\fBcooperlake\fR" 4
  .IX Item "cooperlake"
! Intel Cooper Lake \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ,
! AVX512CD, AVX512VNNI\s0 and \s-1AVX512BF16\s0 instruction set support.
! .IP "\fBicelake-client\fR" 4
  .IX Item "icelake-client"
! Intel Ice Lake Client \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2
! , VPCLMULQDQ, AVX512BITALG, RDPID\s0 and \s-1AVX512VPOPCNTDQ\s0 instruction set support.
! .IP "\fBicelake-server\fR" 4
  .IX Item "icelake-server"
! Intel Ice Lake Server \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2
! , VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD\s0 and \s-1CLWB\s0
  instruction set support.
! .IP "\fBtigerlake\fR" 4
  .IX Item "tigerlake"
! Intel Tiger Lake \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD
  PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, MOVDIRI, MOVDIR64B, CLWB,
! AVX512VP2INTERSECT\s0 and \s-1KEYLOCKER\s0 instruction set support.
! .IP "\fBrocketlake\fR" 4
  .IX Item "rocketlake"
! Intel Rocket Lake \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD
  PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
! VPCLMULQDQ, AVX512BITALG, RDPID\s0 and \s-1AVX512VPOPCNTDQ\s0 instruction set support.
! .IP "\fBalderlake\fR" 4
  .IX Item "alderlake"
  .PD 0
! .IP "\fBraptorlake\fR" 4
  .IX Item "raptorlake"
! .IP "\fBmeteorlake\fR" 4
  .IX Item "meteorlake"
  .PD
! Intel Alder Lake/Raptor Lake/Meteor Lake \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX,
! SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND,
! XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX,\s0 GFNI-SSE, \s-1CLWB,
! MOVDIRI, MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA,
! LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL\s0 and
! AVX-VNNI instruction set support.
! .IP "\fBsapphirerapids\fR" 4
  .IX Item "sapphirerapids"
  .PD 0
! .IP "\fBemeraldrapids\fR" 4
  .IX Item "emeraldrapids"
  .PD
! Intel Sapphire Rapids/Emerald Rapids \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE,
  SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL,
  FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX,
  PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW,
  AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES,
  AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG,
  WBNOINVD, CLWB, MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG,
! SERIALIZE, TSXLDTRK, UINTR, AMX\-BF16,\s0 AMX-TILE, \s-1AMX\-INT8,\s0 AVX-VNNI, \s-1AVX512\-FP16\s0
! and \s-1AVX512BF16\s0 instruction set support.
! .IP "\fBgraniterapids\fR" 4
  .IX Item "graniterapids"
! Intel Granite Rapids \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB,
  MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK,
! UINTR, AMX\-BF16,\s0 AMX-TILE, \s-1AMX\-INT8,\s0 AVX-VNNI, \s-1AVX512\-FP16, AVX512BF16, AMX\-FP16\s0
! and \s-1PREFETCHI\s0 instruction set support.
! .IP "\fBgraniterapids-d\fR" 4
  .IX Item "graniterapids-d"
! Intel Granite Rapids D \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB,
  MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK,
! UINTR, AMX\-BF16,\s0 AMX-TILE, \s-1AMX\-INT8,\s0 AVX-VNNI, \s-1AVX512FP16, AVX512BF16, AMX\-FP16,
! PREFETCHI\s0 and AMX-COMPLEX instruction set support.
! .IP "\fBbonnell\fR" 4
  .IX Item "bonnell"
  .PD 0
! .IP "\fBatom\fR" 4
  .IX Item "atom"
  .PD
! Intel Bonnell \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
  instruction set support.
! .IP "\fBsilvermont\fR" 4
  .IX Item "silvermont"
  .PD 0
! .IP "\fBslm\fR" 4
  .IX Item "slm"
  .PD
! Intel Silvermont \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW\s0 and \s-1RDRND\s0
  instruction set support.
! .IP "\fBgoldmont\fR" 4
  .IX Item "goldmont"
! Intel Goldmont \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA,
! RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT\s0 and \s-1FSGSBASE\s0 instruction
  set support.
! .IP "\fBgoldmont-plus\fR" 4
  .IX Item "goldmont-plus"
! Intel Goldmont Plus \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES,
  SHA, RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE,
! RDPID\s0 and \s-1SGX\s0 instruction set support.
! .IP "\fBtremont\fR" 4
  .IX Item "tremont"
! Intel Tremont \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA,
  RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE, RDPID,
! SGX, CLWB,\s0 GFNI-SSE, \s-1MOVDIRI, MOVDIR64B, CLDEMOTE\s0 and \s-1WAITPKG\s0 instruction set
  support.
! .IP "\fBsierraforest\fR" 4
  .IX Item "sierraforest"
! Intel Sierra Forest \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC,
! XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX,\s0 GFNI-SSE, \s-1CLWB, MOVDIRI,
  MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT,
! PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL,\s0 AVX-VNNI,
! \&\s-1AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, ENQCMD\s0 and \s-1UINTR\s0 instruction set
  support.
! .IP "\fBgrandridge\fR" 4
  .IX Item "grandridge"
! Intel Grand Ridge \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC,
! XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX,\s0 GFNI-SSE, \s-1CLWB, MOVDIRI,
  MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT,
! PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL,\s0 AVX-VNNI,
! \&\s-1AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, ENQCMD\s0 and \s-1UINTR\s0 instruction set
  support.
! .IP "\fBknl\fR" 4
  .IX Item "knl"
! Intel Knights Landing \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
! AVX512PF, AVX512ER, AVX512F, AVX512CD\s0 and \s-1PREFETCHWT1\s0 instruction set support.
! .IP "\fBknm\fR" 4
  .IX Item "knm"
! Intel Knights Mill \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
! AVX512PF, AVX512ER, AVX512F, AVX512CD\s0 and \s-1PREFETCHWT1, AVX5124VNNIW,
! AVX5124FMAPS\s0 and \s-1AVX512VPOPCNTDQ\s0 instruction set support.
! .IP "\fBk6\fR" 4
  .IX Item "k6"
! \&\s-1AMD K6 CPU\s0 with \s-1MMX\s0 instruction set support.
! .IP "\fBk6\-2\fR" 4
  .IX Item "k6-2"
  .PD 0
! .IP "\fBk6\-3\fR" 4
  .IX Item "k6-3"
  .PD
! Improved versions of \s-1AMD K6 CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
! .IP "\fBathlon\fR" 4
  .IX Item "athlon"
  .PD 0
! .IP "\fBathlon-tbird\fR" 4
  .IX Item "athlon-tbird"
  .PD
! \&\s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX,\s0 3dNOW!, enhanced 3DNow! and \s-1SSE\s0 prefetch instructions
  support.
! .IP "\fBathlon\-4\fR" 4
  .IX Item "athlon-4"
  .PD 0
! .IP "\fBathlon-xp\fR" 4
  .IX Item "athlon-xp"
! .IP "\fBathlon-mp\fR" 4
  .IX Item "athlon-mp"
  .PD
! Improved \s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX,\s0 3DNow!, enhanced 3DNow! and full \s-1SSE\s0
  instruction set support.
! .IP "\fBk8\fR" 4
  .IX Item "k8"
  .PD 0
! .IP "\fBopteron\fR" 4
  .IX Item "opteron"
! .IP "\fBathlon64\fR" 4
  .IX Item "athlon64"
! .IP "\fBathlon-fx\fR" 4
  .IX Item "athlon-fx"
  .PD
! Processors based on the \s-1AMD K8\s0 core with x86\-64 instruction set support,
! including the \s-1AMD\s0 Opteron, Athlon 64, and Athlon 64 \s-1FX\s0 processors.
! (This supersets \s-1MMX, SSE, SSE2,\s0 3DNow!, enhanced 3DNow! and 64\-bit
  instruction set extensions.)
! .IP "\fBk8\-sse3\fR" 4
  .IX Item "k8-sse3"
  .PD 0
! .IP "\fBopteron\-sse3\fR" 4
  .IX Item "opteron-sse3"
! .IP "\fBathlon64\-sse3\fR" 4
  .IX Item "athlon64-sse3"
  .PD
! Improved versions of \s-1AMD K8\s0 cores with \s-1SSE3\s0 instruction set support.
! .IP "\fBamdfam10\fR" 4
  .IX Item "amdfam10"
  .PD 0
! .IP "\fBbarcelona\fR" 4
  .IX Item "barcelona"
  .PD
! CPUs based on \s-1AMD\s0 Family 10h cores with x86\-64 instruction set support.  (This
! supersets \s-1MMX, SSE, SSE2, SSE3, SSE4A,\s0 3DNow!, enhanced 3DNow!, \s-1ABM\s0 and 64\-bit
  instruction set extensions.)
! .IP "\fBbdver1\fR" 4
  .IX Item "bdver1"
! CPUs based on \s-1AMD\s0 Family 15h cores with x86\-64 instruction set support.  (This
! supersets \s-1FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A,
! SSSE3, SSE4.1, SSE4.2, ABM\s0 and 64\-bit instruction set extensions.)
! .IP "\fBbdver2\fR" 4
  .IX Item "bdver2"
! \&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets \s-1BMI, TBM, F16C, FMA, FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX,
! SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM\s0 and 64\-bit instruction set 
  extensions.)
! .IP "\fBbdver3\fR" 4
  .IX Item "bdver3"
! \&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets \s-1BMI, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, XOP, LWP, AES,\s0 
! \&\s-1PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM\s0 and
  64\-bit instruction set extensions.)
! .IP "\fBbdver4\fR" 4
  .IX Item "bdver4"
! \&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets \s-1BMI, BMI2, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, AVX2, XOP, LWP,\s0 
! \&\s-1AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1,
! SSE4.2, ABM\s0 and 64\-bit instruction set extensions.)
! .IP "\fBznver1\fR" 4
  .IX Item "znver1"
! \&\s-1AMD\s0 Family 17h core based CPUs with x86\-64 instruction set support.  (This
! supersets \s-1BMI, BMI2, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX,
  SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3,
! SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT,\s0 and 64\-bit
  instruction set extensions.)
! .IP "\fBznver2\fR" 4
  .IX Item "znver2"
! \&\s-1AMD\s0 Family 17h core based CPUs with x86\-64 instruction set support. (This
! supersets \s-1BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
! WBNOINVD,\s0 and 64\-bit instruction set extensions.)
! .IP "\fBznver3\fR" 4
  .IX Item "znver3"
! \&\s-1AMD\s0 Family 19h core based CPUs with x86\-64 instruction set support. (This
! supersets \s-1BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
! WBNOINVD, PKU, VPCLMULQDQ, VAES,\s0 and 64\-bit instruction set extensions.)
! .IP "\fBznver4\fR" 4
  .IX Item "znver4"
! \&\s-1AMD\s0 Family 19h core based CPUs with x86\-64 instruction set support. (This
! supersets \s-1BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
  WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD,
  AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI,
! AVX512BITALG, AVX512VPOPCNTDQ, GFNI\s0 and 64\-bit instruction set extensions.)
! .IP "\fBznver5\fR" 4
  .IX Item "znver5"
! \&\s-1AMD\s0 Family 1ah core based CPUs with x86\-64 instruction set support. (This
! supersets \s-1BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
  WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD,
  AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI,
  AVX512BITALG, AVX512VPOPCNTDQ, GFNI, AVXVNNI, MOVDIRI, MOVDIR64B,
! AVX512VP2INTERSECT, PREFETCHI\s0 and 64\-bit instruction set extensions.)
! .IP "\fBbtver1\fR" 4
  .IX Item "btver1"
! CPUs based on \s-1AMD\s0 Family 14h cores with x86\-64 instruction set support.  (This
! supersets \s-1MMX, SSE, SSE2, SSE3, SSSE3, SSE4A, CX16, ABM\s0 and 64\-bit
  instruction set extensions.)
! .IP "\fBbtver2\fR" 4
  .IX Item "btver2"
! CPUs based on \s-1AMD\s0 Family 16h cores with x86\-64 instruction set support. This
! includes \s-1MOVBE, F16C, BMI, AVX, PCLMUL, AES, SSE4.2, SSE4.1, CX16, ABM,
! SSE4A, SSSE3, SSE3, SSE2, SSE, MMX\s0 and 64\-bit instruction set extensions.
! .IP "\fBwinchip\-c6\fR" 4
  .IX Item "winchip-c6"
! \&\s-1IDT\s0 WinChip C6 \s-1CPU,\s0 dealt in same way as i486 with additional \s-1MMX\s0 instruction
  set support.
! .IP "\fBwinchip2\fR" 4
  .IX Item "winchip2"
! \&\s-1IDT\s0 WinChip 2 \s-1CPU,\s0 dealt in same way as i486 with additional \s-1MMX\s0 and 3DNow!
  instruction set support.
! .IP "\fBc3\fR" 4
  .IX Item "c3"
! \&\s-1VIA C3 CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBc3\-2\fR" 4
  .IX Item "c3-2"
! \&\s-1VIA C3\-2\s0 (Nehemiah/C5XL) \s-1CPU\s0 with \s-1MMX\s0 and \s-1SSE\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBc7\fR" 4
  .IX Item "c7"
! \&\s-1VIA C7\s0 (Esther) \s-1CPU\s0 with \s-1MMX, SSE, SSE2\s0 and \s-1SSE3\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBsamuel\-2\fR" 4
  .IX Item "samuel-2"
! \&\s-1VIA\s0 Eden Samuel 2 \s-1CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnehemiah\fR" 4
  .IX Item "nehemiah"
! \&\s-1VIA\s0 Eden Nehemiah \s-1CPU\s0 with \s-1MMX\s0 and \s-1SSE\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBesther\fR" 4
  .IX Item "esther"
! \&\s-1VIA\s0 Eden Esther \s-1CPU\s0 with \s-1MMX, SSE, SSE2\s0 and \s-1SSE3\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBeden\-x2\fR" 4
  .IX Item "eden-x2"
! \&\s-1VIA\s0 Eden X2 \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2\s0 and \s-1SSE3\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBeden\-x4\fR" 4
  .IX Item "eden-x4"
! \&\s-1VIA\s0 Eden X4 \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2,
! AVX\s0 and \s-1AVX2\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\fR" 4
  .IX Item "nano"
! Generic \s-1VIA\s0 Nano \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\-1000\fR" 4
  .IX Item "nano-1000"
! \&\s-1VIA\s0 Nano 1xxx \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\-2000\fR" 4
  .IX Item "nano-2000"
! \&\s-1VIA\s0 Nano 2xxx \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\-3000\fR" 4
  .IX Item "nano-3000"
! \&\s-1VIA\s0 Nano 3xxx \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3, SSSE3\s0 and \s-1SSE4.1\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\-x2\fR" 4
  .IX Item "nano-x2"
! \&\s-1VIA\s0 Nano Dual Core \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3, SSSE3\s0 and \s-1SSE4.1\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\-x4\fR" 4
  .IX Item "nano-x4"
! \&\s-1VIA\s0 Nano Quad Core \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3, SSSE3\s0 and \s-1SSE4.1\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBlujiazui\fR" 4
  .IX Item "lujiazui"
! \&\s-1ZHAOXIN\s0 lujiazui \s-1CPU\s0 with x86\-64, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
  SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16,
! ABM, BMI, BMI2, FXSR, RDSEED\s0 instruction set support.  While the CPUs
! do support \s-1AVX\s0 and F16C, these aren't enabled by \f(CW\*(C`\-march=lujiazui\*(C'\fR
  for performance reasons.
! .IP "\fBgeode\fR" 4
  .IX Item "geode"
! \&\s-1AMD\s0 Geode embedded processor with \s-1MMX\s0 and 3DNow! instruction set support.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
  .IX Item "-mtune=cpu-type"
! Tune to \fIcpu-type\fR everything applicable about the generated code, except
! for the \s-1ABI\s0 and the set of available instructions.  
! While picking a specific \fIcpu-type\fR schedules things appropriately
  for that particular chip, the compiler does not generate any code that
  cannot run on the default machine type unless you use a
! \&\fB\-march=\fR\fIcpu-type\fR option.
! For example, if \s-1GCC\s0 is configured for i686\-pc\-linux\-gnu
  then \fB\-mtune=pentium4\fR generates code that is tuned for Pentium 4
  but still runs on i686 machines.
  .Sp
! The choices for \fIcpu-type\fR are the same as for \fB\-march\fR.
! In addition, \fB\-mtune\fR supports 2 extra choices for \fIcpu-type\fR:
  .RS 4
! .IP "\fBgeneric\fR" 4
  .IX Item "generic"
! Produce code optimized for the most common \s-1IA32/AMD64/EM64T\s0 processors.
! If you know the \s-1CPU\s0 on which your code will run, then you should use
  the corresponding \fB\-mtune\fR or \fB\-march\fR option instead of
! \&\fB\-mtune=generic\fR.  But, if you do not know exactly what \s-1CPU\s0 users
  of your application will have, then you should use this option.
  .Sp
  As new processors are deployed in the marketplace, the behavior of this
  option will change.  Therefore, if you upgrade to a newer version of
! \&\s-1GCC,\s0 code generation controlled by this option will change to reflect
  the processors
! that are most common at the time that version of \s-1GCC\s0 is released.
  .Sp
  There is no \fB\-march=generic\fR option because \fB\-march\fR
  indicates the instruction set the compiler can use, and there is no
  generic instruction set applicable to all processors.  In contrast,
  \&\fB\-mtune\fR indicates the processor (or, in this case, collection of
  processors) for which the code is optimized.
! .IP "\fBintel\fR" 4
  .IX Item "intel"
  Produce code optimized for the most current Intel processors, which are
! Haswell and Silvermont for this version of \s-1GCC.\s0  If you know the \s-1CPU\s0
  on which your code will run, then you should use the corresponding
  \&\fB\-mtune\fR or \fB\-march\fR option instead of \fB\-mtune=intel\fR.
  But, if you want your application performs better on both Haswell and
--- 31302,31897 ----
  .IX Subsection "x86 Options"
  .PP
  These \fB\-m\fR options are defined for the x86 family of computers.
! .IP \fB\-march=\fR\fIcpu\-type\fR 4
  .IX Item "-march=cpu-type"
! Generate instructions for the machine type \fIcpu\-type\fR.  In contrast to
! \&\fB\-mtune=\fR\fIcpu\-type\fR, which merely tunes the generated code 
! for the specified \fIcpu\-type\fR, \fB\-march=\fR\fIcpu\-type\fR allows GCC
  to generate code that may not run at all on processors other than the one
! indicated.  Specifying \fB\-march=\fR\fIcpu\-type\fR implies 
! \&\fB\-mtune=\fR\fIcpu\-type\fR, except where noted otherwise.
  .Sp
! The choices for \fIcpu\-type\fR are:
  .RS 4
! .IP \fBnative\fR 4
  .IX Item "native"
! This selects the CPU to generate code for at compilation time by determining
  the processor type of the compiling machine.  Using \fB\-march=native\fR
  enables all instruction subsets supported by the local machine (hence
  the result might not run on different machines).  Using \fB\-mtune=native\fR
  produces code optimized for the local machine under the constraints
  of the selected instruction set.
! .IP \fBx86\-64\fR 4
  .IX Item "x86-64"
! A generic CPU with 64\-bit extensions.
! .IP \fBx86\-64\-v2\fR 4
  .IX Item "x86-64-v2"
  .PD 0
! .IP \fBx86\-64\-v3\fR 4
  .IX Item "x86-64-v3"
! .IP \fBx86\-64\-v4\fR 4
  .IX Item "x86-64-v4"
  .PD
! These choices for \fIcpu\-type\fR select the corresponding
! micro\-architecture level from the x86\-64 psABI.  On ABIs other than
! the x86\-64 psABI they select the same CPU features as the x86\-64 psABI
! documents for the particular micro\-architecture level.
  .Sp
! Since these \fIcpu\-type\fR values do not have a corresponding
  \&\fB\-mtune\fR setting, using \fB\-march\fR with these values enables
  generic tuning.  Specific tuning can be enabled using the
! \&\fB\-mtune=\fR\fIother\-cpu\-type\fR option with an appropriate
! \&\fIother\-cpu\-type\fR value.
! .IP \fBi386\fR 4
  .IX Item "i386"
! Original Intel i386 CPU.
! .IP \fBi486\fR 4
  .IX Item "i486"
! Intel i486 CPU.  (No scheduling is implemented for this chip.)
! .IP \fBi586\fR 4
  .IX Item "i586"
  .PD 0
! .IP \fBpentium\fR 4
  .IX Item "pentium"
  .PD
! Intel Pentium CPU with no MMX support.
! .IP \fBlakemont\fR 4
  .IX Item "lakemont"
! Intel Lakemont MCU, based on Intel Pentium CPU.
! .IP \fBpentium\-mmx\fR 4
  .IX Item "pentium-mmx"
! Intel Pentium MMX CPU, based on Pentium core with MMX instruction set support.
! .IP \fBpentiumpro\fR 4
  .IX Item "pentiumpro"
! Intel Pentium Pro CPU.
! .IP \fBi686\fR 4
  .IX Item "i686"
  When used with \fB\-march\fR, the Pentium Pro
  instruction set is used, so the code runs on all i686 family chips.
  When used with \fB\-mtune\fR, it has the same meaning as \fBgeneric\fR.
! .IP \fBpentium2\fR 4
  .IX Item "pentium2"
! Intel Pentium II CPU, based on Pentium Pro core with MMX and FXSR instruction
  set support.
! .IP \fBpentium3\fR 4
  .IX Item "pentium3"
  .PD 0
! .IP \fBpentium3m\fR 4
  .IX Item "pentium3m"
  .PD
! Intel Pentium III CPU, based on Pentium Pro core with MMX, FXSR and SSE
  instruction set support.
! .IP \fBpentium\-m\fR 4
  .IX Item "pentium-m"
! Intel Pentium M; low\-power version of Intel Pentium III CPU
! with MMX, SSE, SSE2 and FXSR instruction set support.  Used by Centrino
  notebooks.
! .IP \fBpentium4\fR 4
  .IX Item "pentium4"
  .PD 0
! .IP \fBpentium4m\fR 4
  .IX Item "pentium4m"
  .PD
! Intel Pentium 4 CPU with MMX, SSE, SSE2 and FXSR instruction set support.
! .IP \fBprescott\fR 4
  .IX Item "prescott"
! Improved version of Intel Pentium 4 CPU with MMX, SSE, SSE2, SSE3 and FXSR
  instruction set support.
! .IP \fBnocona\fR 4
  .IX Item "nocona"
! Improved version of Intel Pentium 4 CPU with 64\-bit extensions, MMX, SSE,
! SSE2, SSE3 and FXSR instruction set support.
! .IP \fBcore2\fR 4
  .IX Item "core2"
! Intel Core 2 CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, CX16,
! SAHF and FXSR instruction set support.
! .IP \fBnehalem\fR 4
  .IX Item "nehalem"
  .PD 0
! .IP \fBcorei7\fR 4
  .IX Item "corei7"
  .PD
! Intel Nehalem CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF and FXSR instruction set support.
! .IP \fBwestmere\fR 4
  .IX Item "westmere"
! Intel Westmere CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR and PCLMUL instruction set support.
! .IP \fBsandybridge\fR 4
  .IX Item "sandybridge"
  .PD 0
! .IP \fBcorei7\-avx\fR 4
  .IX Item "corei7-avx"
  .PD
! Intel Sandy Bridge CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE and PCLMUL instruction set
  support.
! .IP \fBivybridge\fR 4
  .IX Item "ivybridge"
  .PD 0
! .IP \fBcore\-avx\-i\fR 4
  .IX Item "core-avx-i"
  .PD
! Intel Ivy Bridge CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND
  and F16C instruction set support.
! .IP \fBhaswell\fR 4
  .IX Item "haswell"
  .PD 0
! .IP \fBcore\-avx2\fR 4
  .IX Item "core-avx2"
  .PD
! Intel Haswell CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
! F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE and HLE instruction set support.
! .IP \fBbroadwell\fR 4
  .IX Item "broadwell"
! Intel Broadwell CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
! F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX and PREFETCHW
  instruction set support.
! .IP \fBskylake\fR 4
  .IX Item "skylake"
! Intel Skylake CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
! CLFLUSHOPT, XSAVEC, XSAVES and SGX instruction set support.
! .IP \fBskylake\-avx512\fR 4
  .IX Item "skylake-avx512"
! Intel Skylake Server CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW,
! AVX512DQ and AVX512CD instruction set support.
! .IP \fBcascadelake\fR 4
  .IX Item "cascadelake"
! Intel Cascade Lake CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ,
! AVX512CD and AVX512VNNI instruction set support.
! .IP \fBcannonlake\fR 4
  .IX Item "cannonlake"
! Intel Cannon Lake Server CPU with 64\-bit extensions, MMX, SSE, SSE2,
  SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL,
  FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX,
  PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW,
! AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA and SHA instruction set
  support.
! .IP \fBcooperlake\fR 4
  .IX Item "cooperlake"
! Intel Cooper Lake CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ,
! AVX512CD, AVX512VNNI and AVX512BF16 instruction set support.
! .IP \fBicelake\-client\fR 4
  .IX Item "icelake-client"
! Intel Ice Lake Client CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2
! , VPCLMULQDQ, AVX512BITALG, RDPID and AVX512VPOPCNTDQ instruction set support.
! .IP \fBicelake\-server\fR 4
  .IX Item "icelake-server"
! Intel Ice Lake Server CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2
! , VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD and CLWB
  instruction set support.
! .IP \fBtigerlake\fR 4
  .IX Item "tigerlake"
! Intel Tiger Lake CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD
  PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, MOVDIRI, MOVDIR64B, CLWB,
! AVX512VP2INTERSECT and KEYLOCKER instruction set support.
! .IP \fBrocketlake\fR 4
  .IX Item "rocketlake"
! Intel Rocket Lake CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD
  PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
! VPCLMULQDQ, AVX512BITALG, RDPID and AVX512VPOPCNTDQ instruction set support.
! .IP \fBalderlake\fR 4
  .IX Item "alderlake"
  .PD 0
! .IP \fBraptorlake\fR 4
  .IX Item "raptorlake"
! .IP \fBmeteorlake\fR 4
  .IX Item "meteorlake"
  .PD
! Intel Alder Lake/Raptor Lake/Meteor Lake CPU with 64\-bit extensions, MOVBE,
! MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL,
! RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX,
! GFNI\-SSE, CLWB, MOVDIRI, MOVDIR64B, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C,
! FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL and
! AVX\-VNNI instruction set support.
! .IP \fBsapphirerapids\fR 4
  .IX Item "sapphirerapids"
  .PD 0
! .IP \fBemeraldrapids\fR 4
  .IX Item "emeraldrapids"
  .PD
! Intel Sapphire Rapids/Emerald Rapids CPU with 64\-bit extensions, MMX, SSE,
  SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL,
  FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX,
  PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW,
  AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES,
  AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG,
  WBNOINVD, CLWB, MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG,
! SERIALIZE, TSXLDTRK, UINTR, AMX\-BF16, AMX\-TILE, AMX\-INT8, AVX\-VNNI, AVX512\-FP16
! and AVX512BF16 instruction set support.
! .IP \fBgraniterapids\fR 4
  .IX Item "graniterapids"
! Intel Granite Rapids CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB,
  MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK,
! UINTR, AMX\-BF16, AMX\-TILE, AMX\-INT8, AVX\-VNNI, AVX512\-FP16, AVX512BF16, AMX\-FP16
! and PREFETCHI instruction set support.
! .IP \fBgraniterapids\-d\fR 4
  .IX Item "graniterapids-d"
! Intel Granite Rapids D CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB,
  MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK,
! UINTR, AMX\-BF16, AMX\-TILE, AMX\-INT8, AVX\-VNNI, AVX512FP16, AVX512BF16, AMX\-FP16,
! PREFETCHI and AMX\-COMPLEX instruction set support.
! .IP \fBbonnell\fR 4
  .IX Item "bonnell"
  .PD 0
! .IP \fBatom\fR 4
  .IX Item "atom"
  .PD
! Intel Bonnell CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3 and SSSE3
  instruction set support.
! .IP \fBsilvermont\fR 4
  .IX Item "silvermont"
  .PD 0
! .IP \fBslm\fR 4
  .IX Item "slm"
  .PD
! Intel Silvermont CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW and RDRND
  instruction set support.
! .IP \fBgoldmont\fR 4
  .IX Item "goldmont"
! Intel Goldmont CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA,
! RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT and FSGSBASE instruction
  set support.
! .IP \fBgoldmont\-plus\fR 4
  .IX Item "goldmont-plus"
! Intel Goldmont Plus CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES,
  SHA, RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE,
! RDPID and SGX instruction set support.
! .IP \fBtremont\fR 4
  .IX Item "tremont"
! Intel Tremont CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA,
  RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE, RDPID,
! SGX, CLWB, GFNI\-SSE, MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG instruction set
  support.
! .IP \fBsierraforest\fR 4
  .IX Item "sierraforest"
! Intel Sierra Forest CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC,
! XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI\-SSE, CLWB, MOVDIRI,
  MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT,
! PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX\-VNNI,
! AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, ENQCMD and UINTR instruction set
  support.
! .IP \fBgrandridge\fR 4
  .IX Item "grandridge"
! Intel Grand Ridge CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC,
! XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI\-SSE, CLWB, MOVDIRI,
  MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT,
! PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX\-VNNI,
! AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, ENQCMD and UINTR instruction set
  support.
! .IP \fBknl\fR 4
  .IX Item "knl"
! Intel Knights Landing CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
! AVX512PF, AVX512ER, AVX512F, AVX512CD and PREFETCHWT1 instruction set support.
! .IP \fBknm\fR 4
  .IX Item "knm"
! Intel Knights Mill CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
! AVX512PF, AVX512ER, AVX512F, AVX512CD and PREFETCHWT1, AVX5124VNNIW,
! AVX5124FMAPS and AVX512VPOPCNTDQ instruction set support.
! .IP \fBk6\fR 4
  .IX Item "k6"
! AMD K6 CPU with MMX instruction set support.
! .IP \fBk6\-2\fR 4
  .IX Item "k6-2"
  .PD 0
! .IP \fBk6\-3\fR 4
  .IX Item "k6-3"
  .PD
! Improved versions of AMD K6 CPU with MMX and 3DNow! instruction set support.
! .IP \fBathlon\fR 4
  .IX Item "athlon"
  .PD 0
! .IP \fBathlon\-tbird\fR 4
  .IX Item "athlon-tbird"
  .PD
! AMD Athlon CPU with MMX, 3dNOW!, enhanced 3DNow! and SSE prefetch instructions
  support.
! .IP \fBathlon\-4\fR 4
  .IX Item "athlon-4"
  .PD 0
! .IP \fBathlon\-xp\fR 4
  .IX Item "athlon-xp"
! .IP \fBathlon\-mp\fR 4
  .IX Item "athlon-mp"
  .PD
! Improved AMD Athlon CPU with MMX, 3DNow!, enhanced 3DNow! and full SSE
  instruction set support.
! .IP \fBk8\fR 4
  .IX Item "k8"
  .PD 0
! .IP \fBopteron\fR 4
  .IX Item "opteron"
! .IP \fBathlon64\fR 4
  .IX Item "athlon64"
! .IP \fBathlon\-fx\fR 4
  .IX Item "athlon-fx"
  .PD
! Processors based on the AMD K8 core with x86\-64 instruction set support,
! including the AMD Opteron, Athlon 64, and Athlon 64 FX processors.
! (This supersets MMX, SSE, SSE2, 3DNow!, enhanced 3DNow! and 64\-bit
  instruction set extensions.)
! .IP \fBk8\-sse3\fR 4
  .IX Item "k8-sse3"
  .PD 0
! .IP \fBopteron\-sse3\fR 4
  .IX Item "opteron-sse3"
! .IP \fBathlon64\-sse3\fR 4
  .IX Item "athlon64-sse3"
  .PD
! Improved versions of AMD K8 cores with SSE3 instruction set support.
! .IP \fBamdfam10\fR 4
  .IX Item "amdfam10"
  .PD 0
! .IP \fBbarcelona\fR 4
  .IX Item "barcelona"
  .PD
! CPUs based on AMD Family 10h cores with x86\-64 instruction set support.  (This
! supersets MMX, SSE, SSE2, SSE3, SSE4A, 3DNow!, enhanced 3DNow!, ABM and 64\-bit
  instruction set extensions.)
! .IP \fBbdver1\fR 4
  .IX Item "bdver1"
! CPUs based on AMD Family 15h cores with x86\-64 instruction set support.  (This
! supersets FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A,
! SSSE3, SSE4.1, SSE4.2, ABM and 64\-bit instruction set extensions.)
! .IP \fBbdver2\fR 4
  .IX Item "bdver2"
! AMD Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets BMI, TBM, F16C, FMA, FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX,
! SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64\-bit instruction set 
  extensions.)
! .IP \fBbdver3\fR 4
  .IX Item "bdver3"
! AMD Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets BMI, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, XOP, LWP, AES, 
! PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and
  64\-bit instruction set extensions.)
! .IP \fBbdver4\fR 4
  .IX Item "bdver4"
! AMD Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets BMI, BMI2, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, AVX2, XOP, LWP, 
! AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1,
! SSE4.2, ABM and 64\-bit instruction set extensions.)
! .IP \fBznver1\fR 4
  .IX Item "znver1"
! AMD Family 17h core based CPUs with x86\-64 instruction set support.  (This
! supersets BMI, BMI2, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX,
  SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3,
! SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, and 64\-bit
  instruction set extensions.)
! .IP \fBznver2\fR 4
  .IX Item "znver2"
! AMD Family 17h core based CPUs with x86\-64 instruction set support. (This
! supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
! WBNOINVD, and 64\-bit instruction set extensions.)
! .IP \fBznver3\fR 4
  .IX Item "znver3"
! AMD Family 19h core based CPUs with x86\-64 instruction set support. (This
! supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
! WBNOINVD, PKU, VPCLMULQDQ, VAES, and 64\-bit instruction set extensions.)
! .IP \fBznver4\fR 4
  .IX Item "znver4"
! AMD Family 19h core based CPUs with x86\-64 instruction set support. (This
! supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
  WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD,
  AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI,
! AVX512BITALG, AVX512VPOPCNTDQ, GFNI and 64\-bit instruction set extensions.)
! .IP \fBznver5\fR 4
  .IX Item "znver5"
! AMD Family 1ah core based CPUs with x86\-64 instruction set support. (This
! supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
  WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD,
  AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI,
  AVX512BITALG, AVX512VPOPCNTDQ, GFNI, AVXVNNI, MOVDIRI, MOVDIR64B,
! AVX512VP2INTERSECT, PREFETCHI and 64\-bit instruction set extensions.)
! .IP \fBbtver1\fR 4
  .IX Item "btver1"
! CPUs based on AMD Family 14h cores with x86\-64 instruction set support.  (This
! supersets MMX, SSE, SSE2, SSE3, SSSE3, SSE4A, CX16, ABM and 64\-bit
  instruction set extensions.)
! .IP \fBbtver2\fR 4
  .IX Item "btver2"
! CPUs based on AMD Family 16h cores with x86\-64 instruction set support. This
! includes MOVBE, F16C, BMI, AVX, PCLMUL, AES, SSE4.2, SSE4.1, CX16, ABM,
! SSE4A, SSSE3, SSE3, SSE2, SSE, MMX and 64\-bit instruction set extensions.
! .IP \fBwinchip\-c6\fR 4
  .IX Item "winchip-c6"
! IDT WinChip C6 CPU, dealt in same way as i486 with additional MMX instruction
  set support.
! .IP \fBwinchip2\fR 4
  .IX Item "winchip2"
! IDT WinChip 2 CPU, dealt in same way as i486 with additional MMX and 3DNow!
  instruction set support.
! .IP \fBc3\fR 4
  .IX Item "c3"
! VIA C3 CPU with MMX and 3DNow! instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBc3\-2\fR 4
  .IX Item "c3-2"
! VIA C3\-2 (Nehemiah/C5XL) CPU with MMX and SSE instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBc7\fR 4
  .IX Item "c7"
! VIA C7 (Esther) CPU with MMX, SSE, SSE2 and SSE3 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBsamuel\-2\fR 4
  .IX Item "samuel-2"
! VIA Eden Samuel 2 CPU with MMX and 3DNow! instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnehemiah\fR 4
  .IX Item "nehemiah"
! VIA Eden Nehemiah CPU with MMX and SSE instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBesther\fR 4
  .IX Item "esther"
! VIA Eden Esther CPU with MMX, SSE, SSE2 and SSE3 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBeden\-x2\fR 4
  .IX Item "eden-x2"
! VIA Eden X2 CPU with x86\-64, MMX, SSE, SSE2 and SSE3 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBeden\-x4\fR 4
  .IX Item "eden-x4"
! VIA Eden X4 CPU with x86\-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2,
! AVX and AVX2 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\fR 4
  .IX Item "nano"
! Generic VIA Nano CPU with x86\-64, MMX, SSE, SSE2, SSE3 and SSSE3
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\-1000\fR 4
  .IX Item "nano-1000"
! VIA Nano 1xxx CPU with x86\-64, MMX, SSE, SSE2, SSE3 and SSSE3
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\-2000\fR 4
  .IX Item "nano-2000"
! VIA Nano 2xxx CPU with x86\-64, MMX, SSE, SSE2, SSE3 and SSSE3
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\-3000\fR 4
  .IX Item "nano-3000"
! VIA Nano 3xxx CPU with x86\-64, MMX, SSE, SSE2, SSE3, SSSE3 and SSE4.1
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\-x2\fR 4
  .IX Item "nano-x2"
! VIA Nano Dual Core CPU with x86\-64, MMX, SSE, SSE2, SSE3, SSSE3 and SSE4.1
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\-x4\fR 4
  .IX Item "nano-x4"
! VIA Nano Quad Core CPU with x86\-64, MMX, SSE, SSE2, SSE3, SSSE3 and SSE4.1
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBlujiazui\fR 4
  .IX Item "lujiazui"
! ZHAOXIN lujiazui CPU with x86\-64, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
  SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16,
! ABM, BMI, BMI2, FXSR, RDSEED instruction set support.  While the CPUs
! do support AVX and F16C, these aren\*(Aqt enabled by \f(CW\*(C`\-march=lujiazui\*(C'\fR
  for performance reasons.
! .IP \fBgeode\fR 4
  .IX Item "geode"
! AMD Geode embedded processor with MMX and 3DNow! instruction set support.
  .RE
  .RS 4
  .RE
! .IP \fB\-mtune=\fR\fIcpu\-type\fR 4
  .IX Item "-mtune=cpu-type"
! Tune to \fIcpu\-type\fR everything applicable about the generated code, except
! for the ABI and the set of available instructions.  
! While picking a specific \fIcpu\-type\fR schedules things appropriately
  for that particular chip, the compiler does not generate any code that
  cannot run on the default machine type unless you use a
! \&\fB\-march=\fR\fIcpu\-type\fR option.
! For example, if GCC is configured for i686\-pc\-linux\-gnu
  then \fB\-mtune=pentium4\fR generates code that is tuned for Pentium 4
  but still runs on i686 machines.
  .Sp
! The choices for \fIcpu\-type\fR are the same as for \fB\-march\fR.
! In addition, \fB\-mtune\fR supports 2 extra choices for \fIcpu\-type\fR:
  .RS 4
! .IP \fBgeneric\fR 4
  .IX Item "generic"
! Produce code optimized for the most common IA32/AMD64/EM64T processors.
! If you know the CPU on which your code will run, then you should use
  the corresponding \fB\-mtune\fR or \fB\-march\fR option instead of
! \&\fB\-mtune=generic\fR.  But, if you do not know exactly what CPU users
  of your application will have, then you should use this option.
  .Sp
  As new processors are deployed in the marketplace, the behavior of this
  option will change.  Therefore, if you upgrade to a newer version of
! GCC, code generation controlled by this option will change to reflect
  the processors
! that are most common at the time that version of GCC is released.
  .Sp
  There is no \fB\-march=generic\fR option because \fB\-march\fR
  indicates the instruction set the compiler can use, and there is no
  generic instruction set applicable to all processors.  In contrast,
  \&\fB\-mtune\fR indicates the processor (or, in this case, collection of
  processors) for which the code is optimized.
! .IP \fBintel\fR 4
  .IX Item "intel"
  Produce code optimized for the most current Intel processors, which are
! Haswell and Silvermont for this version of GCC.  If you know the CPU
  on which your code will run, then you should use the corresponding
  \&\fB\-mtune\fR or \fB\-march\fR option instead of \fB\-mtune=intel\fR.
  But, if you want your application performs better on both Haswell and
*************** Silvermont, then you should use this opt
*** 31968,31975 ****
  .Sp
  As new Intel processors are deployed in the marketplace, the behavior of
  this option will change.  Therefore, if you upgrade to a newer version of
! \&\s-1GCC,\s0 code generation controlled by this option will change to reflect
! the most current Intel processors at the time that version of \s-1GCC\s0 is
  released.
  .Sp
  There is no \fB\-march=intel\fR option because \fB\-march\fR indicates
--- 31899,31906 ----
  .Sp
  As new Intel processors are deployed in the marketplace, the behavior of
  this option will change.  Therefore, if you upgrade to a newer version of
! GCC, code generation controlled by this option will change to reflect
! the most current Intel processors at the time that version of GCC is
  released.
  .Sp
  There is no \fB\-march=intel\fR option because \fB\-march\fR indicates
*************** processors) for which the code is optimi
*** 31980,32015 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
  .IX Item "-mcpu=cpu-type"
  A deprecated synonym for \fB\-mtune\fR.
! .IP "\fB\-mfpmath=\fR\fIunit\fR" 4
  .IX Item "-mfpmath=unit"
! Generate floating-point arithmetic for selected unit \fIunit\fR.  The choices
  for \fIunit\fR are:
  .RS 4
! .IP "\fB387\fR" 4
  .IX Item "387"
! Use the standard 387 floating-point coprocessor present on the majority of chips and
  emulated otherwise.  Code compiled with this option runs almost everywhere.
  The temporary results are computed in 80\-bit precision instead of the precision
  specified by the type, resulting in slightly different results compared to most
  of other chips.  See \fB\-ffloat\-store\fR for more detailed description.
  .Sp
! This is the default choice for non-Darwin x86\-32 targets.
! .IP "\fBsse\fR" 4
  .IX Item "sse"
! Use scalar floating-point instructions present in the \s-1SSE\s0 instruction set.
! This instruction set is supported by Pentium \s-1III\s0 and newer chips,
! and in the \s-1AMD\s0 line
! by Athlon\-4, Athlon \s-1XP\s0 and Athlon \s-1MP\s0 chips.  The earlier version of the \s-1SSE\s0
! instruction set supports only single-precision arithmetic, thus the double and
! extended-precision arithmetic are still done using 387.  A later version, present
! only in Pentium 4 and \s-1AMD\s0 x86\-64 chips, supports double-precision
  arithmetic too.
  .Sp
! For the x86\-32 compiler, you must use \fB\-march=\fR\fIcpu-type\fR, \fB\-msse\fR
! or \fB\-msse2\fR switches to enable \s-1SSE\s0 extensions and make this option
  effective.  For the x86\-64 compiler, these extensions are enabled by default.
  .Sp
  The resulting code should be considerably faster in the majority of cases and avoid
--- 31911,31946 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-mcpu=\fR\fIcpu\-type\fR 4
  .IX Item "-mcpu=cpu-type"
  A deprecated synonym for \fB\-mtune\fR.
! .IP \fB\-mfpmath=\fR\fIunit\fR 4
  .IX Item "-mfpmath=unit"
! Generate floating\-point arithmetic for selected unit \fIunit\fR.  The choices
  for \fIunit\fR are:
  .RS 4
! .IP \fB387\fR 4
  .IX Item "387"
! Use the standard 387 floating\-point coprocessor present on the majority of chips and
  emulated otherwise.  Code compiled with this option runs almost everywhere.
  The temporary results are computed in 80\-bit precision instead of the precision
  specified by the type, resulting in slightly different results compared to most
  of other chips.  See \fB\-ffloat\-store\fR for more detailed description.
  .Sp
! This is the default choice for non\-Darwin x86\-32 targets.
! .IP \fBsse\fR 4
  .IX Item "sse"
! Use scalar floating\-point instructions present in the SSE instruction set.
! This instruction set is supported by Pentium III and newer chips,
! and in the AMD line
! by Athlon\-4, Athlon XP and Athlon MP chips.  The earlier version of the SSE
! instruction set supports only single\-precision arithmetic, thus the double and
! extended\-precision arithmetic are still done using 387.  A later version, present
! only in Pentium 4 and AMD x86\-64 chips, supports double\-precision
  arithmetic too.
  .Sp
! For the x86\-32 compiler, you must use \fB\-march=\fR\fIcpu\-type\fR, \fB\-msse\fR
! or \fB\-msse2\fR switches to enable SSE extensions and make this option
  effective.  For the x86\-64 compiler, these extensions are enabled by default.
  .Sp
  The resulting code should be considerably faster in the majority of cases and avoid
*************** the numerical instability problems of 38
*** 32017,32110 ****
  code that expects temporaries to be 80 bits.
  .Sp
  This is the default choice for the x86\-64 compiler, Darwin x86\-32 targets,
! and the default choice for x86\-32 targets with the \s-1SSE2\s0 instruction set
  when \fB\-ffast\-math\fR is enabled.
! .IP "\fBsse,387\fR" 4
  .IX Item "sse,387"
  .PD 0
! .IP "\fBsse+387\fR" 4
  .IX Item "sse+387"
! .IP "\fBboth\fR" 4
  .IX Item "both"
  .PD
  Attempt to utilize both instruction sets at once.  This effectively doubles the
  amount of available registers, and on chips with separate execution units for
! 387 and \s-1SSE\s0 the execution resources too.  Use this option with care, as it is
! still experimental, because the \s-1GCC\s0 register allocator does not model separate
  functional units well, resulting in unstable performance.
  .RE
  .RS 4
  .RE
! .IP "\fB\-masm=\fR\fIdialect\fR" 4
  .IX Item "-masm=dialect"
  Output assembly instructions using selected \fIdialect\fR.  Also affects
  which dialect is used for basic \f(CW\*(C`asm\*(C'\fR and
  extended \f(CW\*(C`asm\*(C'\fR. Supported choices (in dialect
  order) are \fBatt\fR or \fBintel\fR. The default is \fBatt\fR. Darwin does
  not support \fBintel\fR.
! .IP "\fB\-mieee\-fp\fR" 4
  .IX Item "-mieee-fp"
  .PD 0
! .IP "\fB\-mno\-ieee\-fp\fR" 4
  .IX Item "-mno-ieee-fp"
  .PD
! Control whether or not the compiler uses \s-1IEEE\s0 floating-point
  comparisons.  These correctly handle the case where the result of a
  comparison is unordered.
! .IP "\fB\-m80387\fR" 4
  .IX Item "-m80387"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
  Generate output containing 80387 instructions for floating point.
! .IP "\fB\-mno\-80387\fR" 4
  .IX Item "-mno-80387"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
  Generate output containing library calls for floating point.
  .Sp
! \&\fBWarning:\fR the requisite libraries are not part of \s-1GCC.\s0
! Normally the facilities of the machine's usual C compiler are used, but
! this cannot be done directly in cross-compilation.  You must make your
  own arrangements to provide suitable library functions for
! cross-compilation.
  .Sp
! On machines where a function returns floating-point results in the 80387
! register stack, some floating-point opcodes may be emitted even if
  \&\fB\-msoft\-float\fR is used.
! .IP "\fB\-mno\-fp\-ret\-in\-387\fR" 4
  .IX Item "-mno-fp-ret-in-387"
! Do not use the \s-1FPU\s0 registers for return values of functions.
  .Sp
  The usual calling convention has functions return values of types
! \&\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR in an \s-1FPU\s0 register, even if there
! is no \s-1FPU.\s0  The idea is that the operating system should emulate
! an \s-1FPU.\s0
  .Sp
  The option \fB\-mno\-fp\-ret\-in\-387\fR causes such values to be returned
! in ordinary \s-1CPU\s0 registers instead.
! .IP "\fB\-mno\-fancy\-math\-387\fR" 4
  .IX Item "-mno-fancy-math-387"
  Some 387 emulators do not support the \f(CW\*(C`sin\*(C'\fR, \f(CW\*(C`cos\*(C'\fR and
  \&\f(CW\*(C`sqrt\*(C'\fR instructions for the 387.  Specify this option to avoid
  generating those instructions.
  This option is overridden when \fB\-march\fR
! indicates that the target \s-1CPU\s0 always has an \s-1FPU\s0 and so the
  instruction does not need emulation.  These
  instructions are not generated unless you also use the
  \&\fB\-funsafe\-math\-optimizations\fR switch.
! .IP "\fB\-malign\-double\fR" 4
  .IX Item "-malign-double"
  .PD 0
! .IP "\fB\-mno\-align\-double\fR" 4
  .IX Item "-mno-align-double"
  .PD
! Control whether \s-1GCC\s0 aligns \f(CW\*(C`double\*(C'\fR, \f(CW\*(C`long double\*(C'\fR, and
! \&\f(CW\*(C`long long\*(C'\fR variables on a two-word boundary or a one-word
! boundary.  Aligning \f(CW\*(C`double\*(C'\fR variables on a two-word boundary
  produces code that runs somewhat faster on a Pentium at the
  expense of more memory.
  .Sp
--- 31948,32041 ----
  code that expects temporaries to be 80 bits.
  .Sp
  This is the default choice for the x86\-64 compiler, Darwin x86\-32 targets,
! and the default choice for x86\-32 targets with the SSE2 instruction set
  when \fB\-ffast\-math\fR is enabled.
! .IP \fBsse,387\fR 4
  .IX Item "sse,387"
  .PD 0
! .IP \fBsse+387\fR 4
  .IX Item "sse+387"
! .IP \fBboth\fR 4
  .IX Item "both"
  .PD
  Attempt to utilize both instruction sets at once.  This effectively doubles the
  amount of available registers, and on chips with separate execution units for
! 387 and SSE the execution resources too.  Use this option with care, as it is
! still experimental, because the GCC register allocator does not model separate
  functional units well, resulting in unstable performance.
  .RE
  .RS 4
  .RE
! .IP \fB\-masm=\fR\fIdialect\fR 4
  .IX Item "-masm=dialect"
  Output assembly instructions using selected \fIdialect\fR.  Also affects
  which dialect is used for basic \f(CW\*(C`asm\*(C'\fR and
  extended \f(CW\*(C`asm\*(C'\fR. Supported choices (in dialect
  order) are \fBatt\fR or \fBintel\fR. The default is \fBatt\fR. Darwin does
  not support \fBintel\fR.
! .IP \fB\-mieee\-fp\fR 4
  .IX Item "-mieee-fp"
  .PD 0
! .IP \fB\-mno\-ieee\-fp\fR 4
  .IX Item "-mno-ieee-fp"
  .PD
! Control whether or not the compiler uses IEEE floating\-point
  comparisons.  These correctly handle the case where the result of a
  comparison is unordered.
! .IP \fB\-m80387\fR 4
  .IX Item "-m80387"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
  Generate output containing 80387 instructions for floating point.
! .IP \fB\-mno\-80387\fR 4
  .IX Item "-mno-80387"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
  Generate output containing library calls for floating point.
  .Sp
! \&\fBWarning:\fR the requisite libraries are not part of GCC.
! Normally the facilities of the machine\*(Aqs usual C compiler are used, but
! this cannot be done directly in cross\-compilation.  You must make your
  own arrangements to provide suitable library functions for
! cross\-compilation.
  .Sp
! On machines where a function returns floating\-point results in the 80387
! register stack, some floating\-point opcodes may be emitted even if
  \&\fB\-msoft\-float\fR is used.
! .IP \fB\-mno\-fp\-ret\-in\-387\fR 4
  .IX Item "-mno-fp-ret-in-387"
! Do not use the FPU registers for return values of functions.
  .Sp
  The usual calling convention has functions return values of types
! \&\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR in an FPU register, even if there
! is no FPU.  The idea is that the operating system should emulate
! an FPU.
  .Sp
  The option \fB\-mno\-fp\-ret\-in\-387\fR causes such values to be returned
! in ordinary CPU registers instead.
! .IP \fB\-mno\-fancy\-math\-387\fR 4
  .IX Item "-mno-fancy-math-387"
  Some 387 emulators do not support the \f(CW\*(C`sin\*(C'\fR, \f(CW\*(C`cos\*(C'\fR and
  \&\f(CW\*(C`sqrt\*(C'\fR instructions for the 387.  Specify this option to avoid
  generating those instructions.
  This option is overridden when \fB\-march\fR
! indicates that the target CPU always has an FPU and so the
  instruction does not need emulation.  These
  instructions are not generated unless you also use the
  \&\fB\-funsafe\-math\-optimizations\fR switch.
! .IP \fB\-malign\-double\fR 4
  .IX Item "-malign-double"
  .PD 0
! .IP \fB\-mno\-align\-double\fR 4
  .IX Item "-mno-align-double"
  .PD
! Control whether GCC aligns \f(CW\*(C`double\*(C'\fR, \f(CW\*(C`long double\*(C'\fR, and
! \&\f(CW\*(C`long long\*(C'\fR variables on a two\-word boundary or a one\-word
! boundary.  Aligning \f(CW\*(C`double\*(C'\fR variables on a two\-word boundary
  produces code that runs somewhat faster on a Pentium at the
  expense of more memory.
  .Sp
*************** structures containing the above types ar
*** 32115,32124 ****
  the published application binary interface specifications for the x86\-32
  and are not binary compatible with structures in code compiled
  without that switch.
! .IP "\fB\-m96bit\-long\-double\fR" 4
  .IX Item "-m96bit-long-double"
  .PD 0
! .IP "\fB\-m128bit\-long\-double\fR" 4
  .IX Item "-m128bit-long-double"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type.  The x86\-32
--- 32046,32055 ----
  the published application binary interface specifications for the x86\-32
  and are not binary compatible with structures in code compiled
  without that switch.
! .IP \fB\-m96bit\-long\-double\fR 4
  .IX Item "-m96bit-long-double"
  .PD 0
! .IP \fB\-m128bit\-long\-double\fR 4
  .IX Item "-m128bit-long-double"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type.  The x86\-32
*************** so \fB\-m96bit\-long\-double\fR is the d
*** 32127,32155 ****
  .Sp
  Modern architectures (Pentium and newer) prefer \f(CW\*(C`long double\*(C'\fR
  to be aligned to an 8\- or 16\-byte boundary.  In arrays or structures
! conforming to the \s-1ABI,\s0 this is not possible.  So specifying
  \&\fB\-m128bit\-long\-double\fR aligns \f(CW\*(C`long double\*(C'\fR
  to a 16\-byte boundary by padding the \f(CW\*(C`long double\*(C'\fR with an additional
  32\-bit zero.
  .Sp
  In the x86\-64 compiler, \fB\-m128bit\-long\-double\fR is the default choice as
! its \s-1ABI\s0 specifies that \f(CW\*(C`long double\*(C'\fR is aligned on 16\-byte boundary.
  .Sp
  Notice that neither of these options enable any extra precision over the x87
  standard of 80 bits for a \f(CW\*(C`long double\*(C'\fR.
  .Sp
! \&\fBWarning:\fR if you override the default value for your target \s-1ABI,\s0 this
  changes the size of 
  structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
  as well as modifying the function calling convention for functions taking
! \&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary-compatible
  with code compiled without that switch.
! .IP "\fB\-mlong\-double\-64\fR" 4
  .IX Item "-mlong-double-64"
  .PD 0
! .IP "\fB\-mlong\-double\-80\fR" 4
  .IX Item "-mlong-double-80"
! .IP "\fB\-mlong\-double\-128\fR" 4
  .IX Item "-mlong-double-128"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
--- 32058,32086 ----
  .Sp
  Modern architectures (Pentium and newer) prefer \f(CW\*(C`long double\*(C'\fR
  to be aligned to an 8\- or 16\-byte boundary.  In arrays or structures
! conforming to the ABI, this is not possible.  So specifying
  \&\fB\-m128bit\-long\-double\fR aligns \f(CW\*(C`long double\*(C'\fR
  to a 16\-byte boundary by padding the \f(CW\*(C`long double\*(C'\fR with an additional
  32\-bit zero.
  .Sp
  In the x86\-64 compiler, \fB\-m128bit\-long\-double\fR is the default choice as
! its ABI specifies that \f(CW\*(C`long double\*(C'\fR is aligned on 16\-byte boundary.
  .Sp
  Notice that neither of these options enable any extra precision over the x87
  standard of 80 bits for a \f(CW\*(C`long double\*(C'\fR.
  .Sp
! \&\fBWarning:\fR if you override the default value for your target ABI, this
  changes the size of 
  structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
  as well as modifying the function calling convention for functions taking
! \&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary\-compatible
  with code compiled without that switch.
! .IP \fB\-mlong\-double\-64\fR 4
  .IX Item "-mlong-double-64"
  .PD 0
! .IP \fB\-mlong\-double\-80\fR 4
  .IX Item "-mlong-double-80"
! .IP \fB\-mlong\-double\-128\fR 4
  .IX Item "-mlong-double-128"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
*************** type. This is the default for 32\-bit Bi
*** 32158,32185 ****
  of 128 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the
  \&\f(CW\*(C`_\|_float128\*(C'\fR type. This is the default for 64\-bit Bionic C library.
  .Sp
! \&\fBWarning:\fR if you override the default value for your target \s-1ABI,\s0 this
  changes the size of
  structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
  as well as modifying the function calling convention for functions taking
! \&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary-compatible
  with code compiled without that switch.
! .IP "\fB\-malign\-data=\fR\fItype\fR" 4
  .IX Item "-malign-data=type"
! Control how \s-1GCC\s0 aligns variables.  Supported values for \fItype\fR are
! \&\fBcompat\fR uses increased alignment value compatible uses \s-1GCC 4.8\s0
  and earlier, \fBabi\fR uses alignment value as specified by the
  psABI, and \fBcacheline\fR uses increased alignment value to match
  the cache line size.  \fBcompat\fR is the default.
! .IP "\fB\-mlarge\-data\-threshold=\fR\fIthreshold\fR" 4
  .IX Item "-mlarge-data-threshold=threshold"
  When \fB\-mcmodel=medium\fR is specified, data objects larger than
  \&\fIthreshold\fR are placed in the large data section.  This value must be the
  same across all objects linked into the binary, and defaults to 65535.
! .IP "\fB\-mrtd\fR" 4
  .IX Item "-mrtd"
! Use a different function-calling convention, in which functions that
! take a fixed number of arguments return with the \f(CW\*(C`ret \f(CInum\f(CW\*(C'\fR
  instruction, which pops their arguments while returning.  This saves one
  instruction in the caller since there is no need to pop the arguments
  there.
--- 32089,32116 ----
  of 128 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the
  \&\f(CW\*(C`_\|_float128\*(C'\fR type. This is the default for 64\-bit Bionic C library.
  .Sp
! \&\fBWarning:\fR if you override the default value for your target ABI, this
  changes the size of
  structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
  as well as modifying the function calling convention for functions taking
! \&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary\-compatible
  with code compiled without that switch.
! .IP \fB\-malign\-data=\fR\fItype\fR 4
  .IX Item "-malign-data=type"
! Control how GCC aligns variables.  Supported values for \fItype\fR are
! \&\fBcompat\fR uses increased alignment value compatible uses GCC 4.8
  and earlier, \fBabi\fR uses alignment value as specified by the
  psABI, and \fBcacheline\fR uses increased alignment value to match
  the cache line size.  \fBcompat\fR is the default.
! .IP \fB\-mlarge\-data\-threshold=\fR\fIthreshold\fR 4
  .IX Item "-mlarge-data-threshold=threshold"
  When \fB\-mcmodel=medium\fR is specified, data objects larger than
  \&\fIthreshold\fR are placed in the large data section.  This value must be the
  same across all objects linked into the binary, and defaults to 65535.
! .IP \fB\-mrtd\fR 4
  .IX Item "-mrtd"
! Use a different function\-calling convention, in which functions that
! take a fixed number of arguments return with the \f(CW\*(C`ret \fR\f(CInum\fR\f(CW\*(C'\fR
  instruction, which pops their arguments while returning.  This saves one
  instruction in the caller since there is no need to pop the arguments
  there.
*************** functions.
*** 32201,32207 ****
  In addition, seriously incorrect code results if you call a
  function with too many arguments.  (Normally, extra arguments are
  harmlessly ignored.)
! .IP "\fB\-mregparm=\fR\fInum\fR" 4
  .IX Item "-mregparm=num"
  Control how many registers are used to pass integer arguments.  By
  default, no registers are used to pass arguments, and at most 3
--- 32132,32138 ----
  In addition, seriously incorrect code results if you call a
  function with too many arguments.  (Normally, extra arguments are
  harmlessly ignored.)
! .IP \fB\-mregparm=\fR\fInum\fR 4
  .IX Item "-mregparm=num"
  Control how many registers are used to pass integer arguments.  By
  default, no registers are used to pass arguments, and at most 3
*************** function by using the function attribute
*** 32212,32294 ****
  \&\fInum\fR is nonzero, then you must build all modules with the same
  value, including any libraries.  This includes the system libraries and
  startup modules.
! .IP "\fB\-msseregparm\fR" 4
  .IX Item "-msseregparm"
! Use \s-1SSE\s0 register passing conventions for float and double arguments
  and return values.  You can control this behavior for a specific
  function by using the function attribute \f(CW\*(C`sseregparm\*(C'\fR.
  .Sp
  \&\fBWarning:\fR if you use this switch then you must build all
  modules with the same value, including any libraries.  This includes
  the system libraries and startup modules.
! .IP "\fB\-mvect8\-ret\-in\-mem\fR" 4
  .IX Item "-mvect8-ret-in-mem"
! Return 8\-byte vectors in memory instead of \s-1MMX\s0 registers.  This is the
! default on VxWorks to match the \s-1ABI\s0 of the Sun Studio compilers until
  version 12.  \fIOnly\fR use this option if you need to remain
  compatible with existing code produced by those previous compiler
! versions or older versions of \s-1GCC.\s0
! .IP "\fB\-mpc32\fR" 4
  .IX Item "-mpc32"
  .PD 0
! .IP "\fB\-mpc64\fR" 4
  .IX Item "-mpc64"
! .IP "\fB\-mpc80\fR" 4
  .IX Item "-mpc80"
  .PD
! Set 80387 floating-point precision to 32, 64 or 80 bits.  When \fB\-mpc32\fR
! is specified, the significands of results of floating-point operations are
  rounded to 24 bits (single precision); \fB\-mpc64\fR rounds the
! significands of results of floating-point operations to 53 bits (double
  precision) and \fB\-mpc80\fR rounds the significands of results of
! floating-point operations to 64 bits (extended double precision), which is
! the default.  When this option is used, floating-point operations in higher
! precisions are not available to the programmer without setting the \s-1FPU\s0
  control word explicitly.
  .Sp
! Setting the rounding of floating-point operations to less than the default
  80 bits can speed some programs by 2% or more.  Note that some mathematical
! libraries assume that extended-precision (80\-bit) floating-point operations
  are enabled by default; routines in such libraries could suffer significant
! loss of accuracy, typically through so-called \*(L"catastrophic cancellation\*(R",
  when this option is used to set the precision to less than extended precision.
! .IP "\fB\-mdaz\-ftz\fR" 4
  .IX Item "-mdaz-ftz"
! The flush-to-zero (\s-1FTZ\s0) and denormals-are-zero (\s-1DAZ\s0) flags in the \s-1MXCSR\s0 register
! are used to control floating-point calculations.SSE and \s-1AVX\s0 instructions
! including scalar and vector instructions could benefit from enabling the \s-1FTZ\s0
! and \s-1DAZ\s0 flags when \fB\-mdaz\-ftz\fR is specified. Don't set \s-1FTZ/DAZ\s0 flags
  when \fB\-mno\-daz\-ftz\fR or \fB\-shared\fR is specified, \fB\-mdaz\-ftz\fR
! will set \s-1FTZ/DAZ\s0 flags even with \fB\-shared\fR.
! .IP "\fB\-mstackrealign\fR" 4
  .IX Item "-mstackrealign"
  Realign the stack at entry.  On the x86, the \fB\-mstackrealign\fR
  option generates an alternate prologue and epilogue that realigns the
! run-time stack if necessary.  This supports mixing legacy codes that keep
  4\-byte stack alignment with modern codes that keep 16\-byte stack alignment for
! \&\s-1SSE\s0 compatibility.  See also the attribute \f(CW\*(C`force_align_arg_pointer\*(C'\fR,
  applicable to individual functions.
! .IP "\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR" 4
  .IX Item "-mpreferred-stack-boundary=num"
  Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
  byte boundary.  If \fB\-mpreferred\-stack\-boundary\fR is not specified,
  the default is 4 (16 bytes or 128 bits).
  .Sp
  \&\fBWarning:\fR When generating code for the x86\-64 architecture with
! \&\s-1SSE\s0 extensions disabled, \fB\-mpreferred\-stack\-boundary=3\fR can be
  used to keep the stack boundary aligned to 8 byte boundary.  Since
! x86\-64 \s-1ABI\s0 require 16 byte stack alignment, this is \s-1ABI\s0 incompatible and
  intended to be used in controlled environment where stack space is
  important limitation.  This option leads to wrong code when functions
  compiled with 16 byte stack alignment (such as functions from a standard
! library) are called with misaligned stack.  In this case, \s-1SSE\s0
  instructions may lead to misaligned memory access traps.  In addition,
  variable arguments are handled incorrectly for 16 byte aligned
  objects (including x87 long double and _\|_int128), leading to wrong
  results.  You must build all modules with
  \&\fB\-mpreferred\-stack\-boundary=3\fR, including any libraries.  This
  includes the system libraries and startup modules.
! .IP "\fB\-mincoming\-stack\-boundary=\fR\fInum\fR" 4
  .IX Item "-mincoming-stack-boundary=num"
  Assume the incoming stack is aligned to a 2 raised to \fInum\fR byte
  boundary.  If \fB\-mincoming\-stack\-boundary\fR is not specified,
--- 32143,32225 ----
  \&\fInum\fR is nonzero, then you must build all modules with the same
  value, including any libraries.  This includes the system libraries and
  startup modules.
! .IP \fB\-msseregparm\fR 4
  .IX Item "-msseregparm"
! Use 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 \f(CW\*(C`sseregparm\*(C'\fR.
  .Sp
  \&\fBWarning:\fR if you use this switch then you must build all
  modules with the same value, including any libraries.  This includes
  the system libraries and startup modules.
! .IP \fB\-mvect8\-ret\-in\-mem\fR 4
  .IX Item "-mvect8-ret-in-mem"
! Return 8\-byte vectors in memory instead of MMX registers.  This is the
! default on VxWorks to match the ABI of the Sun Studio compilers until
  version 12.  \fIOnly\fR use this option if you need to remain
  compatible with existing code produced by those previous compiler
! versions or older versions of GCC.
! .IP \fB\-mpc32\fR 4
  .IX Item "-mpc32"
  .PD 0
! .IP \fB\-mpc64\fR 4
  .IX Item "-mpc64"
! .IP \fB\-mpc80\fR 4
  .IX Item "-mpc80"
  .PD
! Set 80387 floating\-point precision to 32, 64 or 80 bits.  When \fB\-mpc32\fR
! is specified, the significands of results of floating\-point operations are
  rounded to 24 bits (single precision); \fB\-mpc64\fR rounds the
! significands of results of floating\-point operations to 53 bits (double
  precision) and \fB\-mpc80\fR rounds the significands of results of
! floating\-point operations to 64 bits (extended double precision), which is
! the default.  When this option is used, floating\-point operations in higher
! precisions are not available to the programmer without setting the FPU
  control word explicitly.
  .Sp
! Setting the rounding of floating\-point operations to less than the default
  80 bits can speed some programs by 2% or more.  Note that some mathematical
! libraries assume that extended\-precision (80\-bit) floating\-point operations
  are enabled by default; routines in such libraries could suffer significant
! loss of accuracy, typically through so\-called "catastrophic cancellation",
  when this option is used to set the precision to less than extended precision.
! .IP \fB\-mdaz\-ftz\fR 4
  .IX Item "-mdaz-ftz"
! The flush\-to\-zero (FTZ) and denormals\-are\-zero (DAZ) flags in the MXCSR register
! are used to control floating\-point calculations.SSE and AVX instructions
! including scalar and vector instructions could benefit from enabling the FTZ
! and DAZ flags when \fB\-mdaz\-ftz\fR is specified. Don\*(Aqt set FTZ/DAZ flags
  when \fB\-mno\-daz\-ftz\fR or \fB\-shared\fR is specified, \fB\-mdaz\-ftz\fR
! will set FTZ/DAZ flags even with \fB\-shared\fR.
! .IP \fB\-mstackrealign\fR 4
  .IX Item "-mstackrealign"
  Realign the stack at entry.  On the x86, the \fB\-mstackrealign\fR
  option generates an alternate prologue and epilogue that realigns the
! run\-time stack if necessary.  This supports mixing legacy codes that keep
  4\-byte stack alignment with modern codes that keep 16\-byte stack alignment for
! SSE compatibility.  See also the attribute \f(CW\*(C`force_align_arg_pointer\*(C'\fR,
  applicable to individual functions.
! .IP \fB\-mpreferred\-stack\-boundary=\fR\fInum\fR 4
  .IX Item "-mpreferred-stack-boundary=num"
  Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
  byte boundary.  If \fB\-mpreferred\-stack\-boundary\fR is not specified,
  the default is 4 (16 bytes or 128 bits).
  .Sp
  \&\fBWarning:\fR When generating code for the x86\-64 architecture with
! SSE extensions disabled, \fB\-mpreferred\-stack\-boundary=3\fR can be
  used to keep the stack boundary aligned to 8 byte boundary.  Since
! x86\-64 ABI require 16 byte stack alignment, this is ABI incompatible and
  intended to be used in controlled environment where stack space is
  important limitation.  This option leads to wrong code when functions
  compiled with 16 byte stack alignment (such as functions from a standard
! library) are called with misaligned stack.  In this case, SSE
  instructions may lead to misaligned memory access traps.  In addition,
  variable arguments are handled incorrectly for 16 byte aligned
  objects (including x87 long double and _\|_int128), leading to wrong
  results.  You must build all modules with
  \&\fB\-mpreferred\-stack\-boundary=3\fR, including any libraries.  This
  includes the system libraries and startup modules.
! .IP \fB\-mincoming\-stack\-boundary=\fR\fInum\fR 4
  .IX Item "-mincoming-stack-boundary=num"
  Assume the incoming stack is aligned to a 2 raised to \fInum\fR byte
  boundary.  If \fB\-mincoming\-stack\-boundary\fR is not specified,
*************** the one specified by \fB\-mpreferred\-st
*** 32296,32303 ****
  .Sp
  On Pentium and Pentium Pro, \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long double\*(C'\fR values
  should be aligned to an 8\-byte boundary (see \fB\-malign\-double\fR) or
! suffer significant run time performance penalties.  On Pentium \s-1III,\s0 the
! Streaming \s-1SIMD\s0 Extension (\s-1SSE\s0) data type \f(CW\*(C`_\|_m128\*(C'\fR may not work
  properly if it is not 16\-byte aligned.
  .Sp
  To ensure proper alignment of this values on the stack, the stack boundary
--- 32227,32234 ----
  .Sp
  On Pentium and Pentium Pro, \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long double\*(C'\fR values
  should be aligned to an 8\-byte boundary (see \fB\-malign\-double\fR) or
! suffer significant run time performance penalties.  On Pentium III, the
! Streaming SIMD Extension (SSE) data type \f(CW\*(C`_\|_m128\*(C'\fR may not work
  properly if it is not 16\-byte aligned.
  .Sp
  To ensure proper alignment of this values on the stack, the stack boundary
*************** This extra alignment does consume extra
*** 32312,32693 ****
  increases code size.  Code that is sensitive to stack space usage, such
  as embedded systems and operating system kernels, may want to reduce the
  preferred alignment to \fB\-mpreferred\-stack\-boundary=2\fR.
! .IP "\fB\-mmmx\fR" 4
  .IX Item "-mmmx"
  .PD 0
! .IP "\fB\-msse\fR" 4
  .IX Item "-msse"
! .IP "\fB\-msse2\fR" 4
  .IX Item "-msse2"
! .IP "\fB\-msse3\fR" 4
  .IX Item "-msse3"
! .IP "\fB\-mssse3\fR" 4
  .IX Item "-mssse3"
! .IP "\fB\-msse4\fR" 4
  .IX Item "-msse4"
! .IP "\fB\-msse4a\fR" 4
  .IX Item "-msse4a"
! .IP "\fB\-msse4.1\fR" 4
  .IX Item "-msse4.1"
! .IP "\fB\-msse4.2\fR" 4
  .IX Item "-msse4.2"
! .IP "\fB\-mavx\fR" 4
  .IX Item "-mavx"
! .IP "\fB\-mavx2\fR" 4
  .IX Item "-mavx2"
! .IP "\fB\-mavx512f\fR" 4
  .IX Item "-mavx512f"
! .IP "\fB\-mavx512pf\fR" 4
  .IX Item "-mavx512pf"
! .IP "\fB\-mavx512er\fR" 4
  .IX Item "-mavx512er"
! .IP "\fB\-mavx512cd\fR" 4
  .IX Item "-mavx512cd"
! .IP "\fB\-mavx512vl\fR" 4
  .IX Item "-mavx512vl"
! .IP "\fB\-mavx512bw\fR" 4
  .IX Item "-mavx512bw"
! .IP "\fB\-mavx512dq\fR" 4
  .IX Item "-mavx512dq"
! .IP "\fB\-mavx512ifma\fR" 4
  .IX Item "-mavx512ifma"
! .IP "\fB\-mavx512vbmi\fR" 4
  .IX Item "-mavx512vbmi"
! .IP "\fB\-msha\fR" 4
  .IX Item "-msha"
! .IP "\fB\-maes\fR" 4
  .IX Item "-maes"
! .IP "\fB\-mpclmul\fR" 4
  .IX Item "-mpclmul"
! .IP "\fB\-mclflushopt\fR" 4
  .IX Item "-mclflushopt"
! .IP "\fB\-mclwb\fR" 4
  .IX Item "-mclwb"
! .IP "\fB\-mfsgsbase\fR" 4
  .IX Item "-mfsgsbase"
! .IP "\fB\-mptwrite\fR" 4
  .IX Item "-mptwrite"
! .IP "\fB\-mrdrnd\fR" 4
  .IX Item "-mrdrnd"
! .IP "\fB\-mf16c\fR" 4
  .IX Item "-mf16c"
! .IP "\fB\-mfma\fR" 4
  .IX Item "-mfma"
! .IP "\fB\-mpconfig\fR" 4
  .IX Item "-mpconfig"
! .IP "\fB\-mwbnoinvd\fR" 4
  .IX Item "-mwbnoinvd"
! .IP "\fB\-mfma4\fR" 4
  .IX Item "-mfma4"
! .IP "\fB\-mprfchw\fR" 4
  .IX Item "-mprfchw"
! .IP "\fB\-mrdpid\fR" 4
  .IX Item "-mrdpid"
! .IP "\fB\-mprefetchwt1\fR" 4
  .IX Item "-mprefetchwt1"
! .IP "\fB\-mrdseed\fR" 4
  .IX Item "-mrdseed"
! .IP "\fB\-msgx\fR" 4
  .IX Item "-msgx"
! .IP "\fB\-mxop\fR" 4
  .IX Item "-mxop"
! .IP "\fB\-mlwp\fR" 4
  .IX Item "-mlwp"
! .IP "\fB\-m3dnow\fR" 4
  .IX Item "-m3dnow"
! .IP "\fB\-m3dnowa\fR" 4
  .IX Item "-m3dnowa"
! .IP "\fB\-mpopcnt\fR" 4
  .IX Item "-mpopcnt"
! .IP "\fB\-mabm\fR" 4
  .IX Item "-mabm"
! .IP "\fB\-madx\fR" 4
  .IX Item "-madx"
! .IP "\fB\-mbmi\fR" 4
  .IX Item "-mbmi"
! .IP "\fB\-mbmi2\fR" 4
  .IX Item "-mbmi2"
! .IP "\fB\-mlzcnt\fR" 4
  .IX Item "-mlzcnt"
! .IP "\fB\-mfxsr\fR" 4
  .IX Item "-mfxsr"
! .IP "\fB\-mxsave\fR" 4
  .IX Item "-mxsave"
! .IP "\fB\-mxsaveopt\fR" 4
  .IX Item "-mxsaveopt"
! .IP "\fB\-mxsavec\fR" 4
  .IX Item "-mxsavec"
! .IP "\fB\-mxsaves\fR" 4
  .IX Item "-mxsaves"
! .IP "\fB\-mrtm\fR" 4
  .IX Item "-mrtm"
! .IP "\fB\-mhle\fR" 4
  .IX Item "-mhle"
! .IP "\fB\-mtbm\fR" 4
  .IX Item "-mtbm"
! .IP "\fB\-mmwaitx\fR" 4
  .IX Item "-mmwaitx"
! .IP "\fB\-mclzero\fR" 4
  .IX Item "-mclzero"
! .IP "\fB\-mpku\fR" 4
  .IX Item "-mpku"
! .IP "\fB\-mavx512vbmi2\fR" 4
  .IX Item "-mavx512vbmi2"
! .IP "\fB\-mavx512bf16\fR" 4
  .IX Item "-mavx512bf16"
! .IP "\fB\-mavx512fp16\fR" 4
  .IX Item "-mavx512fp16"
! .IP "\fB\-mgfni\fR" 4
  .IX Item "-mgfni"
! .IP "\fB\-mvaes\fR" 4
  .IX Item "-mvaes"
! .IP "\fB\-mwaitpkg\fR" 4
  .IX Item "-mwaitpkg"
! .IP "\fB\-mvpclmulqdq\fR" 4
  .IX Item "-mvpclmulqdq"
! .IP "\fB\-mavx512bitalg\fR" 4
  .IX Item "-mavx512bitalg"
! .IP "\fB\-mmovdiri\fR" 4
  .IX Item "-mmovdiri"
! .IP "\fB\-mmovdir64b\fR" 4
  .IX Item "-mmovdir64b"
! .IP "\fB\-menqcmd\fR" 4
  .IX Item "-menqcmd"
! .IP "\fB\-muintr\fR" 4
  .IX Item "-muintr"
! .IP "\fB\-mtsxldtrk\fR" 4
  .IX Item "-mtsxldtrk"
! .IP "\fB\-mavx512vpopcntdq\fR" 4
  .IX Item "-mavx512vpopcntdq"
! .IP "\fB\-mavx512vp2intersect\fR" 4
  .IX Item "-mavx512vp2intersect"
! .IP "\fB\-mavx5124fmaps\fR" 4
  .IX Item "-mavx5124fmaps"
! .IP "\fB\-mavx512vnni\fR" 4
  .IX Item "-mavx512vnni"
! .IP "\fB\-mavxvnni\fR" 4
  .IX Item "-mavxvnni"
! .IP "\fB\-mavx5124vnniw\fR" 4
  .IX Item "-mavx5124vnniw"
! .IP "\fB\-mcldemote\fR" 4
  .IX Item "-mcldemote"
! .IP "\fB\-mserialize\fR" 4
  .IX Item "-mserialize"
! .IP "\fB\-mamx\-tile\fR" 4
  .IX Item "-mamx-tile"
! .IP "\fB\-mamx\-int8\fR" 4
  .IX Item "-mamx-int8"
! .IP "\fB\-mamx\-bf16\fR" 4
  .IX Item "-mamx-bf16"
! .IP "\fB\-mhreset\fR" 4
  .IX Item "-mhreset"
! .IP "\fB\-mkl\fR" 4
  .IX Item "-mkl"
! .IP "\fB\-mwidekl\fR" 4
  .IX Item "-mwidekl"
! .IP "\fB\-mavxifma\fR" 4
  .IX Item "-mavxifma"
! .IP "\fB\-mavxvnniint8\fR" 4
  .IX Item "-mavxvnniint8"
! .IP "\fB\-mavxneconvert\fR" 4
  .IX Item "-mavxneconvert"
! .IP "\fB\-mcmpccxadd\fR" 4
  .IX Item "-mcmpccxadd"
! .IP "\fB\-mamx\-fp16\fR" 4
  .IX Item "-mamx-fp16"
! .IP "\fB\-mprefetchi\fR" 4
  .IX Item "-mprefetchi"
! .IP "\fB\-mraoint\fR" 4
  .IX Item "-mraoint"
! .IP "\fB\-mamx\-complex\fR" 4
  .IX Item "-mamx-complex"
  .PD
! These switches enable the use of instructions in the \s-1MMX, SSE,
  SSE2, SSE3, SSSE3, SSE4, SSE4A, SSE4.1, SSE4.2, AVX, AVX2, AVX512F, AVX512PF,
  AVX512ER, AVX512CD, AVX512VL, AVX512BW, AVX512DQ, AVX512IFMA, AVX512VBMI, SHA,
  AES, PCLMUL, CLFLUSHOPT, CLWB, FSGSBASE, PTWRITE, RDRND, F16C, FMA, PCONFIG,
! WBNOINVD, FMA4, PREFETCHW, RDPID, PREFETCHWT1, RDSEED, SGX, XOP, LWP,\s0
! 3DNow!, enhanced 3DNow!, \s-1POPCNT, ABM, ADX, BMI, BMI2, LZCNT, FXSR, XSAVE,
  XSAVEOPT, XSAVEC, XSAVES, RTM, HLE, TBM, MWAITX, CLZERO, PKU, AVX512VBMI2,
  GFNI, VAES, WAITPKG, VPCLMULQDQ, AVX512BITALG, MOVDIRI, MOVDIR64B, AVX512BF16,
  ENQCMD, AVX512VPOPCNTDQ, AVX5124FMAPS, AVX512VNNI, AVX5124VNNIW, SERIALIZE,
  UINTR, HRESET, AMXTILE, AMXINT8, AMXBF16, KL, WIDEKL, AVXVNNI, AVX512\-FP16,
! AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AMX\-FP16, PREFETCHI, RAOINT,\s0
! AMX-COMPLEX or \s-1CLDEMOTE\s0 extended instruction sets. Each has a corresponding
  \&\fB\-mno\-\fR option to disable use of these instructions.
  .Sp
! These extensions are also available as built-in functions: see
! \&\fBx86 Built-in Functions\fR, for details of the functions enabled and
  disabled by these switches.
  .Sp
! To generate \s-1SSE/SSE2\s0 instructions automatically from floating-point
  code (as opposed to 387 instructions), see \fB\-mfpmath=sse\fR.
  .Sp
! \&\s-1GCC\s0 depresses SSEx instructions when \fB\-mavx\fR is used. Instead, it
! generates new \s-1AVX\s0 instructions or \s-1AVX\s0 equivalence for all SSEx instructions
  when needed.
  .Sp
! These options enable \s-1GCC\s0 to use these extended instructions in
  generated code, even without \fB\-mfpmath=sse\fR.  Applications that
! perform run-time \s-1CPU\s0 detection must compile separate files for each
  supported architecture, using the appropriate flags.  In particular,
! the file containing the \s-1CPU\s0 detection code should be compiled without
  these options.
! .IP "\fB\-mdump\-tune\-features\fR" 4
  .IX Item "-mdump-tune-features"
! This option instructs \s-1GCC\s0 to dump the names of the x86 performance 
  tuning features and default settings. The names can be used in 
! \&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR.
! .IP "\fB\-mtune\-ctrl=\fR\fIfeature-list\fR" 4
  .IX Item "-mtune-ctrl=feature-list"
  This option is used to do fine grain control of x86 code generation features.
! \&\fIfeature-list\fR is a comma separated list of \fIfeature\fR names. See also
  \&\fB\-mdump\-tune\-features\fR. When specified, the \fIfeature\fR is turned
  on if it is not preceded with \fB^\fR, otherwise, it is turned off. 
! \&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR is intended to be used by \s-1GCC\s0
  developers. Using it may lead to code paths not covered by testing and can
  potentially result in compiler ICEs or runtime errors.
! .IP "\fB\-mno\-default\fR" 4
  .IX Item "-mno-default"
! This option instructs \s-1GCC\s0 to turn off all tunable features. See also 
! \&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR and \fB\-mdump\-tune\-features\fR.
! .IP "\fB\-mcld\fR" 4
  .IX Item "-mcld"
! This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`cld\*(C'\fR instruction in the prologue
  of functions that use string instructions.  String instructions depend on
! the \s-1DF\s0 flag to select between autoincrement or autodecrement mode.  While the
! \&\s-1ABI\s0 specifies the \s-1DF\s0 flag to be cleared on function entry, some operating
! systems violate this specification by not clearing the \s-1DF\s0 flag in their
! exception dispatchers.  The exception handler can be invoked with the \s-1DF\s0 flag
  set, which leads to wrong direction mode when string instructions are used.
  This option can be enabled by default on 32\-bit x86 targets by configuring
! \&\s-1GCC\s0 with the \fB\-\-enable\-cld\fR configure option.  Generation of \f(CW\*(C`cld\*(C'\fR
  instructions can be suppressed with the \fB\-mno\-cld\fR compiler option
  in this case.
! .IP "\fB\-mvzeroupper\fR" 4
  .IX Item "-mvzeroupper"
! This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`vzeroupper\*(C'\fR instruction
  before a transfer of control flow out of the function to minimize
! the \s-1AVX\s0 to \s-1SSE\s0 transition penalty as well as remove unnecessary \f(CW\*(C`zeroupper\*(C'\fR
  intrinsics.
! .IP "\fB\-mprefer\-avx128\fR" 4
  .IX Item "-mprefer-avx128"
! This option instructs \s-1GCC\s0 to use 128\-bit \s-1AVX\s0 instructions instead of
! 256\-bit \s-1AVX\s0 instructions in the auto-vectorizer.
! .IP "\fB\-mprefer\-vector\-width=\fR\fIopt\fR" 4
  .IX Item "-mprefer-vector-width=opt"
! This option instructs \s-1GCC\s0 to use \fIopt\fR\-bit vector width in instructions
  instead of default on the selected platform.
! .IP "\fB\-mmove\-max=\fR\fIbits\fR" 4
  .IX Item "-mmove-max=bits"
! This option instructs \s-1GCC\s0 to set the maximum number of bits can be
  moved from memory to memory efficiently to \fIbits\fR.  The valid
  \&\fIbits\fR are 128, 256 and 512.
! .IP "\fB\-mstore\-max=\fR\fIbits\fR" 4
  .IX Item "-mstore-max=bits"
! This option instructs \s-1GCC\s0 to set the maximum number of bits can be
  stored to memory efficiently to \fIbits\fR.  The valid \fIbits\fR are
  128, 256 and 512.
  .RS 4
! .IP "\fBnone\fR" 4
  .IX Item "none"
! No extra limitations applied to \s-1GCC\s0 other than defined by the selected platform.
! .IP "\fB128\fR" 4
  .IX Item "128"
  Prefer 128\-bit vector width for instructions.
! .IP "\fB256\fR" 4
  .IX Item "256"
  Prefer 256\-bit vector width for instructions.
! .IP "\fB512\fR" 4
  .IX Item "512"
  Prefer 512\-bit vector width for instructions.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mcx16\fR" 4
  .IX Item "-mcx16"
! This option enables \s-1GCC\s0 to generate \f(CW\*(C`CMPXCHG16B\*(C'\fR instructions in 64\-bit
! code to implement compare-and-exchange operations on 16\-byte aligned 128\-bit
  objects.  This is useful for atomic updates of data structures exceeding one
  machine word in size.  The compiler uses this instruction to implement
  \&\fB_\|_sync Builtins\fR.  However, for \fB_\|_atomic Builtins\fR operating on
  128\-bit integers, a library call is always used.
! .IP "\fB\-msahf\fR" 4
  .IX Item "-msahf"
  This option enables generation of \f(CW\*(C`SAHF\*(C'\fR instructions in 64\-bit code.
  Early Intel Pentium 4 CPUs with Intel 64 support,
  prior to the introduction of Pentium 4 G1 step in December 2005,
  lacked the \f(CW\*(C`LAHF\*(C'\fR and \f(CW\*(C`SAHF\*(C'\fR instructions
! which are supported by \s-1AMD64.\s0
  These are load and store instructions, respectively, for certain status flags.
  In 64\-bit mode, the \f(CW\*(C`SAHF\*(C'\fR instruction is used to optimize \f(CW\*(C`fmod\*(C'\fR,
! \&\f(CW\*(C`drem\*(C'\fR, and \f(CW\*(C`remainder\*(C'\fR built-in functions;
  see \fBOther Builtins\fR for details.
! .IP "\fB\-mmovbe\fR" 4
  .IX Item "-mmovbe"
  This option enables use of the \f(CW\*(C`movbe\*(C'\fR instruction to implement
  \&\f(CW\*(C`_\|_builtin_bswap32\*(C'\fR and \f(CW\*(C`_\|_builtin_bswap64\*(C'\fR.
! .IP "\fB\-mshstk\fR" 4
  .IX Item "-mshstk"
! The \fB\-mshstk\fR option enables shadow stack built-in functions
! from x86 Control-flow Enforcement Technology (\s-1CET\s0).
! .IP "\fB\-mcrc32\fR" 4
  .IX Item "-mcrc32"
! This option enables built-in functions \f(CW\*(C`_\|_builtin_ia32_crc32qi\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_ia32_crc32hi\*(C'\fR, \f(CW\*(C`_\|_builtin_ia32_crc32si\*(C'\fR and
  \&\f(CW\*(C`_\|_builtin_ia32_crc32di\*(C'\fR to generate the \f(CW\*(C`crc32\*(C'\fR machine instruction.
! .IP "\fB\-mmwait\fR" 4
  .IX Item "-mmwait"
! This option enables built-in functions \f(CW\*(C`_\|_builtin_ia32_monitor\*(C'\fR,
  and \f(CW\*(C`_\|_builtin_ia32_mwait\*(C'\fR to generate the \f(CW\*(C`monitor\*(C'\fR and
  \&\f(CW\*(C`mwait\*(C'\fR machine instructions.
! .IP "\fB\-mrecip\fR" 4
  .IX Item "-mrecip"
  This option enables use of \f(CW\*(C`RCPSS\*(C'\fR and \f(CW\*(C`RSQRTSS\*(C'\fR instructions
  (and their vectorized variants \f(CW\*(C`RCPPS\*(C'\fR and \f(CW\*(C`RSQRTPS\*(C'\fR)
! with an additional Newton-Raphson step
  to increase precision instead of \f(CW\*(C`DIVSS\*(C'\fR and \f(CW\*(C`SQRTSS\*(C'\fR
  (and their vectorized
! variants) for single-precision floating-point arguments.  These instructions
  are generated only when \fB\-funsafe\-math\-optimizations\fR is enabled
  together with \fB\-ffinite\-math\-only\fR and \fB\-fno\-trapping\-math\fR.
  Note that while the throughput of the sequence is higher than the throughput
! of the non-reciprocal instruction, the precision of the sequence can be
  decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.99999994).
  .Sp
! Note that \s-1GCC\s0 implements \f(CW\*(C`1.0f/sqrtf(\f(CIx\f(CW)\*(C'\fR in terms of \f(CW\*(C`RSQRTSS\*(C'\fR
  (or \f(CW\*(C`RSQRTPS\*(C'\fR) already with \fB\-ffast\-math\fR (or the above option
! combination), and doesn't need \fB\-mrecip\fR.
  .Sp
! Also note that \s-1GCC\s0 emits the above sequence with additional Newton-Raphson step
! for vectorized single-float division and vectorized \f(CW\*(C`sqrtf(\f(CIx\f(CW)\*(C'\fR
  already with \fB\-ffast\-math\fR (or the above option combination), and
! doesn't need \fB\-mrecip\fR.
! .IP "\fB\-mrecip=\fR\fIopt\fR" 4
  .IX Item "-mrecip=opt"
  This option controls which reciprocal estimate instructions
! may be used.  \fIopt\fR is a comma-separated list of options, which may
  be preceded by a \fB!\fR to invert the option:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
  Enable all estimate instructions.
! .IP "\fBdefault\fR" 4
  .IX Item "default"
  Enable the default instructions, equivalent to \fB\-mrecip\fR.
! .IP "\fBnone\fR" 4
  .IX Item "none"
  Disable all estimate instructions, equivalent to \fB\-mno\-recip\fR.
! .IP "\fBdiv\fR" 4
  .IX Item "div"
  Enable the approximation for scalar division.
! .IP "\fBvec-div\fR" 4
  .IX Item "vec-div"
  Enable the approximation for vectorized division.
! .IP "\fBsqrt\fR" 4
  .IX Item "sqrt"
  Enable the approximation for scalar square root.
! .IP "\fBvec-sqrt\fR" 4
  .IX Item "vec-sqrt"
  Enable the approximation for vectorized square root.
  .RE
--- 32243,32624 ----
  increases code size.  Code that is sensitive to stack space usage, such
  as embedded systems and operating system kernels, may want to reduce the
  preferred alignment to \fB\-mpreferred\-stack\-boundary=2\fR.
! .IP \fB\-mmmx\fR 4
  .IX Item "-mmmx"
  .PD 0
! .IP \fB\-msse\fR 4
  .IX Item "-msse"
! .IP \fB\-msse2\fR 4
  .IX Item "-msse2"
! .IP \fB\-msse3\fR 4
  .IX Item "-msse3"
! .IP \fB\-mssse3\fR 4
  .IX Item "-mssse3"
! .IP \fB\-msse4\fR 4
  .IX Item "-msse4"
! .IP \fB\-msse4a\fR 4
  .IX Item "-msse4a"
! .IP \fB\-msse4.1\fR 4
  .IX Item "-msse4.1"
! .IP \fB\-msse4.2\fR 4
  .IX Item "-msse4.2"
! .IP \fB\-mavx\fR 4
  .IX Item "-mavx"
! .IP \fB\-mavx2\fR 4
  .IX Item "-mavx2"
! .IP \fB\-mavx512f\fR 4
  .IX Item "-mavx512f"
! .IP \fB\-mavx512pf\fR 4
  .IX Item "-mavx512pf"
! .IP \fB\-mavx512er\fR 4
  .IX Item "-mavx512er"
! .IP \fB\-mavx512cd\fR 4
  .IX Item "-mavx512cd"
! .IP \fB\-mavx512vl\fR 4
  .IX Item "-mavx512vl"
! .IP \fB\-mavx512bw\fR 4
  .IX Item "-mavx512bw"
! .IP \fB\-mavx512dq\fR 4
  .IX Item "-mavx512dq"
! .IP \fB\-mavx512ifma\fR 4
  .IX Item "-mavx512ifma"
! .IP \fB\-mavx512vbmi\fR 4
  .IX Item "-mavx512vbmi"
! .IP \fB\-msha\fR 4
  .IX Item "-msha"
! .IP \fB\-maes\fR 4
  .IX Item "-maes"
! .IP \fB\-mpclmul\fR 4
  .IX Item "-mpclmul"
! .IP \fB\-mclflushopt\fR 4
  .IX Item "-mclflushopt"
! .IP \fB\-mclwb\fR 4
  .IX Item "-mclwb"
! .IP \fB\-mfsgsbase\fR 4
  .IX Item "-mfsgsbase"
! .IP \fB\-mptwrite\fR 4
  .IX Item "-mptwrite"
! .IP \fB\-mrdrnd\fR 4
  .IX Item "-mrdrnd"
! .IP \fB\-mf16c\fR 4
  .IX Item "-mf16c"
! .IP \fB\-mfma\fR 4
  .IX Item "-mfma"
! .IP \fB\-mpconfig\fR 4
  .IX Item "-mpconfig"
! .IP \fB\-mwbnoinvd\fR 4
  .IX Item "-mwbnoinvd"
! .IP \fB\-mfma4\fR 4
  .IX Item "-mfma4"
! .IP \fB\-mprfchw\fR 4
  .IX Item "-mprfchw"
! .IP \fB\-mrdpid\fR 4
  .IX Item "-mrdpid"
! .IP \fB\-mprefetchwt1\fR 4
  .IX Item "-mprefetchwt1"
! .IP \fB\-mrdseed\fR 4
  .IX Item "-mrdseed"
! .IP \fB\-msgx\fR 4
  .IX Item "-msgx"
! .IP \fB\-mxop\fR 4
  .IX Item "-mxop"
! .IP \fB\-mlwp\fR 4
  .IX Item "-mlwp"
! .IP \fB\-m3dnow\fR 4
  .IX Item "-m3dnow"
! .IP \fB\-m3dnowa\fR 4
  .IX Item "-m3dnowa"
! .IP \fB\-mpopcnt\fR 4
  .IX Item "-mpopcnt"
! .IP \fB\-mabm\fR 4
  .IX Item "-mabm"
! .IP \fB\-madx\fR 4
  .IX Item "-madx"
! .IP \fB\-mbmi\fR 4
  .IX Item "-mbmi"
! .IP \fB\-mbmi2\fR 4
  .IX Item "-mbmi2"
! .IP \fB\-mlzcnt\fR 4
  .IX Item "-mlzcnt"
! .IP \fB\-mfxsr\fR 4
  .IX Item "-mfxsr"
! .IP \fB\-mxsave\fR 4
  .IX Item "-mxsave"
! .IP \fB\-mxsaveopt\fR 4
  .IX Item "-mxsaveopt"
! .IP \fB\-mxsavec\fR 4
  .IX Item "-mxsavec"
! .IP \fB\-mxsaves\fR 4
  .IX Item "-mxsaves"
! .IP \fB\-mrtm\fR 4
  .IX Item "-mrtm"
! .IP \fB\-mhle\fR 4
  .IX Item "-mhle"
! .IP \fB\-mtbm\fR 4
  .IX Item "-mtbm"
! .IP \fB\-mmwaitx\fR 4
  .IX Item "-mmwaitx"
! .IP \fB\-mclzero\fR 4
  .IX Item "-mclzero"
! .IP \fB\-mpku\fR 4
  .IX Item "-mpku"
! .IP \fB\-mavx512vbmi2\fR 4
  .IX Item "-mavx512vbmi2"
! .IP \fB\-mavx512bf16\fR 4
  .IX Item "-mavx512bf16"
! .IP \fB\-mavx512fp16\fR 4
  .IX Item "-mavx512fp16"
! .IP \fB\-mgfni\fR 4
  .IX Item "-mgfni"
! .IP \fB\-mvaes\fR 4
  .IX Item "-mvaes"
! .IP \fB\-mwaitpkg\fR 4
  .IX Item "-mwaitpkg"
! .IP \fB\-mvpclmulqdq\fR 4
  .IX Item "-mvpclmulqdq"
! .IP \fB\-mavx512bitalg\fR 4
  .IX Item "-mavx512bitalg"
! .IP \fB\-mmovdiri\fR 4
  .IX Item "-mmovdiri"
! .IP \fB\-mmovdir64b\fR 4
  .IX Item "-mmovdir64b"
! .IP \fB\-menqcmd\fR 4
  .IX Item "-menqcmd"
! .IP \fB\-muintr\fR 4
  .IX Item "-muintr"
! .IP \fB\-mtsxldtrk\fR 4
  .IX Item "-mtsxldtrk"
! .IP \fB\-mavx512vpopcntdq\fR 4
  .IX Item "-mavx512vpopcntdq"
! .IP \fB\-mavx512vp2intersect\fR 4
  .IX Item "-mavx512vp2intersect"
! .IP \fB\-mavx5124fmaps\fR 4
  .IX Item "-mavx5124fmaps"
! .IP \fB\-mavx512vnni\fR 4
  .IX Item "-mavx512vnni"
! .IP \fB\-mavxvnni\fR 4
  .IX Item "-mavxvnni"
! .IP \fB\-mavx5124vnniw\fR 4
  .IX Item "-mavx5124vnniw"
! .IP \fB\-mcldemote\fR 4
  .IX Item "-mcldemote"
! .IP \fB\-mserialize\fR 4
  .IX Item "-mserialize"
! .IP \fB\-mamx\-tile\fR 4
  .IX Item "-mamx-tile"
! .IP \fB\-mamx\-int8\fR 4
  .IX Item "-mamx-int8"
! .IP \fB\-mamx\-bf16\fR 4
  .IX Item "-mamx-bf16"
! .IP \fB\-mhreset\fR 4
  .IX Item "-mhreset"
! .IP \fB\-mkl\fR 4
  .IX Item "-mkl"
! .IP \fB\-mwidekl\fR 4
  .IX Item "-mwidekl"
! .IP \fB\-mavxifma\fR 4
  .IX Item "-mavxifma"
! .IP \fB\-mavxvnniint8\fR 4
  .IX Item "-mavxvnniint8"
! .IP \fB\-mavxneconvert\fR 4
  .IX Item "-mavxneconvert"
! .IP \fB\-mcmpccxadd\fR 4
  .IX Item "-mcmpccxadd"
! .IP \fB\-mamx\-fp16\fR 4
  .IX Item "-mamx-fp16"
! .IP \fB\-mprefetchi\fR 4
  .IX Item "-mprefetchi"
! .IP \fB\-mraoint\fR 4
  .IX Item "-mraoint"
! .IP \fB\-mamx\-complex\fR 4
  .IX Item "-mamx-complex"
  .PD
! These switches enable the use of instructions in the MMX, SSE,
  SSE2, SSE3, SSSE3, SSE4, SSE4A, SSE4.1, SSE4.2, AVX, AVX2, AVX512F, AVX512PF,
  AVX512ER, AVX512CD, AVX512VL, AVX512BW, AVX512DQ, AVX512IFMA, AVX512VBMI, SHA,
  AES, PCLMUL, CLFLUSHOPT, CLWB, FSGSBASE, PTWRITE, RDRND, F16C, FMA, PCONFIG,
! WBNOINVD, FMA4, PREFETCHW, RDPID, PREFETCHWT1, RDSEED, SGX, XOP, LWP,
! 3DNow!, enhanced 3DNow!, POPCNT, ABM, ADX, BMI, BMI2, LZCNT, FXSR, XSAVE,
  XSAVEOPT, XSAVEC, XSAVES, RTM, HLE, TBM, MWAITX, CLZERO, PKU, AVX512VBMI2,
  GFNI, VAES, WAITPKG, VPCLMULQDQ, AVX512BITALG, MOVDIRI, MOVDIR64B, AVX512BF16,
  ENQCMD, AVX512VPOPCNTDQ, AVX5124FMAPS, AVX512VNNI, AVX5124VNNIW, SERIALIZE,
  UINTR, HRESET, AMXTILE, AMXINT8, AMXBF16, KL, WIDEKL, AVXVNNI, AVX512\-FP16,
! AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AMX\-FP16, PREFETCHI, RAOINT,
! AMX\-COMPLEX or CLDEMOTE extended instruction sets. Each has a corresponding
  \&\fB\-mno\-\fR option to disable use of these instructions.
  .Sp
! These extensions are also available as built\-in functions: see
! \&\fBx86 Built\-in Functions\fR, for details of the functions enabled and
  disabled by these switches.
  .Sp
! To generate SSE/SSE2 instructions automatically from floating\-point
  code (as opposed to 387 instructions), see \fB\-mfpmath=sse\fR.
  .Sp
! GCC depresses SSEx instructions when \fB\-mavx\fR is used. Instead, it
! generates new AVX instructions or AVX equivalence for all SSEx instructions
  when needed.
  .Sp
! These options enable GCC to use these extended instructions in
  generated code, even without \fB\-mfpmath=sse\fR.  Applications that
! perform run\-time CPU detection must compile separate files for each
  supported architecture, using the appropriate flags.  In particular,
! the file containing the CPU detection code should be compiled without
  these options.
! .IP \fB\-mdump\-tune\-features\fR 4
  .IX Item "-mdump-tune-features"
! This option instructs GCC to dump the names of the x86 performance 
  tuning features and default settings. The names can be used in 
! \&\fB\-mtune\-ctrl=\fR\fIfeature\-list\fR.
! .IP \fB\-mtune\-ctrl=\fR\fIfeature\-list\fR 4
  .IX Item "-mtune-ctrl=feature-list"
  This option is used to do fine grain control of x86 code generation features.
! \&\fIfeature\-list\fR is a comma separated list of \fIfeature\fR names. See also
  \&\fB\-mdump\-tune\-features\fR. When specified, the \fIfeature\fR is turned
  on if it is not preceded with \fB^\fR, otherwise, it is turned off. 
! \&\fB\-mtune\-ctrl=\fR\fIfeature\-list\fR is intended to be used by GCC
  developers. Using it may lead to code paths not covered by testing and can
  potentially result in compiler ICEs or runtime errors.
! .IP \fB\-mno\-default\fR 4
  .IX Item "-mno-default"
! This option instructs GCC to turn off all tunable features. See also 
! \&\fB\-mtune\-ctrl=\fR\fIfeature\-list\fR and \fB\-mdump\-tune\-features\fR.
! .IP \fB\-mcld\fR 4
  .IX Item "-mcld"
! This option instructs GCC to emit a \f(CW\*(C`cld\*(C'\fR 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 \fB\-\-enable\-cld\fR configure option.  Generation of \f(CW\*(C`cld\*(C'\fR
  instructions can be suppressed with the \fB\-mno\-cld\fR compiler option
  in this case.
! .IP \fB\-mvzeroupper\fR 4
  .IX Item "-mvzeroupper"
! This option instructs GCC to emit a \f(CW\*(C`vzeroupper\*(C'\fR instruction
  before a transfer of control flow out of the function to minimize
! the AVX to SSE transition penalty as well as remove unnecessary \f(CW\*(C`zeroupper\*(C'\fR
  intrinsics.
! .IP \fB\-mprefer\-avx128\fR 4
  .IX Item "-mprefer-avx128"
! This option instructs GCC to use 128\-bit AVX instructions instead of
! 256\-bit AVX instructions in the auto\-vectorizer.
! .IP \fB\-mprefer\-vector\-width=\fR\fIopt\fR 4
  .IX Item "-mprefer-vector-width=opt"
! This option instructs GCC to use \fIopt\fR\-bit vector width in instructions
  instead of default on the selected platform.
! .IP \fB\-mmove\-max=\fR\fIbits\fR 4
  .IX Item "-mmove-max=bits"
! This option instructs GCC to set the maximum number of bits can be
  moved from memory to memory efficiently to \fIbits\fR.  The valid
  \&\fIbits\fR are 128, 256 and 512.
! .IP \fB\-mstore\-max=\fR\fIbits\fR 4
  .IX Item "-mstore-max=bits"
! This option instructs GCC to set the maximum number of bits can be
  stored to memory efficiently to \fIbits\fR.  The valid \fIbits\fR are
  128, 256 and 512.
  .RS 4
! .IP \fBnone\fR 4
  .IX Item "none"
! No extra limitations applied to GCC other than defined by the selected platform.
! .IP \fB128\fR 4
  .IX Item "128"
  Prefer 128\-bit vector width for instructions.
! .IP \fB256\fR 4
  .IX Item "256"
  Prefer 256\-bit vector width for instructions.
! .IP \fB512\fR 4
  .IX Item "512"
  Prefer 512\-bit vector width for instructions.
  .RE
  .RS 4
  .RE
! .IP \fB\-mcx16\fR 4
  .IX Item "-mcx16"
! This option enables GCC to generate \f(CW\*(C`CMPXCHG16B\*(C'\fR instructions in 64\-bit
! code to implement compare\-and\-exchange operations on 16\-byte aligned 128\-bit
  objects.  This is useful for atomic updates of data structures exceeding one
  machine word in size.  The compiler uses this instruction to implement
  \&\fB_\|_sync Builtins\fR.  However, for \fB_\|_atomic Builtins\fR operating on
  128\-bit integers, a library call is always used.
! .IP \fB\-msahf\fR 4
  .IX Item "-msahf"
  This option enables generation of \f(CW\*(C`SAHF\*(C'\fR instructions in 64\-bit code.
  Early Intel Pentium 4 CPUs with Intel 64 support,
  prior to the introduction of Pentium 4 G1 step in December 2005,
  lacked the \f(CW\*(C`LAHF\*(C'\fR and \f(CW\*(C`SAHF\*(C'\fR instructions
! which are supported by AMD64.
  These are load and store instructions, respectively, for certain status flags.
  In 64\-bit mode, the \f(CW\*(C`SAHF\*(C'\fR instruction is used to optimize \f(CW\*(C`fmod\*(C'\fR,
! \&\f(CW\*(C`drem\*(C'\fR, and \f(CW\*(C`remainder\*(C'\fR built\-in functions;
  see \fBOther Builtins\fR for details.
! .IP \fB\-mmovbe\fR 4
  .IX Item "-mmovbe"
  This option enables use of the \f(CW\*(C`movbe\*(C'\fR instruction to implement
  \&\f(CW\*(C`_\|_builtin_bswap32\*(C'\fR and \f(CW\*(C`_\|_builtin_bswap64\*(C'\fR.
! .IP \fB\-mshstk\fR 4
  .IX Item "-mshstk"
! The \fB\-mshstk\fR option enables shadow stack built\-in functions
! from x86 Control\-flow Enforcement Technology (CET).
! .IP \fB\-mcrc32\fR 4
  .IX Item "-mcrc32"
! This option enables built\-in functions \f(CW\*(C`_\|_builtin_ia32_crc32qi\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_ia32_crc32hi\*(C'\fR, \f(CW\*(C`_\|_builtin_ia32_crc32si\*(C'\fR and
  \&\f(CW\*(C`_\|_builtin_ia32_crc32di\*(C'\fR to generate the \f(CW\*(C`crc32\*(C'\fR machine instruction.
! .IP \fB\-mmwait\fR 4
  .IX Item "-mmwait"
! This option enables built\-in functions \f(CW\*(C`_\|_builtin_ia32_monitor\*(C'\fR,
  and \f(CW\*(C`_\|_builtin_ia32_mwait\*(C'\fR to generate the \f(CW\*(C`monitor\*(C'\fR and
  \&\f(CW\*(C`mwait\*(C'\fR machine instructions.
! .IP \fB\-mrecip\fR 4
  .IX Item "-mrecip"
  This option enables use of \f(CW\*(C`RCPSS\*(C'\fR and \f(CW\*(C`RSQRTSS\*(C'\fR instructions
  (and their vectorized variants \f(CW\*(C`RCPPS\*(C'\fR and \f(CW\*(C`RSQRTPS\*(C'\fR)
! with an additional Newton\-Raphson step
  to increase precision instead of \f(CW\*(C`DIVSS\*(C'\fR and \f(CW\*(C`SQRTSS\*(C'\fR
  (and their vectorized
! variants) for single\-precision floating\-point arguments.  These instructions
  are generated only when \fB\-funsafe\-math\-optimizations\fR is enabled
  together with \fB\-ffinite\-math\-only\fR and \fB\-fno\-trapping\-math\fR.
  Note that while the throughput of the sequence is higher than the throughput
! of the non\-reciprocal instruction, the precision of the sequence can be
  decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.99999994).
  .Sp
! Note that GCC implements \f(CW\*(C`1.0f/sqrtf(\fR\f(CIx\fR\f(CW)\*(C'\fR in terms of \f(CW\*(C`RSQRTSS\*(C'\fR
  (or \f(CW\*(C`RSQRTPS\*(C'\fR) already with \fB\-ffast\-math\fR (or the above option
! combination), and doesn\*(Aqt need \fB\-mrecip\fR.
  .Sp
! Also note that GCC emits the above sequence with additional Newton\-Raphson step
! for vectorized single\-float division and vectorized \f(CWsqrtf(\fR\f(CIx\fR\f(CW)\fR
  already with \fB\-ffast\-math\fR (or the above option combination), and
! doesn\*(Aqt need \fB\-mrecip\fR.
! .IP \fB\-mrecip=\fR\fIopt\fR 4
  .IX Item "-mrecip=opt"
  This option controls which reciprocal estimate instructions
! may be used.  \fIopt\fR is a comma\-separated list of options, which may
  be preceded by a \fB!\fR to invert the option:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
  Enable all estimate instructions.
! .IP \fBdefault\fR 4
  .IX Item "default"
  Enable the default instructions, equivalent to \fB\-mrecip\fR.
! .IP \fBnone\fR 4
  .IX Item "none"
  Disable all estimate instructions, equivalent to \fB\-mno\-recip\fR.
! .IP \fBdiv\fR 4
  .IX Item "div"
  Enable the approximation for scalar division.
! .IP \fBvec\-div\fR 4
  .IX Item "vec-div"
  Enable the approximation for vectorized division.
! .IP \fBsqrt\fR 4
  .IX Item "sqrt"
  Enable the approximation for scalar square root.
! .IP \fBvec\-sqrt\fR 4
  .IX Item "vec-sqrt"
  Enable the approximation for vectorized square root.
  .RE
*************** Enable the approximation for vectorized
*** 32696,32712 ****
  So, for example, \fB\-mrecip=all,!sqrt\fR enables
  all of the reciprocal approximations, except for square root.
  .RE
! .IP "\fB\-mveclibabi=\fR\fItype\fR" 4
  .IX Item "-mveclibabi=type"
! Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
  external library.  Supported values for \fItype\fR are \fBsvml\fR 
  for the Intel short
! vector math library and \fBacml\fR for the \s-1AMD\s0 math core library.
  To use this option, both \fB\-ftree\-vectorize\fR and
! \&\fB\-funsafe\-math\-optimizations\fR have to be enabled, and an \s-1SVML\s0 or \s-1ACML\s0 
! ABI-compatible library must be specified at link time.
  .Sp
! \&\s-1GCC\s0 currently emits calls to \f(CW\*(C`vmldExp2\*(C'\fR,
  \&\f(CW\*(C`vmldLn2\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldPow2\*(C'\fR,
  \&\f(CW\*(C`vmldTanh2\*(C'\fR, \f(CW\*(C`vmldTan2\*(C'\fR, \f(CW\*(C`vmldAtan2\*(C'\fR, \f(CW\*(C`vmldAtanh2\*(C'\fR,
  \&\f(CW\*(C`vmldCbrt2\*(C'\fR, \f(CW\*(C`vmldSinh2\*(C'\fR, \f(CW\*(C`vmldSin2\*(C'\fR, \f(CW\*(C`vmldAsinh2\*(C'\fR,
--- 32627,32643 ----
  So, for example, \fB\-mrecip=all,!sqrt\fR enables
  all of the reciprocal approximations, except for square root.
  .RE
! .IP \fB\-mveclibabi=\fR\fItype\fR 4
  .IX Item "-mveclibabi=type"
! Specifies the ABI type to use for vectorizing intrinsics using an
  external library.  Supported values for \fItype\fR are \fBsvml\fR 
  for the Intel short
! vector math library and \fBacml\fR for the AMD math core library.
  To use this option, both \fB\-ftree\-vectorize\fR and
! \&\fB\-funsafe\-math\-optimizations\fR have to be enabled, and an SVML or ACML 
! ABI\-compatible library must be specified at link time.
  .Sp
! GCC currently emits calls to \f(CW\*(C`vmldExp2\*(C'\fR,
  \&\f(CW\*(C`vmldLn2\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldPow2\*(C'\fR,
  \&\f(CW\*(C`vmldTanh2\*(C'\fR, \f(CW\*(C`vmldTan2\*(C'\fR, \f(CW\*(C`vmldAtan2\*(C'\fR, \f(CW\*(C`vmldAtanh2\*(C'\fR,
  \&\f(CW\*(C`vmldCbrt2\*(C'\fR, \f(CW\*(C`vmldSinh2\*(C'\fR, \f(CW\*(C`vmldSin2\*(C'\fR, \f(CW\*(C`vmldAsinh2\*(C'\fR,
*************** function type when \fB\-mveclibabi=svml\
*** 32722,32808 ****
  \&\f(CW\*(C`_\|_vrs4_expf\*(C'\fR, \f(CW\*(C`_\|_vrs4_logf\*(C'\fR, \f(CW\*(C`_\|_vrs4_log2f\*(C'\fR,
  \&\f(CW\*(C`_\|_vrs4_log10f\*(C'\fR and \f(CW\*(C`_\|_vrs4_powf\*(C'\fR for the corresponding function type
  when \fB\-mveclibabi=acml\fR is used.
! .IP "\fB\-mabi=\fR\fIname\fR" 4
  .IX Item "-mabi=name"
  Generate code for the specified calling convention.  Permissible values
! are \fBsysv\fR for the \s-1ABI\s0 used on GNU/Linux and other systems, and
! \&\fBms\fR for the Microsoft \s-1ABI.\s0  The default is to use the Microsoft
! \&\s-1ABI\s0 when targeting Microsoft Windows and the SysV \s-1ABI\s0 on all other systems.
  You can control this behavior for specific functions by
  using the function attributes \f(CW\*(C`ms_abi\*(C'\fR and \f(CW\*(C`sysv_abi\*(C'\fR.
! .IP "\fB\-mforce\-indirect\-call\fR" 4
  .IX Item "-mforce-indirect-call"
  Force all calls to functions to be indirect. This is useful
  when using Intel Processor Trace where it generates more precise timing
  information for function calls.
! .IP "\fB\-mmanual\-endbr\fR" 4
  .IX Item "-mmanual-endbr"
! Insert \s-1ENDBR\s0 instruction at function entry only via the \f(CW\*(C`cf_check\*(C'\fR
  function attribute. This is useful when used with the option
! \&\fB\-fcf\-protection=branch\fR to control \s-1ENDBR\s0 insertion at the
  function entry.
! .IP "\fB\-mcet\-switch\fR" 4
  .IX Item "-mcet-switch"
! By default, \s-1CET\s0 instrumentation is turned off on switch statements that
  use a jump table and indirect branch track is disabled.  Since jump
! tables are stored in read-only memory, this does not result in a direct
! loss of hardening.  But if the jump table index is attacker-controlled,
! the indirect jump may not be constrained by \s-1CET.\s0  This option turns on
! \&\s-1CET\s0 instrumentation to enable indirect branch track for switch statements
  with jump tables which leads to the jump targets reachable via any indirect
  jumps.
! .IP "\fB\-mcall\-ms2sysv\-xlogues\fR" 4
  .IX Item "-mcall-ms2sysv-xlogues"
! Due to differences in 64\-bit ABIs, any Microsoft \s-1ABI\s0 function that calls a
! System V \s-1ABI\s0 function must consider \s-1RSI, RDI\s0 and \s-1XMM6\-15\s0 as clobbered.  By
  default, the code for saving and restoring these registers is emitted inline,
  resulting in fairly lengthy prologues and epilogues.  Using
  \&\fB\-mcall\-ms2sysv\-xlogues\fR emits prologues and epilogues that
  use stubs in the static portion of libgcc to perform these saves and restores,
  thus reducing function size at the cost of a few extra instructions.
! .IP "\fB\-mtls\-dialect=\fR\fItype\fR" 4
  .IX Item "-mtls-dialect=type"
! Generate code to access thread-local storage using the \fBgnu\fR or
  \&\fBgnu2\fR conventions.  \fBgnu\fR is the conservative default;
! \&\fBgnu2\fR is more efficient, but it may add compile\- and run-time
  requirements that cannot be satisfied on all systems.
! .IP "\fB\-mpush\-args\fR" 4
  .IX Item "-mpush-args"
  .PD 0
! .IP "\fB\-mno\-push\-args\fR" 4
  .IX Item "-mno-push-args"
  .PD
! Use \s-1PUSH\s0 operations to store outgoing parameters.  This method is shorter
! and usually equally fast as method using \s-1SUB/MOV\s0 operations and is enabled
  by default.  In some cases disabling it may improve performance because of
  improved scheduling and reduced dependencies.
! .IP "\fB\-maccumulate\-outgoing\-args\fR" 4
  .IX Item "-maccumulate-outgoing-args"
  If enabled, the maximum amount of space required for outgoing arguments is
  computed in the function prologue.  This is faster on most modern CPUs
  because of reduced dependencies, improved scheduling and reduced stack usage
  when the preferred stack boundary is not equal to 2.  The drawback is a notable
  increase in code size.  This switch implies \fB\-mno\-push\-args\fR.
! .IP "\fB\-mthreads\fR" 4
  .IX Item "-mthreads"
! Support thread-safe exception handling on MinGW.  Programs that rely
! on thread-safe exception handling must compile and link all code with the
  \&\fB\-mthreads\fR option.  When compiling, \fB\-mthreads\fR defines
  \&\fB\-D_MT\fR; when linking, it links in a special thread helper library
! \&\fB\-lmingwthrd\fR which cleans up per-thread exception-handling data.
! .IP "\fB\-mms\-bitfields\fR" 4
  .IX Item "-mms-bitfields"
  .PD 0
! .IP "\fB\-mno\-ms\-bitfields\fR" 4
  .IX Item "-mno-ms-bitfields"
  .PD
! Enable/disable bit-field layout compatible with the native Microsoft
  Windows compiler.
  .Sp
! If \f(CW\*(C`packed\*(C'\fR is used on a structure, or if bit-fields are used,
! it may be that the Microsoft \s-1ABI\s0 lays out the structure differently
! than the way \s-1GCC\s0 normally does.  Particularly when moving packed
! data between functions compiled with \s-1GCC\s0 and the native Microsoft compiler
  (either via function call or as data in a file), it may be necessary to access
  either format.
  .Sp
--- 32653,32739 ----
  \&\f(CW\*(C`_\|_vrs4_expf\*(C'\fR, \f(CW\*(C`_\|_vrs4_logf\*(C'\fR, \f(CW\*(C`_\|_vrs4_log2f\*(C'\fR,
  \&\f(CW\*(C`_\|_vrs4_log10f\*(C'\fR and \f(CW\*(C`_\|_vrs4_powf\*(C'\fR for the corresponding function type
  when \fB\-mveclibabi=acml\fR is used.
! .IP \fB\-mabi=\fR\fIname\fR 4
  .IX Item "-mabi=name"
  Generate code for the specified calling convention.  Permissible values
! are \fBsysv\fR for the ABI used on GNU/Linux and other systems, and
! \&\fBms\fR for the Microsoft ABI.  The default is to use the Microsoft
! ABI when targeting Microsoft Windows and the SysV ABI on all other systems.
  You can control this behavior for specific functions by
  using the function attributes \f(CW\*(C`ms_abi\*(C'\fR and \f(CW\*(C`sysv_abi\*(C'\fR.
! .IP \fB\-mforce\-indirect\-call\fR 4
  .IX Item "-mforce-indirect-call"
  Force all calls to functions to be indirect. This is useful
  when using Intel Processor Trace where it generates more precise timing
  information for function calls.
! .IP \fB\-mmanual\-endbr\fR 4
  .IX Item "-mmanual-endbr"
! Insert ENDBR instruction at function entry only via the \f(CW\*(C`cf_check\*(C'\fR
  function attribute. This is useful when used with the option
! \&\fB\-fcf\-protection=branch\fR to control ENDBR insertion at the
  function entry.
! .IP \fB\-mcet\-switch\fR 4
  .IX Item "-mcet-switch"
! By default, CET instrumentation is turned off on switch statements that
  use a jump table and indirect branch track is disabled.  Since jump
! tables are stored in read\-only memory, this does not result in a direct
! loss of hardening.  But if the jump table index is attacker\-controlled,
! the indirect jump may not be constrained by CET.  This option turns on
! CET instrumentation to enable indirect branch track for switch statements
  with jump tables which leads to the jump targets reachable via any indirect
  jumps.
! .IP \fB\-mcall\-ms2sysv\-xlogues\fR 4
  .IX Item "-mcall-ms2sysv-xlogues"
! Due to differences in 64\-bit ABIs, any Microsoft ABI function that calls a
! System V ABI function must consider RSI, RDI and XMM6\-15 as clobbered.  By
  default, the code for saving and restoring these registers is emitted inline,
  resulting in fairly lengthy prologues and epilogues.  Using
  \&\fB\-mcall\-ms2sysv\-xlogues\fR emits prologues and epilogues that
  use stubs in the static portion of libgcc to perform these saves and restores,
  thus reducing function size at the cost of a few extra instructions.
! .IP \fB\-mtls\-dialect=\fR\fItype\fR 4
  .IX Item "-mtls-dialect=type"
! Generate code to access thread\-local storage using the \fBgnu\fR or
  \&\fBgnu2\fR conventions.  \fBgnu\fR is the conservative default;
! \&\fBgnu2\fR is more efficient, but it may add compile\- and run\-time
  requirements that cannot be satisfied on all systems.
! .IP \fB\-mpush\-args\fR 4
  .IX Item "-mpush-args"
  .PD 0
! .IP \fB\-mno\-push\-args\fR 4
  .IX Item "-mno-push-args"
  .PD
! Use 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.
! .IP \fB\-maccumulate\-outgoing\-args\fR 4
  .IX Item "-maccumulate-outgoing-args"
  If enabled, the maximum amount of space required for outgoing arguments is
  computed in the function prologue.  This is faster on most modern CPUs
  because of reduced dependencies, improved scheduling and reduced stack usage
  when the preferred stack boundary is not equal to 2.  The drawback is a notable
  increase in code size.  This switch implies \fB\-mno\-push\-args\fR.
! .IP \fB\-mthreads\fR 4
  .IX Item "-mthreads"
! Support thread\-safe exception handling on MinGW.  Programs that rely
! on thread\-safe exception handling must compile and link all code with the
  \&\fB\-mthreads\fR option.  When compiling, \fB\-mthreads\fR defines
  \&\fB\-D_MT\fR; when linking, it links in a special thread helper library
! \&\fB\-lmingwthrd\fR which cleans up per\-thread exception\-handling data.
! .IP \fB\-mms\-bitfields\fR 4
  .IX Item "-mms-bitfields"
  .PD 0
! .IP \fB\-mno\-ms\-bitfields\fR 4
  .IX Item "-mno-ms-bitfields"
  .PD
! Enable/disable bit\-field layout compatible with the native Microsoft
  Windows compiler.
  .Sp
! If \f(CW\*(C`packed\*(C'\fR is used on a structure, or if bit\-fields are used,
! it may be that the Microsoft ABI lays out the structure differently
! than the way GCC normally does.  Particularly when moving packed
! data between functions compiled with GCC and the native Microsoft compiler
  (either via function call or as data in a file), it may be necessary to access
  either format.
  .Sp
*************** or type attributes.  For more informatio
*** 32812,32820 ****
  and \fBx86 Type Attributes\fR.
  .Sp
  The Microsoft structure layout algorithm is fairly simple with the exception
! of the bit-field packing.  
! The padding and alignment of members of structures and whether a bit-field 
! can straddle a storage-unit boundary are determine by these rules:
  .RS 4
  .IP "1. Structure members are stored sequentially in the order in which they are" 4
  .IX Item "1. Structure members are stored sequentially in the order in which they are"
--- 32743,32751 ----
  and \fBx86 Type Attributes\fR.
  .Sp
  The Microsoft structure layout algorithm is fairly simple with the exception
! of the bit\-field packing.  
! The padding and alignment of members of structures and whether a bit\-field 
! can straddle a storage\-unit boundary are determine by these rules:
  .RS 4
  .IP "1. Structure members are stored sequentially in the order in which they are" 4
  .IX Item "1. Structure members are stored sequentially in the order in which they are"
*************** Every object is allocated an offset so t
*** 32832,32849 ****
  .Vb 1
  \&        offset % alignment_requirement == 0
  .Ve
! .IP "3. Adjacent bit-fields are packed into the same 1\-, 2\-, or 4\-byte allocation" 4
  .IX Item "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.
  .RE
  .RS 4
  .Sp
! \&\s-1MSVC\s0 interprets zero-length bit-fields in the following ways:
! .IP "1. If a zero-length bit-field is inserted between two bit-fields that" 4
  .IX Item "1. If a zero-length bit-field is inserted between two bit-fields that"
! are normally coalesced, the bit-fields are not coalesced.
  .Sp
  For example:
  .Sp
--- 32763,32780 ----
  .Vb 1
  \&        offset % alignment_requirement == 0
  .Ve
! .IP "3. Adjacent bit\-fields are packed into the same 1\-, 2\-, or 4\-byte allocation" 4
  .IX Item "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.
  .RE
  .RS 4
  .Sp
! MSVC interprets zero\-length bit\-fields in the following ways:
! .IP "1. If a zero\-length bit\-field is inserted between two bit\-fields that" 4
  .IX Item "1. If a zero-length bit-field is inserted between two bit-fields that"
! are normally coalesced, the bit\-fields are not coalesced.
  .Sp
  For example:
  .Sp
*************** For example:
*** 32856,32868 ****
  \&         } t1;
  .Ve
  .Sp
! The size of \f(CW\*(C`t1\*(C'\fR is 8 bytes with the zero-length bit-field.  If the
! zero-length bit-field were removed, \f(CW\*(C`t1\*(C'\fR's size would be 4 bytes.
! .ie n .IP "2. If a zero-length bit-field is inserted after a bit-field, ""foo"", and the" 4
! .el .IP "2. If a zero-length bit-field is inserted after a bit-field, \f(CWfoo\fR, and the" 4
  .IX Item "2. If a zero-length bit-field is inserted after a bit-field, foo, and the"
! alignment of the zero-length bit-field is greater than the member that follows it,
! \&\f(CW\*(C`bar\*(C'\fR, \f(CW\*(C`bar\*(C'\fR is aligned as the type of the zero-length bit-field.
  .Sp
  For example:
  .Sp
--- 32787,32799 ----
  \&         } t1;
  .Ve
  .Sp
! The size of \f(CW\*(C`t1\*(C'\fR is 8 bytes with the zero\-length bit\-field.  If the
! zero\-length bit\-field were removed, \f(CW\*(C`t1\*(C'\fR\*(Aqs size would be 4 bytes.
! .ie n .IP "2. If a zero\-length bit\-field is inserted after a bit\-field, ""foo"", and the" 4
! .el .IP "2. If a zero\-length bit\-field is inserted after a bit\-field, \f(CWfoo\fR, and the" 4
  .IX Item "2. If a zero-length bit-field is inserted after a bit-field, foo, and the"
! alignment of the zero\-length bit\-field is greater than the member that follows it,
! \&\f(CW\*(C`bar\*(C'\fR, \f(CW\*(C`bar\*(C'\fR is aligned as the type of the zero\-length bit\-field.
  .Sp
  For example:
  .Sp
*************** For example:
*** 32883,32900 ****
  .Ve
  .Sp
  For \f(CW\*(C`t2\*(C'\fR, \f(CW\*(C`bar\*(C'\fR is placed at offset 2, rather than offset 1.
! Accordingly, the size of \f(CW\*(C`t2\*(C'\fR is 4.  For \f(CW\*(C`t3\*(C'\fR, the zero-length
! bit-field does not affect the alignment of \f(CW\*(C`bar\*(C'\fR or, as a result, the size
  of the structure.
  .Sp
  Taking this into account, it is important to note the following:
  .RS 4
! .IP "1. If a zero-length bit-field follows a normal bit-field, the type of the" 4
  .IX Item "1. If a zero-length bit-field follows a normal bit-field, the type of the"
! zero-length bit-field may affect the alignment of the structure as whole. For
! example, \f(CW\*(C`t2\*(C'\fR has a size of 4 bytes, since the zero-length bit-field follows a
! normal bit-field, and is of type short.
! .IP "2. Even if a zero-length bit-field is not followed by a normal bit-field, it may" 4
  .IX Item "2. Even if a zero-length bit-field is not followed by a normal bit-field, it may"
  still affect the alignment of the structure:
  .Sp
--- 32814,32831 ----
  .Ve
  .Sp
  For \f(CW\*(C`t2\*(C'\fR, \f(CW\*(C`bar\*(C'\fR is placed at offset 2, rather than offset 1.
! Accordingly, the size of \f(CW\*(C`t2\*(C'\fR is 4.  For \f(CW\*(C`t3\*(C'\fR, the zero\-length
! bit\-field does not affect the alignment of \f(CW\*(C`bar\*(C'\fR or, as a result, the size
  of the structure.
  .Sp
  Taking this into account, it is important to note the following:
  .RS 4
! .IP "1. If a zero\-length bit\-field follows a normal bit\-field, the type of the" 4
  .IX Item "1. If a zero-length bit-field follows a normal bit-field, the type of the"
! zero\-length bit\-field may affect the alignment of the structure as whole. For
! example, \f(CW\*(C`t2\*(C'\fR has a size of 4 bytes, since the zero\-length bit\-field follows a
! normal bit\-field, and is of type short.
! .IP "2. Even if a zero\-length bit\-field is not followed by a normal bit\-field, it may" 4
  .IX Item "2. Even if a zero-length bit-field is not followed by a normal bit-field, it may"
  still affect the alignment of the structure:
  .Sp
*************** Here, \f(CW\*(C`t4\*(C'\fR takes up 4 by
*** 32910,32916 ****
  .RE
  .RS 4
  .RE
! .IP "3. Zero-length bit-fields following non-bit-field members are ignored:" 4
  .IX Item "3. Zero-length bit-fields following non-bit-field members are ignored:"
  .Vb 6
  \&        struct
--- 32841,32847 ----
  .RE
  .RS 4
  .RE
! .IP "3. Zero\-length bit\-fields following non\-bit\-field members are ignored:" 4
  .IX Item "3. Zero-length bit-fields following non-bit-field members are ignored:"
  .Vb 6
  \&        struct
*************** Here, \f(CW\*(C`t5\*(C'\fR takes up 2 by
*** 32925,33114 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-mno\-align\-stringops\fR" 4
  .IX Item "-mno-align-stringops"
  Do not align the destination of inlined string operations.  This switch reduces
  code size and improves performance in case the destination is already aligned,
! but \s-1GCC\s0 doesn't know about it.
! .IP "\fB\-minline\-all\-stringops\fR" 4
  .IX Item "-minline-all-stringops"
! By default \s-1GCC\s0 inlines string operations only when the destination is 
  known to be aligned to least a 4\-byte boundary.  
  This enables more inlining and increases code
  size, but may improve performance of code that depends on fast
  \&\f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memset\*(C'\fR for short lengths.
  The option enables inline expansion of \f(CW\*(C`strlen\*(C'\fR for all
  pointer alignments.
! .IP "\fB\-minline\-stringops\-dynamically\fR" 4
  .IX Item "-minline-stringops-dynamically"
! For string operations of unknown size, use run-time checks with
  inline code for small blocks and a library call for large blocks.
! .IP "\fB\-mstringop\-strategy=\fR\fIalg\fR" 4
  .IX Item "-mstringop-strategy=alg"
  Override the internal decision heuristic for the particular algorithm to use
  for inlining string operations.  The allowed values for \fIalg\fR are:
  .RS 4
! .IP "\fBrep_byte\fR" 4
  .IX Item "rep_byte"
  .PD 0
! .IP "\fBrep_4byte\fR" 4
  .IX Item "rep_4byte"
! .IP "\fBrep_8byte\fR" 4
  .IX Item "rep_8byte"
  .PD
  Expand using i386 \f(CW\*(C`rep\*(C'\fR prefix of the specified size.
! .IP "\fBbyte_loop\fR" 4
  .IX Item "byte_loop"
  .PD 0
! .IP "\fBloop\fR" 4
  .IX Item "loop"
! .IP "\fBunrolled_loop\fR" 4
  .IX Item "unrolled_loop"
  .PD
  Expand into an inline loop.
! .IP "\fBlibcall\fR" 4
  .IX Item "libcall"
  Always use a library call.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mmemcpy\-strategy=\fR\fIstrategy\fR" 4
  .IX Item "-mmemcpy-strategy=strategy"
  Override the internal decision heuristic to decide if \f(CW\*(C`_\|_builtin_memcpy\*(C'\fR
  should be inlined and what inline algorithm to use when the expected size
  of the copy operation is known. \fIstrategy\fR 
! is a comma-separated list of \fIalg\fR:\fImax_size\fR:\fIdest_align\fR triplets. 
  \&\fIalg\fR is specified in \fB\-mstringop\-strategy\fR, \fImax_size\fR specifies
  the max byte size with which inline algorithm \fIalg\fR is allowed.  For the last
! triplet, the \fImax_size\fR must be \f(CW\*(C`\-1\*(C'\fR. The \fImax_size\fR of the triplets
  in the list must be specified in increasing order.  The minimal byte size for 
! \&\fIalg\fR is \f(CW0\fR for the first triplet and \f(CW\*(C`\f(CImax_size\f(CW + 1\*(C'\fR of the 
  preceding range.
! .IP "\fB\-mmemset\-strategy=\fR\fIstrategy\fR" 4
  .IX Item "-mmemset-strategy=strategy"
  The option is similar to \fB\-mmemcpy\-strategy=\fR except that it is to control
  \&\f(CW\*(C`_\|_builtin_memset\*(C'\fR expansion.
! .IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
  .IX Item "-momit-leaf-frame-pointer"
! Don't keep the frame pointer in a register for leaf functions.  This
  avoids the instructions to save, set up, and restore frame pointers and
  makes an extra register available in leaf functions.  The option
  \&\fB\-fomit\-leaf\-frame\-pointer\fR removes the frame pointer for leaf functions,
  which might make debugging harder.
! .IP "\fB\-mtls\-direct\-seg\-refs\fR" 4
  .IX Item "-mtls-direct-seg-refs"
  .PD 0
! .IP "\fB\-mno\-tls\-direct\-seg\-refs\fR" 4
  .IX Item "-mno-tls-direct-seg-refs"
  .PD
! Controls whether \s-1TLS\s0 variables may be accessed with offsets from the
! \&\s-1TLS\s0 segment register (\f(CW%gs\fR for 32\-bit, \f(CW%fs\fR for 64\-bit),
  or whether the thread base pointer must be added.  Whether or not this
  is valid depends on the operating system, and whether it maps the
! segment to cover the entire \s-1TLS\s0 area.
  .Sp
! For systems that use the \s-1GNU C\s0 Library, the default is on.
! .IP "\fB\-msse2avx\fR" 4
  .IX Item "-msse2avx"
  .PD 0
! .IP "\fB\-mno\-sse2avx\fR" 4
  .IX Item "-mno-sse2avx"
  .PD
! Specify that the assembler should encode \s-1SSE\s0 instructions with \s-1VEX\s0
  prefix.  The option \fB\-mavx\fR turns this on by default.
! .IP "\fB\-mfentry\fR" 4
  .IX Item "-mfentry"
  .PD 0
! .IP "\fB\-mno\-fentry\fR" 4
  .IX Item "-mno-fentry"
  .PD
  If profiling is active (\fB\-pg\fR), put the profiling
  counter call before the prologue.
  Note: On x86 architectures the attribute \f(CW\*(C`ms_hook_prologue\*(C'\fR
! isn't possible at the moment for \fB\-mfentry\fR and \fB\-pg\fR.
! .IP "\fB\-mrecord\-mcount\fR" 4
  .IX Item "-mrecord-mcount"
  .PD 0
! .IP "\fB\-mno\-record\-mcount\fR" 4
  .IX Item "-mno-record-mcount"
  .PD
  If profiling is active (\fB\-pg\fR), generate a _\|_mcount_loc section
  that contains pointers to each profiling call. This is useful for
  automatically patching and out calls.
! .IP "\fB\-mnop\-mcount\fR" 4
  .IX Item "-mnop-mcount"
  .PD 0
! .IP "\fB\-mno\-nop\-mcount\fR" 4
  .IX Item "-mno-nop-mcount"
  .PD
  If profiling is active (\fB\-pg\fR), generate the calls to
  the profiling functions as NOPs. This is useful when they
  should be patched in later dynamically. This is likely only
  useful together with \fB\-mrecord\-mcount\fR.
! .IP "\fB\-minstrument\-return=\fR\fItype\fR" 4
  .IX Item "-minstrument-return=type"
  Instrument function exit in \-pg \-mfentry instrumented functions with
  call to specified function. This only instruments true returns ending
  with ret, but not sibling calls ending with jump. Valid types
  are \fInone\fR to not instrument, \fIcall\fR to generate a call to _\|_return_\|_,
  or \fInop5\fR to generate a 5 byte nop.
! .IP "\fB\-mrecord\-return\fR" 4
  .IX Item "-mrecord-return"
  .PD 0
! .IP "\fB\-mno\-record\-return\fR" 4
  .IX Item "-mno-record-return"
  .PD
  Generate a _\|_return_loc section pointing to all return instrumentation code.
! .IP "\fB\-mfentry\-name=\fR\fIname\fR" 4
  .IX Item "-mfentry-name=name"
  Set name of _\|_fentry_\|_ symbol called at function entry for \-pg \-mfentry functions.
! .IP "\fB\-mfentry\-section=\fR\fIname\fR" 4
  .IX Item "-mfentry-section=name"
  Set name of section to record \-mrecord\-mcount calls (default _\|_mcount_loc).
! .IP "\fB\-mskip\-rax\-setup\fR" 4
  .IX Item "-mskip-rax-setup"
  .PD 0
! .IP "\fB\-mno\-skip\-rax\-setup\fR" 4
  .IX Item "-mno-skip-rax-setup"
  .PD
! When generating code for the x86\-64 architecture with \s-1SSE\s0 extensions
! disabled, \fB\-mskip\-rax\-setup\fR can be used to skip setting up \s-1RAX\s0
  register when there are no variable arguments passed in vector registers.
  .Sp
! \&\fBWarning:\fR Since \s-1RAX\s0 register is used to avoid unnecessarily
  saving vector registers on stack when passing variable arguments, the
  impacts of this option are callees may waste some stack space,
! misbehave or jump to a random location.  \s-1GCC 4.4\s0 or newer don't have
! those issues, regardless the \s-1RAX\s0 register value.
! .IP "\fB\-m8bit\-idiv\fR" 4
  .IX Item "-m8bit-idiv"
  .PD 0
! .IP "\fB\-mno\-8bit\-idiv\fR" 4
  .IX Item "-mno-8bit-idiv"
  .PD
  On some processors, like Intel Atom, 8\-bit unsigned integer divide is
  much faster than 32\-bit/64\-bit integer divide.  This option generates a
! run-time check.  If both dividend and divisor are within range of 0
  to 255, 8\-bit unsigned integer divide is used instead of
  32\-bit/64\-bit integer divide.
! .IP "\fB\-mavx256\-split\-unaligned\-load\fR" 4
  .IX Item "-mavx256-split-unaligned-load"
  .PD 0
! .IP "\fB\-mavx256\-split\-unaligned\-store\fR" 4
  .IX Item "-mavx256-split-unaligned-store"
  .PD
! Split 32\-byte \s-1AVX\s0 unaligned load and store.
! .IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP "\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR" 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP "\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR" 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for global canary or \fBtls\fR for per-thread
! canary in the \s-1TLS\s0 block (the default).  This option has effect only when
  \&\fB\-fstack\-protector\fR or \fB\-fstack\-protector\-all\fR is specified.
  .Sp
  With the latter choice the options
--- 32856,33045 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-mno\-align\-stringops\fR 4
  .IX Item "-mno-align-stringops"
  Do not align the destination of inlined string operations.  This switch reduces
  code size and improves performance in case the destination is already aligned,
! but GCC doesn\*(Aqt know about it.
! .IP \fB\-minline\-all\-stringops\fR 4
  .IX Item "-minline-all-stringops"
! By default GCC inlines string operations only when the destination is 
  known to be aligned to least a 4\-byte boundary.  
  This enables more inlining and increases code
  size, but may improve performance of code that depends on fast
  \&\f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memset\*(C'\fR for short lengths.
  The option enables inline expansion of \f(CW\*(C`strlen\*(C'\fR for all
  pointer alignments.
! .IP \fB\-minline\-stringops\-dynamically\fR 4
  .IX Item "-minline-stringops-dynamically"
! For string operations of unknown size, use run\-time checks with
  inline code for small blocks and a library call for large blocks.
! .IP \fB\-mstringop\-strategy=\fR\fIalg\fR 4
  .IX Item "-mstringop-strategy=alg"
  Override the internal decision heuristic for the particular algorithm to use
  for inlining string operations.  The allowed values for \fIalg\fR are:
  .RS 4
! .IP \fBrep_byte\fR 4
  .IX Item "rep_byte"
  .PD 0
! .IP \fBrep_4byte\fR 4
  .IX Item "rep_4byte"
! .IP \fBrep_8byte\fR 4
  .IX Item "rep_8byte"
  .PD
  Expand using i386 \f(CW\*(C`rep\*(C'\fR prefix of the specified size.
! .IP \fBbyte_loop\fR 4
  .IX Item "byte_loop"
  .PD 0
! .IP \fBloop\fR 4
  .IX Item "loop"
! .IP \fBunrolled_loop\fR 4
  .IX Item "unrolled_loop"
  .PD
  Expand into an inline loop.
! .IP \fBlibcall\fR 4
  .IX Item "libcall"
  Always use a library call.
  .RE
  .RS 4
  .RE
! .IP \fB\-mmemcpy\-strategy=\fR\fIstrategy\fR 4
  .IX Item "-mmemcpy-strategy=strategy"
  Override the internal decision heuristic to decide if \f(CW\*(C`_\|_builtin_memcpy\*(C'\fR
  should be inlined and what inline algorithm to use when the expected size
  of the copy operation is known. \fIstrategy\fR 
! is a comma\-separated list of \fIalg\fR:\fImax_size\fR:\fIdest_align\fR triplets. 
  \&\fIalg\fR is specified in \fB\-mstringop\-strategy\fR, \fImax_size\fR specifies
  the max byte size with which inline algorithm \fIalg\fR is allowed.  For the last
! triplet, the \fImax_size\fR must be \f(CW\-1\fR. The \fImax_size\fR of the triplets
  in the list must be specified in increasing order.  The minimal byte size for 
! \&\fIalg\fR is \f(CW0\fR for the first triplet and \f(CW\*(C`\fR\f(CImax_size\fR\f(CW + 1\*(C'\fR of the 
  preceding range.
! .IP \fB\-mmemset\-strategy=\fR\fIstrategy\fR 4
  .IX Item "-mmemset-strategy=strategy"
  The option is similar to \fB\-mmemcpy\-strategy=\fR except that it is to control
  \&\f(CW\*(C`_\|_builtin_memset\*(C'\fR expansion.
! .IP \fB\-momit\-leaf\-frame\-pointer\fR 4
  .IX Item "-momit-leaf-frame-pointer"
! Don\*(Aqt keep the frame pointer in a register for leaf functions.  This
  avoids the instructions to save, set up, and restore frame pointers and
  makes an extra register available in leaf functions.  The option
  \&\fB\-fomit\-leaf\-frame\-pointer\fR removes the frame pointer for leaf functions,
  which might make debugging harder.
! .IP \fB\-mtls\-direct\-seg\-refs\fR 4
  .IX Item "-mtls-direct-seg-refs"
  .PD 0
! .IP \fB\-mno\-tls\-direct\-seg\-refs\fR 4
  .IX Item "-mno-tls-direct-seg-refs"
  .PD
! Controls whether TLS variables may be accessed with offsets from the
! TLS segment register (\f(CW%gs\fR for 32\-bit, \f(CW%fs\fR for 64\-bit),
  or whether the thread base pointer must be added.  Whether or not this
  is valid depends on the operating system, and whether it maps the
! segment to cover the entire TLS area.
  .Sp
! For systems that use the GNU C Library, the default is on.
! .IP \fB\-msse2avx\fR 4
  .IX Item "-msse2avx"
  .PD 0
! .IP \fB\-mno\-sse2avx\fR 4
  .IX Item "-mno-sse2avx"
  .PD
! Specify that the assembler should encode SSE instructions with VEX
  prefix.  The option \fB\-mavx\fR turns this on by default.
! .IP \fB\-mfentry\fR 4
  .IX Item "-mfentry"
  .PD 0
! .IP \fB\-mno\-fentry\fR 4
  .IX Item "-mno-fentry"
  .PD
  If profiling is active (\fB\-pg\fR), put the profiling
  counter call before the prologue.
  Note: On x86 architectures the attribute \f(CW\*(C`ms_hook_prologue\*(C'\fR
! isn\*(Aqt possible at the moment for \fB\-mfentry\fR and \fB\-pg\fR.
! .IP \fB\-mrecord\-mcount\fR 4
  .IX Item "-mrecord-mcount"
  .PD 0
! .IP \fB\-mno\-record\-mcount\fR 4
  .IX Item "-mno-record-mcount"
  .PD
  If profiling is active (\fB\-pg\fR), generate a _\|_mcount_loc section
  that contains pointers to each profiling call. This is useful for
  automatically patching and out calls.
! .IP \fB\-mnop\-mcount\fR 4
  .IX Item "-mnop-mcount"
  .PD 0
! .IP \fB\-mno\-nop\-mcount\fR 4
  .IX Item "-mno-nop-mcount"
  .PD
  If profiling is active (\fB\-pg\fR), generate the calls to
  the profiling functions as NOPs. This is useful when they
  should be patched in later dynamically. This is likely only
  useful together with \fB\-mrecord\-mcount\fR.
! .IP \fB\-minstrument\-return=\fR\fItype\fR 4
  .IX Item "-minstrument-return=type"
  Instrument function exit in \-pg \-mfentry instrumented functions with
  call to specified function. This only instruments true returns ending
  with ret, but not sibling calls ending with jump. Valid types
  are \fInone\fR to not instrument, \fIcall\fR to generate a call to _\|_return_\|_,
  or \fInop5\fR to generate a 5 byte nop.
! .IP \fB\-mrecord\-return\fR 4
  .IX Item "-mrecord-return"
  .PD 0
! .IP \fB\-mno\-record\-return\fR 4
  .IX Item "-mno-record-return"
  .PD
  Generate a _\|_return_loc section pointing to all return instrumentation code.
! .IP \fB\-mfentry\-name=\fR\fIname\fR 4
  .IX Item "-mfentry-name=name"
  Set name of _\|_fentry_\|_ symbol called at function entry for \-pg \-mfentry functions.
! .IP \fB\-mfentry\-section=\fR\fIname\fR 4
  .IX Item "-mfentry-section=name"
  Set name of section to record \-mrecord\-mcount calls (default _\|_mcount_loc).
! .IP \fB\-mskip\-rax\-setup\fR 4
  .IX Item "-mskip-rax-setup"
  .PD 0
! .IP \fB\-mno\-skip\-rax\-setup\fR 4
  .IX Item "-mno-skip-rax-setup"
  .PD
! When generating code for the x86\-64 architecture with SSE extensions
! disabled, \fB\-mskip\-rax\-setup\fR can be used to skip setting up RAX
  register when there are no variable arguments passed in vector registers.
  .Sp
! \&\fBWarning:\fR Since RAX register is used to avoid unnecessarily
  saving vector registers on stack when passing variable arguments, the
  impacts of this option are callees may waste some stack space,
! misbehave or jump to a random location.  GCC 4.4 or newer don\*(Aqt have
! those issues, regardless the RAX register value.
! .IP \fB\-m8bit\-idiv\fR 4
  .IX Item "-m8bit-idiv"
  .PD 0
! .IP \fB\-mno\-8bit\-idiv\fR 4
  .IX Item "-mno-8bit-idiv"
  .PD
  On some processors, like Intel Atom, 8\-bit unsigned integer divide is
  much faster than 32\-bit/64\-bit integer divide.  This option generates a
! run\-time check.  If both dividend and divisor are within range of 0
  to 255, 8\-bit unsigned integer divide is used instead of
  32\-bit/64\-bit integer divide.
! .IP \fB\-mavx256\-split\-unaligned\-load\fR 4
  .IX Item "-mavx256-split-unaligned-load"
  .PD 0
! .IP \fB\-mavx256\-split\-unaligned\-store\fR 4
  .IX Item "-mavx256-split-unaligned-store"
  .PD
! Split 32\-byte AVX unaligned load and store.
! .IP \fB\-mstack\-protector\-guard=\fR\fIguard\fR 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP \fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for global canary or \fBtls\fR for per\-thread
! canary in the TLS block (the default).  This option has effect only when
  \&\fB\-fstack\-protector\fR or \fB\-fstack\-protector\-all\fR is specified.
  .Sp
  With the latter choice the options
*************** With the latter choice the options
*** 33116,33141 ****
  \&\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR furthermore specify
  which segment register (\f(CW%fs\fR or \f(CW%gs\fR) to use as base register
  for reading the canary, and from what offset from that base register.
! The default for those is as specified in the relevant \s-1ABI.\s0
! .IP "\fB\-mgeneral\-regs\-only\fR" 4
  .IX Item "-mgeneral-regs-only"
! Generate code that uses only the general-purpose registers.  This
! prevents the compiler from using floating-point, vector, mask and bound
  registers.
! .IP "\fB\-mrelax\-cmpxchg\-loop\fR" 4
  .IX Item "-mrelax-cmpxchg-loop"
! When emitting a compare-and-swap loop for \fB_\|_sync Builtins\fR
  and \fB_\|_atomic Builtins\fR lacking a native instruction, optimize
  for the highly contended case by issuing an atomic load before the
  \&\f(CW\*(C`CMPXCHG\*(C'\fR instruction, and using the \f(CW\*(C`PAUSE\*(C'\fR instruction
! to save \s-1CPU\s0 power when restarting the loop.
! .IP "\fB\-mindirect\-branch=\fR\fIchoice\fR" 4
  .IX Item "-mindirect-branch=choice"
  Convert indirect call and jump with \fIchoice\fR.  The default is
  \&\fBkeep\fR, which keeps indirect call and jump unmodified.
  \&\fBthunk\fR converts indirect call and jump to call and return thunk.
! \&\fBthunk-inline\fR converts indirect call and jump to inlined call
! and return thunk.  \fBthunk-extern\fR converts indirect call and jump
  to external call and return thunk provided in a separate object file.
  You can control this behavior for a specific function by using the
  function attribute \f(CW\*(C`indirect_branch\*(C'\fR.
--- 33047,33072 ----
  \&\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR furthermore specify
  which segment register (\f(CW%fs\fR or \f(CW%gs\fR) to use as base register
  for reading the canary, and from what offset from that base register.
! The default for those is as specified in the relevant ABI.
! .IP \fB\-mgeneral\-regs\-only\fR 4
  .IX Item "-mgeneral-regs-only"
! Generate code that uses only the general\-purpose registers.  This
! prevents the compiler from using floating\-point, vector, mask and bound
  registers.
! .IP \fB\-mrelax\-cmpxchg\-loop\fR 4
  .IX Item "-mrelax-cmpxchg-loop"
! When emitting a compare\-and\-swap loop for \fB_\|_sync Builtins\fR
  and \fB_\|_atomic Builtins\fR lacking a native instruction, optimize
  for the highly contended case by issuing an atomic load before the
  \&\f(CW\*(C`CMPXCHG\*(C'\fR instruction, and using the \f(CW\*(C`PAUSE\*(C'\fR instruction
! to save CPU power when restarting the loop.
! .IP \fB\-mindirect\-branch=\fR\fIchoice\fR 4
  .IX Item "-mindirect-branch=choice"
  Convert indirect call and jump with \fIchoice\fR.  The default is
  \&\fBkeep\fR, which keeps indirect call and jump unmodified.
  \&\fBthunk\fR converts indirect call and jump to call and return thunk.
! \&\fBthunk\-inline\fR converts indirect call and jump to inlined call
! and return thunk.  \fBthunk\-extern\fR converts indirect call and jump
  to external call and return thunk provided in a separate object file.
  You can control this behavior for a specific function by using the
  function attribute \f(CW\*(C`indirect_branch\*(C'\fR.
*************** not be reachable in the large code model
*** 33147,33200 ****
  .Sp
  Note that \fB\-mindirect\-branch=thunk\-extern\fR is compatible with
  \&\fB\-fcf\-protection=branch\fR since the external thunk can be made
! to enable control-flow check.
! .IP "\fB\-mfunction\-return=\fR\fIchoice\fR" 4
  .IX Item "-mfunction-return=choice"
  Convert function return with \fIchoice\fR.  The default is \fBkeep\fR,
  which keeps function return unmodified.  \fBthunk\fR converts function
! return to call and return thunk.  \fBthunk-inline\fR converts function
! return to inlined call and return thunk.  \fBthunk-extern\fR converts
  function return to external call and return thunk provided in a separate
  object file.  You can control this behavior for a specific function by
  using the function attribute \f(CW\*(C`function_return\*(C'\fR.
  .Sp
  Note that \fB\-mindirect\-return=thunk\-extern\fR is compatible with
  \&\fB\-fcf\-protection=branch\fR since the external thunk can be made
! to enable control-flow check.
  .Sp
  Note that \fB\-mcmodel=large\fR is incompatible with
  \&\fB\-mfunction\-return=thunk\fR and
  \&\fB\-mfunction\-return=thunk\-extern\fR since the thunk function may
  not be reachable in the large code model.
! .IP "\fB\-mindirect\-branch\-register\fR" 4
  .IX Item "-mindirect-branch-register"
  Force indirect call and jump via register.
! .IP "\fB\-mharden\-sls=\fR\fIchoice\fR" 4
  .IX Item "-mharden-sls=choice"
! Generate code to mitigate against straight line speculation (\s-1SLS\s0) with
! \&\fIchoice\fR.  The default is \fBnone\fR which disables all \s-1SLS\s0
! hardening.  \fBreturn\fR enables \s-1SLS\s0 hardening for function returns.
! \&\fBindirect-jmp\fR enables \s-1SLS\s0 hardening for indirect jumps.
! \&\fBall\fR enables all \s-1SLS\s0 hardening.
! .IP "\fB\-mindirect\-branch\-cs\-prefix\fR" 4
  .IX Item "-mindirect-branch-cs-prefix"
! Add \s-1CS\s0 prefix to call and jmp to indirect thunk with branch target in
  r8\-r15 registers so that the call and jmp instruction length is 6 bytes
  to allow them to be replaced with \fBlfence; call *%r8\-r15\fR or
! \&\fBlfence; jmp *%r8\-r15\fR at run-time.
  .PP
  These \fB\-m\fR switches are supported in addition to the above
  on x86\-64 processors in 64\-bit environments.
! .IP "\fB\-m32\fR" 4
  .IX Item "-m32"
  .PD 0
! .IP "\fB\-m64\fR" 4
  .IX Item "-m64"
! .IP "\fB\-mx32\fR" 4
  .IX Item "-mx32"
! .IP "\fB\-m16\fR" 4
  .IX Item "-m16"
! .IP "\fB\-miamcu\fR" 4
  .IX Item "-miamcu"
  .PD
  Generate code for a 16\-bit, 32\-bit or 64\-bit environment.
--- 33078,33131 ----
  .Sp
  Note that \fB\-mindirect\-branch=thunk\-extern\fR is compatible with
  \&\fB\-fcf\-protection=branch\fR since the external thunk can be made
! to enable control\-flow check.
! .IP \fB\-mfunction\-return=\fR\fIchoice\fR 4
  .IX Item "-mfunction-return=choice"
  Convert function return with \fIchoice\fR.  The default is \fBkeep\fR,
  which keeps function return unmodified.  \fBthunk\fR converts function
! return to call and return thunk.  \fBthunk\-inline\fR converts function
! return to inlined call and return thunk.  \fBthunk\-extern\fR converts
  function return to external call and return thunk provided in a separate
  object file.  You can control this behavior for a specific function by
  using the function attribute \f(CW\*(C`function_return\*(C'\fR.
  .Sp
  Note that \fB\-mindirect\-return=thunk\-extern\fR is compatible with
  \&\fB\-fcf\-protection=branch\fR since the external thunk can be made
! to enable control\-flow check.
  .Sp
  Note that \fB\-mcmodel=large\fR is incompatible with
  \&\fB\-mfunction\-return=thunk\fR and
  \&\fB\-mfunction\-return=thunk\-extern\fR since the thunk function may
  not be reachable in the large code model.
! .IP \fB\-mindirect\-branch\-register\fR 4
  .IX Item "-mindirect-branch-register"
  Force indirect call and jump via register.
! .IP \fB\-mharden\-sls=\fR\fIchoice\fR 4
  .IX Item "-mharden-sls=choice"
! Generate code to mitigate against straight line speculation (SLS) with
! \&\fIchoice\fR.  The default is \fBnone\fR which disables all SLS
! hardening.  \fBreturn\fR enables SLS hardening for function returns.
! \&\fBindirect\-jmp\fR enables SLS hardening for indirect jumps.
! \&\fBall\fR enables all SLS hardening.
! .IP \fB\-mindirect\-branch\-cs\-prefix\fR 4
  .IX Item "-mindirect-branch-cs-prefix"
! Add CS prefix to call and jmp to indirect thunk with branch target in
  r8\-r15 registers so that the call and jmp instruction length is 6 bytes
  to allow them to be replaced with \fBlfence; call *%r8\-r15\fR or
! \&\fBlfence; jmp *%r8\-r15\fR at run\-time.
  .PP
  These \fB\-m\fR switches are supported in addition to the above
  on x86\-64 processors in 64\-bit environments.
! .IP \fB\-m32\fR 4
  .IX Item "-m32"
  .PD 0
! .IP \fB\-m64\fR 4
  .IX Item "-m64"
! .IP \fB\-mx32\fR 4
  .IX Item "-mx32"
! .IP \fB\-m16\fR 4
  .IX Item "-m16"
! .IP \fB\-miamcu\fR 4
  .IX Item "-miamcu"
  .PD
  Generate code for a 16\-bit, 32\-bit or 64\-bit environment.
*************** The \fB\-m16\fR option is the same as \f
*** 33215,33272 ****
  it outputs the \f(CW\*(C`.code16gcc\*(C'\fR assembly directive at the beginning of
  the assembly output so that the binary can run in 16\-bit mode.
  .Sp
! The \fB\-miamcu\fR option generates code which conforms to Intel \s-1MCU\s0
  psABI.  It requires the \fB\-m32\fR option to be turned on.
! .IP "\fB\-mno\-red\-zone\fR" 4
  .IX Item "-mno-red-zone"
! Do not use a so-called \*(L"red zone\*(R" for x86\-64 code.  The red zone is mandated
! by the x86\-64 \s-1ABI\s0; it is a 128\-byte area beyond the location of the
  stack pointer that is not modified by signal or interrupt handlers
  and therefore can be used for temporary data without adjusting the stack
  pointer.  The flag \fB\-mno\-red\-zone\fR disables this red zone.
! .IP "\fB\-mcmodel=small\fR" 4
  .IX Item "-mcmodel=small"
  Generate code for the small code model: the program and its symbols must
! be linked in the lower 2 \s-1GB\s0 of the address space.  Pointers are 64 bits.
  Programs can be statically or dynamically linked.  This is the default
  code model.
! .IP "\fB\-mcmodel=kernel\fR" 4
  .IX Item "-mcmodel=kernel"
  Generate code for the kernel code model.  The kernel runs in the
! negative 2 \s-1GB\s0 of the address space.
  This model has to be used for Linux kernel code.
! .IP "\fB\-mcmodel=medium\fR" 4
  .IX Item "-mcmodel=medium"
  Generate code for the medium model: the program is linked in the lower 2
! \&\s-1GB\s0 of the address space.  Small symbols are also placed there.  Symbols
  with sizes larger than \fB\-mlarge\-data\-threshold\fR are put into
! large data or \s-1BSS\s0 sections and can be located above 2GB.  Programs can
  be statically or dynamically linked.
! .IP "\fB\-mcmodel=large\fR" 4
  .IX Item "-mcmodel=large"
  Generate code for the large model.  This model makes no assumptions
  about addresses and sizes of sections.
! .IP "\fB\-maddress\-mode=long\fR" 4
  .IX Item "-maddress-mode=long"
  Generate code for long address mode.  This is only supported for 64\-bit
  and x32 environments.  It is the default address mode for 64\-bit
  environments.
! .IP "\fB\-maddress\-mode=short\fR" 4
  .IX Item "-maddress-mode=short"
  Generate code for short address mode.  This is only supported for 32\-bit
  and x32 environments.  It is the default address mode for 32\-bit and
  x32 environments.
! .IP "\fB\-mneeded\fR" 4
  .IX Item "-mneeded"
  .PD 0
! .IP "\fB\-mno\-needed\fR" 4
  .IX Item "-mno-needed"
  .PD
! Emit \s-1GNU_PROPERTY_X86_ISA_1_NEEDED GNU\s0 property for Linux target to
! indicate the micro-architecture \s-1ISA\s0 level required to execute the binary.
! .IP "\fB\-mno\-direct\-extern\-access\fR" 4
  .IX Item "-mno-direct-extern-access"
! Without \fB\-fpic\fR nor \fB\-fPIC\fR, always use the \s-1GOT\s0 pointer
  to access external symbols.  With \fB\-fpic\fR or \fB\-fPIC\fR,
  treat access to protected symbols as local symbols.  The default is
  \&\fB\-mdirect\-extern\-access\fR.
--- 33146,33203 ----
  it outputs the \f(CW\*(C`.code16gcc\*(C'\fR assembly directive at the beginning of
  the assembly output so that the binary can run in 16\-bit mode.
  .Sp
! The \fB\-miamcu\fR option generates code which conforms to Intel MCU
  psABI.  It requires the \fB\-m32\fR option to be turned on.
! .IP \fB\-mno\-red\-zone\fR 4
  .IX Item "-mno-red-zone"
! Do not use a so\-called "red zone" for x86\-64 code.  The red zone is mandated
! by the x86\-64 ABI; it is a 128\-byte area beyond the location of the
  stack pointer that is not modified by signal or interrupt handlers
  and therefore can be used for temporary data without adjusting the stack
  pointer.  The flag \fB\-mno\-red\-zone\fR disables this red zone.
! .IP \fB\-mcmodel=small\fR 4
  .IX Item "-mcmodel=small"
  Generate code for the small code model: the program and its symbols must
! be linked in the lower 2 GB of the address space.  Pointers are 64 bits.
  Programs can be statically or dynamically linked.  This is the default
  code model.
! .IP \fB\-mcmodel=kernel\fR 4
  .IX Item "-mcmodel=kernel"
  Generate code for the kernel code model.  The kernel runs in the
! negative 2 GB of the address space.
  This model has to be used for Linux kernel code.
! .IP \fB\-mcmodel=medium\fR 4
  .IX Item "-mcmodel=medium"
  Generate code for the medium model: the program is linked in the lower 2
! GB of the address space.  Small symbols are also placed there.  Symbols
  with sizes larger than \fB\-mlarge\-data\-threshold\fR are put into
! large data or BSS sections and can be located above 2GB.  Programs can
  be statically or dynamically linked.
! .IP \fB\-mcmodel=large\fR 4
  .IX Item "-mcmodel=large"
  Generate code for the large model.  This model makes no assumptions
  about addresses and sizes of sections.
! .IP \fB\-maddress\-mode=long\fR 4
  .IX Item "-maddress-mode=long"
  Generate code for long address mode.  This is only supported for 64\-bit
  and x32 environments.  It is the default address mode for 64\-bit
  environments.
! .IP \fB\-maddress\-mode=short\fR 4
  .IX Item "-maddress-mode=short"
  Generate code for short address mode.  This is only supported for 32\-bit
  and x32 environments.  It is the default address mode for 32\-bit and
  x32 environments.
! .IP \fB\-mneeded\fR 4
  .IX Item "-mneeded"
  .PD 0
! .IP \fB\-mno\-needed\fR 4
  .IX Item "-mno-needed"
  .PD
! Emit GNU_PROPERTY_X86_ISA_1_NEEDED GNU property for Linux target to
! indicate the micro\-architecture ISA level required to execute the binary.
! .IP \fB\-mno\-direct\-extern\-access\fR 4
  .IX Item "-mno-direct-extern-access"
! Without \fB\-fpic\fR nor \fB\-fPIC\fR, always use the GOT pointer
  to access external symbols.  With \fB\-fpic\fR or \fB\-fPIC\fR,
  treat access to protected symbols as local symbols.  The default is
  \&\fB\-mdirect\-extern\-access\fR.
*************** treat access to protected symbols as loc
*** 33275,33289 ****
  \&\fB\-mno\-direct\-extern\-access\fR and executable compiled with
  \&\fB\-mdirect\-extern\-access\fR may not be binary compatible if
  protected symbols are used in shared libraries and executable.
! .IP "\fB\-munroll\-only\-small\-loops\fR" 4
  .IX Item "-munroll-only-small-loops"
  Controls conservative small loop unrolling. It is default enabled by
  O2, and unrolls loop with less than 4 insns by 1 time. Explicit
  \&\-f[no\-]unroll\-[all\-]loops would disable this flag to avoid any
  unintended unrolling behavior that user does not want.
! .IP "\fB\-mlam=\fR\fIchoice\fR" 4
  .IX Item "-mlam=choice"
! \&\s-1LAM\s0(linear\-address masking) allows special bits in the pointer to be used
  for metadata. The default is \fBnone\fR. With \fBu48\fR, pointer bits in
  positions 62:48 can be used for metadata; With \fBu57\fR, pointer bits in
  positions 62:57 can be used for metadata.
--- 33206,33220 ----
  \&\fB\-mno\-direct\-extern\-access\fR and executable compiled with
  \&\fB\-mdirect\-extern\-access\fR may not be binary compatible if
  protected symbols are used in shared libraries and executable.
! .IP \fB\-munroll\-only\-small\-loops\fR 4
  .IX Item "-munroll-only-small-loops"
  Controls conservative small loop unrolling. It is default enabled by
  O2, and unrolls loop with less than 4 insns by 1 time. Explicit
  \&\-f[no\-]unroll\-[all\-]loops would disable this flag to avoid any
  unintended unrolling behavior that user does not want.
! .IP \fB\-mlam=\fR\fIchoice\fR 4
  .IX Item "-mlam=choice"
! LAM(linear\-address masking) allows special bits in the pointer to be used
  for metadata. The default is \fBnone\fR. With \fBu48\fR, pointer bits in
  positions 62:48 can be used for metadata; With \fBu57\fR, pointer bits in
  positions 62:57 can be used for metadata.
*************** positions 62:57 can be used for metadata
*** 33292,33356 ****
  .IX Subsection "x86 Windows Options"
  .PP
  These additional options are available for Microsoft Windows targets:
! .IP "\fB\-mconsole\fR" 4
  .IX Item "-mconsole"
  This option
  specifies that a console application is to be generated, by
! instructing the linker to set the \s-1PE\s0 header subsystem type
  required for console applications.
  This option is available for Cygwin and MinGW targets and is
  enabled by default on those targets.
! .IP "\fB\-mdll\fR" 4
  .IX Item "-mdll"
  This option is available for Cygwin and MinGW targets.  It
  specifies that a DLL\-\-\-a dynamic link library\-\-\-is to be
  generated, enabling the selection of the required runtime
  startup object and entry point.
! .IP "\fB\-mnop\-fun\-dllimport\fR" 4
  .IX Item "-mnop-fun-dllimport"
  This option is available for Cygwin and MinGW targets.  It
  specifies that the \f(CW\*(C`dllimport\*(C'\fR attribute should be ignored.
! .IP "\fB\-mthreads\fR" 4
  .IX Item "-mthreads"
  This option is available for MinGW targets. It specifies
! that MinGW-specific thread support is to be used.
! .IP "\fB\-municode\fR" 4
  .IX Item "-municode"
  This option is available for MinGW\-w64 targets.  It causes
  the \f(CW\*(C`UNICODE\*(C'\fR preprocessor macro to be predefined, and
! chooses Unicode-capable runtime startup code.
! .IP "\fB\-mwin32\fR" 4
  .IX Item "-mwin32"
  This option is available for Cygwin and MinGW targets.  It
  specifies that the typical Microsoft Windows predefined macros are to
! be set in the pre-processor, but does not influence the choice
  of runtime library/startup code.
! .IP "\fB\-mwindows\fR" 4
  .IX Item "-mwindows"
  This option is available for Cygwin and MinGW targets.  It
! specifies that a \s-1GUI\s0 application is to be generated by
! instructing the linker to set the \s-1PE\s0 header subsystem type
  appropriately.
! .IP "\fB\-fno\-set\-stack\-executable\fR" 4
  .IX Item "-fno-set-stack-executable"
  This option is available for MinGW targets. It specifies that
! the executable flag for the stack used by nested functions isn't
  set. This is necessary for binaries running in kernel mode of
! Microsoft Windows, as there the User32 \s-1API,\s0 which is used to set executable
! privileges, isn't available.
! .IP "\fB\-fwritable\-relocated\-rdata\fR" 4
  .IX Item "-fwritable-relocated-rdata"
  This option is available for MinGW and Cygwin targets.  It specifies
! that relocated-data in read-only section is put into the \f(CW\*(C`.data\*(C'\fR
  section.  This is a necessary for older runtimes not supporting
! modification of \f(CW\*(C`.rdata\*(C'\fR sections for pseudo-relocation.
! .IP "\fB\-mpe\-aligned\-commons\fR" 4
  .IX Item "-mpe-aligned-commons"
  This option is available for Cygwin and MinGW targets.  It
! specifies that the \s-1GNU\s0 extension to the \s-1PE\s0 file format that
! permits the correct alignment of \s-1COMMON\s0 variables should be
  used when generating code.  It is enabled by default if
! \&\s-1GCC\s0 detects that the target assembler found during configuration
  supports the feature.
  .PP
  See also under \fBx86 Options\fR for standard options.
--- 33223,33287 ----
  .IX Subsection "x86 Windows Options"
  .PP
  These additional options are available for Microsoft Windows targets:
! .IP \fB\-mconsole\fR 4
  .IX Item "-mconsole"
  This option
  specifies that a console application is to be generated, by
! instructing the linker to set the PE header subsystem type
  required for console applications.
  This option is available for Cygwin and MinGW targets and is
  enabled by default on those targets.
! .IP \fB\-mdll\fR 4
  .IX Item "-mdll"
  This option is available for Cygwin and MinGW targets.  It
  specifies that a DLL\-\-\-a dynamic link library\-\-\-is to be
  generated, enabling the selection of the required runtime
  startup object and entry point.
! .IP \fB\-mnop\-fun\-dllimport\fR 4
  .IX Item "-mnop-fun-dllimport"
  This option is available for Cygwin and MinGW targets.  It
  specifies that the \f(CW\*(C`dllimport\*(C'\fR attribute should be ignored.
! .IP \fB\-mthreads\fR 4
  .IX Item "-mthreads"
  This option is available for MinGW targets. It specifies
! that MinGW\-specific thread support is to be used.
! .IP \fB\-municode\fR 4
  .IX Item "-municode"
  This option is available for MinGW\-w64 targets.  It causes
  the \f(CW\*(C`UNICODE\*(C'\fR preprocessor macro to be predefined, and
! chooses Unicode\-capable runtime startup code.
! .IP \fB\-mwin32\fR 4
  .IX Item "-mwin32"
  This option is available for Cygwin and MinGW targets.  It
  specifies that the typical Microsoft Windows predefined macros are to
! be set in the pre\-processor, but does not influence the choice
  of runtime library/startup code.
! .IP \fB\-mwindows\fR 4
  .IX Item "-mwindows"
  This option is available for Cygwin and MinGW targets.  It
! specifies that a GUI application is to be generated by
! instructing the linker to set the PE header subsystem type
  appropriately.
! .IP \fB\-fno\-set\-stack\-executable\fR 4
  .IX Item "-fno-set-stack-executable"
  This option is available for MinGW targets. It specifies that
! the executable flag for the stack used by nested functions isn\*(Aqt
  set. This is necessary for binaries running in kernel mode of
! Microsoft Windows, as there the User32 API, which is used to set executable
! privileges, isn\*(Aqt available.
! .IP \fB\-fwritable\-relocated\-rdata\fR 4
  .IX Item "-fwritable-relocated-rdata"
  This option is available for MinGW and Cygwin targets.  It specifies
! that relocated\-data in read\-only section is put into the \f(CW\*(C`.data\*(C'\fR
  section.  This is a necessary for older runtimes not supporting
! modification of \f(CW\*(C`.rdata\*(C'\fR sections for pseudo\-relocation.
! .IP \fB\-mpe\-aligned\-commons\fR 4
  .IX Item "-mpe-aligned-commons"
  This option is available for Cygwin and MinGW targets.  It
! specifies that the GNU extension to the PE file format that
! permits the correct alignment of COMMON variables should be
  used when generating code.  It is enabled by default if
! GCC detects that the target assembler found during configuration
  supports the feature.
  .PP
  See also under \fBx86 Options\fR for standard options.
*************** See also under \fBx86 Options\fR for sta
*** 33359,33365 ****
  .IX Subsection "Xstormy16 Options"
  .PP
  These options are defined for Xstormy16:
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Choose startup files and linker script suitable for the simulator.
  .PP
--- 33290,33296 ----
  .IX Subsection "Xstormy16 Options"
  .PP
  These options are defined for Xstormy16:
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Choose startup files and linker script suitable for the simulator.
  .PP
*************** Choose startup files and linker script s
*** 33367,33376 ****
  .IX Subsection "Xtensa Options"
  .PP
  These options are supported for Xtensa targets:
! .IP "\fB\-mconst16\fR" 4
  .IX Item "-mconst16"
  .PD 0
! .IP "\fB\-mno\-const16\fR" 4
  .IX Item "-mno-const16"
  .PD
  Enable or disable use of \f(CW\*(C`CONST16\*(C'\fR instructions for loading
--- 33298,33307 ----
  .IX Subsection "Xtensa Options"
  .PP
  These options are supported for Xtensa targets:
! .IP \fB\-mconst16\fR 4
  .IX Item "-mconst16"
  .PD 0
! .IP \fB\-mno\-const16\fR 4
  .IX Item "-mno-const16"
  .PD
  Enable or disable use of \f(CW\*(C`CONST16\*(C'\fR instructions for loading
*************** standard option from Tensilica.  When en
*** 33379,33436 ****
  instructions are always used in place of the standard \f(CW\*(C`L32R\*(C'\fR
  instructions.  The use of \f(CW\*(C`CONST16\*(C'\fR is enabled by default only if
  the \f(CW\*(C`L32R\*(C'\fR instruction is not available.
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
  Enable or disable use of fused multiply/add and multiply/subtract
! instructions in the floating-point option.  This has no effect if the
! floating-point option is not also enabled.  Disabling fused multiply/add
  and multiply/subtract instructions forces the compiler to use separate
  instructions for the multiply and add/subtract operations.  This may be
! desirable in some cases where strict \s-1IEEE\s0 754\-compliant results are
  required: the fused multiply add/subtract instructions do not round the
  intermediate result, thereby producing results with \fImore\fR bits of
! precision than specified by the \s-1IEEE\s0 standard.  Disabling fused multiply
  add/subtract instructions also ensures that the program output is not
! sensitive to the compiler's ability to combine multiply and add/subtract
  operations.
! .IP "\fB\-mserialize\-volatile\fR" 4
  .IX Item "-mserialize-volatile"
  .PD 0
! .IP "\fB\-mno\-serialize\-volatile\fR" 4
  .IX Item "-mno-serialize-volatile"
  .PD
! When this option is enabled, \s-1GCC\s0 inserts \f(CW\*(C`MEMW\*(C'\fR instructions before
  \&\f(CW\*(C`volatile\*(C'\fR memory references to guarantee sequential consistency.
  The default is \fB\-mserialize\-volatile\fR.  Use
  \&\fB\-mno\-serialize\-volatile\fR to omit the \f(CW\*(C`MEMW\*(C'\fR instructions.
! .IP "\fB\-mforce\-no\-pic\fR" 4
  .IX Item "-mforce-no-pic"
! For targets, like GNU/Linux, where all user-mode Xtensa code must be
! position-independent code (\s-1PIC\s0), this option disables \s-1PIC\s0 for compiling
  kernel code.
! .IP "\fB\-mtext\-section\-literals\fR" 4
  .IX Item "-mtext-section-literals"
  .PD 0
! .IP "\fB\-mno\-text\-section\-literals\fR" 4
  .IX Item "-mno-text-section-literals"
  .PD
  These options control the treatment of literal pools.  The default is
  \&\fB\-mno\-text\-section\-literals\fR, which places literals in a separate
  section in the output file.  This allows the literal pool to be placed
! in a data \s-1RAM/ROM,\s0 and it also allows the linker to combine literal
  pools from separate object files to remove redundant literals and
  improve code size.  With \fB\-mtext\-section\-literals\fR, the literals
  are interspersed in the text section in order to keep them as close as
  possible to their references.  This may be necessary for large assembly
  files.  Literals for each function are placed right before that function.
! .IP "\fB\-mauto\-litpools\fR" 4
  .IX Item "-mauto-litpools"
  .PD 0
! .IP "\fB\-mno\-auto\-litpools\fR" 4
  .IX Item "-mno-auto-litpools"
  .PD
  These options control the treatment of literal pools.  The default is
--- 33310,33367 ----
  instructions are always used in place of the standard \f(CW\*(C`L32R\*(C'\fR
  instructions.  The use of \f(CW\*(C`CONST16\*(C'\fR is enabled by default only if
  the \f(CW\*(C`L32R\*(C'\fR instruction is not available.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
  Enable or disable use of fused multiply/add and multiply/subtract
! instructions in the floating\-point option.  This has no effect if the
! floating\-point option is not also enabled.  Disabling fused multiply/add
  and multiply/subtract instructions forces the compiler to use separate
  instructions for the multiply and add/subtract operations.  This may be
! desirable in some cases where strict IEEE 754\-compliant results are
  required: the fused multiply add/subtract instructions do not round the
  intermediate result, thereby producing results with \fImore\fR bits of
! precision than specified by the IEEE standard.  Disabling fused multiply
  add/subtract instructions also ensures that the program output is not
! sensitive to the compiler\*(Aqs ability to combine multiply and add/subtract
  operations.
! .IP \fB\-mserialize\-volatile\fR 4
  .IX Item "-mserialize-volatile"
  .PD 0
! .IP \fB\-mno\-serialize\-volatile\fR 4
  .IX Item "-mno-serialize-volatile"
  .PD
! When this option is enabled, GCC inserts \f(CW\*(C`MEMW\*(C'\fR instructions before
  \&\f(CW\*(C`volatile\*(C'\fR memory references to guarantee sequential consistency.
  The default is \fB\-mserialize\-volatile\fR.  Use
  \&\fB\-mno\-serialize\-volatile\fR to omit the \f(CW\*(C`MEMW\*(C'\fR instructions.
! .IP \fB\-mforce\-no\-pic\fR 4
  .IX Item "-mforce-no-pic"
! For targets, like GNU/Linux, where all user\-mode Xtensa code must be
! position\-independent code (PIC), this option disables PIC for compiling
  kernel code.
! .IP \fB\-mtext\-section\-literals\fR 4
  .IX Item "-mtext-section-literals"
  .PD 0
! .IP \fB\-mno\-text\-section\-literals\fR 4
  .IX Item "-mno-text-section-literals"
  .PD
  These options control the treatment of literal pools.  The default is
  \&\fB\-mno\-text\-section\-literals\fR, which places literals in a separate
  section in the output file.  This allows the literal pool to be placed
! in a data 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 \fB\-mtext\-section\-literals\fR, the literals
  are interspersed in the text section in order to keep them as close as
  possible to their references.  This may be necessary for large assembly
  files.  Literals for each function are placed right before that function.
! .IP \fB\-mauto\-litpools\fR 4
  .IX Item "-mauto-litpools"
  .PD 0
! .IP \fB\-mno\-auto\-litpools\fR 4
  .IX Item "-mno-auto-litpools"
  .PD
  These options control the treatment of literal pools.  The default is
*************** do relaxation and place literals as nece
*** 33444,33472 ****
  assembler to create several literal pools per function and assemble
  very big functions, which may not be possible with
  \&\fB\-mtext\-section\-literals\fR.
! .IP "\fB\-mtarget\-align\fR" 4
  .IX Item "-mtarget-align"
  .PD 0
! .IP "\fB\-mno\-target\-align\fR" 4
  .IX Item "-mno-target-align"
  .PD
! When this option is enabled, \s-1GCC\s0 instructs the assembler to
  automatically align instructions to reduce branch penalties at the
  expense of some code density.  The assembler attempts to widen density
  instructions to align branch targets and the instructions following call
  instructions.  If there are not enough preceding safe density
  instructions to align a target, no widening is performed.  The
  default is \fB\-mtarget\-align\fR.  These options do not affect the
! treatment of auto-aligned instructions like \f(CW\*(C`LOOP\*(C'\fR, which the
  assembler always aligns, either by widening density instructions or
! by inserting \s-1NOP\s0 instructions.
! .IP "\fB\-mlongcalls\fR" 4
  .IX Item "-mlongcalls"
  .PD 0
! .IP "\fB\-mno\-longcalls\fR" 4
  .IX Item "-mno-longcalls"
  .PD
! When this option is enabled, \s-1GCC\s0 instructs the assembler to translate
  direct calls to indirect calls unless it can determine that the target
  of a direct call is in the range allowed by the call instruction.  This
  translation typically occurs for calls to functions in other source
--- 33375,33403 ----
  assembler to create several literal pools per function and assemble
  very big functions, which may not be possible with
  \&\fB\-mtext\-section\-literals\fR.
! .IP \fB\-mtarget\-align\fR 4
  .IX Item "-mtarget-align"
  .PD 0
! .IP \fB\-mno\-target\-align\fR 4
  .IX Item "-mno-target-align"
  .PD
! When this option is enabled, GCC instructs the assembler to
  automatically align instructions to reduce branch penalties at the
  expense of some code density.  The assembler attempts to widen density
  instructions to align branch targets and the instructions following call
  instructions.  If there are not enough preceding safe density
  instructions to align a target, no widening is performed.  The
  default is \fB\-mtarget\-align\fR.  These options do not affect the
! treatment of auto\-aligned instructions like \f(CW\*(C`LOOP\*(C'\fR, which the
  assembler always aligns, either by widening density instructions or
! by inserting NOP instructions.
! .IP \fB\-mlongcalls\fR 4
  .IX Item "-mlongcalls"
  .PD 0
! .IP \fB\-mno\-longcalls\fR 4
  .IX Item "-mno-longcalls"
  .PD
! When this option is enabled, 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
*************** instruction into an \f(CW\*(C`L32R\*(C'\
*** 33475,33507 ****
  The default is \fB\-mno\-longcalls\fR.  This option should be used in
  programs where the call target can potentially be out of range.  This
  option is implemented in the assembler, not the compiler, so the
! assembly code generated by \s-1GCC\s0 still shows direct call
  instructions\-\-\-look at the disassembled object code to see the actual
  instructions.  Note that the assembler uses an indirect call for
! every cross-file call, not just those that really are out of range.
! .IP "\fB\-mabi=\fR\fIname\fR" 4
  .IX Item "-mabi=name"
! Generate code for the specified \s-1ABI.\s0  Permissible values are: \fBcall0\fR,
! \&\fBwindowed\fR.  Default \s-1ABI\s0 is chosen by the Xtensa core configuration.
! .IP "\fB\-mabi=call0\fR" 4
  .IX Item "-mabi=call0"
  When this option is enabled function parameters are passed in registers
  \&\f(CW\*(C`a2\*(C'\fR through \f(CW\*(C`a7\*(C'\fR, registers \f(CW\*(C`a12\*(C'\fR through \f(CW\*(C`a15\*(C'\fR are
! caller-saved, and register \f(CW\*(C`a15\*(C'\fR may be used as a frame pointer.
! When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_XTENSA_CALL0_ABI_\|_\*(C'\fR is defined.
! .IP "\fB\-mabi=windowed\fR" 4
  .IX Item "-mabi=windowed"
  When this option is enabled function parameters are passed in registers
  \&\f(CW\*(C`a10\*(C'\fR through \f(CW\*(C`a15\*(C'\fR, and called function rotates register window
  by 8 registers on entry so that its arguments are found in registers
  \&\f(CW\*(C`a2\*(C'\fR through \f(CW\*(C`a7\*(C'\fR.  Register \f(CW\*(C`a7\*(C'\fR may be used as a frame
  pointer.  Register window is rotated 8 registers back upon return.
! When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_XTENSA_WINDOWED_ABI_\|_\*(C'\fR is defined.
! .IP "\fB\-mextra\-l32r\-costs=\fR\fIn\fR" 4
  .IX Item "-mextra-l32r-costs=n"
! Specify an extra cost of instruction \s-1RAM/ROM\s0 access for \f(CW\*(C`L32R\*(C'\fR
  instructions, in clock cycles.  This affects, when optimizing for speed,
  whether loading a constant from literal pool using \f(CW\*(C`L32R\*(C'\fR or
  synthesizing the constant from a small one with a couple of arithmetic
--- 33406,33438 ----
  The default is \fB\-mno\-longcalls\fR.  This option should be used in
  programs where the call target can potentially be out of range.  This
  option is implemented in the assembler, not the compiler, so the
! assembly code generated by GCC still shows direct call
  instructions\-\-\-look at the disassembled object code to see the actual
  instructions.  Note that the assembler uses an indirect call for
! every cross\-file call, not just those that really are out of range.
! .IP \fB\-mabi=\fR\fIname\fR 4
  .IX Item "-mabi=name"
! Generate code for the specified ABI.  Permissible values are: \fBcall0\fR,
! \&\fBwindowed\fR.  Default ABI is chosen by the Xtensa core configuration.
! .IP \fB\-mabi=call0\fR 4
  .IX Item "-mabi=call0"
  When this option is enabled function parameters are passed in registers
  \&\f(CW\*(C`a2\*(C'\fR through \f(CW\*(C`a7\*(C'\fR, registers \f(CW\*(C`a12\*(C'\fR through \f(CW\*(C`a15\*(C'\fR are
! caller\-saved, and register \f(CW\*(C`a15\*(C'\fR may be used as a frame pointer.
! When this version of the ABI is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_XTENSA_CALL0_ABI_\|_\*(C'\fR is defined.
! .IP \fB\-mabi=windowed\fR 4
  .IX Item "-mabi=windowed"
  When this option is enabled function parameters are passed in registers
  \&\f(CW\*(C`a10\*(C'\fR through \f(CW\*(C`a15\*(C'\fR, and called function rotates register window
  by 8 registers on entry so that its arguments are found in registers
  \&\f(CW\*(C`a2\*(C'\fR through \f(CW\*(C`a7\*(C'\fR.  Register \f(CW\*(C`a7\*(C'\fR may be used as a frame
  pointer.  Register window is rotated 8 registers back upon return.
! When this version of the ABI is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_XTENSA_WINDOWED_ABI_\|_\*(C'\fR is defined.
! .IP \fB\-mextra\-l32r\-costs=\fR\fIn\fR 4
  .IX Item "-mextra-l32r-costs=n"
! Specify an extra cost of instruction RAM/ROM access for \f(CW\*(C`L32R\*(C'\fR
  instructions, in clock cycles.  This affects, when optimizing for speed,
  whether loading a constant from literal pool using \f(CW\*(C`L32R\*(C'\fR or
  synthesizing the constant from a small one with a couple of arithmetic
*************** instructions.  The default value is 0.
*** 33511,33519 ****
  .IX Subsection "zSeries Options"
  .PP
  These are listed under
! .SH "ENVIRONMENT"
  .IX Header "ENVIRONMENT"
! This section describes several environment variables that affect how \s-1GCC\s0
  operates.  Some of them work by specifying directories or prefixes to use
  when searching for various kinds of files.  Some are used to specify other
  aspects of the compilation environment.
--- 33442,33450 ----
  .IX Subsection "zSeries Options"
  .PP
  These are listed under
! .SH ENVIRONMENT
  .IX Header "ENVIRONMENT"
! 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.
*************** aspects of the compilation environment.
*** 33521,33586 ****
  Note that you can also specify places to search using options such as
  \&\fB\-B\fR, \fB\-I\fR and \fB\-L\fR.  These
  take precedence over places specified using environment variables, which
! in turn take precedence over those specified by the configuration of \s-1GCC.\s0
! .IP "\fB\s-1LANG\s0\fR" 4
  .IX Item "LANG"
  .PD 0
! .IP "\fB\s-1LC_CTYPE\s0\fR" 4
  .IX Item "LC_CTYPE"
! .IP "\fB\s-1LC_MESSAGES\s0\fR" 4
  .IX Item "LC_MESSAGES"
! .IP "\fB\s-1LC_ALL\s0\fR" 4
  .IX Item "LC_ALL"
  .PD
! These environment variables control the way that \s-1GCC\s0 uses
! localization information which allows \s-1GCC\s0 to work with different
! national conventions.  \s-1GCC\s0 inspects the locale categories
! \&\fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR if it has been configured to do
  so.  These locale categories can be set to any value supported by your
  installation.  A typical value is \fBen_GB.UTF\-8\fR for English in the United
! Kingdom encoded in \s-1UTF\-8.\s0
  .Sp
! The \fB\s-1LC_CTYPE\s0\fR environment variable specifies character
! classification.  \s-1GCC\s0 uses it to determine the character boundaries in
  a string; this is needed for some multibyte encodings that contain quote
  and escape characters that are otherwise interpreted as a string
  end or escape.
  .Sp
! The \fB\s-1LC_MESSAGES\s0\fR environment variable specifies the language to
  use in diagnostic messages.
  .Sp
! If the \fB\s-1LC_ALL\s0\fR environment variable is set, it overrides the value
! of \fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR; otherwise, \fB\s-1LC_CTYPE\s0\fR
! and \fB\s-1LC_MESSAGES\s0\fR default to the value of the \fB\s-1LANG\s0\fR
! environment variable.  If none of these variables are set, \s-1GCC\s0
  defaults to traditional C English behavior.
! .IP "\fB\s-1TMPDIR\s0\fR" 4
  .IX Item "TMPDIR"
! If \fB\s-1TMPDIR\s0\fR is set, it specifies the directory to use for temporary
! files.  \s-1GCC\s0 uses temporary files to hold the output of one stage of
  compilation which is to be used as input to the next stage: for example,
  the output of the preprocessor, which is the input to the compiler
  proper.
! .IP "\fB\s-1GCC_COMPARE_DEBUG\s0\fR" 4
  .IX Item "GCC_COMPARE_DEBUG"
! Setting \fB\s-1GCC_COMPARE_DEBUG\s0\fR is nearly equivalent to passing
  \&\fB\-fcompare\-debug\fR to the compiler driver.  See the documentation
  of this option for more details.
! .IP "\fB\s-1GCC_EXEC_PREFIX\s0\fR" 4
  .IX Item "GCC_EXEC_PREFIX"
! If \fB\s-1GCC_EXEC_PREFIX\s0\fR is set, it specifies a prefix to use in the
  names of the subprograms executed by the compiler.  No slash is added
  when this prefix is combined with the name of a subprogram, but you can
  specify a prefix that ends with a slash if you wish.
  .Sp
! If \fB\s-1GCC_EXEC_PREFIX\s0\fR is not set, \s-1GCC\s0 attempts to figure out
  an appropriate prefix to use based on the pathname it is invoked with.
  .Sp
! If \s-1GCC\s0 cannot find the subprogram using the specified prefix, it
  tries looking in the usual places for the subprogram.
  .Sp
! The default value of \fB\s-1GCC_EXEC_PREFIX\s0\fR is
! \&\fI\fIprefix\fI/lib/gcc/\fR where \fIprefix\fR is the prefix to
  the installed compiler. In many cases \fIprefix\fR is the value
  of \f(CW\*(C`prefix\*(C'\fR when you ran the \fIconfigure\fR script.
  .Sp
--- 33452,33517 ----
  Note that you can also specify places to search using options such as
  \&\fB\-B\fR, \fB\-I\fR and \fB\-L\fR.  These
  take precedence over places specified using environment variables, which
! in turn take precedence over those specified by the configuration of GCC.
! .IP \fBLANG\fR 4
  .IX Item "LANG"
  .PD 0
! .IP \fBLC_CTYPE\fR 4
  .IX Item "LC_CTYPE"
! .IP \fBLC_MESSAGES\fR 4
  .IX Item "LC_MESSAGES"
! .IP \fBLC_ALL\fR 4
  .IX Item "LC_ALL"
  .PD
! These environment variables control the way that GCC uses
! localization information which allows GCC to work with different
! national conventions.  GCC inspects the locale categories
! \&\fBLC_CTYPE\fR and \fBLC_MESSAGES\fR if it has been configured to do
  so.  These locale categories can be set to any value supported by your
  installation.  A typical value is \fBen_GB.UTF\-8\fR for English in the United
! Kingdom encoded in UTF\-8.
  .Sp
! The \fBLC_CTYPE\fR environment variable specifies character
! classification.  GCC uses it to determine the character boundaries in
  a string; this is needed for some multibyte encodings that contain quote
  and escape characters that are otherwise interpreted as a string
  end or escape.
  .Sp
! The \fBLC_MESSAGES\fR environment variable specifies the language to
  use in diagnostic messages.
  .Sp
! If the \fBLC_ALL\fR environment variable is set, it overrides the value
! of \fBLC_CTYPE\fR and \fBLC_MESSAGES\fR; otherwise, \fBLC_CTYPE\fR
! and \fBLC_MESSAGES\fR default to the value of the \fBLANG\fR
! environment variable.  If none of these variables are set, GCC
  defaults to traditional C English behavior.
! .IP \fBTMPDIR\fR 4
  .IX Item "TMPDIR"
! If \fBTMPDIR\fR 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.
! .IP \fBGCC_COMPARE_DEBUG\fR 4
  .IX Item "GCC_COMPARE_DEBUG"
! Setting \fBGCC_COMPARE_DEBUG\fR is nearly equivalent to passing
  \&\fB\-fcompare\-debug\fR to the compiler driver.  See the documentation
  of this option for more details.
! .IP \fBGCC_EXEC_PREFIX\fR 4
  .IX Item "GCC_EXEC_PREFIX"
! If \fBGCC_EXEC_PREFIX\fR is set, it specifies a prefix to use in the
  names of the subprograms executed by the compiler.  No slash is added
  when this prefix is combined with the name of a subprogram, but you can
  specify a prefix that ends with a slash if you wish.
  .Sp
! If \fBGCC_EXEC_PREFIX\fR is not set, GCC attempts to figure out
  an appropriate prefix to use based on the pathname it is invoked with.
  .Sp
! If GCC cannot find the subprogram using the specified prefix, it
  tries looking in the usual places for the subprogram.
  .Sp
! The default value of \fBGCC_EXEC_PREFIX\fR is
! \&\fIprefix/lib/gcc/\fR where \fIprefix\fR is the prefix to
  the installed compiler. In many cases \fIprefix\fR is the value
  of \f(CW\*(C`prefix\*(C'\fR when you ran the \fIconfigure\fR script.
  .Sp
*************** used for linking.
*** 33592,33658 ****
  In addition, the prefix is used in an unusual way in finding the
  directories to search for header files.  For each of the standard
  directories whose name normally begins with \fB/usr/local/lib/gcc\fR
! (more precisely, with the value of \fB\s-1GCC_INCLUDE_DIR\s0\fR), \s-1GCC\s0 tries
  replacing that beginning with the specified prefix to produce an
! alternate directory name.  Thus, with \fB\-Bfoo/\fR, \s-1GCC\s0 searches
  \&\fIfoo/bar\fR just before it searches the standard directory 
  \&\fI/usr/local/lib/bar\fR.
  If a standard directory begins with the configured
  \&\fIprefix\fR then the value of \fIprefix\fR is replaced by
! \&\fB\s-1GCC_EXEC_PREFIX\s0\fR when looking for header files.
! .IP "\fB\s-1COMPILER_PATH\s0\fR" 4
  .IX Item "COMPILER_PATH"
! The value of \fB\s-1COMPILER_PATH\s0\fR is a colon-separated list of
! directories, much like \fB\s-1PATH\s0\fR.  \s-1GCC\s0 tries the directories thus
  specified when searching for subprograms, if it cannot find the
! subprograms using \fB\s-1GCC_EXEC_PREFIX\s0\fR.
! .IP "\fB\s-1LIBRARY_PATH\s0\fR" 4
  .IX Item "LIBRARY_PATH"
! The value of \fB\s-1LIBRARY_PATH\s0\fR is a colon-separated list of
! directories, much like \fB\s-1PATH\s0\fR.  When configured as a native compiler,
! \&\s-1GCC\s0 tries the directories thus specified when searching for special
! linker files, if it cannot find them using \fB\s-1GCC_EXEC_PREFIX\s0\fR.  Linking
! using \s-1GCC\s0 also uses these directories when searching for ordinary
  libraries for the \fB\-l\fR option (but directories specified with
  \&\fB\-L\fR come first).
! .IP "\fB\s-1LANG\s0\fR" 4
  .IX Item "LANG"
  This variable is used to pass locale information to the compiler.  One way in
  which this information is used is to determine the character set to be used
! when character literals, string literals and comments are parsed in C and \*(C+.
  When the compiler is configured to allow multibyte characters,
! the following values for \fB\s-1LANG\s0\fR are recognized:
  .RS 4
! .IP "\fBC\-JIS\fR" 4
  .IX Item "C-JIS"
! Recognize \s-1JIS\s0 characters.
! .IP "\fBC\-SJIS\fR" 4
  .IX Item "C-SJIS"
! Recognize \s-1SJIS\s0 characters.
! .IP "\fBC\-EUCJP\fR" 4
  .IX Item "C-EUCJP"
! Recognize \s-1EUCJP\s0 characters.
  .RE
  .RS 4
  .Sp
! If \fB\s-1LANG\s0\fR is not defined, or if it has some other value, then the
  compiler uses \f(CW\*(C`mblen\*(C'\fR and \f(CW\*(C`mbtowc\*(C'\fR as defined by the default locale to
  recognize and translate multibyte characters.
  .RE
! .IP "\fB\s-1GCC_EXTRA_DIAGNOSTIC_OUTPUT\s0\fR" 4
  .IX Item "GCC_EXTRA_DIAGNOSTIC_OUTPUT"
! If \fB\s-1GCC_EXTRA_DIAGNOSTIC_OUTPUT\s0\fR is set to one of the following values,
! then additional text will be emitted to stderr when fix-it hints are
  emitted.  \fB\-fdiagnostics\-parseable\-fixits\fR and
  \&\fB\-fno\-diagnostics\-parseable\-fixits\fR take precedence over this
  environment variable.
  .RS 4
! .IP "\fBfixits\-v1\fR" 4
  .IX Item "fixits-v1"
! Emit parseable fix-it hints, equivalent to
  \&\fB\-fdiagnostics\-parseable\-fixits\fR.  In particular, columns are
  expressed as a count of bytes, starting at byte 1 for the initial column.
! .IP "\fBfixits\-v2\fR" 4
  .IX Item "fixits-v2"
  As \f(CW\*(C`fixits\-v1\*(C'\fR, but columns are expressed as display columns,
  as per \fB\-fdiagnostics\-column\-unit=display\fR.
--- 33523,33589 ----
  In addition, the prefix is used in an unusual way in finding the
  directories to search for header files.  For each of the standard
  directories whose name normally begins with \fB/usr/local/lib/gcc\fR
! (more precisely, with the value of \fBGCC_INCLUDE_DIR\fR), GCC tries
  replacing that beginning with the specified prefix to produce an
! alternate directory name.  Thus, with \fB\-Bfoo/\fR, GCC searches
  \&\fIfoo/bar\fR just before it searches the standard directory 
  \&\fI/usr/local/lib/bar\fR.
  If a standard directory begins with the configured
  \&\fIprefix\fR then the value of \fIprefix\fR is replaced by
! \&\fBGCC_EXEC_PREFIX\fR when looking for header files.
! .IP \fBCOMPILER_PATH\fR 4
  .IX Item "COMPILER_PATH"
! The value of \fBCOMPILER_PATH\fR is a colon\-separated list of
! directories, much like \fBPATH\fR.  GCC tries the directories thus
  specified when searching for subprograms, if it cannot find the
! subprograms using \fBGCC_EXEC_PREFIX\fR.
! .IP \fBLIBRARY_PATH\fR 4
  .IX Item "LIBRARY_PATH"
! The value of \fBLIBRARY_PATH\fR is a colon\-separated list of
! directories, much like \fBPATH\fR.  When configured as a native compiler,
! GCC tries the directories thus specified when searching for special
! linker files, if it cannot find them using \fBGCC_EXEC_PREFIX\fR.  Linking
! using GCC also uses these directories when searching for ordinary
  libraries for the \fB\-l\fR option (but directories specified with
  \&\fB\-L\fR come first).
! .IP \fBLANG\fR 4
  .IX Item "LANG"
  This variable is used to pass locale information to the compiler.  One way in
  which this information is used is to determine the character set to be used
! when character literals, string literals and comments are parsed in C and C++.
  When the compiler is configured to allow multibyte characters,
! the following values for \fBLANG\fR are recognized:
  .RS 4
! .IP \fBC\-JIS\fR 4
  .IX Item "C-JIS"
! Recognize JIS characters.
! .IP \fBC\-SJIS\fR 4
  .IX Item "C-SJIS"
! Recognize SJIS characters.
! .IP \fBC\-EUCJP\fR 4
  .IX Item "C-EUCJP"
! Recognize EUCJP characters.
  .RE
  .RS 4
  .Sp
! If \fBLANG\fR is not defined, or if it has some other value, then the
  compiler uses \f(CW\*(C`mblen\*(C'\fR and \f(CW\*(C`mbtowc\*(C'\fR as defined by the default locale to
  recognize and translate multibyte characters.
  .RE
! .IP \fBGCC_EXTRA_DIAGNOSTIC_OUTPUT\fR 4
  .IX Item "GCC_EXTRA_DIAGNOSTIC_OUTPUT"
! If \fBGCC_EXTRA_DIAGNOSTIC_OUTPUT\fR is set to one of the following values,
! then additional text will be emitted to stderr when fix\-it hints are
  emitted.  \fB\-fdiagnostics\-parseable\-fixits\fR and
  \&\fB\-fno\-diagnostics\-parseable\-fixits\fR take precedence over this
  environment variable.
  .RS 4
! .IP \fBfixits\-v1\fR 4
  .IX Item "fixits-v1"
! Emit parseable fix\-it hints, equivalent to
  \&\fB\-fdiagnostics\-parseable\-fixits\fR.  In particular, columns are
  expressed as a count of bytes, starting at byte 1 for the initial column.
! .IP \fBfixits\-v2\fR 4
  .IX Item "fixits-v2"
  As \f(CW\*(C`fixits\-v1\*(C'\fR, but columns are expressed as display columns,
  as per \fB\-fdiagnostics\-column\-unit=display\fR.
*************** as per \fB\-fdiagnostics\-column\-unit=d
*** 33662,33684 ****
  .PP
  Some additional environment variables affect the behavior of the
  preprocessor.
! .IP "\fB\s-1CPATH\s0\fR" 4
  .IX Item "CPATH"
  .PD 0
! .IP "\fBC_INCLUDE_PATH\fR" 4
  .IX Item "C_INCLUDE_PATH"
! .IP "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4
  .IX Item "CPLUS_INCLUDE_PATH"
! .IP "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4
  .IX Item "OBJC_INCLUDE_PATH"
  .PD
! Each variable's value is a list of directories separated by a special
! character, much like \fB\s-1PATH\s0\fR, in which to look for header files.
! The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, is target-dependent and
! determined at \s-1GCC\s0 build time.  For Microsoft Windows-based targets it is a
  semicolon, and for almost all other targets it is a colon.
  .Sp
! \&\fB\s-1CPATH\s0\fR specifies a list of directories to be searched as if
  specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
  options on the command line.  This environment variable is used
  regardless of which language is being preprocessed.
--- 33593,33615 ----
  .PP
  Some additional environment variables affect the behavior of the
  preprocessor.
! .IP \fBCPATH\fR 4
  .IX Item "CPATH"
  .PD 0
! .IP \fBC_INCLUDE_PATH\fR 4
  .IX Item "C_INCLUDE_PATH"
! .IP \fBCPLUS_INCLUDE_PATH\fR 4
  .IX Item "CPLUS_INCLUDE_PATH"
! .IP \fBOBJC_INCLUDE_PATH\fR 4
  .IX Item "OBJC_INCLUDE_PATH"
  .PD
! Each variable\*(Aqs value is a list of directories separated by a special
! character, much like \fBPATH\fR, in which to look for header files.
! The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, 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.
  .Sp
! \&\fBCPATH\fR specifies a list of directories to be searched as if
  specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
  options on the command line.  This environment variable is used
  regardless of which language is being preprocessed.
*************** paths given with \fB\-isystem\fR options
*** 33691,33706 ****
  In all these variables, an empty element instructs the compiler to
  search its current working directory.  Empty elements can appear at the
  beginning or end of a path.  For instance, if the value of
! \&\fB\s-1CPATH\s0\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
  effect as \fB\-I.\ \-I/special/include\fR.
! .IP "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4
  .IX Item "DEPENDENCIES_OUTPUT"
  If this variable is set, its value specifies how to output
! dependencies for Make based on the non-system header files processed
  by the compiler.  System header files are ignored in the dependency
  output.
  .Sp
! The value of \fB\s-1DEPENDENCIES_OUTPUT\s0\fR can be just a file name, in
  which case the Make rules are written to that file, guessing the target
  name from the source file name.  Or the value can have the form
  \&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
--- 33622,33637 ----
  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
! \&\fBCPATH\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
  effect as \fB\-I.\ \-I/special/include\fR.
! .IP \fBDEPENDENCIES_OUTPUT\fR 4
  .IX Item "DEPENDENCIES_OUTPUT"
  If this variable is set, its value specifies how to output
! dependencies for Make based on the non\-system header files processed
  by the compiler.  System header files are ignored in the dependency
  output.
  .Sp
! The value of \fBDEPENDENCIES_OUTPUT\fR can be just a file name, in
  which case the Make rules are written to that file, guessing the target
  name from the source file name.  Or the value can have the form
  \&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
*************** file \fIfile\fR using \fItarget\fR as th
*** 33709,33750 ****
  In other words, this environment variable is equivalent to combining
  the options \fB\-MM\fR and \fB\-MF\fR,
  with an optional \fB\-MT\fR switch too.
! .IP "\fB\s-1SUNPRO_DEPENDENCIES\s0\fR" 4
  .IX Item "SUNPRO_DEPENDENCIES"
! This variable is the same as \fB\s-1DEPENDENCIES_OUTPUT\s0\fR (see above),
  except that system header files are not ignored, so it implies
  \&\fB\-M\fR rather than \fB\-MM\fR.  However, the dependence on the
  main input file is omitted.
! .IP "\fB\s-1SOURCE_DATE_EPOCH\s0\fR" 4
  .IX Item "SOURCE_DATE_EPOCH"
! If this variable is set, its value specifies a \s-1UNIX\s0 timestamp to be
  used in replacement of the current date and time in the \f(CW\*(C`_\|_DATE_\|_\*(C'\fR
  and \f(CW\*(C`_\|_TIME_\|_\*(C'\fR macros, so that the embedded timestamps become
  reproducible.
  .Sp
! The value of \fB\s-1SOURCE_DATE_EPOCH\s0\fR must be a \s-1UNIX\s0 timestamp,
  defined as the number of seconds (excluding leap seconds) since
! 01 Jan 1970 00:00:00 represented in \s-1ASCII\s0; identical to the output of
  \&\f(CW\*(C`date +%s\*(C'\fR on GNU/Linux and other systems that support the
  \&\f(CW%s\fR extension in the \f(CW\*(C`date\*(C'\fR command.
  .Sp
  The value should be a known timestamp such as the last modification
  time of the source or package and it should be set by the build
  process.
! .SH "BUGS"
  .IX Header "BUGS"
  For instructions on reporting bugs, see
  <\fBhttps://gcc.gnu.org/bugs/\fR>.
! .SH "FOOTNOTES"
  .IX Header "FOOTNOTES"
! .IP "1." 4
  On some systems, \fBgcc \-shared\fR
  needs to build supplementary stub code for constructors to work.  On
! multi-libbed systems, \fBgcc \-shared\fR must select the correct support
  libraries to link against.  Failing to supply the correct flags may lead
  to subtle defects.  Supplying them in cases where they are not necessary
  is innocuous.  \fB\-shared\fR suppresses the addition of startup code
! to alter the floating-point environment as done with \fB\-ffast\-math\fR,
  \&\fB\-Ofast\fR or \fB\-funsafe\-math\-optimizations\fR on some targets.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
--- 33640,33681 ----
  In other words, this environment variable is equivalent to combining
  the options \fB\-MM\fR and \fB\-MF\fR,
  with an optional \fB\-MT\fR switch too.
! .IP \fBSUNPRO_DEPENDENCIES\fR 4
  .IX Item "SUNPRO_DEPENDENCIES"
! This variable is the same as \fBDEPENDENCIES_OUTPUT\fR (see above),
  except that system header files are not ignored, so it implies
  \&\fB\-M\fR rather than \fB\-MM\fR.  However, the dependence on the
  main input file is omitted.
! .IP \fBSOURCE_DATE_EPOCH\fR 4
  .IX Item "SOURCE_DATE_EPOCH"
! If this variable is set, its value specifies a UNIX timestamp to be
  used in replacement of the current date and time in the \f(CW\*(C`_\|_DATE_\|_\*(C'\fR
  and \f(CW\*(C`_\|_TIME_\|_\*(C'\fR macros, so that the embedded timestamps become
  reproducible.
  .Sp
! The value of \fBSOURCE_DATE_EPOCH\fR must be a UNIX timestamp,
  defined as the number of seconds (excluding leap seconds) since
! 01 Jan 1970 00:00:00 represented in ASCII; identical to the output of
  \&\f(CW\*(C`date +%s\*(C'\fR on GNU/Linux and other systems that support the
  \&\f(CW%s\fR extension in the \f(CW\*(C`date\*(C'\fR command.
  .Sp
  The value should be a known timestamp such as the last modification
  time of the source or package and it should be set by the build
  process.
! .SH BUGS
  .IX Header "BUGS"
  For instructions on reporting bugs, see
  <\fBhttps://gcc.gnu.org/bugs/\fR>.
! .SH FOOTNOTES
  .IX Header "FOOTNOTES"
! .IP 1. 4
  On some systems, \fBgcc \-shared\fR
  needs to build supplementary stub code for constructors to work.  On
! multi\-libbed systems, \fBgcc \-shared\fR must select the correct support
  libraries to link against.  Failing to supply the correct flags may lead
  to subtle defects.  Supplying them in cases where they are not necessary
  is innocuous.  \fB\-shared\fR suppresses the addition of startup code
! to alter the floating\-point environment as done with \fB\-ffast\-math\fR,
  \&\fB\-Ofast\fR or \fB\-funsafe\-math\-optimizations\fR on some targets.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
*************** to alter the floating-point environment
*** 33752,33781 ****
  \&\fBcpp\fR\|(1), \fBgcov\fR\|(1), \fBas\fR\|(1), \fBld\fR\|(1), \fBgdb\fR\|(1)
  and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIas\fR,
  \&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
! .SH "AUTHOR"
  .IX Header "AUTHOR"
  See the Info entry for \fBgcc\fR, or
  <\fBhttps://gcc.gnu.org/onlinedocs/gcc/Contributors.html\fR>,
! for contributors to \s-1GCC.\s0
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 1988\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
! Free Software\*(R", the Front-Cover texts being (a) (see below), and with
! the Back-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The \s-1FSF\s0's Front-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The \s-1FSF\s0's Back-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
--- 33683,33712 ----
  \&\fBcpp\fR\|(1), \fBgcov\fR\|(1), \fBas\fR\|(1), \fBld\fR\|(1), \fBgdb\fR\|(1)
  and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIas\fR,
  \&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
! .SH AUTHOR
  .IX Header "AUTHOR"
  See the Info entry for \fBgcc\fR, or
  <\fBhttps://gcc.gnu.org/onlinedocs/gcc/Contributors.html\fR>,
! for contributors to GCC.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 1988\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the GNU Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being "GNU General Public License" and "Funding
! Free Software", the Front\-Cover texts being (a) (see below), and with
! the Back\-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The FSF\*(Aqs Front\-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The FSF\*(Aqs Back\-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
diff -Nrcpad gcc-13.4.0/gcc/doc/gcc.1 gcc-13.5.0-RC-20260904/gcc/doc/gcc.1
*** gcc-13.4.0/gcc/doc/gcc.1	Thu Jun  5 16:21:57 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gcc.1	Fri Sep  4 07:50:37 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,161 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GCC 1"
! .TH GCC 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gcc \- GNU project C and C++ compiler
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
  gcc [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR] [\fB\-std=\fR\fIstandard\fR]
      [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
      [\fB\-W\fR\fIwarn\fR...] [\fB\-Wpedantic\fR]
      [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
      [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
!     [\fB\-f\fR\fIoption\fR...] [\fB\-m\fR\fImachine-option\fR...]
      [\fB\-o\fR \fIoutfile\fR] [@\fIfile\fR] \fIinfile\fR...
  .PP
  Only the most useful options are listed here; see below for the
  remainder.  \fBg++\fR accepts mostly the same options as \fBgcc\fR.
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
! When you invoke \s-1GCC,\s0 it normally does preprocessing, compilation,
! assembly and linking.  The \*(L"overall options\*(R" allow you to stop this
  process at an intermediate stage.  For example, the \fB\-c\fR option
  says not to run the linker.  Then the output consists of object files
  output by the assembler.
--- 53,86 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GCC 1"
! .TH GCC 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gcc \- GNU project C and C++ compiler
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
  gcc [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR] [\fB\-std=\fR\fIstandard\fR]
      [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
      [\fB\-W\fR\fIwarn\fR...] [\fB\-Wpedantic\fR]
      [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
      [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
!     [\fB\-f\fR\fIoption\fR...] [\fB\-m\fR\fImachine\-option\fR...]
      [\fB\-o\fR \fIoutfile\fR] [@\fIfile\fR] \fIinfile\fR...
  .PP
  Only the most useful options are listed here; see below for the
  remainder.  \fBg++\fR accepts mostly the same options as \fBgcc\fR.
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
! When you invoke 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 \fB\-c\fR option
  says not to run the linker.  Then the output consists of object files
  output by the assembler.
*************** control the preprocessor and others the
*** 165,188 ****
  options control the assembler and linker; most of these are not
  documented here, since you rarely need to use any of them.
  .PP
! Most of the command-line options that you can use with \s-1GCC\s0 are useful
  for C programs; when an option is only useful with another language
! (usually \*(C+), the explanation says so explicitly.  If the description
  for a particular option does not mention a source language, you can use
  that option with all supported languages.
  .PP
! The usual way to run \s-1GCC\s0 is to run the executable called \fBgcc\fR, or
! \&\fImachine\fR\fB\-gcc\fR when cross-compiling, or
! \&\fImachine\fR\fB\-gcc\-\fR\fIversion\fR to run a specific version of \s-1GCC.\s0
! When you compile \*(C+ programs, you should invoke \s-1GCC\s0 as \fBg++\fR 
  instead.
  .PP
  The \fBgcc\fR program accepts options and file names as operands.  Many
! options have multi-letter names; therefore multiple single-letter options
  may \fInot\fR be grouped: \fB\-dv\fR is very different from \fB\-d\ \-v\fR.
  .PP
  You can mix options and other arguments.  For the most part, the order
! you use doesn't matter.  Order does matter when you use several
  options of the same kind; for example, if you specify \fB\-L\fR more
  than once, the directories are searched in the order specified.  Also,
  the placement of the \fB\-l\fR option is significant.
--- 90,113 ----
  options control the assembler and linker; most of these are not
  documented here, since you rarely need to use any of them.
  .PP
! Most of the command\-line options that you can use with 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.
  .PP
! The usual way to run GCC is to run the executable called \fBgcc\fR, or
! \&\fImachine\fR\fB\-gcc\fR when cross\-compiling, or
! \&\fImachine\fR\fB\-gcc\-\fR\fIversion\fR to run a specific version of GCC.
! When you compile C++ programs, you should invoke GCC as \fBg++\fR 
  instead.
  .PP
  The \fBgcc\fR program accepts options and file names as operands.  Many
! options have multi\-letter names; therefore multiple single\-letter options
  may \fInot\fR be grouped: \fB\-dv\fR is very different from \fB\-d\ \-v\fR.
  .PP
  You can mix options and other arguments.  For the most part, the order
! you use doesn\*(Aqt matter.  Order does matter when you use several
  options of the same kind; for example, if you specify \fB\-L\fR more
  than once, the directories are searched in the order specified.  Also,
  the placement of the \fB\-l\fR option is significant.
*************** integers followed by a byte size suffix
*** 205,214 ****
  such as \f(CW\*(C`kB\*(C'\fR and \f(CW\*(C`KiB\*(C'\fR for kilobyte and kibibyte, respectively,
  \&\f(CW\*(C`MB\*(C'\fR and \f(CW\*(C`MiB\*(C'\fR for megabyte and mebibyte, \f(CW\*(C`GB\*(C'\fR and
  \&\f(CW\*(C`GiB\*(C'\fR for gigabyte and gigibyte, and so on.  Such arguments are
! designated by \fIbyte-size\fR in the following text.  Refer to the \s-1NIST,
! IEC,\s0 and other relevant national and international standards for the full
  listing and explanation of the binary and decimal byte size prefixes.
! .SH "OPTIONS"
  .IX Header "OPTIONS"
  .SS "Option Summary"
  .IX Subsection "Option Summary"
--- 130,139 ----
  such as \f(CW\*(C`kB\*(C'\fR and \f(CW\*(C`KiB\*(C'\fR for kilobyte and kibibyte, respectively,
  \&\f(CW\*(C`MB\*(C'\fR and \f(CW\*(C`MiB\*(C'\fR for megabyte and mebibyte, \f(CW\*(C`GB\*(C'\fR and
  \&\f(CW\*(C`GiB\*(C'\fR for gigabyte and gigibyte, and so on.  Such arguments are
! designated by \fIbyte\-size\fR in the following text.  Refer to the NIST,
! IEC, and other relevant national and international standards for the full
  listing and explanation of the binary and decimal byte size prefixes.
! .SH OPTIONS
  .IX Header "OPTIONS"
  .SS "Option Summary"
  .IX Subsection "Option Summary"
*************** in the following sections.
*** 233,245 ****
  \&\-flax\-vector\-conversions  \-fms\-extensions
  \&\-foffload=\fR\fIarg\fR  \fB\-foffload\-options=\fR\fIarg\fR
  \&\fB\-fopenacc  \-fopenacc\-dim=\fR\fIgeom\fR
! \&\fB\-fopenmp  \-fopenmp\-simd  \-fopenmp\-target\-simd\-clone\fR[\fB=\fR\fIdevice-type\fR]
  \&\fB\-fpermitted\-flt\-eval\-methods=\fR\fIstandard\fR
  \&\fB\-fplan9\-extensions  \-fsigned\-bitfields  \-funsigned\-bitfields
  \&\-fsigned\-char  \-funsigned\-char \-fstrict\-flex\-arrays[=\fR\fIn\fR\fB]
  \&\-fsso\-struct=\fR\fIendianness\fR
! .IP "\fI\*(C+ Language Options\fR" 4
! .IX Item " Language Options"
  \&\fB\-fabi\-version=\fR\fIn\fR  \fB\-fno\-access\-control
  \&\-faligned\-new=\fR\fIn\fR  \fB\-fargs\-in\-order=\fR\fIn\fR  \fB\-fchar8_t  \-fcheck\-new
  \&\-fconstexpr\-depth=\fR\fIn\fR  \fB\-fconstexpr\-cache\-depth=\fR\fIn\fR
--- 158,170 ----
  \&\-flax\-vector\-conversions  \-fms\-extensions
  \&\-foffload=\fR\fIarg\fR  \fB\-foffload\-options=\fR\fIarg\fR
  \&\fB\-fopenacc  \-fopenacc\-dim=\fR\fIgeom\fR
! \&\fB\-fopenmp  \-fopenmp\-simd  \-fopenmp\-target\-simd\-clone\fR[\fB=\fR\fIdevice\-type\fR]
  \&\fB\-fpermitted\-flt\-eval\-methods=\fR\fIstandard\fR
  \&\fB\-fplan9\-extensions  \-fsigned\-bitfields  \-funsigned\-bitfields
  \&\-fsigned\-char  \-funsigned\-char \-fstrict\-flex\-arrays[=\fR\fIn\fR\fB]
  \&\-fsso\-struct=\fR\fIendianness\fR
! .IP "\fIC++ Language Options\fR" 4
! .IX Item "C++ Language Options"
  \&\fB\-fabi\-version=\fR\fIn\fR  \fB\-fno\-access\-control
  \&\-faligned\-new=\fR\fIn\fR  \fB\-fargs\-in\-order=\fR\fIn\fR  \fB\-fchar8_t  \-fcheck\-new
  \&\-fconstexpr\-depth=\fR\fIn\fR  \fB\-fconstexpr\-cache\-depth=\fR\fIn\fR
*************** in the following sections.
*** 300,308 ****
  \&\-Wno\-terminate  \-Wuseless\-cast  \-Wno\-vexing\-parse
  \&\-Wvirtual\-inheritance
  \&\-Wno\-virtual\-move\-assign  \-Wvolatile  \-Wzero\-as\-null\-pointer\-constant\fR
! .IP "\fIObjective-C and Objective\-\*(C+ Language Options\fR" 4
! .IX Item "Objective-C and Objective- Language Options"
! \&\fB\-fconstant\-string\-class=\fR\fIclass-name\fR
  \&\fB\-fgnu\-runtime  \-fnext\-runtime
  \&\-fno\-nil\-receivers
  \&\-fobjc\-abi\-version=\fR\fIn\fR
--- 225,233 ----
  \&\-Wno\-terminate  \-Wuseless\-cast  \-Wno\-vexing\-parse
  \&\-Wvirtual\-inheritance
  \&\-Wno\-virtual\-move\-assign  \-Wvolatile  \-Wzero\-as\-null\-pointer\-constant\fR
! .IP "\fIObjective\-C and Objective\-C++ Language Options\fR" 4
! .IX Item "Objective-C and Objective-C++ Language Options"
! \&\fB\-fconstant\-string\-class=\fR\fIclass\-name\fR
  \&\fB\-fgnu\-runtime  \-fnext\-runtime
  \&\-fno\-nil\-receivers
  \&\-fobjc\-abi\-version=\fR\fIn\fR
*************** in the following sections.
*** 325,334 ****
  .IX Item "Diagnostic Message Formatting Options"
  \&\fB\-fmessage\-length=\fR\fIn\fR
  \&\fB\-fdiagnostics\-plain\-output
! \&\-fdiagnostics\-show\-location=\fR[\fBonce\fR|\fBevery-line\fR]
  \&\fB\-fdiagnostics\-color=\fR[\fBauto\fR|\fBnever\fR|\fBalways\fR]
  \&\fB\-fdiagnostics\-urls=\fR[\fBauto\fR|\fBnever\fR|\fBalways\fR]
! \&\fB\-fdiagnostics\-format=\fR[\fBtext\fR|\fBsarif-stderr\fR|\fBsarif-file\fR|\fBjson\fR|\fBjson-stderr\fR|\fBjson-file\fR]
  \&\fB\-fno\-diagnostics\-show\-option  \-fno\-diagnostics\-show\-caret
  \&\-fno\-diagnostics\-show\-labels  \-fno\-diagnostics\-show\-line\-numbers
  \&\-fno\-diagnostics\-show\-cwe
--- 250,259 ----
  .IX Item "Diagnostic Message Formatting Options"
  \&\fB\-fmessage\-length=\fR\fIn\fR
  \&\fB\-fdiagnostics\-plain\-output
! \&\-fdiagnostics\-show\-location=\fR[\fBonce\fR|\fBevery\-line\fR]
  \&\fB\-fdiagnostics\-color=\fR[\fBauto\fR|\fBnever\fR|\fBalways\fR]
  \&\fB\-fdiagnostics\-urls=\fR[\fBauto\fR|\fBnever\fR|\fBalways\fR]
! \&\fB\-fdiagnostics\-format=\fR[\fBtext\fR|\fBsarif\-stderr\fR|\fBsarif\-file\fR|\fBjson\fR|\fBjson\-stderr\fR|\fBjson\-file\fR]
  \&\fB\-fno\-diagnostics\-show\-option  \-fno\-diagnostics\-show\-caret
  \&\-fno\-diagnostics\-show\-labels  \-fno\-diagnostics\-show\-line\-numbers
  \&\-fno\-diagnostics\-show\-cwe
*************** in the following sections.
*** 336,342 ****
  \&\-fdiagnostics\-minimum\-margin\-width=\fR\fIwidth\fR
  \&\fB\-fdiagnostics\-parseable\-fixits  \-fdiagnostics\-generate\-patch
  \&\-fdiagnostics\-show\-template\-tree  \-fno\-elide\-type
! \&\-fdiagnostics\-path\-format=\fR[\fBnone\fR|\fBseparate-events\fR|\fBinline-events\fR]
  \&\fB\-fdiagnostics\-show\-path\-depths
  \&\-fno\-show\-column
  \&\-fdiagnostics\-column\-unit=\fR[\fBdisplay\fR|\fBbyte\fR]
--- 261,267 ----
  \&\-fdiagnostics\-minimum\-margin\-width=\fR\fIwidth\fR
  \&\fB\-fdiagnostics\-parseable\-fixits  \-fdiagnostics\-generate\-patch
  \&\-fdiagnostics\-show\-template\-tree  \-fno\-elide\-type
! \&\-fdiagnostics\-path\-format=\fR[\fBnone\fR|\fBseparate\-events\fR|\fBinline\-events\fR]
  \&\fB\-fdiagnostics\-show\-path\-depths
  \&\-fno\-show\-column
  \&\-fdiagnostics\-column\-unit=\fR[\fBdisplay\fR|\fBbyte\fR]
*************** in the following sections.
*** 348,355 ****
  \&\-pedantic\-errors
  \&\-w  \-Wextra  \-Wall  \-Wabi=\fR\fIn\fR
  \&\fB\-Waddress  \-Wno\-address\-of\-packed\-member  \-Waggregate\-return
! \&\-Walloc\-size\-larger\-than=\fR\fIbyte-size\fR  \fB\-Walloc\-zero
! \&\-Walloca  \-Walloca\-larger\-than=\fR\fIbyte-size\fR
  \&\fB\-Wno\-aggressive\-loop\-optimizations
  \&\-Warith\-conversion
  \&\-Warray\-bounds  \-Warray\-bounds=\fR\fIn\fR  \fB\-Warray\-compare
--- 273,280 ----
  \&\-pedantic\-errors
  \&\-w  \-Wextra  \-Wall  \-Wabi=\fR\fIn\fR
  \&\fB\-Waddress  \-Wno\-address\-of\-packed\-member  \-Waggregate\-return
! \&\-Walloc\-size\-larger\-than=\fR\fIbyte\-size\fR  \fB\-Walloc\-zero
! \&\-Walloca  \-Walloca\-larger\-than=\fR\fIbyte\-size\fR
  \&\fB\-Wno\-aggressive\-loop\-optimizations
  \&\-Warith\-conversion
  \&\-Warray\-bounds  \-Warray\-bounds=\fR\fIn\fR  \fB\-Warray\-compare
*************** in the following sections.
*** 384,390 ****
  \&\-Wformat\-nonliteral  \-Wformat\-overflow=\fR\fIn\fR
  \&\fB\-Wformat\-security  \-Wformat\-signedness  \-Wformat\-truncation=\fR\fIn\fR
  \&\fB\-Wformat\-y2k  \-Wframe\-address
! \&\-Wframe\-larger\-than=\fR\fIbyte-size\fR  \fB\-Wno\-free\-nonheap\-object
  \&\-Wno\-if\-not\-aligned  \-Wno\-ignored\-attributes
  \&\-Wignored\-qualifiers  \-Wno\-incompatible\-pointer\-types
  \&\-Wimplicit  \-Wimplicit\-fallthrough  \-Wimplicit\-fallthrough=\fR\fIn\fR
--- 309,315 ----
  \&\-Wformat\-nonliteral  \-Wformat\-overflow=\fR\fIn\fR
  \&\fB\-Wformat\-security  \-Wformat\-signedness  \-Wformat\-truncation=\fR\fIn\fR
  \&\fB\-Wformat\-y2k  \-Wframe\-address
! \&\-Wframe\-larger\-than=\fR\fIbyte\-size\fR  \fB\-Wno\-free\-nonheap\-object
  \&\-Wno\-if\-not\-aligned  \-Wno\-ignored\-attributes
  \&\-Wignored\-qualifiers  \-Wno\-incompatible\-pointer\-types
  \&\-Wimplicit  \-Wimplicit\-fallthrough  \-Wimplicit\-fallthrough=\fR\fIn\fR
*************** in the following sections.
*** 393,399 ****
  \&\-Winit\-self  \-Winline  \-Wno\-int\-conversion  \-Wint\-in\-bool\-context
  \&\-Wno\-int\-to\-pointer\-cast  \-Wno\-invalid\-memory\-model
  \&\-Winvalid\-pch  \-Winvalid\-utf8  \-Wno\-unicode  \-Wjump\-misses\-init
! \&\-Wlarger\-than=\fR\fIbyte-size\fR  \fB\-Wlogical\-not\-parentheses  \-Wlogical\-op
  \&\-Wlong\-long  \-Wno\-lto\-type\-mismatch \-Wmain  \-Wmaybe\-uninitialized
  \&\-Wmemset\-elt\-size  \-Wmemset\-transposed\-args
  \&\-Wmisleading\-indentation  \-Wmissing\-attributes  \-Wmissing\-braces
--- 318,324 ----
  \&\-Winit\-self  \-Winline  \-Wno\-int\-conversion  \-Wint\-in\-bool\-context
  \&\-Wno\-int\-to\-pointer\-cast  \-Wno\-invalid\-memory\-model
  \&\-Winvalid\-pch  \-Winvalid\-utf8  \-Wno\-unicode  \-Wjump\-misses\-init
! \&\-Wlarger\-than=\fR\fIbyte\-size\fR  \fB\-Wlogical\-not\-parentheses  \-Wlogical\-op
  \&\-Wlong\-long  \-Wno\-lto\-type\-mismatch \-Wmain  \-Wmaybe\-uninitialized
  \&\-Wmemset\-elt\-size  \-Wmemset\-transposed\-args
  \&\-Wmisleading\-indentation  \-Wmissing\-attributes  \-Wmissing\-braces
*************** in the following sections.
*** 419,425 ****
  \&\-Wno\-sizeof\-array\-argument
  \&\-Wsizeof\-array\-div
  \&\-Wsizeof\-pointer\-div  \-Wsizeof\-pointer\-memaccess
! \&\-Wstack\-protector  \-Wstack\-usage=\fR\fIbyte-size\fR  \fB\-Wstrict\-aliasing
  \&\-Wstrict\-aliasing=n  \-Wstrict\-overflow  \-Wstrict\-overflow=\fR\fIn\fR
  \&\fB\-Wstring\-compare
  \&\-Wno\-stringop\-overflow \-Wno\-stringop\-overread
--- 344,350 ----
  \&\-Wno\-sizeof\-array\-argument
  \&\-Wsizeof\-array\-div
  \&\-Wsizeof\-pointer\-div  \-Wsizeof\-pointer\-memaccess
! \&\-Wstack\-protector  \-Wstack\-usage=\fR\fIbyte\-size\fR  \fB\-Wstrict\-aliasing
  \&\-Wstrict\-aliasing=n  \-Wstrict\-overflow  \-Wstrict\-overflow=\fR\fIn\fR
  \&\fB\-Wstring\-compare
  \&\-Wno\-stringop\-overflow \-Wno\-stringop\-overread
*************** in the following sections.
*** 439,445 ****
  \&\-Wunused\-value  \-Wunused\-variable
  \&\-Wno\-varargs  \-Wvariadic\-macros
  \&\-Wvector\-operation\-performance
! \&\-Wvla  \-Wvla\-larger\-than=\fR\fIbyte-size\fR  \fB\-Wno\-vla\-larger\-than
  \&\-Wvolatile\-register\-var  \-Wwrite\-strings
  \&\-Wxor\-used\-as\-pow
  \&\-Wzero\-length\-bounds\fR
--- 364,370 ----
  \&\-Wunused\-value  \-Wunused\-variable
  \&\-Wno\-varargs  \-Wvariadic\-macros
  \&\-Wvector\-operation\-performance
! \&\-Wvla  \-Wvla\-larger\-than=\fR\fIbyte\-size\fR  \fB\-Wno\-vla\-larger\-than
  \&\-Wvolatile\-register\-var  \-Wwrite\-strings
  \&\-Wxor\-used\-as\-pow
  \&\-Wzero\-length\-bounds\fR
*************** in the following sections.
*** 515,521 ****
  \&\-Wno\-analyzer\-va\-list\-use\-after\-va\-end
  \&\-Wno\-analyzer\-write\-to\-const
  \&\-Wno\-analyzer\-write\-to\-string\-literal\fR
! .IP "\fIC and Objective-C-only Warning Options\fR" 4
  .IX Item "C and Objective-C-only Warning Options"
  \&\fB\-Wbad\-function\-cast  \-Wmissing\-declarations
  \&\-Wmissing\-parameter\-type  \-Wmissing\-prototypes  \-Wnested\-externs
--- 440,446 ----
  \&\-Wno\-analyzer\-va\-list\-use\-after\-va\-end
  \&\-Wno\-analyzer\-write\-to\-const
  \&\-Wno\-analyzer\-write\-to\-string\-literal\fR
! .IP "\fIC and Objective\-C\-only Warning Options\fR" 4
  .IX Item "C and Objective-C-only Warning Options"
  \&\fB\-Wbad\-function\-cast  \-Wmissing\-declarations
  \&\-Wmissing\-parameter\-type  \-Wmissing\-prototypes  \-Wnested\-externs
*************** in the following sections.
*** 540,546 ****
  \&\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR  \fB\-fdebug\-types\-section
  \&\-fno\-eliminate\-unused\-debug\-types
  \&\-femit\-struct\-debug\-baseonly  \-femit\-struct\-debug\-reduced
! \&\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR]
  \&\fB\-fno\-eliminate\-unused\-debug\-symbols  \-femit\-class\-debug\-always
  \&\-fno\-merge\-debug\-strings  \-fno\-dwarf2\-cfi\-asm
  \&\-fvar\-tracking  \-fvar\-tracking\-assignments\fR
--- 465,471 ----
  \&\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR  \fB\-fdebug\-types\-section
  \&\-fno\-eliminate\-unused\-debug\-types
  \&\-femit\-struct\-debug\-baseonly  \-femit\-struct\-debug\-reduced
! \&\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec\-list\fR]
  \&\fB\-fno\-eliminate\-unused\-debug\-symbols  \-femit\-class\-debug\-always
  \&\-fno\-merge\-debug\-strings  \-fno\-dwarf2\-cfi\-asm
  \&\-fvar\-tracking  \-fvar\-tracking\-assignments\fR
*************** in the following sections.
*** 646,652 ****
  \&\fB\-fprofile\-note=\fR\fIpath\fR \fB\-fprofile\-prefix\-path=\fR\fIpath\fR
  \&\fB\-fprofile\-update=\fR\fImethod\fR \fB\-fprofile\-filter\-files=\fR\fIregex\fR
  \&\fB\-fprofile\-exclude\-files=\fR\fIregex\fR
! \&\fB\-fprofile\-reproducible=\fR[\fBmultithreaded\fR|\fBparallel-runs\fR|\fBserial\fR]
  \&\fB\-fsanitize=\fR\fIstyle\fR  \fB\-fsanitize\-recover  \-fsanitize\-recover=\fR\fIstyle\fR
  \&\fB\-fsanitize\-trap   \-fsanitize\-trap=\fR\fIstyle\fR
  \&\fB\-fasan\-shadow\-offset=\fR\fInumber\fR  \fB\-fsanitize\-sections=\fR\fIs1\fR\fB,\fR\fIs2\fR\fB,...
--- 571,577 ----
  \&\fB\-fprofile\-note=\fR\fIpath\fR \fB\-fprofile\-prefix\-path=\fR\fIpath\fR
  \&\fB\-fprofile\-update=\fR\fImethod\fR \fB\-fprofile\-filter\-files=\fR\fIregex\fR
  \&\fB\-fprofile\-exclude\-files=\fR\fIregex\fR
! \&\fB\-fprofile\-reproducible=\fR[\fBmultithreaded\fR|\fBparallel\-runs\fR|\fBserial\fR]
  \&\fB\-fsanitize=\fR\fIstyle\fR  \fB\-fsanitize\-recover  \-fsanitize\-recover=\fR\fIstyle\fR
  \&\fB\-fsanitize\-trap   \-fsanitize\-trap=\fR\fIstyle\fR
  \&\fB\-fasan\-shadow\-offset=\fR\fInumber\fR  \fB\-fsanitize\-sections=\fR\fIs1\fR\fB,\fR\fIs2\fR\fB,...
*************** in the following sections.
*** 687,693 ****
  \&\fB\-Wa,\fR\fIoption\fR  \fB\-Xassembler\fR \fIoption\fR
  .IP "\fILinker Options\fR" 4
  .IX Item "Linker Options"
! \&\fIobject-file-name\fR  \fB\-fuse\-ld=\fR\fIlinker\fR  \fB\-l\fR\fIlibrary\fR
  \&\fB\-nostartfiles  \-nodefaultlibs  \-nolibc  \-nostdlib  \-nostdlib++
  \&\-e\fR \fIentry\fR  \fB\-\-entry=\fR\fIentry\fR
  \&\fB\-pie  \-pthread  \-r  \-rdynamic
--- 612,618 ----
  \&\fB\-Wa,\fR\fIoption\fR  \fB\-Xassembler\fR \fIoption\fR
  .IP "\fILinker Options\fR" 4
  .IX Item "Linker Options"
! \&\fIobject\-file\-name\fR  \fB\-fuse\-ld=\fR\fIlinker\fR  \fB\-l\fR\fIlibrary\fR
  \&\fB\-nostartfiles  \-nodefaultlibs  \-nolibc  \-nostdlib  \-nostdlib++
  \&\-e\fR \fIentry\fR  \fB\-\-entry=\fR\fIentry\fR
  \&\fB\-pie  \-pthread  \-r  \-rdynamic
*************** in the following sections.
*** 729,740 ****
  \&\fB\-d\fR\fIletters\fR  \fB\-dumpspecs  \-dumpmachine  \-dumpversion
  \&\-dumpfullversion  \-fcallgraph\-info\fR[\fB=su,da\fR]
  \&\fB\-fchecking  \-fchecking=\fR\fIn\fR
! \&\fB\-fdbg\-cnt\-list  \-fdbg\-cnt=\fR\fIcounter-value-list\fR
  \&\fB\-fdisable\-ipa\-\fR\fIpass_name\fR
  \&\fB\-fdisable\-rtl\-\fR\fIpass_name\fR
! \&\fB\-fdisable\-rtl\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR
  \&\fB\-fdisable\-tree\-\fR\fIpass_name\fR
! \&\fB\-fdisable\-tree\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR
  \&\fB\-fdump\-debug  \-fdump\-earlydebug
  \&\-fdump\-noaddr  \-fdump\-unnumbered  \-fdump\-unnumbered\-links
  \&\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR]
--- 654,665 ----
  \&\fB\-d\fR\fIletters\fR  \fB\-dumpspecs  \-dumpmachine  \-dumpversion
  \&\-dumpfullversion  \-fcallgraph\-info\fR[\fB=su,da\fR]
  \&\fB\-fchecking  \-fchecking=\fR\fIn\fR
! \&\fB\-fdbg\-cnt\-list  \-fdbg\-cnt=\fR\fIcounter\-value\-list\fR
  \&\fB\-fdisable\-ipa\-\fR\fIpass_name\fR
  \&\fB\-fdisable\-rtl\-\fR\fIpass_name\fR
! \&\fB\-fdisable\-rtl\-\fR\fIpass\-name\fR\fB=\fR\fIrange\-list\fR
  \&\fB\-fdisable\-tree\-\fR\fIpass_name\fR
! \&\fB\-fdisable\-tree\-\fR\fIpass\-name\fR\fB=\fR\fIrange\-list\fR
  \&\fB\-fdump\-debug  \-fdump\-earlydebug
  \&\-fdump\-noaddr  \-fdump\-unnumbered  \-fdump\-unnumbered\-links
  \&\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR]
*************** in the following sections.
*** 752,758 ****
  \&\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR
  \&\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]  \fB\-fcompare\-debug\-second
  \&\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR
! \&\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR
  \&\fB\-fira\-verbose=\fR\fIn\fR
  \&\fB\-flto\-report  \-flto\-report\-wpa  \-fmem\-report\-wpa
  \&\-fmem\-report  \-fpre\-ipa\-mem\-report  \-fpost\-ipa\-mem\-report
--- 677,683 ----
  \&\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR
  \&\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]  \fB\-fcompare\-debug\-second
  \&\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR
! \&\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR
  \&\fB\-fira\-verbose=\fR\fIn\fR
  \&\fB\-flto\-report  \-flto\-report\-wpa  \-fmem\-report\-wpa
  \&\-fmem\-report  \-fpre\-ipa\-mem\-report  \-fpost\-ipa\-mem\-report
*************** in the following sections.
*** 767,773 ****
  \&\-print\-prog\-name=\fR\fIprogram\fR  \fB\-print\-search\-dirs  \-Q
  \&\-print\-sysroot  \-print\-sysroot\-headers\-suffix
  \&\-save\-temps  \-save\-temps=cwd  \-save\-temps=obj  \-time\fR[\fB=\fR\fIfile\fR]
! .IP "\fIMachine-Dependent Options\fR" 4
  .IX Item "Machine-Dependent Options"
  \&\fIAArch64 Options\fR
  \&\fB\-mabi=\fR\fIname\fR  \fB\-mbig\-endian  \-mlittle\-endian
--- 692,698 ----
  \&\-print\-prog\-name=\fR\fIprogram\fR  \fB\-print\-search\-dirs  \-Q
  \&\-print\-sysroot  \-print\-sysroot\-headers\-suffix
  \&\-save\-temps  \-save\-temps=cwd  \-save\-temps=obj  \-time\fR[\fB=\fR\fIfile\fR]
! .IP "\fIMachine\-Dependent Options\fR" 4
  .IX Item "Machine-Dependent Options"
  \&\fIAArch64 Options\fR
  \&\fB\-mabi=\fR\fIname\fR  \fB\-mbig\-endian  \-mlittle\-endian
*************** in the following sections.
*** 781,787 ****
  \&\-mlow\-precision\-recip\-sqrt  \-mlow\-precision\-sqrt  \-mlow\-precision\-div
  \&\-mpc\-relative\-literal\-loads
  \&\-msign\-return\-address=\fR\fIscope\fR
! \&\fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR
  \&\fB+\fR\fIb\-key\fR\fB]|\fR\fIbti\fR
  \&\fB\-mharden\-sls=\fR\fIopts\fR
  \&\fB\-march=\fR\fIname\fR  \fB\-mcpu=\fR\fIname\fR  \fB\-mtune=\fR\fIname\fR
--- 706,712 ----
  \&\-mlow\-precision\-recip\-sqrt  \-mlow\-precision\-sqrt  \-mlow\-precision\-div
  \&\-mpc\-relative\-literal\-loads
  \&\-msign\-return\-address=\fR\fIscope\fR
! \&\fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR
  \&\fB+\fR\fIb\-key\fR\fB]|\fR\fIbti\fR
  \&\fB\-mharden\-sls=\fR\fIopts\fR
  \&\fB\-march=\fR\fIname\fR  \fB\-mcpu=\fR\fIname\fR  \fB\-mtune=\fR\fIname\fR
*************** in the following sections.
*** 798,807 ****
  \&\-mfp\-mode=\fR\fImode\fR  \fB\-mvect\-double  \-max\-vect\-align=\fR\fInum\fR
  \&\fB\-msplit\-vecmove\-early  \-m1reg\-\fR\fIreg\fR
  .Sp
! \&\fI\s-1AMD GCN\s0 Options\fR
  \&\fB\-march=\fR\fIgpu\fR \fB\-mtune=\fR\fIgpu\fR \fB\-mstack\-size=\fR\fIbytes\fR
  .Sp
! \&\fI\s-1ARC\s0 Options\fR
  \&\fB\-mbarrel\-shifter  \-mjli\-always
  \&\-mcpu=\fR\fIcpu\fR  \fB\-mA6  \-mARC600  \-mA7  \-mARC700
  \&\-mdpfp  \-mdpfp\-compact  \-mdpfp\-fast  \-mno\-dpfp\-lrsr
--- 723,732 ----
  \&\-mfp\-mode=\fR\fImode\fR  \fB\-mvect\-double  \-max\-vect\-align=\fR\fInum\fR
  \&\fB\-msplit\-vecmove\-early  \-m1reg\-\fR\fIreg\fR
  .Sp
! \&\fIAMD GCN Options\fR
  \&\fB\-march=\fR\fIgpu\fR \fB\-mtune=\fR\fIgpu\fR \fB\-mstack\-size=\fR\fIbytes\fR
  .Sp
! \&\fIARC Options\fR
  \&\fB\-mbarrel\-shifter  \-mjli\-always
  \&\-mcpu=\fR\fIcpu\fR  \fB\-mA6  \-mARC600  \-mA7  \-mARC700
  \&\-mdpfp  \-mdpfp\-compact  \-mdpfp\-fast  \-mno\-dpfp\-lrsr
*************** in the following sections.
*** 821,827 ****
  \&\-munalign\-prob\-threshold=\fR\fIprobability\fR  \fB\-mmpy\-option=\fR\fImulto\fR
  \&\fB\-mdiv\-rem  \-mcode\-density  \-mll64  \-mfpu=\fR\fIfpu\fR  \fB\-mrf16  \-mbranch\-index\fR
  .Sp
! \&\fI\s-1ARM\s0 Options\fR
  \&\fB\-mapcs\-frame  \-mno\-apcs\-frame
  \&\-mabi=\fR\fIname\fR
  \&\fB\-mapcs\-stack\-check  \-mno\-apcs\-stack\-check
--- 746,752 ----
  \&\-munalign\-prob\-threshold=\fR\fIprobability\fR  \fB\-mmpy\-option=\fR\fImulto\fR
  \&\fB\-mdiv\-rem  \-mcode\-density  \-mll64  \-mfpu=\fR\fIfpu\fR  \fB\-mrf16  \-mbranch\-index\fR
  .Sp
! \&\fIARM Options\fR
  \&\fB\-mapcs\-frame  \-mno\-apcs\-frame
  \&\-mabi=\fR\fIname\fR
  \&\fB\-mapcs\-stack\-check  \-mno\-apcs\-stack\-check
*************** in the following sections.
*** 861,870 ****
  \&\-mfix\-cmse\-cve\-2021\-35465
  \&\-mstack\-protector\-guard=\fR\fIguard\fR \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR
  \&\fB\-mfdpic
! \&\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR\fB]
! [+\fR\fIbti\fR\fB]|\fR\fIbti\fR\fB[+\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR\fB]]\fR
  .Sp
! \&\fI\s-1AVR\s0 Options\fR
  \&\fB\-mmcu=\fR\fImcu\fR  \fB\-mabsdata  \-maccumulate\-args
  \&\-mbranch\-cost=\fR\fIcost\fR
  \&\fB\-mcall\-prologues  \-mgas\-isr\-prologues  \-mint8
--- 786,795 ----
  \&\-mfix\-cmse\-cve\-2021\-35465
  \&\-mstack\-protector\-guard=\fR\fIguard\fR \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR
  \&\fB\-mfdpic
! \&\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR\fB]
! [+\fR\fIbti\fR\fB]|\fR\fIbti\fR\fB[+\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR\fB]]\fR
  .Sp
! \&\fIAVR Options\fR
  \&\fB\-mmcu=\fR\fImcu\fR  \fB\-mabsdata  \-maccumulate\-args
  \&\-mbranch\-cost=\fR\fIcost\fR
  \&\fB\-mcall\-prologues  \-mgas\-isr\-prologues  \-mint8
*************** in the following sections.
*** 888,896 ****
  .Sp
  \&\fIC6X Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian  \-march=\fR\fIcpu\fR
! \&\fB\-msim  \-msdata=\fR\fIsdata-type\fR
  .Sp
! \&\fI\s-1CRIS\s0 Options\fR
  \&\fB\-mcpu=\fR\fIcpu\fR  \fB\-march=\fR\fIcpu\fR
  \&\fB\-mtune=\fR\fIcpu\fR \fB\-mmax\-stack\-frame=\fR\fIn\fR
  \&\fB\-metrax4  \-metrax100  \-mpdebug  \-mcc\-init  \-mno\-side\-effects
--- 813,821 ----
  .Sp
  \&\fIC6X Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian  \-march=\fR\fIcpu\fR
! \&\fB\-msim  \-msdata=\fR\fIsdata\-type\fR
  .Sp
! \&\fICRIS Options\fR
  \&\fB\-mcpu=\fR\fIcpu\fR  \fB\-march=\fR\fIcpu\fR
  \&\fB\-mtune=\fR\fIcpu\fR \fB\-mmax\-stack\-frame=\fR\fIn\fR
  \&\fB\-metrax4  \-metrax100  \-mpdebug  \-mcc\-init  \-mno\-side\-effects
*************** in the following sections.
*** 937,948 ****
  \&\-whatsloaded  \-F  \-gused  \-gfull  \-mmacosx\-version\-min=\fR\fIversion\fR
  \&\fB\-mkernel  \-mone\-byte\-bool\fR
  .Sp
! \&\fI\s-1DEC\s0 Alpha Options\fR
  \&\fB\-mno\-fp\-regs  \-msoft\-float
  \&\-mieee  \-mieee\-with\-inexact  \-mieee\-conformant
  \&\-mfp\-trap\-mode=\fR\fImode\fR  \fB\-mfp\-rounding\-mode=\fR\fImode\fR
  \&\fB\-mtrap\-precision=\fR\fImode\fR  \fB\-mbuild\-constants
! \&\-mcpu=\fR\fIcpu-type\fR  \fB\-mtune=\fR\fIcpu-type\fR
  \&\fB\-mbwx  \-mmax  \-mfix  \-mcix
  \&\-mfloat\-vax  \-mfloat\-ieee
  \&\-mexplicit\-relocs  \-msmall\-data  \-mlarge\-data
--- 862,873 ----
  \&\-whatsloaded  \-F  \-gused  \-gfull  \-mmacosx\-version\-min=\fR\fIversion\fR
  \&\fB\-mkernel  \-mone\-byte\-bool\fR
  .Sp
! \&\fIDEC Alpha Options\fR
  \&\fB\-mno\-fp\-regs  \-msoft\-float
  \&\-mieee  \-mieee\-with\-inexact  \-mieee\-conformant
  \&\-mfp\-trap\-mode=\fR\fImode\fR  \fB\-mfp\-rounding\-mode=\fR\fImode\fR
  \&\fB\-mtrap\-precision=\fR\fImode\fR  \fB\-mbuild\-constants
! \&\-mcpu=\fR\fIcpu\-type\fR  \fB\-mtune=\fR\fIcpu\-type\fR
  \&\fB\-mbwx  \-mmax  \-mfix  \-mcix
  \&\-mfloat\-vax  \-mfloat\-ieee
  \&\-mexplicit\-relocs  \-msmall\-data  \-mlarge\-data
*************** in the following sections.
*** 954,966 ****
  \&\fB\-mframe\-limit=\fR\fIbytes\fR \fB\-mxbpf \-mco\-re \-mno\-co\-re
  \&\-mjmpext \-mjmp32 \-malu32 \-mcpu=\fR\fIversion\fR
  .Sp
! \&\fI\s-1FR30\s0 Options\fR
  \&\fB\-msmall\-model  \-mno\-lsim\fR
  .Sp
! \&\fI\s-1FT32\s0 Options\fR
  \&\fB\-msim  \-mlra  \-mnodiv  \-mft32b  \-mcompress  \-mnopm\fR
  .Sp
! \&\fI\s-1FRV\s0 Options\fR
  \&\fB\-mgpr\-32  \-mgpr\-64  \-mfpr\-32  \-mfpr\-64
  \&\-mhard\-float  \-msoft\-float
  \&\-malloc\-cc  \-mfixed\-cc  \-mdword  \-mno\-dword
--- 879,891 ----
  \&\fB\-mframe\-limit=\fR\fIbytes\fR \fB\-mxbpf \-mco\-re \-mno\-co\-re
  \&\-mjmpext \-mjmp32 \-malu32 \-mcpu=\fR\fIversion\fR
  .Sp
! \&\fIFR30 Options\fR
  \&\fB\-msmall\-model  \-mno\-lsim\fR
  .Sp
! \&\fIFT32 Options\fR
  \&\fB\-msim  \-mlra  \-mnodiv  \-mft32b  \-mcompress  \-mnopm\fR
  .Sp
! \&\fIFRV Options\fR
  \&\fB\-mgpr\-32  \-mgpr\-64  \-mfpr\-32  \-mfpr\-64
  \&\-mhard\-float  \-msoft\-float
  \&\-malloc\-cc  \-mfixed\-cc  \-mdword  \-mno\-dword
*************** in the following sections.
*** 985,996 ****
  \&\fIH8/300 Options\fR
  \&\fB\-mrelax  \-mh  \-ms  \-mn  \-mexr  \-mno\-exr  \-mint32  \-malign\-300\fR
  .Sp
! \&\fI\s-1HPPA\s0 Options\fR
! \&\fB\-march=\fR\fIarchitecture-type\fR
  \&\fB\-matomic\-libcalls  \-mbig\-switch
  \&\-mcaller\-copies  \-mdisable\-fpregs  \-mdisable\-indexing
  \&\-mordered  \-mfast\-indirect\-calls  \-mgas  \-mgnu\-ld   \-mhp\-ld
! \&\-mfixed\-range=\fR\fIregister-range\fR
  \&\fB\-mcoherent\-ldcw \-mjump\-in\-delay  \-mlinker\-opt  \-mlong\-calls
  \&\-mlong\-load\-store  \-mno\-atomic\-libcalls  \-mno\-disable\-fpregs
  \&\-mno\-disable\-indexing  \-mno\-fast\-indirect\-calls  \-mno\-gas
--- 910,921 ----
  \&\fIH8/300 Options\fR
  \&\fB\-mrelax  \-mh  \-ms  \-mn  \-mexr  \-mno\-exr  \-mint32  \-malign\-300\fR
  .Sp
! \&\fIHPPA Options\fR
! \&\fB\-march=\fR\fIarchitecture\-type\fR
  \&\fB\-matomic\-libcalls  \-mbig\-switch
  \&\-mcaller\-copies  \-mdisable\-fpregs  \-mdisable\-indexing
  \&\-mordered  \-mfast\-indirect\-calls  \-mgas  \-mgnu\-ld   \-mhp\-ld
! \&\-mfixed\-range=\fR\fIregister\-range\fR
  \&\fB\-mcoherent\-ldcw \-mjump\-in\-delay  \-mlinker\-opt  \-mlong\-calls
  \&\-mlong\-load\-store  \-mno\-atomic\-libcalls  \-mno\-disable\-fpregs
  \&\-mno\-disable\-indexing  \-mno\-fast\-indirect\-calls  \-mno\-gas
*************** in the following sections.
*** 998,1007 ****
  \&\-mno\-portable\-runtime  \-mno\-soft\-float
  \&\-mno\-space\-regs  \-msoft\-float  \-mpa\-risc\-1\-0
  \&\-mpa\-risc\-1\-1  \-mpa\-risc\-2\-0  \-mportable\-runtime
! \&\-mschedule=\fR\fIcpu-type\fR  \fB\-mspace\-regs  \-msoft\-mult  \-msio  \-mwsio
! \&\-munix=\fR\fIunix-std\fR  \fB\-nolibdld  \-static  \-threads\fR
  .Sp
! \&\fI\s-1IA\-64\s0 Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian  \-mgnu\-as  \-mgnu\-ld  \-mno\-pic
  \&\-mvolatile\-asm\-stop  \-mregister\-names  \-msdata  \-mno\-sdata
  \&\-mconstant\-gp  \-mauto\-pic  \-mfused\-madd
--- 923,932 ----
  \&\-mno\-portable\-runtime  \-mno\-soft\-float
  \&\-mno\-space\-regs  \-msoft\-float  \-mpa\-risc\-1\-0
  \&\-mpa\-risc\-1\-1  \-mpa\-risc\-2\-0  \-mportable\-runtime
! \&\-mschedule=\fR\fIcpu\-type\fR  \fB\-mspace\-regs  \-msoft\-mult  \-msio  \-mwsio
! \&\-munix=\fR\fIunix\-std\fR  \fB\-nolibdld  \-static  \-threads\fR
  .Sp
! \&\fIIA\-64 Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian  \-mgnu\-as  \-mgnu\-ld  \-mno\-pic
  \&\-mvolatile\-asm\-stop  \-mregister\-names  \-msdata  \-mno\-sdata
  \&\-mconstant\-gp  \-mauto\-pic  \-mfused\-madd
*************** in the following sections.
*** 1014,1036 ****
  \&\-minline\-sqrt\-min\-latency  \-minline\-sqrt\-max\-throughput
  \&\-mno\-inline\-sqrt
  \&\-mdwarf2\-asm  \-mearly\-stop\-bits
! \&\-mfixed\-range=\fR\fIregister-range\fR  \fB\-mtls\-size=\fR\fItls-size\fR
! \&\fB\-mtune=\fR\fIcpu-type\fR  \fB\-milp32  \-mlp64
  \&\-msched\-br\-data\-spec  \-msched\-ar\-data\-spec  \-msched\-control\-spec
  \&\-msched\-br\-in\-data\-spec  \-msched\-ar\-in\-data\-spec  \-msched\-in\-control\-spec
  \&\-msched\-spec\-ldc  \-msched\-spec\-control\-ldc
  \&\-msched\-prefer\-non\-data\-spec\-insns  \-msched\-prefer\-non\-control\-spec\-insns
  \&\-msched\-stop\-bits\-after\-every\-cycle  \-msched\-count\-spec\-in\-critical\-path
  \&\-msel\-sched\-dont\-check\-control\-spec  \-msched\-fp\-mem\-deps\-zero\-cost
! \&\-msched\-max\-memory\-insns\-hard\-limit  \-msched\-max\-memory\-insns=\fR\fImax-insns\fR
  .Sp
! \&\fI\s-1LM32\s0 Options\fR
  \&\fB\-mbarrel\-shift\-enabled  \-mdivide\-enabled  \-mmultiply\-enabled
  \&\-msign\-extend\-enabled  \-muser\-enabled\fR
  .Sp
  \&\fILoongArch Options\fR
! \&\fB\-march=\fR\fIcpu-type\fR  \fB\-mtune=\fR\fIcpu-type\fR \fB\-mabi=\fR\fIbase-abi-type\fR
! \&\fB\-mfpu=\fR\fIfpu-type\fR \fB\-msoft\-float \-msingle\-float \-mdouble\-float
  \&\-mbranch\-cost=\fR\fIn\fR  \fB\-mcheck\-zero\-division \-mno\-check\-zero\-division
  \&\-mcond\-move\-int  \-mno\-cond\-move\-int
  \&\-mcond\-move\-float  \-mno\-cond\-move\-float
--- 939,961 ----
  \&\-minline\-sqrt\-min\-latency  \-minline\-sqrt\-max\-throughput
  \&\-mno\-inline\-sqrt
  \&\-mdwarf2\-asm  \-mearly\-stop\-bits
! \&\-mfixed\-range=\fR\fIregister\-range\fR  \fB\-mtls\-size=\fR\fItls\-size\fR
! \&\fB\-mtune=\fR\fIcpu\-type\fR  \fB\-milp32  \-mlp64
  \&\-msched\-br\-data\-spec  \-msched\-ar\-data\-spec  \-msched\-control\-spec
  \&\-msched\-br\-in\-data\-spec  \-msched\-ar\-in\-data\-spec  \-msched\-in\-control\-spec
  \&\-msched\-spec\-ldc  \-msched\-spec\-control\-ldc
  \&\-msched\-prefer\-non\-data\-spec\-insns  \-msched\-prefer\-non\-control\-spec\-insns
  \&\-msched\-stop\-bits\-after\-every\-cycle  \-msched\-count\-spec\-in\-critical\-path
  \&\-msel\-sched\-dont\-check\-control\-spec  \-msched\-fp\-mem\-deps\-zero\-cost
! \&\-msched\-max\-memory\-insns\-hard\-limit  \-msched\-max\-memory\-insns=\fR\fImax\-insns\fR
  .Sp
! \&\fILM32 Options\fR
  \&\fB\-mbarrel\-shift\-enabled  \-mdivide\-enabled  \-mmultiply\-enabled
  \&\-msign\-extend\-enabled  \-muser\-enabled\fR
  .Sp
  \&\fILoongArch Options\fR
! \&\fB\-march=\fR\fIcpu\-type\fR  \fB\-mtune=\fR\fIcpu\-type\fR \fB\-mabi=\fR\fIbase\-abi\-type\fR
! \&\fB\-mfpu=\fR\fIfpu\-type\fR \fB\-msoft\-float \-msingle\-float \-mdouble\-float
  \&\-mbranch\-cost=\fR\fIn\fR  \fB\-mcheck\-zero\-division \-mno\-check\-zero\-division
  \&\-mcond\-move\-int  \-mno\-cond\-move\-int
  \&\-mcond\-move\-float  \-mno\-cond\-move\-float
*************** in the following sections.
*** 1038,1044 ****
  \&\-mmax\-inline\-memcpy\-size=\fR\fIn\fR
  \&\fB\-mexplicit\-relocs \-mno\-explicit\-relocs
  \&\-mdirect\-extern\-access \-mno\-direct\-extern\-access
! \&\-mcmodel=\fR\fIcode-model\fR \fB\-mrelax \-mpass\-mrelax\-to\-as\fR
  .Sp
  \&\fIM32R/D Options\fR
  \&\fB\-m32r2  \-m32rx  \-m32r
--- 963,969 ----
  \&\-mmax\-inline\-memcpy\-size=\fR\fIn\fR
  \&\fB\-mexplicit\-relocs \-mno\-explicit\-relocs
  \&\-mdirect\-extern\-access \-mno\-direct\-extern\-access
! \&\-mcmodel=\fR\fIcode\-model\fR \fB\-mrelax \-mpass\-mrelax\-to\-as\fR
  .Sp
  \&\fIM32R/D Options\fR
  \&\fB\-m32r2  \-m32rx  \-m32r
*************** in the following sections.
*** 1046,1053 ****
  \&\-malign\-loops  \-mno\-align\-loops
  \&\-missue\-rate=\fR\fInumber\fR
  \&\fB\-mbranch\-cost=\fR\fInumber\fR
! \&\fB\-mmodel=\fR\fIcode-size-model-type\fR
! \&\fB\-msdata=\fR\fIsdata-type\fR
  \&\fB\-mno\-flush\-func  \-mflush\-func=\fR\fIname\fR
  \&\fB\-mno\-flush\-trap  \-mflush\-trap=\fR\fInumber\fR
  \&\fB\-G\fR \fInum\fR
--- 971,978 ----
  \&\-malign\-loops  \-mno\-align\-loops
  \&\-missue\-rate=\fR\fInumber\fR
  \&\fB\-mbranch\-cost=\fR\fInumber\fR
! \&\fB\-mmodel=\fR\fIcode\-size\-model\-type\fR
! \&\fB\-msdata=\fR\fIsdata\-type\fR
  \&\fB\-mno\-flush\-func  \-mflush\-func=\fR\fIname\fR
  \&\fB\-mno\-flush\-trap  \-mflush\-trap=\fR\fInumber\fR
  \&\fB\-G\fR \fInum\fR
*************** in the following sections.
*** 1078,1087 ****
  \&\fB\-mmemcpy  \-mxl\-soft\-mul  \-mxl\-soft\-div  \-mxl\-barrel\-shift
  \&\-mxl\-pattern\-compare  \-mxl\-stack\-check  \-mxl\-gp\-opt  \-mno\-clearbss
  \&\-mxl\-multiply\-high  \-mxl\-float\-convert  \-mxl\-float\-sqrt
! \&\-mbig\-endian  \-mlittle\-endian  \-mxl\-reorder  \-mxl\-mode\-\fR\fIapp-model\fR
  \&\fB\-mpic\-data\-is\-text\-relative\fR
  .Sp
! \&\fI\s-1MIPS\s0 Options\fR
  \&\fB\-EL  \-EB  \-march=\fR\fIarch\fR  \fB\-mtune=\fR\fIarch\fR
  \&\fB\-mips1  \-mips2  \-mips3  \-mips4  \-mips32  \-mips32r2  \-mips32r3  \-mips32r5
  \&\-mips32r6  \-mips64  \-mips64r2  \-mips64r3  \-mips64r5  \-mips64r6
--- 1003,1012 ----
  \&\fB\-mmemcpy  \-mxl\-soft\-mul  \-mxl\-soft\-div  \-mxl\-barrel\-shift
  \&\-mxl\-pattern\-compare  \-mxl\-stack\-check  \-mxl\-gp\-opt  \-mno\-clearbss
  \&\-mxl\-multiply\-high  \-mxl\-float\-convert  \-mxl\-float\-sqrt
! \&\-mbig\-endian  \-mlittle\-endian  \-mxl\-reorder  \-mxl\-mode\-\fR\fIapp\-model\fR
  \&\fB\-mpic\-data\-is\-text\-relative\fR
  .Sp
! \&\fIMIPS Options\fR
  \&\fB\-EL  \-EB  \-march=\fR\fIarch\fR  \fB\-mtune=\fR\fIarch\fR
  \&\fB\-mips1  \-mips2  \-mips3  \-mips4  \-mips32  \-mips32r2  \-mips32r3  \-mips32r5
  \&\-mips32r6  \-mips64  \-mips64r2  \-mips64r3  \-mips64r5  \-mips64r6
*************** in the following sections.
*** 1106,1112 ****
  \&\-mloongson\-mmi  \-mno\-loongson\-mmi
  \&\-mloongson\-ext  \-mno\-loongson\-ext
  \&\-mloongson\-ext2  \-mno\-loongson\-ext2
! \&\-mfpu=\fR\fIfpu-type\fR
  \&\fB\-msmartmips  \-mno\-smartmips
  \&\-mpaired\-single  \-mno\-paired\-single  \-mdmx  \-mno\-mdmx
  \&\-mips3d  \-mno\-mips3d  \-mmt  \-mno\-mt  \-mllsc  \-mno\-llsc
--- 1031,1037 ----
  \&\-mloongson\-mmi  \-mno\-loongson\-mmi
  \&\-mloongson\-ext  \-mno\-loongson\-ext
  \&\-mloongson\-ext2  \-mno\-loongson\-ext2
! \&\-mfpu=\fR\fIfpu\-type\fR
  \&\fB\-msmartmips  \-mno\-smartmips
  \&\-mpaired\-single  \-mno\-paired\-single  \-mdmx  \-mno\-mdmx
  \&\-mips3d  \-mno\-mips3d  \-mmt  \-mno\-mt  \-mllsc  \-mno\-llsc
*************** in the following sections.
*** 1139,1168 ****
  \&\-mrelax\-pic\-calls  \-mno\-relax\-pic\-calls  \-mmcount\-ra\-address
  \&\-mframe\-header\-opt  \-mno\-frame\-header\-opt\fR
  .Sp
! \&\fI\s-1MMIX\s0 Options\fR
  \&\fB\-mlibfuncs  \-mno\-libfuncs  \-mepsilon  \-mno\-epsilon  \-mabi=gnu
  \&\-mabi=mmixware  \-mzero\-extend  \-mknuthdiv  \-mtoplevel\-symbols
  \&\-melf  \-mbranch\-predict  \-mno\-branch\-predict  \-mbase\-addresses
  \&\-mno\-base\-addresses  \-msingle\-exit  \-mno\-single\-exit\fR
  .Sp
! \&\fI\s-1MN10300\s0 Options\fR
  \&\fB\-mmult\-bug  \-mno\-mult\-bug
  \&\-mno\-am33  \-mam33  \-mam33\-2  \-mam34
! \&\-mtune=\fR\fIcpu-type\fR
  \&\fB\-mreturn\-pointer\-on\-d0
  \&\-mno\-crt0  \-mrelax  \-mliw  \-msetlb\fR
  .Sp
  \&\fIMoxie Options\fR
  \&\fB\-meb  \-mel  \-mmul.x  \-mno\-crt0\fR
  .Sp
! \&\fI\s-1MSP430\s0 Options\fR
  \&\fB\-msim  \-masm\-hex  \-mmcu=  \-mcpu=  \-mlarge  \-msmall  \-mrelax
  \&\-mwarn\-mcu
  \&\-mcode\-region=  \-mdata\-region=
  \&\-msilicon\-errata=  \-msilicon\-errata\-warn=
  \&\-mhwmult=  \-minrt  \-mtiny\-printf  \-mmax\-inline\-shift=\fR
  .Sp
! \&\fI\s-1NDS32\s0 Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian
  \&\-mreduced\-regs  \-mfull\-regs
  \&\-mcmov  \-mno\-cmov
--- 1064,1093 ----
  \&\-mrelax\-pic\-calls  \-mno\-relax\-pic\-calls  \-mmcount\-ra\-address
  \&\-mframe\-header\-opt  \-mno\-frame\-header\-opt\fR
  .Sp
! \&\fIMMIX Options\fR
  \&\fB\-mlibfuncs  \-mno\-libfuncs  \-mepsilon  \-mno\-epsilon  \-mabi=gnu
  \&\-mabi=mmixware  \-mzero\-extend  \-mknuthdiv  \-mtoplevel\-symbols
  \&\-melf  \-mbranch\-predict  \-mno\-branch\-predict  \-mbase\-addresses
  \&\-mno\-base\-addresses  \-msingle\-exit  \-mno\-single\-exit\fR
  .Sp
! \&\fIMN10300 Options\fR
  \&\fB\-mmult\-bug  \-mno\-mult\-bug
  \&\-mno\-am33  \-mam33  \-mam33\-2  \-mam34
! \&\-mtune=\fR\fIcpu\-type\fR
  \&\fB\-mreturn\-pointer\-on\-d0
  \&\-mno\-crt0  \-mrelax  \-mliw  \-msetlb\fR
  .Sp
  \&\fIMoxie Options\fR
  \&\fB\-meb  \-mel  \-mmul.x  \-mno\-crt0\fR
  .Sp
! \&\fIMSP430 Options\fR
  \&\fB\-msim  \-masm\-hex  \-mmcu=  \-mcpu=  \-mlarge  \-msmall  \-mrelax
  \&\-mwarn\-mcu
  \&\-mcode\-region=  \-mdata\-region=
  \&\-msilicon\-errata=  \-msilicon\-errata\-warn=
  \&\-mhwmult=  \-minrt  \-mtiny\-printf  \-mmax\-inline\-shift=\fR
  .Sp
! \&\fINDS32 Options\fR
  \&\fB\-mbig\-endian  \-mlittle\-endian
  \&\-mreduced\-regs  \-mfull\-regs
  \&\-mcmov  \-mno\-cmov
*************** in the following sections.
*** 1174,1183 ****
  \&\-misr\-vector\-size=\fR\fInum\fR
  \&\fB\-mcache\-block\-size=\fR\fInum\fR
  \&\fB\-march=\fR\fIarch\fR
! \&\fB\-mcmodel=\fR\fIcode-model\fR
  \&\fB\-mctor\-dtor  \-mrelax\fR
  .Sp
! \&\fINios \s-1II\s0 Options\fR
  \&\fB\-G\fR \fInum\fR  \fB\-mgpopt=\fR\fIoption\fR  \fB\-mgpopt  \-mno\-gpopt
  \&\-mgprel\-sec=\fR\fIregexp\fR  \fB\-mr0rel\-sec=\fR\fIregexp\fR
  \&\fB\-mel  \-meb
--- 1099,1108 ----
  \&\-misr\-vector\-size=\fR\fInum\fR
  \&\fB\-mcache\-block\-size=\fR\fInum\fR
  \&\fB\-march=\fR\fIarch\fR
! \&\fB\-mcmodel=\fR\fIcode\-model\fR
  \&\fB\-mctor\-dtor  \-mrelax\fR
  .Sp
! \&\fINios II Options\fR
  \&\fB\-G\fR \fInum\fR  \fB\-mgpopt=\fR\fIoption\fR  \fB\-mgpopt  \-mno\-gpopt
  \&\-mgprel\-sec=\fR\fIregexp\fR  \fB\-mr0rel\-sec=\fR\fIregexp\fR
  \&\fB\-mel  \-meb
*************** in the following sections.
*** 1190,1196 ****
  \&\fB\-mhal  \-msmallc  \-msys\-crt0=\fR\fIname\fR  \fB\-msys\-lib=\fR\fIname\fR
  \&\fB\-march=\fR\fIarch\fR  \fB\-mbmx  \-mno\-bmx  \-mcdx  \-mno\-cdx\fR
  .Sp
! \&\fINvidia \s-1PTX\s0 Options\fR
  \&\fB\-m64  \-mmainkernel  \-moptimize\fR
  .Sp
  \&\fIOpenRISC Options\fR
--- 1115,1121 ----
  \&\fB\-mhal  \-msmallc  \-msys\-crt0=\fR\fIname\fR  \fB\-msys\-lib=\fR\fIname\fR
  \&\fB\-march=\fR\fIarch\fR  \fB\-mbmx  \-mno\-bmx  \-mcdx  \-mno\-cdx\fR
  .Sp
! \&\fINvidia PTX Options\fR
  \&\fB\-m64  \-mmainkernel  \-moptimize\fR
  .Sp
  \&\fIOpenRISC Options\fR
*************** in the following sections.
*** 1198,1226 ****
  \&\-msoft\-mul  \-msoft\-div
  \&\-msoft\-float  \-mhard\-float  \-mdouble\-float \-munordered\-float
  \&\-mcmov  \-mror  \-mrori  \-msext  \-msfimm  \-mshftimm
! \&\-mcmodel=\fR\fIcode-model\fR
  .Sp
! \&\fI\s-1PDP\-11\s0 Options\fR
  \&\fB\-mfpu  \-msoft\-float  \-mac0  \-mno\-ac0  \-m40  \-m45  \-m10
  \&\-mint32  \-mno\-int16  \-mint16  \-mno\-int32
  \&\-msplit  \-munix\-asm  \-mdec\-asm  \-mgnu\-asm  \-mlra\fR
  .Sp
  \&\fIPowerPC Options\fR
! See \s-1RS/6000\s0 and PowerPC Options.
  .Sp
! \&\fI\s-1PRU\s0 Options\fR
  \&\fB\-mmcu=\fR\fImcu\fR  \fB\-minrt  \-mno\-relax  \-mloop
  \&\-mabi=\fR\fIvariant\fR
  .Sp
! \&\fIRISC-V Options\fR
  \&\fB\-mbranch\-cost=\fR\fIN\-instruction\fR
  \&\fB\-mplt  \-mno\-plt
! \&\-mabi=\fR\fIABI-string\fR
  \&\fB\-mfdiv  \-mno\-fdiv
  \&\-mdiv  \-mno\-div
! \&\-misa\-spec=\fR\fIISA-spec-string\fR
! \&\fB\-march=\fR\fIISA-string\fR
! \&\fB\-mtune=\fR\fIprocessor-string\fR
  \&\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR
  \&\fB\-msmall\-data\-limit=\fR\fIN\-bytes\fR
  \&\fB\-msave\-restore  \-mno\-save\-restore
--- 1123,1151 ----
  \&\-msoft\-mul  \-msoft\-div
  \&\-msoft\-float  \-mhard\-float  \-mdouble\-float \-munordered\-float
  \&\-mcmov  \-mror  \-mrori  \-msext  \-msfimm  \-mshftimm
! \&\-mcmodel=\fR\fIcode\-model\fR
  .Sp
! \&\fIPDP\-11 Options\fR
  \&\fB\-mfpu  \-msoft\-float  \-mac0  \-mno\-ac0  \-m40  \-m45  \-m10
  \&\-mint32  \-mno\-int16  \-mint16  \-mno\-int32
  \&\-msplit  \-munix\-asm  \-mdec\-asm  \-mgnu\-asm  \-mlra\fR
  .Sp
  \&\fIPowerPC Options\fR
! See RS/6000 and PowerPC Options.
  .Sp
! \&\fIPRU Options\fR
  \&\fB\-mmcu=\fR\fImcu\fR  \fB\-minrt  \-mno\-relax  \-mloop
  \&\-mabi=\fR\fIvariant\fR
  .Sp
! \&\fIRISC\-V Options\fR
  \&\fB\-mbranch\-cost=\fR\fIN\-instruction\fR
  \&\fB\-mplt  \-mno\-plt
! \&\-mabi=\fR\fIABI\-string\fR
  \&\fB\-mfdiv  \-mno\-fdiv
  \&\-mdiv  \-mno\-div
! \&\-misa\-spec=\fR\fIISA\-spec\-string\fR
! \&\fB\-march=\fR\fIISA\-string\fR
! \&\fB\-mtune=\fR\fIprocessor\-string\fR
  \&\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR
  \&\fB\-msmall\-data\-limit=\fR\fIN\-bytes\fR
  \&\fB\-msave\-restore  \-mno\-save\-restore
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1237,1251 ****
  \&\fB\-mcsr\-check \-mno\-csr\-check
  \&\-minline\-atomics  \-mno\-inline\-atomics\fR
  .Sp
! \&\fI\s-1RL78\s0 Options\fR
  \&\fB\-msim  \-mmul=none  \-mmul=g13  \-mmul=g14  \-mallregs
  \&\-mcpu=g10  \-mcpu=g13  \-mcpu=g14  \-mg10  \-mg13  \-mg14
  \&\-m64bit\-doubles  \-m32bit\-doubles  \-msave\-mduc\-in\-interrupts\fR
  .Sp
! \&\fI\s-1RS/6000\s0 and PowerPC Options\fR
! \&\fB\-mcpu=\fR\fIcpu-type\fR
! \&\fB\-mtune=\fR\fIcpu-type\fR
! \&\fB\-mcmodel=\fR\fIcode-model\fR
  \&\fB\-mpowerpc64
  \&\-maltivec  \-mno\-altivec
  \&\-mpowerpc\-gpopt  \-mno\-powerpc\-gpopt
--- 1162,1176 ----
  \&\fB\-mcsr\-check \-mno\-csr\-check
  \&\-minline\-atomics  \-mno\-inline\-atomics\fR
  .Sp
! \&\fIRL78 Options\fR
  \&\fB\-msim  \-mmul=none  \-mmul=g13  \-mmul=g14  \-mallregs
  \&\-mcpu=g10  \-mcpu=g13  \-mcpu=g14  \-mg10  \-mg13  \-mg14
  \&\-m64bit\-doubles  \-m32bit\-doubles  \-msave\-mduc\-in\-interrupts\fR
  .Sp
! \&\fIRS/6000 and PowerPC Options\fR
! \&\fB\-mcpu=\fR\fIcpu\-type\fR
! \&\fB\-mtune=\fR\fIcpu\-type\fR
! \&\fB\-mcmodel=\fR\fIcode\-model\fR
  \&\fB\-mpowerpc64
  \&\-maltivec  \-mno\-altivec
  \&\-mpowerpc\-gpopt  \-mno\-powerpc\-gpopt
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1272,1278 ****
  \&\-mcall\-sysv  \-mcall\-sysv\-eabi  \-mcall\-sysv\-noeabi
  \&\-mtraceback=\fR\fItraceback_type\fR
  \&\fB\-maix\-struct\-return  \-msvr4\-struct\-return
! \&\-mabi=\fR\fIabi-type\fR  \fB\-msecure\-plt  \-mbss\-plt
  \&\-mlongcall  \-mno\-longcall  \-mpltseq  \-mno\-pltseq
  \&\-mblock\-move\-inline\-limit=\fR\fInum\fR
  \&\fB\-mblock\-compare\-inline\-limit=\fR\fInum\fR
--- 1197,1203 ----
  \&\-mcall\-sysv  \-mcall\-sysv\-eabi  \-mcall\-sysv\-noeabi
  \&\-mtraceback=\fR\fItraceback_type\fR
  \&\fB\-maix\-struct\-return  \-msvr4\-struct\-return
! \&\-mabi=\fR\fIabi\-type\fR  \fB\-msecure\-plt  \-mbss\-plt
  \&\-mlongcall  \-mno\-longcall  \-mpltseq  \-mno\-pltseq
  \&\-mblock\-move\-inline\-limit=\fR\fInum\fR
  \&\fB\-mblock\-compare\-inline\-limit=\fR\fInum\fR
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1303,1309 ****
  \&\-mpcrel \-mno\-pcrel \-mmma \-mno\-mmma \-mrop\-protect \-mno\-rop\-protect
  \&\-mprivileged \-mno\-privileged\fR
  .Sp
! \&\fI\s-1RX\s0 Options\fR
  \&\fB\-m64bit\-doubles  \-m32bit\-doubles  \-fpu  \-nofpu
  \&\-mcpu=
  \&\-mbig\-endian\-data  \-mlittle\-endian\-data
--- 1228,1234 ----
  \&\-mpcrel \-mno\-pcrel \-mmma \-mno\-mmma \-mrop\-protect \-mno\-rop\-protect
  \&\-mprivileged \-mno\-privileged\fR
  .Sp
! \&\fIRX Options\fR
  \&\fB\-m64bit\-doubles  \-m32bit\-doubles  \-fpu  \-nofpu
  \&\-mcpu=
  \&\-mbig\-endian\-data  \-mlittle\-endian\-data
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1320,1326 ****
  \&\-msave\-acc\-in\-interrupts\fR
  .Sp
  \&\fIS/390 and zSeries Options\fR
! \&\fB\-mtune=\fR\fIcpu-type\fR  \fB\-march=\fR\fIcpu-type\fR
  \&\fB\-mhard\-float  \-msoft\-float  \-mhard\-dfp  \-mno\-hard\-dfp
  \&\-mlong\-double\-64  \-mlong\-double\-128
  \&\-mbackchain  \-mno\-backchain  \-mpacked\-stack  \-mno\-packed\-stack
--- 1245,1251 ----
  \&\-msave\-acc\-in\-interrupts\fR
  .Sp
  \&\fIS/390 and zSeries Options\fR
! \&\fB\-mtune=\fR\fIcpu\-type\fR  \fB\-march=\fR\fIcpu\-type\fR
  \&\fB\-mhard\-float  \-msoft\-float  \-mhard\-dfp  \-mno\-hard\-dfp
  \&\-mlong\-double\-64  \-mlong\-double\-128
  \&\-mbackchain  \-mno\-backchain  \-mpacked\-stack  \-mno\-packed\-stack
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1332,1338 ****
  \&\-mwarn\-framesize  \-mwarn\-dynamicstack  \-mstack\-size  \-mstack\-guard
  \&\-mhotpatch=\fR\fIhalfwords\fR\fB,\fR\fIhalfwords\fR
  .Sp
! \&\fI\s-1SH\s0 Options\fR
  \&\fB\-m1  \-m2  \-m2e
  \&\-m2a\-nofpu  \-m2a\-single\-only  \-m2a\-single  \-m2a
  \&\-m3  \-m3e
--- 1257,1263 ----
  \&\-mwarn\-framesize  \-mwarn\-dynamicstack  \-mstack\-size  \-mstack\-guard
  \&\-mhotpatch=\fR\fIhalfwords\fR\fB,\fR\fIhalfwords\fR
  .Sp
! \&\fISH Options\fR
  \&\fB\-m1  \-m2  \-m2e
  \&\-m2a\-nofpu  \-m2a\-single\-only  \-m2a\-single  \-m2a
  \&\-m3  \-m3e
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1342,1350 ****
  \&\-mbigtable  \-mfmovd  \-mrenesas  \-mno\-renesas  \-mnomacsave
  \&\-mieee  \-mno\-ieee  \-mbitops  \-misize  \-minline\-ic_invalidate  \-mpadstruct
  \&\-mprefergot  \-musermode  \-multcost=\fR\fInumber\fR  \fB\-mdiv=\fR\fIstrategy\fR
! \&\fB\-mdivsi3_libfunc=\fR\fIname\fR  \fB\-mfixed\-range=\fR\fIregister-range\fR
  \&\fB\-maccumulate\-outgoing\-args
! \&\-matomic\-model=\fR\fIatomic-model\fR
  \&\fB\-mbranch\-cost=\fR\fInum\fR  \fB\-mzdcbranch  \-mno\-zdcbranch
  \&\-mcbranch\-force\-delay\-slot
  \&\-mfused\-madd  \-mno\-fused\-madd  \-mfsca  \-mno\-fsca  \-mfsrra  \-mno\-fsrra
--- 1267,1275 ----
  \&\-mbigtable  \-mfmovd  \-mrenesas  \-mno\-renesas  \-mnomacsave
  \&\-mieee  \-mno\-ieee  \-mbitops  \-misize  \-minline\-ic_invalidate  \-mpadstruct
  \&\-mprefergot  \-musermode  \-multcost=\fR\fInumber\fR  \fB\-mdiv=\fR\fIstrategy\fR
! \&\fB\-mdivsi3_libfunc=\fR\fIname\fR  \fB\-mfixed\-range=\fR\fIregister\-range\fR
  \&\fB\-maccumulate\-outgoing\-args
! \&\-matomic\-model=\fR\fIatomic\-model\fR
  \&\fB\-mbranch\-cost=\fR\fInum\fR  \fB\-mzdcbranch  \-mno\-zdcbranch
  \&\-mcbranch\-force\-delay\-slot
  \&\-mfused\-madd  \-mno\-fused\-madd  \-mfsca  \-mno\-fsca  \-mfsrra  \-mno\-fsrra
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1354,1364 ****
  \&\fB\-mclear\-hwcap  \-mno\-clear\-hwcap  \-mimpure\-text  \-mno\-impure\-text
  \&\-pthreads\fR
  .Sp
! \&\fI\s-1SPARC\s0 Options\fR
! \&\fB\-mcpu=\fR\fIcpu-type\fR
! \&\fB\-mtune=\fR\fIcpu-type\fR
! \&\fB\-mcmodel=\fR\fIcode-model\fR
! \&\fB\-mmemory\-model=\fR\fImem-model\fR
  \&\fB\-m32  \-m64  \-mapp\-regs  \-mno\-app\-regs
  \&\-mfaster\-structs  \-mno\-faster\-structs  \-mflat  \-mno\-flat
  \&\-mfpu  \-mno\-fpu  \-mhard\-float  \-msoft\-float
--- 1279,1289 ----
  \&\fB\-mclear\-hwcap  \-mno\-clear\-hwcap  \-mimpure\-text  \-mno\-impure\-text
  \&\-pthreads\fR
  .Sp
! \&\fISPARC Options\fR
! \&\fB\-mcpu=\fR\fIcpu\-type\fR
! \&\fB\-mtune=\fR\fIcpu\-type\fR
! \&\fB\-mcmodel=\fR\fIcode\-model\fR
! \&\fB\-mmemory\-model=\fR\fImem\-model\fR
  \&\fB\-m32  \-m64  \-mapp\-regs  \-mno\-app\-regs
  \&\-mfaster\-structs  \-mno\-faster\-structs  \-mflat  \-mno\-flat
  \&\-mfpu  \-mno\-fpu  \-mhard\-float  \-msoft\-float
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1395,1408 ****
  \&\-mrh850\-abi
  \&\-mbig\-switch\fR
  .Sp
! \&\fI\s-1VAX\s0 Options\fR
  \&\fB\-mg  \-mgnu  \-munix  \-mlra\fR
  .Sp
  \&\fIVisium Options\fR
  \&\fB\-mdebug  \-msim  \-mfpu  \-mno\-fpu  \-mhard\-float  \-msoft\-float
! \&\-mcpu=\fR\fIcpu-type\fR  \fB\-mtune=\fR\fIcpu-type\fR  \fB\-msv\-mode  \-muser\-mode\fR
  .Sp
! \&\fI\s-1VMS\s0 Options\fR
  \&\fB\-mvms\-return\-codes  \-mdebug\-main=\fR\fIprefix\fR  \fB\-mmalloc64
  \&\-mpointer\-size=\fR\fIsize\fR
  .Sp
--- 1320,1333 ----
  \&\-mrh850\-abi
  \&\-mbig\-switch\fR
  .Sp
! \&\fIVAX Options\fR
  \&\fB\-mg  \-mgnu  \-munix  \-mlra\fR
  .Sp
  \&\fIVisium Options\fR
  \&\fB\-mdebug  \-msim  \-mfpu  \-mno\-fpu  \-mhard\-float  \-msoft\-float
! \&\-mcpu=\fR\fIcpu\-type\fR  \fB\-mtune=\fR\fIcpu\-type\fR  \fB\-msv\-mode  \-muser\-mode\fR
  .Sp
! \&\fIVMS Options\fR
  \&\fB\-mvms\-return\-codes  \-mdebug\-main=\fR\fIprefix\fR  \fB\-mmalloc64
  \&\-mpointer\-size=\fR\fIsize\fR
  .Sp
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1411,1418 ****
  \&\-Xbind\-lazy  \-Xbind\-now\fR
  .Sp
  \&\fIx86 Options\fR
! \&\fB\-mtune=\fR\fIcpu-type\fR  \fB\-march=\fR\fIcpu-type\fR
! \&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR  \fB\-mdump\-tune\-features  \-mno\-default
  \&\-mfpmath=\fR\fIunit\fR
  \&\fB\-masm=\fR\fIdialect\fR  \fB\-mno\-fancy\-math\-387
  \&\-mno\-fp\-ret\-in\-387  \-m80387  \-mhard\-float  \-msoft\-float
--- 1336,1343 ----
  \&\-Xbind\-lazy  \-Xbind\-now\fR
  .Sp
  \&\fIx86 Options\fR
! \&\fB\-mtune=\fR\fIcpu\-type\fR  \fB\-march=\fR\fIcpu\-type\fR
! \&\fB\-mtune\-ctrl=\fR\fIfeature\-list\fR  \fB\-mdump\-tune\-features  \-mno\-default
  \&\-mfpmath=\fR\fIunit\fR
  \&\fB\-masm=\fR\fIdialect\fR  \fB\-mno\-fancy\-math\-387
  \&\-mno\-fp\-ret\-in\-387  \-m80387  \-mhard\-float  \-msoft\-float
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1449,1455 ****
  \&\-mveclibabi=\fR\fItype\fR  \fB\-mvect8\-ret\-in\-mem
  \&\-mpc32  \-mpc64  \-mpc80  \-mdaz\-ftz \-mstackrealign
  \&\-momit\-leaf\-frame\-pointer  \-mno\-red\-zone  \-mno\-tls\-direct\-seg\-refs
! \&\-mcmodel=\fR\fIcode-model\fR  \fB\-mabi=\fR\fIname\fR  \fB\-maddress\-mode=\fR\fImode\fR
  \&\fB\-m32  \-m64  \-mx32  \-m16  \-miamcu  \-mlarge\-data\-threshold=\fR\fInum\fR
  \&\fB\-msse2avx  \-mfentry  \-mrecord\-mcount  \-mnop\-mcount  \-m8bit\-idiv
  \&\-minstrument\-return=\fR\fItype\fR \fB\-mfentry\-name=\fR\fIname\fR \fB\-mfentry\-section=\fR\fIname\fR
--- 1374,1380 ----
  \&\-mveclibabi=\fR\fItype\fR  \fB\-mvect8\-ret\-in\-mem
  \&\-mpc32  \-mpc64  \-mpc80  \-mdaz\-ftz \-mstackrealign
  \&\-momit\-leaf\-frame\-pointer  \-mno\-red\-zone  \-mno\-tls\-direct\-seg\-refs
! \&\-mcmodel=\fR\fIcode\-model\fR  \fB\-mabi=\fR\fIname\fR  \fB\-maddress\-mode=\fR\fImode\fR
  \&\fB\-m32  \-m64  \-mx32  \-m16  \-miamcu  \-mlarge\-data\-threshold=\fR\fInum\fR
  \&\fB\-msse2avx  \-mfentry  \-mrecord\-mcount  \-mnop\-mcount  \-m8bit\-idiv
  \&\-minstrument\-return=\fR\fItype\fR \fB\-mfentry\-name=\fR\fIname\fR \fB\-mfentry\-section=\fR\fIname\fR
*************** See \s-1RS/6000\s0 and PowerPC Options.
*** 1481,1487 ****
  \&\-mauto\-litpools  \-mno\-auto\-litpools
  \&\-mtarget\-align  \-mno\-target\-align
  \&\-mlongcalls  \-mno\-longcalls
! \&\-mabi=\fR\fIabi-type\fR
  \&\fB\-mextra\-l32r\-costs=\fR\fIcycles\fR
  .Sp
  \&\fIzSeries Options\fR
--- 1406,1412 ----
  \&\-mauto\-litpools  \-mno\-auto\-litpools
  \&\-mtarget\-align  \-mno\-target\-align
  \&\-mlongcalls  \-mno\-longcalls
! \&\-mabi=\fR\fIabi\-type\fR
  \&\fB\-mextra\-l32r\-costs=\fR\fIcycles\fR
  .Sp
  \&\fIzSeries Options\fR
*************** See S/390 and zSeries Options.
*** 1489,1495 ****
  .SS "Options Controlling the Kind of Output"
  .IX Subsection "Options Controlling the Kind of Output"
  Compilation can involve up to four stages: preprocessing, compilation
! proper, assembly and linking, always in that order.  \s-1GCC\s0 is capable of
  preprocessing and compiling several files either into several
  assembler input files, or into one assembler input file; then each
  assembler input file produces an object file, and linking combines all
--- 1414,1420 ----
  .SS "Options Controlling the Kind of Output"
  .IX Subsection "Options Controlling the Kind of Output"
  Compilation can involve up to four stages: preprocessing, compilation
! proper, assembly and linking, always in that order.  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
*************** into an executable file.
*** 1498,1664 ****
  .PP
  For any given input file, the file name suffix determines what kind of
  compilation is done:
! .IP "\fIfile\fR\fB.c\fR" 4
  .IX Item "file.c"
  C source code that must be preprocessed.
! .IP "\fIfile\fR\fB.i\fR" 4
  .IX Item "file.i"
  C source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.ii\fR" 4
  .IX Item "file.ii"
! \&\*(C+ source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.m\fR" 4
  .IX Item "file.m"
! Objective-C source code.  Note that you must link with the \fIlibobjc\fR
! library to make an Objective-C program work.
! .IP "\fIfile\fR\fB.mi\fR" 4
  .IX Item "file.mi"
! Objective-C source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.mm\fR" 4
  .IX Item "file.mm"
  .PD 0
! .IP "\fIfile\fR\fB.M\fR" 4
  .IX Item "file.M"
  .PD
! Objective\-\*(C+ source code.  Note that you must link with the \fIlibobjc\fR
! library to make an Objective\-\*(C+ program work.  Note that \fB.M\fR refers
  to a literal capital M.
! .IP "\fIfile\fR\fB.mii\fR" 4
  .IX Item "file.mii"
! Objective\-\*(C+ source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.h\fR" 4
  .IX Item "file.h"
! C, \*(C+, Objective-C or Objective\-\*(C+ header file to be turned into a
! precompiled header (default), or C, \*(C+ header file to be turned into an
  Ada spec (via the \fB\-fdump\-ada\-spec\fR switch).
! .IP "\fIfile\fR\fB.cc\fR" 4
  .IX Item "file.cc"
  .PD 0
! .IP "\fIfile\fR\fB.cp\fR" 4
  .IX Item "file.cp"
! .IP "\fIfile\fR\fB.cxx\fR" 4
  .IX Item "file.cxx"
! .IP "\fIfile\fR\fB.cpp\fR" 4
  .IX Item "file.cpp"
! .IP "\fIfile\fR\fB.CPP\fR" 4
  .IX Item "file.CPP"
! .IP "\fIfile\fR\fB.c++\fR" 4
  .IX Item "file.c++"
! .IP "\fIfile\fR\fB.C\fR" 4
  .IX Item "file.C"
  .PD
! \&\*(C+ source code that must be preprocessed.  Note that in \fB.cxx\fR,
  the last two letters must both be literally \fBx\fR.  Likewise,
  \&\fB.C\fR refers to a literal capital C.
! .IP "\fIfile\fR\fB.mm\fR" 4
  .IX Item "file.mm"
  .PD 0
! .IP "\fIfile\fR\fB.M\fR" 4
  .IX Item "file.M"
  .PD
! Objective\-\*(C+ source code that must be preprocessed.
! .IP "\fIfile\fR\fB.mii\fR" 4
  .IX Item "file.mii"
! Objective\-\*(C+ source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.hh\fR" 4
  .IX Item "file.hh"
  .PD 0
! .IP "\fIfile\fR\fB.H\fR" 4
  .IX Item "file.H"
! .IP "\fIfile\fR\fB.hp\fR" 4
  .IX Item "file.hp"
! .IP "\fIfile\fR\fB.hxx\fR" 4
  .IX Item "file.hxx"
! .IP "\fIfile\fR\fB.hpp\fR" 4
  .IX Item "file.hpp"
! .IP "\fIfile\fR\fB.HPP\fR" 4
  .IX Item "file.HPP"
! .IP "\fIfile\fR\fB.h++\fR" 4
  .IX Item "file.h++"
! .IP "\fIfile\fR\fB.tcc\fR" 4
  .IX Item "file.tcc"
  .PD
! \&\*(C+ header file to be turned into a precompiled header or Ada spec.
! .IP "\fIfile\fR\fB.f\fR" 4
  .IX Item "file.f"
  .PD 0
! .IP "\fIfile\fR\fB.for\fR" 4
  .IX Item "file.for"
! .IP "\fIfile\fR\fB.ftn\fR" 4
  .IX Item "file.ftn"
  .PD
  Fixed form Fortran source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.F\fR" 4
  .IX Item "file.F"
  .PD 0
! .IP "\fIfile\fR\fB.FOR\fR" 4
  .IX Item "file.FOR"
! .IP "\fIfile\fR\fB.fpp\fR" 4
  .IX Item "file.fpp"
! .IP "\fIfile\fR\fB.FPP\fR" 4
  .IX Item "file.FPP"
! .IP "\fIfile\fR\fB.FTN\fR" 4
  .IX Item "file.FTN"
  .PD
  Fixed form Fortran source code that must be preprocessed (with the traditional
  preprocessor).
! .IP "\fIfile\fR\fB.f90\fR" 4
  .IX Item "file.f90"
  .PD 0
! .IP "\fIfile\fR\fB.f95\fR" 4
  .IX Item "file.f95"
! .IP "\fIfile\fR\fB.f03\fR" 4
  .IX Item "file.f03"
! .IP "\fIfile\fR\fB.f08\fR" 4
  .IX Item "file.f08"
  .PD
  Free form Fortran source code that should not be preprocessed.
! .IP "\fIfile\fR\fB.F90\fR" 4
  .IX Item "file.F90"
  .PD 0
! .IP "\fIfile\fR\fB.F95\fR" 4
  .IX Item "file.F95"
! .IP "\fIfile\fR\fB.F03\fR" 4
  .IX Item "file.F03"
! .IP "\fIfile\fR\fB.F08\fR" 4
  .IX Item "file.F08"
  .PD
  Free form Fortran source code that must be preprocessed (with the
  traditional preprocessor).
! .IP "\fIfile\fR\fB.go\fR" 4
  .IX Item "file.go"
  Go source code.
! .IP "\fIfile\fR\fB.d\fR" 4
  .IX Item "file.d"
  D source code.
! .IP "\fIfile\fR\fB.di\fR" 4
  .IX Item "file.di"
  D interface file.
! .IP "\fIfile\fR\fB.dd\fR" 4
  .IX Item "file.dd"
  D documentation code (Ddoc).
! .IP "\fIfile\fR\fB.ads\fR" 4
  .IX Item "file.ads"
  Ada source code file that contains a library unit declaration (a
  declaration of a package, subprogram, or generic, or a generic
  instantiation), or a library unit renaming declaration (a package,
  generic, or subprogram renaming declaration).  Such files are also
  called \fIspecs\fR.
! .IP "\fIfile\fR\fB.adb\fR" 4
  .IX Item "file.adb"
  Ada source code file containing a library unit body (a subprogram or
  package body).  Such files are also called \fIbodies\fR.
! .IP "\fIfile\fR\fB.s\fR" 4
  .IX Item "file.s"
  Assembler code.
! .IP "\fIfile\fR\fB.S\fR" 4
  .IX Item "file.S"
  .PD 0
! .IP "\fIfile\fR\fB.sx\fR" 4
  .IX Item "file.sx"
  .PD
  Assembler code that must be preprocessed.
! .IP "\fIother\fR" 4
  .IX Item "other"
  An object file to be fed straight into linking.
  Any file name with no recognized suffix is treated this way.
--- 1423,1589 ----
  .PP
  For any given input file, the file name suffix determines what kind of
  compilation is done:
! .IP \fIfile\fR\fB.c\fR 4
  .IX Item "file.c"
  C source code that must be preprocessed.
! .IP \fIfile\fR\fB.i\fR 4
  .IX Item "file.i"
  C source code that should not be preprocessed.
! .IP \fIfile\fR\fB.ii\fR 4
  .IX Item "file.ii"
! C++ source code that should not be preprocessed.
! .IP \fIfile\fR\fB.m\fR 4
  .IX Item "file.m"
! Objective\-C source code.  Note that you must link with the \fIlibobjc\fR
! library to make an Objective\-C program work.
! .IP \fIfile\fR\fB.mi\fR 4
  .IX Item "file.mi"
! Objective\-C source code that should not be preprocessed.
! .IP \fIfile\fR\fB.mm\fR 4
  .IX Item "file.mm"
  .PD 0
! .IP \fIfile\fR\fB.M\fR 4
  .IX Item "file.M"
  .PD
! Objective\-C++ source code.  Note that you must link with the \fIlibobjc\fR
! library to make an Objective\-C++ program work.  Note that \fB.M\fR refers
  to a literal capital M.
! .IP \fIfile\fR\fB.mii\fR 4
  .IX Item "file.mii"
! Objective\-C++ source code that should not be preprocessed.
! .IP \fIfile\fR\fB.h\fR 4
  .IX Item "file.h"
! C, C++, Objective\-C or Objective\-C++ header file to be turned into a
! precompiled header (default), or C, C++ header file to be turned into an
  Ada spec (via the \fB\-fdump\-ada\-spec\fR switch).
! .IP \fIfile\fR\fB.cc\fR 4
  .IX Item "file.cc"
  .PD 0
! .IP \fIfile\fR\fB.cp\fR 4
  .IX Item "file.cp"
! .IP \fIfile\fR\fB.cxx\fR 4
  .IX Item "file.cxx"
! .IP \fIfile\fR\fB.cpp\fR 4
  .IX Item "file.cpp"
! .IP \fIfile\fR\fB.CPP\fR 4
  .IX Item "file.CPP"
! .IP \fIfile\fR\fB.c++\fR 4
  .IX Item "file.c++"
! .IP \fIfile\fR\fB.C\fR 4
  .IX Item "file.C"
  .PD
! C++ source code that must be preprocessed.  Note that in \fB.cxx\fR,
  the last two letters must both be literally \fBx\fR.  Likewise,
  \&\fB.C\fR refers to a literal capital C.
! .IP \fIfile\fR\fB.mm\fR 4
  .IX Item "file.mm"
  .PD 0
! .IP \fIfile\fR\fB.M\fR 4
  .IX Item "file.M"
  .PD
! Objective\-C++ source code that must be preprocessed.
! .IP \fIfile\fR\fB.mii\fR 4
  .IX Item "file.mii"
! Objective\-C++ source code that should not be preprocessed.
! .IP \fIfile\fR\fB.hh\fR 4
  .IX Item "file.hh"
  .PD 0
! .IP \fIfile\fR\fB.H\fR 4
  .IX Item "file.H"
! .IP \fIfile\fR\fB.hp\fR 4
  .IX Item "file.hp"
! .IP \fIfile\fR\fB.hxx\fR 4
  .IX Item "file.hxx"
! .IP \fIfile\fR\fB.hpp\fR 4
  .IX Item "file.hpp"
! .IP \fIfile\fR\fB.HPP\fR 4
  .IX Item "file.HPP"
! .IP \fIfile\fR\fB.h++\fR 4
  .IX Item "file.h++"
! .IP \fIfile\fR\fB.tcc\fR 4
  .IX Item "file.tcc"
  .PD
! C++ header file to be turned into a precompiled header or Ada spec.
! .IP \fIfile\fR\fB.f\fR 4
  .IX Item "file.f"
  .PD 0
! .IP \fIfile\fR\fB.for\fR 4
  .IX Item "file.for"
! .IP \fIfile\fR\fB.ftn\fR 4
  .IX Item "file.ftn"
  .PD
  Fixed form Fortran source code that should not be preprocessed.
! .IP \fIfile\fR\fB.F\fR 4
  .IX Item "file.F"
  .PD 0
! .IP \fIfile\fR\fB.FOR\fR 4
  .IX Item "file.FOR"
! .IP \fIfile\fR\fB.fpp\fR 4
  .IX Item "file.fpp"
! .IP \fIfile\fR\fB.FPP\fR 4
  .IX Item "file.FPP"
! .IP \fIfile\fR\fB.FTN\fR 4
  .IX Item "file.FTN"
  .PD
  Fixed form Fortran source code that must be preprocessed (with the traditional
  preprocessor).
! .IP \fIfile\fR\fB.f90\fR 4
  .IX Item "file.f90"
  .PD 0
! .IP \fIfile\fR\fB.f95\fR 4
  .IX Item "file.f95"
! .IP \fIfile\fR\fB.f03\fR 4
  .IX Item "file.f03"
! .IP \fIfile\fR\fB.f08\fR 4
  .IX Item "file.f08"
  .PD
  Free form Fortran source code that should not be preprocessed.
! .IP \fIfile\fR\fB.F90\fR 4
  .IX Item "file.F90"
  .PD 0
! .IP \fIfile\fR\fB.F95\fR 4
  .IX Item "file.F95"
! .IP \fIfile\fR\fB.F03\fR 4
  .IX Item "file.F03"
! .IP \fIfile\fR\fB.F08\fR 4
  .IX Item "file.F08"
  .PD
  Free form Fortran source code that must be preprocessed (with the
  traditional preprocessor).
! .IP \fIfile\fR\fB.go\fR 4
  .IX Item "file.go"
  Go source code.
! .IP \fIfile\fR\fB.d\fR 4
  .IX Item "file.d"
  D source code.
! .IP \fIfile\fR\fB.di\fR 4
  .IX Item "file.di"
  D interface file.
! .IP \fIfile\fR\fB.dd\fR 4
  .IX Item "file.dd"
  D documentation code (Ddoc).
! .IP \fIfile\fR\fB.ads\fR 4
  .IX Item "file.ads"
  Ada source code file that contains a library unit declaration (a
  declaration of a package, subprogram, or generic, or a generic
  instantiation), or a library unit renaming declaration (a package,
  generic, or subprogram renaming declaration).  Such files are also
  called \fIspecs\fR.
! .IP \fIfile\fR\fB.adb\fR 4
  .IX Item "file.adb"
  Ada source code file containing a library unit body (a subprogram or
  package body).  Such files are also called \fIbodies\fR.
! .IP \fIfile\fR\fB.s\fR 4
  .IX Item "file.s"
  Assembler code.
! .IP \fIfile\fR\fB.S\fR 4
  .IX Item "file.S"
  .PD 0
! .IP \fIfile\fR\fB.sx\fR 4
  .IX Item "file.sx"
  .PD
  Assembler code that must be preprocessed.
! .IP \fIother\fR 4
  .IX Item "other"
  An object file to be fed straight into linking.
  Any file name with no recognized suffix is treated this way.
*************** Specify explicitly the \fIlanguage\fR fo
*** 1671,1686 ****
  name suffix).  This option applies to all following input files until
  the next \fB\-x\fR option.  Possible values for \fIlanguage\fR are:
  .Sp
! .Vb 9
  \&        c  c\-header  cpp\-output
  \&        c++  c++\-header  c++\-system\-header c++\-user\-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
  \&        d
! \&        f77  f77\-cpp\-input f95  f95\-cpp\-input
  \&        go
  .Ve
  .IP "\fB\-x none\fR" 4
  .IX Item "-x none"
--- 1596,1615 ----
  name suffix).  This option applies to all following input files until
  the next \fB\-x\fR option.  Possible values for \fIlanguage\fR are:
  .Sp
! .Vb 10
  \&        c  c\-header  cpp\-output
  \&        c++  c++\-header  c++\-system\-header c++\-user\-header c++\-cpp\-output
! \&        objective\-c  objective\-c\-header  objective\-c\-cpp\-output  objc\-cpp\-output
! \&        objective\-c++  objective\-c++\-header  objective\-c++\-cpp\-output
! \&        objc++\-cpp\-output
  \&        assembler  assembler\-with\-cpp
! \&        ada  adascil  adawhy
  \&        d
! \&        f77  f77\-cpp\-input  f95  f95\-cpp\-input
  \&        go
+ \&        modula\-2  modula\-2\-cpp\-output
+ \&        rust
+ \&        lto
  .Ve
  .IP "\fB\-x none\fR" 4
  .IX Item "-x none"
*************** If you only want some of the stages of c
*** 1692,1699 ****
  \&\fB\-x\fR (or filename suffixes) to tell \fBgcc\fR where to start, and
  one of the options \fB\-c\fR, \fB\-S\fR, or \fB\-E\fR to say where
  \&\fBgcc\fR is to stop.  Note that some combinations (for example,
! \&\fB\-x cpp-output \-E\fR) instruct \fBgcc\fR to do nothing at all.
! .IP "\fB\-c\fR" 4
  .IX Item "-c"
  Compile or assemble the source files, but do not link.  The linking
  stage simply is not done.  The ultimate output is in the form of an
--- 1621,1628 ----
  \&\fB\-x\fR (or filename suffixes) to tell \fBgcc\fR where to start, and
  one of the options \fB\-c\fR, \fB\-S\fR, or \fB\-E\fR to say where
  \&\fBgcc\fR is to stop.  Note that some combinations (for example,
! \&\fB\-x cpp\-output \-E\fR) instruct \fBgcc\fR to do nothing at all.
! .IP \fB\-c\fR 4
  .IX Item "-c"
  Compile or assemble the source files, but do not link.  The linking
  stage simply is not done.  The ultimate output is in the form of an
*************** the suffix \fB.c\fR, \fB.i\fR, \fB.s\fR,
*** 1704,1726 ****
  .Sp
  Unrecognized input files, not requiring compilation or assembly, are
  ignored.
! .IP "\fB\-S\fR" 4
  .IX Item "-S"
  Stop after the stage of compilation proper; do not assemble.  The output
! is in the form of an assembler code file for each non-assembler input
  file specified.
  .Sp
  By default, the assembler file name for a source file is made by
  replacing the suffix \fB.c\fR, \fB.i\fR, etc., with \fB.s\fR.
  .Sp
! Input files that don't require compilation are ignored.
! .IP "\fB\-E\fR" 4
  .IX Item "-E"
  Stop after the preprocessing stage; do not run the compiler proper.  The
  output is in the form of preprocessed source code, which is sent to the
  standard output.
  .Sp
! Input files that don't require preprocessing are ignored.
  .IP "\fB\-o\fR \fIfile\fR" 4
  .IX Item "-o file"
  Place the primary output in file \fIfile\fR.  This applies to whatever
--- 1633,1655 ----
  .Sp
  Unrecognized input files, not requiring compilation or assembly, are
  ignored.
! .IP \fB\-S\fR 4
  .IX Item "-S"
  Stop after the stage of compilation proper; do not assemble.  The output
! is in the form of an assembler code file for each non\-assembler input
  file specified.
  .Sp
  By default, the assembler file name for a source file is made by
  replacing the suffix \fB.c\fR, \fB.i\fR, etc., with \fB.s\fR.
  .Sp
! Input files that don\*(Aqt require compilation are ignored.
! .IP \fB\-E\fR 4
  .IX Item "-E"
  Stop after the preprocessing stage; do not run the compiler proper.  The
  output is in the form of preprocessed source code, which is sent to the
  standard output.
  .Sp
! Input files that don\*(Aqt require preprocessing are ignored.
  .IP "\fB\-o\fR \fIfile\fR" 4
  .IX Item "-o file"
  Place the primary output in file \fIfile\fR.  This applies to whatever
*************** object file, an assembler file or prepro
*** 1729,1737 ****
  .Sp
  If \fB\-o\fR is not specified, the default is to put an executable
  file in \fIa.out\fR, the object file for
! \&\fI\fIsource\fI.\fIsuffix\fI\fR in \fI\fIsource\fI.o\fR, its
! assembler file in \fI\fIsource\fI.s\fR, a precompiled header file in
! \&\fI\fIsource\fI.\fIsuffix\fI.gch\fR, and all preprocessed C source on
  standard output.
  .Sp
  Though \fB\-o\fR names only the primary output, it also affects the
--- 1658,1666 ----
  .Sp
  If \fB\-o\fR is not specified, the default is to put an executable
  file in \fIa.out\fR, the object file for
! \&\fIsource.suffix\fR in \fIsource.o\fR, its
! assembler file in \fIsource.s\fR, a precompiled header file in
! \&\fIsource.suffix.gch\fR, and all preprocessed C source on
  standard output.
  .Sp
  Though \fB\-o\fR names only the primary output, it also affects the
*************** dumps next to it, e.g., aux file \fIfoo.
*** 1756,1762 ****
  \&\fB\-gsplit\-dwarf\fR, and dump file \fIfoo.c.???r.final\fR for
  \&\fB\-fdump\-rtl\-final\fR.
  .Sp
! If a non-linker output file is explicitly specified, aux and dump files
  by default take the same base name:
  .Sp
  .Vb 1
--- 1685,1691 ----
  \&\fB\-gsplit\-dwarf\fR, and dump file \fIfoo.c.???r.final\fR for
  \&\fB\-fdump\-rtl\-final\fR.
  .Sp
! If a non\-linker output file is explicitly specified, aux and dump files
  by default take the same base name:
  .Sp
  .Vb 1
*************** an intermediate, thus auxiliary output),
*** 1813,1826 ****
  (implied) output file \fIfoo.o\fR.
  .Sp
  Absent this option, dump and aux files take their names from the input
! file, or from the (non-linker) output file, if one is explicitly
  specified: dump output files (e.g. those requested by \fB\-fdump\-*\fR
  options) with the input name suffix, and aux output files (those
! requested by other non-dump options, e.g. \f(CW\*(C`\-save\-temps\*(C'\fR,
  \&\f(CW\*(C`\-gsplit\-dwarf\*(C'\fR, \f(CW\*(C`\-fcallgraph\-info\*(C'\fR) without it.
  .Sp
  Similar suffix differentiation of dump and aux outputs can be attained
! for explicitly-given \fB\-dumpbase basename.suf\fR by also specifying
  \&\fB\-dumpbase\-ext .suf\fR.
  .Sp
  If \fIdumpbase\fR is explicitly specified with any directory component,
--- 1742,1755 ----
  (implied) output file \fIfoo.o\fR.
  .Sp
  Absent this option, dump and aux files take their names from the input
! file, or from the (non\-linker) output file, if one is explicitly
  specified: dump output files (e.g. those requested by \fB\-fdump\-*\fR
  options) with the input name suffix, and aux output files (those
! requested by other non\-dump options, e.g. \f(CW\*(C`\-save\-temps\*(C'\fR,
  \&\f(CW\*(C`\-gsplit\-dwarf\*(C'\fR, \f(CW\*(C`\-fcallgraph\-info\*(C'\fR) without it.
  .Sp
  Similar suffix differentiation of dump and aux outputs can be attained
! for explicitly\-given \fB\-dumpbase basename.suf\fR by also specifying
  \&\fB\-dumpbase\-ext .suf\fR.
  .Sp
  If \fIdumpbase\fR is explicitly specified with any directory component,
*************** will name aux outputs \fIdir/foo.*\fR an
*** 1865,1871 ****
  \&\fIdir/foo.c.*\fR.  Note how their basenames are taken from the input
  name, but the directory still defaults to that of the output.
  .Sp
! The empty-string dumpbase does not prevent the use of the output
  basename for outputs during linking:
  .Sp
  .Vb 1
--- 1794,1800 ----
  \&\fIdir/foo.c.*\fR.  Note how their basenames are taken from the input
  name, but the directory still defaults to that of the output.
  .Sp
! The empty\-string dumpbase does not prevent the use of the output
  basename for outputs during linking:
  .Sp
  .Vb 1
*************** basename for outputs during linking:
*** 1874,1880 ****
  .Sp
  The compilation of the source files will name auxiliary outputs
  \&\fIdir/foo.*\fR and \fIdir/bar.*\fR, and dump outputs
! \&\fIdir/foo.c.*\fR and \fIdir/bar.c.*\fR.  \s-1LTO\s0 recompilation during
  linking will use \fIdir/foobar.\fR as the prefix for dumps and
  auxiliary files.
  .IP "\fB\-dumpbase\-ext\fR \fIauxdropsuf\fR" 4
--- 1803,1809 ----
  .Sp
  The compilation of the source files will name auxiliary outputs
  \&\fIdir/foo.*\fR and \fIdir/bar.*\fR, and dump outputs
! \&\fIdir/foo.c.*\fR and \fIdir/bar.c.*\fR.  LTO recompilation during
  linking will use \fIdir/foobar.\fR as the prefix for dumps and
  auxiliary files.
  .IP "\fB\-dumpbase\-ext\fR \fIauxdropsuf\fR" 4
*************** When compiling from multiple input files
*** 1957,1963 ****
  specified, \fIdumpbase\fR, minus a \fIauxdropsuf\fR suffix, and a dash
  are appended to (or override, if containing any directory components) an
  explicit or defaulted \fIdumppfx\fR, so that each of the multiple
! compilations gets differently-named aux and dump outputs.
  .Sp
  .Vb 1
  \&        gcc foo.c bar.c \-c \-dumpdir dir/pfx\- \-dumpbase main ...
--- 1886,1892 ----
  specified, \fIdumpbase\fR, minus a \fIauxdropsuf\fR suffix, and a dash
  are appended to (or override, if containing any directory components) an
  explicit or defaulted \fIdumppfx\fR, so that each of the multiple
! compilations gets differently\-named aux and dump outputs.
  .Sp
  .Vb 1
  \&        gcc foo.c bar.c \-c \-dumpdir dir/pfx\- \-dumpbase main ...
*************** outputs auxiliary dumps to \fIdir/pfx\-m
*** 1967,1973 ****
  \&\fIdir/pfx\-main\-bar.*\fR, appending \fIdumpbase\fR\- to \fIdumppfx\fR.
  Dump outputs retain the input file suffix: \fIdir/pfx\-main\-foo.c.*\fR
  and \fIdir/pfx\-main\-bar.c.*\fR, respectively.  Contrast with the
! single-input compilation:
  .Sp
  .Vb 1
  \&        gcc foo.c \-c \-dumpdir dir/pfx\- \-dumpbase main ...
--- 1896,1902 ----
  \&\fIdir/pfx\-main\-bar.*\fR, appending \fIdumpbase\fR\- to \fIdumppfx\fR.
  Dump outputs retain the input file suffix: \fIdir/pfx\-main\-foo.c.*\fR
  and \fIdir/pfx\-main\-bar.c.*\fR, respectively.  Contrast with the
! single\-input compilation:
  .Sp
  .Vb 1
  \&        gcc foo.c \-c \-dumpdir dir/pfx\- \-dumpbase main ...
*************** instead.  Note, however, that unlike ear
*** 1992,2006 ****
  .Sp
  does not append the output name \fImain\fR to \fIdumppfx\fR, because
  \&\fB\-dumpdir\fR is explicitly specified.  The goal is that the
! explicitly-specified \fIdumppfx\fR may contain the specified output name
! as part of the prefix, if desired; only an explicitly-specified
  \&\fB\-dumpbase\fR would be combined with it, in order to avoid simply
  discarding a meaningful option.
  .Sp
  When compiling and then linking from a single input file, the linker
  output base name will only be appended to the default \fIdumppfx\fR as
  above if it does not share the base name with the single input file
! name.  This has been covered in single-input linking cases above, but
  not with an explicit \fB\-dumpdir\fR that inhibits the combination,
  even if overridden by \fB\-save\-temps=*\fR:
  .Sp
--- 1921,1935 ----
  .Sp
  does not append the output name \fImain\fR to \fIdumppfx\fR, because
  \&\fB\-dumpdir\fR is explicitly specified.  The goal is that the
! explicitly\-specified \fIdumppfx\fR may contain the specified output name
! as part of the prefix, if desired; only an explicitly\-specified
  \&\fB\-dumpbase\fR would be combined with it, in order to avoid simply
  discarding a meaningful option.
  .Sp
  When compiling and then linking from a single input file, the linker
  output base name will only be appended to the default \fIdumppfx\fR as
  above if it does not share the base name with the single input file
! name.  This has been covered in single\-input linking cases above, but
  not with an explicit \fB\-dumpdir\fR that inhibits the combination,
  even if overridden by \fB\-save\-temps=*\fR:
  .Sp
*************** for each input are formed by combining \
*** 2023,2118 ****
  minus suffix, and the auxiliary output suffix; dump output names are
  only different in that the suffix from \fIdumpbase\fR is retained.
  .Sp
! When it comes to auxiliary and dump outputs created during \s-1LTO\s0
  recompilation, a combination of \fIdumppfx\fR and \fIdumpbase\fR, as
  given or as derived from the linker output name but not from inputs,
  even in cases in which this combination would not otherwise be used as
! such, is passed down with a trailing period replacing the compiler-added
! dash, if any, as a \fB\-dumpdir\fR option to \fBlto-wrapper\fR;
  being involved in linking, this program does not normally get any
  \&\fB\-dumpbase\fR and \fB\-dumpbase\-ext\fR, and it ignores them.
  .Sp
! When running sub-compilers, \fBlto-wrapper\fR appends \s-1LTO\s0 stage
  names to the received \fIdumppfx\fR, ensures it contains a directory
  component so that it overrides any \fB\-dumpdir\fR, and passes that as
! \&\fB\-dumpbase\fR to sub-compilers.
! .IP "\fB\-v\fR" 4
  .IX Item "-v"
  Print (on standard error output) the commands executed to run the stages
  of compilation.  Also print the version number of the compiler driver
  program and of the preprocessor and the compiler proper.
! .IP "\fB\-###\fR" 4
  .IX Item "-###"
  Like \fB\-v\fR except the commands are not executed and arguments
  are quoted unless they contain only alphanumeric characters or \f(CW\*(C`./\-_\*(C'\fR.
! This is useful for shell scripts to capture the driver-generated command lines.
! .IP "\fB\-\-help\fR" 4
  .IX Item "--help"
! Print (on the standard output) a description of the command-line options
  understood by \fBgcc\fR.  If the \fB\-v\fR option is also specified
  then \fB\-\-help\fR is also passed on to the various processes
! invoked by \fBgcc\fR, so that they can display the command-line options
  they accept.  If the \fB\-Wextra\fR option has also been specified
! (prior to the \fB\-\-help\fR option), then command-line options that
  have no documentation associated with them are also displayed.
! .IP "\fB\-\-target\-help\fR" 4
  .IX Item "--target-help"
! Print (on the standard output) a description of target-specific command-line
! options for each tool.  For some targets extra target-specific
  information may also be printed.
! .IP "\fB\-\-help={\fR\fIclass\fR|[\fB^\fR]\fIqualifier\fR\fB}\fR[\fB,...\fR]" 4
  .IX Item "--help={class|[^]qualifier}[,...]"
! Print (on the standard output) a description of the command-line
  options understood by the compiler that fit into all specified classes
  and qualifiers.  These are the supported classes:
  .RS 4
! .IP "\fBoptimizers\fR" 4
  .IX Item "optimizers"
  Display all of the optimization options supported by the
  compiler.
! .IP "\fBwarnings\fR" 4
  .IX Item "warnings"
  Display all of the options controlling warning messages
  produced by the compiler.
! .IP "\fBtarget\fR" 4
  .IX Item "target"
! Display target-specific options.  Unlike the
! \&\fB\-\-target\-help\fR option however, target-specific options of the
  linker and assembler are not displayed.  This is because those
  tools do not currently support the extended \fB\-\-help=\fR syntax.
! .IP "\fBparams\fR" 4
  .IX Item "params"
  Display the values recognized by the \fB\-\-param\fR
  option.
! .IP "\fIlanguage\fR" 4
  .IX Item "language"
  Display the options supported for \fIlanguage\fR, where
  \&\fIlanguage\fR is the name of one of the languages supported in this
! version of \s-1GCC.\s0  If an option is supported by all languages, one needs
  to select \fBcommon\fR class.
! .IP "\fBcommon\fR" 4
  .IX Item "common"
  Display the options that are common to all languages.
  .RE
  .RS 4
  .Sp
  These are the supported qualifiers:
! .IP "\fBundocumented\fR" 4
  .IX Item "undocumented"
  Display only those options that are undocumented.
! .IP "\fBjoined\fR" 4
  .IX Item "joined"
  Display options taking an argument that appears after an equal
  sign in the same continuous piece of text, such as:
  \&\fB\-\-help=target\fR.
! .IP "\fBseparate\fR" 4
  .IX Item "separate"
  Display options taking an argument that appears as a separate word
! following the original option, such as: \fB\-o output-file\fR.
  .RE
  .RS 4
  .Sp
! Thus for example to display all the undocumented target-specific
  switches supported by the compiler, use:
  .Sp
  .Vb 1
--- 1952,2047 ----
  minus suffix, and the auxiliary output suffix; dump output names are
  only different in that the suffix from \fIdumpbase\fR is retained.
  .Sp
! When it comes to auxiliary and dump outputs created during LTO
  recompilation, a combination of \fIdumppfx\fR and \fIdumpbase\fR, as
  given or as derived from the linker output name but not from inputs,
  even in cases in which this combination would not otherwise be used as
! such, is passed down with a trailing period replacing the compiler\-added
! dash, if any, as a \fB\-dumpdir\fR option to \fBlto\-wrapper\fR;
  being involved in linking, this program does not normally get any
  \&\fB\-dumpbase\fR and \fB\-dumpbase\-ext\fR, and it ignores them.
  .Sp
! When running sub\-compilers, \fBlto\-wrapper\fR appends LTO stage
  names to the received \fIdumppfx\fR, ensures it contains a directory
  component so that it overrides any \fB\-dumpdir\fR, and passes that as
! \&\fB\-dumpbase\fR to sub\-compilers.
! .IP \fB\-v\fR 4
  .IX Item "-v"
  Print (on standard error output) the commands executed to run the stages
  of compilation.  Also print the version number of the compiler driver
  program and of the preprocessor and the compiler proper.
! .IP \fB\-###\fR 4
  .IX Item "-###"
  Like \fB\-v\fR except the commands are not executed and arguments
  are quoted unless they contain only alphanumeric characters or \f(CW\*(C`./\-_\*(C'\fR.
! This is useful for shell scripts to capture the driver\-generated command lines.
! .IP \fB\-\-help\fR 4
  .IX Item "--help"
! Print (on the standard output) a description of the command\-line options
  understood by \fBgcc\fR.  If the \fB\-v\fR option is also specified
  then \fB\-\-help\fR is also passed on to the various processes
! invoked by \fBgcc\fR, so that they can display the command\-line options
  they accept.  If the \fB\-Wextra\fR option has also been specified
! (prior to the \fB\-\-help\fR option), then command\-line options that
  have no documentation associated with them are also displayed.
! .IP \fB\-\-target\-help\fR 4
  .IX Item "--target-help"
! Print (on the standard output) a description of target\-specific command\-line
! options for each tool.  For some targets extra target\-specific
  information may also be printed.
! .IP \fB\-\-help={\fR\fIclass\fR|[\fB^\fR]\fIqualifier\fR\fB}\fR[\fB,...\fR] 4
  .IX Item "--help={class|[^]qualifier}[,...]"
! Print (on the standard output) a description of the command\-line
  options understood by the compiler that fit into all specified classes
  and qualifiers.  These are the supported classes:
  .RS 4
! .IP \fBoptimizers\fR 4
  .IX Item "optimizers"
  Display all of the optimization options supported by the
  compiler.
! .IP \fBwarnings\fR 4
  .IX Item "warnings"
  Display all of the options controlling warning messages
  produced by the compiler.
! .IP \fBtarget\fR 4
  .IX Item "target"
! Display target\-specific options.  Unlike the
! \&\fB\-\-target\-help\fR option however, target\-specific options of the
  linker and assembler are not displayed.  This is because those
  tools do not currently support the extended \fB\-\-help=\fR syntax.
! .IP \fBparams\fR 4
  .IX Item "params"
  Display the values recognized by the \fB\-\-param\fR
  option.
! .IP \fIlanguage\fR 4
  .IX Item "language"
  Display the options supported for \fIlanguage\fR, where
  \&\fIlanguage\fR is the name of one of the languages supported in this
! version of GCC.  If an option is supported by all languages, one needs
  to select \fBcommon\fR class.
! .IP \fBcommon\fR 4
  .IX Item "common"
  Display the options that are common to all languages.
  .RE
  .RS 4
  .Sp
  These are the supported qualifiers:
! .IP \fBundocumented\fR 4
  .IX Item "undocumented"
  Display only those options that are undocumented.
! .IP \fBjoined\fR 4
  .IX Item "joined"
  Display options taking an argument that appears after an equal
  sign in the same continuous piece of text, such as:
  \&\fB\-\-help=target\fR.
! .IP \fBseparate\fR 4
  .IX Item "separate"
  Display options taking an argument that appears as a separate word
! following the original option, such as: \fB\-o output\-file\fR.
  .RE
  .RS 4
  .Sp
! Thus for example to display all the undocumented target\-specific
  switches supported by the compiler, use:
  .Sp
  .Vb 1
*************** qualifiers.
*** 2134,2140 ****
  Combining several classes is possible, although this usually
  restricts the output so much that there is nothing to display.  One
  case where it does work, however, is when one of the classes is
! \&\fItarget\fR.  For example, to display all the target-specific
  optimization options, use:
  .Sp
  .Vb 1
--- 2063,2069 ----
  Combining several classes is possible, although this usually
  restricts the output so much that there is nothing to display.  One
  case where it does work, however, is when one of the classes is
! \&\fItarget\fR.  For example, to display all the target\-specific
  optimization options, use:
  .Sp
  .Vb 1
*************** options, an indication is given as to wh
*** 2154,2160 ****
  disabled or set to a specific value (assuming that the compiler
  knows this at the point where the \fB\-\-help=\fR option is used).
  .Sp
! Here is a truncated example from the \s-1ARM\s0 port of \fBgcc\fR:
  .Sp
  .Vb 5
  \&          % gcc \-Q \-mabi=2 \-\-help=target \-c
--- 2083,2089 ----
  disabled or set to a specific value (assuming that the compiler
  knows this at the point where the \fB\-\-help=\fR option is used).
  .Sp
! Here is a truncated example from the ARM port of \fBgcc\fR:
  .Sp
  .Vb 5
  \&          % gcc \-Q \-mabi=2 \-\-help=target \-c
*************** Here is a truncated example from the \s-
*** 2164,2170 ****
  \&          \-mapcs                                [disabled]
  .Ve
  .Sp
! The output is sensitive to the effects of previous command-line
  options, so for example it is possible to find out which optimizations
  are enabled at \fB\-O2\fR by using:
  .Sp
--- 2093,2099 ----
  \&          \-mapcs                                [disabled]
  .Ve
  .Sp
! The output is sensitive to the effects of previous command\-line
  options, so for example it is possible to find out which optimizations
  are enabled at \fB\-O2\fR by using:
  .Sp
*************** by \fB\-O3\fR by using:
*** 2181,2204 ****
  \&        diff /tmp/O2\-opts /tmp/O3\-opts | grep enabled
  .Ve
  .RE
! .IP "\fB\-\-version\fR" 4
  .IX Item "--version"
! Display the version number and copyrights of the invoked \s-1GCC.\s0
! .IP "\fB\-pass\-exit\-codes\fR" 4
  .IX Item "-pass-exit-codes"
  Normally the \fBgcc\fR program exits with the code of 1 if any
! phase of the compiler returns a non-success return code.  If you specify
  \&\fB\-pass\-exit\-codes\fR, the \fBgcc\fR program instead returns with
  the numerically highest error produced by any phase returning an error
! indication.  The C, \*(C+, and Fortran front ends return 4 if an internal
  compiler error is encountered.
! .IP "\fB\-pipe\fR" 4
  .IX Item "-pipe"
  Use pipes rather than temporary files for communication between the
  various stages of compilation.  This fails to work on some systems where
! the assembler is unable to read from a pipe; but the \s-1GNU\s0 assembler has
  no trouble.
! .IP "\fB\-specs=\fR\fIfile\fR" 4
  .IX Item "-specs=file"
  Process \fIfile\fR after the compiler reads in the standard \fIspecs\fR
  file, in order to override the defaults which the \fBgcc\fR driver
--- 2110,2133 ----
  \&        diff /tmp/O2\-opts /tmp/O3\-opts | grep enabled
  .Ve
  .RE
! .IP \fB\-\-version\fR 4
  .IX Item "--version"
! Display the version number and copyrights of the invoked GCC.
! .IP \fB\-pass\-exit\-codes\fR 4
  .IX Item "-pass-exit-codes"
  Normally the \fBgcc\fR program exits with the code of 1 if any
! phase of the compiler returns a non\-success return code.  If you specify
  \&\fB\-pass\-exit\-codes\fR, the \fBgcc\fR program instead returns with
  the numerically highest error produced by any phase returning an error
! indication.  The C, C++, and Fortran front ends return 4 if an internal
  compiler error is encountered.
! .IP \fB\-pipe\fR 4
  .IX Item "-pipe"
  Use pipes rather than temporary files for communication between the
  various stages of compilation.  This fails to work on some systems where
! the assembler is unable to read from a pipe; but the GNU assembler has
  no trouble.
! .IP \fB\-specs=\fR\fIfile\fR 4
  .IX Item "-specs=file"
  Process \fIfile\fR after the compiler reads in the standard \fIspecs\fR
  file, in order to override the defaults which the \fBgcc\fR driver
*************** program uses when determining what switc
*** 2206,2212 ****
  \&\fBcc1plus\fR, \fBas\fR, \fBld\fR, etc.  More than one
  \&\fB\-specs=\fR\fIfile\fR can be specified on the command line, and they
  are processed in order, from left to right.
! .IP "\fB\-wrapper\fR" 4
  .IX Item "-wrapper"
  Invoke all subcommands under a wrapper program.  The name of the
  wrapper program and its parameters are passed as a comma separated
--- 2135,2141 ----
  \&\fBcc1plus\fR, \fBas\fR, \fBld\fR, etc.  More than one
  \&\fB\-specs=\fR\fIfile\fR can be specified on the command line, and they
  are processed in order, from left to right.
! .IP \fB\-wrapper\fR 4
  .IX Item "-wrapper"
  Invoke all subcommands under a wrapper program.  The name of the
  wrapper program and its parameters are passed as a comma separated
*************** list.
*** 2219,2275 ****
  This invokes all subprograms of \fBgcc\fR under
  \&\fBgdb \-\-args\fR, thus the invocation of \fBcc1\fR is
  \&\fBgdb \-\-args cc1 ...\fR.
! .IP "\fB\-ffile\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
  .IX Item "-ffile-prefix-map=old=new"
! When compiling files residing in directory \fI\fIold\fI\fR, record
  any references to them in the result of the compilation as if the
! files resided in directory \fI\fInew\fI\fR instead.  Specifying this
  option is equivalent to specifying all the individual
  \&\fB\-f*\-prefix\-map\fR options.  This can be used to make reproducible
  builds that are location independent.  Directories referenced by
  directives are not affected by these options.  See also
  \&\fB\-fmacro\-prefix\-map\fR, \fB\-fdebug\-prefix\-map\fR,
  \&\fB\-fprofile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP "\fB\-fcanon\-prefix\-map\fR" 4
  .IX Item "-fcanon-prefix-map"
  For the \fB\-f*\-prefix\-map\fR options normally comparison
! of \fI\fIold\fI\fR prefix against the filename that would be normally
  referenced in the result of the compilation is done using textual
  comparison of the prefixes, or ignoring character case for case insensitive
! filesystems and considering slashes and backslashes as equal on \s-1DOS\s0 based
  filesystems.  The \fB\-fcanon\-prefix\-map\fR causes such comparisons
! to be done on canonicalized paths of \fI\fIold\fI\fR
  and the referenced filename.
! .IP "\fB\-fplugin=\fR\fIname\fR\fB.so\fR" 4
  .IX Item "-fplugin=name.so"
  Load the plugin code in file \fIname\fR.so, assumed to be a
! shared object to be dlopen'd by the compiler.  The base name of
  the shared object file is used to identify the plugin for the
  purposes of argument parsing (See
  \&\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR below).
  Each plugin should define the callback functions specified in the
! Plugins \s-1API.\s0
! .IP "\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR" 4
  .IX Item "-fplugin-arg-name-key=value"
  Define an argument called \fIkey\fR with a value of \fIvalue\fR
  for the plugin called \fIname\fR.
! .IP "\fB\-fdump\-ada\-spec\fR[\fB\-slim\fR]" 4
  .IX Item "-fdump-ada-spec[-slim]"
! For C and \*(C+ source and include files, generate corresponding Ada specs.
! .IP "\fB\-fada\-spec\-parent=\fR\fIunit\fR" 4
  .IX Item "-fada-spec-parent=unit"
  In conjunction with \fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] above, generate
  Ada specs as child units of parent \fIunit\fR.
! .IP "\fB\-fdump\-go\-spec=\fR\fIfile\fR" 4
  .IX Item "-fdump-go-spec=file"
  For input files in any language, generate corresponding Go
  declarations in \fIfile\fR.  This generates Go \f(CW\*(C`const\*(C'\fR,
  \&\f(CW\*(C`type\*(C'\fR, \f(CW\*(C`var\*(C'\fR, and \f(CW\*(C`func\*(C'\fR declarations which may be a
  useful way to start writing a Go interface to code written in some
  other language.
! .IP "\fB@\fR\fIfile\fR" 4
  .IX Item "@file"
! Read command-line options from \fIfile\fR.  The options read are
  inserted in place of the original @\fIfile\fR option.  If \fIfile\fR
  does not exist, or cannot be read, then the option will be treated
  literally, and not removed.
--- 2148,2204 ----
  This invokes all subprograms of \fBgcc\fR under
  \&\fBgdb \-\-args\fR, thus the invocation of \fBcc1\fR is
  \&\fBgdb \-\-args cc1 ...\fR.
! .IP \fB\-ffile\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 4
  .IX Item "-ffile-prefix-map=old=new"
! When compiling files residing in directory \fIold\fR, record
  any references to them in the result of the compilation as if the
! files resided in directory \fInew\fR instead.  Specifying this
  option is equivalent to specifying all the individual
  \&\fB\-f*\-prefix\-map\fR options.  This can be used to make reproducible
  builds that are location independent.  Directories referenced by
  directives are not affected by these options.  See also
  \&\fB\-fmacro\-prefix\-map\fR, \fB\-fdebug\-prefix\-map\fR,
  \&\fB\-fprofile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP \fB\-fcanon\-prefix\-map\fR 4
  .IX Item "-fcanon-prefix-map"
  For the \fB\-f*\-prefix\-map\fR options normally comparison
! of \fIold\fR prefix against the filename that would be normally
  referenced in the result of the compilation is done using textual
  comparison of the prefixes, or ignoring character case for case insensitive
! filesystems and considering slashes and backslashes as equal on DOS based
  filesystems.  The \fB\-fcanon\-prefix\-map\fR causes such comparisons
! to be done on canonicalized paths of \fIold\fR
  and the referenced filename.
! .IP \fB\-fplugin=\fR\fIname\fR\fB.so\fR 4
  .IX Item "-fplugin=name.so"
  Load the plugin code in file \fIname\fR.so, assumed to be a
! shared object to be dlopen\*(Aqd by the compiler.  The base name of
  the shared object file is used to identify the plugin for the
  purposes of argument parsing (See
  \&\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR below).
  Each plugin should define the callback functions specified in the
! Plugins API.
! .IP \fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR 4
  .IX Item "-fplugin-arg-name-key=value"
  Define an argument called \fIkey\fR with a value of \fIvalue\fR
  for the plugin called \fIname\fR.
! .IP \fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] 4
  .IX Item "-fdump-ada-spec[-slim]"
! For C and C++ source and include files, generate corresponding Ada specs.
! .IP \fB\-fada\-spec\-parent=\fR\fIunit\fR 4
  .IX Item "-fada-spec-parent=unit"
  In conjunction with \fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] above, generate
  Ada specs as child units of parent \fIunit\fR.
! .IP \fB\-fdump\-go\-spec=\fR\fIfile\fR 4
  .IX Item "-fdump-go-spec=file"
  For input files in any language, generate corresponding Go
  declarations in \fIfile\fR.  This generates Go \f(CW\*(C`const\*(C'\fR,
  \&\f(CW\*(C`type\*(C'\fR, \f(CW\*(C`var\*(C'\fR, and \f(CW\*(C`func\*(C'\fR declarations which may be a
  useful way to start writing a Go interface to code written in some
  other language.
! .IP \fB@\fR\fIfile\fR 4
  .IX Item "@file"
! Read command\-line options from \fIfile\fR.  The options read are
  inserted in place of the original @\fIfile\fR option.  If \fIfile\fR
  does not exist, or cannot be read, then the option will be treated
  literally, and not removed.
*************** option in either single or double quotes
*** 2280,2569 ****
  backslash) may be included by prefixing the character to be included
  with a backslash.  The \fIfile\fR may itself contain additional
  @\fIfile\fR options; any such options will be processed recursively.
! .SS "Compiling \*(C+ Programs"
! .IX Subsection "Compiling Programs"
! \&\*(C+ source files conventionally use one of the suffixes \fB.C\fR,
  \&\fB.cc\fR, \fB.cpp\fR, \fB.CPP\fR, \fB.c++\fR, \fB.cp\fR, or
! \&\fB.cxx\fR; \*(C+ header files often use \fB.hh\fR, \fB.hpp\fR,
  \&\fB.H\fR, or (for shared template code) \fB.tcc\fR; and
! preprocessed \*(C+ files use the suffix \fB.ii\fR.  \s-1GCC\s0 recognizes
! files with these names and compiles them as \*(C+ programs even if you
  call the compiler the same way as for compiling C programs (usually
  with the name \fBgcc\fR).
  .PP
! However, the use of \fBgcc\fR does not add the \*(C+ library.
! \&\fBg++\fR is a program that calls \s-1GCC\s0 and automatically specifies linking
! against the \*(C+ library.  It treats \fB.c\fR,
! \&\fB.h\fR and \fB.i\fR files as \*(C+ source files instead of C source
  files unless \fB\-x\fR is used.  This program is also useful when
! precompiling a C header file with a \fB.h\fR extension for use in \*(C+
  compilations.  On many systems, \fBg++\fR is also installed with
  the name \fBc++\fR.
  .PP
! When you compile \*(C+ programs, you may specify many of the same
! command-line options that you use for compiling programs in any
! language; or command-line options meaningful for C and related
! languages; or options that are meaningful only for \*(C+ programs.
  .SS "Options Controlling C Dialect"
  .IX Subsection "Options Controlling C Dialect"
  The following options control the dialect of C (or languages derived
! from C, such as \*(C+, Objective-C and Objective\-\*(C+) that the compiler
  accepts:
! .IP "\fB\-ansi\fR" 4
  .IX Item "-ansi"
! In C mode, this is equivalent to \fB\-std=c90\fR. In \*(C+ mode, it is
  equivalent to \fB\-std=c++98\fR.
  .Sp
! This turns off certain features of \s-1GCC\s0 that are incompatible with \s-1ISO
! C90\s0 (when compiling C code), or of standard \*(C+ (when compiling \*(C+ code),
  such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, and
  predefined macros such as \f(CW\*(C`unix\*(C'\fR and \f(CW\*(C`vax\*(C'\fR that identify the
  type of system you are using.  It also enables the undesirable and
! rarely used \s-1ISO\s0 trigraph feature.  For the C compiler,
! it disables recognition of \*(C+ style \fB//\fR comments as well as
  the \f(CW\*(C`inline\*(C'\fR keyword.
  .Sp
  The alternate keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_extension_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR continue to work despite
! \&\fB\-ansi\fR.  You would not want to use them in an \s-1ISO C\s0 program, of
  course, but it is useful to put them in header files that might be included
  in compilations done with \fB\-ansi\fR.  Alternate predefined macros
  such as \f(CW\*(C`_\|_unix_\|_\*(C'\fR and \f(CW\*(C`_\|_vax_\|_\*(C'\fR are also available, with or
  without \fB\-ansi\fR.
  .Sp
! The \fB\-ansi\fR option does not cause non-ISO programs to be
  rejected gratuitously.  For that, \fB\-Wpedantic\fR is required in
  addition to \fB\-ansi\fR.
  .Sp
  The macro \f(CW\*(C`_\|_STRICT_ANSI_\|_\*(C'\fR is predefined when the \fB\-ansi\fR
  option is used.  Some header files may notice this macro and refrain
  from declaring certain functions or defining certain macros that the
! \&\s-1ISO\s0 standard doesn't call for; this is to avoid interfering with any
  programs that might use these names for other things.
  .Sp
  Functions that are normally built in but do not have semantics
! defined by \s-1ISO C\s0 (such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built-in
  functions when \fB\-ansi\fR is used.
! .IP "\fB\-std=\fR" 4
  .IX Item "-std="
  Determine the language standard.   This option
! is currently only supported when compiling C or \*(C+.
  .Sp
  The compiler can accept several base standards, such as \fBc90\fR or
! \&\fBc++98\fR, and \s-1GNU\s0 dialects of those standards, such as
  \&\fBgnu90\fR or \fBgnu++98\fR.  When a base standard is specified, the
  compiler accepts all programs following that standard plus those
! using \s-1GNU\s0 extensions that do not contradict it.  For example,
! \&\fB\-std=c90\fR turns off certain features of \s-1GCC\s0 that are
! incompatible with \s-1ISO C90,\s0 such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR
! keywords, but not other \s-1GNU\s0 extensions that do not have a meaning in
! \&\s-1ISO C90,\s0 such as omitting the middle term of a \f(CW\*(C`?:\*(C'\fR
! expression. On the other hand, when a \s-1GNU\s0 dialect of a standard is
  specified, all features supported by the compiler are enabled, even when
  those features change the meaning of the base standard.  As a result, some
! strict-conforming programs may be rejected.  The particular standard
! is used by \fB\-Wpedantic\fR to identify which features are \s-1GNU\s0
  extensions given that version of the standard. For example
! \&\fB\-std=gnu90 \-Wpedantic\fR warns about \*(C+ style \fB//\fR
  comments, while \fB\-std=gnu99 \-Wpedantic\fR does not.
  .Sp
  A value for this option must be provided; possible values are
  .RS 4
! .IP "\fBc90\fR" 4
  .IX Item "c90"
  .PD 0
! .IP "\fBc89\fR" 4
  .IX Item "c89"
! .IP "\fBiso9899:1990\fR" 4
  .IX Item "iso9899:1990"
  .PD
! Support all \s-1ISO C90\s0 programs (certain \s-1GNU\s0 extensions that conflict
! with \s-1ISO C90\s0 are disabled). Same as \fB\-ansi\fR for C code.
! .IP "\fBiso9899:199409\fR" 4
  .IX Item "iso9899:199409"
! \&\s-1ISO C90\s0 as modified in amendment 1.
! .IP "\fBc99\fR" 4
  .IX Item "c99"
  .PD 0
! .IP "\fBc9x\fR" 4
  .IX Item "c9x"
! .IP "\fBiso9899:1999\fR" 4
  .IX Item "iso9899:1999"
! .IP "\fBiso9899:199x\fR" 4
  .IX Item "iso9899:199x"
  .PD
! \&\s-1ISO C99.\s0  This standard is substantially completely supported, modulo
! bugs and floating-point issues
  (mainly but not entirely relating to optional C99 features from
  Annexes F and G).  See
  <\fBhttps://gcc.gnu.org/c99status.html\fR> for more information.  The
  names \fBc9x\fR and \fBiso9899:199x\fR are deprecated.
! .IP "\fBc11\fR" 4
  .IX Item "c11"
  .PD 0
! .IP "\fBc1x\fR" 4
  .IX Item "c1x"
! .IP "\fBiso9899:2011\fR" 4
  .IX Item "iso9899:2011"
  .PD
! \&\s-1ISO C11,\s0 the 2011 revision of the \s-1ISO C\s0 standard.  This standard is
! substantially completely supported, modulo bugs, floating-point issues
  (mainly but not entirely relating to optional C11 features from
! Annexes F and G) and the optional Annexes K (Bounds-checking
  interfaces) and L (Analyzability).  The name \fBc1x\fR is deprecated.
! .IP "\fBc17\fR" 4
  .IX Item "c17"
  .PD 0
! .IP "\fBc18\fR" 4
  .IX Item "c18"
! .IP "\fBiso9899:2017\fR" 4
  .IX Item "iso9899:2017"
! .IP "\fBiso9899:2018\fR" 4
  .IX Item "iso9899:2018"
  .PD
! \&\s-1ISO C17,\s0 the 2017 revision of the \s-1ISO C\s0 standard
  (published in 2018).  This standard is
  same as C11 except for corrections of defects (all of which are also
  applied with \fB\-std=c11\fR) and a new value of
  \&\f(CW\*(C`_\|_STDC_VERSION_\|_\*(C'\fR, and so is supported to the same extent as C11.
! .IP "\fBc2x\fR" 4
  .IX Item "c2x"
! The next version of the \s-1ISO C\s0 standard, still under development.  The
  support for this version is experimental and incomplete.
! .IP "\fBgnu90\fR" 4
  .IX Item "gnu90"
  .PD 0
! .IP "\fBgnu89\fR" 4
  .IX Item "gnu89"
  .PD
! \&\s-1GNU\s0 dialect of \s-1ISO C90\s0 (including some C99 features).
! .IP "\fBgnu99\fR" 4
  .IX Item "gnu99"
  .PD 0
! .IP "\fBgnu9x\fR" 4
  .IX Item "gnu9x"
  .PD
! \&\s-1GNU\s0 dialect of \s-1ISO C99.\s0  The name \fBgnu9x\fR is deprecated.
! .IP "\fBgnu11\fR" 4
  .IX Item "gnu11"
  .PD 0
! .IP "\fBgnu1x\fR" 4
  .IX Item "gnu1x"
  .PD
! \&\s-1GNU\s0 dialect of \s-1ISO C11.\s0
  The name \fBgnu1x\fR is deprecated.
! .IP "\fBgnu17\fR" 4
  .IX Item "gnu17"
  .PD 0
! .IP "\fBgnu18\fR" 4
  .IX Item "gnu18"
  .PD
! \&\s-1GNU\s0 dialect of \s-1ISO C17.\s0  This is the default for C code.
! .IP "\fBgnu2x\fR" 4
  .IX Item "gnu2x"
! The next version of the \s-1ISO C\s0 standard, still under development, plus
! \&\s-1GNU\s0 extensions.  The support for this version is experimental and
  incomplete.
! .IP "\fBc++98\fR" 4
  .IX Item "c++98"
  .PD 0
! .IP "\fBc++03\fR" 4
  .IX Item "c++03"
  .PD
! The 1998 \s-1ISO \*(C+\s0 standard plus the 2003 technical corrigendum and some
! additional defect reports. Same as \fB\-ansi\fR for \*(C+ code.
! .IP "\fBgnu++98\fR" 4
  .IX Item "gnu++98"
  .PD 0
! .IP "\fBgnu++03\fR" 4
  .IX Item "gnu++03"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++98\fR.
! .IP "\fBc++11\fR" 4
  .IX Item "c++11"
  .PD 0
! .IP "\fBc++0x\fR" 4
  .IX Item "c++0x"
  .PD
! The 2011 \s-1ISO \*(C+\s0 standard plus amendments.
  The name \fBc++0x\fR is deprecated.
! .IP "\fBgnu++11\fR" 4
  .IX Item "gnu++11"
  .PD 0
! .IP "\fBgnu++0x\fR" 4
  .IX Item "gnu++0x"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++11\fR.
  The name \fBgnu++0x\fR is deprecated.
! .IP "\fBc++14\fR" 4
  .IX Item "c++14"
  .PD 0
! .IP "\fBc++1y\fR" 4
  .IX Item "c++1y"
  .PD
! The 2014 \s-1ISO \*(C+\s0 standard plus amendments.
  The name \fBc++1y\fR is deprecated.
! .IP "\fBgnu++14\fR" 4
  .IX Item "gnu++14"
  .PD 0
! .IP "\fBgnu++1y\fR" 4
  .IX Item "gnu++1y"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++14\fR.
  The name \fBgnu++1y\fR is deprecated.
! .IP "\fBc++17\fR" 4
  .IX Item "c++17"
  .PD 0
! .IP "\fBc++1z\fR" 4
  .IX Item "c++1z"
  .PD
! The 2017 \s-1ISO \*(C+\s0 standard plus amendments.
  The name \fBc++1z\fR is deprecated.
! .IP "\fBgnu++17\fR" 4
  .IX Item "gnu++17"
  .PD 0
! .IP "\fBgnu++1z\fR" 4
  .IX Item "gnu++1z"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++17\fR.
! This is the default for \*(C+ code.
  The name \fBgnu++1z\fR is deprecated.
! .IP "\fBc++20\fR" 4
  .IX Item "c++20"
  .PD 0
! .IP "\fBc++2a\fR" 4
  .IX Item "c++2a"
  .PD
! The 2020 \s-1ISO \*(C+\s0 standard plus amendments.
  Support is experimental, and could change in incompatible ways in
  future releases.
  The name \fBc++2a\fR is deprecated.
! .IP "\fBgnu++20\fR" 4
  .IX Item "gnu++20"
  .PD 0
! .IP "\fBgnu++2a\fR" 4
  .IX Item "gnu++2a"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++20\fR.
  Support is experimental, and could change in incompatible ways in
  future releases.
  The name \fBgnu++2a\fR is deprecated.
! .IP "\fBc++2b\fR" 4
  .IX Item "c++2b"
  .PD 0
! .IP "\fBc++23\fR" 4
  .IX Item "c++23"
  .PD
! The next revision of the \s-1ISO \*(C+\s0 standard, planned for
  2023.  Support is highly experimental, and will almost certainly
  change in incompatible ways in future releases.
! .IP "\fBgnu++2b\fR" 4
  .IX Item "gnu++2b"
  .PD 0
! .IP "\fBgnu++23\fR" 4
  .IX Item "gnu++23"
  .PD
! \&\s-1GNU\s0 dialect of \fB\-std=c++2b\fR.  Support is highly experimental,
  and will almost certainly change in incompatible ways in future
  releases.
  .RE
--- 2209,2498 ----
  backslash) may be included by prefixing the character to be included
  with a backslash.  The \fIfile\fR may itself contain additional
  @\fIfile\fR options; any such options will be processed recursively.
! .SS "Compiling C++ Programs"
! .IX Subsection "Compiling C++ Programs"
! C++ source files conventionally use one of the suffixes \fB.C\fR,
  \&\fB.cc\fR, \fB.cpp\fR, \fB.CPP\fR, \fB.c++\fR, \fB.cp\fR, or
! \&\fB.cxx\fR; C++ header files often use \fB.hh\fR, \fB.hpp\fR,
  \&\fB.H\fR, or (for shared template code) \fB.tcc\fR; and
! preprocessed C++ files use the suffix \fB.ii\fR.  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 \fBgcc\fR).
  .PP
! However, the use of \fBgcc\fR does not add the C++ library.
! \&\fBg++\fR is a program that calls GCC and automatically specifies linking
! against the C++ library.  It treats \fB.c\fR,
! \&\fB.h\fR and \fB.i\fR files as C++ source files instead of C source
  files unless \fB\-x\fR is used.  This program is also useful when
! precompiling a C header file with a \fB.h\fR extension for use in C++
  compilations.  On many systems, \fBg++\fR is also installed with
  the name \fBc++\fR.
  .PP
! When you compile C++ programs, you may specify many of the same
! command\-line options that you use for compiling programs in any
! language; or command\-line options meaningful for C and related
! languages; or options that are meaningful only for C++ programs.
  .SS "Options Controlling C Dialect"
  .IX Subsection "Options Controlling C Dialect"
  The following options control the dialect of C (or languages derived
! from C, such as C++, Objective\-C and Objective\-C++) that the compiler
  accepts:
! .IP \fB\-ansi\fR 4
  .IX Item "-ansi"
! In C mode, this is equivalent to \fB\-std=c90\fR. In C++ mode, it is
  equivalent to \fB\-std=c++98\fR.
  .Sp
! This turns off certain features of GCC that are incompatible with ISO
! C90 (when compiling C code), or of standard C++ (when compiling C++ code),
  such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, and
  predefined macros such as \f(CW\*(C`unix\*(C'\fR and \f(CW\*(C`vax\*(C'\fR that identify the
  type of system you are using.  It also enables the undesirable and
! rarely used ISO trigraph feature.  For the C compiler,
! it disables recognition of C++ style \fB//\fR comments as well as
  the \f(CW\*(C`inline\*(C'\fR keyword.
  .Sp
  The alternate keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_extension_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR continue to work despite
! \&\fB\-ansi\fR.  You would not want to use them in an ISO C program, of
  course, but it is useful to put them in header files that might be included
  in compilations done with \fB\-ansi\fR.  Alternate predefined macros
  such as \f(CW\*(C`_\|_unix_\|_\*(C'\fR and \f(CW\*(C`_\|_vax_\|_\*(C'\fR are also available, with or
  without \fB\-ansi\fR.
  .Sp
! The \fB\-ansi\fR option does not cause non\-ISO programs to be
  rejected gratuitously.  For that, \fB\-Wpedantic\fR is required in
  addition to \fB\-ansi\fR.
  .Sp
  The macro \f(CW\*(C`_\|_STRICT_ANSI_\|_\*(C'\fR is predefined when the \fB\-ansi\fR
  option is used.  Some header files may notice this macro and refrain
  from declaring certain functions or defining certain macros that the
! ISO standard doesn\*(Aqt call for; this is to avoid interfering with any
  programs that might use these names for other things.
  .Sp
  Functions that are normally built in but do not have semantics
! defined by ISO C (such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built\-in
  functions when \fB\-ansi\fR is used.
! .IP \fB\-std=\fR 4
  .IX Item "-std="
  Determine the language standard.   This option
! is currently only supported when compiling C or C++.
  .Sp
  The compiler can accept several base standards, such as \fBc90\fR or
! \&\fBc++98\fR, and GNU dialects of those standards, such as
  \&\fBgnu90\fR or \fBgnu++98\fR.  When a base standard is specified, the
  compiler accepts all programs following that standard plus those
! using GNU extensions that do not contradict it.  For example,
! \&\fB\-std=c90\fR turns off certain features of GCC that are
! incompatible with ISO C90, such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR
! keywords, but not other GNU extensions that do not have a meaning in
! ISO C90, such as omitting the middle term of a \f(CW\*(C`?:\*(C'\fR
! expression. On the other hand, when a GNU dialect of a standard is
  specified, all features supported by the compiler are enabled, even when
  those features change the meaning of the base standard.  As a result, some
! strict\-conforming programs may be rejected.  The particular standard
! is used by \fB\-Wpedantic\fR to identify which features are GNU
  extensions given that version of the standard. For example
! \&\fB\-std=gnu90 \-Wpedantic\fR warns about C++ style \fB//\fR
  comments, while \fB\-std=gnu99 \-Wpedantic\fR does not.
  .Sp
  A value for this option must be provided; possible values are
  .RS 4
! .IP \fBc90\fR 4
  .IX Item "c90"
  .PD 0
! .IP \fBc89\fR 4
  .IX Item "c89"
! .IP \fBiso9899:1990\fR 4
  .IX Item "iso9899:1990"
  .PD
! Support all ISO C90 programs (certain GNU extensions that conflict
! with ISO C90 are disabled). Same as \fB\-ansi\fR for C code.
! .IP \fBiso9899:199409\fR 4
  .IX Item "iso9899:199409"
! ISO C90 as modified in amendment 1.
! .IP \fBc99\fR 4
  .IX Item "c99"
  .PD 0
! .IP \fBc9x\fR 4
  .IX Item "c9x"
! .IP \fBiso9899:1999\fR 4
  .IX Item "iso9899:1999"
! .IP \fBiso9899:199x\fR 4
  .IX Item "iso9899:199x"
  .PD
! ISO C99.  This standard is substantially completely supported, modulo
! bugs and floating\-point issues
  (mainly but not entirely relating to optional C99 features from
  Annexes F and G).  See
  <\fBhttps://gcc.gnu.org/c99status.html\fR> for more information.  The
  names \fBc9x\fR and \fBiso9899:199x\fR are deprecated.
! .IP \fBc11\fR 4
  .IX Item "c11"
  .PD 0
! .IP \fBc1x\fR 4
  .IX Item "c1x"
! .IP \fBiso9899:2011\fR 4
  .IX Item "iso9899:2011"
  .PD
! ISO C11, the 2011 revision of the ISO C standard.  This standard is
! substantially completely supported, modulo bugs, floating\-point issues
  (mainly but not entirely relating to optional C11 features from
! Annexes F and G) and the optional Annexes K (Bounds\-checking
  interfaces) and L (Analyzability).  The name \fBc1x\fR is deprecated.
! .IP \fBc17\fR 4
  .IX Item "c17"
  .PD 0
! .IP \fBc18\fR 4
  .IX Item "c18"
! .IP \fBiso9899:2017\fR 4
  .IX Item "iso9899:2017"
! .IP \fBiso9899:2018\fR 4
  .IX Item "iso9899:2018"
  .PD
! ISO C17, the 2017 revision of the ISO C standard
  (published in 2018).  This standard is
  same as C11 except for corrections of defects (all of which are also
  applied with \fB\-std=c11\fR) and a new value of
  \&\f(CW\*(C`_\|_STDC_VERSION_\|_\*(C'\fR, and so is supported to the same extent as C11.
! .IP \fBc2x\fR 4
  .IX Item "c2x"
! The next version of the ISO C standard, still under development.  The
  support for this version is experimental and incomplete.
! .IP \fBgnu90\fR 4
  .IX Item "gnu90"
  .PD 0
! .IP \fBgnu89\fR 4
  .IX Item "gnu89"
  .PD
! GNU dialect of ISO C90 (including some C99 features).
! .IP \fBgnu99\fR 4
  .IX Item "gnu99"
  .PD 0
! .IP \fBgnu9x\fR 4
  .IX Item "gnu9x"
  .PD
! GNU dialect of ISO C99.  The name \fBgnu9x\fR is deprecated.
! .IP \fBgnu11\fR 4
  .IX Item "gnu11"
  .PD 0
! .IP \fBgnu1x\fR 4
  .IX Item "gnu1x"
  .PD
! GNU dialect of ISO C11.
  The name \fBgnu1x\fR is deprecated.
! .IP \fBgnu17\fR 4
  .IX Item "gnu17"
  .PD 0
! .IP \fBgnu18\fR 4
  .IX Item "gnu18"
  .PD
! GNU dialect of ISO C17.  This is the default for C code.
! .IP \fBgnu2x\fR 4
  .IX Item "gnu2x"
! The next version of the ISO C standard, still under development, plus
! GNU extensions.  The support for this version is experimental and
  incomplete.
! .IP \fBc++98\fR 4
  .IX Item "c++98"
  .PD 0
! .IP \fBc++03\fR 4
  .IX Item "c++03"
  .PD
! The 1998 ISO C++ standard plus the 2003 technical corrigendum and some
! additional defect reports. Same as \fB\-ansi\fR for C++ code.
! .IP \fBgnu++98\fR 4
  .IX Item "gnu++98"
  .PD 0
! .IP \fBgnu++03\fR 4
  .IX Item "gnu++03"
  .PD
! GNU dialect of \fB\-std=c++98\fR.
! .IP \fBc++11\fR 4
  .IX Item "c++11"
  .PD 0
! .IP \fBc++0x\fR 4
  .IX Item "c++0x"
  .PD
! The 2011 ISO C++ standard plus amendments.
  The name \fBc++0x\fR is deprecated.
! .IP \fBgnu++11\fR 4
  .IX Item "gnu++11"
  .PD 0
! .IP \fBgnu++0x\fR 4
  .IX Item "gnu++0x"
  .PD
! GNU dialect of \fB\-std=c++11\fR.
  The name \fBgnu++0x\fR is deprecated.
! .IP \fBc++14\fR 4
  .IX Item "c++14"
  .PD 0
! .IP \fBc++1y\fR 4
  .IX Item "c++1y"
  .PD
! The 2014 ISO C++ standard plus amendments.
  The name \fBc++1y\fR is deprecated.
! .IP \fBgnu++14\fR 4
  .IX Item "gnu++14"
  .PD 0
! .IP \fBgnu++1y\fR 4
  .IX Item "gnu++1y"
  .PD
! GNU dialect of \fB\-std=c++14\fR.
  The name \fBgnu++1y\fR is deprecated.
! .IP \fBc++17\fR 4
  .IX Item "c++17"
  .PD 0
! .IP \fBc++1z\fR 4
  .IX Item "c++1z"
  .PD
! The 2017 ISO C++ standard plus amendments.
  The name \fBc++1z\fR is deprecated.
! .IP \fBgnu++17\fR 4
  .IX Item "gnu++17"
  .PD 0
! .IP \fBgnu++1z\fR 4
  .IX Item "gnu++1z"
  .PD
! GNU dialect of \fB\-std=c++17\fR.
! This is the default for C++ code.
  The name \fBgnu++1z\fR is deprecated.
! .IP \fBc++20\fR 4
  .IX Item "c++20"
  .PD 0
! .IP \fBc++2a\fR 4
  .IX Item "c++2a"
  .PD
! The 2020 ISO C++ standard plus amendments.
  Support is experimental, and could change in incompatible ways in
  future releases.
  The name \fBc++2a\fR is deprecated.
! .IP \fBgnu++20\fR 4
  .IX Item "gnu++20"
  .PD 0
! .IP \fBgnu++2a\fR 4
  .IX Item "gnu++2a"
  .PD
! GNU dialect of \fB\-std=c++20\fR.
  Support is experimental, and could change in incompatible ways in
  future releases.
  The name \fBgnu++2a\fR is deprecated.
! .IP \fBc++2b\fR 4
  .IX Item "c++2b"
  .PD 0
! .IP \fBc++23\fR 4
  .IX Item "c++23"
  .PD
! The next revision of the ISO C++ standard, planned for
  2023.  Support is highly experimental, and will almost certainly
  change in incompatible ways in future releases.
! .IP \fBgnu++2b\fR 4
  .IX Item "gnu++2b"
  .PD 0
! .IP \fBgnu++23\fR 4
  .IX Item "gnu++23"
  .PD
! GNU dialect of \fB\-std=c++2b\fR.  Support is highly experimental,
  and will almost certainly change in incompatible ways in future
  releases.
  .RE
*************** definition (\fBC\fR or \fBF\fR, respecti
*** 2584,2622 ****
  character).  In the case of function definitions, a K&R\-style list of
  arguments followed by their declarations is also provided, inside
  comments, after the declaration.
! .IP "\fB\-fno\-asm\fR" 4
  .IX Item "-fno-asm"
  Do not recognize \f(CW\*(C`asm\*(C'\fR, \f(CW\*(C`inline\*(C'\fR or \f(CW\*(C`typeof\*(C'\fR as a
  keyword, so that code can use these words as identifiers.  You can use
  the keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR
  instead.  In C, \fB\-ansi\fR implies \fB\-fno\-asm\fR.
  .Sp
! In \*(C+, \f(CW\*(C`inline\*(C'\fR is a standard keyword and is not affected by
  this switch.  You may want to use the \fB\-fno\-gnu\-keywords\fR flag
  instead, which disables \f(CW\*(C`typeof\*(C'\fR but not \f(CW\*(C`asm\*(C'\fR and
  \&\f(CW\*(C`inline\*(C'\fR.  In C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR),
  this switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords,
! since \f(CW\*(C`inline\*(C'\fR is a standard keyword in \s-1ISO C99.\s0  In C2X mode
  (\fB\-std=c2x\fR or \fB\-std=gnu2x\fR), this switch only affects
  the \f(CW\*(C`asm\*(C'\fR keyword, since \f(CW\*(C`typeof\*(C'\fR is a standard keyword in
! \&\s-1ISO C2X.\s0
! .IP "\fB\-fno\-builtin\fR" 4
  .IX Item "-fno-builtin"
  .PD 0
! .IP "\fB\-fno\-builtin\-\fR\fIfunction\fR" 4
  .IX Item "-fno-builtin-function"
  .PD
! Don't recognize built-in functions that do not begin with
  \&\fB_\|_builtin_\fR as prefix.
  .Sp
! \&\s-1GCC\s0 normally generates special code to handle certain built-in functions
  more efficiently; for instance, calls to \f(CW\*(C`alloca\*(C'\fR may become single
  instructions which adjust the stack directly, and calls to \f(CW\*(C`memcpy\*(C'\fR
  may become inline copy loops.  The resulting code is often both smaller
  and faster, but since the function calls no longer appear as such, you
  cannot set a breakpoint on those calls, nor can you change the behavior
  of the functions by linking with a different library.  In addition,
! when a function is recognized as a built-in function, \s-1GCC\s0 may use
  information about that function to warn about problems with calls to
  that function, or to generate more efficient code, even if the
  resulting code still contains calls to that function.  For example,
--- 2513,2551 ----
  character).  In the case of function definitions, a K&R\-style list of
  arguments followed by their declarations is also provided, inside
  comments, after the declaration.
! .IP \fB\-fno\-asm\fR 4
  .IX Item "-fno-asm"
  Do not recognize \f(CW\*(C`asm\*(C'\fR, \f(CW\*(C`inline\*(C'\fR or \f(CW\*(C`typeof\*(C'\fR as a
  keyword, so that code can use these words as identifiers.  You can use
  the keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR
  instead.  In C, \fB\-ansi\fR implies \fB\-fno\-asm\fR.
  .Sp
! In C++, \f(CW\*(C`inline\*(C'\fR is a standard keyword and is not affected by
  this switch.  You may want to use the \fB\-fno\-gnu\-keywords\fR flag
  instead, which disables \f(CW\*(C`typeof\*(C'\fR but not \f(CW\*(C`asm\*(C'\fR and
  \&\f(CW\*(C`inline\*(C'\fR.  In C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR),
  this switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords,
! since \f(CW\*(C`inline\*(C'\fR is a standard keyword in ISO C99.  In C2X mode
  (\fB\-std=c2x\fR or \fB\-std=gnu2x\fR), this switch only affects
  the \f(CW\*(C`asm\*(C'\fR keyword, since \f(CW\*(C`typeof\*(C'\fR is a standard keyword in
! ISO C2X.
! .IP \fB\-fno\-builtin\fR 4
  .IX Item "-fno-builtin"
  .PD 0
! .IP \fB\-fno\-builtin\-\fR\fIfunction\fR 4
  .IX Item "-fno-builtin-function"
  .PD
! Don\*(Aqt recognize built\-in functions that do not begin with
  \&\fB_\|_builtin_\fR as prefix.
  .Sp
! GCC normally generates special code to handle certain built\-in functions
  more efficiently; for instance, calls to \f(CW\*(C`alloca\*(C'\fR may become single
  instructions which adjust the stack directly, and calls to \f(CW\*(C`memcpy\*(C'\fR
  may become inline copy loops.  The resulting code is often both smaller
  and faster, but since the function calls no longer appear as such, you
  cannot set a breakpoint on those calls, nor can you change the behavior
  of the functions by linking with a different library.  In addition,
! when a function is recognized as a built\-in function, 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 \fB\-Wformat\fR
*** 2625,2681 ****
  known not to modify global memory.
  .Sp
  With the \fB\-fno\-builtin\-\fR\fIfunction\fR option
! only the built-in function \fIfunction\fR is
  disabled.  \fIfunction\fR must not begin with \fB_\|_builtin_\fR.  If a
! function is named that is not built-in in this version of \s-1GCC,\s0 this
  option is ignored.  There is no corresponding
  \&\fB\-fbuiltin\-\fR\fIfunction\fR option; if you wish to enable
! built-in functions selectively when using \fB\-fno\-builtin\fR or
  \&\fB\-ffreestanding\fR, you may define macros such as:
  .Sp
  .Vb 2
  \&        #define abs(n)          _\|_builtin_abs ((n))
  \&        #define strcpy(d, s)    _\|_builtin_strcpy ((d), (s))
  .Ve
! .IP "\fB\-fcond\-mismatch\fR" 4
  .IX Item "-fcond-mismatch"
  Allow conditional expressions with mismatched types in the second and
  third arguments.  The value of such an expression is void.  This option
! is not supported for \*(C+.
! .IP "\fB\-ffreestanding\fR" 4
  .IX Item "-ffreestanding"
  Assert that compilation targets a freestanding environment.  This
  implies \fB\-fno\-builtin\fR.  A freestanding environment
  is one in which the standard library may not exist, and program startup may
! not necessarily be at \f(CW\*(C`main\*(C'\fR.  The most obvious example is an \s-1OS\s0 kernel.
  This is equivalent to \fB\-fno\-hosted\fR.
! .IP "\fB\-fgimple\fR" 4
  .IX Item "-fgimple"
  Enable parsing of function definitions marked with \f(CW\*(C`_\|_GIMPLE\*(C'\fR.
! This is an experimental feature that allows unit testing of \s-1GIMPLE\s0
  passes.
! .IP "\fB\-fgnu\-tm\fR" 4
  .IX Item "-fgnu-tm"
  When the option \fB\-fgnu\-tm\fR is specified, the compiler
! generates code for the Linux variant of Intel's current Transactional
! Memory \s-1ABI\s0 specification document (Revision 1.1, May 6 2009).  This is
  an experimental feature whose interface may change in future versions
! of \s-1GCC,\s0 as the official specification changes.  Please note that not
  all architectures are supported for this feature.
  .Sp
! For more information on \s-1GCC\s0's support for transactional memory,
  .Sp
  Note that the transactional memory feature is not supported with
! non-call exceptions (\fB\-fnon\-call\-exceptions\fR).
! .IP "\fB\-fgnu89\-inline\fR" 4
  .IX Item "-fgnu89-inline"
! The option \fB\-fgnu89\-inline\fR tells \s-1GCC\s0 to use the traditional
! \&\s-1GNU\s0 semantics for \f(CW\*(C`inline\*(C'\fR functions when in C99 mode.
  .Sp
  Using this option is roughly equivalent to adding the
  \&\f(CW\*(C`gnu_inline\*(C'\fR function attribute to all inline functions.
  .Sp
! The option \fB\-fno\-gnu89\-inline\fR explicitly tells \s-1GCC\s0 to use the
  C99 semantics for \f(CW\*(C`inline\*(C'\fR when in C99 or gnu99 mode (i.e., it
  specifies the default behavior).
  This option is not supported in \fB\-std=c90\fR or
--- 2554,2610 ----
  known not to modify global memory.
  .Sp
  With the \fB\-fno\-builtin\-\fR\fIfunction\fR option
! only the built\-in function \fIfunction\fR is
  disabled.  \fIfunction\fR must not begin with \fB_\|_builtin_\fR.  If a
! function is named that is not built\-in in this version of GCC, this
  option is ignored.  There is no corresponding
  \&\fB\-fbuiltin\-\fR\fIfunction\fR option; if you wish to enable
! built\-in functions selectively when using \fB\-fno\-builtin\fR or
  \&\fB\-ffreestanding\fR, you may define macros such as:
  .Sp
  .Vb 2
  \&        #define abs(n)          _\|_builtin_abs ((n))
  \&        #define strcpy(d, s)    _\|_builtin_strcpy ((d), (s))
  .Ve
! .IP \fB\-fcond\-mismatch\fR 4
  .IX Item "-fcond-mismatch"
  Allow conditional expressions with mismatched types in the second and
  third arguments.  The value of such an expression is void.  This option
! is not supported for C++.
! .IP \fB\-ffreestanding\fR 4
  .IX Item "-ffreestanding"
  Assert that compilation targets a freestanding environment.  This
  implies \fB\-fno\-builtin\fR.  A freestanding environment
  is one in which the standard library may not exist, and program startup may
! not necessarily be at \f(CW\*(C`main\*(C'\fR.  The most obvious example is an OS kernel.
  This is equivalent to \fB\-fno\-hosted\fR.
! .IP \fB\-fgimple\fR 4
  .IX Item "-fgimple"
  Enable parsing of function definitions marked with \f(CW\*(C`_\|_GIMPLE\*(C'\fR.
! This is an experimental feature that allows unit testing of GIMPLE
  passes.
! .IP \fB\-fgnu\-tm\fR 4
  .IX Item "-fgnu-tm"
  When the option \fB\-fgnu\-tm\fR is specified, the compiler
! generates code for the Linux variant of Intel\*(Aqs current Transactional
! Memory ABI specification document (Revision 1.1, May 6 2009).  This is
  an experimental feature whose interface may change in future versions
! of GCC, as the official specification changes.  Please note that not
  all architectures are supported for this feature.
  .Sp
! For more information on GCC\*(Aqs support for transactional memory,
  .Sp
  Note that the transactional memory feature is not supported with
! non\-call exceptions (\fB\-fnon\-call\-exceptions\fR).
! .IP \fB\-fgnu89\-inline\fR 4
  .IX Item "-fgnu89-inline"
! The option \fB\-fgnu89\-inline\fR tells GCC to use the traditional
! GNU semantics for \f(CW\*(C`inline\*(C'\fR functions when in C99 mode.
  .Sp
  Using this option is roughly equivalent to adding the
  \&\f(CW\*(C`gnu_inline\*(C'\fR function attribute to all inline functions.
  .Sp
! The option \fB\-fno\-gnu89\-inline\fR explicitly tells GCC to use the
  C99 semantics for \f(CW\*(C`inline\*(C'\fR when in C99 or gnu99 mode (i.e., it
  specifies the default behavior).
  This option is not supported in \fB\-std=c90\fR or
*************** This option is not supported in \fB\-std
*** 2684,2706 ****
  The preprocessor macros \f(CW\*(C`_\|_GNUC_GNU_INLINE_\|_\*(C'\fR and
  \&\f(CW\*(C`_\|_GNUC_STDC_INLINE_\|_\*(C'\fR may be used to check which semantics are
  in effect for \f(CW\*(C`inline\*(C'\fR functions.
! .IP "\fB\-fhosted\fR" 4
  .IX Item "-fhosted"
  Assert that compilation targets a hosted environment.  This implies
  \&\fB\-fbuiltin\fR.  A hosted environment is one in which the
  entire standard library is available, and in which \f(CW\*(C`main\*(C'\fR has a return
  type of \f(CW\*(C`int\*(C'\fR.  Examples are nearly everything except a kernel.
  This is equivalent to \fB\-fno\-freestanding\fR.
! .IP "\fB\-flax\-vector\-conversions\fR" 4
  .IX Item "-flax-vector-conversions"
  Allow implicit conversions between vectors with differing numbers of
  elements and/or incompatible element types.  This option should not be
  used for new code.
! .IP "\fB\-fms\-extensions\fR" 4
  .IX Item "-fms-extensions"
! Accept some non-standard constructs used in Microsoft header files.
  .Sp
! In \*(C+ code, this allows member names in structures to be similar
  to previous types declarations.
  .Sp
  .Vb 4
--- 2613,2635 ----
  The preprocessor macros \f(CW\*(C`_\|_GNUC_GNU_INLINE_\|_\*(C'\fR and
  \&\f(CW\*(C`_\|_GNUC_STDC_INLINE_\|_\*(C'\fR may be used to check which semantics are
  in effect for \f(CW\*(C`inline\*(C'\fR functions.
! .IP \fB\-fhosted\fR 4
  .IX Item "-fhosted"
  Assert that compilation targets a hosted environment.  This implies
  \&\fB\-fbuiltin\fR.  A hosted environment is one in which the
  entire standard library is available, and in which \f(CW\*(C`main\*(C'\fR has a return
  type of \f(CW\*(C`int\*(C'\fR.  Examples are nearly everything except a kernel.
  This is equivalent to \fB\-fno\-freestanding\fR.
! .IP \fB\-flax\-vector\-conversions\fR 4
  .IX Item "-flax-vector-conversions"
  Allow implicit conversions between vectors with differing numbers of
  elements and/or incompatible element types.  This option should not be
  used for new code.
! .IP \fB\-fms\-extensions\fR 4
  .IX Item "-fms-extensions"
! Accept some non\-standard constructs used in Microsoft header files.
  .Sp
! In C++ code, this allows member names in structures to be similar
  to previous types declarations.
  .Sp
  .Vb 4
*************** Some cases of unnamed fields in structur
*** 2714,2749 ****
  accepted with this option.
  .Sp
  Note that this option is off for all targets except for x86
! targets using ms-abi.
! .IP "\fB\-foffload=disable\fR" 4
  .IX Item "-foffload=disable"
  .PD 0
! .IP "\fB\-foffload=default\fR" 4
  .IX Item "-foffload=default"
! .IP "\fB\-foffload=\fR\fItarget-list\fR" 4
  .IX Item "-foffload=target-list"
  .PD
  Specify for which OpenMP and OpenACC offload targets code should be generated.
  The default behavior, equivalent to \fB\-foffload=default\fR, is to generate
  code for all supported offload targets.  The \fB\-foffload=disable\fR form
  generates code only for the host fallback, while
! \&\fB\-foffload=\fR\fItarget-list\fR generates code only for the specified
! comma-separated list of offload targets.
  .Sp
! Offload targets are specified in \s-1GCC\s0's internal target-triplet format. You can
  run the compiler with \fB\-v\fR to show the list of configured offload targets
  under \f(CW\*(C`OFFLOAD_TARGET_NAMES\*(C'\fR.
! .IP "\fB\-foffload\-options=\fR\fIoptions\fR" 4
  .IX Item "-foffload-options=options"
  .PD 0
! .IP "\fB\-foffload\-options=\fR\fItarget-triplet-list\fR\fB=\fR\fIoptions\fR" 4
  .IX Item "-foffload-options=target-triplet-list=options"
  .PD
! With \fB\-foffload\-options=\fR\fIoptions\fR, \s-1GCC\s0 passes the specified
  \&\fIoptions\fR to the compilers for all enabled offloading targets.  You can
  specify options that apply only to a specific target or targets by using
! the \fB\-foffload\-options=\fR\fItarget-list\fR\fB=\fR\fIoptions\fR form.  The
! \&\fItarget-list\fR is a comma-separated list in the same format as for the
  \&\fB\-foffload=\fR option.
  .Sp
  Typical command lines are
--- 2643,2678 ----
  accepted with this option.
  .Sp
  Note that this option is off for all targets except for x86
! targets using ms\-abi.
! .IP \fB\-foffload=disable\fR 4
  .IX Item "-foffload=disable"
  .PD 0
! .IP \fB\-foffload=default\fR 4
  .IX Item "-foffload=default"
! .IP \fB\-foffload=\fR\fItarget\-list\fR 4
  .IX Item "-foffload=target-list"
  .PD
  Specify for which OpenMP and OpenACC offload targets code should be generated.
  The default behavior, equivalent to \fB\-foffload=default\fR, is to generate
  code for all supported offload targets.  The \fB\-foffload=disable\fR form
  generates code only for the host fallback, while
! \&\fB\-foffload=\fR\fItarget\-list\fR generates code only for the specified
! comma\-separated list of offload targets.
  .Sp
! Offload targets are specified in GCC\*(Aqs internal target\-triplet format. You can
  run the compiler with \fB\-v\fR to show the list of configured offload targets
  under \f(CW\*(C`OFFLOAD_TARGET_NAMES\*(C'\fR.
! .IP \fB\-foffload\-options=\fR\fIoptions\fR 4
  .IX Item "-foffload-options=options"
  .PD 0
! .IP \fB\-foffload\-options=\fR\fItarget\-triplet\-list\fR\fB=\fR\fIoptions\fR 4
  .IX Item "-foffload-options=target-triplet-list=options"
  .PD
! With \fB\-foffload\-options=\fR\fIoptions\fR, GCC passes the specified
  \&\fIoptions\fR to the compilers for all enabled offloading targets.  You can
  specify options that apply only to a specific target or targets by using
! the \fB\-foffload\-options=\fR\fItarget\-list\fR\fB=\fR\fIoptions\fR form.  The
! \&\fItarget\-list\fR is a comma\-separated list in the same format as for the
  \&\fB\-foffload=\fR option.
  .Sp
  Typical command lines are
*************** Typical command lines are
*** 2753,2801 ****
  \&        \-foffload\-options="\-lgfortran \-lm" \-foffload\-options=nvptx\-none=\-latomic
  \&        \-foffload\-options=amdgcn\-amdhsa=\-march=gfx906 \-foffload\-options=\-lm
  .Ve
! .IP "\fB\-fopenacc\fR" 4
  .IX Item "-fopenacc"
! Enable handling of OpenACC directives \f(CW\*(C`#pragma acc\*(C'\fR in C/\*(C+ and
  \&\f(CW\*(C`!$acc\*(C'\fR in Fortran.  When \fB\-fopenacc\fR is specified, the
  compiler generates accelerated code according to the OpenACC Application
  Programming Interface v2.6 <\fBhttps://www.openacc.org\fR>.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets that
  have support for \fB\-pthread\fR.
! .IP "\fB\-fopenacc\-dim=\fR\fIgeom\fR" 4
  .IX Item "-fopenacc-dim=geom"
  Specify default compute dimensions for parallel offload regions that do
  not explicitly specify.  The \fIgeom\fR value is a triple of
! \&':'\-separated sizes, in order 'gang', 'worker' and, 'vector'.  A size
! can be omitted, to use a target-specific default value.
! .IP "\fB\-fopenmp\fR" 4
  .IX Item "-fopenmp"
! Enable handling of OpenMP directives \f(CW\*(C`#pragma omp\*(C'\fR in C/\*(C+,
! \&\f(CW\*(C`[[omp::directive(...)]]\*(C'\fR and \f(CW\*(C`[[omp::sequence(...)]]\*(C'\fR in \*(C+ and
  \&\f(CW\*(C`!$omp\*(C'\fR in Fortran.  When \fB\-fopenmp\fR is specified, the
  compiler generates parallel code according to the OpenMP Application
  Program Interface v4.5 <\fBhttps://www.openmp.org\fR>.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets that
  have support for \fB\-pthread\fR. \fB\-fopenmp\fR implies
  \&\fB\-fopenmp\-simd\fR.
! .IP "\fB\-fopenmp\-simd\fR" 4
  .IX Item "-fopenmp-simd"
! Enable handling of OpenMP's \f(CW\*(C`simd\*(C'\fR, \f(CW\*(C`declare simd\*(C'\fR,
  \&\f(CW\*(C`declare reduction\*(C'\fR, \f(CW\*(C`assume\*(C'\fR, \f(CW\*(C`ordered\*(C'\fR, \f(CW\*(C`scan\*(C'\fR,
  \&\f(CW\*(C`loop\*(C'\fR directives and combined or composite directives with
! \&\f(CW\*(C`simd\*(C'\fR as constituent with \f(CW\*(C`#pragma omp\*(C'\fR in C/\*(C+,
! \&\f(CW\*(C`[[omp::directive(...)]]\*(C'\fR and \f(CW\*(C`[[omp::sequence(...)]]\*(C'\fR in \*(C+
  and \f(CW\*(C`!$omp\*(C'\fR in Fortran.  Other OpenMP directives are ignored.
! .IP "\fB\-fopenmp\-target\-simd\-clone\fR" 4
  .IX Item "-fopenmp-target-simd-clone"
  .PD 0
! .IP "\fB\-fopenmp\-target\-simd\-clone=\fR\fIdevice-type\fR" 4
  .IX Item "-fopenmp-target-simd-clone=device-type"
  .PD
! In addition to generating \s-1SIMD\s0 clones for functions marked with the
! \&\f(CW\*(C`declare simd\*(C'\fR directive, \s-1GCC\s0 also generates clones
  for functions marked with the OpenMP \f(CW\*(C`declare target\*(C'\fR directive
  that are suitable for vectorization when this option is in effect.  The
! \&\fIdevice-type\fR may be one of \f(CW\*(C`none\*(C'\fR, \f(CW\*(C`host\*(C'\fR, \f(CW\*(C`nohost\*(C'\fR,
  and \f(CW\*(C`any\*(C'\fR, which correspond to keywords for the \f(CW\*(C`device_type\*(C'\fR
  clause of the \f(CW\*(C`declare target\*(C'\fR directive; clones are generated for
  the intersection of devices specified.
--- 2682,2730 ----
  \&        \-foffload\-options="\-lgfortran \-lm" \-foffload\-options=nvptx\-none=\-latomic
  \&        \-foffload\-options=amdgcn\-amdhsa=\-march=gfx906 \-foffload\-options=\-lm
  .Ve
! .IP \fB\-fopenacc\fR 4
  .IX Item "-fopenacc"
! Enable handling of OpenACC directives \f(CW\*(C`#pragma acc\*(C'\fR in C/C++ and
  \&\f(CW\*(C`!$acc\*(C'\fR in Fortran.  When \fB\-fopenacc\fR is specified, the
  compiler generates accelerated code according to the OpenACC Application
  Programming Interface v2.6 <\fBhttps://www.openacc.org\fR>.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets that
  have support for \fB\-pthread\fR.
! .IP \fB\-fopenacc\-dim=\fR\fIgeom\fR 4
  .IX Item "-fopenacc-dim=geom"
  Specify default compute dimensions for parallel offload regions that do
  not explicitly specify.  The \fIgeom\fR value is a triple of
! \&\*(Aq:\*(Aq\-separated sizes, in order \*(Aqgang\*(Aq, \*(Aqworker\*(Aq and, \*(Aqvector\*(Aq.  A size
! can be omitted, to use a target\-specific default value.
! .IP \fB\-fopenmp\fR 4
  .IX Item "-fopenmp"
! Enable handling of OpenMP directives \f(CW\*(C`#pragma omp\*(C'\fR in C/C++,
! \&\f(CW\*(C`[[omp::directive(...)]]\*(C'\fR and \f(CW\*(C`[[omp::sequence(...)]]\*(C'\fR in C++ and
  \&\f(CW\*(C`!$omp\*(C'\fR in Fortran.  When \fB\-fopenmp\fR is specified, the
  compiler generates parallel code according to the OpenMP Application
  Program Interface v4.5 <\fBhttps://www.openmp.org\fR>.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets that
  have support for \fB\-pthread\fR. \fB\-fopenmp\fR implies
  \&\fB\-fopenmp\-simd\fR.
! .IP \fB\-fopenmp\-simd\fR 4
  .IX Item "-fopenmp-simd"
! Enable handling of OpenMP\*(Aqs \f(CW\*(C`simd\*(C'\fR, \f(CW\*(C`declare simd\*(C'\fR,
  \&\f(CW\*(C`declare reduction\*(C'\fR, \f(CW\*(C`assume\*(C'\fR, \f(CW\*(C`ordered\*(C'\fR, \f(CW\*(C`scan\*(C'\fR,
  \&\f(CW\*(C`loop\*(C'\fR directives and combined or composite directives with
! \&\f(CW\*(C`simd\*(C'\fR as constituent with \f(CW\*(C`#pragma omp\*(C'\fR in C/C++,
! \&\f(CW\*(C`[[omp::directive(...)]]\*(C'\fR and \f(CW\*(C`[[omp::sequence(...)]]\*(C'\fR in C++
  and \f(CW\*(C`!$omp\*(C'\fR in Fortran.  Other OpenMP directives are ignored.
! .IP \fB\-fopenmp\-target\-simd\-clone\fR 4
  .IX Item "-fopenmp-target-simd-clone"
  .PD 0
! .IP \fB\-fopenmp\-target\-simd\-clone=\fR\fIdevice\-type\fR 4
  .IX Item "-fopenmp-target-simd-clone=device-type"
  .PD
! In addition to generating SIMD clones for functions marked with the
! \&\f(CW\*(C`declare simd\*(C'\fR directive, GCC also generates clones
  for functions marked with the OpenMP \f(CW\*(C`declare target\*(C'\fR directive
  that are suitable for vectorization when this option is in effect.  The
! \&\fIdevice\-type\fR may be one of \f(CW\*(C`none\*(C'\fR, \f(CW\*(C`host\*(C'\fR, \f(CW\*(C`nohost\*(C'\fR,
  and \f(CW\*(C`any\*(C'\fR, which correspond to keywords for the \f(CW\*(C`device_type\*(C'\fR
  clause of the \f(CW\*(C`declare target\*(C'\fR directive; clones are generated for
  the intersection of devices specified.
*************** the intersection of devices specified.
*** 2807,2815 ****
  At \fB\-O2\fR and higher (but not \fB\-Os\fR or \fB\-Og\fR) this
  optimization defaults to \fB\-fopenmp\-target\-simd\-clone=nohost\fR; otherwise
  it is disabled by default.
! .IP "\fB\-fpermitted\-flt\-eval\-methods=\fR\fIstyle\fR" 4
  .IX Item "-fpermitted-flt-eval-methods=style"
! \&\s-1ISO/IEC TS 18661\-3\s0 defines new permissible values for
  \&\f(CW\*(C`FLT_EVAL_METHOD\*(C'\fR that indicate that operations and constants with
  a semantic type that is an interchange or extended format should be
  evaluated to the precision and range of that type.  These new values are
--- 2736,2744 ----
  At \fB\-O2\fR and higher (but not \fB\-Os\fR or \fB\-Og\fR) this
  optimization defaults to \fB\-fopenmp\-target\-simd\-clone=nohost\fR; otherwise
  it is disabled by default.
! .IP \fB\-fpermitted\-flt\-eval\-methods=\fR\fIstyle\fR 4
  .IX Item "-fpermitted-flt-eval-methods=style"
! ISO/IEC TS 18661\-3 defines new permissible values for
  \&\f(CW\*(C`FLT_EVAL_METHOD\*(C'\fR that indicate that operations and constants with
  a semantic type that is an interchange or extended format should be
  evaluated to the precision and range of that type.  These new values are
*************** the new values.
*** 2820,2864 ****
  .Sp
  \&\fB\-fpermitted\-flt\-eval\-methods\fR specifies whether the compiler
  should allow only the values of \f(CW\*(C`FLT_EVAL_METHOD\*(C'\fR specified in C99/C11,
! or the extended set of values specified in \s-1ISO/IEC TS 18661\-3.\s0
  .Sp
  \&\fIstyle\fR is either \f(CW\*(C`c11\*(C'\fR or \f(CW\*(C`ts\-18661\-3\*(C'\fR as appropriate.
  .Sp
  The default when in a standards compliant mode (\fB\-std=c11\fR or similar)
! is \fB\-fpermitted\-flt\-eval\-methods=c11\fR.  The default when in a \s-1GNU\s0
  dialect (\fB\-std=gnu11\fR or similar) is
  \&\fB\-fpermitted\-flt\-eval\-methods=ts\-18661\-3\fR.
! .IP "\fB\-fplan9\-extensions\fR" 4
  .IX Item "-fplan9-extensions"
! Accept some non-standard constructs used in Plan 9 code.
  .Sp
  This enables \fB\-fms\-extensions\fR, permits passing pointers to
  structures with anonymous fields to functions that expect pointers to
  elements of the type of the field, and permits referring to anonymous
  fields declared using a typedef.    This is only
! supported for C, not \*(C+.
! .IP "\fB\-fsigned\-bitfields\fR" 4
  .IX Item "-fsigned-bitfields"
  .PD 0
! .IP "\fB\-funsigned\-bitfields\fR" 4
  .IX Item "-funsigned-bitfields"
! .IP "\fB\-fno\-signed\-bitfields\fR" 4
  .IX Item "-fno-signed-bitfields"
! .IP "\fB\-fno\-unsigned\-bitfields\fR" 4
  .IX Item "-fno-unsigned-bitfields"
  .PD
! These options control whether a bit-field is signed or unsigned, when the
  declaration does not use either \f(CW\*(C`signed\*(C'\fR or \f(CW\*(C`unsigned\*(C'\fR.  By
! default, such a bit-field is signed, because this is consistent: the
  basic integer types such as \f(CW\*(C`int\*(C'\fR are signed types.
! .IP "\fB\-fsigned\-char\fR" 4
  .IX Item "-fsigned-char"
  Let the type \f(CW\*(C`char\*(C'\fR be signed, like \f(CW\*(C`signed char\*(C'\fR.
  .Sp
  Note that this is equivalent to \fB\-fno\-unsigned\-char\fR, which is
  the negative form of \fB\-funsigned\-char\fR.  Likewise, the option
  \&\fB\-fno\-signed\-char\fR is equivalent to \fB\-funsigned\-char\fR.
! .IP "\fB\-funsigned\-char\fR" 4
  .IX Item "-funsigned-char"
  Let the type \f(CW\*(C`char\*(C'\fR be unsigned, like \f(CW\*(C`unsigned char\*(C'\fR.
  .Sp
--- 2749,2793 ----
  .Sp
  \&\fB\-fpermitted\-flt\-eval\-methods\fR specifies whether the compiler
  should allow only the values of \f(CW\*(C`FLT_EVAL_METHOD\*(C'\fR specified in C99/C11,
! or the extended set of values specified in ISO/IEC TS 18661\-3.
  .Sp
  \&\fIstyle\fR is either \f(CW\*(C`c11\*(C'\fR or \f(CW\*(C`ts\-18661\-3\*(C'\fR as appropriate.
  .Sp
  The default when in a standards compliant mode (\fB\-std=c11\fR or similar)
! is \fB\-fpermitted\-flt\-eval\-methods=c11\fR.  The default when in a GNU
  dialect (\fB\-std=gnu11\fR or similar) is
  \&\fB\-fpermitted\-flt\-eval\-methods=ts\-18661\-3\fR.
! .IP \fB\-fplan9\-extensions\fR 4
  .IX Item "-fplan9-extensions"
! Accept some non\-standard constructs used in Plan 9 code.
  .Sp
  This enables \fB\-fms\-extensions\fR, permits passing pointers to
  structures with anonymous fields to functions that expect pointers to
  elements of the type of the field, and permits referring to anonymous
  fields declared using a typedef.    This is only
! supported for C, not C++.
! .IP \fB\-fsigned\-bitfields\fR 4
  .IX Item "-fsigned-bitfields"
  .PD 0
! .IP \fB\-funsigned\-bitfields\fR 4
  .IX Item "-funsigned-bitfields"
! .IP \fB\-fno\-signed\-bitfields\fR 4
  .IX Item "-fno-signed-bitfields"
! .IP \fB\-fno\-unsigned\-bitfields\fR 4
  .IX Item "-fno-unsigned-bitfields"
  .PD
! These options control whether a bit\-field is signed or unsigned, when the
  declaration does not use either \f(CW\*(C`signed\*(C'\fR or \f(CW\*(C`unsigned\*(C'\fR.  By
! default, such a bit\-field is signed, because this is consistent: the
  basic integer types such as \f(CW\*(C`int\*(C'\fR are signed types.
! .IP \fB\-fsigned\-char\fR 4
  .IX Item "-fsigned-char"
  Let the type \f(CW\*(C`char\*(C'\fR be signed, like \f(CW\*(C`signed char\*(C'\fR.
  .Sp
  Note that this is equivalent to \fB\-fno\-unsigned\-char\fR, which is
  the negative form of \fB\-funsigned\-char\fR.  Likewise, the option
  \&\fB\-fno\-signed\-char\fR is equivalent to \fB\-funsigned\-char\fR.
! .IP \fB\-funsigned\-char\fR 4
  .IX Item "-funsigned-char"
  Let the type \f(CW\*(C`char\*(C'\fR be unsigned, like \f(CW\*(C`unsigned char\*(C'\fR.
  .Sp
*************** make such a program work with the opposi
*** 2876,2882 ****
  The type \f(CW\*(C`char\*(C'\fR is always a distinct type from each of
  \&\f(CW\*(C`signed char\*(C'\fR or \f(CW\*(C`unsigned char\*(C'\fR, even though its behavior
  is always just like one of those two.
! .IP "\fB\-fstrict\-flex\-arrays\fR" 4
  .IX Item "-fstrict-flex-arrays"
  Control when to treat the trailing array of a structure as a flexible array
  member for the purpose of accessing the elements of such an array.
--- 2805,2811 ----
  The type \f(CW\*(C`char\*(C'\fR is always a distinct type from each of
  \&\f(CW\*(C`signed char\*(C'\fR or \f(CW\*(C`unsigned char\*(C'\fR, even though its behavior
  is always just like one of those two.
! .IP \fB\-fstrict\-flex\-arrays\fR 4
  .IX Item "-fstrict-flex-arrays"
  Control when to treat the trailing array of a structure as a flexible array
  member for the purpose of accessing the elements of such an array.
*************** is declared as a flexible array member p
*** 2886,2892 ****
  The negative form is equivalent to \fB\-fstrict\-flex\-arrays=0\fR, which is the
  least strict.  All trailing arrays of structures are treated as flexible array
  members.
! .IP "\fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR" 4
  .IX Item "-fstrict-flex-arrays=level"
  Control when to treat the trailing array of a structure as a flexible array
  member for the purpose of accessing the elements of such an array.  The value
--- 2815,2821 ----
  The negative form is equivalent to \fB\-fstrict\-flex\-arrays=0\fR, which is the
  least strict.  All trailing arrays of structures are treated as flexible array
  members.
! .IP \fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR 4
  .IX Item "-fstrict-flex-arrays=level"
  Control when to treat the trailing array of a structure as a flexible array
  member for the purpose of accessing the elements of such an array.  The value
*************** The possible values of \fIlevel\fR are t
*** 2897,2916 ****
  .Sp
  You can control this behavior for a specific trailing array field of a
  structure by using the variable attribute \f(CW\*(C`strict_flex_array\*(C'\fR attribute.
! .IP "\fB\-fsso\-struct=\fR\fIendianness\fR" 4
  .IX Item "-fsso-struct=endianness"
  Set the default scalar storage order of structures and unions to the
! specified endianness.  The accepted values are \fBbig-endian\fR,
! \&\fBlittle-endian\fR and \fBnative\fR for the native endianness of
! the target (the default).  This option is not supported for \*(C+.
  .Sp
! \&\fBWarning:\fR the \fB\-fsso\-struct\fR switch causes \s-1GCC\s0 to generate
  code that is not binary compatible with code generated without it if the
  specified endianness is not the native endianness of the target.
! .SS "Options Controlling \*(C+ Dialect"
! .IX Subsection "Options Controlling Dialect"
! This section describes the command-line options that are only meaningful
! for \*(C+ programs.  You can also use most of the \s-1GNU\s0 compiler options
  regardless of what language your program is in.  For example, you
  might compile a file \fIfirstClass.C\fR like this:
  .PP
--- 2826,2845 ----
  .Sp
  You can control this behavior for a specific trailing array field of a
  structure by using the variable attribute \f(CW\*(C`strict_flex_array\*(C'\fR attribute.
! .IP \fB\-fsso\-struct=\fR\fIendianness\fR 4
  .IX Item "-fsso-struct=endianness"
  Set the default scalar storage order of structures and unions to the
! specified endianness.  The accepted values are \fBbig\-endian\fR,
! \&\fBlittle\-endian\fR and \fBnative\fR for the native endianness of
! the target (the default).  This option is not supported for C++.
  .Sp
! \&\fBWarning:\fR the \fB\-fsso\-struct\fR switch causes GCC to generate
  code that is not binary compatible with code generated without it if the
  specified endianness is not the native endianness of the target.
! .SS "Options Controlling C++ Dialect"
! .IX Subsection "Options Controlling C++ Dialect"
! This section describes the command\-line options that are only meaningful
! for C++ programs.  You can also use most of the GNU compiler options
  regardless of what language your program is in.  For example, you
  might compile a file \fIfirstClass.C\fR like this:
  .PP
*************** might compile a file \fIfirstClass.C\fR
*** 2919,2942 ****
  .Ve
  .PP
  In this example, only \fB\-fstrict\-enums\fR is an option meant
! only for \*(C+ programs; you can use the other options with any
! language supported by \s-1GCC.\s0
  .PP
  Some options for compiling C programs, such as \fB\-std\fR, are also
! relevant for \*(C+ programs.
  .PP
! Here is a list of options that are \fIonly\fR for compiling \*(C+ programs:
! .IP "\fB\-fabi\-version=\fR\fIn\fR" 4
  .IX Item "-fabi-version=n"
! Use version \fIn\fR of the \*(C+ \s-1ABI.\s0  The default is version 0.
  .Sp
  Version 0 refers to the version conforming most closely to
! the \*(C+ \s-1ABI\s0 specification.  Therefore, the \s-1ABI\s0 obtained using version 0
! will change in different versions of G++ as \s-1ABI\s0 bugs are fixed.
  .Sp
! Version 1 is the version of the \*(C+ \s-1ABI\s0 that first appeared in G++ 3.2.
  .Sp
! Version 2 is the version of the \*(C+ \s-1ABI\s0 that first appeared in G++
  3.4, and was the default through G++ 4.9.
  .Sp
  Version 3 corrects an error in mangling a constant address as a
--- 2848,2871 ----
  .Ve
  .PP
  In this example, only \fB\-fstrict\-enums\fR is an option meant
! only for C++ programs; you can use the other options with any
! language supported by GCC.
  .PP
  Some options for compiling C programs, such as \fB\-std\fR, are also
! relevant for C++ programs.
  .PP
! Here is a list of options that are \fIonly\fR for compiling C++ programs:
! .IP \fB\-fabi\-version=\fR\fIn\fR 4
  .IX Item "-fabi-version=n"
! Use version \fIn\fR of the C++ ABI.  The default is version 0.
  .Sp
  Version 0 refers to the version conforming most closely to
! the C++ ABI specification.  Therefore, the ABI obtained using version 0
! will change in different versions of G++ as ABI bugs are fixed.
  .Sp
! Version 1 is the version of the C++ ABI that first appeared in G++ 3.2.
  .Sp
! Version 2 is the version of the C++ ABI that first appeared in G++
  3.4, and was the default through G++ 4.9.
  .Sp
  Version 3 corrects an error in mangling a constant address as a
*************** plain decl, and use of a function parame
*** 2951,2957 ****
  another parameter.
  .Sp
  Version 6, which first appeared in G++ 4.7, corrects the promotion
! behavior of \*(C+11 scoped enums and the mangling of template argument
  packs, const/static_cast, prefix ++ and \-\-, and a class scope function
  used as a template argument.
  .Sp
--- 2880,2886 ----
  another parameter.
  .Sp
  Version 6, which first appeared in G++ 4.7, corrects the promotion
! behavior of C++11 scoped enums and the mangling of template argument
  packs, const/static_cast, prefix ++ and \-\-, and a class scope function
  used as a template argument.
  .Sp
*************** builtin type and corrects the mangling o
*** 2960,2966 ****
  scope.
  .Sp
  Version 8, which first appeared in G++ 4.9, corrects the substitution
! behavior of function types with function-cv-qualifiers.
  .Sp
  Version 9, which first appeared in G++ 5.2, corrects the alignment of
  \&\f(CW\*(C`nullptr_t\*(C'\fR.
--- 2889,2895 ----
  scope.
  .Sp
  Version 8, which first appeared in G++ 4.9, corrects the substitution
! behavior of function types with function\-cv\-qualifiers.
  .Sp
  Version 9, which first appeared in G++ 5.2, corrects the alignment of
  \&\f(CW\*(C`nullptr_t\*(C'\fR.
*************** change in version 12.
*** 2987,2993 ****
  Version 14, which first appeared in G++ 10, corrects the mangling of
  the nullptr expression.
  .Sp
! Version 15, which first appeared in G++ 10.3, corrects G++ 10 \s-1ABI\s0
  tag regression.
  .Sp
  Version 16, which first appeared in G++ 11, changes the mangling of
--- 2916,2922 ----
  Version 14, which first appeared in G++ 10, corrects the mangling of
  the nullptr expression.
  .Sp
! Version 15, which first appeared in G++ 10.3, corrects G++ 10 ABI
  tag regression.
  .Sp
  Version 16, which first appeared in G++ 11, changes the mangling of
*************** dependent operator names.
*** 2996,3050 ****
  .Sp
  Version 17, which first appeared in G++ 12, fixes layout of classes
  that inherit from aggregate classes with default member initializers
! in \*(C+14 and up.
  .Sp
  Version 18, which first appeard in G++ 13, fixes manglings of lambdas
  that have additional context.
  .Sp
  See also \fB\-Wabi\fR.
! .IP "\fB\-fabi\-compat\-version=\fR\fIn\fR" 4
  .IX Item "-fabi-compat-version=n"
  On targets that support strong aliases, G++
  works around mangling changes by creating an alias with the correct
  mangled name when defining a symbol with an incorrect mangled name.
! This switch specifies which \s-1ABI\s0 version to use for the alias.
  .Sp
! With \fB\-fabi\-version=0\fR (the default), this defaults to 13 (\s-1GCC 8.2\s0
! compatibility).  If another \s-1ABI\s0 version is explicitly selected, this
! defaults to 0.  For compatibility with \s-1GCC\s0 versions 3.2 through 4.9,
  use \fB\-fabi\-compat\-version=2\fR.
  .Sp
  If this option is not provided but \fB\-Wabi=\fR\fIn\fR is, that
  version is used for compatibility aliases.  If this option is provided
  along with \fB\-Wabi\fR (without the version), the version from this
  option is used for the warning.
! .IP "\fB\-fno\-access\-control\fR" 4
  .IX Item "-fno-access-control"
  Turn off all access checking.  This switch is mainly useful for working
  around bugs in the access control code.
! .IP "\fB\-faligned\-new\fR" 4
  .IX Item "-faligned-new"
! Enable support for \*(C+17 \f(CW\*(C`new\*(C'\fR of types that require more
  alignment than \f(CW\*(C`void* ::operator new(std::size_t)\*(C'\fR provides.  A
  numeric argument such as \f(CW\*(C`\-faligned\-new=32\*(C'\fR can be used to
  specify how much alignment (in bytes) is provided by that function,
  but few users will need to override the default of
! \&\f(CW\*(C`alignof(std::max_align_t)\*(C'\fR.
  .Sp
  This flag is enabled by default for \fB\-std=c++17\fR.
! .IP "\fB\-fchar8_t\fR" 4
  .IX Item "-fchar8_t"
  .PD 0
! .IP "\fB\-fno\-char8_t\fR" 4
  .IX Item "-fno-char8_t"
  .PD
! Enable support for \f(CW\*(C`char8_t\*(C'\fR as adopted for \*(C+20.  This includes
  the addition of a new \f(CW\*(C`char8_t\*(C'\fR fundamental type, changes to the
! types of \s-1UTF\-8\s0 string and character literals, new signatures for
! user-defined literals, associated standard library updates, and new
  \&\f(CW\*(C`_\|_cpp_char8_t\*(C'\fR and \f(CW\*(C`_\|_cpp_lib_char8_t\*(C'\fR feature test macros.
  .Sp
! This option enables functions to be overloaded for ordinary and \s-1UTF\-8\s0
  strings:
  .Sp
  .Vb 4
--- 2925,2979 ----
  .Sp
  Version 17, which first appeared in G++ 12, fixes layout of classes
  that inherit from aggregate classes with default member initializers
! in C++14 and up.
  .Sp
  Version 18, which first appeard in G++ 13, fixes manglings of lambdas
  that have additional context.
  .Sp
  See also \fB\-Wabi\fR.
! .IP \fB\-fabi\-compat\-version=\fR\fIn\fR 4
  .IX Item "-fabi-compat-version=n"
  On targets that support strong aliases, G++
  works around mangling changes by creating an alias with the correct
  mangled name when defining a symbol with an incorrect mangled name.
! This switch specifies which ABI version to use for the alias.
  .Sp
! With \fB\-fabi\-version=0\fR (the default), this defaults to 13 (GCC 8.2
! compatibility).  If another ABI version is explicitly selected, this
! defaults to 0.  For compatibility with GCC versions 3.2 through 4.9,
  use \fB\-fabi\-compat\-version=2\fR.
  .Sp
  If this option is not provided but \fB\-Wabi=\fR\fIn\fR is, that
  version is used for compatibility aliases.  If this option is provided
  along with \fB\-Wabi\fR (without the version), the version from this
  option is used for the warning.
! .IP \fB\-fno\-access\-control\fR 4
  .IX Item "-fno-access-control"
  Turn off all access checking.  This switch is mainly useful for working
  around bugs in the access control code.
! .IP \fB\-faligned\-new\fR 4
  .IX Item "-faligned-new"
! Enable support for C++17 \f(CW\*(C`new\*(C'\fR of types that require more
  alignment than \f(CW\*(C`void* ::operator new(std::size_t)\*(C'\fR provides.  A
  numeric argument such as \f(CW\*(C`\-faligned\-new=32\*(C'\fR can be used to
  specify how much alignment (in bytes) is provided by that function,
  but few users will need to override the default of
! \&\f(CWalignof(std::max_align_t)\fR.
  .Sp
  This flag is enabled by default for \fB\-std=c++17\fR.
! .IP \fB\-fchar8_t\fR 4
  .IX Item "-fchar8_t"
  .PD 0
! .IP \fB\-fno\-char8_t\fR 4
  .IX Item "-fno-char8_t"
  .PD
! Enable support for \f(CW\*(C`char8_t\*(C'\fR as adopted for C++20.  This includes
  the addition of a new \f(CW\*(C`char8_t\*(C'\fR fundamental type, changes to the
! types of UTF\-8 string and character literals, new signatures for
! user\-defined literals, associated standard library updates, and new
  \&\f(CW\*(C`_\|_cpp_char8_t\*(C'\fR and \f(CW\*(C`_\|_cpp_lib_char8_t\*(C'\fR feature test macros.
  .Sp
! This option enables functions to be overloaded for ordinary and UTF\-8
  strings:
  .Sp
  .Vb 4
*************** strings:
*** 3054,3060 ****
  \&        int v2 = f(u8"text");   // Calls #2
  .Ve
  .Sp
! and introduces new signatures for user-defined literals:
  .Sp
  .Vb 6
  \&        int operator""_udl1(char8_t);
--- 2983,2989 ----
  \&        int v2 = f(u8"text");   // Calls #2
  .Ve
  .Sp
! and introduces new signatures for user\-defined literals:
  .Sp
  .Vb 6
  \&        int operator""_udl1(char8_t);
*************** and introduces new signatures for user-d
*** 3065,3073 ****
  \&        int v5 = u8"text"_udl3;
  .Ve
  .Sp
! The change to the types of \s-1UTF\-8\s0 string and character literals introduces
! incompatibilities with \s-1ISO \*(C+11\s0 and later standards.  For example, the
! following code is well-formed under \s-1ISO \*(C+11,\s0 but is ill-formed when
  \&\fB\-fchar8_t\fR is specified.
  .Sp
  .Vb 11
--- 2994,3002 ----
  \&        int v5 = u8"text"_udl3;
  .Ve
  .Sp
! The change to the types of UTF\-8 string and character literals introduces
! incompatibilities with ISO C++11 and later standards.  For example, the
! following code is well\-formed under ISO C++11, but is ill\-formed when
  \&\fB\-fchar8_t\fR is specified.
  .Sp
  .Vb 11
*************** following code is well-formed under \s-1
*** 3083,3122 ****
  \&                                //        \`basic_string\*(Aq to non\-scalar
  \&                                //        type \`basic_string\*(Aq requested
  .Ve
! .IP "\fB\-fcheck\-new\fR" 4
  .IX Item "-fcheck-new"
! Check that the pointer returned by \f(CW\*(C`operator new\*(C'\fR is non-null
  before attempting to modify the storage allocated.  This check is
! normally unnecessary because the \*(C+ standard specifies that
  \&\f(CW\*(C`operator new\*(C'\fR only returns \f(CW0\fR if it is declared
! \&\f(CW\*(C`throw()\*(C'\fR, in which case the compiler always checks the
  return value even without this option.  In all other cases, when
! \&\f(CW\*(C`operator new\*(C'\fR has a non-empty exception specification, memory
  exhaustion is signalled by throwing \f(CW\*(C`std::bad_alloc\*(C'\fR.  See also
  \&\fBnew (nothrow)\fR.
! .IP "\fB\-fconcepts\fR" 4
  .IX Item "-fconcepts"
  .PD 0
! .IP "\fB\-fconcepts\-ts\fR" 4
  .IX Item "-fconcepts-ts"
  .PD
! Enable support for the \*(C+ Concepts feature for constraining template
  arguments.  With \fB\-std=c++20\fR and above, Concepts are part of
  the language standard, so \fB\-fconcepts\fR defaults to on.
  .Sp
! Some constructs that were allowed by the earlier \*(C+ Extensions for
! Concepts Technical Specification, \s-1ISO 19217\s0 (2015), but didn't make it
  into the standard, can additionally be enabled by
  \&\fB\-fconcepts\-ts\fR.
! .IP "\fB\-fconstexpr\-depth=\fR\fIn\fR" 4
  .IX Item "-fconstexpr-depth=n"
! Set the maximum nested evaluation depth for \*(C+11 constexpr functions
  to \fIn\fR.  A limit is needed to detect endless recursion during
  constant expression evaluation.  The minimum specified by the standard
  is 512.
! .IP "\fB\-fconstexpr\-cache\-depth=\fR\fIn\fR" 4
  .IX Item "-fconstexpr-cache-depth=n"
! Set the maximum level of nested evaluation depth for \*(C+11 constexpr
  functions that will be cached to \fIn\fR.  This is a heuristic that
  trades off compilation speed (when the cache avoids repeated
  calculations) against memory consumption (when the cache grows very
--- 3012,3051 ----
  \&                                //        \`basic_string\*(Aq to non\-scalar
  \&                                //        type \`basic_string\*(Aq requested
  .Ve
! .IP \fB\-fcheck\-new\fR 4
  .IX Item "-fcheck-new"
! Check that the pointer returned by \f(CW\*(C`operator new\*(C'\fR is non\-null
  before attempting to modify the storage allocated.  This check is
! normally unnecessary because the C++ standard specifies that
  \&\f(CW\*(C`operator new\*(C'\fR only returns \f(CW0\fR if it is declared
! \&\f(CWthrow()\fR, in which case the compiler always checks the
  return value even without this option.  In all other cases, when
! \&\f(CW\*(C`operator new\*(C'\fR has a non\-empty exception specification, memory
  exhaustion is signalled by throwing \f(CW\*(C`std::bad_alloc\*(C'\fR.  See also
  \&\fBnew (nothrow)\fR.
! .IP \fB\-fconcepts\fR 4
  .IX Item "-fconcepts"
  .PD 0
! .IP \fB\-fconcepts\-ts\fR 4
  .IX Item "-fconcepts-ts"
  .PD
! Enable support for the C++ Concepts feature for constraining template
  arguments.  With \fB\-std=c++20\fR and above, Concepts are part of
  the language standard, so \fB\-fconcepts\fR defaults to on.
  .Sp
! Some constructs that were allowed by the earlier C++ Extensions for
! Concepts Technical Specification, ISO 19217 (2015), but didn\*(Aqt make it
  into the standard, can additionally be enabled by
  \&\fB\-fconcepts\-ts\fR.
! .IP \fB\-fconstexpr\-depth=\fR\fIn\fR 4
  .IX Item "-fconstexpr-depth=n"
! Set the maximum nested evaluation depth for C++11 constexpr functions
  to \fIn\fR.  A limit is needed to detect endless recursion during
  constant expression evaluation.  The minimum specified by the standard
  is 512.
! .IP \fB\-fconstexpr\-cache\-depth=\fR\fIn\fR 4
  .IX Item "-fconstexpr-cache-depth=n"
! Set the maximum level of nested evaluation depth for C++11 constexpr
  functions that will be cached to \fIn\fR.  This is a heuristic that
  trades off compilation speed (when the cache avoids repeated
  calculations) against memory consumption (when the cache grows very
*************** large from highly recursive evaluations)
*** 3124,3135 ****
  users are likely to want to adjust it, but if your code does heavy
  constexpr calculations you might want to experiment to find which
  value works best for you.
! .IP "\fB\-fconstexpr\-fp\-except\fR" 4
  .IX Item "-fconstexpr-fp-except"
! Annex F of the C standard specifies that \s-1IEC559\s0 floating point
  exceptions encountered at compile time should not stop compilation.
! \&\*(C+ compilers have historically not followed this guidance, instead
! treating floating point division by zero as non-constant even though
  it has a well defined value.  This flag tells the compiler to give
  Annex F priority over other rules saying that a particular operation
  is undefined.
--- 3053,3064 ----
  users are likely to want to adjust it, but if your code does heavy
  constexpr calculations you might want to experiment to find which
  value works best for you.
! .IP \fB\-fconstexpr\-fp\-except\fR 4
  .IX Item "-fconstexpr-fp-except"
! Annex F of the C standard specifies that IEC559 floating point
  exceptions encountered at compile time should not stop compilation.
! C++ compilers have historically not followed this guidance, instead
! treating floating point division by zero as non\-constant even though
  it has a well defined value.  This flag tells the compiler to give
  Annex F priority over other rules saying that a particular operation
  is undefined.
*************** is undefined.
*** 3137,3148 ****
  .Vb 1
  \&        constexpr float inf = 1./0.; // OK with \-fconstexpr\-fp\-except
  .Ve
! .IP "\fB\-fconstexpr\-loop\-limit=\fR\fIn\fR" 4
  .IX Item "-fconstexpr-loop-limit=n"
! Set the maximum number of iterations for a loop in \*(C+14 constexpr functions
  to \fIn\fR.  A limit is needed to detect infinite loops during
  constant expression evaluation.  The default is 262144 (1<<18).
! .IP "\fB\-fconstexpr\-ops\-limit=\fR\fIn\fR" 4
  .IX Item "-fconstexpr-ops-limit=n"
  Set the maximum number of operations during a single constexpr evaluation.
  Even when number of iterations of a single loop is limited with the above limit,
--- 3066,3077 ----
  .Vb 1
  \&        constexpr float inf = 1./0.; // OK with \-fconstexpr\-fp\-except
  .Ve
! .IP \fB\-fconstexpr\-loop\-limit=\fR\fIn\fR 4
  .IX Item "-fconstexpr-loop-limit=n"
! Set the maximum number of iterations for a loop in C++14 constexpr functions
  to \fIn\fR.  A limit is needed to detect infinite loops during
  constant expression evaluation.  The default is 262144 (1<<18).
! .IP \fB\-fconstexpr\-ops\-limit=\fR\fIn\fR 4
  .IX Item "-fconstexpr-ops-limit=n"
  Set the maximum number of operations during a single constexpr evaluation.
  Even when number of iterations of a single loop is limited with the above limit,
*************** smaller than the above limit, or if in a
*** 3151,3164 ****
  of a loop too many expressions need to be evaluated, the resulting constexpr
  evaluation might take too long.
  The default is 33554432 (1<<25).
! .IP "\fB\-fcontracts\fR" 4
  .IX Item "-fcontracts"
! Enable experimental support for the \*(C+ Contracts feature, as briefly
! added to and then removed from the \*(C+20 working paper (N4820).  The
  implementation also includes proposed enhancements from papers P1290,
  P1332, and P1429.  This functionality is intended mostly for those
  interested in experimentation towards refining the feature to get it
! into shape for a future \*(C+ standard.
  .Sp
  On violation of a checked contract, the violation handler is called.
  Users can replace the violation handler by defining
--- 3080,3093 ----
  of a loop too many expressions need to be evaluated, the resulting constexpr
  evaluation might take too long.
  The default is 33554432 (1<<25).
! .IP \fB\-fcontracts\fR 4
  .IX Item "-fcontracts"
! Enable experimental support for the C++ Contracts feature, as briefly
! added to and then removed from the C++20 working paper (N4820).  The
  implementation also includes proposed enhancements from papers P1290,
  P1332, and P1429.  This functionality is intended mostly for those
  interested in experimentation towards refining the feature to get it
! into shape for a future C++ standard.
  .Sp
  On violation of a checked contract, the violation handler is called.
  Users can replace the violation handler by defining
*************** to specify which contracts will be check
*** 3173,3204 ****
  contracts, P1332 contracts, or P1429 contracts; these sets cannot be
  used together.
  .RS 4
! .IP "\fB\-fcontract\-mode=[on|off]\fR" 4
  .IX Item "-fcontract-mode=[on|off]"
  Control whether any contracts have any semantics at all.  Defaults to on.
! .IP "\fB\-fcontract\-assumption\-mode=[on|off]\fR" 4
  .IX Item "-fcontract-assumption-mode=[on|off]"
  [N4820] Control whether contracts with level \fBaxiom\fR
  should have the assume semantic.  Defaults to on.
! .IP "\fB\-fcontract\-build\-level=[off|default|audit]\fR" 4
  .IX Item "-fcontract-build-level=[off|default|audit]"
  [N4820] Specify which level of contracts to generate checks
  for.  Defaults to \fBdefault\fR.
! .IP "\fB\-fcontract\-continuation\-mode=[on|off]\fR" 4
  .IX Item "-fcontract-continuation-mode=[on|off]"
  [N4820] Control whether to allow the program to continue executing
  after a contract violation.  That is, do checked contracts have the
  \&\fBmaybe\fR semantic described below rather than the \fBnever\fR
  semantic.  Defaults to off.
! .IP "\fB\-fcontract\-role=:,,\fR" 4
  .IX Item "-fcontract-role=:,,"
  [P1332] Specify the concrete semantics for each contract level
  of a particular contract role.
! .IP "\fB\-fcontract\-semantic=[default|audit|axiom]:\fR" 4
  .IX Item "-fcontract-semantic=[default|audit|axiom]:"
  [P1429] Specify the concrete semantic for a particular
  contract level.
! .IP "\fB\-fcontract\-strict\-declarations=[on|off]\fR" 4
  .IX Item "-fcontract-strict-declarations=[on|off]"
  Control whether to reject adding contracts to a function after its
  first declaration.  Defaults to off.
--- 3102,3133 ----
  contracts, P1332 contracts, or P1429 contracts; these sets cannot be
  used together.
  .RS 4
! .IP \fB\-fcontract\-mode=[on|off]\fR 4
  .IX Item "-fcontract-mode=[on|off]"
  Control whether any contracts have any semantics at all.  Defaults to on.
! .IP \fB\-fcontract\-assumption\-mode=[on|off]\fR 4
  .IX Item "-fcontract-assumption-mode=[on|off]"
  [N4820] Control whether contracts with level \fBaxiom\fR
  should have the assume semantic.  Defaults to on.
! .IP \fB\-fcontract\-build\-level=[off|default|audit]\fR 4
  .IX Item "-fcontract-build-level=[off|default|audit]"
  [N4820] Specify which level of contracts to generate checks
  for.  Defaults to \fBdefault\fR.
! .IP \fB\-fcontract\-continuation\-mode=[on|off]\fR 4
  .IX Item "-fcontract-continuation-mode=[on|off]"
  [N4820] Control whether to allow the program to continue executing
  after a contract violation.  That is, do checked contracts have the
  \&\fBmaybe\fR semantic described below rather than the \fBnever\fR
  semantic.  Defaults to off.
! .IP \fB\-fcontract\-role=:,,\fR 4
  .IX Item "-fcontract-role=:,,"
  [P1332] Specify the concrete semantics for each contract level
  of a particular contract role.
! .IP \fB\-fcontract\-semantic=[default|audit|axiom]:\fR 4
  .IX Item "-fcontract-semantic=[default|audit|axiom]:"
  [P1429] Specify the concrete semantic for a particular
  contract level.
! .IP \fB\-fcontract\-strict\-declarations=[on|off]\fR 4
  .IX Item "-fcontract-strict-declarations=[on|off]"
  Control whether to reject adding contracts to a function after its
  first declaration.  Defaults to off.
*************** first declaration.  Defaults to off.
*** 3208,3239 ****
  The possible concrete semantics for that can be specified with
  \&\fB\-fcontract\-role\fR or \fB\-fcontract\-semantic\fR are:
  .ie n .IP """ignore""" 4
! .el .IP "\f(CWignore\fR" 4
  .IX Item "ignore"
  This contract has no effect.
  .ie n .IP """assume""" 4
! .el .IP "\f(CWassume\fR" 4
  .IX Item "assume"
! This contract is treated like \*(C+23 \f(CW\*(C`[[assume]]\*(C'\fR.
  .ie n .IP """check_never_continue""" 4
! .el .IP "\f(CWcheck_never_continue\fR" 4
  .IX Item "check_never_continue"
  .PD 0
  .ie n .IP """never""" 4
! .el .IP "\f(CWnever\fR" 4
  .IX Item "never"
  .ie n .IP """abort""" 4
! .el .IP "\f(CWabort\fR" 4
  .IX Item "abort"
  .PD
  This contract is checked.  If it fails, the violation handler is
  called.  If the handler returns, \f(CW\*(C`std::terminate\*(C'\fR is called.
  .ie n .IP """check_maybe_continue""" 4
! .el .IP "\f(CWcheck_maybe_continue\fR" 4
  .IX Item "check_maybe_continue"
  .PD 0
  .ie n .IP """maybe""" 4
! .el .IP "\f(CWmaybe\fR" 4
  .IX Item "maybe"
  .PD
  This contract is checked.  If it fails, the violation handler is
--- 3137,3168 ----
  The possible concrete semantics for that can be specified with
  \&\fB\-fcontract\-role\fR or \fB\-fcontract\-semantic\fR are:
  .ie n .IP """ignore""" 4
! .el .IP \f(CWignore\fR 4
  .IX Item "ignore"
  This contract has no effect.
  .ie n .IP """assume""" 4
! .el .IP \f(CWassume\fR 4
  .IX Item "assume"
! This contract is treated like C++23 \f(CW\*(C`[[assume]]\*(C'\fR.
  .ie n .IP """check_never_continue""" 4
! .el .IP \f(CWcheck_never_continue\fR 4
  .IX Item "check_never_continue"
  .PD 0
  .ie n .IP """never""" 4
! .el .IP \f(CWnever\fR 4
  .IX Item "never"
  .ie n .IP """abort""" 4
! .el .IP \f(CWabort\fR 4
  .IX Item "abort"
  .PD
  This contract is checked.  If it fails, the violation handler is
  called.  If the handler returns, \f(CW\*(C`std::terminate\*(C'\fR is called.
  .ie n .IP """check_maybe_continue""" 4
! .el .IP \f(CWcheck_maybe_continue\fR 4
  .IX Item "check_maybe_continue"
  .PD 0
  .ie n .IP """maybe""" 4
! .el .IP \f(CWmaybe\fR 4
  .IX Item "maybe"
  .PD
  This contract is checked.  If it fails, the violation handler is
*************** called.  If the handler returns, executi
*** 3241,3529 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-fcoroutines\fR" 4
  .IX Item "-fcoroutines"
! Enable support for the \*(C+ coroutines extension (experimental).
! .IP "\fB\-fno\-elide\-constructors\fR" 4
  .IX Item "-fno-elide-constructors"
! The \*(C+ standard allows an implementation to omit creating a temporary
  that is only used to initialize another object of the same type.
  Specifying this option disables that optimization, and forces G++ to
  call the copy constructor in all cases.  This option also causes G++
  to call trivial member functions which otherwise would be expanded inline.
  .Sp
! In \*(C+17, the compiler is required to omit these temporaries, but this
  option still affects trivial member functions.
! .IP "\fB\-fno\-enforce\-eh\-specs\fR" 4
  .IX Item "-fno-enforce-eh-specs"
! Don't generate code to check for violation of exception specifications
! at run time.  This option violates the \*(C+ standard, but may be useful
  for reducing code size in production builds, much like defining
  \&\f(CW\*(C`NDEBUG\*(C'\fR.  This does not give user code permission to throw
  exceptions in violation of the exception specifications; the compiler
  still optimizes based on the specifications, so throwing an
  unexpected exception results in undefined behavior at run time.
! .IP "\fB\-fextern\-tls\-init\fR" 4
  .IX Item "-fextern-tls-init"
  .PD 0
! .IP "\fB\-fno\-extern\-tls\-init\fR" 4
  .IX Item "-fno-extern-tls-init"
  .PD
! The \*(C+11 and OpenMP standards allow \f(CW\*(C`thread_local\*(C'\fR and
  \&\f(CW\*(C`threadprivate\*(C'\fR variables to have dynamic (runtime)
  initialization.  To support this, any use of such a variable goes
  through a wrapper function that performs any necessary initialization.
  When the use and definition of the variable are in the same
  translation unit, this overhead can be optimized away, but when the
  use is in a different translation unit there is significant overhead
! even if the variable doesn't actually need dynamic initialization.  If
  the programmer can be sure that no use of the variable in a
! non-defining \s-1TU\s0 needs to trigger dynamic initialization (either
  because the variable is statically initialized, or a use of the
! variable in the defining \s-1TU\s0 will be executed before any uses in
! another \s-1TU\s0), they can avoid this overhead with the
  \&\fB\-fno\-extern\-tls\-init\fR option.
  .Sp
  On targets that support symbol aliases, the default is
  \&\fB\-fextern\-tls\-init\fR.  On targets that do not support symbol
  aliases, the default is \fB\-fno\-extern\-tls\-init\fR.
! .IP "\fB\-ffold\-simple\-inlines\fR" 4
  .IX Item "-ffold-simple-inlines"
  .PD 0
! .IP "\fB\-fno\-fold\-simple\-inlines\fR" 4
  .IX Item "-fno-fold-simple-inlines"
  .PD
! Permit the \*(C+ frontend to fold calls to \f(CW\*(C`std::move\*(C'\fR, \f(CW\*(C`std::forward\*(C'\fR,
  \&\f(CW\*(C`std::addressof\*(C'\fR and \f(CW\*(C`std::as_const\*(C'\fR.  In contrast to inlining, this
  means no debug information will be generated for such calls.  Since these
  functions are rarely interesting to debug, this flag is enabled by default
  unless \fB\-fno\-inline\fR is active.
! .IP "\fB\-fno\-gnu\-keywords\fR" 4
  .IX Item "-fno-gnu-keywords"
  Do not recognize \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use this
  word as an identifier.  You can use the keyword \f(CW\*(C`_\|_typeof_\|_\*(C'\fR instead.
! This option is implied by the strict \s-1ISO \*(C+\s0 dialects: \fB\-ansi\fR,
  \&\fB\-std=c++98\fR, \fB\-std=c++11\fR, etc.
! .IP "\fB\-fimplicit\-constexpr\fR" 4
  .IX Item "-fimplicit-constexpr"
  Make inline functions implicitly constexpr, if they satisfy the
  requirements for a constexpr function.  This option can be used in
! \&\*(C+14 mode or later.  This can result in initialization changing from
  dynamic to static and other optimizations.
! .IP "\fB\-fno\-implicit\-templates\fR" 4
  .IX Item "-fno-implicit-templates"
! Never emit code for non-inline templates that are instantiated
  implicitly (i.e. by use); only emit code for explicit instantiations.
  If you use this option, you must take care to structure your code to
  include all the necessary explicit instantiations to avoid getting
  undefined symbols at link time.
! .IP "\fB\-fno\-implicit\-inline\-templates\fR" 4
  .IX Item "-fno-implicit-inline-templates"
! Don't emit code for implicit instantiations of inline templates, either.
  The default is to handle inlines differently so that compiles with and
  without optimization need the same set of explicit instantiations.
! .IP "\fB\-fno\-implement\-inlines\fR" 4
  .IX Item "-fno-implement-inlines"
! To save space, do not emit out-of-line copies of inline functions
  controlled by \f(CW\*(C`#pragma implementation\*(C'\fR.  This causes linker
  errors if these functions are not inlined everywhere they are called.
! .IP "\fB\-fmodules\-ts\fR" 4
  .IX Item "-fmodules-ts"
  .PD 0
! .IP "\fB\-fno\-modules\-ts\fR" 4
  .IX Item "-fno-modules-ts"
  .PD
! Enable support for \*(C+20 modules.  The
  \&\fB\-fno\-modules\-ts\fR is usually not needed, as that is the
! default.  Even though this is a \*(C+20 feature, it is not currently
  implicitly enabled by selecting that standard version.
! .IP "\fB\-fmodule\-header\fR" 4
  .IX Item "-fmodule-header"
  .PD 0
! .IP "\fB\-fmodule\-header=user\fR" 4
  .IX Item "-fmodule-header=user"
! .IP "\fB\-fmodule\-header=system\fR" 4
  .IX Item "-fmodule-header=system"
  .PD
  Compile a header file to create an importable header unit.
! .IP "\fB\-fmodule\-implicit\-inline\fR" 4
  .IX Item "-fmodule-implicit-inline"
  Member functions defined in their class definitions are not implicitly
! inline for modular code.  This is different to traditional \*(C+
  behavior, for good reasons.  However, it may result in a difficulty
  during code porting.  This option makes such function definitions
! implicitly inline.  It does however generate an \s-1ABI\s0 incompatibility,
  so you must use it everywhere or nowhere.  (Such definitions outside
  of a named module remain implicitly inline, regardless.)
! .IP "\fB\-fno\-module\-lazy\fR" 4
  .IX Item "-fno-module-lazy"
  Disable lazy module importing and module mapper creation.
! .IP "\fB\-fmodule\-mapper=\fR[\fIhostname\fR]\fB:\fR\fIport\fR[\fB?\fR\fIident\fR]" 4
  .IX Item "-fmodule-mapper=[hostname]:port[?ident]"
  .PD 0
  .IP "\fB\-fmodule\-mapper=|\fR\fIprogram\fR[\fB?\fR\fIident\fR]\fB \fR\fIargs...\fR" 4
  .IX Item "-fmodule-mapper=|program[?ident] args..."
! .IP "\fB\-fmodule\-mapper==\fR\fIsocket\fR[\fB?\fR\fIident\fR]" 4
  .IX Item "-fmodule-mapper==socket[?ident]"
! .IP "\fB\-fmodule\-mapper=<>\fR[\fIinout\fR][\fB?\fR\fIident\fR]" 4
  .IX Item "-fmodule-mapper=<>[inout][?ident]"
! .IP "\fB\-fmodule\-mapper=<\fR\fIin\fR\fB>\fR\fIout\fR[\fB?\fR\fIident\fR]" 4
  .IX Item "-fmodule-mapper=out[?ident]"
! .IP "\fB\-fmodule\-mapper=\fR\fIfile\fR[\fB?\fR\fIident\fR]" 4
  .IX Item "-fmodule-mapper=file[?ident]"
  .PD
  An oracle to query for module name to filename mappings.  If
! unspecified the \fB\s-1CXX_MODULE_MAPPER\s0\fR environment variable is used,
! and if that is unset, an in-process default is provided.
! .IP "\fB\-fmodule\-only\fR" 4
  .IX Item "-fmodule-only"
  Only emit the Compiled Module Interface, inhibiting any object file.
! .IP "\fB\-fms\-extensions\fR" 4
  .IX Item "-fms-extensions"
! Disable Wpedantic warnings about constructs used in \s-1MFC,\s0 such as implicit
! int and getting a pointer to member function via non-standard syntax.
! .IP "\fB\-fnew\-inheriting\-ctors\fR" 4
  .IX Item "-fnew-inheriting-ctors"
! Enable the P0136 adjustment to the semantics of \*(C+11 constructor
! inheritance.  This is part of \*(C+17 but also considered to be a Defect
! Report against \*(C+11 and \*(C+14.  This flag is enabled by default
  unless \fB\-fabi\-version=10\fR or lower is specified.
! .IP "\fB\-fnew\-ttp\-matching\fR" 4
  .IX Item "-fnew-ttp-matching"
  Enable the P0522 resolution to Core issue 150, template template
  parameters and default arguments: this allows a template with default
  template arguments as an argument for a template template parameter
  with fewer template parameters.  This flag is enabled by default for
  \&\fB\-std=c++17\fR.
! .IP "\fB\-fno\-nonansi\-builtins\fR" 4
  .IX Item "-fno-nonansi-builtins"
! Disable built-in declarations of functions that are not mandated by
! \&\s-1ANSI/ISO C.\s0  These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR,
  \&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions.
! .IP "\fB\-fnothrow\-opt\fR" 4
  .IX Item "-fnothrow-opt"
! Treat a \f(CW\*(C`throw()\*(C'\fR exception specification as if it were a
  \&\f(CW\*(C`noexcept\*(C'\fR specification to reduce or eliminate the text size
  overhead relative to a function with no exception specification.  If
! the function has local variables of types with non-trivial
  destructors, the exception specification actually makes the
! function smaller because the \s-1EH\s0 cleanups for those variables can be
  optimized away.  The semantic effect is that an exception thrown out of
  a function with such an exception specification results in a call
  to \f(CW\*(C`terminate\*(C'\fR rather than \f(CW\*(C`unexpected\*(C'\fR.
! .IP "\fB\-fno\-operator\-names\fR" 4
  .IX Item "-fno-operator-names"
  Do not treat the operator name keywords \f(CW\*(C`and\*(C'\fR, \f(CW\*(C`bitand\*(C'\fR,
  \&\f(CW\*(C`bitor\*(C'\fR, \f(CW\*(C`compl\*(C'\fR, \f(CW\*(C`not\*(C'\fR, \f(CW\*(C`or\*(C'\fR and \f(CW\*(C`xor\*(C'\fR as
  synonyms as keywords.
! .IP "\fB\-fno\-optional\-diags\fR" 4
  .IX Item "-fno-optional-diags"
  Disable diagnostics that the standard says a compiler does not need to
  issue.  Currently, the only such diagnostic issued by G++ is the one for
  a name having multiple meanings within a class.
! .IP "\fB\-fpermissive\fR" 4
  .IX Item "-fpermissive"
  Downgrade some diagnostics about nonconformant code from errors to
  warnings.  Thus, using \fB\-fpermissive\fR allows some
  nonconforming code to compile.
! .IP "\fB\-fno\-pretty\-templates\fR" 4
  .IX Item "-fno-pretty-templates"
  When an error message refers to a specialization of a function
  template, the compiler normally prints the signature of the
  template followed by the template arguments and any typedefs or
  typenames in the signature (e.g. \f(CW\*(C`void f(T) [with T = int]\*(C'\fR
! rather than \f(CW\*(C`void f(int)\*(C'\fR) so that it's clear which template is
  involved.  When an error message refers to a specialization of a class
  template, the compiler omits any template arguments that match
  the default template arguments for that template.  If either of these
  behaviors make it harder to understand the error message rather than
  easier, you can use \fB\-fno\-pretty\-templates\fR to disable them.
! .IP "\fB\-fno\-rtti\fR" 4
  .IX Item "-fno-rtti"
  Disable generation of information about every class with virtual
! functions for use by the \*(C+ run-time type identification features
! (\f(CW\*(C`dynamic_cast\*(C'\fR and \f(CW\*(C`typeid\*(C'\fR).  If you don't use those parts
  of the language, you can save some space by using this flag.  Note that
  exception handling uses the same information, but G++ generates it as
  needed. The \f(CW\*(C`dynamic_cast\*(C'\fR operator can still be used for casts that
! do not require run-time type information, i.e. casts to \f(CW\*(C`void *\*(C'\fR or to
  unambiguous base classes.
  .Sp
  Mixing code compiled with \fB\-frtti\fR with that compiled with
  \&\fB\-fno\-rtti\fR may not work.  For example, programs may
  fail to link if a class compiled with \fB\-fno\-rtti\fR is used as a base 
  for a class compiled with \fB\-frtti\fR.
! .IP "\fB\-fsized\-deallocation\fR" 4
  .IX Item "-fsized-deallocation"
! Enable the built-in global declarations
  .Sp
  .Vb 2
  \&        void operator delete (void *, std::size_t) noexcept;
  \&        void operator delete[] (void *, std::size_t) noexcept;
  .Ve
  .Sp
! as introduced in \*(C+14.  This is useful for user-defined replacement
  deallocation functions that, for example, use the size of the object
  to make deallocation faster.  Enabled by default under
  \&\fB\-std=c++14\fR and above.  The flag \fB\-Wsized\-deallocation\fR
  warns about places that might want to add a definition.
! .IP "\fB\-fstrict\-enums\fR" 4
  .IX Item "-fstrict-enums"
  Allow the compiler to optimize using the assumption that a value of
  enumerated type can only be one of the values of the enumeration (as
! defined in the \*(C+ standard; basically, a value that can be
  represented in the minimum number of bits needed to represent all the
  enumerators).  This assumption may not be valid if the program uses a
  cast to convert an arbitrary integer value to the enumerated type.
! .IP "\fB\-fstrong\-eval\-order\fR" 4
  .IX Item "-fstrong-eval-order"
  Evaluate member access, array subscripting, and shift expressions in
! left-to-right order, and evaluate assignment in right-to-left order,
! as adopted for \*(C+17.  Enabled by default with \fB\-std=c++17\fR.
  \&\fB\-fstrong\-eval\-order=some\fR enables just the ordering of member
  access and shift expressions, and is the default without
  \&\fB\-std=c++17\fR.
! .IP "\fB\-ftemplate\-backtrace\-limit=\fR\fIn\fR" 4
  .IX Item "-ftemplate-backtrace-limit=n"
  Set the maximum number of template instantiation notes for a single
  warning or error to \fIn\fR.  The default value is 10.
! .IP "\fB\-ftemplate\-depth=\fR\fIn\fR" 4
  .IX Item "-ftemplate-depth=n"
  Set the maximum instantiation depth for template classes to \fIn\fR.
  A limit on the template instantiation depth is needed to detect
! endless recursions during template class instantiation.  \s-1ANSI/ISO \*(C+\s0
  conforming programs must not rely on a maximum depth greater than 17
! (changed to 1024 in \*(C+11).  The default value is 900, as the compiler
  can run out of stack space before hitting 1024 in some situations.
! .IP "\fB\-fno\-threadsafe\-statics\fR" 4
  .IX Item "-fno-threadsafe-statics"
! Do not emit the extra code to use the routines specified in the \*(C+
! \&\s-1ABI\s0 for thread-safe initialization of local statics.  You can use this
! option to reduce code size slightly in code that doesn't need to be
! thread-safe.
! .IP "\fB\-fuse\-cxa\-atexit\fR" 4
  .IX Item "-fuse-cxa-atexit"
  Register destructors for objects with static storage duration with the
  \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR function rather than the \f(CW\*(C`atexit\*(C'\fR function.
! This option is required for fully standards-compliant handling of static
  destructors, but only works if your C library supports
  \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR.
! .IP "\fB\-fno\-use\-cxa\-get\-exception\-ptr\fR" 4
  .IX Item "-fno-use-cxa-get-exception-ptr"
! Don't use the \f(CW\*(C`_\|_cxa_get_exception_ptr\*(C'\fR runtime routine.  This
  causes \f(CW\*(C`std::uncaught_exception\*(C'\fR to be incorrect, but is necessary
  if the runtime routine is not available.
! .IP "\fB\-fvisibility\-inlines\-hidden\fR" 4
  .IX Item "-fvisibility-inlines-hidden"
  This switch declares that the user does not attempt to compare
  pointers to inline functions or methods where the addresses of the two functions
  are taken in different shared objects.
  .Sp
! The effect of this is that \s-1GCC\s0 may, effectively, mark inline methods with
  \&\f(CW\*(C`_\|_attribute_\|_ ((visibility ("hidden")))\*(C'\fR so that they do not
! appear in the export table of a \s-1DSO\s0 and do not require a \s-1PLT\s0 indirection
! when used within the \s-1DSO.\s0  Enabling this option can have a dramatic effect
! on load and link times of a \s-1DSO\s0 as it massively reduces the size of the
  dynamic export table when the library makes heavy use of templates.
  .Sp
  The behavior of this switch is not quite the same as marking the
--- 3170,3458 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-fcoroutines\fR 4
  .IX Item "-fcoroutines"
! Enable support for the C++ coroutines extension (experimental).
! .IP \fB\-fno\-elide\-constructors\fR 4
  .IX Item "-fno-elide-constructors"
! The C++ standard allows an implementation to omit creating a temporary
  that is only used to initialize another object of the same type.
  Specifying this option disables that optimization, and forces G++ to
  call the copy constructor in all cases.  This option also causes G++
  to call trivial member functions which otherwise would be expanded inline.
  .Sp
! In C++17, the compiler is required to omit these temporaries, but this
  option still affects trivial member functions.
! .IP \fB\-fno\-enforce\-eh\-specs\fR 4
  .IX Item "-fno-enforce-eh-specs"
! Don\*(Aqt generate code to check for violation of exception specifications
! at run time.  This option violates the C++ standard, but may be useful
  for reducing code size in production builds, much like defining
  \&\f(CW\*(C`NDEBUG\*(C'\fR.  This does not give user code permission to throw
  exceptions in violation of the exception specifications; the compiler
  still optimizes based on the specifications, so throwing an
  unexpected exception results in undefined behavior at run time.
! .IP \fB\-fextern\-tls\-init\fR 4
  .IX Item "-fextern-tls-init"
  .PD 0
! .IP \fB\-fno\-extern\-tls\-init\fR 4
  .IX Item "-fno-extern-tls-init"
  .PD
! The C++11 and OpenMP standards allow \f(CW\*(C`thread_local\*(C'\fR and
  \&\f(CW\*(C`threadprivate\*(C'\fR variables to have dynamic (runtime)
  initialization.  To support this, any use of such a variable goes
  through a wrapper function that performs any necessary initialization.
  When the use and definition of the variable are in the same
  translation unit, this overhead can be optimized away, but when the
  use is in a different translation unit there is significant overhead
! even if the variable doesn\*(Aqt actually need dynamic initialization.  If
  the programmer can be sure that no use of the variable in a
! non\-defining TU needs to trigger dynamic initialization (either
  because the variable is statically initialized, or a use of the
! variable in the defining TU will be executed before any uses in
! another TU), they can avoid this overhead with the
  \&\fB\-fno\-extern\-tls\-init\fR option.
  .Sp
  On targets that support symbol aliases, the default is
  \&\fB\-fextern\-tls\-init\fR.  On targets that do not support symbol
  aliases, the default is \fB\-fno\-extern\-tls\-init\fR.
! .IP \fB\-ffold\-simple\-inlines\fR 4
  .IX Item "-ffold-simple-inlines"
  .PD 0
! .IP \fB\-fno\-fold\-simple\-inlines\fR 4
  .IX Item "-fno-fold-simple-inlines"
  .PD
! Permit the C++ frontend to fold calls to \f(CW\*(C`std::move\*(C'\fR, \f(CW\*(C`std::forward\*(C'\fR,
  \&\f(CW\*(C`std::addressof\*(C'\fR and \f(CW\*(C`std::as_const\*(C'\fR.  In contrast to inlining, this
  means no debug information will be generated for such calls.  Since these
  functions are rarely interesting to debug, this flag is enabled by default
  unless \fB\-fno\-inline\fR is active.
! .IP \fB\-fno\-gnu\-keywords\fR 4
  .IX Item "-fno-gnu-keywords"
  Do not recognize \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use this
  word as an identifier.  You can use the keyword \f(CW\*(C`_\|_typeof_\|_\*(C'\fR instead.
! This option is implied by the strict ISO C++ dialects: \fB\-ansi\fR,
  \&\fB\-std=c++98\fR, \fB\-std=c++11\fR, etc.
! .IP \fB\-fimplicit\-constexpr\fR 4
  .IX Item "-fimplicit-constexpr"
  Make inline functions implicitly constexpr, if they satisfy the
  requirements for a constexpr function.  This option can be used in
! C++14 mode or later.  This can result in initialization changing from
  dynamic to static and other optimizations.
! .IP \fB\-fno\-implicit\-templates\fR 4
  .IX Item "-fno-implicit-templates"
! Never emit code for non\-inline templates that are instantiated
  implicitly (i.e. by use); only emit code for explicit instantiations.
  If you use this option, you must take care to structure your code to
  include all the necessary explicit instantiations to avoid getting
  undefined symbols at link time.
! .IP \fB\-fno\-implicit\-inline\-templates\fR 4
  .IX Item "-fno-implicit-inline-templates"
! Don\*(Aqt emit code for implicit instantiations of inline templates, either.
  The default is to handle inlines differently so that compiles with and
  without optimization need the same set of explicit instantiations.
! .IP \fB\-fno\-implement\-inlines\fR 4
  .IX Item "-fno-implement-inlines"
! To save space, do not emit out\-of\-line copies of inline functions
  controlled by \f(CW\*(C`#pragma implementation\*(C'\fR.  This causes linker
  errors if these functions are not inlined everywhere they are called.
! .IP \fB\-fmodules\-ts\fR 4
  .IX Item "-fmodules-ts"
  .PD 0
! .IP \fB\-fno\-modules\-ts\fR 4
  .IX Item "-fno-modules-ts"
  .PD
! Enable support for C++20 modules.  The
  \&\fB\-fno\-modules\-ts\fR is usually not needed, as that is the
! default.  Even though this is a C++20 feature, it is not currently
  implicitly enabled by selecting that standard version.
! .IP \fB\-fmodule\-header\fR 4
  .IX Item "-fmodule-header"
  .PD 0
! .IP \fB\-fmodule\-header=user\fR 4
  .IX Item "-fmodule-header=user"
! .IP \fB\-fmodule\-header=system\fR 4
  .IX Item "-fmodule-header=system"
  .PD
  Compile a header file to create an importable header unit.
! .IP \fB\-fmodule\-implicit\-inline\fR 4
  .IX Item "-fmodule-implicit-inline"
  Member functions defined in their class definitions are not implicitly
! inline for modular code.  This is different to traditional C++
  behavior, for good reasons.  However, it may result in a difficulty
  during code porting.  This option makes such function definitions
! implicitly inline.  It does however generate an ABI incompatibility,
  so you must use it everywhere or nowhere.  (Such definitions outside
  of a named module remain implicitly inline, regardless.)
! .IP \fB\-fno\-module\-lazy\fR 4
  .IX Item "-fno-module-lazy"
  Disable lazy module importing and module mapper creation.
! .IP \fB\-fmodule\-mapper=\fR[\fIhostname\fR]\fB:\fR\fIport\fR[\fB?\fR\fIident\fR] 4
  .IX Item "-fmodule-mapper=[hostname]:port[?ident]"
  .PD 0
  .IP "\fB\-fmodule\-mapper=|\fR\fIprogram\fR[\fB?\fR\fIident\fR]\fB \fR\fIargs...\fR" 4
  .IX Item "-fmodule-mapper=|program[?ident] args..."
! .IP \fB\-fmodule\-mapper==\fR\fIsocket\fR[\fB?\fR\fIident\fR] 4
  .IX Item "-fmodule-mapper==socket[?ident]"
! .IP \fB\-fmodule\-mapper=<>\fR[\fIinout\fR][\fB?\fR\fIident\fR] 4
  .IX Item "-fmodule-mapper=<>[inout][?ident]"
! .IP \fB\-fmodule\-mapper=<\fR\fIin\fR\fB>\fR\fIout\fR[\fB?\fR\fIident\fR] 4
  .IX Item "-fmodule-mapper=out[?ident]"
! .IP \fB\-fmodule\-mapper=\fR\fIfile\fR[\fB?\fR\fIident\fR] 4
  .IX Item "-fmodule-mapper=file[?ident]"
  .PD
  An oracle to query for module name to filename mappings.  If
! unspecified the \fBCXX_MODULE_MAPPER\fR environment variable is used,
! and if that is unset, an in\-process default is provided.
! .IP \fB\-fmodule\-only\fR 4
  .IX Item "-fmodule-only"
  Only emit the Compiled Module Interface, inhibiting any object file.
! .IP \fB\-fms\-extensions\fR 4
  .IX Item "-fms-extensions"
! Disable Wpedantic warnings about constructs used in MFC, such as implicit
! int and getting a pointer to member function via non\-standard syntax.
! .IP \fB\-fnew\-inheriting\-ctors\fR 4
  .IX Item "-fnew-inheriting-ctors"
! Enable the P0136 adjustment to the semantics of C++11 constructor
! inheritance.  This is part of C++17 but also considered to be a Defect
! Report against C++11 and C++14.  This flag is enabled by default
  unless \fB\-fabi\-version=10\fR or lower is specified.
! .IP \fB\-fnew\-ttp\-matching\fR 4
  .IX Item "-fnew-ttp-matching"
  Enable the P0522 resolution to Core issue 150, template template
  parameters and default arguments: this allows a template with default
  template arguments as an argument for a template template parameter
  with fewer template parameters.  This flag is enabled by default for
  \&\fB\-std=c++17\fR.
! .IP \fB\-fno\-nonansi\-builtins\fR 4
  .IX Item "-fno-nonansi-builtins"
! Disable built\-in declarations of functions that are not mandated by
! ANSI/ISO C.  These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR,
  \&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions.
! .IP \fB\-fnothrow\-opt\fR 4
  .IX Item "-fnothrow-opt"
! Treat a \f(CWthrow()\fR exception specification as if it were a
  \&\f(CW\*(C`noexcept\*(C'\fR specification to reduce or eliminate the text size
  overhead relative to a function with no exception specification.  If
! the function has local variables of types with non\-trivial
  destructors, the exception specification actually makes the
! function smaller because the EH cleanups for those variables can be
  optimized away.  The semantic effect is that an exception thrown out of
  a function with such an exception specification results in a call
  to \f(CW\*(C`terminate\*(C'\fR rather than \f(CW\*(C`unexpected\*(C'\fR.
! .IP \fB\-fno\-operator\-names\fR 4
  .IX Item "-fno-operator-names"
  Do not treat the operator name keywords \f(CW\*(C`and\*(C'\fR, \f(CW\*(C`bitand\*(C'\fR,
  \&\f(CW\*(C`bitor\*(C'\fR, \f(CW\*(C`compl\*(C'\fR, \f(CW\*(C`not\*(C'\fR, \f(CW\*(C`or\*(C'\fR and \f(CW\*(C`xor\*(C'\fR as
  synonyms as keywords.
! .IP \fB\-fno\-optional\-diags\fR 4
  .IX Item "-fno-optional-diags"
  Disable diagnostics that the standard says a compiler does not need to
  issue.  Currently, the only such diagnostic issued by G++ is the one for
  a name having multiple meanings within a class.
! .IP \fB\-fpermissive\fR 4
  .IX Item "-fpermissive"
  Downgrade some diagnostics about nonconformant code from errors to
  warnings.  Thus, using \fB\-fpermissive\fR allows some
  nonconforming code to compile.
! .IP \fB\-fno\-pretty\-templates\fR 4
  .IX Item "-fno-pretty-templates"
  When an error message refers to a specialization of a function
  template, the compiler normally prints the signature of the
  template followed by the template arguments and any typedefs or
  typenames in the signature (e.g. \f(CW\*(C`void f(T) [with T = int]\*(C'\fR
! rather than \f(CW\*(C`void f(int)\*(C'\fR) so that it\*(Aqs clear which template is
  involved.  When an error message refers to a specialization of a class
  template, the compiler omits any template arguments that match
  the default template arguments for that template.  If either of these
  behaviors make it harder to understand the error message rather than
  easier, you can use \fB\-fno\-pretty\-templates\fR to disable them.
! .IP \fB\-fno\-rtti\fR 4
  .IX Item "-fno-rtti"
  Disable generation of information about every class with virtual
! functions for use by the C++ run\-time type identification features
! (\f(CW\*(C`dynamic_cast\*(C'\fR and \f(CW\*(C`typeid\*(C'\fR).  If you don\*(Aqt use those parts
  of the language, you can save some space by using this flag.  Note that
  exception handling uses the same information, but G++ generates it as
  needed. The \f(CW\*(C`dynamic_cast\*(C'\fR operator can still be used for casts that
! do not require run\-time type information, i.e. casts to \f(CW\*(C`void *\*(C'\fR or to
  unambiguous base classes.
  .Sp
  Mixing code compiled with \fB\-frtti\fR with that compiled with
  \&\fB\-fno\-rtti\fR may not work.  For example, programs may
  fail to link if a class compiled with \fB\-fno\-rtti\fR is used as a base 
  for a class compiled with \fB\-frtti\fR.
! .IP \fB\-fsized\-deallocation\fR 4
  .IX Item "-fsized-deallocation"
! Enable the built\-in global declarations
  .Sp
  .Vb 2
  \&        void operator delete (void *, std::size_t) noexcept;
  \&        void operator delete[] (void *, std::size_t) noexcept;
  .Ve
  .Sp
! as introduced in C++14.  This is useful for user\-defined replacement
  deallocation functions that, for example, use the size of the object
  to make deallocation faster.  Enabled by default under
  \&\fB\-std=c++14\fR and above.  The flag \fB\-Wsized\-deallocation\fR
  warns about places that might want to add a definition.
! .IP \fB\-fstrict\-enums\fR 4
  .IX Item "-fstrict-enums"
  Allow the compiler to optimize using the assumption that a value of
  enumerated type can only be one of the values of the enumeration (as
! defined in the C++ standard; basically, a value that can be
  represented in the minimum number of bits needed to represent all the
  enumerators).  This assumption may not be valid if the program uses a
  cast to convert an arbitrary integer value to the enumerated type.
! .IP \fB\-fstrong\-eval\-order\fR 4
  .IX Item "-fstrong-eval-order"
  Evaluate member access, array subscripting, and shift expressions in
! left\-to\-right order, and evaluate assignment in right\-to\-left order,
! as adopted for C++17.  Enabled by default with \fB\-std=c++17\fR.
  \&\fB\-fstrong\-eval\-order=some\fR enables just the ordering of member
  access and shift expressions, and is the default without
  \&\fB\-std=c++17\fR.
! .IP \fB\-ftemplate\-backtrace\-limit=\fR\fIn\fR 4
  .IX Item "-ftemplate-backtrace-limit=n"
  Set the maximum number of template instantiation notes for a single
  warning or error to \fIn\fR.  The default value is 10.
! .IP \fB\-ftemplate\-depth=\fR\fIn\fR 4
  .IX Item "-ftemplate-depth=n"
  Set the maximum instantiation depth for template classes to \fIn\fR.
  A limit on the template instantiation depth is needed to detect
! endless recursions during template class instantiation.  ANSI/ISO C++
  conforming programs must not rely on a maximum depth greater than 17
! (changed to 1024 in C++11).  The default value is 900, as the compiler
  can run out of stack space before hitting 1024 in some situations.
! .IP \fB\-fno\-threadsafe\-statics\fR 4
  .IX Item "-fno-threadsafe-statics"
! Do not emit the extra code to use the routines specified in the C++
! ABI for thread\-safe initialization of local statics.  You can use this
! option to reduce code size slightly in code that doesn\*(Aqt need to be
! thread\-safe.
! .IP \fB\-fuse\-cxa\-atexit\fR 4
  .IX Item "-fuse-cxa-atexit"
  Register destructors for objects with static storage duration with the
  \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR function rather than the \f(CW\*(C`atexit\*(C'\fR function.
! This option is required for fully standards\-compliant handling of static
  destructors, but only works if your C library supports
  \&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR.
! .IP \fB\-fno\-use\-cxa\-get\-exception\-ptr\fR 4
  .IX Item "-fno-use-cxa-get-exception-ptr"
! Don\*(Aqt use the \f(CW\*(C`_\|_cxa_get_exception_ptr\*(C'\fR runtime routine.  This
  causes \f(CW\*(C`std::uncaught_exception\*(C'\fR to be incorrect, but is necessary
  if the runtime routine is not available.
! .IP \fB\-fvisibility\-inlines\-hidden\fR 4
  .IX Item "-fvisibility-inlines-hidden"
  This switch declares that the user does not attempt to compare
  pointers to inline functions or methods where the addresses of the two functions
  are taken in different shared objects.
  .Sp
! The effect of this is that GCC may, effectively, mark inline methods with
  \&\f(CW\*(C`_\|_attribute_\|_ ((visibility ("hidden")))\*(C'\fR so that they do not
! appear in the export table of a 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.
  .Sp
  The behavior of this switch is not quite the same as marking the
*************** visibility has no effect.
*** 3539,3559 ****
  .Sp
  Explicitly instantiated inline methods are unaffected by this option
  as their linkage might otherwise cross a shared library boundary.
! .IP "\fB\-fvisibility\-ms\-compat\fR" 4
  .IX Item "-fvisibility-ms-compat"
! This flag attempts to use visibility settings to make \s-1GCC\s0's \*(C+
  linkage model compatible with that of Microsoft Visual Studio.
  .Sp
! The flag makes these changes to \s-1GCC\s0's linkage model:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  It sets the default visibility to \f(CW\*(C`hidden\*(C'\fR, like
  \&\fB\-fvisibility=hidden\fR.
! .IP "2." 4
  .IX Item "2."
  Types, but not their members, are not hidden by default.
! .IP "3." 4
  .IX Item "3."
  The One Definition Rule is relaxed for types without explicit
  visibility specifications that are defined in more than one
--- 3468,3488 ----
  .Sp
  Explicitly instantiated inline methods are unaffected by this option
  as their linkage might otherwise cross a shared library boundary.
! .IP \fB\-fvisibility\-ms\-compat\fR 4
  .IX Item "-fvisibility-ms-compat"
! This flag attempts to use visibility settings to make GCC\*(Aqs C++
  linkage model compatible with that of Microsoft Visual Studio.
  .Sp
! The flag makes these changes to GCC\*(Aqs linkage model:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  It sets the default visibility to \f(CW\*(C`hidden\*(C'\fR, like
  \&\fB\-fvisibility=hidden\fR.
! .IP 2. 4
  .IX Item "2."
  Types, but not their members, are not hidden by default.
! .IP 3. 4
  .IX Item "3."
  The One Definition Rule is relaxed for types without explicit
  visibility specifications that are defined in more than one
*************** of the same type with the same name but
*** 3572,3608 ****
  objects are different, so changing one does not change the other;
  and that pointers to function members defined in different shared
  objects may not compare equal.  When this flag is given, it is a
! violation of the \s-1ODR\s0 to define types with the same name differently.
  .RE
! .IP "\fB\-fno\-weak\fR" 4
  .IX Item "-fno-weak"
  Do not use weak symbol support, even if it is provided by the linker.
  By default, G++ uses weak symbols if they are available.  This
! option exists only for testing, and should not be used by end-users;
  it results in inferior code and has no benefits.  This option may
  be removed in a future release of G++.
! .IP "\fB\-fext\-numeric\-literals\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-fext-numeric-literals ( and Objective- only)"
! Accept imaginary, fixed-point, or machine-defined
! literal number suffixes as \s-1GNU\s0 extensions.
  When this option is turned off these suffixes are treated
! as \*(C+11 user-defined literal numeric suffixes.
! This is on by default for all pre\-\*(C+11 dialects and all \s-1GNU\s0 dialects:
  \&\fB\-std=c++98\fR, \fB\-std=gnu++98\fR, \fB\-std=gnu++11\fR,
  \&\fB\-std=gnu++14\fR.
  This option is off by default
! for \s-1ISO \*(C+11\s0 onwards (\fB\-std=c++11\fR, ...).
! .IP "\fB\-nostdinc++\fR" 4
  .IX Item "-nostdinc++"
  Do not search for header files in the standard directories specific to
! \&\*(C+, but do still search the other standard directories.  (This option
! is used when building the \*(C+ library.)
! .IP "\fB\-flang\-info\-include\-translate\fR" 4
  .IX Item "-flang-info-include-translate"
  .PD 0
! .IP "\fB\-flang\-info\-include\-translate\-not\fR" 4
  .IX Item "-flang-info-include-translate-not"
! .IP "\fB\-flang\-info\-include\-translate=\fR\fIheader\fR" 4
  .IX Item "-flang-info-include-translate=header"
  .PD
  Inform of include translation events.  The first will note accepted
--- 3501,3537 ----
  objects are different, so changing one does not change the other;
  and that pointers to function members defined in different shared
  objects may not compare equal.  When this flag is given, it is a
! violation of the ODR to define types with the same name differently.
  .RE
! .IP \fB\-fno\-weak\fR 4
  .IX Item "-fno-weak"
  Do not use weak symbol support, even if it is provided by the linker.
  By default, G++ uses weak symbols if they are available.  This
! option exists only for testing, and should not be used by end\-users;
  it results in inferior code and has no benefits.  This option may
  be removed in a future release of G++.
! .IP "\fB\-fext\-numeric\-literals\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-fext-numeric-literals (C++ and Objective-C++ only)"
! Accept imaginary, fixed\-point, or machine\-defined
! literal number suffixes as GNU extensions.
  When this option is turned off these suffixes are treated
! as C++11 user\-defined literal numeric suffixes.
! This is on by default for all pre\-C++11 dialects and all GNU dialects:
  \&\fB\-std=c++98\fR, \fB\-std=gnu++98\fR, \fB\-std=gnu++11\fR,
  \&\fB\-std=gnu++14\fR.
  This option is off by default
! for ISO C++11 onwards (\fB\-std=c++11\fR, ...).
! .IP \fB\-nostdinc++\fR 4
  .IX Item "-nostdinc++"
  Do not search for header files in the standard directories specific to
! C++, but do still search the other standard directories.  (This option
! is used when building the C++ library.)
! .IP \fB\-flang\-info\-include\-translate\fR 4
  .IX Item "-flang-info-include-translate"
  .PD 0
! .IP \fB\-flang\-info\-include\-translate\-not\fR 4
  .IX Item "-flang-info-include-translate-not"
! .IP \fB\-flang\-info\-include\-translate=\fR\fIheader\fR 4
  .IX Item "-flang-info-include-translate=header"
  .PD
  Inform of include translation events.  The first will note accepted
*************** translations.  The \fIheader\fR form wil
*** 3611,3647 ****
  translations relating to that specific header.  If \fIheader\fR is of
  the form \f(CW"user"\fR or \f(CW\*(C`\*(C'\fR it will be resolved to a
  specific user or system header using the include path.
! .IP "\fB\-flang\-info\-module\-cmi\fR" 4
  .IX Item "-flang-info-module-cmi"
  .PD 0
! .IP "\fB\-flang\-info\-module\-cmi=\fR\fImodule\fR" 4
  .IX Item "-flang-info-module-cmi=module"
  .PD
  Inform of Compiled Module Interface pathnames.  The first will note
! all read \s-1CMI\s0 pathnames.  The \fImodule\fR form will not reading a
! specific module's \s-1CMI.\s0  \fImodule\fR may be a named module or a
! header-unit (the latter indicated by either being a pathname containing
  directory separators or enclosed in \f(CW\*(C`<>\*(C'\fR or \f(CW""\fR).
! .IP "\fB\-stdlib=\fR\fIlibstdc++,libc++\fR" 4
  .IX Item "-stdlib=libstdc++,libc++"
  When G++ is configured to support this option, it allows specification of
! alternate \*(C+ runtime libraries.  Two options are available: \fIlibstdc++\fR
! (the default, native \*(C+ runtime for G++) and \fIlibc++\fR which is the
! \&\*(C+ runtime installed on some operating systems (e.g. Darwin versions from
  Darwin11 onwards).  The option switches G++ to use the headers from the
  specified library and to emit \f(CW\*(C`\-lstdc++\*(C'\fR or \f(CW\*(C`\-lc++\*(C'\fR respectively,
! when a \*(C+ runtime is required for linking.
  .PP
! In addition, these warning options have meanings only for \*(C+ programs:
! .IP "\fB\-Wabi\-tag\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wabi-tag ( and Objective- only)"
! Warn when a type with an \s-1ABI\s0 tag is used in a context that does not
! have that \s-1ABI\s0 tag.  See \fB\*(C+ Attributes\fR for more information
! about \s-1ABI\s0 tags.
! .IP "\fB\-Wcomma\-subscript\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wcomma-subscript ( and Objective- only)"
  Warn about uses of a comma expression within a subscripting expression.
! This usage was deprecated in \*(C+20 and is going to be removed in \*(C+23.
  However, a comma expression wrapped in \f(CW\*(C`( )\*(C'\fR is not deprecated.  Example:
  .Sp
  .Vb 4
--- 3540,3576 ----
  translations relating to that specific header.  If \fIheader\fR is of
  the form \f(CW"user"\fR or \f(CW\*(C`\*(C'\fR it will be resolved to a
  specific user or system header using the include path.
! .IP \fB\-flang\-info\-module\-cmi\fR 4
  .IX Item "-flang-info-module-cmi"
  .PD 0
! .IP \fB\-flang\-info\-module\-cmi=\fR\fImodule\fR 4
  .IX Item "-flang-info-module-cmi=module"
  .PD
  Inform of Compiled Module Interface pathnames.  The first will note
! all read CMI pathnames.  The \fImodule\fR form will not reading a
! specific module\*(Aqs CMI.  \fImodule\fR may be a named module or a
! header\-unit (the latter indicated by either being a pathname containing
  directory separators or enclosed in \f(CW\*(C`<>\*(C'\fR or \f(CW""\fR).
! .IP \fB\-stdlib=\fR\fIlibstdc++,libc++\fR 4
  .IX Item "-stdlib=libstdc++,libc++"
  When G++ is configured to support this option, it allows specification of
! alternate C++ runtime libraries.  Two options are available: \fIlibstdc++\fR
! (the default, native C++ runtime for G++) and \fIlibc++\fR which is the
! C++ runtime installed on some operating systems (e.g. Darwin versions from
  Darwin11 onwards).  The option switches G++ to use the headers from the
  specified library and to emit \f(CW\*(C`\-lstdc++\*(C'\fR or \f(CW\*(C`\-lc++\*(C'\fR respectively,
! when a C++ runtime is required for linking.
  .PP
! In addition, these warning options have meanings only for C++ programs:
! .IP "\fB\-Wabi\-tag\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wabi-tag (C++ and Objective-C++ only)"
! Warn when a type with an ABI tag is used in a context that does not
! have that ABI tag.  See \fBC++ Attributes\fR for more information
! about ABI tags.
! .IP "\fB\-Wcomma\-subscript\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wcomma-subscript (C++ and Objective-C++ only)"
  Warn about uses of a comma expression within a subscripting expression.
! This usage was deprecated in C++20 and is going to be removed in C++23.
  However, a comma expression wrapped in \f(CW\*(C`( )\*(C'\fR is not deprecated.  Example:
  .Sp
  .Vb 4
*************** However, a comma expression wrapped in \
*** 3651,3673 ****
  \&        }
  .Ve
  .Sp
! In \*(C+23 it is valid to have comma separated expressions in a subscript
  when an overloaded subscript operator is found and supports the right
  number and types of arguments.  G++ will accept the formerly valid syntax
! for code that is not valid in \*(C+23 but used to be valid but deprecated
! in \*(C+20 with a pedantic warning that can be disabled with
  \&\fB\-Wno\-comma\-subscript\fR.
  .Sp
  Enabled by default with \fB\-std=c++20\fR unless \fB\-Wno\-deprecated\fR,
  and with \fB\-std=c++23\fR regardless of \fB\-Wno\-deprecated\fR.
! .IP "\fB\-Wctad\-maybe\-unsupported\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wctad-maybe-unsupported ( and Objective- only)"
! Warn when performing class template argument deduction (\s-1CTAD\s0) on a type with
  no explicitly written deduction guides.  This warning will point out cases
! where \s-1CTAD\s0 succeeded only because the compiler synthesized the implicit
  deduction guides, which might not be what the programmer intended.  Certain
! style guides allow \s-1CTAD\s0 only on types that specifically \*(L"opt-in\*(R"; i.e., on
! types that are designed to support \s-1CTAD.\s0  This warning can be suppressed with
  the following pattern:
  .Sp
  .Vb 6
--- 3580,3602 ----
  \&        }
  .Ve
  .Sp
! In C++23 it is valid to have comma separated expressions in a subscript
  when an overloaded subscript operator is found and supports the right
  number and types of arguments.  G++ will accept the formerly valid syntax
! for code that is not valid in C++23 but used to be valid but deprecated
! in C++20 with a pedantic warning that can be disabled with
  \&\fB\-Wno\-comma\-subscript\fR.
  .Sp
  Enabled by default with \fB\-std=c++20\fR unless \fB\-Wno\-deprecated\fR,
  and with \fB\-std=c++23\fR regardless of \fB\-Wno\-deprecated\fR.
! .IP "\fB\-Wctad\-maybe\-unsupported\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wctad-maybe-unsupported (C++ and Objective-C++ only)"
! Warn when performing class template argument deduction (CTAD) on a type with
  no explicitly written deduction guides.  This warning will point out cases
! where CTAD succeeded only because the compiler synthesized the implicit
  deduction guides, which might not be what the programmer intended.  Certain
! style guides allow CTAD only on types that specifically "opt\-in"; i.e., on
! types that are designed to support CTAD.  This warning can be suppressed with
  the following pattern:
  .Sp
  .Vb 6
*************** the following pattern:
*** 3678,3692 ****
  \&        // Guide with incomplete parameter type will never be considered.
  \&        S(allow_ctad_t) \-> S;
  .Ve
! .IP "\fB\-Wctor\-dtor\-privacy\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wctor-dtor-privacy ( and Objective- only)"
  Warn when a class seems unusable because all the constructors or
  destructors in that class are private, and it has neither friends nor
! public static member functions.  Also warn if there are no non-private
! methods, and there's at least one private member function that isn't
  a constructor or destructor.
! .IP "\fB\-Wdangling\-reference\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wdangling-reference ( and Objective- only)"
  Warn when a reference is bound to a temporary whose lifetime has ended.
  For example:
  .Sp
--- 3607,3621 ----
  \&        // Guide with incomplete parameter type will never be considered.
  \&        S(allow_ctad_t) \-> S;
  .Ve
! .IP "\fB\-Wctor\-dtor\-privacy\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wctor-dtor-privacy (C++ and Objective-C++ only)"
  Warn when a class seems unusable because all the constructors or
  destructors in that class are private, and it has neither friends nor
! public static member functions.  Also warn if there are no non\-private
! methods, and there\*(Aqs at least one private member function that isn\*(Aqt
  a constructor or destructor.
! .IP "\fB\-Wdangling\-reference\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wdangling-reference (C++ and Objective-C++ only)"
  Warn when a reference is bound to a temporary whose lifetime has ended.
  For example:
  .Sp
*************** Member functions are checked as well, bu
*** 3719,3725 ****
  .Ve
  .Sp
  Certain functions are safe in this respect, for example \f(CW\*(C`std::use_facet\*(C'\fR:
! they take and return a reference, but they don't return one of its arguments,
  which can fool the warning.  Such functions can be excluded from the warning
  by wrapping them in a \f(CW\*(C`#pragma\*(C'\fR:
  .Sp
--- 3648,3654 ----
  .Ve
  .Sp
  Certain functions are safe in this respect, for example \f(CW\*(C`std::use_facet\*(C'\fR:
! they take and return a reference, but they don\*(Aqt return one of its arguments,
  which can fool the warning.  Such functions can be excluded from the warning
  by wrapping them in a \f(CW\*(C`#pragma\*(C'\fR:
  .Sp
*************** both references dangle after the end of
*** 3741,3766 ****
  the call to \f(CW\*(C`std::minmax\*(C'\fR.
  .Sp
  This warning is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wdelete\-non\-virtual\-dtor\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wdelete-non-virtual-dtor ( and Objective- only)"
  Warn when \f(CW\*(C`delete\*(C'\fR is used to destroy an instance of a class that
! has virtual functions and non-virtual destructor. It is unsafe to delete
  an instance of a derived class through a pointer to a base class if the
  base class does not have a virtual destructor.  This warning is enabled
  by \fB\-Wall\fR.
! .IP "\fB\-Wdeprecated\-copy\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wdeprecated-copy ( and Objective- only)"
  Warn that the implicit declaration of a copy constructor or copy
! assignment operator is deprecated if the class has a user-provided
! copy constructor or copy assignment operator, in \*(C+11 and up.  This
  warning is enabled by \fB\-Wextra\fR.  With
  \&\fB\-Wdeprecated\-copy\-dtor\fR, also deprecate if the class has a
! user-provided destructor.
! .IP "\fB\-Wno\-deprecated\-enum\-enum\-conversion\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-deprecated-enum-enum-conversion ( and Objective- only)"
  Disable the warning about the case when the usual arithmetic conversions
  are applied on operands where one is of enumeration type and the other is
! of a different enumeration type.  This conversion was deprecated in \*(C+20.
  For example:
  .Sp
  .Vb 3
--- 3670,3695 ----
  the call to \f(CW\*(C`std::minmax\*(C'\fR.
  .Sp
  This warning is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wdelete\-non\-virtual\-dtor\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wdelete-non-virtual-dtor (C++ and Objective-C++ only)"
  Warn when \f(CW\*(C`delete\*(C'\fR is used to destroy an instance of a class that
! has virtual functions and non\-virtual destructor. It is unsafe to delete
  an instance of a derived class through a pointer to a base class if the
  base class does not have a virtual destructor.  This warning is enabled
  by \fB\-Wall\fR.
! .IP "\fB\-Wdeprecated\-copy\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wdeprecated-copy (C++ and Objective-C++ only)"
  Warn that the implicit declaration of a copy constructor or copy
! assignment operator is deprecated if the class has a user\-provided
! copy constructor or copy assignment operator, in C++11 and up.  This
  warning is enabled by \fB\-Wextra\fR.  With
  \&\fB\-Wdeprecated\-copy\-dtor\fR, also deprecate if the class has a
! user\-provided destructor.
! .IP "\fB\-Wno\-deprecated\-enum\-enum\-conversion\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-deprecated-enum-enum-conversion (C++ and Objective-C++ only)"
  Disable the warning about the case when the usual arithmetic conversions
  are applied on operands where one is of enumeration type and the other is
! of a different enumeration type.  This conversion was deprecated in C++20.
  For example:
  .Sp
  .Vb 3
*************** For example:
*** 3770,3782 ****
  .Ve
  .Sp
  \&\fB\-Wdeprecated\-enum\-enum\-conversion\fR is enabled by default with
! \&\fB\-std=c++20\fR.  In pre\-\*(C+20 dialects, this warning can be enabled
  by \fB\-Wenum\-conversion\fR.
! .IP "\fB\-Wno\-deprecated\-enum\-float\-conversion\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-deprecated-enum-float-conversion ( and Objective- only)"
  Disable the warning about the case when the usual arithmetic conversions
  are applied on operands where one is of enumeration type and the other is
! of a floating-point type.  This conversion was deprecated in \*(C+20.  For
  example:
  .Sp
  .Vb 3
--- 3699,3711 ----
  .Ve
  .Sp
  \&\fB\-Wdeprecated\-enum\-enum\-conversion\fR is enabled by default with
! \&\fB\-std=c++20\fR.  In pre\-C++20 dialects, this warning can be enabled
  by \fB\-Wenum\-conversion\fR.
! .IP "\fB\-Wno\-deprecated\-enum\-float\-conversion\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-deprecated-enum-float-conversion (C++ and Objective-C++ only)"
  Disable the warning about the case when the usual arithmetic conversions
  are applied on operands where one is of enumeration type and the other is
! of a floating\-point type.  This conversion was deprecated in C++20.  For
  example:
  .Sp
  .Vb 3
*************** example:
*** 3786,3814 ****
  .Ve
  .Sp
  \&\fB\-Wdeprecated\-enum\-float\-conversion\fR is enabled by default with
! \&\fB\-std=c++20\fR.  In pre\-\*(C+20 dialects, this warning can be enabled
  by \fB\-Wenum\-conversion\fR.
! .IP "\fB\-Wno\-init\-list\-lifetime\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-init-list-lifetime ( and Objective- only)"
  Do not warn about uses of \f(CW\*(C`std::initializer_list\*(C'\fR that are likely
  to result in dangling pointers.  Since the underlying array for an
! \&\f(CW\*(C`initializer_list\*(C'\fR is handled like a normal \*(C+ temporary object,
  it is easy to inadvertently keep a pointer to the array past the end
! of the array's lifetime.  For example:
  .RS 4
! .IP "*" 4
  If a function returns a temporary \f(CW\*(C`initializer_list\*(C'\fR, or a local
! \&\f(CW\*(C`initializer_list\*(C'\fR variable, the array's lifetime ends at the end
  of the return statement, so the value returned has a dangling pointer.
! .IP "*" 4
! If a new-expression creates an \f(CW\*(C`initializer_list\*(C'\fR, the array only
! lives until the end of the enclosing full-expression, so the
  \&\f(CW\*(C`initializer_list\*(C'\fR in the heap has a dangling pointer.
! .IP "*" 4
  When an \f(CW\*(C`initializer_list\*(C'\fR variable is assigned from a
! brace-enclosed initializer list, the temporary array created for the
  right side of the assignment only lives until the end of the
! full-expression, so at the next statement the \f(CW\*(C`initializer_list\*(C'\fR
  variable has a dangling pointer.
  .Sp
  .Vb 6
--- 3715,3743 ----
  .Ve
  .Sp
  \&\fB\-Wdeprecated\-enum\-float\-conversion\fR is enabled by default with
! \&\fB\-std=c++20\fR.  In pre\-C++20 dialects, this warning can be enabled
  by \fB\-Wenum\-conversion\fR.
! .IP "\fB\-Wno\-init\-list\-lifetime\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-init-list-lifetime (C++ and Objective-C++ only)"
  Do not warn about uses of \f(CW\*(C`std::initializer_list\*(C'\fR that are likely
  to result in dangling pointers.  Since the underlying array for an
! \&\f(CW\*(C`initializer_list\*(C'\fR is handled like a normal C++ temporary object,
  it is easy to inadvertently keep a pointer to the array past the end
! of the array\*(Aqs lifetime.  For example:
  .RS 4
! .IP * 4
  If a function returns a temporary \f(CW\*(C`initializer_list\*(C'\fR, or a local
! \&\f(CW\*(C`initializer_list\*(C'\fR variable, the array\*(Aqs lifetime ends at the end
  of the return statement, so the value returned has a dangling pointer.
! .IP * 4
! If a new\-expression creates an \f(CW\*(C`initializer_list\*(C'\fR, the array only
! lives until the end of the enclosing full\-expression, so the
  \&\f(CW\*(C`initializer_list\*(C'\fR in the heap has a dangling pointer.
! .IP * 4
  When an \f(CW\*(C`initializer_list\*(C'\fR variable is assigned from a
! brace\-enclosed initializer list, the temporary array created for the
  right side of the assignment only lives until the end of the
! full\-expression, so at the next statement the \f(CW\*(C`initializer_list\*(C'\fR
  variable has a dangling pointer.
  .Sp
  .Vb 6
*************** variable has a dangling pointer.
*** 3819,3846 ****
  \&        // now the temporary is gone and li has a dangling pointer
  \&        int i = li.begin()[0] // undefined behavior
  .Ve
! .IP "*" 4
  When a list constructor stores the \f(CW\*(C`begin\*(C'\fR pointer from the
! \&\f(CW\*(C`initializer_list\*(C'\fR argument, this doesn't extend the lifetime of
  the array, so if a class variable is constructed from a temporary
  \&\f(CW\*(C`initializer_list\*(C'\fR, the pointer is left dangling by the end of
  the variable declaration statement.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Winvalid\-constexpr\fR" 4
  .IX Item "-Winvalid-constexpr"
! Warn when a function never produces a constant expression.  In \*(C+20
  and earlier, for every \f(CW\*(C`constexpr\*(C'\fR function and function template,
  there must be at least one set of function arguments in at least one
  instantiation such that an invocation of the function or constructor
  could be an evaluated subexpression of a core constant expression.
! \&\*(C+23 removed this restriction, so it's possible to have a function
  or a function template marked \f(CW\*(C`constexpr\*(C'\fR for which no invocation
  satisfies the requirements of a core constant expression.
  .Sp
! This warning is enabled as a pedantic warning by default in \*(C+20 and
! earlier.  In \*(C+23, \fB\-Winvalid\-constexpr\fR can be turned on, in
  which case it will be an ordinary warning.  For example:
  .Sp
  .Vb 7
--- 3748,3775 ----
  \&        // now the temporary is gone and li has a dangling pointer
  \&        int i = li.begin()[0] // undefined behavior
  .Ve
! .IP * 4
  When a list constructor stores the \f(CW\*(C`begin\*(C'\fR pointer from the
! \&\f(CW\*(C`initializer_list\*(C'\fR argument, this doesn\*(Aqt extend the lifetime of
  the array, so if a class variable is constructed from a temporary
  \&\f(CW\*(C`initializer_list\*(C'\fR, the pointer is left dangling by the end of
  the variable declaration statement.
  .RE
  .RS 4
  .RE
! .IP \fB\-Winvalid\-constexpr\fR 4
  .IX Item "-Winvalid-constexpr"
! Warn when a function never produces a constant expression.  In C++20
  and earlier, for every \f(CW\*(C`constexpr\*(C'\fR function and function template,
  there must be at least one set of function arguments in at least one
  instantiation such that an invocation of the function or constructor
  could be an evaluated subexpression of a core constant expression.
! C++23 removed this restriction, so it\*(Aqs possible to have a function
  or a function template marked \f(CW\*(C`constexpr\*(C'\fR for which no invocation
  satisfies the requirements of a core constant expression.
  .Sp
! This warning is enabled as a pedantic warning by default in C++20 and
! earlier.  In C++23, \fB\-Winvalid\-constexpr\fR can be turned on, in
  which case it will be an ordinary warning.  For example:
  .Sp
  .Vb 7
*************** which case it will be an ordinary warnin
*** 3852,3868 ****
  \&          f(i);
  \&        }
  .Ve
! .IP "\fB\-Winvalid\-imported\-macros\fR" 4
  .IX Item "-Winvalid-imported-macros"
  Verify all imported macro definitions are valid at the end of
  compilation.  This is not enabled by default, as it requires
  additional processing to determine.  It may be useful when preparing
! sets of header-units to ensure consistent macros.
! .IP "\fB\-Wno\-literal\-suffix\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-literal-suffix ( and Objective- only)"
  Do not warn when a string or character literal is followed by a
! ud-suffix which does not begin with an underscore.  As a conforming
! extension, \s-1GCC\s0 treats such suffixes as separate preprocessing tokens
  in order to maintain backwards compatibility with code that uses
  formatting macros from \f(CW\*(C`\*(C'\fR.  For example:
  .Sp
--- 3781,3797 ----
  \&          f(i);
  \&        }
  .Ve
! .IP \fB\-Winvalid\-imported\-macros\fR 4
  .IX Item "-Winvalid-imported-macros"
  Verify all imported macro definitions are valid at the end of
  compilation.  This is not enabled by default, as it requires
  additional processing to determine.  It may be useful when preparing
! sets of header\-units to ensure consistent macros.
! .IP "\fB\-Wno\-literal\-suffix\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-literal-suffix (C++ and Objective-C++ only)"
  Do not warn when a string or character literal is followed by a
! ud\-suffix which does not begin with an underscore.  As a conforming
! extension, GCC treats such suffixes as separate preprocessing tokens
  in order to maintain backwards compatibility with code that uses
  formatting macros from \f(CW\*(C`\*(C'\fR.  For example:
  .Sp
*************** formatting macros from \f(CW\*(C`\*(C'\fR, but in
! \&\*(C+17 it calls \f(CW\*(C`f\*(C'\fR.
! .IP "\fB\-Wclass\-memaccess\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wclass-memaccess ( and Objective- only)"
  Warn when the destination of a call to a raw memory function such as
  \&\f(CW\*(C`memset\*(C'\fR or \f(CW\*(C`memcpy\*(C'\fR is an object of class type, and when writing
! into such an object might bypass the class non-trivial or deleted constructor
! or copy assignment, violate const-correctness or encapsulation, or corrupt
  virtual table pointers.  Modifying the representation of such objects may
  violate invariants maintained by member functions of the class.  For example,
! the call to \f(CW\*(C`memset\*(C'\fR below is undefined because it modifies a non-trivial
  class object and is, therefore, diagnosed.  The safe way to either initialize
  or clear the storage of objects of such types is by using the appropriate
  constructor or assignment operator, if one is available.
--- 3852,3868 ----
  \&        void h() { f(g); }
  .Ve
  .Sp
! In C++14, \f(CW\*(C`f\*(C'\fR calls \f(CW\*(C`f\*(C'\fR, but in
! C++17 it calls \f(CW\*(C`f\*(C'\fR.
! .IP "\fB\-Wclass\-memaccess\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wclass-memaccess (C++ and Objective-C++ only)"
  Warn when the destination of a call to a raw memory function such as
  \&\f(CW\*(C`memset\*(C'\fR or \f(CW\*(C`memcpy\*(C'\fR is an object of class type, and when writing
! into such an object might bypass the class non\-trivial or deleted constructor
! or copy assignment, violate const\-correctness or encapsulation, or corrupt
  virtual table pointers.  Modifying the representation of such objects may
  violate invariants maintained by member functions of the class.  For example,
! the call to \f(CW\*(C`memset\*(C'\fR below is undefined because it modifies a non\-trivial
  class object and is, therefore, diagnosed.  The safe way to either initialize
  or clear the storage of objects of such types is by using the appropriate
  constructor or assignment operator, if one is available.
*************** The \fB\-Wclass\-memaccess\fR option is
*** 3947,3955 ****
  Explicitly casting the pointer to the class object to \f(CW\*(C`void *\*(C'\fR or
  to a type that can be safely accessed by the raw memory function suppresses
  the warning.
! .IP "\fB\-Wnon\-virtual\-dtor\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wnon-virtual-dtor ( and Objective- only)"
! Warn when a class has virtual functions and an accessible non-virtual
  destructor itself or in an accessible polymorphic base class, in which
  case it is possible but unsafe to delete an instance of a derived
  class through a pointer to the class itself or base class.  This
--- 3876,3884 ----
  Explicitly casting the pointer to the class object to \f(CW\*(C`void *\*(C'\fR or
  to a type that can be safely accessed by the raw memory function suppresses
  the warning.
! .IP "\fB\-Wnon\-virtual\-dtor\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wnon-virtual-dtor (C++ and Objective-C++ only)"
! Warn when a class has virtual functions and an accessible non\-virtual
  destructor itself or in an accessible polymorphic base class, in which
  case it is possible but unsafe to delete an instance of a derived
  class through a pointer to the class itself or base class.  This
*************** warning is automatically enabled if \fB\
*** 3957,3971 ****
  The \fB\-Wdelete\-non\-virtual\-dtor\fR option (enabled by \fB\-Wall\fR)
  should be preferred because it warns about the unsafe cases without false
  positives.
! .IP "\fB\-Wregister\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wregister ( and Objective- only)"
  Warn on uses of the \f(CW\*(C`register\*(C'\fR storage class specifier, except
! when it is part of the \s-1GNU\s0 \fBExplicit Register Variables\fR extension.
  The use of the \f(CW\*(C`register\*(C'\fR keyword as storage class specifier has
! been deprecated in \*(C+11 and removed in \*(C+17.
  Enabled by default with \fB\-std=c++17\fR.
! .IP "\fB\-Wreorder\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wreorder ( and Objective- only)"
  Warn when the order of member initializers given in the code does not
  match the order in which they must be executed.  For instance:
  .Sp
--- 3886,3900 ----
  The \fB\-Wdelete\-non\-virtual\-dtor\fR option (enabled by \fB\-Wall\fR)
  should be preferred because it warns about the unsafe cases without false
  positives.
! .IP "\fB\-Wregister\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wregister (C++ and Objective-C++ only)"
  Warn on uses of the \f(CW\*(C`register\*(C'\fR storage class specifier, except
! when it is part of the GNU \fBExplicit Register Variables\fR extension.
  The use of the \f(CW\*(C`register\*(C'\fR keyword as storage class specifier has
! been deprecated in C++11 and removed in C++17.
  Enabled by default with \fB\-std=c++17\fR.
! .IP "\fB\-Wreorder\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-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:
  .Sp
*************** match the order in which they must be ex
*** 3980,3991 ****
  The compiler rearranges the member initializers for \f(CW\*(C`i\*(C'\fR
  and \f(CW\*(C`j\*(C'\fR to match the declaration order of the members, emitting
  a warning to that effect.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-pessimizing\-move\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-pessimizing-move ( and Objective- only)"
  This warning warns when a call to \f(CW\*(C`std::move\*(C'\fR prevents copy
  elision.  A typical scenario when copy elision can occur is when returning in
  a function with a class return type, when the expression being returned is the
! name of a non-volatile automatic object, and is not a function parameter, and
  has the same type as the function return type.
  .Sp
  .Vb 9
--- 3909,3920 ----
  The compiler rearranges the member initializers for \f(CW\*(C`i\*(C'\fR
  and \f(CW\*(C`j\*(C'\fR to match the declaration order of the members, emitting
  a warning to that effect.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-pessimizing\-move\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-pessimizing-move (C++ and Objective-C++ only)"
  This warning warns when a call to \f(CW\*(C`std::move\*(C'\fR prevents copy
  elision.  A typical scenario when copy elision can occur is when returning in
  a function with a class return type, when the expression being returned is the
! name of a non\-volatile automatic object, and is not a function parameter, and
  has the same type as the function return type.
  .Sp
  .Vb 9
*************** has the same type as the function return
*** 4003,4015 ****
  But in this example, the \f(CW\*(C`std::move\*(C'\fR call prevents copy elision.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-redundant\-move\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-redundant-move ( and Objective- only)"
  This warning warns about redundant calls to \f(CW\*(C`std::move\*(C'\fR; that is, when
  a move operation would have been performed even without the \f(CW\*(C`std::move\*(C'\fR
  call.  This happens because the compiler is forced to treat the object as if
  it were an rvalue in certain situations such as returning a local variable,
! where copy elision isn't applicable.  Consider:
  .Sp
  .Vb 8
  \&        struct T {
--- 3932,3944 ----
  But in this example, the \f(CW\*(C`std::move\*(C'\fR call prevents copy elision.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-redundant\-move\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-redundant-move (C++ and Objective-C++ only)"
  This warning warns about redundant calls to \f(CW\*(C`std::move\*(C'\fR; that is, when
  a move operation would have been performed even without the \f(CW\*(C`std::move\*(C'\fR
  call.  This happens because the compiler is forced to treat the object as if
  it were an rvalue in certain situations such as returning a local variable,
! where copy elision isn\*(Aqt applicable.  Consider:
  .Sp
  .Vb 8
  \&        struct T {
*************** Issue 1579, another example is:
*** 4040,4053 ****
  \&        }
  .Ve
  .Sp
! In this example, copy elision isn't applicable because the type of the
  expression being returned and the function return type differ, yet G++
  treats the return value as if it were designated by an rvalue.
  .Sp
  This warning is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wrange\-loop\-construct\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wrange-loop-construct ( and Objective- only)"
! This warning warns when a \*(C+ range-based for-loop is creating an unnecessary
  copy.  This can happen when the range declaration is not a reference, but
  probably should be.  For example:
  .Sp
--- 3969,3982 ----
  \&        }
  .Ve
  .Sp
! In this example, copy elision isn\*(Aqt applicable because the type of the
  expression being returned and the function return type differ, yet G++
  treats the return value as if it were designated by an rvalue.
  .Sp
  This warning is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wrange\-loop\-construct\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wrange-loop-construct (C++ and Objective-C++ only)"
! This warning warns when a C++ range\-based for\-loop is creating an unnecessary
  copy.  This can happen when the range declaration is not a reference, but
  probably should be.  For example:
  .Sp
*************** probably should be.  For example:
*** 4059,4068 ****
  \&        }
  .Ve
  .Sp
! It does not warn when the type being copied is a trivially-copyable type whose
  size is less than 64 bytes.
  .Sp
! This warning also warns when a loop variable in a range-based for-loop is
  initialized with a value of a different type resulting in a copy.  For example:
  .Sp
  .Vb 4
--- 3988,3997 ----
  \&        }
  .Ve
  .Sp
! It does not warn when the type being copied is a trivially\-copyable type whose
  size is less than 64 bytes.
  .Sp
! This warning also warns when a loop variable in a range\-based for\-loop is
  initialized with a value of a different type resulting in a copy.  For example:
  .Sp
  .Vb 4
*************** type \f(CW\*(C`double\*(C'\fR is created
*** 4077,4085 ****
  \&\f(CW\*(C`const double &\*(C'\fR is bound.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wredundant\-tags\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wredundant-tags ( and Objective- only)"
! Warn about redundant class-key and enum-key in references to class types
  and enumerated types in contexts where the key can be eliminated without
  causing an ambiguity.  For example:
  .Sp
--- 4006,4014 ----
  \&\f(CW\*(C`const double &\*(C'\fR is bound.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wredundant\-tags\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wredundant-tags (C++ and Objective-C++ only)"
! Warn about redundant class\-key and enum\-key in references to class types
  and enumerated types in contexts where the key can be eliminated without
  causing an ambiguity.  For example:
  .Sp
*************** On the other hand, in this example there
*** 4095,4174 ****
  \&        void foo ();   // "hides" struct foo
  \&        void bar (struct foo&);  // no warning, keyword struct is necessary
  .Ve
! .IP "\fB\-Wno\-subobject\-linkage\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-subobject-linkage ( and Objective- only)"
  Do not warn
  if a class type has a base or a field whose type uses the anonymous
  namespace or depends on a type with no linkage.  If a type A depends on
  a type B with no or internal linkage, defining it in multiple
! translation units would be an \s-1ODR\s0 violation because the meaning of B
  is different in each translation unit.  If A only appears in a single
  translation unit, the best way to silence the warning is to give it
  internal linkage by putting it in an anonymous namespace as well.  The
! compiler doesn't give this warning for types defined in the main .C
  file, as those are unlikely to have multiple definitions.
  \&\fB\-Wsubobject\-linkage\fR is enabled by default.
! .IP "\fB\-Weffc++\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Weffc++ ( and Objective- only)"
! Warn about violations of the following style guidelines from Scott Meyers'
! \&\fIEffective \*(C+\fR series of books:
  .RS 4
! .IP "*" 4
  Define a copy constructor and an assignment operator for classes
! with dynamically-allocated memory.
! .IP "*" 4
  Prefer initialization to assignment in constructors.
! .IP "*" 4
  Have \f(CW\*(C`operator=\*(C'\fR return a reference to \f(CW*this\fR.
! .IP "*" 4
! Don't try to return a reference when you must return an object.
! .IP "*" 4
  Distinguish between prefix and postfix forms of increment and
  decrement operators.
! .IP "*" 4
  Never overload \f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, or \f(CW\*(C`,\*(C'\fR.
  .RE
  .RS 4
  .Sp
  This option also enables \fB\-Wnon\-virtual\-dtor\fR, which is also
! one of the effective \*(C+ recommendations.  However, the check is
  extended to warn about the lack of virtual destructor in accessible
! non-polymorphic bases classes too.
  .Sp
  When selecting this option, be aware that the standard library
  headers do not obey all of these guidelines; use \fBgrep \-v\fR
  to filter out those warnings.
  .RE
! .IP "\fB\-Wno\-exceptions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-exceptions ( and Objective- only)"
  Disable the warning about the case when an exception handler is shadowed by
  another handler, which can point out a wrong ordering of exception handlers.
! .IP "\fB\-Wstrict\-null\-sentinel\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wstrict-null-sentinel ( and Objective- only)"
  Warn about the use of an uncasted \f(CW\*(C`NULL\*(C'\fR as sentinel.  When
! compiling only with \s-1GCC\s0 this is a valid sentinel, as \f(CW\*(C`NULL\*(C'\fR is defined
  to \f(CW\*(C`_\|_null\*(C'\fR.  Although it is a null pointer constant rather than a
  null pointer, it is guaranteed to be of the same size as a pointer.
  But this use is not portable across different compilers.
! .IP "\fB\-Wno\-non\-template\-friend\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-non-template-friend ( and Objective- only)"
! Disable warnings when non-template friend functions are declared
! within a template.  In very old versions of \s-1GCC\s0 that predate implementation
! of the \s-1ISO\s0 standard, declarations such as 
! \&\fBfriend int foo(int)\fR, where the name of the friend is an unqualified-id,
  could be interpreted as a particular specialization of a template
  function; the warning exists to diagnose compatibility problems, 
  and is enabled by default.
! .IP "\fB\-Wold\-style\-cast\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wold-style-cast ( and Objective- only)"
! Warn if an old-style (C\-style) cast to a non-void type is used within
! a \*(C+ program.  The new-style casts (\f(CW\*(C`dynamic_cast\*(C'\fR,
  \&\f(CW\*(C`static_cast\*(C'\fR, \f(CW\*(C`reinterpret_cast\*(C'\fR, and \f(CW\*(C`const_cast\*(C'\fR) are
  less vulnerable to unintended effects and much easier to search for.
! .IP "\fB\-Woverloaded\-virtual\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Woverloaded-virtual ( and Objective- only)"
  .PD 0
! .IP "\fB\-Woverloaded\-virtual=\fR\fIn\fR" 4
  .IX Item "-Woverloaded-virtual=n"
  .PD
  Warn when a function declaration hides virtual functions from a
--- 4024,4103 ----
  \&        void foo ();   // "hides" struct foo
  \&        void bar (struct foo&);  // no warning, keyword struct is necessary
  .Ve
! .IP "\fB\-Wno\-subobject\-linkage\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-subobject-linkage (C++ and Objective-C++ only)"
  Do not warn
  if a class type has a base or a field whose type uses the anonymous
  namespace or depends on a type with no linkage.  If a type A depends on
  a type B with no or internal linkage, defining it in multiple
! translation units would be an ODR violation because the meaning of B
  is different in each translation unit.  If A only appears in a single
  translation unit, the best way to silence the warning is to give it
  internal linkage by putting it in an anonymous namespace as well.  The
! compiler doesn\*(Aqt give this warning for types defined in the main .C
  file, as those are unlikely to have multiple definitions.
  \&\fB\-Wsubobject\-linkage\fR is enabled by default.
! .IP "\fB\-Weffc++\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Weffc++ (C++ and Objective-C++ only)"
! Warn about violations of the following style guidelines from Scott Meyers\*(Aq
! \&\fIEffective C++\fR series of books:
  .RS 4
! .IP * 4
  Define a copy constructor and an assignment operator for classes
! with dynamically\-allocated memory.
! .IP * 4
  Prefer initialization to assignment in constructors.
! .IP * 4
  Have \f(CW\*(C`operator=\*(C'\fR return a reference to \f(CW*this\fR.
! .IP * 4
! Don\*(Aqt try to return a reference when you must return an object.
! .IP * 4
  Distinguish between prefix and postfix forms of increment and
  decrement operators.
! .IP * 4
  Never overload \f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, or \f(CW\*(C`,\*(C'\fR.
  .RE
  .RS 4
  .Sp
  This option also enables \fB\-Wnon\-virtual\-dtor\fR, which is also
! one of the effective C++ recommendations.  However, the check is
  extended to warn about the lack of virtual destructor in accessible
! non\-polymorphic bases classes too.
  .Sp
  When selecting this option, be aware that the standard library
  headers do not obey all of these guidelines; use \fBgrep \-v\fR
  to filter out those warnings.
  .RE
! .IP "\fB\-Wno\-exceptions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-exceptions (C++ and Objective-C++ only)"
  Disable the warning about the case when an exception handler is shadowed by
  another handler, which can point out a wrong ordering of exception handlers.
! .IP "\fB\-Wstrict\-null\-sentinel\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wstrict-null-sentinel (C++ and Objective-C++ only)"
  Warn about the use of an uncasted \f(CW\*(C`NULL\*(C'\fR as sentinel.  When
! compiling only with GCC this is a valid sentinel, as \f(CW\*(C`NULL\*(C'\fR is defined
  to \f(CW\*(C`_\|_null\*(C'\fR.  Although it is a null pointer constant rather than a
  null pointer, it is guaranteed to be of the same size as a pointer.
  But this use is not portable across different compilers.
! .IP "\fB\-Wno\-non\-template\-friend\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-non-template-friend (C++ and Objective-C++ only)"
! Disable warnings when non\-template friend functions are declared
! within a template.  In very old versions of GCC that predate implementation
! of the ISO standard, declarations such as 
! \&\fBfriend int foo(int)\fR, where the name of the friend is an unqualified\-id,
  could be interpreted as a particular specialization of a template
  function; the warning exists to diagnose compatibility problems, 
  and is enabled by default.
! .IP "\fB\-Wold\-style\-cast\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-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 (\f(CW\*(C`dynamic_cast\*(C'\fR,
  \&\f(CW\*(C`static_cast\*(C'\fR, \f(CW\*(C`reinterpret_cast\*(C'\fR, and \f(CW\*(C`const_cast\*(C'\fR) are
  less vulnerable to unintended effects and much easier to search for.
! .IP "\fB\-Woverloaded\-virtual\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Woverloaded-virtual (C++ and Objective-C++ only)"
  .PD 0
! .IP \fB\-Woverloaded\-virtual=\fR\fIn\fR 4
  .IX Item "-Woverloaded-virtual=n"
  .PD
  Warn when a function declaration hides virtual functions from a
*************** like:
*** 4195,4202 ****
  fails to compile.
  .Sp
  In cases where the different signatures are not an accident, the
! simplest solution is to add a using-declaration to the derived class
! to un-hide the base function, e.g. add \f(CW\*(C`using A::f;\*(C'\fR to \f(CW\*(C`B\*(C'\fR.
  .Sp
  The optional level suffix controls the behavior when all the
  declarations in the derived class override virtual functions in the
--- 4124,4131 ----
  fails to compile.
  .Sp
  In cases where the different signatures are not an accident, the
! simplest solution is to add a using\-declaration to the derived class
! to un\-hide the base function, e.g. add \f(CW\*(C`using A::f;\*(C'\fR to \f(CW\*(C`B\*(C'\fR.
  .Sp
  The optional level suffix controls the behavior when all the
  declarations in the derived class override virtual functions in the
*************** for some of the overloads are fine.
*** 4220,4255 ****
  At level 1, this case does not warn; at level 2, it does.
  \&\fB\-Woverloaded\-virtual\fR by itself selects level 2.  Level 1 is
  included in \fB\-Wall\fR.
! .IP "\fB\-Wno\-pmf\-conversions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-pmf-conversions ( and Objective- only)"
  Disable the diagnostic for converting a bound pointer to member function
  to a plain pointer.
! .IP "\fB\-Wsign\-promo\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wsign-promo ( and Objective- only)"
  Warn when overload resolution chooses a promotion from unsigned or
  enumerated type to a signed type, over a conversion to an unsigned type of
  the same size.  Previous versions of G++ tried to preserve
  unsignedness, but the standard mandates the current behavior.
! .IP "\fB\-Wtemplates\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wtemplates ( and Objective- only)"
  Warn when a primary template declaration is encountered.  Some coding
  rules disallow templates, and this may be used to enforce that rule.
! The warning is inactive inside a system header file, such as the \s-1STL,\s0 so
! one can still use the \s-1STL.\s0  One may also instantiate or specialize
  templates.
! .IP "\fB\-Wmismatched\-new\-delete\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wmismatched-new-delete ( and Objective- only)"
  Warn for mismatches between calls to \f(CW\*(C`operator new\*(C'\fR or \f(CW\*(C`operator
  delete\*(C'\fR and the corresponding call to the allocation or deallocation function.
! This includes invocations of \*(C+ \f(CW\*(C`operator delete\*(C'\fR with pointers
  returned from either mismatched forms of \f(CW\*(C`operator new\*(C'\fR, or from other
! functions that allocate objects for which the \f(CW\*(C`operator delete\*(C'\fR isn't
  a suitable deallocator, as well as calls to other deallocation functions
  with pointers returned from \f(CW\*(C`operator new\*(C'\fR for which the deallocation
! function isn't suitable.
  .Sp
  For example, the \f(CW\*(C`delete\*(C'\fR expression in the function below is diagnosed
! because it doesn't match the array form of the \f(CW\*(C`new\*(C'\fR expression
  the pointer argument was returned from.  Similarly, the call to \f(CW\*(C`free\*(C'\fR
  is also diagnosed.
  .Sp
--- 4149,4184 ----
  At level 1, this case does not warn; at level 2, it does.
  \&\fB\-Woverloaded\-virtual\fR by itself selects level 2.  Level 1 is
  included in \fB\-Wall\fR.
! .IP "\fB\-Wno\-pmf\-conversions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-pmf-conversions (C++ and Objective-C++ only)"
  Disable the diagnostic for converting a bound pointer to member function
  to a plain pointer.
! .IP "\fB\-Wsign\-promo\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wsign-promo (C++ and Objective-C++ only)"
  Warn when overload resolution chooses a promotion from unsigned or
  enumerated type to a signed type, over a conversion to an unsigned type of
  the same size.  Previous versions of G++ tried to preserve
  unsignedness, but the standard mandates the current behavior.
! .IP "\fB\-Wtemplates\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wtemplates (C++ and Objective-C++ only)"
  Warn when a primary template declaration is encountered.  Some coding
  rules disallow templates, and this may be used to enforce that rule.
! The warning is inactive inside a system header file, such as the STL, so
! one can still use the STL.  One may also instantiate or specialize
  templates.
! .IP "\fB\-Wmismatched\-new\-delete\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wmismatched-new-delete (C++ and Objective-C++ only)"
  Warn for mismatches between calls to \f(CW\*(C`operator new\*(C'\fR or \f(CW\*(C`operator
  delete\*(C'\fR and the corresponding call to the allocation or deallocation function.
! This includes invocations of C++ \f(CW\*(C`operator delete\*(C'\fR with pointers
  returned from either mismatched forms of \f(CW\*(C`operator new\*(C'\fR, or from other
! functions that allocate objects for which the \f(CW\*(C`operator delete\*(C'\fR isn\*(Aqt
  a suitable deallocator, as well as calls to other deallocation functions
  with pointers returned from \f(CW\*(C`operator new\*(C'\fR for which the deallocation
! function isn\*(Aqt suitable.
  .Sp
  For example, the \f(CW\*(C`delete\*(C'\fR expression in the function below is diagnosed
! because it doesn\*(Aqt match the array form of the \f(CW\*(C`new\*(C'\fR expression
  the pointer argument was returned from.  Similarly, the call to \f(CW\*(C`free\*(C'\fR
  is also diagnosed.
  .Sp
*************** involving allocation and deallocation fu
*** 4269,4283 ****
  new\*(C'\fR and \f(CW\*(C`operator delete\*(C'\fR.
  .Sp
  \&\fB\-Wmismatched\-new\-delete\fR is included in \fB\-Wall\fR.
! .IP "\fB\-Wmismatched\-tags\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wmismatched-tags ( and Objective- only)"
  Warn for declarations of structs, classes, and class templates and their
! specializations with a class-key that does not match either the definition
  or the first declaration if no definition is provided.
  .Sp
  For example, the declaration of \f(CW\*(C`struct Object\*(C'\fR in the argument list
  of \f(CW\*(C`draw\*(C'\fR triggers the warning.  To avoid it, either remove the redundant
! class-key \f(CW\*(C`struct\*(C'\fR or replace it with \f(CW\*(C`class\*(C'\fR to match its definition.
  .Sp
  .Vb 5
  \&        class Object {
--- 4198,4212 ----
  new\*(C'\fR and \f(CW\*(C`operator delete\*(C'\fR.
  .Sp
  \&\fB\-Wmismatched\-new\-delete\fR is included in \fB\-Wall\fR.
! .IP "\fB\-Wmismatched\-tags\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wmismatched-tags (C++ and Objective-C++ only)"
  Warn for declarations of structs, classes, and class templates and their
! specializations with a class\-key that does not match either the definition
  or the first declaration if no definition is provided.
  .Sp
  For example, the declaration of \f(CW\*(C`struct Object\*(C'\fR in the argument list
  of \f(CW\*(C`draw\*(C'\fR triggers the warning.  To avoid it, either remove the redundant
! class\-key \f(CW\*(C`struct\*(C'\fR or replace it with \f(CW\*(C`class\*(C'\fR to match its definition.
  .Sp
  .Vb 5
  \&        class Object {
*************** class-key \f(CW\*(C`struct\*(C'\fR or re
*** 4287,4336 ****
  \&        void draw (struct Object*);
  .Ve
  .Sp
! It is not wrong to declare a class with the class-key \f(CW\*(C`struct\*(C'\fR as
  the example above shows.  The \fB\-Wmismatched\-tags\fR option is intended
  to help achieve a consistent style of class declarations.  In code that is
! intended to be portable to Windows-based compilers the warning helps prevent
  unresolved references due to the difference in the mangling of symbols
! declared with different class-keys.  The option can be used either on its
  own or in conjunction with \fB\-Wredundant\-tags\fR.
! .IP "\fB\-Wmultiple\-inheritance\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wmultiple-inheritance ( and Objective- only)"
  Warn when a class is defined with multiple direct base classes.  Some
  coding rules disallow multiple inheritance, and this may be used to
  enforce that rule.  The warning is inactive inside a system header file,
! such as the \s-1STL,\s0 so one can still use the \s-1STL.\s0  One may also define
  classes that indirectly use multiple inheritance.
! .IP "\fB\-Wvirtual\-inheritance\fR" 4
  .IX Item "-Wvirtual-inheritance"
  Warn when a class is defined with a virtual direct base class.  Some
  coding rules disallow multiple inheritance, and this may be used to
  enforce that rule.  The warning is inactive inside a system header file,
! such as the \s-1STL,\s0 so one can still use the \s-1STL.\s0  One may also define
  classes that indirectly use virtual inheritance.
! .IP "\fB\-Wno\-virtual\-move\-assign\fR" 4
  .IX Item "-Wno-virtual-move-assign"
  Suppress warnings about inheriting from a virtual base with a
! non-trivial \*(C+11 move assignment operator.  This is dangerous because
  if the virtual base is reachable along more than one path, it is
  moved multiple times, which can mean both objects end up in the
! moved-from state.  If the move assignment operator is written to avoid
! moving from a moved-from object, this warning can be disabled.
! .IP "\fB\-Wnamespaces\fR" 4
  .IX Item "-Wnamespaces"
  Warn when a namespace definition is opened.  Some coding rules disallow
  namespaces, and this may be used to enforce that rule.  The warning is
! inactive inside a system header file, such as the \s-1STL,\s0 so one can still
! use the \s-1STL.\s0  One may also use using directives and qualified names.
! .IP "\fB\-Wno\-terminate\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-terminate ( and Objective- only)"
! Disable the warning about a throw-expression that will immediately
  result in a call to \f(CW\*(C`terminate\*(C'\fR.
! .IP "\fB\-Wno\-vexing\-parse\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-vexing-parse ( and Objective- only)"
  Warn about the most vexing parse syntactic ambiguity.  This warns about
  the cases when a declaration looks like a variable definition, but the
! \&\*(C+ language requires it to be interpreted as a function declaration.
  For instance:
  .Sp
  .Vb 4
--- 4216,4265 ----
  \&        void draw (struct Object*);
  .Ve
  .Sp
! It is not wrong to declare a class with the class\-key \f(CW\*(C`struct\*(C'\fR as
  the example above shows.  The \fB\-Wmismatched\-tags\fR option is intended
  to help achieve a consistent style of class declarations.  In code that is
! intended to be portable to Windows\-based compilers the warning helps prevent
  unresolved references due to the difference in the mangling of symbols
! declared with different class\-keys.  The option can be used either on its
  own or in conjunction with \fB\-Wredundant\-tags\fR.
! .IP "\fB\-Wmultiple\-inheritance\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wmultiple-inheritance (C++ and Objective-C++ only)"
  Warn when a class is defined with multiple direct base classes.  Some
  coding rules disallow multiple inheritance, and this may be used to
  enforce that rule.  The warning is inactive inside a system header file,
! such as the STL, so one can still use the STL.  One may also define
  classes that indirectly use multiple inheritance.
! .IP \fB\-Wvirtual\-inheritance\fR 4
  .IX Item "-Wvirtual-inheritance"
  Warn when a class is defined with a virtual direct base class.  Some
  coding rules disallow multiple inheritance, and this may be used to
  enforce that rule.  The warning is inactive inside a system header file,
! such as the STL, so one can still use the STL.  One may also define
  classes that indirectly use virtual inheritance.
! .IP \fB\-Wno\-virtual\-move\-assign\fR 4
  .IX Item "-Wno-virtual-move-assign"
  Suppress warnings about inheriting from a virtual base with a
! non\-trivial C++11 move assignment operator.  This is dangerous because
  if the virtual base is reachable along more than one path, it is
  moved multiple times, which can mean both objects end up in the
! moved\-from state.  If the move assignment operator is written to avoid
! moving from a moved\-from object, this warning can be disabled.
! .IP \fB\-Wnamespaces\fR 4
  .IX Item "-Wnamespaces"
  Warn when a namespace definition is opened.  Some coding rules disallow
  namespaces, and this may be used to enforce that rule.  The warning is
! inactive inside a system header file, such as the STL, so one can still
! use the STL.  One may also use using directives and qualified names.
! .IP "\fB\-Wno\-terminate\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-terminate (C++ and Objective-C++ only)"
! Disable the warning about a throw\-expression that will immediately
  result in a call to \f(CW\*(C`terminate\*(C'\fR.
! .IP "\fB\-Wno\-vexing\-parse\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-vexing-parse (C++ and Objective-C++ only)"
  Warn about the most vexing parse syntactic ambiguity.  This warns about
  the cases when a declaration looks like a variable definition, but the
! C++ language requires it to be interpreted as a function declaration.
  For instance:
  .Sp
  .Vb 4
*************** The warning will suggest options how to
*** 4355,4395 ****
  it can suggest removing the parentheses or using braces instead.
  .Sp
  This warning is enabled by default.
! .IP "\fB\-Wno\-class\-conversion\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-class-conversion ( and Objective- only)"
  Do not warn when a conversion function converts an
  object to the same type, to a base class of that type, or to void; such
  a conversion function will never be called.
! .IP "\fB\-Wvolatile\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wvolatile ( and Objective- only)"
  Warn about deprecated uses of the \f(CW\*(C`volatile\*(C'\fR qualifier.  This includes
  postfix and prefix \f(CW\*(C`++\*(C'\fR and \f(CW\*(C`\-\-\*(C'\fR expressions of
  \&\f(CW\*(C`volatile\*(C'\fR\-qualified types, using simple assignments where the left
! operand is a \f(CW\*(C`volatile\*(C'\fR\-qualified non-class type for their value,
  compound assignments where the left operand is a \f(CW\*(C`volatile\*(C'\fR\-qualified
! non-class type, \f(CW\*(C`volatile\*(C'\fR\-qualified function return type,
  \&\f(CW\*(C`volatile\*(C'\fR\-qualified parameter type, and structured bindings of a
! \&\f(CW\*(C`volatile\*(C'\fR\-qualified type.  This usage was deprecated in \*(C+20.
  .Sp
  Enabled by default with \fB\-std=c++20\fR.
! .IP "\fB\-Wzero\-as\-null\-pointer\-constant\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wzero-as-null-pointer-constant ( and Objective- only)"
  Warn when a literal \fB0\fR is used as null pointer constant.  This can
! be useful to facilitate the conversion to \f(CW\*(C`nullptr\*(C'\fR in \*(C+11.
! .IP "\fB\-Waligned\-new\fR" 4
  .IX Item "-Waligned-new"
! Warn about a new-expression of a type that requires greater alignment
! than the \f(CW\*(C`alignof(std::max_align_t)\*(C'\fR but uses an allocation
  function without an explicit alignment parameter. This option is
  enabled by \fB\-Wall\fR.
  .Sp
  Normally this only warns about global allocation functions, but
  \&\fB\-Waligned\-new=all\fR also warns about class member allocation
  functions.
! .IP "\fB\-Wno\-placement\-new\fR" 4
  .IX Item "-Wno-placement-new"
  .PD 0
! .IP "\fB\-Wplacement\-new=\fR\fIn\fR" 4
  .IX Item "-Wplacement-new=n"
  .PD
  Warn about placement new expressions with undefined behavior, such as
--- 4284,4324 ----
  it can suggest removing the parentheses or using braces instead.
  .Sp
  This warning is enabled by default.
! .IP "\fB\-Wno\-class\-conversion\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-class-conversion (C++ and Objective-C++ only)"
  Do not warn when a conversion function converts an
  object to the same type, to a base class of that type, or to void; such
  a conversion function will never be called.
! .IP "\fB\-Wvolatile\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wvolatile (C++ and Objective-C++ only)"
  Warn about deprecated uses of the \f(CW\*(C`volatile\*(C'\fR qualifier.  This includes
  postfix and prefix \f(CW\*(C`++\*(C'\fR and \f(CW\*(C`\-\-\*(C'\fR expressions of
  \&\f(CW\*(C`volatile\*(C'\fR\-qualified types, using simple assignments where the left
! operand is a \f(CW\*(C`volatile\*(C'\fR\-qualified non\-class type for their value,
  compound assignments where the left operand is a \f(CW\*(C`volatile\*(C'\fR\-qualified
! non\-class type, \f(CW\*(C`volatile\*(C'\fR\-qualified function return type,
  \&\f(CW\*(C`volatile\*(C'\fR\-qualified parameter type, and structured bindings of a
! \&\f(CW\*(C`volatile\*(C'\fR\-qualified type.  This usage was deprecated in C++20.
  .Sp
  Enabled by default with \fB\-std=c++20\fR.
! .IP "\fB\-Wzero\-as\-null\-pointer\-constant\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wzero-as-null-pointer-constant (C++ and Objective-C++ only)"
  Warn when a literal \fB0\fR is used as null pointer constant.  This can
! be useful to facilitate the conversion to \f(CW\*(C`nullptr\*(C'\fR in C++11.
! .IP \fB\-Waligned\-new\fR 4
  .IX Item "-Waligned-new"
! Warn about a new\-expression of a type that requires greater alignment
! than the \f(CWalignof(std::max_align_t)\fR but uses an allocation
  function without an explicit alignment parameter. This option is
  enabled by \fB\-Wall\fR.
  .Sp
  Normally this only warns about global allocation functions, but
  \&\fB\-Waligned\-new=all\fR also warns about class member allocation
  functions.
! .IP \fB\-Wno\-placement\-new\fR 4
  .IX Item "-Wno-placement-new"
  .PD 0
! .IP \fB\-Wplacement\-new=\fR\fIn\fR 4
  .IX Item "-Wplacement-new=n"
  .PD
  Warn about placement new expressions with undefined behavior, such as
*************** because it attempts to construct an arra
*** 4405,4425 ****
  .Sp
  This warning is enabled by default.
  .RS 4
! .IP "\fB\-Wplacement\-new=1\fR" 4
  .IX Item "-Wplacement-new=1"
  This is the default warning level of \fB\-Wplacement\-new\fR.  At this
  level the warning is not issued for some strictly undefined constructs that
! \&\s-1GCC\s0 allows as extensions for compatibility with legacy code.  For example,
  the following \f(CW\*(C`new\*(C'\fR expression is not diagnosed at this level even
! though it has undefined behavior according to the \*(C+ standard because
! it writes past the end of the one-element array.
  .Sp
  .Vb 3
  \&        struct S { int n, a[1]; };
  \&        S *s = (S *)malloc (sizeof *s + 31 * sizeof s\->a[0]);
  \&        new (s\->a)int [32]();
  .Ve
! .IP "\fB\-Wplacement\-new=2\fR" 4
  .IX Item "-Wplacement-new=2"
  At this level, in addition to diagnosing all the same constructs as at level
  1, a diagnostic is also issued for placement new expressions that construct
--- 4334,4354 ----
  .Sp
  This warning is enabled by default.
  .RS 4
! .IP \fB\-Wplacement\-new=1\fR 4
  .IX Item "-Wplacement-new=1"
  This is the default warning level of \fB\-Wplacement\-new\fR.  At this
  level the warning is not issued for some strictly undefined constructs that
! GCC allows as extensions for compatibility with legacy code.  For example,
  the following \f(CW\*(C`new\*(C'\fR expression is not diagnosed at this level even
! though it has undefined behavior according to the C++ standard because
! it writes past the end of the one\-element array.
  .Sp
  .Vb 3
  \&        struct S { int n, a[1]; };
  \&        S *s = (S *)malloc (sizeof *s + 31 * sizeof s\->a[0]);
  \&        new (s\->a)int [32]();
  .Ve
! .IP \fB\-Wplacement\-new=2\fR 4
  .IX Item "-Wplacement-new=2"
  At this level, in addition to diagnosing all the same constructs as at level
  1, a diagnostic is also issued for placement new expressions that construct
*************** use of the flexible member array extensi
*** 4436,4446 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wcatch\-value\fR" 4
  .IX Item "-Wcatch-value"
  .PD 0
! .IP "\fB\-Wcatch\-value=\fR\fIn\fR\fB \fR(\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wcatch-value=n ( and Objective- only)"
  .PD
  Warn about catch handlers that do not catch via reference.
  With \fB\-Wcatch\-value=1\fR (or \fB\-Wcatch\-value\fR for short)
--- 4365,4375 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wcatch\-value\fR 4
  .IX Item "-Wcatch-value"
  .PD 0
! .IP "\fB\-Wcatch\-value=\fR\fIn\fR\fB \fR(C++ and Objective\-C++ only)" 4
! .IX Item "-Wcatch-value=n (C++ and Objective-C++ only)"
  .PD
  Warn about catch handlers that do not catch via reference.
  With \fB\-Wcatch\-value=1\fR (or \fB\-Wcatch\-value\fR for short)
*************** warn about polymorphic class types that
*** 4448,4465 ****
  With \fB\-Wcatch\-value=2\fR warn about all class types that are caught
  by value. With \fB\-Wcatch\-value=3\fR warn about all types that are
  not caught by reference. \fB\-Wcatch\-value\fR is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wconditionally\-supported\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wconditionally-supported ( and Objective- only)"
! Warn for conditionally-supported (\*(C+11 [intro.defs]) constructs.
! .IP "\fB\-Wno\-delete\-incomplete\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-delete-incomplete ( and Objective- only)"
  Do not warn when deleting a pointer to incomplete type, which may cause
  undefined behavior at runtime.  This warning is enabled by default.
! .IP "\fB\-Wextra\-semi\fR (\*(C+, Objective\-\*(C+ only)" 4
! .IX Item "-Wextra-semi (, Objective- only)"
! Warn about redundant semicolons after in-class function definitions.
! .IP "\fB\-Wno\-inaccessible\-base\fR (\*(C+, Objective\-\*(C+ only)" 4
! .IX Item "-Wno-inaccessible-base (, Objective- only)"
  This option controls warnings
  when a base class is inaccessible in a class derived from it due to
  ambiguity.  The warning is enabled by default.
--- 4377,4394 ----
  With \fB\-Wcatch\-value=2\fR warn about all class types that are caught
  by value. With \fB\-Wcatch\-value=3\fR warn about all types that are
  not caught by reference. \fB\-Wcatch\-value\fR is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wconditionally\-supported\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wconditionally-supported (C++ and Objective-C++ only)"
! Warn for conditionally\-supported (C++11 [intro.defs]) constructs.
! .IP "\fB\-Wno\-delete\-incomplete\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-delete-incomplete (C++ and Objective-C++ only)"
  Do not warn when deleting a pointer to incomplete type, which may cause
  undefined behavior at runtime.  This warning is enabled by default.
! .IP "\fB\-Wextra\-semi\fR (C++, Objective\-C++ only)" 4
! .IX Item "-Wextra-semi (C++, Objective-C++ only)"
! Warn about redundant semicolons after in\-class function definitions.
! .IP "\fB\-Wno\-inaccessible\-base\fR (C++, Objective\-C++ only)" 4
! .IX Item "-Wno-inaccessible-base (C++, Objective-C++ only)"
  This option controls warnings
  when a base class is inaccessible in a class derived from it due to
  ambiguity.  The warning is enabled by default.
*************** bases is enabled by the \fB\-Wextra\fR o
*** 4473,4497 ****
  \&        
  \&        struct C : B, A { };
  .Ve
! .IP "\fB\-Wno\-inherited\-variadic\-ctor\fR" 4
  .IX Item "-Wno-inherited-variadic-ctor"
! Suppress warnings about use of \*(C+11 inheriting constructors when the
  base class inherited from has a C variadic constructor; the warning is
  on by default because the ellipsis is not inherited.
! .IP "\fB\-Wno\-invalid\-offsetof\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-invalid-offsetof ( and Objective- only)"
! Suppress warnings from applying the \f(CW\*(C`offsetof\*(C'\fR macro to a non-POD
! type.  According to the 2014 \s-1ISO \*(C+\s0 standard, applying \f(CW\*(C`offsetof\*(C'\fR
! to a non-standard-layout type is undefined.  In existing \*(C+ implementations,
  however, \f(CW\*(C`offsetof\*(C'\fR typically gives meaningful results.
  This flag is for users who are aware that they are
  writing nonportable code and who have deliberately chosen to ignore the
  warning about it.
  .Sp
  The restrictions on \f(CW\*(C`offsetof\*(C'\fR may be relaxed in a future version
! of the \*(C+ standard.
! .IP "\fB\-Wsized\-deallocation\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wsized-deallocation ( and Objective- only)"
  Warn about a definition of an unsized deallocation function
  .Sp
  .Vb 2
--- 4402,4426 ----
  \&        
  \&        struct C : B, A { };
  .Ve
! .IP \fB\-Wno\-inherited\-variadic\-ctor\fR 4
  .IX Item "-Wno-inherited-variadic-ctor"
! Suppress warnings about use of C++11 inheriting constructors when the
  base class inherited from has a C variadic constructor; the warning is
  on by default because the ellipsis is not inherited.
! .IP "\fB\-Wno\-invalid\-offsetof\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-invalid-offsetof (C++ and Objective-C++ only)"
! Suppress warnings from applying the \f(CW\*(C`offsetof\*(C'\fR macro to a non\-POD
! type.  According to the 2014 ISO C++ standard, applying \f(CW\*(C`offsetof\*(C'\fR
! to a non\-standard\-layout type is undefined.  In existing C++ implementations,
  however, \f(CW\*(C`offsetof\*(C'\fR typically gives meaningful results.
  This flag is for users who are aware that they are
  writing nonportable code and who have deliberately chosen to ignore the
  warning about it.
  .Sp
  The restrictions on \f(CW\*(C`offsetof\*(C'\fR may be relaxed in a future version
! of the C++ standard.
! .IP "\fB\-Wsized\-deallocation\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wsized-deallocation (C++ and Objective-C++ only)"
  Warn about a definition of an unsized deallocation function
  .Sp
  .Vb 2
*************** without a definition of the correspondin
*** 4508,4542 ****
  .Sp
  or vice versa.  Enabled by \fB\-Wextra\fR along with
  \&\fB\-fsized\-deallocation\fR.
! .IP "\fB\-Wsuggest\-final\-types\fR" 4
  .IX Item "-Wsuggest-final-types"
  Warn about types with virtual methods where code quality would be improved
! if the type were declared with the \*(C+11 \f(CW\*(C`final\*(C'\fR specifier,
  or, if possible,
! declared in an anonymous namespace. This allows \s-1GCC\s0 to more aggressively
  devirtualize the polymorphic calls. This warning is more effective with
! link-time optimization,
  where the information about the class hierarchy graph is
  more complete.
! .IP "\fB\-Wsuggest\-final\-methods\fR" 4
  .IX Item "-Wsuggest-final-methods"
  Warn about virtual methods where code quality would be improved if the method
! were declared with the \*(C+11 \f(CW\*(C`final\*(C'\fR specifier,
  or, if possible, its type were
  declared in an anonymous namespace or with the \f(CW\*(C`final\*(C'\fR specifier.
  This warning is
! more effective with link-time optimization, where the information about the
  class hierarchy graph is more complete. It is recommended to first consider
  suggestions of \fB\-Wsuggest\-final\-types\fR and then rebuild with new
  annotations.
! .IP "\fB\-Wsuggest\-override\fR" 4
  .IX Item "-Wsuggest-override"
  Warn about overriding virtual functions that are not marked with the
  \&\f(CW\*(C`override\*(C'\fR keyword.
! .IP "\fB\-Wuse\-after\-free\fR" 4
  .IX Item "-Wuse-after-free"
  .PD 0
! .IP "\fB\-Wuse\-after\-free=\fR\fIn\fR" 4
  .IX Item "-Wuse-after-free=n"
  .PD
  Warn about uses of pointers to dynamically allocated objects that have
--- 4437,4471 ----
  .Sp
  or vice versa.  Enabled by \fB\-Wextra\fR along with
  \&\fB\-fsized\-deallocation\fR.
! .IP \fB\-Wsuggest\-final\-types\fR 4
  .IX Item "-Wsuggest-final-types"
  Warn about types with virtual methods where code quality would be improved
! if the type were declared with the C++11 \f(CW\*(C`final\*(C'\fR specifier,
  or, if possible,
! declared in an anonymous namespace. This allows GCC to more aggressively
  devirtualize the polymorphic calls. This warning is more effective with
! link\-time optimization,
  where the information about the class hierarchy graph is
  more complete.
! .IP \fB\-Wsuggest\-final\-methods\fR 4
  .IX Item "-Wsuggest-final-methods"
  Warn about virtual methods where code quality would be improved if the method
! were declared with the C++11 \f(CW\*(C`final\*(C'\fR specifier,
  or, if possible, its type were
  declared in an anonymous namespace or with the \f(CW\*(C`final\*(C'\fR specifier.
  This warning is
! more effective with link\-time optimization, where the information about the
  class hierarchy graph is more complete. It is recommended to first consider
  suggestions of \fB\-Wsuggest\-final\-types\fR and then rebuild with new
  annotations.
! .IP \fB\-Wsuggest\-override\fR 4
  .IX Item "-Wsuggest-override"
  Warn about overriding virtual functions that are not marked with the
  \&\f(CW\*(C`override\*(C'\fR keyword.
! .IP \fB\-Wuse\-after\-free\fR 4
  .IX Item "-Wuse-after-free"
  .PD 0
! .IP \fB\-Wuse\-after\-free=\fR\fIn\fR 4
  .IX Item "-Wuse-after-free=n"
  .PD
  Warn about uses of pointers to dynamically allocated objects that have
*************** been rendered indeterminate by a call to
*** 4544,4550 ****
  The warning is enabled at all optimization levels but may yield different
  results with optimization than without.
  .RS 4
! .IP "\fB\-Wuse\-after\-free=1\fR" 4
  .IX Item "-Wuse-after-free=1"
  At level 1 the warning attempts to diagnose only unconditional uses
  of pointers made indeterminate by a deallocation call or a successful
--- 4473,4479 ----
  The warning is enabled at all optimization levels but may yield different
  results with optimization than without.
  .RS 4
! .IP \fB\-Wuse\-after\-free=1\fR 4
  .IX Item "-Wuse-after-free=1"
  At level 1 the warning attempts to diagnose only unconditional uses
  of pointers made indeterminate by a deallocation call or a successful
*************** in an actual reallocatio of memory.  Thi
*** 4553,4559 ****
  calls as well as uses in arithmetic and relational expressions.  Although
  undefined, uses of indeterminate pointers in equality (or inequality)
  expressions are not diagnosed at this level.
! .IP "\fB\-Wuse\-after\-free=2\fR" 4
  .IX Item "-Wuse-after-free=2"
  At level 2, in addition to unconditional uses, the warning also diagnoses
  conditional uses of pointers made indeterminate by a deallocation call.
--- 4482,4488 ----
  calls as well as uses in arithmetic and relational expressions.  Although
  undefined, uses of indeterminate pointers in equality (or inequality)
  expressions are not diagnosed at this level.
! .IP \fB\-Wuse\-after\-free=2\fR 4
  .IX Item "-Wuse-after-free=2"
  At level 2, in addition to unconditional uses, the warning also diagnoses
  conditional uses of pointers made indeterminate by a deallocation call.
*************** function is diagnosed at this level:
*** 4572,4578 ****
  \&            free (p\->data);   // warning: p may be used after free
  \&        }
  .Ve
! .IP "\fB\-Wuse\-after\-free=3\fR" 4
  .IX Item "-Wuse-after-free=3"
  At level 3, the warning also diagnoses uses of indeterminate pointers in
  equality expressions.  All uses of indeterminate pointers are undefined
--- 4501,4507 ----
  \&            free (p\->data);   // warning: p may be used after free
  \&        }
  .Ve
! .IP \fB\-Wuse\-after\-free=3\fR 4
  .IX Item "-Wuse-after-free=3"
  At level 3, the warning also diagnoses uses of indeterminate pointers in
  equality expressions.  All uses of indeterminate pointers are undefined
*************** pointers after reallocation.
*** 4602,4611 ****
  .Sp
  \&\fB\-Wuse\-after\-free=2\fR is included in \fB\-Wall\fR.
  .RE
! .IP "\fB\-Wuseless\-cast\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wuseless-cast ( and Objective- only)"
  Warn when an expression is cast to its own type.  This warning does not
! occur when a class object is converted to a non-reference type as that
  is a way to create a temporary:
  .Sp
  .Vb 6
--- 4531,4540 ----
  .Sp
  \&\fB\-Wuse\-after\-free=2\fR is included in \fB\-Wall\fR.
  .RE
! .IP "\fB\-Wuseless\-cast\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wuseless-cast (C++ and Objective-C++ only)"
  Warn when an expression is cast to its own type.  This warning does not
! occur when a class object is converted to a non\-reference type as that
  is a way to create a temporary:
  .Sp
  .Vb 6
*************** is a way to create a temporary:
*** 4616,4633 ****
  \&          g (S(arg)); // make arg prvalue so that it can bind to S&&
  \&        }
  .Ve
! .IP "\fB\-Wno\-conversion\-null\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-conversion-null ( and Objective- only)"
! Do not warn for conversions between \f(CW\*(C`NULL\*(C'\fR and non-pointer
  types. \fB\-Wconversion\-null\fR is enabled by default.
! .SS "Options Controlling Objective-C and Objective\-\*(C+ Dialects"
! .IX Subsection "Options Controlling Objective-C and Objective- Dialects"
! (\s-1NOTE:\s0 This manual does not describe the Objective-C and Objective\-\*(C+
  languages themselves.
  .PP
! This section describes the command-line options that are only meaningful
! for Objective-C and Objective\-\*(C+ programs.  You can also use most of
! the language-independent \s-1GNU\s0 compiler options.
  For example, you might compile a file \fIsome_class.m\fR like this:
  .PP
  .Vb 1
--- 4545,4562 ----
  \&          g (S(arg)); // make arg prvalue so that it can bind to S&&
  \&        }
  .Ve
! .IP "\fB\-Wno\-conversion\-null\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-conversion-null (C++ and Objective-C++ only)"
! Do not warn for conversions between \f(CW\*(C`NULL\*(C'\fR and non\-pointer
  types. \fB\-Wconversion\-null\fR is enabled by default.
! .SS "Options Controlling Objective\-C and Objective\-C++ Dialects"
! .IX Subsection "Options Controlling Objective-C and Objective-C++ Dialects"
! (NOTE: This manual does not describe the Objective\-C and Objective\-C++
  languages themselves.
  .PP
! This section describes the command\-line options that are only meaningful
! for Objective\-C and Objective\-C++ programs.  You can also use most of
! the language\-independent GNU compiler options.
  For example, you might compile a file \fIsome_class.m\fR like this:
  .PP
  .Vb 1
*************** For example, you might compile a file \f
*** 4635,4798 ****
  .Ve
  .PP
  In this example, \fB\-fgnu\-runtime\fR is an option meant only for
! Objective-C and Objective\-\*(C+ programs; you can use the other options with
! any language supported by \s-1GCC.\s0
  .PP
! Note that since Objective-C is an extension of the C language, Objective-C
! compilations may also use options specific to the C front-end (e.g.,
! \&\fB\-Wtraditional\fR).  Similarly, Objective\-\*(C+ compilations may use
! \&\*(C+\-specific options (e.g., \fB\-Wabi\fR).
  .PP
! Here is a list of options that are \fIonly\fR for compiling Objective-C
! and Objective\-\*(C+ programs:
! .IP "\fB\-fconstant\-string\-class=\fR\fIclass-name\fR" 4
  .IX Item "-fconstant-string-class=class-name"
! Use \fIclass-name\fR as the name of the class to instantiate for each
  literal string specified with the syntax \f(CW\*(C`@"..."\*(C'\fR.  The default
! class name is \f(CW\*(C`NXConstantString\*(C'\fR if the \s-1GNU\s0 runtime is being used, and
  \&\f(CW\*(C`NSConstantString\*(C'\fR if the NeXT runtime is being used (see below).  On
  Darwin (macOS, MacOS X) platforms, the \fB\-fconstant\-cfstrings\fR option, if
  also present, overrides the \fB\-fconstant\-string\-class\fR setting and cause
  \&\f(CW\*(C`@"..."\*(C'\fR literals to be laid out as constant CoreFoundation strings.
! Note that \fB\-fconstant\-cfstrings\fR is an alias for the target-specific
  \&\fB\-mconstant\-cfstrings\fR equivalent.
! .IP "\fB\-fgnu\-runtime\fR" 4
  .IX Item "-fgnu-runtime"
! Generate object code compatible with the standard \s-1GNU\s0 Objective-C
  runtime.  This is the default for most types of systems.
! .IP "\fB\-fnext\-runtime\fR" 4
  .IX Item "-fnext-runtime"
  Generate output compatible with the NeXT runtime.  This is the default
! for NeXT-based systems, including Darwin and Mac \s-1OS X.\s0  The macro
  \&\f(CW\*(C`_\|_NEXT_RUNTIME_\|_\*(C'\fR is predefined if (and only if) this option is
  used.
! .IP "\fB\-fno\-nil\-receivers\fR" 4
  .IX Item "-fno-nil-receivers"
! Assume that all Objective-C message dispatches (\f(CW\*(C`[receiver
  message:arg]\*(C'\fR) in this translation unit ensure that the receiver is
  not \f(CW\*(C`nil\*(C'\fR.  This allows for more efficient entry points in the
  runtime to be used.  This option is only available in conjunction with
! the NeXT runtime and \s-1ABI\s0 version 0 or 1.
! .IP "\fB\-fobjc\-abi\-version=\fR\fIn\fR" 4
  .IX Item "-fobjc-abi-version=n"
! Use version \fIn\fR of the Objective-C \s-1ABI\s0 for the selected runtime.
  This option is currently supported only for the NeXT runtime.  In that
! case, Version 0 is the traditional (32\-bit) \s-1ABI\s0 without support for
! properties and other Objective-C 2.0 additions.  Version 1 is the
! traditional (32\-bit) \s-1ABI\s0 with support for properties and other
! Objective-C 2.0 additions.  Version 2 is the modern (64\-bit) \s-1ABI.\s0  If
  nothing is specified, the default is Version 0 on 32\-bit target
  machines, and Version 2 on 64\-bit target machines.
! .IP "\fB\-fobjc\-call\-cxx\-cdtors\fR" 4
  .IX Item "-fobjc-call-cxx-cdtors"
! For each Objective-C class, check if any of its instance variables is a
! \&\*(C+ object with a non-trivial default constructor.  If so, synthesize a
  special \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR instance method which runs
! non-trivial default constructors on any such instance variables, in order,
  and then return \f(CW\*(C`self\*(C'\fR.  Similarly, check if any instance variable
! is a \*(C+ object with a non-trivial destructor, and if so, synthesize a
  special \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR method which runs
  all such default destructors, in reverse order.
  .Sp
  The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR
  methods thusly generated only operate on instance variables
! declared in the current Objective-C class, and not those inherited
! from superclasses.  It is the responsibility of the Objective-C
! runtime to invoke all such methods in an object's inheritance
  hierarchy.  The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR methods are invoked
  by the runtime immediately after a new object instance is allocated;
  the \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods are invoked immediately
  before the runtime deallocates an object instance.
  .Sp
! As of this writing, only the NeXT runtime on Mac \s-1OS X 10.4\s0 and later has
  support for invoking the \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and
  \&\f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods.
! .IP "\fB\-fobjc\-direct\-dispatch\fR" 4
  .IX Item "-fobjc-direct-dispatch"
  Allow fast jumps to the message dispatcher.  On Darwin this is
  accomplished via the comm page.
! .IP "\fB\-fobjc\-exceptions\fR" 4
  .IX Item "-fobjc-exceptions"
  Enable syntactic support for structured exception handling in
! Objective-C, similar to what is offered by \*(C+.  This option
! is required to use the Objective-C keywords \f(CW@try\fR,
  \&\f(CW@throw\fR, \f(CW@catch\fR, \f(CW@finally\fR and
! \&\f(CW@synchronized\fR.  This option is available with both the \s-1GNU\s0
  runtime and the NeXT runtime (but not available in conjunction with
! the NeXT runtime on Mac \s-1OS X 10.2\s0 and earlier).
! .IP "\fB\-fobjc\-gc\fR" 4
  .IX Item "-fobjc-gc"
! Enable garbage collection (\s-1GC\s0) in Objective-C and Objective\-\*(C+
  programs.  This option is only available with the NeXT runtime; the
! \&\s-1GNU\s0 runtime has a different garbage collection implementation that
  does not require special compiler flags.
! .IP "\fB\-fobjc\-nilcheck\fR" 4
  .IX Item "-fobjc-nilcheck"
! For the NeXT runtime with version 2 of the \s-1ABI,\s0 check for a nil
  receiver in method invocations before doing the actual method call.
  This is the default and can be disabled using
  \&\fB\-fno\-objc\-nilcheck\fR.  Class methods and super calls are never
  checked for nil in this way no matter what this flag is set to.
! Currently this flag does nothing when the \s-1GNU\s0 runtime, or an older
! version of the NeXT runtime \s-1ABI,\s0 is used.
! .IP "\fB\-fobjc\-std=objc1\fR" 4
  .IX Item "-fobjc-std=objc1"
! Conform to the language syntax of Objective-C 1.0, the language
! recognized by \s-1GCC 4.0.\s0  This only affects the Objective-C additions to
! the C/\*(C+ language; it does not affect conformance to C/\*(C+ standards,
! which is controlled by the separate C/\*(C+ dialect option flags.  When
! this option is used with the Objective-C or Objective\-\*(C+ compiler,
! any Objective-C syntax that is not recognized by \s-1GCC 4.0\s0 is rejected.
! This is useful if you need to make sure that your Objective-C code can
! be compiled with older versions of \s-1GCC.\s0
! .IP "\fB\-freplace\-objc\-classes\fR" 4
  .IX Item "-freplace-objc-classes"
! Emit a special marker instructing \fB\fBld\fB\|(1)\fR not to statically link in
! the resulting object file, and allow \fB\fBdyld\fB\|(1)\fR to load it in at
! run time instead.  This is used in conjunction with the Fix-and-Continue
  debugging mode, where the object file in question may be recompiled and
  dynamically reloaded in the course of program execution, without the need
! to restart the program itself.  Currently, Fix-and-Continue functionality
! is only available in conjunction with the NeXT runtime on Mac \s-1OS X 10.3\s0
  and later.
! .IP "\fB\-fzero\-link\fR" 4
  .IX Item "-fzero-link"
  When compiling for the NeXT runtime, the compiler ordinarily replaces calls
! to \f(CW\*(C`objc_getClass("...")\*(C'\fR (when the name of the class is known at
  compile time) with static class references that get initialized at load time,
! which improves run-time performance.  Specifying the \fB\-fzero\-link\fR flag
! suppresses this behavior and causes calls to \f(CW\*(C`objc_getClass("...")\*(C'\fR
! to be retained.  This is useful in Zero-Link debugging mode, since it allows
  for individual class implementations to be modified during program execution.
! The \s-1GNU\s0 runtime currently always retains calls to \f(CW\*(C`objc_get_class("...")\*(C'\fR
! regardless of command-line options.
! .IP "\fB\-fno\-local\-ivars\fR" 4
  .IX Item "-fno-local-ivars"
! By default instance variables in Objective-C can be accessed as if
! they were local variables from within the methods of the class they're
  declared in.  This can lead to shadowing between instance variables
  and other variables declared either locally inside a class method or
  globally with the same name.  Specifying the \fB\-fno\-local\-ivars\fR
  flag disables this behavior thus avoiding variable shadowing issues.
! .IP "\fB\-fivar\-visibility=\fR[\fBpublic\fR|\fBprotected\fR|\fBprivate\fR|\fBpackage\fR]" 4
  .IX Item "-fivar-visibility=[public|protected|private|package]"
  Set the default instance variable visibility to the specified option
  so that instance variables declared outside the scope of any access
  modifier directives default to the specified visibility.
! .IP "\fB\-gen\-decls\fR" 4
  .IX Item "-gen-decls"
  Dump interface declarations for all classes seen in the source file to a
! file named \fI\fIsourcename\fI.decl\fR.
! .IP "\fB\-Wassign\-intercept\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wassign-intercept (Objective-C and Objective- only)"
! Warn whenever an Objective-C assignment is being intercepted by the
  garbage collector.
! .IP "\fB\-Wno\-property\-assign\-default\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-property-assign-default (Objective-C and Objective- only)"
! Do not warn if a property for an Objective-C object has no assign
  semantics specified.
! .IP "\fB\-Wno\-protocol\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-protocol (Objective-C and Objective- only)"
  If a class is declared to implement a protocol, a warning is issued for
  every method in the protocol that is not implemented by the class.  The
  default behavior is to issue a warning for every method not explicitly
--- 4564,4727 ----
  .Ve
  .PP
  In this example, \fB\-fgnu\-runtime\fR is an option meant only for
! Objective\-C and Objective\-C++ programs; you can use the other options with
! any language supported by GCC.
  .PP
! Note that since Objective\-C is an extension of the C language, Objective\-C
! compilations may also use options specific to the C front\-end (e.g.,
! \&\fB\-Wtraditional\fR).  Similarly, Objective\-C++ compilations may use
! C++\-specific options (e.g., \fB\-Wabi\fR).
  .PP
! Here is a list of options that are \fIonly\fR for compiling Objective\-C
! and Objective\-C++ programs:
! .IP \fB\-fconstant\-string\-class=\fR\fIclass\-name\fR 4
  .IX Item "-fconstant-string-class=class-name"
! Use \fIclass\-name\fR as the name of the class to instantiate for each
  literal string specified with the syntax \f(CW\*(C`@"..."\*(C'\fR.  The default
! class name is \f(CW\*(C`NXConstantString\*(C'\fR if the GNU runtime is being used, and
  \&\f(CW\*(C`NSConstantString\*(C'\fR if the NeXT runtime is being used (see below).  On
  Darwin (macOS, MacOS X) platforms, the \fB\-fconstant\-cfstrings\fR option, if
  also present, overrides the \fB\-fconstant\-string\-class\fR setting and cause
  \&\f(CW\*(C`@"..."\*(C'\fR literals to be laid out as constant CoreFoundation strings.
! Note that \fB\-fconstant\-cfstrings\fR is an alias for the target\-specific
  \&\fB\-mconstant\-cfstrings\fR equivalent.
! .IP \fB\-fgnu\-runtime\fR 4
  .IX Item "-fgnu-runtime"
! Generate object code compatible with the standard GNU Objective\-C
  runtime.  This is the default for most types of systems.
! .IP \fB\-fnext\-runtime\fR 4
  .IX Item "-fnext-runtime"
  Generate output compatible with the NeXT runtime.  This is the default
! for NeXT\-based systems, including Darwin and Mac OS X.  The macro
  \&\f(CW\*(C`_\|_NEXT_RUNTIME_\|_\*(C'\fR is predefined if (and only if) this option is
  used.
! .IP \fB\-fno\-nil\-receivers\fR 4
  .IX Item "-fno-nil-receivers"
! Assume that all Objective\-C message dispatches (\f(CW\*(C`[receiver
  message:arg]\*(C'\fR) in this translation unit ensure that the receiver is
  not \f(CW\*(C`nil\*(C'\fR.  This allows for more efficient entry points in the
  runtime to be used.  This option is only available in conjunction with
! the NeXT runtime and ABI version 0 or 1.
! .IP \fB\-fobjc\-abi\-version=\fR\fIn\fR 4
  .IX Item "-fobjc-abi-version=n"
! Use version \fIn\fR of the Objective\-C 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.
! .IP \fB\-fobjc\-call\-cxx\-cdtors\fR 4
  .IX Item "-fobjc-call-cxx-cdtors"
! For each Objective\-C class, check if any of its instance variables is a
! C++ object with a non\-trivial default constructor.  If so, synthesize a
  special \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR instance method which runs
! non\-trivial default constructors on any such instance variables, in order,
  and then return \f(CW\*(C`self\*(C'\fR.  Similarly, check if any instance variable
! is a C++ object with a non\-trivial destructor, and if so, synthesize a
  special \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR method which runs
  all such default destructors, in reverse order.
  .Sp
  The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR
  methods thusly generated only operate on instance variables
! declared in the current Objective\-C class, and not those inherited
! from superclasses.  It is the responsibility of the Objective\-C
! runtime to invoke all such methods in an object\*(Aqs inheritance
  hierarchy.  The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR methods are invoked
  by the runtime immediately after a new object instance is allocated;
  the \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods are invoked immediately
  before the runtime deallocates an object instance.
  .Sp
! As of this writing, only the NeXT runtime on Mac OS X 10.4 and later has
  support for invoking the \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and
  \&\f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods.
! .IP \fB\-fobjc\-direct\-dispatch\fR 4
  .IX Item "-fobjc-direct-dispatch"
  Allow fast jumps to the message dispatcher.  On Darwin this is
  accomplished via the comm page.
! .IP \fB\-fobjc\-exceptions\fR 4
  .IX Item "-fobjc-exceptions"
  Enable syntactic support for structured exception handling in
! Objective\-C, similar to what is offered by C++.  This option
! is required to use the Objective\-C keywords \f(CW@try\fR,
  \&\f(CW@throw\fR, \f(CW@catch\fR, \f(CW@finally\fR and
! \&\f(CW@synchronized\fR.  This option is available with both the GNU
  runtime and the NeXT runtime (but not available in conjunction with
! the NeXT runtime on Mac OS X 10.2 and earlier).
! .IP \fB\-fobjc\-gc\fR 4
  .IX Item "-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.
! .IP \fB\-fobjc\-nilcheck\fR 4
  .IX Item "-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
  \&\fB\-fno\-objc\-nilcheck\fR.  Class methods and super calls are never
  checked for nil in this way no matter what this flag is set to.
! Currently this flag does nothing when the GNU runtime, or an older
! version of the NeXT runtime ABI, is used.
! .IP \fB\-fobjc\-std=objc1\fR 4
  .IX Item "-fobjc-std=objc1"
! Conform to the language syntax of Objective\-C 1.0, the language
! recognized by 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.
! .IP \fB\-freplace\-objc\-classes\fR 4
  .IX Item "-freplace-objc-classes"
! Emit a special marker instructing \fBld\|(1)\fR not to statically link in
! the resulting object file, and allow \fBdyld\|(1)\fR to load it in at
! run time instead.  This is used in conjunction with the Fix\-and\-Continue
  debugging mode, where the object file in question may be recompiled and
  dynamically reloaded in the course of program execution, without the need
! to restart the program itself.  Currently, Fix\-and\-Continue functionality
! is only available in conjunction with the NeXT runtime on Mac OS X 10.3
  and later.
! .IP \fB\-fzero\-link\fR 4
  .IX Item "-fzero-link"
  When compiling for the NeXT runtime, the compiler ordinarily replaces calls
! to \f(CWobjc_getClass("...")\fR (when the name of the class is known at
  compile time) with static class references that get initialized at load time,
! which improves run\-time performance.  Specifying the \fB\-fzero\-link\fR flag
! suppresses this behavior and causes calls to \f(CWobjc_getClass("...")\fR
! to be retained.  This is useful in Zero\-Link debugging mode, since it allows
  for individual class implementations to be modified during program execution.
! The GNU runtime currently always retains calls to \f(CWobjc_get_class("...")\fR
! regardless of command\-line options.
! .IP \fB\-fno\-local\-ivars\fR 4
  .IX Item "-fno-local-ivars"
! By default instance variables in Objective\-C can be accessed as if
! they were local variables from within the methods of the class they\*(Aqre
  declared in.  This can lead to shadowing between instance variables
  and other variables declared either locally inside a class method or
  globally with the same name.  Specifying the \fB\-fno\-local\-ivars\fR
  flag disables this behavior thus avoiding variable shadowing issues.
! .IP \fB\-fivar\-visibility=\fR[\fBpublic\fR|\fBprotected\fR|\fBprivate\fR|\fBpackage\fR] 4
  .IX Item "-fivar-visibility=[public|protected|private|package]"
  Set the default instance variable visibility to the specified option
  so that instance variables declared outside the scope of any access
  modifier directives default to the specified visibility.
! .IP \fB\-gen\-decls\fR 4
  .IX Item "-gen-decls"
  Dump interface declarations for all classes seen in the source file to a
! file named \fIsourcename.decl\fR.
! .IP "\fB\-Wassign\-intercept\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wassign-intercept (Objective-C and Objective-C++ only)"
! Warn whenever an Objective\-C assignment is being intercepted by the
  garbage collector.
! .IP "\fB\-Wno\-property\-assign\-default\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wno-property-assign-default (Objective-C and Objective-C++ only)"
! Do not warn if a property for an Objective\-C object has no assign
  semantics specified.
! .IP "\fB\-Wno\-protocol\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-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 meth
*** 4800,4868 ****
  from the superclass.  If you use the \fB\-Wno\-protocol\fR option, then
  methods inherited from the superclass are considered to be implemented,
  and no warning is issued for them.
! .IP "\fB\-Wobjc\-root\-class\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wobjc-root-class (Objective-C and Objective- only)"
  Warn if a class interface lacks a superclass. Most classes will inherit
  from \f(CW\*(C`NSObject\*(C'\fR (or \f(CW\*(C`Object\*(C'\fR) for example.  When declaring
  classes intended to be root classes, the warning can be suppressed by
  marking their interfaces with \f(CW\*(C`_\|_attribute_\|_((objc_root_class))\*(C'\fR.
! .IP "\fB\-Wselector\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wselector (Objective-C and Objective- only)"
  Warn if multiple methods of different types for the same selector are
  found during compilation.  The check is performed on the list of methods
  in the final stage of compilation.  Additionally, a check is performed
! for each selector appearing in a \f(CW\*(C`@selector(...)\*(C'\fR
  expression, and a corresponding method for that selector has been found
  during compilation.  Because these checks scan the method table only at
  the end of compilation, these warnings are not produced if the final
  stage of compilation is not reached, for example because an error is
  found during compilation, or because the \fB\-fsyntax\-only\fR option is
  being used.
! .IP "\fB\-Wstrict\-selector\-match\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wstrict-selector-match (Objective-C and Objective- only)"
  Warn if multiple methods with differing argument and/or return types are
  found for a given selector when attempting to send a message using this
  selector to a receiver of type \f(CW\*(C`id\*(C'\fR or \f(CW\*(C`Class\*(C'\fR.  When this flag
  is off (which is the default behavior), the compiler omits such warnings
  if any differences found are confined to types that share the same size
  and alignment.
! .IP "\fB\-Wundeclared\-selector\fR (Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wundeclared-selector (Objective-C and Objective- only)"
! Warn if a \f(CW\*(C`@selector(...)\*(C'\fR expression referring to an
  undeclared selector is found.  A selector is considered undeclared if no
  method with that name has been declared before the
! \&\f(CW\*(C`@selector(...)\*(C'\fR expression, either explicitly in an
  \&\f(CW@interface\fR or \f(CW@protocol\fR declaration, or implicitly in
  an \f(CW@implementation\fR section.  This option always performs its
! checks as soon as a \f(CW\*(C`@selector(...)\*(C'\fR expression is found,
  while \fB\-Wselector\fR only performs its checks in the final stage of
  compilation.  This also enforces the coding style convention
  that methods and selectors must be declared before being used.
! .IP "\fB\-print\-objc\-runtime\-info\fR" 4
  .IX Item "-print-objc-runtime-info"
  Generate C header describing the largest structure that is passed by
  value, if any.
  .SS "Options to Control Diagnostic Messages Formatting"
  .IX Subsection "Options to Control Diagnostic Messages Formatting"
  Traditionally, diagnostic messages have been formatted irrespective of
! the output device's aspect (e.g. its width, ...).  You can use the
  options described below
  to control the formatting algorithm for diagnostic messages, 
  e.g. how many characters per line, how often source location
  information should be reported.  Note that some language front ends may not
  honor these options.
! .IP "\fB\-fmessage\-length=\fR\fIn\fR" 4
  .IX Item "-fmessage-length=n"
  Try to format error messages so that they fit on lines of about
! \&\fIn\fR characters.  If \fIn\fR is zero, then no line-wrapping is
  done; each error message appears on a single line.  This is the
  default for all front ends.
  .Sp
  Note \- this option also affects the display of the \fB#error\fR and
! \&\fB#warning\fR pre-processor directives, and the \fBdeprecated\fR
  function/type/variable attribute.  It does not however affect the
! \&\fBpragma \s-1GCC\s0 warning\fR and \fBpragma \s-1GCC\s0 error\fR pragmas.
! .IP "\fB\-fdiagnostics\-plain\-output\fR" 4
  .IX Item "-fdiagnostics-plain-output"
  This option requests that diagnostic output look as plain as possible, which
  may be useful when running \fBdejagnu\fR or other utilities that need to
--- 4729,4797 ----
  from the superclass.  If you use the \fB\-Wno\-protocol\fR option, then
  methods inherited from the superclass are considered to be implemented,
  and no warning is issued for them.
! .IP "\fB\-Wobjc\-root\-class\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wobjc-root-class (Objective-C and Objective-C++ only)"
  Warn if a class interface lacks a superclass. Most classes will inherit
  from \f(CW\*(C`NSObject\*(C'\fR (or \f(CW\*(C`Object\*(C'\fR) for example.  When declaring
  classes intended to be root classes, the warning can be suppressed by
  marking their interfaces with \f(CW\*(C`_\|_attribute_\|_((objc_root_class))\*(C'\fR.
! .IP "\fB\-Wselector\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-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 \f(CW@selector(...)\fR
  expression, and a corresponding method for that selector has been found
  during compilation.  Because these checks scan the method table only at
  the end of compilation, these warnings are not produced if the final
  stage of compilation is not reached, for example because an error is
  found during compilation, or because the \fB\-fsyntax\-only\fR option is
  being used.
! .IP "\fB\-Wstrict\-selector\-match\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wstrict-selector-match (Objective-C and Objective-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 \f(CW\*(C`id\*(C'\fR or \f(CW\*(C`Class\*(C'\fR.  When this flag
  is off (which is the default behavior), the compiler omits such warnings
  if any differences found are confined to types that share the same size
  and alignment.
! .IP "\fB\-Wundeclared\-selector\fR (Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wundeclared-selector (Objective-C and Objective-C++ only)"
! Warn if a \f(CW@selector(...)\fR expression referring to an
  undeclared selector is found.  A selector is considered undeclared if no
  method with that name has been declared before the
! \&\f(CW@selector(...)\fR expression, either explicitly in an
  \&\f(CW@interface\fR or \f(CW@protocol\fR declaration, or implicitly in
  an \f(CW@implementation\fR section.  This option always performs its
! checks as soon as a \f(CW@selector(...)\fR expression is found,
  while \fB\-Wselector\fR only performs its checks in the final stage of
  compilation.  This also enforces the coding style convention
  that methods and selectors must be declared before being used.
! .IP \fB\-print\-objc\-runtime\-info\fR 4
  .IX Item "-print-objc-runtime-info"
  Generate C header describing the largest structure that is passed by
  value, if any.
  .SS "Options to Control Diagnostic Messages Formatting"
  .IX Subsection "Options to Control Diagnostic Messages Formatting"
  Traditionally, diagnostic messages have been formatted irrespective of
! the output device\*(Aqs aspect (e.g. its width, ...).  You can use the
  options described below
  to control the formatting algorithm for diagnostic messages, 
  e.g. how many characters per line, how often source location
  information should be reported.  Note that some language front ends may not
  honor these options.
! .IP \fB\-fmessage\-length=\fR\fIn\fR 4
  .IX Item "-fmessage-length=n"
  Try to format error messages so that they fit on lines of about
! \&\fIn\fR characters.  If \fIn\fR is zero, then no line\-wrapping is
  done; each error message appears on a single line.  This is the
  default for all front ends.
  .Sp
  Note \- this option also affects the display of the \fB#error\fR and
! \&\fB#warning\fR pre\-processor directives, and the \fBdeprecated\fR
  function/type/variable attribute.  It does not however affect the
! \&\fBpragma GCC warning\fR and \fBpragma GCC error\fR pragmas.
! .IP \fB\-fdiagnostics\-plain\-output\fR 4
  .IX Item "-fdiagnostics-plain-output"
  This option requests that diagnostic output look as plain as possible, which
  may be useful when running \fBdejagnu\fR or other utilities that need to
*************** options:
*** 4874,4915 ****
  \&\-fdiagnostics\-color=never
  \&\-fdiagnostics\-urls=never
  \&\-fdiagnostics\-path\-format=separate\-events\fR
! In the future, if \s-1GCC\s0 changes the default appearance of its diagnostics, the
  corresponding option to disable the new behavior will be added to this list.
! .IP "\fB\-fdiagnostics\-show\-location=once\fR" 4
  .IX Item "-fdiagnostics-show-location=once"
! Only meaningful in line-wrapping mode.  Instructs the diagnostic messages
  reporter to emit source location information \fIonce\fR; that is, in
  case the message is too long to fit on a single physical line and has to
! be wrapped, the source location won't be emitted (as prefix) again,
  over and over, in subsequent continuation lines.  This is the default
  behavior.
! .IP "\fB\-fdiagnostics\-show\-location=every\-line\fR" 4
  .IX Item "-fdiagnostics-show-location=every-line"
! Only meaningful in line-wrapping mode.  Instructs the diagnostic
  messages reporter to emit the same source location information (as
  prefix) for physical lines that result from the process of breaking
  a message which is too long to fit on a single line.
! .IP "\fB\-fdiagnostics\-color[=\fR\fI\s-1WHEN\s0\fR\fB]\fR" 4
  .IX Item "-fdiagnostics-color[=WHEN]"
  .PD 0
! .IP "\fB\-fno\-diagnostics\-color\fR" 4
  .IX Item "-fno-diagnostics-color"
  .PD
! Use color in diagnostics.  \fI\s-1WHEN\s0\fR is \fBnever\fR, \fBalways\fR,
  or \fBauto\fR.  The default depends on how the compiler has been configured,
! it can be any of the above \fI\s-1WHEN\s0\fR options or also \fBnever\fR
! if \fB\s-1GCC_COLORS\s0\fR environment variable isn't present in the environment,
  and \fBauto\fR otherwise.
! \&\fBauto\fR makes \s-1GCC\s0 use color only when the standard error is a terminal,
  and when not executing in an emacs shell.
  The forms \fB\-fdiagnostics\-color\fR and \fB\-fno\-diagnostics\-color\fR are
  aliases for \fB\-fdiagnostics\-color=always\fR and
  \&\fB\-fdiagnostics\-color=never\fR, respectively.
  .Sp
! The colors are defined by the environment variable \fB\s-1GCC_COLORS\s0\fR.
! Its value is a colon-separated list of capabilities and Select Graphic
! Rendition (\s-1SGR\s0) substrings. \s-1SGR\s0 commands are interpreted by the
  terminal or terminal emulator.  (See the section in the documentation
  of your text terminal for permitted values and their meanings as
  character attributes.)  These substring values are integers in decimal
--- 4803,4844 ----
  \&\-fdiagnostics\-color=never
  \&\-fdiagnostics\-urls=never
  \&\-fdiagnostics\-path\-format=separate\-events\fR
! In the future, if GCC changes the default appearance of its diagnostics, the
  corresponding option to disable the new behavior will be added to this list.
! .IP \fB\-fdiagnostics\-show\-location=once\fR 4
  .IX Item "-fdiagnostics-show-location=once"
! Only meaningful in line\-wrapping mode.  Instructs the diagnostic messages
  reporter to emit source location information \fIonce\fR; that is, in
  case the message is too long to fit on a single physical line and has to
! be wrapped, the source location won\*(Aqt be emitted (as prefix) again,
  over and over, in subsequent continuation lines.  This is the default
  behavior.
! .IP \fB\-fdiagnostics\-show\-location=every\-line\fR 4
  .IX Item "-fdiagnostics-show-location=every-line"
! Only meaningful in line\-wrapping mode.  Instructs the diagnostic
  messages reporter to emit the same source location information (as
  prefix) for physical lines that result from the process of breaking
  a message which is too long to fit on a single line.
! .IP \fB\-fdiagnostics\-color[=\fR\fIWHEN\fR\fB]\fR 4
  .IX Item "-fdiagnostics-color[=WHEN]"
  .PD 0
! .IP \fB\-fno\-diagnostics\-color\fR 4
  .IX Item "-fno-diagnostics-color"
  .PD
! Use color in diagnostics.  \fIWHEN\fR is \fBnever\fR, \fBalways\fR,
  or \fBauto\fR.  The default depends on how the compiler has been configured,
! it can be any of the above \fIWHEN\fR options or also \fBnever\fR
! if \fBGCC_COLORS\fR environment variable isn\*(Aqt present in the environment,
  and \fBauto\fR otherwise.
! \&\fBauto\fR makes GCC use color only when the standard error is a terminal,
  and when not executing in an emacs shell.
  The forms \fB\-fdiagnostics\-color\fR and \fB\-fno\-diagnostics\-color\fR are
  aliases for \fB\-fdiagnostics\-color=always\fR and
  \&\fB\-fdiagnostics\-color=never\fR, respectively.
  .Sp
! The colors are defined by the environment variable \fBGCC_COLORS\fR.
! Its value is a colon\-separated list of capabilities and Select Graphic
! Rendition (SGR) substrings. SGR commands are interpreted by the
  terminal or terminal emulator.  (See the section in the documentation
  of your text terminal for permitted values and their meanings as
  character attributes.)  These substring values are integers in decimal
*************** for 88\-color and 256\-color modes foreg
*** 4930,4936 ****
  and \fB48;5;0\fR to \fB48;5;255\fR
  for 88\-color and 256\-color modes background colors.
  .Sp
! The default \fB\s-1GCC_COLORS\s0\fR is
  .Sp
  .Vb 4
  \&        error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\e
--- 4859,4865 ----
  and \fB48;5;0\fR to \fB48;5;255\fR
  for 88\-color and 256\-color modes background colors.
  .Sp
! The default \fBGCC_COLORS\fR is
  .Sp
  .Vb 4
  \&        error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\e
*************** The default \fB\s-1GCC_COLORS\s0\fR is
*** 4942,5082 ****
  where \fB01;31\fR is bold red, \fB01;35\fR is bold magenta,
  \&\fB01;36\fR is bold cyan, \fB32\fR is green, \fB34\fR is blue,
  \&\fB01\fR is bold, and \fB31\fR is red.
! Setting \fB\s-1GCC_COLORS\s0\fR to the empty string disables colors.
  Supported capabilities are as follows.
  .RS 4
  .ie n .IP """error=""" 4
! .el .IP "\f(CWerror=\fR" 4
  .IX Item "error="
! \&\s-1SGR\s0 substring for error: markers.
  .ie n .IP """warning=""" 4
! .el .IP "\f(CWwarning=\fR" 4
  .IX Item "warning="
! \&\s-1SGR\s0 substring for warning: markers.
  .ie n .IP """note=""" 4
! .el .IP "\f(CWnote=\fR" 4
  .IX Item "note="
! \&\s-1SGR\s0 substring for note: markers.
  .ie n .IP """path=""" 4
! .el .IP "\f(CWpath=\fR" 4
  .IX Item "path="
! \&\s-1SGR\s0 substring for colorizing paths of control-flow events as printed
  via \fB\-fdiagnostics\-path\-format=\fR, such as the identifiers of
  individual events and lines indicating interprocedural calls and returns.
  .ie n .IP """range1=""" 4
! .el .IP "\f(CWrange1=\fR" 4
  .IX Item "range1="
! \&\s-1SGR\s0 substring for first additional range.
  .ie n .IP """range2=""" 4
! .el .IP "\f(CWrange2=\fR" 4
  .IX Item "range2="
! \&\s-1SGR\s0 substring for second additional range.
  .ie n .IP """locus=""" 4
! .el .IP "\f(CWlocus=\fR" 4
  .IX Item "locus="
! \&\s-1SGR\s0 substring for location information, \fBfile:line\fR or
  \&\fBfile:line:column\fR etc.
  .ie n .IP """quote=""" 4
! .el .IP "\f(CWquote=\fR" 4
  .IX Item "quote="
! \&\s-1SGR\s0 substring for information printed within quotes.
  .ie n .IP """fnname=""" 4
! .el .IP "\f(CWfnname=\fR" 4
  .IX Item "fnname="
! \&\s-1SGR\s0 substring for names of \*(C+ functions.
  .ie n .IP """targs=""" 4
! .el .IP "\f(CWtargs=\fR" 4
  .IX Item "targs="
! \&\s-1SGR\s0 substring for \*(C+ function template parameter bindings.
  .ie n .IP """fixit\-insert=""" 4
! .el .IP "\f(CWfixit\-insert=\fR" 4
  .IX Item "fixit-insert="
! \&\s-1SGR\s0 substring for fix-it hints suggesting text to
  be inserted or replaced.
  .ie n .IP """fixit\-delete=""" 4
! .el .IP "\f(CWfixit\-delete=\fR" 4
  .IX Item "fixit-delete="
! \&\s-1SGR\s0 substring for fix-it hints suggesting text to
  be deleted.
  .ie n .IP """diff\-filename=""" 4
! .el .IP "\f(CWdiff\-filename=\fR" 4
  .IX Item "diff-filename="
! \&\s-1SGR\s0 substring for filename headers within generated patches.
  .ie n .IP """diff\-hunk=""" 4
! .el .IP "\f(CWdiff\-hunk=\fR" 4
  .IX Item "diff-hunk="
! \&\s-1SGR\s0 substring for the starts of hunks within generated patches.
  .ie n .IP """diff\-delete=""" 4
! .el .IP "\f(CWdiff\-delete=\fR" 4
  .IX Item "diff-delete="
! \&\s-1SGR\s0 substring for deleted lines within generated patches.
  .ie n .IP """diff\-insert=""" 4
! .el .IP "\f(CWdiff\-insert=\fR" 4
  .IX Item "diff-insert="
! \&\s-1SGR\s0 substring for inserted lines within generated patches.
  .ie n .IP """type\-diff=""" 4
! .el .IP "\f(CWtype\-diff=\fR" 4
  .IX Item "type-diff="
! \&\s-1SGR\s0 substring for highlighting mismatching types within template
! arguments in the \*(C+ frontend.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdiagnostics\-urls[=\fR\fI\s-1WHEN\s0\fR\fB]\fR" 4
  .IX Item "-fdiagnostics-urls[=WHEN]"
  Use escape sequences to embed URLs in diagnostics.  For example, when
! \&\fB\-fdiagnostics\-show\-option\fR emits text showing the command-line
! option controlling a diagnostic, embed a \s-1URL\s0 for documentation of that
  option.
  .Sp
! \&\fI\s-1WHEN\s0\fR is \fBnever\fR, \fBalways\fR, or \fBauto\fR.
! \&\fBauto\fR makes \s-1GCC\s0 use \s-1URL\s0 escape sequences only when the standard error
  is a terminal, and when not executing in an emacs shell or any graphical
  terminal which is known to be incompatible with this feature, see below.
  .Sp
  The default depends on how the compiler has been configured.
! It can be any of the above \fI\s-1WHEN\s0\fR options.
  .Sp
! \&\s-1GCC\s0 can also be configured (via the
! \&\fB\-\-with\-diagnostics\-urls=auto\-if\-env\fR configure-time option)
  so that the default is affected by environment variables.
! Under such a configuration, \s-1GCC\s0 defaults to using \fBauto\fR
! if either \fB\s-1GCC_URLS\s0\fR or \fB\s-1TERM_URLS\s0\fR environment variables are
! present and non-empty in the environment of the compiler, or \fBnever\fR
  if neither are.
  .Sp
  However, even with \fB\-fdiagnostics\-urls=always\fR the behavior is
  dependent on those environment variables:
! If \fB\s-1GCC_URLS\s0\fR is set to empty or \fBno\fR, do not embed URLs in
! diagnostics.  If set to \fBst\fR, URLs use \s-1ST\s0 escape sequences.
! If set to \fBbel\fR, the default, URLs use \s-1BEL\s0 escape sequences.
! Any other non-empty value enables the feature.
! If \fB\s-1GCC_URLS\s0\fR is not set, use \fB\s-1TERM_URLS\s0\fR as a fallback.
! Note: \s-1ST\s0 is an \s-1ANSI\s0 escape sequence, string terminator \fB\s-1ESC\s0 \e\fR,
! \&\s-1BEL\s0 is an \s-1ASCII\s0 character, CTRL-G that usually sounds like a beep.
  .Sp
! At this time \s-1GCC\s0 tries to detect also a few terminals that are known to
! not implement the \s-1URL\s0 feature, and have bugs or at least had bugs in
! some versions that are still in use, where the \s-1URL\s0 escapes are likely
  to misbehave, i.e. print garbage on the screen.
  That list is currently xfce4\-terminal, certain known to be buggy
! gnome-terminal versions, the linux console, and mingw.
  This check can be skipped with the \fB\-fdiagnostics\-urls=always\fR.
! .IP "\fB\-fno\-diagnostics\-show\-option\fR" 4
  .IX Item "-fno-diagnostics-show-option"
  By default, each diagnostic emitted includes text indicating the
! command-line option that directly controls the diagnostic (if such an
  option is known to the diagnostic machinery).  Specifying the
  \&\fB\-fno\-diagnostics\-show\-option\fR flag suppresses that behavior.
! .IP "\fB\-fno\-diagnostics\-show\-caret\fR" 4
  .IX Item "-fno-diagnostics-show-caret"
  By default, each diagnostic emitted includes the original source line
  and a caret \fB^\fR indicating the column.  This option suppresses this
  information.  The source line is truncated to \fIn\fR characters, if
  the \fB\-fmessage\-length=n\fR option is given.  When the output is done
  to the terminal, the width is limited to the width given by the
! \&\fB\s-1COLUMNS\s0\fR environment variable or, if not set, to the terminal width.
! .IP "\fB\-fno\-diagnostics\-show\-labels\fR" 4
  .IX Item "-fno-diagnostics-show-labels"
  By default, when printing source code (via \fB\-fdiagnostics\-show\-caret\fR),
  diagnostics can label ranges of source code with pertinent information, such
--- 4871,5011 ----
  where \fB01;31\fR is bold red, \fB01;35\fR is bold magenta,
  \&\fB01;36\fR is bold cyan, \fB32\fR is green, \fB34\fR is blue,
  \&\fB01\fR is bold, and \fB31\fR is red.
! Setting \fBGCC_COLORS\fR to the empty string disables colors.
  Supported capabilities are as follows.
  .RS 4
  .ie n .IP """error=""" 4
! .el .IP \f(CWerror=\fR 4
  .IX Item "error="
! SGR substring for error: markers.
  .ie n .IP """warning=""" 4
! .el .IP \f(CWwarning=\fR 4
  .IX Item "warning="
! SGR substring for warning: markers.
  .ie n .IP """note=""" 4
! .el .IP \f(CWnote=\fR 4
  .IX Item "note="
! SGR substring for note: markers.
  .ie n .IP """path=""" 4
! .el .IP \f(CWpath=\fR 4
  .IX Item "path="
! SGR substring for colorizing paths of control\-flow events as printed
  via \fB\-fdiagnostics\-path\-format=\fR, such as the identifiers of
  individual events and lines indicating interprocedural calls and returns.
  .ie n .IP """range1=""" 4
! .el .IP \f(CWrange1=\fR 4
  .IX Item "range1="
! SGR substring for first additional range.
  .ie n .IP """range2=""" 4
! .el .IP \f(CWrange2=\fR 4
  .IX Item "range2="
! SGR substring for second additional range.
  .ie n .IP """locus=""" 4
! .el .IP \f(CWlocus=\fR 4
  .IX Item "locus="
! SGR substring for location information, \fBfile:line\fR or
  \&\fBfile:line:column\fR etc.
  .ie n .IP """quote=""" 4
! .el .IP \f(CWquote=\fR 4
  .IX Item "quote="
! SGR substring for information printed within quotes.
  .ie n .IP """fnname=""" 4
! .el .IP \f(CWfnname=\fR 4
  .IX Item "fnname="
! SGR substring for names of C++ functions.
  .ie n .IP """targs=""" 4
! .el .IP \f(CWtargs=\fR 4
  .IX Item "targs="
! SGR substring for C++ function template parameter bindings.
  .ie n .IP """fixit\-insert=""" 4
! .el .IP \f(CWfixit\-insert=\fR 4
  .IX Item "fixit-insert="
! SGR substring for fix\-it hints suggesting text to
  be inserted or replaced.
  .ie n .IP """fixit\-delete=""" 4
! .el .IP \f(CWfixit\-delete=\fR 4
  .IX Item "fixit-delete="
! SGR substring for fix\-it hints suggesting text to
  be deleted.
  .ie n .IP """diff\-filename=""" 4
! .el .IP \f(CWdiff\-filename=\fR 4
  .IX Item "diff-filename="
! SGR substring for filename headers within generated patches.
  .ie n .IP """diff\-hunk=""" 4
! .el .IP \f(CWdiff\-hunk=\fR 4
  .IX Item "diff-hunk="
! SGR substring for the starts of hunks within generated patches.
  .ie n .IP """diff\-delete=""" 4
! .el .IP \f(CWdiff\-delete=\fR 4
  .IX Item "diff-delete="
! SGR substring for deleted lines within generated patches.
  .ie n .IP """diff\-insert=""" 4
! .el .IP \f(CWdiff\-insert=\fR 4
  .IX Item "diff-insert="
! SGR substring for inserted lines within generated patches.
  .ie n .IP """type\-diff=""" 4
! .el .IP \f(CWtype\-diff=\fR 4
  .IX Item "type-diff="
! SGR substring for highlighting mismatching types within template
! arguments in the C++ frontend.
  .RE
  .RS 4
  .RE
! .IP \fB\-fdiagnostics\-urls[=\fR\fIWHEN\fR\fB]\fR 4
  .IX Item "-fdiagnostics-urls[=WHEN]"
  Use escape sequences to embed URLs in diagnostics.  For example, when
! \&\fB\-fdiagnostics\-show\-option\fR emits text showing the command\-line
! option controlling a diagnostic, embed a URL for documentation of that
  option.
  .Sp
! \&\fIWHEN\fR is \fBnever\fR, \fBalways\fR, or \fBauto\fR.
! \&\fBauto\fR makes GCC use URL escape sequences only when the standard error
  is a terminal, and when not executing in an emacs shell or any graphical
  terminal which is known to be incompatible with this feature, see below.
  .Sp
  The default depends on how the compiler has been configured.
! It can be any of the above \fIWHEN\fR options.
  .Sp
! GCC can also be configured (via the
! \&\fB\-\-with\-diagnostics\-urls=auto\-if\-env\fR configure\-time option)
  so that the default is affected by environment variables.
! Under such a configuration, GCC defaults to using \fBauto\fR
! if either \fBGCC_URLS\fR or \fBTERM_URLS\fR environment variables are
! present and non\-empty in the environment of the compiler, or \fBnever\fR
  if neither are.
  .Sp
  However, even with \fB\-fdiagnostics\-urls=always\fR the behavior is
  dependent on those environment variables:
! If \fBGCC_URLS\fR is set to empty or \fBno\fR, do not embed URLs in
! diagnostics.  If set to \fBst\fR, URLs use ST escape sequences.
! If set to \fBbel\fR, the default, URLs use BEL escape sequences.
! Any other non\-empty value enables the feature.
! If \fBGCC_URLS\fR is not set, use \fBTERM_URLS\fR as a fallback.
! Note: ST is an ANSI escape sequence, string terminator \fBESC \e\fR,
! BEL is an ASCII character, CTRL\-G that usually sounds like a beep.
  .Sp
! At this time GCC tries to detect also a few terminals that are known to
! not implement the URL feature, and have bugs or at least had bugs in
! some versions that are still in use, where the URL escapes are likely
  to misbehave, i.e. print garbage on the screen.
  That list is currently xfce4\-terminal, certain known to be buggy
! gnome\-terminal versions, the linux console, and mingw.
  This check can be skipped with the \fB\-fdiagnostics\-urls=always\fR.
! .IP \fB\-fno\-diagnostics\-show\-option\fR 4
  .IX Item "-fno-diagnostics-show-option"
  By default, each diagnostic emitted includes text indicating the
! command\-line option that directly controls the diagnostic (if such an
  option is known to the diagnostic machinery).  Specifying the
  \&\fB\-fno\-diagnostics\-show\-option\fR flag suppresses that behavior.
! .IP \fB\-fno\-diagnostics\-show\-caret\fR 4
  .IX Item "-fno-diagnostics-show-caret"
  By default, each diagnostic emitted includes the original source line
  and a caret \fB^\fR indicating the column.  This option suppresses this
  information.  The source line is truncated to \fIn\fR characters, if
  the \fB\-fmessage\-length=n\fR option is given.  When the output is done
  to the terminal, the width is limited to the width given by the
! \&\fBCOLUMNS\fR environment variable or, if not set, to the terminal width.
! .IP \fB\-fno\-diagnostics\-show\-labels\fR 4
  .IX Item "-fno-diagnostics-show-labels"
  By default, when printing source code (via \fB\-fdiagnostics\-show\-caret\fR),
  diagnostics can label ranges of source code with pertinent information, such
*************** as the types of expressions:
*** 5090,5133 ****
  .Ve
  .Sp
  This option suppresses the printing of these labels (in the example above,
! the vertical bars and the \*(L"char *\*(R" and \*(L"long int\*(R" text).
! .IP "\fB\-fno\-diagnostics\-show\-cwe\fR" 4
  .IX Item "-fno-diagnostics-show-cwe"
  Diagnostic messages can optionally have an associated
!  \s-1CWE\s0 (\f(CW\*(C`https://cwe.mitre.org/index.html\*(C'\fR) identifier.
! \&\s-1GCC\s0 itself only provides such metadata for some of the \fB\-fanalyzer\fR
! diagnostics.  \s-1GCC\s0 plugins may also provide diagnostics with such metadata.
  By default, if this information is present, it will be printed with
  the diagnostic.  This option suppresses the printing of this metadata.
! .IP "\fB\-fno\-diagnostics\-show\-rules\fR" 4
  .IX Item "-fno-diagnostics-show-rules"
  Diagnostic messages can optionally have rules associated with them, such
  as from a coding standard, or a specification.
! \&\s-1GCC\s0 itself does not do this for any of its diagnostics, but plugins may do so.
  By default, if this information is present, it will be printed with
  the diagnostic.  This option suppresses the printing of this metadata.
! .IP "\fB\-fno\-diagnostics\-show\-line\-numbers\fR" 4
  .IX Item "-fno-diagnostics-show-line-numbers"
  By default, when printing source code (via \fB\-fdiagnostics\-show\-caret\fR),
  a left margin is printed, showing line numbers.  This option suppresses this
  left margin.
! .IP "\fB\-fdiagnostics\-minimum\-margin\-width=\fR\fIwidth\fR" 4
  .IX Item "-fdiagnostics-minimum-margin-width=width"
  This option controls the minimum width of the left margin printed by
  \&\fB\-fdiagnostics\-show\-line\-numbers\fR.  It defaults to 6.
! .IP "\fB\-fdiagnostics\-parseable\-fixits\fR" 4
  .IX Item "-fdiagnostics-parseable-fixits"
! Emit fix-it hints in a machine-parseable format, suitable for consumption
! by IDEs.  For each fix-it, a line will be printed after the relevant
! diagnostic, starting with the string \*(L"fix-it:\*(R".  For example:
  .Sp
  .Vb 1
  \&        fix\-it:"test.c":{45:3\-45:21}:"gtk_widget_show_all"
  .Ve
  .Sp
! The location is expressed as a half-open range, expressed as a count of
  bytes, starting at byte 1 for the initial column.  In the above example,
! bytes 3 through 20 of line 45 of \*(L"test.c\*(R" are to be replaced with the
  given string:
  .Sp
  .Vb 5
--- 5019,5062 ----
  .Ve
  .Sp
  This option suppresses the printing of these labels (in the example above,
! the vertical bars and the "char *" and "long int" text).
! .IP \fB\-fno\-diagnostics\-show\-cwe\fR 4
  .IX Item "-fno-diagnostics-show-cwe"
  Diagnostic messages can optionally have an associated
!  CWE (\f(CW\*(C`https://cwe.mitre.org/index.html\*(C'\fR) identifier.
! GCC itself only provides such metadata for some of the \fB\-fanalyzer\fR
! diagnostics.  GCC plugins may also provide diagnostics with such metadata.
  By default, if this information is present, it will be printed with
  the diagnostic.  This option suppresses the printing of this metadata.
! .IP \fB\-fno\-diagnostics\-show\-rules\fR 4
  .IX Item "-fno-diagnostics-show-rules"
  Diagnostic messages can optionally have rules associated with them, such
  as from a coding standard, or a specification.
! GCC itself does not do this for any of its diagnostics, but plugins may do so.
  By default, if this information is present, it will be printed with
  the diagnostic.  This option suppresses the printing of this metadata.
! .IP \fB\-fno\-diagnostics\-show\-line\-numbers\fR 4
  .IX Item "-fno-diagnostics-show-line-numbers"
  By default, when printing source code (via \fB\-fdiagnostics\-show\-caret\fR),
  a left margin is printed, showing line numbers.  This option suppresses this
  left margin.
! .IP \fB\-fdiagnostics\-minimum\-margin\-width=\fR\fIwidth\fR 4
  .IX Item "-fdiagnostics-minimum-margin-width=width"
  This option controls the minimum width of the left margin printed by
  \&\fB\-fdiagnostics\-show\-line\-numbers\fR.  It defaults to 6.
! .IP \fB\-fdiagnostics\-parseable\-fixits\fR 4
  .IX Item "-fdiagnostics-parseable-fixits"
! Emit fix\-it hints in a machine\-parseable format, suitable for consumption
! by IDEs.  For each fix\-it, a line will be printed after the relevant
! diagnostic, starting with the string "fix\-it:".  For example:
  .Sp
  .Vb 1
  \&        fix\-it:"test.c":{45:3\-45:21}:"gtk_widget_show_all"
  .Ve
  .Sp
! The location is expressed as a half\-open range, expressed as a count of
  bytes, starting at byte 1 for the initial column.  In the above example,
! bytes 3 through 20 of line 45 of "test.c" are to be replaced with the
  given string:
  .Sp
  .Vb 5
*************** given string:
*** 5138,5153 ****
  \&          gtk_widget_show_all
  .Ve
  .Sp
! The filename and replacement string escape backslash as \*(L"\e\e\*(R", tab as \*(L"\et\*(R",
! newline as \*(L"\en\*(R", double quotes as \*(L"\e\*(R"\*(L", non-printable characters as octal
! (e.g. vertical tab as \*(R"\e013").
  .Sp
  An empty replacement string indicates that the given range is to be removed.
! An empty range (e.g. \*(L"45:3\-45:3\*(R") indicates that the string is to
  be inserted at the given position.
! .IP "\fB\-fdiagnostics\-generate\-patch\fR" 4
  .IX Item "-fdiagnostics-generate-patch"
! Print fix-it hints to stderr in unified diff format, after any diagnostics
  are printed.  For example:
  .Sp
  .Vb 3
--- 5067,5082 ----
  \&          gtk_widget_show_all
  .Ve
  .Sp
! The filename and replacement string escape backslash as "\e\e", tab as "\et",
! newline as "\en", double quotes as "\e"", non\-printable characters as octal
! (e.g. vertical tab as "\e013").
  .Sp
  An empty replacement string indicates that the given range is to be removed.
! An empty range (e.g. "45:3\-45:3") indicates that the string is to
  be inserted at the given position.
! .IP \fB\-fdiagnostics\-generate\-patch\fR 4
  .IX Item "-fdiagnostics-generate-patch"
! Print fix\-it hints to stderr in unified diff format, after any diagnostics
  are printed.  For example:
  .Sp
  .Vb 3
*************** are printed.  For example:
*** 5164,5172 ****
  .Sp
  The diff may or may not be colorized, following the same rules
  as for diagnostics (see \fB\-fdiagnostics\-color\fR).
! .IP "\fB\-fdiagnostics\-show\-template\-tree\fR" 4
  .IX Item "-fdiagnostics-show-template-tree"
! In the \*(C+ frontend, when printing diagnostics showing mismatching
  template types, such as:
  .Sp
  .Vb 2
--- 5093,5101 ----
  .Sp
  The diff may or may not be colorized, following the same rules
  as for diagnostics (see \fB\-fdiagnostics\-color\fR).
! .IP \fB\-fdiagnostics\-show\-template\-tree\fR 4
  .IX Item "-fdiagnostics-show-template-tree"
! In the C++ frontend, when printing diagnostics showing mismatching
  template types, such as:
  .Sp
  .Vb 2
*************** template types, such as:
*** 5175,5181 ****
  .Ve
  .Sp
  the \fB\-fdiagnostics\-show\-template\-tree\fR flag enables printing a
! tree-like structure showing the common and differing parts of the types,
  such as:
  .Sp
  .Vb 4
--- 5104,5110 ----
  .Ve
  .Sp
  the \fB\-fdiagnostics\-show\-template\-tree\fR flag enables printing a
! tree\-like structure showing the common and differing parts of the types,
  such as:
  .Sp
  .Vb 4
*************** such as:
*** 5185,5196 ****
  \&              [double != float]>>
  .Ve
  .Sp
! The parts that differ are highlighted with color (\*(L"double\*(R" and
! \&\*(L"float\*(R" in this case).
! .IP "\fB\-fno\-elide\-type\fR" 4
  .IX Item "-fno-elide-type"
! By default when the \*(C+ frontend prints diagnostics showing mismatching
! template types, common parts of the types are printed as \*(L"[...]\*(R" to
  simplify the error message.  For example:
  .Sp
  .Vb 2
--- 5114,5125 ----
  \&              [double != float]>>
  .Ve
  .Sp
! The parts that differ are highlighted with color ("double" and
! "float" in this case).
! .IP \fB\-fno\-elide\-type\fR 4
  .IX Item "-fno-elide-type"
! By default when the C++ frontend prints diagnostics showing mismatching
! template types, common parts of the types are printed as "[...]" to
  simplify the error message.  For example:
  .Sp
  .Vb 2
*************** simplify the error message.  For example
*** 5201,5217 ****
  Specifying the \fB\-fno\-elide\-type\fR flag suppresses that behavior.
  This flag also affects the output of the
  \&\fB\-fdiagnostics\-show\-template\-tree\fR flag.
! .IP "\fB\-fdiagnostics\-path\-format=\fR\fI\s-1KIND\s0\fR" 4
  .IX Item "-fdiagnostics-path-format=KIND"
! Specify how to print paths of control-flow events for diagnostics that
  have such a path associated with them.
  .Sp
! \&\fI\s-1KIND\s0\fR is \fBnone\fR, \fBseparate-events\fR, or \fBinline-events\fR,
  the default.
  .Sp
  \&\fBnone\fR means to not print diagnostic paths.
  .Sp
! \&\fBseparate-events\fR means to print a separate \*(L"note\*(R" diagnostic for
  each event within the diagnostic.  For example:
  .Sp
  .Vb 4
--- 5130,5146 ----
  Specifying the \fB\-fno\-elide\-type\fR flag suppresses that behavior.
  This flag also affects the output of the
  \&\fB\-fdiagnostics\-show\-template\-tree\fR flag.
! .IP \fB\-fdiagnostics\-path\-format=\fR\fIKIND\fR 4
  .IX Item "-fdiagnostics-path-format=KIND"
! Specify how to print paths of control\-flow events for diagnostics that
  have such a path associated with them.
  .Sp
! \&\fIKIND\fR is \fBnone\fR, \fBseparate\-events\fR, or \fBinline\-events\fR,
  the default.
  .Sp
  \&\fBnone\fR means to not print diagnostic paths.
  .Sp
! \&\fBseparate\-events\fR means to print a separate "note" diagnostic for
  each event within the diagnostic.  For example:
  .Sp
  .Vb 4
*************** each event within the diagnostic.  For e
*** 5221,5229 ****
  \&        test.c:29:5: note: (3) when calling \*(AqPyList_Append\*(Aq, passing NULL from (1) as argument 1
  .Ve
  .Sp
! \&\fBinline-events\fR means to print the events \*(L"inline\*(R" within the source
  code.  This view attempts to consolidate the events into runs of
! sufficiently-close events, printing them as labelled ranges within the source.
  .Sp
  For example, the same events as above might be printed as:
  .Sp
--- 5150,5158 ----
  \&        test.c:29:5: note: (3) when calling \*(AqPyList_Append\*(Aq, passing NULL from (1) as argument 1
  .Ve
  .Sp
! \&\fBinline\-events\fR means to print the events "inline" within the source
  code.  This view attempts to consolidate the events into runs of
! sufficiently\-close events, printing them as labelled ranges within the source.
  .Sp
  For example, the same events as above might be printed as:
  .Sp
*************** For example:
*** 5297,5305 ****
  \&            |
  \&        (etc)
  .Ve
! .IP "\fB\-fdiagnostics\-show\-path\-depths\fR" 4
  .IX Item "-fdiagnostics-show-path-depths"
! This option provides additional information when printing control-flow paths
  associated with a diagnostic.
  .Sp
  If this is option is provided then the stack depth will be printed for
--- 5226,5234 ----
  \&            |
  \&        (etc)
  .Ve
! .IP \fB\-fdiagnostics\-show\-path\-depths\fR 4
  .IX Item "-fdiagnostics-show-path-depths"
! This option provides additional information when printing control\-flow paths
  associated with a diagnostic.
  .Sp
  If this is option is provided then the stack depth will be printed for
*************** If provided with \fB\-fdiagnostics\-path
*** 5308,5393 ****
  the stack depth and function declaration will be appended when printing
  each event.
  .Sp
! This is intended for use by \s-1GCC\s0 developers and plugin developers when
  debugging diagnostics that report interprocedural control flow.
! .IP "\fB\-fno\-show\-column\fR" 4
  .IX Item "-fno-show-column"
  Do not print column numbers in diagnostics.  This may be necessary if
  diagnostics are being scanned by a program that does not understand the
  column numbers, such as \fBdejagnu\fR.
! .IP "\fB\-fdiagnostics\-column\-unit=\fR\fI\s-1UNIT\s0\fR" 4
  .IX Item "-fdiagnostics-column-unit=UNIT"
  Select the units for the column number.  This affects traditional diagnostics
! (in the absence of \fB\-fno\-show\-column\fR), as well as \s-1JSON\s0 format
  diagnostics if requested.
  .Sp
! The default \fI\s-1UNIT\s0\fR, \fBdisplay\fR, considers the number of display
  columns occupied by each character.  This may be larger than the number
  of bytes required to encode the character, in the case of tab
  characters, or it may be smaller, in the case of multibyte characters.
! For example, the character \*(L"\s-1GREEK SMALL LETTER PI\s0 (U+03C0)\*(R" occupies one
! display column, and its \s-1UTF\-8\s0 encoding requires two bytes; the character
! \&\*(L"\s-1SLIGHTLY SMILING FACE\s0 (U+1F642)\*(R" occupies two display columns, and
! its \s-1UTF\-8\s0 encoding requires four bytes.
  .Sp
! Setting \fI\s-1UNIT\s0\fR to \fBbyte\fR changes the column number to the raw byte
! count in all cases, as was traditionally output by \s-1GCC\s0 prior to version 11.1.0.
! .IP "\fB\-fdiagnostics\-column\-origin=\fR\fI\s-1ORIGIN\s0\fR" 4
  .IX Item "-fdiagnostics-column-origin=ORIGIN"
  Select the origin for column numbers, i.e. the column number assigned to the
! first column.  The default value of 1 corresponds to traditional \s-1GCC\s0
! behavior and to the \s-1GNU\s0 style guide.  Some utilities may perform better with an
! origin of 0; any non-negative value may be specified.
! .IP "\fB\-fdiagnostics\-escape\-format=\fR\fI\s-1FORMAT\s0\fR" 4
  .IX Item "-fdiagnostics-escape-format=FORMAT"
! When \s-1GCC\s0 prints pertinent source lines for a diagnostic it normally attempts
  to print the source bytes directly.  However, some diagnostics relate to encoding
! issues in the source file, such as malformed \s-1UTF\-8,\s0 or issues with Unicode
! normalization.  These diagnostics are flagged so that \s-1GCC\s0 will escape bytes
! that are not printable \s-1ASCII\s0 when printing their pertinent source lines.
  .Sp
  This option controls how such bytes should be escaped.
  .Sp
! The default \fI\s-1FORMAT\s0\fR, \fBunicode\fR displays Unicode characters that
! are not printable \s-1ASCII\s0 in the form \fB\fR, and bytes that do not
! correspond to a Unicode character validly-encoded in UTF\-8\-encoded will be
! displayed as hexadecimal in the form \fB<\s-1XX\s0>\fR.
  .Sp
  For example, a source line containing the string \fBbefore\fR followed by the
! Unicode character U+03C0 (\*(L"\s-1GREEK SMALL LETTER PI\*(R",\s0 with \s-1UTF\-8\s0 encoding
! 0xCF 0x80) followed by the byte 0xBF (a stray \s-1UTF\-8\s0 trailing byte), followed by
  the string \fBafter\fR will be printed for such a diagnostic as:
  .Sp
  .Vb 1
  \&         beforeafter
  .Ve
  .Sp
! Setting \fI\s-1FORMAT\s0\fR to \fBbytes\fR will display all non-printable-ASCII bytes
! in the form \fB<\s-1XX\s0>\fR, thus showing the underlying encoding of non-ASCII
  Unicode characters.  For the example above, the following will be printed:
  .Sp
  .Vb 1
  \&         before<80>after
  .Ve
! .IP "\fB\-fdiagnostics\-format=\fR\fI\s-1FORMAT\s0\fR" 4
  .IX Item "-fdiagnostics-format=FORMAT"
  Select a different format for printing diagnostics.
! \&\fI\s-1FORMAT\s0\fR is \fBtext\fR, \fBsarif-stderr\fR, \fBsarif-file\fR,
! \&\fBjson\fR, \fBjson-stderr\fR, or \fBjson-file\fR.
  .Sp
  The default is \fBtext\fR.
  .Sp
! The \fBsarif-stderr\fR and \fBsarif-file\fR formats both emit
! diagnostics in \s-1SARIF\s0 Version 2.1.0 format, either to stderr, or to a file
! named \fI\fIsource\fI.sarif\fR, respectively.
  .Sp
! The \fBjson\fR format is a synonym for \fBjson-stderr\fR.
! The \fBjson-stderr\fR and \fBjson-file\fR formats are identical, apart from
! where the \s-1JSON\s0 is emitted to \- with the former, the \s-1JSON\s0 is emitted to stderr,
! whereas with \fBjson-file\fR it is written to \fI\fIsource\fI.gcc.json\fR.
  .Sp
! The emitted \s-1JSON\s0 consists of a top-level \s-1JSON\s0 array containing \s-1JSON\s0 objects
! representing the diagnostics.  The \s-1JSON\s0 is emitted as one line, without
  formatting; the examples below have been formatted for clarity.
  .Sp
  Diagnostics can have child diagnostics.  For example, this error and note:
--- 5237,5322 ----
  the stack depth and function declaration will be appended when printing
  each event.
  .Sp
! This is intended for use by GCC developers and plugin developers when
  debugging diagnostics that report interprocedural control flow.
! .IP \fB\-fno\-show\-column\fR 4
  .IX Item "-fno-show-column"
  Do not print column numbers in diagnostics.  This may be necessary if
  diagnostics are being scanned by a program that does not understand the
  column numbers, such as \fBdejagnu\fR.
! .IP \fB\-fdiagnostics\-column\-unit=\fR\fIUNIT\fR 4
  .IX Item "-fdiagnostics-column-unit=UNIT"
  Select the units for the column number.  This affects traditional diagnostics
! (in the absence of \fB\-fno\-show\-column\fR), as well as JSON format
  diagnostics if requested.
  .Sp
! The default \fIUNIT\fR, \fBdisplay\fR, considers the number of display
  columns occupied by each character.  This may be larger than the number
  of bytes required to encode the character, in the case of tab
  characters, or it may be smaller, in the case of multibyte characters.
! For example, the character "GREEK SMALL LETTER PI (U+03C0)" occupies one
! display column, and its UTF\-8 encoding requires two bytes; the character
! "SLIGHTLY SMILING FACE (U+1F642)" occupies two display columns, and
! its UTF\-8 encoding requires four bytes.
  .Sp
! Setting \fIUNIT\fR to \fBbyte\fR changes the column number to the raw byte
! count in all cases, as was traditionally output by GCC prior to version 11.1.0.
! .IP \fB\-fdiagnostics\-column\-origin=\fR\fIORIGIN\fR 4
  .IX Item "-fdiagnostics-column-origin=ORIGIN"
  Select the origin for column numbers, i.e. the column number assigned to the
! first column.  The default value of 1 corresponds to traditional GCC
! behavior and to the GNU style guide.  Some utilities may perform better with an
! origin of 0; any non\-negative value may be specified.
! .IP \fB\-fdiagnostics\-escape\-format=\fR\fIFORMAT\fR 4
  .IX Item "-fdiagnostics-escape-format=FORMAT"
! When GCC prints pertinent source lines for a diagnostic it normally attempts
  to print the source bytes directly.  However, some diagnostics relate to encoding
! issues in the source file, such as malformed UTF\-8, or issues with Unicode
! normalization.  These diagnostics are flagged so that GCC will escape bytes
! that are not printable ASCII when printing their pertinent source lines.
  .Sp
  This option controls how such bytes should be escaped.
  .Sp
! The default \fIFORMAT\fR, \fBunicode\fR displays Unicode characters that
! are not printable ASCII in the form \fB\fR, and bytes that do not
! correspond to a Unicode character validly\-encoded in UTF\-8\-encoded will be
! displayed as hexadecimal in the form \fB\fR.
  .Sp
  For example, a source line containing the string \fBbefore\fR followed by the
! Unicode character U+03C0 ("GREEK SMALL LETTER PI", with UTF\-8 encoding
! 0xCF 0x80) followed by the byte 0xBF (a stray UTF\-8 trailing byte), followed by
  the string \fBafter\fR will be printed for such a diagnostic as:
  .Sp
  .Vb 1
  \&         beforeafter
  .Ve
  .Sp
! Setting \fIFORMAT\fR to \fBbytes\fR will display all non\-printable\-ASCII bytes
! in the form \fB\fR, thus showing the underlying encoding of non\-ASCII
  Unicode characters.  For the example above, the following will be printed:
  .Sp
  .Vb 1
  \&         before<80>after
  .Ve
! .IP \fB\-fdiagnostics\-format=\fR\fIFORMAT\fR 4
  .IX Item "-fdiagnostics-format=FORMAT"
  Select a different format for printing diagnostics.
! \&\fIFORMAT\fR is \fBtext\fR, \fBsarif\-stderr\fR, \fBsarif\-file\fR,
! \&\fBjson\fR, \fBjson\-stderr\fR, or \fBjson\-file\fR.
  .Sp
  The default is \fBtext\fR.
  .Sp
! The \fBsarif\-stderr\fR and \fBsarif\-file\fR formats both emit
! diagnostics in SARIF Version 2.1.0 format, either to stderr, or to a file
! named \fIsource.sarif\fR, respectively.
  .Sp
! The \fBjson\fR format is a synonym for \fBjson\-stderr\fR.
! The \fBjson\-stderr\fR and \fBjson\-file\fR formats are identical, apart from
! where the JSON is emitted to \- with the former, the JSON is emitted to stderr,
! whereas with \fBjson\-file\fR it is written to \fIsource.gcc.json\fR.
  .Sp
! The emitted JSON consists of a top\-level JSON array containing JSON objects
! representing the diagnostics.  The JSON is emitted as one line, without
  formatting; the examples below have been formatted for clarity.
  .Sp
  Diagnostics can have child diagnostics.  For example, this error and note:
*************** Diagnostics can have child diagnostics.
*** 5403,5409 ****
  \&              |     ^
  .Ve
  .Sp
! might be printed in \s-1JSON\s0 form (after formatting) like this:
  .Sp
  .Vb 10
  \&        [
--- 5332,5338 ----
  \&              |     ^
  .Ve
  .Sp
! might be printed in JSON form (after formatting) like this:
  .Sp
  .Vb 10
  \&        [
*************** might be printed in \s-1JSON\s0 form (af
*** 5457,5463 ****
  where the \f(CW\*(C`note\*(C'\fR is a child of the \f(CW\*(C`warning\*(C'\fR.
  .Sp
  A diagnostic has a \f(CW\*(C`kind\*(C'\fR.  If this is \f(CW\*(C`warning\*(C'\fR, then there is
! an \f(CW\*(C`option\*(C'\fR key describing the command-line option controlling the
  warning.
  .Sp
  A diagnostic can contain zero or more locations.  Each location has an
--- 5386,5392 ----
  where the \f(CW\*(C`note\*(C'\fR is a child of the \f(CW\*(C`warning\*(C'\fR.
  .Sp
  A diagnostic has a \f(CW\*(C`kind\*(C'\fR.  If this is \f(CW\*(C`warning\*(C'\fR, then there is
! an \f(CW\*(C`option\*(C'\fR key describing the command\-line option controlling the
  warning.
  .Sp
  A diagnostic can contain zero or more locations.  Each location has an
*************** optional \f(CW\*(C`label\*(C'\fR string
*** 5466,5477 ****
  A position is described by a \f(CW\*(C`file\*(C'\fR name, a \f(CW\*(C`line\*(C'\fR number, and
  three numbers indicating a column position:
  .RS 4
! .IP "*" 4
  \&\f(CW\*(C`display\-column\*(C'\fR counts display columns, accounting for tabs and
  multibyte characters.
! .IP "*" 4
  \&\f(CW\*(C`byte\-column\*(C'\fR counts raw bytes.
! .IP "*" 4
  \&\f(CW\*(C`column\*(C'\fR is equal to one of
  the previous two, as dictated by the \fB\-fdiagnostics\-column\-unit\fR
  option.
--- 5395,5406 ----
  A position is described by a \f(CW\*(C`file\*(C'\fR name, a \f(CW\*(C`line\*(C'\fR number, and
  three numbers indicating a column position:
  .RS 4
! .IP * 4
  \&\f(CW\*(C`display\-column\*(C'\fR counts display columns, accounting for tabs and
  multibyte characters.
! .IP * 4
  \&\f(CW\*(C`byte\-column\*(C'\fR counts raw bytes.
! .IP * 4
  \&\f(CW\*(C`column\*(C'\fR is equal to one of
  the previous two, as dictated by the \fB\-fdiagnostics\-column\-unit\fR
  option.
*************** option.
*** 5481,5487 ****
  All three columns are relative to the origin specified by
  \&\fB\-fdiagnostics\-column\-origin\fR, which is typically equal to 1 but may
  be set, for instance, to 0 for compatibility with other utilities that
! number columns from 0.  The column origin is recorded in the \s-1JSON\s0 output in
  the \f(CW\*(C`column\-origin\*(C'\fR tag.  In the remaining examples below, the extra
  column number outputs have been omitted for brevity.
  .Sp
--- 5410,5416 ----
  All three columns are relative to the origin specified by
  \&\fB\-fdiagnostics\-column\-origin\fR, which is typically equal to 1 but may
  be set, for instance, to 0 for compatibility with other utilities that
! number columns from 0.  The column origin is recorded in the JSON output in
  the \f(CW\*(C`column\-origin\*(C'\fR tag.  In the remaining examples below, the extra
  column number outputs have been omitted for brevity.
  .Sp
*************** For example, this error:
*** 5497,5505 ****
  \&              |          S {aka struct s}
  .Ve
  .Sp
! has three locations.  Its primary location is at the \*(L"+\*(R" token at column
! 23.  It has two secondary locations, describing the left and right-hand sides
! of the expression, which have labels.  It might be printed in \s-1JSON\s0 form as:
  .Sp
  .Vb 10
  \&            {
--- 5426,5434 ----
  \&              |          S {aka struct s}
  .Ve
  .Sp
! has three locations.  Its primary location is at the "+" token at column
! 23.  It has two secondary locations, describing the left and right\-hand sides
! of the expression, which have labels.  It might be printed in JSON form as:
  .Sp
  .Vb 10
  \&            {
*************** of the expression, which have labels.  I
*** 5535,5544 ****
  \&            }
  .Ve
  .Sp
! If a diagnostic contains fix-it hints, it has a \f(CW\*(C`fixits\*(C'\fR array,
! consisting of half-open intervals, similar to the output of
  \&\fB\-fdiagnostics\-parseable\-fixits\fR.  For example, this diagnostic
! with a replacement fix-it hint:
  .Sp
  .Vb 5
  \&        demo.c:8:15: error: \*(Aqstruct s\*(Aq has no member named \*(Aqcolour\*(Aq; did you
--- 5464,5473 ----
  \&            }
  .Ve
  .Sp
! If a diagnostic contains fix\-it hints, it has a \f(CW\*(C`fixits\*(C'\fR array,
! consisting of half\-open intervals, similar to the output of
  \&\fB\-fdiagnostics\-parseable\-fixits\fR.  For example, this diagnostic
! with a replacement fix\-it hint:
  .Sp
  .Vb 5
  \&        demo.c:8:15: error: \*(Aqstruct s\*(Aq has no member named \*(Aqcolour\*(Aq; did you
*************** with a replacement fix-it hint:
*** 5548,5554 ****
  \&              |               color
  .Ve
  .Sp
! might be printed in \s-1JSON\s0 form as:
  .Sp
  .Vb 10
  \&            {
--- 5477,5483 ----
  \&              |               color
  .Ve
  .Sp
! might be printed in JSON form as:
  .Sp
  .Vb 10
  \&            {
*************** might be printed in \s-1JSON\s0 form as:
*** 5588,5599 ****
  \&            }
  .Ve
  .Sp
! where the fix-it hint suggests replacing the text from \f(CW\*(C`start\*(C'\fR up
! to but not including \f(CW\*(C`next\*(C'\fR with \f(CW\*(C`string\*(C'\fR's value.  Deletions
  are expressed via an empty value for \f(CW\*(C`string\*(C'\fR, insertions by
  having \f(CW\*(C`start\*(C'\fR equal \f(CW\*(C`next\*(C'\fR.
  .Sp
! If the diagnostic has a path of control-flow events associated with it,
  it has a \f(CW\*(C`path\*(C'\fR array of objects representing the events.  Each
  event object has a \f(CW\*(C`description\*(C'\fR string, a \f(CW\*(C`location\*(C'\fR object,
  along with a \f(CW\*(C`function\*(C'\fR string and a \f(CW\*(C`depth\*(C'\fR number for
--- 5517,5528 ----
  \&            }
  .Ve
  .Sp
! where the fix\-it hint suggests replacing the text from \f(CW\*(C`start\*(C'\fR up
! to but not including \f(CW\*(C`next\*(C'\fR with \f(CW\*(C`string\*(C'\fR\*(Aqs value.  Deletions
  are expressed via an empty value for \f(CW\*(C`string\*(C'\fR, insertions by
  having \f(CW\*(C`start\*(C'\fR equal \f(CW\*(C`next\*(C'\fR.
  .Sp
! If the diagnostic has a path of control\-flow events associated with it,
  it has a \f(CW\*(C`path\*(C'\fR array of objects representing the events.  Each
  event object has a \f(CW\*(C`description\*(C'\fR string, a \f(CW\*(C`location\*(C'\fR object,
  along with a \f(CW\*(C`function\*(C'\fR string and a \f(CW\*(C`depth\*(C'\fR number for
*************** stack depth relative to some baseline: t
*** 5603,5609 ****
  within the stack.
  .Sp
  For example, the intraprocedural example shown for
! \&\fB\-fdiagnostics\-path\-format=\fR might have this \s-1JSON\s0 for its path:
  .Sp
  .Vb 10
  \&            "path": [
--- 5532,5538 ----
  within the stack.
  .Sp
  For example, the intraprocedural example shown for
! \&\fB\-fdiagnostics\-path\-format=\fR might have this JSON for its path:
  .Sp
  .Vb 10
  \&            "path": [
*************** For example, the intraprocedural example
*** 5641,5647 ****
  .Ve
  .Sp
  Diagnostics have a boolean attribute \f(CW\*(C`escape\-source\*(C'\fR, hinting whether
! non-ASCII bytes should be escaped when printing the pertinent lines of
  source code (\f(CW\*(C`true\*(C'\fR for diagnostics involving source encoding issues).
  .RE
  .SS "Options to Request or Suppress Warnings"
--- 5570,5576 ----
  .Ve
  .Sp
  Diagnostics have a boolean attribute \f(CW\*(C`escape\-source\*(C'\fR, hinting whether
! non\-ASCII bytes should be escaped when printing the pertinent lines of
  source code (\f(CW\*(C`true\*(C'\fR for diagnostics involving source encoding issues).
  .RE
  .SS "Options to Request or Suppress Warnings"
*************** Warnings are diagnostic messages that re
*** 5650,5675 ****
  are not inherently erroneous but that are risky or suggest there
  may have been an error.
  .PP
! The following language-independent options do not enable specific
! warnings but control the kinds of diagnostics produced by \s-1GCC.\s0
! .IP "\fB\-fsyntax\-only\fR" 4
  .IX Item "-fsyntax-only"
! Check the code for syntax errors, but don't do anything beyond that.
! .IP "\fB\-fmax\-errors=\fR\fIn\fR" 4
  .IX Item "-fmax-errors=n"
  Limits the maximum number of error messages to \fIn\fR, at which point
! \&\s-1GCC\s0 bails out rather than attempting to continue processing the source
  code.  If \fIn\fR is 0 (the default), there is no limit on the number
  of error messages produced.  If \fB\-Wfatal\-errors\fR is also
  specified, then \fB\-Wfatal\-errors\fR takes precedence over this
  option.
! .IP "\fB\-w\fR" 4
  .IX Item "-w"
  Inhibit all warning messages.
! .IP "\fB\-Werror\fR" 4
  .IX Item "-Werror"
  Make all warnings into errors.
! .IP "\fB\-Werror=\fR" 4
  .IX Item "-Werror="
  Make the specified warning into an error.  The specifier for a warning
  is appended; for example \fB\-Werror=switch\fR turns the warnings
--- 5579,5604 ----
  are not inherently erroneous but that are risky or suggest there
  may have been an error.
  .PP
! The following language\-independent options do not enable specific
! warnings but control the kinds of diagnostics produced by GCC.
! .IP \fB\-fsyntax\-only\fR 4
  .IX Item "-fsyntax-only"
! Check the code for syntax errors, but don\*(Aqt do anything beyond that.
! .IP \fB\-fmax\-errors=\fR\fIn\fR 4
  .IX Item "-fmax-errors=n"
  Limits the maximum number of error messages to \fIn\fR, at which point
! GCC bails out rather than attempting to continue processing the source
  code.  If \fIn\fR is 0 (the default), there is no limit on the number
  of error messages produced.  If \fB\-Wfatal\-errors\fR is also
  specified, then \fB\-Wfatal\-errors\fR takes precedence over this
  option.
! .IP \fB\-w\fR 4
  .IX Item "-w"
  Inhibit all warning messages.
! .IP \fB\-Werror\fR 4
  .IX Item "-Werror"
  Make all warnings into errors.
! .IP \fB\-Werror=\fR 4
  .IX Item "-Werror="
  Make the specified warning into an error.  The specifier for a warning
  is appended; for example \fB\-Werror=switch\fR turns the warnings
*************** option that controls the warning.  That
*** 5688,5694 ****
  Note that specifying \fB\-Werror=\fR\fIfoo\fR automatically implies
  \&\fB\-W\fR\fIfoo\fR.  However, \fB\-Wno\-error=\fR\fIfoo\fR does not
  imply anything.
! .IP "\fB\-Wfatal\-errors\fR" 4
  .IX Item "-Wfatal-errors"
  This option causes the compiler to abort compilation on the first error
  occurred rather than trying to keep going and printing further error
--- 5617,5623 ----
  Note that specifying \fB\-Werror=\fR\fIfoo\fR automatically implies
  \&\fB\-W\fR\fIfoo\fR.  However, \fB\-Wno\-error=\fR\fIfoo\fR does not
  imply anything.
! .IP \fB\-Wfatal\-errors\fR 4
  .IX Item "-Wfatal-errors"
  This option causes the compiler to abort compilation on the first error
  occurred rather than trying to keep going and printing further error
*************** implicit declarations.  Each of these sp
*** 5700,5720 ****
  has a negative form beginning \fB\-Wno\-\fR to turn off warnings; for
  example, \fB\-Wno\-implicit\fR.  This manual lists only one of the
  two forms, whichever is not the default.  For further
! language-specific options also refer to \fB\*(C+ Dialect Options\fR and
! \&\fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
  Additional warnings can be produced by enabling the static analyzer;
  .PP
  Some options, such as \fB\-Wall\fR and \fB\-Wextra\fR, turn on other
  options, such as \fB\-Wunused\fR, which may turn on further options,
  such as \fB\-Wunused\-value\fR. The combined effect of positive and
  negative forms is that more specific options have priority over less
! specific ones, independently of their position in the command-line. For
  options of the same specificity, the last one takes effect. Options
  enabled or disabled via pragmas take effect
! as if they appeared at the end of the command-line.
  .PP
  When an unrecognized warning option is requested (e.g.,
! \&\fB\-Wunknown\-warning\fR), \s-1GCC\s0 emits a diagnostic stating
  that the option is not recognized.  However, if the \fB\-Wno\-\fR form
  is used, the behavior is slightly different: no diagnostic is
  produced for \fB\-Wno\-unknown\-warning\fR unless other diagnostics
--- 5629,5649 ----
  has a negative form beginning \fB\-Wno\-\fR to turn off warnings; for
  example, \fB\-Wno\-implicit\fR.  This manual lists only one of the
  two forms, whichever is not the default.  For further
! language\-specific options also refer to \fBC++ Dialect Options\fR and
! \&\fBObjective\-C and Objective\-C++ Dialect Options\fR.
  Additional warnings can be produced by enabling the static analyzer;
  .PP
  Some options, such as \fB\-Wall\fR and \fB\-Wextra\fR, turn on other
  options, such as \fB\-Wunused\fR, which may turn on further options,
  such as \fB\-Wunused\-value\fR. The combined effect of positive and
  negative forms is that more specific options have priority over less
! specific ones, independently of their position in the command\-line. For
  options of the same specificity, the last one takes effect. Options
  enabled or disabled via pragmas take effect
! as if they appeared at the end of the command\-line.
  .PP
  When an unrecognized warning option is requested (e.g.,
! \&\fB\-Wunknown\-warning\fR), GCC emits a diagnostic stating
  that the option is not recognized.  However, if the \fB\-Wno\-\fR form
  is used, the behavior is slightly different: no diagnostic is
  produced for \fB\-Wno\-unknown\-warning\fR unless other diagnostics
*************** warns that an unrecognized option is pre
*** 5724,5843 ****
  .PP
  The effectiveness of some warnings depends on optimizations also being
  enabled. For example \fB\-Wsuggest\-final\-types\fR is more effective
! with link-time optimization and some instances of other warnings may
  not be issued at all unless optimization is enabled.  While optimization
  in general improves the efficacy of control and data flow sensitive
  warnings, in some cases it may also cause false positives.
! .IP "\fB\-Wpedantic\fR" 4
  .IX Item "-Wpedantic"
  .PD 0
! .IP "\fB\-pedantic\fR" 4
  .IX Item "-pedantic"
  .PD
! Issue all the warnings demanded by strict \s-1ISO C\s0 and \s-1ISO \*(C+\s0;
  reject all programs that use forbidden extensions, and some other
! programs that do not follow \s-1ISO C\s0 and \s-1ISO \*(C+.\s0  For \s-1ISO C,\s0 follows the
! version of the \s-1ISO C\s0 standard specified by any \fB\-std\fR option used.
  .Sp
! Valid \s-1ISO C\s0 and \s-1ISO \*(C+\s0 programs should compile properly with or without
  this option (though a rare few require \fB\-ansi\fR or a
! \&\fB\-std\fR option specifying the required version of \s-1ISO C\s0).  However,
! without this option, certain \s-1GNU\s0 extensions and traditional C and \*(C+
  features are supported as well.  With this option, they are rejected.
  .Sp
  \&\fB\-Wpedantic\fR does not cause warning messages for use of the
  alternate keywords whose names begin and end with \fB_\|_\fR.  This alternate
! format can also be used to disable warnings for non-ISO \fB_\|_intN\fR types,
  i.e. \fB_\|_intN_\|_\fR.
  Pedantic warnings are also disabled in the expression that follows
  \&\f(CW\*(C`_\|_extension_\|_\*(C'\fR.  However, only system header files should use
  these escape routes; application programs should avoid them.
  .Sp
! Some users try to use \fB\-Wpedantic\fR to check programs for strict \s-1ISO
! C\s0 conformance.  They soon find that it does not do quite what they want:
! it finds some non-ISO practices, but not all\-\-\-only those for which
! \&\s-1ISO C\s0 \fIrequires\fR a diagnostic, and some others for which
  diagnostics have been added.
  .Sp
! A feature to report any failure to conform to \s-1ISO C\s0 might be useful in
  some instances, but would require considerable additional work and would
! be quite different from \fB\-Wpedantic\fR.  We don't have plans to
  support such a feature in the near future.
  .Sp
! Where the standard specified with \fB\-std\fR represents a \s-1GNU\s0
  extended dialect of C, such as \fBgnu90\fR or \fBgnu99\fR, there is a
! corresponding \fIbase standard\fR, the version of \s-1ISO C\s0 on which the \s-1GNU\s0
  extended dialect is based.  Warnings from \fB\-Wpedantic\fR are given
  where they are required by the base standard.  (It does not make sense
! for such warnings to be given only for features not in the specified \s-1GNU
! C\s0 dialect, since by definition the \s-1GNU\s0 dialects of C include all
  features the compiler supports with the given option, and there would be
  nothing to warn about.)
! .IP "\fB\-pedantic\-errors\fR" 4
  .IX Item "-pedantic-errors"
  Give an error whenever the \fIbase standard\fR (see \fB\-Wpedantic\fR)
  requires a diagnostic, in some cases where there is undefined behavior
! at compile-time and in some other cases that do not prevent compilation
  of programs that are valid according to the standard. This is not
  equivalent to \fB\-Werror=pedantic\fR, since there are errors enabled
  by this option and not enabled by the latter and vice versa.
! .IP "\fB\-Wall\fR" 4
  .IX Item "-Wall"
  This enables all the warnings about constructions that some users
  consider questionable, and that are easy to avoid (or modify to
  prevent the warning), even in conjunction with macros.  This also
! enables some language-specific warnings described in \fB\*(C+ Dialect
! Options\fR and \fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
  .Sp
  \&\fB\-Wall\fR turns on the following warning flags:
  .Sp
  \&\fB\-Waddress
  \&\-Warray\-bounds=1\fR (only with\fB \fR\fB\-O2\fR)
  \&\fB\-Warray\-compare
! \&\-Warray\-parameter=2\fR (C and Objective-C only)
  \&\fB\-Wbool\-compare
  \&\-Wbool\-operation
  \&\-Wc++11\-compat  \-Wc++14\-compat
! \&\-Wcatch\-value\fR (\*(C+ and Objective\-\*(C+ only)
  \&\fB\-Wchar\-subscripts
  \&\-Wcomment
  \&\-Wdangling\-pointer=2
! \&\-Wduplicate\-decl\-specifier\fR (C and Objective-C only)
! \&\fB\-Wenum\-compare\fR (in C/ObjC; this is on by default in \*(C+)
! \&\fB\-Wenum\-int\-mismatch\fR (C and Objective-C only)
  \&\fB\-Wformat
  \&\-Wformat\-overflow
  \&\-Wformat\-truncation
  \&\-Wint\-in\-bool\-context
! \&\-Wimplicit\fR (C and Objective-C only)
! \&\fB\-Wimplicit\-int\fR (C and Objective-C only)
! \&\fB\-Wimplicit\-function\-declaration\fR (C and Objective-C only)
! \&\fB\-Winit\-self\fR (only for \*(C+)
  \&\fB\-Wlogical\-not\-parentheses
  \&\-Wmain\fR (only for C/ObjC and unless\fB \fR\fB\-ffreestanding\fR)
  \&\fB\-Wmaybe\-uninitialized
  \&\-Wmemset\-elt\-size
  \&\-Wmemset\-transposed\-args
! \&\-Wmisleading\-indentation\fR (only for C/\*(C+)
  \&\fB\-Wmismatched\-dealloc
! \&\-Wmismatched\-new\-delete\fR (only for C/\*(C+)
  \&\fB\-Wmissing\-attributes
  \&\-Wmissing\-braces\fR (only for C/ObjC)
  \&\fB\-Wmultistatement\-macros
! \&\-Wnarrowing\fR (only for \*(C+)
  \&\fB\-Wnonnull
  \&\-Wnonnull\-compare
  \&\-Wopenmp\-simd
  \&\-Wparentheses
! \&\-Wpessimizing\-move\fR (only for \*(C+)
  \&\fB\-Wpointer\-sign
! \&\-Wrange\-loop\-construct\fR (only for \*(C+)
  \&\fB\-Wreorder
  \&\-Wrestrict
  \&\-Wreturn\-type
! \&\-Wself\-move\fR (only for \*(C+)
  \&\fB\-Wsequence\-point
! \&\-Wsign\-compare\fR (only in \*(C+)
  \&\fB\-Wsizeof\-array\-div
  \&\-Wsizeof\-pointer\-div
  \&\-Wsizeof\-pointer\-memaccess
--- 5653,5772 ----
  .PP
  The effectiveness of some warnings depends on optimizations also being
  enabled. For example \fB\-Wsuggest\-final\-types\fR is more effective
! with link\-time optimization and some instances of other warnings may
  not be issued at all unless optimization is enabled.  While optimization
  in general improves the efficacy of control and data flow sensitive
  warnings, in some cases it may also cause false positives.
! .IP \fB\-Wpedantic\fR 4
  .IX Item "-Wpedantic"
  .PD 0
! .IP \fB\-pedantic\fR 4
  .IX Item "-pedantic"
  .PD
! Issue all the warnings demanded by strict 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 \fB\-std\fR option used.
  .Sp
! Valid ISO C and ISO C++ programs should compile properly with or without
  this option (though a rare few require \fB\-ansi\fR or a
! \&\fB\-std\fR option specifying the required version of 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.
  .Sp
  \&\fB\-Wpedantic\fR does not cause warning messages for use of the
  alternate keywords whose names begin and end with \fB_\|_\fR.  This alternate
! format can also be used to disable warnings for non\-ISO \fB_\|_intN\fR types,
  i.e. \fB_\|_intN_\|_\fR.
  Pedantic warnings are also disabled in the expression that follows
  \&\f(CW\*(C`_\|_extension_\|_\*(C'\fR.  However, only system header files should use
  these escape routes; application programs should avoid them.
  .Sp
! Some users try to use \fB\-Wpedantic\fR to check programs for strict 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 \fIrequires\fR a diagnostic, and some others for which
  diagnostics have been added.
  .Sp
! 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 \fB\-Wpedantic\fR.  We don\*(Aqt have plans to
  support such a feature in the near future.
  .Sp
! Where the standard specified with \fB\-std\fR represents a GNU
  extended dialect of C, such as \fBgnu90\fR or \fBgnu99\fR, there is a
! corresponding \fIbase standard\fR, the version of ISO C on which the GNU
  extended dialect is based.  Warnings from \fB\-Wpedantic\fR are given
  where they are required by the base standard.  (It does not make sense
! for such warnings to be given only for features not in the specified 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.)
! .IP \fB\-pedantic\-errors\fR 4
  .IX Item "-pedantic-errors"
  Give an error whenever the \fIbase standard\fR (see \fB\-Wpedantic\fR)
  requires a diagnostic, in some cases where there is undefined behavior
! at compile\-time and in some other cases that do not prevent compilation
  of programs that are valid according to the standard. This is not
  equivalent to \fB\-Werror=pedantic\fR, since there are errors enabled
  by this option and not enabled by the latter and vice versa.
! .IP \fB\-Wall\fR 4
  .IX Item "-Wall"
  This enables all the warnings about constructions that some users
  consider questionable, and that are easy to avoid (or modify to
  prevent the warning), even in conjunction with macros.  This also
! enables some language\-specific warnings described in \fBC++ Dialect
! Options\fR and \fBObjective\-C and Objective\-C++ Dialect Options\fR.
  .Sp
  \&\fB\-Wall\fR turns on the following warning flags:
  .Sp
  \&\fB\-Waddress
  \&\-Warray\-bounds=1\fR (only with\fB \fR\fB\-O2\fR)
  \&\fB\-Warray\-compare
! \&\-Warray\-parameter=2\fR (C and Objective\-C only)
  \&\fB\-Wbool\-compare
  \&\-Wbool\-operation
  \&\-Wc++11\-compat  \-Wc++14\-compat
! \&\-Wcatch\-value\fR (C++ and Objective\-C++ only)
  \&\fB\-Wchar\-subscripts
  \&\-Wcomment
  \&\-Wdangling\-pointer=2
! \&\-Wduplicate\-decl\-specifier\fR (C and Objective\-C only)
! \&\fB\-Wenum\-compare\fR (in C/ObjC; this is on by default in C++)
! \&\fB\-Wenum\-int\-mismatch\fR (C and Objective\-C only)
  \&\fB\-Wformat
  \&\-Wformat\-overflow
  \&\-Wformat\-truncation
  \&\-Wint\-in\-bool\-context
! \&\-Wimplicit\fR (C and Objective\-C only)
! \&\fB\-Wimplicit\-int\fR (C and Objective\-C only)
! \&\fB\-Wimplicit\-function\-declaration\fR (C and Objective\-C only)
! \&\fB\-Winit\-self\fR (only for C++)
  \&\fB\-Wlogical\-not\-parentheses
  \&\-Wmain\fR (only for C/ObjC and unless\fB \fR\fB\-ffreestanding\fR)
  \&\fB\-Wmaybe\-uninitialized
  \&\-Wmemset\-elt\-size
  \&\-Wmemset\-transposed\-args
! \&\-Wmisleading\-indentation\fR (only for C/C++)
  \&\fB\-Wmismatched\-dealloc
! \&\-Wmismatched\-new\-delete\fR (only for C/C++)
  \&\fB\-Wmissing\-attributes
  \&\-Wmissing\-braces\fR (only for C/ObjC)
  \&\fB\-Wmultistatement\-macros
! \&\-Wnarrowing\fR (only for C++)
  \&\fB\-Wnonnull
  \&\-Wnonnull\-compare
  \&\-Wopenmp\-simd
  \&\-Wparentheses
! \&\-Wpessimizing\-move\fR (only for C++)
  \&\fB\-Wpointer\-sign
! \&\-Wrange\-loop\-construct\fR (only for C++)
  \&\fB\-Wreorder
  \&\-Wrestrict
  \&\-Wreturn\-type
! \&\-Wself\-move\fR (only for C++)
  \&\fB\-Wsequence\-point
! \&\-Wsign\-compare\fR (only in C++)
  \&\fB\-Wsizeof\-array\-div
  \&\-Wsizeof\-pointer\-div
  \&\-Wsizeof\-pointer\-memaccess
*************** Options\fR and \fBObjective-C and Object
*** 5853,5859 ****
  \&\-Wunused\-value
  \&\-Wunused\-variable
  \&\-Wuse\-after\-free=2
! \&\-Wvla\-parameter\fR (C and Objective-C only)
  \&\fB\-Wvolatile\-register\-var
  \&\-Wzero\-length\-bounds\fR
  .Sp
--- 5782,5788 ----
  \&\-Wunused\-value
  \&\-Wunused\-variable
  \&\-Wuse\-after\-free=2
! \&\-Wvla\-parameter\fR (C and Objective\-C only)
  \&\fB\-Wvolatile\-register\-var
  \&\-Wzero\-length\-bounds\fR
  .Sp
*************** others warn about constructions that are
*** 5864,5870 ****
  some cases, and there is no simple way to modify the code to suppress
  the warning. Some of them are enabled by \fB\-Wextra\fR but many of
  them must be enabled individually.
! .IP "\fB\-Wextra\fR" 4
  .IX Item "-Wextra"
  This enables some extra warning flags that are not enabled by
  \&\fB\-Wall\fR. (This option used to be called \fB\-W\fR.  The older
--- 5793,5799 ----
  some cases, and there is no simple way to modify the code to suppress
  the warning. Some of them are enabled by \fB\-Wextra\fR but many of
  them must be enabled individually.
! .IP \fB\-Wextra\fR 4
  .IX Item "-Wextra"
  This enables some extra warning flags that are not enabled by
  \&\fB\-Wall\fR. (This option used to be called \fB\-W\fR.  The older
*************** name is still supported, but the newer n
*** 5872,5879 ****
  .Sp
  \&\fB\-Wclobbered
  \&\-Wcast\-function\-type
! \&\-Wdangling\-reference\fR (\*(C+ only)
! \&\fB\-Wdeprecated\-copy\fR (\*(C+ only)
  \&\fB\-Wempty\-body
  \&\-Wenum\-conversion\fR (C only)
  \&\fB\-Wignored\-qualifiers
--- 5801,5808 ----
  .Sp
  \&\fB\-Wclobbered
  \&\-Wcast\-function\-type
! \&\-Wdangling\-reference\fR (C++ only)
! \&\fB\-Wdeprecated\-copy\fR (C++ only)
  \&\fB\-Wempty\-body
  \&\-Wenum\-conversion\fR (C only)
  \&\fB\-Wignored\-qualifiers
*************** name is still supported, but the newer n
*** 5884,5933 ****
  \&\fB\-Woverride\-init
  \&\-Wsign\-compare\fR (C only)
  \&\fB\-Wstring\-compare
! \&\-Wredundant\-move\fR (only for \*(C+)
  \&\fB\-Wtype\-limits
  \&\-Wuninitialized
! \&\-Wshift\-negative\-value\fR (in \*(C+11 to \*(C+17 and in C99 and newer)
  \&\fB\-Wunused\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)
  \&\fB\-Wunused\-but\-set\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)
  .Sp
  The option \fB\-Wextra\fR also prints warning messages for the
  following cases:
  .RS 4
! .IP "*" 4
  A pointer is compared against integer zero with \f(CW\*(C`<\*(C'\fR, \f(CW\*(C`<=\*(C'\fR,
  \&\f(CW\*(C`>\*(C'\fR, or \f(CW\*(C`>=\*(C'\fR.
! .IP "*" 4
! (\*(C+ only) An enumerator and a non-enumerator both appear in a
  conditional expression.
! .IP "*" 4
! (\*(C+ only) Ambiguous virtual bases.
! .IP "*" 4
! (\*(C+ only) Subscripting an array that has been declared \f(CW\*(C`register\*(C'\fR.
! .IP "*" 4
! (\*(C+ only) Taking the address of a variable that has been declared
  \&\f(CW\*(C`register\*(C'\fR.
! .IP "*" 4
! (\*(C+ only) A base class is not initialized in the copy constructor
  of a derived class.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wabi\fR (C, Objective-C, \*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wabi (C, Objective-C, and Objective- only)"
! Warn about code affected by \s-1ABI\s0 changes.  This includes code that may
! not be compatible with the vendor-neutral \*(C+ \s-1ABI\s0 as well as the psABI
  for the particular target.
  .Sp
! Since G++ now defaults to updating the \s-1ABI\s0 with each major release,
! normally \fB\-Wabi\fR warns only about \*(C+ \s-1ABI\s0 compatibility
  problems if there is a check added later in a release series for an
! \&\s-1ABI\s0 issue discovered since the initial release.  \fB\-Wabi\fR warns
! about more things if an older \s-1ABI\s0 version is selected (with
  \&\fB\-fabi\-version=\fR\fIn\fR).
  .Sp
  \&\fB\-Wabi\fR can also be used with an explicit version number to
! warn about \*(C+ \s-1ABI\s0 compatibility with a particular \fB\-fabi\-version\fR
  level, e.g. \fB\-Wabi=2\fR to warn about changes relative to
  \&\fB\-fabi\-version=2\fR.
  .Sp
--- 5813,5862 ----
  \&\fB\-Woverride\-init
  \&\-Wsign\-compare\fR (C only)
  \&\fB\-Wstring\-compare
! \&\-Wredundant\-move\fR (only for C++)
  \&\fB\-Wtype\-limits
  \&\-Wuninitialized
! \&\-Wshift\-negative\-value\fR (in C++11 to C++17 and in C99 and newer)
  \&\fB\-Wunused\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)
  \&\fB\-Wunused\-but\-set\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)
  .Sp
  The option \fB\-Wextra\fR also prints warning messages for the
  following cases:
  .RS 4
! .IP * 4
  A pointer is compared against integer zero with \f(CW\*(C`<\*(C'\fR, \f(CW\*(C`<=\*(C'\fR,
  \&\f(CW\*(C`>\*(C'\fR, or \f(CW\*(C`>=\*(C'\fR.
! .IP * 4
! (C++ only) An enumerator and a non\-enumerator both appear in a
  conditional expression.
! .IP * 4
! (C++ only) Ambiguous virtual bases.
! .IP * 4
! (C++ only) Subscripting an array that has been declared \f(CW\*(C`register\*(C'\fR.
! .IP * 4
! (C++ only) Taking the address of a variable that has been declared
  \&\f(CW\*(C`register\*(C'\fR.
! .IP * 4
! (C++ only) A base class is not initialized in the copy constructor
  of a derived class.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wabi\fR (C, Objective\-C, C++ and Objective\-C++ only)" 4
! .IX Item "-Wabi (C, Objective-C, C++ and Objective-C++ only)"
! Warn about code affected by ABI changes.  This includes code that may
! not be compatible with the vendor\-neutral C++ ABI as well as the psABI
  for the particular target.
  .Sp
! Since G++ now defaults to updating the ABI with each major release,
! normally \fB\-Wabi\fR warns only about C++ ABI compatibility
  problems if there is a check added later in a release series for an
! ABI issue discovered since the initial release.  \fB\-Wabi\fR warns
! about more things if an older ABI version is selected (with
  \&\fB\-fabi\-version=\fR\fIn\fR).
  .Sp
  \&\fB\-Wabi\fR can also be used with an explicit version number to
! warn about C++ ABI compatibility with a particular \fB\-fabi\-version\fR
  level, e.g. \fB\-Wabi=2\fR to warn about changes relative to
  \&\fB\-fabi\-version=2\fR.
  .Sp
*************** If an explicit version number is provide
*** 5936,5942 ****
  from this option is used for compatibility aliases.  If no explicit
  version number is provided with this option, but
  \&\fB\-fabi\-compat\-version\fR is specified, that version number is
! used for \*(C+ \s-1ABI\s0 warnings.
  .Sp
  Although an effort has been made to warn about
  all such cases, there are probably some cases that are not warned about,
--- 5865,5871 ----
  from this option is used for compatibility aliases.  If no explicit
  version number is provided with this option, but
  \&\fB\-fabi\-compat\-version\fR is specified, that version number is
! used for C++ ABI warnings.
  .Sp
  Although an effort has been made to warn about
  all such cases, there are probably some cases that are not warned about,
*************** concerned about the fact that code gener
*** 5949,5958 ****
  compatible with code generated by other compilers.
  .Sp
  Known incompatibilities in \fB\-fabi\-version=2\fR (which was the
! default from \s-1GCC 3.4\s0 to 4.9) include:
  .RS 4
! .IP "*" 4
! A template with a non-type template parameter of reference type was
  mangled incorrectly:
  .Sp
  .Vb 3
--- 5878,5887 ----
  compatible with code generated by other compilers.
  .Sp
  Known incompatibilities in \fB\-fabi\-version=2\fR (which was the
! default from GCC 3.4 to 4.9) include:
  .RS 4
! .IP * 4
! A template with a non\-type template parameter of reference type was
  mangled incorrectly:
  .Sp
  .Vb 3
*************** mangled incorrectly:
*** 5962,6022 ****
  .Ve
  .Sp
  This was fixed in \fB\-fabi\-version=3\fR.
! .IP "*" 4
! \&\s-1SIMD\s0 vector types declared using \f(CW\*(C`_\|_attribute ((vector_size))\*(C'\fR were
! mangled in a non-standard way that does not allow for overloading of
  functions taking vectors of different sizes.
  .Sp
  The mangling was changed in \fB\-fabi\-version=4\fR.
! .IP "*" 4
  \&\f(CW\*(C`_\|_attribute ((const))\*(C'\fR and \f(CW\*(C`noreturn\*(C'\fR were mangled as type
  qualifiers, and \f(CW\*(C`decltype\*(C'\fR of a plain declaration was folded away.
  .Sp
  These mangling issues were fixed in \fB\-fabi\-version=5\fR.
! .IP "*" 4
  Scoped enumerators passed as arguments to a variadic function are
  promoted like unscoped enumerators, causing \f(CW\*(C`va_arg\*(C'\fR to complain.
  On most targets this does not actually affect the parameter passing
! \&\s-1ABI,\s0 as there is no way to pass an argument smaller than \f(CW\*(C`int\*(C'\fR.
  .Sp
! Also, the \s-1ABI\s0 changed the mangling of template argument packs,
  \&\f(CW\*(C`const_cast\*(C'\fR, \f(CW\*(C`static_cast\*(C'\fR, prefix increment/decrement, and
  a class scope function used as a template argument.
  .Sp
  These issues were corrected in \fB\-fabi\-version=6\fR.
! .IP "*" 4
  Lambdas in default argument scope were mangled incorrectly, and the
! \&\s-1ABI\s0 changed the mangling of \f(CW\*(C`nullptr_t\*(C'\fR.
  .Sp
  These issues were corrected in \fB\-fabi\-version=7\fR.
! .IP "*" 4
! When mangling a function type with function-cv-qualifiers, the
! un-qualified function type was incorrectly treated as a substitution
  candidate.
  .Sp
! This was fixed in \fB\-fabi\-version=8\fR, the default for \s-1GCC 5.1.\s0
! .IP "*" 4
! \&\f(CW\*(C`decltype(nullptr)\*(C'\fR incorrectly had an alignment of 1, leading to
! unaligned accesses.  Note that this did not affect the \s-1ABI\s0 of a
  function with a \f(CW\*(C`nullptr_t\*(C'\fR parameter, as parameters have a
  minimum alignment.
  .Sp
! This was fixed in \fB\-fabi\-version=9\fR, the default for \s-1GCC 5.2.\s0
! .IP "*" 4
! Target-specific attributes that affect the identity of a type, such as
  ia32 calling conventions on a function type (stdcall, regparm, etc.),
  did not affect the mangled name, leading to name collisions when
  function pointers were used as template arguments.
  .Sp
! This was fixed in \fB\-fabi\-version=10\fR, the default for \s-1GCC 6.1.\s0
  .RE
  .RS 4
  .Sp
! This option also enables warnings about psABI-related changes.
  The known psABI changes at this point include:
! .IP "*" 4
  For SysV/x86\-64, unions with \f(CW\*(C`long double\*(C'\fR members are
! passed in memory as specified in psABI.  Prior to \s-1GCC 4.4,\s0 this was not
  the case.  For example:
  .Sp
  .Vb 4
--- 5891,5951 ----
  .Ve
  .Sp
  This was fixed in \fB\-fabi\-version=3\fR.
! .IP * 4
! SIMD vector types declared using \f(CW\*(C`_\|_attribute ((vector_size))\*(C'\fR were
! mangled in a non\-standard way that does not allow for overloading of
  functions taking vectors of different sizes.
  .Sp
  The mangling was changed in \fB\-fabi\-version=4\fR.
! .IP * 4
  \&\f(CW\*(C`_\|_attribute ((const))\*(C'\fR and \f(CW\*(C`noreturn\*(C'\fR were mangled as type
  qualifiers, and \f(CW\*(C`decltype\*(C'\fR of a plain declaration was folded away.
  .Sp
  These mangling issues were fixed in \fB\-fabi\-version=5\fR.
! .IP * 4
  Scoped enumerators passed as arguments to a variadic function are
  promoted like unscoped enumerators, causing \f(CW\*(C`va_arg\*(C'\fR to complain.
  On most targets this does not actually affect the parameter passing
! ABI, as there is no way to pass an argument smaller than \f(CW\*(C`int\*(C'\fR.
  .Sp
! Also, the ABI changed the mangling of template argument packs,
  \&\f(CW\*(C`const_cast\*(C'\fR, \f(CW\*(C`static_cast\*(C'\fR, prefix increment/decrement, and
  a class scope function used as a template argument.
  .Sp
  These issues were corrected in \fB\-fabi\-version=6\fR.
! .IP * 4
  Lambdas in default argument scope were mangled incorrectly, and the
! ABI changed the mangling of \f(CW\*(C`nullptr_t\*(C'\fR.
  .Sp
  These issues were corrected in \fB\-fabi\-version=7\fR.
! .IP * 4
! When mangling a function type with function\-cv\-qualifiers, the
! un\-qualified function type was incorrectly treated as a substitution
  candidate.
  .Sp
! This was fixed in \fB\-fabi\-version=8\fR, the default for GCC 5.1.
! .IP * 4
! \&\f(CWdecltype(nullptr)\fR incorrectly had an alignment of 1, leading to
! unaligned accesses.  Note that this did not affect the ABI of a
  function with a \f(CW\*(C`nullptr_t\*(C'\fR parameter, as parameters have a
  minimum alignment.
  .Sp
! This was fixed in \fB\-fabi\-version=9\fR, the default for GCC 5.2.
! .IP * 4
! Target\-specific attributes that affect the identity of a type, such as
  ia32 calling conventions on a function type (stdcall, regparm, etc.),
  did not affect the mangled name, leading to name collisions when
  function pointers were used as template arguments.
  .Sp
! This was fixed in \fB\-fabi\-version=10\fR, the default for GCC 6.1.
  .RE
  .RS 4
  .Sp
! This option also enables warnings about psABI\-related changes.
  The known psABI changes at this point include:
! .IP * 4
  For SysV/x86\-64, unions with \f(CW\*(C`long double\*(C'\fR members are
! passed in memory as specified in psABI.  Prior to GCC 4.4, this was not
  the case.  For example:
  .Sp
  .Vb 4
*************** the case.  For example:
*** 6030,6040 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wno\-changes\-meaning\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-changes-meaning ( and Objective- only)"
! \&\*(C+ requires that unqualified uses of a name within a class have the
  same meaning in the complete scope of the class, so declaring the name
! after using it is ill-formed:
  .Sp
  .Vb 3
  \&        struct A;
--- 5959,5969 ----
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wno\-changes\-meaning\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-changes-meaning (C++ and Objective-C++ only)"
! C++ requires that unqualified uses of a name within a class have the
  same meaning in the complete scope of the class, so declaring the name
! after using it is ill\-formed:
  .Sp
  .Vb 3
  \&        struct A;
*************** error case can be reduced to a warning w
*** 6049,6075 ****
  \&\fB\-Wno\-error=changes\-meaning\fR or \fB\-fpermissive\fR.
  .Sp
  Both diagnostics are also suppressed by \fB\-fms\-extensions\fR.
! .IP "\fB\-Wchar\-subscripts\fR" 4
  .IX Item "-Wchar-subscripts"
  Warn if an array subscript has type \f(CW\*(C`char\*(C'\fR.  This is a common cause
  of error, as programmers often forget that this type is signed on some
  machines.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-coverage\-mismatch\fR" 4
  .IX Item "-Wno-coverage-mismatch"
  Warn if feedback profiles do not match when using the
  \&\fB\-fprofile\-use\fR option.
  If a source file is changed between compiling with \fB\-fprofile\-generate\fR
  and with \fB\-fprofile\-use\fR, the files with the profile feedback can fail
! to match the source file and \s-1GCC\s0 cannot use the profile feedback
  information.  By default, this warning is enabled and is treated as an
  error.  \fB\-Wno\-coverage\-mismatch\fR can be used to disable the
  warning or \fB\-Wno\-error=coverage\-mismatch\fR can be used to
  disable the error.  Disabling the error for this warning can result in
  poorly optimized code and is useful only in the
! case of very minor changes such as bug fixes to an existing code-base.
  Completely disabling the warning is not recommended.
! .IP "\fB\-Wno\-coverage\-invalid\-line\-number\fR" 4
  .IX Item "-Wno-coverage-invalid-line-number"
  Warn in case a function ends earlier than it begins due
  to an invalid linenum macros.  The warning is emitted only
--- 5978,6004 ----
  \&\fB\-Wno\-error=changes\-meaning\fR or \fB\-fpermissive\fR.
  .Sp
  Both diagnostics are also suppressed by \fB\-fms\-extensions\fR.
! .IP \fB\-Wchar\-subscripts\fR 4
  .IX Item "-Wchar-subscripts"
  Warn if an array subscript has type \f(CW\*(C`char\*(C'\fR.  This is a common cause
  of error, as programmers often forget that this type is signed on some
  machines.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wno\-coverage\-mismatch\fR 4
  .IX Item "-Wno-coverage-mismatch"
  Warn if feedback profiles do not match when using the
  \&\fB\-fprofile\-use\fR option.
  If a source file is changed between compiling with \fB\-fprofile\-generate\fR
  and with \fB\-fprofile\-use\fR, the files with the profile feedback can fail
! to match the source file and GCC cannot use the profile feedback
  information.  By default, this warning is enabled and is treated as an
  error.  \fB\-Wno\-coverage\-mismatch\fR can be used to disable the
  warning or \fB\-Wno\-error=coverage\-mismatch\fR can be used to
  disable the error.  Disabling the error for this warning can result in
  poorly optimized code and is useful only in the
! case of very minor changes such as bug fixes to an existing code\-base.
  Completely disabling the warning is not recommended.
! .IP \fB\-Wno\-coverage\-invalid\-line\-number\fR 4
  .IX Item "-Wno-coverage-invalid-line-number"
  Warn in case a function ends earlier than it begins due
  to an invalid linenum macros.  The warning is emitted only
*************** By default, this warning is enabled and
*** 6079,6098 ****
  error.  \fB\-Wno\-coverage\-invalid\-line\-number\fR can be used to disable the
  warning or \fB\-Wno\-error=coverage\-invalid\-line\-number\fR can be used to
  disable the error.
! .IP "\fB\-Wno\-cpp\fR (C, Objective-C, \*(C+, Objective\-\*(C+ and Fortran only)" 4
! .IX Item "-Wno-cpp (C, Objective-C, , Objective- and Fortran only)"
  Suppress warning messages emitted by \f(CW\*(C`#warning\*(C'\fR directives.
! .IP "\fB\-Wdouble\-promotion\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wdouble-promotion (C, , Objective-C and Objective- only)"
  Give a warning when a value of type \f(CW\*(C`float\*(C'\fR is implicitly
! promoted to \f(CW\*(C`double\*(C'\fR.  CPUs with a 32\-bit \*(L"single-precision\*(R"
! floating-point unit implement \f(CW\*(C`float\*(C'\fR in hardware, but emulate
  \&\f(CW\*(C`double\*(C'\fR in software.  On such a machine, doing computations
  using \f(CW\*(C`double\*(C'\fR values is much more expensive because of the
  overhead required for software emulation.
  .Sp
  It is easy to accidentally do computations with \f(CW\*(C`double\*(C'\fR because
! floating-point literals are implicitly of type \f(CW\*(C`double\*(C'\fR.  For
  example, in:
  .Sp
  .Vb 4
--- 6008,6027 ----
  error.  \fB\-Wno\-coverage\-invalid\-line\-number\fR can be used to disable the
  warning or \fB\-Wno\-error=coverage\-invalid\-line\-number\fR can be used to
  disable the error.
! .IP "\fB\-Wno\-cpp\fR (C, Objective\-C, C++, Objective\-C++ and Fortran only)" 4
! .IX Item "-Wno-cpp (C, Objective-C, C++, Objective-C++ and Fortran only)"
  Suppress warning messages emitted by \f(CW\*(C`#warning\*(C'\fR directives.
! .IP "\fB\-Wdouble\-promotion\fR (C, C++, Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wdouble-promotion (C, C++, Objective-C and Objective-C++ only)"
  Give a warning when a value of type \f(CW\*(C`float\*(C'\fR is implicitly
! promoted to \f(CW\*(C`double\*(C'\fR.  CPUs with a 32\-bit "single\-precision"
! floating\-point unit implement \f(CW\*(C`float\*(C'\fR in hardware, but emulate
  \&\f(CW\*(C`double\*(C'\fR in software.  On such a machine, doing computations
  using \f(CW\*(C`double\*(C'\fR values is much more expensive because of the
  overhead required for software emulation.
  .Sp
  It is easy to accidentally do computations with \f(CW\*(C`double\*(C'\fR because
! floating\-point literals are implicitly of type \f(CW\*(C`double\*(C'\fR.  For
  example, in:
  .Sp
  .Vb 4
*************** example, in:
*** 6103,6118 ****
  .Ve
  .Sp
  the compiler performs the entire computation with \f(CW\*(C`double\*(C'\fR
! because the floating-point literal is a \f(CW\*(C`double\*(C'\fR.
! .IP "\fB\-Wduplicate\-decl\-specifier\fR (C and Objective-C only)" 4
  .IX Item "-Wduplicate-decl-specifier (C and Objective-C only)"
  Warn if a declaration has duplicate \f(CW\*(C`const\*(C'\fR, \f(CW\*(C`volatile\*(C'\fR,
  \&\f(CW\*(C`restrict\*(C'\fR or \f(CW\*(C`_Atomic\*(C'\fR specifier.  This warning is enabled by
  \&\fB\-Wall\fR.
! .IP "\fB\-Wformat\fR" 4
  .IX Item "-Wformat"
  .PD 0
! .IP "\fB\-Wformat=\fR\fIn\fR" 4
  .IX Item "-Wformat=n"
  .PD
  Check calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR, etc., to make sure that
--- 6032,6047 ----
  .Ve
  .Sp
  the compiler performs the entire computation with \f(CW\*(C`double\*(C'\fR
! because the floating\-point literal is a \f(CW\*(C`double\*(C'\fR.
! .IP "\fB\-Wduplicate\-decl\-specifier\fR (C and Objective\-C only)" 4
  .IX Item "-Wduplicate-decl-specifier (C and Objective-C only)"
  Warn if a declaration has duplicate \f(CW\*(C`const\*(C'\fR, \f(CW\*(C`volatile\*(C'\fR,
  \&\f(CW\*(C`restrict\*(C'\fR or \f(CW\*(C`_Atomic\*(C'\fR specifier.  This warning is enabled by
  \&\fB\-Wall\fR.
! .IP \fB\-Wformat\fR 4
  .IX Item "-Wformat"
  .PD 0
! .IP \fB\-Wformat=\fR\fIn\fR 4
  .IX Item "-Wformat=n"
  .PD
  Check calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR, etc., to make sure that
*************** specified, and that the conversions spec
*** 6121,6146 ****
  sense.  This includes standard functions, and others specified by format
  attributes, in the \f(CW\*(C`printf\*(C'\fR,
  \&\f(CW\*(C`scanf\*(C'\fR, \f(CW\*(C`strftime\*(C'\fR and \f(CW\*(C`strfmon\*(C'\fR (an X/Open extension,
! not in the C standard) families (or other target-specific families).
  Which functions are checked without format attributes having been
  specified depends on the standard version selected, and such checks of
  functions without the attribute specified are disabled by
  \&\fB\-ffreestanding\fR or \fB\-fno\-builtin\fR.
  .Sp
! The formats are checked against the format features supported by \s-1GNU\s0
! libc version 2.2.  These include all \s-1ISO C90\s0 and C99 features, as well
! as features from the Single Unix Specification and some \s-1BSD\s0 and \s-1GNU\s0
  extensions.  Other library implementations may not support all these
! features; \s-1GCC\s0 does not support warning about features that go beyond a
! particular library's limitations.  However, if \fB\-Wpedantic\fR is used
  with \fB\-Wformat\fR, warnings are given about format features not
  in the selected standard version (but not for \f(CW\*(C`strfmon\*(C'\fR formats,
  since those are not in any version of the C standard).
  .RS 4
! .IP "\fB\-Wformat=1\fR" 4
  .IX Item "-Wformat=1"
  .PD 0
! .IP "\fB\-Wformat\fR" 4
  .IX Item "-Wformat"
  .PD
  Option \fB\-Wformat\fR is equivalent to \fB\-Wformat=1\fR, and
--- 6050,6075 ----
  sense.  This includes standard functions, and others specified by format
  attributes, in the \f(CW\*(C`printf\*(C'\fR,
  \&\f(CW\*(C`scanf\*(C'\fR, \f(CW\*(C`strftime\*(C'\fR and \f(CW\*(C`strfmon\*(C'\fR (an X/Open extension,
! not in the C standard) families (or other target\-specific families).
  Which functions are checked without format attributes having been
  specified depends on the standard version selected, and such checks of
  functions without the attribute specified are disabled by
  \&\fB\-ffreestanding\fR or \fB\-fno\-builtin\fR.
  .Sp
! The formats are checked against the format features supported by 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\*(Aqs limitations.  However, if \fB\-Wpedantic\fR is used
  with \fB\-Wformat\fR, warnings are given about format features not
  in the selected standard version (but not for \f(CW\*(C`strfmon\*(C'\fR formats,
  since those are not in any version of the C standard).
  .RS 4
! .IP \fB\-Wformat=1\fR 4
  .IX Item "-Wformat=1"
  .PD 0
! .IP \fB\-Wformat\fR 4
  .IX Item "-Wformat"
  .PD
  Option \fB\-Wformat\fR is equivalent to \fB\-Wformat=1\fR, and
*************** aspects of this level of format checking
*** 6151,6157 ****
  options: \fB\-Wno\-format\-contains\-nul\fR,
  \&\fB\-Wno\-format\-extra\-args\fR, and \fB\-Wno\-format\-zero\-length\fR.
  \&\fB\-Wformat\fR is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wformat=2\fR" 4
  .IX Item "-Wformat=2"
  Enable \fB\-Wformat\fR plus additional format checks.  Currently
  equivalent to \fB\-Wformat \-Wformat\-nonliteral \-Wformat\-security
--- 6080,6086 ----
  options: \fB\-Wno\-format\-contains\-nul\fR,
  \&\fB\-Wno\-format\-extra\-args\fR, and \fB\-Wno\-format\-zero\-length\fR.
  \&\fB\-Wformat\fR is enabled by \fB\-Wall\fR.
! .IP \fB\-Wformat=2\fR 4
  .IX Item "-Wformat=2"
  Enable \fB\-Wformat\fR plus additional format checks.  Currently
  equivalent to \fB\-Wformat \-Wformat\-nonliteral \-Wformat\-security
*************** equivalent to \fB\-Wformat \-Wformat\-no
*** 6159,6169 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wno\-format\-contains\-nul\fR" 4
  .IX Item "-Wno-format-contains-nul"
  If \fB\-Wformat\fR is specified, do not warn about format strings that
! contain \s-1NUL\s0 bytes.
! .IP "\fB\-Wno\-format\-extra\-args\fR" 4
  .IX Item "-Wno-format-extra-args"
  If \fB\-Wformat\fR is specified, do not warn about excess arguments to a
  \&\f(CW\*(C`printf\*(C'\fR or \f(CW\*(C`scanf\*(C'\fR format function.  The C standard specifies
--- 6088,6098 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wno\-format\-contains\-nul\fR 4
  .IX Item "-Wno-format-contains-nul"
  If \fB\-Wformat\fR is specified, do not warn about format strings that
! contain NUL bytes.
! .IP \fB\-Wno\-format\-extra\-args\fR 4
  .IX Item "-Wno-format-extra-args"
  If \fB\-Wformat\fR is specified, do not warn about excess arguments to a
  \&\f(CW\*(C`printf\*(C'\fR or \f(CW\*(C`scanf\*(C'\fR format function.  The C standard specifies
*************** type to pass to \f(CW\*(C`va_arg\*(C'\fR
*** 6176,6199 ****
  in the case of \f(CW\*(C`scanf\*(C'\fR formats, this option suppresses the
  warning if the unused arguments are all pointers, since the Single
  Unix Specification says that such unused arguments are allowed.
! .IP "\fB\-Wformat\-overflow\fR" 4
  .IX Item "-Wformat-overflow"
  .PD 0
! .IP "\fB\-Wformat\-overflow=\fR\fIlevel\fR" 4
  .IX Item "-Wformat-overflow=level"
  .PD
  Warn about calls to formatted input/output functions such as \f(CW\*(C`sprintf\*(C'\fR
  and \f(CW\*(C`vsprintf\*(C'\fR that might overflow the destination buffer.  When the
  exact number of bytes written by a format directive cannot be determined
! at compile-time it is estimated based on heuristics that depend on the
  \&\fIlevel\fR argument and on optimization.  While enabling optimization
  will in most cases improve the accuracy of the warning, it may also
  result in false positives.
  .RS 4
! .IP "\fB\-Wformat\-overflow\fR" 4
  .IX Item "-Wformat-overflow"
  .PD 0
! .IP "\fB\-Wformat\-overflow=1\fR" 4
  .IX Item "-Wformat-overflow=1"
  .PD
  Level \fI1\fR of \fB\-Wformat\-overflow\fR enabled by \fB\-Wformat\fR
--- 6105,6128 ----
  in the case of \f(CW\*(C`scanf\*(C'\fR formats, this option suppresses the
  warning if the unused arguments are all pointers, since the Single
  Unix Specification says that such unused arguments are allowed.
! .IP \fB\-Wformat\-overflow\fR 4
  .IX Item "-Wformat-overflow"
  .PD 0
! .IP \fB\-Wformat\-overflow=\fR\fIlevel\fR 4
  .IX Item "-Wformat-overflow=level"
  .PD
  Warn about calls to formatted input/output functions such as \f(CW\*(C`sprintf\*(C'\fR
  and \f(CW\*(C`vsprintf\*(C'\fR that might overflow the destination buffer.  When the
  exact number of bytes written by a format directive cannot be determined
! at compile\-time it is estimated based on heuristics that depend on the
  \&\fIlevel\fR argument and on optimization.  While enabling optimization
  will in most cases improve the accuracy of the warning, it may also
  result in false positives.
  .RS 4
! .IP \fB\-Wformat\-overflow\fR 4
  .IX Item "-Wformat-overflow"
  .PD 0
! .IP \fB\-Wformat\-overflow=1\fR 4
  .IX Item "-Wformat-overflow=1"
  .PD
  Level \fI1\fR of \fB\-Wformat\-overflow\fR enabled by \fB\-Wformat\fR
*************** likely overflow the buffer.  At this lev
*** 6202,6212 ****
  directives with unknown values are assumed to have the value of one, and
  strings of unknown length to be empty.  Numeric arguments that are known
  to be bounded to a subrange of their type, or string arguments whose output
! is bounded either by their directive's precision or by a finite set of
  string literals, are assumed to take on the value within the range that
  results in the most bytes on output.  For example, the call to \f(CW\*(C`sprintf\*(C'\fR
  below is diagnosed because even with both \fIa\fR and \fIb\fR equal to zero,
! the terminating \s-1NUL\s0 character (\f(CW\*(Aq\e0\*(Aq\fR) appended by the function
  to the destination buffer will be written past its end.  Increasing
  the size of the buffer by a single byte is sufficient to avoid the
  warning, though it may not be sufficient to avoid the overflow.
--- 6131,6141 ----
  directives with unknown values are assumed to have the value of one, and
  strings of unknown length to be empty.  Numeric arguments that are known
  to be bounded to a subrange of their type, or string arguments whose output
! is bounded either by their directive\*(Aqs precision or by a finite set of
  string literals, are assumed to take on the value within the range that
  results in the most bytes on output.  For example, the call to \f(CW\*(C`sprintf\*(C'\fR
  below is diagnosed because even with both \fIa\fR and \fIb\fR equal to zero,
! the terminating NUL character (\f(CW\*(Aq\e0\*(Aq\fR) appended by the function
  to the destination buffer will be written past its end.  Increasing
  the size of the buffer by a single byte is sufficient to avoid the
  warning, though it may not be sufficient to avoid the overflow.
*************** warning, though it may not be sufficient
*** 6218,6231 ****
  \&          sprintf (buf, "a = %i, b = %i\en", a, b);
  \&        }
  .Ve
! .IP "\fB\-Wformat\-overflow=2\fR" 4
  .IX Item "-Wformat-overflow=2"
  Level \fI2\fR warns also about calls that might overflow the destination
  buffer given an argument of sufficient length or magnitude.  At level
  \&\fI2\fR, unknown numeric arguments are assumed to have the minimum
  representable value for signed types with a precision greater than 1, and
  the maximum representable value otherwise.  Unknown string arguments whose
! length cannot be assumed to be bounded either by the directive's precision,
  or by a finite set of string literals they may evaluate to, or the character
  array they may point to, are assumed to be 1 character long.
  .Sp
--- 6147,6160 ----
  \&          sprintf (buf, "a = %i, b = %i\en", a, b);
  \&        }
  .Ve
! .IP \fB\-Wformat\-overflow=2\fR 4
  .IX Item "-Wformat-overflow=2"
  Level \fI2\fR warns also about calls that might overflow the destination
  buffer given an argument of sufficient length or magnitude.  At level
  \&\fI2\fR, unknown numeric arguments are assumed to have the minimum
  representable value for signed types with a precision greater than 1, and
  the maximum representable value otherwise.  Unknown string arguments whose
! length cannot be assumed to be bounded either by the directive\*(Aqs precision,
  or by a finite set of string literals they may evaluate to, or the character
  array they may point to, are assumed to be 1 character long.
  .Sp
*************** this time because with \fIa\fR equal to
*** 6234,6240 ****
  \&\f(CW%i\fR directive will write some of its digits beyond the end of
  the destination buffer.  To make the call safe regardless of the values
  of the two variables, the size of the destination buffer must be increased
! to at least 34 bytes.  \s-1GCC\s0 includes the minimum size of the buffer in
  an informational note following the warning.
  .Sp
  An alternative to increasing the size of the destination buffer is to
--- 6163,6169 ----
  \&\f(CW%i\fR directive will write some of its digits beyond the end of
  the destination buffer.  To make the call safe regardless of the values
  of the two variables, the size of the destination buffer must be increased
! to at least 34 bytes.  GCC includes the minimum size of the buffer in
  an informational note following the warning.
  .Sp
  An alternative to increasing the size of the destination buffer is to
*************** required size of the buffer to 24 bytes.
*** 6259,6314 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wno\-format\-zero\-length\fR" 4
  .IX Item "-Wno-format-zero-length"
! If \fB\-Wformat\fR is specified, do not warn about zero-length formats.
! The C standard specifies that zero-length formats are allowed.
! .IP "\fB\-Wformat\-nonliteral\fR" 4
  .IX Item "-Wformat-nonliteral"
  If \fB\-Wformat\fR is specified, also warn if the format string is not a
  string literal and so cannot be checked, unless the format function
  takes its format arguments as a \f(CW\*(C`va_list\*(C'\fR.
! .IP "\fB\-Wformat\-security\fR" 4
  .IX Item "-Wformat-security"
  If \fB\-Wformat\fR is specified, also warn about uses of format
  functions that represent possible security problems.  At present, this
  warns about calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR functions where the
  format string is not a string literal and there are no format arguments,
  as in \f(CW\*(C`printf (foo);\*(C'\fR.  This may be a security hole if the format
! string came from untrusted input and contains \fB\f(CB%n\fB\fR.  (This is
  currently a subset of what \fB\-Wformat\-nonliteral\fR warns about, but
  in future warnings may be added to \fB\-Wformat\-security\fR that are not
  included in \fB\-Wformat\-nonliteral\fR.)
! .IP "\fB\-Wformat\-signedness\fR" 4
  .IX Item "-Wformat-signedness"
  If \fB\-Wformat\fR is specified, also warn if the format string
  requires an unsigned argument and the argument is signed and vice versa.
! .IP "\fB\-Wformat\-truncation\fR" 4
  .IX Item "-Wformat-truncation"
  .PD 0
! .IP "\fB\-Wformat\-truncation=\fR\fIlevel\fR" 4
  .IX Item "-Wformat-truncation=level"
  .PD
  Warn about calls to formatted input/output functions such as \f(CW\*(C`snprintf\*(C'\fR
  and \f(CW\*(C`vsnprintf\*(C'\fR that might result in output truncation.  When the exact
  number of bytes written by a format directive cannot be determined at
! compile-time it is estimated based on heuristics that depend on
  the \fIlevel\fR argument and on optimization.  While enabling optimization
  will in most cases improve the accuracy of the warning, it may also result
  in false positives.  Except as noted otherwise, the option uses the same
  logic \fB\-Wformat\-overflow\fR.
  .RS 4
! .IP "\fB\-Wformat\-truncation\fR" 4
  .IX Item "-Wformat-truncation"
  .PD 0
! .IP "\fB\-Wformat\-truncation=1\fR" 4
  .IX Item "-Wformat-truncation=1"
  .PD
  Level \fI1\fR of \fB\-Wformat\-truncation\fR enabled by \fB\-Wformat\fR
  employs a conservative approach that warns only about calls to bounded
  functions whose return value is unused and that will most likely result
  in output truncation.
! .IP "\fB\-Wformat\-truncation=2\fR" 4
  .IX Item "-Wformat-truncation=2"
  Level \fI2\fR warns also about calls to bounded functions whose return
  value is used and that might result in truncation given an argument of
--- 6188,6243 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wno\-format\-zero\-length\fR 4
  .IX Item "-Wno-format-zero-length"
! If \fB\-Wformat\fR is specified, do not warn about zero\-length formats.
! The C standard specifies that zero\-length formats are allowed.
! .IP \fB\-Wformat\-nonliteral\fR 4
  .IX Item "-Wformat-nonliteral"
  If \fB\-Wformat\fR is specified, also warn if the format string is not a
  string literal and so cannot be checked, unless the format function
  takes its format arguments as a \f(CW\*(C`va_list\*(C'\fR.
! .IP \fB\-Wformat\-security\fR 4
  .IX Item "-Wformat-security"
  If \fB\-Wformat\fR is specified, also warn about uses of format
  functions that represent possible security problems.  At present, this
  warns about calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR functions where the
  format string is not a string literal and there are no format arguments,
  as in \f(CW\*(C`printf (foo);\*(C'\fR.  This may be a security hole if the format
! string came from untrusted input and contains \fR\f(CB%n\fR\fB\fR.  (This is
  currently a subset of what \fB\-Wformat\-nonliteral\fR warns about, but
  in future warnings may be added to \fB\-Wformat\-security\fR that are not
  included in \fB\-Wformat\-nonliteral\fR.)
! .IP \fB\-Wformat\-signedness\fR 4
  .IX Item "-Wformat-signedness"
  If \fB\-Wformat\fR is specified, also warn if the format string
  requires an unsigned argument and the argument is signed and vice versa.
! .IP \fB\-Wformat\-truncation\fR 4
  .IX Item "-Wformat-truncation"
  .PD 0
! .IP \fB\-Wformat\-truncation=\fR\fIlevel\fR 4
  .IX Item "-Wformat-truncation=level"
  .PD
  Warn about calls to formatted input/output functions such as \f(CW\*(C`snprintf\*(C'\fR
  and \f(CW\*(C`vsnprintf\*(C'\fR that might result in output truncation.  When the exact
  number of bytes written by a format directive cannot be determined at
! compile\-time it is estimated based on heuristics that depend on
  the \fIlevel\fR argument and on optimization.  While enabling optimization
  will in most cases improve the accuracy of the warning, it may also result
  in false positives.  Except as noted otherwise, the option uses the same
  logic \fB\-Wformat\-overflow\fR.
  .RS 4
! .IP \fB\-Wformat\-truncation\fR 4
  .IX Item "-Wformat-truncation"
  .PD 0
! .IP \fB\-Wformat\-truncation=1\fR 4
  .IX Item "-Wformat-truncation=1"
  .PD
  Level \fI1\fR of \fB\-Wformat\-truncation\fR enabled by \fB\-Wformat\fR
  employs a conservative approach that warns only about calls to bounded
  functions whose return value is unused and that will most likely result
  in output truncation.
! .IP \fB\-Wformat\-truncation=2\fR 4
  .IX Item "-Wformat-truncation=2"
  Level \fI2\fR warns also about calls to bounded functions whose return
  value is used and that might result in truncation given an argument of
*************** sufficient length or magnitude.
*** 6316,6347 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wformat\-y2k\fR" 4
  .IX Item "-Wformat-y2k"
  If \fB\-Wformat\fR is specified, also warn about \f(CW\*(C`strftime\*(C'\fR
! formats that may yield only a two-digit year.
! .IP "\fB\-Wnonnull\fR" 4
  .IX Item "-Wnonnull"
  Warn about passing a null pointer for arguments marked as
! requiring a non-null value by the \f(CW\*(C`nonnull\*(C'\fR function attribute.
  .Sp
  \&\fB\-Wnonnull\fR is included in \fB\-Wall\fR and \fB\-Wformat\fR.  It
  can be disabled with the \fB\-Wno\-nonnull\fR option.
! .IP "\fB\-Wnonnull\-compare\fR" 4
  .IX Item "-Wnonnull-compare"
  Warn when comparing an argument marked with the \f(CW\*(C`nonnull\*(C'\fR
  function attribute against null inside the function.
  .Sp
  \&\fB\-Wnonnull\-compare\fR is included in \fB\-Wall\fR.  It
  can be disabled with the \fB\-Wno\-nonnull\-compare\fR option.
! .IP "\fB\-Wnull\-dereference\fR" 4
  .IX Item "-Wnull-dereference"
  Warn if the compiler detects paths that trigger erroneous or
  undefined behavior due to dereferencing a null pointer.  This option
  is only active when \fB\-fdelete\-null\-pointer\-checks\fR is active,
  which is enabled by optimizations in most targets.  The precision of
  the warnings depends on the optimization options used.
! .IP "\fB\-Winfinite\-recursion\fR" 4
  .IX Item "-Winfinite-recursion"
  Warn about infinitely recursive calls.  The warning is effective at all
  optimization levels but requires optimization in order to detect infinite
--- 6245,6276 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wformat\-y2k\fR 4
  .IX Item "-Wformat-y2k"
  If \fB\-Wformat\fR is specified, also warn about \f(CW\*(C`strftime\*(C'\fR
! formats that may yield only a two\-digit year.
! .IP \fB\-Wnonnull\fR 4
  .IX Item "-Wnonnull"
  Warn about passing a null pointer for arguments marked as
! requiring a non\-null value by the \f(CW\*(C`nonnull\*(C'\fR function attribute.
  .Sp
  \&\fB\-Wnonnull\fR is included in \fB\-Wall\fR and \fB\-Wformat\fR.  It
  can be disabled with the \fB\-Wno\-nonnull\fR option.
! .IP \fB\-Wnonnull\-compare\fR 4
  .IX Item "-Wnonnull-compare"
  Warn when comparing an argument marked with the \f(CW\*(C`nonnull\*(C'\fR
  function attribute against null inside the function.
  .Sp
  \&\fB\-Wnonnull\-compare\fR is included in \fB\-Wall\fR.  It
  can be disabled with the \fB\-Wno\-nonnull\-compare\fR option.
! .IP \fB\-Wnull\-dereference\fR 4
  .IX Item "-Wnull-dereference"
  Warn if the compiler detects paths that trigger erroneous or
  undefined behavior due to dereferencing a null pointer.  This option
  is only active when \fB\-fdelete\-null\-pointer\-checks\fR is active,
  which is enabled by optimizations in most targets.  The precision of
  the warnings depends on the optimization options used.
! .IP \fB\-Winfinite\-recursion\fR 4
  .IX Item "-Winfinite-recursion"
  Warn about infinitely recursive calls.  The warning is effective at all
  optimization levels but requires optimization in order to detect infinite
*************** recursion in calls between two or more f
*** 6351,6362 ****
  Compare with \fB\-Wanalyzer\-infinite\-recursion\fR which provides a
  similar diagnostic, but is implemented in a different way (as part of
  \&\fB\-fanalyzer\fR).
! .IP "\fB\-Winit\-self\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Winit-self (C, , Objective-C and Objective- only)"
  Warn about uninitialized variables that are initialized with themselves.
  Note this option can only be used with the \fB\-Wuninitialized\fR option.
  .Sp
! For example, \s-1GCC\s0 warns about \f(CW\*(C`i\*(C'\fR being uninitialized in the
  following snippet only when \fB\-Winit\-self\fR has been specified:
  .Sp
  .Vb 5
--- 6280,6291 ----
  Compare with \fB\-Wanalyzer\-infinite\-recursion\fR which provides a
  similar diagnostic, but is implemented in a different way (as part of
  \&\fB\-fanalyzer\fR).
! .IP "\fB\-Winit\-self\fR (C, C++, Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Winit-self (C, C++, Objective-C and Objective-C++ only)"
  Warn about uninitialized variables that are initialized with themselves.
  Note this option can only be used with the \fB\-Wuninitialized\fR option.
  .Sp
! For example, GCC warns about \f(CW\*(C`i\*(C'\fR being uninitialized in the
  following snippet only when \fB\-Winit\-self\fR has been specified:
  .Sp
  .Vb 5
*************** following snippet only when \fB\-Winit\-
*** 6367,6394 ****
  \&        }
  .Ve
  .Sp
! This warning is enabled by \fB\-Wall\fR in \*(C+.
! .IP "\fB\-Wno\-implicit\-int\fR (C and Objective-C only)" 4
  .IX Item "-Wno-implicit-int (C and Objective-C only)"
  This option controls warnings when a declaration does not specify a type.
  This warning is enabled by default in C99 and later dialects of C,
  and also by \fB\-Wall\fR.
! .IP "\fB\-Wno\-implicit\-function\-declaration\fR (C and Objective-C only)" 4
  .IX Item "-Wno-implicit-function-declaration (C and Objective-C only)"
  This option controls warnings when a function is used before being declared.
  This warning is enabled by default in C99 and later dialects of C,
  and also by \fB\-Wall\fR.
  The warning is made into an error by \fB\-pedantic\-errors\fR.
! .IP "\fB\-Wimplicit\fR (C and Objective-C only)" 4
  .IX Item "-Wimplicit (C and Objective-C only)"
  Same as \fB\-Wimplicit\-int\fR and \fB\-Wimplicit\-function\-declaration\fR.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wimplicit\-fallthrough\fR" 4
  .IX Item "-Wimplicit-fallthrough"
  \&\fB\-Wimplicit\-fallthrough\fR is the same as \fB\-Wimplicit\-fallthrough=3\fR
  and \fB\-Wno\-implicit\-fallthrough\fR is the same as
  \&\fB\-Wimplicit\-fallthrough=0\fR.
! .IP "\fB\-Wimplicit\-fallthrough=\fR\fIn\fR" 4
  .IX Item "-Wimplicit-fallthrough=n"
  Warn when a switch case falls through.  For example:
  .Sp
--- 6296,6323 ----
  \&        }
  .Ve
  .Sp
! This warning is enabled by \fB\-Wall\fR in C++.
! .IP "\fB\-Wno\-implicit\-int\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-implicit-int (C and Objective-C only)"
  This option controls warnings when a declaration does not specify a type.
  This warning is enabled by default in C99 and later dialects of C,
  and also by \fB\-Wall\fR.
! .IP "\fB\-Wno\-implicit\-function\-declaration\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-implicit-function-declaration (C and Objective-C only)"
  This option controls warnings when a function is used before being declared.
  This warning is enabled by default in C99 and later dialects of C,
  and also by \fB\-Wall\fR.
  The warning is made into an error by \fB\-pedantic\-errors\fR.
! .IP "\fB\-Wimplicit\fR (C and Objective\-C only)" 4
  .IX Item "-Wimplicit (C and Objective-C only)"
  Same as \fB\-Wimplicit\-int\fR and \fB\-Wimplicit\-function\-declaration\fR.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wimplicit\-fallthrough\fR 4
  .IX Item "-Wimplicit-fallthrough"
  \&\fB\-Wimplicit\-fallthrough\fR is the same as \fB\-Wimplicit\-fallthrough=3\fR
  and \fB\-Wno\-implicit\-fallthrough\fR is the same as
  \&\fB\-Wimplicit\-fallthrough=0\fR.
! .IP \fB\-Wimplicit\-fallthrough=\fR\fIn\fR 4
  .IX Item "-Wimplicit-fallthrough=n"
  Warn when a switch case falls through.  For example:
  .Sp
*************** warns when appropriate.  E.g.
*** 6429,6435 ****
  .Ve
  .Sp
  Since there are occasions where a switch case fall through is desirable,
! \&\s-1GCC\s0 provides an attribute, \f(CW\*(C`_\|_attribute_\|_ ((fallthrough))\*(C'\fR, that is
  to be used along with a null statement to suppress this warning that
  would normally occur:
  .Sp
--- 6358,6364 ----
  .Ve
  .Sp
  Since there are occasions where a switch case fall through is desirable,
! GCC provides an attribute, \f(CW\*(C`_\|_attribute_\|_ ((fallthrough))\*(C'\fR, that is
  to be used along with a null statement to suppress this warning that
  would normally occur:
  .Sp
*************** would normally occur:
*** 6444,6454 ****
  \&          }
  .Ve
  .Sp
! \&\*(C+17 provides a standard way to suppress the \fB\-Wimplicit\-fallthrough\fR
! warning using \f(CW\*(C`[[fallthrough]];\*(C'\fR instead of the \s-1GNU\s0 attribute.  In \*(C+11
! or \*(C+14 users can use \f(CW\*(C`[[gnu::fallthrough]];\*(C'\fR, which is a \s-1GNU\s0 extension.
  Instead of these attributes, it is also possible to add a fallthrough comment
! to silence the warning.  The whole body of the C or \*(C+ style comment should
  match the given regular expressions listed below.  The option argument \fIn\fR
  specifies what kind of comments are accepted:
  .RS 4
--- 6373,6383 ----
  \&          }
  .Ve
  .Sp
! C++17 provides a standard way to suppress the \fB\-Wimplicit\-fallthrough\fR
! warning using \f(CW\*(C`[[fallthrough]];\*(C'\fR instead of the GNU attribute.  In C++11
! or C++14 users can use \f(CW\*(C`[[gnu::fallthrough]];\*(C'\fR, which is a GNU extension.
  Instead of these attributes, it is also possible to add a fallthrough comment
! to silence the warning.  The whole body of the C or C++ style comment should
  match the given regular expressions listed below.  The option argument \fIn\fR
  specifies what kind of comments are accepted:
  .RS 4
*************** expression, any comment is used as fallt
*** 6468,6478 ****
  following regular expressions:
  .RS 4
  .ie n .IP "*<""\-fallthrough"">" 4
! .el .IP "*<\f(CW\-fallthrough\fR>" 4
  .IX Item "*<-fallthrough>"
  .PD 0
  .ie n .IP "*<""@fallthrough@"">" 4
! .el .IP "*<\f(CW@fallthrough@\fR>" 4
  .IX Item "*<@fallthrough@>"
  .ie n .IP "*<""lint \-fallthrough[ \et]*"">" 4
  .el .IP "*<\f(CWlint \-fallthrough[ \et]*\fR>" 4
--- 6397,6407 ----
  following regular expressions:
  .RS 4
  .ie n .IP "*<""\-fallthrough"">" 4
! .el .IP *<\f(CW\-fallthrough\fR> 4
  .IX Item "*<-fallthrough>"
  .PD 0
  .ie n .IP "*<""@fallthrough@"">" 4
! .el .IP *<\f(CW@fallthrough@\fR> 4
  .IX Item "*<@fallthrough@>"
  .ie n .IP "*<""lint \-fallthrough[ \et]*"">" 4
  .el .IP "*<\f(CWlint \-fallthrough[ \et]*\fR>" 4
*************** following regular expressions:
*** 6486,6505 ****
  .ie n .IP "*<""[ \et.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |\-)?thr(ough|u)[ \et.!]*(\-[^\en\er]*)?"">" 4
  .el .IP "*<\f(CW[ \et.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |\-)?thr(ough|u)[ \et.!]*(\-[^\en\er]*)?\fR>" 4
  .IX Item "*<[ t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |-)?thr(ough|u)[ t.!]*(-[^nr]*)?>"
  .RE
  .RS 4
  .RE
  .IP "*<\fB\-Wimplicit\-fallthrough=4\fR case sensitively matches one of the>" 4
  .IX Item "*<-Wimplicit-fallthrough=4 case sensitively matches one of the>"
- .PD
  following regular expressions:
  .RS 4
  .ie n .IP "*<""\-fallthrough"">" 4
! .el .IP "*<\f(CW\-fallthrough\fR>" 4
  .IX Item "*<-fallthrough>"
  .PD 0
  .ie n .IP "*<""@fallthrough@"">" 4
! .el .IP "*<\f(CW@fallthrough@\fR>" 4
  .IX Item "*<@fallthrough@>"
  .ie n .IP "*<""lint \-fallthrough[ \et]*"">" 4
  .el .IP "*<\f(CWlint \-fallthrough[ \et]*\fR>" 4
--- 6415,6434 ----
  .ie n .IP "*<""[ \et.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |\-)?thr(ough|u)[ \et.!]*(\-[^\en\er]*)?"">" 4
  .el .IP "*<\f(CW[ \et.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |\-)?thr(ough|u)[ \et.!]*(\-[^\en\er]*)?\fR>" 4
  .IX Item "*<[ t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?fall(s | |-)?thr(ough|u)[ t.!]*(-[^nr]*)?>"
+ .PD
  .RE
  .RS 4
  .RE
  .IP "*<\fB\-Wimplicit\-fallthrough=4\fR case sensitively matches one of the>" 4
  .IX Item "*<-Wimplicit-fallthrough=4 case sensitively matches one of the>"
  following regular expressions:
  .RS 4
  .ie n .IP "*<""\-fallthrough"">" 4
! .el .IP *<\f(CW\-fallthrough\fR> 4
  .IX Item "*<-fallthrough>"
  .PD 0
  .ie n .IP "*<""@fallthrough@"">" 4
! .el .IP *<\f(CW@fallthrough@\fR> 4
  .IX Item "*<@fallthrough@>"
  .ie n .IP "*<""lint \-fallthrough[ \et]*"">" 4
  .el .IP "*<\f(CWlint \-fallthrough[ \et]*\fR>" 4
*************** following regular expressions:
*** 6507,6518 ****
  .ie n .IP "*<""[ \et]*FALLTHR(OUGH|U)[ \et]*"">" 4
  .el .IP "*<\f(CW[ \et]*FALLTHR(OUGH|U)[ \et]*\fR>" 4
  .IX Item "*<[ t]*FALLTHR(OUGH|U)[ t]*>"
  .RE
  .RS 4
  .RE
! .IP "*<\fB\-Wimplicit\-fallthrough=5\fR doesn't recognize any comments as>" 4
  .IX Item "*<-Wimplicit-fallthrough=5 doesn't recognize any comments as>"
- .PD
  fallthrough comments, only attributes disable the warning.
  .RE
  .RS 4
--- 6436,6447 ----
  .ie n .IP "*<""[ \et]*FALLTHR(OUGH|U)[ \et]*"">" 4
  .el .IP "*<\f(CW[ \et]*FALLTHR(OUGH|U)[ \et]*\fR>" 4
  .IX Item "*<[ t]*FALLTHR(OUGH|U)[ t]*>"
+ .PD
  .RE
  .RS 4
  .RE
! .IP "*<\fB\-Wimplicit\-fallthrough=5\fR doesn\*(Aqt recognize any comments as>" 4
  .IX Item "*<-Wimplicit-fallthrough=5 doesn't recognize any comments as>"
  fallthrough comments, only attributes disable the warning.
  .RE
  .RS 4
*************** by \f(CW\*(C`case\*(C'\fR or \f(CW\*(C`d
*** 6534,6577 ****
  .Sp
  The \fB\-Wimplicit\-fallthrough=3\fR warning is enabled by \fB\-Wextra\fR.
  .RE
! .IP "\fB\-Wno\-if\-not\-aligned\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-if-not-aligned (C, , Objective-C and Objective- only)"
  Control if warnings triggered by the \f(CW\*(C`warn_if_not_aligned\*(C'\fR attribute
  should be issued.  These warnings are enabled by default.
! .IP "\fB\-Wignored\-qualifiers\fR (C and \*(C+ only)" 4
! .IX Item "-Wignored-qualifiers (C and only)"
  Warn if the return type of a function has a type qualifier
! such as \f(CW\*(C`const\*(C'\fR.  For \s-1ISO C\s0 such a type qualifier has no effect,
  since the value returned by a function is not an lvalue.
! For \*(C+, the warning is only emitted for scalar types or \f(CW\*(C`void\*(C'\fR.
! \&\s-1ISO C\s0 prohibits qualified \f(CW\*(C`void\*(C'\fR return types on function
  definitions, so such return types always receive a warning
  even without this option.
  .Sp
  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wno\-ignored\-attributes\fR (C and \*(C+ only)" 4
! .IX Item "-Wno-ignored-attributes (C and only)"
  This option controls warnings when an attribute is ignored.
  This is different from the
  \&\fB\-Wattributes\fR option in that it warns whenever the compiler decides
  to drop an attribute, not that the attribute is either unknown, used in a
  wrong place, etc.  This warning is enabled by default.
! .IP "\fB\-Wmain\fR" 4
  .IX Item "-Wmain"
  Warn if the type of \f(CW\*(C`main\*(C'\fR is suspicious.  \f(CW\*(C`main\*(C'\fR should be
  a function with external linkage, returning int, taking either zero
  arguments, two, or three arguments of appropriate types.  This warning
! is enabled by default in \*(C+ and is enabled by either \fB\-Wall\fR
  or \fB\-Wpedantic\fR.
! .IP "\fB\-Wmisleading\-indentation\fR (C and \*(C+ only)" 4
! .IX Item "-Wmisleading-indentation (C and only)"
  Warn when the indentation of the code does not reflect the block structure.
  Specifically, a warning is issued for \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR, \f(CW\*(C`while\*(C'\fR, and
  \&\f(CW\*(C`for\*(C'\fR clauses with a guarded statement that does not use braces,
  followed by an unguarded statement with the same indentation.
  .Sp
! In the following example, the call to \*(L"bar\*(R" is misleadingly indented as
! if it were guarded by the \*(L"if\*(R" conditional.
  .Sp
  .Vb 3
  \&          if (some_condition ())
--- 6463,6506 ----
  .Sp
  The \fB\-Wimplicit\-fallthrough=3\fR warning is enabled by \fB\-Wextra\fR.
  .RE
! .IP "\fB\-Wno\-if\-not\-aligned\fR (C, C++, Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wno-if-not-aligned (C, C++, Objective-C and Objective-C++ only)"
  Control if warnings triggered by the \f(CW\*(C`warn_if_not_aligned\*(C'\fR attribute
  should be issued.  These warnings are enabled by default.
! .IP "\fB\-Wignored\-qualifiers\fR (C and C++ only)" 4
! .IX Item "-Wignored-qualifiers (C and C++ only)"
  Warn if the return type of a function has a type qualifier
! such as \f(CW\*(C`const\*(C'\fR.  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 \f(CW\*(C`void\*(C'\fR.
! ISO C prohibits qualified \f(CW\*(C`void\*(C'\fR return types on function
  definitions, so such return types always receive a warning
  even without this option.
  .Sp
  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wno\-ignored\-attributes\fR (C and C++ only)" 4
! .IX Item "-Wno-ignored-attributes (C and C++ only)"
  This option controls warnings when an attribute is ignored.
  This is different from the
  \&\fB\-Wattributes\fR option in that it warns whenever the compiler decides
  to drop an attribute, not that the attribute is either unknown, used in a
  wrong place, etc.  This warning is enabled by default.
! .IP \fB\-Wmain\fR 4
  .IX Item "-Wmain"
  Warn if the type of \f(CW\*(C`main\*(C'\fR is suspicious.  \f(CW\*(C`main\*(C'\fR should be
  a function with external linkage, returning int, taking either zero
  arguments, two, or three arguments of appropriate types.  This warning
! is enabled by default in C++ and is enabled by either \fB\-Wall\fR
  or \fB\-Wpedantic\fR.
! .IP "\fB\-Wmisleading\-indentation\fR (C and C++ only)" 4
! .IX Item "-Wmisleading-indentation (C and C++ only)"
  Warn when the indentation of the code does not reflect the block structure.
  Specifically, a warning is issued for \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR, \f(CW\*(C`while\*(C'\fR, and
  \&\f(CW\*(C`for\*(C'\fR clauses with a guarded statement that does not use braces,
  followed by an unguarded statement with the same indentation.
  .Sp
! In the following example, the call to "bar" is misleadingly indented as
! if it were guarded by the "if" conditional.
  .Sp
  .Vb 3
  \&          if (some_condition ())
*************** The warning is not issued after a \f(CW\
*** 6599,6606 ****
  typically indicates autogenerated code, and no assumptions can be made
  about the layout of the file that the directive references.
  .Sp
! This warning is enabled by \fB\-Wall\fR in C and \*(C+.
! .IP "\fB\-Wmissing\-attributes\fR" 4
  .IX Item "-Wmissing-attributes"
  Warn when a declaration of a function is missing one or more attributes
  that a related function is declared with and whose absence may adversely
--- 6528,6535 ----
  typically indicates autogenerated code, and no assumptions can be made
  about the layout of the file that the directive references.
  .Sp
! This warning is enabled by \fB\-Wall\fR in C and C++.
! .IP \fB\-Wmissing\-attributes\fR 4
  .IX Item "-Wmissing-attributes"
  Warn when a declaration of a function is missing one or more attributes
  that a related function is declared with and whose absence may adversely
*************** Attributes considered include \f(CW\*(C`
*** 6616,6622 ****
  \&\f(CW\*(C`nonnull\*(C'\fR, \f(CW\*(C`noreturn\*(C'\fR, \f(CW\*(C`nothrow\*(C'\fR, \f(CW\*(C`pure\*(C'\fR,
  \&\f(CW\*(C`returns_nonnull\*(C'\fR, and \f(CW\*(C`returns_twice\*(C'\fR.
  .Sp
! In \*(C+, the warning is issued when an explicit specialization of a primary
  template declared with attribute \f(CW\*(C`alloc_align\*(C'\fR, \f(CW\*(C`alloc_size\*(C'\fR,
  \&\f(CW\*(C`assume_aligned\*(C'\fR, \f(CW\*(C`format\*(C'\fR, \f(CW\*(C`format_arg\*(C'\fR, \f(CW\*(C`malloc\*(C'\fR,
  or \f(CW\*(C`nonnull\*(C'\fR is declared without it.  Attributes \f(CW\*(C`deprecated\*(C'\fR,
--- 6545,6551 ----
  \&\f(CW\*(C`nonnull\*(C'\fR, \f(CW\*(C`noreturn\*(C'\fR, \f(CW\*(C`nothrow\*(C'\fR, \f(CW\*(C`pure\*(C'\fR,
  \&\f(CW\*(C`returns_nonnull\*(C'\fR, and \f(CW\*(C`returns_twice\*(C'\fR.
  .Sp
! In C++, the warning is issued when an explicit specialization of a primary
  template declared with attribute \f(CW\*(C`alloc_align\*(C'\fR, \f(CW\*(C`alloc_size\*(C'\fR,
  \&\f(CW\*(C`assume_aligned\*(C'\fR, \f(CW\*(C`format\*(C'\fR, \f(CW\*(C`format_arg\*(C'\fR, \f(CW\*(C`malloc\*(C'\fR,
  or \f(CW\*(C`nonnull\*(C'\fR is declared without it.  Attributes \f(CW\*(C`deprecated\*(C'\fR,
*************** diagnosed because it is missing one of t
*** 6644,6650 ****
  \&        void* _\|_attribute_\|_ ((malloc))   // missing alloc_size
  \&        allocate (size_t);
  .Ve
! .IP "\fB\-Wmissing\-braces\fR" 4
  .IX Item "-Wmissing-braces"
  Warn if an aggregate or union initializer is not fully bracketed.  In
  the following example, the initializer for \f(CW\*(C`a\*(C'\fR is not fully
--- 6573,6579 ----
  \&        void* _\|_attribute_\|_ ((malloc))   // missing alloc_size
  \&        allocate (size_t);
  .Ve
! .IP \fB\-Wmissing\-braces\fR 4
  .IX Item "-Wmissing-braces"
  Warn if an aggregate or union initializer is not fully bracketed.  In
  the following example, the initializer for \f(CW\*(C`a\*(C'\fR is not fully
*************** bracketed, but that for \f(CW\*(C`b\*(C'
*** 6656,6667 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wmissing\-include\-dirs\fR (C, \*(C+, Objective-C, Objective\-\*(C+ and Fortran only)" 4
! .IX Item "-Wmissing-include-dirs (C, , Objective-C, Objective- and Fortran only)"
! Warn if a user-supplied include directory does not exist. This option is disabled
! by default for C, \*(C+, Objective-C and Objective\-\*(C+. For Fortran, it is partially
  enabled by default by warning for \-I and \-J, only.
! .IP "\fB\-Wno\-missing\-profile\fR" 4
  .IX Item "-Wno-missing-profile"
  This option controls warnings if feedback profiles are missing when using the
  \&\fB\-fprofile\-use\fR option.
--- 6585,6596 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wmissing\-include\-dirs\fR (C, C++, Objective\-C, Objective\-C++ and Fortran only)" 4
! .IX Item "-Wmissing-include-dirs (C, C++, Objective-C, Objective-C++ and Fortran only)"
! Warn if a user\-supplied include directory does not exist. This option is disabled
! by default for C, C++, Objective\-C and Objective\-C++. For Fortran, it is partially
  enabled by default by warning for \-I and \-J, only.
! .IP \fB\-Wno\-missing\-profile\fR 4
  .IX Item "-Wno-missing-profile"
  This option controls warnings if feedback profiles are missing when using the
  \&\fB\-fprofile\-use\fR option.
*************** between compiling with \fB\-fprofile\-ge
*** 6671,6692 ****
  In these cases, the profile feedback data files do not contain any
  profile feedback information for
  the newly added function or file respectively.  Also, in the case when profile
! count data (.gcda) files are removed, \s-1GCC\s0 cannot use any profile feedback
  information.  In all these cases, warnings are issued to inform you that a
  profile generation step is due.
  Ignoring the warning can result in poorly optimized code.
  \&\fB\-Wno\-missing\-profile\fR can be used to
  disable the warning, but this is not recommended and should be done only
! when non-existent profile data is justified.
! .IP "\fB\-Wmismatched\-dealloc\fR" 4
  .IX Item "-Wmismatched-dealloc"
  Warn for calls to deallocation functions with pointer arguments returned
! from from allocations functions for which the former isn't a suitable
  deallocator.  A pair of functions can be associated as matching allocators
  and deallocators by use of attribute \f(CW\*(C`malloc\*(C'\fR.  Unless disabled by
  the \fB\-fno\-builtin\fR option the standard functions \f(CW\*(C`calloc\*(C'\fR,
  \&\f(CW\*(C`malloc\*(C'\fR, \f(CW\*(C`realloc\*(C'\fR, and \f(CW\*(C`free\*(C'\fR, as well as the corresponding
! forms of \*(C+ \f(CW\*(C`operator new\*(C'\fR and \f(CW\*(C`operator delete\*(C'\fR are implicitly
  associated as matching allocators and deallocators.  In the following
  example \f(CW\*(C`mydealloc\*(C'\fR is the deallocator for pointers returned from
  \&\f(CW\*(C`myalloc\*(C'\fR.
--- 6600,6621 ----
  In these cases, the profile feedback data files do not contain any
  profile feedback information for
  the newly added function or file respectively.  Also, in the case when profile
! count data (.gcda) files are removed, GCC cannot use any profile feedback
  information.  In all these cases, warnings are issued to inform you that a
  profile generation step is due.
  Ignoring the warning can result in poorly optimized code.
  \&\fB\-Wno\-missing\-profile\fR can be used to
  disable the warning, but this is not recommended and should be done only
! when non\-existent profile data is justified.
! .IP \fB\-Wmismatched\-dealloc\fR 4
  .IX Item "-Wmismatched-dealloc"
  Warn for calls to deallocation functions with pointer arguments returned
! from from allocations functions for which the former isn\*(Aqt a suitable
  deallocator.  A pair of functions can be associated as matching allocators
  and deallocators by use of attribute \f(CW\*(C`malloc\*(C'\fR.  Unless disabled by
  the \fB\-fno\-builtin\fR option the standard functions \f(CW\*(C`calloc\*(C'\fR,
  \&\f(CW\*(C`malloc\*(C'\fR, \f(CW\*(C`realloc\*(C'\fR, and \f(CW\*(C`free\*(C'\fR, as well as the corresponding
! forms of C++ \f(CW\*(C`operator new\*(C'\fR and \f(CW\*(C`operator delete\*(C'\fR are implicitly
  associated as matching allocators and deallocators.  In the following
  example \f(CW\*(C`mydealloc\*(C'\fR is the deallocator for pointers returned from
  \&\f(CW\*(C`myalloc\*(C'\fR.
*************** example \f(CW\*(C`mydealloc\*(C'\fR is t
*** 6706,6716 ****
  \&        }
  .Ve
  .Sp
! In \*(C+, the related option \fB\-Wmismatched\-new\-delete\fR diagnoses
  mismatches involving either \f(CW\*(C`operator new\*(C'\fR or \f(CW\*(C`operator delete\*(C'\fR.
  .Sp
  Option \fB\-Wmismatched\-dealloc\fR is included in \fB\-Wall\fR.
! .IP "\fB\-Wmultistatement\-macros\fR" 4
  .IX Item "-Wmultistatement-macros"
  Warn about unsafe multiple statement macros that appear to be guarded
  by a clause such as \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR, \f(CW\*(C`for\*(C'\fR, \f(CW\*(C`switch\*(C'\fR, or
--- 6635,6645 ----
  \&        }
  .Ve
  .Sp
! In C++, the related option \fB\-Wmismatched\-new\-delete\fR diagnoses
  mismatches involving either \f(CW\*(C`operator new\*(C'\fR or \f(CW\*(C`operator delete\*(C'\fR.
  .Sp
  Option \fB\-Wmismatched\-dealloc\fR is included in \fB\-Wall\fR.
! .IP \fB\-Wmultistatement\-macros\fR 4
  .IX Item "-Wmultistatement-macros"
  Warn about unsafe multiple statement macros that appear to be guarded
  by a clause such as \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR, \f(CW\*(C`for\*(C'\fR, \f(CW\*(C`switch\*(C'\fR, or
*************** For example:
*** 6726,6732 ****
  .Ve
  .Sp
  will increment \f(CW\*(C`y\*(C'\fR unconditionally, not just when \f(CW\*(C`c\*(C'\fR holds.
! The can usually be fixed by wrapping the macro in a do-while loop:
  .Sp
  .Vb 3
  \&        #define DOIT do { x++; y++; } while (0)
--- 6655,6661 ----
  .Ve
  .Sp
  will increment \f(CW\*(C`y\*(C'\fR unconditionally, not just when \f(CW\*(C`c\*(C'\fR holds.
! The can usually be fixed by wrapping the macro in a do\-while loop:
  .Sp
  .Vb 3
  \&        #define DOIT do { x++; y++; } while (0)
*************** The can usually be fixed by wrapping the
*** 6734,6741 ****
  \&          DOIT;
  .Ve
  .Sp
! This warning is enabled by \fB\-Wall\fR in C and \*(C+.
! .IP "\fB\-Wparentheses\fR" 4
  .IX Item "-Wparentheses"
  Warn if parentheses are omitted in certain contexts, such
  as when there is an assignment in a context where a truth value
--- 6663,6670 ----
  \&          DOIT;
  .Ve
  .Sp
! This warning is enabled by \fB\-Wall\fR in C and C++.
! .IP \fB\-Wparentheses\fR 4
  .IX Item "-Wparentheses"
  Warn if parentheses are omitted in certain contexts, such
  as when there is an assignment in a context where a truth value
*************** Also warn if a comparison like \f(CW\*(C
*** 6746,6758 ****
  equivalent to \f(CW\*(C`(x<=y ? 1 : 0) <= z\*(C'\fR, which is a different
  interpretation from that of ordinary mathematical notation.
  .Sp
! Also warn for dangerous uses of the \s-1GNU\s0 extension to
  \&\f(CW\*(C`?:\*(C'\fR with omitted middle operand. When the condition
  in the \f(CW\*(C`?\*(C'\fR: operator is a boolean expression, the omitted value is
  always 1.  Often programmers expect it to be a value computed
  inside the conditional expression instead.
  .Sp
! For \*(C+ this also warns for some cases of unnecessary parentheses in
  declarations, which can indicate an attempt at a function call instead
  of a declaration:
  .Sp
--- 6675,6687 ----
  equivalent to \f(CW\*(C`(x<=y ? 1 : 0) <= z\*(C'\fR, which is a different
  interpretation from that of ordinary mathematical notation.
  .Sp
! Also warn for dangerous uses of the GNU extension to
  \&\f(CW\*(C`?:\*(C'\fR with omitted middle operand. When the condition
  in the \f(CW\*(C`?\*(C'\fR: operator is a boolean expression, the omitted value is
  always 1.  Often programmers expect it to be a value computed
  inside the conditional expression instead.
  .Sp
! For C++ this also warns for some cases of unnecessary parentheses in
  declarations, which can indicate an attempt at a function call instead
  of a declaration:
  .Sp
*************** of a declaration:
*** 6765,6772 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-self\-move\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-self-move ( and Objective- only)"
  This warning warns when a value is moved to itself with \f(CW\*(C`std::move\*(C'\fR.
  Such a \f(CW\*(C`std::move\*(C'\fR typically has no effect.
  .Sp
--- 6694,6701 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-self\-move\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-self-move (C++ and Objective-C++ only)"
  This warning warns when a value is moved to itself with \f(CW\*(C`std::move\*(C'\fR.
  Such a \f(CW\*(C`std::move\*(C'\fR typically has no effect.
  .Sp
*************** Such a \f(CW\*(C`std::move\*(C'\fR typic
*** 6783,6794 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wsequence\-point\fR" 4
  .IX Item "-Wsequence-point"
  Warn about code that may have undefined semantics because of violations
! of sequence point rules in the C and \*(C+ standards.
  .Sp
! The C and \*(C+ standards define the order in which expressions in a C/\*(C+
  program are evaluated in terms of \fIsequence points\fR, which represent
  a partial ordering between the execution of parts of the program: those
  executed before the sequence point, and those executed after it.  These
--- 6712,6723 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wsequence\-point\fR 4
  .IX Item "-Wsequence-point"
  Warn about code that may have undefined semantics because of violations
! of sequence point rules in the C and C++ standards.
  .Sp
! The C and C++ standards define the order in which expressions in a C/C++
  program are evaluated in terms of \fIsequence points\fR, which represent
  a partial ordering between the execution of parts of the program: those
  executed before the sequence point, and those executed after it.  These
*************** ruled that function calls do not overlap
*** 6807,6817 ****
  .Sp
  It is not specified when between sequence points modifications to the
  values of objects take effect.  Programs whose behavior depends on this
! have undefined behavior; the C and \*(C+ standards specify that \*(L"Between
  the previous and next sequence point an object shall have its stored
  value modified at most once by the evaluation of an expression.
  Furthermore, the prior value shall be read only to determine the value
! to be stored.\*(R".  If a program breaks these rules, the results on any
  particular implementation are entirely unpredictable.
  .Sp
  Examples of code with undefined behavior are \f(CW\*(C`a = a++;\*(C'\fR, \f(CW\*(C`a[n]
--- 6736,6746 ----
  .Sp
  It is not specified when between sequence points modifications to the
  values of objects take effect.  Programs whose behavior depends on this
! have undefined behavior; the C and C++ standards specify that "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.
  .Sp
  Examples of code with undefined behavior are \f(CW\*(C`a = a++;\*(C'\fR, \f(CW\*(C`a[n]
*************** diagnosed by this option, and it may giv
*** 6820,6844 ****
  result, but in general it has been found fairly effective at detecting
  this sort of problem in programs.
  .Sp
! The \*(C+17 standard will define the order of evaluation of operands in
! more cases: in particular it requires that the right-hand side of an
! assignment be evaluated before the left-hand side, so the above
  examples are no longer undefined.  But this option will still warn
  about them, to help people avoid writing code that is undefined in C
! and earlier revisions of \*(C+.
  .Sp
  The standard is worded confusingly, therefore there is some debate
  over the precise meaning of the sequence point rules in subtle cases.
  Links to discussions of the problem, including proposed formal
! definitions, may be found on the \s-1GCC\s0 readings page, at
  <\fBhttps://gcc.gnu.org/readings.html\fR>.
  .Sp
! This warning is enabled by \fB\-Wall\fR for C and \*(C+.
! .IP "\fB\-Wno\-return\-local\-addr\fR" 4
  .IX Item "-Wno-return-local-addr"
! Do not warn about returning a pointer (or in \*(C+, a reference) to a
  variable that goes out of scope after the function returns.
! .IP "\fB\-Wreturn\-type\fR" 4
  .IX Item "-Wreturn-type"
  Warn whenever a function is defined with a return type that defaults
  to \f(CW\*(C`int\*(C'\fR.  Also warn about any \f(CW\*(C`return\*(C'\fR statement with no
--- 6749,6773 ----
  result, but in general it has been found fairly effective at detecting
  this sort of problem in programs.
  .Sp
! The C++17 standard will define the order of evaluation of operands in
! more cases: in particular it requires that the right\-hand side of an
! assignment be evaluated before the left\-hand side, so the above
  examples are no longer undefined.  But this option will still warn
  about them, to help people avoid writing code that is undefined in C
! and earlier revisions of C++.
  .Sp
  The standard is worded confusingly, therefore there is some debate
  over the precise meaning of the sequence point rules in subtle cases.
  Links to discussions of the problem, including proposed formal
! definitions, may be found on the GCC readings page, at
  <\fBhttps://gcc.gnu.org/readings.html\fR>.
  .Sp
! This warning is enabled by \fB\-Wall\fR for C and C++.
! .IP \fB\-Wno\-return\-local\-addr\fR 4
  .IX Item "-Wno-return-local-addr"
! Do not warn about returning a pointer (or in C++, a reference) to a
  variable that goes out of scope after the function returns.
! .IP \fB\-Wreturn\-type\fR 4
  .IX Item "-Wreturn-type"
  Warn whenever a function is defined with a return type that defaults
  to \f(CW\*(C`int\*(C'\fR.  Also warn about any \f(CW\*(C`return\*(C'\fR statement with no
*************** without a value).
*** 6848,6900 ****
  .Sp
  For C only, warn about a \f(CW\*(C`return\*(C'\fR statement with an expression in a
  function whose return type is \f(CW\*(C`void\*(C'\fR, unless the expression type is
! also \f(CW\*(C`void\*(C'\fR.  As a \s-1GNU\s0 extension, the latter case is accepted
  without a warning unless \fB\-Wpedantic\fR is used.  Attempting
  to use the return value of a non\-\f(CW\*(C`void\*(C'\fR function other than \f(CW\*(C`main\*(C'\fR
  that flows off the end by reaching the closing curly brace that terminates
  the function is undefined.
  .Sp
! Unlike in C, in \*(C+, flowing off the end of a non\-\f(CW\*(C`void\*(C'\fR function other
  than \f(CW\*(C`main\*(C'\fR results in undefined behavior even when the value of
  the function is not used.
  .Sp
! This warning is enabled by default in \*(C+ and by \fB\-Wall\fR otherwise.
! .IP "\fB\-Wno\-shift\-count\-negative\fR" 4
  .IX Item "-Wno-shift-count-negative"
  Controls warnings if a shift count is negative.
  This warning is enabled by default.
! .IP "\fB\-Wno\-shift\-count\-overflow\fR" 4
  .IX Item "-Wno-shift-count-overflow"
  Controls warnings if a shift count is greater than or equal to the bit width
  of the type.  This warning is enabled by default.
! .IP "\fB\-Wshift\-negative\-value\fR" 4
  .IX Item "-Wshift-negative-value"
  Warn if left shifting a negative value.  This warning is enabled by
! \&\fB\-Wextra\fR in C99 (and newer) and \*(C+11 to \*(C+17 modes.
! .IP "\fB\-Wno\-shift\-overflow\fR" 4
  .IX Item "-Wno-shift-overflow"
  .PD 0
! .IP "\fB\-Wshift\-overflow=\fR\fIn\fR" 4
  .IX Item "-Wshift-overflow=n"
  .PD
  These options control warnings about left shift overflows.
  .RS 4
! .IP "\fB\-Wshift\-overflow=1\fR" 4
  .IX Item "-Wshift-overflow=1"
  This is the warning level of \fB\-Wshift\-overflow\fR and is enabled
! by default in C99 and \*(C+11 modes (and newer).  This warning level does
! not warn about left-shifting 1 into the sign bit.  (However, in C, such
  an overflow is still rejected in contexts where an integer constant expression
! is required.)  No warning is emitted in \*(C+20 mode (and newer), as signed left
  shifts always wrap.
! .IP "\fB\-Wshift\-overflow=2\fR" 4
  .IX Item "-Wshift-overflow=2"
! This warning level also warns about left-shifting 1 into the sign bit,
! unless \*(C+14 mode (or newer) is active.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wswitch\fR" 4
  .IX Item "-Wswitch"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
  and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
--- 6777,6829 ----
  .Sp
  For C only, warn about a \f(CW\*(C`return\*(C'\fR statement with an expression in a
  function whose return type is \f(CW\*(C`void\*(C'\fR, unless the expression type is
! also \f(CW\*(C`void\*(C'\fR.  As a GNU extension, the latter case is accepted
  without a warning unless \fB\-Wpedantic\fR is used.  Attempting
  to use the return value of a non\-\f(CW\*(C`void\*(C'\fR function other than \f(CW\*(C`main\*(C'\fR
  that flows off the end by reaching the closing curly brace that terminates
  the function is undefined.
  .Sp
! Unlike in C, in C++, flowing off the end of a non\-\f(CW\*(C`void\*(C'\fR function other
  than \f(CW\*(C`main\*(C'\fR results in undefined behavior even when the value of
  the function is not used.
  .Sp
! This warning is enabled by default in C++ and by \fB\-Wall\fR otherwise.
! .IP \fB\-Wno\-shift\-count\-negative\fR 4
  .IX Item "-Wno-shift-count-negative"
  Controls warnings if a shift count is negative.
  This warning is enabled by default.
! .IP \fB\-Wno\-shift\-count\-overflow\fR 4
  .IX Item "-Wno-shift-count-overflow"
  Controls warnings if a shift count is greater than or equal to the bit width
  of the type.  This warning is enabled by default.
! .IP \fB\-Wshift\-negative\-value\fR 4
  .IX Item "-Wshift-negative-value"
  Warn if left shifting a negative value.  This warning is enabled by
! \&\fB\-Wextra\fR in C99 (and newer) and C++11 to C++17 modes.
! .IP \fB\-Wno\-shift\-overflow\fR 4
  .IX Item "-Wno-shift-overflow"
  .PD 0
! .IP \fB\-Wshift\-overflow=\fR\fIn\fR 4
  .IX Item "-Wshift-overflow=n"
  .PD
  These options control warnings about left shift overflows.
  .RS 4
! .IP \fB\-Wshift\-overflow=1\fR 4
  .IX Item "-Wshift-overflow=1"
  This is the warning level of \fB\-Wshift\-overflow\fR and is enabled
! by default in C99 and C++11 modes (and newer).  This warning level does
! not warn about left\-shifting 1 into the sign bit.  (However, in C, such
  an overflow is still rejected in contexts where an integer constant expression
! is required.)  No warning is emitted in C++20 mode (and newer), as signed left
  shifts always wrap.
! .IP \fB\-Wshift\-overflow=2\fR 4
  .IX Item "-Wshift-overflow=2"
! This warning level also warns about left\-shifting 1 into the sign bit,
! unless C++14 mode (or newer) is active.
  .RE
  .RS 4
  .RE
! .IP \fB\-Wswitch\fR 4
  .IX Item "-Wswitch"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
  and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
*************** warning.)  \f(CW\*(C`case\*(C'\fR labels
*** 6903,6913 ****
  provoke warnings when this option is used (even if there is a
  \&\f(CW\*(C`default\*(C'\fR label).
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wswitch\-default\fR" 4
  .IX Item "-Wswitch-default"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement does not have a \f(CW\*(C`default\*(C'\fR
  case.
! .IP "\fB\-Wswitch\-enum\fR" 4
  .IX Item "-Wswitch-enum"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
  and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
--- 6832,6842 ----
  provoke warnings when this option is used (even if there is a
  \&\f(CW\*(C`default\*(C'\fR label).
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wswitch\-default\fR 4
  .IX Item "-Wswitch-default"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement does not have a \f(CW\*(C`default\*(C'\fR
  case.
! .IP \fB\-Wswitch\-enum\fR 4
  .IX Item "-Wswitch-enum"
  Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
  and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
*************** provoke warnings when this option is use
*** 6916,6922 ****
  between \fB\-Wswitch\fR and this option is that this option gives a
  warning about an omitted enumeration code even if there is a
  \&\f(CW\*(C`default\*(C'\fR label.
! .IP "\fB\-Wno\-switch\-bool\fR" 4
  .IX Item "-Wno-switch-bool"
  Do not warn when a \f(CW\*(C`switch\*(C'\fR statement has an index of boolean type
  and the case values are outside the range of a boolean type.
--- 6845,6851 ----
  between \fB\-Wswitch\fR and this option is that this option gives a
  warning about an omitted enumeration code even if there is a
  \&\f(CW\*(C`default\*(C'\fR label.
! .IP \fB\-Wno\-switch\-bool\fR 4
  .IX Item "-Wno-switch-bool"
  Do not warn when a \f(CW\*(C`switch\*(C'\fR statement has an index of boolean type
  and the case values are outside the range of a boolean type.
*************** expression to a type other than \f(CW\*(
*** 6930,6943 ****
  \&          }
  .Ve
  .Sp
! This warning is enabled by default for C and \*(C+ programs.
! .IP "\fB\-Wno\-switch\-outside\-range\fR" 4
  .IX Item "-Wno-switch-outside-range"
  This option controls warnings when a \f(CW\*(C`switch\*(C'\fR case has a value
  that is outside of its
  respective type range.  This warning is enabled by default for
! C and \*(C+ programs.
! .IP "\fB\-Wno\-switch\-unreachable\fR" 4
  .IX Item "-Wno-switch-unreachable"
  Do not warn when a \f(CW\*(C`switch\*(C'\fR statement contains statements between the
  controlling expression and the first case label, which will never be
--- 6859,6872 ----
  \&          }
  .Ve
  .Sp
! This warning is enabled by default for C and C++ programs.
! .IP \fB\-Wno\-switch\-outside\-range\fR 4
  .IX Item "-Wno-switch-outside-range"
  This option controls warnings when a \f(CW\*(C`switch\*(C'\fR case has a value
  that is outside of its
  respective type range.  This warning is enabled by default for
! C and C++ programs.
! .IP \fB\-Wno\-switch\-unreachable\fR 4
  .IX Item "-Wno-switch-unreachable"
  Do not warn when a \f(CW\*(C`switch\*(C'\fR statement contains statements between the
  controlling expression and the first case label, which will never be
*************** controlling expression and the first cas
*** 6967,6984 ****
  \&          }
  .Ve
  .Sp
! This warning is enabled by default for C and \*(C+ programs.
! .IP "\fB\-Wsync\-nand\fR (C and \*(C+ only)" 4
! .IX Item "-Wsync-nand (C and only)"
  Warn when \f(CW\*(C`_\|_sync_fetch_and_nand\*(C'\fR and \f(CW\*(C`_\|_sync_nand_and_fetch\*(C'\fR
! built-in functions are used.  These functions changed semantics in \s-1GCC 4.4.\s0
! .IP "\fB\-Wtrivial\-auto\-var\-init\fR" 4
  .IX Item "-Wtrivial-auto-var-init"
  Warn when \f(CW\*(C`\-ftrivial\-auto\-var\-init\*(C'\fR cannot initialize the automatic
  variable.  A common situation is an automatic variable that is declared
  between the controlling expression and the first case label of a \f(CW\*(C`switch\*(C'\fR
  statement.
! .IP "\fB\-Wunused\-but\-set\-parameter\fR" 4
  .IX Item "-Wunused-but-set-parameter"
  Warn whenever a function parameter is assigned to, but otherwise unused
  (aside from its declaration).
--- 6896,6913 ----
  \&          }
  .Ve
  .Sp
! This warning is enabled by default for C and C++ programs.
! .IP "\fB\-Wsync\-nand\fR (C and C++ only)" 4
! .IX Item "-Wsync-nand (C and C++ only)"
  Warn when \f(CW\*(C`_\|_sync_fetch_and_nand\*(C'\fR and \f(CW\*(C`_\|_sync_nand_and_fetch\*(C'\fR
! built\-in functions are used.  These functions changed semantics in GCC 4.4.
! .IP \fB\-Wtrivial\-auto\-var\-init\fR 4
  .IX Item "-Wtrivial-auto-var-init"
  Warn when \f(CW\*(C`\-ftrivial\-auto\-var\-init\*(C'\fR cannot initialize the automatic
  variable.  A common situation is an automatic variable that is declared
  between the controlling expression and the first case label of a \f(CW\*(C`switch\*(C'\fR
  statement.
! .IP \fB\-Wunused\-but\-set\-parameter\fR 4
  .IX Item "-Wunused-but-set-parameter"
  Warn whenever a function parameter is assigned to, but otherwise unused
  (aside from its declaration).
*************** To suppress this warning use the \f(CW\*
*** 6987,6993 ****
  .Sp
  This warning is also enabled by \fB\-Wunused\fR together with
  \&\fB\-Wextra\fR.
! .IP "\fB\-Wunused\-but\-set\-variable\fR" 4
  .IX Item "-Wunused-but-set-variable"
  Warn whenever a local variable is assigned to, but otherwise unused
  (aside from its declaration).
--- 6916,6922 ----
  .Sp
  This warning is also enabled by \fB\-Wunused\fR together with
  \&\fB\-Wextra\fR.
! .IP \fB\-Wunused\-but\-set\-variable\fR 4
  .IX Item "-Wunused-but-set-variable"
  Warn whenever a local variable is assigned to, but otherwise unused
  (aside from its declaration).
*************** To suppress this warning use the \f(CW\*
*** 6997,7089 ****
  .Sp
  This warning is also enabled by \fB\-Wunused\fR, which is enabled
  by \fB\-Wall\fR.
! .IP "\fB\-Wunused\-function\fR" 4
  .IX Item "-Wunused-function"
  Warn whenever a static function is declared but not defined or a
! non-inline static function is unused.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wunused\-label\fR" 4
  .IX Item "-Wunused-label"
  Warn whenever a label is declared but not used.
  This warning is enabled by \fB\-Wall\fR.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP "\fB\-Wunused\-local\-typedefs\fR (C, Objective-C, \*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wunused-local-typedefs (C, Objective-C, and Objective- only)"
  Warn when a typedef locally defined in a function is not used.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wunused\-parameter\fR" 4
  .IX Item "-Wunused-parameter"
  Warn whenever a function parameter is unused aside from its declaration.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP "\fB\-Wno\-unused\-result\fR" 4
  .IX Item "-Wno-unused-result"
  Do not warn if a caller of a function marked with attribute
  \&\f(CW\*(C`warn_unused_result\*(C'\fR does not use
  its return value. The default is \fB\-Wunused\-result\fR.
! .IP "\fB\-Wunused\-variable\fR" 4
  .IX Item "-Wunused-variable"
  Warn whenever a local or static variable is unused aside from its
  declaration. This option implies \fB\-Wunused\-const\-variable=1\fR for C,
! but not for \*(C+. This warning is enabled by \fB\-Wall\fR.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP "\fB\-Wunused\-const\-variable\fR" 4
  .IX Item "-Wunused-const-variable"
  .PD 0
! .IP "\fB\-Wunused\-const\-variable=\fR\fIn\fR" 4
  .IX Item "-Wunused-const-variable=n"
  .PD
  Warn whenever a constant static variable is unused aside from its declaration.
  \&\fB\-Wunused\-const\-variable=1\fR is enabled by \fB\-Wunused\-variable\fR
! for C, but not for \*(C+. In C this declares variable storage, but in \*(C+ this
  is not an error since const variables take the place of \f(CW\*(C`#define\*(C'\fRs.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
  .RS 4
! .IP "\fB\-Wunused\-const\-variable=1\fR" 4
  .IX Item "-Wunused-const-variable=1"
  This is the warning level that is enabled by \fB\-Wunused\-variable\fR for
  C.  It warns only about unused static const variables defined in the main
  compilation unit, but not about static const variables declared in any
  header included.
! .IP "\fB\-Wunused\-const\-variable=2\fR" 4
  .IX Item "-Wunused-const-variable=2"
  This warning level also warns for unused constant static variables in
  headers (excluding system headers).  This is the warning level of
  \&\fB\-Wunused\-const\-variable\fR and must be explicitly requested since
! in \*(C+ this isn't an error and in C it might be harder to clean up all
  headers included.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wunused\-value\fR" 4
  .IX Item "-Wunused-value"
  Warn whenever a statement computes a result that is explicitly not
  used. To suppress this warning cast the unused expression to
! \&\f(CW\*(C`void\*(C'\fR. This includes an expression-statement or the left-hand
  side of a comma expression that contains no side effects. For example,
  an expression such as \f(CW\*(C`x[i,j]\*(C'\fR causes a warning, while
  \&\f(CW\*(C`x[(void)i,j]\*(C'\fR does not.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wunused\fR" 4
  .IX Item "-Wunused"
  All the above \fB\-Wunused\fR options combined.
  .Sp
  In order to get a warning about an unused function parameter, you must
  either specify \fB\-Wextra \-Wunused\fR (note that \fB\-Wall\fR implies
  \&\fB\-Wunused\fR), or separately specify \fB\-Wunused\-parameter\fR.
! .IP "\fB\-Wuninitialized\fR" 4
  .IX Item "-Wuninitialized"
  Warn if an object with automatic or allocated storage duration is used
! without having been initialized.  In \*(C+, also warn if a non-static
! reference or non-static \f(CW\*(C`const\*(C'\fR member appears in a class without
  constructors.
  .Sp
! In addition, passing a pointer (or in \*(C+, a reference) to an uninitialized
! object to a \f(CW\*(C`const\*(C'\fR\-qualified argument of a built-in function known to
  read the object is also diagnosed by this warning.
  (\fB\-Wmaybe\-uninitialized\fR is issued for ordinary functions.)
  .Sp
--- 6926,7018 ----
  .Sp
  This warning is also enabled by \fB\-Wunused\fR, which is enabled
  by \fB\-Wall\fR.
! .IP \fB\-Wunused\-function\fR 4
  .IX Item "-Wunused-function"
  Warn whenever a static function is declared but not defined or a
! non\-inline static function is unused.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wunused\-label\fR 4
  .IX Item "-Wunused-label"
  Warn whenever a label is declared but not used.
  This warning is enabled by \fB\-Wall\fR.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP "\fB\-Wunused\-local\-typedefs\fR (C, Objective\-C, C++ and Objective\-C++ only)" 4
! .IX Item "-Wunused-local-typedefs (C, Objective-C, C++ and Objective-C++ only)"
  Warn when a typedef locally defined in a function is not used.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wunused\-parameter\fR 4
  .IX Item "-Wunused-parameter"
  Warn whenever a function parameter is unused aside from its declaration.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP \fB\-Wno\-unused\-result\fR 4
  .IX Item "-Wno-unused-result"
  Do not warn if a caller of a function marked with attribute
  \&\f(CW\*(C`warn_unused_result\*(C'\fR does not use
  its return value. The default is \fB\-Wunused\-result\fR.
! .IP \fB\-Wunused\-variable\fR 4
  .IX Item "-Wunused-variable"
  Warn whenever a local or static variable is unused aside from its
  declaration. This option implies \fB\-Wunused\-const\-variable=1\fR for C,
! but not for C++. This warning is enabled by \fB\-Wall\fR.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
! .IP \fB\-Wunused\-const\-variable\fR 4
  .IX Item "-Wunused-const-variable"
  .PD 0
! .IP \fB\-Wunused\-const\-variable=\fR\fIn\fR 4
  .IX Item "-Wunused-const-variable=n"
  .PD
  Warn whenever a constant static variable is unused aside from its declaration.
  \&\fB\-Wunused\-const\-variable=1\fR is enabled by \fB\-Wunused\-variable\fR
! for C, but not for C++. In C this declares variable storage, but in C++ this
  is not an error since const variables take the place of \f(CW\*(C`#define\*(C'\fRs.
  .Sp
  To suppress this warning use the \f(CW\*(C`unused\*(C'\fR attribute.
  .RS 4
! .IP \fB\-Wunused\-const\-variable=1\fR 4
  .IX Item "-Wunused-const-variable=1"
  This is the warning level that is enabled by \fB\-Wunused\-variable\fR for
  C.  It warns only about unused static const variables defined in the main
  compilation unit, but not about static const variables declared in any
  header included.
! .IP \fB\-Wunused\-const\-variable=2\fR 4
  .IX Item "-Wunused-const-variable=2"
  This warning level also warns for unused constant static variables in
  headers (excluding system headers).  This is the warning level of
  \&\fB\-Wunused\-const\-variable\fR and must be explicitly requested since
! in C++ this isn\*(Aqt an error and in C it might be harder to clean up all
  headers included.
  .RE
  .RS 4
  .RE
! .IP \fB\-Wunused\-value\fR 4
  .IX Item "-Wunused-value"
  Warn whenever a statement computes a result that is explicitly not
  used. To suppress this warning cast the unused expression to
! \&\f(CW\*(C`void\*(C'\fR. This includes an expression\-statement or the left\-hand
  side of a comma expression that contains no side effects. For example,
  an expression such as \f(CW\*(C`x[i,j]\*(C'\fR causes a warning, while
  \&\f(CW\*(C`x[(void)i,j]\*(C'\fR does not.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wunused\fR 4
  .IX Item "-Wunused"
  All the above \fB\-Wunused\fR options combined.
  .Sp
  In order to get a warning about an unused function parameter, you must
  either specify \fB\-Wextra \-Wunused\fR (note that \fB\-Wall\fR implies
  \&\fB\-Wunused\fR), or separately specify \fB\-Wunused\-parameter\fR.
! .IP \fB\-Wuninitialized\fR 4
  .IX Item "-Wuninitialized"
  Warn if an object with automatic or allocated storage duration is used
! without having been initialized.  In C++, also warn if a non\-static
! reference or non\-static \f(CW\*(C`const\*(C'\fR member appears in a class without
  constructors.
  .Sp
! In addition, passing a pointer (or in C++, a reference) to an uninitialized
! object to a \f(CW\*(C`const\*(C'\fR\-qualified argument of a built\-in function known to
  read the object is also diagnosed by this warning.
  (\fB\-Wmaybe\-uninitialized\fR is issued for ordinary functions.)
  .Sp
*************** structure, union or array variables as w
*** 7095,7101 ****
  uninitialized as a whole.  They do not occur for variables or elements
  declared \f(CW\*(C`volatile\*(C'\fR.  Because these warnings depend on
  optimization, the exact variables or elements for which there are
! warnings depend on the precise optimization options and version of \s-1GCC\s0
  used.
  .Sp
  Note that there may be no warning about a variable that is used only
--- 7024,7030 ----
  uninitialized as a whole.  They do not occur for variables or elements
  declared \f(CW\*(C`volatile\*(C'\fR.  Because these warnings depend on
  optimization, the exact variables or elements for which there are
! warnings depend on the precise optimization options and version of GCC
  used.
  .Sp
  Note that there may be no warning about a variable that is used only
*************** to compute a value that itself is never
*** 7103,7110 ****
  computations may be deleted by data flow analysis before the warnings
  are printed.
  .Sp
! In \*(C+, this warning also warns about using uninitialized objects in
! member-initializer-lists.  For example, \s-1GCC\s0 warns about \f(CW\*(C`b\*(C'\fR being
  uninitialized in the following snippet:
  .Sp
  .Vb 5
--- 7032,7039 ----
  computations may be deleted by data flow analysis before the warnings
  are printed.
  .Sp
! In C++, this warning also warns about using uninitialized objects in
! member\-initializer\-lists.  For example, GCC warns about \f(CW\*(C`b\*(C'\fR being
  uninitialized in the following snippet:
  .Sp
  .Vb 5
*************** uninitialized in the following snippet:
*** 7114,7127 ****
  \&          A() : a(b) { }
  \&        };
  .Ve
! .IP "\fB\-Wno\-invalid\-memory\-model\fR" 4
  .IX Item "-Wno-invalid-memory-model"
  This option controls warnings
  for invocations of \fB_\|_atomic Builtins\fR, \fB_\|_sync Builtins\fR,
  and the C11 atomic generic functions with a memory consistency argument
  that is either invalid for the operation or outside the range of values
  of the \f(CW\*(C`memory_order\*(C'\fR enumeration.  For example, since the
! \&\f(CW\*(C`_\|_atomic_store\*(C'\fR and \f(CW\*(C`_\|_atomic_store_n\*(C'\fR built-ins are only
  defined for the relaxed, release, and sequentially consistent memory
  orders the following code is diagnosed:
  .Sp
--- 7043,7056 ----
  \&          A() : a(b) { }
  \&        };
  .Ve
! .IP \fB\-Wno\-invalid\-memory\-model\fR 4
  .IX Item "-Wno-invalid-memory-model"
  This option controls warnings
  for invocations of \fB_\|_atomic Builtins\fR, \fB_\|_sync Builtins\fR,
  and the C11 atomic generic functions with a memory consistency argument
  that is either invalid for the operation or outside the range of values
  of the \f(CW\*(C`memory_order\*(C'\fR enumeration.  For example, since the
! \&\f(CW\*(C`_\|_atomic_store\*(C'\fR and \f(CW\*(C`_\|_atomic_store_n\*(C'\fR built\-ins are only
  defined for the relaxed, release, and sequentially consistent memory
  orders the following code is diagnosed:
  .Sp
*************** orders the following code is diagnosed:
*** 7133,7139 ****
  .Ve
  .Sp
  \&\fB\-Winvalid\-memory\-model\fR is enabled by default.
! .IP "\fB\-Wmaybe\-uninitialized\fR" 4
  .IX Item "-Wmaybe-uninitialized"
  For an object with automatic or allocated storage duration, if there exists
  a path from the function entry to a use of the object that is initialized,
--- 7062,7068 ----
  .Ve
  .Sp
  \&\fB\-Winvalid\-memory\-model\fR is enabled by default.
! .IP \fB\-Wmaybe\-uninitialized\fR 4
  .IX Item "-Wmaybe-uninitialized"
  For an object with automatic or allocated storage duration, if there exists
  a path from the function entry to a use of the object that is initialized,
*************** but there exist some other paths for whi
*** 7141,7157 ****
  the compiler emits a warning if it cannot prove the uninitialized paths
  are not executed at run time.
  .Sp
! In addition, passing a pointer (or in \*(C+, a reference) to an uninitialized
  object to a \f(CW\*(C`const\*(C'\fR\-qualified function argument is also diagnosed by
! this warning.  (\fB\-Wuninitialized\fR is issued for built-in functions
  known to read the object.)  Annotating the function with attribute
! \&\f(CW\*(C`access (none)\*(C'\fR indicates that the argument isn't used to access
  the object and avoids the warning.
  .Sp
  These warnings are only possible in optimizing compilation, because otherwise
! \&\s-1GCC\s0 does not keep track of the state of variables.
  .Sp
! These warnings are made optional because \s-1GCC\s0 may not be able to determine when
  the code is correct in spite of appearing to have an error.  Here is one
  example of how this can happen:
  .Sp
--- 7070,7086 ----
  the compiler emits a warning if it cannot prove the uninitialized paths
  are not executed at run time.
  .Sp
! In addition, passing a pointer (or in C++, a reference) to an uninitialized
  object to a \f(CW\*(C`const\*(C'\fR\-qualified function argument is also diagnosed by
! this warning.  (\fB\-Wuninitialized\fR is issued for built\-in functions
  known to read the object.)  Annotating the function with attribute
! \&\f(CW\*(C`access (none)\*(C'\fR indicates that the argument isn\*(Aqt used to access
  the object and avoids the warning.
  .Sp
  These warnings are only possible in optimizing compilation, because otherwise
! GCC does not keep track of the state of variables.
  .Sp
! These warnings are made optional because GCC may not be able to determine when
  the code is correct in spite of appearing to have an error.  Here is one
  example of how this can happen:
  .Sp
*************** example of how this can happen:
*** 7171,7181 ****
  .Ve
  .Sp
  If the value of \f(CW\*(C`y\*(C'\fR is always 1, 2 or 3, then \f(CW\*(C`x\*(C'\fR is
! always initialized, but \s-1GCC\s0 doesn't know this. To suppress the
  warning, you need to provide a default case with \fBassert\fR\|(0) or
  similar code.
  .Sp
! This option also warns when a non-volatile automatic variable might be
  changed by a call to \f(CW\*(C`longjmp\*(C'\fR.
  The compiler sees only the calls to \f(CW\*(C`setjmp\*(C'\fR.  It cannot know
  where \f(CW\*(C`longjmp\*(C'\fR will be called; in fact, a signal handler could
--- 7100,7110 ----
  .Ve
  .Sp
  If the value of \f(CW\*(C`y\*(C'\fR is always 1, 2 or 3, then \f(CW\*(C`x\*(C'\fR is
! always initialized, but GCC doesn\*(Aqt know this. To suppress the
  warning, you need to provide a default case with \fBassert\fR\|(0) or
  similar code.
  .Sp
! This option also warns when a non\-volatile automatic variable might be
  changed by a call to \f(CW\*(C`longjmp\*(C'\fR.
  The compiler sees only the calls to \f(CW\*(C`setjmp\*(C'\fR.  It cannot know
  where \f(CW\*(C`longjmp\*(C'\fR will be called; in fact, a signal handler could
*************** Some spurious warnings can be avoided if
*** 7187,7204 ****
  you use that never return as \f(CW\*(C`noreturn\*(C'\fR.
  .Sp
  This warning is enabled by \fB\-Wall\fR or \fB\-Wextra\fR.
! .IP "\fB\-Wunknown\-pragmas\fR" 4
  .IX Item "-Wunknown-pragmas"
  Warn when a \f(CW\*(C`#pragma\*(C'\fR directive is encountered that is not understood by 
! \&\s-1GCC.\s0  If this command-line option is used, warnings are even issued
  for unknown pragmas in system header files.  This is not the case if
! the warnings are only enabled by the \fB\-Wall\fR command-line option.
! .IP "\fB\-Wno\-pragmas\fR" 4
  .IX Item "-Wno-pragmas"
  Do not warn about misuses of pragmas, such as incorrect parameters,
  invalid syntax, or conflicts between pragmas.  See also
  \&\fB\-Wunknown\-pragmas\fR.
! .IP "\fB\-Wno\-prio\-ctor\-dtor\fR" 4
  .IX Item "-Wno-prio-ctor-dtor"
  Do not warn if a priority from 0 to 100 is used for constructor or destructor.
  The use of constructor and destructor attributes allow you to assign a
--- 7116,7133 ----
  you use that never return as \f(CW\*(C`noreturn\*(C'\fR.
  .Sp
  This warning is enabled by \fB\-Wall\fR or \fB\-Wextra\fR.
! .IP \fB\-Wunknown\-pragmas\fR 4
  .IX Item "-Wunknown-pragmas"
  Warn when a \f(CW\*(C`#pragma\*(C'\fR directive is encountered that is not understood by 
! GCC.  If this command\-line option is used, warnings are even issued
  for unknown pragmas in system header files.  This is not the case if
! the warnings are only enabled by the \fB\-Wall\fR command\-line option.
! .IP \fB\-Wno\-pragmas\fR 4
  .IX Item "-Wno-pragmas"
  Do not warn about misuses of pragmas, such as incorrect parameters,
  invalid syntax, or conflicts between pragmas.  See also
  \&\fB\-Wunknown\-pragmas\fR.
! .IP \fB\-Wno\-prio\-ctor\-dtor\fR 4
  .IX Item "-Wno-prio-ctor-dtor"
  Do not warn if a priority from 0 to 100 is used for constructor or destructor.
  The use of constructor and destructor attributes allow you to assign a
*************** priority to the constructor/destructor t
*** 7206,7212 ****
  before \f(CW\*(C`main\*(C'\fR is called or after it returns.  The priority values must be
  greater than 100 as the compiler reserves priority values between 0\-\-100 for
  the implementation.
! .IP "\fB\-Wstrict\-aliasing\fR" 4
  .IX Item "-Wstrict-aliasing"
  This option is only active when \fB\-fstrict\-aliasing\fR is active.
  It warns about code that might break the strict aliasing rules that the
--- 7135,7141 ----
  before \f(CW\*(C`main\*(C'\fR is called or after it returns.  The priority values must be
  greater than 100 as the compiler reserves priority values between 0\-\-100 for
  the implementation.
! .IP \fB\-Wstrict\-aliasing\fR 4
  .IX Item "-Wstrict-aliasing"
  This option is only active when \fB\-fstrict\-aliasing\fR is active.
  It warns about code that might break the strict aliasing rules that the
*************** compiler is using for optimization.  The
*** 7214,7220 ****
  cases, but does attempt to catch the more common pitfalls.  It is
  included in \fB\-Wall\fR.
  It is equivalent to \fB\-Wstrict\-aliasing=3\fR
! .IP "\fB\-Wstrict\-aliasing=n\fR" 4
  .IX Item "-Wstrict-aliasing=n"
  This option is only active when \fB\-fstrict\-aliasing\fR is active.
  It warns about code that might break the strict aliasing rules that the
--- 7143,7149 ----
  cases, but does attempt to catch the more common pitfalls.  It is
  included in \fB\-Wall\fR.
  It is equivalent to \fB\-Wstrict\-aliasing=3\fR
! .IP \fB\-Wstrict\-aliasing=n\fR 4
  .IX Item "-Wstrict-aliasing=n"
  This option is only active when \fB\-fstrict\-aliasing\fR is active.
  It warns about code that might break the strict aliasing rules that the
*************** negatives.  Slightly slower than levels
*** 7243,7255 ****
  Takes care of the common pun+dereference pattern in the front end:
  \&\f(CW\*(C`*(int*)&some_float\*(C'\fR.
  If optimization is enabled, it also runs in the back end, where it deals
! with multiple statement cases using flow-sensitive points-to information.
  Only warns when the converted pointer is dereferenced.
  Does not warn about incomplete types.
! .IP "\fB\-Wstrict\-overflow\fR" 4
  .IX Item "-Wstrict-overflow"
  .PD 0
! .IP "\fB\-Wstrict\-overflow=\fR\fIn\fR" 4
  .IX Item "-Wstrict-overflow=n"
  .PD
  This option is only active when signed overflow is undefined.
--- 7172,7184 ----
  Takes care of the common pun+dereference pattern in the front end:
  \&\f(CW\*(C`*(int*)&some_float\*(C'\fR.
  If optimization is enabled, it also runs in the back end, where it deals
! with multiple statement cases using flow\-sensitive points\-to information.
  Only warns when the converted pointer is dereferenced.
  Does not warn about incomplete types.
! .IP \fB\-Wstrict\-overflow\fR 4
  .IX Item "-Wstrict-overflow"
  .PD 0
! .IP \fB\-Wstrict\-overflow=\fR\fIn\fR 4
  .IX Item "-Wstrict-overflow=n"
  .PD
  This option is only active when signed overflow is undefined.
*************** undefined signed overflow when estimatin
*** 7269,7282 ****
  requires, in particular when determining whether a loop will be
  executed at all.
  .RS 4
! .IP "\fB\-Wstrict\-overflow=1\fR" 4
  .IX Item "-Wstrict-overflow=1"
  Warn about cases that are both questionable and easy to avoid.  For
  example the compiler simplifies
  \&\f(CW\*(C`x + 1 > x\*(C'\fR to \f(CW1\fR.  This level of
  \&\fB\-Wstrict\-overflow\fR is enabled by \fB\-Wall\fR; higher levels
  are not, and must be explicitly requested.
! .IP "\fB\-Wstrict\-overflow=2\fR" 4
  .IX Item "-Wstrict-overflow=2"
  Also warn about other cases where a comparison is simplified to a
  constant.  For example: \f(CW\*(C`abs (x) >= 0\*(C'\fR.  This can only be
--- 7198,7211 ----
  requires, in particular when determining whether a loop will be
  executed at all.
  .RS 4
! .IP \fB\-Wstrict\-overflow=1\fR 4
  .IX Item "-Wstrict-overflow=1"
  Warn about cases that are both questionable and easy to avoid.  For
  example the compiler simplifies
  \&\f(CW\*(C`x + 1 > x\*(C'\fR to \f(CW1\fR.  This level of
  \&\fB\-Wstrict\-overflow\fR is enabled by \fB\-Wall\fR; higher levels
  are not, and must be explicitly requested.
! .IP \fB\-Wstrict\-overflow=2\fR 4
  .IX Item "-Wstrict-overflow=2"
  Also warn about other cases where a comparison is simplified to a
  constant.  For example: \f(CW\*(C`abs (x) >= 0\*(C'\fR.  This can only be
*************** simplified when signed integer overflow
*** 7284,7298 ****
  \&\f(CW\*(C`abs (INT_MIN)\*(C'\fR overflows to \f(CW\*(C`INT_MIN\*(C'\fR, which is less than
  zero.  \fB\-Wstrict\-overflow\fR (with no level) is the same as
  \&\fB\-Wstrict\-overflow=2\fR.
! .IP "\fB\-Wstrict\-overflow=3\fR" 4
  .IX Item "-Wstrict-overflow=3"
  Also warn about other cases where a comparison is simplified.  For
  example: \f(CW\*(C`x + 1 > 1\*(C'\fR is simplified to \f(CW\*(C`x > 0\*(C'\fR.
! .IP "\fB\-Wstrict\-overflow=4\fR" 4
  .IX Item "-Wstrict-overflow=4"
  Also warn about other simplifications not covered by the above cases.
  For example: \f(CW\*(C`(x * 10) / 5\*(C'\fR is simplified to \f(CW\*(C`x * 2\*(C'\fR.
! .IP "\fB\-Wstrict\-overflow=5\fR" 4
  .IX Item "-Wstrict-overflow=5"
  Also warn about cases where the compiler reduces the magnitude of a
  constant involved in a comparison.  For example: \f(CW\*(C`x + 2 > y\*(C'\fR is
--- 7213,7227 ----
  \&\f(CW\*(C`abs (INT_MIN)\*(C'\fR overflows to \f(CW\*(C`INT_MIN\*(C'\fR, which is less than
  zero.  \fB\-Wstrict\-overflow\fR (with no level) is the same as
  \&\fB\-Wstrict\-overflow=2\fR.
! .IP \fB\-Wstrict\-overflow=3\fR 4
  .IX Item "-Wstrict-overflow=3"
  Also warn about other cases where a comparison is simplified.  For
  example: \f(CW\*(C`x + 1 > 1\*(C'\fR is simplified to \f(CW\*(C`x > 0\*(C'\fR.
! .IP \fB\-Wstrict\-overflow=4\fR 4
  .IX Item "-Wstrict-overflow=4"
  Also warn about other simplifications not covered by the above cases.
  For example: \f(CW\*(C`(x * 10) / 5\*(C'\fR is simplified to \f(CW\*(C`x * 2\*(C'\fR.
! .IP \fB\-Wstrict\-overflow=5\fR 4
  .IX Item "-Wstrict-overflow=5"
  Also warn about cases where the compiler reduces the magnitude of a
  constant involved in a comparison.  For example: \f(CW\*(C`x + 2 > y\*(C'\fR is
*************** false positives.
*** 7303,7317 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wstring\-compare\fR" 4
  .IX Item "-Wstring-compare"
  Warn for calls to \f(CW\*(C`strcmp\*(C'\fR and \f(CW\*(C`strncmp\*(C'\fR whose result is
! determined to be either zero or non-zero in tests for such equality
  owing to the length of one argument being greater than the size of
  the array the other argument is stored in (or the bound in the case
  of \f(CW\*(C`strncmp\*(C'\fR).  Such calls could be mistakes.  For example,
  the call to \f(CW\*(C`strcmp\*(C'\fR below is diagnosed because its result is
! necessarily non-zero irrespective of the contents of the array \f(CW\*(C`a\*(C'\fR.
  .Sp
  .Vb 8
  \&        extern char a[4];
--- 7232,7246 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wstring\-compare\fR 4
  .IX Item "-Wstring-compare"
  Warn for calls to \f(CW\*(C`strcmp\*(C'\fR and \f(CW\*(C`strncmp\*(C'\fR whose result is
! determined to be either zero or non\-zero in tests for such equality
  owing to the length of one argument being greater than the size of
  the array the other argument is stored in (or the bound in the case
  of \f(CW\*(C`strncmp\*(C'\fR).  Such calls could be mistakes.  For example,
  the call to \f(CW\*(C`strcmp\*(C'\fR below is diagnosed because its result is
! necessarily non\-zero irrespective of the contents of the array \f(CW\*(C`a\*(C'\fR.
  .Sp
  .Vb 8
  \&        extern char a[4];
*************** necessarily non-zero irrespective of the
*** 7325,7336 ****
  .Ve
  .Sp
  \&\fB\-Wstring\-compare\fR is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wno\-stringop\-overflow\fR" 4
  .IX Item "-Wno-stringop-overflow"
  .PD 0
! .IP "\fB\-Wstringop\-overflow\fR" 4
  .IX Item "-Wstringop-overflow"
! .IP "\fB\-Wstringop\-overflow=\fR\fItype\fR" 4
  .IX Item "-Wstringop-overflow=type"
  .PD
  Warn for calls to string manipulation functions such as \f(CW\*(C`memcpy\*(C'\fR and
--- 7254,7265 ----
  .Ve
  .Sp
  \&\fB\-Wstring\-compare\fR is enabled by \fB\-Wextra\fR.
! .IP \fB\-Wno\-stringop\-overflow\fR 4
  .IX Item "-Wno-stringop-overflow"
  .PD 0
! .IP \fB\-Wstringop\-overflow\fR 4
  .IX Item "-Wstringop-overflow"
! .IP \fB\-Wstringop\-overflow=\fR\fItype\fR 4
  .IX Item "-Wstringop-overflow=type"
  .PD
  Warn for calls to string manipulation functions such as \f(CW\*(C`memcpy\*(C'\fR and
*************** of Object Size type\-0.  The option also
*** 7343,7354 ****
  in excess of the largest possible object or at most \f(CW\*(C`SIZE_MAX / 2\*(C'\fR bytes.
  The option produces the best results with optimization enabled but can detect
  a small subset of simple buffer overflows even without optimization in
! calls to the \s-1GCC\s0 built-in functions like \f(CW\*(C`_\|_builtin_memcpy\*(C'\fR that
  correspond to the standard functions.  In any case, the option warns about
  just a subset of buffer overflows detected by the corresponding overflow
! checking built-ins.  For example, the option issues a warning for
  the \f(CW\*(C`strcpy\*(C'\fR call below because it copies at least 5 characters
! (the string \f(CW"blue"\fR including the terminating \s-1NUL\s0) into the buffer
  of size 4.
  .Sp
  .Vb 11
--- 7272,7283 ----
  in excess of the largest possible object or at most \f(CW\*(C`SIZE_MAX / 2\*(C'\fR bytes.
  The option produces the best results with optimization enabled but can detect
  a small subset of simple buffer overflows even without optimization in
! calls to the GCC built\-in functions like \f(CW\*(C`_\|_builtin_memcpy\*(C'\fR that
  correspond to the standard functions.  In any case, the option warns about
  just a subset of buffer overflows detected by the corresponding overflow
! checking built\-ins.  For example, the option issues a warning for
  the \f(CW\*(C`strcpy\*(C'\fR call below because it copies at least 5 characters
! (the string \f(CW"blue"\fR including the terminating NUL) into the buffer
  of size 4.
  .Sp
  .Vb 11
*************** of size 4.
*** 7370,7408 ****
  .Sp
  Option \fB\-Wstringop\-overflow=2\fR is enabled by default.
  .RS 4
! .IP "\fB\-Wstringop\-overflow\fR" 4
  .IX Item "-Wstringop-overflow"
  .PD 0
! .IP "\fB\-Wstringop\-overflow=1\fR" 4
  .IX Item "-Wstringop-overflow=1"
  .PD
! The \fB\-Wstringop\-overflow=1\fR option uses type-zero Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  does not warn for writes past the end of subobjects of larger objects accessed
  by pointers unless the size of the largest surrounding object is known.  When
  the destination may be one of several objects it is assumed to be the largest
  one of them.  On Linux systems, when optimization is enabled at this setting
  the option warns for the same code as when the \f(CW\*(C`_FORTIFY_SOURCE\*(C'\fR macro
! is defined to a non-zero value.
! .IP "\fB\-Wstringop\-overflow=2\fR" 4
  .IX Item "-Wstringop-overflow=2"
! The \fB\-Wstringop\-overflow=2\fR option uses type-one Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflows when writing to members of the largest complete
  objects whose exact size is known.  However, it does not warn for excessive
  writes to the same members of unknown objects referenced by pointers since
  they may point to arrays containing unknown numbers of elements.  This is
  the default setting of the option.
! .IP "\fB\-Wstringop\-overflow=3\fR" 4
  .IX Item "-Wstringop-overflow=3"
! The \fB\-Wstringop\-overflow=3\fR option uses type-two Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflowing the smallest object or data member.  This is the
  most restrictive setting of the option that may result in warnings for safe
  code.
! .IP "\fB\-Wstringop\-overflow=4\fR" 4
  .IX Item "-Wstringop-overflow=4"
! The \fB\-Wstringop\-overflow=4\fR option uses type-three Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflowing any data members, and when the destination is
  one of several objects it uses the size of the largest of them to decide
--- 7299,7337 ----
  .Sp
  Option \fB\-Wstringop\-overflow=2\fR is enabled by default.
  .RS 4
! .IP \fB\-Wstringop\-overflow\fR 4
  .IX Item "-Wstringop-overflow"
  .PD 0
! .IP \fB\-Wstringop\-overflow=1\fR 4
  .IX Item "-Wstringop-overflow=1"
  .PD
! The \fB\-Wstringop\-overflow=1\fR option uses type\-zero Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  does not warn for writes past the end of subobjects of larger objects accessed
  by pointers unless the size of the largest surrounding object is known.  When
  the destination may be one of several objects it is assumed to be the largest
  one of them.  On Linux systems, when optimization is enabled at this setting
  the option warns for the same code as when the \f(CW\*(C`_FORTIFY_SOURCE\*(C'\fR macro
! is defined to a non\-zero value.
! .IP \fB\-Wstringop\-overflow=2\fR 4
  .IX Item "-Wstringop-overflow=2"
! The \fB\-Wstringop\-overflow=2\fR option uses type\-one Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflows when writing to members of the largest complete
  objects whose exact size is known.  However, it does not warn for excessive
  writes to the same members of unknown objects referenced by pointers since
  they may point to arrays containing unknown numbers of elements.  This is
  the default setting of the option.
! .IP \fB\-Wstringop\-overflow=3\fR 4
  .IX Item "-Wstringop-overflow=3"
! The \fB\-Wstringop\-overflow=3\fR option uses type\-two Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflowing the smallest object or data member.  This is the
  most restrictive setting of the option that may result in warnings for safe
  code.
! .IP \fB\-Wstringop\-overflow=4\fR 4
  .IX Item "-Wstringop-overflow=4"
! The \fB\-Wstringop\-overflow=4\fR option uses type\-three Object Size Checking
  to determine the sizes of destination objects.  At this setting the option
  warns about overflowing any data members, and when the destination is
  one of several objects it uses the size of the largest of them to decide
*************** setting of the option may result in warn
*** 7411,7424 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wno\-stringop\-overread\fR" 4
  .IX Item "-Wno-stringop-overread"
  Warn for calls to string manipulation functions such as \f(CW\*(C`memchr\*(C'\fR, or
  \&\f(CW\*(C`strcpy\*(C'\fR that are determined to read past the end of the source
  sequence.
  .Sp
  Option \fB\-Wstringop\-overread\fR is enabled by default.
! .IP "\fB\-Wno\-stringop\-truncation\fR" 4
  .IX Item "-Wno-stringop-truncation"
  Do not warn for calls to bounded string manipulation functions
  such as \f(CW\*(C`strncat\*(C'\fR,
--- 7340,7353 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Wno\-stringop\-overread\fR 4
  .IX Item "-Wno-stringop-overread"
  Warn for calls to string manipulation functions such as \f(CW\*(C`memchr\*(C'\fR, or
  \&\f(CW\*(C`strcpy\*(C'\fR that are determined to read past the end of the source
  sequence.
  .Sp
  Option \fB\-Wstringop\-overread\fR is enabled by default.
! .IP \fB\-Wno\-stringop\-truncation\fR 4
  .IX Item "-Wno-stringop-truncation"
  Do not warn for calls to bounded string manipulation functions
  such as \f(CW\*(C`strncat\*(C'\fR,
*************** warning use \f(CW\*(C`bufsize \- strlen
*** 7438,7448 ****
  .Ve
  .Sp
  As another example, the following call to \f(CW\*(C`strncpy\*(C'\fR results in copying
! to \f(CW\*(C`d\*(C'\fR just the characters preceding the terminating \s-1NUL,\s0 without
! appending the \s-1NUL\s0 to the end.  Assuming the result of \f(CW\*(C`strncpy\*(C'\fR is
! necessarily a NUL-terminated string is a common mistake, and so the call
  is diagnosed.  To avoid the warning when the result is not expected to be
! NUL-terminated, call \f(CW\*(C`memcpy\*(C'\fR instead.
  .Sp
  .Vb 4
  \&        void copy (char *d, const char *s)
--- 7367,7377 ----
  .Ve
  .Sp
  As another example, the following call to \f(CW\*(C`strncpy\*(C'\fR results in copying
! to \f(CW\*(C`d\*(C'\fR just the characters preceding the terminating NUL, without
! appending the NUL to the end.  Assuming the result of \f(CW\*(C`strncpy\*(C'\fR is
! necessarily a NUL\-terminated string is a common mistake, and so the call
  is diagnosed.  To avoid the warning when the result is not expected to be
! NUL\-terminated, call \f(CW\*(C`memcpy\*(C'\fR instead.
  .Sp
  .Vb 4
  \&        void copy (char *d, const char *s)
*************** NUL-terminated, call \f(CW\*(C`memcpy\*(
*** 7454,7460 ****
  In the following example, the call to \f(CW\*(C`strncpy\*(C'\fR specifies the size
  of the destination buffer as the bound.  If the length of the source
  string is equal to or greater than this size the result of the copy will
! not be NUL-terminated.  Therefore, the call is also diagnosed.  To avoid
  the warning, specify \f(CW\*(C`sizeof buf \- 1\*(C'\fR as the bound and set the last
  element of the buffer to \f(CW\*(C`NUL\*(C'\fR.
  .Sp
--- 7383,7389 ----
  In the following example, the call to \f(CW\*(C`strncpy\*(C'\fR specifies the size
  of the destination buffer as the bound.  If the length of the source
  string is equal to or greater than this size the result of the copy will
! not be NUL\-terminated.  Therefore, the call is also diagnosed.  To avoid
  the warning, specify \f(CW\*(C`sizeof buf \- 1\*(C'\fR as the bound and set the last
  element of the buffer to \f(CW\*(C`NUL\*(C'\fR.
  .Sp
*************** of bytes with no terminating \f(CW\*(C`N
*** 7472,7484 ****
  with attribute \f(CW\*(C`nonstring\*(C'\fR to avoid this warning.  Such arrays,
  however, are not suitable arguments to functions that expect
  \&\f(CW\*(C`NUL\*(C'\fR\-terminated strings.  To help detect accidental misuses of
! such arrays \s-1GCC\s0 issues warnings unless it can prove that the use is
  safe.
! .IP "\fB\-Wstrict\-flex\-arrays\fR" 4
  .IX Item "-Wstrict-flex-arrays"
  Warn about inproper usages of flexible array members
! according to the \fIlevel\fR of the \f(CW\*(C`strict_flex_array (\f(CIlevel\f(CW)\*(C'\fR
! attribute attached to the trailing array field of a structure if it's
  available, otherwise according to the \fIlevel\fR of the option
  \&\fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR.
  .Sp
--- 7401,7413 ----
  with attribute \f(CW\*(C`nonstring\*(C'\fR to avoid this warning.  Such arrays,
  however, are not suitable arguments to functions that expect
  \&\f(CW\*(C`NUL\*(C'\fR\-terminated strings.  To help detect accidental misuses of
! such arrays GCC issues warnings unless it can prove that the use is
  safe.
! .IP \fB\-Wstrict\-flex\-arrays\fR 4
  .IX Item "-Wstrict-flex-arrays"
  Warn about inproper usages of flexible array members
! according to the \fIlevel\fR of the \f(CW\*(C`strict_flex_array (\fR\f(CIlevel\fR\f(CW)\*(C'\fR
! attribute attached to the trailing array field of a structure if it\*(Aqs
  available, otherwise according to the \fIlevel\fR of the option
  \&\fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR.
  .Sp
*************** of a structure that have 2 or more eleme
*** 7490,7592 ****
  as a flexible array member.
  .Sp
  when \fIlevel\fR=2, in addition to \fIlevel\fR=1, additional warnings will be
! issued for a trailing one-element array reference of a structure
  if the array is referenced as a flexible array member.
  .Sp
  when \fIlevel\fR=3, in addition to \fIlevel\fR=2, additional warnings will be
! issued for a trailing zero-length array reference of a structure
  if the array is referenced as a flexible array member.
! .IP "\fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR|\fBformat\fR|\fBcold\fR|\fBmalloc\fR]" 4
  .IX Item "-Wsuggest-attribute=[pure|const|noreturn|format|cold|malloc]"
  Warn for cases where adding an attribute may be beneficial. The
  attributes currently supported are listed below.
  .RS 4
! .IP "\fB\-Wsuggest\-attribute=pure\fR" 4
  .IX Item "-Wsuggest-attribute=pure"
  .PD 0
! .IP "\fB\-Wsuggest\-attribute=const\fR" 4
  .IX Item "-Wsuggest-attribute=const"
! .IP "\fB\-Wsuggest\-attribute=noreturn\fR" 4
  .IX Item "-Wsuggest-attribute=noreturn"
! .IP "\fB\-Wmissing\-noreturn\fR" 4
  .IX Item "-Wmissing-noreturn"
! .IP "\fB\-Wsuggest\-attribute=malloc\fR" 4
  .IX Item "-Wsuggest-attribute=malloc"
  .PD
  Warn about functions that might be candidates for attributes
  \&\f(CW\*(C`pure\*(C'\fR, \f(CW\*(C`const\*(C'\fR or \f(CW\*(C`noreturn\*(C'\fR or \f(CW\*(C`malloc\*(C'\fR. The compiler
  only warns for functions visible in other compilation units or (in the case of
  \&\f(CW\*(C`pure\*(C'\fR and \f(CW\*(C`const\*(C'\fR) if it cannot prove that the function returns
! normally. A function returns normally if it doesn't contain an infinite loop or
  return abnormally by throwing, calling \f(CW\*(C`abort\*(C'\fR or trapping.  This analysis
  requires option \fB\-fipa\-pure\-const\fR, which is enabled by default at
  \&\fB\-O\fR and higher.  Higher optimization levels improve the accuracy
  of the analysis.
! .IP "\fB\-Wsuggest\-attribute=format\fR" 4
  .IX Item "-Wsuggest-attribute=format"
  .PD 0
! .IP "\fB\-Wmissing\-format\-attribute\fR" 4
  .IX Item "-Wmissing-format-attribute"
  .PD
  Warn about function pointers that might be candidates for \f(CW\*(C`format\*(C'\fR
  attributes.  Note these are only possible candidates, not absolute ones.
! \&\s-1GCC\s0 guesses that function pointers with \f(CW\*(C`format\*(C'\fR attributes that
  are used in assignment, initialization, parameter passing or return
  statements should have a corresponding \f(CW\*(C`format\*(C'\fR attribute in the
! resulting type.  I.e. the left-hand side of the assignment or
  initialization, the type of the parameter variable, or the return type
  of the containing function respectively should also have a \f(CW\*(C`format\*(C'\fR
  attribute to avoid the warning.
  .Sp
! \&\s-1GCC\s0 also warns about function definitions that might be
  candidates for \f(CW\*(C`format\*(C'\fR attributes.  Again, these are only
! possible candidates.  \s-1GCC\s0 guesses that \f(CW\*(C`format\*(C'\fR attributes
  might be appropriate for any function that calls a function like
  \&\f(CW\*(C`vprintf\*(C'\fR or \f(CW\*(C`vscanf\*(C'\fR, but this might not always be the
  case, and some functions for which \f(CW\*(C`format\*(C'\fR attributes are
  appropriate may not be detected.
! .IP "\fB\-Wsuggest\-attribute=cold\fR" 4
  .IX Item "-Wsuggest-attribute=cold"
  Warn about functions that might be candidates for \f(CW\*(C`cold\*(C'\fR attribute.  This
  is based on static detection and generally only warns about functions which
  always leads to a call to another \f(CW\*(C`cold\*(C'\fR function such as wrappers of
! \&\*(C+ \f(CW\*(C`throw\*(C'\fR or fatal error reporting functions leading to \f(CW\*(C`abort\*(C'\fR.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Walloc\-zero\fR" 4
  .IX Item "-Walloc-zero"
  Warn about calls to allocation functions decorated with attribute
! \&\f(CW\*(C`alloc_size\*(C'\fR that specify zero bytes, including those to the built-in
  forms of the functions \f(CW\*(C`aligned_alloc\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`calloc\*(C'\fR,
  \&\f(CW\*(C`malloc\*(C'\fR, and \f(CW\*(C`realloc\*(C'\fR.  Because the behavior of these functions
  when called with a zero size differs among implementations (and in the case
  of \f(CW\*(C`realloc\*(C'\fR has been deprecated) relying on it may result in subtle
  portability bugs and should be avoided.
! .IP "\fB\-Walloc\-size\-larger\-than=\fR\fIbyte-size\fR" 4
  .IX Item "-Walloc-size-larger-than=byte-size"
  Warn about calls to functions decorated with attribute \f(CW\*(C`alloc_size\*(C'\fR
  that attempt to allocate objects larger than the specified number of bytes,
  or where the result of the size computation in an integer type with infinite
! precision would exceed the value of \fB\s-1PTRDIFF_MAX\s0\fR on the target.
! \&\fB\-Walloc\-size\-larger\-than=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte-size\fR of \fB\s-1SIZE_MAX\s0\fR or more or by
  \&\fB\-Wno\-alloc\-size\-larger\-than\fR.
! .IP "\fB\-Wno\-alloc\-size\-larger\-than\fR" 4
  .IX Item "-Wno-alloc-size-larger-than"
  Disable \fB\-Walloc\-size\-larger\-than=\fR warnings.  The option is
! equivalent to \fB\-Walloc\-size\-larger\-than=\fR\fB\s-1SIZE_MAX\s0\fR or
  larger.
! .IP "\fB\-Walloca\fR" 4
  .IX Item "-Walloca"
  This option warns on all uses of \f(CW\*(C`alloca\*(C'\fR in the source.
! .IP "\fB\-Walloca\-larger\-than=\fR\fIbyte-size\fR" 4
  .IX Item "-Walloca-larger-than=byte-size"
  This option warns on calls to \f(CW\*(C`alloca\*(C'\fR with an integer argument whose
  value is either zero, or that is not bounded by a controlling predicate
! that limits its value to at most \fIbyte-size\fR.  It also warns for calls
! to \f(CW\*(C`alloca\*(C'\fR where the bound value is unknown.  Arguments of non-integer
  types are considered unbounded even if they appear to be constrained to
  the expected range.
  .Sp
--- 7419,7521 ----
  as a flexible array member.
  .Sp
  when \fIlevel\fR=2, in addition to \fIlevel\fR=1, additional warnings will be
! issued for a trailing one\-element array reference of a structure
  if the array is referenced as a flexible array member.
  .Sp
  when \fIlevel\fR=3, in addition to \fIlevel\fR=2, additional warnings will be
! issued for a trailing zero\-length array reference of a structure
  if the array is referenced as a flexible array member.
! .IP \fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR|\fBformat\fR|\fBcold\fR|\fBmalloc\fR] 4
  .IX Item "-Wsuggest-attribute=[pure|const|noreturn|format|cold|malloc]"
  Warn for cases where adding an attribute may be beneficial. The
  attributes currently supported are listed below.
  .RS 4
! .IP \fB\-Wsuggest\-attribute=pure\fR 4
  .IX Item "-Wsuggest-attribute=pure"
  .PD 0
! .IP \fB\-Wsuggest\-attribute=const\fR 4
  .IX Item "-Wsuggest-attribute=const"
! .IP \fB\-Wsuggest\-attribute=noreturn\fR 4
  .IX Item "-Wsuggest-attribute=noreturn"
! .IP \fB\-Wmissing\-noreturn\fR 4
  .IX Item "-Wmissing-noreturn"
! .IP \fB\-Wsuggest\-attribute=malloc\fR 4
  .IX Item "-Wsuggest-attribute=malloc"
  .PD
  Warn about functions that might be candidates for attributes
  \&\f(CW\*(C`pure\*(C'\fR, \f(CW\*(C`const\*(C'\fR or \f(CW\*(C`noreturn\*(C'\fR or \f(CW\*(C`malloc\*(C'\fR. The compiler
  only warns for functions visible in other compilation units or (in the case of
  \&\f(CW\*(C`pure\*(C'\fR and \f(CW\*(C`const\*(C'\fR) if it cannot prove that the function returns
! normally. A function returns normally if it doesn\*(Aqt contain an infinite loop or
  return abnormally by throwing, calling \f(CW\*(C`abort\*(C'\fR or trapping.  This analysis
  requires option \fB\-fipa\-pure\-const\fR, which is enabled by default at
  \&\fB\-O\fR and higher.  Higher optimization levels improve the accuracy
  of the analysis.
! .IP \fB\-Wsuggest\-attribute=format\fR 4
  .IX Item "-Wsuggest-attribute=format"
  .PD 0
! .IP \fB\-Wmissing\-format\-attribute\fR 4
  .IX Item "-Wmissing-format-attribute"
  .PD
  Warn about function pointers that might be candidates for \f(CW\*(C`format\*(C'\fR
  attributes.  Note these are only possible candidates, not absolute ones.
! GCC guesses that function pointers with \f(CW\*(C`format\*(C'\fR attributes that
  are used in assignment, initialization, parameter passing or return
  statements should have a corresponding \f(CW\*(C`format\*(C'\fR attribute in the
! resulting type.  I.e. the left\-hand side of the assignment or
  initialization, the type of the parameter variable, or the return type
  of the containing function respectively should also have a \f(CW\*(C`format\*(C'\fR
  attribute to avoid the warning.
  .Sp
! GCC also warns about function definitions that might be
  candidates for \f(CW\*(C`format\*(C'\fR attributes.  Again, these are only
! possible candidates.  GCC guesses that \f(CW\*(C`format\*(C'\fR attributes
  might be appropriate for any function that calls a function like
  \&\f(CW\*(C`vprintf\*(C'\fR or \f(CW\*(C`vscanf\*(C'\fR, but this might not always be the
  case, and some functions for which \f(CW\*(C`format\*(C'\fR attributes are
  appropriate may not be detected.
! .IP \fB\-Wsuggest\-attribute=cold\fR 4
  .IX Item "-Wsuggest-attribute=cold"
  Warn about functions that might be candidates for \f(CW\*(C`cold\*(C'\fR attribute.  This
  is based on static detection and generally only warns about functions which
  always leads to a call to another \f(CW\*(C`cold\*(C'\fR function such as wrappers of
! C++ \f(CW\*(C`throw\*(C'\fR or fatal error reporting functions leading to \f(CW\*(C`abort\*(C'\fR.
  .RE
  .RS 4
  .RE
! .IP \fB\-Walloc\-zero\fR 4
  .IX Item "-Walloc-zero"
  Warn about calls to allocation functions decorated with attribute
! \&\f(CW\*(C`alloc_size\*(C'\fR that specify zero bytes, including those to the built\-in
  forms of the functions \f(CW\*(C`aligned_alloc\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`calloc\*(C'\fR,
  \&\f(CW\*(C`malloc\*(C'\fR, and \f(CW\*(C`realloc\*(C'\fR.  Because the behavior of these functions
  when called with a zero size differs among implementations (and in the case
  of \f(CW\*(C`realloc\*(C'\fR has been deprecated) relying on it may result in subtle
  portability bugs and should be avoided.
! .IP \fB\-Walloc\-size\-larger\-than=\fR\fIbyte\-size\fR 4
  .IX Item "-Walloc-size-larger-than=byte-size"
  Warn about calls to functions decorated with attribute \f(CW\*(C`alloc_size\*(C'\fR
  that attempt to allocate objects larger than the specified number of bytes,
  or where the result of the size computation in an integer type with infinite
! precision would exceed the value of \fBPTRDIFF_MAX\fR on the target.
! \&\fB\-Walloc\-size\-larger\-than=\fR\fBPTRDIFF_MAX\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte\-size\fR of \fBSIZE_MAX\fR or more or by
  \&\fB\-Wno\-alloc\-size\-larger\-than\fR.
! .IP \fB\-Wno\-alloc\-size\-larger\-than\fR 4
  .IX Item "-Wno-alloc-size-larger-than"
  Disable \fB\-Walloc\-size\-larger\-than=\fR warnings.  The option is
! equivalent to \fB\-Walloc\-size\-larger\-than=\fR\fBSIZE_MAX\fR or
  larger.
! .IP \fB\-Walloca\fR 4
  .IX Item "-Walloca"
  This option warns on all uses of \f(CW\*(C`alloca\*(C'\fR in the source.
! .IP \fB\-Walloca\-larger\-than=\fR\fIbyte\-size\fR 4
  .IX Item "-Walloca-larger-than=byte-size"
  This option warns on calls to \f(CW\*(C`alloca\*(C'\fR with an integer argument whose
  value is either zero, or that is not bounded by a controlling predicate
! that limits its value to at most \fIbyte\-size\fR.  It also warns for calls
! to \f(CW\*(C`alloca\*(C'\fR where the bound value is unknown.  Arguments of non\-integer
  types are considered unbounded even if they appear to be constrained to
  the expected range.
  .Sp
*************** expected argument to be implicitly cast
*** 7642,7657 ****
  .Sp
  This option also warns when \f(CW\*(C`alloca\*(C'\fR is used in a loop.
  .Sp
! \&\fB\-Walloca\-larger\-than=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default
  but is usually only effective  when \fB\-ftree\-vrp\fR is active (default
  for \fB\-O2\fR and above).
  .Sp
! See also \fB\-Wvla\-larger\-than=\fR\fBbyte-size\fR.
! .IP "\fB\-Wno\-alloca\-larger\-than\fR" 4
  .IX Item "-Wno-alloca-larger-than"
  Disable \fB\-Walloca\-larger\-than=\fR warnings.  The option is
! equivalent to \fB\-Walloca\-larger\-than=\fR\fB\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Warith\-conversion\fR" 4
  .IX Item "-Warith-conversion"
  Do warn about implicit conversions from arithmetic operations even
  when conversion of the operands to the same type cannot change their
--- 7571,7586 ----
  .Sp
  This option also warns when \f(CW\*(C`alloca\*(C'\fR is used in a loop.
  .Sp
! \&\fB\-Walloca\-larger\-than=\fR\fBPTRDIFF_MAX\fR is enabled by default
  but is usually only effective  when \fB\-ftree\-vrp\fR is active (default
  for \fB\-O2\fR and above).
  .Sp
! See also \fB\-Wvla\-larger\-than=\fR\fBbyte\-size\fR.
! .IP \fB\-Wno\-alloca\-larger\-than\fR 4
  .IX Item "-Wno-alloca-larger-than"
  Disable \fB\-Walloca\-larger\-than=\fR warnings.  The option is
! equivalent to \fB\-Walloca\-larger\-than=\fR\fBSIZE_MAX\fR or larger.
! .IP \fB\-Warith\-conversion\fR 4
  .IX Item "-Warith-conversion"
  Do warn about implicit conversions from arithmetic operations even
  when conversion of the operands to the same type cannot change their
*************** values.  This affects warnings from \fB\
*** 7665,7674 ****
  \&          c = c + 1; // only warns with B<\-Warith\-conversion>
  \&        }
  .Ve
! .IP "\fB\-Warray\-bounds\fR" 4
  .IX Item "-Warray-bounds"
  .PD 0
! .IP "\fB\-Warray\-bounds=\fR\fIn\fR" 4
  .IX Item "-Warray-bounds=n"
  .PD
  Warn about out of bounds subscripts or offsets into arrays.  This warning
--- 7594,7603 ----
  \&          c = c + 1; // only warns with B<\-Warith\-conversion>
  \&        }
  .Ve
! .IP \fB\-Warray\-bounds\fR 4
  .IX Item "-Warray-bounds"
  .PD 0
! .IP \fB\-Warray\-bounds=\fR\fIn\fR 4
  .IX Item "-Warray-bounds=n"
  .PD
  Warn about out of bounds subscripts or offsets into arrays.  This warning
*************** are issued even without optimization.
*** 7679,7687 ****
  By default, the trailing array of a structure will be treated as a flexible
  array member by \fB\-Warray\-bounds\fR or \fB\-Warray\-bounds=\fR\fIn\fR
  if it is declared as either a flexible array member per C99 standard onwards
! (\fB[]\fR), a \s-1GCC\s0 zero-length array extension (\fB[0]\fR), or an one-element
  array (\fB[1]\fR). As a result, out of bounds subscripts or offsets into
! zero-length arrays or one-element arrays are not warned by default.
  .Sp
  You can add the option \fB\-fstrict\-flex\-arrays\fR or
  \&\fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR to control how this
--- 7608,7616 ----
  By default, the trailing array of a structure will be treated as a flexible
  array member by \fB\-Warray\-bounds\fR or \fB\-Warray\-bounds=\fR\fIn\fR
  if it is declared as either a flexible array member per C99 standard onwards
! (\fB[]\fR), a GCC zero\-length array extension (\fB[0]\fR), or an one\-element
  array (\fB[1]\fR). As a result, out of bounds subscripts or offsets into
! zero\-length arrays or one\-element arrays are not warned by default.
  .Sp
  You can add the option \fB\-fstrict\-flex\-arrays\fR or
  \&\fB\-fstrict\-flex\-arrays=\fR\fIlevel\fR to control how this
*************** option treat trailing array of a structu
*** 7690,7705 ****
  when \fIlevel\fR<=1, no change to the default behavior.
  .Sp
  when \fIlevel\fR=2, additional warnings will be issued for out of bounds
! subscripts or offsets into one-element arrays;
  .Sp
  when \fIlevel\fR=3, in addition to \fIlevel\fR=2, additional warnings will be
! issued for out of bounds subscripts or offsets into zero-length arrays.
  .RS 4
! .IP "\fB\-Warray\-bounds=1\fR" 4
  .IX Item "-Warray-bounds=1"
  This is the default warning level of \fB\-Warray\-bounds\fR and is enabled
  by \fB\-Wall\fR; higher levels are not, and must be explicitly requested.
! .IP "\fB\-Warray\-bounds=2\fR" 4
  .IX Item "-Warray-bounds=2"
  This warning level also warns about the intermediate results of pointer
  arithmetic that may yield out of bounds values. This warning level may
--- 7619,7634 ----
  when \fIlevel\fR<=1, no change to the default behavior.
  .Sp
  when \fIlevel\fR=2, additional warnings will be issued for out of bounds
! subscripts or offsets into one\-element arrays;
  .Sp
  when \fIlevel\fR=3, in addition to \fIlevel\fR=2, additional warnings will be
! issued for out of bounds subscripts or offsets into zero\-length arrays.
  .RS 4
! .IP \fB\-Warray\-bounds=1\fR 4
  .IX Item "-Warray-bounds=1"
  This is the default warning level of \fB\-Warray\-bounds\fR and is enabled
  by \fB\-Wall\fR; higher levels are not, and must be explicitly requested.
! .IP \fB\-Warray\-bounds=2\fR 4
  .IX Item "-Warray-bounds=2"
  This warning level also warns about the intermediate results of pointer
  arithmetic that may yield out of bounds values. This warning level may
*************** give a larger number of false positives
*** 7707,7716 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-Warray\-compare\fR" 4
  .IX Item "-Warray-compare"
  Warn about equality and relational comparisons between two operands of array
! type.  This comparison was deprecated in \*(C+20.  For example:
  .Sp
  .Vb 3
  \&        int arr1[5];
--- 7636,7645 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-Warray\-compare\fR 4
  .IX Item "-Warray-compare"
  Warn about equality and relational comparisons between two operands of array
! type.  This comparison was deprecated in C++20.  For example:
  .Sp
  .Vb 3
  \&        int arr1[5];
*************** type.  This comparison was deprecated in
*** 7719,7733 ****
  .Ve
  .Sp
  \&\fB\-Warray\-compare\fR is enabled by \fB\-Wall\fR.
! .IP "\fB\-Warray\-parameter\fR" 4
  .IX Item "-Warray-parameter"
  .PD 0
! .IP "\fB\-Warray\-parameter=\fR\fIn\fR" 4
  .IX Item "-Warray-parameter=n"
  .PD
  Warn about redeclarations of functions involving arguments of array or
  pointer types of inconsistent kinds or forms, and enable the detection
! of out-of-bounds accesses to such parameters by warnings such as
  \&\fB\-Warray\-bounds\fR.
  .Sp
  If the first function declaration uses the array form the bound specified
--- 7648,7662 ----
  .Ve
  .Sp
  \&\fB\-Warray\-compare\fR is enabled by \fB\-Wall\fR.
! .IP \fB\-Warray\-parameter\fR 4
  .IX Item "-Warray-parameter"
  .PD 0
! .IP \fB\-Warray\-parameter=\fR\fIn\fR 4
  .IX Item "-Warray-parameter=n"
  .PD
  Warn about redeclarations of functions involving arguments of array or
  pointer types of inconsistent kinds or forms, and enable the detection
! of out\-of\-bounds accesses to such parameters by warnings such as
  \&\fB\-Warray\-bounds\fR.
  .Sp
  If the first function declaration uses the array form the bound specified
*************** not trigger a warning.
*** 7769,7789 ****
  \&\fB\-Warray\-parameter=2\fR is included in \fB\-Wall\fR.  The
  \&\fB\-Wvla\-parameter\fR option triggers warnings for similar inconsistencies
  involving Variable Length Array arguments.
! .IP "\fB\-Wattribute\-alias=\fR\fIn\fR" 4
  .IX Item "-Wattribute-alias=n"
  .PD 0
! .IP "\fB\-Wno\-attribute\-alias\fR" 4
  .IX Item "-Wno-attribute-alias"
  .PD
  Warn about declarations using the \f(CW\*(C`alias\*(C'\fR and similar attributes whose
  target is incompatible with the type of the alias.
  .RS 4
! .IP "\fB\-Wattribute\-alias=1\fR" 4
  .IX Item "-Wattribute-alias=1"
  The default warning level of the \fB\-Wattribute\-alias\fR option diagnoses
  incompatibilities between the type of the alias declaration and that of its
  target.  Such incompatibilities are typically indicative of bugs.
! .IP "\fB\-Wattribute\-alias=2\fR" 4
  .IX Item "-Wattribute-alias=2"
  At this level \fB\-Wattribute\-alias\fR also diagnoses cases where
  the attributes of the alias declaration are more restrictive than the
--- 7698,7718 ----
  \&\fB\-Warray\-parameter=2\fR is included in \fB\-Wall\fR.  The
  \&\fB\-Wvla\-parameter\fR option triggers warnings for similar inconsistencies
  involving Variable Length Array arguments.
! .IP \fB\-Wattribute\-alias=\fR\fIn\fR 4
  .IX Item "-Wattribute-alias=n"
  .PD 0
! .IP \fB\-Wno\-attribute\-alias\fR 4
  .IX Item "-Wno-attribute-alias"
  .PD
  Warn about declarations using the \f(CW\*(C`alias\*(C'\fR and similar attributes whose
  target is incompatible with the type of the alias.
  .RS 4
! .IP \fB\-Wattribute\-alias=1\fR 4
  .IX Item "-Wattribute-alias=1"
  The default warning level of the \fB\-Wattribute\-alias\fR option diagnoses
  incompatibilities between the type of the alias declaration and that of its
  target.  Such incompatibilities are typically indicative of bugs.
! .IP \fB\-Wattribute\-alias=2\fR 4
  .IX Item "-Wattribute-alias=2"
  At this level \fB\-Wattribute\-alias\fR also diagnoses cases where
  the attributes of the alias declaration are more restrictive than the
*************** Attributes considered include \f(CW\*(C`
*** 7805,7820 ****
  This is the default.  You can disable these warnings with either
  \&\fB\-Wno\-attribute\-alias\fR or \fB\-Wattribute\-alias=0\fR.
  .RE
! .IP "\fB\-Wbidi\-chars=\fR[\fBnone\fR|\fBunpaired\fR|\fBany\fR|\fBucn\fR]" 4
  .IX Item "-Wbidi-chars=[none|unpaired|any|ucn]"
! Warn about possibly misleading \s-1UTF\-8\s0 bidirectional control characters in
  comments, string literals, character constants, and identifiers.  Such
! characters can change left-to-right writing direction into right-to-left
  (and vice versa), which can cause confusion between the logical order and
  visual order.  This may be dangerous; for instance, it may seem that a piece
  of code is not commented out, whereas it in fact is.
  .Sp
! There are three levels of warning supported by \s-1GCC.\s0  The default is
  \&\fB\-Wbidi\-chars=unpaired\fR, which warns about improperly terminated
  bidi contexts.  \fB\-Wbidi\-chars=none\fR turns the warning off.
  \&\fB\-Wbidi\-chars=any\fR warns about any use of bidirectional control
--- 7734,7749 ----
  This is the default.  You can disable these warnings with either
  \&\fB\-Wno\-attribute\-alias\fR or \fB\-Wattribute\-alias=0\fR.
  .RE
! .IP \fB\-Wbidi\-chars=\fR[\fBnone\fR|\fBunpaired\fR|\fBany\fR|\fBucn\fR] 4
  .IX Item "-Wbidi-chars=[none|unpaired|any|ucn]"
! Warn about possibly misleading UTF\-8 bidirectional control characters in
  comments, string literals, character constants, and identifiers.  Such
! characters can change left\-to\-right writing direction into right\-to\-left
  (and vice versa), which can cause confusion between the logical order and
  visual order.  This may be dangerous; for instance, it may seem that a piece
  of code is not commented out, whereas it in fact is.
  .Sp
! There are three levels of warning supported by GCC.  The default is
  \&\fB\-Wbidi\-chars=unpaired\fR, which warns about improperly terminated
  bidi contexts.  \fB\-Wbidi\-chars=none\fR turns the warning off.
  \&\fB\-Wbidi\-chars=any\fR warns about any use of bidirectional control
*************** to turn on such checking by using \fB\-W
*** 7825,7831 ****
  \&\fB\-Wbidi\-chars=any,ucn\fR.  Using \fB\-Wbidi\-chars=ucn\fR is valid,
  and is equivalent to \fB\-Wbidi\-chars=unpaired,ucn\fR, if no previous
  \&\fB\-Wbidi\-chars=any\fR was specified.
! .IP "\fB\-Wbool\-compare\fR" 4
  .IX Item "-Wbool-compare"
  Warn about boolean expression compared with an integer value different from
  \&\f(CW\*(C`true\*(C'\fR/\f(CW\*(C`false\*(C'\fR.  For instance, the following comparison is
--- 7754,7760 ----
  \&\fB\-Wbidi\-chars=any,ucn\fR.  Using \fB\-Wbidi\-chars=ucn\fR is valid,
  and is equivalent to \fB\-Wbidi\-chars=unpaired,ucn\fR, if no previous
  \&\fB\-Wbidi\-chars=any\fR was specified.
! .IP \fB\-Wbool\-compare\fR 4
  .IX Item "-Wbool-compare"
  Warn about boolean expression compared with an integer value different from
  \&\f(CW\*(C`true\*(C'\fR/\f(CW\*(C`false\*(C'\fR.  For instance, the following comparison is
*************** always false:
*** 7838,7855 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wbool\-operation\fR" 4
  .IX Item "-Wbool-operation"
  Warn about suspicious operations on expressions of a boolean type.  For
  instance, bitwise negation of a boolean is very likely a bug in the program.
  For C, this warning also warns about incrementing or decrementing a boolean,
! which rarely makes sense.  (In \*(C+, decrementing a boolean is always invalid.
! Incrementing a boolean is invalid in \*(C+17, and deprecated otherwise.)
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wduplicated\-branches\fR" 4
  .IX Item "-Wduplicated-branches"
! Warn when an if-else has identical branches.  This warning detects cases like
  .Sp
  .Vb 4
  \&        if (p != NULL)
--- 7767,7784 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wbool\-operation\fR 4
  .IX Item "-Wbool-operation"
  Warn about suspicious operations on expressions of a boolean type.  For
  instance, bitwise negation of a boolean is very likely a bug in the program.
  For C, this warning also warns about incrementing or decrementing a boolean,
! which rarely makes sense.  (In C++, decrementing a boolean is always invalid.
! Incrementing a boolean is invalid in C++17, and deprecated otherwise.)
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wduplicated\-branches\fR 4
  .IX Item "-Wduplicated-branches"
! Warn when an if\-else has identical branches.  This warning detects cases like
  .Sp
  .Vb 4
  \&        if (p != NULL)
*************** Warn when an if-else has identical branc
*** 7858,7912 ****
  \&          return 0;
  .Ve
  .Sp
! It doesn't warn when both branches contain just a null statement.  This warning
  also warn for conditional operators:
  .Sp
  .Vb 1
  \&          int i = x ? *p : *p;
  .Ve
! .IP "\fB\-Wduplicated\-cond\fR" 4
  .IX Item "-Wduplicated-cond"
! Warn about duplicated conditions in an if-else-if chain.  For instance,
  warn for the following code:
  .Sp
  .Vb 2
  \&        if (p\->q != NULL) { ... }
  \&        else if (p\->q != NULL) { ... }
  .Ve
! .IP "\fB\-Wframe\-address\fR" 4
  .IX Item "-Wframe-address"
  Warn when the \fB_\|_builtin_frame_address\fR or \fB_\|_builtin_return_address\fR
  is called with an argument greater than 0.  Such calls may return indeterminate
  values or crash the program.  The warning is included in \fB\-Wall\fR.
! .IP "\fB\-Wno\-discarded\-qualifiers\fR (C and Objective-C only)" 4
  .IX Item "-Wno-discarded-qualifiers (C and Objective-C only)"
  Do not warn if type qualifiers on pointers are being discarded.
  Typically, the compiler warns if a \f(CW\*(C`const char *\*(C'\fR variable is
  passed to a function that takes a \f(CW\*(C`char *\*(C'\fR parameter.  This option
  can be used to suppress such a warning.
! .IP "\fB\-Wno\-discarded\-array\-qualifiers\fR (C and Objective-C only)" 4
  .IX Item "-Wno-discarded-array-qualifiers (C and Objective-C only)"
  Do not warn if type qualifiers on arrays which are pointer targets
  are being discarded.  Typically, the compiler warns if a
  \&\f(CW\*(C`const int (*)[]\*(C'\fR variable is passed to a function that
  takes a \f(CW\*(C`int (*)[]\*(C'\fR parameter.  This option can be used to
  suppress such a warning.
! .IP "\fB\-Wno\-incompatible\-pointer\-types\fR (C and Objective-C only)" 4
  .IX Item "-Wno-incompatible-pointer-types (C and Objective-C only)"
  Do not warn when there is a conversion between pointers that have incompatible
  types.  This warning is for cases not covered by \fB\-Wno\-pointer\-sign\fR,
  which warns for pointer argument passing or assignment with different
  signedness.
! .IP "\fB\-Wno\-int\-conversion\fR (C and Objective-C only)" 4
  .IX Item "-Wno-int-conversion (C and Objective-C only)"
  Do not warn about incompatible integer to pointer and pointer to integer
  conversions.  This warning is about implicit conversions; for explicit
  conversions the warnings \fB\-Wno\-int\-to\-pointer\-cast\fR and
  \&\fB\-Wno\-pointer\-to\-int\-cast\fR may be used.
! .IP "\fB\-Wzero\-length\-bounds\fR" 4
  .IX Item "-Wzero-length-bounds"
! Warn about accesses to elements of zero-length array members that might
! overlap other members of the same object.  Declaring interior zero-length
  arrays is discouraged because accesses to them are undefined.
  .Sp
  For example, the first two stores in function \f(CW\*(C`bad\*(C'\fR are diagnosed
--- 7787,7841 ----
  \&          return 0;
  .Ve
  .Sp
! It doesn\*(Aqt warn when both branches contain just a null statement.  This warning
  also warn for conditional operators:
  .Sp
  .Vb 1
  \&          int i = x ? *p : *p;
  .Ve
! .IP \fB\-Wduplicated\-cond\fR 4
  .IX Item "-Wduplicated-cond"
! Warn about duplicated conditions in an if\-else\-if chain.  For instance,
  warn for the following code:
  .Sp
  .Vb 2
  \&        if (p\->q != NULL) { ... }
  \&        else if (p\->q != NULL) { ... }
  .Ve
! .IP \fB\-Wframe\-address\fR 4
  .IX Item "-Wframe-address"
  Warn when the \fB_\|_builtin_frame_address\fR or \fB_\|_builtin_return_address\fR
  is called with an argument greater than 0.  Such calls may return indeterminate
  values or crash the program.  The warning is included in \fB\-Wall\fR.
! .IP "\fB\-Wno\-discarded\-qualifiers\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-discarded-qualifiers (C and Objective-C only)"
  Do not warn if type qualifiers on pointers are being discarded.
  Typically, the compiler warns if a \f(CW\*(C`const char *\*(C'\fR variable is
  passed to a function that takes a \f(CW\*(C`char *\*(C'\fR parameter.  This option
  can be used to suppress such a warning.
! .IP "\fB\-Wno\-discarded\-array\-qualifiers\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-discarded-array-qualifiers (C and Objective-C only)"
  Do not warn if type qualifiers on arrays which are pointer targets
  are being discarded.  Typically, the compiler warns if a
  \&\f(CW\*(C`const int (*)[]\*(C'\fR variable is passed to a function that
  takes a \f(CW\*(C`int (*)[]\*(C'\fR parameter.  This option can be used to
  suppress such a warning.
! .IP "\fB\-Wno\-incompatible\-pointer\-types\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-incompatible-pointer-types (C and Objective-C only)"
  Do not warn when there is a conversion between pointers that have incompatible
  types.  This warning is for cases not covered by \fB\-Wno\-pointer\-sign\fR,
  which warns for pointer argument passing or assignment with different
  signedness.
! .IP "\fB\-Wno\-int\-conversion\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-int-conversion (C and Objective-C only)"
  Do not warn about incompatible integer to pointer and pointer to integer
  conversions.  This warning is about implicit conversions; for explicit
  conversions the warnings \fB\-Wno\-int\-to\-pointer\-cast\fR and
  \&\fB\-Wno\-pointer\-to\-int\-cast\fR may be used.
! .IP \fB\-Wzero\-length\-bounds\fR 4
  .IX Item "-Wzero-length-bounds"
! Warn about accesses to elements of zero\-length array members that might
! overlap other members of the same object.  Declaring interior zero\-length
  arrays is discouraged because accesses to them are undefined.
  .Sp
  For example, the first two stores in function \f(CW\*(C`bad\*(C'\fR are diagnosed
*************** because it is beyond the bounds of the e
*** 7927,7950 ****
  .Ve
  .Sp
  Option \fB\-Wzero\-length\-bounds\fR is enabled by \fB\-Warray\-bounds\fR.
! .IP "\fB\-Wno\-div\-by\-zero\fR" 4
  .IX Item "-Wno-div-by-zero"
! Do not warn about compile-time integer division by zero.  Floating-point
  division by zero is not warned about, as it can be a legitimate way of
  obtaining infinities and NaNs.
! .IP "\fB\-Wsystem\-headers\fR" 4
  .IX Item "-Wsystem-headers"
  Print warning messages for constructs found in system header files.
  Warnings from system headers are normally suppressed, on the assumption
  that they usually do not indicate real problems and would only make the
! compiler output harder to read.  Using this command-line option tells
! \&\s-1GCC\s0 to emit warnings from system headers as if they occurred in user
  code.  However, note that using \fB\-Wall\fR in conjunction with this
  option does \fInot\fR warn about unknown pragmas in system
  headers\-\-\-for that, \fB\-Wunknown\-pragmas\fR must also be used.
! .IP "\fB\-Wtautological\-compare\fR" 4
  .IX Item "-Wtautological-compare"
! Warn if a self-comparison always evaluates to true or false.  This
  warning detects various mistakes such as:
  .Sp
  .Vb 3
--- 7856,7879 ----
  .Ve
  .Sp
  Option \fB\-Wzero\-length\-bounds\fR is enabled by \fB\-Warray\-bounds\fR.
! .IP \fB\-Wno\-div\-by\-zero\fR 4
  .IX Item "-Wno-div-by-zero"
! Do not warn about compile\-time integer division by zero.  Floating\-point
  division by zero is not warned about, as it can be a legitimate way of
  obtaining infinities and NaNs.
! .IP \fB\-Wsystem\-headers\fR 4
  .IX Item "-Wsystem-headers"
  Print warning messages for constructs found in system header files.
  Warnings from system headers are normally suppressed, on the assumption
  that they usually do not indicate real problems and would only make the
! compiler output harder to read.  Using this command\-line option tells
! GCC to emit warnings from system headers as if they occurred in user
  code.  However, note that using \fB\-Wall\fR in conjunction with this
  option does \fInot\fR warn about unknown pragmas in system
  headers\-\-\-for that, \fB\-Wunknown\-pragmas\fR must also be used.
! .IP \fB\-Wtautological\-compare\fR 4
  .IX Item "-Wtautological-compare"
! Warn if a self\-comparison always evaluates to true or false.  This
  warning detects various mistakes such as:
  .Sp
  .Vb 3
*************** to true or false, for instance:
*** 7963,7969 ****
  will always be false.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wtrampolines\fR" 4
  .IX Item "-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
--- 7892,7898 ----
  will always be false.
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wtrampolines\fR 4
  .IX Item "-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
*************** used to call the nested function indirec
*** 7972,8002 ****
  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.
! .IP "\fB\-Wfloat\-equal\fR" 4
  .IX Item "-Wfloat-equal"
! Warn if floating-point values are used in equality comparisons.
  .Sp
  The idea behind this is that sometimes it is convenient (for the
! programmer) to consider floating-point values as approximations to
  infinitely precise real numbers.  If you are doing this, then you need
  to compute (by analyzing the code, or in some other way) the maximum or
  likely maximum error that the computation introduces, and allow for it
! when performing comparisons (and when producing output, but that's a
  different problem).  In particular, instead of testing for equality, you
  should check to see whether the two values have ranges that overlap; and
  this is done with the relational operators, so equality comparisons are
  probably mistaken.
! .IP "\fB\-Wtraditional\fR (C and Objective-C only)" 4
  .IX Item "-Wtraditional (C and Objective-C only)"
  Warn about certain constructs that behave differently in traditional and
! \&\s-1ISO C.\s0  Also warn about \s-1ISO C\s0 constructs that have no traditional C
  equivalent, and/or problematic constructs that should be avoided.
  .RS 4
! .IP "*" 4
  Macro parameters that appear within string literals in the macro body.
  In traditional C macro replacement takes place within string literals,
! but in \s-1ISO C\s0 it does not.
! .IP "*" 4
  In traditional C, some preprocessor directives did not exist.
  Traditional preprocessors only considered a line to be a directive
  if the \fB#\fR appeared in column 1 on the line.  Therefore
--- 7901,7931 ----
  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.
! .IP \fB\-Wfloat\-equal\fR 4
  .IX Item "-Wfloat-equal"
! Warn if floating\-point values are used in equality comparisons.
  .Sp
  The idea behind this is that sometimes it is convenient (for the
! programmer) to consider floating\-point values as approximations to
  infinitely precise real numbers.  If you are doing this, then you need
  to compute (by analyzing the code, or in some other way) the maximum or
  likely maximum error that the computation introduces, and allow for it
! when performing comparisons (and when producing output, but that\*(Aqs a
  different problem).  In particular, instead of testing for equality, you
  should check to see whether the two values have ranges that overlap; and
  this is done with the relational operators, so equality comparisons are
  probably mistaken.
! .IP "\fB\-Wtraditional\fR (C and Objective\-C only)" 4
  .IX Item "-Wtraditional (C and Objective-C only)"
  Warn about certain constructs that behave differently in traditional and
! ISO C.  Also warn about ISO C constructs that have no traditional C
  equivalent, and/or problematic constructs that should be avoided.
  .RS 4
! .IP * 4
  Macro parameters that appear within string literals in the macro body.
  In traditional C macro replacement takes place within string literals,
! but in ISO C it does not.
! .IP * 4
  In traditional C, some preprocessor directives did not exist.
  Traditional preprocessors only considered a line to be a directive
  if the \fB#\fR appeared in column 1 on the line.  Therefore
*************** first character on the line.  It also su
*** 8006,8104 ****
  \&\f(CW\*(C`#pragma\*(C'\fR not understood by traditional C by indenting them.  Some
  traditional implementations do not recognize \f(CW\*(C`#elif\*(C'\fR, so this option
  suggests avoiding it altogether.
! .IP "*" 4
! A function-like macro that appears without arguments.
! .IP "*" 4
  The unary plus operator.
! .IP "*" 4
! The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating-point
  constant suffixes.  (Traditional C does support the \fBL\fR suffix on integer
  constants.)  Note, these suffixes appear in macros defined in the system
  headers of most modern systems, e.g. the \fB_MIN\fR/\fB_MAX\fR macros in \f(CW\*(C`\*(C'\fR.
  Use of these macros in user code might normally lead to spurious
! warnings, however \s-1GCC\s0's integrated preprocessor has enough context to
  avoid warning in these cases.
! .IP "*" 4
  A function declared external in one block and then used after the end of
  the block.
! .IP "*" 4
  A \f(CW\*(C`switch\*(C'\fR statement has an operand of type \f(CW\*(C`long\*(C'\fR.
! .IP "*" 4
  A non\-\f(CW\*(C`static\*(C'\fR function declaration follows a \f(CW\*(C`static\*(C'\fR one.
  This construct is not accepted by some traditional C compilers.
! .IP "*" 4
! The \s-1ISO\s0 type of an integer constant has a different width or
  signedness from its traditional type.  This warning is only issued if
  the base of the constant is ten.  I.e. hexadecimal or octal values, which
  typically represent bit patterns, are not warned about.
! .IP "*" 4
! Usage of \s-1ISO\s0 string concatenation is detected.
! .IP "*" 4
  Initialization of automatic aggregates.
! .IP "*" 4
  Identifier conflicts with labels.  Traditional C lacks a separate
  namespace for labels.
! .IP "*" 4
  Initialization of unions.  If the initializer is zero, the warning is
  omitted.  This is done under the assumption that the zero initializer in
  user code appears conditioned on e.g. \f(CW\*(C`_\|_STDC_\|_\*(C'\fR to avoid missing
  initializer warnings and relies on default initialization to zero in the
  traditional C case.
! .IP "*" 4
  Conversions by prototypes between fixed/floating\-point values and vice
  versa.  The absence of these prototypes when compiling with traditional
  C causes serious problems.  This is a subset of the possible
  conversion warnings; for the full set use \fB\-Wtraditional\-conversion\fR.
! .IP "*" 4
! Use of \s-1ISO C\s0 style function definitions.  This warning intentionally is
  \&\fInot\fR issued for prototype declarations or variadic functions
! because these \s-1ISO C\s0 features appear in your code when using
! libiberty's traditional C compatibility macros, \f(CW\*(C`PARAMS\*(C'\fR and
  \&\f(CW\*(C`VPARAMS\*(C'\fR.  This warning is also bypassed for nested functions
! because that feature is already a \s-1GCC\s0 extension and thus not relevant to
  traditional C compatibility.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wtraditional\-conversion\fR (C and Objective-C only)" 4
  .IX Item "-Wtraditional-conversion (C and Objective-C only)"
  Warn if a prototype causes a type conversion that is different from what
  would happen to the same argument in the absence of a prototype.  This
  includes conversions of fixed point to floating and vice versa, and
! conversions changing the width or signedness of a fixed-point argument
  except when the same as the default promotion.
! .IP "\fB\-Wdeclaration\-after\-statement\fR (C and Objective-C only)" 4
  .IX Item "-Wdeclaration-after-statement (C and Objective-C only)"
  Warn when a declaration is found after a statement in a block.  This
! construct, known from \*(C+, was introduced with \s-1ISO C99\s0 and is by default
! allowed in \s-1GCC.\s0  It is not supported by \s-1ISO C90.\s0
! .IP "\fB\-Wshadow\fR" 4
  .IX Item "-Wshadow"
  Warn whenever a local variable or type declaration shadows another
! variable, parameter, type, class member (in \*(C+), or instance variable
! (in Objective-C) or whenever a built-in function is shadowed.  Note
! that in \*(C+, the compiler warns if a local variable shadows an
  explicit typedef, but not if it shadows a struct/class/enum.
  If this warning is enabled, it includes also all instances of
  local shadowing.  This means that \fB\-Wno\-shadow=local\fR
  and \fB\-Wno\-shadow=compatible\-local\fR are ignored when
  \&\fB\-Wshadow\fR is used.
  Same as \fB\-Wshadow=global\fR.
! .IP "\fB\-Wno\-shadow\-ivar\fR (Objective-C only)" 4
  .IX Item "-Wno-shadow-ivar (Objective-C only)"
  Do not warn whenever a local variable shadows an instance variable in an
! Objective-C method.
! .IP "\fB\-Wshadow=global\fR" 4
  .IX Item "-Wshadow=global"
  Warn for any shadowing.
  Same as \fB\-Wshadow\fR.
! .IP "\fB\-Wshadow=local\fR" 4
  .IX Item "-Wshadow=local"
  Warn when a local variable shadows another local variable or parameter.
! .IP "\fB\-Wshadow=compatible\-local\fR" 4
  .IX Item "-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 \fB\-Wshadow=local\fR) is based on the idea that when
--- 7935,8033 ----
  \&\f(CW\*(C`#pragma\*(C'\fR not understood by traditional C by indenting them.  Some
  traditional implementations do not recognize \f(CW\*(C`#elif\*(C'\fR, so this option
  suggests avoiding it altogether.
! .IP * 4
! A function\-like macro that appears without arguments.
! .IP * 4
  The unary plus operator.
! .IP * 4
! The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating\-point
  constant suffixes.  (Traditional C does support the \fBL\fR suffix on integer
  constants.)  Note, these suffixes appear in macros defined in the system
  headers of most modern systems, e.g. the \fB_MIN\fR/\fB_MAX\fR macros in \f(CW\*(C`\*(C'\fR.
  Use of these macros in user code might normally lead to spurious
! warnings, however GCC\*(Aqs integrated preprocessor has enough context to
  avoid warning in these cases.
! .IP * 4
  A function declared external in one block and then used after the end of
  the block.
! .IP * 4
  A \f(CW\*(C`switch\*(C'\fR statement has an operand of type \f(CW\*(C`long\*(C'\fR.
! .IP * 4
  A non\-\f(CW\*(C`static\*(C'\fR function declaration follows a \f(CW\*(C`static\*(C'\fR one.
  This construct is not accepted by some traditional C compilers.
! .IP * 4
! 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.
! .IP * 4
! Usage of ISO string concatenation is detected.
! .IP * 4
  Initialization of automatic aggregates.
! .IP * 4
  Identifier conflicts with labels.  Traditional C lacks a separate
  namespace for labels.
! .IP * 4
  Initialization of unions.  If the initializer is zero, the warning is
  omitted.  This is done under the assumption that the zero initializer in
  user code appears conditioned on e.g. \f(CW\*(C`_\|_STDC_\|_\*(C'\fR to avoid missing
  initializer warnings and relies on default initialization to zero in the
  traditional C case.
! .IP * 4
  Conversions by prototypes between fixed/floating\-point values and vice
  versa.  The absence of these prototypes when compiling with traditional
  C causes serious problems.  This is a subset of the possible
  conversion warnings; for the full set use \fB\-Wtraditional\-conversion\fR.
! .IP * 4
! Use of ISO C style function definitions.  This warning intentionally is
  \&\fInot\fR issued for prototype declarations or variadic functions
! because these ISO C features appear in your code when using
! libiberty\*(Aqs traditional C compatibility macros, \f(CW\*(C`PARAMS\*(C'\fR and
  \&\f(CW\*(C`VPARAMS\*(C'\fR.  This warning is also bypassed for nested functions
! because that feature is already a GCC extension and thus not relevant to
  traditional C compatibility.
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wtraditional\-conversion\fR (C and Objective\-C only)" 4
  .IX Item "-Wtraditional-conversion (C and Objective-C only)"
  Warn if a prototype causes a type conversion that is different from what
  would happen to the same argument in the absence of a prototype.  This
  includes conversions of fixed point to floating and vice versa, and
! conversions changing the width or signedness of a fixed\-point argument
  except when the same as the default promotion.
! .IP "\fB\-Wdeclaration\-after\-statement\fR (C and Objective\-C only)" 4
  .IX Item "-Wdeclaration-after-statement (C and Objective-C only)"
  Warn when a declaration is found after a statement in a block.  This
! construct, known from C++, was introduced with ISO C99 and is by default
! allowed in GCC.  It is not supported by ISO C90.
! .IP \fB\-Wshadow\fR 4
  .IX Item "-Wshadow"
  Warn whenever a local variable or type declaration shadows another
! variable, parameter, type, class member (in C++), or instance variable
! (in Objective\-C) or whenever a built\-in function is shadowed.  Note
! that in C++, the compiler warns if a local variable shadows an
  explicit typedef, but not if it shadows a struct/class/enum.
  If this warning is enabled, it includes also all instances of
  local shadowing.  This means that \fB\-Wno\-shadow=local\fR
  and \fB\-Wno\-shadow=compatible\-local\fR are ignored when
  \&\fB\-Wshadow\fR is used.
  Same as \fB\-Wshadow=global\fR.
! .IP "\fB\-Wno\-shadow\-ivar\fR (Objective\-C only)" 4
  .IX Item "-Wno-shadow-ivar (Objective-C only)"
  Do not warn whenever a local variable shadows an instance variable in an
! Objective\-C method.
! .IP \fB\-Wshadow=global\fR 4
  .IX Item "-Wshadow=global"
  Warn for any shadowing.
  Same as \fB\-Wshadow\fR.
! .IP \fB\-Wshadow=local\fR 4
  .IX Item "-Wshadow=local"
  Warn when a local variable shadows another local variable or parameter.
! .IP \fB\-Wshadow=compatible\-local\fR 4
  .IX Item "-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 \fB\-Wshadow=local\fR) is based on the idea that when
*************** Note that this also means that shadowing
*** 8126,8165 ****
  \&\f(CW\*(C`char *i\*(C'\fR does not emit a warning.
  .Sp
  This warning is also enabled by \fB\-Wshadow=local\fR.
! .IP "\fB\-Wlarger\-than=\fR\fIbyte-size\fR" 4
  .IX Item "-Wlarger-than=byte-size"
! Warn whenever an object is defined whose size exceeds \fIbyte-size\fR.
! \&\fB\-Wlarger\-than=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte-size\fR of \fB\s-1SIZE_MAX\s0\fR or more or by \fB\-Wno\-larger\-than\fR.
  .Sp
  Also warn for calls to bounded functions such as \f(CW\*(C`memchr\*(C'\fR or
  \&\f(CW\*(C`strnlen\*(C'\fR that specify a bound greater than the largest possible
! object, which is \fB\s-1PTRDIFF_MAX\s0\fR bytes by default.  These warnings
  can only be disabled by \fB\-Wno\-larger\-than\fR.
! .IP "\fB\-Wno\-larger\-than\fR" 4
  .IX Item "-Wno-larger-than"
  Disable \fB\-Wlarger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wlarger\-than=\fR\fB\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Wframe\-larger\-than=\fR\fIbyte-size\fR" 4
  .IX Item "-Wframe-larger-than=byte-size"
! Warn if the size of a function frame exceeds \fIbyte-size\fR.
  The computation done to determine the stack frame size is approximate
  and not conservative.
! The actual requirements may be somewhat greater than \fIbyte-size\fR
  even if you do not get a warning.  In addition, any space allocated
! via \f(CW\*(C`alloca\*(C'\fR, variable-length arrays, or related constructs
  is not included by the compiler when determining
  whether or not to issue a warning.
! \&\fB\-Wframe\-larger\-than=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte-size\fR of \fB\s-1SIZE_MAX\s0\fR or more or by
  \&\fB\-Wno\-frame\-larger\-than\fR.
! .IP "\fB\-Wno\-frame\-larger\-than\fR" 4
  .IX Item "-Wno-frame-larger-than"
  Disable \fB\-Wframe\-larger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wframe\-larger\-than=\fR\fB\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Wfree\-nonheap\-object\fR" 4
  .IX Item "-Wfree-nonheap-object"
  Warn when attempting to deallocate an object that was either not allocated
  on the heap, or by using a pointer that was not returned from a prior call
--- 8055,8094 ----
  \&\f(CW\*(C`char *i\*(C'\fR does not emit a warning.
  .Sp
  This warning is also enabled by \fB\-Wshadow=local\fR.
! .IP \fB\-Wlarger\-than=\fR\fIbyte\-size\fR 4
  .IX Item "-Wlarger-than=byte-size"
! Warn whenever an object is defined whose size exceeds \fIbyte\-size\fR.
! \&\fB\-Wlarger\-than=\fR\fBPTRDIFF_MAX\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte\-size\fR of \fBSIZE_MAX\fR or more or by \fB\-Wno\-larger\-than\fR.
  .Sp
  Also warn for calls to bounded functions such as \f(CW\*(C`memchr\*(C'\fR or
  \&\f(CW\*(C`strnlen\*(C'\fR that specify a bound greater than the largest possible
! object, which is \fBPTRDIFF_MAX\fR bytes by default.  These warnings
  can only be disabled by \fB\-Wno\-larger\-than\fR.
! .IP \fB\-Wno\-larger\-than\fR 4
  .IX Item "-Wno-larger-than"
  Disable \fB\-Wlarger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wlarger\-than=\fR\fBSIZE_MAX\fR or larger.
! .IP \fB\-Wframe\-larger\-than=\fR\fIbyte\-size\fR 4
  .IX Item "-Wframe-larger-than=byte-size"
! Warn if the size of a function frame exceeds \fIbyte\-size\fR.
  The computation done to determine the stack frame size is approximate
  and not conservative.
! The actual requirements may be somewhat greater than \fIbyte\-size\fR
  even if you do not get a warning.  In addition, any space allocated
! via \f(CW\*(C`alloca\*(C'\fR, variable\-length arrays, or related constructs
  is not included by the compiler when determining
  whether or not to issue a warning.
! \&\fB\-Wframe\-larger\-than=\fR\fBPTRDIFF_MAX\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte\-size\fR of \fBSIZE_MAX\fR or more or by
  \&\fB\-Wno\-frame\-larger\-than\fR.
! .IP \fB\-Wno\-frame\-larger\-than\fR 4
  .IX Item "-Wno-frame-larger-than"
  Disable \fB\-Wframe\-larger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wframe\-larger\-than=\fR\fBSIZE_MAX\fR or larger.
! .IP \fB\-Wfree\-nonheap\-object\fR 4
  .IX Item "-Wfree-nonheap-object"
  Warn when attempting to deallocate an object that was either not allocated
  on the heap, or by using a pointer that was not returned from a prior call
*************** diagnosed.
*** 8178,8207 ****
  .Ve
  .Sp
  \&\fB\-Wfree\-nonheap\-object\fR is included in \fB\-Wall\fR.
! .IP "\fB\-Wstack\-usage=\fR\fIbyte-size\fR" 4
  .IX Item "-Wstack-usage=byte-size"
! Warn if the stack usage of a function might exceed \fIbyte-size\fR.
  The computation done to determine the stack usage is conservative.
! Any space allocated via \f(CW\*(C`alloca\*(C'\fR, variable-length arrays, or related
  constructs is included by the compiler when determining whether or not to
  issue a warning.
  .Sp
  The message is in keeping with the output of \fB\-fstack\-usage\fR.
  .RS 4
! .IP "*" 4
! If the stack usage is fully static but exceeds the specified amount, it's:
  .Sp
  .Vb 1
  \&          warning: stack usage is 1120 bytes
  .Ve
! .IP "*" 4
! If the stack usage is (partly) dynamic but bounded, it's:
  .Sp
  .Vb 1
  \&          warning: stack usage might be 1648 bytes
  .Ve
! .IP "*" 4
! If the stack usage is (partly) dynamic and not bounded, it's:
  .Sp
  .Vb 1
  \&          warning: stack usage might be unbounded
--- 8107,8136 ----
  .Ve
  .Sp
  \&\fB\-Wfree\-nonheap\-object\fR is included in \fB\-Wall\fR.
! .IP \fB\-Wstack\-usage=\fR\fIbyte\-size\fR 4
  .IX Item "-Wstack-usage=byte-size"
! Warn if the stack usage of a function might exceed \fIbyte\-size\fR.
  The computation done to determine the stack usage is conservative.
! Any space allocated via \f(CW\*(C`alloca\*(C'\fR, variable\-length arrays, or related
  constructs is included by the compiler when determining whether or not to
  issue a warning.
  .Sp
  The message is in keeping with the output of \fB\-fstack\-usage\fR.
  .RS 4
! .IP * 4
! If the stack usage is fully static but exceeds the specified amount, it\*(Aqs:
  .Sp
  .Vb 1
  \&          warning: stack usage is 1120 bytes
  .Ve
! .IP * 4
! If the stack usage is (partly) dynamic but bounded, it\*(Aqs:
  .Sp
  .Vb 1
  \&          warning: stack usage might be 1648 bytes
  .Ve
! .IP * 4
! If the stack usage is (partly) dynamic and not bounded, it\*(Aqs:
  .Sp
  .Vb 1
  \&          warning: stack usage might be unbounded
*************** If the stack usage is (partly) dynamic a
*** 8209,8224 ****
  .RE
  .RS 4
  .Sp
! \&\fB\-Wstack\-usage=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte-size\fR of \fB\s-1SIZE_MAX\s0\fR or more or by
  \&\fB\-Wno\-stack\-usage\fR.
  .RE
! .IP "\fB\-Wno\-stack\-usage\fR" 4
  .IX Item "-Wno-stack-usage"
  Disable \fB\-Wstack\-usage=\fR warnings.  The option is equivalent
! to \fB\-Wstack\-usage=\fR\fB\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Wunsafe\-loop\-optimizations\fR" 4
  .IX Item "-Wunsafe-loop-optimizations"
  Warn if the loop cannot be optimized because the compiler cannot
  assume anything on the bounds of the loop indices.  With
--- 8138,8153 ----
  .RE
  .RS 4
  .Sp
! \&\fB\-Wstack\-usage=\fR\fBPTRDIFF_MAX\fR is enabled by default.
  Warnings controlled by the option can be disabled either by specifying
! \&\fIbyte\-size\fR of \fBSIZE_MAX\fR or more or by
  \&\fB\-Wno\-stack\-usage\fR.
  .RE
! .IP \fB\-Wno\-stack\-usage\fR 4
  .IX Item "-Wno-stack-usage"
  Disable \fB\-Wstack\-usage=\fR warnings.  The option is equivalent
! to \fB\-Wstack\-usage=\fR\fBSIZE_MAX\fR or larger.
! .IP \fB\-Wunsafe\-loop\-optimizations\fR 4
  .IX Item "-Wunsafe-loop-optimizations"
  Warn if the loop cannot be optimized because the compiler cannot
  assume anything on the bounds of the loop indices.  With
*************** such assumptions.
*** 8227,8244 ****
  .IP "\fB\-Wno\-pedantic\-ms\-format\fR (MinGW targets only)" 4
  .IX Item "-Wno-pedantic-ms-format (MinGW targets only)"
  When used in combination with \fB\-Wformat\fR
! and \fB\-pedantic\fR without \s-1GNU\s0 extensions, this option
! disables the warnings about non-ISO \f(CW\*(C`printf\*(C'\fR / \f(CW\*(C`scanf\*(C'\fR format
  width specifiers \f(CW\*(C`I32\*(C'\fR, \f(CW\*(C`I64\*(C'\fR, and \f(CW\*(C`I\*(C'\fR used on Windows targets,
! which depend on the \s-1MS\s0 runtime.
! .IP "\fB\-Wpointer\-arith\fR" 4
  .IX Item "-Wpointer-arith"
! Warn about anything that depends on the \*(L"size of\*(R" a function type or
! of \f(CW\*(C`void\*(C'\fR.  \s-1GNU C\s0 assigns these types a size of 1, for
  convenience in calculations with \f(CW\*(C`void *\*(C'\fR pointers and pointers
! to functions.  In \*(C+, warn also when an arithmetic operation involves
  \&\f(CW\*(C`NULL\*(C'\fR.  This warning is also enabled by \fB\-Wpedantic\fR.
! .IP "\fB\-Wno\-pointer\-compare\fR" 4
  .IX Item "-Wno-pointer-compare"
  Do not warn if a pointer is compared with a zero character constant.
  This usually
--- 8156,8173 ----
  .IP "\fB\-Wno\-pedantic\-ms\-format\fR (MinGW targets only)" 4
  .IX Item "-Wno-pedantic-ms-format (MinGW targets only)"
  When used in combination with \fB\-Wformat\fR
! and \fB\-pedantic\fR without GNU extensions, this option
! disables the warnings about non\-ISO \f(CW\*(C`printf\*(C'\fR / \f(CW\*(C`scanf\*(C'\fR format
  width specifiers \f(CW\*(C`I32\*(C'\fR, \f(CW\*(C`I64\*(C'\fR, and \f(CW\*(C`I\*(C'\fR used on Windows targets,
! which depend on the MS runtime.
! .IP \fB\-Wpointer\-arith\fR 4
  .IX Item "-Wpointer-arith"
! Warn about anything that depends on the "size of" a function type or
! of \f(CW\*(C`void\*(C'\fR.  GNU C assigns these types a size of 1, for
  convenience in calculations with \f(CW\*(C`void *\*(C'\fR pointers and pointers
! to functions.  In C++, warn also when an arithmetic operation involves
  \&\f(CW\*(C`NULL\*(C'\fR.  This warning is also enabled by \fB\-Wpedantic\fR.
! .IP \fB\-Wno\-pointer\-compare\fR 4
  .IX Item "-Wno-pointer-compare"
  Do not warn if a pointer is compared with a zero character constant.
  This usually
*************** means that the pointer was meant to be d
*** 8250,8259 ****
  \&          return 42;
  .Ve
  .Sp
! Note that the code above is invalid in \*(C+11.
  .Sp
  This warning is enabled by default.
! .IP "\fB\-Wtsan\fR" 4
  .IX Item "-Wtsan"
  Warn about unsupported features in ThreadSanitizer.
  .Sp
--- 8179,8188 ----
  \&          return 42;
  .Ve
  .Sp
! Note that the code above is invalid in C++11.
  .Sp
  This warning is enabled by default.
! .IP \fB\-Wtsan\fR 4
  .IX Item "-Wtsan"
  Warn about unsupported features in ThreadSanitizer.
  .Sp
*************** ThreadSanitizer does not support \f(CW\*
*** 8261,8293 ****
  can report false positives.
  .Sp
  This warning is enabled by default.
! .IP "\fB\-Wtype\-limits\fR" 4
  .IX Item "-Wtype-limits"
  Warn if a comparison is always true or always false due to the limited
  range of the data type, but do not warn for constant expressions.  For
  example, warn if an unsigned variable is compared against zero with
  \&\f(CW\*(C`<\*(C'\fR or \f(CW\*(C`>=\*(C'\fR.  This warning is also enabled by
  \&\fB\-Wextra\fR.
! .IP "\fB\-Wabsolute\-value\fR (C and Objective-C only)" 4
  .IX Item "-Wabsolute-value (C and Objective-C only)"
  Warn for calls to standard functions that compute the absolute value
  of an argument when a more appropriate standard function is available.
! For example, calling \f(CW\*(C`abs(3.14)\*(C'\fR triggers the warning because the
  appropriate function to call to compute the absolute value of a double
  argument is \f(CW\*(C`fabs\*(C'\fR.  The option also triggers warnings when the
  argument in a call to such a function has an unsigned type.  This
  warning can be suppressed with an explicit type cast and it is also
  enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wcomment\fR" 4
  .IX Item "-Wcomment"
  .PD 0
! .IP "\fB\-Wcomments\fR" 4
  .IX Item "-Wcomments"
  .PD
! Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
! comment, or whenever a backslash-newline appears in a \fB//\fR comment.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wtrigraphs\fR" 4
  .IX Item "-Wtrigraphs"
  Warn if any trigraphs are encountered that might change the meaning of
  the program.  Trigraphs within comments are not warned about,
--- 8190,8222 ----
  can report false positives.
  .Sp
  This warning is enabled by default.
! .IP \fB\-Wtype\-limits\fR 4
  .IX Item "-Wtype-limits"
  Warn if a comparison is always true or always false due to the limited
  range of the data type, but do not warn for constant expressions.  For
  example, warn if an unsigned variable is compared against zero with
  \&\f(CW\*(C`<\*(C'\fR or \f(CW\*(C`>=\*(C'\fR.  This warning is also enabled by
  \&\fB\-Wextra\fR.
! .IP "\fB\-Wabsolute\-value\fR (C and Objective\-C only)" 4
  .IX Item "-Wabsolute-value (C and Objective-C only)"
  Warn for calls to standard functions that compute the absolute value
  of an argument when a more appropriate standard function is available.
! For example, calling \f(CWabs(3.14)\fR triggers the warning because the
  appropriate function to call to compute the absolute value of a double
  argument is \f(CW\*(C`fabs\*(C'\fR.  The option also triggers warnings when the
  argument in a call to such a function has an unsigned type.  This
  warning can be suppressed with an explicit type cast and it is also
  enabled by \fB\-Wextra\fR.
! .IP \fB\-Wcomment\fR 4
  .IX Item "-Wcomment"
  .PD 0
! .IP \fB\-Wcomments\fR 4
  .IX Item "-Wcomments"
  .PD
! Warn whenever a comment\-start sequence \fB/*\fR appears in a \fB/*\fR
! comment, or whenever a backslash\-newline appears in a \fB//\fR comment.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wtrigraphs\fR 4
  .IX Item "-Wtrigraphs"
  Warn if any trigraphs are encountered that might change the meaning of
  the program.  Trigraphs within comments are not warned about,
*************** This option is implied by \fB\-Wall\fR.
*** 8297,8325 ****
  given, this option is still enabled unless trigraphs are enabled.  To
  get trigraph conversion without warnings, but get the other
  \&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
! .IP "\fB\-Wundef\fR" 4
  .IX Item "-Wundef"
  Warn if an undefined identifier is evaluated in an \f(CW\*(C`#if\*(C'\fR directive.
  Such identifiers are replaced with zero.
! .IP "\fB\-Wexpansion\-to\-defined\fR" 4
  .IX Item "-Wexpansion-to-defined"
  Warn whenever \fBdefined\fR is encountered in the expansion of a macro
  (including the case where the macro is expanded by an \fB#if\fR directive).
  Such usage is not portable.
  This warning is also enabled by \fB\-Wpedantic\fR and \fB\-Wextra\fR.
! .IP "\fB\-Wunused\-macros\fR" 4
  .IX Item "-Wunused-macros"
  Warn about macros defined in the main file that are unused.  A macro
  is \fIused\fR if it is expanded or tested for existence at least once.
  The preprocessor also warns if the macro has not been used at the
  time it is redefined or undefined.
  .Sp
! Built-in macros, macros defined on the command line, and macros
  defined in include files are not warned about.
  .Sp
  \&\fINote:\fR If a macro is actually used, but only used in skipped
  conditional blocks, then the preprocessor reports it as unused.  To avoid the
! warning in such a case, you might improve the scope of the macro's
  definition by, for example, moving it into the first skipped block.
  Alternatively, you could provide a dummy use with something like:
  .Sp
--- 8226,8254 ----
  given, this option is still enabled unless trigraphs are enabled.  To
  get trigraph conversion without warnings, but get the other
  \&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
! .IP \fB\-Wundef\fR 4
  .IX Item "-Wundef"
  Warn if an undefined identifier is evaluated in an \f(CW\*(C`#if\*(C'\fR directive.
  Such identifiers are replaced with zero.
! .IP \fB\-Wexpansion\-to\-defined\fR 4
  .IX Item "-Wexpansion-to-defined"
  Warn whenever \fBdefined\fR is encountered in the expansion of a macro
  (including the case where the macro is expanded by an \fB#if\fR directive).
  Such usage is not portable.
  This warning is also enabled by \fB\-Wpedantic\fR and \fB\-Wextra\fR.
! .IP \fB\-Wunused\-macros\fR 4
  .IX Item "-Wunused-macros"
  Warn about macros defined in the main file that are unused.  A macro
  is \fIused\fR if it is expanded or tested for existence at least once.
  The preprocessor also warns if the macro has not been used at the
  time it is redefined or undefined.
  .Sp
! Built\-in macros, macros defined on the command line, and macros
  defined in include files are not warned about.
  .Sp
  \&\fINote:\fR If a macro is actually used, but only used in skipped
  conditional blocks, then the preprocessor reports it as unused.  To avoid the
! warning in such a case, you might improve the scope of the macro\*(Aqs
  definition by, for example, moving it into the first skipped block.
  Alternatively, you could provide a dummy use with something like:
  .Sp
*************** Alternatively, you could provide a dummy
*** 8327,8333 ****
  \&        #if defined the_macro_causing_the_warning
  \&        #endif
  .Ve
! .IP "\fB\-Wno\-endif\-labels\fR" 4
  .IX Item "-Wno-endif-labels"
  Do not warn whenever an \f(CW\*(C`#else\*(C'\fR or an \f(CW\*(C`#endif\*(C'\fR are followed by text.
  This sometimes happens in older programs with code of the form
--- 8256,8262 ----
  \&        #if defined the_macro_causing_the_warning
  \&        #endif
  .Ve
! .IP \fB\-Wno\-endif\-labels\fR 4
  .IX Item "-Wno-endif-labels"
  Do not warn whenever an \f(CW\*(C`#else\*(C'\fR or an \f(CW\*(C`#endif\*(C'\fR are followed by text.
  This sometimes happens in older programs with code of the form
*************** This sometimes happens in older programs
*** 8342,8424 ****
  .Sp
  The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments.
  This warning is on by default.
! .IP "\fB\-Wbad\-function\-cast\fR (C and Objective-C only)" 4
  .IX Item "-Wbad-function-cast (C and Objective-C only)"
! Warn when a function call is cast to a non-matching type.
  For example, warn if a call to a function returning an integer type 
  is cast to a pointer type.
! .IP "\fB\-Wc90\-c99\-compat\fR (C and Objective-C only)" 4
  .IX Item "-Wc90-c99-compat (C and Objective-C only)"
! Warn about features not present in \s-1ISO C90,\s0 but present in \s-1ISO C99.\s0
  For instance, warn about use of variable length arrays, \f(CW\*(C`long long\*(C'\fR
  type, \f(CW\*(C`bool\*(C'\fR type, compound literals, designated initializers, and so
  on.  This option is independent of the standards mode.  Warnings are disabled
  in the expression that follows \f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc99\-c11\-compat\fR (C and Objective-C only)" 4
  .IX Item "-Wc99-c11-compat (C and Objective-C only)"
! Warn about features not present in \s-1ISO C99,\s0 but present in \s-1ISO C11.\s0
  For instance, warn about use of anonymous structures and unions,
! \&\f(CW\*(C`_Atomic\*(C'\fR type qualifier, \f(CW\*(C`_Thread_local\*(C'\fR storage-class specifier,
  \&\f(CW\*(C`_Alignas\*(C'\fR specifier, \f(CW\*(C`Alignof\*(C'\fR operator, \f(CW\*(C`_Generic\*(C'\fR keyword,
  and so on.  This option is independent of the standards mode.  Warnings are
  disabled in the expression that follows \f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc11\-c2x\-compat\fR (C and Objective-C only)" 4
  .IX Item "-Wc11-c2x-compat (C and Objective-C only)"
! Warn about features not present in \s-1ISO C11,\s0 but present in \s-1ISO C2X.\s0
  For instance, warn about omitting the string in \f(CW\*(C`_Static_assert\*(C'\fR,
  use of \fB[[]]\fR syntax for attributes, use of decimal
! floating-point types, and so on.  This option is independent of the
  standards mode.  Warnings are disabled in the expression that follows
  \&\f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc++\-compat\fR (C and Objective-C only)" 4
  .IX Item "-Wc++-compat (C and Objective-C only)"
! Warn about \s-1ISO C\s0 constructs that are outside of the common subset of
! \&\s-1ISO C\s0 and \s-1ISO \*(C+,\s0 e.g. request for implicit conversion from
  \&\f(CW\*(C`void *\*(C'\fR to a pointer to non\-\f(CW\*(C`void\*(C'\fR type.
! .IP "\fB\-Wc++11\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wc++11-compat ( and Objective- only)"
! Warn about \*(C+ constructs whose meaning differs between \s-1ISO \*(C+ 1998\s0
! and \s-1ISO \*(C+ 2011,\s0 e.g., identifiers in \s-1ISO \*(C+ 1998\s0 that are keywords
! in \s-1ISO \*(C+ 2011.\s0  This warning turns on \fB\-Wnarrowing\fR and is
  enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++14\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wc++14-compat ( and Objective- only)"
! Warn about \*(C+ constructs whose meaning differs between \s-1ISO \*(C+ 2011\s0
! and \s-1ISO \*(C+ 2014.\s0  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++17\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wc++17-compat ( and Objective- only)"
! Warn about \*(C+ constructs whose meaning differs between \s-1ISO \*(C+ 2014\s0
! and \s-1ISO \*(C+ 2017.\s0  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++20\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wc++20-compat ( and Objective- only)"
! Warn about \*(C+ constructs whose meaning differs between \s-1ISO \*(C+ 2017\s0
! and \s-1ISO \*(C+ 2020.\s0  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-c++11\-extensions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-c++11-extensions ( and Objective- only)"
! Do not warn about \*(C+11 constructs in code being compiled using
! an older \*(C+ standard.  Even without this option, some \*(C+11 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++14\-extensions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-c++14-extensions ( and Objective- only)"
! Do not warn about \*(C+14 constructs in code being compiled using
! an older \*(C+ standard.  Even without this option, some \*(C+14 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++17\-extensions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-c++17-extensions ( and Objective- only)"
! Do not warn about \*(C+17 constructs in code being compiled using
! an older \*(C+ standard.  Even without this option, some \*(C+17 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++20\-extensions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-c++20-extensions ( and Objective- only)"
! Do not warn about \*(C+20 constructs in code being compiled using
! an older \*(C+ standard.  Even without this option, some \*(C+20 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++23\-extensions\fR (\*(C+ and Objective\-\*(C+ only)" 4
! .IX Item "-Wno-c++23-extensions ( and Objective- only)"
! Do not warn about \*(C+23 constructs in code being compiled using
! an older \*(C+ standard.  Even without this option, some \*(C+23 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wcast\-qual\fR" 4
  .IX Item "-Wcast-qual"
  Warn whenever a pointer is cast so as to remove a type qualifier from
  the target type.  For example, warn if a \f(CW\*(C`const char *\*(C'\fR is cast
--- 8271,8353 ----
  .Sp
  The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments.
  This warning is on by default.
! .IP "\fB\-Wbad\-function\-cast\fR (C and Objective\-C only)" 4
  .IX Item "-Wbad-function-cast (C and Objective-C only)"
! Warn when a function call is cast to a non\-matching type.
  For example, warn if a call to a function returning an integer type 
  is cast to a pointer type.
! .IP "\fB\-Wc90\-c99\-compat\fR (C and Objective\-C only)" 4
  .IX Item "-Wc90-c99-compat (C and Objective-C only)"
! Warn about features not present in ISO C90, but present in ISO C99.
  For instance, warn about use of variable length arrays, \f(CW\*(C`long long\*(C'\fR
  type, \f(CW\*(C`bool\*(C'\fR type, compound literals, designated initializers, and so
  on.  This option is independent of the standards mode.  Warnings are disabled
  in the expression that follows \f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc99\-c11\-compat\fR (C and Objective\-C only)" 4
  .IX Item "-Wc99-c11-compat (C and Objective-C only)"
! Warn about features not present in ISO C99, but present in ISO C11.
  For instance, warn about use of anonymous structures and unions,
! \&\f(CW\*(C`_Atomic\*(C'\fR type qualifier, \f(CW\*(C`_Thread_local\*(C'\fR storage\-class specifier,
  \&\f(CW\*(C`_Alignas\*(C'\fR specifier, \f(CW\*(C`Alignof\*(C'\fR operator, \f(CW\*(C`_Generic\*(C'\fR keyword,
  and so on.  This option is independent of the standards mode.  Warnings are
  disabled in the expression that follows \f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc11\-c2x\-compat\fR (C and Objective\-C only)" 4
  .IX Item "-Wc11-c2x-compat (C and Objective-C only)"
! Warn about features not present in ISO C11, but present in ISO C2X.
  For instance, warn about omitting the string in \f(CW\*(C`_Static_assert\*(C'\fR,
  use of \fB[[]]\fR syntax for attributes, use of decimal
! floating\-point types, and so on.  This option is independent of the
  standards mode.  Warnings are disabled in the expression that follows
  \&\f(CW\*(C`_\|_extension_\|_\*(C'\fR.
! .IP "\fB\-Wc++\-compat\fR (C and Objective\-C only)" 4
  .IX Item "-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
  \&\f(CW\*(C`void *\*(C'\fR to a pointer to non\-\f(CW\*(C`void\*(C'\fR type.
! .IP "\fB\-Wc++11\-compat\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wc++11-compat (C++ and Objective-C++ only)"
! Warn about C++ constructs whose meaning differs between ISO C++ 1998
! and ISO C++ 2011, e.g., identifiers in ISO C++ 1998 that are keywords
! in ISO C++ 2011.  This warning turns on \fB\-Wnarrowing\fR and is
  enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++14\-compat\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wc++14-compat (C++ and Objective-C++ only)"
! Warn about C++ constructs whose meaning differs between ISO C++ 2011
! and ISO C++ 2014.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++17\-compat\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wc++17-compat (C++ and Objective-C++ only)"
! Warn about C++ constructs whose meaning differs between ISO C++ 2014
! and ISO C++ 2017.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wc++20\-compat\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wc++20-compat (C++ and Objective-C++ only)"
! Warn about C++ constructs whose meaning differs between ISO C++ 2017
! and ISO C++ 2020.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-c++11\-extensions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-c++11-extensions (C++ and Objective-C++ only)"
! Do not warn about C++11 constructs in code being compiled using
! an older C++ standard.  Even without this option, some C++11 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++14\-extensions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-c++14-extensions (C++ and Objective-C++ only)"
! Do not warn about C++14 constructs in code being compiled using
! an older C++ standard.  Even without this option, some C++14 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++17\-extensions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-c++17-extensions (C++ and Objective-C++ only)"
! Do not warn about C++17 constructs in code being compiled using
! an older C++ standard.  Even without this option, some C++17 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++20\-extensions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-c++20-extensions (C++ and Objective-C++ only)"
! Do not warn about C++20 constructs in code being compiled using
! an older C++ standard.  Even without this option, some C++20 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP "\fB\-Wno\-c++23\-extensions\fR (C++ and Objective\-C++ only)" 4
! .IX Item "-Wno-c++23-extensions (C++ and Objective-C++ only)"
! Do not warn about C++23 constructs in code being compiled using
! an older C++ standard.  Even without this option, some C++23 constructs
  will only be diagnosed if \fB\-Wpedantic\fR is used.
! .IP \fB\-Wcast\-qual\fR 4
  .IX Item "-Wcast-qual"
  Warn whenever a pointer is cast so as to remove a type qualifier from
  the target type.  For example, warn if a \f(CW\*(C`const char *\*(C'\fR is cast
*************** is unsafe, as in this example:
*** 8436,8469 ****
  \&          /* Now char** pointer points to read\-only memory.  */
  \&          **p = \*(Aqb\*(Aq;
  .Ve
! .IP "\fB\-Wcast\-align\fR" 4
  .IX Item "-Wcast-align"
  Warn whenever a pointer is cast such that the required alignment of the
  target is increased.  For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
  an \f(CW\*(C`int *\*(C'\fR on machines where integers can only be accessed at
! two\- or four-byte boundaries.
! .IP "\fB\-Wcast\-align=strict\fR" 4
  .IX Item "-Wcast-align=strict"
  Warn whenever a pointer is cast such that the required alignment of the
  target is increased.  For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
  an \f(CW\*(C`int *\*(C'\fR regardless of the target machine.
! .IP "\fB\-Wcast\-function\-type\fR" 4
  .IX Item "-Wcast-function-type"
  Warn when a function pointer is cast to an incompatible function pointer.
  In a cast involving function types with a variable argument list only
  the types of initial arguments that are provided are considered.
! Any parameter of pointer-type matches any other pointer-type.  Any benign
  differences in integral types are ignored, like \f(CW\*(C`int\*(C'\fR vs. \f(CW\*(C`long\*(C'\fR
! on \s-1ILP32\s0 targets.  Likewise type qualifiers are ignored.  The function
  type \f(CW\*(C`void (*) (void)\*(C'\fR is special and matches everything, which can
  be used to suppress this warning.
  In a cast involving pointer to member types this warning warns whenever
  the type cast is changing the pointer to member type.
  This warning is enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wwrite\-strings\fR" 4
  .IX Item "-Wwrite-strings"
  When compiling C, give string constants the type \f(CW\*(C`const
! char[\f(CIlength\f(CW]\*(C'\fR so that copying the address of one into a
  non\-\f(CW\*(C`const\*(C'\fR \f(CW\*(C`char *\*(C'\fR pointer produces a warning.  These
  warnings help you find at compile time code that can try to write
  into a string constant, but only if you have been very careful about
--- 8365,8398 ----
  \&          /* Now char** pointer points to read\-only memory.  */
  \&          **p = \*(Aqb\*(Aq;
  .Ve
! .IP \fB\-Wcast\-align\fR 4
  .IX Item "-Wcast-align"
  Warn whenever a pointer is cast such that the required alignment of the
  target is increased.  For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
  an \f(CW\*(C`int *\*(C'\fR on machines where integers can only be accessed at
! two\- or four\-byte boundaries.
! .IP \fB\-Wcast\-align=strict\fR 4
  .IX Item "-Wcast-align=strict"
  Warn whenever a pointer is cast such that the required alignment of the
  target is increased.  For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
  an \f(CW\*(C`int *\*(C'\fR regardless of the target machine.
! .IP \fB\-Wcast\-function\-type\fR 4
  .IX Item "-Wcast-function-type"
  Warn when a function pointer is cast to an incompatible function pointer.
  In a cast involving function types with a variable argument list only
  the types of initial arguments that are provided are considered.
! Any parameter of pointer\-type matches any other pointer\-type.  Any benign
  differences in integral types are ignored, like \f(CW\*(C`int\*(C'\fR vs. \f(CW\*(C`long\*(C'\fR
! on ILP32 targets.  Likewise type qualifiers are ignored.  The function
  type \f(CW\*(C`void (*) (void)\*(C'\fR is special and matches everything, which can
  be used to suppress this warning.
  In a cast involving pointer to member types this warning warns whenever
  the type cast is changing the pointer to member type.
  This warning is enabled by \fB\-Wextra\fR.
! .IP \fB\-Wwrite\-strings\fR 4
  .IX Item "-Wwrite-strings"
  When compiling C, give string constants the type \f(CW\*(C`const
! char[\fR\f(CIlength\fR\f(CW]\*(C'\fR so that copying the address of one into a
  non\-\f(CW\*(C`const\*(C'\fR \f(CW\*(C`char *\*(C'\fR pointer produces a warning.  These
  warnings help you find at compile time code that can try to write
  into a string constant, but only if you have been very careful about
*************** using \f(CW\*(C`const\*(C'\fR in declara
*** 8471,8486 ****
  just a nuisance. This is why we did not make \fB\-Wall\fR request
  these warnings.
  .Sp
! When compiling \*(C+, warn about the deprecated conversion from string
! literals to \f(CW\*(C`char *\*(C'\fR.  This warning is enabled by default for \*(C+
  programs.
! .IP "\fB\-Wclobbered\fR" 4
  .IX Item "-Wclobbered"
  Warn for variables that might be changed by \f(CW\*(C`longjmp\*(C'\fR or
  \&\f(CW\*(C`vfork\*(C'\fR.  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wno\-complain\-wrong\-lang\fR" 4
  .IX Item "-Wno-complain-wrong-lang"
! By default, language front ends complain when a command-line option is
  valid, but not applicable to that front end.
  This may be disabled with \fB\-Wno\-complain\-wrong\-lang\fR,
  which is mostly useful when invoking a single compiler driver for
--- 8400,8415 ----
  just a nuisance. This is why we did not make \fB\-Wall\fR request
  these warnings.
  .Sp
! When compiling C++, warn about the deprecated conversion from string
! literals to \f(CW\*(C`char *\*(C'\fR.  This warning is enabled by default for C++
  programs.
! .IP \fB\-Wclobbered\fR 4
  .IX Item "-Wclobbered"
  Warn for variables that might be changed by \f(CW\*(C`longjmp\*(C'\fR or
  \&\f(CW\*(C`vfork\*(C'\fR.  This warning is also enabled by \fB\-Wextra\fR.
! .IP \fB\-Wno\-complain\-wrong\-lang\fR 4
  .IX Item "-Wno-complain-wrong-lang"
! By default, language front ends complain when a command\-line option is
  valid, but not applicable to that front end.
  This may be disabled with \fB\-Wno\-complain\-wrong\-lang\fR,
  which is mostly useful when invoking a single compiler driver for
*************** multiple source files written in differe
*** 8490,8501 ****
  \&        $ g++ \-fno\-rtti a.cc b.f90
  .Ve
  .Sp
! The driver \fIg++\fR invokes the \*(C+ front end to compile \fIa.cc\fR
  and the Fortran front end to compile \fIb.f90\fR.
  The latter front end diagnoses
! \&\fBf951: Warning: command-line option '\-fno\-rtti' is valid for \*(C+/D/ObjC++ but not for Fortran\fR,
  which may be disabled with \fB\-Wno\-complain\-wrong\-lang\fR.
! .IP "\fB\-Wconversion\fR" 4
  .IX Item "-Wconversion"
  Warn for implicit conversions that may alter a value. This includes
  conversions between real and integer, like \f(CW\*(C`abs (x)\*(C'\fR when
--- 8419,8430 ----
  \&        $ g++ \-fno\-rtti a.cc b.f90
  .Ve
  .Sp
! The driver \fIg++\fR invokes the C++ front end to compile \fIa.cc\fR
  and the Fortran front end to compile \fIb.f90\fR.
  The latter front end diagnoses
! \&\fBf951: Warning: command\-line option \*(Aq\-fno\-rtti\*(Aq is valid for C++/D/ObjC++ but not for Fortran\fR,
  which may be disabled with \fB\-Wno\-complain\-wrong\-lang\fR.
! .IP \fB\-Wconversion\fR 4
  .IX Item "-Wconversion"
  Warn for implicit conversions that may alter a value. This includes
  conversions between real and integer, like \f(CW\*(C`abs (x)\*(C'\fR when
*************** changed by the conversion like in \f(CW\
*** 8507,8522 ****
  conversions between signed and unsigned integers can be disabled by
  using \fB\-Wno\-sign\-conversion\fR.
  .Sp
! For \*(C+, also warn for confusing overload resolution for user-defined
  conversions; and conversions that never use a type conversion
  operator: conversions to \f(CW\*(C`void\*(C'\fR, the same type, a base class or a
  reference to them. Warnings about conversions between signed and
! unsigned integers are disabled by default in \*(C+ unless
  \&\fB\-Wsign\-conversion\fR is explicitly enabled.
  .Sp
  Warnings about conversion from arithmetic on a small type back to that
  type are only given with \fB\-Warith\-conversion\fR.
! .IP "\fB\-Wdangling\-else\fR" 4
  .IX Item "-Wdangling-else"
  Warn about constructions where there may be confusion to which
  \&\f(CW\*(C`if\*(C'\fR statement an \f(CW\*(C`else\*(C'\fR branch belongs.  Here is an example of
--- 8436,8451 ----
  conversions between signed and unsigned integers can be disabled by
  using \fB\-Wno\-sign\-conversion\fR.
  .Sp
! For C++, also warn for confusing overload resolution for user\-defined
  conversions; and conversions that never use a type conversion
  operator: conversions to \f(CW\*(C`void\*(C'\fR, the same type, a base class or a
  reference to them. Warnings about conversions between signed and
! unsigned integers are disabled by default in C++ unless
  \&\fB\-Wsign\-conversion\fR is explicitly enabled.
  .Sp
  Warnings about conversion from arithmetic on a small type back to that
  type are only given with \fB\-Warith\-conversion\fR.
! .IP \fB\-Wdangling\-else\fR 4
  .IX Item "-Wdangling-else"
  Warn about constructions where there may be confusion to which
  \&\f(CW\*(C`if\*(C'\fR statement an \f(CW\*(C`else\*(C'\fR branch belongs.  Here is an example of
*************** such a case:
*** 8532,8542 ****
  \&        }
  .Ve
  .Sp
! In C/\*(C+, every \f(CW\*(C`else\*(C'\fR branch belongs to the innermost possible
  \&\f(CW\*(C`if\*(C'\fR statement, which in this example is \f(CW\*(C`if (b)\*(C'\fR.  This is
  often not what the programmer expected, as illustrated in the above
  example by indentation the programmer chose.  When there is the
! potential for this confusion, \s-1GCC\s0 issues a warning when this flag
  is specified.  To eliminate the warning, add explicit braces around
  the innermost \f(CW\*(C`if\*(C'\fR statement so there is no way the \f(CW\*(C`else\*(C'\fR
  can belong to the enclosing \f(CW\*(C`if\*(C'\fR.  The resulting code
--- 8461,8471 ----
  \&        }
  .Ve
  .Sp
! In C/C++, every \f(CW\*(C`else\*(C'\fR branch belongs to the innermost possible
  \&\f(CW\*(C`if\*(C'\fR statement, which in this example is \f(CW\*(C`if (b)\*(C'\fR.  This is
  often not what the programmer expected, as illustrated in the above
  example by indentation the programmer chose.  When there is the
! potential for this confusion, GCC issues a warning when this flag
  is specified.  To eliminate the warning, add explicit braces around
  the innermost \f(CW\*(C`if\*(C'\fR statement so there is no way the \f(CW\*(C`else\*(C'\fR
  can belong to the enclosing \f(CW\*(C`if\*(C'\fR.  The resulting code
*************** looks like this:
*** 8555,8574 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wparentheses\fR.
! .IP "\fB\-Wdangling\-pointer\fR" 4
  .IX Item "-Wdangling-pointer"
  .PD 0
! .IP "\fB\-Wdangling\-pointer=\fR\fIn\fR" 4
  .IX Item "-Wdangling-pointer=n"
  .PD
! Warn about uses of pointers (or \*(C+ references) to objects with automatic
  storage duration after their lifetime has ended.  This includes local
  variables declared in nested blocks, compound literals and other unnamed
  temporary objects.  In addition, warn about storing the address of such
  objects in escaped pointers.  The warning is enabled at all optimization
  levels but may yield different results with optimization than without.
  .RS 4
! .IP "\fB\-Wdangling\-pointer=1\fR" 4
  .IX Item "-Wdangling-pointer=1"
  At level 1 the warning diagnoses only unconditional uses of dangling pointers.
  For example
--- 8484,8503 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wparentheses\fR.
! .IP \fB\-Wdangling\-pointer\fR 4
  .IX Item "-Wdangling-pointer"
  .PD 0
! .IP \fB\-Wdangling\-pointer=\fR\fIn\fR 4
  .IX Item "-Wdangling-pointer=n"
  .PD
! Warn about uses of pointers (or C++ references) to objects with automatic
  storage duration after their lifetime has ended.  This includes local
  variables declared in nested blocks, compound literals and other unnamed
  temporary objects.  In addition, warn about storing the address of such
  objects in escaped pointers.  The warning is enabled at all optimization
  levels but may yield different results with optimization than without.
  .RS 4
! .IP \fB\-Wdangling\-pointer=1\fR 4
  .IX Item "-Wdangling-pointer=1"
  At level 1 the warning diagnoses only unconditional uses of dangling pointers.
  For example
*************** In the following function the store of t
*** 8593,8599 ****
  \&          *p = &x;
  \&        }
  .Ve
! .IP "\fB\-Wdangling\-pointer=2\fR" 4
  .IX Item "-Wdangling-pointer=2"
  At level 2, in addition to unconditional uses the warning also diagnoses
  conditional uses of dangling pointers.
--- 8522,8528 ----
  \&          *p = &x;
  \&        }
  .Ve
! .IP \fB\-Wdangling\-pointer=2\fR 4
  .IX Item "-Wdangling-pointer=2"
  At level 2, in addition to unconditional uses the warning also diagnoses
  conditional uses of dangling pointers.
*************** triggers at this level.
*** 8620,8649 ****
  .Sp
  \&\fB\-Wdangling\-pointer=2\fR is included in \fB\-Wall\fR.
  .RE
! .IP "\fB\-Wdate\-time\fR" 4
  .IX Item "-Wdate-time"
  Warn when macros \f(CW\*(C`_\|_TIME_\|_\*(C'\fR, \f(CW\*(C`_\|_DATE_\|_\*(C'\fR or \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR
! are encountered as they might prevent bit-wise-identical reproducible
  compilations.
! .IP "\fB\-Wempty\-body\fR" 4
  .IX Item "-Wempty-body"
  Warn if an empty body occurs in an \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR or \f(CW\*(C`do
  while\*(C'\fR statement.  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wno\-endif\-labels\fR" 4
  .IX Item "-Wno-endif-labels"
  Do not warn about stray tokens after \f(CW\*(C`#else\*(C'\fR and \f(CW\*(C`#endif\*(C'\fR.
! .IP "\fB\-Wenum\-compare\fR" 4
  .IX Item "-Wenum-compare"
  Warn about a comparison between values of different enumerated types.
! In \*(C+ enumerated type mismatches in conditional expressions are also
  diagnosed and the warning is enabled by default.  In C this warning is 
  enabled by \fB\-Wall\fR.
! .IP "\fB\-Wenum\-conversion\fR" 4
  .IX Item "-Wenum-conversion"
  Warn when a value of enumerated type is implicitly converted to a 
  different enumerated type.  This warning is enabled by \fB\-Wextra\fR
  in C.
! .IP "\fB\-Wenum\-int\-mismatch\fR (C and Objective-C only)" 4
  .IX Item "-Wenum-int-mismatch (C and Objective-C only)"
  Warn about mismatches between an enumerated type and an integer type in
  declarations.  For example:
--- 8549,8578 ----
  .Sp
  \&\fB\-Wdangling\-pointer=2\fR is included in \fB\-Wall\fR.
  .RE
! .IP \fB\-Wdate\-time\fR 4
  .IX Item "-Wdate-time"
  Warn when macros \f(CW\*(C`_\|_TIME_\|_\*(C'\fR, \f(CW\*(C`_\|_DATE_\|_\*(C'\fR or \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR
! are encountered as they might prevent bit\-wise\-identical reproducible
  compilations.
! .IP \fB\-Wempty\-body\fR 4
  .IX Item "-Wempty-body"
  Warn if an empty body occurs in an \f(CW\*(C`if\*(C'\fR, \f(CW\*(C`else\*(C'\fR or \f(CW\*(C`do
  while\*(C'\fR statement.  This warning is also enabled by \fB\-Wextra\fR.
! .IP \fB\-Wno\-endif\-labels\fR 4
  .IX Item "-Wno-endif-labels"
  Do not warn about stray tokens after \f(CW\*(C`#else\*(C'\fR and \f(CW\*(C`#endif\*(C'\fR.
! .IP \fB\-Wenum\-compare\fR 4
  .IX Item "-Wenum-compare"
  Warn about a comparison between values of different enumerated types.
! In C++ enumerated type mismatches in conditional expressions are also
  diagnosed and the warning is enabled by default.  In C this warning is 
  enabled by \fB\-Wall\fR.
! .IP \fB\-Wenum\-conversion\fR 4
  .IX Item "-Wenum-conversion"
  Warn when a value of enumerated type is implicitly converted to a 
  different enumerated type.  This warning is enabled by \fB\-Wextra\fR
  in C.
! .IP "\fB\-Wenum\-int\-mismatch\fR (C and Objective\-C only)" 4
  .IX Item "-Wenum-int-mismatch (C and Objective-C only)"
  Warn about mismatches between an enumerated type and an integer type in
  declarations.  For example:
*************** declarations.  For example:
*** 8656,8698 ****
  .Sp
  In C, an enumerated type is compatible with \f(CW\*(C`char\*(C'\fR, a signed
  integer type, or an unsigned integer type.  However, since the choice
! of the underlying type of an enumerated type is implementation-defined,
! such mismatches may cause portability issues.  In \*(C+, such mismatches
  are an error.  In C, this warning is enabled by \fB\-Wall\fR and
  \&\fB\-Wc++\-compat\fR.
! .IP "\fB\-Wjump\-misses\-init\fR (C, Objective-C only)" 4
  .IX Item "-Wjump-misses-init (C, Objective-C only)"
  Warn if a \f(CW\*(C`goto\*(C'\fR statement or a \f(CW\*(C`switch\*(C'\fR statement jumps
  forward across the initialization of a variable, or jumps backward to a
  label after the variable has been initialized.  This only warns about
  variables that are initialized when they are declared.  This warning is
! only supported for C and Objective-C; in \*(C+ this sort of branch is an
  error in any case.
  .Sp
  \&\fB\-Wjump\-misses\-init\fR is included in \fB\-Wc++\-compat\fR.  It
  can be disabled with the \fB\-Wno\-jump\-misses\-init\fR option.
! .IP "\fB\-Wsign\-compare\fR" 4
  .IX Item "-Wsign-compare"
  Warn when a comparison between signed and unsigned values could produce
  an incorrect result when the signed value is converted to unsigned.
! In \*(C+, this warning is also enabled by \fB\-Wall\fR.  In C, it is
  also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wsign\-conversion\fR" 4
  .IX Item "-Wsign-conversion"
  Warn for implicit conversions that may change the sign of an integer
  value, like assigning a signed integer expression to an unsigned
  integer variable. An explicit cast silences the warning. In C, this
  option is enabled also by \fB\-Wconversion\fR.
! .IP "\fB\-Wfloat\-conversion\fR" 4
  .IX Item "-Wfloat-conversion"
  Warn for implicit conversions that reduce the precision of a real value.
  This includes conversions from real to integer, and from higher precision
  real to lower precision real values.  This option is also enabled by
  \&\fB\-Wconversion\fR.
! .IP "\fB\-Wno\-scalar\-storage\-order\fR" 4
  .IX Item "-Wno-scalar-storage-order"
  Do not warn on suspicious constructs involving reverse scalar storage order.
! .IP "\fB\-Wsizeof\-array\-div\fR" 4
  .IX Item "-Wsizeof-array-div"
  Warn about divisions of two sizeof operators when the first one is applied
  to an array and the divisor does not equal the size of the array element.
--- 8585,8627 ----
  .Sp
  In C, an enumerated type is compatible with \f(CW\*(C`char\*(C'\fR, a signed
  integer type, or an unsigned integer type.  However, since the choice
! of the underlying type of an enumerated type is implementation\-defined,
! such mismatches may cause portability issues.  In C++, such mismatches
  are an error.  In C, this warning is enabled by \fB\-Wall\fR and
  \&\fB\-Wc++\-compat\fR.
! .IP "\fB\-Wjump\-misses\-init\fR (C, Objective\-C only)" 4
  .IX Item "-Wjump-misses-init (C, Objective-C only)"
  Warn if a \f(CW\*(C`goto\*(C'\fR statement or a \f(CW\*(C`switch\*(C'\fR statement jumps
  forward across the initialization of a variable, or jumps backward to a
  label after the variable has been initialized.  This only warns about
  variables that are initialized when they are declared.  This warning is
! only supported for C and Objective\-C; in C++ this sort of branch is an
  error in any case.
  .Sp
  \&\fB\-Wjump\-misses\-init\fR is included in \fB\-Wc++\-compat\fR.  It
  can be disabled with the \fB\-Wno\-jump\-misses\-init\fR option.
! .IP \fB\-Wsign\-compare\fR 4
  .IX Item "-Wsign-compare"
  Warn when a comparison between signed and unsigned values could produce
  an incorrect result when the signed value is converted to unsigned.
! In C++, this warning is also enabled by \fB\-Wall\fR.  In C, it is
  also enabled by \fB\-Wextra\fR.
! .IP \fB\-Wsign\-conversion\fR 4
  .IX Item "-Wsign-conversion"
  Warn for implicit conversions that may change the sign of an integer
  value, like assigning a signed integer expression to an unsigned
  integer variable. An explicit cast silences the warning. In C, this
  option is enabled also by \fB\-Wconversion\fR.
! .IP \fB\-Wfloat\-conversion\fR 4
  .IX Item "-Wfloat-conversion"
  Warn for implicit conversions that reduce the precision of a real value.
  This includes conversions from real to integer, and from higher precision
  real to lower precision real values.  This option is also enabled by
  \&\fB\-Wconversion\fR.
! .IP \fB\-Wno\-scalar\-storage\-order\fR 4
  .IX Item "-Wno-scalar-storage-order"
  Do not warn on suspicious constructs involving reverse scalar storage order.
! .IP \fB\-Wsizeof\-array\-div\fR 4
  .IX Item "-Wsizeof-array-div"
  Warn about divisions of two sizeof operators when the first one is applied
  to an array and the divisor does not equal the size of the array element.
*************** array, which is likely what the user int
*** 8708,8723 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wsizeof\-pointer\-div\fR" 4
  .IX Item "-Wsizeof-pointer-div"
  Warn for suspicious divisions of two sizeof expressions that divide
  the pointer size by the element size, which is the usual way to compute
! the array size but won't work out correctly with pointers.  This warning
  warns e.g. about \f(CW\*(C`sizeof (ptr) / sizeof (ptr[0])\*(C'\fR if \f(CW\*(C`ptr\*(C'\fR is
  not an array, but a pointer.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wsizeof\-pointer\-memaccess\fR" 4
  .IX Item "-Wsizeof-pointer-memaccess"
! Warn for suspicious length parameters to certain string and memory built-in
  functions if the argument uses \f(CW\*(C`sizeof\*(C'\fR.  This warning triggers for
  example for \f(CW\*(C`memset (ptr, 0, sizeof (ptr));\*(C'\fR if \f(CW\*(C`ptr\*(C'\fR is not
  an array, but a pointer, and suggests a possible fix, or about
--- 8637,8652 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wsizeof\-pointer\-div\fR 4
  .IX Item "-Wsizeof-pointer-div"
  Warn for suspicious divisions of two sizeof expressions that divide
  the pointer size by the element size, which is the usual way to compute
! the array size but won\*(Aqt work out correctly with pointers.  This warning
  warns e.g. about \f(CW\*(C`sizeof (ptr) / sizeof (ptr[0])\*(C'\fR if \f(CW\*(C`ptr\*(C'\fR is
  not an array, but a pointer.  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wsizeof\-pointer\-memaccess\fR 4
  .IX Item "-Wsizeof-pointer-memaccess"
! Warn for suspicious length parameters to certain string and memory built\-in
  functions if the argument uses \f(CW\*(C`sizeof\*(C'\fR.  This warning triggers for
  example for \f(CW\*(C`memset (ptr, 0, sizeof (ptr));\*(C'\fR if \f(CW\*(C`ptr\*(C'\fR is not
  an array, but a pointer, and suggests a possible fix, or about
*************** is almost certainly a mistake and so the
*** 8739,8759 ****
  .Ve
  .Sp
  The \fB\-Wsizeof\-pointer\-memaccess\fR option is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-sizeof\-array\-argument\fR" 4
  .IX Item "-Wno-sizeof-array-argument"
  Do not warn when the \f(CW\*(C`sizeof\*(C'\fR operator is applied to a parameter that is
  declared as an array in a function definition.  This warning is enabled by
! default for C and \*(C+ programs.
! .IP "\fB\-Wmemset\-elt\-size\fR" 4
  .IX Item "-Wmemset-elt-size"
! Warn for suspicious calls to the \f(CW\*(C`memset\*(C'\fR built-in function, if the
  first argument references an array, and the third argument is a number
  equal to the number of elements, but not equal to the size of the array
  in memory.  This indicates that the user has omitted a multiplication by
  the element size.  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wmemset\-transposed\-args\fR" 4
  .IX Item "-Wmemset-transposed-args"
! Warn for suspicious calls to the \f(CW\*(C`memset\*(C'\fR built-in function where
  the second argument is not zero and the third argument is zero.  For
  example, the call \f(CW\*(C`memset (buf, sizeof buf, 0)\*(C'\fR is diagnosed because
  \&\f(CW\*(C`memset (buf, 0, sizeof buf)\*(C'\fR was meant instead.  The diagnostic
--- 8668,8688 ----
  .Ve
  .Sp
  The \fB\-Wsizeof\-pointer\-memaccess\fR option is enabled by \fB\-Wall\fR.
! .IP \fB\-Wno\-sizeof\-array\-argument\fR 4
  .IX Item "-Wno-sizeof-array-argument"
  Do not warn when the \f(CW\*(C`sizeof\*(C'\fR operator is applied to a parameter that is
  declared as an array in a function definition.  This warning is enabled by
! default for C and C++ programs.
! .IP \fB\-Wmemset\-elt\-size\fR 4
  .IX Item "-Wmemset-elt-size"
! Warn for suspicious calls to the \f(CW\*(C`memset\*(C'\fR built\-in function, if the
  first argument references an array, and the third argument is a number
  equal to the number of elements, but not equal to the size of the array
  in memory.  This indicates that the user has omitted a multiplication by
  the element size.  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wmemset\-transposed\-args\fR 4
  .IX Item "-Wmemset-transposed-args"
! Warn for suspicious calls to the \f(CW\*(C`memset\*(C'\fR built\-in function where
  the second argument is not zero and the third argument is zero.  For
  example, the call \f(CW\*(C`memset (buf, sizeof buf, 0)\*(C'\fR is diagnosed because
  \&\f(CW\*(C`memset (buf, 0, sizeof buf)\*(C'\fR was meant instead.  The diagnostic
*************** it is an expression that is folded to ze
*** 8762,8768 ****
  type, it is far less likely that the arguments have been mistakenly
  transposed and no warning is emitted.  This warning is enabled
  by \fB\-Wall\fR.
! .IP "\fB\-Waddress\fR" 4
  .IX Item "-Waddress"
  Warn about suspicious uses of address expressions. These include comparing
  the address of a function or a declared object to the null pointer constant
--- 8691,8697 ----
  type, it is far less likely that the arguments have been mistakenly
  transposed and no warning is emitted.  This warning is enabled
  by \fB\-Wall\fR.
! .IP \fB\-Waddress\fR 4
  .IX Item "-Waddress"
  Warn about suspicious uses of address expressions. These include comparing
  the address of a function or a declared object to the null pointer constant
*************** and are not portable, and suggest the in
*** 8809,8831 ****
  The warning is suppressed if the suspicious expression is the result
  of macro expansion.
  \&\fB\-Waddress\fR warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-address\-of\-packed\-member\fR" 4
  .IX Item "-Wno-address-of-packed-member"
  Do not warn when the address of packed member of struct or union is taken,
  which usually results in an unaligned pointer value.  This is
  enabled by default.
! .IP "\fB\-Wlogical\-op\fR" 4
  .IX Item "-Wlogical-op"
  Warn about suspicious uses of logical operators in expressions.
  This includes using logical operators in contexts where a
! bit-wise operator is likely to be expected.  Also warns when
  the operands of a logical operator are the same:
  .Sp
  .Vb 2
  \&        extern int a;
  \&        if (a < 0 && a < 0) { ... }
  .Ve
! .IP "\fB\-Wlogical\-not\-parentheses\fR" 4
  .IX Item "-Wlogical-not-parentheses"
  Warn about logical not used on the left hand side operand of a comparison.
  This option does not warn if the right operand is considered to be a boolean
--- 8738,8760 ----
  The warning is suppressed if the suspicious expression is the result
  of macro expansion.
  \&\fB\-Waddress\fR warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wno\-address\-of\-packed\-member\fR 4
  .IX Item "-Wno-address-of-packed-member"
  Do not warn when the address of packed member of struct or union is taken,
  which usually results in an unaligned pointer value.  This is
  enabled by default.
! .IP \fB\-Wlogical\-op\fR 4
  .IX Item "-Wlogical-op"
  Warn about suspicious uses of logical operators in expressions.
  This includes using logical operators in contexts where a
! bit\-wise operator is likely to be expected.  Also warns when
  the operands of a logical operator are the same:
  .Sp
  .Vb 2
  \&        extern int a;
  \&        if (a < 0 && a < 0) { ... }
  .Ve
! .IP \fB\-Wlogical\-not\-parentheses\fR 4
  .IX Item "-Wlogical-not-parentheses"
  Warn about logical not used on the left hand side operand of a comparison.
  This option does not warn if the right operand is considered to be a boolean
*************** expression.  Its purpose is to detect su
*** 8837,8843 ****
  \&        if (!a > 1) { ... }
  .Ve
  .Sp
! It is possible to suppress the warning by wrapping the \s-1LHS\s0 into
  parentheses:
  .Sp
  .Vb 1
--- 8766,8772 ----
  \&        if (!a > 1) { ... }
  .Ve
  .Sp
! It is possible to suppress the warning by wrapping the LHS into
  parentheses:
  .Sp
  .Vb 1
*************** parentheses:
*** 8845,8860 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Waggregate\-return\fR" 4
  .IX Item "-Waggregate-return"
  Warn if any functions that return structures or unions are defined or
  called.  (In languages where you can return an array, this also elicits
  a warning.)
! .IP "\fB\-Wno\-aggressive\-loop\-optimizations\fR" 4
  .IX Item "-Wno-aggressive-loop-optimizations"
  Warn if in a loop with constant number of iterations the compiler detects
  undefined behavior in some statement during one or more of the iterations.
! .IP "\fB\-Wno\-attributes\fR" 4
  .IX Item "-Wno-attributes"
  Do not warn if an unexpected \f(CW\*(C`_\|_attribute_\|_\*(C'\fR is used, such as
  unrecognized attributes, function attributes applied to variables,
--- 8774,8789 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Waggregate\-return\fR 4
  .IX Item "-Waggregate-return"
  Warn if any functions that return structures or unions are defined or
  called.  (In languages where you can return an array, this also elicits
  a warning.)
! .IP \fB\-Wno\-aggressive\-loop\-optimizations\fR 4
  .IX Item "-Wno-aggressive-loop-optimizations"
  Warn if in a loop with constant number of iterations the compiler detects
  undefined behavior in some statement during one or more of the iterations.
! .IP \fB\-Wno\-attributes\fR 4
  .IX Item "-Wno-attributes"
  Do not warn if an unexpected \f(CW\*(C`_\|_attribute_\|_\*(C'\fR is used, such as
  unrecognized attributes, function attributes applied to variables,
*************** etc.  This does not stop errors for inco
*** 8862,8868 ****
  attributes.
  .Sp
  Additionally, using \fB\-Wno\-attributes=\fR, it is possible to suppress
! warnings about unknown scoped attributes (in \*(C+11 and C2X).  For example,
  \&\fB\-Wno\-attributes=vendor::attr\fR disables warning about the following
  declaration:
  .Sp
--- 8791,8797 ----
  attributes.
  .Sp
  Additionally, using \fB\-Wno\-attributes=\fR, it is possible to suppress
! warnings about unknown scoped attributes (in C++11 and C2X).  For example,
  \&\fB\-Wno\-attributes=vendor::attr\fR disables warning about the following
  declaration:
  .Sp
*************** of these declarations:
*** 8880,8895 ****
  .Ve
  .Sp
  Note that \fB\-Wno\-attributes=\fR does not imply \fB\-Wno\-attributes\fR.
! .IP "\fB\-Wno\-builtin\-declaration\-mismatch\fR" 4
  .IX Item "-Wno-builtin-declaration-mismatch"
! Warn if a built-in function is declared with an incompatible signature
! or as a non-function, or when a built-in function declared with a type
  that does not include a prototype is called with arguments whose promoted
  types do not match those expected by the function.  When \fB\-Wextra\fR
! is specified, also warn when a built-in function that takes arguments is
  declared without a prototype.  The \fB\-Wbuiltin\-declaration\-mismatch\fR
  warning is enabled by default.  To avoid the warning include the appropriate
! header to bring the prototypes of built-in functions into scope.
  .Sp
  For example, the call to \f(CW\*(C`memset\*(C'\fR below is diagnosed by the warning
  because the function expects a value of type \f(CW\*(C`size_t\*(C'\fR as its argument
--- 8809,8824 ----
  .Ve
  .Sp
  Note that \fB\-Wno\-attributes=\fR does not imply \fB\-Wno\-attributes\fR.
! .IP \fB\-Wno\-builtin\-declaration\-mismatch\fR 4
  .IX Item "-Wno-builtin-declaration-mismatch"
! Warn if a built\-in function is declared with an incompatible signature
! or as a non\-function, or when a built\-in function declared with a type
  that does not include a prototype is called with arguments whose promoted
  types do not match those expected by the function.  When \fB\-Wextra\fR
! is specified, also warn when a built\-in function that takes arguments is
  declared without a prototype.  The \fB\-Wbuiltin\-declaration\-mismatch\fR
  warning is enabled by default.  To avoid the warning include the appropriate
! header to bring the prototypes of built\-in functions into scope.
  .Sp
  For example, the call to \f(CW\*(C`memset\*(C'\fR below is diagnosed by the warning
  because the function expects a value of type \f(CW\*(C`size_t\*(C'\fR as its argument
*************** the declaration of the function is diagn
*** 8903,8933 ****
  \&          memset (d, \*(Aq\e0\*(Aq, 32);
  \&        }
  .Ve
! .IP "\fB\-Wno\-builtin\-macro\-redefined\fR" 4
  .IX Item "-Wno-builtin-macro-redefined"
! Do not warn if certain built-in macros are redefined.  This suppresses
  warnings for redefinition of \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR, \f(CW\*(C`_\|_TIME_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_DATE_\|_\*(C'\fR, \f(CW\*(C`_\|_FILE_\|_\*(C'\fR, and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR.
! .IP "\fB\-Wstrict\-prototypes\fR (C and Objective-C only)" 4
  .IX Item "-Wstrict-prototypes (C and Objective-C only)"
  Warn if a function is declared or defined without specifying the
! argument types.  (An old-style function definition is permitted without
  a warning if preceded by a declaration that specifies the argument
  types.)
! .IP "\fB\-Wold\-style\-declaration\fR (C and Objective-C only)" 4
  .IX Item "-Wold-style-declaration (C and Objective-C only)"
  Warn for obsolescent usages, according to the C Standard, in a
! declaration. For example, warn if storage-class specifiers like
  \&\f(CW\*(C`static\*(C'\fR are not the first things in a declaration.  This warning
  is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wold\-style\-definition\fR (C and Objective-C only)" 4
  .IX Item "-Wold-style-definition (C and Objective-C only)"
! Warn if an old-style function definition is used.  A warning is given
  even if there is a previous prototype.  A definition using \fB()\fR
! is not considered an old-style definition in C2X mode, because it is
  equivalent to \fB(void)\fR in that case, but is considered an
! old-style definition for older standards.
! .IP "\fB\-Wmissing\-parameter\-type\fR (C and Objective-C only)" 4
  .IX Item "-Wmissing-parameter-type (C and Objective-C only)"
  A function parameter is declared without a type specifier in K&R\-style
  functions:
--- 8832,8862 ----
  \&          memset (d, \*(Aq\e0\*(Aq, 32);
  \&        }
  .Ve
! .IP \fB\-Wno\-builtin\-macro\-redefined\fR 4
  .IX Item "-Wno-builtin-macro-redefined"
! Do not warn if certain built\-in macros are redefined.  This suppresses
  warnings for redefinition of \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR, \f(CW\*(C`_\|_TIME_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_DATE_\|_\*(C'\fR, \f(CW\*(C`_\|_FILE_\|_\*(C'\fR, and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR.
! .IP "\fB\-Wstrict\-prototypes\fR (C and Objective\-C only)" 4
  .IX Item "-Wstrict-prototypes (C and Objective-C only)"
  Warn if a function is declared or defined without specifying the
! argument types.  (An old\-style function definition is permitted without
  a warning if preceded by a declaration that specifies the argument
  types.)
! .IP "\fB\-Wold\-style\-declaration\fR (C and Objective\-C only)" 4
  .IX Item "-Wold-style-declaration (C and Objective-C only)"
  Warn for obsolescent usages, according to the C Standard, in a
! declaration. For example, warn if storage\-class specifiers like
  \&\f(CW\*(C`static\*(C'\fR are not the first things in a declaration.  This warning
  is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wold\-style\-definition\fR (C and Objective\-C only)" 4
  .IX Item "-Wold-style-definition (C and Objective-C only)"
! Warn if an old\-style function definition is used.  A warning is given
  even if there is a previous prototype.  A definition using \fB()\fR
! is not considered an old\-style definition in C2X mode, because it is
  equivalent to \fB(void)\fR in that case, but is considered an
! old\-style definition for older standards.
! .IP "\fB\-Wmissing\-parameter\-type\fR (C and Objective\-C only)" 4
  .IX Item "-Wmissing-parameter-type (C and Objective-C only)"
  A function parameter is declared without a type specifier in K&R\-style
  functions:
*************** functions:
*** 8937,8964 ****
  .Ve
  .Sp
  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wmissing\-prototypes\fR (C and Objective-C only)" 4
  .IX Item "-Wmissing-prototypes (C and Objective-C only)"
  Warn if a global function is defined without a previous prototype
  declaration.  This warning is issued even if the definition itself
  provides a prototype.  Use this option to detect global functions
  that do not have a matching prototype declaration in a header file.
! This option is not valid for \*(C+ because all function declarations
! provide prototypes and a non-matching declaration declares an
  overload rather than conflict with an earlier declaration.
! Use \fB\-Wmissing\-declarations\fR to detect missing declarations in \*(C+.
! .IP "\fB\-Wmissing\-declarations\fR" 4
  .IX Item "-Wmissing-declarations"
  Warn if a global function is defined without a previous declaration.
  Do so even if the definition itself provides a prototype.
  Use this option to detect global functions that are not declared in
  header files.  In C, no warnings are issued for functions with previous
! non-prototype declarations; use \fB\-Wmissing\-prototypes\fR to detect
! missing prototypes.  In \*(C+, no warnings are issued for function templates,
  or for inline functions, or for functions in anonymous namespaces.
! .IP "\fB\-Wmissing\-field\-initializers\fR" 4
  .IX Item "-Wmissing-field-initializers"
! Warn if a structure's initializer has some fields missing.  For
  example, the following code causes such a warning, because
  \&\f(CW\*(C`x.h\*(C'\fR is implicitly zero:
  .Sp
--- 8866,8893 ----
  .Ve
  .Sp
  This warning is also enabled by \fB\-Wextra\fR.
! .IP "\fB\-Wmissing\-prototypes\fR (C and Objective\-C only)" 4
  .IX Item "-Wmissing-prototypes (C and Objective-C only)"
  Warn if a global function is defined without a previous prototype
  declaration.  This warning is issued even if the definition itself
  provides a prototype.  Use this option to detect global functions
  that do not have a matching prototype declaration in a header file.
! This option is not valid for C++ because all function declarations
! provide prototypes and a non\-matching declaration declares an
  overload rather than conflict with an earlier declaration.
! Use \fB\-Wmissing\-declarations\fR to detect missing declarations in C++.
! .IP \fB\-Wmissing\-declarations\fR 4
  .IX Item "-Wmissing-declarations"
  Warn if a global function is defined without a previous declaration.
  Do so even if the definition itself provides a prototype.
  Use this option to detect global functions that are not declared in
  header files.  In C, no warnings are issued for functions with previous
! non\-prototype declarations; use \fB\-Wmissing\-prototypes\fR to detect
! missing prototypes.  In C++, no warnings are issued for function templates,
  or for inline functions, or for functions in anonymous namespaces.
! .IP \fB\-Wmissing\-field\-initializers\fR 4
  .IX Item "-Wmissing-field-initializers"
! Warn if a structure\*(Aqs initializer has some fields missing.  For
  example, the following code causes such a warning, because
  \&\f(CW\*(C`x.h\*(C'\fR is implicitly zero:
  .Sp
*************** In C this option does not warn about the
*** 8983,8989 ****
  \&        struct s x = { 0 };
  .Ve
  .Sp
! Likewise, in \*(C+ this option does not warn about the empty { }
  initializer, for example:
  .Sp
  .Vb 2
--- 8912,8918 ----
  \&        struct s x = { 0 };
  .Ve
  .Sp
! Likewise, in C++ this option does not warn about the empty { }
  initializer, for example:
  .Sp
  .Vb 2
*************** initializer, for example:
*** 8993,9001 ****
  .Sp
  This warning is included in \fB\-Wextra\fR.  To get other \fB\-Wextra\fR
  warnings without this one, use \fB\-Wextra \-Wno\-missing\-field\-initializers\fR.
! .IP "\fB\-Wno\-missing\-requires\fR" 4
  .IX Item "-Wno-missing-requires"
! By default, the compiler warns about a concept-id appearing as a \*(C+20 simple-requirement:
  .Sp
  .Vb 1
  \&        bool satisfied = requires { C };
--- 8922,8930 ----
  .Sp
  This warning is included in \fB\-Wextra\fR.  To get other \fB\-Wextra\fR
  warnings without this one, use \fB\-Wextra \-Wno\-missing\-field\-initializers\fR.
! .IP \fB\-Wno\-missing\-requires\fR 4
  .IX Item "-Wno-missing-requires"
! By default, the compiler warns about a concept\-id appearing as a C++20 simple\-requirement:
  .Sp
  .Vb 1
  \&        bool satisfied = requires { C };
*************** so \fBsatisfied\fR is only true if conce
*** 9012,9018 ****
  type \fBT\fR.
  .Sp
  This warning can be disabled with \fB\-Wno\-missing\-requires\fR.
! .IP "\fB\-Wno\-missing\-template\-keyword\fR" 4
  .IX Item "-Wno-missing-template-keyword"
  The member access tokens ., \-> and :: must be followed by the \f(CW\*(C`template\*(C'\fR
  keyword if the parent object is dependent and the member being named is a
--- 8941,8947 ----
  type \fBT\fR.
  .Sp
  This warning can be disabled with \fB\-Wno\-missing\-requires\fR.
! .IP \fB\-Wno\-missing\-template\-keyword\fR 4
  .IX Item "-Wno-missing-template-keyword"
  The member access tokens ., \-> and :: must be followed by the \f(CW\*(C`template\*(C'\fR
  keyword if the parent object is dependent and the member being named is a
*************** template, even where m and N are integer
*** 9042,9073 ****
  .Ve
  .Sp
  This warning can be disabled with \fB\-Wno\-missing\-template\-keyword\fR.
! .IP "\fB\-Wno\-multichar\fR" 4
  .IX Item "-Wno-multichar"
! Do not warn if a multicharacter constant (\fB'\s-1FOOF\s0'\fR) is used.
! Usually they indicate a typo in the user's code, as they have
! implementation-defined values, and should not be used in portable code.
! .IP "\fB\-Wnormalized=\fR[\fBnone\fR|\fBid\fR|\fBnfc\fR|\fBnfkc\fR]" 4
  .IX Item "-Wnormalized=[none|id|nfc|nfkc]"
! In \s-1ISO C\s0 and \s-1ISO \*(C+,\s0 two identifiers are different if they are
  different sequences of characters.  However, sometimes when characters
! outside the basic \s-1ASCII\s0 character set are used, you can have two
  different character sequences that look the same.  To avoid confusion,
! the \s-1ISO 10646\s0 standard sets out some \fInormalization rules\fR which
  when applied ensure that two sequences that look the same are turned into
! the same sequence.  \s-1GCC\s0 can warn you if you are using identifiers that
  have not been normalized; this option controls that warning.
  .Sp
! There are four levels of warning supported by \s-1GCC.\s0  The default is
  \&\fB\-Wnormalized=nfc\fR, which warns about any identifier that is
! not in the \s-1ISO 10646 \*(L"C\*(R"\s0 normalized form, \fI\s-1NFC\s0\fR.  \s-1NFC\s0 is the
  recommended form for most uses.  It is equivalent to
  \&\fB\-Wnormalized\fR.
  .Sp
  Unfortunately, there are some characters allowed in identifiers by
! \&\s-1ISO C\s0 and \s-1ISO \*(C+\s0 that, when turned into \s-1NFC,\s0 are not allowed in 
! identifiers.  That is, there's no way to use these symbols in portable
! \&\s-1ISO C\s0 or \*(C+ and have all your identifiers in \s-1NFC.\s0
  \&\fB\-Wnormalized=id\fR suppresses the warning for these characters.
  It is hoped that future versions of the standards involved will correct
  this, which is why this option is not the default.
--- 8971,9002 ----
  .Ve
  .Sp
  This warning can be disabled with \fB\-Wno\-missing\-template\-keyword\fR.
! .IP \fB\-Wno\-multichar\fR 4
  .IX Item "-Wno-multichar"
! Do not warn if a multicharacter constant (\fB\*(AqFOOF\*(Aq\fR) is used.
! Usually they indicate a typo in the user\*(Aqs code, as they have
! implementation\-defined values, and should not be used in portable code.
! .IP \fB\-Wnormalized=\fR[\fBnone\fR|\fBid\fR|\fBnfc\fR|\fBnfkc\fR] 4
  .IX Item "-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 \fInormalization rules\fR which
  when applied ensure that two sequences that look the same are turned into
! the same sequence.  GCC can warn you if you are using identifiers that
  have not been normalized; this option controls that warning.
  .Sp
! There are four levels of warning supported by GCC.  The default is
  \&\fB\-Wnormalized=nfc\fR, which warns about any identifier that is
! not in the ISO 10646 "C" normalized form, \fINFC\fR.  NFC is the
  recommended form for most uses.  It is equivalent to
  \&\fB\-Wnormalized\fR.
  .Sp
  Unfortunately, there are some characters allowed in identifiers by
! ISO C and ISO C++ that, when turned into NFC, are not allowed in 
! identifiers.  That is, there\*(Aqs no way to use these symbols in portable
! ISO C or C++ and have all your identifiers in NFC.
  \&\fB\-Wnormalized=id\fR suppresses the warning for these characters.
  It is hoped that future versions of the standards involved will correct
  this, which is why this option is not the default.
*************** this, which is why this option is not th
*** 9075,9126 ****
  You can switch the warning off for all characters by writing
  \&\fB\-Wnormalized=none\fR or \fB\-Wno\-normalized\fR.  You should
  only do this if you are using some other normalization scheme (like
! \&\*(L"D\*(R"), because otherwise you can easily create bugs that are
  literally impossible to see.
  .Sp
! Some characters in \s-1ISO 10646\s0 have distinct meanings but look identical
  in some fonts or display methodologies, especially once formatting has
! been applied.  For instance \f(CW\*(C`\eu207F\*(C'\fR, \*(L"\s-1SUPERSCRIPT LATIN SMALL
! LETTER N\*(R",\s0 displays just like a regular \f(CW\*(C`n\*(C'\fR that has been
! placed in a superscript.  \s-1ISO 10646\s0 defines the \fI\s-1NFKC\s0\fR
  normalization scheme to convert all these into a standard form as
! well, and \s-1GCC\s0 warns if your code is not in \s-1NFKC\s0 if you use
  \&\fB\-Wnormalized=nfkc\fR.  This warning is comparable to warning
  about every identifier that contains the letter O because it might be
  confused with the digit 0, and so is not the default, but may be
  useful as a local coding convention if the programming environment 
  cannot be fixed to display these characters distinctly.
! .IP "\fB\-Wno\-attribute\-warning\fR" 4
  .IX Item "-Wno-attribute-warning"
  Do not warn about usage of functions
  declared with \f(CW\*(C`warning\*(C'\fR attribute.  By default, this warning is
  enabled.  \fB\-Wno\-attribute\-warning\fR can be used to disable the
  warning or \fB\-Wno\-error=attribute\-warning\fR can be used to
  disable the error when compiled with \fB\-Werror\fR flag.
! .IP "\fB\-Wno\-deprecated\fR" 4
  .IX Item "-Wno-deprecated"
  Do not warn about usage of deprecated features.
! .IP "\fB\-Wno\-deprecated\-declarations\fR" 4
  .IX Item "-Wno-deprecated-declarations"
  Do not warn about uses of functions,
  variables, and types marked as deprecated by using the \f(CW\*(C`deprecated\*(C'\fR
  attribute.
! .IP "\fB\-Wno\-overflow\fR" 4
  .IX Item "-Wno-overflow"
! Do not warn about compile-time overflow in constant expressions.
! .IP "\fB\-Wno\-odr\fR" 4
  .IX Item "-Wno-odr"
! Warn about One Definition Rule violations during link-time optimization.
  Enabled by default.
! .IP "\fB\-Wopenacc\-parallelism\fR" 4
  .IX Item "-Wopenacc-parallelism"
  Warn about potentially suboptimal choices related to OpenACC parallelism.
! .IP "\fB\-Wopenmp\-simd\fR" 4
  .IX Item "-Wopenmp-simd"
  Warn if the vectorizer cost model overrides the OpenMP
  simd directive set by user.  The \fB\-fsimd\-cost\-model=unlimited\fR
  option can be used to relax the cost model.
! .IP "\fB\-Woverride\-init\fR (C and Objective-C only)" 4
  .IX Item "-Woverride-init (C and Objective-C only)"
  Warn if an initialized field without side effects is overridden when
  using designated initializers.
--- 9004,9055 ----
  You can switch the warning off for all characters by writing
  \&\fB\-Wnormalized=none\fR or \fB\-Wno\-normalized\fR.  You should
  only do this if you are using some other normalization scheme (like
! "D"), because otherwise you can easily create bugs that are
  literally impossible to see.
  .Sp
! 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 \f(CW\*(C`\eu207F\*(C'\fR, "SUPERSCRIPT LATIN SMALL
! LETTER N", displays just like a regular \f(CW\*(C`n\*(C'\fR that has been
! placed in a superscript.  ISO 10646 defines the \fINFKC\fR
  normalization scheme to convert all these into a standard form as
! well, and GCC warns if your code is not in NFKC if you use
  \&\fB\-Wnormalized=nfkc\fR.  This warning is comparable to warning
  about every identifier that contains the letter O because it might be
  confused with the digit 0, and so is not the default, but may be
  useful as a local coding convention if the programming environment 
  cannot be fixed to display these characters distinctly.
! .IP \fB\-Wno\-attribute\-warning\fR 4
  .IX Item "-Wno-attribute-warning"
  Do not warn about usage of functions
  declared with \f(CW\*(C`warning\*(C'\fR attribute.  By default, this warning is
  enabled.  \fB\-Wno\-attribute\-warning\fR can be used to disable the
  warning or \fB\-Wno\-error=attribute\-warning\fR can be used to
  disable the error when compiled with \fB\-Werror\fR flag.
! .IP \fB\-Wno\-deprecated\fR 4
  .IX Item "-Wno-deprecated"
  Do not warn about usage of deprecated features.
! .IP \fB\-Wno\-deprecated\-declarations\fR 4
  .IX Item "-Wno-deprecated-declarations"
  Do not warn about uses of functions,
  variables, and types marked as deprecated by using the \f(CW\*(C`deprecated\*(C'\fR
  attribute.
! .IP \fB\-Wno\-overflow\fR 4
  .IX Item "-Wno-overflow"
! Do not warn about compile\-time overflow in constant expressions.
! .IP \fB\-Wno\-odr\fR 4
  .IX Item "-Wno-odr"
! Warn about One Definition Rule violations during link\-time optimization.
  Enabled by default.
! .IP \fB\-Wopenacc\-parallelism\fR 4
  .IX Item "-Wopenacc-parallelism"
  Warn about potentially suboptimal choices related to OpenACC parallelism.
! .IP \fB\-Wopenmp\-simd\fR 4
  .IX Item "-Wopenmp-simd"
  Warn if the vectorizer cost model overrides the OpenMP
  simd directive set by user.  The \fB\-fsimd\-cost\-model=unlimited\fR
  option can be used to relax the cost model.
! .IP "\fB\-Woverride\-init\fR (C and Objective\-C only)" 4
  .IX Item "-Woverride-init (C and Objective-C only)"
  Warn if an initialized field without side effects is overridden when
  using designated initializers.
*************** using designated initializers.
*** 9128,9142 ****
  This warning is included in \fB\-Wextra\fR.  To get other
  \&\fB\-Wextra\fR warnings without this one, use \fB\-Wextra
  \&\-Wno\-override\-init\fR.
! .IP "\fB\-Wno\-override\-init\-side\-effects\fR (C and Objective-C only)" 4
  .IX Item "-Wno-override-init-side-effects (C and Objective-C only)"
  Do not warn if an initialized field with side effects is overridden when
  using designated initializers.  This warning is enabled by default.
! .IP "\fB\-Wpacked\fR" 4
  .IX Item "-Wpacked"
  Warn if a structure is given the packed attribute, but the packed
  attribute has no effect on the layout or size of the structure.
! Such structures may be mis-aligned for little benefit.  For
  instance, in this code, the variable \f(CW\*(C`f.x\*(C'\fR in \f(CW\*(C`struct bar\*(C'\fR
  is misaligned even though \f(CW\*(C`struct bar\*(C'\fR does not itself
  have the packed attribute:
--- 9057,9071 ----
  This warning is included in \fB\-Wextra\fR.  To get other
  \&\fB\-Wextra\fR warnings without this one, use \fB\-Wextra
  \&\-Wno\-override\-init\fR.
! .IP "\fB\-Wno\-override\-init\-side\-effects\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-override-init-side-effects (C and Objective-C only)"
  Do not warn if an initialized field with side effects is overridden when
  using designated initializers.  This warning is enabled by default.
! .IP \fB\-Wpacked\fR 4
  .IX Item "-Wpacked"
  Warn if a structure is given the packed attribute, but the packed
  attribute has no effect on the layout or size of the structure.
! Such structures may be mis\-aligned for little benefit.  For
  instance, in this code, the variable \f(CW\*(C`f.x\*(C'\fR in \f(CW\*(C`struct bar\*(C'\fR
  is misaligned even though \f(CW\*(C`struct bar\*(C'\fR does not itself
  have the packed attribute:
*************** have the packed attribute:
*** 9151,9162 ****
  \&          struct foo f;
  \&        };
  .Ve
! .IP "\fB\-Wnopacked\-bitfield\-compat\fR" 4
  .IX Item "-Wnopacked-bitfield-compat"
! The 4.1, 4.2 and 4.3 series of \s-1GCC\s0 ignore the \f(CW\*(C`packed\*(C'\fR attribute
! on bit-fields of type \f(CW\*(C`char\*(C'\fR.  This was fixed in \s-1GCC 4.4\s0 but
! the change can lead to differences in the structure layout.  \s-1GCC\s0
! informs you when the offset of such a field has changed in \s-1GCC 4.4.\s0
  For example there is no longer a 4\-bit padding between field \f(CW\*(C`a\*(C'\fR
  and \f(CW\*(C`b\*(C'\fR in this structure:
  .Sp
--- 9080,9091 ----
  \&          struct foo f;
  \&        };
  .Ve
! .IP \fB\-Wnopacked\-bitfield\-compat\fR 4
  .IX Item "-Wnopacked-bitfield-compat"
! The 4.1, 4.2 and 4.3 series of GCC ignore the \f(CW\*(C`packed\*(C'\fR attribute
! on bit\-fields of type \f(CW\*(C`char\*(C'\fR.  This was 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 \f(CW\*(C`a\*(C'\fR
  and \f(CW\*(C`b\*(C'\fR in this structure:
  .Sp
*************** and \f(CW\*(C`b\*(C'\fR in this structur
*** 9170,9177 ****
  .Sp
  This warning is enabled by default.  Use
  \&\fB\-Wno\-packed\-bitfield\-compat\fR to disable this warning.
! .IP "\fB\-Wpacked\-not\-aligned\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wpacked-not-aligned (C, , Objective-C and Objective- only)"
  Warn if a structure field with explicitly specified alignment in a
  packed struct or union is misaligned.  For example, a warning will
  be issued on \f(CW\*(C`struct S\*(C'\fR, like, \f(CW\*(C`warning: alignment 1 of
--- 9099,9106 ----
  .Sp
  This warning is enabled by default.  Use
  \&\fB\-Wno\-packed\-bitfield\-compat\fR to disable this warning.
! .IP "\fB\-Wpacked\-not\-aligned\fR (C, C++, Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wpacked-not-aligned (C, C++, Objective-C and Objective-C++ only)"
  Warn if a structure field with explicitly specified alignment in a
  packed struct or union is misaligned.  For example, a warning will
  be issued on \f(CW\*(C`struct S\*(C'\fR, like, \f(CW\*(C`warning: alignment 1 of
*************** be issued on \f(CW\*(C`struct S\*(C'\fR,
*** 9185,9208 ****
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wpadded\fR" 4
  .IX Item "-Wpadded"
  Warn if padding is included in a structure, either to align an element
  of the structure or to align the whole structure.  Sometimes when this
  happens it is possible to rearrange the fields of the structure to
  reduce the padding and so make the structure smaller.
! .IP "\fB\-Wredundant\-decls\fR" 4
  .IX Item "-Wredundant-decls"
  Warn if anything is declared more than once in the same scope, even in
  cases where multiple declaration is valid and changes nothing.
! .IP "\fB\-Wrestrict\fR" 4
  .IX Item "-Wrestrict"
  Warn when an object referenced by a \f(CW\*(C`restrict\*(C'\fR\-qualified parameter
! (or, in \*(C+, a \f(CW\*(C`_\|_restrict\*(C'\fR\-qualified parameter) is aliased by another
  argument, or when copies between such objects overlap.  For example,
  the call to the \f(CW\*(C`strcpy\*(C'\fR function below attempts to truncate the string
  by replacing its initial characters with the last four.  However, because
! the call writes the terminating \s-1NUL\s0 into \f(CW\*(C`a[4]\*(C'\fR, the copies overlap and
  the call is diagnosed.
  .Sp
  .Vb 6
--- 9114,9137 ----
  .Ve
  .Sp
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wpadded\fR 4
  .IX Item "-Wpadded"
  Warn if padding is included in a structure, either to align an element
  of the structure or to align the whole structure.  Sometimes when this
  happens it is possible to rearrange the fields of the structure to
  reduce the padding and so make the structure smaller.
! .IP \fB\-Wredundant\-decls\fR 4
  .IX Item "-Wredundant-decls"
  Warn if anything is declared more than once in the same scope, even in
  cases where multiple declaration is valid and changes nothing.
! .IP \fB\-Wrestrict\fR 4
  .IX Item "-Wrestrict"
  Warn when an object referenced by a \f(CW\*(C`restrict\*(C'\fR\-qualified parameter
! (or, in C++, a \f(CW\*(C`_\|_restrict\*(C'\fR\-qualified parameter) is aliased by another
  argument, or when copies between such objects overlap.  For example,
  the call to the \f(CW\*(C`strcpy\*(C'\fR function below attempts to truncate the string
  by replacing its initial characters with the last four.  However, because
! the call writes the terminating NUL into \f(CW\*(C`a[4]\*(C'\fR, the copies overlap and
  the call is diagnosed.
  .Sp
  .Vb 6
*************** the call is diagnosed.
*** 9217,9226 ****
  The \fB\-Wrestrict\fR option detects some instances of simple overlap
  even without optimization but works best at \fB\-O2\fR and above.  It
  is included in \fB\-Wall\fR.
! .IP "\fB\-Wnested\-externs\fR (C and Objective-C only)" 4
  .IX Item "-Wnested-externs (C and Objective-C only)"
  Warn if an \f(CW\*(C`extern\*(C'\fR declaration is encountered within a function.
! .IP "\fB\-Winline\fR" 4
  .IX Item "-Winline"
  Warn if a function that is declared as inline cannot be inlined.
  Even with this option, the compiler does not warn about failures to
--- 9146,9155 ----
  The \fB\-Wrestrict\fR option detects some instances of simple overlap
  even without optimization but works best at \fB\-O2\fR and above.  It
  is included in \fB\-Wall\fR.
! .IP "\fB\-Wnested\-externs\fR (C and Objective\-C only)" 4
  .IX Item "-Wnested-externs (C and Objective-C only)"
  Warn if an \f(CW\*(C`extern\*(C'\fR declaration is encountered within a function.
! .IP \fB\-Winline\fR 4
  .IX Item "-Winline"
  Warn if a function that is declared as inline cannot be inlined.
  Even with this option, the compiler does not warn about failures to
*************** the size of the function being inlined a
*** 9232,9241 ****
  that has already been done in the current function.  Therefore,
  seemingly insignificant changes in the source program can cause the
  warnings produced by \fB\-Winline\fR to appear or disappear.
! .IP "\fB\-Winterference\-size\fR" 4
  .IX Item "-Winterference-size"
! Warn about use of \*(C+17 \f(CW\*(C`std::hardware_destructive_interference_size\*(C'\fR
! without specifying its value with \fB\-\-param destructive-interference-size\fR.
  Also warn about questionable values for that option.
  .Sp
  This variable is intended to be used for controlling class layout, to
--- 9161,9170 ----
  that has already been done in the current function.  Therefore,
  seemingly insignificant changes in the source program can cause the
  warnings produced by \fB\-Winline\fR to appear or disappear.
! .IP \fB\-Winterference\-size\fR 4
  .IX Item "-Winterference-size"
! Warn about use of C++17 \f(CW\*(C`std::hardware_destructive_interference_size\*(C'\fR
! without specifying its value with \fB\-\-param destructive\-interference\-size\fR.
  Also warn about questionable values for that option.
  .Sp
  This variable is intended to be used for controlling class layout, to
*************** avoid false sharing in concurrent code:
*** 9251,9323 ****
  .Ve
  .Sp
  Here \fBone\fR and \fBtwo\fR are intended to be far enough apart
! that stores to one won't require accesses to the other to reload the
  cache line.
  .Sp
! By default, \fB\-\-param destructive-interference-size\fR and
! \&\fB\-\-param constructive-interference-size\fR are set based on the
  current \fB\-mtune\fR option, typically to the L1 cache line size
! for the particular target \s-1CPU,\s0 sometimes to a range if tuning for a
! generic target.  So all translation units that depend on \s-1ABI\s0
  compatibility for the use of these variables must be compiled with
  the same \fB\-mtune\fR (or \fB\-mcpu\fR).
  .Sp
! If \s-1ABI\s0 stability is important, such as if the use is in a header for a
  library, you should probably not use the hardware interference size
  variables at all.  Alternatively, you can force a particular value
  with \fB\-\-param\fR.
  .Sp
! If you are confident that your use of the variable does not affect \s-1ABI\s0
  outside a single build of your project, you can turn off the warning
  with \fB\-Wno\-interference\-size\fR.
! .IP "\fB\-Wint\-in\-bool\-context\fR" 4
  .IX Item "-Wint-in-bool-context"
  Warn for suspicious use of integer values where boolean values are expected,
! such as conditional expressions (?:) using non-boolean integer constants in
  boolean context, like \f(CW\*(C`if (a <= b ? 2 : 3)\*(C'\fR.  Or left shifting of signed
  integers in boolean context, like \f(CW\*(C`for (a = 0; 1 << a; a++);\*(C'\fR.  Likewise
  for all kinds of multiplications regardless of the data type.
  This warning is enabled by \fB\-Wall\fR.
! .IP "\fB\-Wno\-int\-to\-pointer\-cast\fR" 4
  .IX Item "-Wno-int-to-pointer-cast"
  Suppress warnings from casts to pointer type of an integer of a
! different size. In \*(C+, casting to a pointer type of smaller size is
! an error. \fBWint-to-pointer-cast\fR is enabled by default.
! .IP "\fB\-Wno\-pointer\-to\-int\-cast\fR (C and Objective-C only)" 4
  .IX Item "-Wno-pointer-to-int-cast (C and Objective-C only)"
  Suppress warnings from casts from a pointer to an integer type of a
  different size.
! .IP "\fB\-Winvalid\-pch\fR" 4
  .IX Item "-Winvalid-pch"
  Warn if a precompiled header is found in
  the search path but cannot be used.
! .IP "\fB\-Winvalid\-utf8\fR" 4
  .IX Item "-Winvalid-utf8"
! Warn if an invalid \s-1UTF\-8\s0 character is found.
! This warning is on by default for \*(C+23 if \fB\-finput\-charset=UTF\-8\fR
  is used and turned into error with \fB\-pedantic\-errors\fR.
! .IP "\fB\-Wno\-unicode\fR" 4
  .IX Item "-Wno-unicode"
! Don't diagnose invalid forms of delimited or named escape sequences which are
  treated as separate tokens.  \fBWunicode\fR is enabled by default.
! .IP "\fB\-Wlong\-long\fR" 4
  .IX Item "-Wlong-long"
  Warn if \f(CW\*(C`long long\*(C'\fR type is used.  This is enabled by either
! \&\fB\-Wpedantic\fR or \fB\-Wtraditional\fR in \s-1ISO C90\s0 and \*(C+98
  modes.  To inhibit the warning messages, use \fB\-Wno\-long\-long\fR.
! .IP "\fB\-Wvariadic\-macros\fR" 4
  .IX Item "-Wvariadic-macros"
! Warn if variadic macros are used in \s-1ISO C90\s0 mode, or if the \s-1GNU\s0
! alternate syntax is used in \s-1ISO C99\s0 mode.  This is enabled by either
  \&\fB\-Wpedantic\fR or \fB\-Wtraditional\fR.  To inhibit the warning
  messages, use \fB\-Wno\-variadic\-macros\fR.
! .IP "\fB\-Wno\-varargs\fR" 4
  .IX Item "-Wno-varargs"
  Do not warn upon questionable usage of the macros used to handle variable
  arguments like \f(CW\*(C`va_start\*(C'\fR.  These warnings are enabled by default.
! .IP "\fB\-Wvector\-operation\-performance\fR" 4
  .IX Item "-Wvector-operation-performance"
! Warn if vector operation is not implemented via \s-1SIMD\s0 capabilities of the
  architecture.  Mainly useful for the performance tuning.
  Vector operation can be implemented \f(CW\*(C`piecewise\*(C'\fR, which means that the
  scalar operation is performed on every vector element; 
--- 9180,9252 ----
  .Ve
  .Sp
  Here \fBone\fR and \fBtwo\fR are intended to be far enough apart
! that stores to one won\*(Aqt require accesses to the other to reload the
  cache line.
  .Sp
! By default, \fB\-\-param destructive\-interference\-size\fR and
! \&\fB\-\-param constructive\-interference\-size\fR are set based on the
  current \fB\-mtune\fR option, typically to the L1 cache line size
! for the particular target CPU, sometimes to a range if tuning for a
! generic target.  So all translation units that depend on ABI
  compatibility for the use of these variables must be compiled with
  the same \fB\-mtune\fR (or \fB\-mcpu\fR).
  .Sp
! If ABI stability is important, such as if the use is in a header for a
  library, you should probably not use the hardware interference size
  variables at all.  Alternatively, you can force a particular value
  with \fB\-\-param\fR.
  .Sp
! If you are confident that your use of the variable does not affect ABI
  outside a single build of your project, you can turn off the warning
  with \fB\-Wno\-interference\-size\fR.
! .IP \fB\-Wint\-in\-bool\-context\fR 4
  .IX Item "-Wint-in-bool-context"
  Warn for suspicious use of integer values where boolean values are expected,
! such as conditional expressions (?:) using non\-boolean integer constants in
  boolean context, like \f(CW\*(C`if (a <= b ? 2 : 3)\*(C'\fR.  Or left shifting of signed
  integers in boolean context, like \f(CW\*(C`for (a = 0; 1 << a; a++);\*(C'\fR.  Likewise
  for all kinds of multiplications regardless of the data type.
  This warning is enabled by \fB\-Wall\fR.
! .IP \fB\-Wno\-int\-to\-pointer\-cast\fR 4
  .IX Item "-Wno-int-to-pointer-cast"
  Suppress warnings from casts to pointer type of an integer of a
! different size. In C++, casting to a pointer type of smaller size is
! an error. \fBWint\-to\-pointer\-cast\fR is enabled by default.
! .IP "\fB\-Wno\-pointer\-to\-int\-cast\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-pointer-to-int-cast (C and Objective-C only)"
  Suppress warnings from casts from a pointer to an integer type of a
  different size.
! .IP \fB\-Winvalid\-pch\fR 4
  .IX Item "-Winvalid-pch"
  Warn if a precompiled header is found in
  the search path but cannot be used.
! .IP \fB\-Winvalid\-utf8\fR 4
  .IX Item "-Winvalid-utf8"
! Warn if an invalid UTF\-8 character is found.
! This warning is on by default for C++23 if \fB\-finput\-charset=UTF\-8\fR
  is used and turned into error with \fB\-pedantic\-errors\fR.
! .IP \fB\-Wno\-unicode\fR 4
  .IX Item "-Wno-unicode"
! Don\*(Aqt diagnose invalid forms of delimited or named escape sequences which are
  treated as separate tokens.  \fBWunicode\fR is enabled by default.
! .IP \fB\-Wlong\-long\fR 4
  .IX Item "-Wlong-long"
  Warn if \f(CW\*(C`long long\*(C'\fR type is used.  This is enabled by either
! \&\fB\-Wpedantic\fR or \fB\-Wtraditional\fR in ISO C90 and C++98
  modes.  To inhibit the warning messages, use \fB\-Wno\-long\-long\fR.
! .IP \fB\-Wvariadic\-macros\fR 4
  .IX Item "-Wvariadic-macros"
! Warn if variadic macros are used in ISO C90 mode, or if the GNU
! alternate syntax is used in ISO C99 mode.  This is enabled by either
  \&\fB\-Wpedantic\fR or \fB\-Wtraditional\fR.  To inhibit the warning
  messages, use \fB\-Wno\-variadic\-macros\fR.
! .IP \fB\-Wno\-varargs\fR 4
  .IX Item "-Wno-varargs"
  Do not warn upon questionable usage of the macros used to handle variable
  arguments like \f(CW\*(C`va_start\*(C'\fR.  These warnings are enabled by default.
! .IP \fB\-Wvector\-operation\-performance\fR 4
  .IX Item "-Wvector-operation-performance"
! Warn if vector operation is not implemented via SIMD capabilities of the
  architecture.  Mainly useful for the performance tuning.
  Vector operation can be implemented \f(CW\*(C`piecewise\*(C'\fR, which means that the
  scalar operation is performed on every vector element; 
*************** scalar operation is performed on every v
*** 9325,9364 ****
  using scalars of wider type, which normally is more performance efficient;
  and \f(CW\*(C`as a single scalar\*(C'\fR, which means that vector fits into a
  scalar type.
! .IP "\fB\-Wvla\fR" 4
  .IX Item "-Wvla"
! Warn if a variable-length array is used in the code.
  \&\fB\-Wno\-vla\fR prevents the \fB\-Wpedantic\fR warning of
! the variable-length array.
! .IP "\fB\-Wvla\-larger\-than=\fR\fIbyte-size\fR" 4
  .IX Item "-Wvla-larger-than=byte-size"
  If this option is used, the compiler warns for declarations of
! variable-length arrays whose size is either unbounded, or bounded
! by an argument that allows the array size to exceed \fIbyte-size\fR
! bytes.  This is similar to how \fB\-Walloca\-larger\-than=\fR\fIbyte-size\fR
! works, but with variable-length arrays.
  .Sp
! Note that \s-1GCC\s0 may optimize small variable-length arrays of a known
  value into plain arrays, so this warning may not get triggered for
  such arrays.
  .Sp
! \&\fB\-Wvla\-larger\-than=\fR\fB\s-1PTRDIFF_MAX\s0\fR is enabled by default but
  is typically only effective when \fB\-ftree\-vrp\fR is active (default
  for \fB\-O2\fR and above).
  .Sp
! See also \fB\-Walloca\-larger\-than=\fR\fIbyte-size\fR.
! .IP "\fB\-Wno\-vla\-larger\-than\fR" 4
  .IX Item "-Wno-vla-larger-than"
  Disable \fB\-Wvla\-larger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wvla\-larger\-than=\fR\fB\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Wvla\-parameter\fR" 4
  .IX Item "-Wvla-parameter"
  Warn about redeclarations of functions involving arguments of Variable
  Length Array types of inconsistent kinds or forms, and enable the detection
! of out-of-bounds accesses to such parameters by warnings such as
  \&\fB\-Warray\-bounds\fR.
  .Sp
! If the first function declaration uses the \s-1VLA\s0 form the bound specified
  in the array is assumed to be the minimum number of elements expected to
  be provided in calls to the function and the maximum number of elements
  accessed by it.  Failing to provide arguments of sufficient size or
--- 9254,9293 ----
  using scalars of wider type, which normally is more performance efficient;
  and \f(CW\*(C`as a single scalar\*(C'\fR, which means that vector fits into a
  scalar type.
! .IP \fB\-Wvla\fR 4
  .IX Item "-Wvla"
! Warn if a variable\-length array is used in the code.
  \&\fB\-Wno\-vla\fR prevents the \fB\-Wpedantic\fR warning of
! the variable\-length array.
! .IP \fB\-Wvla\-larger\-than=\fR\fIbyte\-size\fR 4
  .IX Item "-Wvla-larger-than=byte-size"
  If this option is used, the compiler warns for declarations of
! variable\-length arrays whose size is either unbounded, or bounded
! by an argument that allows the array size to exceed \fIbyte\-size\fR
! bytes.  This is similar to how \fB\-Walloca\-larger\-than=\fR\fIbyte\-size\fR
! works, but with variable\-length arrays.
  .Sp
! Note that GCC may optimize small variable\-length arrays of a known
  value into plain arrays, so this warning may not get triggered for
  such arrays.
  .Sp
! \&\fB\-Wvla\-larger\-than=\fR\fBPTRDIFF_MAX\fR is enabled by default but
  is typically only effective when \fB\-ftree\-vrp\fR is active (default
  for \fB\-O2\fR and above).
  .Sp
! See also \fB\-Walloca\-larger\-than=\fR\fIbyte\-size\fR.
! .IP \fB\-Wno\-vla\-larger\-than\fR 4
  .IX Item "-Wno-vla-larger-than"
  Disable \fB\-Wvla\-larger\-than=\fR warnings.  The option is equivalent
! to \fB\-Wvla\-larger\-than=\fR\fBSIZE_MAX\fR or larger.
! .IP \fB\-Wvla\-parameter\fR 4
  .IX Item "-Wvla-parameter"
  Warn about redeclarations of functions involving arguments of Variable
  Length Array types of inconsistent kinds or forms, and enable the detection
! of out\-of\-bounds accesses to such parameters by warnings such as
  \&\fB\-Warray\-bounds\fR.
  .Sp
! If the first function declaration uses the VLA form the bound specified
  in the array is assumed to be the minimum number of elements expected to
  be provided in calls to the function and the maximum number of elements
  accessed by it.  Failing to provide arguments of sufficient size or
*************** accessing more than the maximum number o
*** 9367,9374 ****
  For example, the warning triggers for the following redeclarations because
  the first one allows an array of any size to be passed to \f(CW\*(C`f\*(C'\fR while
  the second one specifies that the array argument must have at least \f(CW\*(C`n\*(C'\fR
! elements.  In addition, calling \f(CW\*(C`f\*(C'\fR with the associated \s-1VLA\s0 bound
! parameter in excess of the actual \s-1VLA\s0 bound triggers a warning as well.
  .Sp
  .Vb 3
  \&        void f (int n, int[n]);
--- 9296,9303 ----
  For example, the warning triggers for the following redeclarations because
  the first one allows an array of any size to be passed to \f(CW\*(C`f\*(C'\fR while
  the second one specifies that the array argument must have at least \f(CW\*(C`n\*(C'\fR
! elements.  In addition, calling \f(CW\*(C`f\*(C'\fR with the associated VLA bound
! parameter in excess of the actual VLA bound triggers a warning as well.
  .Sp
  .Vb 3
  \&        void f (int n, int[n]);
*************** parameter in excess of the actual \s-1VL
*** 9389,9475 ****
  \&\fB\-Wvla\-parameter\fR is included in \fB\-Wall\fR.  The
  \&\fB\-Warray\-parameter\fR option triggers warnings for similar problems
  involving ordinary array arguments.
! .IP "\fB\-Wvolatile\-register\-var\fR" 4
  .IX Item "-Wvolatile-register-var"
  Warn if a register variable is declared volatile.  The volatile
  modifier does not inhibit all optimizations that may eliminate reads
  and/or writes to register variables.  This warning is enabled by
  \&\fB\-Wall\fR.
! .IP "\fB\-Wxor\-used\-as\-pow\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
! .IX Item "-Wxor-used-as-pow (C, , Objective-C and Objective- only)"
  Warn about uses of \f(CW\*(C`^\*(C'\fR, the exclusive or operator, where it appears
  the user meant exponentiation.  Specifically, the warning occurs when the
! left-hand side is the decimal constant 2 or 10 and the right-hand side
  is also a decimal constant.
  .Sp
! In C and \*(C+, \f(CW\*(C`^\*(C'\fR means exclusive or, whereas in some other languages
! (e.g. TeX and some versions of \s-1BASIC\s0) it means exponentiation.
  .Sp
  This warning is enabled by default.  It can be silenced by converting one
  of the operands to hexadecimal.
! .IP "\fB\-Wdisabled\-optimization\fR" 4
  .IX Item "-Wdisabled-optimization"
  Warn if a requested optimization pass is disabled.  This warning does
  not generally indicate that there is anything wrong with your code; it
! merely indicates that \s-1GCC\s0's optimizers are unable to handle the code
  effectively.  Often, the problem is that your code is too big or too
! complex; \s-1GCC\s0 refuses to optimize programs when the optimization
  itself is likely to take inordinate amounts of time.
! .IP "\fB\-Wpointer\-sign\fR (C and Objective-C only)" 4
  .IX Item "-Wpointer-sign (C and Objective-C only)"
  Warn for pointer argument passing or assignment with different signedness.
! This option is only supported for C and Objective-C.  It is implied by
  \&\fB\-Wall\fR and by \fB\-Wpedantic\fR, which can be disabled with
  \&\fB\-Wno\-pointer\-sign\fR.
! .IP "\fB\-Wstack\-protector\fR" 4
  .IX Item "-Wstack-protector"
  This option is only active when \fB\-fstack\-protector\fR is active.  It
  warns about functions that are not protected against stack smashing.
! .IP "\fB\-Woverlength\-strings\fR" 4
  .IX Item "-Woverlength-strings"
! Warn about string constants that are longer than the \*(L"minimum
! maximum\*(R" length specified in the C standard.  Modern compilers
  generally allow string constants that are much longer than the
! standard's minimum limit, but very portable programs should avoid
  using longer strings.
  .Sp
  The limit applies \fIafter\fR string constant concatenation, and does
! not count the trailing \s-1NUL.\s0  In C90, the limit was 509 characters; in
! C99, it was raised to 4095.  \*(C+98 does not specify a normative
! minimum maximum, so we do not diagnose overlength strings in \*(C+.
  .Sp
  This option is implied by \fB\-Wpedantic\fR, and can be disabled with
  \&\fB\-Wno\-overlength\-strings\fR.
! .IP "\fB\-Wunsuffixed\-float\-constants\fR (C and Objective-C only)" 4
  .IX Item "-Wunsuffixed-float-constants (C and Objective-C only)"
  Issue a warning for any floating constant that does not have
  a suffix.  When used together with \fB\-Wsystem\-headers\fR it
  warns about such constants in system header files.  This can be useful
  when preparing code to use with the \f(CW\*(C`FLOAT_CONST_DECIMAL64\*(C'\fR pragma
! from the decimal floating-point extension to C99.
! .IP "\fB\-Wno\-lto\-type\-mismatch\fR" 4
  .IX Item "-Wno-lto-type-mismatch"
! During the link-time optimization, do not warn about type mismatches in
  global declarations from different compilation units.
  Requires \fB\-flto\fR to be enabled.  Enabled by default.
! .IP "\fB\-Wno\-designated\-init\fR (C and Objective-C only)" 4
  .IX Item "-Wno-designated-init (C and Objective-C only)"
  Suppress warnings when a positional initializer is used to initialize
  a structure that has been marked with the \f(CW\*(C`designated_init\*(C'\fR
  attribute.
  .SS "Options That Control Static Analysis"
  .IX Subsection "Options That Control Static Analysis"
! .IP "\fB\-fanalyzer\fR" 4
  .IX Item "-fanalyzer"
  This option enables an static analysis of program flow which looks
! for \*(L"interesting\*(R" interprocedural paths through the
  code, and issues warnings for problems found on them.
  .Sp
! This analysis is much more expensive than other \s-1GCC\s0 warnings.
  .Sp
! In technical terms, it performs coverage-guided symbolic execution of
  the code being compiled.  It is neither sound nor complete: it can
! have false positives and false negatives.  It is a bug-finding tool,
  rather than a tool for proving program correctness.
  .Sp
  The analyzer is only suitable for use on C code in this release.
--- 9318,9404 ----
  \&\fB\-Wvla\-parameter\fR is included in \fB\-Wall\fR.  The
  \&\fB\-Warray\-parameter\fR option triggers warnings for similar problems
  involving ordinary array arguments.
! .IP \fB\-Wvolatile\-register\-var\fR 4
  .IX Item "-Wvolatile-register-var"
  Warn if a register variable is declared volatile.  The volatile
  modifier does not inhibit all optimizations that may eliminate reads
  and/or writes to register variables.  This warning is enabled by
  \&\fB\-Wall\fR.
! .IP "\fB\-Wxor\-used\-as\-pow\fR (C, C++, Objective\-C and Objective\-C++ only)" 4
! .IX Item "-Wxor-used-as-pow (C, C++, Objective-C and Objective-C++ only)"
  Warn about uses of \f(CW\*(C`^\*(C'\fR, the exclusive or operator, where it appears
  the user meant exponentiation.  Specifically, the warning occurs when the
! left\-hand side is the decimal constant 2 or 10 and the right\-hand side
  is also a decimal constant.
  .Sp
! In C and C++, \f(CW\*(C`^\*(C'\fR means exclusive or, whereas in some other languages
! (e.g. TeX and some versions of BASIC) it means exponentiation.
  .Sp
  This warning is enabled by default.  It can be silenced by converting one
  of the operands to hexadecimal.
! .IP \fB\-Wdisabled\-optimization\fR 4
  .IX Item "-Wdisabled-optimization"
  Warn if a requested optimization pass is disabled.  This warning does
  not generally indicate that there is anything wrong with your code; it
! merely indicates that GCC\*(Aqs optimizers are unable to handle the code
  effectively.  Often, the problem is that your code is too big or too
! complex; GCC refuses to optimize programs when the optimization
  itself is likely to take inordinate amounts of time.
! .IP "\fB\-Wpointer\-sign\fR (C and Objective\-C only)" 4
  .IX Item "-Wpointer-sign (C and Objective-C only)"
  Warn for pointer argument passing or assignment with different signedness.
! This option is only supported for C and Objective\-C.  It is implied by
  \&\fB\-Wall\fR and by \fB\-Wpedantic\fR, which can be disabled with
  \&\fB\-Wno\-pointer\-sign\fR.
! .IP \fB\-Wstack\-protector\fR 4
  .IX Item "-Wstack-protector"
  This option is only active when \fB\-fstack\-protector\fR is active.  It
  warns about functions that are not protected against stack smashing.
! .IP \fB\-Woverlength\-strings\fR 4
  .IX Item "-Woverlength-strings"
! Warn about string constants that are longer than the "minimum
! maximum" length specified in the C standard.  Modern compilers
  generally allow string constants that are much longer than the
! standard\*(Aqs minimum limit, but very portable programs should avoid
  using longer strings.
  .Sp
  The limit applies \fIafter\fR string constant concatenation, and does
! not count the trailing 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++.
  .Sp
  This option is implied by \fB\-Wpedantic\fR, and can be disabled with
  \&\fB\-Wno\-overlength\-strings\fR.
! .IP "\fB\-Wunsuffixed\-float\-constants\fR (C and Objective\-C only)" 4
  .IX Item "-Wunsuffixed-float-constants (C and Objective-C only)"
  Issue a warning for any floating constant that does not have
  a suffix.  When used together with \fB\-Wsystem\-headers\fR it
  warns about such constants in system header files.  This can be useful
  when preparing code to use with the \f(CW\*(C`FLOAT_CONST_DECIMAL64\*(C'\fR pragma
! from the decimal floating\-point extension to C99.
! .IP \fB\-Wno\-lto\-type\-mismatch\fR 4
  .IX Item "-Wno-lto-type-mismatch"
! During the link\-time optimization, do not warn about type mismatches in
  global declarations from different compilation units.
  Requires \fB\-flto\fR to be enabled.  Enabled by default.
! .IP "\fB\-Wno\-designated\-init\fR (C and Objective\-C only)" 4
  .IX Item "-Wno-designated-init (C and Objective-C only)"
  Suppress warnings when a positional initializer is used to initialize
  a structure that has been marked with the \f(CW\*(C`designated_init\*(C'\fR
  attribute.
  .SS "Options That Control Static Analysis"
  .IX Subsection "Options That Control Static Analysis"
! .IP \fB\-fanalyzer\fR 4
  .IX Item "-fanalyzer"
  This option enables an static analysis of program flow which looks
! for "interesting" interprocedural paths through the
  code, and issues warnings for problems found on them.
  .Sp
! This analysis is much more expensive than other GCC warnings.
  .Sp
! In technical terms, it performs coverage\-guided symbolic execution of
  the code being compiled.  It is neither sound nor complete: it can
! have false positives and false negatives.  It is a bug\-finding tool,
  rather than a tool for proving program correctness.
  .Sp
  The analyzer is only suitable for use on C code in this release.
*************** Enabling this option effectively enables
*** 9516,9524 ****
  \&\-Wanalyzer\-write\-to\-const
  \&\-Wanalyzer\-write\-to\-string\-literal\fR
  .Sp
! This option is only available if \s-1GCC\s0 was configured with analyzer
  support enabled.
! .IP "\fB\-Wanalyzer\-too\-complex\fR" 4
  .IX Item "-Wanalyzer-too-complex"
  If \fB\-fanalyzer\fR is enabled, the analyzer uses various heuristics
  to attempt to explore the control flow and data flow in the program,
--- 9445,9453 ----
  \&\-Wanalyzer\-write\-to\-const
  \&\-Wanalyzer\-write\-to\-string\-literal\fR
  .Sp
! This option is only available if GCC was configured with analyzer
  support enabled.
! .IP \fB\-Wanalyzer\-too\-complex\fR 4
  .IX Item "-Wanalyzer-too-complex"
  If \fB\-fanalyzer\fR is enabled, the analyzer uses various heuristics
  to attempt to explore the control flow and data flow in the program,
*************** but these can be defeated by sufficientl
*** 9527,9533 ****
  By default, the analysis silently stops if the code is too
  complicated for the analyzer to fully explore and it reaches an internal
  limit.  The \fB\-Wanalyzer\-too\-complex\fR option warns if this occurs.
! .IP "\fB\-Wno\-analyzer\-allocation\-size\fR" 4
  .IX Item "-Wno-analyzer-allocation-size"
  This warning requires \fB\-fanalyzer\fR, which enables it;
  to disable it, use \fB\-Wno\-analyzer\-allocation\-size\fR.
--- 9456,9462 ----
  By default, the analysis silently stops if the code is too
  complicated for the analyzer to fully explore and it reaches an internal
  limit.  The \fB\-Wanalyzer\-too\-complex\fR option warns if this occurs.
! .IP \fB\-Wno\-analyzer\-allocation\-size\fR 4
  .IX Item "-Wno-analyzer-allocation-size"
  This warning requires \fB\-fanalyzer\fR, which enables it;
  to disable it, use \fB\-Wno\-analyzer\-allocation\-size\fR.
*************** This diagnostic warns for paths through
*** 9536,9543 ****
  a buffer is assigned to point at a buffer with a size that is not a
  multiple of \f(CW\*(C`sizeof (*pointer)\*(C'\fR.
  .Sp
! See  \s-1CWE\-131:\s0 Incorrect Calculation of Buffer Size (\f(CW\*(C`https://cwe.mitre.org/data/definitions/131.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-deref\-before\-check\fR" 4
  .IX Item "-Wno-analyzer-deref-before-check"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-deref\-before\-check\fR
--- 9465,9472 ----
  a buffer is assigned to point at a buffer with a size that is not a
  multiple of \f(CW\*(C`sizeof (*pointer)\*(C'\fR.
  .Sp
! See  CWE\-131: Incorrect Calculation of Buffer Size (\f(CW\*(C`https://cwe.mitre.org/data/definitions/131.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-deref\-before\-check\fR 4
  .IX Item "-Wno-analyzer-deref-before-check"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-deref\-before\-check\fR
*************** to disable it.
*** 9545,9565 ****
  .Sp
  This diagnostic warns for paths through the code in which a pointer
  is checked for \f(CW\*(C`NULL\*(C'\fR *after* it has already been
! dereferenced, suggesting that the pointer could have been \s-1NULL.\s0
! Such cases suggest that the check for \s-1NULL\s0 is either redundant,
  or that it needs to be moved to before the pointer is dereferenced.
  .Sp
  This diagnostic also considers values passed to a function argument
! marked with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non-NULL
  value, and thus will complain if such values are checked for \f(CW\*(C`NULL\*(C'\fR
  after returning from such a function call.
  .Sp
  This diagnostic is unlikely to be reported when any level of optimization
! is enabled, as \s-1GCC\s0's optimization logic will typically consider such
! checks for \s-1NULL\s0 as being redundant, and optimize them away before the
! analyzer \*(L"sees\*(R" them.  Hence optimization should be disabled when
  attempting to trigger this diagnostic.
! .IP "\fB\-Wno\-analyzer\-double\-fclose\fR" 4
  .IX Item "-Wno-analyzer-double-fclose"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-double\-fclose\fR to disable it.
--- 9474,9494 ----
  .Sp
  This diagnostic warns for paths through the code in which a pointer
  is checked for \f(CW\*(C`NULL\*(C'\fR *after* it has already been
! dereferenced, suggesting that the pointer could have been NULL.
! Such cases suggest that the check for NULL is either redundant,
  or that it needs to be moved to before the pointer is dereferenced.
  .Sp
  This diagnostic also considers values passed to a function argument
! marked with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non\-NULL
  value, and thus will complain if such values are checked for \f(CW\*(C`NULL\*(C'\fR
  after returning from such a function call.
  .Sp
  This diagnostic is unlikely to be reported when any level of optimization
! is enabled, as GCC\*(Aqs optimization logic will typically consider such
! checks for NULL as being redundant, and optimize them away before the
! analyzer "sees" them.  Hence optimization should be disabled when
  attempting to trigger this diagnostic.
! .IP \fB\-Wno\-analyzer\-double\-fclose\fR 4
  .IX Item "-Wno-analyzer-double-fclose"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-double\-fclose\fR to disable it.
*************** This warning requires \fB\-fanalyzer\fR,
*** 9567,9574 ****
  This diagnostic warns for paths through the code in which a \f(CW\*(C`FILE *\*(C'\fR
  can have \f(CW\*(C`fclose\*(C'\fR called on it more than once.
  .Sp
! See  \s-1CWE\-1341:\s0 Multiple Releases of Same Resource or Handle (\f(CW\*(C`https://cwe.mitre.org/data/definitions/1341.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-double\-free\fR" 4
  .IX Item "-Wno-analyzer-double-free"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-double\-free\fR to disable it.
--- 9496,9503 ----
  This diagnostic warns for paths through the code in which a \f(CW\*(C`FILE *\*(C'\fR
  can have \f(CW\*(C`fclose\*(C'\fR called on it more than once.
  .Sp
! See  CWE\-1341: Multiple Releases of Same Resource or Handle (\f(CW\*(C`https://cwe.mitre.org/data/definitions/1341.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-double\-free\fR 4
  .IX Item "-Wno-analyzer-double-free"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-double\-free\fR to disable it.
*************** This diagnostic warns for paths through
*** 9577,9621 ****
  can have a deallocator called on it more than once, either \f(CW\*(C`free\*(C'\fR,
  or a deallocator referenced by attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  \s-1CWE\-415:\s0 Double Free (\f(CW\*(C`https://cwe.mitre.org/data/definitions/415.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-exposure\-through\-output\-file\fR" 4
  .IX Item "-Wno-analyzer-exposure-through-output-file"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-exposure\-through\-output\-file\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! security-sensitive value is written to an output file
  (such as writing a password to a log file).
  .Sp
! See  \s-1CWE\-532:\s0 Information Exposure Through Log Files (\f(CW\*(C`https://cwe.mitre.org/data/definitions/532.html\*(C'\fR).
! .IP "\fB\-Wanalyzer\-exposure\-through\-uninit\-copy\fR" 4
  .IX Item "-Wanalyzer-exposure-through-uninit-copy"
  This warning requires both \fB\-fanalyzer\fR and the use of a plugin
! to specify a function that copies across a \*(L"trust boundary\*(R".  Use
  \&\fB\-Wno\-analyzer\-exposure\-through\-uninit\-copy\fR to disable it.
  .Sp
! This diagnostic warns for \*(L"infoleaks\*(R" \- paths through the code in which
  uninitialized values are copied across a security boundary
! (such as code within an \s-1OS\s0 kernel that copies a partially-initialized
  struct on the stack to user space).
  .Sp
! See  \s-1CWE\-200:\s0 Exposure of Sensitive Information to an Unauthorized Actor (\f(CW\*(C`https://cwe.mitre.org/data/definitions/200.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-fd\-access\-mode\-mismatch\fR" 4
  .IX Item "-Wno-analyzer-fd-access-mode-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-access\-mode\-mismatch\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through code in which a
! \&\f(CW\*(C`read\*(C'\fR on a write-only file descriptor is attempted, or vice versa.
  .Sp
  This diagnostic also warns for code paths in a which a function with attribute
  \&\f(CW\*(C`fd_arg_read (N)\*(C'\fR is called with a file descriptor opened with
  \&\f(CW\*(C`O_WRONLY\*(C'\fR at referenced argument \f(CW\*(C`N\*(C'\fR or a function with attribute
  \&\f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a file descriptor opened with
  \&\f(CW\*(C`O_RDONLY\*(C'\fR at referenced argument \fIN\fR.
! .IP "\fB\-Wno\-analyzer\-fd\-double\-close\fR" 4
  .IX Item "-Wno-analyzer-fd-double-close"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-double\-close\fR
--- 9506,9550 ----
  can have a deallocator called on it more than once, either \f(CW\*(C`free\*(C'\fR,
  or a deallocator referenced by attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  CWE\-415: Double Free (\f(CW\*(C`https://cwe.mitre.org/data/definitions/415.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-exposure\-through\-output\-file\fR 4
  .IX Item "-Wno-analyzer-exposure-through-output-file"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-exposure\-through\-output\-file\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! security\-sensitive value is written to an output file
  (such as writing a password to a log file).
  .Sp
! See  CWE\-532: Information Exposure Through Log Files (\f(CW\*(C`https://cwe.mitre.org/data/definitions/532.html\*(C'\fR).
! .IP \fB\-Wanalyzer\-exposure\-through\-uninit\-copy\fR 4
  .IX Item "-Wanalyzer-exposure-through-uninit-copy"
  This warning requires both \fB\-fanalyzer\fR and the use of a plugin
! to specify a function that copies across a "trust boundary".  Use
  \&\fB\-Wno\-analyzer\-exposure\-through\-uninit\-copy\fR to disable it.
  .Sp
! This diagnostic warns for "infoleaks" \- paths through the code in which
  uninitialized values are copied across a security boundary
! (such as code within an OS kernel that copies a partially\-initialized
  struct on the stack to user space).
  .Sp
! See  CWE\-200: Exposure of Sensitive Information to an Unauthorized Actor (\f(CW\*(C`https://cwe.mitre.org/data/definitions/200.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-fd\-access\-mode\-mismatch\fR 4
  .IX Item "-Wno-analyzer-fd-access-mode-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-access\-mode\-mismatch\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through code in which a
! \&\f(CW\*(C`read\*(C'\fR on a write\-only file descriptor is attempted, or vice versa.
  .Sp
  This diagnostic also warns for code paths in a which a function with attribute
  \&\f(CW\*(C`fd_arg_read (N)\*(C'\fR is called with a file descriptor opened with
  \&\f(CW\*(C`O_WRONLY\*(C'\fR at referenced argument \f(CW\*(C`N\*(C'\fR or a function with attribute
  \&\f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a file descriptor opened with
  \&\f(CW\*(C`O_RDONLY\*(C'\fR at referenced argument \fIN\fR.
! .IP \fB\-Wno\-analyzer\-fd\-double\-close\fR 4
  .IX Item "-Wno-analyzer-fd-double-close"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-double\-close\fR
*************** to disable it.
*** 9624,9631 ****
  This diagnostic warns for paths through code in which a
  file descriptor can be closed more than once.
  .Sp
! See  \s-1CWE\-1341:\s0 Multiple Releases of Same Resource or Handle (\f(CW\*(C`https://cwe.mitre.org/data/definitions/1341.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-fd\-leak\fR" 4
  .IX Item "-Wno-analyzer-fd-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-leak\fR
--- 9553,9560 ----
  This diagnostic warns for paths through code in which a
  file descriptor can be closed more than once.
  .Sp
! See  CWE\-1341: Multiple Releases of Same Resource or Handle (\f(CW\*(C`https://cwe.mitre.org/data/definitions/1341.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-fd\-leak\fR 4
  .IX Item "-Wno-analyzer-fd-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-leak\fR
*************** to disable it.
*** 9634,9653 ****
  This diagnostic warns for paths through code in which an
  open file descriptor is leaked.
  .Sp
! See  \s-1CWE\-775:\s0 Missing Release of File Descriptor or Handle after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/775.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-fd\-phase\-mismatch\fR" 4
  .IX Item "-Wno-analyzer-fd-phase-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-phase\-mismatch\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through code in which an operation is
! attempted in the wrong phase of a file descriptor's lifetime.
  For example, it will warn on attempts to call \f(CW\*(C`accept\*(C'\fR on a stream
  socket that has not yet had \f(CW\*(C`listen\*(C'\fR successfully called on it.
  .Sp
! See  \s-1CWE\-666:\s0 Operation on Resource in Wrong Phase of Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/666.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-fd\-type\-mismatch\fR" 4
  .IX Item "-Wno-analyzer-fd-type-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-type\-mismatch\fR
--- 9563,9582 ----
  This diagnostic warns for paths through code in which an
  open file descriptor is leaked.
  .Sp
! See  CWE\-775: Missing Release of File Descriptor or Handle after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/775.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-fd\-phase\-mismatch\fR 4
  .IX Item "-Wno-analyzer-fd-phase-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-phase\-mismatch\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through code in which an operation is
! attempted in the wrong phase of a file descriptor\*(Aqs lifetime.
  For example, it will warn on attempts to call \f(CW\*(C`accept\*(C'\fR on a stream
  socket that has not yet had \f(CW\*(C`listen\*(C'\fR successfully called on it.
  .Sp
! See  CWE\-666: Operation on Resource in Wrong Phase of Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/666.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-fd\-type\-mismatch\fR 4
  .IX Item "-Wno-analyzer-fd-type-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-type\-mismatch\fR
*************** operation is attempted on the wrong type
*** 9658,9664 ****
  For example, it will warn on attempts to use socket operations
  on a file descriptor obtained via \f(CW\*(C`open\*(C'\fR, or when attempting
  to use a stream socket operation on a datagram socket.
! .IP "\fB\-Wno\-analyzer\-fd\-use\-after\-close\fR" 4
  .IX Item "-Wno-analyzer-fd-use-after-close"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-use\-after\-close\fR
--- 9587,9593 ----
  For example, it will warn on attempts to use socket operations
  on a file descriptor obtained via \f(CW\*(C`open\*(C'\fR, or when attempting
  to use a stream socket operation on a datagram socket.
! .IP \fB\-Wno\-analyzer\-fd\-use\-after\-close\fR 4
  .IX Item "-Wno-analyzer-fd-use-after-close"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-use\-after\-close\fR
*************** This diagnostic also warns for paths thr
*** 9671,9677 ****
  a function with attribute \f(CW\*(C`fd_arg (N)\*(C'\fR or \f(CW\*(C`fd_arg_read (N)\*(C'\fR
  or \f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a closed file descriptor at
  referenced argument \f(CW\*(C`N\*(C'\fR.
! .IP "\fB\-Wno\-analyzer\-fd\-use\-without\-check\fR" 4
  .IX Item "-Wno-analyzer-fd-use-without-check"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-use\-without\-check\fR
--- 9600,9606 ----
  a function with attribute \f(CW\*(C`fd_arg (N)\*(C'\fR or \f(CW\*(C`fd_arg_read (N)\*(C'\fR
  or \f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a closed file descriptor at
  referenced argument \f(CW\*(C`N\*(C'\fR.
! .IP \fB\-Wno\-analyzer\-fd\-use\-without\-check\fR 4
  .IX Item "-Wno-analyzer-fd-use-without-check"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-fd\-use\-without\-check\fR
*************** This diagnostic also warns for paths thr
*** 9684,9690 ****
  a function with attribute \f(CW\*(C`fd_arg (N)\*(C'\fR or \f(CW\*(C`fd_arg_read (N)\*(C'\fR
  or \f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a file descriptor, at referenced
  argument \f(CW\*(C`N\*(C'\fR, without being checked for validity.
! .IP "\fB\-Wno\-analyzer\-file\-leak\fR" 4
  .IX Item "-Wno-analyzer-file-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-file\-leak\fR
--- 9613,9619 ----
  a function with attribute \f(CW\*(C`fd_arg (N)\*(C'\fR or \f(CW\*(C`fd_arg_read (N)\*(C'\fR
  or \f(CW\*(C`fd_arg_write (N)\*(C'\fR is called with a file descriptor, at referenced
  argument \f(CW\*(C`N\*(C'\fR, without being checked for validity.
! .IP \fB\-Wno\-analyzer\-file\-leak\fR 4
  .IX Item "-Wno-analyzer-file-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-file\-leak\fR
*************** to disable it.
*** 9693,9720 ****
  This diagnostic warns for paths through the code in which a
  \&\f(CW\*(C`\*(C'\fR \f(CW\*(C`FILE *\*(C'\fR stream object is leaked.
  .Sp
! See  \s-1CWE\-775:\s0 Missing Release of File Descriptor or Handle after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/775.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-free\-of\-non\-heap\fR" 4
  .IX Item "-Wno-analyzer-free-of-non-heap"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-free\-of\-non\-heap\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through the code in which \f(CW\*(C`free\*(C'\fR
! is called on a non-heap pointer (e.g. an on-stack buffer, or a global).
  .Sp
! See  \s-1CWE\-590:\s0 Free of Memory not on the Heap (\f(CW\*(C`https://cwe.mitre.org/data/definitions/590.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-imprecise\-fp\-arithmetic\fR" 4
  .IX Item "-Wno-analyzer-imprecise-fp-arithmetic"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-imprecise\-fp\-arithmetic\fR
  to disable it.
  .Sp
! This diagnostic warns for paths through the code in which floating-point
  arithmetic is used in locations where precise computation is needed.  This
! diagnostic only warns on use of floating-point operands inside the
  calculation of an allocation size at the moment.
! .IP "\fB\-Wno\-analyzer\-infinite\-recursion\fR" 4
  .IX Item "-Wno-analyzer-infinite-recursion"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-infinite\-recursion\fR to disable it.
--- 9622,9649 ----
  This diagnostic warns for paths through the code in which a
  \&\f(CW\*(C`\*(C'\fR \f(CW\*(C`FILE *\*(C'\fR stream object is leaked.
  .Sp
! See  CWE\-775: Missing Release of File Descriptor or Handle after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/775.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-free\-of\-non\-heap\fR 4
  .IX Item "-Wno-analyzer-free-of-non-heap"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-free\-of\-non\-heap\fR
  to disable it.
  .Sp
  This diagnostic warns for paths through the code in which \f(CW\*(C`free\*(C'\fR
! is called on a non\-heap pointer (e.g. an on\-stack buffer, or a global).
  .Sp
! See  CWE\-590: Free of Memory not on the Heap (\f(CW\*(C`https://cwe.mitre.org/data/definitions/590.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-imprecise\-fp\-arithmetic\fR 4
  .IX Item "-Wno-analyzer-imprecise-fp-arithmetic"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-imprecise\-fp\-arithmetic\fR
  to disable it.
  .Sp
! This diagnostic warns for paths through the code in which floating\-point
  arithmetic is used in locations where precise computation is needed.  This
! diagnostic only warns on use of floating\-point operands inside the
  calculation of an allocation size at the moment.
! .IP \fB\-Wno\-analyzer\-infinite\-recursion\fR 4
  .IX Item "-Wno-analyzer-infinite-recursion"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-infinite\-recursion\fR to disable it.
*************** This warning requires \fB\-fanalyzer\fR,
*** 9722,9728 ****
  This diagnostics warns for paths through the code which appear to
  lead to infinite recursion.
  .Sp
! Specifically, when the analyzer \*(L"sees\*(R" a recursive call, it will compare
  the state of memory at the entry to the new frame with that at the entry
  to the previous frame of that function on the stack.  The warning is
  issued if nothing in memory appears to be changing; any changes observed
--- 9651,9657 ----
  This diagnostics warns for paths through the code which appear to
  lead to infinite recursion.
  .Sp
! Specifically, when the analyzer "sees" a recursive call, it will compare
  the state of memory at the entry to the new frame with that at the entry
  to the previous frame of that function on the stack.  The warning is
  issued if nothing in memory appears to be changing; any changes observed
*************** to parameters or globals are assumed to
*** 9730,9742 ****
  recursion and thus suppress the warning.
  .Sp
  This diagnostic is likely to miss cases of infinite recursion that
! are convered to iteration by the optimizer before the analyzer \*(L"sees\*(R"
  them.  Hence optimization should be disabled when attempting to trigger
  this diagnostic.
  .Sp
  Compare with \fB\-Winfinite\-recursion\fR, which provides a similar
  diagnostic, but is implemented in a different way.
! .IP "\fB\-Wno\-analyzer\-jump\-through\-null\fR" 4
  .IX Item "-Wno-analyzer-jump-through-null"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-jump\-through\-null\fR
--- 9659,9671 ----
  recursion and thus suppress the warning.
  .Sp
  This diagnostic is likely to miss cases of infinite recursion that
! are convered to iteration by the optimizer before the analyzer "sees"
  them.  Hence optimization should be disabled when attempting to trigger
  this diagnostic.
  .Sp
  Compare with \fB\-Winfinite\-recursion\fR, which provides a similar
  diagnostic, but is implemented in a different way.
! .IP \fB\-Wno\-analyzer\-jump\-through\-null\fR 4
  .IX Item "-Wno-analyzer-jump-through-null"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-jump\-through\-null\fR
*************** to disable it.
*** 9744,9750 ****
  .Sp
  This diagnostic warns for paths through the code in which a \f(CW\*(C`NULL\*(C'\fR
  function pointer is called.
! .IP "\fB\-Wno\-analyzer\-malloc\-leak\fR" 4
  .IX Item "-Wno-analyzer-malloc-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-malloc\-leak\fR
--- 9673,9679 ----
  .Sp
  This diagnostic warns for paths through the code in which a \f(CW\*(C`NULL\*(C'\fR
  function pointer is called.
! .IP \fB\-Wno\-analyzer\-malloc\-leak\fR 4
  .IX Item "-Wno-analyzer-malloc-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-malloc\-leak\fR
*************** This diagnostic warns for paths through
*** 9754,9761 ****
  pointer allocated via an allocator is leaked: either \f(CW\*(C`malloc\*(C'\fR,
  or a function marked with attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  \s-1CWE\-401:\s0 Missing Release of Memory after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/401.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-mismatching\-deallocation\fR" 4
  .IX Item "-Wno-analyzer-mismatching-deallocation"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-mismatching\-deallocation\fR
--- 9683,9690 ----
  pointer allocated via an allocator is leaked: either \f(CW\*(C`malloc\*(C'\fR,
  or a function marked with attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  CWE\-401: Missing Release of Memory after Effective Lifetime (\f(CW\*(C`https://cwe.mitre.org/data/definitions/401.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-mismatching\-deallocation\fR 4
  .IX Item "-Wno-analyzer-mismatching-deallocation"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-mismatching\-deallocation\fR
*************** will warn about mismatches between \f(CW
*** 9768,9838 ****
  and vector \f(CW\*(C`delete[]\*(C'\fR, and those marked as allocator/deallocator
  pairs using attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  \s-1CWE\-762:\s0 Mismatched Memory Management Routines (\f(CW\*(C`https://cwe.mitre.org/data/definitions/762.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-out\-of\-bounds\fR" 4
  .IX Item "-Wno-analyzer-out-of-bounds"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-out\-of\-bounds\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a buffer is
! definitely read or written out-of-bounds.  The diagnostic applies for
  cases where the analyzer is able to determine a constant offset and for
  accesses past the end of a buffer, also a constant capacity.  Further,
  the diagnostic does limited checking for accesses past the end when the
  offset as well as the capacity is symbolic.
  .Sp
! See  \s-1CWE\-119:\s0 Improper Restriction of Operations within the Bounds of a Memory Buffer (\f(CW\*(C`https://cwe.mitre.org/data/definitions/119.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-possible\-null\-argument\fR" 4
  .IX Item "-Wno-analyzer-possible-null-argument"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-possible\-null\-argument\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! possibly-NULL value is passed to a function argument marked
! with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non-NULL
  value.
  .Sp
! See  \s-1CWE\-690:\s0 Unchecked Return Value to \s-1NULL\s0 Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/690.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-possible\-null\-dereference\fR" 4
  .IX Item "-Wno-analyzer-possible-null-dereference"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-possible\-null\-dereference\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! possibly-NULL value is dereferenced.
  .Sp
! See  \s-1CWE\-690:\s0 Unchecked Return Value to \s-1NULL\s0 Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/690.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-null\-argument\fR" 4
  .IX Item "-Wno-analyzer-null-argument"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-null\-argument\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! value known to be \s-1NULL\s0 is passed to a function argument marked
! with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non-NULL
  value.
  .Sp
! See  \s-1CWE\-476: NULL\s0 Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/476.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-null\-dereference\fR" 4
  .IX Item "-Wno-analyzer-null-dereference"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-null\-dereference\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! value known to be \s-1NULL\s0 is dereferenced.
  .Sp
! See  \s-1CWE\-476: NULL\s0 Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/476.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-putenv\-of\-auto\-var\fR" 4
  .IX Item "-Wno-analyzer-putenv-of-auto-var"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-putenv\-of\-auto\-var\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
  call to \f(CW\*(C`putenv\*(C'\fR is passed a pointer to an automatic variable
! or an on-stack buffer.
  .Sp
! See  \s-1POS34\-C.\s0 Do not call \fBputenv()\fR with a pointer to an automatic variable as the argument (\f(CW\*(C`https://wiki.sei.cmu.edu/confluence/x/6NYxBQ\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-shift\-count\-negative\fR" 4
  .IX Item "-Wno-analyzer-shift-count-negative"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-shift\-count\-negative\fR to disable it.
--- 9697,9767 ----
  and vector \f(CW\*(C`delete[]\*(C'\fR, and those marked as allocator/deallocator
  pairs using attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  CWE\-762: Mismatched Memory Management Routines (\f(CW\*(C`https://cwe.mitre.org/data/definitions/762.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-out\-of\-bounds\fR 4
  .IX Item "-Wno-analyzer-out-of-bounds"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-out\-of\-bounds\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a buffer is
! definitely read or written out\-of\-bounds.  The diagnostic applies for
  cases where the analyzer is able to determine a constant offset and for
  accesses past the end of a buffer, also a constant capacity.  Further,
  the diagnostic does limited checking for accesses past the end when the
  offset as well as the capacity is symbolic.
  .Sp
! See  CWE\-119: Improper Restriction of Operations within the Bounds of a Memory Buffer (\f(CW\*(C`https://cwe.mitre.org/data/definitions/119.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-possible\-null\-argument\fR 4
  .IX Item "-Wno-analyzer-possible-null-argument"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-possible\-null\-argument\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! possibly\-NULL value is passed to a function argument marked
! with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non\-NULL
  value.
  .Sp
! See  CWE\-690: Unchecked Return Value to NULL Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/690.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-possible\-null\-dereference\fR 4
  .IX Item "-Wno-analyzer-possible-null-dereference"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-possible\-null\-dereference\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! possibly\-NULL value is dereferenced.
  .Sp
! See  CWE\-690: Unchecked Return Value to NULL Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/690.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-null\-argument\fR 4
  .IX Item "-Wno-analyzer-null-argument"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-null\-argument\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! value known to be NULL is passed to a function argument marked
! with \f(CW\*(C`_\|_attribute_\|_((nonnull))\*(C'\fR as requiring a non\-NULL
  value.
  .Sp
! See  CWE\-476: NULL Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/476.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-null\-dereference\fR 4
  .IX Item "-Wno-analyzer-null-dereference"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-null\-dereference\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! value known to be NULL is dereferenced.
  .Sp
! See  CWE\-476: NULL Pointer Dereference (\f(CW\*(C`https://cwe.mitre.org/data/definitions/476.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-putenv\-of\-auto\-var\fR 4
  .IX Item "-Wno-analyzer-putenv-of-auto-var"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-putenv\-of\-auto\-var\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
  call to \f(CW\*(C`putenv\*(C'\fR is passed a pointer to an automatic variable
! or an on\-stack buffer.
  .Sp
! See  POS34\-C. Do not call \fBputenv()\fR with a pointer to an automatic variable as the argument (\f(CW\*(C`https://wiki.sei.cmu.edu/confluence/x/6NYxBQ\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-shift\-count\-negative\fR 4
  .IX Item "-Wno-analyzer-shift-count-negative"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-shift\-count\-negative\fR to disable it.
*************** This warning requires \fB\-fanalyzer\fR,
*** 9840,9863 ****
  This diagnostic warns for paths through the code in which a
  shift is attempted with a negative count.  It is analogous to
  the \fB\-Wshift\-count\-negative\fR diagnostic implemented in
! the C/\*(C+ front ends, but is implemented based on analyzing
  interprocedural paths, rather than merely parsing the syntax tree.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP "\fB\-Wno\-analyzer\-shift\-count\-overflow\fR" 4
  .IX Item "-Wno-analyzer-shift-count-overflow"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-shift\-count\-overflow\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
  shift is attempted with a count greater than or equal to the
! precision of the operand's type.  It is analogous to
  the \fB\-Wshift\-count\-overflow\fR diagnostic implemented in
! the C/\*(C+ front ends, but is implemented based on analyzing
  interprocedural paths, rather than merely parsing the syntax tree.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP "\fB\-Wno\-analyzer\-stale\-setjmp\-buffer\fR" 4
  .IX Item "-Wno-analyzer-stale-setjmp-buffer"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-stale\-setjmp\-buffer\fR to disable it.
--- 9769,9792 ----
  This diagnostic warns for paths through the code in which a
  shift is attempted with a negative count.  It is analogous to
  the \fB\-Wshift\-count\-negative\fR diagnostic implemented in
! the C/C++ front ends, but is implemented based on analyzing
  interprocedural paths, rather than merely parsing the syntax tree.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP \fB\-Wno\-analyzer\-shift\-count\-overflow\fR 4
  .IX Item "-Wno-analyzer-shift-count-overflow"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-shift\-count\-overflow\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
  shift is attempted with a count greater than or equal to the
! precision of the operand\*(Aqs type.  It is analogous to
  the \fB\-Wshift\-count\-overflow\fR diagnostic implemented in
! the C/C++ front ends, but is implemented based on analyzing
  interprocedural paths, rather than merely parsing the syntax tree.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP \fB\-Wno\-analyzer\-stale\-setjmp\-buffer\fR 4
  .IX Item "-Wno-analyzer-stale-setjmp-buffer"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-stale\-setjmp\-buffer\fR to disable it.
*************** location, it records the stack frame.  T
*** 9871,9897 ****
  when the function containing the \f(CW\*(C`setjmp\*(C'\fR call returns.  Attempting
  to rewind to it via \f(CW\*(C`longjmp\*(C'\fR would reference a stack frame that
  no longer exists, and likely lead to a crash (or worse).
! .IP "\fB\-Wno\-analyzer\-tainted\-allocation\-size\fR" 4
  .IX Item "-Wno-analyzer-tainted-allocation-size"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-allocation\-size\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as the size
  of an allocation without being sanitized, so that an attacker could
  inject an excessively large allocation and potentially cause a denial
  of service attack.
  .Sp
! See  \s-1CWE\-789:\s0 Memory Allocation with Excessive Size Value (\f(CW\*(C`https://cwe.mitre.org/data/definitions/789.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-tainted\-assertion\fR" 4
  .IX Item "-Wno-analyzer-tainted-assertion"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-assertion\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as part of a
  condition without being first sanitized, and that condition guards a
  call to a function marked with attribute \f(CW\*(C`noreturn\*(C'\fR
  (such as the function \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR).  Such functions
--- 9800,9826 ----
  when the function containing the \f(CW\*(C`setjmp\*(C'\fR call returns.  Attempting
  to rewind to it via \f(CW\*(C`longjmp\*(C'\fR would reference a stack frame that
  no longer exists, and likely lead to a crash (or worse).
! .IP \fB\-Wno\-analyzer\-tainted\-allocation\-size\fR 4
  .IX Item "-Wno-analyzer-tainted-allocation-size"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-allocation\-size\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as the size
  of an allocation without being sanitized, so that an attacker could
  inject an excessively large allocation and potentially cause a denial
  of service attack.
  .Sp
! See  CWE\-789: Memory Allocation with Excessive Size Value (\f(CW\*(C`https://cwe.mitre.org/data/definitions/789.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-tainted\-assertion\fR 4
  .IX Item "-Wno-analyzer-tainted-assertion"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-assertion\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as part of a
  condition without being first sanitized, and that condition guards a
  call to a function marked with attribute \f(CW\*(C`noreturn\*(C'\fR
  (such as the function \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR).  Such functions
*************** assertion failure handlers.  For example
*** 9904,9932 ****
  .Sp
  In such cases:
  .RS 4
! .IP "*" 4
! when assertion-checking is enabled: an attacker could trigger
  a denial of service by injecting an assertion failure
! .IP "*" 4
! when assertion-checking is disabled, such as by defining \f(CW\*(C`NDEBUG\*(C'\fR,
  an attacker could inject data that subverts the process, since it
  presumably violates a precondition that is being assumed by the code.
  .RE
  .RS 4
  .Sp
! Note that when assertion-checking is disabled, the assertions are
  typically removed by the preprocessor before the analyzer has a chance
! to \*(L"see\*(R" them, so this diagnostic can only generate warnings on builds
! in which assertion-checking is enabled.
  .Sp
  For the purpose of this warning, any function marked with attribute
  \&\f(CW\*(C`noreturn\*(C'\fR is considered as a possible assertion failure
  handler, including \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR.  Note that these functions
! are sometimes removed by the optimizer before the analyzer \*(L"sees\*(R" them.
  Hence optimization should be disabled when attempting to trigger this
  diagnostic.
  .Sp
! See  \s-1CWE\-617:\s0 Reachable Assertion (\f(CW\*(C`https://cwe.mitre.org/data/definitions/617.html\*(C'\fR).
  .Sp
  The warning can also report problematic constructions such as
  .Sp
--- 9833,9861 ----
  .Sp
  In such cases:
  .RS 4
! .IP * 4
! when assertion\-checking is enabled: an attacker could trigger
  a denial of service by injecting an assertion failure
! .IP * 4
! when assertion\-checking is disabled, such as by defining \f(CW\*(C`NDEBUG\*(C'\fR,
  an attacker could inject data that subverts the process, since it
  presumably violates a precondition that is being assumed by the code.
  .RE
  .RS 4
  .Sp
! Note that when assertion\-checking is disabled, the assertions are
  typically removed by the preprocessor before the analyzer has a chance
! to "see" them, so this diagnostic can only generate warnings on builds
! in which assertion\-checking is enabled.
  .Sp
  For the purpose of this warning, any function marked with attribute
  \&\f(CW\*(C`noreturn\*(C'\fR is considered as a possible assertion failure
  handler, including \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR.  Note that these functions
! are sometimes removed by the optimizer before the analyzer "sees" them.
  Hence optimization should be disabled when attempting to trigger this
  diagnostic.
  .Sp
! See  CWE\-617: Reachable Assertion (\f(CW\*(C`https://cwe.mitre.org/data/definitions/617.html\*(C'\fR).
  .Sp
  The warning can also report problematic constructions such as
  .Sp
*************** The warning can also report problematic
*** 9943,10007 ****
  .Sp
  despite the above not being an assertion failure, strictly speaking.
  .RE
! .IP "\fB\-Wno\-analyzer\-tainted\-array\-index\fR" 4
  .IX Item "-Wno-analyzer-tainted-array-index"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-array\-index\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as the index
  of an array access without being sanitized, so that an attacker
! could inject an out-of-bounds access.
  .Sp
! See  \s-1CWE\-129:\s0 Improper Validation of Array Index (\f(CW\*(C`https://cwe.mitre.org/data/definitions/129.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-tainted\-divisor\fR" 4
  .IX Item "-Wno-analyzer-tainted-divisor"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-divisor\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as the divisor
  in a division or modulus operation without being sanitized, so that
! an attacker could inject a division-by-zero.
  .Sp
! See  \s-1CWE\-369:\s0 Divide By Zero (\f(CW\*(C`https://cwe.mitre.org/data/definitions/369.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-tainted\-offset\fR" 4
  .IX Item "-Wno-analyzer-tainted-offset"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-offset\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as a pointer offset
! without being sanitized, so that an attacker could inject an out-of-bounds
  access.
  .Sp
! See  \s-1CWE\-823:\s0 Use of Out-of-range Pointer Offset (\f(CW\*(C`https://cwe.mitre.org/data/definitions/823.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-tainted\-size\fR" 4
  .IX Item "-Wno-analyzer-tainted-size"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-size\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker's control is used as the size of
  an operation such as \f(CW\*(C`memset\*(C'\fR without being sanitized, so that an
! attacker could inject an out-of-bounds access.
  .Sp
! See  \s-1CWE\-129:\s0 Improper Validation of Array Index (\f(CW\*(C`https://cwe.mitre.org/data/definitions/129.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-unsafe\-call\-within\-signal\-handler\fR" 4
  .IX Item "-Wno-analyzer-unsafe-call-within-signal-handler"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-unsafe\-call\-within\-signal\-handler\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! function known to be async-signal-unsafe (such as \f(CW\*(C`fprintf\*(C'\fR) is
  called from a signal handler.
  .Sp
! See  \s-1CWE\-479:\s0 Signal Handler Use of a Non-reentrant Function (\f(CW\*(C`https://cwe.mitre.org/data/definitions/479.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-use\-after\-free\fR" 4
  .IX Item "-Wno-analyzer-use-after-free"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-after\-free\fR to disable it.
--- 9872,9936 ----
  .Sp
  despite the above not being an assertion failure, strictly speaking.
  .RE
! .IP \fB\-Wno\-analyzer\-tainted\-array\-index\fR 4
  .IX Item "-Wno-analyzer-tainted-array-index"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-array\-index\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as the index
  of an array access without being sanitized, so that an attacker
! could inject an out\-of\-bounds access.
  .Sp
! See  CWE\-129: Improper Validation of Array Index (\f(CW\*(C`https://cwe.mitre.org/data/definitions/129.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-tainted\-divisor\fR 4
  .IX Item "-Wno-analyzer-tainted-divisor"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-divisor\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as the divisor
  in a division or modulus operation without being sanitized, so that
! an attacker could inject a division\-by\-zero.
  .Sp
! See  CWE\-369: Divide By Zero (\f(CW\*(C`https://cwe.mitre.org/data/definitions/369.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-tainted\-offset\fR 4
  .IX Item "-Wno-analyzer-tainted-offset"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-offset\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as a pointer offset
! without being sanitized, so that an attacker could inject an out\-of\-bounds
  access.
  .Sp
! See  CWE\-823: Use of Out\-of\-range Pointer Offset (\f(CW\*(C`https://cwe.mitre.org/data/definitions/823.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-tainted\-size\fR 4
  .IX Item "-Wno-analyzer-tainted-size"
  This warning requires both \fB\-fanalyzer\fR and
  \&\fB\-fanalyzer\-checker=taint\fR to enable it;
  use \fB\-Wno\-analyzer\-tainted\-size\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a value
! that could be under an attacker\*(Aqs control is used as the size of
  an operation such as \f(CW\*(C`memset\*(C'\fR without being sanitized, so that an
! attacker could inject an out\-of\-bounds access.
  .Sp
! See  CWE\-129: Improper Validation of Array Index (\f(CW\*(C`https://cwe.mitre.org/data/definitions/129.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-unsafe\-call\-within\-signal\-handler\fR 4
  .IX Item "-Wno-analyzer-unsafe-call-within-signal-handler"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-unsafe\-call\-within\-signal\-handler\fR to disable it.
  .Sp
  This diagnostic warns for paths through the code in which a
! function known to be async\-signal\-unsafe (such as \f(CW\*(C`fprintf\*(C'\fR) is
  called from a signal handler.
  .Sp
! See  CWE\-479: Signal Handler Use of a Non\-reentrant Function (\f(CW\*(C`https://cwe.mitre.org/data/definitions/479.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-use\-after\-free\fR 4
  .IX Item "-Wno-analyzer-use-after-free"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-after\-free\fR to disable it.
*************** This diagnostic warns for paths through
*** 10010,10017 ****
  pointer is used after a deallocator is called on it: either \f(CW\*(C`free\*(C'\fR,
  or a deallocator referenced by attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  \s-1CWE\-416:\s0 Use After Free (\f(CW\*(C`https://cwe.mitre.org/data/definitions/416.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR" 4
  .IX Item "-Wno-analyzer-use-of-pointer-in-stale-stack-frame"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR
--- 9939,9946 ----
  pointer is used after a deallocator is called on it: either \f(CW\*(C`free\*(C'\fR,
  or a deallocator referenced by attribute \f(CW\*(C`malloc\*(C'\fR.
  .Sp
! See  CWE\-416: Use After Free (\f(CW\*(C`https://cwe.mitre.org/data/definitions/416.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR 4
  .IX Item "-Wno-analyzer-use-of-pointer-in-stale-stack-frame"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR
*************** to disable it.
*** 10019,10025 ****
  .Sp
  This diagnostic warns for paths through the code in which a pointer
  is dereferenced that points to a variable in a stale stack frame.
! .IP "\fB\-Wno\-analyzer\-va\-arg\-type\-mismatch\fR" 4
  .IX Item "-Wno-analyzer-va-arg-type-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-arg\-type\-mismatch\fR
--- 9948,9954 ----
  .Sp
  This diagnostic warns for paths through the code in which a pointer
  is dereferenced that points to a variable in a stale stack frame.
! .IP \fB\-Wno\-analyzer\-va\-arg\-type\-mismatch\fR 4
  .IX Item "-Wno-analyzer-va-arg-type-mismatch"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-arg\-type\-mismatch\fR
*************** the analyzer detects an attempt to use \
*** 10030,10037 ****
  passed to a variadic call, but uses a type that does not match that of
  the expression passed to the call.
  .Sp
! See  \s-1CWE\-686:\s0 Function Call With Incorrect Argument Type (\f(CW\*(C`https://cwe.mitre.org/data/definitions/686.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-va\-list\-exhausted\fR" 4
  .IX Item "-Wno-analyzer-va-list-exhausted"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-exhausted\fR
--- 9959,9966 ----
  passed to a variadic call, but uses a type that does not match that of
  the expression passed to the call.
  .Sp
! See  CWE\-686: Function Call With Incorrect Argument Type (\f(CW\*(C`https://cwe.mitre.org/data/definitions/686.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-va\-list\-exhausted\fR 4
  .IX Item "-Wno-analyzer-va-list-exhausted"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-exhausted\fR
*************** the analyzer detects an attempt to use \
*** 10042,10049 ****
  value passed to a variadic call, but all of the values in the
  \&\f(CW\*(C`va_list\*(C'\fR have already been consumed.
  .Sp
! See  \s-1CWE\-685:\s0 Function Call With Incorrect Number of Arguments (\f(CW\*(C`https://cwe.mitre.org/data/definitions/685.html\*(C'\fR).
! .IP "\fB\-Wno\-analyzer\-va\-list\-leak\fR" 4
  .IX Item "-Wno-analyzer-va-list-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-leak\fR
--- 9971,9978 ----
  value passed to a variadic call, but all of the values in the
  \&\f(CW\*(C`va_list\*(C'\fR have already been consumed.
  .Sp
! See  CWE\-685: Function Call With Incorrect Number of Arguments (\f(CW\*(C`https://cwe.mitre.org/data/definitions/685.html\*(C'\fR).
! .IP \fB\-Wno\-analyzer\-va\-list\-leak\fR 4
  .IX Item "-Wno-analyzer-va-list-leak"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-leak\fR
*************** to disable it.
*** 10052,10058 ****
  This diagnostic warns for interprocedural paths through the code for which
  the analyzer detects that \f(CW\*(C`va_start\*(C'\fR or \f(CW\*(C`va_copy\*(C'\fR has been called
  on a \f(CW\*(C`va_list\*(C'\fR without a corresponding call to \f(CW\*(C`va_end\*(C'\fR.
! .IP "\fB\-Wno\-analyzer\-va\-list\-use\-after\-va\-end\fR" 4
  .IX Item "-Wno-analyzer-va-list-use-after-va-end"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-use\-after\-va\-end\fR
--- 9981,9987 ----
  This diagnostic warns for interprocedural paths through the code for which
  the analyzer detects that \f(CW\*(C`va_start\*(C'\fR or \f(CW\*(C`va_copy\*(C'\fR has been called
  on a \f(CW\*(C`va_list\*(C'\fR without a corresponding call to \f(CW\*(C`va_end\*(C'\fR.
! .IP \fB\-Wno\-analyzer\-va\-list\-use\-after\-va\-end\fR 4
  .IX Item "-Wno-analyzer-va-list-use-after-va-end"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-va\-list\-use\-after\-va\-end\fR
*************** This diagnostic warns for interprocedura
*** 10062,10068 ****
  the analyzer detects an attempt to use a \f(CW\*(C`va_list\*(C'\fR  after
  \&\f(CW\*(C`va_end\*(C'\fR has been called on it.
  \&\f(CW\*(C`va_list\*(C'\fR.
! .IP "\fB\-Wno\-analyzer\-write\-to\-const\fR" 4
  .IX Item "-Wno-analyzer-write-to-const"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-write\-to\-const\fR
--- 9991,9997 ----
  the analyzer detects an attempt to use a \f(CW\*(C`va_list\*(C'\fR  after
  \&\f(CW\*(C`va_end\*(C'\fR has been called on it.
  \&\f(CW\*(C`va_list\*(C'\fR.
! .IP \fB\-Wno\-analyzer\-write\-to\-const\fR 4
  .IX Item "-Wno-analyzer-write-to-const"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-write\-to\-const\fR
*************** This diagnostic warns for paths through
*** 10072,10078 ****
  detects an attempt to write through a pointer to a \f(CW\*(C`const\*(C'\fR object.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP "\fB\-Wno\-analyzer\-write\-to\-string\-literal\fR" 4
  .IX Item "-Wno-analyzer-write-to-string-literal"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-write\-to\-string\-literal\fR
--- 10001,10007 ----
  detects an attempt to write through a pointer to a \f(CW\*(C`const\*(C'\fR object.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP \fB\-Wno\-analyzer\-write\-to\-string\-literal\fR 4
  .IX Item "-Wno-analyzer-write-to-string-literal"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-write\-to\-string\-literal\fR
*************** This diagnostic warns for paths through
*** 10082,10088 ****
  detects an attempt to write through a pointer to a string literal.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP "\fB\-Wno\-analyzer\-use\-of\-uninitialized\-value\fR" 4
  .IX Item "-Wno-analyzer-use-of-uninitialized-value"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-of\-uninitialized\-value\fR to disable it.
--- 10011,10017 ----
  detects an attempt to write through a pointer to a string literal.
  However, the analyzer does not prioritize detection of such paths, so
  false negatives are more likely relative to other warnings.
! .IP \fB\-Wno\-analyzer\-use\-of\-uninitialized\-value\fR 4
  .IX Item "-Wno-analyzer-use-of-uninitialized-value"
  This warning requires \fB\-fanalyzer\fR, which enables it; use
  \&\fB\-Wno\-analyzer\-use\-of\-uninitialized\-value\fR to disable it.
*************** This warning requires \fB\-fanalyzer\fR,
*** 10090,10105 ****
  This diagnostic warns for paths through the code in which an uninitialized
  value is used.
  .Sp
! See  \s-1CWE\-457:\s0 Use of Uninitialized Variable (\f(CW\*(C`https://cwe.mitre.org/data/definitions/457.html\*(C'\fR).
  .PP
  The analyzer has hardcoded knowledge about the behavior of the following
! memory-management functions:
  .ie n .IP "*<""alloca"">" 4
! .el .IP "*<\f(CWalloca\fR>" 4
  .IX Item "*"
  .PD 0
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  .PD
  \&\f(CW\*(C`_\|_builtin_alloc_with_align\*(C'\fR, \f(CW@item\fR \f(CW\*(C`_\|_builtin_calloc\*(C'\fR,
--- 10019,10034 ----
  This diagnostic warns for paths through the code in which an uninitialized
  value is used.
  .Sp
! See  CWE\-457: Use of Uninitialized Variable (\f(CW\*(C`https://cwe.mitre.org/data/definitions/457.html\*(C'\fR).
  .PP
  The analyzer has hardcoded knowledge about the behavior of the following
! memory\-management functions:
  .ie n .IP "*<""alloca"">" 4
! .el .IP *<\f(CWalloca\fR> 4
  .IX Item "*"
  .PD 0
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  .PD
  \&\f(CW\*(C`_\|_builtin_alloc_with_align\*(C'\fR, \f(CW@item\fR \f(CW\*(C`_\|_builtin_calloc\*(C'\fR,
*************** memory-management functions:
*** 10108,10124 ****
  \&\f(CW\*(C`_\|_builtin_memset_chk\*(C'\fR, \f(CW\*(C`_\|_builtin_realloc\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_stack_restore\*(C'\fR, and \f(CW\*(C`_\|_builtin_stack_save\*(C'\fR
  .ie n .IP "*<""calloc"">" 4
! .el .IP "*<\f(CWcalloc\fR>" 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""free"">" 4
! .el .IP "*<\f(CWfree\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""malloc"">" 4
! .el .IP "*<\f(CWmalloc\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""memset"">" 4
! .el .IP "*<\f(CWmemset\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""operator delete"">" 4
  .el .IP "*<\f(CWoperator delete\fR>" 4
--- 10037,10053 ----
  \&\f(CW\*(C`_\|_builtin_memset_chk\*(C'\fR, \f(CW\*(C`_\|_builtin_realloc\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_stack_restore\*(C'\fR, and \f(CW\*(C`_\|_builtin_stack_save\*(C'\fR
  .ie n .IP "*<""calloc"">" 4
! .el .IP *<\f(CWcalloc\fR> 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""free"">" 4
! .el .IP *<\f(CWfree\fR> 4
  .IX Item "*"
  .ie n .IP "*<""malloc"">" 4
! .el .IP *<\f(CWmalloc\fR> 4
  .IX Item "*"
  .ie n .IP "*<""memset"">" 4
! .el .IP *<\f(CWmemset\fR> 4
  .IX Item "*"
  .ie n .IP "*<""operator delete"">" 4
  .el .IP "*<\f(CWoperator delete\fR>" 4
*************** memory-management functions:
*** 10133,10173 ****
  .el .IP "*<\f(CWoperator new []\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""realloc"">" 4
! .el .IP "*<\f(CWrealloc\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""strdup"">" 4
! .el .IP "*<\f(CWstrdup\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""strndup"">" 4
! .el .IP "*<\f(CWstrndup\fR>" 4
  .IX Item "*"
  .PD
  .PP
  of the following functions for working with file descriptors:
  .ie n .IP "*<""open"">" 4
! .el .IP "*<\f(CWopen\fR>" 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""close"">" 4
! .el .IP "*<\f(CWclose\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""creat"">" 4
! .el .IP "*<\f(CWcreat\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""dup"", ""dup2"" and ""dup3"">" 4
  .el .IP "*<\f(CWdup\fR, \f(CWdup2\fR and \f(CWdup3\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""isatty"">" 4
! .el .IP "*<\f(CWisatty\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""pipe"", and ""pipe2"">" 4
  .el .IP "*<\f(CWpipe\fR, and \f(CWpipe2\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""read"">" 4
! .el .IP "*<\f(CWread\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""write"">" 4
! .el .IP "*<\f(CWwrite\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""socket"", ""bind"", ""listen"", ""accept"", and ""connect"">" 4
  .el .IP "*<\f(CWsocket\fR, \f(CWbind\fR, \f(CWlisten\fR, \f(CWaccept\fR, and \f(CWconnect\fR>" 4
--- 10062,10102 ----
  .el .IP "*<\f(CWoperator new []\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""realloc"">" 4
! .el .IP *<\f(CWrealloc\fR> 4
  .IX Item "*"
  .ie n .IP "*<""strdup"">" 4
! .el .IP *<\f(CWstrdup\fR> 4
  .IX Item "*"
  .ie n .IP "*<""strndup"">" 4
! .el .IP *<\f(CWstrndup\fR> 4
  .IX Item "*"
  .PD
  .PP
  of the following functions for working with file descriptors:
  .ie n .IP "*<""open"">" 4
! .el .IP *<\f(CWopen\fR> 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""close"">" 4
! .el .IP *<\f(CWclose\fR> 4
  .IX Item "*"
  .ie n .IP "*<""creat"">" 4
! .el .IP *<\f(CWcreat\fR> 4
  .IX Item "*"
  .ie n .IP "*<""dup"", ""dup2"" and ""dup3"">" 4
  .el .IP "*<\f(CWdup\fR, \f(CWdup2\fR and \f(CWdup3\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""isatty"">" 4
! .el .IP *<\f(CWisatty\fR> 4
  .IX Item "*"
  .ie n .IP "*<""pipe"", and ""pipe2"">" 4
  .el .IP "*<\f(CWpipe\fR, and \f(CWpipe2\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""read"">" 4
! .el .IP *<\f(CWread\fR> 4
  .IX Item "*"
  .ie n .IP "*<""write"">" 4
! .el .IP *<\f(CWwrite\fR> 4
  .IX Item "*"
  .ie n .IP "*<""socket"", ""bind"", ""listen"", ""accept"", and ""connect"">" 4
  .el .IP "*<\f(CWsocket\fR, \f(CWbind\fR, \f(CWlisten\fR, \f(CWaccept\fR, and \f(CWconnect\fR>" 4
*************** of the following functions for working w
*** 10175,10182 ****
  .PD
  .PP
  of the following functions for working with \f(CW\*(C`\*(C'\fR streams:
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  \&\f(CW\*(C`_\|_builtin_fprintf_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_fputc\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_fputc_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_fputs\*(C'\fR,
--- 10104,10111 ----
  .PD
  .PP
  of the following functions for working with \f(CW\*(C`\*(C'\fR streams:
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  \&\f(CW\*(C`_\|_builtin_fprintf_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_fputc\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_fputc_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_fputs\*(C'\fR,
*************** of the following functions for working w
*** 10188,10274 ****
  \&\f(CW\*(C`_\|_builtin_puts_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_vfprintf\*(C'\fR, and
  \&\f(CW\*(C`_\|_builtin_vprintf\*(C'\fR
  .ie n .IP "*<""fopen"">" 4
! .el .IP "*<\f(CWfopen\fR>" 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""fclose"">" 4
! .el .IP "*<\f(CWfclose\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""ferror"">" 4
! .el .IP "*<\f(CWferror\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fgets"">" 4
! .el .IP "*<\f(CWfgets\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fgets_unlocked"">" 4
! .el .IP "*<\f(CWfgets_unlocked\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fileno"">" 4
! .el .IP "*<\f(CWfileno\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fread"">" 4
! .el .IP "*<\f(CWfread\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""getc"">" 4
! .el .IP "*<\f(CWgetc\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""getchar"">" 4
! .el .IP "*<\f(CWgetchar\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fprintf"">" 4
! .el .IP "*<\f(CWfprintf\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""printf"">" 4
! .el .IP "*<\f(CWprintf\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""fwrite"">" 4
! .el .IP "*<\f(CWfwrite\fR>" 4
  .IX Item "*"
  .PD
  .PP
  and of the following functions:
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  \&\f(CW\*(C`_\|_builtin_expect_with_probability\*(C'\fR, \f(CW\*(C`_\|_builtin_strchr\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_strcpy\*(C'\fR, \f(CW\*(C`_\|_builtin_strcpy_chk\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_strlen\*(C'\fR, \f(CW\*(C`_\|_builtin_va_copy\*(C'\fR, and
  \&\f(CW\*(C`_\|_builtin_va_start\*(C'\fR
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""getpass"">" 4
! .el .IP "*<\f(CWgetpass\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""longjmp"">" 4
! .el .IP "*<\f(CWlongjmp\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""putenv"">" 4
! .el .IP "*<\f(CWputenv\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""setjmp"">" 4
! .el .IP "*<\f(CWsetjmp\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""siglongjmp"">" 4
! .el .IP "*<\f(CWsiglongjmp\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""signal"">" 4
! .el .IP "*<\f(CWsignal\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""sigsetjmp"">" 4
! .el .IP "*<\f(CWsigsetjmp\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""strchr"">" 4
! .el .IP "*<\f(CWstrchr\fR>" 4
  .IX Item "*"
  .ie n .IP "*<""strlen"">" 4
! .el .IP "*<\f(CWstrlen\fR>" 4
  .IX Item "*"
  .PD
  .PP
  In addition, various functions with an \f(CW\*(C`_\|_analyzer_\*(C'\fR prefix have
! special meaning to the analyzer, described in the \s-1GCC\s0 Internals manual.
  .PP
  Pertinent parameters for controlling the exploration are:
  .IP "*<\fB\-\-param analyzer\-bb\-explosion\-factor=\fR\fIvalue\fR>" 4
--- 10117,10203 ----
  \&\f(CW\*(C`_\|_builtin_puts_unlocked\*(C'\fR, \f(CW\*(C`_\|_builtin_vfprintf\*(C'\fR, and
  \&\f(CW\*(C`_\|_builtin_vprintf\*(C'\fR
  .ie n .IP "*<""fopen"">" 4
! .el .IP *<\f(CWfopen\fR> 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""fclose"">" 4
! .el .IP *<\f(CWfclose\fR> 4
  .IX Item "*"
  .ie n .IP "*<""ferror"">" 4
! .el .IP *<\f(CWferror\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fgets"">" 4
! .el .IP *<\f(CWfgets\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fgets_unlocked"">" 4
! .el .IP *<\f(CWfgets_unlocked\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fileno"">" 4
! .el .IP *<\f(CWfileno\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fread"">" 4
! .el .IP *<\f(CWfread\fR> 4
  .IX Item "*"
  .ie n .IP "*<""getc"">" 4
! .el .IP *<\f(CWgetc\fR> 4
  .IX Item "*"
  .ie n .IP "*<""getchar"">" 4
! .el .IP *<\f(CWgetchar\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fprintf"">" 4
! .el .IP *<\f(CWfprintf\fR> 4
  .IX Item "*"
  .ie n .IP "*<""printf"">" 4
! .el .IP *<\f(CWprintf\fR> 4
  .IX Item "*"
  .ie n .IP "*<""fwrite"">" 4
! .el .IP *<\f(CWfwrite\fR> 4
  .IX Item "*"
  .PD
  .PP
  and of the following functions:
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  \&\f(CW\*(C`_\|_builtin_expect_with_probability\*(C'\fR, \f(CW\*(C`_\|_builtin_strchr\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_strcpy\*(C'\fR, \f(CW\*(C`_\|_builtin_strcpy_chk\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_strlen\*(C'\fR, \f(CW\*(C`_\|_builtin_va_copy\*(C'\fR, and
  \&\f(CW\*(C`_\|_builtin_va_start\*(C'\fR
! .ie n .IP "*" 4
! .el .IP "*" 4
  .IX Item "*"
  .PD 0
  .ie n .IP "*<""getpass"">" 4
! .el .IP *<\f(CWgetpass\fR> 4
  .IX Item "*"
  .ie n .IP "*<""longjmp"">" 4
! .el .IP *<\f(CWlongjmp\fR> 4
  .IX Item "*"
  .ie n .IP "*<""putenv"">" 4
! .el .IP *<\f(CWputenv\fR> 4
  .IX Item "*"
  .ie n .IP "*<""setjmp"">" 4
! .el .IP *<\f(CWsetjmp\fR> 4
  .IX Item "*"
  .ie n .IP "*<""siglongjmp"">" 4
! .el .IP *<\f(CWsiglongjmp\fR> 4
  .IX Item "*"
  .ie n .IP "*<""signal"">" 4
! .el .IP *<\f(CWsignal\fR> 4
  .IX Item "*"
  .ie n .IP "*<""sigsetjmp"">" 4
! .el .IP *<\f(CWsigsetjmp\fR> 4
  .IX Item "*"
  .ie n .IP "*<""strchr"">" 4
! .el .IP *<\f(CWstrchr\fR> 4
  .IX Item "*"
  .ie n .IP "*<""strlen"">" 4
! .el .IP *<\f(CWstrlen\fR> 4
  .IX Item "*"
  .PD
  .PP
  In addition, various functions with an \f(CW\*(C`_\|_analyzer_\*(C'\fR prefix have
! special meaning to the analyzer, described in the GCC Internals manual.
  .PP
  Pertinent parameters for controlling the exploration are:
  .IP "*<\fB\-\-param analyzer\-bb\-explosion\-factor=\fR\fIvalue\fR>" 4
*************** Pertinent parameters for controlling the
*** 10283,10289 ****
  .PD
  .PP
  The following options control the analyzer.
! .IP "\fB\-fanalyzer\-call\-summaries\fR" 4
  .IX Item "-fanalyzer-call-summaries"
  Simplify interprocedural analysis by computing the effect of certain calls,
  rather than exploring all paths through the function from callsite to each
--- 10212,10218 ----
  .PD
  .PP
  The following options control the analyzer.
! .IP \fB\-fanalyzer\-call\-summaries\fR 4
  .IX Item "-fanalyzer-call-summaries"
  Simplify interprocedural analysis by computing the effect of certain calls,
  rather than exploring all paths through the function from callsite to each
*************** possible return.
*** 10292,10298 ****
  If enabled, call summaries are only used for functions with more than one
  call site, and that are sufficiently complicated (as per
  \&\fB\-\-param analyzer\-min\-snodes\-for\-call\-summary=\fR\fIvalue\fR).
! .IP "\fB\-fanalyzer\-checker=\fR\fIname\fR" 4
  .IX Item "-fanalyzer-checker=name"
  Restrict the analyzer to run just the named checker, and enable it.
  .Sp
--- 10221,10227 ----
  If enabled, call summaries are only used for functions with more than one
  call site, and that are sufficiently complicated (as per
  \&\fB\-\-param analyzer\-min\-snodes\-for\-call\-summary=\fR\fIvalue\fR).
! .IP \fB\-fanalyzer\-checker=\fR\fIname\fR 4
  .IX Item "-fanalyzer-checker=name"
  Restrict the analyzer to run just the named checker, and enable it.
  .Sp
*************** following warnings from \fB\-fanalyzer\f
*** 10325,10331 ****
  \&\-Wanalyzer\-use\-after\-free
  \&\-Wanalyzer\-va\-list\-leak
  \&\-Wanalyzer\-va\-list\-use\-after\-va\-end\fR
! .IP "\fB\-fno\-analyzer\-feasibility\fR" 4
  .IX Item "-fno-analyzer-feasibility"
  This option is intended for analyzer developers.
  .Sp
--- 10254,10260 ----
  \&\-Wanalyzer\-use\-after\-free
  \&\-Wanalyzer\-va\-list\-leak
  \&\-Wanalyzer\-va\-list\-use\-after\-va\-end\fR
! .IP \fB\-fno\-analyzer\-feasibility\fR 4
  .IX Item "-fno-analyzer-feasibility"
  This option is intended for analyzer developers.
  .Sp
*************** for each diagnostic it emits: that the c
*** 10334,10408 ****
  exclusive.  Diagnostics for which no feasible path can be found are rejected.
  This filtering can be suppressed with \fB\-fno\-analyzer\-feasibility\fR, for
  debugging issues in this code.
! .IP "\fB\-fanalyzer\-fine\-grained\fR" 4
  .IX Item "-fanalyzer-fine-grained"
  This option is intended for analyzer developers.
  .Sp
! Internally the analyzer builds an \*(L"exploded graph\*(R" that combines
  control flow graphs with data flow information.
  .Sp
  By default, an edge in this graph can contain the effects of a run
  of multiple statements within a basic block.  With
  \&\fB\-fanalyzer\-fine\-grained\fR, each statement gets its own edge.
! .IP "\fB\-fanalyzer\-show\-duplicate\-count\fR" 4
  .IX Item "-fanalyzer-show-duplicate-count"
  This option is intended for analyzer developers: if multiple diagnostics
  have been detected as being duplicates of each other, it emits a note when
  reporting the best diagnostic, giving the number of additional diagnostics
  that were suppressed by the deduplication logic.
! .IP "\fB\-fno\-analyzer\-state\-merge\fR" 4
  .IX Item "-fno-analyzer-state-merge"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer attempts to simplify analysis by merging
  sufficiently similar states at each program point as it builds its
! \&\*(L"exploded graph\*(R".  With \fB\-fno\-analyzer\-state\-merge\fR this
! merging can be suppressed, for debugging state-handling issues.
! .IP "\fB\-fno\-analyzer\-state\-purge\fR" 4
  .IX Item "-fno-analyzer-state-purge"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer attempts to simplify analysis by purging
  aspects of state at a program point that appear to no longer be relevant
! e.g. the values of locals that aren't accessed later in the function
! and which aren't relevant to leak analysis.
  .Sp
  With \fB\-fno\-analyzer\-state\-purge\fR this purging of state can
! be suppressed, for debugging state-handling issues.
! .IP "\fB\-fno\-analyzer\-suppress\-followups\fR" 4
  .IX Item "-fno-analyzer-suppress-followups"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer will stop exploring an execution path after
  encountering certain diagnostics, in order to avoid potentially issuing a
! cascade of follow-up diagnostics.
  .Sp
  The diagnostics that terminate analysis along a path are:
  .RS 4
! .IP "*<\fB\-Wanalyzer\-null\-argument\fR>" 4
  .IX Item "*<-Wanalyzer-null-argument>"
  .PD 0
! .IP "*<\fB\-Wanalyzer\-null\-dereference\fR>" 4
  .IX Item "*<-Wanalyzer-null-dereference>"
! .IP "*<\fB\-Wanalyzer\-use\-after\-free\fR>" 4
  .IX Item "*<-Wanalyzer-use-after-free>"
! .IP "*<\fB\-Wanalyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR>" 4
  .IX Item "*<-Wanalyzer-use-of-pointer-in-stale-stack-frame>"
! .IP "*<\fB\-Wanalyzer\-use\-of\-uninitialized\-value\fR>" 4
  .IX Item "*<-Wanalyzer-use-of-uninitialized-value>"
  .RE
  .RS 4
- .PD
  .Sp
  With \fB\-fno\-analyzer\-suppress\-followups\fR the analyzer will
  continue to explore such paths even after such diagnostics, which may
  be helpful for debugging issues in the analyzer, or for microbenchmarks
  for detecting undefined behavior.
  .RE
! .IP "\fB\-fanalyzer\-transitivity\fR" 4
  .IX Item "-fanalyzer-transitivity"
  This option enables transitivity of constraints within the analyzer.
! .IP "\fB\-fno\-analyzer\-undo\-inlining\fR" 4
  .IX Item "-fno-analyzer-undo-inlining"
  This option is intended for analyzer developers.
  .Sp
--- 10263,10337 ----
  exclusive.  Diagnostics for which no feasible path can be found are rejected.
  This filtering can be suppressed with \fB\-fno\-analyzer\-feasibility\fR, for
  debugging issues in this code.
! .IP \fB\-fanalyzer\-fine\-grained\fR 4
  .IX Item "-fanalyzer-fine-grained"
  This option is intended for analyzer developers.
  .Sp
! Internally the analyzer builds an "exploded graph" that combines
  control flow graphs with data flow information.
  .Sp
  By default, an edge in this graph can contain the effects of a run
  of multiple statements within a basic block.  With
  \&\fB\-fanalyzer\-fine\-grained\fR, each statement gets its own edge.
! .IP \fB\-fanalyzer\-show\-duplicate\-count\fR 4
  .IX Item "-fanalyzer-show-duplicate-count"
  This option is intended for analyzer developers: if multiple diagnostics
  have been detected as being duplicates of each other, it emits a note when
  reporting the best diagnostic, giving the number of additional diagnostics
  that were suppressed by the deduplication logic.
! .IP \fB\-fno\-analyzer\-state\-merge\fR 4
  .IX Item "-fno-analyzer-state-merge"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer attempts to simplify analysis by merging
  sufficiently similar states at each program point as it builds its
! "exploded graph".  With \fB\-fno\-analyzer\-state\-merge\fR this
! merging can be suppressed, for debugging state\-handling issues.
! .IP \fB\-fno\-analyzer\-state\-purge\fR 4
  .IX Item "-fno-analyzer-state-purge"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer attempts to simplify analysis by purging
  aspects of state at a program point that appear to no longer be relevant
! e.g. the values of locals that aren\*(Aqt accessed later in the function
! and which aren\*(Aqt relevant to leak analysis.
  .Sp
  With \fB\-fno\-analyzer\-state\-purge\fR this purging of state can
! be suppressed, for debugging state\-handling issues.
! .IP \fB\-fno\-analyzer\-suppress\-followups\fR 4
  .IX Item "-fno-analyzer-suppress-followups"
  This option is intended for analyzer developers.
  .Sp
  By default the analyzer will stop exploring an execution path after
  encountering certain diagnostics, in order to avoid potentially issuing a
! cascade of follow\-up diagnostics.
  .Sp
  The diagnostics that terminate analysis along a path are:
  .RS 4
! .IP *<\fB\-Wanalyzer\-null\-argument\fR> 4
  .IX Item "*<-Wanalyzer-null-argument>"
  .PD 0
! .IP *<\fB\-Wanalyzer\-null\-dereference\fR> 4
  .IX Item "*<-Wanalyzer-null-dereference>"
! .IP *<\fB\-Wanalyzer\-use\-after\-free\fR> 4
  .IX Item "*<-Wanalyzer-use-after-free>"
! .IP *<\fB\-Wanalyzer\-use\-of\-pointer\-in\-stale\-stack\-frame\fR> 4
  .IX Item "*<-Wanalyzer-use-of-pointer-in-stale-stack-frame>"
! .IP *<\fB\-Wanalyzer\-use\-of\-uninitialized\-value\fR> 4
  .IX Item "*<-Wanalyzer-use-of-uninitialized-value>"
+ .PD
  .RE
  .RS 4
  .Sp
  With \fB\-fno\-analyzer\-suppress\-followups\fR the analyzer will
  continue to explore such paths even after such diagnostics, which may
  be helpful for debugging issues in the analyzer, or for microbenchmarks
  for detecting undefined behavior.
  .RE
! .IP \fB\-fanalyzer\-transitivity\fR 4
  .IX Item "-fanalyzer-transitivity"
  This option enables transitivity of constraints within the analyzer.
! .IP \fB\-fno\-analyzer\-undo\-inlining\fR 4
  .IX Item "-fno-analyzer-undo-inlining"
  This option is intended for analyzer developers.
  .Sp
*************** This option is intended for analyzer dev
*** 10410,10416 ****
  tools, and some optimizations have already been applied to the code.  In
  particular function inlining may have occurred, leading to the
  interprocedural execution paths emitted by the analyzer containing
! function frames that don't correspond to those in the original source
  code.
  .Sp
  By default the analyzer attempts to reconstruct the original function
--- 10339,10345 ----
  tools, and some optimizations have already been applied to the code.  In
  particular function inlining may have occurred, leading to the
  interprocedural execution paths emitted by the analyzer containing
! function frames that don\*(Aqt correspond to those in the original source
  code.
  .Sp
  By default the analyzer attempts to reconstruct the original function
*************** frames, and to emit events showing the i
*** 10419,10541 ****
  With \fB\-fno\-analyzer\-undo\-inlining\fR this attempt to reconstruct
  the original frame information can be be disabled, which may be of help
  when debugging issues in the analyzer.
! .IP "\fB\-fanalyzer\-verbose\-edges\fR" 4
  .IX Item "-fanalyzer-verbose-edges"
  This option is intended for analyzer developers.  It enables more
! verbose, lower-level detail in the descriptions of control flow
  within diagnostic paths.
! .IP "\fB\-fanalyzer\-verbose\-state\-changes\fR" 4
  .IX Item "-fanalyzer-verbose-state-changes"
  This option is intended for analyzer developers.  It enables more
! verbose, lower-level detail in the descriptions of events relating
  to state machines within diagnostic paths.
! .IP "\fB\-fanalyzer\-verbosity=\fR\fIlevel\fR" 4
  .IX Item "-fanalyzer-verbosity=level"
  This option controls the complexity of the control flow paths that are
  emitted for analyzer diagnostics.
  .Sp
  The \fIlevel\fR can be one of:
  .RS 4
! .IP "\fB0\fR" 4
  .IX Item "0"
  At this level, interprocedural call and return events are displayed,
! along with the most pertinent state-change events relating to
  a diagnostic.  For example, for a double\-\f(CW\*(C`free\*(C'\fR diagnostic,
  both calls to \f(CW\*(C`free\*(C'\fR will be shown.
! .IP "\fB1\fR" 4
  .IX Item "1"
  As per the previous level, but also show events for the entry
  to each function.
! .IP "\fB2\fR" 4
  .IX Item "2"
  As per the previous level, but also show events relating to
  control flow that are significant to triggering the issue
! (e.g. \*(L"true path taken\*(R" at a conditional).
  .Sp
  This level is the default.
! .IP "\fB3\fR" 4
  .IX Item "3"
  As per the previous level, but show all control flow events, not
  just significant ones.
! .IP "\fB4\fR" 4
  .IX Item "4"
  This level is intended for analyzer developers; it adds various
  other events intended for debugging the analyzer.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdump\-analyzer\fR" 4
  .IX Item "-fdump-analyzer"
  Dump internal details about what the analyzer is doing to
! \&\fI\fIfile\fI.analyzer.txt\fR.
  \&\fB\-fdump\-analyzer\-stderr\fR overrides this option.
! .IP "\fB\-fdump\-analyzer\-stderr\fR" 4
  .IX Item "-fdump-analyzer-stderr"
  Dump internal details about what the analyzer is doing to stderr.
  This option overrides \fB\-fdump\-analyzer\fR.
! .IP "\fB\-fdump\-analyzer\-callgraph\fR" 4
  .IX Item "-fdump-analyzer-callgraph"
  Dump a representation of the call graph suitable for viewing with
! GraphViz to \fI\fIfile\fI.callgraph.dot\fR.
! .IP "\fB\-fdump\-analyzer\-exploded\-graph\fR" 4
  .IX Item "-fdump-analyzer-exploded-graph"
! Dump a representation of the \*(L"exploded graph\*(R" suitable for viewing with
! GraphViz to \fI\fIfile\fI.eg.dot\fR.
! Nodes are color-coded based on state-machine states to emphasize
  state changes.
! .IP "\fB\-fdump\-analyzer\-exploded\-nodes\fR" 4
  .IX Item "-fdump-analyzer-exploded-nodes"
! Emit diagnostics showing where nodes in the \*(L"exploded graph\*(R" are
  in relation to the program source.
! .IP "\fB\-fdump\-analyzer\-exploded\-nodes\-2\fR" 4
  .IX Item "-fdump-analyzer-exploded-nodes-2"
! Dump a textual representation of the \*(L"exploded graph\*(R" to
! \&\fI\fIfile\fI.eg.txt\fR.
! .IP "\fB\-fdump\-analyzer\-exploded\-nodes\-3\fR" 4
  .IX Item "-fdump-analyzer-exploded-nodes-3"
! Dump a textual representation of the \*(L"exploded graph\*(R" to
! one dump file per node, to \fI\fIfile\fI.eg\-\fIid\fI.txt\fR.
  This is typically a large number of dump files.
! .IP "\fB\-fdump\-analyzer\-exploded\-paths\fR" 4
  .IX Item "-fdump-analyzer-exploded-paths"
! Dump a textual representation of the \*(L"exploded path\*(R" for each
! diagnostic to \fI\fIfile\fI.\fIidx\fI.\fIkind\fI.epath.txt\fR.
! .IP "\fB\-fdump\-analyzer\-feasibility\fR" 4
  .IX Item "-fdump-analyzer-feasibility"
! Dump internal details about the analyzer's search for feasible paths.
  The details are written in a form suitable for viewing with GraphViz
! to filenames of the form \fI\fIfile\fI.*.fg.dot\fR,
! \&\fI\fIfile\fI.*.tg.dot\fR, and \fI\fIfile\fI.*.fpath.txt\fR.
! .IP "\fB\-fdump\-analyzer\-json\fR" 4
  .IX Item "-fdump-analyzer-json"
! Dump a compressed \s-1JSON\s0 representation of analyzer internals to
! \&\fI\fIfile\fI.analyzer.json.gz\fR.  The precise format is subject
  to change.
! .IP "\fB\-fdump\-analyzer\-state\-purge\fR" 4
  .IX Item "-fdump-analyzer-state-purge"
  As per \fB\-fdump\-analyzer\-supergraph\fR, dump a representation of the
! \&\*(L"supergraph\*(R" suitable for viewing with GraphViz, but annotate the
  graph with information on what state will be purged at each node.
! The graph is written to \fI\fIfile\fI.state\-purge.dot\fR.
! .IP "\fB\-fdump\-analyzer\-supergraph\fR" 4
  .IX Item "-fdump-analyzer-supergraph"
! Dump representations of the \*(L"supergraph\*(R" suitable for viewing with
! GraphViz to \fI\fIfile\fI.supergraph.dot\fR and to
! \&\fI\fIfile\fI.supergraph\-eg.dot\fR.  These show all of the
  control flow graphs in the program, with interprocedural edges for
  calls and returns.  The second dump contains annotations showing nodes
! in the \*(L"exploded graph\*(R" and diagnostics associated with them.
! .IP "\fB\-fdump\-analyzer\-untracked\fR" 4
  .IX Item "-fdump-analyzer-untracked"
  Emit custom warnings with internal details intended for analyzer developers.
  .SS "Options for Debugging Your Program"
  .IX Subsection "Options for Debugging Your Program"
! To tell \s-1GCC\s0 to emit extra information for use by a debugger, in almost 
  all cases you need only to add \fB\-g\fR to your other options.  Some debug
! formats can co-exist (like \s-1DWARF\s0 with \s-1CTF\s0) when each of them is enabled
  explicitly by adding the respective command line option to your other options.
  .PP
! \&\s-1GCC\s0 allows you to use \fB\-g\fR with
  \&\fB\-O\fR.  The shortcuts taken by optimized code may occasionally
  be surprising: some variables you declared may not exist
  at all; flow of control may briefly move where you did not expect it;
--- 10348,10470 ----
  With \fB\-fno\-analyzer\-undo\-inlining\fR this attempt to reconstruct
  the original frame information can be be disabled, which may be of help
  when debugging issues in the analyzer.
! .IP \fB\-fanalyzer\-verbose\-edges\fR 4
  .IX Item "-fanalyzer-verbose-edges"
  This option is intended for analyzer developers.  It enables more
! verbose, lower\-level detail in the descriptions of control flow
  within diagnostic paths.
! .IP \fB\-fanalyzer\-verbose\-state\-changes\fR 4
  .IX Item "-fanalyzer-verbose-state-changes"
  This option is intended for analyzer developers.  It enables more
! verbose, lower\-level detail in the descriptions of events relating
  to state machines within diagnostic paths.
! .IP \fB\-fanalyzer\-verbosity=\fR\fIlevel\fR 4
  .IX Item "-fanalyzer-verbosity=level"
  This option controls the complexity of the control flow paths that are
  emitted for analyzer diagnostics.
  .Sp
  The \fIlevel\fR can be one of:
  .RS 4
! .IP \fB0\fR 4
  .IX Item "0"
  At this level, interprocedural call and return events are displayed,
! along with the most pertinent state\-change events relating to
  a diagnostic.  For example, for a double\-\f(CW\*(C`free\*(C'\fR diagnostic,
  both calls to \f(CW\*(C`free\*(C'\fR will be shown.
! .IP \fB1\fR 4
  .IX Item "1"
  As per the previous level, but also show events for the entry
  to each function.
! .IP \fB2\fR 4
  .IX Item "2"
  As per the previous level, but also show events relating to
  control flow that are significant to triggering the issue
! (e.g. "true path taken" at a conditional).
  .Sp
  This level is the default.
! .IP \fB3\fR 4
  .IX Item "3"
  As per the previous level, but show all control flow events, not
  just significant ones.
! .IP \fB4\fR 4
  .IX Item "4"
  This level is intended for analyzer developers; it adds various
  other events intended for debugging the analyzer.
  .RE
  .RS 4
  .RE
! .IP \fB\-fdump\-analyzer\fR 4
  .IX Item "-fdump-analyzer"
  Dump internal details about what the analyzer is doing to
! \&\fIfile.analyzer.txt\fR.
  \&\fB\-fdump\-analyzer\-stderr\fR overrides this option.
! .IP \fB\-fdump\-analyzer\-stderr\fR 4
  .IX Item "-fdump-analyzer-stderr"
  Dump internal details about what the analyzer is doing to stderr.
  This option overrides \fB\-fdump\-analyzer\fR.
! .IP \fB\-fdump\-analyzer\-callgraph\fR 4
  .IX Item "-fdump-analyzer-callgraph"
  Dump a representation of the call graph suitable for viewing with
! GraphViz to \fIfile.callgraph.dot\fR.
! .IP \fB\-fdump\-analyzer\-exploded\-graph\fR 4
  .IX Item "-fdump-analyzer-exploded-graph"
! Dump a representation of the "exploded graph" suitable for viewing with
! GraphViz to \fIfile.eg.dot\fR.
! Nodes are color\-coded based on state\-machine states to emphasize
  state changes.
! .IP \fB\-fdump\-analyzer\-exploded\-nodes\fR 4
  .IX Item "-fdump-analyzer-exploded-nodes"
! Emit diagnostics showing where nodes in the "exploded graph" are
  in relation to the program source.
! .IP \fB\-fdump\-analyzer\-exploded\-nodes\-2\fR 4
  .IX Item "-fdump-analyzer-exploded-nodes-2"
! Dump a textual representation of the "exploded graph" to
! \&\fIfile.eg.txt\fR.
! .IP \fB\-fdump\-analyzer\-exploded\-nodes\-3\fR 4
  .IX Item "-fdump-analyzer-exploded-nodes-3"
! Dump a textual representation of the "exploded graph" to
! one dump file per node, to \fIfile.eg\-id.txt\fR.
  This is typically a large number of dump files.
! .IP \fB\-fdump\-analyzer\-exploded\-paths\fR 4
  .IX Item "-fdump-analyzer-exploded-paths"
! Dump a textual representation of the "exploded path" for each
! diagnostic to \fIfile.idx.kind.epath.txt\fR.
! .IP \fB\-fdump\-analyzer\-feasibility\fR 4
  .IX Item "-fdump-analyzer-feasibility"
! Dump internal details about the analyzer\*(Aqs search for feasible paths.
  The details are written in a form suitable for viewing with GraphViz
! to filenames of the form \fIfile.*.fg.dot\fR,
! \&\fIfile.*.tg.dot\fR, and \fIfile.*.fpath.txt\fR.
! .IP \fB\-fdump\-analyzer\-json\fR 4
  .IX Item "-fdump-analyzer-json"
! Dump a compressed JSON representation of analyzer internals to
! \&\fIfile.analyzer.json.gz\fR.  The precise format is subject
  to change.
! .IP \fB\-fdump\-analyzer\-state\-purge\fR 4
  .IX Item "-fdump-analyzer-state-purge"
  As per \fB\-fdump\-analyzer\-supergraph\fR, dump a representation of the
! "supergraph" suitable for viewing with GraphViz, but annotate the
  graph with information on what state will be purged at each node.
! The graph is written to \fIfile.state\-purge.dot\fR.
! .IP \fB\-fdump\-analyzer\-supergraph\fR 4
  .IX Item "-fdump-analyzer-supergraph"
! Dump representations of the "supergraph" suitable for viewing with
! GraphViz to \fIfile.supergraph.dot\fR and to
! \&\fIfile.supergraph\-eg.dot\fR.  These show all of the
  control flow graphs in the program, with interprocedural edges for
  calls and returns.  The second dump contains annotations showing nodes
! in the "exploded graph" and diagnostics associated with them.
! .IP \fB\-fdump\-analyzer\-untracked\fR 4
  .IX Item "-fdump-analyzer-untracked"
  Emit custom warnings with internal details intended for analyzer developers.
  .SS "Options for Debugging Your Program"
  .IX Subsection "Options for Debugging Your Program"
! To tell GCC to emit extra information for use by a debugger, in almost 
  all cases you need only to add \fB\-g\fR to your other options.  Some debug
! formats can co\-exist (like DWARF with CTF) when each of them is enabled
  explicitly by adding the respective command line option to your other options.
  .PP
! GCC allows you to use \fB\-g\fR with
  \&\fB\-O\fR.  The shortcuts taken by optimized code may occasionally
  be surprising: some variables you declared may not exist
  at all; flow of control may briefly move where you did not expect it;
*************** using \fB\-Og\fR with \fB\-g\fR.
*** 10550,10633 ****
  With no \fB\-O\fR option at all, some compiler passes that collect
  information useful for debugging do not run at all, so that
  \&\fB\-Og\fR may result in a better debugging experience.
! .IP "\fB\-g\fR" 4
  .IX Item "-g"
! Produce debugging information in the operating system's native format
! (stabs, \s-1COFF, XCOFF,\s0 or \s-1DWARF\s0).  \s-1GDB\s0 can work with this debugging
  information.
  .Sp
  On most systems that use stabs format, \fB\-g\fR enables use of extra
! debugging information that only \s-1GDB\s0 can use; this extra information
! makes debugging work better in \s-1GDB\s0 but probably makes other debuggers
  crash or refuse to read the program.  If you want to control for certain whether
  to generate the extra information, use \fB\-gvms\fR (see below).
! .IP "\fB\-ggdb\fR" 4
  .IX Item "-ggdb"
! Produce debugging information for use by \s-1GDB.\s0  This means to use the
! most expressive format available (\s-1DWARF,\s0 stabs, or the native format
! if neither of those are supported), including \s-1GDB\s0 extensions if at all
  possible.
! .IP "\fB\-gdwarf\fR" 4
  .IX Item "-gdwarf"
  .PD 0
! .IP "\fB\-gdwarf\-\fR\fIversion\fR" 4
  .IX Item "-gdwarf-version"
  .PD
! Produce debugging information in \s-1DWARF\s0 format (if that is supported).
  The value of \fIversion\fR may be either 2, 3, 4 or 5; the default
! version for most targets is 5 (with the exception of VxWorks, \s-1TPF\s0 and
! Darwin/Mac \s-1OS X,\s0 which default to version 2, and \s-1AIX,\s0 which defaults
  to version 4).
  .Sp
! Note that with \s-1DWARF\s0 Version 2, some ports require and always
! use some non-conflicting \s-1DWARF 3\s0 extensions in the unwind tables.
  .Sp
! Version 4 may require \s-1GDB 7.0\s0 and \fB\-fvar\-tracking\-assignments\fR
! for maximum benefit. Version 5 requires \s-1GDB 8.0\s0 or higher.
  .Sp
! \&\s-1GCC\s0 no longer supports \s-1DWARF\s0 Version 1, which is substantially
  different than Version 2 and later.  For historical reasons, some
! other DWARF-related options such as
! \&\fB\-fno\-dwarf2\-cfi\-asm\fR) retain a reference to \s-1DWARF\s0 Version 2
! in their names, but apply to all currently-supported versions of \s-1DWARF.\s0
! .IP "\fB\-gbtf\fR" 4
  .IX Item "-gbtf"
! Request \s-1BTF\s0 debug information.  \s-1BTF\s0 is the default debugging format for the
! eBPF target.  On other targets, like x86, \s-1BTF\s0 debug information can be
! generated along with \s-1DWARF\s0 debug information when both of the debug formats are
  enabled explicitly via their respective command line options.
! .IP "\fB\-gctf\fR" 4
  .IX Item "-gctf"
  .PD 0
! .IP "\fB\-gctf\fR\fIlevel\fR" 4
  .IX Item "-gctflevel"
  .PD
! Request \s-1CTF\s0 debug information and use level to specify how much \s-1CTF\s0 debug
  information should be produced.  If \fB\-gctf\fR is specified
! without a value for level, the default level of \s-1CTF\s0 debug information is 2.
  .Sp
! \&\s-1CTF\s0 debug information can be generated along with \s-1DWARF\s0 debug information when
  both of the debug formats are enabled explicitly via their respective command
  line options.
  .Sp
! Level 0 produces no \s-1CTF\s0 debug information at all.  Thus, \fB\-gctf0\fR
  negates \fB\-gctf\fR.
  .Sp
! Level 1 produces \s-1CTF\s0 information for tracebacks only.  This includes callsite
  information, but does not include type information.
  .Sp
  Level 2 produces type information for entities (functions, data objects etc.)
! at file-scope or global-scope only.
! .IP "\fB\-gvms\fR" 4
  .IX Item "-gvms"
  Produce debugging information in Alpha/VMS debug format (if that is
! supported).  This is the format used by \s-1DEBUG\s0 on Alpha/VMS systems.
! .IP "\fB\-g\fR\fIlevel\fR" 4
  .IX Item "-glevel"
  .PD 0
! .IP "\fB\-ggdb\fR\fIlevel\fR" 4
  .IX Item "-ggdblevel"
! .IP "\fB\-gvms\fR\fIlevel\fR" 4
  .IX Item "-gvmslevel"
  .PD
  Request debugging information and also use \fIlevel\fR to specify how
--- 10479,10562 ----
  With no \fB\-O\fR option at all, some compiler passes that collect
  information useful for debugging do not run at all, so that
  \&\fB\-Og\fR may result in a better debugging experience.
! .IP \fB\-g\fR 4
  .IX Item "-g"
! Produce debugging information in the operating system\*(Aqs native format
! (stabs, COFF, XCOFF, or DWARF).  GDB can work with this debugging
  information.
  .Sp
  On most systems that use stabs format, \fB\-g\fR enables use of extra
! debugging information that only GDB can use; this extra information
! makes debugging work better in GDB but probably makes other debuggers
  crash or refuse to read the program.  If you want to control for certain whether
  to generate the extra information, use \fB\-gvms\fR (see below).
! .IP \fB\-ggdb\fR 4
  .IX Item "-ggdb"
! Produce debugging information for use by GDB.  This means to use the
! most expressive format available (DWARF, stabs, or the native format
! if neither of those are supported), including GDB extensions if at all
  possible.
! .IP \fB\-gdwarf\fR 4
  .IX Item "-gdwarf"
  .PD 0
! .IP \fB\-gdwarf\-\fR\fIversion\fR 4
  .IX Item "-gdwarf-version"
  .PD
! Produce debugging information in DWARF format (if that is supported).
  The value of \fIversion\fR may be either 2, 3, 4 or 5; the default
! version for most targets is 5 (with the exception of VxWorks, TPF and
! Darwin/Mac OS X, which default to version 2, and AIX, which defaults
  to version 4).
  .Sp
! Note that with DWARF Version 2, some ports require and always
! use some non\-conflicting DWARF 3 extensions in the unwind tables.
  .Sp
! Version 4 may require GDB 7.0 and \fB\-fvar\-tracking\-assignments\fR
! for maximum benefit. Version 5 requires GDB 8.0 or higher.
  .Sp
! GCC no longer supports DWARF Version 1, which is substantially
  different than Version 2 and later.  For historical reasons, some
! other DWARF\-related options such as
! \&\fB\-fno\-dwarf2\-cfi\-asm\fR) retain a reference to DWARF Version 2
! in their names, but apply to all currently\-supported versions of DWARF.
! .IP \fB\-gbtf\fR 4
  .IX Item "-gbtf"
! Request BTF debug information.  BTF is the default debugging format for the
! eBPF target.  On other targets, like x86, BTF debug information can be
! generated along with DWARF debug information when both of the debug formats are
  enabled explicitly via their respective command line options.
! .IP \fB\-gctf\fR 4
  .IX Item "-gctf"
  .PD 0
! .IP \fB\-gctf\fR\fIlevel\fR 4
  .IX Item "-gctflevel"
  .PD
! Request CTF debug information and use level to specify how much CTF debug
  information should be produced.  If \fB\-gctf\fR is specified
! without a value for level, the default level of CTF debug information is 2.
  .Sp
! CTF debug information can be generated along with DWARF debug information when
  both of the debug formats are enabled explicitly via their respective command
  line options.
  .Sp
! Level 0 produces no CTF debug information at all.  Thus, \fB\-gctf0\fR
  negates \fB\-gctf\fR.
  .Sp
! Level 1 produces CTF information for tracebacks only.  This includes callsite
  information, but does not include type information.
  .Sp
  Level 2 produces type information for entities (functions, data objects etc.)
! at file\-scope or global\-scope only.
! .IP \fB\-gvms\fR 4
  .IX Item "-gvms"
  Produce debugging information in Alpha/VMS debug format (if that is
! supported).  This is the format used by DEBUG on Alpha/VMS systems.
! .IP \fB\-g\fR\fIlevel\fR 4
  .IX Item "-glevel"
  .PD 0
! .IP \fB\-ggdb\fR\fIlevel\fR 4
  .IX Item "-ggdblevel"
! .IP \fB\-gvms\fR\fIlevel\fR 4
  .IX Item "-gvmslevel"
  .PD
  Request debugging information and also use \fIlevel\fR to specify how
*************** Level 0 produces no debug information at
*** 10637,10643 ****
  \&\fB\-g\fR.
  .Sp
  Level 1 produces minimal information, enough for making backtraces in
! parts of the program that you don't plan to debug.  This includes
  descriptions of functions and external variables, and line number
  tables, but no information about local variables.
  .Sp
--- 10566,10572 ----
  \&\fB\-g\fR.
  .Sp
  Level 1 produces minimal information, enough for making backtraces in
! parts of the program that you don\*(Aqt plan to debug.  This includes
  descriptions of functions and external variables, and line number
  tables, but no information about local variables.
  .Sp
*************** the last such option is the one that is
*** 10651,10688 ****
  \&\fB\-gdwarf\fR does not accept a concatenated debug level, to avoid
  confusion with \fB\-gdwarf\-\fR\fIlevel\fR.
  Instead use an additional \fB\-g\fR\fIlevel\fR option to change the
! debug level for \s-1DWARF.\s0
! .IP "\fB\-fno\-eliminate\-unused\-debug\-symbols\fR" 4
  .IX Item "-fno-eliminate-unused-debug-symbols"
  By default, no debug information is produced for symbols that are not actually
  used. Use this option if you want debug information for all symbols.
! .IP "\fB\-femit\-class\-debug\-always\fR" 4
  .IX Item "-femit-class-debug-always"
! Instead of emitting debugging information for a \*(C+ class in only one
  object file, emit it in all object files using the class.  This option
! should be used only with debuggers that are unable to handle the way \s-1GCC\s0
  normally emits debugging information for classes because using this
  option increases the size of debugging information by as much as a
  factor of two.
! .IP "\fB\-fno\-merge\-debug\-strings\fR" 4
  .IX Item "-fno-merge-debug-strings"
  Direct the linker to not merge together strings in the debugging
  information that are identical in different object files.  Merging is
  not supported by all assemblers or linkers.  Merging decreases the size
  of the debug information in the output file at the cost of increasing
  link processing time.  Merging is enabled by default.
! .IP "\fB\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
  .IX Item "-fdebug-prefix-map=old=new"
! When compiling files residing in directory \fI\fIold\fI\fR, record
  debugging information describing them as if the files resided in
! directory \fI\fInew\fI\fR instead.  This can be used to replace a
! build-time path with an install-time path in the debug info.  It can
  also be used to change an absolute path to a relative path by using
  \&\fI.\fR for \fInew\fR.  This can give more reproducible builds, which
! are location independent, but may require an extra command to tell \s-1GDB\s0
  where to find the source files. See also \fB\-ffile\-prefix\-map\fR
  and \fB\-fcanon\-prefix\-map\fR.
! .IP "\fB\-fvar\-tracking\fR" 4
  .IX Item "-fvar-tracking"
  Run variable tracking pass.  It computes where variables are stored at each
  position in code.  Better debugging information is then generated
--- 10580,10617 ----
  \&\fB\-gdwarf\fR does not accept a concatenated debug level, to avoid
  confusion with \fB\-gdwarf\-\fR\fIlevel\fR.
  Instead use an additional \fB\-g\fR\fIlevel\fR option to change the
! debug level for DWARF.
! .IP \fB\-fno\-eliminate\-unused\-debug\-symbols\fR 4
  .IX Item "-fno-eliminate-unused-debug-symbols"
  By default, no debug information is produced for symbols that are not actually
  used. Use this option if you want debug information for all symbols.
! .IP \fB\-femit\-class\-debug\-always\fR 4
  .IX Item "-femit-class-debug-always"
! Instead of emitting debugging information for a C++ class in only one
  object file, emit it in all object files using the class.  This option
! should be used only with debuggers that are unable to handle the way GCC
  normally emits debugging information for classes because using this
  option increases the size of debugging information by as much as a
  factor of two.
! .IP \fB\-fno\-merge\-debug\-strings\fR 4
  .IX Item "-fno-merge-debug-strings"
  Direct the linker to not merge together strings in the debugging
  information that are identical in different object files.  Merging is
  not supported by all assemblers or linkers.  Merging decreases the size
  of the debug information in the output file at the cost of increasing
  link processing time.  Merging is enabled by default.
! .IP \fB\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 4
  .IX Item "-fdebug-prefix-map=old=new"
! When compiling files residing in directory \fIold\fR, record
  debugging information describing them as if the files resided in
! directory \fInew\fR instead.  This can be used to replace a
! build\-time path with an install\-time path in the debug info.  It can
  also be used to change an absolute path to a relative path by using
  \&\fI.\fR for \fInew\fR.  This can give more reproducible builds, which
! are location independent, but may require an extra command to tell GDB
  where to find the source files. See also \fB\-ffile\-prefix\-map\fR
  and \fB\-fcanon\-prefix\-map\fR.
! .IP \fB\-fvar\-tracking\fR 4
  .IX Item "-fvar-tracking"
  Run variable tracking pass.  It computes where variables are stored at each
  position in code.  Better debugging information is then generated
*************** position in code.  Better debugging info
*** 10691,10826 ****
  It is enabled by default when compiling with optimization (\fB\-Os\fR,
  \&\fB\-O\fR, \fB\-O2\fR, ...), debugging information (\fB\-g\fR) and
  the debug info format supports it.
! .IP "\fB\-fvar\-tracking\-assignments\fR" 4
  .IX Item "-fvar-tracking-assignments"
  Annotate assignments to user variables early in the compilation and
  attempt to carry the annotations over throughout the compilation all the
  way to the end, in an attempt to improve debug information while
  optimizing.  Use of \fB\-gdwarf\-4\fR is recommended along with it.
  .Sp
! It can be enabled even if var-tracking is disabled, in which case
  annotations are created and maintained, but discarded at the end.
  By default, this flag is enabled together with \fB\-fvar\-tracking\fR,
  except when selective scheduling is enabled.
! .IP "\fB\-gsplit\-dwarf\fR" 4
  .IX Item "-gsplit-dwarf"
! If \s-1DWARF\s0 debugging information is enabled, separate as much debugging
  information as possible into a separate output file with the extension
  \&\fI.dwo\fR.  This option allows the build system to avoid linking files with
  debug information.  To be useful, this option requires a debugger capable of
  reading \fI.dwo\fR files.
! .IP "\fB\-gdwarf32\fR" 4
  .IX Item "-gdwarf32"
  .PD 0
! .IP "\fB\-gdwarf64\fR" 4
  .IX Item "-gdwarf64"
  .PD
! If \s-1DWARF\s0 debugging information is enabled, the \fB\-gdwarf32\fR selects
! the 32\-bit \s-1DWARF\s0 format and the \fB\-gdwarf64\fR selects the 64\-bit
! \&\s-1DWARF\s0 format.  The default is target specific, on most targets it is
! \&\fB\-gdwarf32\fR though.  The 32\-bit \s-1DWARF\s0 format is smaller, but
! can't support more than 2GiB of debug information in any of the \s-1DWARF\s0
! debug information sections.  The 64\-bit \s-1DWARF\s0 format allows larger debug
  information and might not be well supported by all consumers yet.
! .IP "\fB\-gdescribe\-dies\fR" 4
  .IX Item "-gdescribe-dies"
! Add description attributes to some \s-1DWARF\s0 DIEs that have no name attribute,
  such as artificial variables, external references and call site
  parameter DIEs.
! .IP "\fB\-gpubnames\fR" 4
  .IX Item "-gpubnames"
! Generate \s-1DWARF\s0 \f(CW\*(C`.debug_pubnames\*(C'\fR and \f(CW\*(C`.debug_pubtypes\*(C'\fR sections.
! .IP "\fB\-ggnu\-pubnames\fR" 4
  .IX Item "-ggnu-pubnames"
  Generate \f(CW\*(C`.debug_pubnames\*(C'\fR and \f(CW\*(C`.debug_pubtypes\*(C'\fR sections in a format
! suitable for conversion into a \s-1GDB\s0 index.  This option is only useful
! with a linker that can produce \s-1GDB\s0 index version 7.
! .IP "\fB\-fdebug\-types\-section\fR" 4
  .IX Item "-fdebug-types-section"
! When using \s-1DWARF\s0 Version 4 or higher, type DIEs can be put into
  their own \f(CW\*(C`.debug_types\*(C'\fR section instead of making them part of the
  \&\f(CW\*(C`.debug_info\*(C'\fR section.  It is more efficient to put them in a separate
  comdat section since the linker can then remove duplicates.
! But not all \s-1DWARF\s0 consumers support \f(CW\*(C`.debug_types\*(C'\fR sections yet
  and on some objects \f(CW\*(C`.debug_types\*(C'\fR produces larger instead of smaller
  debugging information.
! .IP "\fB\-grecord\-gcc\-switches\fR" 4
  .IX Item "-grecord-gcc-switches"
  .PD 0
! .IP "\fB\-gno\-record\-gcc\-switches\fR" 4
  .IX Item "-gno-record-gcc-switches"
  .PD
! This switch causes the command-line options used to invoke the
  compiler that may affect code generation to be appended to the
! DW_AT_producer attribute in \s-1DWARF\s0 debugging information.  The options
  are concatenated with spaces separating them from each other and from
  the compiler version.  
  It is enabled by default.
  See also \fB\-frecord\-gcc\-switches\fR for another
  way of storing compiler options into the object file.
! .IP "\fB\-gstrict\-dwarf\fR" 4
  .IX Item "-gstrict-dwarf"
! Disallow using extensions of later \s-1DWARF\s0 standard version than selected
! with \fB\-gdwarf\-\fR\fIversion\fR.  On most targets using non-conflicting
! \&\s-1DWARF\s0 extensions from later standard versions is allowed.
! .IP "\fB\-gno\-strict\-dwarf\fR" 4
  .IX Item "-gno-strict-dwarf"
! Allow using extensions of later \s-1DWARF\s0 standard version than selected with
  \&\fB\-gdwarf\-\fR\fIversion\fR.
! .IP "\fB\-gas\-loc\-support\fR" 4
  .IX Item "-gas-loc-support"
  Inform the compiler that the assembler supports \f(CW\*(C`.loc\*(C'\fR directives.
! It may then use them for the assembler to generate \s-1DWARF2+\s0 line number
  tables.
  .Sp
! This is generally desirable, because assembler-generated line-number
  tables are a lot more compact than those the compiler can generate
  itself.
  .Sp
! This option will be enabled by default if, at \s-1GCC\s0 configure time, the
  assembler was found to support such directives.
! .IP "\fB\-gno\-as\-loc\-support\fR" 4
  .IX Item "-gno-as-loc-support"
! Force \s-1GCC\s0 to generate \s-1DWARF2+\s0 line number tables internally, if \s-1DWARF2+\s0
  line number tables are to be generated.
! .IP "\fB\-gas\-locview\-support\fR" 4
  .IX Item "-gas-locview-support"
  Inform the compiler that the assembler supports \f(CW\*(C`view\*(C'\fR assignment
  and reset assertion checking in \f(CW\*(C`.loc\*(C'\fR directives.
  .Sp
! This option will be enabled by default if, at \s-1GCC\s0 configure time, the
  assembler was found to support them.
! .IP "\fB\-gno\-as\-locview\-support\fR" 4
  .IX Item "-gno-as-locview-support"
! Force \s-1GCC\s0 to assign view numbers internally, if
  \&\fB\-gvariable\-location\-views\fR are explicitly requested.
! .IP "\fB\-gcolumn\-info\fR" 4
  .IX Item "-gcolumn-info"
  .PD 0
! .IP "\fB\-gno\-column\-info\fR" 4
  .IX Item "-gno-column-info"
  .PD
! Emit location column information into \s-1DWARF\s0 debugging information, rather
  than just file and line.
  This option is enabled by default.
! .IP "\fB\-gstatement\-frontiers\fR" 4
  .IX Item "-gstatement-frontiers"
  .PD 0
! .IP "\fB\-gno\-statement\-frontiers\fR" 4
  .IX Item "-gno-statement-frontiers"
  .PD
! This option causes \s-1GCC\s0 to create markers in the internal representation
  at the beginning of statements, and to keep them roughly in place
  throughout compilation, using them to guide the output of \f(CW\*(C`is_stmt\*(C'\fR
  markers in the line number table.  This is enabled by default when
  compiling with optimization (\fB\-Os\fR, \fB\-O1\fR, \fB\-O2\fR,
! \&...), and outputting \s-1DWARF 2\s0 debug information at the normal level.
! .IP "\fB\-gvariable\-location\-views\fR" 4
  .IX Item "-gvariable-location-views"
  .PD 0
! .IP "\fB\-gvariable\-location\-views=incompat5\fR" 4
  .IX Item "-gvariable-location-views=incompat5"
! .IP "\fB\-gno\-variable\-location\-views\fR" 4
  .IX Item "-gno-variable-location-views"
  .PD
  Augment variable location lists with progressive view numbers implied
--- 10620,10755 ----
  It is enabled by default when compiling with optimization (\fB\-Os\fR,
  \&\fB\-O\fR, \fB\-O2\fR, ...), debugging information (\fB\-g\fR) and
  the debug info format supports it.
! .IP \fB\-fvar\-tracking\-assignments\fR 4
  .IX Item "-fvar-tracking-assignments"
  Annotate assignments to user variables early in the compilation and
  attempt to carry the annotations over throughout the compilation all the
  way to the end, in an attempt to improve debug information while
  optimizing.  Use of \fB\-gdwarf\-4\fR is recommended along with it.
  .Sp
! It can be enabled even if var\-tracking is disabled, in which case
  annotations are created and maintained, but discarded at the end.
  By default, this flag is enabled together with \fB\-fvar\-tracking\fR,
  except when selective scheduling is enabled.
! .IP \fB\-gsplit\-dwarf\fR 4
  .IX Item "-gsplit-dwarf"
! If DWARF debugging information is enabled, separate as much debugging
  information as possible into a separate output file with the extension
  \&\fI.dwo\fR.  This option allows the build system to avoid linking files with
  debug information.  To be useful, this option requires a debugger capable of
  reading \fI.dwo\fR files.
! .IP \fB\-gdwarf32\fR 4
  .IX Item "-gdwarf32"
  .PD 0
! .IP \fB\-gdwarf64\fR 4
  .IX Item "-gdwarf64"
  .PD
! If DWARF debugging information is enabled, the \fB\-gdwarf32\fR selects
! the 32\-bit DWARF format and the \fB\-gdwarf64\fR selects the 64\-bit
! DWARF format.  The default is target specific, on most targets it is
! \&\fB\-gdwarf32\fR though.  The 32\-bit DWARF format is smaller, but
! can\*(Aqt support more than 2GiB of debug information in any of the DWARF
! debug information sections.  The 64\-bit DWARF format allows larger debug
  information and might not be well supported by all consumers yet.
! .IP \fB\-gdescribe\-dies\fR 4
  .IX Item "-gdescribe-dies"
! Add description attributes to some DWARF DIEs that have no name attribute,
  such as artificial variables, external references and call site
  parameter DIEs.
! .IP \fB\-gpubnames\fR 4
  .IX Item "-gpubnames"
! Generate DWARF \f(CW\*(C`.debug_pubnames\*(C'\fR and \f(CW\*(C`.debug_pubtypes\*(C'\fR sections.
! .IP \fB\-ggnu\-pubnames\fR 4
  .IX Item "-ggnu-pubnames"
  Generate \f(CW\*(C`.debug_pubnames\*(C'\fR and \f(CW\*(C`.debug_pubtypes\*(C'\fR sections in a format
! suitable for conversion into a GDB index.  This option is only useful
! with a linker that can produce GDB index version 7.
! .IP \fB\-fdebug\-types\-section\fR 4
  .IX Item "-fdebug-types-section"
! When using DWARF Version 4 or higher, type DIEs can be put into
  their own \f(CW\*(C`.debug_types\*(C'\fR section instead of making them part of the
  \&\f(CW\*(C`.debug_info\*(C'\fR section.  It is more efficient to put them in a separate
  comdat section since the linker can then remove duplicates.
! But not all DWARF consumers support \f(CW\*(C`.debug_types\*(C'\fR sections yet
  and on some objects \f(CW\*(C`.debug_types\*(C'\fR produces larger instead of smaller
  debugging information.
! .IP \fB\-grecord\-gcc\-switches\fR 4
  .IX Item "-grecord-gcc-switches"
  .PD 0
! .IP \fB\-gno\-record\-gcc\-switches\fR 4
  .IX Item "-gno-record-gcc-switches"
  .PD
! This switch causes the command\-line options used to invoke the
  compiler that may affect code generation to be appended to the
! DW_AT_producer attribute in DWARF debugging information.  The options
  are concatenated with spaces separating them from each other and from
  the compiler version.  
  It is enabled by default.
  See also \fB\-frecord\-gcc\-switches\fR for another
  way of storing compiler options into the object file.
! .IP \fB\-gstrict\-dwarf\fR 4
  .IX Item "-gstrict-dwarf"
! Disallow using extensions of later DWARF standard version than selected
! with \fB\-gdwarf\-\fR\fIversion\fR.  On most targets using non\-conflicting
! DWARF extensions from later standard versions is allowed.
! .IP \fB\-gno\-strict\-dwarf\fR 4
  .IX Item "-gno-strict-dwarf"
! Allow using extensions of later DWARF standard version than selected with
  \&\fB\-gdwarf\-\fR\fIversion\fR.
! .IP \fB\-gas\-loc\-support\fR 4
  .IX Item "-gas-loc-support"
  Inform the compiler that the assembler supports \f(CW\*(C`.loc\*(C'\fR directives.
! It may then use them for the assembler to generate DWARF2+ line number
  tables.
  .Sp
! This is generally desirable, because assembler\-generated line\-number
  tables are a lot more compact than those the compiler can generate
  itself.
  .Sp
! This option will be enabled by default if, at GCC configure time, the
  assembler was found to support such directives.
! .IP \fB\-gno\-as\-loc\-support\fR 4
  .IX Item "-gno-as-loc-support"
! Force GCC to generate DWARF2+ line number tables internally, if DWARF2+
  line number tables are to be generated.
! .IP \fB\-gas\-locview\-support\fR 4
  .IX Item "-gas-locview-support"
  Inform the compiler that the assembler supports \f(CW\*(C`view\*(C'\fR assignment
  and reset assertion checking in \f(CW\*(C`.loc\*(C'\fR directives.
  .Sp
! This option will be enabled by default if, at GCC configure time, the
  assembler was found to support them.
! .IP \fB\-gno\-as\-locview\-support\fR 4
  .IX Item "-gno-as-locview-support"
! Force GCC to assign view numbers internally, if
  \&\fB\-gvariable\-location\-views\fR are explicitly requested.
! .IP \fB\-gcolumn\-info\fR 4
  .IX Item "-gcolumn-info"
  .PD 0
! .IP \fB\-gno\-column\-info\fR 4
  .IX Item "-gno-column-info"
  .PD
! Emit location column information into DWARF debugging information, rather
  than just file and line.
  This option is enabled by default.
! .IP \fB\-gstatement\-frontiers\fR 4
  .IX Item "-gstatement-frontiers"
  .PD 0
! .IP \fB\-gno\-statement\-frontiers\fR 4
  .IX Item "-gno-statement-frontiers"
  .PD
! This option causes GCC to create markers in the internal representation
  at the beginning of statements, and to keep them roughly in place
  throughout compilation, using them to guide the output of \f(CW\*(C`is_stmt\*(C'\fR
  markers in the line number table.  This is enabled by default when
  compiling with optimization (\fB\-Os\fR, \fB\-O1\fR, \fB\-O2\fR,
! \&...), and outputting DWARF 2 debug information at the normal level.
! .IP \fB\-gvariable\-location\-views\fR 4
  .IX Item "-gvariable-location-views"
  .PD 0
! .IP \fB\-gvariable\-location\-views=incompat5\fR 4
  .IX Item "-gvariable-location-views=incompat5"
! .IP \fB\-gno\-variable\-location\-views\fR 4
  .IX Item "-gno-variable-location-views"
  .PD
  Augment variable location lists with progressive view numbers implied
*************** associated with the corresponding source
*** 10830,10894 ****
  point.  If the assembler lacks support for view numbers in line number
  tables, this will cause the compiler to emit the line number table,
  which generally makes them somewhat less compact.  The augmented line
! number tables and location lists are fully backward-compatible, so they
  can be consumed by debug information consumers that are not aware of
! these augmentations, but they won't derive any benefit from them either.
  .Sp
! This is enabled by default when outputting \s-1DWARF 2\s0 debug information at
  the normal level, as long as there is assembler support,
  \&\fB\-fvar\-tracking\-assignments\fR is enabled and
  \&\fB\-gstrict\-dwarf\fR is not.  When assembler support is not
! available, this may still be enabled, but it will force \s-1GCC\s0 to output
  internal line number tables, and if
  \&\fB\-ginternal\-reset\-location\-views\fR is not enabled, that will most
  certainly lead to silently mismatching location views.
  .Sp
  There is a proposed representation for view numbers that is not backward
! compatible with the location list format introduced in \s-1DWARF 5,\s0 that can
  be enabled with \fB\-gvariable\-location\-views=incompat5\fR.  This
  option may be removed in the future, is only provided as a reference
  implementation of the proposed representation.  Debug information
  consumers are not expected to support this extended format, and they
  would be rendered unable to decode location lists using it.
! .IP "\fB\-ginternal\-reset\-location\-views\fR" 4
  .IX Item "-ginternal-reset-location-views"
  .PD 0
! .IP "\fB\-gno\-internal\-reset\-location\-views\fR" 4
  .IX Item "-gno-internal-reset-location-views"
  .PD
  Attempt to determine location views that can be omitted from location
  view lists.  This requires the compiler to have very accurate insn
! length estimates, which isn't always the case, and it may cause
  incorrect view lists to be generated silently when using an assembler
! that does not support location view lists.  The \s-1GNU\s0 assembler will flag
  any such error as a \f(CW\*(C`view number mismatch\*(C'\fR.  This is only enabled
  on ports that define a reliable estimation function.
! .IP "\fB\-ginline\-points\fR" 4
  .IX Item "-ginline-points"
  .PD 0
! .IP "\fB\-gno\-inline\-points\fR" 4
  .IX Item "-gno-inline-points"
  .PD
  Generate extended debug information for inlined functions.  Location
  view tracking markers are inserted at inlined entry points, so that
  address and view numbers can be computed and output in debug
  information.  This can be enabled independently of location views, in
! which case the view numbers won't be output, but it can only be enabled
  along with statement frontiers, and it is only enabled by default if
  location views are enabled.
! .IP "\fB\-gz\fR[\fB=\fR\fItype\fR]" 4
  .IX Item "-gz[=type]"
! Produce compressed debug sections in \s-1DWARF\s0 format, if that is supported.
  If \fItype\fR is not given, the default type depends on the capabilities
  of the assembler and linker used.  \fItype\fR may be one of
! \&\fBnone\fR (don't compress debug sections), or \fBzlib\fR (use zlib
! compression in \s-1ELF\s0 gABI format).  If the linker doesn't support writing
  compressed debug sections, the option is rejected.  Otherwise, if the
  assembler does not support them, \fB\-gz\fR is silently ignored when
  producing object files.
! .IP "\fB\-femit\-struct\-debug\-baseonly\fR" 4
  .IX Item "-femit-struct-debug-baseonly"
! Emit debug information for struct-like types
  only when the base name of the compilation source file
  matches the base name of file in which the struct is defined.
  .Sp
--- 10759,10823 ----
  point.  If the assembler lacks support for view numbers in line number
  tables, this will cause the compiler to emit the line number table,
  which generally makes them somewhat less compact.  The augmented line
! number tables and location lists are fully backward\-compatible, so they
  can be consumed by debug information consumers that are not aware of
! these augmentations, but they won\*(Aqt derive any benefit from them either.
  .Sp
! This is enabled by default when outputting DWARF 2 debug information at
  the normal level, as long as there is assembler support,
  \&\fB\-fvar\-tracking\-assignments\fR is enabled and
  \&\fB\-gstrict\-dwarf\fR is not.  When assembler support is not
! available, this may still be enabled, but it will force GCC to output
  internal line number tables, and if
  \&\fB\-ginternal\-reset\-location\-views\fR is not enabled, that will most
  certainly lead to silently mismatching location views.
  .Sp
  There is a proposed representation for view numbers that is not backward
! compatible with the location list format introduced in DWARF 5, that can
  be enabled with \fB\-gvariable\-location\-views=incompat5\fR.  This
  option may be removed in the future, is only provided as a reference
  implementation of the proposed representation.  Debug information
  consumers are not expected to support this extended format, and they
  would be rendered unable to decode location lists using it.
! .IP \fB\-ginternal\-reset\-location\-views\fR 4
  .IX Item "-ginternal-reset-location-views"
  .PD 0
! .IP \fB\-gno\-internal\-reset\-location\-views\fR 4
  .IX Item "-gno-internal-reset-location-views"
  .PD
  Attempt to determine location views that can be omitted from location
  view lists.  This requires the compiler to have very accurate insn
! length estimates, which isn\*(Aqt always the case, and it may cause
  incorrect view lists to be generated silently when using an assembler
! that does not support location view lists.  The GNU assembler will flag
  any such error as a \f(CW\*(C`view number mismatch\*(C'\fR.  This is only enabled
  on ports that define a reliable estimation function.
! .IP \fB\-ginline\-points\fR 4
  .IX Item "-ginline-points"
  .PD 0
! .IP \fB\-gno\-inline\-points\fR 4
  .IX Item "-gno-inline-points"
  .PD
  Generate extended debug information for inlined functions.  Location
  view tracking markers are inserted at inlined entry points, so that
  address and view numbers can be computed and output in debug
  information.  This can be enabled independently of location views, in
! which case the view numbers won\*(Aqt be output, but it can only be enabled
  along with statement frontiers, and it is only enabled by default if
  location views are enabled.
! .IP \fB\-gz\fR[\fB=\fR\fItype\fR] 4
  .IX Item "-gz[=type]"
! Produce compressed debug sections in DWARF format, if that is supported.
  If \fItype\fR is not given, the default type depends on the capabilities
  of the assembler and linker used.  \fItype\fR may be one of
! \&\fBnone\fR (don\*(Aqt compress debug sections), or \fBzlib\fR (use zlib
! compression in ELF gABI format).  If the linker doesn\*(Aqt support writing
  compressed debug sections, the option is rejected.  Otherwise, if the
  assembler does not support them, \fB\-gz\fR is silently ignored when
  producing object files.
! .IP \fB\-femit\-struct\-debug\-baseonly\fR 4
  .IX Item "-femit-struct-debug-baseonly"
! Emit debug information for struct\-like types
  only when the base name of the compilation source file
  matches the base name of file in which the struct is defined.
  .Sp
*************** but at significant potential loss in typ
*** 10897,10906 ****
  See \fB\-femit\-struct\-debug\-reduced\fR for a less aggressive option.
  See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
  .Sp
! This option works only with \s-1DWARF\s0 debug output.
! .IP "\fB\-femit\-struct\-debug\-reduced\fR" 4
  .IX Item "-femit-struct-debug-reduced"
! Emit debug information for struct-like types
  only when the base name of the compilation source file
  matches the base name of file in which the type is defined,
  unless the struct is a template or defined in a system header.
--- 10826,10835 ----
  See \fB\-femit\-struct\-debug\-reduced\fR for a less aggressive option.
  See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
  .Sp
! This option works only with DWARF debug output.
! .IP \fB\-femit\-struct\-debug\-reduced\fR 4
  .IX Item "-femit-struct-debug-reduced"
! Emit debug information for struct\-like types
  only when the base name of the compilation source file
  matches the base name of file in which the type is defined,
  unless the struct is a template or defined in a system header.
*************** with some potential loss in type informa
*** 10910,10919 ****
  See \fB\-femit\-struct\-debug\-baseonly\fR for a more aggressive option.
  See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
  .Sp
! This option works only with \s-1DWARF\s0 debug output.
! .IP "\fB\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR]" 4
  .IX Item "-femit-struct-debug-detailed[=spec-list]"
! Specify the struct-like types
  for which the compiler generates debug information.
  The intent is to reduce duplicate struct debug information
  between different object files within the same program.
--- 10839,10848 ----
  See \fB\-femit\-struct\-debug\-baseonly\fR for a more aggressive option.
  See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
  .Sp
! This option works only with DWARF debug output.
! .IP \fB\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec\-list\fR] 4
  .IX Item "-femit-struct-debug-detailed[=spec-list]"
! Specify the struct\-like types
  for which the compiler generates debug information.
  The intent is to reduce duplicate struct debug information
  between different object files within the same program.
*************** An example is
*** 10935,10942 ****
  The optional second word limits the specification to
  ordinary structs (\fBord:\fR) or generic structs (\fBgen:\fR).
  Generic structs are a bit complicated to explain.
! For \*(C+, these are non-explicit specializations of template classes,
! or non-template classes within the above.
  Other programming languages have generics,
  but \fB\-femit\-struct\-debug\-detailed\fR does not yet implement them.
  .Sp
--- 10864,10871 ----
  The optional second word limits the specification to
  ordinary structs (\fBord:\fR) or generic structs (\fBgen:\fR).
  Generic structs are a bit complicated to explain.
! For C++, these are non\-explicit specializations of template classes,
! or non\-template classes within the above.
  Other programming languages have generics,
  but \fB\-femit\-struct\-debug\-detailed\fR does not yet implement them.
  .Sp
*************** You may need to experiment to determine
*** 10956,10971 ****
  .Sp
  The default is \fB\-femit\-struct\-debug\-detailed=all\fR.
  .Sp
! This option works only with \s-1DWARF\s0 debug output.
! .IP "\fB\-fno\-dwarf2\-cfi\-asm\fR" 4
  .IX Item "-fno-dwarf2-cfi-asm"
! Emit \s-1DWARF\s0 unwind info as compiler generated \f(CW\*(C`.eh_frame\*(C'\fR section
! instead of using \s-1GAS\s0 \f(CW\*(C`.cfi_*\*(C'\fR directives.
! .IP "\fB\-fno\-eliminate\-unused\-debug\-types\fR" 4
  .IX Item "-fno-eliminate-unused-debug-types"
! Normally, when producing \s-1DWARF\s0 output, \s-1GCC\s0 avoids producing debug symbol 
  output for types that are nowhere used in the source file being compiled.
! Sometimes it is useful to have \s-1GCC\s0 emit debugging
  information for all types declared in a compilation
  unit, regardless of whether or not they are actually used
  in that compilation unit, for example 
--- 10885,10900 ----
  .Sp
  The default is \fB\-femit\-struct\-debug\-detailed=all\fR.
  .Sp
! This option works only with DWARF debug output.
! .IP \fB\-fno\-dwarf2\-cfi\-asm\fR 4
  .IX Item "-fno-dwarf2-cfi-asm"
! Emit DWARF unwind info as compiler generated \f(CW\*(C`.eh_frame\*(C'\fR section
! instead of using GAS \f(CW\*(C`.cfi_*\*(C'\fR directives.
! .IP \fB\-fno\-eliminate\-unused\-debug\-types\fR 4
  .IX Item "-fno-eliminate-unused-debug-types"
! Normally, when producing DWARF output, GCC avoids producing debug symbol 
  output for types that are nowhere used in the source file being compiled.
! Sometimes it is useful to have GCC emit debugging
  information for all types declared in a compilation
  unit, regardless of whether or not they are actually used
  in that compilation unit, for example 
*************** however, this results in a significant a
*** 10976,10982 ****
  .IX Subsection "Options That Control Optimization"
  These options control various sorts of optimizations.
  .PP
! Without any optimization option, the compiler's goal is to reduce the
  cost of compilation and to make debugging produce the expected
  results.  Statements are independent: if you stop the program with a
  breakpoint between statements, you can then assign a new value to any
--- 10905,10911 ----
  .IX Subsection "Options That Control Optimization"
  These options control various sorts of optimizations.
  .PP
! Without any optimization option, the compiler\*(Aqs 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
*************** Most optimizations are completely disabl
*** 11001,11014 ****
  optimization flags are specified.  Similarly, \fB\-Og\fR suppresses
  many optimization passes.
  .PP
! Depending on the target and how \s-1GCC\s0 was configured, a slightly different
  set of optimizations may be enabled at each \fB\-O\fR level than
! those listed here.  You can invoke \s-1GCC\s0 with \fB\-Q \-\-help=optimizers\fR
  to find out the exact set of optimizations that are enabled at each level.
! .IP "\fB\-O\fR" 4
  .IX Item "-O"
  .PD 0
! .IP "\fB\-O1\fR" 4
  .IX Item "-O1"
  .PD
  Optimize.  Optimizing compilation takes somewhat more time, and a lot
--- 10930,10943 ----
  optimization flags are specified.  Similarly, \fB\-Og\fR suppresses
  many optimization passes.
  .PP
! Depending on the target and how GCC was configured, a slightly different
  set of optimizations may be enabled at each \fB\-O\fR level than
! those listed here.  You can invoke GCC with \fB\-Q \-\-help=optimizers\fR
  to find out the exact set of optimizations that are enabled at each level.
! .IP \fB\-O\fR 4
  .IX Item "-O"
  .PD 0
! .IP \fB\-O1\fR 4
  .IX Item "-O1"
  .PD
  Optimize.  Optimizing compilation takes somewhat more time, and a lot
*************** compilation time.
*** 11067,11076 ****
  \&\-ftree\-sra
  \&\-ftree\-ter
  \&\-funit\-at\-a\-time\fR
! .IP "\fB\-O2\fR" 4
  .IX Item "-O2"
! Optimize even more.  \s-1GCC\s0 performs nearly all supported optimizations
! that do not involve a space-speed tradeoff.
  As compared to \fB\-O\fR, this option increases both compilation time
  and the performance of the generated code.
  .Sp
--- 10996,11005 ----
  \&\-ftree\-sra
  \&\-ftree\-ter
  \&\-funit\-at\-a\-time\fR
! .IP \fB\-O2\fR 4
  .IX Item "-O2"
! Optimize even more.  GCC performs nearly all supported optimizations
! that do not involve a space\-speed tradeoff.
  As compared to \fB\-O\fR, this option increases both compilation time
  and the performance of the generated code.
  .Sp
*************** also turns on the following optimization
*** 11118,11124 ****
  .Sp
  Please note the warning under \fB\-fgcse\fR about
  invoking \fB\-O2\fR on programs that use computed gotos.
! .IP "\fB\-O3\fR" 4
  .IX Item "-O3"
  Optimize yet more.  \fB\-O3\fR turns on all optimizations specified
  by \fB\-O2\fR and also turns on the following optimization flags:
--- 11047,11053 ----
  .Sp
  Please note the warning under \fB\-fgcse\fR about
  invoking \fB\-O2\fR on programs that use computed gotos.
! .IP \fB\-O3\fR 4
  .IX Item "-O3"
  Optimize yet more.  \fB\-O3\fR turns on all optimizations specified
  by \fB\-O2\fR and also turns on the following optimization flags:
*************** by \fB\-O2\fR and also turns on the foll
*** 11136,11146 ****
  \&\-funswitch\-loops
  \&\-fvect\-cost\-model=dynamic
  \&\-fversion\-loops\-for\-strides\fR
! .IP "\fB\-O0\fR" 4
  .IX Item "-O0"
  Reduce compilation time and make debugging produce the expected
  results.  This is the default.
! .IP "\fB\-Os\fR" 4
  .IX Item "-Os"
  Optimize for size.  \fB\-Os\fR enables all \fB\-O2\fR optimizations 
  except those that often increase code size:
--- 11065,11075 ----
  \&\-funswitch\-loops
  \&\-fvect\-cost\-model=dynamic
  \&\-fversion\-loops\-for\-strides\fR
! .IP \fB\-O0\fR 4
  .IX Item "-O0"
  Reduce compilation time and make debugging produce the expected
  results.  This is the default.
! .IP \fB\-Os\fR 4
  .IX Item "-Os"
  Optimize for size.  \fB\-Os\fR enables all \fB\-O2\fR optimizations 
  except those that often increase code size:
*************** except those that often increase code si
*** 11152,11170 ****
  It also enables \fB\-finline\-functions\fR, causes the compiler to tune for
  code size rather than execution speed, and performs further optimizations
  designed to reduce code size.
! .IP "\fB\-Ofast\fR" 4
  .IX Item "-Ofast"
  Disregard strict standards compliance.  \fB\-Ofast\fR enables all
  \&\fB\-O3\fR optimizations.  It also enables optimizations that are not
! valid for all standard-compliant programs.
  It turns on \fB\-ffast\-math\fR, \fB\-fallow\-store\-data\-races\fR
! and the Fortran-specific \fB\-fstack\-arrays\fR, unless
  \&\fB\-fmax\-stack\-var\-size\fR is specified, and \fB\-fno\-protect\-parens\fR.
  It turns off \fB\-fsemantic\-interposition\fR.
! .IP "\fB\-Og\fR" 4
  .IX Item "-Og"
  Optimize debugging experience.  \fB\-Og\fR should be the optimization
! level of choice for the standard edit-compile-debug cycle, offering
  a reasonable level of optimization while maintaining fast compilation
  and a good debugging experience.  It is a better choice than \fB\-O0\fR
  for producing debuggable code because some compiler passes
--- 11081,11099 ----
  It also enables \fB\-finline\-functions\fR, causes the compiler to tune for
  code size rather than execution speed, and performs further optimizations
  designed to reduce code size.
! .IP \fB\-Ofast\fR 4
  .IX Item "-Ofast"
  Disregard strict standards compliance.  \fB\-Ofast\fR enables all
  \&\fB\-O3\fR optimizations.  It also enables optimizations that are not
! valid for all standard\-compliant programs.
  It turns on \fB\-ffast\-math\fR, \fB\-fallow\-store\-data\-races\fR
! and the Fortran\-specific \fB\-fstack\-arrays\fR, unless
  \&\fB\-fmax\-stack\-var\-size\fR is specified, and \fB\-fno\-protect\-parens\fR.
  It turns off \fB\-fsemantic\-interposition\fR.
! .IP \fB\-Og\fR 4
  .IX Item "-Og"
  Optimize debugging experience.  \fB\-Og\fR should be the optimization
! level of choice for the standard edit\-compile\-debug cycle, offering
  a reasonable level of optimization while maintaining fast compilation
  and a good debugging experience.  It is a better choice than \fB\-O0\fR
  for producing debuggable code because some compiler passes
*************** optimization flags except for those that
*** 11180,11186 ****
  \&\-finline\-functions\-called\-once
  \&\-fmove\-loop\-invariants  \-fmove\-loop\-stores  \-fssa\-phiopt
  \&\-ftree\-bit\-ccp  \-ftree\-dse  \-ftree\-pta  \-ftree\-sra\fR
! .IP "\fB\-Oz\fR" 4
  .IX Item "-Oz"
  Optimize aggressively for size rather than speed.  This may increase
  the number of instructions executed if those instructions require
--- 11109,11115 ----
  \&\-finline\-functions\-called\-once
  \&\-fmove\-loop\-invariants  \-fmove\-loop\-stores  \-fssa\-phiopt
  \&\-ftree\-bit\-ccp  \-ftree\-dse  \-ftree\-pta  \-ftree\-sra\fR
! .IP \fB\-Oz\fR 4
  .IX Item "-Oz"
  Optimize aggressively for size rather than speed.  This may increase
  the number of instructions executed if those instructions require
*************** including enabling most \fB\-O2\fR optim
*** 11190,11196 ****
  If you use multiple \fB\-O\fR options, with or without level numbers,
  the last such option is the one that is effective.
  .PP
! Options of the form \fB\-f\fR\fIflag\fR specify machine-independent
  flags.  Most flags have both positive and negative forms; the negative
  form of \fB\-ffoo\fR is \fB\-fno\-foo\fR.  In the table
  below, only one of the forms is listed\-\-\-the one you typically 
--- 11119,11125 ----
  If you use multiple \fB\-O\fR options, with or without level numbers,
  the last such option is the one that is effective.
  .PP
! Options of the form \fB\-f\fR\fIflag\fR specify machine\-independent
  flags.  Most flags have both positive and negative forms; the negative
  form of \fB\-ffoo\fR is \fB\-fno\-foo\fR.  In the table
  below, only one of the forms is listed\-\-\-the one you typically 
*************** or adding it.
*** 11199,11260 ****
  .PP
  The following options control specific optimizations.  They are either
  activated by \fB\-O\fR options or are related to ones that are.  You
! can use the following flags in the rare cases when \*(L"fine-tuning\*(R" of
  optimizations to be performed is desired.
! .IP "\fB\-fno\-defer\-pop\fR" 4
  .IX Item "-fno-defer-pop"
  For machines that must pop arguments after a function call, always pop 
  the arguments as soon as each function returns.  
  At levels \fB\-O1\fR and higher, \fB\-fdefer\-pop\fR is the default;
  this allows the compiler to let arguments accumulate on the stack for several
  function calls and pop them all at once.
! .IP "\fB\-fforward\-propagate\fR" 4
  .IX Item "-fforward-propagate"
! Perform a forward propagation pass on \s-1RTL.\s0  The pass tries to combine two
  instructions and checks if the result can be simplified.  If loop unrolling
  is active, two passes are performed and the second is scheduled after
  loop unrolling.
  .Sp
  This option is enabled by default at optimization levels \fB\-O1\fR,
  \&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-ffp\-contract=\fR\fIstyle\fR" 4
  .IX Item "-ffp-contract=style"
! \&\fB\-ffp\-contract=off\fR disables floating-point expression contraction.
! \&\fB\-ffp\-contract=fast\fR enables floating-point expression contraction
! such as forming of fused multiply-add operations if the target has
  native support for them.
! \&\fB\-ffp\-contract=on\fR enables floating-point expression contraction
  if allowed by the language standard.  This is currently not implemented
  and treated equal to \fB\-ffp\-contract=off\fR.
  .Sp
  The default is \fB\-ffp\-contract=fast\fR.
! .IP "\fB\-fomit\-frame\-pointer\fR" 4
  .IX Item "-fomit-frame-pointer"
! Omit the frame pointer in functions that don't need one.  This avoids the
  instructions to save, set up and restore the frame pointer; on many targets
  it also makes an extra register available.
  .Sp
  On some targets this flag has no effect because the standard calling sequence
  always uses a frame pointer, so it cannot be omitted.
  .Sp
! Note that \fB\-fno\-omit\-frame\-pointer\fR doesn't guarantee the frame pointer
  is used in all functions.  Several targets always omit the frame pointer in
  leaf functions.
  .Sp
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-foptimize\-sibling\-calls\fR" 4
  .IX Item "-foptimize-sibling-calls"
  Optimize sibling and tail recursive calls.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-foptimize\-strlen\fR" 4
  .IX Item "-foptimize-strlen"
  Optimize various standard C string functions (e.g. \f(CW\*(C`strlen\*(C'\fR,
  \&\f(CW\*(C`strchr\*(C'\fR or \f(CW\*(C`strcpy\*(C'\fR) and
  their \f(CW\*(C`_FORTIFY_SOURCE\*(C'\fR counterparts into faster alternatives.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-fno\-inline\fR" 4
  .IX Item "-fno-inline"
  Do not expand any functions inline apart from those marked with
  the \f(CW\*(C`always_inline\*(C'\fR attribute.  This is the default when not
--- 11128,11189 ----
  .PP
  The following options control specific optimizations.  They are either
  activated by \fB\-O\fR options or are related to ones that are.  You
! can use the following flags in the rare cases when "fine\-tuning" of
  optimizations to be performed is desired.
! .IP \fB\-fno\-defer\-pop\fR 4
  .IX Item "-fno-defer-pop"
  For machines that must pop arguments after a function call, always pop 
  the arguments as soon as each function returns.  
  At levels \fB\-O1\fR and higher, \fB\-fdefer\-pop\fR is the default;
  this allows the compiler to let arguments accumulate on the stack for several
  function calls and pop them all at once.
! .IP \fB\-fforward\-propagate\fR 4
  .IX Item "-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.
  .Sp
  This option is enabled by default at optimization levels \fB\-O1\fR,
  \&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-ffp\-contract=\fR\fIstyle\fR 4
  .IX Item "-ffp-contract=style"
! \&\fB\-ffp\-contract=off\fR disables floating\-point expression contraction.
! \&\fB\-ffp\-contract=fast\fR enables floating\-point expression contraction
! such as forming of fused multiply\-add operations if the target has
  native support for them.
! \&\fB\-ffp\-contract=on\fR enables floating\-point expression contraction
  if allowed by the language standard.  This is currently not implemented
  and treated equal to \fB\-ffp\-contract=off\fR.
  .Sp
  The default is \fB\-ffp\-contract=fast\fR.
! .IP \fB\-fomit\-frame\-pointer\fR 4
  .IX Item "-fomit-frame-pointer"
! Omit the frame pointer in functions that don\*(Aqt need one.  This avoids the
  instructions to save, set up and restore the frame pointer; on many targets
  it also makes an extra register available.
  .Sp
  On some targets this flag has no effect because the standard calling sequence
  always uses a frame pointer, so it cannot be omitted.
  .Sp
! Note that \fB\-fno\-omit\-frame\-pointer\fR doesn\*(Aqt guarantee the frame pointer
  is used in all functions.  Several targets always omit the frame pointer in
  leaf functions.
  .Sp
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-foptimize\-sibling\-calls\fR 4
  .IX Item "-foptimize-sibling-calls"
  Optimize sibling and tail recursive calls.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-foptimize\-strlen\fR 4
  .IX Item "-foptimize-strlen"
  Optimize various standard C string functions (e.g. \f(CW\*(C`strlen\*(C'\fR,
  \&\f(CW\*(C`strchr\*(C'\fR or \f(CW\*(C`strcpy\*(C'\fR) and
  their \f(CW\*(C`_FORTIFY_SOURCE\*(C'\fR counterparts into faster alternatives.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-fno\-inline\fR 4
  .IX Item "-fno-inline"
  Do not expand any functions inline apart from those marked with
  the \f(CW\*(C`always_inline\*(C'\fR attribute.  This is the default when not
*************** optimizing.
*** 11262,11268 ****
  .Sp
  Single functions can be exempted from inlining by marking them
  with the \f(CW\*(C`noinline\*(C'\fR attribute.
! .IP "\fB\-finline\-small\-functions\fR" 4
  .IX Item "-finline-small-functions"
  Integrate functions into their callers when their body is smaller than expected
  function call code (so overall size of program gets smaller).  The compiler
--- 11191,11197 ----
  .Sp
  Single functions can be exempted from inlining by marking them
  with the \f(CW\*(C`noinline\*(C'\fR attribute.
! .IP \fB\-finline\-small\-functions\fR 4
  .IX Item "-finline-small-functions"
  Integrate functions into their callers when their body is smaller than expected
  function call code (so overall size of program gets smaller).  The compiler
*************** in this way.  This inlining applies to a
*** 11271,11277 ****
  inline.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-findirect\-inlining\fR" 4
  .IX Item "-findirect-inlining"
  Inline also indirect calls that are discovered to be known at compile
  time thanks to previous inlining.  This option has any effect only
--- 11200,11206 ----
  inline.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-findirect\-inlining\fR 4
  .IX Item "-findirect-inlining"
  Inline also indirect calls that are discovered to be known at compile
  time thanks to previous inlining.  This option has any effect only
*************** when inlining itself is turned on by the
*** 11279,11285 ****
  or \fB\-finline\-small\-functions\fR options.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-finline\-functions\fR" 4
  .IX Item "-finline-functions"
  Consider all functions for inlining, even if they are not declared inline.
  The compiler heuristically decides which functions are worth integrating
--- 11208,11214 ----
  or \fB\-finline\-small\-functions\fR options.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-finline\-functions\fR 4
  .IX Item "-finline-functions"
  Consider all functions for inlining, even if they are not declared inline.
  The compiler heuristically decides which functions are worth integrating
*************** assembler code in its own right.
*** 11291,11297 ****
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.  Also enabled
  by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-finline\-functions\-called\-once\fR" 4
  .IX Item "-finline-functions-called-once"
  Consider all \f(CW\*(C`static\*(C'\fR functions called once for inlining into their
  caller even if they are not marked \f(CW\*(C`inline\*(C'\fR.  If a call to a given
--- 11220,11226 ----
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.  Also enabled
  by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-finline\-functions\-called\-once\fR 4
  .IX Item "-finline-functions-called-once"
  Consider all \f(CW\*(C`static\*(C'\fR functions called once for inlining into their
  caller even if they are not marked \f(CW\*(C`inline\*(C'\fR.  If a call to a given
*************** in its own right.
*** 11300,11306 ****
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR,
  but not \fB\-Og\fR.
! .IP "\fB\-fearly\-inlining\fR" 4
  .IX Item "-fearly-inlining"
  Inline functions marked by \f(CW\*(C`always_inline\*(C'\fR and functions whose body seems
  smaller than the function call overhead early before doing
--- 11229,11235 ----
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR,
  but not \fB\-Og\fR.
! .IP \fB\-fearly\-inlining\fR 4
  .IX Item "-fearly-inlining"
  Inline functions marked by \f(CW\*(C`always_inline\*(C'\fR and functions whose body seems
  smaller than the function call overhead early before doing
*************** makes profiling significantly cheaper an
*** 11309,11324 ****
  having large chains of nested wrapper functions.
  .Sp
  Enabled by default.
! .IP "\fB\-fipa\-sra\fR" 4
  .IX Item "-fipa-sra"
  Perform interprocedural scalar replacement of aggregates, removal of
  unused parameters and replacement of parameters passed by reference
  by parameters passed by value.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
! .IP "\fB\-finline\-limit=\fR\fIn\fR" 4
  .IX Item "-finline-limit=n"
! By default, \s-1GCC\s0 limits the size of functions that can be inlined.  This flag
  allows coarse control of this limit.  \fIn\fR is the size of functions that
  can be inlined in number of pseudo instructions.
  .Sp
--- 11238,11253 ----
  having large chains of nested wrapper functions.
  .Sp
  Enabled by default.
! .IP \fB\-fipa\-sra\fR 4
  .IX Item "-fipa-sra"
  Perform interprocedural scalar replacement of aggregates, removal of
  unused parameters and replacement of parameters passed by reference
  by parameters passed by value.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
! .IP \fB\-finline\-limit=\fR\fIn\fR 4
  .IX Item "-finline-limit=n"
! By default, GCC limits the size of functions that can be inlined.  This flag
  allows coarse control of this limit.  \fIn\fR is the size of functions that
  can be inlined in number of pseudo instructions.
  .Sp
*************** specified individually by using \fB\-\-p
*** 11327,11336 ****
  The \fB\-finline\-limit=\fR\fIn\fR option sets some of these parameters
  as follows:
  .RS 4
! .IP "\fBmax-inline-insns-single\fR" 4
  .IX Item "max-inline-insns-single"
  is set to \fIn\fR/2.
! .IP "\fBmax-inline-insns-auto\fR" 4
  .IX Item "max-inline-insns-auto"
  is set to \fIn\fR/2.
  .RE
--- 11256,11265 ----
  The \fB\-finline\-limit=\fR\fIn\fR option sets some of these parameters
  as follows:
  .RS 4
! .IP \fBmax\-inline\-insns\-single\fR 4
  .IX Item "max-inline-insns-single"
  is set to \fIn\fR/2.
! .IP \fBmax\-inline\-insns\-auto\fR 4
  .IX Item "max-inline-insns-auto"
  is set to \fIn\fR/2.
  .RE
*************** parameters controlling inlining and for
*** 11343,11379 ****
  in default behavior.
  .Sp
  \&\fINote:\fR pseudo instruction represents, in this particular context, an
! abstract measurement of function's size.  In no way does it represent a count
  of assembly instructions and as such its exact meaning might change from one
  release to an another.
  .RE
! .IP "\fB\-fno\-keep\-inline\-dllexport\fR" 4
  .IX Item "-fno-keep-inline-dllexport"
! This is a more fine-grained version of \fB\-fkeep\-inline\-functions\fR,
  which applies only to functions that are declared using the \f(CW\*(C`dllexport\*(C'\fR
  attribute or declspec.
! .IP "\fB\-fkeep\-inline\-functions\fR" 4
  .IX Item "-fkeep-inline-functions"
  In C, emit \f(CW\*(C`static\*(C'\fR functions that are declared \f(CW\*(C`inline\*(C'\fR
  into the object file, even if the function has been inlined into all
  of its callers.  This switch does not affect functions using the
! \&\f(CW\*(C`extern inline\*(C'\fR extension in \s-1GNU C90.\s0  In \*(C+, emit any and all
  inline functions into the object file.
! .IP "\fB\-fkeep\-static\-functions\fR" 4
  .IX Item "-fkeep-static-functions"
  Emit \f(CW\*(C`static\*(C'\fR functions into the object file, even if the function
  is never used.
! .IP "\fB\-fkeep\-static\-consts\fR" 4
  .IX Item "-fkeep-static-consts"
! Emit variables declared \f(CW\*(C`static const\*(C'\fR when optimization isn't turned
! on, even if the variables aren't referenced.
  .Sp
! \&\s-1GCC\s0 enables this option by default.  If you want to force the compiler to
  check if a variable is referenced, regardless of whether or not
  optimization is turned on, use the \fB\-fno\-keep\-static\-consts\fR option.
! .IP "\fB\-fmerge\-constants\fR" 4
  .IX Item "-fmerge-constants"
! Attempt to merge identical constants (string constants and floating-point
  constants) across compilation units.
  .Sp
  This option is the default for optimized compilation if the assembler and
--- 11272,11308 ----
  in default behavior.
  .Sp
  \&\fINote:\fR pseudo instruction represents, in this particular context, an
! abstract measurement of function\*(Aqs size.  In no way does it represent a count
  of assembly instructions and as such its exact meaning might change from one
  release to an another.
  .RE
! .IP \fB\-fno\-keep\-inline\-dllexport\fR 4
  .IX Item "-fno-keep-inline-dllexport"
! This is a more fine\-grained version of \fB\-fkeep\-inline\-functions\fR,
  which applies only to functions that are declared using the \f(CW\*(C`dllexport\*(C'\fR
  attribute or declspec.
! .IP \fB\-fkeep\-inline\-functions\fR 4
  .IX Item "-fkeep-inline-functions"
  In C, emit \f(CW\*(C`static\*(C'\fR functions that are declared \f(CW\*(C`inline\*(C'\fR
  into the object file, even if the function has been inlined into all
  of its callers.  This switch does not affect functions using the
! \&\f(CW\*(C`extern inline\*(C'\fR extension in GNU C90.  In C++, emit any and all
  inline functions into the object file.
! .IP \fB\-fkeep\-static\-functions\fR 4
  .IX Item "-fkeep-static-functions"
  Emit \f(CW\*(C`static\*(C'\fR functions into the object file, even if the function
  is never used.
! .IP \fB\-fkeep\-static\-consts\fR 4
  .IX Item "-fkeep-static-consts"
! Emit variables declared \f(CW\*(C`static const\*(C'\fR when optimization isn\*(Aqt turned
! on, even if the variables aren\*(Aqt referenced.
  .Sp
! GCC enables this option by default.  If you want to force the compiler to
  check if a variable is referenced, regardless of whether or not
  optimization is turned on, use the \fB\-fno\-keep\-static\-consts\fR option.
! .IP \fB\-fmerge\-constants\fR 4
  .IX Item "-fmerge-constants"
! Attempt to merge identical constants (string constants and floating\-point
  constants) across compilation units.
  .Sp
  This option is the default for optimized compilation if the assembler and
*************** linker support it.  Use \fB\-fno\-merge\
*** 11381,11436 ****
  behavior.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fmerge\-all\-constants\fR" 4
  .IX Item "-fmerge-all-constants"
  Attempt to merge identical constants and identical variables.
  .Sp
  This option implies \fB\-fmerge\-constants\fR.  In addition to
  \&\fB\-fmerge\-constants\fR this considers e.g. even constant initialized
! arrays or initialized constant variables with integral or floating-point
! types.  Languages like C or \*(C+ require each variable, including multiple
  instances of the same variable in recursive calls, to have distinct locations,
! so using this option results in non-conforming
  behavior.
! .IP "\fB\-fmodulo\-sched\fR" 4
  .IX Item "-fmodulo-sched"
  Perform swing modulo scheduling immediately before the first scheduling
  pass.  This pass looks at innermost loops and reorders their
  instructions by overlapping different iterations.
! .IP "\fB\-fmodulo\-sched\-allow\-regmoves\fR" 4
  .IX Item "-fmodulo-sched-allow-regmoves"
! Perform more aggressive SMS-based modulo scheduling with register moves
! allowed.  By setting this flag certain anti-dependences edges are
! deleted, which triggers the generation of reg-moves based on the
! life-range analysis.  This option is effective only with
  \&\fB\-fmodulo\-sched\fR enabled.
! .IP "\fB\-fno\-branch\-count\-reg\fR" 4
  .IX Item "-fno-branch-count-reg"
  Disable the optimization pass that scans for opportunities to use 
! \&\*(L"decrement and branch\*(R" instructions on a count register instead of
  instruction sequences that decrement a register, compare it against zero, and
  then branch based upon the result.  This option is only meaningful on
  architectures that support such instructions, which include x86, PowerPC,
! \&\s-1IA\-64\s0 and S/390.  Note that the \fB\-fno\-branch\-count\-reg\fR option
! doesn't remove the decrement and branch instructions from the generated
  instruction stream introduced by other optimization passes.
  .Sp
  The default is \fB\-fbranch\-count\-reg\fR at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP "\fB\-fno\-function\-cse\fR" 4
  .IX Item "-fno-function-cse"
  Do not put function addresses in registers; make each instruction that
! calls a constant function contain the function's address explicitly.
  .Sp
  This option results in less efficient code, but some strange hacks
  that alter the assembler output may be confused by the optimizations
  performed when this option is not used.
  .Sp
  The default is \fB\-ffunction\-cse\fR
! .IP "\fB\-fno\-zero\-initialized\-in\-bss\fR" 4
  .IX Item "-fno-zero-initialized-in-bss"
! If the target supports a \s-1BSS\s0 section, \s-1GCC\s0 by default puts variables that
! are initialized to zero into \s-1BSS.\s0  This can save space in the resulting
  code.
  .Sp
  This option turns off this behavior because some programs explicitly
--- 11310,11365 ----
  behavior.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fmerge\-all\-constants\fR 4
  .IX Item "-fmerge-all-constants"
  Attempt to merge identical constants and identical variables.
  .Sp
  This option implies \fB\-fmerge\-constants\fR.  In addition to
  \&\fB\-fmerge\-constants\fR this considers e.g. even constant initialized
! arrays or initialized constant variables with integral or floating\-point
! types.  Languages like C or C++ require each variable, including multiple
  instances of the same variable in recursive calls, to have distinct locations,
! so using this option results in non\-conforming
  behavior.
! .IP \fB\-fmodulo\-sched\fR 4
  .IX Item "-fmodulo-sched"
  Perform swing modulo scheduling immediately before the first scheduling
  pass.  This pass looks at innermost loops and reorders their
  instructions by overlapping different iterations.
! .IP \fB\-fmodulo\-sched\-allow\-regmoves\fR 4
  .IX Item "-fmodulo-sched-allow-regmoves"
! Perform more aggressive SMS\-based modulo scheduling with register moves
! allowed.  By setting this flag certain anti\-dependences edges are
! deleted, which triggers the generation of reg\-moves based on the
! life\-range analysis.  This option is effective only with
  \&\fB\-fmodulo\-sched\fR enabled.
! .IP \fB\-fno\-branch\-count\-reg\fR 4
  .IX Item "-fno-branch-count-reg"
  Disable the optimization pass that scans for opportunities to use 
! "decrement and branch" instructions on a count register instead of
  instruction sequences that decrement a register, compare it against zero, and
  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.  Note that the \fB\-fno\-branch\-count\-reg\fR option
! doesn\*(Aqt remove the decrement and branch instructions from the generated
  instruction stream introduced by other optimization passes.
  .Sp
  The default is \fB\-fbranch\-count\-reg\fR at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP \fB\-fno\-function\-cse\fR 4
  .IX Item "-fno-function-cse"
  Do not put function addresses in registers; make each instruction that
! calls a constant function contain the function\*(Aqs address explicitly.
  .Sp
  This option results in less efficient code, but some strange hacks
  that alter the assembler output may be confused by the optimizations
  performed when this option is not used.
  .Sp
  The default is \fB\-ffunction\-cse\fR
! .IP \fB\-fno\-zero\-initialized\-in\-bss\fR 4
  .IX Item "-fno-zero-initialized-in-bss"
! If the target supports a BSS section, GCC by default puts variables that
! are initialized to zero into BSS.  This can save space in the resulting
  code.
  .Sp
  This option turns off this behavior because some programs explicitly
*************** resulting executable can find the beginn
*** 11439,11445 ****
  assumptions based on that.
  .Sp
  The default is \fB\-fzero\-initialized\-in\-bss\fR.
! .IP "\fB\-fthread\-jumps\fR" 4
  .IX Item "-fthread-jumps"
  Perform optimizations that check to see if a jump branches to a
  location where another comparison subsumed by the first is found.  If
--- 11368,11374 ----
  assumptions based on that.
  .Sp
  The default is \fB\-fzero\-initialized\-in\-bss\fR.
! .IP \fB\-fthread\-jumps\fR 4
  .IX Item "-fthread-jumps"
  Perform optimizations that check to see if a jump branches to a
  location where another comparison subsumed by the first is found.  If
*************** second branch or a point immediately fol
*** 11448,11454 ****
  the condition is known to be true or false.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fsplit\-wide\-types\fR" 4
  .IX Item "-fsplit-wide-types"
  When using a type that occupies multiple registers, such as \f(CW\*(C`long
  long\*(C'\fR on a 32\-bit system, split the registers apart and allocate them
--- 11377,11383 ----
  the condition is known to be true or false.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fsplit\-wide\-types\fR 4
  .IX Item "-fsplit-wide-types"
  When using a type that occupies multiple registers, such as \f(CW\*(C`long
  long\*(C'\fR on a 32\-bit system, split the registers apart and allocate them
*************** but may make debugging more difficult.
*** 11457,11504 ****
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR,
  \&\fB\-Os\fR.
! .IP "\fB\-fsplit\-wide\-types\-early\fR" 4
  .IX Item "-fsplit-wide-types-early"
  Fully split wide types early, instead of very late.
  This option has no effect unless \fB\-fsplit\-wide\-types\fR is turned on.
  .Sp
  This is the default on some targets.
! .IP "\fB\-fcse\-follow\-jumps\fR" 4
  .IX Item "-fcse-follow-jumps"
! In common subexpression elimination (\s-1CSE\s0), scan through jump instructions
  when the target of the jump is not reached by any other path.  For
! example, when \s-1CSE\s0 encounters an \f(CW\*(C`if\*(C'\fR statement with an
! \&\f(CW\*(C`else\*(C'\fR clause, \s-1CSE\s0 follows the jump when the condition
  tested is false.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fcse\-skip\-blocks\fR" 4
  .IX Item "-fcse-skip-blocks"
! This is similar to \fB\-fcse\-follow\-jumps\fR, but causes \s-1CSE\s0 to
! follow jumps that conditionally skip over blocks.  When \s-1CSE\s0
  encounters a simple \f(CW\*(C`if\*(C'\fR statement with no else clause,
! \&\fB\-fcse\-skip\-blocks\fR causes \s-1CSE\s0 to follow the jump around the
  body of the \f(CW\*(C`if\*(C'\fR.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-frerun\-cse\-after\-loop\fR" 4
  .IX Item "-frerun-cse-after-loop"
! Re-run common subexpression elimination after loop optimizations are
  performed.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fgcse\fR" 4
  .IX Item "-fgcse"
  Perform a global common subexpression elimination pass.
  This pass also performs global constant and copy propagation.
  .Sp
! \&\fINote:\fR When compiling a program using computed gotos, a \s-1GCC\s0
! extension, you may get better run-time performance if you disable
  the global common subexpression elimination pass by adding
  \&\fB\-fno\-gcse\fR to the command line.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fgcse\-lm\fR" 4
  .IX Item "-fgcse-lm"
  When \fB\-fgcse\-lm\fR is enabled, global common subexpression elimination
  attempts to move loads that are only killed by stores into themselves.  This
--- 11386,11433 ----
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR,
  \&\fB\-Os\fR.
! .IP \fB\-fsplit\-wide\-types\-early\fR 4
  .IX Item "-fsplit-wide-types-early"
  Fully split wide types early, instead of very late.
  This option has no effect unless \fB\-fsplit\-wide\-types\fR is turned on.
  .Sp
  This is the default on some targets.
! .IP \fB\-fcse\-follow\-jumps\fR 4
  .IX Item "-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 \f(CW\*(C`if\*(C'\fR statement with an
! \&\f(CW\*(C`else\*(C'\fR clause, CSE follows the jump when the condition
  tested is false.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fcse\-skip\-blocks\fR 4
  .IX Item "-fcse-skip-blocks"
! This is similar to \fB\-fcse\-follow\-jumps\fR, but causes CSE to
! follow jumps that conditionally skip over blocks.  When CSE
  encounters a simple \f(CW\*(C`if\*(C'\fR statement with no else clause,
! \&\fB\-fcse\-skip\-blocks\fR causes CSE to follow the jump around the
  body of the \f(CW\*(C`if\*(C'\fR.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-frerun\-cse\-after\-loop\fR 4
  .IX Item "-frerun-cse-after-loop"
! Re\-run common subexpression elimination after loop optimizations are
  performed.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fgcse\fR 4
  .IX Item "-fgcse"
  Perform a global common subexpression elimination pass.
  This pass also performs global constant and copy propagation.
  .Sp
! \&\fINote:\fR When compiling a program using computed gotos, a GCC
! extension, you may get better run\-time performance if you disable
  the global common subexpression elimination pass by adding
  \&\fB\-fno\-gcse\fR to the command line.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fgcse\-lm\fR 4
  .IX Item "-fgcse-lm"
  When \fB\-fgcse\-lm\fR is enabled, global common subexpression elimination
  attempts to move loads that are only killed by stores into themselves.  This
*************** allows a loop containing a load/store se
*** 11506,11512 ****
  the loop, and a copy/store within the loop.
  .Sp
  Enabled by default when \fB\-fgcse\fR is enabled.
! .IP "\fB\-fgcse\-sm\fR" 4
  .IX Item "-fgcse-sm"
  When \fB\-fgcse\-sm\fR is enabled, a store motion pass is run after
  global common subexpression elimination.  This pass attempts to move
--- 11435,11441 ----
  the loop, and a copy/store within the loop.
  .Sp
  Enabled by default when \fB\-fgcse\fR is enabled.
! .IP \fB\-fgcse\-sm\fR 4
  .IX Item "-fgcse-sm"
  When \fB\-fgcse\-sm\fR is enabled, a store motion pass is run after
  global common subexpression elimination.  This pass attempts to move
*************** loops containing a load/store sequence c
*** 11515,11588 ****
  the loop and a store after the loop.
  .Sp
  Not enabled at any optimization level.
! .IP "\fB\-fgcse\-las\fR" 4
  .IX Item "-fgcse-las"
  When \fB\-fgcse\-las\fR is enabled, the global common subexpression
  elimination pass eliminates redundant loads that come after stores to the
  same memory location (both partial and full redundancies).
  .Sp
  Not enabled at any optimization level.
! .IP "\fB\-fgcse\-after\-reload\fR" 4
  .IX Item "-fgcse-after-reload"
  When \fB\-fgcse\-after\-reload\fR is enabled, a redundant load elimination
  pass is performed after reload.  The purpose of this pass is to clean up
  redundant spilling.
  .Sp
  Enabled by \fB\-O3\fR, \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-faggressive\-loop\-optimizations\fR" 4
  .IX Item "-faggressive-loop-optimizations"
  This option tells the loop optimizer to use language constraints to
  derive bounds for the number of iterations of a loop.  This assumes that
  loop code does not invoke undefined behavior by for example causing signed
! integer overflows or out-of-bound array accesses.  The bounds for the
  number of iterations of a loop are used to guide loop unrolling and peeling
  and loop exit test optimizations.
  This option is enabled by default.
! .IP "\fB\-funconstrained\-commons\fR" 4
  .IX Item "-funconstrained-commons"
  This option tells the compiler that variables declared in common blocks
  (e.g. Fortran) may later be overridden with longer trailing arrays. This
  prevents certain optimizations that depend on knowing the array bounds.
! .IP "\fB\-fcrossjumping\fR" 4
  .IX Item "-fcrossjumping"
! Perform cross-jumping transformation.
  This transformation unifies equivalent code and saves code size.  The
! resulting code may or may not perform better than without cross-jumping.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fauto\-inc\-dec\fR" 4
  .IX Item "-fauto-inc-dec"
  Combine increments or decrements of addresses with memory accesses.
  This pass is always skipped on architectures that do not have
  instructions to support this.  Enabled by default at \fB\-O1\fR and
  higher on architectures that support this.
! .IP "\fB\-fdce\fR" 4
  .IX Item "-fdce"
! Perform dead code elimination (\s-1DCE\s0) on \s-1RTL.\s0
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fdse\fR" 4
  .IX Item "-fdse"
! Perform dead store elimination (\s-1DSE\s0) on \s-1RTL.\s0
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fif\-conversion\fR" 4
  .IX Item "-fif-conversion"
! Attempt to transform conditional jumps into branch-less equivalents.  This
  includes use of conditional moves, min, max, set flags and abs instructions, and
  some tricks doable by standard arithmetics.  The use of conditional execution
  on chips where it is available is controlled by \fB\-fif\-conversion2\fR.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, but
  not with \fB\-Og\fR.
! .IP "\fB\-fif\-conversion2\fR" 4
  .IX Item "-fif-conversion2"
  Use conditional execution (where available) to transform conditional jumps into
! branch-less equivalents.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, but
  not with \fB\-Og\fR.
! .IP "\fB\-fdeclone\-ctor\-dtor\fR" 4
  .IX Item "-fdeclone-ctor-dtor"
! The \*(C+ \s-1ABI\s0 requires multiple entry points for constructors and
  destructors: one for a base subobject, one for a complete object, and
  one for a virtual destructor that calls operator delete afterwards.
  For a hierarchy with virtual bases, the base and complete variants are
--- 11444,11517 ----
  the loop and a store after the loop.
  .Sp
  Not enabled at any optimization level.
! .IP \fB\-fgcse\-las\fR 4
  .IX Item "-fgcse-las"
  When \fB\-fgcse\-las\fR is enabled, the global common subexpression
  elimination pass eliminates redundant loads that come after stores to the
  same memory location (both partial and full redundancies).
  .Sp
  Not enabled at any optimization level.
! .IP \fB\-fgcse\-after\-reload\fR 4
  .IX Item "-fgcse-after-reload"
  When \fB\-fgcse\-after\-reload\fR is enabled, a redundant load elimination
  pass is performed after reload.  The purpose of this pass is to clean up
  redundant spilling.
  .Sp
  Enabled by \fB\-O3\fR, \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-faggressive\-loop\-optimizations\fR 4
  .IX Item "-faggressive-loop-optimizations"
  This option tells the loop optimizer to use language constraints to
  derive bounds for the number of iterations of a loop.  This assumes that
  loop code does not invoke undefined behavior by for example causing signed
! integer overflows or out\-of\-bound array accesses.  The bounds for the
  number of iterations of a loop are used to guide loop unrolling and peeling
  and loop exit test optimizations.
  This option is enabled by default.
! .IP \fB\-funconstrained\-commons\fR 4
  .IX Item "-funconstrained-commons"
  This option tells the compiler that variables declared in common blocks
  (e.g. Fortran) may later be overridden with longer trailing arrays. This
  prevents certain optimizations that depend on knowing the array bounds.
! .IP \fB\-fcrossjumping\fR 4
  .IX Item "-fcrossjumping"
! Perform cross\-jumping transformation.
  This transformation unifies equivalent code and saves code size.  The
! resulting code may or may not perform better than without cross\-jumping.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fauto\-inc\-dec\fR 4
  .IX Item "-fauto-inc-dec"
  Combine increments or decrements of addresses with memory accesses.
  This pass is always skipped on architectures that do not have
  instructions to support this.  Enabled by default at \fB\-O1\fR and
  higher on architectures that support this.
! .IP \fB\-fdce\fR 4
  .IX Item "-fdce"
! Perform dead code elimination (DCE) on RTL.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fdse\fR 4
  .IX Item "-fdse"
! Perform dead store elimination (DSE) on RTL.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fif\-conversion\fR 4
  .IX Item "-fif-conversion"
! Attempt to transform conditional jumps into branch\-less equivalents.  This
  includes use of conditional moves, min, max, set flags and abs instructions, and
  some tricks doable by standard arithmetics.  The use of conditional execution
  on chips where it is available is controlled by \fB\-fif\-conversion2\fR.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, but
  not with \fB\-Og\fR.
! .IP \fB\-fif\-conversion2\fR 4
  .IX Item "-fif-conversion2"
  Use conditional execution (where available) to transform conditional jumps into
! branch\-less equivalents.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, but
  not with \fB\-Og\fR.
! .IP \fB\-fdeclone\-ctor\-dtor\fR 4
  .IX Item "-fdeclone-ctor-dtor"
! The C++ ABI requires multiple entry points for constructors and
  destructors: one for a base subobject, one for a complete object, and
  one for a virtual destructor that calls operator delete afterwards.
  For a hierarchy with virtual bases, the base and complete variants are
*************** base and complete variants are changed t
*** 11591,11603 ****
  implementation.
  .Sp
  Enabled by \fB\-Os\fR.
! .IP "\fB\-fdelete\-null\-pointer\-checks\fR" 4
  .IX Item "-fdelete-null-pointer-checks"
  Assume that programs cannot safely dereference null pointers, and that
  no code or data element resides at address zero.
  This option enables simple constant
  folding optimizations at all optimization levels.  In addition, other
! optimization passes in \s-1GCC\s0 use this flag to control global dataflow
  analyses that eliminate useless checks for null pointers; these assume
  that a memory access to address zero always results in a trap, so
  that if a pointer is checked after it has already been dereferenced,
--- 11520,11532 ----
  implementation.
  .Sp
  Enabled by \fB\-Os\fR.
! .IP \fB\-fdelete\-null\-pointer\-checks\fR 4
  .IX Item "-fdelete-null-pointer-checks"
  Assume that programs cannot safely dereference null pointers, and that
  no code or data element resides at address zero.
  This option 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 a memory access to address zero always results in a trap, so
  that if a pointer is checked after it has already been dereferenced,
*************** Note however that in some environments t
*** 11607,11625 ****
  Use \fB\-fno\-delete\-null\-pointer\-checks\fR to disable this optimization
  for programs that depend on that behavior.
  .Sp
! This option is enabled by default on most targets.  On Nios \s-1II ELF,\s0 it
! defaults to off.  On \s-1AVR\s0 and \s-1MSP430,\s0 this option is completely disabled.
  .Sp
  Passes that use the dataflow information
  are enabled independently at different optimization levels.
! .IP "\fB\-fdevirtualize\fR" 4
  .IX Item "-fdevirtualize"
  Attempt to convert calls to virtual functions to direct calls.  This
  is done both within a procedure and interprocedurally as part of
  indirect inlining (\fB\-findirect\-inlining\fR) and interprocedural constant
  propagation (\fB\-fipa\-cp\fR).
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fdevirtualize\-speculatively\fR" 4
  .IX Item "-fdevirtualize-speculatively"
  Attempt to convert calls to virtual functions to speculative direct calls.
  Based on the analysis of the type inheritance graph, determine for a given call
--- 11536,11554 ----
  Use \fB\-fno\-delete\-null\-pointer\-checks\fR to disable this optimization
  for programs that depend on that behavior.
  .Sp
! This option is enabled by default on most targets.  On Nios II ELF, it
! defaults to off.  On AVR and MSP430, this option is completely disabled.
  .Sp
  Passes that use the dataflow information
  are enabled independently at different optimization levels.
! .IP \fB\-fdevirtualize\fR 4
  .IX Item "-fdevirtualize"
  Attempt to convert calls to virtual functions to direct calls.  This
  is done both within a procedure and interprocedurally as part of
  indirect inlining (\fB\-findirect\-inlining\fR) and interprocedural constant
  propagation (\fB\-fipa\-cp\fR).
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fdevirtualize\-speculatively\fR 4
  .IX Item "-fdevirtualize-speculatively"
  Attempt to convert calls to virtual functions to speculative direct calls.
  Based on the analysis of the type inheritance graph, determine for a given call
*************** the set of likely targets. If the set is
*** 11627,11655 ****
  the call into a conditional deciding between direct and indirect calls.  The
  speculative calls enable more optimizations, such as inlining.  When they seem
  useless after further optimization, they are converted back into original form.
! .IP "\fB\-fdevirtualize\-at\-ltrans\fR" 4
  .IX Item "-fdevirtualize-at-ltrans"
  Stream extra information needed for aggressive devirtualization when running
! the link-time optimizer in local transformation mode.  
  This option enables more devirtualization but
  significantly increases the size of streamed data. For this reason it is
  disabled by default.
! .IP "\fB\-fexpensive\-optimizations\fR" 4
  .IX Item "-fexpensive-optimizations"
  Perform a number of minor optimizations that are relatively expensive.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-free\fR" 4
  .IX Item "-free"
  Attempt to remove redundant extension instructions.  This is especially
! helpful for the x86\-64 architecture, which implicitly zero-extends in 64\-bit
  registers after writing to their lower 32\-bit half.
  .Sp
  Enabled for Alpha, AArch64 and x86 at levels \fB\-O2\fR,
  \&\fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fno\-lifetime\-dse\fR" 4
  .IX Item "-fno-lifetime-dse"
! In \*(C+ the value of an object is only affected by changes within its
  lifetime: when the constructor begins, the object has an indeterminate
  value, and any changes during the lifetime of the object are dead when
  the object is destroyed.  Normally dead store elimination will take
--- 11556,11584 ----
  the call into a conditional deciding between direct and indirect calls.  The
  speculative calls enable more optimizations, such as inlining.  When they seem
  useless after further optimization, they are converted back into original form.
! .IP \fB\-fdevirtualize\-at\-ltrans\fR 4
  .IX Item "-fdevirtualize-at-ltrans"
  Stream extra information needed for aggressive devirtualization when running
! the link\-time optimizer in local transformation mode.  
  This option enables more devirtualization but
  significantly increases the size of streamed data. For this reason it is
  disabled by default.
! .IP \fB\-fexpensive\-optimizations\fR 4
  .IX Item "-fexpensive-optimizations"
  Perform a number of minor optimizations that are relatively expensive.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-free\fR 4
  .IX Item "-free"
  Attempt to remove redundant extension instructions.  This is especially
! helpful for the x86\-64 architecture, which implicitly zero\-extends in 64\-bit
  registers after writing to their lower 32\-bit half.
  .Sp
  Enabled for Alpha, AArch64 and x86 at levels \fB\-O2\fR,
  \&\fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fno\-lifetime\-dse\fR 4
  .IX Item "-fno-lifetime-dse"
! In C++ the value of an object is only affected by changes within its
  lifetime: when the constructor begins, the object has an indeterminate
  value, and any changes during the lifetime of the object are dead when
  the object is destroyed.  Normally dead store elimination will take
*************** storage) but still treat the object as d
*** 11661,11697 ****
  can use \fB\-flifetime\-dse=1\fR.  The default behavior can be
  explicitly selected with \fB\-flifetime\-dse=2\fR.
  \&\fB\-flifetime\-dse=0\fR is equivalent to \fB\-fno\-lifetime\-dse\fR.
! .IP "\fB\-flive\-range\-shrinkage\fR" 4
  .IX Item "-flive-range-shrinkage"
  Attempt to decrease register pressure through register live range
  shrinkage.  This is helpful for fast processors with small or moderate
  size register sets.
! .IP "\fB\-fira\-algorithm=\fR\fIalgorithm\fR" 4
  .IX Item "-fira-algorithm=algorithm"
  Use the specified coloring algorithm for the integrated register
  allocator.  The \fIalgorithm\fR argument can be \fBpriority\fR, which
! specifies Chow's priority coloring, or \fB\s-1CB\s0\fR, which specifies
! Chaitin-Briggs coloring.  Chaitin-Briggs coloring is not implemented
  for all architectures, but for those targets that do support it, it is
  the default because it generates better code.
! .IP "\fB\-fira\-region=\fR\fIregion\fR" 4
  .IX Item "-fira-region=region"
  Use specified regions for the integrated register allocator.  The
  \&\fIregion\fR argument should be one of the following:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
  Use all loops as register allocation regions.
  This can give the best results for machines with a small and/or
  irregular register set.
! .IP "\fBmixed\fR" 4
  .IX Item "mixed"
  Use all loops except for loops with small register pressure 
  as the regions.  This value usually gives
  the best results in most cases and for most architectures,
  and is enabled by default when compiling with optimization for speed
  (\fB\-O\fR, \fB\-O2\fR, ...).
! .IP "\fBone\fR" 4
  .IX Item "one"
  Use all functions as a single region.  
  This typically results in the smallest code size, and is enabled by default for
--- 11590,11626 ----
  can use \fB\-flifetime\-dse=1\fR.  The default behavior can be
  explicitly selected with \fB\-flifetime\-dse=2\fR.
  \&\fB\-flifetime\-dse=0\fR is equivalent to \fB\-fno\-lifetime\-dse\fR.
! .IP \fB\-flive\-range\-shrinkage\fR 4
  .IX Item "-flive-range-shrinkage"
  Attempt to decrease register pressure through register live range
  shrinkage.  This is helpful for fast processors with small or moderate
  size register sets.
! .IP \fB\-fira\-algorithm=\fR\fIalgorithm\fR 4
  .IX Item "-fira-algorithm=algorithm"
  Use the specified coloring algorithm for the integrated register
  allocator.  The \fIalgorithm\fR argument can be \fBpriority\fR, which
! specifies Chow\*(Aqs priority coloring, or \fBCB\fR, which specifies
! Chaitin\-Briggs coloring.  Chaitin\-Briggs coloring is not implemented
  for all architectures, but for those targets that do support it, it is
  the default because it generates better code.
! .IP \fB\-fira\-region=\fR\fIregion\fR 4
  .IX Item "-fira-region=region"
  Use specified regions for the integrated register allocator.  The
  \&\fIregion\fR argument should be one of the following:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
  Use all loops as register allocation regions.
  This can give the best results for machines with a small and/or
  irregular register set.
! .IP \fBmixed\fR 4
  .IX Item "mixed"
  Use all loops except for loops with small register pressure 
  as the regions.  This value usually gives
  the best results in most cases and for most architectures,
  and is enabled by default when compiling with optimization for speed
  (\fB\-O\fR, \fB\-O2\fR, ...).
! .IP \fBone\fR 4
  .IX Item "one"
  Use all functions as a single region.  
  This typically results in the smallest code size, and is enabled by default for
*************** This typically results in the smallest c
*** 11699,11738 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-fira\-hoist\-pressure\fR" 4
  .IX Item "-fira-hoist-pressure"
! Use \s-1IRA\s0 to evaluate register pressure in the code hoisting pass for
  decisions to hoist expressions.  This option usually results in smaller
  code, but it can slow the compiler down.
  .Sp
  This option is enabled at level \fB\-Os\fR for all targets.
! .IP "\fB\-fira\-loop\-pressure\fR" 4
  .IX Item "-fira-loop-pressure"
! Use \s-1IRA\s0 to evaluate register pressure in loops for decisions to move
  loop invariants.  This option usually results in generation
  of faster and smaller code on machines with large register files (>= 32
  registers), but it can slow the compiler down.
  .Sp
  This option is enabled at level \fB\-O3\fR for some targets.
! .IP "\fB\-fno\-ira\-share\-save\-slots\fR" 4
  .IX Item "-fno-ira-share-save-slots"
! Disable sharing of stack slots used for saving call-used hard
  registers living through a call.  Each hard register gets a
  separate stack slot, and as a result function stack frames are
  larger.
! .IP "\fB\-fno\-ira\-share\-spill\-slots\fR" 4
  .IX Item "-fno-ira-share-spill-slots"
! Disable sharing of stack slots allocated for pseudo-registers.  Each
! pseudo-register that does not get a hard register gets a separate
  stack slot, and as a result function stack frames are larger.
! .IP "\fB\-flra\-remat\fR" 4
  .IX Item "-flra-remat"
! Enable CFG-sensitive rematerialization in \s-1LRA.\s0  Instead of loading
! values of spilled pseudos, \s-1LRA\s0 tries to rematerialize (recalculate)
  values if it is profitable.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fdelayed\-branch\fR" 4
  .IX Item "-fdelayed-branch"
  If supported for the target machine, attempt to reorder instructions
  to exploit instruction slots available after delayed branch
--- 11628,11667 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-fira\-hoist\-pressure\fR 4
  .IX Item "-fira-hoist-pressure"
! Use IRA to evaluate register pressure in the code hoisting pass for
  decisions to hoist expressions.  This option usually results in smaller
  code, but it can slow the compiler down.
  .Sp
  This option is enabled at level \fB\-Os\fR for all targets.
! .IP \fB\-fira\-loop\-pressure\fR 4
  .IX Item "-fira-loop-pressure"
! Use IRA to evaluate register pressure in loops for decisions to move
  loop invariants.  This option usually results in generation
  of faster and smaller code on machines with large register files (>= 32
  registers), but it can slow the compiler down.
  .Sp
  This option is enabled at level \fB\-O3\fR for some targets.
! .IP \fB\-fno\-ira\-share\-save\-slots\fR 4
  .IX Item "-fno-ira-share-save-slots"
! Disable sharing of stack slots used for saving call\-used hard
  registers living through a call.  Each hard register gets a
  separate stack slot, and as a result function stack frames are
  larger.
! .IP \fB\-fno\-ira\-share\-spill\-slots\fR 4
  .IX Item "-fno-ira-share-spill-slots"
! Disable sharing of stack slots allocated for pseudo\-registers.  Each
! pseudo\-register that does not get a hard register gets a separate
  stack slot, and as a result function stack frames are larger.
! .IP \fB\-flra\-remat\fR 4
  .IX Item "-flra-remat"
! Enable CFG\-sensitive rematerialization in LRA.  Instead of loading
! values of spilled pseudos, LRA tries to rematerialize (recalculate)
  values if it is profitable.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fdelayed\-branch\fR 4
  .IX Item "-fdelayed-branch"
  If supported for the target machine, attempt to reorder instructions
  to exploit instruction slots available after delayed branch
*************** instructions.
*** 11740,11755 ****
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR,
  but not at \fB\-Og\fR.
! .IP "\fB\-fschedule\-insns\fR" 4
  .IX Item "-fschedule-insns"
  If supported for the target machine, attempt to reorder instructions to
  eliminate execution stalls due to required data being unavailable.  This
  helps machines that have slow floating point or memory load instructions
  by allowing other instructions to be issued until the result of the load
! or floating-point instruction is required.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-fschedule\-insns2\fR" 4
  .IX Item "-fschedule-insns2"
  Similar to \fB\-fschedule\-insns\fR, but requests an additional pass of
  instruction scheduling after register allocation has been done.  This is
--- 11669,11684 ----
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR,
  but not at \fB\-Og\fR.
! .IP \fB\-fschedule\-insns\fR 4
  .IX Item "-fschedule-insns"
  If supported for the target machine, attempt to reorder instructions to
  eliminate execution stalls due to required data being unavailable.  This
  helps machines that have slow floating point or memory load instructions
  by allowing other instructions to be issued until the result of the load
! or floating\-point instruction is required.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-fschedule\-insns2\fR 4
  .IX Item "-fschedule-insns2"
  Similar to \fB\-fschedule\-insns\fR, but requests an additional pass of
  instruction scheduling after register allocation has been done.  This is
*************** especially useful on machines with a rel
*** 11757,11773 ****
  registers and where memory load instructions take more than one cycle.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fno\-sched\-interblock\fR" 4
  .IX Item "-fno-sched-interblock"
  Disable instruction scheduling across basic blocks, which
  is normally enabled when scheduling before register allocation, i.e.
  with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fno\-sched\-spec\fR" 4
  .IX Item "-fno-sched-spec"
! Disable speculative motion of non-load instructions, which
  is normally enabled when scheduling before register allocation, i.e.
  with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-pressure\fR" 4
  .IX Item "-fsched-pressure"
  Enable register pressure sensitive insn scheduling before register
  allocation.  This only makes sense when scheduling before register
--- 11686,11702 ----
  registers and where memory load instructions take more than one cycle.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fno\-sched\-interblock\fR 4
  .IX Item "-fno-sched-interblock"
  Disable instruction scheduling across basic blocks, which
  is normally enabled when scheduling before register allocation, i.e.
  with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fno\-sched\-spec\fR 4
  .IX Item "-fno-sched-spec"
! Disable speculative motion of non\-load instructions, which
  is normally enabled when scheduling before register allocation, i.e.
  with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-pressure\fR 4
  .IX Item "-fsched-pressure"
  Enable register pressure sensitive insn scheduling before register
  allocation.  This only makes sense when scheduling before register
*************** allocation is enabled, i.e. with \fB\-fs
*** 11776,11795 ****
  generated code and decrease its size by preventing register pressure
  increase above the number of available hard registers and subsequent
  spills in register allocation.
! .IP "\fB\-fsched\-spec\-load\fR" 4
  .IX Item "-fsched-spec-load"
  Allow speculative motion of some load instructions.  This only makes
  sense when scheduling before register allocation, i.e. with
  \&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-spec\-load\-dangerous\fR" 4
  .IX Item "-fsched-spec-load-dangerous"
  Allow speculative motion of more load instructions.  This only makes
  sense when scheduling before register allocation, i.e. with
  \&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-stalled\-insns\fR" 4
  .IX Item "-fsched-stalled-insns"
  .PD 0
! .IP "\fB\-fsched\-stalled\-insns=\fR\fIn\fR" 4
  .IX Item "-fsched-stalled-insns=n"
  .PD
  Define how many insns (if any) can be moved prematurely from the queue
--- 11705,11724 ----
  generated code and decrease its size by preventing register pressure
  increase above the number of available hard registers and subsequent
  spills in register allocation.
! .IP \fB\-fsched\-spec\-load\fR 4
  .IX Item "-fsched-spec-load"
  Allow speculative motion of some load instructions.  This only makes
  sense when scheduling before register allocation, i.e. with
  \&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-spec\-load\-dangerous\fR 4
  .IX Item "-fsched-spec-load-dangerous"
  Allow speculative motion of more load instructions.  This only makes
  sense when scheduling before register allocation, i.e. with
  \&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-stalled\-insns\fR 4
  .IX Item "-fsched-stalled-insns"
  .PD 0
! .IP \fB\-fsched\-stalled\-insns=\fR\fIn\fR 4
  .IX Item "-fsched-stalled-insns=n"
  .PD
  Define how many insns (if any) can be moved prematurely from the queue
*************** prematurely, \fB\-fsched\-stalled\-insns
*** 11799,11808 ****
  on how many queued insns can be moved prematurely.
  \&\fB\-fsched\-stalled\-insns\fR without a value is equivalent to
  \&\fB\-fsched\-stalled\-insns=1\fR.
! .IP "\fB\-fsched\-stalled\-insns\-dep\fR" 4
  .IX Item "-fsched-stalled-insns-dep"
  .PD 0
! .IP "\fB\-fsched\-stalled\-insns\-dep=\fR\fIn\fR" 4
  .IX Item "-fsched-stalled-insns-dep=n"
  .PD
  Define how many insn groups (cycles) are examined for a dependency
--- 11728,11737 ----
  on how many queued insns can be moved prematurely.
  \&\fB\-fsched\-stalled\-insns\fR without a value is equivalent to
  \&\fB\-fsched\-stalled\-insns=1\fR.
! .IP \fB\-fsched\-stalled\-insns\-dep\fR 4
  .IX Item "-fsched-stalled-insns-dep"
  .PD 0
! .IP \fB\-fsched\-stalled\-insns\-dep=\fR\fIn\fR 4
  .IX Item "-fsched-stalled-insns-dep=n"
  .PD
  Define how many insn groups (cycles) are examined for a dependency
*************** and only if \fB\-fsched\-stalled\-insns\
*** 11813,11895 ****
  \&\fB\-fsched\-stalled\-insns\-dep=0\fR.
  \&\fB\-fsched\-stalled\-insns\-dep\fR without a value is equivalent to
  \&\fB\-fsched\-stalled\-insns\-dep=1\fR.
! .IP "\fB\-fsched2\-use\-superblocks\fR" 4
  .IX Item "-fsched2-use-superblocks"
  When scheduling after register allocation, use superblock scheduling.
  This allows motion across basic block boundaries,
  resulting in faster schedules.  This option is experimental, as not all machine
! descriptions used by \s-1GCC\s0 model the \s-1CPU\s0 closely enough to avoid unreliable
  results from the algorithm.
  .Sp
  This only makes sense when scheduling after register allocation, i.e. with
  \&\fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-group\-heuristic\fR" 4
  .IX Item "-fsched-group-heuristic"
  Enable the group heuristic in the scheduler.  This heuristic favors
  the instruction that belongs to a schedule group.  This is enabled
  by default when scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
  or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-critical\-path\-heuristic\fR" 4
  .IX Item "-fsched-critical-path-heuristic"
! Enable the critical-path heuristic in the scheduler.  This heuristic favors
  instructions on the critical path.  This is enabled by default when
  scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
  or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-spec\-insn\-heuristic\fR" 4
  .IX Item "-fsched-spec-insn-heuristic"
  Enable the speculative instruction heuristic in the scheduler.  This
  heuristic favors speculative instructions with greater dependency weakness.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR
  or at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-rank\-heuristic\fR" 4
  .IX Item "-fsched-rank-heuristic"
  Enable the rank heuristic in the scheduler.  This heuristic favors
  the instruction belonging to a basic block with greater size or frequency.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-last\-insn\-heuristic\fR" 4
  .IX Item "-fsched-last-insn-heuristic"
! Enable the last-instruction heuristic in the scheduler.  This heuristic
  favors the instruction that is less dependent on the last instruction
  scheduled.  This is enabled by default when scheduling is enabled,
  i.e. with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP "\fB\-fsched\-dep\-count\-heuristic\fR" 4
  .IX Item "-fsched-dep-count-heuristic"
! Enable the dependent-count heuristic in the scheduler.  This heuristic
  favors the instruction that has more instructions depending on it.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP "\fB\-freschedule\-modulo\-scheduled\-loops\fR" 4
  .IX Item "-freschedule-modulo-scheduled-loops"
  Modulo scheduling is performed before traditional scheduling.  If a loop
  is modulo scheduled, later scheduling passes may change its schedule.  
  Use this option to control that behavior.
! .IP "\fB\-fselective\-scheduling\fR" 4
  .IX Item "-fselective-scheduling"
  Schedule instructions using selective scheduling algorithm.  Selective
  scheduling runs instead of the first scheduler pass.
! .IP "\fB\-fselective\-scheduling2\fR" 4
  .IX Item "-fselective-scheduling2"
  Schedule instructions using selective scheduling algorithm.  Selective
  scheduling runs instead of the second scheduler pass.
! .IP "\fB\-fsel\-sched\-pipelining\fR" 4
  .IX Item "-fsel-sched-pipelining"
  Enable software pipelining of innermost loops during selective scheduling.
  This option has no effect unless one of \fB\-fselective\-scheduling\fR or
  \&\fB\-fselective\-scheduling2\fR is turned on.
! .IP "\fB\-fsel\-sched\-pipelining\-outer\-loops\fR" 4
  .IX Item "-fsel-sched-pipelining-outer-loops"
  When pipelining loops during selective scheduling, also pipeline outer loops.
  This option has no effect unless \fB\-fsel\-sched\-pipelining\fR is turned on.
! .IP "\fB\-fsemantic\-interposition\fR" 4
  .IX Item "-fsemantic-interposition"
! Some object formats, like \s-1ELF,\s0 allow interposing of symbols by the 
  dynamic linker.
! This means that for symbols exported from the \s-1DSO,\s0 the compiler cannot perform
  interprocedural propagation, inlining and other optimizations in anticipation
  that the function or variable in question may change. While this feature is
  useful, for example, to rewrite memory allocation functions by a debugging
--- 11742,11824 ----
  \&\fB\-fsched\-stalled\-insns\-dep=0\fR.
  \&\fB\-fsched\-stalled\-insns\-dep\fR without a value is equivalent to
  \&\fB\-fsched\-stalled\-insns\-dep=1\fR.
! .IP \fB\-fsched2\-use\-superblocks\fR 4
  .IX Item "-fsched2-use-superblocks"
  When scheduling after register allocation, use superblock scheduling.
  This allows motion across basic block boundaries,
  resulting in faster schedules.  This option is experimental, as not all machine
! descriptions used by GCC model the CPU closely enough to avoid unreliable
  results from the algorithm.
  .Sp
  This only makes sense when scheduling after register allocation, i.e. with
  \&\fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-group\-heuristic\fR 4
  .IX Item "-fsched-group-heuristic"
  Enable the group heuristic in the scheduler.  This heuristic favors
  the instruction that belongs to a schedule group.  This is enabled
  by default when scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
  or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-critical\-path\-heuristic\fR 4
  .IX Item "-fsched-critical-path-heuristic"
! Enable the critical\-path heuristic in the scheduler.  This heuristic favors
  instructions on the critical path.  This is enabled by default when
  scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
  or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-spec\-insn\-heuristic\fR 4
  .IX Item "-fsched-spec-insn-heuristic"
  Enable the speculative instruction heuristic in the scheduler.  This
  heuristic favors speculative instructions with greater dependency weakness.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR
  or at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-rank\-heuristic\fR 4
  .IX Item "-fsched-rank-heuristic"
  Enable the rank heuristic in the scheduler.  This heuristic favors
  the instruction belonging to a basic block with greater size or frequency.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-last\-insn\-heuristic\fR 4
  .IX Item "-fsched-last-insn-heuristic"
! Enable the last\-instruction heuristic in the scheduler.  This heuristic
  favors the instruction that is less dependent on the last instruction
  scheduled.  This is enabled by default when scheduling is enabled,
  i.e. with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP \fB\-fsched\-dep\-count\-heuristic\fR 4
  .IX Item "-fsched-dep-count-heuristic"
! Enable the dependent\-count heuristic in the scheduler.  This heuristic
  favors the instruction that has more instructions depending on it.
  This is enabled by default when scheduling is enabled, i.e.
  with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
  at \fB\-O2\fR or higher.
! .IP \fB\-freschedule\-modulo\-scheduled\-loops\fR 4
  .IX Item "-freschedule-modulo-scheduled-loops"
  Modulo scheduling is performed before traditional scheduling.  If a loop
  is modulo scheduled, later scheduling passes may change its schedule.  
  Use this option to control that behavior.
! .IP \fB\-fselective\-scheduling\fR 4
  .IX Item "-fselective-scheduling"
  Schedule instructions using selective scheduling algorithm.  Selective
  scheduling runs instead of the first scheduler pass.
! .IP \fB\-fselective\-scheduling2\fR 4
  .IX Item "-fselective-scheduling2"
  Schedule instructions using selective scheduling algorithm.  Selective
  scheduling runs instead of the second scheduler pass.
! .IP \fB\-fsel\-sched\-pipelining\fR 4
  .IX Item "-fsel-sched-pipelining"
  Enable software pipelining of innermost loops during selective scheduling.
  This option has no effect unless one of \fB\-fselective\-scheduling\fR or
  \&\fB\-fselective\-scheduling2\fR is turned on.
! .IP \fB\-fsel\-sched\-pipelining\-outer\-loops\fR 4
  .IX Item "-fsel-sched-pipelining-outer-loops"
  When pipelining loops during selective scheduling, also pipeline outer loops.
  This option has no effect unless \fB\-fsel\-sched\-pipelining\fR is turned on.
! .IP \fB\-fsemantic\-interposition\fR 4
  .IX Item "-fsemantic-interposition"
! Some object formats, like ELF, allow interposing of symbols by the 
  dynamic linker.
! This means that for symbols exported from the DSO, the compiler cannot perform
  interprocedural propagation, inlining and other optimizations in anticipation
  that the function or variable in question may change. While this feature is
  useful, for example, to rewrite memory allocation functions by a debugging
*************** for variables, the constructor of the va
*** 11902,11919 ****
  has no effect for functions explicitly declared inline 
  (where it is never allowed for interposition to change semantics) 
  and for symbols explicitly declared weak.
! .IP "\fB\-fshrink\-wrap\fR" 4
  .IX Item "-fshrink-wrap"
  Emit function prologues only before parts of the function that need it,
  rather than at the top of the function.  This flag is enabled by default at
  \&\fB\-O\fR and higher.
! .IP "\fB\-fshrink\-wrap\-separate\fR" 4
  .IX Item "-fshrink-wrap-separate"
! Shrink-wrap separate parts of the prologue and epilogue separately, so that
  those parts are only executed when needed.
  This option is on by default, but has no effect unless \fB\-fshrink\-wrap\fR
  is also turned on and the target supports this.
! .IP "\fB\-fcaller\-saves\fR" 4
  .IX Item "-fcaller-saves"
  Enable allocation of values to registers that are clobbered by
  function calls, by emitting extra instructions to save and restore the
--- 11831,11848 ----
  has no effect for functions explicitly declared inline 
  (where it is never allowed for interposition to change semantics) 
  and for symbols explicitly declared weak.
! .IP \fB\-fshrink\-wrap\fR 4
  .IX Item "-fshrink-wrap"
  Emit function prologues only before parts of the function that need it,
  rather than at the top of the function.  This flag is enabled by default at
  \&\fB\-O\fR and higher.
! .IP \fB\-fshrink\-wrap\-separate\fR 4
  .IX Item "-fshrink-wrap-separate"
! Shrink\-wrap separate parts of the prologue and epilogue separately, so that
  those parts are only executed when needed.
  This option is on by default, but has no effect unless \fB\-fshrink\-wrap\fR
  is also turned on and the target supports this.
! .IP \fB\-fcaller\-saves\fR 4
  .IX Item "-fcaller-saves"
  Enable allocation of values to registers that are clobbered by
  function calls, by emitting extra instructions to save and restore the
*************** registers around such calls.  Such alloc
*** 11921,11936 ****
  seems to result in better code.
  .Sp
  This option is always enabled by default on certain machines, usually
! those which have no call-preserved registers to use instead.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fcombine\-stack\-adjustments\fR" 4
  .IX Item "-fcombine-stack-adjustments"
  Tracks stack adjustments (pushes and pops) and stack memory references
  and then tries to find ways to combine them.
  .Sp
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-ra\fR" 4
  .IX Item "-fipa-ra"
  Use caller save registers for allocation if those registers are not used by
  any called function.  In that case it is not necessary to save and restore
--- 11850,11865 ----
  seems to result in better code.
  .Sp
  This option is always enabled by default on certain machines, usually
! those which have no call\-preserved registers to use instead.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fcombine\-stack\-adjustments\fR 4
  .IX Item "-fcombine-stack-adjustments"
  Tracks stack adjustments (pushes and pops) and stack memory references
  and then tries to find ways to combine them.
  .Sp
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-ra\fR 4
  .IX Item "-fipa-ra"
  Use caller save registers for allocation if those registers are not used by
  any called function.  In that case it is not necessary to save and restore
*************** same compilation unit as current functio
*** 11939,12022 ****
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, however the option
  is disabled if generated code will be instrumented for profiling
! (\fB\-p\fR, or \fB\-pg\fR) or if callee's register usage cannot be known
  exactly (this happens on targets that do not expose prologues
! and epilogues in \s-1RTL\s0).
! .IP "\fB\-fconserve\-stack\fR" 4
  .IX Item "-fconserve-stack"
  Attempt to minimize stack usage.  The compiler attempts to use less
  stack space, even if that makes the program slower.  This option
! implies setting the \fBlarge-stack-frame\fR parameter to 100
! and the \fBlarge-stack-frame-growth\fR parameter to 400.
! .IP "\fB\-ftree\-reassoc\fR" 4
  .IX Item "-ftree-reassoc"
  Perform reassociation on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP "\fB\-fcode\-hoisting\fR" 4
  .IX Item "-fcode-hoisting"
  Perform code hoisting.  Code hoisting tries to move the
  evaluation of expressions executed on all paths to the function exit
  as early as possible.  This is especially useful as a code size
  optimization, but it often helps for code speed as well.
  This flag is enabled by default at \fB\-O2\fR and higher.
! .IP "\fB\-ftree\-pre\fR" 4
  .IX Item "-ftree-pre"
! Perform partial redundancy elimination (\s-1PRE\s0) on trees.  This flag is
  enabled by default at \fB\-O2\fR and \fB\-O3\fR.
! .IP "\fB\-ftree\-partial\-pre\fR" 4
  .IX Item "-ftree-partial-pre"
! Make partial redundancy elimination (\s-1PRE\s0) more aggressive.  This flag is
  enabled by default at \fB\-O3\fR.
! .IP "\fB\-ftree\-forwprop\fR" 4
  .IX Item "-ftree-forwprop"
  Perform forward propagation on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-fre\fR" 4
  .IX Item "-ftree-fre"
! Perform full redundancy elimination (\s-1FRE\s0) on trees.  The difference
! between \s-1FRE\s0 and \s-1PRE\s0 is that \s-1FRE\s0 only considers expressions
  that are computed on all paths leading to the redundant computation.
! This analysis is faster than \s-1PRE,\s0 though it exposes fewer redundancies.
  This flag is enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-phiprop\fR" 4
  .IX Item "-ftree-phiprop"
  Perform hoisting of loads from conditional pointers on trees.  This
  pass is enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fhoist\-adjacent\-loads\fR" 4
  .IX Item "-fhoist-adjacent-loads"
! Speculatively hoist loads from both branches of an if-then-else if the
  loads are from adjacent locations in the same structure and the target
  architecture has a conditional move instruction.  This flag is enabled
  by default at \fB\-O2\fR and higher.
! .IP "\fB\-ftree\-copy\-prop\fR" 4
  .IX Item "-ftree-copy-prop"
  Perform copy propagation on trees.  This pass eliminates unnecessary
  copy operations.  This flag is enabled by default at \fB\-O1\fR and
  higher.
! .IP "\fB\-fipa\-pure\-const\fR" 4
  .IX Item "-fipa-pure-const"
  Discover which functions are pure or constant.
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-reference\fR" 4
  .IX Item "-fipa-reference"
  Discover which static variables do not escape the
  compilation unit.
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-reference\-addressable\fR" 4
  .IX Item "-fipa-reference-addressable"
! Discover read-only, write-only and non-addressable static variables.
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-stack\-alignment\fR" 4
  .IX Item "-fipa-stack-alignment"
  Reduce stack alignment on call sites if possible.
  Enabled by default.
! .IP "\fB\-fipa\-pta\fR" 4
  .IX Item "-fipa-pta"
  Perform interprocedural pointer analysis and interprocedural modification
  and reference analysis.  This option can cause excessive memory and
! compile-time usage on large compilation units.  It is not enabled by
  default at any optimization level.
! .IP "\fB\-fipa\-profile\fR" 4
  .IX Item "-fipa-profile"
  Perform interprocedural profile propagation.  The functions called only from
  cold functions are marked as cold. Also functions executed once (such as
--- 11868,11951 ----
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR, however the option
  is disabled if generated code will be instrumented for profiling
! (\fB\-p\fR, or \fB\-pg\fR) or if callee\*(Aqs register usage cannot be known
  exactly (this happens on targets that do not expose prologues
! and epilogues in RTL).
! .IP \fB\-fconserve\-stack\fR 4
  .IX Item "-fconserve-stack"
  Attempt to minimize stack usage.  The compiler attempts to use less
  stack space, even if that makes the program slower.  This option
! implies setting the \fBlarge\-stack\-frame\fR parameter to 100
! and the \fBlarge\-stack\-frame\-growth\fR parameter to 400.
! .IP \fB\-ftree\-reassoc\fR 4
  .IX Item "-ftree-reassoc"
  Perform reassociation on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP \fB\-fcode\-hoisting\fR 4
  .IX Item "-fcode-hoisting"
  Perform code hoisting.  Code hoisting tries to move the
  evaluation of expressions executed on all paths to the function exit
  as early as possible.  This is especially useful as a code size
  optimization, but it often helps for code speed as well.
  This flag is enabled by default at \fB\-O2\fR and higher.
! .IP \fB\-ftree\-pre\fR 4
  .IX Item "-ftree-pre"
! Perform partial redundancy elimination (PRE) on trees.  This flag is
  enabled by default at \fB\-O2\fR and \fB\-O3\fR.
! .IP \fB\-ftree\-partial\-pre\fR 4
  .IX Item "-ftree-partial-pre"
! Make partial redundancy elimination (PRE) more aggressive.  This flag is
  enabled by default at \fB\-O3\fR.
! .IP \fB\-ftree\-forwprop\fR 4
  .IX Item "-ftree-forwprop"
  Perform forward propagation on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-fre\fR 4
  .IX Item "-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 \fB\-O1\fR and higher.
! .IP \fB\-ftree\-phiprop\fR 4
  .IX Item "-ftree-phiprop"
  Perform hoisting of loads from conditional pointers on trees.  This
  pass is enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fhoist\-adjacent\-loads\fR 4
  .IX Item "-fhoist-adjacent-loads"
! Speculatively hoist loads from both branches of an if\-then\-else if the
  loads are from adjacent locations in the same structure and the target
  architecture has a conditional move instruction.  This flag is enabled
  by default at \fB\-O2\fR and higher.
! .IP \fB\-ftree\-copy\-prop\fR 4
  .IX Item "-ftree-copy-prop"
  Perform copy propagation on trees.  This pass eliminates unnecessary
  copy operations.  This flag is enabled by default at \fB\-O1\fR and
  higher.
! .IP \fB\-fipa\-pure\-const\fR 4
  .IX Item "-fipa-pure-const"
  Discover which functions are pure or constant.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-reference\fR 4
  .IX Item "-fipa-reference"
  Discover which static variables do not escape the
  compilation unit.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-reference\-addressable\fR 4
  .IX Item "-fipa-reference-addressable"
! Discover read\-only, write\-only and non\-addressable static variables.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-stack\-alignment\fR 4
  .IX Item "-fipa-stack-alignment"
  Reduce stack alignment on call sites if possible.
  Enabled by default.
! .IP \fB\-fipa\-pta\fR 4
  .IX Item "-fipa-pta"
  Perform interprocedural pointer analysis and interprocedural modification
  and reference analysis.  This option can cause excessive memory and
! compile\-time usage on large compilation units.  It is not enabled by
  default at any optimization level.
! .IP \fB\-fipa\-profile\fR 4
  .IX Item "-fipa-profile"
  Perform interprocedural profile propagation.  The functions called only from
  cold functions are marked as cold. Also functions executed once (such as
*************** cold functions are marked as cold. Also
*** 12024,12036 ****
  identified. Cold functions and loop less parts of functions executed once are
  then optimized for size.
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-modref\fR" 4
  .IX Item "-fipa-modref"
  Perform interprocedural mod/ref analysis.  This optimization analyzes the side
  effects of functions (memory locations that are modified or referenced) and
  enables better optimization across the function call boundary.  This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fipa\-cp\fR" 4
  .IX Item "-fipa-cp"
  Perform interprocedural constant propagation.
  This optimization analyzes the program to determine when values passed
--- 11953,11965 ----
  identified. Cold functions and loop less parts of functions executed once are
  then optimized for size.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-modref\fR 4
  .IX Item "-fipa-modref"
  Perform interprocedural mod/ref analysis.  This optimization analyzes the side
  effects of functions (memory locations that are modified or referenced) and
  enables better optimization across the function call boundary.  This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fipa\-cp\fR 4
  .IX Item "-fipa-cp"
  Perform interprocedural constant propagation.
  This optimization analyzes the program to determine when values passed
*************** This optimization can substantially incr
*** 12039,12045 ****
  if the application has constants passed to functions.
  This flag is enabled by default at \fB\-O2\fR, \fB\-Os\fR and \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-fipa\-cp\-clone\fR" 4
  .IX Item "-fipa-cp-clone"
  Perform function cloning to make interprocedural constant propagation stronger.
  When enabled, interprocedural constant propagation performs function cloning
--- 11968,11974 ----
  if the application has constants passed to functions.
  This flag is enabled by default at \fB\-O2\fR, \fB\-Os\fR and \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-fipa\-cp\-clone\fR 4
  .IX Item "-fipa-cp-clone"
  Perform function cloning to make interprocedural constant propagation stronger.
  When enabled, interprocedural constant propagation performs function cloning
*************** it may significantly increase code size
*** 12049,12105 ****
  (see \fB\-\-param ipa\-cp\-unit\-growth=\fR\fIvalue\fR).
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-fipa\-bit\-cp\fR" 4
  .IX Item "-fipa-bit-cp"
  When enabled, perform interprocedural bitwise constant
  propagation. This flag is enabled by default at \fB\-O2\fR and
  by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
  It requires that \fB\-fipa\-cp\fR is enabled.
! .IP "\fB\-fipa\-vrp\fR" 4
  .IX Item "-fipa-vrp"
  When enabled, perform interprocedural propagation of value
  ranges. This flag is enabled by default at \fB\-O2\fR. It requires
  that \fB\-fipa\-cp\fR is enabled.
! .IP "\fB\-fipa\-icf\fR" 4
  .IX Item "-fipa-icf"
! Perform Identical Code Folding for functions and read-only variables.
  The optimization reduces code size and may disturb unwind stacks by replacing
  a function by equivalent one with a different name. The optimization works
! more effectively with link-time optimization enabled.
  .Sp
! Although the behavior is similar to the Gold Linker's \s-1ICF\s0 optimization, \s-1GCC ICF\s0
  works on different levels and thus the optimizations are not same \- there are
! equivalences that are found only by \s-1GCC\s0 and equivalences found only by Gold.
  .Sp
  This flag is enabled by default at \fB\-O2\fR and \fB\-Os\fR.
! .IP "\fB\-flive\-patching=\fR\fIlevel\fR" 4
  .IX Item "-flive-patching=level"
! Control \s-1GCC\s0's optimizations to produce output suitable for live-patching.
  .Sp
! If the compiler's optimization uses a function's body or information extracted
  from its body to optimize/change another function, the latter is called an
  impacted function of the former.  If a function is patched, its impacted
  functions should be patched too.
  .Sp
! The impacted functions are determined by the compiler's interprocedural
  optimizations.  For example, a caller is impacted when inlining a function
  into its caller,
  cloning a function and changing its caller to call this new clone,
! or extracting a function's pureness/constness information to optimize
  its direct or indirect callers, etc.
  .Sp
! Usually, the more \s-1IPA\s0 optimizations enabled, the larger the number of
  impacted functions for each function.  In order to control the number of
  impacted functions and more easily compute the list of impacted function,
! \&\s-1IPA\s0 optimizations can be partially enabled at two different levels.
  .Sp
  The \fIlevel\fR argument should be one of the following:
  .RS 4
! .IP "\fBinline-clone\fR" 4
  .IX Item "inline-clone"
  Only enable inlining and cloning optimizations, which includes inlining,
  cloning, interprocedural scalar replacement of aggregates and partial inlining.
! As a result, when patching a function, all its callers and its clones'
  callers are impacted, therefore need to be patched as well.
  .Sp
  \&\fB\-flive\-patching=inline\-clone\fR disables the following optimization flags:
--- 11978,12034 ----
  (see \fB\-\-param ipa\-cp\-unit\-growth=\fR\fIvalue\fR).
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-fipa\-bit\-cp\fR 4
  .IX Item "-fipa-bit-cp"
  When enabled, perform interprocedural bitwise constant
  propagation. This flag is enabled by default at \fB\-O2\fR and
  by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
  It requires that \fB\-fipa\-cp\fR is enabled.
! .IP \fB\-fipa\-vrp\fR 4
  .IX Item "-fipa-vrp"
  When enabled, perform interprocedural propagation of value
  ranges. This flag is enabled by default at \fB\-O2\fR. It requires
  that \fB\-fipa\-cp\fR is enabled.
! .IP \fB\-fipa\-icf\fR 4
  .IX Item "-fipa-icf"
! Perform Identical Code Folding for functions and read\-only variables.
  The optimization reduces code size and may disturb unwind stacks by replacing
  a function by equivalent one with a different name. The optimization works
! more effectively with link\-time optimization enabled.
  .Sp
! Although the behavior is similar to the Gold Linker\*(Aqs ICF optimization, GCC ICF
  works on different levels and thus the optimizations are not same \- there are
! equivalences that are found only by GCC and equivalences found only by Gold.
  .Sp
  This flag is enabled by default at \fB\-O2\fR and \fB\-Os\fR.
! .IP \fB\-flive\-patching=\fR\fIlevel\fR 4
  .IX Item "-flive-patching=level"
! Control GCC\*(Aqs optimizations to produce output suitable for live\-patching.
  .Sp
! If the compiler\*(Aqs optimization uses a function\*(Aqs body or information extracted
  from its body to optimize/change another function, the latter is called an
  impacted function of the former.  If a function is patched, its impacted
  functions should be patched too.
  .Sp
! The impacted functions are determined by the compiler\*(Aqs interprocedural
  optimizations.  For example, a caller is impacted when inlining a function
  into its caller,
  cloning a function and changing its caller to call this new clone,
! or extracting a function\*(Aqs pureness/constness information to optimize
  its direct or indirect callers, etc.
  .Sp
! Usually, the more IPA optimizations enabled, the larger the number of
  impacted functions for each function.  In order to control the number of
  impacted functions and more easily compute the list of impacted function,
! IPA optimizations can be partially enabled at two different levels.
  .Sp
  The \fIlevel\fR argument should be one of the following:
  .RS 4
! .IP \fBinline\-clone\fR 4
  .IX Item "inline-clone"
  Only enable inlining and cloning optimizations, which includes inlining,
  cloning, interprocedural scalar replacement of aggregates and partial inlining.
! As a result, when patching a function, all its callers and its clones\*(Aq
  callers are impacted, therefore need to be patched as well.
  .Sp
  \&\fB\-flive\-patching=inline\-clone\fR disables the following optimization flags:
*************** callers are impacted, therefore need to
*** 12108,12114 ****
  \&\-fipa\-bit\-cp  \-fipa\-vrp  \-fipa\-pure\-const
  \&\-fipa\-reference\-addressable
  \&\-fipa\-stack\-alignment \-fipa\-modref\fR
! .IP "\fBinline-only-static\fR" 4
  .IX Item "inline-only-static"
  Only enable inlining of static functions.
  As a result, when patching a static function, all its callers are impacted
--- 12037,12043 ----
  \&\-fipa\-bit\-cp  \-fipa\-vrp  \-fipa\-pure\-const
  \&\-fipa\-reference\-addressable
  \&\-fipa\-stack\-alignment \-fipa\-modref\fR
! .IP \fBinline\-only\-static\fR 4
  .IX Item "inline-only-static"
  Only enable inlining of static functions.
  As a result, when patching a static function, all its callers are impacted
*************** optimization flags:
*** 12123,12279 ****
  .RS 4
  .Sp
  When \fB\-flive\-patching\fR is specified without any value, the default value
! is \fIinline-clone\fR.
  .Sp
  This flag is disabled by default.
  .Sp
! Note that \fB\-flive\-patching\fR is not supported with link-time optimization
  (\fB\-flto\fR).
  .RE
! .IP "\fB\-fisolate\-erroneous\-paths\-dereference\fR" 4
  .IX Item "-fisolate-erroneous-paths-dereference"
  Detect paths that trigger erroneous or undefined behavior due to
  dereferencing a null pointer.  Isolate those paths from the main control
  flow and turn the statement with erroneous or undefined behavior into a trap.
  This flag is enabled by default at \fB\-O2\fR and higher and depends on
  \&\fB\-fdelete\-null\-pointer\-checks\fR also being enabled.
! .IP "\fB\-fisolate\-erroneous\-paths\-attribute\fR" 4
  .IX Item "-fisolate-erroneous-paths-attribute"
  Detect paths that trigger erroneous or undefined behavior due to a null value
  being used in a way forbidden by a \f(CW\*(C`returns_nonnull\*(C'\fR or \f(CW\*(C`nonnull\*(C'\fR
  attribute.  Isolate those paths from the main control flow and turn the
  statement with erroneous or undefined behavior into a trap.  This is not
  currently enabled, but may be enabled by \fB\-O2\fR in the future.
! .IP "\fB\-ftree\-sink\fR" 4
  .IX Item "-ftree-sink"
  Perform forward store motion on trees.  This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-bit\-ccp\fR" 4
  .IX Item "-ftree-bit-ccp"
  Perform sparse conditional bit constant propagation on trees and propagate
  pointer alignment information.
  This pass only operates on local scalar variables and is enabled by default
  at \fB\-O1\fR and higher, except for \fB\-Og\fR.
  It requires that \fB\-ftree\-ccp\fR is enabled.
! .IP "\fB\-ftree\-ccp\fR" 4
  .IX Item "-ftree-ccp"
! Perform sparse conditional constant propagation (\s-1CCP\s0) on trees.  This
  pass only operates on local scalar variables and is enabled by default
  at \fB\-O1\fR and higher.
! .IP "\fB\-fssa\-backprop\fR" 4
  .IX Item "-fssa-backprop"
  Propagate information about uses of a value up the definition chain
  in order to simplify the definitions.  For example, this pass strips
  sign operations if the sign of a value never matters.  The flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fssa\-phiopt\fR" 4
  .IX Item "-fssa-phiopt"
! Perform pattern matching on \s-1SSA PHI\s0 nodes to optimize conditional
  code.  This pass is enabled by default at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP "\fB\-ftree\-switch\-conversion\fR" 4
  .IX Item "-ftree-switch-conversion"
  Perform conversion of simple initializations in a switch to
  initializations from a scalar array.  This flag is enabled by default
  at \fB\-O2\fR and higher.
! .IP "\fB\-ftree\-tail\-merge\fR" 4
  .IX Item "-ftree-tail-merge"
  Look for identical code sequences.  When found, replace one with a jump to the
  other.  This optimization is known as tail merging or cross jumping.  This flag
  is enabled by default at \fB\-O2\fR and higher.  The compilation time
  in this pass can
! be limited using \fBmax-tail-merge-comparisons\fR parameter and
! \&\fBmax-tail-merge-iterations\fR parameter.
! .IP "\fB\-ftree\-dce\fR" 4
  .IX Item "-ftree-dce"
! Perform dead code elimination (\s-1DCE\s0) on trees.  This flag is enabled by
  default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-builtin\-call\-dce\fR" 4
  .IX Item "-ftree-builtin-call-dce"
! Perform conditional dead code elimination (\s-1DCE\s0) for calls to built-in functions
  that may set \f(CW\*(C`errno\*(C'\fR but are otherwise free of side effects.  This flag is
  enabled by default at \fB\-O2\fR and higher if \fB\-Os\fR is not also
  specified.
! .IP "\fB\-ffinite\-loops\fR" 4
  .IX Item "-ffinite-loops"
  Assume that a loop with an exit will eventually take the exit and not loop
  indefinitely.  This allows the compiler to remove loops that otherwise have
! no side-effects, not considering eventual endless looping as such.
  .Sp
! This option is enabled by default at \fB\-O2\fR for \*(C+ with \-std=c++11
  or higher.
! .IP "\fB\-ftree\-dominator\-opts\fR" 4
  .IX Item "-ftree-dominator-opts"
  Perform a variety of simple scalar cleanups (constant/copy
  propagation, redundancy elimination, range propagation and expression
  simplification) based on a dominator tree traversal.  This also
  performs jump threading (to reduce jumps to jumps). This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-dse\fR" 4
  .IX Item "-ftree-dse"
! Perform dead store elimination (\s-1DSE\s0) on trees.  A dead store is a store into
  a memory location that is later overwritten by another store without
  any intervening loads.  In this case the earlier store can be deleted.  This
  flag is enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-ch\fR" 4
  .IX Item "-ftree-ch"
  Perform loop header copying on trees.  This is beneficial since it increases
  effectiveness of code motion optimizations.  It also saves one jump.  This flag
  is enabled by default at \fB\-O1\fR and higher.  It is not enabled
  for \fB\-Os\fR, since it usually increases code size.
! .IP "\fB\-ftree\-loop\-optimize\fR" 4
  .IX Item "-ftree-loop-optimize"
  Perform loop optimizations on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-loop\-linear\fR" 4
  .IX Item "-ftree-loop-linear"
  .PD 0
! .IP "\fB\-floop\-strip\-mine\fR" 4
  .IX Item "-floop-strip-mine"
! .IP "\fB\-floop\-block\fR" 4
  .IX Item "-floop-block"
  .PD
  Perform loop nest optimizations.  Same as
! \&\fB\-floop\-nest\-optimize\fR.  To use this code transformation, \s-1GCC\s0 has
  to be configured with \fB\-\-with\-isl\fR to enable the Graphite loop
  transformation infrastructure.
! .IP "\fB\-fgraphite\-identity\fR" 4
  .IX Item "-fgraphite-identity"
  Enable the identity transformation for graphite.  For every SCoP we generate
  the polyhedral representation and transform it back to gimple.  Using
  \&\fB\-fgraphite\-identity\fR we can check the costs or benefits of the
! \&\s-1GIMPLE\s0 \-> \s-1GRAPHITE\s0 \-> \s-1GIMPLE\s0 transformation.  Some minimal optimizations
  are also performed by the code generator isl, like index splitting and
  dead code elimination in loops.
! .IP "\fB\-floop\-nest\-optimize\fR" 4
  .IX Item "-floop-nest-optimize"
  Enable the isl based loop nest optimizer.  This is a generic loop nest
  optimizer based on the Pluto optimization algorithms.  It calculates a loop
! structure optimized for data-locality and parallelism.  This option
  is experimental.
! .IP "\fB\-floop\-parallelize\-all\fR" 4
  .IX Item "-floop-parallelize-all"
  Use the Graphite data dependence analysis to identify loops that can
  be parallelized.  Parallelize all the loops that can be analyzed to
  not contain loop carried dependences without checking that it is
  profitable to parallelize the loops.
! .IP "\fB\-ftree\-coalesce\-vars\fR" 4
  .IX Item "-ftree-coalesce-vars"
! While transforming the program out of the \s-1SSA\s0 representation, attempt to
! reduce copying by coalescing versions of different user-defined
  variables, instead of just compiler temporaries.  This may severely
  limit the ability to debug an optimized program compiled with
  \&\fB\-fno\-var\-tracking\-assignments\fR.  In the negated form, this flag
! prevents \s-1SSA\s0 coalescing of user variables.  This option is enabled by
  default if optimization is enabled, and it does very little otherwise.
! .IP "\fB\-ftree\-loop\-if\-convert\fR" 4
  .IX Item "-ftree-loop-if-convert"
  Attempt to transform conditional jumps in the innermost loops to
! branch-less equivalents.  The intent is to remove control-flow from
  the innermost loops in order to improve the ability of the
  vectorization pass to handle these loops.  This is enabled by default
  if vectorization is enabled.
! .IP "\fB\-ftree\-loop\-distribution\fR" 4
  .IX Item "-ftree-loop-distribution"
  Perform loop distribution.  This flag can improve cache performance on
  big loop bodies and allow further loop optimizations, like
--- 12052,12208 ----
  .RS 4
  .Sp
  When \fB\-flive\-patching\fR is specified without any value, the default value
! is \fIinline\-clone\fR.
  .Sp
  This flag is disabled by default.
  .Sp
! Note that \fB\-flive\-patching\fR is not supported with link\-time optimization
  (\fB\-flto\fR).
  .RE
! .IP \fB\-fisolate\-erroneous\-paths\-dereference\fR 4
  .IX Item "-fisolate-erroneous-paths-dereference"
  Detect paths that trigger erroneous or undefined behavior due to
  dereferencing a null pointer.  Isolate those paths from the main control
  flow and turn the statement with erroneous or undefined behavior into a trap.
  This flag is enabled by default at \fB\-O2\fR and higher and depends on
  \&\fB\-fdelete\-null\-pointer\-checks\fR also being enabled.
! .IP \fB\-fisolate\-erroneous\-paths\-attribute\fR 4
  .IX Item "-fisolate-erroneous-paths-attribute"
  Detect paths that trigger erroneous or undefined behavior due to a null value
  being used in a way forbidden by a \f(CW\*(C`returns_nonnull\*(C'\fR or \f(CW\*(C`nonnull\*(C'\fR
  attribute.  Isolate those paths from the main control flow and turn the
  statement with erroneous or undefined behavior into a trap.  This is not
  currently enabled, but may be enabled by \fB\-O2\fR in the future.
! .IP \fB\-ftree\-sink\fR 4
  .IX Item "-ftree-sink"
  Perform forward store motion on trees.  This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-bit\-ccp\fR 4
  .IX Item "-ftree-bit-ccp"
  Perform sparse conditional bit constant propagation on trees and propagate
  pointer alignment information.
  This pass only operates on local scalar variables and is enabled by default
  at \fB\-O1\fR and higher, except for \fB\-Og\fR.
  It requires that \fB\-ftree\-ccp\fR is enabled.
! .IP \fB\-ftree\-ccp\fR 4
  .IX Item "-ftree-ccp"
! Perform sparse conditional constant propagation (CCP) on trees.  This
  pass only operates on local scalar variables and is enabled by default
  at \fB\-O1\fR and higher.
! .IP \fB\-fssa\-backprop\fR 4
  .IX Item "-fssa-backprop"
  Propagate information about uses of a value up the definition chain
  in order to simplify the definitions.  For example, this pass strips
  sign operations if the sign of a value never matters.  The flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fssa\-phiopt\fR 4
  .IX Item "-fssa-phiopt"
! Perform pattern matching on SSA PHI nodes to optimize conditional
  code.  This pass is enabled by default at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP \fB\-ftree\-switch\-conversion\fR 4
  .IX Item "-ftree-switch-conversion"
  Perform conversion of simple initializations in a switch to
  initializations from a scalar array.  This flag is enabled by default
  at \fB\-O2\fR and higher.
! .IP \fB\-ftree\-tail\-merge\fR 4
  .IX Item "-ftree-tail-merge"
  Look for identical code sequences.  When found, replace one with a jump to the
  other.  This optimization is known as tail merging or cross jumping.  This flag
  is enabled by default at \fB\-O2\fR and higher.  The compilation time
  in this pass can
! be limited using \fBmax\-tail\-merge\-comparisons\fR parameter and
! \&\fBmax\-tail\-merge\-iterations\fR parameter.
! .IP \fB\-ftree\-dce\fR 4
  .IX Item "-ftree-dce"
! Perform dead code elimination (DCE) on trees.  This flag is enabled by
  default at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-builtin\-call\-dce\fR 4
  .IX Item "-ftree-builtin-call-dce"
! Perform conditional dead code elimination (DCE) for calls to built\-in functions
  that may set \f(CW\*(C`errno\*(C'\fR but are otherwise free of side effects.  This flag is
  enabled by default at \fB\-O2\fR and higher if \fB\-Os\fR is not also
  specified.
! .IP \fB\-ffinite\-loops\fR 4
  .IX Item "-ffinite-loops"
  Assume that a loop with an exit will eventually take the exit and not loop
  indefinitely.  This allows the compiler to remove loops that otherwise have
! no side\-effects, not considering eventual endless looping as such.
  .Sp
! This option is enabled by default at \fB\-O2\fR for C++ with \-std=c++11
  or higher.
! .IP \fB\-ftree\-dominator\-opts\fR 4
  .IX Item "-ftree-dominator-opts"
  Perform a variety of simple scalar cleanups (constant/copy
  propagation, redundancy elimination, range propagation and expression
  simplification) based on a dominator tree traversal.  This also
  performs jump threading (to reduce jumps to jumps). This flag is
  enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-dse\fR 4
  .IX Item "-ftree-dse"
! Perform dead store elimination (DSE) on trees.  A dead store is a store into
  a memory location that is later overwritten by another store without
  any intervening loads.  In this case the earlier store can be deleted.  This
  flag is enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-ch\fR 4
  .IX Item "-ftree-ch"
  Perform loop header copying on trees.  This is beneficial since it increases
  effectiveness of code motion optimizations.  It also saves one jump.  This flag
  is enabled by default at \fB\-O1\fR and higher.  It is not enabled
  for \fB\-Os\fR, since it usually increases code size.
! .IP \fB\-ftree\-loop\-optimize\fR 4
  .IX Item "-ftree-loop-optimize"
  Perform loop optimizations on trees.  This flag is enabled by default
  at \fB\-O1\fR and higher.
! .IP \fB\-ftree\-loop\-linear\fR 4
  .IX Item "-ftree-loop-linear"
  .PD 0
! .IP \fB\-floop\-strip\-mine\fR 4
  .IX Item "-floop-strip-mine"
! .IP \fB\-floop\-block\fR 4
  .IX Item "-floop-block"
  .PD
  Perform loop nest optimizations.  Same as
! \&\fB\-floop\-nest\-optimize\fR.  To use this code transformation, GCC has
  to be configured with \fB\-\-with\-isl\fR to enable the Graphite loop
  transformation infrastructure.
! .IP \fB\-fgraphite\-identity\fR 4
  .IX Item "-fgraphite-identity"
  Enable the identity transformation for graphite.  For every SCoP we generate
  the polyhedral representation and transform it back to gimple.  Using
  \&\fB\-fgraphite\-identity\fR we can check the costs or benefits of the
! GIMPLE \-> GRAPHITE \-> GIMPLE transformation.  Some minimal optimizations
  are also performed by the code generator isl, like index splitting and
  dead code elimination in loops.
! .IP \fB\-floop\-nest\-optimize\fR 4
  .IX Item "-floop-nest-optimize"
  Enable the isl based loop nest optimizer.  This is a generic loop nest
  optimizer based on the Pluto optimization algorithms.  It calculates a loop
! structure optimized for data\-locality and parallelism.  This option
  is experimental.
! .IP \fB\-floop\-parallelize\-all\fR 4
  .IX Item "-floop-parallelize-all"
  Use the Graphite data dependence analysis to identify loops that can
  be parallelized.  Parallelize all the loops that can be analyzed to
  not contain loop carried dependences without checking that it is
  profitable to parallelize the loops.
! .IP \fB\-ftree\-coalesce\-vars\fR 4
  .IX Item "-ftree-coalesce-vars"
! While transforming the program out of the SSA representation, attempt to
! reduce copying by coalescing versions of different user\-defined
  variables, instead of just compiler temporaries.  This may severely
  limit the ability to debug an optimized program compiled with
  \&\fB\-fno\-var\-tracking\-assignments\fR.  In the negated form, this flag
! prevents SSA coalescing of user variables.  This option is enabled by
  default if optimization is enabled, and it does very little otherwise.
! .IP \fB\-ftree\-loop\-if\-convert\fR 4
  .IX Item "-ftree-loop-if-convert"
  Attempt to transform conditional jumps in the innermost loops to
! branch\-less equivalents.  The intent is to remove control\-flow from
  the innermost loops in order to improve the ability of the
  vectorization pass to handle these loops.  This is enabled by default
  if vectorization is enabled.
! .IP \fB\-ftree\-loop\-distribution\fR 4
  .IX Item "-ftree-loop-distribution"
  Perform loop distribution.  This flag can improve cache performance on
  big loop bodies and allow further loop optimizations, like
*************** is transformed to
*** 12299,12305 ****
  .Sp
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-ftree\-loop\-distribute\-patterns\fR" 4
  .IX Item "-ftree-loop-distribute-patterns"
  Perform loop distribution of patterns that can be code generated with
  calls to a library.  This flag is enabled by default at \fB\-O2\fR and
--- 12228,12234 ----
  .Sp
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-ftree\-loop\-distribute\-patterns\fR 4
  .IX Item "-ftree-loop-distribute-patterns"
  Perform loop distribution of patterns that can be code generated with
  calls to a library.  This flag is enabled by default at \fB\-O2\fR and
*************** is transformed to
*** 12329,12335 ****
  and the initialization loop is transformed into a call to memset zero.
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-floop\-interchange\fR" 4
  .IX Item "-floop-interchange"
  Perform loop interchange outside of graphite.  This flag can improve cache
  performance on loop nest and allow further loop optimizations, like
--- 12258,12264 ----
  and the initialization loop is transformed into a call to memset zero.
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-floop\-interchange\fR 4
  .IX Item "-floop-interchange"
  Perform loop interchange outside of graphite.  This flag can improve cache
  performance on loop nest and allow further loop optimizations, like
*************** is transformed to
*** 12353,12379 ****
  .Sp
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-floop\-unroll\-and\-jam\fR" 4
  .IX Item "-floop-unroll-and-jam"
  Apply unroll and jam transformations on feasible loops.  In a loop
  nest this unrolls the outer loop by some factor and fuses the resulting
  multiple inner loops.  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-ftree\-loop\-im\fR" 4
  .IX Item "-ftree-loop-im"
  Perform loop invariant motion on trees.  This pass moves only invariants that
! are hard to handle at \s-1RTL\s0 level (function calls, operations that expand to
  nontrivial sequences of insns).  With \fB\-funswitch\-loops\fR it also moves
  operands of conditions that are invariant out of the loop, so that we can use
  just trivial invariantness analysis in loop unswitching.  The pass also includes
  store motion.
! .IP "\fB\-ftree\-loop\-ivcanon\fR" 4
  .IX Item "-ftree-loop-ivcanon"
  Create a canonical counter for number of iterations in loops for which
  determining number of iterations requires complicated analysis.  Later
  optimizations then may determine the number easily.  Useful especially
  in connection with unrolling.
! .IP "\fB\-ftree\-scev\-cprop\fR" 4
  .IX Item "-ftree-scev-cprop"
  Perform final value replacement.  If a variable is modified in a loop
  in such a way that its value when exiting the loop can be determined using
--- 12282,12308 ----
  .Sp
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-floop\-unroll\-and\-jam\fR 4
  .IX Item "-floop-unroll-and-jam"
  Apply unroll and jam transformations on feasible loops.  In a loop
  nest this unrolls the outer loop by some factor and fuses the resulting
  multiple inner loops.  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-ftree\-loop\-im\fR 4
  .IX Item "-ftree-loop-im"
  Perform loop invariant motion on trees.  This pass moves only invariants that
! are hard to handle at RTL level (function calls, operations that expand to
  nontrivial sequences of insns).  With \fB\-funswitch\-loops\fR it also moves
  operands of conditions that are invariant out of the loop, so that we can use
  just trivial invariantness analysis in loop unswitching.  The pass also includes
  store motion.
! .IP \fB\-ftree\-loop\-ivcanon\fR 4
  .IX Item "-ftree-loop-ivcanon"
  Create a canonical counter for number of iterations in loops for which
  determining number of iterations requires complicated analysis.  Later
  optimizations then may determine the number easily.  Useful especially
  in connection with unrolling.
! .IP \fB\-ftree\-scev\-cprop\fR 4
  .IX Item "-ftree-scev-cprop"
  Perform final value replacement.  If a variable is modified in a loop
  in such a way that its value when exiting the loop can be determined using
*************** only its initial value and the number of
*** 12381,12453 ****
  the final value by such a computation, provided it is sufficiently cheap.
  This reduces data dependencies and may allow further simplifications.
  Enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-fivopts\fR" 4
  .IX Item "-fivopts"
  Perform induction variable optimizations (strength reduction, induction
  variable merging and induction variable elimination) on trees.
! .IP "\fB\-ftree\-parallelize\-loops=n\fR" 4
  .IX Item "-ftree-parallelize-loops=n"
  Parallelize loops, i.e., split their iteration space to run in n threads.
  This is only possible for loops whose iterations are independent
  and can be arbitrarily reordered.  The optimization is only
! profitable on multiprocessor machines, for loops that are CPU-intensive,
  rather than constrained e.g. by memory bandwidth.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets
  that have support for \fB\-pthread\fR.
! .IP "\fB\-ftree\-pta\fR" 4
  .IX Item "-ftree-pta"
! Perform function-local points-to analysis on trees.  This flag is
  enabled by default at \fB\-O1\fR and higher, except for \fB\-Og\fR.
! .IP "\fB\-ftree\-sra\fR" 4
  .IX Item "-ftree-sra"
  Perform scalar replacement of aggregates.  This pass replaces structure
  references with scalars to prevent committing structures to memory too
  early.  This flag is enabled by default at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP "\fB\-fstore\-merging\fR" 4
  .IX Item "-fstore-merging"
  Perform merging of narrow stores to consecutive memory addresses.  This pass
  merges contiguous stores of immediate values narrower than a word into fewer
  wider stores to reduce the number of instructions.  This is enabled by default
  at \fB\-O2\fR and higher as well as \fB\-Os\fR.
! .IP "\fB\-ftree\-ter\fR" 4
  .IX Item "-ftree-ter"
! Perform temporary expression replacement during the \s-1SSA\-\s0>normal phase.  Single
  use/single def temporaries are replaced at their use location with their
! defining expression.  This results in non-GIMPLE code, but gives the expanders
! much more complex trees to work on resulting in better \s-1RTL\s0 generation.  This is
  enabled by default at \fB\-O1\fR and higher.
! .IP "\fB\-ftree\-slsr\fR" 4
  .IX Item "-ftree-slsr"
! Perform straight-line strength reduction on trees.  This recognizes related
  expressions involving multiplications and replaces them by less expensive
  calculations when possible.  This is enabled by default at \fB\-O1\fR and
  higher.
! .IP "\fB\-ftree\-vectorize\fR" 4
  .IX Item "-ftree-vectorize"
  Perform vectorization on trees. This flag enables \fB\-ftree\-loop\-vectorize\fR
  and \fB\-ftree\-slp\-vectorize\fR if not explicitly specified.
! .IP "\fB\-ftree\-loop\-vectorize\fR" 4
  .IX Item "-ftree-loop-vectorize"
  Perform loop vectorization on trees. This flag is enabled by default at
  \&\fB\-O2\fR and by \fB\-ftree\-vectorize\fR, \fB\-fprofile\-use\fR,
  and \fB\-fauto\-profile\fR.
! .IP "\fB\-ftree\-slp\-vectorize\fR" 4
  .IX Item "-ftree-slp-vectorize"
  Perform basic block vectorization on trees. This flag is enabled by default at
  \&\fB\-O2\fR and by \fB\-ftree\-vectorize\fR, \fB\-fprofile\-use\fR,
  and \fB\-fauto\-profile\fR.
! .IP "\fB\-ftrivial\-auto\-var\-init=\fR\fIchoice\fR" 4
  .IX Item "-ftrivial-auto-var-init=choice"
  Initialize automatic variables with either a pattern or with zeroes to increase
  the security and predictability of a program by preventing uninitialized memory
  disclosure and use.
! \&\s-1GCC\s0 still considers an automatic variable that doesn't have an explicit
  initializer as uninitialized, \fB\-Wuninitialized\fR and
  \&\fB\-Wanalyzer\-use\-of\-uninitialized\-value\fR will still report
  warning messages on such automatic variables and the compiler will
  perform optimization as if the variable were uninitialized.
! With this option, \s-1GCC\s0 will also initialize any padding of automatic variables
  that have structure or union types to zeroes.
  However, the current implementation cannot initialize automatic variables that
  are declared between the controlling expression and the first case of a
--- 12310,12382 ----
  the final value by such a computation, provided it is sufficiently cheap.
  This reduces data dependencies and may allow further simplifications.
  Enabled by default at \fB\-O1\fR and higher.
! .IP \fB\-fivopts\fR 4
  .IX Item "-fivopts"
  Perform induction variable optimizations (strength reduction, induction
  variable merging and induction variable elimination) on trees.
! .IP \fB\-ftree\-parallelize\-loops=n\fR 4
  .IX Item "-ftree-parallelize-loops=n"
  Parallelize loops, i.e., split their iteration space to run in n threads.
  This is only possible for loops whose iterations are independent
  and can be arbitrarily reordered.  The optimization is only
! profitable on multiprocessor machines, for loops that are CPU\-intensive,
  rather than constrained e.g. by memory bandwidth.  This option
  implies \fB\-pthread\fR, and thus is only supported on targets
  that have support for \fB\-pthread\fR.
! .IP \fB\-ftree\-pta\fR 4
  .IX Item "-ftree-pta"
! Perform function\-local points\-to analysis on trees.  This flag is
  enabled by default at \fB\-O1\fR and higher, except for \fB\-Og\fR.
! .IP \fB\-ftree\-sra\fR 4
  .IX Item "-ftree-sra"
  Perform scalar replacement of aggregates.  This pass replaces structure
  references with scalars to prevent committing structures to memory too
  early.  This flag is enabled by default at \fB\-O1\fR and higher,
  except for \fB\-Og\fR.
! .IP \fB\-fstore\-merging\fR 4
  .IX Item "-fstore-merging"
  Perform merging of narrow stores to consecutive memory addresses.  This pass
  merges contiguous stores of immediate values narrower than a word into fewer
  wider stores to reduce the number of instructions.  This is enabled by default
  at \fB\-O2\fR and higher as well as \fB\-Os\fR.
! .IP \fB\-ftree\-ter\fR 4
  .IX Item "-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 \fB\-O1\fR and higher.
! .IP \fB\-ftree\-slsr\fR 4
  .IX Item "-ftree-slsr"
! Perform straight\-line strength reduction on trees.  This recognizes related
  expressions involving multiplications and replaces them by less expensive
  calculations when possible.  This is enabled by default at \fB\-O1\fR and
  higher.
! .IP \fB\-ftree\-vectorize\fR 4
  .IX Item "-ftree-vectorize"
  Perform vectorization on trees. This flag enables \fB\-ftree\-loop\-vectorize\fR
  and \fB\-ftree\-slp\-vectorize\fR if not explicitly specified.
! .IP \fB\-ftree\-loop\-vectorize\fR 4
  .IX Item "-ftree-loop-vectorize"
  Perform loop vectorization on trees. This flag is enabled by default at
  \&\fB\-O2\fR and by \fB\-ftree\-vectorize\fR, \fB\-fprofile\-use\fR,
  and \fB\-fauto\-profile\fR.
! .IP \fB\-ftree\-slp\-vectorize\fR 4
  .IX Item "-ftree-slp-vectorize"
  Perform basic block vectorization on trees. This flag is enabled by default at
  \&\fB\-O2\fR and by \fB\-ftree\-vectorize\fR, \fB\-fprofile\-use\fR,
  and \fB\-fauto\-profile\fR.
! .IP \fB\-ftrivial\-auto\-var\-init=\fR\fIchoice\fR 4
  .IX Item "-ftrivial-auto-var-init=choice"
  Initialize automatic variables with either a pattern or with zeroes to increase
  the security and predictability of a program by preventing uninitialized memory
  disclosure and use.
! GCC still considers an automatic variable that doesn\*(Aqt have an explicit
  initializer as uninitialized, \fB\-Wuninitialized\fR and
  \&\fB\-Wanalyzer\-use\-of\-uninitialized\-value\fR will still report
  warning messages on such automatic variables and the compiler will
  perform optimization as if the variable were uninitialized.
! With this option, GCC will also initialize any padding of automatic variables
  that have structure or union types to zeroes.
  However, the current implementation cannot initialize automatic variables that
  are declared between the controlling expression and the first case of a
*************** such cases.
*** 12456,12472 ****
  .Sp
  The three values of \fIchoice\fR are:
  .RS 4
! .IP "*" 4
! \&\fBuninitialized\fR doesn't initialize any automatic variables.
! This is C and \*(C+'s default.
! .IP "*" 4
  \&\fBpattern\fR Initialize automatic variables with values which will likely
  transform logic bugs into crashes down the line, are easily recognized in a
  crash dump and without being values that programmers can rely on for useful
  program semantics.
! The current value is byte-repeatable pattern with byte \*(L"0xFE\*(R".
  The values used for pattern initialization might be changed in the future.
! .IP "*" 4
  \&\fBzero\fR Initialize automatic variables with zeroes.
  .RE
  .RS 4
--- 12385,12401 ----
  .Sp
  The three values of \fIchoice\fR are:
  .RS 4
! .IP * 4
! \&\fBuninitialized\fR doesn\*(Aqt initialize any automatic variables.
! This is C and C++\*(Aqs default.
! .IP * 4
  \&\fBpattern\fR Initialize automatic variables with values which will likely
  transform logic bugs into crashes down the line, are easily recognized in a
  crash dump and without being values that programmers can rely on for useful
  program semantics.
! The current value is byte\-repeatable pattern with byte "0xFE".
  The values used for pattern initialization might be changed in the future.
! .IP * 4
  \&\fBzero\fR Initialize automatic variables with zeroes.
  .RE
  .RS 4
*************** The default is \fBuninitialized\fR.
*** 12476,12511 ****
  You can control this behavior for a specific variable by using the variable
  attribute \f(CW\*(C`uninitialized\*(C'\fR.
  .RE
! .IP "\fB\-fvect\-cost\-model=\fR\fImodel\fR" 4
  .IX Item "-fvect-cost-model=model"
  Alter the cost model used for vectorization.  The \fImodel\fR argument
  should be one of \fBunlimited\fR, \fBdynamic\fR, \fBcheap\fR or
! \&\fBvery-cheap\fR.
! With the \fBunlimited\fR model the vectorized code-path is assumed
  to be profitable while with the \fBdynamic\fR model a runtime check
! guards the vectorized code-path to enable it only for iteration
  counts that will likely execute faster than when executing the original
  scalar loop.  The \fBcheap\fR model disables vectorization of
  loops where doing so would be cost prohibitive for example due to
  required runtime checks for data dependence or alignment but otherwise
! is equal to the \fBdynamic\fR model.  The \fBvery-cheap\fR model only
  allows vectorization if the vector code would entirely replace the
  scalar code that is being vectorized.  For example, if each iteration
  of a vectorized loop would only be able to handle exactly four iterations
! of the scalar loop, the \fBvery-cheap\fR model would only allow
  vectorization if the scalar iteration count is known to be a multiple
  of four.
  .Sp
  The default cost model depends on other optimization flags and is
  either \fBdynamic\fR or \fBcheap\fR.
! .IP "\fB\-fsimd\-cost\-model=\fR\fImodel\fR" 4
  .IX Item "-fsimd-cost-model=model"
  Alter the cost model used for vectorization of loops marked with the OpenMP
  simd directive.  The \fImodel\fR argument should be one of
  \&\fBunlimited\fR, \fBdynamic\fR, \fBcheap\fR.  All values of \fImodel\fR
  have the same meaning as described in \fB\-fvect\-cost\-model\fR and by
  default a cost model defined with \fB\-fvect\-cost\-model\fR is used.
! .IP "\fB\-ftree\-vrp\fR" 4
  .IX Item "-ftree-vrp"
  Perform Value Range Propagation on trees.  This is similar to the
  constant propagation pass, but instead of values, ranges of values are
--- 12405,12440 ----
  You can control this behavior for a specific variable by using the variable
  attribute \f(CW\*(C`uninitialized\*(C'\fR.
  .RE
! .IP \fB\-fvect\-cost\-model=\fR\fImodel\fR 4
  .IX Item "-fvect-cost-model=model"
  Alter the cost model used for vectorization.  The \fImodel\fR argument
  should be one of \fBunlimited\fR, \fBdynamic\fR, \fBcheap\fR or
! \&\fBvery\-cheap\fR.
! With the \fBunlimited\fR model the vectorized code\-path is assumed
  to be profitable while with the \fBdynamic\fR model a runtime check
! guards the vectorized code\-path to enable it only for iteration
  counts that will likely execute faster than when executing the original
  scalar loop.  The \fBcheap\fR model disables vectorization of
  loops where doing so would be cost prohibitive for example due to
  required runtime checks for data dependence or alignment but otherwise
! is equal to the \fBdynamic\fR model.  The \fBvery\-cheap\fR model only
  allows vectorization if the vector code would entirely replace the
  scalar code that is being vectorized.  For example, if each iteration
  of a vectorized loop would only be able to handle exactly four iterations
! of the scalar loop, the \fBvery\-cheap\fR model would only allow
  vectorization if the scalar iteration count is known to be a multiple
  of four.
  .Sp
  The default cost model depends on other optimization flags and is
  either \fBdynamic\fR or \fBcheap\fR.
! .IP \fB\-fsimd\-cost\-model=\fR\fImodel\fR 4
  .IX Item "-fsimd-cost-model=model"
  Alter the cost model used for vectorization of loops marked with the OpenMP
  simd directive.  The \fImodel\fR argument should be one of
  \&\fBunlimited\fR, \fBdynamic\fR, \fBcheap\fR.  All values of \fImodel\fR
  have the same meaning as described in \fB\-fvect\-cost\-model\fR and by
  default a cost model defined with \fB\-fvect\-cost\-model\fR is used.
! .IP \fB\-ftree\-vrp\fR 4
  .IX Item "-ftree-vrp"
  Perform Value Range Propagation on trees.  This is similar to the
  constant propagation pass, but instead of values, ranges of values are
*************** checks like array bound checks and null
*** 12514,12551 ****
  enabled by default at \fB\-O2\fR and higher.  Null pointer check
  elimination is only done if \fB\-fdelete\-null\-pointer\-checks\fR is
  enabled.
! .IP "\fB\-fsplit\-paths\fR" 4
  .IX Item "-fsplit-paths"
  Split paths leading to loop backedges.  This can improve dead code
  elimination and common subexpression elimination.  This is enabled by
  default at \fB\-O3\fR and above.
! .IP "\fB\-fsplit\-ivs\-in\-unroller\fR" 4
  .IX Item "-fsplit-ivs-in-unroller"
  Enables expression of values of induction variables in later iterations
  of the unrolled loop using the value in the first iteration.  This breaks
  long dependency chains, thus improving efficiency of the scheduling passes.
  .Sp
! A combination of \fB\-fweb\fR and \s-1CSE\s0 is often sufficient to obtain the
  same effect.  However, that is not reliable in cases where the loop body
  is more complicated than a single basic block.  It also does not work at all
! on some architectures due to restrictions in the \s-1CSE\s0 pass.
  .Sp
  This optimization is enabled by default.
! .IP "\fB\-fvariable\-expansion\-in\-unroller\fR" 4
  .IX Item "-fvariable-expansion-in-unroller"
  With this option, the compiler creates multiple copies of some
  local variables when unrolling a loop, which can result in superior code.
  .Sp
  This optimization is enabled by default for PowerPC targets, but disabled
  by default otherwise.
! .IP "\fB\-fpartial\-inlining\fR" 4
  .IX Item "-fpartial-inlining"
  Inline parts of functions.  This option has any effect only
  when inlining itself is turned on by the \fB\-finline\-functions\fR
  or \fB\-finline\-small\-functions\fR options.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fpredictive\-commoning\fR" 4
  .IX Item "-fpredictive-commoning"
  Perform predictive commoning optimization, i.e., reusing computations
  (especially memory loads and stores) performed in previous
--- 12443,12480 ----
  enabled by default at \fB\-O2\fR and higher.  Null pointer check
  elimination is only done if \fB\-fdelete\-null\-pointer\-checks\fR is
  enabled.
! .IP \fB\-fsplit\-paths\fR 4
  .IX Item "-fsplit-paths"
  Split paths leading to loop backedges.  This can improve dead code
  elimination and common subexpression elimination.  This is enabled by
  default at \fB\-O3\fR and above.
! .IP \fB\-fsplit\-ivs\-in\-unroller\fR 4
  .IX Item "-fsplit-ivs-in-unroller"
  Enables expression of values of induction variables in later iterations
  of the unrolled loop using the value in the first iteration.  This breaks
  long dependency chains, thus improving efficiency of the scheduling passes.
  .Sp
! A combination of \fB\-fweb\fR and CSE is often sufficient to obtain the
  same effect.  However, that is not reliable in cases where the loop body
  is more complicated than a single basic block.  It also does not work at all
! on some architectures due to restrictions in the CSE pass.
  .Sp
  This optimization is enabled by default.
! .IP \fB\-fvariable\-expansion\-in\-unroller\fR 4
  .IX Item "-fvariable-expansion-in-unroller"
  With this option, the compiler creates multiple copies of some
  local variables when unrolling a loop, which can result in superior code.
  .Sp
  This optimization is enabled by default for PowerPC targets, but disabled
  by default otherwise.
! .IP \fB\-fpartial\-inlining\fR 4
  .IX Item "-fpartial-inlining"
  Inline parts of functions.  This option has any effect only
  when inlining itself is turned on by the \fB\-finline\-functions\fR
  or \fB\-finline\-small\-functions\fR options.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fpredictive\-commoning\fR 4
  .IX Item "-fpredictive-commoning"
  Perform predictive commoning optimization, i.e., reusing computations
  (especially memory loads and stores) performed in previous
*************** iterations of loops.
*** 12553,12559 ****
  .Sp
  This option is enabled at level \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-fprefetch\-loop\-arrays\fR" 4
  .IX Item "-fprefetch-loop-arrays"
  If supported by the target machine, generate instructions to prefetch
  memory to improve the performance of loops that access large arrays.
--- 12482,12488 ----
  .Sp
  This option is enabled at level \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-fprefetch\-loop\-arrays\fR 4
  .IX Item "-fprefetch-loop-arrays"
  If supported by the target machine, generate instructions to prefetch
  memory to improve the performance of loops that access large arrays.
*************** This option may generate better or worse
*** 12562,12573 ****
  dependent on the structure of loops within the source code.
  .Sp
  Disabled at level \fB\-Os\fR.
! .IP "\fB\-fno\-printf\-return\-value\fR" 4
  .IX Item "-fno-printf-return-value"
  Do not substitute constants for known return value of formatted output
  functions such as \f(CW\*(C`sprintf\*(C'\fR, \f(CW\*(C`snprintf\*(C'\fR, \f(CW\*(C`vsprintf\*(C'\fR, and
  \&\f(CW\*(C`vsnprintf\*(C'\fR (but not \f(CW\*(C`printf\*(C'\fR of \f(CW\*(C`fprintf\*(C'\fR).  This
! transformation allows \s-1GCC\s0 to optimize or even eliminate branches based
  on the known return value of these functions called with arguments that
  are either constant, or whose values are known to be in a range that
  makes determining the exact return value possible.  For example, when
--- 12491,12502 ----
  dependent on the structure of loops within the source code.
  .Sp
  Disabled at level \fB\-Os\fR.
! .IP \fB\-fno\-printf\-return\-value\fR 4
  .IX Item "-fno-printf-return-value"
  Do not substitute constants for known return value of formatted output
  functions such as \f(CW\*(C`sprintf\*(C'\fR, \f(CW\*(C`snprintf\*(C'\fR, \f(CW\*(C`vsprintf\*(C'\fR, and
  \&\f(CW\*(C`vsnprintf\*(C'\fR (but not \f(CW\*(C`printf\*(C'\fR of \f(CW\*(C`fprintf\*(C'\fR).  This
! transformation allows GCC to optimize or even eliminate branches based
  on the known return value of these functions called with arguments that
  are either constant, or whose values are known to be in a range that
  makes determining the exact return value possible.  For example, when
*************** The \fB\-fprintf\-return\-value\fR optio
*** 12586,12609 ****
  and yields best results with \fB\-O2\fR and above.  It works in tandem
  with the \fB\-Wformat\-overflow\fR and \fB\-Wformat\-truncation\fR
  options.  The \fB\-fprintf\-return\-value\fR option is enabled by default.
! .IP "\fB\-fno\-peephole\fR" 4
  .IX Item "-fno-peephole"
  .PD 0
! .IP "\fB\-fno\-peephole2\fR" 4
  .IX Item "-fno-peephole2"
  .PD
! Disable any machine-specific peephole optimizations.  The difference
  between \fB\-fno\-peephole\fR and \fB\-fno\-peephole2\fR is in how they
  are implemented in the compiler; some targets use one, some use the
  other, a few use both.
  .Sp
  \&\fB\-fpeephole\fR is enabled by default.
  \&\fB\-fpeephole2\fR enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fno\-guess\-branch\-probability\fR" 4
  .IX Item "-fno-guess-branch-probability"
  Do not guess branch probabilities using heuristics.
  .Sp
! \&\s-1GCC\s0 uses heuristics to guess branch probabilities if they are
  not provided by profiling feedback (\fB\-fprofile\-arcs\fR).  These
  heuristics are based on the control flow graph.  If some branch probabilities
  are specified by \f(CW\*(C`_\|_builtin_expect\*(C'\fR, then the heuristics are
--- 12515,12538 ----
  and yields best results with \fB\-O2\fR and above.  It works in tandem
  with the \fB\-Wformat\-overflow\fR and \fB\-Wformat\-truncation\fR
  options.  The \fB\-fprintf\-return\-value\fR option is enabled by default.
! .IP \fB\-fno\-peephole\fR 4
  .IX Item "-fno-peephole"
  .PD 0
! .IP \fB\-fno\-peephole2\fR 4
  .IX Item "-fno-peephole2"
  .PD
! Disable any machine\-specific peephole optimizations.  The difference
  between \fB\-fno\-peephole\fR and \fB\-fno\-peephole2\fR is in how they
  are implemented in the compiler; some targets use one, some use the
  other, a few use both.
  .Sp
  \&\fB\-fpeephole\fR is enabled by default.
  \&\fB\-fpeephole2\fR enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fno\-guess\-branch\-probability\fR 4
  .IX Item "-fno-guess-branch-probability"
  Do not guess branch probabilities using heuristics.
  .Sp
! GCC uses heuristics to guess branch probabilities if they are
  not provided by profiling feedback (\fB\-fprofile\-arcs\fR).  These
  heuristics are based on the control flow graph.  If some branch probabilities
  are specified by \f(CW\*(C`_\|_builtin_expect\*(C'\fR, then the heuristics are
*************** some cases, it may be useful to disable
*** 12614,12641 ****
  of \f(CW\*(C`_\|_builtin_expect\*(C'\fR are easier to understand.
  .Sp
  It is also possible to specify expected probability of the expression
! with \f(CW\*(C`_\|_builtin_expect_with_probability\*(C'\fR built-in function.
  .Sp
  The default is \fB\-fguess\-branch\-probability\fR at levels
  \&\fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-freorder\-blocks\fR" 4
  .IX Item "-freorder-blocks"
  Reorder basic blocks in the compiled function in order to reduce number of
  taken branches and improve code locality.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-freorder\-blocks\-algorithm=\fR\fIalgorithm\fR" 4
  .IX Item "-freorder-blocks-algorithm=algorithm"
  Use the specified algorithm for basic block reordering.  The
  \&\fIalgorithm\fR argument can be \fBsimple\fR, which does not increase
  code size (except sometimes due to secondary effects like alignment),
! or \fBstc\fR, the \*(L"software trace cache\*(R" algorithm, which tries to
  put all often executed code together, minimizing the number of branches
  executed by making extra copies of code.
  .Sp
  The default is \fBsimple\fR at levels \fB\-O1\fR, \fB\-Os\fR, and
  \&\fBstc\fR at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-freorder\-blocks\-and\-partition\fR" 4
  .IX Item "-freorder-blocks-and-partition"
  In addition to reordering basic blocks in the compiled function, in order
  to reduce number of taken branches, partitions hot and cold basic blocks
--- 12543,12570 ----
  of \f(CW\*(C`_\|_builtin_expect\*(C'\fR are easier to understand.
  .Sp
  It is also possible to specify expected probability of the expression
! with \f(CW\*(C`_\|_builtin_expect_with_probability\*(C'\fR built\-in function.
  .Sp
  The default is \fB\-fguess\-branch\-probability\fR at levels
  \&\fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-freorder\-blocks\fR 4
  .IX Item "-freorder-blocks"
  Reorder basic blocks in the compiled function in order to reduce number of
  taken branches and improve code locality.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-freorder\-blocks\-algorithm=\fR\fIalgorithm\fR 4
  .IX Item "-freorder-blocks-algorithm=algorithm"
  Use the specified algorithm for basic block reordering.  The
  \&\fIalgorithm\fR argument can be \fBsimple\fR, which does not increase
  code size (except sometimes due to secondary effects like alignment),
! or \fBstc\fR, the "software trace cache" algorithm, which tries to
  put all often executed code together, minimizing the number of branches
  executed by making extra copies of code.
  .Sp
  The default is \fBsimple\fR at levels \fB\-O1\fR, \fB\-Os\fR, and
  \&\fBstc\fR at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-freorder\-blocks\-and\-partition\fR 4
  .IX Item "-freorder-blocks-and-partition"
  In addition to reordering basic blocks in the compiled function, in order
  to reduce number of taken branches, partitions hot and cold basic blocks
*************** into separate sections of the assembly a
*** 12643,12656 ****
  paging and cache locality performance.
  .Sp
  This optimization is automatically turned off in the presence of
! exception handling or unwind tables (on targets using setjump/longjump or target specific scheme), for linkonce sections, for functions with a user-defined
  section attribute and on any architecture that does not support named
  sections.  When \fB\-fsplit\-stack\fR is used this option is not
  enabled by default (to avoid linker errors), but may be enabled
  explicitly (if using a working linker).
  .Sp
  Enabled for x86 at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-freorder\-functions\fR" 4
  .IX Item "-freorder-functions"
  Reorder functions in the object file in order to
  improve code locality.  This is implemented by using special
--- 12572,12585 ----
  paging and cache locality performance.
  .Sp
  This optimization is automatically turned off in the presence of
! exception handling or unwind tables (on targets using setjump/longjump or target specific scheme), for linkonce sections, for functions with a user\-defined
  section attribute and on any architecture that does not support named
  sections.  When \fB\-fsplit\-stack\fR is used this option is not
  enabled by default (to avoid linker errors), but may be enabled
  explicitly (if using a working linker).
  .Sp
  Enabled for x86 at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-freorder\-functions\fR 4
  .IX Item "-freorder-functions"
  Reorder functions in the object file in order to
  improve code locality.  This is implemented by using special
*************** subsections \f(CW\*(C`.text.hot\*(C'\fR
*** 12659,12673 ****
  the linker so object file format must support named sections and linker must
  place them in a reasonable way.
  .Sp
! This option isn't effective unless you either provide profile feedback
  (see \fB\-fprofile\-arcs\fR for details) or manually annotate functions with 
  \&\f(CW\*(C`hot\*(C'\fR or \f(CW\*(C`cold\*(C'\fR attributes.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fstrict\-aliasing\fR" 4
  .IX Item "-fstrict-aliasing"
  Allow the compiler to assume the strictest aliasing rules applicable to
! the language being compiled.  For C (and \*(C+), this activates
  optimizations based on the type of expressions.  In particular, an
  object of one type is assumed never to reside at the same address as an
  object of a different type, unless the types are almost the same.  For
--- 12588,12602 ----
  the linker so object file format must support named sections and linker must
  place them in a reasonable way.
  .Sp
! This option isn\*(Aqt effective unless you either provide profile feedback
  (see \fB\-fprofile\-arcs\fR for details) or manually annotate functions with 
  \&\f(CW\*(C`hot\*(C'\fR or \f(CW\*(C`cold\*(C'\fR attributes.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fstrict\-aliasing\fR 4
  .IX Item "-fstrict-aliasing"
  Allow the compiler to assume the strictest aliasing rules applicable to
! the language being compiled.  For C (and C++), this activates
  optimizations based on the type of expressions.  In particular, an
  object of one type is assumed never to reside at the same address as an
  object of a different type, unless the types are almost the same.  For
*************** Pay special attention to code like this:
*** 12691,12698 ****
  .Ve
  .Sp
  The practice of reading from a different union member than the one most
! recently written to (called \*(L"type-punning\*(R") is common.  Even with
! \&\fB\-fstrict\-aliasing\fR, type-punning is allowed, provided the memory
  is accessed through the union type.  So, the code above works as
  expected.    However, this code might not:
  .Sp
--- 12620,12627 ----
  .Ve
  .Sp
  The practice of reading from a different union member than the one most
! recently written to (called "type\-punning") is common.  Even with
! \&\fB\-fstrict\-aliasing\fR, type\-punning is allowed, provided the memory
  is accessed through the union type.  So, the code above works as
  expected.    However, this code might not:
  .Sp
*************** uses a union type, e.g.:
*** 12719,12725 ****
  .Sp
  The \fB\-fstrict\-aliasing\fR option is enabled at levels
  \&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fipa\-strict\-aliasing\fR" 4
  .IX Item "-fipa-strict-aliasing"
  Controls whether rules of \fB\-fstrict\-aliasing\fR are applied across
  function boundaries.  Note that if multiple functions gets inlined into a
--- 12648,12654 ----
  .Sp
  The \fB\-fstrict\-aliasing\fR option is enabled at levels
  \&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fipa\-strict\-aliasing\fR 4
  .IX Item "-fipa-strict-aliasing"
  Controls whether rules of \fB\-fstrict\-aliasing\fR are applied across
  function boundaries.  Note that if multiple functions gets inlined into a
*************** function boundary.
*** 12728,12748 ****
  .Sp
  The \fB\-fipa\-strict\-aliasing\fR option is enabled by default and is
  effective only in combination with \fB\-fstrict\-aliasing\fR.
! .IP "\fB\-falign\-functions\fR" 4
  .IX Item "-falign-functions"
  .PD 0
! .IP "\fB\-falign\-functions=\fR\fIn\fR" 4
  .IX Item "-falign-functions=n"
! .IP "\fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR" 4
  .IX Item "-falign-functions=n:m"
! .IP "\fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR" 4
  .IX Item "-falign-functions=n:m:n2"
! .IP "\fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR" 4
  .IX Item "-falign-functions=n:m:n2:m2"
  .PD
! Align the start of functions to the next power-of-two greater than or
  equal to \fIn\fR, skipping up to \fIm\fR\-1 bytes.  This ensures that at
! least the first \fIm\fR bytes of the function can be fetched by the \s-1CPU\s0
  without crossing an \fIn\fR\-byte alignment boundary.
  .Sp
  If \fIm\fR is not specified, it defaults to \fIn\fR.
--- 12657,12677 ----
  .Sp
  The \fB\-fipa\-strict\-aliasing\fR option is enabled by default and is
  effective only in combination with \fB\-fstrict\-aliasing\fR.
! .IP \fB\-falign\-functions\fR 4
  .IX Item "-falign-functions"
  .PD 0
! .IP \fB\-falign\-functions=\fR\fIn\fR 4
  .IX Item "-falign-functions=n"
! .IP \fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR 4
  .IX Item "-falign-functions=n:m"
! .IP \fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR 4
  .IX Item "-falign-functions=n:m:n2"
! .IP \fB\-falign\-functions=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR 4
  .IX Item "-falign-functions=n:m:n2:m2"
  .PD
! Align the start of functions to the next power\-of\-two greater than or
  equal to \fIn\fR, skipping up to \fIm\fR\-1 bytes.  This ensures that at
! least the first \fIm\fR bytes of the function can be fetched by the CPU
  without crossing an \fIn\fR\-byte alignment boundary.
  .Sp
  If \fIm\fR is not specified, it defaults to \fIn\fR.
*************** in that case, it is rounded up.
*** 12766,12794 ****
  \&\fB\-fno\-align\-functions\fR and \fB\-falign\-functions=1\fR are
  equivalent and mean that functions are not aligned.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine-dependent default.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-flimit\-function\-alignment\fR" 4
  .IX Item "-flimit-function-alignment"
  If this option is enabled, the compiler tries to avoid unnecessarily
  overaligning functions. It attempts to instruct the assembler to align
  by the amount specified by \fB\-falign\-functions\fR, but not to
  skip more bytes than the size of the function.
! .IP "\fB\-falign\-labels\fR" 4
  .IX Item "-falign-labels"
  .PD 0
! .IP "\fB\-falign\-labels=\fR\fIn\fR" 4
  .IX Item "-falign-labels=n"
! .IP "\fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR" 4
  .IX Item "-falign-labels=n:m"
! .IP "\fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR" 4
  .IX Item "-falign-labels=n:m:n2"
! .IP "\fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR" 4
  .IX Item "-falign-labels=n:m:n2:m2"
  .PD
! Align all branch targets to a power-of-two boundary.
  .Sp
  Parameters of this option are analogous to the \fB\-falign\-functions\fR option.
  \&\fB\-fno\-align\-labels\fR and \fB\-falign\-labels=1\fR are
--- 12695,12723 ----
  \&\fB\-fno\-align\-functions\fR and \fB\-falign\-functions=1\fR are
  equivalent and mean that functions are not aligned.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine\-dependent default.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-flimit\-function\-alignment\fR 4
  .IX Item "-flimit-function-alignment"
  If this option is enabled, the compiler tries to avoid unnecessarily
  overaligning functions. It attempts to instruct the assembler to align
  by the amount specified by \fB\-falign\-functions\fR, but not to
  skip more bytes than the size of the function.
! .IP \fB\-falign\-labels\fR 4
  .IX Item "-falign-labels"
  .PD 0
! .IP \fB\-falign\-labels=\fR\fIn\fR 4
  .IX Item "-falign-labels=n"
! .IP \fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR 4
  .IX Item "-falign-labels=n:m"
! .IP \fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR 4
  .IX Item "-falign-labels=n:m:n2"
! .IP \fB\-falign\-labels=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR 4
  .IX Item "-falign-labels=n:m:n2:m2"
  .PD
! Align all branch targets to a power\-of\-two boundary.
  .Sp
  Parameters of this option are analogous to the \fB\-falign\-functions\fR option.
  \&\fB\-fno\-align\-labels\fR and \fB\-falign\-labels=1\fR are
*************** equivalent and mean that labels are not
*** 12797,12820 ****
  If \fB\-falign\-loops\fR or \fB\-falign\-jumps\fR are applicable and
  are greater than this value, then their values are used instead.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine-dependent default
  which is very likely to be \fB1\fR, meaning no alignment.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-falign\-loops\fR" 4
  .IX Item "-falign-loops"
  .PD 0
! .IP "\fB\-falign\-loops=\fR\fIn\fR" 4
  .IX Item "-falign-loops=n"
! .IP "\fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR" 4
  .IX Item "-falign-loops=n:m"
! .IP "\fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR" 4
  .IX Item "-falign-loops=n:m:n2"
! .IP "\fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR" 4
  .IX Item "-falign-loops=n:m:n2:m2"
  .PD
! Align loops to a power-of-two boundary.  If the loops are executed
  many times, this makes up for any execution of the dummy padding
  instructions.
  .Sp
--- 12726,12749 ----
  If \fB\-falign\-loops\fR or \fB\-falign\-jumps\fR are applicable and
  are greater than this value, then their values are used instead.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine\-dependent default
  which is very likely to be \fB1\fR, meaning no alignment.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-falign\-loops\fR 4
  .IX Item "-falign-loops"
  .PD 0
! .IP \fB\-falign\-loops=\fR\fIn\fR 4
  .IX Item "-falign-loops=n"
! .IP \fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR 4
  .IX Item "-falign-loops=n:m"
! .IP \fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR 4
  .IX Item "-falign-loops=n:m:n2"
! .IP \fB\-falign\-loops=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR 4
  .IX Item "-falign-loops=n:m:n2:m2"
  .PD
! Align loops to a power\-of\-two boundary.  If the loops are executed
  many times, this makes up for any execution of the dummy padding
  instructions.
  .Sp
*************** Parameters of this option are analogous
*** 12826,12847 ****
  equivalent and mean that loops are not aligned.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine-dependent default.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-falign\-jumps\fR" 4
  .IX Item "-falign-jumps"
  .PD 0
! .IP "\fB\-falign\-jumps=\fR\fIn\fR" 4
  .IX Item "-falign-jumps=n"
! .IP "\fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR" 4
  .IX Item "-falign-jumps=n:m"
! .IP "\fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR" 4
  .IX Item "-falign-jumps=n:m:n2"
! .IP "\fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR" 4
  .IX Item "-falign-jumps=n:m:n2:m2"
  .PD
! Align branch targets to a power-of-two boundary, for branch targets
  where the targets can only be reached by jumping.  In this case,
  no dummy operations need be executed.
  .Sp
--- 12755,12776 ----
  equivalent and mean that loops are not aligned.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine\-dependent default.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-falign\-jumps\fR 4
  .IX Item "-falign-jumps"
  .PD 0
! .IP \fB\-falign\-jumps=\fR\fIn\fR 4
  .IX Item "-falign-jumps=n"
! .IP \fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR 4
  .IX Item "-falign-jumps=n:m"
! .IP \fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR 4
  .IX Item "-falign-jumps=n:m:n2"
! .IP \fB\-falign\-jumps=\fR\fIn\fR\fB:\fR\fIm\fR\fB:\fR\fIn2\fR\fB:\fR\fIm2\fR 4
  .IX Item "-falign-jumps=n:m:n2:m2"
  .PD
! Align branch targets to a power\-of\-two boundary, for branch targets
  where the targets can only be reached by jumping.  In this case,
  no dummy operations need be executed.
  .Sp
*************** Parameters of this option are analogous
*** 12852,12865 ****
  \&\fB\-fno\-align\-jumps\fR and \fB\-falign\-jumps=1\fR are
  equivalent and mean that loops are not aligned.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine-dependent default.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP "\fB\-fno\-allocation\-dce\fR" 4
  .IX Item "-fno-allocation-dce"
! Do not remove unused \*(C+ allocations in dead code elimination.
! .IP "\fB\-fallow\-store\-data\-races\fR" 4
  .IX Item "-fallow-store-data-races"
  Allow the compiler to perform optimizations that may introduce new data races
  on stores, without proving that the variable cannot be concurrently accessed
--- 12781,12794 ----
  \&\fB\-fno\-align\-jumps\fR and \fB\-falign\-jumps=1\fR are
  equivalent and mean that loops are not aligned.
  .Sp
! If \fIn\fR is not specified or is zero, use a machine\-dependent default.
  The maximum allowed \fIn\fR option value is 65536.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
! .IP \fB\-fno\-allocation\-dce\fR 4
  .IX Item "-fno-allocation-dce"
! Do not remove unused C++ allocations in dead code elimination.
! .IP \fB\-fallow\-store\-data\-races\fR 4
  .IX Item "-fallow-store-data-races"
  Allow the compiler to perform optimizations that may introduce new data races
  on stores, without proving that the variable cannot be concurrently accessed
*************** use this option if it is known that glob
*** 12868,12890 ****
  multiple threads.
  .Sp
  Examples of optimizations enabled by \fB\-fallow\-store\-data\-races\fR include
! hoisting or if-conversions that may cause a value that was already in memory
! to be re-written with that same value.  Such re-writing is safe in a single
! threaded context but may be unsafe in a multi-threaded context.  Note that on
! some processors, if-conversions may be required in order to enable
  vectorization.
  .Sp
  Enabled at level \fB\-Ofast\fR.
! .IP "\fB\-funit\-at\-a\-time\fR" 4
  .IX Item "-funit-at-a-time"
  This option is left for compatibility reasons. \fB\-funit\-at\-a\-time\fR
  has no effect, while \fB\-fno\-unit\-at\-a\-time\fR implies
  \&\fB\-fno\-toplevel\-reorder\fR and \fB\-fno\-section\-anchors\fR.
  .Sp
  Enabled by default.
! .IP "\fB\-fno\-toplevel\-reorder\fR" 4
  .IX Item "-fno-toplevel-reorder"
! Do not reorder top-level functions, variables, and \f(CW\*(C`asm\*(C'\fR
  statements.  Output them in the same order that they appear in the
  input file.  When this option is used, unreferenced static variables
  are not removed.  This option is intended to support existing code
--- 12797,12819 ----
  multiple threads.
  .Sp
  Examples of optimizations enabled by \fB\-fallow\-store\-data\-races\fR include
! hoisting or if\-conversions that may cause a value that was already in memory
! to be re\-written with that same value.  Such re\-writing is safe in a single
! threaded context but may be unsafe in a multi\-threaded context.  Note that on
! some processors, if\-conversions may be required in order to enable
  vectorization.
  .Sp
  Enabled at level \fB\-Ofast\fR.
! .IP \fB\-funit\-at\-a\-time\fR 4
  .IX Item "-funit-at-a-time"
  This option is left for compatibility reasons. \fB\-funit\-at\-a\-time\fR
  has no effect, while \fB\-fno\-unit\-at\-a\-time\fR implies
  \&\fB\-fno\-toplevel\-reorder\fR and \fB\-fno\-section\-anchors\fR.
  .Sp
  Enabled by default.
! .IP \fB\-fno\-toplevel\-reorder\fR 4
  .IX Item "-fno-toplevel-reorder"
! Do not reorder top\-level functions, variables, and \f(CW\*(C`asm\*(C'\fR
  statements.  Output them in the same order that they appear in the
  input file.  When this option is used, unreferenced static variables
  are not removed.  This option is intended to support existing code
*************** use attributes when possible.
*** 12895,12901 ****
  also at \fB\-O0\fR if \fB\-fsection\-anchors\fR is explicitly requested.
  Additionally \fB\-fno\-toplevel\-reorder\fR implies
  \&\fB\-fno\-section\-anchors\fR.
! .IP "\fB\-funreachable\-traps\fR" 4
  .IX Item "-funreachable-traps"
  With this option, the compiler turns calls to
  \&\f(CW\*(C`_\|_builtin_unreachable\*(C'\fR into traps, instead of using them for
--- 12824,12830 ----
  also at \fB\-O0\fR if \fB\-fsection\-anchors\fR is explicitly requested.
  Additionally \fB\-fno\-toplevel\-reorder\fR implies
  \&\fB\-fno\-section\-anchors\fR.
! .IP \fB\-funreachable\-traps\fR 4
  .IX Item "-funreachable-traps"
  With this option, the compiler turns calls to
  \&\f(CW\*(C`_\|_builtin_unreachable\*(C'\fR into traps, instead of using them for
*************** options.  If \fB\-fsanitize=unreachable\
*** 12908,12924 ****
  takes priority over this one.
  .Sp
  This option is enabled by default at \fB\-O0\fR and \fB\-Og\fR.
! .IP "\fB\-fweb\fR" 4
  .IX Item "-fweb"
  Constructs webs as commonly used for register allocation purposes and assign
  each web individual pseudo register.  This allows the register allocation pass
  to operate on pseudos directly, but also strengthens several other optimization
! passes, such as \s-1CSE,\s0 loop optimizer and trivial dead code remover.  It can,
  however, make debugging impossible, since variables no longer stay in a
! \&\*(L"home register\*(R".
  .Sp
  Enabled by default with \fB\-funroll\-loops\fR.
! .IP "\fB\-fwhole\-program\fR" 4
  .IX Item "-fwhole-program"
  Assume that the current compilation unit represents the whole program being
  compiled.  All public functions and variables with the exception of \f(CW\*(C`main\*(C'\fR
--- 12837,12853 ----
  takes priority over this one.
  .Sp
  This option is enabled by default at \fB\-O0\fR and \fB\-Og\fR.
! .IP \fB\-fweb\fR 4
  .IX Item "-fweb"
  Constructs webs as commonly used for register allocation purposes and assign
  each web individual pseudo register.  This allows the register allocation pass
  to operate on pseudos directly, but also strengthens several other optimization
! passes, such as CSE, loop optimizer and trivial dead code remover.  It can,
  however, make debugging impossible, since variables no longer stay in a
! "home register".
  .Sp
  Enabled by default with \fB\-funroll\-loops\fR.
! .IP \fB\-fwhole\-program\fR 4
  .IX Item "-fwhole-program"
  Assume that the current compilation unit represents the whole program being
  compiled.  All public functions and variables with the exception of \f(CW\*(C`main\*(C'\fR
*************** and in effect are optimized more aggress
*** 12927,12946 ****
  .Sp
  With \fB\-flto\fR this option has a limited use.  In most cases the
  precise list of symbols used or exported from the binary is known the
! resolution info passed to the link-time optimizer by the linker plugin.  It is
  still useful if no linker plugin is used or during incremental link step when
  final code is produced (with \fB\-flto\fR
  \&\fB\-flinker\-output=nolto\-rel\fR).
! .IP "\fB\-flto[=\fR\fIn\fR\fB]\fR" 4
  .IX Item "-flto[=n]"
! This option runs the standard link-time optimizer.  When invoked
! with source code, it generates \s-1GIMPLE\s0 (one of \s-1GCC\s0's internal
! representations) and writes it to special \s-1ELF\s0 sections in the object
  file.  When the object files are linked together, all the function
! bodies are read from these \s-1ELF\s0 sections and instantiated as if they
  had been part of the same translation unit.
  .Sp
! To use the link-time optimizer, \fB\-flto\fR and optimization
  options should be specified at compile time and during the final link.
  It is recommended that you compile all the files participating in the
  same link with the same options and also specify those options at
--- 12856,12875 ----
  .Sp
  With \fB\-flto\fR this option has a limited use.  In most cases the
  precise list of symbols used or exported from the binary is known the
! resolution info passed to the link\-time optimizer by the linker plugin.  It is
  still useful if no linker plugin is used or during incremental link step when
  final code is produced (with \fB\-flto\fR
  \&\fB\-flinker\-output=nolto\-rel\fR).
! .IP \fB\-flto[=\fR\fIn\fR\fB]\fR 4
  .IX Item "-flto[=n]"
! This option runs the standard link\-time optimizer.  When invoked
! with source code, it generates GIMPLE (one of GCC\*(Aqs 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.
  .Sp
! To use the link\-time optimizer, \fB\-flto\fR and optimization
  options should be specified at compile time and during the final link.
  It is recommended that you compile all the files participating in the
  same link with the same options and also specify those options at
*************** For example:
*** 12953,12991 ****
  \&        gcc \-o myprog \-flto \-O2 foo.o bar.o
  .Ve
  .Sp
! The first two invocations to \s-1GCC\s0 save a bytecode representation
! of \s-1GIMPLE\s0 into special \s-1ELF\s0 sections inside \fIfoo.o\fR and
! \&\fIbar.o\fR.  The final invocation reads the \s-1GIMPLE\s0 bytecode from
  \&\fIfoo.o\fR and \fIbar.o\fR, merges the two files into a single
  internal image, and compiles the result as usual.  Since both
  \&\fIfoo.o\fR and \fIbar.o\fR are merged into a single image, this
! causes all the interprocedural analyses and optimizations in \s-1GCC\s0 to
  work across the two files as if they were a single one.  This means,
  for example, that the inliner is able to inline functions in
! \&\fIbar.o\fR into functions in \fIfoo.o\fR and vice-versa.
  .Sp
! Another (simpler) way to enable link-time optimization is:
  .Sp
  .Vb 1
  \&        gcc \-o myprog \-flto \-O2 foo.c bar.c
  .Ve
  .Sp
  The above generates bytecode for \fIfoo.c\fR and \fIbar.c\fR,
! merges them together into a single \s-1GIMPLE\s0 representation and optimizes
  them as usual to produce \fImyprog\fR.
  .Sp
! The important thing to keep in mind is that to enable link-time
! optimizations you need to use the \s-1GCC\s0 driver to perform the link step.
! \&\s-1GCC\s0 automatically performs link-time optimization if any of the
! objects involved were compiled with the \fB\-flto\fR command-line option.  
  You can always override
! the automatic decision to do link-time optimization
  by passing \fB\-fno\-lto\fR to the link command.
  .Sp
  To make whole program optimization effective, it is necessary to make
  certain whole program assumptions.  The compiler needs to know
  what functions and variables can be accessed by libraries and runtime
! outside of the link-time optimized unit.  When supported by the linker,
  the linker plugin (see \fB\-fuse\-linker\-plugin\fR) passes information
  to the compiler about used and externally visible symbols.  When
  the linker plugin is not available, \fB\-fwhole\-program\fR should be
--- 12882,12920 ----
  \&        gcc \-o myprog \-flto \-O2 foo.o bar.o
  .Ve
  .Sp
! The first two invocations to GCC save a bytecode representation
! of GIMPLE into special ELF sections inside \fIfoo.o\fR and
! \&\fIbar.o\fR.  The final invocation reads the GIMPLE bytecode from
  \&\fIfoo.o\fR and \fIbar.o\fR, merges the two files into a single
  internal image, and compiles the result as usual.  Since both
  \&\fIfoo.o\fR and \fIbar.o\fR are merged into a single image, this
! causes all the interprocedural analyses and optimizations in 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
! \&\fIbar.o\fR into functions in \fIfoo.o\fR and vice\-versa.
  .Sp
! Another (simpler) way to enable link\-time optimization is:
  .Sp
  .Vb 1
  \&        gcc \-o myprog \-flto \-O2 foo.c bar.c
  .Ve
  .Sp
  The above generates bytecode for \fIfoo.c\fR and \fIbar.c\fR,
! merges them together into a single GIMPLE representation and optimizes
  them as usual to produce \fImyprog\fR.
  .Sp
! The important thing to keep in mind is that to enable link\-time
! optimizations you need to use the GCC driver to perform the link step.
! GCC automatically performs link\-time optimization if any of the
! objects involved were compiled with the \fB\-flto\fR command\-line option.  
  You can always override
! the automatic decision to do link\-time optimization
  by passing \fB\-fno\-lto\fR to the link command.
  .Sp
  To make whole program optimization effective, it is necessary to make
  certain whole program assumptions.  The compiler needs to know
  what functions and variables can be accessed by libraries and runtime
! outside of the link\-time optimized unit.  When supported by the linker,
  the linker plugin (see \fB\-fuse\-linker\-plugin\fR) passes information
  to the compiler about used and externally visible symbols.  When
  the linker plugin is not available, \fB\-fwhole\-program\fR should be
*************** to more aggressive optimization decision
*** 12994,13020 ****
  .Sp
  When a file is compiled with \fB\-flto\fR without
  \&\fB\-fuse\-linker\-plugin\fR, the generated object file is larger than
! a regular object file because it contains \s-1GIMPLE\s0 bytecodes and the usual
  final code (see \fB\-ffat\-lto\-objects\fR).  This means that
! object files with \s-1LTO\s0 information can be linked as normal object
  files; if \fB\-fno\-lto\fR is passed to the linker, no
  interprocedural optimizations are applied.  Note that when
  \&\fB\-fno\-fat\-lto\-objects\fR is enabled the compile stage is faster
! but you cannot perform a regular, non-LTO link on them.
  .Sp
! When producing the final binary, \s-1GCC\s0 only
! applies link-time optimizations to those files that contain bytecode.
  Therefore, you can mix and match object files and libraries with
! \&\s-1GIMPLE\s0 bytecodes and final object code.  \s-1GCC\s0 automatically selects
! which files to optimize in \s-1LTO\s0 mode and which files to link without
  further processing.
  .Sp
  Generally, options specified at link time override those
! specified at compile time, although in some cases \s-1GCC\s0 attempts to infer
! link-time options from the settings used to compile the input files.
  .Sp
  If you do not specify an optimization level option \fB\-O\fR at
! link time, then \s-1GCC\s0 uses the highest optimization level 
  used when compiling the object files.  Note that it is generally 
  ineffective to specify an optimization level option only at link time and 
  not at compile time, for two reasons.  First, compiling without 
--- 12923,12949 ----
  .Sp
  When a file is compiled with \fB\-flto\fR without
  \&\fB\-fuse\-linker\-plugin\fR, the generated object file is larger than
! a regular object file because it contains GIMPLE bytecodes and the usual
  final code (see \fB\-ffat\-lto\-objects\fR).  This means that
! object files with LTO information can be linked as normal object
  files; if \fB\-fno\-lto\fR is passed to the linker, no
  interprocedural optimizations are applied.  Note that when
  \&\fB\-fno\-fat\-lto\-objects\fR is enabled the compile stage is faster
! but you cannot perform a regular, non\-LTO link on them.
  .Sp
! When producing the final binary, GCC only
! applies link\-time optimizations to those files that contain bytecode.
  Therefore, you can mix and match object files and libraries with
! GIMPLE bytecodes and final object code.  GCC automatically selects
! which files to optimize in LTO mode and which files to link without
  further processing.
  .Sp
  Generally, options specified at link time override those
! specified at compile time, although in some cases GCC attempts to infer
! link\-time options from the settings used to compile the input files.
  .Sp
  If you do not specify an optimization level option \fB\-O\fR at
! link time, then GCC uses the highest optimization level 
  used when compiling the object files.  Note that it is generally 
  ineffective to specify an optimization level option only at link time and 
  not at compile time, for two reasons.  First, compiling without 
*************** needed for effective optimization at lin
*** 13023,13029 ****
  optimization passes can be performed only at compile time and 
  not at link time.
  .Sp
! There are some code generation flags preserved by \s-1GCC\s0 when
  generating bytecodes, as they need to be used during the final link.
  Currently, the following options and their settings are taken from
  the first object file that explicitly specifies them: 
--- 12952,12958 ----
  optimization passes can be performed only at compile time and 
  not at link time.
  .Sp
! There are some code generation flags preserved by GCC when
  generating bytecodes, as they need to be used during the final link.
  Currently, the following options and their settings are taken from
  the first object file that explicitly specifies them: 
*************** The following options \fB\-fPIC\fR, \fB\
*** 13042,13048 ****
  \&        B<\-fPIC/\-fpic> + B<\-fpie> = B<\-fpie>
  .Ve
  .Sp
! Certain ABI-changing flags are required to match in all compilation units,
  and trying to override this at link time with a conflicting value
  is ignored.  This includes options such as \fB\-freg\-struct\-return\fR
  and \fB\-fpcc\-struct\-return\fR.
--- 12971,12977 ----
  \&        B<\-fPIC/\-fpic> + B<\-fpie> = B<\-fpie>
  .Ve
  .Sp
! Certain ABI\-changing flags are required to match in all compilation units,
  and trying to override this at link time with a conflicting value
  is ignored.  This includes options such as \fB\-freg\-struct\-return\fR
  and \fB\-fpcc\-struct\-return\fR.
*************** over \fB\-ffp\-contract=fast\fR.  You ca
*** 13057,13063 ****
  .Sp
  Diagnostic options such as \fB\-Wstringop\-overflow\fR are passed
  through to the link stage and their setting matches that of the
! compile-step at function granularity.  Note that this matters only
  for diagnostics emitted during optimization.  Note that code
  transforms such as inlining can lead to warnings being enabled
  or disabled for regions if code not consistent with the setting
--- 12986,12992 ----
  .Sp
  Diagnostic options such as \fB\-Wstringop\-overflow\fR are passed
  through to the link stage and their setting matches that of the
! compile\-step at function granularity.  Note that this matters only
  for diagnostics emitted during optimization.  Note that code
  transforms such as inlining can lead to warnings being enabled
  or disabled for regions if code not consistent with the setting
*************** When you need to pass options to the ass
*** 13067,13073 ****
  \&\fB\-Xassembler\fR make sure to either compile such translation
  units with \fB\-fno\-lto\fR or consistently use the same assembler
  options on all translation units.  You can alternatively also
! specify assembler options at \s-1LTO\s0 link time.
  .Sp
  To enable debug info generation you need to supply \fB\-g\fR at
  compile time.  If any of the input files at link time were built
--- 12996,13002 ----
  \&\fB\-Xassembler\fR make sure to either compile such translation
  units with \fB\-fno\-lto\fR or consistently use the same assembler
  options on all translation units.  You can alternatively also
! specify assembler options at LTO link time.
  .Sp
  To enable debug info generation you need to supply \fB\-g\fR at
  compile time.  If any of the input files at link time were built
*************** like the dwarf level \fB\-gdwarf\-5\fR n
*** 13077,13089 ****
  at the linker command line and mixing different settings in different
  translation units is discouraged.
  .Sp
! If \s-1LTO\s0 encounters objects with C linkage declared with incompatible
  types in separate translation units to be linked together (undefined
! behavior according to \s-1ISO C99 6.2.7\s0), a non-fatal diagnostic may be
  issued.  The behavior is still undefined at run time.  Similar
  diagnostics may be raised for other languages.
  .Sp
! Another feature of \s-1LTO\s0 is that it is possible to apply interprocedural
  optimizations on files written in different languages:
  .Sp
  .Vb 4
--- 13006,13018 ----
  at the linker command line and mixing different settings in different
  translation units is discouraged.
  .Sp
! If LTO encounters objects with C linkage declared with incompatible
  types in separate translation units to be linked together (undefined
! behavior according to ISO C99 6.2.7), a non\-fatal diagnostic may be
  issued.  The behavior is still undefined at run time.  Similar
  diagnostics may be raised for other languages.
  .Sp
! Another feature of LTO is that it is possible to apply interprocedural
  optimizations on files written in different languages:
  .Sp
  .Vb 4
*************** optimizations on files written in differ
*** 13093,13131 ****
  \&        g++ \-o myprog \-flto \-O3 foo.o bar.o baz.o \-lgfortran
  .Ve
  .Sp
! Notice that the final link is done with \fBg++\fR to get the \*(C+
  runtime libraries and \fB\-lgfortran\fR is added to get the Fortran
! runtime libraries.  In general, when mixing languages in \s-1LTO\s0 mode, you
  should use the same link command options as when mixing languages in a
! regular (non-LTO) compilation.
  .Sp
! If object files containing \s-1GIMPLE\s0 bytecode are stored in a library archive, say
! \&\fIlibfoo.a\fR, it is possible to extract and use them in an \s-1LTO\s0 link if you
  are using a linker with plugin support.  To create static libraries suitable
! for \s-1LTO,\s0 use \fBgcc-ar\fR and \fBgcc-ranlib\fR instead of \fBar\fR
  and \fBranlib\fR; 
! to show the symbols of object files with \s-1GIMPLE\s0 bytecode, use
! \&\fBgcc-nm\fR.  Those commands require that \fBar\fR, \fBranlib\fR
  and \fBnm\fR have been compiled with plugin support.  At link time, use the
  flag \fB\-fuse\-linker\-plugin\fR to ensure that the library participates in
! the \s-1LTO\s0 optimization process:
  .Sp
  .Vb 1
  \&        gcc \-o myprog \-O2 \-flto \-fuse\-linker\-plugin a.o b.o \-lfoo
  .Ve
  .Sp
  With the linker plugin enabled, the linker extracts the needed
! \&\s-1GIMPLE\s0 files from \fIlibfoo.a\fR and passes them on to the running \s-1GCC\s0
! to make them part of the aggregated \s-1GIMPLE\s0 image to be optimized.
  .Sp
  If you are not using a linker with plugin support and/or do not
  enable the linker plugin, then the objects inside \fIlibfoo.a\fR
  are extracted and linked as usual, but they do not participate
! in the \s-1LTO\s0 optimization process.  In order to make a static library suitable
! for both \s-1LTO\s0 optimization and usual linkage, compile its object files with
  \&\fB\-flto\fR \fB\-ffat\-lto\-objects\fR.
  .Sp
! Link-time optimizations do not require the presence of the whole program to
  operate.  If the program does not require any symbols to be exported, it is
  possible to combine \fB\-flto\fR and \fB\-fwhole\-program\fR to allow
  the interprocedural optimizers to use more aggressive assumptions which may
--- 13022,13060 ----
  \&        g++ \-o myprog \-flto \-O3 foo.o bar.o baz.o \-lgfortran
  .Ve
  .Sp
! Notice that the final link is done with \fBg++\fR to get the C++
  runtime libraries and \fB\-lgfortran\fR is added to get the Fortran
! runtime libraries.  In general, when mixing languages in LTO mode, you
  should use the same link command options as when mixing languages in a
! regular (non\-LTO) compilation.
  .Sp
! If object files containing GIMPLE bytecode are stored in a library archive, say
! \&\fIlibfoo.a\fR, it is possible to extract and use them in an LTO link if you
  are using a linker with plugin support.  To create static libraries suitable
! for LTO, use \fBgcc\-ar\fR and \fBgcc\-ranlib\fR instead of \fBar\fR
  and \fBranlib\fR; 
! to show the symbols of object files with GIMPLE bytecode, use
! \&\fBgcc\-nm\fR.  Those commands require that \fBar\fR, \fBranlib\fR
  and \fBnm\fR have been compiled with plugin support.  At link time, use the
  flag \fB\-fuse\-linker\-plugin\fR to ensure that the library participates in
! the LTO optimization process:
  .Sp
  .Vb 1
  \&        gcc \-o myprog \-O2 \-flto \-fuse\-linker\-plugin a.o b.o \-lfoo
  .Ve
  .Sp
  With the linker plugin enabled, the linker extracts the needed
! GIMPLE files from \fIlibfoo.a\fR and passes them on to the running GCC
! to make them part of the aggregated GIMPLE image to be optimized.
  .Sp
  If you are not using a linker with plugin support and/or do not
  enable the linker plugin, then the objects inside \fIlibfoo.a\fR
  are extracted and linked as usual, but they do not participate
! in the LTO optimization process.  In order to make a static library suitable
! for both LTO optimization and usual linkage, compile its object files with
  \&\fB\-flto\fR \fB\-ffat\-lto\-objects\fR.
  .Sp
! Link\-time optimizations do not require the presence of the whole program to
  operate.  If the program does not require any symbols to be exported, it is
  possible to combine \fB\-flto\fR and \fB\-fwhole\-program\fR to allow
  the interprocedural optimizers to use more aggressive assumptions which may
*************** lead to improved optimization opportunit
*** 13133,13168 ****
  Use of \fB\-fwhole\-program\fR is not needed when linker plugin is
  active (see \fB\-fuse\-linker\-plugin\fR).
  .Sp
! The current implementation of \s-1LTO\s0 makes no
  attempt to generate bytecode that is portable between different
  types of hosts.  The bytecode files are versioned and there is a
  strict version check, so bytecode files generated in one version of
! \&\s-1GCC\s0 do not work with an older or newer version of \s-1GCC.\s0
  .Sp
! Link-time optimization does not work well with generation of debugging
! information on systems other than those using a combination of \s-1ELF\s0 and
! \&\s-1DWARF.\s0
  .Sp
  If you specify the optional \fIn\fR, the optimization and code
  generation done at link time is executed in parallel using \fIn\fR
  parallel jobs by utilizing an installed \fBmake\fR program.  The
! environment variable \fB\s-1MAKE\s0\fR may be used to override the program
  used.
  .Sp
! You can also specify \fB\-flto=jobserver\fR to use \s-1GNU\s0 make's
  job server mode to determine the number of parallel jobs. This
! is useful when the Makefile calling \s-1GCC\s0 is already executing in parallel.
  You must prepend a \fB+\fR to the command recipe in the parent Makefile
! for this to work.  This option likely only works if \fB\s-1MAKE\s0\fR is
! \&\s-1GNU\s0 make.  Even without the option value, \s-1GCC\s0 tries to automatically
! detect a running \s-1GNU\s0 make's job server.
  .Sp
! Use \fB\-flto=auto\fR to use \s-1GNU\s0 make's job server, if available,
! or otherwise fall back to autodetection of the number of \s-1CPU\s0 threads
  present in your system.
! .IP "\fB\-flto\-partition=\fR\fIalg\fR" 4
  .IX Item "-flto-partition=alg"
! Specify the partitioning algorithm used by the link-time optimizer.
  The value is either \fB1to1\fR to specify a partitioning mirroring
  the original source files or \fBbalanced\fR to specify partitioning
  into equally sized chunks (whenever possible) or \fBmax\fR to create
--- 13062,13097 ----
  Use of \fB\-fwhole\-program\fR is not needed when linker plugin is
  active (see \fB\-fuse\-linker\-plugin\fR).
  .Sp
! The current implementation of 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 do not work with an older or newer version of GCC.
  .Sp
! Link\-time optimization does not work well with generation of debugging
! information on systems other than those using a combination of ELF and
! DWARF.
  .Sp
  If you specify the optional \fIn\fR, the optimization and code
  generation done at link time is executed in parallel using \fIn\fR
  parallel jobs by utilizing an installed \fBmake\fR program.  The
! environment variable \fBMAKE\fR may be used to override the program
  used.
  .Sp
! You can also specify \fB\-flto=jobserver\fR to use GNU make\*(Aqs
  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 \fB+\fR to the command recipe in the parent Makefile
! for this to work.  This option likely only works if \fBMAKE\fR is
! GNU make.  Even without the option value, GCC tries to automatically
! detect a running GNU make\*(Aqs job server.
  .Sp
! Use \fB\-flto=auto\fR to use GNU make\*(Aqs job server, if available,
! or otherwise fall back to autodetection of the number of CPU threads
  present in your system.
! .IP \fB\-flto\-partition=\fR\fIalg\fR 4
  .IX Item "-flto-partition=alg"
! Specify the partitioning algorithm used by the link\-time optimizer.
  The value is either \fB1to1\fR to specify a partitioning mirroring
  the original source files or \fBbalanced\fR to specify partitioning
  into equally sized chunks (whenever possible) or \fBmax\fR to create
*************** as an workaround for various code orderi
*** 13173,13233 ****
  partitioning is intended for internal testing only.
  The value \fBone\fR specifies that exactly one partition should be
  used while the value \fBnone\fR bypasses partitioning and executes
! the link-time optimization step directly from the \s-1WPA\s0 phase.
! .IP "\fB\-flto\-compression\-level=\fR\fIn\fR" 4
  .IX Item "-flto-compression-level=n"
  This option specifies the level of compression used for intermediate
! language written to \s-1LTO\s0 object files, and is only meaningful in
! conjunction with \s-1LTO\s0 mode (\fB\-flto\fR).  \s-1GCC\s0 currently supports two
! \&\s-1LTO\s0 compression algorithms. For zstd, valid values are 0 (no compression)
  to 19 (maximum compression), while zlib supports values from 0 to 9.
  Values outside this range are clamped to either minimum or maximum
  of the supported values.  If the option is not given,
  a default balanced compression setting is used.
! .IP "\fB\-fuse\-linker\-plugin\fR" 4
  .IX Item "-fuse-linker-plugin"
! Enables the use of a linker plugin during link-time optimization.  This
  option relies on plugin support in the linker, which is available in gold
! or in \s-1GNU\s0 ld 2.21 or newer.
  .Sp
! This option enables the extraction of object files with \s-1GIMPLE\s0 bytecode out
  of library archives. This improves the quality of optimization by exposing
! more code to the link-time optimizer.  This information specifies what
! symbols can be accessed externally (by non-LTO object or during dynamic
  linking).  Resulting code quality improvements on binaries (and shared
  libraries that use hidden visibility) are similar to \fB\-fwhole\-program\fR.
  See \fB\-flto\fR for a description of the effect of this flag and how to
  use it.
  .Sp
! This option is enabled by default when \s-1LTO\s0 support in \s-1GCC\s0 is enabled
! and \s-1GCC\s0 was configured for use with
! a linker supporting plugins (\s-1GNU\s0 ld 2.21 or newer or gold).
! .IP "\fB\-ffat\-lto\-objects\fR" 4
  .IX Item "-ffat-lto-objects"
! Fat \s-1LTO\s0 objects are object files that contain both the intermediate language
! and the object code. This makes them usable for both \s-1LTO\s0 linking and normal
  linking. This option is effective only when compiling with \fB\-flto\fR
  and is ignored at link time.
  .Sp
! \&\fB\-fno\-fat\-lto\-objects\fR improves compilation time over plain \s-1LTO,\s0 but
! requires the complete toolchain to be aware of \s-1LTO.\s0 It requires a linker with
  linker plugin support for basic functionality.  Additionally,
  \&\fBnm\fR, \fBar\fR and \fBranlib\fR
! need to support linker plugins to allow a full-featured build environment
! (capable of building static libraries etc).  \s-1GCC\s0 provides the \fBgcc-ar\fR,
! \&\fBgcc-nm\fR, \fBgcc-ranlib\fR wrappers to pass the right options
! to these tools. With non fat \s-1LTO\s0 makefiles need to be modified to use them.
  .Sp
! Note that modern binutils provide plugin auto-load mechanism.
! Installing the linker plugin into \fI\f(CI$libdir\fI/bfd\-plugins\fR has the same
! effect as usage of the command wrappers (\fBgcc-ar\fR, \fBgcc-nm\fR and
! \&\fBgcc-ranlib\fR).
  .Sp
  The default is \fB\-fno\-fat\-lto\-objects\fR on targets with linker plugin
  support.
! .IP "\fB\-fcompare\-elim\fR" 4
  .IX Item "-fcompare-elim"
! After register allocation and post-register allocation instruction splitting,
  identify arithmetic instructions that compute processor flags similar to a
  comparison operation based on that arithmetic.  If possible, eliminate the
  explicit comparison operation.
--- 13102,13162 ----
  partitioning is intended for internal testing only.
  The value \fBone\fR specifies that exactly one partition should be
  used while the value \fBnone\fR bypasses partitioning and executes
! the link\-time optimization step directly from the WPA phase.
! .IP \fB\-flto\-compression\-level=\fR\fIn\fR 4
  .IX Item "-flto-compression-level=n"
  This option specifies the level of compression used for intermediate
! language written to LTO object files, and is only meaningful in
! conjunction with LTO mode (\fB\-flto\fR).  GCC currently supports two
! LTO compression algorithms. For zstd, valid values are 0 (no compression)
  to 19 (maximum compression), while zlib supports values from 0 to 9.
  Values outside this range are clamped to either minimum or maximum
  of the supported values.  If the option is not given,
  a default balanced compression setting is used.
! .IP \fB\-fuse\-linker\-plugin\fR 4
  .IX Item "-fuse-linker-plugin"
! Enables the use of a linker plugin during link\-time optimization.  This
  option relies on plugin support in the linker, which is available in gold
! or in GNU ld 2.21 or newer.
  .Sp
! 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 \fB\-fwhole\-program\fR.
  See \fB\-flto\fR for a description of the effect of this flag and how to
  use it.
  .Sp
! This option is enabled by default when 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).
! .IP \fB\-ffat\-lto\-objects\fR 4
  .IX Item "-ffat-lto-objects"
! Fat LTO objects are object files that contain both the intermediate language
! and the object code. This makes them usable for both LTO linking and normal
  linking. This option is effective only when compiling with \fB\-flto\fR
  and is ignored at link time.
  .Sp
! \&\fB\-fno\-fat\-lto\-objects\fR improves compilation time over plain LTO, but
! requires the complete toolchain to be aware of LTO. It requires a linker with
  linker plugin support for basic functionality.  Additionally,
  \&\fBnm\fR, \fBar\fR and \fBranlib\fR
! need to support linker plugins to allow a full\-featured build environment
! (capable of building static libraries etc).  GCC provides the \fBgcc\-ar\fR,
! \&\fBgcc\-nm\fR, \fBgcc\-ranlib\fR wrappers to pass the right options
! to these tools. With non fat LTO makefiles need to be modified to use them.
  .Sp
! Note that modern binutils provide plugin auto\-load mechanism.
! Installing the linker plugin into \fR\f(CI$libdir\fR\fI/bfd\-plugins\fR has the same
! effect as usage of the command wrappers (\fBgcc\-ar\fR, \fBgcc\-nm\fR and
! \&\fBgcc\-ranlib\fR).
  .Sp
  The default is \fB\-fno\-fat\-lto\-objects\fR on targets with linker plugin
  support.
! .IP \fB\-fcompare\-elim\fR 4
  .IX Item "-fcompare-elim"
! After register allocation and post\-register allocation instruction splitting,
  identify arithmetic instructions that compute processor flags similar to a
  comparison operation based on that arithmetic.  If possible, eliminate the
  explicit comparison operation.
*************** This pass only applies to certain target
*** 13236,13257 ****
  the comparison operation before register allocation is complete.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fcprop\-registers\fR" 4
  .IX Item "-fcprop-registers"
! After register allocation and post-register allocation instruction splitting,
! perform a copy-propagation pass to try to reduce scheduling dependencies
  and occasionally eliminate the copy.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-fprofile\-correction\fR" 4
  .IX Item "-fprofile-correction"
! Profiles collected using an instrumented binary for multi-threaded programs may
  be inconsistent due to missed counter updates. When this option is specified,
! \&\s-1GCC\s0 uses heuristics to correct or smooth out such inconsistencies. By
! default, \s-1GCC\s0 emits an error message when an inconsistent profile is detected.
  .Sp
  This option is enabled by \fB\-fauto\-profile\fR.
! .IP "\fB\-fprofile\-partial\-training\fR" 4
  .IX Item "-fprofile-partial-training"
  With \f(CW\*(C`\-fprofile\-use\*(C'\fR all portions of programs not executed during train
  run are optimized agressively for size rather than speed.  In some cases it is
--- 13165,13186 ----
  the comparison operation before register allocation is complete.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fcprop\-registers\fR 4
  .IX Item "-fcprop-registers"
! After register allocation and post\-register allocation instruction splitting,
! perform a copy\-propagation pass to try to reduce scheduling dependencies
  and occasionally eliminate the copy.
  .Sp
  Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-fprofile\-correction\fR 4
  .IX Item "-fprofile-correction"
! Profiles collected using an instrumented binary for multi\-threaded programs may
  be inconsistent due to missed counter updates. When this option is specified,
! GCC uses heuristics to correct or smooth out such inconsistencies. By
! default, GCC emits an error message when an inconsistent profile is detected.
  .Sp
  This option is enabled by \fB\-fauto\-profile\fR.
! .IP \fB\-fprofile\-partial\-training\fR 4
  .IX Item "-fprofile-partial-training"
  With \f(CW\*(C`\-fprofile\-use\*(C'\fR all portions of programs not executed during train
  run are optimized agressively for size rather than speed.  In some cases it is
*************** functions not executed during the train
*** 13263,13275 ****
  they were compiled without profile feedback. This leads to better performance
  when train run is not representative but also leads to significantly bigger
  code.
! .IP "\fB\-fprofile\-use\fR" 4
  .IX Item "-fprofile-use"
  .PD 0
! .IP "\fB\-fprofile\-use=\fR\fIpath\fR" 4
  .IX Item "-fprofile-use=path"
  .PD
! Enable profile feedback-directed optimizations, 
  and the following optimizations, many of which
  are generally profitable only with profile feedback available:
  .Sp
--- 13192,13204 ----
  they were compiled without profile feedback. This leads to better performance
  when train run is not representative but also leads to significantly bigger
  code.
! .IP \fB\-fprofile\-use\fR 4
  .IX Item "-fprofile-use"
  .PD 0
! .IP \fB\-fprofile\-use=\fR\fIpath\fR 4
  .IX Item "-fprofile-use=path"
  .PD
! Enable profile feedback\-directed optimizations, 
  and the following optimizations, many of which
  are generally profitable only with profile feedback available:
  .Sp
*************** are generally profitable only with profi
*** 13283,13303 ****
  .Sp
  Before you can use this option, you must first generate profiling information.
  .Sp
! By default, \s-1GCC\s0 emits an error message if the feedback profiles do not
  match the source code.  This error can be turned into a warning by using
  \&\fB\-Wno\-error=coverage\-mismatch\fR.  Note this may result in poorly
! optimized code.  Additionally, by default, \s-1GCC\s0 also emits a warning message if
  the feedback profiles do not exist (see \fB\-Wmissing\-profile\fR).
  .Sp
! If \fIpath\fR is specified, \s-1GCC\s0 looks at the \fIpath\fR to find
  the profile feedback data files. See \fB\-fprofile\-dir\fR.
! .IP "\fB\-fauto\-profile\fR" 4
  .IX Item "-fauto-profile"
  .PD 0
! .IP "\fB\-fauto\-profile=\fR\fIpath\fR" 4
  .IX Item "-fauto-profile=path"
  .PD
! Enable sampling-based feedback-directed optimizations, 
  and the following optimizations,
  many of which are generally profitable only with profile feedback available:
  .Sp
--- 13212,13232 ----
  .Sp
  Before you can use this option, you must first generate profiling information.
  .Sp
! 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
  \&\fB\-Wno\-error=coverage\-mismatch\fR.  Note this may result in poorly
! optimized code.  Additionally, by default, GCC also emits a warning message if
  the feedback profiles do not exist (see \fB\-Wmissing\-profile\fR).
  .Sp
! If \fIpath\fR is specified, GCC looks at the \fIpath\fR to find
  the profile feedback data files. See \fB\-fprofile\-dir\fR.
! .IP \fB\-fauto\-profile\fR 4
  .IX Item "-fauto-profile"
  .PD 0
! .IP \fB\-fauto\-profile=\fR\fIpath\fR 4
  .IX Item "-fauto-profile=path"
  .PD
! Enable sampling\-based feedback\-directed optimizations, 
  and the following optimizations,
  many of which are generally profitable only with profile feedback available:
  .Sp
*************** E.g.
*** 13324,13330 ****
  .Ve
  .Sp
  Then use the \fBcreate_gcov\fR tool to convert the raw profile data
! to a format that can be used by \s-1GCC.\s0  You must also supply the 
  unstripped binary for your program to this tool.  
  See <\fBhttps://github.com/google/autofdo\fR>.
  .Sp
--- 13253,13259 ----
  .Ve
  .Sp
  Then use the \fBcreate_gcov\fR tool to convert the raw profile data
! to a format that can be used by GCC.  You must also supply the 
  unstripped binary for your program to this tool.  
  See <\fBhttps://github.com/google/autofdo\fR>.
  .Sp
*************** E.g.
*** 13335,13380 ****
  \&            \-\-gcov=profile.afdo
  .Ve
  .PP
! The following options control compiler behavior regarding floating-point 
  arithmetic.  These options trade off between speed and
  correctness.  All must be specifically enabled.
! .IP "\fB\-ffloat\-store\fR" 4
  .IX Item "-ffloat-store"
! Do not store floating-point variables in registers, and inhibit other
! options that might change whether a floating-point value is taken from a
  register or memory.
  .Sp
  This option prevents undesirable excess precision on machines such as
  the 68000 where the floating registers (of the 68881) keep more
  precision than a \f(CW\*(C`double\*(C'\fR is supposed to have.  Similarly for the
  x86 architecture.  For most programs, the excess precision does only
! good, but a few programs rely on the precise definition of \s-1IEEE\s0 floating
  point.  Use \fB\-ffloat\-store\fR for such programs, after modifying
  them to store all pertinent intermediate computations into variables.
! .IP "\fB\-fexcess\-precision=\fR\fIstyle\fR" 4
  .IX Item "-fexcess-precision=style"
  This option allows further control over excess precision on machines
! where floating-point operations occur in a format with more precision or
! range than the \s-1IEEE\s0 standard and interchange floating-point types.  By
  default, \fB\-fexcess\-precision=fast\fR is in effect; this means that
  operations may be carried out in a wider precision than the types specified
  in the source if that would result in faster code, and it is unpredictable
  when rounding to the types specified in the source code takes place.
! When compiling C or \*(C+, if \fB\-fexcess\-precision=standard\fR is specified
! then excess precision follows the rules specified in \s-1ISO C99\s0 or \*(C+; in particular,
  both casts and assignments cause values to be rounded to their
  semantic types (whereas \fB\-ffloat\-store\fR only affects
! assignments).  This option is enabled by default for C or \*(C+ if a strict
  conformance option such as \fB\-std=c99\fR or \fB\-std=c++17\fR is used.
  \&\fB\-ffast\-math\fR enables \fB\-fexcess\-precision=fast\fR by default
  regardless of whether a strict conformance option is used.
  .Sp
  \&\fB\-fexcess\-precision=standard\fR is not implemented for languages
! other than C or \*(C+.  On the x86, it has no effect if \fB\-mfpmath=sse\fR
! or \fB\-mfpmath=sse+387\fR is specified; in the former case, \s-1IEEE\s0
  semantics apply without excess precision, and in the latter, rounding
  is unpredictable.
! .IP "\fB\-ffast\-math\fR" 4
  .IX Item "-ffast-math"
  Sets the options \fB\-fno\-math\-errno\fR, \fB\-funsafe\-math\-optimizations\fR,
  \&\fB\-ffinite\-math\-only\fR, \fB\-fno\-rounding\-math\fR,
--- 13264,13309 ----
  \&            \-\-gcov=profile.afdo
  .Ve
  .PP
! The following options control compiler behavior regarding floating\-point 
  arithmetic.  These options trade off between speed and
  correctness.  All must be specifically enabled.
! .IP \fB\-ffloat\-store\fR 4
  .IX Item "-ffloat-store"
! Do not store floating\-point variables in registers, and inhibit other
! options that might change whether a floating\-point value is taken from a
  register or memory.
  .Sp
  This option prevents undesirable excess precision on machines such as
  the 68000 where the floating registers (of the 68881) keep more
  precision than a \f(CW\*(C`double\*(C'\fR is supposed to have.  Similarly for the
  x86 architecture.  For most programs, the excess precision does only
! good, but a few programs rely on the precise definition of IEEE floating
  point.  Use \fB\-ffloat\-store\fR for such programs, after modifying
  them to store all pertinent intermediate computations into variables.
! .IP \fB\-fexcess\-precision=\fR\fIstyle\fR 4
  .IX Item "-fexcess-precision=style"
  This option allows further control over excess precision on machines
! where floating\-point operations occur in a format with more precision or
! range than the IEEE standard and interchange floating\-point types.  By
  default, \fB\-fexcess\-precision=fast\fR is in effect; this means that
  operations may be carried out in a wider precision than the types specified
  in the source if that would result in faster code, and it is unpredictable
  when rounding to the types specified in the source code takes place.
! When compiling C or C++, if \fB\-fexcess\-precision=standard\fR is specified
! then excess precision follows the rules specified in ISO C99 or C++; in particular,
  both casts and assignments cause values to be rounded to their
  semantic types (whereas \fB\-ffloat\-store\fR only affects
! assignments).  This option is enabled by default for C or C++ if a strict
  conformance option such as \fB\-std=c99\fR or \fB\-std=c++17\fR is used.
  \&\fB\-ffast\-math\fR enables \fB\-fexcess\-precision=fast\fR by default
  regardless of whether a strict conformance option is used.
  .Sp
  \&\fB\-fexcess\-precision=standard\fR is not implemented for languages
! other than C or C++.  On the x86, it has no effect if \fB\-mfpmath=sse\fR
! or \fB\-mfpmath=sse+387\fR is specified; in the former case, IEEE
  semantics apply without excess precision, and in the latter, rounding
  is unpredictable.
! .IP \fB\-ffast\-math\fR 4
  .IX Item "-ffast-math"
  Sets the options \fB\-fno\-math\-errno\fR, \fB\-funsafe\-math\-optimizations\fR,
  \&\fB\-ffinite\-math\-only\fR, \fB\-fno\-rounding\-math\fR,
*************** This option causes the preprocessor macr
*** 13385,13403 ****
  .Sp
  This option is not turned on by any \fB\-O\fR option besides
  \&\fB\-Ofast\fR since it can result in incorrect output for programs
! that depend on an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications
  for math functions. It may, however, yield faster code for programs
  that do not require the guarantees of these specifications.
! .IP "\fB\-fno\-math\-errno\fR" 4
  .IX Item "-fno-math-errno"
  Do not set \f(CW\*(C`errno\*(C'\fR after calling math functions that are executed
  with a single instruction, e.g., \f(CW\*(C`sqrt\*(C'\fR.  A program that relies on
! \&\s-1IEEE\s0 exceptions for math error handling may want to use this flag
! for speed while maintaining \s-1IEEE\s0 arithmetic compatibility.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
  math functions. It may, however, yield faster code for programs
  that do not require the guarantees of these specifications.
  .Sp
--- 13314,13332 ----
  .Sp
  This option is not turned on by any \fB\-O\fR option besides
  \&\fB\-Ofast\fR since it can result in incorrect output for programs
! that depend on an exact implementation of 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.
! .IP \fB\-fno\-math\-errno\fR 4
  .IX Item "-fno-math-errno"
  Do not set \f(CW\*(C`errno\*(C'\fR after calling math functions that are executed
  with a single instruction, e.g., \f(CW\*(C`sqrt\*(C'\fR.  A program that relies on
! IEEE exceptions for math error handling may want to use this flag
! for speed while maintaining IEEE arithmetic compatibility.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of 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.
  .Sp
*************** The default is \fB\-fmath\-errno\fR.
*** 13406,13445 ****
  On Darwin systems, the math library never sets \f(CW\*(C`errno\*(C'\fR.  There is
  therefore no reason for the compiler to consider the possibility that
  it might, and \fB\-fno\-math\-errno\fR is the default.
! .IP "\fB\-funsafe\-math\-optimizations\fR" 4
  .IX Item "-funsafe-math-optimizations"
! Allow optimizations for floating-point arithmetic that (a) assume
! that arguments and results are valid and (b) may violate \s-1IEEE\s0 or
! \&\s-1ANSI\s0 standards.  When used at link time, it may include libraries
! or startup files that change the default \s-1FPU\s0 control word or other
  similar optimizations.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
  math functions. It may, however, yield faster code for programs
  that do not require the guarantees of these specifications.
  Enables \fB\-fno\-signed\-zeros\fR, \fB\-fno\-trapping\-math\fR,
  \&\fB\-fassociative\-math\fR and \fB\-freciprocal\-math\fR.
  .Sp
  The default is \fB\-fno\-unsafe\-math\-optimizations\fR.
! .IP "\fB\-fassociative\-math\fR" 4
  .IX Item "-fassociative-math"
! Allow re-association of operands in series of floating-point operations.
! This violates the \s-1ISO C\s0 and \*(C+ language standard by possibly changing
! computation result.  \s-1NOTE:\s0 re-ordering may change the sign of zero as
  well as ignore NaNs and inhibit or create underflow or overflow (and
  thus cannot be used on code that relies on rounding behavior like
! \&\f(CW\*(C`(x + 2**52) \- 2**52\*(C'\fR.  May also reorder floating-point comparisons
  and thus may not be used when ordered comparisons are required.
  This option requires that both \fB\-fno\-signed\-zeros\fR and
! \&\fB\-fno\-trapping\-math\fR be in effect.  Moreover, it doesn't make
  much sense with \fB\-frounding\-math\fR. For Fortran the option
  is automatically enabled when both \fB\-fno\-signed\-zeros\fR and
  \&\fB\-fno\-trapping\-math\fR are in effect.
  .Sp
  The default is \fB\-fno\-associative\-math\fR.
! .IP "\fB\-freciprocal\-math\fR" 4
  .IX Item "-freciprocal-math"
  Allow the reciprocal of a value to be used instead of dividing by
  the value if this enables optimizations.  For example \f(CW\*(C`x / y\*(C'\fR
--- 13335,13374 ----
  On Darwin systems, the math library never sets \f(CW\*(C`errno\*(C'\fR.  There is
  therefore no reason for the compiler to consider the possibility that
  it might, and \fB\-fno\-math\-errno\fR is the default.
! .IP \fB\-funsafe\-math\-optimizations\fR 4
  .IX Item "-funsafe-math-optimizations"
! Allow optimizations for floating\-point arithmetic that (a) assume
! that arguments and results are valid and (b) may violate 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.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of 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 \fB\-fno\-signed\-zeros\fR, \fB\-fno\-trapping\-math\fR,
  \&\fB\-fassociative\-math\fR and \fB\-freciprocal\-math\fR.
  .Sp
  The default is \fB\-fno\-unsafe\-math\-optimizations\fR.
! .IP \fB\-fassociative\-math\fR 4
  .IX Item "-fassociative-math"
! Allow re\-association of operands in series of floating\-point operations.
! This violates the ISO C and C++ language standard by possibly changing
! computation result.  NOTE: re\-ordering may change the sign of zero as
  well as ignore NaNs and inhibit or create underflow or overflow (and
  thus cannot be used on code that relies on rounding behavior like
! \&\f(CW\*(C`(x + 2**52) \- 2**52\*(C'\fR.  May also reorder floating\-point comparisons
  and thus may not be used when ordered comparisons are required.
  This option requires that both \fB\-fno\-signed\-zeros\fR and
! \&\fB\-fno\-trapping\-math\fR be in effect.  Moreover, it doesn\*(Aqt make
  much sense with \fB\-frounding\-math\fR. For Fortran the option
  is automatically enabled when both \fB\-fno\-signed\-zeros\fR and
  \&\fB\-fno\-trapping\-math\fR are in effect.
  .Sp
  The default is \fB\-fno\-associative\-math\fR.
! .IP \fB\-freciprocal\-math\fR 4
  .IX Item "-freciprocal-math"
  Allow the reciprocal of a value to be used instead of dividing by
  the value if this enables optimizations.  For example \f(CW\*(C`x / y\*(C'\fR
*************** is subject to common subexpression elimi
*** 13448,13517 ****
  precision and increases the number of flops operating on the value.
  .Sp
  The default is \fB\-fno\-reciprocal\-math\fR.
! .IP "\fB\-ffinite\-math\-only\fR" 4
  .IX Item "-ffinite-math-only"
! Allow optimizations for floating-point arithmetic that assume
  that arguments and results are not NaNs or +\-Infs.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
  math functions. It may, however, yield faster code for programs
  that do not require the guarantees of these specifications.
  .Sp
  The default is \fB\-fno\-finite\-math\-only\fR.
! .IP "\fB\-fno\-signed\-zeros\fR" 4
  .IX Item "-fno-signed-zeros"
! Allow optimizations for floating-point arithmetic that ignore the
! signedness of zero.  \s-1IEEE\s0 arithmetic specifies the behavior of
  distinct +0.0 and \-0.0 values, which then prohibits simplification
  of expressions such as x+0.0 or 0.0*x (even with \fB\-ffinite\-math\-only\fR).
! This option implies that the sign of a zero result isn't significant.
  .Sp
  The default is \fB\-fsigned\-zeros\fR.
! .IP "\fB\-fno\-trapping\-math\fR" 4
  .IX Item "-fno-trapping-math"
! Compile code assuming that floating-point operations cannot generate
! user-visible traps.  These traps include division by zero, overflow,
  underflow, inexact result and invalid operation.  This option requires
  that \fB\-fno\-signaling\-nans\fR be in effect.  Setting this option may
! allow faster code if one relies on \*(L"non-stop\*(R" \s-1IEEE\s0 arithmetic, for example.
  .Sp
  This option should never be turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
  math functions.
  .Sp
  The default is \fB\-ftrapping\-math\fR.
  .Sp
! Future versions of \s-1GCC\s0 may provide finer control of this setting
! using C99's \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma.  This command-line option
  will be used along with \fB\-frounding\-math\fR to specify the
  default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
! .IP "\fB\-frounding\-math\fR" 4
  .IX Item "-frounding-math"
! Disable transformations and optimizations that assume default floating-point
! rounding behavior.  This is round-to-zero for all floating point
! to integer conversions, and round-to-nearest for all other arithmetic
  truncations.  This option should be specified for programs that change
! the \s-1FP\s0 rounding mode dynamically, or that may be executed with a
! non-default rounding mode.  This option disables constant folding of
! floating-point expressions at compile time (which may be affected by
  rounding mode) and arithmetic transformations that are unsafe in the
! presence of sign-dependent rounding modes.
  .Sp
  The default is \fB\-fno\-rounding\-math\fR.
  .Sp
  This option is experimental and does not currently guarantee to
! disable all \s-1GCC\s0 optimizations that are affected by rounding mode.
! Future versions of \s-1GCC\s0 may provide finer control of this setting
! using C99's \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma.  This command-line option
  will be used along with \fB\-ftrapping\-math\fR to specify the
  default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
! .IP "\fB\-fsignaling\-nans\fR" 4
  .IX Item "-fsignaling-nans"
! Compile code assuming that \s-1IEEE\s0 signaling NaNs may generate user-visible
! traps during floating-point operations.  Setting this option disables
  optimizations that may change the number of exceptions visible with
  signaling NaNs.  This option implies \fB\-ftrapping\-math\fR.
  .Sp
--- 13377,13446 ----
  precision and increases the number of flops operating on the value.
  .Sp
  The default is \fB\-fno\-reciprocal\-math\fR.
! .IP \fB\-ffinite\-math\-only\fR 4
  .IX Item "-ffinite-math-only"
! Allow optimizations for floating\-point arithmetic that assume
  that arguments and results are not NaNs or +\-Infs.
  .Sp
  This option is not turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of 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.
  .Sp
  The default is \fB\-fno\-finite\-math\-only\fR.
! .IP \fB\-fno\-signed\-zeros\fR 4
  .IX Item "-fno-signed-zeros"
! Allow optimizations for floating\-point arithmetic that ignore the
! signedness of zero.  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 \fB\-ffinite\-math\-only\fR).
! This option implies that the sign of a zero result isn\*(Aqt significant.
  .Sp
  The default is \fB\-fsigned\-zeros\fR.
! .IP \fB\-fno\-trapping\-math\fR 4
  .IX Item "-fno-trapping-math"
! Compile code assuming that floating\-point operations cannot generate
! user\-visible traps.  These traps include division by zero, overflow,
  underflow, inexact result and invalid operation.  This option requires
  that \fB\-fno\-signaling\-nans\fR be in effect.  Setting this option may
! allow faster code if one relies on "non\-stop" IEEE arithmetic, for example.
  .Sp
  This option should never be turned on by any \fB\-O\fR option since
  it can result in incorrect output for programs that depend on
! an exact implementation of IEEE or ISO rules/specifications for
  math functions.
  .Sp
  The default is \fB\-ftrapping\-math\fR.
  .Sp
! Future versions of GCC may provide finer control of this setting
! using C99\*(Aqs \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma.  This command\-line option
  will be used along with \fB\-frounding\-math\fR to specify the
  default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
! .IP \fB\-frounding\-math\fR 4
  .IX Item "-frounding-math"
! Disable transformations and optimizations that assume default floating\-point
! rounding behavior.  This is round\-to\-zero for all floating point
! to integer conversions, and round\-to\-nearest for all other arithmetic
  truncations.  This option should be specified for programs that change
! the 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.
  .Sp
  The default is \fB\-fno\-rounding\-math\fR.
  .Sp
  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\*(Aqs \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma.  This command\-line option
  will be used along with \fB\-ftrapping\-math\fR to specify the
  default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
! .IP \fB\-fsignaling\-nans\fR 4
  .IX Item "-fsignaling-nans"
! Compile code assuming that 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 \fB\-ftrapping\-math\fR.
  .Sp
*************** be defined.
*** 13521,13549 ****
  The default is \fB\-fno\-signaling\-nans\fR.
  .Sp
  This option is experimental and does not currently guarantee to
! disable all \s-1GCC\s0 optimizations that affect signaling NaN behavior.
! .IP "\fB\-fno\-fp\-int\-builtin\-inexact\fR" 4
  .IX Item "-fno-fp-int-builtin-inexact"
! Do not allow the built-in functions \f(CW\*(C`ceil\*(C'\fR, \f(CW\*(C`floor\*(C'\fR,
  \&\f(CW\*(C`round\*(C'\fR and \f(CW\*(C`trunc\*(C'\fR, and their \f(CW\*(C`float\*(C'\fR and \f(CW\*(C`long
! double\*(C'\fR variants, to generate code that raises the \*(L"inexact\*(R"
! floating-point exception for noninteger arguments.  \s-1ISO C99\s0 and C11
! allow these functions to raise the \*(L"inexact\*(R" exception, but \s-1ISO/IEC
! TS 18661\-1:2014,\s0 the C bindings to \s-1IEEE 754\-2008,\s0 as integrated into
! \&\s-1ISO C2X,\s0 does not allow these functions to do so.
  .Sp
  The default is \fB\-ffp\-int\-builtin\-inexact\fR, allowing the
  exception to be raised, unless C2X or a later C standard is selected.
  This option does nothing unless \fB\-ftrapping\-math\fR is in effect.
  .Sp
  Even if \fB\-fno\-fp\-int\-builtin\-inexact\fR is used, if the functions
! generate a call to a library function then the \*(L"inexact\*(R" exception
! may be raised if the library implementation does not follow \s-1TS 18661.\s0
! .IP "\fB\-fsingle\-precision\-constant\fR" 4
  .IX Item "-fsingle-precision-constant"
! Treat floating-point constants as single precision instead of
! implicitly converting them to double-precision constants.
! .IP "\fB\-fcx\-limited\-range\fR" 4
  .IX Item "-fcx-limited-range"
  When enabled, this option states that a range reduction step is not
  needed when performing complex division.  Also, there is no checking
--- 13450,13478 ----
  The default is \fB\-fno\-signaling\-nans\fR.
  .Sp
  This option is experimental and does not currently guarantee to
! disable all GCC optimizations that affect signaling NaN behavior.
! .IP \fB\-fno\-fp\-int\-builtin\-inexact\fR 4
  .IX Item "-fno-fp-int-builtin-inexact"
! Do not allow the built\-in functions \f(CW\*(C`ceil\*(C'\fR, \f(CW\*(C`floor\*(C'\fR,
  \&\f(CW\*(C`round\*(C'\fR and \f(CW\*(C`trunc\*(C'\fR, and their \f(CW\*(C`float\*(C'\fR and \f(CW\*(C`long
! double\*(C'\fR variants, to generate code that raises the "inexact"
! floating\-point exception for noninteger arguments.  ISO C99 and C11
! allow these functions to raise the "inexact" exception, but ISO/IEC
! TS 18661\-1:2014, the C bindings to IEEE 754\-2008, as integrated into
! ISO C2X, does not allow these functions to do so.
  .Sp
  The default is \fB\-ffp\-int\-builtin\-inexact\fR, allowing the
  exception to be raised, unless C2X or a later C standard is selected.
  This option does nothing unless \fB\-ftrapping\-math\fR is in effect.
  .Sp
  Even if \fB\-fno\-fp\-int\-builtin\-inexact\fR is used, if the functions
! generate a call to a library function then the "inexact" exception
! may be raised if the library implementation does not follow TS 18661.
! .IP \fB\-fsingle\-precision\-constant\fR 4
  .IX Item "-fsingle-precision-constant"
! Treat floating\-point constants as single precision instead of
! implicitly converting them to double\-precision constants.
! .IP \fB\-fcx\-limited\-range\fR 4
  .IX Item "-fcx-limited-range"
  When enabled, this option states that a range reduction step is not
  needed when performing complex division.  Also, there is no checking
*************** whether the result of a complex multipli
*** 13552,13561 ****
  default is \fB\-fno\-cx\-limited\-range\fR, but is enabled by
  \&\fB\-ffast\-math\fR.
  .Sp
! This option controls the default setting of the \s-1ISO C99\s0
  \&\f(CW\*(C`CX_LIMITED_RANGE\*(C'\fR pragma.  Nevertheless, the option applies to
  all languages.
! .IP "\fB\-fcx\-fortran\-rules\fR" 4
  .IX Item "-fcx-fortran-rules"
  Complex multiplication and division follow Fortran rules.  Range
  reduction is done as part of complex division, but there is no checking
--- 13481,13490 ----
  default is \fB\-fno\-cx\-limited\-range\fR, but is enabled by
  \&\fB\-ffast\-math\fR.
  .Sp
! This option controls the default setting of the ISO C99
  \&\f(CW\*(C`CX_LIMITED_RANGE\*(C'\fR pragma.  Nevertheless, the option applies to
  all languages.
! .IP \fB\-fcx\-fortran\-rules\fR 4
  .IX Item "-fcx-fortran-rules"
  Complex multiplication and division follow Fortran rules.  Range
  reduction is done as part of complex division, but there is no checking
*************** The default is \fB\-fno\-cx\-fortran\-ru
*** 13567,13594 ****
  The following options control optimizations that may improve
  performance, but are not enabled by any \fB\-O\fR options.  This
  section includes experimental options that may produce broken code.
! .IP "\fB\-fbranch\-probabilities\fR" 4
  .IX Item "-fbranch-probabilities"
  After running a program compiled with \fB\-fprofile\-arcs\fR,
  you can compile it a second time using
  \&\fB\-fbranch\-probabilities\fR, to improve optimizations based on
  the number of times each branch was taken.  When a program
  compiled with \fB\-fprofile\-arcs\fR exits, it saves arc execution
! counts to a file called \fI\fIsourcename\fI.gcda\fR for each source
  file.  The information in this data file is very dependent on the
  structure of the generated code, so you must use the same source code
  and the same optimization options for both compilations.
  See details about the file naming in \fB\-fprofile\-arcs\fR.
  .Sp
! With \fB\-fbranch\-probabilities\fR, \s-1GCC\s0 puts a
! \&\fB\s-1REG_BR_PROB\s0\fR note on each \fB\s-1JUMP_INSN\s0\fR and \fB\s-1CALL_INSN\s0\fR.
  These can be used to improve optimization.  Currently, they are only
  used in one place: in \fIreorg.cc\fR, instead of guessing which path a
! branch is most likely to take, the \fB\s-1REG_BR_PROB\s0\fR values are used to
  exactly determine which path is taken more often.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-fprofile\-values\fR" 4
  .IX Item "-fprofile-values"
  If combined with \fB\-fprofile\-arcs\fR, it adds code so that some
  data about values of expressions in the program is gathered.
--- 13496,13523 ----
  The following options control optimizations that may improve
  performance, but are not enabled by any \fB\-O\fR options.  This
  section includes experimental options that may produce broken code.
! .IP \fB\-fbranch\-probabilities\fR 4
  .IX Item "-fbranch-probabilities"
  After running a program compiled with \fB\-fprofile\-arcs\fR,
  you can compile it a second time using
  \&\fB\-fbranch\-probabilities\fR, to improve optimizations based on
  the number of times each branch was taken.  When a program
  compiled with \fB\-fprofile\-arcs\fR exits, it saves arc execution
! counts to a file called \fIsourcename.gcda\fR for each source
  file.  The information in this data file is very dependent on the
  structure of the generated code, so you must use the same source code
  and the same optimization options for both compilations.
  See details about the file naming in \fB\-fprofile\-arcs\fR.
  .Sp
! With \fB\-fbranch\-probabilities\fR, GCC puts a
! \&\fBREG_BR_PROB\fR note on each \fBJUMP_INSN\fR and \fBCALL_INSN\fR.
  These can be used to improve optimization.  Currently, they are only
  used in one place: in \fIreorg.cc\fR, instead of guessing which path a
! branch is most likely to take, the \fBREG_BR_PROB\fR values are used to
  exactly determine which path is taken more often.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-fprofile\-values\fR 4
  .IX Item "-fprofile-values"
  If combined with \fB\-fprofile\-arcs\fR, it adds code so that some
  data about values of expressions in the program is gathered.
*************** from profiling values of expressions for
*** 13598,13611 ****
  .Sp
  Enabled by \fB\-fprofile\-generate\fR, \fB\-fprofile\-use\fR, and
  \&\fB\-fauto\-profile\fR.
! .IP "\fB\-fprofile\-reorder\-functions\fR" 4
  .IX Item "-fprofile-reorder-functions"
  Function reordering based on profile instrumentation collects
  first time of execution of a function and orders these functions
  in ascending order.
  .Sp
  Enabled with \fB\-fprofile\-use\fR.
! .IP "\fB\-fvpt\fR" 4
  .IX Item "-fvpt"
  If combined with \fB\-fprofile\-arcs\fR, this option instructs the compiler
  to add code to gather information about values of expressions.
--- 13527,13540 ----
  .Sp
  Enabled by \fB\-fprofile\-generate\fR, \fB\-fprofile\-use\fR, and
  \&\fB\-fauto\-profile\fR.
! .IP \fB\-fprofile\-reorder\-functions\fR 4
  .IX Item "-fprofile-reorder-functions"
  Function reordering based on profile instrumentation collects
  first time of execution of a function and orders these functions
  in ascending order.
  .Sp
  Enabled with \fB\-fprofile\-use\fR.
! .IP \fB\-fvpt\fR 4
  .IX Item "-fvpt"
  If combined with \fB\-fprofile\-arcs\fR, this option instructs the compiler
  to add code to gather information about values of expressions.
*************** Currently the optimizations include spec
*** 13616,13646 ****
  using the knowledge about the value of the denominator.
  .Sp
  Enabled with \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-frename\-registers\fR" 4
  .IX Item "-frename-registers"
  Attempt to avoid false dependencies in scheduled code by making use
  of registers left over after register allocation.  This optimization
  most benefits processors with lots of registers.  Depending on the
  debug information format adopted by the target, however, it can
  make debugging impossible, since variables no longer stay in
! a \*(L"home register\*(R".
  .Sp
  Enabled by default with \fB\-funroll\-loops\fR.
! .IP "\fB\-fschedule\-fusion\fR" 4
  .IX Item "-fschedule-fusion"
  Performs a target dependent pass over the instruction stream to schedule
  instructions of same type together because target machine can execute them
  more efficiently if they are adjacent to each other in the instruction flow.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP "\fB\-ftracer\fR" 4
  .IX Item "-ftracer"
  Perform tail duplication to enlarge superblock size.  This transformation
  simplifies the control flow of the function allowing other optimizations to do
  a better job.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-funroll\-loops\fR" 4
  .IX Item "-funroll-loops"
  Unroll loops whose number of iterations can be determined at compile time or
  upon entry to the loop.  \fB\-funroll\-loops\fR implies
--- 13545,13575 ----
  using the knowledge about the value of the denominator.
  .Sp
  Enabled with \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-frename\-registers\fR 4
  .IX Item "-frename-registers"
  Attempt to avoid false dependencies in scheduled code by making use
  of registers left over after register allocation.  This optimization
  most benefits processors with lots of registers.  Depending on the
  debug information format adopted by the target, however, it can
  make debugging impossible, since variables no longer stay in
! a "home register".
  .Sp
  Enabled by default with \fB\-funroll\-loops\fR.
! .IP \fB\-fschedule\-fusion\fR 4
  .IX Item "-fschedule-fusion"
  Performs a target dependent pass over the instruction stream to schedule
  instructions of same type together because target machine can execute them
  more efficiently if they are adjacent to each other in the instruction flow.
  .Sp
  Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
! .IP \fB\-ftracer\fR 4
  .IX Item "-ftracer"
  Perform tail duplication to enlarge superblock size.  This transformation
  simplifies the control flow of the function allowing other optimizations to do
  a better job.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-funroll\-loops\fR 4
  .IX Item "-funroll-loops"
  Unroll loops whose number of iterations can be determined at compile time or
  upon entry to the loop.  \fB\-funroll\-loops\fR implies
*************** a small constant number of iterations).
*** 13650,13662 ****
  or may not make it run faster.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-funroll\-all\-loops\fR" 4
  .IX Item "-funroll-all-loops"
  Unroll all loops, even if their number of iterations is uncertain when
  the loop is entered.  This usually makes programs run more slowly.
  \&\fB\-funroll\-all\-loops\fR implies the same options as
  \&\fB\-funroll\-loops\fR.
! .IP "\fB\-fpeel\-loops\fR" 4
  .IX Item "-fpeel-loops"
  Peels loops for which there is enough information that they do not
  roll much (from profile feedback or static analysis).  It also turns on
--- 13579,13591 ----
  or may not make it run faster.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-funroll\-all\-loops\fR 4
  .IX Item "-funroll-all-loops"
  Unroll all loops, even if their number of iterations is uncertain when
  the loop is entered.  This usually makes programs run more slowly.
  \&\fB\-funroll\-all\-loops\fR implies the same options as
  \&\fB\-funroll\-loops\fR.
! .IP \fB\-fpeel\-loops\fR 4
  .IX Item "-fpeel-loops"
  Peels loops for which there is enough information that they do not
  roll much (from profile feedback or static analysis).  It also turns on
*************** complete loop peeling (i.e. complete rem
*** 13664,13694 ****
  number of iterations).
  .Sp
  Enabled by \fB\-O3\fR, \fB\-fprofile\-use\fR, and \fB\-fauto\-profile\fR.
! .IP "\fB\-fmove\-loop\-invariants\fR" 4
  .IX Item "-fmove-loop-invariants"
! Enables the loop invariant motion pass in the \s-1RTL\s0 loop optimizer.  Enabled
  at level \fB\-O1\fR and higher, except for \fB\-Og\fR.
! .IP "\fB\-fmove\-loop\-stores\fR" 4
  .IX Item "-fmove-loop-stores"
! Enables the loop store motion pass in the \s-1GIMPLE\s0 loop optimizer.  This
  moves invariant stores to after the end of the loop in exchange for
  carrying the stored value in a register across the iteration.
  Note for this option to have an effect \fB\-ftree\-loop\-im\fR has to
  be enabled as well.  Enabled at level \fB\-O1\fR and higher, except
  for \fB\-Og\fR.
! .IP "\fB\-fsplit\-loops\fR" 4
  .IX Item "-fsplit-loops"
! Split a loop into two if it contains a condition that's always true
  for one side of the iteration space and false for the other.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-funswitch\-loops\fR" 4
  .IX Item "-funswitch-loops"
  Move branches with loop invariant conditions out of the loop, with duplicates
  of the loop on both branches (modified according to result of the condition).
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-fversion\-loops\-for\-strides\fR" 4
  .IX Item "-fversion-loops-for-strides"
  If a loop iterates over an array with a variable stride, create another
  version of the loop that assumes the stride is always one.  For example:
--- 13593,13623 ----
  number of iterations).
  .Sp
  Enabled by \fB\-O3\fR, \fB\-fprofile\-use\fR, and \fB\-fauto\-profile\fR.
! .IP \fB\-fmove\-loop\-invariants\fR 4
  .IX Item "-fmove-loop-invariants"
! Enables the loop invariant motion pass in the RTL loop optimizer.  Enabled
  at level \fB\-O1\fR and higher, except for \fB\-Og\fR.
! .IP \fB\-fmove\-loop\-stores\fR 4
  .IX Item "-fmove-loop-stores"
! Enables the loop store motion pass in the GIMPLE loop optimizer.  This
  moves invariant stores to after the end of the loop in exchange for
  carrying the stored value in a register across the iteration.
  Note for this option to have an effect \fB\-ftree\-loop\-im\fR has to
  be enabled as well.  Enabled at level \fB\-O1\fR and higher, except
  for \fB\-Og\fR.
! .IP \fB\-fsplit\-loops\fR 4
  .IX Item "-fsplit-loops"
! Split a loop into two if it contains a condition that\*(Aqs always true
  for one side of the iteration space and false for the other.
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-funswitch\-loops\fR 4
  .IX Item "-funswitch-loops"
  Move branches with loop invariant conditions out of the loop, with duplicates
  of the loop on both branches (modified according to result of the condition).
  .Sp
  Enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-fversion\-loops\-for\-strides\fR 4
  .IX Item "-fversion-loops-for-strides"
  If a loop iterates over an array with a variable stride, create another
  version of the loop that assumes the stride is always one.  For example:
*************** becomes:
*** 13709,13740 ****
  \&            x[i * stride] = ...;
  .Ve
  .Sp
! This is particularly useful for assumed-shape arrays in Fortran where
  (for example) it allows better vectorization assuming contiguous accesses.
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP "\fB\-ffunction\-sections\fR" 4
  .IX Item "-ffunction-sections"
  .PD 0
! .IP "\fB\-fdata\-sections\fR" 4
  .IX Item "-fdata-sections"
  .PD
  Place each function or data item into its own section in the output
  file if the target supports arbitrary sections.  The name of the
! function or the name of the data item determines the section's name
  in the output file.
  .Sp
  Use these options on systems where the linker can perform optimizations to
  improve locality of reference in the instruction space.  Most systems using the
! \&\s-1ELF\s0 object format have linkers with such optimizations.  On \s-1AIX,\s0 the linker
  rearranges sections (CSECTs) based on the call graph.  The performance impact
  varies.
  .Sp
  Together with a linker garbage collection (linker \fB\-\-gc\-sections\fR
! option) these options may lead to smaller statically-linked executables (after
  stripping).
  .Sp
! On \s-1ELF/DWARF\s0 systems these options do not degenerate the quality of the debug
  information.  There could be issues with other object files/debug info formats.
  .Sp
  Only use these options when there are significant benefits from doing so.  When
--- 13638,13669 ----
  \&            x[i * stride] = ...;
  .Ve
  .Sp
! This is particularly useful for assumed\-shape arrays in Fortran where
  (for example) it allows better vectorization assuming contiguous accesses.
  This flag is enabled by default at \fB\-O3\fR.
  It is also enabled by \fB\-fprofile\-use\fR and \fB\-fauto\-profile\fR.
! .IP \fB\-ffunction\-sections\fR 4
  .IX Item "-ffunction-sections"
  .PD 0
! .IP \fB\-fdata\-sections\fR 4
  .IX Item "-fdata-sections"
  .PD
  Place each function or data item into its own section in the output
  file if the target supports arbitrary sections.  The name of the
! function or the name of the data item determines the section\*(Aqs name
  in the output file.
  .Sp
  Use these options on systems where the linker can perform optimizations to
  improve locality of reference in the instruction space.  Most systems using the
! ELF object format have linkers with such optimizations.  On AIX, the linker
  rearranges sections (CSECTs) based on the call graph.  The performance impact
  varies.
  .Sp
  Together with a linker garbage collection (linker \fB\-\-gc\-sections\fR
! option) these options may lead to smaller statically\-linked executables (after
  stripping).
  .Sp
! On ELF/DWARF systems these options do not degenerate the quality of the debug
  information.  There could be issues with other object files/debug info formats.
  .Sp
  Only use these options when there are significant benefits from doing so.  When
*************** They prevent optimizations by the compil
*** 13744,13758 ****
  locations inside a translation unit since the locations are unknown until
  link time.  An example of such an optimization is relaxing calls to short call
  instructions.
! .IP "\fB\-fstdarg\-opt\fR" 4
  .IX Item "-fstdarg-opt"
  Optimize the prologue of variadic argument functions with respect to usage of
  those arguments.
! .IP "\fB\-fsection\-anchors\fR" 4
  .IX Item "-fsection-anchors"
  Try to reduce the number of symbolic address calculations by using
! shared \*(L"anchor\*(R" symbols to address nearby objects.  This transformation
! can help to reduce the number of \s-1GOT\s0 entries and \s-1GOT\s0 accesses on some
  targets.
  .Sp
  For example, the implementation of the following function \f(CW\*(C`foo\*(C'\fR:
--- 13673,13687 ----
  locations inside a translation unit since the locations are unknown until
  link time.  An example of such an optimization is relaxing calls to short call
  instructions.
! .IP \fB\-fstdarg\-opt\fR 4
  .IX Item "-fstdarg-opt"
  Optimize the prologue of variadic argument functions with respect to usage of
  those arguments.
! .IP \fB\-fsection\-anchors\fR 4
  .IX Item "-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.
  .Sp
  For example, the implementation of the following function \f(CW\*(C`foo\*(C'\fR:
*************** For example, the implementation of the f
*** 13765,13771 ****
  usually calculates the addresses of all three variables, but if you
  compile it with \fB\-fsection\-anchors\fR, it accesses the variables
  from a common anchor point instead.  The effect is similar to the
! following pseudocode (which isn't valid C):
  .Sp
  .Vb 5
  \&        int foo (void)
--- 13694,13700 ----
  usually calculates the addresses of all three variables, but if you
  compile it with \fB\-fsection\-anchors\fR, it accesses the variables
  from a common anchor point instead.  The effect is similar to the
! following pseudocode (which isn\*(Aqt valid C):
  .Sp
  .Vb 5
  \&        int foo (void)
*************** following pseudocode (which isn't valid
*** 13776,13785 ****
  .Ve
  .Sp
  Not all targets support this option.
! .IP "\fB\-fzero\-call\-used\-regs=\fR\fIchoice\fR" 4
  .IX Item "-fzero-call-used-regs=choice"
! Zero call-used registers at function return to increase program
! security by either mitigating Return-Oriented Programming (\s-1ROP\s0)
  attacks or preventing information leakage through registers.
  .Sp
  The possible values of \fIchoice\fR are the same as for the
--- 13705,13714 ----
  .Ve
  .Sp
  Not all targets support this option.
! .IP \fB\-fzero\-call\-used\-regs=\fR\fIchoice\fR 4
  .IX Item "-fzero-call-used-regs=choice"
! Zero call\-used registers at function return to increase program
! security by either mitigating Return\-Oriented Programming (ROP)
  attacks or preventing information leakage through registers.
  .Sp
  The possible values of \fIchoice\fR are the same as for the
*************** You can control this behavior for a spec
*** 13790,13797 ****
  attribute \f(CW\*(C`zero_call_used_regs\*(C'\fR.
  .IP "\fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR" 4
  .IX Item "--param name=value"
! In some places, \s-1GCC\s0 uses various constants to control the amount of
! optimization that is done.  For example, \s-1GCC\s0 does not inline functions
  that contain more than a certain number of instructions.  You can
  control some of these constants on the command line using the
  \&\fB\-\-param\fR option.
--- 13719,13726 ----
  attribute \f(CW\*(C`zero_call_used_regs\*(C'\fR.
  .IP "\fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR" 4
  .IX Item "--param name=value"
! In some places, GCC uses various constants to control the amount of
! optimization that is done.  For example, GCC does not inline functions
  that contain more than a certain number of instructions.  You can
  control some of these constants on the command line using the
  \&\fB\-\-param\fR option.
*************** use the \fB\-\-help=param \-Q\fR options
*** 13806,13859 ****
  In each case, the \fIvalue\fR is an integer.  The following choices
  of \fIname\fR are recognized for all targets:
  .RS 4
! .IP "\fBpredictable-branch-outcome\fR" 4
  .IX Item "predictable-branch-outcome"
  When branch is predicted to be taken with probability lower than this threshold
  (in percent), then it is considered well predictable.
! .IP "\fBmax-rtl-if-conversion-insns\fR" 4
  .IX Item "max-rtl-if-conversion-insns"
! \&\s-1RTL\s0 if-conversion tries to remove conditional branches around a block and
  replace them with conditionally executed instructions.  This parameter
  gives the maximum number of instructions in a block which should be
! considered for if-conversion.  The compiler will
! also use other heuristics to decide whether if-conversion is likely to be
  profitable.
! .IP "\fBmax-rtl-if-conversion-predictable-cost\fR" 4
  .IX Item "max-rtl-if-conversion-predictable-cost"
! \&\s-1RTL\s0 if-conversion will try to remove conditional branches around a block
  and replace them with conditionally executed instructions.  These parameters
  give the maximum permissible cost for the sequence that would be generated
! by if-conversion depending on whether the branch is statically determined
  to be predictable or not.  The units for this parameter are the same as
! those for the \s-1GCC\s0 internal seq_cost metric.  The compiler will try to
! provide a reasonable default for this parameter using the \s-1BRANCH_COST\s0
  target macro.
! .IP "\fBmax-crossjump-edges\fR" 4
  .IX Item "max-crossjump-edges"
! The maximum number of incoming edges to consider for cross-jumping.
  The algorithm used by \fB\-fcrossjumping\fR is O(N^2) in
  the number of edges incoming to each block.  Increasing values mean
  more aggressive optimization, making the compilation time increase with
  probably small improvement in executable size.
! .IP "\fBmin-crossjump-insns\fR" 4
  .IX Item "min-crossjump-insns"
  The minimum number of instructions that must be matched at the end
! of two blocks before cross-jumping is performed on them.  This
  value is ignored in the case where all instructions in the block being
! cross-jumped from are matched.
! .IP "\fBmax-grow-copy-bb-insns\fR" 4
  .IX Item "max-grow-copy-bb-insns"
  The maximum code size expansion factor when copying basic blocks
  instead of jumping.  The expansion is relative to a jump instruction.
! .IP "\fBmax-goto-duplication-insns\fR" 4
  .IX Item "max-goto-duplication-insns"
  The maximum number of instructions to duplicate to a block that jumps
  to a computed goto.  To avoid O(N^2) behavior in a number of
! passes, \s-1GCC\s0 factors computed gotos early in the compilation process,
  and unfactors them as late as possible.  Only computed jumps at the
! end of a basic blocks with no more than max-goto-duplication-insns are
  unfactored.
! .IP "\fBmax-delay-slot-insn-search\fR" 4
  .IX Item "max-delay-slot-insn-search"
  The maximum number of instructions to consider when looking for an
  instruction to fill a delay slot.  If more than this arbitrary number of
--- 13735,13788 ----
  In each case, the \fIvalue\fR is an integer.  The following choices
  of \fIname\fR are recognized for all targets:
  .RS 4
! .IP \fBpredictable\-branch\-outcome\fR 4
  .IX Item "predictable-branch-outcome"
  When branch is predicted to be taken with probability lower than this threshold
  (in percent), then it is considered well predictable.
! .IP \fBmax\-rtl\-if\-conversion\-insns\fR 4
  .IX Item "max-rtl-if-conversion-insns"
! RTL if\-conversion tries to remove conditional branches around a block and
  replace them with conditionally executed instructions.  This parameter
  gives the maximum number of instructions in a block which should be
! considered for if\-conversion.  The compiler will
! also use other heuristics to decide whether if\-conversion is likely to be
  profitable.
! .IP \fBmax\-rtl\-if\-conversion\-predictable\-cost\fR 4
  .IX Item "max-rtl-if-conversion-predictable-cost"
! RTL if\-conversion will try to remove conditional branches around a block
  and replace them with conditionally executed instructions.  These parameters
  give the maximum permissible cost for the sequence that would be generated
! by if\-conversion depending on whether the branch is statically determined
  to be predictable or not.  The units for this parameter are the same as
! those for the GCC internal seq_cost metric.  The compiler will try to
! provide a reasonable default for this parameter using the BRANCH_COST
  target macro.
! .IP \fBmax\-crossjump\-edges\fR 4
  .IX Item "max-crossjump-edges"
! The maximum number of incoming edges to consider for cross\-jumping.
  The algorithm used by \fB\-fcrossjumping\fR is O(N^2) in
  the number of edges incoming to each block.  Increasing values mean
  more aggressive optimization, making the compilation time increase with
  probably small improvement in executable size.
! .IP \fBmin\-crossjump\-insns\fR 4
  .IX Item "min-crossjump-insns"
  The minimum number of instructions that must be matched at the end
! of two blocks before cross\-jumping is performed on them.  This
  value is ignored in the case where all instructions in the block being
! cross\-jumped from are matched.
! .IP \fBmax\-grow\-copy\-bb\-insns\fR 4
  .IX Item "max-grow-copy-bb-insns"
  The maximum code size expansion factor when copying basic blocks
  instead of jumping.  The expansion is relative to a jump instruction.
! .IP \fBmax\-goto\-duplication\-insns\fR 4
  .IX Item "max-goto-duplication-insns"
  The maximum number of instructions to duplicate to a block that jumps
  to a computed goto.  To avoid O(N^2) behavior in a number of
! passes, 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.
! .IP \fBmax\-delay\-slot\-insn\-search\fR 4
  .IX Item "max-delay-slot-insn-search"
  The maximum number of instructions to consider when looking for an
  instruction to fill a delay slot.  If more than this arbitrary number of
*************** instructions are searched, the time savi
*** 13861,14032 ****
  are minimal, so stop searching.  Increasing values mean more
  aggressive optimization, making the compilation time increase with probably
  small improvement in execution time.
! .IP "\fBmax-delay-slot-live-search\fR" 4
  .IX Item "max-delay-slot-live-search"
  When trying to fill delay slots, the maximum number of instructions to
  consider when searching for a block with valid live register
  information.  Increasing this arbitrarily chosen value means more
  aggressive optimization, increasing the compilation time.  This parameter
  should be removed when the delay slot code is rewritten to maintain the
! control-flow graph.
! .IP "\fBmax-gcse-memory\fR" 4
  .IX Item "max-gcse-memory"
  The approximate maximum amount of memory in \f(CW\*(C`kB\*(C'\fR that can be allocated in
  order to perform the global common subexpression elimination
  optimization.  If more memory than specified is required, the
  optimization is not done.
! .IP "\fBmax-gcse-insertion-ratio\fR" 4
  .IX Item "max-gcse-insertion-ratio"
  If the ratio of expression insertions to deletions is larger than this value
! for any expression, then \s-1RTL PRE\s0 inserts or removes the expression and thus
  leaves partially redundant computations in the instruction stream.
! .IP "\fBmax-pending-list-length\fR" 4
  .IX Item "max-pending-list-length"
  The maximum number of pending dependencies scheduling allows
  before flushing the current state and starting over.  Large functions
  with few branches or calls can create excessively large lists which
  needlessly consume memory and resources.
! .IP "\fBmax-modulo-backtrack-attempts\fR" 4
  .IX Item "max-modulo-backtrack-attempts"
  The maximum number of backtrack attempts the scheduler should make
  when modulo scheduling a loop.  Larger values can exponentially increase
  compilation time.
! .IP "\fBmax-inline-functions-called-once-loop-depth\fR" 4
  .IX Item "max-inline-functions-called-once-loop-depth"
  Maximal loop depth of a call considered by inline heuristics that tries to
  inline all functions called once.
! .IP "\fBmax-inline-functions-called-once-insns\fR" 4
  .IX Item "max-inline-functions-called-once-insns"
  Maximal estimated size of functions produced while inlining functions called
  once.
! .IP "\fBmax-inline-insns-single\fR" 4
  .IX Item "max-inline-insns-single"
! Several parameters control the tree inliner used in \s-1GCC.\s0  This number sets the
! maximum number of instructions (counted in \s-1GCC\s0's internal representation) in a
  single function that the tree inliner considers for inlining.  This only
  affects functions declared inline and methods implemented in a class
! declaration (\*(C+).
! .IP "\fBmax-inline-insns-auto\fR" 4
  .IX Item "max-inline-insns-auto"
  When you use \fB\-finline\-functions\fR (included in \fB\-O3\fR),
  a lot of functions that would otherwise not be considered for inlining
  by the compiler are investigated.  To those functions, a different
  (more restrictive) limit compared to functions declared inline can
! be applied (\fB\-\-param max-inline-insns-auto\fR).
! .IP "\fBmax-inline-insns-small\fR" 4
  .IX Item "max-inline-insns-small"
  This is bound applied to calls which are considered relevant with
  \&\fB\-finline\-small\-functions\fR.
! .IP "\fBmax-inline-insns-size\fR" 4
  .IX Item "max-inline-insns-size"
  This is bound applied to calls which are optimized for size. Small growth
  may be desirable to anticipate optimization oppurtunities exposed by inlining.
! .IP "\fBuninlined-function-insns\fR" 4
  .IX Item "uninlined-function-insns"
  Number of instructions accounted by inliner for function overhead such as
  function prologue and epilogue.
! .IP "\fBuninlined-function-time\fR" 4
  .IX Item "uninlined-function-time"
  Extra time accounted by inliner for function overhead such as time needed to
  execute function prologue and epilogue.
! .IP "\fBinline-heuristics-hint-percent\fR" 4
  .IX Item "inline-heuristics-hint-percent"
! The scale (in percents) applied to \fBinline-insns-single\fR,
! \&\fBinline\-insns\-single\-O2\fR, \fBinline-insns-auto\fR
  when inline heuristics hints that inlining is
  very profitable (will enable later optimizations).
! .IP "\fBuninlined-thunk-insns\fR" 4
  .IX Item "uninlined-thunk-insns"
  .PD 0
! .IP "\fBuninlined-thunk-time\fR" 4
  .IX Item "uninlined-thunk-time"
  .PD
! Same as \fB\-\-param uninlined-function-insns\fR and
! \&\fB\-\-param uninlined-function-time\fR but applied to function thunks.
! .IP "\fBinline-min-speedup\fR" 4
  .IX Item "inline-min-speedup"
  When estimated performance improvement of caller + callee runtime exceeds this
  threshold (in percent), the function can be inlined regardless of the limit on
! \&\fB\-\-param max-inline-insns-single\fR and \fB\-\-param
! max-inline-insns-auto\fR.
! .IP "\fBlarge-function-insns\fR" 4
  .IX Item "large-function-insns"
  The limit specifying really large functions.  For functions larger than this
  limit after inlining, inlining is constrained by
! \&\fB\-\-param large-function-growth\fR.  This parameter is useful primarily
! to avoid extreme compilation time caused by non-linear algorithms used by the
  back end.
! .IP "\fBlarge-function-growth\fR" 4
  .IX Item "large-function-growth"
  Specifies maximal growth of large function caused by inlining in percents.
  For example, parameter value 100 limits large function growth to 2.0 times
  the original size.
! .IP "\fBlarge-unit-insns\fR" 4
  .IX Item "large-unit-insns"
  The limit specifying large translation unit.  Growth caused by inlining of
! units larger than this limit is limited by \fB\-\-param inline-unit-growth\fR.
  For small units this might be too tight.
  For example, consider a unit consisting of function A
  that is inline and B that just calls A three times.  If B is small relative to
  A, the growth of unit is 300\e% and yet such inlining is very sane.  For very
  large units consisting of small inlineable functions, however, the overall unit
  growth limit is needed to avoid exponential explosion of code size.  Thus for
! smaller units, the size is increased to \fB\-\-param large-unit-insns\fR
! before applying \fB\-\-param inline-unit-growth\fR.
! .IP "\fBlazy-modules\fR" 4
  .IX Item "lazy-modules"
! Maximum number of concurrently open \*(C+ module files when lazy loading.
! .IP "\fBinline-unit-growth\fR" 4
  .IX Item "inline-unit-growth"
  Specifies maximal overall growth of the compilation unit caused by inlining.
  For example, parameter value 20 limits unit growth to 1.2 times the original
  size. Cold functions (either marked cold via an attribute or by profile
  feedback) are not accounted into the unit size.
! .IP "\fBipa-cp-unit-growth\fR" 4
  .IX Item "ipa-cp-unit-growth"
  Specifies maximal overall growth of the compilation unit caused by
  interprocedural constant propagation.  For example, parameter value 10 limits
  unit growth to 1.1 times the original size.
! .IP "\fBipa-cp-large-unit-insns\fR" 4
  .IX Item "ipa-cp-large-unit-insns"
! The size of translation unit that IPA-CP pass considers large.
! .IP "\fBlarge-stack-frame\fR" 4
  .IX Item "large-stack-frame"
  The limit specifying large stack frames.  While inlining the algorithm is trying
  to not grow past this limit too much.
! .IP "\fBlarge-stack-frame-growth\fR" 4
  .IX Item "large-stack-frame-growth"
  Specifies maximal growth of large stack frames caused by inlining in percents.
  For example, parameter value 1000 limits large stack frame growth to 11 times
  the original size.
! .IP "\fBmax-inline-insns-recursive\fR" 4
  .IX Item "max-inline-insns-recursive"
  .PD 0
! .IP "\fBmax-inline-insns-recursive-auto\fR" 4
  .IX Item "max-inline-insns-recursive-auto"
  .PD
! Specifies the maximum number of instructions an out-of-line copy of a
! self-recursive inline
  function can grow into by performing recursive inlining.
  .Sp
! \&\fB\-\-param max-inline-insns-recursive\fR applies to functions
  declared inline.
  For functions not declared inline, recursive inlining
  happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
! enabled; \fB\-\-param max-inline-insns-recursive-auto\fR applies instead.
! .IP "\fBmax-inline-recursive-depth\fR" 4
  .IX Item "max-inline-recursive-depth"
  .PD 0
! .IP "\fBmax-inline-recursive-depth-auto\fR" 4
  .IX Item "max-inline-recursive-depth-auto"
  .PD
  Specifies the maximum recursion depth used for recursive inlining.
  .Sp
! \&\fB\-\-param max-inline-recursive-depth\fR applies to functions
  declared inline.  For functions not declared inline, recursive inlining
  happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
! enabled; \fB\-\-param max-inline-recursive-depth-auto\fR applies instead.
! .IP "\fBmin-inline-recursive-probability\fR" 4
  .IX Item "min-inline-recursive-probability"
  Recursive inlining is profitable only for function having deep recursion
  in average and can hurt for function having little recursion depth by
--- 13790,13961 ----
  are minimal, so stop searching.  Increasing values mean more
  aggressive optimization, making the compilation time increase with probably
  small improvement in execution time.
! .IP \fBmax\-delay\-slot\-live\-search\fR 4
  .IX Item "max-delay-slot-live-search"
  When trying to fill delay slots, the maximum number of instructions to
  consider when searching for a block with valid live register
  information.  Increasing this arbitrarily chosen value means more
  aggressive optimization, increasing the compilation time.  This parameter
  should be removed when the delay slot code is rewritten to maintain the
! control\-flow graph.
! .IP \fBmax\-gcse\-memory\fR 4
  .IX Item "max-gcse-memory"
  The approximate maximum amount of memory in \f(CW\*(C`kB\*(C'\fR that can be allocated in
  order to perform the global common subexpression elimination
  optimization.  If more memory than specified is required, the
  optimization is not done.
! .IP \fBmax\-gcse\-insertion\-ratio\fR 4
  .IX Item "max-gcse-insertion-ratio"
  If the ratio of expression insertions to deletions is larger than this value
! for any expression, then RTL PRE inserts or removes the expression and thus
  leaves partially redundant computations in the instruction stream.
! .IP \fBmax\-pending\-list\-length\fR 4
  .IX Item "max-pending-list-length"
  The maximum number of pending dependencies scheduling allows
  before flushing the current state and starting over.  Large functions
  with few branches or calls can create excessively large lists which
  needlessly consume memory and resources.
! .IP \fBmax\-modulo\-backtrack\-attempts\fR 4
  .IX Item "max-modulo-backtrack-attempts"
  The maximum number of backtrack attempts the scheduler should make
  when modulo scheduling a loop.  Larger values can exponentially increase
  compilation time.
! .IP \fBmax\-inline\-functions\-called\-once\-loop\-depth\fR 4
  .IX Item "max-inline-functions-called-once-loop-depth"
  Maximal loop depth of a call considered by inline heuristics that tries to
  inline all functions called once.
! .IP \fBmax\-inline\-functions\-called\-once\-insns\fR 4
  .IX Item "max-inline-functions-called-once-insns"
  Maximal estimated size of functions produced while inlining functions called
  once.
! .IP \fBmax\-inline\-insns\-single\fR 4
  .IX Item "max-inline-insns-single"
! Several parameters control the tree inliner used in GCC.  This number sets the
! maximum number of instructions (counted in GCC\*(Aqs internal representation) in a
  single function that the tree inliner considers for inlining.  This only
  affects functions declared inline and methods implemented in a class
! declaration (C++).
! .IP \fBmax\-inline\-insns\-auto\fR 4
  .IX Item "max-inline-insns-auto"
  When you use \fB\-finline\-functions\fR (included in \fB\-O3\fR),
  a lot of functions that would otherwise not be considered for inlining
  by the compiler are investigated.  To those functions, a different
  (more restrictive) limit compared to functions declared inline can
! be applied (\fB\-\-param max\-inline\-insns\-auto\fR).
! .IP \fBmax\-inline\-insns\-small\fR 4
  .IX Item "max-inline-insns-small"
  This is bound applied to calls which are considered relevant with
  \&\fB\-finline\-small\-functions\fR.
! .IP \fBmax\-inline\-insns\-size\fR 4
  .IX Item "max-inline-insns-size"
  This is bound applied to calls which are optimized for size. Small growth
  may be desirable to anticipate optimization oppurtunities exposed by inlining.
! .IP \fBuninlined\-function\-insns\fR 4
  .IX Item "uninlined-function-insns"
  Number of instructions accounted by inliner for function overhead such as
  function prologue and epilogue.
! .IP \fBuninlined\-function\-time\fR 4
  .IX Item "uninlined-function-time"
  Extra time accounted by inliner for function overhead such as time needed to
  execute function prologue and epilogue.
! .IP \fBinline\-heuristics\-hint\-percent\fR 4
  .IX Item "inline-heuristics-hint-percent"
! The scale (in percents) applied to \fBinline\-insns\-single\fR,
! \&\fBinline\-insns\-single\-O2\fR, \fBinline\-insns\-auto\fR
  when inline heuristics hints that inlining is
  very profitable (will enable later optimizations).
! .IP \fBuninlined\-thunk\-insns\fR 4
  .IX Item "uninlined-thunk-insns"
  .PD 0
! .IP \fBuninlined\-thunk\-time\fR 4
  .IX Item "uninlined-thunk-time"
  .PD
! Same as \fB\-\-param uninlined\-function\-insns\fR and
! \&\fB\-\-param uninlined\-function\-time\fR but applied to function thunks.
! .IP \fBinline\-min\-speedup\fR 4
  .IX Item "inline-min-speedup"
  When estimated performance improvement of caller + callee runtime exceeds this
  threshold (in percent), the function can be inlined regardless of the limit on
! \&\fB\-\-param max\-inline\-insns\-single\fR and \fB\-\-param
! max\-inline\-insns\-auto\fR.
! .IP \fBlarge\-function\-insns\fR 4
  .IX Item "large-function-insns"
  The limit specifying really large functions.  For functions larger than this
  limit after inlining, inlining is constrained by
! \&\fB\-\-param large\-function\-growth\fR.  This parameter is useful primarily
! to avoid extreme compilation time caused by non\-linear algorithms used by the
  back end.
! .IP \fBlarge\-function\-growth\fR 4
  .IX Item "large-function-growth"
  Specifies maximal growth of large function caused by inlining in percents.
  For example, parameter value 100 limits large function growth to 2.0 times
  the original size.
! .IP \fBlarge\-unit\-insns\fR 4
  .IX Item "large-unit-insns"
  The limit specifying large translation unit.  Growth caused by inlining of
! units larger than this limit is limited by \fB\-\-param inline\-unit\-growth\fR.
  For small units this might be too tight.
  For example, consider a unit consisting of function A
  that is inline and B that just calls A three times.  If B is small relative to
  A, the growth of unit is 300\e% and yet such inlining is very sane.  For very
  large units consisting of small inlineable functions, however, the overall unit
  growth limit is needed to avoid exponential explosion of code size.  Thus for
! smaller units, the size is increased to \fB\-\-param large\-unit\-insns\fR
! before applying \fB\-\-param inline\-unit\-growth\fR.
! .IP \fBlazy\-modules\fR 4
  .IX Item "lazy-modules"
! Maximum number of concurrently open C++ module files when lazy loading.
! .IP \fBinline\-unit\-growth\fR 4
  .IX Item "inline-unit-growth"
  Specifies maximal overall growth of the compilation unit caused by inlining.
  For example, parameter value 20 limits unit growth to 1.2 times the original
  size. Cold functions (either marked cold via an attribute or by profile
  feedback) are not accounted into the unit size.
! .IP \fBipa\-cp\-unit\-growth\fR 4
  .IX Item "ipa-cp-unit-growth"
  Specifies maximal overall growth of the compilation unit caused by
  interprocedural constant propagation.  For example, parameter value 10 limits
  unit growth to 1.1 times the original size.
! .IP \fBipa\-cp\-large\-unit\-insns\fR 4
  .IX Item "ipa-cp-large-unit-insns"
! The size of translation unit that IPA\-CP pass considers large.
! .IP \fBlarge\-stack\-frame\fR 4
  .IX Item "large-stack-frame"
  The limit specifying large stack frames.  While inlining the algorithm is trying
  to not grow past this limit too much.
! .IP \fBlarge\-stack\-frame\-growth\fR 4
  .IX Item "large-stack-frame-growth"
  Specifies maximal growth of large stack frames caused by inlining in percents.
  For example, parameter value 1000 limits large stack frame growth to 11 times
  the original size.
! .IP \fBmax\-inline\-insns\-recursive\fR 4
  .IX Item "max-inline-insns-recursive"
  .PD 0
! .IP \fBmax\-inline\-insns\-recursive\-auto\fR 4
  .IX Item "max-inline-insns-recursive-auto"
  .PD
! Specifies the maximum number of instructions an out\-of\-line copy of a
! self\-recursive inline
  function can grow into by performing recursive inlining.
  .Sp
! \&\fB\-\-param max\-inline\-insns\-recursive\fR applies to functions
  declared inline.
  For functions not declared inline, recursive inlining
  happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
! enabled; \fB\-\-param max\-inline\-insns\-recursive\-auto\fR applies instead.
! .IP \fBmax\-inline\-recursive\-depth\fR 4
  .IX Item "max-inline-recursive-depth"
  .PD 0
! .IP \fBmax\-inline\-recursive\-depth\-auto\fR 4
  .IX Item "max-inline-recursive-depth-auto"
  .PD
  Specifies the maximum recursion depth used for recursive inlining.
  .Sp
! \&\fB\-\-param max\-inline\-recursive\-depth\fR applies to functions
  declared inline.  For functions not declared inline, recursive inlining
  happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
! enabled; \fB\-\-param max\-inline\-recursive\-depth\-auto\fR applies instead.
! .IP \fBmin\-inline\-recursive\-probability\fR 4
  .IX Item "min-inline-recursive-probability"
  Recursive inlining is profitable only for function having deep recursion
  in average and can hurt for function having little recursion depth by
*************** When profile feedback is available (see
*** 14037,14255 ****
  recursion depth can be guessed from the probability that function recurses
  via a given call expression.  This parameter limits inlining only to call
  expressions whose probability exceeds the given threshold (in percents).
! .IP "\fBearly-inlining-insns\fR" 4
  .IX Item "early-inlining-insns"
  Specify growth that the early inliner can make.  In effect it increases
  the amount of inlining for code having a large abstraction penalty.
! .IP "\fBmax-early-inliner-iterations\fR" 4
  .IX Item "max-early-inliner-iterations"
  Limit of iterations of the early inliner.  This basically bounds
  the number of nested indirect calls the early inliner can resolve.
  Deeper chains are still handled by late inlining.
! .IP "\fBcomdat-sharing-probability\fR" 4
  .IX Item "comdat-sharing-probability"
! Probability (in percent) that \*(C+ inline function with comdat visibility
  are shared across multiple compilation units.
! .IP "\fBmodref-max-bases\fR" 4
  .IX Item "modref-max-bases"
  .PD 0
! .IP "\fBmodref-max-refs\fR" 4
  .IX Item "modref-max-refs"
! .IP "\fBmodref-max-accesses\fR" 4
  .IX Item "modref-max-accesses"
  .PD
  Specifies the maximal number of base pointers, references and accesses stored
  for a single function by mod/ref analysis.
! .IP "\fBmodref-max-tests\fR" 4
  .IX Item "modref-max-tests"
  Specifies the maxmal number of tests alias oracle can perform to disambiguate
  memory locations using the mod/ref information.  This parameter ought to be
! bigger than \fB\-\-param modref-max-bases\fR and \fB\-\-param
! modref-max-refs\fR.
! .IP "\fBmodref-max-depth\fR" 4
  .IX Item "modref-max-depth"
! Specifies the maximum depth of \s-1DFS\s0 walk used by modref escape analysis.
  Setting to 0 disables the analysis completely.
! .IP "\fBmodref-max-escape-points\fR" 4
  .IX Item "modref-max-escape-points"
! Specifies the maximum number of escape points tracked by modref per SSA-name.
! .IP "\fBmodref-max-adjustments\fR" 4
  .IX Item "modref-max-adjustments"
  Specifies the maximum number the access range is enlarged during modref dataflow
  analysis.
! .IP "\fBprofile-func-internal-id\fR" 4
  .IX Item "profile-func-internal-id"
  A parameter to control whether to use function internal id in profile
  database lookup. If the value is 0, the compiler uses an id that
  is based on function assembler name and filename, which makes old profile
  data more tolerant to source changes such as function reordering etc.
! .IP "\fBmin-vect-loop-bound\fR" 4
  .IX Item "min-vect-loop-bound"
  The minimum number of iterations under which loops are not vectorized
  when \fB\-ftree\-vectorize\fR is used.  The number of iterations after
  vectorization needs to be greater than the value specified by this option
  to allow vectorization.
! .IP "\fBgcse-cost-distance-ratio\fR" 4
  .IX Item "gcse-cost-distance-ratio"
  Scaling factor in calculation of maximum distance an expression
! can be moved by \s-1GCSE\s0 optimizations.  This is currently supported only in the
  code hoisting pass.  The bigger the ratio, the more aggressive code hoisting
  is with simple expressions, i.e., the expressions that have cost
! less than \fBgcse-unrestricted-cost\fR.  Specifying 0 disables
  hoisting of simple expressions.
! .IP "\fBgcse-unrestricted-cost\fR" 4
  .IX Item "gcse-unrestricted-cost"
  Cost, roughly measured as the cost of a single typical machine
! instruction, at which \s-1GCSE\s0 optimizations do not constrain
  the distance an expression can travel.  This is currently
  supported only in the code hoisting pass.  The lesser the cost,
  the more aggressive code hoisting is.  Specifying 0 
  allows all expressions to travel unrestricted distances.
! .IP "\fBmax-hoist-depth\fR" 4
  .IX Item "max-hoist-depth"
  The depth of search in the dominator tree for expressions to hoist.
  This is used to avoid quadratic behavior in hoisting algorithm.
  The value of 0 does not limit on the search, but may slow down compilation
  of huge functions.
! .IP "\fBmax-tail-merge-comparisons\fR" 4
  .IX Item "max-tail-merge-comparisons"
  The maximum amount of similar bbs to compare a bb with.  This is used to
  avoid quadratic behavior in tree tail merging.
! .IP "\fBmax-tail-merge-iterations\fR" 4
  .IX Item "max-tail-merge-iterations"
  The maximum amount of iterations of the pass over the function.  This is used to
  limit compilation time in tree tail merging.
! .IP "\fBstore-merging-allow-unaligned\fR" 4
  .IX Item "store-merging-allow-unaligned"
  Allow the store merging pass to introduce unaligned stores if it is legal to
  do so.
! .IP "\fBmax-stores-to-merge\fR" 4
  .IX Item "max-stores-to-merge"
  The maximum number of stores to attempt to merge into wider stores in the store
  merging pass.
! .IP "\fBmax-store-chains-to-track\fR" 4
  .IX Item "max-store-chains-to-track"
  The maximum number of store chains to track at the same time in the attempt
  to merge them into wider stores in the store merging pass.
! .IP "\fBmax-stores-to-track\fR" 4
  .IX Item "max-stores-to-track"
  The maximum number of stores to track at the same time in the attemt to
  to merge them into wider stores in the store merging pass.
! .IP "\fBmax-unrolled-insns\fR" 4
  .IX Item "max-unrolled-insns"
  The maximum number of instructions that a loop may have to be unrolled.
  If a loop is unrolled, this parameter also determines how many times
  the loop code is unrolled.
! .IP "\fBmax-average-unrolled-insns\fR" 4
  .IX Item "max-average-unrolled-insns"
  The maximum number of instructions biased by probabilities of their execution
  that a loop may have to be unrolled.  If a loop is unrolled,
  this parameter also determines how many times the loop code is unrolled.
! .IP "\fBmax-unroll-times\fR" 4
  .IX Item "max-unroll-times"
  The maximum number of unrollings of a single loop.
! .IP "\fBmax-peeled-insns\fR" 4
  .IX Item "max-peeled-insns"
  The maximum number of instructions that a loop may have to be peeled.
  If a loop is peeled, this parameter also determines how many times
  the loop code is peeled.
! .IP "\fBmax-peel-times\fR" 4
  .IX Item "max-peel-times"
  The maximum number of peelings of a single loop.
! .IP "\fBmax-peel-branches\fR" 4
  .IX Item "max-peel-branches"
  The maximum number of branches on the hot path through the peeled sequence.
! .IP "\fBmax-completely-peeled-insns\fR" 4
  .IX Item "max-completely-peeled-insns"
  The maximum number of insns of a completely peeled loop.
! .IP "\fBmax-completely-peel-times\fR" 4
  .IX Item "max-completely-peel-times"
  The maximum number of iterations of a loop to be suitable for complete peeling.
! .IP "\fBmax-completely-peel-loop-nest-depth\fR" 4
  .IX Item "max-completely-peel-loop-nest-depth"
  The maximum depth of a loop nest suitable for complete peeling.
! .IP "\fBmax-unswitch-insns\fR" 4
  .IX Item "max-unswitch-insns"
  The maximum number of insns of an unswitched loop.
! .IP "\fBmax-unswitch-depth\fR" 4
  .IX Item "max-unswitch-depth"
  The maximum depth of a loop nest to be unswitched.
! .IP "\fBlim-expensive\fR" 4
  .IX Item "lim-expensive"
  The minimum cost of an expensive expression in the loop invariant motion.
! .IP "\fBmin-loop-cond-split-prob\fR" 4
  .IX Item "min-loop-cond-split-prob"
! When \s-1FDO\s0 profile information is available, \fBmin-loop-cond-split-prob\fR
! specifies minimum threshold for probability of semi-invariant condition
  statement to trigger loop split.
! .IP "\fBiv-consider-all-candidates-bound\fR" 4
  .IX Item "iv-consider-all-candidates-bound"
  Bound on number of candidates for induction variables, below which
  all candidates are considered for each use in induction variable
  optimizations.  If there are more candidates than this,
  only the most relevant ones are considered to avoid quadratic time complexity.
! .IP "\fBiv-max-considered-uses\fR" 4
  .IX Item "iv-max-considered-uses"
  The induction variable optimizations give up on loops that contain more
  induction variable uses.
! .IP "\fBiv-always-prune-cand-set-bound\fR" 4
  .IX Item "iv-always-prune-cand-set-bound"
  If the number of candidates in the set is smaller than this value,
  always try to remove unnecessary ivs from the set
  when adding a new one.
! .IP "\fBavg-loop-niter\fR" 4
  .IX Item "avg-loop-niter"
  Average number of iterations of a loop.
! .IP "\fBdse-max-object-size\fR" 4
  .IX Item "dse-max-object-size"
  Maximum size (in bytes) of objects tracked bytewise by dead store elimination.
  Larger values may result in larger compilation times.
! .IP "\fBdse-max-alias-queries-per-store\fR" 4
  .IX Item "dse-max-alias-queries-per-store"
  Maximum number of queries into the alias oracle per store.
  Larger values result in larger compilation times and may result in more
  removed dead stores.
! .IP "\fBscev-max-expr-size\fR" 4
  .IX Item "scev-max-expr-size"
  Bound on size of expressions used in the scalar evolutions analyzer.
  Large expressions slow the analyzer.
! .IP "\fBscev-max-expr-complexity\fR" 4
  .IX Item "scev-max-expr-complexity"
  Bound on the complexity of the expressions in the scalar evolutions analyzer.
  Complex expressions slow the analyzer.
! .IP "\fBmax-tree-if-conversion-phi-args\fR" 4
  .IX Item "max-tree-if-conversion-phi-args"
! Maximum number of arguments in a \s-1PHI\s0 supported by \s-1TREE\s0 if conversion
  unless the loop is marked with simd pragma.
! .IP "\fBvect-max-layout-candidates\fR" 4
  .IX Item "vect-max-layout-candidates"
  The maximum number of possible vector layouts (such as permutations)
! to consider when optimizing to-be-vectorized code.
! .IP "\fBvect-max-version-for-alignment-checks\fR" 4
  .IX Item "vect-max-version-for-alignment-checks"
! The maximum number of run-time checks that can be performed when
  doing loop versioning for alignment in the vectorizer.
! .IP "\fBvect-max-version-for-alias-checks\fR" 4
  .IX Item "vect-max-version-for-alias-checks"
! The maximum number of run-time checks that can be performed when
  doing loop versioning for alias in the vectorizer.
! .IP "\fBvect-max-peeling-for-alignment\fR" 4
  .IX Item "vect-max-peeling-for-alignment"
  The maximum number of loop peels to enhance access alignment
  for vectorizer. Value \-1 means no limit.
! .IP "\fBmax-iterations-to-track\fR" 4
  .IX Item "max-iterations-to-track"
! The maximum number of iterations of a loop the brute-force algorithm
  for analysis of the number of iterations of the loop tries to evaluate.
! .IP "\fBhot-bb-count-fraction\fR" 4
  .IX Item "hot-bb-count-fraction"
  The denominator n of fraction 1/n of the maximal execution count of a
  basic block in the entire program that a basic block needs to at least
  have in order to be considered hot.  The default is 10000, which means
  that a basic block is considered hot if its execution count is greater
  than 1/10000 of the maximal execution count.  0 means that it is never
! considered hot.  Used in non-LTO mode.
! .IP "\fBhot-bb-count-ws-permille\fR" 4
  .IX Item "hot-bb-count-ws-permille"
  The number of most executed permilles, ranging from 0 to 1000, of the
  profiled execution of the entire program to which the execution count
--- 13966,14184 ----
  recursion depth can be guessed from the probability that function recurses
  via a given call expression.  This parameter limits inlining only to call
  expressions whose probability exceeds the given threshold (in percents).
! .IP \fBearly\-inlining\-insns\fR 4
  .IX Item "early-inlining-insns"
  Specify growth that the early inliner can make.  In effect it increases
  the amount of inlining for code having a large abstraction penalty.
! .IP \fBmax\-early\-inliner\-iterations\fR 4
  .IX Item "max-early-inliner-iterations"
  Limit of iterations of the early inliner.  This basically bounds
  the number of nested indirect calls the early inliner can resolve.
  Deeper chains are still handled by late inlining.
! .IP \fBcomdat\-sharing\-probability\fR 4
  .IX Item "comdat-sharing-probability"
! Probability (in percent) that C++ inline function with comdat visibility
  are shared across multiple compilation units.
! .IP \fBmodref\-max\-bases\fR 4
  .IX Item "modref-max-bases"
  .PD 0
! .IP \fBmodref\-max\-refs\fR 4
  .IX Item "modref-max-refs"
! .IP \fBmodref\-max\-accesses\fR 4
  .IX Item "modref-max-accesses"
  .PD
  Specifies the maximal number of base pointers, references and accesses stored
  for a single function by mod/ref analysis.
! .IP \fBmodref\-max\-tests\fR 4
  .IX Item "modref-max-tests"
  Specifies the maxmal number of tests alias oracle can perform to disambiguate
  memory locations using the mod/ref information.  This parameter ought to be
! bigger than \fB\-\-param modref\-max\-bases\fR and \fB\-\-param
! modref\-max\-refs\fR.
! .IP \fBmodref\-max\-depth\fR 4
  .IX Item "modref-max-depth"
! Specifies the maximum depth of DFS walk used by modref escape analysis.
  Setting to 0 disables the analysis completely.
! .IP \fBmodref\-max\-escape\-points\fR 4
  .IX Item "modref-max-escape-points"
! Specifies the maximum number of escape points tracked by modref per SSA\-name.
! .IP \fBmodref\-max\-adjustments\fR 4
  .IX Item "modref-max-adjustments"
  Specifies the maximum number the access range is enlarged during modref dataflow
  analysis.
! .IP \fBprofile\-func\-internal\-id\fR 4
  .IX Item "profile-func-internal-id"
  A parameter to control whether to use function internal id in profile
  database lookup. If the value is 0, the compiler uses an id that
  is based on function assembler name and filename, which makes old profile
  data more tolerant to source changes such as function reordering etc.
! .IP \fBmin\-vect\-loop\-bound\fR 4
  .IX Item "min-vect-loop-bound"
  The minimum number of iterations under which loops are not vectorized
  when \fB\-ftree\-vectorize\fR is used.  The number of iterations after
  vectorization needs to be greater than the value specified by this option
  to allow vectorization.
! .IP \fBgcse\-cost\-distance\-ratio\fR 4
  .IX Item "gcse-cost-distance-ratio"
  Scaling factor in calculation of maximum distance an expression
! can be moved by GCSE optimizations.  This is currently supported only in the
  code hoisting pass.  The bigger the ratio, the more aggressive code hoisting
  is with simple expressions, i.e., the expressions that have cost
! less than \fBgcse\-unrestricted\-cost\fR.  Specifying 0 disables
  hoisting of simple expressions.
! .IP \fBgcse\-unrestricted\-cost\fR 4
  .IX Item "gcse-unrestricted-cost"
  Cost, roughly measured as the cost of a single typical machine
! instruction, at which GCSE optimizations do not constrain
  the distance an expression can travel.  This is currently
  supported only in the code hoisting pass.  The lesser the cost,
  the more aggressive code hoisting is.  Specifying 0 
  allows all expressions to travel unrestricted distances.
! .IP \fBmax\-hoist\-depth\fR 4
  .IX Item "max-hoist-depth"
  The depth of search in the dominator tree for expressions to hoist.
  This is used to avoid quadratic behavior in hoisting algorithm.
  The value of 0 does not limit on the search, but may slow down compilation
  of huge functions.
! .IP \fBmax\-tail\-merge\-comparisons\fR 4
  .IX Item "max-tail-merge-comparisons"
  The maximum amount of similar bbs to compare a bb with.  This is used to
  avoid quadratic behavior in tree tail merging.
! .IP \fBmax\-tail\-merge\-iterations\fR 4
  .IX Item "max-tail-merge-iterations"
  The maximum amount of iterations of the pass over the function.  This is used to
  limit compilation time in tree tail merging.
! .IP \fBstore\-merging\-allow\-unaligned\fR 4
  .IX Item "store-merging-allow-unaligned"
  Allow the store merging pass to introduce unaligned stores if it is legal to
  do so.
! .IP \fBmax\-stores\-to\-merge\fR 4
  .IX Item "max-stores-to-merge"
  The maximum number of stores to attempt to merge into wider stores in the store
  merging pass.
! .IP \fBmax\-store\-chains\-to\-track\fR 4
  .IX Item "max-store-chains-to-track"
  The maximum number of store chains to track at the same time in the attempt
  to merge them into wider stores in the store merging pass.
! .IP \fBmax\-stores\-to\-track\fR 4
  .IX Item "max-stores-to-track"
  The maximum number of stores to track at the same time in the attemt to
  to merge them into wider stores in the store merging pass.
! .IP \fBmax\-unrolled\-insns\fR 4
  .IX Item "max-unrolled-insns"
  The maximum number of instructions that a loop may have to be unrolled.
  If a loop is unrolled, this parameter also determines how many times
  the loop code is unrolled.
! .IP \fBmax\-average\-unrolled\-insns\fR 4
  .IX Item "max-average-unrolled-insns"
  The maximum number of instructions biased by probabilities of their execution
  that a loop may have to be unrolled.  If a loop is unrolled,
  this parameter also determines how many times the loop code is unrolled.
! .IP \fBmax\-unroll\-times\fR 4
  .IX Item "max-unroll-times"
  The maximum number of unrollings of a single loop.
! .IP \fBmax\-peeled\-insns\fR 4
  .IX Item "max-peeled-insns"
  The maximum number of instructions that a loop may have to be peeled.
  If a loop is peeled, this parameter also determines how many times
  the loop code is peeled.
! .IP \fBmax\-peel\-times\fR 4
  .IX Item "max-peel-times"
  The maximum number of peelings of a single loop.
! .IP \fBmax\-peel\-branches\fR 4
  .IX Item "max-peel-branches"
  The maximum number of branches on the hot path through the peeled sequence.
! .IP \fBmax\-completely\-peeled\-insns\fR 4
  .IX Item "max-completely-peeled-insns"
  The maximum number of insns of a completely peeled loop.
! .IP \fBmax\-completely\-peel\-times\fR 4
  .IX Item "max-completely-peel-times"
  The maximum number of iterations of a loop to be suitable for complete peeling.
! .IP \fBmax\-completely\-peel\-loop\-nest\-depth\fR 4
  .IX Item "max-completely-peel-loop-nest-depth"
  The maximum depth of a loop nest suitable for complete peeling.
! .IP \fBmax\-unswitch\-insns\fR 4
  .IX Item "max-unswitch-insns"
  The maximum number of insns of an unswitched loop.
! .IP \fBmax\-unswitch\-depth\fR 4
  .IX Item "max-unswitch-depth"
  The maximum depth of a loop nest to be unswitched.
! .IP \fBlim\-expensive\fR 4
  .IX Item "lim-expensive"
  The minimum cost of an expensive expression in the loop invariant motion.
! .IP \fBmin\-loop\-cond\-split\-prob\fR 4
  .IX Item "min-loop-cond-split-prob"
! When FDO profile information is available, \fBmin\-loop\-cond\-split\-prob\fR
! specifies minimum threshold for probability of semi\-invariant condition
  statement to trigger loop split.
! .IP \fBiv\-consider\-all\-candidates\-bound\fR 4
  .IX Item "iv-consider-all-candidates-bound"
  Bound on number of candidates for induction variables, below which
  all candidates are considered for each use in induction variable
  optimizations.  If there are more candidates than this,
  only the most relevant ones are considered to avoid quadratic time complexity.
! .IP \fBiv\-max\-considered\-uses\fR 4
  .IX Item "iv-max-considered-uses"
  The induction variable optimizations give up on loops that contain more
  induction variable uses.
! .IP \fBiv\-always\-prune\-cand\-set\-bound\fR 4
  .IX Item "iv-always-prune-cand-set-bound"
  If the number of candidates in the set is smaller than this value,
  always try to remove unnecessary ivs from the set
  when adding a new one.
! .IP \fBavg\-loop\-niter\fR 4
  .IX Item "avg-loop-niter"
  Average number of iterations of a loop.
! .IP \fBdse\-max\-object\-size\fR 4
  .IX Item "dse-max-object-size"
  Maximum size (in bytes) of objects tracked bytewise by dead store elimination.
  Larger values may result in larger compilation times.
! .IP \fBdse\-max\-alias\-queries\-per\-store\fR 4
  .IX Item "dse-max-alias-queries-per-store"
  Maximum number of queries into the alias oracle per store.
  Larger values result in larger compilation times and may result in more
  removed dead stores.
! .IP \fBscev\-max\-expr\-size\fR 4
  .IX Item "scev-max-expr-size"
  Bound on size of expressions used in the scalar evolutions analyzer.
  Large expressions slow the analyzer.
! .IP \fBscev\-max\-expr\-complexity\fR 4
  .IX Item "scev-max-expr-complexity"
  Bound on the complexity of the expressions in the scalar evolutions analyzer.
  Complex expressions slow the analyzer.
! .IP \fBmax\-tree\-if\-conversion\-phi\-args\fR 4
  .IX Item "max-tree-if-conversion-phi-args"
! Maximum number of arguments in a PHI supported by TREE if conversion
  unless the loop is marked with simd pragma.
! .IP \fBvect\-max\-layout\-candidates\fR 4
  .IX Item "vect-max-layout-candidates"
  The maximum number of possible vector layouts (such as permutations)
! to consider when optimizing to\-be\-vectorized code.
! .IP \fBvect\-max\-version\-for\-alignment\-checks\fR 4
  .IX Item "vect-max-version-for-alignment-checks"
! The maximum number of run\-time checks that can be performed when
  doing loop versioning for alignment in the vectorizer.
! .IP \fBvect\-max\-version\-for\-alias\-checks\fR 4
  .IX Item "vect-max-version-for-alias-checks"
! The maximum number of run\-time checks that can be performed when
  doing loop versioning for alias in the vectorizer.
! .IP \fBvect\-max\-peeling\-for\-alignment\fR 4
  .IX Item "vect-max-peeling-for-alignment"
  The maximum number of loop peels to enhance access alignment
  for vectorizer. Value \-1 means no limit.
! .IP \fBmax\-iterations\-to\-track\fR 4
  .IX Item "max-iterations-to-track"
! The maximum number of iterations of a loop the brute\-force algorithm
  for analysis of the number of iterations of the loop tries to evaluate.
! .IP \fBhot\-bb\-count\-fraction\fR 4
  .IX Item "hot-bb-count-fraction"
  The denominator n of fraction 1/n of the maximal execution count of a
  basic block in the entire program that a basic block needs to at least
  have in order to be considered hot.  The default is 10000, which means
  that a basic block is considered hot if its execution count is greater
  than 1/10000 of the maximal execution count.  0 means that it is never
! considered hot.  Used in non\-LTO mode.
! .IP \fBhot\-bb\-count\-ws\-permille\fR 4
  .IX Item "hot-bb-count-ws-permille"
  The number of most executed permilles, ranging from 0 to 1000, of the
  profiled execution of the entire program to which the execution count
*************** of a basic block must be part of in orde
*** 14257,14264 ****
  default is 990, which means that a basic block is considered hot if
  its execution count contributes to the upper 990 permilles, or 99.0%,
  of the profiled execution of the entire program.  0 means that it is
! never considered hot.  Used in \s-1LTO\s0 mode.
! .IP "\fBhot-bb-frequency-fraction\fR" 4
  .IX Item "hot-bb-frequency-fraction"
  The denominator n of fraction 1/n of the execution frequency of the
  entry block of a function that a basic block of this function needs
--- 14186,14193 ----
  default is 990, which means that a basic block is considered hot if
  its execution count contributes to the upper 990 permilles, or 99.0%,
  of the profiled execution of the entire program.  0 means that it is
! never considered hot.  Used in LTO mode.
! .IP \fBhot\-bb\-frequency\-fraction\fR 4
  .IX Item "hot-bb-frequency-fraction"
  The denominator n of fraction 1/n of the execution frequency of the
  entry block of a function that a basic block of this function needs
*************** to at least have in order to be consider
*** 14266,14272 ****
  which means that a basic block is considered hot in a function if it
  is executed more frequently than 1/1000 of the frequency of the entry
  block of the function.  0 means that it is never considered hot.
! .IP "\fBunlikely-bb-count-fraction\fR" 4
  .IX Item "unlikely-bb-count-fraction"
  The denominator n of fraction 1/n of the number of profiled runs of
  the entire program below which the execution count of a basic block
--- 14195,14201 ----
  which means that a basic block is considered hot in a function if it
  is executed more frequently than 1/1000 of the frequency of the entry
  block of the function.  0 means that it is never considered hot.
! .IP \fBunlikely\-bb\-count\-fraction\fR 4
  .IX Item "unlikely-bb-count-fraction"
  The denominator n of fraction 1/n of the number of profiled runs of
  the entire program below which the execution count of a basic block
*************** must be in order for the basic block to
*** 14274,14280 ****
  The default is 20, which means that a basic block is considered unlikely
  executed if it is executed in fewer than 1/20, or 5%, of the runs of
  the program.  0 means that it is always considered unlikely executed.
! .IP "\fBmax-predicted-iterations\fR" 4
  .IX Item "max-predicted-iterations"
  The maximum number of loop iterations we predict statically.  This is useful
  in cases where a function contains a single loop with known bound and
--- 14203,14209 ----
  The default is 20, which means that a basic block is considered unlikely
  executed if it is executed in fewer than 1/20, or 5%, of the runs of
  the program.  0 means that it is always considered unlikely executed.
! .IP \fBmax\-predicted\-iterations\fR 4
  .IX Item "max-predicted-iterations"
  The maximum number of loop iterations we predict statically.  This is useful
  in cases where a function contains a single loop with known bound and
*************** another loop with unknown bound.
*** 14282,14529 ****
  The known number of iterations is predicted correctly, while
  the unknown number of iterations average to roughly 10.  This means that the
  loop without bounds appears artificially cold relative to the other one.
! .IP "\fBbuiltin-expect-probability\fR" 4
  .IX Item "builtin-expect-probability"
  Control the probability of the expression having the specified value. This
  parameter takes a percentage (i.e. 0 ... 100) as input.
! .IP "\fBbuiltin-string-cmp-inline-length\fR" 4
  .IX Item "builtin-string-cmp-inline-length"
  The maximum length of a constant string for a builtin string cmp call 
  eligible for inlining.
! .IP "\fBalign-threshold\fR" 4
  .IX Item "align-threshold"
  Select fraction of the maximal frequency of executions of a basic block in
  a function to align the basic block.
! .IP "\fBalign-loop-iterations\fR" 4
  .IX Item "align-loop-iterations"
  A loop expected to iterate at least the selected number of iterations is
  aligned.
! .IP "\fBtracer-dynamic-coverage\fR" 4
  .IX Item "tracer-dynamic-coverage"
  .PD 0
! .IP "\fBtracer-dynamic-coverage-feedback\fR" 4
  .IX Item "tracer-dynamic-coverage-feedback"
  .PD
  This value is used to limit superblock formation once the given percentage of
  executed instructions is covered.  This limits unnecessary code size
  expansion.
  .Sp
! The \fBtracer-dynamic-coverage-feedback\fR parameter
  is used only when profile
  feedback is available.  The real profiles (as opposed to statically estimated
  ones) are much less balanced allowing the threshold to be larger value.
! .IP "\fBtracer-max-code-growth\fR" 4
  .IX Item "tracer-max-code-growth"
  Stop tail duplication once code growth has reached given percentage.  This is
  a rather artificial limit, as most of the duplicates are eliminated later in
  cross jumping, so it may be set to much higher values than is the desired code
  growth.
! .IP "\fBtracer-min-branch-ratio\fR" 4
  .IX Item "tracer-min-branch-ratio"
  Stop reverse growth when the reverse probability of best edge is less than this
  threshold (in percent).
! .IP "\fBtracer-min-branch-probability\fR" 4
  .IX Item "tracer-min-branch-probability"
  .PD 0
! .IP "\fBtracer-min-branch-probability-feedback\fR" 4
  .IX Item "tracer-min-branch-probability-feedback"
  .PD
  Stop forward growth if the best edge has probability lower than this
  threshold.
  .Sp
! Similarly to \fBtracer-dynamic-coverage\fR two parameters are
! provided.  \fBtracer-min-branch-probability-feedback\fR is used for
! compilation with profile feedback and \fBtracer-min-branch-probability\fR
  compilation without.  The value for compilation with profile feedback
  needs to be more conservative (higher) in order to make tracer
  effective.
! .IP "\fBstack-clash-protection-guard-size\fR" 4
  .IX Item "stack-clash-protection-guard-size"
  Specify the size of the operating system provided stack guard as
  2 raised to \fInum\fR bytes.  Higher values may reduce the
  number of explicit probes, but a value larger than the operating system
  provided guard will leave code vulnerable to stack clash style attacks.
! .IP "\fBstack-clash-protection-probe-interval\fR" 4
  .IX Item "stack-clash-protection-probe-interval"
  Stack clash protection involves probing stack space as it is allocated.  This
  param controls the maximum distance between probes into the stack as 2 raised
  to \fInum\fR bytes.  Higher values may reduce the number of explicit probes, but a value
  larger than the operating system provided guard will leave code vulnerable to
  stack clash style attacks.
! .IP "\fBmax-cse-path-length\fR" 4
  .IX Item "max-cse-path-length"
! The maximum number of basic blocks on path that \s-1CSE\s0 considers.
! .IP "\fBmax-cse-insns\fR" 4
  .IX Item "max-cse-insns"
! The maximum number of instructions \s-1CSE\s0 processes before flushing.
! .IP "\fBggc-min-expand\fR" 4
  .IX Item "ggc-min-expand"
! \&\s-1GCC\s0 uses a garbage collector to manage its own memory allocation.  This
  parameter specifies the minimum percentage by which the garbage
! collector's heap should be allowed to expand between collections.
  Tuning this may improve compilation speed; it has no effect on code
  generation.
  .Sp
! The default is 30% + 70% * (\s-1RAM/1GB\s0) with an upper bound of 100% when
! \&\s-1RAM\s0 >= 1GB.  If \f(CW\*(C`getrlimit\*(C'\fR is available, the notion of \*(L"\s-1RAM\*(R"\s0 is
! the smallest of actual \s-1RAM\s0 and \f(CW\*(C`RLIMIT_DATA\*(C'\fR or \f(CW\*(C`RLIMIT_AS\*(C'\fR.  If
! \&\s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a particular platform, the lower
  bound of 30% is used.  Setting this parameter and
! \&\fBggc-min-heapsize\fR to zero causes a full collection to occur at
  every opportunity.  This is extremely slow, but can be useful for
  debugging.
! .IP "\fBggc-min-heapsize\fR" 4
  .IX Item "ggc-min-heapsize"
! Minimum size of the garbage collector's heap before it begins bothering
  to collect garbage.  The first collection occurs after the heap expands
! by \fBggc-min-expand\fR% beyond \fBggc-min-heapsize\fR.  Again,
  tuning this may improve compilation speed, and has no effect on code
  generation.
  .Sp
! The default is the smaller of \s-1RAM/8, RLIMIT_RSS,\s0 or a limit that
! tries to ensure that \s-1RLIMIT_DATA\s0 or \s-1RLIMIT_AS\s0 are not exceeded, but
  with a lower bound of 4096 (four megabytes) and an upper bound of
! 131072 (128 megabytes).  If \s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a
  particular platform, the lower bound is used.  Setting this parameter
  very large effectively disables garbage collection.  Setting this
! parameter and \fBggc-min-expand\fR to zero causes a full collection
  to occur at every opportunity.
! .IP "\fBmax-reload-search-insns\fR" 4
  .IX Item "max-reload-search-insns"
  The maximum number of instruction reload should look backward for equivalent
  register.  Increasing values mean more aggressive optimization, making the
  compilation time increase with probably slightly better performance.
! .IP "\fBmax-cselib-memory-locations\fR" 4
  .IX Item "max-cselib-memory-locations"
  The maximum number of memory locations cselib should take into account.
  Increasing values mean more aggressive optimization, making the compilation time
  increase with probably slightly better performance.
! .IP "\fBmax-sched-ready-insns\fR" 4
  .IX Item "max-sched-ready-insns"
  The maximum number of instructions ready to be issued the scheduler should
  consider at any given time during the first scheduling pass.  Increasing
  values mean more thorough searches, making the compilation time increase
  with probably little benefit.
! .IP "\fBmax-sched-region-blocks\fR" 4
  .IX Item "max-sched-region-blocks"
  The maximum number of blocks in a region to be considered for
  interblock scheduling.
! .IP "\fBmax-pipeline-region-blocks\fR" 4
  .IX Item "max-pipeline-region-blocks"
  The maximum number of blocks in a region to be considered for
  pipelining in the selective scheduler.
! .IP "\fBmax-sched-region-insns\fR" 4
  .IX Item "max-sched-region-insns"
  The maximum number of insns in a region to be considered for
  interblock scheduling.
! .IP "\fBmax-pipeline-region-insns\fR" 4
  .IX Item "max-pipeline-region-insns"
  The maximum number of insns in a region to be considered for
  pipelining in the selective scheduler.
! .IP "\fBmin-spec-prob\fR" 4
  .IX Item "min-spec-prob"
  The minimum probability (in percents) of reaching a source block
  for interblock speculative scheduling.
! .IP "\fBmax-sched-extend-regions-iters\fR" 4
  .IX Item "max-sched-extend-regions-iters"
! The maximum number of iterations through \s-1CFG\s0 to extend regions.
  A value of 0 disables region extensions.
! .IP "\fBmax-sched-insn-conflict-delay\fR" 4
  .IX Item "max-sched-insn-conflict-delay"
  The maximum conflict delay for an insn to be considered for speculative motion.
! .IP "\fBsched-spec-prob-cutoff\fR" 4
  .IX Item "sched-spec-prob-cutoff"
  The minimal probability of speculation success (in percents), so that
  speculative insns are scheduled.
! .IP "\fBsched-state-edge-prob-cutoff\fR" 4
  .IX Item "sched-state-edge-prob-cutoff"
  The minimum probability an edge must have for the scheduler to save its
  state across it.
! .IP "\fBsched-mem-true-dep-cost\fR" 4
  .IX Item "sched-mem-true-dep-cost"
! Minimal distance (in \s-1CPU\s0 cycles) between store and load targeting same
  memory locations.
! .IP "\fBselsched-max-lookahead\fR" 4
  .IX Item "selsched-max-lookahead"
  The maximum size of the lookahead window of selective scheduling.  It is a
  depth of search for available instructions.
! .IP "\fBselsched-max-sched-times\fR" 4
  .IX Item "selsched-max-sched-times"
  The maximum number of times that an instruction is scheduled during
  selective scheduling.  This is the limit on the number of iterations
  through which the instruction may be pipelined.
! .IP "\fBselsched-insns-to-rename\fR" 4
  .IX Item "selsched-insns-to-rename"
  The maximum number of best instructions in the ready list that are considered
  for renaming in the selective scheduler.
! .IP "\fBsms-min-sc\fR" 4
  .IX Item "sms-min-sc"
  The minimum value of stage count that swing modulo scheduler
  generates.
! .IP "\fBmax-last-value-rtl\fR" 4
  .IX Item "max-last-value-rtl"
  The maximum size measured as number of RTLs that can be recorded in an expression
  in combiner for a pseudo register as last known value of that register.
! .IP "\fBmax-combine-insns\fR" 4
  .IX Item "max-combine-insns"
! The maximum number of instructions the \s-1RTL\s0 combiner tries to combine.
! .IP "\fBinteger-share-limit\fR" 4
  .IX Item "integer-share-limit"
  Small integer constants can use a shared data structure, reducing the
! compiler's memory usage and increasing its speed.  This sets the maximum
  value of a shared integer constant.
! .IP "\fBssp-buffer-size\fR" 4
  .IX Item "ssp-buffer-size"
  The minimum size of buffers (i.e. arrays) that receive stack smashing
  protection when \fB\-fstack\-protector\fR is used.
! .IP "\fBmin-size-for-stack-sharing\fR" 4
  .IX Item "min-size-for-stack-sharing"
  The minimum size of variables taking part in stack slot sharing when not
  optimizing.
! .IP "\fBmax-jump-thread-duplication-stmts\fR" 4
  .IX Item "max-jump-thread-duplication-stmts"
  Maximum number of statements allowed in a block that needs to be
  duplicated when threading jumps.
! .IP "\fBmax-jump-thread-paths\fR" 4
  .IX Item "max-jump-thread-paths"
  The maximum number of paths to consider when searching for jump threading
  opportunities.  When arriving at a block, incoming edges are only considered
  if the number of paths to be searched so far multiplied by the number of
  incoming edges does not exhaust the specified maximum number of paths to
  consider.
! .IP "\fBmax-fields-for-field-sensitive\fR" 4
  .IX Item "max-fields-for-field-sensitive"
  Maximum number of fields in a structure treated in
  a field sensitive manner during pointer analysis.
! .IP "\fBprefetch-latency\fR" 4
  .IX Item "prefetch-latency"
  Estimate on average number of instructions that are executed before
  prefetch finishes.  The distance prefetched ahead is proportional
  to this constant.  Increasing this number may also lead to less
! streams being prefetched (see \fBsimultaneous-prefetches\fR).
! .IP "\fBsimultaneous-prefetches\fR" 4
  .IX Item "simultaneous-prefetches"
  Maximum number of prefetches that can run at the same time.
! .IP "\fBl1\-cache\-line\-size\fR" 4
  .IX Item "l1-cache-line-size"
  The size of cache line in L1 data cache, in bytes.
! .IP "\fBl1\-cache\-size\fR" 4
  .IX Item "l1-cache-size"
  The size of L1 data cache, in kilobytes.
! .IP "\fBl2\-cache\-size\fR" 4
  .IX Item "l2-cache-size"
  The size of L2 data cache, in kilobytes.
! .IP "\fBprefetch-dynamic-strides\fR" 4
  .IX Item "prefetch-dynamic-strides"
  Whether the loop array prefetch pass should issue software prefetch hints
! for strides that are non-constant.  In some cases this may be
! beneficial, though the fact the stride is non-constant may make it
  hard to predict when there is clear benefit to issuing these hints.
  .Sp
! Set to 1 if the prefetch hints should be issued for non-constant
  strides.  Set to 0 if prefetch hints should be issued only for strides that
! are known to be constant and below \fBprefetch-minimum-stride\fR.
! .IP "\fBprefetch-minimum-stride\fR" 4
  .IX Item "prefetch-minimum-stride"
  Minimum constant stride, in bytes, to start using prefetch hints for.  If
  the stride is less than this threshold, prefetch hints will not be issued.
--- 14211,14458 ----
  The known number of iterations is predicted correctly, while
  the unknown number of iterations average to roughly 10.  This means that the
  loop without bounds appears artificially cold relative to the other one.
! .IP \fBbuiltin\-expect\-probability\fR 4
  .IX Item "builtin-expect-probability"
  Control the probability of the expression having the specified value. This
  parameter takes a percentage (i.e. 0 ... 100) as input.
! .IP \fBbuiltin\-string\-cmp\-inline\-length\fR 4
  .IX Item "builtin-string-cmp-inline-length"
  The maximum length of a constant string for a builtin string cmp call 
  eligible for inlining.
! .IP \fBalign\-threshold\fR 4
  .IX Item "align-threshold"
  Select fraction of the maximal frequency of executions of a basic block in
  a function to align the basic block.
! .IP \fBalign\-loop\-iterations\fR 4
  .IX Item "align-loop-iterations"
  A loop expected to iterate at least the selected number of iterations is
  aligned.
! .IP \fBtracer\-dynamic\-coverage\fR 4
  .IX Item "tracer-dynamic-coverage"
  .PD 0
! .IP \fBtracer\-dynamic\-coverage\-feedback\fR 4
  .IX Item "tracer-dynamic-coverage-feedback"
  .PD
  This value is used to limit superblock formation once the given percentage of
  executed instructions is covered.  This limits unnecessary code size
  expansion.
  .Sp
! The \fBtracer\-dynamic\-coverage\-feedback\fR parameter
  is used only when profile
  feedback is available.  The real profiles (as opposed to statically estimated
  ones) are much less balanced allowing the threshold to be larger value.
! .IP \fBtracer\-max\-code\-growth\fR 4
  .IX Item "tracer-max-code-growth"
  Stop tail duplication once code growth has reached given percentage.  This is
  a rather artificial limit, as most of the duplicates are eliminated later in
  cross jumping, so it may be set to much higher values than is the desired code
  growth.
! .IP \fBtracer\-min\-branch\-ratio\fR 4
  .IX Item "tracer-min-branch-ratio"
  Stop reverse growth when the reverse probability of best edge is less than this
  threshold (in percent).
! .IP \fBtracer\-min\-branch\-probability\fR 4
  .IX Item "tracer-min-branch-probability"
  .PD 0
! .IP \fBtracer\-min\-branch\-probability\-feedback\fR 4
  .IX Item "tracer-min-branch-probability-feedback"
  .PD
  Stop forward growth if the best edge has probability lower than this
  threshold.
  .Sp
! Similarly to \fBtracer\-dynamic\-coverage\fR two parameters are
! provided.  \fBtracer\-min\-branch\-probability\-feedback\fR is used for
! compilation with profile feedback and \fBtracer\-min\-branch\-probability\fR
  compilation without.  The value for compilation with profile feedback
  needs to be more conservative (higher) in order to make tracer
  effective.
! .IP \fBstack\-clash\-protection\-guard\-size\fR 4
  .IX Item "stack-clash-protection-guard-size"
  Specify the size of the operating system provided stack guard as
  2 raised to \fInum\fR bytes.  Higher values may reduce the
  number of explicit probes, but a value larger than the operating system
  provided guard will leave code vulnerable to stack clash style attacks.
! .IP \fBstack\-clash\-protection\-probe\-interval\fR 4
  .IX Item "stack-clash-protection-probe-interval"
  Stack clash protection involves probing stack space as it is allocated.  This
  param controls the maximum distance between probes into the stack as 2 raised
  to \fInum\fR bytes.  Higher values may reduce the number of explicit probes, but a value
  larger than the operating system provided guard will leave code vulnerable to
  stack clash style attacks.
! .IP \fBmax\-cse\-path\-length\fR 4
  .IX Item "max-cse-path-length"
! The maximum number of basic blocks on path that CSE considers.
! .IP \fBmax\-cse\-insns\fR 4
  .IX Item "max-cse-insns"
! The maximum number of instructions CSE processes before flushing.
! .IP \fBggc\-min\-expand\fR 4
  .IX Item "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\*(Aqs heap should be allowed to expand between collections.
  Tuning this may improve compilation speed; it has no effect on code
  generation.
  .Sp
! The default is 30% + 70% * (RAM/1GB) with an upper bound of 100% when
! RAM >= 1GB.  If \f(CW\*(C`getrlimit\*(C'\fR is available, the notion of "RAM" is
! the smallest of actual RAM and \f(CW\*(C`RLIMIT_DATA\*(C'\fR or \f(CW\*(C`RLIMIT_AS\*(C'\fR.  If
! GCC is not able to calculate RAM on a particular platform, the lower
  bound of 30% is used.  Setting this parameter and
! \&\fBggc\-min\-heapsize\fR to zero causes a full collection to occur at
  every opportunity.  This is extremely slow, but can be useful for
  debugging.
! .IP \fBggc\-min\-heapsize\fR 4
  .IX Item "ggc-min-heapsize"
! Minimum size of the garbage collector\*(Aqs heap before it begins bothering
  to collect garbage.  The first collection occurs after the heap expands
! by \fBggc\-min\-expand\fR% beyond \fBggc\-min\-heapsize\fR.  Again,
  tuning this may improve compilation speed, and has no effect on code
  generation.
  .Sp
! The default is the smaller of RAM/8, RLIMIT_RSS, or a limit that
! tries to ensure that RLIMIT_DATA or RLIMIT_AS are not exceeded, but
  with a lower bound of 4096 (four megabytes) and an upper bound of
! 131072 (128 megabytes).  If GCC is not able to calculate RAM on a
  particular platform, the lower bound is used.  Setting this parameter
  very large effectively disables garbage collection.  Setting this
! parameter and \fBggc\-min\-expand\fR to zero causes a full collection
  to occur at every opportunity.
! .IP \fBmax\-reload\-search\-insns\fR 4
  .IX Item "max-reload-search-insns"
  The maximum number of instruction reload should look backward for equivalent
  register.  Increasing values mean more aggressive optimization, making the
  compilation time increase with probably slightly better performance.
! .IP \fBmax\-cselib\-memory\-locations\fR 4
  .IX Item "max-cselib-memory-locations"
  The maximum number of memory locations cselib should take into account.
  Increasing values mean more aggressive optimization, making the compilation time
  increase with probably slightly better performance.
! .IP \fBmax\-sched\-ready\-insns\fR 4
  .IX Item "max-sched-ready-insns"
  The maximum number of instructions ready to be issued the scheduler should
  consider at any given time during the first scheduling pass.  Increasing
  values mean more thorough searches, making the compilation time increase
  with probably little benefit.
! .IP \fBmax\-sched\-region\-blocks\fR 4
  .IX Item "max-sched-region-blocks"
  The maximum number of blocks in a region to be considered for
  interblock scheduling.
! .IP \fBmax\-pipeline\-region\-blocks\fR 4
  .IX Item "max-pipeline-region-blocks"
  The maximum number of blocks in a region to be considered for
  pipelining in the selective scheduler.
! .IP \fBmax\-sched\-region\-insns\fR 4
  .IX Item "max-sched-region-insns"
  The maximum number of insns in a region to be considered for
  interblock scheduling.
! .IP \fBmax\-pipeline\-region\-insns\fR 4
  .IX Item "max-pipeline-region-insns"
  The maximum number of insns in a region to be considered for
  pipelining in the selective scheduler.
! .IP \fBmin\-spec\-prob\fR 4
  .IX Item "min-spec-prob"
  The minimum probability (in percents) of reaching a source block
  for interblock speculative scheduling.
! .IP \fBmax\-sched\-extend\-regions\-iters\fR 4
  .IX Item "max-sched-extend-regions-iters"
! The maximum number of iterations through CFG to extend regions.
  A value of 0 disables region extensions.
! .IP \fBmax\-sched\-insn\-conflict\-delay\fR 4
  .IX Item "max-sched-insn-conflict-delay"
  The maximum conflict delay for an insn to be considered for speculative motion.
! .IP \fBsched\-spec\-prob\-cutoff\fR 4
  .IX Item "sched-spec-prob-cutoff"
  The minimal probability of speculation success (in percents), so that
  speculative insns are scheduled.
! .IP \fBsched\-state\-edge\-prob\-cutoff\fR 4
  .IX Item "sched-state-edge-prob-cutoff"
  The minimum probability an edge must have for the scheduler to save its
  state across it.
! .IP \fBsched\-mem\-true\-dep\-cost\fR 4
  .IX Item "sched-mem-true-dep-cost"
! Minimal distance (in CPU cycles) between store and load targeting same
  memory locations.
! .IP \fBselsched\-max\-lookahead\fR 4
  .IX Item "selsched-max-lookahead"
  The maximum size of the lookahead window of selective scheduling.  It is a
  depth of search for available instructions.
! .IP \fBselsched\-max\-sched\-times\fR 4
  .IX Item "selsched-max-sched-times"
  The maximum number of times that an instruction is scheduled during
  selective scheduling.  This is the limit on the number of iterations
  through which the instruction may be pipelined.
! .IP \fBselsched\-insns\-to\-rename\fR 4
  .IX Item "selsched-insns-to-rename"
  The maximum number of best instructions in the ready list that are considered
  for renaming in the selective scheduler.
! .IP \fBsms\-min\-sc\fR 4
  .IX Item "sms-min-sc"
  The minimum value of stage count that swing modulo scheduler
  generates.
! .IP \fBmax\-last\-value\-rtl\fR 4
  .IX Item "max-last-value-rtl"
  The maximum size measured as number of RTLs that can be recorded in an expression
  in combiner for a pseudo register as last known value of that register.
! .IP \fBmax\-combine\-insns\fR 4
  .IX Item "max-combine-insns"
! The maximum number of instructions the RTL combiner tries to combine.
! .IP \fBinteger\-share\-limit\fR 4
  .IX Item "integer-share-limit"
  Small integer constants can use a shared data structure, reducing the
! compiler\*(Aqs memory usage and increasing its speed.  This sets the maximum
  value of a shared integer constant.
! .IP \fBssp\-buffer\-size\fR 4
  .IX Item "ssp-buffer-size"
  The minimum size of buffers (i.e. arrays) that receive stack smashing
  protection when \fB\-fstack\-protector\fR is used.
! .IP \fBmin\-size\-for\-stack\-sharing\fR 4
  .IX Item "min-size-for-stack-sharing"
  The minimum size of variables taking part in stack slot sharing when not
  optimizing.
! .IP \fBmax\-jump\-thread\-duplication\-stmts\fR 4
  .IX Item "max-jump-thread-duplication-stmts"
  Maximum number of statements allowed in a block that needs to be
  duplicated when threading jumps.
! .IP \fBmax\-jump\-thread\-paths\fR 4
  .IX Item "max-jump-thread-paths"
  The maximum number of paths to consider when searching for jump threading
  opportunities.  When arriving at a block, incoming edges are only considered
  if the number of paths to be searched so far multiplied by the number of
  incoming edges does not exhaust the specified maximum number of paths to
  consider.
! .IP \fBmax\-fields\-for\-field\-sensitive\fR 4
  .IX Item "max-fields-for-field-sensitive"
  Maximum number of fields in a structure treated in
  a field sensitive manner during pointer analysis.
! .IP \fBprefetch\-latency\fR 4
  .IX Item "prefetch-latency"
  Estimate on average number of instructions that are executed before
  prefetch finishes.  The distance prefetched ahead is proportional
  to this constant.  Increasing this number may also lead to less
! streams being prefetched (see \fBsimultaneous\-prefetches\fR).
! .IP \fBsimultaneous\-prefetches\fR 4
  .IX Item "simultaneous-prefetches"
  Maximum number of prefetches that can run at the same time.
! .IP \fBl1\-cache\-line\-size\fR 4
  .IX Item "l1-cache-line-size"
  The size of cache line in L1 data cache, in bytes.
! .IP \fBl1\-cache\-size\fR 4
  .IX Item "l1-cache-size"
  The size of L1 data cache, in kilobytes.
! .IP \fBl2\-cache\-size\fR 4
  .IX Item "l2-cache-size"
  The size of L2 data cache, in kilobytes.
! .IP \fBprefetch\-dynamic\-strides\fR 4
  .IX Item "prefetch-dynamic-strides"
  Whether the loop array prefetch pass should issue software prefetch hints
! for strides that are non\-constant.  In some cases this may be
! beneficial, though the fact the stride is non\-constant may make it
  hard to predict when there is clear benefit to issuing these hints.
  .Sp
! Set to 1 if the prefetch hints should be issued for non\-constant
  strides.  Set to 0 if prefetch hints should be issued only for strides that
! are known to be constant and below \fBprefetch\-minimum\-stride\fR.
! .IP \fBprefetch\-minimum\-stride\fR 4
  .IX Item "prefetch-minimum-stride"
  Minimum constant stride, in bytes, to start using prefetch hints for.  If
  the stride is less than this threshold, prefetch hints will not be issued.
*************** the software prefetchers.  If the hardwa
*** 14534,14554 ****
  stride they can handle, it should be used here to improve the use of
  software prefetchers.
  .Sp
! A value of \-1 means we don't have a threshold and therefore
  prefetch hints can be issued for any constant stride.
  .Sp
  This setting is only useful for strides that are known and constant.
! .IP "\fBdestructive-interference-size\fR" 4
  .IX Item "destructive-interference-size"
  .PD 0
! .IP "\fBconstructive-interference-size\fR" 4
  .IX Item "constructive-interference-size"
  .PD
! The values for the \*(C+17 variables
  \&\f(CW\*(C`std::hardware_destructive_interference_size\*(C'\fR and
  \&\f(CW\*(C`std::hardware_constructive_interference_size\*(C'\fR.  The destructive
  interference size is the minimum recommended offset between two
! independent concurrently-accessed objects; the constructive
  interference size is the maximum recommended size of contiguous memory
  accessed together.  Typically both will be the size of an L1 cache
  line for the target, in bytes.  For a generic target covering a range of L1
--- 14463,14483 ----
  stride they can handle, it should be used here to improve the use of
  software prefetchers.
  .Sp
! A value of \-1 means we don\*(Aqt have a threshold and therefore
  prefetch hints can be issued for any constant stride.
  .Sp
  This setting is only useful for strides that are known and constant.
! .IP \fBdestructive\-interference\-size\fR 4
  .IX Item "destructive-interference-size"
  .PD 0
! .IP \fBconstructive\-interference\-size\fR 4
  .IX Item "constructive-interference-size"
  .PD
! The values for the C++17 variables
  \&\f(CW\*(C`std::hardware_destructive_interference_size\*(C'\fR and
  \&\f(CW\*(C`std::hardware_constructive_interference_size\*(C'\fR.  The destructive
  interference size is the minimum recommended offset between two
! independent concurrently\-accessed objects; the constructive
  interference size is the maximum recommended size of contiguous memory
  accessed together.  Typically both will be the size of an L1 cache
  line for the target, in bytes.  For a generic target covering a range of L1
*************** the small end of the range and the destr
*** 14557,14565 ****
  end.
  .Sp
  The destructive interference size is intended to be used for layout,
! and thus has \s-1ABI\s0 impact.  The default value is not expected to be
  stable, and on some targets varies with \fB\-mtune\fR, so use of
! this variable in a context where \s-1ABI\s0 stability is important, such as
  the public interface of a library, is strongly discouraged; if it is
  used in that context, users can stabilize the value using this
  option.
--- 14486,14494 ----
  end.
  .Sp
  The destructive interference size is intended to be used for layout,
! and thus has ABI impact.  The default value is not expected to be
  stable, and on some targets varies with \fB\-mtune\fR, so use of
! this variable in a context where ABI stability is important, such as
  the public interface of a library, is strongly discouraged; if it is
  used in that context, users can stabilize the value using this
  option.
*************** typically only used in a \fBstatic_asser
*** 14569,14601 ****
  fits within a cache line.
  .Sp
  See also \fB\-Winterference\-size\fR.
! .IP "\fBloop-interchange-max-num-stmts\fR" 4
  .IX Item "loop-interchange-max-num-stmts"
  The maximum number of stmts in a loop to be interchanged.
! .IP "\fBloop-interchange-stride-ratio\fR" 4
  .IX Item "loop-interchange-stride-ratio"
  The minimum ratio between stride of two loops for interchange to be profitable.
! .IP "\fBmin-insn-to-prefetch-ratio\fR" 4
  .IX Item "min-insn-to-prefetch-ratio"
  The minimum ratio between the number of instructions and the
  number of prefetches to enable prefetching in a loop.
! .IP "\fBprefetch-min-insn-to-mem-ratio\fR" 4
  .IX Item "prefetch-min-insn-to-mem-ratio"
  The minimum ratio between the number of instructions and the
  number of memory references to enable prefetching in a loop.
! .IP "\fBuse-canonical-types\fR" 4
  .IX Item "use-canonical-types"
! Whether the compiler should use the \*(L"canonical\*(R" type system.
  Should always be 1, which uses a more efficient internal
! mechanism for comparing types in \*(C+ and Objective\-\*(C+.  However, if
  bugs in the canonical type system are causing compilation failures,
  set this value to 0 to disable canonical types.
! .IP "\fBswitch-conversion-max-branch-ratio\fR" 4
  .IX Item "switch-conversion-max-branch-ratio"
  Switch initialization conversion refuses to create arrays that are
! bigger than \fBswitch-conversion-max-branch-ratio\fR times the number of
  branches in the switch.
! .IP "\fBmax-partial-antic-length\fR" 4
  .IX Item "max-partial-antic-length"
  Maximum length of the partial antic set computed during the tree
  partial redundancy elimination optimization (\fB\-ftree\-pre\fR) when
--- 14498,14530 ----
  fits within a cache line.
  .Sp
  See also \fB\-Winterference\-size\fR.
! .IP \fBloop\-interchange\-max\-num\-stmts\fR 4
  .IX Item "loop-interchange-max-num-stmts"
  The maximum number of stmts in a loop to be interchanged.
! .IP \fBloop\-interchange\-stride\-ratio\fR 4
  .IX Item "loop-interchange-stride-ratio"
  The minimum ratio between stride of two loops for interchange to be profitable.
! .IP \fBmin\-insn\-to\-prefetch\-ratio\fR 4
  .IX Item "min-insn-to-prefetch-ratio"
  The minimum ratio between the number of instructions and the
  number of prefetches to enable prefetching in a loop.
! .IP \fBprefetch\-min\-insn\-to\-mem\-ratio\fR 4
  .IX Item "prefetch-min-insn-to-mem-ratio"
  The minimum ratio between the number of instructions and the
  number of memory references to enable prefetching in a loop.
! .IP \fBuse\-canonical\-types\fR 4
  .IX Item "use-canonical-types"
! Whether the compiler should use the "canonical" type system.
  Should always be 1, which uses a more efficient internal
! mechanism for comparing types in C++ and Objective\-C++.  However, if
  bugs in the canonical type system are causing compilation failures,
  set this value to 0 to disable canonical types.
! .IP \fBswitch\-conversion\-max\-branch\-ratio\fR 4
  .IX Item "switch-conversion-max-branch-ratio"
  Switch initialization conversion refuses to create arrays that are
! bigger than \fBswitch\-conversion\-max\-branch\-ratio\fR times the number of
  branches in the switch.
! .IP \fBmax\-partial\-antic\-length\fR 4
  .IX Item "max-partial-antic-length"
  Maximum length of the partial antic set computed during the tree
  partial redundancy elimination optimization (\fB\-ftree\-pre\fR) when
*************** consuming all of the memory available on
*** 14605,14678 ****
  parameter sets a limit on the length of the sets that are computed,
  which prevents the runaway behavior.  Setting a value of 0 for
  this parameter allows an unlimited set length.
! .IP "\fBrpo-vn-max-loop-depth\fR" 4
  .IX Item "rpo-vn-max-loop-depth"
! Maximum loop depth that is value-numbered optimistically.
  When the limit hits the innermost
! \&\fIrpo-vn-max-loop-depth\fR loops and the outermost loop in the
! loop nest are value-numbered optimistically and the remaining ones not.
! .IP "\fBsccvn-max-alias-queries-per-access\fR" 4
  .IX Item "sccvn-max-alias-queries-per-access"
! Maximum number of alias-oracle queries we perform when looking for
  redundancies for loads and stores.  If this limit is hit the search
  is aborted and the load or store is not considered redundant.  The
  number of queries is algorithmically limited to the number of
  stores on all paths from the load to the function entry.
! .IP "\fBira-max-loops-num\fR" 4
  .IX Item "ira-max-loops-num"
! \&\s-1IRA\s0 uses regional register allocation by default.  If a function
  contains more loops than the number given by this parameter, only at most
! the given number of the most frequently-executed loops form regions
  for regional register allocation.
! .IP "\fBira-max-conflict-table-size\fR" 4
  .IX Item "ira-max-conflict-table-size"
! Although \s-1IRA\s0 uses a sophisticated algorithm to compress the conflict
  table, the table can still require excessive amounts of memory for
  huge functions.  If the conflict table for a function could be more
! than the size in \s-1MB\s0 given by this parameter, the register allocator
! instead uses a faster, simpler, and lower-quality
! algorithm that does not require building a pseudo-register conflict table.
! .IP "\fBira-loop-reserved-regs\fR" 4
  .IX Item "ira-loop-reserved-regs"
! \&\s-1IRA\s0 can be used to evaluate more accurate register pressure in loops
  for decisions to move loop invariants (see \fB\-O3\fR).  The number
  of available registers reserved for some other purposes is given
  by this parameter.  Default of the parameter
  is the best found from numerous experiments.
! .IP "\fBira-consider-dup-in-all-alts\fR" 4
  .IX Item "ira-consider-dup-in-all-alts"
! Make \s-1IRA\s0 to consider matching constraint (duplicated operand number)
  heavily in all available alternatives for preferred register class.
! If it is set as zero, it means \s-1IRA\s0 only respects the matching
! constraint when it's in the only available alternative with an
! appropriate register class.  Otherwise, it means \s-1IRA\s0 will check all
  available alternatives for preferred register class even if it has
  found some choice with an appropriate register class and respect the
  found qualified matching constraint.
! .IP "\fBira-simple-lra-insn-threshold\fR" 4
  .IX Item "ira-simple-lra-insn-threshold"
! Approximate function insn number in 1K units triggering simple local \s-1RA.\s0
! .IP "\fBlra-inheritance-ebb-probability-cutoff\fR" 4
  .IX Item "lra-inheritance-ebb-probability-cutoff"
! \&\s-1LRA\s0 tries to reuse values reloaded in registers in subsequent insns.
! This optimization is called inheritance.  \s-1EBB\s0 is used as a region to
! do this optimization.  The parameter defines a minimal fall-through
! edge probability in percentage used to add \s-1BB\s0 to inheritance \s-1EBB\s0 in
! \&\s-1LRA.\s0  The default value was chosen
! from numerous runs of \s-1SPEC2000\s0 on x86\-64.
! .IP "\fBloop-invariant-max-bbs-in-loop\fR" 4
  .IX Item "loop-invariant-max-bbs-in-loop"
  Loop invariant motion can be very expensive, both in compilation time and
! in amount of needed compile-time memory, with very large loops.  Loops
! with more basic blocks than this parameter won't have loop invariant
  motion optimization performed on them.
! .IP "\fBloop-max-datarefs-for-datadeps\fR" 4
  .IX Item "loop-max-datarefs-for-datadeps"
  Building data dependencies is expensive for very large loops.  This
  parameter limits the number of data references in loops that are
  considered for data dependence analysis.  These large loops are no
  handled by the optimizations using loop data dependencies.
! .IP "\fBmax-vartrack-size\fR" 4
  .IX Item "max-vartrack-size"
  Sets a maximum number of hash table slots to use during variable
  tracking dataflow analysis of any function.  If this limit is exceeded
--- 14534,14607 ----
  parameter sets a limit on the length of the sets that are computed,
  which prevents the runaway behavior.  Setting a value of 0 for
  this parameter allows an unlimited set length.
! .IP \fBrpo\-vn\-max\-loop\-depth\fR 4
  .IX Item "rpo-vn-max-loop-depth"
! Maximum loop depth that is value\-numbered optimistically.
  When the limit hits the innermost
! \&\fIrpo\-vn\-max\-loop\-depth\fR loops and the outermost loop in the
! loop nest are value\-numbered optimistically and the remaining ones not.
! .IP \fBsccvn\-max\-alias\-queries\-per\-access\fR 4
  .IX Item "sccvn-max-alias-queries-per-access"
! Maximum number of alias\-oracle queries we perform when looking for
  redundancies for loads and stores.  If this limit is hit the search
  is aborted and the load or store is not considered redundant.  The
  number of queries is algorithmically limited to the number of
  stores on all paths from the load to the function entry.
! .IP \fBira\-max\-loops\-num\fR 4
  .IX Item "ira-max-loops-num"
! IRA uses regional register allocation by default.  If a function
  contains more loops than the number given by this parameter, only at most
! the given number of the most frequently\-executed loops form regions
  for regional register allocation.
! .IP \fBira\-max\-conflict\-table\-size\fR 4
  .IX Item "ira-max-conflict-table-size"
! Although IRA uses a sophisticated algorithm to compress the conflict
  table, the table can still require excessive amounts of memory for
  huge functions.  If the conflict table for a function could be more
! than the size in MB given by this parameter, the register allocator
! instead uses a faster, simpler, and lower\-quality
! algorithm that does not require building a pseudo\-register conflict table.
! .IP \fBira\-loop\-reserved\-regs\fR 4
  .IX Item "ira-loop-reserved-regs"
! IRA can be used to evaluate more accurate register pressure in loops
  for decisions to move loop invariants (see \fB\-O3\fR).  The number
  of available registers reserved for some other purposes is given
  by this parameter.  Default of the parameter
  is the best found from numerous experiments.
! .IP \fBira\-consider\-dup\-in\-all\-alts\fR 4
  .IX Item "ira-consider-dup-in-all-alts"
! Make IRA to consider matching constraint (duplicated operand number)
  heavily in all available alternatives for preferred register class.
! If it is set as zero, it means IRA only respects the matching
! constraint when it\*(Aqs in the only available alternative with an
! appropriate register class.  Otherwise, it means IRA will check all
  available alternatives for preferred register class even if it has
  found some choice with an appropriate register class and respect the
  found qualified matching constraint.
! .IP \fBira\-simple\-lra\-insn\-threshold\fR 4
  .IX Item "ira-simple-lra-insn-threshold"
! Approximate function insn number in 1K units triggering simple local RA.
! .IP \fBlra\-inheritance\-ebb\-probability\-cutoff\fR 4
  .IX Item "lra-inheritance-ebb-probability-cutoff"
! LRA tries to reuse values reloaded in registers in subsequent insns.
! This optimization is called inheritance.  EBB is used as a region to
! do this optimization.  The parameter defines a minimal fall\-through
! edge probability in percentage used to add BB to inheritance EBB in
! LRA.  The default value was chosen
! from numerous runs of SPEC2000 on x86\-64.
! .IP \fBloop\-invariant\-max\-bbs\-in\-loop\fR 4
  .IX Item "loop-invariant-max-bbs-in-loop"
  Loop invariant motion can be very expensive, both in compilation time and
! in amount of needed compile\-time memory, with very large loops.  Loops
! with more basic blocks than this parameter won\*(Aqt have loop invariant
  motion optimization performed on them.
! .IP \fBloop\-max\-datarefs\-for\-datadeps\fR 4
  .IX Item "loop-max-datarefs-for-datadeps"
  Building data dependencies is expensive for very large loops.  This
  parameter limits the number of data references in loops that are
  considered for data dependence analysis.  These large loops are no
  handled by the optimizations using loop data dependencies.
! .IP \fBmax\-vartrack\-size\fR 4
  .IX Item "max-vartrack-size"
  Sets a maximum number of hash table slots to use during variable
  tracking dataflow analysis of any function.  If this limit is exceeded
*************** function is retried without it, after re
*** 14681,14687 ****
  the function.  If the limit is exceeded even without debug insns, var
  tracking analysis is completely disabled for the function.  Setting
  the parameter to zero makes it unlimited.
! .IP "\fBmax-vartrack-expr-depth\fR" 4
  .IX Item "max-vartrack-expr-depth"
  Sets a maximum number of recursion levels when attempting to map
  variable names or debug temporaries to value expressions.  This trades
--- 14610,14616 ----
  the function.  If the limit is exceeded even without debug insns, var
  tracking analysis is completely disabled for the function.  Setting
  the parameter to zero makes it unlimited.
! .IP \fBmax\-vartrack\-expr\-depth\fR 4
  .IX Item "max-vartrack-expr-depth"
  Sets a maximum number of recursion levels when attempting to map
  variable names or debug temporaries to value expressions.  This trades
*************** low, value expressions that are availabl
*** 14690,14896 ****
  debug information may end up not being used; setting this higher may
  enable the compiler to find more complex debug expressions, but compile
  time and memory use may grow.
! .IP "\fBmax-debug-marker-count\fR" 4
  .IX Item "max-debug-marker-count"
  Sets a threshold on the number of debug markers (e.g. begin stmt
! markers) to avoid complexity explosion at inlining or expanding to \s-1RTL.\s0
  If a function has more such gimple stmts than the set limit, such stmts
! will be dropped from the inlined copy of a function, and from its \s-1RTL\s0
  expansion.
! .IP "\fBmin-nondebug-insn-uid\fR" 4
  .IX Item "min-nondebug-insn-uid"
  Use uids starting at this parameter for nondebug insns.  The range below
  the parameter is reserved exclusively for debug insns created by
  \&\fB\-fvar\-tracking\-assignments\fR, but debug insns may get
! (non-overlapping) uids above it if the reserved range is exhausted.
! .IP "\fBipa-sra-deref-prob-threshold\fR" 4
  .IX Item "ipa-sra-deref-prob-threshold"
! IPA-SRA replaces a pointer which is known not be \s-1NULL\s0 with one or more
  new parameters only when the probability (in percent, relative to
  function entry) of it being dereferenced is higher than this parameter.
! .IP "\fBipa-sra-ptr-growth-factor\fR" 4
  .IX Item "ipa-sra-ptr-growth-factor"
! IPA-SRA replaces a pointer to an aggregate with one or more new
  parameters only when their cumulative size is less or equal to
! \&\fBipa-sra-ptr-growth-factor\fR times the size of the original
  pointer parameter.
! .IP "\fBipa-sra-ptrwrap-growth-factor\fR" 4
  .IX Item "ipa-sra-ptrwrap-growth-factor"
  Additional maximum allowed growth of total size of new parameters
! that ipa-sra replaces a pointer to an aggregate with,
  if it points to a local variable that the caller only writes to and
  passes it as an argument to other functions.
! .IP "\fBipa-sra-max-replacements\fR" 4
  .IX Item "ipa-sra-max-replacements"
! Maximum pieces of an aggregate that IPA-SRA tracks.  As a
  consequence, it is also the maximum number of replacements of a formal
  parameter.
! .IP "\fBsra-max-scalarization-size-Ospeed\fR" 4
  .IX Item "sra-max-scalarization-size-Ospeed"
  .PD 0
! .IP "\fBsra-max-scalarization-size-Osize\fR" 4
  .IX Item "sra-max-scalarization-size-Osize"
  .PD
! The two Scalar Reduction of Aggregates passes (\s-1SRA\s0 and IPA-SRA) aim to
  replace scalar parts of aggregates with uses of independent scalar
  variables.  These parameters control the maximum size, in storage units,
  of aggregate which is considered for replacement when compiling for
  speed
! (\fBsra-max-scalarization-size-Ospeed\fR) or size
! (\fBsra-max-scalarization-size-Osize\fR) respectively.
! .IP "\fBsra-max-propagations\fR" 4
  .IX Item "sra-max-propagations"
  The maximum number of artificial accesses that Scalar Replacement of
! Aggregates (\s-1SRA\s0) will track, per one local variable, in order to
  facilitate copy propagation.
! .IP "\fBtm-max-aggregate-size\fR" 4
  .IX Item "tm-max-aggregate-size"
! When making copies of thread-local variables in a transaction, this
  parameter specifies the size in bytes after which variables are
  saved with the logging functions as opposed to save/restore code
  sequence pairs.  This option only applies when using
  \&\fB\-fgnu\-tm\fR.
! .IP "\fBgraphite-max-nb-scop-params\fR" 4
  .IX Item "graphite-max-nb-scop-params"
  To avoid exponential effects in the Graphite loop transforms, the
  number of parameters in a Static Control Part (SCoP) is bounded.
  A value of zero can be used to lift
  the bound.  A variable whose value is unknown at compilation time and
  defined outside a SCoP is a parameter of the SCoP.
! .IP "\fBloop-block-tile-size\fR" 4
  .IX Item "loop-block-tile-size"
  Loop blocking or strip mining transforms, enabled with
  \&\fB\-floop\-block\fR or \fB\-floop\-strip\-mine\fR, strip mine each
  loop in the loop nest by a given number of iterations.  The strip
! length can be changed using the \fBloop-block-tile-size\fR
  parameter.
! .IP "\fBipa-jump-function-lookups\fR" 4
  .IX Item "ipa-jump-function-lookups"
  Specifies number of statements visited during jump function offset discovery.
! .IP "\fBipa-cp-value-list-size\fR" 4
  .IX Item "ipa-cp-value-list-size"
! IPA-CP attempts to track all possible values and types passed to a function's
  parameter in order to propagate them and perform devirtualization.
! \&\fBipa-cp-value-list-size\fR is the maximum number of values and types it
  stores per one formal parameter of a function.
! .IP "\fBipa-cp-eval-threshold\fR" 4
  .IX Item "ipa-cp-eval-threshold"
! IPA-CP calculates its own score of cloning profitability heuristics
  and performs those cloning opportunities with scores that exceed
! \&\fBipa-cp-eval-threshold\fR.
! .IP "\fBipa-cp-max-recursive-depth\fR" 4
  .IX Item "ipa-cp-max-recursive-depth"
! Maximum depth of recursive cloning for self-recursive function.
! .IP "\fBipa-cp-min-recursive-probability\fR" 4
  .IX Item "ipa-cp-min-recursive-probability"
  Recursive cloning only when the probability of call being executed exceeds
  the parameter.
! .IP "\fBipa-cp-profile-count-base\fR" 4
  .IX Item "ipa-cp-profile-count-base"
! When using \fB\-fprofile\-use\fR option, IPA-CP will consider the measured
  execution count of a call graph edge at this percentage position in their
  histogram as the basis for its heuristics calculation.
! .IP "\fBipa-cp-recursive-freq-factor\fR" 4
  .IX Item "ipa-cp-recursive-freq-factor"
  The number of times interprocedural copy propagation expects recursive
  functions to call themselves.
! .IP "\fBipa-cp-recursion-penalty\fR" 4
  .IX Item "ipa-cp-recursion-penalty"
  Percentage penalty the recursive functions will receive when they
  are evaluated for cloning.
! .IP "\fBipa-cp-single-call-penalty\fR" 4
  .IX Item "ipa-cp-single-call-penalty"
  Percentage penalty functions containing a single call to another
  function will receive when they are evaluated for cloning.
! .IP "\fBipa-max-agg-items\fR" 4
  .IX Item "ipa-max-agg-items"
! IPA-CP is also capable to propagate a number of scalar values passed
! in an aggregate. \fBipa-max-agg-items\fR controls the maximum
  number of such values per one parameter.
! .IP "\fBipa-cp-loop-hint-bonus\fR" 4
  .IX Item "ipa-cp-loop-hint-bonus"
! When IPA-CP determines that a cloning candidate would make the number
  of iterations of a loop known, it adds a bonus of
! \&\fBipa-cp-loop-hint-bonus\fR to the profitability score of
  the candidate.
! .IP "\fBipa-max-loop-predicates\fR" 4
  .IX Item "ipa-max-loop-predicates"
! The maximum number of different predicates \s-1IPA\s0 will use to describe when
  loops in a function have known properties.
! .IP "\fBipa-max-aa-steps\fR" 4
  .IX Item "ipa-max-aa-steps"
! During its analysis of function bodies, IPA-CP employs alias analysis
  in order to track values pointed to by function parameters.  In order
  not spend too much time analyzing huge functions, it gives up and
  consider all memory clobbered after examining
! \&\fBipa-max-aa-steps\fR statements modifying memory.
! .IP "\fBipa-max-switch-predicate-bounds\fR" 4
  .IX Item "ipa-max-switch-predicate-bounds"
  Maximal number of boundary endpoints of case ranges of switch statement.
! For switch exceeding this limit, IPA-CP will not construct cloning cost
  predicate, which is used to estimate cloning benefit, for default case
  of the switch statement.
! .IP "\fBipa-max-param-expr-ops\fR" 4
  .IX Item "ipa-max-param-expr-ops"
! IPA-CP will analyze conditional statement that references some function
  parameter to estimate benefit for cloning upon certain constant value.
  But if number of operations in a parameter expression exceeds
! \&\fBipa-max-param-expr-ops\fR, the expression is treated as complicated
! one, and is not handled by \s-1IPA\s0 analysis.
! .IP "\fBlto-partitions\fR" 4
  .IX Item "lto-partitions"
! Specify desired number of partitions produced during \s-1WHOPR\s0 compilation.
  The number of partitions should exceed the number of CPUs used for compilation.
! .IP "\fBlto-min-partition\fR" 4
  .IX Item "lto-min-partition"
! Size of minimal partition for \s-1WHOPR\s0 (in estimated instructions).
  This prevents expenses of splitting very small programs into too many
  partitions.
! .IP "\fBlto-max-partition\fR" 4
  .IX Item "lto-max-partition"
! Size of max partition for \s-1WHOPR\s0 (in estimated instructions).
  to provide an upper bound for individual size of partition.
  Meant to be used only with balanced partitioning.
! .IP "\fBlto-max-streaming-parallelism\fR" 4
  .IX Item "lto-max-streaming-parallelism"
! Maximal number of parallel processes used for \s-1LTO\s0 streaming.
! .IP "\fBcxx-max-namespaces-for-diagnostic-help\fR" 4
  .IX Item "cxx-max-namespaces-for-diagnostic-help"
! The maximum number of namespaces to consult for suggestions when \*(C+
  name lookup fails for an identifier.
! .IP "\fBsink-frequency-threshold\fR" 4
  .IX Item "sink-frequency-threshold"
  The maximum relative execution frequency (in percents) of the target block
! relative to a statement's original block to allow statement sinking of a
  statement.  Larger numbers result in more aggressive statement sinking.
  A small positive adjustment is applied for
  statements with memory operands as those are even more profitable so sink.
! .IP "\fBmax-stores-to-sink\fR" 4
  .IX Item "max-stores-to-sink"
  The maximum number of conditional store pairs that can be sunk.  Set to 0
! if either vectorization (\fB\-ftree\-vectorize\fR) or if-conversion
  (\fB\-ftree\-loop\-if\-convert\fR) is disabled.
! .IP "\fBcase-values-threshold\fR" 4
  .IX Item "case-values-threshold"
  The smallest number of different values for which it is best to use a
! jump-table instead of a tree of conditional branches.  If the value is
  0, use the default for the machine.
! .IP "\fBjump-table-max-growth-ratio-for-size\fR" 4
  .IX Item "jump-table-max-growth-ratio-for-size"
  The maximum code size growth ratio when expanding
  into a jump table (in percent).  The parameter is used when
  optimizing for size.
! .IP "\fBjump-table-max-growth-ratio-for-speed\fR" 4
  .IX Item "jump-table-max-growth-ratio-for-speed"
  The maximum code size growth ratio when expanding
  into a jump table (in percent).  The parameter is used when
  optimizing for speed.
! .IP "\fBtree-reassoc-width\fR" 4
  .IX Item "tree-reassoc-width"
  Set the maximum number of instructions executed in parallel in
  reassociated tree. This parameter overrides target dependent
  heuristics used by default if has non zero value.
! .IP "\fBsched-pressure-algorithm\fR" 4
  .IX Item "sched-pressure-algorithm"
  Choose between the two available implementations of
  \&\fB\-fsched\-pressure\fR.  Algorithm 1 is the original implementation
--- 14619,14825 ----
  debug information may end up not being used; setting this higher may
  enable the compiler to find more complex debug expressions, but compile
  time and memory use may grow.
! .IP \fBmax\-debug\-marker\-count\fR 4
  .IX Item "max-debug-marker-count"
  Sets a threshold on the number of debug markers (e.g. begin stmt
! markers) to avoid complexity explosion at inlining or expanding to RTL.
  If a function has more such gimple stmts than the set limit, such stmts
! will be dropped from the inlined copy of a function, and from its RTL
  expansion.
! .IP \fBmin\-nondebug\-insn\-uid\fR 4
  .IX Item "min-nondebug-insn-uid"
  Use uids starting at this parameter for nondebug insns.  The range below
  the parameter is reserved exclusively for debug insns created by
  \&\fB\-fvar\-tracking\-assignments\fR, but debug insns may get
! (non\-overlapping) uids above it if the reserved range is exhausted.
! .IP \fBipa\-sra\-deref\-prob\-threshold\fR 4
  .IX Item "ipa-sra-deref-prob-threshold"
! IPA\-SRA replaces a pointer which is known not be NULL with one or more
  new parameters only when the probability (in percent, relative to
  function entry) of it being dereferenced is higher than this parameter.
! .IP \fBipa\-sra\-ptr\-growth\-factor\fR 4
  .IX Item "ipa-sra-ptr-growth-factor"
! IPA\-SRA replaces a pointer to an aggregate with one or more new
  parameters only when their cumulative size is less or equal to
! \&\fBipa\-sra\-ptr\-growth\-factor\fR times the size of the original
  pointer parameter.
! .IP \fBipa\-sra\-ptrwrap\-growth\-factor\fR 4
  .IX Item "ipa-sra-ptrwrap-growth-factor"
  Additional maximum allowed growth of total size of new parameters
! that ipa\-sra replaces a pointer to an aggregate with,
  if it points to a local variable that the caller only writes to and
  passes it as an argument to other functions.
! .IP \fBipa\-sra\-max\-replacements\fR 4
  .IX Item "ipa-sra-max-replacements"
! Maximum pieces of an aggregate that IPA\-SRA tracks.  As a
  consequence, it is also the maximum number of replacements of a formal
  parameter.
! .IP \fBsra\-max\-scalarization\-size\-Ospeed\fR 4
  .IX Item "sra-max-scalarization-size-Ospeed"
  .PD 0
! .IP \fBsra\-max\-scalarization\-size\-Osize\fR 4
  .IX Item "sra-max-scalarization-size-Osize"
  .PD
! The two Scalar Reduction of Aggregates passes (SRA and IPA\-SRA) aim to
  replace scalar parts of aggregates with uses of independent scalar
  variables.  These parameters control the maximum size, in storage units,
  of aggregate which is considered for replacement when compiling for
  speed
! (\fBsra\-max\-scalarization\-size\-Ospeed\fR) or size
! (\fBsra\-max\-scalarization\-size\-Osize\fR) respectively.
! .IP \fBsra\-max\-propagations\fR 4
  .IX Item "sra-max-propagations"
  The maximum number of artificial accesses that Scalar Replacement of
! Aggregates (SRA) will track, per one local variable, in order to
  facilitate copy propagation.
! .IP \fBtm\-max\-aggregate\-size\fR 4
  .IX Item "tm-max-aggregate-size"
! When making copies of thread\-local variables in a transaction, this
  parameter specifies the size in bytes after which variables are
  saved with the logging functions as opposed to save/restore code
  sequence pairs.  This option only applies when using
  \&\fB\-fgnu\-tm\fR.
! .IP \fBgraphite\-max\-nb\-scop\-params\fR 4
  .IX Item "graphite-max-nb-scop-params"
  To avoid exponential effects in the Graphite loop transforms, the
  number of parameters in a Static Control Part (SCoP) is bounded.
  A value of zero can be used to lift
  the bound.  A variable whose value is unknown at compilation time and
  defined outside a SCoP is a parameter of the SCoP.
! .IP \fBloop\-block\-tile\-size\fR 4
  .IX Item "loop-block-tile-size"
  Loop blocking or strip mining transforms, enabled with
  \&\fB\-floop\-block\fR or \fB\-floop\-strip\-mine\fR, strip mine each
  loop in the loop nest by a given number of iterations.  The strip
! length can be changed using the \fBloop\-block\-tile\-size\fR
  parameter.
! .IP \fBipa\-jump\-function\-lookups\fR 4
  .IX Item "ipa-jump-function-lookups"
  Specifies number of statements visited during jump function offset discovery.
! .IP \fBipa\-cp\-value\-list\-size\fR 4
  .IX Item "ipa-cp-value-list-size"
! IPA\-CP attempts to track all possible values and types passed to a function\*(Aqs
  parameter in order to propagate them and perform devirtualization.
! \&\fBipa\-cp\-value\-list\-size\fR is the maximum number of values and types it
  stores per one formal parameter of a function.
! .IP \fBipa\-cp\-eval\-threshold\fR 4
  .IX Item "ipa-cp-eval-threshold"
! IPA\-CP calculates its own score of cloning profitability heuristics
  and performs those cloning opportunities with scores that exceed
! \&\fBipa\-cp\-eval\-threshold\fR.
! .IP \fBipa\-cp\-max\-recursive\-depth\fR 4
  .IX Item "ipa-cp-max-recursive-depth"
! Maximum depth of recursive cloning for self\-recursive function.
! .IP \fBipa\-cp\-min\-recursive\-probability\fR 4
  .IX Item "ipa-cp-min-recursive-probability"
  Recursive cloning only when the probability of call being executed exceeds
  the parameter.
! .IP \fBipa\-cp\-profile\-count\-base\fR 4
  .IX Item "ipa-cp-profile-count-base"
! When using \fB\-fprofile\-use\fR option, IPA\-CP will consider the measured
  execution count of a call graph edge at this percentage position in their
  histogram as the basis for its heuristics calculation.
! .IP \fBipa\-cp\-recursive\-freq\-factor\fR 4
  .IX Item "ipa-cp-recursive-freq-factor"
  The number of times interprocedural copy propagation expects recursive
  functions to call themselves.
! .IP \fBipa\-cp\-recursion\-penalty\fR 4
  .IX Item "ipa-cp-recursion-penalty"
  Percentage penalty the recursive functions will receive when they
  are evaluated for cloning.
! .IP \fBipa\-cp\-single\-call\-penalty\fR 4
  .IX Item "ipa-cp-single-call-penalty"
  Percentage penalty functions containing a single call to another
  function will receive when they are evaluated for cloning.
! .IP \fBipa\-max\-agg\-items\fR 4
  .IX Item "ipa-max-agg-items"
! IPA\-CP is also capable to propagate a number of scalar values passed
! in an aggregate. \fBipa\-max\-agg\-items\fR controls the maximum
  number of such values per one parameter.
! .IP \fBipa\-cp\-loop\-hint\-bonus\fR 4
  .IX Item "ipa-cp-loop-hint-bonus"
! When IPA\-CP determines that a cloning candidate would make the number
  of iterations of a loop known, it adds a bonus of
! \&\fBipa\-cp\-loop\-hint\-bonus\fR to the profitability score of
  the candidate.
! .IP \fBipa\-max\-loop\-predicates\fR 4
  .IX Item "ipa-max-loop-predicates"
! The maximum number of different predicates IPA will use to describe when
  loops in a function have known properties.
! .IP \fBipa\-max\-aa\-steps\fR 4
  .IX Item "ipa-max-aa-steps"
! During its analysis of function bodies, IPA\-CP employs alias analysis
  in order to track values pointed to by function parameters.  In order
  not spend too much time analyzing huge functions, it gives up and
  consider all memory clobbered after examining
! \&\fBipa\-max\-aa\-steps\fR statements modifying memory.
! .IP \fBipa\-max\-switch\-predicate\-bounds\fR 4
  .IX Item "ipa-max-switch-predicate-bounds"
  Maximal number of boundary endpoints of case ranges of switch statement.
! For switch exceeding this limit, IPA\-CP will not construct cloning cost
  predicate, which is used to estimate cloning benefit, for default case
  of the switch statement.
! .IP \fBipa\-max\-param\-expr\-ops\fR 4
  .IX Item "ipa-max-param-expr-ops"
! IPA\-CP will analyze conditional statement that references some function
  parameter to estimate benefit for cloning upon certain constant value.
  But if number of operations in a parameter expression exceeds
! \&\fBipa\-max\-param\-expr\-ops\fR, the expression is treated as complicated
! one, and is not handled by IPA analysis.
! .IP \fBlto\-partitions\fR 4
  .IX Item "lto-partitions"
! Specify desired number of partitions produced during WHOPR compilation.
  The number of partitions should exceed the number of CPUs used for compilation.
! .IP \fBlto\-min\-partition\fR 4
  .IX Item "lto-min-partition"
! Size of minimal partition for WHOPR (in estimated instructions).
  This prevents expenses of splitting very small programs into too many
  partitions.
! .IP \fBlto\-max\-partition\fR 4
  .IX Item "lto-max-partition"
! Size of max partition for WHOPR (in estimated instructions).
  to provide an upper bound for individual size of partition.
  Meant to be used only with balanced partitioning.
! .IP \fBlto\-max\-streaming\-parallelism\fR 4
  .IX Item "lto-max-streaming-parallelism"
! Maximal number of parallel processes used for LTO streaming.
! .IP \fBcxx\-max\-namespaces\-for\-diagnostic\-help\fR 4
  .IX Item "cxx-max-namespaces-for-diagnostic-help"
! The maximum number of namespaces to consult for suggestions when C++
  name lookup fails for an identifier.
! .IP \fBsink\-frequency\-threshold\fR 4
  .IX Item "sink-frequency-threshold"
  The maximum relative execution frequency (in percents) of the target block
! relative to a statement\*(Aqs original block to allow statement sinking of a
  statement.  Larger numbers result in more aggressive statement sinking.
  A small positive adjustment is applied for
  statements with memory operands as those are even more profitable so sink.
! .IP \fBmax\-stores\-to\-sink\fR 4
  .IX Item "max-stores-to-sink"
  The maximum number of conditional store pairs that can be sunk.  Set to 0
! if either vectorization (\fB\-ftree\-vectorize\fR) or if\-conversion
  (\fB\-ftree\-loop\-if\-convert\fR) is disabled.
! .IP \fBcase\-values\-threshold\fR 4
  .IX Item "case-values-threshold"
  The smallest number of different values for which it is best to use a
! jump\-table instead of a tree of conditional branches.  If the value is
  0, use the default for the machine.
! .IP \fBjump\-table\-max\-growth\-ratio\-for\-size\fR 4
  .IX Item "jump-table-max-growth-ratio-for-size"
  The maximum code size growth ratio when expanding
  into a jump table (in percent).  The parameter is used when
  optimizing for size.
! .IP \fBjump\-table\-max\-growth\-ratio\-for\-speed\fR 4
  .IX Item "jump-table-max-growth-ratio-for-speed"
  The maximum code size growth ratio when expanding
  into a jump table (in percent).  The parameter is used when
  optimizing for speed.
! .IP \fBtree\-reassoc\-width\fR 4
  .IX Item "tree-reassoc-width"
  Set the maximum number of instructions executed in parallel in
  reassociated tree. This parameter overrides target dependent
  heuristics used by default if has non zero value.
! .IP \fBsched\-pressure\-algorithm\fR 4
  .IX Item "sched-pressure-algorithm"
  Choose between the two available implementations of
  \&\fB\-fsched\-pressure\fR.  Algorithm 1 is the original implementation
*************** Algorithm 2 was designed to be a comprom
*** 14899,14971 ****
  conservative approach taken by algorithm 1 and the rather aggressive
  approach taken by the default scheduler.  It relies more heavily on
  having a regular register file and accurate register pressure classes.
! See \fIhaifa\-sched.cc\fR in the \s-1GCC\s0 sources for more details.
  .Sp
  The default choice depends on the target.
! .IP "\fBmax-slsr-cand-scan\fR" 4
  .IX Item "max-slsr-cand-scan"
  Set the maximum number of existing candidates that are considered when
! seeking a basis for a new straight-line strength reduction candidate.
! .IP "\fBasan-globals\fR" 4
  .IX Item "asan-globals"
  Enable buffer overflow detection for global objects.  This kind
  of protection is enabled by default if you are using
  \&\fB\-fsanitize=address\fR option.
  To disable global objects protection use \fB\-\-param asan\-globals=0\fR.
! .IP "\fBasan-stack\fR" 4
  .IX Item "asan-stack"
  Enable buffer overflow detection for stack objects.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable stack protection use \fB\-\-param asan\-stack=0\fR option.
! .IP "\fBasan-instrument-reads\fR" 4
  .IX Item "asan-instrument-reads"
  Enable buffer overflow detection for memory reads.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable memory reads protection use
  \&\fB\-\-param asan\-instrument\-reads=0\fR.
! .IP "\fBasan-instrument-writes\fR" 4
  .IX Item "asan-instrument-writes"
  Enable buffer overflow detection for memory writes.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable memory writes protection use
  \&\fB\-\-param asan\-instrument\-writes=0\fR option.
! .IP "\fBasan-memintrin\fR" 4
  .IX Item "asan-memintrin"
! Enable detection for built-in functions.  This kind of protection
  is enabled by default when using \fB\-fsanitize=address\fR.
! To disable built-in functions protection use
  \&\fB\-\-param asan\-memintrin=0\fR.
! .IP "\fBasan-use-after-return\fR" 4
  .IX Item "asan-use-after-return"
! Enable detection of use-after-return.  This kind of protection
  is enabled by default when using the \fB\-fsanitize=address\fR option.
  To disable it use \fB\-\-param asan\-use\-after\-return=0\fR.
  .Sp
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_stack_use_after_return=1\*(C'\fR to the environment variable
! \&\fB\s-1ASAN_OPTIONS\s0\fR.
! .IP "\fBasan-instrumentation-with-call-threshold\fR" 4
  .IX Item "asan-instrumentation-with-call-threshold"
  If number of memory accesses in function being instrumented
  is greater or equal to this number, use callbacks instead of inline checks.
  E.g. to disable inline code use
  \&\fB\-\-param asan\-instrumentation\-with\-call\-threshold=0\fR.
! .IP "\fBasan-kernel-mem-intrinsic-prefix\fR" 4
  .IX Item "asan-kernel-mem-intrinsic-prefix"
  If nonzero, prefix calls to \f(CW\*(C`memcpy\*(C'\fR, \f(CW\*(C`memset\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR
  with \fB_\|_asan_\fR or \fB_\|_hwasan_\fR
  for \fB\-fsanitize=kernel\-address\fR or \fB\-fsanitize=kernel\-hwaddress\fR,
  respectively.
! .IP "\fBhwasan-instrument-stack\fR" 4
  .IX Item "hwasan-instrument-stack"
! Enable hwasan instrumentation of statically sized stack-allocated variables.
  This kind of instrumentation is enabled by default when using
  \&\fB\-fsanitize=hwaddress\fR and disabled by default when using
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable stack instrumentation use
  \&\fB\-\-param hwasan\-instrument\-stack=0\fR, and to enable it use
  \&\fB\-\-param hwasan\-instrument\-stack=1\fR.
! .IP "\fBhwasan-random-frame-tag\fR" 4
  .IX Item "hwasan-random-frame-tag"
  When using stack instrumentation, decide tags for stack variables using a
  deterministic sequence beginning at a random tag for each frame.  With this
--- 14828,14900 ----
  conservative approach taken by algorithm 1 and the rather aggressive
  approach taken by the default scheduler.  It relies more heavily on
  having a regular register file and accurate register pressure classes.
! See \fIhaifa\-sched.cc\fR in the GCC sources for more details.
  .Sp
  The default choice depends on the target.
! .IP \fBmax\-slsr\-cand\-scan\fR 4
  .IX Item "max-slsr-cand-scan"
  Set the maximum number of existing candidates that are considered when
! seeking a basis for a new straight\-line strength reduction candidate.
! .IP \fBasan\-globals\fR 4
  .IX Item "asan-globals"
  Enable buffer overflow detection for global objects.  This kind
  of protection is enabled by default if you are using
  \&\fB\-fsanitize=address\fR option.
  To disable global objects protection use \fB\-\-param asan\-globals=0\fR.
! .IP \fBasan\-stack\fR 4
  .IX Item "asan-stack"
  Enable buffer overflow detection for stack objects.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable stack protection use \fB\-\-param asan\-stack=0\fR option.
! .IP \fBasan\-instrument\-reads\fR 4
  .IX Item "asan-instrument-reads"
  Enable buffer overflow detection for memory reads.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable memory reads protection use
  \&\fB\-\-param asan\-instrument\-reads=0\fR.
! .IP \fBasan\-instrument\-writes\fR 4
  .IX Item "asan-instrument-writes"
  Enable buffer overflow detection for memory writes.  This kind of
  protection is enabled by default when using \fB\-fsanitize=address\fR.
  To disable memory writes protection use
  \&\fB\-\-param asan\-instrument\-writes=0\fR option.
! .IP \fBasan\-memintrin\fR 4
  .IX Item "asan-memintrin"
! Enable detection for built\-in functions.  This kind of protection
  is enabled by default when using \fB\-fsanitize=address\fR.
! To disable built\-in functions protection use
  \&\fB\-\-param asan\-memintrin=0\fR.
! .IP \fBasan\-use\-after\-return\fR 4
  .IX Item "asan-use-after-return"
! Enable detection of use\-after\-return.  This kind of protection
  is enabled by default when using the \fB\-fsanitize=address\fR option.
  To disable it use \fB\-\-param asan\-use\-after\-return=0\fR.
  .Sp
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_stack_use_after_return=1\*(C'\fR to the environment variable
! \&\fBASAN_OPTIONS\fR.
! .IP \fBasan\-instrumentation\-with\-call\-threshold\fR 4
  .IX Item "asan-instrumentation-with-call-threshold"
  If number of memory accesses in function being instrumented
  is greater or equal to this number, use callbacks instead of inline checks.
  E.g. to disable inline code use
  \&\fB\-\-param asan\-instrumentation\-with\-call\-threshold=0\fR.
! .IP \fBasan\-kernel\-mem\-intrinsic\-prefix\fR 4
  .IX Item "asan-kernel-mem-intrinsic-prefix"
  If nonzero, prefix calls to \f(CW\*(C`memcpy\*(C'\fR, \f(CW\*(C`memset\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR
  with \fB_\|_asan_\fR or \fB_\|_hwasan_\fR
  for \fB\-fsanitize=kernel\-address\fR or \fB\-fsanitize=kernel\-hwaddress\fR,
  respectively.
! .IP \fBhwasan\-instrument\-stack\fR 4
  .IX Item "hwasan-instrument-stack"
! Enable hwasan instrumentation of statically sized stack\-allocated variables.
  This kind of instrumentation is enabled by default when using
  \&\fB\-fsanitize=hwaddress\fR and disabled by default when using
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable stack instrumentation use
  \&\fB\-\-param hwasan\-instrument\-stack=0\fR, and to enable it use
  \&\fB\-\-param hwasan\-instrument\-stack=1\fR.
! .IP \fBhwasan\-random\-frame\-tag\fR 4
  .IX Item "hwasan-random-frame-tag"
  When using stack instrumentation, decide tags for stack variables using a
  deterministic sequence beginning at a random tag for each frame.  With this
*************** parameter unset tags are chosen using th
*** 14973,15099 ****
  This is enabled by default for \fB\-fsanitize=hwaddress\fR and unavailable
  for \fB\-fsanitize=kernel\-hwaddress\fR.
  To disable it use \fB\-\-param hwasan\-random\-frame\-tag=0\fR.
! .IP "\fBhwasan-instrument-allocas\fR" 4
  .IX Item "hwasan-instrument-allocas"
! Enable hwasan instrumentation of dynamically sized stack-allocated variables.
  This kind of instrumentation is enabled by default when using
  \&\fB\-fsanitize=hwaddress\fR and disabled by default when using
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable instrumentation of such variables use
  \&\fB\-\-param hwasan\-instrument\-allocas=0\fR, and to enable it use
  \&\fB\-\-param hwasan\-instrument\-allocas=1\fR.
! .IP "\fBhwasan-instrument-reads\fR" 4
  .IX Item "hwasan-instrument-reads"
  Enable hwasan checks on memory reads.  Instrumentation of reads is enabled by
  default for both \fB\-fsanitize=hwaddress\fR and
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable checking memory reads use
  \&\fB\-\-param hwasan\-instrument\-reads=0\fR.
! .IP "\fBhwasan-instrument-writes\fR" 4
  .IX Item "hwasan-instrument-writes"
  Enable hwasan checks on memory writes.  Instrumentation of writes is enabled by
  default for both \fB\-fsanitize=hwaddress\fR and
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable checking memory writes use
  \&\fB\-\-param hwasan\-instrument\-writes=0\fR.
! .IP "\fBhwasan-instrument-mem-intrinsics\fR" 4
  .IX Item "hwasan-instrument-mem-intrinsics"
  Enable hwasan instrumentation of builtin functions.  Instrumentation of these
  builtin functions is enabled by default for both \fB\-fsanitize=hwaddress\fR
  and \fB\-fsanitize=kernel\-hwaddress\fR.
  To disable instrumentation of builtin functions use
  \&\fB\-\-param hwasan\-instrument\-mem\-intrinsics=0\fR.
! .IP "\fBuse-after-scope-direct-emission-threshold\fR" 4
  .IX Item "use-after-scope-direct-emission-threshold"
  If the size of a local variable in bytes is smaller or equal to this
  number, directly poison (or unpoison) shadow memory instead of using
! run-time callbacks.
! .IP "\fBtsan-distinguish-volatile\fR" 4
  .IX Item "tsan-distinguish-volatile"
  Emit special instrumentation for accesses to volatiles.
! .IP "\fBtsan-instrument-func-entry-exit\fR" 4
  .IX Item "tsan-instrument-func-entry-exit"
  Emit instrumentation calls to _\|\fB_tsan_func_entry()\fR and _\|\fB_tsan_func_exit()\fR.
! .IP "\fBmax-fsm-thread-path-insns\fR" 4
  .IX Item "max-fsm-thread-path-insns"
  Maximum number of instructions to copy when duplicating blocks on a
  finite state automaton jump thread path.
! .IP "\fBthreader-debug\fR" 4
  .IX Item "threader-debug"
  threader\-debug=[none|all] Enables verbose dumping of the threader solver.
! .IP "\fBparloops-chunk-size\fR" 4
  .IX Item "parloops-chunk-size"
  Chunk size of omp schedule for loops parallelized by parloops.
! .IP "\fBparloops-schedule\fR" 4
  .IX Item "parloops-schedule"
  Schedule type of omp schedule for loops parallelized by parloops (static,
  dynamic, guided, auto, runtime).
! .IP "\fBparloops-min-per-thread\fR" 4
  .IX Item "parloops-min-per-thread"
  The minimum number of iterations per thread of an innermost parallelized
  loop for which the parallelized variant is preferred over the single threaded
  one.  Note that for a parallelized loop nest the
  minimum number of iterations of the outermost loop per thread is two.
! .IP "\fBmax-ssa-name-query-depth\fR" 4
  .IX Item "max-ssa-name-query-depth"
! Maximum depth of recursion when querying properties of \s-1SSA\s0 names in things
  like fold routines.  One level of recursion corresponds to following a
! use-def chain.
! .IP "\fBmax-speculative-devirt-maydefs\fR" 4
  .IX Item "max-speculative-devirt-maydefs"
! The maximum number of may-defs we analyze when looking for a must-def
  specifying the dynamic type of an object that invokes a virtual call
  we may be able to devirtualize speculatively.
! .IP "\fBevrp-sparse-threshold\fR" 4
  .IX Item "evrp-sparse-threshold"
! Maximum number of basic blocks before \s-1EVRP\s0 uses a sparse cache.
! .IP "\fBranger-debug\fR" 4
  .IX Item "ranger-debug"
  Specifies the type of debug output to be issued for ranges.
! .IP "\fBevrp-switch-limit\fR" 4
  .IX Item "evrp-switch-limit"
! Specifies the maximum number of switch cases before \s-1EVRP\s0 ignores a switch.
! .IP "\fBunroll-jam-min-percent\fR" 4
  .IX Item "unroll-jam-min-percent"
  The minimum percentage of memory references that must be optimized
! away for the unroll-and-jam transformation to be considered profitable.
! .IP "\fBunroll-jam-max-unroll\fR" 4
  .IX Item "unroll-jam-max-unroll"
  The maximum number of times the outer loop should be unrolled by
! the unroll-and-jam transformation.
! .IP "\fBmax-rtl-if-conversion-unpredictable-cost\fR" 4
  .IX Item "max-rtl-if-conversion-unpredictable-cost"
  Maximum permissible cost for the sequence that would be generated
! by the \s-1RTL\s0 if-conversion pass for a branch that is considered unpredictable.
! .IP "\fBmax-variable-expansions-in-unroller\fR" 4
  .IX Item "max-variable-expansions-in-unroller"
  If \fB\-fvariable\-expansion\-in\-unroller\fR is used, the maximum number
  of times that an individual variable will be expanded during loop unrolling.
! .IP "\fBpartial-inlining-entry-probability\fR" 4
  .IX Item "partial-inlining-entry-probability"
! Maximum probability of the entry \s-1BB\s0 of split region
! (in percent relative to entry \s-1BB\s0 of the function)
  to make partial inlining happen.
! .IP "\fBmax-tracked-strlens\fR" 4
  .IX Item "max-tracked-strlens"
  Maximum number of strings for which strlen optimization pass will
  track string lengths.
! .IP "\fBgcse-after-reload-partial-fraction\fR" 4
  .IX Item "gcse-after-reload-partial-fraction"
  The threshold ratio for performing partial redundancy
  elimination after reload.
! .IP "\fBgcse-after-reload-critical-fraction\fR" 4
  .IX Item "gcse-after-reload-critical-fraction"
  The threshold ratio of critical edges execution count that
  permit performing redundancy elimination after reload.
! .IP "\fBmax-loop-header-insns\fR" 4
  .IX Item "max-loop-header-insns"
  The maximum number of insns in loop header duplicated
  by the copy loop headers pass.
! .IP "\fBvect-epilogues-nomask\fR" 4
  .IX Item "vect-epilogues-nomask"
  Enable loop epilogue vectorization using smaller vector size.
! .IP "\fBvect-partial-vector-usage\fR" 4
  .IX Item "vect-partial-vector-usage"
  Controls when the loop vectorizer considers using partial vector loads
  and stores as an alternative to falling back to scalar code.  0 stops
--- 14902,15028 ----
  This is enabled by default for \fB\-fsanitize=hwaddress\fR and unavailable
  for \fB\-fsanitize=kernel\-hwaddress\fR.
  To disable it use \fB\-\-param hwasan\-random\-frame\-tag=0\fR.
! .IP \fBhwasan\-instrument\-allocas\fR 4
  .IX Item "hwasan-instrument-allocas"
! Enable hwasan instrumentation of dynamically sized stack\-allocated variables.
  This kind of instrumentation is enabled by default when using
  \&\fB\-fsanitize=hwaddress\fR and disabled by default when using
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable instrumentation of such variables use
  \&\fB\-\-param hwasan\-instrument\-allocas=0\fR, and to enable it use
  \&\fB\-\-param hwasan\-instrument\-allocas=1\fR.
! .IP \fBhwasan\-instrument\-reads\fR 4
  .IX Item "hwasan-instrument-reads"
  Enable hwasan checks on memory reads.  Instrumentation of reads is enabled by
  default for both \fB\-fsanitize=hwaddress\fR and
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable checking memory reads use
  \&\fB\-\-param hwasan\-instrument\-reads=0\fR.
! .IP \fBhwasan\-instrument\-writes\fR 4
  .IX Item "hwasan-instrument-writes"
  Enable hwasan checks on memory writes.  Instrumentation of writes is enabled by
  default for both \fB\-fsanitize=hwaddress\fR and
  \&\fB\-fsanitize=kernel\-hwaddress\fR.
  To disable checking memory writes use
  \&\fB\-\-param hwasan\-instrument\-writes=0\fR.
! .IP \fBhwasan\-instrument\-mem\-intrinsics\fR 4
  .IX Item "hwasan-instrument-mem-intrinsics"
  Enable hwasan instrumentation of builtin functions.  Instrumentation of these
  builtin functions is enabled by default for both \fB\-fsanitize=hwaddress\fR
  and \fB\-fsanitize=kernel\-hwaddress\fR.
  To disable instrumentation of builtin functions use
  \&\fB\-\-param hwasan\-instrument\-mem\-intrinsics=0\fR.
! .IP \fBuse\-after\-scope\-direct\-emission\-threshold\fR 4
  .IX Item "use-after-scope-direct-emission-threshold"
  If the size of a local variable in bytes is smaller or equal to this
  number, directly poison (or unpoison) shadow memory instead of using
! run\-time callbacks.
! .IP \fBtsan\-distinguish\-volatile\fR 4
  .IX Item "tsan-distinguish-volatile"
  Emit special instrumentation for accesses to volatiles.
! .IP \fBtsan\-instrument\-func\-entry\-exit\fR 4
  .IX Item "tsan-instrument-func-entry-exit"
  Emit instrumentation calls to _\|\fB_tsan_func_entry()\fR and _\|\fB_tsan_func_exit()\fR.
! .IP \fBmax\-fsm\-thread\-path\-insns\fR 4
  .IX Item "max-fsm-thread-path-insns"
  Maximum number of instructions to copy when duplicating blocks on a
  finite state automaton jump thread path.
! .IP \fBthreader\-debug\fR 4
  .IX Item "threader-debug"
  threader\-debug=[none|all] Enables verbose dumping of the threader solver.
! .IP \fBparloops\-chunk\-size\fR 4
  .IX Item "parloops-chunk-size"
  Chunk size of omp schedule for loops parallelized by parloops.
! .IP \fBparloops\-schedule\fR 4
  .IX Item "parloops-schedule"
  Schedule type of omp schedule for loops parallelized by parloops (static,
  dynamic, guided, auto, runtime).
! .IP \fBparloops\-min\-per\-thread\fR 4
  .IX Item "parloops-min-per-thread"
  The minimum number of iterations per thread of an innermost parallelized
  loop for which the parallelized variant is preferred over the single threaded
  one.  Note that for a parallelized loop nest the
  minimum number of iterations of the outermost loop per thread is two.
! .IP \fBmax\-ssa\-name\-query\-depth\fR 4
  .IX Item "max-ssa-name-query-depth"
! Maximum depth of recursion when querying properties of SSA names in things
  like fold routines.  One level of recursion corresponds to following a
! use\-def chain.
! .IP \fBmax\-speculative\-devirt\-maydefs\fR 4
  .IX Item "max-speculative-devirt-maydefs"
! The maximum number of may\-defs we analyze when looking for a must\-def
  specifying the dynamic type of an object that invokes a virtual call
  we may be able to devirtualize speculatively.
! .IP \fBevrp\-sparse\-threshold\fR 4
  .IX Item "evrp-sparse-threshold"
! Maximum number of basic blocks before EVRP uses a sparse cache.
! .IP \fBranger\-debug\fR 4
  .IX Item "ranger-debug"
  Specifies the type of debug output to be issued for ranges.
! .IP \fBevrp\-switch\-limit\fR 4
  .IX Item "evrp-switch-limit"
! Specifies the maximum number of switch cases before EVRP ignores a switch.
! .IP \fBunroll\-jam\-min\-percent\fR 4
  .IX Item "unroll-jam-min-percent"
  The minimum percentage of memory references that must be optimized
! away for the unroll\-and\-jam transformation to be considered profitable.
! .IP \fBunroll\-jam\-max\-unroll\fR 4
  .IX Item "unroll-jam-max-unroll"
  The maximum number of times the outer loop should be unrolled by
! the unroll\-and\-jam transformation.
! .IP \fBmax\-rtl\-if\-conversion\-unpredictable\-cost\fR 4
  .IX Item "max-rtl-if-conversion-unpredictable-cost"
  Maximum permissible cost for the sequence that would be generated
! by the RTL if\-conversion pass for a branch that is considered unpredictable.
! .IP \fBmax\-variable\-expansions\-in\-unroller\fR 4
  .IX Item "max-variable-expansions-in-unroller"
  If \fB\-fvariable\-expansion\-in\-unroller\fR is used, the maximum number
  of times that an individual variable will be expanded during loop unrolling.
! .IP \fBpartial\-inlining\-entry\-probability\fR 4
  .IX Item "partial-inlining-entry-probability"
! Maximum probability of the entry BB of split region
! (in percent relative to entry BB of the function)
  to make partial inlining happen.
! .IP \fBmax\-tracked\-strlens\fR 4
  .IX Item "max-tracked-strlens"
  Maximum number of strings for which strlen optimization pass will
  track string lengths.
! .IP \fBgcse\-after\-reload\-partial\-fraction\fR 4
  .IX Item "gcse-after-reload-partial-fraction"
  The threshold ratio for performing partial redundancy
  elimination after reload.
! .IP \fBgcse\-after\-reload\-critical\-fraction\fR 4
  .IX Item "gcse-after-reload-critical-fraction"
  The threshold ratio of critical edges execution count that
  permit performing redundancy elimination after reload.
! .IP \fBmax\-loop\-header\-insns\fR 4
  .IX Item "max-loop-header-insns"
  The maximum number of insns in loop header duplicated
  by the copy loop headers pass.
! .IP \fBvect\-epilogues\-nomask\fR 4
  .IX Item "vect-epilogues-nomask"
  Enable loop epilogue vectorization using smaller vector size.
! .IP \fBvect\-partial\-vector\-usage\fR 4
  .IX Item "vect-partial-vector-usage"
  Controls when the loop vectorizer considers using partial vector loads
  and stores as an alternative to falling back to scalar code.  0 stops
*************** partial vector loads and stores if vecto
*** 15102,15369 ****
  code to iterate.  2 allows partial vector loads and stores in all loops.
  The parameter only has an effect on targets that support partial
  vector loads and stores.
! .IP "\fBvect-inner-loop-cost-factor\fR" 4
  .IX Item "vect-inner-loop-cost-factor"
  The maximum factor which the loop vectorizer applies to the cost of statements
  in an inner loop relative to the loop being vectorized.  The factor applied
  is the maximum of the estimated number of iterations of the inner loop and
  this parameter.  The default value of this parameter is 50.
! .IP "\fBvect-induction-float\fR" 4
  .IX Item "vect-induction-float"
  Enable loop vectorization of floating point inductions.
! .IP "\fBavoid-fma-max-bits\fR" 4
  .IX Item "avoid-fma-max-bits"
  Maximum number of bits for which we avoid creating FMAs.
! .IP "\fBsms-loop-average-count-threshold\fR" 4
  .IX Item "sms-loop-average-count-threshold"
  A threshold on the average loop count considered by the swing modulo scheduler.
! .IP "\fBsms-dfa-history\fR" 4
  .IX Item "sms-dfa-history"
  The number of cycles the swing modulo scheduler considers when checking
! conflicts using \s-1DFA.\s0
! .IP "\fBgraphite-allow-codegen-errors\fR" 4
  .IX Item "graphite-allow-codegen-errors"
  Whether codegen errors should be ICEs when \fB\-fchecking\fR.
! .IP "\fBsms-max-ii-factor\fR" 4
  .IX Item "sms-max-ii-factor"
  A factor for tuning the upper bound that swing modulo scheduler
  uses for scheduling a loop.
! .IP "\fBlra-max-considered-reload-pseudos\fR" 4
  .IX Item "lra-max-considered-reload-pseudos"
  The max number of reload pseudos which are considered during
! spilling a non-reload pseudo.
! .IP "\fBmax-pow-sqrt-depth\fR" 4
  .IX Item "max-pow-sqrt-depth"
  Maximum depth of sqrt chains to use when synthesizing exponentiation
  by a real constant.
! .IP "\fBmax-dse-active-local-stores\fR" 4
  .IX Item "max-dse-active-local-stores"
! Maximum number of active local stores in \s-1RTL\s0 dead store elimination.
! .IP "\fBasan-instrument-allocas\fR" 4
  .IX Item "asan-instrument-allocas"
  Enable asan allocas/VLAs protection.
! .IP "\fBmax-iterations-computation-cost\fR" 4
  .IX Item "max-iterations-computation-cost"
  Bound on the cost of an expression to compute the number of iterations.
! .IP "\fBmax-isl-operations\fR" 4
  .IX Item "max-isl-operations"
  Maximum number of isl operations, 0 means unlimited.
! .IP "\fBgraphite-max-arrays-per-scop\fR" 4
  .IX Item "graphite-max-arrays-per-scop"
  Maximum number of arrays per scop.
! .IP "\fBmax-vartrack-reverse-op-size\fR" 4
  .IX Item "max-vartrack-reverse-op-size"
  Max. size of loc list for which reverse ops should be added.
! .IP "\fBfsm-scale-path-stmts\fR" 4
  .IX Item "fsm-scale-path-stmts"
  Scale factor to apply to the number of statements in a threading path
  crossing a loop backedge when comparing to
  \&\fB\-\-param=max\-jump\-thread\-duplication\-stmts\fR.
! .IP "\fBuninit-control-dep-attempts\fR" 4
  .IX Item "uninit-control-dep-attempts"
  Maximum number of nested calls to search for control dependencies
  during uninitialized variable analysis.
! .IP "\fBuninit-max-chain-len\fR" 4
  .IX Item "uninit-max-chain-len"
  Maximum number of predicates anded for each predicate ored in the normalized
  predicate chain.
! .IP "\fBuninit-max-num-chains\fR" 4
  .IX Item "uninit-max-num-chains"
  Maximum number of predicates ored in the normalized predicate chain.
! .IP "\fBsched-autopref-queue-depth\fR" 4
  .IX Item "sched-autopref-queue-depth"
  Hardware autoprefetcher scheduler model control flag.
! Number of lookahead cycles the model looks into; at '
! \&' only enable instruction sorting heuristic.
! .IP "\fBloop-versioning-max-inner-insns\fR" 4
  .IX Item "loop-versioning-max-inner-insns"
  The maximum number of instructions that an inner loop can have
  before the loop versioning pass considers it too big to copy.
! .IP "\fBloop-versioning-max-outer-insns\fR" 4
  .IX Item "loop-versioning-max-outer-insns"
  The maximum number of instructions that an outer loop can have
  before the loop versioning pass considers it too big to copy,
  discounting any instructions in inner loops that directly benefit
  from versioning.
! .IP "\fBssa-name-def-chain-limit\fR" 4
  .IX Item "ssa-name-def-chain-limit"
! The maximum number of \s-1SSA_NAME\s0 assignments to follow in determining
  a property of a variable such as its value.  This limits the number
! of iterations or recursive calls \s-1GCC\s0 performs when optimizing certain
  statements or when determining their validity prior to issuing
  diagnostics.
! .IP "\fBstore-merging-max-size\fR" 4
  .IX Item "store-merging-max-size"
  Maximum size of a single store merging region in bytes.
! .IP "\fBhash-table-verification-limit\fR" 4
  .IX Item "hash-table-verification-limit"
  The number of elements for which hash table verification is done
  for each searched element.
! .IP "\fBmax-find-base-term-values\fR" 4
  .IX Item "max-find-base-term-values"
  Maximum number of VALUEs handled during a single find_base_term call.
! .IP "\fBanalyzer-max-enodes-per-program-point\fR" 4
  .IX Item "analyzer-max-enodes-per-program-point"
  The maximum number of exploded nodes per program point within
  the analyzer, before terminating analysis of that point.
! .IP "\fBanalyzer-max-constraints\fR" 4
  .IX Item "analyzer-max-constraints"
  The maximum number of constraints per state.
! .IP "\fBanalyzer-min-snodes-for-call-summary\fR" 4
  .IX Item "analyzer-min-snodes-for-call-summary"
  The minimum number of supernodes within a function for the
  analyzer to consider summarizing its effects at call sites.
! .IP "\fBanalyzer-max-enodes-for-full-dump\fR" 4
  .IX Item "analyzer-max-enodes-for-full-dump"
  The maximum depth of exploded nodes that should appear in a dot dump
  before switching to a less verbose format.
! .IP "\fBanalyzer-max-recursion-depth\fR" 4
  .IX Item "analyzer-max-recursion-depth"
  The maximum number of times a callsite can appear in a call stack
  within the analyzer, before terminating analysis of a call that would
  recurse deeper.
! .IP "\fBanalyzer-max-svalue-depth\fR" 4
  .IX Item "analyzer-max-svalue-depth"
  The maximum depth of a symbolic value, before approximating
  the value as unknown.
! .IP "\fBanalyzer-max-infeasible-edges\fR" 4
  .IX Item "analyzer-max-infeasible-edges"
  The maximum number of infeasible edges to reject before declaring
  a diagnostic as infeasible.
! .IP "\fBgimple-fe-computed-hot-bb-threshold\fR" 4
  .IX Item "gimple-fe-computed-hot-bb-threshold"
  The number of executions of a basic block which is considered hot.
! The parameter is used only in \s-1GIMPLE FE.\s0
! .IP "\fBanalyzer-bb-explosion-factor\fR" 4
  .IX Item "analyzer-bb-explosion-factor"
! The maximum number of 'after supernode' exploded nodes within the analyzer
  per supernode, before terminating analysis.
! .IP "\fBranger-logical-depth\fR" 4
  .IX Item "ranger-logical-depth"
  Maximum depth of logical expression evaluation ranger will look through
  when evaluating outgoing edge ranges.
! .IP "\fBranger-recompute-depth\fR" 4
  .IX Item "ranger-recompute-depth"
  Maximum depth of instruction chains to consider for recomputation
  in the outgoing range calculator.
! .IP "\fBrelation-block-limit\fR" 4
  .IX Item "relation-block-limit"
  Maximum number of relations the oracle will register in a basic block.
! .IP "\fBmin-pagesize\fR" 4
  .IX Item "min-pagesize"
  Minimum page size for warning purposes.
! .IP "\fBopenacc-kernels\fR" 4
  .IX Item "openacc-kernels"
! Specify mode of OpenACC `kernels' constructs handling.
! With \fB\-\-param=openacc\-kernels=decompose\fR, OpenACC `kernels'
  constructs are decomposed into parts, a sequence of compute
  constructs, each then handled individually.
  This is work in progress.
! With \fB\-\-param=openacc\-kernels=parloops\fR, OpenACC `kernels'
  constructs are handled by the \fBparloops\fR pass, en bloc.
  This is the current default.
! .IP "\fBopenacc-privatization\fR" 4
  .IX Item "openacc-privatization"
  Control whether the \fB\-fopt\-info\-omp\-note\fR and applicable
  \&\fB\-fdump\-tree\-*\-details\fR options emit OpenACC privatization diagnostics.
! With \fB\-\-param=openacc\-privatization=quiet\fR, don't diagnose.
  This is the current default.
  With \fB\-\-param=openacc\-privatization=noisy\fR, do diagnose.
  .RE
  .RS 4
  .Sp
  The following choices of \fIname\fR are available on AArch64 targets:
! .IP "\fBaarch64\-sve\-compare\-costs\fR" 4
  .IX Item "aarch64-sve-compare-costs"
! When vectorizing for \s-1SVE,\s0 consider using \*(L"unpacked\*(R" vectors for
  smaller elements and use the cost model to pick the cheapest approach.
! Also use the cost model to choose between \s-1SVE\s0 and Advanced \s-1SIMD\s0 vectorization.
  .Sp
  Using unpacked vectors includes storing smaller elements in larger
  containers and accessing elements with extending loads and truncating
  stores.
! .IP "\fBaarch64\-float\-recp\-precision\fR" 4
  .IX Item "aarch64-float-recp-precision"
  The number of Newton iterations for calculating the reciprocal for float type.
  The precision of division is proportional to this param when division
  approximation is enabled.  The default value is 1.
! .IP "\fBaarch64\-double\-recp\-precision\fR" 4
  .IX Item "aarch64-double-recp-precision"
  The number of Newton iterations for calculating the reciprocal for double type.
  The precision of division is propotional to this param when division
  approximation is enabled.  The default value is 2.
! .IP "\fBaarch64\-autovec\-preference\fR" 4
  .IX Item "aarch64-autovec-preference"
! Force an \s-1ISA\s0 selection strategy for auto-vectorization.  Accepts values from
  0 to 4, inclusive.
  .RS 4
! .IP "\fB0\fR" 4
  .IX Item "0"
  Use the default heuristics.
! .IP "\fB1\fR" 4
  .IX Item "1"
! Use only Advanced \s-1SIMD\s0 for auto-vectorization.
! .IP "\fB2\fR" 4
  .IX Item "2"
! Use only \s-1SVE\s0 for auto-vectorization.
! .IP "\fB3\fR" 4
  .IX Item "3"
! Use both Advanced \s-1SIMD\s0 and \s-1SVE.\s0  Prefer Advanced \s-1SIMD\s0 when the costs are
  deemed equal.
! .IP "\fB4\fR" 4
  .IX Item "4"
! Use both Advanced \s-1SIMD\s0 and \s-1SVE.\s0  Prefer \s-1SVE\s0 when the costs are deemed equal.
  .RE
  .RS 4
  .Sp
  The default value is 0.
  .RE
! .IP "\fBaarch64\-loop\-vect\-issue\-rate\-niters\fR" 4
  .IX Item "aarch64-loop-vect-issue-rate-niters"
  The tuning for some AArch64 CPUs tries to take both latencies and issue
  rates into account when deciding whether a loop should be vectorized
! using \s-1SVE,\s0 vectorized using Advanced \s-1SIMD,\s0 or not vectorized at all.
! If this parameter is set to \fIn\fR, \s-1GCC\s0 will not use this heuristic
  for loops that are known to execute in fewer than \fIn\fR Advanced
! \&\s-1SIMD\s0 iterations.
! .IP "\fBaarch64\-vect\-unroll\-limit\fR" 4
  .IX Item "aarch64-vect-unroll-limit"
  The vectorizer will use available tuning information to determine whether it
  would be beneficial to unroll the main vectorized loop and by how much.  This
! parameter set's the upper bound of how much the vectorizer will unroll the main
  loop.  The default value is four.
  .RE
  .RS 4
  .Sp
  The following choices of \fIname\fR are available on i386 and x86_64 targets:
! .IP "\fBx86\-stlf\-window\-ninsns\fR" 4
  .IX Item "x86-stlf-window-ninsns"
! Instructions number above which \s-1STFL\s0 stall penalty can be compensated.
! .IP "\fBx86\-stv\-max\-visits\fR" 4
  .IX Item "x86-stv-max-visits"
! The maximum number of use and def visits when discovering a \s-1STV\s0 chain before
  the discovery is aborted.
  .RE
  .RS 4
  .RE
  .SS "Program Instrumentation Options"
  .IX Subsection "Program Instrumentation Options"
! \&\s-1GCC\s0 supports a number of command-line options that control adding
! run-time instrumentation to the code it normally generates.  
  For example, one purpose of instrumentation is collect profiling
  statistics for use in finding program hot spots, code coverage
! analysis, or profile-guided optimizations.
! Another class of program instrumentation is adding run-time checking 
  to detect programming errors like invalid pointer
! dereferences or out-of-bounds array accesses, as well as deliberately
! hostile attacks such as stack smashing or \*(C+ vtable hijacking.
  There is also a general hook which can be used to implement other
! forms of tracing or function-level instrumentation for debug or
  program analysis purposes.
! .IP "\fB\-p\fR" 4
  .IX Item "-p"
  .PD 0
! .IP "\fB\-pg\fR" 4
  .IX Item "-pg"
  .PD
  Generate extra code to write profile information suitable for the
--- 15031,15298 ----
  code to iterate.  2 allows partial vector loads and stores in all loops.
  The parameter only has an effect on targets that support partial
  vector loads and stores.
! .IP \fBvect\-inner\-loop\-cost\-factor\fR 4
  .IX Item "vect-inner-loop-cost-factor"
  The maximum factor which the loop vectorizer applies to the cost of statements
  in an inner loop relative to the loop being vectorized.  The factor applied
  is the maximum of the estimated number of iterations of the inner loop and
  this parameter.  The default value of this parameter is 50.
! .IP \fBvect\-induction\-float\fR 4
  .IX Item "vect-induction-float"
  Enable loop vectorization of floating point inductions.
! .IP \fBavoid\-fma\-max\-bits\fR 4
  .IX Item "avoid-fma-max-bits"
  Maximum number of bits for which we avoid creating FMAs.
! .IP \fBsms\-loop\-average\-count\-threshold\fR 4
  .IX Item "sms-loop-average-count-threshold"
  A threshold on the average loop count considered by the swing modulo scheduler.
! .IP \fBsms\-dfa\-history\fR 4
  .IX Item "sms-dfa-history"
  The number of cycles the swing modulo scheduler considers when checking
! conflicts using DFA.
! .IP \fBgraphite\-allow\-codegen\-errors\fR 4
  .IX Item "graphite-allow-codegen-errors"
  Whether codegen errors should be ICEs when \fB\-fchecking\fR.
! .IP \fBsms\-max\-ii\-factor\fR 4
  .IX Item "sms-max-ii-factor"
  A factor for tuning the upper bound that swing modulo scheduler
  uses for scheduling a loop.
! .IP \fBlra\-max\-considered\-reload\-pseudos\fR 4
  .IX Item "lra-max-considered-reload-pseudos"
  The max number of reload pseudos which are considered during
! spilling a non\-reload pseudo.
! .IP \fBmax\-pow\-sqrt\-depth\fR 4
  .IX Item "max-pow-sqrt-depth"
  Maximum depth of sqrt chains to use when synthesizing exponentiation
  by a real constant.
! .IP \fBmax\-dse\-active\-local\-stores\fR 4
  .IX Item "max-dse-active-local-stores"
! Maximum number of active local stores in RTL dead store elimination.
! .IP \fBasan\-instrument\-allocas\fR 4
  .IX Item "asan-instrument-allocas"
  Enable asan allocas/VLAs protection.
! .IP \fBmax\-iterations\-computation\-cost\fR 4
  .IX Item "max-iterations-computation-cost"
  Bound on the cost of an expression to compute the number of iterations.
! .IP \fBmax\-isl\-operations\fR 4
  .IX Item "max-isl-operations"
  Maximum number of isl operations, 0 means unlimited.
! .IP \fBgraphite\-max\-arrays\-per\-scop\fR 4
  .IX Item "graphite-max-arrays-per-scop"
  Maximum number of arrays per scop.
! .IP \fBmax\-vartrack\-reverse\-op\-size\fR 4
  .IX Item "max-vartrack-reverse-op-size"
  Max. size of loc list for which reverse ops should be added.
! .IP \fBfsm\-scale\-path\-stmts\fR 4
  .IX Item "fsm-scale-path-stmts"
  Scale factor to apply to the number of statements in a threading path
  crossing a loop backedge when comparing to
  \&\fB\-\-param=max\-jump\-thread\-duplication\-stmts\fR.
! .IP \fBuninit\-control\-dep\-attempts\fR 4
  .IX Item "uninit-control-dep-attempts"
  Maximum number of nested calls to search for control dependencies
  during uninitialized variable analysis.
! .IP \fBuninit\-max\-chain\-len\fR 4
  .IX Item "uninit-max-chain-len"
  Maximum number of predicates anded for each predicate ored in the normalized
  predicate chain.
! .IP \fBuninit\-max\-num\-chains\fR 4
  .IX Item "uninit-max-num-chains"
  Maximum number of predicates ored in the normalized predicate chain.
! .IP \fBsched\-autopref\-queue\-depth\fR 4
  .IX Item "sched-autopref-queue-depth"
  Hardware autoprefetcher scheduler model control flag.
! Number of lookahead cycles the model looks into; at \*(Aq
! \&\*(Aq only enable instruction sorting heuristic.
! .IP \fBloop\-versioning\-max\-inner\-insns\fR 4
  .IX Item "loop-versioning-max-inner-insns"
  The maximum number of instructions that an inner loop can have
  before the loop versioning pass considers it too big to copy.
! .IP \fBloop\-versioning\-max\-outer\-insns\fR 4
  .IX Item "loop-versioning-max-outer-insns"
  The maximum number of instructions that an outer loop can have
  before the loop versioning pass considers it too big to copy,
  discounting any instructions in inner loops that directly benefit
  from versioning.
! .IP \fBssa\-name\-def\-chain\-limit\fR 4
  .IX Item "ssa-name-def-chain-limit"
! The maximum number of SSA_NAME assignments to follow in determining
  a property of a variable such as its value.  This limits the number
! of iterations or recursive calls GCC performs when optimizing certain
  statements or when determining their validity prior to issuing
  diagnostics.
! .IP \fBstore\-merging\-max\-size\fR 4
  .IX Item "store-merging-max-size"
  Maximum size of a single store merging region in bytes.
! .IP \fBhash\-table\-verification\-limit\fR 4
  .IX Item "hash-table-verification-limit"
  The number of elements for which hash table verification is done
  for each searched element.
! .IP \fBmax\-find\-base\-term\-values\fR 4
  .IX Item "max-find-base-term-values"
  Maximum number of VALUEs handled during a single find_base_term call.
! .IP \fBanalyzer\-max\-enodes\-per\-program\-point\fR 4
  .IX Item "analyzer-max-enodes-per-program-point"
  The maximum number of exploded nodes per program point within
  the analyzer, before terminating analysis of that point.
! .IP \fBanalyzer\-max\-constraints\fR 4
  .IX Item "analyzer-max-constraints"
  The maximum number of constraints per state.
! .IP \fBanalyzer\-min\-snodes\-for\-call\-summary\fR 4
  .IX Item "analyzer-min-snodes-for-call-summary"
  The minimum number of supernodes within a function for the
  analyzer to consider summarizing its effects at call sites.
! .IP \fBanalyzer\-max\-enodes\-for\-full\-dump\fR 4
  .IX Item "analyzer-max-enodes-for-full-dump"
  The maximum depth of exploded nodes that should appear in a dot dump
  before switching to a less verbose format.
! .IP \fBanalyzer\-max\-recursion\-depth\fR 4
  .IX Item "analyzer-max-recursion-depth"
  The maximum number of times a callsite can appear in a call stack
  within the analyzer, before terminating analysis of a call that would
  recurse deeper.
! .IP \fBanalyzer\-max\-svalue\-depth\fR 4
  .IX Item "analyzer-max-svalue-depth"
  The maximum depth of a symbolic value, before approximating
  the value as unknown.
! .IP \fBanalyzer\-max\-infeasible\-edges\fR 4
  .IX Item "analyzer-max-infeasible-edges"
  The maximum number of infeasible edges to reject before declaring
  a diagnostic as infeasible.
! .IP \fBgimple\-fe\-computed\-hot\-bb\-threshold\fR 4
  .IX Item "gimple-fe-computed-hot-bb-threshold"
  The number of executions of a basic block which is considered hot.
! The parameter is used only in GIMPLE FE.
! .IP \fBanalyzer\-bb\-explosion\-factor\fR 4
  .IX Item "analyzer-bb-explosion-factor"
! The maximum number of \*(Aqafter supernode\*(Aq exploded nodes within the analyzer
  per supernode, before terminating analysis.
! .IP \fBranger\-logical\-depth\fR 4
  .IX Item "ranger-logical-depth"
  Maximum depth of logical expression evaluation ranger will look through
  when evaluating outgoing edge ranges.
! .IP \fBranger\-recompute\-depth\fR 4
  .IX Item "ranger-recompute-depth"
  Maximum depth of instruction chains to consider for recomputation
  in the outgoing range calculator.
! .IP \fBrelation\-block\-limit\fR 4
  .IX Item "relation-block-limit"
  Maximum number of relations the oracle will register in a basic block.
! .IP \fBmin\-pagesize\fR 4
  .IX Item "min-pagesize"
  Minimum page size for warning purposes.
! .IP \fBopenacc\-kernels\fR 4
  .IX Item "openacc-kernels"
! Specify mode of OpenACC \`kernels\*(Aq constructs handling.
! With \fB\-\-param=openacc\-kernels=decompose\fR, OpenACC \`kernels\*(Aq
  constructs are decomposed into parts, a sequence of compute
  constructs, each then handled individually.
  This is work in progress.
! With \fB\-\-param=openacc\-kernels=parloops\fR, OpenACC \`kernels\*(Aq
  constructs are handled by the \fBparloops\fR pass, en bloc.
  This is the current default.
! .IP \fBopenacc\-privatization\fR 4
  .IX Item "openacc-privatization"
  Control whether the \fB\-fopt\-info\-omp\-note\fR and applicable
  \&\fB\-fdump\-tree\-*\-details\fR options emit OpenACC privatization diagnostics.
! With \fB\-\-param=openacc\-privatization=quiet\fR, don\*(Aqt diagnose.
  This is the current default.
  With \fB\-\-param=openacc\-privatization=noisy\fR, do diagnose.
  .RE
  .RS 4
  .Sp
  The following choices of \fIname\fR are available on AArch64 targets:
! .IP \fBaarch64\-sve\-compare\-costs\fR 4
  .IX Item "aarch64-sve-compare-costs"
! When vectorizing for SVE, consider using "unpacked" vectors for
  smaller elements and use the cost model to pick the cheapest approach.
! Also use the cost model to choose between SVE and Advanced SIMD vectorization.
  .Sp
  Using unpacked vectors includes storing smaller elements in larger
  containers and accessing elements with extending loads and truncating
  stores.
! .IP \fBaarch64\-float\-recp\-precision\fR 4
  .IX Item "aarch64-float-recp-precision"
  The number of Newton iterations for calculating the reciprocal for float type.
  The precision of division is proportional to this param when division
  approximation is enabled.  The default value is 1.
! .IP \fBaarch64\-double\-recp\-precision\fR 4
  .IX Item "aarch64-double-recp-precision"
  The number of Newton iterations for calculating the reciprocal for double type.
  The precision of division is propotional to this param when division
  approximation is enabled.  The default value is 2.
! .IP \fBaarch64\-autovec\-preference\fR 4
  .IX Item "aarch64-autovec-preference"
! Force an ISA selection strategy for auto\-vectorization.  Accepts values from
  0 to 4, inclusive.
  .RS 4
! .IP \fB0\fR 4
  .IX Item "0"
  Use the default heuristics.
! .IP \fB1\fR 4
  .IX Item "1"
! Use only Advanced SIMD for auto\-vectorization.
! .IP \fB2\fR 4
  .IX Item "2"
! Use only SVE for auto\-vectorization.
! .IP \fB3\fR 4
  .IX Item "3"
! Use both Advanced SIMD and SVE.  Prefer Advanced SIMD when the costs are
  deemed equal.
! .IP \fB4\fR 4
  .IX Item "4"
! Use both Advanced SIMD and SVE.  Prefer SVE when the costs are deemed equal.
  .RE
  .RS 4
  .Sp
  The default value is 0.
  .RE
! .IP \fBaarch64\-loop\-vect\-issue\-rate\-niters\fR 4
  .IX Item "aarch64-loop-vect-issue-rate-niters"
  The tuning for some AArch64 CPUs tries to take both latencies and issue
  rates into account when deciding whether a loop should be vectorized
! using SVE, vectorized using Advanced SIMD, or not vectorized at all.
! If this parameter is set to \fIn\fR, GCC will not use this heuristic
  for loops that are known to execute in fewer than \fIn\fR Advanced
! SIMD iterations.
! .IP \fBaarch64\-vect\-unroll\-limit\fR 4
  .IX Item "aarch64-vect-unroll-limit"
  The vectorizer will use available tuning information to determine whether it
  would be beneficial to unroll the main vectorized loop and by how much.  This
! parameter set\*(Aqs the upper bound of how much the vectorizer will unroll the main
  loop.  The default value is four.
  .RE
  .RS 4
  .Sp
  The following choices of \fIname\fR are available on i386 and x86_64 targets:
! .IP \fBx86\-stlf\-window\-ninsns\fR 4
  .IX Item "x86-stlf-window-ninsns"
! Instructions number above which STFL stall penalty can be compensated.
! .IP \fBx86\-stv\-max\-visits\fR 4
  .IX Item "x86-stv-max-visits"
! The maximum number of use and def visits when discovering a STV chain before
  the discovery is aborted.
  .RE
  .RS 4
  .RE
  .SS "Program Instrumentation Options"
  .IX Subsection "Program Instrumentation Options"
! GCC supports a number of command\-line options that control adding
! run\-time instrumentation to the code it normally generates.  
  For example, one purpose of instrumentation is collect profiling
  statistics for use in finding program hot spots, code coverage
! analysis, or profile\-guided optimizations.
! Another class of program instrumentation is adding run\-time checking 
  to detect programming errors like invalid pointer
! dereferences or out\-of\-bounds array accesses, as well as deliberately
! hostile attacks such as stack smashing or C++ vtable hijacking.
  There is also a general hook which can be used to implement other
! forms of tracing or function\-level instrumentation for debug or
  program analysis purposes.
! .IP \fB\-p\fR 4
  .IX Item "-p"
  .PD 0
! .IP \fB\-pg\fR 4
  .IX Item "-pg"
  .PD
  Generate extra code to write profile information suitable for the
*************** linking.
*** 15374,15393 ****
  .Sp
  You can use the function attribute \f(CW\*(C`no_instrument_function\*(C'\fR to
  suppress profiling of individual functions when compiling with these options.
! .IP "\fB\-fprofile\-arcs\fR" 4
  .IX Item "-fprofile-arcs"
  Add code so that program flow \fIarcs\fR are instrumented.  During
  execution the program records how many times each branch and call is
  executed and how many times it is taken or returns.  On targets that support
  constructors with priority support, profiling properly handles constructors,
! destructors and \*(C+ constructors (and destructors) of classes which are used
  as a type of a global variable.
  .Sp
  When the compiled
  program exits it saves this data to a file called
! \&\fI\fIauxname\fI.gcda\fR for each source file.  The data may be used for
! profile-directed optimizations (\fB\-fbranch\-probabilities\fR), or for
! test coverage analysis (\fB\-ftest\-coverage\fR).  Each object file's
  \&\fIauxname\fR is generated from the name of the output file, if
  explicitly specified and it is not the final executable, otherwise it is
  the basename of the source file.  In both cases any suffix is removed
--- 15303,15322 ----
  .Sp
  You can use the function attribute \f(CW\*(C`no_instrument_function\*(C'\fR to
  suppress profiling of individual functions when compiling with these options.
! .IP \fB\-fprofile\-arcs\fR 4
  .IX Item "-fprofile-arcs"
  Add code so that program flow \fIarcs\fR are instrumented.  During
  execution the program records how many times each branch and call is
  executed and how many times it is taken or returns.  On targets that support
  constructors with priority support, profiling properly handles constructors,
! destructors and C++ constructors (and destructors) of classes which are used
  as a type of a global variable.
  .Sp
  When the compiled
  program exits it saves this data to a file called
! \&\fIauxname.gcda\fR for each source file.  The data may be used for
! profile\-directed optimizations (\fB\-fbranch\-probabilities\fR), or for
! test coverage analysis (\fB\-ftest\-coverage\fR).  Each object file\*(Aqs
  \&\fIauxname\fR is generated from the name of the output file, if
  explicitly specified and it is not the final executable, otherwise it is
  the basename of the source file.  In both cases any suffix is removed
*************** Note that if a command line directly lin
*** 15398,15446 ****
  \&\fI.gcda\fR files will be prefixed with the unsuffixed name of the output file.
  E.g. \f(CW\*(C`gcc a.c b.c \-o binary\*(C'\fR would generate \fIbinary\-a.gcda\fR and
  \&\fIbinary\-b.gcda\fR files.
! .IP "\fB\-\-coverage\fR" 4
  .IX Item "--coverage"
  This option is used to compile and link code instrumented for coverage
  analysis.  The option is a synonym for \fB\-fprofile\-arcs\fR
  \&\fB\-ftest\-coverage\fR (when compiling) and \fB\-lgcov\fR (when
  linking).  See the documentation for those options for more details.
  .RS 4
! .IP "*" 4
  Compile the source files with \fB\-fprofile\-arcs\fR plus optimization
  and code generation options.  For test coverage analysis, use the
  additional \fB\-ftest\-coverage\fR option.  You do not need to profile
  every source file in a program.
! .IP "*" 4
  Compile the source files additionally with \fB\-fprofile\-abs\-path\fR
  to create absolute path names in the \fI.gcno\fR files.  This allows
  \&\fBgcov\fR to find the correct sources in projects where compilations
  occur with different working directories.
! .IP "*" 4
  Link your object files with \fB\-lgcov\fR or \fB\-fprofile\-arcs\fR
  (the latter implies the former).
! .IP "*" 4
  Run the program on a representative workload to generate the arc profile
  information.  This may be repeated any number of times.  You can run
  concurrent instances of your program, and provided that the file system
  supports locking, the data files will be correctly updated.  Unless
! a strict \s-1ISO C\s0 dialect option is in effect, \f(CW\*(C`fork\*(C'\fR calls are
  detected and correctly handled without double counting.
  .Sp
  Moreover, an object file can be recompiled multiple times
  and the corresponding \fI.gcda\fR file merges as long as
  the source file and the compiler options are unchanged.
! .IP "*" 4
! For profile-directed optimizations, compile the source files again with
  the same optimization and code generation options plus
  \&\fB\-fbranch\-probabilities\fR.
! .IP "*" 4
  For test coverage analysis, use \fBgcov\fR to produce human readable
  information from the \fI.gcno\fR and \fI.gcda\fR files.  Refer to the
  \&\fBgcov\fR documentation for further information.
  .RE
  .RS 4
  .Sp
! With \fB\-fprofile\-arcs\fR, for each function of your program \s-1GCC\s0
  creates a program flow graph, then finds a spanning tree for the graph.
  Only arcs that are not on the spanning tree have to be instrumented: the
  compiler adds code to count the number of times that these arcs are
--- 15327,15375 ----
  \&\fI.gcda\fR files will be prefixed with the unsuffixed name of the output file.
  E.g. \f(CW\*(C`gcc a.c b.c \-o binary\*(C'\fR would generate \fIbinary\-a.gcda\fR and
  \&\fIbinary\-b.gcda\fR files.
! .IP \fB\-\-coverage\fR 4
  .IX Item "--coverage"
  This option is used to compile and link code instrumented for coverage
  analysis.  The option is a synonym for \fB\-fprofile\-arcs\fR
  \&\fB\-ftest\-coverage\fR (when compiling) and \fB\-lgcov\fR (when
  linking).  See the documentation for those options for more details.
  .RS 4
! .IP * 4
  Compile the source files with \fB\-fprofile\-arcs\fR plus optimization
  and code generation options.  For test coverage analysis, use the
  additional \fB\-ftest\-coverage\fR option.  You do not need to profile
  every source file in a program.
! .IP * 4
  Compile the source files additionally with \fB\-fprofile\-abs\-path\fR
  to create absolute path names in the \fI.gcno\fR files.  This allows
  \&\fBgcov\fR to find the correct sources in projects where compilations
  occur with different working directories.
! .IP * 4
  Link your object files with \fB\-lgcov\fR or \fB\-fprofile\-arcs\fR
  (the latter implies the former).
! .IP * 4
  Run the program on a representative workload to generate the arc profile
  information.  This may be repeated any number of times.  You can run
  concurrent instances of your program, and provided that the file system
  supports locking, the data files will be correctly updated.  Unless
! a strict ISO C dialect option is in effect, \f(CW\*(C`fork\*(C'\fR calls are
  detected and correctly handled without double counting.
  .Sp
  Moreover, an object file can be recompiled multiple times
  and the corresponding \fI.gcda\fR file merges as long as
  the source file and the compiler options are unchanged.
! .IP * 4
! For profile\-directed optimizations, compile the source files again with
  the same optimization and code generation options plus
  \&\fB\-fbranch\-probabilities\fR.
! .IP * 4
  For test coverage analysis, use \fBgcov\fR to produce human readable
  information from the \fI.gcno\fR and \fI.gcda\fR files.  Refer to the
  \&\fBgcov\fR documentation for further information.
  .RE
  .RS 4
  .Sp
! With \fB\-fprofile\-arcs\fR, for each function of your program 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
*** 15448,15499 ****
  instrumentation code can be added to the block; otherwise, a new basic
  block must be created to hold the instrumentation code.
  .RE
! .IP "\fB\-ftest\-coverage\fR" 4
  .IX Item "-ftest-coverage"
! Produce a notes file that the \fBgcov\fR code-coverage utility can use to
! show program coverage.  Each source file's note file is called
! \&\fI\fIauxname\fI.gcno\fR.  Refer to the \fB\-fprofile\-arcs\fR option
  above for a description of \fIauxname\fR and instructions on how to
  generate test coverage data.  Coverage data matches the source files
  more closely if you do not optimize.
! .IP "\fB\-fprofile\-abs\-path\fR" 4
  .IX Item "-fprofile-abs-path"
  Automatically convert relative source file names to absolute path names
  in the \fI.gcno\fR files.  This allows \fBgcov\fR to find the correct
  sources in projects where compilations occur with different working
  directories.
! .IP "\fB\-fprofile\-dir=\fR\fIpath\fR" 4
  .IX Item "-fprofile-dir=path"
  Set the directory to search for the profile data files in to \fIpath\fR.
  This option affects only the profile data generated by
  \&\fB\-fprofile\-generate\fR, \fB\-ftest\-coverage\fR, \fB\-fprofile\-arcs\fR
  and used by \fB\-fprofile\-use\fR and \fB\-fbranch\-probabilities\fR
  and its related options.  Both absolute and relative paths can be used.
! By default, \s-1GCC\s0 uses the current directory as \fIpath\fR, thus the
  profile data file appears in the same directory as the object file.
  In order to prevent the file name clashing, if the object file name is
  not an absolute path, we mangle the absolute path of the
! \&\fI\fIsourcename\fI.gcda\fR file and use it as the file name of a
  \&\fI.gcda\fR file.  See details about the file naming in \fB\-fprofile\-arcs\fR.
  See similar option \fB\-fprofile\-note\fR.
  .Sp
  When an executable is run in a massive parallel environment, it is recommended
  to save profile to different folders.  That can be done with variables
! in \fIpath\fR that are exported during run-time:
  .RS 4
! .IP "\fB\f(CB%p\fB\fR" 4
  .IX Item "%p"
! process \s-1ID.\s0
! .IP "\fB\f(CB%q\fB{\s-1VAR\s0}\fR" 4
  .IX Item "%q{VAR}"
! value of environment variable \fI\s-1VAR\s0\fR
  .RE
  .RS 4
  .RE
! .IP "\fB\-fprofile\-generate\fR" 4
  .IX Item "-fprofile-generate"
  .PD 0
! .IP "\fB\-fprofile\-generate=\fR\fIpath\fR" 4
  .IX Item "-fprofile-generate=path"
  .PD
  Enable options usually used for instrumenting application to produce
--- 15377,15430 ----
  instrumentation code can be added to the block; otherwise, a new basic
  block must be created to hold the instrumentation code.
  .RE
! .IP \fB\-ftest\-coverage\fR 4
  .IX Item "-ftest-coverage"
! Produce a notes file that the \fBgcov\fR code\-coverage utility can use to
! show program coverage.  Each source file\*(Aqs note file is called
! \&\fIauxname.gcno\fR.  Refer to the \fB\-fprofile\-arcs\fR option
  above for a description of \fIauxname\fR and instructions on how to
  generate test coverage data.  Coverage data matches the source files
  more closely if you do not optimize.
! .IP \fB\-fprofile\-abs\-path\fR 4
  .IX Item "-fprofile-abs-path"
  Automatically convert relative source file names to absolute path names
  in the \fI.gcno\fR files.  This allows \fBgcov\fR to find the correct
  sources in projects where compilations occur with different working
  directories.
! .IP \fB\-fprofile\-dir=\fR\fIpath\fR 4
  .IX Item "-fprofile-dir=path"
  Set the directory to search for the profile data files in to \fIpath\fR.
  This option affects only the profile data generated by
  \&\fB\-fprofile\-generate\fR, \fB\-ftest\-coverage\fR, \fB\-fprofile\-arcs\fR
  and used by \fB\-fprofile\-use\fR and \fB\-fbranch\-probabilities\fR
  and its related options.  Both absolute and relative paths can be used.
! By default, GCC uses the current directory as \fIpath\fR, thus the
  profile data file appears in the same directory as the object file.
  In order to prevent the file name clashing, if the object file name is
  not an absolute path, we mangle the absolute path of the
! \&\fIsourcename.gcda\fR file and use it as the file name of a
  \&\fI.gcda\fR file.  See details about the file naming in \fB\-fprofile\-arcs\fR.
  See similar option \fB\-fprofile\-note\fR.
  .Sp
  When an executable is run in a massive parallel environment, it is recommended
  to save profile to different folders.  That can be done with variables
! in \fIpath\fR that are exported during run\-time:
  .RS 4
! .ie n .IP \fR\fB%p\fR\fB\fR 4
! .el .IP \fR\f(CB%p\fR\fB\fR 4
  .IX Item "%p"
! process ID.
! .ie n .IP \fR\fB%q\fR\fB{VAR}\fR 4
! .el .IP \fR\f(CB%q\fR\fB{VAR}\fR 4
  .IX Item "%q{VAR}"
! value of environment variable \fIVAR\fR
  .RE
  .RS 4
  .RE
! .IP \fB\-fprofile\-generate\fR 4
  .IX Item "-fprofile-generate"
  .PD 0
! .IP \fB\-fprofile\-generate=\fR\fIpath\fR 4
  .IX Item "-fprofile-generate=path"
  .PD
  Enable options usually used for instrumenting application to produce
*************** The following options are enabled:
*** 15505,15519 ****
  \&\fB\-fprofile\-arcs\fR, \fB\-fprofile\-values\fR,
  \&\fB\-finline\-functions\fR, and \fB\-fipa\-bit\-cp\fR.
  .Sp
! If \fIpath\fR is specified, \s-1GCC\s0 looks at the \fIpath\fR to find
  the profile feedback data files. See \fB\-fprofile\-dir\fR.
  .Sp
  To optimize the program based on the collected profile information, use
  \&\fB\-fprofile\-use\fR.
! .IP "\fB\-fprofile\-info\-section\fR" 4
  .IX Item "-fprofile-info-section"
  .PD 0
! .IP "\fB\-fprofile\-info\-section=\fR\fIname\fR" 4
  .IX Item "-fprofile-info-section=name"
  .PD
  Register the profile information in the specified section instead of using a
--- 15436,15450 ----
  \&\fB\-fprofile\-arcs\fR, \fB\-fprofile\-values\fR,
  \&\fB\-finline\-functions\fR, and \fB\-fipa\-bit\-cp\fR.
  .Sp
! If \fIpath\fR is specified, GCC looks at the \fIpath\fR to find
  the profile feedback data files. See \fB\-fprofile\-dir\fR.
  .Sp
  To optimize the program based on the collected profile information, use
  \&\fB\-fprofile\-use\fR.
! .IP \fB\-fprofile\-info\-section\fR 4
  .IX Item "-fprofile-info-section"
  .PD 0
! .IP \fB\-fprofile\-info\-section=\fR\fIname\fR 4
  .IX Item "-fprofile-info-section=name"
  .PD
  Register the profile information in the specified section instead of using a
*************** environments (for example embedded syste
*** 15528,15534 ****
  support constructors/destructors or the C library file I/O.
  .Sp
  The linker could collect the input sections in a continuous memory block and
! define start and end symbols.  A \s-1GNU\s0 linker script example which defines a
  linker output section follows:
  .Sp
  .Vb 6
--- 15459,15465 ----
  support constructors/destructors or the C library file I/O.
  .Sp
  The linker could collect the input sections in a continuous memory block and
! define start and end symbols.  A GNU linker script example which defines a
  linker output section follows:
  .Sp
  .Vb 6
*************** for example like this:
*** 15598,15617 ****
  \&        }
  .Ve
  .Sp
! The \fBmerge-stream\fR subcommand of \fBgcov-tool\fR may be used to
  deserialize the data stream generated by the \f(CW\*(C`_\|_gcov_filename_to_gcfn\*(C'\fR and
  \&\f(CW\*(C`_\|_gcov_info_to_gcda\*(C'\fR functions and merge the profile information into
  \&\fI.gcda\fR files on the host filesystem.
! .IP "\fB\-fprofile\-note=\fR\fIpath\fR" 4
  .IX Item "-fprofile-note=path"
! If \fIpath\fR is specified, \s-1GCC\s0 saves \fI.gcno\fR file into \fIpath\fR
  location.  If you combine the option with multiple source files,
  the \fI.gcno\fR file will be overwritten.
! .IP "\fB\-fprofile\-prefix\-path=\fR\fIpath\fR" 4
  .IX Item "-fprofile-prefix-path=path"
  This option can be used in combination with
  \&\fBprofile\-generate=\fR\fIprofile_dir\fR and
! \&\fBprofile\-use=\fR\fIprofile_dir\fR to inform \s-1GCC\s0 where is the base
  directory of built source tree.  By default \fIprofile_dir\fR will contain
  files with mangled absolute paths of all object files in the built project.
  This is not desirable when directory used to build the instrumented binary
--- 15529,15548 ----
  \&        }
  .Ve
  .Sp
! The \fBmerge\-stream\fR subcommand of \fBgcov\-tool\fR may be used to
  deserialize the data stream generated by the \f(CW\*(C`_\|_gcov_filename_to_gcfn\*(C'\fR and
  \&\f(CW\*(C`_\|_gcov_info_to_gcda\*(C'\fR functions and merge the profile information into
  \&\fI.gcda\fR files on the host filesystem.
! .IP \fB\-fprofile\-note=\fR\fIpath\fR 4
  .IX Item "-fprofile-note=path"
! If \fIpath\fR is specified, GCC saves \fI.gcno\fR file into \fIpath\fR
  location.  If you combine the option with multiple source files,
  the \fI.gcno\fR file will be overwritten.
! .IP \fB\-fprofile\-prefix\-path=\fR\fIpath\fR 4
  .IX Item "-fprofile-prefix-path=path"
  This option can be used in combination with
  \&\fBprofile\-generate=\fR\fIprofile_dir\fR and
! \&\fBprofile\-use=\fR\fIprofile_dir\fR to inform GCC where is the base
  directory of built source tree.  By default \fIprofile_dir\fR will contain
  files with mangled absolute paths of all object files in the built project.
  This is not desirable when directory used to build the instrumented binary
*************** feedback because the profile data will n
*** 15620,15662 ****
  In such setups \fB\-fprofile\-prefix\-path=\fR\fIpath\fR with \fIpath\fR
  pointing to the base directory of the build can be used to strip the irrelevant
  part of the path and keep all file names relative to the main build directory.
! .IP "\fB\-fprofile\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
  .IX Item "-fprofile-prefix-map=old=new"
! When compiling files residing in directory \fI\fIold\fI\fR, record
  profiling information (with \fB\-\-coverage\fR)
  describing them as if the files resided in
! directory \fI\fInew\fI\fR instead.
  See also \fB\-ffile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP "\fB\-fprofile\-update=\fR\fImethod\fR" 4
  .IX Item "-fprofile-update=method"
  Alter the update method for an application instrumented for profile
  feedback based optimization.  The \fImethod\fR argument should be one of
! \&\fBsingle\fR, \fBatomic\fR or \fBprefer-atomic\fR.
! The first one is useful for single-threaded applications,
! while the second one prevents profile corruption by emitting thread-safe code.
  .Sp
  \&\fBWarning:\fR When an application does not properly join all threads
  (or creates an detached thread), a profile file can be still corrupted.
  .Sp
! Using \fBprefer-atomic\fR would be transformed either to \fBatomic\fR,
! when supported by a target, or to \fBsingle\fR otherwise.  The \s-1GCC\s0 driver
! automatically selects \fBprefer-atomic\fR when \fB\-pthread\fR
  is present in the command line.
! .IP "\fB\-fprofile\-filter\-files=\fR\fIregex\fR" 4
  .IX Item "-fprofile-filter-files=regex"
  Instrument only functions from files whose name matches
! any of the regular expressions (separated by semi-colons).
  .Sp
  For example, \fB\-fprofile\-filter\-files=main\e.c;module.*\e.c\fR will instrument
! only \fImain.c\fR and all C files starting with 'module'.
! .IP "\fB\-fprofile\-exclude\-files=\fR\fIregex\fR" 4
  .IX Item "-fprofile-exclude-files=regex"
  Instrument only functions from files whose name does not match
! any of the regular expressions (separated by semi-colons).
  .Sp
  For example, \fB\-fprofile\-exclude\-files=/usr/.*\fR will prevent instrumentation
  of all files that are located in the \fI/usr/\fR folder.
! .IP "\fB\-fprofile\-reproducible=\fR[\fBmultithreaded\fR|\fBparallel-runs\fR|\fBserial\fR]" 4
  .IX Item "-fprofile-reproducible=[multithreaded|parallel-runs|serial]"
  Control level of reproducibility of profile gathered by
  \&\f(CW\*(C`\-fprofile\-generate\*(C'\fR.  This makes it possible to rebuild program
--- 15551,15593 ----
  In such setups \fB\-fprofile\-prefix\-path=\fR\fIpath\fR with \fIpath\fR
  pointing to the base directory of the build can be used to strip the irrelevant
  part of the path and keep all file names relative to the main build directory.
! .IP \fB\-fprofile\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 4
  .IX Item "-fprofile-prefix-map=old=new"
! When compiling files residing in directory \fIold\fR, record
  profiling information (with \fB\-\-coverage\fR)
  describing them as if the files resided in
! directory \fInew\fR instead.
  See also \fB\-ffile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP \fB\-fprofile\-update=\fR\fImethod\fR 4
  .IX Item "-fprofile-update=method"
  Alter the update method for an application instrumented for profile
  feedback based optimization.  The \fImethod\fR argument should be one of
! \&\fBsingle\fR, \fBatomic\fR or \fBprefer\-atomic\fR.
! The first one is useful for single\-threaded applications,
! while the second one prevents profile corruption by emitting thread\-safe code.
  .Sp
  \&\fBWarning:\fR When an application does not properly join all threads
  (or creates an detached thread), a profile file can be still corrupted.
  .Sp
! Using \fBprefer\-atomic\fR would be transformed either to \fBatomic\fR,
! when supported by a target, or to \fBsingle\fR otherwise.  The GCC driver
! automatically selects \fBprefer\-atomic\fR when \fB\-pthread\fR
  is present in the command line.
! .IP \fB\-fprofile\-filter\-files=\fR\fIregex\fR 4
  .IX Item "-fprofile-filter-files=regex"
  Instrument only functions from files whose name matches
! any of the regular expressions (separated by semi\-colons).
  .Sp
  For example, \fB\-fprofile\-filter\-files=main\e.c;module.*\e.c\fR will instrument
! only \fImain.c\fR and all C files starting with \*(Aqmodule\*(Aq.
! .IP \fB\-fprofile\-exclude\-files=\fR\fIregex\fR 4
  .IX Item "-fprofile-exclude-files=regex"
  Instrument only functions from files whose name does not match
! any of the regular expressions (separated by semi\-colons).
  .Sp
  For example, \fB\-fprofile\-exclude\-files=/usr/.*\fR will prevent instrumentation
  of all files that are located in the \fI/usr/\fR folder.
! .IP \fB\-fprofile\-reproducible=\fR[\fBmultithreaded\fR|\fBparallel\-runs\fR|\fBserial\fR] 4
  .IX Item "-fprofile-reproducible=[multithreaded|parallel-runs|serial]"
  Control level of reproducibility of profile gathered by
  \&\f(CW\*(C`\-fprofile\-generate\*(C'\fR.  This makes it possible to rebuild program
*************** packages.
*** 15666,15680 ****
  With \fB\-fprofile\-reproducible=serial\fR the profile gathered by
  \&\fB\-fprofile\-generate\fR is reproducible provided the trained program
  behaves the same at each invocation of the train run, it is not
! multi-threaded and profile data streaming is always done in the same
  order.  Note that profile streaming happens at the end of program run but
  also before \f(CW\*(C`fork\*(C'\fR function is invoked.
  .Sp
  Note that it is quite common that execution counts of some part of
  programs depends, for example, on length of temporary file names or
! memory space randomization (that may affect hash-table collision rate).
! Such non-reproducible part of programs may be annotated by
! \&\f(CW\*(C`no_instrument_function\*(C'\fR function attribute. \fBgcov-dump\fR with
  \&\fB\-l\fR can be used to dump gathered data and verify that they are
  indeed reproducible.
  .Sp
--- 15597,15611 ----
  With \fB\-fprofile\-reproducible=serial\fR the profile gathered by
  \&\fB\-fprofile\-generate\fR is reproducible provided the trained program
  behaves the same at each invocation of the train run, it is not
! multi\-threaded and profile data streaming is always done in the same
  order.  Note that profile streaming happens at the end of program run but
  also before \f(CW\*(C`fork\*(C'\fR function is invoked.
  .Sp
  Note that it is quite common that execution counts of some part of
  programs depends, for example, on length of temporary file names or
! memory space randomization (that may affect hash\-table collision rate).
! Such non\-reproducible part of programs may be annotated by
! \&\f(CW\*(C`no_instrument_function\*(C'\fR function attribute. \fBgcov\-dump\fR with
  \&\fB\-l\fR can be used to dump gathered data and verify that they are
  indeed reproducible.
  .Sp
*************** gcda files.  This setting makes it possi
*** 15684,15698 ****
  instrumented program in parallel (such as with \f(CW\*(C`make \-j\*(C'\fR). This
  reduces quality of gathered data, in particular of indirect call
  profiling.
! .IP "\fB\-fsanitize=address\fR" 4
  .IX Item "-fsanitize=address"
  Enable AddressSanitizer, a fast memory error detector.
  Memory access instructions are instrumented to detect
! out-of-bounds and use-after-free bugs.
  The option enables \fB\-fsanitize\-address\-use\-after\-scope\fR.
  See <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizer\fR> for
! more details.  The run-time behavior can be influenced using the
! \&\fB\s-1ASAN_OPTIONS\s0\fR environment variable.  When set to \f(CW\*(C`help=1\*(C'\fR,
  the available options are shown at startup of the instrumented program.  See
  <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run\-time\-flags\fR>
  for a list of supported options.
--- 15615,15629 ----
  instrumented program in parallel (such as with \f(CW\*(C`make \-j\*(C'\fR). This
  reduces quality of gathered data, in particular of indirect call
  profiling.
! .IP \fB\-fsanitize=address\fR 4
  .IX Item "-fsanitize=address"
  Enable AddressSanitizer, a fast memory error detector.
  Memory access instructions are instrumented to detect
! out\-of\-bounds and use\-after\-free bugs.
  The option enables \fB\-fsanitize\-address\-use\-after\-scope\fR.
  See <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizer\fR> for
! more details.  The run\-time behavior can be influenced using the
! \&\fBASAN_OPTIONS\fR environment variable.  When set to \f(CW\*(C`help=1\*(C'\fR,
  the available options are shown at startup of the instrumented program.  See
  <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizerFlags#run\-time\-flags\fR>
  for a list of supported options.
*************** most function inlining), \fB\-fno\-optim
*** 15708,15738 ****
  optimizing sibling and tail recursive calls; this option is implicit for
  \&\fB\-O0\fR, \fB\-O1\fR, or \fB\-Og\fR), or \fB\-fno\-ipa\-icf\fR (which
  disables Identical Code Folding for functions).  Since multiple runs of the
! program may yield backtraces with different addresses due to \s-1ASLR\s0 (Address
! Space Layout Randomization), it may be desirable to turn \s-1ASLR\s0 off.  On Linux,
! this can be achieved with \fBsetarch `uname \-m` \-R ./prog\fR.
! .IP "\fB\-fsanitize=kernel\-address\fR" 4
  .IX Item "-fsanitize=kernel-address"
  Enable AddressSanitizer for Linux kernel.
  See <\fBhttps://github.com/google/kernel\-sanitizers\fR> for more details.
! .IP "\fB\-fsanitize=hwaddress\fR" 4
  .IX Item "-fsanitize=hwaddress"
! Enable Hardware-assisted AddressSanitizer, which uses a hardware ability to
  ignore the top byte of a pointer to allow the detection of memory errors with
  a low memory overhead.
! Memory access instructions are instrumented to detect out-of-bounds and
! use-after-free bugs.
  The option enables \fB\-fsanitize\-address\-use\-after\-scope\fR.
  See
  <\fBhttps://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html\fR>
! for more details.  The run-time behavior can be influenced using the
! \&\fB\s-1HWASAN_OPTIONS\s0\fR environment variable.  When set to \f(CW\*(C`help=1\*(C'\fR,
  the available options are shown at startup of the instrumented program.
  The option cannot be combined with \fB\-fsanitize=thread\fR or
  \&\fB\-fsanitize=address\fR, and is currently only available on AArch64.
! .IP "\fB\-fsanitize=kernel\-hwaddress\fR" 4
  .IX Item "-fsanitize=kernel-hwaddress"
! Enable Hardware-assisted AddressSanitizer for compilation of the Linux kernel.
  Similar to \fB\-fsanitize=kernel\-address\fR but using an alternate
  instrumentation method, and similar to \fB\-fsanitize=hwaddress\fR but with
  instrumentation differences necessary for compiling the Linux kernel.
--- 15639,15669 ----
  optimizing sibling and tail recursive calls; this option is implicit for
  \&\fB\-O0\fR, \fB\-O1\fR, or \fB\-Og\fR), or \fB\-fno\-ipa\-icf\fR (which
  disables Identical Code Folding for functions).  Since multiple runs of the
! program may yield backtraces with different addresses due to ASLR (Address
! Space Layout Randomization), it may be desirable to turn ASLR off.  On Linux,
! this can be achieved with \fBsetarch \`uname \-m\` \-R ./prog\fR.
! .IP \fB\-fsanitize=kernel\-address\fR 4
  .IX Item "-fsanitize=kernel-address"
  Enable AddressSanitizer for Linux kernel.
  See <\fBhttps://github.com/google/kernel\-sanitizers\fR> for more details.
! .IP \fB\-fsanitize=hwaddress\fR 4
  .IX Item "-fsanitize=hwaddress"
! Enable Hardware\-assisted AddressSanitizer, which uses a hardware ability to
  ignore the top byte of a pointer to allow the detection of memory errors with
  a low memory overhead.
! Memory access instructions are instrumented to detect out\-of\-bounds and
! use\-after\-free bugs.
  The option enables \fB\-fsanitize\-address\-use\-after\-scope\fR.
  See
  <\fBhttps://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html\fR>
! for more details.  The run\-time behavior can be influenced using the
! \&\fBHWASAN_OPTIONS\fR environment variable.  When set to \f(CW\*(C`help=1\*(C'\fR,
  the available options are shown at startup of the instrumented program.
  The option cannot be combined with \fB\-fsanitize=thread\fR or
  \&\fB\-fsanitize=address\fR, and is currently only available on AArch64.
! .IP \fB\-fsanitize=kernel\-hwaddress\fR 4
  .IX Item "-fsanitize=kernel-hwaddress"
! Enable Hardware\-assisted AddressSanitizer for compilation of the Linux kernel.
  Similar to \fB\-fsanitize=kernel\-address\fR but using an alternate
  instrumentation method, and similar to \fB\-fsanitize=hwaddress\fR but with
  instrumentation differences necessary for compiling the Linux kernel.
*************** account for the stack pointer having a d
*** 15741,15751 ****
  .Sp
  \&\fINote:\fR This option has different defaults to the \fB\-fsanitize=hwaddress\fR.
  Instrumenting the stack and alloca calls are not on by default but are still
! possible by specifying the command-line options
  \&\fB\-\-param hwasan\-instrument\-stack=1\fR and
  \&\fB\-\-param hwasan\-instrument\-allocas=1\fR respectively. Using a random frame
  tag is not implemented for kernel instrumentation.
! .IP "\fB\-fsanitize=pointer\-compare\fR" 4
  .IX Item "-fsanitize=pointer-compare"
  Instrument comparison operation (<, <=, >, >=) with pointer operands.
  The option must be combined with either \fB\-fsanitize=kernel\-address\fR or
--- 15672,15682 ----
  .Sp
  \&\fINote:\fR This option has different defaults to the \fB\-fsanitize=hwaddress\fR.
  Instrumenting the stack and alloca calls are not on by default but are still
! possible by specifying the command\-line options
  \&\fB\-\-param hwasan\-instrument\-stack=1\fR and
  \&\fB\-\-param hwasan\-instrument\-allocas=1\fR respectively. Using a random frame
  tag is not implemented for kernel instrumentation.
! .IP \fB\-fsanitize=pointer\-compare\fR 4
  .IX Item "-fsanitize=pointer-compare"
  Instrument comparison operation (<, <=, >, >=) with pointer operands.
  The option must be combined with either \fB\-fsanitize=kernel\-address\fR or
*************** The option must be combined with either
*** 15753,15761 ****
  The option cannot be combined with \fB\-fsanitize=thread\fR.
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_invalid_pointer_pairs=2\*(C'\fR to the environment variable
! \&\fB\s-1ASAN_OPTIONS\s0\fR. Using \f(CW\*(C`detect_invalid_pointer_pairs=1\*(C'\fR detects
! invalid operation only when both pointers are non-null.
! .IP "\fB\-fsanitize=pointer\-subtract\fR" 4
  .IX Item "-fsanitize=pointer-subtract"
  Instrument subtraction with pointer operands.
  The option must be combined with either \fB\-fsanitize=kernel\-address\fR or
--- 15684,15692 ----
  The option cannot be combined with \fB\-fsanitize=thread\fR.
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_invalid_pointer_pairs=2\*(C'\fR to the environment variable
! \&\fBASAN_OPTIONS\fR. Using \f(CW\*(C`detect_invalid_pointer_pairs=1\*(C'\fR detects
! invalid operation only when both pointers are non\-null.
! .IP \fB\-fsanitize=pointer\-subtract\fR 4
  .IX Item "-fsanitize=pointer-subtract"
  Instrument subtraction with pointer operands.
  The option must be combined with either \fB\-fsanitize=kernel\-address\fR or
*************** The option must be combined with either
*** 15763,15785 ****
  The option cannot be combined with \fB\-fsanitize=thread\fR.
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_invalid_pointer_pairs=2\*(C'\fR to the environment variable
! \&\fB\s-1ASAN_OPTIONS\s0\fR. Using \f(CW\*(C`detect_invalid_pointer_pairs=1\*(C'\fR detects
! invalid operation only when both pointers are non-null.
! .IP "\fB\-fsanitize=shadow\-call\-stack\fR" 4
  .IX Item "-fsanitize=shadow-call-stack"
  Enable ShadowCallStack, a security enhancement mechanism used to protect
  programs against return address overwrites (e.g. stack buffer overflows.)
! It works by saving a function's return address to a separately allocated
  shadow call stack in the function prologue and restoring the return address
  from the shadow call stack in the function epilogue.  Instrumentation only
  occurs in functions that need to save the return address to the stack.
  .Sp
  Currently it only supports the aarch64 platform.  It is specifically
! designed for linux kernels that enable the \s-1CONFIG_SHADOW_CALL_STACK\s0 option.
  For the user space programs, runtime support is not currently provided
  in libc and libgcc.  Users who want to use this feature in user space need
  to provide their own support for the runtime.  It should be noted that
! this may cause the \s-1ABI\s0 rules to be broken.
  .Sp
  On aarch64, the instrumentation makes use of the platform register \f(CW\*(C`x18\*(C'\fR.
  This generally means that any code that may run on the same thread as code
--- 15694,15716 ----
  The option cannot be combined with \fB\-fsanitize=thread\fR.
  Note: By default the check is disabled at run time.  To enable it,
  add \f(CW\*(C`detect_invalid_pointer_pairs=2\*(C'\fR to the environment variable
! \&\fBASAN_OPTIONS\fR. Using \f(CW\*(C`detect_invalid_pointer_pairs=1\*(C'\fR detects
! invalid operation only when both pointers are non\-null.
! .IP \fB\-fsanitize=shadow\-call\-stack\fR 4
  .IX Item "-fsanitize=shadow-call-stack"
  Enable ShadowCallStack, a security enhancement mechanism used to protect
  programs against return address overwrites (e.g. stack buffer overflows.)
! It works by saving a function\*(Aqs return address to a separately allocated
  shadow call stack in the function prologue and restoring the return address
  from the shadow call stack in the function epilogue.  Instrumentation only
  occurs in functions that need to save the return address to the stack.
  .Sp
  Currently it only supports the aarch64 platform.  It is specifically
! designed for linux kernels that enable the CONFIG_SHADOW_CALL_STACK option.
  For the user space programs, runtime support is not currently provided
  in libc and libgcc.  Users who want to use this feature in user space need
  to provide their own support for the runtime.  It should be noted that
! this may cause the ABI rules to be broken.
  .Sp
  On aarch64, the instrumentation makes use of the platform register \f(CW\*(C`x18\*(C'\fR.
  This generally means that any code that may run on the same thread as code
*************** to turn off exceptions.
*** 15794,15805 ****
  .Sp
  See <\fBhttps://clang.llvm.org/docs/ShadowCallStack.html\fR> for more
  details.
! .IP "\fB\-fsanitize=thread\fR" 4
  .IX Item "-fsanitize=thread"
  Enable ThreadSanitizer, a fast data race detector.
  Memory access instructions are instrumented to detect
  data race bugs.  See <\fBhttps://github.com/google/sanitizers/wiki#threadsanitizer\fR> for more
! details. The run-time behavior can be influenced using the \fB\s-1TSAN_OPTIONS\s0\fR
  environment variable; see
  <\fBhttps://github.com/google/sanitizers/wiki/ThreadSanitizerFlags\fR> for a list of
  supported options.
--- 15725,15736 ----
  .Sp
  See <\fBhttps://clang.llvm.org/docs/ShadowCallStack.html\fR> for more
  details.
! .IP \fB\-fsanitize=thread\fR 4
  .IX Item "-fsanitize=thread"
  Enable ThreadSanitizer, a fast data race detector.
  Memory access instructions are instrumented to detect
  data race bugs.  See <\fBhttps://github.com/google/sanitizers/wiki#threadsanitizer\fR> for more
! details. The run\-time behavior can be influenced using the \fBTSAN_OPTIONS\fR
  environment variable; see
  <\fBhttps://github.com/google/sanitizers/wiki/ThreadSanitizerFlags\fR> for a list of
  supported options.
*************** The option cannot be combined with \fB\-
*** 15807,15875 ****
  \&\fB\-fsanitize=leak\fR.
  .Sp
  Note that sanitized atomic builtins cannot throw exceptions when
! operating on invalid memory addresses with non-call exceptions
  (\fB\-fnon\-call\-exceptions\fR).
! .IP "\fB\-fsanitize=leak\fR" 4
  .IX Item "-fsanitize=leak"
  Enable LeakSanitizer, a memory leak detector.
  This option only matters for linking of executables.
  The executable is linked against a library that overrides \f(CW\*(C`malloc\*(C'\fR
  and other allocator functions.  See
  <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer\fR> for more
! details.  The run-time behavior can be influenced using the
! \&\fB\s-1LSAN_OPTIONS\s0\fR environment variable.
  The option cannot be combined with \fB\-fsanitize=thread\fR.
! .IP "\fB\-fsanitize=undefined\fR" 4
  .IX Item "-fsanitize=undefined"
  Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector.
  Various computations are instrumented to detect undefined behavior
! at runtime.  See <\fBhttps://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html\fR> for more details.   The run-time behavior can be influenced using the
! \&\fB\s-1UBSAN_OPTIONS\s0\fR environment variable.  Current suboptions are:
  .RS 4
! .IP "\fB\-fsanitize=shift\fR" 4
  .IX Item "-fsanitize=shift"
  This option enables checking that the result of a shift operation is
  not undefined.  Note that what exactly is considered undefined differs
! slightly between C and \*(C+, as well as between \s-1ISO C90\s0 and C99, etc.
  This option has two suboptions, \fB\-fsanitize=shift\-base\fR and
  \&\fB\-fsanitize=shift\-exponent\fR.
! .IP "\fB\-fsanitize=shift\-exponent\fR" 4
  .IX Item "-fsanitize=shift-exponent"
  This option enables checking that the second argument of a shift operation
  is not negative and is smaller than the precision of the promoted first
  argument.
! .IP "\fB\-fsanitize=shift\-base\fR" 4
  .IX Item "-fsanitize=shift-base"
  If the second argument of a shift operation is within range, check that the
  result of a shift operation is not undefined.  Note that what exactly is
! considered undefined differs slightly between C and \*(C+, as well as between
! \&\s-1ISO C90\s0 and C99, etc.
! .IP "\fB\-fsanitize=integer\-divide\-by\-zero\fR" 4
  .IX Item "-fsanitize=integer-divide-by-zero"
  Detect integer division by zero.
! .IP "\fB\-fsanitize=unreachable\fR" 4
  .IX Item "-fsanitize=unreachable"
  With this option, the compiler turns the \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR
  call into a diagnostics message call instead.  When reaching the
  \&\f(CW\*(C`_\|_builtin_unreachable\*(C'\fR call, the behavior is undefined.
! .IP "\fB\-fsanitize=vla\-bound\fR" 4
  .IX Item "-fsanitize=vla-bound"
  This option instructs the compiler to check that the size of a variable
  length array is positive.
! .IP "\fB\-fsanitize=null\fR" 4
  .IX Item "-fsanitize=null"
  This option enables pointer checking.  Particularly, the application
  built with this option turned on will issue an error message when it
! tries to dereference a \s-1NULL\s0 pointer, or if a reference (possibly an
! rvalue reference) is bound to a \s-1NULL\s0 pointer, or if a method is invoked
! on an object pointed by a \s-1NULL\s0 pointer.
! .IP "\fB\-fsanitize=return\fR" 4
  .IX Item "-fsanitize=return"
  This option enables return statement checking.  Programs
  built with this option turned on will issue an error message
! when the end of a non-void function is reached without actually
! returning a value.  This option works in \*(C+ only.
! .IP "\fB\-fsanitize=signed\-integer\-overflow\fR" 4
  .IX Item "-fsanitize=signed-integer-overflow"
  This option enables signed integer overflow checking.  We check that
  the result of \f(CW\*(C`+\*(C'\fR, \f(CW\*(C`*\*(C'\fR, and both unary and binary \f(CW\*(C`\-\*(C'\fR
--- 15738,15806 ----
  \&\fB\-fsanitize=leak\fR.
  .Sp
  Note that sanitized atomic builtins cannot throw exceptions when
! operating on invalid memory addresses with non\-call exceptions
  (\fB\-fnon\-call\-exceptions\fR).
! .IP \fB\-fsanitize=leak\fR 4
  .IX Item "-fsanitize=leak"
  Enable LeakSanitizer, a memory leak detector.
  This option only matters for linking of executables.
  The executable is linked against a library that overrides \f(CW\*(C`malloc\*(C'\fR
  and other allocator functions.  See
  <\fBhttps://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer\fR> for more
! details.  The run\-time behavior can be influenced using the
! \&\fBLSAN_OPTIONS\fR environment variable.
  The option cannot be combined with \fB\-fsanitize=thread\fR.
! .IP \fB\-fsanitize=undefined\fR 4
  .IX Item "-fsanitize=undefined"
  Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector.
  Various computations are instrumented to detect undefined behavior
! at runtime.  See <\fBhttps://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html\fR> for more details.   The run\-time behavior can be influenced using the
! \&\fBUBSAN_OPTIONS\fR environment variable.  Current suboptions are:
  .RS 4
! .IP \fB\-fsanitize=shift\fR 4
  .IX Item "-fsanitize=shift"
  This option enables checking that the result of a shift operation is
  not undefined.  Note that what exactly is considered undefined differs
! slightly between C and C++, as well as between ISO C90 and C99, etc.
  This option has two suboptions, \fB\-fsanitize=shift\-base\fR and
  \&\fB\-fsanitize=shift\-exponent\fR.
! .IP \fB\-fsanitize=shift\-exponent\fR 4
  .IX Item "-fsanitize=shift-exponent"
  This option enables checking that the second argument of a shift operation
  is not negative and is smaller than the precision of the promoted first
  argument.
! .IP \fB\-fsanitize=shift\-base\fR 4
  .IX Item "-fsanitize=shift-base"
  If the second argument of a shift operation is within range, check that the
  result of a shift operation is not undefined.  Note that what exactly is
! considered undefined differs slightly between C and C++, as well as between
! ISO C90 and C99, etc.
! .IP \fB\-fsanitize=integer\-divide\-by\-zero\fR 4
  .IX Item "-fsanitize=integer-divide-by-zero"
  Detect integer division by zero.
! .IP \fB\-fsanitize=unreachable\fR 4
  .IX Item "-fsanitize=unreachable"
  With this option, the compiler turns the \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR
  call into a diagnostics message call instead.  When reaching the
  \&\f(CW\*(C`_\|_builtin_unreachable\*(C'\fR call, the behavior is undefined.
! .IP \fB\-fsanitize=vla\-bound\fR 4
  .IX Item "-fsanitize=vla-bound"
  This option instructs the compiler to check that the size of a variable
  length array is positive.
! .IP \fB\-fsanitize=null\fR 4
  .IX Item "-fsanitize=null"
  This option enables pointer checking.  Particularly, the application
  built with this option turned on will issue an error message when it
! tries to dereference a NULL pointer, or if a reference (possibly an
! rvalue reference) is bound to a NULL pointer, or if a method is invoked
! on an object pointed by a NULL pointer.
! .IP \fB\-fsanitize=return\fR 4
  .IX Item "-fsanitize=return"
  This option enables return statement checking.  Programs
  built with this option turned on will issue an error message
! when the end of a non\-void function is reached without actually
! returning a value.  This option works in C++ only.
! .IP \fB\-fsanitize=signed\-integer\-overflow\fR 4
  .IX Item "-fsanitize=signed-integer-overflow"
  This option enables signed integer overflow checking.  We check that
  the result of \f(CW\*(C`+\*(C'\fR, \f(CW\*(C`*\*(C'\fR, and both unary and binary \f(CW\*(C`\-\*(C'\fR
*************** overflow:
*** 15882,15956 ****
  \&        signed char a = SCHAR_MAX;
  \&        a++;
  .Ve
! .IP "\fB\-fsanitize=bounds\fR" 4
  .IX Item "-fsanitize=bounds"
  This option enables instrumentation of array bounds.  Various out of bounds
! accesses are detected.  Flexible array members, flexible array member-like
  arrays, and initializers of variables with static storage are not
! instrumented, with the exception of flexible array member-like arrays
  for which \f(CW\*(C`\-fstrict\-flex\-arrays\*(C'\fR or \f(CW\*(C`\-fstrict\-flex\-arrays=\*(C'\fR
! options or \f(CW\*(C`strict_flex_array\*(C'\fR attributes say they shouldn't be treated
! like flexible array member-like arrays.
! .IP "\fB\-fsanitize=bounds\-strict\fR" 4
  .IX Item "-fsanitize=bounds-strict"
  This option enables strict instrumentation of array bounds.  Most out of bounds
! accesses are detected, including flexible array member-like arrays.
  Initializers of variables with static storage are not instrumented.
! .IP "\fB\-fsanitize=alignment\fR" 4
  .IX Item "-fsanitize=alignment"
  This option enables checking of alignment of pointers when they are
  dereferenced, or when a reference is bound to insufficiently aligned target,
  or when a method or constructor is invoked on insufficiently aligned object.
! .IP "\fB\-fsanitize=object\-size\fR" 4
  .IX Item "-fsanitize=object-size"
  This option enables instrumentation of memory references using the
  \&\f(CW\*(C`_\|_builtin_dynamic_object_size\*(C'\fR function.  Various out of bounds
  pointer accesses are detected.
! .IP "\fB\-fsanitize=float\-divide\-by\-zero\fR" 4
  .IX Item "-fsanitize=float-divide-by-zero"
! Detect floating-point division by zero.  Unlike other similar options,
  \&\fB\-fsanitize=float\-divide\-by\-zero\fR is not enabled by
! \&\fB\-fsanitize=undefined\fR, since floating-point division by zero can
  be a legitimate way of obtaining infinities and NaNs.
! .IP "\fB\-fsanitize=float\-cast\-overflow\fR" 4
  .IX Item "-fsanitize=float-cast-overflow"
! This option enables floating-point type to integer conversion checking.
  We check that the result of the conversion does not overflow.
  Unlike other similar options, \fB\-fsanitize=float\-cast\-overflow\fR is
  not enabled by \fB\-fsanitize=undefined\fR.
  This option does not work well with \f(CW\*(C`FE_INVALID\*(C'\fR exceptions enabled.
! .IP "\fB\-fsanitize=nonnull\-attribute\fR" 4
  .IX Item "-fsanitize=nonnull-attribute"
  This option enables instrumentation of calls, checking whether null values
! are not passed to arguments marked as requiring a non-null value by the
  \&\f(CW\*(C`nonnull\*(C'\fR function attribute.
! .IP "\fB\-fsanitize=returns\-nonnull\-attribute\fR" 4
  .IX Item "-fsanitize=returns-nonnull-attribute"
  This option enables instrumentation of return statements in functions
  marked with \f(CW\*(C`returns_nonnull\*(C'\fR function attribute, to detect returning
  of null values from such functions.
! .IP "\fB\-fsanitize=bool\fR" 4
  .IX Item "-fsanitize=bool"
  This option enables instrumentation of loads from bool.  If a value other
! than 0/1 is loaded, a run-time error is issued.
! .IP "\fB\-fsanitize=enum\fR" 4
  .IX Item "-fsanitize=enum"
  This option enables instrumentation of loads from an enum type.  If
  a value outside the range of values for the enum type is loaded,
! a run-time error is issued.
! .IP "\fB\-fsanitize=vptr\fR" 4
  .IX Item "-fsanitize=vptr"
! This option enables instrumentation of \*(C+ member function calls, member
  accesses and some conversions between pointers to base and derived classes,
  to verify the referenced object has the correct dynamic type.
! .IP "\fB\-fsanitize=pointer\-overflow\fR" 4
  .IX Item "-fsanitize=pointer-overflow"
  This option enables instrumentation of pointer arithmetics.  If the pointer
! arithmetics overflows, a run-time error is issued.
! .IP "\fB\-fsanitize=builtin\fR" 4
  .IX Item "-fsanitize=builtin"
  This option enables instrumentation of arguments to selected builtin
! functions.  If an invalid value is passed to such arguments, a run-time
  error is issued.  E.g. passing 0 as the argument to \f(CW\*(C`_\|_builtin_ctz\*(C'\fR
  or \f(CW\*(C`_\|_builtin_clz\*(C'\fR invokes undefined behavior and is diagnosed
  by this option.
--- 15813,15887 ----
  \&        signed char a = SCHAR_MAX;
  \&        a++;
  .Ve
! .IP \fB\-fsanitize=bounds\fR 4
  .IX Item "-fsanitize=bounds"
  This option enables instrumentation of array bounds.  Various out of bounds
! accesses are detected.  Flexible array members, flexible array member\-like
  arrays, and initializers of variables with static storage are not
! instrumented, with the exception of flexible array member\-like arrays
  for which \f(CW\*(C`\-fstrict\-flex\-arrays\*(C'\fR or \f(CW\*(C`\-fstrict\-flex\-arrays=\*(C'\fR
! options or \f(CW\*(C`strict_flex_array\*(C'\fR attributes say they shouldn\*(Aqt be treated
! like flexible array member\-like arrays.
! .IP \fB\-fsanitize=bounds\-strict\fR 4
  .IX Item "-fsanitize=bounds-strict"
  This option enables strict instrumentation of array bounds.  Most out of bounds
! accesses are detected, including flexible array member\-like arrays.
  Initializers of variables with static storage are not instrumented.
! .IP \fB\-fsanitize=alignment\fR 4
  .IX Item "-fsanitize=alignment"
  This option enables checking of alignment of pointers when they are
  dereferenced, or when a reference is bound to insufficiently aligned target,
  or when a method or constructor is invoked on insufficiently aligned object.
! .IP \fB\-fsanitize=object\-size\fR 4
  .IX Item "-fsanitize=object-size"
  This option enables instrumentation of memory references using the
  \&\f(CW\*(C`_\|_builtin_dynamic_object_size\*(C'\fR function.  Various out of bounds
  pointer accesses are detected.
! .IP \fB\-fsanitize=float\-divide\-by\-zero\fR 4
  .IX Item "-fsanitize=float-divide-by-zero"
! Detect floating\-point division by zero.  Unlike other similar options,
  \&\fB\-fsanitize=float\-divide\-by\-zero\fR is not enabled by
! \&\fB\-fsanitize=undefined\fR, since floating\-point division by zero can
  be a legitimate way of obtaining infinities and NaNs.
! .IP \fB\-fsanitize=float\-cast\-overflow\fR 4
  .IX Item "-fsanitize=float-cast-overflow"
! This option enables floating\-point type to integer conversion checking.
  We check that the result of the conversion does not overflow.
  Unlike other similar options, \fB\-fsanitize=float\-cast\-overflow\fR is
  not enabled by \fB\-fsanitize=undefined\fR.
  This option does not work well with \f(CW\*(C`FE_INVALID\*(C'\fR exceptions enabled.
! .IP \fB\-fsanitize=nonnull\-attribute\fR 4
  .IX Item "-fsanitize=nonnull-attribute"
  This option enables instrumentation of calls, checking whether null values
! are not passed to arguments marked as requiring a non\-null value by the
  \&\f(CW\*(C`nonnull\*(C'\fR function attribute.
! .IP \fB\-fsanitize=returns\-nonnull\-attribute\fR 4
  .IX Item "-fsanitize=returns-nonnull-attribute"
  This option enables instrumentation of return statements in functions
  marked with \f(CW\*(C`returns_nonnull\*(C'\fR function attribute, to detect returning
  of null values from such functions.
! .IP \fB\-fsanitize=bool\fR 4
  .IX Item "-fsanitize=bool"
  This option enables instrumentation of loads from bool.  If a value other
! than 0/1 is loaded, a run\-time error is issued.
! .IP \fB\-fsanitize=enum\fR 4
  .IX Item "-fsanitize=enum"
  This option enables instrumentation of loads from an enum type.  If
  a value outside the range of values for the enum type is loaded,
! a run\-time error is issued.
! .IP \fB\-fsanitize=vptr\fR 4
  .IX Item "-fsanitize=vptr"
! This option enables instrumentation of C++ member function calls, member
  accesses and some conversions between pointers to base and derived classes,
  to verify the referenced object has the correct dynamic type.
! .IP \fB\-fsanitize=pointer\-overflow\fR 4
  .IX Item "-fsanitize=pointer-overflow"
  This option enables instrumentation of pointer arithmetics.  If the pointer
! arithmetics overflows, a run\-time error is issued.
! .IP \fB\-fsanitize=builtin\fR 4
  .IX Item "-fsanitize=builtin"
  This option enables instrumentation of arguments to selected builtin
! functions.  If an invalid value is passed to such arguments, a run\-time
  error is issued.  E.g. passing 0 as the argument to \f(CW\*(C`_\|_builtin_ctz\*(C'\fR
  or \f(CW\*(C`_\|_builtin_clz\*(C'\fR invokes undefined behavior and is diagnosed
  by this option.
*************** While \fB\-ftrapv\fR causes traps for si
*** 15966,15989 ****
  \&\fB\-fsanitize=undefined\fR gives a diagnostic message.
  This currently works only for the C family of languages.
  .RE
! .IP "\fB\-fno\-sanitize=all\fR" 4
  .IX Item "-fno-sanitize=all"
  This option disables all previously enabled sanitizers.
  \&\fB\-fsanitize=all\fR is not allowed, as some sanitizers cannot be used
  together.
! .IP "\fB\-fasan\-shadow\-offset=\fR\fInumber\fR" 4
  .IX Item "-fasan-shadow-offset=number"
! This option forces \s-1GCC\s0 to use custom shadow offset in AddressSanitizer checks.
  It is useful for experimenting with different shadow memory layouts in
  Kernel AddressSanitizer.
! .IP "\fB\-fsanitize\-sections=\fR\fIs1\fR\fB,\fR\fIs2\fR\fB,...\fR" 4
  .IX Item "-fsanitize-sections=s1,s2,..."
! Sanitize global variables in selected user-defined sections.  \fIsi\fR may
  contain wildcards.
! .IP "\fB\-fsanitize\-recover\fR[\fB=\fR\fIopts\fR]" 4
  .IX Item "-fsanitize-recover[=opts]"
  \&\fB\-fsanitize\-recover=\fR controls error recovery mode for sanitizers
! mentioned in comma-separated list of \fIopts\fR.  Enabling this option
  for a sanitizer component causes it to attempt to continue
  running the program as if no error happened.  This means multiple
  runtime errors can be reported in a single program run, and the exit
--- 15897,15920 ----
  \&\fB\-fsanitize=undefined\fR gives a diagnostic message.
  This currently works only for the C family of languages.
  .RE
! .IP \fB\-fno\-sanitize=all\fR 4
  .IX Item "-fno-sanitize=all"
  This option disables all previously enabled sanitizers.
  \&\fB\-fsanitize=all\fR is not allowed, as some sanitizers cannot be used
  together.
! .IP \fB\-fasan\-shadow\-offset=\fR\fInumber\fR 4
  .IX Item "-fasan-shadow-offset=number"
! This option forces GCC to use custom shadow offset in AddressSanitizer checks.
  It is useful for experimenting with different shadow memory layouts in
  Kernel AddressSanitizer.
! .IP \fB\-fsanitize\-sections=\fR\fIs1\fR\fB,\fR\fIs2\fR\fB,...\fR 4
  .IX Item "-fsanitize-sections=s1,s2,..."
! Sanitize global variables in selected user\-defined sections.  \fIsi\fR may
  contain wildcards.
! .IP \fB\-fsanitize\-recover\fR[\fB=\fR\fIopts\fR] 4
  .IX Item "-fsanitize-recover[=opts]"
  \&\fB\-fsanitize\-recover=\fR controls error recovery mode for sanitizers
! mentioned in comma\-separated list of \fIopts\fR.  Enabling this option
  for a sanitizer component causes it to attempt to continue
  running the program as if no error happened.  This means multiple
  runtime errors can be reported in a single program run, and the exit
*************** code of the program may indicate success
*** 15991,15997 ****
  have been reported.  The \fB\-fno\-sanitize\-recover=\fR option
  can be used to alter
  this behavior: only the first detected error is reported
! and program then exits with a non-zero exit code.
  .Sp
  Currently this feature only works for \fB\-fsanitize=undefined\fR (and its suboptions
  except for \fB\-fsanitize=unreachable\fR and \fB\-fsanitize=return\fR),
--- 15922,15928 ----
  have been reported.  The \fB\-fno\-sanitize\-recover=\fR option
  can be used to alter
  this behavior: only the first detected error is reported
! and program then exits with a non\-zero exit code.
  .Sp
  Currently this feature only works for \fB\-fsanitize=undefined\fR (and its suboptions
  except for \fB\-fsanitize=unreachable\fR and \fB\-fsanitize=return\fR),
*************** equivalent to specifying an \fIopts\fR l
*** 16017,16030 ****
  .Vb 1
  \&        undefined,float\-cast\-overflow,float\-divide\-by\-zero,bounds\-strict
  .Ve
! .IP "\fB\-fsanitize\-address\-use\-after\-scope\fR" 4
  .IX Item "-fsanitize-address-use-after-scope"
! Enable sanitization of local variables to detect use-after-scope bugs.
  The option sets \fB\-fstack\-reuse\fR to \fBnone\fR.
! .IP "\fB\-fsanitize\-trap\fR[\fB=\fR\fIopts\fR]" 4
  .IX Item "-fsanitize-trap[=opts]"
  The \fB\-fsanitize\-trap=\fR option instructs the compiler to
! report for sanitizers mentioned in comma-separated list of \fIopts\fR
  undefined behavior using \f(CW\*(C`_\|_builtin_trap\*(C'\fR rather than a \f(CW\*(C`libubsan\*(C'\fR
  library routine.  If this option is enabled for certain sanitizer,
  it takes precedence over the \fB\-fsanitizer\-recover=\fR for that
--- 15948,15961 ----
  .Vb 1
  \&        undefined,float\-cast\-overflow,float\-divide\-by\-zero,bounds\-strict
  .Ve
! .IP \fB\-fsanitize\-address\-use\-after\-scope\fR 4
  .IX Item "-fsanitize-address-use-after-scope"
! Enable sanitization of local variables to detect use\-after\-scope bugs.
  The option sets \fB\-fstack\-reuse\fR to \fBnone\fR.
! .IP \fB\-fsanitize\-trap\fR[\fB=\fR\fIopts\fR] 4
  .IX Item "-fsanitize-trap[=opts]"
  The \fB\-fsanitize\-trap=\fR option instructs the compiler to
! report for sanitizers mentioned in comma\-separated list of \fIopts\fR
  undefined behavior using \f(CW\*(C`_\|_builtin_trap\*(C'\fR rather than a \f(CW\*(C`libubsan\*(C'\fR
  library routine.  If this option is enabled for certain sanitizer,
  it takes precedence over the \fB\-fsanitizer\-recover=\fR for that
*************** If \f(CW\*(C`\-fsanitize\-trap=undefined
*** 16046,16060 ****
  and \f(CW\*(C`\-fsanitize=vptr\*(C'\fR is enabled on the command line, the
  instrumentation is silently ignored as the instrumentation always needs
  \&\f(CW\*(C`libubsan\*(C'\fR support, \fB\-fsanitize\-trap=vptr\fR is not allowed.
! .IP "\fB\-fsanitize\-undefined\-trap\-on\-error\fR" 4
  .IX Item "-fsanitize-undefined-trap-on-error"
  The \fB\-fsanitize\-undefined\-trap\-on\-error\fR option is deprecated
  equivalent of \fB\-fsanitize\-trap=all\fR.
! .IP "\fB\-fsanitize\-coverage=trace\-pc\fR" 4
  .IX Item "-fsanitize-coverage=trace-pc"
! Enable coverage-guided fuzzing code instrumentation.
  Inserts a call to \f(CW\*(C`_\|_sanitizer_cov_trace_pc\*(C'\fR into every basic block.
! .IP "\fB\-fsanitize\-coverage=trace\-cmp\fR" 4
  .IX Item "-fsanitize-coverage=trace-cmp"
  Enable dataflow guided fuzzing code instrumentation.
  Inserts a call to \f(CW\*(C`_\|_sanitizer_cov_trace_cmp1\*(C'\fR,
--- 15977,15991 ----
  and \f(CW\*(C`\-fsanitize=vptr\*(C'\fR is enabled on the command line, the
  instrumentation is silently ignored as the instrumentation always needs
  \&\f(CW\*(C`libubsan\*(C'\fR support, \fB\-fsanitize\-trap=vptr\fR is not allowed.
! .IP \fB\-fsanitize\-undefined\-trap\-on\-error\fR 4
  .IX Item "-fsanitize-undefined-trap-on-error"
  The \fB\-fsanitize\-undefined\-trap\-on\-error\fR option is deprecated
  equivalent of \fB\-fsanitize\-trap=all\fR.
! .IP \fB\-fsanitize\-coverage=trace\-pc\fR 4
  .IX Item "-fsanitize-coverage=trace-pc"
! Enable coverage\-guided fuzzing code instrumentation.
  Inserts a call to \f(CW\*(C`_\|_sanitizer_cov_trace_pc\*(C'\fR into every basic block.
! .IP \fB\-fsanitize\-coverage=trace\-cmp\fR 4
  .IX Item "-fsanitize-coverage=trace-cmp"
  Enable dataflow guided fuzzing code instrumentation.
  Inserts a call to \f(CW\*(C`_\|_sanitizer_cov_trace_cmp1\*(C'\fR,
*************** variable or \f(CW\*(C`_\|_sanitizer_cov_
*** 16067,16092 ****
  operand constant, \f(CW\*(C`_\|_sanitizer_cov_trace_cmpf\*(C'\fR or
  \&\f(CW\*(C`_\|_sanitizer_cov_trace_cmpd\*(C'\fR for float or double comparisons and
  \&\f(CW\*(C`_\|_sanitizer_cov_trace_switch\*(C'\fR for switch statements.
! .IP "\fB\-fcf\-protection=\fR[\fBfull\fR|\fBbranch\fR|\fBreturn\fR|\fBnone\fR|\fBcheck\fR]" 4
  .IX Item "-fcf-protection=[full|branch|return|none|check]"
! Enable code instrumentation of control-flow transfers to increase
! program security by checking that target addresses of control-flow
  transfer instructions (such as indirect function call, function return,
  indirect jump) are valid.  This prevents diverting the flow of control
  to an unexpected target.  This is intended to protect against such
! threats as Return-oriented Programming (\s-1ROP\s0), and similarly
! call/jmp\-oriented programming (\s-1COP/JOP\s0).
  .Sp
  The value \f(CW\*(C`branch\*(C'\fR tells the compiler to implement checking of
! validity of control-flow transfer at the point of indirect branch
  instructions, i.e. call/jmp instructions.  The value \f(CW\*(C`return\*(C'\fR
  implements checking of validity at the point of returning from a
  function.  The value \f(CW\*(C`full\*(C'\fR is an alias for specifying both
  \&\f(CW\*(C`branch\*(C'\fR and \f(CW\*(C`return\*(C'\fR. The value \f(CW\*(C`none\*(C'\fR turns off
  instrumentation.
  .Sp
! The value \f(CW\*(C`check\*(C'\fR is used for the final link with link-time
! optimization (\s-1LTO\s0).  An error is issued if \s-1LTO\s0 object files are
  compiled with different \fB\-fcf\-protection\fR values.  The
  value \f(CW\*(C`check\*(C'\fR is ignored at the compile time.
  .Sp
--- 15998,16023 ----
  operand constant, \f(CW\*(C`_\|_sanitizer_cov_trace_cmpf\*(C'\fR or
  \&\f(CW\*(C`_\|_sanitizer_cov_trace_cmpd\*(C'\fR for float or double comparisons and
  \&\f(CW\*(C`_\|_sanitizer_cov_trace_switch\*(C'\fR for switch statements.
! .IP \fB\-fcf\-protection=\fR[\fBfull\fR|\fBbranch\fR|\fBreturn\fR|\fBnone\fR|\fBcheck\fR] 4
  .IX Item "-fcf-protection=[full|branch|return|none|check]"
! Enable code instrumentation of control\-flow transfers to increase
! program security by checking that target addresses of control\-flow
  transfer instructions (such as indirect function call, function return,
  indirect jump) are valid.  This prevents diverting the flow of control
  to an unexpected target.  This is intended to protect against such
! threats as Return\-oriented Programming (ROP), and similarly
! call/jmp\-oriented programming (COP/JOP).
  .Sp
  The value \f(CW\*(C`branch\*(C'\fR tells the compiler to implement checking of
! validity of control\-flow transfer at the point of indirect branch
  instructions, i.e. call/jmp instructions.  The value \f(CW\*(C`return\*(C'\fR
  implements checking of validity at the point of returning from a
  function.  The value \f(CW\*(C`full\*(C'\fR is an alias for specifying both
  \&\f(CW\*(C`branch\*(C'\fR and \f(CW\*(C`return\*(C'\fR. The value \f(CW\*(C`none\*(C'\fR turns off
  instrumentation.
  .Sp
! The value \f(CW\*(C`check\*(C'\fR is used for the final link with link\-time
! optimization (LTO).  An error is issued if LTO object files are
  compiled with different \fB\-fcf\-protection\fR values.  The
  value \f(CW\*(C`check\*(C'\fR is ignored at the compile time.
  .Sp
*************** You can also use the \f(CW\*(C`nocf_chec
*** 16099,16107 ****
  which functions and calls should be skipped from instrumentation.
  .Sp
  Currently the x86 GNU/Linux target provides an implementation based
! on Intel Control-flow Enforcement Technology (\s-1CET\s0) which works for
  i686 processor or newer.
! .IP "\fB\-fharden\-compares\fR" 4
  .IX Item "-fharden-compares"
  For every logical test that survives gimple optimizations and is
  \&\fInot\fR the condition in a conditional branch (for example,
--- 16030,16038 ----
  which functions and calls should be skipped from instrumentation.
  .Sp
  Currently the x86 GNU/Linux target provides an implementation based
! on Intel Control\-flow Enforcement Technology (CET) which works for
  i686 processor or newer.
! .IP \fB\-fharden\-compares\fR 4
  .IX Item "-fharden-compares"
  For every logical test that survives gimple optimizations and is
  \&\fInot\fR the condition in a conditional branch (for example,
*************** variables), emit extra code to compute a
*** 16110,16123 ****
  condition, and to call \f(CW\*(C`_\|_builtin_trap\*(C'\fR if the results do not
  match.  Use with \fB\-fharden\-conditional\-branches\fR to cover all
  conditionals.
! .IP "\fB\-fharden\-conditional\-branches\fR" 4
  .IX Item "-fharden-conditional-branches"
! For every non-vectorized conditional branch that survives gimple
  optimizations, emit extra code to compute and verify the reversed
  condition, and to call \f(CW\*(C`_\|_builtin_trap\*(C'\fR if the result is
  unexpected.  Use with \fB\-fharden\-compares\fR to cover all
  conditionals.
! .IP "\fB\-fstack\-protector\fR" 4
  .IX Item "-fstack-protector"
  Emit extra code to check for buffer overflows, such as stack smashing
  attacks.  This is done by adding a guard variable to functions with
--- 16041,16054 ----
  condition, and to call \f(CW\*(C`_\|_builtin_trap\*(C'\fR if the results do not
  match.  Use with \fB\-fharden\-conditional\-branches\fR to cover all
  conditionals.
! .IP \fB\-fharden\-conditional\-branches\fR 4
  .IX Item "-fharden-conditional-branches"
! For every non\-vectorized conditional branch that survives gimple
  optimizations, emit extra code to compute and verify the reversed
  condition, and to call \f(CW\*(C`_\|_builtin_trap\*(C'\fR if the result is
  unexpected.  Use with \fB\-fharden\-compares\fR to cover all
  conditionals.
! .IP \fB\-fstack\-protector\fR 4
  .IX Item "-fstack-protector"
  Emit extra code to check for buffer overflows, such as stack smashing
  attacks.  This is done by adding a guard variable to functions with
*************** initialized when a function is entered a
*** 16127,16153 ****
  exits.  If a guard check fails, an error message is printed and the program
  exits.  Only variables that are actually allocated on the stack are
  considered, optimized away variables or variables allocated in registers
! don't count.
! .IP "\fB\-fstack\-protector\-all\fR" 4
  .IX Item "-fstack-protector-all"
  Like \fB\-fstack\-protector\fR except that all functions are protected.
! .IP "\fB\-fstack\-protector\-strong\fR" 4
  .IX Item "-fstack-protector-strong"
  Like \fB\-fstack\-protector\fR but includes additional functions to
  be protected \-\-\- those that have local array definitions, or have
  references to local frame addresses.  Only variables that are actually
  allocated on the stack are considered, optimized away variables or variables
! allocated in registers don't count.
! .IP "\fB\-fstack\-protector\-explicit\fR" 4
  .IX Item "-fstack-protector-explicit"
  Like \fB\-fstack\-protector\fR but only protects those functions which
  have the \f(CW\*(C`stack_protect\*(C'\fR attribute.
! .IP "\fB\-fstack\-check\fR" 4
  .IX Item "-fstack-check"
  Generate code to verify that you do not go beyond the boundary of the
  stack.  You should specify this flag if you are running in an
  environment with multiple threads, but you only rarely need to specify it in
! a single-threaded environment since stack overflow is automatically
  detected on nearly all systems if there is only one stack.
  .Sp
  Note that this switch does not actually cause checking to be done; the
--- 16058,16084 ----
  exits.  If a guard check fails, an error message is printed and the program
  exits.  Only variables that are actually allocated on the stack are
  considered, optimized away variables or variables allocated in registers
! don\*(Aqt count.
! .IP \fB\-fstack\-protector\-all\fR 4
  .IX Item "-fstack-protector-all"
  Like \fB\-fstack\-protector\fR except that all functions are protected.
! .IP \fB\-fstack\-protector\-strong\fR 4
  .IX Item "-fstack-protector-strong"
  Like \fB\-fstack\-protector\fR but includes additional functions to
  be protected \-\-\- those that have local array definitions, or have
  references to local frame addresses.  Only variables that are actually
  allocated on the stack are considered, optimized away variables or variables
! allocated in registers don\*(Aqt count.
! .IP \fB\-fstack\-protector\-explicit\fR 4
  .IX Item "-fstack-protector-explicit"
  Like \fB\-fstack\-protector\fR but only protects those functions which
  have the \f(CW\*(C`stack_protect\*(C'\fR attribute.
! .IP \fB\-fstack\-check\fR 4
  .IX Item "-fstack-check"
  Generate code to verify that you do not go beyond the boundary of the
  stack.  You should specify this flag if you are running in an
  environment with multiple threads, but you only rarely need to specify it in
! a single\-threaded environment since stack overflow is automatically
  detected on nearly all systems if there is only one stack.
  .Sp
  Note that this switch does not actually cause checking to be done; the
*************** operating system or the language runtime
*** 16155,16193 ****
  generation of code to ensure that they see the stack being extended.
  .Sp
  You can additionally specify a string parameter: \fBno\fR means no
! checking, \fBgeneric\fR means force the use of old-style checking,
  \&\fBspecific\fR means use the best checking method and is equivalent
  to bare \fB\-fstack\-check\fR.
  .Sp
! Old-style checking is a generic mechanism that requires no specific
  target support in the compiler but comes with the following drawbacks:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  Modified allocation strategy for large objects: they are always
  allocated dynamically if their size exceeds a fixed threshold.  Note this
  may change the semantics of some code.
! .IP "2." 4
  .IX Item "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.
! .IP "3." 4
  .IX Item "3."
  Inefficiency: because of both the modified allocation strategy and the
  generic implementation, code performance is hampered.
  .RE
  .RS 4
  .Sp
! Note that old-style stack checking is also the fallback method for
  \&\fBspecific\fR if no target support has been added in the compiler.
  .Sp
! \&\fB\-fstack\-check=\fR is designed for Ada's needs to detect infinite recursion
  and stack overflows.  \fBspecific\fR is an excellent choice when compiling
! Ada code.  It is not generally sufficient to protect against stack-clash
  attacks.  To protect against those you want \fB\-fstack\-clash\-protection\fR.
  .RE
! .IP "\fB\-fstack\-clash\-protection\fR" 4
  .IX Item "-fstack-clash-protection"
  Generate code to prevent stack clash style attacks.  When this option is
  enabled, the compiler will only allocate one page of stack space at a time
--- 16086,16124 ----
  generation of code to ensure that they see the stack being extended.
  .Sp
  You can additionally specify a string parameter: \fBno\fR means no
! checking, \fBgeneric\fR means force the use of old\-style checking,
  \&\fBspecific\fR means use the best checking method and is equivalent
  to bare \fB\-fstack\-check\fR.
  .Sp
! Old\-style checking is a generic mechanism that requires no specific
  target support in the compiler but comes with the following drawbacks:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  Modified allocation strategy for large objects: they are always
  allocated dynamically if their size exceeds a fixed threshold.  Note this
  may change the semantics of some code.
! .IP 2. 4
  .IX Item "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.
! .IP 3. 4
  .IX Item "3."
  Inefficiency: because of both the modified allocation strategy and the
  generic implementation, code performance is hampered.
  .RE
  .RS 4
  .Sp
! Note that old\-style stack checking is also the fallback method for
  \&\fBspecific\fR if no target support has been added in the compiler.
  .Sp
! \&\fB\-fstack\-check=\fR is designed for Ada\*(Aqs needs to detect infinite recursion
  and stack overflows.  \fBspecific\fR is an excellent choice when compiling
! Ada code.  It is not generally sufficient to protect against stack\-clash
  attacks.  To protect against those you want \fB\-fstack\-clash\-protection\fR.
  .RE
! .IP \fB\-fstack\-clash\-protection\fR 4
  .IX Item "-fstack-clash-protection"
  Generate code to prevent stack clash style attacks.  When this option is
  enabled, the compiler will only allocate one page of stack space at a time
*************** those targets \fB\-fstack\-clash\-protec
*** 16200,16211 ****
  allocations.  \fB\-fstack\-clash\-protection\fR may also provide limited
  protection for static stack allocations if the target supports
  \&\fB\-fstack\-check=specific\fR.
! .IP "\fB\-fstack\-limit\-register=\fR\fIreg\fR" 4
  .IX Item "-fstack-limit-register=reg"
  .PD 0
! .IP "\fB\-fstack\-limit\-symbol=\fR\fIsym\fR" 4
  .IX Item "-fstack-limit-symbol=sym"
! .IP "\fB\-fno\-stack\-limit\fR" 4
  .IX Item "-fno-stack-limit"
  .PD
  Generate code to ensure that the stack does not grow beyond a certain value,
--- 16131,16142 ----
  allocations.  \fB\-fstack\-clash\-protection\fR may also provide limited
  protection for static stack allocations if the target supports
  \&\fB\-fstack\-check=specific\fR.
! .IP \fB\-fstack\-limit\-register=\fR\fIreg\fR 4
  .IX Item "-fstack-limit-register=reg"
  .PD 0
! .IP \fB\-fstack\-limit\-symbol=\fR\fIsym\fR 4
  .IX Item "-fstack-limit-symbol=sym"
! .IP \fB\-fno\-stack\-limit\fR 4
  .IX Item "-fno-stack-limit"
  .PD
  Generate code to ensure that the stack does not grow beyond a certain value,
*************** For instance, if the stack starts at abs
*** 16218,16228 ****
  and grows downwards, you can use the flags
  \&\fB\-fstack\-limit\-symbol=_\|_stack_limit\fR and
  \&\fB\-Wl,\-\-defsym,_\|_stack_limit=0x7ffe0000\fR to enforce a stack limit
! of 128KB.  Note that this may only work with the \s-1GNU\s0 linker.
  .Sp
  You can locally override stack limit checking by using the
  \&\f(CW\*(C`no_stack_limit\*(C'\fR function attribute.
! .IP "\fB\-fsplit\-stack\fR" 4
  .IX Item "-fsplit-stack"
  Generate code to automatically split the stack before it overflows.
  The resulting program has a discontiguous stack which can only
--- 16149,16159 ----
  and grows downwards, you can use the flags
  \&\fB\-fstack\-limit\-symbol=_\|_stack_limit\fR and
  \&\fB\-Wl,\-\-defsym,_\|_stack_limit=0x7ffe0000\fR to enforce a stack limit
! of 128KB.  Note that this may only work with the GNU linker.
  .Sp
  You can locally override stack limit checking by using the
  \&\f(CW\*(C`no_stack_limit\*(C'\fR function attribute.
! .IP \fB\-fsplit\-stack\fR 4
  .IX Item "-fsplit-stack"
  Generate code to automatically split the stack before it overflows.
  The resulting program has a discontiguous stack which can only
*************** available for the latter code to run.  I
*** 16238,16248 ****
  including library code, with \fB\-fsplit\-stack\fR is not an option,
  then the linker can fix up these calls so that the code compiled
  without \fB\-fsplit\-stack\fR always has a large stack.  Support for
! this is implemented in the gold linker in \s-1GNU\s0 binutils release 2.21
  and later.
! .IP "\fB\-fvtable\-verify=\fR[\fBstd\fR|\fBpreinit\fR|\fBnone\fR]" 4
  .IX Item "-fvtable-verify=[std|preinit|none]"
! This option is only available when compiling \*(C+ code.
  It turns on (or off, if using \fB\-fvtable\-verify=none\fR) the security
  feature that verifies at run time, for every virtual call, that
  the vtable pointer through which the call is made is valid for the type of
--- 16169,16179 ----
  including library code, with \fB\-fsplit\-stack\fR is not an option,
  then the linker can fix up these calls so that the code compiled
  without \fB\-fsplit\-stack\fR always has a large stack.  Support for
! this is implemented in the gold linker in GNU binutils release 2.21
  and later.
! .IP \fB\-fvtable\-verify=\fR[\fBstd\fR|\fBpreinit\fR|\fBnone\fR] 4
  .IX Item "-fvtable-verify=[std|preinit|none]"
! This option is only available when compiling C++ code.
  It turns on (or off, if using \fB\-fvtable\-verify=none\fR) the security
  feature that verifies at run time, for every virtual call, that
  the vtable pointer through which the call is made is valid for the type of
*************** the object, and has not been corrupted o
*** 16250,16256 ****
  pointer is detected at run time, an error is reported and execution of the
  program is immediately halted.
  .Sp
! This option causes run-time data structures to be built at program startup,
  which are used for verifying the vtable pointers.  
  The options \fBstd\fR and \fBpreinit\fR
  control the timing of when these data structures are built.  In both cases the
--- 16181,16187 ----
  pointer is detected at run time, an error is reported and execution of the
  program is immediately halted.
  .Sp
! This option causes run\-time data structures to be built at program startup,
  which are used for verifying the vtable pointers.  
  The options \fBstd\fR and \fBpreinit\fR
  control the timing of when these data structures are built.  In both cases the
*************** libraries have been loaded and initializ
*** 16263,16269 ****
  If this option appears multiple times in the command line with different
  values specified, \fBnone\fR takes highest priority over both \fBstd\fR and
  \&\fBpreinit\fR; \fBpreinit\fR takes priority over \fBstd\fR.
! .IP "\fB\-fvtv\-debug\fR" 4
  .IX Item "-fvtv-debug"
  When used in conjunction with \fB\-fvtable\-verify=std\fR or 
  \&\fB\-fvtable\-verify=preinit\fR, causes debug versions of the 
--- 16194,16200 ----
  If this option appears multiple times in the command line with different
  values specified, \fBnone\fR takes highest priority over both \fBstd\fR and
  \&\fBpreinit\fR; \fBpreinit\fR takes priority over \fBstd\fR.
! .IP \fB\-fvtv\-debug\fR 4
  .IX Item "-fvtv-debug"
  When used in conjunction with \fB\-fvtable\-verify=std\fR or 
  \&\fB\-fvtable\-verify=preinit\fR, causes debug versions of the 
*************** runtime functions for the vtable verific
*** 16271,16299 ****
  This flag also causes the compiler to log information about which 
  vtable pointers it finds for each class.
  This information is written to a file named \fIvtv_set_ptr_data.log\fR 
! in the directory named by the environment variable \fB\s-1VTV_LOGS_DIR\s0\fR 
  if that is defined or the current working directory otherwise.
  .Sp
  Note:  This feature \fIappends\fR data to the log file. If you want a fresh log
  file, be sure to delete any existing one.
! .IP "\fB\-fvtv\-counts\fR" 4
  .IX Item "-fvtv-counts"
  This is a debugging flag.  When used in conjunction with
  \&\fB\-fvtable\-verify=std\fR or \fB\-fvtable\-verify=preinit\fR, this
  causes the compiler to keep track of the total number of virtual calls
  it encounters and the number of verifications it inserts.  It also
! counts the number of calls to certain run-time library functions
  that it inserts and logs this information for each compilation unit.
  The compiler writes this information to a file named
  \&\fIvtv_count_data.log\fR in the directory named by the environment
! variable \fB\s-1VTV_LOGS_DIR\s0\fR if that is defined or the current working
  directory otherwise.  It also counts the size of the vtable pointer sets
  for each class, and writes this information to \fIvtv_class_set_sizes.log\fR
  in the same directory.
  .Sp
  Note:  This feature \fIappends\fR data to the log files.  To get fresh log
  files, be sure to delete any existing ones.
! .IP "\fB\-finstrument\-functions\fR" 4
  .IX Item "-finstrument-functions"
  Generate instrumentation calls for entry and exit to functions.  Just
  after function entry and just before function exit, the following
--- 16202,16230 ----
  This flag also causes the compiler to log information about which 
  vtable pointers it finds for each class.
  This information is written to a file named \fIvtv_set_ptr_data.log\fR 
! in the directory named by the environment variable \fBVTV_LOGS_DIR\fR 
  if that is defined or the current working directory otherwise.
  .Sp
  Note:  This feature \fIappends\fR data to the log file. If you want a fresh log
  file, be sure to delete any existing one.
! .IP \fB\-fvtv\-counts\fR 4
  .IX Item "-fvtv-counts"
  This is a debugging flag.  When used in conjunction with
  \&\fB\-fvtable\-verify=std\fR or \fB\-fvtable\-verify=preinit\fR, this
  causes the compiler to keep track of the total number of virtual calls
  it encounters and the number of verifications it inserts.  It also
! counts the number of calls to certain run\-time library functions
  that it inserts and logs this information for each compilation unit.
  The compiler writes this information to a file named
  \&\fIvtv_count_data.log\fR in the directory named by the environment
! variable \fBVTV_LOGS_DIR\fR if that is defined or the current working
  directory otherwise.  It also counts the size of the vtable pointer sets
  for each class, and writes this information to \fIvtv_class_set_sizes.log\fR
  in the same directory.
  .Sp
  Note:  This feature \fIappends\fR data to the log files.  To get fresh log
  files, be sure to delete any existing ones.
! .IP \fB\-finstrument\-functions\fR 4
  .IX Item "-finstrument-functions"
  Generate instrumentation calls for entry and exit to functions.  Just
  after function entry and just before function exit, the following
*************** providing static copies.)
*** 16326,16336 ****
  .Sp
  A function may be given the attribute \f(CW\*(C`no_instrument_function\*(C'\fR, in
  which case this instrumentation is not done.  This can be used, for
! example, for the profiling functions listed above, high-priority
  interrupt routines, and any functions from which the profiling functions
  cannot safely be called (perhaps signal handlers, if the profiling
  routines generate output or allocate memory).
! .IP "\fB\-finstrument\-functions\-once\fR" 4
  .IX Item "-finstrument-functions-once"
  This is similar to \fB\-finstrument\-functions\fR, but the profiling
  functions are called only once per instrumented function, i.e. the first
--- 16257,16267 ----
  .Sp
  A function may be given the attribute \f(CW\*(C`no_instrument_function\*(C'\fR, in
  which case this instrumentation is not done.  This can be used, for
! example, for the profiling functions listed above, high\-priority
  interrupt routines, and any functions from which the profiling functions
  cannot safely be called (perhaps signal handlers, if the profiling
  routines generate output or allocate memory).
! .IP \fB\-finstrument\-functions\-once\fR 4
  .IX Item "-finstrument-functions-once"
  This is similar to \fB\-finstrument\-functions\fR, but the profiling
  functions are called only once per instrumented function, i.e. the first
*************** functions are called at \fIleast\fR once
*** 16345,16351 ****
  once per thread, but the calls are always paired, that is to say, if a
  thread calls the first function, then it will call the second function,
  unless it never reaches the exit of the instrumented function.
! .IP "\fB\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,...\fR" 4
  .IX Item "-finstrument-functions-exclude-file-list=file,file,..."
  Set the list of functions that are excluded from instrumentation (see
  the description of \fB\-finstrument\-functions\fR).  If the file that
--- 16276,16282 ----
  once per thread, but the calls are always paired, that is to say, if a
  thread calls the first function, then it will call the second function,
  unless it never reaches the exit of the instrumented function.
! .IP \fB\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,...\fR 4
  .IX Item "-finstrument-functions-exclude-file-list=file,file,..."
  Set the list of functions that are excluded from instrumentation (see
  the description of \fB\-finstrument\-functions\fR).  If the file that
*************** contain \fI/bits/stl\fR or \fIinclude/sy
*** 16365,16415 ****
  .Sp
  If, for some reason, you want to include letter \fB,\fR in one of
  \&\fIsym\fR, write \fB,\fR. For example,
! \&\fB\-finstrument\-functions\-exclude\-file\-list=',,tmp'\fR
  (note the single quote surrounding the option).
! .IP "\fB\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,...\fR" 4
  .IX Item "-finstrument-functions-exclude-function-list=sym,sym,..."
  This is similar to \fB\-finstrument\-functions\-exclude\-file\-list\fR,
  but this option sets the list of function names to be excluded from
! instrumentation.  The function name to be matched is its user-visible
  name, such as \f(CW\*(C`vector blah(const vector &)\*(C'\fR, not the
  internal mangled name (e.g., \f(CW\*(C`_Z4blahRSt6vectorIiSaIiEE\*(C'\fR).  The
  match is done on substrings: if the \fIsym\fR parameter is a substring
! of the function name, it is considered to be a match.  For C99 and \*(C+
! extended identifiers, the function name must be given in \s-1UTF\-8,\s0 not
  using universal character names.
! .IP "\fB\-fpatchable\-function\-entry=\fR\fIN\fR\fB[,\fR\fIM\fR\fB]\fR" 4
  .IX Item "-fpatchable-function-entry=N[,M]"
  Generate \fIN\fR NOPs right at the beginning
! of each function, with the function entry point before the \fIM\fRth \s-1NOP.\s0
  If \fIM\fR is omitted, it defaults to \f(CW0\fR so the
! function entry points to the address just at the first \s-1NOP.\s0
! The \s-1NOP\s0 instructions reserve extra space which can be used to patch in
  any desired instrumentation at run time, provided that the code segment
  is writable.  The amount of space is controllable indirectly via
! the number of NOPs; the \s-1NOP\s0 instruction used corresponds to the instruction
! emitted by the internal \s-1GCC\s0 back-end interface \f(CW\*(C`gen_nop\*(C'\fR.  This behavior
! is target-specific and may also depend on the architecture variant and/or
  other compilation options.
  .Sp
! For run-time identification, the starting addresses of these areas,
  which correspond to their respective function entries minus \fIM\fR,
  are additionally collected in the \f(CW\*(C`_\|_patchable_function_entries\*(C'\fR
  section of the resulting binary.
  .Sp
  Note that the value of \f(CW\*(C`_\|_attribute_\|_ ((patchable_function_entry
! (N,M)))\*(C'\fR takes precedence over command-line option
  \&\fB\-fpatchable\-function\-entry=N,M\fR.  This can be used to increase
  the area size or to remove it completely on a single function.
  If \f(CW\*(C`N=0\*(C'\fR, no pad location is recorded.
  .Sp
! The \s-1NOP\s0 instructions are inserted at\-\-\-and maybe before, depending on
  \&\fIM\fR\-\-\-the function entry address, even before the prologue.  On
! PowerPC with the ELFv2 \s-1ABI,\s0 for a function with dual entry points,
  the local entry point is this function entry address.
  .Sp
  The maximum value of \fIN\fR and \fIM\fR is 65535.  On PowerPC with the
! ELFv2 \s-1ABI,\s0 for a function with dual entry points, the supported values
  for \fIM\fR are 0, 2, 6 and 14.
  .SS "Options Controlling the Preprocessor"
  .IX Subsection "Options Controlling the Preprocessor"
--- 16296,16346 ----
  .Sp
  If, for some reason, you want to include letter \fB,\fR in one of
  \&\fIsym\fR, write \fB,\fR. For example,
! \&\fB\-finstrument\-functions\-exclude\-file\-list=\*(Aq,,tmp\*(Aq\fR
  (note the single quote surrounding the option).
! .IP \fB\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,...\fR 4
  .IX Item "-finstrument-functions-exclude-function-list=sym,sym,..."
  This is similar to \fB\-finstrument\-functions\-exclude\-file\-list\fR,
  but this option sets the list of function names to be excluded from
! instrumentation.  The function name to be matched is its user\-visible
  name, such as \f(CW\*(C`vector blah(const vector &)\*(C'\fR, not the
  internal mangled name (e.g., \f(CW\*(C`_Z4blahRSt6vectorIiSaIiEE\*(C'\fR).  The
  match is done on substrings: if the \fIsym\fR parameter is a substring
! of the function name, it is considered to be a match.  For C99 and C++
! extended identifiers, the function name must be given in UTF\-8, not
  using universal character names.
! .IP \fB\-fpatchable\-function\-entry=\fR\fIN\fR\fB[,\fR\fIM\fR\fB]\fR 4
  .IX Item "-fpatchable-function-entry=N[,M]"
  Generate \fIN\fR NOPs right at the beginning
! of each function, with the function entry point before the \fIM\fRth NOP.
  If \fIM\fR is omitted, it defaults to \f(CW0\fR so the
! function entry points to the address just at the first NOP.
! The NOP instructions reserve extra space which can be used to patch in
  any desired instrumentation at run time, provided that the code segment
  is writable.  The amount of space is controllable indirectly via
! the number of NOPs; the NOP instruction used corresponds to the instruction
! emitted by the internal GCC back\-end interface \f(CW\*(C`gen_nop\*(C'\fR.  This behavior
! is target\-specific and may also depend on the architecture variant and/or
  other compilation options.
  .Sp
! For run\-time identification, the starting addresses of these areas,
  which correspond to their respective function entries minus \fIM\fR,
  are additionally collected in the \f(CW\*(C`_\|_patchable_function_entries\*(C'\fR
  section of the resulting binary.
  .Sp
  Note that the value of \f(CW\*(C`_\|_attribute_\|_ ((patchable_function_entry
! (N,M)))\*(C'\fR takes precedence over command\-line option
  \&\fB\-fpatchable\-function\-entry=N,M\fR.  This can be used to increase
  the area size or to remove it completely on a single function.
  If \f(CW\*(C`N=0\*(C'\fR, no pad location is recorded.
  .Sp
! The NOP instructions are inserted at\-\-\-and maybe before, depending on
  \&\fIM\fR\-\-\-the function entry address, even before the prologue.  On
! PowerPC with the ELFv2 ABI, for a function with dual entry points,
  the local entry point is this function entry address.
  .Sp
  The maximum value of \fIN\fR and \fIM\fR is 65535.  On PowerPC with the
! ELFv2 ABI, for a function with dual entry points, the supported values
  for \fIM\fR are 0, 2, 6 and 14.
  .SS "Options Controlling the Preprocessor"
  .IX Subsection "Options Controlling the Preprocessor"
*************** they appeared during translation phase t
*** 16436,16450 ****
  directive.  In particular, the definition is truncated by
  embedded newline characters.
  .Sp
! If you are invoking the preprocessor from a shell or shell-like
! program you may need to use the shell's quoting syntax to protect
  characters such as spaces that have a meaning in the shell syntax.
  .Sp
! If you wish to define a function-like macro on the command line, write
  its argument list with surrounding parentheses before the equals sign
  (if any).  Parentheses are meaningful to most shells, so you should
  quote the option.  With \fBsh\fR and \fBcsh\fR,
! \&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works.
  .Sp
  \&\fB\-D\fR and \fB\-U\fR options are processed in the order they
  are given on the command line.  All \fB\-imacros\fR \fIfile\fR and
--- 16367,16381 ----
  directive.  In particular, the definition is truncated by
  embedded newline characters.
  .Sp
! If you are invoking the preprocessor from a shell or shell\-like
! program you may need to use the shell\*(Aqs quoting syntax to protect
  characters such as spaces that have a meaning in the shell syntax.
  .Sp
! If you wish to define a function\-like macro on the command line, write
  its argument list with surrounding parentheses before the equals sign
  (if any).  Parentheses are meaningful to most shells, so you should
  quote the option.  With \fBsh\fR and \fBcsh\fR,
! \&\fB\-D\*(Aq\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB\*(Aq\fR works.
  .Sp
  \&\fB\-D\fR and \fB\-U\fR options are processed in the order they
  are given on the command line.  All \fB\-imacros\fR \fIfile\fR and
*************** provided with a \fB\-D\fR option.
*** 16458,16464 ****
  .IX Item "-include file"
  Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
  line of the primary source file.  However, the first directory searched
! for \fIfile\fR is the preprocessor's working directory \fIinstead of\fR
  the directory containing the main source file.  If not found there, it
  is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
  chain as normal.
--- 16389,16395 ----
  .IX Item "-include file"
  Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
  line of the primary source file.  However, the first directory searched
! for \fIfile\fR is the preprocessor\*(Aqs working directory \fIinstead of\fR
  the directory containing the main source file.  If not found there, it
  is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
  chain as normal.
*************** processing its declarations.
*** 16474,16497 ****
  .Sp
  All files specified by \fB\-imacros\fR are processed before all files
  specified by \fB\-include\fR.
! .IP "\fB\-undef\fR" 4
  .IX Item "-undef"
! Do not predefine any system-specific or GCC-specific macros.  The
  standard predefined macros remain defined.
! .IP "\fB\-pthread\fR" 4
  .IX Item "-pthread"
! Define additional macros required for using the \s-1POSIX\s0 threads library.
  You should use this option consistently for both compilation and linking.
  This option is supported on GNU/Linux targets, most other Unix derivatives,
  and also on x86 Cygwin and MinGW targets.
! .IP "\fB\-M\fR" 4
  .IX Item "-M"
  Instead of outputting the result of preprocessing, output a rule
  suitable for \fBmake\fR describing the dependencies of the main
  source file.  The preprocessor outputs one \fBmake\fR rule containing
  the object file name for that source file, a colon, and the names of all
  the included files, including those coming from \fB\-include\fR or
! \&\fB\-imacros\fR command-line options.
  .Sp
  Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
  object file name consists of the name of the source file with any
--- 16405,16428 ----
  .Sp
  All files specified by \fB\-imacros\fR are processed before all files
  specified by \fB\-include\fR.
! .IP \fB\-undef\fR 4
  .IX Item "-undef"
! Do not predefine any system\-specific or GCC\-specific macros.  The
  standard predefined macros remain defined.
! .IP \fB\-pthread\fR 4
  .IX Item "-pthread"
! Define additional macros required for using the POSIX threads library.
  You should use this option consistently for both compilation and linking.
  This option is supported on GNU/Linux targets, most other Unix derivatives,
  and also on x86 Cygwin and MinGW targets.
! .IP \fB\-M\fR 4
  .IX Item "-M"
  Instead of outputting the result of preprocessing, output a rule
  suitable for \fBmake\fR describing the dependencies of the main
  source file.  The preprocessor outputs one \fBmake\fR rule containing
  the object file name for that source file, a colon, and the names of all
  the included files, including those coming from \fB\-include\fR or
! \&\fB\-imacros\fR command\-line options.
  .Sp
  Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
  object file name consists of the name of the source file with any
*************** parts removed.  If there are many includ
*** 16500,16515 ****
  split into several lines using \fB\e\fR\-newline.  The rule has no
  commands.
  .Sp
! This option does not suppress the preprocessor's debug output, such as
  \&\fB\-dM\fR.  To avoid mixing such debug output with the dependency
  rules you should explicitly specify the dependency output file with
  \&\fB\-MF\fR, or use an environment variable like
! \&\fB\s-1DEPENDENCIES_OUTPUT\s0\fR.  Debug output
  is still sent to the regular output stream as normal.
  .Sp
  Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
  warnings with an implicit \fB\-w\fR.
! .IP "\fB\-MM\fR" 4
  .IX Item "-MM"
  Like \fB\-M\fR but do not mention header files that are found in
  system header directories, nor header files that are included,
--- 16431,16446 ----
  split into several lines using \fB\e\fR\-newline.  The rule has no
  commands.
  .Sp
! This option does not suppress the preprocessor\*(Aqs debug output, such as
  \&\fB\-dM\fR.  To avoid mixing such debug output with the dependency
  rules you should explicitly specify the dependency output file with
  \&\fB\-MF\fR, or use an environment variable like
! \&\fBDEPENDENCIES_OUTPUT\fR.  Debug output
  is still sent to the regular output stream as normal.
  .Sp
  Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
  warnings with an implicit \fB\-w\fR.
! .IP \fB\-MM\fR 4
  .IX Item "-MM"
  Like \fB\-M\fR but do not mention header files that are found in
  system header directories, nor header files that are included,
*************** When used with the driver options \fB\-M
*** 16529,16535 ****
  \&\fB\-MF\fR overrides the default dependency output file.
  .Sp
  If \fIfile\fR is \fI\-\fR, then the dependencies are written to \fIstdout\fR.
! .IP "\fB\-MG\fR" 4
  .IX Item "-MG"
  In conjunction with an option such as \fB\-M\fR requesting
  dependency generation, \fB\-MG\fR assumes missing header files are
--- 16460,16466 ----
  \&\fB\-MF\fR overrides the default dependency output file.
  .Sp
  If \fIfile\fR is \fI\-\fR, then the dependencies are written to \fIstdout\fR.
! .IP \fB\-MG\fR 4
  .IX Item "-MG"
  In conjunction with an option such as \fB\-M\fR requesting
  dependency generation, \fB\-MG\fR assumes missing header files are
*************** also suppresses preprocessed output, as
*** 16540,16551 ****
  this useless.
  .Sp
  This feature is used in automatic updating of makefiles.
! .IP "\fB\-Mno\-modules\fR" 4
  .IX Item "-Mno-modules"
  Disable dependency generation for compiled module interfaces.
! .IP "\fB\-MP\fR" 4
  .IX Item "-MP"
! This option instructs \s-1CPP\s0 to add a phony target for each dependency
  other than the main file, causing each to depend on nothing.  These
  dummy rules work around errors \fBmake\fR gives if you remove header
  files without updating the \fIMakefile\fR to match.
--- 16471,16482 ----
  this useless.
  .Sp
  This feature is used in automatic updating of makefiles.
! .IP \fB\-Mno\-modules\fR 4
  .IX Item "-Mno-modules"
  Disable dependency generation for compiled module interfaces.
! .IP \fB\-MP\fR 4
  .IX Item "-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 \fBmake\fR gives if you remove header
  files without updating the \fIMakefile\fR to match.
*************** This is typical output:
*** 16560,16574 ****
  .IP "\fB\-MT\fR \fItarget\fR" 4
  .IX Item "-MT target"
  Change the target of the rule emitted by dependency generation.  By
! default \s-1CPP\s0 takes the name of the main input file, deletes any
  directory components and any file suffix such as \fB.c\fR, and
! appends the platform's usual object suffix.  The result is the target.
  .Sp
  An \fB\-MT\fR option sets the target to be exactly the string you
  specify.  If you want multiple targets, you can specify them as a single
  argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
  .Sp
! For example, \fB\-MT\ '$(objpfx)foo.o'\fR might give
  .Sp
  .Vb 1
  \&        $(objpfx)foo.o: foo.c
--- 16491,16505 ----
  .IP "\fB\-MT\fR \fItarget\fR" 4
  .IX Item "-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 \fB.c\fR, and
! appends the platform\*(Aqs usual object suffix.  The result is the target.
  .Sp
  An \fB\-MT\fR option sets the target to be exactly the string you
  specify.  If you want multiple targets, you can specify them as a single
  argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
  .Sp
! For example, \fB\-MT\ \*(Aq$(objpfx)foo.o\*(Aq\fR might give
  .Sp
  .Vb 1
  \&        $(objpfx)foo.o: foo.c
*************** For example, \fB\-MT\ '$(objpfx)foo.o'\f
*** 16576,16582 ****
  .IP "\fB\-MQ\fR \fItarget\fR" 4
  .IX Item "-MQ target"
  Same as \fB\-MT\fR, but it quotes any characters which are special to
! Make.  \fB\-MQ\ '$(objpfx)foo.o'\fR gives
  .Sp
  .Vb 1
  \&        $$(objpfx)foo.o: foo.c
--- 16507,16513 ----
  .IP "\fB\-MQ\fR \fItarget\fR" 4
  .IX Item "-MQ target"
  Same as \fB\-MT\fR, but it quotes any characters which are special to
! Make.  \fB\-MQ\ \*(Aq$(objpfx)foo.o\*(Aq\fR gives
  .Sp
  .Vb 1
  \&        $$(objpfx)foo.o: foo.c
*************** Make.  \fB\-MQ\ '$(objpfx)foo.o'\fR give
*** 16584,16590 ****
  .Sp
  The default target is automatically quoted, as if it were given with
  \&\fB\-MQ\fR.
! .IP "\fB\-MD\fR" 4
  .IX Item "-MD"
  \&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
  \&\fB\-E\fR is not implied.  The driver determines \fIfile\fR based on
--- 16515,16521 ----
  .Sp
  The default target is automatically quoted, as if it were given with
  \&\fB\-MQ\fR.
! .IP \fB\-MD\fR 4
  .IX Item "-MD"
  \&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
  \&\fB\-E\fR is not implied.  The driver determines \fIfile\fR based on
*************** is understood to specify a target object
*** 16599,16609 ****
  .Sp
  Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
  a dependency output file as a side effect of the compilation process.
! .IP "\fB\-MMD\fR" 4
  .IX Item "-MMD"
  Like \fB\-MD\fR except mention only user header files, not system
  header files.
! .IP "\fB\-fpreprocessed\fR" 4
  .IX Item "-fpreprocessed"
  Indicate to the preprocessor that the input file has already been
  preprocessed.  This suppresses things like macro expansion, trigraph
--- 16530,16540 ----
  .Sp
  Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
  a dependency output file as a side effect of the compilation process.
! .IP \fB\-MMD\fR 4
  .IX Item "-MMD"
  Like \fB\-MD\fR except mention only user header files, not system
  header files.
! .IP \fB\-fpreprocessed\fR 4
  .IX Item "-fpreprocessed"
  Indicate to the preprocessor that the input file has already been
  preprocessed.  This suppresses things like macro expansion, trigraph
*************** a tokenizer for the front ends.
*** 16615,16627 ****
  .Sp
  \&\fB\-fpreprocessed\fR is implicit if the input file has one of the
  extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR.  These are the
! extensions that \s-1GCC\s0 uses for preprocessed files created by
  \&\fB\-save\-temps\fR.
! .IP "\fB\-fdirectives\-only\fR" 4
  .IX Item "-fdirectives-only"
  When preprocessing, handle directives, but do not expand macros.
  .Sp
! The option's behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
  options.
  .Sp
  With \fB\-E\fR, preprocessing is limited to the handling of directives
--- 16546,16558 ----
  .Sp
  \&\fB\-fpreprocessed\fR is implicit if the input file has one of the
  extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR.  These are the
! extensions that GCC uses for preprocessed files created by
  \&\fB\-save\-temps\fR.
! .IP \fB\-fdirectives\-only\fR 4
  .IX Item "-fdirectives-only"
  When preprocessing, handle directives, but do not expand macros.
  .Sp
! The option\*(Aqs behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
  options.
  .Sp
  With \fB\-E\fR, preprocessing is limited to the handling of directives
*************** files previously preprocessed with \f(CW
*** 16638,16664 ****
  With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
  \&\fB\-fpreprocessed\fR take precedence.  This enables full preprocessing of
  files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
! .IP "\fB\-fdollars\-in\-identifiers\fR" 4
  .IX Item "-fdollars-in-identifiers"
  Accept \fB$\fR in identifiers.
! .IP "\fB\-fextended\-identifiers\fR" 4
  .IX Item "-fextended-identifiers"
  Accept universal character names and extended characters in
  identifiers.  This option is enabled by default for C99 (and later C
! standard versions) and \*(C+.
! .IP "\fB\-fno\-canonical\-system\-headers\fR" 4
  .IX Item "-fno-canonical-system-headers"
  When preprocessing, do not shorten system header paths with canonicalization.
! .IP "\fB\-fmax\-include\-depth=\fR\fIdepth\fR" 4
  .IX Item "-fmax-include-depth=depth"
  Set the maximum depth of the nested #include. The default is 200.
! .IP "\fB\-ftabstop=\fR\fIwidth\fR" 4
  .IX Item "-ftabstop=width"
  Set the distance between tab stops.  This helps the preprocessor report
  correct column numbers in warnings or errors, even if tabs appear on the
  line.  If the value is less than 1 or greater than 100, the option is
  ignored.  The default is 8.
! .IP "\fB\-ftrack\-macro\-expansion\fR[\fB=\fR\fIlevel\fR]" 4
  .IX Item "-ftrack-macro-expansion[=level]"
  Track locations of tokens across macro expansions. This allows the
  compiler to emit diagnostic about the current macro expansion stack
--- 16569,16595 ----
  With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
  \&\fB\-fpreprocessed\fR take precedence.  This enables full preprocessing of
  files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
! .IP \fB\-fdollars\-in\-identifiers\fR 4
  .IX Item "-fdollars-in-identifiers"
  Accept \fB$\fR in identifiers.
! .IP \fB\-fextended\-identifiers\fR 4
  .IX Item "-fextended-identifiers"
  Accept universal character names and extended characters in
  identifiers.  This option is enabled by default for C99 (and later C
! standard versions) and C++.
! .IP \fB\-fno\-canonical\-system\-headers\fR 4
  .IX Item "-fno-canonical-system-headers"
  When preprocessing, do not shorten system header paths with canonicalization.
! .IP \fB\-fmax\-include\-depth=\fR\fIdepth\fR 4
  .IX Item "-fmax-include-depth=depth"
  Set the maximum depth of the nested #include. The default is 200.
! .IP \fB\-ftabstop=\fR\fIwidth\fR 4
  .IX Item "-ftabstop=width"
  Set the distance between tab stops.  This helps the preprocessor report
  correct column numbers in warnings or errors, even if tabs appear on the
  line.  If the value is less than 1 or greater than 100, the option is
  ignored.  The default is 8.
! .IP \fB\-ftrack\-macro\-expansion\fR[\fB=\fR\fIlevel\fR] 4
  .IX Item "-ftrack-macro-expansion[=level]"
  Track locations of tokens across macro expansions. This allows the
  compiler to emit diagnostic about the current macro expansion stack
*************** when a compilation error occurs in a mac
*** 16666,16746 ****
  option makes the preprocessor and the compiler consume more
  memory. The \fIlevel\fR parameter can be used to choose the level of
  precision of token location tracking thus decreasing the memory
! consumption if necessary. Value \fB0\fR of \fIlevel\fR de-activates
  this option. Value \fB1\fR tracks tokens locations in a
  degraded mode for the sake of minimal memory overhead. In this mode
  all tokens resulting from the expansion of an argument of a
! function-like macro have the same location. Value \fB2\fR tracks
  tokens locations completely. This value is the most memory hungry.
  When this option is given no argument, the default parameter value is
  \&\fB2\fR.
  .Sp
  Note that \f(CW\*(C`\-ftrack\-macro\-expansion=2\*(C'\fR is activated by default.
! .IP "\fB\-fmacro\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
  .IX Item "-fmacro-prefix-map=old=new"
! When preprocessing files residing in directory \fI\fIold\fI\fR,
  expand the \f(CW\*(C`_\|_FILE_\|_\*(C'\fR and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR macros as if the
! files resided in directory \fI\fInew\fI\fR instead.  This can be used
  to change an absolute path to a relative path by using \fI.\fR for
  \&\fInew\fR which can result in more reproducible builds that are
  location independent.  This option also affects
  \&\f(CW\*(C`_\|_builtin_FILE()\*(C'\fR during compilation.  See also
  \&\fB\-ffile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP "\fB\-fexec\-charset=\fR\fIcharset\fR" 4
  .IX Item "-fexec-charset=charset"
  Set the execution character set, used for string and character
! constants.  The default is \s-1UTF\-8.\s0  \fIcharset\fR can be any encoding
! supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP "\fB\-fwide\-exec\-charset=\fR\fIcharset\fR" 4
  .IX Item "-fwide-exec-charset=charset"
  Set the wide execution character set, used for wide string and
! character constants.  The default is one of \s-1UTF\-32BE, UTF\-32LE, UTF\-16BE,\s0
! or \s-1UTF\-16LE,\s0 whichever corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR and the
! big-endian or little-endian byte order being used for code generation.  As
  with \fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
! by the system's \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
  problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
! .IP "\fB\-finput\-charset=\fR\fIcharset\fR" 4
  .IX Item "-finput-charset=charset"
  Set the input character set, used for translation from the character
! set of the input file to the source character set used by \s-1GCC.\s0  If the
! locale does not specify, or \s-1GCC\s0 cannot get this information from the
! locale, the default is \s-1UTF\-8.\s0  This can be overridden by either the locale
! or this command-line option.  Currently the command-line option takes
! precedence if there's a conflict.  \fIcharset\fR can be any encoding
! supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP "\fB\-fpch\-deps\fR" 4
  .IX Item "-fpch-deps"
  When using precompiled headers, this flag
! causes the dependency-output flags to also list the files from the
! precompiled header's dependencies.  If not specified, only the
  precompiled header are listed and not the files that were used to
  create it, because those files are not consulted when a precompiled
  header is used.
! .IP "\fB\-fpch\-preprocess\fR" 4
  .IX Item "-fpch-preprocess"
  This option allows use of a precompiled header together with \fB\-E\fR.  It inserts a special \f(CW\*(C`#pragma\*(C'\fR,
! \&\f(CW\*(C`#pragma GCC pch_preprocess "\f(CIfilename\f(CW"\*(C'\fR in the output to mark
  the place where the precompiled header was found, and its \fIfilename\fR.
! When \fB\-fpreprocessed\fR is in use, \s-1GCC\s0 recognizes this \f(CW\*(C`#pragma\*(C'\fR
! and loads the \s-1PCH.\s0
  .Sp
  This option is off by default, because the resulting preprocessed output
! is only really suitable as input to \s-1GCC.\s0  It is switched on by
  \&\fB\-save\-temps\fR.
  .Sp
  You should not write this \f(CW\*(C`#pragma\*(C'\fR in your own code, but it is
! safe to edit the filename if the \s-1PCH\s0 file is available in a different
! location.  The filename may be absolute or it may be relative to \s-1GCC\s0's
  current directory.
! .IP "\fB\-fworking\-directory\fR" 4
  .IX Item "-fworking-directory"
  Enable generation of linemarkers in the preprocessor output that
  let the compiler know the current working directory at the time of
  preprocessing.  When this option is enabled, the preprocessor
  emits, after the initial linemarker, a second linemarker with the
! current working directory followed by two slashes.  \s-1GCC\s0 uses 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
--- 16597,16677 ----
  option makes the preprocessor and the compiler consume more
  memory. The \fIlevel\fR parameter can be used to choose the level of
  precision of token location tracking thus decreasing the memory
! consumption if necessary. Value \fB0\fR of \fIlevel\fR de\-activates
  this option. Value \fB1\fR tracks tokens locations in a
  degraded mode for the sake of minimal memory overhead. In this mode
  all tokens resulting from the expansion of an argument of a
! function\-like macro have the same location. Value \fB2\fR tracks
  tokens locations completely. This value is the most memory hungry.
  When this option is given no argument, the default parameter value is
  \&\fB2\fR.
  .Sp
  Note that \f(CW\*(C`\-ftrack\-macro\-expansion=2\*(C'\fR is activated by default.
! .IP \fB\-fmacro\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 4
  .IX Item "-fmacro-prefix-map=old=new"
! When preprocessing files residing in directory \fIold\fR,
  expand the \f(CW\*(C`_\|_FILE_\|_\*(C'\fR and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR macros as if the
! files resided in directory \fInew\fR instead.  This can be used
  to change an absolute path to a relative path by using \fI.\fR for
  \&\fInew\fR which can result in more reproducible builds that are
  location independent.  This option also affects
  \&\f(CW\*(C`_\|_builtin_FILE()\*(C'\fR during compilation.  See also
  \&\fB\-ffile\-prefix\-map\fR and \fB\-fcanon\-prefix\-map\fR.
! .IP \fB\-fexec\-charset=\fR\fIcharset\fR 4
  .IX Item "-fexec-charset=charset"
  Set the execution character set, used for string and character
! constants.  The default is UTF\-8.  \fIcharset\fR can be any encoding
! supported by the system\*(Aqs \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP \fB\-fwide\-exec\-charset=\fR\fIcharset\fR 4
  .IX Item "-fwide-exec-charset=charset"
  Set the wide execution character set, used for wide string and
! character constants.  The default is one of UTF\-32BE, UTF\-32LE, UTF\-16BE,
! or UTF\-16LE, whichever corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR and the
! big\-endian or little\-endian byte order being used for code generation.  As
  with \fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
! by the system\*(Aqs \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
  problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
! .IP \fB\-finput\-charset=\fR\fIcharset\fR 4
  .IX Item "-finput-charset=charset"
  Set the input character set, used for translation from the character
! set of the input file to the source character set used by 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\*(Aqs a conflict.  \fIcharset\fR can be any encoding
! supported by the system\*(Aqs \f(CW\*(C`iconv\*(C'\fR library routine.
! .IP \fB\-fpch\-deps\fR 4
  .IX Item "-fpch-deps"
  When using precompiled headers, this flag
! causes the dependency\-output flags to also list the files from the
! precompiled header\*(Aqs dependencies.  If not specified, only the
  precompiled header are listed and not the files that were used to
  create it, because those files are not consulted when a precompiled
  header is used.
! .IP \fB\-fpch\-preprocess\fR 4
  .IX Item "-fpch-preprocess"
  This option allows use of a precompiled header together with \fB\-E\fR.  It inserts a special \f(CW\*(C`#pragma\*(C'\fR,
! \&\f(CW\*(C`#pragma GCC pch_preprocess "\fR\f(CIfilename\fR\f(CW"\*(C'\fR in the output to mark
  the place where the precompiled header was found, and its \fIfilename\fR.
! When \fB\-fpreprocessed\fR is in use, GCC recognizes this \f(CW\*(C`#pragma\*(C'\fR
! and loads the PCH.
  .Sp
  This option is off by default, because the resulting preprocessed output
! is only really suitable as input to GCC.  It is switched on by
  \&\fB\-save\-temps\fR.
  .Sp
  You should not write this \f(CW\*(C`#pragma\*(C'\fR in your own code, but it is
! safe to edit the filename if the PCH file is available in a different
! location.  The filename may be absolute or it may be relative to GCC\*(Aqs
  current directory.
! .IP \fB\-fworking\-directory\fR 4
  .IX Item "-fworking-directory"
  Enable generation of linemarkers in the preprocessor output that
  let the compiler know the current working directory at the time of
  preprocessing.  When this option is enabled, the preprocessor
  emits, after the initial linemarker, a second linemarker with the
! current working directory followed by two slashes.  GCC uses this
! directory, when it\*(Aqs 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
*************** it does not use shell special characters
*** 16757,16763 ****
  .IX Item "-A -predicate=answer"
  Cancel an assertion with the predicate \fIpredicate\fR and answer
  \&\fIanswer\fR.
! .IP "\fB\-C\fR" 4
  .IX Item "-C"
  Do not discard comments.  All comments are passed through to the output
  file, except for comments in processed directives, which are deleted
--- 16688,16694 ----
  .IX Item "-A -predicate=answer"
  Cancel an assertion with the predicate \fIpredicate\fR and answer
  \&\fIanswer\fR.
! .IP \fB\-C\fR 4
  .IX Item "-C"
  Do not discard comments.  All comments are passed through to the output
  file, except for comments in processed directives, which are deleted
*************** causes the preprocessor to treat comment
*** 16768,16811 ****
  For example, comments appearing at the start of what would be a
  directive line have the effect of turning that line into an ordinary
  source line, since the first token on the line is no longer a \fB#\fR.
! .IP "\fB\-CC\fR" 4
  .IX Item "-CC"
  Do not discard comments, including during macro expansion.  This is
  like \fB\-C\fR, except that comments contained within macros are
  also passed through to the output file where the macro is expanded.
  .Sp
  In addition to the side effects of the \fB\-C\fR option, the
! \&\fB\-CC\fR option causes all \*(C+\-style comments inside a macro
  to be converted to C\-style comments.  This is to prevent later use
  of that macro from inadvertently commenting out the remainder of
  the source line.
  .Sp
  The \fB\-CC\fR option is generally used to support lint comments.
! .IP "\fB\-P\fR" 4
  .IX Item "-P"
  Inhibit generation of linemarkers in the output from the preprocessor.
  This might be useful when running the preprocessor on something that is
  not C code, and will be sent to a program which might be confused by the
  linemarkers.
! .IP "\fB\-traditional\fR" 4
  .IX Item "-traditional"
  .PD 0
! .IP "\fB\-traditional\-cpp\fR" 4
  .IX Item "-traditional-cpp"
  .PD
! Try to imitate the behavior of pre-standard C preprocessors, as
! opposed to \s-1ISO C\s0 preprocessors.
! See the \s-1GNU CPP\s0 manual for details.
  .Sp
! Note that \s-1GCC\s0 does not otherwise attempt to emulate a pre-standard 
  C compiler, and these options are only supported with the \fB\-E\fR 
! switch, or when invoking \s-1CPP\s0 explicitly.
! .IP "\fB\-trigraphs\fR" 4
  .IX Item "-trigraphs"
! Support \s-1ISO C\s0 trigraphs.
! These are three-character sequences, all starting with \fB??\fR, that
! are defined by \s-1ISO C\s0 to stand for single characters.  For example,
! \&\fB??/\fR stands for \fB\e\fR, so \fB'??/n'\fR is a character
  constant for a newline.
  .Sp
  The nine trigraphs and their replacements are
--- 16699,16742 ----
  For example, comments appearing at the start of what would be a
  directive line have the effect of turning that line into an ordinary
  source line, since the first token on the line is no longer a \fB#\fR.
! .IP \fB\-CC\fR 4
  .IX Item "-CC"
  Do not discard comments, including during macro expansion.  This is
  like \fB\-C\fR, except that comments contained within macros are
  also passed through to the output file where the macro is expanded.
  .Sp
  In addition to the side effects of the \fB\-C\fR option, the
! \&\fB\-CC\fR option causes all C++\-style comments inside a macro
  to be converted to C\-style comments.  This is to prevent later use
  of that macro from inadvertently commenting out the remainder of
  the source line.
  .Sp
  The \fB\-CC\fR option is generally used to support lint comments.
! .IP \fB\-P\fR 4
  .IX Item "-P"
  Inhibit generation of linemarkers in the output from the preprocessor.
  This might be useful when running the preprocessor on something that is
  not C code, and will be sent to a program which might be confused by the
  linemarkers.
! .IP \fB\-traditional\fR 4
  .IX Item "-traditional"
  .PD 0
! .IP \fB\-traditional\-cpp\fR 4
  .IX Item "-traditional-cpp"
  .PD
! Try to imitate the behavior of pre\-standard C preprocessors, as
! opposed to ISO C preprocessors.
! See the GNU CPP manual for details.
  .Sp
! Note that GCC does not otherwise attempt to emulate a pre\-standard 
  C compiler, and these options are only supported with the \fB\-E\fR 
! switch, or when invoking CPP explicitly.
! .IP \fB\-trigraphs\fR 4
  .IX Item "-trigraphs"
! Support ISO C trigraphs.
! These are three\-character sequences, all starting with \fB??\fR, that
! are defined by ISO C to stand for single characters.  For example,
! \&\fB??/\fR stands for \fB\e\fR, so \fB\*(Aq??/n\*(Aq\fR is a character
  constant for a newline.
  .Sp
  The nine trigraphs and their replacements are
*************** The nine trigraphs and their replacement
*** 16815,16844 ****
  \&        Replacement:      [    ]    {    }    #    \e    ^    |    ~
  .Ve
  .Sp
! By default, \s-1GCC\s0 ignores trigraphs, but in
! standard-conforming modes it converts them.  See the \fB\-std\fR and
  \&\fB\-ansi\fR options.
! .IP "\fB\-remap\fR" 4
  .IX Item "-remap"
  Enable special code to work around file systems which only permit very
! short file names, such as MS-DOS.
! .IP "\fB\-H\fR" 4
  .IX Item "-H"
  Print the name of each header file used, in addition to other normal
  activities.  Each name is indented to show how deep in the
  \&\fB#include\fR stack it is.  Precompiled header files are also
  printed, even if they are found to be invalid; an invalid precompiled
  header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
! .IP "\fB\-d\fR\fIletters\fR" 4
  .IX Item "-dletters"
  Says to make debugging dumps during compilation as specified by
  \&\fIletters\fR.  The flags documented here are those relevant to the
  preprocessor.  Other \fIletters\fR are interpreted
! by the compiler proper, or reserved for future versions of \s-1GCC,\s0 and so
  are silently ignored.  If you specify \fIletters\fR whose behavior
  conflicts, the result is undefined.
  .RS 4
! .IP "\fB\-dM\fR" 4
  .IX Item "-dM"
  Instead of the normal output, generate a list of \fB#define\fR
  directives for all the macros defined during the execution of the
--- 16746,16775 ----
  \&        Replacement:      [    ]    {    }    #    \e    ^    |    ~
  .Ve
  .Sp
! By default, GCC ignores trigraphs, but in
! standard\-conforming modes it converts them.  See the \fB\-std\fR and
  \&\fB\-ansi\fR options.
! .IP \fB\-remap\fR 4
  .IX Item "-remap"
  Enable special code to work around file systems which only permit very
! short file names, such as MS\-DOS.
! .IP \fB\-H\fR 4
  .IX Item "-H"
  Print the name of each header file used, in addition to other normal
  activities.  Each name is indented to show how deep in the
  \&\fB#include\fR stack it is.  Precompiled header files are also
  printed, even if they are found to be invalid; an invalid precompiled
  header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
! .IP \fB\-d\fR\fIletters\fR 4
  .IX Item "-dletters"
  Says to make debugging dumps during compilation as specified by
  \&\fIletters\fR.  The flags documented here are those relevant to the
  preprocessor.  Other \fIletters\fR are interpreted
! by the compiler proper, or reserved for future versions of GCC, and so
  are silently ignored.  If you specify \fIletters\fR whose behavior
  conflicts, the result is undefined.
  .RS 4
! .IP \fB\-dM\fR 4
  .IX Item "-dM"
  Instead of the normal output, generate a list of \fB#define\fR
  directives for all the macros defined during the execution of the
*************** shows all the predefined macros.
*** 16854,16873 ****
  .Sp
  If you use \fB\-dM\fR without the \fB\-E\fR option, \fB\-dM\fR is
  interpreted as a synonym for \fB\-fdump\-rtl\-mach\fR.
! .IP "\fB\-dD\fR" 4
  .IX Item "-dD"
  Like \fB\-dM\fR except in two respects: it does \fInot\fR include the
  predefined macros, and it outputs \fIboth\fR the \fB#define\fR
  directives and the result of preprocessing.  Both kinds of output go to
  the standard output file.
! .IP "\fB\-dN\fR" 4
  .IX Item "-dN"
  Like \fB\-dD\fR, but emit only the macro names, not their expansions.
! .IP "\fB\-dI\fR" 4
  .IX Item "-dI"
  Output \fB#include\fR directives in addition to the result of
  preprocessing.
! .IP "\fB\-dU\fR" 4
  .IX Item "-dU"
  Like \fB\-dD\fR except that only macros that are expanded, or whose
  definedness is tested in preprocessor directives, are output; the
--- 16785,16804 ----
  .Sp
  If you use \fB\-dM\fR without the \fB\-E\fR option, \fB\-dM\fR is
  interpreted as a synonym for \fB\-fdump\-rtl\-mach\fR.
! .IP \fB\-dD\fR 4
  .IX Item "-dD"
  Like \fB\-dM\fR except in two respects: it does \fInot\fR include the
  predefined macros, and it outputs \fIboth\fR the \fB#define\fR
  directives and the result of preprocessing.  Both kinds of output go to
  the standard output file.
! .IP \fB\-dN\fR 4
  .IX Item "-dN"
  Like \fB\-dD\fR, but emit only the macro names, not their expansions.
! .IP \fB\-dI\fR 4
  .IX Item "-dI"
  Output \fB#include\fR directives in addition to the result of
  preprocessing.
! .IP \fB\-dU\fR 4
  .IX Item "-dU"
  Like \fB\-dD\fR except that only macros that are expanded, or whose
  definedness is tested in preprocessor directives, are output; the
*************** undefined at the time.
*** 16877,16929 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdebug\-cpp\fR" 4
  .IX Item "-fdebug-cpp"
! This option is only useful for debugging \s-1GCC.\s0  When used from \s-1CPP\s0 or with
  \&\fB\-E\fR, it dumps debugging information about location maps.  Every
  token in the output is preceded by the dump of the map its location
  belongs to.
  .Sp
! When used from \s-1GCC\s0 without \fB\-E\fR, this option has no effect.
! .IP "\fB\-Wp,\fR\fIoption\fR" 4
  .IX Item "-Wp,option"
  You can use \fB\-Wp,\fR\fIoption\fR to bypass the compiler driver
  and pass \fIoption\fR directly through to the preprocessor.  If
  \&\fIoption\fR contains commas, it is split into multiple options at the
  commas.  However, many options are modified, translated or interpreted
  by the compiler driver before being passed to the preprocessor, and
! \&\fB\-Wp\fR forcibly bypasses this phase.  The preprocessor's direct
  interface is undocumented and subject to change, so whenever possible
  you should avoid using \fB\-Wp\fR and let the driver handle the
  options instead.
  .IP "\fB\-Xpreprocessor\fR \fIoption\fR" 4
  .IX Item "-Xpreprocessor option"
  Pass \fIoption\fR as an option to the preprocessor.  You can use this to
! supply system-specific preprocessor options that \s-1GCC\s0 does not 
  recognize.
  .Sp
  If you want to pass an option that takes an argument, you must use
  \&\fB\-Xpreprocessor\fR twice, once for the option and once for the argument.
! .IP "\fB\-no\-integrated\-cpp\fR" 4
  .IX Item "-no-integrated-cpp"
  Perform preprocessing as a separate pass before compilation.
! By default, \s-1GCC\s0 performs preprocessing as an integrated part of
  input tokenization and parsing.
  If this option is provided, the appropriate language front end
! (\fBcc1\fR, \fBcc1plus\fR, or \fBcc1obj\fR for C, \*(C+,
! and Objective-C, respectively) is instead invoked twice,
  once for preprocessing only and once for actual compilation
  of the preprocessed input.
  This option may be useful in conjunction with the \fB\-B\fR or
  \&\fB\-wrapper\fR options to specify an alternate preprocessor or
  perform additional processing of the program source between
  normal preprocessing and compilation.
! .IP "\fB\-flarge\-source\-files\fR" 4
  .IX Item "-flarge-source-files"
! Adjust \s-1GCC\s0 to expect large source files, at the expense of slower
  compilation and higher memory usage.
  .Sp
! Specifically, \s-1GCC\s0 normally tracks both column numbers and line numbers
  within source files and it normally prints both of these numbers in
  diagnostics.  However, once it has processed a certain number of source
  lines, it stops tracking column numbers and only tracks line numbers.
--- 16808,16860 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-fdebug\-cpp\fR 4
  .IX Item "-fdebug-cpp"
! This option is only useful for debugging GCC.  When used from CPP or with
  \&\fB\-E\fR, it dumps debugging information about location maps.  Every
  token in the output is preceded by the dump of the map its location
  belongs to.
  .Sp
! When used from GCC without \fB\-E\fR, this option has no effect.
! .IP \fB\-Wp,\fR\fIoption\fR 4
  .IX Item "-Wp,option"
  You can use \fB\-Wp,\fR\fIoption\fR to bypass the compiler driver
  and pass \fIoption\fR directly through to the preprocessor.  If
  \&\fIoption\fR contains commas, it is split into multiple options at the
  commas.  However, many options are modified, translated or interpreted
  by the compiler driver before being passed to the preprocessor, and
! \&\fB\-Wp\fR forcibly bypasses this phase.  The preprocessor\*(Aqs direct
  interface is undocumented and subject to change, so whenever possible
  you should avoid using \fB\-Wp\fR and let the driver handle the
  options instead.
  .IP "\fB\-Xpreprocessor\fR \fIoption\fR" 4
  .IX Item "-Xpreprocessor option"
  Pass \fIoption\fR as an option to the preprocessor.  You can use this to
! supply system\-specific preprocessor options that GCC does not 
  recognize.
  .Sp
  If you want to pass an option that takes an argument, you must use
  \&\fB\-Xpreprocessor\fR twice, once for the option and once for the argument.
! .IP \fB\-no\-integrated\-cpp\fR 4
  .IX Item "-no-integrated-cpp"
  Perform preprocessing as a separate pass before compilation.
! By default, GCC performs preprocessing as an integrated part of
  input tokenization and parsing.
  If this option is provided, the appropriate language front end
! (\fBcc1\fR, \fBcc1plus\fR, or \fBcc1obj\fR for C, C++,
! and Objective\-C, respectively) is instead invoked twice,
  once for preprocessing only and once for actual compilation
  of the preprocessed input.
  This option may be useful in conjunction with the \fB\-B\fR or
  \&\fB\-wrapper\fR options to specify an alternate preprocessor or
  perform additional processing of the program source between
  normal preprocessing and compilation.
! .IP \fB\-flarge\-source\-files\fR 4
  .IX Item "-flarge-source-files"
! Adjust GCC to expect large source files, at the expense of slower
  compilation and higher memory usage.
  .Sp
! Specifically, GCC normally tracks both column numbers and line numbers
  within source files and it normally prints both of these numbers in
  diagnostics.  However, once it has processed a certain number of source
  lines, it stops tracking column numbers and only tracks line numbers.
*************** This means that diagnostics for later li
*** 16931,16948 ****
  It also means that options like \fB\-Wmisleading\-indentation\fR cease to work
  at that point, although the compiler prints a note if this happens.
  Passing \fB\-flarge\-source\-files\fR significantly increases the number
! of source lines that \s-1GCC\s0 can process before it stops tracking columns.
  .SS "Passing Options to the Assembler"
  .IX Subsection "Passing Options to the Assembler"
  You can pass options to the assembler.
! .IP "\fB\-Wa,\fR\fIoption\fR" 4
  .IX Item "-Wa,option"
  Pass \fIoption\fR as an option to the assembler.  If \fIoption\fR
  contains commas, it is split into multiple options at the commas.
  .IP "\fB\-Xassembler\fR \fIoption\fR" 4
  .IX Item "-Xassembler option"
  Pass \fIoption\fR as an option to the assembler.  You can use this to
! supply system-specific assembler options that \s-1GCC\s0 does not
  recognize.
  .Sp
  If you want to pass an option that takes an argument, you must use
--- 16862,16879 ----
  It also means that options like \fB\-Wmisleading\-indentation\fR cease to work
  at that point, although the compiler prints a note if this happens.
  Passing \fB\-flarge\-source\-files\fR significantly increases the number
! of source lines that GCC can process before it stops tracking columns.
  .SS "Passing Options to the Assembler"
  .IX Subsection "Passing Options to the Assembler"
  You can pass options to the assembler.
! .IP \fB\-Wa,\fR\fIoption\fR 4
  .IX Item "-Wa,option"
  Pass \fIoption\fR as an option to the assembler.  If \fIoption\fR
  contains commas, it is split into multiple options at the commas.
  .IP "\fB\-Xassembler\fR \fIoption\fR" 4
  .IX Item "-Xassembler option"
  Pass \fIoption\fR as an option to the assembler.  You can use this to
! supply system\-specific assembler options that GCC does not
  recognize.
  .Sp
  If you want to pass an option that takes an argument, you must use
*************** If you want to pass an option that takes
*** 16952,16980 ****
  These options come into play when the compiler links object files into
  an executable output file.  They are meaningless if the compiler is
  not doing a link step.
! .IP "\fIobject-file-name\fR" 4
  .IX Item "object-file-name"
  A file name that does not end in a special recognized suffix is
  considered to name an object file or library.  (Object files are
  distinguished from libraries by the linker according to the file
  contents.)  If linking is done, these object files are used as input
  to the linker.
! .IP "\fB\-c\fR" 4
  .IX Item "-c"
  .PD 0
! .IP "\fB\-S\fR" 4
  .IX Item "-S"
! .IP "\fB\-E\fR" 4
  .IX Item "-E"
  .PD
  If any of these options is used, then the linker is not run, and
  object file names should not be used as arguments.
! .IP "\fB\-flinker\-output=\fR\fItype\fR" 4
  .IX Item "-flinker-output=type"
! This option controls code generation of the link-time optimizer.  By
  default the linker output is automatically determined by the linker
  plugin.  For debugging the compiler and if incremental linking with a 
! non-LTO object file is desired, it may be useful to control the type
  manually.
  .Sp
  If \fItype\fR is \fBexec\fR, code generation produces a static
--- 16883,16911 ----
  These options come into play when the compiler links object files into
  an executable output file.  They are meaningless if the compiler is
  not doing a link step.
! .IP \fIobject\-file\-name\fR 4
  .IX Item "object-file-name"
  A file name that does not end in a special recognized suffix is
  considered to name an object file or library.  (Object files are
  distinguished from libraries by the linker according to the file
  contents.)  If linking is done, these object files are used as input
  to the linker.
! .IP \fB\-c\fR 4
  .IX Item "-c"
  .PD 0
! .IP \fB\-S\fR 4
  .IX Item "-S"
! .IP \fB\-E\fR 4
  .IX Item "-E"
  .PD
  If any of these options is used, then the linker is not run, and
  object file names should not be used as arguments.
! .IP \fB\-flinker\-output=\fR\fItype\fR 4
  .IX Item "-flinker-output=type"
! This option controls code generation of the link\-time optimizer.  By
  default the linker output is automatically determined by the linker
  plugin.  For debugging the compiler and if incremental linking with a 
! non\-LTO object file is desired, it may be useful to control the type
  manually.
  .Sp
  If \fItype\fR is \fBexec\fR, code generation produces a static
*************** disabled.
*** 16984,16990 ****
  If \fItype\fR is \fBdyn\fR, code generation produces a shared
  library.  In this case \fB\-fpic\fR or \fB\-fPIC\fR is preserved,
  but not enabled automatically.  This allows to build shared libraries
! without position-independent code on architectures where this is
  possible, i.e. on x86.
  .Sp
  If \fItype\fR is \fBpie\fR, code generation produces an \fB\-fpie\fR
--- 16915,16921 ----
  If \fItype\fR is \fBdyn\fR, code generation produces a shared
  library.  In this case \fB\-fpic\fR or \fB\-fPIC\fR is preserved,
  but not enabled automatically.  This allows to build shared libraries
! without position\-independent code on architectures where this is
  possible, i.e. on x86.
  .Sp
  If \fItype\fR is \fBpie\fR, code generation produces an \fB\-fpie\fR
*************** except that \fB\-fpie\fR is not disabled
*** 16993,17034 ****
  time.
  .Sp
  If \fItype\fR is \fBrel\fR, the compiler assumes that incremental linking is
! done.  The sections containing intermediate code for link-time optimization are
! merged, pre-optimized, and output to the resulting object file. In addition, if
  \&\fB\-ffat\-lto\-objects\fR is specified, binary code is produced for future
! non-LTO linking. The object file produced by incremental linking is smaller
  than a static library produced from the same object files.  At link time the
  result of incremental linking also loads faster than a static
  library assuming that the majority of objects in the library are used.
  .Sp
! Finally \fBnolto-rel\fR configures the compiler for incremental linking where
  code generation is forced, a final binary is produced, and the intermediate
! code for later link-time optimization is stripped. When multiple object files
  are linked together the resulting code is better optimized than with
! link-time optimizations disabled (for example, cross-module inlining 
  happens), but most of benefits of whole program optimizations are lost.
  .Sp
  During the incremental link (by \fB\-r\fR) the linker plugin defaults to
! \&\fBrel\fR. With current interfaces to \s-1GNU\s0 Binutils it is however not
! possible to incrementally link \s-1LTO\s0 objects and non-LTO objects into a single
  mixed object file.  If any of object files in incremental link cannot
! be used for link-time optimization, the linker plugin issues a warning and
! uses \fBnolto-rel\fR. To maintain whole program optimization, it is
  recommended to link such objects into static library instead. Alternatively it
! is possible to use H.J. Lu's binutils with support for mixed objects.
! .IP "\fB\-fuse\-ld=bfd\fR" 4
  .IX Item "-fuse-ld=bfd"
  Use the \fBbfd\fR linker instead of the default linker.
! .IP "\fB\-fuse\-ld=gold\fR" 4
  .IX Item "-fuse-ld=gold"
  Use the \fBgold\fR linker instead of the default linker.
! .IP "\fB\-fuse\-ld=lld\fR" 4
  .IX Item "-fuse-ld=lld"
! Use the \s-1LLVM\s0 \fBlld\fR linker instead of the default linker.
! .IP "\fB\-fuse\-ld=mold\fR" 4
  .IX Item "-fuse-ld=mold"
  Use the Modern Linker (\fBmold\fR) instead of the default linker.
! .IP "\fB\-l\fR\fIlibrary\fR" 4
  .IX Item "-llibrary"
  .PD 0
  .IP "\fB\-l\fR \fIlibrary\fR" 4
--- 16924,16965 ----
  time.
  .Sp
  If \fItype\fR is \fBrel\fR, the compiler assumes that incremental linking is
! done.  The sections containing intermediate code for link\-time optimization are
! merged, pre\-optimized, and output to the resulting object file. In addition, if
  \&\fB\-ffat\-lto\-objects\fR is specified, binary code is produced for future
! non\-LTO linking. The object file produced by incremental linking is smaller
  than a static library produced from the same object files.  At link time the
  result of incremental linking also loads faster than a static
  library assuming that the majority of objects in the library are used.
  .Sp
! Finally \fBnolto\-rel\fR configures the compiler for incremental linking where
  code generation is forced, a final binary is produced, and the intermediate
! code for later link\-time optimization is stripped. When multiple object files
  are linked together the resulting code is better optimized than with
! link\-time optimizations disabled (for example, cross\-module inlining 
  happens), but most of benefits of whole program optimizations are lost.
  .Sp
  During the incremental link (by \fB\-r\fR) the linker plugin defaults to
! \&\fBrel\fR. With current interfaces to GNU Binutils it is however not
! possible to incrementally link LTO objects and non\-LTO objects into a single
  mixed object file.  If any of object files in incremental link cannot
! be used for link\-time optimization, the linker plugin issues a warning and
! uses \fBnolto\-rel\fR. To maintain whole program optimization, it is
  recommended to link such objects into static library instead. Alternatively it
! is possible to use H.J. Lu\*(Aqs binutils with support for mixed objects.
! .IP \fB\-fuse\-ld=bfd\fR 4
  .IX Item "-fuse-ld=bfd"
  Use the \fBbfd\fR linker instead of the default linker.
! .IP \fB\-fuse\-ld=gold\fR 4
  .IX Item "-fuse-ld=gold"
  Use the \fBgold\fR linker instead of the default linker.
! .IP \fB\-fuse\-ld=lld\fR 4
  .IX Item "-fuse-ld=lld"
! Use the LLVM \fBlld\fR linker instead of the default linker.
! .IP \fB\-fuse\-ld=mold\fR 4
  .IX Item "-fuse-ld=mold"
  Use the Modern Linker (\fBmold\fR) instead of the default linker.
! .IP \fB\-l\fR\fIlibrary\fR 4
  .IX Item "-llibrary"
  .PD 0
  .IP "\fB\-l\fR \fIlibrary\fR" 4
*************** Use the Modern Linker (\fBmold\fR) inste
*** 17036,17054 ****
  .PD
  Search the library named \fIlibrary\fR when linking.  (The second
  alternative with the library as a separate argument is only for
! \&\s-1POSIX\s0 compliance and is not recommended.)
  .Sp
! The \fB\-l\fR option is passed directly to the linker by \s-1GCC.\s0  Refer
  to your linker documentation for exact details.  The general
! description below applies to the \s-1GNU\s0 linker.
  .Sp
  The linker searches a standard list of directories for the library.
  The directories searched include several standard system directories
  plus any that you specify with \fB\-L\fR.
  .Sp
  Static libraries are archives of object files, and have file names
! like \fIlib\fIlibrary\fI.a\fR.  Some targets also support shared
! libraries, which typically have names like \fIlib\fIlibrary\fI.so\fR.
  If both static and shared libraries are found, the linker gives
  preference to linking with the shared library unless the
  \&\fB\-static\fR option is used.
--- 16967,16985 ----
  .PD
  Search the library named \fIlibrary\fR when linking.  (The second
  alternative with the library as a separate argument is only for
! POSIX compliance and is not recommended.)
  .Sp
! The \fB\-l\fR option is passed directly to the linker by GCC.  Refer
  to your linker documentation for exact details.  The general
! description below applies to the GNU linker.
  .Sp
  The linker searches a standard list of directories for the library.
  The directories searched include several standard system directories
  plus any that you specify with \fB\-L\fR.
  .Sp
  Static libraries are archives of object files, and have file names
! like \fIliblibrary.a\fR.  Some targets also support shared
! libraries, which typically have names like \fIliblibrary.so\fR.
  If both static and shared libraries are found, the linker gives
  preference to linking with the shared library unless the
  \&\fB\-static\fR option is used.
*************** linker searches and processes libraries
*** 17058,17073 ****
  are specified.  Thus, \fBfoo.o \-lz bar.o\fR searches library \fBz\fR
  after file \fIfoo.o\fR but before \fIbar.o\fR.  If \fIbar.o\fR refers
  to functions in \fBz\fR, those functions may not be loaded.
! .IP "\fB\-lobjc\fR" 4
  .IX Item "-lobjc"
  You need this special case of the \fB\-l\fR option in order to
! link an Objective-C or Objective\-\*(C+ program.
! .IP "\fB\-nostartfiles\fR" 4
  .IX Item "-nostartfiles"
  Do not use the standard system startup files when linking.
  The standard system libraries are used normally, unless \fB\-nostdlib\fR,
  \&\fB\-nolibc\fR, or \fB\-nodefaultlibs\fR is used.
! .IP "\fB\-nodefaultlibs\fR" 4
  .IX Item "-nodefaultlibs"
  Do not use the standard system libraries when linking.
  Only the libraries you specify are passed to the linker, and options
--- 16989,17004 ----
  are specified.  Thus, \fBfoo.o \-lz bar.o\fR searches library \fBz\fR
  after file \fIfoo.o\fR but before \fIbar.o\fR.  If \fIbar.o\fR refers
  to functions in \fBz\fR, those functions may not be loaded.
! .IP \fB\-lobjc\fR 4
  .IX Item "-lobjc"
  You need this special case of the \fB\-l\fR option in order to
! link an Objective\-C or Objective\-C++ program.
! .IP \fB\-nostartfiles\fR 4
  .IX Item "-nostartfiles"
  Do not use the standard system startup files when linking.
  The standard system libraries are used normally, unless \fB\-nostdlib\fR,
  \&\fB\-nolibc\fR, or \fB\-nodefaultlibs\fR is used.
! .IP \fB\-nodefaultlibs\fR 4
  .IX Item "-nodefaultlibs"
  Do not use the standard system libraries when linking.
  Only the libraries you specify are passed to the linker, and options
*************** The compiler may generate calls to \f(CW
*** 17081,17087 ****
  These entries are usually resolved by entries in
  libc.  These entry points should be supplied through some other
  mechanism when this option is specified.
! .IP "\fB\-nolibc\fR" 4
  .IX Item "-nolibc"
  Do not use the C library or system libraries tightly coupled with it when
  linking.  Still link with the startup files, \fIlibgcc\fR or toolchain
--- 17012,17018 ----
  These entries are usually resolved by entries in
  libc.  These entry points should be supplied through some other
  mechanism when this option is specified.
! .IP \fB\-nolibc\fR 4
  .IX Item "-nolibc"
  Do not use the C library or system libraries tightly coupled with it when
  linking.  Still link with the startup files, \fIlibgcc\fR or toolchain
*************** or \fIlibstdc++\fR unless options preven
*** 17090,17098 ****
  well.  This typically removes \fB\-lc\fR from the link command line, as well
  as system libraries that normally go with it and become meaningless when
  absence of a C library is assumed, for example \fB\-lpthread\fR or
! \&\fB\-lm\fR in some configurations.  This is intended for bare-board
  targets when there is indeed no C library available.
! .IP "\fB\-nostdlib\fR" 4
  .IX Item "-nostdlib"
  Do not use the standard system startup files or libraries when linking.
  No startup files and only the libraries you specify are passed to
--- 17021,17029 ----
  well.  This typically removes \fB\-lc\fR from the link command line, as well
  as system libraries that normally go with it and become meaningless when
  absence of a C library is assumed, for example \fB\-lpthread\fR or
! \&\fB\-lm\fR in some configurations.  This is intended for bare\-board
  targets when there is indeed no C library available.
! .IP \fB\-nostdlib\fR 4
  .IX Item "-nostdlib"
  Do not use the standard system startup files or libraries when linking.
  No startup files and only the libraries you specify are passed to
*************** mechanism when this option is specified.
*** 17107,17144 ****
  .Sp
  One of the standard libraries bypassed by \fB\-nostdlib\fR and
  \&\fB\-nodefaultlibs\fR is \fIlibgcc.a\fR, a library of internal subroutines
! which \s-1GCC\s0 uses to overcome shortcomings of particular machines, or special
  needs for some languages.
  .Sp
  In most cases, you need \fIlibgcc.a\fR even when you want to avoid
  other standard libraries.  In other words, when you specify \fB\-nostdlib\fR
  or \fB\-nodefaultlibs\fR you should usually specify \fB\-lgcc\fR as well.
! This ensures that you have no unresolved references to internal \s-1GCC\s0
  library subroutines.
! (An example of such an internal subroutine is \f(CW\*(C`_\|_main\*(C'\fR, used to ensure \*(C+
  constructors are called.)
! .IP "\fB\-nostdlib++\fR" 4
  .IX Item "-nostdlib++"
! Do not implicitly link with standard \*(C+ libraries.
  .IP "\fB\-e\fR \fIentry\fR" 4
  .IX Item "-e entry"
  .PD 0
! .IP "\fB\-\-entry=\fR\fIentry\fR" 4
  .IX Item "--entry=entry"
  .PD
  Specify that the program entry point is \fIentry\fR.  The argument is
! interpreted by the linker; the \s-1GNU\s0 linker accepts either a symbol name
  or an address.
! .IP "\fB\-pie\fR" 4
  .IX Item "-pie"
  Produce a dynamically linked position independent executable on targets
  that support it.  For predictable results, you must also specify the same
  set of options used for compilation (\fB\-fpie\fR, \fB\-fPIE\fR,
  or model suboptions) when you specify this linker option.
! .IP "\fB\-no\-pie\fR" 4
  .IX Item "-no-pie"
! Don't produce a dynamically linked position independent executable.
! .IP "\fB\-static\-pie\fR" 4
  .IX Item "-static-pie"
  Produce a static position independent executable on targets that support
  it.  A static position independent executable is similar to a static
--- 17038,17075 ----
  .Sp
  One of the standard libraries bypassed by \fB\-nostdlib\fR and
  \&\fB\-nodefaultlibs\fR is \fIlibgcc.a\fR, a library of internal subroutines
! which GCC uses to overcome shortcomings of particular machines, or special
  needs for some languages.
  .Sp
  In most cases, you need \fIlibgcc.a\fR even when you want to avoid
  other standard libraries.  In other words, when you specify \fB\-nostdlib\fR
  or \fB\-nodefaultlibs\fR you should usually specify \fB\-lgcc\fR as well.
! This ensures that you have no unresolved references to internal GCC
  library subroutines.
! (An example of such an internal subroutine is \f(CW\*(C`_\|_main\*(C'\fR, used to ensure C++
  constructors are called.)
! .IP \fB\-nostdlib++\fR 4
  .IX Item "-nostdlib++"
! Do not implicitly link with standard C++ libraries.
  .IP "\fB\-e\fR \fIentry\fR" 4
  .IX Item "-e entry"
  .PD 0
! .IP \fB\-\-entry=\fR\fIentry\fR 4
  .IX Item "--entry=entry"
  .PD
  Specify that the program entry point is \fIentry\fR.  The argument is
! interpreted by the linker; the GNU linker accepts either a symbol name
  or an address.
! .IP \fB\-pie\fR 4
  .IX Item "-pie"
  Produce a dynamically linked position independent executable on targets
  that support it.  For predictable results, you must also specify the same
  set of options used for compilation (\fB\-fpie\fR, \fB\-fPIE\fR,
  or model suboptions) when you specify this linker option.
! .IP \fB\-no\-pie\fR 4
  .IX Item "-no-pie"
! Don\*(Aqt produce a dynamically linked position independent executable.
! .IP \fB\-static\-pie\fR 4
  .IX Item "-static-pie"
  Produce a static position independent executable on targets that support
  it.  A static position independent executable is similar to a static
*************** executable, but can be loaded at any add
*** 17146,17188 ****
  For predictable results, you must also specify the same set of options
  used for compilation (\fB\-fpie\fR, \fB\-fPIE\fR, or model
  suboptions) when you specify this linker option.
! .IP "\fB\-pthread\fR" 4
  .IX Item "-pthread"
! Link with the \s-1POSIX\s0 threads library.  This option is supported on 
  GNU/Linux targets, most other Unix derivatives, and also on 
  x86 Cygwin and MinGW targets.  On some targets this option also sets 
  flags for the preprocessor, so it should be used consistently for both
  compilation and linking.
! .IP "\fB\-r\fR" 4
  .IX Item "-r"
  Produce a relocatable object as output.  This is also known as partial
  linking.
! .IP "\fB\-rdynamic\fR" 4
  .IX Item "-rdynamic"
! Pass the flag \fB\-export\-dynamic\fR to the \s-1ELF\s0 linker, on targets
  that support it. This instructs the linker to add all symbols, not
  only used ones, to the dynamic symbol table. This option is needed
  for some uses of \f(CW\*(C`dlopen\*(C'\fR or to allow obtaining backtraces
  from within a program.
! .IP "\fB\-s\fR" 4
  .IX Item "-s"
  Remove all symbol table and relocation information from the executable.
! .IP "\fB\-static\fR" 4
  .IX Item "-static"
  On systems that support dynamic linking, this overrides \fB\-pie\fR
  and prevents linking with the shared libraries.  On other systems, this
  option has no effect.
! .IP "\fB\-shared\fR" 4
  .IX Item "-shared"
  Produce a shared object which can then be linked with other objects to
  form an executable.  Not all systems support this option.  For predictable
  results, you must also specify the same set of options used for compilation
  (\fB\-fpic\fR, \fB\-fPIC\fR, or model suboptions) when
  you specify this linker option.[1]
! .IP "\fB\-shared\-libgcc\fR" 4
  .IX Item "-shared-libgcc"
  .PD 0
! .IP "\fB\-static\-libgcc\fR" 4
  .IX Item "-static-libgcc"
  .PD
  On systems that provide \fIlibgcc\fR as a shared library, these options
--- 17077,17119 ----
  For predictable results, you must also specify the same set of options
  used for compilation (\fB\-fpie\fR, \fB\-fPIE\fR, or model
  suboptions) when you specify this linker option.
! .IP \fB\-pthread\fR 4
  .IX Item "-pthread"
! Link with the POSIX threads library.  This option is supported on 
  GNU/Linux targets, most other Unix derivatives, and also on 
  x86 Cygwin and MinGW targets.  On some targets this option also sets 
  flags for the preprocessor, so it should be used consistently for both
  compilation and linking.
! .IP \fB\-r\fR 4
  .IX Item "-r"
  Produce a relocatable object as output.  This is also known as partial
  linking.
! .IP \fB\-rdynamic\fR 4
  .IX Item "-rdynamic"
! Pass the flag \fB\-export\-dynamic\fR 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 \f(CW\*(C`dlopen\*(C'\fR or to allow obtaining backtraces
  from within a program.
! .IP \fB\-s\fR 4
  .IX Item "-s"
  Remove all symbol table and relocation information from the executable.
! .IP \fB\-static\fR 4
  .IX Item "-static"
  On systems that support dynamic linking, this overrides \fB\-pie\fR
  and prevents linking with the shared libraries.  On other systems, this
  option has no effect.
! .IP \fB\-shared\fR 4
  .IX Item "-shared"
  Produce a shared object which can then be linked with other objects to
  form an executable.  Not all systems support this option.  For predictable
  results, you must also specify the same set of options used for compilation
  (\fB\-fpic\fR, \fB\-fPIC\fR, or model suboptions) when
  you specify this linker option.[1]
! .IP \fB\-shared\-libgcc\fR 4
  .IX Item "-shared-libgcc"
  .PD 0
! .IP \fB\-static\-libgcc\fR 4
  .IX Item "-static-libgcc"
  .PD
  On systems that provide \fIlibgcc\fR as a shared library, these options
*************** across different shared libraries.  In t
*** 17197,17209 ****
  as well as the application itself should use the shared \fIlibgcc\fR.
  .Sp
  Therefore, the G++ driver automatically adds \fB\-shared\-libgcc\fR
! whenever you build a shared library or a main executable, because \*(C+
  programs typically use exceptions, so this is the right thing to do.
  .Sp
! If, instead, you use the \s-1GCC\s0 driver to create shared libraries, you may
  find that they are not always linked with the shared \fIlibgcc\fR.
! If \s-1GCC\s0 finds, at its configuration time, that you have a non-GNU linker
! or a \s-1GNU\s0 linker that does not support option \fB\-\-eh\-frame\-hdr\fR,
  it links the shared version of \fIlibgcc\fR into shared libraries
  by default.  Otherwise, it takes advantage of the linker and optimizes
  away the linking with the shared version of \fIlibgcc\fR, linking with
--- 17128,17140 ----
  as well as the application itself should use the shared \fIlibgcc\fR.
  .Sp
  Therefore, the G++ driver automatically adds \fB\-shared\-libgcc\fR
! whenever you build a shared library or a main executable, because C++
  programs typically use exceptions, so this is the right thing to do.
  .Sp
! If, instead, you use the GCC driver to create shared libraries, you may
  find that they are not always linked with the shared \fIlibgcc\fR.
! If GCC finds, at its configuration time, that you have a non\-GNU linker
! or a GNU linker that does not support option \fB\-\-eh\-frame\-hdr\fR,
  it links the shared version of \fIlibgcc\fR into shared libraries
  by default.  Otherwise, it takes advantage of the linker and optimizes
  away the linking with the shared version of \fIlibgcc\fR, linking with
*************** However, if a library or main executable
*** 17215,17259 ****
  exceptions, you must link it using the G++ driver, or using the option
  \&\fB\-shared\-libgcc\fR, such that it is linked with the shared
  \&\fIlibgcc\fR.
! .IP "\fB\-static\-libasan\fR" 4
  .IX Item "-static-libasan"
  When the \fB\-fsanitize=address\fR option is used to link a program,
! the \s-1GCC\s0 driver automatically links against \fBlibasan\fR.  If
  \&\fIlibasan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibasan\fR.  The \fB\-static\-libasan\fR option directs the \s-1GCC\s0
  driver to link \fIlibasan\fR statically, without necessarily linking
  other libraries statically.
! .IP "\fB\-static\-libtsan\fR" 4
  .IX Item "-static-libtsan"
  When the \fB\-fsanitize=thread\fR option is used to link a program,
! the \s-1GCC\s0 driver automatically links against \fBlibtsan\fR.  If
  \&\fIlibtsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibtsan\fR.  The \fB\-static\-libtsan\fR option directs the \s-1GCC\s0
  driver to link \fIlibtsan\fR statically, without necessarily linking
  other libraries statically.
! .IP "\fB\-static\-liblsan\fR" 4
  .IX Item "-static-liblsan"
  When the \fB\-fsanitize=leak\fR option is used to link a program,
! the \s-1GCC\s0 driver automatically links against \fBliblsan\fR.  If
  \&\fIliblsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIliblsan\fR.  The \fB\-static\-liblsan\fR option directs the \s-1GCC\s0
  driver to link \fIliblsan\fR statically, without necessarily linking
  other libraries statically.
! .IP "\fB\-static\-libubsan\fR" 4
  .IX Item "-static-libubsan"
  When the \fB\-fsanitize=undefined\fR option is used to link a program,
! the \s-1GCC\s0 driver automatically links against \fBlibubsan\fR.  If
  \&\fIlibubsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibubsan\fR.  The \fB\-static\-libubsan\fR option directs the \s-1GCC\s0
  driver to link \fIlibubsan\fR statically, without necessarily linking
  other libraries statically.
! .IP "\fB\-static\-libstdc++\fR" 4
  .IX Item "-static-libstdc++"
! When the \fBg++\fR program is used to link a \*(C+ program, it
  normally automatically links against \fBlibstdc++\fR.  If
  \&\fIlibstdc++\fR is available as a shared library, and the
  \&\fB\-static\fR option is not used, then this links against the
--- 17146,17190 ----
  exceptions, you must link it using the G++ driver, or using the option
  \&\fB\-shared\-libgcc\fR, such that it is linked with the shared
  \&\fIlibgcc\fR.
! .IP \fB\-static\-libasan\fR 4
  .IX Item "-static-libasan"
  When the \fB\-fsanitize=address\fR option is used to link a program,
! the GCC driver automatically links against \fBlibasan\fR.  If
  \&\fIlibasan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibasan\fR.  The \fB\-static\-libasan\fR option directs the GCC
  driver to link \fIlibasan\fR statically, without necessarily linking
  other libraries statically.
! .IP \fB\-static\-libtsan\fR 4
  .IX Item "-static-libtsan"
  When the \fB\-fsanitize=thread\fR option is used to link a program,
! the GCC driver automatically links against \fBlibtsan\fR.  If
  \&\fIlibtsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibtsan\fR.  The \fB\-static\-libtsan\fR option directs the GCC
  driver to link \fIlibtsan\fR statically, without necessarily linking
  other libraries statically.
! .IP \fB\-static\-liblsan\fR 4
  .IX Item "-static-liblsan"
  When the \fB\-fsanitize=leak\fR option is used to link a program,
! the GCC driver automatically links against \fBliblsan\fR.  If
  \&\fIliblsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIliblsan\fR.  The \fB\-static\-liblsan\fR option directs the GCC
  driver to link \fIliblsan\fR statically, without necessarily linking
  other libraries statically.
! .IP \fB\-static\-libubsan\fR 4
  .IX Item "-static-libubsan"
  When the \fB\-fsanitize=undefined\fR option is used to link a program,
! the GCC driver automatically links against \fBlibubsan\fR.  If
  \&\fIlibubsan\fR is available as a shared library, and the \fB\-static\fR
  option is not used, then this links against the shared version of
! \&\fIlibubsan\fR.  The \fB\-static\-libubsan\fR option directs the GCC
  driver to link \fIlibubsan\fR statically, without necessarily linking
  other libraries statically.
! .IP \fB\-static\-libstdc++\fR 4
  .IX Item "-static-libstdc++"
! When the \fBg++\fR program is used to link a C++ program, it
  normally automatically links against \fBlibstdc++\fR.  If
  \&\fIlibstdc++\fR is available as a shared library, and the
  \&\fB\-static\fR option is not used, then this links against the
*************** the program without going all the way to
*** 17263,17269 ****
  \&\fB\-static\-libstdc++\fR option directs the \fBg++\fR driver to
  link \fIlibstdc++\fR statically, without necessarily linking other
  libraries statically.
! .IP "\fB\-symbolic\fR" 4
  .IX Item "-symbolic"
  Bind references to global symbols when building a shared object.  Warn
  about any unresolved references (unless overridden by the link editor
--- 17194,17200 ----
  \&\fB\-static\-libstdc++\fR option directs the \fBg++\fR driver to
  link \fIlibstdc++\fR statically, without necessarily linking other
  libraries statically.
! .IP \fB\-symbolic\fR 4
  .IX Item "-symbolic"
  Bind references to global symbols when building a shared object.  Warn
  about any unresolved references (unless overridden by the link editor
*************** this option.
*** 17272,17305 ****
  .IP "\fB\-T\fR \fIscript\fR" 4
  .IX Item "-T script"
  Use \fIscript\fR as the linker script.  This option is supported by most
! systems using the \s-1GNU\s0 linker.  On some targets, such as bare-board
  targets without an operating system, the \fB\-T\fR option may be required
  when linking to avoid references to undefined symbols.
  .IP "\fB\-Xlinker\fR \fIoption\fR" 4
  .IX Item "-Xlinker option"
  Pass \fIoption\fR as an option to the linker.  You can use this to
! supply system-specific linker options that \s-1GCC\s0 does not recognize.
  .Sp
  If you want to pass an option that takes a separate argument, you must use
  \&\fB\-Xlinker\fR twice, once for the option and once for the argument.
  For example, to pass \fB\-assert definitions\fR, you must write
  \&\fB\-Xlinker \-assert \-Xlinker definitions\fR.  It does not work to write
! \&\fB\-Xlinker \*(L"\-assert definitions\*(R"\fR, because this passes the entire
  string as a single argument, which is not what the linker expects.
  .Sp
! When using the \s-1GNU\s0 linker, it is usually more convenient to pass
  arguments to linker options using the \fIoption\fR\fB=\fR\fIvalue\fR
  syntax than as separate arguments.  For example, you can specify
  \&\fB\-Xlinker \-Map=output.map\fR rather than
  \&\fB\-Xlinker \-Map \-Xlinker output.map\fR.  Other linkers may not support
! this syntax for command-line options.
! .IP "\fB\-Wl,\fR\fIoption\fR" 4
  .IX Item "-Wl,option"
  Pass \fIoption\fR as an option to the linker.  If \fIoption\fR contains
  commas, it is split into multiple options at the commas.  You can use this
  syntax to pass an argument to the option.
  For example, \fB\-Wl,\-Map,output.map\fR passes \fB\-Map output.map\fR to the
! linker.  When using the \s-1GNU\s0 linker, you can also get the same effect with
  \&\fB\-Wl,\-Map=output.map\fR.
  .IP "\fB\-u\fR \fIsymbol\fR" 4
  .IX Item "-u symbol"
--- 17203,17236 ----
  .IP "\fB\-T\fR \fIscript\fR" 4
  .IX Item "-T script"
  Use \fIscript\fR as the linker script.  This option is supported by most
! systems using the GNU linker.  On some targets, such as bare\-board
  targets without an operating system, the \fB\-T\fR option may be required
  when linking to avoid references to undefined symbols.
  .IP "\fB\-Xlinker\fR \fIoption\fR" 4
  .IX Item "-Xlinker option"
  Pass \fIoption\fR as an option to the linker.  You can use this to
! supply system\-specific linker options that GCC does not recognize.
  .Sp
  If you want to pass an option that takes a separate argument, you must use
  \&\fB\-Xlinker\fR twice, once for the option and once for the argument.
  For example, to pass \fB\-assert definitions\fR, you must write
  \&\fB\-Xlinker \-assert \-Xlinker definitions\fR.  It does not work to write
! \&\fB\-Xlinker "\-assert definitions"\fR, because this passes the entire
  string as a single argument, which is not what the linker expects.
  .Sp
! When using the GNU linker, it is usually more convenient to pass
  arguments to linker options using the \fIoption\fR\fB=\fR\fIvalue\fR
  syntax than as separate arguments.  For example, you can specify
  \&\fB\-Xlinker \-Map=output.map\fR rather than
  \&\fB\-Xlinker \-Map \-Xlinker output.map\fR.  Other linkers may not support
! this syntax for command\-line options.
! .IP \fB\-Wl,\fR\fIoption\fR 4
  .IX Item "-Wl,option"
  Pass \fIoption\fR as an option to the linker.  If \fIoption\fR contains
  commas, it is split into multiple options at the commas.  You can use this
  syntax to pass an argument to the option.
  For example, \fB\-Wl,\-Map,output.map\fR passes \fB\-Map output.map\fR to the
! linker.  When using the GNU linker, you can also get the same effect with
  \&\fB\-Wl,\-Map=output.map\fR.
  .IP "\fB\-u\fR \fIsymbol\fR" 4
  .IX Item "-u symbol"
*************** or \f(CW$SYSROOT\fR is replaced by the s
*** 17332,17371 ****
  \&\fB\-\-sysroot\fR and \fB\-isysroot\fR.
  .Sp
  Directories specified with \fB\-iquote\fR apply only to the quote 
! form of the directive, \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.
  Directories specified with \fB\-I\fR, \fB\-isystem\fR, 
  or \fB\-idirafter\fR apply to lookup for both the
! \&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR and
! \&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR directives.
  .Sp
  You can specify any number or combination of these options on the 
  command line to search for header files in several directories.  
  The lookup order is as follows:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  For the quote form of the include directive, the directory of the current
  file is searched first.
! .IP "2." 4
  .IX Item "2."
  For the quote form of the include directive, the directories specified
! by \fB\-iquote\fR options are searched in left-to-right order,
  as they appear on the command line.
! .IP "3." 4
  .IX Item "3."
  Directories specified with \fB\-I\fR options are scanned in
! left-to-right order.
! .IP "4." 4
  .IX Item "4."
  Directories specified with \fB\-isystem\fR options are scanned in
! left-to-right order.
! .IP "5." 4
  .IX Item "5."
  Standard system directories are scanned.
! .IP "6." 4
  .IX Item "6."
  Directories specified with \fB\-idirafter\fR options are scanned in
! left-to-right order.
  .RE
  .RS 4
  .Sp
--- 17263,17302 ----
  \&\fB\-\-sysroot\fR and \fB\-isysroot\fR.
  .Sp
  Directories specified with \fB\-iquote\fR apply only to the quote 
! form of the directive, \f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR.
  Directories specified with \fB\-I\fR, \fB\-isystem\fR, 
  or \fB\-idirafter\fR apply to lookup for both the
! \&\f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR and
! \&\f(CW\*(C`#include\ <\fR\f(CIfile\fR\f(CW>\*(C'\fR directives.
  .Sp
  You can specify any number or combination of these options on the 
  command line to search for header files in several directories.  
  The lookup order is as follows:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  For the quote form of the include directive, the directory of the current
  file is searched first.
! .IP 2. 4
  .IX Item "2."
  For the quote form of the include directive, the directories specified
! by \fB\-iquote\fR options are searched in left\-to\-right order,
  as they appear on the command line.
! .IP 3. 4
  .IX Item "3."
  Directories specified with \fB\-I\fR options are scanned in
! left\-to\-right order.
! .IP 4. 4
  .IX Item "4."
  Directories specified with \fB\-isystem\fR options are scanned in
! left\-to\-right order.
! .IP 5. 4
  .IX Item "5."
  Standard system directories are scanned.
! .IP 6. 4
  .IX Item "6."
  Directories specified with \fB\-idirafter\fR options are scanned in
! left\-to\-right order.
  .RE
  .RS 4
  .Sp
*************** You can use \fB\-I\fR to override a syst
*** 17373,17379 ****
  file, substituting your own version, since these directories are
  searched before the standard system header file directories.  
  However, you should
! not use this option to add directories that contain vendor-supplied
  system header files; use \fB\-isystem\fR for that.
  .Sp
  The \fB\-isystem\fR and \fB\-idirafter\fR options also mark the directory
--- 17304,17310 ----
  file, substituting your own version, since these directories are
  searched before the standard system header file directories.  
  However, you should
! not use this option to add directories that contain vendor\-supplied
  system header files; use \fB\-isystem\fR for that.
  .Sp
  The \fB\-isystem\fR and \fB\-idirafter\fR options also mark the directory
*************** If a standard system include directory,
*** 17384,17396 ****
  \&\fB\-isystem\fR, is also specified with \fB\-I\fR, the \fB\-I\fR
  option is ignored.  The directory is still searched but as a
  system directory at its normal position in the system include chain.
! This is to ensure that \s-1GCC\s0's procedure to fix buggy system headers and
  the ordering for the \f(CW\*(C`#include_next\*(C'\fR directive are not inadvertently
  changed.
  If you really need to change the search order for system directories,
  use the \fB\-nostdinc\fR and/or \fB\-isystem\fR options.
  .RE
! .IP "\fB\-I\-\fR" 4
  .IX Item "-I-"
  Split the include path.
  This option has been deprecated.  Please use \fB\-iquote\fR instead for
--- 17315,17327 ----
  \&\fB\-isystem\fR, is also specified with \fB\-I\fR, the \fB\-I\fR
  option is ignored.  The directory is still searched but as a
  system directory at its normal position in the system include chain.
! This is to ensure that GCC\*(Aqs procedure to fix buggy system headers and
  the ordering for the \f(CW\*(C`#include_next\*(C'\fR directive are not inadvertently
  changed.
  If you really need to change the search order for system directories,
  use the \fB\-nostdinc\fR and/or \fB\-isystem\fR options.
  .RE
! .IP \fB\-I\-\fR 4
  .IX Item "-I-"
  Split the include path.
  This option has been deprecated.  Please use \fB\-iquote\fR instead for
*************** option.
*** 17399,17411 ****
  .Sp
  Any directories specified with \fB\-I\fR
  options before \fB\-I\-\fR are searched only for headers requested with
! \&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
! \&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR.  If additional directories are
  specified with \fB\-I\fR options after the \fB\-I\-\fR, those
  directories are searched for all \fB#include\fR directives.
  .Sp
  In addition, \fB\-I\-\fR inhibits the use of the directory of the current
! file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.  There is no way to override this effect of \fB\-I\-\fR.
  .IP "\fB\-iprefix\fR \fIprefix\fR" 4
  .IX Item "-iprefix prefix"
  Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
--- 17330,17342 ----
  .Sp
  Any directories specified with \fB\-I\fR
  options before \fB\-I\-\fR are searched only for headers requested with
! \&\f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR; they are not searched for
! \&\f(CW\*(C`#include\ <\fR\f(CIfile\fR\f(CW>\*(C'\fR.  If additional directories are
  specified with \fB\-I\fR options after the \fB\-I\-\fR, those
  directories are searched for all \fB#include\fR directives.
  .Sp
  In addition, \fB\-I\-\fR inhibits the use of the directory of the current
! file directory as the first search directory for \f(CW\*(C`#include\ "\fR\f(CIfile\fR\f(CW"\*(C'\fR.  There is no way to override this effect of \fB\-I\-\fR.
  .IP "\fB\-iprefix\fR \fIprefix\fR" 4
  .IX Item "-iprefix prefix"
  Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
*************** information.
*** 17430,17459 ****
  .IP "\fB\-imultilib\fR \fIdir\fR" 4
  .IX Item "-imultilib dir"
  Use \fIdir\fR as a subdirectory of the directory containing
! target-specific \*(C+ headers.
! .IP "\fB\-nostdinc\fR" 4
  .IX Item "-nostdinc"
  Do not search the standard system directories for header files.
  Only the directories explicitly specified with \fB\-I\fR,
  \&\fB\-iquote\fR, \fB\-isystem\fR, and/or \fB\-idirafter\fR
  options (and the directory of the current file, if appropriate) 
  are searched.
! .IP "\fB\-nostdinc++\fR" 4
  .IX Item "-nostdinc++"
! Do not search for header files in the \*(C+\-specific standard directories,
  but do still search the other standard directories.  (This option is
! used when building the \*(C+ library.)
! .IP "\fB\-iplugindir=\fR\fIdir\fR" 4
  .IX Item "-iplugindir=dir"
  Set the directory to search for plugins that are passed
  by \fB\-fplugin=\fR\fIname\fR instead of
  \&\fB\-fplugin=\fR\fIpath\fR\fB/\fR\fIname\fR\fB.so\fR.  This option is not meant
  to be used by the user, but only passed by the driver.
! .IP "\fB\-L\fR\fIdir\fR" 4
  .IX Item "-Ldir"
  Add directory \fIdir\fR to the list of directories to be searched
  for \fB\-l\fR.
! .IP "\fB\-B\fR\fIprefix\fR" 4
  .IX Item "-Bprefix"
  This option specifies where to find the executables, libraries,
  include files, and data files of the compiler itself.
--- 17361,17390 ----
  .IP "\fB\-imultilib\fR \fIdir\fR" 4
  .IX Item "-imultilib dir"
  Use \fIdir\fR as a subdirectory of the directory containing
! target\-specific C++ headers.
! .IP \fB\-nostdinc\fR 4
  .IX Item "-nostdinc"
  Do not search the standard system directories for header files.
  Only the directories explicitly specified with \fB\-I\fR,
  \&\fB\-iquote\fR, \fB\-isystem\fR, and/or \fB\-idirafter\fR
  options (and the directory of the current file, if appropriate) 
  are searched.
! .IP \fB\-nostdinc++\fR 4
  .IX Item "-nostdinc++"
! Do not search for header files in the C++\-specific standard directories,
  but do still search the other standard directories.  (This option is
! used when building the C++ library.)
! .IP \fB\-iplugindir=\fR\fIdir\fR 4
  .IX Item "-iplugindir=dir"
  Set the directory to search for plugins that are passed
  by \fB\-fplugin=\fR\fIname\fR instead of
  \&\fB\-fplugin=\fR\fIpath\fR\fB/\fR\fIname\fR\fB.so\fR.  This option is not meant
  to be used by the user, but only passed by the driver.
! .IP \fB\-L\fR\fIdir\fR 4
  .IX Item "-Ldir"
  Add directory \fIdir\fR to the list of directories to be searched
  for \fB\-l\fR.
! .IP \fB\-B\fR\fIprefix\fR 4
  .IX Item "-Bprefix"
  This option specifies where to find the executables, libraries,
  include files, and data files of the compiler itself.
*************** is not specified, the driver tries two s
*** 17470,17476 ****
  \&\fI/usr/lib/gcc/\fR and \fI/usr/local/lib/gcc/\fR.  If neither of
  those results in a file name that is found, the unmodified program
  name is searched for using the directories specified in your
! \&\fB\s-1PATH\s0\fR environment variable.
  .Sp
  The compiler checks to see if the path provided by \fB\-B\fR
  refers to a directory, and if necessary it adds a directory
--- 17401,17407 ----
  \&\fI/usr/lib/gcc/\fR and \fI/usr/local/lib/gcc/\fR.  If neither of
  those results in a file name that is found, the unmodified program
  name is searched for using the directories specified in your
! \&\fBPATH\fR environment variable.
  .Sp
  The compiler checks to see if the path provided by \fB\-B\fR
  refers to a directory, and if necessary it adds a directory
*************** standard prefixes above are tried, and t
*** 17489,17531 ****
  out of the link if it is not found by those means.
  .Sp
  Another way to specify a prefix much like the \fB\-B\fR prefix is to use
! the environment variable \fB\s-1GCC_EXEC_PREFIX\s0\fR.
  .Sp
  As a special kludge, if the path provided by \fB\-B\fR is
! \&\fI[dir/]stage\fIN\fI/\fR, where \fIN\fR is a number in the range 0 to
  9, then it is replaced by \fI[dir/]include\fR.  This is to help
! with boot-strapping the compiler.
! .IP "\fB\-no\-canonical\-prefixes\fR" 4
  .IX Item "-no-canonical-prefixes"
  Do not expand any symbolic links, resolve references to \fB/../\fR
  or \fB/./\fR, or make the path absolute when generating a relative
  prefix.
! .IP "\fB\-\-sysroot=\fR\fIdir\fR" 4
  .IX Item "--sysroot=dir"
  Use \fIdir\fR as the logical root directory for headers and libraries.
  For example, if the compiler normally searches for headers in
  \&\fI/usr/include\fR and libraries in \fI/usr/lib\fR, it instead
! searches \fI\fIdir\fI/usr/include\fR and \fI\fIdir\fI/usr/lib\fR.
  .Sp
  If you use both this option and the \fB\-isysroot\fR option, then
  the \fB\-\-sysroot\fR option applies to libraries, but the
  \&\fB\-isysroot\fR option applies to header files.
  .Sp
! The \s-1GNU\s0 linker (beginning with version 2.16) has the necessary support
  for this option.  If your linker does not support this option, the
  header file aspect of \fB\-\-sysroot\fR still works, but the
  library aspect does not.
! .IP "\fB\-\-no\-sysroot\-suffix\fR" 4
  .IX Item "--no-sysroot-suffix"
  For some targets, a suffix is added to the root directory specified
  with \fB\-\-sysroot\fR, depending on the other options used, so that
  headers may for example be found in
! \&\fI\fIdir\fI/\fIsuffix\fI/usr/include\fR instead of
! \&\fI\fIdir\fI/usr/include\fR.  This option disables the addition of
  such a suffix.
  .SS "Options for Code Generation Conventions"
  .IX Subsection "Options for Code Generation Conventions"
! These machine-independent options control the interface conventions
  used in code generation.
  .PP
  Most of them have both positive and negative forms; the negative form
--- 17420,17462 ----
  out of the link if it is not found by those means.
  .Sp
  Another way to specify a prefix much like the \fB\-B\fR prefix is to use
! the environment variable \fBGCC_EXEC_PREFIX\fR.
  .Sp
  As a special kludge, if the path provided by \fB\-B\fR is
! \&\fI[dir/]stageN/\fR, where \fIN\fR is a number in the range 0 to
  9, then it is replaced by \fI[dir/]include\fR.  This is to help
! with boot\-strapping the compiler.
! .IP \fB\-no\-canonical\-prefixes\fR 4
  .IX Item "-no-canonical-prefixes"
  Do not expand any symbolic links, resolve references to \fB/../\fR
  or \fB/./\fR, or make the path absolute when generating a relative
  prefix.
! .IP \fB\-\-sysroot=\fR\fIdir\fR 4
  .IX Item "--sysroot=dir"
  Use \fIdir\fR as the logical root directory for headers and libraries.
  For example, if the compiler normally searches for headers in
  \&\fI/usr/include\fR and libraries in \fI/usr/lib\fR, it instead
! searches \fIdir/usr/include\fR and \fIdir/usr/lib\fR.
  .Sp
  If you use both this option and the \fB\-isysroot\fR option, then
  the \fB\-\-sysroot\fR option applies to libraries, but the
  \&\fB\-isysroot\fR option applies to header files.
  .Sp
! The 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 \fB\-\-sysroot\fR still works, but the
  library aspect does not.
! .IP \fB\-\-no\-sysroot\-suffix\fR 4
  .IX Item "--no-sysroot-suffix"
  For some targets, a suffix is added to the root directory specified
  with \fB\-\-sysroot\fR, depending on the other options used, so that
  headers may for example be found in
! \&\fIdir/suffix/usr/include\fR instead of
! \&\fIdir/usr/include\fR.  This option disables the addition of
  such a suffix.
  .SS "Options for Code Generation Conventions"
  .IX Subsection "Options for Code Generation Conventions"
! These machine\-independent options control the interface conventions
  used in code generation.
  .PP
  Most of them have both positive and negative forms; the negative form
*************** of \fB\-ffoo\fR is \fB\-fno\-foo\fR.  In
*** 17533,17539 ****
  one of the forms is listed\-\-\-the one that is not the default.  You
  can figure out the other form by either removing \fBno\-\fR or adding
  it.
! .IP "\fB\-fstack\-reuse=\fR\fIreuse-level\fR" 4
  .IX Item "-fstack-reuse=reuse-level"
  This option controls stack space reuse for user declared local/auto variables
  and compiler generated temporaries.  \fIreuse_level\fR can be \fBall\fR,
--- 17464,17470 ----
  one of the forms is listed\-\-\-the one that is not the default.  You
  can figure out the other form by either removing \fBno\-\fR or adding
  it.
! .IP \fB\-fstack\-reuse=\fR\fIreuse\-level\fR 4
  .IX Item "-fstack-reuse=reuse-level"
  This option controls stack space reuse for user declared local/auto variables
  and compiler generated temporaries.  \fIreuse_level\fR can be \fBall\fR,
*************** Another example:
*** 17601,17689 ****
  \&           }
  .Ve
  .Sp
! The lifetime of a compiler generated temporary is well defined by the \*(C+
  standard. When a lifetime of a temporary ends, and if the temporary lives
  in memory, the optimizing compiler has the freedom to reuse its stack
  space with other temporaries or scoped local variables whose live range
  does not overlap with it. However some of the legacy code relies on
! the behavior of older compilers in which temporaries' stack space is
  not reused, the aggressive stack reuse can lead to runtime errors. This
  option is used to control the temporary stack reuse optimization.
! .IP "\fB\-ftrapv\fR" 4
  .IX Item "-ftrapv"
  This option generates traps for signed overflow on addition, subtraction,
  multiplication operations.
  The options \fB\-ftrapv\fR and \fB\-fwrapv\fR override each other, so using
! \&\fB\-ftrapv\fR \fB\-fwrapv\fR on the command-line results in
  \&\fB\-fwrapv\fR being effective.  Note that only active options override, so
! using \fB\-ftrapv\fR \fB\-fwrapv\fR \fB\-fno\-wrapv\fR on the command-line
  results in \fB\-ftrapv\fR being effective.
! .IP "\fB\-fwrapv\fR" 4
  .IX Item "-fwrapv"
  This option instructs the compiler to assume that signed arithmetic
  overflow of addition, subtraction and multiplication wraps around
! using twos-complement representation.  This flag enables some optimizations
  and disables others.
  The options \fB\-ftrapv\fR and \fB\-fwrapv\fR override each other, so using
! \&\fB\-ftrapv\fR \fB\-fwrapv\fR on the command-line results in
  \&\fB\-fwrapv\fR being effective.  Note that only active options override, so
! using \fB\-ftrapv\fR \fB\-fwrapv\fR \fB\-fno\-wrapv\fR on the command-line
  results in \fB\-ftrapv\fR being effective.
! .IP "\fB\-fwrapv\-pointer\fR" 4
  .IX Item "-fwrapv-pointer"
  This option instructs the compiler to assume that pointer arithmetic
! overflow on addition and subtraction wraps around using twos-complement
  representation.  This flag disables some optimizations which assume
  pointer overflow is invalid.
! .IP "\fB\-fstrict\-overflow\fR" 4
  .IX Item "-fstrict-overflow"
  This option implies \fB\-fno\-wrapv\fR \fB\-fno\-wrapv\-pointer\fR and when
  negated implies \fB\-fwrapv\fR \fB\-fwrapv\-pointer\fR.
! .IP "\fB\-fexceptions\fR" 4
  .IX Item "-fexceptions"
  Enable exception handling.  Generates extra code needed to propagate
! exceptions.  For some targets, this implies \s-1GCC\s0 generates frame
  unwind information for all functions, which can produce significant data
  size overhead, although it does not affect execution.  If you do not
! specify this option, \s-1GCC\s0 enables it by default for languages like
! \&\*(C+ that normally require exception handling, and disables it for
  languages like C that do not normally require it.  However, you may need
  to enable this option when compiling C code that needs to interoperate
! properly with exception handlers written in \*(C+.  You may also wish to
! disable this option if you are compiling older \*(C+ programs that don't
  use exception handling.
! .IP "\fB\-fnon\-call\-exceptions\fR" 4
  .IX Item "-fnon-call-exceptions"
  Generate code that allows trapping instructions to throw exceptions.
! Note that this requires platform-specific runtime support that does
  not exist everywhere.  Moreover, it only allows \fItrapping\fR
! instructions to throw exceptions, i.e. memory references or floating-point
  instructions.  It does not allow exceptions to be thrown from
  arbitrary signal handlers such as \f(CW\*(C`SIGALRM\*(C'\fR.  This enables
  \&\fB\-fexceptions\fR.
! .IP "\fB\-fdelete\-dead\-exceptions\fR" 4
  .IX Item "-fdelete-dead-exceptions"
! Consider that instructions that may throw exceptions but don't otherwise
  contribute to the execution of the program can be optimized away.
  This does not affect calls to functions except those with the
  \&\f(CW\*(C`pure\*(C'\fR or \f(CW\*(C`const\*(C'\fR attributes.
! This option is enabled by default for the Ada and \*(C+ compilers, as permitted by
  the language specifications.
  Optimization passes that cause dead exceptions to be removed are enabled independently at different optimization levels.
! .IP "\fB\-funwind\-tables\fR" 4
  .IX Item "-funwind-tables"
  Similar to \fB\-fexceptions\fR, except that it just generates any needed
  static data, but does not affect the generated code in any other way.
  You normally do not need to enable this option; instead, a language processor
  that needs this handling enables it on your behalf.
! .IP "\fB\-fasynchronous\-unwind\-tables\fR" 4
  .IX Item "-fasynchronous-unwind-tables"
! Generate unwind table in \s-1DWARF\s0 format, if supported by target machine.  The
  table is exact at each instruction boundary, so it can be used for stack
  unwinding from asynchronous events (such as debugger or garbage collector).
! .IP "\fB\-fno\-gnu\-unique\fR" 4
  .IX Item "-fno-gnu-unique"
! On systems with recent \s-1GNU\s0 assembler and C library, the \*(C+ compiler
  uses the \f(CW\*(C`STB_GNU_UNIQUE\*(C'\fR binding to make sure that definitions
  of template static data members and static local variables in inline
  functions are unique even in the presence of \f(CW\*(C`RTLD_LOCAL\*(C'\fR; this
--- 17532,17620 ----
  \&           }
  .Ve
  .Sp
! The lifetime of a compiler generated temporary is well defined by the C++
  standard. When a lifetime of a temporary ends, and if the temporary lives
  in memory, the optimizing compiler has the freedom to reuse its stack
  space with other temporaries or scoped local variables whose live range
  does not overlap with it. However some of the legacy code relies on
! the behavior of older compilers in which temporaries\*(Aq stack space is
  not reused, the aggressive stack reuse can lead to runtime errors. This
  option is used to control the temporary stack reuse optimization.
! .IP \fB\-ftrapv\fR 4
  .IX Item "-ftrapv"
  This option generates traps for signed overflow on addition, subtraction,
  multiplication operations.
  The options \fB\-ftrapv\fR and \fB\-fwrapv\fR override each other, so using
! \&\fB\-ftrapv\fR \fB\-fwrapv\fR on the command\-line results in
  \&\fB\-fwrapv\fR being effective.  Note that only active options override, so
! using \fB\-ftrapv\fR \fB\-fwrapv\fR \fB\-fno\-wrapv\fR on the command\-line
  results in \fB\-ftrapv\fR being effective.
! .IP \fB\-fwrapv\fR 4
  .IX Item "-fwrapv"
  This option instructs the compiler to assume that signed arithmetic
  overflow of addition, subtraction and multiplication wraps around
! using twos\-complement representation.  This flag enables some optimizations
  and disables others.
  The options \fB\-ftrapv\fR and \fB\-fwrapv\fR override each other, so using
! \&\fB\-ftrapv\fR \fB\-fwrapv\fR on the command\-line results in
  \&\fB\-fwrapv\fR being effective.  Note that only active options override, so
! using \fB\-ftrapv\fR \fB\-fwrapv\fR \fB\-fno\-wrapv\fR on the command\-line
  results in \fB\-ftrapv\fR being effective.
! .IP \fB\-fwrapv\-pointer\fR 4
  .IX Item "-fwrapv-pointer"
  This option instructs the compiler to assume that pointer arithmetic
! overflow on addition and subtraction wraps around using twos\-complement
  representation.  This flag disables some optimizations which assume
  pointer overflow is invalid.
! .IP \fB\-fstrict\-overflow\fR 4
  .IX Item "-fstrict-overflow"
  This option implies \fB\-fno\-wrapv\fR \fB\-fno\-wrapv\-pointer\fR and when
  negated implies \fB\-fwrapv\fR \fB\-fwrapv\-pointer\fR.
! .IP \fB\-fexceptions\fR 4
  .IX Item "-fexceptions"
  Enable exception handling.  Generates extra code needed to propagate
! exceptions.  For some targets, this implies GCC generates frame
  unwind information for all functions, which can produce significant data
  size overhead, although it does not affect execution.  If you do not
! specify this option, GCC enables it by default for languages like
! C++ that normally require exception handling, and disables it for
  languages like C that do not normally require it.  However, you may need
  to enable this option when compiling C code that needs to interoperate
! properly with exception handlers written in C++.  You may also wish to
! disable this option if you are compiling older C++ programs that don\*(Aqt
  use exception handling.
! .IP \fB\-fnon\-call\-exceptions\fR 4
  .IX Item "-fnon-call-exceptions"
  Generate code that allows trapping instructions to throw exceptions.
! Note that this requires platform\-specific runtime support that does
  not exist everywhere.  Moreover, it only allows \fItrapping\fR
! instructions to throw exceptions, i.e. memory references or floating\-point
  instructions.  It does not allow exceptions to be thrown from
  arbitrary signal handlers such as \f(CW\*(C`SIGALRM\*(C'\fR.  This enables
  \&\fB\-fexceptions\fR.
! .IP \fB\-fdelete\-dead\-exceptions\fR 4
  .IX Item "-fdelete-dead-exceptions"
! Consider that instructions that may throw exceptions but don\*(Aqt otherwise
  contribute to the execution of the program can be optimized away.
  This does not affect calls to functions except those with the
  \&\f(CW\*(C`pure\*(C'\fR or \f(CW\*(C`const\*(C'\fR attributes.
! This option is enabled by default for the Ada and C++ compilers, as permitted by
  the language specifications.
  Optimization passes that cause dead exceptions to be removed are enabled independently at different optimization levels.
! .IP \fB\-funwind\-tables\fR 4
  .IX Item "-funwind-tables"
  Similar to \fB\-fexceptions\fR, except that it just generates any needed
  static data, but does not affect the generated code in any other way.
  You normally do not need to enable this option; instead, a language processor
  that needs this handling enables it on your behalf.
! .IP \fB\-fasynchronous\-unwind\-tables\fR 4
  .IX Item "-fasynchronous-unwind-tables"
! Generate unwind table in DWARF format, if supported by target machine.  The
  table is exact at each instruction boundary, so it can be used for stack
  unwinding from asynchronous events (such as debugger or garbage collector).
! .IP \fB\-fno\-gnu\-unique\fR 4
  .IX Item "-fno-gnu-unique"
! On systems with recent GNU assembler and C library, the C++ compiler
  uses the \f(CW\*(C`STB_GNU_UNIQUE\*(C'\fR binding to make sure that definitions
  of template static data members and static local variables in inline
  functions are unique even in the presence of \f(CW\*(C`RTLD_LOCAL\*(C'\fR; this
*************** is necessary to avoid problems with a li
*** 17691,17705 ****
  \&\f(CW\*(C`RTLD_LOCAL\*(C'\fR plugins depending on a definition in one of them and
  therefore disagreeing with the other one about the binding of the
  symbol.  But this causes \f(CW\*(C`dlclose\*(C'\fR to be ignored for affected
! DSOs; if your program relies on reinitialization of a \s-1DSO\s0 via
  \&\f(CW\*(C`dlclose\*(C'\fR and \f(CW\*(C`dlopen\*(C'\fR, you can use
  \&\fB\-fno\-gnu\-unique\fR.
! .IP "\fB\-fpcc\-struct\-return\fR" 4
  .IX Item "-fpcc-struct-return"
! Return \*(L"short\*(R" \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in memory like
  longer ones, rather than in registers.  This convention is less
  efficient, but it has the advantage of allowing intercallability between
! GCC-compiled files and files compiled with other compilers, particularly
  the Portable C Compiler (pcc).
  .Sp
  The precise convention for returning structures in memory depends
--- 17622,17636 ----
  \&\f(CW\*(C`RTLD_LOCAL\*(C'\fR plugins depending on a definition in one of them and
  therefore disagreeing with the other one about the binding of the
  symbol.  But this causes \f(CW\*(C`dlclose\*(C'\fR to be ignored for affected
! DSOs; if your program relies on reinitialization of a DSO via
  \&\f(CW\*(C`dlclose\*(C'\fR and \f(CW\*(C`dlopen\*(C'\fR, you can use
  \&\fB\-fno\-gnu\-unique\fR.
! .IP \fB\-fpcc\-struct\-return\fR 4
  .IX Item "-fpcc-struct-return"
! Return "short" \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in memory like
  longer ones, rather than in registers.  This convention is less
  efficient, but it has the advantage of allowing intercallability between
! GCC\-compiled files and files compiled with other compilers, particularly
  the Portable C Compiler (pcc).
  .Sp
  The precise convention for returning structures in memory depends
*************** that of some integer type.
*** 17711,17753 ****
  \&\fBWarning:\fR code compiled with the \fB\-fpcc\-struct\-return\fR
  switch is not binary compatible with code compiled with the
  \&\fB\-freg\-struct\-return\fR switch.
! Use it to conform to a non-default application binary interface.
! .IP "\fB\-freg\-struct\-return\fR" 4
  .IX Item "-freg-struct-return"
  Return \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in registers when possible.
  This is more efficient for small structures than
  \&\fB\-fpcc\-struct\-return\fR.
  .Sp
  If you specify neither \fB\-fpcc\-struct\-return\fR nor
! \&\fB\-freg\-struct\-return\fR, \s-1GCC\s0 defaults to whichever convention is
! standard for the target.  If there is no standard convention, \s-1GCC\s0
! defaults to \fB\-fpcc\-struct\-return\fR, except on targets where \s-1GCC\s0 is
  the principal compiler.  In those cases, we can choose the standard, and
  we chose the more efficient register return alternative.
  .Sp
  \&\fBWarning:\fR code compiled with the \fB\-freg\-struct\-return\fR
  switch is not binary compatible with code compiled with the
  \&\fB\-fpcc\-struct\-return\fR switch.
! Use it to conform to a non-default application binary interface.
! .IP "\fB\-fshort\-enums\fR" 4
  .IX Item "-fshort-enums"
  Allocate to an \f(CW\*(C`enum\*(C'\fR type only as many bytes as it needs for the
  declared range of possible values.  Specifically, the \f(CW\*(C`enum\*(C'\fR type
  is equivalent to the smallest integer type that has enough room.
  .Sp
! \&\fBWarning:\fR the \fB\-fshort\-enums\fR switch causes \s-1GCC\s0 to generate
  code that is not binary compatible with code generated without that switch.
! Use it to conform to a non-default application binary interface.
! .IP "\fB\-fshort\-wchar\fR" 4
  .IX Item "-fshort-wchar"
  Override the underlying type for \f(CW\*(C`wchar_t\*(C'\fR to be \f(CW\*(C`short
  unsigned int\*(C'\fR instead of the default for the target.  This option is
! useful for building programs to run under \s-1WINE.\s0
  .Sp
! \&\fBWarning:\fR the \fB\-fshort\-wchar\fR switch causes \s-1GCC\s0 to generate
  code that is not binary compatible with code generated without that switch.
! Use it to conform to a non-default application binary interface.
! .IP "\fB\-fcommon\fR" 4
  .IX Item "-fcommon"
  In C code, this option controls the placement of global variables
  defined without an initializer, known as \fItentative definitions\fR
--- 17642,17684 ----
  \&\fBWarning:\fR code compiled with the \fB\-fpcc\-struct\-return\fR
  switch is not binary compatible with code compiled with the
  \&\fB\-freg\-struct\-return\fR switch.
! Use it to conform to a non\-default application binary interface.
! .IP \fB\-freg\-struct\-return\fR 4
  .IX Item "-freg-struct-return"
  Return \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in registers when possible.
  This is more efficient for small structures than
  \&\fB\-fpcc\-struct\-return\fR.
  .Sp
  If you specify neither \fB\-fpcc\-struct\-return\fR nor
! \&\fB\-freg\-struct\-return\fR, GCC defaults to whichever convention is
! standard for the target.  If there is no standard convention, GCC
! defaults to \fB\-fpcc\-struct\-return\fR, 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.
  .Sp
  \&\fBWarning:\fR code compiled with the \fB\-freg\-struct\-return\fR
  switch is not binary compatible with code compiled with the
  \&\fB\-fpcc\-struct\-return\fR switch.
! Use it to conform to a non\-default application binary interface.
! .IP \fB\-fshort\-enums\fR 4
  .IX Item "-fshort-enums"
  Allocate to an \f(CW\*(C`enum\*(C'\fR type only as many bytes as it needs for the
  declared range of possible values.  Specifically, the \f(CW\*(C`enum\*(C'\fR type
  is equivalent to the smallest integer type that has enough room.
  .Sp
! \&\fBWarning:\fR the \fB\-fshort\-enums\fR switch causes 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.
! .IP \fB\-fshort\-wchar\fR 4
  .IX Item "-fshort-wchar"
  Override the underlying type for \f(CW\*(C`wchar_t\*(C'\fR to be \f(CW\*(C`short
  unsigned int\*(C'\fR instead of the default for the target.  This option is
! useful for building programs to run under WINE.
  .Sp
! \&\fBWarning:\fR the \fB\-fshort\-wchar\fR 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.
! .IP \fB\-fcommon\fR 4
  .IX Item "-fcommon"
  In C code, this option controls the placement of global variables
  defined without an initializer, known as \fItentative definitions\fR
*************** in the C standard.  Tentative definition
*** 17755,17782 ****
  of a variable with the \f(CW\*(C`extern\*(C'\fR keyword, which do not allocate storage.
  .Sp
  The default is \fB\-fno\-common\fR, which specifies that the compiler places
! uninitialized global variables in the \s-1BSS\s0 section of the object file.
  This inhibits the merging of tentative definitions by the linker so you get a
! multiple-definition error if the same variable is accidentally defined in more
  than one compilation unit.
  .Sp
  The \fB\-fcommon\fR places uninitialized global variables in a common block.
  This allows the linker to resolve all tentative definitions of the same variable
! in different compilation units to the same object, or to a non-tentative
! definition.  This behavior is inconsistent with \*(C+, and on many targets implies
  a speed and code size penalty on global variable references.  It is mainly
  useful to enable legacy code to link without errors.
! .IP "\fB\-fno\-ident\fR" 4
  .IX Item "-fno-ident"
  Ignore the \f(CW\*(C`#ident\*(C'\fR directive.
! .IP "\fB\-finhibit\-size\-directive\fR" 4
  .IX Item "-finhibit-size-directive"
! Don't output a \f(CW\*(C`.size\*(C'\fR assembler directive, or anything else that
  would cause trouble if the function is split in the middle, and the
  two halves are placed at locations far apart in memory.  This option is
  used when compiling \fIcrtstuff.c\fR; you should not need to use it
  for anything else.
! .IP "\fB\-fverbose\-asm\fR" 4
  .IX Item "-fverbose-asm"
  Put extra commentary information in the generated assembly code to
  make it more readable.  This option is generally only of use to those
--- 17686,17713 ----
  of a variable with the \f(CW\*(C`extern\*(C'\fR keyword, which do not allocate storage.
  .Sp
  The default is \fB\-fno\-common\fR, which specifies that the compiler places
! uninitialized global variables in the BSS section of the object file.
  This inhibits the merging of tentative definitions by the linker so you get a
! multiple\-definition error if the same variable is accidentally defined in more
  than one compilation unit.
  .Sp
  The \fB\-fcommon\fR places uninitialized global variables in a common block.
  This allows the linker to resolve all tentative definitions of the same variable
! in different compilation units to the same object, or to a non\-tentative
! definition.  This behavior is inconsistent with C++, and on many targets implies
  a speed and code size penalty on global variable references.  It is mainly
  useful to enable legacy code to link without errors.
! .IP \fB\-fno\-ident\fR 4
  .IX Item "-fno-ident"
  Ignore the \f(CW\*(C`#ident\*(C'\fR directive.
! .IP \fB\-finhibit\-size\-directive\fR 4
  .IX Item "-finhibit-size-directive"
! Don\*(Aqt output a \f(CW\*(C`.size\*(C'\fR assembler directive, or anything else that
  would cause trouble if the function is split in the middle, and the
  two halves are placed at locations far apart in memory.  This option is
  used when compiling \fIcrtstuff.c\fR; you should not need to use it
  for anything else.
! .IP \fB\-fverbose\-asm\fR 4
  .IX Item "-fverbose-asm"
  Put extra commentary information in the generated assembly code to
  make it more readable.  This option is generally only of use to those
*************** files.
*** 17789,17801 ****
  .Sp
  The added comments include:
  .RS 4
! .IP "*" 4
! information on the compiler version and command-line options,
! .IP "*" 4
  the source code lines associated with the assembly instructions,
! in the form \s-1FILENAME:LINENUMBER:CONTENT OF LINE,\s0
! .IP "*" 4
! hints on which high-level expressions correspond to
  the various assembly instruction operands.
  .RE
  .RS 4
--- 17720,17732 ----
  .Sp
  The added comments include:
  .RS 4
! .IP * 4
! information on the compiler version and command\-line options,
! .IP * 4
  the source code lines associated with the assembly instructions,
! in the form FILENAME:LINENUMBER:CONTENT OF LINE,
! .IP * 4
! hints on which high\-level expressions correspond to
  the various assembly instruction operands.
  .RE
  .RS 4
*************** gives output similar to this:
*** 17866,17970 ****
  The comments are intended for humans rather than machines and hence the
  precise format of the comments is subject to change.
  .RE
! .IP "\fB\-frecord\-gcc\-switches\fR" 4
  .IX Item "-frecord-gcc-switches"
  This switch causes the command line used to invoke the
  compiler to be recorded into the object file that is being created.
  This switch is only implemented on some targets and the exact format
  of the recording is target and binary file format dependent, but it
! usually takes the form of a section containing \s-1ASCII\s0 text.  This
  switch is related to the \fB\-fverbose\-asm\fR switch, but that
  switch only records information in the assembler output file as
  comments, so it never reaches the object file.
  See also \fB\-grecord\-gcc\-switches\fR for another
  way of storing compiler options into the object file.
! .IP "\fB\-fpic\fR" 4
  .IX Item "-fpic"
! Generate position-independent code (\s-1PIC\s0) suitable for use in a shared
  library, if supported for the target machine.  Such code accesses all
! constant addresses through a global offset table (\s-1GOT\s0).  The dynamic
! loader resolves the \s-1GOT\s0 entries when the program starts (the dynamic
! loader is not part of \s-1GCC\s0; it is part of the operating system).  If
! the \s-1GOT\s0 size for the linked executable exceeds a machine-specific
  maximum size, you get an error message from the linker indicating that
  \&\fB\-fpic\fR does not work; in that case, recompile with \fB\-fPIC\fR
! instead.  (These maximums are 8k on the \s-1SPARC,\s0 28k on AArch64 and 32k
! on the m68k and \s-1RS/6000.\s0  The x86 has no such limit.)
  .Sp
! Position-independent code requires special support, and therefore works
! only on certain machines.  For the x86, \s-1GCC\s0 supports \s-1PIC\s0 for System V
! but not for the Sun 386i.  Code generated for the \s-1IBM RS/6000\s0 is always
! position-independent.
  .Sp
  When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
  are defined to 1.
! .IP "\fB\-fPIC\fR" 4
  .IX Item "-fPIC"
! If supported for the target machine, emit position-independent code,
  suitable for dynamic linking and avoiding any limit on the size of the
  global offset table.  This option makes a difference on AArch64, m68k,
! PowerPC and \s-1SPARC.\s0
  .Sp
! Position-independent code requires special support, and therefore works
  only on certain machines.
  .Sp
  When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
  are defined to 2.
! .IP "\fB\-fpie\fR" 4
  .IX Item "-fpie"
  .PD 0
! .IP "\fB\-fPIE\fR" 4
  .IX Item "-fPIE"
  .PD
  These options are similar to \fB\-fpic\fR and \fB\-fPIC\fR, but the
! generated position-independent code can be only linked into executables.
  Usually these options are used to compile code that will be linked using
! the \fB\-pie\fR \s-1GCC\s0 option.
  .Sp
  \&\fB\-fpie\fR and \fB\-fPIE\fR both define the macros
  \&\f(CW\*(C`_\|_pie_\|_\*(C'\fR and \f(CW\*(C`_\|_PIE_\|_\*(C'\fR.  The macros have the value 1
  for \fB\-fpie\fR and 2 for \fB\-fPIE\fR.
! .IP "\fB\-fno\-plt\fR" 4
  .IX Item "-fno-plt"
! Do not use the \s-1PLT\s0 for external function calls in position-independent code.
! Instead, load the callee address at call sites from the \s-1GOT\s0 and branch to it.
! This leads to more efficient code by eliminating \s-1PLT\s0 stubs and exposing
! \&\s-1GOT\s0 loads to optimizations.  On architectures such as 32\-bit x86 where
! \&\s-1PLT\s0 stubs expect the \s-1GOT\s0 pointer in a specific register, this gives more
  register allocation freedom to the compiler.
! Lazy binding requires use of the \s-1PLT\s0; 
  with \fB\-fno\-plt\fR all external symbols are resolved at load time.
  .Sp
  Alternatively, the function attribute \f(CW\*(C`noplt\*(C'\fR can be used to avoid calls
! through the \s-1PLT\s0 for specific external functions.
  .Sp
! In position-dependent code, a few targets also convert calls to
! functions that are marked to not use the \s-1PLT\s0 to use the \s-1GOT\s0 instead.
! .IP "\fB\-fno\-jump\-tables\fR" 4
  .IX Item "-fno-jump-tables"
  Do not use jump tables for switch statements even where it would be
  more efficient than other code generation strategies.  This option is
  of use in conjunction with \fB\-fpic\fR or \fB\-fPIC\fR for
  building code that forms part of a dynamic linker and cannot
  reference the address of a jump table.  On some targets, jump tables
! do not require a \s-1GOT\s0 and this option is not needed.
! .IP "\fB\-fno\-bit\-tests\fR" 4
  .IX Item "-fno-bit-tests"
  Do not use bit tests for switch statements even where it would be
  more efficient than other code generation strategies.
! .IP "\fB\-ffixed\-\fR\fIreg\fR" 4
  .IX Item "-ffixed-reg"
  Treat the register named \fIreg\fR as a fixed register; generated code
  should never refer to it (except perhaps as a stack pointer, frame
  pointer or in some other fixed role).
  .Sp
  \&\fIreg\fR must be the name of a register.  The register names accepted
! are machine-specific and are defined in the \f(CW\*(C`REGISTER_NAMES\*(C'\fR
  macro in the machine description macro file.
  .Sp
  This flag does not have a negative form, because it specifies a
! three-way choice.
! .IP "\fB\-fcall\-used\-\fR\fIreg\fR" 4
  .IX Item "-fcall-used-reg"
  Treat the register named \fIreg\fR as an allocable register that is
  clobbered by function calls.  It may be allocated for temporaries or
--- 17797,17901 ----
  The comments are intended for humans rather than machines and hence the
  precise format of the comments is subject to change.
  .RE
! .IP \fB\-frecord\-gcc\-switches\fR 4
  .IX Item "-frecord-gcc-switches"
  This switch causes the command line used to invoke the
  compiler to be recorded into the object file that is being created.
  This switch is only implemented on some targets and the exact format
  of the recording is target and binary file format dependent, but it
! usually takes the form of a section containing ASCII text.  This
  switch is related to the \fB\-fverbose\-asm\fR switch, but that
  switch only records information in the assembler output file as
  comments, so it never reaches the object file.
  See also \fB\-grecord\-gcc\-switches\fR for another
  way of storing compiler options into the object file.
! .IP \fB\-fpic\fR 4
  .IX Item "-fpic"
! Generate position\-independent code (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
  \&\fB\-fpic\fR does not work; in that case, recompile with \fB\-fPIC\fR
! instead.  (These maximums are 8k on the SPARC, 28k on AArch64 and 32k
! on the m68k and RS/6000.  The x86 has no such limit.)
  .Sp
! Position\-independent code requires special support, and therefore works
! only on certain machines.  For the x86, GCC supports PIC for System V
! but not for the Sun 386i.  Code generated for the IBM RS/6000 is always
! position\-independent.
  .Sp
  When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
  are defined to 1.
! .IP \fB\-fPIC\fR 4
  .IX Item "-fPIC"
! If supported for the target machine, emit position\-independent code,
  suitable for dynamic linking and avoiding any limit on the size of the
  global offset table.  This option makes a difference on AArch64, m68k,
! PowerPC and SPARC.
  .Sp
! Position\-independent code requires special support, and therefore works
  only on certain machines.
  .Sp
  When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
  are defined to 2.
! .IP \fB\-fpie\fR 4
  .IX Item "-fpie"
  .PD 0
! .IP \fB\-fPIE\fR 4
  .IX Item "-fPIE"
  .PD
  These options are similar to \fB\-fpic\fR and \fB\-fPIC\fR, but the
! generated position\-independent code can be only linked into executables.
  Usually these options are used to compile code that will be linked using
! the \fB\-pie\fR GCC option.
  .Sp
  \&\fB\-fpie\fR and \fB\-fPIE\fR both define the macros
  \&\f(CW\*(C`_\|_pie_\|_\*(C'\fR and \f(CW\*(C`_\|_PIE_\|_\*(C'\fR.  The macros have the value 1
  for \fB\-fpie\fR and 2 for \fB\-fPIE\fR.
! .IP \fB\-fno\-plt\fR 4
  .IX Item "-fno-plt"
! Do not use the PLT for external function calls in position\-independent code.
! Instead, load the callee address at call sites from the GOT and branch to it.
! This leads to more efficient code by eliminating PLT stubs and exposing
! GOT loads to optimizations.  On architectures such as 32\-bit x86 where
! PLT stubs expect the GOT pointer in a specific register, this gives more
  register allocation freedom to the compiler.
! Lazy binding requires use of the PLT; 
  with \fB\-fno\-plt\fR all external symbols are resolved at load time.
  .Sp
  Alternatively, the function attribute \f(CW\*(C`noplt\*(C'\fR can be used to avoid calls
! through the PLT for specific external functions.
  .Sp
! In position\-dependent code, a few targets also convert calls to
! functions that are marked to not use the PLT to use the GOT instead.
! .IP \fB\-fno\-jump\-tables\fR 4
  .IX Item "-fno-jump-tables"
  Do not use jump tables for switch statements even where it would be
  more efficient than other code generation strategies.  This option is
  of use in conjunction with \fB\-fpic\fR or \fB\-fPIC\fR for
  building code that forms part of a dynamic linker and cannot
  reference the address of a jump table.  On some targets, jump tables
! do not require a GOT and this option is not needed.
! .IP \fB\-fno\-bit\-tests\fR 4
  .IX Item "-fno-bit-tests"
  Do not use bit tests for switch statements even where it would be
  more efficient than other code generation strategies.
! .IP \fB\-ffixed\-\fR\fIreg\fR 4
  .IX Item "-ffixed-reg"
  Treat the register named \fIreg\fR as a fixed register; generated code
  should never refer to it (except perhaps as a stack pointer, frame
  pointer or in some other fixed role).
  .Sp
  \&\fIreg\fR must be the name of a register.  The register names accepted
! are machine\-specific and are defined in the \f(CW\*(C`REGISTER_NAMES\*(C'\fR
  macro in the machine description macro file.
  .Sp
  This flag does not have a negative form, because it specifies a
! three\-way choice.
! .IP \fB\-fcall\-used\-\fR\fIreg\fR 4
  .IX Item "-fcall-used-reg"
  Treat the register named \fIreg\fR as an allocable register that is
  clobbered by function calls.  It may be allocated for temporaries or
*************** do not save and restore the register \fI
*** 17973,17983 ****
  .Sp
  It is an error to use this flag with the frame pointer or stack pointer.
  Use of this flag for other registers that have fixed pervasive roles in
! the machine's execution model produces disastrous results.
  .Sp
  This flag does not have a negative form, because it specifies a
! three-way choice.
! .IP "\fB\-fcall\-saved\-\fR\fIreg\fR" 4
  .IX Item "-fcall-saved-reg"
  Treat the register named \fIreg\fR as an allocable register saved by
  functions.  It may be allocated even for temporaries or variables that
--- 17904,17914 ----
  .Sp
  It is an error to use this flag with the frame pointer or stack pointer.
  Use of this flag for other registers that have fixed pervasive roles in
! the machine\*(Aqs execution model produces disastrous results.
  .Sp
  This flag does not have a negative form, because it specifies a
! three\-way choice.
! .IP \fB\-fcall\-saved\-\fR\fIreg\fR 4
  .IX Item "-fcall-saved-reg"
  Treat the register named \fIreg\fR as an allocable register saved by
  functions.  It may be allocated even for temporaries or variables that
*************** the register \fIreg\fR if they use it.
*** 17986,17999 ****
  .Sp
  It is an error to use this flag with the frame pointer or stack pointer.
  Use of this flag for other registers that have fixed pervasive roles in
! the machine's execution model produces disastrous results.
  .Sp
  A different sort of disaster results from the use of this flag for
  a register in which function values may be returned.
  .Sp
  This flag does not have a negative form, because it specifies a
! three-way choice.
! .IP "\fB\-fpack\-struct[=\fR\fIn\fR\fB]\fR" 4
  .IX Item "-fpack-struct[=n]"
  Without a value specified, pack all structure members together without
  holes.  When a value is specified (which must be a small power of two), pack
--- 17917,17930 ----
  .Sp
  It is an error to use this flag with the frame pointer or stack pointer.
  Use of this flag for other registers that have fixed pervasive roles in
! the machine\*(Aqs execution model produces disastrous results.
  .Sp
  A different sort of disaster results from the use of this flag for
  a register in which function values may be returned.
  .Sp
  This flag does not have a negative form, because it specifies a
! three\-way choice.
! .IP \fB\-fpack\-struct[=\fR\fIn\fR\fB]\fR 4
  .IX Item "-fpack-struct[=n]"
  Without a value specified, pack all structure members together without
  holes.  When a value is specified (which must be a small power of two), pack
*************** structure members according to this valu
*** 18001,18036 ****
  alignment (that is, objects with default alignment requirements larger than
  this are output potentially unaligned at the next fitting location.
  .Sp
! \&\fBWarning:\fR the \fB\-fpack\-struct\fR switch causes \s-1GCC\s0 to generate
  code that is not binary compatible with code generated without that switch.
  Additionally, it makes the code suboptimal.
! Use it to conform to a non-default application binary interface.
! .IP "\fB\-fleading\-underscore\fR" 4
  .IX Item "-fleading-underscore"
  This option and its counterpart, \fB\-fno\-leading\-underscore\fR, forcibly
  change the way C symbols are represented in the object file.  One use
  is to help link with legacy assembly code.
  .Sp
! \&\fBWarning:\fR the \fB\-fleading\-underscore\fR switch causes \s-1GCC\s0 to
  generate code that is not binary compatible with code generated without that
! switch.  Use it to conform to a non-default application binary interface.
  Not all targets provide complete support for this switch.
! .IP "\fB\-ftls\-model=\fR\fImodel\fR" 4
  .IX Item "-ftls-model=model"
! Alter the thread-local storage model to be used.
! The \fImodel\fR argument should be one of \fBglobal-dynamic\fR,
! \&\fBlocal-dynamic\fR, \fBinitial-exec\fR or \fBlocal-exec\fR.
  Note that the choice is subject to optimization: the compiler may use
  a more efficient model for symbols not visible outside of the translation
  unit, or if \fB\-fpic\fR is not given on the command line.
  .Sp
! The default without \fB\-fpic\fR is \fBinitial-exec\fR; with
! \&\fB\-fpic\fR the default is \fBglobal-dynamic\fR.
! .IP "\fB\-ftrampolines\fR" 4
  .IX Item "-ftrampolines"
  For targets that normally need trampolines for nested functions, always
  generate them instead of using descriptors.  Otherwise, for targets that
! do not need them, like for example HP-PA or \s-1IA\-64,\s0 do nothing.
  .Sp
  A trampoline is a small piece of code that is created at run time on the
  stack when the address of a nested function is taken, and is used to call
--- 17932,17967 ----
  alignment (that is, objects with default alignment requirements larger than
  this are output potentially unaligned at the next fitting location.
  .Sp
! \&\fBWarning:\fR the \fB\-fpack\-struct\fR switch causes 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.
! .IP \fB\-fleading\-underscore\fR 4
  .IX Item "-fleading-underscore"
  This option and its counterpart, \fB\-fno\-leading\-underscore\fR, forcibly
  change the way C symbols are represented in the object file.  One use
  is to help link with legacy assembly code.
  .Sp
! \&\fBWarning:\fR the \fB\-fleading\-underscore\fR switch causes 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.
! .IP \fB\-ftls\-model=\fR\fImodel\fR 4
  .IX Item "-ftls-model=model"
! Alter the thread\-local storage model to be used.
! The \fImodel\fR argument should be one of \fBglobal\-dynamic\fR,
! \&\fBlocal\-dynamic\fR, \fBinitial\-exec\fR or \fBlocal\-exec\fR.
  Note that the choice is subject to optimization: the compiler may use
  a more efficient model for symbols not visible outside of the translation
  unit, or if \fB\-fpic\fR is not given on the command line.
  .Sp
! The default without \fB\-fpic\fR is \fBinitial\-exec\fR; with
! \&\fB\-fpic\fR the default is \fBglobal\-dynamic\fR.
! .IP \fB\-ftrampolines\fR 4
  .IX Item "-ftrampolines"
  For targets that normally need trampolines for nested functions, always
  generate them instead of using descriptors.  Otherwise, for targets that
! do not need them, like for example HP\-PA or IA\-64, do nothing.
  .Sp
  A trampoline is a small piece of code that is created at run time on the
  stack when the address of a nested function is taken, and is used to call
*************** writing, \fB\-fno\-trampolines\fR is ena
*** 18045,18077 ****
  .Sp
  Moreover, code compiled with \fB\-ftrampolines\fR and code compiled with
  \&\fB\-fno\-trampolines\fR are not binary compatible if nested functions are
! present.  This option must therefore be used on a program-wide basis and be
  manipulated with extreme care.
  .Sp
  For languages other than Ada, the \f(CW\*(C`\-ftrampolines\*(C'\fR and
  \&\f(CW\*(C`\-fno\-trampolines\*(C'\fR options currently have no effect, and
  trampolines are always generated on platforms that need them
  for nested functions.
! .IP "\fB\-fvisibility=\fR[\fBdefault\fR|\fBinternal\fR|\fBhidden\fR|\fBprotected\fR]" 4
  .IX Item "-fvisibility=[default|internal|hidden|protected]"
! Set the default \s-1ELF\s0 image symbol visibility to the specified option\-\-\-all
  symbols are marked with this unless overridden within the code.
  Using this feature can very substantially improve linking and
  load times of shared object libraries, produce more optimized
! code, provide near-perfect \s-1API\s0 export and prevent symbol clashes.
  It is \fBstrongly\fR recommended that you use this in any shared objects
  you distribute.
  .Sp
  Despite the nomenclature, \fBdefault\fR always means public; i.e.,
  available to be linked against from outside the shared object.
! \&\fBprotected\fR and \fBinternal\fR are pretty useless in real-world
  usage so the only other commonly used option is \fBhidden\fR.
! The default if \fB\-fvisibility\fR isn't specified is
  \&\fBdefault\fR, i.e., make every symbol public.
  .Sp
! A good explanation of the benefits offered by ensuring \s-1ELF\s0
! symbols have the correct visibility is given by \*(L"How To Write
! Shared Libraries\*(R" by Ulrich Drepper (which can be found at
  <\fBhttps://www.akkadia.org/drepper/\fR>)\-\-\-however a superior
  solution made possible by this option to marking things hidden when
  the default is public is to make the default hidden and mark things
--- 17976,18008 ----
  .Sp
  Moreover, code compiled with \fB\-ftrampolines\fR and code compiled with
  \&\fB\-fno\-trampolines\fR are not binary compatible if nested functions are
! present.  This option must therefore be used on a program\-wide basis and be
  manipulated with extreme care.
  .Sp
  For languages other than Ada, the \f(CW\*(C`\-ftrampolines\*(C'\fR and
  \&\f(CW\*(C`\-fno\-trampolines\*(C'\fR options currently have no effect, and
  trampolines are always generated on platforms that need them
  for nested functions.
! .IP \fB\-fvisibility=\fR[\fBdefault\fR|\fBinternal\fR|\fBhidden\fR|\fBprotected\fR] 4
  .IX Item "-fvisibility=[default|internal|hidden|protected]"
! Set the default ELF image symbol visibility to the specified option\-\-\-all
  symbols are marked with this unless overridden within the code.
  Using this feature can very substantially improve linking and
  load times of shared object libraries, produce more optimized
! code, provide near\-perfect API export and prevent symbol clashes.
  It is \fBstrongly\fR recommended that you use this in any shared objects
  you distribute.
  .Sp
  Despite the nomenclature, \fBdefault\fR always means public; i.e.,
  available to be linked against from outside the shared object.
! \&\fBprotected\fR and \fBinternal\fR are pretty useless in real\-world
  usage so the only other commonly used option is \fBhidden\fR.
! The default if \fB\-fvisibility\fR isn\*(Aqt specified is
  \&\fBdefault\fR, i.e., make every symbol public.
  .Sp
! 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
  <\fBhttps://www.akkadia.org/drepper/\fR>)\-\-\-however a superior
  solution made possible by this option to marking things hidden when
  the default is public is to make the default hidden and mark things
*************** public.  This is the norm with DLLs on W
*** 18079,18085 ****
  and \f(CW\*(C`_\|_attribute_\|_ ((visibility("default")))\*(C'\fR instead of
  \&\f(CW\*(C`_\|_declspec(dllexport)\*(C'\fR you get almost identical semantics with
  identical syntax.  This is a great boon to those working with
! cross-platform projects.
  .Sp
  For those adding visibility support to existing code, you may find
  \&\f(CW\*(C`#pragma GCC visibility\*(C'\fR of use.  This works by you enclosing
--- 18010,18016 ----
  and \f(CW\*(C`_\|_attribute_\|_ ((visibility("default")))\*(C'\fR instead of
  \&\f(CW\*(C`_\|_declspec(dllexport)\*(C'\fR you get almost identical semantics with
  identical syntax.  This is a great boon to those working with
! cross\-platform projects.
  .Sp
  For those adding visibility support to existing code, you may find
  \&\f(CW\*(C`#pragma GCC visibility\*(C'\fR of use.  This works by you enclosing
*************** the declarations you wish to set visibil
*** 18087,18098 ****
  \&\f(CW\*(C`#pragma GCC visibility push(hidden)\*(C'\fR and
  \&\f(CW\*(C`#pragma GCC visibility pop\*(C'\fR.
  Bear in mind that symbol visibility should be viewed \fBas
! part of the \s-1API\s0 interface contract\fR and thus all new code should
  always specify visibility when it is not the default; i.e., declarations
! only for use within the local \s-1DSO\s0 should \fBalways\fR be marked explicitly
! as hidden as so to avoid \s-1PLT\s0 indirection overheads\-\-\-making this
! abundantly clear also aids readability and self-documentation of the code.
! Note that due to \s-1ISO \*(C+\s0 specification requirements, \f(CW\*(C`operator new\*(C'\fR and
  \&\f(CW\*(C`operator delete\*(C'\fR must always be of default visibility.
  .Sp
  Be aware that headers from outside your project, in particular system
--- 18018,18029 ----
  \&\f(CW\*(C`#pragma GCC visibility push(hidden)\*(C'\fR and
  \&\f(CW\*(C`#pragma GCC visibility pop\*(C'\fR.
  Bear in mind that symbol visibility should be viewed \fBas
! part of the API interface contract\fR and thus all new code should
  always specify visibility when it is not the default; i.e., declarations
! only for use within the local DSO should \fBalways\fR 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, \f(CW\*(C`operator new\*(C'\fR and
  \&\f(CW\*(C`operator delete\*(C'\fR must always be of default visibility.
  .Sp
  Be aware that headers from outside your project, in particular system
*************** before including any such headers.
*** 18104,18115 ****
  \&\f(CW\*(C`extern\*(C'\fR declarations are not affected by \fB\-fvisibility\fR, so
  a lot of code can be recompiled with \fB\-fvisibility=hidden\fR with
  no modifications.  However, this means that calls to \f(CW\*(C`extern\*(C'\fR
! functions with no explicit visibility use the \s-1PLT,\s0 so it is more
  effective to use \f(CW\*(C`_\|_attribute ((visibility))\*(C'\fR and/or
  \&\f(CW\*(C`#pragma GCC visibility\*(C'\fR to tell the compiler which \f(CW\*(C`extern\*(C'\fR
  declarations should be treated as hidden.
  .Sp
! Note that \fB\-fvisibility\fR does affect \*(C+ vague linkage
  entities. This means that, for instance, an exception class that is
  be thrown between DSOs must be explicitly marked with default
  visibility so that the \fBtype_info\fR nodes are unified between
--- 18035,18046 ----
  \&\f(CW\*(C`extern\*(C'\fR declarations are not affected by \fB\-fvisibility\fR, so
  a lot of code can be recompiled with \fB\-fvisibility=hidden\fR with
  no modifications.  However, this means that calls to \f(CW\*(C`extern\*(C'\fR
! functions with no explicit visibility use the PLT, so it is more
  effective to use \f(CW\*(C`_\|_attribute ((visibility))\*(C'\fR and/or
  \&\f(CW\*(C`#pragma GCC visibility\*(C'\fR to tell the compiler which \f(CW\*(C`extern\*(C'\fR
  declarations should be treated as hidden.
  .Sp
! Note that \fB\-fvisibility\fR does affect C++ vague linkage
  entities. This means that, for instance, an exception class that is
  be thrown between DSOs must be explicitly marked with default
  visibility so that the \fBtype_info\fR nodes are unified between
*************** the DSOs.
*** 18117,18174 ****
  .Sp
  An overview of these techniques, their benefits and how to use them
  is at <\fBhttps://gcc.gnu.org/wiki/Visibility\fR>.
! .IP "\fB\-fstrict\-volatile\-bitfields\fR" 4
  .IX Item "-fstrict-volatile-bitfields"
! This option should be used if accesses to volatile bit-fields (or other
  structure fields, although the compiler usually honors those types
  anyway) should use a single access of the width of the
! field's type, aligned to a natural alignment if possible.  For
! example, targets with memory-mapped peripheral registers might require
  all such accesses to be 16 bits wide; with this flag you can
! declare all peripheral bit-fields as \f(CW\*(C`unsigned short\*(C'\fR (assuming short
! is 16 bits on these targets) to force \s-1GCC\s0 to use 16\-bit accesses
  instead of, perhaps, a more efficient 32\-bit access.
  .Sp
  If this option is disabled, the compiler uses the most efficient
  instruction.  In the previous example, that might be a 32\-bit load
  instruction, even though that accesses bytes that do not contain
! any portion of the bit-field, or memory-mapped registers unrelated to
  the one being updated.
  .Sp
  In some cases, such as when the \f(CW\*(C`packed\*(C'\fR attribute is applied to a 
  structure field, it may not be possible to access the field with a single
  read or write that is correctly aligned for the target machine.  In this
! case \s-1GCC\s0 falls back to generating multiple accesses rather than code that 
  will fault or truncate the result at run time.
  .Sp
! Note:  Due to restrictions of the C/\*(C+11 memory model, write accesses are
! not allowed to touch non bit-field members.  It is therefore recommended
! to define all bits of the field's type as bit-field members.
  .Sp
  The default value of this option is determined by the application binary
  interface for the target processor.
! .IP "\fB\-fsync\-libcalls\fR" 4
  .IX Item "-fsync-libcalls"
! This option controls whether any out-of-line instance of the \f(CW\*(C`_\|_sync\*(C'\fR
! family of functions may be used to implement the \*(C+11 \f(CW\*(C`_\|_atomic\*(C'\fR
  family of functions.
  .Sp
  The default value of this option is enabled, thus the only useful form
  of the option is \fB\-fno\-sync\-libcalls\fR.  This option is used in
  the implementation of the \fIlibatomic\fR runtime library.
! .SS "\s-1GCC\s0 Developer Options"
  .IX Subsection "GCC Developer Options"
! This section describes command-line options that are primarily of
! interest to \s-1GCC\s0 developers, including options to support compiler
! testing and investigation of compiler bugs and compile-time
  performance problems.  This includes options that produce debug dumps
  at various points in the compilation; that print statistics such as
! memory use and execution time; and that print information about \s-1GCC\s0's
  configuration, such as where it searches for libraries.  You should
  rarely need to use any of these options for ordinary compilation and
  linking tasks.
  .PP
! Many developer options that cause \s-1GCC\s0 to dump output to a file take an
  optional \fB=\fR\fIfilename\fR suffix. You can specify \fBstdout\fR
  or \fB\-\fR to dump to standard output, and \fBstderr\fR for standard
  error.
--- 18048,18105 ----
  .Sp
  An overview of these techniques, their benefits and how to use them
  is at <\fBhttps://gcc.gnu.org/wiki/Visibility\fR>.
! .IP \fB\-fstrict\-volatile\-bitfields\fR 4
  .IX Item "-fstrict-volatile-bitfields"
! This option should be used if accesses to volatile bit\-fields (or other
  structure fields, although the compiler usually honors those types
  anyway) should use a single access of the width of the
! field\*(Aqs type, aligned to a natural alignment if possible.  For
! example, targets with memory\-mapped peripheral registers might require
  all such accesses to be 16 bits wide; with this flag you can
! declare all peripheral bit\-fields as \f(CW\*(C`unsigned short\*(C'\fR (assuming short
! is 16 bits on these targets) to force GCC to use 16\-bit accesses
  instead of, perhaps, a more efficient 32\-bit access.
  .Sp
  If this option is disabled, the compiler uses the most efficient
  instruction.  In the previous example, that might be a 32\-bit load
  instruction, even though that accesses bytes that do not contain
! any portion of the bit\-field, or memory\-mapped registers unrelated to
  the one being updated.
  .Sp
  In some cases, such as when the \f(CW\*(C`packed\*(C'\fR attribute is applied to a 
  structure field, it may not be possible to access the field with a single
  read or write that is correctly aligned for the target machine.  In this
! case GCC falls back to generating multiple accesses rather than code that 
  will fault or truncate the result at run time.
  .Sp
! Note:  Due to restrictions of the C/C++11 memory model, write accesses are
! not allowed to touch non bit\-field members.  It is therefore recommended
! to define all bits of the field\*(Aqs type as bit\-field members.
  .Sp
  The default value of this option is determined by the application binary
  interface for the target processor.
! .IP \fB\-fsync\-libcalls\fR 4
  .IX Item "-fsync-libcalls"
! This option controls whether any out\-of\-line instance of the \f(CW\*(C`_\|_sync\*(C'\fR
! family of functions may be used to implement the C++11 \f(CW\*(C`_\|_atomic\*(C'\fR
  family of functions.
  .Sp
  The default value of this option is enabled, thus the only useful form
  of the option is \fB\-fno\-sync\-libcalls\fR.  This option is used in
  the implementation of the \fIlibatomic\fR runtime library.
! .SS "GCC Developer Options"
  .IX Subsection "GCC Developer Options"
! This section describes command\-line options that are primarily of
! interest to GCC developers, including options to support compiler
! testing and investigation of compiler bugs and compile\-time
  performance problems.  This includes options that produce debug dumps
  at various points in the compilation; that print statistics such as
! memory use and execution time; and that print information about GCC\*(Aqs
  configuration, such as where it searches for libraries.  You should
  rarely need to use any of these options for ordinary compilation and
  linking tasks.
  .PP
! Many developer options that cause GCC to dump output to a file take an
  optional \fB=\fR\fIfilename\fR suffix. You can specify \fBstdout\fR
  or \fB\-\fR to dump to standard output, and \fBstderr\fR for standard
  error.
*************** phase letter, and pass name.  The base d
*** 18179,18202 ****
  output file produced by the compiler if explicitly specified and not
  an executable; otherwise it is the source file name.
  The pass number is determined by the order passes are registered with
! the compiler's pass manager. 
  This is generally the same as the order of execution, but passes
! registered by plugins, target-specific passes, or passes that are
  otherwise registered late are numbered higher than the pass named
  \&\fBfinal\fR, even if they are executed earlier.  The phase letter is
! one of \fBi\fR (inter-procedural analysis), \fBl\fR
! (language-specific), \fBr\fR (\s-1RTL\s0), or \fBt\fR (tree). 
  The files are created in the directory of the output file.
! .IP "\fB\-fcallgraph\-info\fR" 4
  .IX Item "-fcallgraph-info"
  .PD 0
! .IP "\fB\-fcallgraph\-info=\fR\fI\s-1MARKERS\s0\fR" 4
  .IX Item "-fcallgraph-info=MARKERS"
  .PD
  Makes the compiler output callgraph information for the program, on a
! per-object-file basis.  The information is generated in the common \s-1VCG\s0
! format.  It can be decorated with additional, per-node and/or per-edge
! information, if a list of comma-separated markers is additionally
  specified.  When the \f(CW\*(C`su\*(C'\fR marker is specified, the callgraph is
  decorated with stack usage information; it is equivalent to
  \&\fB\-fstack\-usage\fR.  When the \f(CW\*(C`da\*(C'\fR marker is specified, the
--- 18110,18133 ----
  output file produced by the compiler if explicitly specified and not
  an executable; otherwise it is the source file name.
  The pass number is determined by the order passes are registered with
! the compiler\*(Aqs pass manager. 
  This is generally the same as the order of execution, but passes
! registered by plugins, target\-specific passes, or passes that are
  otherwise registered late are numbered higher than the pass named
  \&\fBfinal\fR, even if they are executed earlier.  The phase letter is
! one of \fBi\fR (inter\-procedural analysis), \fBl\fR
! (language\-specific), \fBr\fR (RTL), or \fBt\fR (tree). 
  The files are created in the directory of the output file.
! .IP \fB\-fcallgraph\-info\fR 4
  .IX Item "-fcallgraph-info"
  .PD 0
! .IP \fB\-fcallgraph\-info=\fR\fIMARKERS\fR 4
  .IX Item "-fcallgraph-info=MARKERS"
  .PD
  Makes the compiler output callgraph information for the program, on a
! per\-object\-file basis.  The information is generated in the common VCG
! format.  It can be decorated with additional, per\-node and/or per\-edge
! information, if a list of comma\-separated markers is additionally
  specified.  When the \f(CW\*(C`su\*(C'\fR marker is specified, the callgraph is
  decorated with stack usage information; it is equivalent to
  \&\fB\-fstack\-usage\fR.  When the \f(CW\*(C`da\*(C'\fR marker is specified, the
*************** callgraph is decorated with information
*** 18204,18222 ****
  objects.
  .Sp
  When compiling with \fB\-flto\fR, no callgraph information is output
! along with the object file.  At \s-1LTO\s0 link time, \fB\-fcallgraph\-info\fR
  may generate multiple callgraph information files next to intermediate
! \&\s-1LTO\s0 output files.
! .IP "\fB\-d\fR\fIletters\fR" 4
  .IX Item "-dletters"
  .PD 0
! .IP "\fB\-fdump\-rtl\-\fR\fIpass\fR" 4
  .IX Item "-fdump-rtl-pass"
! .IP "\fB\-fdump\-rtl\-\fR\fIpass\fR\fB=\fR\fIfilename\fR" 4
  .IX Item "-fdump-rtl-pass=filename"
  .PD
  Says to make debugging dumps during compilation at times specified by
! \&\fIletters\fR.  This is used for debugging the RTL-based passes of the
  compiler.
  .Sp
  Some \fB\-d\fR\fIletters\fR switches have different meaning when
--- 18135,18153 ----
  objects.
  .Sp
  When compiling with \fB\-flto\fR, no callgraph information is output
! along with the object file.  At LTO link time, \fB\-fcallgraph\-info\fR
  may generate multiple callgraph information files next to intermediate
! LTO output files.
! .IP \fB\-d\fR\fIletters\fR 4
  .IX Item "-dletters"
  .PD 0
! .IP \fB\-fdump\-rtl\-\fR\fIpass\fR 4
  .IX Item "-fdump-rtl-pass"
! .IP \fB\-fdump\-rtl\-\fR\fIpass\fR\fB=\fR\fIfilename\fR 4
  .IX Item "-fdump-rtl-pass=filename"
  .PD
  Says to make debugging dumps during compilation at times specified by
! \&\fIletters\fR.  This is used for debugging the RTL\-based passes of the
  compiler.
  .Sp
  Some \fB\-d\fR\fIletters\fR switches have different meaning when
*************** Debug dumps can be enabled with a \fB\-f
*** 18226,18530 ****
  \&\fB\-d\fR option \fIletters\fR.  Here are the possible
  letters for use in \fIpass\fR and \fIletters\fR, and their meanings:
  .RS 4
! .IP "\fB\-fdump\-rtl\-alignments\fR" 4
  .IX Item "-fdump-rtl-alignments"
  Dump after branch alignments have been computed.
! .IP "\fB\-fdump\-rtl\-asmcons\fR" 4
  .IX Item "-fdump-rtl-asmcons"
  Dump after fixing rtl statements that have unsatisfied in/out constraints.
! .IP "\fB\-fdump\-rtl\-auto_inc_dec\fR" 4
  .IX Item "-fdump-rtl-auto_inc_dec"
! Dump after auto-inc-dec discovery.  This pass is only run on
  architectures that have auto inc or auto dec instructions.
! .IP "\fB\-fdump\-rtl\-barriers\fR" 4
  .IX Item "-fdump-rtl-barriers"
  Dump after cleaning up the barrier instructions.
! .IP "\fB\-fdump\-rtl\-bbpart\fR" 4
  .IX Item "-fdump-rtl-bbpart"
  Dump after partitioning hot and cold basic blocks.
! .IP "\fB\-fdump\-rtl\-bbro\fR" 4
  .IX Item "-fdump-rtl-bbro"
  Dump after block reordering.
! .IP "\fB\-fdump\-rtl\-btl1\fR" 4
  .IX Item "-fdump-rtl-btl1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-btl2\fR" 4
  .IX Item "-fdump-rtl-btl2"
  .PD
  \&\fB\-fdump\-rtl\-btl1\fR and \fB\-fdump\-rtl\-btl2\fR enable dumping
  after the two branch
  target load optimization passes.
! .IP "\fB\-fdump\-rtl\-bypass\fR" 4
  .IX Item "-fdump-rtl-bypass"
  Dump after jump bypassing and control flow optimizations.
! .IP "\fB\-fdump\-rtl\-combine\fR" 4
  .IX Item "-fdump-rtl-combine"
! Dump after the \s-1RTL\s0 instruction combination pass.
! .IP "\fB\-fdump\-rtl\-compgotos\fR" 4
  .IX Item "-fdump-rtl-compgotos"
  Dump after duplicating the computed gotos.
! .IP "\fB\-fdump\-rtl\-ce1\fR" 4
  .IX Item "-fdump-rtl-ce1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-ce2\fR" 4
  .IX Item "-fdump-rtl-ce2"
! .IP "\fB\-fdump\-rtl\-ce3\fR" 4
  .IX Item "-fdump-rtl-ce3"
  .PD
  \&\fB\-fdump\-rtl\-ce1\fR, \fB\-fdump\-rtl\-ce2\fR, and
  \&\fB\-fdump\-rtl\-ce3\fR enable dumping after the three
  if conversion passes.
! .IP "\fB\-fdump\-rtl\-cprop_hardreg\fR" 4
  .IX Item "-fdump-rtl-cprop_hardreg"
  Dump after hard register copy propagation.
! .IP "\fB\-fdump\-rtl\-csa\fR" 4
  .IX Item "-fdump-rtl-csa"
  Dump after combining stack adjustments.
! .IP "\fB\-fdump\-rtl\-cse1\fR" 4
  .IX Item "-fdump-rtl-cse1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-cse2\fR" 4
  .IX Item "-fdump-rtl-cse2"
  .PD
  \&\fB\-fdump\-rtl\-cse1\fR and \fB\-fdump\-rtl\-cse2\fR enable dumping after
  the two common subexpression elimination passes.
! .IP "\fB\-fdump\-rtl\-dce\fR" 4
  .IX Item "-fdump-rtl-dce"
  Dump after the standalone dead code elimination passes.
! .IP "\fB\-fdump\-rtl\-dbr\fR" 4
  .IX Item "-fdump-rtl-dbr"
  Dump after delayed branch scheduling.
! .IP "\fB\-fdump\-rtl\-dce1\fR" 4
  .IX Item "-fdump-rtl-dce1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-dce2\fR" 4
  .IX Item "-fdump-rtl-dce2"
  .PD
  \&\fB\-fdump\-rtl\-dce1\fR and \fB\-fdump\-rtl\-dce2\fR enable dumping after
  the two dead store elimination passes.
! .IP "\fB\-fdump\-rtl\-eh\fR" 4
  .IX Item "-fdump-rtl-eh"
! Dump after finalization of \s-1EH\s0 handling code.
! .IP "\fB\-fdump\-rtl\-eh_ranges\fR" 4
  .IX Item "-fdump-rtl-eh_ranges"
! Dump after conversion of \s-1EH\s0 handling range regions.
! .IP "\fB\-fdump\-rtl\-expand\fR" 4
  .IX Item "-fdump-rtl-expand"
! Dump after \s-1RTL\s0 generation.
! .IP "\fB\-fdump\-rtl\-fwprop1\fR" 4
  .IX Item "-fdump-rtl-fwprop1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-fwprop2\fR" 4
  .IX Item "-fdump-rtl-fwprop2"
  .PD
  \&\fB\-fdump\-rtl\-fwprop1\fR and \fB\-fdump\-rtl\-fwprop2\fR enable
  dumping after the two forward propagation passes.
! .IP "\fB\-fdump\-rtl\-gcse1\fR" 4
  .IX Item "-fdump-rtl-gcse1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-gcse2\fR" 4
  .IX Item "-fdump-rtl-gcse2"
  .PD
  \&\fB\-fdump\-rtl\-gcse1\fR and \fB\-fdump\-rtl\-gcse2\fR enable dumping
  after global common subexpression elimination.
! .IP "\fB\-fdump\-rtl\-init\-regs\fR" 4
  .IX Item "-fdump-rtl-init-regs"
  Dump after the initialization of the registers.
! .IP "\fB\-fdump\-rtl\-initvals\fR" 4
  .IX Item "-fdump-rtl-initvals"
  Dump after the computation of the initial value sets.
! .IP "\fB\-fdump\-rtl\-into_cfglayout\fR" 4
  .IX Item "-fdump-rtl-into_cfglayout"
  Dump after converting to cfglayout mode.
! .IP "\fB\-fdump\-rtl\-ira\fR" 4
  .IX Item "-fdump-rtl-ira"
  Dump after iterated register allocation.
! .IP "\fB\-fdump\-rtl\-jump\fR" 4
  .IX Item "-fdump-rtl-jump"
  Dump after the second jump optimization.
! .IP "\fB\-fdump\-rtl\-loop2\fR" 4
  .IX Item "-fdump-rtl-loop2"
  \&\fB\-fdump\-rtl\-loop2\fR enables dumping after the rtl
  loop optimization passes.
! .IP "\fB\-fdump\-rtl\-mach\fR" 4
  .IX Item "-fdump-rtl-mach"
  Dump after performing the machine dependent reorganization pass, if that
  pass exists.
! .IP "\fB\-fdump\-rtl\-mode_sw\fR" 4
  .IX Item "-fdump-rtl-mode_sw"
  Dump after removing redundant mode switches.
! .IP "\fB\-fdump\-rtl\-rnreg\fR" 4
  .IX Item "-fdump-rtl-rnreg"
  Dump after register renumbering.
! .IP "\fB\-fdump\-rtl\-outof_cfglayout\fR" 4
  .IX Item "-fdump-rtl-outof_cfglayout"
  Dump after converting from cfglayout mode.
! .IP "\fB\-fdump\-rtl\-peephole2\fR" 4
  .IX Item "-fdump-rtl-peephole2"
  Dump after the peephole pass.
! .IP "\fB\-fdump\-rtl\-postreload\fR" 4
  .IX Item "-fdump-rtl-postreload"
! Dump after post-reload optimizations.
! .IP "\fB\-fdump\-rtl\-pro_and_epilogue\fR" 4
  .IX Item "-fdump-rtl-pro_and_epilogue"
  Dump after generating the function prologues and epilogues.
! .IP "\fB\-fdump\-rtl\-sched1\fR" 4
  .IX Item "-fdump-rtl-sched1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-sched2\fR" 4
  .IX Item "-fdump-rtl-sched2"
  .PD
  \&\fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR enable dumping
  after the basic block scheduling passes.
! .IP "\fB\-fdump\-rtl\-ree\fR" 4
  .IX Item "-fdump-rtl-ree"
  Dump after sign/zero extension elimination.
! .IP "\fB\-fdump\-rtl\-seqabstr\fR" 4
  .IX Item "-fdump-rtl-seqabstr"
  Dump after common sequence discovery.
! .IP "\fB\-fdump\-rtl\-shorten\fR" 4
  .IX Item "-fdump-rtl-shorten"
  Dump after shortening branches.
! .IP "\fB\-fdump\-rtl\-sibling\fR" 4
  .IX Item "-fdump-rtl-sibling"
  Dump after sibling call optimizations.
! .IP "\fB\-fdump\-rtl\-split1\fR" 4
  .IX Item "-fdump-rtl-split1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-split2\fR" 4
  .IX Item "-fdump-rtl-split2"
! .IP "\fB\-fdump\-rtl\-split3\fR" 4
  .IX Item "-fdump-rtl-split3"
! .IP "\fB\-fdump\-rtl\-split4\fR" 4
  .IX Item "-fdump-rtl-split4"
! .IP "\fB\-fdump\-rtl\-split5\fR" 4
  .IX Item "-fdump-rtl-split5"
  .PD
  These options enable dumping after five rounds of
  instruction splitting.
! .IP "\fB\-fdump\-rtl\-sms\fR" 4
  .IX Item "-fdump-rtl-sms"
  Dump after modulo scheduling.  This pass is only run on some
  architectures.
! .IP "\fB\-fdump\-rtl\-stack\fR" 4
  .IX Item "-fdump-rtl-stack"
! Dump after conversion from \s-1GCC\s0's \*(L"flat register file\*(R" registers to the
! x87's stack-like registers.  This pass is only run on x86 variants.
! .IP "\fB\-fdump\-rtl\-subreg1\fR" 4
  .IX Item "-fdump-rtl-subreg1"
  .PD 0
! .IP "\fB\-fdump\-rtl\-subreg2\fR" 4
  .IX Item "-fdump-rtl-subreg2"
  .PD
  \&\fB\-fdump\-rtl\-subreg1\fR and \fB\-fdump\-rtl\-subreg2\fR enable dumping after
  the two subreg expansion passes.
! .IP "\fB\-fdump\-rtl\-unshare\fR" 4
  .IX Item "-fdump-rtl-unshare"
  Dump after all rtl has been unshared.
! .IP "\fB\-fdump\-rtl\-vartrack\fR" 4
  .IX Item "-fdump-rtl-vartrack"
  Dump after variable tracking.
! .IP "\fB\-fdump\-rtl\-vregs\fR" 4
  .IX Item "-fdump-rtl-vregs"
  Dump after converting virtual registers to hard registers.
! .IP "\fB\-fdump\-rtl\-web\fR" 4
  .IX Item "-fdump-rtl-web"
  Dump after live range splitting.
! .IP "\fB\-fdump\-rtl\-regclass\fR" 4
  .IX Item "-fdump-rtl-regclass"
  .PD 0
! .IP "\fB\-fdump\-rtl\-subregs_of_mode_init\fR" 4
  .IX Item "-fdump-rtl-subregs_of_mode_init"
! .IP "\fB\-fdump\-rtl\-subregs_of_mode_finish\fR" 4
  .IX Item "-fdump-rtl-subregs_of_mode_finish"
! .IP "\fB\-fdump\-rtl\-dfinit\fR" 4
  .IX Item "-fdump-rtl-dfinit"
! .IP "\fB\-fdump\-rtl\-dfinish\fR" 4
  .IX Item "-fdump-rtl-dfinish"
  .PD
  These dumps are defined but always produce empty files.
! .IP "\fB\-da\fR" 4
  .IX Item "-da"
  .PD 0
! .IP "\fB\-fdump\-rtl\-all\fR" 4
  .IX Item "-fdump-rtl-all"
  .PD
  Produce all the dumps listed above.
! .IP "\fB\-dA\fR" 4
  .IX Item "-dA"
  Annotate the assembler output with miscellaneous debugging information.
! .IP "\fB\-dD\fR" 4
  .IX Item "-dD"
  Dump all macro definitions, at the end of preprocessing, in addition to
  normal output.
! .IP "\fB\-dH\fR" 4
  .IX Item "-dH"
  Produce a core dump whenever an error occurs.
! .IP "\fB\-dp\fR" 4
  .IX Item "-dp"
  Annotate the assembler output with a comment indicating which
  pattern and alternative is used.  The length and cost of each instruction are
  also printed.
! .IP "\fB\-dP\fR" 4
  .IX Item "-dP"
! Dump the \s-1RTL\s0 in the assembler output as a comment before each instruction.
  Also turns on \fB\-dp\fR annotation.
! .IP "\fB\-dx\fR" 4
  .IX Item "-dx"
! Just generate \s-1RTL\s0 for a function instead of compiling it.  Usually used
  with \fB\-fdump\-rtl\-expand\fR.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdump\-debug\fR" 4
  .IX Item "-fdump-debug"
  Dump debugging information generated during the debug
  generation phase.
! .IP "\fB\-fdump\-earlydebug\fR" 4
  .IX Item "-fdump-earlydebug"
  Dump debugging information generated during the early debug
  generation phase.
! .IP "\fB\-fdump\-noaddr\fR" 4
  .IX Item "-fdump-noaddr"
  When doing debugging dumps, suppress address output.  This makes it more
  feasible to use diff on debugging dumps for compiler invocations with
  different compiler binaries and/or different
  text / bss / data / heap / stack / dso start locations.
! .IP "\fB\-freport\-bug\fR" 4
  .IX Item "-freport-bug"
  Collect and dump debug information into a temporary file if an
! internal compiler error (\s-1ICE\s0) occurs.
! .IP "\fB\-fdump\-unnumbered\fR" 4
  .IX Item "-fdump-unnumbered"
  When doing debugging dumps, suppress instruction numbers and address output.
  This makes it more feasible to use diff on debugging dumps for compiler
  invocations with different options, in particular with and without
  \&\fB\-g\fR.
! .IP "\fB\-fdump\-unnumbered\-links\fR" 4
  .IX Item "-fdump-unnumbered-links"
  When doing debugging dumps (see \fB\-d\fR option above), suppress
  instruction numbers for the links to the previous and next instructions
  in a sequence.
! .IP "\fB\-fdump\-ipa\-\fR\fIswitch\fR" 4
  .IX Item "-fdump-ipa-switch"
  .PD 0
! .IP "\fB\-fdump\-ipa\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR" 4
  .IX Item "-fdump-ipa-switch-options"
  .PD
! Control the dumping at various stages of inter-procedural analysis
  language tree to a file.  The file name is generated by appending a
  switch specific suffix to the source file name, and the file is created
  in the same directory as the output file.  The following dumps are
  possible:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
! Enables all inter-procedural analysis dumps.
! .IP "\fBcgraph\fR" 4
  .IX Item "cgraph"
! Dumps information about call-graph optimization, unused function removal,
  and inlining decisions.
! .IP "\fBinline\fR" 4
  .IX Item "inline"
  Dump after function inlining.
  .RE
--- 18157,18461 ----
  \&\fB\-d\fR option \fIletters\fR.  Here are the possible
  letters for use in \fIpass\fR and \fIletters\fR, and their meanings:
  .RS 4
! .IP \fB\-fdump\-rtl\-alignments\fR 4
  .IX Item "-fdump-rtl-alignments"
  Dump after branch alignments have been computed.
! .IP \fB\-fdump\-rtl\-asmcons\fR 4
  .IX Item "-fdump-rtl-asmcons"
  Dump after fixing rtl statements that have unsatisfied in/out constraints.
! .IP \fB\-fdump\-rtl\-auto_inc_dec\fR 4
  .IX Item "-fdump-rtl-auto_inc_dec"
! Dump after auto\-inc\-dec discovery.  This pass is only run on
  architectures that have auto inc or auto dec instructions.
! .IP \fB\-fdump\-rtl\-barriers\fR 4
  .IX Item "-fdump-rtl-barriers"
  Dump after cleaning up the barrier instructions.
! .IP \fB\-fdump\-rtl\-bbpart\fR 4
  .IX Item "-fdump-rtl-bbpart"
  Dump after partitioning hot and cold basic blocks.
! .IP \fB\-fdump\-rtl\-bbro\fR 4
  .IX Item "-fdump-rtl-bbro"
  Dump after block reordering.
! .IP \fB\-fdump\-rtl\-btl1\fR 4
  .IX Item "-fdump-rtl-btl1"
  .PD 0
! .IP \fB\-fdump\-rtl\-btl2\fR 4
  .IX Item "-fdump-rtl-btl2"
  .PD
  \&\fB\-fdump\-rtl\-btl1\fR and \fB\-fdump\-rtl\-btl2\fR enable dumping
  after the two branch
  target load optimization passes.
! .IP \fB\-fdump\-rtl\-bypass\fR 4
  .IX Item "-fdump-rtl-bypass"
  Dump after jump bypassing and control flow optimizations.
! .IP \fB\-fdump\-rtl\-combine\fR 4
  .IX Item "-fdump-rtl-combine"
! Dump after the RTL instruction combination pass.
! .IP \fB\-fdump\-rtl\-compgotos\fR 4
  .IX Item "-fdump-rtl-compgotos"
  Dump after duplicating the computed gotos.
! .IP \fB\-fdump\-rtl\-ce1\fR 4
  .IX Item "-fdump-rtl-ce1"
  .PD 0
! .IP \fB\-fdump\-rtl\-ce2\fR 4
  .IX Item "-fdump-rtl-ce2"
! .IP \fB\-fdump\-rtl\-ce3\fR 4
  .IX Item "-fdump-rtl-ce3"
  .PD
  \&\fB\-fdump\-rtl\-ce1\fR, \fB\-fdump\-rtl\-ce2\fR, and
  \&\fB\-fdump\-rtl\-ce3\fR enable dumping after the three
  if conversion passes.
! .IP \fB\-fdump\-rtl\-cprop_hardreg\fR 4
  .IX Item "-fdump-rtl-cprop_hardreg"
  Dump after hard register copy propagation.
! .IP \fB\-fdump\-rtl\-csa\fR 4
  .IX Item "-fdump-rtl-csa"
  Dump after combining stack adjustments.
! .IP \fB\-fdump\-rtl\-cse1\fR 4
  .IX Item "-fdump-rtl-cse1"
  .PD 0
! .IP \fB\-fdump\-rtl\-cse2\fR 4
  .IX Item "-fdump-rtl-cse2"
  .PD
  \&\fB\-fdump\-rtl\-cse1\fR and \fB\-fdump\-rtl\-cse2\fR enable dumping after
  the two common subexpression elimination passes.
! .IP \fB\-fdump\-rtl\-dce\fR 4
  .IX Item "-fdump-rtl-dce"
  Dump after the standalone dead code elimination passes.
! .IP \fB\-fdump\-rtl\-dbr\fR 4
  .IX Item "-fdump-rtl-dbr"
  Dump after delayed branch scheduling.
! .IP \fB\-fdump\-rtl\-dce1\fR 4
  .IX Item "-fdump-rtl-dce1"
  .PD 0
! .IP \fB\-fdump\-rtl\-dce2\fR 4
  .IX Item "-fdump-rtl-dce2"
  .PD
  \&\fB\-fdump\-rtl\-dce1\fR and \fB\-fdump\-rtl\-dce2\fR enable dumping after
  the two dead store elimination passes.
! .IP \fB\-fdump\-rtl\-eh\fR 4
  .IX Item "-fdump-rtl-eh"
! Dump after finalization of EH handling code.
! .IP \fB\-fdump\-rtl\-eh_ranges\fR 4
  .IX Item "-fdump-rtl-eh_ranges"
! Dump after conversion of EH handling range regions.
! .IP \fB\-fdump\-rtl\-expand\fR 4
  .IX Item "-fdump-rtl-expand"
! Dump after RTL generation.
! .IP \fB\-fdump\-rtl\-fwprop1\fR 4
  .IX Item "-fdump-rtl-fwprop1"
  .PD 0
! .IP \fB\-fdump\-rtl\-fwprop2\fR 4
  .IX Item "-fdump-rtl-fwprop2"
  .PD
  \&\fB\-fdump\-rtl\-fwprop1\fR and \fB\-fdump\-rtl\-fwprop2\fR enable
  dumping after the two forward propagation passes.
! .IP \fB\-fdump\-rtl\-gcse1\fR 4
  .IX Item "-fdump-rtl-gcse1"
  .PD 0
! .IP \fB\-fdump\-rtl\-gcse2\fR 4
  .IX Item "-fdump-rtl-gcse2"
  .PD
  \&\fB\-fdump\-rtl\-gcse1\fR and \fB\-fdump\-rtl\-gcse2\fR enable dumping
  after global common subexpression elimination.
! .IP \fB\-fdump\-rtl\-init\-regs\fR 4
  .IX Item "-fdump-rtl-init-regs"
  Dump after the initialization of the registers.
! .IP \fB\-fdump\-rtl\-initvals\fR 4
  .IX Item "-fdump-rtl-initvals"
  Dump after the computation of the initial value sets.
! .IP \fB\-fdump\-rtl\-into_cfglayout\fR 4
  .IX Item "-fdump-rtl-into_cfglayout"
  Dump after converting to cfglayout mode.
! .IP \fB\-fdump\-rtl\-ira\fR 4
  .IX Item "-fdump-rtl-ira"
  Dump after iterated register allocation.
! .IP \fB\-fdump\-rtl\-jump\fR 4
  .IX Item "-fdump-rtl-jump"
  Dump after the second jump optimization.
! .IP \fB\-fdump\-rtl\-loop2\fR 4
  .IX Item "-fdump-rtl-loop2"
  \&\fB\-fdump\-rtl\-loop2\fR enables dumping after the rtl
  loop optimization passes.
! .IP \fB\-fdump\-rtl\-mach\fR 4
  .IX Item "-fdump-rtl-mach"
  Dump after performing the machine dependent reorganization pass, if that
  pass exists.
! .IP \fB\-fdump\-rtl\-mode_sw\fR 4
  .IX Item "-fdump-rtl-mode_sw"
  Dump after removing redundant mode switches.
! .IP \fB\-fdump\-rtl\-rnreg\fR 4
  .IX Item "-fdump-rtl-rnreg"
  Dump after register renumbering.
! .IP \fB\-fdump\-rtl\-outof_cfglayout\fR 4
  .IX Item "-fdump-rtl-outof_cfglayout"
  Dump after converting from cfglayout mode.
! .IP \fB\-fdump\-rtl\-peephole2\fR 4
  .IX Item "-fdump-rtl-peephole2"
  Dump after the peephole pass.
! .IP \fB\-fdump\-rtl\-postreload\fR 4
  .IX Item "-fdump-rtl-postreload"
! Dump after post\-reload optimizations.
! .IP \fB\-fdump\-rtl\-pro_and_epilogue\fR 4
  .IX Item "-fdump-rtl-pro_and_epilogue"
  Dump after generating the function prologues and epilogues.
! .IP \fB\-fdump\-rtl\-sched1\fR 4
  .IX Item "-fdump-rtl-sched1"
  .PD 0
! .IP \fB\-fdump\-rtl\-sched2\fR 4
  .IX Item "-fdump-rtl-sched2"
  .PD
  \&\fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR enable dumping
  after the basic block scheduling passes.
! .IP \fB\-fdump\-rtl\-ree\fR 4
  .IX Item "-fdump-rtl-ree"
  Dump after sign/zero extension elimination.
! .IP \fB\-fdump\-rtl\-seqabstr\fR 4
  .IX Item "-fdump-rtl-seqabstr"
  Dump after common sequence discovery.
! .IP \fB\-fdump\-rtl\-shorten\fR 4
  .IX Item "-fdump-rtl-shorten"
  Dump after shortening branches.
! .IP \fB\-fdump\-rtl\-sibling\fR 4
  .IX Item "-fdump-rtl-sibling"
  Dump after sibling call optimizations.
! .IP \fB\-fdump\-rtl\-split1\fR 4
  .IX Item "-fdump-rtl-split1"
  .PD 0
! .IP \fB\-fdump\-rtl\-split2\fR 4
  .IX Item "-fdump-rtl-split2"
! .IP \fB\-fdump\-rtl\-split3\fR 4
  .IX Item "-fdump-rtl-split3"
! .IP \fB\-fdump\-rtl\-split4\fR 4
  .IX Item "-fdump-rtl-split4"
! .IP \fB\-fdump\-rtl\-split5\fR 4
  .IX Item "-fdump-rtl-split5"
  .PD
  These options enable dumping after five rounds of
  instruction splitting.
! .IP \fB\-fdump\-rtl\-sms\fR 4
  .IX Item "-fdump-rtl-sms"
  Dump after modulo scheduling.  This pass is only run on some
  architectures.
! .IP \fB\-fdump\-rtl\-stack\fR 4
  .IX Item "-fdump-rtl-stack"
! Dump after conversion from GCC\*(Aqs "flat register file" registers to the
! x87\*(Aqs stack\-like registers.  This pass is only run on x86 variants.
! .IP \fB\-fdump\-rtl\-subreg1\fR 4
  .IX Item "-fdump-rtl-subreg1"
  .PD 0
! .IP \fB\-fdump\-rtl\-subreg2\fR 4
  .IX Item "-fdump-rtl-subreg2"
  .PD
  \&\fB\-fdump\-rtl\-subreg1\fR and \fB\-fdump\-rtl\-subreg2\fR enable dumping after
  the two subreg expansion passes.
! .IP \fB\-fdump\-rtl\-unshare\fR 4
  .IX Item "-fdump-rtl-unshare"
  Dump after all rtl has been unshared.
! .IP \fB\-fdump\-rtl\-vartrack\fR 4
  .IX Item "-fdump-rtl-vartrack"
  Dump after variable tracking.
! .IP \fB\-fdump\-rtl\-vregs\fR 4
  .IX Item "-fdump-rtl-vregs"
  Dump after converting virtual registers to hard registers.
! .IP \fB\-fdump\-rtl\-web\fR 4
  .IX Item "-fdump-rtl-web"
  Dump after live range splitting.
! .IP \fB\-fdump\-rtl\-regclass\fR 4
  .IX Item "-fdump-rtl-regclass"
  .PD 0
! .IP \fB\-fdump\-rtl\-subregs_of_mode_init\fR 4
  .IX Item "-fdump-rtl-subregs_of_mode_init"
! .IP \fB\-fdump\-rtl\-subregs_of_mode_finish\fR 4
  .IX Item "-fdump-rtl-subregs_of_mode_finish"
! .IP \fB\-fdump\-rtl\-dfinit\fR 4
  .IX Item "-fdump-rtl-dfinit"
! .IP \fB\-fdump\-rtl\-dfinish\fR 4
  .IX Item "-fdump-rtl-dfinish"
  .PD
  These dumps are defined but always produce empty files.
! .IP \fB\-da\fR 4
  .IX Item "-da"
  .PD 0
! .IP \fB\-fdump\-rtl\-all\fR 4
  .IX Item "-fdump-rtl-all"
  .PD
  Produce all the dumps listed above.
! .IP \fB\-dA\fR 4
  .IX Item "-dA"
  Annotate the assembler output with miscellaneous debugging information.
! .IP \fB\-dD\fR 4
  .IX Item "-dD"
  Dump all macro definitions, at the end of preprocessing, in addition to
  normal output.
! .IP \fB\-dH\fR 4
  .IX Item "-dH"
  Produce a core dump whenever an error occurs.
! .IP \fB\-dp\fR 4
  .IX Item "-dp"
  Annotate the assembler output with a comment indicating which
  pattern and alternative is used.  The length and cost of each instruction are
  also printed.
! .IP \fB\-dP\fR 4
  .IX Item "-dP"
! Dump the RTL in the assembler output as a comment before each instruction.
  Also turns on \fB\-dp\fR annotation.
! .IP \fB\-dx\fR 4
  .IX Item "-dx"
! Just generate RTL for a function instead of compiling it.  Usually used
  with \fB\-fdump\-rtl\-expand\fR.
  .RE
  .RS 4
  .RE
! .IP \fB\-fdump\-debug\fR 4
  .IX Item "-fdump-debug"
  Dump debugging information generated during the debug
  generation phase.
! .IP \fB\-fdump\-earlydebug\fR 4
  .IX Item "-fdump-earlydebug"
  Dump debugging information generated during the early debug
  generation phase.
! .IP \fB\-fdump\-noaddr\fR 4
  .IX Item "-fdump-noaddr"
  When doing debugging dumps, suppress address output.  This makes it more
  feasible to use diff on debugging dumps for compiler invocations with
  different compiler binaries and/or different
  text / bss / data / heap / stack / dso start locations.
! .IP \fB\-freport\-bug\fR 4
  .IX Item "-freport-bug"
  Collect and dump debug information into a temporary file if an
! internal compiler error (ICE) occurs.
! .IP \fB\-fdump\-unnumbered\fR 4
  .IX Item "-fdump-unnumbered"
  When doing debugging dumps, suppress instruction numbers and address output.
  This makes it more feasible to use diff on debugging dumps for compiler
  invocations with different options, in particular with and without
  \&\fB\-g\fR.
! .IP \fB\-fdump\-unnumbered\-links\fR 4
  .IX Item "-fdump-unnumbered-links"
  When doing debugging dumps (see \fB\-d\fR option above), suppress
  instruction numbers for the links to the previous and next instructions
  in a sequence.
! .IP \fB\-fdump\-ipa\-\fR\fIswitch\fR 4
  .IX Item "-fdump-ipa-switch"
  .PD 0
! .IP \fB\-fdump\-ipa\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR 4
  .IX Item "-fdump-ipa-switch-options"
  .PD
! Control the dumping at various stages of inter\-procedural analysis
  language tree to a file.  The file name is generated by appending a
  switch specific suffix to the source file name, and the file is created
  in the same directory as the output file.  The following dumps are
  possible:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
! Enables all inter\-procedural analysis dumps.
! .IP \fBcgraph\fR 4
  .IX Item "cgraph"
! Dumps information about call\-graph optimization, unused function removal,
  and inlining decisions.
! .IP \fBinline\fR 4
  .IX Item "inline"
  Dump after function inlining.
  .RE
*************** that were not inlined.
*** 18540,18554 ****
  .Sp
  By default, the dump will contain messages about successful
  optimizations (equivalent to \fB\-optimized\fR) together with
! low-level details about the analysis.
  .RE
! .IP "\fB\-fdump\-ipa\-clones\fR" 4
  .IX Item "-fdump-ipa-clones"
  Create a dump file containing information about creation of call graph
! node clones and removals of call graph nodes during inter-procedural
  optimizations and transformations.  Its main intended use is that tools
! that create live-patches can determine the set of functions that need to
! be live-patched to completely replace a particular function (see
  \&\fB\-flive\-patching\fR).  The file name is generated by appending
  suffix \f(CW\*(C`ipa\-clones\*(C'\fR to the source file name, and the file is
  created in the same directory as the output file.  Each entry in the
--- 18471,18485 ----
  .Sp
  By default, the dump will contain messages about successful
  optimizations (equivalent to \fB\-optimized\fR) together with
! low\-level details about the analysis.
  .RE
! .IP \fB\-fdump\-ipa\-clones\fR 4
  .IX Item "-fdump-ipa-clones"
  Create a dump file containing information about creation of call graph
! node clones and removals of call graph nodes during inter\-procedural
  optimizations and transformations.  Its main intended use is that tools
! that create live\-patches can determine the set of functions that need to
! be live\-patched to completely replace a particular function (see
  \&\fB\-flive\-patching\fR).  The file name is generated by appending
  suffix \f(CW\*(C`ipa\-clones\*(C'\fR to the source file name, and the file is
  created in the same directory as the output file.  Each entry in the
*************** file is on a separate line containing se
*** 18556,18677 ****
  .Sp
  In the case of call graph clone creation, the individual fields are:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  String \f(CW\*(C`Callgraph clone\*(C'\fR.
! .IP "2." 4
  .IX Item "2."
  Name of the function being cloned as it is presented to the assembler.
! .IP "3." 4
  .IX Item "3."
  A number that uniquely represents the function being cloned in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole-program analysis but is likely to be different in the two
  phases.
! .IP "4." 4
  .IX Item "4."
  The file name of the source file where the function is defined.
! .IP "5." 4
  .IX Item "5."
  The line on which the function definition is located.
! .IP "6." 4
  .IX Item "6."
  The column where the function definition is located.
! .IP "7." 4
  .IX Item "7."
  Name of the new function clone as it is presented to the assembler.
! .IP "8." 4
  .IX Item "8."
  A number that uniquely represents the new function clone in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole-program analysis but is likely to be different in the two
  phases.
! .IP "9." 4
  .IX Item "9."
  The file name of the source file where the source code location of the
  new clone points to.
! .IP "10." 4
  .IX Item "10."
  The line to which the source code location of the new clone points to.
! .IP "11." 4
  .IX Item "11."
  The column to which the source code location of the new clone points to.
! .IP "12." 4
  .IX Item "12."
  A string that determines the reason for cloning.
  .RE
  .RS 4
  .Sp
  In the case of call graph clone removal, the individual fields are:
! .IP "1." 4
  .IX Item "1."
  String \f(CW\*(C`Callgraph removal\*(C'\fR.
! .IP "2." 4
  .IX Item "2."
  Name of the function being removed as it would be presented to the assembler.
! .IP "3." 4
  .IX Item "3."
  A number that uniquely represents the function being cloned in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole-program analysis but is likely to be different in the two
  phases.
! .IP "4." 4
  .IX Item "4."
  The file name of the source file where the function is defined.
! .IP "5." 4
  .IX Item "5."
  The line on which the function definition is located.
! .IP "6." 4
  .IX Item "6."
  The column where the function definition is located.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdump\-lang\fR" 4
  .IX Item "-fdump-lang"
! Dump language-specific information.  The file name is made by appending
  \&\fI.lang\fR to the source file name.
! .IP "\fB\-fdump\-lang\-all\fR" 4
  .IX Item "-fdump-lang-all"
  .PD 0
! .IP "\fB\-fdump\-lang\-\fR\fIswitch\fR" 4
  .IX Item "-fdump-lang-switch"
! .IP "\fB\-fdump\-lang\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR" 4
  .IX Item "-fdump-lang-switch-options"
! .IP "\fB\-fdump\-lang\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR" 4
  .IX Item "-fdump-lang-switch-options=filename"
  .PD
! Control the dumping of language-specific information.  The \fIoptions\fR
  and \fIfilename\fR portions behave as described in the
  \&\fB\-fdump\-tree\fR option.  The following \fIswitch\fR values are
  accepted:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
! Enable all language-specific dumps.
! .IP "\fBclass\fR" 4
  .IX Item "class"
  Dump class hierarchy information.  Virtual table information is emitted
! unless '\fBslim\fR' is specified.  This option is applicable to \*(C+ only.
! .IP "\fBmodule\fR" 4
  .IX Item "module"
  Dump module information.  Options \fBlineno\fR (locations),
  \&\fBgraph\fR (reachability), \fBblocks\fR (clusters),
  \&\fBuid\fR (serialization), \fBalias\fR (mergeable),
  \&\fBasmname\fR (Elrond), \fBeh\fR (mapper) & \fBvops\fR
  (macros) may provide additional information.  This option is
! applicable to \*(C+ only.
! .IP "\fBraw\fR" 4
  .IX Item "raw"
! Dump the raw internal tree data.  This option is applicable to \*(C+ only.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdump\-passes\fR" 4
  .IX Item "-fdump-passes"
  Print on \fIstderr\fR the list of optimization passes that are turned
! on and off by the current command-line options.
! .IP "\fB\-fdump\-statistics\-\fR\fIoption\fR" 4
  .IX Item "-fdump-statistics-option"
  Enable and control dumping of pass statistics in a separate file.  The
  file name is generated by appending a suffix ending in
--- 18487,18608 ----
  .Sp
  In the case of call graph clone creation, the individual fields are:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  String \f(CW\*(C`Callgraph clone\*(C'\fR.
! .IP 2. 4
  .IX Item "2."
  Name of the function being cloned as it is presented to the assembler.
! .IP 3. 4
  .IX Item "3."
  A number that uniquely represents the function being cloned in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole\-program analysis but is likely to be different in the two
  phases.
! .IP 4. 4
  .IX Item "4."
  The file name of the source file where the function is defined.
! .IP 5. 4
  .IX Item "5."
  The line on which the function definition is located.
! .IP 6. 4
  .IX Item "6."
  The column where the function definition is located.
! .IP 7. 4
  .IX Item "7."
  Name of the new function clone as it is presented to the assembler.
! .IP 8. 4
  .IX Item "8."
  A number that uniquely represents the new function clone in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole\-program analysis but is likely to be different in the two
  phases.
! .IP 9. 4
  .IX Item "9."
  The file name of the source file where the source code location of the
  new clone points to.
! .IP 10. 4
  .IX Item "10."
  The line to which the source code location of the new clone points to.
! .IP 11. 4
  .IX Item "11."
  The column to which the source code location of the new clone points to.
! .IP 12. 4
  .IX Item "12."
  A string that determines the reason for cloning.
  .RE
  .RS 4
  .Sp
  In the case of call graph clone removal, the individual fields are:
! .IP 1. 4
  .IX Item "1."
  String \f(CW\*(C`Callgraph removal\*(C'\fR.
! .IP 2. 4
  .IX Item "2."
  Name of the function being removed as it would be presented to the assembler.
! .IP 3. 4
  .IX Item "3."
  A number that uniquely represents the function being cloned in the call
  graph.  Note that the number is unique only within a compilation unit or
! within whole\-program analysis but is likely to be different in the two
  phases.
! .IP 4. 4
  .IX Item "4."
  The file name of the source file where the function is defined.
! .IP 5. 4
  .IX Item "5."
  The line on which the function definition is located.
! .IP 6. 4
  .IX Item "6."
  The column where the function definition is located.
  .RE
  .RS 4
  .RE
! .IP \fB\-fdump\-lang\fR 4
  .IX Item "-fdump-lang"
! Dump language\-specific information.  The file name is made by appending
  \&\fI.lang\fR to the source file name.
! .IP \fB\-fdump\-lang\-all\fR 4
  .IX Item "-fdump-lang-all"
  .PD 0
! .IP \fB\-fdump\-lang\-\fR\fIswitch\fR 4
  .IX Item "-fdump-lang-switch"
! .IP \fB\-fdump\-lang\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR 4
  .IX Item "-fdump-lang-switch-options"
! .IP \fB\-fdump\-lang\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR 4
  .IX Item "-fdump-lang-switch-options=filename"
  .PD
! Control the dumping of language\-specific information.  The \fIoptions\fR
  and \fIfilename\fR portions behave as described in the
  \&\fB\-fdump\-tree\fR option.  The following \fIswitch\fR values are
  accepted:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
! Enable all language\-specific dumps.
! .IP \fBclass\fR 4
  .IX Item "class"
  Dump class hierarchy information.  Virtual table information is emitted
! unless \*(Aq\fBslim\fR\*(Aq is specified.  This option is applicable to C++ only.
! .IP \fBmodule\fR 4
  .IX Item "module"
  Dump module information.  Options \fBlineno\fR (locations),
  \&\fBgraph\fR (reachability), \fBblocks\fR (clusters),
  \&\fBuid\fR (serialization), \fBalias\fR (mergeable),
  \&\fBasmname\fR (Elrond), \fBeh\fR (mapper) & \fBvops\fR
  (macros) may provide additional information.  This option is
! applicable to C++ only.
! .IP \fBraw\fR 4
  .IX Item "raw"
! Dump the raw internal tree data.  This option is applicable to C++ only.
  .RE
  .RS 4
  .RE
! .IP \fB\-fdump\-passes\fR 4
  .IX Item "-fdump-passes"
  Print on \fIstderr\fR the list of optimization passes that are turned
! on and off by the current command\-line options.
! .IP \fB\-fdump\-statistics\-\fR\fIoption\fR 4
  .IX Item "-fdump-statistics-option"
  Enable and control dumping of pass statistics in a separate file.  The
  file name is generated by appending a suffix ending in
*************** form is used, \fB\-stats\fR causes count
*** 18681,18694 ****
  whole compilation unit while \fB\-details\fR dumps every event as
  the passes generate them.  The default with no option is to sum
  counters for each function compiled.
! .IP "\fB\-fdump\-tree\-all\fR" 4
  .IX Item "-fdump-tree-all"
  .PD 0
! .IP "\fB\-fdump\-tree\-\fR\fIswitch\fR" 4
  .IX Item "-fdump-tree-switch"
! .IP "\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR" 4
  .IX Item "-fdump-tree-switch-options"
! .IP "\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR" 4
  .IX Item "-fdump-tree-switch-options=filename"
  .PD
  Control the dumping at various stages of processing the intermediate
--- 18612,18625 ----
  whole compilation unit while \fB\-details\fR dumps every event as
  the passes generate them.  The default with no option is to sum
  counters for each function compiled.
! .IP \fB\-fdump\-tree\-all\fR 4
  .IX Item "-fdump-tree-all"
  .PD 0
! .IP \fB\-fdump\-tree\-\fR\fIswitch\fR 4
  .IX Item "-fdump-tree-switch"
! .IP \fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR 4
  .IX Item "-fdump-tree-switch-options"
! .IP \fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR 4
  .IX Item "-fdump-tree-switch-options=filename"
  .PD
  Control the dumping at various stages of processing the intermediate
*************** which control the details of the dump.
*** 18698,18785 ****
  to all dumps; those that are not meaningful are ignored.  The
  following options are available
  .RS 4
! .IP "\fBaddress\fR" 4
  .IX Item "address"
  Print the address of each node.  Usually this is not meaningful as it
  changes according to the environment and source file.  Its primary use
  is for tying up a dump file with a debug environment.
! .IP "\fBasmname\fR" 4
  .IX Item "asmname"
  If \f(CW\*(C`DECL_ASSEMBLER_NAME\*(C'\fR has been set for a given decl, use that
  in the dump instead of \f(CW\*(C`DECL_NAME\*(C'\fR.  Its primary use is ease of
  use working backward from mangled names in the assembly file.
! .IP "\fBslim\fR" 4
  .IX Item "slim"
! When dumping front-end intermediate representations, inhibit dumping
  of members of a scope or body of a function merely because that scope
  has been reached.  Only dump such items when they are directly reachable
  by some other path.
  .Sp
! When dumping pretty-printed trees, this option inhibits dumping the
  bodies of control structures.
  .Sp
! When dumping \s-1RTL,\s0 print the \s-1RTL\s0 in slim (condensed) form instead of
! the default LISP-like representation.
! .IP "\fBraw\fR" 4
  .IX Item "raw"
  Print a raw representation of the tree.  By default, trees are
! pretty-printed into a C\-like representation.
! .IP "\fBdetails\fR" 4
  .IX Item "details"
  Enable more detailed dumps (not honored by every dump option). Also
  include information from the optimization passes.
! .IP "\fBstats\fR" 4
  .IX Item "stats"
  Enable dumping various statistics about the pass (not honored by every dump
  option).
! .IP "\fBblocks\fR" 4
  .IX Item "blocks"
  Enable showing basic block boundaries (disabled in raw dumps).
! .IP "\fBgraph\fR" 4
  .IX Item "graph"
  For each of the other indicated dump files (\fB\-fdump\-rtl\-\fR\fIpass\fR),
  dump a representation of the control flow graph suitable for viewing with
! GraphViz to \fI\fIfile\fI.\fIpassid\fI.\fIpass\fI.dot\fR.  Each function in
! the file is pretty-printed as a subgraph, so that GraphViz can render them
  all in a single plot.
  .Sp
! This option currently only works for \s-1RTL\s0 dumps, and the \s-1RTL\s0 is always
  dumped in slim form.
! .IP "\fBvops\fR" 4
  .IX Item "vops"
  Enable showing virtual operands for every statement.
! .IP "\fBlineno\fR" 4
  .IX Item "lineno"
  Enable showing line numbers for statements.
! .IP "\fBuid\fR" 4
  .IX Item "uid"
! Enable showing the unique \s-1ID\s0 (\f(CW\*(C`DECL_UID\*(C'\fR) for each variable.
! .IP "\fBverbose\fR" 4
  .IX Item "verbose"
  Enable showing the tree dump for each statement.
! .IP "\fBeh\fR" 4
  .IX Item "eh"
! Enable showing the \s-1EH\s0 region number holding each statement.
! .IP "\fBscev\fR" 4
  .IX Item "scev"
  Enable showing scalar evolution analysis details.
! .IP "\fBoptimized\fR" 4
  .IX Item "optimized"
  Enable showing optimization information (only available in certain
  passes).
! .IP "\fBmissed\fR" 4
  .IX Item "missed"
  Enable showing missed optimization information (only available in certain
  passes).
! .IP "\fBnote\fR" 4
  .IX Item "note"
  Enable other detailed optimization information (only available in
  certain passes).
! .IP "\fBall\fR" 4
  .IX Item "all"
  Turn on all options, except \fBraw\fR, \fBslim\fR, \fBverbose\fR
  and \fBlineno\fR.
! .IP "\fBoptall\fR" 4
  .IX Item "optall"
  Turn on all optimization options, i.e., \fBoptimized\fR,
  \&\fBmissed\fR, and \fBnote\fR.
--- 18629,18716 ----
  to all dumps; those that are not meaningful are ignored.  The
  following options are available
  .RS 4
! .IP \fBaddress\fR 4
  .IX Item "address"
  Print the address of each node.  Usually this is not meaningful as it
  changes according to the environment and source file.  Its primary use
  is for tying up a dump file with a debug environment.
! .IP \fBasmname\fR 4
  .IX Item "asmname"
  If \f(CW\*(C`DECL_ASSEMBLER_NAME\*(C'\fR has been set for a given decl, use that
  in the dump instead of \f(CW\*(C`DECL_NAME\*(C'\fR.  Its primary use is ease of
  use working backward from mangled names in the assembly file.
! .IP \fBslim\fR 4
  .IX Item "slim"
! When dumping front\-end intermediate representations, inhibit dumping
  of members of a scope or body of a function merely because that scope
  has been reached.  Only dump such items when they are directly reachable
  by some other path.
  .Sp
! When dumping pretty\-printed trees, this option inhibits dumping the
  bodies of control structures.
  .Sp
! When dumping RTL, print the RTL in slim (condensed) form instead of
! the default LISP\-like representation.
! .IP \fBraw\fR 4
  .IX Item "raw"
  Print a raw representation of the tree.  By default, trees are
! pretty\-printed into a C\-like representation.
! .IP \fBdetails\fR 4
  .IX Item "details"
  Enable more detailed dumps (not honored by every dump option). Also
  include information from the optimization passes.
! .IP \fBstats\fR 4
  .IX Item "stats"
  Enable dumping various statistics about the pass (not honored by every dump
  option).
! .IP \fBblocks\fR 4
  .IX Item "blocks"
  Enable showing basic block boundaries (disabled in raw dumps).
! .IP \fBgraph\fR 4
  .IX Item "graph"
  For each of the other indicated dump files (\fB\-fdump\-rtl\-\fR\fIpass\fR),
  dump a representation of the control flow graph suitable for viewing with
! GraphViz to \fIfile.passid.pass.dot\fR.  Each function in
! the file is pretty\-printed as a subgraph, so that GraphViz can render them
  all in a single plot.
  .Sp
! This option currently only works for RTL dumps, and the RTL is always
  dumped in slim form.
! .IP \fBvops\fR 4
  .IX Item "vops"
  Enable showing virtual operands for every statement.
! .IP \fBlineno\fR 4
  .IX Item "lineno"
  Enable showing line numbers for statements.
! .IP \fBuid\fR 4
  .IX Item "uid"
! Enable showing the unique ID (\f(CW\*(C`DECL_UID\*(C'\fR) for each variable.
! .IP \fBverbose\fR 4
  .IX Item "verbose"
  Enable showing the tree dump for each statement.
! .IP \fBeh\fR 4
  .IX Item "eh"
! Enable showing the EH region number holding each statement.
! .IP \fBscev\fR 4
  .IX Item "scev"
  Enable showing scalar evolution analysis details.
! .IP \fBoptimized\fR 4
  .IX Item "optimized"
  Enable showing optimization information (only available in certain
  passes).
! .IP \fBmissed\fR 4
  .IX Item "missed"
  Enable showing missed optimization information (only available in certain
  passes).
! .IP \fBnote\fR 4
  .IX Item "note"
  Enable other detailed optimization information (only available in
  certain passes).
! .IP \fBall\fR 4
  .IX Item "all"
  Turn on all options, except \fBraw\fR, \fBslim\fR, \fBverbose\fR
  and \fBlineno\fR.
! .IP \fBoptall\fR 4
  .IX Item "optall"
  Turn on all optimization options, i.e., \fBoptimized\fR,
  \&\fBmissed\fR, and \fBnote\fR.
*************** Turn on all optimization options, i.e.,
*** 18788,18827 ****
  .Sp
  To determine what tree dumps are available or find the dump for a pass
  of interest follow the steps below.
! .IP "1." 4
  .IX Item "1."
! Invoke \s-1GCC\s0 with \fB\-fdump\-passes\fR and in the \fIstderr\fR output
  look for a code that corresponds to the pass you are interested in.
  For example, the codes \f(CW\*(C`tree\-evrp\*(C'\fR, \f(CW\*(C`tree\-vrp1\*(C'\fR, and
  \&\f(CW\*(C`tree\-vrp2\*(C'\fR correspond to the three Value Range Propagation passes.
  The number at the end distinguishes distinct invocations of the same pass.
! .IP "2." 4
  .IX Item "2."
  To enable the creation of the dump file, append the pass code to
! the \fB\-fdump\-\fR option prefix and invoke \s-1GCC\s0 with it.  For example,
  to enable the dump from the Early Value Range Propagation pass, invoke
! \&\s-1GCC\s0 with the \fB\-fdump\-tree\-evrp\fR option.  Optionally, you may
! specify the name of the dump file.  If you don't specify one, \s-1GCC\s0
  creates as described below.
! .IP "3." 4
  .IX Item "3."
  Find the pass dump in a file whose name is composed of three components
! separated by a period: the name of the source file \s-1GCC\s0 was invoked to
  compile, a numeric suffix indicating the pass number followed by the
! letter \fBt\fR for tree passes (and the letter \fBr\fR for \s-1RTL\s0 passes),
! and finally the pass code.  For example, the Early \s-1VRP\s0 pass dump might
  be in a file named \fImyfile.c.038t.evrp\fR in the current working
  directory.  Note that the numeric codes are not stable and may change
! from one version of \s-1GCC\s0 to another.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fopt\-info\fR" 4
  .IX Item "-fopt-info"
  .PD 0
! .IP "\fB\-fopt\-info\-\fR\fIoptions\fR" 4
  .IX Item "-fopt-info-options"
! .IP "\fB\-fopt\-info\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR" 4
  .IX Item "-fopt-info-options=filename"
  .PD
  Controls optimization dumps from various optimization passes. If the
--- 18719,18758 ----
  .Sp
  To determine what tree dumps are available or find the dump for a pass
  of interest follow the steps below.
! .IP 1. 4
  .IX Item "1."
! Invoke GCC with \fB\-fdump\-passes\fR and in the \fIstderr\fR output
  look for a code that corresponds to the pass you are interested in.
  For example, the codes \f(CW\*(C`tree\-evrp\*(C'\fR, \f(CW\*(C`tree\-vrp1\*(C'\fR, and
  \&\f(CW\*(C`tree\-vrp2\*(C'\fR correspond to the three Value Range Propagation passes.
  The number at the end distinguishes distinct invocations of the same pass.
! .IP 2. 4
  .IX Item "2."
  To enable the creation of the dump file, append the pass code to
! the \fB\-fdump\-\fR option prefix and invoke GCC with it.  For example,
  to enable the dump from the Early Value Range Propagation pass, invoke
! GCC with the \fB\-fdump\-tree\-evrp\fR option.  Optionally, you may
! specify the name of the dump file.  If you don\*(Aqt specify one, GCC
  creates as described below.
! .IP 3. 4
  .IX Item "3."
  Find the pass dump in a file whose name is composed of three components
! separated by a period: the name of the source file GCC was invoked to
  compile, a numeric suffix indicating the pass number followed by the
! letter \fBt\fR for tree passes (and the letter \fBr\fR for RTL passes),
! and finally the pass code.  For example, the Early VRP pass dump might
  be in a file named \fImyfile.c.038t.evrp\fR in the current working
  directory.  Note that the numeric codes are not stable and may change
! from one version of GCC to another.
  .RE
  .RS 4
  .RE
! .IP \fB\-fopt\-info\fR 4
  .IX Item "-fopt-info"
  .PD 0
! .IP \fB\-fopt\-info\-\fR\fIoptions\fR 4
  .IX Item "-fopt-info-options"
! .IP \fB\-fopt\-info\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR 4
  .IX Item "-fopt-info-options=filename"
  .PD
  Controls optimization dumps from various optimization passes. If the
*************** optimizations.
*** 18831,18869 ****
  .Sp
  The \fIoptions\fR can be divided into three groups:
  .RS 4
! .IP "1." 4
  .IX Item "1."
  options describing what kinds of messages should be emitted,
! .IP "2." 4
  .IX Item "2."
  options describing the verbosity of the dump, and
! .IP "3." 4
  .IX Item "3."
  options describing which optimizations should be included.
  .RE
  .RS 4
  .Sp
  The options from each group can be freely mixed as they are
! non-overlapping. However, in case of any conflicts,
  the later options override the earlier options on the command
  line.
  .Sp
  The following options control which kinds of messages should be emitted:
! .IP "\fBoptimized\fR" 4
  .IX Item "optimized"
  Print information when an optimization is successfully applied. It is
  up to a pass to decide which information is relevant. For example, the
  vectorizer passes print the source location of loops which are
  successfully vectorized.
! .IP "\fBmissed\fR" 4
  .IX Item "missed"
  Print information about missed optimizations. Individual passes
  control which information to include in the output.
! .IP "\fBnote\fR" 4
  .IX Item "note"
  Print verbose information about optimizations, such as certain
  transformations, more detailed messages about decisions etc.
! .IP "\fBall\fR" 4
  .IX Item "all"
  Print detailed optimization information. This includes
  \&\fBoptimized\fR, \fBmissed\fR, and \fBnote\fR.
--- 18762,18800 ----
  .Sp
  The \fIoptions\fR can be divided into three groups:
  .RS 4
! .IP 1. 4
  .IX Item "1."
  options describing what kinds of messages should be emitted,
! .IP 2. 4
  .IX Item "2."
  options describing the verbosity of the dump, and
! .IP 3. 4
  .IX Item "3."
  options describing which optimizations should be included.
  .RE
  .RS 4
  .Sp
  The options from each group can be freely mixed as they are
! non\-overlapping. However, in case of any conflicts,
  the later options override the earlier options on the command
  line.
  .Sp
  The following options control which kinds of messages should be emitted:
! .IP \fBoptimized\fR 4
  .IX Item "optimized"
  Print information when an optimization is successfully applied. It is
  up to a pass to decide which information is relevant. For example, the
  vectorizer passes print the source location of loops which are
  successfully vectorized.
! .IP \fBmissed\fR 4
  .IX Item "missed"
  Print information about missed optimizations. Individual passes
  control which information to include in the output.
! .IP \fBnote\fR 4
  .IX Item "note"
  Print verbose information about optimizations, such as certain
  transformations, more detailed messages about decisions etc.
! .IP \fBall\fR 4
  .IX Item "all"
  Print detailed optimization information. This includes
  \&\fBoptimized\fR, \fBmissed\fR, and \fBnote\fR.
*************** Print detailed optimization information.
*** 18871,18902 ****
  .RS 4
  .Sp
  The following option controls the dump verbosity:
! .IP "\fBinternals\fR" 4
  .IX Item "internals"
! By default, only \*(L"high-level\*(R" messages are emitted. This option enables
  additional, more detailed, messages, which are likely to only be of interest
! to \s-1GCC\s0 developers.
  .RE
  .RS 4
  .Sp
  One or more of the following option keywords can be used to describe a
  group of optimizations:
! .IP "\fBipa\fR" 4
  .IX Item "ipa"
  Enable dumps from all interprocedural optimizations.
! .IP "\fBloop\fR" 4
  .IX Item "loop"
  Enable dumps from all loop optimizations.
! .IP "\fBinline\fR" 4
  .IX Item "inline"
  Enable dumps from all inlining optimizations.
! .IP "\fBomp\fR" 4
  .IX Item "omp"
! Enable dumps from all \s-1OMP\s0 (Offloading and Multi Processing) optimizations.
! .IP "\fBvec\fR" 4
  .IX Item "vec"
  Enable dumps from all vectorization optimizations.
! .IP "\fBoptall\fR" 4
  .IX Item "optall"
  Enable dumps from all optimizations. This is a superset of
  the optimization groups listed above.
--- 18802,18833 ----
  .RS 4
  .Sp
  The following option controls the dump verbosity:
! .IP \fBinternals\fR 4
  .IX Item "internals"
! By default, only "high\-level" messages are emitted. This option enables
  additional, more detailed, messages, which are likely to only be of interest
! to GCC developers.
  .RE
  .RS 4
  .Sp
  One or more of the following option keywords can be used to describe a
  group of optimizations:
! .IP \fBipa\fR 4
  .IX Item "ipa"
  Enable dumps from all interprocedural optimizations.
! .IP \fBloop\fR 4
  .IX Item "loop"
  Enable dumps from all loop optimizations.
! .IP \fBinline\fR 4
  .IX Item "inline"
  Enable dumps from all inlining optimizations.
! .IP \fBomp\fR 4
  .IX Item "omp"
! Enable dumps from all OMP (Offloading and Multi Processing) optimizations.
! .IP \fBvec\fR 4
  .IX Item "vec"
  Enable dumps from all vectorization optimizations.
! .IP \fBoptall\fR 4
  .IX Item "optall"
  Enable dumps from all optimizations. This is a superset of
  the optimization groups listed above.
*************** the optimization groups listed above.
*** 18904,18912 ****
  .RS 4
  .Sp
  If \fIoptions\fR is
! omitted, it defaults to \fBoptimized-optall\fR, which means to dump messages
  about successful optimizations from all the passes, omitting messages
! that are treated as \*(L"internals\*(R".
  .Sp
  If the \fIfilename\fR is provided, then the dumps from all the
  applicable optimizations are concatenated into the \fIfilename\fR.
--- 18835,18843 ----
  .RS 4
  .Sp
  If \fIoptions\fR is
! omitted, it defaults to \fBoptimized\-optall\fR, which means to dump messages
  about successful optimizations from all the passes, omitting messages
! that are treated as "internals".
  .Sp
  If the \fIfilename\fR is provided, then the dumps from all the
  applicable optimizations are concatenated into the \fIfilename\fR.
*************** the first option takes effect and the su
*** 18968,19004 ****
  ignored. Thus only \fIvec.miss\fR is produced which contains
  dumps from the vectorizer about missed opportunities.
  .RE
! .IP "\fB\-fsave\-optimization\-record\fR" 4
  .IX Item "-fsave-optimization-record"
! Write a \s-1SRCFILE\s0.opt\-record.json.gz file detailing what optimizations
  were performed, for those optimizations that support \fB\-fopt\-info\fR.
  .Sp
  This option is experimental and the format of the data within the
! compressed \s-1JSON\s0 file is subject to change.
  .Sp
! It is roughly equivalent to a machine-readable version of
  \&\fB\-fopt\-info\-all\fR, as a collection of messages with source file,
  line number and column number, with the following additional data for
  each message:
  .RS 4
! .IP "*" 4
  the execution count of the code being optimized, along with metadata about
  whether this was from actual profile data, or just an estimate, allowing
  consumers to prioritize messages by code hotness,
! .IP "*" 4
  the function name of the code being optimized, where applicable,
! .IP "*" 4
! the \*(L"inlining chain\*(R" for the code being optimized, so that when
  a function is inlined into several different places (which might
  themselves be inlined), the reader can distinguish between the copies,
! .IP "*" 4
  objects identifying those parts of the message that refer to expressions,
! statements or symbol-table nodes, which of these categories they are, and,
  when available, their source code location,
! .IP "*" 4
! the \s-1GCC\s0 pass that emitted the message, and
! .IP "*" 4
! the location in \s-1GCC\s0's own code from which the message was emitted
  .RE
  .RS 4
  .Sp
--- 18899,18935 ----
  ignored. Thus only \fIvec.miss\fR is produced which contains
  dumps from the vectorizer about missed opportunities.
  .RE
! .IP \fB\-fsave\-optimization\-record\fR 4
  .IX Item "-fsave-optimization-record"
! Write a SRCFILE.opt\-record.json.gz file detailing what optimizations
  were performed, for those optimizations that support \fB\-fopt\-info\fR.
  .Sp
  This option is experimental and the format of the data within the
! compressed JSON file is subject to change.
  .Sp
! It is roughly equivalent to a machine\-readable version of
  \&\fB\-fopt\-info\-all\fR, as a collection of messages with source file,
  line number and column number, with the following additional data for
  each message:
  .RS 4
! .IP * 4
  the execution count of the code being optimized, along with metadata about
  whether this was from actual profile data, or just an estimate, allowing
  consumers to prioritize messages by code hotness,
! .IP * 4
  the function name of the code being optimized, where applicable,
! .IP * 4
! the "inlining chain" for the code being optimized, so that when
  a function is inlined into several different places (which might
  themselves be inlined), the reader can distinguish between the copies,
! .IP * 4
  objects identifying those parts of the message that refer to expressions,
! statements or symbol\-table nodes, which of these categories they are, and,
  when available, their source code location,
! .IP * 4
! the GCC pass that emitted the message, and
! .IP * 4
! the location in GCC\*(Aqs own code from which the message was emitted
  .RE
  .RS 4
  .Sp
*************** Additionally, some messages are logicall
*** 19006,19012 ****
  messages, reflecting implementation details of the optimization
  passes.
  .RE
! .IP "\fB\-fsched\-verbose=\fR\fIn\fR" 4
  .IX Item "-fsched-verbose=n"
  On targets that use instruction scheduling, this option controls the
  amount of debugging output the scheduler prints to the dump files.
--- 18937,18943 ----
  messages, reflecting implementation details of the optimization
  passes.
  .RE
! .IP \fB\-fsched\-verbose=\fR\fIn\fR 4
  .IX Item "-fsched-verbose=n"
  On targets that use instruction scheduling, this option controls the
  amount of debugging output the scheduler prints to the dump files.
*************** For \fIn\fR greater than zero, \fB\-fsch
*** 19015,19080 ****
  same information as \fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR.
  For \fIn\fR greater than one, it also output basic block probabilities,
  detailed ready list information and unit/insn info.  For \fIn\fR greater
! than two, it includes \s-1RTL\s0 at abort point, control-flow and regions info.
  And for \fIn\fR over four, \fB\-fsched\-verbose\fR also includes
  dependence info.
! .IP "\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR" 4
  .IX Item "-fenable-kind-pass"
  .PD 0
! .IP "\fB\-fdisable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
  .IX Item "-fdisable-kind-pass=range-list"
  .PD
  This is a set of options that are used to explicitly disable/enable
! optimization passes.  These options are intended for use for debugging \s-1GCC.\s0
  Compiler users should use regular options for enabling/disabling
  passes instead.
  .RS 4
! .IP "\fB\-fdisable\-ipa\-\fR\fIpass\fR" 4
  .IX Item "-fdisable-ipa-pass"
! Disable \s-1IPA\s0 pass \fIpass\fR. \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
  appended with a sequential number starting from 1.
! .IP "\fB\-fdisable\-rtl\-\fR\fIpass\fR" 4
  .IX Item "-fdisable-rtl-pass"
  .PD 0
! .IP "\fB\-fdisable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
  .IX Item "-fdisable-rtl-pass=range-list"
  .PD
! Disable \s-1RTL\s0 pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
! appended with a sequential number starting from 1.  \fIrange-list\fR is a 
! comma-separated list of function ranges or assembler names.  Each range is a number
  pair separated by a colon.  The range is inclusive in both ends.  If the range
  is trivial, the number pair can be simplified as a single number.  If the
! function's call graph node's \fIuid\fR falls within one of the specified ranges,
  the \fIpass\fR is disabled for that function.  The \fIuid\fR is shown in the
  function header of a dump file, and the pass names can be dumped by using
  option \fB\-fdump\-passes\fR.
! .IP "\fB\-fdisable\-tree\-\fR\fIpass\fR" 4
  .IX Item "-fdisable-tree-pass"
  .PD 0
! .IP "\fB\-fdisable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
  .IX Item "-fdisable-tree-pass=range-list"
  .PD
  Disable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description of
  option arguments.
! .IP "\fB\-fenable\-ipa\-\fR\fIpass\fR" 4
  .IX Item "-fenable-ipa-pass"
! Enable \s-1IPA\s0 pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
  appended with a sequential number starting from 1.
! .IP "\fB\-fenable\-rtl\-\fR\fIpass\fR" 4
  .IX Item "-fenable-rtl-pass"
  .PD 0
! .IP "\fB\-fenable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
  .IX Item "-fenable-rtl-pass=range-list"
  .PD
! Enable \s-1RTL\s0 pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for option argument
  description and examples.
! .IP "\fB\-fenable\-tree\-\fR\fIpass\fR" 4
  .IX Item "-fenable-tree-pass"
  .PD 0
! .IP "\fB\-fenable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
  .IX Item "-fenable-tree-pass=range-list"
  .PD
  Enable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description
--- 18946,19011 ----
  same information as \fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR.
  For \fIn\fR greater than one, it also output basic block probabilities,
  detailed ready list information and unit/insn info.  For \fIn\fR greater
! than two, it includes RTL at abort point, control\-flow and regions info.
  And for \fIn\fR over four, \fB\-fsched\-verbose\fR also includes
  dependence info.
! .IP \fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR 4
  .IX Item "-fenable-kind-pass"
  .PD 0
! .IP \fB\-fdisable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR 4
  .IX Item "-fdisable-kind-pass=range-list"
  .PD
  This is a set of options that are used to explicitly disable/enable
! optimization passes.  These options are intended for use for debugging GCC.
  Compiler users should use regular options for enabling/disabling
  passes instead.
  .RS 4
! .IP \fB\-fdisable\-ipa\-\fR\fIpass\fR 4
  .IX Item "-fdisable-ipa-pass"
! Disable IPA pass \fIpass\fR. \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
  appended with a sequential number starting from 1.
! .IP \fB\-fdisable\-rtl\-\fR\fIpass\fR 4
  .IX Item "-fdisable-rtl-pass"
  .PD 0
! .IP \fB\-fdisable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR 4
  .IX Item "-fdisable-rtl-pass=range-list"
  .PD
! Disable RTL pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
! appended with a sequential number starting from 1.  \fIrange\-list\fR is a 
! comma\-separated list of function ranges or assembler names.  Each range is a number
  pair separated by a colon.  The range is inclusive in both ends.  If the range
  is trivial, the number pair can be simplified as a single number.  If the
! function\*(Aqs call graph node\*(Aqs \fIuid\fR falls within one of the specified ranges,
  the \fIpass\fR is disabled for that function.  The \fIuid\fR is shown in the
  function header of a dump file, and the pass names can be dumped by using
  option \fB\-fdump\-passes\fR.
! .IP \fB\-fdisable\-tree\-\fR\fIpass\fR 4
  .IX Item "-fdisable-tree-pass"
  .PD 0
! .IP \fB\-fdisable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR 4
  .IX Item "-fdisable-tree-pass=range-list"
  .PD
  Disable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description of
  option arguments.
! .IP \fB\-fenable\-ipa\-\fR\fIpass\fR 4
  .IX Item "-fenable-ipa-pass"
! Enable IPA pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
  statically invoked in the compiler multiple times, the pass name should be
  appended with a sequential number starting from 1.
! .IP \fB\-fenable\-rtl\-\fR\fIpass\fR 4
  .IX Item "-fenable-rtl-pass"
  .PD 0
! .IP \fB\-fenable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR 4
  .IX Item "-fenable-rtl-pass=range-list"
  .PD
! Enable RTL pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for option argument
  description and examples.
! .IP \fB\-fenable\-tree\-\fR\fIpass\fR 4
  .IX Item "-fenable-tree-pass"
  .PD 0
! .IP \fB\-fenable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange\-list\fR 4
  .IX Item "-fenable-tree-pass=range-list"
  .PD
  Enable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description
*************** Here are some examples showing uses of t
*** 19101,19118 ****
  \&           \-fenable\-tree\-unroll
  .Ve
  .RE
! .IP "\fB\-fchecking\fR" 4
  .IX Item "-fchecking"
  .PD 0
! .IP "\fB\-fchecking=\fR\fIn\fR" 4
  .IX Item "-fchecking=n"
  .PD
  Enable internal consistency checking.  The default depends on
  the compiler configuration.  \fB\-fchecking=2\fR enables further
  internal consistency checking that might affect code generation.
! .IP "\fB\-frandom\-seed=\fR\fIstring\fR" 4
  .IX Item "-frandom-seed=string"
! This option provides a seed that \s-1GCC\s0 uses in place of
  random numbers in generating certain symbol names
  that have to be different in every compiled file.  It is also used to
  place unique stamps in coverage data files and the object files that
--- 19032,19049 ----
  \&           \-fenable\-tree\-unroll
  .Ve
  .RE
! .IP \fB\-fchecking\fR 4
  .IX Item "-fchecking"
  .PD 0
! .IP \fB\-fchecking=\fR\fIn\fR 4
  .IX Item "-fchecking=n"
  .PD
  Enable internal consistency checking.  The default depends on
  the compiler configuration.  \fB\-fchecking=2\fR enables further
  internal consistency checking that might affect code generation.
! .IP \fB\-frandom\-seed=\fR\fIstring\fR 4
  .IX Item "-frandom-seed=string"
! This option provides a seed that GCC uses in place of
  random numbers in generating certain symbol names
  that have to be different in every compiled file.  It is also used to
  place unique stamps in coverage data files and the object files that
*************** produce them.  You can use the \fB\-fran
*** 19120,19153 ****
  reproducibly identical object files.
  .Sp
  The \fIstring\fR can either be a number (decimal, octal or hex) or an
! arbitrary string (in which case it's converted to a number by
! computing \s-1CRC32\s0).
  .Sp
  The \fIstring\fR should be different for every file you compile.
! .IP "\fB\-save\-temps\fR" 4
  .IX Item "-save-temps"
! Store the usual \*(L"temporary\*(R" intermediate files permanently; name them
  as auxiliary output files, as specified described under
  \&\fB\-dumpbase\fR and \fB\-dumpdir\fR.
  .Sp
! When used in combination with the \fB\-x\fR command-line option,
  \&\fB\-save\-temps\fR is sensible enough to avoid overwriting an
  input source file with the same extension as an intermediate file.
  The corresponding intermediate file may be obtained by renaming the
  source file before using \fB\-save\-temps\fR.
! .IP "\fB\-save\-temps=cwd\fR" 4
  .IX Item "-save-temps=cwd"
  Equivalent to \fB\-save\-temps \-dumpdir ./\fR.
! .IP "\fB\-save\-temps=obj\fR" 4
  .IX Item "-save-temps=obj"
! Equivalent to \fB\-save\-temps \-dumpdir \f(BIoutdir/\fB\fR, where
  \&\fIoutdir/\fR is the directory of the output file specified after the
  \&\fB\-o\fR option, including any directory separators.  If the
  \&\fB\-o\fR option is not used, the \fB\-save\-temps=obj\fR switch
  behaves like \fB\-save\-temps=cwd\fR.
! .IP "\fB\-time\fR[\fB=\fR\fIfile\fR]" 4
  .IX Item "-time[=file]"
! Report the \s-1CPU\s0 time taken by each subprocess in the compilation
  sequence.  For C source files, this is the compiler proper and assembler
  (plus the linker if linking is done).
  .Sp
--- 19051,19084 ----
  reproducibly identical object files.
  .Sp
  The \fIstring\fR can either be a number (decimal, octal or hex) or an
! arbitrary string (in which case it\*(Aqs converted to a number by
! computing CRC32).
  .Sp
  The \fIstring\fR should be different for every file you compile.
! .IP \fB\-save\-temps\fR 4
  .IX Item "-save-temps"
! Store the usual "temporary" intermediate files permanently; name them
  as auxiliary output files, as specified described under
  \&\fB\-dumpbase\fR and \fB\-dumpdir\fR.
  .Sp
! When used in combination with the \fB\-x\fR command\-line option,
  \&\fB\-save\-temps\fR is sensible enough to avoid overwriting an
  input source file with the same extension as an intermediate file.
  The corresponding intermediate file may be obtained by renaming the
  source file before using \fB\-save\-temps\fR.
! .IP \fB\-save\-temps=cwd\fR 4
  .IX Item "-save-temps=cwd"
  Equivalent to \fB\-save\-temps \-dumpdir ./\fR.
! .IP \fB\-save\-temps=obj\fR 4
  .IX Item "-save-temps=obj"
! Equivalent to \fB\-save\-temps \-dumpdir \fR\f(BIoutdir/\fR, where
  \&\fIoutdir/\fR is the directory of the output file specified after the
  \&\fB\-o\fR option, including any directory separators.  If the
  \&\fB\-o\fR option is not used, the \fB\-save\-temps=obj\fR switch
  behaves like \fB\-save\-temps=cwd\fR.
! .IP \fB\-time\fR[\fB=\fR\fIfile\fR] 4
  .IX Item "-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).
  .Sp
*************** Without the specification of an output f
*** 19158,19165 ****
  \&        # as 0.00 0.01
  .Ve
  .Sp
! The first number on each line is the \*(L"user time\*(R", that is time spent
! executing the program itself.  The second number is \*(L"system time\*(R",
  time spent executing operating system routines on behalf of the program.
  Both numbers are in seconds.
  .Sp
--- 19089,19096 ----
  \&        # as 0.00 0.01
  .Ve
  .Sp
! 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.
  .Sp
*************** named file, and it looks like this:
*** 19171,19186 ****
  \&        0.00 0.01 as 
  .Ve
  .Sp
! The \*(L"user time\*(R" and the \*(L"system time\*(R" are moved before the program
  name, and the options passed to the program are displayed, so that one
  can later tell what file was being compiled, and with which options.
! .IP "\fB\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR]" 4
  .IX Item "-fdump-final-insns[=file]"
! Dump the final internal representation (\s-1RTL\s0) to \fIfile\fR.  If the
  optional argument is omitted (or if \fIfile\fR is \f(CW\*(C`.\*(C'\fR), the name
  of the dump file is determined by appending \f(CW\*(C`.gkd\*(C'\fR to the
  dump base name, see \fB\-dumpbase\fR.
! .IP "\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]" 4
  .IX Item "-fcompare-debug[=opts]"
  If no error occurs during compilation, run the compiler a second time,
  adding \fIopts\fR and \fB\-fcompare\-debug\-second\fR to the arguments
--- 19102,19117 ----
  \&        0.00 0.01 as 
  .Ve
  .Sp
! 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.
! .IP \fB\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR] 4
  .IX Item "-fdump-final-insns[=file]"
! Dump the final internal representation (RTL) to \fIfile\fR.  If the
  optional argument is omitted (or if \fIfile\fR is \f(CW\*(C`.\*(C'\fR), the name
  of the dump file is determined by appending \f(CW\*(C`.gkd\*(C'\fR to the
  dump base name, see \fB\-dumpbase\fR.
! .IP \fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR] 4
  .IX Item "-fcompare-debug[=opts]"
  If no error occurs during compilation, run the compiler a second time,
  adding \fIopts\fR and \fB\-fcompare\-debug\-second\fR to the arguments
*************** representation in both compilations, and
*** 19189,19212 ****
  .Sp
  If the equal sign is omitted, the default \fB\-gtoggle\fR is used.
  .Sp
! The environment variable \fB\s-1GCC_COMPARE_DEBUG\s0\fR, if defined, non-empty
  and nonzero, implicitly enables \fB\-fcompare\-debug\fR.  If
! \&\fB\s-1GCC_COMPARE_DEBUG\s0\fR is defined to a string starting with a dash,
  then it is used for \fIopts\fR, otherwise the default \fB\-gtoggle\fR
  is used.
  .Sp
  \&\fB\-fcompare\-debug=\fR, with the equal sign but without \fIopts\fR,
  is equivalent to \fB\-fno\-compare\-debug\fR, which disables the dumping
  of the final representation and the second compilation, preventing even
! \&\fB\s-1GCC_COMPARE_DEBUG\s0\fR from taking effect.
  .Sp
  To verify full coverage during \fB\-fcompare\-debug\fR testing, set
! \&\fB\s-1GCC_COMPARE_DEBUG\s0\fR to say \fB\-fcompare\-debug\-not\-overridden\fR,
! which \s-1GCC\s0 rejects as an invalid option in any actual compilation
  (rather than preprocessing, assembly or linking).  To get just a
! warning, setting \fB\s-1GCC_COMPARE_DEBUG\s0\fR to \fB\-w%n\-fcompare\-debug
  not overridden\fR will do.
! .IP "\fB\-fcompare\-debug\-second\fR" 4
  .IX Item "-fcompare-debug-second"
  This option is implicitly passed to the compiler for the second
  compilation requested by \fB\-fcompare\-debug\fR, along with options to
--- 19120,19143 ----
  .Sp
  If the equal sign is omitted, the default \fB\-gtoggle\fR is used.
  .Sp
! The environment variable \fBGCC_COMPARE_DEBUG\fR, if defined, non\-empty
  and nonzero, implicitly enables \fB\-fcompare\-debug\fR.  If
! \&\fBGCC_COMPARE_DEBUG\fR is defined to a string starting with a dash,
  then it is used for \fIopts\fR, otherwise the default \fB\-gtoggle\fR
  is used.
  .Sp
  \&\fB\-fcompare\-debug=\fR, with the equal sign but without \fIopts\fR,
  is equivalent to \fB\-fno\-compare\-debug\fR, which disables the dumping
  of the final representation and the second compilation, preventing even
! \&\fBGCC_COMPARE_DEBUG\fR from taking effect.
  .Sp
  To verify full coverage during \fB\-fcompare\-debug\fR testing, set
! \&\fBGCC_COMPARE_DEBUG\fR to say \fB\-fcompare\-debug\-not\-overridden\fR,
! which GCC rejects as an invalid option in any actual compilation
  (rather than preprocessing, assembly or linking).  To get just a
! warning, setting \fBGCC_COMPARE_DEBUG\fR to \fB\-w%n\-fcompare\-debug
  not overridden\fR will do.
! .IP \fB\-fcompare\-debug\-second\fR 4
  .IX Item "-fcompare-debug-second"
  This option is implicitly passed to the compiler for the second
  compilation requested by \fB\-fcompare\-debug\fR, along with options to
*************** overwriting those generated by the first
*** 19219,19225 ****
  When this option is passed to the compiler driver, it causes the
  \&\fIfirst\fR compilation to be skipped, which makes it useful for little
  other than debugging the compiler proper.
! .IP "\fB\-gtoggle\fR" 4
  .IX Item "-gtoggle"
  Turn off generation of debug info, if leaving out this option
  generates it, or turn it on at level 2 otherwise.  The position of this
--- 19150,19156 ----
  When this option is passed to the compiler driver, it causes the
  \&\fIfirst\fR compilation to be skipped, which makes it useful for little
  other than debugging the compiler proper.
! .IP \fB\-gtoggle\fR 4
  .IX Item "-gtoggle"
  Turn off generation of debug info, if leaving out this option
  generates it, or turn it on at level 2 otherwise.  The position of this
*************** argument in the command line does not ma
*** 19227,19289 ****
  other options are processed, and it does so only once, no matter how
  many times it is given.  This is mainly intended to be used with
  \&\fB\-fcompare\-debug\fR.
! .IP "\fB\-fvar\-tracking\-assignments\-toggle\fR" 4
  .IX Item "-fvar-tracking-assignments-toggle"
  Toggle \fB\-fvar\-tracking\-assignments\fR, in the same way that
  \&\fB\-gtoggle\fR toggles \fB\-g\fR.
! .IP "\fB\-Q\fR" 4
  .IX Item "-Q"
  Makes the compiler print out each function name as it is compiled, and
  print some statistics about each pass when it finishes.
! .IP "\fB\-ftime\-report\fR" 4
  .IX Item "-ftime-report"
  Makes the compiler print some statistics about the time consumed by each
  pass when it finishes.
! .IP "\fB\-ftime\-report\-details\fR" 4
  .IX Item "-ftime-report-details"
  Record the time consumed by infrastructure parts separately for each pass.
! .IP "\fB\-fira\-verbose=\fR\fIn\fR" 4
  .IX Item "-fira-verbose=n"
  Control the verbosity of the dump file for the integrated register allocator.
  The default value is 5.  If the value \fIn\fR is greater or equal to 10,
  the dump output is sent to stderr using the same format as \fIn\fR minus 10.
! .IP "\fB\-flto\-report\fR" 4
  .IX Item "-flto-report"
! Prints a report with internal details on the workings of the link-time
  optimizer.  The contents of this report vary from version to version.
! It is meant to be useful to \s-1GCC\s0 developers when processing object
! files in \s-1LTO\s0 mode (via \fB\-flto\fR).
  .Sp
  Disabled by default.
! .IP "\fB\-flto\-report\-wpa\fR" 4
  .IX Item "-flto-report-wpa"
! Like \fB\-flto\-report\fR, but only print for the \s-1WPA\s0 phase of link-time
  optimization.
! .IP "\fB\-fmem\-report\fR" 4
  .IX Item "-fmem-report"
  Makes the compiler print some statistics about permanent memory
  allocation when it finishes.
! .IP "\fB\-fmem\-report\-wpa\fR" 4
  .IX Item "-fmem-report-wpa"
  Makes the compiler print some statistics about permanent memory
! allocation for the \s-1WPA\s0 phase only.
! .IP "\fB\-fpre\-ipa\-mem\-report\fR" 4
  .IX Item "-fpre-ipa-mem-report"
  .PD 0
! .IP "\fB\-fpost\-ipa\-mem\-report\fR" 4
  .IX Item "-fpost-ipa-mem-report"
  .PD
  Makes the compiler print some statistics about permanent memory
  allocation before or after interprocedural optimization.
! .IP "\fB\-fmultiflags\fR" 4
  .IX Item "-fmultiflags"
! This option enables multilib-aware \f(CW\*(C`TFLAGS\*(C'\fR to be used to build
  target libraries with options different from those the compiler is
  configured to use by default, through the use of specs
  .Sp
  Like \f(CW\*(C`TFLAGS\*(C'\fR, this allows the target libraries to be built for
  portable baseline environments, while the compiler defaults to more
! demanding ones.  That's useful because users can easily override the
  defaults the compiler is configured to use to build their own programs,
  if the defaults are not ideal for their target environment, whereas
  rebuilding the runtime libraries is usually not as easy or desirable.
--- 19158,19220 ----
  other options are processed, and it does so only once, no matter how
  many times it is given.  This is mainly intended to be used with
  \&\fB\-fcompare\-debug\fR.
! .IP \fB\-fvar\-tracking\-assignments\-toggle\fR 4
  .IX Item "-fvar-tracking-assignments-toggle"
  Toggle \fB\-fvar\-tracking\-assignments\fR, in the same way that
  \&\fB\-gtoggle\fR toggles \fB\-g\fR.
! .IP \fB\-Q\fR 4
  .IX Item "-Q"
  Makes the compiler print out each function name as it is compiled, and
  print some statistics about each pass when it finishes.
! .IP \fB\-ftime\-report\fR 4
  .IX Item "-ftime-report"
  Makes the compiler print some statistics about the time consumed by each
  pass when it finishes.
! .IP \fB\-ftime\-report\-details\fR 4
  .IX Item "-ftime-report-details"
  Record the time consumed by infrastructure parts separately for each pass.
! .IP \fB\-fira\-verbose=\fR\fIn\fR 4
  .IX Item "-fira-verbose=n"
  Control the verbosity of the dump file for the integrated register allocator.
  The default value is 5.  If the value \fIn\fR is greater or equal to 10,
  the dump output is sent to stderr using the same format as \fIn\fR minus 10.
! .IP \fB\-flto\-report\fR 4
  .IX Item "-flto-report"
! Prints a report with internal details on the workings of the link\-time
  optimizer.  The contents of this report vary from version to version.
! It is meant to be useful to GCC developers when processing object
! files in LTO mode (via \fB\-flto\fR).
  .Sp
  Disabled by default.
! .IP \fB\-flto\-report\-wpa\fR 4
  .IX Item "-flto-report-wpa"
! Like \fB\-flto\-report\fR, but only print for the WPA phase of link\-time
  optimization.
! .IP \fB\-fmem\-report\fR 4
  .IX Item "-fmem-report"
  Makes the compiler print some statistics about permanent memory
  allocation when it finishes.
! .IP \fB\-fmem\-report\-wpa\fR 4
  .IX Item "-fmem-report-wpa"
  Makes the compiler print some statistics about permanent memory
! allocation for the WPA phase only.
! .IP \fB\-fpre\-ipa\-mem\-report\fR 4
  .IX Item "-fpre-ipa-mem-report"
  .PD 0
! .IP \fB\-fpost\-ipa\-mem\-report\fR 4
  .IX Item "-fpost-ipa-mem-report"
  .PD
  Makes the compiler print some statistics about permanent memory
  allocation before or after interprocedural optimization.
! .IP \fB\-fmultiflags\fR 4
  .IX Item "-fmultiflags"
! This option enables multilib\-aware \f(CW\*(C`TFLAGS\*(C'\fR to be used to build
  target libraries with options different from those the compiler is
  configured to use by default, through the use of specs
  .Sp
  Like \f(CW\*(C`TFLAGS\*(C'\fR, this allows the target libraries to be built for
  portable baseline environments, while the compiler defaults to more
! demanding ones.  That\*(Aqs useful because users can easily override the
  defaults the compiler is configured to use to build their own programs,
  if the defaults are not ideal for their target environment, whereas
  rebuilding the runtime libraries is usually not as easy or desirable.
*************** selected for different multilibs.  The w
*** 19293,19323 ****
  build with \fBmake TFLAGS=\-fmultiflags\fR, after configuring
  \&\fB\-\-with\-specs=%{fmultiflags:...}\fR.
  .Sp
! This option is discarded by the driver once it's done processing driver
  self spec.
  .Sp
  It is also useful to check that \f(CW\*(C`TFLAGS\*(C'\fR are being used to build
! all target libraries, by configuring a non-bootstrap compiler
! \&\fB\-\-with\-specs='%{!fmultiflags:%emissing \s-1TFLAGS\s0}'\fR and building
  the compiler and target libraries.
! .IP "\fB\-fprofile\-report\fR" 4
  .IX Item "-fprofile-report"
  Makes the compiler print some statistics about consistency of the
  (estimated) profile and effect of individual passes.
! .IP "\fB\-fstack\-usage\fR" 4
  .IX Item "-fstack-usage"
  Makes the compiler output stack usage information for the program, on a
! per-function basis.  The filename for the dump is made by appending
  \&\fI.su\fR to the \fIauxname\fR.  \fIauxname\fR is generated from the name of
  the output file, if explicitly specified and it is not an executable,
  otherwise it is the basename of the source file.  An entry is made up
  of three fields:
  .RS 4
! .IP "*" 4
  The name of the function.
! .IP "*" 4
  A number of bytes.
! .IP "*" 4
  One or more qualifiers: \f(CW\*(C`static\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR, \f(CW\*(C`bounded\*(C'\fR.
  .RE
  .RS 4
--- 19224,19254 ----
  build with \fBmake TFLAGS=\-fmultiflags\fR, after configuring
  \&\fB\-\-with\-specs=%{fmultiflags:...}\fR.
  .Sp
! This option is discarded by the driver once it\*(Aqs done processing driver
  self spec.
  .Sp
  It is also useful to check that \f(CW\*(C`TFLAGS\*(C'\fR are being used to build
! all target libraries, by configuring a non\-bootstrap compiler
! \&\fB\-\-with\-specs=\*(Aq%{!fmultiflags:%emissing TFLAGS}\*(Aq\fR and building
  the compiler and target libraries.
! .IP \fB\-fprofile\-report\fR 4
  .IX Item "-fprofile-report"
  Makes the compiler print some statistics about consistency of the
  (estimated) profile and effect of individual passes.
! .IP \fB\-fstack\-usage\fR 4
  .IX Item "-fstack-usage"
  Makes the compiler output stack usage information for the program, on a
! per\-function basis.  The filename for the dump is made by appending
  \&\fI.su\fR to the \fIauxname\fR.  \fIauxname\fR is generated from the name of
  the output file, if explicitly specified and it is not an executable,
  otherwise it is the basename of the source file.  An entry is made up
  of three fields:
  .RS 4
! .IP * 4
  The name of the function.
! .IP * 4
  A number of bytes.
! .IP * 4
  One or more qualifiers: \f(CW\*(C`static\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR, \f(CW\*(C`bounded\*(C'\fR.
  .RE
  .RS 4
*************** the function.  If it is not present, the
*** 19337,19397 ****
  not bounded at compile time and the second field only represents the
  bounded part.
  .RE
! .IP "\fB\-fstats\fR" 4
  .IX Item "-fstats"
! Emit statistics about front-end processing at the end of the compilation.
! This option is supported only by the \*(C+ front end, and
  the information is generally only useful to the G++ development team.
! .IP "\fB\-fdbg\-cnt\-list\fR" 4
  .IX Item "-fdbg-cnt-list"
  Print the name and the counter upper bound for all debug counters.
! .IP "\fB\-fdbg\-cnt=\fR\fIcounter-value-list\fR" 4
  .IX Item "-fdbg-cnt=counter-value-list"
! Set the internal debug counter lower and upper bound.  \fIcounter-value-list\fR
! is a comma-separated list of \fIname\fR:\fIlower_bound1\fR\-\fIupper_bound1\fR
  [:\fIlower_bound2\fR\-\fIupper_bound2\fR...] tuples which sets
  the name of the counter and list of closed intervals.
  The \fIlower_bound\fR is optional and is zero
  initialized if not set.
  For example, with \fB\-fdbg\-cnt=dce:2\-4:10\-11,tail_call:10\fR,
! \&\f(CW\*(C`dbg_cnt(dce)\*(C'\fR returns true only for second, third, fourth, tenth and
  eleventh invocation.
! For \f(CW\*(C`dbg_cnt(tail_call)\*(C'\fR true is returned for first 10 invocations.
! .IP "\fB\-print\-file\-name=\fR\fIlibrary\fR" 4
  .IX Item "-print-file-name=library"
  Print the full absolute name of the library file \fIlibrary\fR that
! would be used when linking\-\-\-and don't do anything else.  With this
! option, \s-1GCC\s0 does not compile or link anything; it just prints the
  file name.
! .IP "\fB\-print\-multi\-directory\fR" 4
  .IX Item "-print-multi-directory"
  Print the directory name corresponding to the multilib selected by any
  other switches present in the command line.  This directory is supposed
! to exist in \fB\s-1GCC_EXEC_PREFIX\s0\fR.
! .IP "\fB\-print\-multi\-lib\fR" 4
  .IX Item "-print-multi-lib"
  Print the mapping from multilib directory names to compiler switches
  that enable them.  The directory name is separated from the switches by
  \&\fB;\fR, and each switch starts with an \fB@\fR instead of the
  \&\fB\-\fR, without spaces between multiple switches.  This is supposed to
  ease shell processing.
! .IP "\fB\-print\-multi\-os\-directory\fR" 4
  .IX Item "-print-multi-os-directory"
! Print the path to \s-1OS\s0 libraries for the selected
! multilib, relative to some \fIlib\fR subdirectory.  If \s-1OS\s0 libraries are
  present in the \fIlib\fR subdirectory and no multilibs are used, this is
! usually just \fI.\fR, if \s-1OS\s0 libraries are present in \fIlib\fIsuffix\fI\fR
  sibling directories this prints e.g. \fI../lib64\fR, \fI../lib\fR or
! \&\fI../lib32\fR, or if \s-1OS\s0 libraries are present in \fIlib/\fIsubdir\fI\fR
  subdirectories it prints e.g. \fIamd64\fR, \fIsparcv9\fR or \fIev6\fR.
! .IP "\fB\-print\-multiarch\fR" 4
  .IX Item "-print-multiarch"
! Print the path to \s-1OS\s0 libraries for the selected multiarch,
  relative to some \fIlib\fR subdirectory.
! .IP "\fB\-print\-prog\-name=\fR\fIprogram\fR" 4
  .IX Item "-print-prog-name=program"
  Like \fB\-print\-file\-name\fR, but searches for a program such as \fBcpp\fR.
! .IP "\fB\-print\-libgcc\-file\-name\fR" 4
  .IX Item "-print-libgcc-file-name"
  Same as \fB\-print\-file\-name=libgcc.a\fR.
  .Sp
--- 19268,19328 ----
  not bounded at compile time and the second field only represents the
  bounded part.
  .RE
! .IP \fB\-fstats\fR 4
  .IX Item "-fstats"
! Emit statistics about front\-end processing at the end of the compilation.
! This option is supported only by the C++ front end, and
  the information is generally only useful to the G++ development team.
! .IP \fB\-fdbg\-cnt\-list\fR 4
  .IX Item "-fdbg-cnt-list"
  Print the name and the counter upper bound for all debug counters.
! .IP \fB\-fdbg\-cnt=\fR\fIcounter\-value\-list\fR 4
  .IX Item "-fdbg-cnt=counter-value-list"
! Set the internal debug counter lower and upper bound.  \fIcounter\-value\-list\fR
! is a comma\-separated list of \fIname\fR:\fIlower_bound1\fR\-\fIupper_bound1\fR
  [:\fIlower_bound2\fR\-\fIupper_bound2\fR...] tuples which sets
  the name of the counter and list of closed intervals.
  The \fIlower_bound\fR is optional and is zero
  initialized if not set.
  For example, with \fB\-fdbg\-cnt=dce:2\-4:10\-11,tail_call:10\fR,
! \&\f(CWdbg_cnt(dce)\fR returns true only for second, third, fourth, tenth and
  eleventh invocation.
! For \f(CWdbg_cnt(tail_call)\fR true is returned for first 10 invocations.
! .IP \fB\-print\-file\-name=\fR\fIlibrary\fR 4
  .IX Item "-print-file-name=library"
  Print the full absolute name of the library file \fIlibrary\fR that
! would be used when linking\-\-\-and don\*(Aqt do anything else.  With this
! option, GCC does not compile or link anything; it just prints the
  file name.
! .IP \fB\-print\-multi\-directory\fR 4
  .IX Item "-print-multi-directory"
  Print the directory name corresponding to the multilib selected by any
  other switches present in the command line.  This directory is supposed
! to exist in \fBGCC_EXEC_PREFIX\fR.
! .IP \fB\-print\-multi\-lib\fR 4
  .IX Item "-print-multi-lib"
  Print the mapping from multilib directory names to compiler switches
  that enable them.  The directory name is separated from the switches by
  \&\fB;\fR, and each switch starts with an \fB@\fR instead of the
  \&\fB\-\fR, without spaces between multiple switches.  This is supposed to
  ease shell processing.
! .IP \fB\-print\-multi\-os\-directory\fR 4
  .IX Item "-print-multi-os-directory"
! Print the path to OS libraries for the selected
! multilib, relative to some \fIlib\fR subdirectory.  If OS libraries are
  present in the \fIlib\fR subdirectory and no multilibs are used, this is
! usually just \fI.\fR, if OS libraries are present in \fIlibsuffix\fR
  sibling directories this prints e.g. \fI../lib64\fR, \fI../lib\fR or
! \&\fI../lib32\fR, or if OS libraries are present in \fIlib/subdir\fR
  subdirectories it prints e.g. \fIamd64\fR, \fIsparcv9\fR or \fIev6\fR.
! .IP \fB\-print\-multiarch\fR 4
  .IX Item "-print-multiarch"
! Print the path to OS libraries for the selected multiarch,
  relative to some \fIlib\fR subdirectory.
! .IP \fB\-print\-prog\-name=\fR\fIprogram\fR 4
  .IX Item "-print-prog-name=program"
  Like \fB\-print\-file\-name\fR, but searches for a program such as \fBcpp\fR.
! .IP \fB\-print\-libgcc\-file\-name\fR 4
  .IX Item "-print-libgcc-file-name"
  Same as \fB\-print\-file\-name=libgcc.a\fR.
  .Sp
*************** but you do want to link with \fIlibgcc.a
*** 19401,19458 ****
  .Vb 1
  \&        gcc \-nostdlib ... \`gcc \-print\-libgcc\-file\-name\`
  .Ve
! .IP "\fB\-print\-search\-dirs\fR" 4
  .IX Item "-print-search-dirs"
  Print the name of the configured installation directory and a list of
! program and library directories \fBgcc\fR searches\-\-\-and don't do anything else.
  .Sp
  This is useful when \fBgcc\fR prints the error message
  \&\fBinstallation problem, cannot exec cpp0: No such file or directory\fR.
  To resolve this you either need to put \fIcpp0\fR and the other compiler
  components where \fBgcc\fR expects to find them, or you can set the environment
! variable \fB\s-1GCC_EXEC_PREFIX\s0\fR to the directory where you installed them.
! Don't forget the trailing \fB/\fR.
! .IP "\fB\-print\-sysroot\fR" 4
  .IX Item "-print-sysroot"
  Print the target sysroot directory that is used during
  compilation.  This is the target sysroot specified either at configure
  time or using the \fB\-\-sysroot\fR option, possibly with an extra
  suffix that depends on compilation options.  If no target sysroot is
  specified, the option prints nothing.
! .IP "\fB\-print\-sysroot\-headers\-suffix\fR" 4
  .IX Item "-print-sysroot-headers-suffix"
  Print the suffix added to the target sysroot when searching for
  headers, or give an error if the compiler is not configured with such
! a suffix\-\-\-and don't do anything else.
! .IP "\fB\-dumpmachine\fR" 4
  .IX Item "-dumpmachine"
! Print the compiler's target machine (for example,
! \&\fBi686\-pc\-linux\-gnu\fR)\-\-\-and don't do anything else.
! .IP "\fB\-dumpversion\fR" 4
  .IX Item "-dumpversion"
! Print the compiler version (for example, \f(CW3.0\fR, \f(CW6.3.0\fR or \f(CW7\fR)\-\-\-and don't do
  anything else.  This is the compiler version used in filesystem paths and
  specs. Depending on how the compiler has been configured it can be just
  a single number (major version), two numbers separated by a dot (major and
  minor version) or three numbers separated by dots (major, minor and patchlevel
  version).
! .IP "\fB\-dumpfullversion\fR" 4
  .IX Item "-dumpfullversion"
! Print the full compiler version\-\-\-and don't do anything else. The output is
  always three numbers separated by dots, major, minor and patchlevel version.
! .IP "\fB\-dumpspecs\fR" 4
  .IX Item "-dumpspecs"
! Print the compiler's built-in specs\-\-\-and don't do anything else.  (This
! is used when \s-1GCC\s0 itself is being built.)
! .SS "Machine-Dependent Options"
  .IX Subsection "Machine-Dependent Options"
! Each target machine supported by \s-1GCC\s0 can have its own options\-\-\-for
  example, to allow you to compile for a particular processor variant or
! \&\s-1ABI,\s0 or to control optimizations specific to that machine.  By
! convention, the names of machine-specific options start with
  \&\fB\-m\fR.
  .PP
! Some configurations of the compiler also support additional target-specific
  options, usually for compatibility with other compilers on the same
  platform.
  .PP
--- 19332,19389 ----
  .Vb 1
  \&        gcc \-nostdlib ... \`gcc \-print\-libgcc\-file\-name\`
  .Ve
! .IP \fB\-print\-search\-dirs\fR 4
  .IX Item "-print-search-dirs"
  Print the name of the configured installation directory and a list of
! program and library directories \fBgcc\fR searches\-\-\-and don\*(Aqt do anything else.
  .Sp
  This is useful when \fBgcc\fR prints the error message
  \&\fBinstallation problem, cannot exec cpp0: No such file or directory\fR.
  To resolve this you either need to put \fIcpp0\fR and the other compiler
  components where \fBgcc\fR expects to find them, or you can set the environment
! variable \fBGCC_EXEC_PREFIX\fR to the directory where you installed them.
! Don\*(Aqt forget the trailing \fB/\fR.
! .IP \fB\-print\-sysroot\fR 4
  .IX Item "-print-sysroot"
  Print the target sysroot directory that is used during
  compilation.  This is the target sysroot specified either at configure
  time or using the \fB\-\-sysroot\fR option, possibly with an extra
  suffix that depends on compilation options.  If no target sysroot is
  specified, the option prints nothing.
! .IP \fB\-print\-sysroot\-headers\-suffix\fR 4
  .IX Item "-print-sysroot-headers-suffix"
  Print the suffix added to the target sysroot when searching for
  headers, or give an error if the compiler is not configured with such
! a suffix\-\-\-and don\*(Aqt do anything else.
! .IP \fB\-dumpmachine\fR 4
  .IX Item "-dumpmachine"
! Print the compiler\*(Aqs target machine (for example,
! \&\fBi686\-pc\-linux\-gnu\fR)\-\-\-and don\*(Aqt do anything else.
! .IP \fB\-dumpversion\fR 4
  .IX Item "-dumpversion"
! Print the compiler version (for example, \f(CW3.0\fR, \f(CW6.3.0\fR or \f(CW7\fR)\-\-\-and don\*(Aqt do
  anything else.  This is the compiler version used in filesystem paths and
  specs. Depending on how the compiler has been configured it can be just
  a single number (major version), two numbers separated by a dot (major and
  minor version) or three numbers separated by dots (major, minor and patchlevel
  version).
! .IP \fB\-dumpfullversion\fR 4
  .IX Item "-dumpfullversion"
! Print the full compiler version\-\-\-and don\*(Aqt do anything else. The output is
  always three numbers separated by dots, major, minor and patchlevel version.
! .IP \fB\-dumpspecs\fR 4
  .IX Item "-dumpspecs"
! Print the compiler\*(Aqs built\-in specs\-\-\-and don\*(Aqt do anything else.  (This
! is used when GCC itself is being built.)
! .SS "Machine\-Dependent Options"
  .IX Subsection "Machine-Dependent Options"
! Each target machine supported by GCC can have its own options\-\-\-for
  example, to allow you to compile for a particular processor variant or
! ABI, or to control optimizations specific to that machine.  By
! convention, the names of machine\-specific options start with
  \&\fB\-m\fR.
  .PP
! Some configurations of the compiler also support additional target\-specific
  options, usually for compatibility with other compilers on the same
  platform.
  .PP
*************** platform.
*** 19460,19526 ****
  .IX Subsection "AArch64 Options"
  .PP
  These options are defined for AArch64 implementations:
! .IP "\fB\-mabi=\fR\fIname\fR" 4
  .IX Item "-mabi=name"
  Generate code for the specified data model.  Permissible values
! are \fBilp32\fR for SysV-like data model where int, long int and pointers
! are 32 bits, and \fBlp64\fR for SysV-like data model where int is 32 bits,
  but long int and pointers are 64 bits.
  .Sp
  The default depends on the specific target configuration.  Note that
! the \s-1LP64\s0 and \s-1ILP32\s0 ABIs are not link-compatible; you must compile your
! entire program with the same \s-1ABI,\s0 and link with a compatible set of libraries.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate big-endian code.  This is the default when \s-1GCC\s0 is configured for an
  \&\fBaarch64_be\-*\-*\fR target.
! .IP "\fB\-mgeneral\-regs\-only\fR" 4
  .IX Item "-mgeneral-regs-only"
! Generate code which uses only the general-purpose registers.  This will prevent
! the compiler from using floating-point and Advanced \s-1SIMD\s0 registers but will not
  impose any restrictions on the assembler.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate little-endian code.  This is the default when \s-1GCC\s0 is configured for an
  \&\fBaarch64\-*\-*\fR but not an \fBaarch64_be\-*\-*\fR target.
! .IP "\fB\-mcmodel=tiny\fR" 4
  .IX Item "-mcmodel=tiny"
  Generate code for the tiny code model.  The program and its statically defined
  symbols must be within 1MB of each other.  Programs can be statically or
  dynamically linked.
! .IP "\fB\-mcmodel=small\fR" 4
  .IX Item "-mcmodel=small"
  Generate code for the small code model.  The program and its statically defined
  symbols must be within 4GB of each other.  Programs can be statically or
  dynamically linked.  This is the default code model.
! .IP "\fB\-mcmodel=large\fR" 4
  .IX Item "-mcmodel=large"
  Generate code for the large code model.  This makes no assumptions about
  addresses and sizes of sections.  Programs can be statically linked only.  The
  \&\fB\-mcmodel=large\fR option is incompatible with \fB\-mabi=ilp32\fR,
  \&\fB\-fpic\fR and \fB\-fPIC\fR.
! .IP "\fB\-mstrict\-align\fR" 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP "\fB\-mno\-strict\-align\fR" 4
  .IX Item "-mno-strict-align"
  .PD
  Avoid or allow generating memory accesses that may not be aligned on a natural
  object boundary as described in the architecture specification.
! .IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
  .IX Item "-momit-leaf-frame-pointer"
  .PD 0
! .IP "\fB\-mno\-omit\-leaf\-frame\-pointer\fR" 4
  .IX Item "-mno-omit-leaf-frame-pointer"
  .PD
  Omit or keep the frame pointer in leaf functions.  The former behavior is the
  default.
! .IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP "\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR" 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP "\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR" 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
--- 19391,19457 ----
  .IX Subsection "AArch64 Options"
  .PP
  These options are defined for AArch64 implementations:
! .IP \fB\-mabi=\fR\fIname\fR 4
  .IX Item "-mabi=name"
  Generate code for the specified data model.  Permissible values
! are \fBilp32\fR for SysV\-like data model where int, long int and pointers
! are 32 bits, and \fBlp64\fR for SysV\-like data model where int is 32 bits,
  but long int and pointers are 64 bits.
  .Sp
  The default depends on the specific target configuration.  Note that
! the LP64 and ILP32 ABIs are not link\-compatible; you must compile your
! entire program with the same ABI, and link with a compatible set of libraries.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate big\-endian code.  This is the default when GCC is configured for an
  \&\fBaarch64_be\-*\-*\fR target.
! .IP \fB\-mgeneral\-regs\-only\fR 4
  .IX Item "-mgeneral-regs-only"
! Generate code which uses only the general\-purpose registers.  This will prevent
! the compiler from using floating\-point and Advanced SIMD registers but will not
  impose any restrictions on the assembler.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate little\-endian code.  This is the default when GCC is configured for an
  \&\fBaarch64\-*\-*\fR but not an \fBaarch64_be\-*\-*\fR target.
! .IP \fB\-mcmodel=tiny\fR 4
  .IX Item "-mcmodel=tiny"
  Generate code for the tiny code model.  The program and its statically defined
  symbols must be within 1MB of each other.  Programs can be statically or
  dynamically linked.
! .IP \fB\-mcmodel=small\fR 4
  .IX Item "-mcmodel=small"
  Generate code for the small code model.  The program and its statically defined
  symbols must be within 4GB of each other.  Programs can be statically or
  dynamically linked.  This is the default code model.
! .IP \fB\-mcmodel=large\fR 4
  .IX Item "-mcmodel=large"
  Generate code for the large code model.  This makes no assumptions about
  addresses and sizes of sections.  Programs can be statically linked only.  The
  \&\fB\-mcmodel=large\fR option is incompatible with \fB\-mabi=ilp32\fR,
  \&\fB\-fpic\fR and \fB\-fPIC\fR.
! .IP \fB\-mstrict\-align\fR 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP \fB\-mno\-strict\-align\fR 4
  .IX Item "-mno-strict-align"
  .PD
  Avoid or allow generating memory accesses that may not be aligned on a natural
  object boundary as described in the architecture specification.
! .IP \fB\-momit\-leaf\-frame\-pointer\fR 4
  .IX Item "-momit-leaf-frame-pointer"
  .PD 0
! .IP \fB\-mno\-omit\-leaf\-frame\-pointer\fR 4
  .IX Item "-mno-omit-leaf-frame-pointer"
  .PD
  Omit or keep the frame pointer in leaf functions.  The former behavior is the
  default.
! .IP \fB\-mstack\-protector\-guard=\fR\fIguard\fR 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP \fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
*************** which system register to use as base reg
*** 19534,19573 ****
  and from what offset from that base register. There is no default
  register or offset as this is entirely for use within the Linux
  kernel.
! .IP "\fB\-mtls\-dialect=desc\fR" 4
  .IX Item "-mtls-dialect=desc"
! Use \s-1TLS\s0 descriptors as the thread-local storage mechanism for dynamic accesses
! of \s-1TLS\s0 variables.  This is the default.
! .IP "\fB\-mtls\-dialect=traditional\fR" 4
  .IX Item "-mtls-dialect=traditional"
! Use traditional \s-1TLS\s0 as the thread-local storage mechanism for dynamic accesses
! of \s-1TLS\s0 variables.
! .IP "\fB\-mtls\-size=\fR\fIsize\fR" 4
  .IX Item "-mtls-size=size"
! Specify bit size of immediate \s-1TLS\s0 offsets.  Valid values are 12, 24, 32, 48.
  This option requires binutils 2.26 or newer.
! .IP "\fB\-mfix\-cortex\-a53\-835769\fR" 4
  .IX Item "-mfix-cortex-a53-835769"
  .PD 0
! .IP "\fB\-mno\-fix\-cortex\-a53\-835769\fR" 4
  .IX Item "-mno-fix-cortex-a53-835769"
  .PD
! Enable or disable the workaround for the \s-1ARM\s0 Cortex\-A53 erratum number 835769.
! This involves inserting a \s-1NOP\s0 instruction between memory instructions and
! 64\-bit integer multiply-accumulate instructions.
! .IP "\fB\-mfix\-cortex\-a53\-843419\fR" 4
  .IX Item "-mfix-cortex-a53-843419"
  .PD 0
! .IP "\fB\-mno\-fix\-cortex\-a53\-843419\fR" 4
  .IX Item "-mno-fix-cortex-a53-843419"
  .PD
! Enable or disable the workaround for the \s-1ARM\s0 Cortex\-A53 erratum number 843419.
  This erratum workaround is made at link time and this will only pass the
  corresponding flag to the linker.
! .IP "\fB\-mlow\-precision\-recip\-sqrt\fR" 4
  .IX Item "-mlow-precision-recip-sqrt"
  .PD 0
! .IP "\fB\-mno\-low\-precision\-recip\-sqrt\fR" 4
  .IX Item "-mno-low-precision-recip-sqrt"
  .PD
  Enable or disable the reciprocal square root approximation.
--- 19465,19504 ----
  and from what offset from that base register. There is no default
  register or offset as this is entirely for use within the Linux
  kernel.
! .IP \fB\-mtls\-dialect=desc\fR 4
  .IX Item "-mtls-dialect=desc"
! Use TLS descriptors as the thread\-local storage mechanism for dynamic accesses
! of TLS variables.  This is the default.
! .IP \fB\-mtls\-dialect=traditional\fR 4
  .IX Item "-mtls-dialect=traditional"
! Use traditional TLS as the thread\-local storage mechanism for dynamic accesses
! of TLS variables.
! .IP \fB\-mtls\-size=\fR\fIsize\fR 4
  .IX Item "-mtls-size=size"
! Specify bit size of immediate TLS offsets.  Valid values are 12, 24, 32, 48.
  This option requires binutils 2.26 or newer.
! .IP \fB\-mfix\-cortex\-a53\-835769\fR 4
  .IX Item "-mfix-cortex-a53-835769"
  .PD 0
! .IP \fB\-mno\-fix\-cortex\-a53\-835769\fR 4
  .IX Item "-mno-fix-cortex-a53-835769"
  .PD
! Enable or disable the workaround for the ARM Cortex\-A53 erratum number 835769.
! This involves inserting a NOP instruction between memory instructions and
! 64\-bit integer multiply\-accumulate instructions.
! .IP \fB\-mfix\-cortex\-a53\-843419\fR 4
  .IX Item "-mfix-cortex-a53-843419"
  .PD 0
! .IP \fB\-mno\-fix\-cortex\-a53\-843419\fR 4
  .IX Item "-mno-fix-cortex-a53-843419"
  .PD
! Enable or disable the workaround for the ARM Cortex\-A53 erratum number 843419.
  This erratum workaround is made at link time and this will only pass the
  corresponding flag to the linker.
! .IP \fB\-mlow\-precision\-recip\-sqrt\fR 4
  .IX Item "-mlow-precision-recip-sqrt"
  .PD 0
! .IP \fB\-mno\-low\-precision\-recip\-sqrt\fR 4
  .IX Item "-mno-low-precision-recip-sqrt"
  .PD
  Enable or disable the reciprocal square root approximation.
*************** This option only has an effect if \fB\-f
*** 19575,19584 ****
  \&\fB\-funsafe\-math\-optimizations\fR is used as well.  Enabling this reduces
  precision of reciprocal square root results to about 16 bits for
  single precision and to 32 bits for double precision.
! .IP "\fB\-mlow\-precision\-sqrt\fR" 4
  .IX Item "-mlow-precision-sqrt"
  .PD 0
! .IP "\fB\-mno\-low\-precision\-sqrt\fR" 4
  .IX Item "-mno-low-precision-sqrt"
  .PD
  Enable or disable the square root approximation.
--- 19506,19515 ----
  \&\fB\-funsafe\-math\-optimizations\fR is used as well.  Enabling this reduces
  precision of reciprocal square root results to about 16 bits for
  single precision and to 32 bits for double precision.
! .IP \fB\-mlow\-precision\-sqrt\fR 4
  .IX Item "-mlow-precision-sqrt"
  .PD 0
! .IP \fB\-mno\-low\-precision\-sqrt\fR 4
  .IX Item "-mno-low-precision-sqrt"
  .PD
  Enable or disable the square root approximation.
*************** This option only has an effect if \fB\-f
*** 19587,19596 ****
  precision of square root results to about 16 bits for
  single precision and to 32 bits for double precision.
  If enabled, it implies \fB\-mlow\-precision\-recip\-sqrt\fR.
! .IP "\fB\-mlow\-precision\-div\fR" 4
  .IX Item "-mlow-precision-div"
  .PD 0
! .IP "\fB\-mno\-low\-precision\-div\fR" 4
  .IX Item "-mno-low-precision-div"
  .PD
  Enable or disable the division approximation.
--- 19518,19527 ----
  precision of square root results to about 16 bits for
  single precision and to 32 bits for double precision.
  If enabled, it implies \fB\-mlow\-precision\-recip\-sqrt\fR.
! .IP \fB\-mlow\-precision\-div\fR 4
  .IX Item "-mlow-precision-div"
  .PD 0
! .IP \fB\-mno\-low\-precision\-div\fR 4
  .IX Item "-mno-low-precision-div"
  .PD
  Enable or disable the division approximation.
*************** This option only has an effect if \fB\-f
*** 19598,19607 ****
  \&\fB\-funsafe\-math\-optimizations\fR is used as well.  Enabling this reduces
  precision of division results to about 16 bits for
  single precision and to 32 bits for double precision.
! .IP "\fB\-mtrack\-speculation\fR" 4
  .IX Item "-mtrack-speculation"
  .PD 0
! .IP "\fB\-mno\-track\-speculation\fR" 4
  .IX Item "-mno-track-speculation"
  .PD
  Enable or disable generation of additional code to track speculative
--- 19529,19538 ----
  \&\fB\-funsafe\-math\-optimizations\fR is used as well.  Enabling this reduces
  precision of division results to about 16 bits for
  single precision and to 32 bits for double precision.
! .IP \fB\-mtrack\-speculation\fR 4
  .IX Item "-mtrack-speculation"
  .PD 0
! .IP \fB\-mno\-track\-speculation\fR 4
  .IX Item "-mno-track-speculation"
  .PD
  Enable or disable generation of additional code to track speculative
*************** execution through conditional branches.
*** 19609,19624 ****
  be used by the compiler when expanding calls to
  \&\f(CW\*(C`_\|_builtin_speculation_safe_copy\*(C'\fR to permit a more efficient code
  sequence to be generated.
! .IP "\fB\-moutline\-atomics\fR" 4
  .IX Item "-moutline-atomics"
  .PD 0
! .IP "\fB\-mno\-outline\-atomics\fR" 4
  .IX Item "-mno-outline-atomics"
  .PD
! Enable or disable calls to out-of-line helpers to implement atomic operations.
! These helpers will, at runtime, determine if the \s-1LSE\s0 instructions from
  ARMv8.1\-A can be used; if not, they will use the load/store\-exclusive
! instructions that are present in the base ARMv8.0 \s-1ISA.\s0
  .Sp
  This option is only applicable when compiling for the base ARMv8.0
  instruction set.  If using a later revision, e.g. \fB\-march=armv8.1\-a\fR
--- 19540,19555 ----
  be used by the compiler when expanding calls to
  \&\f(CW\*(C`_\|_builtin_speculation_safe_copy\*(C'\fR to permit a more efficient code
  sequence to be generated.
! .IP \fB\-moutline\-atomics\fR 4
  .IX Item "-moutline-atomics"
  .PD 0
! .IP \fB\-mno\-outline\-atomics\fR 4
  .IX Item "-mno-outline-atomics"
  .PD
! Enable or disable calls to out\-of\-line helpers to implement atomic operations.
! These helpers will, at runtime, determine if the LSE instructions from
  ARMv8.1\-A can be used; if not, they will use the load/store\-exclusive
! instructions that are present in the base ARMv8.0 ISA.
  .Sp
  This option is only applicable when compiling for the base ARMv8.0
  instruction set.  If using a later revision, e.g. \fB\-march=armv8.1\-a\fR
*************** or \fB\-march=armv8\-a+lse\fR, the ARMv8
*** 19626,19632 ****
  used directly.  The same applies when using \fB\-mcpu=\fR when the
  selected cpu supports the \fBlse\fR feature.
  This option is on by default.
! .IP "\fB\-march=\fR\fIname\fR" 4
  .IX Item "-march=name"
  Specify the name of the target architecture and, optionally, one or
  more feature modifiers.  This option has the form
--- 19557,19563 ----
  used directly.  The same applies when using \fB\-mcpu=\fR when the
  selected cpu supports the \fBlse\fR feature.
  This option is on by default.
! .IP \fB\-march=\fR\fIname\fR 4
  .IX Item "-march=name"
  Specify the name of the target architecture and, optionally, one or
  more feature modifiers.  This option has the form
*************** and the features that they enable by def
*** 19666,19694 ****
  .IX Item "armv9.3-a : Armv9.3-A : armv9.2-a, +mops"
  .IP "\fBarmv8\-r\fR : Armv8\-R : \fBarmv8\-r\fR" 4
  .IX Item "armv8-r : Armv8-R : armv8-r"
  .RE
  .RS 4
- .PD
  .Sp
  The value \fBnative\fR is available on native AArch64 GNU/Linux and
  causes the compiler to pick the architecture of the host system.  This
  option has no effect if the compiler is unable to recognize the
  architecture of the host system,
  .Sp
! The permissible values for \fIfeature\fR are listed in the sub-section
  on \fBaarch64\-feature\-modifiers,,\fR\fB\-march\fR \fBand\fR \fB\-mcpu\fR
  \&\fBFeature Modifiers\fR.  Where conflicting feature modifiers are
! specified, the right-most feature is used.
  .Sp
! \&\s-1GCC\s0 uses \fIname\fR to determine what kind of instructions it can emit
  when generating assembly code.  If \fB\-march\fR is specified
  without either of \fB\-mtune\fR or \fB\-mcpu\fR also being
  specified, the code is tuned to perform well across a range of target
  processors implementing the target architecture.
  .RE
! .IP "\fB\-mtune=\fR\fIname\fR" 4
  .IX Item "-mtune=name"
! Specify the name of the target processor for which \s-1GCC\s0 should tune the
  performance of the code.  Permissible values for this option are:
  \&\fBgeneric\fR, \fBcortex\-a35\fR, \fBcortex\-a53\fR, \fBcortex\-a55\fR,
  \&\fBcortex\-a57\fR, \fBcortex\-a72\fR, \fBcortex\-a73\fR, \fBcortex\-a75\fR,
--- 19597,19625 ----
  .IX Item "armv9.3-a : Armv9.3-A : armv9.2-a, +mops"
  .IP "\fBarmv8\-r\fR : Armv8\-R : \fBarmv8\-r\fR" 4
  .IX Item "armv8-r : Armv8-R : armv8-r"
+ .PD
  .RE
  .RS 4
  .Sp
  The value \fBnative\fR is available on native AArch64 GNU/Linux and
  causes the compiler to pick the architecture of the host system.  This
  option has no effect if the compiler is unable to recognize the
  architecture of the host system,
  .Sp
! The permissible values for \fIfeature\fR are listed in the sub\-section
  on \fBaarch64\-feature\-modifiers,,\fR\fB\-march\fR \fBand\fR \fB\-mcpu\fR
  \&\fBFeature Modifiers\fR.  Where conflicting feature modifiers are
! specified, the right\-most feature is used.
  .Sp
! GCC uses \fIname\fR to determine what kind of instructions it can emit
  when generating assembly code.  If \fB\-march\fR is specified
  without either of \fB\-mtune\fR or \fB\-mcpu\fR also being
  specified, the code is tuned to perform well across a range of target
  processors implementing the target architecture.
  .RE
! .IP \fB\-mtune=\fR\fIname\fR 4
  .IX Item "-mtune=name"
! Specify the name of the target processor for which GCC should tune the
  performance of the code.  Permissible values for this option are:
  \&\fBgeneric\fR, \fBcortex\-a35\fR, \fBcortex\-a53\fR, \fBcortex\-a55\fR,
  \&\fBcortex\-a57\fR, \fBcortex\-a72\fR, \fBcortex\-a73\fR, \fBcortex\-a75\fR,
*************** performance of the code.  Permissible va
*** 19716,19730 ****
  .Sp
  The values \fBcortex\-a57.cortex\-a53\fR, \fBcortex\-a72.cortex\-a53\fR,
  \&\fBcortex\-a73.cortex\-a35\fR, \fBcortex\-a73.cortex\-a53\fR,
! \&\fBcortex\-a75.cortex\-a55\fR, \fBcortex\-a76.cortex\-a55\fR specify that \s-1GCC\s0
  should tune for a big.LITTLE system.
  .Sp
! The value \fBneoverse\-512tvb\fR specifies that \s-1GCC\s0 should tune
! for Neoverse cores that (a) implement \s-1SVE\s0 and (b) have a total vector
! bandwidth of 512 bits per cycle.  In other words, the option tells \s-1GCC\s0 to
! tune for Neoverse cores that can execute 4 128\-bit Advanced \s-1SIMD\s0 arithmetic
! instructions a cycle and that can execute an equivalent number of \s-1SVE\s0
! arithmetic instructions per cycle (2 for 256\-bit \s-1SVE, 4\s0 for 128\-bit \s-1SVE\s0).
  This is more general than tuning for a specific core like Neoverse V1
  but is more specific than the default tuning described below.
  .Sp
--- 19647,19661 ----
  .Sp
  The values \fBcortex\-a57.cortex\-a53\fR, \fBcortex\-a72.cortex\-a53\fR,
  \&\fBcortex\-a73.cortex\-a35\fR, \fBcortex\-a73.cortex\-a53\fR,
! \&\fBcortex\-a75.cortex\-a55\fR, \fBcortex\-a76.cortex\-a55\fR specify that GCC
  should tune for a big.LITTLE system.
  .Sp
! The value \fBneoverse\-512tvb\fR specifies that GCC should tune
! for Neoverse cores that (a) implement SVE and (b) have a total vector
! bandwidth of 512 bits per cycle.  In other words, the option tells GCC to
! tune for Neoverse cores that can execute 4 128\-bit Advanced SIMD arithmetic
! instructions a cycle and that can execute an equivalent number of SVE
! arithmetic instructions per cycle (2 for 256\-bit SVE, 4 for 128\-bit SVE).
  This is more general than tuning for a specific core like Neoverse V1
  but is more specific than the default tuning described below.
  .Sp
*************** are specified, the code is tuned to perf
*** 19737,19755 ****
  of target processors.
  .Sp
  This option cannot be suffixed by feature modifiers.
! .IP "\fB\-mcpu=\fR\fIname\fR" 4
  .IX Item "-mcpu=name"
  Specify the name of the target processor, optionally suffixed by one
  or more feature modifiers.  This option has the form
  \&\fB\-mcpu=\fR\fIcpu\fR{\fB+\fR[\fBno\fR]\fIfeature\fR}*, where
  the permissible values for \fIcpu\fR are the same as those available
  for \fB\-mtune\fR.  The permissible values for \fIfeature\fR are
! documented in the sub-section on
  \&\fBaarch64\-feature\-modifiers,,\fR\fB\-march\fR \fBand\fR \fB\-mcpu\fR
  \&\fBFeature Modifiers\fR.  Where conflicting feature modifiers are
! specified, the right-most feature is used.
  .Sp
! \&\s-1GCC\s0 uses \fIname\fR to determine what kind of instructions it can emit when
  generating assembly code (as if by \fB\-march\fR) and to determine
  the target processor for which to tune for performance (as if
  by \fB\-mtune\fR).  Where this option is used in conjunction
--- 19668,19686 ----
  of target processors.
  .Sp
  This option cannot be suffixed by feature modifiers.
! .IP \fB\-mcpu=\fR\fIname\fR 4
  .IX Item "-mcpu=name"
  Specify the name of the target processor, optionally suffixed by one
  or more feature modifiers.  This option has the form
  \&\fB\-mcpu=\fR\fIcpu\fR{\fB+\fR[\fBno\fR]\fIfeature\fR}*, where
  the permissible values for \fIcpu\fR are the same as those available
  for \fB\-mtune\fR.  The permissible values for \fIfeature\fR are
! documented in the sub\-section on
  \&\fBaarch64\-feature\-modifiers,,\fR\fB\-march\fR \fBand\fR \fB\-mcpu\fR
  \&\fBFeature Modifiers\fR.  Where conflicting feature modifiers are
! specified, the right\-most feature is used.
  .Sp
! GCC uses \fIname\fR to determine what kind of instructions it can emit when
  generating assembly code (as if by \fB\-march\fR) and to determine
  the target processor for which to tune for performance (as if
  by \fB\-mtune\fR).  Where this option is used in conjunction
*************** over the appropriate part of this option
*** 19758,19801 ****
  .Sp
  \&\fB\-mcpu=neoverse\-512tvb\fR is special in that it does not refer
  to a specific core, but instead refers to all Neoverse cores that
! (a) implement \s-1SVE\s0 and (b) have a total vector bandwidth of 512 bits
  a cycle.  Unless overridden by \fB\-march\fR,
  \&\fB\-mcpu=neoverse\-512tvb\fR generates code that can run on a
  Neoverse V1 core, since Neoverse V1 is the first Neoverse core with
  these properties.  Unless overridden by \fB\-mtune\fR,
  \&\fB\-mcpu=neoverse\-512tvb\fR tunes code in the same way as for
  \&\fB\-mtune=neoverse\-512tvb\fR.
! .IP "\fB\-moverride=\fR\fIstring\fR" 4
  .IX Item "-moverride=string"
! Override tuning decisions made by the back-end in response to a
  \&\fB\-mtune=\fR switch.  The syntax, semantics, and accepted values
  for \fIstring\fR in this option are not guaranteed to be consistent
  across releases.
  .Sp
! This option is only intended to be useful when developing \s-1GCC.\s0
! .IP "\fB\-mverbose\-cost\-dump\fR" 4
  .IX Item "-mverbose-cost-dump"
  Enable verbose cost model dumping in the debug dump files.  This option is
  provided for use in debugging the compiler.
! .IP "\fB\-mpc\-relative\-literal\-loads\fR" 4
  .IX Item "-mpc-relative-literal-loads"
  .PD 0
! .IP "\fB\-mno\-pc\-relative\-literal\-loads\fR" 4
  .IX Item "-mno-pc-relative-literal-loads"
  .PD
! Enable or disable PC-relative literal loads.  With this option literal pools are
  accessed using a single instruction and emitted after each function.  This
  limits the maximum size of functions to 1MB.  This is enabled by default for
  \&\fB\-mcmodel=tiny\fR.
! .IP "\fB\-msign\-return\-address=\fR\fIscope\fR" 4
  .IX Item "-msign-return-address=scope"
  Select the function scope on which return address signing will be applied.
  Permissible values are \fBnone\fR, which disables return address signing,
! \&\fBnon-leaf\fR, which enables pointer signing for functions which are not leaf
  functions, and \fBall\fR, which enables pointer signing for all functions.  The
  default value is \fBnone\fR. This option has been deprecated by
  \&\-mbranch\-protection.
! .IP "\fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR\fB+\fR\fIb\-key\fR\fB]|\fR\fIbti\fR" 4
  .IX Item "-mbranch-protection=none|standard|pac-ret[+leaf+b-key]|bti"
  Select the branch protection features to use.
  \&\fBnone\fR is the default and turns off all types of branch protection.
--- 19689,19732 ----
  .Sp
  \&\fB\-mcpu=neoverse\-512tvb\fR is special in that it does not refer
  to a specific core, but instead refers to all Neoverse cores that
! (a) implement SVE and (b) have a total vector bandwidth of 512 bits
  a cycle.  Unless overridden by \fB\-march\fR,
  \&\fB\-mcpu=neoverse\-512tvb\fR generates code that can run on a
  Neoverse V1 core, since Neoverse V1 is the first Neoverse core with
  these properties.  Unless overridden by \fB\-mtune\fR,
  \&\fB\-mcpu=neoverse\-512tvb\fR tunes code in the same way as for
  \&\fB\-mtune=neoverse\-512tvb\fR.
! .IP \fB\-moverride=\fR\fIstring\fR 4
  .IX Item "-moverride=string"
! Override tuning decisions made by the back\-end in response to a
  \&\fB\-mtune=\fR switch.  The syntax, semantics, and accepted values
  for \fIstring\fR in this option are not guaranteed to be consistent
  across releases.
  .Sp
! This option is only intended to be useful when developing GCC.
! .IP \fB\-mverbose\-cost\-dump\fR 4
  .IX Item "-mverbose-cost-dump"
  Enable verbose cost model dumping in the debug dump files.  This option is
  provided for use in debugging the compiler.
! .IP \fB\-mpc\-relative\-literal\-loads\fR 4
  .IX Item "-mpc-relative-literal-loads"
  .PD 0
! .IP \fB\-mno\-pc\-relative\-literal\-loads\fR 4
  .IX Item "-mno-pc-relative-literal-loads"
  .PD
! Enable or disable PC\-relative literal loads.  With this option literal pools are
  accessed using a single instruction and emitted after each function.  This
  limits the maximum size of functions to 1MB.  This is enabled by default for
  \&\fB\-mcmodel=tiny\fR.
! .IP \fB\-msign\-return\-address=\fR\fIscope\fR 4
  .IX Item "-msign-return-address=scope"
  Select the function scope on which return address signing will be applied.
  Permissible values are \fBnone\fR, which disables return address signing,
! \&\fBnon\-leaf\fR, which enables pointer signing for functions which are not leaf
  functions, and \fBall\fR, which enables pointer signing for all functions.  The
  default value is \fBnone\fR. This option has been deprecated by
  \&\-mbranch\-protection.
! .IP \fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR\fB+\fR\fIb\-key\fR\fB]|\fR\fIbti\fR 4
  .IX Item "-mbranch-protection=none|standard|pac-ret[+leaf+b-key]|bti"
  Select the branch protection features to use.
  \&\fBnone\fR is the default and turns off all types of branch protection.
*************** Select the branch protection features to
*** 19803,20003 ****
  has additional tuning options, then \fBstandard\fR sets it to its standard
  level.
  \&\fBpac\-ret[+\fR\fIleaf\fR\fB]\fR turns on return address signing to its standard
! level: signing functions that save the return address to memory (non-leaf
  functions will practically always do this) using the a\-key.  The optional
  argument \fBleaf\fR can be used to extend the signing to include leaf
  functions.  The optional argument \fBb\-key\fR can be used to sign the functions
  with the B\-key instead of the A\-key.
  \&\fBbti\fR turns on branch target identification mechanism.
! .IP "\fB\-mharden\-sls=\fR\fIopts\fR" 4
  .IX Item "-mharden-sls=opts"
! Enable compiler hardening against straight line speculation (\s-1SLS\s0).
! \&\fIopts\fR is a comma-separated list of the following options:
  .RS 4
! .IP "\fBretbr\fR" 4
  .IX Item "retbr"
  .PD 0
! .IP "\fBblr\fR" 4
  .IX Item "blr"
  .RE
  .RS 4
- .PD
  .Sp
! In addition, \fB\-mharden\-sls=all\fR enables all \s-1SLS\s0 hardening while
! \&\fB\-mharden\-sls=none\fR disables all \s-1SLS\s0 hardening.
  .RE
! .IP "\fB\-msve\-vector\-bits=\fR\fIbits\fR" 4
  .IX Item "-msve-vector-bits=bits"
! Specify the number of bits in an \s-1SVE\s0 vector register.  This option only has
! an effect when \s-1SVE\s0 is enabled.
  .Sp
! \&\s-1GCC\s0 supports two forms of \s-1SVE\s0 code generation: \*(L"vector-length
! agnostic\*(R" output that works with any size of vector register and
! \&\*(L"vector-length specific\*(R" output that allows \s-1GCC\s0 to make assumptions
  about the vector length when it is useful for optimization reasons.
  The possible values of \fBbits\fR are: \fBscalable\fR, \fB128\fR,
  \&\fB256\fR, \fB512\fR, \fB1024\fR and \fB2048\fR.
! Specifying \fBscalable\fR selects vector-length agnostic
! output.  At present \fB\-msve\-vector\-bits=128\fR also generates vector-length
! agnostic output for big-endian targets.  All other values generate
! vector-length specific code.  The behavior of these values may change
  in future releases and no value except \fBscalable\fR should be
  relied on for producing code that is portable across different
! hardware \s-1SVE\s0 vector lengths.
  .Sp
  The default is \fB\-msve\-vector\-bits=scalable\fR, which produces
! vector-length agnostic code.
  .PP
  \fB\-march\fR and \fB\-mcpu\fR Feature Modifiers
  .IX Subsection "-march and -mcpu Feature Modifiers"
  .PP
  Feature modifiers used with \fB\-march\fR and \fB\-mcpu\fR can be any of
  the following and their inverses \fBno\fR\fIfeature\fR:
! .IP "\fBcrc\fR" 4
  .IX Item "crc"
! Enable \s-1CRC\s0 extension.  This is on by default for
  \&\fB\-march=armv8.1\-a\fR.
! .IP "\fBcrypto\fR" 4
  .IX Item "crypto"
! Enable Crypto extension.  This also enables Advanced \s-1SIMD\s0 and floating-point
  instructions.
! .IP "\fBfp\fR" 4
  .IX Item "fp"
! Enable floating-point instructions.  This is on by default for all possible
  values for options \fB\-march\fR and \fB\-mcpu\fR.
! .IP "\fBsimd\fR" 4
  .IX Item "simd"
! Enable Advanced \s-1SIMD\s0 instructions.  This also enables floating-point
  instructions.  This is on by default for all possible values for options
  \&\fB\-march\fR and \fB\-mcpu\fR.
! .IP "\fBsve\fR" 4
  .IX Item "sve"
  Enable Scalable Vector Extension instructions.  This also enables Advanced
! \&\s-1SIMD\s0 and floating-point instructions.
! .IP "\fBlse\fR" 4
  .IX Item "lse"
  Enable Large System Extension instructions.  This is on by default for
  \&\fB\-march=armv8.1\-a\fR.
! .IP "\fBrdma\fR" 4
  .IX Item "rdma"
  Enable Round Double Multiply Accumulate instructions.  This is on by default
  for \fB\-march=armv8.1\-a\fR.
! .IP "\fBfp16\fR" 4
  .IX Item "fp16"
! Enable \s-1FP16\s0 extension.  This also enables floating-point instructions.
! .IP "\fBfp16fml\fR" 4
  .IX Item "fp16fml"
! Enable \s-1FP16\s0 fmla extension.  This also enables \s-1FP16\s0 extensions and
! floating-point instructions. This option is enabled by default for \fB\-march=armv8.4\-a\fR. Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP "\fBrcpc\fR" 4
  .IX Item "rcpc"
! Enable the RCpc extension.  This enables the use of the \s-1LDAPR\s0 instructions for
! load-acquire atomic semantics, and passes it on to the assembler, enabling
  inline asm statements to use instructions from the RCpc extension.
! .IP "\fBdotprod\fR" 4
  .IX Item "dotprod"
! Enable the Dot Product extension.  This also enables Advanced \s-1SIMD\s0 instructions.
! .IP "\fBaes\fR" 4
  .IX Item "aes"
  Enable the Armv8\-a aes and pmull crypto extension.  This also enables Advanced
! \&\s-1SIMD\s0 instructions.
! .IP "\fBsha2\fR" 4
  .IX Item "sha2"
! Enable the Armv8\-a sha2 crypto extension.  This also enables Advanced \s-1SIMD\s0 instructions.
! .IP "\fBsha3\fR" 4
  .IX Item "sha3"
! Enable the sha512 and sha3 crypto extension.  This also enables Advanced \s-1SIMD\s0
  instructions. Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP "\fBsm4\fR" 4
  .IX Item "sm4"
! Enable the sm3 and sm4 crypto extension.  This also enables Advanced \s-1SIMD\s0 instructions.
  Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP "\fBprofile\fR" 4
  .IX Item "profile"
  Enable the Statistical Profiling extension.  This option is only to enable the
  extension at the assembler level and does not affect code generation.
! .IP "\fBrng\fR" 4
  .IX Item "rng"
  Enable the Armv8.5\-a Random Number instructions.  This option is only to
  enable the extension at the assembler level and does not affect code
  generation.
! .IP "\fBmemtag\fR" 4
  .IX Item "memtag"
  Enable the Armv8.5\-a Memory Tagging Extensions.
  Use of this option with architectures prior to Armv8.5\-A is not supported.
! .IP "\fBsb\fR" 4
  .IX Item "sb"
  Enable the Armv8\-a Speculation Barrier instruction.  This option is only to
  enable the extension at the assembler level and does not affect code
  generation.  This option is enabled by default for \fB\-march=armv8.5\-a\fR.
! .IP "\fBssbs\fR" 4
  .IX Item "ssbs"
  Enable the Armv8\-a Speculative Store Bypass Safe instruction.  This option
  is only to enable the extension at the assembler level and does not affect code
  generation.  This option is enabled by default for \fB\-march=armv8.5\-a\fR.
! .IP "\fBpredres\fR" 4
  .IX Item "predres"
  Enable the Armv8\-a Execution and Data Prediction Restriction instructions.
  This option is only to enable the extension at the assembler level and does
  not affect code generation.  This option is enabled by default for
  \&\fB\-march=armv8.5\-a\fR.
! .IP "\fBsve2\fR" 4
  .IX Item "sve2"
! Enable the Armv8\-a Scalable Vector Extension 2.  This also enables \s-1SVE\s0
  instructions.
! .IP "\fBsve2\-bitperm\fR" 4
  .IX Item "sve2-bitperm"
! Enable \s-1SVE2\s0 bitperm instructions.  This also enables \s-1SVE2\s0 instructions.
! .IP "\fBsve2\-sm4\fR" 4
  .IX Item "sve2-sm4"
! Enable \s-1SVE2\s0 sm4 instructions.  This also enables \s-1SVE2\s0 instructions.
! .IP "\fBsve2\-aes\fR" 4
  .IX Item "sve2-aes"
! Enable \s-1SVE2\s0 aes instructions.  This also enables \s-1SVE2\s0 instructions.
! .IP "\fBsve2\-sha3\fR" 4
  .IX Item "sve2-sha3"
! Enable \s-1SVE2\s0 sha3 instructions.  This also enables \s-1SVE2\s0 instructions.
! .IP "\fBtme\fR" 4
  .IX Item "tme"
  Enable the Transactional Memory Extension.
! .IP "\fBi8mm\fR" 4
  .IX Item "i8mm"
  Enable 8\-bit Integer Matrix Multiply instructions.  This also enables
! Advanced \s-1SIMD\s0 and floating-point instructions.  This option is enabled by
  default for \fB\-march=armv8.6\-a\fR.  Use of this option with architectures
  prior to Armv8.2\-A is not supported.
! .IP "\fBf32mm\fR" 4
  .IX Item "f32mm"
  Enable 32\-bit Floating point Matrix Multiply instructions.  This also enables
! \&\s-1SVE\s0 instructions.  Use of this option with architectures prior to Armv8.2\-A is
  not supported.
! .IP "\fBf64mm\fR" 4
  .IX Item "f64mm"
  Enable 64\-bit Floating point Matrix Multiply instructions.  This also enables
! \&\s-1SVE\s0 instructions.  Use of this option with architectures prior to Armv8.2\-A is
  not supported.
! .IP "\fBbf16\fR" 4
  .IX Item "bf16"
! Enable brain half-precision floating-point instructions.  This also enables
! Advanced \s-1SIMD\s0 and floating-point instructions.  This option is enabled by
  default for \fB\-march=armv8.6\-a\fR.  Use of this option with architectures
  prior to Armv8.2\-A is not supported.
! .IP "\fBls64\fR" 4
  .IX Item "ls64"
  Enable the 64\-byte atomic load and store instructions for accelerators.
  This option is enabled by default for \fB\-march=armv8.7\-a\fR.
! .IP "\fBmops\fR" 4
  .IX Item "mops"
  Enable the instructions to accelerate memory operations like \f(CW\*(C`memcpy\*(C'\fR,
  \&\f(CW\*(C`memmove\*(C'\fR, \f(CW\*(C`memset\*(C'\fR.  This option is enabled by default for
  \&\fB\-march=armv8.8\-a\fR
! .IP "\fBflagm\fR" 4
  .IX Item "flagm"
  Enable the Flag Manipulation instructions Extension.
! .IP "\fBpauth\fR" 4
  .IX Item "pauth"
  Enable the Pointer Authentication Extension.
! .IP "\fBcssc\fR" 4
  .IX Item "cssc"
  Enable the Common Short Sequence Compression instructions.
  .PP
--- 19734,19934 ----
  has additional tuning options, then \fBstandard\fR sets it to its standard
  level.
  \&\fBpac\-ret[+\fR\fIleaf\fR\fB]\fR turns on return address signing to its standard
! level: signing functions that save the return address to memory (non\-leaf
  functions will practically always do this) using the a\-key.  The optional
  argument \fBleaf\fR can be used to extend the signing to include leaf
  functions.  The optional argument \fBb\-key\fR can be used to sign the functions
  with the B\-key instead of the A\-key.
  \&\fBbti\fR turns on branch target identification mechanism.
! .IP \fB\-mharden\-sls=\fR\fIopts\fR 4
  .IX Item "-mharden-sls=opts"
! Enable compiler hardening against straight line speculation (SLS).
! \&\fIopts\fR is a comma\-separated list of the following options:
  .RS 4
! .IP \fBretbr\fR 4
  .IX Item "retbr"
  .PD 0
! .IP \fBblr\fR 4
  .IX Item "blr"
+ .PD
  .RE
  .RS 4
  .Sp
! In addition, \fB\-mharden\-sls=all\fR enables all SLS hardening while
! \&\fB\-mharden\-sls=none\fR disables all SLS hardening.
  .RE
! .IP \fB\-msve\-vector\-bits=\fR\fIbits\fR 4
  .IX Item "-msve-vector-bits=bits"
! Specify the number of bits in an SVE vector register.  This option only has
! an effect when SVE is enabled.
  .Sp
! GCC supports two forms of SVE code generation: "vector\-length
! agnostic" output that works with any size of vector register and
! "vector\-length specific" output that allows GCC to make assumptions
  about the vector length when it is useful for optimization reasons.
  The possible values of \fBbits\fR are: \fBscalable\fR, \fB128\fR,
  \&\fB256\fR, \fB512\fR, \fB1024\fR and \fB2048\fR.
! Specifying \fBscalable\fR selects vector\-length agnostic
! output.  At present \fB\-msve\-vector\-bits=128\fR also generates vector\-length
! agnostic output for big\-endian targets.  All other values generate
! vector\-length specific code.  The behavior of these values may change
  in future releases and no value except \fBscalable\fR should be
  relied on for producing code that is portable across different
! hardware SVE vector lengths.
  .Sp
  The default is \fB\-msve\-vector\-bits=scalable\fR, which produces
! vector\-length agnostic code.
  .PP
  \fB\-march\fR and \fB\-mcpu\fR Feature Modifiers
  .IX Subsection "-march and -mcpu Feature Modifiers"
  .PP
  Feature modifiers used with \fB\-march\fR and \fB\-mcpu\fR can be any of
  the following and their inverses \fBno\fR\fIfeature\fR:
! .IP \fBcrc\fR 4
  .IX Item "crc"
! Enable CRC extension.  This is on by default for
  \&\fB\-march=armv8.1\-a\fR.
! .IP \fBcrypto\fR 4
  .IX Item "crypto"
! Enable Crypto extension.  This also enables Advanced SIMD and floating\-point
  instructions.
! .IP \fBfp\fR 4
  .IX Item "fp"
! Enable floating\-point instructions.  This is on by default for all possible
  values for options \fB\-march\fR and \fB\-mcpu\fR.
! .IP \fBsimd\fR 4
  .IX Item "simd"
! Enable Advanced SIMD instructions.  This also enables floating\-point
  instructions.  This is on by default for all possible values for options
  \&\fB\-march\fR and \fB\-mcpu\fR.
! .IP \fBsve\fR 4
  .IX Item "sve"
  Enable Scalable Vector Extension instructions.  This also enables Advanced
! SIMD and floating\-point instructions.
! .IP \fBlse\fR 4
  .IX Item "lse"
  Enable Large System Extension instructions.  This is on by default for
  \&\fB\-march=armv8.1\-a\fR.
! .IP \fBrdma\fR 4
  .IX Item "rdma"
  Enable Round Double Multiply Accumulate instructions.  This is on by default
  for \fB\-march=armv8.1\-a\fR.
! .IP \fBfp16\fR 4
  .IX Item "fp16"
! Enable FP16 extension.  This also enables floating\-point instructions.
! .IP \fBfp16fml\fR 4
  .IX Item "fp16fml"
! Enable FP16 fmla extension.  This also enables FP16 extensions and
! floating\-point instructions. This option is enabled by default for \fB\-march=armv8.4\-a\fR. Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP \fBrcpc\fR 4
  .IX Item "rcpc"
! Enable the RCpc extension.  This enables the use of the LDAPR instructions for
! load\-acquire atomic semantics, and passes it on to the assembler, enabling
  inline asm statements to use instructions from the RCpc extension.
! .IP \fBdotprod\fR 4
  .IX Item "dotprod"
! Enable the Dot Product extension.  This also enables Advanced SIMD instructions.
! .IP \fBaes\fR 4
  .IX Item "aes"
  Enable the Armv8\-a aes and pmull crypto extension.  This also enables Advanced
! SIMD instructions.
! .IP \fBsha2\fR 4
  .IX Item "sha2"
! Enable the Armv8\-a sha2 crypto extension.  This also enables Advanced SIMD instructions.
! .IP \fBsha3\fR 4
  .IX Item "sha3"
! Enable the sha512 and sha3 crypto extension.  This also enables Advanced SIMD
  instructions. Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP \fBsm4\fR 4
  .IX Item "sm4"
! Enable the sm3 and sm4 crypto extension.  This also enables Advanced SIMD instructions.
  Use of this option with architectures prior to Armv8.2\-A is not supported.
! .IP \fBprofile\fR 4
  .IX Item "profile"
  Enable the Statistical Profiling extension.  This option is only to enable the
  extension at the assembler level and does not affect code generation.
! .IP \fBrng\fR 4
  .IX Item "rng"
  Enable the Armv8.5\-a Random Number instructions.  This option is only to
  enable the extension at the assembler level and does not affect code
  generation.
! .IP \fBmemtag\fR 4
  .IX Item "memtag"
  Enable the Armv8.5\-a Memory Tagging Extensions.
  Use of this option with architectures prior to Armv8.5\-A is not supported.
! .IP \fBsb\fR 4
  .IX Item "sb"
  Enable the Armv8\-a Speculation Barrier instruction.  This option is only to
  enable the extension at the assembler level and does not affect code
  generation.  This option is enabled by default for \fB\-march=armv8.5\-a\fR.
! .IP \fBssbs\fR 4
  .IX Item "ssbs"
  Enable the Armv8\-a Speculative Store Bypass Safe instruction.  This option
  is only to enable the extension at the assembler level and does not affect code
  generation.  This option is enabled by default for \fB\-march=armv8.5\-a\fR.
! .IP \fBpredres\fR 4
  .IX Item "predres"
  Enable the Armv8\-a Execution and Data Prediction Restriction instructions.
  This option is only to enable the extension at the assembler level and does
  not affect code generation.  This option is enabled by default for
  \&\fB\-march=armv8.5\-a\fR.
! .IP \fBsve2\fR 4
  .IX Item "sve2"
! Enable the Armv8\-a Scalable Vector Extension 2.  This also enables SVE
  instructions.
! .IP \fBsve2\-bitperm\fR 4
  .IX Item "sve2-bitperm"
! Enable SVE2 bitperm instructions.  This also enables SVE2 instructions.
! .IP \fBsve2\-sm4\fR 4
  .IX Item "sve2-sm4"
! Enable SVE2 sm4 instructions.  This also enables SVE2 instructions.
! .IP \fBsve2\-aes\fR 4
  .IX Item "sve2-aes"
! Enable SVE2 aes instructions.  This also enables SVE2 instructions.
! .IP \fBsve2\-sha3\fR 4
  .IX Item "sve2-sha3"
! Enable SVE2 sha3 instructions.  This also enables SVE2 instructions.
! .IP \fBtme\fR 4
  .IX Item "tme"
  Enable the Transactional Memory Extension.
! .IP \fBi8mm\fR 4
  .IX Item "i8mm"
  Enable 8\-bit Integer Matrix Multiply instructions.  This also enables
! Advanced SIMD and floating\-point instructions.  This option is enabled by
  default for \fB\-march=armv8.6\-a\fR.  Use of this option with architectures
  prior to Armv8.2\-A is not supported.
! .IP \fBf32mm\fR 4
  .IX Item "f32mm"
  Enable 32\-bit Floating point Matrix Multiply instructions.  This also enables
! SVE instructions.  Use of this option with architectures prior to Armv8.2\-A is
  not supported.
! .IP \fBf64mm\fR 4
  .IX Item "f64mm"
  Enable 64\-bit Floating point Matrix Multiply instructions.  This also enables
! SVE instructions.  Use of this option with architectures prior to Armv8.2\-A is
  not supported.
! .IP \fBbf16\fR 4
  .IX Item "bf16"
! Enable brain half\-precision floating\-point instructions.  This also enables
! Advanced SIMD and floating\-point instructions.  This option is enabled by
  default for \fB\-march=armv8.6\-a\fR.  Use of this option with architectures
  prior to Armv8.2\-A is not supported.
! .IP \fBls64\fR 4
  .IX Item "ls64"
  Enable the 64\-byte atomic load and store instructions for accelerators.
  This option is enabled by default for \fB\-march=armv8.7\-a\fR.
! .IP \fBmops\fR 4
  .IX Item "mops"
  Enable the instructions to accelerate memory operations like \f(CW\*(C`memcpy\*(C'\fR,
  \&\f(CW\*(C`memmove\*(C'\fR, \f(CW\*(C`memset\*(C'\fR.  This option is enabled by default for
  \&\fB\-march=armv8.8\-a\fR
! .IP \fBflagm\fR 4
  .IX Item "flagm"
  Enable the Flag Manipulation instructions Extension.
! .IP \fBpauth\fR 4
  .IX Item "pauth"
  Enable the Pointer Authentication Extension.
! .IP \fBcssc\fR 4
  .IX Item "cssc"
  Enable the Common Short Sequence Compression instructions.
  .PP
*************** Conversely, \fBnofp\fR implies \fBnosimd
*** 20010,20143 ****
  .IX Subsection "Adapteva Epiphany Options"
  .PP
  These \fB\-m\fR options are defined for Adapteva Epiphany:
! .IP "\fB\-mhalf\-reg\-file\fR" 4
  .IX Item "-mhalf-reg-file"
! Don't allocate any register in the range \f(CW\*(C`r32\*(C'\fR...\f(CW\*(C`r63\*(C'\fR.
  That allows code to run on hardware variants that lack these registers.
! .IP "\fB\-mprefer\-short\-insn\-regs\fR" 4
  .IX Item "-mprefer-short-insn-regs"
  Preferentially allocate registers that allow short instruction generation.
  This can result in increased instruction count, so this may either reduce or
  increase overall code size.
! .IP "\fB\-mbranch\-cost=\fR\fInum\fR" 4
  .IX Item "-mbranch-cost=num"
! Set the cost of branches to roughly \fInum\fR \*(L"simple\*(R" instructions.
  This cost is only a heuristic and is not guaranteed to produce
  consistent results across releases.
! .IP "\fB\-mcmove\fR" 4
  .IX Item "-mcmove"
  Enable the generation of conditional moves.
! .IP "\fB\-mnops=\fR\fInum\fR" 4
  .IX Item "-mnops=num"
  Emit \fInum\fR NOPs before every other generated instruction.
! .IP "\fB\-mno\-soft\-cmpsf\fR" 4
  .IX Item "-mno-soft-cmpsf"
! For single-precision floating-point comparisons, emit an \f(CW\*(C`fsub\*(C'\fR instruction
  and test the flags.  This is faster than a software comparison, but can
  get incorrect results in the presence of NaNs, or when two different small
  numbers are compared such that their difference is calculated as zero.
! The default is \fB\-msoft\-cmpsf\fR, which uses slower, but IEEE-compliant,
  software comparisons.
! .IP "\fB\-mstack\-offset=\fR\fInum\fR" 4
  .IX Item "-mstack-offset=num"
  Set the offset between the top of the stack and the stack pointer.
  E.g., a value of 8 means that the eight bytes in the range \f(CW\*(C`sp+0...sp+7\*(C'\fR
  can be used by leaf functions without stack allocation.
  Values other than \fB8\fR or \fB16\fR are untested and unlikely to work.
! Note also that this option changes the \s-1ABI\s0; compiling a program with a
  different stack offset than the libraries have been compiled with
  generally does not work.
  This option can be useful if you want to evaluate if a different stack
  offset would give you better code, but to actually use a different stack
  offset to build working programs, it is recommended to configure the
  toolchain with the appropriate \fB\-\-with\-stack\-offset=\fR\fInum\fR option.
! .IP "\fB\-mno\-round\-nearest\fR" 4
  .IX Item "-mno-round-nearest"
  Make the scheduler assume that the rounding mode has been set to
  truncating.  The default is \fB\-mround\-nearest\fR.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  If not otherwise specified by an attribute, assume all calls might be beyond
  the offset range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, and therefore load the
  function address into a register before performing a (otherwise direct) call.
  This is the default.
! .IP "\fB\-mshort\-calls\fR" 4
  .IX Item "-mshort-calls"
  If not otherwise specified by an attribute, assume all direct calls are
  in the range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, so use these instructions
  for direct calls.  The default is \fB\-mlong\-calls\fR.
! .IP "\fB\-msmall16\fR" 4
  .IX Item "-msmall16"
  Assume addresses can be loaded as 16\-bit unsigned values.  This does not
  apply to function addresses for which \fB\-mlong\-calls\fR semantics
  are in effect.
! .IP "\fB\-mfp\-mode=\fR\fImode\fR" 4
  .IX Item "-mfp-mode=mode"
! Set the prevailing mode of the floating-point unit.
! This determines the floating-point mode that is provided and expected
  at function call and return time.  Making this mode match the mode you
  predominantly need at function start can make your programs smaller and
  faster by avoiding unnecessary mode switches.
  .Sp
  \&\fImode\fR can be set to one the following values:
  .RS 4
! .IP "\fBcaller\fR" 4
  .IX Item "caller"
  Any mode at function entry is valid, and retained or restored when
  the function returns, and when it calls other functions.
  This mode is useful for compiling libraries or other compilation units
  you might want to incorporate into different programs with different
! prevailing \s-1FPU\s0 modes, and the convenience of being able to use a single
  object file outweighs the size and speed overhead for any extra
  mode switching that might be needed, compared with what would be needed
! with a more specific choice of prevailing \s-1FPU\s0 mode.
! .IP "\fBtruncate\fR" 4
  .IX Item "truncate"
! This is the mode used for floating-point calculations with
  truncating (i.e. round towards zero) rounding mode.  That includes
  conversion from floating point to integer.
! .IP "\fBround-nearest\fR" 4
  .IX Item "round-nearest"
! This is the mode used for floating-point calculations with
! round-to-nearest-or-even rounding mode.
! .IP "\fBint\fR" 4
  .IX Item "int"
! This is the mode used to perform integer calculations in the \s-1FPU,\s0 e.g.
! integer multiply, or integer multiply-and-accumulate.
  .RE
  .RS 4
  .Sp
  The default is \fB\-mfp\-mode=caller\fR
  .RE
! .IP "\fB\-mno\-split\-lohi\fR" 4
  .IX Item "-mno-split-lohi"
  .PD 0
! .IP "\fB\-mno\-postinc\fR" 4
  .IX Item "-mno-postinc"
! .IP "\fB\-mno\-postmodify\fR" 4
  .IX Item "-mno-postmodify"
  .PD
  Code generation tweaks that disable, respectively, splitting of 32\-bit
! loads, generation of post-increment addresses, and generation of
! post-modify addresses.  The defaults are \fBmsplit-lohi\fR,
  \&\fB\-mpost\-inc\fR, and \fB\-mpost\-modify\fR.
! .IP "\fB\-mnovect\-double\fR" 4
  .IX Item "-mnovect-double"
! Change the preferred \s-1SIMD\s0 mode to SImode.  The default is
! \&\fB\-mvect\-double\fR, which uses DImode as preferred \s-1SIMD\s0 mode.
! .IP "\fB\-max\-vect\-align=\fR\fInum\fR" 4
  .IX Item "-max-vect-align=num"
! The maximum alignment for \s-1SIMD\s0 vector mode types.
  \&\fInum\fR may be 4 or 8.  The default is 8.
! Note that this is an \s-1ABI\s0 change, even though many library function
! interfaces are unaffected if they don't use \s-1SIMD\s0 vector modes
  in places that affect size and/or alignment of relevant types.
! .IP "\fB\-msplit\-vecmove\-early\fR" 4
  .IX Item "-msplit-vecmove-early"
  Split vector moves into single word moves before reload.  In theory this
  can give better register allocation, but so far the reverse seems to be
  generally the case.
! .IP "\fB\-m1reg\-\fR\fIreg\fR" 4
  .IX Item "-m1reg-reg"
  Specify a register to hold the constant \-1, which makes loading small negative
  constants and certain bitmasks faster.
--- 19941,20074 ----
  .IX Subsection "Adapteva Epiphany Options"
  .PP
  These \fB\-m\fR options are defined for Adapteva Epiphany:
! .IP \fB\-mhalf\-reg\-file\fR 4
  .IX Item "-mhalf-reg-file"
! Don\*(Aqt allocate any register in the range \f(CW\*(C`r32\*(C'\fR...\f(CW\*(C`r63\*(C'\fR.
  That allows code to run on hardware variants that lack these registers.
! .IP \fB\-mprefer\-short\-insn\-regs\fR 4
  .IX Item "-mprefer-short-insn-regs"
  Preferentially allocate registers that allow short instruction generation.
  This can result in increased instruction count, so this may either reduce or
  increase overall code size.
! .IP \fB\-mbranch\-cost=\fR\fInum\fR 4
  .IX Item "-mbranch-cost=num"
! Set the cost of branches to roughly \fInum\fR "simple" instructions.
  This cost is only a heuristic and is not guaranteed to produce
  consistent results across releases.
! .IP \fB\-mcmove\fR 4
  .IX Item "-mcmove"
  Enable the generation of conditional moves.
! .IP \fB\-mnops=\fR\fInum\fR 4
  .IX Item "-mnops=num"
  Emit \fInum\fR NOPs before every other generated instruction.
! .IP \fB\-mno\-soft\-cmpsf\fR 4
  .IX Item "-mno-soft-cmpsf"
! For single\-precision floating\-point comparisons, emit an \f(CW\*(C`fsub\*(C'\fR instruction
  and test the flags.  This is faster than a software comparison, but can
  get incorrect results in the presence of NaNs, or when two different small
  numbers are compared such that their difference is calculated as zero.
! The default is \fB\-msoft\-cmpsf\fR, which uses slower, but IEEE\-compliant,
  software comparisons.
! .IP \fB\-mstack\-offset=\fR\fInum\fR 4
  .IX Item "-mstack-offset=num"
  Set the offset between the top of the stack and the stack pointer.
  E.g., a value of 8 means that the eight bytes in the range \f(CW\*(C`sp+0...sp+7\*(C'\fR
  can be used by leaf functions without stack allocation.
  Values other than \fB8\fR or \fB16\fR are untested and unlikely to work.
! Note also that this option changes the ABI; compiling a program with a
  different stack offset than the libraries have been compiled with
  generally does not work.
  This option can be useful if you want to evaluate if a different stack
  offset would give you better code, but to actually use a different stack
  offset to build working programs, it is recommended to configure the
  toolchain with the appropriate \fB\-\-with\-stack\-offset=\fR\fInum\fR option.
! .IP \fB\-mno\-round\-nearest\fR 4
  .IX Item "-mno-round-nearest"
  Make the scheduler assume that the rounding mode has been set to
  truncating.  The default is \fB\-mround\-nearest\fR.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  If not otherwise specified by an attribute, assume all calls might be beyond
  the offset range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, and therefore load the
  function address into a register before performing a (otherwise direct) call.
  This is the default.
! .IP \fB\-mshort\-calls\fR 4
  .IX Item "-mshort-calls"
  If not otherwise specified by an attribute, assume all direct calls are
  in the range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, so use these instructions
  for direct calls.  The default is \fB\-mlong\-calls\fR.
! .IP \fB\-msmall16\fR 4
  .IX Item "-msmall16"
  Assume addresses can be loaded as 16\-bit unsigned values.  This does not
  apply to function addresses for which \fB\-mlong\-calls\fR semantics
  are in effect.
! .IP \fB\-mfp\-mode=\fR\fImode\fR 4
  .IX Item "-mfp-mode=mode"
! Set the prevailing mode of the floating\-point unit.
! This determines the floating\-point mode that is provided and expected
  at function call and return time.  Making this mode match the mode you
  predominantly need at function start can make your programs smaller and
  faster by avoiding unnecessary mode switches.
  .Sp
  \&\fImode\fR can be set to one the following values:
  .RS 4
! .IP \fBcaller\fR 4
  .IX Item "caller"
  Any mode at function entry is valid, and retained or restored when
  the function returns, and when it calls other functions.
  This mode is useful for compiling libraries or other compilation units
  you might want to incorporate into different programs with different
! prevailing FPU modes, and the convenience of being able to use a single
  object file outweighs the size and speed overhead for any extra
  mode switching that might be needed, compared with what would be needed
! with a more specific choice of prevailing FPU mode.
! .IP \fBtruncate\fR 4
  .IX Item "truncate"
! This is the mode used for floating\-point calculations with
  truncating (i.e. round towards zero) rounding mode.  That includes
  conversion from floating point to integer.
! .IP \fBround\-nearest\fR 4
  .IX Item "round-nearest"
! This is the mode used for floating\-point calculations with
! round\-to\-nearest\-or\-even rounding mode.
! .IP \fBint\fR 4
  .IX Item "int"
! This is the mode used to perform integer calculations in the FPU, e.g.
! integer multiply, or integer multiply\-and\-accumulate.
  .RE
  .RS 4
  .Sp
  The default is \fB\-mfp\-mode=caller\fR
  .RE
! .IP \fB\-mno\-split\-lohi\fR 4
  .IX Item "-mno-split-lohi"
  .PD 0
! .IP \fB\-mno\-postinc\fR 4
  .IX Item "-mno-postinc"
! .IP \fB\-mno\-postmodify\fR 4
  .IX Item "-mno-postmodify"
  .PD
  Code generation tweaks that disable, respectively, splitting of 32\-bit
! loads, generation of post\-increment addresses, and generation of
! post\-modify addresses.  The defaults are \fBmsplit\-lohi\fR,
  \&\fB\-mpost\-inc\fR, and \fB\-mpost\-modify\fR.
! .IP \fB\-mnovect\-double\fR 4
  .IX Item "-mnovect-double"
! Change the preferred SIMD mode to SImode.  The default is
! \&\fB\-mvect\-double\fR, which uses DImode as preferred SIMD mode.
! .IP \fB\-max\-vect\-align=\fR\fInum\fR 4
  .IX Item "-max-vect-align=num"
! The maximum alignment for SIMD vector mode types.
  \&\fInum\fR may be 4 or 8.  The default is 8.
! Note that this is an ABI change, even though many library function
! interfaces are unaffected if they don\*(Aqt use SIMD vector modes
  in places that affect size and/or alignment of relevant types.
! .IP \fB\-msplit\-vecmove\-early\fR 4
  .IX Item "-msplit-vecmove-early"
  Split vector moves into single word moves before reload.  In theory this
  can give better register allocation, but so far the reverse seems to be
  generally the case.
! .IP \fB\-m1reg\-\fR\fIreg\fR 4
  .IX Item "-m1reg-reg"
  Specify a register to hold the constant \-1, which makes loading small negative
  constants and certain bitmasks faster.
*************** which specify use of that register as a
*** 20146,20656 ****
  and \fBnone\fR, which means that no register is used for this
  purpose.  The default is \fB\-m1reg\-none\fR.
  .PP
! \fI\s-1AMD GCN\s0 Options\fR
  .IX Subsection "AMD GCN Options"
  .PP
! These options are defined specifically for the \s-1AMD GCN\s0 port.
! .IP "\fB\-march=\fR\fIgpu\fR" 4
  .IX Item "-march=gpu"
  .PD 0
! .IP "\fB\-mtune=\fR\fIgpu\fR" 4
  .IX Item "-mtune=gpu"
  .PD
  Set architecture type or tuning for \fIgpu\fR. Supported values for \fIgpu\fR
  are
  .RS 4
! .IP "\fBfiji\fR" 4
  .IX Item "fiji"
! Compile for \s-1GCN3\s0 Fiji devices (gfx803).
! .IP "\fBgfx900\fR" 4
  .IX Item "gfx900"
! Compile for \s-1GCN5\s0 Vega 10 devices (gfx900).
! .IP "\fBgfx906\fR" 4
  .IX Item "gfx906"
! Compile for \s-1GCN5\s0 Vega 20 devices (gfx906).
! .IP "\fBgfx908\fR" 4
  .IX Item "gfx908"
! Compile for \s-1CDNA1\s0 Instinct \s-1MI100\s0 series devices (gfx908).
! .IP "\fBgfx90a\fR" 4
  .IX Item "gfx90a"
! Compile for \s-1CDNA2\s0 Instinct \s-1MI200\s0 series devices (gfx90a).
  .RE
  .RS 4
  .RE
! .IP "\fB\-msram\-ecc=on\fR" 4
  .IX Item "-msram-ecc=on"
  .PD 0
! .IP "\fB\-msram\-ecc=off\fR" 4
  .IX Item "-msram-ecc=off"
! .IP "\fB\-msram\-ecc=any\fR" 4
  .IX Item "-msram-ecc=any"
  .PD
! Compile binaries suitable for devices with the SRAM-ECC feature enabled,
! disabled, or either mode.  This feature can be enabled per-process on some
  devices.  The compiled code must match the device mode. The default is
  \&\fBany\fR, for devices that support it.
! .IP "\fB\-mstack\-size=\fR\fIbytes\fR" 4
  .IX Item "-mstack-size=bytes"
! Specify how many \fIbytes\fR of stack space will be requested for each \s-1GPU\s0
! thread (wave-front).  Beware that there may be many threads and limited memory
  available.  The size of the stack allocation may also have an impact on
! run-time performance.  The default is 32KB when using OpenACC or OpenMP, and
  1MB otherwise.
! .IP "\fB\-mxnack\fR" 4
  .IX Item "-mxnack"
! Compile binaries suitable for devices with the \s-1XNACK\s0 feature enabled.  Some
! devices always require \s-1XNACK\s0 and some allow the user to configure \s-1XNACK.\s0  The
  compiled code must match the device mode.  The default is \fB\-mno\-xnack\fR.
  At present this option is a placeholder for support that is not yet
  implemented.
  .PP
! \fI\s-1ARC\s0 Options\fR
  .IX Subsection "ARC Options"
  .PP
  The following options control the architecture variant for which code
  is being compiled:
! .IP "\fB\-mbarrel\-shifter\fR" 4
  .IX Item "-mbarrel-shifter"
  Generate instructions supported by barrel shifter.  This is the default
  unless \fB\-mcpu=ARC601\fR or \fB\-mcpu=ARCEM\fR is in effect.
! .IP "\fB\-mjli\-always\fR" 4
  .IX Item "-mjli-always"
  Force to call a function using jli_s instruction.  This option is
  valid only for ARCv2 architecture.
! .IP "\fB\-mcpu=\fR\fIcpu\fR" 4
  .IX Item "-mcpu=cpu"
  Set architecture type, register usage, and instruction scheduling
  parameters for \fIcpu\fR.  There are also shortcut alias options
  available for backward compatibility and convenience.  Supported
  values for \fIcpu\fR are
  .RS 4
! .IP "\fBarc600\fR" 4
  .IX Item "arc600"
! Compile for \s-1ARC600.\s0  Aliases: \fB\-mA6\fR, \fB\-mARC600\fR.
! .IP "\fBarc601\fR" 4
  .IX Item "arc601"
! Compile for \s-1ARC601.\s0  Alias: \fB\-mARC601\fR.
! .IP "\fBarc700\fR" 4
  .IX Item "arc700"
! Compile for \s-1ARC700.\s0  Aliases: \fB\-mA7\fR, \fB\-mARC700\fR.
  This is the default when configured with \fB\-\-with\-cpu=arc700\fR.
! .IP "\fBarcem\fR" 4
  .IX Item "arcem"
! Compile for \s-1ARC EM.\s0
! .IP "\fBarchs\fR" 4
  .IX Item "archs"
! Compile for \s-1ARC HS.\s0
! .IP "\fBem\fR" 4
  .IX Item "em"
! Compile for \s-1ARC EM CPU\s0 with no hardware extensions.
! .IP "\fBem4\fR" 4
  .IX Item "em4"
! Compile for \s-1ARC EM4 CPU.\s0
! .IP "\fBem4_dmips\fR" 4
  .IX Item "em4_dmips"
! Compile for \s-1ARC EM4 DMIPS CPU.\s0
! .IP "\fBem4_fpus\fR" 4
  .IX Item "em4_fpus"
! Compile for \s-1ARC EM4 DMIPS CPU\s0 with the single-precision floating-point
  extension.
! .IP "\fBem4_fpuda\fR" 4
  .IX Item "em4_fpuda"
! Compile for \s-1ARC EM4 DMIPS CPU\s0 with single-precision floating-point and
  double assist instructions.
! .IP "\fBhs\fR" 4
  .IX Item "hs"
! Compile for \s-1ARC HS CPU\s0 with no hardware extensions except the atomic
  instructions.
! .IP "\fBhs34\fR" 4
  .IX Item "hs34"
! Compile for \s-1ARC HS34 CPU.\s0
! .IP "\fBhs38\fR" 4
  .IX Item "hs38"
! Compile for \s-1ARC HS38 CPU.\s0
! .IP "\fBhs38_linux\fR" 4
  .IX Item "hs38_linux"
! Compile for \s-1ARC HS38 CPU\s0 with all hardware extensions on.
! .IP "\fBhs4x\fR" 4
  .IX Item "hs4x"
! Compile for \s-1ARC\s0 HS4x \s-1CPU.\s0
! .IP "\fBhs4xd\fR" 4
  .IX Item "hs4xd"
! Compile for \s-1ARC\s0 HS4xD \s-1CPU.\s0
! .IP "\fBhs4x_rel31\fR" 4
  .IX Item "hs4x_rel31"
! Compile for \s-1ARC\s0 HS4x \s-1CPU\s0 release 3.10a.
! .IP "\fBarc600_norm\fR" 4
  .IX Item "arc600_norm"
! Compile for \s-1ARC 600 CPU\s0 with \f(CW\*(C`norm\*(C'\fR instructions enabled.
! .IP "\fBarc600_mul32x16\fR" 4
  .IX Item "arc600_mul32x16"
! Compile for \s-1ARC 600 CPU\s0 with \f(CW\*(C`norm\*(C'\fR and 32x16\-bit multiply 
  instructions enabled.
! .IP "\fBarc600_mul64\fR" 4
  .IX Item "arc600_mul64"
! Compile for \s-1ARC 600 CPU\s0 with \f(CW\*(C`norm\*(C'\fR and \f(CW\*(C`mul64\*(C'\fR\-family 
  instructions enabled.
! .IP "\fBarc601_norm\fR" 4
  .IX Item "arc601_norm"
! Compile for \s-1ARC 601 CPU\s0 with \f(CW\*(C`norm\*(C'\fR instructions enabled.
! .IP "\fBarc601_mul32x16\fR" 4
  .IX Item "arc601_mul32x16"
! Compile for \s-1ARC 601 CPU\s0 with \f(CW\*(C`norm\*(C'\fR and 32x16\-bit multiply
  instructions enabled.
! .IP "\fBarc601_mul64\fR" 4
  .IX Item "arc601_mul64"
! Compile for \s-1ARC 601 CPU\s0 with \f(CW\*(C`norm\*(C'\fR and \f(CW\*(C`mul64\*(C'\fR\-family
  instructions enabled.
! .IP "\fBnps400\fR" 4
  .IX Item "nps400"
! Compile for \s-1ARC 700\s0 on \s-1NPS400\s0 chip.
! .IP "\fBem_mini\fR" 4
  .IX Item "em_mini"
! Compile for \s-1ARC EM\s0 minimalist configuration featuring reduced register
  set.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mdpfp\fR" 4
  .IX Item "-mdpfp"
  .PD 0
! .IP "\fB\-mdpfp\-compact\fR" 4
  .IX Item "-mdpfp-compact"
  .PD
! Generate double-precision \s-1FPX\s0 instructions, tuned for the compact
  implementation.
! .IP "\fB\-mdpfp\-fast\fR" 4
  .IX Item "-mdpfp-fast"
! Generate double-precision \s-1FPX\s0 instructions, tuned for the fast
  implementation.
! .IP "\fB\-mno\-dpfp\-lrsr\fR" 4
  .IX Item "-mno-dpfp-lrsr"
! Disable \f(CW\*(C`lr\*(C'\fR and \f(CW\*(C`sr\*(C'\fR instructions from using \s-1FPX\s0 extension
  aux registers.
! .IP "\fB\-mea\fR" 4
  .IX Item "-mea"
  Generate extended arithmetic instructions.  Currently only
  \&\f(CW\*(C`divaw\*(C'\fR, \f(CW\*(C`adds\*(C'\fR, \f(CW\*(C`subs\*(C'\fR, and \f(CW\*(C`sat16\*(C'\fR are
  supported.  Only valid for \fB\-mcpu=ARC700\fR.
! .IP "\fB\-mno\-mpy\fR" 4
  .IX Item "-mno-mpy"
! Do not generate \f(CW\*(C`mpy\*(C'\fR\-family instructions for \s-1ARC700.\s0  This option is
  deprecated.
! .IP "\fB\-mmul32x16\fR" 4
  .IX Item "-mmul32x16"
! Generate 32x16\-bit multiply and multiply-accumulate instructions.
! .IP "\fB\-mmul64\fR" 4
  .IX Item "-mmul64"
  Generate \f(CW\*(C`mul64\*(C'\fR and \f(CW\*(C`mulu64\*(C'\fR instructions.  
  Only valid for \fB\-mcpu=ARC600\fR.
! .IP "\fB\-mnorm\fR" 4
  .IX Item "-mnorm"
  Generate \f(CW\*(C`norm\*(C'\fR instructions.  This is the default if \fB\-mcpu=ARC700\fR
  is in effect.
! .IP "\fB\-mspfp\fR" 4
  .IX Item "-mspfp"
  .PD 0
! .IP "\fB\-mspfp\-compact\fR" 4
  .IX Item "-mspfp-compact"
  .PD
! Generate single-precision \s-1FPX\s0 instructions, tuned for the compact
  implementation.
! .IP "\fB\-mspfp\-fast\fR" 4
  .IX Item "-mspfp-fast"
! Generate single-precision \s-1FPX\s0 instructions, tuned for the fast
  implementation.
! .IP "\fB\-msimd\fR" 4
  .IX Item "-msimd"
! Enable generation of \s-1ARC SIMD\s0 instructions via target-specific
  builtins.  Only valid for \fB\-mcpu=ARC700\fR.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  This option ignored; it is provided for compatibility purposes only.
! Software floating-point code is emitted by default, and this default
! can overridden by \s-1FPX\s0 options; \fB\-mspfp\fR, \fB\-mspfp\-compact\fR, or
  \&\fB\-mspfp\-fast\fR for single precision, and \fB\-mdpfp\fR,
  \&\fB\-mdpfp\-compact\fR, or \fB\-mdpfp\-fast\fR for double precision.
! .IP "\fB\-mswap\fR" 4
  .IX Item "-mswap"
  Generate \f(CW\*(C`swap\*(C'\fR instructions.
! .IP "\fB\-matomic\fR" 4
  .IX Item "-matomic"
  This enables use of the locked load/store conditional extension to implement
! atomic memory built-in functions.  Not available for \s-1ARC\s0 6xx or \s-1ARC
! EM\s0 cores.
! .IP "\fB\-mdiv\-rem\fR" 4
  .IX Item "-mdiv-rem"
  Enable \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`rem\*(C'\fR instructions for ARCv2 cores.
! .IP "\fB\-mcode\-density\fR" 4
  .IX Item "-mcode-density"
! Enable code density instructions for \s-1ARC EM.\s0  
! This option is on by default for \s-1ARC HS.\s0
! .IP "\fB\-mll64\fR" 4
  .IX Item "-mll64"
! Enable double load/store operations for \s-1ARC HS\s0 cores.
! .IP "\fB\-mtp\-regno=\fR\fIregno\fR" 4
  .IX Item "-mtp-regno=regno"
  Specify thread pointer register number.
! .IP "\fB\-mmpy\-option=\fR\fImulto\fR" 4
  .IX Item "-mmpy-option=multo"
  Compile ARCv2 code with a multiplier design option.  You can specify 
  the option using either a string or numeric value for \fImulto\fR.  
  \&\fBwlh1\fR is the default value.  The recognized values are:
  .RS 4
! .IP "\fB0\fR" 4
  .IX Item "0"
  .PD 0
! .IP "\fBnone\fR" 4
  .IX Item "none"
  .PD
  No multiplier available.
! .IP "\fB1\fR" 4
  .IX Item "1"
  .PD 0
! .IP "\fBw\fR" 4
  .IX Item "w"
  .PD
  16x16 multiplier, fully pipelined.
  The following instructions are enabled: \f(CW\*(C`mpyw\*(C'\fR and \f(CW\*(C`mpyuw\*(C'\fR.
! .IP "\fB2\fR" 4
  .IX Item "2"
  .PD 0
! .IP "\fBwlh1\fR" 4
  .IX Item "wlh1"
  .PD
  32x32 multiplier, fully
  pipelined (1 stage).  The following instructions are additionally
  enabled: \f(CW\*(C`mpy\*(C'\fR, \f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP "\fB3\fR" 4
  .IX Item "3"
  .PD 0
! .IP "\fBwlh2\fR" 4
  .IX Item "wlh2"
  .PD
  32x32 multiplier, fully pipelined
  (2 stages).  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP "\fB4\fR" 4
  .IX Item "4"
  .PD 0
! .IP "\fBwlh3\fR" 4
  .IX Item "wlh3"
  .PD
  Two 16x16 multipliers, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP "\fB5\fR" 4
  .IX Item "5"
  .PD 0
! .IP "\fBwlh4\fR" 4
  .IX Item "wlh4"
  .PD
  One 16x16 multiplier, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP "\fB6\fR" 4
  .IX Item "6"
  .PD 0
! .IP "\fBwlh5\fR" 4
  .IX Item "wlh5"
  .PD
  One 32x4 multiplier, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP "\fB7\fR" 4
  .IX Item "7"
  .PD 0
! .IP "\fBplus_dmpy\fR" 4
  .IX Item "plus_dmpy"
  .PD
! \&\s-1ARC HS SIMD\s0 support.
! .IP "\fB8\fR" 4
  .IX Item "8"
  .PD 0
! .IP "\fBplus_macd\fR" 4
  .IX Item "plus_macd"
  .PD
! \&\s-1ARC HS SIMD\s0 support.
! .IP "\fB9\fR" 4
  .IX Item "9"
  .PD 0
! .IP "\fBplus_qmacw\fR" 4
  .IX Item "plus_qmacw"
  .PD
! \&\s-1ARC HS SIMD\s0 support.
  .RE
  .RS 4
  .Sp
  This option is only available for ARCv2 cores.
  .RE
! .IP "\fB\-mfpu=\fR\fIfpu\fR" 4
  .IX Item "-mfpu=fpu"
! Enables support for specific floating-point hardware extensions for ARCv2
  cores.  Supported values for \fIfpu\fR are:
  .RS 4
! .IP "\fBfpus\fR" 4
  .IX Item "fpus"
! Enables support for single-precision floating-point hardware
  extensions.
! .IP "\fBfpud\fR" 4
  .IX Item "fpud"
! Enables support for double-precision floating-point hardware
! extensions.  The single-precision floating-point extension is also
! enabled.  Not available for \s-1ARC EM.\s0
! .IP "\fBfpuda\fR" 4
  .IX Item "fpuda"
! Enables support for double-precision floating-point hardware
! extensions using double-precision assist instructions.  The single-precision
! floating-point extension is also enabled.  This option is
! only available for \s-1ARC EM.\s0
! .IP "\fBfpuda_div\fR" 4
  .IX Item "fpuda_div"
! Enables support for double-precision floating-point hardware
! extensions using double-precision assist instructions.
! The single-precision floating-point, square-root, and divide 
  extensions are also enabled.  This option is
! only available for \s-1ARC EM.\s0
! .IP "\fBfpuda_fma\fR" 4
  .IX Item "fpuda_fma"
! Enables support for double-precision floating-point hardware
! extensions using double-precision assist instructions.
! The single-precision floating-point and fused multiply and add 
  hardware extensions are also enabled.  This option is
! only available for \s-1ARC EM.\s0
! .IP "\fBfpuda_all\fR" 4
  .IX Item "fpuda_all"
! Enables support for double-precision floating-point hardware
! extensions using double-precision assist instructions.
! All single-precision floating-point hardware extensions are also
! enabled.  This option is only available for \s-1ARC EM.\s0
! .IP "\fBfpus_div\fR" 4
  .IX Item "fpus_div"
! Enables support for single-precision floating-point, square-root and divide 
  hardware extensions.
! .IP "\fBfpud_div\fR" 4
  .IX Item "fpud_div"
! Enables support for double-precision floating-point, square-root and divide 
  hardware extensions.  This option
! includes option \fBfpus_div\fR. Not available for \s-1ARC EM.\s0
! .IP "\fBfpus_fma\fR" 4
  .IX Item "fpus_fma"
! Enables support for single-precision floating-point and 
  fused multiply and add hardware extensions.
! .IP "\fBfpud_fma\fR" 4
  .IX Item "fpud_fma"
! Enables support for double-precision floating-point and 
  fused multiply and add hardware extensions.  This option
! includes option \fBfpus_fma\fR.  Not available for \s-1ARC EM.\s0
! .IP "\fBfpus_all\fR" 4
  .IX Item "fpus_all"
! Enables support for all single-precision floating-point hardware
  extensions.
! .IP "\fBfpud_all\fR" 4
  .IX Item "fpud_all"
! Enables support for all single\- and double-precision floating-point
! hardware extensions.  Not available for \s-1ARC EM.\s0
  .RE
  .RS 4
  .RE
! .IP "\fB\-mirq\-ctrl\-saved=\fR\fIregister-range\fR\fB,\fR \fIblink\fR\fB,\fR \fIlp_count\fR" 4
  .IX Item "-mirq-ctrl-saved=register-range, blink, lp_count"
! Specifies general-purposes registers that the processor automatically
! saves/restores on interrupt entry and exit.  \fIregister-range\fR is
  specified as two registers separated by a dash.  The register range
  always starts with \f(CW\*(C`r0\*(C'\fR, the upper limit is \f(CW\*(C`fp\*(C'\fR register.
  \&\fIblink\fR and \fIlp_count\fR are optional.  This option is only
! valid for \s-1ARC EM\s0 and \s-1ARC HS\s0 cores.
! .IP "\fB\-mrgf\-banked\-regs=\fR\fInumber\fR" 4
  .IX Item "-mrgf-banked-regs=number"
  Specifies the number of registers replicated in second register bank
  on entry to fast interrupt.  Fast interrupts are interrupts with the
! highest priority level P0.  These interrupts save only \s-1PC\s0 and \s-1STATUS32\s0
  registers to avoid memory transactions during interrupt entry and exit
  sequences.  Use this option when you are using fast interrupts in an
! \&\s-1ARC V2\s0 family processor.  Permitted values are 4, 8, 16, and 32.
! .IP "\fB\-mlpc\-width=\fR\fIwidth\fR" 4
  .IX Item "-mlpc-width=width"
  Specify the width of the \f(CW\*(C`lp_count\*(C'\fR register.  Valid values for
  \&\fIwidth\fR are 8, 16, 20, 24, 28 and 32 bits.  The default width is
  fixed to 32 bits.  If the width is less than 32, the compiler does not
! attempt to transform loops in your program to use the zero-delay loop
  mechanism unless it is known that the \f(CW\*(C`lp_count\*(C'\fR register can
! hold the required loop-counter value.  Depending on the width
! specified, the compiler and run-time library might continue to use the
  loop mechanism for various needs.  This option defines macro
  \&\f(CW\*(C`_\|_ARC_LPC_WIDTH_\|_\*(C'\fR with the value of \fIwidth\fR.
! .IP "\fB\-mrf16\fR" 4
  .IX Item "-mrf16"
  This option instructs the compiler to generate code for a 16\-entry
  register file.  This option defines the \f(CW\*(C`_\|_ARC_RF16_\|_\*(C'\fR
  preprocessor macro.
! .IP "\fB\-mbranch\-index\fR" 4
  .IX Item "-mbranch-index"
  Enable use of \f(CW\*(C`bi\*(C'\fR or \f(CW\*(C`bih\*(C'\fR instructions to implement jump
  tables.
  .PP
  The following options are passed through to the assembler, and also
  define preprocessor macro symbols.
! .IP "\fB\-mdsp\-packa\fR" 4
  .IX Item "-mdsp-packa"
! Passed down to the assembler to enable the \s-1DSP\s0 Pack A extensions.
  Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdsp_packa\*(C'\fR.  This option is
  deprecated.
! .IP "\fB\-mdvbf\fR" 4
  .IX Item "-mdvbf"
  Passed down to the assembler to enable the dual Viterbi butterfly
  extension.  Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdvbf\*(C'\fR.  This
  option is deprecated.
! .IP "\fB\-mlock\fR" 4
  .IX Item "-mlock"
  Passed down to the assembler to enable the locked load/store
  conditional extension.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xlock\*(C'\fR.
! .IP "\fB\-mmac\-d16\fR" 4
  .IX Item "-mmac-d16"
  Passed down to the assembler.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xxmac_d16\*(C'\fR.  This option is deprecated.
! .IP "\fB\-mmac\-24\fR" 4
  .IX Item "-mmac-24"
  Passed down to the assembler.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xxmac_24\*(C'\fR.  This option is deprecated.
! .IP "\fB\-mrtsc\fR" 4
  .IX Item "-mrtsc"
! Passed down to the assembler to enable the 64\-bit time-stamp counter
  extension instruction.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xrtsc\*(C'\fR.  This option is deprecated.
! .IP "\fB\-mswape\fR" 4
  .IX Item "-mswape"
  Passed down to the assembler to enable the swap byte ordering
  extension instruction.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xswape\*(C'\fR.
! .IP "\fB\-mtelephony\fR" 4
  .IX Item "-mtelephony"
! Passed down to the assembler to enable dual\- and single-operand
  instructions for telephony.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xtelephony\*(C'\fR.  This option is deprecated.
! .IP "\fB\-mxy\fR" 4
  .IX Item "-mxy"
! Passed down to the assembler to enable the \s-1XY\s0 memory extension.  Also
  sets the preprocessor symbol \f(CW\*(C`_\|_Xxy\*(C'\fR.
  .PP
  The following options control how the assembly code is annotated:
! .IP "\fB\-misize\fR" 4
  .IX Item "-misize"
  Annotate assembler instructions with estimated addresses.
! .IP "\fB\-mannotate\-align\fR" 4
  .IX Item "-mannotate-align"
  Explain what alignment considerations lead to the decision to make an
  instruction short or long.
  .PP
  The following options are passed through to the linker:
! .IP "\fB\-marclinux\fR" 4
  .IX Item "-marclinux"
  Passed through to the linker, to specify use of the \f(CW\*(C`arclinux\*(C'\fR emulation.
  This option is enabled by default in tool chains built for
  \&\f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets
  when profiling is not requested.
! .IP "\fB\-marclinux_prof\fR" 4
  .IX Item "-marclinux_prof"
  Passed through to the linker, to specify use of the
  \&\f(CW\*(C`arclinux_prof\*(C'\fR emulation.  This option is enabled by default in
--- 20077,20587 ----
  and \fBnone\fR, which means that no register is used for this
  purpose.  The default is \fB\-m1reg\-none\fR.
  .PP
! \fIAMD GCN Options\fR
  .IX Subsection "AMD GCN Options"
  .PP
! These options are defined specifically for the AMD GCN port.
! .IP \fB\-march=\fR\fIgpu\fR 4
  .IX Item "-march=gpu"
  .PD 0
! .IP \fB\-mtune=\fR\fIgpu\fR 4
  .IX Item "-mtune=gpu"
  .PD
  Set architecture type or tuning for \fIgpu\fR. Supported values for \fIgpu\fR
  are
  .RS 4
! .IP \fBfiji\fR 4
  .IX Item "fiji"
! Compile for GCN3 Fiji devices (gfx803).
! .IP \fBgfx900\fR 4
  .IX Item "gfx900"
! Compile for GCN5 Vega 10 devices (gfx900).
! .IP \fBgfx906\fR 4
  .IX Item "gfx906"
! Compile for GCN5 Vega 20 devices (gfx906).
! .IP \fBgfx908\fR 4
  .IX Item "gfx908"
! Compile for CDNA1 Instinct MI100 series devices (gfx908).
! .IP \fBgfx90a\fR 4
  .IX Item "gfx90a"
! Compile for CDNA2 Instinct MI200 series devices (gfx90a).
  .RE
  .RS 4
  .RE
! .IP \fB\-msram\-ecc=on\fR 4
  .IX Item "-msram-ecc=on"
  .PD 0
! .IP \fB\-msram\-ecc=off\fR 4
  .IX Item "-msram-ecc=off"
! .IP \fB\-msram\-ecc=any\fR 4
  .IX Item "-msram-ecc=any"
  .PD
! Compile binaries suitable for devices with the SRAM\-ECC feature enabled,
! disabled, or either mode.  This feature can be enabled per\-process on some
  devices.  The compiled code must match the device mode. The default is
  \&\fBany\fR, for devices that support it.
! .IP \fB\-mstack\-size=\fR\fIbytes\fR 4
  .IX Item "-mstack-size=bytes"
! Specify how many \fIbytes\fR of stack space will be requested for each GPU
! thread (wave\-front).  Beware that there may be many threads and limited memory
  available.  The size of the stack allocation may also have an impact on
! run\-time performance.  The default is 32KB when using OpenACC or OpenMP, and
  1MB otherwise.
! .IP \fB\-mxnack\fR 4
  .IX Item "-mxnack"
! Compile binaries suitable for devices with the XNACK feature enabled.  Some
! devices always require XNACK and some allow the user to configure XNACK.  The
  compiled code must match the device mode.  The default is \fB\-mno\-xnack\fR.
  At present this option is a placeholder for support that is not yet
  implemented.
  .PP
! \fIARC Options\fR
  .IX Subsection "ARC Options"
  .PP
  The following options control the architecture variant for which code
  is being compiled:
! .IP \fB\-mbarrel\-shifter\fR 4
  .IX Item "-mbarrel-shifter"
  Generate instructions supported by barrel shifter.  This is the default
  unless \fB\-mcpu=ARC601\fR or \fB\-mcpu=ARCEM\fR is in effect.
! .IP \fB\-mjli\-always\fR 4
  .IX Item "-mjli-always"
  Force to call a function using jli_s instruction.  This option is
  valid only for ARCv2 architecture.
! .IP \fB\-mcpu=\fR\fIcpu\fR 4
  .IX Item "-mcpu=cpu"
  Set architecture type, register usage, and instruction scheduling
  parameters for \fIcpu\fR.  There are also shortcut alias options
  available for backward compatibility and convenience.  Supported
  values for \fIcpu\fR are
  .RS 4
! .IP \fBarc600\fR 4
  .IX Item "arc600"
! Compile for ARC600.  Aliases: \fB\-mA6\fR, \fB\-mARC600\fR.
! .IP \fBarc601\fR 4
  .IX Item "arc601"
! Compile for ARC601.  Alias: \fB\-mARC601\fR.
! .IP \fBarc700\fR 4
  .IX Item "arc700"
! Compile for ARC700.  Aliases: \fB\-mA7\fR, \fB\-mARC700\fR.
  This is the default when configured with \fB\-\-with\-cpu=arc700\fR.
! .IP \fBarcem\fR 4
  .IX Item "arcem"
! Compile for ARC EM.
! .IP \fBarchs\fR 4
  .IX Item "archs"
! Compile for ARC HS.
! .IP \fBem\fR 4
  .IX Item "em"
! Compile for ARC EM CPU with no hardware extensions.
! .IP \fBem4\fR 4
  .IX Item "em4"
! Compile for ARC EM4 CPU.
! .IP \fBem4_dmips\fR 4
  .IX Item "em4_dmips"
! Compile for ARC EM4 DMIPS CPU.
! .IP \fBem4_fpus\fR 4
  .IX Item "em4_fpus"
! Compile for ARC EM4 DMIPS CPU with the single\-precision floating\-point
  extension.
! .IP \fBem4_fpuda\fR 4
  .IX Item "em4_fpuda"
! Compile for ARC EM4 DMIPS CPU with single\-precision floating\-point and
  double assist instructions.
! .IP \fBhs\fR 4
  .IX Item "hs"
! Compile for ARC HS CPU with no hardware extensions except the atomic
  instructions.
! .IP \fBhs34\fR 4
  .IX Item "hs34"
! Compile for ARC HS34 CPU.
! .IP \fBhs38\fR 4
  .IX Item "hs38"
! Compile for ARC HS38 CPU.
! .IP \fBhs38_linux\fR 4
  .IX Item "hs38_linux"
! Compile for ARC HS38 CPU with all hardware extensions on.
! .IP \fBhs4x\fR 4
  .IX Item "hs4x"
! Compile for ARC HS4x CPU.
! .IP \fBhs4xd\fR 4
  .IX Item "hs4xd"
! Compile for ARC HS4xD CPU.
! .IP \fBhs4x_rel31\fR 4
  .IX Item "hs4x_rel31"
! Compile for ARC HS4x CPU release 3.10a.
! .IP \fBarc600_norm\fR 4
  .IX Item "arc600_norm"
! Compile for ARC 600 CPU with \f(CW\*(C`norm\*(C'\fR instructions enabled.
! .IP \fBarc600_mul32x16\fR 4
  .IX Item "arc600_mul32x16"
! Compile for ARC 600 CPU with \f(CW\*(C`norm\*(C'\fR and 32x16\-bit multiply 
  instructions enabled.
! .IP \fBarc600_mul64\fR 4
  .IX Item "arc600_mul64"
! Compile for ARC 600 CPU with \f(CW\*(C`norm\*(C'\fR and \f(CW\*(C`mul64\*(C'\fR\-family 
  instructions enabled.
! .IP \fBarc601_norm\fR 4
  .IX Item "arc601_norm"
! Compile for ARC 601 CPU with \f(CW\*(C`norm\*(C'\fR instructions enabled.
! .IP \fBarc601_mul32x16\fR 4
  .IX Item "arc601_mul32x16"
! Compile for ARC 601 CPU with \f(CW\*(C`norm\*(C'\fR and 32x16\-bit multiply
  instructions enabled.
! .IP \fBarc601_mul64\fR 4
  .IX Item "arc601_mul64"
! Compile for ARC 601 CPU with \f(CW\*(C`norm\*(C'\fR and \f(CW\*(C`mul64\*(C'\fR\-family
  instructions enabled.
! .IP \fBnps400\fR 4
  .IX Item "nps400"
! Compile for ARC 700 on NPS400 chip.
! .IP \fBem_mini\fR 4
  .IX Item "em_mini"
! Compile for ARC EM minimalist configuration featuring reduced register
  set.
  .RE
  .RS 4
  .RE
! .IP \fB\-mdpfp\fR 4
  .IX Item "-mdpfp"
  .PD 0
! .IP \fB\-mdpfp\-compact\fR 4
  .IX Item "-mdpfp-compact"
  .PD
! Generate double\-precision FPX instructions, tuned for the compact
  implementation.
! .IP \fB\-mdpfp\-fast\fR 4
  .IX Item "-mdpfp-fast"
! Generate double\-precision FPX instructions, tuned for the fast
  implementation.
! .IP \fB\-mno\-dpfp\-lrsr\fR 4
  .IX Item "-mno-dpfp-lrsr"
! Disable \f(CW\*(C`lr\*(C'\fR and \f(CW\*(C`sr\*(C'\fR instructions from using FPX extension
  aux registers.
! .IP \fB\-mea\fR 4
  .IX Item "-mea"
  Generate extended arithmetic instructions.  Currently only
  \&\f(CW\*(C`divaw\*(C'\fR, \f(CW\*(C`adds\*(C'\fR, \f(CW\*(C`subs\*(C'\fR, and \f(CW\*(C`sat16\*(C'\fR are
  supported.  Only valid for \fB\-mcpu=ARC700\fR.
! .IP \fB\-mno\-mpy\fR 4
  .IX Item "-mno-mpy"
! Do not generate \f(CW\*(C`mpy\*(C'\fR\-family instructions for ARC700.  This option is
  deprecated.
! .IP \fB\-mmul32x16\fR 4
  .IX Item "-mmul32x16"
! Generate 32x16\-bit multiply and multiply\-accumulate instructions.
! .IP \fB\-mmul64\fR 4
  .IX Item "-mmul64"
  Generate \f(CW\*(C`mul64\*(C'\fR and \f(CW\*(C`mulu64\*(C'\fR instructions.  
  Only valid for \fB\-mcpu=ARC600\fR.
! .IP \fB\-mnorm\fR 4
  .IX Item "-mnorm"
  Generate \f(CW\*(C`norm\*(C'\fR instructions.  This is the default if \fB\-mcpu=ARC700\fR
  is in effect.
! .IP \fB\-mspfp\fR 4
  .IX Item "-mspfp"
  .PD 0
! .IP \fB\-mspfp\-compact\fR 4
  .IX Item "-mspfp-compact"
  .PD
! Generate single\-precision FPX instructions, tuned for the compact
  implementation.
! .IP \fB\-mspfp\-fast\fR 4
  .IX Item "-mspfp-fast"
! Generate single\-precision FPX instructions, tuned for the fast
  implementation.
! .IP \fB\-msimd\fR 4
  .IX Item "-msimd"
! Enable generation of ARC SIMD instructions via target\-specific
  builtins.  Only valid for \fB\-mcpu=ARC700\fR.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  This option ignored; it is provided for compatibility purposes only.
! Software floating\-point code is emitted by default, and this default
! can overridden by FPX options; \fB\-mspfp\fR, \fB\-mspfp\-compact\fR, or
  \&\fB\-mspfp\-fast\fR for single precision, and \fB\-mdpfp\fR,
  \&\fB\-mdpfp\-compact\fR, or \fB\-mdpfp\-fast\fR for double precision.
! .IP \fB\-mswap\fR 4
  .IX Item "-mswap"
  Generate \f(CW\*(C`swap\*(C'\fR instructions.
! .IP \fB\-matomic\fR 4
  .IX Item "-matomic"
  This enables use of the locked load/store conditional extension to implement
! atomic memory built\-in functions.  Not available for ARC 6xx or ARC
! EM cores.
! .IP \fB\-mdiv\-rem\fR 4
  .IX Item "-mdiv-rem"
  Enable \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`rem\*(C'\fR instructions for ARCv2 cores.
! .IP \fB\-mcode\-density\fR 4
  .IX Item "-mcode-density"
! Enable code density instructions for ARC EM.  
! This option is on by default for ARC HS.
! .IP \fB\-mll64\fR 4
  .IX Item "-mll64"
! Enable double load/store operations for ARC HS cores.
! .IP \fB\-mtp\-regno=\fR\fIregno\fR 4
  .IX Item "-mtp-regno=regno"
  Specify thread pointer register number.
! .IP \fB\-mmpy\-option=\fR\fImulto\fR 4
  .IX Item "-mmpy-option=multo"
  Compile ARCv2 code with a multiplier design option.  You can specify 
  the option using either a string or numeric value for \fImulto\fR.  
  \&\fBwlh1\fR is the default value.  The recognized values are:
  .RS 4
! .IP \fB0\fR 4
  .IX Item "0"
  .PD 0
! .IP \fBnone\fR 4
  .IX Item "none"
  .PD
  No multiplier available.
! .IP \fB1\fR 4
  .IX Item "1"
  .PD 0
! .IP \fBw\fR 4
  .IX Item "w"
  .PD
  16x16 multiplier, fully pipelined.
  The following instructions are enabled: \f(CW\*(C`mpyw\*(C'\fR and \f(CW\*(C`mpyuw\*(C'\fR.
! .IP \fB2\fR 4
  .IX Item "2"
  .PD 0
! .IP \fBwlh1\fR 4
  .IX Item "wlh1"
  .PD
  32x32 multiplier, fully
  pipelined (1 stage).  The following instructions are additionally
  enabled: \f(CW\*(C`mpy\*(C'\fR, \f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP \fB3\fR 4
  .IX Item "3"
  .PD 0
! .IP \fBwlh2\fR 4
  .IX Item "wlh2"
  .PD
  32x32 multiplier, fully pipelined
  (2 stages).  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP \fB4\fR 4
  .IX Item "4"
  .PD 0
! .IP \fBwlh3\fR 4
  .IX Item "wlh3"
  .PD
  Two 16x16 multipliers, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP \fB5\fR 4
  .IX Item "5"
  .PD 0
! .IP \fBwlh4\fR 4
  .IX Item "wlh4"
  .PD
  One 16x16 multiplier, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP \fB6\fR 4
  .IX Item "6"
  .PD 0
! .IP \fBwlh5\fR 4
  .IX Item "wlh5"
  .PD
  One 32x4 multiplier, blocking,
  sequential.  The following instructions are additionally enabled: \f(CW\*(C`mpy\*(C'\fR,
  \&\f(CW\*(C`mpyu\*(C'\fR, \f(CW\*(C`mpym\*(C'\fR, \f(CW\*(C`mpymu\*(C'\fR, and \f(CW\*(C`mpy_s\*(C'\fR.
! .IP \fB7\fR 4
  .IX Item "7"
  .PD 0
! .IP \fBplus_dmpy\fR 4
  .IX Item "plus_dmpy"
  .PD
! ARC HS SIMD support.
! .IP \fB8\fR 4
  .IX Item "8"
  .PD 0
! .IP \fBplus_macd\fR 4
  .IX Item "plus_macd"
  .PD
! ARC HS SIMD support.
! .IP \fB9\fR 4
  .IX Item "9"
  .PD 0
! .IP \fBplus_qmacw\fR 4
  .IX Item "plus_qmacw"
  .PD
! ARC HS SIMD support.
  .RE
  .RS 4
  .Sp
  This option is only available for ARCv2 cores.
  .RE
! .IP \fB\-mfpu=\fR\fIfpu\fR 4
  .IX Item "-mfpu=fpu"
! Enables support for specific floating\-point hardware extensions for ARCv2
  cores.  Supported values for \fIfpu\fR are:
  .RS 4
! .IP \fBfpus\fR 4
  .IX Item "fpus"
! Enables support for single\-precision floating\-point hardware
  extensions.
! .IP \fBfpud\fR 4
  .IX Item "fpud"
! Enables support for double\-precision floating\-point hardware
! extensions.  The single\-precision floating\-point extension is also
! enabled.  Not available for ARC EM.
! .IP \fBfpuda\fR 4
  .IX Item "fpuda"
! Enables support for double\-precision floating\-point hardware
! extensions using double\-precision assist instructions.  The single\-precision
! floating\-point extension is also enabled.  This option is
! only available for ARC EM.
! .IP \fBfpuda_div\fR 4
  .IX Item "fpuda_div"
! Enables support for double\-precision floating\-point hardware
! extensions using double\-precision assist instructions.
! The single\-precision floating\-point, square\-root, and divide 
  extensions are also enabled.  This option is
! only available for ARC EM.
! .IP \fBfpuda_fma\fR 4
  .IX Item "fpuda_fma"
! Enables support for double\-precision floating\-point hardware
! extensions using double\-precision assist instructions.
! The single\-precision floating\-point and fused multiply and add 
  hardware extensions are also enabled.  This option is
! only available for ARC EM.
! .IP \fBfpuda_all\fR 4
  .IX Item "fpuda_all"
! Enables support for double\-precision floating\-point hardware
! extensions using double\-precision assist instructions.
! All single\-precision floating\-point hardware extensions are also
! enabled.  This option is only available for ARC EM.
! .IP \fBfpus_div\fR 4
  .IX Item "fpus_div"
! Enables support for single\-precision floating\-point, square\-root and divide 
  hardware extensions.
! .IP \fBfpud_div\fR 4
  .IX Item "fpud_div"
! Enables support for double\-precision floating\-point, square\-root and divide 
  hardware extensions.  This option
! includes option \fBfpus_div\fR. Not available for ARC EM.
! .IP \fBfpus_fma\fR 4
  .IX Item "fpus_fma"
! Enables support for single\-precision floating\-point and 
  fused multiply and add hardware extensions.
! .IP \fBfpud_fma\fR 4
  .IX Item "fpud_fma"
! Enables support for double\-precision floating\-point and 
  fused multiply and add hardware extensions.  This option
! includes option \fBfpus_fma\fR.  Not available for ARC EM.
! .IP \fBfpus_all\fR 4
  .IX Item "fpus_all"
! Enables support for all single\-precision floating\-point hardware
  extensions.
! .IP \fBfpud_all\fR 4
  .IX Item "fpud_all"
! Enables support for all single\- and double\-precision floating\-point
! hardware extensions.  Not available for ARC EM.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mirq\-ctrl\-saved=\fR\fIregister\-range\fR\fB,\fR \fIblink\fR\fB,\fR \fIlp_count\fR" 4
  .IX Item "-mirq-ctrl-saved=register-range, blink, lp_count"
! Specifies general\-purposes registers that the processor automatically
! saves/restores on interrupt entry and exit.  \fIregister\-range\fR is
  specified as two registers separated by a dash.  The register range
  always starts with \f(CW\*(C`r0\*(C'\fR, the upper limit is \f(CW\*(C`fp\*(C'\fR register.
  \&\fIblink\fR and \fIlp_count\fR are optional.  This option is only
! valid for ARC EM and ARC HS cores.
! .IP \fB\-mrgf\-banked\-regs=\fR\fInumber\fR 4
  .IX Item "-mrgf-banked-regs=number"
  Specifies the number of registers replicated in second register bank
  on entry to fast interrupt.  Fast interrupts are interrupts with the
! highest priority level P0.  These interrupts save only PC and STATUS32
  registers to avoid memory transactions during interrupt entry and exit
  sequences.  Use this option when you are using fast interrupts in an
! ARC V2 family processor.  Permitted values are 4, 8, 16, and 32.
! .IP \fB\-mlpc\-width=\fR\fIwidth\fR 4
  .IX Item "-mlpc-width=width"
  Specify the width of the \f(CW\*(C`lp_count\*(C'\fR register.  Valid values for
  \&\fIwidth\fR are 8, 16, 20, 24, 28 and 32 bits.  The default width is
  fixed to 32 bits.  If the width is less than 32, the compiler does not
! attempt to transform loops in your program to use the zero\-delay loop
  mechanism unless it is known that the \f(CW\*(C`lp_count\*(C'\fR register can
! hold the required loop\-counter value.  Depending on the width
! specified, the compiler and run\-time library might continue to use the
  loop mechanism for various needs.  This option defines macro
  \&\f(CW\*(C`_\|_ARC_LPC_WIDTH_\|_\*(C'\fR with the value of \fIwidth\fR.
! .IP \fB\-mrf16\fR 4
  .IX Item "-mrf16"
  This option instructs the compiler to generate code for a 16\-entry
  register file.  This option defines the \f(CW\*(C`_\|_ARC_RF16_\|_\*(C'\fR
  preprocessor macro.
! .IP \fB\-mbranch\-index\fR 4
  .IX Item "-mbranch-index"
  Enable use of \f(CW\*(C`bi\*(C'\fR or \f(CW\*(C`bih\*(C'\fR instructions to implement jump
  tables.
  .PP
  The following options are passed through to the assembler, and also
  define preprocessor macro symbols.
! .IP \fB\-mdsp\-packa\fR 4
  .IX Item "-mdsp-packa"
! Passed down to the assembler to enable the DSP Pack A extensions.
  Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdsp_packa\*(C'\fR.  This option is
  deprecated.
! .IP \fB\-mdvbf\fR 4
  .IX Item "-mdvbf"
  Passed down to the assembler to enable the dual Viterbi butterfly
  extension.  Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdvbf\*(C'\fR.  This
  option is deprecated.
! .IP \fB\-mlock\fR 4
  .IX Item "-mlock"
  Passed down to the assembler to enable the locked load/store
  conditional extension.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xlock\*(C'\fR.
! .IP \fB\-mmac\-d16\fR 4
  .IX Item "-mmac-d16"
  Passed down to the assembler.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xxmac_d16\*(C'\fR.  This option is deprecated.
! .IP \fB\-mmac\-24\fR 4
  .IX Item "-mmac-24"
  Passed down to the assembler.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xxmac_24\*(C'\fR.  This option is deprecated.
! .IP \fB\-mrtsc\fR 4
  .IX Item "-mrtsc"
! Passed down to the assembler to enable the 64\-bit time\-stamp counter
  extension instruction.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xrtsc\*(C'\fR.  This option is deprecated.
! .IP \fB\-mswape\fR 4
  .IX Item "-mswape"
  Passed down to the assembler to enable the swap byte ordering
  extension instruction.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xswape\*(C'\fR.
! .IP \fB\-mtelephony\fR 4
  .IX Item "-mtelephony"
! Passed down to the assembler to enable dual\- and single\-operand
  instructions for telephony.  Also sets the preprocessor symbol
  \&\f(CW\*(C`_\|_Xtelephony\*(C'\fR.  This option is deprecated.
! .IP \fB\-mxy\fR 4
  .IX Item "-mxy"
! Passed down to the assembler to enable the XY memory extension.  Also
  sets the preprocessor symbol \f(CW\*(C`_\|_Xxy\*(C'\fR.
  .PP
  The following options control how the assembly code is annotated:
! .IP \fB\-misize\fR 4
  .IX Item "-misize"
  Annotate assembler instructions with estimated addresses.
! .IP \fB\-mannotate\-align\fR 4
  .IX Item "-mannotate-align"
  Explain what alignment considerations lead to the decision to make an
  instruction short or long.
  .PP
  The following options are passed through to the linker:
! .IP \fB\-marclinux\fR 4
  .IX Item "-marclinux"
  Passed through to the linker, to specify use of the \f(CW\*(C`arclinux\*(C'\fR emulation.
  This option is enabled by default in tool chains built for
  \&\f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets
  when profiling is not requested.
! .IP \fB\-marclinux_prof\fR 4
  .IX Item "-marclinux_prof"
  Passed through to the linker, to specify use of the
  \&\f(CW\*(C`arclinux_prof\*(C'\fR emulation.  This option is enabled by default in
*************** tool chains built for \f(CW\*(C`arc\-lin
*** 20658,20727 ****
  \&\f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets when profiling is requested.
  .PP
  The following options control the semantics of generated code:
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  Generate calls as register indirect calls, thus providing access
  to the full 32\-bit address range.
! .IP "\fB\-mmedium\-calls\fR" 4
  .IX Item "-mmedium-calls"
! Don't use less than 25\-bit addressing range for calls, which is the
! offset available for an unconditional branch-and-link
  instruction.  Conditional execution of function calls is suppressed, to
  allow use of the 25\-bit range, rather than the 21\-bit range with
! conditional branch-and-link.  This is the default for tool chains built
  for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
! Put definitions of externally-visible data in a small data section if
  that data is no bigger than \fInum\fR bytes.  The default value of
! \&\fInum\fR is 4 for any \s-1ARC\s0 configuration, or 8 when we have double
  load/store operations.
! .IP "\fB\-mno\-sdata\fR" 4
  .IX Item "-mno-sdata"
  Do not generate sdata references.  This is the default for tool chains
  built for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR
  targets.
! .IP "\fB\-mvolatile\-cache\fR" 4
  .IX Item "-mvolatile-cache"
  Use ordinarily cached memory accesses for volatile references.  This is the
  default.
! .IP "\fB\-mno\-volatile\-cache\fR" 4
  .IX Item "-mno-volatile-cache"
  Enable cache bypass for volatile references.
  .PP
  The following options fine tune code generation:
! .IP "\fB\-malign\-call\fR" 4
  .IX Item "-malign-call"
  Does nothing.  Preserved for backward compatibility.
! .IP "\fB\-mauto\-modify\-reg\fR" 4
  .IX Item "-mauto-modify-reg"
  Enable the use of pre/post modify with register displacement.
! .IP "\fB\-mbbit\-peephole\fR" 4
  .IX Item "-mbbit-peephole"
  Enable bbit peephole2.
! .IP "\fB\-mno\-brcc\fR" 4
  .IX Item "-mno-brcc"
! This option disables a target-specific pass in \fIarc_reorg\fR to
! generate compare-and-branch (\f(CW\*(C`br\f(CIcc\f(CW\*(C'\fR) instructions.  
  It has no effect on
  generation of these instructions driven by the combiner pass.
! .IP "\fB\-mcase\-vector\-pcrel\fR" 4
  .IX Item "-mcase-vector-pcrel"
! Use PC-relative switch case tables to enable case table shortening.
  This is the default for \fB\-Os\fR.
! .IP "\fB\-mcompact\-casesi\fR" 4
  .IX Item "-mcompact-casesi"
  Enable compact \f(CW\*(C`casesi\*(C'\fR pattern.  This is the default for \fB\-Os\fR,
  and only available for ARCv1 cores.  This option is deprecated.
! .IP "\fB\-mno\-cond\-exec\fR" 4
  .IX Item "-mno-cond-exec"
! Disable the ARCompact-specific pass to generate conditional 
  execution instructions.
  .Sp
  Due to delay slot scheduling and interactions between operand numbers,
  literal sizes, instruction lengths, and the support for conditional execution,
! the target-independent pass to generate conditional execution is often lacking,
! so the \s-1ARC\s0 port has kept a special pass around that tries to find more
  conditional execution generation opportunities after register allocation,
  branch shortening, and delay slot scheduling have been done.  This pass
  generally, but not always, improves performance and code size, at the cost of
--- 20589,20658 ----
  \&\f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets when profiling is requested.
  .PP
  The following options control the semantics of generated code:
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  Generate calls as register indirect calls, thus providing access
  to the full 32\-bit address range.
! .IP \fB\-mmedium\-calls\fR 4
  .IX Item "-mmedium-calls"
! Don\*(Aqt use less than 25\-bit addressing range for calls, which is the
! offset available for an unconditional branch\-and\-link
  instruction.  Conditional execution of function calls is suppressed, to
  allow use of the 25\-bit range, rather than the 21\-bit range with
! conditional branch\-and\-link.  This is the default for tool chains built
  for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
! Put definitions of externally\-visible data in a small data section if
  that data is no bigger than \fInum\fR bytes.  The default value of
! \&\fInum\fR is 4 for any ARC configuration, or 8 when we have double
  load/store operations.
! .IP \fB\-mno\-sdata\fR 4
  .IX Item "-mno-sdata"
  Do not generate sdata references.  This is the default for tool chains
  built for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR
  targets.
! .IP \fB\-mvolatile\-cache\fR 4
  .IX Item "-mvolatile-cache"
  Use ordinarily cached memory accesses for volatile references.  This is the
  default.
! .IP \fB\-mno\-volatile\-cache\fR 4
  .IX Item "-mno-volatile-cache"
  Enable cache bypass for volatile references.
  .PP
  The following options fine tune code generation:
! .IP \fB\-malign\-call\fR 4
  .IX Item "-malign-call"
  Does nothing.  Preserved for backward compatibility.
! .IP \fB\-mauto\-modify\-reg\fR 4
  .IX Item "-mauto-modify-reg"
  Enable the use of pre/post modify with register displacement.
! .IP \fB\-mbbit\-peephole\fR 4
  .IX Item "-mbbit-peephole"
  Enable bbit peephole2.
! .IP \fB\-mno\-brcc\fR 4
  .IX Item "-mno-brcc"
! This option disables a target\-specific pass in \fIarc_reorg\fR to
! generate compare\-and\-branch (\f(CW\*(C`br\fR\f(CIcc\fR\f(CW\*(C'\fR) instructions.  
  It has no effect on
  generation of these instructions driven by the combiner pass.
! .IP \fB\-mcase\-vector\-pcrel\fR 4
  .IX Item "-mcase-vector-pcrel"
! Use PC\-relative switch case tables to enable case table shortening.
  This is the default for \fB\-Os\fR.
! .IP \fB\-mcompact\-casesi\fR 4
  .IX Item "-mcompact-casesi"
  Enable compact \f(CW\*(C`casesi\*(C'\fR pattern.  This is the default for \fB\-Os\fR,
  and only available for ARCv1 cores.  This option is deprecated.
! .IP \fB\-mno\-cond\-exec\fR 4
  .IX Item "-mno-cond-exec"
! Disable the ARCompact\-specific pass to generate conditional 
  execution instructions.
  .Sp
  Due to delay slot scheduling and interactions between operand numbers,
  literal sizes, instruction lengths, and the support for conditional execution,
! the target\-independent pass to generate conditional execution is often lacking,
! so the ARC port has kept a special pass around that tries to find more
  conditional execution generation opportunities after register allocation,
  branch shortening, and delay slot scheduling have been done.  This pass
  generally, but not always, improves performance and code size, at the cost of
*************** extra compilation time, which is why the
*** 20729,20761 ****
  If you have a problem with call instructions exceeding their allowable
  offset range because they are conditionalized, you should consider using
  \&\fB\-mmedium\-calls\fR instead.
! .IP "\fB\-mearly\-cbranchsi\fR" 4
  .IX Item "-mearly-cbranchsi"
! Enable pre-reload use of the \f(CW\*(C`cbranchsi\*(C'\fR pattern.
! .IP "\fB\-mexpand\-adddi\fR" 4
  .IX Item "-mexpand-adddi"
! Expand \f(CW\*(C`adddi3\*(C'\fR and \f(CW\*(C`subdi3\*(C'\fR at \s-1RTL\s0 generation time into
  \&\f(CW\*(C`add.f\*(C'\fR, \f(CW\*(C`adc\*(C'\fR etc.  This option is deprecated.
! .IP "\fB\-mindexed\-loads\fR" 4
  .IX Item "-mindexed-loads"
  Enable the use of indexed loads.  This can be problematic because some
  optimizers then assume that indexed stores exist, which is not
  the case.
! .IP "\fB\-mlra\fR" 4
  .IX Item "-mlra"
! Enable Local Register Allocation.  This is still experimental for \s-1ARC,\s0
  so by default the compiler uses standard reload
  (i.e. \fB\-mno\-lra\fR).
! .IP "\fB\-mlra\-priority\-none\fR" 4
  .IX Item "-mlra-priority-none"
! Don't indicate any priority for target registers.
! .IP "\fB\-mlra\-priority\-compact\fR" 4
  .IX Item "-mlra-priority-compact"
  Indicate target register priority for r0..r3 / r12..r15.
! .IP "\fB\-mlra\-priority\-noncompact\fR" 4
  .IX Item "-mlra-priority-noncompact"
  Reduce target register priority for r0..r3 / r12..r15.
! .IP "\fB\-mmillicode\fR" 4
  .IX Item "-mmillicode"
  When optimizing for size (using \fB\-Os\fR), prologues and epilogues
  that have to save or restore a large number of registers are often
--- 20660,20692 ----
  If you have a problem with call instructions exceeding their allowable
  offset range because they are conditionalized, you should consider using
  \&\fB\-mmedium\-calls\fR instead.
! .IP \fB\-mearly\-cbranchsi\fR 4
  .IX Item "-mearly-cbranchsi"
! Enable pre\-reload use of the \f(CW\*(C`cbranchsi\*(C'\fR pattern.
! .IP \fB\-mexpand\-adddi\fR 4
  .IX Item "-mexpand-adddi"
! Expand \f(CW\*(C`adddi3\*(C'\fR and \f(CW\*(C`subdi3\*(C'\fR at RTL generation time into
  \&\f(CW\*(C`add.f\*(C'\fR, \f(CW\*(C`adc\*(C'\fR etc.  This option is deprecated.
! .IP \fB\-mindexed\-loads\fR 4
  .IX Item "-mindexed-loads"
  Enable the use of indexed loads.  This can be problematic because some
  optimizers then assume that indexed stores exist, which is not
  the case.
! .IP \fB\-mlra\fR 4
  .IX Item "-mlra"
! Enable Local Register Allocation.  This is still experimental for ARC,
  so by default the compiler uses standard reload
  (i.e. \fB\-mno\-lra\fR).
! .IP \fB\-mlra\-priority\-none\fR 4
  .IX Item "-mlra-priority-none"
! Don\*(Aqt indicate any priority for target registers.
! .IP \fB\-mlra\-priority\-compact\fR 4
  .IX Item "-mlra-priority-compact"
  Indicate target register priority for r0..r3 / r12..r15.
! .IP \fB\-mlra\-priority\-noncompact\fR 4
  .IX Item "-mlra-priority-noncompact"
  Reduce target register priority for r0..r3 / r12..r15.
! .IP \fB\-mmillicode\fR 4
  .IX Item "-mmillicode"
  When optimizing for size (using \fB\-Os\fR), prologues and epilogues
  that have to save or restore a large number of registers are often
*************** referred to as a \fImillicode\fR call.
*** 20764,20802 ****
  performance issues, and/or cause linking issues when linking in a
  nonstandard way, this option is provided to turn on or off millicode
  call generation.
! .IP "\fB\-mcode\-density\-frame\fR" 4
  .IX Item "-mcode-density-frame"
  This option enable the compiler to emit \f(CW\*(C`enter\*(C'\fR and \f(CW\*(C`leave\*(C'\fR
  instructions.  These instructions are only valid for CPUs with
! code-density feature.
! .IP "\fB\-mmixed\-code\fR" 4
  .IX Item "-mmixed-code"
  Does nothing.  Preserved for backward compatibility.
! .IP "\fB\-mq\-class\fR" 4
  .IX Item "-mq-class"
  Ths option is deprecated.  Enable \fBq\fR instruction alternatives.
  This is the default for \fB\-Os\fR.
! .IP "\fB\-mRcq\fR" 4
  .IX Item "-mRcq"
  Does nothing.  Preserved for backward compatibility.
! .IP "\fB\-mRcw\fR" 4
  .IX Item "-mRcw"
  Does nothing.  Preserved for backward compatibility.
! .IP "\fB\-msize\-level=\fR\fIlevel\fR" 4
  .IX Item "-msize-level=level"
! Fine-tune size optimization with regards to instruction lengths and alignment.
  The recognized values for \fIlevel\fR are:
  .RS 4
! .IP "\fB0\fR" 4
  .IX Item "0"
  No size optimization.  This level is deprecated and treated like \fB1\fR.
! .IP "\fB1\fR" 4
  .IX Item "1"
  Short instructions are used opportunistically.
! .IP "\fB2\fR" 4
  .IX Item "2"
  In addition, alignment of loops and of code after barriers are dropped.
! .IP "\fB3\fR" 4
  .IX Item "3"
  In addition, optional data alignment is dropped, and the option \fBOs\fR is enabled.
  .RE
--- 20695,20733 ----
  performance issues, and/or cause linking issues when linking in a
  nonstandard way, this option is provided to turn on or off millicode
  call generation.
! .IP \fB\-mcode\-density\-frame\fR 4
  .IX Item "-mcode-density-frame"
  This option enable the compiler to emit \f(CW\*(C`enter\*(C'\fR and \f(CW\*(C`leave\*(C'\fR
  instructions.  These instructions are only valid for CPUs with
! code\-density feature.
! .IP \fB\-mmixed\-code\fR 4
  .IX Item "-mmixed-code"
  Does nothing.  Preserved for backward compatibility.
! .IP \fB\-mq\-class\fR 4
  .IX Item "-mq-class"
  Ths option is deprecated.  Enable \fBq\fR instruction alternatives.
  This is the default for \fB\-Os\fR.
! .IP \fB\-mRcq\fR 4
  .IX Item "-mRcq"
  Does nothing.  Preserved for backward compatibility.
! .IP \fB\-mRcw\fR 4
  .IX Item "-mRcw"
  Does nothing.  Preserved for backward compatibility.
! .IP \fB\-msize\-level=\fR\fIlevel\fR 4
  .IX Item "-msize-level=level"
! Fine\-tune size optimization with regards to instruction lengths and alignment.
  The recognized values for \fIlevel\fR are:
  .RS 4
! .IP \fB0\fR 4
  .IX Item "0"
  No size optimization.  This level is deprecated and treated like \fB1\fR.
! .IP \fB1\fR 4
  .IX Item "1"
  Short instructions are used opportunistically.
! .IP \fB2\fR 4
  .IX Item "2"
  In addition, alignment of loops and of code after barriers are dropped.
! .IP \fB3\fR 4
  .IX Item "3"
  In addition, optional data alignment is dropped, and the option \fBOs\fR is enabled.
  .RE
*************** In addition, optional data alignment is
*** 20805,20993 ****
  This defaults to \fB3\fR when \fB\-Os\fR is in effect.  Otherwise,
  the behavior when this is not set is equivalent to level \fB1\fR.
  .RE
! .IP "\fB\-mtune=\fR\fIcpu\fR" 4
  .IX Item "-mtune=cpu"
  Set instruction scheduling parameters for \fIcpu\fR, overriding any implied
  by \fB\-mcpu=\fR.
  .Sp
  Supported values for \fIcpu\fR are
  .RS 4
! .IP "\fB\s-1ARC600\s0\fR" 4
  .IX Item "ARC600"
! Tune for \s-1ARC600 CPU.\s0
! .IP "\fB\s-1ARC601\s0\fR" 4
  .IX Item "ARC601"
! Tune for \s-1ARC601 CPU.\s0
! .IP "\fB\s-1ARC700\s0\fR" 4
  .IX Item "ARC700"
! Tune for \s-1ARC700 CPU\s0 with standard multiplier block.
! .IP "\fBARC700\-xmac\fR" 4
  .IX Item "ARC700-xmac"
! Tune for \s-1ARC700 CPU\s0 with \s-1XMAC\s0 block.
! .IP "\fB\s-1ARC725D\s0\fR" 4
  .IX Item "ARC725D"
! Tune for \s-1ARC725D CPU.\s0
! .IP "\fB\s-1ARC750D\s0\fR" 4
  .IX Item "ARC750D"
! Tune for \s-1ARC750D CPU.\s0
! .IP "\fBcore3\fR" 4
  .IX Item "core3"
! Tune for ARCv2 core3 type \s-1CPU.\s0  This option enable usage of
  \&\f(CW\*(C`dbnz\*(C'\fR instruction.
! .IP "\fBrelease31a\fR" 4
  .IX Item "release31a"
  Tune for ARC4x release 3.10a.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mmultcost=\fR\fInum\fR" 4
  .IX Item "-mmultcost=num"
  Cost to assume for a multiply instruction, with \fB4\fR being equal to a
  normal instruction.
! .IP "\fB\-munalign\-prob\-threshold=\fR\fIprobability\fR" 4
  .IX Item "-munalign-prob-threshold=probability"
  Does nothing.  Preserved for backward compatibility.
  .PP
  The following options are maintained for backward compatibility, but
  are now deprecated and will be removed in a future release:
! .IP "\fB\-margonaut\fR" 4
  .IX Item "-margonaut"
! Obsolete \s-1FPX.\s0
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
  .PD 0
! .IP "\fB\-EB\fR" 4
  .IX Item "-EB"
  .PD
! Compile code for big-endian targets.  Use of these options is now
! deprecated.  Big-endian code is supported by configuring \s-1GCC\s0 to build
  \&\f(CW\*(C`arceb\-elf32\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets,
  for which big endian is the default.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
  .PD 0
! .IP "\fB\-EL\fR" 4
  .IX Item "-EL"
  .PD
! Compile code for little-endian targets.  Use of these options is now
! deprecated.  Little-endian code is supported by configuring \s-1GCC\s0 to build 
  \&\f(CW\*(C`arc\-elf32\*(C'\fR and \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR targets,
  for which little endian is the default.
! .IP "\fB\-mbarrel_shifter\fR" 4
  .IX Item "-mbarrel_shifter"
  Replaced by \fB\-mbarrel\-shifter\fR.
! .IP "\fB\-mdpfp_compact\fR" 4
  .IX Item "-mdpfp_compact"
  Replaced by \fB\-mdpfp\-compact\fR.
! .IP "\fB\-mdpfp_fast\fR" 4
  .IX Item "-mdpfp_fast"
  Replaced by \fB\-mdpfp\-fast\fR.
! .IP "\fB\-mdsp_packa\fR" 4
  .IX Item "-mdsp_packa"
  Replaced by \fB\-mdsp\-packa\fR.
! .IP "\fB\-mEA\fR" 4
  .IX Item "-mEA"
  Replaced by \fB\-mea\fR.
! .IP "\fB\-mmac_24\fR" 4
  .IX Item "-mmac_24"
  Replaced by \fB\-mmac\-24\fR.
! .IP "\fB\-mmac_d16\fR" 4
  .IX Item "-mmac_d16"
  Replaced by \fB\-mmac\-d16\fR.
! .IP "\fB\-mspfp_compact\fR" 4
  .IX Item "-mspfp_compact"
  Replaced by \fB\-mspfp\-compact\fR.
! .IP "\fB\-mspfp_fast\fR" 4
  .IX Item "-mspfp_fast"
  Replaced by \fB\-mspfp\-fast\fR.
! .IP "\fB\-mtune=\fR\fIcpu\fR" 4
  .IX Item "-mtune=cpu"
  Values \fBarc600\fR, \fBarc601\fR, \fBarc700\fR and
! \&\fBarc700\-xmac\fR for \fIcpu\fR are replaced by \fB\s-1ARC600\s0\fR,
! \&\fB\s-1ARC601\s0\fR, \fB\s-1ARC700\s0\fR and \fBARC700\-xmac\fR respectively.
! .IP "\fB\-multcost=\fR\fInum\fR" 4
  .IX Item "-multcost=num"
  Replaced by \fB\-mmultcost\fR.
  .PP
! \fI\s-1ARM\s0 Options\fR
  .IX Subsection "ARM Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1ARM\s0 port:
! .IP "\fB\-mabi=\fR\fIname\fR" 4
  .IX Item "-mabi=name"
! Generate code for the specified \s-1ABI.\s0  Permissible values are: \fBapcs-gnu\fR,
! \&\fBatpcs\fR, \fBaapcs\fR, \fBaapcs-linux\fR and \fBiwmmxt\fR.
! .IP "\fB\-mapcs\-frame\fR" 4
  .IX Item "-mapcs-frame"
! Generate a stack frame that is compliant with the \s-1ARM\s0 Procedure Call
  Standard for all functions, even if this is not strictly necessary for
  correct execution of the code.  Specifying \fB\-fomit\-frame\-pointer\fR
  with this option causes the stack frames not to be generated for
  leaf functions.  The default is \fB\-mno\-apcs\-frame\fR.
  This option is deprecated.
! .IP "\fB\-mapcs\fR" 4
  .IX Item "-mapcs"
  This is a synonym for \fB\-mapcs\-frame\fR and is deprecated.
! .IP "\fB\-mthumb\-interwork\fR" 4
  .IX Item "-mthumb-interwork"
! Generate code that supports calling between the \s-1ARM\s0 and Thumb
  instruction sets.  Without this option, on pre\-v5 architectures, the
  two instruction sets cannot be reliably used inside one program.  The
  default is \fB\-mno\-thumb\-interwork\fR, since slightly larger code
! is generated when \fB\-mthumb\-interwork\fR is specified.  In \s-1AAPCS\s0
  configurations this option is meaningless.
! .IP "\fB\-mno\-sched\-prolog\fR" 4
  .IX Item "-mno-sched-prolog"
  Prevent the reordering of instructions in the function prologue, or the
! merging of those instruction with the instructions in the function's
  body.  This means that all functions start with a recognizable set
  of instructions (or in fact one of a choice from a small set of
  different function prologues), and this information can be used to
  locate the start of functions inside an executable piece of code.  The
  default is \fB\-msched\-prolog\fR.
! .IP "\fB\-mfloat\-abi=\fR\fIname\fR" 4
  .IX Item "-mfloat-abi=name"
! Specifies which floating-point \s-1ABI\s0 to use.  Permissible values
  are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
  .Sp
! Specifying \fBsoft\fR causes \s-1GCC\s0 to generate output containing
! library calls for floating-point operations.
! \&\fBsoftfp\fR allows the generation of code using hardware floating-point
! instructions, but still uses the soft-float calling conventions.
! \&\fBhard\fR allows generation of floating-point instructions
! and uses FPU-specific calling conventions.
  .Sp
  The default depends on the specific target configuration.  Note that
! the hard-float and soft-float ABIs are not link-compatible; you must
! compile your entire program with the same \s-1ABI,\s0 and link with a
  compatible set of libraries.
! .IP "\fB\-mgeneral\-regs\-only\fR" 4
  .IX Item "-mgeneral-regs-only"
! Generate code which uses only the general-purpose registers.  This will prevent
! the compiler from using floating-point and Advanced \s-1SIMD\s0 registers but will not
  impose any restrictions on the assembler.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code for a processor running in little-endian mode.  This is
  the default for all standard configurations.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code for a processor running in big-endian mode; the default is
! to compile code for a little-endian processor.
! .IP "\fB\-mbe8\fR" 4
  .IX Item "-mbe8"
  .PD 0
! .IP "\fB\-mbe32\fR" 4
  .IX Item "-mbe32"
  .PD
! When linking a big-endian image select between \s-1BE8\s0 and \s-1BE32\s0 formats.
! The option has no effect for little-endian images and is ignored.  The
  default is dependent on the selected target architecture.  For ARMv6
! and later architectures the default is \s-1BE8,\s0 for older architectures
! the default is \s-1BE32.\s0  \s-1BE32\s0 format has been deprecated by \s-1ARM.\s0
! .IP "\fB\-march=\fR\fIname\fR[\fB+extension...\fR]" 4
  .IX Item "-march=name[+extension...]"
! This specifies the name of the target \s-1ARM\s0 architecture.  \s-1GCC\s0 uses this
  name to determine what kind of instructions it can emit when generating
  assembly code.  This option can be used in conjunction with or instead
  of the \fB\-mcpu=\fR option.
--- 20736,20924 ----
  This defaults to \fB3\fR when \fB\-Os\fR is in effect.  Otherwise,
  the behavior when this is not set is equivalent to level \fB1\fR.
  .RE
! .IP \fB\-mtune=\fR\fIcpu\fR 4
  .IX Item "-mtune=cpu"
  Set instruction scheduling parameters for \fIcpu\fR, overriding any implied
  by \fB\-mcpu=\fR.
  .Sp
  Supported values for \fIcpu\fR are
  .RS 4
! .IP \fBARC600\fR 4
  .IX Item "ARC600"
! Tune for ARC600 CPU.
! .IP \fBARC601\fR 4
  .IX Item "ARC601"
! Tune for ARC601 CPU.
! .IP \fBARC700\fR 4
  .IX Item "ARC700"
! Tune for ARC700 CPU with standard multiplier block.
! .IP \fBARC700\-xmac\fR 4
  .IX Item "ARC700-xmac"
! Tune for ARC700 CPU with XMAC block.
! .IP \fBARC725D\fR 4
  .IX Item "ARC725D"
! Tune for ARC725D CPU.
! .IP \fBARC750D\fR 4
  .IX Item "ARC750D"
! Tune for ARC750D CPU.
! .IP \fBcore3\fR 4
  .IX Item "core3"
! Tune for ARCv2 core3 type CPU.  This option enable usage of
  \&\f(CW\*(C`dbnz\*(C'\fR instruction.
! .IP \fBrelease31a\fR 4
  .IX Item "release31a"
  Tune for ARC4x release 3.10a.
  .RE
  .RS 4
  .RE
! .IP \fB\-mmultcost=\fR\fInum\fR 4
  .IX Item "-mmultcost=num"
  Cost to assume for a multiply instruction, with \fB4\fR being equal to a
  normal instruction.
! .IP \fB\-munalign\-prob\-threshold=\fR\fIprobability\fR 4
  .IX Item "-munalign-prob-threshold=probability"
  Does nothing.  Preserved for backward compatibility.
  .PP
  The following options are maintained for backward compatibility, but
  are now deprecated and will be removed in a future release:
! .IP \fB\-margonaut\fR 4
  .IX Item "-margonaut"
! Obsolete FPX.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
  .PD 0
! .IP \fB\-EB\fR 4
  .IX Item "-EB"
  .PD
! Compile code for big\-endian targets.  Use of these options is now
! deprecated.  Big\-endian code is supported by configuring GCC to build
  \&\f(CW\*(C`arceb\-elf32\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets,
  for which big endian is the default.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
  .PD 0
! .IP \fB\-EL\fR 4
  .IX Item "-EL"
  .PD
! Compile code for little\-endian targets.  Use of these options is now
! deprecated.  Little\-endian code is supported by configuring GCC to build 
  \&\f(CW\*(C`arc\-elf32\*(C'\fR and \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR targets,
  for which little endian is the default.
! .IP \fB\-mbarrel_shifter\fR 4
  .IX Item "-mbarrel_shifter"
  Replaced by \fB\-mbarrel\-shifter\fR.
! .IP \fB\-mdpfp_compact\fR 4
  .IX Item "-mdpfp_compact"
  Replaced by \fB\-mdpfp\-compact\fR.
! .IP \fB\-mdpfp_fast\fR 4
  .IX Item "-mdpfp_fast"
  Replaced by \fB\-mdpfp\-fast\fR.
! .IP \fB\-mdsp_packa\fR 4
  .IX Item "-mdsp_packa"
  Replaced by \fB\-mdsp\-packa\fR.
! .IP \fB\-mEA\fR 4
  .IX Item "-mEA"
  Replaced by \fB\-mea\fR.
! .IP \fB\-mmac_24\fR 4
  .IX Item "-mmac_24"
  Replaced by \fB\-mmac\-24\fR.
! .IP \fB\-mmac_d16\fR 4
  .IX Item "-mmac_d16"
  Replaced by \fB\-mmac\-d16\fR.
! .IP \fB\-mspfp_compact\fR 4
  .IX Item "-mspfp_compact"
  Replaced by \fB\-mspfp\-compact\fR.
! .IP \fB\-mspfp_fast\fR 4
  .IX Item "-mspfp_fast"
  Replaced by \fB\-mspfp\-fast\fR.
! .IP \fB\-mtune=\fR\fIcpu\fR 4
  .IX Item "-mtune=cpu"
  Values \fBarc600\fR, \fBarc601\fR, \fBarc700\fR and
! \&\fBarc700\-xmac\fR for \fIcpu\fR are replaced by \fBARC600\fR,
! \&\fBARC601\fR, \fBARC700\fR and \fBARC700\-xmac\fR respectively.
! .IP \fB\-multcost=\fR\fInum\fR 4
  .IX Item "-multcost=num"
  Replaced by \fB\-mmultcost\fR.
  .PP
! \fIARM Options\fR
  .IX Subsection "ARM Options"
  .PP
! These \fB\-m\fR options are defined for the ARM port:
! .IP \fB\-mabi=\fR\fIname\fR 4
  .IX Item "-mabi=name"
! Generate code for the specified ABI.  Permissible values are: \fBapcs\-gnu\fR,
! \&\fBatpcs\fR, \fBaapcs\fR, \fBaapcs\-linux\fR and \fBiwmmxt\fR.
! .IP \fB\-mapcs\-frame\fR 4
  .IX Item "-mapcs-frame"
! Generate a stack frame that is compliant with the ARM Procedure Call
  Standard for all functions, even if this is not strictly necessary for
  correct execution of the code.  Specifying \fB\-fomit\-frame\-pointer\fR
  with this option causes the stack frames not to be generated for
  leaf functions.  The default is \fB\-mno\-apcs\-frame\fR.
  This option is deprecated.
! .IP \fB\-mapcs\fR 4
  .IX Item "-mapcs"
  This is a synonym for \fB\-mapcs\-frame\fR and is deprecated.
! .IP \fB\-mthumb\-interwork\fR 4
  .IX Item "-mthumb-interwork"
! Generate code that supports calling between the ARM and Thumb
  instruction sets.  Without this option, on pre\-v5 architectures, the
  two instruction sets cannot be reliably used inside one program.  The
  default is \fB\-mno\-thumb\-interwork\fR, since slightly larger code
! is generated when \fB\-mthumb\-interwork\fR is specified.  In AAPCS
  configurations this option is meaningless.
! .IP \fB\-mno\-sched\-prolog\fR 4
  .IX Item "-mno-sched-prolog"
  Prevent the reordering of instructions in the function prologue, or the
! merging of those instruction with the instructions in the function\*(Aqs
  body.  This means that all functions start with a recognizable set
  of instructions (or in fact one of a choice from a small set of
  different function prologues), and this information can be used to
  locate the start of functions inside an executable piece of code.  The
  default is \fB\-msched\-prolog\fR.
! .IP \fB\-mfloat\-abi=\fR\fIname\fR 4
  .IX Item "-mfloat-abi=name"
! Specifies which floating\-point ABI to use.  Permissible values
  are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
  .Sp
! Specifying \fBsoft\fR causes GCC to generate output containing
! library calls for floating\-point operations.
! \&\fBsoftfp\fR allows the generation of code using hardware floating\-point
! instructions, but still uses the soft\-float calling conventions.
! \&\fBhard\fR allows generation of floating\-point instructions
! and uses FPU\-specific calling conventions.
  .Sp
  The default depends on the specific target configuration.  Note that
! the hard\-float and soft\-float ABIs are not link\-compatible; you must
! compile your entire program with the same ABI, and link with a
  compatible set of libraries.
! .IP \fB\-mgeneral\-regs\-only\fR 4
  .IX Item "-mgeneral-regs-only"
! Generate code which uses only the general\-purpose registers.  This will prevent
! the compiler from using floating\-point and Advanced SIMD registers but will not
  impose any restrictions on the assembler.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code for a processor running in little\-endian mode.  This is
  the default for all standard configurations.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code for a processor running in big\-endian mode; the default is
! to compile code for a little\-endian processor.
! .IP \fB\-mbe8\fR 4
  .IX Item "-mbe8"
  .PD 0
! .IP \fB\-mbe32\fR 4
  .IX Item "-mbe32"
  .PD
! When linking a big\-endian image select between BE8 and BE32 formats.
! The option has no effect for little\-endian images and is ignored.  The
  default is dependent on the selected target architecture.  For ARMv6
! and later architectures the default is BE8, for older architectures
! the default is BE32.  BE32 format has been deprecated by ARM.
! .IP \fB\-march=\fR\fIname\fR[\fB+extension...\fR] 4
  .IX Item "-march=name[+extension...]"
! 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 \fB\-mcpu=\fR option.
*************** Most extension names are generically nam
*** 21034,21574 ****
  dependent upon the architecture to which it is applied.  For example,
  the \fB+simd\fR option can be applied to both \fBarmv7\-a\fR and
  \&\fBarmv8\-a\fR architectures, but will enable the original ARMv7\-A
! Advanced \s-1SIMD\s0 (Neon) extensions for \fBarmv7\-a\fR and the ARMv8\-A
  variant for \fBarmv8\-a\fR.
  .Sp
  The table below lists the supported extensions for each architecture.
  Architectures not mentioned do not support any extensions.
  .RS 4
! .IP "\fBarmv5te\fR" 4
  .IX Item "armv5te"
  .PD 0
! .IP "\fBarmv6\fR" 4
  .IX Item "armv6"
! .IP "\fBarmv6j\fR" 4
  .IX Item "armv6j"
! .IP "\fBarmv6k\fR" 4
  .IX Item "armv6k"
! .IP "\fBarmv6kz\fR" 4
  .IX Item "armv6kz"
! .IP "\fBarmv6t2\fR" 4
  .IX Item "armv6t2"
! .IP "\fBarmv6z\fR" 4
  .IX Item "armv6z"
! .IP "\fBarmv6zk\fR" 4
  .IX Item "armv6zk"
  .RS 4
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
  .PD
! The VFPv2 floating-point instructions.  The extension \fB+vfpv2\fR can be
  used as an alias for this extension.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv7\fR" 4
  .IX Item "armv7"
  The common subset of the ARMv7\-A, ARMv7\-R and ARMv7\-M architectures.
  .RS 4
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The VFPv3 floating-point instructions, with 16 double-precision
  registers.  The extension \fB+vfpv3\-d16\fR can be used as an alias
! for this extension.  Note that floating-point is not supported by the
  base ARMv7\-M architecture, but is compatible with both the ARMv7\-A and
  ARMv7\-R architectures.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv7\-a\fR" 4
  .IX Item "armv7-a"
  .RS 4
  .PD 0
! .IP "\fB+mp\fR" 4
  .IX Item "+mp"
  .PD
  The multiprocessing extension.
! .IP "\fB+sec\fR" 4
  .IX Item "+sec"
  The security extension.
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The VFPv3 floating-point instructions, with 16 double-precision
  registers.  The extension \fB+vfpv3\-d16\fR can be used as an alias
  for this extension.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The Advanced \s-1SIMD\s0 (Neon) v1 and the VFPv3 floating-point instructions.
  The extensions \fB+neon\fR and \fB+neon\-vfpv3\fR can be used as aliases
  for this extension.
! .IP "\fB+vfpv3\fR" 4
  .IX Item "+vfpv3"
! The VFPv3 floating-point instructions, with 32 double-precision
  registers.
! .IP "\fB+vfpv3\-d16\-fp16\fR" 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating-point instructions, with 16 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+vfpv3\-fp16\fR" 4
  .IX Item "+vfpv3-fp16"
! The VFPv3 floating-point instructions, with 32 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+vfpv4\-d16\fR" 4
  .IX Item "+vfpv4-d16"
! The VFPv4 floating-point instructions, with 16 double-precision
  registers.
! .IP "\fB+vfpv4\fR" 4
  .IX Item "+vfpv4"
! The VFPv4 floating-point instructions, with 32 double-precision
  registers.
! .IP "\fB+neon\-fp16\fR" 4
  .IX Item "+neon-fp16"
! The Advanced \s-1SIMD\s0 (Neon) v1 and the VFPv3 floating-point instructions, with
! the half-precision floating-point conversion operations.
! .IP "\fB+neon\-vfpv4\fR" 4
  .IX Item "+neon-vfpv4"
! The Advanced \s-1SIMD\s0 (Neon) v2 and the VFPv4 floating-point instructions.
! .IP "\fB+nosimd\fR" 4
  .IX Item "+nosimd"
! Disable the Advanced \s-1SIMD\s0 instructions (does not disable floating point).
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point and Advanced \s-1SIMD\s0 instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv7ve\fR" 4
  .IX Item "armv7ve"
  The extended version of the ARMv7\-A architecture with support for
  virtualization.
  .RS 4
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The VFPv4 floating-point instructions, with 16 double-precision registers.
  The extension \fB+vfpv4\-d16\fR can be used as an alias for this extension.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The Advanced \s-1SIMD\s0 (Neon) v2 and the VFPv4 floating-point instructions.  The
  extension \fB+neon\-vfpv4\fR can be used as an alias for this extension.
! .IP "\fB+vfpv3\-d16\fR" 4
  .IX Item "+vfpv3-d16"
! The VFPv3 floating-point instructions, with 16 double-precision
  registers.
! .IP "\fB+vfpv3\fR" 4
  .IX Item "+vfpv3"
! The VFPv3 floating-point instructions, with 32 double-precision
  registers.
! .IP "\fB+vfpv3\-d16\-fp16\fR" 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating-point instructions, with 16 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+vfpv3\-fp16\fR" 4
  .IX Item "+vfpv3-fp16"
! The VFPv3 floating-point instructions, with 32 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+vfpv4\-d16\fR" 4
  .IX Item "+vfpv4-d16"
! The VFPv4 floating-point instructions, with 16 double-precision
  registers.
! .IP "\fB+vfpv4\fR" 4
  .IX Item "+vfpv4"
! The VFPv4 floating-point instructions, with 32 double-precision
  registers.
! .IP "\fB+neon\fR" 4
  .IX Item "+neon"
! The Advanced \s-1SIMD\s0 (Neon) v1 and the VFPv3 floating-point instructions.
  The extension \fB+neon\-vfpv3\fR can be used as an alias for this extension.
! .IP "\fB+neon\-fp16\fR" 4
  .IX Item "+neon-fp16"
! The Advanced \s-1SIMD\s0 (Neon) v1 and the VFPv3 floating-point instructions, with
! the half-precision floating-point conversion operations.
! .IP "\fB+nosimd\fR" 4
  .IX Item "+nosimd"
! Disable the Advanced \s-1SIMD\s0 instructions (does not disable floating point).
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point and Advanced \s-1SIMD\s0 instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8\-a\fR" 4
  .IX Item "armv8-a"
  .RS 4
  .PD 0
! .IP "\fB+crc\fR" 4
  .IX Item "+crc"
  .PD
! The Cyclic Redundancy Check (\s-1CRC\s0) instructions.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8\-A Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
  The cryptographic instructions.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+sb\fR" 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP "\fB+predres\fR" 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.1\-a\fR" 4
  .IX Item "armv8.1-a"
  .RS 4
  .PD 0
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
  .PD
! The ARMv8.1\-A Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced \s-1SIMD\s0 and
! floating-point instructions.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+sb\fR" 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP "\fB+predres\fR" 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.2\-a\fR" 4
  .IX Item "armv8.2-a"
  .PD 0
! .IP "\fBarmv8.3\-a\fR" 4
  .IX Item "armv8.3-a"
  .RS 4
! .IP "\fB+fp16\fR" 4
  .IX Item "+fp16"
  .PD
! The half-precision floating-point data processing instructions.
! This also enables the Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+fp16fml\fR" 4
  .IX Item "+fp16fml"
! The half-precision floating-point fmla extension.  This also enables
! the half-precision floating-point extension and Advanced \s-1SIMD\s0 and
! floating-point instructions.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8.1\-A Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced \s-1SIMD\s0 and
! floating-point instructions.
! .IP "\fB+dotprod\fR" 4
  .IX Item "+dotprod"
! Enable the Dot Product extension.  This also enables Advanced \s-1SIMD\s0 instructions.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+sb\fR" 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP "\fB+predres\fR" 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
! .IP "\fB+i8mm\fR" 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+bf16\fR" 4
  .IX Item "+bf16"
! Brain half-precision floating-point instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.4\-a\fR" 4
  .IX Item "armv8.4-a"
  .RS 4
  .PD 0
! .IP "\fB+fp16\fR" 4
  .IX Item "+fp16"
  .PD
! The half-precision floating-point data processing instructions.
! This also enables the Advanced \s-1SIMD\s0 and floating-point instructions as well
! as the Dot Product extension and the half-precision floating-point fmla
  extension.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced \s-1SIMD\s0 and floating-point instructions as well as the
  Dot Product extension.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced \s-1SIMD\s0 and
! floating-point instructions as well as the Dot Product extension.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+sb\fR" 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP "\fB+predres\fR" 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
! .IP "\fB+i8mm\fR" 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+bf16\fR" 4
  .IX Item "+bf16"
! Brain half-precision floating-point instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.5\-a\fR" 4
  .IX Item "armv8.5-a"
  .RS 4
  .PD 0
! .IP "\fB+fp16\fR" 4
  .IX Item "+fp16"
  .PD
! The half-precision floating-point data processing instructions.
! This also enables the Advanced \s-1SIMD\s0 and floating-point instructions as well
! as the Dot Product extension and the half-precision floating-point fmla
  extension.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced \s-1SIMD\s0 and floating-point instructions as well as the
  Dot Product extension.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced \s-1SIMD\s0 and
! floating-point instructions as well as the Dot Product extension.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+i8mm\fR" 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+bf16\fR" 4
  .IX Item "+bf16"
! Brain half-precision floating-point instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.6\-a\fR" 4
  .IX Item "armv8.6-a"
  .RS 4
  .PD 0
! .IP "\fB+fp16\fR" 4
  .IX Item "+fp16"
  .PD
! The half-precision floating-point data processing instructions.
! This also enables the Advanced \s-1SIMD\s0 and floating-point instructions as well
! as the Dot Product extension and the half-precision floating-point fmla
  extension.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced \s-1SIMD\s0 and floating-point instructions as well as the
  Dot Product extension.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced \s-1SIMD\s0 and
! floating-point instructions as well as the Dot Product extension.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
! .IP "\fB+i8mm\fR" 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+bf16\fR" 4
  .IX Item "+bf16"
! Brain half-precision floating-point instructions.
! This also enables Advanced \s-1SIMD\s0 and floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv7\-r\fR" 4
  .IX Item "armv7-r"
  .RS 4
  .PD 0
! .IP "\fB+fp.sp\fR" 4
  .IX Item "+fp.sp"
  .PD
! The single-precision VFPv3 floating-point instructions.  The extension
  \&\fB+vfpv3xd\fR can be used as an alias for this extension.
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The VFPv3 floating-point instructions with 16 double-precision registers.
  The extension +vfpv3\-d16 can be used as an alias for this extension.
! .IP "\fB+vfpv3xd\-d16\-fp16\fR" 4
  .IX Item "+vfpv3xd-d16-fp16"
! The single-precision VFPv3 floating-point instructions with 16 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+vfpv3\-d16\-fp16\fR" 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating-point instructions with 16 double-precision
! registers and the half-precision floating-point conversion operations.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point extension.
! .IP "\fB+idiv\fR" 4
  .IX Item "+idiv"
! The ARM-state integer division instructions.
! .IP "\fB+noidiv\fR" 4
  .IX Item "+noidiv"
! Disable the ARM-state integer division extension.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv7e\-m\fR" 4
  .IX Item "armv7e-m"
  .RS 4
  .PD 0
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
  .PD
! The single-precision VFPv4 floating-point instructions.
! .IP "\fB+fpv5\fR" 4
  .IX Item "+fpv5"
! The single-precision FPv5 floating-point instructions.
! .IP "\fB+fp.dp\fR" 4
  .IX Item "+fp.dp"
! The single\- and double-precision FPv5 floating-point instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point extensions.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8.1\-m.main\fR" 4
  .IX Item "armv8.1-m.main"
  .RS 4
  .PD 0
! .IP "\fB+dsp\fR" 4
  .IX Item "+dsp"
  .PD
! The \s-1DSP\s0 instructions.
! .IP "\fB+mve\fR" 4
  .IX Item "+mve"
! The M\-Profile Vector Extension (\s-1MVE\s0) integer instructions.
! .IP "\fB+mve.fp\fR" 4
  .IX Item "+mve.fp"
! The M\-Profile Vector Extension (\s-1MVE\s0) integer and single precision
! floating-point instructions.
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The single-precision floating-point instructions.
! .IP "\fB+fp.dp\fR" 4
  .IX Item "+fp.dp"
! The single\- and double-precision floating-point instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point extension.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (\s-1CDE\s0) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7.
! .IP "\fB+pacbti\fR" 4
  .IX Item "+pacbti"
  Enable the Pointer Authentication and Branch Target Identification Extension.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8\-m.main\fR" 4
  .IX Item "armv8-m.main"
  .RS 4
  .PD 0
! .IP "\fB+dsp\fR" 4
  .IX Item "+dsp"
  .PD
! The \s-1DSP\s0 instructions.
! .IP "\fB+nodsp\fR" 4
  .IX Item "+nodsp"
! Disable the \s-1DSP\s0 extension.
! .IP "\fB+fp\fR" 4
  .IX Item "+fp"
! The single-precision floating-point instructions.
! .IP "\fB+fp.dp\fR" 4
  .IX Item "+fp.dp"
! The single\- and double-precision floating-point instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point extension.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (\s-1CDE\s0) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7.
  .RE
  .RS 4
  .RE
! .IP "\fBarmv8\-r\fR" 4
  .IX Item "armv8-r"
  .RS 4
  .PD 0
! .IP "\fB+crc\fR" 4
  .IX Item "+crc"
  .PD
! The Cyclic Redundancy Check (\s-1CRC\s0) instructions.
! .IP "\fB+fp.sp\fR" 4
  .IX Item "+fp.sp"
! The single-precision FPv5 floating-point instructions.
! .IP "\fB+simd\fR" 4
  .IX Item "+simd"
! The ARMv8\-A Advanced \s-1SIMD\s0 and floating-point instructions.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
  The cryptographic instructions.
! .IP "\fB+nocrypto\fR" 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disable the floating-point, Advanced \s-1SIMD\s0 and cryptographic instructions.
  .RE
  .RS 4
  .RE
  .RE
  .RS 4
  .Sp
! \&\fB\-march=native\fR causes the compiler to auto-detect the architecture
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto-detect
  is unsuccessful the option has no effect.
  .RE
! .IP "\fB\-mtune=\fR\fIname\fR" 4
  .IX Item "-mtune=name"
! This option specifies the name of the target \s-1ARM\s0 processor for
! which \s-1GCC\s0 should tune the performance of the code.
! For some \s-1ARM\s0 implementations better performance can be obtained by using
  this option.
  Permissible names are: \fBarm7tdmi\fR, \fBarm7tdmi\-s\fR, \fBarm710t\fR,
  \&\fBarm720t\fR, \fBarm740t\fR, \fBstrongarm\fR, \fBstrongarm110\fR,
--- 20965,21505 ----
  dependent upon the architecture to which it is applied.  For example,
  the \fB+simd\fR option can be applied to both \fBarmv7\-a\fR and
  \&\fBarmv8\-a\fR architectures, but will enable the original ARMv7\-A
! Advanced SIMD (Neon) extensions for \fBarmv7\-a\fR and the ARMv8\-A
  variant for \fBarmv8\-a\fR.
  .Sp
  The table below lists the supported extensions for each architecture.
  Architectures not mentioned do not support any extensions.
  .RS 4
! .IP \fBarmv5te\fR 4
  .IX Item "armv5te"
  .PD 0
! .IP \fBarmv6\fR 4
  .IX Item "armv6"
! .IP \fBarmv6j\fR 4
  .IX Item "armv6j"
! .IP \fBarmv6k\fR 4
  .IX Item "armv6k"
! .IP \fBarmv6kz\fR 4
  .IX Item "armv6kz"
! .IP \fBarmv6t2\fR 4
  .IX Item "armv6t2"
! .IP \fBarmv6z\fR 4
  .IX Item "armv6z"
! .IP \fBarmv6zk\fR 4
  .IX Item "armv6zk"
  .RS 4
! .IP \fB+fp\fR 4
  .IX Item "+fp"
  .PD
! The VFPv2 floating\-point instructions.  The extension \fB+vfpv2\fR can be
  used as an alias for this extension.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv7\fR 4
  .IX Item "armv7"
  The common subset of the ARMv7\-A, ARMv7\-R and ARMv7\-M architectures.
  .RS 4
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The VFPv3 floating\-point instructions, with 16 double\-precision
  registers.  The extension \fB+vfpv3\-d16\fR can be used as an alias
! for this extension.  Note that floating\-point is not supported by the
  base ARMv7\-M architecture, but is compatible with both the ARMv7\-A and
  ARMv7\-R architectures.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv7\-a\fR 4
  .IX Item "armv7-a"
  .RS 4
  .PD 0
! .IP \fB+mp\fR 4
  .IX Item "+mp"
  .PD
  The multiprocessing extension.
! .IP \fB+sec\fR 4
  .IX Item "+sec"
  The security extension.
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The VFPv3 floating\-point instructions, with 16 double\-precision
  registers.  The extension \fB+vfpv3\-d16\fR can be used as an alias
  for this extension.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The Advanced SIMD (Neon) v1 and the VFPv3 floating\-point instructions.
  The extensions \fB+neon\fR and \fB+neon\-vfpv3\fR can be used as aliases
  for this extension.
! .IP \fB+vfpv3\fR 4
  .IX Item "+vfpv3"
! The VFPv3 floating\-point instructions, with 32 double\-precision
  registers.
! .IP \fB+vfpv3\-d16\-fp16\fR 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating\-point instructions, with 16 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+vfpv3\-fp16\fR 4
  .IX Item "+vfpv3-fp16"
! The VFPv3 floating\-point instructions, with 32 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+vfpv4\-d16\fR 4
  .IX Item "+vfpv4-d16"
! The VFPv4 floating\-point instructions, with 16 double\-precision
  registers.
! .IP \fB+vfpv4\fR 4
  .IX Item "+vfpv4"
! The VFPv4 floating\-point instructions, with 32 double\-precision
  registers.
! .IP \fB+neon\-fp16\fR 4
  .IX Item "+neon-fp16"
! The Advanced SIMD (Neon) v1 and the VFPv3 floating\-point instructions, with
! the half\-precision floating\-point conversion operations.
! .IP \fB+neon\-vfpv4\fR 4
  .IX Item "+neon-vfpv4"
! The Advanced SIMD (Neon) v2 and the VFPv4 floating\-point instructions.
! .IP \fB+nosimd\fR 4
  .IX Item "+nosimd"
! Disable the Advanced SIMD instructions (does not disable floating point).
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point and Advanced SIMD instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv7ve\fR 4
  .IX Item "armv7ve"
  The extended version of the ARMv7\-A architecture with support for
  virtualization.
  .RS 4
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The VFPv4 floating\-point instructions, with 16 double\-precision registers.
  The extension \fB+vfpv4\-d16\fR can be used as an alias for this extension.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The Advanced SIMD (Neon) v2 and the VFPv4 floating\-point instructions.  The
  extension \fB+neon\-vfpv4\fR can be used as an alias for this extension.
! .IP \fB+vfpv3\-d16\fR 4
  .IX Item "+vfpv3-d16"
! The VFPv3 floating\-point instructions, with 16 double\-precision
  registers.
! .IP \fB+vfpv3\fR 4
  .IX Item "+vfpv3"
! The VFPv3 floating\-point instructions, with 32 double\-precision
  registers.
! .IP \fB+vfpv3\-d16\-fp16\fR 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating\-point instructions, with 16 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+vfpv3\-fp16\fR 4
  .IX Item "+vfpv3-fp16"
! The VFPv3 floating\-point instructions, with 32 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+vfpv4\-d16\fR 4
  .IX Item "+vfpv4-d16"
! The VFPv4 floating\-point instructions, with 16 double\-precision
  registers.
! .IP \fB+vfpv4\fR 4
  .IX Item "+vfpv4"
! The VFPv4 floating\-point instructions, with 32 double\-precision
  registers.
! .IP \fB+neon\fR 4
  .IX Item "+neon"
! The Advanced SIMD (Neon) v1 and the VFPv3 floating\-point instructions.
  The extension \fB+neon\-vfpv3\fR can be used as an alias for this extension.
! .IP \fB+neon\-fp16\fR 4
  .IX Item "+neon-fp16"
! The Advanced SIMD (Neon) v1 and the VFPv3 floating\-point instructions, with
! the half\-precision floating\-point conversion operations.
! .IP \fB+nosimd\fR 4
  .IX Item "+nosimd"
! Disable the Advanced SIMD instructions (does not disable floating point).
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point and Advanced SIMD instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8\-a\fR 4
  .IX Item "armv8-a"
  .RS 4
  .PD 0
! .IP \fB+crc\fR 4
  .IX Item "+crc"
  .PD
! The Cyclic Redundancy Check (CRC) instructions.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8\-A Advanced SIMD and floating\-point instructions.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
  The cryptographic instructions.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+sb\fR 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP \fB+predres\fR 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.1\-a\fR 4
  .IX Item "armv8.1-a"
  .RS 4
  .PD 0
! .IP \fB+simd\fR 4
  .IX Item "+simd"
  .PD
! The ARMv8.1\-A Advanced SIMD and floating\-point instructions.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced SIMD and
! floating\-point instructions.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+sb\fR 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP \fB+predres\fR 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.2\-a\fR 4
  .IX Item "armv8.2-a"
  .PD 0
! .IP \fBarmv8.3\-a\fR 4
  .IX Item "armv8.3-a"
  .RS 4
! .IP \fB+fp16\fR 4
  .IX Item "+fp16"
  .PD
! The half\-precision floating\-point data processing instructions.
! This also enables the Advanced SIMD and floating\-point instructions.
! .IP \fB+fp16fml\fR 4
  .IX Item "+fp16fml"
! The half\-precision floating\-point fmla extension.  This also enables
! the half\-precision floating\-point extension and Advanced SIMD and
! floating\-point instructions.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8.1\-A Advanced SIMD and floating\-point instructions.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced SIMD and
! floating\-point instructions.
! .IP \fB+dotprod\fR 4
  .IX Item "+dotprod"
! Enable the Dot Product extension.  This also enables Advanced SIMD instructions.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+sb\fR 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP \fB+predres\fR 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
! .IP \fB+i8mm\fR 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced SIMD and floating\-point instructions.
! .IP \fB+bf16\fR 4
  .IX Item "+bf16"
! Brain half\-precision floating\-point instructions.
! This also enables Advanced SIMD and floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.4\-a\fR 4
  .IX Item "armv8.4-a"
  .RS 4
  .PD 0
! .IP \fB+fp16\fR 4
  .IX Item "+fp16"
  .PD
! The half\-precision floating\-point data processing instructions.
! This also enables the Advanced SIMD and floating\-point instructions as well
! as the Dot Product extension and the half\-precision floating\-point fmla
  extension.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced SIMD and floating\-point instructions as well as the
  Dot Product extension.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced SIMD and
! floating\-point instructions as well as the Dot Product extension.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+sb\fR 4
  .IX Item "+sb"
  Speculation Barrier Instruction.
! .IP \fB+predres\fR 4
  .IX Item "+predres"
  Execution and Data Prediction Restriction Instructions.
! .IP \fB+i8mm\fR 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced SIMD and floating\-point instructions.
! .IP \fB+bf16\fR 4
  .IX Item "+bf16"
! Brain half\-precision floating\-point instructions.
! This also enables Advanced SIMD and floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.5\-a\fR 4
  .IX Item "armv8.5-a"
  .RS 4
  .PD 0
! .IP \fB+fp16\fR 4
  .IX Item "+fp16"
  .PD
! The half\-precision floating\-point data processing instructions.
! This also enables the Advanced SIMD and floating\-point instructions as well
! as the Dot Product extension and the half\-precision floating\-point fmla
  extension.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced SIMD and floating\-point instructions as well as the
  Dot Product extension.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced SIMD and
! floating\-point instructions as well as the Dot Product extension.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+i8mm\fR 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced SIMD and floating\-point instructions.
! .IP \fB+bf16\fR 4
  .IX Item "+bf16"
! Brain half\-precision floating\-point instructions.
! This also enables Advanced SIMD and floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.6\-a\fR 4
  .IX Item "armv8.6-a"
  .RS 4
  .PD 0
! .IP \fB+fp16\fR 4
  .IX Item "+fp16"
  .PD
! The half\-precision floating\-point data processing instructions.
! This also enables the Advanced SIMD and floating\-point instructions as well
! as the Dot Product extension and the half\-precision floating\-point fmla
  extension.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8.3\-A Advanced SIMD and floating\-point instructions as well as the
  Dot Product extension.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
! The cryptographic instructions.  This also enables the Advanced SIMD and
! floating\-point instructions as well as the Dot Product extension.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic extension.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
! .IP \fB+i8mm\fR 4
  .IX Item "+i8mm"
  8\-bit Integer Matrix Multiply instructions.
! This also enables Advanced SIMD and floating\-point instructions.
! .IP \fB+bf16\fR 4
  .IX Item "+bf16"
! Brain half\-precision floating\-point instructions.
! This also enables Advanced SIMD and floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv7\-r\fR 4
  .IX Item "armv7-r"
  .RS 4
  .PD 0
! .IP \fB+fp.sp\fR 4
  .IX Item "+fp.sp"
  .PD
! The single\-precision VFPv3 floating\-point instructions.  The extension
  \&\fB+vfpv3xd\fR can be used as an alias for this extension.
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The VFPv3 floating\-point instructions with 16 double\-precision registers.
  The extension +vfpv3\-d16 can be used as an alias for this extension.
! .IP \fB+vfpv3xd\-d16\-fp16\fR 4
  .IX Item "+vfpv3xd-d16-fp16"
! The single\-precision VFPv3 floating\-point instructions with 16 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+vfpv3\-d16\-fp16\fR 4
  .IX Item "+vfpv3-d16-fp16"
! The VFPv3 floating\-point instructions with 16 double\-precision
! registers and the half\-precision floating\-point conversion operations.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point extension.
! .IP \fB+idiv\fR 4
  .IX Item "+idiv"
! The ARM\-state integer division instructions.
! .IP \fB+noidiv\fR 4
  .IX Item "+noidiv"
! Disable the ARM\-state integer division extension.
  .RE
  .RS 4
  .RE
! .IP \fBarmv7e\-m\fR 4
  .IX Item "armv7e-m"
  .RS 4
  .PD 0
! .IP \fB+fp\fR 4
  .IX Item "+fp"
  .PD
! The single\-precision VFPv4 floating\-point instructions.
! .IP \fB+fpv5\fR 4
  .IX Item "+fpv5"
! The single\-precision FPv5 floating\-point instructions.
! .IP \fB+fp.dp\fR 4
  .IX Item "+fp.dp"
! The single\- and double\-precision FPv5 floating\-point instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point extensions.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8.1\-m.main\fR 4
  .IX Item "armv8.1-m.main"
  .RS 4
  .PD 0
! .IP \fB+dsp\fR 4
  .IX Item "+dsp"
  .PD
! The DSP instructions.
! .IP \fB+mve\fR 4
  .IX Item "+mve"
! The M\-Profile Vector Extension (MVE) integer instructions.
! .IP \fB+mve.fp\fR 4
  .IX Item "+mve.fp"
! The M\-Profile Vector Extension (MVE) integer and single precision
! floating\-point instructions.
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The single\-precision floating\-point instructions.
! .IP \fB+fp.dp\fR 4
  .IX Item "+fp.dp"
! The single\- and double\-precision floating\-point instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point extension.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (CDE) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7.
! .IP \fB+pacbti\fR 4
  .IX Item "+pacbti"
  Enable the Pointer Authentication and Branch Target Identification Extension.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8\-m.main\fR 4
  .IX Item "armv8-m.main"
  .RS 4
  .PD 0
! .IP \fB+dsp\fR 4
  .IX Item "+dsp"
  .PD
! The DSP instructions.
! .IP \fB+nodsp\fR 4
  .IX Item "+nodsp"
! Disable the DSP extension.
! .IP \fB+fp\fR 4
  .IX Item "+fp"
! The single\-precision floating\-point instructions.
! .IP \fB+fp.dp\fR 4
  .IX Item "+fp.dp"
! The single\- and double\-precision floating\-point instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point extension.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (CDE) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7.
  .RE
  .RS 4
  .RE
! .IP \fBarmv8\-r\fR 4
  .IX Item "armv8-r"
  .RS 4
  .PD 0
! .IP \fB+crc\fR 4
  .IX Item "+crc"
  .PD
! The Cyclic Redundancy Check (CRC) instructions.
! .IP \fB+fp.sp\fR 4
  .IX Item "+fp.sp"
! The single\-precision FPv5 floating\-point instructions.
! .IP \fB+simd\fR 4
  .IX Item "+simd"
! The ARMv8\-A Advanced SIMD and floating\-point instructions.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
  The cryptographic instructions.
! .IP \fB+nocrypto\fR 4
  .IX Item "+nocrypto"
  Disable the cryptographic instructions.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disable the floating\-point, Advanced SIMD and cryptographic instructions.
  .RE
  .RS 4
  .RE
  .RE
  .RS 4
  .Sp
! \&\fB\-march=native\fR causes the compiler to auto\-detect the architecture
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto\-detect
  is unsuccessful the option has no effect.
  .RE
! .IP \fB\-mtune=\fR\fIname\fR 4
  .IX Item "-mtune=name"
! This option specifies the name of the target ARM processor for
! which GCC should tune the performance of the code.
! For some ARM implementations better performance can be obtained by using
  this option.
  Permissible names are: \fBarm7tdmi\fR, \fBarm7tdmi\-s\fR, \fBarm710t\fR,
  \&\fBarm720t\fR, \fBarm740t\fR, \fBstrongarm\fR, \fBstrongarm110\fR,
*************** Permissible names are: \fBarm7tdmi\fR, \
*** 21597,21628 ****
  \&\fBfa606te\fR, \fBfa626te\fR, \fBfmp626\fR, \fBfa726te\fR, \fBstar\-mc1\fR,
  \&\fBxgene1\fR.
  .Sp
! Additionally, this option can specify that \s-1GCC\s0 should tune the performance
  of the code for a big.LITTLE system.  Permissible names are:
  \&\fBcortex\-a15.cortex\-a7\fR, \fBcortex\-a17.cortex\-a7\fR,
  \&\fBcortex\-a57.cortex\-a53\fR, \fBcortex\-a72.cortex\-a53\fR,
  \&\fBcortex\-a72.cortex\-a35\fR, \fBcortex\-a73.cortex\-a53\fR,
  \&\fBcortex\-a75.cortex\-a55\fR, \fBcortex\-a76.cortex\-a55\fR.
  .Sp
! \&\fB\-mtune=generic\-\fR\fIarch\fR specifies that \s-1GCC\s0 should tune the
  performance for a blend of processors within architecture \fIarch\fR.
  The aim is to generate code that run well on the current most popular
  processors, balancing between optimizations that benefit some CPUs in the
  range, and avoiding performance pitfalls of other CPUs.  The effects of
! this option may change in future \s-1GCC\s0 versions as \s-1CPU\s0 models come and go.
  .Sp
  \&\fB\-mtune\fR permits the same extension options as \fB\-mcpu\fR, but
  the extension options do not affect the tuning of the generated code.
  .Sp
! \&\fB\-mtune=native\fR causes the compiler to auto-detect the \s-1CPU\s0
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto-detect is
  unsuccessful the option has no effect.
! .IP "\fB\-mcpu=\fR\fIname\fR[\fB+extension...\fR]" 4
  .IX Item "-mcpu=name[+extension...]"
! This specifies the name of the target \s-1ARM\s0 processor.  \s-1GCC\s0 uses this name
! to derive the name of the target \s-1ARM\s0 architecture (as if specified
! by \fB\-march\fR) and the \s-1ARM\s0 processor type for which to tune for
  performance (as if specified by \fB\-mtune\fR).  Where this option
  is used in conjunction with \fB\-march\fR or \fB\-mtune\fR,
  those options take precedence over the appropriate part of this option.
--- 21528,21559 ----
  \&\fBfa606te\fR, \fBfa626te\fR, \fBfmp626\fR, \fBfa726te\fR, \fBstar\-mc1\fR,
  \&\fBxgene1\fR.
  .Sp
! Additionally, this option can specify that GCC should tune the performance
  of the code for a big.LITTLE system.  Permissible names are:
  \&\fBcortex\-a15.cortex\-a7\fR, \fBcortex\-a17.cortex\-a7\fR,
  \&\fBcortex\-a57.cortex\-a53\fR, \fBcortex\-a72.cortex\-a53\fR,
  \&\fBcortex\-a72.cortex\-a35\fR, \fBcortex\-a73.cortex\-a53\fR,
  \&\fBcortex\-a75.cortex\-a55\fR, \fBcortex\-a76.cortex\-a55\fR.
  .Sp
! \&\fB\-mtune=generic\-\fR\fIarch\fR specifies that GCC should tune the
  performance for a blend of processors within architecture \fIarch\fR.
  The aim is to generate code that run well on the current most popular
  processors, balancing between optimizations that benefit some CPUs in the
  range, and avoiding performance pitfalls of other CPUs.  The effects of
! this option may change in future GCC versions as CPU models come and go.
  .Sp
  \&\fB\-mtune\fR permits the same extension options as \fB\-mcpu\fR, but
  the extension options do not affect the tuning of the generated code.
  .Sp
! \&\fB\-mtune=native\fR causes the compiler to auto\-detect the CPU
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto\-detect is
  unsuccessful the option has no effect.
! .IP \fB\-mcpu=\fR\fIname\fR[\fB+extension...\fR] 4
  .IX Item "-mcpu=name[+extension...]"
! This specifies the name of the target ARM processor.  GCC uses this name
! to derive the name of the target ARM architecture (as if specified
! by \fB\-march\fR) and the ARM processor type for which to tune for
  performance (as if specified by \fB\-mtune\fR).  Where this option
  is used in conjunction with \fB\-march\fR or \fB\-mtune\fR,
  those options take precedence over the appropriate part of this option.
*************** Many of the supported CPUs implement opt
*** 21631,21649 ****
  extensions.  Where this is so the architectural extensions are
  normally enabled by default.  If implementations that lack the
  extension exist, then the extension syntax can be used to disable
! those extensions that have been omitted.  For floating-point and
! Advanced \s-1SIMD\s0 (Neon) instructions, the settings of the options
  \&\fB\-mfloat\-abi\fR and \fB\-mfpu\fR must also be considered:
! floating-point and Advanced \s-1SIMD\s0 instructions will only be used if
  \&\fB\-mfloat\-abi\fR is not set to \fBsoft\fR; and any setting of
  \&\fB\-mfpu\fR other than \fBauto\fR will override the available
! floating-point and \s-1SIMD\s0 extension instructions.
  .Sp
  For example, \fBcortex\-a9\fR can be found in three major
! configurations: integer only, with just a floating-point unit or with
! floating-point and Advanced \s-1SIMD.\s0  The default is to enable all the
  instructions, but the extensions \fB+nosimd\fR and \fB+nofp\fR can
! be used to disable just the \s-1SIMD\s0 or both the \s-1SIMD\s0 and floating-point
  instructions respectively.
  .Sp
  Permissible names for this option are the same as those for
--- 21562,21580 ----
  extensions.  Where this is so the architectural extensions are
  normally enabled by default.  If implementations that lack the
  extension exist, then the extension syntax can be used to disable
! those extensions that have been omitted.  For floating\-point and
! Advanced SIMD (Neon) instructions, the settings of the options
  \&\fB\-mfloat\-abi\fR and \fB\-mfpu\fR must also be considered:
! floating\-point and Advanced SIMD instructions will only be used if
  \&\fB\-mfloat\-abi\fR is not set to \fBsoft\fR; and any setting of
  \&\fB\-mfpu\fR other than \fBauto\fR will override the available
! floating\-point and SIMD extension instructions.
  .Sp
  For example, \fBcortex\-a9\fR can be found in three major
! configurations: integer only, with just a floating\-point unit or with
! floating\-point and Advanced SIMD.  The default is to enable all the
  instructions, but the extensions \fB+nosimd\fR and \fB+nofp\fR can
! be used to disable just the SIMD or both the SIMD and floating\-point
  instructions respectively.
  .Sp
  Permissible names for this option are the same as those for
*************** Permissible names for this option are th
*** 21651,21704 ****
  .Sp
  The following extension options are common to the listed CPUs:
  .RS 4
! .IP "\fB+nodsp\fR" 4
  .IX Item "+nodsp"
! Disable the \s-1DSP\s0 instructions on \fBcortex\-m33\fR, \fBcortex\-m35p\fR,
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR. Also disable the M\-Profile Vector
! Extension (\s-1MVE\s0) integer and single precision floating-point instructions on
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR.
! .IP "\fB+nopacbti\fR" 4
  .IX Item "+nopacbti"
  Disable the Pointer Authentication and Branch Target Identification Extension
  on \fBcortex\-m85\fR.
! .IP "\fB+nomve\fR" 4
  .IX Item "+nomve"
! Disable the M\-Profile Vector Extension (\s-1MVE\s0) integer and single precision
! floating-point instructions on \fBcortex\-m55\fR and \fBcortex\-m85\fR.
! .IP "\fB+nomve.fp\fR" 4
  .IX Item "+nomve.fp"
! Disable the M\-Profile Vector Extension (\s-1MVE\s0) single precision floating-point
  instructions on \fBcortex\-m55\fR and \fBcortex\-m85\fR.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (\s-1CDE\s0) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7 on \fBcortex\-m55\fR.
! .IP "\fB+nofp\fR" 4
  .IX Item "+nofp"
! Disables the floating-point instructions on \fBarm9e\fR,
  \&\fBarm946e\-s\fR, \fBarm966e\-s\fR, \fBarm968e\-s\fR, \fBarm10e\fR,
  \&\fBarm1020e\fR, \fBarm1022e\fR, \fBarm926ej\-s\fR,
  \&\fBarm1026ej\-s\fR, \fBcortex\-r5\fR, \fBcortex\-r7\fR, \fBcortex\-r8\fR,
  \&\fBcortex\-m4\fR, \fBcortex\-m7\fR, \fBcortex\-m33\fR, \fBcortex\-m35p\fR
  \&\fBcortex\-m4\fR, \fBcortex\-m7\fR, \fBcortex\-m33\fR, \fBcortex\-m35p\fR,
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR.
! Disables the floating-point and \s-1SIMD\s0 instructions on
  \&\fBgeneric\-armv7\-a\fR, \fBcortex\-a5\fR, \fBcortex\-a7\fR,
  \&\fBcortex\-a8\fR, \fBcortex\-a9\fR, \fBcortex\-a12\fR,
  \&\fBcortex\-a15\fR, \fBcortex\-a17\fR, \fBcortex\-a15.cortex\-a7\fR,
  \&\fBcortex\-a17.cortex\-a7\fR, \fBcortex\-a32\fR, \fBcortex\-a35\fR,
  \&\fBcortex\-a53\fR and \fBcortex\-a55\fR.
! .IP "\fB+nofp.dp\fR" 4
  .IX Item "+nofp.dp"
! Disables the double-precision component of the floating-point instructions
  on \fBcortex\-r5\fR, \fBcortex\-r7\fR, \fBcortex\-r8\fR, \fBcortex\-r52\fR,
  \&\fBcortex\-r52plus\fR and \fBcortex\-m7\fR.
! .IP "\fB+nosimd\fR" 4
  .IX Item "+nosimd"
! Disables the \s-1SIMD\s0 (but not floating-point) instructions on
  \&\fBgeneric\-armv7\-a\fR, \fBcortex\-a5\fR, \fBcortex\-a7\fR
  and \fBcortex\-a9\fR.
! .IP "\fB+crypto\fR" 4
  .IX Item "+crypto"
  Enables the cryptographic instructions on \fBcortex\-a32\fR,
  \&\fBcortex\-a35\fR, \fBcortex\-a53\fR, \fBcortex\-a55\fR, \fBcortex\-a57\fR,
--- 21582,21635 ----
  .Sp
  The following extension options are common to the listed CPUs:
  .RS 4
! .IP \fB+nodsp\fR 4
  .IX Item "+nodsp"
! Disable the DSP instructions on \fBcortex\-m33\fR, \fBcortex\-m35p\fR,
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR. Also disable the M\-Profile Vector
! Extension (MVE) integer and single precision floating\-point instructions on
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR.
! .IP \fB+nopacbti\fR 4
  .IX Item "+nopacbti"
  Disable the Pointer Authentication and Branch Target Identification Extension
  on \fBcortex\-m85\fR.
! .IP \fB+nomve\fR 4
  .IX Item "+nomve"
! Disable the M\-Profile Vector Extension (MVE) integer and single precision
! floating\-point instructions on \fBcortex\-m55\fR and \fBcortex\-m85\fR.
! .IP \fB+nomve.fp\fR 4
  .IX Item "+nomve.fp"
! Disable the M\-Profile Vector Extension (MVE) single precision floating\-point
  instructions on \fBcortex\-m55\fR and \fBcortex\-m85\fR.
  .IP "\fB+cdecp0, +cdecp1, ... , +cdecp7\fR" 4
  .IX Item "+cdecp0, +cdecp1, ... , +cdecp7"
! Enable the Custom Datapath Extension (CDE) on selected coprocessors according
  to the numbers given in the options in the range 0 to 7 on \fBcortex\-m55\fR.
! .IP \fB+nofp\fR 4
  .IX Item "+nofp"
! Disables the floating\-point instructions on \fBarm9e\fR,
  \&\fBarm946e\-s\fR, \fBarm966e\-s\fR, \fBarm968e\-s\fR, \fBarm10e\fR,
  \&\fBarm1020e\fR, \fBarm1022e\fR, \fBarm926ej\-s\fR,
  \&\fBarm1026ej\-s\fR, \fBcortex\-r5\fR, \fBcortex\-r7\fR, \fBcortex\-r8\fR,
  \&\fBcortex\-m4\fR, \fBcortex\-m7\fR, \fBcortex\-m33\fR, \fBcortex\-m35p\fR
  \&\fBcortex\-m4\fR, \fBcortex\-m7\fR, \fBcortex\-m33\fR, \fBcortex\-m35p\fR,
  \&\fBcortex\-m55\fR and \fBcortex\-m85\fR.
! Disables the floating\-point and SIMD instructions on
  \&\fBgeneric\-armv7\-a\fR, \fBcortex\-a5\fR, \fBcortex\-a7\fR,
  \&\fBcortex\-a8\fR, \fBcortex\-a9\fR, \fBcortex\-a12\fR,
  \&\fBcortex\-a15\fR, \fBcortex\-a17\fR, \fBcortex\-a15.cortex\-a7\fR,
  \&\fBcortex\-a17.cortex\-a7\fR, \fBcortex\-a32\fR, \fBcortex\-a35\fR,
  \&\fBcortex\-a53\fR and \fBcortex\-a55\fR.
! .IP \fB+nofp.dp\fR 4
  .IX Item "+nofp.dp"
! Disables the double\-precision component of the floating\-point instructions
  on \fBcortex\-r5\fR, \fBcortex\-r7\fR, \fBcortex\-r8\fR, \fBcortex\-r52\fR,
  \&\fBcortex\-r52plus\fR and \fBcortex\-m7\fR.
! .IP \fB+nosimd\fR 4
  .IX Item "+nosimd"
! Disables the SIMD (but not floating\-point) instructions on
  \&\fBgeneric\-armv7\-a\fR, \fBcortex\-a5\fR, \fBcortex\-a7\fR
  and \fBcortex\-a9\fR.
! .IP \fB+crypto\fR 4
  .IX Item "+crypto"
  Enables the cryptographic instructions on \fBcortex\-a32\fR,
  \&\fBcortex\-a35\fR, \fBcortex\-a53\fR, \fBcortex\-a55\fR, \fBcortex\-a57\fR,
*************** Enables the cryptographic instructions o
*** 21710,21716 ****
  .RS 4
  .Sp
  Additionally the \fBgeneric\-armv7\-a\fR pseudo target defaults to
! VFPv3 with 16 double-precision registers.  It supports the following
  extension options: \fBmp\fR, \fBsec\fR, \fBvfpv3\-d16\fR,
  \&\fBvfpv3\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3\-fp16\fR,
  \&\fBvfpv4\-d16\fR, \fBvfpv4\fR, \fBneon\fR, \fBneon\-vfpv3\fR,
--- 21641,21647 ----
  .RS 4
  .Sp
  Additionally the \fBgeneric\-armv7\-a\fR pseudo target defaults to
! VFPv3 with 16 double\-precision registers.  It supports the following
  extension options: \fBmp\fR, \fBsec\fR, \fBvfpv3\-d16\fR,
  \&\fBvfpv3\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3\-fp16\fR,
  \&\fBvfpv4\-d16\fR, \fBvfpv4\fR, \fBneon\fR, \fBneon\-vfpv3\fR,
*************** the extensions to \fB\-march=armv7\-a\fR
*** 21721,21734 ****
  equivalent to \fB\-march=\fR\fIarch\fR \fB\-mtune=generic\-\fR\fIarch\fR.
  See \fB\-mtune\fR for more information.
  .Sp
! \&\fB\-mcpu=native\fR causes the compiler to auto-detect the \s-1CPU\s0
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto-detect
  is unsuccessful the option has no effect.
  .RE
! .IP "\fB\-mfpu=\fR\fIname\fR" 4
  .IX Item "-mfpu=name"
! This specifies what floating-point hardware (or hardware emulation) is
  available on the target.  Permissible names are: \fBauto\fR, \fBvfpv2\fR,
  \&\fBvfpv3\fR,
  \&\fBvfpv3\-fp16\fR, \fBvfpv3\-d16\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3xd\fR,
--- 21652,21665 ----
  equivalent to \fB\-march=\fR\fIarch\fR \fB\-mtune=generic\-\fR\fIarch\fR.
  See \fB\-mtune\fR for more information.
  .Sp
! \&\fB\-mcpu=native\fR causes the compiler to auto\-detect the CPU
  of the build computer.  At present, this feature is only supported on
! GNU/Linux, and not all architectures are recognized.  If the auto\-detect
  is unsuccessful the option has no effect.
  .RE
! .IP \fB\-mfpu=\fR\fIname\fR 4
  .IX Item "-mfpu=name"
! This specifies what floating\-point hardware (or hardware emulation) is
  available on the target.  Permissible names are: \fBauto\fR, \fBvfpv2\fR,
  \&\fBvfpv3\fR,
  \&\fBvfpv3\-fp16\fR, \fBvfpv3\-d16\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3xd\fR,
*************** Note that \fBneon\fR is an alias for \fB
*** 21740,21770 ****
  is an alias for \fBvfpv2\fR.
  .Sp
  The setting \fBauto\fR is the default and is special.  It causes the
! compiler to select the floating-point and Advanced \s-1SIMD\s0 instructions
  based on the settings of \fB\-mcpu\fR and \fB\-march\fR.
  .Sp
! If the selected floating-point hardware includes the \s-1NEON\s0 extension
! (e.g. \fB\-mfpu=neon\fR), note that floating-point
! operations are not generated by \s-1GCC\s0's auto-vectorization pass unless
  \&\fB\-funsafe\-math\-optimizations\fR is also specified.  This is
! because \s-1NEON\s0 hardware does not fully implement the \s-1IEEE 754\s0 standard for
! floating-point arithmetic (in particular denormal values are treated as
! zero), so the use of \s-1NEON\s0 instructions may lead to a loss of precision.
  .Sp
! You can also set the fpu name at function level by using the \f(CW\*(C`target("fpu=")\*(C'\fR function attributes or pragmas.
! .IP "\fB\-mfp16\-format=\fR\fIname\fR" 4
  .IX Item "-mfp16-format=name"
! Specify the format of the \f(CW\*(C`_\|_fp16\*(C'\fR half-precision floating-point type.
  Permissible names are \fBnone\fR, \fBieee\fR, and \fBalternative\fR;
  the default is \fBnone\fR, in which case the \f(CW\*(C`_\|_fp16\*(C'\fR type is not
  defined.
! .IP "\fB\-mstructure\-size\-boundary=\fR\fIn\fR" 4
  .IX Item "-mstructure-size-boundary=n"
  The sizes of all structures and unions are rounded up to a multiple
  of the number of bits set by this option.  Permissible values are 8, 32
! and 64.  The default value varies for different toolchains.  For the \s-1COFF\s0
  targeted toolchain the default value is 8.  A value of 64 is only allowed
! if the underlying \s-1ABI\s0 supports it.
  .Sp
  Specifying a larger number can produce faster, more efficient code, but
  can also increase the size of the program.  Different values are potentially
--- 21671,21701 ----
  is an alias for \fBvfpv2\fR.
  .Sp
  The setting \fBauto\fR is the default and is special.  It causes the
! compiler to select the floating\-point and Advanced SIMD instructions
  based on the settings of \fB\-mcpu\fR and \fB\-march\fR.
  .Sp
! If the selected floating\-point hardware includes the NEON extension
! (e.g. \fB\-mfpu=neon\fR), note that floating\-point
! operations are not generated by GCC\*(Aqs auto\-vectorization pass unless
  \&\fB\-funsafe\-math\-optimizations\fR 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.
  .Sp
! You can also set the fpu name at function level by using the \f(CWtarget("fpu=")\fR function attributes or pragmas.
! .IP \fB\-mfp16\-format=\fR\fIname\fR 4
  .IX Item "-mfp16-format=name"
! Specify the format of the \f(CW\*(C`_\|_fp16\*(C'\fR half\-precision floating\-point type.
  Permissible names are \fBnone\fR, \fBieee\fR, and \fBalternative\fR;
  the default is \fBnone\fR, in which case the \f(CW\*(C`_\|_fp16\*(C'\fR type is not
  defined.
! .IP \fB\-mstructure\-size\-boundary=\fR\fIn\fR 4
  .IX Item "-mstructure-size-boundary=n"
  The sizes of all structures and unions are rounded up to a multiple
  of the number of bits set by this option.  Permissible values are 8, 32
! and 64.  The default value varies for different toolchains.  For the COFF
  targeted toolchain the default value is 8.  A value of 64 is only allowed
! if the underlying ABI supports it.
  .Sp
  Specifying a larger number can produce faster, more efficient code, but
  can also increase the size of the program.  Different values are potentially
*************** work with code or libraries compiled wit
*** 21773,21793 ****
  information using structures or unions.
  .Sp
  This option is deprecated.
! .IP "\fB\-mabort\-on\-noreturn\fR" 4
  .IX Item "-mabort-on-noreturn"
  Generate a call to the function \f(CW\*(C`abort\*(C'\fR at the end of a
  \&\f(CW\*(C`noreturn\*(C'\fR function.  It is executed if the function tries to
  return.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP "\fB\-mno\-long\-calls\fR" 4
  .IX Item "-mno-long-calls"
  .PD
  Tells the compiler to perform function calls by first loading the
  address of the function into a register and then performing a subroutine
  call on this register.  This switch is needed if the target function
! lies outside of the 64\-megabyte addressing range of the offset-based
  version of subroutine call instruction.
  .Sp
  Even if this switch is enabled, not all function calls are turned
--- 21704,21724 ----
  information using structures or unions.
  .Sp
  This option is deprecated.
! .IP \fB\-mabort\-on\-noreturn\fR 4
  .IX Item "-mabort-on-noreturn"
  Generate a call to the function \f(CW\*(C`abort\*(C'\fR at the end of a
  \&\f(CW\*(C`noreturn\*(C'\fR function.  It is executed if the function tries to
  return.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP \fB\-mno\-long\-calls\fR 4
  .IX Item "-mno-long-calls"
  .PD
  Tells the compiler to perform function calls by first loading the
  address of the function into a register and then performing a subroutine
  call on this register.  This switch is needed if the target function
! lies outside of the 64\-megabyte addressing range of the offset\-based
  version of subroutine call instruction.
  .Sp
  Even if this switch is enabled, not all function calls are turned
*************** placing the function calls within the sc
*** 21807,21834 ****
  long_calls_off\*(C'\fR directive.  Note these switches have no effect on how
  the compiler generates code to handle function calls via function
  pointers.
! .IP "\fB\-msingle\-pic\-base\fR" 4
  .IX Item "-msingle-pic-base"
! Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
  loading it in the prologue for each function.  The runtime system is
  responsible for initializing this register with an appropriate value
  before execution begins.
! .IP "\fB\-mpic\-register=\fR\fIreg\fR" 4
  .IX Item "-mpic-register=reg"
! Specify the register to be used for \s-1PIC\s0 addressing.
! For standard \s-1PIC\s0 base case, the default is any suitable register
! determined by compiler.  For single \s-1PIC\s0 base case, the default is
! \&\fBR9\fR if target is \s-1EABI\s0 based or stack-checking is enabled,
  otherwise the default is \fBR10\fR.
! .IP "\fB\-mpic\-data\-is\-text\-relative\fR" 4
  .IX Item "-mpic-data-is-text-relative"
  Assume that the displacement between the text and data segments is fixed
! at static link time.  This permits using PC-relative addressing
  operations to access data known to be in the data segment.  For
! non-VxWorks \s-1RTP\s0 targets, this option is enabled by default.  When
  disabled on such targets, it will enable \fB\-msingle\-pic\-base\fR by
  default.
! .IP "\fB\-mpoke\-function\-name\fR" 4
  .IX Item "-mpoke-function-name"
  Write the name of each function into the text section, directly
  preceding the function prologue.  The generated code is similar to this:
--- 21738,21765 ----
  long_calls_off\*(C'\fR directive.  Note these switches have no effect on how
  the compiler generates code to handle function calls via function
  pointers.
! .IP \fB\-msingle\-pic\-base\fR 4
  .IX Item "-msingle-pic-base"
! Treat the register used for PIC addressing as read\-only, rather than
  loading it in the prologue for each function.  The runtime system is
  responsible for initializing this register with an appropriate value
  before execution begins.
! .IP \fB\-mpic\-register=\fR\fIreg\fR 4
  .IX Item "-mpic-register=reg"
! Specify the register to be used for PIC addressing.
! For standard PIC base case, the default is any suitable register
! determined by compiler.  For single PIC base case, the default is
! \&\fBR9\fR if target is EABI based or stack\-checking is enabled,
  otherwise the default is \fBR10\fR.
! .IP \fB\-mpic\-data\-is\-text\-relative\fR 4
  .IX Item "-mpic-data-is-text-relative"
  Assume that the displacement between the text and data segments is fixed
! at static link time.  This permits using PC\-relative addressing
  operations to access data known to be in the data segment.  For
! non\-VxWorks RTP targets, this option is enabled by default.  When
  disabled on such targets, it will enable \fB\-msingle\-pic\-base\fR by
  default.
! .IP \fB\-mpoke\-function\-name\fR 4
  .IX Item "-mpoke-function-name"
  Write the name of each function into the text section, directly
  preceding the function prologue.  The generated code is similar to this:
*************** When performing a stack backtrace, code
*** 21850,21900 ****
  location \f(CW\*(C`pc \- 12\*(C'\fR and the top 8 bits are set, then we know that
  there is a function name embedded immediately preceding this location
  and has length \f(CW\*(C`((pc[\-3]) & 0xff000000)\*(C'\fR.
! .IP "\fB\-mthumb\fR" 4
  .IX Item "-mthumb"
  .PD 0
! .IP "\fB\-marm\fR" 4
  .IX Item "-marm"
  .PD
! Select between generating code that executes in \s-1ARM\s0 and Thumb
  states.  The default for most configurations is to generate code
! that executes in \s-1ARM\s0 state, but the default can be changed by
! configuring \s-1GCC\s0 with the \fB\-\-with\-mode=\fR\fIstate\fR
  configure option.
  .Sp
! You can also override the \s-1ARM\s0 and Thumb mode for each function
! by using the \f(CW\*(C`target("thumb")\*(C'\fR and \f(CW\*(C`target("arm")\*(C'\fR function attributes or pragmas.
! .IP "\fB\-mflip\-thumb\fR" 4
  .IX Item "-mflip-thumb"
  Switch ARM/Thumb modes on alternating functions.
  This option is provided for regression testing of mixed Thumb/ARM code
  generation, and is not intended for ordinary use in compiling code.
! .IP "\fB\-mtpcs\-frame\fR" 4
  .IX Item "-mtpcs-frame"
  Generate a stack frame that is compliant with the Thumb Procedure Call
! Standard for all non-leaf functions.  (A leaf function is one that does
  not call any other functions.)  The default is \fB\-mno\-tpcs\-frame\fR.
! .IP "\fB\-mtpcs\-leaf\-frame\fR" 4
  .IX Item "-mtpcs-leaf-frame"
  Generate a stack frame that is compliant with the Thumb Procedure Call
  Standard for all leaf functions.  (A leaf function is one that does
  not call any other functions.)  The default is \fB\-mno\-apcs\-leaf\-frame\fR.
! .IP "\fB\-mcallee\-super\-interworking\fR" 4
  .IX Item "-mcallee-super-interworking"
! Gives all externally visible functions in the file being compiled an \s-1ARM\s0
  instruction set header which switches to Thumb mode before executing the
  rest of the function.  This allows these functions to be called from
! non-interworking code.  This option is not valid in \s-1AAPCS\s0 configurations
  because interworking is enabled by default.
! .IP "\fB\-mcaller\-super\-interworking\fR" 4
  .IX Item "-mcaller-super-interworking"
  Allows calls via function pointers (including virtual functions) to
  execute correctly regardless of whether the target code has been
  compiled for interworking or not.  There is a small overhead in the cost
  of executing a function pointer if this option is enabled.  This option
! is not valid in \s-1AAPCS\s0 configurations because interworking is enabled
  by default.
! .IP "\fB\-mtp=\fR\fIname\fR" 4
  .IX Item "-mtp=name"
  Specify the access model for the thread local storage pointer.  The valid
  models are \fBsoft\fR, which generates calls to \f(CW\*(C`_\|_aeabi_read_tp\*(C'\fR,
--- 21781,21831 ----
  location \f(CW\*(C`pc \- 12\*(C'\fR and the top 8 bits are set, then we know that
  there is a function name embedded immediately preceding this location
  and has length \f(CW\*(C`((pc[\-3]) & 0xff000000)\*(C'\fR.
! .IP \fB\-mthumb\fR 4
  .IX Item "-mthumb"
  .PD 0
! .IP \fB\-marm\fR 4
  .IX Item "-marm"
  .PD
! Select between generating code that executes in ARM and Thumb
  states.  The default for most configurations is to generate code
! that executes in ARM state, but the default can be changed by
! configuring GCC with the \fB\-\-with\-mode=\fR\fIstate\fR
  configure option.
  .Sp
! You can also override the ARM and Thumb mode for each function
! by using the \f(CWtarget("thumb")\fR and \f(CWtarget("arm")\fR function attributes or pragmas.
! .IP \fB\-mflip\-thumb\fR 4
  .IX Item "-mflip-thumb"
  Switch ARM/Thumb modes on alternating functions.
  This option is provided for regression testing of mixed Thumb/ARM code
  generation, and is not intended for ordinary use in compiling code.
! .IP \fB\-mtpcs\-frame\fR 4
  .IX Item "-mtpcs-frame"
  Generate a stack frame that is compliant with the Thumb Procedure Call
! Standard for all non\-leaf functions.  (A leaf function is one that does
  not call any other functions.)  The default is \fB\-mno\-tpcs\-frame\fR.
! .IP \fB\-mtpcs\-leaf\-frame\fR 4
  .IX Item "-mtpcs-leaf-frame"
  Generate a stack frame that is compliant with the Thumb Procedure Call
  Standard for all leaf functions.  (A leaf function is one that does
  not call any other functions.)  The default is \fB\-mno\-apcs\-leaf\-frame\fR.
! .IP \fB\-mcallee\-super\-interworking\fR 4
  .IX Item "-mcallee-super-interworking"
! Gives all externally visible functions in the file being compiled an 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.
! .IP \fB\-mcaller\-super\-interworking\fR 4
  .IX Item "-mcaller-super-interworking"
  Allows calls via function pointers (including virtual functions) to
  execute correctly regardless of whether the target code has been
  compiled for interworking or not.  There is a small overhead in the cost
  of executing a function pointer if this option is enabled.  This option
! is not valid in AAPCS configurations because interworking is enabled
  by default.
! .IP \fB\-mtp=\fR\fIname\fR 4
  .IX Item "-mtp=name"
  Specify the access model for the thread local storage pointer.  The valid
  models are \fBsoft\fR, which generates calls to \f(CW\*(C`_\|_aeabi_read_tp\*(C'\fR,
*************** models are \fBsoft\fR, which generates c
*** 21902,21948 ****
  (supported in the arm6k architecture), and \fBauto\fR, which uses the
  best available method for the selected processor.  The default setting is
  \&\fBauto\fR.
! .IP "\fB\-mtls\-dialect=\fR\fIdialect\fR" 4
  .IX Item "-mtls-dialect=dialect"
  Specify the dialect to use for accessing thread local storage.  Two
  \&\fIdialect\fRs are supported\-\-\-\fBgnu\fR and \fBgnu2\fR.  The
! \&\fBgnu\fR dialect selects the original \s-1GNU\s0 scheme for supporting
! local and global dynamic \s-1TLS\s0 models.  The \fBgnu2\fR dialect
! selects the \s-1GNU\s0 descriptor scheme, which provides better performance
! for shared libraries.  The \s-1GNU\s0 descriptor scheme is compatible with
  the original scheme, but does require new assembler, linker and
! library support.  Initial and local exec \s-1TLS\s0 models are unaffected by
  this option and always use the original scheme.
! .IP "\fB\-mword\-relocations\fR" 4
  .IX Item "-mword-relocations"
! Only generate absolute relocations on word-sized values (i.e. R_ARM_ABS32).
  This is enabled by default on targets (uClinux, SymbianOS) where the runtime
  loader imposes this restriction, and when \fB\-fpic\fR or \fB\-fPIC\fR
  is specified. This option conflicts with \fB\-mslow\-flash\-data\fR.
! .IP "\fB\-mfix\-cortex\-m3\-ldrd\fR" 4
  .IX Item "-mfix-cortex-m3-ldrd"
  Some Cortex\-M3 cores can cause data corruption when \f(CW\*(C`ldrd\*(C'\fR instructions
  with overlapping destination and base registers are used.  This option avoids
  generating these instructions.  This option is enabled by default when
  \&\fB\-mcpu=cortex\-m3\fR is specified.
! .IP "\fB\-mfix\-cortex\-a57\-aes\-1742098\fR" 4
  .IX Item "-mfix-cortex-a57-aes-1742098"
  .PD 0
! .IP "\fB\-mno\-fix\-cortex\-a57\-aes\-1742098\fR" 4
  .IX Item "-mno-fix-cortex-a57-aes-1742098"
! .IP "\fB\-mfix\-cortex\-a72\-aes\-1655431\fR" 4
  .IX Item "-mfix-cortex-a72-aes-1655431"
! .IP "\fB\-mno\-fix\-cortex\-a72\-aes\-1655431\fR" 4
  .IX Item "-mno-fix-cortex-a72-aes-1655431"
  .PD
  Enable (disable) mitigation for an erratum on Cortex\-A57 and
! Cortex\-A72 that affects the \s-1AES\s0 cryptographic instructions.  This
  option is enabled by default when either \fB\-mcpu=cortex\-a57\fR or
  \&\fB\-mcpu=cortex\-a72\fR is specified.
! .IP "\fB\-munaligned\-access\fR" 4
  .IX Item "-munaligned-access"
  .PD 0
! .IP "\fB\-mno\-unaligned\-access\fR" 4
  .IX Item "-mno-unaligned-access"
  .PD
  Enables (or disables) reading and writing of 16\- and 32\- bit values
--- 21833,21879 ----
  (supported in the arm6k architecture), and \fBauto\fR, which uses the
  best available method for the selected processor.  The default setting is
  \&\fBauto\fR.
! .IP \fB\-mtls\-dialect=\fR\fIdialect\fR 4
  .IX Item "-mtls-dialect=dialect"
  Specify the dialect to use for accessing thread local storage.  Two
  \&\fIdialect\fRs are supported\-\-\-\fBgnu\fR and \fBgnu2\fR.  The
! \&\fBgnu\fR dialect selects the original GNU scheme for supporting
! local and global dynamic TLS models.  The \fBgnu2\fR dialect
! selects the GNU descriptor scheme, which provides better performance
! for shared libraries.  The GNU descriptor scheme is compatible with
  the original scheme, but does require new assembler, linker and
! library support.  Initial and local exec TLS models are unaffected by
  this option and always use the original scheme.
! .IP \fB\-mword\-relocations\fR 4
  .IX Item "-mword-relocations"
! Only generate absolute relocations on word\-sized values (i.e. R_ARM_ABS32).
  This is enabled by default on targets (uClinux, SymbianOS) where the runtime
  loader imposes this restriction, and when \fB\-fpic\fR or \fB\-fPIC\fR
  is specified. This option conflicts with \fB\-mslow\-flash\-data\fR.
! .IP \fB\-mfix\-cortex\-m3\-ldrd\fR 4
  .IX Item "-mfix-cortex-m3-ldrd"
  Some Cortex\-M3 cores can cause data corruption when \f(CW\*(C`ldrd\*(C'\fR instructions
  with overlapping destination and base registers are used.  This option avoids
  generating these instructions.  This option is enabled by default when
  \&\fB\-mcpu=cortex\-m3\fR is specified.
! .IP \fB\-mfix\-cortex\-a57\-aes\-1742098\fR 4
  .IX Item "-mfix-cortex-a57-aes-1742098"
  .PD 0
! .IP \fB\-mno\-fix\-cortex\-a57\-aes\-1742098\fR 4
  .IX Item "-mno-fix-cortex-a57-aes-1742098"
! .IP \fB\-mfix\-cortex\-a72\-aes\-1655431\fR 4
  .IX Item "-mfix-cortex-a72-aes-1655431"
! .IP \fB\-mno\-fix\-cortex\-a72\-aes\-1655431\fR 4
  .IX Item "-mno-fix-cortex-a72-aes-1655431"
  .PD
  Enable (disable) mitigation for an erratum on Cortex\-A57 and
! Cortex\-A72 that affects the AES cryptographic instructions.  This
  option is enabled by default when either \fB\-mcpu=cortex\-a57\fR or
  \&\fB\-mcpu=cortex\-a72\fR is specified.
! .IP \fB\-munaligned\-access\fR 4
  .IX Item "-munaligned-access"
  .PD 0
! .IP \fB\-mno\-unaligned\-access\fR 4
  .IX Item "-mno-unaligned-access"
  .PD
  Enables (or disables) reading and writing of 16\- and 32\- bit values
*************** ARMv8\-M Baseline architectures, and ena
*** 21952,22044 ****
  architectures.  If unaligned access is not enabled then words in packed
  data structures are accessed a byte at a time.
  .Sp
! The \s-1ARM\s0 attribute \f(CW\*(C`Tag_CPU_unaligned_access\*(C'\fR is set in the
  generated object file to either true or false, depending upon the
  setting of this option.  If unaligned access is enabled then the
  preprocessor symbol \f(CW\*(C`_\|_ARM_FEATURE_UNALIGNED\*(C'\fR is also
  defined.
! .IP "\fB\-mneon\-for\-64bits\fR" 4
  .IX Item "-mneon-for-64bits"
  This option is deprecated and has no effect.
! .IP "\fB\-mslow\-flash\-data\fR" 4
  .IX Item "-mslow-flash-data"
  Assume loading data from flash is slower than fetching instruction.
  Therefore literal load is minimized for better performance.
  This option is only supported when compiling for ARMv7 M\-profile and
  off by default. It conflicts with \fB\-mword\-relocations\fR.
! .IP "\fB\-masm\-syntax\-unified\fR" 4
  .IX Item "-masm-syntax-unified"
  Assume inline assembler is using unified asm syntax.  The default is
  currently off which implies divided syntax.  This option has no impact
! on Thumb2. However, this may change in future releases of \s-1GCC.\s0
  Divided syntax should be considered deprecated.
! .IP "\fB\-mrestrict\-it\fR" 4
  .IX Item "-mrestrict-it"
! Restricts generation of \s-1IT\s0 blocks to conform to the rules of ARMv8\-A.
! \&\s-1IT\s0 blocks can only contain a single 16\-bit instruction from a select
  set of instructions. This option is on by default for ARMv8\-A Thumb mode.
! .IP "\fB\-mprint\-tune\-info\fR" 4
  .IX Item "-mprint-tune-info"
! Print \s-1CPU\s0 tuning information as comment in assembler file.  This is
  an option used only for regression testing of the compiler and not
  intended for ordinary use in compiling code.  This option is disabled
  by default.
! .IP "\fB\-mverbose\-cost\-dump\fR" 4
  .IX Item "-mverbose-cost-dump"
  Enable verbose cost model dumping in the debug dump files.  This option is
  provided for use in debugging the compiler.
! .IP "\fB\-mpure\-code\fR" 4
  .IX Item "-mpure-code"
  Do not allow constant data to be placed in code sections.
! Additionally, when compiling for \s-1ELF\s0 object format give all text sections the
! \&\s-1ELF\s0 processor-specific section attribute \f(CW\*(C`SHF_ARM_PURECODE\*(C'\fR.  This option
! is only available when generating non-pic code for M\-profile targets.
! .IP "\fB\-mcmse\fR" 4
  .IX Item "-mcmse"
! Generate secure code as per the \*(L"ARMv8\-M Security Extensions: Requirements on
! Development Tools Engineering Specification\*(R", which can be found on
  <\fBhttps://developer.arm.com/documentation/ecm0359818/latest/\fR>.
! .IP "\fB\-mfix\-cmse\-cve\-2021\-35465\fR" 4
  .IX Item "-mfix-cmse-cve-2021-35465"
  Mitigate against a potential security issue with the \f(CW\*(C`VLLDM\*(C'\fR instruction
! in some M\-profile devices when using \s-1CMSE\s0 (\s-1CVE\-2021\-365465\s0).  This option is
  enabled by default when the option \fB\-mcpu=\fR is used with
  \&\f(CW\*(C`cortex\-m33\*(C'\fR, \f(CW\*(C`cortex\-m35p\*(C'\fR, \f(CW\*(C`cortex\-m55\*(C'\fR, \f(CW\*(C`cortex\-m85\*(C'\fR
  or \f(CW\*(C`star\-mc1\*(C'\fR. The option \fB\-mno\-fix\-cmse\-cve\-2021\-35465\fR can be used
  to disable the mitigation.
! .IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP "\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR" 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
  locations are \fBglobal\fR for a global canary or \fBtls\fR for a
! canary accessible via the \s-1TLS\s0 register. The option
  \&\fB\-mstack\-protector\-guard\-offset=\fR is for use with
! \&\fB\-fstack\-protector\-guard=tls\fR and not for use in user-land code.
! .IP "\fB\-mfdpic\fR" 4
  .IX Item "-mfdpic"
  .PD 0
! .IP "\fB\-mno\-fdpic\fR" 4
  .IX Item "-mno-fdpic"
  .PD
! Select the \s-1FDPIC ABI,\s0 which uses 64\-bit function descriptors to
  represent pointers to functions.  When the compiler is configured for
  \&\f(CW\*(C`arm\-*\-uclinuxfdpiceabi\*(C'\fR targets, this option is on by default
  and implies \fB\-fPIE\fR if none of the PIC/PIE\-related options is
! provided.  On other targets, it only enables the FDPIC-specific code
  generation features, and the user should explicitly provide the
  PIC/PIE\-related options as needed.
  .Sp
  Note that static linking is not supported because it would still
! involve the dynamic linker when the program self-relocates.  If such
  behavior is acceptable, use \-static and \-Wl,\-dynamic\-linker options.
  .Sp
  The opposite \fB\-mno\-fdpic\fR option is useful (and required) to
  build the Linux kernel using the same (\f(CW\*(C`arm\-*\-uclinuxfdpiceabi\*(C'\fR)
  toolchain as the one used to build the userland programs.
! .IP "\fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR\fB][+\fR\fIbti\fR\fB]|\fR\fIbti\fR\fB[+\fR\fIpac-ret\fR\fB[+\fR\fIleaf\fR\fB]]\fR" 4
  .IX Item "-mbranch-protection=none|standard|pac-ret[+leaf][+bti]|bti[+pac-ret[+leaf]]"
  Enable branch protection features (armv8.1\-m.main only).
  \&\fBnone\fR generate code without branch protection or return address
--- 21883,21975 ----
  architectures.  If unaligned access is not enabled then words in packed
  data structures are accessed a byte at a time.
  .Sp
! The ARM attribute \f(CW\*(C`Tag_CPU_unaligned_access\*(C'\fR is set in the
  generated object file to either true or false, depending upon the
  setting of this option.  If unaligned access is enabled then the
  preprocessor symbol \f(CW\*(C`_\|_ARM_FEATURE_UNALIGNED\*(C'\fR is also
  defined.
! .IP \fB\-mneon\-for\-64bits\fR 4
  .IX Item "-mneon-for-64bits"
  This option is deprecated and has no effect.
! .IP \fB\-mslow\-flash\-data\fR 4
  .IX Item "-mslow-flash-data"
  Assume loading data from flash is slower than fetching instruction.
  Therefore literal load is minimized for better performance.
  This option is only supported when compiling for ARMv7 M\-profile and
  off by default. It conflicts with \fB\-mword\-relocations\fR.
! .IP \fB\-masm\-syntax\-unified\fR 4
  .IX Item "-masm-syntax-unified"
  Assume inline assembler is using unified asm syntax.  The default is
  currently off which implies divided syntax.  This option has no impact
! on Thumb2. However, this may change in future releases of GCC.
  Divided syntax should be considered deprecated.
! .IP \fB\-mrestrict\-it\fR 4
  .IX Item "-mrestrict-it"
! Restricts generation of IT blocks to conform to the rules of ARMv8\-A.
! IT blocks can only contain a single 16\-bit instruction from a select
  set of instructions. This option is on by default for ARMv8\-A Thumb mode.
! .IP \fB\-mprint\-tune\-info\fR 4
  .IX Item "-mprint-tune-info"
! Print CPU tuning information as comment in assembler file.  This is
  an option used only for regression testing of the compiler and not
  intended for ordinary use in compiling code.  This option is disabled
  by default.
! .IP \fB\-mverbose\-cost\-dump\fR 4
  .IX Item "-mverbose-cost-dump"
  Enable verbose cost model dumping in the debug dump files.  This option is
  provided for use in debugging the compiler.
! .IP \fB\-mpure\-code\fR 4
  .IX Item "-mpure-code"
  Do not allow constant data to be placed in code sections.
! Additionally, when compiling for ELF object format give all text sections the
! ELF processor\-specific section attribute \f(CW\*(C`SHF_ARM_PURECODE\*(C'\fR.  This option
! is only available when generating non\-pic code for M\-profile targets.
! .IP \fB\-mcmse\fR 4
  .IX Item "-mcmse"
! Generate secure code as per the "ARMv8\-M Security Extensions: Requirements on
! Development Tools Engineering Specification", which can be found on
  <\fBhttps://developer.arm.com/documentation/ecm0359818/latest/\fR>.
! .IP \fB\-mfix\-cmse\-cve\-2021\-35465\fR 4
  .IX Item "-mfix-cmse-cve-2021-35465"
  Mitigate against a potential security issue with the \f(CW\*(C`VLLDM\*(C'\fR instruction
! in some M\-profile devices when using CMSE (CVE\-2021\-365465).  This option is
  enabled by default when the option \fB\-mcpu=\fR is used with
  \&\f(CW\*(C`cortex\-m33\*(C'\fR, \f(CW\*(C`cortex\-m35p\*(C'\fR, \f(CW\*(C`cortex\-m55\*(C'\fR, \f(CW\*(C`cortex\-m85\*(C'\fR
  or \f(CW\*(C`star\-mc1\*(C'\fR. The option \fB\-mno\-fix\-cmse\-cve\-2021\-35465\fR can be used
  to disable the mitigation.
! .IP \fB\-mstack\-protector\-guard=\fR\fIguard\fR 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
  locations are \fBglobal\fR for a global canary or \fBtls\fR for a
! canary accessible via the TLS register. The option
  \&\fB\-mstack\-protector\-guard\-offset=\fR is for use with
! \&\fB\-fstack\-protector\-guard=tls\fR and not for use in user\-land code.
! .IP \fB\-mfdpic\fR 4
  .IX Item "-mfdpic"
  .PD 0
! .IP \fB\-mno\-fdpic\fR 4
  .IX Item "-mno-fdpic"
  .PD
! Select the FDPIC ABI, which uses 64\-bit function descriptors to
  represent pointers to functions.  When the compiler is configured for
  \&\f(CW\*(C`arm\-*\-uclinuxfdpiceabi\*(C'\fR targets, this option is on by default
  and implies \fB\-fPIE\fR if none of the PIC/PIE\-related options is
! provided.  On other targets, it only enables the FDPIC\-specific code
  generation features, and the user should explicitly provide the
  PIC/PIE\-related options as needed.
  .Sp
  Note that static linking is not supported because it would still
! involve the dynamic linker when the program self\-relocates.  If such
  behavior is acceptable, use \-static and \-Wl,\-dynamic\-linker options.
  .Sp
  The opposite \fB\-mno\-fdpic\fR option is useful (and required) to
  build the Linux kernel using the same (\f(CW\*(C`arm\-*\-uclinuxfdpiceabi\*(C'\fR)
  toolchain as the one used to build the userland programs.
! .IP \fB\-mbranch\-protection=\fR\fInone\fR\fB|\fR\fIstandard\fR\fB|\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR\fB][+\fR\fIbti\fR\fB]|\fR\fIbti\fR\fB[+\fR\fIpac\-ret\fR\fB[+\fR\fIleaf\fR\fB]]\fR 4
  .IX Item "-mbranch-protection=none|standard|pac-ret[+leaf][+bti]|bti[+pac-ret[+leaf]]"
  Enable branch protection features (armv8.1\-m.main only).
  \&\fBnone\fR generate code without branch protection or return address
*************** set to its standard level, which is to s
*** 22050,22067 ****
  the return address to memory.
  \&\fBleaf\fR When return address signing is enabled, also sign leaf
  functions even if they do not write the return address to memory.
! +\fBbti\fR Add landing-pad instructions at the permitted targets of
  indirect branch instructions.
  .Sp
  If the \fB+pacbti\fR architecture extension is not enabled, then all
  branch protection and return address signing operations are
  constrained to use only the instructions defined in the
! architectural-NOP space. The generated code will remain
! backwards-compatible with earlier versions of the architecture, but
  the additional security can be enabled at run time on processors that
! support the \fB\s-1PACBTI\s0\fR extension.
  .Sp
! Branch target enforcement using \s-1BTI\s0 can only be enabled at runtime if
  all code in the application has been compiled with at least
  \&\fB\-mbranch\-protection=bti\fR.
  .Sp
--- 21981,21998 ----
  the return address to memory.
  \&\fBleaf\fR When return address signing is enabled, also sign leaf
  functions even if they do not write the return address to memory.
! +\fBbti\fR Add landing\-pad instructions at the permitted targets of
  indirect branch instructions.
  .Sp
  If the \fB+pacbti\fR architecture extension is not enabled, then all
  branch protection and return address signing operations are
  constrained to use only the instructions defined in the
! architectural\-NOP space. The generated code will remain
! backwards\-compatible with earlier versions of the architecture, but
  the additional security can be enabled at run time on processors that
! support the \fBPACBTI\fR extension.
  .Sp
! Branch target enforcement using BTI can only be enabled at runtime if
  all code in the application has been compiled with at least
  \&\fB\-mbranch\-protection=bti\fR.
  .Sp
*************** or later.
*** 22071,22191 ****
  The default is to generate code without branch protection or return
  address signing.
  .PP
! \fI\s-1AVR\s0 Options\fR
  .IX Subsection "AVR Options"
  .PP
! These options are defined for \s-1AVR\s0 implementations:
! .IP "\fB\-mmcu=\fR\fImcu\fR" 4
  .IX Item "-mmcu=mcu"
! Specify the \s-1AVR\s0 instruction set architecture (\s-1ISA\s0) or device type.
  The default for this option is \f(CW\*(C`avr2\*(C'\fR.
  .Sp
! The following \s-1AVR\s0 devices and ISAs are supported.
  \&\fINote:\fR A complete device support consists of
! startup code \f(CW\*(C`crt\f(CImcu\f(CW.o\*(C'\fR, a device header \f(CW\*(C`avr/io*.h\*(C'\fR,
! a device library \f(CW\*(C`lib\f(CImcu\f(CW.a\*(C'\fR and a
! device-specs (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#spec\-files\*(C'\fR) file
! \&\f(CW\*(C`specs\-\f(CImcu\f(CW\*(C'\fR. Only the latter is provided by the compiler
! according the supported \f(CW\*(C`\f(CImcu\f(CW\*(C'\fRs below.  The rest is supported
! by AVR-LibC (\f(CW\*(C`https://www.nongnu.org/avr\-libc/\*(C'\fR), or by means of
  \&\f(CW\*(C`atpack\*(C'\fR (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#atpack\*(C'\fR) files
  from the hardware manufacturer.
  .RS 4
  .ie n .IP """avr2""" 4
! .el .IP "\f(CWavr2\fR" 4
  .IX Item "avr2"
! \&\*(L"Classic\*(R" devices with up to 8 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`attiny22\*(C'\fR, \f(CW\*(C`attiny26\*(C'\fR, \f(CW\*(C`at90s2313\*(C'\fR, \f(CW\*(C`at90s2323\*(C'\fR, \f(CW\*(C`at90s2333\*(C'\fR, \f(CW\*(C`at90s2343\*(C'\fR, \f(CW\*(C`at90s4414\*(C'\fR, \f(CW\*(C`at90s4433\*(C'\fR, \f(CW\*(C`at90s4434\*(C'\fR, \f(CW\*(C`at90c8534\*(C'\fR, \f(CW\*(C`at90s8515\*(C'\fR, \f(CW\*(C`at90s8535\*(C'\fR.
  .ie n .IP """avr25""" 4
! .el .IP "\f(CWavr25\fR" 4
  .IX Item "avr25"
! \&\*(L"Classic\*(R" devices with up to 8 KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
  \&\fImcu\fR = \f(CW\*(C`attiny13\*(C'\fR, \f(CW\*(C`attiny13a\*(C'\fR, \f(CW\*(C`attiny24\*(C'\fR, \f(CW\*(C`attiny24a\*(C'\fR, \f(CW\*(C`attiny25\*(C'\fR, \f(CW\*(C`attiny261\*(C'\fR, \f(CW\*(C`attiny261a\*(C'\fR, \f(CW\*(C`attiny2313\*(C'\fR, \f(CW\*(C`attiny2313a\*(C'\fR, \f(CW\*(C`attiny43u\*(C'\fR, \f(CW\*(C`attiny44\*(C'\fR, \f(CW\*(C`attiny44a\*(C'\fR, \f(CW\*(C`attiny45\*(C'\fR, \f(CW\*(C`attiny48\*(C'\fR, \f(CW\*(C`attiny441\*(C'\fR, \f(CW\*(C`attiny461\*(C'\fR, \f(CW\*(C`attiny461a\*(C'\fR, \f(CW\*(C`attiny4313\*(C'\fR, \f(CW\*(C`attiny84\*(C'\fR, \f(CW\*(C`attiny84a\*(C'\fR, \f(CW\*(C`attiny85\*(C'\fR, \f(CW\*(C`attiny87\*(C'\fR, \f(CW\*(C`attiny88\*(C'\fR, \f(CW\*(C`attiny828\*(C'\fR, \f(CW\*(C`attiny841\*(C'\fR, \f(CW\*(C`attiny861\*(C'\fR, \f(CW\*(C`attiny861a\*(C'\fR, \f(CW\*(C`ata5272\*(C'\fR, \f(CW\*(C`ata6616c\*(C'\fR, \f(CW\*(C`at86rf401\*(C'\fR.
  .ie n .IP """avr3""" 4
! .el .IP "\f(CWavr3\fR" 4
  .IX Item "avr3"
! \&\*(L"Classic\*(R" devices with 16 KiB up to 64 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`at76c711\*(C'\fR, \f(CW\*(C`at43usb355\*(C'\fR.
  .ie n .IP """avr31""" 4
! .el .IP "\f(CWavr31\fR" 4
  .IX Item "avr31"
! \&\*(L"Classic\*(R" devices with 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega103\*(C'\fR, \f(CW\*(C`at43usb320\*(C'\fR.
  .ie n .IP """avr35""" 4
! .el .IP "\f(CWavr35\fR" 4
  .IX Item "avr35"
! \&\*(L"Classic\*(R" devices with 16 KiB up to 64 KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
  \&\fImcu\fR = \f(CW\*(C`attiny167\*(C'\fR, \f(CW\*(C`attiny1634\*(C'\fR, \f(CW\*(C`atmega8u2\*(C'\fR, \f(CW\*(C`atmega16u2\*(C'\fR, \f(CW\*(C`atmega32u2\*(C'\fR, \f(CW\*(C`ata5505\*(C'\fR, \f(CW\*(C`ata6617c\*(C'\fR, \f(CW\*(C`ata664251\*(C'\fR, \f(CW\*(C`at90usb82\*(C'\fR, \f(CW\*(C`at90usb162\*(C'\fR.
  .ie n .IP """avr4""" 4
! .el .IP "\f(CWavr4\fR" 4
  .IX Item "avr4"
! \&\*(L"Enhanced\*(R" devices with up to 8 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega48\*(C'\fR, \f(CW\*(C`atmega48a\*(C'\fR, \f(CW\*(C`atmega48p\*(C'\fR, \f(CW\*(C`atmega48pa\*(C'\fR, \f(CW\*(C`atmega48pb\*(C'\fR, \f(CW\*(C`atmega8\*(C'\fR, \f(CW\*(C`atmega8a\*(C'\fR, \f(CW\*(C`atmega8hva\*(C'\fR, \f(CW\*(C`atmega88\*(C'\fR, \f(CW\*(C`atmega88a\*(C'\fR, \f(CW\*(C`atmega88p\*(C'\fR, \f(CW\*(C`atmega88pa\*(C'\fR, \f(CW\*(C`atmega88pb\*(C'\fR, \f(CW\*(C`atmega8515\*(C'\fR, \f(CW\*(C`atmega8535\*(C'\fR, \f(CW\*(C`ata5795\*(C'\fR, \f(CW\*(C`ata6285\*(C'\fR, \f(CW\*(C`ata6286\*(C'\fR, \f(CW\*(C`ata6289\*(C'\fR, \f(CW\*(C`ata6612c\*(C'\fR, \f(CW\*(C`at90pwm1\*(C'\fR, \f(CW\*(C`at90pwm2\*(C'\fR, \f(CW\*(C`at90pwm2b\*(C'\fR, \f(CW\*(C`at90pwm3\*(C'\fR, \f(CW\*(C`at90pwm3b\*(C'\fR, \f(CW\*(C`at90pwm81\*(C'\fR.
  .ie n .IP """avr5""" 4
! .el .IP "\f(CWavr5\fR" 4
  .IX Item "avr5"
! \&\*(L"Enhanced\*(R" devices with 16 KiB up to 64 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega16\*(C'\fR, \f(CW\*(C`atmega16a\*(C'\fR, \f(CW\*(C`atmega16hva\*(C'\fR, \f(CW\*(C`atmega16hva2\*(C'\fR, \f(CW\*(C`atmega16hvb\*(C'\fR, \f(CW\*(C`atmega16hvbrevb\*(C'\fR, \f(CW\*(C`atmega16m1\*(C'\fR, \f(CW\*(C`atmega16u4\*(C'\fR, \f(CW\*(C`atmega161\*(C'\fR, \f(CW\*(C`atmega162\*(C'\fR, \f(CW\*(C`atmega163\*(C'\fR, \f(CW\*(C`atmega164a\*(C'\fR, \f(CW\*(C`atmega164p\*(C'\fR, \f(CW\*(C`atmega164pa\*(C'\fR, \f(CW\*(C`atmega165\*(C'\fR, \f(CW\*(C`atmega165a\*(C'\fR, \f(CW\*(C`atmega165p\*(C'\fR, \f(CW\*(C`atmega165pa\*(C'\fR, \f(CW\*(C`atmega168\*(C'\fR, \f(CW\*(C`atmega168a\*(C'\fR, \f(CW\*(C`atmega168p\*(C'\fR, \f(CW\*(C`atmega168pa\*(C'\fR, \f(CW\*(C`atmega168pb\*(C'\fR, \f(CW\*(C`atmega169\*(C'\fR, \f(CW\*(C`atmega169a\*(C'\fR, \f(CW\*(C`atmega169p\*(C'\fR, \f(CW\*(C`atmega169pa\*(C'\fR, \f(CW\*(C`atmega32\*(C'\fR, \f(CW\*(C`atmega32a\*(C'\fR, \f(CW\*(C`atmega32c1\*(C'\fR, \f(CW\*(C`atmega32hvb\*(C'\fR, \f(CW\*(C`atmega32hvbrevb\*(C'\fR, \f(CW\*(C`atmega32m1\*(C'\fR, \f(CW\*(C`atmega32u4\*(C'\fR, \f(CW\*(C`atmega32u6\*(C'\fR, \f(CW\*(C`atmega323\*(C'\fR, \f(CW\*(C`atmega324a\*(C'\fR, \f(CW\*(C`atmega324p\*(C'\fR, \f(CW\*(C`atmega324pa\*(C'\fR, \f(CW\*(C`atmega324pb\*(C'\fR, \f(CW\*(C`atmega325\*(C'\fR, \f(CW\*(C`atmega325a\*(C'\fR, \f(CW\*(C`atmega325p\*(C'\fR, \f(CW\*(C`atmega325pa\*(C'\fR, \f(CW\*(C`atmega328\*(C'\fR, \f(CW\*(C`atmega328p\*(C'\fR, \f(CW\*(C`atmega328pb\*(C'\fR, \f(CW\*(C`atmega329\*(C'\fR, \f(CW\*(C`atmega329a\*(C'\fR, \f(CW\*(C`atmega329p\*(C'\fR, \f(CW\*(C`atmega329pa\*(C'\fR, \f(CW\*(C`atmega3250\*(C'\fR, \f(CW\*(C`atmega3250a\*(C'\fR, \f(CW\*(C`atmega3250p\*(C'\fR, \f(CW\*(C`atmega3250pa\*(C'\fR, \f(CW\*(C`atmega3290\*(C'\fR, \f(CW\*(C`atmega3290a\*(C'\fR, \f(CW\*(C`atmega3290p\*(C'\fR, \f(CW\*(C`atmega3290pa\*(C'\fR, \f(CW\*(C`atmega406\*(C'\fR, \f(CW\*(C`atmega64\*(C'\fR, \f(CW\*(C`atmega64a\*(C'\fR, \f(CW\*(C`atmega64c1\*(C'\fR, \f(CW\*(C`atmega64hve\*(C'\fR, \f(CW\*(C`atmega64hve2\*(C'\fR, \f(CW\*(C`atmega64m1\*(C'\fR, \f(CW\*(C`atmega64rfr2\*(C'\fR, \f(CW\*(C`atmega640\*(C'\fR, \f(CW\*(C`atmega644\*(C'\fR, \f(CW\*(C`atmega644a\*(C'\fR, \f(CW\*(C`atmega644p\*(C'\fR, \f(CW\*(C`atmega644pa\*(C'\fR, \f(CW\*(C`atmega644rfr2\*(C'\fR, \f(CW\*(C`atmega645\*(C'\fR, \f(CW\*(C`atmega645a\*(C'\fR, \f(CW\*(C`atmega645p\*(C'\fR, \f(CW\*(C`atmega649\*(C'\fR, \f(CW\*(C`atmega649a\*(C'\fR, \f(CW\*(C`atmega649p\*(C'\fR, \f(CW\*(C`atmega6450\*(C'\fR, \f(CW\*(C`atmega6450a\*(C'\fR, \f(CW\*(C`atmega6450p\*(C'\fR, \f(CW\*(C`atmega6490\*(C'\fR, \f(CW\*(C`atmega6490a\*(C'\fR, \f(CW\*(C`atmega6490p\*(C'\fR, \f(CW\*(C`ata5790\*(C'\fR, \f(CW\*(C`ata5790n\*(C'\fR, \f(CW\*(C`ata5791\*(C'\fR, \f(CW\*(C`ata6613c\*(C'\fR, \f(CW\*(C`ata6614q\*(C'\fR, \f(CW\*(C`ata5782\*(C'\fR, \f(CW\*(C`ata5831\*(C'\fR, \f(CW\*(C`ata8210\*(C'\fR, \f(CW\*(C`ata8510\*(C'\fR, \f(CW\*(C`ata5787\*(C'\fR, \f(CW\*(C`ata5835\*(C'\fR, \f(CW\*(C`ata5700m322\*(C'\fR, \f(CW\*(C`ata5702m322\*(C'\fR, \f(CW\*(C`at90pwm161\*(C'\fR, \f(CW\*(C`at90pwm216\*(C'\fR, \f(CW\*(C`at90pwm316\*(C'\fR, \f(CW\*(C`at90can32\*(C'\fR, \f(CW\*(C`at90can64\*(C'\fR, \f(CW\*(C`at90scr100\*(C'\fR, \f(CW\*(C`at90usb646\*(C'\fR, \f(CW\*(C`at90usb647\*(C'\fR, \f(CW\*(C`at94k\*(C'\fR, \f(CW\*(C`m3000\*(C'\fR.
  .ie n .IP """avr51""" 4
! .el .IP "\f(CWavr51\fR" 4
  .IX Item "avr51"
! \&\*(L"Enhanced\*(R" devices with 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega128\*(C'\fR, \f(CW\*(C`atmega128a\*(C'\fR, \f(CW\*(C`atmega128rfa1\*(C'\fR, \f(CW\*(C`atmega128rfr2\*(C'\fR, \f(CW\*(C`atmega1280\*(C'\fR, \f(CW\*(C`atmega1281\*(C'\fR, \f(CW\*(C`atmega1284\*(C'\fR, \f(CW\*(C`atmega1284p\*(C'\fR, \f(CW\*(C`atmega1284rfr2\*(C'\fR, \f(CW\*(C`at90can128\*(C'\fR, \f(CW\*(C`at90usb1286\*(C'\fR, \f(CW\*(C`at90usb1287\*(C'\fR.
  .ie n .IP """avr6""" 4
! .el .IP "\f(CWavr6\fR" 4
  .IX Item "avr6"
! \&\*(L"Enhanced\*(R" devices with 3\-byte \s-1PC,\s0 i.e. with more than 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega256rfr2\*(C'\fR, \f(CW\*(C`atmega2560\*(C'\fR, \f(CW\*(C`atmega2561\*(C'\fR, \f(CW\*(C`atmega2564rfr2\*(C'\fR.
  .ie n .IP """avrxmega2""" 4
! .el .IP "\f(CWavrxmega2\fR" 4
  .IX Item "avrxmega2"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 8 KiB and up to 64 KiB of program memory.
! \&\fImcu\fR = \f(CW\*(C`atxmega8e5\*(C'\fR, \f(CW\*(C`atxmega16a4\*(C'\fR, \f(CW\*(C`atxmega16a4u\*(C'\fR, \f(CW\*(C`atxmega16c4\*(C'\fR, \f(CW\*(C`atxmega16d4\*(C'\fR, \f(CW\*(C`atxmega16e5\*(C'\fR, \f(CW\*(C`atxmega32a4\*(C'\fR, \f(CW\*(C`atxmega32a4u\*(C'\fR, \f(CW\*(C`atxmega32c3\*(C'\fR, \f(CW\*(C`atxmega32c4\*(C'\fR, \f(CW\*(C`atxmega32d3\*(C'\fR, \f(CW\*(C`atxmega32d4\*(C'\fR, \f(CW\*(C`atxmega32e5\*(C'\fR, \f(CW\*(C`avr64da28\*(C'\fR, \f(CW\*(C`avr64da32\*(C'\fR, \f(CW\*(C`avr64da48\*(C'\fR, \f(CW\*(C`avr64da64\*(C'\fR, \f(CW\*(C`avr64db28\*(C'\fR, \f(CW\*(C`avr64db32\*(C'\fR, \f(CW\*(C`avr64db48\*(C'\fR, \f(CW\*(C`avr64db64\*(C'\fR, \f(CW\*(C`avr64dd14\*(C'\fR, \f(CW\*(C`avr64dd20\*(C'\fR, \f(CW\*(C`avr64dd28\*(C'\fR, \f(CW\*(C`avr64dd32\*(C'\fR, \f(CW\*(C`avr64du28\*(C'\fR, \f(CW\*(C`avr64du32\*(C'\fR, \f(CW\*(C`avr64ea28\*(C'\fR, \f(CW\*(C`avr64ea32\*(C'\fR, \f(CW\*(C`avr64ea48\*(C'\fR, \f(CW\*(C`avr64sd28\*(C'\fR, \f(CW\*(C`avr64sd32\*(C'\fR, \f(CW\*(C`avr64sd48\*(C'\fR.
  .ie n .IP """avrxmega3""" 4
! .el .IP "\f(CWavrxmega3\fR" 4
  .IX Item "avrxmega3"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with up to 64 KiB of combined program memory and \s-1RAM,\s0 and with program memory visible in the \s-1RAM\s0 address space.
! \&\fImcu\fR = \f(CW\*(C`attiny202\*(C'\fR, \f(CW\*(C`attiny204\*(C'\fR, \f(CW\*(C`attiny212\*(C'\fR, \f(CW\*(C`attiny214\*(C'\fR, \f(CW\*(C`attiny402\*(C'\fR, \f(CW\*(C`attiny404\*(C'\fR, \f(CW\*(C`attiny406\*(C'\fR, \f(CW\*(C`attiny412\*(C'\fR, \f(CW\*(C`attiny414\*(C'\fR, \f(CW\*(C`attiny416\*(C'\fR, \f(CW\*(C`attiny416auto\*(C'\fR, \f(CW\*(C`attiny417\*(C'\fR, \f(CW\*(C`attiny424\*(C'\fR, \f(CW\*(C`attiny426\*(C'\fR, \f(CW\*(C`attiny427\*(C'\fR, \f(CW\*(C`attiny804\*(C'\fR, \f(CW\*(C`attiny806\*(C'\fR, \f(CW\*(C`attiny807\*(C'\fR, \f(CW\*(C`attiny814\*(C'\fR, \f(CW\*(C`attiny816\*(C'\fR, \f(CW\*(C`attiny817\*(C'\fR, \f(CW\*(C`attiny824\*(C'\fR, \f(CW\*(C`attiny826\*(C'\fR, \f(CW\*(C`attiny827\*(C'\fR, \f(CW\*(C`attiny1604\*(C'\fR, \f(CW\*(C`attiny1606\*(C'\fR, \f(CW\*(C`attiny1607\*(C'\fR, \f(CW\*(C`attiny1614\*(C'\fR, \f(CW\*(C`attiny1616\*(C'\fR, \f(CW\*(C`attiny1617\*(C'\fR, \f(CW\*(C`attiny1624\*(C'\fR, \f(CW\*(C`attiny1626\*(C'\fR, \f(CW\*(C`attiny1627\*(C'\fR, \f(CW\*(C`attiny3214\*(C'\fR, \f(CW\*(C`attiny3216\*(C'\fR, \f(CW\*(C`attiny3217\*(C'\fR, \f(CW\*(C`attiny3224\*(C'\fR, \f(CW\*(C`attiny3226\*(C'\fR, \f(CW\*(C`attiny3227\*(C'\fR, \f(CW\*(C`atmega808\*(C'\fR, \f(CW\*(C`atmega809\*(C'\fR, \f(CW\*(C`atmega1608\*(C'\fR, \f(CW\*(C`atmega1609\*(C'\fR, \f(CW\*(C`atmega3208\*(C'\fR, \f(CW\*(C`atmega3209\*(C'\fR, \f(CW\*(C`atmega4808\*(C'\fR, \f(CW\*(C`atmega4809\*(C'\fR, \f(CW\*(C`avr16dd14\*(C'\fR, \f(CW\*(C`avr16dd20\*(C'\fR, \f(CW\*(C`avr16dd28\*(C'\fR, \f(CW\*(C`avr16dd32\*(C'\fR, \f(CW\*(C`avr16du14\*(C'\fR, \f(CW\*(C`avr16du20\*(C'\fR, \f(CW\*(C`avr16du28\*(C'\fR, \f(CW\*(C`avr16du32\*(C'\fR, \f(CW\*(C`avr16ea28\*(C'\fR, \f(CW\*(C`avr16ea32\*(C'\fR, \f(CW\*(C`avr16ea48\*(C'\fR, \f(CW\*(C`avr16eb14\*(C'\fR, \f(CW\*(C`avr16eb20\*(C'\fR, \f(CW\*(C`avr16eb28\*(C'\fR, \f(CW\*(C`avr16eb32\*(C'\fR, \f(CW\*(C`avr32da28\*(C'\fR, \f(CW\*(C`avr32da32\*(C'\fR, \f(CW\*(C`avr32da48\*(C'\fR, \f(CW\*(C`avr32db28\*(C'\fR, \f(CW\*(C`avr32db32\*(C'\fR, \f(CW\*(C`avr32db48\*(C'\fR, \f(CW\*(C`avr32dd14\*(C'\fR, \f(CW\*(C`avr32dd20\*(C'\fR, \f(CW\*(C`avr32dd28\*(C'\fR, \f(CW\*(C`avr32dd32\*(C'\fR, \f(CW\*(C`avr32du14\*(C'\fR, \f(CW\*(C`avr32du20\*(C'\fR, \f(CW\*(C`avr32du28\*(C'\fR, \f(CW\*(C`avr32du32\*(C'\fR, \f(CW\*(C`avr32ea28\*(C'\fR, \f(CW\*(C`avr32ea32\*(C'\fR, \f(CW\*(C`avr32ea48\*(C'\fR, \f(CW\*(C`avr32sd20\*(C'\fR, \f(CW\*(C`avr32sd28\*(C'\fR, \f(CW\*(C`avr32sd32\*(C'\fR.
  .ie n .IP """avrxmega4""" 4
! .el .IP "\f(CWavrxmega4\fR" 4
  .IX Item "avrxmega4"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 64 KiB and up to 128 KiB of program memory.
! \&\fImcu\fR = \f(CW\*(C`atxmega64a3\*(C'\fR, \f(CW\*(C`atxmega64a3u\*(C'\fR, \f(CW\*(C`atxmega64a4u\*(C'\fR, \f(CW\*(C`atxmega64b1\*(C'\fR, \f(CW\*(C`atxmega64b3\*(C'\fR, \f(CW\*(C`atxmega64c3\*(C'\fR, \f(CW\*(C`atxmega64d3\*(C'\fR, \f(CW\*(C`atxmega64d4\*(C'\fR, \f(CW\*(C`avr128da28\*(C'\fR, \f(CW\*(C`avr128da32\*(C'\fR, \f(CW\*(C`avr128da48\*(C'\fR, \f(CW\*(C`avr128da64\*(C'\fR, \f(CW\*(C`avr128db28\*(C'\fR, \f(CW\*(C`avr128db32\*(C'\fR, \f(CW\*(C`avr128db48\*(C'\fR, \f(CW\*(C`avr128db64\*(C'\fR.
  .ie n .IP """avrxmega5""" 4
! .el .IP "\f(CWavrxmega5\fR" 4
  .IX Item "avrxmega5"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 64 KiB and up to 128 KiB of program memory and more than 64 KiB of \s-1RAM.\s0
  \&\fImcu\fR = \f(CW\*(C`atxmega64a1\*(C'\fR, \f(CW\*(C`atxmega64a1u\*(C'\fR.
  .ie n .IP """avrxmega6""" 4
! .el .IP "\f(CWavrxmega6\fR" 4
  .IX Item "avrxmega6"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atxmega128a3\*(C'\fR, \f(CW\*(C`atxmega128a3u\*(C'\fR, \f(CW\*(C`atxmega128b1\*(C'\fR, \f(CW\*(C`atxmega128b3\*(C'\fR, \f(CW\*(C`atxmega128c3\*(C'\fR, \f(CW\*(C`atxmega128d3\*(C'\fR, \f(CW\*(C`atxmega128d4\*(C'\fR, \f(CW\*(C`atxmega192a3\*(C'\fR, \f(CW\*(C`atxmega192a3u\*(C'\fR, \f(CW\*(C`atxmega192c3\*(C'\fR, \f(CW\*(C`atxmega192d3\*(C'\fR, \f(CW\*(C`atxmega256a3\*(C'\fR, \f(CW\*(C`atxmega256a3b\*(C'\fR, \f(CW\*(C`atxmega256a3bu\*(C'\fR, \f(CW\*(C`atxmega256a3u\*(C'\fR, \f(CW\*(C`atxmega256c3\*(C'\fR, \f(CW\*(C`atxmega256d3\*(C'\fR, \f(CW\*(C`atxmega384c3\*(C'\fR, \f(CW\*(C`atxmega384d3\*(C'\fR.
  .ie n .IP """avrxmega7""" 4
! .el .IP "\f(CWavrxmega7\fR" 4
  .IX Item "avrxmega7"
! \&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 128 KiB of program memory and more than 64 KiB of \s-1RAM.\s0
  \&\fImcu\fR = \f(CW\*(C`atxmega128a1\*(C'\fR, \f(CW\*(C`atxmega128a1u\*(C'\fR, \f(CW\*(C`atxmega128a4u\*(C'\fR.
  .ie n .IP """avrtiny""" 4
! .el .IP "\f(CWavrtiny\fR" 4
  .IX Item "avrtiny"
! \&\*(L"\s-1TINY\*(R"\s0 Tiny core devices with 512 B up to 4 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`attiny4\*(C'\fR, \f(CW\*(C`attiny5\*(C'\fR, \f(CW\*(C`attiny9\*(C'\fR, \f(CW\*(C`attiny10\*(C'\fR, \f(CW\*(C`attiny102\*(C'\fR, \f(CW\*(C`attiny104\*(C'\fR, \f(CW\*(C`attiny20\*(C'\fR, \f(CW\*(C`attiny40\*(C'\fR.
  .ie n .IP """avr1""" 4
! .el .IP "\f(CWavr1\fR" 4
  .IX Item "avr1"
! This \s-1ISA\s0 is implemented by the minimal \s-1AVR\s0 core and supported for assembler only.
  \&\fImcu\fR = \f(CW\*(C`attiny11\*(C'\fR, \f(CW\*(C`attiny12\*(C'\fR, \f(CW\*(C`attiny15\*(C'\fR, \f(CW\*(C`attiny28\*(C'\fR, \f(CW\*(C`at90s1200\*(C'\fR.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mabsdata\fR" 4
  .IX Item "-mabsdata"
! Assume that all data in static storage can be accessed by \s-1LDS / STS\s0
  instructions.  This option has only an effect on reduced Tiny devices like
  ATtiny40.  See also the \f(CW\*(C`absdata\*(C'\fR
! \&\fB\s-1AVR\s0 Variable Attributes,variable attribute\fR.
! .IP "\fB\-maccumulate\-args\fR" 4
  .IX Item "-maccumulate-args"
  Accumulate outgoing function arguments and acquire/release the needed
  stack space for outgoing function arguments once in function
--- 22002,22122 ----
  The default is to generate code without branch protection or return
  address signing.
  .PP
! \fIAVR Options\fR
  .IX Subsection "AVR Options"
  .PP
! These options are defined for AVR implementations:
! .IP \fB\-mmcu=\fR\fImcu\fR 4
  .IX Item "-mmcu=mcu"
! Specify the AVR instruction set architecture (ISA) or device type.
  The default for this option is \f(CW\*(C`avr2\*(C'\fR.
  .Sp
! The following AVR devices and ISAs are supported.
  \&\fINote:\fR A complete device support consists of
! startup code \f(CW\*(C`crt\fR\f(CImcu\fR\f(CW.o\*(C'\fR, a device header \f(CW\*(C`avr/io*.h\*(C'\fR,
! a device library \f(CW\*(C`lib\fR\f(CImcu\fR\f(CW.a\*(C'\fR and a
! device\-specs (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#spec\-files\*(C'\fR) file
! \&\f(CW\*(C`specs\-\fR\f(CImcu\fR\f(CW\*(C'\fR. Only the latter is provided by the compiler
! according the supported \f(CW\*(C`\fR\f(CImcu\fR\f(CW\*(C'\fRs below.  The rest is supported
! by AVR\-LibC (\f(CW\*(C`https://www.nongnu.org/avr\-libc/\*(C'\fR), or by means of
  \&\f(CW\*(C`atpack\*(C'\fR (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#atpack\*(C'\fR) files
  from the hardware manufacturer.
  .RS 4
  .ie n .IP """avr2""" 4
! .el .IP \f(CWavr2\fR 4
  .IX Item "avr2"
! "Classic" devices with up to 8 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`attiny22\*(C'\fR, \f(CW\*(C`attiny26\*(C'\fR, \f(CW\*(C`at90s2313\*(C'\fR, \f(CW\*(C`at90s2323\*(C'\fR, \f(CW\*(C`at90s2333\*(C'\fR, \f(CW\*(C`at90s2343\*(C'\fR, \f(CW\*(C`at90s4414\*(C'\fR, \f(CW\*(C`at90s4433\*(C'\fR, \f(CW\*(C`at90s4434\*(C'\fR, \f(CW\*(C`at90c8534\*(C'\fR, \f(CW\*(C`at90s8515\*(C'\fR, \f(CW\*(C`at90s8535\*(C'\fR.
  .ie n .IP """avr25""" 4
! .el .IP \f(CWavr25\fR 4
  .IX Item "avr25"
! "Classic" devices with up to 8 KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
  \&\fImcu\fR = \f(CW\*(C`attiny13\*(C'\fR, \f(CW\*(C`attiny13a\*(C'\fR, \f(CW\*(C`attiny24\*(C'\fR, \f(CW\*(C`attiny24a\*(C'\fR, \f(CW\*(C`attiny25\*(C'\fR, \f(CW\*(C`attiny261\*(C'\fR, \f(CW\*(C`attiny261a\*(C'\fR, \f(CW\*(C`attiny2313\*(C'\fR, \f(CW\*(C`attiny2313a\*(C'\fR, \f(CW\*(C`attiny43u\*(C'\fR, \f(CW\*(C`attiny44\*(C'\fR, \f(CW\*(C`attiny44a\*(C'\fR, \f(CW\*(C`attiny45\*(C'\fR, \f(CW\*(C`attiny48\*(C'\fR, \f(CW\*(C`attiny441\*(C'\fR, \f(CW\*(C`attiny461\*(C'\fR, \f(CW\*(C`attiny461a\*(C'\fR, \f(CW\*(C`attiny4313\*(C'\fR, \f(CW\*(C`attiny84\*(C'\fR, \f(CW\*(C`attiny84a\*(C'\fR, \f(CW\*(C`attiny85\*(C'\fR, \f(CW\*(C`attiny87\*(C'\fR, \f(CW\*(C`attiny88\*(C'\fR, \f(CW\*(C`attiny828\*(C'\fR, \f(CW\*(C`attiny841\*(C'\fR, \f(CW\*(C`attiny861\*(C'\fR, \f(CW\*(C`attiny861a\*(C'\fR, \f(CW\*(C`ata5272\*(C'\fR, \f(CW\*(C`ata6616c\*(C'\fR, \f(CW\*(C`at86rf401\*(C'\fR.
  .ie n .IP """avr3""" 4
! .el .IP \f(CWavr3\fR 4
  .IX Item "avr3"
! "Classic" devices with 16 KiB up to 64 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`at76c711\*(C'\fR, \f(CW\*(C`at43usb355\*(C'\fR.
  .ie n .IP """avr31""" 4
! .el .IP \f(CWavr31\fR 4
  .IX Item "avr31"
! "Classic" devices with 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega103\*(C'\fR, \f(CW\*(C`at43usb320\*(C'\fR.
  .ie n .IP """avr35""" 4
! .el .IP \f(CWavr35\fR 4
  .IX Item "avr35"
! "Classic" devices with 16 KiB up to 64 KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
  \&\fImcu\fR = \f(CW\*(C`attiny167\*(C'\fR, \f(CW\*(C`attiny1634\*(C'\fR, \f(CW\*(C`atmega8u2\*(C'\fR, \f(CW\*(C`atmega16u2\*(C'\fR, \f(CW\*(C`atmega32u2\*(C'\fR, \f(CW\*(C`ata5505\*(C'\fR, \f(CW\*(C`ata6617c\*(C'\fR, \f(CW\*(C`ata664251\*(C'\fR, \f(CW\*(C`at90usb82\*(C'\fR, \f(CW\*(C`at90usb162\*(C'\fR.
  .ie n .IP """avr4""" 4
! .el .IP \f(CWavr4\fR 4
  .IX Item "avr4"
! "Enhanced" devices with up to 8 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega48\*(C'\fR, \f(CW\*(C`atmega48a\*(C'\fR, \f(CW\*(C`atmega48p\*(C'\fR, \f(CW\*(C`atmega48pa\*(C'\fR, \f(CW\*(C`atmega48pb\*(C'\fR, \f(CW\*(C`atmega8\*(C'\fR, \f(CW\*(C`atmega8a\*(C'\fR, \f(CW\*(C`atmega8hva\*(C'\fR, \f(CW\*(C`atmega88\*(C'\fR, \f(CW\*(C`atmega88a\*(C'\fR, \f(CW\*(C`atmega88p\*(C'\fR, \f(CW\*(C`atmega88pa\*(C'\fR, \f(CW\*(C`atmega88pb\*(C'\fR, \f(CW\*(C`atmega8515\*(C'\fR, \f(CW\*(C`atmega8535\*(C'\fR, \f(CW\*(C`ata5795\*(C'\fR, \f(CW\*(C`ata6285\*(C'\fR, \f(CW\*(C`ata6286\*(C'\fR, \f(CW\*(C`ata6289\*(C'\fR, \f(CW\*(C`ata6612c\*(C'\fR, \f(CW\*(C`at90pwm1\*(C'\fR, \f(CW\*(C`at90pwm2\*(C'\fR, \f(CW\*(C`at90pwm2b\*(C'\fR, \f(CW\*(C`at90pwm3\*(C'\fR, \f(CW\*(C`at90pwm3b\*(C'\fR, \f(CW\*(C`at90pwm81\*(C'\fR.
  .ie n .IP """avr5""" 4
! .el .IP \f(CWavr5\fR 4
  .IX Item "avr5"
! "Enhanced" devices with 16 KiB up to 64 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega16\*(C'\fR, \f(CW\*(C`atmega16a\*(C'\fR, \f(CW\*(C`atmega16hva\*(C'\fR, \f(CW\*(C`atmega16hva2\*(C'\fR, \f(CW\*(C`atmega16hvb\*(C'\fR, \f(CW\*(C`atmega16hvbrevb\*(C'\fR, \f(CW\*(C`atmega16m1\*(C'\fR, \f(CW\*(C`atmega16u4\*(C'\fR, \f(CW\*(C`atmega161\*(C'\fR, \f(CW\*(C`atmega162\*(C'\fR, \f(CW\*(C`atmega163\*(C'\fR, \f(CW\*(C`atmega164a\*(C'\fR, \f(CW\*(C`atmega164p\*(C'\fR, \f(CW\*(C`atmega164pa\*(C'\fR, \f(CW\*(C`atmega165\*(C'\fR, \f(CW\*(C`atmega165a\*(C'\fR, \f(CW\*(C`atmega165p\*(C'\fR, \f(CW\*(C`atmega165pa\*(C'\fR, \f(CW\*(C`atmega168\*(C'\fR, \f(CW\*(C`atmega168a\*(C'\fR, \f(CW\*(C`atmega168p\*(C'\fR, \f(CW\*(C`atmega168pa\*(C'\fR, \f(CW\*(C`atmega168pb\*(C'\fR, \f(CW\*(C`atmega169\*(C'\fR, \f(CW\*(C`atmega169a\*(C'\fR, \f(CW\*(C`atmega169p\*(C'\fR, \f(CW\*(C`atmega169pa\*(C'\fR, \f(CW\*(C`atmega32\*(C'\fR, \f(CW\*(C`atmega32a\*(C'\fR, \f(CW\*(C`atmega32c1\*(C'\fR, \f(CW\*(C`atmega32hvb\*(C'\fR, \f(CW\*(C`atmega32hvbrevb\*(C'\fR, \f(CW\*(C`atmega32m1\*(C'\fR, \f(CW\*(C`atmega32u4\*(C'\fR, \f(CW\*(C`atmega32u6\*(C'\fR, \f(CW\*(C`atmega323\*(C'\fR, \f(CW\*(C`atmega324a\*(C'\fR, \f(CW\*(C`atmega324p\*(C'\fR, \f(CW\*(C`atmega324pa\*(C'\fR, \f(CW\*(C`atmega324pb\*(C'\fR, \f(CW\*(C`atmega325\*(C'\fR, \f(CW\*(C`atmega325a\*(C'\fR, \f(CW\*(C`atmega325p\*(C'\fR, \f(CW\*(C`atmega325pa\*(C'\fR, \f(CW\*(C`atmega328\*(C'\fR, \f(CW\*(C`atmega328p\*(C'\fR, \f(CW\*(C`atmega328pb\*(C'\fR, \f(CW\*(C`atmega329\*(C'\fR, \f(CW\*(C`atmega329a\*(C'\fR, \f(CW\*(C`atmega329p\*(C'\fR, \f(CW\*(C`atmega329pa\*(C'\fR, \f(CW\*(C`atmega3250\*(C'\fR, \f(CW\*(C`atmega3250a\*(C'\fR, \f(CW\*(C`atmega3250p\*(C'\fR, \f(CW\*(C`atmega3250pa\*(C'\fR, \f(CW\*(C`atmega3290\*(C'\fR, \f(CW\*(C`atmega3290a\*(C'\fR, \f(CW\*(C`atmega3290p\*(C'\fR, \f(CW\*(C`atmega3290pa\*(C'\fR, \f(CW\*(C`atmega406\*(C'\fR, \f(CW\*(C`atmega64\*(C'\fR, \f(CW\*(C`atmega64a\*(C'\fR, \f(CW\*(C`atmega64c1\*(C'\fR, \f(CW\*(C`atmega64hve\*(C'\fR, \f(CW\*(C`atmega64hve2\*(C'\fR, \f(CW\*(C`atmega64m1\*(C'\fR, \f(CW\*(C`atmega64rfr2\*(C'\fR, \f(CW\*(C`atmega640\*(C'\fR, \f(CW\*(C`atmega644\*(C'\fR, \f(CW\*(C`atmega644a\*(C'\fR, \f(CW\*(C`atmega644p\*(C'\fR, \f(CW\*(C`atmega644pa\*(C'\fR, \f(CW\*(C`atmega644rfr2\*(C'\fR, \f(CW\*(C`atmega645\*(C'\fR, \f(CW\*(C`atmega645a\*(C'\fR, \f(CW\*(C`atmega645p\*(C'\fR, \f(CW\*(C`atmega649\*(C'\fR, \f(CW\*(C`atmega649a\*(C'\fR, \f(CW\*(C`atmega649p\*(C'\fR, \f(CW\*(C`atmega6450\*(C'\fR, \f(CW\*(C`atmega6450a\*(C'\fR, \f(CW\*(C`atmega6450p\*(C'\fR, \f(CW\*(C`atmega6490\*(C'\fR, \f(CW\*(C`atmega6490a\*(C'\fR, \f(CW\*(C`atmega6490p\*(C'\fR, \f(CW\*(C`ata5790\*(C'\fR, \f(CW\*(C`ata5790n\*(C'\fR, \f(CW\*(C`ata5791\*(C'\fR, \f(CW\*(C`ata6613c\*(C'\fR, \f(CW\*(C`ata6614q\*(C'\fR, \f(CW\*(C`ata5782\*(C'\fR, \f(CW\*(C`ata5831\*(C'\fR, \f(CW\*(C`ata8210\*(C'\fR, \f(CW\*(C`ata8510\*(C'\fR, \f(CW\*(C`ata5787\*(C'\fR, \f(CW\*(C`ata5835\*(C'\fR, \f(CW\*(C`ata5700m322\*(C'\fR, \f(CW\*(C`ata5702m322\*(C'\fR, \f(CW\*(C`at90pwm161\*(C'\fR, \f(CW\*(C`at90pwm216\*(C'\fR, \f(CW\*(C`at90pwm316\*(C'\fR, \f(CW\*(C`at90can32\*(C'\fR, \f(CW\*(C`at90can64\*(C'\fR, \f(CW\*(C`at90scr100\*(C'\fR, \f(CW\*(C`at90usb646\*(C'\fR, \f(CW\*(C`at90usb647\*(C'\fR, \f(CW\*(C`at94k\*(C'\fR, \f(CW\*(C`m3000\*(C'\fR.
  .ie n .IP """avr51""" 4
! .el .IP \f(CWavr51\fR 4
  .IX Item "avr51"
! "Enhanced" devices with 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega128\*(C'\fR, \f(CW\*(C`atmega128a\*(C'\fR, \f(CW\*(C`atmega128rfa1\*(C'\fR, \f(CW\*(C`atmega128rfr2\*(C'\fR, \f(CW\*(C`atmega1280\*(C'\fR, \f(CW\*(C`atmega1281\*(C'\fR, \f(CW\*(C`atmega1284\*(C'\fR, \f(CW\*(C`atmega1284p\*(C'\fR, \f(CW\*(C`atmega1284rfr2\*(C'\fR, \f(CW\*(C`at90can128\*(C'\fR, \f(CW\*(C`at90usb1286\*(C'\fR, \f(CW\*(C`at90usb1287\*(C'\fR.
  .ie n .IP """avr6""" 4
! .el .IP \f(CWavr6\fR 4
  .IX Item "avr6"
! "Enhanced" devices with 3\-byte PC, i.e. with more than 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atmega256rfr2\*(C'\fR, \f(CW\*(C`atmega2560\*(C'\fR, \f(CW\*(C`atmega2561\*(C'\fR, \f(CW\*(C`atmega2564rfr2\*(C'\fR.
  .ie n .IP """avrxmega2""" 4
! .el .IP \f(CWavrxmega2\fR 4
  .IX Item "avrxmega2"
! "XMEGA" devices with more than 8 KiB and up to 64 KiB of program memory.
! \&\fImcu\fR = \f(CW\*(C`atxmega8e5\*(C'\fR, \f(CW\*(C`atxmega16a4\*(C'\fR, \f(CW\*(C`atxmega16a4u\*(C'\fR, \f(CW\*(C`atxmega16c4\*(C'\fR, \f(CW\*(C`atxmega16d4\*(C'\fR, \f(CW\*(C`atxmega16e5\*(C'\fR, \f(CW\*(C`atxmega32a4\*(C'\fR, \f(CW\*(C`atxmega32a4u\*(C'\fR, \f(CW\*(C`atxmega32c3\*(C'\fR, \f(CW\*(C`atxmega32c4\*(C'\fR, \f(CW\*(C`atxmega32d3\*(C'\fR, \f(CW\*(C`atxmega32d4\*(C'\fR, \f(CW\*(C`atxmega32e5\*(C'\fR, \f(CW\*(C`avr64da28\*(C'\fR, \f(CW\*(C`avr64da28s\*(C'\fR, \f(CW\*(C`avr64da32\*(C'\fR, \f(CW\*(C`avr64da32s\*(C'\fR, \f(CW\*(C`avr64da48\*(C'\fR, \f(CW\*(C`avr64da48s\*(C'\fR, \f(CW\*(C`avr64da64\*(C'\fR, \f(CW\*(C`avr64da64s\*(C'\fR, \f(CW\*(C`avr64db28\*(C'\fR, \f(CW\*(C`avr64db32\*(C'\fR, \f(CW\*(C`avr64db48\*(C'\fR, \f(CW\*(C`avr64db64\*(C'\fR, \f(CW\*(C`avr64dd14\*(C'\fR, \f(CW\*(C`avr64dd20\*(C'\fR, \f(CW\*(C`avr64dd28\*(C'\fR, \f(CW\*(C`avr64dd32\*(C'\fR, \f(CW\*(C`avr64du28\*(C'\fR, \f(CW\*(C`avr64du32\*(C'\fR, \f(CW\*(C`avr64ea28\*(C'\fR, \f(CW\*(C`avr64ea32\*(C'\fR, \f(CW\*(C`avr64ea48\*(C'\fR, \f(CW\*(C`avr64sd28\*(C'\fR, \f(CW\*(C`avr64sd32\*(C'\fR, \f(CW\*(C`avr64sd48\*(C'\fR.
  .ie n .IP """avrxmega3""" 4
! .el .IP \f(CWavrxmega3\fR 4
  .IX Item "avrxmega3"
! "XMEGA" devices with up to 64 KiB of combined program memory and RAM, and with program memory visible in the RAM address space.
! \&\fImcu\fR = \f(CW\*(C`attiny202\*(C'\fR, \f(CW\*(C`attiny204\*(C'\fR, \f(CW\*(C`attiny212\*(C'\fR, \f(CW\*(C`attiny214\*(C'\fR, \f(CW\*(C`attiny402\*(C'\fR, \f(CW\*(C`attiny404\*(C'\fR, \f(CW\*(C`attiny406\*(C'\fR, \f(CW\*(C`attiny412\*(C'\fR, \f(CW\*(C`attiny414\*(C'\fR, \f(CW\*(C`attiny416\*(C'\fR, \f(CW\*(C`attiny416auto\*(C'\fR, \f(CW\*(C`attiny417\*(C'\fR, \f(CW\*(C`attiny424\*(C'\fR, \f(CW\*(C`attiny426\*(C'\fR, \f(CW\*(C`attiny427\*(C'\fR, \f(CW\*(C`attiny804\*(C'\fR, \f(CW\*(C`attiny806\*(C'\fR, \f(CW\*(C`attiny807\*(C'\fR, \f(CW\*(C`attiny814\*(C'\fR, \f(CW\*(C`attiny816\*(C'\fR, \f(CW\*(C`attiny817\*(C'\fR, \f(CW\*(C`attiny824\*(C'\fR, \f(CW\*(C`attiny826\*(C'\fR, \f(CW\*(C`attiny827\*(C'\fR, \f(CW\*(C`attiny1604\*(C'\fR, \f(CW\*(C`attiny1606\*(C'\fR, \f(CW\*(C`attiny1607\*(C'\fR, \f(CW\*(C`attiny1614\*(C'\fR, \f(CW\*(C`attiny1616\*(C'\fR, \f(CW\*(C`attiny1617\*(C'\fR, \f(CW\*(C`attiny1624\*(C'\fR, \f(CW\*(C`attiny1626\*(C'\fR, \f(CW\*(C`attiny1627\*(C'\fR, \f(CW\*(C`attiny3214\*(C'\fR, \f(CW\*(C`attiny3216\*(C'\fR, \f(CW\*(C`attiny3217\*(C'\fR, \f(CW\*(C`attiny3224\*(C'\fR, \f(CW\*(C`attiny3226\*(C'\fR, \f(CW\*(C`attiny3227\*(C'\fR, \f(CW\*(C`atmega808\*(C'\fR, \f(CW\*(C`atmega809\*(C'\fR, \f(CW\*(C`atmega1608\*(C'\fR, \f(CW\*(C`atmega1609\*(C'\fR, \f(CW\*(C`atmega3208\*(C'\fR, \f(CW\*(C`atmega3209\*(C'\fR, \f(CW\*(C`atmega4808\*(C'\fR, \f(CW\*(C`atmega4809\*(C'\fR, \f(CW\*(C`avr16dd14\*(C'\fR, \f(CW\*(C`avr16dd20\*(C'\fR, \f(CW\*(C`avr16dd28\*(C'\fR, \f(CW\*(C`avr16dd32\*(C'\fR, \f(CW\*(C`avr16du14\*(C'\fR, \f(CW\*(C`avr16du20\*(C'\fR, \f(CW\*(C`avr16du28\*(C'\fR, \f(CW\*(C`avr16du32\*(C'\fR, \f(CW\*(C`avr16ea28\*(C'\fR, \f(CW\*(C`avr16ea32\*(C'\fR, \f(CW\*(C`avr16ea48\*(C'\fR, \f(CW\*(C`avr16eb14\*(C'\fR, \f(CW\*(C`avr16eb20\*(C'\fR, \f(CW\*(C`avr16eb28\*(C'\fR, \f(CW\*(C`avr16eb32\*(C'\fR, \f(CW\*(C`avr16la14\*(C'\fR, \f(CW\*(C`avr16la20\*(C'\fR, \f(CW\*(C`avr16la28\*(C'\fR, \f(CW\*(C`avr16la32\*(C'\fR, \f(CW\*(C`avr32da28\*(C'\fR, \f(CW\*(C`avr32da28s\*(C'\fR, \f(CW\*(C`avr32da32\*(C'\fR, \f(CW\*(C`avr32da32s\*(C'\fR, \f(CW\*(C`avr32da48\*(C'\fR, \f(CW\*(C`avr32da48s\*(C'\fR, \f(CW\*(C`avr32db28\*(C'\fR, \f(CW\*(C`avr32db32\*(C'\fR, \f(CW\*(C`avr32db48\*(C'\fR, \f(CW\*(C`avr32dd14\*(C'\fR, \f(CW\*(C`avr32dd20\*(C'\fR, \f(CW\*(C`avr32dd28\*(C'\fR, \f(CW\*(C`avr32dd32\*(C'\fR, \f(CW\*(C`avr32du14\*(C'\fR, \f(CW\*(C`avr32du20\*(C'\fR, \f(CW\*(C`avr32du28\*(C'\fR, \f(CW\*(C`avr32du32\*(C'\fR, \f(CW\*(C`avr32ea28\*(C'\fR, \f(CW\*(C`avr32ea32\*(C'\fR, \f(CW\*(C`avr32ea48\*(C'\fR, \f(CW\*(C`avr32eb14\*(C'\fR, \f(CW\*(C`avr32eb20\*(C'\fR, \f(CW\*(C`avr32eb28\*(C'\fR, \f(CW\*(C`avr32eb32\*(C'\fR, \f(CW\*(C`avr32la14\*(C'\fR, \f(CW\*(C`avr32la20\*(C'\fR, \f(CW\*(C`avr32la28\*(C'\fR, \f(CW\*(C`avr32la32\*(C'\fR, \f(CW\*(C`avr32sd20\*(C'\fR, \f(CW\*(C`avr32sd28\*(C'\fR, \f(CW\*(C`avr32sd32\*(C'\fR.
  .ie n .IP """avrxmega4""" 4
! .el .IP \f(CWavrxmega4\fR 4
  .IX Item "avrxmega4"
! "XMEGA" devices with more than 64 KiB and up to 128 KiB of program memory.
! \&\fImcu\fR = \f(CW\*(C`atxmega64a3\*(C'\fR, \f(CW\*(C`atxmega64a3u\*(C'\fR, \f(CW\*(C`atxmega64a4u\*(C'\fR, \f(CW\*(C`atxmega64b1\*(C'\fR, \f(CW\*(C`atxmega64b3\*(C'\fR, \f(CW\*(C`atxmega64c3\*(C'\fR, \f(CW\*(C`atxmega64d3\*(C'\fR, \f(CW\*(C`atxmega64d4\*(C'\fR, \f(CW\*(C`avr128da28\*(C'\fR, \f(CW\*(C`avr128da28s\*(C'\fR, \f(CW\*(C`avr128da32\*(C'\fR, \f(CW\*(C`avr128da32s\*(C'\fR, \f(CW\*(C`avr128da48\*(C'\fR, \f(CW\*(C`avr128da48s\*(C'\fR, \f(CW\*(C`avr128da64\*(C'\fR, \f(CW\*(C`avr128da64s\*(C'\fR, \f(CW\*(C`avr128db28\*(C'\fR, \f(CW\*(C`avr128db32\*(C'\fR, \f(CW\*(C`avr128db48\*(C'\fR, \f(CW\*(C`avr128db64\*(C'\fR.
  .ie n .IP """avrxmega5""" 4
! .el .IP \f(CWavrxmega5\fR 4
  .IX Item "avrxmega5"
! "XMEGA" devices with more than 64 KiB and up to 128 KiB of program memory and more than 64 KiB of RAM.
  \&\fImcu\fR = \f(CW\*(C`atxmega64a1\*(C'\fR, \f(CW\*(C`atxmega64a1u\*(C'\fR.
  .ie n .IP """avrxmega6""" 4
! .el .IP \f(CWavrxmega6\fR 4
  .IX Item "avrxmega6"
! "XMEGA" devices with more than 128 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`atxmega128a3\*(C'\fR, \f(CW\*(C`atxmega128a3u\*(C'\fR, \f(CW\*(C`atxmega128b1\*(C'\fR, \f(CW\*(C`atxmega128b3\*(C'\fR, \f(CW\*(C`atxmega128c3\*(C'\fR, \f(CW\*(C`atxmega128d3\*(C'\fR, \f(CW\*(C`atxmega128d4\*(C'\fR, \f(CW\*(C`atxmega192a3\*(C'\fR, \f(CW\*(C`atxmega192a3u\*(C'\fR, \f(CW\*(C`atxmega192c3\*(C'\fR, \f(CW\*(C`atxmega192d3\*(C'\fR, \f(CW\*(C`atxmega256a3\*(C'\fR, \f(CW\*(C`atxmega256a3b\*(C'\fR, \f(CW\*(C`atxmega256a3bu\*(C'\fR, \f(CW\*(C`atxmega256a3u\*(C'\fR, \f(CW\*(C`atxmega256c3\*(C'\fR, \f(CW\*(C`atxmega256d3\*(C'\fR, \f(CW\*(C`atxmega384c3\*(C'\fR, \f(CW\*(C`atxmega384d3\*(C'\fR.
  .ie n .IP """avrxmega7""" 4
! .el .IP \f(CWavrxmega7\fR 4
  .IX Item "avrxmega7"
! "XMEGA" devices with more than 128 KiB of program memory and more than 64 KiB of RAM.
  \&\fImcu\fR = \f(CW\*(C`atxmega128a1\*(C'\fR, \f(CW\*(C`atxmega128a1u\*(C'\fR, \f(CW\*(C`atxmega128a4u\*(C'\fR.
  .ie n .IP """avrtiny""" 4
! .el .IP \f(CWavrtiny\fR 4
  .IX Item "avrtiny"
! "TINY" Tiny core devices with 512 B up to 4 KiB of program memory.
  \&\fImcu\fR = \f(CW\*(C`attiny4\*(C'\fR, \f(CW\*(C`attiny5\*(C'\fR, \f(CW\*(C`attiny9\*(C'\fR, \f(CW\*(C`attiny10\*(C'\fR, \f(CW\*(C`attiny102\*(C'\fR, \f(CW\*(C`attiny104\*(C'\fR, \f(CW\*(C`attiny20\*(C'\fR, \f(CW\*(C`attiny40\*(C'\fR.
  .ie n .IP """avr1""" 4
! .el .IP \f(CWavr1\fR 4
  .IX Item "avr1"
! This ISA is implemented by the minimal AVR core and supported for assembler only.
  \&\fImcu\fR = \f(CW\*(C`attiny11\*(C'\fR, \f(CW\*(C`attiny12\*(C'\fR, \f(CW\*(C`attiny15\*(C'\fR, \f(CW\*(C`attiny28\*(C'\fR, \f(CW\*(C`at90s1200\*(C'\fR.
  .RE
  .RS 4
  .RE
! .IP \fB\-mabsdata\fR 4
  .IX Item "-mabsdata"
! Assume that all data in static storage can be accessed by LDS / STS
  instructions.  This option has only an effect on reduced Tiny devices like
  ATtiny40.  See also the \f(CW\*(C`absdata\*(C'\fR
! \&\fBAVR Variable Attributes,variable attribute\fR.
! .IP \fB\-maccumulate\-args\fR 4
  .IX Item "-maccumulate-args"
  Accumulate outgoing function arguments and acquire/release the needed
  stack space for outgoing function arguments once in function
*************** prologue/epilogue.  Without this option,
*** 22193,22218 ****
  before calling a function and popped afterwards.
  .Sp
  Popping the arguments after the function call can be expensive on
! \&\s-1AVR\s0 so that accumulating the stack space might lead to smaller
  executables because arguments need not be removed from the
  stack after such a function call.
  .Sp
  This option can lead to reduced code size for functions that perform
  several calls to functions that get their arguments on the stack like
! calls to printf-like functions.
! .IP "\fB\-mbranch\-cost=\fR\fIcost\fR" 4
  .IX Item "-mbranch-cost=cost"
  Set the branch costs for conditional branch instructions to
! \&\fIcost\fR.  Reasonable values for \fIcost\fR are small, non-negative
  integers. The default branch cost is 0.
! .IP "\fB\-mcall\-prologues\fR" 4
  .IX Item "-mcall-prologues"
  Functions prologues/epilogues are expanded as calls to appropriate
  subroutines.  Code size is smaller.
! .IP "\fB\-mdouble=\fR\fIbits\fR" 4
  .IX Item "-mdouble=bits"
  .PD 0
! .IP "\fB\-mlong\-double=\fR\fIbits\fR" 4
  .IX Item "-mlong-double=bits"
  .PD
  Set the size (in bits) of the \f(CW\*(C`double\*(C'\fR or \f(CW\*(C`long double\*(C'\fR type,
--- 22124,22149 ----
  before calling a function and popped afterwards.
  .Sp
  Popping the arguments after the function call can be expensive on
! AVR so that accumulating the stack space might lead to smaller
  executables because arguments need not be removed from the
  stack after such a function call.
  .Sp
  This option can lead to reduced code size for functions that perform
  several calls to functions that get their arguments on the stack like
! calls to printf\-like functions.
! .IP \fB\-mbranch\-cost=\fR\fIcost\fR 4
  .IX Item "-mbranch-cost=cost"
  Set the branch costs for conditional branch instructions to
! \&\fIcost\fR.  Reasonable values for \fIcost\fR are small, non\-negative
  integers. The default branch cost is 0.
! .IP \fB\-mcall\-prologues\fR 4
  .IX Item "-mcall-prologues"
  Functions prologues/epilogues are expanded as calls to appropriate
  subroutines.  Code size is smaller.
! .IP \fB\-mdouble=\fR\fIbits\fR 4
  .IX Item "-mdouble=bits"
  .PD 0
! .IP \fB\-mlong\-double=\fR\fIbits\fR 4
  .IX Item "-mlong-double=bits"
  .PD
  Set the size (in bits) of the \f(CW\*(C`double\*(C'\fR or \f(CW\*(C`long double\*(C'\fR type,
*************** Whether or not a specific value for \fIb
*** 22221,22258 ****
  the \f(CW\*(C`\-\-with\-double=\*(C'\fR and \f(CW\*(C`\-\-with\-long\-double=\*(C'\fR
  configure\ options (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR),
  and the same applies for the default values of the options.
! .IP "\fB\-mgas\-isr\-prologues\fR" 4
  .IX Item "-mgas-isr-prologues"
  Interrupt service routines (ISRs) may use the \f(CW\*(C`_\|_gcc_isr\*(C'\fR pseudo
! instruction supported by \s-1GNU\s0 Binutils.
  If this option is on, the feature can still be disabled for individual
! ISRs by means of the \fB\s-1AVR\s0 Function Attributes,,\f(CB\*(C`no_gccisr\*(C'\fB\fR
  function attribute.  This feature is activated per default
  if optimization is on (but not with \fB\-Og\fR, \f(CW@pxref\fR{Optimize Options}),
! and if \s-1GNU\s0 Binutils support \s-1PR21683\s0 (\f(CW\*(C`https://sourceware.org/PR21683\*(C'\fR).
! .IP "\fB\-mint8\fR" 4
  .IX Item "-mint8"
  Assume \f(CW\*(C`int\*(C'\fR to be 8\-bit integer.  This affects the sizes of all types: a
  \&\f(CW\*(C`char\*(C'\fR is 1 byte, an \f(CW\*(C`int\*(C'\fR is 1 byte, a \f(CW\*(C`long\*(C'\fR is 2 bytes,
  and \f(CW\*(C`long long\*(C'\fR is 4 bytes.  Please note that this option does not
  conform to the C standards, but it results in smaller code
  size.
! .IP "\fB\-mmain\-is\-OS_task\fR" 4
  .IX Item "-mmain-is-OS_task"
  Do not save registers in \f(CW\*(C`main\*(C'\fR.  The effect is the same like
! attaching attribute \fB\s-1AVR\s0 Function Attributes,,\f(CB\*(C`OS_task\*(C'\fB\fR
  to \f(CW\*(C`main\*(C'\fR. It is activated per default if optimization is on.
! .IP "\fB\-mno\-interrupts\fR" 4
  .IX Item "-mno-interrupts"
  Generated code is not compatible with hardware interrupts.
  Code size is smaller.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Try to replace \f(CW\*(C`CALL\*(C'\fR resp. \f(CW\*(C`JMP\*(C'\fR instruction by the shorter
  \&\f(CW\*(C`RCALL\*(C'\fR resp. \f(CW\*(C`RJMP\*(C'\fR instruction if applicable.
  Setting \fB\-mrelax\fR just adds the \fB\-\-mlink\-relax\fR option to
! the assembler's command line and the \fB\-\-relax\fR option to the
! linker's command line.
  .Sp
  Jump relaxing is performed by the linker because jump offsets are not
  known before code is located. Therefore, the assembler code generated by the
--- 22152,22189 ----
  the \f(CW\*(C`\-\-with\-double=\*(C'\fR and \f(CW\*(C`\-\-with\-long\-double=\*(C'\fR
  configure\ options (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR),
  and the same applies for the default values of the options.
! .IP \fB\-mgas\-isr\-prologues\fR 4
  .IX Item "-mgas-isr-prologues"
  Interrupt service routines (ISRs) may use the \f(CW\*(C`_\|_gcc_isr\*(C'\fR pseudo
! instruction supported by GNU Binutils.
  If this option is on, the feature can still be disabled for individual
! ISRs by means of the \fBAVR Function Attributes,,\fR\f(CB\*(C`no_gccisr\*(C'\fR
  function attribute.  This feature is activated per default
  if optimization is on (but not with \fB\-Og\fR, \f(CW@pxref\fR{Optimize Options}),
! and if GNU Binutils support PR21683 (\f(CW\*(C`https://sourceware.org/PR21683\*(C'\fR).
! .IP \fB\-mint8\fR 4
  .IX Item "-mint8"
  Assume \f(CW\*(C`int\*(C'\fR to be 8\-bit integer.  This affects the sizes of all types: a
  \&\f(CW\*(C`char\*(C'\fR is 1 byte, an \f(CW\*(C`int\*(C'\fR is 1 byte, a \f(CW\*(C`long\*(C'\fR is 2 bytes,
  and \f(CW\*(C`long long\*(C'\fR is 4 bytes.  Please note that this option does not
  conform to the C standards, but it results in smaller code
  size.
! .IP \fB\-mmain\-is\-OS_task\fR 4
  .IX Item "-mmain-is-OS_task"
  Do not save registers in \f(CW\*(C`main\*(C'\fR.  The effect is the same like
! attaching attribute \fBAVR Function Attributes,,\fR\f(CB\*(C`OS_task\*(C'\fR
  to \f(CW\*(C`main\*(C'\fR. It is activated per default if optimization is on.
! .IP \fB\-mno\-interrupts\fR 4
  .IX Item "-mno-interrupts"
  Generated code is not compatible with hardware interrupts.
  Code size is smaller.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Try to replace \f(CW\*(C`CALL\*(C'\fR resp. \f(CW\*(C`JMP\*(C'\fR instruction by the shorter
  \&\f(CW\*(C`RCALL\*(C'\fR resp. \f(CW\*(C`RJMP\*(C'\fR instruction if applicable.
  Setting \fB\-mrelax\fR just adds the \fB\-\-mlink\-relax\fR option to
! the assembler\*(Aqs command line and the \fB\-\-relax\fR option to the
! linker\*(Aqs command line.
  .Sp
  Jump relaxing is performed by the linker because jump offsets are not
  known before code is located. Therefore, the assembler code generated by the
*************** differ from instructions in the assemble
*** 22261,22277 ****
  .Sp
  Relaxing must be turned on if linker stubs are needed, see the
  section on \f(CW\*(C`EIND\*(C'\fR and linker stubs below.
! .IP "\fB\-mstrict\-X\fR" 4
  .IX Item "-mstrict-X"
  Use address register \f(CW\*(C`X\*(C'\fR in a way proposed by the hardware.  This means
! that \f(CW\*(C`X\*(C'\fR is only used in indirect, post-increment or
! pre-decrement addressing.
  .Sp
  Without this option, the \f(CW\*(C`X\*(C'\fR register may be used in the same way
  as \f(CW\*(C`Y\*(C'\fR or \f(CW\*(C`Z\*(C'\fR which then is emulated by additional
  instructions.  
  For example, loading a value with \f(CW\*(C`X+const\*(C'\fR addressing with a
! small non-negative \f(CW\*(C`const < 64\*(C'\fR to a register \fIRn\fR is
  performed as
  .Sp
  .Vb 3
--- 22192,22208 ----
  .Sp
  Relaxing must be turned on if linker stubs are needed, see the
  section on \f(CW\*(C`EIND\*(C'\fR and linker stubs below.
! .IP \fB\-mstrict\-X\fR 4
  .IX Item "-mstrict-X"
  Use address register \f(CW\*(C`X\*(C'\fR in a way proposed by the hardware.  This means
! that \f(CW\*(C`X\*(C'\fR is only used in indirect, post\-increment or
! pre\-decrement addressing.
  .Sp
  Without this option, the \f(CW\*(C`X\*(C'\fR register may be used in the same way
  as \f(CW\*(C`Y\*(C'\fR or \f(CW\*(C`Z\*(C'\fR which then is emulated by additional
  instructions.  
  For example, loading a value with \f(CW\*(C`X+const\*(C'\fR addressing with a
! small non\-negative \f(CW\*(C`const < 64\*(C'\fR to a register \fIRn\fR is
  performed as
  .Sp
  .Vb 3
*************** performed as
*** 22279,22313 ****
  \&        ld   , X        ;  = *X
  \&        sbiw r26, const   ; X \-= const
  .Ve
! .IP "\fB\-mtiny\-stack\fR" 4
  .IX Item "-mtiny-stack"
  Only change the lower 8 bits of the stack pointer.
! .IP "\fB\-mfract\-convert\-truncate\fR" 4
  .IX Item "-mfract-convert-truncate"
! Allow to use truncation instead of rounding towards zero for fractional fixed-point types.
! .IP "\fB\-nodevicelib\fR" 4
  .IX Item "-nodevicelib"
! Don't link against AVR-LibC's device specific library \f(CW\*(C`lib.a\*(C'\fR.
! .IP "\fB\-nodevicespecs\fR" 4
  .IX Item "-nodevicespecs"
! Don't add \fB\-specs=device\-specs/specs\-\fR\fImcu\fR to the compiler driver's
! command line.  The user takes responsibility for supplying the sub-processes
  like compiler proper, assembler and linker with appropriate command line
  options.  This means that the user has to supply her private device specs
! file by means of \fB\-specs=\fR\fIpath-to-specs-file\fR.  There is no
  more need for option \fB\-mmcu=\fR\fImcu\fR.
  .Sp
  This option can also serve as a replacement for the older way of
! specifying custom device-specs files that needed \fB\-B\fR \fIsome-path\fR to point to a directory
  which contains a folder named \f(CW\*(C`device\-specs\*(C'\fR which contains a specs file named
! \&\f(CW\*(C`specs\-\f(CImcu\f(CW\*(C'\fR, where \fImcu\fR was specified by \fB\-mmcu=\fR\fImcu\fR.
! .IP "\fB\-Waddr\-space\-convert\fR" 4
  .IX Item "-Waddr-space-convert"
  Warn about conversions between address spaces in the case where the
  resulting address space is not contained in the incoming address space.
! .IP "\fB\-Wmisspelled\-isr\fR" 4
  .IX Item "-Wmisspelled-isr"
! Warn if the \s-1ISR\s0 is misspelled, i.e. without _\|_vector prefix.
  Enabled by default.
  .PP
  \f(CW\*(C`EIND\*(C'\fR and Devices with More Than 128 Ki Bytes of Flash
--- 22210,22244 ----
  \&        ld   , X        ;  = *X
  \&        sbiw r26, const   ; X \-= const
  .Ve
! .IP \fB\-mtiny\-stack\fR 4
  .IX Item "-mtiny-stack"
  Only change the lower 8 bits of the stack pointer.
! .IP \fB\-mfract\-convert\-truncate\fR 4
  .IX Item "-mfract-convert-truncate"
! Allow to use truncation instead of rounding towards zero for fractional fixed\-point types.
! .IP \fB\-nodevicelib\fR 4
  .IX Item "-nodevicelib"
! Don\*(Aqt link against AVR\-LibC\*(Aqs device specific library \f(CW\*(C`lib.a\*(C'\fR.
! .IP \fB\-nodevicespecs\fR 4
  .IX Item "-nodevicespecs"
! Don\*(Aqt add \fB\-specs=device\-specs/specs\-\fR\fImcu\fR to the compiler driver\*(Aqs
! command line.  The user takes responsibility for supplying the sub\-processes
  like compiler proper, assembler and linker with appropriate command line
  options.  This means that the user has to supply her private device specs
! file by means of \fB\-specs=\fR\fIpath\-to\-specs\-file\fR.  There is no
  more need for option \fB\-mmcu=\fR\fImcu\fR.
  .Sp
  This option can also serve as a replacement for the older way of
! specifying custom device\-specs files that needed \fB\-B\fR \fIsome\-path\fR to point to a directory
  which contains a folder named \f(CW\*(C`device\-specs\*(C'\fR which contains a specs file named
! \&\f(CW\*(C`specs\-\fR\f(CImcu\fR\f(CW\*(C'\fR, where \fImcu\fR was specified by \fB\-mmcu=\fR\fImcu\fR.
! .IP \fB\-Waddr\-space\-convert\fR 4
  .IX Item "-Waddr-space-convert"
  Warn about conversions between address spaces in the case where the
  resulting address space is not contained in the incoming address space.
! .IP \fB\-Wmisspelled\-isr\fR 4
  .IX Item "-Wmisspelled-isr"
! Warn if the ISR is misspelled, i.e. without _\|_vector prefix.
  Enabled by default.
  .PP
  \f(CW\*(C`EIND\*(C'\fR and Devices with More Than 128 Ki Bytes of Flash
*************** when \f(CW\*(C`EICALL\*(C'\fR or \f(CW\*
*** 22325,22369 ****
  .PP
  Indirect jumps and calls on these devices are handled as follows by
  the compiler and are subject to some limitations:
! .IP "*" 4
  The compiler never sets \f(CW\*(C`EIND\*(C'\fR.
! .IP "*" 4
  The compiler uses \f(CW\*(C`EIND\*(C'\fR implicitly in \f(CW\*(C`EICALL\*(C'\fR/\f(CW\*(C`EIJMP\*(C'\fR
  instructions or might read \f(CW\*(C`EIND\*(C'\fR directly in order to emulate an
  indirect call/jump by means of a \f(CW\*(C`RET\*(C'\fR instruction.
! .IP "*" 4
  The compiler assumes that \f(CW\*(C`EIND\*(C'\fR never changes during the startup
  code or during the application. In particular, \f(CW\*(C`EIND\*(C'\fR is not
  saved/restored in function or interrupt service routine
  prologue/epilogue.
! .IP "*" 4
  For indirect calls to functions and computed goto, the linker
  generates \fIstubs\fR. Stubs are jump pads sometimes also called
  \&\fItrampolines\fR. Thus, the indirect call/jump jumps to such a stub.
  The stub contains a direct jump to the desired address.
! .IP "*" 4
  Linker relaxation must be turned on so that the linker generates
  the stubs correctly in all situations. See the compiler option
  \&\fB\-mrelax\fR and the linker option \fB\-\-relax\fR.
  There are corner cases where the linker is supposed to generate stubs
  but aborts without relaxation and without a helpful error message.
! .IP "*" 4
  The default linker script is arranged for code with \f(CW\*(C`EIND = 0\*(C'\fR.
  If code is supposed to work for a setup with \f(CW\*(C`EIND != 0\*(C'\fR, a custom
  linker script has to be used in order to place the sections whose
  name start with \f(CW\*(C`.trampolines\*(C'\fR into the segment where \f(CW\*(C`EIND\*(C'\fR
  points to.
! .IP "*" 4
  The startup code from libgcc never sets \f(CW\*(C`EIND\*(C'\fR.
! Notice that startup code is a blend of code from libgcc and AVR-LibC.
! For the impact of AVR-LibC on \f(CW\*(C`EIND\*(C'\fR, see the
! AVR-LibC\ user\ manual (\f(CW\*(C`https://www.nongnu.org/avr\-libc/user\-manual/\*(C'\fR).
! .IP "*" 4
! It is legitimate for user-specific startup code to set up \f(CW\*(C`EIND\*(C'\fR
  early, for example by means of initialization code located in
  section \f(CW\*(C`.init3\*(C'\fR. Such code runs prior to general startup code
! that initializes \s-1RAM\s0 and calls constructors, but after the bit
! of startup code from AVR-LibC that sets \f(CW\*(C`EIND\*(C'\fR to the segment
  where the vector table is located.
  .Sp
  .Vb 1
--- 22256,22300 ----
  .PP
  Indirect jumps and calls on these devices are handled as follows by
  the compiler and are subject to some limitations:
! .IP * 4
  The compiler never sets \f(CW\*(C`EIND\*(C'\fR.
! .IP * 4
  The compiler uses \f(CW\*(C`EIND\*(C'\fR implicitly in \f(CW\*(C`EICALL\*(C'\fR/\f(CW\*(C`EIJMP\*(C'\fR
  instructions or might read \f(CW\*(C`EIND\*(C'\fR directly in order to emulate an
  indirect call/jump by means of a \f(CW\*(C`RET\*(C'\fR instruction.
! .IP * 4
  The compiler assumes that \f(CW\*(C`EIND\*(C'\fR never changes during the startup
  code or during the application. In particular, \f(CW\*(C`EIND\*(C'\fR is not
  saved/restored in function or interrupt service routine
  prologue/epilogue.
! .IP * 4
  For indirect calls to functions and computed goto, the linker
  generates \fIstubs\fR. Stubs are jump pads sometimes also called
  \&\fItrampolines\fR. Thus, the indirect call/jump jumps to such a stub.
  The stub contains a direct jump to the desired address.
! .IP * 4
  Linker relaxation must be turned on so that the linker generates
  the stubs correctly in all situations. See the compiler option
  \&\fB\-mrelax\fR and the linker option \fB\-\-relax\fR.
  There are corner cases where the linker is supposed to generate stubs
  but aborts without relaxation and without a helpful error message.
! .IP * 4
  The default linker script is arranged for code with \f(CW\*(C`EIND = 0\*(C'\fR.
  If code is supposed to work for a setup with \f(CW\*(C`EIND != 0\*(C'\fR, a custom
  linker script has to be used in order to place the sections whose
  name start with \f(CW\*(C`.trampolines\*(C'\fR into the segment where \f(CW\*(C`EIND\*(C'\fR
  points to.
! .IP * 4
  The startup code from libgcc never sets \f(CW\*(C`EIND\*(C'\fR.
! Notice that startup code is a blend of code from libgcc and AVR\-LibC.
! For the impact of AVR\-LibC on \f(CW\*(C`EIND\*(C'\fR, see the
! AVR\-LibC\ user\ manual (\f(CW\*(C`https://www.nongnu.org/avr\-libc/user\-manual/\*(C'\fR).
! .IP * 4
! It is legitimate for user\-specific startup code to set up \f(CW\*(C`EIND\*(C'\fR
  early, for example by means of initialization code located in
  section \f(CW\*(C`.init3\*(C'\fR. Such code runs prior to general startup code
! that initializes RAM and calls constructors, but after the bit
! of startup code from AVR\-LibC that sets \f(CW\*(C`EIND\*(C'\fR to the segment
  where the vector table is located.
  .Sp
  .Vb 1
*************** where the vector table is located.
*** 22379,22385 ****
  .Ve
  .Sp
  The \f(CW\*(C`_\|_trampolines_start\*(C'\fR symbol is defined in the linker script.
! .IP "*" 4
  Stubs are generated automatically by the linker if
  the following two conditions are met:
  .RS 4
--- 22310,22316 ----
  .Ve
  .Sp
  The \f(CW\*(C`_\|_trampolines_start\*(C'\fR symbol is defined in the linker script.
! .IP * 4
  Stubs are generated automatically by the linker if
  the following two conditions are met:
  .RS 4
*************** the following two conditions are met:
*** 22398,22404 ****
  .RE
  .RS 4
  .RE
! .IP "*" 4
  The compiler emits such \f(CW\*(C`gs\*(C'\fR modifiers for code labels in the
  following situations:
  .RS 4
--- 22329,22335 ----
  .RE
  .RS 4
  .RE
! .IP * 4
  The compiler emits such \f(CW\*(C`gs\*(C'\fR modifiers for code labels in the
  following situations:
  .RS 4
*************** following situations:
*** 22407,22431 ****
  .PD 0
  .IP "\-" 4
  .IX Item "-"
! .IP "\-" 4
  .IX Item "-"
  .PD
! command-line option.
  .IP "\-" 4
  .IX Item "-"
! tables you can specify the \fB\-fno\-jump\-tables\fR command-line option.
! .IP "\-" 4
! .IX Item "-"
  .PD 0
! .ie n .IP "\-" 4
  .el .IP "\-" 4
  .IX Item "-"
  .RE
  .RS 4
  .RE
! .IP "*" 4
! .PD
! Jumping to non-symbolic addresses like so is \fInot\fR supported:
  .Sp
  .Vb 5
  \&        int main (void)
--- 22338,22362 ----
  .PD 0
  .IP "\-" 4
  .IX Item "-"
! .IP "\-" 4
  .IX Item "-"
  .PD
! command\-line option.
  .IP "\-" 4
  .IX Item "-"
! tables you can specify the \fB\-fno\-jump\-tables\fR command\-line option.
! .IP "\-" 4
! .IX Item "-"
  .PD 0
! .ie n .IP "\-" 4
  .el .IP "\-" 4
  .IX Item "-"
+ .PD
  .RE
  .RS 4
  .RE
! .IP * 4
! Jumping to non\-symbolic addresses like so is \fInot\fR supported:
  .Sp
  .Vb 5
  \&        int main (void)
*************** Alternatively, \f(CW\*(C`func_4\*(C'\fR
*** 22454,22460 ****
  Handling of the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR and \f(CW\*(C`RAMPZ\*(C'\fR Special Function Registers
  .IX Subsection "Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers"
  .PP
! Some \s-1AVR\s0 devices support memories larger than the 64 KiB range
  that can be accessed with 16\-bit pointers.  To access memory locations
  outside this 64 KiB range, the content of a \f(CW\*(C`RAMP\*(C'\fR
  register is used as high part of the address:
--- 22385,22391 ----
  Handling of the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR and \f(CW\*(C`RAMPZ\*(C'\fR Special Function Registers
  .IX Subsection "Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers"
  .PP
! Some AVR devices support memories larger than the 64 KiB range
  that can be accessed with 16\-bit pointers.  To access memory locations
  outside this 64 KiB range, the content of a \f(CW\*(C`RAMP\*(C'\fR
  register is used as high part of the address:
*************** The \f(CW\*(C`X\*(C'\fR, \f(CW\*(C`Y\*(C
*** 22462,22502 ****
  with the \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR, \f(CW\*(C`RAMPZ\*(C'\fR special function
  register, respectively, to get a wide address. Similarly,
  \&\f(CW\*(C`RAMPD\*(C'\fR is used together with direct addressing.
! .IP "*" 4
  The startup code initializes the \f(CW\*(C`RAMP\*(C'\fR special function
  registers with zero.
! .IP "*" 4
! If a \fB\s-1AVR\s0 Named Address Spaces,named address space\fR other than
  generic or \f(CW\*(C`_\|_flash\*(C'\fR is used, then \f(CW\*(C`RAMPZ\*(C'\fR is set
  as needed before the operation.
! .IP "*" 4
! If the device supports \s-1RAM\s0 larger than 64 KiB and the compiler
  needs to change \f(CW\*(C`RAMPZ\*(C'\fR to accomplish an operation, \f(CW\*(C`RAMPZ\*(C'\fR
  is reset to zero after the operation.
! .IP "*" 4
! If the device comes with a specific \f(CW\*(C`RAMP\*(C'\fR register, the \s-1ISR\s0
! prologue/epilogue saves/restores that \s-1SFR\s0 and initializes it with
! zero in case the \s-1ISR\s0 code might (implicitly) use it.
! .IP "*" 4
! \&\s-1RAM\s0 larger than 64 KiB is not supported by \s-1GCC\s0 for \s-1AVR\s0 targets.
  If you use inline assembler to read from locations outside the
  16\-bit address range and change one of the \f(CW\*(C`RAMP\*(C'\fR registers,
  you must reset it to zero after the access.
  .PP
! \s-1AVR\s0 Built-in Macros
  .IX Subsection "AVR Built-in Macros"
  .PP
! \&\s-1GCC\s0 defines several built-in macros so that the user code can test
  for the presence or absence of features.  Almost any of the following
! built-in macros are deduced from device capabilities and thus
! triggered by the \fB\-mmcu=\fR command-line option.
  .PP
! For even more AVR-specific built-in macros see
! \&\fB\s-1AVR\s0 Named Address Spaces\fR and \fB\s-1AVR\s0 Built-in Functions\fR.
  .ie n .IP """_\|_AVR_ARCH_\|_""" 4
! .el .IP "\f(CW_\|_AVR_ARCH_\|_\fR" 4
  .IX Item "__AVR_ARCH__"
! Build-in macro that resolves to a decimal number that identifies the
  architecture and depends on the \fB\-mmcu=\fR\fImcu\fR option.
  Possible values are:
  .Sp
--- 22393,22433 ----
  with the \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR, \f(CW\*(C`RAMPZ\*(C'\fR special function
  register, respectively, to get a wide address. Similarly,
  \&\f(CW\*(C`RAMPD\*(C'\fR is used together with direct addressing.
! .IP * 4
  The startup code initializes the \f(CW\*(C`RAMP\*(C'\fR special function
  registers with zero.
! .IP * 4
! If a \fBAVR Named Address Spaces,named address space\fR other than
  generic or \f(CW\*(C`_\|_flash\*(C'\fR is used, then \f(CW\*(C`RAMPZ\*(C'\fR is set
  as needed before the operation.
! .IP * 4
! If the device supports RAM larger than 64 KiB and the compiler
  needs to change \f(CW\*(C`RAMPZ\*(C'\fR to accomplish an operation, \f(CW\*(C`RAMPZ\*(C'\fR
  is reset to zero after the operation.
! .IP * 4
! If the device comes with a specific \f(CW\*(C`RAMP\*(C'\fR register, the ISR
! prologue/epilogue saves/restores that SFR and initializes it with
! zero in case the ISR code might (implicitly) use it.
! .IP * 4
! RAM larger than 64 KiB is not supported by GCC for AVR targets.
  If you use inline assembler to read from locations outside the
  16\-bit address range and change one of the \f(CW\*(C`RAMP\*(C'\fR registers,
  you must reset it to zero after the access.
  .PP
! AVR Built\-in Macros
  .IX Subsection "AVR Built-in Macros"
  .PP
! GCC defines several built\-in macros so that the user code can test
  for the presence or absence of features.  Almost any of the following
! built\-in macros are deduced from device capabilities and thus
! triggered by the \fB\-mmcu=\fR command\-line option.
  .PP
! For even more AVR\-specific built\-in macros see
! \&\fBAVR Named Address Spaces\fR and \fBAVR Built\-in Functions\fR.
  .ie n .IP """_\|_AVR_ARCH_\|_""" 4
! .el .IP \f(CW_\|_AVR_ARCH_\|_\fR 4
  .IX Item "__AVR_ARCH__"
! Build\-in macro that resolves to a decimal number that identifies the
  architecture and depends on the \fB\-mmcu=\fR\fImcu\fR option.
  Possible values are:
  .Sp
*************** respectively and
*** 22515,22778 ****
  for \fImcu\fR=\f(CW\*(C`avrtiny\*(C'\fR,
  \&\f(CW\*(C`avrxmega2\*(C'\fR, \f(CW\*(C`avrxmega3\*(C'\fR, \f(CW\*(C`avrxmega4\*(C'\fR,
  \&\f(CW\*(C`avrxmega5\*(C'\fR, \f(CW\*(C`avrxmega6\*(C'\fR, \f(CW\*(C`avrxmega7\*(C'\fR, respectively.
! If \fImcu\fR specifies a device, this built-in macro is set
  accordingly. For example, with \fB\-mmcu=atmega8\fR the macro is
  defined to \f(CW4\fR.
! .ie n .IP """_\|_AVR_\fIDevice\fP_\|_""" 4
! .el .IP "\f(CW_\|_AVR_\f(CIDevice\f(CW_\|_\fR" 4
  .IX Item "__AVR_Device__"
! Setting \fB\-mmcu=\fR\fIdevice\fR defines this built-in macro which reflects
! the device's name. For example, \fB\-mmcu=atmega8\fR defines the
! built-in macro \f(CW\*(C`_\|_AVR_ATmega8_\|_\*(C'\fR, \fB\-mmcu=attiny261a\fR defines
  \&\f(CW\*(C`_\|_AVR_ATtiny261A_\|_\*(C'\fR, etc.
  .Sp
! The built-in macros' names follow
! the scheme \f(CW\*(C`_\|_AVR_\f(CIDevice\f(CW_\|_\*(C'\fR where \fIDevice\fR is
! the device name as from the \s-1AVR\s0 user manual. The difference between
! \&\fIDevice\fR in the built-in macro and \fIdevice\fR in
  \&\fB\-mmcu=\fR\fIdevice\fR is that the latter is always lowercase.
  .Sp
  If \fIdevice\fR is not a device but only a core architecture like
  \&\fBavr51\fR, this macro is not defined.
  .ie n .IP """_\|_AVR_DEVICE_NAME_\|_""" 4
! .el .IP "\f(CW_\|_AVR_DEVICE_NAME_\|_\fR" 4
  .IX Item "__AVR_DEVICE_NAME__"
! Setting \fB\-mmcu=\fR\fIdevice\fR defines this built-in macro to
! the device's name. For example, with \fB\-mmcu=atmega8\fR the macro
  is defined to \f(CW\*(C`atmega8\*(C'\fR.
  .Sp
  If \fIdevice\fR is not a device but only a core architecture like
  \&\fBavr51\fR, this macro is not defined.
  .ie n .IP """_\|_AVR_XMEGA_\|_""" 4
! .el .IP "\f(CW_\|_AVR_XMEGA_\|_\fR" 4
  .IX Item "__AVR_XMEGA__"
! The device / architecture belongs to the \s-1XMEGA\s0 family of devices.
  .ie n .IP """_\|_AVR_HAVE_ADIW_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_ADIW_\|_\fR" 4
  .IX Item "__AVR_HAVE_ADIW__"
  The device has the \f(CW\*(C`ADIW\*(C'\fR and \f(CW\*(C`SBIW\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_ELPM_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_ELPM_\|_\fR" 4
  .IX Item "__AVR_HAVE_ELPM__"
  The device has the \f(CW\*(C`ELPM\*(C'\fR instruction.
  .ie n .IP """_\|_AVR_HAVE_ELPMX_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_ELPMX_\|_\fR" 4
  .IX Item "__AVR_HAVE_ELPMX__"
! The device has the \f(CW\*(C`ELPM R\f(CIn\f(CW,Z\*(C'\fR and \f(CW\*(C`ELPM
! R\f(CIn\f(CW,Z+\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_LPMX_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_LPMX_\|_\fR" 4
  .IX Item "__AVR_HAVE_LPMX__"
! The device has the \f(CW\*(C`LPM R\f(CIn\f(CW,Z\*(C'\fR and
! \&\f(CW\*(C`LPM R\f(CIn\f(CW,Z+\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_MOVW_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_MOVW_\|_\fR" 4
  .IX Item "__AVR_HAVE_MOVW__"
  The device has the \f(CW\*(C`MOVW\*(C'\fR instruction to perform 16\-bit
! register-register moves.
  .ie n .IP """_\|_AVR_HAVE_MUL_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_MUL_\|_\fR" 4
  .IX Item "__AVR_HAVE_MUL__"
  The device has a hardware multiplier.
  .ie n .IP """_\|_AVR_HAVE_JMP_CALL_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_JMP_CALL_\|_\fR" 4
  .IX Item "__AVR_HAVE_JMP_CALL__"
  The device has the \f(CW\*(C`JMP\*(C'\fR and \f(CW\*(C`CALL\*(C'\fR instructions.
  This is the case for devices with more than 8 KiB of program
  memory.
  .ie n .IP """_\|_AVR_HAVE_EIJMP_EICALL_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_EIJMP_EICALL_\|_\fR" 4
  .IX Item "__AVR_HAVE_EIJMP_EICALL__"
  .PD 0
  .ie n .IP """_\|_AVR_3_BYTE_PC_\|_""" 4
! .el .IP "\f(CW_\|_AVR_3_BYTE_PC_\|_\fR" 4
  .IX Item "__AVR_3_BYTE_PC__"
  .PD
  The device has the \f(CW\*(C`EIJMP\*(C'\fR and \f(CW\*(C`EICALL\*(C'\fR instructions.
  This is the case for devices with more than 128 KiB of program memory.
  This also means that the program counter
! (\s-1PC\s0) is 3 bytes wide.
  .ie n .IP """_\|_AVR_2_BYTE_PC_\|_""" 4
! .el .IP "\f(CW_\|_AVR_2_BYTE_PC_\|_\fR" 4
  .IX Item "__AVR_2_BYTE_PC__"
! The program counter (\s-1PC\s0) is 2 bytes wide. This is the case for devices
  with up to 128 KiB of program memory.
  .ie n .IP """_\|_AVR_HAVE_8BIT_SP_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_8BIT_SP_\|_\fR" 4
  .IX Item "__AVR_HAVE_8BIT_SP__"
  .PD 0
  .ie n .IP """_\|_AVR_HAVE_16BIT_SP_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_16BIT_SP_\|_\fR" 4
  .IX Item "__AVR_HAVE_16BIT_SP__"
  .PD
! The stack pointer (\s-1SP\s0) register is treated as 8\-bit respectively
  16\-bit register by the compiler.
  The definition of these macros is affected by \fB\-mtiny\-stack\fR.
  .ie n .IP """_\|_AVR_HAVE_SPH_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_SPH_\|_\fR" 4
  .IX Item "__AVR_HAVE_SPH__"
  .PD 0
  .ie n .IP """_\|_AVR_SP8_\|_""" 4
! .el .IP "\f(CW_\|_AVR_SP8_\|_\fR" 4
  .IX Item "__AVR_SP8__"
  .PD
! The device has the \s-1SPH\s0 (high part of stack pointer) special function
  register or has an 8\-bit stack pointer, respectively.
  The definition of these macros is affected by \fB\-mmcu=\fR and
  in the cases of \fB\-mmcu=avr2\fR and \fB\-mmcu=avr25\fR also
  by \fB\-msp8\fR.
  .ie n .IP """_\|_AVR_HAVE_RAMPD_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_RAMPD_\|_\fR" 4
  .IX Item "__AVR_HAVE_RAMPD__"
  .PD 0
  .ie n .IP """_\|_AVR_HAVE_RAMPX_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_RAMPX_\|_\fR" 4
  .IX Item "__AVR_HAVE_RAMPX__"
  .ie n .IP """_\|_AVR_HAVE_RAMPY_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_RAMPY_\|_\fR" 4
  .IX Item "__AVR_HAVE_RAMPY__"
  .ie n .IP """_\|_AVR_HAVE_RAMPZ_\|_""" 4
! .el .IP "\f(CW_\|_AVR_HAVE_RAMPZ_\|_\fR" 4
  .IX Item "__AVR_HAVE_RAMPZ__"
  .PD
  The device has the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR,
  \&\f(CW\*(C`RAMPZ\*(C'\fR special function register, respectively.
  .ie n .IP """_\|_NO_INTERRUPTS_\|_""" 4
! .el .IP "\f(CW_\|_NO_INTERRUPTS_\|_\fR" 4
  .IX Item "__NO_INTERRUPTS__"
! This macro reflects the \fB\-mno\-interrupts\fR command-line option.
  .ie n .IP """_\|_AVR_ERRATA_SKIP_\|_""" 4
! .el .IP "\f(CW_\|_AVR_ERRATA_SKIP_\|_\fR" 4
  .IX Item "__AVR_ERRATA_SKIP__"
  .PD 0
  .ie n .IP """_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_""" 4
! .el .IP "\f(CW_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_\fR" 4
  .IX Item "__AVR_ERRATA_SKIP_JMP_CALL__"
  .PD
! Some \s-1AVR\s0 devices (\s-1AT90S8515,\s0 ATmega103) must not skip 32\-bit
  instructions because of a hardware erratum.  Skip instructions are
  \&\f(CW\*(C`SBRS\*(C'\fR, \f(CW\*(C`SBRC\*(C'\fR, \f(CW\*(C`SBIS\*(C'\fR, \f(CW\*(C`SBIC\*(C'\fR and \f(CW\*(C`CPSE\*(C'\fR.
  The second macro is only defined if \f(CW\*(C`_\|_AVR_HAVE_JMP_CALL_\|_\*(C'\fR is also
  set.
  .ie n .IP """_\|_AVR_ISA_RMW_\|_""" 4
! .el .IP "\f(CW_\|_AVR_ISA_RMW_\|_\fR" 4
  .IX Item "__AVR_ISA_RMW__"
! The device has Read-Modify-Write instructions (\s-1XCH, LAC, LAS\s0 and \s-1LAT\s0).
! .ie n .IP """_\|_AVR_SFR_OFFSET_\|_=\fIoffset\fP""" 4
! .el .IP "\f(CW_\|_AVR_SFR_OFFSET_\|_=\f(CIoffset\f(CW\fR" 4
  .IX Item "__AVR_SFR_OFFSET__=offset"
  Instructions that can address I/O special function registers directly
  like \f(CW\*(C`IN\*(C'\fR, \f(CW\*(C`OUT\*(C'\fR, \f(CW\*(C`SBI\*(C'\fR, etc. may use a different
! address as if addressed by an instruction to access \s-1RAM\s0 like \f(CW\*(C`LD\*(C'\fR
  or \f(CW\*(C`STS\*(C'\fR. This offset depends on the device architecture and has
! to be subtracted from the \s-1RAM\s0 address in order to get the
  respective I/O address.
  .ie n .IP """_\|_AVR_SHORT_CALLS_\|_""" 4
! .el .IP "\f(CW_\|_AVR_SHORT_CALLS_\|_\fR" 4
  .IX Item "__AVR_SHORT_CALLS__"
  The \fB\-mshort\-calls\fR command line option is set.
! .ie n .IP """_\|_AVR_PM_BASE_ADDRESS_\|_=\fIaddr\fP""" 4
! .el .IP "\f(CW_\|_AVR_PM_BASE_ADDRESS_\|_=\f(CIaddr\f(CW\fR" 4
  .IX Item "__AVR_PM_BASE_ADDRESS__=addr"
  Some devices support reading from flash memory by means of \f(CW\*(C`LD*\*(C'\fR
  instructions.  The flash memory is seen in the data address space
  at an offset of \f(CW\*(C`_\|_AVR_PM_BASE_ADDRESS_\|_\*(C'\fR.  If this macro
  is not defined, this feature is not available.  If defined,
  the address space is linear and there is no need to put
! \&\f(CW\*(C`.rodata\*(C'\fR into \s-1RAM.\s0  This is handled by the default linker
  description file, and is currently available for
  \&\f(CW\*(C`avrtiny\*(C'\fR and \f(CW\*(C`avrxmega3\*(C'\fR.  Even more convenient,
  there is no need to use address spaces like \f(CW\*(C`_\|_flash\*(C'\fR or
  features like attribute \f(CW\*(C`progmem\*(C'\fR and \f(CW\*(C`pgm_read_*\*(C'\fR.
  .ie n .IP """_\|_WITH_AVRLIBC_\|_""" 4
! .el .IP "\f(CW_\|_WITH_AVRLIBC_\|_\fR" 4
  .IX Item "__WITH_AVRLIBC__"
! The compiler is configured to be used together with AVR-Libc.
  See the \fB\-\-with\-avrlibc\fR configure option.
  .ie n .IP """_\|_HAVE_DOUBLE_MULTILIB_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_DOUBLE_MULTILIB_\|_\fR" 4
  .IX Item "__HAVE_DOUBLE_MULTILIB__"
  Defined if \fB\-mdouble=\fR acts as a multilib option.
  .ie n .IP """_\|_HAVE_DOUBLE32_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_DOUBLE32_\|_\fR" 4
  .IX Item "__HAVE_DOUBLE32__"
  .PD 0
  .ie n .IP """_\|_HAVE_DOUBLE64_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_DOUBLE64_\|_\fR" 4
  .IX Item "__HAVE_DOUBLE64__"
  .PD
  Defined if the compiler supports 32\-bit double resp. 64\-bit double.
  The actual layout is specified by option \fB\-mdouble=\fR.
  .ie n .IP """_\|_DEFAULT_DOUBLE_\|_""" 4
! .el .IP "\f(CW_\|_DEFAULT_DOUBLE_\|_\fR" 4
  .IX Item "__DEFAULT_DOUBLE__"
  The size in bits of \f(CW\*(C`double\*(C'\fR if \fB\-mdouble=\fR is not set.
! To test the layout of \f(CW\*(C`double\*(C'\fR in a program, use the built-in
  macro \f(CW\*(C`_\|_SIZEOF_DOUBLE_\|_\*(C'\fR.
  .ie n .IP """_\|_HAVE_LONG_DOUBLE32_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_LONG_DOUBLE32_\|_\fR" 4
  .IX Item "__HAVE_LONG_DOUBLE32__"
  .PD 0
  .ie n .IP """_\|_HAVE_LONG_DOUBLE64_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_LONG_DOUBLE64_\|_\fR" 4
  .IX Item "__HAVE_LONG_DOUBLE64__"
  .ie n .IP """_\|_HAVE_LONG_DOUBLE_MULTILIB_\|_""" 4
! .el .IP "\f(CW_\|_HAVE_LONG_DOUBLE_MULTILIB_\|_\fR" 4
  .IX Item "__HAVE_LONG_DOUBLE_MULTILIB__"
  .ie n .IP """_\|_DEFAULT_LONG_DOUBLE_\|_""" 4
! .el .IP "\f(CW_\|_DEFAULT_LONG_DOUBLE_\|_\fR" 4
  .IX Item "__DEFAULT_LONG_DOUBLE__"
  .PD
  Same as above, but for \f(CW\*(C`long double\*(C'\fR instead of \f(CW\*(C`double\*(C'\fR.
  .ie n .IP """_\|_WITH_DOUBLE_COMPARISON_\|_""" 4
! .el .IP "\f(CW_\|_WITH_DOUBLE_COMPARISON_\|_\fR" 4
  .IX Item "__WITH_DOUBLE_COMPARISON__"
  Reflects the \f(CW\*(C`\-\-with\-double\-comparison={tristate|bool|libf7}\*(C'\fR
  configure\ option (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR)
  and is defined to \f(CW2\fR or \f(CW3\fR.
  .ie n .IP """_\|_WITH_LIBF7_LIBGCC_\|_""" 4
! .el .IP "\f(CW_\|_WITH_LIBF7_LIBGCC_\|_\fR" 4
  .IX Item "__WITH_LIBF7_LIBGCC__"
  .PD 0
  .ie n .IP """_\|_WITH_LIBF7_MATH_\|_""" 4
! .el .IP "\f(CW_\|_WITH_LIBF7_MATH_\|_\fR" 4
  .IX Item "__WITH_LIBF7_MATH__"
  .ie n .IP """_\|_WITH_LIBF7_MATH_SYMBOLS_\|_""" 4
! .el .IP "\f(CW_\|_WITH_LIBF7_MATH_SYMBOLS_\|_\fR" 4
  .IX Item "__WITH_LIBF7_MATH_SYMBOLS__"
  .PD
  Reflects the \f(CW\*(C`\-\-with\-libf7={libgcc|math|math\-symbols}\*(C'\fR
  configure\ option (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR).
  .PP
! \s-1AVR\s0 Internal Options
  .IX Subsection "AVR Internal Options"
  .PP
  The following options are used internally by the compiler and to communicate
! between device specs files and the compiler proper. You don't need to set these
  options by hand, in particular they are not optimization options.
! Using these options in the wrong way may lead to sub-optimal or wrong code.
  They are documented for completeness, and in order to get a better
  understanding of
  device\ specs (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#spec\-files\*(C'\fR)
  files.
! .IP "\fB\-mn\-flash=\fR\fInum\fR" 4
  .IX Item "-mn-flash=num"
  Assume that the flash memory has a size of \fInum\fR times 64 KiB.
! This determines which \f(CW\*(C`_\|_flash\f(CIN\f(CW\*(C'\fR address spaces are available.
! .IP "\fB\-mrmw\fR" 4
  .IX Item "-mrmw"
! Assume that the device supports the Read-Modify-Write
  instructions \f(CW\*(C`XCH\*(C'\fR, \f(CW\*(C`LAC\*(C'\fR, \f(CW\*(C`LAS\*(C'\fR and \f(CW\*(C`LAT\*(C'\fR.
! .IP "\fB\-mshort\-calls\fR" 4
  .IX Item "-mshort-calls"
  Assume that \f(CW\*(C`RJMP\*(C'\fR and \f(CW\*(C`RCALL\*(C'\fR can target the whole
  program memory. This option is used for multilib generation and selection
  for the devices from architecture \f(CW\*(C`avrxmega3\*(C'\fR.
! .IP "\fB\-mskip\-bug\fR" 4
  .IX Item "-mskip-bug"
  Generate code without skips (\f(CW\*(C`CPSE\*(C'\fR, \f(CW\*(C`SBRS\*(C'\fR,
  \&\f(CW\*(C`SBRC\*(C'\fR, \f(CW\*(C`SBIS\*(C'\fR, \f(CW\*(C`SBIC\*(C'\fR) over 32\-bit instructions.
! .IP "\fB\-msp8\fR" 4
  .IX Item "-msp8"
  Treat the stack pointer register as an 8\-bit register,
  i.e. assume the high byte of the stack pointer is zero.
--- 22446,22709 ----
  for \fImcu\fR=\f(CW\*(C`avrtiny\*(C'\fR,
  \&\f(CW\*(C`avrxmega2\*(C'\fR, \f(CW\*(C`avrxmega3\*(C'\fR, \f(CW\*(C`avrxmega4\*(C'\fR,
  \&\f(CW\*(C`avrxmega5\*(C'\fR, \f(CW\*(C`avrxmega6\*(C'\fR, \f(CW\*(C`avrxmega7\*(C'\fR, respectively.
! If \fImcu\fR specifies a device, this built\-in macro is set
  accordingly. For example, with \fB\-mmcu=atmega8\fR the macro is
  defined to \f(CW4\fR.
! .ie n .IP """_\|_AVR_\fIDevice\fR_\|_""" 4
! .el .IP \f(CW_\|_AVR_\fR\f(CIDevice\fR\f(CW_\|_\fR 4
  .IX Item "__AVR_Device__"
! Setting \fB\-mmcu=\fR\fIdevice\fR defines this built\-in macro which reflects
! the device\*(Aqs name. For example, \fB\-mmcu=atmega8\fR defines the
! built\-in macro \f(CW\*(C`_\|_AVR_ATmega8_\|_\*(C'\fR, \fB\-mmcu=attiny261a\fR defines
  \&\f(CW\*(C`_\|_AVR_ATtiny261A_\|_\*(C'\fR, etc.
  .Sp
! The built\-in macros\*(Aq names follow
! the scheme \f(CW\*(C`_\|_AVR_\fR\f(CIDevice\fR\f(CW_\|_\*(C'\fR where \fIDevice\fR is
! the device name as from the AVR user manual. The difference between
! \&\fIDevice\fR in the built\-in macro and \fIdevice\fR in
  \&\fB\-mmcu=\fR\fIdevice\fR is that the latter is always lowercase.
  .Sp
  If \fIdevice\fR is not a device but only a core architecture like
  \&\fBavr51\fR, this macro is not defined.
  .ie n .IP """_\|_AVR_DEVICE_NAME_\|_""" 4
! .el .IP \f(CW_\|_AVR_DEVICE_NAME_\|_\fR 4
  .IX Item "__AVR_DEVICE_NAME__"
! Setting \fB\-mmcu=\fR\fIdevice\fR defines this built\-in macro to
! the device\*(Aqs name. For example, with \fB\-mmcu=atmega8\fR the macro
  is defined to \f(CW\*(C`atmega8\*(C'\fR.
  .Sp
  If \fIdevice\fR is not a device but only a core architecture like
  \&\fBavr51\fR, this macro is not defined.
  .ie n .IP """_\|_AVR_XMEGA_\|_""" 4
! .el .IP \f(CW_\|_AVR_XMEGA_\|_\fR 4
  .IX Item "__AVR_XMEGA__"
! The device / architecture belongs to the XMEGA family of devices.
  .ie n .IP """_\|_AVR_HAVE_ADIW_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_ADIW_\|_\fR 4
  .IX Item "__AVR_HAVE_ADIW__"
  The device has the \f(CW\*(C`ADIW\*(C'\fR and \f(CW\*(C`SBIW\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_ELPM_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_ELPM_\|_\fR 4
  .IX Item "__AVR_HAVE_ELPM__"
  The device has the \f(CW\*(C`ELPM\*(C'\fR instruction.
  .ie n .IP """_\|_AVR_HAVE_ELPMX_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_ELPMX_\|_\fR 4
  .IX Item "__AVR_HAVE_ELPMX__"
! The device has the \f(CW\*(C`ELPM R\fR\f(CIn\fR\f(CW,Z\*(C'\fR and \f(CW\*(C`ELPM
! R\fR\f(CIn\fR\f(CW,Z+\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_LPMX_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_LPMX_\|_\fR 4
  .IX Item "__AVR_HAVE_LPMX__"
! The device has the \f(CW\*(C`LPM R\fR\f(CIn\fR\f(CW,Z\*(C'\fR and
! \&\f(CW\*(C`LPM R\fR\f(CIn\fR\f(CW,Z+\*(C'\fR instructions.
  .ie n .IP """_\|_AVR_HAVE_MOVW_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_MOVW_\|_\fR 4
  .IX Item "__AVR_HAVE_MOVW__"
  The device has the \f(CW\*(C`MOVW\*(C'\fR instruction to perform 16\-bit
! register\-register moves.
  .ie n .IP """_\|_AVR_HAVE_MUL_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_MUL_\|_\fR 4
  .IX Item "__AVR_HAVE_MUL__"
  The device has a hardware multiplier.
  .ie n .IP """_\|_AVR_HAVE_JMP_CALL_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_JMP_CALL_\|_\fR 4
  .IX Item "__AVR_HAVE_JMP_CALL__"
  The device has the \f(CW\*(C`JMP\*(C'\fR and \f(CW\*(C`CALL\*(C'\fR instructions.
  This is the case for devices with more than 8 KiB of program
  memory.
  .ie n .IP """_\|_AVR_HAVE_EIJMP_EICALL_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_EIJMP_EICALL_\|_\fR 4
  .IX Item "__AVR_HAVE_EIJMP_EICALL__"
  .PD 0
  .ie n .IP """_\|_AVR_3_BYTE_PC_\|_""" 4
! .el .IP \f(CW_\|_AVR_3_BYTE_PC_\|_\fR 4
  .IX Item "__AVR_3_BYTE_PC__"
  .PD
  The device has the \f(CW\*(C`EIJMP\*(C'\fR and \f(CW\*(C`EICALL\*(C'\fR instructions.
  This is the case for devices with more than 128 KiB of program memory.
  This also means that the program counter
! (PC) is 3 bytes wide.
  .ie n .IP """_\|_AVR_2_BYTE_PC_\|_""" 4
! .el .IP \f(CW_\|_AVR_2_BYTE_PC_\|_\fR 4
  .IX Item "__AVR_2_BYTE_PC__"
! The program counter (PC) is 2 bytes wide. This is the case for devices
  with up to 128 KiB of program memory.
  .ie n .IP """_\|_AVR_HAVE_8BIT_SP_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_8BIT_SP_\|_\fR 4
  .IX Item "__AVR_HAVE_8BIT_SP__"
  .PD 0
  .ie n .IP """_\|_AVR_HAVE_16BIT_SP_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_16BIT_SP_\|_\fR 4
  .IX Item "__AVR_HAVE_16BIT_SP__"
  .PD
! The stack pointer (SP) register is treated as 8\-bit respectively
  16\-bit register by the compiler.
  The definition of these macros is affected by \fB\-mtiny\-stack\fR.
  .ie n .IP """_\|_AVR_HAVE_SPH_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_SPH_\|_\fR 4
  .IX Item "__AVR_HAVE_SPH__"
  .PD 0
  .ie n .IP """_\|_AVR_SP8_\|_""" 4
! .el .IP \f(CW_\|_AVR_SP8_\|_\fR 4
  .IX Item "__AVR_SP8__"
  .PD
! The device has the SPH (high part of stack pointer) special function
  register or has an 8\-bit stack pointer, respectively.
  The definition of these macros is affected by \fB\-mmcu=\fR and
  in the cases of \fB\-mmcu=avr2\fR and \fB\-mmcu=avr25\fR also
  by \fB\-msp8\fR.
  .ie n .IP """_\|_AVR_HAVE_RAMPD_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_RAMPD_\|_\fR 4
  .IX Item "__AVR_HAVE_RAMPD__"
  .PD 0
  .ie n .IP """_\|_AVR_HAVE_RAMPX_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_RAMPX_\|_\fR 4
  .IX Item "__AVR_HAVE_RAMPX__"
  .ie n .IP """_\|_AVR_HAVE_RAMPY_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_RAMPY_\|_\fR 4
  .IX Item "__AVR_HAVE_RAMPY__"
  .ie n .IP """_\|_AVR_HAVE_RAMPZ_\|_""" 4
! .el .IP \f(CW_\|_AVR_HAVE_RAMPZ_\|_\fR 4
  .IX Item "__AVR_HAVE_RAMPZ__"
  .PD
  The device has the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR,
  \&\f(CW\*(C`RAMPZ\*(C'\fR special function register, respectively.
  .ie n .IP """_\|_NO_INTERRUPTS_\|_""" 4
! .el .IP \f(CW_\|_NO_INTERRUPTS_\|_\fR 4
  .IX Item "__NO_INTERRUPTS__"
! This macro reflects the \fB\-mno\-interrupts\fR command\-line option.
  .ie n .IP """_\|_AVR_ERRATA_SKIP_\|_""" 4
! .el .IP \f(CW_\|_AVR_ERRATA_SKIP_\|_\fR 4
  .IX Item "__AVR_ERRATA_SKIP__"
  .PD 0
  .ie n .IP """_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_""" 4
! .el .IP \f(CW_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_\fR 4
  .IX Item "__AVR_ERRATA_SKIP_JMP_CALL__"
  .PD
! Some AVR devices (AT90S8515, ATmega103) must not skip 32\-bit
  instructions because of a hardware erratum.  Skip instructions are
  \&\f(CW\*(C`SBRS\*(C'\fR, \f(CW\*(C`SBRC\*(C'\fR, \f(CW\*(C`SBIS\*(C'\fR, \f(CW\*(C`SBIC\*(C'\fR and \f(CW\*(C`CPSE\*(C'\fR.
  The second macro is only defined if \f(CW\*(C`_\|_AVR_HAVE_JMP_CALL_\|_\*(C'\fR is also
  set.
  .ie n .IP """_\|_AVR_ISA_RMW_\|_""" 4
! .el .IP \f(CW_\|_AVR_ISA_RMW_\|_\fR 4
  .IX Item "__AVR_ISA_RMW__"
! The device has Read\-Modify\-Write instructions (XCH, LAC, LAS and LAT).
! .ie n .IP """_\|_AVR_SFR_OFFSET_\|_=\fIoffset\fR""" 4
! .el .IP \f(CW_\|_AVR_SFR_OFFSET_\|_=\fR\f(CIoffset\fR\f(CW\fR 4
  .IX Item "__AVR_SFR_OFFSET__=offset"
  Instructions that can address I/O special function registers directly
  like \f(CW\*(C`IN\*(C'\fR, \f(CW\*(C`OUT\*(C'\fR, \f(CW\*(C`SBI\*(C'\fR, etc. may use a different
! address as if addressed by an instruction to access RAM like \f(CW\*(C`LD\*(C'\fR
  or \f(CW\*(C`STS\*(C'\fR. This offset depends on the device architecture and has
! to be subtracted from the RAM address in order to get the
  respective I/O address.
  .ie n .IP """_\|_AVR_SHORT_CALLS_\|_""" 4
! .el .IP \f(CW_\|_AVR_SHORT_CALLS_\|_\fR 4
  .IX Item "__AVR_SHORT_CALLS__"
  The \fB\-mshort\-calls\fR command line option is set.
! .ie n .IP """_\|_AVR_PM_BASE_ADDRESS_\|_=\fIaddr\fR""" 4
! .el .IP \f(CW_\|_AVR_PM_BASE_ADDRESS_\|_=\fR\f(CIaddr\fR\f(CW\fR 4
  .IX Item "__AVR_PM_BASE_ADDRESS__=addr"
  Some devices support reading from flash memory by means of \f(CW\*(C`LD*\*(C'\fR
  instructions.  The flash memory is seen in the data address space
  at an offset of \f(CW\*(C`_\|_AVR_PM_BASE_ADDRESS_\|_\*(C'\fR.  If this macro
  is not defined, this feature is not available.  If defined,
  the address space is linear and there is no need to put
! \&\f(CW\*(C`.rodata\*(C'\fR into RAM.  This is handled by the default linker
  description file, and is currently available for
  \&\f(CW\*(C`avrtiny\*(C'\fR and \f(CW\*(C`avrxmega3\*(C'\fR.  Even more convenient,
  there is no need to use address spaces like \f(CW\*(C`_\|_flash\*(C'\fR or
  features like attribute \f(CW\*(C`progmem\*(C'\fR and \f(CW\*(C`pgm_read_*\*(C'\fR.
  .ie n .IP """_\|_WITH_AVRLIBC_\|_""" 4
! .el .IP \f(CW_\|_WITH_AVRLIBC_\|_\fR 4
  .IX Item "__WITH_AVRLIBC__"
! The compiler is configured to be used together with AVR\-Libc.
  See the \fB\-\-with\-avrlibc\fR configure option.
  .ie n .IP """_\|_HAVE_DOUBLE_MULTILIB_\|_""" 4
! .el .IP \f(CW_\|_HAVE_DOUBLE_MULTILIB_\|_\fR 4
  .IX Item "__HAVE_DOUBLE_MULTILIB__"
  Defined if \fB\-mdouble=\fR acts as a multilib option.
  .ie n .IP """_\|_HAVE_DOUBLE32_\|_""" 4
! .el .IP \f(CW_\|_HAVE_DOUBLE32_\|_\fR 4
  .IX Item "__HAVE_DOUBLE32__"
  .PD 0
  .ie n .IP """_\|_HAVE_DOUBLE64_\|_""" 4
! .el .IP \f(CW_\|_HAVE_DOUBLE64_\|_\fR 4
  .IX Item "__HAVE_DOUBLE64__"
  .PD
  Defined if the compiler supports 32\-bit double resp. 64\-bit double.
  The actual layout is specified by option \fB\-mdouble=\fR.
  .ie n .IP """_\|_DEFAULT_DOUBLE_\|_""" 4
! .el .IP \f(CW_\|_DEFAULT_DOUBLE_\|_\fR 4
  .IX Item "__DEFAULT_DOUBLE__"
  The size in bits of \f(CW\*(C`double\*(C'\fR if \fB\-mdouble=\fR is not set.
! To test the layout of \f(CW\*(C`double\*(C'\fR in a program, use the built\-in
  macro \f(CW\*(C`_\|_SIZEOF_DOUBLE_\|_\*(C'\fR.
  .ie n .IP """_\|_HAVE_LONG_DOUBLE32_\|_""" 4
! .el .IP \f(CW_\|_HAVE_LONG_DOUBLE32_\|_\fR 4
  .IX Item "__HAVE_LONG_DOUBLE32__"
  .PD 0
  .ie n .IP """_\|_HAVE_LONG_DOUBLE64_\|_""" 4
! .el .IP \f(CW_\|_HAVE_LONG_DOUBLE64_\|_\fR 4
  .IX Item "__HAVE_LONG_DOUBLE64__"
  .ie n .IP """_\|_HAVE_LONG_DOUBLE_MULTILIB_\|_""" 4
! .el .IP \f(CW_\|_HAVE_LONG_DOUBLE_MULTILIB_\|_\fR 4
  .IX Item "__HAVE_LONG_DOUBLE_MULTILIB__"
  .ie n .IP """_\|_DEFAULT_LONG_DOUBLE_\|_""" 4
! .el .IP \f(CW_\|_DEFAULT_LONG_DOUBLE_\|_\fR 4
  .IX Item "__DEFAULT_LONG_DOUBLE__"
  .PD
  Same as above, but for \f(CW\*(C`long double\*(C'\fR instead of \f(CW\*(C`double\*(C'\fR.
  .ie n .IP """_\|_WITH_DOUBLE_COMPARISON_\|_""" 4
! .el .IP \f(CW_\|_WITH_DOUBLE_COMPARISON_\|_\fR 4
  .IX Item "__WITH_DOUBLE_COMPARISON__"
  Reflects the \f(CW\*(C`\-\-with\-double\-comparison={tristate|bool|libf7}\*(C'\fR
  configure\ option (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR)
  and is defined to \f(CW2\fR or \f(CW3\fR.
  .ie n .IP """_\|_WITH_LIBF7_LIBGCC_\|_""" 4
! .el .IP \f(CW_\|_WITH_LIBF7_LIBGCC_\|_\fR 4
  .IX Item "__WITH_LIBF7_LIBGCC__"
  .PD 0
  .ie n .IP """_\|_WITH_LIBF7_MATH_\|_""" 4
! .el .IP \f(CW_\|_WITH_LIBF7_MATH_\|_\fR 4
  .IX Item "__WITH_LIBF7_MATH__"
  .ie n .IP """_\|_WITH_LIBF7_MATH_SYMBOLS_\|_""" 4
! .el .IP \f(CW_\|_WITH_LIBF7_MATH_SYMBOLS_\|_\fR 4
  .IX Item "__WITH_LIBF7_MATH_SYMBOLS__"
  .PD
  Reflects the \f(CW\*(C`\-\-with\-libf7={libgcc|math|math\-symbols}\*(C'\fR
  configure\ option (\f(CW\*(C`https://gcc.gnu.org/install/configure.html#avr\*(C'\fR).
  .PP
! AVR Internal Options
  .IX Subsection "AVR Internal Options"
  .PP
  The following options are used internally by the compiler and to communicate
! between device specs files and the compiler proper. You don\*(Aqt need to set these
  options by hand, in particular they are not optimization options.
! Using these options in the wrong way may lead to sub\-optimal or wrong code.
  They are documented for completeness, and in order to get a better
  understanding of
  device\ specs (\f(CW\*(C`https://gcc.gnu.org/wiki/avr\-gcc#spec\-files\*(C'\fR)
  files.
! .IP \fB\-mn\-flash=\fR\fInum\fR 4
  .IX Item "-mn-flash=num"
  Assume that the flash memory has a size of \fInum\fR times 64 KiB.
! This determines which \f(CW\*(C`_\|_flash\fR\f(CIN\fR\f(CW\*(C'\fR address spaces are available.
! .IP \fB\-mrmw\fR 4
  .IX Item "-mrmw"
! Assume that the device supports the Read\-Modify\-Write
  instructions \f(CW\*(C`XCH\*(C'\fR, \f(CW\*(C`LAC\*(C'\fR, \f(CW\*(C`LAS\*(C'\fR and \f(CW\*(C`LAT\*(C'\fR.
! .IP \fB\-mshort\-calls\fR 4
  .IX Item "-mshort-calls"
  Assume that \f(CW\*(C`RJMP\*(C'\fR and \f(CW\*(C`RCALL\*(C'\fR can target the whole
  program memory. This option is used for multilib generation and selection
  for the devices from architecture \f(CW\*(C`avrxmega3\*(C'\fR.
! .IP \fB\-mskip\-bug\fR 4
  .IX Item "-mskip-bug"
  Generate code without skips (\f(CW\*(C`CPSE\*(C'\fR, \f(CW\*(C`SBRS\*(C'\fR,
  \&\f(CW\*(C`SBRC\*(C'\fR, \f(CW\*(C`SBIS\*(C'\fR, \f(CW\*(C`SBIC\*(C'\fR) over 32\-bit instructions.
! .IP \fB\-msp8\fR 4
  .IX Item "-msp8"
  Treat the stack pointer register as an 8\-bit register,
  i.e. assume the high byte of the stack pointer is zero.
*************** These architectures mix devices with and
*** 22782,22788 ****
  .PP
  \fIBlackfin Options\fR
  .IX Subsection "Blackfin Options"
! .IP "\fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR]" 4
  .IX Item "-mcpu=cpu[-sirevision]"
  Specifies the name of the target Blackfin processor.  Currently, \fIcpu\fR
  can be one of \fBbf512\fR, \fBbf514\fR, \fBbf516\fR, \fBbf518\fR,
--- 22713,22719 ----
  .PP
  \fIBlackfin Options\fR
  .IX Subsection "Blackfin Options"
! .IP \fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR] 4
  .IX Item "-mcpu=cpu[-sirevision]"
  Specifies the name of the target Blackfin processor.  Currently, \fIcpu\fR
  can be one of \fBbf512\fR, \fBbf514\fR, \fBbf516\fR, \fBbf518\fR,
*************** hexadecimal digits representing the majo
*** 22802,22920 ****
  revision.  If \fIsirevision\fR is \fBnone\fR, the \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR
  is not defined.  If \fIsirevision\fR is \fBany\fR, the
  \&\f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR is defined to be \f(CW0xffff\fR.
! If this optional \fIsirevision\fR is not used, \s-1GCC\s0 assumes the latest known
  silicon revision of the targeted Blackfin processor.
  .Sp
! \&\s-1GCC\s0 defines a preprocessor macro for the specified \fIcpu\fR.
! For the \fBbfin-elf\fR toolchain, this option causes the hardware \s-1BSP\s0
  provided by libgloss to be linked in if \fB\-msim\fR is not given.
  .Sp
  Without this option, \fBbf532\fR is used as the processor by default.
  .Sp
  Note that support for \fBbf561\fR is incomplete.  For \fBbf561\fR,
  only the preprocessor macro is defined.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
! the simulator \s-1BSP\s0 provided by libgloss to be linked in.  This option
! has effect only for \fBbfin-elf\fR toolchain.
  Certain other options, such as \fB\-mid\-shared\-library\fR and
  \&\fB\-mfdpic\fR, imply \fB\-msim\fR.
! .IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
  .IX Item "-momit-leaf-frame-pointer"
! Don't keep the frame pointer in a register for leaf functions.  This
  avoids the instructions to save, set up and restore frame pointers and
  makes an extra register available in leaf functions.
! .IP "\fB\-mspecld\-anomaly\fR" 4
  .IX Item "-mspecld-anomaly"
  When enabled, the compiler ensures that the generated code does not
  contain speculative loads after jump instructions. If this option is used,
  \&\f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_LOADS\*(C'\fR is defined.
! .IP "\fB\-mno\-specld\-anomaly\fR" 4
  .IX Item "-mno-specld-anomaly"
! Don't generate extra code to prevent speculative loads from occurring.
! .IP "\fB\-mcsync\-anomaly\fR" 4
  .IX Item "-mcsync-anomaly"
  When enabled, the compiler ensures that the generated code does not
! contain \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions too soon after conditional branches.
  If this option is used, \f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_SYNCS\*(C'\fR is defined.
! .IP "\fB\-mno\-csync\-anomaly\fR" 4
  .IX Item "-mno-csync-anomaly"
! Don't generate extra code to prevent \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions from
  occurring too soon after a conditional branch.
! .IP "\fB\-mlow64k\fR" 4
  .IX Item "-mlow64k"
  When enabled, the compiler is free to take advantage of the knowledge that
  the entire program fits into the low 64k of memory.
! .IP "\fB\-mno\-low64k\fR" 4
  .IX Item "-mno-low64k"
  Assume that the program is arbitrarily large.  This is the default.
! .IP "\fB\-mstack\-check\-l1\fR" 4
  .IX Item "-mstack-check-l1"
  Do stack checking using information placed into L1 scratchpad memory by the
  uClinux kernel.
! .IP "\fB\-mid\-shared\-library\fR" 4
  .IX Item "-mid-shared-library"
! Generate code that supports shared libraries via the library \s-1ID\s0 method.
  This allows for execute in place and shared libraries in an environment
  without virtual memory management.  This option implies \fB\-fPIC\fR.
! With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
! .IP "\fB\-mno\-id\-shared\-library\fR" 4
  .IX Item "-mno-id-shared-library"
! Generate code that doesn't assume ID-based shared libraries are being used.
  This is the default.
! .IP "\fB\-mleaf\-id\-shared\-library\fR" 4
  .IX Item "-mleaf-id-shared-library"
! Generate code that supports shared libraries via the library \s-1ID\s0 method,
! but assumes that this library or executable won't link against any other
! \&\s-1ID\s0 shared libraries.  That allows the compiler to use faster code for jumps
  and calls.
! .IP "\fB\-mno\-leaf\-id\-shared\-library\fR" 4
  .IX Item "-mno-leaf-id-shared-library"
! Do not assume that the code being compiled won't link against any \s-1ID\s0 shared
  libraries.  Slower code is generated for jump and call insns.
! .IP "\fB\-mshared\-library\-id=n\fR" 4
  .IX Item "-mshared-library-id=n"
! Specifies the identification number of the ID-based shared library being
  compiled.  Specifying a value of 0 generates more compact code; specifying
  other values forces the allocation of that number to the current
! library but is no more space\- or time-efficient than omitting this option.
! .IP "\fB\-msep\-data\fR" 4
  .IX Item "-msep-data"
  Generate code that allows the data segment to be located in a different
  area of memory from the text segment.  This allows for execute in place in
  an environment without virtual memory management by eliminating relocations
  against the text section.
! .IP "\fB\-mno\-sep\-data\fR" 4
  .IX Item "-mno-sep-data"
  Generate code that assumes that the data segment follows the text segment.
  This is the default.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP "\fB\-mno\-long\-calls\fR" 4
  .IX Item "-mno-long-calls"
  .PD
  Tells the compiler to perform function calls by first loading the
  address of the function into a register and then performing a subroutine
  call on this register.  This switch is needed if the target function
! lies outside of the 24\-bit addressing range of the offset-based
  version of subroutine call instruction.
  .Sp
  This feature is not enabled by default.  Specifying
  \&\fB\-mno\-long\-calls\fR restores the default behavior.  Note these
  switches have no effect on how the compiler generates code to handle
  function calls via function pointers.
! .IP "\fB\-mfast\-fp\fR" 4
  .IX Item "-mfast-fp"
! Link with the fast floating-point library. This library relaxes some of
! the \s-1IEEE\s0 floating-point standard's rules for checking inputs against
! Not-a-Number (\s-1NAN\s0), in the interest of performance.
! .IP "\fB\-minline\-plt\fR" 4
  .IX Item "-minline-plt"
! Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
  not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
! .IP "\fB\-mmulticore\fR" 4
  .IX Item "-mmulticore"
  Build a standalone application for multicore Blackfin processors. 
  This option causes proper start files and link scripts supporting 
--- 22733,22851 ----
  revision.  If \fIsirevision\fR is \fBnone\fR, the \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR
  is not defined.  If \fIsirevision\fR is \fBany\fR, the
  \&\f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR is defined to be \f(CW0xffff\fR.
! If this optional \fIsirevision\fR is not used, GCC assumes the latest known
  silicon revision of the targeted Blackfin processor.
  .Sp
! GCC defines a preprocessor macro for the specified \fIcpu\fR.
! For the \fBbfin\-elf\fR toolchain, this option causes the hardware BSP
  provided by libgloss to be linked in if \fB\-msim\fR is not given.
  .Sp
  Without this option, \fBbf532\fR is used as the processor by default.
  .Sp
  Note that support for \fBbf561\fR is incomplete.  For \fBbf561\fR,
  only the preprocessor macro is defined.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
! the simulator BSP provided by libgloss to be linked in.  This option
! has effect only for \fBbfin\-elf\fR toolchain.
  Certain other options, such as \fB\-mid\-shared\-library\fR and
  \&\fB\-mfdpic\fR, imply \fB\-msim\fR.
! .IP \fB\-momit\-leaf\-frame\-pointer\fR 4
  .IX Item "-momit-leaf-frame-pointer"
! Don\*(Aqt 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.
! .IP \fB\-mspecld\-anomaly\fR 4
  .IX Item "-mspecld-anomaly"
  When enabled, the compiler ensures that the generated code does not
  contain speculative loads after jump instructions. If this option is used,
  \&\f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_LOADS\*(C'\fR is defined.
! .IP \fB\-mno\-specld\-anomaly\fR 4
  .IX Item "-mno-specld-anomaly"
! Don\*(Aqt generate extra code to prevent speculative loads from occurring.
! .IP \fB\-mcsync\-anomaly\fR 4
  .IX Item "-mcsync-anomaly"
  When enabled, the compiler ensures that the generated code does not
! contain CSYNC or SSYNC instructions too soon after conditional branches.
  If this option is used, \f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_SYNCS\*(C'\fR is defined.
! .IP \fB\-mno\-csync\-anomaly\fR 4
  .IX Item "-mno-csync-anomaly"
! Don\*(Aqt generate extra code to prevent CSYNC or SSYNC instructions from
  occurring too soon after a conditional branch.
! .IP \fB\-mlow64k\fR 4
  .IX Item "-mlow64k"
  When enabled, the compiler is free to take advantage of the knowledge that
  the entire program fits into the low 64k of memory.
! .IP \fB\-mno\-low64k\fR 4
  .IX Item "-mno-low64k"
  Assume that the program is arbitrarily large.  This is the default.
! .IP \fB\-mstack\-check\-l1\fR 4
  .IX Item "-mstack-check-l1"
  Do stack checking using information placed into L1 scratchpad memory by the
  uClinux kernel.
! .IP \fB\-mid\-shared\-library\fR 4
  .IX Item "-mid-shared-library"
! Generate code that supports shared libraries via the library ID method.
  This allows for execute in place and shared libraries in an environment
  without virtual memory management.  This option implies \fB\-fPIC\fR.
! With a \fBbfin\-elf\fR target, this option implies \fB\-msim\fR.
! .IP \fB\-mno\-id\-shared\-library\fR 4
  .IX Item "-mno-id-shared-library"
! Generate code that doesn\*(Aqt assume ID\-based shared libraries are being used.
  This is the default.
! .IP \fB\-mleaf\-id\-shared\-library\fR 4
  .IX Item "-mleaf-id-shared-library"
! Generate code that supports shared libraries via the library ID method,
! but assumes that this library or executable won\*(Aqt link against any other
! ID shared libraries.  That allows the compiler to use faster code for jumps
  and calls.
! .IP \fB\-mno\-leaf\-id\-shared\-library\fR 4
  .IX Item "-mno-leaf-id-shared-library"
! Do not assume that the code being compiled won\*(Aqt link against any ID shared
  libraries.  Slower code is generated for jump and call insns.
! .IP \fB\-mshared\-library\-id=n\fR 4
  .IX Item "-mshared-library-id=n"
! Specifies the identification number of the ID\-based shared library being
  compiled.  Specifying a value of 0 generates more compact code; specifying
  other values forces the allocation of that number to the current
! library but is no more space\- or time\-efficient than omitting this option.
! .IP \fB\-msep\-data\fR 4
  .IX Item "-msep-data"
  Generate code that allows the data segment to be located in a different
  area of memory from the text segment.  This allows for execute in place in
  an environment without virtual memory management by eliminating relocations
  against the text section.
! .IP \fB\-mno\-sep\-data\fR 4
  .IX Item "-mno-sep-data"
  Generate code that assumes that the data segment follows the text segment.
  This is the default.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP \fB\-mno\-long\-calls\fR 4
  .IX Item "-mno-long-calls"
  .PD
  Tells the compiler to perform function calls by first loading the
  address of the function into a register and then performing a subroutine
  call on this register.  This switch is needed if the target function
! lies outside of the 24\-bit addressing range of the offset\-based
  version of subroutine call instruction.
  .Sp
  This feature is not enabled by default.  Specifying
  \&\fB\-mno\-long\-calls\fR restores the default behavior.  Note these
  switches have no effect on how the compiler generates code to handle
  function calls via function pointers.
! .IP \fB\-mfast\-fp\fR 4
  .IX Item "-mfast-fp"
! Link with the fast floating\-point library. This library relaxes some of
! the IEEE floating\-point standard\*(Aqs rules for checking inputs against
! Not\-a\-Number (NAN), in the interest of performance.
! .IP \fB\-minline\-plt\fR 4
  .IX Item "-minline-plt"
! Enable inlining of PLT entries in function calls to functions that are
  not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
! .IP \fB\-mmulticore\fR 4
  .IX Item "-mmulticore"
  Build a standalone application for multicore Blackfin processors. 
  This option causes proper start files and link scripts supporting 
*************** multicore to be used, and defines the ma
*** 22922,22956 ****
  It can only be used with \fB\-mcpu=bf561\fR[\fB\-\fR\fIsirevision\fR].
  .Sp
  This option can be used with \fB\-mcorea\fR or \fB\-mcoreb\fR, which
! selects the one-application-per-core programming model.  Without
  \&\fB\-mcorea\fR or \fB\-mcoreb\fR, the single\-application/dual\-core
  programming model is used. In this model, the main function of Core B
  should be named as \f(CW\*(C`coreb_main\*(C'\fR.
  .Sp
! If this option is not used, the single-core application programming
  model is used.
! .IP "\fB\-mcorea\fR" 4
  .IX Item "-mcorea"
! Build a standalone application for Core A of \s-1BF561\s0 when using
! the one-application-per-core programming model. Proper start files
  and link scripts are used to support Core A, and the macro
  \&\f(CW\*(C`_\|_BFIN_COREA\*(C'\fR is defined.
  This option can only be used in conjunction with \fB\-mmulticore\fR.
! .IP "\fB\-mcoreb\fR" 4
  .IX Item "-mcoreb"
! Build a standalone application for Core B of \s-1BF561\s0 when using
! the one-application-per-core programming model. Proper start files
  and link scripts are used to support Core B, and the macro
  \&\f(CW\*(C`_\|_BFIN_COREB\*(C'\fR is defined. When this option is used, \f(CW\*(C`coreb_main\*(C'\fR
  should be used instead of \f(CW\*(C`main\*(C'\fR. 
  This option can only be used in conjunction with \fB\-mmulticore\fR.
! .IP "\fB\-msdram\fR" 4
  .IX Item "-msdram"
! Build a standalone application for \s-1SDRAM.\s0 Proper start files and
! link scripts are used to put the application into \s-1SDRAM,\s0 and the macro
  \&\f(CW\*(C`_\|_BFIN_SDRAM\*(C'\fR is defined.
! The loader should initialize \s-1SDRAM\s0 before loading the application.
! .IP "\fB\-micplb\fR" 4
  .IX Item "-micplb"
  Assume that ICPLBs are enabled at run time.  This has an effect on certain
  anomaly workarounds.  For Linux targets, the default is to assume ICPLBs
--- 22853,22887 ----
  It can only be used with \fB\-mcpu=bf561\fR[\fB\-\fR\fIsirevision\fR].
  .Sp
  This option can be used with \fB\-mcorea\fR or \fB\-mcoreb\fR, which
! selects the one\-application\-per\-core programming model.  Without
  \&\fB\-mcorea\fR or \fB\-mcoreb\fR, the single\-application/dual\-core
  programming model is used. In this model, the main function of Core B
  should be named as \f(CW\*(C`coreb_main\*(C'\fR.
  .Sp
! If this option is not used, the single\-core application programming
  model is used.
! .IP \fB\-mcorea\fR 4
  .IX Item "-mcorea"
! Build a standalone application for Core A of BF561 when using
! the one\-application\-per\-core programming model. Proper start files
  and link scripts are used to support Core A, and the macro
  \&\f(CW\*(C`_\|_BFIN_COREA\*(C'\fR is defined.
  This option can only be used in conjunction with \fB\-mmulticore\fR.
! .IP \fB\-mcoreb\fR 4
  .IX Item "-mcoreb"
! Build a standalone application for Core B of BF561 when using
! the one\-application\-per\-core programming model. Proper start files
  and link scripts are used to support Core B, and the macro
  \&\f(CW\*(C`_\|_BFIN_COREB\*(C'\fR is defined. When this option is used, \f(CW\*(C`coreb_main\*(C'\fR
  should be used instead of \f(CW\*(C`main\*(C'\fR. 
  This option can only be used in conjunction with \fB\-mmulticore\fR.
! .IP \fB\-msdram\fR 4
  .IX Item "-msdram"
! Build a standalone application for SDRAM. Proper start files and
! link scripts are used to put the application into SDRAM, and the macro
  \&\f(CW\*(C`_\|_BFIN_SDRAM\*(C'\fR is defined.
! The loader should initialize SDRAM before loading the application.
! .IP \fB\-micplb\fR 4
  .IX Item "-micplb"
  Assume that ICPLBs are enabled at run time.  This has an effect on certain
  anomaly workarounds.  For Linux targets, the default is to assume ICPLBs
*************** are enabled; for standalone applications
*** 22958,22992 ****
  .PP
  \fIC6X Options\fR
  .IX Subsection "C6X Options"
! .IP "\fB\-march=\fR\fIname\fR" 4
  .IX Item "-march=name"
! This specifies the name of the target architecture.  \s-1GCC\s0 uses this
  name to determine what kind of instructions it can emit when generating
  assembly code.  Permissible names are: \fBc62x\fR,
  \&\fBc64x\fR, \fBc64x+\fR, \fBc67x\fR, \fBc67x+\fR, \fBc674x\fR.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code for a big-endian target.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code for a little-endian target.  This is the default.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Choose startup files and linker script suitable for the simulator.
! .IP "\fB\-msdata=default\fR" 4
  .IX Item "-msdata=default"
  Put small global and static data in the \f(CW\*(C`.neardata\*(C'\fR section,
  which is pointed to by register \f(CW\*(C`B14\*(C'\fR.  Put small uninitialized
  global and static data in the \f(CW\*(C`.bss\*(C'\fR section, which is adjacent
! to the \f(CW\*(C`.neardata\*(C'\fR section.  Put small read-only data into the
  \&\f(CW\*(C`.rodata\*(C'\fR section.  The corresponding sections used for large
  pieces of data are \f(CW\*(C`.fardata\*(C'\fR, \f(CW\*(C`.far\*(C'\fR and \f(CW\*(C`.const\*(C'\fR.
! .IP "\fB\-msdata=all\fR" 4
  .IX Item "-msdata=all"
  Put all data, not just small objects, into the sections reserved for
  small data, and use addressing relative to the \f(CW\*(C`B14\*(C'\fR register to
  access them.
! .IP "\fB\-msdata=none\fR" 4
  .IX Item "-msdata=none"
  Make no use of the sections reserved for small data, and use absolute
  addresses to access all data.  Put all initialized global and static
--- 22889,22923 ----
  .PP
  \fIC6X Options\fR
  .IX Subsection "C6X Options"
! .IP \fB\-march=\fR\fIname\fR 4
  .IX Item "-march=name"
! This specifies the name of the target architecture.  GCC uses this
  name to determine what kind of instructions it can emit when generating
  assembly code.  Permissible names are: \fBc62x\fR,
  \&\fBc64x\fR, \fBc64x+\fR, \fBc67x\fR, \fBc67x+\fR, \fBc674x\fR.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code for a big\-endian target.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code for a little\-endian target.  This is the default.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Choose startup files and linker script suitable for the simulator.
! .IP \fB\-msdata=default\fR 4
  .IX Item "-msdata=default"
  Put small global and static data in the \f(CW\*(C`.neardata\*(C'\fR section,
  which is pointed to by register \f(CW\*(C`B14\*(C'\fR.  Put small uninitialized
  global and static data in the \f(CW\*(C`.bss\*(C'\fR section, which is adjacent
! to the \f(CW\*(C`.neardata\*(C'\fR section.  Put small read\-only data into the
  \&\f(CW\*(C`.rodata\*(C'\fR section.  The corresponding sections used for large
  pieces of data are \f(CW\*(C`.fardata\*(C'\fR, \f(CW\*(C`.far\*(C'\fR and \f(CW\*(C`.const\*(C'\fR.
! .IP \fB\-msdata=all\fR 4
  .IX Item "-msdata=all"
  Put all data, not just small objects, into the sections reserved for
  small data, and use addressing relative to the \f(CW\*(C`B14\*(C'\fR register to
  access them.
! .IP \fB\-msdata=none\fR 4
  .IX Item "-msdata=none"
  Make no use of the sections reserved for small data, and use absolute
  addresses to access all data.  Put all initialized global and static
*************** data in the \f(CW\*(C`.fardata\*(C'\fR s
*** 22994,23117 ****
  \&\f(CW\*(C`.far\*(C'\fR section.  Put all constant data into the \f(CW\*(C`.const\*(C'\fR
  section.
  .PP
! \fI\s-1CRIS\s0 Options\fR
  .IX Subsection "CRIS Options"
  .PP
! These options are defined specifically for the \s-1CRIS\s0 ports.
! .IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
  .IX Item "-march=architecture-type"
  .PD 0
! .IP "\fB\-mcpu=\fR\fIarchitecture-type\fR" 4
  .IX Item "-mcpu=architecture-type"
  .PD
  Generate code for the specified architecture.  The choices for
! \&\fIarchitecture-type\fR are \fBv3\fR, \fBv8\fR and \fBv10\fR for
! respectively \s-1ETRAX\s0\ 4, \s-1ETRAX\s0\ 100, and \s-1ETRAX\s0\ 100\ \s-1LX.\s0
  Default is \fBv0\fR.
! .IP "\fB\-mtune=\fR\fIarchitecture-type\fR" 4
  .IX Item "-mtune=architecture-type"
! Tune to \fIarchitecture-type\fR everything applicable about the generated
! code, except for the \s-1ABI\s0 and the set of available instructions.  The
! choices for \fIarchitecture-type\fR are the same as for
! \&\fB\-march=\fR\fIarchitecture-type\fR.
! .IP "\fB\-mmax\-stack\-frame=\fR\fIn\fR" 4
  .IX Item "-mmax-stack-frame=n"
  Warn when the stack frame of a function exceeds \fIn\fR bytes.
! .IP "\fB\-metrax4\fR" 4
  .IX Item "-metrax4"
  .PD 0
! .IP "\fB\-metrax100\fR" 4
  .IX Item "-metrax100"
  .PD
  The options \fB\-metrax4\fR and \fB\-metrax100\fR are synonyms for
  \&\fB\-march=v3\fR and \fB\-march=v8\fR respectively.
! .IP "\fB\-mmul\-bug\-workaround\fR" 4
  .IX Item "-mmul-bug-workaround"
  .PD 0
! .IP "\fB\-mno\-mul\-bug\-workaround\fR" 4
  .IX Item "-mno-mul-bug-workaround"
  .PD
! Work around a bug in the \f(CW\*(C`muls\*(C'\fR and \f(CW\*(C`mulu\*(C'\fR instructions for \s-1CPU\s0
  models where it applies.  This option is disabled by default.
! .IP "\fB\-mpdebug\fR" 4
  .IX Item "-mpdebug"
! Enable CRIS-specific verbose debug-related information in the assembly
  code.  This option also has the effect of turning off the \fB#NO_APP\fR
! formatted-code indicator to the assembler at the beginning of the
  assembly file.
! .IP "\fB\-mcc\-init\fR" 4
  .IX Item "-mcc-init"
! Do not use condition-code results from previous instruction; always emit
  compare and test instructions before use of condition codes.
! .IP "\fB\-mno\-side\-effects\fR" 4
  .IX Item "-mno-side-effects"
  Do not emit instructions with side effects in addressing modes other than
! post-increment.
! .IP "\fB\-mstack\-align\fR" 4
  .IX Item "-mstack-align"
  .PD 0
! .IP "\fB\-mno\-stack\-align\fR" 4
  .IX Item "-mno-stack-align"
! .IP "\fB\-mdata\-align\fR" 4
  .IX Item "-mdata-align"
! .IP "\fB\-mno\-data\-align\fR" 4
  .IX Item "-mno-data-align"
! .IP "\fB\-mconst\-align\fR" 4
  .IX Item "-mconst-align"
! .IP "\fB\-mno\-const\-align\fR" 4
  .IX Item "-mno-const-align"
  .PD
  These options (\fBno\-\fR options) arrange (eliminate arrangements) for the
  stack frame, individual data and constants to be aligned for the maximum
! single data access size for the chosen \s-1CPU\s0 model.  The default is to
! arrange for 32\-bit alignment.  \s-1ABI\s0 details such as structure layout are
  not affected by these options.
! .IP "\fB\-m32\-bit\fR" 4
  .IX Item "-m32-bit"
  .PD 0
! .IP "\fB\-m16\-bit\fR" 4
  .IX Item "-m16-bit"
! .IP "\fB\-m8\-bit\fR" 4
  .IX Item "-m8-bit"
  .PD
! Similar to the stack\- data\- and const-align options above, these options
  arrange for stack frame, writable data and constants to all be 32\-bit,
  16\-bit or 8\-bit aligned.  The default is 32\-bit alignment.
! .IP "\fB\-mno\-prologue\-epilogue\fR" 4
  .IX Item "-mno-prologue-epilogue"
  .PD 0
! .IP "\fB\-mprologue\-epilogue\fR" 4
  .IX Item "-mprologue-epilogue"
  .PD
  With \fB\-mno\-prologue\-epilogue\fR, the normal function prologue and
  epilogue which set up the stack frame are omitted and no return
  instructions or return sequences are generated in the code.  Use this
  option only together with visual inspection of the compiled code: no
! warnings or errors are generated when call-saved registers must be saved,
  or storage for local variables needs to be allocated.
! .IP "\fB\-melf\fR" 4
  .IX Item "-melf"
! Legacy no-op option.
! .IP "\fB\-sim\fR" 4
  .IX Item "-sim"
  This option arranges
! to link with input-output functions from a simulator library.  Code,
! initialized data and zero-initialized data are allocated consecutively.
! .IP "\fB\-sim2\fR" 4
  .IX Item "-sim2"
  Like \fB\-sim\fR, but pass linker options to locate initialized data at
! 0x40000000 and zero-initialized data at 0x80000000.
  .PP
  \fIC\-SKY Options\fR
  .IX Subsection "C-SKY Options"
  .PP
! \&\s-1GCC\s0 supports these options when compiling for C\-SKY V2 processors.
! .IP "\fB\-march=\fR\fIarch\fR" 4
  .IX Item "-march=arch"
  Specify the C\-SKY target architecture.  Valid values for \fIarch\fR are:
  \&\fBck801\fR, \fBck802\fR, \fBck803\fR, \fBck807\fR, and \fBck810\fR.
  The default is \fBck810\fR.
! .IP "\fB\-mcpu=\fR\fIcpu\fR" 4
  .IX Item "-mcpu=cpu"
  Specify the C\-SKY target processor.  Valid values for \fIcpu\fR are:
  \&\fBck801\fR, \fBck801t\fR,
--- 22925,23048 ----
  \&\f(CW\*(C`.far\*(C'\fR section.  Put all constant data into the \f(CW\*(C`.const\*(C'\fR
  section.
  .PP
! \fICRIS Options\fR
  .IX Subsection "CRIS Options"
  .PP
! These options are defined specifically for the CRIS ports.
! .IP \fB\-march=\fR\fIarchitecture\-type\fR 4
  .IX Item "-march=architecture-type"
  .PD 0
! .IP \fB\-mcpu=\fR\fIarchitecture\-type\fR 4
  .IX Item "-mcpu=architecture-type"
  .PD
  Generate code for the specified architecture.  The choices for
! \&\fIarchitecture\-type\fR are \fBv3\fR, \fBv8\fR and \fBv10\fR for
! respectively ETRAX\ 4, ETRAX\ 100, and ETRAX\ 100\ LX.
  Default is \fBv0\fR.
! .IP \fB\-mtune=\fR\fIarchitecture\-type\fR 4
  .IX Item "-mtune=architecture-type"
! Tune to \fIarchitecture\-type\fR everything applicable about the generated
! code, except for the ABI and the set of available instructions.  The
! choices for \fIarchitecture\-type\fR are the same as for
! \&\fB\-march=\fR\fIarchitecture\-type\fR.
! .IP \fB\-mmax\-stack\-frame=\fR\fIn\fR 4
  .IX Item "-mmax-stack-frame=n"
  Warn when the stack frame of a function exceeds \fIn\fR bytes.
! .IP \fB\-metrax4\fR 4
  .IX Item "-metrax4"
  .PD 0
! .IP \fB\-metrax100\fR 4
  .IX Item "-metrax100"
  .PD
  The options \fB\-metrax4\fR and \fB\-metrax100\fR are synonyms for
  \&\fB\-march=v3\fR and \fB\-march=v8\fR respectively.
! .IP \fB\-mmul\-bug\-workaround\fR 4
  .IX Item "-mmul-bug-workaround"
  .PD 0
! .IP \fB\-mno\-mul\-bug\-workaround\fR 4
  .IX Item "-mno-mul-bug-workaround"
  .PD
! Work around a bug in the \f(CW\*(C`muls\*(C'\fR and \f(CW\*(C`mulu\*(C'\fR instructions for CPU
  models where it applies.  This option is disabled by default.
! .IP \fB\-mpdebug\fR 4
  .IX Item "-mpdebug"
! Enable CRIS\-specific verbose debug\-related information in the assembly
  code.  This option also has the effect of turning off the \fB#NO_APP\fR
! formatted\-code indicator to the assembler at the beginning of the
  assembly file.
! .IP \fB\-mcc\-init\fR 4
  .IX Item "-mcc-init"
! Do not use condition\-code results from previous instruction; always emit
  compare and test instructions before use of condition codes.
! .IP \fB\-mno\-side\-effects\fR 4
  .IX Item "-mno-side-effects"
  Do not emit instructions with side effects in addressing modes other than
! post\-increment.
! .IP \fB\-mstack\-align\fR 4
  .IX Item "-mstack-align"
  .PD 0
! .IP \fB\-mno\-stack\-align\fR 4
  .IX Item "-mno-stack-align"
! .IP \fB\-mdata\-align\fR 4
  .IX Item "-mdata-align"
! .IP \fB\-mno\-data\-align\fR 4
  .IX Item "-mno-data-align"
! .IP \fB\-mconst\-align\fR 4
  .IX Item "-mconst-align"
! .IP \fB\-mno\-const\-align\fR 4
  .IX Item "-mno-const-align"
  .PD
  These options (\fBno\-\fR options) arrange (eliminate arrangements) for the
  stack frame, individual data and constants to be aligned for the maximum
! single data access size for the chosen CPU model.  The default is to
! arrange for 32\-bit alignment.  ABI details such as structure layout are
  not affected by these options.
! .IP \fB\-m32\-bit\fR 4
  .IX Item "-m32-bit"
  .PD 0
! .IP \fB\-m16\-bit\fR 4
  .IX Item "-m16-bit"
! .IP \fB\-m8\-bit\fR 4
  .IX Item "-m8-bit"
  .PD
! Similar to the stack\- data\- and const\-align options above, these options
  arrange for stack frame, writable data and constants to all be 32\-bit,
  16\-bit or 8\-bit aligned.  The default is 32\-bit alignment.
! .IP \fB\-mno\-prologue\-epilogue\fR 4
  .IX Item "-mno-prologue-epilogue"
  .PD 0
! .IP \fB\-mprologue\-epilogue\fR 4
  .IX Item "-mprologue-epilogue"
  .PD
  With \fB\-mno\-prologue\-epilogue\fR, the normal function prologue and
  epilogue which set up the stack frame are omitted and no return
  instructions or return sequences are generated in the code.  Use this
  option only together with visual inspection of the compiled code: no
! warnings or errors are generated when call\-saved registers must be saved,
  or storage for local variables needs to be allocated.
! .IP \fB\-melf\fR 4
  .IX Item "-melf"
! Legacy no\-op option.
! .IP \fB\-sim\fR 4
  .IX Item "-sim"
  This option arranges
! to link with input\-output functions from a simulator library.  Code,
! initialized data and zero\-initialized data are allocated consecutively.
! .IP \fB\-sim2\fR 4
  .IX Item "-sim2"
  Like \fB\-sim\fR, but pass linker options to locate initialized data at
! 0x40000000 and zero\-initialized data at 0x80000000.
  .PP
  \fIC\-SKY Options\fR
  .IX Subsection "C-SKY Options"
  .PP
! GCC supports these options when compiling for C\-SKY V2 processors.
! .IP \fB\-march=\fR\fIarch\fR 4
  .IX Item "-march=arch"
  Specify the C\-SKY target architecture.  Valid values for \fIarch\fR are:
  \&\fBck801\fR, \fBck802\fR, \fBck803\fR, \fBck807\fR, and \fBck810\fR.
  The default is \fBck810\fR.
! .IP \fB\-mcpu=\fR\fIcpu\fR 4
  .IX Item "-mcpu=cpu"
  Specify the C\-SKY target processor.  Valid values for \fIcpu\fR are:
  \&\fBck801\fR, \fBck801t\fR,
*************** Specify the C\-SKY target processor.  Va
*** 23130,23334 ****
  \&\fBck810e\fR, \fBck810et\fR, \fBck810ef\fR, \fBck810eft\fR,
  \&\fBck810\fR, \fBck810v\fR, \fBck810f\fR, \fBck810t\fR, \fBck810fv\fR,
  \&\fBck810tv\fR, \fBck810ft\fR, and \fBck810ftv\fR.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
  .PD 0
! .IP "\fB\-EB\fR" 4
  .IX Item "-EB"
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! .IP "\fB\-EL\fR" 4
  .IX Item "-EL"
  .PD
! Select big\- or little-endian code.  The default is little-endian.
! .IP "\fB\-mfloat\-abi=\fR\fIname\fR" 4
  .IX Item "-mfloat-abi=name"
! Specifies which floating-point \s-1ABI\s0 to use.  Permissible values
  are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
  .Sp
! Specifying \fBsoft\fR causes \s-1GCC\s0 to generate output containing
! library calls for floating-point operations.
! \&\fBsoftfp\fR allows the generation of code using hardware floating-point
! instructions, but still uses the soft-float calling conventions.
! \&\fBhard\fR allows generation of floating-point instructions
! and uses FPU-specific calling conventions.
  .Sp
  The default depends on the specific target configuration.  Note that
! the hard-float and soft-float ABIs are not link-compatible; you must
! compile your entire program with the same \s-1ABI,\s0 and link with a
  compatible set of libraries.
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
! Select hardware or software floating-point implementations.
  The default is soft float.
! .IP "\fB\-mdouble\-float\fR" 4
  .IX Item "-mdouble-float"
  .PD 0
! .IP "\fB\-mno\-double\-float\fR" 4
  .IX Item "-mno-double-float"
  .PD
  When \fB\-mhard\-float\fR is in effect, enable generation of
! double-precision float instructions.  This is the default except
! when compiling for \s-1CK803.\s0
! .IP "\fB\-mfdivdu\fR" 4
  .IX Item "-mfdivdu"
  .PD 0
! .IP "\fB\-mno\-fdivdu\fR" 4
  .IX Item "-mno-fdivdu"
  .PD
  When \fB\-mhard\-float\fR is in effect, enable generation of
  \&\f(CW\*(C`frecipd\*(C'\fR, \f(CW\*(C`fsqrtd\*(C'\fR, and \f(CW\*(C`fdivd\*(C'\fR instructions.
! This is the default except when compiling for \s-1CK803.\s0
! .IP "\fB\-mfpu=\fR\fIfpu\fR" 4
  .IX Item "-mfpu=fpu"
! Select the floating-point processor.  This option can only be used with
  \&\fB\-mhard\-float\fR.
  Values for \fIfpu\fR are
  \&\fBfpv2_sf\fR (equivalent to \fB\-mno\-double\-float \-mno\-fdivdu\fR),
  \&\fBfpv2\fR (\fB\-mdouble\-float \-mno\-divdu\fR), and
  \&\fBfpv2_divd\fR (\fB\-mdouble\-float \-mdivdu\fR).
! .IP "\fB\-melrw\fR" 4
  .IX Item "-melrw"
  .PD 0
! .IP "\fB\-mno\-elrw\fR" 4
  .IX Item "-mno-elrw"
  .PD
  Enable the extended \f(CW\*(C`lrw\*(C'\fR instruction.  This option defaults to on
! for \s-1CK801\s0 and off otherwise.
! .IP "\fB\-mistack\fR" 4
  .IX Item "-mistack"
  .PD 0
! .IP "\fB\-mno\-istack\fR" 4
  .IX Item "-mno-istack"
  .PD
  Enable interrupt stack instructions; the default is off.
  .Sp
  The \fB\-mistack\fR option is required to handle the
  \&\f(CW\*(C`interrupt\*(C'\fR and \f(CW\*(C`isr\*(C'\fR function attributes.
! .IP "\fB\-mmp\fR" 4
  .IX Item "-mmp"
  Enable multiprocessor instructions; the default is off.
! .IP "\fB\-mcp\fR" 4
  .IX Item "-mcp"
  Enable coprocessor instructions; the default is off.
! .IP "\fB\-mcache\fR" 4
  .IX Item "-mcache"
  Enable coprocessor instructions; the default is off.
! .IP "\fB\-msecurity\fR" 4
  .IX Item "-msecurity"
  Enable C\-SKY security instructions; the default is off.
! .IP "\fB\-mtrust\fR" 4
  .IX Item "-mtrust"
  Enable C\-SKY trust instructions; the default is off.
! .IP "\fB\-mdsp\fR" 4
  .IX Item "-mdsp"
  .PD 0
! .IP "\fB\-medsp\fR" 4
  .IX Item "-medsp"
! .IP "\fB\-mvdsp\fR" 4
  .IX Item "-mvdsp"
  .PD
! Enable C\-SKY \s-1DSP,\s0 Enhanced \s-1DSP,\s0 or Vector \s-1DSP\s0 instructions, respectively.
  All of these options default to off.
! .IP "\fB\-mdiv\fR" 4
  .IX Item "-mdiv"
  .PD 0
! .IP "\fB\-mno\-div\fR" 4
  .IX Item "-mno-div"
  .PD
  Generate divide instructions.  Default is off.
! .IP "\fB\-msmart\fR" 4
  .IX Item "-msmart"
  .PD 0
! .IP "\fB\-mno\-smart\fR" 4
  .IX Item "-mno-smart"
  .PD
  Generate code for Smart Mode, using only registers numbered 0\-7 to allow
! use of 16\-bit instructions.  This option is ignored for \s-1CK801\s0 where this
! is the required behavior, and it defaults to on for \s-1CK802.\s0
  For other targets, the default is off.
! .IP "\fB\-mhigh\-registers\fR" 4
  .IX Item "-mhigh-registers"
  .PD 0
! .IP "\fB\-mno\-high\-registers\fR" 4
  .IX Item "-mno-high-registers"
  .PD
  Generate code using the high registers numbered 16\-31.  This option
! is not supported on \s-1CK801, CK802,\s0 or \s-1CK803,\s0 and is enabled by default
  for other processors.
! .IP "\fB\-manchor\fR" 4
  .IX Item "-manchor"
  .PD 0
! .IP "\fB\-mno\-anchor\fR" 4
  .IX Item "-mno-anchor"
  .PD
  Generate code using global anchor symbol addresses.
! .IP "\fB\-mpushpop\fR" 4
  .IX Item "-mpushpop"
  .PD 0
! .IP "\fB\-mno\-pushpop\fR" 4
  .IX Item "-mno-pushpop"
  .PD
  Generate code using \f(CW\*(C`push\*(C'\fR and \f(CW\*(C`pop\*(C'\fR instructions.  This option
  defaults to on.
! .IP "\fB\-mmultiple\-stld\fR" 4
  .IX Item "-mmultiple-stld"
  .PD 0
! .IP "\fB\-mstm\fR" 4
  .IX Item "-mstm"
! .IP "\fB\-mno\-multiple\-stld\fR" 4
  .IX Item "-mno-multiple-stld"
! .IP "\fB\-mno\-stm\fR" 4
  .IX Item "-mno-stm"
  .PD
  Generate code using \f(CW\*(C`stm\*(C'\fR and \f(CW\*(C`ldm\*(C'\fR instructions.  This option
! isn't supported on \s-1CK801\s0 but is enabled by default on other processors.
! .IP "\fB\-mconstpool\fR" 4
  .IX Item "-mconstpool"
  .PD 0
! .IP "\fB\-mno\-constpool\fR" 4
  .IX Item "-mno-constpool"
  .PD
  Create constant pools in the compiler instead of deferring it to the
  assembler.  This option is the default and required for correct code
! generation on \s-1CK801\s0 and \s-1CK802,\s0 and is optional on other processors.
! .IP "\fB\-mstack\-size\fR" 4
  .IX Item "-mstack-size"
  .PD 0
! .IP "\fB\-mno\-stack\-size\fR" 4
  .IX Item "-mno-stack-size"
  .PD
  Emit \f(CW\*(C`.stack_size\*(C'\fR directives for each function in the assembly
  output.  This option defaults to off.
! .IP "\fB\-mccrt\fR" 4
  .IX Item "-mccrt"
  .PD 0
! .IP "\fB\-mno\-ccrt\fR" 4
  .IX Item "-mno-ccrt"
  .PD
  Generate code for the C\-SKY compiler runtime instead of libgcc.  This
  option defaults to off.
! .IP "\fB\-mbranch\-cost=\fR\fIn\fR" 4
  .IX Item "-mbranch-cost=n"
  Set the branch costs to roughly \f(CW\*(C`n\*(C'\fR instructions.  The default is 1.
! .IP "\fB\-msched\-prolog\fR" 4
  .IX Item "-msched-prolog"
  .PD 0
! .IP "\fB\-mno\-sched\-prolog\fR" 4
  .IX Item "-mno-sched-prolog"
  .PD
  Permit scheduling of function prologue and epilogue sequences.  Using
! this option can result in code that is not compliant with the C\-SKY V2 \s-1ABI\s0
  prologue requirements and that cannot be debugged or backtraced.
  It is disabled by default.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Links the library libsemi.a which is in compatible with simulator. Applicable
! to \s-1ELF\s0 compiler only.
  .PP
  \fIDarwin Options\fR
  .IX Subsection "Darwin Options"
--- 23061,23265 ----
  \&\fBck810e\fR, \fBck810et\fR, \fBck810ef\fR, \fBck810eft\fR,
  \&\fBck810\fR, \fBck810v\fR, \fBck810f\fR, \fBck810t\fR, \fBck810fv\fR,
  \&\fBck810tv\fR, \fBck810ft\fR, and \fBck810ftv\fR.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
  .PD 0
! .IP \fB\-EB\fR 4
  .IX Item "-EB"
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! .IP \fB\-EL\fR 4
  .IX Item "-EL"
  .PD
! Select big\- or little\-endian code.  The default is little\-endian.
! .IP \fB\-mfloat\-abi=\fR\fIname\fR 4
  .IX Item "-mfloat-abi=name"
! Specifies which floating\-point ABI to use.  Permissible values
  are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
  .Sp
! Specifying \fBsoft\fR causes GCC to generate output containing
! library calls for floating\-point operations.
! \&\fBsoftfp\fR allows the generation of code using hardware floating\-point
! instructions, but still uses the soft\-float calling conventions.
! \&\fBhard\fR allows generation of floating\-point instructions
! and uses FPU\-specific calling conventions.
  .Sp
  The default depends on the specific target configuration.  Note that
! the hard\-float and soft\-float ABIs are not link\-compatible; you must
! compile your entire program with the same ABI, and link with a
  compatible set of libraries.
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
! Select hardware or software floating\-point implementations.
  The default is soft float.
! .IP \fB\-mdouble\-float\fR 4
  .IX Item "-mdouble-float"
  .PD 0
! .IP \fB\-mno\-double\-float\fR 4
  .IX Item "-mno-double-float"
  .PD
  When \fB\-mhard\-float\fR is in effect, enable generation of
! double\-precision float instructions.  This is the default except
! when compiling for CK803.
! .IP \fB\-mfdivdu\fR 4
  .IX Item "-mfdivdu"
  .PD 0
! .IP \fB\-mno\-fdivdu\fR 4
  .IX Item "-mno-fdivdu"
  .PD
  When \fB\-mhard\-float\fR is in effect, enable generation of
  \&\f(CW\*(C`frecipd\*(C'\fR, \f(CW\*(C`fsqrtd\*(C'\fR, and \f(CW\*(C`fdivd\*(C'\fR instructions.
! This is the default except when compiling for CK803.
! .IP \fB\-mfpu=\fR\fIfpu\fR 4
  .IX Item "-mfpu=fpu"
! Select the floating\-point processor.  This option can only be used with
  \&\fB\-mhard\-float\fR.
  Values for \fIfpu\fR are
  \&\fBfpv2_sf\fR (equivalent to \fB\-mno\-double\-float \-mno\-fdivdu\fR),
  \&\fBfpv2\fR (\fB\-mdouble\-float \-mno\-divdu\fR), and
  \&\fBfpv2_divd\fR (\fB\-mdouble\-float \-mdivdu\fR).
! .IP \fB\-melrw\fR 4
  .IX Item "-melrw"
  .PD 0
! .IP \fB\-mno\-elrw\fR 4
  .IX Item "-mno-elrw"
  .PD
  Enable the extended \f(CW\*(C`lrw\*(C'\fR instruction.  This option defaults to on
! for CK801 and off otherwise.
! .IP \fB\-mistack\fR 4
  .IX Item "-mistack"
  .PD 0
! .IP \fB\-mno\-istack\fR 4
  .IX Item "-mno-istack"
  .PD
  Enable interrupt stack instructions; the default is off.
  .Sp
  The \fB\-mistack\fR option is required to handle the
  \&\f(CW\*(C`interrupt\*(C'\fR and \f(CW\*(C`isr\*(C'\fR function attributes.
! .IP \fB\-mmp\fR 4
  .IX Item "-mmp"
  Enable multiprocessor instructions; the default is off.
! .IP \fB\-mcp\fR 4
  .IX Item "-mcp"
  Enable coprocessor instructions; the default is off.
! .IP \fB\-mcache\fR 4
  .IX Item "-mcache"
  Enable coprocessor instructions; the default is off.
! .IP \fB\-msecurity\fR 4
  .IX Item "-msecurity"
  Enable C\-SKY security instructions; the default is off.
! .IP \fB\-mtrust\fR 4
  .IX Item "-mtrust"
  Enable C\-SKY trust instructions; the default is off.
! .IP \fB\-mdsp\fR 4
  .IX Item "-mdsp"
  .PD 0
! .IP \fB\-medsp\fR 4
  .IX Item "-medsp"
! .IP \fB\-mvdsp\fR 4
  .IX Item "-mvdsp"
  .PD
! Enable C\-SKY DSP, Enhanced DSP, or Vector DSP instructions, respectively.
  All of these options default to off.
! .IP \fB\-mdiv\fR 4
  .IX Item "-mdiv"
  .PD 0
! .IP \fB\-mno\-div\fR 4
  .IX Item "-mno-div"
  .PD
  Generate divide instructions.  Default is off.
! .IP \fB\-msmart\fR 4
  .IX Item "-msmart"
  .PD 0
! .IP \fB\-mno\-smart\fR 4
  .IX Item "-mno-smart"
  .PD
  Generate code for Smart Mode, using only registers numbered 0\-7 to allow
! use of 16\-bit instructions.  This option is ignored for CK801 where this
! is the required behavior, and it defaults to on for CK802.
  For other targets, the default is off.
! .IP \fB\-mhigh\-registers\fR 4
  .IX Item "-mhigh-registers"
  .PD 0
! .IP \fB\-mno\-high\-registers\fR 4
  .IX Item "-mno-high-registers"
  .PD
  Generate code using the high registers numbered 16\-31.  This option
! is not supported on CK801, CK802, or CK803, and is enabled by default
  for other processors.
! .IP \fB\-manchor\fR 4
  .IX Item "-manchor"
  .PD 0
! .IP \fB\-mno\-anchor\fR 4
  .IX Item "-mno-anchor"
  .PD
  Generate code using global anchor symbol addresses.
! .IP \fB\-mpushpop\fR 4
  .IX Item "-mpushpop"
  .PD 0
! .IP \fB\-mno\-pushpop\fR 4
  .IX Item "-mno-pushpop"
  .PD
  Generate code using \f(CW\*(C`push\*(C'\fR and \f(CW\*(C`pop\*(C'\fR instructions.  This option
  defaults to on.
! .IP \fB\-mmultiple\-stld\fR 4
  .IX Item "-mmultiple-stld"
  .PD 0
! .IP \fB\-mstm\fR 4
  .IX Item "-mstm"
! .IP \fB\-mno\-multiple\-stld\fR 4
  .IX Item "-mno-multiple-stld"
! .IP \fB\-mno\-stm\fR 4
  .IX Item "-mno-stm"
  .PD
  Generate code using \f(CW\*(C`stm\*(C'\fR and \f(CW\*(C`ldm\*(C'\fR instructions.  This option
! isn\*(Aqt supported on CK801 but is enabled by default on other processors.
! .IP \fB\-mconstpool\fR 4
  .IX Item "-mconstpool"
  .PD 0
! .IP \fB\-mno\-constpool\fR 4
  .IX Item "-mno-constpool"
  .PD
  Create constant pools in the compiler instead of deferring it to the
  assembler.  This option is the default and required for correct code
! generation on CK801 and CK802, and is optional on other processors.
! .IP \fB\-mstack\-size\fR 4
  .IX Item "-mstack-size"
  .PD 0
! .IP \fB\-mno\-stack\-size\fR 4
  .IX Item "-mno-stack-size"
  .PD
  Emit \f(CW\*(C`.stack_size\*(C'\fR directives for each function in the assembly
  output.  This option defaults to off.
! .IP \fB\-mccrt\fR 4
  .IX Item "-mccrt"
  .PD 0
! .IP \fB\-mno\-ccrt\fR 4
  .IX Item "-mno-ccrt"
  .PD
  Generate code for the C\-SKY compiler runtime instead of libgcc.  This
  option defaults to off.
! .IP \fB\-mbranch\-cost=\fR\fIn\fR 4
  .IX Item "-mbranch-cost=n"
  Set the branch costs to roughly \f(CW\*(C`n\*(C'\fR instructions.  The default is 1.
! .IP \fB\-msched\-prolog\fR 4
  .IX Item "-msched-prolog"
  .PD 0
! .IP \fB\-mno\-sched\-prolog\fR 4
  .IX Item "-mno-sched-prolog"
  .PD
  Permit scheduling of function prologue and epilogue sequences.  Using
! this option can result in code that is not compliant with the C\-SKY V2 ABI
  prologue requirements and that cannot be debugged or backtraced.
  It is disabled by default.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Links the library libsemi.a which is in compatible with simulator. Applicable
! to ELF compiler only.
  .PP
  \fIDarwin Options\fR
  .IX Subsection "Darwin Options"
*************** to \s-1ELF\s0 compiler only.
*** 23336,23354 ****
  These options are defined for all architectures running the Darwin operating
  system.
  .PP
! \&\s-1FSF GCC\s0 on Darwin does not create \*(L"fat\*(R" object files; it creates
! an object file for the single architecture that \s-1GCC\s0 was built to
! target.  Apple's \s-1GCC\s0 on Darwin does create \*(L"fat\*(R" files if multiple
  \&\fB\-arch\fR options are used; it does so by running the compiler or
  linker multiple times and joining the results together with
  \&\fIlipo\fR.
  .PP
  The subtype of the file created (like \fBppc7400\fR or \fBppc970\fR or
! \&\fBi686\fR) is determined by the flags that specify the \s-1ISA\s0
! that \s-1GCC\s0 is targeting, like \fB\-mcpu\fR or \fB\-march\fR.  The
  \&\fB\-force_cpusubtype_ALL\fR option can be used to override this.
  .PP
! The Darwin tools vary in their behavior when presented with an \s-1ISA\s0
  mismatch.  The assembler, \fIas\fR, only permits instructions to
  be used that are valid for the subtype of the file it is generating,
  so you cannot put 64\-bit instructions in a \fBppc750\fR object file.
--- 23267,23285 ----
  These options are defined for all architectures running the Darwin operating
  system.
  .PP
! FSF GCC on Darwin does not create "fat" object files; it creates
! an object file for the single architecture that GCC was built to
! target.  Apple\*(Aqs GCC on Darwin does create "fat" files if multiple
  \&\fB\-arch\fR options are used; it does so by running the compiler or
  linker multiple times and joining the results together with
  \&\fIlipo\fR.
  .PP
  The subtype of the file created (like \fBppc7400\fR or \fBppc970\fR or
! \&\fBi686\fR) is determined by the flags that specify the ISA
! that GCC is targeting, like \fB\-mcpu\fR or \fB\-march\fR.  The
  \&\fB\-force_cpusubtype_ALL\fR option can be used to override this.
  .PP
! The Darwin tools vary in their behavior when presented with an ISA
  mismatch.  The assembler, \fIas\fR, only permits instructions to
  be used that are valid for the subtype of the file it is generating,
  so you cannot put 64\-bit instructions in a \fBppc750\fR object file.
*************** restrictive subtype than its input files
*** 23358,23369 ****
  a \fBppc970\fR object file in a \fBppc7400\fR library).  The linker
  for executables, \fBld\fR, quietly gives the executable the most
  restrictive subtype of any of its input files.
! .IP "\fB\-F\fR\fIdir\fR" 4
  .IX Item "-Fdir"
  Add the framework directory \fIdir\fR to the head of the list of
  directories to be searched for header files.  These directories are
  interleaved with those specified by \fB\-I\fR options and are
! scanned in a left-to-right order.
  .Sp
  A framework directory is a directory with frameworks in it.  A
  framework is a directory with a \fIHeaders\fR and/or
--- 23289,23300 ----
  a \fBppc970\fR object file in a \fBppc7400\fR library).  The linker
  for executables, \fBld\fR, quietly gives the executable the most
  restrictive subtype of any of its input files.
! .IP \fB\-F\fR\fIdir\fR 4
  .IX Item "-Fdir"
  Add the framework directory \fIdir\fR to the head of the list of
  directories to be searched for header files.  These directories are
  interleaved with those specified by \fB\-I\fR options and are
! scanned in a left\-to\-right order.
  .Sp
  A framework directory is a directory with frameworks in it.  A
  framework is a directory with a \fIHeaders\fR and/or
*************** in \fI.framework\fR.  The name of a fram
*** 23372,23378 ****
  directory excluding the \fI.framework\fR.  Headers associated with
  the framework are found in one of those two directories, with
  \&\fIHeaders\fR being searched first.  A subframework is a framework
! directory that is in a framework's \fIFrameworks\fR directory.
  Includes of subframework headers can only appear in a header of a
  framework that contains the subframework, or in a sibling subframework
  header.  Two subframeworks are siblings if they occur in the same
--- 23303,23309 ----
  directory excluding the \fI.framework\fR.  Headers associated with
  the framework are found in one of those two directories, with
  \&\fIHeaders\fR being searched first.  A subframework is a framework
! directory that is in a framework\*(Aqs \fIFrameworks\fR directory.
  Includes of subframework headers can only appear in a header of a
  framework that contains the subframework, or in a sibling subframework
  header.  Two subframeworks are siblings if they occur in the same
*************** in \fI/System/Library/Frameworks\fR and
*** 23385,23424 ****
  \&\f(CW\*(C`#include \*(C'\fR, where \fIFramework\fR denotes
  the name of the framework and \fIheader.h\fR is found in the
  \&\fIPrivateHeaders\fR or \fIHeaders\fR directory.
! .IP "\fB\-iframework\fR\fIdir\fR" 4
  .IX Item "-iframeworkdir"
  Like \fB\-F\fR except the directory is a treated as a system
  directory.  The main difference between this \fB\-iframework\fR and
  \&\fB\-F\fR is that with \fB\-iframework\fR the compiler does not
  warn about constructs contained within header files found via
  \&\fIdir\fR.  This option is valid only for the C family of languages.
! .IP "\fB\-gused\fR" 4
  .IX Item "-gused"
  Emit debugging information for symbols that are used.  For stabs
  debugging format, this enables \fB\-feliminate\-unused\-debug\-symbols\fR.
! This is by default \s-1ON.\s0
! .IP "\fB\-gfull\fR" 4
  .IX Item "-gfull"
  Emit debugging information for all symbols and types.
! .IP "\fB\-fconstant\-cfstrings\fR" 4
  .IX Item "-fconstant-cfstrings"
  The \fB\-fconstant\-cfstrings\fR is an alias for \fB\-mconstant\-cfstrings\fR.
! .IP "\fB\-mconstant\-cfstrings\fR" 4
  .IX Item "-mconstant-cfstrings"
  When the NeXT runtime is being used (the default on these systems), override
  any \fB\-fconstant\-string\-class\fR setting and cause \f(CW\*(C`@"..."\*(C'\fR
  literals to be laid out as constant CoreFoundation strings.
! .IP "\fB\-mmacosx\-version\-min=\fR\fIversion\fR" 4
  .IX Item "-mmacosx-version-min=version"
  The earliest version of MacOS X that this executable will run on is
  \&\fIversion\fR.  Typical values supported for \fIversion\fR include \f(CW12\fR,
  \&\f(CW10.12\fR, and \f(CW10.5.8\fR.
  .Sp
! If the compiler was built to use the system's headers by default,
  then the default for this option is the system version on which the
  compiler is running, otherwise the default is to make choices that
  are compatible with as many systems and code bases as possible.
! .IP "\fB\-mkernel\fR" 4
  .IX Item "-mkernel"
  Enable kernel development mode.  The \fB\-mkernel\fR option sets
  \&\fB\-static\fR, \fB\-fno\-common\fR, \fB\-fno\-use\-cxa\-atexit\fR,
--- 23316,23355 ----
  \&\f(CW\*(C`#include \*(C'\fR, where \fIFramework\fR denotes
  the name of the framework and \fIheader.h\fR is found in the
  \&\fIPrivateHeaders\fR or \fIHeaders\fR directory.
! .IP \fB\-iframework\fR\fIdir\fR 4
  .IX Item "-iframeworkdir"
  Like \fB\-F\fR except the directory is a treated as a system
  directory.  The main difference between this \fB\-iframework\fR and
  \&\fB\-F\fR is that with \fB\-iframework\fR the compiler does not
  warn about constructs contained within header files found via
  \&\fIdir\fR.  This option is valid only for the C family of languages.
! .IP \fB\-gused\fR 4
  .IX Item "-gused"
  Emit debugging information for symbols that are used.  For stabs
  debugging format, this enables \fB\-feliminate\-unused\-debug\-symbols\fR.
! This is by default ON.
! .IP \fB\-gfull\fR 4
  .IX Item "-gfull"
  Emit debugging information for all symbols and types.
! .IP \fB\-fconstant\-cfstrings\fR 4
  .IX Item "-fconstant-cfstrings"
  The \fB\-fconstant\-cfstrings\fR is an alias for \fB\-mconstant\-cfstrings\fR.
! .IP \fB\-mconstant\-cfstrings\fR 4
  .IX Item "-mconstant-cfstrings"
  When the NeXT runtime is being used (the default on these systems), override
  any \fB\-fconstant\-string\-class\fR setting and cause \f(CW\*(C`@"..."\*(C'\fR
  literals to be laid out as constant CoreFoundation strings.
! .IP \fB\-mmacosx\-version\-min=\fR\fIversion\fR 4
  .IX Item "-mmacosx-version-min=version"
  The earliest version of MacOS X that this executable will run on is
  \&\fIversion\fR.  Typical values supported for \fIversion\fR include \f(CW12\fR,
  \&\f(CW10.12\fR, and \f(CW10.5.8\fR.
  .Sp
! If the compiler was built to use the system\*(Aqs headers by default,
  then the default for this option is the system version on which the
  compiler is running, otherwise the default is to make choices that
  are compatible with as many systems and code bases as possible.
! .IP \fB\-mkernel\fR 4
  .IX Item "-mkernel"
  Enable kernel development mode.  The \fB\-mkernel\fR option sets
  \&\fB\-static\fR, \fB\-fno\-common\fR, \fB\-fno\-use\-cxa\-atexit\fR,
*************** Enable kernel development mode.  The \fB
*** 23427,23712 ****
  applicable.  This mode also sets \fB\-mno\-altivec\fR,
  \&\fB\-msoft\-float\fR, \fB\-fno\-builtin\fR and
  \&\fB\-mlong\-branch\fR for PowerPC targets.
! .IP "\fB\-mone\-byte\-bool\fR" 4
  .IX Item "-mone-byte-bool"
  Override the defaults for \f(CW\*(C`bool\*(C'\fR so that \f(CW\*(C`sizeof(bool)==1\*(C'\fR.
! By default \f(CW\*(C`sizeof(bool)\*(C'\fR is \f(CW4\fR when compiling for
  Darwin/PowerPC and \f(CW1\fR when compiling for Darwin/x86, so this
  option has no effect on x86.
  .Sp
! \&\fBWarning:\fR The \fB\-mone\-byte\-bool\fR switch causes \s-1GCC\s0
  to generate code that is not binary compatible with code generated
  without that switch.  Using this switch may require recompiling all
  other modules in a program, including system libraries.  Use this
! switch to conform to a non-default data model.
! .IP "\fB\-mfix\-and\-continue\fR" 4
  .IX Item "-mfix-and-continue"
  .PD 0
! .IP "\fB\-ffix\-and\-continue\fR" 4
  .IX Item "-ffix-and-continue"
! .IP "\fB\-findirect\-data\fR" 4
  .IX Item "-findirect-data"
  .PD
  Generate code suitable for fast turnaround development, such as to
! allow \s-1GDB\s0 to dynamically load \fI.o\fR files into already-running
  programs.  \fB\-findirect\-data\fR and \fB\-ffix\-and\-continue\fR
  are provided for backwards compatibility.
! .IP "\fB\-all_load\fR" 4
  .IX Item "-all_load"
  Loads all members of static archive libraries.
  See man \fBld\fR\|(1) for more information.
! .IP "\fB\-arch_errors_fatal\fR" 4
  .IX Item "-arch_errors_fatal"
  Cause the errors having to do with files that have the wrong architecture
  to be fatal.
! .IP "\fB\-bind_at_load\fR" 4
  .IX Item "-bind_at_load"
  Causes the output file to be marked such that the dynamic linker will
  bind all undefined references when the file is loaded or launched.
! .IP "\fB\-bundle\fR" 4
  .IX Item "-bundle"
! Produce a Mach-o bundle format file.
  See man \fBld\fR\|(1) for more information.
  .IP "\fB\-bundle_loader\fR \fIexecutable\fR" 4
  .IX Item "-bundle_loader executable"
  This option specifies the \fIexecutable\fR that will load the build
  output file being linked.  See man \fBld\fR\|(1) for more information.
! .IP "\fB\-dynamiclib\fR" 4
  .IX Item "-dynamiclib"
! When passed this option, \s-1GCC\s0 produces a dynamic library instead of
  an executable when linking, using the Darwin \fIlibtool\fR command.
! .IP "\fB\-force_cpusubtype_ALL\fR" 4
  .IX Item "-force_cpusubtype_ALL"
! This causes \s-1GCC\s0's output file to have the \fB\s-1ALL\s0\fR subtype, instead of
  one controlled by the \fB\-mcpu\fR or \fB\-march\fR option.
  .IP "\fB\-allowable_client\fR  \fIclient_name\fR" 4
  .IX Item "-allowable_client client_name"
  .PD 0
! .IP "\fB\-client_name\fR" 4
  .IX Item "-client_name"
! .IP "\fB\-compatibility_version\fR" 4
  .IX Item "-compatibility_version"
! .IP "\fB\-current_version\fR" 4
  .IX Item "-current_version"
! .IP "\fB\-dead_strip\fR" 4
  .IX Item "-dead_strip"
! .IP "\fB\-dependency\-file\fR" 4
  .IX Item "-dependency-file"
! .IP "\fB\-dylib_file\fR" 4
  .IX Item "-dylib_file"
! .IP "\fB\-dylinker_install_name\fR" 4
  .IX Item "-dylinker_install_name"
! .IP "\fB\-dynamic\fR" 4
  .IX Item "-dynamic"
! .IP "\fB\-exported_symbols_list\fR" 4
  .IX Item "-exported_symbols_list"
! .IP "\fB\-filelist\fR" 4
  .IX Item "-filelist"
! .IP "\fB\-flat_namespace\fR" 4
  .IX Item "-flat_namespace"
! .IP "\fB\-force_flat_namespace\fR" 4
  .IX Item "-force_flat_namespace"
! .IP "\fB\-headerpad_max_install_names\fR" 4
  .IX Item "-headerpad_max_install_names"
! .IP "\fB\-image_base\fR" 4
  .IX Item "-image_base"
! .IP "\fB\-init\fR" 4
  .IX Item "-init"
! .IP "\fB\-install_name\fR" 4
  .IX Item "-install_name"
! .IP "\fB\-keep_private_externs\fR" 4
  .IX Item "-keep_private_externs"
! .IP "\fB\-multi_module\fR" 4
  .IX Item "-multi_module"
! .IP "\fB\-multiply_defined\fR" 4
  .IX Item "-multiply_defined"
! .IP "\fB\-multiply_defined_unused\fR" 4
  .IX Item "-multiply_defined_unused"
! .IP "\fB\-noall_load\fR" 4
  .IX Item "-noall_load"
! .IP "\fB\-no_dead_strip_inits_and_terms\fR" 4
  .IX Item "-no_dead_strip_inits_and_terms"
! .IP "\fB\-nofixprebinding\fR" 4
  .IX Item "-nofixprebinding"
! .IP "\fB\-nomultidefs\fR" 4
  .IX Item "-nomultidefs"
! .IP "\fB\-noprebind\fR" 4
  .IX Item "-noprebind"
! .IP "\fB\-noseglinkedit\fR" 4
  .IX Item "-noseglinkedit"
! .IP "\fB\-pagezero_size\fR" 4
  .IX Item "-pagezero_size"
! .IP "\fB\-prebind\fR" 4
  .IX Item "-prebind"
! .IP "\fB\-prebind_all_twolevel_modules\fR" 4
  .IX Item "-prebind_all_twolevel_modules"
! .IP "\fB\-private_bundle\fR" 4
  .IX Item "-private_bundle"
! .IP "\fB\-read_only_relocs\fR" 4
  .IX Item "-read_only_relocs"
! .IP "\fB\-sectalign\fR" 4
  .IX Item "-sectalign"
! .IP "\fB\-sectobjectsymbols\fR" 4
  .IX Item "-sectobjectsymbols"
! .IP "\fB\-whyload\fR" 4
  .IX Item "-whyload"
! .IP "\fB\-seg1addr\fR" 4
  .IX Item "-seg1addr"
! .IP "\fB\-sectcreate\fR" 4
  .IX Item "-sectcreate"
! .IP "\fB\-sectobjectsymbols\fR" 4
  .IX Item "-sectobjectsymbols"
! .IP "\fB\-sectorder\fR" 4
  .IX Item "-sectorder"
! .IP "\fB\-segaddr\fR" 4
  .IX Item "-segaddr"
! .IP "\fB\-segs_read_only_addr\fR" 4
  .IX Item "-segs_read_only_addr"
! .IP "\fB\-segs_read_write_addr\fR" 4
  .IX Item "-segs_read_write_addr"
! .IP "\fB\-seg_addr_table\fR" 4
  .IX Item "-seg_addr_table"
! .IP "\fB\-seg_addr_table_filename\fR" 4
  .IX Item "-seg_addr_table_filename"
! .IP "\fB\-seglinkedit\fR" 4
  .IX Item "-seglinkedit"
! .IP "\fB\-segprot\fR" 4
  .IX Item "-segprot"
! .IP "\fB\-segs_read_only_addr\fR" 4
  .IX Item "-segs_read_only_addr"
! .IP "\fB\-segs_read_write_addr\fR" 4
  .IX Item "-segs_read_write_addr"
! .IP "\fB\-single_module\fR" 4
  .IX Item "-single_module"
! .IP "\fB\-static\fR" 4
  .IX Item "-static"
! .IP "\fB\-sub_library\fR" 4
  .IX Item "-sub_library"
! .IP "\fB\-sub_umbrella\fR" 4
  .IX Item "-sub_umbrella"
! .IP "\fB\-twolevel_namespace\fR" 4
  .IX Item "-twolevel_namespace"
! .IP "\fB\-umbrella\fR" 4
  .IX Item "-umbrella"
! .IP "\fB\-undefined\fR" 4
  .IX Item "-undefined"
! .IP "\fB\-unexported_symbols_list\fR" 4
  .IX Item "-unexported_symbols_list"
! .IP "\fB\-weak_reference_mismatches\fR" 4
  .IX Item "-weak_reference_mismatches"
! .IP "\fB\-whatsloaded\fR" 4
  .IX Item "-whatsloaded"
  .PD
  These options are passed to the Darwin linker.  The Darwin linker man page
  describes them in detail.
  .PP
! \fI\s-1DEC\s0 Alpha Options\fR
  .IX Subsection "DEC Alpha Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1DEC\s0 Alpha implementations:
! .IP "\fB\-mno\-soft\-float\fR" 4
  .IX Item "-mno-soft-float"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
! Use (do not use) the hardware floating-point instructions for
! floating-point operations.  When \fB\-msoft\-float\fR is specified,
! functions in \fIlibgcc.a\fR are used to perform floating-point
  operations.  Unless they are replaced by routines that emulate the
! floating-point operations, or compiled in such a way as to call such
! emulations routines, these routines issue floating-point
! operations.   If you are compiling for an Alpha without floating-point
  operations, you must ensure that the library is built so as not to call
  them.
  .Sp
! Note that Alpha implementations without floating-point operations are
! required to have floating-point registers.
! .IP "\fB\-mfp\-reg\fR" 4
  .IX Item "-mfp-reg"
  .PD 0
! .IP "\fB\-mno\-fp\-regs\fR" 4
  .IX Item "-mno-fp-regs"
  .PD
! Generate code that uses (does not use) the floating-point register set.
! \&\fB\-mno\-fp\-regs\fR implies \fB\-msoft\-float\fR.  If the floating-point
! register set is not used, floating-point operands are passed in integer
! registers as if they were integers and floating-point results are passed
! in \f(CW$0\fR instead of \f(CW$f0\fR.  This is a non-standard calling sequence,
! so any function with a floating-point argument or return value called by code
  compiled with \fB\-mno\-fp\-regs\fR must also be compiled with that
  option.
  .Sp
  A typical use of this option is building a kernel that does not use,
! and hence need not save and restore, any floating-point registers.
! .IP "\fB\-mieee\fR" 4
  .IX Item "-mieee"
! The Alpha architecture implements floating-point hardware optimized for
! maximum performance.  It is mostly compliant with the \s-1IEEE\s0 floating-point
  standard.  However, for full compliance, software assistance is
! required.  This option generates code fully IEEE-compliant code
! \&\fIexcept\fR that the \fIinexact-flag\fR is not maintained (see below).
  If this option is turned on, the preprocessor macro \f(CW\*(C`_IEEE_FP\*(C'\fR is
  defined during compilation.  The resulting code is less efficient but is
! able to correctly support denormalized numbers and exceptional \s-1IEEE\s0
! values such as not-a-number and plus/minus infinity.  Other Alpha
  compilers call this option \fB\-ieee_with_no_inexact\fR.
! .IP "\fB\-mieee\-with\-inexact\fR" 4
  .IX Item "-mieee-with-inexact"
  This is like \fB\-mieee\fR except the generated code also maintains
! the \s-1IEEE\s0 \fIinexact-flag\fR.  Turning on this option causes the
! generated code to implement fully-compliant \s-1IEEE\s0 math.  In addition to
  \&\f(CW\*(C`_IEEE_FP\*(C'\fR, \f(CW\*(C`_IEEE_FP_EXACT\*(C'\fR is defined as a preprocessor
  macro.  On some Alpha implementations the resulting code may execute
  significantly slower than the code generated by default.  Since there is
! very little code that depends on the \fIinexact-flag\fR, you should
  normally not specify this option.  Other Alpha compilers call this
  option \fB\-ieee_with_inexact\fR.
! .IP "\fB\-mfp\-trap\-mode=\fR\fItrap-mode\fR" 4
  .IX Item "-mfp-trap-mode=trap-mode"
! This option controls what floating-point related traps are enabled.
! Other Alpha compilers call this option \fB\-fptm\fR \fItrap-mode\fR.
  The trap mode can be set to one of four values:
  .RS 4
! .IP "\fBn\fR" 4
  .IX Item "n"
  This is the default (normal) setting.  The only traps that are enabled
  are the ones that cannot be disabled in software (e.g., division by zero
  trap).
! .IP "\fBu\fR" 4
  .IX Item "u"
  In addition to the traps enabled by \fBn\fR, underflow traps are enabled
  as well.
! .IP "\fBsu\fR" 4
  .IX Item "su"
  Like \fBu\fR, but the instructions are marked to be safe for software
  completion (see Alpha architecture manual for details).
! .IP "\fBsui\fR" 4
  .IX Item "sui"
  Like \fBsu\fR, but inexact traps are enabled as well.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mfp\-rounding\-mode=\fR\fIrounding-mode\fR" 4
  .IX Item "-mfp-rounding-mode=rounding-mode"
! Selects the \s-1IEEE\s0 rounding mode.  Other Alpha compilers call this option
! \&\fB\-fprm\fR \fIrounding-mode\fR.  The \fIrounding-mode\fR can be one
  of:
  .RS 4
! .IP "\fBn\fR" 4
  .IX Item "n"
! Normal \s-1IEEE\s0 rounding mode.  Floating-point numbers are rounded towards
  the nearest machine number or towards the even machine number in case
  of a tie.
! .IP "\fBm\fR" 4
  .IX Item "m"
  Round towards minus infinity.
! .IP "\fBc\fR" 4
  .IX Item "c"
! Chopped rounding mode.  Floating-point numbers are rounded towards zero.
! .IP "\fBd\fR" 4
  .IX Item "d"
! Dynamic rounding mode.  A field in the floating-point control register
  (\fIfpcr\fR, see Alpha architecture reference manual) controls the
  rounding mode in effect.  The C library initializes this register for
  rounding towards plus infinity.  Thus, unless your program modifies the
--- 23358,23643 ----
  applicable.  This mode also sets \fB\-mno\-altivec\fR,
  \&\fB\-msoft\-float\fR, \fB\-fno\-builtin\fR and
  \&\fB\-mlong\-branch\fR for PowerPC targets.
! .IP \fB\-mone\-byte\-bool\fR 4
  .IX Item "-mone-byte-bool"
  Override the defaults for \f(CW\*(C`bool\*(C'\fR so that \f(CW\*(C`sizeof(bool)==1\*(C'\fR.
! By default \f(CWsizeof(bool)\fR is \f(CW4\fR when compiling for
  Darwin/PowerPC and \f(CW1\fR when compiling for Darwin/x86, so this
  option has no effect on x86.
  .Sp
! \&\fBWarning:\fR The \fB\-mone\-byte\-bool\fR switch causes 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.
! .IP \fB\-mfix\-and\-continue\fR 4
  .IX Item "-mfix-and-continue"
  .PD 0
! .IP \fB\-ffix\-and\-continue\fR 4
  .IX Item "-ffix-and-continue"
! .IP \fB\-findirect\-data\fR 4
  .IX Item "-findirect-data"
  .PD
  Generate code suitable for fast turnaround development, such as to
! allow GDB to dynamically load \fI.o\fR files into already\-running
  programs.  \fB\-findirect\-data\fR and \fB\-ffix\-and\-continue\fR
  are provided for backwards compatibility.
! .IP \fB\-all_load\fR 4
  .IX Item "-all_load"
  Loads all members of static archive libraries.
  See man \fBld\fR\|(1) for more information.
! .IP \fB\-arch_errors_fatal\fR 4
  .IX Item "-arch_errors_fatal"
  Cause the errors having to do with files that have the wrong architecture
  to be fatal.
! .IP \fB\-bind_at_load\fR 4
  .IX Item "-bind_at_load"
  Causes the output file to be marked such that the dynamic linker will
  bind all undefined references when the file is loaded or launched.
! .IP \fB\-bundle\fR 4
  .IX Item "-bundle"
! Produce a Mach\-o bundle format file.
  See man \fBld\fR\|(1) for more information.
  .IP "\fB\-bundle_loader\fR \fIexecutable\fR" 4
  .IX Item "-bundle_loader executable"
  This option specifies the \fIexecutable\fR that will load the build
  output file being linked.  See man \fBld\fR\|(1) for more information.
! .IP \fB\-dynamiclib\fR 4
  .IX Item "-dynamiclib"
! When passed this option, GCC produces a dynamic library instead of
  an executable when linking, using the Darwin \fIlibtool\fR command.
! .IP \fB\-force_cpusubtype_ALL\fR 4
  .IX Item "-force_cpusubtype_ALL"
! This causes GCC\*(Aqs output file to have the \fBALL\fR subtype, instead of
  one controlled by the \fB\-mcpu\fR or \fB\-march\fR option.
  .IP "\fB\-allowable_client\fR  \fIclient_name\fR" 4
  .IX Item "-allowable_client client_name"
  .PD 0
! .IP \fB\-client_name\fR 4
  .IX Item "-client_name"
! .IP \fB\-compatibility_version\fR 4
  .IX Item "-compatibility_version"
! .IP \fB\-current_version\fR 4
  .IX Item "-current_version"
! .IP \fB\-dead_strip\fR 4
  .IX Item "-dead_strip"
! .IP \fB\-dependency\-file\fR 4
  .IX Item "-dependency-file"
! .IP \fB\-dylib_file\fR 4
  .IX Item "-dylib_file"
! .IP \fB\-dylinker_install_name\fR 4
  .IX Item "-dylinker_install_name"
! .IP \fB\-dynamic\fR 4
  .IX Item "-dynamic"
! .IP \fB\-exported_symbols_list\fR 4
  .IX Item "-exported_symbols_list"
! .IP \fB\-filelist\fR 4
  .IX Item "-filelist"
! .IP \fB\-flat_namespace\fR 4
  .IX Item "-flat_namespace"
! .IP \fB\-force_flat_namespace\fR 4
  .IX Item "-force_flat_namespace"
! .IP \fB\-headerpad_max_install_names\fR 4
  .IX Item "-headerpad_max_install_names"
! .IP \fB\-image_base\fR 4
  .IX Item "-image_base"
! .IP \fB\-init\fR 4
  .IX Item "-init"
! .IP \fB\-install_name\fR 4
  .IX Item "-install_name"
! .IP \fB\-keep_private_externs\fR 4
  .IX Item "-keep_private_externs"
! .IP \fB\-multi_module\fR 4
  .IX Item "-multi_module"
! .IP \fB\-multiply_defined\fR 4
  .IX Item "-multiply_defined"
! .IP \fB\-multiply_defined_unused\fR 4
  .IX Item "-multiply_defined_unused"
! .IP \fB\-noall_load\fR 4
  .IX Item "-noall_load"
! .IP \fB\-no_dead_strip_inits_and_terms\fR 4
  .IX Item "-no_dead_strip_inits_and_terms"
! .IP \fB\-nofixprebinding\fR 4
  .IX Item "-nofixprebinding"
! .IP \fB\-nomultidefs\fR 4
  .IX Item "-nomultidefs"
! .IP \fB\-noprebind\fR 4
  .IX Item "-noprebind"
! .IP \fB\-noseglinkedit\fR 4
  .IX Item "-noseglinkedit"
! .IP \fB\-pagezero_size\fR 4
  .IX Item "-pagezero_size"
! .IP \fB\-prebind\fR 4
  .IX Item "-prebind"
! .IP \fB\-prebind_all_twolevel_modules\fR 4
  .IX Item "-prebind_all_twolevel_modules"
! .IP \fB\-private_bundle\fR 4
  .IX Item "-private_bundle"
! .IP \fB\-read_only_relocs\fR 4
  .IX Item "-read_only_relocs"
! .IP \fB\-sectalign\fR 4
  .IX Item "-sectalign"
! .IP \fB\-sectobjectsymbols\fR 4
  .IX Item "-sectobjectsymbols"
! .IP \fB\-whyload\fR 4
  .IX Item "-whyload"
! .IP \fB\-seg1addr\fR 4
  .IX Item "-seg1addr"
! .IP \fB\-sectcreate\fR 4
  .IX Item "-sectcreate"
! .IP \fB\-sectobjectsymbols\fR 4
  .IX Item "-sectobjectsymbols"
! .IP \fB\-sectorder\fR 4
  .IX Item "-sectorder"
! .IP \fB\-segaddr\fR 4
  .IX Item "-segaddr"
! .IP \fB\-segs_read_only_addr\fR 4
  .IX Item "-segs_read_only_addr"
! .IP \fB\-segs_read_write_addr\fR 4
  .IX Item "-segs_read_write_addr"
! .IP \fB\-seg_addr_table\fR 4
  .IX Item "-seg_addr_table"
! .IP \fB\-seg_addr_table_filename\fR 4
  .IX Item "-seg_addr_table_filename"
! .IP \fB\-seglinkedit\fR 4
  .IX Item "-seglinkedit"
! .IP \fB\-segprot\fR 4
  .IX Item "-segprot"
! .IP \fB\-segs_read_only_addr\fR 4
  .IX Item "-segs_read_only_addr"
! .IP \fB\-segs_read_write_addr\fR 4
  .IX Item "-segs_read_write_addr"
! .IP \fB\-single_module\fR 4
  .IX Item "-single_module"
! .IP \fB\-static\fR 4
  .IX Item "-static"
! .IP \fB\-sub_library\fR 4
  .IX Item "-sub_library"
! .IP \fB\-sub_umbrella\fR 4
  .IX Item "-sub_umbrella"
! .IP \fB\-twolevel_namespace\fR 4
  .IX Item "-twolevel_namespace"
! .IP \fB\-umbrella\fR 4
  .IX Item "-umbrella"
! .IP \fB\-undefined\fR 4
  .IX Item "-undefined"
! .IP \fB\-unexported_symbols_list\fR 4
  .IX Item "-unexported_symbols_list"
! .IP \fB\-weak_reference_mismatches\fR 4
  .IX Item "-weak_reference_mismatches"
! .IP \fB\-whatsloaded\fR 4
  .IX Item "-whatsloaded"
  .PD
  These options are passed to the Darwin linker.  The Darwin linker man page
  describes them in detail.
  .PP
! \fIDEC Alpha Options\fR
  .IX Subsection "DEC Alpha Options"
  .PP
! These \fB\-m\fR options are defined for the DEC Alpha implementations:
! .IP \fB\-mno\-soft\-float\fR 4
  .IX Item "-mno-soft-float"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
! Use (do not use) the hardware floating\-point instructions for
! floating\-point operations.  When \fB\-msoft\-float\fR is specified,
! functions in \fIlibgcc.a\fR are used to perform floating\-point
  operations.  Unless they are replaced by routines that emulate the
! floating\-point operations, or compiled in such a way as to call such
! emulations routines, these routines issue floating\-point
! operations.   If you are compiling for an Alpha without floating\-point
  operations, you must ensure that the library is built so as not to call
  them.
  .Sp
! Note that Alpha implementations without floating\-point operations are
! required to have floating\-point registers.
! .IP \fB\-mfp\-reg\fR 4
  .IX Item "-mfp-reg"
  .PD 0
! .IP \fB\-mno\-fp\-regs\fR 4
  .IX Item "-mno-fp-regs"
  .PD
! Generate code that uses (does not use) the floating\-point register set.
! \&\fB\-mno\-fp\-regs\fR implies \fB\-msoft\-float\fR.  If the floating\-point
! register set is not used, floating\-point operands are passed in integer
! registers as if they were integers and floating\-point results are passed
! in \f(CW$0\fR instead of \f(CW$f0\fR.  This is a non\-standard calling sequence,
! so any function with a floating\-point argument or return value called by code
  compiled with \fB\-mno\-fp\-regs\fR must also be compiled with that
  option.
  .Sp
  A typical use of this option is building a kernel that does not use,
! and hence need not save and restore, any floating\-point registers.
! .IP \fB\-mieee\fR 4
  .IX Item "-mieee"
! The Alpha architecture implements floating\-point hardware optimized for
! maximum performance.  It is mostly compliant with the IEEE floating\-point
  standard.  However, for full compliance, software assistance is
! required.  This option generates code fully IEEE\-compliant code
! \&\fIexcept\fR that the \fIinexact\-flag\fR is not maintained (see below).
  If this option is turned on, the preprocessor macro \f(CW\*(C`_IEEE_FP\*(C'\fR is
  defined during compilation.  The resulting code is less efficient but is
! able to correctly support denormalized numbers and exceptional IEEE
! values such as not\-a\-number and plus/minus infinity.  Other Alpha
  compilers call this option \fB\-ieee_with_no_inexact\fR.
! .IP \fB\-mieee\-with\-inexact\fR 4
  .IX Item "-mieee-with-inexact"
  This is like \fB\-mieee\fR except the generated code also maintains
! the IEEE \fIinexact\-flag\fR.  Turning on this option causes the
! generated code to implement fully\-compliant IEEE math.  In addition to
  \&\f(CW\*(C`_IEEE_FP\*(C'\fR, \f(CW\*(C`_IEEE_FP_EXACT\*(C'\fR is defined as a preprocessor
  macro.  On some Alpha implementations the resulting code may execute
  significantly slower than the code generated by default.  Since there is
! very little code that depends on the \fIinexact\-flag\fR, you should
  normally not specify this option.  Other Alpha compilers call this
  option \fB\-ieee_with_inexact\fR.
! .IP \fB\-mfp\-trap\-mode=\fR\fItrap\-mode\fR 4
  .IX Item "-mfp-trap-mode=trap-mode"
! This option controls what floating\-point related traps are enabled.
! Other Alpha compilers call this option \fB\-fptm\fR \fItrap\-mode\fR.
  The trap mode can be set to one of four values:
  .RS 4
! .IP \fBn\fR 4
  .IX Item "n"
  This is the default (normal) setting.  The only traps that are enabled
  are the ones that cannot be disabled in software (e.g., division by zero
  trap).
! .IP \fBu\fR 4
  .IX Item "u"
  In addition to the traps enabled by \fBn\fR, underflow traps are enabled
  as well.
! .IP \fBsu\fR 4
  .IX Item "su"
  Like \fBu\fR, but the instructions are marked to be safe for software
  completion (see Alpha architecture manual for details).
! .IP \fBsui\fR 4
  .IX Item "sui"
  Like \fBsu\fR, but inexact traps are enabled as well.
  .RE
  .RS 4
  .RE
! .IP \fB\-mfp\-rounding\-mode=\fR\fIrounding\-mode\fR 4
  .IX Item "-mfp-rounding-mode=rounding-mode"
! Selects the IEEE rounding mode.  Other Alpha compilers call this option
! \&\fB\-fprm\fR \fIrounding\-mode\fR.  The \fIrounding\-mode\fR can be one
  of:
  .RS 4
! .IP \fBn\fR 4
  .IX Item "n"
! Normal IEEE rounding mode.  Floating\-point numbers are rounded towards
  the nearest machine number or towards the even machine number in case
  of a tie.
! .IP \fBm\fR 4
  .IX Item "m"
  Round towards minus infinity.
! .IP \fBc\fR 4
  .IX Item "c"
! Chopped rounding mode.  Floating\-point numbers are rounded towards zero.
! .IP \fBd\fR 4
  .IX Item "d"
! Dynamic rounding mode.  A field in the floating\-point control register
  (\fIfpcr\fR, see Alpha architecture reference manual) controls the
  rounding mode in effect.  The C library initializes this register for
  rounding towards plus infinity.  Thus, unless your program modifies the
*************** rounding towards plus infinity.  Thus, u
*** 23714,23818 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-mtrap\-precision=\fR\fItrap-precision\fR" 4
  .IX Item "-mtrap-precision=trap-precision"
! In the Alpha architecture, floating-point traps are imprecise.  This
  means without software assistance it is impossible to recover from a
  floating trap and program execution normally needs to be terminated.
! \&\s-1GCC\s0 can generate code that can assist operating system trap handlers
! in determining the exact location that caused a floating-point trap.
  Depending on the requirements of an application, different levels of
  precisions can be selected:
  .RS 4
! .IP "\fBp\fR" 4
  .IX Item "p"
  Program precision.  This option is the default and means a trap handler
! can only identify which program caused a floating-point exception.
! .IP "\fBf\fR" 4
  .IX Item "f"
  Function precision.  The trap handler can determine the function that
! caused a floating-point exception.
! .IP "\fBi\fR" 4
  .IX Item "i"
  Instruction precision.  The trap handler can determine the exact
! instruction that caused a floating-point exception.
  .RE
  .RS 4
  .Sp
  Other Alpha compilers provide the equivalent options called
  \&\fB\-scope_safe\fR and \fB\-resumption_safe\fR.
  .RE
! .IP "\fB\-mieee\-conformant\fR" 4
  .IX Item "-mieee-conformant"
! This option marks the generated code as \s-1IEEE\s0 conformant.  You must not
  use this option unless you also specify \fB\-mtrap\-precision=i\fR and either
  \&\fB\-mfp\-trap\-mode=su\fR or \fB\-mfp\-trap\-mode=sui\fR.  Its only effect
  is to emit the line \fB.eflag 48\fR in the function prologue of the
  generated assembly file.
! .IP "\fB\-mbuild\-constants\fR" 4
  .IX Item "-mbuild-constants"
! Normally \s-1GCC\s0 examines a 32\- or 64\-bit integer constant to
  see if it can construct it from smaller constants in two or three
  instructions.  If it cannot, it outputs the constant as a literal and
  generates code to load it from the data segment at run time.
  .Sp
! Use this option to require \s-1GCC\s0 to construct \fIall\fR integer constants
  using code, even if it takes more instructions (the maximum is six).
  .Sp
  You typically use this option to build a shared library dynamic
  loader.  Itself a shared library, it must relocate itself in memory
  before it can find the variables and constants in its own data segment.
! .IP "\fB\-mbwx\fR" 4
  .IX Item "-mbwx"
  .PD 0
! .IP "\fB\-mno\-bwx\fR" 4
  .IX Item "-mno-bwx"
! .IP "\fB\-mcix\fR" 4
  .IX Item "-mcix"
! .IP "\fB\-mno\-cix\fR" 4
  .IX Item "-mno-cix"
! .IP "\fB\-mfix\fR" 4
  .IX Item "-mfix"
! .IP "\fB\-mno\-fix\fR" 4
  .IX Item "-mno-fix"
! .IP "\fB\-mmax\fR" 4
  .IX Item "-mmax"
! .IP "\fB\-mno\-max\fR" 4
  .IX Item "-mno-max"
  .PD
! Indicate whether \s-1GCC\s0 should generate code to use the optional \s-1BWX,
! CIX, FIX\s0 and \s-1MAX\s0 instruction sets.  The default is to use the instruction
! sets supported by the \s-1CPU\s0 type specified via \fB\-mcpu=\fR option or that
! of the \s-1CPU\s0 on which \s-1GCC\s0 was built if none is specified.
! .IP "\fB\-mfloat\-vax\fR" 4
  .IX Item "-mfloat-vax"
  .PD 0
! .IP "\fB\-mfloat\-ieee\fR" 4
  .IX Item "-mfloat-ieee"
  .PD
! Generate code that uses (does not use) \s-1VAX F\s0 and G floating-point
! arithmetic instead of \s-1IEEE\s0 single and double precision.
! .IP "\fB\-mexplicit\-relocs\fR" 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP "\fB\-mno\-explicit\-relocs\fR" 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Older Alpha assemblers provided no way to generate symbol relocations
  except via assembler macros.  Use of these macros does not allow
! optimal instruction scheduling.  \s-1GNU\s0 binutils as of version 2.12
  supports a new syntax that allows the compiler to explicitly mark
  which relocations should apply to which instructions.  This option
! is mostly useful for debugging, as \s-1GCC\s0 detects the capabilities of
  the assembler when it is built and sets the default accordingly.
! .IP "\fB\-msmall\-data\fR" 4
  .IX Item "-msmall-data"
  .PD 0
! .IP "\fB\-mlarge\-data\fR" 4
  .IX Item "-mlarge-data"
  .PD
  When \fB\-mexplicit\-relocs\fR is in effect, static data is
! accessed via \fIgp-relative\fR relocations.  When \fB\-msmall\-data\fR
  is used, objects 8 bytes long or smaller are placed in a \fIsmall data area\fR
  (the \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR sections) and are accessed via
  16\-bit relocations off of the \f(CW$gp\fR register.  This limits the
--- 23645,23749 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-mtrap\-precision=\fR\fItrap\-precision\fR 4
  .IX Item "-mtrap-precision=trap-precision"
! In the Alpha architecture, floating\-point traps are imprecise.  This
  means without software assistance it is impossible to recover from a
  floating trap and program execution normally needs to be terminated.
! 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:
  .RS 4
! .IP \fBp\fR 4
  .IX Item "p"
  Program precision.  This option is the default and means a trap handler
! can only identify which program caused a floating\-point exception.
! .IP \fBf\fR 4
  .IX Item "f"
  Function precision.  The trap handler can determine the function that
! caused a floating\-point exception.
! .IP \fBi\fR 4
  .IX Item "i"
  Instruction precision.  The trap handler can determine the exact
! instruction that caused a floating\-point exception.
  .RE
  .RS 4
  .Sp
  Other Alpha compilers provide the equivalent options called
  \&\fB\-scope_safe\fR and \fB\-resumption_safe\fR.
  .RE
! .IP \fB\-mieee\-conformant\fR 4
  .IX Item "-mieee-conformant"
! This option marks the generated code as IEEE conformant.  You must not
  use this option unless you also specify \fB\-mtrap\-precision=i\fR and either
  \&\fB\-mfp\-trap\-mode=su\fR or \fB\-mfp\-trap\-mode=sui\fR.  Its only effect
  is to emit the line \fB.eflag 48\fR in the function prologue of the
  generated assembly file.
! .IP \fB\-mbuild\-constants\fR 4
  .IX Item "-mbuild-constants"
! Normally GCC examines a 32\- or 64\-bit integer constant to
  see if it can construct it from smaller constants in two or three
  instructions.  If it cannot, it outputs the constant as a literal and
  generates code to load it from the data segment at run time.
  .Sp
! Use this option to require GCC to construct \fIall\fR integer constants
  using code, even if it takes more instructions (the maximum is six).
  .Sp
  You typically use this option to build a shared library dynamic
  loader.  Itself a shared library, it must relocate itself in memory
  before it can find the variables and constants in its own data segment.
! .IP \fB\-mbwx\fR 4
  .IX Item "-mbwx"
  .PD 0
! .IP \fB\-mno\-bwx\fR 4
  .IX Item "-mno-bwx"
! .IP \fB\-mcix\fR 4
  .IX Item "-mcix"
! .IP \fB\-mno\-cix\fR 4
  .IX Item "-mno-cix"
! .IP \fB\-mfix\fR 4
  .IX Item "-mfix"
! .IP \fB\-mno\-fix\fR 4
  .IX Item "-mno-fix"
! .IP \fB\-mmax\fR 4
  .IX Item "-mmax"
! .IP \fB\-mno\-max\fR 4
  .IX Item "-mno-max"
  .PD
! Indicate whether 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 \fB\-mcpu=\fR option or that
! of the CPU on which GCC was built if none is specified.
! .IP \fB\-mfloat\-vax\fR 4
  .IX Item "-mfloat-vax"
  .PD 0
! .IP \fB\-mfloat\-ieee\fR 4
  .IX Item "-mfloat-ieee"
  .PD
! Generate code that uses (does not use) VAX F and G floating\-point
! arithmetic instead of IEEE single and double precision.
! .IP \fB\-mexplicit\-relocs\fR 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP \fB\-mno\-explicit\-relocs\fR 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Older Alpha assemblers provided no way to generate symbol relocations
  except via assembler macros.  Use of these macros does not allow
! optimal instruction scheduling.  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.
! .IP \fB\-msmall\-data\fR 4
  .IX Item "-msmall-data"
  .PD 0
! .IP \fB\-mlarge\-data\fR 4
  .IX Item "-mlarge-data"
  .PD
  When \fB\-mexplicit\-relocs\fR is in effect, static data is
! accessed via \fIgp\-relative\fR relocations.  When \fB\-msmall\-data\fR
  is used, objects 8 bytes long or smaller are placed in a \fIsmall data area\fR
  (the \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR sections) and are accessed via
  16\-bit relocations off of the \f(CW$gp\fR register.  This limits the
*************** directly accessed via a single instructi
*** 23822,23835 ****
  The default is \fB\-mlarge\-data\fR.  With this option the data area
  is limited to just below 2GB.  Programs that require more than 2GB of
  data must use \f(CW\*(C`malloc\*(C'\fR or \f(CW\*(C`mmap\*(C'\fR to allocate the data in the
! heap instead of in the program's data segment.
  .Sp
  When generating code for shared libraries, \fB\-fpic\fR implies
  \&\fB\-msmall\-data\fR and \fB\-fPIC\fR implies \fB\-mlarge\-data\fR.
! .IP "\fB\-msmall\-text\fR" 4
  .IX Item "-msmall-text"
  .PD 0
! .IP "\fB\-mlarge\-text\fR" 4
  .IX Item "-mlarge-text"
  .PD
  When \fB\-msmall\-text\fR is used, the compiler assumes that the
--- 23753,23766 ----
  The default is \fB\-mlarge\-data\fR.  With this option the data area
  is limited to just below 2GB.  Programs that require more than 2GB of
  data must use \f(CW\*(C`malloc\*(C'\fR or \f(CW\*(C`mmap\*(C'\fR to allocate the data in the
! heap instead of in the program\*(Aqs data segment.
  .Sp
  When generating code for shared libraries, \fB\-fpic\fR implies
  \&\fB\-msmall\-data\fR and \fB\-fPIC\fR implies \fB\-mlarge\-data\fR.
! .IP \fB\-msmall\-text\fR 4
  .IX Item "-msmall-text"
  .PD 0
! .IP \fB\-mlarge\-text\fR 4
  .IX Item "-mlarge-text"
  .PD
  When \fB\-msmall\-text\fR is used, the compiler assumes that the
*************** same \f(CW$gp\fR value, and thus reduce
*** 23840,23921 ****
  required for a function call from 4 to 1.
  .Sp
  The default is \fB\-mlarge\-text\fR.
! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set and instruction scheduling parameters for
! machine type \fIcpu_type\fR.  You can specify either the \fB\s-1EV\s0\fR
! style name or the corresponding chip number.  \s-1GCC\s0 supports scheduling
! parameters for the \s-1EV4, EV5\s0 and \s-1EV6\s0 family of processors and
  chooses the default values for the instruction set from the processor
! you specify.  If you do not specify a processor type, \s-1GCC\s0 defaults
  to the processor on which the compiler was built.
  .Sp
  Supported values for \fIcpu_type\fR are
  .RS 4
! .IP "\fBev4\fR" 4
  .IX Item "ev4"
  .PD 0
! .IP "\fBev45\fR" 4
  .IX Item "ev45"
! .IP "\fB21064\fR" 4
  .IX Item "21064"
  .PD
! Schedules as an \s-1EV4\s0 and has no instruction set extensions.
! .IP "\fBev5\fR" 4
  .IX Item "ev5"
  .PD 0
! .IP "\fB21164\fR" 4
  .IX Item "21164"
  .PD
! Schedules as an \s-1EV5\s0 and has no instruction set extensions.
! .IP "\fBev56\fR" 4
  .IX Item "ev56"
  .PD 0
! .IP "\fB21164a\fR" 4
  .IX Item "21164a"
  .PD
! Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 extension.
! .IP "\fBpca56\fR" 4
  .IX Item "pca56"
  .PD 0
! .IP "\fB21164pc\fR" 4
  .IX Item "21164pc"
! .IP "\fB21164PC\fR" 4
  .IX Item "21164PC"
  .PD
! Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 and \s-1MAX\s0 extensions.
! .IP "\fBev6\fR" 4
  .IX Item "ev6"
  .PD 0
! .IP "\fB21264\fR" 4
  .IX Item "21264"
  .PD
! Schedules as an \s-1EV6\s0 and supports the \s-1BWX, FIX,\s0 and \s-1MAX\s0 extensions.
! .IP "\fBev67\fR" 4
  .IX Item "ev67"
  .PD 0
! .IP "\fB21264a\fR" 4
  .IX Item "21264a"
  .PD
! Schedules as an \s-1EV6\s0 and supports the \s-1BWX, CIX, FIX,\s0 and \s-1MAX\s0 extensions.
  .RE
  .RS 4
  .Sp
  Native toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize
  the processor.
  .RE
! .IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
  .IX Item "-mtune=cpu_type"
  Set only the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR.  The instruction set is not changed.
  .Sp
  Native toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mtune=native\fR has no effect if \s-1GCC\s0 does not recognize
  the processor.
! .IP "\fB\-mmemory\-latency=\fR\fItime\fR" 4
  .IX Item "-mmemory-latency=time"
  Sets the latency the scheduler should assume for typical memory
  references as seen by the application.  This number is highly
--- 23771,23852 ----
  required for a function call from 4 to 1.
  .Sp
  The default is \fB\-mlarge\-text\fR.
! .IP \fB\-mcpu=\fR\fIcpu_type\fR 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set and instruction scheduling parameters for
! machine type \fIcpu_type\fR.  You can specify either the \fBEV\fR
! style name or the corresponding chip number.  GCC supports scheduling
! parameters for the EV4, EV5 and EV6 family of processors and
  chooses the default values for the instruction set from the processor
! you specify.  If you do not specify a processor type, GCC defaults
  to the processor on which the compiler was built.
  .Sp
  Supported values for \fIcpu_type\fR are
  .RS 4
! .IP \fBev4\fR 4
  .IX Item "ev4"
  .PD 0
! .IP \fBev45\fR 4
  .IX Item "ev45"
! .IP \fB21064\fR 4
  .IX Item "21064"
  .PD
! Schedules as an EV4 and has no instruction set extensions.
! .IP \fBev5\fR 4
  .IX Item "ev5"
  .PD 0
! .IP \fB21164\fR 4
  .IX Item "21164"
  .PD
! Schedules as an EV5 and has no instruction set extensions.
! .IP \fBev56\fR 4
  .IX Item "ev56"
  .PD 0
! .IP \fB21164a\fR 4
  .IX Item "21164a"
  .PD
! Schedules as an EV5 and supports the BWX extension.
! .IP \fBpca56\fR 4
  .IX Item "pca56"
  .PD 0
! .IP \fB21164pc\fR 4
  .IX Item "21164pc"
! .IP \fB21164PC\fR 4
  .IX Item "21164PC"
  .PD
! Schedules as an EV5 and supports the BWX and MAX extensions.
! .IP \fBev6\fR 4
  .IX Item "ev6"
  .PD 0
! .IP \fB21264\fR 4
  .IX Item "21264"
  .PD
! Schedules as an EV6 and supports the BWX, FIX, and MAX extensions.
! .IP \fBev67\fR 4
  .IX Item "ev67"
  .PD 0
! .IP \fB21264a\fR 4
  .IX Item "21264a"
  .PD
! Schedules as an EV6 and supports the BWX, CIX, FIX, and MAX extensions.
  .RE
  .RS 4
  .Sp
  Native toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mcpu=native\fR has no effect if GCC does not recognize
  the processor.
  .RE
! .IP \fB\-mtune=\fR\fIcpu_type\fR 4
  .IX Item "-mtune=cpu_type"
  Set only the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR.  The instruction set is not changed.
  .Sp
  Native toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mtune=native\fR has no effect if GCC does not recognize
  the processor.
! .IP \fB\-mmemory\-latency=\fR\fItime\fR 4
  .IX Item "-mmemory-latency=time"
  Sets the latency the scheduler should assume for typical memory
  references as seen by the application.  This number is highly
*************** and the size of the external cache on th
*** 23924,23962 ****
  .Sp
  Valid options for \fItime\fR are
  .RS 4
! .IP "\fInumber\fR" 4
  .IX Item "number"
  A decimal number representing clock cycles.
! .IP "\fBL1\fR" 4
  .IX Item "L1"
  .PD 0
! .IP "\fBL2\fR" 4
  .IX Item "L2"
! .IP "\fBL3\fR" 4
  .IX Item "L3"
! .IP "\fBmain\fR" 4
  .IX Item "main"
  .PD
  The compiler contains estimates of the number of clock cycles for
! \&\*(L"typical\*(R" \s-1EV4 & EV5\s0 hardware for the Level 1, 2 & 3 caches
  (also called Dcache, Scache, and Bcache), as well as to main memory.
! Note that L3 is only valid for \s-1EV5.\s0
  .RE
  .RS 4
  .RE
  .PP
  \fIeBPF Options\fR
  .IX Subsection "eBPF Options"
! .IP "\fB\-mframe\-limit=\fR\fIbytes\fR" 4
  .IX Item "-mframe-limit=bytes"
  This specifies the hard limit for frame sizes, in bytes.  Currently,
  the value that can be specified should be less than or equal to
  \&\fB32767\fR.  Defaults to whatever limit is imposed by the version of
  the Linux kernel targeted.
! .IP "\fB\-mkernel=\fR\fIversion\fR" 4
  .IX Item "-mkernel=version"
  This specifies the minimum version of the kernel that will run the
! compiled program.  \s-1GCC\s0 uses this version to determine which
  instructions to use, what kernel helpers to allow, etc.  Currently,
  \&\fIversion\fR can be one of \fB4.0\fR, \fB4.1\fR, \fB4.2\fR,
  \&\fB4.3\fR, \fB4.4\fR, \fB4.5\fR, \fB4.6\fR, \fB4.7\fR,
--- 23855,23893 ----
  .Sp
  Valid options for \fItime\fR are
  .RS 4
! .IP \fInumber\fR 4
  .IX Item "number"
  A decimal number representing clock cycles.
! .IP \fBL1\fR 4
  .IX Item "L1"
  .PD 0
! .IP \fBL2\fR 4
  .IX Item "L2"
! .IP \fBL3\fR 4
  .IX Item "L3"
! .IP \fBmain\fR 4
  .IX Item "main"
  .PD
  The compiler contains estimates of the number of clock cycles for
! "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.
  .RE
  .RS 4
  .RE
  .PP
  \fIeBPF Options\fR
  .IX Subsection "eBPF Options"
! .IP \fB\-mframe\-limit=\fR\fIbytes\fR 4
  .IX Item "-mframe-limit=bytes"
  This specifies the hard limit for frame sizes, in bytes.  Currently,
  the value that can be specified should be less than or equal to
  \&\fB32767\fR.  Defaults to whatever limit is imposed by the version of
  the Linux kernel targeted.
! .IP \fB\-mkernel=\fR\fIversion\fR 4
  .IX Item "-mkernel=version"
  This specifies the minimum version of the kernel that will run the
! compiled program.  GCC uses this version to determine which
  instructions to use, what kernel helpers to allow, etc.  Currently,
  \&\fIversion\fR can be one of \fB4.0\fR, \fB4.1\fR, \fB4.2\fR,
  \&\fB4.3\fR, \fB4.4\fR, \fB4.5\fR, \fB4.6\fR, \fB4.7\fR,
*************** instructions to use, what kernel helpers
*** 23964,24287 ****
  \&\fB4.13\fR, \fB4.14\fR, \fB4.15\fR, \fB4.16\fR, \fB4.17\fR,
  \&\fB4.18\fR, \fB4.19\fR, \fB4.20\fR, \fB5.0\fR, \fB5.1\fR,
  \&\fB5.2\fR, \fBlatest\fR and \fBnative\fR.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code for a big-endian target.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code for a little-endian target.  This is the default.
! .IP "\fB\-mjmpext\fR" 4
  .IX Item "-mjmpext"
! Enable generation of extra conditional-branch instructions.
! Enabled for \s-1CPU\s0 v2 and above.
! .IP "\fB\-mjmp32\fR" 4
  .IX Item "-mjmp32"
! Enable 32\-bit jump instructions. Enabled for \s-1CPU\s0 v3 and above.
! .IP "\fB\-malu32\fR" 4
  .IX Item "-malu32"
! Enable 32\-bit \s-1ALU\s0 instructions. Enabled for \s-1CPU\s0 v3 and above.
! .IP "\fB\-mcpu=\fR\fIversion\fR" 4
  .IX Item "-mcpu=version"
! This specifies which version of the eBPF \s-1ISA\s0 to target. Newer versions
  may not be supported by all kernels. The default is \fBv3\fR.
  .Sp
  Supported values for \fIversion\fR are:
  .RS 4
! .IP "\fBv1\fR" 4
  .IX Item "v1"
! The first stable eBPF \s-1ISA\s0 with no special features or extensions.
! .IP "\fBv2\fR" 4
  .IX Item "v2"
  Supports the jump extensions, as in \fB\-mjmpext\fR.
! .IP "\fBv3\fR" 4
  .IX Item "v3"
  All features of v2, plus:
  .RS 4
  .IP "\-<32\-bit jump operations, as in \fB\-mjmp32\fR>" 4
  .IX Item "-<32-bit jump operations, as in -mjmp32>"
  .PD 0
! .IP "\-<32\-bit \s-1ALU\s0 operations, as in \fB\-malu32\fR>" 4
  .IX Item "-<32-bit ALU operations, as in -malu32>"
  .RE
  .RS 4
  .RE
  .RE
  .RS 4
  .RE
! .IP "\fB\-mco\-re\fR" 4
  .IX Item "-mco-re"
! .PD
! Enable \s-1BPF\s0 Compile Once \- Run Everywhere (CO-RE) support. Requires and
  is implied by \fB\-gbtf\fR.
! .IP "\fB\-mno\-co\-re\fR" 4
  .IX Item "-mno-co-re"
! Disable \s-1BPF\s0 Compile Once \- Run Everywhere (CO-RE) support. \s-1BPF\s0 CO-RE
! support is enabled by default when generating \s-1BTF\s0 debug information for
! the \s-1BPF\s0 target.
! .IP "\fB\-mxbpf\fR" 4
  .IX Item "-mxbpf"
! Generate code for an expanded version of \s-1BPF,\s0 which relaxes some of
! the restrictions imposed by the \s-1BPF\s0 architecture:
  .RS 4
! .IP "\-" 4
  .IX Item "-"
  exit, respectively.
  .RE
  .RS 4
  .RE
  .PP
! \fI\s-1FR30\s0 Options\fR
  .IX Subsection "FR30 Options"
  .PP
! These options are defined specifically for the \s-1FR30\s0 port.
! .IP "\fB\-msmall\-model\fR" 4
  .IX Item "-msmall-model"
  Use the small address space model.  This can produce smaller code, but
  it does assume that all symbolic values and addresses fit into a
  20\-bit range.
! .IP "\fB\-mno\-lsim\fR" 4
  .IX Item "-mno-lsim"
  Assume that runtime support has been provided and so there is no need
  to include the simulator library (\fIlibsim.a\fR) on the linker
  command line.
  .PP
! \fI\s-1FT32\s0 Options\fR
  .IX Subsection "FT32 Options"
  .PP
! These options are defined specifically for the \s-1FT32\s0 port.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
  an alternate runtime startup and library to be linked.
  You must not use this option when generating programs that will run on
  real hardware; you must provide your own runtime library for whatever
  I/O functions are needed.
! .IP "\fB\-mlra\fR" 4
  .IX Item "-mlra"
! Enable Local Register Allocation.  This is still experimental for \s-1FT32,\s0
  so by default the compiler uses standard reload.
! .IP "\fB\-mnodiv\fR" 4
  .IX Item "-mnodiv"
  Do not use div and mod instructions.
! .IP "\fB\-mft32b\fR" 4
  .IX Item "-mft32b"
! Enable use of the extended instructions of the \s-1FT32B\s0 processor.
! .IP "\fB\-mcompress\fR" 4
  .IX Item "-mcompress"
  Compress all code using the Ft32B code compression scheme.
! .IP "\fB\-mnopm\fR" 4
  .IX Item "-mnopm"
  Do not generate code that reads program memory.
  .PP
! \fI\s-1FRV\s0 Options\fR
  .IX Subsection "FRV Options"
! .IP "\fB\-mgpr\-32\fR" 4
  .IX Item "-mgpr-32"
! Only use the first 32 general-purpose registers.
! .IP "\fB\-mgpr\-64\fR" 4
  .IX Item "-mgpr-64"
! Use all 64 general-purpose registers.
! .IP "\fB\-mfpr\-32\fR" 4
  .IX Item "-mfpr-32"
! Use only the first 32 floating-point registers.
! .IP "\fB\-mfpr\-64\fR" 4
  .IX Item "-mfpr-64"
! Use all 64 floating-point registers.
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
! Use hardware instructions for floating-point operations.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
! Use library routines for floating-point operations.
! .IP "\fB\-malloc\-cc\fR" 4
  .IX Item "-malloc-cc"
  Dynamically allocate condition code registers.
! .IP "\fB\-mfixed\-cc\fR" 4
  .IX Item "-mfixed-cc"
  Do not try to dynamically allocate condition code registers, only
  use \f(CW\*(C`icc0\*(C'\fR and \f(CW\*(C`fcc0\*(C'\fR.
! .IP "\fB\-mdword\fR" 4
  .IX Item "-mdword"
! Change \s-1ABI\s0 to use double word insns.
! .IP "\fB\-mno\-dword\fR" 4
  .IX Item "-mno-dword"
  Do not use double word instructions.
! .IP "\fB\-mdouble\fR" 4
  .IX Item "-mdouble"
! Use floating-point double instructions.
! .IP "\fB\-mno\-double\fR" 4
  .IX Item "-mno-double"
! Do not use floating-point double instructions.
! .IP "\fB\-mmedia\fR" 4
  .IX Item "-mmedia"
  Use media instructions.
! .IP "\fB\-mno\-media\fR" 4
  .IX Item "-mno-media"
  Do not use media instructions.
! .IP "\fB\-mmuladd\fR" 4
  .IX Item "-mmuladd"
  Use multiply and add/subtract instructions.
! .IP "\fB\-mno\-muladd\fR" 4
  .IX Item "-mno-muladd"
  Do not use multiply and add/subtract instructions.
! .IP "\fB\-mfdpic\fR" 4
  .IX Item "-mfdpic"
! Select the \s-1FDPIC ABI,\s0 which uses function descriptors to represent
  pointers to functions.  Without any PIC/PIE\-related options, it
  implies \fB\-fPIE\fR.  With \fB\-fpic\fR or \fB\-fpie\fR, it
! assumes \s-1GOT\s0 entries and small data are within a 12\-bit range from the
! \&\s-1GOT\s0 base address; with \fB\-fPIC\fR or \fB\-fPIE\fR, \s-1GOT\s0 offsets
  are computed with 32 bits.
! With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
! .IP "\fB\-minline\-plt\fR" 4
  .IX Item "-minline-plt"
! Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
  not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
! It's enabled by default if optimizing for speed and compiling for
  shared libraries (i.e., \fB\-fPIC\fR or \fB\-fpic\fR), or when an
  optimization option such as \fB\-O3\fR or above is present in the
  command line.
! .IP "\fB\-mTLS\fR" 4
  .IX Item "-mTLS"
! Assume a large \s-1TLS\s0 segment when generating thread-local code.
! .IP "\fB\-mtls\fR" 4
  .IX Item "-mtls"
! Do not assume a large \s-1TLS\s0 segment when generating thread-local code.
! .IP "\fB\-mgprel\-ro\fR" 4
  .IX Item "-mgprel-ro"
! Enable the use of \f(CW\*(C`GPREL\*(C'\fR relocations in the \s-1FDPIC ABI\s0 for data
! that is known to be in read-only sections.  It's enabled by default,
  except for \fB\-fpic\fR or \fB\-fpie\fR: even though it may help
  make the global offset table smaller, it trades 1 instruction for 4.
  With \fB\-fPIC\fR or \fB\-fPIE\fR, it trades 3 instructions for 4,
  one of which may be shared by multiple symbols, and it avoids the need
! for a \s-1GOT\s0 entry for the referenced symbol, so it's more likely to be a
  win.  If it is not, \fB\-mno\-gprel\-ro\fR can be used to disable it.
! .IP "\fB\-multilib\-library\-pic\fR" 4
  .IX Item "-multilib-library-pic"
! Link with the (library, not \s-1FD\s0) pic libraries.  It's implied by
  \&\fB\-mlibrary\-pic\fR, as well as by \fB\-fPIC\fR and
  \&\fB\-fpic\fR without \fB\-mfdpic\fR.  You should never have to use
  it explicitly.
! .IP "\fB\-mlinked\-fp\fR" 4
  .IX Item "-mlinked-fp"
! Follow the \s-1EABI\s0 requirement of always creating a frame pointer whenever
  a stack frame is allocated.  This option is enabled by default and can
  be disabled with \fB\-mno\-linked\-fp\fR.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  Use indirect addressing to call functions outside the current
  compilation unit.  This allows the functions to be placed anywhere
  within the 32\-bit address space.
! .IP "\fB\-malign\-labels\fR" 4
  .IX Item "-malign-labels"
  Try to align labels to an 8\-byte boundary by inserting NOPs into the
! previous packet.  This option only has an effect when \s-1VLIW\s0 packing
! is enabled.  It doesn't create new packets; it merely adds NOPs to
  existing ones.
! .IP "\fB\-mlibrary\-pic\fR" 4
  .IX Item "-mlibrary-pic"
! Generate position-independent \s-1EABI\s0 code.
! .IP "\fB\-macc\-4\fR" 4
  .IX Item "-macc-4"
  Use only the first four media accumulator registers.
! .IP "\fB\-macc\-8\fR" 4
  .IX Item "-macc-8"
  Use all eight media accumulator registers.
! .IP "\fB\-mpack\fR" 4
  .IX Item "-mpack"
! Pack \s-1VLIW\s0 instructions.
! .IP "\fB\-mno\-pack\fR" 4
  .IX Item "-mno-pack"
! Do not pack \s-1VLIW\s0 instructions.
! .IP "\fB\-mno\-eflags\fR" 4
  .IX Item "-mno-eflags"
! Do not mark \s-1ABI\s0 switches in e_flags.
! .IP "\fB\-mcond\-move\fR" 4
  .IX Item "-mcond-move"
! Enable the use of conditional-move instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-cond\-move\fR" 4
  .IX Item "-mno-cond-move"
! Disable the use of conditional-move instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mscc\fR" 4
  .IX Item "-mscc"
  Enable the use of conditional set instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-scc\fR" 4
  .IX Item "-mno-scc"
  Disable the use of conditional set instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mcond\-exec\fR" 4
  .IX Item "-mcond-exec"
  Enable the use of conditional execution (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-cond\-exec\fR" 4
  .IX Item "-mno-cond-exec"
  Disable the use of conditional execution.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mvliw\-branch\fR" 4
  .IX Item "-mvliw-branch"
! Run a pass to pack branches into \s-1VLIW\s0 instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-vliw\-branch\fR" 4
  .IX Item "-mno-vliw-branch"
! Do not run a pass to pack branches into \s-1VLIW\s0 instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mmulti\-cond\-exec\fR" 4
  .IX Item "-mmulti-cond-exec"
  Enable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution
  (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-multi\-cond\-exec\fR" 4
  .IX Item "-mno-multi-cond-exec"
  Disable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mnested\-cond\-exec\fR" 4
  .IX Item "-mnested-cond-exec"
  Enable nested conditional execution optimizations (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-mno\-nested\-cond\-exec\fR" 4
  .IX Item "-mno-nested-cond-exec"
  Disable nested conditional execution optimizations.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP "\fB\-moptimize\-membar\fR" 4
  .IX Item "-moptimize-membar"
  This switch removes redundant \f(CW\*(C`membar\*(C'\fR instructions from the
! compiler-generated code.  It is enabled by default.
! .IP "\fB\-mno\-optimize\-membar\fR" 4
  .IX Item "-mno-optimize-membar"
  This switch disables the automatic removal of redundant \f(CW\*(C`membar\*(C'\fR
  instructions from the generated code.
! .IP "\fB\-mtomcat\-stats\fR" 4
  .IX Item "-mtomcat-stats"
  Cause gas to print out tomcat statistics.
! .IP "\fB\-mcpu=\fR\fIcpu\fR" 4
  .IX Item "-mcpu=cpu"
  Select the processor type for which to generate code.  Possible values are
  \&\fBfrv\fR, \fBfr550\fR, \fBtomcat\fR, \fBfr500\fR, \fBfr450\fR,
--- 23895,24218 ----
  \&\fB4.13\fR, \fB4.14\fR, \fB4.15\fR, \fB4.16\fR, \fB4.17\fR,
  \&\fB4.18\fR, \fB4.19\fR, \fB4.20\fR, \fB5.0\fR, \fB5.1\fR,
  \&\fB5.2\fR, \fBlatest\fR and \fBnative\fR.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code for a big\-endian target.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code for a little\-endian target.  This is the default.
! .IP \fB\-mjmpext\fR 4
  .IX Item "-mjmpext"
! Enable generation of extra conditional\-branch instructions.
! Enabled for CPU v2 and above.
! .IP \fB\-mjmp32\fR 4
  .IX Item "-mjmp32"
! Enable 32\-bit jump instructions. Enabled for CPU v3 and above.
! .IP \fB\-malu32\fR 4
  .IX Item "-malu32"
! Enable 32\-bit ALU instructions. Enabled for CPU v3 and above.
! .IP \fB\-mcpu=\fR\fIversion\fR 4
  .IX Item "-mcpu=version"
! This specifies which version of the eBPF ISA to target. Newer versions
  may not be supported by all kernels. The default is \fBv3\fR.
  .Sp
  Supported values for \fIversion\fR are:
  .RS 4
! .IP \fBv1\fR 4
  .IX Item "v1"
! The first stable eBPF ISA with no special features or extensions.
! .IP \fBv2\fR 4
  .IX Item "v2"
  Supports the jump extensions, as in \fB\-mjmpext\fR.
! .IP \fBv3\fR 4
  .IX Item "v3"
  All features of v2, plus:
  .RS 4
  .IP "\-<32\-bit jump operations, as in \fB\-mjmp32\fR>" 4
  .IX Item "-<32-bit jump operations, as in -mjmp32>"
  .PD 0
! .IP "\-<32\-bit ALU operations, as in \fB\-malu32\fR>" 4
  .IX Item "-<32-bit ALU operations, as in -malu32>"
+ .PD
  .RE
  .RS 4
  .RE
  .RE
  .RS 4
  .RE
! .IP \fB\-mco\-re\fR 4
  .IX Item "-mco-re"
! Enable BPF Compile Once \- Run Everywhere (CO\-RE) support. Requires and
  is implied by \fB\-gbtf\fR.
! .IP \fB\-mno\-co\-re\fR 4
  .IX Item "-mno-co-re"
! Disable BPF Compile Once \- Run Everywhere (CO\-RE) support. BPF CO\-RE
! support is enabled by default when generating BTF debug information for
! the BPF target.
! .IP \fB\-mxbpf\fR 4
  .IX Item "-mxbpf"
! Generate code for an expanded version of BPF, which relaxes some of
! the restrictions imposed by the BPF architecture:
  .RS 4
! .IP "\-" 4
  .IX Item "-"
  exit, respectively.
  .RE
  .RS 4
  .RE
  .PP
! \fIFR30 Options\fR
  .IX Subsection "FR30 Options"
  .PP
! These options are defined specifically for the FR30 port.
! .IP \fB\-msmall\-model\fR 4
  .IX Item "-msmall-model"
  Use the small address space model.  This can produce smaller code, but
  it does assume that all symbolic values and addresses fit into a
  20\-bit range.
! .IP \fB\-mno\-lsim\fR 4
  .IX Item "-mno-lsim"
  Assume that runtime support has been provided and so there is no need
  to include the simulator library (\fIlibsim.a\fR) on the linker
  command line.
  .PP
! \fIFT32 Options\fR
  .IX Subsection "FT32 Options"
  .PP
! These options are defined specifically for the FT32 port.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
  an alternate runtime startup and library to be linked.
  You must not use this option when generating programs that will run on
  real hardware; you must provide your own runtime library for whatever
  I/O functions are needed.
! .IP \fB\-mlra\fR 4
  .IX Item "-mlra"
! Enable Local Register Allocation.  This is still experimental for FT32,
  so by default the compiler uses standard reload.
! .IP \fB\-mnodiv\fR 4
  .IX Item "-mnodiv"
  Do not use div and mod instructions.
! .IP \fB\-mft32b\fR 4
  .IX Item "-mft32b"
! Enable use of the extended instructions of the FT32B processor.
! .IP \fB\-mcompress\fR 4
  .IX Item "-mcompress"
  Compress all code using the Ft32B code compression scheme.
! .IP \fB\-mnopm\fR 4
  .IX Item "-mnopm"
  Do not generate code that reads program memory.
  .PP
! \fIFRV Options\fR
  .IX Subsection "FRV Options"
! .IP \fB\-mgpr\-32\fR 4
  .IX Item "-mgpr-32"
! Only use the first 32 general\-purpose registers.
! .IP \fB\-mgpr\-64\fR 4
  .IX Item "-mgpr-64"
! Use all 64 general\-purpose registers.
! .IP \fB\-mfpr\-32\fR 4
  .IX Item "-mfpr-32"
! Use only the first 32 floating\-point registers.
! .IP \fB\-mfpr\-64\fR 4
  .IX Item "-mfpr-64"
! Use all 64 floating\-point registers.
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
! Use hardware instructions for floating\-point operations.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
! Use library routines for floating\-point operations.
! .IP \fB\-malloc\-cc\fR 4
  .IX Item "-malloc-cc"
  Dynamically allocate condition code registers.
! .IP \fB\-mfixed\-cc\fR 4
  .IX Item "-mfixed-cc"
  Do not try to dynamically allocate condition code registers, only
  use \f(CW\*(C`icc0\*(C'\fR and \f(CW\*(C`fcc0\*(C'\fR.
! .IP \fB\-mdword\fR 4
  .IX Item "-mdword"
! Change ABI to use double word insns.
! .IP \fB\-mno\-dword\fR 4
  .IX Item "-mno-dword"
  Do not use double word instructions.
! .IP \fB\-mdouble\fR 4
  .IX Item "-mdouble"
! Use floating\-point double instructions.
! .IP \fB\-mno\-double\fR 4
  .IX Item "-mno-double"
! Do not use floating\-point double instructions.
! .IP \fB\-mmedia\fR 4
  .IX Item "-mmedia"
  Use media instructions.
! .IP \fB\-mno\-media\fR 4
  .IX Item "-mno-media"
  Do not use media instructions.
! .IP \fB\-mmuladd\fR 4
  .IX Item "-mmuladd"
  Use multiply and add/subtract instructions.
! .IP \fB\-mno\-muladd\fR 4
  .IX Item "-mno-muladd"
  Do not use multiply and add/subtract instructions.
! .IP \fB\-mfdpic\fR 4
  .IX Item "-mfdpic"
! Select the FDPIC ABI, which uses function descriptors to represent
  pointers to functions.  Without any PIC/PIE\-related options, it
  implies \fB\-fPIE\fR.  With \fB\-fpic\fR or \fB\-fpie\fR, it
! assumes GOT entries and small data are within a 12\-bit range from the
! GOT base address; with \fB\-fPIC\fR or \fB\-fPIE\fR, GOT offsets
  are computed with 32 bits.
! With a \fBbfin\-elf\fR target, this option implies \fB\-msim\fR.
! .IP \fB\-minline\-plt\fR 4
  .IX Item "-minline-plt"
! Enable inlining of PLT entries in function calls to functions that are
  not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
! It\*(Aqs enabled by default if optimizing for speed and compiling for
  shared libraries (i.e., \fB\-fPIC\fR or \fB\-fpic\fR), or when an
  optimization option such as \fB\-O3\fR or above is present in the
  command line.
! .IP \fB\-mTLS\fR 4
  .IX Item "-mTLS"
! Assume a large TLS segment when generating thread\-local code.
! .IP \fB\-mtls\fR 4
  .IX Item "-mtls"
! Do not assume a large TLS segment when generating thread\-local code.
! .IP \fB\-mgprel\-ro\fR 4
  .IX Item "-mgprel-ro"
! Enable the use of \f(CW\*(C`GPREL\*(C'\fR relocations in the FDPIC ABI for data
! that is known to be in read\-only sections.  It\*(Aqs enabled by default,
  except for \fB\-fpic\fR or \fB\-fpie\fR: even though it may help
  make the global offset table smaller, it trades 1 instruction for 4.
  With \fB\-fPIC\fR or \fB\-fPIE\fR, it trades 3 instructions for 4,
  one of which may be shared by multiple symbols, and it avoids the need
! for a GOT entry for the referenced symbol, so it\*(Aqs more likely to be a
  win.  If it is not, \fB\-mno\-gprel\-ro\fR can be used to disable it.
! .IP \fB\-multilib\-library\-pic\fR 4
  .IX Item "-multilib-library-pic"
! Link with the (library, not FD) pic libraries.  It\*(Aqs implied by
  \&\fB\-mlibrary\-pic\fR, as well as by \fB\-fPIC\fR and
  \&\fB\-fpic\fR without \fB\-mfdpic\fR.  You should never have to use
  it explicitly.
! .IP \fB\-mlinked\-fp\fR 4
  .IX Item "-mlinked-fp"
! Follow the 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 \fB\-mno\-linked\-fp\fR.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  Use indirect addressing to call functions outside the current
  compilation unit.  This allows the functions to be placed anywhere
  within the 32\-bit address space.
! .IP \fB\-malign\-labels\fR 4
  .IX Item "-malign-labels"
  Try to align labels to an 8\-byte boundary by inserting NOPs into the
! previous packet.  This option only has an effect when VLIW packing
! is enabled.  It doesn\*(Aqt create new packets; it merely adds NOPs to
  existing ones.
! .IP \fB\-mlibrary\-pic\fR 4
  .IX Item "-mlibrary-pic"
! Generate position\-independent EABI code.
! .IP \fB\-macc\-4\fR 4
  .IX Item "-macc-4"
  Use only the first four media accumulator registers.
! .IP \fB\-macc\-8\fR 4
  .IX Item "-macc-8"
  Use all eight media accumulator registers.
! .IP \fB\-mpack\fR 4
  .IX Item "-mpack"
! Pack VLIW instructions.
! .IP \fB\-mno\-pack\fR 4
  .IX Item "-mno-pack"
! Do not pack VLIW instructions.
! .IP \fB\-mno\-eflags\fR 4
  .IX Item "-mno-eflags"
! Do not mark ABI switches in e_flags.
! .IP \fB\-mcond\-move\fR 4
  .IX Item "-mcond-move"
! Enable the use of conditional\-move instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-cond\-move\fR 4
  .IX Item "-mno-cond-move"
! Disable the use of conditional\-move instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mscc\fR 4
  .IX Item "-mscc"
  Enable the use of conditional set instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-scc\fR 4
  .IX Item "-mno-scc"
  Disable the use of conditional set instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mcond\-exec\fR 4
  .IX Item "-mcond-exec"
  Enable the use of conditional execution (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-cond\-exec\fR 4
  .IX Item "-mno-cond-exec"
  Disable the use of conditional execution.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mvliw\-branch\fR 4
  .IX Item "-mvliw-branch"
! Run a pass to pack branches into VLIW instructions (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-vliw\-branch\fR 4
  .IX Item "-mno-vliw-branch"
! Do not run a pass to pack branches into VLIW instructions.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mmulti\-cond\-exec\fR 4
  .IX Item "-mmulti-cond-exec"
  Enable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution
  (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-multi\-cond\-exec\fR 4
  .IX Item "-mno-multi-cond-exec"
  Disable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mnested\-cond\-exec\fR 4
  .IX Item "-mnested-cond-exec"
  Enable nested conditional execution optimizations (default).
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-mno\-nested\-cond\-exec\fR 4
  .IX Item "-mno-nested-cond-exec"
  Disable nested conditional execution optimizations.
  .Sp
  This switch is mainly for debugging the compiler and will likely be removed
  in a future version.
! .IP \fB\-moptimize\-membar\fR 4
  .IX Item "-moptimize-membar"
  This switch removes redundant \f(CW\*(C`membar\*(C'\fR instructions from the
! compiler\-generated code.  It is enabled by default.
! .IP \fB\-mno\-optimize\-membar\fR 4
  .IX Item "-mno-optimize-membar"
  This switch disables the automatic removal of redundant \f(CW\*(C`membar\*(C'\fR
  instructions from the generated code.
! .IP \fB\-mtomcat\-stats\fR 4
  .IX Item "-mtomcat-stats"
  Cause gas to print out tomcat statistics.
! .IP \fB\-mcpu=\fR\fIcpu\fR 4
  .IX Item "-mcpu=cpu"
  Select the processor type for which to generate code.  Possible values are
  \&\fBfrv\fR, \fBfr550\fR, \fBtomcat\fR, \fBfr500\fR, \fBfr450\fR,
*************** Select the processor type for which to g
*** 24291,24329 ****
  .IX Subsection "GNU/Linux Options"
  .PP
  These \fB\-m\fR options are defined for GNU/Linux targets:
! .IP "\fB\-mglibc\fR" 4
  .IX Item "-mglibc"
! Use the \s-1GNU C\s0 library.  This is the default except
  on \fB*\-*\-linux\-*uclibc*\fR, \fB*\-*\-linux\-*musl*\fR and
  \&\fB*\-*\-linux\-*android*\fR targets.
! .IP "\fB\-muclibc\fR" 4
  .IX Item "-muclibc"
  Use uClibc C library.  This is the default on
  \&\fB*\-*\-linux\-*uclibc*\fR targets.
! .IP "\fB\-mmusl\fR" 4
  .IX Item "-mmusl"
  Use the musl C library.  This is the default on
  \&\fB*\-*\-linux\-*musl*\fR targets.
! .IP "\fB\-mbionic\fR" 4
  .IX Item "-mbionic"
  Use Bionic C library.  This is the default on
  \&\fB*\-*\-linux\-*android*\fR targets.
! .IP "\fB\-mandroid\fR" 4
  .IX Item "-mandroid"
  Compile code compatible with Android platform.  This is the default on
  \&\fB*\-*\-linux\-*android*\fR targets.
  .Sp
  When compiling, this option enables \fB\-mbionic\fR, \fB\-fPIC\fR,
  \&\fB\-fno\-exceptions\fR and \fB\-fno\-rtti\fR by default.  When linking,
! this option makes the \s-1GCC\s0 driver pass Android-specific options to the linker.
  Finally, this option causes the preprocessor macro \f(CW\*(C`_\|_ANDROID_\|_\*(C'\fR
  to be defined.
! .IP "\fB\-tno\-android\-cc\fR" 4
  .IX Item "-tno-android-cc"
  Disable compilation effects of \fB\-mandroid\fR, i.e., do not enable
  \&\fB\-mbionic\fR, \fB\-fPIC\fR, \fB\-fno\-exceptions\fR and
  \&\fB\-fno\-rtti\fR by default.
! .IP "\fB\-tno\-android\-ld\fR" 4
  .IX Item "-tno-android-ld"
  Disable linking effects of \fB\-mandroid\fR, i.e., pass standard Linux
  linking options to the linker.
--- 24222,24260 ----
  .IX Subsection "GNU/Linux Options"
  .PP
  These \fB\-m\fR options are defined for GNU/Linux targets:
! .IP \fB\-mglibc\fR 4
  .IX Item "-mglibc"
! Use the GNU C library.  This is the default except
  on \fB*\-*\-linux\-*uclibc*\fR, \fB*\-*\-linux\-*musl*\fR and
  \&\fB*\-*\-linux\-*android*\fR targets.
! .IP \fB\-muclibc\fR 4
  .IX Item "-muclibc"
  Use uClibc C library.  This is the default on
  \&\fB*\-*\-linux\-*uclibc*\fR targets.
! .IP \fB\-mmusl\fR 4
  .IX Item "-mmusl"
  Use the musl C library.  This is the default on
  \&\fB*\-*\-linux\-*musl*\fR targets.
! .IP \fB\-mbionic\fR 4
  .IX Item "-mbionic"
  Use Bionic C library.  This is the default on
  \&\fB*\-*\-linux\-*android*\fR targets.
! .IP \fB\-mandroid\fR 4
  .IX Item "-mandroid"
  Compile code compatible with Android platform.  This is the default on
  \&\fB*\-*\-linux\-*android*\fR targets.
  .Sp
  When compiling, this option enables \fB\-mbionic\fR, \fB\-fPIC\fR,
  \&\fB\-fno\-exceptions\fR and \fB\-fno\-rtti\fR by default.  When linking,
! this option makes the GCC driver pass Android\-specific options to the linker.
  Finally, this option causes the preprocessor macro \f(CW\*(C`_\|_ANDROID_\|_\*(C'\fR
  to be defined.
! .IP \fB\-tno\-android\-cc\fR 4
  .IX Item "-tno-android-cc"
  Disable compilation effects of \fB\-mandroid\fR, i.e., do not enable
  \&\fB\-mbionic\fR, \fB\-fPIC\fR, \fB\-fno\-exceptions\fR and
  \&\fB\-fno\-rtti\fR by default.
! .IP \fB\-tno\-android\-ld\fR 4
  .IX Item "-tno-android-ld"
  Disable linking effects of \fB\-mandroid\fR, i.e., pass standard Linux
  linking options to the linker.
*************** linking options to the linker.
*** 24332,24368 ****
  .IX Subsection "H8/300 Options"
  .PP
  These \fB\-m\fR options are defined for the H8/300 implementations:
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Shorten some address references at link time, when possible; uses the
  linker option \fB\-relax\fR.
! .IP "\fB\-mh\fR" 4
  .IX Item "-mh"
  Generate code for the H8/300H.
! .IP "\fB\-ms\fR" 4
  .IX Item "-ms"
  Generate code for the H8S.
! .IP "\fB\-mn\fR" 4
  .IX Item "-mn"
  Generate code for the H8S and H8/300H in the normal mode.  This switch
  must be used either with \fB\-mh\fR or \fB\-ms\fR.
! .IP "\fB\-ms2600\fR" 4
  .IX Item "-ms2600"
  Generate code for the H8S/2600.  This switch must be used with \fB\-ms\fR.
! .IP "\fB\-mexr\fR" 4
  .IX Item "-mexr"
  Extended registers are stored on stack before execution of function
  with monitor attribute. Default option is \fB\-mexr\fR.
  This option is valid only for H8S targets.
! .IP "\fB\-mno\-exr\fR" 4
  .IX Item "-mno-exr"
  Extended registers are not stored on stack before execution of function 
  with monitor attribute. Default option is \fB\-mno\-exr\fR. 
  This option is valid only for H8S targets.
! .IP "\fB\-mint32\fR" 4
  .IX Item "-mint32"
  Make \f(CW\*(C`int\*(C'\fR data 32 bits by default.
! .IP "\fB\-malign\-300\fR" 4
  .IX Item "-malign-300"
  On the H8/300H and H8S, use the same alignment rules as for the H8/300.
  The default for the H8/300H and H8S is to align longs and floats on
--- 24263,24299 ----
  .IX Subsection "H8/300 Options"
  .PP
  These \fB\-m\fR options are defined for the H8/300 implementations:
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Shorten some address references at link time, when possible; uses the
  linker option \fB\-relax\fR.
! .IP \fB\-mh\fR 4
  .IX Item "-mh"
  Generate code for the H8/300H.
! .IP \fB\-ms\fR 4
  .IX Item "-ms"
  Generate code for the H8S.
! .IP \fB\-mn\fR 4
  .IX Item "-mn"
  Generate code for the H8S and H8/300H in the normal mode.  This switch
  must be used either with \fB\-mh\fR or \fB\-ms\fR.
! .IP \fB\-ms2600\fR 4
  .IX Item "-ms2600"
  Generate code for the H8S/2600.  This switch must be used with \fB\-ms\fR.
! .IP \fB\-mexr\fR 4
  .IX Item "-mexr"
  Extended registers are stored on stack before execution of function
  with monitor attribute. Default option is \fB\-mexr\fR.
  This option is valid only for H8S targets.
! .IP \fB\-mno\-exr\fR 4
  .IX Item "-mno-exr"
  Extended registers are not stored on stack before execution of function 
  with monitor attribute. Default option is \fB\-mno\-exr\fR. 
  This option is valid only for H8S targets.
! .IP \fB\-mint32\fR 4
  .IX Item "-mint32"
  Make \f(CW\*(C`int\*(C'\fR data 32 bits by default.
! .IP \fB\-malign\-300\fR 4
  .IX Item "-malign-300"
  On the H8/300H and H8S, use the same alignment rules as for the H8/300.
  The default for the H8/300H and H8S is to align longs and floats on
*************** The default for the H8/300H and H8S is t
*** 24370,24402 ****
  \&\fB\-malign\-300\fR causes them to be aligned on 2\-byte boundaries.
  This option has no effect on the H8/300.
  .PP
! \fI\s-1HPPA\s0 Options\fR
  .IX Subsection "HPPA Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1HPPA\s0 family of computers:
! .IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
  .IX Item "-march=architecture-type"
  Generate code for the specified architecture.  The choices for
! \&\fIarchitecture-type\fR are \fB1.0\fR for \s-1PA 1.0,\s0 \fB1.1\fR for \s-1PA
! 1.1,\s0 and \fB2.0\fR for \s-1PA 2.0\s0 processors.  Refer to
! \&\fI/usr/lib/sched.models\fR on an HP-UX system to determine the proper
  architecture option for your machine.  Code compiled for lower numbered
  architectures runs on higher numbered architectures, but not the
  other way around.
! .IP "\fB\-mpa\-risc\-1\-0\fR" 4
  .IX Item "-mpa-risc-1-0"
  .PD 0
! .IP "\fB\-mpa\-risc\-1\-1\fR" 4
  .IX Item "-mpa-risc-1-1"
! .IP "\fB\-mpa\-risc\-2\-0\fR" 4
  .IX Item "-mpa-risc-2-0"
  .PD
  Synonyms for \fB\-march=1.0\fR, \fB\-march=1.1\fR, and \fB\-march=2.0\fR respectively.
! .IP "\fB\-matomic\-libcalls\fR" 4
  .IX Item "-matomic-libcalls"
  Generate libcalls for atomic loads and stores when sync libcalls are disabled.
  This option is enabled by default.  It only affects the generation of
! atomic libcalls by the \s-1HPPA\s0 backend.
  .Sp
  Both the sync and \fIlibatomic\fR libcall implementations use locking.
  As a result, processor stores are not atomic with respect to other
--- 24301,24333 ----
  \&\fB\-malign\-300\fR causes them to be aligned on 2\-byte boundaries.
  This option has no effect on the H8/300.
  .PP
! \fIHPPA Options\fR
  .IX Subsection "HPPA Options"
  .PP
! These \fB\-m\fR options are defined for the HPPA family of computers:
! .IP \fB\-march=\fR\fIarchitecture\-type\fR 4
  .IX Item "-march=architecture-type"
  Generate code for the specified architecture.  The choices for
! \&\fIarchitecture\-type\fR are \fB1.0\fR for PA 1.0, \fB1.1\fR for PA
! 1.1, and \fB2.0\fR for PA 2.0 processors.  Refer to
! \&\fI/usr/lib/sched.models\fR on an HP\-UX system to determine the proper
  architecture option for your machine.  Code compiled for lower numbered
  architectures runs on higher numbered architectures, but not the
  other way around.
! .IP \fB\-mpa\-risc\-1\-0\fR 4
  .IX Item "-mpa-risc-1-0"
  .PD 0
! .IP \fB\-mpa\-risc\-1\-1\fR 4
  .IX Item "-mpa-risc-1-1"
! .IP \fB\-mpa\-risc\-2\-0\fR 4
  .IX Item "-mpa-risc-2-0"
  .PD
  Synonyms for \fB\-march=1.0\fR, \fB\-march=1.1\fR, and \fB\-march=2.0\fR respectively.
! .IP \fB\-matomic\-libcalls\fR 4
  .IX Item "-matomic-libcalls"
  Generate libcalls for atomic loads and stores when sync libcalls are disabled.
  This option is enabled by default.  It only affects the generation of
! atomic libcalls by the HPPA backend.
  .Sp
  Both the sync and \fIlibatomic\fR libcall implementations use locking.
  As a result, processor stores are not atomic with respect to other
*************** atomic operations.  Processor loads up t
*** 24404,24410 ****
  respect to other atomic operations provided they are implemented as
  a single access.
  .Sp
! The PA-RISC architecture does not support any atomic operations in
  hardware except for the \f(CW\*(C`ldcw\*(C'\fR instruction.  Thus, all atomic
  support is implemented using sync and atomic libcalls.  Sync libcall
  support is in \fIlibgcc.a\fR.  Atomic libcall support is in
--- 24335,24341 ----
  respect to other atomic operations provided they are implemented as
  a single access.
  .Sp
! The PA\-RISC architecture does not support any atomic operations in
  hardware except for the \f(CW\*(C`ldcw\*(C'\fR instruction.  Thus, all atomic
  support is implemented using sync and atomic libcalls.  Sync libcall
  support is in \fIlibgcc.a\fR.  Atomic libcall support is in
*************** support is in \fIlibgcc.a\fR.  Atomic li
*** 24413,24488 ****
  This option generates \f(CW\*(C`_\|_atomic_exchange\*(C'\fR calls for atomic stores.
  It also provides special handling for atomic DImode accesses on 32\-bit
  targets.
! .IP "\fB\-mbig\-switch\fR" 4
  .IX Item "-mbig-switch"
  Does nothing.  Preserved for backward compatibility.
! .IP "\fB\-mcaller\-copies\fR" 4
  .IX Item "-mcaller-copies"
  The caller copies function arguments passed by hidden reference.  This
  option should be used with care as it is not compatible with the default
  32\-bit runtime.  However, only aggregates larger than eight bytes are
  passed by hidden reference and the option provides better compatibility
  with OpenMP.
! .IP "\fB\-mcoherent\-ldcw\fR" 4
  .IX Item "-mcoherent-ldcw"
! Use ldcw/ldcd coherent cache-control hint.
! .IP "\fB\-mdisable\-fpregs\fR" 4
  .IX Item "-mdisable-fpregs"
! Disable floating-point registers.  Equivalent to \f(CW\*(C`\-msoft\-float\*(C'\fR.
! .IP "\fB\-mdisable\-indexing\fR" 4
  .IX Item "-mdisable-indexing"
  Prevent the compiler from using indexing address modes.  This avoids some
! rather obscure problems when compiling \s-1MIG\s0 generated code under \s-1MACH.\s0
! .IP "\fB\-mfast\-indirect\-calls\fR" 4
  .IX Item "-mfast-indirect-calls"
  Generate code that assumes calls never cross space boundaries.  This
! allows \s-1GCC\s0 to emit code that performs faster indirect calls.
  .Sp
  This option does not work in the presence of shared libraries or nested
  functions.
! .IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP "\fB\-mgas\fR" 4
  .IX Item "-mgas"
! Enable the use of assembler directives only \s-1GAS\s0 understands.
! .IP "\fB\-mgnu\-ld\fR" 4
  .IX Item "-mgnu-ld"
! Use options specific to \s-1GNU\s0 \fBld\fR.
  This passes \fB\-shared\fR to \fBld\fR when
! building a shared library.  It is the default when \s-1GCC\s0 is configured,
! explicitly or implicitly, with the \s-1GNU\s0 linker.  This option does not
  affect which \fBld\fR is called; it only changes what parameters
  are passed to that \fBld\fR.
  The \fBld\fR that is called is determined by the
! \&\fB\-\-with\-ld\fR configure option, \s-1GCC\s0's program search path, and
! finally by the user's \fB\s-1PATH\s0\fR.  The linker used by \s-1GCC\s0 can be printed
! using \fBwhich `gcc \-print\-prog\-name=ld`\fR.  This option is only available
! on the 64\-bit HP-UX \s-1GCC,\s0 i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
! .IP "\fB\-mhp\-ld\fR" 4
  .IX Item "-mhp-ld"
! Use options specific to \s-1HP\s0 \fBld\fR.
  This passes \fB\-b\fR to \fBld\fR when building
  a shared library and passes \fB+Accept TypeMismatch\fR to \fBld\fR on all
! links.  It is the default when \s-1GCC\s0 is configured, explicitly or
! implicitly, with the \s-1HP\s0 linker.  This option does not affect
  which \fBld\fR is called; it only changes what parameters are passed to that
  \&\fBld\fR.
  The \fBld\fR that is called is determined by the \fB\-\-with\-ld\fR
! configure option, \s-1GCC\s0's program search path, and finally by the user's
! \&\fB\s-1PATH\s0\fR.  The linker used by \s-1GCC\s0 can be printed using \fBwhich
! `gcc \-print\-prog\-name=ld`\fR.  This option is only available on the 64\-bit
! HP-UX \s-1GCC,\s0 i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
! .IP "\fB\-mlinker\-opt\fR" 4
  .IX Item "-mlinker-opt"
! Enable the optimization pass in the HP-UX linker.  Note this makes symbolic
! debugging impossible.  It also triggers a bug in the HP-UX 8 and HP-UX 9
  linkers in which they give bogus error messages when linking some programs.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  Generate code that uses long call sequences.  This ensures that a call
  is always able to reach linker generated stubs.  The default is to generate
--- 24344,24419 ----
  This option generates \f(CW\*(C`_\|_atomic_exchange\*(C'\fR calls for atomic stores.
  It also provides special handling for atomic DImode accesses on 32\-bit
  targets.
! .IP \fB\-mbig\-switch\fR 4
  .IX Item "-mbig-switch"
  Does nothing.  Preserved for backward compatibility.
! .IP \fB\-mcaller\-copies\fR 4
  .IX Item "-mcaller-copies"
  The caller copies function arguments passed by hidden reference.  This
  option should be used with care as it is not compatible with the default
  32\-bit runtime.  However, only aggregates larger than eight bytes are
  passed by hidden reference and the option provides better compatibility
  with OpenMP.
! .IP \fB\-mcoherent\-ldcw\fR 4
  .IX Item "-mcoherent-ldcw"
! Use ldcw/ldcd coherent cache\-control hint.
! .IP \fB\-mdisable\-fpregs\fR 4
  .IX Item "-mdisable-fpregs"
! Disable floating\-point registers.  Equivalent to \f(CW\*(C`\-msoft\-float\*(C'\fR.
! .IP \fB\-mdisable\-indexing\fR 4
  .IX Item "-mdisable-indexing"
  Prevent the compiler from using indexing address modes.  This avoids some
! rather obscure problems when compiling MIG generated code under MACH.
! .IP \fB\-mfast\-indirect\-calls\fR 4
  .IX Item "-mfast-indirect-calls"
  Generate code that assumes calls never cross space boundaries.  This
! allows GCC to emit code that performs faster indirect calls.
  .Sp
  This option does not work in the presence of shared libraries or nested
  functions.
! .IP \fB\-mfixed\-range=\fR\fIregister\-range\fR 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP \fB\-mgas\fR 4
  .IX Item "-mgas"
! Enable the use of assembler directives only GAS understands.
! .IP \fB\-mgnu\-ld\fR 4
  .IX Item "-mgnu-ld"
! Use options specific to GNU \fBld\fR.
  This passes \fB\-shared\fR to \fBld\fR when
! building a shared library.  It is the default when GCC is configured,
! explicitly or implicitly, with the GNU linker.  This option does not
  affect which \fBld\fR is called; it only changes what parameters
  are passed to that \fBld\fR.
  The \fBld\fR that is called is determined by the
! \&\fB\-\-with\-ld\fR configure option, GCC\*(Aqs program search path, and
! finally by the user\*(Aqs \fBPATH\fR.  The linker used by GCC can be printed
! using \fBwhich \`gcc \-print\-prog\-name=ld\`\fR.  This option is only available
! on the 64\-bit HP\-UX GCC, i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
! .IP \fB\-mhp\-ld\fR 4
  .IX Item "-mhp-ld"
! Use options specific to HP \fBld\fR.
  This passes \fB\-b\fR to \fBld\fR when building
  a shared library and passes \fB+Accept TypeMismatch\fR to \fBld\fR on all
! links.  It is the default when GCC is configured, explicitly or
! implicitly, with the HP linker.  This option does not affect
  which \fBld\fR is called; it only changes what parameters are passed to that
  \&\fBld\fR.
  The \fBld\fR that is called is determined by the \fB\-\-with\-ld\fR
! configure option, GCC\*(Aqs program search path, and finally by the user\*(Aqs
! \&\fBPATH\fR.  The linker used by GCC can be printed using \fBwhich
! \&\`gcc \-print\-prog\-name=ld\`\fR.  This option is only available on the 64\-bit
! HP\-UX GCC, i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
! .IP \fB\-mlinker\-opt\fR 4
  .IX Item "-mlinker-opt"
! Enable the optimization pass in the HP\-UX linker.  Note this makes symbolic
! debugging impossible.  It also triggers a bug in the HP\-UX 8 and HP\-UX 9
  linkers in which they give bogus error messages when linking some programs.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  Generate code that uses long call sequences.  This ensures that a call
  is always able to reach linker generated stubs.  The default is to generate
*************** long calls only when the distance from t
*** 24490,24502 ****
  of the function or translation unit, as the case may be, exceeds a
  predefined limit set by the branch type being used.  The limits for
  normal calls are 7,600,000 and 240,000 bytes, respectively for the
! \&\s-1PA 2.0\s0 and \s-1PA 1.X\s0 architectures.  Sibcalls are always limited at
  240,000 bytes.
  .Sp
  Distances are measured from the beginning of functions when using the
  \&\fB\-ffunction\-sections\fR option, or when using the \fB\-mgas\fR
! and \fB\-mno\-portable\-runtime\fR options together under HP-UX with
! the \s-1SOM\s0 linker.
  .Sp
  It is normally not desirable to use this option as it degrades
  performance.  However, it may be useful in large applications,
--- 24421,24433 ----
  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.
  .Sp
  Distances are measured from the beginning of functions when using the
  \&\fB\-ffunction\-sections\fR option, or when using the \fB\-mgas\fR
! and \fB\-mno\-portable\-runtime\fR options together under HP\-UX with
! the SOM linker.
  .Sp
  It is normally not desirable to use this option as it degrades
  performance.  However, it may be useful in large applications,
*************** particularly when partial linking is use
*** 24505,24577 ****
  The types of long calls used depends on the capabilities of the
  assembler and linker, and the type of code being generated.  The
  impact on systems that support long absolute calls, and long pic
! symbol-difference or pc-relative calls should be relatively small.
! However, an indirect call is used on 32\-bit \s-1ELF\s0 systems in pic code
  and it is quite long.
! .IP "\fB\-mlong\-load\-store\fR" 4
  .IX Item "-mlong-load-store"
  Generate 3\-instruction load and store sequences as sometimes required by
! the HP-UX 10 linker.  This is equivalent to the \fB+k\fR option to
! the \s-1HP\s0 compilers.
! .IP "\fB\-mjump\-in\-delay\fR" 4
  .IX Item "-mjump-in-delay"
  This option is ignored and provided for compatibility purposes only.
! .IP "\fB\-mno\-space\-regs\fR" 4
  .IX Item "-mno-space-regs"
  Generate code that assumes the target has no space registers.  This allows
! \&\s-1GCC\s0 to generate faster indirect calls and use unscaled index address modes.
  .Sp
! Such code is suitable for level 0 \s-1PA\s0 systems and kernels.
! .IP "\fB\-mordered\fR" 4
  .IX Item "-mordered"
  Assume memory references are ordered and barriers are not needed.
! .IP "\fB\-mportable\-runtime\fR" 4
  .IX Item "-mportable-runtime"
! Use the portable calling conventions proposed by \s-1HP\s0 for \s-1ELF\s0 systems.
! .IP "\fB\-mschedule=\fR\fIcpu-type\fR" 4
  .IX Item "-mschedule=cpu-type"
  Schedule code according to the constraints for the machine type
! \&\fIcpu-type\fR.  The choices for \fIcpu-type\fR are \fB700\fR
  \&\fB7100\fR, \fB7100LC\fR, \fB7200\fR, \fB7300\fR and \fB8000\fR.  Refer
! to \fI/usr/lib/sched.models\fR on an HP-UX system to determine the
  proper scheduling option for your machine.  The default scheduling is
  \&\fB8000\fR.
! .IP "\fB\-msio\fR" 4
  .IX Item "-msio"
! Generate the predefine, \f(CW\*(C`_SIO\*(C'\fR, for server \s-1IO.\s0  The default is
  \&\fB\-mwsio\fR.  This generates the predefines, \f(CW\*(C`_\|_hp9000s700\*(C'\fR,
! \&\f(CW\*(C`_\|_hp9000s700_\|_\*(C'\fR and \f(CW\*(C`_WSIO\*(C'\fR, for workstation \s-1IO.\s0  These
! options are available under HP-UX and HI-UX.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  Generate output containing library calls for floating point.
! \&\fBWarning:\fR the requisite libraries are not available for all \s-1HPPA\s0
! targets.  Normally the facilities of the machine's usual C compiler are
! used, but this cannot be done directly in cross-compilation.  You must make
  your own arrangements to provide suitable library functions for
! cross-compilation.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with \s-1GCC,\s0 with \fB\-msoft\-float\fR in order for
  this to work.
! .IP "\fB\-msoft\-mult\fR" 4
  .IX Item "-msoft-mult"
  Use software integer multiplication.
  .Sp
  This disables the use of the \f(CW\*(C`xmpyu\*(C'\fR instruction.
! .IP "\fB\-munix=\fR\fIunix-std\fR" 4
  .IX Item "-munix=unix-std"
  Generate compiler predefines and select a startfile for the specified
! \&\s-1UNIX\s0 standard.  The choices for \fIunix-std\fR are \fB93\fR, \fB95\fR
! and \fB98\fR.  \fB93\fR is supported on all HP-UX versions.  \fB95\fR
! is available on HP-UX 10.10 and later.  \fB98\fR is available on HP-UX
! 11.11 and later.  The default values are \fB93\fR for HP-UX 10.00,
! \&\fB95\fR for HP-UX 10.10 though to 11.00, and \fB98\fR for HP-UX 11.11
  and later.
  .Sp
! \&\fB\-munix=93\fR provides the same predefines as \s-1GCC 3.3\s0 and 3.4.
  \&\fB\-munix=95\fR provides additional predefines for \f(CW\*(C`XOPEN_UNIX\*(C'\fR
  and \f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, and the startfile \fIunix95.o\fR.
  \&\fB\-munix=98\fR provides additional predefines for \f(CW\*(C`_XOPEN_UNIX\*(C'\fR,
--- 24436,24508 ----
  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.
! .IP \fB\-mlong\-load\-store\fR 4
  .IX Item "-mlong-load-store"
  Generate 3\-instruction load and store sequences as sometimes required by
! the HP\-UX 10 linker.  This is equivalent to the \fB+k\fR option to
! the HP compilers.
! .IP \fB\-mjump\-in\-delay\fR 4
  .IX Item "-mjump-in-delay"
  This option is ignored and provided for compatibility purposes only.
! .IP \fB\-mno\-space\-regs\fR 4
  .IX Item "-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.
  .Sp
! Such code is suitable for level 0 PA systems and kernels.
! .IP \fB\-mordered\fR 4
  .IX Item "-mordered"
  Assume memory references are ordered and barriers are not needed.
! .IP \fB\-mportable\-runtime\fR 4
  .IX Item "-mportable-runtime"
! Use the portable calling conventions proposed by HP for ELF systems.
! .IP \fB\-mschedule=\fR\fIcpu\-type\fR 4
  .IX Item "-mschedule=cpu-type"
  Schedule code according to the constraints for the machine type
! \&\fIcpu\-type\fR.  The choices for \fIcpu\-type\fR are \fB700\fR
  \&\fB7100\fR, \fB7100LC\fR, \fB7200\fR, \fB7300\fR and \fB8000\fR.  Refer
! to \fI/usr/lib/sched.models\fR on an HP\-UX system to determine the
  proper scheduling option for your machine.  The default scheduling is
  \&\fB8000\fR.
! .IP \fB\-msio\fR 4
  .IX Item "-msio"
! Generate the predefine, \f(CW\*(C`_SIO\*(C'\fR, for server IO.  The default is
  \&\fB\-mwsio\fR.  This generates the predefines, \f(CW\*(C`_\|_hp9000s700\*(C'\fR,
! \&\f(CW\*(C`_\|_hp9000s700_\|_\*(C'\fR and \f(CW\*(C`_WSIO\*(C'\fR, for workstation IO.  These
! options are available under HP\-UX and HI\-UX.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  Generate output containing library calls for floating point.
! \&\fBWarning:\fR the requisite libraries are not available for all HPPA
! targets.  Normally the facilities of the machine\*(Aqs usual C compiler are
! used, but this cannot be done directly in cross\-compilation.  You must make
  your own arrangements to provide suitable library functions for
! cross\-compilation.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with GCC, with \fB\-msoft\-float\fR in order for
  this to work.
! .IP \fB\-msoft\-mult\fR 4
  .IX Item "-msoft-mult"
  Use software integer multiplication.
  .Sp
  This disables the use of the \f(CW\*(C`xmpyu\*(C'\fR instruction.
! .IP \fB\-munix=\fR\fIunix\-std\fR 4
  .IX Item "-munix=unix-std"
  Generate compiler predefines and select a startfile for the specified
! UNIX standard.  The choices for \fIunix\-std\fR are \fB93\fR, \fB95\fR
! and \fB98\fR.  \fB93\fR is supported on all HP\-UX versions.  \fB95\fR
! is available on HP\-UX 10.10 and later.  \fB98\fR is available on HP\-UX
! 11.11 and later.  The default values are \fB93\fR for HP\-UX 10.00,
! \&\fB95\fR for HP\-UX 10.10 though to 11.00, and \fB98\fR for HP\-UX 11.11
  and later.
  .Sp
! \&\fB\-munix=93\fR provides the same predefines as GCC 3.3 and 3.4.
  \&\fB\-munix=95\fR provides additional predefines for \f(CW\*(C`XOPEN_UNIX\*(C'\fR
  and \f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, and the startfile \fIunix95.o\fR.
  \&\fB\-munix=98\fR provides additional predefines for \f(CW\*(C`_XOPEN_UNIX\*(C'\fR,
*************** for various library routines.  It also a
*** 24583,24783 ****
  of the C library.  Thus, \fIextreme\fR care is needed in using this
  option.
  .Sp
! Library code that is intended to operate with more than one \s-1UNIX\s0
  standard must test, set and restore the variable \f(CW\*(C`_\|_xpg4_extended_mask\*(C'\fR
! as appropriate.  Most \s-1GNU\s0 software doesn't provide this capability.
! .IP "\fB\-nolibdld\fR" 4
  .IX Item "-nolibdld"
  Suppress the generation of link options to search libdld.sl when the
! \&\fB\-static\fR option is specified on HP-UX 10 and later.
! .IP "\fB\-static\fR" 4
  .IX Item "-static"
! The HP-UX implementation of setlocale in libc has a dependency on
! libdld.sl.  There isn't an archive version of libdld.sl.  Thus,
  when the \fB\-static\fR option is specified, special link options
  are needed to resolve this dependency.
  .Sp
! On HP-UX 10 and later, the \s-1GCC\s0 driver adds the necessary options to
  link with libdld.sl when the \fB\-static\fR option is specified.
  This causes the resulting binary to be dynamic.  On the 64\-bit port,
  the linkers generate dynamic binaries by default in any case.  The
! \&\fB\-nolibdld\fR option can be used to prevent the \s-1GCC\s0 driver from
  adding these link options.
! .IP "\fB\-threads\fR" 4
  .IX Item "-threads"
  Add support for multithreading with the \fIdce thread\fR library
! under HP-UX.  This option sets flags for both the preprocessor and
  linker.
  .PP
! \fI\s-1IA\-64\s0 Options\fR
  .IX Subsection "IA-64 Options"
  .PP
! These are the \fB\-m\fR options defined for the Intel \s-1IA\-64\s0 architecture.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code for a big-endian target.  This is the default for HP-UX.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code for a little-endian target.  This is the default for \s-1AIX5\s0
  and GNU/Linux.
! .IP "\fB\-mgnu\-as\fR" 4
  .IX Item "-mgnu-as"
  .PD 0
! .IP "\fB\-mno\-gnu\-as\fR" 4
  .IX Item "-mno-gnu-as"
  .PD
! Generate (or don't) code for the \s-1GNU\s0 assembler.  This is the default.
! .IP "\fB\-mgnu\-ld\fR" 4
  .IX Item "-mgnu-ld"
  .PD 0
! .IP "\fB\-mno\-gnu\-ld\fR" 4
  .IX Item "-mno-gnu-ld"
  .PD
! Generate (or don't) code for the \s-1GNU\s0 linker.  This is the default.
! .IP "\fB\-mno\-pic\fR" 4
  .IX Item "-mno-pic"
  Generate code that does not use a global pointer register.  The result
! is not position independent code, and violates the \s-1IA\-64 ABI.\s0
! .IP "\fB\-mvolatile\-asm\-stop\fR" 4
  .IX Item "-mvolatile-asm-stop"
  .PD 0
! .IP "\fB\-mno\-volatile\-asm\-stop\fR" 4
  .IX Item "-mno-volatile-asm-stop"
  .PD
! Generate (or don't) a stop bit immediately before and after volatile asm
  statements.
! .IP "\fB\-mregister\-names\fR" 4
  .IX Item "-mregister-names"
  .PD 0
! .IP "\fB\-mno\-register\-names\fR" 4
  .IX Item "-mno-register-names"
  .PD
! Generate (or don't) \fBin\fR, \fBloc\fR, and \fBout\fR register names for
  the stacked registers.  This may make assembler output more readable.
! .IP "\fB\-mno\-sdata\fR" 4
  .IX Item "-mno-sdata"
  .PD 0
! .IP "\fB\-msdata\fR" 4
  .IX Item "-msdata"
  .PD
  Disable (or enable) optimizations that use the small data section.  This may
  be useful for working around optimizer bugs.
! .IP "\fB\-mconstant\-gp\fR" 4
  .IX Item "-mconstant-gp"
  Generate code that uses a single constant global pointer value.  This is
  useful when compiling kernel code.
! .IP "\fB\-mauto\-pic\fR" 4
  .IX Item "-mauto-pic"
! Generate code that is self-relocatable.  This implies \fB\-mconstant\-gp\fR.
  This is useful when compiling firmware code.
! .IP "\fB\-minline\-float\-divide\-min\-latency\fR" 4
  .IX Item "-minline-float-divide-min-latency"
! Generate code for inline divides of floating-point values
  using the minimum latency algorithm.
! .IP "\fB\-minline\-float\-divide\-max\-throughput\fR" 4
  .IX Item "-minline-float-divide-max-throughput"
! Generate code for inline divides of floating-point values
  using the maximum throughput algorithm.
! .IP "\fB\-mno\-inline\-float\-divide\fR" 4
  .IX Item "-mno-inline-float-divide"
! Do not generate inline code for divides of floating-point values.
! .IP "\fB\-minline\-int\-divide\-min\-latency\fR" 4
  .IX Item "-minline-int-divide-min-latency"
  Generate code for inline divides of integer values
  using the minimum latency algorithm.
! .IP "\fB\-minline\-int\-divide\-max\-throughput\fR" 4
  .IX Item "-minline-int-divide-max-throughput"
  Generate code for inline divides of integer values
  using the maximum throughput algorithm.
! .IP "\fB\-mno\-inline\-int\-divide\fR" 4
  .IX Item "-mno-inline-int-divide"
  Do not generate inline code for divides of integer values.
! .IP "\fB\-minline\-sqrt\-min\-latency\fR" 4
  .IX Item "-minline-sqrt-min-latency"
  Generate code for inline square roots
  using the minimum latency algorithm.
! .IP "\fB\-minline\-sqrt\-max\-throughput\fR" 4
  .IX Item "-minline-sqrt-max-throughput"
  Generate code for inline square roots
  using the maximum throughput algorithm.
! .IP "\fB\-mno\-inline\-sqrt\fR" 4
  .IX Item "-mno-inline-sqrt"
  Do not generate inline code for \f(CW\*(C`sqrt\*(C'\fR.
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
! Do (don't) generate code that uses the fused multiply/add or multiply/subtract
  instructions.  The default is to use these instructions.
! .IP "\fB\-mno\-dwarf2\-asm\fR" 4
  .IX Item "-mno-dwarf2-asm"
  .PD 0
! .IP "\fB\-mdwarf2\-asm\fR" 4
  .IX Item "-mdwarf2-asm"
  .PD
! Don't (or do) generate assembler code for the \s-1DWARF\s0 line number debugging
! info.  This may be useful when not using the \s-1GNU\s0 assembler.
! .IP "\fB\-mearly\-stop\-bits\fR" 4
  .IX Item "-mearly-stop-bits"
  .PD 0
! .IP "\fB\-mno\-early\-stop\-bits\fR" 4
  .IX Item "-mno-early-stop-bits"
  .PD
  Allow stop bits to be placed earlier than immediately preceding the
  instruction that triggered the stop bit.  This can improve instruction
  scheduling, but does not always do so.
! .IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP "\fB\-mtls\-size=\fR\fItls-size\fR" 4
  .IX Item "-mtls-size=tls-size"
! Specify bit size of immediate \s-1TLS\s0 offsets.  Valid values are 14, 22, and
  64.
! .IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
  .IX Item "-mtune=cpu-type"
! Tune the instruction scheduling for a particular \s-1CPU,\s0 Valid values are
  \&\fBitanium\fR, \fBitanium1\fR, \fBmerced\fR, \fBitanium2\fR,
  and \fBmckinley\fR.
! .IP "\fB\-milp32\fR" 4
  .IX Item "-milp32"
  .PD 0
! .IP "\fB\-mlp64\fR" 4
  .IX Item "-mlp64"
  .PD
  Generate code for a 32\-bit or 64\-bit environment.
  The 32\-bit environment sets int, long and pointer to 32 bits.
  The 64\-bit environment sets int to 32 bits and long and pointer
! to 64 bits.  These are HP-UX specific flags.
! .IP "\fB\-mno\-sched\-br\-data\-spec\fR" 4
  .IX Item "-mno-sched-br-data-spec"
  .PD 0
! .IP "\fB\-msched\-br\-data\-spec\fR" 4
  .IX Item "-msched-br-data-spec"
  .PD
  (Dis/En)able data speculative scheduling before reload.
  This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
  the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
  The default setting is disabled.
! .IP "\fB\-msched\-ar\-data\-spec\fR" 4
  .IX Item "-msched-ar-data-spec"
  .PD 0
! .IP "\fB\-mno\-sched\-ar\-data\-spec\fR" 4
  .IX Item "-mno-sched-ar-data-spec"
  .PD
  (En/Dis)able data speculative scheduling after reload.
  This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
  the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
  The default setting is enabled.
! .IP "\fB\-mno\-sched\-control\-spec\fR" 4
  .IX Item "-mno-sched-control-spec"
  .PD 0
! .IP "\fB\-msched\-control\-spec\fR" 4
  .IX Item "-msched-control-spec"
  .PD
  (Dis/En)able control speculative scheduling.  This feature is
--- 24514,24714 ----
  of the C library.  Thus, \fIextreme\fR care is needed in using this
  option.
  .Sp
! Library code that is intended to operate with more than one UNIX
  standard must test, set and restore the variable \f(CW\*(C`_\|_xpg4_extended_mask\*(C'\fR
! as appropriate.  Most GNU software doesn\*(Aqt provide this capability.
! .IP \fB\-nolibdld\fR 4
  .IX Item "-nolibdld"
  Suppress the generation of link options to search libdld.sl when the
! \&\fB\-static\fR option is specified on HP\-UX 10 and later.
! .IP \fB\-static\fR 4
  .IX Item "-static"
! The HP\-UX implementation of setlocale in libc has a dependency on
! libdld.sl.  There isn\*(Aqt an archive version of libdld.sl.  Thus,
  when the \fB\-static\fR option is specified, special link options
  are needed to resolve this dependency.
  .Sp
! On HP\-UX 10 and later, the GCC driver adds the necessary options to
  link with libdld.sl when the \fB\-static\fR option is specified.
  This causes the resulting binary to be dynamic.  On the 64\-bit port,
  the linkers generate dynamic binaries by default in any case.  The
! \&\fB\-nolibdld\fR option can be used to prevent the GCC driver from
  adding these link options.
! .IP \fB\-threads\fR 4
  .IX Item "-threads"
  Add support for multithreading with the \fIdce thread\fR library
! under HP\-UX.  This option sets flags for both the preprocessor and
  linker.
  .PP
! \fIIA\-64 Options\fR
  .IX Subsection "IA-64 Options"
  .PP
! These are the \fB\-m\fR options defined for the Intel IA\-64 architecture.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code for a big\-endian target.  This is the default for HP\-UX.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code for a little\-endian target.  This is the default for AIX5
  and GNU/Linux.
! .IP \fB\-mgnu\-as\fR 4
  .IX Item "-mgnu-as"
  .PD 0
! .IP \fB\-mno\-gnu\-as\fR 4
  .IX Item "-mno-gnu-as"
  .PD
! Generate (or don\*(Aqt) code for the GNU assembler.  This is the default.
! .IP \fB\-mgnu\-ld\fR 4
  .IX Item "-mgnu-ld"
  .PD 0
! .IP \fB\-mno\-gnu\-ld\fR 4
  .IX Item "-mno-gnu-ld"
  .PD
! Generate (or don\*(Aqt) code for the GNU linker.  This is the default.
! .IP \fB\-mno\-pic\fR 4
  .IX Item "-mno-pic"
  Generate code that does not use a global pointer register.  The result
! is not position independent code, and violates the IA\-64 ABI.
! .IP \fB\-mvolatile\-asm\-stop\fR 4
  .IX Item "-mvolatile-asm-stop"
  .PD 0
! .IP \fB\-mno\-volatile\-asm\-stop\fR 4
  .IX Item "-mno-volatile-asm-stop"
  .PD
! Generate (or don\*(Aqt) a stop bit immediately before and after volatile asm
  statements.
! .IP \fB\-mregister\-names\fR 4
  .IX Item "-mregister-names"
  .PD 0
! .IP \fB\-mno\-register\-names\fR 4
  .IX Item "-mno-register-names"
  .PD
! Generate (or don\*(Aqt) \fBin\fR, \fBloc\fR, and \fBout\fR register names for
  the stacked registers.  This may make assembler output more readable.
! .IP \fB\-mno\-sdata\fR 4
  .IX Item "-mno-sdata"
  .PD 0
! .IP \fB\-msdata\fR 4
  .IX Item "-msdata"
  .PD
  Disable (or enable) optimizations that use the small data section.  This may
  be useful for working around optimizer bugs.
! .IP \fB\-mconstant\-gp\fR 4
  .IX Item "-mconstant-gp"
  Generate code that uses a single constant global pointer value.  This is
  useful when compiling kernel code.
! .IP \fB\-mauto\-pic\fR 4
  .IX Item "-mauto-pic"
! Generate code that is self\-relocatable.  This implies \fB\-mconstant\-gp\fR.
  This is useful when compiling firmware code.
! .IP \fB\-minline\-float\-divide\-min\-latency\fR 4
  .IX Item "-minline-float-divide-min-latency"
! Generate code for inline divides of floating\-point values
  using the minimum latency algorithm.
! .IP \fB\-minline\-float\-divide\-max\-throughput\fR 4
  .IX Item "-minline-float-divide-max-throughput"
! Generate code for inline divides of floating\-point values
  using the maximum throughput algorithm.
! .IP \fB\-mno\-inline\-float\-divide\fR 4
  .IX Item "-mno-inline-float-divide"
! Do not generate inline code for divides of floating\-point values.
! .IP \fB\-minline\-int\-divide\-min\-latency\fR 4
  .IX Item "-minline-int-divide-min-latency"
  Generate code for inline divides of integer values
  using the minimum latency algorithm.
! .IP \fB\-minline\-int\-divide\-max\-throughput\fR 4
  .IX Item "-minline-int-divide-max-throughput"
  Generate code for inline divides of integer values
  using the maximum throughput algorithm.
! .IP \fB\-mno\-inline\-int\-divide\fR 4
  .IX Item "-mno-inline-int-divide"
  Do not generate inline code for divides of integer values.
! .IP \fB\-minline\-sqrt\-min\-latency\fR 4
  .IX Item "-minline-sqrt-min-latency"
  Generate code for inline square roots
  using the minimum latency algorithm.
! .IP \fB\-minline\-sqrt\-max\-throughput\fR 4
  .IX Item "-minline-sqrt-max-throughput"
  Generate code for inline square roots
  using the maximum throughput algorithm.
! .IP \fB\-mno\-inline\-sqrt\fR 4
  .IX Item "-mno-inline-sqrt"
  Do not generate inline code for \f(CW\*(C`sqrt\*(C'\fR.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
! Do (don\*(Aqt) generate code that uses the fused multiply/add or multiply/subtract
  instructions.  The default is to use these instructions.
! .IP \fB\-mno\-dwarf2\-asm\fR 4
  .IX Item "-mno-dwarf2-asm"
  .PD 0
! .IP \fB\-mdwarf2\-asm\fR 4
  .IX Item "-mdwarf2-asm"
  .PD
! Don\*(Aqt (or do) generate assembler code for the DWARF line number debugging
! info.  This may be useful when not using the GNU assembler.
! .IP \fB\-mearly\-stop\-bits\fR 4
  .IX Item "-mearly-stop-bits"
  .PD 0
! .IP \fB\-mno\-early\-stop\-bits\fR 4
  .IX Item "-mno-early-stop-bits"
  .PD
  Allow stop bits to be placed earlier than immediately preceding the
  instruction that triggered the stop bit.  This can improve instruction
  scheduling, but does not always do so.
! .IP \fB\-mfixed\-range=\fR\fIregister\-range\fR 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP \fB\-mtls\-size=\fR\fItls\-size\fR 4
  .IX Item "-mtls-size=tls-size"
! Specify bit size of immediate TLS offsets.  Valid values are 14, 22, and
  64.
! .IP \fB\-mtune=\fR\fIcpu\-type\fR 4
  .IX Item "-mtune=cpu-type"
! Tune the instruction scheduling for a particular CPU, Valid values are
  \&\fBitanium\fR, \fBitanium1\fR, \fBmerced\fR, \fBitanium2\fR,
  and \fBmckinley\fR.
! .IP \fB\-milp32\fR 4
  .IX Item "-milp32"
  .PD 0
! .IP \fB\-mlp64\fR 4
  .IX Item "-mlp64"
  .PD
  Generate code for a 32\-bit or 64\-bit environment.
  The 32\-bit environment sets int, long and pointer to 32 bits.
  The 64\-bit environment sets int to 32 bits and long and pointer
! to 64 bits.  These are HP\-UX specific flags.
! .IP \fB\-mno\-sched\-br\-data\-spec\fR 4
  .IX Item "-mno-sched-br-data-spec"
  .PD 0
! .IP \fB\-msched\-br\-data\-spec\fR 4
  .IX Item "-msched-br-data-spec"
  .PD
  (Dis/En)able data speculative scheduling before reload.
  This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
  the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
  The default setting is disabled.
! .IP \fB\-msched\-ar\-data\-spec\fR 4
  .IX Item "-msched-ar-data-spec"
  .PD 0
! .IP \fB\-mno\-sched\-ar\-data\-spec\fR 4
  .IX Item "-mno-sched-ar-data-spec"
  .PD
  (En/Dis)able data speculative scheduling after reload.
  This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
  the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
  The default setting is enabled.
! .IP \fB\-mno\-sched\-control\-spec\fR 4
  .IX Item "-mno-sched-control-spec"
  .PD 0
! .IP \fB\-msched\-control\-spec\fR 4
  .IX Item "-msched-control-spec"
  .PD
  (Dis/En)able control speculative scheduling.  This feature is
*************** available only during region scheduling
*** 24785,25077 ****
  This results in generation of the \f(CW\*(C`ld.s\*(C'\fR instructions and
  the corresponding check instructions \f(CW\*(C`chk.s\*(C'\fR.
  The default setting is disabled.
! .IP "\fB\-msched\-br\-in\-data\-spec\fR" 4
  .IX Item "-msched-br-in-data-spec"
  .PD 0
! .IP "\fB\-mno\-sched\-br\-in\-data\-spec\fR" 4
  .IX Item "-mno-sched-br-in-data-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the data speculative loads before reload.
  This is effective only with \fB\-msched\-br\-data\-spec\fR enabled.
  The default setting is enabled.
! .IP "\fB\-msched\-ar\-in\-data\-spec\fR" 4
  .IX Item "-msched-ar-in-data-spec"
  .PD 0
! .IP "\fB\-mno\-sched\-ar\-in\-data\-spec\fR" 4
  .IX Item "-mno-sched-ar-in-data-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the data speculative loads after reload.
  This is effective only with \fB\-msched\-ar\-data\-spec\fR enabled.
  The default setting is enabled.
! .IP "\fB\-msched\-in\-control\-spec\fR" 4
  .IX Item "-msched-in-control-spec"
  .PD 0
! .IP "\fB\-mno\-sched\-in\-control\-spec\fR" 4
  .IX Item "-mno-sched-in-control-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the control speculative loads.
  This is effective only with \fB\-msched\-control\-spec\fR enabled.
  The default setting is enabled.
! .IP "\fB\-mno\-sched\-prefer\-non\-data\-spec\-insns\fR" 4
  .IX Item "-mno-sched-prefer-non-data-spec-insns"
  .PD 0
! .IP "\fB\-msched\-prefer\-non\-data\-spec\-insns\fR" 4
  .IX Item "-msched-prefer-non-data-spec-insns"
  .PD
! If enabled, data-speculative instructions are chosen for schedule
  only if there are no other choices at the moment.  This makes
  the use of the data speculation much more conservative.
  The default setting is disabled.
! .IP "\fB\-mno\-sched\-prefer\-non\-control\-spec\-insns\fR" 4
  .IX Item "-mno-sched-prefer-non-control-spec-insns"
  .PD 0
! .IP "\fB\-msched\-prefer\-non\-control\-spec\-insns\fR" 4
  .IX Item "-msched-prefer-non-control-spec-insns"
  .PD
! If enabled, control-speculative instructions are chosen for schedule
  only if there are no other choices at the moment.  This makes
  the use of the control speculation much more conservative.
  The default setting is disabled.
! .IP "\fB\-mno\-sched\-count\-spec\-in\-critical\-path\fR" 4
  .IX Item "-mno-sched-count-spec-in-critical-path"
  .PD 0
! .IP "\fB\-msched\-count\-spec\-in\-critical\-path\fR" 4
  .IX Item "-msched-count-spec-in-critical-path"
  .PD
  If enabled, speculative dependencies are considered during
  computation of the instructions priorities.  This makes the use of the
  speculation a bit more conservative.
  The default setting is disabled.
! .IP "\fB\-msched\-spec\-ldc\fR" 4
  .IX Item "-msched-spec-ldc"
  Use a simple data speculation check.  This option is on by default.
! .IP "\fB\-msched\-control\-spec\-ldc\fR" 4
  .IX Item "-msched-control-spec-ldc"
  Use a simple check for control speculation.  This option is on by default.
! .IP "\fB\-msched\-stop\-bits\-after\-every\-cycle\fR" 4
  .IX Item "-msched-stop-bits-after-every-cycle"
  Place a stop bit after every cycle when scheduling.  This option is on
  by default.
! .IP "\fB\-msched\-fp\-mem\-deps\-zero\-cost\fR" 4
  .IX Item "-msched-fp-mem-deps-zero-cost"
! Assume that floating-point stores and loads are not likely to cause a conflict
  when placed into the same instruction group.  This option is disabled by
  default.
! .IP "\fB\-msel\-sched\-dont\-check\-control\-spec\fR" 4
  .IX Item "-msel-sched-dont-check-control-spec"
  Generate checks for control speculation in selective scheduling.
  This flag is disabled by default.
! .IP "\fB\-msched\-max\-memory\-insns=\fR\fImax-insns\fR" 4
  .IX Item "-msched-max-memory-insns=max-insns"
  Limit on the number of memory insns per instruction group, giving lower
  priority to subsequent memory insns attempting to schedule in the same
  instruction group. Frequently useful to prevent cache bank conflicts.
  The default value is 1.
! .IP "\fB\-msched\-max\-memory\-insns\-hard\-limit\fR" 4
  .IX Item "-msched-max-memory-insns-hard-limit"
! Makes the limit specified by \fBmsched-max-memory-insns\fR a hard limit,
  disallowing more than that number in an instruction group.
! Otherwise, the limit is \*(L"soft\*(R", meaning that non-memory operations
  are preferred when the limit is reached, but memory operations may still
  be scheduled.
  .PP
! \fI\s-1LM32\s0 Options\fR
  .IX Subsection "LM32 Options"
  .PP
  These \fB\-m\fR options are defined for the LatticeMico32 architecture:
! .IP "\fB\-mbarrel\-shift\-enabled\fR" 4
  .IX Item "-mbarrel-shift-enabled"
! Enable barrel-shift instructions.
! .IP "\fB\-mdivide\-enabled\fR" 4
  .IX Item "-mdivide-enabled"
  Enable divide and modulus instructions.
! .IP "\fB\-mmultiply\-enabled\fR" 4
  .IX Item "-mmultiply-enabled"
  Enable multiply instructions.
! .IP "\fB\-msign\-extend\-enabled\fR" 4
  .IX Item "-msign-extend-enabled"
  Enable sign extend instructions.
! .IP "\fB\-muser\-enabled\fR" 4
  .IX Item "-muser-enabled"
! Enable user-defined instructions.
  .PP
  \fILoongArch Options\fR
  .IX Subsection "LoongArch Options"
  .PP
! These command-line options are defined for LoongArch targets:
! .IP "\fB\-march=\fR\fIcpu-type\fR" 4
  .IX Item "-march=cpu-type"
! Generate instructions for the machine type \fIcpu-type\fR.  In contrast to
! \&\fB\-mtune=\fR\fIcpu-type\fR, which merely tunes the generated code
! for the specified \fIcpu-type\fR, \fB\-march=\fR\fIcpu-type\fR allows \s-1GCC\s0
  to generate code that may not run at all on processors other than the one
! indicated.  Specifying \fB\-march=\fR\fIcpu-type\fR implies
! \&\fB\-mtune=\fR\fIcpu-type\fR, except where noted otherwise.
  .Sp
! The choices for \fIcpu-type\fR are:
  .RS 4
! .IP "\fBnative\fR" 4
  .IX Item "native"
! This selects the \s-1CPU\s0 to generate code for at compilation time by determining
  the processor type of the compiling machine.  Using \fB\-march=native\fR
  enables all instruction subsets supported by the local machine (hence
  the result might not run on different machines).  Using \fB\-mtune=native\fR
  produces code optimized for the local machine under the constraints
  of the selected instruction set.
! .IP "\fBloongarch64\fR" 4
  .IX Item "loongarch64"
! A generic \s-1CPU\s0 with 64\-bit extensions.
! .IP "\fBla464\fR" 4
  .IX Item "la464"
! LoongArch \s-1LA464 CPU\s0 with \s-1LBT, LSX, LASX, LVZ.\s0
  .RE
  .RS 4
  .RE
! .IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
  .IX Item "-mtune=cpu-type"
  Optimize the output for the given processor, specified by microarchitecture
  name.
! .IP "\fB\-mabi=\fR\fIbase-abi-type\fR" 4
  .IX Item "-mabi=base-abi-type"
  Generate code for the specified calling convention.
! \&\fIbase-abi-type\fR can be one of:
  .RS 4
! .IP "\fBlp64d\fR" 4
  .IX Item "lp64d"
! Uses 64\-bit general purpose registers and 32/64\-bit floating-point
! registers for parameter passing.  Data model is \s-1LP64,\s0 where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
! .IP "\fBlp64f\fR" 4
  .IX Item "lp64f"
! Uses 64\-bit general purpose registers and 32\-bit floating-point
! registers for parameter passing.  Data model is \s-1LP64,\s0 where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
! .IP "\fBlp64s\fR" 4
  .IX Item "lp64s"
! Uses 64\-bit general purpose registers and no floating-point
! registers for parameter passing.  Data model is \s-1LP64,\s0 where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mfpu=\fR\fIfpu-type\fR" 4
  .IX Item "-mfpu=fpu-type"
! Generate code for the specified \s-1FPU\s0 type, which can be one of:
  .RS 4
! .IP "\fB64\fR" 4
  .IX Item "64"
! Allow the use of hardware floating-point instructions for 32\-bit
  and 64\-bit operations.
! .IP "\fB32\fR" 4
  .IX Item "32"
! Allow the use of hardware floating-point instructions for 32\-bit
  operations.
! .IP "\fBnone\fR" 4
  .IX Item "none"
  .PD 0
! .IP "\fB0\fR" 4
  .IX Item "0"
  .PD
! Prevent the use of hardware floating-point instructions.
  .RE
  .RS 4
  .RE
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
! Force \fB\-mfpu=none\fR and prevents the use of floating-point
  registers for parameter passing.  This option may change the target
! \&\s-1ABI.\s0
! .IP "\fB\-msingle\-float\fR" 4
  .IX Item "-msingle-float"
! Force \fB\-mfpu=32\fR and allow the use of 32\-bit floating-point
  registers for parameter passing.  This option may change the target
! \&\s-1ABI.\s0
! .IP "\fB\-mdouble\-float\fR" 4
  .IX Item "-mdouble-float"
! Force \fB\-mfpu=64\fR and allow the use of 32/64\-bit floating-point
  registers for parameter passing.  This option may change the target
! \&\s-1ABI.\s0
! .IP "\fB\-mbranch\-cost=\fR\fIn\fR" 4
  .IX Item "-mbranch-cost=n"
  Set the cost of branches to roughly \fIn\fR instructions.
! .IP "\fB\-mcheck\-zero\-division\fR" 4
  .IX Item "-mcheck-zero-division"
  .PD 0
! .IP "\fB\-mno\-check\-zero\-divison\fR" 4
  .IX Item "-mno-check-zero-divison"
  .PD
  Trap (do not trap) on integer division by zero.  The default is
  \&\fB\-mcheck\-zero\-division\fR for \fB\-O0\fR or \fB\-Og\fR, and
  \&\fB\-mno\-check\-zero\-division\fR for other optimization levels.
! .IP "\fB\-mcond\-move\-int\fR" 4
  .IX Item "-mcond-move-int"
  .PD 0
! .IP "\fB\-mno\-cond\-move\-int\fR" 4
  .IX Item "-mno-cond-move-int"
  .PD
! Conditional moves for integral data in general-purpose registers
  are enabled (disabled).  The default is \fB\-mcond\-move\-int\fR.
! .IP "\fB\-mcond\-move\-float\fR" 4
  .IX Item "-mcond-move-float"
  .PD 0
! .IP "\fB\-mno\-cond\-move\-float\fR" 4
  .IX Item "-mno-cond-move-float"
  .PD
! Conditional moves for floating-point registers are enabled (disabled).
  The default is \fB\-mcond\-move\-float\fR.
! .IP "\fB\-mmemcpy\fR" 4
  .IX Item "-mmemcpy"
  .PD 0
! .IP "\fB\-mno\-memcpy\fR" 4
  .IX Item "-mno-memcpy"
  .PD
! Force (do not force) the use of \f(CW\*(C`memcpy\*(C'\fR for non-trivial block moves.
! The default is \fB\-mno\-memcpy\fR, which allows \s-1GCC\s0 to inline most
! constant-sized copies.  Setting optimization level to \fB\-Os\fR also
  forces the use of \f(CW\*(C`memcpy\*(C'\fR, but \fB\-mno\-memcpy\fR may override this
  behavior if explicitly specified, regardless of the order these options on
  the command line.
! .IP "\fB\-mstrict\-align\fR" 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP "\fB\-mno\-strict\-align\fR" 4
  .IX Item "-mno-strict-align"
  .PD
  Avoid or allow generating memory accesses that may not be aligned on a natural
  object boundary as described in the architecture specification. The default is
  \&\fB\-mno\-strict\-align\fR.
! .IP "\fB\-msmall\-data\-limit=\fR\fInumber\fR" 4
  .IX Item "-msmall-data-limit=number"
  Put global and static data smaller than \fInumber\fR bytes into a special
  section (on some targets).  The default value is 0.
! .IP "\fB\-mmax\-inline\-memcpy\-size=\fR\fIn\fR" 4
  .IX Item "-mmax-inline-memcpy-size=n"
  Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure copies)
  less than or equal to \fIn\fR bytes.  The default value of \fIn\fR is 1024.
! .IP "\fB\-mcmodel=\fR\fIcode-model\fR" 4
  .IX Item "-mcmodel=code-model"
  Set the code model to one of:
  .RS 4
! .IP "\fBtiny-static (Not implemented yet)\fR" 4
  .IX Item "tiny-static (Not implemented yet)"
  .PD 0
  .IP "\fBtiny (Not implemented yet)\fR" 4
  .IX Item "tiny (Not implemented yet)"
! .IP "\fBnormal\fR" 4
  .IX Item "normal"
  .PD
  The text segment must be within 128MB addressing space.  The data segment must
  be within 2GB addressing space.
! .IP "\fBmedium\fR" 4
  .IX Item "medium"
  The text segment and data segment must be within 2GB addressing space.
  .IP "\fBlarge (Not implemented yet)\fR" 4
  .IX Item "large (Not implemented yet)"
  .PD 0
! .IP "\fBextreme\fR" 4
  .IX Item "extreme"
  .PD
  This mode does not limit the size of the code segment and data segment.
--- 24716,25008 ----
  This results in generation of the \f(CW\*(C`ld.s\*(C'\fR instructions and
  the corresponding check instructions \f(CW\*(C`chk.s\*(C'\fR.
  The default setting is disabled.
! .IP \fB\-msched\-br\-in\-data\-spec\fR 4
  .IX Item "-msched-br-in-data-spec"
  .PD 0
! .IP \fB\-mno\-sched\-br\-in\-data\-spec\fR 4
  .IX Item "-mno-sched-br-in-data-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the data speculative loads before reload.
  This is effective only with \fB\-msched\-br\-data\-spec\fR enabled.
  The default setting is enabled.
! .IP \fB\-msched\-ar\-in\-data\-spec\fR 4
  .IX Item "-msched-ar-in-data-spec"
  .PD 0
! .IP \fB\-mno\-sched\-ar\-in\-data\-spec\fR 4
  .IX Item "-mno-sched-ar-in-data-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the data speculative loads after reload.
  This is effective only with \fB\-msched\-ar\-data\-spec\fR enabled.
  The default setting is enabled.
! .IP \fB\-msched\-in\-control\-spec\fR 4
  .IX Item "-msched-in-control-spec"
  .PD 0
! .IP \fB\-mno\-sched\-in\-control\-spec\fR 4
  .IX Item "-mno-sched-in-control-spec"
  .PD
  (En/Dis)able speculative scheduling of the instructions that
  are dependent on the control speculative loads.
  This is effective only with \fB\-msched\-control\-spec\fR enabled.
  The default setting is enabled.
! .IP \fB\-mno\-sched\-prefer\-non\-data\-spec\-insns\fR 4
  .IX Item "-mno-sched-prefer-non-data-spec-insns"
  .PD 0
! .IP \fB\-msched\-prefer\-non\-data\-spec\-insns\fR 4
  .IX Item "-msched-prefer-non-data-spec-insns"
  .PD
! If enabled, data\-speculative instructions are chosen for schedule
  only if there are no other choices at the moment.  This makes
  the use of the data speculation much more conservative.
  The default setting is disabled.
! .IP \fB\-mno\-sched\-prefer\-non\-control\-spec\-insns\fR 4
  .IX Item "-mno-sched-prefer-non-control-spec-insns"
  .PD 0
! .IP \fB\-msched\-prefer\-non\-control\-spec\-insns\fR 4
  .IX Item "-msched-prefer-non-control-spec-insns"
  .PD
! If enabled, control\-speculative instructions are chosen for schedule
  only if there are no other choices at the moment.  This makes
  the use of the control speculation much more conservative.
  The default setting is disabled.
! .IP \fB\-mno\-sched\-count\-spec\-in\-critical\-path\fR 4
  .IX Item "-mno-sched-count-spec-in-critical-path"
  .PD 0
! .IP \fB\-msched\-count\-spec\-in\-critical\-path\fR 4
  .IX Item "-msched-count-spec-in-critical-path"
  .PD
  If enabled, speculative dependencies are considered during
  computation of the instructions priorities.  This makes the use of the
  speculation a bit more conservative.
  The default setting is disabled.
! .IP \fB\-msched\-spec\-ldc\fR 4
  .IX Item "-msched-spec-ldc"
  Use a simple data speculation check.  This option is on by default.
! .IP \fB\-msched\-control\-spec\-ldc\fR 4
  .IX Item "-msched-control-spec-ldc"
  Use a simple check for control speculation.  This option is on by default.
! .IP \fB\-msched\-stop\-bits\-after\-every\-cycle\fR 4
  .IX Item "-msched-stop-bits-after-every-cycle"
  Place a stop bit after every cycle when scheduling.  This option is on
  by default.
! .IP \fB\-msched\-fp\-mem\-deps\-zero\-cost\fR 4
  .IX Item "-msched-fp-mem-deps-zero-cost"
! Assume that floating\-point stores and loads are not likely to cause a conflict
  when placed into the same instruction group.  This option is disabled by
  default.
! .IP \fB\-msel\-sched\-dont\-check\-control\-spec\fR 4
  .IX Item "-msel-sched-dont-check-control-spec"
  Generate checks for control speculation in selective scheduling.
  This flag is disabled by default.
! .IP \fB\-msched\-max\-memory\-insns=\fR\fImax\-insns\fR 4
  .IX Item "-msched-max-memory-insns=max-insns"
  Limit on the number of memory insns per instruction group, giving lower
  priority to subsequent memory insns attempting to schedule in the same
  instruction group. Frequently useful to prevent cache bank conflicts.
  The default value is 1.
! .IP \fB\-msched\-max\-memory\-insns\-hard\-limit\fR 4
  .IX Item "-msched-max-memory-insns-hard-limit"
! Makes the limit specified by \fBmsched\-max\-memory\-insns\fR a hard limit,
  disallowing more than that number in an instruction group.
! Otherwise, the limit is "soft", meaning that non\-memory operations
  are preferred when the limit is reached, but memory operations may still
  be scheduled.
  .PP
! \fILM32 Options\fR
  .IX Subsection "LM32 Options"
  .PP
  These \fB\-m\fR options are defined for the LatticeMico32 architecture:
! .IP \fB\-mbarrel\-shift\-enabled\fR 4
  .IX Item "-mbarrel-shift-enabled"
! Enable barrel\-shift instructions.
! .IP \fB\-mdivide\-enabled\fR 4
  .IX Item "-mdivide-enabled"
  Enable divide and modulus instructions.
! .IP \fB\-mmultiply\-enabled\fR 4
  .IX Item "-mmultiply-enabled"
  Enable multiply instructions.
! .IP \fB\-msign\-extend\-enabled\fR 4
  .IX Item "-msign-extend-enabled"
  Enable sign extend instructions.
! .IP \fB\-muser\-enabled\fR 4
  .IX Item "-muser-enabled"
! Enable user\-defined instructions.
  .PP
  \fILoongArch Options\fR
  .IX Subsection "LoongArch Options"
  .PP
! These command\-line options are defined for LoongArch targets:
! .IP \fB\-march=\fR\fIcpu\-type\fR 4
  .IX Item "-march=cpu-type"
! Generate instructions for the machine type \fIcpu\-type\fR.  In contrast to
! \&\fB\-mtune=\fR\fIcpu\-type\fR, which merely tunes the generated code
! for the specified \fIcpu\-type\fR, \fB\-march=\fR\fIcpu\-type\fR allows GCC
  to generate code that may not run at all on processors other than the one
! indicated.  Specifying \fB\-march=\fR\fIcpu\-type\fR implies
! \&\fB\-mtune=\fR\fIcpu\-type\fR, except where noted otherwise.
  .Sp
! The choices for \fIcpu\-type\fR are:
  .RS 4
! .IP \fBnative\fR 4
  .IX Item "native"
! This selects the CPU to generate code for at compilation time by determining
  the processor type of the compiling machine.  Using \fB\-march=native\fR
  enables all instruction subsets supported by the local machine (hence
  the result might not run on different machines).  Using \fB\-mtune=native\fR
  produces code optimized for the local machine under the constraints
  of the selected instruction set.
! .IP \fBloongarch64\fR 4
  .IX Item "loongarch64"
! A generic CPU with 64\-bit extensions.
! .IP \fBla464\fR 4
  .IX Item "la464"
! LoongArch LA464 CPU with LBT, LSX, LASX, LVZ.
  .RE
  .RS 4
  .RE
! .IP \fB\-mtune=\fR\fIcpu\-type\fR 4
  .IX Item "-mtune=cpu-type"
  Optimize the output for the given processor, specified by microarchitecture
  name.
! .IP \fB\-mabi=\fR\fIbase\-abi\-type\fR 4
  .IX Item "-mabi=base-abi-type"
  Generate code for the specified calling convention.
! \&\fIbase\-abi\-type\fR can be one of:
  .RS 4
! .IP \fBlp64d\fR 4
  .IX Item "lp64d"
! Uses 64\-bit general purpose registers and 32/64\-bit floating\-point
! registers for parameter passing.  Data model is LP64, where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
! .IP \fBlp64f\fR 4
  .IX Item "lp64f"
! Uses 64\-bit general purpose registers and 32\-bit floating\-point
! registers for parameter passing.  Data model is LP64, where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
! .IP \fBlp64s\fR 4
  .IX Item "lp64s"
! Uses 64\-bit general purpose registers and no floating\-point
! registers for parameter passing.  Data model is LP64, where \fBint\fR
  is 32 bits, while \fBlong int\fR and pointers are 64 bits.
  .RE
  .RS 4
  .RE
! .IP \fB\-mfpu=\fR\fIfpu\-type\fR 4
  .IX Item "-mfpu=fpu-type"
! Generate code for the specified FPU type, which can be one of:
  .RS 4
! .IP \fB64\fR 4
  .IX Item "64"
! Allow the use of hardware floating\-point instructions for 32\-bit
  and 64\-bit operations.
! .IP \fB32\fR 4
  .IX Item "32"
! Allow the use of hardware floating\-point instructions for 32\-bit
  operations.
! .IP \fBnone\fR 4
  .IX Item "none"
  .PD 0
! .IP \fB0\fR 4
  .IX Item "0"
  .PD
! Prevent the use of hardware floating\-point instructions.
  .RE
  .RS 4
  .RE
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
! Force \fB\-mfpu=none\fR and prevents the use of floating\-point
  registers for parameter passing.  This option may change the target
! ABI.
! .IP \fB\-msingle\-float\fR 4
  .IX Item "-msingle-float"
! Force \fB\-mfpu=32\fR and allow the use of 32\-bit floating\-point
  registers for parameter passing.  This option may change the target
! ABI.
! .IP \fB\-mdouble\-float\fR 4
  .IX Item "-mdouble-float"
! Force \fB\-mfpu=64\fR and allow the use of 32/64\-bit floating\-point
  registers for parameter passing.  This option may change the target
! ABI.
! .IP \fB\-mbranch\-cost=\fR\fIn\fR 4
  .IX Item "-mbranch-cost=n"
  Set the cost of branches to roughly \fIn\fR instructions.
! .IP \fB\-mcheck\-zero\-division\fR 4
  .IX Item "-mcheck-zero-division"
  .PD 0
! .IP \fB\-mno\-check\-zero\-divison\fR 4
  .IX Item "-mno-check-zero-divison"
  .PD
  Trap (do not trap) on integer division by zero.  The default is
  \&\fB\-mcheck\-zero\-division\fR for \fB\-O0\fR or \fB\-Og\fR, and
  \&\fB\-mno\-check\-zero\-division\fR for other optimization levels.
! .IP \fB\-mcond\-move\-int\fR 4
  .IX Item "-mcond-move-int"
  .PD 0
! .IP \fB\-mno\-cond\-move\-int\fR 4
  .IX Item "-mno-cond-move-int"
  .PD
! Conditional moves for integral data in general\-purpose registers
  are enabled (disabled).  The default is \fB\-mcond\-move\-int\fR.
! .IP \fB\-mcond\-move\-float\fR 4
  .IX Item "-mcond-move-float"
  .PD 0
! .IP \fB\-mno\-cond\-move\-float\fR 4
  .IX Item "-mno-cond-move-float"
  .PD
! Conditional moves for floating\-point registers are enabled (disabled).
  The default is \fB\-mcond\-move\-float\fR.
! .IP \fB\-mmemcpy\fR 4
  .IX Item "-mmemcpy"
  .PD 0
! .IP \fB\-mno\-memcpy\fR 4
  .IX Item "-mno-memcpy"
  .PD
! Force (do not force) the use of \f(CW\*(C`memcpy\*(C'\fR for non\-trivial block moves.
! The default is \fB\-mno\-memcpy\fR, which allows GCC to inline most
! constant\-sized copies.  Setting optimization level to \fB\-Os\fR also
  forces the use of \f(CW\*(C`memcpy\*(C'\fR, but \fB\-mno\-memcpy\fR may override this
  behavior if explicitly specified, regardless of the order these options on
  the command line.
! .IP \fB\-mstrict\-align\fR 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP \fB\-mno\-strict\-align\fR 4
  .IX Item "-mno-strict-align"
  .PD
  Avoid or allow generating memory accesses that may not be aligned on a natural
  object boundary as described in the architecture specification. The default is
  \&\fB\-mno\-strict\-align\fR.
! .IP \fB\-msmall\-data\-limit=\fR\fInumber\fR 4
  .IX Item "-msmall-data-limit=number"
  Put global and static data smaller than \fInumber\fR bytes into a special
  section (on some targets).  The default value is 0.
! .IP \fB\-mmax\-inline\-memcpy\-size=\fR\fIn\fR 4
  .IX Item "-mmax-inline-memcpy-size=n"
  Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure copies)
  less than or equal to \fIn\fR bytes.  The default value of \fIn\fR is 1024.
! .IP \fB\-mcmodel=\fR\fIcode\-model\fR 4
  .IX Item "-mcmodel=code-model"
  Set the code model to one of:
  .RS 4
! .IP "\fBtiny\-static (Not implemented yet)\fR" 4
  .IX Item "tiny-static (Not implemented yet)"
  .PD 0
  .IP "\fBtiny (Not implemented yet)\fR" 4
  .IX Item "tiny (Not implemented yet)"
! .IP \fBnormal\fR 4
  .IX Item "normal"
  .PD
  The text segment must be within 128MB addressing space.  The data segment must
  be within 2GB addressing space.
! .IP \fBmedium\fR 4
  .IX Item "medium"
  The text segment and data segment must be within 2GB addressing space.
  .IP "\fBlarge (Not implemented yet)\fR" 4
  .IX Item "large (Not implemented yet)"
  .PD 0
! .IP \fBextreme\fR 4
  .IX Item "extreme"
  .PD
  This mode does not limit the size of the code segment and data segment.
*************** The \fB\-mcmodel=extreme\fR option is in
*** 25082,25184 ****
  .Sp
  The default code model is \f(CW\*(C`normal\*(C'\fR.
  .RE
! .IP "\fB\-mexplicit\-relocs\fR" 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP "\fB\-mno\-explicit\-relocs\fR" 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Use or do not use assembler relocation operators when dealing with symbolic
  addresses.  The alternative is to use assembler macros instead, which may
  limit instruction scheduling but allow linker relaxation.  The default
  value for the option is determined with the assembler capability detected
! during \s-1GCC\s0 build-time and the setting of \f(CW\*(C`\-mrelax\*(C'\fR:
  \&\f(CW\*(C`\-mexplicit\-relocs\*(C'\fR if the assembler supports relocation operators
  but \f(CW\*(C`\-mrelax\*(C'\fR is not enabled, \f(CW\*(C`\-mno\-explicit\-relocs\*(C'\fR otherwise.
! .IP "\fB\-mdirect\-extern\-access\fR" 4
  .IX Item "-mdirect-extern-access"
  .PD 0
! .IP "\fB\-mno\-direct\-extern\-access\fR" 4
  .IX Item "-mno-direct-extern-access"
  .PD
! Do not use or use \s-1GOT\s0 to access external symbols.  The default is
! \&\fB\-mno\-direct\-extern\-access\fR: \s-1GOT\s0 is used for external symbols with
  default visibility, but not used for other external symbols.
  .Sp
! With \fB\-mdirect\-extern\-access\fR, \s-1GOT\s0 is not used and all external
! symbols are PC-relatively addressed.  It is \fBonly\fR suitable for
! environments where no dynamic link is performed, like firmwares, \s-1OS\s0
  kernels, executables linked with \fB\-static\fR or \fB\-static\-pie\fR.
  \&\fB\-mdirect\-extern\-access\fR is not compatible with \fB\-fPIC\fR or
  \&\fB\-fpic\fR.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  .PD 0
! .IP "\fB\-mno\-relax\fR" 4
  .IX Item "-mno-relax"
  .PD
  Take (do not take) advantage of linker relaxations.  If
  \&\fB\-mpass\-mrelax\-to\-as\fR is enabled, this option is also passed to
! the assembler.  The default is determined during \s-1GCC\s0 build-time by
  detecting corresponding assembler support:
  \&\fB\-mrelax\fR if the assembler supports both the \fB\-mrelax\fR
! option and the conditional branch relaxation (it's required or the
  \&\f(CW\*(C`.align\*(C'\fR directives and conditional branch instructions in the
! assembly code outputted by \s-1GCC\s0 may be rejected by the assembler because
  of a relocation overflow), \fB\-mno\-relax\fR otherwise.
! .IP "\fB\-mpass\-mrelax\-to\-as\fR" 4
  .IX Item "-mpass-mrelax-to-as"
  .PD 0
! .IP "\fB\-mno\-pass\-mrelax\-to\-as\fR" 4
  .IX Item "-mno-pass-mrelax-to-as"
  .PD
  Pass (do not pass) the \fB\-mrelax\fR or \fB\-mno\-relax\fR option
! to the assembler.  The default is determined during \s-1GCC\s0 build-time by
  detecting corresponding assembler support:
  \&\fB\-mpass\-mrelax\-to\-as\fR if the assembler supports the
  \&\fB\-mrelax\fR option, \fB\-mno\-pass\-mrelax\-to\-as\fR otherwise.
  This option is mostly useful for debugging, or interoperation with
! assemblers different from the build-time one.
  .PP
  \fIM32C Options\fR
  .IX Subsection "M32C Options"
! .IP "\fB\-mcpu=\fR\fIname\fR" 4
  .IX Item "-mcpu=name"
! Select the \s-1CPU\s0 for which code is generated.  \fIname\fR may be one of
  \&\fBr8c\fR for the R8C/Tiny series, \fBm16c\fR for the M16C (up to
  /60) series, \fBm32cm\fR for the M16C/80 series, or \fBm32c\fR for
  the M32C/80 series.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
  an alternate runtime library to be linked in which supports, for
  example, file I/O.  You must not use this option when generating
  programs that will run on real hardware; you must provide your own
  runtime library for whatever I/O functions are needed.
! .IP "\fB\-memregs=\fR\fInumber\fR" 4
  .IX Item "-memregs=number"
! Specifies the number of memory-based pseudo-registers \s-1GCC\s0 uses
! during code generation.  These pseudo-registers are used like real
! registers, so there is a tradeoff between \s-1GCC\s0's ability to fit the
  code into available registers, and the performance penalty of using
  memory instead of registers.  Note that all modules in a program must
  be compiled with the same value for this option.  Because of that, you
! must not use this option with \s-1GCC\s0's default runtime libraries.
  .PP
  \fIM32R/D Options\fR
  .IX Subsection "M32R/D Options"
  .PP
  These \fB\-m\fR options are defined for Renesas M32R/D architectures:
! .IP "\fB\-m32r2\fR" 4
  .IX Item "-m32r2"
  Generate code for the M32R/2.
! .IP "\fB\-m32rx\fR" 4
  .IX Item "-m32rx"
  Generate code for the M32R/X.
! .IP "\fB\-m32r\fR" 4
  .IX Item "-m32r"
  Generate code for the M32R.  This is the default.
! .IP "\fB\-mmodel=small\fR" 4
  .IX Item "-mmodel=small"
  Assume all objects live in the lower 16MB of memory (so that their addresses
  can be loaded with the \f(CW\*(C`ld24\*(C'\fR instruction), and assume all subroutines
--- 25013,25115 ----
  .Sp
  The default code model is \f(CW\*(C`normal\*(C'\fR.
  .RE
! .IP \fB\-mexplicit\-relocs\fR 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP \fB\-mno\-explicit\-relocs\fR 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Use or do not use assembler relocation operators when dealing with symbolic
  addresses.  The alternative is to use assembler macros instead, which may
  limit instruction scheduling but allow linker relaxation.  The default
  value for the option is determined with the assembler capability detected
! during GCC build\-time and the setting of \f(CW\*(C`\-mrelax\*(C'\fR:
  \&\f(CW\*(C`\-mexplicit\-relocs\*(C'\fR if the assembler supports relocation operators
  but \f(CW\*(C`\-mrelax\*(C'\fR is not enabled, \f(CW\*(C`\-mno\-explicit\-relocs\*(C'\fR otherwise.
! .IP \fB\-mdirect\-extern\-access\fR 4
  .IX Item "-mdirect-extern-access"
  .PD 0
! .IP \fB\-mno\-direct\-extern\-access\fR 4
  .IX Item "-mno-direct-extern-access"
  .PD
! Do not use or use GOT to access external symbols.  The default is
! \&\fB\-mno\-direct\-extern\-access\fR: GOT is used for external symbols with
  default visibility, but not used for other external symbols.
  .Sp
! With \fB\-mdirect\-extern\-access\fR, GOT is not used and all external
! symbols are PC\-relatively addressed.  It is \fBonly\fR suitable for
! environments where no dynamic link is performed, like firmwares, OS
  kernels, executables linked with \fB\-static\fR or \fB\-static\-pie\fR.
  \&\fB\-mdirect\-extern\-access\fR is not compatible with \fB\-fPIC\fR or
  \&\fB\-fpic\fR.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  .PD 0
! .IP \fB\-mno\-relax\fR 4
  .IX Item "-mno-relax"
  .PD
  Take (do not take) advantage of linker relaxations.  If
  \&\fB\-mpass\-mrelax\-to\-as\fR is enabled, this option is also passed to
! the assembler.  The default is determined during GCC build\-time by
  detecting corresponding assembler support:
  \&\fB\-mrelax\fR if the assembler supports both the \fB\-mrelax\fR
! option and the conditional branch relaxation (it\*(Aqs required or the
  \&\f(CW\*(C`.align\*(C'\fR directives and conditional branch instructions in the
! assembly code outputted by GCC may be rejected by the assembler because
  of a relocation overflow), \fB\-mno\-relax\fR otherwise.
! .IP \fB\-mpass\-mrelax\-to\-as\fR 4
  .IX Item "-mpass-mrelax-to-as"
  .PD 0
! .IP \fB\-mno\-pass\-mrelax\-to\-as\fR 4
  .IX Item "-mno-pass-mrelax-to-as"
  .PD
  Pass (do not pass) the \fB\-mrelax\fR or \fB\-mno\-relax\fR option
! to the assembler.  The default is determined during GCC build\-time by
  detecting corresponding assembler support:
  \&\fB\-mpass\-mrelax\-to\-as\fR if the assembler supports the
  \&\fB\-mrelax\fR option, \fB\-mno\-pass\-mrelax\-to\-as\fR otherwise.
  This option is mostly useful for debugging, or interoperation with
! assemblers different from the build\-time one.
  .PP
  \fIM32C Options\fR
  .IX Subsection "M32C Options"
! .IP \fB\-mcpu=\fR\fIname\fR 4
  .IX Item "-mcpu=name"
! Select the CPU for which code is generated.  \fIname\fR may be one of
  \&\fBr8c\fR for the R8C/Tiny series, \fBm16c\fR for the M16C (up to
  /60) series, \fBm32cm\fR for the M16C/80 series, or \fBm32c\fR for
  the M32C/80 series.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Specifies that the program will be run on the simulator.  This causes
  an alternate runtime library to be linked in which supports, for
  example, file I/O.  You must not use this option when generating
  programs that will run on real hardware; you must provide your own
  runtime library for whatever I/O functions are needed.
! .IP \fB\-memregs=\fR\fInumber\fR 4
  .IX Item "-memregs=number"
! Specifies the number of memory\-based pseudo\-registers GCC uses
! during code generation.  These pseudo\-registers are used like real
! registers, so there is a tradeoff between GCC\*(Aqs ability to fit the
  code into available registers, and the performance penalty of using
  memory instead of registers.  Note that all modules in a program must
  be compiled with the same value for this option.  Because of that, you
! must not use this option with GCC\*(Aqs default runtime libraries.
  .PP
  \fIM32R/D Options\fR
  .IX Subsection "M32R/D Options"
  .PP
  These \fB\-m\fR options are defined for Renesas M32R/D architectures:
! .IP \fB\-m32r2\fR 4
  .IX Item "-m32r2"
  Generate code for the M32R/2.
! .IP \fB\-m32rx\fR 4
  .IX Item "-m32rx"
  Generate code for the M32R/X.
! .IP \fB\-m32r\fR 4
  .IX Item "-m32r"
  Generate code for the M32R.  This is the default.
! .IP \fB\-mmodel=small\fR 4
  .IX Item "-mmodel=small"
  Assume all objects live in the lower 16MB of memory (so that their addresses
  can be loaded with the \f(CW\*(C`ld24\*(C'\fR instruction), and assume all subroutines
*************** This is the default.
*** 25187,25205 ****
  .Sp
  The addressability of a particular object can be set with the
  \&\f(CW\*(C`model\*(C'\fR attribute.
! .IP "\fB\-mmodel=medium\fR" 4
  .IX Item "-mmodel=medium"
  Assume objects may be anywhere in the 32\-bit address space (the compiler
  generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
  assume all subroutines are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
! .IP "\fB\-mmodel=large\fR" 4
  .IX Item "-mmodel=large"
  Assume objects may be anywhere in the 32\-bit address space (the compiler
  generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
  assume subroutines may not be reachable with the \f(CW\*(C`bl\*(C'\fR instruction
  (the compiler generates the much slower \f(CW\*(C`seth/add3/jl\*(C'\fR
  instruction sequence).
! .IP "\fB\-msdata=none\fR" 4
  .IX Item "-msdata=none"
  Disable use of the small data area.  Variables are put into
  one of \f(CW\*(C`.data\*(C'\fR, \f(CW\*(C`.bss\*(C'\fR, or \f(CW\*(C`.rodata\*(C'\fR (unless the
--- 25118,25136 ----
  .Sp
  The addressability of a particular object can be set with the
  \&\f(CW\*(C`model\*(C'\fR attribute.
! .IP \fB\-mmodel=medium\fR 4
  .IX Item "-mmodel=medium"
  Assume objects may be anywhere in the 32\-bit address space (the compiler
  generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
  assume all subroutines are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
! .IP \fB\-mmodel=large\fR 4
  .IX Item "-mmodel=large"
  Assume objects may be anywhere in the 32\-bit address space (the compiler
  generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
  assume subroutines may not be reachable with the \f(CW\*(C`bl\*(C'\fR instruction
  (the compiler generates the much slower \f(CW\*(C`seth/add3/jl\*(C'\fR
  instruction sequence).
! .IP \fB\-msdata=none\fR 4
  .IX Item "-msdata=none"
  Disable use of the small data area.  Variables are put into
  one of \f(CW\*(C`.data\*(C'\fR, \f(CW\*(C`.bss\*(C'\fR, or \f(CW\*(C`.rodata\*(C'\fR (unless the
*************** This is the default.
*** 25209,25267 ****
  The small data area consists of sections \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR.
  Objects may be explicitly put in the small data area with the
  \&\f(CW\*(C`section\*(C'\fR attribute using one of these sections.
! .IP "\fB\-msdata=sdata\fR" 4
  .IX Item "-msdata=sdata"
  Put small global and static data in the small data area, but do not
  generate special code to reference them.
! .IP "\fB\-msdata=use\fR" 4
  .IX Item "-msdata=use"
  Put small global and static data in the small data area, and generate
  special instructions to reference them.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  Put global and static objects less than or equal to \fInum\fR bytes
! into the small data or \s-1BSS\s0 sections instead of the normal data or \s-1BSS\s0
  sections.  The default value of \fInum\fR is 8.
  The \fB\-msdata\fR option must be set to one of \fBsdata\fR or \fBuse\fR
  for this option to have any effect.
  .Sp
  All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
  Compiling with different values of \fInum\fR may or may not work; if it
! doesn't the linker gives an error message\-\-\-incorrect code is not
  generated.
! .IP "\fB\-mdebug\fR" 4
  .IX Item "-mdebug"
  Makes the M32R\-specific code in the compiler display some statistics
  that might help in debugging programs.
! .IP "\fB\-malign\-loops\fR" 4
  .IX Item "-malign-loops"
  Align all loops to a 32\-byte boundary.
! .IP "\fB\-mno\-align\-loops\fR" 4
  .IX Item "-mno-align-loops"
  Do not enforce a 32\-byte alignment for loops.  This is the default.
! .IP "\fB\-missue\-rate=\fR\fInumber\fR" 4
  .IX Item "-missue-rate=number"
  Issue \fInumber\fR instructions per cycle.  \fInumber\fR can only be 1
  or 2.
! .IP "\fB\-mbranch\-cost=\fR\fInumber\fR" 4
  .IX Item "-mbranch-cost=number"
  \&\fInumber\fR can only be 1 or 2.  If it is 1 then branches are
  preferred over conditional code, if it is 2, then the opposite applies.
! .IP "\fB\-mflush\-trap=\fR\fInumber\fR" 4
  .IX Item "-mflush-trap=number"
  Specifies the trap number to use to flush the cache.  The default is
  12.  Valid numbers are between 0 and 15 inclusive.
! .IP "\fB\-mno\-flush\-trap\fR" 4
  .IX Item "-mno-flush-trap"
  Specifies that the cache cannot be flushed by using a trap.
! .IP "\fB\-mflush\-func=\fR\fIname\fR" 4
  .IX Item "-mflush-func=name"
  Specifies the name of the operating system function to call to flush
  the cache.  The default is \fB_flush_cache\fR, but a function call
  is only used if a trap is not available.
! .IP "\fB\-mno\-flush\-func\fR" 4
  .IX Item "-mno-flush-func"
! Indicates that there is no \s-1OS\s0 function for flushing the cache.
  .PP
  \fIM680x0 Options\fR
  .IX Subsection "M680x0 Options"
--- 25140,25198 ----
  The small data area consists of sections \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR.
  Objects may be explicitly put in the small data area with the
  \&\f(CW\*(C`section\*(C'\fR attribute using one of these sections.
! .IP \fB\-msdata=sdata\fR 4
  .IX Item "-msdata=sdata"
  Put small global and static data in the small data area, but do not
  generate special code to reference them.
! .IP \fB\-msdata=use\fR 4
  .IX Item "-msdata=use"
  Put small global and static data in the small data area, and generate
  special instructions to reference them.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  Put global and static objects less than or equal to \fInum\fR bytes
! into the small data or BSS sections instead of the normal data or BSS
  sections.  The default value of \fInum\fR is 8.
  The \fB\-msdata\fR option must be set to one of \fBsdata\fR or \fBuse\fR
  for this option to have any effect.
  .Sp
  All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
  Compiling with different values of \fInum\fR may or may not work; if it
! doesn\*(Aqt the linker gives an error message\-\-\-incorrect code is not
  generated.
! .IP \fB\-mdebug\fR 4
  .IX Item "-mdebug"
  Makes the M32R\-specific code in the compiler display some statistics
  that might help in debugging programs.
! .IP \fB\-malign\-loops\fR 4
  .IX Item "-malign-loops"
  Align all loops to a 32\-byte boundary.
! .IP \fB\-mno\-align\-loops\fR 4
  .IX Item "-mno-align-loops"
  Do not enforce a 32\-byte alignment for loops.  This is the default.
! .IP \fB\-missue\-rate=\fR\fInumber\fR 4
  .IX Item "-missue-rate=number"
  Issue \fInumber\fR instructions per cycle.  \fInumber\fR can only be 1
  or 2.
! .IP \fB\-mbranch\-cost=\fR\fInumber\fR 4
  .IX Item "-mbranch-cost=number"
  \&\fInumber\fR can only be 1 or 2.  If it is 1 then branches are
  preferred over conditional code, if it is 2, then the opposite applies.
! .IP \fB\-mflush\-trap=\fR\fInumber\fR 4
  .IX Item "-mflush-trap=number"
  Specifies the trap number to use to flush the cache.  The default is
  12.  Valid numbers are between 0 and 15 inclusive.
! .IP \fB\-mno\-flush\-trap\fR 4
  .IX Item "-mno-flush-trap"
  Specifies that the cache cannot be flushed by using a trap.
! .IP \fB\-mflush\-func=\fR\fIname\fR 4
  .IX Item "-mflush-func=name"
  Specifies the name of the operating system function to call to flush
  the cache.  The default is \fB_flush_cache\fR, but a function call
  is only used if a trap is not available.
! .IP \fB\-mno\-flush\-func\fR 4
  .IX Item "-mno-flush-func"
! Indicates that there is no OS function for flushing the cache.
  .PP
  \fIM680x0 Options\fR
  .IX Subsection "M680x0 Options"
*************** These are the \fB\-m\fR options defined
*** 25270,25293 ****
  The default settings depend on which architecture was selected when
  the compiler was configured; the defaults for the most common choices
  are given below.
! .IP "\fB\-march=\fR\fIarch\fR" 4
  .IX Item "-march=arch"
  Generate code for a specific M680x0 or ColdFire instruction set
  architecture.  Permissible values of \fIarch\fR for M680x0
  architectures are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
  \&\fB68030\fR, \fB68040\fR, \fB68060\fR and \fBcpu32\fR.  ColdFire
! architectures are selected according to Freescale's \s-1ISA\s0 classification
  and the permissible values are: \fBisaa\fR, \fBisaaplus\fR,
  \&\fBisab\fR and \fBisac\fR.
  .Sp
! \&\s-1GCC\s0 defines a macro \f(CW\*(C`_\|_mcf\f(CIarch\f(CW_\|_\*(C'\fR whenever it is generating
  code for a ColdFire target.  The \fIarch\fR in this macro is one of the
  \&\fB\-march\fR arguments given above.
  .Sp
  When used together, \fB\-march\fR and \fB\-mtune\fR select code
  that runs on a family of similar processors but that is optimized
  for a particular microarchitecture.
! .IP "\fB\-mcpu=\fR\fIcpu\fR" 4
  .IX Item "-mcpu=cpu"
  Generate code for a specific M680x0 or ColdFire processor.
  The M680x0 \fIcpu\fRs are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
--- 25201,25224 ----
  The default settings depend on which architecture was selected when
  the compiler was configured; the defaults for the most common choices
  are given below.
! .IP \fB\-march=\fR\fIarch\fR 4
  .IX Item "-march=arch"
  Generate code for a specific M680x0 or ColdFire instruction set
  architecture.  Permissible values of \fIarch\fR for M680x0
  architectures are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
  \&\fB68030\fR, \fB68040\fR, \fB68060\fR and \fBcpu32\fR.  ColdFire
! architectures are selected according to Freescale\*(Aqs ISA classification
  and the permissible values are: \fBisaa\fR, \fBisaaplus\fR,
  \&\fBisab\fR and \fBisac\fR.
  .Sp
! GCC defines a macro \f(CW\*(C`_\|_mcf\fR\f(CIarch\fR\f(CW_\|_\*(C'\fR whenever it is generating
  code for a ColdFire target.  The \fIarch\fR in this macro is one of the
  \&\fB\-march\fR arguments given above.
  .Sp
  When used together, \fB\-march\fR and \fB\-mtune\fR select code
  that runs on a family of similar processors but that is optimized
  for a particular microarchitecture.
! .IP \fB\-mcpu=\fR\fIcpu\fR 4
  .IX Item "-mcpu=cpu"
  Generate code for a specific M680x0 or ColdFire processor.
  The M680x0 \fIcpu\fRs are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
*************** below, which also classifies the CPUs in
*** 25344,25362 ****
  .IX Item "5407 : 5407"
  .IP "\fB5475\fR : \fB5470\fR \fB5471\fR \fB5472\fR \fB5473\fR \fB5474\fR \fB5475\fR \fB547x\fR \fB5480\fR \fB5481\fR \fB5482\fR \fB5483\fR \fB5484\fR \fB5485\fR" 4
  .IX Item "5475 : 5470 5471 5472 5473 5474 5475 547x 5480 5481 5482 5483 5484 5485"
  .RE
  .RS 4
- .PD
  .Sp
  \&\fB\-mcpu=\fR\fIcpu\fR overrides \fB\-march=\fR\fIarch\fR if
  \&\fIarch\fR is compatible with \fIcpu\fR.  Other combinations of
  \&\fB\-mcpu\fR and \fB\-march\fR are rejected.
  .Sp
! \&\s-1GCC\s0 defines the macro \f(CW\*(C`_\|_mcf_cpu_\f(CIcpu\f(CW\*(C'\fR when ColdFire target
! \&\fIcpu\fR is selected.  It also defines \f(CW\*(C`_\|_mcf_family_\f(CIfamily\f(CW\*(C'\fR,
  where the value of \fIfamily\fR is given by the table above.
  .RE
! .IP "\fB\-mtune=\fR\fItune\fR" 4
  .IX Item "-mtune=tune"
  Tune the code for a particular microarchitecture within the
  constraints set by \fB\-march\fR and \fB\-mcpu\fR.
--- 25275,25293 ----
  .IX Item "5407 : 5407"
  .IP "\fB5475\fR : \fB5470\fR \fB5471\fR \fB5472\fR \fB5473\fR \fB5474\fR \fB5475\fR \fB547x\fR \fB5480\fR \fB5481\fR \fB5482\fR \fB5483\fR \fB5484\fR \fB5485\fR" 4
  .IX Item "5475 : 5470 5471 5472 5473 5474 5475 547x 5480 5481 5482 5483 5484 5485"
+ .PD
  .RE
  .RS 4
  .Sp
  \&\fB\-mcpu=\fR\fIcpu\fR overrides \fB\-march=\fR\fIarch\fR if
  \&\fIarch\fR is compatible with \fIcpu\fR.  Other combinations of
  \&\fB\-mcpu\fR and \fB\-march\fR are rejected.
  .Sp
! GCC defines the macro \f(CW\*(C`_\|_mcf_cpu_\fR\f(CIcpu\fR\f(CW\*(C'\fR when ColdFire target
! \&\fIcpu\fR is selected.  It also defines \f(CW\*(C`_\|_mcf_family_\fR\f(CIfamily\fR\f(CW\*(C'\fR,
  where the value of \fIfamily\fR is given by the table above.
  .RE
! .IP \fB\-mtune=\fR\fItune\fR 4
  .IX Item "-mtune=tune"
  Tune the code for a particular microarchitecture within the
  constraints set by \fB\-march\fR and \fB\-mcpu\fR.
*************** to run relatively well on 68020, 68030 a
*** 25371,25418 ****
  as well.  These two options select the same tuning decisions as
  \&\fB\-m68020\-40\fR and \fB\-m68020\-60\fR respectively.
  .Sp
! \&\s-1GCC\s0 defines the macros \f(CW\*(C`_\|_mc\f(CIarch\f(CW\*(C'\fR and \f(CW\*(C`_\|_mc\f(CIarch\f(CW_\|_\*(C'\fR
  when tuning for 680x0 architecture \fIarch\fR.  It also defines
! \&\f(CW\*(C`mc\f(CIarch\f(CW\*(C'\fR unless either \fB\-ansi\fR or a non-GNU \fB\-std\fR
! option is used.  If \s-1GCC\s0 is tuning for a range of architectures,
  as selected by \fB\-mtune=68020\-40\fR or \fB\-mtune=68020\-60\fR,
  it defines the macros for every architecture in the range.
  .Sp
! \&\s-1GCC\s0 also defines the macro \f(CW\*(C`_\|_m\f(CIuarch\f(CW_\|_\*(C'\fR when tuning for
  ColdFire microarchitecture \fIuarch\fR, where \fIuarch\fR is one
  of the arguments given above.
! .IP "\fB\-m68000\fR" 4
  .IX Item "-m68000"
  .PD 0
! .IP "\fB\-mc68000\fR" 4
  .IX Item "-mc68000"
  .PD
  Generate output for a 68000.  This is the default
  when the compiler is configured for 68000\-based systems.
  It is equivalent to \fB\-march=68000\fR.
  .Sp
! Use this option for microcontrollers with a 68000 or \s-1EC000\s0 core,
  including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
! .IP "\fB\-m68010\fR" 4
  .IX Item "-m68010"
  Generate output for a 68010.  This is the default
  when the compiler is configured for 68010\-based systems.
  It is equivalent to \fB\-march=68010\fR.
! .IP "\fB\-m68020\fR" 4
  .IX Item "-m68020"
  .PD 0
! .IP "\fB\-mc68020\fR" 4
  .IX Item "-mc68020"
  .PD
  Generate output for a 68020.  This is the default
  when the compiler is configured for 68020\-based systems.
  It is equivalent to \fB\-march=68020\fR.
! .IP "\fB\-m68030\fR" 4
  .IX Item "-m68030"
  Generate output for a 68030.  This is the default when the compiler is
  configured for 68030\-based systems.  It is equivalent to
  \&\fB\-march=68030\fR.
! .IP "\fB\-m68040\fR" 4
  .IX Item "-m68040"
  Generate output for a 68040.  This is the default when the compiler is
  configured for 68040\-based systems.  It is equivalent to
--- 25302,25349 ----
  as well.  These two options select the same tuning decisions as
  \&\fB\-m68020\-40\fR and \fB\-m68020\-60\fR respectively.
  .Sp
! GCC defines the macros \f(CW\*(C`_\|_mc\fR\f(CIarch\fR\f(CW\*(C'\fR and \f(CW\*(C`_\|_mc\fR\f(CIarch\fR\f(CW_\|_\*(C'\fR
  when tuning for 680x0 architecture \fIarch\fR.  It also defines
! \&\f(CW\*(C`mc\fR\f(CIarch\fR\f(CW\*(C'\fR unless either \fB\-ansi\fR or a non\-GNU \fB\-std\fR
! option is used.  If GCC is tuning for a range of architectures,
  as selected by \fB\-mtune=68020\-40\fR or \fB\-mtune=68020\-60\fR,
  it defines the macros for every architecture in the range.
  .Sp
! GCC also defines the macro \f(CW\*(C`_\|_m\fR\f(CIuarch\fR\f(CW_\|_\*(C'\fR when tuning for
  ColdFire microarchitecture \fIuarch\fR, where \fIuarch\fR is one
  of the arguments given above.
! .IP \fB\-m68000\fR 4
  .IX Item "-m68000"
  .PD 0
! .IP \fB\-mc68000\fR 4
  .IX Item "-mc68000"
  .PD
  Generate output for a 68000.  This is the default
  when the compiler is configured for 68000\-based systems.
  It is equivalent to \fB\-march=68000\fR.
  .Sp
! Use this option for microcontrollers with a 68000 or EC000 core,
  including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
! .IP \fB\-m68010\fR 4
  .IX Item "-m68010"
  Generate output for a 68010.  This is the default
  when the compiler is configured for 68010\-based systems.
  It is equivalent to \fB\-march=68010\fR.
! .IP \fB\-m68020\fR 4
  .IX Item "-m68020"
  .PD 0
! .IP \fB\-mc68020\fR 4
  .IX Item "-mc68020"
  .PD
  Generate output for a 68020.  This is the default
  when the compiler is configured for 68020\-based systems.
  It is equivalent to \fB\-march=68020\fR.
! .IP \fB\-m68030\fR 4
  .IX Item "-m68030"
  Generate output for a 68030.  This is the default when the compiler is
  configured for 68030\-based systems.  It is equivalent to
  \&\fB\-march=68030\fR.
! .IP \fB\-m68040\fR 4
  .IX Item "-m68040"
  Generate output for a 68040.  This is the default when the compiler is
  configured for 68040\-based systems.  It is equivalent to
*************** configured for 68040\-based systems.  It
*** 25421,25427 ****
  This option inhibits the use of 68881/68882 instructions that have to be
  emulated by software on the 68040.  Use this option if your 68040 does not
  have code to emulate those instructions.
! .IP "\fB\-m68060\fR" 4
  .IX Item "-m68060"
  Generate output for a 68060.  This is the default when the compiler is
  configured for 68060\-based systems.  It is equivalent to
--- 25352,25358 ----
  This option inhibits the use of 68881/68882 instructions that have to be
  emulated by software on the 68040.  Use this option if your 68040 does not
  have code to emulate those instructions.
! .IP \fB\-m68060\fR 4
  .IX Item "-m68060"
  Generate output for a 68060.  This is the default when the compiler is
  configured for 68060\-based systems.  It is equivalent to
*************** configured for 68060\-based systems.  It
*** 25430,25477 ****
  This option inhibits the use of 68020 and 68881/68882 instructions that
  have to be emulated by software on the 68060.  Use this option if your 68060
  does not have code to emulate those instructions.
! .IP "\fB\-mcpu32\fR" 4
  .IX Item "-mcpu32"
! Generate output for a \s-1CPU32.\s0  This is the default
  when the compiler is configured for CPU32\-based systems.
  It is equivalent to \fB\-march=cpu32\fR.
  .Sp
  Use this option for microcontrollers with a
! \&\s-1CPU32\s0 or \s-1CPU32+\s0 core, including the 68330, 68331, 68332, 68333, 68334,
  68336, 68340, 68341, 68349 and 68360.
! .IP "\fB\-m5200\fR" 4
  .IX Item "-m5200"
! Generate output for a 520X ColdFire \s-1CPU.\s0  This is the default
  when the compiler is configured for 520X\-based systems.
  It is equivalent to \fB\-mcpu=5206\fR, and is now deprecated
  in favor of that option.
  .Sp
  Use this option for microcontroller with a 5200 core, including
! the \s-1MCF5202, MCF5203, MCF5204\s0 and \s-1MCF5206.\s0
! .IP "\fB\-m5206e\fR" 4
  .IX Item "-m5206e"
! Generate output for a 5206e ColdFire \s-1CPU.\s0  The option is now
  deprecated in favor of the equivalent \fB\-mcpu=5206e\fR.
! .IP "\fB\-m528x\fR" 4
  .IX Item "-m528x"
  Generate output for a member of the ColdFire 528X family.
  The option is now deprecated in favor of the equivalent
  \&\fB\-mcpu=528x\fR.
! .IP "\fB\-m5307\fR" 4
  .IX Item "-m5307"
! Generate output for a ColdFire 5307 \s-1CPU.\s0  The option is now deprecated
  in favor of the equivalent \fB\-mcpu=5307\fR.
! .IP "\fB\-m5407\fR" 4
  .IX Item "-m5407"
! Generate output for a ColdFire 5407 \s-1CPU.\s0  The option is now deprecated
  in favor of the equivalent \fB\-mcpu=5407\fR.
! .IP "\fB\-mcfv4e\fR" 4
  .IX Item "-mcfv4e"
! Generate output for a ColdFire V4e family \s-1CPU\s0 (e.g. 547x/548x).
! This includes use of hardware floating-point instructions.
  The option is equivalent to \fB\-mcpu=547x\fR, and is now
  deprecated in favor of that option.
! .IP "\fB\-m68020\-40\fR" 4
  .IX Item "-m68020-40"
  Generate output for a 68040, without using any of the new instructions.
  This results in code that can run relatively efficiently on either a
--- 25361,25408 ----
  This option inhibits the use of 68020 and 68881/68882 instructions that
  have to be emulated by software on the 68060.  Use this option if your 68060
  does not have code to emulate those instructions.
! .IP \fB\-mcpu32\fR 4
  .IX Item "-mcpu32"
! Generate output for a CPU32.  This is the default
  when the compiler is configured for CPU32\-based systems.
  It is equivalent to \fB\-march=cpu32\fR.
  .Sp
  Use this option for microcontrollers with a
! CPU32 or CPU32+ core, including the 68330, 68331, 68332, 68333, 68334,
  68336, 68340, 68341, 68349 and 68360.
! .IP \fB\-m5200\fR 4
  .IX Item "-m5200"
! Generate output for a 520X ColdFire CPU.  This is the default
  when the compiler is configured for 520X\-based systems.
  It is equivalent to \fB\-mcpu=5206\fR, and is now deprecated
  in favor of that option.
  .Sp
  Use this option for microcontroller with a 5200 core, including
! the MCF5202, MCF5203, MCF5204 and MCF5206.
! .IP \fB\-m5206e\fR 4
  .IX Item "-m5206e"
! Generate output for a 5206e ColdFire CPU.  The option is now
  deprecated in favor of the equivalent \fB\-mcpu=5206e\fR.
! .IP \fB\-m528x\fR 4
  .IX Item "-m528x"
  Generate output for a member of the ColdFire 528X family.
  The option is now deprecated in favor of the equivalent
  \&\fB\-mcpu=528x\fR.
! .IP \fB\-m5307\fR 4
  .IX Item "-m5307"
! Generate output for a ColdFire 5307 CPU.  The option is now deprecated
  in favor of the equivalent \fB\-mcpu=5307\fR.
! .IP \fB\-m5407\fR 4
  .IX Item "-m5407"
! Generate output for a ColdFire 5407 CPU.  The option is now deprecated
  in favor of the equivalent \fB\-mcpu=5407\fR.
! .IP \fB\-mcfv4e\fR 4
  .IX Item "-mcfv4e"
! Generate output for a ColdFire V4e family CPU (e.g. 547x/548x).
! This includes use of hardware floating\-point instructions.
  The option is equivalent to \fB\-mcpu=547x\fR, and is now
  deprecated in favor of that option.
! .IP \fB\-m68020\-40\fR 4
  .IX Item "-m68020-40"
  Generate output for a 68040, without using any of the new instructions.
  This results in code that can run relatively efficiently on either a
*************** This results in code that can run relati
*** 25479,25485 ****
  68881 instructions that are emulated on the 68040.
  .Sp
  The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-40\fR.
! .IP "\fB\-m68020\-60\fR" 4
  .IX Item "-m68020-60"
  Generate output for a 68060, without using any of the new instructions.
  This results in code that can run relatively efficiently on either a
--- 25410,25416 ----
  68881 instructions that are emulated on the 68040.
  .Sp
  The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-40\fR.
! .IP \fB\-m68020\-60\fR 4
  .IX Item "-m68020-60"
  Generate output for a 68060, without using any of the new instructions.
  This results in code that can run relatively efficiently on either a
*************** This results in code that can run relati
*** 25487,25546 ****
  68881 instructions that are emulated on the 68060.
  .Sp
  The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-60\fR.
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD 0
! .IP "\fB\-m68881\fR" 4
  .IX Item "-m68881"
  .PD
! Generate floating-point instructions.  This is the default for 68020
! and above, and for ColdFire devices that have an \s-1FPU.\s0  It defines the
  macro \f(CW\*(C`_\|_HAVE_68881_\|_\*(C'\fR on M680x0 targets and \f(CW\*(C`_\|_mcffpu_\|_\*(C'\fR
  on ColdFire targets.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
! Do not generate floating-point instructions; use library calls instead.
  This is the default for 68000, 68010, and 68832 targets.  It is also
! the default for ColdFire devices that have no \s-1FPU.\s0
! .IP "\fB\-mdiv\fR" 4
  .IX Item "-mdiv"
  .PD 0
! .IP "\fB\-mno\-div\fR" 4
  .IX Item "-mno-div"
  .PD
  Generate (do not generate) ColdFire hardware divide and remainder
  instructions.  If \fB\-march\fR is used without \fB\-mcpu\fR,
! the default is \*(L"on\*(R" for ColdFire architectures and \*(L"off\*(R" for M680x0
! architectures.  Otherwise, the default is taken from the target \s-1CPU\s0
! (either the default \s-1CPU,\s0 or the one specified by \fB\-mcpu\fR).  For
! example, the default is \*(L"off\*(R" for \fB\-mcpu=5206\fR and \*(L"on\*(R" for
  \&\fB\-mcpu=5206e\fR.
  .Sp
! \&\s-1GCC\s0 defines the macro \f(CW\*(C`_\|_mcfhwdiv_\|_\*(C'\fR when this option is enabled.
! .IP "\fB\-mshort\fR" 4
  .IX Item "-mshort"
  Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR.
  Additionally, parameters passed on the stack are also aligned to a
! 16\-bit boundary even on targets whose \s-1API\s0 mandates promotion to 32\-bit.
! .IP "\fB\-mno\-short\fR" 4
  .IX Item "-mno-short"
  Do not consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide.  This is the default.
! .IP "\fB\-mnobitfield\fR" 4
  .IX Item "-mnobitfield"
  .PD 0
! .IP "\fB\-mno\-bitfield\fR" 4
  .IX Item "-mno-bitfield"
  .PD
! Do not use the bit-field instructions.  The \fB\-m68000\fR, \fB\-mcpu32\fR
  and \fB\-m5200\fR options imply \fB\-mnobitfield\fR.
! .IP "\fB\-mbitfield\fR" 4
  .IX Item "-mbitfield"
! Do use the bit-field instructions.  The \fB\-m68020\fR option implies
  \&\fB\-mbitfield\fR.  This is the default if you use a configuration
  designed for a 68020.
! .IP "\fB\-mrtd\fR" 4
  .IX Item "-mrtd"
! Use a different function-calling convention, in which functions
  that take a fixed number of arguments return with the \f(CW\*(C`rtd\*(C'\fR
  instruction, which pops their arguments while returning.  This
  saves one instruction in the caller since there is no need to pop
--- 25418,25477 ----
  68881 instructions that are emulated on the 68060.
  .Sp
  The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-60\fR.
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD 0
! .IP \fB\-m68881\fR 4
  .IX Item "-m68881"
  .PD
! Generate floating\-point instructions.  This is the default for 68020
! and above, and for ColdFire devices that have an FPU.  It defines the
  macro \f(CW\*(C`_\|_HAVE_68881_\|_\*(C'\fR on M680x0 targets and \f(CW\*(C`_\|_mcffpu_\|_\*(C'\fR
  on ColdFire targets.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
! Do not generate floating\-point instructions; use library calls instead.
  This is the default for 68000, 68010, and 68832 targets.  It is also
! the default for ColdFire devices that have no FPU.
! .IP \fB\-mdiv\fR 4
  .IX Item "-mdiv"
  .PD 0
! .IP \fB\-mno\-div\fR 4
  .IX Item "-mno-div"
  .PD
  Generate (do not generate) ColdFire hardware divide and remainder
  instructions.  If \fB\-march\fR is used without \fB\-mcpu\fR,
! the default is "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 \fB\-mcpu\fR).  For
! example, the default is "off" for \fB\-mcpu=5206\fR and "on" for
  \&\fB\-mcpu=5206e\fR.
  .Sp
! GCC defines the macro \f(CW\*(C`_\|_mcfhwdiv_\|_\*(C'\fR when this option is enabled.
! .IP \fB\-mshort\fR 4
  .IX Item "-mshort"
  Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR.
  Additionally, parameters passed on the stack are also aligned to a
! 16\-bit boundary even on targets whose API mandates promotion to 32\-bit.
! .IP \fB\-mno\-short\fR 4
  .IX Item "-mno-short"
  Do not consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide.  This is the default.
! .IP \fB\-mnobitfield\fR 4
  .IX Item "-mnobitfield"
  .PD 0
! .IP \fB\-mno\-bitfield\fR 4
  .IX Item "-mno-bitfield"
  .PD
! Do not use the bit\-field instructions.  The \fB\-m68000\fR, \fB\-mcpu32\fR
  and \fB\-m5200\fR options imply \fB\-mnobitfield\fR.
! .IP \fB\-mbitfield\fR 4
  .IX Item "-mbitfield"
! Do use the bit\-field instructions.  The \fB\-m68020\fR option implies
  \&\fB\-mbitfield\fR.  This is the default if you use a configuration
  designed for a 68020.
! .IP \fB\-mrtd\fR 4
  .IX Item "-mrtd"
! Use a different function\-calling convention, in which functions
  that take a fixed number of arguments return with the \f(CW\*(C`rtd\*(C'\fR
  instruction, which pops their arguments while returning.  This
  saves one instruction in the caller since there is no need to pop
*************** function with too many arguments.  (Norm
*** 25560,25635 ****
  harmlessly ignored.)
  .Sp
  The \f(CW\*(C`rtd\*(C'\fR instruction is supported by the 68010, 68020, 68030,
! 68040, 68060 and \s-1CPU32\s0 processors, but not by the 68000 or 5200.
  .Sp
  The default is \fB\-mno\-rtd\fR.
! .IP "\fB\-malign\-int\fR" 4
  .IX Item "-malign-int"
  .PD 0
! .IP "\fB\-mno\-align\-int\fR" 4
  .IX Item "-mno-align-int"
  .PD
! Control whether \s-1GCC\s0 aligns \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`long long\*(C'\fR,
  \&\f(CW\*(C`float\*(C'\fR, \f(CW\*(C`double\*(C'\fR, and \f(CW\*(C`long double\*(C'\fR variables on a 32\-bit
  boundary (\fB\-malign\-int\fR) or a 16\-bit boundary (\fB\-mno\-align\-int\fR).
  Aligning variables on 32\-bit boundaries produces code that runs somewhat
  faster on processors with 32\-bit busses at the expense of more memory.
  .Sp
! \&\fBWarning:\fR if you use the \fB\-malign\-int\fR switch, \s-1GCC\s0
  aligns structures containing the above types differently than
  most published application binary interface specifications for the m68k.
  .Sp
! Use the pc-relative addressing mode of the 68000 directly, instead of
  using a global offset table.  At present, this option implies \fB\-fpic\fR,
! allowing at most a 16\-bit offset for pc-relative addressing.  \fB\-fPIC\fR is
  not presently supported with \fB\-mpcrel\fR, though this could be supported for
  68020 and higher processors.
! .IP "\fB\-mno\-strict\-align\fR" 4
  .IX Item "-mno-strict-align"
  .PD 0
! .IP "\fB\-mstrict\-align\fR" 4
  .IX Item "-mstrict-align"
  .PD
  Do not (do) assume that unaligned memory references are handled by
  the system.
! .IP "\fB\-msep\-data\fR" 4
  .IX Item "-msep-data"
  Generate code that allows the data segment to be located in a different
! area of memory from the text segment.  This allows for execute-in-place in
  an environment without virtual memory management.  This option implies
  \&\fB\-fPIC\fR.
! .IP "\fB\-mno\-sep\-data\fR" 4
  .IX Item "-mno-sep-data"
  Generate code that assumes that the data segment follows the text segment.
  This is the default.
! .IP "\fB\-mid\-shared\-library\fR" 4
  .IX Item "-mid-shared-library"
! Generate code that supports shared libraries via the library \s-1ID\s0 method.
! This allows for execute-in-place and shared libraries in an environment
  without virtual memory management.  This option implies \fB\-fPIC\fR.
! .IP "\fB\-mno\-id\-shared\-library\fR" 4
  .IX Item "-mno-id-shared-library"
! Generate code that doesn't assume ID-based shared libraries are being used.
  This is the default.
! .IP "\fB\-mshared\-library\-id=n\fR" 4
  .IX Item "-mshared-library-id=n"
! Specifies the identification number of the ID-based shared library being
  compiled.  Specifying a value of 0 generates more compact code; specifying
  other values forces the allocation of that number to the current
! library, but is no more space\- or time-efficient than omitting this option.
! .IP "\fB\-mxgot\fR" 4
  .IX Item "-mxgot"
  .PD 0
! .IP "\fB\-mno\-xgot\fR" 4
  .IX Item "-mno-xgot"
  .PD
! When generating position-independent code for ColdFire, generate code
! that works if the \s-1GOT\s0 has more than 8192 entries.  This code is
  larger and slower than code generated without this option.  On M680x0
  processors, this option is not needed; \fB\-fPIC\fR suffices.
  .Sp
! \&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT.\s0
! While this is relatively efficient, it only works if the \s-1GOT\s0
  is smaller than about 64k.  Anything larger causes the linker
  to report an error such as:
  .Sp
--- 25491,25566 ----
  harmlessly ignored.)
  .Sp
  The \f(CW\*(C`rtd\*(C'\fR instruction is supported by the 68010, 68020, 68030,
! 68040, 68060 and CPU32 processors, but not by the 68000 or 5200.
  .Sp
  The default is \fB\-mno\-rtd\fR.
! .IP \fB\-malign\-int\fR 4
  .IX Item "-malign-int"
  .PD 0
! .IP \fB\-mno\-align\-int\fR 4
  .IX Item "-mno-align-int"
  .PD
! Control whether GCC aligns \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`long long\*(C'\fR,
  \&\f(CW\*(C`float\*(C'\fR, \f(CW\*(C`double\*(C'\fR, and \f(CW\*(C`long double\*(C'\fR variables on a 32\-bit
  boundary (\fB\-malign\-int\fR) or a 16\-bit boundary (\fB\-mno\-align\-int\fR).
  Aligning variables on 32\-bit boundaries produces code that runs somewhat
  faster on processors with 32\-bit busses at the expense of more memory.
  .Sp
! \&\fBWarning:\fR if you use the \fB\-malign\-int\fR switch, GCC
  aligns structures containing the above types differently than
  most published application binary interface specifications for the m68k.
  .Sp
! Use the pc\-relative addressing mode of the 68000 directly, instead of
  using a global offset table.  At present, this option implies \fB\-fpic\fR,
! allowing at most a 16\-bit offset for pc\-relative addressing.  \fB\-fPIC\fR is
  not presently supported with \fB\-mpcrel\fR, though this could be supported for
  68020 and higher processors.
! .IP \fB\-mno\-strict\-align\fR 4
  .IX Item "-mno-strict-align"
  .PD 0
! .IP \fB\-mstrict\-align\fR 4
  .IX Item "-mstrict-align"
  .PD
  Do not (do) assume that unaligned memory references are handled by
  the system.
! .IP \fB\-msep\-data\fR 4
  .IX Item "-msep-data"
  Generate code that allows the data segment to be located in a different
! area of memory from the text segment.  This allows for execute\-in\-place in
  an environment without virtual memory management.  This option implies
  \&\fB\-fPIC\fR.
! .IP \fB\-mno\-sep\-data\fR 4
  .IX Item "-mno-sep-data"
  Generate code that assumes that the data segment follows the text segment.
  This is the default.
! .IP \fB\-mid\-shared\-library\fR 4
  .IX Item "-mid-shared-library"
! Generate code that supports shared libraries via the library ID method.
! This allows for execute\-in\-place and shared libraries in an environment
  without virtual memory management.  This option implies \fB\-fPIC\fR.
! .IP \fB\-mno\-id\-shared\-library\fR 4
  .IX Item "-mno-id-shared-library"
! Generate code that doesn\*(Aqt assume ID\-based shared libraries are being used.
  This is the default.
! .IP \fB\-mshared\-library\-id=n\fR 4
  .IX Item "-mshared-library-id=n"
! Specifies the identification number of the ID\-based shared library being
  compiled.  Specifying a value of 0 generates more compact code; specifying
  other values forces the allocation of that number to the current
! library, but is no more space\- or time\-efficient than omitting this option.
! .IP \fB\-mxgot\fR 4
  .IX Item "-mxgot"
  .PD 0
! .IP \fB\-mno\-xgot\fR 4
  .IX Item "-mno-xgot"
  .PD
! When generating position\-independent code for ColdFire, generate code
! that works if the 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; \fB\-fPIC\fR suffices.
  .Sp
! 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:
  .Sp
*************** It should then work with very large GOTs
*** 25642,25655 ****
  \&\fB\-mxgot\fR is less efficient, since it takes 4 instructions to fetch
  the value of a global symbol.
  .Sp
! Note that some linkers, including newer versions of the \s-1GNU\s0 linker,
! can create multiple GOTs and sort \s-1GOT\s0 entries.  If you have such a linker,
  you should only need to use \fB\-mxgot\fR when compiling a single
! object file that accesses more than 8192 \s-1GOT\s0 entries.  Very few do.
  .Sp
! These options have no effect unless \s-1GCC\s0 is generating
! position-independent code.
! .IP "\fB\-mlong\-jump\-table\-offsets\fR" 4
  .IX Item "-mlong-jump-table-offsets"
  Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables.  The default is to use
  16\-bit offsets.
--- 25573,25586 ----
  \&\fB\-mxgot\fR is less efficient, since it takes 4 instructions to fetch
  the value of a global symbol.
  .Sp
! Note that some linkers, including newer versions of the GNU linker,
! can create multiple GOTs and sort GOT entries.  If you have such a linker,
  you should only need to use \fB\-mxgot\fR when compiling a single
! object file that accesses more than 8192 GOT entries.  Very few do.
  .Sp
! These options have no effect unless GCC is generating
! position\-independent code.
! .IP \fB\-mlong\-jump\-table\-offsets\fR 4
  .IX Item "-mlong-jump-table-offsets"
  Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables.  The default is to use
  16\-bit offsets.
*************** Use 32\-bit offsets in \f(CW\*(C`switch\
*** 25659,25733 ****
  .PP
  These are the \fB\-m\fR options defined for the Motorola M*Core
  processors.
! .IP "\fB\-mhardlit\fR" 4
  .IX Item "-mhardlit"
  .PD 0
! .IP "\fB\-mno\-hardlit\fR" 4
  .IX Item "-mno-hardlit"
  .PD
  Inline constants into the code stream if it can be done in two
  instructions or less.
! .IP "\fB\-mdiv\fR" 4
  .IX Item "-mdiv"
  .PD 0
! .IP "\fB\-mno\-div\fR" 4
  .IX Item "-mno-div"
  .PD
  Use the divide instruction.  (Enabled by default).
! .IP "\fB\-mrelax\-immediate\fR" 4
  .IX Item "-mrelax-immediate"
  .PD 0
! .IP "\fB\-mno\-relax\-immediate\fR" 4
  .IX Item "-mno-relax-immediate"
  .PD
! Allow arbitrary-sized immediates in bit operations.
! .IP "\fB\-mwide\-bitfields\fR" 4
  .IX Item "-mwide-bitfields"
  .PD 0
! .IP "\fB\-mno\-wide\-bitfields\fR" 4
  .IX Item "-mno-wide-bitfields"
  .PD
! Always treat bit-fields as \f(CW\*(C`int\*(C'\fR\-sized.
! .IP "\fB\-m4byte\-functions\fR" 4
  .IX Item "-m4byte-functions"
  .PD 0
! .IP "\fB\-mno\-4byte\-functions\fR" 4
  .IX Item "-mno-4byte-functions"
  .PD
  Force all functions to be aligned to a 4\-byte boundary.
! .IP "\fB\-mcallgraph\-data\fR" 4
  .IX Item "-mcallgraph-data"
  .PD 0
! .IP "\fB\-mno\-callgraph\-data\fR" 4
  .IX Item "-mno-callgraph-data"
  .PD
  Emit callgraph information.
! .IP "\fB\-mslow\-bytes\fR" 4
  .IX Item "-mslow-bytes"
  .PD 0
! .IP "\fB\-mno\-slow\-bytes\fR" 4
  .IX Item "-mno-slow-bytes"
  .PD
  Prefer word access when reading byte quantities.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
  .PD 0
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
  .PD
! Generate code for a little-endian target.
! .IP "\fB\-m210\fR" 4
  .IX Item "-m210"
  .PD 0
! .IP "\fB\-m340\fR" 4
  .IX Item "-m340"
  .PD
  Generate code for the 210 processor.
! .IP "\fB\-mno\-lsim\fR" 4
  .IX Item "-mno-lsim"
  Assume that runtime support has been provided and so omit the
  simulator library (\fIlibsim.a)\fR from the linker command line.
! .IP "\fB\-mstack\-increment=\fR\fIsize\fR" 4
  .IX Item "-mstack-increment=size"
  Set the maximum amount for a single stack increment operation.  Large
  values can increase the speed of programs that contain functions
--- 25590,25664 ----
  .PP
  These are the \fB\-m\fR options defined for the Motorola M*Core
  processors.
! .IP \fB\-mhardlit\fR 4
  .IX Item "-mhardlit"
  .PD 0
! .IP \fB\-mno\-hardlit\fR 4
  .IX Item "-mno-hardlit"
  .PD
  Inline constants into the code stream if it can be done in two
  instructions or less.
! .IP \fB\-mdiv\fR 4
  .IX Item "-mdiv"
  .PD 0
! .IP \fB\-mno\-div\fR 4
  .IX Item "-mno-div"
  .PD
  Use the divide instruction.  (Enabled by default).
! .IP \fB\-mrelax\-immediate\fR 4
  .IX Item "-mrelax-immediate"
  .PD 0
! .IP \fB\-mno\-relax\-immediate\fR 4
  .IX Item "-mno-relax-immediate"
  .PD
! Allow arbitrary\-sized immediates in bit operations.
! .IP \fB\-mwide\-bitfields\fR 4
  .IX Item "-mwide-bitfields"
  .PD 0
! .IP \fB\-mno\-wide\-bitfields\fR 4
  .IX Item "-mno-wide-bitfields"
  .PD
! Always treat bit\-fields as \f(CW\*(C`int\*(C'\fR\-sized.
! .IP \fB\-m4byte\-functions\fR 4
  .IX Item "-m4byte-functions"
  .PD 0
! .IP \fB\-mno\-4byte\-functions\fR 4
  .IX Item "-mno-4byte-functions"
  .PD
  Force all functions to be aligned to a 4\-byte boundary.
! .IP \fB\-mcallgraph\-data\fR 4
  .IX Item "-mcallgraph-data"
  .PD 0
! .IP \fB\-mno\-callgraph\-data\fR 4
  .IX Item "-mno-callgraph-data"
  .PD
  Emit callgraph information.
! .IP \fB\-mslow\-bytes\fR 4
  .IX Item "-mslow-bytes"
  .PD 0
! .IP \fB\-mno\-slow\-bytes\fR 4
  .IX Item "-mno-slow-bytes"
  .PD
  Prefer word access when reading byte quantities.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
  .PD 0
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
  .PD
! Generate code for a little\-endian target.
! .IP \fB\-m210\fR 4
  .IX Item "-m210"
  .PD 0
! .IP \fB\-m340\fR 4
  .IX Item "-m340"
  .PD
  Generate code for the 210 processor.
! .IP \fB\-mno\-lsim\fR 4
  .IX Item "-mno-lsim"
  Assume that runtime support has been provided and so omit the
  simulator library (\fIlibsim.a)\fR from the linker command line.
! .IP \fB\-mstack\-increment=\fR\fIsize\fR 4
  .IX Item "-mstack-increment=size"
  Set the maximum amount for a single stack increment operation.  Large
  values can increase the speed of programs that contain functions
*************** value is 0x1000.
*** 25737,25819 ****
  .PP
  \fIMicroBlaze Options\fR
  .IX Subsection "MicroBlaze Options"
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  Use software emulation for floating point (default).
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
! Use hardware floating-point instructions.
! .IP "\fB\-mmemcpy\fR" 4
  .IX Item "-mmemcpy"
  Do not optimize block moves, use \f(CW\*(C`memcpy\*(C'\fR.
! .IP "\fB\-mno\-clearbss\fR" 4
  .IX Item "-mno-clearbss"
  This option is deprecated.  Use \fB\-fno\-zero\-initialized\-in\-bss\fR instead.
! .IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
  .IX Item "-mcpu=cpu-type"
! Use features of, and schedule code for, the given \s-1CPU.\s0
! Supported values are in the format \fBv\fR\fIX\fR\fB.\fR\fI\s-1YY\s0\fR\fB.\fR\fIZ\fR,
! where \fIX\fR is a major version, \fI\s-1YY\s0\fR is the minor version, and
  \&\fIZ\fR is compatibility code.  Example values are \fBv3.00.a\fR,
  \&\fBv4.00.b\fR, \fBv5.00.a\fR, \fBv5.00.b\fR, \fBv6.00.a\fR.
! .IP "\fB\-mxl\-soft\-mul\fR" 4
  .IX Item "-mxl-soft-mul"
  Use software multiply emulation (default).
! .IP "\fB\-mxl\-soft\-div\fR" 4
  .IX Item "-mxl-soft-div"
  Use software emulation for divides (default).
! .IP "\fB\-mxl\-barrel\-shift\fR" 4
  .IX Item "-mxl-barrel-shift"
  Use the hardware barrel shifter.
! .IP "\fB\-mxl\-pattern\-compare\fR" 4
  .IX Item "-mxl-pattern-compare"
  Use pattern compare instructions.
! .IP "\fB\-msmall\-divides\fR" 4
  .IX Item "-msmall-divides"
  Use table lookup optimization for small signed integer divisions.
! .IP "\fB\-mxl\-stack\-check\fR" 4
  .IX Item "-mxl-stack-check"
  This option is deprecated.  Use \fB\-fstack\-check\fR instead.
! .IP "\fB\-mxl\-gp\-opt\fR" 4
  .IX Item "-mxl-gp-opt"
! Use GP-relative \f(CW\*(C`.sdata\*(C'\fR/\f(CW\*(C`.sbss\*(C'\fR sections.
! .IP "\fB\-mxl\-multiply\-high\fR" 4
  .IX Item "-mxl-multiply-high"
  Use multiply high instructions for high part of 32x32 multiply.
! .IP "\fB\-mxl\-float\-convert\fR" 4
  .IX Item "-mxl-float-convert"
! Use hardware floating-point conversion instructions.
! .IP "\fB\-mxl\-float\-sqrt\fR" 4
  .IX Item "-mxl-float-sqrt"
! Use hardware floating-point square root instruction.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code for a big-endian target.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code for a little-endian target.
! .IP "\fB\-mxl\-reorder\fR" 4
  .IX Item "-mxl-reorder"
  Use reorder instructions (swap and byte reversed load/store).
! .IP "\fB\-mxl\-mode\-\fR\fIapp-model\fR" 4
  .IX Item "-mxl-mode-app-model"
! Select application model \fIapp-model\fR.  Valid models are
  .RS 4
! .IP "\fBexecutable\fR" 4
  .IX Item "executable"
  normal executable (default), uses startup code \fIcrt0.o\fR.
! .IP "\fBxmdstub\fR" 4
  .IX Item "xmdstub"
! for use with Xilinx Microprocessor Debugger (\s-1XMD\s0) based
  software intrusive debug agent called xmdstub. This uses startup file
  \&\fIcrt1.o\fR and sets the start address of the program to 0x800.
! .IP "\fBbootstrap\fR" 4
  .IX Item "bootstrap"
  for applications that are loaded using a bootloader.
  This model uses startup file \fIcrt2.o\fR which does not contain a processor
  reset vector handler. This is suitable for transferring control on a
  processor reset to the bootloader rather than the application.
! .IP "\fBnovectors\fR" 4
  .IX Item "novectors"
  for applications that do not require any of the
  MicroBlaze vectors. This option may be useful for applications running
--- 25668,25750 ----
  .PP
  \fIMicroBlaze Options\fR
  .IX Subsection "MicroBlaze Options"
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  Use software emulation for floating point (default).
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
! Use hardware floating\-point instructions.
! .IP \fB\-mmemcpy\fR 4
  .IX Item "-mmemcpy"
  Do not optimize block moves, use \f(CW\*(C`memcpy\*(C'\fR.
! .IP \fB\-mno\-clearbss\fR 4
  .IX Item "-mno-clearbss"
  This option is deprecated.  Use \fB\-fno\-zero\-initialized\-in\-bss\fR instead.
! .IP \fB\-mcpu=\fR\fIcpu\-type\fR 4
  .IX Item "-mcpu=cpu-type"
! Use features of, and schedule code for, the given CPU.
! Supported values are in the format \fBv\fR\fIX\fR\fB.\fR\fIYY\fR\fB.\fR\fIZ\fR,
! where \fIX\fR is a major version, \fIYY\fR is the minor version, and
  \&\fIZ\fR is compatibility code.  Example values are \fBv3.00.a\fR,
  \&\fBv4.00.b\fR, \fBv5.00.a\fR, \fBv5.00.b\fR, \fBv6.00.a\fR.
! .IP \fB\-mxl\-soft\-mul\fR 4
  .IX Item "-mxl-soft-mul"
  Use software multiply emulation (default).
! .IP \fB\-mxl\-soft\-div\fR 4
  .IX Item "-mxl-soft-div"
  Use software emulation for divides (default).
! .IP \fB\-mxl\-barrel\-shift\fR 4
  .IX Item "-mxl-barrel-shift"
  Use the hardware barrel shifter.
! .IP \fB\-mxl\-pattern\-compare\fR 4
  .IX Item "-mxl-pattern-compare"
  Use pattern compare instructions.
! .IP \fB\-msmall\-divides\fR 4
  .IX Item "-msmall-divides"
  Use table lookup optimization for small signed integer divisions.
! .IP \fB\-mxl\-stack\-check\fR 4
  .IX Item "-mxl-stack-check"
  This option is deprecated.  Use \fB\-fstack\-check\fR instead.
! .IP \fB\-mxl\-gp\-opt\fR 4
  .IX Item "-mxl-gp-opt"
! Use GP\-relative \f(CW\*(C`.sdata\*(C'\fR/\f(CW\*(C`.sbss\*(C'\fR sections.
! .IP \fB\-mxl\-multiply\-high\fR 4
  .IX Item "-mxl-multiply-high"
  Use multiply high instructions for high part of 32x32 multiply.
! .IP \fB\-mxl\-float\-convert\fR 4
  .IX Item "-mxl-float-convert"
! Use hardware floating\-point conversion instructions.
! .IP \fB\-mxl\-float\-sqrt\fR 4
  .IX Item "-mxl-float-sqrt"
! Use hardware floating\-point square root instruction.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code for a big\-endian target.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code for a little\-endian target.
! .IP \fB\-mxl\-reorder\fR 4
  .IX Item "-mxl-reorder"
  Use reorder instructions (swap and byte reversed load/store).
! .IP \fB\-mxl\-mode\-\fR\fIapp\-model\fR 4
  .IX Item "-mxl-mode-app-model"
! Select application model \fIapp\-model\fR.  Valid models are
  .RS 4
! .IP \fBexecutable\fR 4
  .IX Item "executable"
  normal executable (default), uses startup code \fIcrt0.o\fR.
! .IP \fBxmdstub\fR 4
  .IX Item "xmdstub"
! for use with Xilinx Microprocessor Debugger (XMD) based
  software intrusive debug agent called xmdstub. This uses startup file
  \&\fIcrt1.o\fR and sets the start address of the program to 0x800.
! .IP \fBbootstrap\fR 4
  .IX Item "bootstrap"
  for applications that are loaded using a bootloader.
  This model uses startup file \fIcrt2.o\fR which does not contain a processor
  reset vector handler. This is suitable for transferring control on a
  processor reset to the bootloader rather than the application.
! .IP \fBnovectors\fR 4
  .IX Item "novectors"
  for applications that do not require any of the
  MicroBlaze vectors. This option may be useful for applications running
*************** within a monitoring application. This mo
*** 25821,25849 ****
  .RE
  .RS 4
  .Sp
! Option \fB\-xl\-mode\-\fR\fIapp-model\fR is a deprecated alias for
! \&\fB\-mxl\-mode\-\fR\fIapp-model\fR.
  .RE
! .IP "\fB\-mpic\-data\-is\-text\-relative\fR" 4
  .IX Item "-mpic-data-is-text-relative"
  Assume that the displacement between the text and data segments is fixed
  at static link time.  This allows data to be referenced by offset from start of
! text address instead of \s-1GOT\s0 since PC-relative addressing is not supported.
  .PP
! \fI\s-1MIPS\s0 Options\fR
  .IX Subsection "MIPS Options"
! .IP "\fB\-EB\fR" 4
  .IX Item "-EB"
! Generate big-endian code.
! .IP "\fB\-EL\fR" 4
  .IX Item "-EL"
! Generate little-endian code.  This is the default for \fBmips*el\-*\-*\fR
  configurations.
! .IP "\fB\-march=\fR\fIarch\fR" 4
  .IX Item "-march=arch"
  Generate code that runs on \fIarch\fR, which can be the name of a
! generic \s-1MIPS ISA,\s0 or the name of a particular processor.
! The \s-1ISA\s0 names are:
  \&\fBmips1\fR, \fBmips2\fR, \fBmips3\fR, \fBmips4\fR,
  \&\fBmips32\fR, \fBmips32r2\fR, \fBmips32r3\fR, \fBmips32r5\fR,
  \&\fBmips32r6\fR, \fBmips64\fR, \fBmips64r2\fR, \fBmips64r3\fR,
--- 25752,25780 ----
  .RE
  .RS 4
  .Sp
! Option \fB\-xl\-mode\-\fR\fIapp\-model\fR is a deprecated alias for
! \&\fB\-mxl\-mode\-\fR\fIapp\-model\fR.
  .RE
! .IP \fB\-mpic\-data\-is\-text\-relative\fR 4
  .IX Item "-mpic-data-is-text-relative"
  Assume that the displacement between the text and data segments is fixed
  at static link time.  This allows data to be referenced by offset from start of
! text address instead of GOT since PC\-relative addressing is not supported.
  .PP
! \fIMIPS Options\fR
  .IX Subsection "MIPS Options"
! .IP \fB\-EB\fR 4
  .IX Item "-EB"
! Generate big\-endian code.
! .IP \fB\-EL\fR 4
  .IX Item "-EL"
! Generate little\-endian code.  This is the default for \fBmips*el\-*\-*\fR
  configurations.
! .IP \fB\-march=\fR\fIarch\fR 4
  .IX Item "-march=arch"
  Generate code that runs on \fIarch\fR, which can be the name of a
! generic MIPS ISA, or the name of a particular processor.
! The ISA names are:
  \&\fBmips1\fR, \fBmips2\fR, \fBmips3\fR, \fBmips4\fR,
  \&\fBmips32\fR, \fBmips32r2\fR, \fBmips32r3\fR, \fBmips32r5\fR,
  \&\fBmips32r6\fR, \fBmips64\fR, \fBmips64r2\fR, \fBmips64r3\fR,
*************** The processor names are:
*** 25878,25890 ****
  \&\fBvr4100\fR, \fBvr4111\fR, \fBvr4120\fR, \fBvr4130\fR, \fBvr4300\fR,
  \&\fBvr5000\fR, \fBvr5400\fR, \fBvr5500\fR,
  \&\fBxlr\fR and \fBxlp\fR.
! The special value \fBfrom-abi\fR selects the
! most compatible architecture for the selected \s-1ABI\s0 (that is,
  \&\fBmips1\fR for 32\-bit ABIs and \fBmips3\fR for 64\-bit ABIs).
  .Sp
  The native Linux/GNU toolchain also supports the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-march=native\fR has no effect if \s-1GCC\s0 does not recognize
  the processor.
  .Sp
  In processor names, a final \fB000\fR can be abbreviated as \fBk\fR
--- 25809,25821 ----
  \&\fBvr4100\fR, \fBvr4111\fR, \fBvr4120\fR, \fBvr4130\fR, \fBvr4300\fR,
  \&\fBvr5000\fR, \fBvr5400\fR, \fBvr5500\fR,
  \&\fBxlr\fR and \fBxlp\fR.
! The special value \fBfrom\-abi\fR selects the
! most compatible architecture for the selected ABI (that is,
  \&\fBmips1\fR for 32\-bit ABIs and \fBmips3\fR for 64\-bit ABIs).
  .Sp
  The native Linux/GNU toolchain also supports the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-march=native\fR has no effect if GCC does not recognize
  the processor.
  .Sp
  In processor names, a final \fB000\fR can be abbreviated as \fBk\fR
*************** For compatibility reasons, \fIn\fR\fBf\f
*** 25900,26115 ****
  for \fIn\fR\fBf2_1\fR while \fIn\fR\fBx\fR and \fIb\fR\fBfx\fR are
  accepted as synonyms for \fIn\fR\fBf1_1\fR.
  .Sp
! \&\s-1GCC\s0 defines two macros based on the value of this option.  The first
  is \f(CW\*(C`_MIPS_ARCH\*(C'\fR, which gives the name of target architecture, as
! a string.  The second has the form \f(CW\*(C`_MIPS_ARCH_\f(CIfoo\f(CW\*(C'\fR,
  where \fIfoo\fR is the capitalized value of \f(CW\*(C`_MIPS_ARCH\*(C'\fR.
  For example, \fB\-march=r2000\fR sets \f(CW\*(C`_MIPS_ARCH\*(C'\fR
  to \f(CW"r2000"\fR and defines the macro \f(CW\*(C`_MIPS_ARCH_R2000\*(C'\fR.
  .Sp
  Note that the \f(CW\*(C`_MIPS_ARCH\*(C'\fR macro uses the processor names given
  above.  In other words, it has the full prefix and does not
! abbreviate \fB000\fR as \fBk\fR.  In the case of \fBfrom-abi\fR,
  the macro names the resolved architecture (either \f(CW"mips1"\fR or
  \&\f(CW"mips3"\fR).  It names the default architecture when no
  \&\fB\-march\fR option is given.
! .IP "\fB\-mtune=\fR\fIarch\fR" 4
  .IX Item "-mtune=arch"
  Optimize for \fIarch\fR.  Among other things, this option controls
  the way instructions are scheduled, and the perceived cost of arithmetic
  operations.  The list of \fIarch\fR values is the same as for
  \&\fB\-march\fR.
  .Sp
! When this option is not used, \s-1GCC\s0 optimizes for the processor
  specified by \fB\-march\fR.  By using \fB\-march\fR and
  \&\fB\-mtune\fR together, it is possible to generate code that
  runs on a family of processors, but optimize the code for one
  particular member of that family.
  .Sp
  \&\fB\-mtune\fR defines the macros \f(CW\*(C`_MIPS_TUNE\*(C'\fR and
! \&\f(CW\*(C`_MIPS_TUNE_\f(CIfoo\f(CW\*(C'\fR, which work in the same way as the
  \&\fB\-march\fR ones described above.
! .IP "\fB\-mips1\fR" 4
  .IX Item "-mips1"
  Equivalent to \fB\-march=mips1\fR.
! .IP "\fB\-mips2\fR" 4
  .IX Item "-mips2"
  Equivalent to \fB\-march=mips2\fR.
! .IP "\fB\-mips3\fR" 4
  .IX Item "-mips3"
  Equivalent to \fB\-march=mips3\fR.
! .IP "\fB\-mips4\fR" 4
  .IX Item "-mips4"
  Equivalent to \fB\-march=mips4\fR.
! .IP "\fB\-mips32\fR" 4
  .IX Item "-mips32"
  Equivalent to \fB\-march=mips32\fR.
! .IP "\fB\-mips32r3\fR" 4
  .IX Item "-mips32r3"
  Equivalent to \fB\-march=mips32r3\fR.
! .IP "\fB\-mips32r5\fR" 4
  .IX Item "-mips32r5"
  Equivalent to \fB\-march=mips32r5\fR.
! .IP "\fB\-mips32r6\fR" 4
  .IX Item "-mips32r6"
  Equivalent to \fB\-march=mips32r6\fR.
! .IP "\fB\-mips64\fR" 4
  .IX Item "-mips64"
  Equivalent to \fB\-march=mips64\fR.
! .IP "\fB\-mips64r2\fR" 4
  .IX Item "-mips64r2"
  Equivalent to \fB\-march=mips64r2\fR.
! .IP "\fB\-mips64r3\fR" 4
  .IX Item "-mips64r3"
  Equivalent to \fB\-march=mips64r3\fR.
! .IP "\fB\-mips64r5\fR" 4
  .IX Item "-mips64r5"
  Equivalent to \fB\-march=mips64r5\fR.
! .IP "\fB\-mips64r6\fR" 4
  .IX Item "-mips64r6"
  Equivalent to \fB\-march=mips64r6\fR.
! .IP "\fB\-mips16\fR" 4
  .IX Item "-mips16"
  .PD 0
! .IP "\fB\-mno\-mips16\fR" 4
  .IX Item "-mno-mips16"
  .PD
! Generate (do not generate) \s-1MIPS16\s0 code.  If \s-1GCC\s0 is targeting a
! \&\s-1MIPS32\s0 or \s-1MIPS64\s0 architecture, it makes use of the MIPS16e \s-1ASE.\s0
  .Sp
! \&\s-1MIPS16\s0 code generation can also be controlled on a per-function basis
  by means of \f(CW\*(C`mips16\*(C'\fR and \f(CW\*(C`nomips16\*(C'\fR attributes.
! .IP "\fB\-mflip\-mips16\fR" 4
  .IX Item "-mflip-mips16"
! Generate \s-1MIPS16\s0 code on alternating functions.  This option is provided
  for regression testing of mixed MIPS16/non\-MIPS16 code generation, and is
  not intended for ordinary use in compiling user code.
! .IP "\fB\-minterlink\-compressed\fR" 4
  .IX Item "-minterlink-compressed"
  .PD 0
! .IP "\fB\-mno\-interlink\-compressed\fR" 4
  .IX Item "-mno-interlink-compressed"
  .PD
! Require (do not require) that code using the standard (uncompressed) \s-1MIPS ISA\s0
! be link-compatible with \s-1MIPS16\s0 and microMIPS code, and vice versa.
  .Sp
! For example, code using the standard \s-1ISA\s0 encoding cannot jump directly
! to \s-1MIPS16\s0 or microMIPS code; it must either use a call or an indirect jump.
! \&\fB\-minterlink\-compressed\fR therefore disables direct jumps unless \s-1GCC\s0
  knows that the target of the jump is not compressed.
! .IP "\fB\-minterlink\-mips16\fR" 4
  .IX Item "-minterlink-mips16"
  .PD 0
! .IP "\fB\-mno\-interlink\-mips16\fR" 4
  .IX Item "-mno-interlink-mips16"
  .PD
  Aliases of \fB\-minterlink\-compressed\fR and
! \&\fB\-mno\-interlink\-compressed\fR.  These options predate the microMIPS \s-1ASE\s0
  and are retained for backwards compatibility.
! .IP "\fB\-mabi=32\fR" 4
  .IX Item "-mabi=32"
  .PD 0
! .IP "\fB\-mabi=o64\fR" 4
  .IX Item "-mabi=o64"
! .IP "\fB\-mabi=n32\fR" 4
  .IX Item "-mabi=n32"
! .IP "\fB\-mabi=64\fR" 4
  .IX Item "-mabi=64"
! .IP "\fB\-mabi=eabi\fR" 4
  .IX Item "-mabi=eabi"
  .PD
! Generate code for the given \s-1ABI.\s0
  .Sp
! Note that the \s-1EABI\s0 has a 32\-bit and a 64\-bit variant.  \s-1GCC\s0 normally
  generates 64\-bit code when you select a 64\-bit architecture, but you
  can use \fB\-mgp32\fR to get 32\-bit code instead.
  .Sp
! For information about the O64 \s-1ABI,\s0 see
  <\fBhttps://gcc.gnu.org/projects/mipso64\-abi.html\fR>.
  .Sp
! \&\s-1GCC\s0 supports a variant of the o32 \s-1ABI\s0 in which floating-point registers
  are 64 rather than 32 bits wide.  You can select this combination with
! \&\fB\-mabi=32\fR \fB\-mfp64\fR.  This \s-1ABI\s0 relies on the \f(CW\*(C`mthc1\*(C'\fR
  and \f(CW\*(C`mfhc1\*(C'\fR instructions and is therefore only supported for
! \&\s-1MIPS32R2, MIPS32R3\s0 and \s-1MIPS32R5\s0 processors.
  .Sp
  The register assignments for arguments and return values remain the
  same, but each scalar value is passed in a single 64\-bit register
  rather than a pair of 32\-bit registers.  For example, scalar
! floating-point values are returned in \fB\f(CB$f0\fB\fR only, not a
! \&\fB\f(CB$f0\fB\fR/\fB\f(CB$f1\fB\fR pair.  The set of call-saved registers also
! remains the same in that the even-numbered double-precision registers
  are saved.
  .Sp
! Two additional variants of the o32 \s-1ABI\s0 are supported to enable
! a transition from 32\-bit to 64\-bit registers.  These are \s-1FPXX\s0
! (\fB\-mfpxx\fR) and \s-1FP64A\s0 (\fB\-mfp64\fR \fB\-mno\-odd\-spreg\fR).
! The \s-1FPXX\s0 extension mandates that all code must execute correctly
  when run using 32\-bit or 64\-bit registers.  The code can be interlinked
! with either \s-1FP32\s0 or \s-1FP64,\s0 but not both.
! The \s-1FP64A\s0 extension is similar to the \s-1FP64\s0 extension but forbids the
! use of odd-numbered single-precision registers.  This can be used
! in conjunction with the \f(CW\*(C`FRE\*(C'\fR mode of FPUs in \s-1MIPS32R5\s0
! processors and allows both \s-1FP32\s0 and \s-1FP64A\s0 code to interlink and
! run in the same process without changing \s-1FPU\s0 modes.
! .IP "\fB\-mabicalls\fR" 4
  .IX Item "-mabicalls"
  .PD 0
! .IP "\fB\-mno\-abicalls\fR" 4
  .IX Item "-mno-abicalls"
  .PD
  Generate (do not generate) code that is suitable for SVR4\-style
  dynamic objects.  \fB\-mabicalls\fR is the default for SVR4\-based
  systems.
! .IP "\fB\-mshared\fR" 4
  .IX Item "-mshared"
  .PD 0
! .IP "\fB\-mno\-shared\fR" 4
  .IX Item "-mno-shared"
  .PD
! Generate (do not generate) code that is fully position-independent,
  and that can therefore be linked into shared libraries.  This option
  only affects \fB\-mabicalls\fR.
  .Sp
! All \fB\-mabicalls\fR code has traditionally been position-independent,
  regardless of options like \fB\-fPIC\fR and \fB\-fpic\fR.  However,
! as an extension, the \s-1GNU\s0 toolchain allows executables to use absolute
! accesses for locally-binding symbols.  It can also use shorter \s-1GP\s0
! initialization sequences and generate direct calls to locally-defined
  functions.  This mode is selected by \fB\-mno\-shared\fR.
  .Sp
  \&\fB\-mno\-shared\fR depends on binutils 2.16 or higher and generates
! objects that can only be linked by the \s-1GNU\s0 linker.  However, the option
! does not affect the \s-1ABI\s0 of the final executable; it only affects the \s-1ABI\s0
  of relocatable objects.  Using \fB\-mno\-shared\fR generally makes
  executables both smaller and quicker.
  .Sp
  \&\fB\-mshared\fR is the default.
! .IP "\fB\-mplt\fR" 4
  .IX Item "-mplt"
  .PD 0
! .IP "\fB\-mno\-plt\fR" 4
  .IX Item "-mno-plt"
  .PD
  Assume (do not assume) that the static and dynamic linkers
  support PLTs and copy relocations.  This option only affects
! \&\fB\-mno\-shared \-mabicalls\fR.  For the n64 \s-1ABI,\s0 this option
  has no effect without \fB\-msym32\fR.
  .Sp
  You can make \fB\-mplt\fR the default by configuring
! \&\s-1GCC\s0 with \fB\-\-with\-mips\-plt\fR.  The default is
  \&\fB\-mno\-plt\fR otherwise.
! .IP "\fB\-mxgot\fR" 4
  .IX Item "-mxgot"
  .PD 0
! .IP "\fB\-mno\-xgot\fR" 4
  .IX Item "-mno-xgot"
  .PD
  Lift (do not lift) the usual restrictions on the size of the global
  offset table.
  .Sp
! \&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT.\s0
! While this is relatively efficient, it only works if the \s-1GOT\s0
  is smaller than about 64k.  Anything larger causes the linker
  to report an error such as:
  .Sp
--- 25831,26046 ----
  for \fIn\fR\fBf2_1\fR while \fIn\fR\fBx\fR and \fIb\fR\fBfx\fR are
  accepted as synonyms for \fIn\fR\fBf1_1\fR.
  .Sp
! GCC defines two macros based on the value of this option.  The first
  is \f(CW\*(C`_MIPS_ARCH\*(C'\fR, which gives the name of target architecture, as
! a string.  The second has the form \f(CW\*(C`_MIPS_ARCH_\fR\f(CIfoo\fR\f(CW\*(C'\fR,
  where \fIfoo\fR is the capitalized value of \f(CW\*(C`_MIPS_ARCH\*(C'\fR.
  For example, \fB\-march=r2000\fR sets \f(CW\*(C`_MIPS_ARCH\*(C'\fR
  to \f(CW"r2000"\fR and defines the macro \f(CW\*(C`_MIPS_ARCH_R2000\*(C'\fR.
  .Sp
  Note that the \f(CW\*(C`_MIPS_ARCH\*(C'\fR macro uses the processor names given
  above.  In other words, it has the full prefix and does not
! abbreviate \fB000\fR as \fBk\fR.  In the case of \fBfrom\-abi\fR,
  the macro names the resolved architecture (either \f(CW"mips1"\fR or
  \&\f(CW"mips3"\fR).  It names the default architecture when no
  \&\fB\-march\fR option is given.
! .IP \fB\-mtune=\fR\fIarch\fR 4
  .IX Item "-mtune=arch"
  Optimize for \fIarch\fR.  Among other things, this option controls
  the way instructions are scheduled, and the perceived cost of arithmetic
  operations.  The list of \fIarch\fR values is the same as for
  \&\fB\-march\fR.
  .Sp
! When this option is not used, GCC optimizes for the processor
  specified by \fB\-march\fR.  By using \fB\-march\fR and
  \&\fB\-mtune\fR together, it is possible to generate code that
  runs on a family of processors, but optimize the code for one
  particular member of that family.
  .Sp
  \&\fB\-mtune\fR defines the macros \f(CW\*(C`_MIPS_TUNE\*(C'\fR and
! \&\f(CW\*(C`_MIPS_TUNE_\fR\f(CIfoo\fR\f(CW\*(C'\fR, which work in the same way as the
  \&\fB\-march\fR ones described above.
! .IP \fB\-mips1\fR 4
  .IX Item "-mips1"
  Equivalent to \fB\-march=mips1\fR.
! .IP \fB\-mips2\fR 4
  .IX Item "-mips2"
  Equivalent to \fB\-march=mips2\fR.
! .IP \fB\-mips3\fR 4
  .IX Item "-mips3"
  Equivalent to \fB\-march=mips3\fR.
! .IP \fB\-mips4\fR 4
  .IX Item "-mips4"
  Equivalent to \fB\-march=mips4\fR.
! .IP \fB\-mips32\fR 4
  .IX Item "-mips32"
  Equivalent to \fB\-march=mips32\fR.
! .IP \fB\-mips32r3\fR 4
  .IX Item "-mips32r3"
  Equivalent to \fB\-march=mips32r3\fR.
! .IP \fB\-mips32r5\fR 4
  .IX Item "-mips32r5"
  Equivalent to \fB\-march=mips32r5\fR.
! .IP \fB\-mips32r6\fR 4
  .IX Item "-mips32r6"
  Equivalent to \fB\-march=mips32r6\fR.
! .IP \fB\-mips64\fR 4
  .IX Item "-mips64"
  Equivalent to \fB\-march=mips64\fR.
! .IP \fB\-mips64r2\fR 4
  .IX Item "-mips64r2"
  Equivalent to \fB\-march=mips64r2\fR.
! .IP \fB\-mips64r3\fR 4
  .IX Item "-mips64r3"
  Equivalent to \fB\-march=mips64r3\fR.
! .IP \fB\-mips64r5\fR 4
  .IX Item "-mips64r5"
  Equivalent to \fB\-march=mips64r5\fR.
! .IP \fB\-mips64r6\fR 4
  .IX Item "-mips64r6"
  Equivalent to \fB\-march=mips64r6\fR.
! .IP \fB\-mips16\fR 4
  .IX Item "-mips16"
  .PD 0
! .IP \fB\-mno\-mips16\fR 4
  .IX Item "-mno-mips16"
  .PD
! Generate (do not generate) MIPS16 code.  If GCC is targeting a
! MIPS32 or MIPS64 architecture, it makes use of the MIPS16e ASE.
  .Sp
! MIPS16 code generation can also be controlled on a per\-function basis
  by means of \f(CW\*(C`mips16\*(C'\fR and \f(CW\*(C`nomips16\*(C'\fR attributes.
! .IP \fB\-mflip\-mips16\fR 4
  .IX Item "-mflip-mips16"
! Generate 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.
! .IP \fB\-minterlink\-compressed\fR 4
  .IX Item "-minterlink-compressed"
  .PD 0
! .IP \fB\-mno\-interlink\-compressed\fR 4
  .IX Item "-mno-interlink-compressed"
  .PD
! Require (do not require) that code using the standard (uncompressed) MIPS ISA
! be link\-compatible with MIPS16 and microMIPS code, and vice versa.
  .Sp
! For example, code using the standard ISA encoding cannot jump directly
! to MIPS16 or microMIPS code; it must either use a call or an indirect jump.
! \&\fB\-minterlink\-compressed\fR therefore disables direct jumps unless GCC
  knows that the target of the jump is not compressed.
! .IP \fB\-minterlink\-mips16\fR 4
  .IX Item "-minterlink-mips16"
  .PD 0
! .IP \fB\-mno\-interlink\-mips16\fR 4
  .IX Item "-mno-interlink-mips16"
  .PD
  Aliases of \fB\-minterlink\-compressed\fR and
! \&\fB\-mno\-interlink\-compressed\fR.  These options predate the microMIPS ASE
  and are retained for backwards compatibility.
! .IP \fB\-mabi=32\fR 4
  .IX Item "-mabi=32"
  .PD 0
! .IP \fB\-mabi=o64\fR 4
  .IX Item "-mabi=o64"
! .IP \fB\-mabi=n32\fR 4
  .IX Item "-mabi=n32"
! .IP \fB\-mabi=64\fR 4
  .IX Item "-mabi=64"
! .IP \fB\-mabi=eabi\fR 4
  .IX Item "-mabi=eabi"
  .PD
! Generate code for the given ABI.
  .Sp
! 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 \fB\-mgp32\fR to get 32\-bit code instead.
  .Sp
! For information about the O64 ABI, see
  <\fBhttps://gcc.gnu.org/projects/mipso64\-abi.html\fR>.
  .Sp
! 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
! \&\fB\-mabi=32\fR \fB\-mfp64\fR.  This ABI relies on the \f(CW\*(C`mthc1\*(C'\fR
  and \f(CW\*(C`mfhc1\*(C'\fR instructions and is therefore only supported for
! MIPS32R2, MIPS32R3 and MIPS32R5 processors.
  .Sp
  The register assignments for arguments and return values remain the
  same, but each scalar value is passed in a single 64\-bit register
  rather than a pair of 32\-bit registers.  For example, scalar
! floating\-point values are returned in \fR\f(CB$f0\fR\fB\fR only, not a
! \&\fB\fR\f(CB$f0\fR\fB\fR/\fB\fR\f(CB$f1\fR\fB\fR pair.  The set of call\-saved registers also
! remains the same in that the even\-numbered double\-precision registers
  are saved.
  .Sp
! Two additional variants of the o32 ABI are supported to enable
! a transition from 32\-bit to 64\-bit registers.  These are FPXX
! (\fB\-mfpxx\fR) and FP64A (\fB\-mfp64\fR \fB\-mno\-odd\-spreg\fR).
! The FPXX extension mandates that all code must execute correctly
  when run using 32\-bit or 64\-bit registers.  The code can be interlinked
! with either FP32 or FP64, but not both.
! The FP64A extension is similar to the FP64 extension but forbids the
! use of odd\-numbered single\-precision registers.  This can be used
! in conjunction with the \f(CW\*(C`FRE\*(C'\fR mode of FPUs in MIPS32R5
! processors and allows both FP32 and FP64A code to interlink and
! run in the same process without changing FPU modes.
! .IP \fB\-mabicalls\fR 4
  .IX Item "-mabicalls"
  .PD 0
! .IP \fB\-mno\-abicalls\fR 4
  .IX Item "-mno-abicalls"
  .PD
  Generate (do not generate) code that is suitable for SVR4\-style
  dynamic objects.  \fB\-mabicalls\fR is the default for SVR4\-based
  systems.
! .IP \fB\-mshared\fR 4
  .IX Item "-mshared"
  .PD 0
! .IP \fB\-mno\-shared\fR 4
  .IX Item "-mno-shared"
  .PD
! Generate (do not generate) code that is fully position\-independent,
  and that can therefore be linked into shared libraries.  This option
  only affects \fB\-mabicalls\fR.
  .Sp
! All \fB\-mabicalls\fR code has traditionally been position\-independent,
  regardless of options like \fB\-fPIC\fR and \fB\-fpic\fR.  However,
! as an extension, the 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 \fB\-mno\-shared\fR.
  .Sp
  \&\fB\-mno\-shared\fR depends on binutils 2.16 or higher and generates
! objects that can only be linked by the GNU linker.  However, the option
! does not affect the ABI of the final executable; it only affects the ABI
  of relocatable objects.  Using \fB\-mno\-shared\fR generally makes
  executables both smaller and quicker.
  .Sp
  \&\fB\-mshared\fR is the default.
! .IP \fB\-mplt\fR 4
  .IX Item "-mplt"
  .PD 0
! .IP \fB\-mno\-plt\fR 4
  .IX Item "-mno-plt"
  .PD
  Assume (do not assume) that the static and dynamic linkers
  support PLTs and copy relocations.  This option only affects
! \&\fB\-mno\-shared \-mabicalls\fR.  For the n64 ABI, this option
  has no effect without \fB\-msym32\fR.
  .Sp
  You can make \fB\-mplt\fR the default by configuring
! GCC with \fB\-\-with\-mips\-plt\fR.  The default is
  \&\fB\-mno\-plt\fR otherwise.
! .IP \fB\-mxgot\fR 4
  .IX Item "-mxgot"
  .PD 0
! .IP \fB\-mno\-xgot\fR 4
  .IX Item "-mno-xgot"
  .PD
  Lift (do not lift) the usual restrictions on the size of the global
  offset table.
  .Sp
! 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:
  .Sp
*************** value of a global symbol.
*** 26124,26413 ****
  .Sp
  Note that some linkers can create multiple GOTs.  If you have such a
  linker, you should only need to use \fB\-mxgot\fR when a single object
! file accesses more than 64k's worth of \s-1GOT\s0 entries.  Very few do.
  .Sp
! These options have no effect unless \s-1GCC\s0 is generating position
  independent code.
! .IP "\fB\-mgp32\fR" 4
  .IX Item "-mgp32"
! Assume that general-purpose registers are 32 bits wide.
! .IP "\fB\-mgp64\fR" 4
  .IX Item "-mgp64"
! Assume that general-purpose registers are 64 bits wide.
! .IP "\fB\-mfp32\fR" 4
  .IX Item "-mfp32"
! Assume that floating-point registers are 32 bits wide.
! .IP "\fB\-mfp64\fR" 4
  .IX Item "-mfp64"
! Assume that floating-point registers are 64 bits wide.
! .IP "\fB\-mfpxx\fR" 4
  .IX Item "-mfpxx"
! Do not assume the width of floating-point registers.
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
! Use floating-point coprocessor instructions.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
! Do not use floating-point coprocessor instructions.  Implement
! floating-point calculations using library calls instead.
! .IP "\fB\-mno\-float\fR" 4
  .IX Item "-mno-float"
  Equivalent to \fB\-msoft\-float\fR, but additionally asserts that the
! program being compiled does not perform any floating-point operations.
! This option is presently supported only by some bare-metal \s-1MIPS\s0
  configurations, where it may select a special set of libraries
! that lack all floating-point support (including, for example, the
! floating-point \f(CW\*(C`printf\*(C'\fR formats).  
  If code compiled with \fB\-mno\-float\fR accidentally contains
! floating-point operations, it is likely to suffer a link-time
! or run-time failure.
! .IP "\fB\-msingle\-float\fR" 4
  .IX Item "-msingle-float"
! Assume that the floating-point coprocessor only supports single-precision
  operations.
! .IP "\fB\-mdouble\-float\fR" 4
  .IX Item "-mdouble-float"
! Assume that the floating-point coprocessor supports double-precision
  operations.  This is the default.
! .IP "\fB\-modd\-spreg\fR" 4
  .IX Item "-modd-spreg"
  .PD 0
! .IP "\fB\-mno\-odd\-spreg\fR" 4
  .IX Item "-mno-odd-spreg"
  .PD
! Enable the use of odd-numbered single-precision floating-point registers
! for the o32 \s-1ABI.\s0  This is the default for processors that are known to
! support these registers.  When using the o32 \s-1FPXX ABI,\s0 \fB\-mno\-odd\-spreg\fR
  is set by default.
! .IP "\fB\-mabs=2008\fR" 4
  .IX Item "-mabs=2008"
  .PD 0
! .IP "\fB\-mabs=legacy\fR" 4
  .IX Item "-mabs=legacy"
  .PD
! These options control the treatment of the special not-a-number (NaN)
! \&\s-1IEEE 754\s0 floating-point data with the \f(CW\*(C`abs.\f(CIfmt\f(CW\*(C'\fR and
! \&\f(CW\*(C`neg.\f(CIfmt\f(CW\*(C'\fR machine instructions.
  .Sp
  By default or when \fB\-mabs=legacy\fR is used the legacy
  treatment is selected.  In this case these instructions are considered
  arithmetic and avoided where correct operation is required and the
  input operand might be a NaN.  A longer sequence of instructions that
! manipulate the sign bit of floating-point datum manually is used
  instead unless the \fB\-ffinite\-math\-only\fR option has also been
  specified.
  .Sp
! The \fB\-mabs=2008\fR option selects the \s-1IEEE 754\-2008\s0 treatment.  In
! this case these instructions are considered non-arithmetic and therefore
  operating correctly in all cases, including in particular where the
  input operand is a NaN.  These instructions are therefore always used
  for the respective operations.
! .IP "\fB\-mnan=2008\fR" 4
  .IX Item "-mnan=2008"
  .PD 0
! .IP "\fB\-mnan=legacy\fR" 4
  .IX Item "-mnan=legacy"
  .PD
! These options control the encoding of the special not-a-number (NaN)
! \&\s-1IEEE 754\s0 floating-point data.
  .Sp
  The \fB\-mnan=legacy\fR option selects the legacy encoding.  In this
  case quiet NaNs (qNaNs) are denoted by the first bit of their trailing
  significand field being 0, whereas signaling NaNs (sNaNs) are denoted
  by the first bit of their trailing significand field being 1.
  .Sp
! The \fB\-mnan=2008\fR option selects the \s-1IEEE 754\-2008\s0 encoding.  In
  this case qNaNs are denoted by the first bit of their trailing
  significand field being 1, whereas sNaNs are denoted by the first bit of
  their trailing significand field being 0.
  .Sp
! The default is \fB\-mnan=legacy\fR unless \s-1GCC\s0 has been configured with
  \&\fB\-\-with\-nan=2008\fR.
! .IP "\fB\-mllsc\fR" 4
  .IX Item "-mllsc"
  .PD 0
! .IP "\fB\-mno\-llsc\fR" 4
  .IX Item "-mno-llsc"
  .PD
  Use (do not use) \fBll\fR, \fBsc\fR, and \fBsync\fR instructions to
! implement atomic memory built-in functions.  When neither option is
! specified, \s-1GCC\s0 uses the instructions if the target architecture
  supports them.
  .Sp
  \&\fB\-mllsc\fR is useful if the runtime environment can emulate the
  instructions and \fB\-mno\-llsc\fR can be useful when compiling for
  nonstandard ISAs.  You can make either option the default by
! configuring \s-1GCC\s0 with \fB\-\-with\-llsc\fR and \fB\-\-without\-llsc\fR
  respectively.  \fB\-\-with\-llsc\fR is the default for some
  configurations; see the installation documentation for details.
! .IP "\fB\-mdsp\fR" 4
  .IX Item "-mdsp"
  .PD 0
! .IP "\fB\-mno\-dsp\fR" 4
  .IX Item "-mno-dsp"
  .PD
! Use (do not use) revision 1 of the \s-1MIPS DSP ASE.\s0
    This option defines the
  preprocessor macro \f(CW\*(C`_\|_mips_dsp\*(C'\fR.  It also defines
  \&\f(CW\*(C`_\|_mips_dsp_rev\*(C'\fR to 1.
! .IP "\fB\-mdspr2\fR" 4
  .IX Item "-mdspr2"
  .PD 0
! .IP "\fB\-mno\-dspr2\fR" 4
  .IX Item "-mno-dspr2"
  .PD
! Use (do not use) revision 2 of the \s-1MIPS DSP ASE.\s0
    This option defines the
  preprocessor macros \f(CW\*(C`_\|_mips_dsp\*(C'\fR and \f(CW\*(C`_\|_mips_dspr2\*(C'\fR.
  It also defines \f(CW\*(C`_\|_mips_dsp_rev\*(C'\fR to 2.
! .IP "\fB\-msmartmips\fR" 4
  .IX Item "-msmartmips"
  .PD 0
! .IP "\fB\-mno\-smartmips\fR" 4
  .IX Item "-mno-smartmips"
  .PD
! Use (do not use) the \s-1MIPS\s0 SmartMIPS \s-1ASE.\s0
! .IP "\fB\-mpaired\-single\fR" 4
  .IX Item "-mpaired-single"
  .PD 0
! .IP "\fB\-mno\-paired\-single\fR" 4
  .IX Item "-mno-paired-single"
  .PD
! Use (do not use) paired-single floating-point instructions.
    This option requires
! hardware floating-point support to be enabled.
! .IP "\fB\-mdmx\fR" 4
  .IX Item "-mdmx"
  .PD 0
! .IP "\fB\-mno\-mdmx\fR" 4
  .IX Item "-mno-mdmx"
  .PD
! Use (do not use) \s-1MIPS\s0 Digital Media Extension instructions.
  This option can only be used when generating 64\-bit code and requires
! hardware floating-point support to be enabled.
! .IP "\fB\-mips3d\fR" 4
  .IX Item "-mips3d"
  .PD 0
! .IP "\fB\-mno\-mips3d\fR" 4
  .IX Item "-mno-mips3d"
  .PD
! Use (do not use) the \s-1MIPS\-3D ASE.\s0  
  The option \fB\-mips3d\fR implies \fB\-mpaired\-single\fR.
! .IP "\fB\-mmicromips\fR" 4
  .IX Item "-mmicromips"
  .PD 0
! .IP "\fB\-mno\-micromips\fR" 4
  .IX Item "-mno-micromips"
  .PD
  Generate (do not generate) microMIPS code.
  .Sp
! MicroMIPS code generation can also be controlled on a per-function basis
  by means of \f(CW\*(C`micromips\*(C'\fR and \f(CW\*(C`nomicromips\*(C'\fR attributes.
! .IP "\fB\-mmt\fR" 4
  .IX Item "-mmt"
  .PD 0
! .IP "\fB\-mno\-mt\fR" 4
  .IX Item "-mno-mt"
  .PD
! Use (do not use) \s-1MT\s0 Multithreading instructions.
! .IP "\fB\-mmcu\fR" 4
  .IX Item "-mmcu"
  .PD 0
! .IP "\fB\-mno\-mcu\fR" 4
  .IX Item "-mno-mcu"
  .PD
! Use (do not use) the \s-1MIPS MCU ASE\s0 instructions.
! .IP "\fB\-meva\fR" 4
  .IX Item "-meva"
  .PD 0
! .IP "\fB\-mno\-eva\fR" 4
  .IX Item "-mno-eva"
  .PD
! Use (do not use) the \s-1MIPS\s0 Enhanced Virtual Addressing instructions.
! .IP "\fB\-mvirt\fR" 4
  .IX Item "-mvirt"
  .PD 0
! .IP "\fB\-mno\-virt\fR" 4
  .IX Item "-mno-virt"
  .PD
! Use (do not use) the \s-1MIPS\s0 Virtualization (\s-1VZ\s0) instructions.
! .IP "\fB\-mxpa\fR" 4
  .IX Item "-mxpa"
  .PD 0
! .IP "\fB\-mno\-xpa\fR" 4
  .IX Item "-mno-xpa"
  .PD
! Use (do not use) the \s-1MIPS\s0 eXtended Physical Address (\s-1XPA\s0) instructions.
! .IP "\fB\-mcrc\fR" 4
  .IX Item "-mcrc"
  .PD 0
! .IP "\fB\-mno\-crc\fR" 4
  .IX Item "-mno-crc"
  .PD
! Use (do not use) the \s-1MIPS\s0 Cyclic Redundancy Check (\s-1CRC\s0) instructions.
! .IP "\fB\-mginv\fR" 4
  .IX Item "-mginv"
  .PD 0
! .IP "\fB\-mno\-ginv\fR" 4
  .IX Item "-mno-ginv"
  .PD
! Use (do not use) the \s-1MIPS\s0 Global INValidate (\s-1GINV\s0) instructions.
! .IP "\fB\-mloongson\-mmi\fR" 4
  .IX Item "-mloongson-mmi"
  .PD 0
! .IP "\fB\-mno\-loongson\-mmi\fR" 4
  .IX Item "-mno-loongson-mmi"
  .PD
! Use (do not use) the \s-1MIPS\s0 Loongson MultiMedia extensions Instructions (\s-1MMI\s0).
! .IP "\fB\-mloongson\-ext\fR" 4
  .IX Item "-mloongson-ext"
  .PD 0
! .IP "\fB\-mno\-loongson\-ext\fR" 4
  .IX Item "-mno-loongson-ext"
  .PD
! Use (do not use) the \s-1MIPS\s0 Loongson EXTensions (\s-1EXT\s0) instructions.
! .IP "\fB\-mloongson\-ext2\fR" 4
  .IX Item "-mloongson-ext2"
  .PD 0
! .IP "\fB\-mno\-loongson\-ext2\fR" 4
  .IX Item "-mno-loongson-ext2"
  .PD
! Use (do not use) the \s-1MIPS\s0 Loongson EXTensions r2 (\s-1EXT2\s0) instructions.
! .IP "\fB\-mlong64\fR" 4
  .IX Item "-mlong64"
  Force \f(CW\*(C`long\*(C'\fR types to be 64 bits wide.  See \fB\-mlong32\fR for
  an explanation of the default and the way that the pointer size is
  determined.
! .IP "\fB\-mlong32\fR" 4
  .IX Item "-mlong32"
  Force \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`int\*(C'\fR, and pointer types to be 32 bits wide.
  .Sp
  The default size of \f(CW\*(C`int\*(C'\fRs, \f(CW\*(C`long\*(C'\fRs and pointers depends on
! the \s-1ABI.\s0  All the supported ABIs use 32\-bit \f(CW\*(C`int\*(C'\fRs.  The n64 \s-1ABI\s0
! uses 64\-bit \f(CW\*(C`long\*(C'\fRs, as does the 64\-bit \s-1EABI\s0; the others use
  32\-bit \f(CW\*(C`long\*(C'\fRs.  Pointers are the same size as \f(CW\*(C`long\*(C'\fRs,
  or the same size as integer registers, whichever is smaller.
! .IP "\fB\-msym32\fR" 4
  .IX Item "-msym32"
  .PD 0
! .IP "\fB\-mno\-sym32\fR" 4
  .IX Item "-mno-sym32"
  .PD
  Assume (do not assume) that all symbols have 32\-bit values, regardless
! of the selected \s-1ABI.\s0  This option is useful in combination with
! \&\fB\-mabi=64\fR and \fB\-mno\-abicalls\fR because it allows \s-1GCC\s0
  to generate shorter and faster references to symbolic addresses.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
! Put definitions of externally-visible data in a small data section
! if that data is no bigger than \fInum\fR bytes.  \s-1GCC\s0 can then generate
  more efficient accesses to the data; see \fB\-mgpopt\fR for details.
  .Sp
  The default \fB\-G\fR option depends on the configuration.
! .IP "\fB\-mlocal\-sdata\fR" 4
  .IX Item "-mlocal-sdata"
  .PD 0
! .IP "\fB\-mno\-local\-sdata\fR" 4
  .IX Item "-mno-local-sdata"
  .PD
  Extend (do not extend) the \fB\-G\fR behavior to local data too,
--- 26055,26344 ----
  .Sp
  Note that some linkers can create multiple GOTs.  If you have such a
  linker, you should only need to use \fB\-mxgot\fR when a single object
! file accesses more than 64k\*(Aqs worth of GOT entries.  Very few do.
  .Sp
! These options have no effect unless GCC is generating position
  independent code.
! .IP \fB\-mgp32\fR 4
  .IX Item "-mgp32"
! Assume that general\-purpose registers are 32 bits wide.
! .IP \fB\-mgp64\fR 4
  .IX Item "-mgp64"
! Assume that general\-purpose registers are 64 bits wide.
! .IP \fB\-mfp32\fR 4
  .IX Item "-mfp32"
! Assume that floating\-point registers are 32 bits wide.
! .IP \fB\-mfp64\fR 4
  .IX Item "-mfp64"
! Assume that floating\-point registers are 64 bits wide.
! .IP \fB\-mfpxx\fR 4
  .IX Item "-mfpxx"
! Do not assume the width of floating\-point registers.
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
! Use floating\-point coprocessor instructions.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
! Do not use floating\-point coprocessor instructions.  Implement
! floating\-point calculations using library calls instead.
! .IP \fB\-mno\-float\fR 4
  .IX Item "-mno-float"
  Equivalent to \fB\-msoft\-float\fR, but additionally asserts that the
! program being compiled does not perform any floating\-point operations.
! This option is presently supported only by some bare\-metal MIPS
  configurations, where it may select a special set of libraries
! that lack all floating\-point support (including, for example, the
! floating\-point \f(CW\*(C`printf\*(C'\fR formats).  
  If code compiled with \fB\-mno\-float\fR accidentally contains
! floating\-point operations, it is likely to suffer a link\-time
! or run\-time failure.
! .IP \fB\-msingle\-float\fR 4
  .IX Item "-msingle-float"
! Assume that the floating\-point coprocessor only supports single\-precision
  operations.
! .IP \fB\-mdouble\-float\fR 4
  .IX Item "-mdouble-float"
! Assume that the floating\-point coprocessor supports double\-precision
  operations.  This is the default.
! .IP \fB\-modd\-spreg\fR 4
  .IX Item "-modd-spreg"
  .PD 0
! .IP \fB\-mno\-odd\-spreg\fR 4
  .IX Item "-mno-odd-spreg"
  .PD
! Enable the use of odd\-numbered single\-precision floating\-point registers
! for the o32 ABI.  This is the default for processors that are known to
! support these registers.  When using the o32 FPXX ABI, \fB\-mno\-odd\-spreg\fR
  is set by default.
! .IP \fB\-mabs=2008\fR 4
  .IX Item "-mabs=2008"
  .PD 0
! .IP \fB\-mabs=legacy\fR 4
  .IX Item "-mabs=legacy"
  .PD
! These options control the treatment of the special not\-a\-number (NaN)
! IEEE 754 floating\-point data with the \f(CW\*(C`abs.\fR\f(CIfmt\fR\f(CW\*(C'\fR and
! \&\f(CW\*(C`neg.\fR\f(CIfmt\fR\f(CW\*(C'\fR machine instructions.
  .Sp
  By default or when \fB\-mabs=legacy\fR is used the legacy
  treatment is selected.  In this case these instructions are considered
  arithmetic and avoided where correct operation is required and the
  input operand might be a NaN.  A longer sequence of instructions that
! manipulate the sign bit of floating\-point datum manually is used
  instead unless the \fB\-ffinite\-math\-only\fR option has also been
  specified.
  .Sp
! The \fB\-mabs=2008\fR option selects the IEEE 754\-2008 treatment.  In
! this case these instructions are considered non\-arithmetic and therefore
  operating correctly in all cases, including in particular where the
  input operand is a NaN.  These instructions are therefore always used
  for the respective operations.
! .IP \fB\-mnan=2008\fR 4
  .IX Item "-mnan=2008"
  .PD 0
! .IP \fB\-mnan=legacy\fR 4
  .IX Item "-mnan=legacy"
  .PD
! These options control the encoding of the special not\-a\-number (NaN)
! IEEE 754 floating\-point data.
  .Sp
  The \fB\-mnan=legacy\fR option selects the legacy encoding.  In this
  case quiet NaNs (qNaNs) are denoted by the first bit of their trailing
  significand field being 0, whereas signaling NaNs (sNaNs) are denoted
  by the first bit of their trailing significand field being 1.
  .Sp
! The \fB\-mnan=2008\fR option selects the IEEE 754\-2008 encoding.  In
  this case qNaNs are denoted by the first bit of their trailing
  significand field being 1, whereas sNaNs are denoted by the first bit of
  their trailing significand field being 0.
  .Sp
! The default is \fB\-mnan=legacy\fR unless GCC has been configured with
  \&\fB\-\-with\-nan=2008\fR.
! .IP \fB\-mllsc\fR 4
  .IX Item "-mllsc"
  .PD 0
! .IP \fB\-mno\-llsc\fR 4
  .IX Item "-mno-llsc"
  .PD
  Use (do not use) \fBll\fR, \fBsc\fR, and \fBsync\fR instructions to
! implement atomic memory built\-in functions.  When neither option is
! specified, GCC uses the instructions if the target architecture
  supports them.
  .Sp
  \&\fB\-mllsc\fR is useful if the runtime environment can emulate the
  instructions and \fB\-mno\-llsc\fR can be useful when compiling for
  nonstandard ISAs.  You can make either option the default by
! configuring GCC with \fB\-\-with\-llsc\fR and \fB\-\-without\-llsc\fR
  respectively.  \fB\-\-with\-llsc\fR is the default for some
  configurations; see the installation documentation for details.
! .IP \fB\-mdsp\fR 4
  .IX Item "-mdsp"
  .PD 0
! .IP \fB\-mno\-dsp\fR 4
  .IX Item "-mno-dsp"
  .PD
! Use (do not use) revision 1 of the MIPS DSP ASE.
    This option defines the
  preprocessor macro \f(CW\*(C`_\|_mips_dsp\*(C'\fR.  It also defines
  \&\f(CW\*(C`_\|_mips_dsp_rev\*(C'\fR to 1.
! .IP \fB\-mdspr2\fR 4
  .IX Item "-mdspr2"
  .PD 0
! .IP \fB\-mno\-dspr2\fR 4
  .IX Item "-mno-dspr2"
  .PD
! Use (do not use) revision 2 of the MIPS DSP ASE.
    This option defines the
  preprocessor macros \f(CW\*(C`_\|_mips_dsp\*(C'\fR and \f(CW\*(C`_\|_mips_dspr2\*(C'\fR.
  It also defines \f(CW\*(C`_\|_mips_dsp_rev\*(C'\fR to 2.
! .IP \fB\-msmartmips\fR 4
  .IX Item "-msmartmips"
  .PD 0
! .IP \fB\-mno\-smartmips\fR 4
  .IX Item "-mno-smartmips"
  .PD
! Use (do not use) the MIPS SmartMIPS ASE.
! .IP \fB\-mpaired\-single\fR 4
  .IX Item "-mpaired-single"
  .PD 0
! .IP \fB\-mno\-paired\-single\fR 4
  .IX Item "-mno-paired-single"
  .PD
! Use (do not use) paired\-single floating\-point instructions.
    This option requires
! hardware floating\-point support to be enabled.
! .IP \fB\-mdmx\fR 4
  .IX Item "-mdmx"
  .PD 0
! .IP \fB\-mno\-mdmx\fR 4
  .IX Item "-mno-mdmx"
  .PD
! Use (do not use) 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.
! .IP \fB\-mips3d\fR 4
  .IX Item "-mips3d"
  .PD 0
! .IP \fB\-mno\-mips3d\fR 4
  .IX Item "-mno-mips3d"
  .PD
! Use (do not use) the MIPS\-3D ASE.  
  The option \fB\-mips3d\fR implies \fB\-mpaired\-single\fR.
! .IP \fB\-mmicromips\fR 4
  .IX Item "-mmicromips"
  .PD 0
! .IP \fB\-mno\-micromips\fR 4
  .IX Item "-mno-micromips"
  .PD
  Generate (do not generate) microMIPS code.
  .Sp
! MicroMIPS code generation can also be controlled on a per\-function basis
  by means of \f(CW\*(C`micromips\*(C'\fR and \f(CW\*(C`nomicromips\*(C'\fR attributes.
! .IP \fB\-mmt\fR 4
  .IX Item "-mmt"
  .PD 0
! .IP \fB\-mno\-mt\fR 4
  .IX Item "-mno-mt"
  .PD
! Use (do not use) MT Multithreading instructions.
! .IP \fB\-mmcu\fR 4
  .IX Item "-mmcu"
  .PD 0
! .IP \fB\-mno\-mcu\fR 4
  .IX Item "-mno-mcu"
  .PD
! Use (do not use) the MIPS MCU ASE instructions.
! .IP \fB\-meva\fR 4
  .IX Item "-meva"
  .PD 0
! .IP \fB\-mno\-eva\fR 4
  .IX Item "-mno-eva"
  .PD
! Use (do not use) the MIPS Enhanced Virtual Addressing instructions.
! .IP \fB\-mvirt\fR 4
  .IX Item "-mvirt"
  .PD 0
! .IP \fB\-mno\-virt\fR 4
  .IX Item "-mno-virt"
  .PD
! Use (do not use) the MIPS Virtualization (VZ) instructions.
! .IP \fB\-mxpa\fR 4
  .IX Item "-mxpa"
  .PD 0
! .IP \fB\-mno\-xpa\fR 4
  .IX Item "-mno-xpa"
  .PD
! Use (do not use) the MIPS eXtended Physical Address (XPA) instructions.
! .IP \fB\-mcrc\fR 4
  .IX Item "-mcrc"
  .PD 0
! .IP \fB\-mno\-crc\fR 4
  .IX Item "-mno-crc"
  .PD
! Use (do not use) the MIPS Cyclic Redundancy Check (CRC) instructions.
! .IP \fB\-mginv\fR 4
  .IX Item "-mginv"
  .PD 0
! .IP \fB\-mno\-ginv\fR 4
  .IX Item "-mno-ginv"
  .PD
! Use (do not use) the MIPS Global INValidate (GINV) instructions.
! .IP \fB\-mloongson\-mmi\fR 4
  .IX Item "-mloongson-mmi"
  .PD 0
! .IP \fB\-mno\-loongson\-mmi\fR 4
  .IX Item "-mno-loongson-mmi"
  .PD
! Use (do not use) the MIPS Loongson MultiMedia extensions Instructions (MMI).
! .IP \fB\-mloongson\-ext\fR 4
  .IX Item "-mloongson-ext"
  .PD 0
! .IP \fB\-mno\-loongson\-ext\fR 4
  .IX Item "-mno-loongson-ext"
  .PD
! Use (do not use) the MIPS Loongson EXTensions (EXT) instructions.
! .IP \fB\-mloongson\-ext2\fR 4
  .IX Item "-mloongson-ext2"
  .PD 0
! .IP \fB\-mno\-loongson\-ext2\fR 4
  .IX Item "-mno-loongson-ext2"
  .PD
! Use (do not use) the MIPS Loongson EXTensions r2 (EXT2) instructions.
! .IP \fB\-mlong64\fR 4
  .IX Item "-mlong64"
  Force \f(CW\*(C`long\*(C'\fR types to be 64 bits wide.  See \fB\-mlong32\fR for
  an explanation of the default and the way that the pointer size is
  determined.
! .IP \fB\-mlong32\fR 4
  .IX Item "-mlong32"
  Force \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`int\*(C'\fR, and pointer types to be 32 bits wide.
  .Sp
  The default size of \f(CW\*(C`int\*(C'\fRs, \f(CW\*(C`long\*(C'\fRs and pointers depends on
! the ABI.  All the supported ABIs use 32\-bit \f(CW\*(C`int\*(C'\fRs.  The n64 ABI
! uses 64\-bit \f(CW\*(C`long\*(C'\fRs, as does the 64\-bit EABI; the others use
  32\-bit \f(CW\*(C`long\*(C'\fRs.  Pointers are the same size as \f(CW\*(C`long\*(C'\fRs,
  or the same size as integer registers, whichever is smaller.
! .IP \fB\-msym32\fR 4
  .IX Item "-msym32"
  .PD 0
! .IP \fB\-mno\-sym32\fR 4
  .IX Item "-mno-sym32"
  .PD
  Assume (do not assume) that all symbols have 32\-bit values, regardless
! of the selected ABI.  This option is useful in combination with
! \&\fB\-mabi=64\fR and \fB\-mno\-abicalls\fR because it allows GCC
  to generate shorter and faster references to symbolic addresses.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
! Put definitions of externally\-visible data in a small data section
! if that data is no bigger than \fInum\fR bytes.  GCC can then generate
  more efficient accesses to the data; see \fB\-mgpopt\fR for details.
  .Sp
  The default \fB\-G\fR option depends on the configuration.
! .IP \fB\-mlocal\-sdata\fR 4
  .IX Item "-mlocal-sdata"
  .PD 0
! .IP \fB\-mno\-local\-sdata\fR 4
  .IX Item "-mno-local-sdata"
  .PD
  Extend (do not extend) the \fB\-G\fR behavior to local data too,
*************** such as to static variables in C.  \fB\-
*** 26415,26431 ****
  default for all configurations.
  .Sp
  If the linker complains that an application is using too much small data,
! you might want to try rebuilding the less performance-critical parts with
  \&\fB\-mno\-local\-sdata\fR.  You might also want to build large
  libraries with \fB\-mno\-local\-sdata\fR, so that the libraries leave
  more room for the main program.
! .IP "\fB\-mextern\-sdata\fR" 4
  .IX Item "-mextern-sdata"
  .PD 0
! .IP "\fB\-mno\-extern\-sdata\fR" 4
  .IX Item "-mno-extern-sdata"
  .PD
! Assume (do not assume) that externally-defined data is in
  a small data section if the size of that data is within the \fB\-G\fR limit.
  \&\fB\-mextern\-sdata\fR is the default for all configurations.
  .Sp
--- 26346,26362 ----
  default for all configurations.
  .Sp
  If the linker complains that an application is using too much small data,
! you might want to try rebuilding the less performance\-critical parts with
  \&\fB\-mno\-local\-sdata\fR.  You might also want to build large
  libraries with \fB\-mno\-local\-sdata\fR, so that the libraries leave
  more room for the main program.
! .IP \fB\-mextern\-sdata\fR 4
  .IX Item "-mextern-sdata"
  .PD 0
! .IP \fB\-mno\-extern\-sdata\fR 4
  .IX Item "-mno-extern-sdata"
  .PD
! Assume (do not assume) that externally\-defined data is in
  a small data section if the size of that data is within the \fB\-G\fR limit.
  \&\fB\-mextern\-sdata\fR is the default for all configurations.
  .Sp
*************** If you compile a module \fIMod\fR with \
*** 26433,26442 ****
  \&\fInum\fR \fB\-mgpopt\fR, and \fIMod\fR references a variable \fIVar\fR
  that is no bigger than \fInum\fR bytes, you must make sure that \fIVar\fR
  is placed in a small data section.  If \fIVar\fR is defined by another
! module, you must either compile that module with a high-enough
! \&\fB\-G\fR setting or attach a \f(CW\*(C`section\*(C'\fR attribute to \fIVar\fR's
  definition.  If \fIVar\fR is common, you must link the application
! with a high-enough \fB\-G\fR setting.
  .Sp
  The easiest way of satisfying these restrictions is to compile
  and link every module with the same \fB\-G\fR option.  However,
--- 26364,26373 ----
  \&\fInum\fR \fB\-mgpopt\fR, and \fIMod\fR references a variable \fIVar\fR
  that is no bigger than \fInum\fR bytes, you must make sure that \fIVar\fR
  is placed in a small data section.  If \fIVar\fR is defined by another
! module, you must either compile that module with a high\-enough
! \&\fB\-G\fR setting or attach a \f(CW\*(C`section\*(C'\fR attribute to \fIVar\fR\*(Aqs
  definition.  If \fIVar\fR is common, you must link the application
! with a high\-enough \fB\-G\fR setting.
  .Sp
  The easiest way of satisfying these restrictions is to compile
  and link every module with the same \fB\-G\fR option.  However,
*************** you may wish to build a library that sup
*** 26444,26457 ****
  small data limits.  You can do this by compiling the library with
  the highest supported \fB\-G\fR setting and additionally using
  \&\fB\-mno\-extern\-sdata\fR to stop the library from making assumptions
! about externally-defined data.
! .IP "\fB\-mgpopt\fR" 4
  .IX Item "-mgpopt"
  .PD 0
! .IP "\fB\-mno\-gpopt\fR" 4
  .IX Item "-mno-gpopt"
  .PD
! Use (do not use) GP-relative accesses for symbols that are known to be
  in a small data section; see \fB\-G\fR, \fB\-mlocal\-sdata\fR and
  \&\fB\-mextern\-sdata\fR.  \fB\-mgpopt\fR is the default for all
  configurations.
--- 26375,26388 ----
  small data limits.  You can do this by compiling the library with
  the highest supported \fB\-G\fR setting and additionally using
  \&\fB\-mno\-extern\-sdata\fR to stop the library from making assumptions
! about externally\-defined data.
! .IP \fB\-mgpopt\fR 4
  .IX Item "-mgpopt"
  .PD 0
! .IP \fB\-mno\-gpopt\fR 4
  .IX Item "-mno-gpopt"
  .PD
! Use (do not use) GP\-relative accesses for symbols that are known to be
  in a small data section; see \fB\-G\fR, \fB\-mlocal\-sdata\fR and
  \&\fB\-mextern\-sdata\fR.  \fB\-mgpopt\fR is the default for all
  configurations.
*************** with \fB\-G0\fR.)
*** 26465,26553 ****
  .Sp
  \&\fB\-mno\-gpopt\fR implies \fB\-mno\-local\-sdata\fR and
  \&\fB\-mno\-extern\-sdata\fR.
! .IP "\fB\-membedded\-data\fR" 4
  .IX Item "-membedded-data"
  .PD 0
! .IP "\fB\-mno\-embedded\-data\fR" 4
  .IX Item "-mno-embedded-data"
  .PD
! Allocate variables to the read-only data section first if possible, then
  next in the small data section if possible, otherwise in data.  This gives
! slightly slower code than the default, but reduces the amount of \s-1RAM\s0 required
  when executing, and thus may be preferred for some embedded systems.
! .IP "\fB\-muninit\-const\-in\-rodata\fR" 4
  .IX Item "-muninit-const-in-rodata"
  .PD 0
! .IP "\fB\-mno\-uninit\-const\-in\-rodata\fR" 4
  .IX Item "-mno-uninit-const-in-rodata"
  .PD
! Put uninitialized \f(CW\*(C`const\*(C'\fR variables in the read-only data section.
  This option is only meaningful in conjunction with \fB\-membedded\-data\fR.
! .IP "\fB\-mcode\-readable=\fR\fIsetting\fR" 4
  .IX Item "-mcode-readable=setting"
! Specify whether \s-1GCC\s0 may generate code that reads from executable sections.
  There are three possible settings:
  .RS 4
! .IP "\fB\-mcode\-readable=yes\fR" 4
  .IX Item "-mcode-readable=yes"
  Instructions may freely access executable sections.  This is the
  default setting.
! .IP "\fB\-mcode\-readable=pcrel\fR" 4
  .IX Item "-mcode-readable=pcrel"
! \&\s-1MIPS16\s0 PC-relative load instructions can access executable sections,
  but other instructions must not do so.  This option is useful on 4KSc
  and 4KSd processors when the code TLBs have the Read Inhibit bit set.
  It is also useful on processors that can be configured to have a dual
! instruction/data \s-1SRAM\s0 interface and that, like the M4K, automatically
! redirect PC-relative loads to the instruction \s-1RAM.\s0
! .IP "\fB\-mcode\-readable=no\fR" 4
  .IX Item "-mcode-readable=no"
  Instructions must not access executable sections.  This option can be
  useful on targets that are configured to have a dual instruction/data
! \&\s-1SRAM\s0 interface but that (unlike the M4K) do not automatically redirect
! PC-relative loads to the instruction \s-1RAM.\s0
  .RE
  .RS 4
  .RE
! .IP "\fB\-msplit\-addresses\fR" 4
  .IX Item "-msplit-addresses"
  .PD 0
! .IP "\fB\-mno\-split\-addresses\fR" 4
  .IX Item "-mno-split-addresses"
  .PD
! Enable (disable) use of the \f(CW\*(C`%hi()\*(C'\fR and \f(CW\*(C`%lo()\*(C'\fR assembler
  relocation operators.  This option has been superseded by
  \&\fB\-mexplicit\-relocs\fR but is retained for backwards compatibility.
! .IP "\fB\-mexplicit\-relocs\fR" 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP "\fB\-mno\-explicit\-relocs\fR" 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Use (do not use) assembler relocation operators when dealing with symbolic
  addresses.  The alternative, selected by \fB\-mno\-explicit\-relocs\fR,
  is to use assembler macros instead.
  .Sp
! \&\fB\-mexplicit\-relocs\fR is the default if \s-1GCC\s0 was configured
  to use an assembler that supports relocation operators.
! .IP "\fB\-mcheck\-zero\-division\fR" 4
  .IX Item "-mcheck-zero-division"
  .PD 0
! .IP "\fB\-mno\-check\-zero\-division\fR" 4
  .IX Item "-mno-check-zero-division"
  .PD
  Trap (do not trap) on integer division by zero.
  .Sp
  The default is \fB\-mcheck\-zero\-division\fR.
! .IP "\fB\-mdivide\-traps\fR" 4
  .IX Item "-mdivide-traps"
  .PD 0
! .IP "\fB\-mdivide\-breaks\fR" 4
  .IX Item "-mdivide-breaks"
  .PD
! \&\s-1MIPS\s0 systems check for division by zero by generating either a
  conditional trap or a break instruction.  Using traps results in
! smaller code, but is only supported on \s-1MIPS II\s0 and later.  Also, some
  versions of the Linux kernel have a bug that prevents trap from
  generating the proper signal (\f(CW\*(C`SIGFPE\*(C'\fR).  Use \fB\-mdivide\-traps\fR to
  allow conditional traps on architectures that support them and
--- 26396,26484 ----
  .Sp
  \&\fB\-mno\-gpopt\fR implies \fB\-mno\-local\-sdata\fR and
  \&\fB\-mno\-extern\-sdata\fR.
! .IP \fB\-membedded\-data\fR 4
  .IX Item "-membedded-data"
  .PD 0
! .IP \fB\-mno\-embedded\-data\fR 4
  .IX Item "-mno-embedded-data"
  .PD
! Allocate variables to the read\-only data section first if possible, then
  next in the small data section if possible, otherwise in data.  This gives
! slightly slower code than the default, but reduces the amount of RAM required
  when executing, and thus may be preferred for some embedded systems.
! .IP \fB\-muninit\-const\-in\-rodata\fR 4
  .IX Item "-muninit-const-in-rodata"
  .PD 0
! .IP \fB\-mno\-uninit\-const\-in\-rodata\fR 4
  .IX Item "-mno-uninit-const-in-rodata"
  .PD
! Put uninitialized \f(CW\*(C`const\*(C'\fR variables in the read\-only data section.
  This option is only meaningful in conjunction with \fB\-membedded\-data\fR.
! .IP \fB\-mcode\-readable=\fR\fIsetting\fR 4
  .IX Item "-mcode-readable=setting"
! Specify whether GCC may generate code that reads from executable sections.
  There are three possible settings:
  .RS 4
! .IP \fB\-mcode\-readable=yes\fR 4
  .IX Item "-mcode-readable=yes"
  Instructions may freely access executable sections.  This is the
  default setting.
! .IP \fB\-mcode\-readable=pcrel\fR 4
  .IX Item "-mcode-readable=pcrel"
! 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.
! .IP \fB\-mcode\-readable=no\fR 4
  .IX Item "-mcode-readable=no"
  Instructions must not access executable sections.  This option can be
  useful on targets that are configured to have a dual instruction/data
! SRAM interface but that (unlike the M4K) do not automatically redirect
! PC\-relative loads to the instruction RAM.
  .RE
  .RS 4
  .RE
! .IP \fB\-msplit\-addresses\fR 4
  .IX Item "-msplit-addresses"
  .PD 0
! .IP \fB\-mno\-split\-addresses\fR 4
  .IX Item "-mno-split-addresses"
  .PD
! Enable (disable) use of the \f(CW%hi()\fR and \f(CW%lo()\fR assembler
  relocation operators.  This option has been superseded by
  \&\fB\-mexplicit\-relocs\fR but is retained for backwards compatibility.
! .IP \fB\-mexplicit\-relocs\fR 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP \fB\-mno\-explicit\-relocs\fR 4
  .IX Item "-mno-explicit-relocs"
  .PD
  Use (do not use) assembler relocation operators when dealing with symbolic
  addresses.  The alternative, selected by \fB\-mno\-explicit\-relocs\fR,
  is to use assembler macros instead.
  .Sp
! \&\fB\-mexplicit\-relocs\fR is the default if GCC was configured
  to use an assembler that supports relocation operators.
! .IP \fB\-mcheck\-zero\-division\fR 4
  .IX Item "-mcheck-zero-division"
  .PD 0
! .IP \fB\-mno\-check\-zero\-division\fR 4
  .IX Item "-mno-check-zero-division"
  .PD
  Trap (do not trap) on integer division by zero.
  .Sp
  The default is \fB\-mcheck\-zero\-division\fR.
! .IP \fB\-mdivide\-traps\fR 4
  .IX Item "-mdivide-traps"
  .PD 0
! .IP \fB\-mdivide\-breaks\fR 4
  .IX Item "-mdivide-breaks"
  .PD
! 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 (\f(CW\*(C`SIGFPE\*(C'\fR).  Use \fB\-mdivide\-traps\fR to
  allow conditional traps on architectures that support them and
*************** allow conditional traps on architectures
*** 26555,26595 ****
  .Sp
  The default is usually \fB\-mdivide\-traps\fR, but this can be
  overridden at configure time using \fB\-\-with\-divide=breaks\fR.
! Divide-by-zero checks can be completely disabled using
  \&\fB\-mno\-check\-zero\-division\fR.
! .IP "\fB\-mload\-store\-pairs\fR" 4
  .IX Item "-mload-store-pairs"
  .PD 0
! .IP "\fB\-mno\-load\-store\-pairs\fR" 4
  .IX Item "-mno-load-store-pairs"
  .PD
  Enable (disable) an optimization that pairs consecutive load or store
  instructions to enable load/store bonding.  This option is enabled by
  default but only takes effect when the selected architecture is known
  to support bonding.
! .IP "\fB\-munaligned\-access\fR" 4
  .IX Item "-munaligned-access"
  .PD 0
! .IP "\fB\-mno\-unaligned\-access\fR" 4
  .IX Item "-mno-unaligned-access"
  .PD
! Enable (disable) direct unaligned access for \s-1MIPS\s0 Release 6.
! MIPSr6 requires load/store unaligned-access support,
  by hardware or trap&emulate.
  So \fB\-mno\-unaligned\-access\fR may be needed by kernel.
! .IP "\fB\-mmemcpy\fR" 4
  .IX Item "-mmemcpy"
  .PD 0
! .IP "\fB\-mno\-memcpy\fR" 4
  .IX Item "-mno-memcpy"
  .PD
! Force (do not force) the use of \f(CW\*(C`memcpy\*(C'\fR for non-trivial block
! moves.  The default is \fB\-mno\-memcpy\fR, which allows \s-1GCC\s0 to inline
! most constant-sized copies.
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP "\fB\-mno\-long\-calls\fR" 4
  .IX Item "-mno-long-calls"
  .PD
  Disable (do not disable) use of the \f(CW\*(C`jal\*(C'\fR instruction.  Calling
--- 26486,26526 ----
  .Sp
  The default is usually \fB\-mdivide\-traps\fR, but this can be
  overridden at configure time using \fB\-\-with\-divide=breaks\fR.
! Divide\-by\-zero checks can be completely disabled using
  \&\fB\-mno\-check\-zero\-division\fR.
! .IP \fB\-mload\-store\-pairs\fR 4
  .IX Item "-mload-store-pairs"
  .PD 0
! .IP \fB\-mno\-load\-store\-pairs\fR 4
  .IX Item "-mno-load-store-pairs"
  .PD
  Enable (disable) an optimization that pairs consecutive load or store
  instructions to enable load/store bonding.  This option is enabled by
  default but only takes effect when the selected architecture is known
  to support bonding.
! .IP \fB\-munaligned\-access\fR 4
  .IX Item "-munaligned-access"
  .PD 0
! .IP \fB\-mno\-unaligned\-access\fR 4
  .IX Item "-mno-unaligned-access"
  .PD
! Enable (disable) direct unaligned access for MIPS Release 6.
! MIPSr6 requires load/store unaligned\-access support,
  by hardware or trap&emulate.
  So \fB\-mno\-unaligned\-access\fR may be needed by kernel.
! .IP \fB\-mmemcpy\fR 4
  .IX Item "-mmemcpy"
  .PD 0
! .IP \fB\-mno\-memcpy\fR 4
  .IX Item "-mno-memcpy"
  .PD
! Force (do not force) the use of \f(CW\*(C`memcpy\*(C'\fR for non\-trivial block
! moves.  The default is \fB\-mno\-memcpy\fR, which allows GCC to inline
! most constant\-sized copies.
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP \fB\-mno\-long\-calls\fR 4
  .IX Item "-mno-long-calls"
  .PD
  Disable (do not disable) use of the \f(CW\*(C`jal\*(C'\fR instruction.  Calling
*************** and callee to be in the same 256 megabyt
*** 26598,26706 ****
  .Sp
  This option has no effect on abicalls code.  The default is
  \&\fB\-mno\-long\-calls\fR.
! .IP "\fB\-mmad\fR" 4
  .IX Item "-mmad"
  .PD 0
! .IP "\fB\-mno\-mad\fR" 4
  .IX Item "-mno-mad"
  .PD
  Enable (disable) use of the \f(CW\*(C`mad\*(C'\fR, \f(CW\*(C`madu\*(C'\fR and \f(CW\*(C`mul\*(C'\fR
! instructions, as provided by the R4650 \s-1ISA.\s0
! .IP "\fB\-mimadd\fR" 4
  .IX Item "-mimadd"
  .PD 0
! .IP "\fB\-mno\-imadd\fR" 4
  .IX Item "-mno-imadd"
  .PD
  Enable (disable) use of the \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR integer
  instructions.  The default is \fB\-mimadd\fR on architectures
  that support \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR except for the 74k 
  architecture where it was found to generate slower code.
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
! Enable (disable) use of the floating-point multiply-accumulate
  instructions, when they are available.  The default is
  \&\fB\-mfused\-madd\fR.
  .Sp
! On the R8000 \s-1CPU\s0 when multiply-accumulate instructions are used,
  the intermediate product is calculated to infinite precision
! and is not subject to the \s-1FCSR\s0 Flush to Zero bit.  This may be
  undesirable in some circumstances.  On other processors the result
  is numerically identical to the equivalent computation using
  separate multiply, add, subtract and negate instructions.
! .IP "\fB\-nocpp\fR" 4
  .IX Item "-nocpp"
! Tell the \s-1MIPS\s0 assembler to not run its preprocessor over user
  assembler files (with a \fB.s\fR suffix) when assembling them.
! .IP "\fB\-mfix\-24k\fR" 4
  .IX Item "-mfix-24k"
  .PD 0
! .IP "\fB\-mno\-fix\-24k\fR" 4
  .IX Item "-mno-fix-24k"
  .PD
  Work around the 24K E48 (lost data on stores during refill) errata.
! The workarounds are implemented by the assembler rather than by \s-1GCC.\s0
! .IP "\fB\-mfix\-r4000\fR" 4
  .IX Item "-mfix-r4000"
  .PD 0
! .IP "\fB\-mno\-fix\-r4000\fR" 4
  .IX Item "-mno-fix-r4000"
  .PD
! Work around certain R4000 \s-1CPU\s0 errata:
  .RS 4
! .IP "\-" 4
! A double-word or a variable shift may give an incorrect result if executed
  immediately after starting an integer division.
! .IP "\-" 4
! A double-word or a variable shift may give an incorrect result if executed
  while an integer multiplication is in progress.
! .IP "\-" 4
  An integer division may give an incorrect result if started in a delay slot
  of a taken branch or a jump.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mfix\-r4400\fR" 4
  .IX Item "-mfix-r4400"
  .PD 0
! .IP "\fB\-mno\-fix\-r4400\fR" 4
  .IX Item "-mno-fix-r4400"
  .PD
! Work around certain R4400 \s-1CPU\s0 errata:
  .RS 4
! .IP "\-" 4
! A double-word or a variable shift may give an incorrect result if executed
  immediately after starting an integer division.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mfix\-r10000\fR" 4
  .IX Item "-mfix-r10000"
  .PD 0
! .IP "\fB\-mno\-fix\-r10000\fR" 4
  .IX Item "-mno-fix-r10000"
  .PD
  Work around certain R10000 errata:
  .RS 4
! .IP "\-" 4
  \&\f(CW\*(C`ll\*(C'\fR/\f(CW\*(C`sc\*(C'\fR sequences may not behave atomically on revisions
  prior to 3.0.  They may deadlock on revisions 2.6 and earlier.
  .RE
  .RS 4
  .Sp
  This option can only be used if the target architecture supports
! branch-likely instructions.  \fB\-mfix\-r10000\fR is the default when
  \&\fB\-march=r10000\fR is used; \fB\-mno\-fix\-r10000\fR is the default
  otherwise.
  .RE
! .IP "\fB\-mfix\-r5900\fR" 4
  .IX Item "-mfix-r5900"
  .PD 0
! .IP "\fB\-mno\-fix\-r5900\fR" 4
  .IX Item "-mno-fix-r5900"
  .PD
  Do not attempt to schedule the preceding instruction into the delay slot
--- 26529,26637 ----
  .Sp
  This option has no effect on abicalls code.  The default is
  \&\fB\-mno\-long\-calls\fR.
! .IP \fB\-mmad\fR 4
  .IX Item "-mmad"
  .PD 0
! .IP \fB\-mno\-mad\fR 4
  .IX Item "-mno-mad"
  .PD
  Enable (disable) use of the \f(CW\*(C`mad\*(C'\fR, \f(CW\*(C`madu\*(C'\fR and \f(CW\*(C`mul\*(C'\fR
! instructions, as provided by the R4650 ISA.
! .IP \fB\-mimadd\fR 4
  .IX Item "-mimadd"
  .PD 0
! .IP \fB\-mno\-imadd\fR 4
  .IX Item "-mno-imadd"
  .PD
  Enable (disable) use of the \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR integer
  instructions.  The default is \fB\-mimadd\fR on architectures
  that support \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR except for the 74k 
  architecture where it was found to generate slower code.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
! Enable (disable) use of the floating\-point multiply\-accumulate
  instructions, when they are available.  The default is
  \&\fB\-mfused\-madd\fR.
  .Sp
! On the R8000 CPU when multiply\-accumulate instructions are used,
  the intermediate product is calculated to infinite precision
! and is not subject to the FCSR Flush to Zero bit.  This may be
  undesirable in some circumstances.  On other processors the result
  is numerically identical to the equivalent computation using
  separate multiply, add, subtract and negate instructions.
! .IP \fB\-nocpp\fR 4
  .IX Item "-nocpp"
! Tell the MIPS assembler to not run its preprocessor over user
  assembler files (with a \fB.s\fR suffix) when assembling them.
! .IP \fB\-mfix\-24k\fR 4
  .IX Item "-mfix-24k"
  .PD 0
! .IP \fB\-mno\-fix\-24k\fR 4
  .IX Item "-mno-fix-24k"
  .PD
  Work around the 24K E48 (lost data on stores during refill) errata.
! The workarounds are implemented by the assembler rather than by GCC.
! .IP \fB\-mfix\-r4000\fR 4
  .IX Item "-mfix-r4000"
  .PD 0
! .IP \fB\-mno\-fix\-r4000\fR 4
  .IX Item "-mno-fix-r4000"
  .PD
! Work around certain R4000 CPU errata:
  .RS 4
! .IP \- 4
! A double\-word or a variable shift may give an incorrect result if executed
  immediately after starting an integer division.
! .IP \- 4
! A double\-word or a variable shift may give an incorrect result if executed
  while an integer multiplication is in progress.
! .IP \- 4
  An integer division may give an incorrect result if started in a delay slot
  of a taken branch or a jump.
  .RE
  .RS 4
  .RE
! .IP \fB\-mfix\-r4400\fR 4
  .IX Item "-mfix-r4400"
  .PD 0
! .IP \fB\-mno\-fix\-r4400\fR 4
  .IX Item "-mno-fix-r4400"
  .PD
! Work around certain R4400 CPU errata:
  .RS 4
! .IP \- 4
! A double\-word or a variable shift may give an incorrect result if executed
  immediately after starting an integer division.
  .RE
  .RS 4
  .RE
! .IP \fB\-mfix\-r10000\fR 4
  .IX Item "-mfix-r10000"
  .PD 0
! .IP \fB\-mno\-fix\-r10000\fR 4
  .IX Item "-mno-fix-r10000"
  .PD
  Work around certain R10000 errata:
  .RS 4
! .IP \- 4
  \&\f(CW\*(C`ll\*(C'\fR/\f(CW\*(C`sc\*(C'\fR sequences may not behave atomically on revisions
  prior to 3.0.  They may deadlock on revisions 2.6 and earlier.
  .RE
  .RS 4
  .Sp
  This option can only be used if the target architecture supports
! branch\-likely instructions.  \fB\-mfix\-r10000\fR is the default when
  \&\fB\-march=r10000\fR is used; \fB\-mno\-fix\-r10000\fR is the default
  otherwise.
  .RE
! .IP \fB\-mfix\-r5900\fR 4
  .IX Item "-mfix-r5900"
  .PD 0
! .IP \fB\-mno\-fix\-r5900\fR 4
  .IX Item "-mno-fix-r5900"
  .PD
  Do not attempt to schedule the preceding instruction into the delay slot
*************** of a branch instruction placed at the en
*** 26708,26733 ****
  instructions or fewer and always schedule a \f(CW\*(C`nop\*(C'\fR instruction there
  instead.  The short loop bug under certain conditions causes loops to
  execute only once or twice, due to a hardware bug in the R5900 chip.  The
! workaround is implemented by the assembler rather than by \s-1GCC.\s0
! .IP "\fB\-mfix\-rm7000\fR" 4
  .IX Item "-mfix-rm7000"
  .PD 0
! .IP "\fB\-mno\-fix\-rm7000\fR" 4
  .IX Item "-mno-fix-rm7000"
  .PD
! Work around the \s-1RM7000\s0 \f(CW\*(C`dmult\*(C'\fR/\f(CW\*(C`dmultu\*(C'\fR errata.  The
! workarounds are implemented by the assembler rather than by \s-1GCC.\s0
! .IP "\fB\-mfix\-vr4120\fR" 4
  .IX Item "-mfix-vr4120"
  .PD 0
! .IP "\fB\-mno\-fix\-vr4120\fR" 4
  .IX Item "-mno-fix-vr4120"
  .PD
! Work around certain \s-1VR4120\s0 errata:
  .RS 4
! .IP "\-" 4
  \&\f(CW\*(C`dmultu\*(C'\fR does not always produce the correct result.
! .IP "\-" 4
  \&\f(CW\*(C`div\*(C'\fR and \f(CW\*(C`ddiv\*(C'\fR do not always produce the correct result if one
  of the operands is negative.
  .RE
--- 26639,26664 ----
  instructions or fewer and always schedule a \f(CW\*(C`nop\*(C'\fR instruction there
  instead.  The short loop bug under certain conditions causes loops to
  execute only once or twice, due to a hardware bug in the R5900 chip.  The
! workaround is implemented by the assembler rather than by GCC.
! .IP \fB\-mfix\-rm7000\fR 4
  .IX Item "-mfix-rm7000"
  .PD 0
! .IP \fB\-mno\-fix\-rm7000\fR 4
  .IX Item "-mno-fix-rm7000"
  .PD
! Work around the RM7000 \f(CW\*(C`dmult\*(C'\fR/\f(CW\*(C`dmultu\*(C'\fR errata.  The
! workarounds are implemented by the assembler rather than by GCC.
! .IP \fB\-mfix\-vr4120\fR 4
  .IX Item "-mfix-vr4120"
  .PD 0
! .IP \fB\-mno\-fix\-vr4120\fR 4
  .IX Item "-mno-fix-vr4120"
  .PD
! Work around certain VR4120 errata:
  .RS 4
! .IP \- 4
  \&\f(CW\*(C`dmultu\*(C'\fR does not always produce the correct result.
! .IP \- 4
  \&\f(CW\*(C`div\*(C'\fR and \f(CW\*(C`ddiv\*(C'\fR do not always produce the correct result if one
  of the operands is negative.
  .RE
*************** The workarounds for the division errata
*** 26737,26800 ****
  \&\fIlibgcc.a\fR.  At present, these functions are only provided by
  the \f(CW\*(C`mips64vr*\-elf\*(C'\fR configurations.
  .Sp
! Other \s-1VR4120\s0 errata require a \s-1NOP\s0 to be inserted between certain pairs of
! instructions.  These errata are handled by the assembler, not by \s-1GCC\s0 itself.
  .RE
! .IP "\fB\-mfix\-vr4130\fR" 4
  .IX Item "-mfix-vr4130"
! Work around the \s-1VR4130\s0 \f(CW\*(C`mflo\*(C'\fR/\f(CW\*(C`mfhi\*(C'\fR errata.  The
! workarounds are implemented by the assembler rather than by \s-1GCC,\s0
! although \s-1GCC\s0 avoids using \f(CW\*(C`mflo\*(C'\fR and \f(CW\*(C`mfhi\*(C'\fR if the
! \&\s-1VR4130\s0 \f(CW\*(C`macc\*(C'\fR, \f(CW\*(C`macchi\*(C'\fR, \f(CW\*(C`dmacc\*(C'\fR and \f(CW\*(C`dmacchi\*(C'\fR
  instructions are available instead.
! .IP "\fB\-mfix\-sb1\fR" 4
  .IX Item "-mfix-sb1"
  .PD 0
! .IP "\fB\-mno\-fix\-sb1\fR" 4
  .IX Item "-mno-fix-sb1"
  .PD
! Work around certain \s-1SB\-1 CPU\s0 core errata.
! (This flag currently works around the \s-1SB\-1\s0 revision 2
! \&\*(L"F1\*(R" and \*(L"F2\*(R" floating-point errata.)
! .IP "\fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR" 4
  .IX Item "-mr10k-cache-barrier=setting"
! Specify whether \s-1GCC\s0 should insert cache barriers to avoid the
  side effects of speculation on R10K processors.
  .Sp
  In common with many processors, the R10K tries to predict the outcome
  of a conditional branch and speculatively executes instructions from
! the \*(L"taken\*(R" branch.  It later aborts these instructions if the
  predicted outcome is wrong.  However, on the R10K, even aborted
  instructions can have side effects.
  .Sp
  This problem only affects kernel stores and, depending on the system,
! kernel loads.  As an example, a speculatively-executed store may load
  the target memory into cache and mark the cache line as dirty, even if
! the store itself is later aborted.  If a \s-1DMA\s0 operation writes to the
! same area of memory before the \*(L"dirty\*(R" line is flushed, the cached
! data overwrites the DMA-ed data.  See the R10K processor manual
  for a full description, including other potential problems.
  .Sp
  One workaround is to insert cache barrier instructions before every memory
  access that might be speculatively executed and that might have side
  effects even if aborted.  \fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR
! controls \s-1GCC\s0's implementation of this workaround.  It assumes that
  aborted accesses to any byte in the following regions does not have
  side effects:
  .RS 4
! .IP "1." 4
  .IX Item "1."
! the memory occupied by the current function's stack frame;
! .IP "2." 4
  .IX Item "2."
  the memory occupied by an incoming stack argument;
! .IP "3." 4
  .IX Item "3."
! the memory occupied by an object with a link-time-constant address.
  .RE
  .RS 4
  .Sp
! It is the kernel's responsibility to ensure that speculative
  accesses to these regions are indeed safe.
  .Sp
  If the input program contains a function declaration such as:
--- 26668,26731 ----
  \&\fIlibgcc.a\fR.  At present, these functions are only provided by
  the \f(CW\*(C`mips64vr*\-elf\*(C'\fR configurations.
  .Sp
! 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.
  .RE
! .IP \fB\-mfix\-vr4130\fR 4
  .IX Item "-mfix-vr4130"
! Work around the VR4130 \f(CW\*(C`mflo\*(C'\fR/\f(CW\*(C`mfhi\*(C'\fR errata.  The
! workarounds are implemented by the assembler rather than by GCC,
! although GCC avoids using \f(CW\*(C`mflo\*(C'\fR and \f(CW\*(C`mfhi\*(C'\fR if the
! VR4130 \f(CW\*(C`macc\*(C'\fR, \f(CW\*(C`macchi\*(C'\fR, \f(CW\*(C`dmacc\*(C'\fR and \f(CW\*(C`dmacchi\*(C'\fR
  instructions are available instead.
! .IP \fB\-mfix\-sb1\fR 4
  .IX Item "-mfix-sb1"
  .PD 0
! .IP \fB\-mno\-fix\-sb1\fR 4
  .IX Item "-mno-fix-sb1"
  .PD
! Work around certain SB\-1 CPU core errata.
! (This flag currently works around the SB\-1 revision 2
! "F1" and "F2" floating\-point errata.)
! .IP \fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR 4
  .IX Item "-mr10k-cache-barrier=setting"
! Specify whether GCC should insert cache barriers to avoid the
  side effects of speculation on R10K processors.
  .Sp
  In common with many processors, the R10K tries to predict the outcome
  of a conditional branch and speculatively executes instructions from
! the "taken" branch.  It later aborts these instructions if the
  predicted outcome is wrong.  However, on the R10K, even aborted
  instructions can have side effects.
  .Sp
  This problem only affects kernel stores and, depending on the system,
! kernel loads.  As an example, a speculatively\-executed store may load
  the target memory into cache and mark the cache line as dirty, even if
! the store itself is later aborted.  If a DMA operation writes to the
! same area of memory before the "dirty" line is flushed, the cached
! data overwrites the DMA\-ed data.  See the R10K processor manual
  for a full description, including other potential problems.
  .Sp
  One workaround is to insert cache barrier instructions before every memory
  access that might be speculatively executed and that might have side
  effects even if aborted.  \fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR
! controls GCC\*(Aqs implementation of this workaround.  It assumes that
  aborted accesses to any byte in the following regions does not have
  side effects:
  .RS 4
! .IP 1. 4
  .IX Item "1."
! the memory occupied by the current function\*(Aqs stack frame;
! .IP 2. 4
  .IX Item "2."
  the memory occupied by an incoming stack argument;
! .IP 3. 4
  .IX Item "3."
! the memory occupied by an object with a link\-time\-constant address.
  .RE
  .RS 4
  .Sp
! It is the kernel\*(Aqs responsibility to ensure that speculative
  accesses to these regions are indeed safe.
  .Sp
  If the input program contains a function declaration such as:
*************** If the input program contains a function
*** 26804,26833 ****
  .Ve
  .Sp
  then the implementation of \f(CW\*(C`foo\*(C'\fR must allow \f(CW\*(C`j foo\*(C'\fR and
! \&\f(CW\*(C`jal foo\*(C'\fR to be executed speculatively.  \s-1GCC\s0 honors this
! restriction for functions it compiles itself.  It expects non-GCC
! functions (such as hand-written assembly code) to do the same.
  .Sp
  The option has three forms:
! .IP "\fB\-mr10k\-cache\-barrier=load\-store\fR" 4
  .IX Item "-mr10k-cache-barrier=load-store"
  Insert a cache barrier before a load or store that might be
  speculatively executed and that might have side effects even
  if aborted.
! .IP "\fB\-mr10k\-cache\-barrier=store\fR" 4
  .IX Item "-mr10k-cache-barrier=store"
  Insert a cache barrier before a store that might be speculatively
  executed and that might have side effects even if aborted.
! .IP "\fB\-mr10k\-cache\-barrier=none\fR" 4
  .IX Item "-mr10k-cache-barrier=none"
  Disable the insertion of cache barriers.  This is the default setting.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mflush\-func=\fR\fIfunc\fR" 4
  .IX Item "-mflush-func=func"
  .PD 0
! .IP "\fB\-mno\-flush\-func\fR" 4
  .IX Item "-mno-flush-func"
  .PD
  Specifies the function to call to flush the I and D caches, or to not
--- 26735,26764 ----
  .Ve
  .Sp
  then the implementation of \f(CW\*(C`foo\*(C'\fR must allow \f(CW\*(C`j foo\*(C'\fR and
! \&\f(CW\*(C`jal foo\*(C'\fR to be executed speculatively.  GCC honors this
! restriction for functions it compiles itself.  It expects non\-GCC
! functions (such as hand\-written assembly code) to do the same.
  .Sp
  The option has three forms:
! .IP \fB\-mr10k\-cache\-barrier=load\-store\fR 4
  .IX Item "-mr10k-cache-barrier=load-store"
  Insert a cache barrier before a load or store that might be
  speculatively executed and that might have side effects even
  if aborted.
! .IP \fB\-mr10k\-cache\-barrier=store\fR 4
  .IX Item "-mr10k-cache-barrier=store"
  Insert a cache barrier before a store that might be speculatively
  executed and that might have side effects even if aborted.
! .IP \fB\-mr10k\-cache\-barrier=none\fR 4
  .IX Item "-mr10k-cache-barrier=none"
  Disable the insertion of cache barriers.  This is the default setting.
  .RE
  .RS 4
  .RE
! .IP \fB\-mflush\-func=\fR\fIfunc\fR 4
  .IX Item "-mflush-func=func"
  .PD 0
! .IP \fB\-mno\-flush\-func\fR 4
  .IX Item "-mno-flush-func"
  .PD
  Specifies the function to call to flush the I and D caches, or to not
*************** call any such function.  If called, the
*** 26835,26867 ****
  arguments as the common \f(CW\*(C`_flush_func\*(C'\fR, that is, the address of the
  memory range for which the cache is being flushed, the size of the
  memory range, and the number 3 (to flush both caches).  The default
! depends on the target \s-1GCC\s0 was configured for, but commonly is either
  \&\f(CW\*(C`_flush_func\*(C'\fR or \f(CW\*(C`_\|_cpu_flush\*(C'\fR.
! .IP "\fBmbranch\-cost=\fR\fInum\fR" 4
  .IX Item "mbranch-cost=num"
! Set the cost of branches to roughly \fInum\fR \*(L"simple\*(R" instructions.
  This cost is only a heuristic and is not guaranteed to produce
  consistent results across releases.  A zero cost redundantly selects
  the default, which is based on the \fB\-mtune\fR setting.
! .IP "\fB\-mbranch\-likely\fR" 4
  .IX Item "-mbranch-likely"
  .PD 0
! .IP "\fB\-mno\-branch\-likely\fR" 4
  .IX Item "-mno-branch-likely"
  .PD
  Enable or disable use of Branch Likely instructions, regardless of the
  default for the selected architecture.  By default, Branch Likely
  instructions may be generated if they are supported by the selected
! architecture.  An exception is for the \s-1MIPS32\s0 and \s-1MIPS64\s0 architectures
  and processors that implement those architectures; for those, Branch
! Likely instructions are not be generated by default because the \s-1MIPS32\s0
! and \s-1MIPS64\s0 architectures specifically deprecate their use.
! .IP "\fB\-mcompact\-branches=never\fR" 4
  .IX Item "-mcompact-branches=never"
  .PD 0
! .IP "\fB\-mcompact\-branches=optimal\fR" 4
  .IX Item "-mcompact-branches=optimal"
! .IP "\fB\-mcompact\-branches=always\fR" 4
  .IX Item "-mcompact-branches=always"
  .PD
  These options control which form of branches will be generated.  The
--- 26766,26798 ----
  arguments as the common \f(CW\*(C`_flush_func\*(C'\fR, that is, the address of the
  memory range for which the cache is being flushed, the size of the
  memory range, and the number 3 (to flush both caches).  The default
! depends on the target GCC was configured for, but commonly is either
  \&\f(CW\*(C`_flush_func\*(C'\fR or \f(CW\*(C`_\|_cpu_flush\*(C'\fR.
! .IP \fBmbranch\-cost=\fR\fInum\fR 4
  .IX Item "mbranch-cost=num"
! Set the cost of branches to roughly \fInum\fR "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 \fB\-mtune\fR setting.
! .IP \fB\-mbranch\-likely\fR 4
  .IX Item "-mbranch-likely"
  .PD 0
! .IP \fB\-mno\-branch\-likely\fR 4
  .IX Item "-mno-branch-likely"
  .PD
  Enable or disable use of Branch Likely instructions, regardless of the
  default for the selected architecture.  By default, Branch Likely
  instructions may be generated if they are supported by the selected
! architecture.  An exception is for the MIPS32 and MIPS64 architectures
  and processors that implement those architectures; for those, Branch
! Likely instructions are not be generated by default because the MIPS32
! and MIPS64 architectures specifically deprecate their use.
! .IP \fB\-mcompact\-branches=never\fR 4
  .IX Item "-mcompact-branches=never"
  .PD 0
! .IP \fB\-mcompact\-branches=optimal\fR 4
  .IX Item "-mcompact-branches=optimal"
! .IP \fB\-mcompact\-branches=always\fR 4
  .IX Item "-mcompact-branches=always"
  .PD
  These options control which form of branches will be generated.  The
*************** The \fB\-mcompact\-branches=never\fR opt
*** 26871,26877 ****
  instructions will never be generated.
  .Sp
  The \fB\-mcompact\-branches=always\fR option ensures that a compact
! branch instruction will be generated if available for \s-1MIPS\s0 Release 6 onwards.
  If a compact branch instruction is not available (or pre\-R6),
  a delay slot form of the branch will be used instead.
  .Sp
--- 26802,26808 ----
  instructions will never be generated.
  .Sp
  The \fB\-mcompact\-branches=always\fR option ensures that a compact
! branch instruction will be generated if available for MIPS Release 6 onwards.
  If a compact branch instruction is not available (or pre\-R6),
  a delay slot form of the branch will be used instead.
  .Sp
*************** The behaviour for MIPS16/microMIPS may c
*** 26880,26920 ****
  since they do have some compact branch instructions.
  .Sp
  The \fB\-mcompact\-branches=optimal\fR option will cause a delay slot
! branch to be used if one is available in the current \s-1ISA\s0 and the delay
  slot is successfully filled.  If the delay slot is not filled, a compact
  branch will be chosen if one is available.
! .IP "\fB\-mfp\-exceptions\fR" 4
  .IX Item "-mfp-exceptions"
  .PD 0
! .IP "\fB\-mno\-fp\-exceptions\fR" 4
  .IX Item "-mno-fp-exceptions"
  .PD
! Specifies whether \s-1FP\s0 exceptions are enabled.  This affects how
! \&\s-1FP\s0 instructions are scheduled for some processors.
! The default is that \s-1FP\s0 exceptions are
  enabled.
  .Sp
! For instance, on the \s-1SB\-1,\s0 if \s-1FP\s0 exceptions are disabled, and we are emitting
! 64\-bit code, then we can use both \s-1FP\s0 pipes.  Otherwise, we can only use one
! \&\s-1FP\s0 pipe.
! .IP "\fB\-mvr4130\-align\fR" 4
  .IX Item "-mvr4130-align"
  .PD 0
! .IP "\fB\-mno\-vr4130\-align\fR" 4
  .IX Item "-mno-vr4130-align"
  .PD
! The \s-1VR4130\s0 pipeline is two-way superscalar, but can only issue two
  instructions together if the first one is 8\-byte aligned.  When this
! option is enabled, \s-1GCC\s0 aligns pairs of instructions that it
  thinks should execute in parallel.
  .Sp
! This option only has an effect when optimizing for the \s-1VR4130.\s0
  It normally makes code faster, but at the expense of making it bigger.
  It is enabled by default at optimization level \fB\-O3\fR.
! .IP "\fB\-msynci\fR" 4
  .IX Item "-msynci"
  .PD 0
! .IP "\fB\-mno\-synci\fR" 4
  .IX Item "-mno-synci"
  .PD
  Enable (disable) generation of \f(CW\*(C`synci\*(C'\fR instructions on
--- 26811,26851 ----
  since they do have some compact branch instructions.
  .Sp
  The \fB\-mcompact\-branches=optimal\fR option will cause a delay slot
! branch to be used if one is available in the current ISA and the delay
  slot is successfully filled.  If the delay slot is not filled, a compact
  branch will be chosen if one is available.
! .IP \fB\-mfp\-exceptions\fR 4
  .IX Item "-mfp-exceptions"
  .PD 0
! .IP \fB\-mno\-fp\-exceptions\fR 4
  .IX Item "-mno-fp-exceptions"
  .PD
! Specifies whether FP exceptions are enabled.  This affects how
! FP instructions are scheduled for some processors.
! The default is that FP exceptions are
  enabled.
  .Sp
! 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.
! .IP \fB\-mvr4130\-align\fR 4
  .IX Item "-mvr4130-align"
  .PD 0
! .IP \fB\-mno\-vr4130\-align\fR 4
  .IX Item "-mno-vr4130-align"
  .PD
! The VR4130 pipeline is two\-way superscalar, but can only issue two
  instructions together if the first one is 8\-byte aligned.  When this
! option is enabled, GCC aligns pairs of instructions that it
  thinks should execute in parallel.
  .Sp
! 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 \fB\-O3\fR.
! .IP \fB\-msynci\fR 4
  .IX Item "-msynci"
  .PD 0
! .IP \fB\-mno\-synci\fR 4
  .IX Item "-mno-synci"
  .PD
  Enable (disable) generation of \f(CW\*(C`synci\*(C'\fR instructions on
*************** enabled) are generated when \f(CW\*(C`_\
*** 26923,27075 ****
  compiled.
  .Sp
  This option defaults to \fB\-mno\-synci\fR, but the default can be
! overridden by configuring \s-1GCC\s0 with \fB\-\-with\-synci\fR.
  .Sp
  When compiling code for single processor systems, it is generally safe
! to use \f(CW\*(C`synci\*(C'\fR.  However, on many multi-core (\s-1SMP\s0) systems, it
  does not invalidate the instruction caches on all cores and may lead
  to undefined behavior.
! .IP "\fB\-mrelax\-pic\-calls\fR" 4
  .IX Item "-mrelax-pic-calls"
  .PD 0
! .IP "\fB\-mno\-relax\-pic\-calls\fR" 4
  .IX Item "-mno-relax-pic-calls"
  .PD
! Try to turn \s-1PIC\s0 calls that are normally dispatched via register
  \&\f(CW$25\fR into direct calls.  This is only possible if the linker can
  resolve the destination at link time and if the destination is within
  range for a direct call.
  .Sp
! \&\fB\-mrelax\-pic\-calls\fR is the default if \s-1GCC\s0 was configured to use
  an assembler and a linker that support the \f(CW\*(C`.reloc\*(C'\fR assembly
  directive and \fB\-mexplicit\-relocs\fR is in effect.  With
  \&\fB\-mno\-explicit\-relocs\fR, this optimization can be performed by the
  assembler and the linker alone without help from the compiler.
! .IP "\fB\-mmcount\-ra\-address\fR" 4
  .IX Item "-mmcount-ra-address"
  .PD 0
! .IP "\fB\-mno\-mcount\-ra\-address\fR" 4
  .IX Item "-mno-mcount-ra-address"
  .PD
  Emit (do not emit) code that allows \f(CW\*(C`_mcount\*(C'\fR to modify the
! calling function's return address.  When enabled, this option extends
! the usual \f(CW\*(C`_mcount\*(C'\fR interface with a new \fIra-address\fR
  parameter, which has type \f(CW\*(C`intptr_t *\*(C'\fR and is passed in register
  \&\f(CW$12\fR.  \f(CW\*(C`_mcount\*(C'\fR can then modify the return address by
  doing both of the following:
  .RS 4
! .IP "*" 4
  Returning the new address in register \f(CW$31\fR.
! .IP "*" 4
! Storing the new address in \f(CW\*(C`*\f(CIra\-address\f(CW\*(C'\fR,
! if \fIra-address\fR is nonnull.
  .RE
  .RS 4
  .Sp
  The default is \fB\-mno\-mcount\-ra\-address\fR.
  .RE
! .IP "\fB\-mframe\-header\-opt\fR" 4
  .IX Item "-mframe-header-opt"
  .PD 0
! .IP "\fB\-mno\-frame\-header\-opt\fR" 4
  .IX Item "-mno-frame-header-opt"
  .PD
! Enable (disable) frame header optimization in the o32 \s-1ABI.\s0  When using the
! o32 \s-1ABI,\s0 calling functions will allocate 16 bytes on the stack for the called
  function to write out register arguments.  When enabled, this optimization
  will suppress the allocation of the frame header if it can be determined that
  it is unused.
  .Sp
  This optimization is off by default at all optimization levels.
! .IP "\fB\-mlxc1\-sxc1\fR" 4
  .IX Item "-mlxc1-sxc1"
  .PD 0
! .IP "\fB\-mno\-lxc1\-sxc1\fR" 4
  .IX Item "-mno-lxc1-sxc1"
  .PD
  When applicable, enable (disable) the generation of \f(CW\*(C`lwxc1\*(C'\fR,
  \&\f(CW\*(C`swxc1\*(C'\fR, \f(CW\*(C`ldxc1\*(C'\fR, \f(CW\*(C`sdxc1\*(C'\fR instructions.  Enabled by default.
! .IP "\fB\-mmadd4\fR" 4
  .IX Item "-mmadd4"
  .PD 0
! .IP "\fB\-mno\-madd4\fR" 4
  .IX Item "-mno-madd4"
  .PD
  When applicable, enable (disable) the generation of 4\-operand \f(CW\*(C`madd.s\*(C'\fR,
  \&\f(CW\*(C`madd.d\*(C'\fR and related instructions.  Enabled by default.
  .PP
! \fI\s-1MMIX\s0 Options\fR
  .IX Subsection "MMIX Options"
  .PP
! These options are defined for the \s-1MMIX:\s0
! .IP "\fB\-mlibfuncs\fR" 4
  .IX Item "-mlibfuncs"
  .PD 0
! .IP "\fB\-mno\-libfuncs\fR" 4
  .IX Item "-mno-libfuncs"
  .PD
  Specify that intrinsic library functions are being compiled, passing all
  values in registers, no matter the size.
! .IP "\fB\-mepsilon\fR" 4
  .IX Item "-mepsilon"
  .PD 0
! .IP "\fB\-mno\-epsilon\fR" 4
  .IX Item "-mno-epsilon"
  .PD
! Generate floating-point comparison instructions that compare with respect
  to the \f(CW\*(C`rE\*(C'\fR epsilon register.
! .IP "\fB\-mabi=mmixware\fR" 4
  .IX Item "-mabi=mmixware"
  .PD 0
! .IP "\fB\-mabi=gnu\fR" 4
  .IX Item "-mabi=gnu"
  .PD
  Generate code that passes function parameters and return values that (in
  the called function) are seen as registers \f(CW$0\fR and up, as opposed to
! the \s-1GNU ABI\s0 which uses global registers \f(CW$231\fR and up.
! .IP "\fB\-mzero\-extend\fR" 4
  .IX Item "-mzero-extend"
  .PD 0
! .IP "\fB\-mno\-zero\-extend\fR" 4
  .IX Item "-mno-zero-extend"
  .PD
  When reading data from memory in sizes shorter than 64 bits, use (do not
! use) zero-extending load instructions by default, rather than
! sign-extending ones.
! .IP "\fB\-mknuthdiv\fR" 4
  .IX Item "-mknuthdiv"
  .PD 0
! .IP "\fB\-mno\-knuthdiv\fR" 4
  .IX Item "-mno-knuthdiv"
  .PD
  Make the result of a division yielding a remainder have the same sign as
  the divisor.  With the default, \fB\-mno\-knuthdiv\fR, the sign of the
  remainder follows the sign of the dividend.  Both methods are
  arithmetically valid, the latter being almost exclusively used.
! .IP "\fB\-mtoplevel\-symbols\fR" 4
  .IX Item "-mtoplevel-symbols"
  .PD 0
! .IP "\fB\-mno\-toplevel\-symbols\fR" 4
  .IX Item "-mno-toplevel-symbols"
  .PD
  Prepend (do not prepend) a \fB:\fR to all global symbols, so the assembly
  code can be used with the \f(CW\*(C`PREFIX\*(C'\fR assembly directive.
! .IP "\fB\-melf\fR" 4
  .IX Item "-melf"
! Generate an executable in the \s-1ELF\s0 format, rather than the default
  \&\fBmmo\fR format used by the \fBmmix\fR simulator.
! .IP "\fB\-mbranch\-predict\fR" 4
  .IX Item "-mbranch-predict"
  .PD 0
! .IP "\fB\-mno\-branch\-predict\fR" 4
  .IX Item "-mno-branch-predict"
  .PD
! Use (do not use) the probable-branch instructions, when static branch
  prediction indicates a probable branch.
! .IP "\fB\-mbase\-addresses\fR" 4
  .IX Item "-mbase-addresses"
  .PD 0
! .IP "\fB\-mno\-base\-addresses\fR" 4
  .IX Item "-mno-base-addresses"
  .PD
  Generate (do not generate) code that uses \fIbase addresses\fR.  Using a
--- 26854,27006 ----
  compiled.
  .Sp
  This option defaults to \fB\-mno\-synci\fR, but the default can be
! overridden by configuring GCC with \fB\-\-with\-synci\fR.
  .Sp
  When compiling code for single processor systems, it is generally safe
! to use \f(CW\*(C`synci\*(C'\fR.  However, on many multi\-core (SMP) systems, it
  does not invalidate the instruction caches on all cores and may lead
  to undefined behavior.
! .IP \fB\-mrelax\-pic\-calls\fR 4
  .IX Item "-mrelax-pic-calls"
  .PD 0
! .IP \fB\-mno\-relax\-pic\-calls\fR 4
  .IX Item "-mno-relax-pic-calls"
  .PD
! Try to turn PIC calls that are normally dispatched via register
  \&\f(CW$25\fR into direct calls.  This is only possible if the linker can
  resolve the destination at link time and if the destination is within
  range for a direct call.
  .Sp
! \&\fB\-mrelax\-pic\-calls\fR is the default if GCC was configured to use
  an assembler and a linker that support the \f(CW\*(C`.reloc\*(C'\fR assembly
  directive and \fB\-mexplicit\-relocs\fR is in effect.  With
  \&\fB\-mno\-explicit\-relocs\fR, this optimization can be performed by the
  assembler and the linker alone without help from the compiler.
! .IP \fB\-mmcount\-ra\-address\fR 4
  .IX Item "-mmcount-ra-address"
  .PD 0
! .IP \fB\-mno\-mcount\-ra\-address\fR 4
  .IX Item "-mno-mcount-ra-address"
  .PD
  Emit (do not emit) code that allows \f(CW\*(C`_mcount\*(C'\fR to modify the
! calling function\*(Aqs return address.  When enabled, this option extends
! the usual \f(CW\*(C`_mcount\*(C'\fR interface with a new \fIra\-address\fR
  parameter, which has type \f(CW\*(C`intptr_t *\*(C'\fR and is passed in register
  \&\f(CW$12\fR.  \f(CW\*(C`_mcount\*(C'\fR can then modify the return address by
  doing both of the following:
  .RS 4
! .IP * 4
  Returning the new address in register \f(CW$31\fR.
! .IP * 4
! Storing the new address in \f(CW\*(C`*\fR\f(CIra\-address\fR\f(CW\*(C'\fR,
! if \fIra\-address\fR is nonnull.
  .RE
  .RS 4
  .Sp
  The default is \fB\-mno\-mcount\-ra\-address\fR.
  .RE
! .IP \fB\-mframe\-header\-opt\fR 4
  .IX Item "-mframe-header-opt"
  .PD 0
! .IP \fB\-mno\-frame\-header\-opt\fR 4
  .IX Item "-mno-frame-header-opt"
  .PD
! Enable (disable) frame header optimization in the o32 ABI.  When using the
! o32 ABI, calling functions will allocate 16 bytes on the stack for the called
  function to write out register arguments.  When enabled, this optimization
  will suppress the allocation of the frame header if it can be determined that
  it is unused.
  .Sp
  This optimization is off by default at all optimization levels.
! .IP \fB\-mlxc1\-sxc1\fR 4
  .IX Item "-mlxc1-sxc1"
  .PD 0
! .IP \fB\-mno\-lxc1\-sxc1\fR 4
  .IX Item "-mno-lxc1-sxc1"
  .PD
  When applicable, enable (disable) the generation of \f(CW\*(C`lwxc1\*(C'\fR,
  \&\f(CW\*(C`swxc1\*(C'\fR, \f(CW\*(C`ldxc1\*(C'\fR, \f(CW\*(C`sdxc1\*(C'\fR instructions.  Enabled by default.
! .IP \fB\-mmadd4\fR 4
  .IX Item "-mmadd4"
  .PD 0
! .IP \fB\-mno\-madd4\fR 4
  .IX Item "-mno-madd4"
  .PD
  When applicable, enable (disable) the generation of 4\-operand \f(CW\*(C`madd.s\*(C'\fR,
  \&\f(CW\*(C`madd.d\*(C'\fR and related instructions.  Enabled by default.
  .PP
! \fIMMIX Options\fR
  .IX Subsection "MMIX Options"
  .PP
! These options are defined for the MMIX:
! .IP \fB\-mlibfuncs\fR 4
  .IX Item "-mlibfuncs"
  .PD 0
! .IP \fB\-mno\-libfuncs\fR 4
  .IX Item "-mno-libfuncs"
  .PD
  Specify that intrinsic library functions are being compiled, passing all
  values in registers, no matter the size.
! .IP \fB\-mepsilon\fR 4
  .IX Item "-mepsilon"
  .PD 0
! .IP \fB\-mno\-epsilon\fR 4
  .IX Item "-mno-epsilon"
  .PD
! Generate floating\-point comparison instructions that compare with respect
  to the \f(CW\*(C`rE\*(C'\fR epsilon register.
! .IP \fB\-mabi=mmixware\fR 4
  .IX Item "-mabi=mmixware"
  .PD 0
! .IP \fB\-mabi=gnu\fR 4
  .IX Item "-mabi=gnu"
  .PD
  Generate code that passes function parameters and return values that (in
  the called function) are seen as registers \f(CW$0\fR and up, as opposed to
! the GNU ABI which uses global registers \f(CW$231\fR and up.
! .IP \fB\-mzero\-extend\fR 4
  .IX Item "-mzero-extend"
  .PD 0
! .IP \fB\-mno\-zero\-extend\fR 4
  .IX Item "-mno-zero-extend"
  .PD
  When reading data from memory in sizes shorter than 64 bits, use (do not
! use) zero\-extending load instructions by default, rather than
! sign\-extending ones.
! .IP \fB\-mknuthdiv\fR 4
  .IX Item "-mknuthdiv"
  .PD 0
! .IP \fB\-mno\-knuthdiv\fR 4
  .IX Item "-mno-knuthdiv"
  .PD
  Make the result of a division yielding a remainder have the same sign as
  the divisor.  With the default, \fB\-mno\-knuthdiv\fR, the sign of the
  remainder follows the sign of the dividend.  Both methods are
  arithmetically valid, the latter being almost exclusively used.
! .IP \fB\-mtoplevel\-symbols\fR 4
  .IX Item "-mtoplevel-symbols"
  .PD 0
! .IP \fB\-mno\-toplevel\-symbols\fR 4
  .IX Item "-mno-toplevel-symbols"
  .PD
  Prepend (do not prepend) a \fB:\fR to all global symbols, so the assembly
  code can be used with the \f(CW\*(C`PREFIX\*(C'\fR assembly directive.
! .IP \fB\-melf\fR 4
  .IX Item "-melf"
! Generate an executable in the ELF format, rather than the default
  \&\fBmmo\fR format used by the \fBmmix\fR simulator.
! .IP \fB\-mbranch\-predict\fR 4
  .IX Item "-mbranch-predict"
  .PD 0
! .IP \fB\-mno\-branch\-predict\fR 4
  .IX Item "-mno-branch-predict"
  .PD
! Use (do not use) the probable\-branch instructions, when static branch
  prediction indicates a probable branch.
! .IP \fB\-mbase\-addresses\fR 4
  .IX Item "-mbase-addresses"
  .PD 0
! .IP \fB\-mno\-base\-addresses\fR 4
  .IX Item "-mno-base-addresses"
  .PD
  Generate (do not generate) code that uses \fIbase addresses\fR.  Using a
*************** to 255 from the value held in the regist
*** 27080,27214 ****
  and fast code, but the number of different data items that can be
  addressed is limited.  This means that a program that uses lots of static
  data may require \fB\-mno\-base\-addresses\fR.
! .IP "\fB\-msingle\-exit\fR" 4
  .IX Item "-msingle-exit"
  .PD 0
! .IP "\fB\-mno\-single\-exit\fR" 4
  .IX Item "-mno-single-exit"
  .PD
  Force (do not force) generated code to have a single exit point in each
  function.
  .PP
! \fI\s-1MN10300\s0 Options\fR
  .IX Subsection "MN10300 Options"
  .PP
! These \fB\-m\fR options are defined for Matsushita \s-1MN10300\s0 architectures:
! .IP "\fB\-mmult\-bug\fR" 4
  .IX Item "-mmult-bug"
! Generate code to avoid bugs in the multiply instructions for the \s-1MN10300\s0
  processors.  This is the default.
! .IP "\fB\-mno\-mult\-bug\fR" 4
  .IX Item "-mno-mult-bug"
  Do not generate code to avoid bugs in the multiply instructions for the
! \&\s-1MN10300\s0 processors.
! .IP "\fB\-mam33\fR" 4
  .IX Item "-mam33"
! Generate code using features specific to the \s-1AM33\s0 processor.
! .IP "\fB\-mno\-am33\fR" 4
  .IX Item "-mno-am33"
! Do not generate code using features specific to the \s-1AM33\s0 processor.  This
  is the default.
! .IP "\fB\-mam33\-2\fR" 4
  .IX Item "-mam33-2"
! Generate code using features specific to the \s-1AM33/2.0\s0 processor.
! .IP "\fB\-mam34\fR" 4
  .IX Item "-mam34"
! Generate code using features specific to the \s-1AM34\s0 processor.
! .IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
  .IX Item "-mtune=cpu-type"
! Use the timing characteristics of the indicated \s-1CPU\s0 type when
  scheduling instructions.  This does not change the targeted processor
! type.  The \s-1CPU\s0 type must be one of \fBmn10300\fR, \fBam33\fR,
  \&\fBam33\-2\fR or \fBam34\fR.
! .IP "\fB\-mreturn\-pointer\-on\-d0\fR" 4
  .IX Item "-mreturn-pointer-on-d0"
  When generating a function that returns a pointer, return the pointer
  in both \f(CW\*(C`a0\*(C'\fR and \f(CW\*(C`d0\*(C'\fR.  Otherwise, the pointer is returned
  only in \f(CW\*(C`a0\*(C'\fR, and attempts to call such functions without a prototype
  result in errors.  Note that this option is on by default; use
  \&\fB\-mno\-return\-pointer\-on\-d0\fR to disable it.
! .IP "\fB\-mno\-crt0\fR" 4
  .IX Item "-mno-crt0"
! Do not link in the C run-time initialization object file.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Indicate to the linker that it should perform a relaxation optimization pass
  to shorten branches, calls and absolute memory addresses.  This option only
  has an effect when used on the command line for the final link step.
  .Sp
  This option makes symbolic debugging impossible.
! .IP "\fB\-mliw\fR" 4
  .IX Item "-mliw"
  Allow the compiler to generate \fILong Instruction Word\fR
! instructions if the target is the \fB\s-1AM33\s0\fR or later.  This is the
  default.  This option defines the preprocessor macro \f(CW\*(C`_\|_LIW_\|_\*(C'\fR.
! .IP "\fB\-mno\-liw\fR" 4
  .IX Item "-mno-liw"
  Do not allow the compiler to generate \fILong Instruction Word\fR
  instructions.  This option defines the preprocessor macro
  \&\f(CW\*(C`_\|_NO_LIW_\|_\*(C'\fR.
! .IP "\fB\-msetlb\fR" 4
  .IX Item "-msetlb"
! Allow the compiler to generate the \fI\s-1SETLB\s0\fR and \fILcc\fR
! instructions if the target is the \fB\s-1AM33\s0\fR or later.  This is the
  default.  This option defines the preprocessor macro \f(CW\*(C`_\|_SETLB_\|_\*(C'\fR.
! .IP "\fB\-mno\-setlb\fR" 4
  .IX Item "-mno-setlb"
! Do not allow the compiler to generate \fI\s-1SETLB\s0\fR or \fILcc\fR
  instructions.  This option defines the preprocessor macro
  \&\f(CW\*(C`_\|_NO_SETLB_\|_\*(C'\fR.
  .PP
  \fIMoxie Options\fR
  .IX Subsection "Moxie Options"
! .IP "\fB\-meb\fR" 4
  .IX Item "-meb"
! Generate big-endian code.  This is the default for \fBmoxie\-*\-*\fR
  configurations.
! .IP "\fB\-mel\fR" 4
  .IX Item "-mel"
! Generate little-endian code.
! .IP "\fB\-mmul.x\fR" 4
  .IX Item "-mmul.x"
  Generate mul.x and umul.x instructions.  This is the default for
  \&\fBmoxiebox\-*\-*\fR configurations.
! .IP "\fB\-mno\-crt0\fR" 4
  .IX Item "-mno-crt0"
! Do not link in the C run-time initialization object file.
  .PP
! \fI\s-1MSP430\s0 Options\fR
  .IX Subsection "MSP430 Options"
  .PP
! These options are defined for the \s-1MSP430:\s0
! .IP "\fB\-masm\-hex\fR" 4
  .IX Item "-masm-hex"
  Force assembly output to always use hex constants.  Normally such
  constants are signed decimals, but this option is available for
  testsuite and/or aesthetic purposes.
! .IP "\fB\-mmcu=\fR" 4
  .IX Item "-mmcu="
! Select the \s-1MCU\s0 to target.  This is used to create a C preprocessor
! symbol based upon the \s-1MCU\s0 name, converted to upper case and pre\- and
! post-fixed with \fB_\|_\fR.  This in turn is used by the
! \&\fImsp430.h\fR header file to select an MCU-specific supplementary
  header file.
  .Sp
! The option also sets the \s-1ISA\s0 to use.  If the \s-1MCU\s0 name is one that is
! known to only support the 430 \s-1ISA\s0 then that is selected, otherwise the
! 430X \s-1ISA\s0 is selected.  A generic \s-1MCU\s0 name of \fBmsp430\fR can also be
! used to select the 430 \s-1ISA.\s0  Similarly the generic \fBmsp430x\fR \s-1MCU\s0
! name selects the 430X \s-1ISA.\s0
  .Sp
! In addition an MCU-specific linker script is added to the linker
! command line.  The script's name is the name of the \s-1MCU\s0 with
  \&\fI.ld\fR appended.  Thus specifying \fB\-mmcu=xxx\fR on the \fBgcc\fR
  command line defines the C preprocessor symbol \f(CW\*(C`_\|_XXX_\|_\*(C'\fR and
  cause the linker to search for a script called \fIxxx.ld\fR.
  .Sp
! The \s-1ISA\s0 and hardware multiply supported for the different MCUs is hard-coded
! into \s-1GCC.\s0  However, an external \fBdevices.csv\fR file can be used to
! extend device support beyond those that have been hard-coded.
  .Sp
! \&\s-1GCC\s0 searches for the \fBdevices.csv\fR file using the following methods in the
  given precedence order, where the first method takes precendence over the
  second which takes precedence over the third.
  .RS 4
--- 27011,27145 ----
  and fast code, but the number of different data items that can be
  addressed is limited.  This means that a program that uses lots of static
  data may require \fB\-mno\-base\-addresses\fR.
! .IP \fB\-msingle\-exit\fR 4
  .IX Item "-msingle-exit"
  .PD 0
! .IP \fB\-mno\-single\-exit\fR 4
  .IX Item "-mno-single-exit"
  .PD
  Force (do not force) generated code to have a single exit point in each
  function.
  .PP
! \fIMN10300 Options\fR
  .IX Subsection "MN10300 Options"
  .PP
! These \fB\-m\fR options are defined for Matsushita MN10300 architectures:
! .IP \fB\-mmult\-bug\fR 4
  .IX Item "-mmult-bug"
! Generate code to avoid bugs in the multiply instructions for the MN10300
  processors.  This is the default.
! .IP \fB\-mno\-mult\-bug\fR 4
  .IX Item "-mno-mult-bug"
  Do not generate code to avoid bugs in the multiply instructions for the
! MN10300 processors.
! .IP \fB\-mam33\fR 4
  .IX Item "-mam33"
! Generate code using features specific to the AM33 processor.
! .IP \fB\-mno\-am33\fR 4
  .IX Item "-mno-am33"
! Do not generate code using features specific to the AM33 processor.  This
  is the default.
! .IP \fB\-mam33\-2\fR 4
  .IX Item "-mam33-2"
! Generate code using features specific to the AM33/2.0 processor.
! .IP \fB\-mam34\fR 4
  .IX Item "-mam34"
! Generate code using features specific to the AM34 processor.
! .IP \fB\-mtune=\fR\fIcpu\-type\fR 4
  .IX Item "-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 \fBmn10300\fR, \fBam33\fR,
  \&\fBam33\-2\fR or \fBam34\fR.
! .IP \fB\-mreturn\-pointer\-on\-d0\fR 4
  .IX Item "-mreturn-pointer-on-d0"
  When generating a function that returns a pointer, return the pointer
  in both \f(CW\*(C`a0\*(C'\fR and \f(CW\*(C`d0\*(C'\fR.  Otherwise, the pointer is returned
  only in \f(CW\*(C`a0\*(C'\fR, and attempts to call such functions without a prototype
  result in errors.  Note that this option is on by default; use
  \&\fB\-mno\-return\-pointer\-on\-d0\fR to disable it.
! .IP \fB\-mno\-crt0\fR 4
  .IX Item "-mno-crt0"
! Do not link in the C run\-time initialization object file.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Indicate to the linker that it should perform a relaxation optimization pass
  to shorten branches, calls and absolute memory addresses.  This option only
  has an effect when used on the command line for the final link step.
  .Sp
  This option makes symbolic debugging impossible.
! .IP \fB\-mliw\fR 4
  .IX Item "-mliw"
  Allow the compiler to generate \fILong Instruction Word\fR
! instructions if the target is the \fBAM33\fR or later.  This is the
  default.  This option defines the preprocessor macro \f(CW\*(C`_\|_LIW_\|_\*(C'\fR.
! .IP \fB\-mno\-liw\fR 4
  .IX Item "-mno-liw"
  Do not allow the compiler to generate \fILong Instruction Word\fR
  instructions.  This option defines the preprocessor macro
  \&\f(CW\*(C`_\|_NO_LIW_\|_\*(C'\fR.
! .IP \fB\-msetlb\fR 4
  .IX Item "-msetlb"
! Allow the compiler to generate the \fISETLB\fR and \fILcc\fR
! instructions if the target is the \fBAM33\fR or later.  This is the
  default.  This option defines the preprocessor macro \f(CW\*(C`_\|_SETLB_\|_\*(C'\fR.
! .IP \fB\-mno\-setlb\fR 4
  .IX Item "-mno-setlb"
! Do not allow the compiler to generate \fISETLB\fR or \fILcc\fR
  instructions.  This option defines the preprocessor macro
  \&\f(CW\*(C`_\|_NO_SETLB_\|_\*(C'\fR.
  .PP
  \fIMoxie Options\fR
  .IX Subsection "Moxie Options"
! .IP \fB\-meb\fR 4
  .IX Item "-meb"
! Generate big\-endian code.  This is the default for \fBmoxie\-*\-*\fR
  configurations.
! .IP \fB\-mel\fR 4
  .IX Item "-mel"
! Generate little\-endian code.
! .IP \fB\-mmul.x\fR 4
  .IX Item "-mmul.x"
  Generate mul.x and umul.x instructions.  This is the default for
  \&\fBmoxiebox\-*\-*\fR configurations.
! .IP \fB\-mno\-crt0\fR 4
  .IX Item "-mno-crt0"
! Do not link in the C run\-time initialization object file.
  .PP
! \fIMSP430 Options\fR
  .IX Subsection "MSP430 Options"
  .PP
! These options are defined for the MSP430:
! .IP \fB\-masm\-hex\fR 4
  .IX Item "-masm-hex"
  Force assembly output to always use hex constants.  Normally such
  constants are signed decimals, but this option is available for
  testsuite and/or aesthetic purposes.
! .IP \fB\-mmcu=\fR 4
  .IX Item "-mmcu="
! Select the MCU to target.  This is used to create a C preprocessor
! symbol based upon the MCU name, converted to upper case and pre\- and
! post\-fixed with \fB_\|_\fR.  This in turn is used by the
! \&\fImsp430.h\fR header file to select an MCU\-specific supplementary
  header file.
  .Sp
! The option also sets the ISA to use.  If the MCU name is one that is
! known to only support the 430 ISA then that is selected, otherwise the
! 430X ISA is selected.  A generic MCU name of \fBmsp430\fR can also be
! used to select the 430 ISA.  Similarly the generic \fBmsp430x\fR MCU
! name selects the 430X ISA.
  .Sp
! In addition an MCU\-specific linker script is added to the linker
! command line.  The script\*(Aqs name is the name of the MCU with
  \&\fI.ld\fR appended.  Thus specifying \fB\-mmcu=xxx\fR on the \fBgcc\fR
  command line defines the C preprocessor symbol \f(CW\*(C`_\|_XXX_\|_\*(C'\fR and
  cause the linker to search for a script called \fIxxx.ld\fR.
  .Sp
! The ISA and hardware multiply supported for the different MCUs is hard\-coded
! into GCC.  However, an external \fBdevices.csv\fR file can be used to
! extend device support beyond those that have been hard\-coded.
  .Sp
! GCC searches for the \fBdevices.csv\fR file using the following methods in the
  given precedence order, where the first method takes precendence over the
  second which takes precedence over the third.
  .RS 4
*************** second which takes precedence over the t
*** 27217,27286 ****
  .IX Item "Include path specified with -I and -L"
  \&\fBdevices.csv\fR will be searched for in each of the directories specified by
  include paths and linker library search paths.
! .IP "Path specified by the environment variable \fB\s-1MSP430_GCC_INCLUDE_DIR\s0\fR" 4
  .IX Item "Path specified by the environment variable MSP430_GCC_INCLUDE_DIR"
  Define the value of the global environment variable
! \&\fB\s-1MSP430_GCC_INCLUDE_DIR\s0\fR
! to the full path to the directory containing devices.csv, and \s-1GCC\s0 will search
  this directory for devices.csv.  If devices.csv is found, this directory will
  also be registered as an include path, and linker library path.  Header files
  and linker scripts in this directory can therefore be used without manually
  specifying \f(CW\*(C`\-I\*(C'\fR and \f(CW\*(C`\-L\*(C'\fR on the command line.
  .IP "The \fBmsp430\-elf{,bare}/include/devices\fR directory" 4
  .IX Item "The msp430-elf{,bare}/include/devices directory"
! Finally, \s-1GCC\s0 will examine \fBmsp430\-elf{,bare}/include/devices\fR from the
  toolchain root directory.  This directory does not exist in a default
  installation, but if the user has created it and copied \fBdevices.csv\fR
! there, then the \s-1MCU\s0 data will be read.  As above, this directory will
  also be registered as an include path, and linker library path.
  .RE
  .RS 4
  .Sp
  If none of the above search methods find \fBdevices.csv\fR, then the
! hard-coded \s-1MCU\s0 data is used.
  .RE
! .IP "\fB\-mwarn\-mcu\fR" 4
  .IX Item "-mwarn-mcu"
  .PD 0
! .IP "\fB\-mno\-warn\-mcu\fR" 4
  .IX Item "-mno-warn-mcu"
  .PD
  This option enables or disables warnings about conflicts between the
! \&\s-1MCU\s0 name specified by the \fB\-mmcu\fR option and the \s-1ISA\s0 set by the
  \&\fB\-mcpu\fR option and/or the hardware multiply support set by the
  \&\fB\-mhwmult\fR option.  It also toggles warnings about unrecognized
! \&\s-1MCU\s0 names.  This option is on by default.
! .IP "\fB\-mcpu=\fR" 4
  .IX Item "-mcpu="
! Specifies the \s-1ISA\s0 to use.  Accepted values are \fBmsp430\fR,
  \&\fBmsp430x\fR and \fBmsp430xv2\fR.  This option is deprecated.  The
! \&\fB\-mmcu=\fR option should be used to select the \s-1ISA.\s0
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Link to the simulator runtime libraries and linker script.  Overrides
  any scripts that would be selected by the \fB\-mmcu=\fR option.
! .IP "\fB\-mlarge\fR" 4
  .IX Item "-mlarge"
! Use large-model addressing (20\-bit pointers, 20\-bit \f(CW\*(C`size_t\*(C'\fR).
! .IP "\fB\-msmall\fR" 4
  .IX Item "-msmall"
! Use small-model addressing (16\-bit pointers, 16\-bit \f(CW\*(C`size_t\*(C'\fR).
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  This option is passed to the assembler and linker, and allows the
  linker to perform certain optimizations that cannot be done until
  the final link.
! .IP "\fBmhwmult=\fR" 4
  .IX Item "mhwmult="
  Describes the type of hardware multiply supported by the target.
  Accepted values are \fBnone\fR for no hardware multiply, \fB16bit\fR
  for the original 16\-bit\-only multiply supported by early MCUs.
  \&\fB32bit\fR for the 16/32\-bit multiply supported by later MCUs and
  \&\fBf5series\fR for the 16/32\-bit multiply supported by F5\-series MCUs.
! A value of \fBauto\fR can also be given.  This tells \s-1GCC\s0 to deduce
! the hardware multiply support based upon the \s-1MCU\s0 name provided by the
  \&\fB\-mmcu\fR option.  If no \fB\-mmcu\fR option is specified or if
! the \s-1MCU\s0 name is not recognized then no hardware multiply support is
  assumed.  \f(CW\*(C`auto\*(C'\fR is the default setting.
  .Sp
  Hardware multiplies are normally performed by calling a library
--- 27148,27217 ----
  .IX Item "Include path specified with -I and -L"
  \&\fBdevices.csv\fR will be searched for in each of the directories specified by
  include paths and linker library search paths.
! .IP "Path specified by the environment variable \fBMSP430_GCC_INCLUDE_DIR\fR" 4
  .IX Item "Path specified by the environment variable MSP430_GCC_INCLUDE_DIR"
  Define the value of the global environment variable
! \&\fBMSP430_GCC_INCLUDE_DIR\fR
! to the full path to the directory containing devices.csv, and GCC will search
  this directory for devices.csv.  If devices.csv is found, this directory will
  also be registered as an include path, and linker library path.  Header files
  and linker scripts in this directory can therefore be used without manually
  specifying \f(CW\*(C`\-I\*(C'\fR and \f(CW\*(C`\-L\*(C'\fR on the command line.
  .IP "The \fBmsp430\-elf{,bare}/include/devices\fR directory" 4
  .IX Item "The msp430-elf{,bare}/include/devices directory"
! Finally, GCC will examine \fBmsp430\-elf{,bare}/include/devices\fR from the
  toolchain root directory.  This directory does not exist in a default
  installation, but if the user has created it and copied \fBdevices.csv\fR
! there, then the MCU data will be read.  As above, this directory will
  also be registered as an include path, and linker library path.
  .RE
  .RS 4
  .Sp
  If none of the above search methods find \fBdevices.csv\fR, then the
! hard\-coded MCU data is used.
  .RE
! .IP \fB\-mwarn\-mcu\fR 4
  .IX Item "-mwarn-mcu"
  .PD 0
! .IP \fB\-mno\-warn\-mcu\fR 4
  .IX Item "-mno-warn-mcu"
  .PD
  This option enables or disables warnings about conflicts between the
! MCU name specified by the \fB\-mmcu\fR option and the ISA set by the
  \&\fB\-mcpu\fR option and/or the hardware multiply support set by the
  \&\fB\-mhwmult\fR option.  It also toggles warnings about unrecognized
! MCU names.  This option is on by default.
! .IP \fB\-mcpu=\fR 4
  .IX Item "-mcpu="
! Specifies the ISA to use.  Accepted values are \fBmsp430\fR,
  \&\fBmsp430x\fR and \fBmsp430xv2\fR.  This option is deprecated.  The
! \&\fB\-mmcu=\fR option should be used to select the ISA.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Link to the simulator runtime libraries and linker script.  Overrides
  any scripts that would be selected by the \fB\-mmcu=\fR option.
! .IP \fB\-mlarge\fR 4
  .IX Item "-mlarge"
! Use large\-model addressing (20\-bit pointers, 20\-bit \f(CW\*(C`size_t\*(C'\fR).
! .IP \fB\-msmall\fR 4
  .IX Item "-msmall"
! Use small\-model addressing (16\-bit pointers, 16\-bit \f(CW\*(C`size_t\*(C'\fR).
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  This option is passed to the assembler and linker, and allows the
  linker to perform certain optimizations that cannot be done until
  the final link.
! .IP \fBmhwmult=\fR 4
  .IX Item "mhwmult="
  Describes the type of hardware multiply supported by the target.
  Accepted values are \fBnone\fR for no hardware multiply, \fB16bit\fR
  for the original 16\-bit\-only multiply supported by early MCUs.
  \&\fB32bit\fR for the 16/32\-bit multiply supported by later MCUs and
  \&\fBf5series\fR for the 16/32\-bit multiply supported by F5\-series MCUs.
! A value of \fBauto\fR can also be given.  This tells GCC to deduce
! the hardware multiply support based upon the MCU name provided by the
  \&\fB\-mmcu\fR option.  If no \fB\-mmcu\fR option is specified or if
! the MCU name is not recognized then no hardware multiply support is
  assumed.  \f(CW\*(C`auto\*(C'\fR is the default setting.
  .Sp
  Hardware multiplies are normally performed by calling a library
*************** inline.  This makes for bigger, but fast
*** 27291,27315 ****
  The hardware multiply routines disable interrupts whilst running and
  restore the previous interrupt state when they finish.  This makes
  them safe to use inside interrupt handlers as well as in normal code.
! .IP "\fB\-minrt\fR" 4
  .IX Item "-minrt"
  Enable the use of a minimum runtime environment \- no static
! initializers or constructors.  This is intended for memory-constrained
  devices.  The compiler includes special symbols in some objects
  that tell the linker and runtime which code fragments are required.
! .IP "\fB\-mtiny\-printf\fR" 4
  .IX Item "-mtiny-printf"
  Enable reduced code size \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`puts\*(C'\fR library functions.
  The \fBtiny\fR implementations of these functions are not reentrant, so
! must be used with caution in multi-threaded applications.
  .Sp
  Support for streams has been removed and the string to be printed will
  always be sent to stdout via the \f(CW\*(C`write\*(C'\fR syscall.  The string is not
  buffered before it is sent to write.
  .Sp
! This option requires Newlib Nano \s-1IO,\s0 so \s-1GCC\s0 must be configured with
  \&\fB\-\-enable\-newlib\-nano\-formatted\-io\fR.
! .IP "\fB\-mmax\-inline\-shift=\fR" 4
  .IX Item "-mmax-inline-shift="
  This option takes an integer between 0 and 64 inclusive, and sets
  the maximum number of inline shift instructions which should be emitted to
--- 27222,27246 ----
  The hardware multiply routines disable interrupts whilst running and
  restore the previous interrupt state when they finish.  This makes
  them safe to use inside interrupt handlers as well as in normal code.
! .IP \fB\-minrt\fR 4
  .IX Item "-minrt"
  Enable the use of a minimum runtime environment \- no static
! initializers or constructors.  This is intended for memory\-constrained
  devices.  The compiler includes special symbols in some objects
  that tell the linker and runtime which code fragments are required.
! .IP \fB\-mtiny\-printf\fR 4
  .IX Item "-mtiny-printf"
  Enable reduced code size \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`puts\*(C'\fR library functions.
  The \fBtiny\fR implementations of these functions are not reentrant, so
! must be used with caution in multi\-threaded applications.
  .Sp
  Support for streams has been removed and the string to be printed will
  always be sent to stdout via the \f(CW\*(C`write\*(C'\fR syscall.  The string is not
  buffered before it is sent to write.
  .Sp
! This option requires Newlib Nano IO, so GCC must be configured with
  \&\fB\-\-enable\-newlib\-nano\-formatted\-io\fR.
! .IP \fB\-mmax\-inline\-shift=\fR 4
  .IX Item "-mmax-inline-shift="
  This option takes an integer between 0 and 64 inclusive, and sets
  the maximum number of inline shift instructions which should be emitted to
*************** perform a shift operation by a constant
*** 27317,27330 ****
  exceeded, an mspabi helper function is used instead.  The default value is 4.
  .Sp
  This only affects cases where a shift by multiple positions cannot be
! completed with a single instruction (e.g. all shifts >1 on the 430 \s-1ISA\s0).
  .Sp
  Shifts of a 32\-bit value are at least twice as costly, so the value passed for
  this option is divided by 2 and the resulting value used instead.
! .IP "\fB\-mcode\-region=\fR" 4
  .IX Item "-mcode-region="
  .PD 0
! .IP "\fB\-mdata\-region=\fR" 4
  .IX Item "-mdata-region="
  .PD
  These options tell the compiler where to place functions and data that
--- 27248,27261 ----
  exceeded, an mspabi helper function is used instead.  The default value is 4.
  .Sp
  This only affects cases where a shift by multiple positions cannot be
! completed with a single instruction (e.g. all shifts >1 on the 430 ISA).
  .Sp
  Shifts of a 32\-bit value are at least twice as costly, so the value passed for
  this option is divided by 2 and the resulting value used instead.
! .IP \fB\-mcode\-region=\fR 4
  .IX Item "-mcode-region="
  .PD 0
! .IP \fB\-mdata\-region=\fR 4
  .IX Item "-mdata-region="
  .PD
  These options tell the compiler where to place functions and data that
*************** like the corresponding attribute.  The f
*** 27335,27492 ****
  \&\f(CW\*(C`any\*(C'\fR \- is the default.  It leaves placement entirely up to the
  linker script and how it assigns the standard sections
  (\f(CW\*(C`.text\*(C'\fR, \f(CW\*(C`.data\*(C'\fR, etc) to the memory regions.
! .IP "\fB\-msilicon\-errata=\fR" 4
  .IX Item "-msilicon-errata="
  This option passes on a request to assembler to enable the fixes for
  the named silicon errata.
! .IP "\fB\-msilicon\-errata\-warn=\fR" 4
  .IX Item "-msilicon-errata-warn="
  This option passes on a request to the assembler to enable warning
  messages when a silicon errata might need to be applied.
! .IP "\fB\-mwarn\-devices\-csv\fR" 4
  .IX Item "-mwarn-devices-csv"
  .PD 0
! .IP "\fB\-mno\-warn\-devices\-csv\fR" 4
  .IX Item "-mno-warn-devices-csv"
  .PD
  Warn if \fBdevices.csv\fR is not found or there are problem parsing it
  (default: on).
  .PP
! \fI\s-1NDS32\s0 Options\fR
  .IX Subsection "NDS32 Options"
  .PP
! These options are defined for \s-1NDS32\s0 implementations:
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate code in big-endian mode.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate code in little-endian mode.
! .IP "\fB\-mreduced\-regs\fR" 4
  .IX Item "-mreduced-regs"
! Use reduced-set registers for register allocation.
! .IP "\fB\-mfull\-regs\fR" 4
  .IX Item "-mfull-regs"
! Use full-set registers for register allocation.
! .IP "\fB\-mcmov\fR" 4
  .IX Item "-mcmov"
  Generate conditional move instructions.
! .IP "\fB\-mno\-cmov\fR" 4
  .IX Item "-mno-cmov"
  Do not generate conditional move instructions.
! .IP "\fB\-mext\-perf\fR" 4
  .IX Item "-mext-perf"
  Generate performance extension instructions.
! .IP "\fB\-mno\-ext\-perf\fR" 4
  .IX Item "-mno-ext-perf"
  Do not generate performance extension instructions.
! .IP "\fB\-mext\-perf2\fR" 4
  .IX Item "-mext-perf2"
  Generate performance extension 2 instructions.
! .IP "\fB\-mno\-ext\-perf2\fR" 4
  .IX Item "-mno-ext-perf2"
  Do not generate performance extension 2 instructions.
! .IP "\fB\-mext\-string\fR" 4
  .IX Item "-mext-string"
  Generate string extension instructions.
! .IP "\fB\-mno\-ext\-string\fR" 4
  .IX Item "-mno-ext-string"
  Do not generate string extension instructions.
! .IP "\fB\-mv3push\fR" 4
  .IX Item "-mv3push"
  Generate v3 push25/pop25 instructions.
! .IP "\fB\-mno\-v3push\fR" 4
  .IX Item "-mno-v3push"
  Do not generate v3 push25/pop25 instructions.
! .IP "\fB\-m16\-bit\fR" 4
  .IX Item "-m16-bit"
  Generate 16\-bit instructions.
! .IP "\fB\-mno\-16\-bit\fR" 4
  .IX Item "-mno-16-bit"
  Do not generate 16\-bit instructions.
! .IP "\fB\-misr\-vector\-size=\fR\fInum\fR" 4
  .IX Item "-misr-vector-size=num"
  Specify the size of each interrupt vector, which must be 4 or 16.
! .IP "\fB\-mcache\-block\-size=\fR\fInum\fR" 4
  .IX Item "-mcache-block-size=num"
  Specify the size of each cache block,
  which must be a power of 2 between 4 and 512.
! .IP "\fB\-march=\fR\fIarch\fR" 4
  .IX Item "-march=arch"
  Specify the name of the target architecture.
! .IP "\fB\-mcmodel=\fR\fIcode-model\fR" 4
  .IX Item "-mcmodel=code-model"
  Set the code model to one of
  .RS 4
! .IP "\fBsmall\fR" 4
  .IX Item "small"
! All the data and read-only data segments must be within 512KB addressing space.
  The text segment must be within 16MB addressing space.
! .IP "\fBmedium\fR" 4
  .IX Item "medium"
! The data segment must be within 512KB while the read-only data segment can be
  within 4GB addressing space.  The text segment should be still within 16MB
  addressing space.
! .IP "\fBlarge\fR" 4
  .IX Item "large"
  All the text and data segments can be within 4GB addressing space.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mctor\-dtor\fR" 4
  .IX Item "-mctor-dtor"
  Enable constructor/destructor feature.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Guide linker to relax instructions.
  .PP
! \fINios \s-1II\s0 Options\fR
  .IX Subsection "Nios II Options"
  .PP
! These are the options defined for the Altera Nios \s-1II\s0 processor.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  Put global and static objects less than or equal to \fInum\fR bytes
! into the small data or \s-1BSS\s0 sections instead of the normal data or \s-1BSS\s0
  sections.  The default value of \fInum\fR is 8.
! .IP "\fB\-mgpopt=\fR\fIoption\fR" 4
  .IX Item "-mgpopt=option"
  .PD 0
! .IP "\fB\-mgpopt\fR" 4
  .IX Item "-mgpopt"
! .IP "\fB\-mno\-gpopt\fR" 4
  .IX Item "-mno-gpopt"
  .PD
! Generate (do not generate) GP-relative accesses.  The following 
  \&\fIoption\fR names are recognized:
  .RS 4
! .IP "\fBnone\fR" 4
  .IX Item "none"
! Do not generate GP-relative accesses.
! .IP "\fBlocal\fR" 4
  .IX Item "local"
! Generate GP-relative accesses for small data objects that are not 
  external, weak, or uninitialized common symbols.  
! Also use GP-relative addressing for objects that
  have been explicitly placed in a small data section via a \f(CW\*(C`section\*(C'\fR
  attribute.
! .IP "\fBglobal\fR" 4
  .IX Item "global"
! As for \fBlocal\fR, but also generate GP-relative accesses for
  small data objects that are external, weak, or common.  If you use this option,
  you must ensure that all parts of your program (including libraries) are
  compiled with the same \fB\-G\fR setting.
! .IP "\fBdata\fR" 4
  .IX Item "data"
! Generate GP-relative accesses for all data objects in the program.  If you
! use this option, the entire data and \s-1BSS\s0 segments
  of your program must fit in 64K of memory and you must use an appropriate
  linker script to allocate them within the addressable range of the
  global pointer.
! .IP "\fBall\fR" 4
  .IX Item "all"
! Generate GP-relative addresses for function pointers as well as data
! pointers.  If you use this option, the entire text, data, and \s-1BSS\s0 segments
  of your program must fit in 64K of memory and you must use an appropriate
  linker script to allocate them within the addressable range of the
  global pointer.
--- 27266,27423 ----
  \&\f(CW\*(C`any\*(C'\fR \- is the default.  It leaves placement entirely up to the
  linker script and how it assigns the standard sections
  (\f(CW\*(C`.text\*(C'\fR, \f(CW\*(C`.data\*(C'\fR, etc) to the memory regions.
! .IP \fB\-msilicon\-errata=\fR 4
  .IX Item "-msilicon-errata="
  This option passes on a request to assembler to enable the fixes for
  the named silicon errata.
! .IP \fB\-msilicon\-errata\-warn=\fR 4
  .IX Item "-msilicon-errata-warn="
  This option passes on a request to the assembler to enable warning
  messages when a silicon errata might need to be applied.
! .IP \fB\-mwarn\-devices\-csv\fR 4
  .IX Item "-mwarn-devices-csv"
  .PD 0
! .IP \fB\-mno\-warn\-devices\-csv\fR 4
  .IX Item "-mno-warn-devices-csv"
  .PD
  Warn if \fBdevices.csv\fR is not found or there are problem parsing it
  (default: on).
  .PP
! \fINDS32 Options\fR
  .IX Subsection "NDS32 Options"
  .PP
! These options are defined for NDS32 implementations:
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate code in big\-endian mode.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate code in little\-endian mode.
! .IP \fB\-mreduced\-regs\fR 4
  .IX Item "-mreduced-regs"
! Use reduced\-set registers for register allocation.
! .IP \fB\-mfull\-regs\fR 4
  .IX Item "-mfull-regs"
! Use full\-set registers for register allocation.
! .IP \fB\-mcmov\fR 4
  .IX Item "-mcmov"
  Generate conditional move instructions.
! .IP \fB\-mno\-cmov\fR 4
  .IX Item "-mno-cmov"
  Do not generate conditional move instructions.
! .IP \fB\-mext\-perf\fR 4
  .IX Item "-mext-perf"
  Generate performance extension instructions.
! .IP \fB\-mno\-ext\-perf\fR 4
  .IX Item "-mno-ext-perf"
  Do not generate performance extension instructions.
! .IP \fB\-mext\-perf2\fR 4
  .IX Item "-mext-perf2"
  Generate performance extension 2 instructions.
! .IP \fB\-mno\-ext\-perf2\fR 4
  .IX Item "-mno-ext-perf2"
  Do not generate performance extension 2 instructions.
! .IP \fB\-mext\-string\fR 4
  .IX Item "-mext-string"
  Generate string extension instructions.
! .IP \fB\-mno\-ext\-string\fR 4
  .IX Item "-mno-ext-string"
  Do not generate string extension instructions.
! .IP \fB\-mv3push\fR 4
  .IX Item "-mv3push"
  Generate v3 push25/pop25 instructions.
! .IP \fB\-mno\-v3push\fR 4
  .IX Item "-mno-v3push"
  Do not generate v3 push25/pop25 instructions.
! .IP \fB\-m16\-bit\fR 4
  .IX Item "-m16-bit"
  Generate 16\-bit instructions.
! .IP \fB\-mno\-16\-bit\fR 4
  .IX Item "-mno-16-bit"
  Do not generate 16\-bit instructions.
! .IP \fB\-misr\-vector\-size=\fR\fInum\fR 4
  .IX Item "-misr-vector-size=num"
  Specify the size of each interrupt vector, which must be 4 or 16.
! .IP \fB\-mcache\-block\-size=\fR\fInum\fR 4
  .IX Item "-mcache-block-size=num"
  Specify the size of each cache block,
  which must be a power of 2 between 4 and 512.
! .IP \fB\-march=\fR\fIarch\fR 4
  .IX Item "-march=arch"
  Specify the name of the target architecture.
! .IP \fB\-mcmodel=\fR\fIcode\-model\fR 4
  .IX Item "-mcmodel=code-model"
  Set the code model to one of
  .RS 4
! .IP \fBsmall\fR 4
  .IX Item "small"
! All the data and read\-only data segments must be within 512KB addressing space.
  The text segment must be within 16MB addressing space.
! .IP \fBmedium\fR 4
  .IX Item "medium"
! The data segment must be within 512KB while the read\-only data segment can be
  within 4GB addressing space.  The text segment should be still within 16MB
  addressing space.
! .IP \fBlarge\fR 4
  .IX Item "large"
  All the text and data segments can be within 4GB addressing space.
  .RE
  .RS 4
  .RE
! .IP \fB\-mctor\-dtor\fR 4
  .IX Item "-mctor-dtor"
  Enable constructor/destructor feature.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Guide linker to relax instructions.
  .PP
! \fINios II Options\fR
  .IX Subsection "Nios II Options"
  .PP
! These are the options defined for the Altera Nios II processor.
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  Put global and static objects less than or equal to \fInum\fR bytes
! into the small data or BSS sections instead of the normal data or BSS
  sections.  The default value of \fInum\fR is 8.
! .IP \fB\-mgpopt=\fR\fIoption\fR 4
  .IX Item "-mgpopt=option"
  .PD 0
! .IP \fB\-mgpopt\fR 4
  .IX Item "-mgpopt"
! .IP \fB\-mno\-gpopt\fR 4
  .IX Item "-mno-gpopt"
  .PD
! Generate (do not generate) GP\-relative accesses.  The following 
  \&\fIoption\fR names are recognized:
  .RS 4
! .IP \fBnone\fR 4
  .IX Item "none"
! Do not generate GP\-relative accesses.
! .IP \fBlocal\fR 4
  .IX Item "local"
! Generate GP\-relative accesses for small data objects that are not 
  external, weak, or uninitialized common symbols.  
! Also use GP\-relative addressing for objects that
  have been explicitly placed in a small data section via a \f(CW\*(C`section\*(C'\fR
  attribute.
! .IP \fBglobal\fR 4
  .IX Item "global"
! As for \fBlocal\fR, but also generate GP\-relative accesses for
  small data objects that are external, weak, or common.  If you use this option,
  you must ensure that all parts of your program (including libraries) are
  compiled with the same \fB\-G\fR setting.
! .IP \fBdata\fR 4
  .IX Item "data"
! Generate GP\-relative accesses for all data objects in the program.  If you
! use this option, the entire data and BSS segments
  of your program must fit in 64K of memory and you must use an appropriate
  linker script to allocate them within the addressable range of the
  global pointer.
! .IP \fBall\fR 4
  .IX Item "all"
! Generate GP\-relative addresses for function pointers as well as data
! pointers.  If you use this option, the entire text, data, and BSS segments
  of your program must fit in 64K of memory and you must use an appropriate
  linker script to allocate them within the addressable range of the
  global pointer.
*************** global pointer.
*** 27497,27632 ****
  \&\fB\-mno\-gpopt\fR is equivalent to \fB\-mgpopt=none\fR.
  .Sp
  The default is \fB\-mgpopt\fR except when \fB\-fpic\fR or
! \&\fB\-fPIC\fR is specified to generate position-independent code.
! Note that the Nios \s-1II ABI\s0 does not permit GP-relative accesses from
  shared libraries.
  .Sp
  You may need to specify \fB\-mno\-gpopt\fR explicitly when building
  programs that include large amounts of small data, including large
! \&\s-1GOT\s0 data sections.  In this case, the 16\-bit offset for GP-relative
  addressing may not be large enough to allow access to the entire 
  small data section.
  .RE
! .IP "\fB\-mgprel\-sec=\fR\fIregexp\fR" 4
  .IX Item "-mgprel-sec=regexp"
  This option specifies additional section names that can be accessed via
! GP-relative addressing.  It is most useful in conjunction with 
  \&\f(CW\*(C`section\*(C'\fR attributes on variable declarations and a custom linker script.  
! The \fIregexp\fR is a \s-1POSIX\s0 Extended Regular Expression.
  .Sp
  This option does not affect the behavior of the \fB\-G\fR option, and 
  the specified sections are in addition to the standard \f(CW\*(C`.sdata\*(C'\fR
! and \f(CW\*(C`.sbss\*(C'\fR small-data sections that are recognized by \fB\-mgpopt\fR.
! .IP "\fB\-mr0rel\-sec=\fR\fIregexp\fR" 4
  .IX Item "-mr0rel-sec=regexp"
  This option specifies names of sections that can be accessed via a 
  16\-bit offset from \f(CW\*(C`r0\*(C'\fR; that is, in the low 32K or high 32K 
  of the 32\-bit address space.  It is most useful in conjunction with 
  \&\f(CW\*(C`section\*(C'\fR attributes on variable declarations and a custom linker script.  
! The \fIregexp\fR is a \s-1POSIX\s0 Extended Regular Expression.
  .Sp
! In contrast to the use of GP-relative addressing for small data, 
! zero-based addressing is never generated by default and there are no 
  conventional section names used in standard linker scripts for sections
  in the low or high areas of memory.
! .IP "\fB\-mel\fR" 4
  .IX Item "-mel"
  .PD 0
! .IP "\fB\-meb\fR" 4
  .IX Item "-meb"
  .PD
! Generate little-endian (default) or big-endian (experimental) code,
  respectively.
! .IP "\fB\-march=\fR\fIarch\fR" 4
  .IX Item "-march=arch"
! This specifies the name of the target Nios \s-1II\s0 architecture.  \s-1GCC\s0 uses this
  name to determine what kind of instructions it can emit when generating
  assembly code.  Permissible names are: \fBr1\fR, \fBr2\fR.
  .Sp
  The preprocessor macro \f(CW\*(C`_\|_nios2_arch_\|_\*(C'\fR is available to programs,
! with value 1 or 2, indicating the targeted \s-1ISA\s0 level.
! .IP "\fB\-mbypass\-cache\fR" 4
  .IX Item "-mbypass-cache"
  .PD 0
! .IP "\fB\-mno\-bypass\-cache\fR" 4
  .IX Item "-mno-bypass-cache"
  .PD
  Force all load and store instructions to always bypass cache by 
  using I/O variants of the instructions. The default is not to
  bypass the cache.
! .IP "\fB\-mno\-cache\-volatile\fR" 4
  .IX Item "-mno-cache-volatile"
  .PD 0
! .IP "\fB\-mcache\-volatile\fR" 4
  .IX Item "-mcache-volatile"
  .PD
  Volatile memory access bypass the cache using the I/O variants of 
  the load and store instructions. The default is not to bypass the cache.
! .IP "\fB\-mno\-fast\-sw\-div\fR" 4
  .IX Item "-mno-fast-sw-div"
  .PD 0
! .IP "\fB\-mfast\-sw\-div\fR" 4
  .IX Item "-mfast-sw-div"
  .PD
! Do not use table-based fast divide for small numbers. The default 
  is to use the fast divide at \fB\-O3\fR and above.
! .IP "\fB\-mno\-hw\-mul\fR" 4
  .IX Item "-mno-hw-mul"
  .PD 0
! .IP "\fB\-mhw\-mul\fR" 4
  .IX Item "-mhw-mul"
! .IP "\fB\-mno\-hw\-mulx\fR" 4
  .IX Item "-mno-hw-mulx"
! .IP "\fB\-mhw\-mulx\fR" 4
  .IX Item "-mhw-mulx"
! .IP "\fB\-mno\-hw\-div\fR" 4
  .IX Item "-mno-hw-div"
! .IP "\fB\-mhw\-div\fR" 4
  .IX Item "-mhw-div"
  .PD
  Enable or disable emitting \f(CW\*(C`mul\*(C'\fR, \f(CW\*(C`mulx\*(C'\fR and \f(CW\*(C`div\*(C'\fR family of 
  instructions by the compiler. The default is to emit \f(CW\*(C`mul\*(C'\fR
  and not emit \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`mulx\*(C'\fR.
! .IP "\fB\-mbmx\fR" 4
  .IX Item "-mbmx"
  .PD 0
! .IP "\fB\-mno\-bmx\fR" 4
  .IX Item "-mno-bmx"
! .IP "\fB\-mcdx\fR" 4
  .IX Item "-mcdx"
! .IP "\fB\-mno\-cdx\fR" 4
  .IX Item "-mno-cdx"
  .PD
! Enable or disable generation of Nios \s-1II R2 BMX\s0 (bit manipulation) and
! \&\s-1CDX\s0 (code density) instructions.  Enabling these instructions also
  requires \fB\-march=r2\fR.  Since these instructions are optional
  extensions to the R2 architecture, the default is not to emit them.
! .IP "\fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR" 4
  .IX Item "-mcustom-insn=N"
  .PD 0
! .IP "\fB\-mno\-custom\-\fR\fIinsn\fR" 4
  .IX Item "-mno-custom-insn"
  .PD
  Each \fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR option enables use of a
  custom instruction with encoding \fIN\fR when generating code that uses 
  \&\fIinsn\fR.  For example, \fB\-mcustom\-fadds=253\fR generates custom
! instruction 253 for single-precision floating-point add operations instead
  of the default behavior of using a library call.
  .Sp
  The following values of \fIinsn\fR are supported.  Except as otherwise
! noted, floating-point operations are expected to be implemented with
! normal \s-1IEEE 754\s0 semantics and correspond directly to the C operators or the
! equivalent \s-1GCC\s0 built-in functions.
  .Sp
! Single-precision floating point:
  .RS 4
  .IP "\fBfadds\fR, \fBfsubs\fR, \fBfdivs\fR, \fBfmuls\fR" 4
  .IX Item "fadds, fsubs, fdivs, fmuls"
  Binary arithmetic operations.
! .IP "\fBfnegs\fR" 4
  .IX Item "fnegs"
  Unary negation.
! .IP "\fBfabss\fR" 4
  .IX Item "fabss"
  Unary absolute value.
  .IP "\fBfcmpeqs\fR, \fBfcmpges\fR, \fBfcmpgts\fR, \fBfcmples\fR, \fBfcmplts\fR, \fBfcmpnes\fR" 4
--- 27428,27563 ----
  \&\fB\-mno\-gpopt\fR is equivalent to \fB\-mgpopt=none\fR.
  .Sp
  The default is \fB\-mgpopt\fR except when \fB\-fpic\fR or
! \&\fB\-fPIC\fR is specified to generate position\-independent code.
! Note that the Nios II ABI does not permit GP\-relative accesses from
  shared libraries.
  .Sp
  You may need to specify \fB\-mno\-gpopt\fR explicitly when building
  programs that include large amounts of small data, including large
! GOT data sections.  In this case, the 16\-bit offset for GP\-relative
  addressing may not be large enough to allow access to the entire 
  small data section.
  .RE
! .IP \fB\-mgprel\-sec=\fR\fIregexp\fR 4
  .IX Item "-mgprel-sec=regexp"
  This option specifies additional section names that can be accessed via
! GP\-relative addressing.  It is most useful in conjunction with 
  \&\f(CW\*(C`section\*(C'\fR attributes on variable declarations and a custom linker script.  
! The \fIregexp\fR is a POSIX Extended Regular Expression.
  .Sp
  This option does not affect the behavior of the \fB\-G\fR option, and 
  the specified sections are in addition to the standard \f(CW\*(C`.sdata\*(C'\fR
! and \f(CW\*(C`.sbss\*(C'\fR small\-data sections that are recognized by \fB\-mgpopt\fR.
! .IP \fB\-mr0rel\-sec=\fR\fIregexp\fR 4
  .IX Item "-mr0rel-sec=regexp"
  This option specifies names of sections that can be accessed via a 
  16\-bit offset from \f(CW\*(C`r0\*(C'\fR; that is, in the low 32K or high 32K 
  of the 32\-bit address space.  It is most useful in conjunction with 
  \&\f(CW\*(C`section\*(C'\fR attributes on variable declarations and a custom linker script.  
! The \fIregexp\fR is a POSIX Extended Regular Expression.
  .Sp
! In contrast to the use of GP\-relative addressing for small data, 
! zero\-based addressing is never generated by default and there are no 
  conventional section names used in standard linker scripts for sections
  in the low or high areas of memory.
! .IP \fB\-mel\fR 4
  .IX Item "-mel"
  .PD 0
! .IP \fB\-meb\fR 4
  .IX Item "-meb"
  .PD
! Generate little\-endian (default) or big\-endian (experimental) code,
  respectively.
! .IP \fB\-march=\fR\fIarch\fR 4
  .IX Item "-march=arch"
! This specifies the name of the target Nios II architecture.  GCC uses this
  name to determine what kind of instructions it can emit when generating
  assembly code.  Permissible names are: \fBr1\fR, \fBr2\fR.
  .Sp
  The preprocessor macro \f(CW\*(C`_\|_nios2_arch_\|_\*(C'\fR is available to programs,
! with value 1 or 2, indicating the targeted ISA level.
! .IP \fB\-mbypass\-cache\fR 4
  .IX Item "-mbypass-cache"
  .PD 0
! .IP \fB\-mno\-bypass\-cache\fR 4
  .IX Item "-mno-bypass-cache"
  .PD
  Force all load and store instructions to always bypass cache by 
  using I/O variants of the instructions. The default is not to
  bypass the cache.
! .IP \fB\-mno\-cache\-volatile\fR 4
  .IX Item "-mno-cache-volatile"
  .PD 0
! .IP \fB\-mcache\-volatile\fR 4
  .IX Item "-mcache-volatile"
  .PD
  Volatile memory access bypass the cache using the I/O variants of 
  the load and store instructions. The default is not to bypass the cache.
! .IP \fB\-mno\-fast\-sw\-div\fR 4
  .IX Item "-mno-fast-sw-div"
  .PD 0
! .IP \fB\-mfast\-sw\-div\fR 4
  .IX Item "-mfast-sw-div"
  .PD
! Do not use table\-based fast divide for small numbers. The default 
  is to use the fast divide at \fB\-O3\fR and above.
! .IP \fB\-mno\-hw\-mul\fR 4
  .IX Item "-mno-hw-mul"
  .PD 0
! .IP \fB\-mhw\-mul\fR 4
  .IX Item "-mhw-mul"
! .IP \fB\-mno\-hw\-mulx\fR 4
  .IX Item "-mno-hw-mulx"
! .IP \fB\-mhw\-mulx\fR 4
  .IX Item "-mhw-mulx"
! .IP \fB\-mno\-hw\-div\fR 4
  .IX Item "-mno-hw-div"
! .IP \fB\-mhw\-div\fR 4
  .IX Item "-mhw-div"
  .PD
  Enable or disable emitting \f(CW\*(C`mul\*(C'\fR, \f(CW\*(C`mulx\*(C'\fR and \f(CW\*(C`div\*(C'\fR family of 
  instructions by the compiler. The default is to emit \f(CW\*(C`mul\*(C'\fR
  and not emit \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`mulx\*(C'\fR.
! .IP \fB\-mbmx\fR 4
  .IX Item "-mbmx"
  .PD 0
! .IP \fB\-mno\-bmx\fR 4
  .IX Item "-mno-bmx"
! .IP \fB\-mcdx\fR 4
  .IX Item "-mcdx"
! .IP \fB\-mno\-cdx\fR 4
  .IX Item "-mno-cdx"
  .PD
! Enable or disable generation of Nios II R2 BMX (bit manipulation) and
! CDX (code density) instructions.  Enabling these instructions also
  requires \fB\-march=r2\fR.  Since these instructions are optional
  extensions to the R2 architecture, the default is not to emit them.
! .IP \fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR 4
  .IX Item "-mcustom-insn=N"
  .PD 0
! .IP \fB\-mno\-custom\-\fR\fIinsn\fR 4
  .IX Item "-mno-custom-insn"
  .PD
  Each \fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR option enables use of a
  custom instruction with encoding \fIN\fR when generating code that uses 
  \&\fIinsn\fR.  For example, \fB\-mcustom\-fadds=253\fR generates custom
! instruction 253 for single\-precision floating\-point add operations instead
  of the default behavior of using a library call.
  .Sp
  The following values of \fIinsn\fR are supported.  Except as otherwise
! noted, floating\-point operations are expected to be implemented with
! normal IEEE 754 semantics and correspond directly to the C operators or the
! equivalent GCC built\-in functions.
  .Sp
! Single\-precision floating point:
  .RS 4
  .IP "\fBfadds\fR, \fBfsubs\fR, \fBfdivs\fR, \fBfmuls\fR" 4
  .IX Item "fadds, fsubs, fdivs, fmuls"
  Binary arithmetic operations.
! .IP \fBfnegs\fR 4
  .IX Item "fnegs"
  Unary negation.
! .IP \fBfabss\fR 4
  .IX Item "fabss"
  Unary absolute value.
  .IP "\fBfcmpeqs\fR, \fBfcmpges\fR, \fBfcmpgts\fR, \fBfcmples\fR, \fBfcmplts\fR, \fBfcmpnes\fR" 4
*************** Unary absolute value.
*** 27634,27659 ****
  Comparison operations.
  .IP "\fBfmins\fR, \fBfmaxs\fR" 4
  .IX Item "fmins, fmaxs"
! Floating-point minimum and maximum.  These instructions are only
  generated if \fB\-ffinite\-math\-only\fR is specified.
! .IP "\fBfsqrts\fR" 4
  .IX Item "fsqrts"
  Unary square root operation.
  .IP "\fBfcoss\fR, \fBfsins\fR, \fBftans\fR, \fBfatans\fR, \fBfexps\fR, \fBflogs\fR" 4
  .IX Item "fcoss, fsins, ftans, fatans, fexps, flogs"
! Floating-point trigonometric and exponential functions.  These instructions
  are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
  .RE
  .RS 4
  .Sp
! Double-precision floating point:
  .IP "\fBfaddd\fR, \fBfsubd\fR, \fBfdivd\fR, \fBfmuld\fR" 4
  .IX Item "faddd, fsubd, fdivd, fmuld"
  Binary arithmetic operations.
! .IP "\fBfnegd\fR" 4
  .IX Item "fnegd"
  Unary negation.
! .IP "\fBfabsd\fR" 4
  .IX Item "fabsd"
  Unary absolute value.
  .IP "\fBfcmpeqd\fR, \fBfcmpged\fR, \fBfcmpgtd\fR, \fBfcmpled\fR, \fBfcmpltd\fR, \fBfcmpned\fR" 4
--- 27565,27590 ----
  Comparison operations.
  .IP "\fBfmins\fR, \fBfmaxs\fR" 4
  .IX Item "fmins, fmaxs"
! Floating\-point minimum and maximum.  These instructions are only
  generated if \fB\-ffinite\-math\-only\fR is specified.
! .IP \fBfsqrts\fR 4
  .IX Item "fsqrts"
  Unary square root operation.
  .IP "\fBfcoss\fR, \fBfsins\fR, \fBftans\fR, \fBfatans\fR, \fBfexps\fR, \fBflogs\fR" 4
  .IX Item "fcoss, fsins, ftans, fatans, fexps, flogs"
! Floating\-point trigonometric and exponential functions.  These instructions
  are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
  .RE
  .RS 4
  .Sp
! Double\-precision floating point:
  .IP "\fBfaddd\fR, \fBfsubd\fR, \fBfdivd\fR, \fBfmuld\fR" 4
  .IX Item "faddd, fsubd, fdivd, fmuld"
  Binary arithmetic operations.
! .IP \fBfnegd\fR 4
  .IX Item "fnegd"
  Unary negation.
! .IP \fBfabsd\fR 4
  .IX Item "fabsd"
  Unary absolute value.
  .IP "\fBfcmpeqd\fR, \fBfcmpged\fR, \fBfcmpgtd\fR, \fBfcmpled\fR, \fBfcmpltd\fR, \fBfcmpned\fR" 4
*************** Unary absolute value.
*** 27661,27737 ****
  Comparison operations.
  .IP "\fBfmind\fR, \fBfmaxd\fR" 4
  .IX Item "fmind, fmaxd"
! Double-precision minimum and maximum.  These instructions are only
  generated if \fB\-ffinite\-math\-only\fR is specified.
! .IP "\fBfsqrtd\fR" 4
  .IX Item "fsqrtd"
  Unary square root operation.
  .IP "\fBfcosd\fR, \fBfsind\fR, \fBftand\fR, \fBfatand\fR, \fBfexpd\fR, \fBflogd\fR" 4
  .IX Item "fcosd, fsind, ftand, fatand, fexpd, flogd"
! Double-precision trigonometric and exponential functions.  These instructions
  are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
  .RE
  .RS 4
  .Sp
  Conversions:
! .IP "\fBfextsd\fR" 4
  .IX Item "fextsd"
  Conversion from single precision to double precision.
! .IP "\fBftruncds\fR" 4
  .IX Item "ftruncds"
  Conversion from double precision to single precision.
  .IP "\fBfixsi\fR, \fBfixsu\fR, \fBfixdi\fR, \fBfixdu\fR" 4
  .IX Item "fixsi, fixsu, fixdi, fixdu"
  Conversion from floating point to signed or unsigned integer types, with
  truncation towards zero.
! .IP "\fBround\fR" 4
  .IX Item "round"
! Conversion from single-precision floating point to signed integer,
  rounding to the nearest integer and ties away from zero.
  This corresponds to the \f(CW\*(C`_\|_builtin_lroundf\*(C'\fR function when
  \&\fB\-fno\-math\-errno\fR is used.
  .IP "\fBfloatis\fR, \fBfloatus\fR, \fBfloatid\fR, \fBfloatud\fR" 4
  .IX Item "floatis, floatus, floatid, floatud"
! Conversion from signed or unsigned integer types to floating-point types.
  .RE
  .RS 4
  .Sp
  In addition, all of the following transfer instructions for internal
! registers X and Y must be provided to use any of the double-precision
! floating-point instructions.  Custom instructions taking two
! double-precision source operands expect the first operand in the
  64\-bit register X.  The other operand (or only operand of a unary
  operation) is given to the custom arithmetic instruction with the
  least significant half in source register \fIsrc1\fR and the most
  significant half in \fIsrc2\fR.  A custom instruction that returns a
! double-precision result returns the most significant 32 bits in the
  destination register and the other half in 32\-bit register Y.  
! \&\s-1GCC\s0 automatically generates the necessary code sequences to write
! register X and/or read register Y when double-precision floating-point
  instructions are used.
! .IP "\fBfwrx\fR" 4
  .IX Item "fwrx"
  Write \fIsrc1\fR into the least significant half of X and \fIsrc2\fR into
  the most significant half of X.
! .IP "\fBfwry\fR" 4
  .IX Item "fwry"
  Write \fIsrc1\fR into Y.
  .IP "\fBfrdxhi\fR, \fBfrdxlo\fR" 4
  .IX Item "frdxhi, frdxlo"
  Read the most or least (respectively) significant half of X and store it in
  \&\fIdest\fR.
! .IP "\fBfrdy\fR" 4
  .IX Item "frdy"
  Read the value of Y and store it into \fIdest\fR.
  .RE
  .RS 4
  .Sp
! Note that you can gain more local control over generation of Nios \s-1II\s0 custom
! instructions by using the \f(CW\*(C`target("custom\-\f(CIinsn\f(CW=\f(CIN\f(CW")\*(C'\fR
! and \f(CW\*(C`target("no\-custom\-\f(CIinsn\f(CW")\*(C'\fR function attributes
  or pragmas.
  .RE
! .IP "\fB\-mcustom\-fpu\-cfg=\fR\fIname\fR" 4
  .IX Item "-mcustom-fpu-cfg=name"
  This option enables a predefined, named set of custom instruction encodings
  (see \fB\-mcustom\-\fR\fIinsn\fR above).  
--- 27592,27668 ----
  Comparison operations.
  .IP "\fBfmind\fR, \fBfmaxd\fR" 4
  .IX Item "fmind, fmaxd"
! Double\-precision minimum and maximum.  These instructions are only
  generated if \fB\-ffinite\-math\-only\fR is specified.
! .IP \fBfsqrtd\fR 4
  .IX Item "fsqrtd"
  Unary square root operation.
  .IP "\fBfcosd\fR, \fBfsind\fR, \fBftand\fR, \fBfatand\fR, \fBfexpd\fR, \fBflogd\fR" 4
  .IX Item "fcosd, fsind, ftand, fatand, fexpd, flogd"
! Double\-precision trigonometric and exponential functions.  These instructions
  are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
  .RE
  .RS 4
  .Sp
  Conversions:
! .IP \fBfextsd\fR 4
  .IX Item "fextsd"
  Conversion from single precision to double precision.
! .IP \fBftruncds\fR 4
  .IX Item "ftruncds"
  Conversion from double precision to single precision.
  .IP "\fBfixsi\fR, \fBfixsu\fR, \fBfixdi\fR, \fBfixdu\fR" 4
  .IX Item "fixsi, fixsu, fixdi, fixdu"
  Conversion from floating point to signed or unsigned integer types, with
  truncation towards zero.
! .IP \fBround\fR 4
  .IX Item "round"
! Conversion from single\-precision floating point to signed integer,
  rounding to the nearest integer and ties away from zero.
  This corresponds to the \f(CW\*(C`_\|_builtin_lroundf\*(C'\fR function when
  \&\fB\-fno\-math\-errno\fR is used.
  .IP "\fBfloatis\fR, \fBfloatus\fR, \fBfloatid\fR, \fBfloatud\fR" 4
  .IX Item "floatis, floatus, floatid, floatud"
! Conversion from signed or unsigned integer types to floating\-point types.
  .RE
  .RS 4
  .Sp
  In addition, all of the following transfer instructions for internal
! registers X and Y must be provided to use any of the double\-precision
! floating\-point instructions.  Custom instructions taking two
! double\-precision source operands expect the first operand in the
  64\-bit register X.  The other operand (or only operand of a unary
  operation) is given to the custom arithmetic instruction with the
  least significant half in source register \fIsrc1\fR and the most
  significant half in \fIsrc2\fR.  A custom instruction that returns a
! double\-precision result returns the most significant 32 bits in the
  destination register and the other half in 32\-bit register Y.  
! GCC automatically generates the necessary code sequences to write
! register X and/or read register Y when double\-precision floating\-point
  instructions are used.
! .IP \fBfwrx\fR 4
  .IX Item "fwrx"
  Write \fIsrc1\fR into the least significant half of X and \fIsrc2\fR into
  the most significant half of X.
! .IP \fBfwry\fR 4
  .IX Item "fwry"
  Write \fIsrc1\fR into Y.
  .IP "\fBfrdxhi\fR, \fBfrdxlo\fR" 4
  .IX Item "frdxhi, frdxlo"
  Read the most or least (respectively) significant half of X and store it in
  \&\fIdest\fR.
! .IP \fBfrdy\fR 4
  .IX Item "frdy"
  Read the value of Y and store it into \fIdest\fR.
  .RE
  .RS 4
  .Sp
! Note that you can gain more local control over generation of Nios II custom
! instructions by using the \f(CWtarget("custom\-\fR\f(CIinsn\fR\f(CW=\fR\f(CIN\fR\f(CW")\fR
! and \f(CWtarget("no\-custom\-\fR\f(CIinsn\fR\f(CW")\fR function attributes
  or pragmas.
  .RE
! .IP \fB\-mcustom\-fpu\-cfg=\fR\fIname\fR 4
  .IX Item "-mcustom-fpu-cfg=name"
  This option enables a predefined, named set of custom instruction encodings
  (see \fB\-mcustom\-\fR\fIinsn\fR above).  
*************** Custom instruction assignments given by
*** 27789,27800 ****
  \&\fB\-mcustom\-fpu\-cfg=\fR, regardless of the
  order of the options on the command line.
  .Sp
! Note that you can gain more local control over selection of a \s-1FPU\s0
! configuration by using the \f(CW\*(C`target("custom\-fpu\-cfg=\f(CIname\f(CW")\*(C'\fR
  function attribute
  or pragma.
  .Sp
! The name \fIfph2\fR is an abbreviation for \fINios \s-1II\s0 Floating Point
  Hardware 2 Component\fR.  Please note that the custom instructions enabled by
  \&\fB\-mcustom\-fmins=233\fR and \fB\-mcustom\-fmaxs=234\fR are only generated
  if \fB\-ffinite\-math\-only\fR is specified.  The custom instruction enabled by
--- 27720,27731 ----
  \&\fB\-mcustom\-fpu\-cfg=\fR, regardless of the
  order of the options on the command line.
  .Sp
! Note that you can gain more local control over selection of a FPU
! configuration by using the \f(CWtarget("custom\-fpu\-cfg=\fR\f(CIname\fR\f(CW")\fR
  function attribute
  or pragma.
  .Sp
! The name \fIfph2\fR is an abbreviation for \fINios II Floating Point
  Hardware 2 Component\fR.  Please note that the custom instructions enabled by
  \&\fB\-mcustom\-fmins=233\fR and \fB\-mcustom\-fmaxs=234\fR are only generated
  if \fB\-ffinite\-math\-only\fR is specified.  The custom instruction enabled by
*************** if \fB\-ffinite\-math\-only\fR is specif
*** 27802,27841 ****
  specified.  In contrast to the other configurations,
  \&\fB\-fsingle\-precision\-constant\fR is not set.
  .PP
! These additional \fB\-m\fR options are available for the Altera Nios \s-1II
! ELF\s0 (bare-metal) target:
! .IP "\fB\-mhal\fR" 4
  .IX Item "-mhal"
! Link with \s-1HAL BSP.\s0  This suppresses linking with the GCC-provided C runtime
  startup and termination code, and is typically used in conjunction with
  \&\fB\-msys\-crt0=\fR to specify the location of the alternate startup code
! provided by the \s-1HAL BSP.\s0
! .IP "\fB\-msmallc\fR" 4
  .IX Item "-msmallc"
  Link with a limited version of the C library, \fB\-lsmallc\fR, rather than
  Newlib.
! .IP "\fB\-msys\-crt0=\fR\fIstartfile\fR" 4
  .IX Item "-msys-crt0=startfile"
  \&\fIstartfile\fR is the file name of the startfile (crt0) to use 
  when linking.  This option is only useful in conjunction with \fB\-mhal\fR.
! .IP "\fB\-msys\-lib=\fR\fIsystemlib\fR" 4
  .IX Item "-msys-lib=systemlib"
  \&\fIsystemlib\fR is the library name of the library that provides
! low-level system calls required by the C library,
  e.g. \f(CW\*(C`read\*(C'\fR and \f(CW\*(C`write\*(C'\fR.
! This option is typically used to link with a library provided by a \s-1HAL BSP.\s0
  .PP
! \fINvidia \s-1PTX\s0 Options\fR
  .IX Subsection "Nvidia PTX Options"
  .PP
! These options are defined for Nvidia \s-1PTX:\s0
! .IP "\fB\-m64\fR" 4
  .IX Item "-m64"
! Ignored, but preserved for backward compatibility.  Only 64\-bit \s-1ABI\s0 is
  supported.
! .IP "\fB\-march=\fR\fIarchitecture-string\fR" 4
  .IX Item "-march=architecture-string"
! Generate code for the specified \s-1PTX ISA\s0 target architecture
  (e.g. \fBsm_35\fR).  Valid architecture strings are \fBsm_30\fR,
  \&\fBsm_35\fR, \fBsm_53\fR, \fBsm_70\fR, \fBsm_75\fR and
  \&\fBsm_80\fR.
--- 27733,27772 ----
  specified.  In contrast to the other configurations,
  \&\fB\-fsingle\-precision\-constant\fR is not set.
  .PP
! These additional \fB\-m\fR options are available for the Altera Nios II
! ELF (bare\-metal) target:
! .IP \fB\-mhal\fR 4
  .IX Item "-mhal"
! Link with HAL BSP.  This suppresses linking with the GCC\-provided C runtime
  startup and termination code, and is typically used in conjunction with
  \&\fB\-msys\-crt0=\fR to specify the location of the alternate startup code
! provided by the HAL BSP.
! .IP \fB\-msmallc\fR 4
  .IX Item "-msmallc"
  Link with a limited version of the C library, \fB\-lsmallc\fR, rather than
  Newlib.
! .IP \fB\-msys\-crt0=\fR\fIstartfile\fR 4
  .IX Item "-msys-crt0=startfile"
  \&\fIstartfile\fR is the file name of the startfile (crt0) to use 
  when linking.  This option is only useful in conjunction with \fB\-mhal\fR.
! .IP \fB\-msys\-lib=\fR\fIsystemlib\fR 4
  .IX Item "-msys-lib=systemlib"
  \&\fIsystemlib\fR is the library name of the library that provides
! low\-level system calls required by the C library,
  e.g. \f(CW\*(C`read\*(C'\fR and \f(CW\*(C`write\*(C'\fR.
! This option is typically used to link with a library provided by a HAL BSP.
  .PP
! \fINvidia PTX Options\fR
  .IX Subsection "Nvidia PTX Options"
  .PP
! These options are defined for Nvidia PTX:
! .IP \fB\-m64\fR 4
  .IX Item "-m64"
! Ignored, but preserved for backward compatibility.  Only 64\-bit ABI is
  supported.
! .IP \fB\-march=\fR\fIarchitecture\-string\fR 4
  .IX Item "-march=architecture-string"
! Generate code for the specified PTX ISA target architecture
  (e.g. \fBsm_35\fR).  Valid architecture strings are \fBsm_30\fR,
  \&\fBsm_35\fR, \fBsm_53\fR, \fBsm_70\fR, \fBsm_75\fR and
  \&\fBsm_80\fR.
*************** The default depends on how the compiler
*** 27845,27904 ****
  This option sets the value of the preprocessor macro
  \&\f(CW\*(C`_\|_PTX_SM_\|_\*(C'\fR; for instance, for \fBsm_35\fR, it has the value
  \&\fB350\fR.
! .IP "\fB\-misa=\fR\fIarchitecture-string\fR" 4
  .IX Item "-misa=architecture-string"
  Alias of \fB\-march=\fR.
! .IP "\fB\-march\-map=\fR\fIarchitecture-string\fR" 4
  .IX Item "-march-map=architecture-string"
  Select the closest available \fB\-march=\fR value that is not more
  capable.  For instance, for \fB\-march\-map=sm_50\fR select
  \&\fB\-march=sm_35\fR, and for \fB\-march\-map=sm_53\fR select
  \&\fB\-march=sm_53\fR.
! .IP "\fB\-mptx=\fR\fIversion-string\fR" 4
  .IX Item "-mptx=version-string"
! Generate code for the specified \s-1PTX ISA\s0 version (e.g. \fB7.0\fR).
  Valid version strings include \fB3.1\fR, \fB6.0\fR, \fB6.3\fR, and
! \&\fB7.0\fR.  The default \s-1PTX ISA\s0 version is 6.0, unless a higher
! version is required for specified \s-1PTX ISA\s0 target architecture via
  option \fB\-march=\fR.
  .Sp
  This option sets the values of the preprocessor macros
  \&\f(CW\*(C`_\|_PTX_ISA_VERSION_MAJOR_\|_\*(C'\fR and \f(CW\*(C`_\|_PTX_ISA_VERSION_MINOR_\|_\*(C'\fR;
  for instance, for \fB3.1\fR the macros have the values \fB3\fR and
  \&\fB1\fR, respectively.
! .IP "\fB\-mmainkernel\fR" 4
  .IX Item "-mmainkernel"
! Link in code for a _\|_main kernel.  This is for stand-alone instead of
  offloading execution.
! .IP "\fB\-moptimize\fR" 4
  .IX Item "-moptimize"
  Apply partitioned execution optimizations.  This is the default when any
  level of optimization is selected.
! .IP "\fB\-msoft\-stack\fR" 4
  .IX Item "-msoft-stack"
  Generate code that does not use \f(CW\*(C`.local\*(C'\fR memory
! directly for stack storage. Instead, a per-warp stack pointer is
! maintained explicitly. This enables variable-length stack allocation (with
! variable-length arrays or \f(CW\*(C`alloca\*(C'\fR), and when global memory is used for
  underlying storage, makes it possible to access automatic variables from other
  threads, or with atomic instructions. This code generation variant is used
  for OpenMP offloading, but the option is exposed on its own for the purpose
  of testing the compiler; to generate code suitable for linking into programs
  using OpenMP offloading, use option \fB\-mgomp\fR.
! .IP "\fB\-muniform\-simt\fR" 4
  .IX Item "-muniform-simt"
  Switch to code generation variant that allows to execute all threads in each
  warp, while maintaining memory state and side effects as if only one thread
! in each warp was active outside of OpenMP \s-1SIMD\s0 regions.  All atomic operations
  and calls to runtime (malloc, free, vprintf) are conditionally executed (iff
  current lane index equals the master lane index), and the register being
  assigned is copied via a shuffle instruction from the master lane.  Outside of
! \&\s-1SIMD\s0 regions lane 0 is the master; inside, each thread sees itself as the
! master.  Shared memory array \f(CW\*(C`int _\|_nvptx_uni[]\*(C'\fR stores all-zeros or
! all-ones bitmasks for each warp, indicating current mode (0 outside of \s-1SIMD\s0
! regions).  Each thread can bitwise-and the bitmask at position \f(CW\*(C`tid.y\*(C'\fR
  with current lane index to compute the master lane index.
! .IP "\fB\-mgomp\fR" 4
  .IX Item "-mgomp"
  Generate code for use in OpenMP offloading: enables \fB\-msoft\-stack\fR and
  \&\fB\-muniform\-simt\fR options, and selects corresponding multilib variant.
--- 27776,27835 ----
  This option sets the value of the preprocessor macro
  \&\f(CW\*(C`_\|_PTX_SM_\|_\*(C'\fR; for instance, for \fBsm_35\fR, it has the value
  \&\fB350\fR.
! .IP \fB\-misa=\fR\fIarchitecture\-string\fR 4
  .IX Item "-misa=architecture-string"
  Alias of \fB\-march=\fR.
! .IP \fB\-march\-map=\fR\fIarchitecture\-string\fR 4
  .IX Item "-march-map=architecture-string"
  Select the closest available \fB\-march=\fR value that is not more
  capable.  For instance, for \fB\-march\-map=sm_50\fR select
  \&\fB\-march=sm_35\fR, and for \fB\-march\-map=sm_53\fR select
  \&\fB\-march=sm_53\fR.
! .IP \fB\-mptx=\fR\fIversion\-string\fR 4
  .IX Item "-mptx=version-string"
! Generate code for the specified PTX ISA version (e.g. \fB7.0\fR).
  Valid version strings include \fB3.1\fR, \fB6.0\fR, \fB6.3\fR, and
! \&\fB7.0\fR.  The default PTX ISA version is 6.0, unless a higher
! version is required for specified PTX ISA target architecture via
  option \fB\-march=\fR.
  .Sp
  This option sets the values of the preprocessor macros
  \&\f(CW\*(C`_\|_PTX_ISA_VERSION_MAJOR_\|_\*(C'\fR and \f(CW\*(C`_\|_PTX_ISA_VERSION_MINOR_\|_\*(C'\fR;
  for instance, for \fB3.1\fR the macros have the values \fB3\fR and
  \&\fB1\fR, respectively.
! .IP \fB\-mmainkernel\fR 4
  .IX Item "-mmainkernel"
! Link in code for a _\|_main kernel.  This is for stand\-alone instead of
  offloading execution.
! .IP \fB\-moptimize\fR 4
  .IX Item "-moptimize"
  Apply partitioned execution optimizations.  This is the default when any
  level of optimization is selected.
! .IP \fB\-msoft\-stack\fR 4
  .IX Item "-msoft-stack"
  Generate code that does not use \f(CW\*(C`.local\*(C'\fR memory
! directly for stack storage. Instead, a per\-warp stack pointer is
! maintained explicitly. This enables variable\-length stack allocation (with
! variable\-length arrays or \f(CW\*(C`alloca\*(C'\fR), and when global memory is used for
  underlying storage, makes it possible to access automatic variables from other
  threads, or with atomic instructions. This code generation variant is used
  for OpenMP offloading, but the option is exposed on its own for the purpose
  of testing the compiler; to generate code suitable for linking into programs
  using OpenMP offloading, use option \fB\-mgomp\fR.
! .IP \fB\-muniform\-simt\fR 4
  .IX Item "-muniform-simt"
  Switch to code generation variant that allows to execute all threads in each
  warp, while maintaining memory state and side effects as if only one thread
! in each warp was active outside of OpenMP SIMD regions.  All atomic operations
  and calls to runtime (malloc, free, vprintf) are conditionally executed (iff
  current lane index equals the master lane index), and the register being
  assigned is copied via a shuffle instruction from the master lane.  Outside of
! SIMD regions lane 0 is the master; inside, each thread sees itself as the
! master.  Shared memory array \f(CW\*(C`int _\|_nvptx_uni[]\*(C'\fR stores all\-zeros or
! all\-ones bitmasks for each warp, indicating current mode (0 outside of SIMD
! regions).  Each thread can bitwise\-and the bitmask at position \f(CW\*(C`tid.y\*(C'\fR
  with current lane index to compute the master lane index.
! .IP \fB\-mgomp\fR 4
  .IX Item "-mgomp"
  Generate code for use in OpenMP offloading: enables \fB\-msoft\-stack\fR and
  \&\fB\-muniform\-simt\fR options, and selects corresponding multilib variant.
*************** Generate code for use in OpenMP offloadi
*** 27907,28045 ****
  .IX Subsection "OpenRISC Options"
  .PP
  These options are defined for OpenRISC:
! .IP "\fB\-mboard=\fR\fIname\fR" 4
  .IX Item "-mboard=name"
  Configure a board specific runtime.  This will be passed to the linker for
  newlib board library linking.  The default is \f(CW\*(C`or1ksim\*(C'\fR.
! .IP "\fB\-mnewlib\fR" 4
  .IX Item "-mnewlib"
  This option is ignored; it is for compatibility purposes only.  This used to
  select linker and preprocessor options for use with newlib.
! .IP "\fB\-msoft\-div\fR" 4
  .IX Item "-msoft-div"
  .PD 0
! .IP "\fB\-mhard\-div\fR" 4
  .IX Item "-mhard-div"
  .PD
  Select software or hardware divide (\f(CW\*(C`l.div\*(C'\fR, \f(CW\*(C`l.divu\*(C'\fR) instructions.
  This default is hardware divide.
! .IP "\fB\-msoft\-mul\fR" 4
  .IX Item "-msoft-mul"
  .PD 0
! .IP "\fB\-mhard\-mul\fR" 4
  .IX Item "-mhard-mul"
  .PD
  Select software or hardware multiply (\f(CW\*(C`l.mul\*(C'\fR, \f(CW\*(C`l.muli\*(C'\fR) instructions.
  This default is hardware multiply.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
  Select software or hardware for floating point operations.
  The default is software.
! .IP "\fB\-mdouble\-float\fR" 4
  .IX Item "-mdouble-float"
! When \fB\-mhard\-float\fR is selected, enables generation of double-precision
  floating point instructions.  By default functions from \fIlibgcc\fR are used
! to perform double-precision floating point operations.
! .IP "\fB\-munordered\-float\fR" 4
  .IX Item "-munordered-float"
  When \fB\-mhard\-float\fR is selected, enables generation of unordered
  floating point compare and set flag (\f(CW\*(C`lf.sfun*\*(C'\fR) instructions.  By default
  functions from \fIlibgcc\fR are used to perform unordered floating point
  compare and set flag operations.
! .IP "\fB\-mcmov\fR" 4
  .IX Item "-mcmov"
  Enable generation of conditional move (\f(CW\*(C`l.cmov\*(C'\fR) instructions.  By
  default the equivalent will be generated using set and branch.
! .IP "\fB\-mror\fR" 4
  .IX Item "-mror"
  Enable generation of rotate right (\f(CW\*(C`l.ror\*(C'\fR) instructions.  By default
  functions from \fIlibgcc\fR are used to perform rotate right operations.
! .IP "\fB\-mrori\fR" 4
  .IX Item "-mrori"
  Enable generation of rotate right with immediate (\f(CW\*(C`l.rori\*(C'\fR) instructions.
  By default functions from \fIlibgcc\fR are used to perform rotate right with
  immediate operations.
! .IP "\fB\-msext\fR" 4
  .IX Item "-msext"
  Enable generation of sign extension (\f(CW\*(C`l.ext*\*(C'\fR) instructions.  By default
  memory loads are used to perform sign extension.
! .IP "\fB\-msfimm\fR" 4
  .IX Item "-msfimm"
  Enable generation of compare and set flag with immediate (\f(CW\*(C`l.sf*i\*(C'\fR)
  instructions.  By default extra instructions will be generated to store the
  immediate to a register first.
! .IP "\fB\-mshftimm\fR" 4
  .IX Item "-mshftimm"
  Enable generation of shift with immediate (\f(CW\*(C`l.srai\*(C'\fR, \f(CW\*(C`l.srli\*(C'\fR,
  \&\f(CW\*(C`l.slli\*(C'\fR) instructions.  By default extra instructions will be generated
  to store the immediate to a register first.
! .IP "\fB\-mcmodel=small\fR" 4
  .IX Item "-mcmodel=small"
! Generate OpenRISC code for the small model: The \s-1GOT\s0 is limited to 64k. This is
  the default model.
! .IP "\fB\-mcmodel=large\fR" 4
  .IX Item "-mcmodel=large"
! Generate OpenRISC code for the large model: The \s-1GOT\s0 may grow up to 4G in size.
  .PP
! \fI\s-1PDP\-11\s0 Options\fR
  .IX Subsection "PDP-11 Options"
  .PP
! These options are defined for the \s-1PDP\-11:\s0
! .IP "\fB\-mfpu\fR" 4
  .IX Item "-mfpu"
! Use hardware \s-1FPP\s0 floating point.  This is the default.  (\s-1FIS\s0 floating
! point on the \s-1PDP\-11/40\s0 is not supported.)  Implies \-m45.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  Do not use hardware floating point.
! .IP "\fB\-mac0\fR" 4
  .IX Item "-mac0"
! Return floating-point results in ac0 (fr0 in Unix assembler syntax).
! .IP "\fB\-mno\-ac0\fR" 4
  .IX Item "-mno-ac0"
! Return floating-point results in memory.  This is the default.
! .IP "\fB\-m40\fR" 4
  .IX Item "-m40"
! Generate code for a \s-1PDP\-11/40.\s0  Implies \-msoft\-float \-mno\-split.
! .IP "\fB\-m45\fR" 4
  .IX Item "-m45"
! Generate code for a \s-1PDP\-11/45.\s0  This is the default.
! .IP "\fB\-m10\fR" 4
  .IX Item "-m10"
! Generate code for a \s-1PDP\-11/10.\s0  Implies \-msoft\-float \-mno\-split.
! .IP "\fB\-mint16\fR" 4
  .IX Item "-mint16"
  .PD 0
! .IP "\fB\-mno\-int32\fR" 4
  .IX Item "-mno-int32"
  .PD
  Use 16\-bit \f(CW\*(C`int\*(C'\fR.  This is the default.
! .IP "\fB\-mint32\fR" 4
  .IX Item "-mint32"
  .PD 0
! .IP "\fB\-mno\-int16\fR" 4
  .IX Item "-mno-int16"
  .PD
  Use 32\-bit \f(CW\*(C`int\*(C'\fR.
! .IP "\fB\-msplit\fR" 4
  .IX Item "-msplit"
  Target has split instruction and data space.  Implies \-m45.
! .IP "\fB\-munix\-asm\fR" 4
  .IX Item "-munix-asm"
  Use Unix assembler syntax.
! .IP "\fB\-mdec\-asm\fR" 4
  .IX Item "-mdec-asm"
! Use \s-1DEC\s0 assembler syntax.
! .IP "\fB\-mgnu\-asm\fR" 4
  .IX Item "-mgnu-asm"
! Use \s-1GNU\s0 assembler syntax.  This is the default.
! .IP "\fB\-mlra\fR" 4
  .IX Item "-mlra"
! Use the new \s-1LRA\s0 register allocator.  By default, the old \*(L"reload\*(R"
  allocator is used.
  .PP
  \fIPowerPC Options\fR
--- 27838,27976 ----
  .IX Subsection "OpenRISC Options"
  .PP
  These options are defined for OpenRISC:
! .IP \fB\-mboard=\fR\fIname\fR 4
  .IX Item "-mboard=name"
  Configure a board specific runtime.  This will be passed to the linker for
  newlib board library linking.  The default is \f(CW\*(C`or1ksim\*(C'\fR.
! .IP \fB\-mnewlib\fR 4
  .IX Item "-mnewlib"
  This option is ignored; it is for compatibility purposes only.  This used to
  select linker and preprocessor options for use with newlib.
! .IP \fB\-msoft\-div\fR 4
  .IX Item "-msoft-div"
  .PD 0
! .IP \fB\-mhard\-div\fR 4
  .IX Item "-mhard-div"
  .PD
  Select software or hardware divide (\f(CW\*(C`l.div\*(C'\fR, \f(CW\*(C`l.divu\*(C'\fR) instructions.
  This default is hardware divide.
! .IP \fB\-msoft\-mul\fR 4
  .IX Item "-msoft-mul"
  .PD 0
! .IP \fB\-mhard\-mul\fR 4
  .IX Item "-mhard-mul"
  .PD
  Select software or hardware multiply (\f(CW\*(C`l.mul\*(C'\fR, \f(CW\*(C`l.muli\*(C'\fR) instructions.
  This default is hardware multiply.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
  Select software or hardware for floating point operations.
  The default is software.
! .IP \fB\-mdouble\-float\fR 4
  .IX Item "-mdouble-float"
! When \fB\-mhard\-float\fR is selected, enables generation of double\-precision
  floating point instructions.  By default functions from \fIlibgcc\fR are used
! to perform double\-precision floating point operations.
! .IP \fB\-munordered\-float\fR 4
  .IX Item "-munordered-float"
  When \fB\-mhard\-float\fR is selected, enables generation of unordered
  floating point compare and set flag (\f(CW\*(C`lf.sfun*\*(C'\fR) instructions.  By default
  functions from \fIlibgcc\fR are used to perform unordered floating point
  compare and set flag operations.
! .IP \fB\-mcmov\fR 4
  .IX Item "-mcmov"
  Enable generation of conditional move (\f(CW\*(C`l.cmov\*(C'\fR) instructions.  By
  default the equivalent will be generated using set and branch.
! .IP \fB\-mror\fR 4
  .IX Item "-mror"
  Enable generation of rotate right (\f(CW\*(C`l.ror\*(C'\fR) instructions.  By default
  functions from \fIlibgcc\fR are used to perform rotate right operations.
! .IP \fB\-mrori\fR 4
  .IX Item "-mrori"
  Enable generation of rotate right with immediate (\f(CW\*(C`l.rori\*(C'\fR) instructions.
  By default functions from \fIlibgcc\fR are used to perform rotate right with
  immediate operations.
! .IP \fB\-msext\fR 4
  .IX Item "-msext"
  Enable generation of sign extension (\f(CW\*(C`l.ext*\*(C'\fR) instructions.  By default
  memory loads are used to perform sign extension.
! .IP \fB\-msfimm\fR 4
  .IX Item "-msfimm"
  Enable generation of compare and set flag with immediate (\f(CW\*(C`l.sf*i\*(C'\fR)
  instructions.  By default extra instructions will be generated to store the
  immediate to a register first.
! .IP \fB\-mshftimm\fR 4
  .IX Item "-mshftimm"
  Enable generation of shift with immediate (\f(CW\*(C`l.srai\*(C'\fR, \f(CW\*(C`l.srli\*(C'\fR,
  \&\f(CW\*(C`l.slli\*(C'\fR) instructions.  By default extra instructions will be generated
  to store the immediate to a register first.
! .IP \fB\-mcmodel=small\fR 4
  .IX Item "-mcmodel=small"
! Generate OpenRISC code for the small model: The GOT is limited to 64k. This is
  the default model.
! .IP \fB\-mcmodel=large\fR 4
  .IX Item "-mcmodel=large"
! Generate OpenRISC code for the large model: The GOT may grow up to 4G in size.
  .PP
! \fIPDP\-11 Options\fR
  .IX Subsection "PDP-11 Options"
  .PP
! These options are defined for the PDP\-11:
! .IP \fB\-mfpu\fR 4
  .IX Item "-mfpu"
! Use hardware FPP floating point.  This is the default.  (FIS floating
! point on the PDP\-11/40 is not supported.)  Implies \-m45.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  Do not use hardware floating point.
! .IP \fB\-mac0\fR 4
  .IX Item "-mac0"
! Return floating\-point results in ac0 (fr0 in Unix assembler syntax).
! .IP \fB\-mno\-ac0\fR 4
  .IX Item "-mno-ac0"
! Return floating\-point results in memory.  This is the default.
! .IP \fB\-m40\fR 4
  .IX Item "-m40"
! Generate code for a PDP\-11/40.  Implies \-msoft\-float \-mno\-split.
! .IP \fB\-m45\fR 4
  .IX Item "-m45"
! Generate code for a PDP\-11/45.  This is the default.
! .IP \fB\-m10\fR 4
  .IX Item "-m10"
! Generate code for a PDP\-11/10.  Implies \-msoft\-float \-mno\-split.
! .IP \fB\-mint16\fR 4
  .IX Item "-mint16"
  .PD 0
! .IP \fB\-mno\-int32\fR 4
  .IX Item "-mno-int32"
  .PD
  Use 16\-bit \f(CW\*(C`int\*(C'\fR.  This is the default.
! .IP \fB\-mint32\fR 4
  .IX Item "-mint32"
  .PD 0
! .IP \fB\-mno\-int16\fR 4
  .IX Item "-mno-int16"
  .PD
  Use 32\-bit \f(CW\*(C`int\*(C'\fR.
! .IP \fB\-msplit\fR 4
  .IX Item "-msplit"
  Target has split instruction and data space.  Implies \-m45.
! .IP \fB\-munix\-asm\fR 4
  .IX Item "-munix-asm"
  Use Unix assembler syntax.
! .IP \fB\-mdec\-asm\fR 4
  .IX Item "-mdec-asm"
! Use DEC assembler syntax.
! .IP \fB\-mgnu\-asm\fR 4
  .IX Item "-mgnu-asm"
! Use GNU assembler syntax.  This is the default.
! .IP \fB\-mlra\fR 4
  .IX Item "-mlra"
! Use the new LRA register allocator.  By default, the old "reload"
  allocator is used.
  .PP
  \fIPowerPC Options\fR
*************** allocator is used.
*** 28047,28090 ****
  .PP
  These are listed under
  .PP
! \fI\s-1PRU\s0 Options\fR
  .IX Subsection "PRU Options"
  .PP
! These command-line options are defined for \s-1PRU\s0 target:
! .IP "\fB\-minrt\fR" 4
  .IX Item "-minrt"
  Link with a minimum runtime environment, with no support for static
  initializers and constructors.  Using this option can significantly reduce
! the size of the final \s-1ELF\s0 binary.  Beware that the compiler could still
  generate code with static initializers and constructors.  It is up to the
  programmer to ensure that the source program will not use those features.
! .IP "\fB\-mmcu=\fR\fImcu\fR" 4
  .IX Item "-mmcu=mcu"
! Specify the \s-1PRU MCU\s0 variant to use.  Check Newlib for the exact list of
  supported MCUs.
! .IP "\fB\-mno\-relax\fR" 4
  .IX Item "-mno-relax"
! Make \s-1GCC\s0 pass the \fB\-\-no\-relax\fR command-line option to the linker
  instead of the \fB\-\-relax\fR option.
! .IP "\fB\-mloop\fR" 4
  .IX Item "-mloop"
! Allow (or do not allow) \s-1GCC\s0 to use the \s-1LOOP\s0 instruction.
! .IP "\fB\-mabi=\fR\fIvariant\fR" 4
  .IX Item "-mabi=variant"
! Specify the \s-1ABI\s0 variant to output code for.  \fB\-mabi=ti\fR selects the
! unmodified \s-1TI ABI\s0 while \fB\-mabi=gnu\fR selects a \s-1GNU\s0 variant that copes
! more naturally with certain \s-1GCC\s0 assumptions.  These are the differences:
  .RS 4
  .IP "\fBFunction Pointer Size\fR" 4
  .IX Item "Function Pointer Size"
! \&\s-1TI ABI\s0 specifies that function (code) pointers are 16\-bit, whereas \s-1GNU\s0
  supports only 32\-bit data and code pointers.
  .IP "\fBOptional Return Value Pointer\fR" 4
  .IX Item "Optional Return Value Pointer"
  Function return values larger than 64 bits are passed by using a hidden
! pointer as the first argument of the function.  \s-1TI ABI,\s0 though, mandates that
! the pointer can be \s-1NULL\s0 in case the caller is not using the returned value.
! \&\s-1GNU\s0 always passes and expects a valid return value pointer.
  .RE
  .RS 4
  .Sp
--- 27978,28021 ----
  .PP
  These are listed under
  .PP
! \fIPRU Options\fR
  .IX Subsection "PRU Options"
  .PP
! These command\-line options are defined for PRU target:
! .IP \fB\-minrt\fR 4
  .IX Item "-minrt"
  Link with a minimum runtime environment, with no support for static
  initializers and constructors.  Using this option can significantly reduce
! the size of the final ELF binary.  Beware that the compiler could still
  generate code with static initializers and constructors.  It is up to the
  programmer to ensure that the source program will not use those features.
! .IP \fB\-mmcu=\fR\fImcu\fR 4
  .IX Item "-mmcu=mcu"
! Specify the PRU MCU variant to use.  Check Newlib for the exact list of
  supported MCUs.
! .IP \fB\-mno\-relax\fR 4
  .IX Item "-mno-relax"
! Make GCC pass the \fB\-\-no\-relax\fR command\-line option to the linker
  instead of the \fB\-\-relax\fR option.
! .IP \fB\-mloop\fR 4
  .IX Item "-mloop"
! Allow (or do not allow) GCC to use the LOOP instruction.
! .IP \fB\-mabi=\fR\fIvariant\fR 4
  .IX Item "-mabi=variant"
! Specify the ABI variant to output code for.  \fB\-mabi=ti\fR selects the
! unmodified TI ABI while \fB\-mabi=gnu\fR selects a GNU variant that copes
! more naturally with certain GCC assumptions.  These are the differences:
  .RS 4
  .IP "\fBFunction Pointer Size\fR" 4
  .IX Item "Function Pointer Size"
! TI ABI specifies that function (code) pointers are 16\-bit, whereas GNU
  supports only 32\-bit data and code pointers.
  .IP "\fBOptional Return Value Pointer\fR" 4
  .IX Item "Optional Return Value Pointer"
  Function return values larger than 64 bits are passed by using a hidden
! pointer as the first argument of the function.  TI ABI, though, mandates that
! the pointer can be NULL in case the caller is not using the returned value.
! GNU always passes and expects a valid return value pointer.
  .RE
  .RS 4
  .Sp
*************** when any of the above code constructs is
*** 28093,28130 ****
  the standard C library cannot be built and it is omitted when linking with
  \&\fB\-mabi=ti\fR.
  .Sp
! Relaxation is a \s-1GNU\s0 feature and for safety reasons is disabled when using
! \&\fB\-mabi=ti\fR.  The \s-1TI\s0 toolchain does not emit relocations for QBBx
! instructions, so the \s-1GNU\s0 linker cannot adjust them when shortening adjacent
! \&\s-1LDI32\s0 pseudo instructions.
  .RE
  .PP
! \fIRISC-V Options\fR
  .IX Subsection "RISC-V Options"
  .PP
! These command-line options are defined for RISC-V targets:
! .IP "\fB\-mbranch\-cost=\fR\fIn\fR" 4
  .IX Item "-mbranch-cost=n"
  Set the cost of branches to roughly \fIn\fR instructions.
! .IP "\fB\-mplt\fR" 4
  .IX Item "-mplt"
  .PD 0
! .IP "\fB\-mno\-plt\fR" 4
  .IX Item "-mno-plt"
  .PD
! When generating \s-1PIC\s0 code, do or don't allow the use of PLTs. Ignored for
! non-PIC.  The default is \fB\-mplt\fR.
! .IP "\fB\-mabi=\fR\fIABI-string\fR" 4
  .IX Item "-mabi=ABI-string"
! Specify integer and floating-point calling convention.  \fIABI-string\fR
  contains two parts: the size of integer types and the registers used for
! floating-point types.  For example \fB\-march=rv64ifd \-mabi=lp64d\fR means that
  \&\fBlong\fR and pointers are 64\-bit (implicitly defining \fBint\fR to be
! 32\-bit), and that floating-point values up to 64 bits wide are passed in F
  registers.  Contrast this with \fB\-march=rv64ifd \-mabi=lp64f\fR, which still
  allows the compiler to generate code that uses the F and D extensions but only
! allows floating-point values up to 32 bits long to be passed in registers; or
! \&\fB\-march=rv64ifd \-mabi=lp64\fR, in which no floating-point arguments will be
  passed in registers.
  .Sp
  The default for this argument is system dependent, users who want a specific
--- 28024,28061 ----
  the standard C library cannot be built and it is omitted when linking with
  \&\fB\-mabi=ti\fR.
  .Sp
! Relaxation is a GNU feature and for safety reasons is disabled when using
! \&\fB\-mabi=ti\fR.  The TI toolchain does not emit relocations for QBBx
! instructions, so the GNU linker cannot adjust them when shortening adjacent
! LDI32 pseudo instructions.
  .RE
  .PP
! \fIRISC\-V Options\fR
  .IX Subsection "RISC-V Options"
  .PP
! These command\-line options are defined for RISC\-V targets:
! .IP \fB\-mbranch\-cost=\fR\fIn\fR 4
  .IX Item "-mbranch-cost=n"
  Set the cost of branches to roughly \fIn\fR instructions.
! .IP \fB\-mplt\fR 4
  .IX Item "-mplt"
  .PD 0
! .IP \fB\-mno\-plt\fR 4
  .IX Item "-mno-plt"
  .PD
! When generating PIC code, do or don\*(Aqt allow the use of PLTs. Ignored for
! non\-PIC.  The default is \fB\-mplt\fR.
! .IP \fB\-mabi=\fR\fIABI\-string\fR 4
  .IX Item "-mabi=ABI-string"
! Specify integer and floating\-point calling convention.  \fIABI\-string\fR
  contains two parts: the size of integer types and the registers used for
! floating\-point types.  For example \fB\-march=rv64ifd \-mabi=lp64d\fR means that
  \&\fBlong\fR and pointers are 64\-bit (implicitly defining \fBint\fR to be
! 32\-bit), and that floating\-point values up to 64 bits wide are passed in F
  registers.  Contrast this with \fB\-march=rv64ifd \-mabi=lp64f\fR, which still
  allows the compiler to generate code that uses the F and D extensions but only
! allows floating\-point values up to 32 bits long to be passed in registers; or
! \&\fB\-march=rv64ifd \-mabi=lp64\fR, in which no floating\-point arguments will be
  passed in registers.
  .Sp
  The default for this argument is system dependent, users who want a specific
*************** calling convention should specify one ex
*** 28132,28187 ****
  conventions are: \fBilp32\fR, \fBilp32f\fR, \fBilp32d\fR, \fBlp64\fR,
  \&\fBlp64f\fR, and \fBlp64d\fR.  Some calling conventions are impossible to
  implement on some ISAs: for example, \fB\-march=rv32if \-mabi=ilp32d\fR is
! invalid because the \s-1ABI\s0 requires 64\-bit values be passed in F registers, but F
! registers are only 32 bits wide.  There is also the \fBilp32e\fR \s-1ABI\s0 that can
! only be used with the \fBrv32e\fR architecture.  This \s-1ABI\s0 is not well
  specified at present, and is subject to change.
! .IP "\fB\-mfdiv\fR" 4
  .IX Item "-mfdiv"
  .PD 0
! .IP "\fB\-mno\-fdiv\fR" 4
  .IX Item "-mno-fdiv"
  .PD
! Do or don't use hardware floating-point divide and square root instructions.
! This requires the F or D extensions for floating-point registers.  The default
  is to use them if the specified architecture has these instructions.
! .IP "\fB\-mdiv\fR" 4
  .IX Item "-mdiv"
  .PD 0
! .IP "\fB\-mno\-div\fR" 4
  .IX Item "-mno-div"
  .PD
! Do or don't use hardware instructions for integer division.  This requires the
  M extension.  The default is to use them if the specified architecture has
  these instructions.
! .IP "\fB\-misa\-spec=\fR\fIISA-spec-string\fR" 4
  .IX Item "-misa-spec=ISA-spec-string"
! Specify the version of the RISC-V Unprivileged (formerly User-Level)
! \&\s-1ISA\s0 specification to produce code conforming to.  The possibilities
! for \fIISA-spec-string\fR are:
  .RS 4
! .ie n .IP "2.2" 4
! .el .IP "\f(CW2.2\fR" 4
  .IX Item "2.2"
  Produce code conforming to version 2.2.
! .ie n .IP "20190608" 4
! .el .IP "\f(CW20190608\fR" 4
  .IX Item "20190608"
  Produce code conforming to version 20190608.
! .ie n .IP "20191213" 4
! .el .IP "\f(CW20191213\fR" 4
  .IX Item "20191213"
  Produce code conforming to version 20191213.
  .RE
  .RS 4
  .Sp
! The default is \fB\-misa\-spec=20191213\fR unless \s-1GCC\s0 has been configured
  with \fB\-\-with\-isa\-spec=\fR specifying a different default version.
  .RE
! .IP "\fB\-march=\fR\fIISA-string\fR" 4
  .IX Item "-march=ISA-string"
! Generate code for given RISC-V \s-1ISA\s0 (e.g. \fBrv64im\fR).  \s-1ISA\s0 strings must be
! lower-case.  Examples include \fBrv64i\fR, \fBrv32g\fR, \fBrv32e\fR, and
  \&\fBrv32imaf\fR.
  .Sp
  When \fB\-march=\fR is not specified, use the setting from \fB\-mcpu\fR.
--- 28063,28118 ----
  conventions are: \fBilp32\fR, \fBilp32f\fR, \fBilp32d\fR, \fBlp64\fR,
  \&\fBlp64f\fR, and \fBlp64d\fR.  Some calling conventions are impossible to
  implement on some ISAs: for example, \fB\-march=rv32if \-mabi=ilp32d\fR is
! invalid because the ABI requires 64\-bit values be passed in F registers, but F
! registers are only 32 bits wide.  There is also the \fBilp32e\fR ABI that can
! only be used with the \fBrv32e\fR architecture.  This ABI is not well
  specified at present, and is subject to change.
! .IP \fB\-mfdiv\fR 4
  .IX Item "-mfdiv"
  .PD 0
! .IP \fB\-mno\-fdiv\fR 4
  .IX Item "-mno-fdiv"
  .PD
! Do or don\*(Aqt use hardware floating\-point divide and square root instructions.
! This requires the F or D extensions for floating\-point registers.  The default
  is to use them if the specified architecture has these instructions.
! .IP \fB\-mdiv\fR 4
  .IX Item "-mdiv"
  .PD 0
! .IP \fB\-mno\-div\fR 4
  .IX Item "-mno-div"
  .PD
! Do or don\*(Aqt use hardware instructions for integer division.  This requires the
  M extension.  The default is to use them if the specified architecture has
  these instructions.
! .IP \fB\-misa\-spec=\fR\fIISA\-spec\-string\fR 4
  .IX Item "-misa-spec=ISA-spec-string"
! Specify the version of the RISC\-V Unprivileged (formerly User\-Level)
! ISA specification to produce code conforming to.  The possibilities
! for \fIISA\-spec\-string\fR are:
  .RS 4
! .ie n .IP 2.2 4
! .el .IP \f(CW2.2\fR 4
  .IX Item "2.2"
  Produce code conforming to version 2.2.
! .ie n .IP 20190608 4
! .el .IP \f(CW20190608\fR 4
  .IX Item "20190608"
  Produce code conforming to version 20190608.
! .ie n .IP 20191213 4
! .el .IP \f(CW20191213\fR 4
  .IX Item "20191213"
  Produce code conforming to version 20191213.
  .RE
  .RS 4
  .Sp
! The default is \fB\-misa\-spec=20191213\fR unless GCC has been configured
  with \fB\-\-with\-isa\-spec=\fR specifying a different default version.
  .RE
! .IP \fB\-march=\fR\fIISA\-string\fR 4
  .IX Item "-march=ISA-string"
! Generate code for given RISC\-V ISA (e.g. \fBrv64im\fR).  ISA strings must be
! lower\-case.  Examples include \fBrv64i\fR, \fBrv32g\fR, \fBrv32e\fR, and
  \&\fBrv32imaf\fR.
  .Sp
  When \fB\-march=\fR is not specified, use the setting from \fB\-mcpu\fR.
*************** When \fB\-march=\fR is not specified, us
*** 28189,28217 ****
  If both \fB\-march\fR and \fB\-mcpu=\fR are not specified, the default for
  this argument is system dependent, users who want a specific architecture
  extensions should specify one explicitly.
! .IP "\fB\-mcpu=\fR\fIprocessor-string\fR" 4
  .IX Item "-mcpu=processor-string"
  Use architecture of and optimize the output for the given processor, specified
! by particular \s-1CPU\s0 name.
  Permissible values for this option are: \fBsifive\-e20\fR, \fBsifive\-e21\fR,
  \&\fBsifive\-e24\fR, \fBsifive\-e31\fR, \fBsifive\-e34\fR, \fBsifive\-e76\fR,
  \&\fBsifive\-s21\fR, \fBsifive\-s51\fR, \fBsifive\-s54\fR, \fBsifive\-s76\fR,
  \&\fBsifive\-u54\fR, and \fBsifive\-u74\fR.
! .IP "\fB\-mtune=\fR\fIprocessor-string\fR" 4
  .IX Item "-mtune=processor-string"
  Optimize the output for the given processor, specified by microarchitecture or
! particular \s-1CPU\s0 name.  Permissible values for this option are: \fBrocket\fR,
  \&\fBsifive\-3\-series\fR, \fBsifive\-5\-series\fR, \fBsifive\-7\-series\fR,
  \&\fBthead\-c906\fR, \fBsize\fR, and all valid options for \fB\-mcpu=\fR.
  .Sp
  When \fB\-mtune=\fR is not specified, use the setting from \fB\-mcpu\fR,
  the default is \fBrocket\fR if both are not specified.
  .Sp
! The \fBsize\fR choice is not intended for use by end-users.  This is used
  when \fB\-Os\fR is specified.  It overrides the instruction cost info
  provided by \fB\-mtune=\fR, but does not override the pipeline info.  This
  helps reduce code size while still giving good performance.
! .IP "\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR" 4
  .IX Item "-mpreferred-stack-boundary=num"
  Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
  byte boundary.  If \fB\-mpreferred\-stack\-boundary\fR is not specified,
--- 28120,28148 ----
  If both \fB\-march\fR and \fB\-mcpu=\fR are not specified, the default for
  this argument is system dependent, users who want a specific architecture
  extensions should specify one explicitly.
! .IP \fB\-mcpu=\fR\fIprocessor\-string\fR 4
  .IX Item "-mcpu=processor-string"
  Use architecture of and optimize the output for the given processor, specified
! by particular CPU name.
  Permissible values for this option are: \fBsifive\-e20\fR, \fBsifive\-e21\fR,
  \&\fBsifive\-e24\fR, \fBsifive\-e31\fR, \fBsifive\-e34\fR, \fBsifive\-e76\fR,
  \&\fBsifive\-s21\fR, \fBsifive\-s51\fR, \fBsifive\-s54\fR, \fBsifive\-s76\fR,
  \&\fBsifive\-u54\fR, and \fBsifive\-u74\fR.
! .IP \fB\-mtune=\fR\fIprocessor\-string\fR 4
  .IX Item "-mtune=processor-string"
  Optimize the output for the given processor, specified by microarchitecture or
! particular CPU name.  Permissible values for this option are: \fBrocket\fR,
  \&\fBsifive\-3\-series\fR, \fBsifive\-5\-series\fR, \fBsifive\-7\-series\fR,
  \&\fBthead\-c906\fR, \fBsize\fR, and all valid options for \fB\-mcpu=\fR.
  .Sp
  When \fB\-mtune=\fR is not specified, use the setting from \fB\-mcpu\fR,
  the default is \fBrocket\fR if both are not specified.
  .Sp
! The \fBsize\fR choice is not intended for use by end\-users.  This is used
  when \fB\-Os\fR is specified.  It overrides the instruction cost info
  provided by \fB\-mtune=\fR, but does not override the pipeline info.  This
  helps reduce code size while still giving good performance.
! .IP \fB\-mpreferred\-stack\-boundary=\fR\fInum\fR 4
  .IX Item "-mpreferred-stack-boundary=num"
  Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
  byte boundary.  If \fB\-mpreferred\-stack\-boundary\fR is not specified,
*************** the default is 4 (16 bytes or 128\-bits)
*** 28220,28341 ****
  \&\fBWarning:\fR If you use this switch, then you must build all modules with
  the same value, including any libraries.  This includes the system libraries
  and startup modules.
! .IP "\fB\-msmall\-data\-limit=\fR\fIn\fR" 4
  .IX Item "-msmall-data-limit=n"
  Put global and static data smaller than \fIn\fR bytes into a special section
  (on some targets).
! .IP "\fB\-msave\-restore\fR" 4
  .IX Item "-msave-restore"
  .PD 0
! .IP "\fB\-mno\-save\-restore\fR" 4
  .IX Item "-mno-save-restore"
  .PD
! Do or don't use smaller but slower prologue and epilogue code that uses
  library function calls.  The default is to use fast inline prologues and
  epilogues.
! .IP "\fB\-minline\-atomics\fR" 4
  .IX Item "-minline-atomics"
  .PD 0
! .IP "\fB\-mno\-inline\-atomics\fR" 4
  .IX Item "-mno-inline-atomics"
  .PD
! Do or don't use smaller but slower subword atomic emulation code that uses
  libatomic function calls.  The default is to use fast inline subword atomics
  that do not require libatomic.
! .IP "\fB\-mshorten\-memrefs\fR" 4
  .IX Item "-mshorten-memrefs"
  .PD 0
! .IP "\fB\-mno\-shorten\-memrefs\fR" 4
  .IX Item "-mno-shorten-memrefs"
  .PD
  Do or do not attempt to make more use of compressed load/store instructions by
! replacing a load/store of 'base register + large offset' with a new load/store
! of 'new base + small offset'.  If the new base gets stored in a compressed
  register, then the new load/store can be compressed.  Currently targets 32\-bit
  integer load/stores only.
! .IP "\fB\-mstrict\-align\fR" 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP "\fB\-mno\-strict\-align\fR" 4
  .IX Item "-mno-strict-align"
  .PD
  Do not or do generate unaligned memory accesses.  The default is set depending
  on whether the processor we are optimizing for supports fast unaligned access
  or not.
! .IP "\fB\-mcmodel=medlow\fR" 4
  .IX Item "-mcmodel=medlow"
! Generate code for the medium-low code model. The program and its statically
  defined symbols must lie within a single 2 GiB address range and must lie
  between absolute addresses \-2 GiB and +2 GiB. Programs can be
  statically or dynamically linked. This is the default code model.
! .IP "\fB\-mcmodel=medany\fR" 4
  .IX Item "-mcmodel=medany"
! Generate code for the medium-any code model. The program and its statically
  defined symbols must be within any single 2 GiB address range. Programs can be
  statically or dynamically linked.
  .Sp
! The code generated by the medium-any code model is position-independent, but is
! not guaranteed to function correctly when linked into position-independent
  executables or libraries.
! .IP "\fB\-mexplicit\-relocs\fR" 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP "\fB\-mno\-exlicit\-relocs\fR" 4
  .IX Item "-mno-exlicit-relocs"
  .PD
  Use or do not use assembler relocation operators when dealing with symbolic
  addresses.  The alternative is to use assembler macros instead, which may
  limit optimization.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  .PD 0
! .IP "\fB\-mno\-relax\fR" 4
  .IX Item "-mno-relax"
  .PD
  Take advantage of linker relaxations to reduce the number of instructions
  required to materialize symbol addresses. The default is to take advantage of
  linker relaxations.
! .IP "\fB\-mriscv\-attribute\fR" 4
  .IX Item "-mriscv-attribute"
  .PD 0
! .IP "\fB\-mno\-riscv\-attribute\fR" 4
  .IX Item "-mno-riscv-attribute"
  .PD
! Emit (do not emit) RISC-V attribute to record extra information into \s-1ELF\s0
  objects.  This feature requires at least binutils 2.32.
! .IP "\fB\-mcsr\-check\fR" 4
  .IX Item "-mcsr-check"
  .PD 0
! .IP "\fB\-mno\-csr\-check\fR" 4
  .IX Item "-mno-csr-check"
  .PD
! Enables or disables the \s-1CSR\s0 checking.
! .IP "\fB\-malign\-data=\fR\fItype\fR" 4
  .IX Item "-malign-data=type"
! Control how \s-1GCC\s0 aligns variables and constants of array, structure, or union
  types.  Supported values for \fItype\fR are \fBxlen\fR which uses x register
  width as the alignment value, and \fBnatural\fR which uses natural alignment.
  \&\fBxlen\fR is the default.
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
! Generate big-endian code.  This is the default when \s-1GCC\s0 is configured for a
  \&\fBriscv64be\-*\-*\fR or \fBriscv32be\-*\-*\fR target.
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
! Generate little-endian code.  This is the default when \s-1GCC\s0 is configured for a
  \&\fBriscv64\-*\-*\fR or \fBriscv32\-*\-*\fR but not a \fBriscv64be\-*\-*\fR or
  \&\fBriscv32be\-*\-*\fR target.
! .IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP "\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR" 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP "\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR" 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for a global canary or \fBtls\fR for per-thread
! canary in the \s-1TLS\s0 block.
  .Sp
  With the latter choice the options
  \&\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR and
--- 28151,28272 ----
  \&\fBWarning:\fR If you use this switch, then you must build all modules with
  the same value, including any libraries.  This includes the system libraries
  and startup modules.
! .IP \fB\-msmall\-data\-limit=\fR\fIn\fR 4
  .IX Item "-msmall-data-limit=n"
  Put global and static data smaller than \fIn\fR bytes into a special section
  (on some targets).
! .IP \fB\-msave\-restore\fR 4
  .IX Item "-msave-restore"
  .PD 0
! .IP \fB\-mno\-save\-restore\fR 4
  .IX Item "-mno-save-restore"
  .PD
! Do or don\*(Aqt use smaller but slower prologue and epilogue code that uses
  library function calls.  The default is to use fast inline prologues and
  epilogues.
! .IP \fB\-minline\-atomics\fR 4
  .IX Item "-minline-atomics"
  .PD 0
! .IP \fB\-mno\-inline\-atomics\fR 4
  .IX Item "-mno-inline-atomics"
  .PD
! Do or don\*(Aqt use smaller but slower subword atomic emulation code that uses
  libatomic function calls.  The default is to use fast inline subword atomics
  that do not require libatomic.
! .IP \fB\-mshorten\-memrefs\fR 4
  .IX Item "-mshorten-memrefs"
  .PD 0
! .IP \fB\-mno\-shorten\-memrefs\fR 4
  .IX Item "-mno-shorten-memrefs"
  .PD
  Do or do not attempt to make more use of compressed load/store instructions by
! replacing a load/store of \*(Aqbase register + large offset\*(Aq with a new load/store
! of \*(Aqnew base + small offset\*(Aq.  If the new base gets stored in a compressed
  register, then the new load/store can be compressed.  Currently targets 32\-bit
  integer load/stores only.
! .IP \fB\-mstrict\-align\fR 4
  .IX Item "-mstrict-align"
  .PD 0
! .IP \fB\-mno\-strict\-align\fR 4
  .IX Item "-mno-strict-align"
  .PD
  Do not or do generate unaligned memory accesses.  The default is set depending
  on whether the processor we are optimizing for supports fast unaligned access
  or not.
! .IP \fB\-mcmodel=medlow\fR 4
  .IX Item "-mcmodel=medlow"
! Generate code for the medium\-low code model. The program and its statically
  defined symbols must lie within a single 2 GiB address range and must lie
  between absolute addresses \-2 GiB and +2 GiB. Programs can be
  statically or dynamically linked. This is the default code model.
! .IP \fB\-mcmodel=medany\fR 4
  .IX Item "-mcmodel=medany"
! Generate code for the medium\-any code model. The program and its statically
  defined symbols must be within any single 2 GiB address range. Programs can be
  statically or dynamically linked.
  .Sp
! The code generated by the medium\-any code model is position\-independent, but is
! not guaranteed to function correctly when linked into position\-independent
  executables or libraries.
! .IP \fB\-mexplicit\-relocs\fR 4
  .IX Item "-mexplicit-relocs"
  .PD 0
! .IP \fB\-mno\-exlicit\-relocs\fR 4
  .IX Item "-mno-exlicit-relocs"
  .PD
  Use or do not use assembler relocation operators when dealing with symbolic
  addresses.  The alternative is to use assembler macros instead, which may
  limit optimization.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  .PD 0
! .IP \fB\-mno\-relax\fR 4
  .IX Item "-mno-relax"
  .PD
  Take advantage of linker relaxations to reduce the number of instructions
  required to materialize symbol addresses. The default is to take advantage of
  linker relaxations.
! .IP \fB\-mriscv\-attribute\fR 4
  .IX Item "-mriscv-attribute"
  .PD 0
! .IP \fB\-mno\-riscv\-attribute\fR 4
  .IX Item "-mno-riscv-attribute"
  .PD
! Emit (do not emit) RISC\-V attribute to record extra information into ELF
  objects.  This feature requires at least binutils 2.32.
! .IP \fB\-mcsr\-check\fR 4
  .IX Item "-mcsr-check"
  .PD 0
! .IP \fB\-mno\-csr\-check\fR 4
  .IX Item "-mno-csr-check"
  .PD
! Enables or disables the CSR checking.
! .IP \fB\-malign\-data=\fR\fItype\fR 4
  .IX Item "-malign-data=type"
! Control how GCC aligns variables and constants of array, structure, or union
  types.  Supported values for \fItype\fR are \fBxlen\fR which uses x register
  width as the alignment value, and \fBnatural\fR which uses natural alignment.
  \&\fBxlen\fR is the default.
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
! Generate big\-endian code.  This is the default when GCC is configured for a
  \&\fBriscv64be\-*\-*\fR or \fBriscv32be\-*\-*\fR target.
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
! Generate little\-endian code.  This is the default when GCC is configured for a
  \&\fBriscv64\-*\-*\fR or \fBriscv32\-*\-*\fR but not a \fBriscv64be\-*\-*\fR or
  \&\fBriscv32be\-*\-*\fR target.
! .IP \fB\-mstack\-protector\-guard=\fR\fIguard\fR 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP \fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for a global canary or \fBtls\fR for per\-thread
! canary in the TLS block.
  .Sp
  With the latter choice the options
  \&\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR and
*************** and from what offset from that base regi
*** 28345,28392 ****
  register or offset as this is entirely for use within the Linux
  kernel.
  .PP
! \fI\s-1RL78\s0 Options\fR
  .IX Subsection "RL78 Options"
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Links in additional target libraries to support operation within a
  simulator.
! .IP "\fB\-mmul=none\fR" 4
  .IX Item "-mmul=none"
  .PD 0
! .IP "\fB\-mmul=g10\fR" 4
  .IX Item "-mmul=g10"
! .IP "\fB\-mmul=g13\fR" 4
  .IX Item "-mmul=g13"
! .IP "\fB\-mmul=g14\fR" 4
  .IX Item "-mmul=g14"
! .IP "\fB\-mmul=rl78\fR" 4
  .IX Item "-mmul=rl78"
  .PD
  Specifies the type of hardware multiplication and division support to
  be used.  The simplest is \f(CW\*(C`none\*(C'\fR, which uses software for both
  multiplication and division.  This is the default.  The \f(CW\*(C`g13\*(C'\fR
  value is for the hardware multiply/divide peripheral found on the
! \&\s-1RL78/G13\s0 (S2 core) targets.  The \f(CW\*(C`g14\*(C'\fR value selects the use of
! the multiplication and division instructions supported by the \s-1RL78/G14\s0
  (S3 core) parts.  The value \f(CW\*(C`rl78\*(C'\fR is an alias for \f(CW\*(C`g14\*(C'\fR and
  the value \f(CW\*(C`mg10\*(C'\fR is an alias for \f(CW\*(C`none\*(C'\fR.
  .Sp
  In addition a C preprocessor macro is defined, based upon the setting
  of this option.  Possible values are: \f(CW\*(C`_\|_RL78_MUL_NONE_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_RL78_MUL_G13_\|_\*(C'\fR or \f(CW\*(C`_\|_RL78_MUL_G14_\|_\*(C'\fR.
! .IP "\fB\-mcpu=g10\fR" 4
  .IX Item "-mcpu=g10"
  .PD 0
! .IP "\fB\-mcpu=g13\fR" 4
  .IX Item "-mcpu=g13"
! .IP "\fB\-mcpu=g14\fR" 4
  .IX Item "-mcpu=g14"
! .IP "\fB\-mcpu=rl78\fR" 4
  .IX Item "-mcpu=rl78"
  .PD
! Specifies the \s-1RL78\s0 core to target.  The default is the G14 core, also
! known as an S3 core or just \s-1RL78.\s0  The G13 or S2 core does not have
  multiply or divide instructions, instead it uses a hardware peripheral
  for these operations.  The G10 or S1 core does not have register
  banks, so it uses a different calling convention.
--- 28276,28323 ----
  register or offset as this is entirely for use within the Linux
  kernel.
  .PP
! \fIRL78 Options\fR
  .IX Subsection "RL78 Options"
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Links in additional target libraries to support operation within a
  simulator.
! .IP \fB\-mmul=none\fR 4
  .IX Item "-mmul=none"
  .PD 0
! .IP \fB\-mmul=g10\fR 4
  .IX Item "-mmul=g10"
! .IP \fB\-mmul=g13\fR 4
  .IX Item "-mmul=g13"
! .IP \fB\-mmul=g14\fR 4
  .IX Item "-mmul=g14"
! .IP \fB\-mmul=rl78\fR 4
  .IX Item "-mmul=rl78"
  .PD
  Specifies the type of hardware multiplication and division support to
  be used.  The simplest is \f(CW\*(C`none\*(C'\fR, which uses software for both
  multiplication and division.  This is the default.  The \f(CW\*(C`g13\*(C'\fR
  value is for the hardware multiply/divide peripheral found on the
! RL78/G13 (S2 core) targets.  The \f(CW\*(C`g14\*(C'\fR value selects the use of
! the multiplication and division instructions supported by the RL78/G14
  (S3 core) parts.  The value \f(CW\*(C`rl78\*(C'\fR is an alias for \f(CW\*(C`g14\*(C'\fR and
  the value \f(CW\*(C`mg10\*(C'\fR is an alias for \f(CW\*(C`none\*(C'\fR.
  .Sp
  In addition a C preprocessor macro is defined, based upon the setting
  of this option.  Possible values are: \f(CW\*(C`_\|_RL78_MUL_NONE_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_RL78_MUL_G13_\|_\*(C'\fR or \f(CW\*(C`_\|_RL78_MUL_G14_\|_\*(C'\fR.
! .IP \fB\-mcpu=g10\fR 4
  .IX Item "-mcpu=g10"
  .PD 0
! .IP \fB\-mcpu=g13\fR 4
  .IX Item "-mcpu=g13"
! .IP \fB\-mcpu=g14\fR 4
  .IX Item "-mcpu=g14"
! .IP \fB\-mcpu=rl78\fR 4
  .IX Item "-mcpu=rl78"
  .PD
! Specifies the RL78 core to target.  The default is the G14 core, also
! known as an S3 core or just RL78.  The G13 or S2 core does not have
  multiply or divide instructions, instead it uses a hardware peripheral
  for these operations.  The G10 or S1 core does not have register
  banks, so it uses a different calling convention.
*************** support to use, unless this is overridde
*** 28398,28539 ****
  peripheral and specifying \fB\-mcpu=g10\fR disables the use of
  hardware multiplications altogether.
  .Sp
! Note, although the \s-1RL78/G14\s0 core is the default target, specifying
  \&\fB\-mcpu=g14\fR or \fB\-mcpu=rl78\fR on the command line does
  change the behavior of the toolchain since it also enables G14
  hardware multiply support.  If these options are not specified on the
  command line then software multiplication routines will be used even
! though the code targets the \s-1RL78\s0 core.  This is for backwards
  compatibility with older toolchains which did not have hardware
  multiply and divide support.
  .Sp
  In addition a C preprocessor macro is defined, based upon the setting
  of this option.  Possible values are: \f(CW\*(C`_\|_RL78_G10_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_RL78_G13_\|_\*(C'\fR or \f(CW\*(C`_\|_RL78_G14_\|_\*(C'\fR.
! .IP "\fB\-mg10\fR" 4
  .IX Item "-mg10"
  .PD 0
! .IP "\fB\-mg13\fR" 4
  .IX Item "-mg13"
! .IP "\fB\-mg14\fR" 4
  .IX Item "-mg14"
! .IP "\fB\-mrl78\fR" 4
  .IX Item "-mrl78"
  .PD
  These are aliases for the corresponding \fB\-mcpu=\fR option.  They
  are provided for backwards compatibility.
! .IP "\fB\-mallregs\fR" 4
  .IX Item "-mallregs"
  Allow the compiler to use all of the available registers.  By default
  registers \f(CW\*(C`r24..r31\*(C'\fR are reserved for use in interrupt handlers.
  With this option enabled these registers can be used in ordinary
  functions as well.
! .IP "\fB\-m64bit\-doubles\fR" 4
  .IX Item "-m64bit-doubles"
  .PD 0
! .IP "\fB\-m32bit\-doubles\fR" 4
  .IX Item "-m32bit-doubles"
  .PD
  Make the \f(CW\*(C`double\*(C'\fR data type be 64 bits (\fB\-m64bit\-doubles\fR)
  or 32 bits (\fB\-m32bit\-doubles\fR) in size.  The default is
  \&\fB\-m32bit\-doubles\fR.
! .IP "\fB\-msave\-mduc\-in\-interrupts\fR" 4
  .IX Item "-msave-mduc-in-interrupts"
  .PD 0
! .IP "\fB\-mno\-save\-mduc\-in\-interrupts\fR" 4
  .IX Item "-mno-save-mduc-in-interrupts"
  .PD
  Specifies that interrupt handler functions should preserve the
! \&\s-1MDUC\s0 registers.  This is only necessary if normal code might use
! the \s-1MDUC\s0 registers, for example because it performs multiplication
! and division operations.  The default is to ignore the \s-1MDUC\s0 registers
  as this makes the interrupt handlers faster.  The target option \-mg13
  needs to be passed for this to work as this feature is only available
! on the G13 target (S2 core).  The \s-1MDUC\s0 registers will only be saved
  if the interrupt handler performs a multiplication or division
  operation or it calls another function.
  .PP
! \fI\s-1IBM RS/6000\s0 and PowerPC Options\fR
  .IX Subsection "IBM RS/6000 and PowerPC Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1IBM RS/6000\s0 and PowerPC:
! .IP "\fB\-mpowerpc\-gpopt\fR" 4
  .IX Item "-mpowerpc-gpopt"
  .PD 0
! .IP "\fB\-mno\-powerpc\-gpopt\fR" 4
  .IX Item "-mno-powerpc-gpopt"
! .IP "\fB\-mpowerpc\-gfxopt\fR" 4
  .IX Item "-mpowerpc-gfxopt"
! .IP "\fB\-mno\-powerpc\-gfxopt\fR" 4
  .IX Item "-mno-powerpc-gfxopt"
! .IP "\fB\-mpowerpc64\fR" 4
  .IX Item "-mpowerpc64"
! .IP "\fB\-mno\-powerpc64\fR" 4
  .IX Item "-mno-powerpc64"
! .IP "\fB\-mmfcrf\fR" 4
  .IX Item "-mmfcrf"
! .IP "\fB\-mno\-mfcrf\fR" 4
  .IX Item "-mno-mfcrf"
! .IP "\fB\-mpopcntb\fR" 4
  .IX Item "-mpopcntb"
! .IP "\fB\-mno\-popcntb\fR" 4
  .IX Item "-mno-popcntb"
! .IP "\fB\-mpopcntd\fR" 4
  .IX Item "-mpopcntd"
! .IP "\fB\-mno\-popcntd\fR" 4
  .IX Item "-mno-popcntd"
! .IP "\fB\-mfprnd\fR" 4
  .IX Item "-mfprnd"
! .IP "\fB\-mno\-fprnd\fR" 4
  .IX Item "-mno-fprnd"
! .IP "\fB\-mcmpb\fR" 4
  .IX Item "-mcmpb"
! .IP "\fB\-mno\-cmpb\fR" 4
  .IX Item "-mno-cmpb"
! .IP "\fB\-mhard\-dfp\fR" 4
  .IX Item "-mhard-dfp"
! .IP "\fB\-mno\-hard\-dfp\fR" 4
  .IX Item "-mno-hard-dfp"
  .PD
  You use these options to specify which instructions are available on the
  processor you are using.  The default value of these options is
! determined when configuring \s-1GCC.\s0  Specifying the
  \&\fB\-mcpu=\fR\fIcpu_type\fR overrides the specification of these
  options.  We recommend you use the \fB\-mcpu=\fR\fIcpu_type\fR option
  rather than the options listed above.
  .Sp
  Specifying \fB\-mpowerpc\-gpopt\fR allows
! \&\s-1GCC\s0 to use the optional PowerPC architecture instructions in the
! General Purpose group, including floating-point square root.  Specifying
! \&\fB\-mpowerpc\-gfxopt\fR allows \s-1GCC\s0 to
  use the optional PowerPC architecture instructions in the Graphics
! group, including floating-point select.
  .Sp
! The \fB\-mmfcrf\fR option allows \s-1GCC\s0 to generate the move from
! condition register field instruction implemented on the \s-1POWER4\s0
  processor and other processors that support the PowerPC V2.01
  architecture.
! The \fB\-mpopcntb\fR option allows \s-1GCC\s0 to generate the popcount and
! double-precision \s-1FP\s0 reciprocal estimate instruction implemented on the
! \&\s-1POWER5\s0 processor and other processors that support the PowerPC V2.02
  architecture.
! The \fB\-mpopcntd\fR option allows \s-1GCC\s0 to generate the popcount
! instruction implemented on the \s-1POWER7\s0 processor and other processors
  that support the PowerPC V2.06 architecture.
! The \fB\-mfprnd\fR option allows \s-1GCC\s0 to generate the \s-1FP\s0 round to
! integer instructions implemented on the \s-1POWER5+\s0 processor and other
  processors that support the PowerPC V2.03 architecture.
! The \fB\-mcmpb\fR option allows \s-1GCC\s0 to generate the compare bytes
! instruction implemented on the \s-1POWER6\s0 processor and other processors
  that support the PowerPC V2.05 architecture.
! The \fB\-mhard\-dfp\fR option allows \s-1GCC\s0 to generate the decimal
! floating-point instructions implemented on some \s-1POWER\s0 processors.
  .Sp
! The \fB\-mpowerpc64\fR option allows \s-1GCC\s0 to generate the additional
  64\-bit instructions that are found in the full PowerPC64 architecture
! and to treat GPRs as 64\-bit, doubleword quantities.  \s-1GCC\s0 defaults to
  \&\fB\-mno\-powerpc64\fR.
! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
  .IX Item "-mcpu=cpu_type"
  Set architecture type, register usage, and
  instruction scheduling parameters for machine type \fIcpu_type\fR.
--- 28329,28470 ----
  peripheral and specifying \fB\-mcpu=g10\fR disables the use of
  hardware multiplications altogether.
  .Sp
! Note, although the RL78/G14 core is the default target, specifying
  \&\fB\-mcpu=g14\fR or \fB\-mcpu=rl78\fR on the command line does
  change the behavior of the toolchain since it also enables G14
  hardware multiply support.  If these options are not specified on the
  command line then software multiplication routines will be used even
! though the code targets the RL78 core.  This is for backwards
  compatibility with older toolchains which did not have hardware
  multiply and divide support.
  .Sp
  In addition a C preprocessor macro is defined, based upon the setting
  of this option.  Possible values are: \f(CW\*(C`_\|_RL78_G10_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_RL78_G13_\|_\*(C'\fR or \f(CW\*(C`_\|_RL78_G14_\|_\*(C'\fR.
! .IP \fB\-mg10\fR 4
  .IX Item "-mg10"
  .PD 0
! .IP \fB\-mg13\fR 4
  .IX Item "-mg13"
! .IP \fB\-mg14\fR 4
  .IX Item "-mg14"
! .IP \fB\-mrl78\fR 4
  .IX Item "-mrl78"
  .PD
  These are aliases for the corresponding \fB\-mcpu=\fR option.  They
  are provided for backwards compatibility.
! .IP \fB\-mallregs\fR 4
  .IX Item "-mallregs"
  Allow the compiler to use all of the available registers.  By default
  registers \f(CW\*(C`r24..r31\*(C'\fR are reserved for use in interrupt handlers.
  With this option enabled these registers can be used in ordinary
  functions as well.
! .IP \fB\-m64bit\-doubles\fR 4
  .IX Item "-m64bit-doubles"
  .PD 0
! .IP \fB\-m32bit\-doubles\fR 4
  .IX Item "-m32bit-doubles"
  .PD
  Make the \f(CW\*(C`double\*(C'\fR data type be 64 bits (\fB\-m64bit\-doubles\fR)
  or 32 bits (\fB\-m32bit\-doubles\fR) in size.  The default is
  \&\fB\-m32bit\-doubles\fR.
! .IP \fB\-msave\-mduc\-in\-interrupts\fR 4
  .IX Item "-msave-mduc-in-interrupts"
  .PD 0
! .IP \fB\-mno\-save\-mduc\-in\-interrupts\fR 4
  .IX Item "-mno-save-mduc-in-interrupts"
  .PD
  Specifies that interrupt handler functions should preserve the
! MDUC registers.  This is only necessary if normal code might use
! the MDUC registers, for example because it performs multiplication
! and division operations.  The default is to ignore the MDUC registers
  as this makes the interrupt handlers faster.  The target option \-mg13
  needs to be passed for this to work as this feature is only available
! on the G13 target (S2 core).  The MDUC registers will only be saved
  if the interrupt handler performs a multiplication or division
  operation or it calls another function.
  .PP
! \fIIBM RS/6000 and PowerPC Options\fR
  .IX Subsection "IBM RS/6000 and PowerPC Options"
  .PP
! These \fB\-m\fR options are defined for the IBM RS/6000 and PowerPC:
! .IP \fB\-mpowerpc\-gpopt\fR 4
  .IX Item "-mpowerpc-gpopt"
  .PD 0
! .IP \fB\-mno\-powerpc\-gpopt\fR 4
  .IX Item "-mno-powerpc-gpopt"
! .IP \fB\-mpowerpc\-gfxopt\fR 4
  .IX Item "-mpowerpc-gfxopt"
! .IP \fB\-mno\-powerpc\-gfxopt\fR 4
  .IX Item "-mno-powerpc-gfxopt"
! .IP \fB\-mpowerpc64\fR 4
  .IX Item "-mpowerpc64"
! .IP \fB\-mno\-powerpc64\fR 4
  .IX Item "-mno-powerpc64"
! .IP \fB\-mmfcrf\fR 4
  .IX Item "-mmfcrf"
! .IP \fB\-mno\-mfcrf\fR 4
  .IX Item "-mno-mfcrf"
! .IP \fB\-mpopcntb\fR 4
  .IX Item "-mpopcntb"
! .IP \fB\-mno\-popcntb\fR 4
  .IX Item "-mno-popcntb"
! .IP \fB\-mpopcntd\fR 4
  .IX Item "-mpopcntd"
! .IP \fB\-mno\-popcntd\fR 4
  .IX Item "-mno-popcntd"
! .IP \fB\-mfprnd\fR 4
  .IX Item "-mfprnd"
! .IP \fB\-mno\-fprnd\fR 4
  .IX Item "-mno-fprnd"
! .IP \fB\-mcmpb\fR 4
  .IX Item "-mcmpb"
! .IP \fB\-mno\-cmpb\fR 4
  .IX Item "-mno-cmpb"
! .IP \fB\-mhard\-dfp\fR 4
  .IX Item "-mhard-dfp"
! .IP \fB\-mno\-hard\-dfp\fR 4
  .IX Item "-mno-hard-dfp"
  .PD
  You use these options to specify which instructions are available on the
  processor you are using.  The default value of these options is
! determined when configuring GCC.  Specifying the
  \&\fB\-mcpu=\fR\fIcpu_type\fR overrides the specification of these
  options.  We recommend you use the \fB\-mcpu=\fR\fIcpu_type\fR option
  rather than the options listed above.
  .Sp
  Specifying \fB\-mpowerpc\-gpopt\fR allows
! GCC to use the optional PowerPC architecture instructions in the
! General Purpose group, including floating\-point square root.  Specifying
! \&\fB\-mpowerpc\-gfxopt\fR allows GCC to
  use the optional PowerPC architecture instructions in the Graphics
! group, including floating\-point select.
  .Sp
! The \fB\-mmfcrf\fR 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 \fB\-mpopcntb\fR 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 \fB\-mpopcntd\fR option allows GCC to generate the popcount
! instruction implemented on the POWER7 processor and other processors
  that support the PowerPC V2.06 architecture.
! The \fB\-mfprnd\fR 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 \fB\-mcmpb\fR 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 \fB\-mhard\-dfp\fR option allows GCC to generate the decimal
! floating\-point instructions implemented on some POWER processors.
  .Sp
! The \fB\-mpowerpc64\fR 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
  \&\fB\-mno\-powerpc64\fR.
! .IP \fB\-mcpu=\fR\fIcpu_type\fR 4
  .IX Item "-mcpu=cpu_type"
  Set architecture type, register usage, and
  instruction scheduling parameters for machine type \fIcpu_type\fR.
*************** model assumed for scheduling purposes.
*** 28559,28565 ****
  Specifying \fBnative\fR as cpu type detects and selects the
  architecture option that corresponds to the host processor of the
  system performing the compilation.
! \&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize the
  processor.
  .Sp
  The other options specify a specific processor.  Code generated under
--- 28490,28496 ----
  Specifying \fBnative\fR as cpu type detects and selects the
  architecture option that corresponds to the host processor of the
  system performing the compilation.
! \&\fB\-mcpu=native\fR has no effect if GCC does not recognize the
  processor.
  .Sp
  The other options specify a specific processor.  Code generated under
*************** following options:
*** 28578,28596 ****
  \&\-mfloat128\-hardware \-mprefixed \-mpcrel \-mmma
  \&\-mrop\-protect\fR
  .Sp
! The particular options set for any particular \s-1CPU\s0 varies between
  compiler versions, depending on what setting seems to produce optimal
! code for that \s-1CPU\s0; it doesn't necessarily reflect the actual hardware's
  capabilities.  If you wish to set an individual option to a particular
  value, you may specify it after the \fB\-mcpu\fR option, like
  \&\fB\-mcpu=970 \-mno\-altivec\fR.
  .Sp
! On \s-1AIX,\s0 the \fB\-maltivec\fR and \fB\-mpowerpc64\fR options are
  not enabled or disabled by the \fB\-mcpu\fR option at present because
! \&\s-1AIX\s0 does not have full support for these options.  You may still
! enable or disable them individually if you're sure it'll work in your
  environment.
! .IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR, but do not set the architecture type or register usage,
--- 28509,28527 ----
  \&\-mfloat128\-hardware \-mprefixed \-mpcrel \-mmma
  \&\-mrop\-protect\fR
  .Sp
! The particular options set for any particular CPU varies between
  compiler versions, depending on what setting seems to produce optimal
! code for that CPU; it doesn\*(Aqt necessarily reflect the actual hardware\*(Aqs
  capabilities.  If you wish to set an individual option to a particular
  value, you may specify it after the \fB\-mcpu\fR option, like
  \&\fB\-mcpu=970 \-mno\-altivec\fR.
  .Sp
! On AIX, the \fB\-maltivec\fR and \fB\-mpowerpc64\fR options are
  not enabled or disabled by the \fB\-mcpu\fR option at present because
! AIX does not have full support for these options.  You may still
! enable or disable them individually if you\*(Aqre sure it\*(Aqll work in your
  environment.
! .IP \fB\-mtune=\fR\fIcpu_type\fR 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR, but do not set the architecture type or register usage,
*************** values for \fIcpu_type\fR are used for \
*** 28599,28894 ****
  \&\fB\-mcpu\fR.  If both are specified, the code generated uses the
  architecture and registers set by \fB\-mcpu\fR, but the
  scheduling parameters set by \fB\-mtune\fR.
! .IP "\fB\-mcmodel=small\fR" 4
  .IX Item "-mcmodel=small"
! Generate PowerPC64 code for the small model: The \s-1TOC\s0 is limited to
  64k.
! .IP "\fB\-mcmodel=medium\fR" 4
  .IX Item "-mcmodel=medium"
! Generate PowerPC64 code for the medium model: The \s-1TOC\s0 and other static
  data may be up to a total of 4G in size.  This is the default for 64\-bit
  Linux.
! .IP "\fB\-mcmodel=large\fR" 4
  .IX Item "-mcmodel=large"
! Generate PowerPC64 code for the large model: The \s-1TOC\s0 may be up to 4G
  in size.  Other data and code is only limited by the 64\-bit address
  space.
! .IP "\fB\-maltivec\fR" 4
  .IX Item "-maltivec"
  .PD 0
! .IP "\fB\-mno\-altivec\fR" 4
  .IX Item "-mno-altivec"
  .PD
  Generate code that uses (does not use) AltiVec instructions, and also
! enable the use of built-in functions that allow more direct access to
  the AltiVec instruction set.  You may also need to set
! \&\fB\-mabi=altivec\fR to adjust the current \s-1ABI\s0 with AltiVec \s-1ABI\s0
  enhancements.
  .Sp
  When \fB\-maltivec\fR is used, the element order for AltiVec intrinsics
  such as \f(CW\*(C`vec_splat\*(C'\fR, \f(CW\*(C`vec_extract\*(C'\fR, and \f(CW\*(C`vec_insert\*(C'\fR 
  match array element order corresponding to the endianness of the
  target.  That is, element zero identifies the leftmost element in a
! vector register when targeting a big-endian platform, and identifies
  the rightmost element in a vector register when targeting a
! little-endian platform.
! .IP "\fB\-mvrsave\fR" 4
  .IX Item "-mvrsave"
  .PD 0
! .IP "\fB\-mno\-vrsave\fR" 4
  .IX Item "-mno-vrsave"
  .PD
! Generate \s-1VRSAVE\s0 instructions when generating AltiVec code.
! .IP "\fB\-msecure\-plt\fR" 4
  .IX Item "-msecure-plt"
  Generate code that allows \fBld\fR and \fBld.so\fR
  to build executables and shared
! libraries with non-executable \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR sections.
  This is a PowerPC
! 32\-bit \s-1SYSV ABI\s0 option.
! .IP "\fB\-mbss\-plt\fR" 4
  .IX Item "-mbss-plt"
! Generate code that uses a \s-1BSS\s0 \f(CW\*(C`.plt\*(C'\fR section that \fBld.so\fR
  fills in, and
  requires \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR
  sections that are both writable and executable.
! This is a PowerPC 32\-bit \s-1SYSV ABI\s0 option.
! .IP "\fB\-misel\fR" 4
  .IX Item "-misel"
  .PD 0
! .IP "\fB\-mno\-isel\fR" 4
  .IX Item "-mno-isel"
  .PD
! This switch enables or disables the generation of \s-1ISEL\s0 instructions.
! .IP "\fB\-mvsx\fR" 4
  .IX Item "-mvsx"
  .PD 0
! .IP "\fB\-mno\-vsx\fR" 4
  .IX Item "-mno-vsx"
  .PD
! Generate code that uses (does not use) vector/scalar (\s-1VSX\s0)
! instructions, and also enable the use of built-in functions that allow
! more direct access to the \s-1VSX\s0 instruction set.
! .IP "\fB\-mcrypto\fR" 4
  .IX Item "-mcrypto"
  .PD 0
! .IP "\fB\-mno\-crypto\fR" 4
  .IX Item "-mno-crypto"
  .PD
! Enable the use (disable) of the built-in functions that allow direct
  access to the cryptographic instructions that were added in version
! 2.07 of the PowerPC \s-1ISA.\s0
! .IP "\fB\-mhtm\fR" 4
  .IX Item "-mhtm"
  .PD 0
! .IP "\fB\-mno\-htm\fR" 4
  .IX Item "-mno-htm"
  .PD
! Enable (disable) the use of the built-in functions that allow direct
! access to the Hardware Transactional Memory (\s-1HTM\s0) instructions that
! were added in version 2.07 of the PowerPC \s-1ISA.\s0
! .IP "\fB\-mpower8\-fusion\fR" 4
  .IX Item "-mpower8-fusion"
  .PD 0
! .IP "\fB\-mno\-power8\-fusion\fR" 4
  .IX Item "-mno-power8-fusion"
  .PD
  Generate code that keeps (does not keeps) some integer operations
  adjacent so that the instructions can be fused together on power8 and
  later processors.
! .IP "\fB\-mpower8\-vector\fR" 4
  .IX Item "-mpower8-vector"
  .PD 0
! .IP "\fB\-mno\-power8\-vector\fR" 4
  .IX Item "-mno-power8-vector"
  .PD
  Generate code that uses (does not use) the vector and scalar
! instructions that were added in version 2.07 of the PowerPC \s-1ISA.\s0  Also
! enable the use of built-in functions that allow more direct access to
  the vector instructions.
! .IP "\fB\-mquad\-memory\fR" 4
  .IX Item "-mquad-memory"
  .PD 0
! .IP "\fB\-mno\-quad\-memory\fR" 4
  .IX Item "-mno-quad-memory"
  .PD
! Generate code that uses (does not use) the non-atomic quad word memory
  instructions.  The \fB\-mquad\-memory\fR option requires use of
  64\-bit mode.
! .IP "\fB\-mquad\-memory\-atomic\fR" 4
  .IX Item "-mquad-memory-atomic"
  .PD 0
! .IP "\fB\-mno\-quad\-memory\-atomic\fR" 4
  .IX Item "-mno-quad-memory-atomic"
  .PD
  Generate code that uses (does not use) the atomic quad word memory
  instructions.  The \fB\-mquad\-memory\-atomic\fR option requires use of
  64\-bit mode.
! .IP "\fB\-mfloat128\fR" 4
  .IX Item "-mfloat128"
  .PD 0
! .IP "\fB\-mno\-float128\fR" 4
  .IX Item "-mno-float128"
  .PD
! Enable/disable the \fI_\|_float128\fR keyword for \s-1IEEE\s0 128\-bit floating point
! and use either software emulation for \s-1IEEE\s0 128\-bit floating point or
  hardware instructions.
  .Sp
! The \s-1VSX\s0 instruction set (\fB\-mvsx\fR) must be enabled to use the \s-1IEEE\s0
! 128\-bit floating point support.  The \s-1IEEE\s0 128\-bit floating point is only
  supported on Linux.
  .Sp
  The default for \fB\-mfloat128\fR is enabled on PowerPC Linux
! systems using the \s-1VSX\s0 instruction set, and disabled on other systems.
  .Sp
! If you use the \s-1ISA 3.0\s0 instruction set (\fB\-mpower9\-vector\fR or
! \&\fB\-mcpu=power9\fR) on a 64\-bit system, the \s-1IEEE\s0 128\-bit floating
! point support will also enable the generation of \s-1ISA 3.0 IEEE\s0 128\-bit
  floating point instructions.  Otherwise, if you do not specify to
! generate \s-1ISA 3.0\s0 instructions or you are targeting a 32\-bit big endian
! system, \s-1IEEE\s0 128\-bit floating point will be done with software
  emulation.
! .IP "\fB\-mfloat128\-hardware\fR" 4
  .IX Item "-mfloat128-hardware"
  .PD 0
! .IP "\fB\-mno\-float128\-hardware\fR" 4
  .IX Item "-mno-float128-hardware"
  .PD
! Enable/disable using \s-1ISA 3.0\s0 hardware instructions to support the
  \&\fI_\|_float128\fR data type.
  .Sp
  The default for \fB\-mfloat128\-hardware\fR is enabled on PowerPC
! Linux systems using the \s-1ISA 3.0\s0 instruction set, and disabled on other
  systems.
! .IP "\fB\-m32\fR" 4
  .IX Item "-m32"
  .PD 0
! .IP "\fB\-m64\fR" 4
  .IX Item "-m64"
  .PD
! Generate code for 32\-bit or 64\-bit environments of Darwin and \s-1SVR4\s0
  targets (including GNU/Linux).  The 32\-bit environment sets int, long
  and pointer to 32 bits and generates code that runs on any PowerPC
  variant.  The 64\-bit environment sets int to 32 bits and long and
  pointer to 64 bits, and generates code for PowerPC64, as for
  \&\fB\-mpowerpc64\fR.
! .IP "\fB\-mfull\-toc\fR" 4
  .IX Item "-mfull-toc"
  .PD 0
! .IP "\fB\-mno\-fp\-in\-toc\fR" 4
  .IX Item "-mno-fp-in-toc"
! .IP "\fB\-mno\-sum\-in\-toc\fR" 4
  .IX Item "-mno-sum-in-toc"
! .IP "\fB\-mminimal\-toc\fR" 4
  .IX Item "-mminimal-toc"
  .PD
! Modify generation of the \s-1TOC\s0 (Table Of Contents), which is created for
  every executable file.  The \fB\-mfull\-toc\fR option is selected by
! default.  In that case, \s-1GCC\s0 allocates at least one \s-1TOC\s0 entry for
! each unique non-automatic variable reference in your program.  \s-1GCC\s0
! also places floating-point constants in the \s-1TOC.\s0  However, only
! 16,384 entries are available in the \s-1TOC.\s0
  .Sp
  If you receive a linker error message that saying you have overflowed
! the available \s-1TOC\s0 space, you can reduce the amount of \s-1TOC\s0 space used
  with the \fB\-mno\-fp\-in\-toc\fR and \fB\-mno\-sum\-in\-toc\fR options.
! \&\fB\-mno\-fp\-in\-toc\fR prevents \s-1GCC\s0 from putting floating-point
! constants in the \s-1TOC\s0 and \fB\-mno\-sum\-in\-toc\fR forces \s-1GCC\s0 to
  generate code to calculate the sum of an address and a constant at
! run time instead of putting that sum into the \s-1TOC.\s0  You may specify one
! or both of these options.  Each causes \s-1GCC\s0 to produce very slightly
! slower and larger code at the expense of conserving \s-1TOC\s0 space.
  .Sp
! If you still run out of space in the \s-1TOC\s0 even when you specify both of
  these options, specify \fB\-mminimal\-toc\fR instead.  This option causes
! \&\s-1GCC\s0 to make only one \s-1TOC\s0 entry for every file.  When you specify this
! option, \s-1GCC\s0 produces code that is slower and larger but which
! uses extremely little \s-1TOC\s0 space.  You may wish to use this option
! only on files that contain less frequently-executed code.
! .IP "\fB\-maix64\fR" 4
  .IX Item "-maix64"
  .PD 0
! .IP "\fB\-maix32\fR" 4
  .IX Item "-maix32"
  .PD
! Enable 64\-bit \s-1AIX ABI\s0 and calling convention: 64\-bit pointers, 64\-bit
  \&\f(CW\*(C`long\*(C'\fR type, and the infrastructure needed to support them.
  Specifying \fB\-maix64\fR implies \fB\-mpowerpc64\fR,
! while \fB\-maix32\fR disables the 64\-bit \s-1ABI\s0 and
! implies \fB\-mno\-powerpc64\fR.  \s-1GCC\s0 defaults to \fB\-maix32\fR.
! .IP "\fB\-mxl\-compat\fR" 4
  .IX Item "-mxl-compat"
  .PD 0
! .IP "\fB\-mno\-xl\-compat\fR" 4
  .IX Item "-mno-xl-compat"
  .PD
! Produce code that conforms more closely to \s-1IBM XL\s0 compiler semantics
! when using AIX-compatible \s-1ABI.\s0  Pass floating-point arguments to
! prototyped functions beyond the register save area (\s-1RSA\s0) on the stack
  in addition to argument FPRs.  Do not assume that most significant
  double in 128\-bit long double value is properly rounded when comparing
! values and converting to double.  Use \s-1XL\s0 symbol names for long double
  support routines.
  .Sp
! The \s-1AIX\s0 calling convention was extended but not initially documented to
  handle an obscure K&R C case of calling a function that takes the
! address of its arguments with fewer arguments than declared.  \s-1IBM XL\s0
! compilers access floating-point arguments that do not fit in the
! \&\s-1RSA\s0 from the stack when a subroutine is compiled without
! optimization.  Because always storing floating-point arguments on the
  stack is inefficient and rarely needed, this option is not enabled by
! default and only is necessary when calling subroutines compiled by \s-1IBM
! XL\s0 compilers without optimization.
! .IP "\fB\-mpe\fR" 4
  .IX Item "-mpe"
! Support \fI\s-1IBM RS/6000 SP\s0\fR \fIParallel Environment\fR (\s-1PE\s0).  Link an
  application written to use message passing with special startup code to
! enable the application to run.  The system must have \s-1PE\s0 installed in the
  standard location (\fI/usr/lpp/ppe.poe/\fR), or the \fIspecs\fR file
  must be overridden with the \fB\-specs=\fR option to specify the
  appropriate directory location.  The Parallel Environment does not
  support threads, so the \fB\-mpe\fR option and the \fB\-pthread\fR
  option are incompatible.
! .IP "\fB\-malign\-natural\fR" 4
  .IX Item "-malign-natural"
  .PD 0
! .IP "\fB\-malign\-power\fR" 4
  .IX Item "-malign-power"
  .PD
! On \s-1AIX,\s0 32\-bit Darwin, and 64\-bit PowerPC GNU/Linux, the option
! \&\fB\-malign\-natural\fR overrides the ABI-defined alignment of larger
! types, such as floating-point doubles, on their natural size-based boundary.
! The option \fB\-malign\-power\fR instructs \s-1GCC\s0 to follow the ABI-specified
! alignment rules.  \s-1GCC\s0 defaults to the standard alignment defined in the \s-1ABI.\s0
  .Sp
  On 64\-bit Darwin, natural alignment is the default, and \fB\-malign\-power\fR
  is not supported.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
! Generate code that does not use (uses) the floating-point register set.
! Software floating-point emulation is provided if you use the
! \&\fB\-msoft\-float\fR option, and pass the option to \s-1GCC\s0 when linking.
! .IP "\fB\-mmultiple\fR" 4
  .IX Item "-mmultiple"
  .PD 0
! .IP "\fB\-mno\-multiple\fR" 4
  .IX Item "-mno-multiple"
  .PD
  Generate code that uses (does not use) the load multiple word
  instructions and the store multiple word instructions.  These
! instructions are generated by default on \s-1POWER\s0 systems, and not
! generated on PowerPC systems.  Do not use \fB\-mmultiple\fR on little-endian
  PowerPC systems, since those instructions do not work when the
! processor is in little-endian mode.  The exceptions are \s-1PPC740\s0 and
! \&\s-1PPC750\s0 which permit these instructions in little-endian mode.
! .IP "\fB\-mupdate\fR" 4
  .IX Item "-mupdate"
  .PD 0
! .IP "\fB\-mno\-update\fR" 4
  .IX Item "-mno-update"
  .PD
  Generate code that uses (does not use) the load or store instructions
--- 28530,28825 ----
  \&\fB\-mcpu\fR.  If both are specified, the code generated uses the
  architecture and registers set by \fB\-mcpu\fR, but the
  scheduling parameters set by \fB\-mtune\fR.
! .IP \fB\-mcmodel=small\fR 4
  .IX Item "-mcmodel=small"
! Generate PowerPC64 code for the small model: The TOC is limited to
  64k.
! .IP \fB\-mcmodel=medium\fR 4
  .IX Item "-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.  This is the default for 64\-bit
  Linux.
! .IP \fB\-mcmodel=large\fR 4
  .IX Item "-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.
! .IP \fB\-maltivec\fR 4
  .IX Item "-maltivec"
  .PD 0
! .IP \fB\-mno\-altivec\fR 4
  .IX Item "-mno-altivec"
  .PD
  Generate code that uses (does not use) AltiVec instructions, and also
! enable the use of built\-in functions that allow more direct access to
  the AltiVec instruction set.  You may also need to set
! \&\fB\-mabi=altivec\fR to adjust the current ABI with AltiVec ABI
  enhancements.
  .Sp
  When \fB\-maltivec\fR is used, the element order for AltiVec intrinsics
  such as \f(CW\*(C`vec_splat\*(C'\fR, \f(CW\*(C`vec_extract\*(C'\fR, and \f(CW\*(C`vec_insert\*(C'\fR 
  match array element order corresponding to the endianness of the
  target.  That is, element zero identifies the leftmost element in a
! vector register when targeting a big\-endian platform, and identifies
  the rightmost element in a vector register when targeting a
! little\-endian platform.
! .IP \fB\-mvrsave\fR 4
  .IX Item "-mvrsave"
  .PD 0
! .IP \fB\-mno\-vrsave\fR 4
  .IX Item "-mno-vrsave"
  .PD
! Generate VRSAVE instructions when generating AltiVec code.
! .IP \fB\-msecure\-plt\fR 4
  .IX Item "-msecure-plt"
  Generate code that allows \fBld\fR and \fBld.so\fR
  to build executables and shared
! libraries with non\-executable \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR sections.
  This is a PowerPC
! 32\-bit SYSV ABI option.
! .IP \fB\-mbss\-plt\fR 4
  .IX Item "-mbss-plt"
! Generate code that uses a BSS \f(CW\*(C`.plt\*(C'\fR section that \fBld.so\fR
  fills in, and
  requires \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR
  sections that are both writable and executable.
! This is a PowerPC 32\-bit SYSV ABI option.
! .IP \fB\-misel\fR 4
  .IX Item "-misel"
  .PD 0
! .IP \fB\-mno\-isel\fR 4
  .IX Item "-mno-isel"
  .PD
! This switch enables or disables the generation of ISEL instructions.
! .IP \fB\-mvsx\fR 4
  .IX Item "-mvsx"
  .PD 0
! .IP \fB\-mno\-vsx\fR 4
  .IX Item "-mno-vsx"
  .PD
! Generate code that uses (does not use) vector/scalar (VSX)
! instructions, and also enable the use of built\-in functions that allow
! more direct access to the VSX instruction set.
! .IP \fB\-mcrypto\fR 4
  .IX Item "-mcrypto"
  .PD 0
! .IP \fB\-mno\-crypto\fR 4
  .IX Item "-mno-crypto"
  .PD
! Enable the use (disable) of the built\-in functions that allow direct
  access to the cryptographic instructions that were added in version
! 2.07 of the PowerPC ISA.
! .IP \fB\-mhtm\fR 4
  .IX Item "-mhtm"
  .PD 0
! .IP \fB\-mno\-htm\fR 4
  .IX Item "-mno-htm"
  .PD
! Enable (disable) the use of the built\-in functions that allow direct
! access to the Hardware Transactional Memory (HTM) instructions that
! were added in version 2.07 of the PowerPC ISA.
! .IP \fB\-mpower8\-fusion\fR 4
  .IX Item "-mpower8-fusion"
  .PD 0
! .IP \fB\-mno\-power8\-fusion\fR 4
  .IX Item "-mno-power8-fusion"
  .PD
  Generate code that keeps (does not keeps) some integer operations
  adjacent so that the instructions can be fused together on power8 and
  later processors.
! .IP \fB\-mpower8\-vector\fR 4
  .IX Item "-mpower8-vector"
  .PD 0
! .IP \fB\-mno\-power8\-vector\fR 4
  .IX Item "-mno-power8-vector"
  .PD
  Generate code that uses (does not use) the vector and scalar
! instructions that were added in version 2.07 of the PowerPC ISA.  Also
! enable the use of built\-in functions that allow more direct access to
  the vector instructions.
! .IP \fB\-mquad\-memory\fR 4
  .IX Item "-mquad-memory"
  .PD 0
! .IP \fB\-mno\-quad\-memory\fR 4
  .IX Item "-mno-quad-memory"
  .PD
! Generate code that uses (does not use) the non\-atomic quad word memory
  instructions.  The \fB\-mquad\-memory\fR option requires use of
  64\-bit mode.
! .IP \fB\-mquad\-memory\-atomic\fR 4
  .IX Item "-mquad-memory-atomic"
  .PD 0
! .IP \fB\-mno\-quad\-memory\-atomic\fR 4
  .IX Item "-mno-quad-memory-atomic"
  .PD
  Generate code that uses (does not use) the atomic quad word memory
  instructions.  The \fB\-mquad\-memory\-atomic\fR option requires use of
  64\-bit mode.
! .IP \fB\-mfloat128\fR 4
  .IX Item "-mfloat128"
  .PD 0
! .IP \fB\-mno\-float128\fR 4
  .IX Item "-mno-float128"
  .PD
! Enable/disable the \fI_\|_float128\fR keyword for IEEE 128\-bit floating point
! and use either software emulation for IEEE 128\-bit floating point or
  hardware instructions.
  .Sp
! The VSX instruction set (\fB\-mvsx\fR) must be enabled to use the IEEE
! 128\-bit floating point support.  The IEEE 128\-bit floating point is only
  supported on Linux.
  .Sp
  The default for \fB\-mfloat128\fR is enabled on PowerPC Linux
! systems using the VSX instruction set, and disabled on other systems.
  .Sp
! If you use the ISA 3.0 instruction set (\fB\-mpower9\-vector\fR or
! \&\fB\-mcpu=power9\fR) on a 64\-bit system, the IEEE 128\-bit floating
! point support will also enable the generation of ISA 3.0 IEEE 128\-bit
  floating point instructions.  Otherwise, if you do not specify to
! generate ISA 3.0 instructions or you are targeting a 32\-bit big endian
! system, IEEE 128\-bit floating point will be done with software
  emulation.
! .IP \fB\-mfloat128\-hardware\fR 4
  .IX Item "-mfloat128-hardware"
  .PD 0
! .IP \fB\-mno\-float128\-hardware\fR 4
  .IX Item "-mno-float128-hardware"
  .PD
! Enable/disable using ISA 3.0 hardware instructions to support the
  \&\fI_\|_float128\fR data type.
  .Sp
  The default for \fB\-mfloat128\-hardware\fR is enabled on PowerPC
! Linux systems using the ISA 3.0 instruction set, and disabled on other
  systems.
! .IP \fB\-m32\fR 4
  .IX Item "-m32"
  .PD 0
! .IP \fB\-m64\fR 4
  .IX Item "-m64"
  .PD
! Generate code for 32\-bit or 64\-bit environments of Darwin and 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
  \&\fB\-mpowerpc64\fR.
! .IP \fB\-mfull\-toc\fR 4
  .IX Item "-mfull-toc"
  .PD 0
! .IP \fB\-mno\-fp\-in\-toc\fR 4
  .IX Item "-mno-fp-in-toc"
! .IP \fB\-mno\-sum\-in\-toc\fR 4
  .IX Item "-mno-sum-in-toc"
! .IP \fB\-mminimal\-toc\fR 4
  .IX Item "-mminimal-toc"
  .PD
! Modify generation of the TOC (Table Of Contents), which is created for
  every executable file.  The \fB\-mfull\-toc\fR option is selected by
! default.  In that case, GCC allocates at least one TOC entry for
! each unique non\-automatic variable reference in your program.  GCC
! also places floating\-point constants in the TOC.  However, only
! 16,384 entries are available in the TOC.
  .Sp
  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 \fB\-mno\-fp\-in\-toc\fR and \fB\-mno\-sum\-in\-toc\fR options.
! \&\fB\-mno\-fp\-in\-toc\fR prevents GCC from putting floating\-point
! constants in the TOC and \fB\-mno\-sum\-in\-toc\fR 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.
  .Sp
! If you still run out of space in the TOC even when you specify both of
  these options, specify \fB\-mminimal\-toc\fR instead.  This option causes
! GCC to make only one TOC entry for every file.  When you specify this
! option, GCC produces code that is slower and larger but which
! uses extremely little TOC space.  You may wish to use this option
! only on files that contain less frequently\-executed code.
! .IP \fB\-maix64\fR 4
  .IX Item "-maix64"
  .PD 0
! .IP \fB\-maix32\fR 4
  .IX Item "-maix32"
  .PD
! Enable 64\-bit AIX ABI and calling convention: 64\-bit pointers, 64\-bit
  \&\f(CW\*(C`long\*(C'\fR type, and the infrastructure needed to support them.
  Specifying \fB\-maix64\fR implies \fB\-mpowerpc64\fR,
! while \fB\-maix32\fR disables the 64\-bit ABI and
! implies \fB\-mno\-powerpc64\fR.  GCC defaults to \fB\-maix32\fR.
! .IP \fB\-mxl\-compat\fR 4
  .IX Item "-mxl-compat"
  .PD 0
! .IP \fB\-mno\-xl\-compat\fR 4
  .IX Item "-mno-xl-compat"
  .PD
! Produce code that conforms more closely to 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.
  .Sp
! The AIX calling convention was extended but not initially documented to
  handle an obscure K&R C case of calling a function that takes the
! address of its arguments with fewer arguments than declared.  IBM XL
! compilers access floating\-point arguments that do not fit in the
! RSA from the stack when a subroutine is compiled without
! optimization.  Because always storing floating\-point arguments on the
  stack is inefficient and rarely needed, this option is not enabled by
! default and only is necessary when calling subroutines compiled by IBM
! XL compilers without optimization.
! .IP \fB\-mpe\fR 4
  .IX Item "-mpe"
! Support \fIIBM RS/6000 SP\fR \fIParallel Environment\fR (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 (\fI/usr/lpp/ppe.poe/\fR), or the \fIspecs\fR file
  must be overridden with the \fB\-specs=\fR option to specify the
  appropriate directory location.  The Parallel Environment does not
  support threads, so the \fB\-mpe\fR option and the \fB\-pthread\fR
  option are incompatible.
! .IP \fB\-malign\-natural\fR 4
  .IX Item "-malign-natural"
  .PD 0
! .IP \fB\-malign\-power\fR 4
  .IX Item "-malign-power"
  .PD
! On AIX, 32\-bit Darwin, and 64\-bit PowerPC GNU/Linux, the option
! \&\fB\-malign\-natural\fR overrides the ABI\-defined alignment of larger
! types, such as floating\-point doubles, on their natural size\-based boundary.
! The option \fB\-malign\-power\fR instructs GCC to follow the ABI\-specified
! alignment rules.  GCC defaults to the standard alignment defined in the ABI.
  .Sp
  On 64\-bit Darwin, natural alignment is the default, and \fB\-malign\-power\fR
  is not supported.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
! Generate code that does not use (uses) the floating\-point register set.
! Software floating\-point emulation is provided if you use the
! \&\fB\-msoft\-float\fR option, and pass the option to GCC when linking.
! .IP \fB\-mmultiple\fR 4
  .IX Item "-mmultiple"
  .PD 0
! .IP \fB\-mno\-multiple\fR 4
  .IX Item "-mno-multiple"
  .PD
  Generate code that uses (does not use) the load multiple word
  instructions and the store multiple word instructions.  These
! instructions are generated by default on POWER systems, and not
! generated on PowerPC systems.  Do not use \fB\-mmultiple\fR on little\-endian
  PowerPC systems, since those instructions do not work when the
! processor is in little\-endian mode.  The exceptions are PPC740 and
! PPC750 which permit these instructions in little\-endian mode.
! .IP \fB\-mupdate\fR 4
  .IX Item "-mupdate"
  .PD 0
! .IP \fB\-mno\-update\fR 4
  .IX Item "-mno-update"
  .PD
  Generate code that uses (does not use) the load or store instructions
*************** location.  These instructions are genera
*** 28898,28907 ****
  stack pointer is updated and the address of the previous frame is
  stored, which means code that walks the stack frame across interrupts or
  signals may get corrupted data.
! .IP "\fB\-mavoid\-indexed\-addresses\fR" 4
  .IX Item "-mavoid-indexed-addresses"
  .PD 0
! .IP "\fB\-mno\-avoid\-indexed\-addresses\fR" 4
  .IX Item "-mno-avoid-indexed-addresses"
  .PD
  Generate code that tries to avoid (not avoid) the use of indexed load
--- 28829,28838 ----
  stack pointer is updated and the address of the previous frame is
  stored, which means code that walks the stack frame across interrupts or
  signals may get corrupted data.
! .IP \fB\-mavoid\-indexed\-addresses\fR 4
  .IX Item "-mavoid-indexed-addresses"
  .PD 0
! .IP \fB\-mno\-avoid\-indexed\-addresses\fR 4
  .IX Item "-mno-avoid-indexed-addresses"
  .PD
  Generate code that tries to avoid (not avoid) the use of indexed load
*************** or store instructions. These instruction
*** 28909,28972 ****
  penalty on Power6 processors in certain situations, such as when
  stepping through large arrays that cross a 16M boundary.  This option
  is enabled by default when targeting Power6 and disabled otherwise.
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating-point multiply and
  accumulate instructions.  These instructions are generated by default
! if hardware floating point is used.  The machine-dependent
! \&\fB\-mfused\-madd\fR option is now mapped to the machine-independent
  \&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
  mapped to \fB\-ffp\-contract=off\fR.
! .IP "\fB\-mmulhw\fR" 4
  .IX Item "-mmulhw"
  .PD 0
! .IP "\fB\-mno\-mulhw\fR" 4
  .IX Item "-mno-mulhw"
  .PD
! Generate code that uses (does not use) the half-word multiply and
! multiply-accumulate instructions on the \s-1IBM 405, 440, 464\s0 and 476 processors.
  These instructions are generated by default when targeting those
  processors.
! .IP "\fB\-mdlmzb\fR" 4
  .IX Item "-mdlmzb"
  .PD 0
! .IP "\fB\-mno\-dlmzb\fR" 4
  .IX Item "-mno-dlmzb"
  .PD
! Generate code that uses (does not use) the string-search \fBdlmzb\fR
! instruction on the \s-1IBM 405, 440, 464\s0 and 476 processors.  This instruction is
  generated by default when targeting those processors.
! .IP "\fB\-mno\-bit\-align\fR" 4
  .IX Item "-mno-bit-align"
  .PD 0
! .IP "\fB\-mbit\-align\fR" 4
  .IX Item "-mbit-align"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) force structures
! and unions that contain bit-fields to be aligned to the base type of the
! bit-field.
  .Sp
  For example, by default a structure containing nothing but 8
! \&\f(CW\*(C`unsigned\*(C'\fR bit-fields of length 1 is aligned to a 4\-byte
  boundary and has a size of 4 bytes.  By using \fB\-mno\-bit\-align\fR,
  the structure is aligned to a 1\-byte boundary and is 1 byte in
  size.
! .IP "\fB\-mno\-strict\-align\fR" 4
  .IX Item "-mno-strict-align"
  .PD 0
! .IP "\fB\-mstrict\-align\fR" 4
  .IX Item "-mstrict-align"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) assume that
  unaligned memory references are handled by the system.
! .IP "\fB\-mrelocatable\fR" 4
  .IX Item "-mrelocatable"
  .PD 0
! .IP "\fB\-mno\-relocatable\fR" 4
  .IX Item "-mno-relocatable"
  .PD
  Generate code that allows (does not allow) a static executable to be
--- 28840,28903 ----
  penalty on Power6 processors in certain situations, such as when
  stepping through large arrays that cross a 16M boundary.  This option
  is enabled by default when targeting Power6 and disabled otherwise.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating\-point multiply and
  accumulate instructions.  These instructions are generated by default
! if hardware floating point is used.  The machine\-dependent
! \&\fB\-mfused\-madd\fR option is now mapped to the machine\-independent
  \&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
  mapped to \fB\-ffp\-contract=off\fR.
! .IP \fB\-mmulhw\fR 4
  .IX Item "-mmulhw"
  .PD 0
! .IP \fB\-mno\-mulhw\fR 4
  .IX Item "-mno-mulhw"
  .PD
! Generate code that uses (does not use) the half\-word multiply and
! multiply\-accumulate instructions on the IBM 405, 440, 464 and 476 processors.
  These instructions are generated by default when targeting those
  processors.
! .IP \fB\-mdlmzb\fR 4
  .IX Item "-mdlmzb"
  .PD 0
! .IP \fB\-mno\-dlmzb\fR 4
  .IX Item "-mno-dlmzb"
  .PD
! Generate code that uses (does not use) the string\-search \fBdlmzb\fR
! instruction on the IBM 405, 440, 464 and 476 processors.  This instruction is
  generated by default when targeting those processors.
! .IP \fB\-mno\-bit\-align\fR 4
  .IX Item "-mno-bit-align"
  .PD 0
! .IP \fB\-mbit\-align\fR 4
  .IX Item "-mbit-align"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) force structures
! and unions that contain bit\-fields to be aligned to the base type of the
! bit\-field.
  .Sp
  For example, by default a structure containing nothing but 8
! \&\f(CW\*(C`unsigned\*(C'\fR bit\-fields of length 1 is aligned to a 4\-byte
  boundary and has a size of 4 bytes.  By using \fB\-mno\-bit\-align\fR,
  the structure is aligned to a 1\-byte boundary and is 1 byte in
  size.
! .IP \fB\-mno\-strict\-align\fR 4
  .IX Item "-mno-strict-align"
  .PD 0
! .IP \fB\-mstrict\-align\fR 4
  .IX Item "-mstrict-align"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) assume that
  unaligned memory references are handled by the system.
! .IP \fB\-mrelocatable\fR 4
  .IX Item "-mrelocatable"
  .PD 0
! .IP \fB\-mno\-relocatable\fR 4
  .IX Item "-mno-relocatable"
  .PD
  Generate code that allows (does not allow) a static executable to be
*************** a table of 32\-bit addresses generated b
*** 28977,28986 ****
  work, all objects linked together must be compiled with
  \&\fB\-mrelocatable\fR or \fB\-mrelocatable\-lib\fR.
  \&\fB\-mrelocatable\fR code aligns the stack to an 8\-byte boundary.
! .IP "\fB\-mrelocatable\-lib\fR" 4
  .IX Item "-mrelocatable-lib"
  .PD 0
! .IP "\fB\-mno\-relocatable\-lib\fR" 4
  .IX Item "-mno-relocatable-lib"
  .PD
  Like \fB\-mrelocatable\fR, \fB\-mrelocatable\-lib\fR generates a
--- 28908,28917 ----
  work, all objects linked together must be compiled with
  \&\fB\-mrelocatable\fR or \fB\-mrelocatable\-lib\fR.
  \&\fB\-mrelocatable\fR code aligns the stack to an 8\-byte boundary.
! .IP \fB\-mrelocatable\-lib\fR 4
  .IX Item "-mrelocatable-lib"
  .PD 0
! .IP \fB\-mno\-relocatable\-lib\fR 4
  .IX Item "-mno-relocatable-lib"
  .PD
  Like \fB\-mrelocatable\fR, \fB\-mrelocatable\-lib\fR generates a
*************** run time, but \fB\-mrelocatable\-lib\fR
*** 28989,29244 ****
  alignment of \fB\-mrelocatable\fR.  Objects compiled with
  \&\fB\-mrelocatable\-lib\fR may be linked with objects compiled with
  any combination of the \fB\-mrelocatable\fR options.
! .IP "\fB\-mno\-toc\fR" 4
  .IX Item "-mno-toc"
  .PD 0
! .IP "\fB\-mtoc\fR" 4
  .IX Item "-mtoc"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) assume that
  register 2 contains a pointer to a global area pointing to the addresses
  used in the program.
! .IP "\fB\-mlittle\fR" 4
  .IX Item "-mlittle"
  .PD 0
! .IP "\fB\-mlittle\-endian\fR" 4
  .IX Item "-mlittle-endian"
  .PD
  On System V.4 and embedded PowerPC systems compile code for the
! processor in little-endian mode.  The \fB\-mlittle\-endian\fR option is
  the same as \fB\-mlittle\fR.
! .IP "\fB\-mbig\fR" 4
  .IX Item "-mbig"
  .PD 0
! .IP "\fB\-mbig\-endian\fR" 4
  .IX Item "-mbig-endian"
  .PD
  On System V.4 and embedded PowerPC systems compile code for the
! processor in big-endian mode.  The \fB\-mbig\-endian\fR option is
  the same as \fB\-mbig\fR.
! .IP "\fB\-mdynamic\-no\-pic\fR" 4
  .IX Item "-mdynamic-no-pic"
! On Darwin and Mac \s-1OS X\s0 systems, compile code so that it is not
  relocatable, but that its external references are relocatable.  The
  resulting code is suitable for applications, but not shared
  libraries.
! .IP "\fB\-msingle\-pic\-base\fR" 4
  .IX Item "-msingle-pic-base"
! Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
  loading it in the prologue for each function.  The runtime system is
  responsible for initializing this register with an appropriate value
  before execution begins.
! .IP "\fB\-mprioritize\-restricted\-insns=\fR\fIpriority\fR" 4
  .IX Item "-mprioritize-restricted-insns=priority"
  This option controls the priority that is assigned to
! dispatch-slot restricted instructions during the second scheduling
  pass.  The argument \fIpriority\fR takes the value \fB0\fR, \fB1\fR,
! or \fB2\fR to assign no, highest, or second-highest (respectively) 
! priority to dispatch-slot restricted
  instructions.
! .IP "\fB\-msched\-costly\-dep=\fR\fIdependence_type\fR" 4
  .IX Item "-msched-costly-dep=dependence_type"
  This option controls which dependences are considered costly
  by the target during instruction scheduling.  The argument
  \&\fIdependence_type\fR takes one of the following values:
  .RS 4
! .IP "\fBno\fR" 4
  .IX Item "no"
  No dependence is costly.
! .IP "\fBall\fR" 4
  .IX Item "all"
  All dependences are costly.
! .IP "\fBtrue_store_to_load\fR" 4
  .IX Item "true_store_to_load"
  A true dependence from store to load is costly.
! .IP "\fBstore_to_load\fR" 4
  .IX Item "store_to_load"
  Any dependence from store to load is costly.
! .IP "\fInumber\fR" 4
  .IX Item "number"
  Any dependence for which the latency is greater than or equal to 
  \&\fInumber\fR is costly.
  .RE
  .RS 4
  .RE
! .IP "\fB\-minsert\-sched\-nops=\fR\fIscheme\fR" 4
  .IX Item "-minsert-sched-nops=scheme"
! This option controls which \s-1NOP\s0 insertion scheme is used during
  the second scheduling pass.  The argument \fIscheme\fR takes one of the
  following values:
  .RS 4
! .IP "\fBno\fR" 4
  .IX Item "no"
! Don't insert NOPs.
! .IP "\fBpad\fR" 4
  .IX Item "pad"
  Pad with NOPs any dispatch group that has vacant issue slots,
! according to the scheduler's grouping.
! .IP "\fBregroup_exact\fR" 4
  .IX Item "regroup_exact"
  Insert NOPs to force costly dependent insns into
  separate groups.  Insert exactly as many NOPs as needed to force an insn
  to a new group, according to the estimated processor grouping.
! .IP "\fInumber\fR" 4
  .IX Item "number"
  Insert NOPs to force costly dependent insns into
  separate groups.  Insert \fInumber\fR NOPs to force an insn to a new group.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mcall\-sysv\fR" 4
  .IX Item "-mcall-sysv"
  On System V.4 and embedded PowerPC systems compile code using calling
  conventions that adhere to the March 1995 draft of the System V
  Application Binary Interface, PowerPC processor supplement.  This is the
! default unless you configured \s-1GCC\s0 using \fBpowerpc\-*\-eabiaix\fR.
! .IP "\fB\-mcall\-sysv\-eabi\fR" 4
  .IX Item "-mcall-sysv-eabi"
  .PD 0
! .IP "\fB\-mcall\-eabi\fR" 4
  .IX Item "-mcall-eabi"
  .PD
  Specify both \fB\-mcall\-sysv\fR and \fB\-meabi\fR options.
! .IP "\fB\-mcall\-sysv\-noeabi\fR" 4
  .IX Item "-mcall-sysv-noeabi"
  Specify both \fB\-mcall\-sysv\fR and \fB\-mno\-eabi\fR options.
! .IP "\fB\-mcall\-aixdesc\fR" 4
  .IX Item "-mcall-aixdesc"
! On System V.4 and embedded PowerPC systems compile code for the \s-1AIX\s0
  operating system.
! .IP "\fB\-mcall\-linux\fR" 4
  .IX Item "-mcall-linux"
  On System V.4 and embedded PowerPC systems compile code for the
! Linux-based \s-1GNU\s0 system.
! .IP "\fB\-mcall\-freebsd\fR" 4
  .IX Item "-mcall-freebsd"
  On System V.4 and embedded PowerPC systems compile code for the
  FreeBSD operating system.
! .IP "\fB\-mcall\-netbsd\fR" 4
  .IX Item "-mcall-netbsd"
  On System V.4 and embedded PowerPC systems compile code for the
  NetBSD operating system.
! .IP "\fB\-mcall\-openbsd\fR" 4
  .IX Item "-mcall-openbsd"
  On System V.4 and embedded PowerPC systems compile code for the
  OpenBSD operating system.
! .IP "\fB\-mtraceback=\fR\fItraceback_type\fR" 4
  .IX Item "-mtraceback=traceback_type"
  Select the type of traceback table. Valid values for \fItraceback_type\fR
  are \fBfull\fR, \fBpart\fR, and \fBno\fR.
! .IP "\fB\-maix\-struct\-return\fR" 4
  .IX Item "-maix-struct-return"
! Return all structures in memory (as specified by the \s-1AIX ABI\s0).
! .IP "\fB\-msvr4\-struct\-return\fR" 4
  .IX Item "-msvr4-struct-return"
  Return structures smaller than 8 bytes in registers (as specified by the
! \&\s-1SVR4 ABI\s0).
! .IP "\fB\-mabi=\fR\fIabi-type\fR" 4
  .IX Item "-mabi=abi-type"
! Extend the current \s-1ABI\s0 with a particular extension, or remove such extension.
! Valid values are: \fBaltivec\fR, \fBno-altivec\fR,
  \&\fBibmlongdouble\fR, \fBieeelongdouble\fR,
  \&\fBelfv1\fR, \fBelfv2\fR,
! and for \s-1AIX:\s0 \fBvec-extabi\fR, \fBvec-default\fR.
! .IP "\fB\-mabi=ibmlongdouble\fR" 4
  .IX Item "-mabi=ibmlongdouble"
! Change the current \s-1ABI\s0 to use \s-1IBM\s0 extended-precision long double.
! This is not likely to work if your system defaults to using \s-1IEEE\s0
! extended-precision long double.  If you change the long double type
! from \s-1IEEE\s0 extended-precision, the compiler will issue a warning unless
  you use the \fB\-Wno\-psabi\fR option.  Requires \fB\-mlong\-double\-128\fR
  to be enabled.
! .IP "\fB\-mabi=ieeelongdouble\fR" 4
  .IX Item "-mabi=ieeelongdouble"
! Change the current \s-1ABI\s0 to use \s-1IEEE\s0 extended-precision long double.
! This is not likely to work if your system defaults to using \s-1IBM\s0
! extended-precision long double.  If you change the long double type
! from \s-1IBM\s0 extended-precision, the compiler will issue a warning unless
  you use the \fB\-Wno\-psabi\fR option.  Requires \fB\-mlong\-double\-128\fR
  to be enabled.
! .IP "\fB\-mabi=elfv1\fR" 4
  .IX Item "-mabi=elfv1"
! Change the current \s-1ABI\s0 to use the ELFv1 \s-1ABI.\s0
! This is the default \s-1ABI\s0 for big-endian PowerPC 64\-bit Linux.
! Overriding the default \s-1ABI\s0 requires special system support and is
  likely to fail in spectacular ways.
! .IP "\fB\-mabi=elfv2\fR" 4
  .IX Item "-mabi=elfv2"
! Change the current \s-1ABI\s0 to use the ELFv2 \s-1ABI.\s0
! This is the default \s-1ABI\s0 for little-endian PowerPC 64\-bit Linux.
! Overriding the default \s-1ABI\s0 requires special system support and is
  likely to fail in spectacular ways.
! .IP "\fB\-mgnu\-attribute\fR" 4
  .IX Item "-mgnu-attribute"
  .PD 0
! .IP "\fB\-mno\-gnu\-attribute\fR" 4
  .IX Item "-mno-gnu-attribute"
  .PD
  Emit .gnu_attribute assembly directives to set tag/value pairs in a
! \&.gnu.attributes section that specify \s-1ABI\s0 variations in function
  parameters or return values.
! .IP "\fB\-mprototype\fR" 4
  .IX Item "-mprototype"
  .PD 0
! .IP "\fB\-mno\-prototype\fR" 4
  .IX Item "-mno-prototype"
  .PD
  On System V.4 and embedded PowerPC systems assume that all calls to
  variable argument functions are properly prototyped.  Otherwise, the
! compiler must insert an instruction before every non-prototyped call to
  set or clear bit 6 of the condition code register (\f(CW\*(C`CR\*(C'\fR) to
! indicate whether floating-point values are passed in the floating-point
  registers in case the function takes variable arguments.  With
  \&\fB\-mprototype\fR, only calls to prototyped variable argument functions
  set or clear the bit.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIsim\-crt0.o\fR and that the standard C libraries are \fIlibsim.a\fR and
  \&\fIlibc.a\fR.  This is the default for \fBpowerpc\-*\-eabisim\fR
  configurations.
! .IP "\fB\-mmvme\fR" 4
  .IX Item "-mmvme"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibmvme.a\fR and
  \&\fIlibc.a\fR.
! .IP "\fB\-mads\fR" 4
  .IX Item "-mads"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibads.a\fR and
  \&\fIlibc.a\fR.
! .IP "\fB\-myellowknife\fR" 4
  .IX Item "-myellowknife"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibyk.a\fR and
  \&\fIlibc.a\fR.
! .IP "\fB\-mvxworks\fR" 4
  .IX Item "-mvxworks"
  On System V.4 and embedded PowerPC systems, specify that you are
  compiling for a VxWorks system.
! .IP "\fB\-memb\fR" 4
  .IX Item "-memb"
! On embedded PowerPC systems, set the \f(CW\*(C`PPC_EMB\*(C'\fR bit in the \s-1ELF\s0 flags
  header to indicate that \fBeabi\fR extended relocations are used.
! .IP "\fB\-meabi\fR" 4
  .IX Item "-meabi"
  .PD 0
! .IP "\fB\-mno\-eabi\fR" 4
  .IX Item "-mno-eabi"
  .PD
  On System V.4 and embedded PowerPC systems do (do not) adhere to the
! Embedded Applications Binary Interface (\s-1EABI\s0), which is a set of
  modifications to the System V.4 specifications.  Selecting \fB\-meabi\fR
  means that the stack is aligned to an 8\-byte boundary, a function
! \&\f(CW\*(C`_\|_eabi\*(C'\fR is called from \f(CW\*(C`main\*(C'\fR to set up the \s-1EABI\s0
  environment, and the \fB\-msdata\fR option can use both \f(CW\*(C`r2\*(C'\fR and
  \&\f(CW\*(C`r13\*(C'\fR to point to two separate small data areas.  Selecting
  \&\fB\-mno\-eabi\fR means that the stack is aligned to a 16\-byte boundary,
! no \s-1EABI\s0 initialization function is called from \f(CW\*(C`main\*(C'\fR, and the
  \&\fB\-msdata\fR option only uses \f(CW\*(C`r13\*(C'\fR to point to a single
  small data area.  The \fB\-meabi\fR option is on by default if you
! configured \s-1GCC\s0 using one of the \fBpowerpc*\-*\-eabi*\fR options.
! .IP "\fB\-msdata=eabi\fR" 4
  .IX Item "-msdata=eabi"
  On System V.4 and embedded PowerPC systems, put small initialized
  \&\f(CW\*(C`const\*(C'\fR global and static data in the \f(CW\*(C`.sdata2\*(C'\fR section, which
--- 28920,29175 ----
  alignment of \fB\-mrelocatable\fR.  Objects compiled with
  \&\fB\-mrelocatable\-lib\fR may be linked with objects compiled with
  any combination of the \fB\-mrelocatable\fR options.
! .IP \fB\-mno\-toc\fR 4
  .IX Item "-mno-toc"
  .PD 0
! .IP \fB\-mtoc\fR 4
  .IX Item "-mtoc"
  .PD
  On System V.4 and embedded PowerPC systems do not (do) assume that
  register 2 contains a pointer to a global area pointing to the addresses
  used in the program.
! .IP \fB\-mlittle\fR 4
  .IX Item "-mlittle"
  .PD 0
! .IP \fB\-mlittle\-endian\fR 4
  .IX Item "-mlittle-endian"
  .PD
  On System V.4 and embedded PowerPC systems compile code for the
! processor in little\-endian mode.  The \fB\-mlittle\-endian\fR option is
  the same as \fB\-mlittle\fR.
! .IP \fB\-mbig\fR 4
  .IX Item "-mbig"
  .PD 0
! .IP \fB\-mbig\-endian\fR 4
  .IX Item "-mbig-endian"
  .PD
  On System V.4 and embedded PowerPC systems compile code for the
! processor in big\-endian mode.  The \fB\-mbig\-endian\fR option is
  the same as \fB\-mbig\fR.
! .IP \fB\-mdynamic\-no\-pic\fR 4
  .IX Item "-mdynamic-no-pic"
! On Darwin and Mac 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.
! .IP \fB\-msingle\-pic\-base\fR 4
  .IX Item "-msingle-pic-base"
! Treat the register used for PIC addressing as read\-only, rather than
  loading it in the prologue for each function.  The runtime system is
  responsible for initializing this register with an appropriate value
  before execution begins.
! .IP \fB\-mprioritize\-restricted\-insns=\fR\fIpriority\fR 4
  .IX Item "-mprioritize-restricted-insns=priority"
  This option controls the priority that is assigned to
! dispatch\-slot restricted instructions during the second scheduling
  pass.  The argument \fIpriority\fR takes the value \fB0\fR, \fB1\fR,
! or \fB2\fR to assign no, highest, or second\-highest (respectively) 
! priority to dispatch\-slot restricted
  instructions.
! .IP \fB\-msched\-costly\-dep=\fR\fIdependence_type\fR 4
  .IX Item "-msched-costly-dep=dependence_type"
  This option controls which dependences are considered costly
  by the target during instruction scheduling.  The argument
  \&\fIdependence_type\fR takes one of the following values:
  .RS 4
! .IP \fBno\fR 4
  .IX Item "no"
  No dependence is costly.
! .IP \fBall\fR 4
  .IX Item "all"
  All dependences are costly.
! .IP \fBtrue_store_to_load\fR 4
  .IX Item "true_store_to_load"
  A true dependence from store to load is costly.
! .IP \fBstore_to_load\fR 4
  .IX Item "store_to_load"
  Any dependence from store to load is costly.
! .IP \fInumber\fR 4
  .IX Item "number"
  Any dependence for which the latency is greater than or equal to 
  \&\fInumber\fR is costly.
  .RE
  .RS 4
  .RE
! .IP \fB\-minsert\-sched\-nops=\fR\fIscheme\fR 4
  .IX Item "-minsert-sched-nops=scheme"
! This option controls which NOP insertion scheme is used during
  the second scheduling pass.  The argument \fIscheme\fR takes one of the
  following values:
  .RS 4
! .IP \fBno\fR 4
  .IX Item "no"
! Don\*(Aqt insert NOPs.
! .IP \fBpad\fR 4
  .IX Item "pad"
  Pad with NOPs any dispatch group that has vacant issue slots,
! according to the scheduler\*(Aqs grouping.
! .IP \fBregroup_exact\fR 4
  .IX Item "regroup_exact"
  Insert NOPs to force costly dependent insns into
  separate groups.  Insert exactly as many NOPs as needed to force an insn
  to a new group, according to the estimated processor grouping.
! .IP \fInumber\fR 4
  .IX Item "number"
  Insert NOPs to force costly dependent insns into
  separate groups.  Insert \fInumber\fR NOPs to force an insn to a new group.
  .RE
  .RS 4
  .RE
! .IP \fB\-mcall\-sysv\fR 4
  .IX Item "-mcall-sysv"
  On System V.4 and embedded PowerPC systems compile code using calling
  conventions that adhere to the March 1995 draft of the System V
  Application Binary Interface, PowerPC processor supplement.  This is the
! default unless you configured GCC using \fBpowerpc\-*\-eabiaix\fR.
! .IP \fB\-mcall\-sysv\-eabi\fR 4
  .IX Item "-mcall-sysv-eabi"
  .PD 0
! .IP \fB\-mcall\-eabi\fR 4
  .IX Item "-mcall-eabi"
  .PD
  Specify both \fB\-mcall\-sysv\fR and \fB\-meabi\fR options.
! .IP \fB\-mcall\-sysv\-noeabi\fR 4
  .IX Item "-mcall-sysv-noeabi"
  Specify both \fB\-mcall\-sysv\fR and \fB\-mno\-eabi\fR options.
! .IP \fB\-mcall\-aixdesc\fR 4
  .IX Item "-mcall-aixdesc"
! On System V.4 and embedded PowerPC systems compile code for the AIX
  operating system.
! .IP \fB\-mcall\-linux\fR 4
  .IX Item "-mcall-linux"
  On System V.4 and embedded PowerPC systems compile code for the
! Linux\-based GNU system.
! .IP \fB\-mcall\-freebsd\fR 4
  .IX Item "-mcall-freebsd"
  On System V.4 and embedded PowerPC systems compile code for the
  FreeBSD operating system.
! .IP \fB\-mcall\-netbsd\fR 4
  .IX Item "-mcall-netbsd"
  On System V.4 and embedded PowerPC systems compile code for the
  NetBSD operating system.
! .IP \fB\-mcall\-openbsd\fR 4
  .IX Item "-mcall-openbsd"
  On System V.4 and embedded PowerPC systems compile code for the
  OpenBSD operating system.
! .IP \fB\-mtraceback=\fR\fItraceback_type\fR 4
  .IX Item "-mtraceback=traceback_type"
  Select the type of traceback table. Valid values for \fItraceback_type\fR
  are \fBfull\fR, \fBpart\fR, and \fBno\fR.
! .IP \fB\-maix\-struct\-return\fR 4
  .IX Item "-maix-struct-return"
! Return all structures in memory (as specified by the AIX ABI).
! .IP \fB\-msvr4\-struct\-return\fR 4
  .IX Item "-msvr4-struct-return"
  Return structures smaller than 8 bytes in registers (as specified by the
! SVR4 ABI).
! .IP \fB\-mabi=\fR\fIabi\-type\fR 4
  .IX Item "-mabi=abi-type"
! Extend the current ABI with a particular extension, or remove such extension.
! Valid values are: \fBaltivec\fR, \fBno\-altivec\fR,
  \&\fBibmlongdouble\fR, \fBieeelongdouble\fR,
  \&\fBelfv1\fR, \fBelfv2\fR,
! and for AIX: \fBvec\-extabi\fR, \fBvec\-default\fR.
! .IP \fB\-mabi=ibmlongdouble\fR 4
  .IX Item "-mabi=ibmlongdouble"
! Change the current ABI to use IBM extended\-precision long double.
! This is not likely to work if your system defaults to using IEEE
! extended\-precision long double.  If you change the long double type
! from IEEE extended\-precision, the compiler will issue a warning unless
  you use the \fB\-Wno\-psabi\fR option.  Requires \fB\-mlong\-double\-128\fR
  to be enabled.
! .IP \fB\-mabi=ieeelongdouble\fR 4
  .IX Item "-mabi=ieeelongdouble"
! Change the current ABI to use IEEE extended\-precision long double.
! This is not likely to work if your system defaults to using IBM
! extended\-precision long double.  If you change the long double type
! from IBM extended\-precision, the compiler will issue a warning unless
  you use the \fB\-Wno\-psabi\fR option.  Requires \fB\-mlong\-double\-128\fR
  to be enabled.
! .IP \fB\-mabi=elfv1\fR 4
  .IX Item "-mabi=elfv1"
! Change the current ABI to use the ELFv1 ABI.
! This is the default ABI for big\-endian PowerPC 64\-bit Linux.
! Overriding the default ABI requires special system support and is
  likely to fail in spectacular ways.
! .IP \fB\-mabi=elfv2\fR 4
  .IX Item "-mabi=elfv2"
! Change the current ABI to use the ELFv2 ABI.
! This is the default ABI for little\-endian PowerPC 64\-bit Linux.
! Overriding the default ABI requires special system support and is
  likely to fail in spectacular ways.
! .IP \fB\-mgnu\-attribute\fR 4
  .IX Item "-mgnu-attribute"
  .PD 0
! .IP \fB\-mno\-gnu\-attribute\fR 4
  .IX Item "-mno-gnu-attribute"
  .PD
  Emit .gnu_attribute assembly directives to set tag/value pairs in a
! \&.gnu.attributes section that specify ABI variations in function
  parameters or return values.
! .IP \fB\-mprototype\fR 4
  .IX Item "-mprototype"
  .PD 0
! .IP \fB\-mno\-prototype\fR 4
  .IX Item "-mno-prototype"
  .PD
  On System V.4 and embedded PowerPC systems assume that all calls to
  variable argument functions are properly prototyped.  Otherwise, the
! compiler must insert an instruction before every non\-prototyped call to
  set or clear bit 6 of the condition code register (\f(CW\*(C`CR\*(C'\fR) to
! indicate whether floating\-point values are passed in the floating\-point
  registers in case the function takes variable arguments.  With
  \&\fB\-mprototype\fR, only calls to prototyped variable argument functions
  set or clear the bit.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIsim\-crt0.o\fR and that the standard C libraries are \fIlibsim.a\fR and
  \&\fIlibc.a\fR.  This is the default for \fBpowerpc\-*\-eabisim\fR
  configurations.
! .IP \fB\-mmvme\fR 4
  .IX Item "-mmvme"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibmvme.a\fR and
  \&\fIlibc.a\fR.
! .IP \fB\-mads\fR 4
  .IX Item "-mads"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibads.a\fR and
  \&\fIlibc.a\fR.
! .IP \fB\-myellowknife\fR 4
  .IX Item "-myellowknife"
  On embedded PowerPC systems, assume that the startup module is called
  \&\fIcrt0.o\fR and the standard C libraries are \fIlibyk.a\fR and
  \&\fIlibc.a\fR.
! .IP \fB\-mvxworks\fR 4
  .IX Item "-mvxworks"
  On System V.4 and embedded PowerPC systems, specify that you are
  compiling for a VxWorks system.
! .IP \fB\-memb\fR 4
  .IX Item "-memb"
! On embedded PowerPC systems, set the \f(CW\*(C`PPC_EMB\*(C'\fR bit in the ELF flags
  header to indicate that \fBeabi\fR extended relocations are used.
! .IP \fB\-meabi\fR 4
  .IX Item "-meabi"
  .PD 0
! .IP \fB\-mno\-eabi\fR 4
  .IX Item "-mno-eabi"
  .PD
  On System V.4 and embedded PowerPC systems do (do not) adhere to the
! Embedded Applications Binary Interface (EABI), which is a set of
  modifications to the System V.4 specifications.  Selecting \fB\-meabi\fR
  means that the stack is aligned to an 8\-byte boundary, a function
! \&\f(CW\*(C`_\|_eabi\*(C'\fR is called from \f(CW\*(C`main\*(C'\fR to set up the EABI
  environment, and the \fB\-msdata\fR option can use both \f(CW\*(C`r2\*(C'\fR and
  \&\f(CW\*(C`r13\*(C'\fR to point to two separate small data areas.  Selecting
  \&\fB\-mno\-eabi\fR means that the stack is aligned to a 16\-byte boundary,
! no EABI initialization function is called from \f(CW\*(C`main\*(C'\fR, and the
  \&\fB\-msdata\fR option only uses \f(CW\*(C`r13\*(C'\fR to point to a single
  small data area.  The \fB\-meabi\fR option is on by default if you
! configured GCC using one of the \fBpowerpc*\-*\-eabi*\fR options.
! .IP \fB\-msdata=eabi\fR 4
  .IX Item "-msdata=eabi"
  On System V.4 and embedded PowerPC systems, put small initialized
  \&\f(CW\*(C`const\*(C'\fR global and static data in the \f(CW\*(C`.sdata2\*(C'\fR section, which
*************** global and static data in the \f(CW\*(C`
*** 29249,29255 ****
  the \f(CW\*(C`.sdata\*(C'\fR section.  The \fB\-msdata=eabi\fR option is
  incompatible with the \fB\-mrelocatable\fR option.  The
  \&\fB\-msdata=eabi\fR option also sets the \fB\-memb\fR option.
! .IP "\fB\-msdata=sysv\fR" 4
  .IX Item "-msdata=sysv"
  On System V.4 and embedded PowerPC systems, put small global and static
  data in the \f(CW\*(C`.sdata\*(C'\fR section, which is pointed to by register
--- 29180,29186 ----
  the \f(CW\*(C`.sdata\*(C'\fR section.  The \fB\-msdata=eabi\fR option is
  incompatible with the \fB\-mrelocatable\fR option.  The
  \&\fB\-msdata=eabi\fR option also sets the \fB\-memb\fR option.
! .IP \fB\-msdata=sysv\fR 4
  .IX Item "-msdata=sysv"
  On System V.4 and embedded PowerPC systems, put small global and static
  data in the \f(CW\*(C`.sdata\*(C'\fR section, which is pointed to by register
*************** data in the \f(CW\*(C`.sdata\*(C'\fR sec
*** 29257,29312 ****
  \&\f(CW\*(C`.sbss\*(C'\fR section, which is adjacent to the \f(CW\*(C`.sdata\*(C'\fR section.
  The \fB\-msdata=sysv\fR option is incompatible with the
  \&\fB\-mrelocatable\fR option.
! .IP "\fB\-msdata=default\fR" 4
  .IX Item "-msdata=default"
  .PD 0
! .IP "\fB\-msdata\fR" 4
  .IX Item "-msdata"
  .PD
  On System V.4 and embedded PowerPC systems, if \fB\-meabi\fR is used,
  compile code the same as \fB\-msdata=eabi\fR, otherwise compile code the
  same as \fB\-msdata=sysv\fR.
! .IP "\fB\-msdata=data\fR" 4
  .IX Item "-msdata=data"
  On System V.4 and embedded PowerPC systems, put small global
  data in the \f(CW\*(C`.sdata\*(C'\fR section.  Put small uninitialized global
  data in the \f(CW\*(C`.sbss\*(C'\fR section.  Do not use register \f(CW\*(C`r13\*(C'\fR
  to address small data however.  This is the default behavior unless
  other \fB\-msdata\fR options are used.
! .IP "\fB\-msdata=none\fR" 4
  .IX Item "-msdata=none"
  .PD 0
! .IP "\fB\-mno\-sdata\fR" 4
  .IX Item "-mno-sdata"
  .PD
  On embedded PowerPC systems, put all initialized global and static data
  in the \f(CW\*(C`.data\*(C'\fR section, and all uninitialized data in the
  \&\f(CW\*(C`.bss\*(C'\fR section.
! .IP "\fB\-mreadonly\-in\-sdata\fR" 4
  .IX Item "-mreadonly-in-sdata"
! Put read-only objects in the \f(CW\*(C`.sdata\*(C'\fR section as well.  This is the
  default.
! .IP "\fB\-mblock\-move\-inline\-limit=\fR\fInum\fR" 4
  .IX Item "-mblock-move-inline-limit=num"
  Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure
  copies) less than or equal to \fInum\fR bytes.  The minimum value for
  \&\fInum\fR is 32 bytes on 32\-bit targets and 64 bytes on 64\-bit
! targets.  The default value is target-specific.
! .IP "\fB\-mblock\-compare\-inline\-limit=\fR\fInum\fR" 4
  .IX Item "-mblock-compare-inline-limit=num"
! Generate non-looping inline code for all block compares (such as calls
  to \f(CW\*(C`memcmp\*(C'\fR or structure compares) less than or equal to \fInum\fR
! bytes. If \fInum\fR is 0, all inline expansion (non-loop and loop) of
! block compare is disabled. The default value is target-specific.
! .IP "\fB\-mblock\-compare\-inline\-loop\-limit=\fR\fInum\fR" 4
  .IX Item "-mblock-compare-inline-loop-limit=num"
  Generate an inline expansion using loop code for all block compares that
  are less than or equal to \fInum\fR bytes, but greater than the limit
! for non-loop inline block compare expansion. If the block length is not
  constant, at most \fInum\fR bytes will be compared before \f(CW\*(C`memcmp\*(C'\fR
  is called to compare the remainder of the block. The default value is
! target-specific.
! .IP "\fB\-mstring\-compare\-inline\-limit=\fR\fInum\fR" 4
  .IX Item "-mstring-compare-inline-limit=num"
  Compare at most \fInum\fR string bytes with inline code.
  If the difference or end of string is not found at the
--- 29188,29243 ----
  \&\f(CW\*(C`.sbss\*(C'\fR section, which is adjacent to the \f(CW\*(C`.sdata\*(C'\fR section.
  The \fB\-msdata=sysv\fR option is incompatible with the
  \&\fB\-mrelocatable\fR option.
! .IP \fB\-msdata=default\fR 4
  .IX Item "-msdata=default"
  .PD 0
! .IP \fB\-msdata\fR 4
  .IX Item "-msdata"
  .PD
  On System V.4 and embedded PowerPC systems, if \fB\-meabi\fR is used,
  compile code the same as \fB\-msdata=eabi\fR, otherwise compile code the
  same as \fB\-msdata=sysv\fR.
! .IP \fB\-msdata=data\fR 4
  .IX Item "-msdata=data"
  On System V.4 and embedded PowerPC systems, put small global
  data in the \f(CW\*(C`.sdata\*(C'\fR section.  Put small uninitialized global
  data in the \f(CW\*(C`.sbss\*(C'\fR section.  Do not use register \f(CW\*(C`r13\*(C'\fR
  to address small data however.  This is the default behavior unless
  other \fB\-msdata\fR options are used.
! .IP \fB\-msdata=none\fR 4
  .IX Item "-msdata=none"
  .PD 0
! .IP \fB\-mno\-sdata\fR 4
  .IX Item "-mno-sdata"
  .PD
  On embedded PowerPC systems, put all initialized global and static data
  in the \f(CW\*(C`.data\*(C'\fR section, and all uninitialized data in the
  \&\f(CW\*(C`.bss\*(C'\fR section.
! .IP \fB\-mreadonly\-in\-sdata\fR 4
  .IX Item "-mreadonly-in-sdata"
! Put read\-only objects in the \f(CW\*(C`.sdata\*(C'\fR section as well.  This is the
  default.
! .IP \fB\-mblock\-move\-inline\-limit=\fR\fInum\fR 4
  .IX Item "-mblock-move-inline-limit=num"
  Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure
  copies) less than or equal to \fInum\fR bytes.  The minimum value for
  \&\fInum\fR is 32 bytes on 32\-bit targets and 64 bytes on 64\-bit
! targets.  The default value is target\-specific.
! .IP \fB\-mblock\-compare\-inline\-limit=\fR\fInum\fR 4
  .IX Item "-mblock-compare-inline-limit=num"
! Generate non\-looping inline code for all block compares (such as calls
  to \f(CW\*(C`memcmp\*(C'\fR or structure compares) less than or equal to \fInum\fR
! bytes. If \fInum\fR is 0, all inline expansion (non\-loop and loop) of
! block compare is disabled. The default value is target\-specific.
! .IP \fB\-mblock\-compare\-inline\-loop\-limit=\fR\fInum\fR 4
  .IX Item "-mblock-compare-inline-loop-limit=num"
  Generate an inline expansion using loop code for all block compares that
  are less than or equal to \fInum\fR bytes, but greater than the limit
! for non\-loop inline block compare expansion. If the block length is not
  constant, at most \fInum\fR bytes will be compared before \f(CW\*(C`memcmp\*(C'\fR
  is called to compare the remainder of the block. The default value is
! target\-specific.
! .IP \fB\-mstring\-compare\-inline\-limit=\fR\fInum\fR 4
  .IX Item "-mstring-compare-inline-limit=num"
  Compare at most \fInum\fR string bytes with inline code.
  If the difference or end of string is not found at the
*************** take care of the rest of the comparison.
*** 29315,29336 ****
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  On embedded PowerPC systems, put global and static items less than or
! equal to \fInum\fR bytes into the small data or \s-1BSS\s0 sections instead of
! the normal data or \s-1BSS\s0 section.  By default, \fInum\fR is 8.  The
  \&\fB\-G\fR \fInum\fR switch is also passed to the linker.
  All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
! .IP "\fB\-mregnames\fR" 4
  .IX Item "-mregnames"
  .PD 0
! .IP "\fB\-mno\-regnames\fR" 4
  .IX Item "-mno-regnames"
  .PD
  On System V.4 and embedded PowerPC systems do (do not) emit register
  names in the assembly language output using symbolic forms.
! .IP "\fB\-mlongcall\fR" 4
  .IX Item "-mlongcall"
  .PD 0
! .IP "\fB\-mno\-longcall\fR" 4
  .IX Item "-mno-longcall"
  .PD
  By default assume that all calls are far away so that a longer and more
--- 29246,29267 ----
  .IP "\fB\-G\fR \fInum\fR" 4
  .IX Item "-G num"
  On embedded PowerPC systems, put global and static items less than or
! equal to \fInum\fR bytes into the small data or BSS sections instead of
! the normal data or BSS section.  By default, \fInum\fR is 8.  The
  \&\fB\-G\fR \fInum\fR switch is also passed to the linker.
  All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
! .IP \fB\-mregnames\fR 4
  .IX Item "-mregnames"
  .PD 0
! .IP \fB\-mno\-regnames\fR 4
  .IX Item "-mno-regnames"
  .PD
  On System V.4 and embedded PowerPC systems do (do not) emit register
  names in the assembly language output using symbolic forms.
! .IP \fB\-mlongcall\fR 4
  .IX Item "-mlongcall"
  .PD 0
! .IP \fB\-mno\-longcall\fR 4
  .IX Item "-mno-longcall"
  .PD
  By default assume that all calls are far away so that a longer and more
*************** expensive calling sequence is required.
*** 29338,29480 ****
  farther than 32 megabytes (33,554,432 bytes) from the current location.
  A short call is generated if the compiler knows
  the call cannot be that far away.  This setting can be overridden by
! the \f(CW\*(C`shortcall\*(C'\fR function attribute, or by \f(CW\*(C`#pragma
! longcall(0)\*(C'\fR.
  .Sp
! Some linkers are capable of detecting out-of-range calls and generating
  glue code on the fly.  On these systems, long calls are unnecessary and
! generate slower code.  As of this writing, the \s-1AIX\s0 linker can do this,
! as can the \s-1GNU\s0 linker for PowerPC/64.  It is planned to add this feature
! to the \s-1GNU\s0 linker for 32\-bit PowerPC systems as well.
  .Sp
! On PowerPC64 ELFv2 and 32\-bit PowerPC systems with newer \s-1GNU\s0 linkers,
! \&\s-1GCC\s0 can generate long calls using an inline \s-1PLT\s0 call sequence (see
  \&\fB\-mpltseq\fR).  PowerPC with \fB\-mbss\-plt\fR and PowerPC64
! ELFv1 (big-endian) do not support inline \s-1PLT\s0 calls.
  .Sp
  On Darwin/PPC systems, \f(CW\*(C`#pragma longcall\*(C'\fR generates \f(CW\*(C`jbsr
  callee, L42\*(C'\fR, plus a \fIbranch island\fR (glue code).  The two target
  addresses represent the callee and the branch island.  The
  Darwin/PPC linker prefers the first address and generates a \f(CW\*(C`bl
! callee\*(C'\fR if the \s-1PPC\s0 \f(CW\*(C`bl\*(C'\fR instruction reaches the callee directly;
  otherwise, the linker generates \f(CW\*(C`bl L42\*(C'\fR to call the branch
  island.  The branch island is appended to the body of the
  calling function; it computes the full 32\-bit address of the callee
  and jumps to it.
  .Sp
! On Mach-O (Darwin) systems, this option directs the compiler emit to
  the glue for every direct call, and the Darwin linker decides whether
  to use or discard it.
  .Sp
! In the future, \s-1GCC\s0 may ignore all longcall specifications
  when the linker is known to generate glue.
! .IP "\fB\-mpltseq\fR" 4
  .IX Item "-mpltseq"
  .PD 0
! .IP "\fB\-mno\-pltseq\fR" 4
  .IX Item "-mno-pltseq"
  .PD
  Implement (do not implement) \-fno\-plt and long calls using an inline
! \&\s-1PLT\s0 call sequence that supports lazy linking and long calls to
! functions in dlopen'd shared libraries.  Inline \s-1PLT\s0 calls are only
! supported on PowerPC64 ELFv2 and 32\-bit PowerPC systems with newer \s-1GNU\s0
  linkers, and are enabled by default if the support is detected when
! configuring \s-1GCC,\s0 and, in the case of 32\-bit PowerPC, if \s-1GCC\s0 is
  configured with \fB\-\-enable\-secureplt\fR.  \fB\-mpltseq\fR code
  and \fB\-mbss\-plt\fR 32\-bit PowerPC relocatable objects may not be
  linked together.
! .IP "\fB\-mtls\-markers\fR" 4
  .IX Item "-mtls-markers"
  .PD 0
! .IP "\fB\-mno\-tls\-markers\fR" 4
  .IX Item "-mno-tls-markers"
  .PD
  Mark (do not mark) calls to \f(CW\*(C`_\|_tls_get_addr\*(C'\fR with a relocation
  specifying the function argument.  The relocation allows the linker to
  reliably associate function call with argument setup instructions for
! \&\s-1TLS\s0 optimization, which in turn allows \s-1GCC\s0 to better schedule the
  sequence.
! .IP "\fB\-mrecip\fR" 4
  .IX Item "-mrecip"
  .PD 0
! .IP "\fB\-mno\-recip\fR" 4
  .IX Item "-mno-recip"
  .PD
  This option enables use of the reciprocal estimate and
  reciprocal square root estimate instructions with additional
! Newton-Raphson steps to increase precision instead of doing a divide or
! square root and divide for floating-point arguments.  You should use
  the \fB\-ffast\-math\fR option when using \fB\-mrecip\fR (or at
  least \fB\-funsafe\-math\-optimizations\fR,
  \&\fB\-ffinite\-math\-only\fR, \fB\-freciprocal\-math\fR and
  \&\fB\-fno\-trapping\-math\fR).  Note that while the throughput of the
! sequence is generally higher than the throughput of the non-reciprocal
  instruction, the precision of the sequence can be decreased by up to 2
  ulp (i.e. the inverse of 1.0 equals 0.99999994) for reciprocal square
  roots.
! .IP "\fB\-mrecip=\fR\fIopt\fR" 4
  .IX Item "-mrecip=opt"
  This option controls which reciprocal estimate instructions
! may be used.  \fIopt\fR is a comma-separated list of options, which may
  be preceded by a \f(CW\*(C`!\*(C'\fR to invert the option:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
  Enable all estimate instructions.
! .IP "\fBdefault\fR" 4
  .IX Item "default"
  Enable the default instructions, equivalent to \fB\-mrecip\fR.
! .IP "\fBnone\fR" 4
  .IX Item "none"
  Disable all estimate instructions, equivalent to \fB\-mno\-recip\fR.
! .IP "\fBdiv\fR" 4
  .IX Item "div"
  Enable the reciprocal approximation instructions for both 
  single and double precision.
! .IP "\fBdivf\fR" 4
  .IX Item "divf"
! Enable the single-precision reciprocal approximation instructions.
! .IP "\fBdivd\fR" 4
  .IX Item "divd"
! Enable the double-precision reciprocal approximation instructions.
! .IP "\fBrsqrt\fR" 4
  .IX Item "rsqrt"
  Enable the reciprocal square root approximation instructions for both
  single and double precision.
! .IP "\fBrsqrtf\fR" 4
  .IX Item "rsqrtf"
! Enable the single-precision reciprocal square root approximation instructions.
! .IP "\fBrsqrtd\fR" 4
  .IX Item "rsqrtd"
! Enable the double-precision reciprocal square root approximation instructions.
  .RE
  .RS 4
  .Sp
  So, for example, \fB\-mrecip=all,!rsqrtd\fR enables
  all of the reciprocal estimate instructions, except for the
  \&\f(CW\*(C`FRSQRTE\*(C'\fR, \f(CW\*(C`XSRSQRTEDP\*(C'\fR, and \f(CW\*(C`XVRSQRTEDP\*(C'\fR instructions
! which handle the double-precision reciprocal square root calculations.
  .RE
! .IP "\fB\-mrecip\-precision\fR" 4
  .IX Item "-mrecip-precision"
  .PD 0
! .IP "\fB\-mno\-recip\-precision\fR" 4
  .IX Item "-mno-recip-precision"
  .PD
  Assume (do not assume) that the reciprocal estimate instructions
! provide higher-precision estimates than is mandated by the PowerPC
! \&\s-1ABI.\s0  Selecting \fB\-mcpu=power6\fR, \fB\-mcpu=power7\fR or
  \&\fB\-mcpu=power8\fR automatically selects \fB\-mrecip\-precision\fR.
! The double-precision square root estimate instructions are not generated by
! default on low-precision machines, since they do not provide an
  estimate that converges after three steps.
! .IP "\fB\-mveclibabi=\fR\fItype\fR" 4
  .IX Item "-mveclibabi=type"
! Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
  external library.  The only type supported at present is \fBmass\fR,
! which specifies to use \s-1IBM\s0's Mathematical Acceleration Subsystem
! (\s-1MASS\s0) libraries for vectorizing intrinsics using external libraries.
! \&\s-1GCC\s0 currently emits calls to \f(CW\*(C`acosd2\*(C'\fR, \f(CW\*(C`acosf4\*(C'\fR,
  \&\f(CW\*(C`acoshd2\*(C'\fR, \f(CW\*(C`acoshf4\*(C'\fR, \f(CW\*(C`asind2\*(C'\fR, \f(CW\*(C`asinf4\*(C'\fR,
  \&\f(CW\*(C`asinhd2\*(C'\fR, \f(CW\*(C`asinhf4\*(C'\fR, \f(CW\*(C`atan2d2\*(C'\fR, \f(CW\*(C`atan2f4\*(C'\fR,
  \&\f(CW\*(C`atand2\*(C'\fR, \f(CW\*(C`atanf4\*(C'\fR, \f(CW\*(C`atanhd2\*(C'\fR, \f(CW\*(C`atanhf4\*(C'\fR,
--- 29269,29411 ----
  farther than 32 megabytes (33,554,432 bytes) from the current location.
  A short call is generated if the compiler knows
  the call cannot be that far away.  This setting can be overridden by
! the \f(CW\*(C`shortcall\*(C'\fR function attribute, or by \f(CW#pragma
! longcall(0)\fR.
  .Sp
! Some linkers are capable of detecting out\-of\-range calls and generating
  glue code on the fly.  On these systems, long calls are unnecessary and
! generate slower code.  As of this writing, the 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.
  .Sp
! On PowerPC64 ELFv2 and 32\-bit PowerPC systems with newer GNU linkers,
! GCC can generate long calls using an inline PLT call sequence (see
  \&\fB\-mpltseq\fR).  PowerPC with \fB\-mbss\-plt\fR and PowerPC64
! ELFv1 (big\-endian) do not support inline PLT calls.
  .Sp
  On Darwin/PPC systems, \f(CW\*(C`#pragma longcall\*(C'\fR generates \f(CW\*(C`jbsr
  callee, L42\*(C'\fR, plus a \fIbranch island\fR (glue code).  The two target
  addresses represent the callee and the branch island.  The
  Darwin/PPC linker prefers the first address and generates a \f(CW\*(C`bl
! callee\*(C'\fR if the PPC \f(CW\*(C`bl\*(C'\fR instruction reaches the callee directly;
  otherwise, the linker generates \f(CW\*(C`bl L42\*(C'\fR to call the branch
  island.  The branch island is appended to the body of the
  calling function; it computes the full 32\-bit address of the callee
  and jumps to it.
  .Sp
! On Mach\-O (Darwin) systems, this option directs the compiler emit to
  the glue for every direct call, and the Darwin linker decides whether
  to use or discard it.
  .Sp
! In the future, GCC may ignore all longcall specifications
  when the linker is known to generate glue.
! .IP \fB\-mpltseq\fR 4
  .IX Item "-mpltseq"
  .PD 0
! .IP \fB\-mno\-pltseq\fR 4
  .IX Item "-mno-pltseq"
  .PD
  Implement (do not implement) \-fno\-plt and long calls using an inline
! PLT call sequence that supports lazy linking and long calls to
! functions in dlopen\*(Aqd shared libraries.  Inline PLT calls are only
! supported on PowerPC64 ELFv2 and 32\-bit PowerPC systems with newer GNU
  linkers, and are enabled by default if the support is detected when
! configuring GCC, and, in the case of 32\-bit PowerPC, if GCC is
  configured with \fB\-\-enable\-secureplt\fR.  \fB\-mpltseq\fR code
  and \fB\-mbss\-plt\fR 32\-bit PowerPC relocatable objects may not be
  linked together.
! .IP \fB\-mtls\-markers\fR 4
  .IX Item "-mtls-markers"
  .PD 0
! .IP \fB\-mno\-tls\-markers\fR 4
  .IX Item "-mno-tls-markers"
  .PD
  Mark (do not mark) calls to \f(CW\*(C`_\|_tls_get_addr\*(C'\fR with a relocation
  specifying the function argument.  The relocation allows the linker to
  reliably associate function call with argument setup instructions for
! TLS optimization, which in turn allows GCC to better schedule the
  sequence.
! .IP \fB\-mrecip\fR 4
  .IX Item "-mrecip"
  .PD 0
! .IP \fB\-mno\-recip\fR 4
  .IX Item "-mno-recip"
  .PD
  This option enables use of the reciprocal estimate and
  reciprocal square root estimate instructions with additional
! Newton\-Raphson steps to increase precision instead of doing a divide or
! square root and divide for floating\-point arguments.  You should use
  the \fB\-ffast\-math\fR option when using \fB\-mrecip\fR (or at
  least \fB\-funsafe\-math\-optimizations\fR,
  \&\fB\-ffinite\-math\-only\fR, \fB\-freciprocal\-math\fR and
  \&\fB\-fno\-trapping\-math\fR).  Note that while the throughput of the
! sequence is generally higher than the throughput of the non\-reciprocal
  instruction, the precision of the sequence can be decreased by up to 2
  ulp (i.e. the inverse of 1.0 equals 0.99999994) for reciprocal square
  roots.
! .IP \fB\-mrecip=\fR\fIopt\fR 4
  .IX Item "-mrecip=opt"
  This option controls which reciprocal estimate instructions
! may be used.  \fIopt\fR is a comma\-separated list of options, which may
  be preceded by a \f(CW\*(C`!\*(C'\fR to invert the option:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
  Enable all estimate instructions.
! .IP \fBdefault\fR 4
  .IX Item "default"
  Enable the default instructions, equivalent to \fB\-mrecip\fR.
! .IP \fBnone\fR 4
  .IX Item "none"
  Disable all estimate instructions, equivalent to \fB\-mno\-recip\fR.
! .IP \fBdiv\fR 4
  .IX Item "div"
  Enable the reciprocal approximation instructions for both 
  single and double precision.
! .IP \fBdivf\fR 4
  .IX Item "divf"
! Enable the single\-precision reciprocal approximation instructions.
! .IP \fBdivd\fR 4
  .IX Item "divd"
! Enable the double\-precision reciprocal approximation instructions.
! .IP \fBrsqrt\fR 4
  .IX Item "rsqrt"
  Enable the reciprocal square root approximation instructions for both
  single and double precision.
! .IP \fBrsqrtf\fR 4
  .IX Item "rsqrtf"
! Enable the single\-precision reciprocal square root approximation instructions.
! .IP \fBrsqrtd\fR 4
  .IX Item "rsqrtd"
! Enable the double\-precision reciprocal square root approximation instructions.
  .RE
  .RS 4
  .Sp
  So, for example, \fB\-mrecip=all,!rsqrtd\fR enables
  all of the reciprocal estimate instructions, except for the
  \&\f(CW\*(C`FRSQRTE\*(C'\fR, \f(CW\*(C`XSRSQRTEDP\*(C'\fR, and \f(CW\*(C`XVRSQRTEDP\*(C'\fR instructions
! which handle the double\-precision reciprocal square root calculations.
  .RE
! .IP \fB\-mrecip\-precision\fR 4
  .IX Item "-mrecip-precision"
  .PD 0
! .IP \fB\-mno\-recip\-precision\fR 4
  .IX Item "-mno-recip-precision"
  .PD
  Assume (do not assume) that the reciprocal estimate instructions
! provide higher\-precision estimates than is mandated by the PowerPC
! ABI.  Selecting \fB\-mcpu=power6\fR, \fB\-mcpu=power7\fR or
  \&\fB\-mcpu=power8\fR automatically selects \fB\-mrecip\-precision\fR.
! The double\-precision square root estimate instructions are not generated by
! default on low\-precision machines, since they do not provide an
  estimate that converges after three steps.
! .IP \fB\-mveclibabi=\fR\fItype\fR 4
  .IX Item "-mveclibabi=type"
! Specifies the ABI type to use for vectorizing intrinsics using an
  external library.  The only type supported at present is \fBmass\fR,
! which specifies to use IBM\*(Aqs Mathematical Acceleration Subsystem
! (MASS) libraries for vectorizing intrinsics using external libraries.
! GCC currently emits calls to \f(CW\*(C`acosd2\*(C'\fR, \f(CW\*(C`acosf4\*(C'\fR,
  \&\f(CW\*(C`acoshd2\*(C'\fR, \f(CW\*(C`acoshf4\*(C'\fR, \f(CW\*(C`asind2\*(C'\fR, \f(CW\*(C`asinf4\*(C'\fR,
  \&\f(CW\*(C`asinhd2\*(C'\fR, \f(CW\*(C`asinhf4\*(C'\fR, \f(CW\*(C`atan2d2\*(C'\fR, \f(CW\*(C`atan2f4\*(C'\fR,
  \&\f(CW\*(C`atand2\*(C'\fR, \f(CW\*(C`atanf4\*(C'\fR, \f(CW\*(C`atanhd2\*(C'\fR, \f(CW\*(C`atanhf4\*(C'\fR,
*************** which specifies to use \s-1IBM\s0's Math
*** 29489,29619 ****
  \&\f(CW\*(C`sinhf4\*(C'\fR, \f(CW\*(C`sqrtd2\*(C'\fR, \f(CW\*(C`sqrtf4\*(C'\fR, \f(CW\*(C`tand2\*(C'\fR,
  \&\f(CW\*(C`tanf4\*(C'\fR, \f(CW\*(C`tanhd2\*(C'\fR, and \f(CW\*(C`tanhf4\*(C'\fR when generating code
  for power7.  Both \fB\-ftree\-vectorize\fR and
! \&\fB\-funsafe\-math\-optimizations\fR must also be enabled.  The \s-1MASS\s0
  libraries must be specified at link time.
! .IP "\fB\-mfriz\fR" 4
  .IX Item "-mfriz"
  .PD 0
! .IP "\fB\-mno\-friz\fR" 4
  .IX Item "-mno-friz"
  .PD
  Generate (do not generate) the \f(CW\*(C`friz\*(C'\fR instruction when the
  \&\fB\-funsafe\-math\-optimizations\fR option is used to optimize
! rounding of floating-point values to 64\-bit integer and back to floating
  point.  The \f(CW\*(C`friz\*(C'\fR instruction does not return the same value if
! the floating-point number is too large to fit in an integer.
! .IP "\fB\-mpointers\-to\-nested\-functions\fR" 4
  .IX Item "-mpointers-to-nested-functions"
  .PD 0
! .IP "\fB\-mno\-pointers\-to\-nested\-functions\fR" 4
  .IX Item "-mno-pointers-to-nested-functions"
  .PD
  Generate (do not generate) code to load up the static chain register
! (\f(CW\*(C`r11\*(C'\fR) when calling through a pointer on \s-1AIX\s0 and 64\-bit Linux
  systems where a function pointer points to a 3\-word descriptor giving
! the function address, \s-1TOC\s0 value to be loaded in register \f(CW\*(C`r2\*(C'\fR, and
  static chain value to be loaded in register \f(CW\*(C`r11\*(C'\fR.  The
  \&\fB\-mpointers\-to\-nested\-functions\fR is on by default.  You cannot
  call through pointers to nested functions or pointers
  to functions compiled in other languages that use the static chain if
  you use \fB\-mno\-pointers\-to\-nested\-functions\fR.
! .IP "\fB\-msave\-toc\-indirect\fR" 4
  .IX Item "-msave-toc-indirect"
  .PD 0
! .IP "\fB\-mno\-save\-toc\-indirect\fR" 4
  .IX Item "-mno-save-toc-indirect"
  .PD
! Generate (do not generate) code to save the \s-1TOC\s0 value in the reserved
  stack location in the function prologue if the function calls through
! a pointer on \s-1AIX\s0 and 64\-bit Linux systems.  If the \s-1TOC\s0 value is not
  saved in the prologue, it is saved just before the call through the
  pointer.  The \fB\-mno\-save\-toc\-indirect\fR option is the default.
! .IP "\fB\-mcompat\-align\-parm\fR" 4
  .IX Item "-mcompat-align-parm"
  .PD 0
! .IP "\fB\-mno\-compat\-align\-parm\fR" 4
  .IX Item "-mno-compat-align-parm"
  .PD
  Generate (do not generate) code to pass structure parameters with a
  maximum alignment of 64 bits, for compatibility with older versions
! of \s-1GCC.\s0
  .Sp
! Older versions of \s-1GCC\s0 (prior to 4.9.0) incorrectly did not align a
  structure parameter on a 128\-bit boundary when that structure contained
  a member requiring 128\-bit alignment.  This is corrected in more
! recent versions of \s-1GCC.\s0  This option may be used to generate code
  that is compatible with functions compiled with older versions of
! \&\s-1GCC.\s0
  .Sp
  The \fB\-mno\-compat\-align\-parm\fR option is the default.
! .IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP "\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR" 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP "\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR" 4
  .IX Item "-mstack-protector-guard-offset=offset"
! .IP "\fB\-mstack\-protector\-guard\-symbol=\fR\fIsymbol\fR" 4
  .IX Item "-mstack-protector-guard-symbol=symbol"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for global canary or \fBtls\fR for per-thread
! canary in the \s-1TLS\s0 block (the default with \s-1GNU\s0 libc version 2.4 or later).
  .Sp
  With the latter choice the options
  \&\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR and
  \&\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR furthermore specify
  which register to use as base register for reading the canary, and from what
  offset from that base register. The default for those is as specified in the
! relevant \s-1ABI.\s0  \fB\-mstack\-protector\-guard\-symbol=\fR\fIsymbol\fR overrides
! the offset with a symbol reference to a canary in the \s-1TLS\s0 block.
! .IP "\fB\-mpcrel\fR" 4
  .IX Item "-mpcrel"
  .PD 0
! .IP "\fB\-mno\-pcrel\fR" 4
  .IX Item "-mno-pcrel"
  .PD
! Generate (do not generate) pc-relative addressing.  The \fB\-mpcrel\fR
  option requires that the medium code model (\fB\-mcmodel=medium\fR)
  and prefixed addressing (\fB\-mprefixed\fR) options are enabled.
! .IP "\fB\-mprefixed\fR" 4
  .IX Item "-mprefixed"
  .PD 0
! .IP "\fB\-mno\-prefixed\fR" 4
  .IX Item "-mno-prefixed"
  .PD
  Generate (do not generate) addressing modes using prefixed load and
  store instructions.  The \fB\-mprefixed\fR option requires that
  the option \fB\-mcpu=power10\fR (or later) is enabled.
! .IP "\fB\-mmma\fR" 4
  .IX Item "-mmma"
  .PD 0
! .IP "\fB\-mno\-mma\fR" 4
  .IX Item "-mno-mma"
  .PD
! Generate (do not generate) the \s-1MMA\s0 instructions.  The \fB\-mma\fR
  option requires that the option \fB\-mcpu=power10\fR (or later)
  is enabled.
! .IP "\fB\-mrop\-protect\fR" 4
  .IX Item "-mrop-protect"
  .PD 0
! .IP "\fB\-mno\-rop\-protect\fR" 4
  .IX Item "-mno-rop-protect"
  .PD
! Generate (do not generate) \s-1ROP\s0 protection instructions when the target
! processor supports them.  Currently this option disables the shrink-wrap
  optimization (\fB\-fshrink\-wrap\fR).
! .IP "\fB\-mprivileged\fR" 4
  .IX Item "-mprivileged"
  .PD 0
! .IP "\fB\-mno\-privileged\fR" 4
  .IX Item "-mno-privileged"
  .PD
  Generate (do not generate) code that will run in privileged state.
! .IP "\fB\-mblock\-ops\-unaligned\-vsx\fR" 4
  .IX Item "-mblock-ops-unaligned-vsx"
  .PD 0
! .IP "\fB\-mno\-block\-ops\-unaligned\-vsx\fR" 4
  .IX Item "-mno-block-ops-unaligned-vsx"
  .PD
  Generate (do not generate) unaligned vsx loads and stores for
--- 29420,29550 ----
  \&\f(CW\*(C`sinhf4\*(C'\fR, \f(CW\*(C`sqrtd2\*(C'\fR, \f(CW\*(C`sqrtf4\*(C'\fR, \f(CW\*(C`tand2\*(C'\fR,
  \&\f(CW\*(C`tanf4\*(C'\fR, \f(CW\*(C`tanhd2\*(C'\fR, and \f(CW\*(C`tanhf4\*(C'\fR when generating code
  for power7.  Both \fB\-ftree\-vectorize\fR and
! \&\fB\-funsafe\-math\-optimizations\fR must also be enabled.  The MASS
  libraries must be specified at link time.
! .IP \fB\-mfriz\fR 4
  .IX Item "-mfriz"
  .PD 0
! .IP \fB\-mno\-friz\fR 4
  .IX Item "-mno-friz"
  .PD
  Generate (do not generate) the \f(CW\*(C`friz\*(C'\fR instruction when the
  \&\fB\-funsafe\-math\-optimizations\fR option is used to optimize
! rounding of floating\-point values to 64\-bit integer and back to floating
  point.  The \f(CW\*(C`friz\*(C'\fR instruction does not return the same value if
! the floating\-point number is too large to fit in an integer.
! .IP \fB\-mpointers\-to\-nested\-functions\fR 4
  .IX Item "-mpointers-to-nested-functions"
  .PD 0
! .IP \fB\-mno\-pointers\-to\-nested\-functions\fR 4
  .IX Item "-mno-pointers-to-nested-functions"
  .PD
  Generate (do not generate) code to load up the static chain register
! (\f(CW\*(C`r11\*(C'\fR) when calling through a pointer on AIX and 64\-bit Linux
  systems where a function pointer points to a 3\-word descriptor giving
! the function address, TOC value to be loaded in register \f(CW\*(C`r2\*(C'\fR, and
  static chain value to be loaded in register \f(CW\*(C`r11\*(C'\fR.  The
  \&\fB\-mpointers\-to\-nested\-functions\fR is on by default.  You cannot
  call through pointers to nested functions or pointers
  to functions compiled in other languages that use the static chain if
  you use \fB\-mno\-pointers\-to\-nested\-functions\fR.
! .IP \fB\-msave\-toc\-indirect\fR 4
  .IX Item "-msave-toc-indirect"
  .PD 0
! .IP \fB\-mno\-save\-toc\-indirect\fR 4
  .IX Item "-mno-save-toc-indirect"
  .PD
! Generate (do not generate) code to save the TOC value in the reserved
  stack location in the function prologue if the function calls through
! a pointer on AIX and 64\-bit Linux systems.  If the TOC value is not
  saved in the prologue, it is saved just before the call through the
  pointer.  The \fB\-mno\-save\-toc\-indirect\fR option is the default.
! .IP \fB\-mcompat\-align\-parm\fR 4
  .IX Item "-mcompat-align-parm"
  .PD 0
! .IP \fB\-mno\-compat\-align\-parm\fR 4
  .IX Item "-mno-compat-align-parm"
  .PD
  Generate (do not generate) code to pass structure parameters with a
  maximum alignment of 64 bits, for compatibility with older versions
! of GCC.
  .Sp
! Older versions of GCC (prior to 4.9.0) incorrectly did not align a
  structure parameter on a 128\-bit boundary when that structure contained
  a member requiring 128\-bit alignment.  This is corrected in more
! recent versions of GCC.  This option may be used to generate code
  that is compatible with functions compiled with older versions of
! GCC.
  .Sp
  The \fB\-mno\-compat\-align\-parm\fR option is the default.
! .IP \fB\-mstack\-protector\-guard=\fR\fIguard\fR 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP \fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR 4
  .IX Item "-mstack-protector-guard-offset=offset"
! .IP \fB\-mstack\-protector\-guard\-symbol=\fR\fIsymbol\fR 4
  .IX Item "-mstack-protector-guard-symbol=symbol"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for global canary or \fBtls\fR for per\-thread
! canary in the TLS block (the default with GNU libc version 2.4 or later).
  .Sp
  With the latter choice the options
  \&\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR and
  \&\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR furthermore specify
  which register to use as base register for reading the canary, and from what
  offset from that base register. The default for those is as specified in the
! relevant ABI.  \fB\-mstack\-protector\-guard\-symbol=\fR\fIsymbol\fR overrides
! the offset with a symbol reference to a canary in the TLS block.
! .IP \fB\-mpcrel\fR 4
  .IX Item "-mpcrel"
  .PD 0
! .IP \fB\-mno\-pcrel\fR 4
  .IX Item "-mno-pcrel"
  .PD
! Generate (do not generate) pc\-relative addressing.  The \fB\-mpcrel\fR
  option requires that the medium code model (\fB\-mcmodel=medium\fR)
  and prefixed addressing (\fB\-mprefixed\fR) options are enabled.
! .IP \fB\-mprefixed\fR 4
  .IX Item "-mprefixed"
  .PD 0
! .IP \fB\-mno\-prefixed\fR 4
  .IX Item "-mno-prefixed"
  .PD
  Generate (do not generate) addressing modes using prefixed load and
  store instructions.  The \fB\-mprefixed\fR option requires that
  the option \fB\-mcpu=power10\fR (or later) is enabled.
! .IP \fB\-mmma\fR 4
  .IX Item "-mmma"
  .PD 0
! .IP \fB\-mno\-mma\fR 4
  .IX Item "-mno-mma"
  .PD
! Generate (do not generate) the MMA instructions.  The \fB\-mma\fR
  option requires that the option \fB\-mcpu=power10\fR (or later)
  is enabled.
! .IP \fB\-mrop\-protect\fR 4
  .IX Item "-mrop-protect"
  .PD 0
! .IP \fB\-mno\-rop\-protect\fR 4
  .IX Item "-mno-rop-protect"
  .PD
! Generate (do not generate) ROP protection instructions when the target
! processor supports them.  Currently this option disables the shrink\-wrap
  optimization (\fB\-fshrink\-wrap\fR).
! .IP \fB\-mprivileged\fR 4
  .IX Item "-mprivileged"
  .PD 0
! .IP \fB\-mno\-privileged\fR 4
  .IX Item "-mno-privileged"
  .PD
  Generate (do not generate) code that will run in privileged state.
! .IP \fB\-mblock\-ops\-unaligned\-vsx\fR 4
  .IX Item "-mblock-ops-unaligned-vsx"
  .PD 0
! .IP \fB\-mno\-block\-ops\-unaligned\-vsx\fR 4
  .IX Item "-mno-block-ops-unaligned-vsx"
  .PD
  Generate (do not generate) unaligned vsx loads and stores for
*************** would be beneficial to unroll the main v
*** 29625,29690 ****
  parameter sets the upper bound of how much the vectorizer will unroll the main
  loop.  The default value is four.
  .PP
! \fI\s-1RX\s0 Options\fR
  .IX Subsection "RX Options"
  .PP
! These command-line options are defined for \s-1RX\s0 targets:
! .IP "\fB\-m64bit\-doubles\fR" 4
  .IX Item "-m64bit-doubles"
  .PD 0
! .IP "\fB\-m32bit\-doubles\fR" 4
  .IX Item "-m32bit-doubles"
  .PD
  Make the \f(CW\*(C`double\*(C'\fR data type be 64 bits (\fB\-m64bit\-doubles\fR)
  or 32 bits (\fB\-m32bit\-doubles\fR) in size.  The default is
! \&\fB\-m32bit\-doubles\fR.  \fINote\fR \s-1RX\s0 floating-point hardware only
  works on 32\-bit values, which is why the default is
  \&\fB\-m32bit\-doubles\fR.
! .IP "\fB\-fpu\fR" 4
  .IX Item "-fpu"
  .PD 0
! .IP "\fB\-nofpu\fR" 4
  .IX Item "-nofpu"
  .PD
! Enables (\fB\-fpu\fR) or disables (\fB\-nofpu\fR) the use of \s-1RX\s0
! floating-point hardware.  The default is enabled for the \s-1RX600\s0
! series and disabled for the \s-1RX200\s0 series.
  .Sp
! Floating-point instructions are only generated for 32\-bit floating-point 
! values, however, so the \s-1FPU\s0 hardware is not used for doubles if the
  \&\fB\-m64bit\-doubles\fR option is used.
  .Sp
  \&\fINote\fR If the \fB\-fpu\fR option is enabled then
  \&\fB\-funsafe\-math\-optimizations\fR is also enabled automatically.
! This is because the \s-1RX FPU\s0 instructions are themselves unsafe.
! .IP "\fB\-mcpu=\fR\fIname\fR" 4
  .IX Item "-mcpu=name"
! Selects the type of \s-1RX CPU\s0 to be targeted.  Currently three types are
! supported, the generic \fB\s-1RX600\s0\fR and \fB\s-1RX200\s0\fR series hardware and
! the specific \fB\s-1RX610\s0\fR \s-1CPU.\s0  The default is \fB\s-1RX600\s0\fR.
  .Sp
! The only difference between \fB\s-1RX600\s0\fR and \fB\s-1RX610\s0\fR is that the
! \&\fB\s-1RX610\s0\fR does not support the \f(CW\*(C`MVTIPL\*(C'\fR instruction.
  .Sp
! The \fB\s-1RX200\s0\fR series does not have a hardware floating-point unit
  and so \fB\-nofpu\fR is enabled by default when this type is
  selected.
! .IP "\fB\-mbig\-endian\-data\fR" 4
  .IX Item "-mbig-endian-data"
  .PD 0
! .IP "\fB\-mlittle\-endian\-data\fR" 4
  .IX Item "-mlittle-endian-data"
  .PD
! Store data (but not code) in the big-endian format.  The default is
! \&\fB\-mlittle\-endian\-data\fR, i.e. to store data in the little-endian
  format.
! .IP "\fB\-msmall\-data\-limit=\fR\fIN\fR" 4
  .IX Item "-msmall-data-limit=N"
  Specifies the maximum size in bytes of global and static variables
  which can be placed into the small data area.  Using the small data
  area can lead to smaller and faster code, but the size of area is
  limited and it is up to the programmer to ensure that the area does
! not overflow.  Also when the small data area is used one of the \s-1RX\s0's
  registers (usually \f(CW\*(C`r13\*(C'\fR) is reserved for use pointing to this
  area, so it is no longer available for use by the compiler.  This
  could result in slower and/or larger code if variables are pushed onto
--- 29556,29621 ----
  parameter sets the upper bound of how much the vectorizer will unroll the main
  loop.  The default value is four.
  .PP
! \fIRX Options\fR
  .IX Subsection "RX Options"
  .PP
! These command\-line options are defined for RX targets:
! .IP \fB\-m64bit\-doubles\fR 4
  .IX Item "-m64bit-doubles"
  .PD 0
! .IP \fB\-m32bit\-doubles\fR 4
  .IX Item "-m32bit-doubles"
  .PD
  Make the \f(CW\*(C`double\*(C'\fR data type be 64 bits (\fB\-m64bit\-doubles\fR)
  or 32 bits (\fB\-m32bit\-doubles\fR) in size.  The default is
! \&\fB\-m32bit\-doubles\fR.  \fINote\fR RX floating\-point hardware only
  works on 32\-bit values, which is why the default is
  \&\fB\-m32bit\-doubles\fR.
! .IP \fB\-fpu\fR 4
  .IX Item "-fpu"
  .PD 0
! .IP \fB\-nofpu\fR 4
  .IX Item "-nofpu"
  .PD
! Enables (\fB\-fpu\fR) or disables (\fB\-nofpu\fR) the use of RX
! floating\-point hardware.  The default is enabled for the RX600
! series and disabled for the RX200 series.
  .Sp
! Floating\-point instructions are only generated for 32\-bit floating\-point 
! values, however, so the FPU hardware is not used for doubles if the
  \&\fB\-m64bit\-doubles\fR option is used.
  .Sp
  \&\fINote\fR If the \fB\-fpu\fR option is enabled then
  \&\fB\-funsafe\-math\-optimizations\fR is also enabled automatically.
! This is because the RX FPU instructions are themselves unsafe.
! .IP \fB\-mcpu=\fR\fIname\fR 4
  .IX Item "-mcpu=name"
! Selects the type of RX CPU to be targeted.  Currently three types are
! supported, the generic \fBRX600\fR and \fBRX200\fR series hardware and
! the specific \fBRX610\fR CPU.  The default is \fBRX600\fR.
  .Sp
! The only difference between \fBRX600\fR and \fBRX610\fR is that the
! \&\fBRX610\fR does not support the \f(CW\*(C`MVTIPL\*(C'\fR instruction.
  .Sp
! The \fBRX200\fR series does not have a hardware floating\-point unit
  and so \fB\-nofpu\fR is enabled by default when this type is
  selected.
! .IP \fB\-mbig\-endian\-data\fR 4
  .IX Item "-mbig-endian-data"
  .PD 0
! .IP \fB\-mlittle\-endian\-data\fR 4
  .IX Item "-mlittle-endian-data"
  .PD
! Store data (but not code) in the big\-endian format.  The default is
! \&\fB\-mlittle\-endian\-data\fR, i.e. to store data in the little\-endian
  format.
! .IP \fB\-msmall\-data\-limit=\fR\fIN\fR 4
  .IX Item "-msmall-data-limit=N"
  Specifies the maximum size in bytes of global and static variables
  which can be placed into the small data area.  Using the small data
  area can lead to smaller and faster code, but the size of area is
  limited and it is up to the programmer to ensure that the area does
! not overflow.  Also when the small data area is used one of the RX\*(Aqs
  registers (usually \f(CW\*(C`r13\*(C'\fR) is reserved for use pointing to this
  area, so it is no longer available for use by the compiler.  This
  could result in slower and/or larger code if variables are pushed onto
*************** reserving a register.  It is up to the p
*** 29701,29727 ****
  discover whether this feature is of benefit to their program.  See the
  description of the \fB\-mpid\fR option for a description of how the
  actual register to hold the small data area pointer is chosen.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  .PD 0
! .IP "\fB\-mno\-sim\fR" 4
  .IX Item "-mno-sim"
  .PD
  Use the simulator runtime.  The default is to use the libgloss
! board-specific runtime.
! .IP "\fB\-mas100\-syntax\fR" 4
  .IX Item "-mas100-syntax"
  .PD 0
! .IP "\fB\-mno\-as100\-syntax\fR" 4
  .IX Item "-mno-as100-syntax"
  .PD
  When generating assembler output use a syntax that is compatible with
! Renesas's \s-1AS100\s0 assembler.  This syntax can also be handled by the \s-1GAS\s0
  assembler, but it has some restrictions so it is not generated by default.
! .IP "\fB\-mmax\-constant\-size=\fR\fIN\fR" 4
  .IX Item "-mmax-constant-size=N"
  Specifies the maximum size, in bytes, of a constant that can be used as
! an operand in a \s-1RX\s0 instruction.  Although the \s-1RX\s0 instruction set does
  allow constants of up to 4 bytes in length to be used in instructions,
  a longer value equates to a longer instruction.  Thus in some
  circumstances it can be beneficial to restrict the size of constants
--- 29632,29658 ----
  discover whether this feature is of benefit to their program.  See the
  description of the \fB\-mpid\fR option for a description of how the
  actual register to hold the small data area pointer is chosen.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  .PD 0
! .IP \fB\-mno\-sim\fR 4
  .IX Item "-mno-sim"
  .PD
  Use the simulator runtime.  The default is to use the libgloss
! board\-specific runtime.
! .IP \fB\-mas100\-syntax\fR 4
  .IX Item "-mas100-syntax"
  .PD 0
! .IP \fB\-mno\-as100\-syntax\fR 4
  .IX Item "-mno-as100-syntax"
  .PD
  When generating assembler output use a syntax that is compatible with
! Renesas\*(Aqs AS100 assembler.  This syntax can also be handled by the GAS
  assembler, but it has some restrictions so it is not generated by default.
! .IP \fB\-mmax\-constant\-size=\fR\fIN\fR 4
  .IX Item "-mmax-constant-size=N"
  Specifies the maximum size, in bytes, of a constant that can be used as
! an operand in a 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
*************** placed into a constant pool and referenc
*** 29730,29741 ****
  .Sp
  The value \fIN\fR can be between 0 and 4.  A value of 0 (the default)
  or 4 means that constants of any size are allowed.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Enable linker relaxation.  Linker relaxation is a process whereby the
  linker attempts to reduce the size of a program by finding shorter
  versions of various instructions.  Disabled by default.
! .IP "\fB\-mint\-register=\fR\fIN\fR" 4
  .IX Item "-mint-register=N"
  Specify the number of registers to reserve for fast interrupt handler
  functions.  The value \fIN\fR can be between 0 and 4.  A value of 1
--- 29661,29672 ----
  .Sp
  The value \fIN\fR can be between 0 and 4.  A value of 0 (the default)
  or 4 means that constants of any size are allowed.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Enable linker relaxation.  Linker relaxation is a process whereby the
  linker attempts to reduce the size of a program by finding shorter
  versions of various instructions.  Disabled by default.
! .IP \fB\-mint\-register=\fR\fIN\fR 4
  .IX Item "-mint-register=N"
  Specify the number of registers to reserve for fast interrupt handler
  functions.  The value \fIN\fR can be between 0 and 4.  A value of 1
*************** of fast interrupt handlers.  A value of
*** 29744,29760 ****
  \&\f(CW\*(C`r12\*(C'\fR.  A value of 3 reserves \f(CW\*(C`r13\*(C'\fR, \f(CW\*(C`r12\*(C'\fR and
  \&\f(CW\*(C`r11\*(C'\fR, and a value of 4 reserves \f(CW\*(C`r13\*(C'\fR through \f(CW\*(C`r10\*(C'\fR.
  A value of 0, the default, does not reserve any registers.
! .IP "\fB\-msave\-acc\-in\-interrupts\fR" 4
  .IX Item "-msave-acc-in-interrupts"
  Specifies that interrupt handler functions should preserve the
  accumulator register.  This is only necessary if normal code might use
  the accumulator register, for example because it performs 64\-bit
  multiplications.  The default is to ignore the accumulator as this
  makes the interrupt handlers faster.
! .IP "\fB\-mpid\fR" 4
  .IX Item "-mpid"
  .PD 0
! .IP "\fB\-mno\-pid\fR" 4
  .IX Item "-mno-pid"
  .PD
  Enables the generation of position independent data.  When enabled any
--- 29675,29691 ----
  \&\f(CW\*(C`r12\*(C'\fR.  A value of 3 reserves \f(CW\*(C`r13\*(C'\fR, \f(CW\*(C`r12\*(C'\fR and
  \&\f(CW\*(C`r11\*(C'\fR, and a value of 4 reserves \f(CW\*(C`r13\*(C'\fR through \f(CW\*(C`r10\*(C'\fR.
  A value of 0, the default, does not reserve any registers.
! .IP \fB\-msave\-acc\-in\-interrupts\fR 4
  .IX Item "-msave-acc-in-interrupts"
  Specifies that interrupt handler functions should preserve the
  accumulator register.  This is only necessary if normal code might use
  the accumulator register, for example because it performs 64\-bit
  multiplications.  The default is to ignore the accumulator as this
  makes the interrupt handlers faster.
! .IP \fB\-mpid\fR 4
  .IX Item "-mpid"
  .PD 0
! .IP \fB\-mno\-pid\fR 4
  .IX Item "-mno-pid"
  .PD
  Enables the generation of position independent data.  When enabled any
*************** larger code, especially in complicated f
*** 29771,29777 ****
  .Sp
  The actual register chosen to hold the constant data base address
  depends upon whether the \fB\-msmall\-data\-limit\fR and/or the
! \&\fB\-mint\-register\fR command-line options are enabled.  Starting
  with register \f(CW\*(C`r13\*(C'\fR and proceeding downwards, registers are
  allocated first to satisfy the requirements of \fB\-mint\-register\fR,
  then \fB\-mpid\fR and finally \fB\-msmall\-data\-limit\fR.  Thus it
--- 29702,29708 ----
  .Sp
  The actual register chosen to hold the constant data base address
  depends upon whether the \fB\-msmall\-data\-limit\fR and/or the
! \&\fB\-mint\-register\fR command\-line options are enabled.  Starting
  with register \f(CW\*(C`r13\*(C'\fR and proceeding downwards, registers are
  allocated first to satisfy the requirements of \fB\-mint\-register\fR,
  then \fB\-mpid\fR and finally \fB\-msmall\-data\-limit\fR.  Thus it
*************** is possible for the small data area regi
*** 29780,29823 ****
  command line.
  .Sp
  By default this feature is not enabled.  The default can be restored
! via the \fB\-mno\-pid\fR command-line option.
! .IP "\fB\-mno\-warn\-multiple\-fast\-interrupts\fR" 4
  .IX Item "-mno-warn-multiple-fast-interrupts"
  .PD 0
! .IP "\fB\-mwarn\-multiple\-fast\-interrupts\fR" 4
  .IX Item "-mwarn-multiple-fast-interrupts"
  .PD
! Prevents \s-1GCC\s0 from issuing a warning message if it finds more than one
  fast interrupt handler when it is compiling a file.  The default is to
! issue a warning for each extra fast interrupt handler found, as the \s-1RX\s0
  only supports one such interrupt.
! .IP "\fB\-mallow\-string\-insns\fR" 4
  .IX Item "-mallow-string-insns"
  .PD 0
! .IP "\fB\-mno\-allow\-string\-insns\fR" 4
  .IX Item "-mno-allow-string-insns"
  .PD
  Enables or disables the use of the string manipulation instructions
  \&\f(CW\*(C`SMOVF\*(C'\fR, \f(CW\*(C`SCMPU\*(C'\fR, \f(CW\*(C`SMOVB\*(C'\fR, \f(CW\*(C`SMOVU\*(C'\fR, \f(CW\*(C`SUNTIL\*(C'\fR
  \&\f(CW\*(C`SWHILE\*(C'\fR and also the \f(CW\*(C`RMPA\*(C'\fR instruction.  These
  instructions may prefetch data, which is not safe to do if accessing
! an I/O register.  (See section 12.2.7 of the \s-1RX62N\s0 Group User's Manual
  for more information).
  .Sp
  The default is to allow these instructions, but it is not possible for
! \&\s-1GCC\s0 to reliably detect all circumstances where a string instruction
  might be used to access an I/O register, so their use cannot be
  disabled automatically.  Instead it is reliant upon the programmer to
  use the \fB\-mno\-allow\-string\-insns\fR option if their program
  accesses I/O space.
  .Sp
! When the instructions are enabled \s-1GCC\s0 defines the C preprocessor
  symbol \f(CW\*(C`_\|_RX_ALLOW_STRING_INSNS_\|_\*(C'\fR, otherwise it defines the
  symbol \f(CW\*(C`_\|_RX_DISALLOW_STRING_INSNS_\|_\*(C'\fR.
! .IP "\fB\-mjsr\fR" 4
  .IX Item "-mjsr"
  .PD 0
! .IP "\fB\-mno\-jsr\fR" 4
  .IX Item "-mno-jsr"
  .PD
  Use only (or not only) \f(CW\*(C`JSR\*(C'\fR instructions to access functions.
--- 29711,29754 ----
  command line.
  .Sp
  By default this feature is not enabled.  The default can be restored
! via the \fB\-mno\-pid\fR command\-line option.
! .IP \fB\-mno\-warn\-multiple\-fast\-interrupts\fR 4
  .IX Item "-mno-warn-multiple-fast-interrupts"
  .PD 0
! .IP \fB\-mwarn\-multiple\-fast\-interrupts\fR 4
  .IX Item "-mwarn-multiple-fast-interrupts"
  .PD
! Prevents GCC from issuing a warning message if it finds more than one
  fast interrupt handler when it is compiling a file.  The default is to
! issue a warning for each extra fast interrupt handler found, as the RX
  only supports one such interrupt.
! .IP \fB\-mallow\-string\-insns\fR 4
  .IX Item "-mallow-string-insns"
  .PD 0
! .IP \fB\-mno\-allow\-string\-insns\fR 4
  .IX Item "-mno-allow-string-insns"
  .PD
  Enables or disables the use of the string manipulation instructions
  \&\f(CW\*(C`SMOVF\*(C'\fR, \f(CW\*(C`SCMPU\*(C'\fR, \f(CW\*(C`SMOVB\*(C'\fR, \f(CW\*(C`SMOVU\*(C'\fR, \f(CW\*(C`SUNTIL\*(C'\fR
  \&\f(CW\*(C`SWHILE\*(C'\fR and also the \f(CW\*(C`RMPA\*(C'\fR instruction.  These
  instructions may prefetch data, which is not safe to do if accessing
! an I/O register.  (See section 12.2.7 of the RX62N Group User\*(Aqs Manual
  for more information).
  .Sp
  The default is to allow these instructions, but it is not possible for
! GCC to reliably detect all circumstances where a string instruction
  might be used to access an I/O register, so their use cannot be
  disabled automatically.  Instead it is reliant upon the programmer to
  use the \fB\-mno\-allow\-string\-insns\fR option if their program
  accesses I/O space.
  .Sp
! When the instructions are enabled GCC defines the C preprocessor
  symbol \f(CW\*(C`_\|_RX_ALLOW_STRING_INSNS_\|_\*(C'\fR, otherwise it defines the
  symbol \f(CW\*(C`_\|_RX_DISALLOW_STRING_INSNS_\|_\*(C'\fR.
! .IP \fB\-mjsr\fR 4
  .IX Item "-mjsr"
  .PD 0
! .IP \fB\-mno\-jsr\fR 4
  .IX Item "-mno-jsr"
  .PD
  Use only (or not only) \f(CW\*(C`JSR\*(C'\fR instructions to access functions.
*************** This option can be used when code size e
*** 29825,29892 ****
  instructions.  Note that \fB\-mno\-jsr\fR does not mean to not use
  \&\f(CW\*(C`JSR\*(C'\fR but instead means that any type of branch may be used.
  .PP
! \&\fINote:\fR The generic \s-1GCC\s0 command-line option \fB\-ffixed\-\fR\fIreg\fR
! has special significance to the \s-1RX\s0 port when used with the
  \&\f(CW\*(C`interrupt\*(C'\fR function attribute.  This attribute indicates a
! function intended to process fast interrupts.  \s-1GCC\s0 ensures
  that it only uses the registers \f(CW\*(C`r10\*(C'\fR, \f(CW\*(C`r11\*(C'\fR, \f(CW\*(C`r12\*(C'\fR
  and/or \f(CW\*(C`r13\*(C'\fR and only provided that the normal use of the
  corresponding registers have been restricted via the
! \&\fB\-ffixed\-\fR\fIreg\fR or \fB\-mint\-register\fR command-line
  options.
  .PP
  \fIS/390 and zSeries Options\fR
  .IX Subsection "S/390 and zSeries Options"
  .PP
  These are the \fB\-m\fR options defined for the S/390 and zSeries architecture.
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
! Use (do not use) the hardware floating-point instructions and registers
! for floating-point operations.  When \fB\-msoft\-float\fR is specified,
! functions in \fIlibgcc.a\fR are used to perform floating-point
  operations.  When \fB\-mhard\-float\fR is specified, the compiler
! generates \s-1IEEE\s0 floating-point instructions.  This is the default.
! .IP "\fB\-mhard\-dfp\fR" 4
  .IX Item "-mhard-dfp"
  .PD 0
! .IP "\fB\-mno\-hard\-dfp\fR" 4
  .IX Item "-mno-hard-dfp"
  .PD
! Use (do not use) the hardware decimal-floating-point instructions for
! decimal-floating-point operations.  When \fB\-mno\-hard\-dfp\fR is
  specified, functions in \fIlibgcc.a\fR are used to perform
! decimal-floating-point operations.  When \fB\-mhard\-dfp\fR is
! specified, the compiler generates decimal-floating-point hardware
  instructions.  This is the default for \fB\-march=z9\-ec\fR or higher.
! .IP "\fB\-mlong\-double\-64\fR" 4
  .IX Item "-mlong-double-64"
  .PD 0
! .IP "\fB\-mlong\-double\-128\fR" 4
  .IX Item "-mlong-double-128"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
  of 64 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the \f(CW\*(C`double\*(C'\fR
  type. This is the default.
! .IP "\fB\-mbackchain\fR" 4
  .IX Item "-mbackchain"
  .PD 0
! .IP "\fB\-mno\-backchain\fR" 4
  .IX Item "-mno-backchain"
  .PD
! Store (do not store) the address of the caller's frame as backchain pointer
! into the callee's stack frame.
  A backchain may be needed to allow debugging using tools that do not understand
! \&\s-1DWARF\s0 call frame information.
  When \fB\-mno\-packed\-stack\fR is in effect, the backchain pointer is stored
  at the bottom of the stack frame; when \fB\-mpacked\-stack\fR is in effect,
  the backchain is placed into the topmost word of the 96/160 byte register
  save area.
  .Sp
! In general, code compiled with \fB\-mbackchain\fR is call-compatible with
  code compiled with \fB\-mno\-backchain\fR; however, use of the backchain
  for debugging purposes usually requires that the whole binary is built with
  \&\fB\-mbackchain\fR.  Note that the combination of \fB\-mbackchain\fR,
--- 29756,29823 ----
  instructions.  Note that \fB\-mno\-jsr\fR does not mean to not use
  \&\f(CW\*(C`JSR\*(C'\fR but instead means that any type of branch may be used.
  .PP
! \&\fINote:\fR The generic GCC command\-line option \fB\-ffixed\-\fR\fIreg\fR
! has special significance to the RX port when used with the
  \&\f(CW\*(C`interrupt\*(C'\fR function attribute.  This attribute indicates a
! function intended to process fast interrupts.  GCC ensures
  that it only uses the registers \f(CW\*(C`r10\*(C'\fR, \f(CW\*(C`r11\*(C'\fR, \f(CW\*(C`r12\*(C'\fR
  and/or \f(CW\*(C`r13\*(C'\fR and only provided that the normal use of the
  corresponding registers have been restricted via the
! \&\fB\-ffixed\-\fR\fIreg\fR or \fB\-mint\-register\fR command\-line
  options.
  .PP
  \fIS/390 and zSeries Options\fR
  .IX Subsection "S/390 and zSeries Options"
  .PP
  These are the \fB\-m\fR options defined for the S/390 and zSeries architecture.
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
! Use (do not use) the hardware floating\-point instructions and registers
! for floating\-point operations.  When \fB\-msoft\-float\fR is specified,
! functions in \fIlibgcc.a\fR are used to perform floating\-point
  operations.  When \fB\-mhard\-float\fR is specified, the compiler
! generates IEEE floating\-point instructions.  This is the default.
! .IP \fB\-mhard\-dfp\fR 4
  .IX Item "-mhard-dfp"
  .PD 0
! .IP \fB\-mno\-hard\-dfp\fR 4
  .IX Item "-mno-hard-dfp"
  .PD
! Use (do not use) the hardware decimal\-floating\-point instructions for
! decimal\-floating\-point operations.  When \fB\-mno\-hard\-dfp\fR is
  specified, functions in \fIlibgcc.a\fR are used to perform
! decimal\-floating\-point operations.  When \fB\-mhard\-dfp\fR is
! specified, the compiler generates decimal\-floating\-point hardware
  instructions.  This is the default for \fB\-march=z9\-ec\fR or higher.
! .IP \fB\-mlong\-double\-64\fR 4
  .IX Item "-mlong-double-64"
  .PD 0
! .IP \fB\-mlong\-double\-128\fR 4
  .IX Item "-mlong-double-128"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
  of 64 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the \f(CW\*(C`double\*(C'\fR
  type. This is the default.
! .IP \fB\-mbackchain\fR 4
  .IX Item "-mbackchain"
  .PD 0
! .IP \fB\-mno\-backchain\fR 4
  .IX Item "-mno-backchain"
  .PD
! Store (do not store) the address of the caller\*(Aqs frame as backchain pointer
! into the callee\*(Aqs stack frame.
  A backchain may be needed to allow debugging using tools that do not understand
! DWARF call frame information.
  When \fB\-mno\-packed\-stack\fR is in effect, the backchain pointer is stored
  at the bottom of the stack frame; when \fB\-mpacked\-stack\fR is in effect,
  the backchain is placed into the topmost word of the 96/160 byte register
  save area.
  .Sp
! In general, code compiled with \fB\-mbackchain\fR is call\-compatible with
  code compiled with \fB\-mno\-backchain\fR; however, use of the backchain
  for debugging purposes usually requires that the whole binary is built with
  \&\fB\-mbackchain\fR.  Note that the combination of \fB\-mbackchain\fR,
*************** for debugging purposes usually requires
*** 29894,29903 ****
  to build a linux kernel use \fB\-msoft\-float\fR.
  .Sp
  The default is to not maintain the backchain.
! .IP "\fB\-mpacked\-stack\fR" 4
  .IX Item "-mpacked-stack"
  .PD 0
! .IP "\fB\-mno\-packed\-stack\fR" 4
  .IX Item "-mno-packed-stack"
  .PD
  Use (do not use) the packed stack layout.  When \fB\-mno\-packed\-stack\fR is
--- 29825,29834 ----
  to build a linux kernel use \fB\-msoft\-float\fR.
  .Sp
  The default is to not maintain the backchain.
! .IP \fB\-mpacked\-stack\fR 4
  .IX Item "-mpacked-stack"
  .PD 0
! .IP \fB\-mno\-packed\-stack\fR 4
  .IX Item "-mno-packed-stack"
  .PD
  Use (do not use) the packed stack layout.  When \fB\-mno\-packed\-stack\fR is
*************** the save area is always used to store th
*** 29911,29930 ****
  register is always saved two words below the backchain.
  .Sp
  As long as the stack frame backchain is not used, code generated with
! \&\fB\-mpacked\-stack\fR is call-compatible with code generated with
! \&\fB\-mno\-packed\-stack\fR.  Note that some non-FSF releases of \s-1GCC 2.95\s0 for
  S/390 or zSeries generated code that uses the stack frame backchain at run
! time, not just for debugging purposes.  Such code is not call-compatible
  with code compiled with \fB\-mpacked\-stack\fR.  Also, note that the
  combination of \fB\-mbackchain\fR,
  \&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported.  In order
  to build a linux kernel use \fB\-msoft\-float\fR.
  .Sp
  The default is to not use the packed stack layout.
! .IP "\fB\-msmall\-exec\fR" 4
  .IX Item "-msmall-exec"
  .PD 0
! .IP "\fB\-mno\-small\-exec\fR" 4
  .IX Item "-mno-small-exec"
  .PD
  Generate (or do not generate) code using the \f(CW\*(C`bras\*(C'\fR instruction
--- 29842,29861 ----
  register is always saved two words below the backchain.
  .Sp
  As long as the stack frame backchain is not used, code generated with
! \&\fB\-mpacked\-stack\fR is call\-compatible with code generated with
! \&\fB\-mno\-packed\-stack\fR.  Note that some non\-FSF releases of 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 \fB\-mpacked\-stack\fR.  Also, note that the
  combination of \fB\-mbackchain\fR,
  \&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported.  In order
  to build a linux kernel use \fB\-msoft\-float\fR.
  .Sp
  The default is to not use the packed stack layout.
! .IP \fB\-msmall\-exec\fR 4
  .IX Item "-msmall-exec"
  .PD 0
! .IP \fB\-mno\-small\-exec\fR 4
  .IX Item "-mno-small-exec"
  .PD
  Generate (or do not generate) code using the \f(CW\*(C`bras\*(C'\fR instruction
*************** to do subroutine calls.
*** 29932,30029 ****
  This only works reliably if the total executable size does not
  exceed 64k.  The default is to use the \f(CW\*(C`basr\*(C'\fR instruction instead,
  which does not have this limitation.
! .IP "\fB\-m64\fR" 4
  .IX Item "-m64"
  .PD 0
! .IP "\fB\-m31\fR" 4
  .IX Item "-m31"
  .PD
  When \fB\-m31\fR is specified, generate code compliant to the
! GNU/Linux for S/390 \s-1ABI.\s0  When \fB\-m64\fR is specified, generate
! code compliant to the GNU/Linux for zSeries \s-1ABI.\s0  This allows \s-1GCC\s0 in
  particular to generate 64\-bit instructions.  For the \fBs390\fR
  targets, the default is \fB\-m31\fR, while the \fBs390x\fR
  targets default to \fB\-m64\fR.
! .IP "\fB\-mzarch\fR" 4
  .IX Item "-mzarch"
  .PD 0
! .IP "\fB\-mesa\fR" 4
  .IX Item "-mesa"
  .PD
  When \fB\-mzarch\fR is specified, generate code using the
  instructions available on z/Architecture.
  When \fB\-mesa\fR is specified, generate code using the
! instructions available on \s-1ESA/390.\s0  Note that \fB\-mesa\fR is
  not possible with \fB\-m64\fR.
! When generating code compliant to the GNU/Linux for S/390 \s-1ABI,\s0
  the default is \fB\-mesa\fR.  When generating code compliant
! to the GNU/Linux for zSeries \s-1ABI,\s0 the default is \fB\-mzarch\fR.
! .IP "\fB\-mhtm\fR" 4
  .IX Item "-mhtm"
  .PD 0
! .IP "\fB\-mno\-htm\fR" 4
  .IX Item "-mno-htm"
  .PD
  The \fB\-mhtm\fR option enables a set of builtins making use of
  instructions available with the transactional execution facility
! introduced with the \s-1IBM\s0 zEnterprise \s-1EC12\s0 machine generation
! \&\fBS/390 System z Built-in Functions\fR.
  \&\fB\-mhtm\fR is enabled by default when using \fB\-march=zEC12\fR.
! .IP "\fB\-mvx\fR" 4
  .IX Item "-mvx"
  .PD 0
! .IP "\fB\-mno\-vx\fR" 4
  .IX Item "-mno-vx"
  .PD
  When \fB\-mvx\fR is specified, generate code using the instructions
! available with the vector extension facility introduced with the \s-1IBM\s0
  z13 machine generation.
! This option changes the \s-1ABI\s0 for some vector type values with regard to
  alignment and calling conventions.  In case vector type values are
! being used in an ABI-relevant context a \s-1GAS\s0 \fB.gnu_attribute\fR
! command will be added to mark the resulting binary with the \s-1ABI\s0 used.
  \&\fB\-mvx\fR is enabled by default when using \fB\-march=z13\fR.
! .IP "\fB\-mzvector\fR" 4
  .IX Item "-mzvector"
  .PD 0
! .IP "\fB\-mno\-zvector\fR" 4
  .IX Item "-mno-zvector"
  .PD
  The \fB\-mzvector\fR option enables vector language extensions and
  builtins using instructions available with the vector extension
! facility introduced with the \s-1IBM\s0 z13 machine generation.
  This option adds support for \fBvector\fR to be used as a keyword to
  define vector type variables and arguments.  \fBvector\fR is only
! available when \s-1GNU\s0 extensions are enabled.  It will not be expanded
  when requesting strict standard compliance e.g. with \fB\-std=c99\fR.
! In addition to the \s-1GCC\s0 low-level builtins \fB\-mzvector\fR enables
! a set of builtins added for compatibility with AltiVec-style
  implementations like Power and Cell.  In order to make use of these
  builtins the header file \fIvecintrin.h\fR needs to be included.
  \&\fB\-mzvector\fR is disabled by default.
! .IP "\fB\-mmvcle\fR" 4
  .IX Item "-mmvcle"
  .PD 0
! .IP "\fB\-mno\-mvcle\fR" 4
  .IX Item "-mno-mvcle"
  .PD
  Generate (or do not generate) code using the \f(CW\*(C`mvcle\*(C'\fR instruction
  to perform block moves.  When \fB\-mno\-mvcle\fR is specified,
  use a \f(CW\*(C`mvc\*(C'\fR loop instead.  This is the default unless optimizing for
  size.
! .IP "\fB\-mdebug\fR" 4
  .IX Item "-mdebug"
  .PD 0
! .IP "\fB\-mno\-debug\fR" 4
  .IX Item "-mno-debug"
  .PD
  Print (or do not print) additional debug information when compiling.
  The default is to not print debug information.
! .IP "\fB\-march=\fR\fIcpu-type\fR" 4
  .IX Item "-march=cpu-type"
! Generate code that runs on \fIcpu-type\fR, which is the name of a
  system representing a certain processor type.  Possible values for
! \&\fIcpu-type\fR are \fBz900\fR/\fBarch5\fR, \fBz990\fR/\fBarch6\fR,
  \&\fBz9\-109\fR, \fBz9\-ec\fR/\fBarch7\fR, \fBz10\fR/\fBarch8\fR,
  \&\fBz196\fR/\fBarch9\fR, \fBzEC12\fR, \fBz13\fR/\fBarch11\fR,
  \&\fBz14\fR/\fBarch12\fR, \fBz15\fR/\fBarch13\fR,
--- 29863,29960 ----
  This only works reliably if the total executable size does not
  exceed 64k.  The default is to use the \f(CW\*(C`basr\*(C'\fR instruction instead,
  which does not have this limitation.
! .IP \fB\-m64\fR 4
  .IX Item "-m64"
  .PD 0
! .IP \fB\-m31\fR 4
  .IX Item "-m31"
  .PD
  When \fB\-m31\fR is specified, generate code compliant to the
! GNU/Linux for S/390 ABI.  When \fB\-m64\fR is specified, generate
! code compliant to the GNU/Linux for zSeries ABI.  This allows GCC in
  particular to generate 64\-bit instructions.  For the \fBs390\fR
  targets, the default is \fB\-m31\fR, while the \fBs390x\fR
  targets default to \fB\-m64\fR.
! .IP \fB\-mzarch\fR 4
  .IX Item "-mzarch"
  .PD 0
! .IP \fB\-mesa\fR 4
  .IX Item "-mesa"
  .PD
  When \fB\-mzarch\fR is specified, generate code using the
  instructions available on z/Architecture.
  When \fB\-mesa\fR is specified, generate code using the
! instructions available on ESA/390.  Note that \fB\-mesa\fR is
  not possible with \fB\-m64\fR.
! When generating code compliant to the GNU/Linux for S/390 ABI,
  the default is \fB\-mesa\fR.  When generating code compliant
! to the GNU/Linux for zSeries ABI, the default is \fB\-mzarch\fR.
! .IP \fB\-mhtm\fR 4
  .IX Item "-mhtm"
  .PD 0
! .IP \fB\-mno\-htm\fR 4
  .IX Item "-mno-htm"
  .PD
  The \fB\-mhtm\fR option enables a set of builtins making use of
  instructions available with the transactional execution facility
! introduced with the IBM zEnterprise EC12 machine generation
! \&\fBS/390 System z Built\-in Functions\fR.
  \&\fB\-mhtm\fR is enabled by default when using \fB\-march=zEC12\fR.
! .IP \fB\-mvx\fR 4
  .IX Item "-mvx"
  .PD 0
! .IP \fB\-mno\-vx\fR 4
  .IX Item "-mno-vx"
  .PD
  When \fB\-mvx\fR is specified, generate code using the instructions
! available with the vector extension facility introduced with the IBM
  z13 machine generation.
! This option changes the ABI for some vector type values with regard to
  alignment and calling conventions.  In case vector type values are
! being used in an ABI\-relevant context a GAS \fB.gnu_attribute\fR
! command will be added to mark the resulting binary with the ABI used.
  \&\fB\-mvx\fR is enabled by default when using \fB\-march=z13\fR.
! .IP \fB\-mzvector\fR 4
  .IX Item "-mzvector"
  .PD 0
! .IP \fB\-mno\-zvector\fR 4
  .IX Item "-mno-zvector"
  .PD
  The \fB\-mzvector\fR option enables vector language extensions and
  builtins using instructions available with the vector extension
! facility introduced with the IBM z13 machine generation.
  This option adds support for \fBvector\fR to be used as a keyword to
  define vector type variables and arguments.  \fBvector\fR is only
! available when GNU extensions are enabled.  It will not be expanded
  when requesting strict standard compliance e.g. with \fB\-std=c99\fR.
! In addition to the GCC low\-level builtins \fB\-mzvector\fR enables
! a set of builtins added for compatibility with AltiVec\-style
  implementations like Power and Cell.  In order to make use of these
  builtins the header file \fIvecintrin.h\fR needs to be included.
  \&\fB\-mzvector\fR is disabled by default.
! .IP \fB\-mmvcle\fR 4
  .IX Item "-mmvcle"
  .PD 0
! .IP \fB\-mno\-mvcle\fR 4
  .IX Item "-mno-mvcle"
  .PD
  Generate (or do not generate) code using the \f(CW\*(C`mvcle\*(C'\fR instruction
  to perform block moves.  When \fB\-mno\-mvcle\fR is specified,
  use a \f(CW\*(C`mvc\*(C'\fR loop instead.  This is the default unless optimizing for
  size.
! .IP \fB\-mdebug\fR 4
  .IX Item "-mdebug"
  .PD 0
! .IP \fB\-mno\-debug\fR 4
  .IX Item "-mno-debug"
  .PD
  Print (or do not print) additional debug information when compiling.
  The default is to not print debug information.
! .IP \fB\-march=\fR\fIcpu\-type\fR 4
  .IX Item "-march=cpu-type"
! Generate code that runs on \fIcpu\-type\fR, which is the name of a
  system representing a certain processor type.  Possible values for
! \&\fIcpu\-type\fR are \fBz900\fR/\fBarch5\fR, \fBz990\fR/\fBarch6\fR,
  \&\fBz9\-109\fR, \fBz9\-ec\fR/\fBarch7\fR, \fBz10\fR/\fBarch8\fR,
  \&\fBz196\fR/\fBarch9\fR, \fBzEC12\fR, \fBz13\fR/\fBarch11\fR,
  \&\fBz14\fR/\fBarch12\fR, \fBz15\fR/\fBarch13\fR,
*************** The default is \fB\-march=z900\fR.
*** 30033,30113 ****
  .Sp
  Specifying \fBnative\fR as cpu type can be used to select the best
  architecture option for the host processor.
! \&\fB\-march=native\fR has no effect if \s-1GCC\s0 does not recognize the
  processor.
! .IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
  .IX Item "-mtune=cpu-type"
! Tune to \fIcpu-type\fR everything applicable about the generated code,
! except for the \s-1ABI\s0 and the set of available instructions.
! The list of \fIcpu-type\fR values is the same as for \fB\-march\fR.
  The default is the value used for \fB\-march\fR.
! .IP "\fB\-mtpf\-trace\fR" 4
  .IX Item "-mtpf-trace"
  .PD 0
! .IP "\fB\-mno\-tpf\-trace\fR" 4
  .IX Item "-mno-tpf-trace"
  .PD
! Generate code that adds (does not add) in \s-1TPF OS\s0 specific branches to trace
  routines in the operating system.  This option is off by default, even
! when compiling for the \s-1TPF OS.\s0
! .IP "\fB\-mtpf\-trace\-skip\fR" 4
  .IX Item "-mtpf-trace-skip"
  .PD 0
! .IP "\fB\-mno\-tpf\-trace\-skip\fR" 4
  .IX Item "-mno-tpf-trace-skip"
  .PD
  Generate code that changes (does not change) the default branch
  targets enabled by \fB\-mtpf\-trace\fR to point to specialized trace
  routines providing the ability of selectively skipping function trace
! entries for the \s-1TPF OS.\s0  This option is off by default, even when
! compiling for the \s-1TPF OS\s0 and specifying \fB\-mtpf\-trace\fR.
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating-point multiply and
  accumulate instructions.  These instructions are generated by default if
  hardware floating point is used.
! .IP "\fB\-mwarn\-framesize=\fR\fIframesize\fR" 4
  .IX Item "-mwarn-framesize=framesize"
  Emit a warning if the current function exceeds the given frame size.  Because
! this is a compile-time check it doesn't need to be a real problem when the program
  runs.  It is intended to identify functions that most probably cause
  a stack overflow.  It is useful to be used in an environment with limited stack
  size e.g. the linux kernel.
! .IP "\fB\-mwarn\-dynamicstack\fR" 4
  .IX Item "-mwarn-dynamicstack"
! Emit a warning if the function calls \f(CW\*(C`alloca\*(C'\fR or uses dynamically-sized
  arrays.  This is generally a bad idea with a limited stack size.
! .IP "\fB\-mstack\-guard=\fR\fIstack-guard\fR" 4
  .IX Item "-mstack-guard=stack-guard"
  .PD 0
! .IP "\fB\-mstack\-size=\fR\fIstack-size\fR" 4
  .IX Item "-mstack-size=stack-size"
  .PD
  If these options are provided the S/390 back end emits additional instructions in
! the function prologue that trigger a trap if the stack size is \fIstack-guard\fR
! bytes above the \fIstack-size\fR (remember that the stack on S/390 grows downward).
! If the \fIstack-guard\fR option is omitted the smallest power of 2 larger than
  the frame size of the compiled function is chosen.
  These options are intended to be used to help debugging stack overflow problems.
  The additionally emitted code causes only little overhead and hence can also be
! used in production-like systems without greater performance degradation.  The given
! values have to be exact powers of 2 and \fIstack-size\fR has to be greater than
! \&\fIstack-guard\fR without exceeding 64k.
  In order to be efficient the extra code makes the assumption that the stack starts
! at an address aligned to the value given by \fIstack-size\fR.
! The \fIstack-guard\fR option can only be used in conjunction with \fIstack-size\fR.
! .IP "\fB\-mhotpatch=\fR\fIpre-halfwords\fR\fB,\fR\fIpost-halfwords\fR" 4
  .IX Item "-mhotpatch=pre-halfwords,post-halfwords"
! If the hotpatch option is enabled, a \*(L"hot-patching\*(R" function
  prologue is generated for all functions in the compilation unit.
! The funtion label is prepended with the given number of two-byte
! \&\s-1NOP\s0 instructions (\fIpre-halfwords\fR, maximum 1000000).  After
! the label, 2 * \fIpost-halfwords\fR bytes are appended, using the
! largest \s-1NOP\s0 like instructions the architecture allows (maximum
  1000000).
  .Sp
  If both arguments are zero, hotpatching is disabled.
--- 29964,30044 ----
  .Sp
  Specifying \fBnative\fR as cpu type can be used to select the best
  architecture option for the host processor.
! \&\fB\-march=native\fR has no effect if GCC does not recognize the
  processor.
! .IP \fB\-mtune=\fR\fIcpu\-type\fR 4
  .IX Item "-mtune=cpu-type"
! Tune to \fIcpu\-type\fR everything applicable about the generated code,
! except for the ABI and the set of available instructions.
! The list of \fIcpu\-type\fR values is the same as for \fB\-march\fR.
  The default is the value used for \fB\-march\fR.
! .IP \fB\-mtpf\-trace\fR 4
  .IX Item "-mtpf-trace"
  .PD 0
! .IP \fB\-mno\-tpf\-trace\fR 4
  .IX Item "-mno-tpf-trace"
  .PD
! Generate code that adds (does not add) in TPF OS specific branches to trace
  routines in the operating system.  This option is off by default, even
! when compiling for the TPF OS.
! .IP \fB\-mtpf\-trace\-skip\fR 4
  .IX Item "-mtpf-trace-skip"
  .PD 0
! .IP \fB\-mno\-tpf\-trace\-skip\fR 4
  .IX Item "-mno-tpf-trace-skip"
  .PD
  Generate code that changes (does not change) the default branch
  targets enabled by \fB\-mtpf\-trace\fR to point to specialized trace
  routines providing the ability of selectively skipping function trace
! entries for the TPF OS.  This option is off by default, even when
! compiling for the TPF OS and specifying \fB\-mtpf\-trace\fR.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating\-point multiply and
  accumulate instructions.  These instructions are generated by default if
  hardware floating point is used.
! .IP \fB\-mwarn\-framesize=\fR\fIframesize\fR 4
  .IX Item "-mwarn-framesize=framesize"
  Emit a warning if the current function exceeds the given frame size.  Because
! this is a compile\-time check it doesn\*(Aqt need to be a real problem when the program
  runs.  It is intended to identify functions that most probably cause
  a stack overflow.  It is useful to be used in an environment with limited stack
  size e.g. the linux kernel.
! .IP \fB\-mwarn\-dynamicstack\fR 4
  .IX Item "-mwarn-dynamicstack"
! Emit a warning if the function calls \f(CW\*(C`alloca\*(C'\fR or uses dynamically\-sized
  arrays.  This is generally a bad idea with a limited stack size.
! .IP \fB\-mstack\-guard=\fR\fIstack\-guard\fR 4
  .IX Item "-mstack-guard=stack-guard"
  .PD 0
! .IP \fB\-mstack\-size=\fR\fIstack\-size\fR 4
  .IX Item "-mstack-size=stack-size"
  .PD
  If these options are provided the S/390 back end emits additional instructions in
! the function prologue that trigger a trap if the stack size is \fIstack\-guard\fR
! bytes above the \fIstack\-size\fR (remember that the stack on S/390 grows downward).
! If the \fIstack\-guard\fR option is omitted the smallest power of 2 larger than
  the frame size of the compiled function is chosen.
  These options are intended to be used to help debugging stack overflow problems.
  The additionally emitted code causes only little overhead and hence can also be
! used in production\-like systems without greater performance degradation.  The given
! values have to be exact powers of 2 and \fIstack\-size\fR has to be greater than
! \&\fIstack\-guard\fR without exceeding 64k.
  In order to be efficient the extra code makes the assumption that the stack starts
! at an address aligned to the value given by \fIstack\-size\fR.
! The \fIstack\-guard\fR option can only be used in conjunction with \fIstack\-size\fR.
! .IP \fB\-mhotpatch=\fR\fIpre\-halfwords\fR\fB,\fR\fIpost\-halfwords\fR 4
  .IX Item "-mhotpatch=pre-halfwords,post-halfwords"
! If the hotpatch option is enabled, a "hot\-patching" function
  prologue is generated for all functions in the compilation unit.
! The funtion label is prepended with the given number of two\-byte
! NOP instructions (\fIpre\-halfwords\fR, maximum 1000000).  After
! the label, 2 * \fIpost\-halfwords\fR bytes are appended, using the
! largest NOP like instructions the architecture allows (maximum
  1000000).
  .Sp
  If both arguments are zero, hotpatching is disabled.
*************** If both arguments are zero, hotpatching
*** 30115,30292 ****
  This option can be overridden for individual functions with the
  \&\f(CW\*(C`hotpatch\*(C'\fR attribute.
  .PP
! \fI\s-1SH\s0 Options\fR
  .IX Subsection "SH Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1SH\s0 implementations:
! .IP "\fB\-m1\fR" 4
  .IX Item "-m1"
! Generate code for the \s-1SH1.\s0
! .IP "\fB\-m2\fR" 4
  .IX Item "-m2"
! Generate code for the \s-1SH2.\s0
! .IP "\fB\-m2e\fR" 4
  .IX Item "-m2e"
  Generate code for the SH2e.
! .IP "\fB\-m2a\-nofpu\fR" 4
  .IX Item "-m2a-nofpu"
! Generate code for the SH2a without \s-1FPU,\s0 or for a SH2a\-FPU in such a way
! that the floating-point unit is not used.
! .IP "\fB\-m2a\-single\-only\fR" 4
  .IX Item "-m2a-single-only"
! Generate code for the SH2a\-FPU, in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m2a\-single\fR" 4
  .IX Item "-m2a-single"
! Generate code for the SH2a\-FPU assuming the floating-point unit is in
! single-precision mode by default.
! .IP "\fB\-m2a\fR" 4
  .IX Item "-m2a"
! Generate code for the SH2a\-FPU assuming the floating-point unit is in
! double-precision mode by default.
! .IP "\fB\-m3\fR" 4
  .IX Item "-m3"
! Generate code for the \s-1SH3.\s0
! .IP "\fB\-m3e\fR" 4
  .IX Item "-m3e"
  Generate code for the SH3e.
! .IP "\fB\-m4\-nofpu\fR" 4
  .IX Item "-m4-nofpu"
! Generate code for the \s-1SH4\s0 without a floating-point unit.
! .IP "\fB\-m4\-single\-only\fR" 4
  .IX Item "-m4-single-only"
! Generate code for the \s-1SH4\s0 with a floating-point unit that only
! supports single-precision arithmetic.
! .IP "\fB\-m4\-single\fR" 4
  .IX Item "-m4-single"
! Generate code for the \s-1SH4\s0 assuming the floating-point unit is in
! single-precision mode by default.
! .IP "\fB\-m4\fR" 4
  .IX Item "-m4"
! Generate code for the \s-1SH4.\s0
! .IP "\fB\-m4\-100\fR" 4
  .IX Item "-m4-100"
! Generate code for \s-1SH4\-100.\s0
! .IP "\fB\-m4\-100\-nofpu\fR" 4
  .IX Item "-m4-100-nofpu"
! Generate code for \s-1SH4\-100\s0 in such a way that the
! floating-point unit is not used.
! .IP "\fB\-m4\-100\-single\fR" 4
  .IX Item "-m4-100-single"
! Generate code for \s-1SH4\-100\s0 assuming the floating-point unit is in
! single-precision mode by default.
! .IP "\fB\-m4\-100\-single\-only\fR" 4
  .IX Item "-m4-100-single-only"
! Generate code for \s-1SH4\-100\s0 in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m4\-200\fR" 4
  .IX Item "-m4-200"
! Generate code for \s-1SH4\-200.\s0
! .IP "\fB\-m4\-200\-nofpu\fR" 4
  .IX Item "-m4-200-nofpu"
! Generate code for \s-1SH4\-200\s0 without in such a way that the
! floating-point unit is not used.
! .IP "\fB\-m4\-200\-single\fR" 4
  .IX Item "-m4-200-single"
! Generate code for \s-1SH4\-200\s0 assuming the floating-point unit is in
! single-precision mode by default.
! .IP "\fB\-m4\-200\-single\-only\fR" 4
  .IX Item "-m4-200-single-only"
! Generate code for \s-1SH4\-200\s0 in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m4\-300\fR" 4
  .IX Item "-m4-300"
! Generate code for \s-1SH4\-300.\s0
! .IP "\fB\-m4\-300\-nofpu\fR" 4
  .IX Item "-m4-300-nofpu"
! Generate code for \s-1SH4\-300\s0 without in such a way that the
! floating-point unit is not used.
! .IP "\fB\-m4\-300\-single\fR" 4
  .IX Item "-m4-300-single"
! Generate code for \s-1SH4\-300\s0 in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m4\-300\-single\-only\fR" 4
  .IX Item "-m4-300-single-only"
! Generate code for \s-1SH4\-300\s0 in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m4\-340\fR" 4
  .IX Item "-m4-340"
! Generate code for \s-1SH4\-340\s0 (no \s-1MMU,\s0 no \s-1FPU\s0).
! .IP "\fB\-m4\-500\fR" 4
  .IX Item "-m4-500"
! Generate code for \s-1SH4\-500\s0 (no \s-1FPU\s0).  Passes \fB\-isa=sh4\-nofpu\fR to the
  assembler.
! .IP "\fB\-m4a\-nofpu\fR" 4
  .IX Item "-m4a-nofpu"
  Generate code for the SH4al\-dsp, or for a SH4a in such a way that the
! floating-point unit is not used.
! .IP "\fB\-m4a\-single\-only\fR" 4
  .IX Item "-m4a-single-only"
! Generate code for the SH4a, in such a way that no double-precision
! floating-point operations are used.
! .IP "\fB\-m4a\-single\fR" 4
  .IX Item "-m4a-single"
! Generate code for the SH4a assuming the floating-point unit is in
! single-precision mode by default.
! .IP "\fB\-m4a\fR" 4
  .IX Item "-m4a"
  Generate code for the SH4a.
! .IP "\fB\-m4al\fR" 4
  .IX Item "-m4al"
  Same as \fB\-m4a\-nofpu\fR, except that it implicitly passes
! \&\fB\-dsp\fR to the assembler.  \s-1GCC\s0 doesn't generate any \s-1DSP\s0
  instructions at the moment.
! .IP "\fB\-mb\fR" 4
  .IX Item "-mb"
! Compile code for the processor in big-endian mode.
! .IP "\fB\-ml\fR" 4
  .IX Item "-ml"
! Compile code for the processor in little-endian mode.
! .IP "\fB\-mdalign\fR" 4
  .IX Item "-mdalign"
  Align doubles at 64\-bit boundaries.  Note that this changes the calling
  conventions, and thus some functions from the standard C library do
  not work unless you recompile it first with \fB\-mdalign\fR.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  Shorten some address references at link time, when possible; uses the
  linker option \fB\-relax\fR.
! .IP "\fB\-mbigtable\fR" 4
  .IX Item "-mbigtable"
  Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables.  The default is to use
  16\-bit offsets.
! .IP "\fB\-mbitops\fR" 4
  .IX Item "-mbitops"
! Enable the use of bit manipulation instructions on \s-1SH2A.\s0
! .IP "\fB\-mfmovd\fR" 4
  .IX Item "-mfmovd"
  Enable the use of the instruction \f(CW\*(C`fmovd\*(C'\fR.  Check \fB\-mdalign\fR for
  alignment constraints.
! .IP "\fB\-mrenesas\fR" 4
  .IX Item "-mrenesas"
  Comply with the calling conventions defined by Renesas.
! .IP "\fB\-mno\-renesas\fR" 4
  .IX Item "-mno-renesas"
! Comply with the calling conventions defined for \s-1GCC\s0 before the Renesas
  conventions were available.  This option is the default for all
! targets of the \s-1SH\s0 toolchain.
! .IP "\fB\-mnomacsave\fR" 4
  .IX Item "-mnomacsave"
! Mark the \f(CW\*(C`MAC\*(C'\fR register as call-clobbered, even if
  \&\fB\-mrenesas\fR is given.
! .IP "\fB\-mieee\fR" 4
  .IX Item "-mieee"
  .PD 0
! .IP "\fB\-mno\-ieee\fR" 4
  .IX Item "-mno-ieee"
  .PD
! Control the \s-1IEEE\s0 compliance of floating-point comparisons, which affects the
  handling of cases where the result of a comparison is unordered.  By default
  \&\fB\-mieee\fR is implicitly enabled.  If \fB\-ffinite\-math\-only\fR is
  enabled \fB\-mno\-ieee\fR is implicitly set, which results in faster
! floating-point greater-equal and less-equal comparisons.  The implicit settings
  can be overridden by specifying either \fB\-mieee\fR or \fB\-mno\-ieee\fR.
! .IP "\fB\-minline\-ic_invalidate\fR" 4
  .IX Item "-minline-ic_invalidate"
  Inline code to invalidate instruction cache entries after setting up
  nested function trampolines.
--- 30046,30223 ----
  This option can be overridden for individual functions with the
  \&\f(CW\*(C`hotpatch\*(C'\fR attribute.
  .PP
! \fISH Options\fR
  .IX Subsection "SH Options"
  .PP
! These \fB\-m\fR options are defined for the SH implementations:
! .IP \fB\-m1\fR 4
  .IX Item "-m1"
! Generate code for the SH1.
! .IP \fB\-m2\fR 4
  .IX Item "-m2"
! Generate code for the SH2.
! .IP \fB\-m2e\fR 4
  .IX Item "-m2e"
  Generate code for the SH2e.
! .IP \fB\-m2a\-nofpu\fR 4
  .IX Item "-m2a-nofpu"
! Generate code for the SH2a without FPU, or for a SH2a\-FPU in such a way
! that the floating\-point unit is not used.
! .IP \fB\-m2a\-single\-only\fR 4
  .IX Item "-m2a-single-only"
! Generate code for the SH2a\-FPU, in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m2a\-single\fR 4
  .IX Item "-m2a-single"
! Generate code for the SH2a\-FPU assuming the floating\-point unit is in
! single\-precision mode by default.
! .IP \fB\-m2a\fR 4
  .IX Item "-m2a"
! Generate code for the SH2a\-FPU assuming the floating\-point unit is in
! double\-precision mode by default.
! .IP \fB\-m3\fR 4
  .IX Item "-m3"
! Generate code for the SH3.
! .IP \fB\-m3e\fR 4
  .IX Item "-m3e"
  Generate code for the SH3e.
! .IP \fB\-m4\-nofpu\fR 4
  .IX Item "-m4-nofpu"
! Generate code for the SH4 without a floating\-point unit.
! .IP \fB\-m4\-single\-only\fR 4
  .IX Item "-m4-single-only"
! Generate code for the SH4 with a floating\-point unit that only
! supports single\-precision arithmetic.
! .IP \fB\-m4\-single\fR 4
  .IX Item "-m4-single"
! Generate code for the SH4 assuming the floating\-point unit is in
! single\-precision mode by default.
! .IP \fB\-m4\fR 4
  .IX Item "-m4"
! Generate code for the SH4.
! .IP \fB\-m4\-100\fR 4
  .IX Item "-m4-100"
! Generate code for SH4\-100.
! .IP \fB\-m4\-100\-nofpu\fR 4
  .IX Item "-m4-100-nofpu"
! Generate code for SH4\-100 in such a way that the
! floating\-point unit is not used.
! .IP \fB\-m4\-100\-single\fR 4
  .IX Item "-m4-100-single"
! Generate code for SH4\-100 assuming the floating\-point unit is in
! single\-precision mode by default.
! .IP \fB\-m4\-100\-single\-only\fR 4
  .IX Item "-m4-100-single-only"
! Generate code for SH4\-100 in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m4\-200\fR 4
  .IX Item "-m4-200"
! Generate code for SH4\-200.
! .IP \fB\-m4\-200\-nofpu\fR 4
  .IX Item "-m4-200-nofpu"
! Generate code for SH4\-200 without in such a way that the
! floating\-point unit is not used.
! .IP \fB\-m4\-200\-single\fR 4
  .IX Item "-m4-200-single"
! Generate code for SH4\-200 assuming the floating\-point unit is in
! single\-precision mode by default.
! .IP \fB\-m4\-200\-single\-only\fR 4
  .IX Item "-m4-200-single-only"
! Generate code for SH4\-200 in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m4\-300\fR 4
  .IX Item "-m4-300"
! Generate code for SH4\-300.
! .IP \fB\-m4\-300\-nofpu\fR 4
  .IX Item "-m4-300-nofpu"
! Generate code for SH4\-300 without in such a way that the
! floating\-point unit is not used.
! .IP \fB\-m4\-300\-single\fR 4
  .IX Item "-m4-300-single"
! Generate code for SH4\-300 in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m4\-300\-single\-only\fR 4
  .IX Item "-m4-300-single-only"
! Generate code for SH4\-300 in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m4\-340\fR 4
  .IX Item "-m4-340"
! Generate code for SH4\-340 (no MMU, no FPU).
! .IP \fB\-m4\-500\fR 4
  .IX Item "-m4-500"
! Generate code for SH4\-500 (no FPU).  Passes \fB\-isa=sh4\-nofpu\fR to the
  assembler.
! .IP \fB\-m4a\-nofpu\fR 4
  .IX Item "-m4a-nofpu"
  Generate code for the SH4al\-dsp, or for a SH4a in such a way that the
! floating\-point unit is not used.
! .IP \fB\-m4a\-single\-only\fR 4
  .IX Item "-m4a-single-only"
! Generate code for the SH4a, in such a way that no double\-precision
! floating\-point operations are used.
! .IP \fB\-m4a\-single\fR 4
  .IX Item "-m4a-single"
! Generate code for the SH4a assuming the floating\-point unit is in
! single\-precision mode by default.
! .IP \fB\-m4a\fR 4
  .IX Item "-m4a"
  Generate code for the SH4a.
! .IP \fB\-m4al\fR 4
  .IX Item "-m4al"
  Same as \fB\-m4a\-nofpu\fR, except that it implicitly passes
! \&\fB\-dsp\fR to the assembler.  GCC doesn\*(Aqt generate any DSP
  instructions at the moment.
! .IP \fB\-mb\fR 4
  .IX Item "-mb"
! Compile code for the processor in big\-endian mode.
! .IP \fB\-ml\fR 4
  .IX Item "-ml"
! Compile code for the processor in little\-endian mode.
! .IP \fB\-mdalign\fR 4
  .IX Item "-mdalign"
  Align doubles at 64\-bit boundaries.  Note that this changes the calling
  conventions, and thus some functions from the standard C library do
  not work unless you recompile it first with \fB\-mdalign\fR.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  Shorten some address references at link time, when possible; uses the
  linker option \fB\-relax\fR.
! .IP \fB\-mbigtable\fR 4
  .IX Item "-mbigtable"
  Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables.  The default is to use
  16\-bit offsets.
! .IP \fB\-mbitops\fR 4
  .IX Item "-mbitops"
! Enable the use of bit manipulation instructions on SH2A.
! .IP \fB\-mfmovd\fR 4
  .IX Item "-mfmovd"
  Enable the use of the instruction \f(CW\*(C`fmovd\*(C'\fR.  Check \fB\-mdalign\fR for
  alignment constraints.
! .IP \fB\-mrenesas\fR 4
  .IX Item "-mrenesas"
  Comply with the calling conventions defined by Renesas.
! .IP \fB\-mno\-renesas\fR 4
  .IX Item "-mno-renesas"
! Comply with the calling conventions defined for GCC before the Renesas
  conventions were available.  This option is the default for all
! targets of the SH toolchain.
! .IP \fB\-mnomacsave\fR 4
  .IX Item "-mnomacsave"
! Mark the \f(CW\*(C`MAC\*(C'\fR register as call\-clobbered, even if
  \&\fB\-mrenesas\fR is given.
! .IP \fB\-mieee\fR 4
  .IX Item "-mieee"
  .PD 0
! .IP \fB\-mno\-ieee\fR 4
  .IX Item "-mno-ieee"
  .PD
! Control the IEEE compliance of floating\-point comparisons, which affects the
  handling of cases where the result of a comparison is unordered.  By default
  \&\fB\-mieee\fR is implicitly enabled.  If \fB\-ffinite\-math\-only\fR is
  enabled \fB\-mno\-ieee\fR is implicitly set, which results in faster
! floating\-point greater\-equal and less\-equal comparisons.  The implicit settings
  can be overridden by specifying either \fB\-mieee\fR or \fB\-mno\-ieee\fR.
! .IP \fB\-minline\-ic_invalidate\fR 4
  .IX Item "-minline-ic_invalidate"
  Inline code to invalidate instruction cache entries after setting up
  nested function trampolines.
*************** If the selected code generation option d
*** 30297,30364 ****
  instruction, and \fB\-musermode\fR is not in effect, the inlined code
  manipulates the instruction cache address array directly with an associative
  write.  This not only requires privileged mode at run time, but it also
! fails if the cache line had been mapped via the \s-1TLB\s0 and has become unmapped.
! .IP "\fB\-misize\fR" 4
  .IX Item "-misize"
  Dump instruction size and location in the assembly code.
! .IP "\fB\-mpadstruct\fR" 4
  .IX Item "-mpadstruct"
  This option is deprecated.  It pads structures to multiple of 4 bytes,
! which is incompatible with the \s-1SH ABI.\s0
! .IP "\fB\-matomic\-model=\fR\fImodel\fR" 4
  .IX Item "-matomic-model=model"
  Sets the model of atomic operations and additional parameters as a comma
! separated list.  For details on the atomic built-in functions see
  \&\fB_\|_atomic Builtins\fR.  The following models and parameters are supported:
  .RS 4
! .IP "\fBnone\fR" 4
  .IX Item "none"
  Disable compiler generated atomic sequences and emit library calls for atomic
  operations.  This is the default if the target is not \f(CW\*(C`sh*\-*\-linux*\*(C'\fR.
! .IP "\fBsoft-gusa\fR" 4
  .IX Item "soft-gusa"
  Generate GNU/Linux compatible gUSA software atomic sequences for the atomic
! built-in functions.  The generated atomic sequences require additional support
  from the interrupt/exception handling code of the system and are only suitable
! for SH3* and SH4* single-core systems.  This option is enabled by default when
! the target is \f(CW\*(C`sh*\-*\-linux*\*(C'\fR and SH3* or SH4*.  When the target is \s-1SH4A,\s0
  this option also partially utilizes the hardware atomic instructions
  \&\f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR to create more efficient code, unless
  \&\fBstrict\fR is specified.
! .IP "\fBsoft-tcb\fR" 4
  .IX Item "soft-tcb"
  Generate software atomic sequences that use a variable in the thread control
  block.  This is a variation of the gUSA sequences which can also be used on
  SH1* and SH2* targets.  The generated atomic sequences require additional
  support from the interrupt/exception handling code of the system and are only
! suitable for single-core systems.  When using this model, the \fBgbr\-offset=\fR
  parameter has to be specified as well.
! .IP "\fBsoft-imask\fR" 4
  .IX Item "soft-imask"
  Generate software atomic sequences that temporarily disable interrupts by
  setting \f(CW\*(C`SR.IMASK = 1111\*(C'\fR.  This model works only when the program runs
! in privileged mode and is only suitable for single-core systems.  Additional
  support from the interrupt/exception handling code of the system is not
  required.  This model is enabled by default when the target is
  \&\f(CW\*(C`sh*\-*\-linux*\*(C'\fR and SH1* or SH2*.
! .IP "\fBhard-llcs\fR" 4
  .IX Item "hard-llcs"
  Generate hardware atomic sequences using the \f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR
! instructions only.  This is only available on \s-1SH4A\s0 and is suitable for
! multi-core systems.  Since the hardware instructions support only 32 bit atomic
  variables access to 8 or 16 bit variables is emulated with 32 bit accesses.
  Code compiled with this option is also compatible with other software
! atomic model interrupt/exception handling systems if executed on an \s-1SH4A\s0
  system.  Additional support from the interrupt/exception handling code of the
  system is not required for this model.
! .IP "\fBgbr\-offset=\fR" 4
  .IX Item "gbr-offset="
  This parameter specifies the offset in bytes of the variable in the thread
  control block structure that should be used by the generated atomic sequences
! when the \fBsoft-tcb\fR model has been selected.  For other models this
  parameter is ignored.  The specified value must be an integer multiple of four
  and in the range 0\-1020.
! .IP "\fBstrict\fR" 4
  .IX Item "strict"
  This parameter prevents mixed usage of multiple atomic models, even if they
  are compatible, and makes the compiler generate atomic sequences of the
--- 30228,30295 ----
  instruction, and \fB\-musermode\fR is not in effect, the inlined code
  manipulates the instruction cache address array directly with an associative
  write.  This not only requires privileged mode at run time, but it also
! fails if the cache line had been mapped via the TLB and has become unmapped.
! .IP \fB\-misize\fR 4
  .IX Item "-misize"
  Dump instruction size and location in the assembly code.
! .IP \fB\-mpadstruct\fR 4
  .IX Item "-mpadstruct"
  This option is deprecated.  It pads structures to multiple of 4 bytes,
! which is incompatible with the SH ABI.
! .IP \fB\-matomic\-model=\fR\fImodel\fR 4
  .IX Item "-matomic-model=model"
  Sets the model of atomic operations and additional parameters as a comma
! separated list.  For details on the atomic built\-in functions see
  \&\fB_\|_atomic Builtins\fR.  The following models and parameters are supported:
  .RS 4
! .IP \fBnone\fR 4
  .IX Item "none"
  Disable compiler generated atomic sequences and emit library calls for atomic
  operations.  This is the default if the target is not \f(CW\*(C`sh*\-*\-linux*\*(C'\fR.
! .IP \fBsoft\-gusa\fR 4
  .IX Item "soft-gusa"
  Generate GNU/Linux compatible gUSA software atomic sequences for the atomic
! built\-in functions.  The generated atomic sequences require additional support
  from the interrupt/exception handling code of the system and are only suitable
! for SH3* and SH4* single\-core systems.  This option is enabled by default when
! the target is \f(CW\*(C`sh*\-*\-linux*\*(C'\fR and SH3* or SH4*.  When the target is SH4A,
  this option also partially utilizes the hardware atomic instructions
  \&\f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR to create more efficient code, unless
  \&\fBstrict\fR is specified.
! .IP \fBsoft\-tcb\fR 4
  .IX Item "soft-tcb"
  Generate software atomic sequences that use a variable in the thread control
  block.  This is a variation of the gUSA sequences which can also be used on
  SH1* and SH2* targets.  The generated atomic sequences require additional
  support from the interrupt/exception handling code of the system and are only
! suitable for single\-core systems.  When using this model, the \fBgbr\-offset=\fR
  parameter has to be specified as well.
! .IP \fBsoft\-imask\fR 4
  .IX Item "soft-imask"
  Generate software atomic sequences that temporarily disable interrupts by
  setting \f(CW\*(C`SR.IMASK = 1111\*(C'\fR.  This model works only when the program runs
! in privileged mode and is only suitable for single\-core systems.  Additional
  support from the interrupt/exception handling code of the system is not
  required.  This model is enabled by default when the target is
  \&\f(CW\*(C`sh*\-*\-linux*\*(C'\fR and SH1* or SH2*.
! .IP \fBhard\-llcs\fR 4
  .IX Item "hard-llcs"
  Generate hardware atomic sequences using the \f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR
! instructions only.  This is only available on SH4A and is suitable for
! multi\-core systems.  Since the hardware instructions support only 32 bit atomic
  variables access to 8 or 16 bit variables is emulated with 32 bit accesses.
  Code compiled with this option is also compatible with other software
! atomic model interrupt/exception handling systems if executed on an SH4A
  system.  Additional support from the interrupt/exception handling code of the
  system is not required for this model.
! .IP \fBgbr\-offset=\fR 4
  .IX Item "gbr-offset="
  This parameter specifies the offset in bytes of the variable in the thread
  control block structure that should be used by the generated atomic sequences
! when the \fBsoft\-tcb\fR model has been selected.  For other models this
  parameter is ignored.  The specified value must be an integer multiple of four
  and in the range 0\-1020.
! .IP \fBstrict\fR 4
  .IX Item "strict"
  This parameter prevents mixed usage of multiple atomic models, even if they
  are compatible, and makes the compiler generate atomic sequences of the
*************** specified model only.
*** 30366,30677 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-mtas\fR" 4
  .IX Item "-mtas"
  Generate the \f(CW\*(C`tas.b\*(C'\fR opcode for \f(CW\*(C`_\|_atomic_test_and_set\*(C'\fR.
  Notice that depending on the particular hardware and software configuration
  this can degrade overall performance due to the operand cache line flushes
! that are implied by the \f(CW\*(C`tas.b\*(C'\fR instruction.  On multi-core \s-1SH4A\s0
  processors the \f(CW\*(C`tas.b\*(C'\fR instruction must be used with caution since it
  can result in data corruption for certain cache configurations.
! .IP "\fB\-mprefergot\fR" 4
  .IX Item "-mprefergot"
! When generating position-independent code, emit function calls using
  the Global Offset Table instead of the Procedure Linkage Table.
! .IP "\fB\-musermode\fR" 4
  .IX Item "-musermode"
  .PD 0
! .IP "\fB\-mno\-usermode\fR" 4
  .IX Item "-mno-usermode"
  .PD
! Don't allow (allow) the compiler generating privileged mode code.  Specifying
  \&\fB\-musermode\fR also implies \fB\-mno\-inline\-ic_invalidate\fR if the
  inlined code would not work in user mode.  \fB\-musermode\fR is the default
  when the target is \f(CW\*(C`sh*\-*\-linux*\*(C'\fR.  If the target is SH1* or SH2*
  \&\fB\-musermode\fR has no effect, since there is no user mode.
! .IP "\fB\-multcost=\fR\fInumber\fR" 4
  .IX Item "-multcost=number"
  Set the cost to assume for a multiply insn.
! .IP "\fB\-mdiv=\fR\fIstrategy\fR" 4
  .IX Item "-mdiv=strategy"
  Set the division strategy to be used for integer division operations.
  \&\fIstrategy\fR can be one of:
  .RS 4
! .IP "\fBcall\-div1\fR" 4
  .IX Item "call-div1"
! Calls a library function that uses the single-step division instruction
  \&\f(CW\*(C`div1\*(C'\fR to perform the operation.  Division by zero calculates an
! unspecified result and does not trap.  This is the default except for \s-1SH4,
! SH2A\s0 and SHcompact.
! .IP "\fBcall-fp\fR" 4
  .IX Item "call-fp"
  Calls a library function that performs the operation in double precision
! floating point.  Division by zero causes a floating-point exception.  This is
! the default for SHcompact with \s-1FPU.\s0  Specifying this for targets that do not
! have a double precision \s-1FPU\s0 defaults to \f(CW\*(C`call\-div1\*(C'\fR.
! .IP "\fBcall-table\fR" 4
  .IX Item "call-table"
  Calls a library function that uses a lookup table for small divisors and
  the \f(CW\*(C`div1\*(C'\fR instruction with case distinction for larger divisors.  Division
  by zero calculates an unspecified result and does not trap.  This is the default
! for \s-1SH4.\s0  Specifying this for targets that do not have dynamic shift
  instructions defaults to \f(CW\*(C`call\-div1\*(C'\fR.
  .RE
  .RS 4
  .Sp
  When a division strategy has not been specified the default strategy is
! selected based on the current target.  For \s-1SH2A\s0 the default strategy is to
  use the \f(CW\*(C`divs\*(C'\fR and \f(CW\*(C`divu\*(C'\fR instructions instead of library function
  calls.
  .RE
! .IP "\fB\-maccumulate\-outgoing\-args\fR" 4
  .IX Item "-maccumulate-outgoing-args"
  Reserve space once for outgoing arguments in the function prologue rather
  than around each call.  Generally beneficial for performance and size.  Also
  needed for unwinding to avoid changing the stack frame around conditional code.
! .IP "\fB\-mdivsi3_libfunc=\fR\fIname\fR" 4
  .IX Item "-mdivsi3_libfunc=name"
  Set the name of the library function used for 32\-bit signed division to
  \&\fIname\fR.
  This only affects the name used in the \fBcall\fR division strategies, and
  the compiler still expects the same sets of input/output/clobbered registers as
  if this option were not present.
! .IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP "\fB\-mbranch\-cost=\fR\fInum\fR" 4
  .IX Item "-mbranch-cost=num"
  Assume \fInum\fR to be the cost for a branch instruction.  Higher numbers
! make the compiler try to generate more branch-free code if possible.  
  If not specified the value is selected depending on the processor type that
  is being compiled for.
! .IP "\fB\-mzdcbranch\fR" 4
  .IX Item "-mzdcbranch"
  .PD 0
! .IP "\fB\-mno\-zdcbranch\fR" 4
  .IX Item "-mno-zdcbranch"
  .PD
  Assume (do not assume) that zero displacement conditional branch instructions
  \&\f(CW\*(C`bt\*(C'\fR and \f(CW\*(C`bf\*(C'\fR are fast.  If \fB\-mzdcbranch\fR is specified, the
  compiler prefers zero displacement branch code sequences.  This is
! enabled by default when generating code for \s-1SH4\s0 and \s-1SH4A.\s0  It can be explicitly
  disabled by specifying \fB\-mno\-zdcbranch\fR.
! .IP "\fB\-mcbranch\-force\-delay\-slot\fR" 4
  .IX Item "-mcbranch-force-delay-slot"
  Force the usage of delay slots for conditional branches, which stuffs the delay
  slot with a \f(CW\*(C`nop\*(C'\fR if a suitable instruction cannot be found.  By default
  this option is disabled.  It can be enabled to work around hardware bugs as
! found in the original \s-1SH7055.\s0
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating-point multiply and
  accumulate instructions.  These instructions are generated by default
! if hardware floating point is used.  The machine-dependent
! \&\fB\-mfused\-madd\fR option is now mapped to the machine-independent
  \&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
  mapped to \fB\-ffp\-contract=off\fR.
! .IP "\fB\-mfsca\fR" 4
  .IX Item "-mfsca"
  .PD 0
! .IP "\fB\-mno\-fsca\fR" 4
  .IX Item "-mno-fsca"
  .PD
  Allow or disallow the compiler to emit the \f(CW\*(C`fsca\*(C'\fR instruction for sine
  and cosine approximations.  The option \fB\-mfsca\fR must be used in
  combination with \fB\-funsafe\-math\-optimizations\fR.  It is enabled by default
! when generating code for \s-1SH4A.\s0  Using \fB\-mno\-fsca\fR disables sine and cosine
  approximations even if \fB\-funsafe\-math\-optimizations\fR is in effect.
! .IP "\fB\-mfsrra\fR" 4
  .IX Item "-mfsrra"
  .PD 0
! .IP "\fB\-mno\-fsrra\fR" 4
  .IX Item "-mno-fsrra"
  .PD
  Allow or disallow the compiler to emit the \f(CW\*(C`fsrra\*(C'\fR instruction for
  reciprocal square root approximations.  The option \fB\-mfsrra\fR must be used
  in combination with \fB\-funsafe\-math\-optimizations\fR and
  \&\fB\-ffinite\-math\-only\fR.  It is enabled by default when generating code for
! \&\s-1SH4A.\s0  Using \fB\-mno\-fsrra\fR disables reciprocal square root approximations
  even if \fB\-funsafe\-math\-optimizations\fR and \fB\-ffinite\-math\-only\fR are
  in effect.
! .IP "\fB\-mpretend\-cmove\fR" 4
  .IX Item "-mpretend-cmove"
! Prefer zero-displacement conditional branches for conditional move instruction
! patterns.  This can result in faster code on the \s-1SH4\s0 processor.
! .IP "\fB\-mfdpic\fR" 4
  .IX Item "-mfdpic"
! Generate code using the \s-1FDPIC ABI.\s0
  .PP
  \fISolaris 2 Options\fR
  .IX Subsection "Solaris 2 Options"
  .PP
  These \fB\-m\fR options are supported on Solaris 2:
! .IP "\fB\-mclear\-hwcap\fR" 4
  .IX Item "-mclear-hwcap"
  \&\fB\-mclear\-hwcap\fR tells the compiler to remove the hardware
  capabilities generated by the Solaris assembler.  This is only necessary
! when object files use \s-1ISA\s0 extensions not supported by the current
  machine, but check at runtime whether or not to use them.
! .IP "\fB\-mimpure\-text\fR" 4
  .IX Item "-mimpure-text"
  \&\fB\-mimpure\-text\fR, used in addition to \fB\-shared\fR, tells
  the compiler to not pass \fB\-z text\fR to the linker when linking a
! shared object.  Using this option, you can link position-dependent
  code into a shared object.
  .Sp
! \&\fB\-mimpure\-text\fR suppresses the \*(L"relocations remain against
! allocatable but non-writable sections\*(R" linker error message.
! However, the necessary relocations trigger copy-on-write, and the
  shared object is not actually shared across processes.  Instead of
  using \fB\-mimpure\-text\fR, you should compile all source code with
  \&\fB\-fpic\fR or \fB\-fPIC\fR.
  .PP
  These switches are supported in addition to the above on Solaris 2:
! .IP "\fB\-pthreads\fR" 4
  .IX Item "-pthreads"
  This is a synonym for \fB\-pthread\fR.
  .PP
! \fI\s-1SPARC\s0 Options\fR
  .IX Subsection "SPARC Options"
  .PP
! These \fB\-m\fR options are supported on the \s-1SPARC:\s0
! .IP "\fB\-mno\-app\-regs\fR" 4
  .IX Item "-mno-app-regs"
  .PD 0
! .IP "\fB\-mapp\-regs\fR" 4
  .IX Item "-mapp-regs"
  .PD
  Specify \fB\-mapp\-regs\fR to generate output using the global registers
! 2 through 4, which the \s-1SPARC SVR4 ABI\s0 reserves for applications.  Like the
  global register 1, each global register 2 through 4 is then treated as an
  allocable register that is clobbered by function calls.  This is the default.
  .Sp
! To be fully \s-1SVR4\s0 ABI-compliant at the cost of some performance loss,
  specify \fB\-mno\-app\-regs\fR.  You should compile libraries and system
  software with this option.
! .IP "\fB\-mflat\fR" 4
  .IX Item "-mflat"
  .PD 0
! .IP "\fB\-mno\-flat\fR" 4
  .IX Item "-mno-flat"
  .PD
  With \fB\-mflat\fR, the compiler does not generate save/restore instructions
! and uses a \*(L"flat\*(R" or single register window model.  This model is compatible
  with the regular register window model.  The local registers and the input
! registers (0\-\-5) are still treated as \*(L"call-saved\*(R" registers and are
  saved on the stack as needed.
  .Sp
  With \fB\-mno\-flat\fR (the default), the compiler generates save/restore
  instructions (except for leaf functions).  This is the normal operating mode.
! .IP "\fB\-mfpu\fR" 4
  .IX Item "-mfpu"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
! Generate output containing floating-point instructions.  This is the
  default.
! .IP "\fB\-mno\-fpu\fR" 4
  .IX Item "-mno-fpu"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
  Generate output containing library calls for floating point.
! \&\fBWarning:\fR the requisite libraries are not available for all \s-1SPARC\s0
! targets.  Normally the facilities of the machine's usual C compiler are
! used, but this cannot be done directly in cross-compilation.  You must make
  your own arrangements to provide suitable library functions for
! cross-compilation.  The embedded targets \fBsparc\-*\-aout\fR and
! \&\fBsparclite\-*\-*\fR do provide software floating-point support.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with \s-1GCC,\s0 with \fB\-msoft\-float\fR in order for
  this to work.
! .IP "\fB\-mhard\-quad\-float\fR" 4
  .IX Item "-mhard-quad-float"
! Generate output containing quad-word (long double) floating-point
  instructions.
! .IP "\fB\-msoft\-quad\-float\fR" 4
  .IX Item "-msoft-quad-float"
! Generate output containing library calls for quad-word (long double)
! floating-point instructions.  The functions called are those specified
! in the \s-1SPARC ABI.\s0  This is the default.
  .Sp
! As of this writing, there are no \s-1SPARC\s0 implementations that have hardware
! support for the quad-word floating-point instructions.  They all invoke
  a trap handler for one of these instructions, and then the trap handler
  emulates the effect of the instruction.  Because of the trap handler overhead,
! this is much slower than calling the \s-1ABI\s0 library routines.  Thus the
  \&\fB\-msoft\-quad\-float\fR option is the default.
! .IP "\fB\-mno\-unaligned\-doubles\fR" 4
  .IX Item "-mno-unaligned-doubles"
  .PD 0
! .IP "\fB\-munaligned\-doubles\fR" 4
  .IX Item "-munaligned-doubles"
  .PD
  Assume that doubles have 8\-byte alignment.  This is the default.
  .Sp
! With \fB\-munaligned\-doubles\fR, \s-1GCC\s0 assumes that doubles have 8\-byte
  alignment only if they are contained in another type, or if they have an
  absolute address.  Otherwise, it assumes they have 4\-byte alignment.
  Specifying this option avoids some rare compatibility problems with code
  generated by other compilers.  It is not the default because it results
! in a performance loss, especially for floating-point code.
! .IP "\fB\-muser\-mode\fR" 4
  .IX Item "-muser-mode"
  .PD 0
! .IP "\fB\-mno\-user\-mode\fR" 4
  .IX Item "-mno-user-mode"
  .PD
  Do not generate code that can only run in supervisor mode.  This is relevant
! only for the \f(CW\*(C`casa\*(C'\fR instruction emitted for the \s-1LEON3\s0 processor.  This
  is the default.
! .IP "\fB\-mfaster\-structs\fR" 4
  .IX Item "-mfaster-structs"
  .PD 0
! .IP "\fB\-mno\-faster\-structs\fR" 4
  .IX Item "-mno-faster-structs"
  .PD
  With \fB\-mfaster\-structs\fR, the compiler assumes that structures
  should have 8\-byte alignment.  This enables the use of pairs of
  \&\f(CW\*(C`ldd\*(C'\fR and \f(CW\*(C`std\*(C'\fR instructions for copies in structure
  assignment, in place of twice as many \f(CW\*(C`ld\*(C'\fR and \f(CW\*(C`st\*(C'\fR pairs.
! However, the use of this changed alignment directly violates the \s-1SPARC
! ABI.\s0  Thus, it's intended only for use on targets where the developer
  acknowledges that their resulting code is not directly in line with
! the rules of the \s-1ABI.\s0
! .IP "\fB\-mstd\-struct\-return\fR" 4
  .IX Item "-mstd-struct-return"
  .PD 0
! .IP "\fB\-mno\-std\-struct\-return\fR" 4
  .IX Item "-mno-std-struct-return"
  .PD
  With \fB\-mstd\-struct\-return\fR, the compiler generates checking code
  in functions returning structures or unions to detect size mismatches
! between the two sides of function calls, as per the 32\-bit \s-1ABI.\s0
  .Sp
  The default is \fB\-mno\-std\-struct\-return\fR.  This option has no effect
  in 64\-bit mode.
! .IP "\fB\-mlra\fR" 4
  .IX Item "-mlra"
  .PD 0
! .IP "\fB\-mno\-lra\fR" 4
  .IX Item "-mno-lra"
  .PD
! Enable Local Register Allocation.  This is the default for \s-1SPARC\s0 since \s-1GCC 7\s0
  so \fB\-mno\-lra\fR needs to be passed to get old Reload.
! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set, register set, and instruction scheduling parameters
  for machine type \fIcpu_type\fR.  Supported values for \fIcpu_type\fR are
--- 30297,30608 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-mtas\fR 4
  .IX Item "-mtas"
  Generate the \f(CW\*(C`tas.b\*(C'\fR opcode for \f(CW\*(C`_\|_atomic_test_and_set\*(C'\fR.
  Notice that depending on the particular hardware and software configuration
  this can degrade overall performance due to the operand cache line flushes
! that are implied by the \f(CW\*(C`tas.b\*(C'\fR instruction.  On multi\-core SH4A
  processors the \f(CW\*(C`tas.b\*(C'\fR instruction must be used with caution since it
  can result in data corruption for certain cache configurations.
! .IP \fB\-mprefergot\fR 4
  .IX Item "-mprefergot"
! When generating position\-independent code, emit function calls using
  the Global Offset Table instead of the Procedure Linkage Table.
! .IP \fB\-musermode\fR 4
  .IX Item "-musermode"
  .PD 0
! .IP \fB\-mno\-usermode\fR 4
  .IX Item "-mno-usermode"
  .PD
! Don\*(Aqt allow (allow) the compiler generating privileged mode code.  Specifying
  \&\fB\-musermode\fR also implies \fB\-mno\-inline\-ic_invalidate\fR if the
  inlined code would not work in user mode.  \fB\-musermode\fR is the default
  when the target is \f(CW\*(C`sh*\-*\-linux*\*(C'\fR.  If the target is SH1* or SH2*
  \&\fB\-musermode\fR has no effect, since there is no user mode.
! .IP \fB\-multcost=\fR\fInumber\fR 4
  .IX Item "-multcost=number"
  Set the cost to assume for a multiply insn.
! .IP \fB\-mdiv=\fR\fIstrategy\fR 4
  .IX Item "-mdiv=strategy"
  Set the division strategy to be used for integer division operations.
  \&\fIstrategy\fR can be one of:
  .RS 4
! .IP \fBcall\-div1\fR 4
  .IX Item "call-div1"
! Calls a library function that uses the single\-step division instruction
  \&\f(CW\*(C`div1\*(C'\fR to perform the operation.  Division by zero calculates an
! unspecified result and does not trap.  This is the default except for SH4,
! SH2A and SHcompact.
! .IP \fBcall\-fp\fR 4
  .IX Item "call-fp"
  Calls a library function that performs the operation in double precision
! floating point.  Division by zero causes a floating\-point exception.  This is
! the default for SHcompact with FPU.  Specifying this for targets that do not
! have a double precision FPU defaults to \f(CW\*(C`call\-div1\*(C'\fR.
! .IP \fBcall\-table\fR 4
  .IX Item "call-table"
  Calls a library function that uses a lookup table for small divisors and
  the \f(CW\*(C`div1\*(C'\fR instruction with case distinction for larger divisors.  Division
  by zero calculates an unspecified result and does not trap.  This is the default
! for SH4.  Specifying this for targets that do not have dynamic shift
  instructions defaults to \f(CW\*(C`call\-div1\*(C'\fR.
  .RE
  .RS 4
  .Sp
  When a division strategy has not been specified the default strategy is
! selected based on the current target.  For SH2A the default strategy is to
  use the \f(CW\*(C`divs\*(C'\fR and \f(CW\*(C`divu\*(C'\fR instructions instead of library function
  calls.
  .RE
! .IP \fB\-maccumulate\-outgoing\-args\fR 4
  .IX Item "-maccumulate-outgoing-args"
  Reserve space once for outgoing arguments in the function prologue rather
  than around each call.  Generally beneficial for performance and size.  Also
  needed for unwinding to avoid changing the stack frame around conditional code.
! .IP \fB\-mdivsi3_libfunc=\fR\fIname\fR 4
  .IX Item "-mdivsi3_libfunc=name"
  Set the name of the library function used for 32\-bit signed division to
  \&\fIname\fR.
  This only affects the name used in the \fBcall\fR division strategies, and
  the compiler still expects the same sets of input/output/clobbered registers as
  if this option were not present.
! .IP \fB\-mfixed\-range=\fR\fIregister\-range\fR 4
  .IX Item "-mfixed-range=register-range"
  Generate code treating the given register range as fixed registers.
  A fixed register is one that the register allocator cannot use.  This is
  useful when compiling kernel code.  A register range is specified as
  two registers separated by a dash.  Multiple register ranges can be
  specified separated by a comma.
! .IP \fB\-mbranch\-cost=\fR\fInum\fR 4
  .IX Item "-mbranch-cost=num"
  Assume \fInum\fR to be the cost for a branch instruction.  Higher numbers
! make the compiler try to generate more branch\-free code if possible.  
  If not specified the value is selected depending on the processor type that
  is being compiled for.
! .IP \fB\-mzdcbranch\fR 4
  .IX Item "-mzdcbranch"
  .PD 0
! .IP \fB\-mno\-zdcbranch\fR 4
  .IX Item "-mno-zdcbranch"
  .PD
  Assume (do not assume) that zero displacement conditional branch instructions
  \&\f(CW\*(C`bt\*(C'\fR and \f(CW\*(C`bf\*(C'\fR are fast.  If \fB\-mzdcbranch\fR is specified, the
  compiler prefers zero displacement branch code sequences.  This is
! enabled by default when generating code for SH4 and SH4A.  It can be explicitly
  disabled by specifying \fB\-mno\-zdcbranch\fR.
! .IP \fB\-mcbranch\-force\-delay\-slot\fR 4
  .IX Item "-mcbranch-force-delay-slot"
  Force the usage of delay slots for conditional branches, which stuffs the delay
  slot with a \f(CW\*(C`nop\*(C'\fR if a suitable instruction cannot be found.  By default
  this option is disabled.  It can be enabled to work around hardware bugs as
! found in the original SH7055.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
! Generate code that uses (does not use) the floating\-point multiply and
  accumulate instructions.  These instructions are generated by default
! if hardware floating point is used.  The machine\-dependent
! \&\fB\-mfused\-madd\fR option is now mapped to the machine\-independent
  \&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
  mapped to \fB\-ffp\-contract=off\fR.
! .IP \fB\-mfsca\fR 4
  .IX Item "-mfsca"
  .PD 0
! .IP \fB\-mno\-fsca\fR 4
  .IX Item "-mno-fsca"
  .PD
  Allow or disallow the compiler to emit the \f(CW\*(C`fsca\*(C'\fR instruction for sine
  and cosine approximations.  The option \fB\-mfsca\fR must be used in
  combination with \fB\-funsafe\-math\-optimizations\fR.  It is enabled by default
! when generating code for SH4A.  Using \fB\-mno\-fsca\fR disables sine and cosine
  approximations even if \fB\-funsafe\-math\-optimizations\fR is in effect.
! .IP \fB\-mfsrra\fR 4
  .IX Item "-mfsrra"
  .PD 0
! .IP \fB\-mno\-fsrra\fR 4
  .IX Item "-mno-fsrra"
  .PD
  Allow or disallow the compiler to emit the \f(CW\*(C`fsrra\*(C'\fR instruction for
  reciprocal square root approximations.  The option \fB\-mfsrra\fR must be used
  in combination with \fB\-funsafe\-math\-optimizations\fR and
  \&\fB\-ffinite\-math\-only\fR.  It is enabled by default when generating code for
! SH4A.  Using \fB\-mno\-fsrra\fR disables reciprocal square root approximations
  even if \fB\-funsafe\-math\-optimizations\fR and \fB\-ffinite\-math\-only\fR are
  in effect.
! .IP \fB\-mpretend\-cmove\fR 4
  .IX Item "-mpretend-cmove"
! Prefer zero\-displacement conditional branches for conditional move instruction
! patterns.  This can result in faster code on the SH4 processor.
! .IP \fB\-mfdpic\fR 4
  .IX Item "-mfdpic"
! Generate code using the FDPIC ABI.
  .PP
  \fISolaris 2 Options\fR
  .IX Subsection "Solaris 2 Options"
  .PP
  These \fB\-m\fR options are supported on Solaris 2:
! .IP \fB\-mclear\-hwcap\fR 4
  .IX Item "-mclear-hwcap"
  \&\fB\-mclear\-hwcap\fR tells the compiler to remove the hardware
  capabilities generated by the Solaris assembler.  This is only necessary
! when object files use ISA extensions not supported by the current
  machine, but check at runtime whether or not to use them.
! .IP \fB\-mimpure\-text\fR 4
  .IX Item "-mimpure-text"
  \&\fB\-mimpure\-text\fR, used in addition to \fB\-shared\fR, tells
  the compiler to not pass \fB\-z text\fR to the linker when linking a
! shared object.  Using this option, you can link position\-dependent
  code into a shared object.
  .Sp
! \&\fB\-mimpure\-text\fR suppresses the "relocations remain against
! allocatable but non\-writable sections" linker error message.
! However, the necessary relocations trigger copy\-on\-write, and the
  shared object is not actually shared across processes.  Instead of
  using \fB\-mimpure\-text\fR, you should compile all source code with
  \&\fB\-fpic\fR or \fB\-fPIC\fR.
  .PP
  These switches are supported in addition to the above on Solaris 2:
! .IP \fB\-pthreads\fR 4
  .IX Item "-pthreads"
  This is a synonym for \fB\-pthread\fR.
  .PP
! \fISPARC Options\fR
  .IX Subsection "SPARC Options"
  .PP
! These \fB\-m\fR options are supported on the SPARC:
! .IP \fB\-mno\-app\-regs\fR 4
  .IX Item "-mno-app-regs"
  .PD 0
! .IP \fB\-mapp\-regs\fR 4
  .IX Item "-mapp-regs"
  .PD
  Specify \fB\-mapp\-regs\fR to generate output using the global registers
! 2 through 4, which the SPARC SVR4 ABI reserves for applications.  Like the
  global register 1, each global register 2 through 4 is then treated as an
  allocable register that is clobbered by function calls.  This is the default.
  .Sp
! To be fully SVR4 ABI\-compliant at the cost of some performance loss,
  specify \fB\-mno\-app\-regs\fR.  You should compile libraries and system
  software with this option.
! .IP \fB\-mflat\fR 4
  .IX Item "-mflat"
  .PD 0
! .IP \fB\-mno\-flat\fR 4
  .IX Item "-mno-flat"
  .PD
  With \fB\-mflat\fR, the compiler does not generate save/restore instructions
! and uses a "flat" or single register window model.  This model is compatible
  with the regular register window model.  The local registers and the input
! registers (0\-\-5) are still treated as "call\-saved" registers and are
  saved on the stack as needed.
  .Sp
  With \fB\-mno\-flat\fR (the default), the compiler generates save/restore
  instructions (except for leaf functions).  This is the normal operating mode.
! .IP \fB\-mfpu\fR 4
  .IX Item "-mfpu"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
! Generate output containing floating\-point instructions.  This is the
  default.
! .IP \fB\-mno\-fpu\fR 4
  .IX Item "-mno-fpu"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
  Generate output containing library calls for floating point.
! \&\fBWarning:\fR the requisite libraries are not available for all SPARC
! targets.  Normally the facilities of the machine\*(Aqs usual C compiler are
! used, but this cannot be done directly in cross\-compilation.  You must make
  your own arrangements to provide suitable library functions for
! cross\-compilation.  The embedded targets \fBsparc\-*\-aout\fR and
! \&\fBsparclite\-*\-*\fR do provide software floating\-point support.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with GCC, with \fB\-msoft\-float\fR in order for
  this to work.
! .IP \fB\-mhard\-quad\-float\fR 4
  .IX Item "-mhard-quad-float"
! Generate output containing quad\-word (long double) floating\-point
  instructions.
! .IP \fB\-msoft\-quad\-float\fR 4
  .IX Item "-msoft-quad-float"
! Generate output containing library calls for quad\-word (long double)
! floating\-point instructions.  The functions called are those specified
! in the SPARC ABI.  This is the default.
  .Sp
! 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
  \&\fB\-msoft\-quad\-float\fR option is the default.
! .IP \fB\-mno\-unaligned\-doubles\fR 4
  .IX Item "-mno-unaligned-doubles"
  .PD 0
! .IP \fB\-munaligned\-doubles\fR 4
  .IX Item "-munaligned-doubles"
  .PD
  Assume that doubles have 8\-byte alignment.  This is the default.
  .Sp
! With \fB\-munaligned\-doubles\fR, 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.
! .IP \fB\-muser\-mode\fR 4
  .IX Item "-muser-mode"
  .PD 0
! .IP \fB\-mno\-user\-mode\fR 4
  .IX Item "-mno-user-mode"
  .PD
  Do not generate code that can only run in supervisor mode.  This is relevant
! only for the \f(CW\*(C`casa\*(C'\fR instruction emitted for the LEON3 processor.  This
  is the default.
! .IP \fB\-mfaster\-structs\fR 4
  .IX Item "-mfaster-structs"
  .PD 0
! .IP \fB\-mno\-faster\-structs\fR 4
  .IX Item "-mno-faster-structs"
  .PD
  With \fB\-mfaster\-structs\fR, the compiler assumes that structures
  should have 8\-byte alignment.  This enables the use of pairs of
  \&\f(CW\*(C`ldd\*(C'\fR and \f(CW\*(C`std\*(C'\fR instructions for copies in structure
  assignment, in place of twice as many \f(CW\*(C`ld\*(C'\fR and \f(CW\*(C`st\*(C'\fR pairs.
! However, the use of this changed alignment directly violates the SPARC
! ABI.  Thus, it\*(Aqs intended only for use on targets where the developer
  acknowledges that their resulting code is not directly in line with
! the rules of the ABI.
! .IP \fB\-mstd\-struct\-return\fR 4
  .IX Item "-mstd-struct-return"
  .PD 0
! .IP \fB\-mno\-std\-struct\-return\fR 4
  .IX Item "-mno-std-struct-return"
  .PD
  With \fB\-mstd\-struct\-return\fR, the compiler generates checking code
  in functions returning structures or unions to detect size mismatches
! between the two sides of function calls, as per the 32\-bit ABI.
  .Sp
  The default is \fB\-mno\-std\-struct\-return\fR.  This option has no effect
  in 64\-bit mode.
! .IP \fB\-mlra\fR 4
  .IX Item "-mlra"
  .PD 0
! .IP \fB\-mno\-lra\fR 4
  .IX Item "-mno-lra"
  .PD
! Enable Local Register Allocation.  This is the default for SPARC since GCC 7
  so \fB\-mno\-lra\fR needs to be passed to get old Reload.
! .IP \fB\-mcpu=\fR\fIcpu_type\fR 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set, register set, and instruction scheduling parameters
  for machine type \fIcpu_type\fR.  Supported values for \fIcpu_type\fR are
*************** for machine type \fIcpu_type\fR.  Suppor
*** 30684,30690 ****
  .Sp
  Native Solaris and GNU/Linux toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize
  the processor.
  .Sp
  Default instruction scheduling parameters are used for values that select
--- 30615,30621 ----
  .Sp
  Native Solaris and GNU/Linux toolchains also support the value \fBnative\fR,
  which selects the best architecture option for the host processor.
! \&\fB\-mcpu=native\fR has no effect if GCC does not recognize
  the processor.
  .Sp
  Default instruction scheduling parameters are used for values that select
*************** an architecture and not an implementatio
*** 30694,30748 ****
  Here is a list of each supported architecture and their supported
  implementations.
  .RS 4
! .IP "v7" 4
  .IX Item "v7"
  cypress, leon3v7
! .IP "v8" 4
  .IX Item "v8"
  supersparc, hypersparc, leon, leon3, leon5
! .IP "sparclite" 4
  .IX Item "sparclite"
  f930, f934, sparclite86x
! .IP "sparclet" 4
  .IX Item "sparclet"
  tsc701
! .IP "v9" 4
  .IX Item "v9"
  ultrasparc, ultrasparc3, niagara, niagara2, niagara3, niagara4,
  niagara7, m8
  .RE
  .RS 4
  .Sp
! By default (unless configured otherwise), \s-1GCC\s0 generates code for the V7
! variant of the \s-1SPARC\s0 architecture.  With \fB\-mcpu=cypress\fR, the compiler
! additionally optimizes it for the Cypress \s-1CY7C602\s0 chip, as used in the
  SPARCStation/SPARCServer 3xx series.  This is also appropriate for the older
! SPARCStation 1, 2, \s-1IPX\s0 etc.
  .Sp
! With \fB\-mcpu=v8\fR, \s-1GCC\s0 generates code for the V8 variant of the \s-1SPARC\s0
  architecture.  The only difference from V7 code is that the compiler emits
! the integer multiply and integer divide instructions which exist in \s-1SPARC\-V8\s0
! but not in \s-1SPARC\-V7.\s0  With \fB\-mcpu=supersparc\fR, the compiler additionally
  optimizes it for the SuperSPARC chip, as used in the SPARCStation 10, 1000 and
  2000 series.
  .Sp
! With \fB\-mcpu=sparclite\fR, \s-1GCC\s0 generates code for the SPARClite variant of
! the \s-1SPARC\s0 architecture.  This adds the integer multiply, integer divide step
! and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClite but not in \s-1SPARC\-V7.\s0
  With \fB\-mcpu=f930\fR, the compiler additionally optimizes it for the
! Fujitsu \s-1MB86930\s0 chip, which is the original SPARClite, with no \s-1FPU.\s0  With
  \&\fB\-mcpu=f934\fR, the compiler additionally optimizes it for the Fujitsu
! \&\s-1MB86934\s0 chip, which is the more recent SPARClite with \s-1FPU.\s0
  .Sp
! With \fB\-mcpu=sparclet\fR, \s-1GCC\s0 generates code for the SPARClet variant of
! the \s-1SPARC\s0 architecture.  This adds the integer multiply, multiply/accumulate,
  integer divide step and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClet
! but not in \s-1SPARC\-V7.\s0  With \fB\-mcpu=tsc701\fR, the compiler additionally
! optimizes it for the \s-1TEMIC\s0 SPARClet chip.
  .Sp
! With \fB\-mcpu=v9\fR, \s-1GCC\s0 generates code for the V9 variant of the \s-1SPARC\s0
! architecture.  This adds 64\-bit integer and floating-point move instructions,
! 3 additional floating-point condition code registers and conditional move
  instructions.  With \fB\-mcpu=ultrasparc\fR, the compiler additionally
  optimizes it for the Sun UltraSPARC I/II/IIi chips.  With
  \&\fB\-mcpu=ultrasparc3\fR, the compiler additionally optimizes it for the
--- 30625,30679 ----
  Here is a list of each supported architecture and their supported
  implementations.
  .RS 4
! .IP v7 4
  .IX Item "v7"
  cypress, leon3v7
! .IP v8 4
  .IX Item "v8"
  supersparc, hypersparc, leon, leon3, leon5
! .IP sparclite 4
  .IX Item "sparclite"
  f930, f934, sparclite86x
! .IP sparclet 4
  .IX Item "sparclet"
  tsc701
! .IP v9 4
  .IX Item "v9"
  ultrasparc, ultrasparc3, niagara, niagara2, niagara3, niagara4,
  niagara7, m8
  .RE
  .RS 4
  .Sp
! By default (unless configured otherwise), GCC generates code for the V7
! variant of the SPARC architecture.  With \fB\-mcpu=cypress\fR, 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.
  .Sp
! With \fB\-mcpu=v8\fR, 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 \fB\-mcpu=supersparc\fR, the compiler additionally
  optimizes it for the SuperSPARC chip, as used in the SPARCStation 10, 1000 and
  2000 series.
  .Sp
! With \fB\-mcpu=sparclite\fR, GCC generates code for the SPARClite variant of
! the SPARC architecture.  This adds the integer multiply, integer divide step
! and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClite but not in SPARC\-V7.
  With \fB\-mcpu=f930\fR, the compiler additionally optimizes it for the
! Fujitsu MB86930 chip, which is the original SPARClite, with no FPU.  With
  \&\fB\-mcpu=f934\fR, the compiler additionally optimizes it for the Fujitsu
! MB86934 chip, which is the more recent SPARClite with FPU.
  .Sp
! With \fB\-mcpu=sparclet\fR, GCC generates code for the SPARClet variant of
! the SPARC architecture.  This adds the integer multiply, multiply/accumulate,
  integer divide step and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClet
! but not in SPARC\-V7.  With \fB\-mcpu=tsc701\fR, the compiler additionally
! optimizes it for the TEMIC SPARClet chip.
  .Sp
! With \fB\-mcpu=v9\fR, 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 \fB\-mcpu=ultrasparc\fR, the compiler additionally
  optimizes it for the Sun UltraSPARC I/II/IIi chips.  With
  \&\fB\-mcpu=ultrasparc3\fR, the compiler additionally optimizes it for the
*************** additionally optimizes it for Sun UltraS
*** 30754,30763 ****
  UltraSPARC T3 chips.  With \fB\-mcpu=niagara4\fR, the compiler
  additionally optimizes it for Sun UltraSPARC T4 chips.  With
  \&\fB\-mcpu=niagara7\fR, the compiler additionally optimizes it for
! Oracle \s-1SPARC M7\s0 chips.  With \fB\-mcpu=m8\fR, the compiler
  additionally optimizes it for Oracle M8 chips.
  .RE
! .IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR, but do not set the instruction set or register set that the
--- 30685,30694 ----
  UltraSPARC T3 chips.  With \fB\-mcpu=niagara4\fR, the compiler
  additionally optimizes it for Sun UltraSPARC T4 chips.  With
  \&\fB\-mcpu=niagara7\fR, the compiler additionally optimizes it for
! Oracle SPARC M7 chips.  With \fB\-mcpu=m8\fR, the compiler
  additionally optimizes it for Oracle M8 chips.
  .RE
! .IP \fB\-mtune=\fR\fIcpu_type\fR 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type
  \&\fIcpu_type\fR, but do not set the instruction set or register set that the
*************** option \fB\-mcpu=\fR\fIcpu_type\fR does.
*** 30765,30983 ****
  .Sp
  The same values for \fB\-mcpu=\fR\fIcpu_type\fR can be used for
  \&\fB\-mtune=\fR\fIcpu_type\fR, but the only useful values are those
! that select a particular \s-1CPU\s0 implementation.  Those are
  \&\fBcypress\fR, \fBsupersparc\fR, \fBhypersparc\fR, \fBleon\fR,
  \&\fBleon3\fR, \fBleon3v7\fR, \fBleon5\fR, \fBf930\fR, \fBf934\fR,
  \&\fBsparclite86x\fR, \fBtsc701\fR, \fBultrasparc\fR,
  \&\fBultrasparc3\fR, \fBniagara\fR, \fBniagara2\fR, \fBniagara3\fR,
  \&\fBniagara4\fR, \fBniagara7\fR and \fBm8\fR.  With native Solaris
  and GNU/Linux toolchains, \fBnative\fR can also be used.
! .IP "\fB\-mv8plus\fR" 4
  .IX Item "-mv8plus"
  .PD 0
! .IP "\fB\-mno\-v8plus\fR" 4
  .IX Item "-mno-v8plus"
  .PD
! With \fB\-mv8plus\fR, \s-1GCC\s0 generates code for the \s-1SPARC\-V8+ ABI.\s0  The
! difference from the V8 \s-1ABI\s0 is that the global and out registers are
  considered 64 bits wide.  This is enabled by default on Solaris in 32\-bit
! mode for all \s-1SPARC\-V9\s0 processors.
! .IP "\fB\-mvis\fR" 4
  .IX Item "-mvis"
  .PD 0
! .IP "\fB\-mno\-vis\fR" 4
  .IX Item "-mno-vis"
  .PD
! With \fB\-mvis\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
  Visual Instruction Set extensions.  The default is \fB\-mno\-vis\fR.
! .IP "\fB\-mvis2\fR" 4
  .IX Item "-mvis2"
  .PD 0
! .IP "\fB\-mno\-vis2\fR" 4
  .IX Item "-mno-vis2"
  .PD
! With \fB\-mvis2\fR, \s-1GCC\s0 generates code that takes advantage of
  version 2.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis2\fR when targeting a cpu that supports such
! instructions, such as UltraSPARC-III and later.  Setting \fB\-mvis2\fR
  also sets \fB\-mvis\fR.
! .IP "\fB\-mvis3\fR" 4
  .IX Item "-mvis3"
  .PD 0
! .IP "\fB\-mno\-vis3\fR" 4
  .IX Item "-mno-vis3"
  .PD
! With \fB\-mvis3\fR, \s-1GCC\s0 generates code that takes advantage of
  version 3.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis3\fR when targeting a cpu that supports such
  instructions, such as niagara\-3 and later.  Setting \fB\-mvis3\fR
  also sets \fB\-mvis2\fR and \fB\-mvis\fR.
! .IP "\fB\-mvis4\fR" 4
  .IX Item "-mvis4"
  .PD 0
! .IP "\fB\-mno\-vis4\fR" 4
  .IX Item "-mno-vis4"
  .PD
! With \fB\-mvis4\fR, \s-1GCC\s0 generates code that takes advantage of
  version 4.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis4\fR when targeting a cpu that supports such
  instructions, such as niagara\-7 and later.  Setting \fB\-mvis4\fR
  also sets \fB\-mvis3\fR, \fB\-mvis2\fR and \fB\-mvis\fR.
! .IP "\fB\-mvis4b\fR" 4
  .IX Item "-mvis4b"
  .PD 0
! .IP "\fB\-mno\-vis4b\fR" 4
  .IX Item "-mno-vis4b"
  .PD
! With \fB\-mvis4b\fR, \s-1GCC\s0 generates code that takes advantage of
  version 4.0 of the UltraSPARC Visual Instruction Set extensions, plus
! the additional \s-1VIS\s0 instructions introduced in the Oracle \s-1SPARC\s0
  Architecture 2017.  The default is \fB\-mvis4b\fR when targeting a
  cpu that supports such instructions, such as m8 and later.  Setting
  \&\fB\-mvis4b\fR also sets \fB\-mvis4\fR, \fB\-mvis3\fR,
  \&\fB\-mvis2\fR and \fB\-mvis\fR.
! .IP "\fB\-mcbcond\fR" 4
  .IX Item "-mcbcond"
  .PD 0
! .IP "\fB\-mno\-cbcond\fR" 4
  .IX Item "-mno-cbcond"
  .PD
! With \fB\-mcbcond\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
! Compare-and-Branch-on-Condition instructions.  The default is \fB\-mcbcond\fR
! when targeting a \s-1CPU\s0 that supports such instructions, such as Niagara\-4 and
  later.
! .IP "\fB\-mfmaf\fR" 4
  .IX Item "-mfmaf"
  .PD 0
! .IP "\fB\-mno\-fmaf\fR" 4
  .IX Item "-mno-fmaf"
  .PD
! With \fB\-mfmaf\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
! Fused Multiply-Add Floating-point instructions.  The default is \fB\-mfmaf\fR
! when targeting a \s-1CPU\s0 that supports such instructions, such as Niagara\-3 and
  later.
! .IP "\fB\-mfsmuld\fR" 4
  .IX Item "-mfsmuld"
  .PD 0
! .IP "\fB\-mno\-fsmuld\fR" 4
  .IX Item "-mno-fsmuld"
  .PD
! With \fB\-mfsmuld\fR, \s-1GCC\s0 generates code that takes advantage of the
! Floating-point Multiply Single to Double (FsMULd) instruction.  The default is
! \&\fB\-mfsmuld\fR when targeting a \s-1CPU\s0 supporting the architecture versions V8
! or V9 with \s-1FPU\s0 except \fB\-mcpu=leon\fR.
! .IP "\fB\-mpopc\fR" 4
  .IX Item "-mpopc"
  .PD 0
! .IP "\fB\-mno\-popc\fR" 4
  .IX Item "-mno-popc"
  .PD
! With \fB\-mpopc\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
  Population Count instruction.  The default is \fB\-mpopc\fR
! when targeting a \s-1CPU\s0 that supports such an instruction, such as Niagara\-2 and
  later.
! .IP "\fB\-msubxc\fR" 4
  .IX Item "-msubxc"
  .PD 0
! .IP "\fB\-mno\-subxc\fR" 4
  .IX Item "-mno-subxc"
  .PD
! With \fB\-msubxc\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
! Subtract-Extended-with-Carry instruction.  The default is \fB\-msubxc\fR
! when targeting a \s-1CPU\s0 that supports such an instruction, such as Niagara\-7 and
  later.
! .IP "\fB\-mfix\-at697f\fR" 4
  .IX Item "-mfix-at697f"
! Enable the documented workaround for the single erratum of the Atmel \s-1AT697F\s0
! processor (which corresponds to erratum #13 of the \s-1AT697E\s0 processor).
! .IP "\fB\-mfix\-ut699\fR" 4
  .IX Item "-mfix-ut699"
! Enable the documented workarounds for the floating-point errata and the data
! cache nullify errata of the \s-1UT699\s0 processor.
! .IP "\fB\-mfix\-ut700\fR" 4
  .IX Item "-mfix-ut700"
! Enable the documented workaround for the back-to-back store errata of
! the \s-1UT699E/UT700\s0 processor.
! .IP "\fB\-mfix\-gr712rc\fR" 4
  .IX Item "-mfix-gr712rc"
! Enable the documented workaround for the back-to-back store errata of
! the \s-1GR712RC\s0 processor.
  .PP
  These \fB\-m\fR options are supported in addition to the above
! on \s-1SPARC\-V9\s0 processors in 64\-bit environments:
! .IP "\fB\-m32\fR" 4
  .IX Item "-m32"
  .PD 0
! .IP "\fB\-m64\fR" 4
  .IX Item "-m64"
  .PD
  Generate code for a 32\-bit or 64\-bit environment.
  The 32\-bit environment sets int, long and pointer to 32 bits.
  The 64\-bit environment sets int to 32 bits and long and pointer
  to 64 bits.
! .IP "\fB\-mcmodel=\fR\fIwhich\fR" 4
  .IX Item "-mcmodel=which"
  Set the code model to one of
  .RS 4
! .IP "\fBmedlow\fR" 4
  .IX Item "medlow"
  The Medium/Low code model: 64\-bit addresses, programs
  must be linked in the low 32 bits of memory.  Programs can be statically
  or dynamically linked.
! .IP "\fBmedmid\fR" 4
  .IX Item "medmid"
  The Medium/Middle code model: 64\-bit addresses, programs
  must be linked in the low 44 bits of memory, the text and data segments must
  be less than 2GB in size and the data segment must be located within 2GB of
  the text segment.
! .IP "\fBmedany\fR" 4
  .IX Item "medany"
  The Medium/Anywhere code model: 64\-bit addresses, programs
  may be linked anywhere in memory, the text and data segments must be less
  than 2GB in size and the data segment must be located within 2GB of the
  text segment.
! .IP "\fBembmedany\fR" 4
  .IX Item "embmedany"
  The Medium/Anywhere code model for embedded systems:
  64\-bit addresses, the text and data segments must be less than 2GB in
  size, both starting anywhere in memory (determined at link time).  The
  global register \f(CW%g4\fR points to the base of the data segment.  Programs
! are statically linked and \s-1PIC\s0 is not supported.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mmemory\-model=\fR\fImem-model\fR" 4
  .IX Item "-mmemory-model=mem-model"
  Set the memory model in force on the processor to one of
  .RS 4
! .IP "\fBdefault\fR" 4
  .IX Item "default"
  The default memory model for the processor and operating system.
! .IP "\fBrmo\fR" 4
  .IX Item "rmo"
  Relaxed Memory Order
! .IP "\fBpso\fR" 4
  .IX Item "pso"
  Partial Store Order
! .IP "\fBtso\fR" 4
  .IX Item "tso"
  Total Store Order
! .IP "\fBsc\fR" 4
  .IX Item "sc"
  Sequential Consistency
  .RE
  .RS 4
  .Sp
! These memory models are formally defined in Appendix D of the \s-1SPARC\-V9\s0
! architecture manual, as set in the processor's \f(CW\*(C`PSTATE.MM\*(C'\fR field.
  .RE
! .IP "\fB\-mstack\-bias\fR" 4
  .IX Item "-mstack-bias"
  .PD 0
! .IP "\fB\-mno\-stack\-bias\fR" 4
  .IX Item "-mno-stack-bias"
  .PD
! With \fB\-mstack\-bias\fR, \s-1GCC\s0 assumes that the stack pointer, and
  frame pointer if present, are offset by \-2047 which must be added back
  when making stack frame references.  This is the default in 64\-bit mode.
  Otherwise, assume no such offset is present.
--- 30696,30914 ----
  .Sp
  The same values for \fB\-mcpu=\fR\fIcpu_type\fR can be used for
  \&\fB\-mtune=\fR\fIcpu_type\fR, but the only useful values are those
! that select a particular CPU implementation.  Those are
  \&\fBcypress\fR, \fBsupersparc\fR, \fBhypersparc\fR, \fBleon\fR,
  \&\fBleon3\fR, \fBleon3v7\fR, \fBleon5\fR, \fBf930\fR, \fBf934\fR,
  \&\fBsparclite86x\fR, \fBtsc701\fR, \fBultrasparc\fR,
  \&\fBultrasparc3\fR, \fBniagara\fR, \fBniagara2\fR, \fBniagara3\fR,
  \&\fBniagara4\fR, \fBniagara7\fR and \fBm8\fR.  With native Solaris
  and GNU/Linux toolchains, \fBnative\fR can also be used.
! .IP \fB\-mv8plus\fR 4
  .IX Item "-mv8plus"
  .PD 0
! .IP \fB\-mno\-v8plus\fR 4
  .IX Item "-mno-v8plus"
  .PD
! With \fB\-mv8plus\fR, GCC generates code for the SPARC\-V8+ ABI.  The
! difference from the V8 ABI is that the global and out registers are
  considered 64 bits wide.  This is enabled by default on Solaris in 32\-bit
! mode for all SPARC\-V9 processors.
! .IP \fB\-mvis\fR 4
  .IX Item "-mvis"
  .PD 0
! .IP \fB\-mno\-vis\fR 4
  .IX Item "-mno-vis"
  .PD
! With \fB\-mvis\fR, GCC generates code that takes advantage of the UltraSPARC
  Visual Instruction Set extensions.  The default is \fB\-mno\-vis\fR.
! .IP \fB\-mvis2\fR 4
  .IX Item "-mvis2"
  .PD 0
! .IP \fB\-mno\-vis2\fR 4
  .IX Item "-mno-vis2"
  .PD
! With \fB\-mvis2\fR, GCC generates code that takes advantage of
  version 2.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis2\fR when targeting a cpu that supports such
! instructions, such as UltraSPARC\-III and later.  Setting \fB\-mvis2\fR
  also sets \fB\-mvis\fR.
! .IP \fB\-mvis3\fR 4
  .IX Item "-mvis3"
  .PD 0
! .IP \fB\-mno\-vis3\fR 4
  .IX Item "-mno-vis3"
  .PD
! With \fB\-mvis3\fR, GCC generates code that takes advantage of
  version 3.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis3\fR when targeting a cpu that supports such
  instructions, such as niagara\-3 and later.  Setting \fB\-mvis3\fR
  also sets \fB\-mvis2\fR and \fB\-mvis\fR.
! .IP \fB\-mvis4\fR 4
  .IX Item "-mvis4"
  .PD 0
! .IP \fB\-mno\-vis4\fR 4
  .IX Item "-mno-vis4"
  .PD
! With \fB\-mvis4\fR, GCC generates code that takes advantage of
  version 4.0 of the UltraSPARC Visual Instruction Set extensions.  The
  default is \fB\-mvis4\fR when targeting a cpu that supports such
  instructions, such as niagara\-7 and later.  Setting \fB\-mvis4\fR
  also sets \fB\-mvis3\fR, \fB\-mvis2\fR and \fB\-mvis\fR.
! .IP \fB\-mvis4b\fR 4
  .IX Item "-mvis4b"
  .PD 0
! .IP \fB\-mno\-vis4b\fR 4
  .IX Item "-mno-vis4b"
  .PD
! With \fB\-mvis4b\fR, GCC generates code that takes advantage of
  version 4.0 of the UltraSPARC Visual Instruction Set extensions, plus
! the additional VIS instructions introduced in the Oracle SPARC
  Architecture 2017.  The default is \fB\-mvis4b\fR when targeting a
  cpu that supports such instructions, such as m8 and later.  Setting
  \&\fB\-mvis4b\fR also sets \fB\-mvis4\fR, \fB\-mvis3\fR,
  \&\fB\-mvis2\fR and \fB\-mvis\fR.
! .IP \fB\-mcbcond\fR 4
  .IX Item "-mcbcond"
  .PD 0
! .IP \fB\-mno\-cbcond\fR 4
  .IX Item "-mno-cbcond"
  .PD
! With \fB\-mcbcond\fR, GCC generates code that takes advantage of the UltraSPARC
! Compare\-and\-Branch\-on\-Condition instructions.  The default is \fB\-mcbcond\fR
! when targeting a CPU that supports such instructions, such as Niagara\-4 and
  later.
! .IP \fB\-mfmaf\fR 4
  .IX Item "-mfmaf"
  .PD 0
! .IP \fB\-mno\-fmaf\fR 4
  .IX Item "-mno-fmaf"
  .PD
! With \fB\-mfmaf\fR, GCC generates code that takes advantage of the UltraSPARC
! Fused Multiply\-Add Floating\-point instructions.  The default is \fB\-mfmaf\fR
! when targeting a CPU that supports such instructions, such as Niagara\-3 and
  later.
! .IP \fB\-mfsmuld\fR 4
  .IX Item "-mfsmuld"
  .PD 0
! .IP \fB\-mno\-fsmuld\fR 4
  .IX Item "-mno-fsmuld"
  .PD
! With \fB\-mfsmuld\fR, GCC generates code that takes advantage of the
! Floating\-point Multiply Single to Double (FsMULd) instruction.  The default is
! \&\fB\-mfsmuld\fR when targeting a CPU supporting the architecture versions V8
! or V9 with FPU except \fB\-mcpu=leon\fR.
! .IP \fB\-mpopc\fR 4
  .IX Item "-mpopc"
  .PD 0
! .IP \fB\-mno\-popc\fR 4
  .IX Item "-mno-popc"
  .PD
! With \fB\-mpopc\fR, GCC generates code that takes advantage of the UltraSPARC
  Population Count instruction.  The default is \fB\-mpopc\fR
! when targeting a CPU that supports such an instruction, such as Niagara\-2 and
  later.
! .IP \fB\-msubxc\fR 4
  .IX Item "-msubxc"
  .PD 0
! .IP \fB\-mno\-subxc\fR 4
  .IX Item "-mno-subxc"
  .PD
! With \fB\-msubxc\fR, GCC generates code that takes advantage of the UltraSPARC
! Subtract\-Extended\-with\-Carry instruction.  The default is \fB\-msubxc\fR
! when targeting a CPU that supports such an instruction, such as Niagara\-7 and
  later.
! .IP \fB\-mfix\-at697f\fR 4
  .IX Item "-mfix-at697f"
! Enable the documented workaround for the single erratum of the Atmel AT697F
! processor (which corresponds to erratum #13 of the AT697E processor).
! .IP \fB\-mfix\-ut699\fR 4
  .IX Item "-mfix-ut699"
! Enable the documented workarounds for the floating\-point errata and the data
! cache nullify errata of the UT699 processor.
! .IP \fB\-mfix\-ut700\fR 4
  .IX Item "-mfix-ut700"
! Enable the documented workaround for the back\-to\-back store errata of
! the UT699E/UT700 processor.
! .IP \fB\-mfix\-gr712rc\fR 4
  .IX Item "-mfix-gr712rc"
! Enable the documented workaround for the back\-to\-back store errata of
! the GR712RC processor.
  .PP
  These \fB\-m\fR options are supported in addition to the above
! on SPARC\-V9 processors in 64\-bit environments:
! .IP \fB\-m32\fR 4
  .IX Item "-m32"
  .PD 0
! .IP \fB\-m64\fR 4
  .IX Item "-m64"
  .PD
  Generate code for a 32\-bit or 64\-bit environment.
  The 32\-bit environment sets int, long and pointer to 32 bits.
  The 64\-bit environment sets int to 32 bits and long and pointer
  to 64 bits.
! .IP \fB\-mcmodel=\fR\fIwhich\fR 4
  .IX Item "-mcmodel=which"
  Set the code model to one of
  .RS 4
! .IP \fBmedlow\fR 4
  .IX Item "medlow"
  The Medium/Low code model: 64\-bit addresses, programs
  must be linked in the low 32 bits of memory.  Programs can be statically
  or dynamically linked.
! .IP \fBmedmid\fR 4
  .IX Item "medmid"
  The Medium/Middle code model: 64\-bit addresses, programs
  must be linked in the low 44 bits of memory, the text and data segments must
  be less than 2GB in size and the data segment must be located within 2GB of
  the text segment.
! .IP \fBmedany\fR 4
  .IX Item "medany"
  The Medium/Anywhere code model: 64\-bit addresses, programs
  may be linked anywhere in memory, the text and data segments must be less
  than 2GB in size and the data segment must be located within 2GB of the
  text segment.
! .IP \fBembmedany\fR 4
  .IX Item "embmedany"
  The Medium/Anywhere code model for embedded systems:
  64\-bit addresses, the text and data segments must be less than 2GB in
  size, both starting anywhere in memory (determined at link time).  The
  global register \f(CW%g4\fR points to the base of the data segment.  Programs
! are statically linked and PIC is not supported.
  .RE
  .RS 4
  .RE
! .IP \fB\-mmemory\-model=\fR\fImem\-model\fR 4
  .IX Item "-mmemory-model=mem-model"
  Set the memory model in force on the processor to one of
  .RS 4
! .IP \fBdefault\fR 4
  .IX Item "default"
  The default memory model for the processor and operating system.
! .IP \fBrmo\fR 4
  .IX Item "rmo"
  Relaxed Memory Order
! .IP \fBpso\fR 4
  .IX Item "pso"
  Partial Store Order
! .IP \fBtso\fR 4
  .IX Item "tso"
  Total Store Order
! .IP \fBsc\fR 4
  .IX Item "sc"
  Sequential Consistency
  .RE
  .RS 4
  .Sp
! These memory models are formally defined in Appendix D of the SPARC\-V9
! architecture manual, as set in the processor\*(Aqs \f(CW\*(C`PSTATE.MM\*(C'\fR field.
  .RE
! .IP \fB\-mstack\-bias\fR 4
  .IX Item "-mstack-bias"
  .PD 0
! .IP \fB\-mno\-stack\-bias\fR 4
  .IX Item "-mno-stack-bias"
  .PD
! With \fB\-mstack\-bias\fR, 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.
*************** Otherwise, assume no such offset is pres
*** 30987,31009 ****
  .PP
  These additional options are available on System V Release 4 for
  compatibility with other compilers on those systems:
! .IP "\fB\-G\fR" 4
  .IX Item "-G"
  Create a shared object.
  It is recommended that \fB\-symbolic\fR or \fB\-shared\fR be used instead.
! .IP "\fB\-Qy\fR" 4
  .IX Item "-Qy"
  Identify the versions of each tool used by the compiler, in a
  \&\f(CW\*(C`.ident\*(C'\fR assembler directive in the output.
! .IP "\fB\-Qn\fR" 4
  .IX Item "-Qn"
  Refrain from adding \f(CW\*(C`.ident\*(C'\fR directives to the output file (this is
  the default).
! .IP "\fB\-YP,\fR\fIdirs\fR" 4
  .IX Item "-YP,dirs"
  Search the directories \fIdirs\fR, and no others, for libraries
  specified with \fB\-l\fR.
! .IP "\fB\-Ym,\fR\fIdir\fR" 4
  .IX Item "-Ym,dir"
  Look in the directory \fIdir\fR to find the M4 preprocessor.
  The assembler uses this option.
--- 30918,30940 ----
  .PP
  These additional options are available on System V Release 4 for
  compatibility with other compilers on those systems:
! .IP \fB\-G\fR 4
  .IX Item "-G"
  Create a shared object.
  It is recommended that \fB\-symbolic\fR or \fB\-shared\fR be used instead.
! .IP \fB\-Qy\fR 4
  .IX Item "-Qy"
  Identify the versions of each tool used by the compiler, in a
  \&\f(CW\*(C`.ident\*(C'\fR assembler directive in the output.
! .IP \fB\-Qn\fR 4
  .IX Item "-Qn"
  Refrain from adding \f(CW\*(C`.ident\*(C'\fR directives to the output file (this is
  the default).
! .IP \fB\-YP,\fR\fIdirs\fR 4
  .IX Item "-YP,dirs"
  Search the directories \fIdirs\fR, and no others, for libraries
  specified with \fB\-l\fR.
! .IP \fB\-Ym,\fR\fIdir\fR 4
  .IX Item "-Ym,dir"
  Look in the directory \fIdir\fR to find the M4 preprocessor.
  The assembler uses this option.
*************** The assembler uses this option.
*** 31012,31040 ****
  .IX Subsection "V850 Options"
  .PP
  These \fB\-m\fR options are defined for V850 implementations:
! .IP "\fB\-mlong\-calls\fR" 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP "\fB\-mno\-long\-calls\fR" 4
  .IX Item "-mno-long-calls"
  .PD
  Treat all calls as being far away (near).  If calls are assumed to be
! far away, the compiler always loads the function's address into a
  register, and calls indirect through the pointer.
! .IP "\fB\-mno\-ep\fR" 4
  .IX Item "-mno-ep"
  .PD 0
! .IP "\fB\-mep\fR" 4
  .IX Item "-mep"
  .PD
  Do not optimize (do optimize) basic blocks that use the same index
  pointer 4 or more times to copy pointer into the \f(CW\*(C`ep\*(C'\fR register, and
  use the shorter \f(CW\*(C`sld\*(C'\fR and \f(CW\*(C`sst\*(C'\fR instructions.  The \fB\-mep\fR
  option is on by default if you optimize.
! .IP "\fB\-mno\-prolog\-function\fR" 4
  .IX Item "-mno-prolog-function"
  .PD 0
! .IP "\fB\-mprolog\-function\fR" 4
  .IX Item "-mprolog-function"
  .PD
  Do not use (do use) external functions to save and restore registers
--- 30943,30971 ----
  .IX Subsection "V850 Options"
  .PP
  These \fB\-m\fR options are defined for V850 implementations:
! .IP \fB\-mlong\-calls\fR 4
  .IX Item "-mlong-calls"
  .PD 0
! .IP \fB\-mno\-long\-calls\fR 4
  .IX Item "-mno-long-calls"
  .PD
  Treat all calls as being far away (near).  If calls are assumed to be
! far away, the compiler always loads the function\*(Aqs address into a
  register, and calls indirect through the pointer.
! .IP \fB\-mno\-ep\fR 4
  .IX Item "-mno-ep"
  .PD 0
! .IP \fB\-mep\fR 4
  .IX Item "-mep"
  .PD
  Do not optimize (do optimize) basic blocks that use the same index
  pointer 4 or more times to copy pointer into the \f(CW\*(C`ep\*(C'\fR register, and
  use the shorter \f(CW\*(C`sld\*(C'\fR and \f(CW\*(C`sst\*(C'\fR instructions.  The \fB\-mep\fR
  option is on by default if you optimize.
! .IP \fB\-mno\-prolog\-function\fR 4
  .IX Item "-mno-prolog-function"
  .PD 0
! .IP \fB\-mprolog\-function\fR 4
  .IX Item "-mprolog-function"
  .PD
  Do not use (do use) external functions to save and restore registers
*************** at the prologue and epilogue of a functi
*** 31042,31094 ****
  are slower, but use less code space if more than one function saves
  the same number of registers.  The \fB\-mprolog\-function\fR option
  is on by default if you optimize.
! .IP "\fB\-mspace\fR" 4
  .IX Item "-mspace"
  Try to make the code as small as possible.  At present, this just turns
  on the \fB\-mep\fR and \fB\-mprolog\-function\fR options.
! .IP "\fB\-mtda=\fR\fIn\fR" 4
  .IX Item "-mtda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the tiny data area that register \f(CW\*(C`ep\*(C'\fR points to.  The tiny data
  area can hold up to 256 bytes in total (128 bytes for byte references).
! .IP "\fB\-msda=\fR\fIn\fR" 4
  .IX Item "-msda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the small data area that register \f(CW\*(C`gp\*(C'\fR points to.  The small data
  area can hold up to 64 kilobytes.
! .IP "\fB\-mzda=\fR\fIn\fR" 4
  .IX Item "-mzda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the first 32 kilobytes of memory.
! .IP "\fB\-mv850\fR" 4
  .IX Item "-mv850"
  Specify that the target processor is the V850.
! .IP "\fB\-mv850e3v5\fR" 4
  .IX Item "-mv850e3v5"
  Specify that the target processor is the V850E3V5.  The preprocessor
  constant \f(CW\*(C`_\|_v850e3v5_\|_\*(C'\fR is defined if this option is used.
! .IP "\fB\-mv850e2v4\fR" 4
  .IX Item "-mv850e2v4"
  Specify that the target processor is the V850E3V5.  This is an alias for
  the \fB\-mv850e3v5\fR option.
! .IP "\fB\-mv850e2v3\fR" 4
  .IX Item "-mv850e2v3"
  Specify that the target processor is the V850E2V3.  The preprocessor
  constant \f(CW\*(C`_\|_v850e2v3_\|_\*(C'\fR is defined if this option is used.
! .IP "\fB\-mv850e2\fR" 4
  .IX Item "-mv850e2"
  Specify that the target processor is the V850E2.  The preprocessor
  constant \f(CW\*(C`_\|_v850e2_\|_\*(C'\fR is defined if this option is used.
! .IP "\fB\-mv850e1\fR" 4
  .IX Item "-mv850e1"
  Specify that the target processor is the V850E1.  The preprocessor
  constants \f(CW\*(C`_\|_v850e1_\|_\*(C'\fR and \f(CW\*(C`_\|_v850e_\|_\*(C'\fR are defined if
  this option is used.
! .IP "\fB\-mv850es\fR" 4
  .IX Item "-mv850es"
  Specify that the target processor is the V850ES.  This is an alias for
  the \fB\-mv850e1\fR option.
! .IP "\fB\-mv850e\fR" 4
  .IX Item "-mv850e"
  Specify that the target processor is the V850E.  The preprocessor
  constant \f(CW\*(C`_\|_v850e_\|_\*(C'\fR is defined if this option is used.
--- 30973,31025 ----
  are slower, but use less code space if more than one function saves
  the same number of registers.  The \fB\-mprolog\-function\fR option
  is on by default if you optimize.
! .IP \fB\-mspace\fR 4
  .IX Item "-mspace"
  Try to make the code as small as possible.  At present, this just turns
  on the \fB\-mep\fR and \fB\-mprolog\-function\fR options.
! .IP \fB\-mtda=\fR\fIn\fR 4
  .IX Item "-mtda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the tiny data area that register \f(CW\*(C`ep\*(C'\fR points to.  The tiny data
  area can hold up to 256 bytes in total (128 bytes for byte references).
! .IP \fB\-msda=\fR\fIn\fR 4
  .IX Item "-msda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the small data area that register \f(CW\*(C`gp\*(C'\fR points to.  The small data
  area can hold up to 64 kilobytes.
! .IP \fB\-mzda=\fR\fIn\fR 4
  .IX Item "-mzda=n"
  Put static or global variables whose size is \fIn\fR bytes or less into
  the first 32 kilobytes of memory.
! .IP \fB\-mv850\fR 4
  .IX Item "-mv850"
  Specify that the target processor is the V850.
! .IP \fB\-mv850e3v5\fR 4
  .IX Item "-mv850e3v5"
  Specify that the target processor is the V850E3V5.  The preprocessor
  constant \f(CW\*(C`_\|_v850e3v5_\|_\*(C'\fR is defined if this option is used.
! .IP \fB\-mv850e2v4\fR 4
  .IX Item "-mv850e2v4"
  Specify that the target processor is the V850E3V5.  This is an alias for
  the \fB\-mv850e3v5\fR option.
! .IP \fB\-mv850e2v3\fR 4
  .IX Item "-mv850e2v3"
  Specify that the target processor is the V850E2V3.  The preprocessor
  constant \f(CW\*(C`_\|_v850e2v3_\|_\*(C'\fR is defined if this option is used.
! .IP \fB\-mv850e2\fR 4
  .IX Item "-mv850e2"
  Specify that the target processor is the V850E2.  The preprocessor
  constant \f(CW\*(C`_\|_v850e2_\|_\*(C'\fR is defined if this option is used.
! .IP \fB\-mv850e1\fR 4
  .IX Item "-mv850e1"
  Specify that the target processor is the V850E1.  The preprocessor
  constants \f(CW\*(C`_\|_v850e1_\|_\*(C'\fR and \f(CW\*(C`_\|_v850e_\|_\*(C'\fR are defined if
  this option is used.
! .IP \fB\-mv850es\fR 4
  .IX Item "-mv850es"
  Specify that the target processor is the V850ES.  This is an alias for
  the \fB\-mv850e1\fR option.
! .IP \fB\-mv850e\fR 4
  .IX Item "-mv850e"
  Specify that the target processor is the V850E.  The preprocessor
  constant \f(CW\*(C`_\|_v850e_\|_\*(C'\fR is defined if this option is used.
*************** relevant \fB_\|_v850*_\|_\fR preprocesso
*** 31100,31208 ****
  .Sp
  The preprocessor constants \f(CW\*(C`_\|_v850\*(C'\fR and \f(CW\*(C`_\|_v851_\|_\*(C'\fR are always
  defined, regardless of which processor variant is the target.
! .IP "\fB\-mdisable\-callt\fR" 4
  .IX Item "-mdisable-callt"
  .PD 0
! .IP "\fB\-mno\-disable\-callt\fR" 4
  .IX Item "-mno-disable-callt"
  .PD
  This option suppresses generation of the \f(CW\*(C`CALLT\*(C'\fR instruction for the
  v850e, v850e1, v850e2, v850e2v3 and v850e3v5 flavors of the v850
  architecture.
  .Sp
! This option is enabled by default when the \s-1RH850 ABI\s0 is
  in use (see \fB\-mrh850\-abi\fR), and disabled by default when the
! \&\s-1GCC ABI\s0 is in use.  If \f(CW\*(C`CALLT\*(C'\fR instructions are being generated
  then the C preprocessor symbol \f(CW\*(C`_\|_V850_CALLT_\|_\*(C'\fR is defined.
! .IP "\fB\-mrelax\fR" 4
  .IX Item "-mrelax"
  .PD 0
! .IP "\fB\-mno\-relax\fR" 4
  .IX Item "-mno-relax"
  .PD
! Pass on (or do not pass on) the \fB\-mrelax\fR command-line option
  to the assembler.
! .IP "\fB\-mlong\-jumps\fR" 4
  .IX Item "-mlong-jumps"
  .PD 0
! .IP "\fB\-mno\-long\-jumps\fR" 4
  .IX Item "-mno-long-jumps"
  .PD
! Disable (or re-enable) the generation of PC-relative jump instructions.
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
! Disable (or re-enable) the generation of hardware floating point
  instructions.  This option is only significant when the target
  architecture is \fBV850E2V3\fR or higher.  If hardware floating point
  instructions are being generated then the C preprocessor symbol
  \&\f(CW\*(C`_\|_FPU_OK_\|_\*(C'\fR is defined, otherwise the symbol
  \&\f(CW\*(C`_\|_NO_FPU_\|_\*(C'\fR is defined.
! .IP "\fB\-mloop\fR" 4
  .IX Item "-mloop"
! Enables the use of the e3v5 \s-1LOOP\s0 instruction.  The use of this
  instruction is not enabled by default when the e3v5 architecture is
  selected because its use is still experimental.
! .IP "\fB\-mrh850\-abi\fR" 4
  .IX Item "-mrh850-abi"
  .PD 0
! .IP "\fB\-mghs\fR" 4
  .IX Item "-mghs"
  .PD
! Enables support for the \s-1RH850\s0 version of the V850 \s-1ABI.\s0  This is the
! default.  With this version of the \s-1ABI\s0 the following rules apply:
  .RS 4
! .IP "*" 4
  Integer sized structures and unions are returned via a memory pointer
  rather than a register.
! .IP "*" 4
  Large structures and unions (more than 8 bytes in size) are passed by
  value.
! .IP "*" 4
  Functions are aligned to 16\-bit boundaries.
! .IP "*" 4
! The \fB\-m8byte\-align\fR command-line option is supported.
! .IP "*" 4
! The \fB\-mdisable\-callt\fR command-line option is enabled by
! default.  The \fB\-mno\-disable\-callt\fR command-line option is not
  supported.
  .RE
  .RS 4
  .Sp
! When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_RH850_ABI_\|_\*(C'\fR is defined.
  .RE
! .IP "\fB\-mgcc\-abi\fR" 4
  .IX Item "-mgcc-abi"
! Enables support for the old \s-1GCC\s0 version of the V850 \s-1ABI.\s0  With this
! version of the \s-1ABI\s0 the following rules apply:
  .RS 4
! .IP "*" 4
  Integer sized structures and unions are returned in register \f(CW\*(C`r10\*(C'\fR.
! .IP "*" 4
  Large structures and unions (more than 8 bytes in size) are passed by
  reference.
! .IP "*" 4
  Functions are aligned to 32\-bit boundaries, unless optimizing for
  size.
! .IP "*" 4
! The \fB\-m8byte\-align\fR command-line option is not supported.
! .IP "*" 4
! The \fB\-mdisable\-callt\fR command-line option is supported but not
  enabled by default.
  .RE
  .RS 4
  .Sp
! When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_GCC_ABI_\|_\*(C'\fR is defined.
  .RE
! .IP "\fB\-m8byte\-align\fR" 4
  .IX Item "-m8byte-align"
  .PD 0
! .IP "\fB\-mno\-8byte\-align\fR" 4
  .IX Item "-mno-8byte-align"
  .PD
  Enables support for \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long long\*(C'\fR types to be
--- 31031,31139 ----
  .Sp
  The preprocessor constants \f(CW\*(C`_\|_v850\*(C'\fR and \f(CW\*(C`_\|_v851_\|_\*(C'\fR are always
  defined, regardless of which processor variant is the target.
! .IP \fB\-mdisable\-callt\fR 4
  .IX Item "-mdisable-callt"
  .PD 0
! .IP \fB\-mno\-disable\-callt\fR 4
  .IX Item "-mno-disable-callt"
  .PD
  This option suppresses generation of the \f(CW\*(C`CALLT\*(C'\fR instruction for the
  v850e, v850e1, v850e2, v850e2v3 and v850e3v5 flavors of the v850
  architecture.
  .Sp
! This option is enabled by default when the RH850 ABI is
  in use (see \fB\-mrh850\-abi\fR), and disabled by default when the
! GCC ABI is in use.  If \f(CW\*(C`CALLT\*(C'\fR instructions are being generated
  then the C preprocessor symbol \f(CW\*(C`_\|_V850_CALLT_\|_\*(C'\fR is defined.
! .IP \fB\-mrelax\fR 4
  .IX Item "-mrelax"
  .PD 0
! .IP \fB\-mno\-relax\fR 4
  .IX Item "-mno-relax"
  .PD
! Pass on (or do not pass on) the \fB\-mrelax\fR command\-line option
  to the assembler.
! .IP \fB\-mlong\-jumps\fR 4
  .IX Item "-mlong-jumps"
  .PD 0
! .IP \fB\-mno\-long\-jumps\fR 4
  .IX Item "-mno-long-jumps"
  .PD
! Disable (or re\-enable) the generation of PC\-relative jump instructions.
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
! Disable (or re\-enable) the generation of hardware floating point
  instructions.  This option is only significant when the target
  architecture is \fBV850E2V3\fR or higher.  If hardware floating point
  instructions are being generated then the C preprocessor symbol
  \&\f(CW\*(C`_\|_FPU_OK_\|_\*(C'\fR is defined, otherwise the symbol
  \&\f(CW\*(C`_\|_NO_FPU_\|_\*(C'\fR is defined.
! .IP \fB\-mloop\fR 4
  .IX Item "-mloop"
! Enables the use of the e3v5 LOOP instruction.  The use of this
  instruction is not enabled by default when the e3v5 architecture is
  selected because its use is still experimental.
! .IP \fB\-mrh850\-abi\fR 4
  .IX Item "-mrh850-abi"
  .PD 0
! .IP \fB\-mghs\fR 4
  .IX Item "-mghs"
  .PD
! Enables support for the RH850 version of the V850 ABI.  This is the
! default.  With this version of the ABI the following rules apply:
  .RS 4
! .IP * 4
  Integer sized structures and unions are returned via a memory pointer
  rather than a register.
! .IP * 4
  Large structures and unions (more than 8 bytes in size) are passed by
  value.
! .IP * 4
  Functions are aligned to 16\-bit boundaries.
! .IP * 4
! The \fB\-m8byte\-align\fR command\-line option is supported.
! .IP * 4
! The \fB\-mdisable\-callt\fR command\-line option is enabled by
! default.  The \fB\-mno\-disable\-callt\fR command\-line option is not
  supported.
  .RE
  .RS 4
  .Sp
! When this version of the ABI is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_RH850_ABI_\|_\*(C'\fR is defined.
  .RE
! .IP \fB\-mgcc\-abi\fR 4
  .IX Item "-mgcc-abi"
! Enables support for the old GCC version of the V850 ABI.  With this
! version of the ABI the following rules apply:
  .RS 4
! .IP * 4
  Integer sized structures and unions are returned in register \f(CW\*(C`r10\*(C'\fR.
! .IP * 4
  Large structures and unions (more than 8 bytes in size) are passed by
  reference.
! .IP * 4
  Functions are aligned to 32\-bit boundaries, unless optimizing for
  size.
! .IP * 4
! The \fB\-m8byte\-align\fR command\-line option is not supported.
! .IP * 4
! The \fB\-mdisable\-callt\fR command\-line option is supported but not
  enabled by default.
  .RE
  .RS 4
  .Sp
! When this version of the ABI is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_GCC_ABI_\|_\*(C'\fR is defined.
  .RE
! .IP \fB\-m8byte\-align\fR 4
  .IX Item "-m8byte-align"
  .PD 0
! .IP \fB\-mno\-8byte\-align\fR 4
  .IX Item "-mno-8byte-align"
  .PD
  Enables support for \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long long\*(C'\fR types to be
*************** aligned on 8\-byte boundaries.  The defa
*** 31210,31288 ****
  alignment of all objects to at most 4\-bytes.  When
  \&\fB\-m8byte\-align\fR is in effect the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_8BYTE_ALIGN_\|_\*(C'\fR is defined.
! .IP "\fB\-mbig\-switch\fR" 4
  .IX Item "-mbig-switch"
  Generate code suitable for big switch tables.  Use this option only if
  the assembler/linker complain about out of range branches within a switch
  table.
! .IP "\fB\-mapp\-regs\fR" 4
  .IX Item "-mapp-regs"
  This option causes r2 and r5 to be used in the code generated by
  the compiler.  This setting is the default.
! .IP "\fB\-mno\-app\-regs\fR" 4
  .IX Item "-mno-app-regs"
  This option causes r2 and r5 to be treated as fixed registers.
  .PP
! \fI\s-1VAX\s0 Options\fR
  .IX Subsection "VAX Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1VAX:\s0
! .IP "\fB\-munix\fR" 4
  .IX Item "-munix"
  Do not output certain jump instructions (\f(CW\*(C`aobleq\*(C'\fR and so on)
! that the Unix assembler for the \s-1VAX\s0 cannot handle across long
  ranges.
! .IP "\fB\-mgnu\fR" 4
  .IX Item "-mgnu"
  Do output those jump instructions, on the assumption that the
! \&\s-1GNU\s0 assembler is being used.
! .IP "\fB\-mg\fR" 4
  .IX Item "-mg"
! Output code for G\-format floating-point numbers instead of D\-format.
! .IP "\fB\-mlra\fR" 4
  .IX Item "-mlra"
  .PD 0
! .IP "\fB\-mno\-lra\fR" 4
  .IX Item "-mno-lra"
  .PD
! Enable Local Register Allocation.  This is still experimental for the \s-1VAX,\s0
  so by default the compiler uses standard reload.
  .PP
  \fIVisium Options\fR
  .IX Subsection "Visium Options"
! .IP "\fB\-mdebug\fR" 4
  .IX Item "-mdebug"
! A program which performs file I/O and is destined to run on an \s-1MCM\s0 target
  should be linked with this option.  It causes the libraries libc.a and
  libdebug.a to be linked.  The program should be run on the target under
! the control of the \s-1GDB\s0 remote debugging stub.
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  A program which performs file I/O and is destined to run on the simulator
  should be linked with option.  This causes libraries libc.a and libsim.a to
  be linked.
! .IP "\fB\-mfpu\fR" 4
  .IX Item "-mfpu"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
! Generate code containing floating-point instructions.  This is the
  default.
! .IP "\fB\-mno\-fpu\fR" 4
  .IX Item "-mno-fpu"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
! Generate code containing library calls for floating-point.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with \s-1GCC,\s0 with \fB\-msoft\-float\fR in order for
  this to work.
! .IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set, register set, and instruction scheduling parameters
  for machine type \fIcpu_type\fR.  Supported values for \fIcpu_type\fR are
--- 31141,31219 ----
  alignment of all objects to at most 4\-bytes.  When
  \&\fB\-m8byte\-align\fR is in effect the C preprocessor symbol
  \&\f(CW\*(C`_\|_V850_8BYTE_ALIGN_\|_\*(C'\fR is defined.
! .IP \fB\-mbig\-switch\fR 4
  .IX Item "-mbig-switch"
  Generate code suitable for big switch tables.  Use this option only if
  the assembler/linker complain about out of range branches within a switch
  table.
! .IP \fB\-mapp\-regs\fR 4
  .IX Item "-mapp-regs"
  This option causes r2 and r5 to be used in the code generated by
  the compiler.  This setting is the default.
! .IP \fB\-mno\-app\-regs\fR 4
  .IX Item "-mno-app-regs"
  This option causes r2 and r5 to be treated as fixed registers.
  .PP
! \fIVAX Options\fR
  .IX Subsection "VAX Options"
  .PP
! These \fB\-m\fR options are defined for the VAX:
! .IP \fB\-munix\fR 4
  .IX Item "-munix"
  Do not output certain jump instructions (\f(CW\*(C`aobleq\*(C'\fR and so on)
! that the Unix assembler for the VAX cannot handle across long
  ranges.
! .IP \fB\-mgnu\fR 4
  .IX Item "-mgnu"
  Do output those jump instructions, on the assumption that the
! GNU assembler is being used.
! .IP \fB\-mg\fR 4
  .IX Item "-mg"
! Output code for G\-format floating\-point numbers instead of D\-format.
! .IP \fB\-mlra\fR 4
  .IX Item "-mlra"
  .PD 0
! .IP \fB\-mno\-lra\fR 4
  .IX Item "-mno-lra"
  .PD
! Enable Local Register Allocation.  This is still experimental for the VAX,
  so by default the compiler uses standard reload.
  .PP
  \fIVisium Options\fR
  .IX Subsection "Visium Options"
! .IP \fB\-mdebug\fR 4
  .IX Item "-mdebug"
! A program which performs file I/O and is destined to run on an MCM target
  should be linked with this option.  It causes the libraries libc.a and
  libdebug.a to be linked.  The program should be run on the target under
! the control of the GDB remote debugging stub.
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  A program which performs file I/O and is destined to run on the simulator
  should be linked with option.  This causes libraries libc.a and libsim.a to
  be linked.
! .IP \fB\-mfpu\fR 4
  .IX Item "-mfpu"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
! Generate code containing floating\-point instructions.  This is the
  default.
! .IP \fB\-mno\-fpu\fR 4
  .IX Item "-mno-fpu"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
! Generate code containing library calls for floating\-point.
  .Sp
  \&\fB\-msoft\-float\fR changes the calling convention in the output file;
  therefore, it is only useful if you compile \fIall\fR of a program with
  this option.  In particular, you need to compile \fIlibgcc.a\fR, the
! library that comes with GCC, with \fB\-msoft\-float\fR in order for
  this to work.
! .IP \fB\-mcpu=\fR\fIcpu_type\fR 4
  .IX Item "-mcpu=cpu_type"
  Set the instruction set, register set, and instruction scheduling parameters
  for machine type \fIcpu_type\fR.  Supported values for \fIcpu_type\fR are
*************** for machine type \fIcpu_type\fR.  Suppor
*** 31290,31332 ****
  .Sp
  \&\fBmcm\fR is a synonym of \fBgr5\fR present for backward compatibility.
  .Sp
! By default (unless configured otherwise), \s-1GCC\s0 generates code for the \s-1GR5\s0
  variant of the Visium architecture.
  .Sp
! With \fB\-mcpu=gr6\fR, \s-1GCC\s0 generates code for the \s-1GR6\s0 variant of the Visium
! architecture.  The only difference from \s-1GR5\s0 code is that the compiler will
  generate block move instructions.
! .IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type \fIcpu_type\fR,
  but do not set the instruction set or register set that the option
  \&\fB\-mcpu=\fR\fIcpu_type\fR would.
! .IP "\fB\-msv\-mode\fR" 4
  .IX Item "-msv-mode"
  Generate code for the supervisor mode, where there are no restrictions on
  the access to general registers.  This is the default.
! .IP "\fB\-muser\-mode\fR" 4
  .IX Item "-muser-mode"
  Generate code for the user mode, where the access to some general registers
! is forbidden: on the \s-1GR5,\s0 registers r24 to r31 cannot be accessed in this
! mode; on the \s-1GR6,\s0 only registers r29 to r31 are affected.
  .PP
! \fI\s-1VMS\s0 Options\fR
  .IX Subsection "VMS Options"
  .PP
! These \fB\-m\fR options are defined for the \s-1VMS\s0 implementations:
! .IP "\fB\-mvms\-return\-codes\fR" 4
  .IX Item "-mvms-return-codes"
! Return \s-1VMS\s0 condition codes from \f(CW\*(C`main\*(C'\fR. The default is to return POSIX-style
  condition (e.g. error) codes.
! .IP "\fB\-mdebug\-main=\fR\fIprefix\fR" 4
  .IX Item "-mdebug-main=prefix"
  Flag the first routine whose name starts with \fIprefix\fR as the main
  routine for the debugger.
! .IP "\fB\-mmalloc64\fR" 4
  .IX Item "-mmalloc64"
  Default to 64\-bit memory allocation routines.
! .IP "\fB\-mpointer\-size=\fR\fIsize\fR" 4
  .IX Item "-mpointer-size=size"
  Set the default size of pointers. Possible options for \fIsize\fR are
  \&\fB32\fR or \fBshort\fR for 32 bit pointers, \fB64\fR or \fBlong\fR
--- 31221,31263 ----
  .Sp
  \&\fBmcm\fR is a synonym of \fBgr5\fR present for backward compatibility.
  .Sp
! By default (unless configured otherwise), GCC generates code for the GR5
  variant of the Visium architecture.
  .Sp
! With \fB\-mcpu=gr6\fR, GCC generates code for the GR6 variant of the Visium
! architecture.  The only difference from GR5 code is that the compiler will
  generate block move instructions.
! .IP \fB\-mtune=\fR\fIcpu_type\fR 4
  .IX Item "-mtune=cpu_type"
  Set the instruction scheduling parameters for machine type \fIcpu_type\fR,
  but do not set the instruction set or register set that the option
  \&\fB\-mcpu=\fR\fIcpu_type\fR would.
! .IP \fB\-msv\-mode\fR 4
  .IX Item "-msv-mode"
  Generate code for the supervisor mode, where there are no restrictions on
  the access to general registers.  This is the default.
! .IP \fB\-muser\-mode\fR 4
  .IX Item "-muser-mode"
  Generate code for the user mode, where the access to some general registers
! is forbidden: on the GR5, registers r24 to r31 cannot be accessed in this
! mode; on the GR6, only registers r29 to r31 are affected.
  .PP
! \fIVMS Options\fR
  .IX Subsection "VMS Options"
  .PP
! These \fB\-m\fR options are defined for the VMS implementations:
! .IP \fB\-mvms\-return\-codes\fR 4
  .IX Item "-mvms-return-codes"
! Return VMS condition codes from \f(CW\*(C`main\*(C'\fR. The default is to return POSIX\-style
  condition (e.g. error) codes.
! .IP \fB\-mdebug\-main=\fR\fIprefix\fR 4
  .IX Item "-mdebug-main=prefix"
  Flag the first routine whose name starts with \fIprefix\fR as the main
  routine for the debugger.
! .IP \fB\-mmalloc64\fR 4
  .IX Item "-mmalloc64"
  Default to 64\-bit memory allocation routines.
! .IP \fB\-mpointer\-size=\fR\fIsize\fR 4
  .IX Item "-mpointer-size=size"
  Set the default size of pointers. Possible options for \fIsize\fR are
  \&\fB32\fR or \fBshort\fR for 32 bit pointers, \fB64\fR or \fBlong\fR
*************** The later option disables \f(CW\*(C`prag
*** 31339,31368 ****
  The options in this section are defined for all VxWorks targets.
  Options specific to the target hardware are listed with the other
  options for that target.
! .IP "\fB\-mrtp\fR" 4
  .IX Item "-mrtp"
! \&\s-1GCC\s0 can generate code for both VxWorks kernels and real time processes
  (RTPs).  This option switches from the former to the latter.  It also
  defines the preprocessor macro \f(CW\*(C`_\|_RTP_\|_\*(C'\fR.
! .IP "\fB\-non\-static\fR" 4
  .IX Item "-non-static"
! Link an \s-1RTP\s0 executable against shared libraries rather than static
  libraries.  The options \fB\-static\fR and \fB\-shared\fR can
  also be used for RTPs; \fB\-static\fR
  is the default.
! .IP "\fB\-Bstatic\fR" 4
  .IX Item "-Bstatic"
  .PD 0
! .IP "\fB\-Bdynamic\fR" 4
  .IX Item "-Bdynamic"
  .PD
  These options are passed down to the linker.  They are defined for
  compatibility with Diab.
! .IP "\fB\-Xbind\-lazy\fR" 4
  .IX Item "-Xbind-lazy"
  Enable lazy binding of function calls.  This option is equivalent to
  \&\fB\-Wl,\-z,now\fR and is defined for compatibility with Diab.
! .IP "\fB\-Xbind\-now\fR" 4
  .IX Item "-Xbind-now"
  Disable lazy binding of function calls.  This option is the default and
  is defined for compatibility with Diab.
--- 31270,31299 ----
  The options in this section are defined for all VxWorks targets.
  Options specific to the target hardware are listed with the other
  options for that target.
! .IP \fB\-mrtp\fR 4
  .IX Item "-mrtp"
! 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 \f(CW\*(C`_\|_RTP_\|_\*(C'\fR.
! .IP \fB\-non\-static\fR 4
  .IX Item "-non-static"
! Link an RTP executable against shared libraries rather than static
  libraries.  The options \fB\-static\fR and \fB\-shared\fR can
  also be used for RTPs; \fB\-static\fR
  is the default.
! .IP \fB\-Bstatic\fR 4
  .IX Item "-Bstatic"
  .PD 0
! .IP \fB\-Bdynamic\fR 4
  .IX Item "-Bdynamic"
  .PD
  These options are passed down to the linker.  They are defined for
  compatibility with Diab.
! .IP \fB\-Xbind\-lazy\fR 4
  .IX Item "-Xbind-lazy"
  Enable lazy binding of function calls.  This option is equivalent to
  \&\fB\-Wl,\-z,now\fR and is defined for compatibility with Diab.
! .IP \fB\-Xbind\-now\fR 4
  .IX Item "-Xbind-now"
  Disable lazy binding of function calls.  This option is the default and
  is defined for compatibility with Diab.
*************** is defined for compatibility with Diab.
*** 31371,31966 ****
  .IX Subsection "x86 Options"
  .PP
  These \fB\-m\fR options are defined for the x86 family of computers.
! .IP "\fB\-march=\fR\fIcpu-type\fR" 4
  .IX Item "-march=cpu-type"
! Generate instructions for the machine type \fIcpu-type\fR.  In contrast to
! \&\fB\-mtune=\fR\fIcpu-type\fR, which merely tunes the generated code 
! for the specified \fIcpu-type\fR, \fB\-march=\fR\fIcpu-type\fR allows \s-1GCC\s0
  to generate code that may not run at all on processors other than the one
! indicated.  Specifying \fB\-march=\fR\fIcpu-type\fR implies 
! \&\fB\-mtune=\fR\fIcpu-type\fR, except where noted otherwise.
  .Sp
! The choices for \fIcpu-type\fR are:
  .RS 4
! .IP "\fBnative\fR" 4
  .IX Item "native"
! This selects the \s-1CPU\s0 to generate code for at compilation time by determining
  the processor type of the compiling machine.  Using \fB\-march=native\fR
  enables all instruction subsets supported by the local machine (hence
  the result might not run on different machines).  Using \fB\-mtune=native\fR
  produces code optimized for the local machine under the constraints
  of the selected instruction set.
! .IP "\fBx86\-64\fR" 4
  .IX Item "x86-64"
! A generic \s-1CPU\s0 with 64\-bit extensions.
! .IP "\fBx86\-64\-v2\fR" 4
  .IX Item "x86-64-v2"
  .PD 0
! .IP "\fBx86\-64\-v3\fR" 4
  .IX Item "x86-64-v3"
! .IP "\fBx86\-64\-v4\fR" 4
  .IX Item "x86-64-v4"
  .PD
! These choices for \fIcpu-type\fR select the corresponding
! micro-architecture level from the x86\-64 psABI.  On ABIs other than
! the x86\-64 psABI they select the same \s-1CPU\s0 features as the x86\-64 psABI
! documents for the particular micro-architecture level.
  .Sp
! Since these \fIcpu-type\fR values do not have a corresponding
  \&\fB\-mtune\fR setting, using \fB\-march\fR with these values enables
  generic tuning.  Specific tuning can be enabled using the
! \&\fB\-mtune=\fR\fIother-cpu-type\fR option with an appropriate
! \&\fIother-cpu-type\fR value.
! .IP "\fBi386\fR" 4
  .IX Item "i386"
! Original Intel i386 \s-1CPU.\s0
! .IP "\fBi486\fR" 4
  .IX Item "i486"
! Intel i486 \s-1CPU.\s0  (No scheduling is implemented for this chip.)
! .IP "\fBi586\fR" 4
  .IX Item "i586"
  .PD 0
! .IP "\fBpentium\fR" 4
  .IX Item "pentium"
  .PD
! Intel Pentium \s-1CPU\s0 with no \s-1MMX\s0 support.
! .IP "\fBlakemont\fR" 4
  .IX Item "lakemont"
! Intel Lakemont \s-1MCU,\s0 based on Intel Pentium \s-1CPU.\s0
! .IP "\fBpentium-mmx\fR" 4
  .IX Item "pentium-mmx"
! Intel Pentium \s-1MMX CPU,\s0 based on Pentium core with \s-1MMX\s0 instruction set support.
! .IP "\fBpentiumpro\fR" 4
  .IX Item "pentiumpro"
! Intel Pentium Pro \s-1CPU.\s0
! .IP "\fBi686\fR" 4
  .IX Item "i686"
  When used with \fB\-march\fR, the Pentium Pro
  instruction set is used, so the code runs on all i686 family chips.
  When used with \fB\-mtune\fR, it has the same meaning as \fBgeneric\fR.
! .IP "\fBpentium2\fR" 4
  .IX Item "pentium2"
! Intel Pentium \s-1II CPU,\s0 based on Pentium Pro core with \s-1MMX\s0 and \s-1FXSR\s0 instruction
  set support.
! .IP "\fBpentium3\fR" 4
  .IX Item "pentium3"
  .PD 0
! .IP "\fBpentium3m\fR" 4
  .IX Item "pentium3m"
  .PD
! Intel Pentium \s-1III CPU,\s0 based on Pentium Pro core with \s-1MMX, FXSR\s0 and \s-1SSE\s0
  instruction set support.
! .IP "\fBpentium-m\fR" 4
  .IX Item "pentium-m"
! Intel Pentium M; low-power version of Intel Pentium \s-1III CPU\s0
! with \s-1MMX, SSE, SSE2\s0 and \s-1FXSR\s0 instruction set support.  Used by Centrino
  notebooks.
! .IP "\fBpentium4\fR" 4
  .IX Item "pentium4"
  .PD 0
! .IP "\fBpentium4m\fR" 4
  .IX Item "pentium4m"
  .PD
! Intel Pentium 4 \s-1CPU\s0 with \s-1MMX, SSE, SSE2\s0 and \s-1FXSR\s0 instruction set support.
! .IP "\fBprescott\fR" 4
  .IX Item "prescott"
! Improved version of Intel Pentium 4 \s-1CPU\s0 with \s-1MMX, SSE, SSE2, SSE3\s0 and \s-1FXSR\s0
  instruction set support.
! .IP "\fBnocona\fR" 4
  .IX Item "nocona"
! Improved version of Intel Pentium 4 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE,
! SSE2, SSE3\s0 and \s-1FXSR\s0 instruction set support.
! .IP "\fBcore2\fR" 4
  .IX Item "core2"
! Intel Core 2 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3, CX16,
! SAHF\s0 and \s-1FXSR\s0 instruction set support.
! .IP "\fBnehalem\fR" 4
  .IX Item "nehalem"
  .PD 0
! .IP "\fBcorei7\fR" 4
  .IX Item "corei7"
  .PD
! Intel Nehalem \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF\s0 and \s-1FXSR\s0 instruction set support.
! .IP "\fBwestmere\fR" 4
  .IX Item "westmere"
! Intel Westmere \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR\s0 and \s-1PCLMUL\s0 instruction set support.
! .IP "\fBsandybridge\fR" 4
  .IX Item "sandybridge"
  .PD 0
! .IP "\fBcorei7\-avx\fR" 4
  .IX Item "corei7-avx"
  .PD
! Intel Sandy Bridge \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE\s0 and \s-1PCLMUL\s0 instruction set
  support.
! .IP "\fBivybridge\fR" 4
  .IX Item "ivybridge"
  .PD 0
! .IP "\fBcore-avx-i\fR" 4
  .IX Item "core-avx-i"
  .PD
! Intel Ivy Bridge \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND\s0
  and F16C instruction set support.
! .IP "\fBhaswell\fR" 4
  .IX Item "haswell"
  .PD 0
! .IP "\fBcore\-avx2\fR" 4
  .IX Item "core-avx2"
  .PD
! Intel Haswell \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
! F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE\s0 and \s-1HLE\s0 instruction set support.
! .IP "\fBbroadwell\fR" 4
  .IX Item "broadwell"
! Intel Broadwell \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
! F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX\s0 and \s-1PREFETCHW\s0
  instruction set support.
! .IP "\fBskylake\fR" 4
  .IX Item "skylake"
! Intel Skylake \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
! CLFLUSHOPT, XSAVEC, XSAVES\s0 and \s-1SGX\s0 instruction set support.
! .IP "\fBskylake\-avx512\fR" 4
  .IX Item "skylake-avx512"
! Intel Skylake Server \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW,
! AVX512DQ\s0 and \s-1AVX512CD\s0 instruction set support.
! .IP "\fBcascadelake\fR" 4
  .IX Item "cascadelake"
! Intel Cascade Lake \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ,
! AVX512CD\s0 and \s-1AVX512VNNI\s0 instruction set support.
! .IP "\fBcannonlake\fR" 4
  .IX Item "cannonlake"
! Intel Cannon Lake Server \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2,
  SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL,
  FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX,
  PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW,
! AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA\s0 and \s-1SHA\s0 instruction set
  support.
! .IP "\fBcooperlake\fR" 4
  .IX Item "cooperlake"
! Intel Cooper Lake \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ,
! AVX512CD, AVX512VNNI\s0 and \s-1AVX512BF16\s0 instruction set support.
! .IP "\fBicelake-client\fR" 4
  .IX Item "icelake-client"
! Intel Ice Lake Client \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2
! , VPCLMULQDQ, AVX512BITALG, RDPID\s0 and \s-1AVX512VPOPCNTDQ\s0 instruction set support.
! .IP "\fBicelake-server\fR" 4
  .IX Item "icelake-server"
! Intel Ice Lake Server \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2
! , VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD\s0 and \s-1CLWB\s0
  instruction set support.
! .IP "\fBtigerlake\fR" 4
  .IX Item "tigerlake"
! Intel Tiger Lake \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD
  PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, MOVDIRI, MOVDIR64B, CLWB,
! AVX512VP2INTERSECT\s0 and \s-1KEYLOCKER\s0 instruction set support.
! .IP "\fBrocketlake\fR" 4
  .IX Item "rocketlake"
! Intel Rocket Lake \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD
  PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
! VPCLMULQDQ, AVX512BITALG, RDPID\s0 and \s-1AVX512VPOPCNTDQ\s0 instruction set support.
! .IP "\fBalderlake\fR" 4
  .IX Item "alderlake"
  .PD 0
! .IP "\fBraptorlake\fR" 4
  .IX Item "raptorlake"
! .IP "\fBmeteorlake\fR" 4
  .IX Item "meteorlake"
  .PD
! Intel Alder Lake/Raptor Lake/Meteor Lake \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX,
! SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND,
! XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX,\s0 GFNI-SSE, \s-1CLWB,
! MOVDIRI, MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA,
! LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL\s0 and
! AVX-VNNI instruction set support.
! .IP "\fBsapphirerapids\fR" 4
  .IX Item "sapphirerapids"
  .PD 0
! .IP "\fBemeraldrapids\fR" 4
  .IX Item "emeraldrapids"
  .PD
! Intel Sapphire Rapids/Emerald Rapids \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE,
  SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL,
  FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX,
  PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW,
  AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES,
  AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG,
  WBNOINVD, CLWB, MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG,
! SERIALIZE, TSXLDTRK, UINTR, AMX\-BF16,\s0 AMX-TILE, \s-1AMX\-INT8,\s0 AVX-VNNI, \s-1AVX512\-FP16\s0
! and \s-1AVX512BF16\s0 instruction set support.
! .IP "\fBgraniterapids\fR" 4
  .IX Item "graniterapids"
! Intel Granite Rapids \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB,
  MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK,
! UINTR, AMX\-BF16,\s0 AMX-TILE, \s-1AMX\-INT8,\s0 AVX-VNNI, \s-1AVX512\-FP16, AVX512BF16, AMX\-FP16\s0
! and \s-1PREFETCHI\s0 instruction set support.
! .IP "\fBgraniterapids-d\fR" 4
  .IX Item "graniterapids-d"
! Intel Granite Rapids D \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB,
  MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK,
! UINTR, AMX\-BF16,\s0 AMX-TILE, \s-1AMX\-INT8,\s0 AVX-VNNI, \s-1AVX512FP16, AVX512BF16, AMX\-FP16,
! PREFETCHI\s0 and AMX-COMPLEX instruction set support.
! .IP "\fBbonnell\fR" 4
  .IX Item "bonnell"
  .PD 0
! .IP "\fBatom\fR" 4
  .IX Item "atom"
  .PD
! Intel Bonnell \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
  instruction set support.
! .IP "\fBsilvermont\fR" 4
  .IX Item "silvermont"
  .PD 0
! .IP "\fBslm\fR" 4
  .IX Item "slm"
  .PD
! Intel Silvermont \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW\s0 and \s-1RDRND\s0
  instruction set support.
! .IP "\fBgoldmont\fR" 4
  .IX Item "goldmont"
! Intel Goldmont \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA,
! RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT\s0 and \s-1FSGSBASE\s0 instruction
  set support.
! .IP "\fBgoldmont-plus\fR" 4
  .IX Item "goldmont-plus"
! Intel Goldmont Plus \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES,
  SHA, RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE,
! RDPID\s0 and \s-1SGX\s0 instruction set support.
! .IP "\fBtremont\fR" 4
  .IX Item "tremont"
! Intel Tremont \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA,
  RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE, RDPID,
! SGX, CLWB,\s0 GFNI-SSE, \s-1MOVDIRI, MOVDIR64B, CLDEMOTE\s0 and \s-1WAITPKG\s0 instruction set
  support.
! .IP "\fBsierraforest\fR" 4
  .IX Item "sierraforest"
! Intel Sierra Forest \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC,
! XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX,\s0 GFNI-SSE, \s-1CLWB, MOVDIRI,
  MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT,
! PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL,\s0 AVX-VNNI,
! \&\s-1AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, ENQCMD\s0 and \s-1UINTR\s0 instruction set
  support.
! .IP "\fBgrandridge\fR" 4
  .IX Item "grandridge"
! Intel Grand Ridge \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC,
! XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX,\s0 GFNI-SSE, \s-1CLWB, MOVDIRI,
  MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT,
! PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL,\s0 AVX-VNNI,
! \&\s-1AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, ENQCMD\s0 and \s-1UINTR\s0 instruction set
  support.
! .IP "\fBknl\fR" 4
  .IX Item "knl"
! Intel Knights Landing \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
! AVX512PF, AVX512ER, AVX512F, AVX512CD\s0 and \s-1PREFETCHWT1\s0 instruction set support.
! .IP "\fBknm\fR" 4
  .IX Item "knm"
! Intel Knights Mill \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
! AVX512PF, AVX512ER, AVX512F, AVX512CD\s0 and \s-1PREFETCHWT1, AVX5124VNNIW,
! AVX5124FMAPS\s0 and \s-1AVX512VPOPCNTDQ\s0 instruction set support.
! .IP "\fBk6\fR" 4
  .IX Item "k6"
! \&\s-1AMD K6 CPU\s0 with \s-1MMX\s0 instruction set support.
! .IP "\fBk6\-2\fR" 4
  .IX Item "k6-2"
  .PD 0
! .IP "\fBk6\-3\fR" 4
  .IX Item "k6-3"
  .PD
! Improved versions of \s-1AMD K6 CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
! .IP "\fBathlon\fR" 4
  .IX Item "athlon"
  .PD 0
! .IP "\fBathlon-tbird\fR" 4
  .IX Item "athlon-tbird"
  .PD
! \&\s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX,\s0 3dNOW!, enhanced 3DNow! and \s-1SSE\s0 prefetch instructions
  support.
! .IP "\fBathlon\-4\fR" 4
  .IX Item "athlon-4"
  .PD 0
! .IP "\fBathlon-xp\fR" 4
  .IX Item "athlon-xp"
! .IP "\fBathlon-mp\fR" 4
  .IX Item "athlon-mp"
  .PD
! Improved \s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX,\s0 3DNow!, enhanced 3DNow! and full \s-1SSE\s0
  instruction set support.
! .IP "\fBk8\fR" 4
  .IX Item "k8"
  .PD 0
! .IP "\fBopteron\fR" 4
  .IX Item "opteron"
! .IP "\fBathlon64\fR" 4
  .IX Item "athlon64"
! .IP "\fBathlon-fx\fR" 4
  .IX Item "athlon-fx"
  .PD
! Processors based on the \s-1AMD K8\s0 core with x86\-64 instruction set support,
! including the \s-1AMD\s0 Opteron, Athlon 64, and Athlon 64 \s-1FX\s0 processors.
! (This supersets \s-1MMX, SSE, SSE2,\s0 3DNow!, enhanced 3DNow! and 64\-bit
  instruction set extensions.)
! .IP "\fBk8\-sse3\fR" 4
  .IX Item "k8-sse3"
  .PD 0
! .IP "\fBopteron\-sse3\fR" 4
  .IX Item "opteron-sse3"
! .IP "\fBathlon64\-sse3\fR" 4
  .IX Item "athlon64-sse3"
  .PD
! Improved versions of \s-1AMD K8\s0 cores with \s-1SSE3\s0 instruction set support.
! .IP "\fBamdfam10\fR" 4
  .IX Item "amdfam10"
  .PD 0
! .IP "\fBbarcelona\fR" 4
  .IX Item "barcelona"
  .PD
! CPUs based on \s-1AMD\s0 Family 10h cores with x86\-64 instruction set support.  (This
! supersets \s-1MMX, SSE, SSE2, SSE3, SSE4A,\s0 3DNow!, enhanced 3DNow!, \s-1ABM\s0 and 64\-bit
  instruction set extensions.)
! .IP "\fBbdver1\fR" 4
  .IX Item "bdver1"
! CPUs based on \s-1AMD\s0 Family 15h cores with x86\-64 instruction set support.  (This
! supersets \s-1FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A,
! SSSE3, SSE4.1, SSE4.2, ABM\s0 and 64\-bit instruction set extensions.)
! .IP "\fBbdver2\fR" 4
  .IX Item "bdver2"
! \&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets \s-1BMI, TBM, F16C, FMA, FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX,
! SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM\s0 and 64\-bit instruction set 
  extensions.)
! .IP "\fBbdver3\fR" 4
  .IX Item "bdver3"
! \&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets \s-1BMI, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, XOP, LWP, AES,\s0 
! \&\s-1PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM\s0 and
  64\-bit instruction set extensions.)
! .IP "\fBbdver4\fR" 4
  .IX Item "bdver4"
! \&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets \s-1BMI, BMI2, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, AVX2, XOP, LWP,\s0 
! \&\s-1AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1,
! SSE4.2, ABM\s0 and 64\-bit instruction set extensions.)
! .IP "\fBznver1\fR" 4
  .IX Item "znver1"
! \&\s-1AMD\s0 Family 17h core based CPUs with x86\-64 instruction set support.  (This
! supersets \s-1BMI, BMI2, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX,
  SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3,
! SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT,\s0 and 64\-bit
  instruction set extensions.)
! .IP "\fBznver2\fR" 4
  .IX Item "znver2"
! \&\s-1AMD\s0 Family 17h core based CPUs with x86\-64 instruction set support. (This
! supersets \s-1BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
! WBNOINVD,\s0 and 64\-bit instruction set extensions.)
! .IP "\fBznver3\fR" 4
  .IX Item "znver3"
! \&\s-1AMD\s0 Family 19h core based CPUs with x86\-64 instruction set support. (This
! supersets \s-1BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
! WBNOINVD, PKU, VPCLMULQDQ, VAES,\s0 and 64\-bit instruction set extensions.)
! .IP "\fBznver4\fR" 4
  .IX Item "znver4"
! \&\s-1AMD\s0 Family 19h core based CPUs with x86\-64 instruction set support. (This
! supersets \s-1BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
  WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD,
  AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI,
! AVX512BITALG, AVX512VPOPCNTDQ, GFNI\s0 and 64\-bit instruction set extensions.)
! .IP "\fBznver5\fR" 4
  .IX Item "znver5"
! \&\s-1AMD\s0 Family 1ah core based CPUs with x86\-64 instruction set support. (This
! supersets \s-1BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
  WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD,
  AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI,
  AVX512BITALG, AVX512VPOPCNTDQ, GFNI, AVXVNNI, MOVDIRI, MOVDIR64B,
! AVX512VP2INTERSECT, PREFETCHI\s0 and 64\-bit instruction set extensions.)
! .IP "\fBbtver1\fR" 4
  .IX Item "btver1"
! CPUs based on \s-1AMD\s0 Family 14h cores with x86\-64 instruction set support.  (This
! supersets \s-1MMX, SSE, SSE2, SSE3, SSSE3, SSE4A, CX16, ABM\s0 and 64\-bit
  instruction set extensions.)
! .IP "\fBbtver2\fR" 4
  .IX Item "btver2"
! CPUs based on \s-1AMD\s0 Family 16h cores with x86\-64 instruction set support. This
! includes \s-1MOVBE, F16C, BMI, AVX, PCLMUL, AES, SSE4.2, SSE4.1, CX16, ABM,
! SSE4A, SSSE3, SSE3, SSE2, SSE, MMX\s0 and 64\-bit instruction set extensions.
! .IP "\fBwinchip\-c6\fR" 4
  .IX Item "winchip-c6"
! \&\s-1IDT\s0 WinChip C6 \s-1CPU,\s0 dealt in same way as i486 with additional \s-1MMX\s0 instruction
  set support.
! .IP "\fBwinchip2\fR" 4
  .IX Item "winchip2"
! \&\s-1IDT\s0 WinChip 2 \s-1CPU,\s0 dealt in same way as i486 with additional \s-1MMX\s0 and 3DNow!
  instruction set support.
! .IP "\fBc3\fR" 4
  .IX Item "c3"
! \&\s-1VIA C3 CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBc3\-2\fR" 4
  .IX Item "c3-2"
! \&\s-1VIA C3\-2\s0 (Nehemiah/C5XL) \s-1CPU\s0 with \s-1MMX\s0 and \s-1SSE\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBc7\fR" 4
  .IX Item "c7"
! \&\s-1VIA C7\s0 (Esther) \s-1CPU\s0 with \s-1MMX, SSE, SSE2\s0 and \s-1SSE3\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBsamuel\-2\fR" 4
  .IX Item "samuel-2"
! \&\s-1VIA\s0 Eden Samuel 2 \s-1CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnehemiah\fR" 4
  .IX Item "nehemiah"
! \&\s-1VIA\s0 Eden Nehemiah \s-1CPU\s0 with \s-1MMX\s0 and \s-1SSE\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBesther\fR" 4
  .IX Item "esther"
! \&\s-1VIA\s0 Eden Esther \s-1CPU\s0 with \s-1MMX, SSE, SSE2\s0 and \s-1SSE3\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBeden\-x2\fR" 4
  .IX Item "eden-x2"
! \&\s-1VIA\s0 Eden X2 \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2\s0 and \s-1SSE3\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBeden\-x4\fR" 4
  .IX Item "eden-x4"
! \&\s-1VIA\s0 Eden X4 \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2,
! AVX\s0 and \s-1AVX2\s0 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\fR" 4
  .IX Item "nano"
! Generic \s-1VIA\s0 Nano \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\-1000\fR" 4
  .IX Item "nano-1000"
! \&\s-1VIA\s0 Nano 1xxx \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\-2000\fR" 4
  .IX Item "nano-2000"
! \&\s-1VIA\s0 Nano 2xxx \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\-3000\fR" 4
  .IX Item "nano-3000"
! \&\s-1VIA\s0 Nano 3xxx \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3, SSSE3\s0 and \s-1SSE4.1\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\-x2\fR" 4
  .IX Item "nano-x2"
! \&\s-1VIA\s0 Nano Dual Core \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3, SSSE3\s0 and \s-1SSE4.1\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBnano\-x4\fR" 4
  .IX Item "nano-x4"
! \&\s-1VIA\s0 Nano Quad Core \s-1CPU\s0 with x86\-64, \s-1MMX, SSE, SSE2, SSE3, SSSE3\s0 and \s-1SSE4.1\s0
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP "\fBlujiazui\fR" 4
  .IX Item "lujiazui"
! \&\s-1ZHAOXIN\s0 lujiazui \s-1CPU\s0 with x86\-64, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
  SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16,
! ABM, BMI, BMI2, FXSR, RDSEED\s0 instruction set support.  While the CPUs
! do support \s-1AVX\s0 and F16C, these aren't enabled by \f(CW\*(C`\-march=lujiazui\*(C'\fR
  for performance reasons.
! .IP "\fBgeode\fR" 4
  .IX Item "geode"
! \&\s-1AMD\s0 Geode embedded processor with \s-1MMX\s0 and 3DNow! instruction set support.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
  .IX Item "-mtune=cpu-type"
! Tune to \fIcpu-type\fR everything applicable about the generated code, except
! for the \s-1ABI\s0 and the set of available instructions.  
! While picking a specific \fIcpu-type\fR schedules things appropriately
  for that particular chip, the compiler does not generate any code that
  cannot run on the default machine type unless you use a
! \&\fB\-march=\fR\fIcpu-type\fR option.
! For example, if \s-1GCC\s0 is configured for i686\-pc\-linux\-gnu
  then \fB\-mtune=pentium4\fR generates code that is tuned for Pentium 4
  but still runs on i686 machines.
  .Sp
! The choices for \fIcpu-type\fR are the same as for \fB\-march\fR.
! In addition, \fB\-mtune\fR supports 2 extra choices for \fIcpu-type\fR:
  .RS 4
! .IP "\fBgeneric\fR" 4
  .IX Item "generic"
! Produce code optimized for the most common \s-1IA32/AMD64/EM64T\s0 processors.
! If you know the \s-1CPU\s0 on which your code will run, then you should use
  the corresponding \fB\-mtune\fR or \fB\-march\fR option instead of
! \&\fB\-mtune=generic\fR.  But, if you do not know exactly what \s-1CPU\s0 users
  of your application will have, then you should use this option.
  .Sp
  As new processors are deployed in the marketplace, the behavior of this
  option will change.  Therefore, if you upgrade to a newer version of
! \&\s-1GCC,\s0 code generation controlled by this option will change to reflect
  the processors
! that are most common at the time that version of \s-1GCC\s0 is released.
  .Sp
  There is no \fB\-march=generic\fR option because \fB\-march\fR
  indicates the instruction set the compiler can use, and there is no
  generic instruction set applicable to all processors.  In contrast,
  \&\fB\-mtune\fR indicates the processor (or, in this case, collection of
  processors) for which the code is optimized.
! .IP "\fBintel\fR" 4
  .IX Item "intel"
  Produce code optimized for the most current Intel processors, which are
! Haswell and Silvermont for this version of \s-1GCC.\s0  If you know the \s-1CPU\s0
  on which your code will run, then you should use the corresponding
  \&\fB\-mtune\fR or \fB\-march\fR option instead of \fB\-mtune=intel\fR.
  But, if you want your application performs better on both Haswell and
--- 31302,31897 ----
  .IX Subsection "x86 Options"
  .PP
  These \fB\-m\fR options are defined for the x86 family of computers.
! .IP \fB\-march=\fR\fIcpu\-type\fR 4
  .IX Item "-march=cpu-type"
! Generate instructions for the machine type \fIcpu\-type\fR.  In contrast to
! \&\fB\-mtune=\fR\fIcpu\-type\fR, which merely tunes the generated code 
! for the specified \fIcpu\-type\fR, \fB\-march=\fR\fIcpu\-type\fR allows GCC
  to generate code that may not run at all on processors other than the one
! indicated.  Specifying \fB\-march=\fR\fIcpu\-type\fR implies 
! \&\fB\-mtune=\fR\fIcpu\-type\fR, except where noted otherwise.
  .Sp
! The choices for \fIcpu\-type\fR are:
  .RS 4
! .IP \fBnative\fR 4
  .IX Item "native"
! This selects the CPU to generate code for at compilation time by determining
  the processor type of the compiling machine.  Using \fB\-march=native\fR
  enables all instruction subsets supported by the local machine (hence
  the result might not run on different machines).  Using \fB\-mtune=native\fR
  produces code optimized for the local machine under the constraints
  of the selected instruction set.
! .IP \fBx86\-64\fR 4
  .IX Item "x86-64"
! A generic CPU with 64\-bit extensions.
! .IP \fBx86\-64\-v2\fR 4
  .IX Item "x86-64-v2"
  .PD 0
! .IP \fBx86\-64\-v3\fR 4
  .IX Item "x86-64-v3"
! .IP \fBx86\-64\-v4\fR 4
  .IX Item "x86-64-v4"
  .PD
! These choices for \fIcpu\-type\fR select the corresponding
! micro\-architecture level from the x86\-64 psABI.  On ABIs other than
! the x86\-64 psABI they select the same CPU features as the x86\-64 psABI
! documents for the particular micro\-architecture level.
  .Sp
! Since these \fIcpu\-type\fR values do not have a corresponding
  \&\fB\-mtune\fR setting, using \fB\-march\fR with these values enables
  generic tuning.  Specific tuning can be enabled using the
! \&\fB\-mtune=\fR\fIother\-cpu\-type\fR option with an appropriate
! \&\fIother\-cpu\-type\fR value.
! .IP \fBi386\fR 4
  .IX Item "i386"
! Original Intel i386 CPU.
! .IP \fBi486\fR 4
  .IX Item "i486"
! Intel i486 CPU.  (No scheduling is implemented for this chip.)
! .IP \fBi586\fR 4
  .IX Item "i586"
  .PD 0
! .IP \fBpentium\fR 4
  .IX Item "pentium"
  .PD
! Intel Pentium CPU with no MMX support.
! .IP \fBlakemont\fR 4
  .IX Item "lakemont"
! Intel Lakemont MCU, based on Intel Pentium CPU.
! .IP \fBpentium\-mmx\fR 4
  .IX Item "pentium-mmx"
! Intel Pentium MMX CPU, based on Pentium core with MMX instruction set support.
! .IP \fBpentiumpro\fR 4
  .IX Item "pentiumpro"
! Intel Pentium Pro CPU.
! .IP \fBi686\fR 4
  .IX Item "i686"
  When used with \fB\-march\fR, the Pentium Pro
  instruction set is used, so the code runs on all i686 family chips.
  When used with \fB\-mtune\fR, it has the same meaning as \fBgeneric\fR.
! .IP \fBpentium2\fR 4
  .IX Item "pentium2"
! Intel Pentium II CPU, based on Pentium Pro core with MMX and FXSR instruction
  set support.
! .IP \fBpentium3\fR 4
  .IX Item "pentium3"
  .PD 0
! .IP \fBpentium3m\fR 4
  .IX Item "pentium3m"
  .PD
! Intel Pentium III CPU, based on Pentium Pro core with MMX, FXSR and SSE
  instruction set support.
! .IP \fBpentium\-m\fR 4
  .IX Item "pentium-m"
! Intel Pentium M; low\-power version of Intel Pentium III CPU
! with MMX, SSE, SSE2 and FXSR instruction set support.  Used by Centrino
  notebooks.
! .IP \fBpentium4\fR 4
  .IX Item "pentium4"
  .PD 0
! .IP \fBpentium4m\fR 4
  .IX Item "pentium4m"
  .PD
! Intel Pentium 4 CPU with MMX, SSE, SSE2 and FXSR instruction set support.
! .IP \fBprescott\fR 4
  .IX Item "prescott"
! Improved version of Intel Pentium 4 CPU with MMX, SSE, SSE2, SSE3 and FXSR
  instruction set support.
! .IP \fBnocona\fR 4
  .IX Item "nocona"
! Improved version of Intel Pentium 4 CPU with 64\-bit extensions, MMX, SSE,
! SSE2, SSE3 and FXSR instruction set support.
! .IP \fBcore2\fR 4
  .IX Item "core2"
! Intel Core 2 CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3, CX16,
! SAHF and FXSR instruction set support.
! .IP \fBnehalem\fR 4
  .IX Item "nehalem"
  .PD 0
! .IP \fBcorei7\fR 4
  .IX Item "corei7"
  .PD
! Intel Nehalem CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF and FXSR instruction set support.
! .IP \fBwestmere\fR 4
  .IX Item "westmere"
! Intel Westmere CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR and PCLMUL instruction set support.
! .IP \fBsandybridge\fR 4
  .IX Item "sandybridge"
  .PD 0
! .IP \fBcorei7\-avx\fR 4
  .IX Item "corei7-avx"
  .PD
! Intel Sandy Bridge CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE and PCLMUL instruction set
  support.
! .IP \fBivybridge\fR 4
  .IX Item "ivybridge"
  .PD 0
! .IP \fBcore\-avx\-i\fR 4
  .IX Item "core-avx-i"
  .PD
! Intel Ivy Bridge CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND
  and F16C instruction set support.
! .IP \fBhaswell\fR 4
  .IX Item "haswell"
  .PD 0
! .IP \fBcore\-avx2\fR 4
  .IX Item "core-avx2"
  .PD
! Intel Haswell CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
! F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE and HLE instruction set support.
! .IP \fBbroadwell\fR 4
  .IX Item "broadwell"
! Intel Broadwell CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
! F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX and PREFETCHW
  instruction set support.
! .IP \fBskylake\fR 4
  .IX Item "skylake"
! Intel Skylake CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
! CLFLUSHOPT, XSAVEC, XSAVES and SGX instruction set support.
! .IP \fBskylake\-avx512\fR 4
  .IX Item "skylake-avx512"
! Intel Skylake Server CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW,
! AVX512DQ and AVX512CD instruction set support.
! .IP \fBcascadelake\fR 4
  .IX Item "cascadelake"
! Intel Cascade Lake CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ,
! AVX512CD and AVX512VNNI instruction set support.
! .IP \fBcannonlake\fR 4
  .IX Item "cannonlake"
! Intel Cannon Lake Server CPU with 64\-bit extensions, MMX, SSE, SSE2,
  SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL,
  FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX,
  PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW,
! AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA and SHA instruction set
  support.
! .IP \fBcooperlake\fR 4
  .IX Item "cooperlake"
! Intel Cooper Lake CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW, AVX512DQ,
! AVX512CD, AVX512VNNI and AVX512BF16 instruction set support.
! .IP \fBicelake\-client\fR 4
  .IX Item "icelake-client"
! Intel Ice Lake Client CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2
! , VPCLMULQDQ, AVX512BITALG, RDPID and AVX512VPOPCNTDQ instruction set support.
! .IP \fBicelake\-server\fR 4
  .IX Item "icelake-server"
! Intel Ice Lake Server CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2
! , VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD and CLWB
  instruction set support.
! .IP \fBtigerlake\fR 4
  .IX Item "tigerlake"
! Intel Tiger Lake CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD
  PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, MOVDIRI, MOVDIR64B, CLWB,
! AVX512VP2INTERSECT and KEYLOCKER instruction set support.
! .IP \fBrocketlake\fR 4
  .IX Item "rocketlake"
! Intel Rocket Lake CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
  F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
  CLFLUSHOPT, XSAVEC, XSAVES, AVX512F, AVX512VL, AVX512BW, AVX512DQ, AVX512CD
  PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
! VPCLMULQDQ, AVX512BITALG, RDPID and AVX512VPOPCNTDQ instruction set support.
! .IP \fBalderlake\fR 4
  .IX Item "alderlake"
  .PD 0
! .IP \fBraptorlake\fR 4
  .IX Item "raptorlake"
! .IP \fBmeteorlake\fR 4
  .IX Item "meteorlake"
  .PD
! Intel Alder Lake/Raptor Lake/Meteor Lake CPU with 64\-bit extensions, MOVBE,
! MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL,
! RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX,
! GFNI\-SSE, CLWB, MOVDIRI, MOVDIR64B, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C,
! FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL and
! AVX\-VNNI instruction set support.
! .IP \fBsapphirerapids\fR 4
  .IX Item "sapphirerapids"
  .PD 0
! .IP \fBemeraldrapids\fR 4
  .IX Item "emeraldrapids"
  .PD
! Intel Sapphire Rapids/Emerald Rapids CPU with 64\-bit extensions, MMX, SSE,
  SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL,
  FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX,
  PREFETCHW, AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW,
  AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES,
  AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG,
  WBNOINVD, CLWB, MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG,
! SERIALIZE, TSXLDTRK, UINTR, AMX\-BF16, AMX\-TILE, AMX\-INT8, AVX\-VNNI, AVX512\-FP16
! and AVX512BF16 instruction set support.
! .IP \fBgraniterapids\fR 4
  .IX Item "graniterapids"
! Intel Granite Rapids CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB,
  MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK,
! UINTR, AMX\-BF16, AMX\-TILE, AMX\-INT8, AVX\-VNNI, AVX512\-FP16, AVX512BF16, AMX\-FP16
! and PREFETCHI instruction set support.
! .IP \fBgraniterapids\-d\fR 4
  .IX Item "graniterapids-d"
! Intel Granite Rapids D CPU with 64\-bit extensions, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
  AES, CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, AVX512VL, AVX512BW, AVX512DQ,
  AVX512CD, PKU, AVX512VBMI, AVX512IFMA, SHA, AVX512VNNI, GFNI, VAES, AVX512VBMI2,
  VPCLMULQDQ, AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD, CLWB,
  MOVDIRI, MOVDIR64B, ENQCMD, CLDEMOTE, PTWRITE, WAITPKG, SERIALIZE, TSXLDTRK,
! UINTR, AMX\-BF16, AMX\-TILE, AMX\-INT8, AVX\-VNNI, AVX512FP16, AVX512BF16, AMX\-FP16,
! PREFETCHI and AMX\-COMPLEX instruction set support.
! .IP \fBbonnell\fR 4
  .IX Item "bonnell"
  .PD 0
! .IP \fBatom\fR 4
  .IX Item "atom"
  .PD
! Intel Bonnell CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3 and SSSE3
  instruction set support.
! .IP \fBsilvermont\fR 4
  .IX Item "silvermont"
  .PD 0
! .IP \fBslm\fR 4
  .IX Item "slm"
  .PD
! Intel Silvermont CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
! SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW and RDRND
  instruction set support.
! .IP \fBgoldmont\fR 4
  .IX Item "goldmont"
! Intel Goldmont CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA,
! RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT and FSGSBASE instruction
  set support.
! .IP \fBgoldmont\-plus\fR 4
  .IX Item "goldmont-plus"
! Intel Goldmont Plus CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES,
  SHA, RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE,
! RDPID and SGX instruction set support.
! .IP \fBtremont\fR 4
  .IX Item "tremont"
! Intel Tremont CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
  SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA,
  RDSEED, XSAVE, XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE, RDPID,
! SGX, CLWB, GFNI\-SSE, MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG instruction set
  support.
! .IP \fBsierraforest\fR 4
  .IX Item "sierraforest"
! Intel Sierra Forest CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC,
! XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI\-SSE, CLWB, MOVDIRI,
  MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT,
! PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX\-VNNI,
! AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, ENQCMD and UINTR instruction set
  support.
! .IP \fBgrandridge\fR 4
  .IX Item "grandridge"
! Intel Grand Ridge CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC,
! XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI\-SSE, CLWB, MOVDIRI,
  MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA, LZCNT,
! PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL, AVX\-VNNI,
! AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, ENQCMD and UINTR instruction set
  support.
! .IP \fBknl\fR 4
  .IX Item "knl"
! Intel Knights Landing CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
! AVX512PF, AVX512ER, AVX512F, AVX512CD and PREFETCHWT1 instruction set support.
! .IP \fBknm\fR 4
  .IX Item "knm"
! Intel Knights Mill CPU with 64\-bit extensions, MOVBE, MMX, SSE, SSE2, SSE3,
  SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE,
  RDRND, F16C, AVX2, BMI, BMI2, LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW,
! AVX512PF, AVX512ER, AVX512F, AVX512CD and PREFETCHWT1, AVX5124VNNIW,
! AVX5124FMAPS and AVX512VPOPCNTDQ instruction set support.
! .IP \fBk6\fR 4
  .IX Item "k6"
! AMD K6 CPU with MMX instruction set support.
! .IP \fBk6\-2\fR 4
  .IX Item "k6-2"
  .PD 0
! .IP \fBk6\-3\fR 4
  .IX Item "k6-3"
  .PD
! Improved versions of AMD K6 CPU with MMX and 3DNow! instruction set support.
! .IP \fBathlon\fR 4
  .IX Item "athlon"
  .PD 0
! .IP \fBathlon\-tbird\fR 4
  .IX Item "athlon-tbird"
  .PD
! AMD Athlon CPU with MMX, 3dNOW!, enhanced 3DNow! and SSE prefetch instructions
  support.
! .IP \fBathlon\-4\fR 4
  .IX Item "athlon-4"
  .PD 0
! .IP \fBathlon\-xp\fR 4
  .IX Item "athlon-xp"
! .IP \fBathlon\-mp\fR 4
  .IX Item "athlon-mp"
  .PD
! Improved AMD Athlon CPU with MMX, 3DNow!, enhanced 3DNow! and full SSE
  instruction set support.
! .IP \fBk8\fR 4
  .IX Item "k8"
  .PD 0
! .IP \fBopteron\fR 4
  .IX Item "opteron"
! .IP \fBathlon64\fR 4
  .IX Item "athlon64"
! .IP \fBathlon\-fx\fR 4
  .IX Item "athlon-fx"
  .PD
! Processors based on the AMD K8 core with x86\-64 instruction set support,
! including the AMD Opteron, Athlon 64, and Athlon 64 FX processors.
! (This supersets MMX, SSE, SSE2, 3DNow!, enhanced 3DNow! and 64\-bit
  instruction set extensions.)
! .IP \fBk8\-sse3\fR 4
  .IX Item "k8-sse3"
  .PD 0
! .IP \fBopteron\-sse3\fR 4
  .IX Item "opteron-sse3"
! .IP \fBathlon64\-sse3\fR 4
  .IX Item "athlon64-sse3"
  .PD
! Improved versions of AMD K8 cores with SSE3 instruction set support.
! .IP \fBamdfam10\fR 4
  .IX Item "amdfam10"
  .PD 0
! .IP \fBbarcelona\fR 4
  .IX Item "barcelona"
  .PD
! CPUs based on AMD Family 10h cores with x86\-64 instruction set support.  (This
! supersets MMX, SSE, SSE2, SSE3, SSE4A, 3DNow!, enhanced 3DNow!, ABM and 64\-bit
  instruction set extensions.)
! .IP \fBbdver1\fR 4
  .IX Item "bdver1"
! CPUs based on AMD Family 15h cores with x86\-64 instruction set support.  (This
! supersets FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A,
! SSSE3, SSE4.1, SSE4.2, ABM and 64\-bit instruction set extensions.)
! .IP \fBbdver2\fR 4
  .IX Item "bdver2"
! AMD Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets BMI, TBM, F16C, FMA, FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX,
! SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64\-bit instruction set 
  extensions.)
! .IP \fBbdver3\fR 4
  .IX Item "bdver3"
! AMD Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets BMI, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, XOP, LWP, AES, 
! PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and
  64\-bit instruction set extensions.)
! .IP \fBbdver4\fR 4
  .IX Item "bdver4"
! AMD Family 15h core based CPUs with x86\-64 instruction set support.  (This
! supersets BMI, BMI2, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, AVX2, XOP, LWP, 
! AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1,
! SSE4.2, ABM and 64\-bit instruction set extensions.)
! .IP \fBznver1\fR 4
  .IX Item "znver1"
! AMD Family 17h core based CPUs with x86\-64 instruction set support.  (This
! supersets BMI, BMI2, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX,
  SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3,
! SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, and 64\-bit
  instruction set extensions.)
! .IP \fBznver2\fR 4
  .IX Item "znver2"
! AMD Family 17h core based CPUs with x86\-64 instruction set support. (This
! supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
! WBNOINVD, and 64\-bit instruction set extensions.)
! .IP \fBznver3\fR 4
  .IX Item "znver3"
! AMD Family 19h core based CPUs with x86\-64 instruction set support. (This
! supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
! WBNOINVD, PKU, VPCLMULQDQ, VAES, and 64\-bit instruction set extensions.)
! .IP \fBznver4\fR 4
  .IX Item "znver4"
! AMD Family 19h core based CPUs with x86\-64 instruction set support. (This
! supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
  WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD,
  AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI,
! AVX512BITALG, AVX512VPOPCNTDQ, GFNI and 64\-bit instruction set extensions.)
! .IP \fBznver5\fR 4
  .IX Item "znver5"
! AMD Family 1ah core based CPUs with x86\-64 instruction set support. (This
! supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED,
  MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A,
  SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID,
  WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD,
  AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI,
  AVX512BITALG, AVX512VPOPCNTDQ, GFNI, AVXVNNI, MOVDIRI, MOVDIR64B,
! AVX512VP2INTERSECT, PREFETCHI and 64\-bit instruction set extensions.)
! .IP \fBbtver1\fR 4
  .IX Item "btver1"
! CPUs based on AMD Family 14h cores with x86\-64 instruction set support.  (This
! supersets MMX, SSE, SSE2, SSE3, SSSE3, SSE4A, CX16, ABM and 64\-bit
  instruction set extensions.)
! .IP \fBbtver2\fR 4
  .IX Item "btver2"
! CPUs based on AMD Family 16h cores with x86\-64 instruction set support. This
! includes MOVBE, F16C, BMI, AVX, PCLMUL, AES, SSE4.2, SSE4.1, CX16, ABM,
! SSE4A, SSSE3, SSE3, SSE2, SSE, MMX and 64\-bit instruction set extensions.
! .IP \fBwinchip\-c6\fR 4
  .IX Item "winchip-c6"
! IDT WinChip C6 CPU, dealt in same way as i486 with additional MMX instruction
  set support.
! .IP \fBwinchip2\fR 4
  .IX Item "winchip2"
! IDT WinChip 2 CPU, dealt in same way as i486 with additional MMX and 3DNow!
  instruction set support.
! .IP \fBc3\fR 4
  .IX Item "c3"
! VIA C3 CPU with MMX and 3DNow! instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBc3\-2\fR 4
  .IX Item "c3-2"
! VIA C3\-2 (Nehemiah/C5XL) CPU with MMX and SSE instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBc7\fR 4
  .IX Item "c7"
! VIA C7 (Esther) CPU with MMX, SSE, SSE2 and SSE3 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBsamuel\-2\fR 4
  .IX Item "samuel-2"
! VIA Eden Samuel 2 CPU with MMX and 3DNow! instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnehemiah\fR 4
  .IX Item "nehemiah"
! VIA Eden Nehemiah CPU with MMX and SSE instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBesther\fR 4
  .IX Item "esther"
! VIA Eden Esther CPU with MMX, SSE, SSE2 and SSE3 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBeden\-x2\fR 4
  .IX Item "eden-x2"
! VIA Eden X2 CPU with x86\-64, MMX, SSE, SSE2 and SSE3 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBeden\-x4\fR 4
  .IX Item "eden-x4"
! VIA Eden X4 CPU with x86\-64, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2,
! AVX and AVX2 instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\fR 4
  .IX Item "nano"
! Generic VIA Nano CPU with x86\-64, MMX, SSE, SSE2, SSE3 and SSSE3
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\-1000\fR 4
  .IX Item "nano-1000"
! VIA Nano 1xxx CPU with x86\-64, MMX, SSE, SSE2, SSE3 and SSSE3
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\-2000\fR 4
  .IX Item "nano-2000"
! VIA Nano 2xxx CPU with x86\-64, MMX, SSE, SSE2, SSE3 and SSSE3
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\-3000\fR 4
  .IX Item "nano-3000"
! VIA Nano 3xxx CPU with x86\-64, MMX, SSE, SSE2, SSE3, SSSE3 and SSE4.1
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\-x2\fR 4
  .IX Item "nano-x2"
! VIA Nano Dual Core CPU with x86\-64, MMX, SSE, SSE2, SSE3, SSSE3 and SSE4.1
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBnano\-x4\fR 4
  .IX Item "nano-x4"
! VIA Nano Quad Core CPU with x86\-64, MMX, SSE, SSE2, SSE3, SSSE3 and SSE4.1
  instruction set support.
  (No scheduling is implemented for this chip.)
! .IP \fBlujiazui\fR 4
  .IX Item "lujiazui"
! ZHAOXIN lujiazui CPU with x86\-64, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
  SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE, XSAVEOPT, FSGSBASE, CX16,
! ABM, BMI, BMI2, FXSR, RDSEED instruction set support.  While the CPUs
! do support AVX and F16C, these aren\*(Aqt enabled by \f(CW\*(C`\-march=lujiazui\*(C'\fR
  for performance reasons.
! .IP \fBgeode\fR 4
  .IX Item "geode"
! AMD Geode embedded processor with MMX and 3DNow! instruction set support.
  .RE
  .RS 4
  .RE
! .IP \fB\-mtune=\fR\fIcpu\-type\fR 4
  .IX Item "-mtune=cpu-type"
! Tune to \fIcpu\-type\fR everything applicable about the generated code, except
! for the ABI and the set of available instructions.  
! While picking a specific \fIcpu\-type\fR schedules things appropriately
  for that particular chip, the compiler does not generate any code that
  cannot run on the default machine type unless you use a
! \&\fB\-march=\fR\fIcpu\-type\fR option.
! For example, if GCC is configured for i686\-pc\-linux\-gnu
  then \fB\-mtune=pentium4\fR generates code that is tuned for Pentium 4
  but still runs on i686 machines.
  .Sp
! The choices for \fIcpu\-type\fR are the same as for \fB\-march\fR.
! In addition, \fB\-mtune\fR supports 2 extra choices for \fIcpu\-type\fR:
  .RS 4
! .IP \fBgeneric\fR 4
  .IX Item "generic"
! Produce code optimized for the most common IA32/AMD64/EM64T processors.
! If you know the CPU on which your code will run, then you should use
  the corresponding \fB\-mtune\fR or \fB\-march\fR option instead of
! \&\fB\-mtune=generic\fR.  But, if you do not know exactly what CPU users
  of your application will have, then you should use this option.
  .Sp
  As new processors are deployed in the marketplace, the behavior of this
  option will change.  Therefore, if you upgrade to a newer version of
! GCC, code generation controlled by this option will change to reflect
  the processors
! that are most common at the time that version of GCC is released.
  .Sp
  There is no \fB\-march=generic\fR option because \fB\-march\fR
  indicates the instruction set the compiler can use, and there is no
  generic instruction set applicable to all processors.  In contrast,
  \&\fB\-mtune\fR indicates the processor (or, in this case, collection of
  processors) for which the code is optimized.
! .IP \fBintel\fR 4
  .IX Item "intel"
  Produce code optimized for the most current Intel processors, which are
! Haswell and Silvermont for this version of GCC.  If you know the CPU
  on which your code will run, then you should use the corresponding
  \&\fB\-mtune\fR or \fB\-march\fR option instead of \fB\-mtune=intel\fR.
  But, if you want your application performs better on both Haswell and
*************** Silvermont, then you should use this opt
*** 31968,31975 ****
  .Sp
  As new Intel processors are deployed in the marketplace, the behavior of
  this option will change.  Therefore, if you upgrade to a newer version of
! \&\s-1GCC,\s0 code generation controlled by this option will change to reflect
! the most current Intel processors at the time that version of \s-1GCC\s0 is
  released.
  .Sp
  There is no \fB\-march=intel\fR option because \fB\-march\fR indicates
--- 31899,31906 ----
  .Sp
  As new Intel processors are deployed in the marketplace, the behavior of
  this option will change.  Therefore, if you upgrade to a newer version of
! GCC, code generation controlled by this option will change to reflect
! the most current Intel processors at the time that version of GCC is
  released.
  .Sp
  There is no \fB\-march=intel\fR option because \fB\-march\fR indicates
*************** processors) for which the code is optimi
*** 31980,32015 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
  .IX Item "-mcpu=cpu-type"
  A deprecated synonym for \fB\-mtune\fR.
! .IP "\fB\-mfpmath=\fR\fIunit\fR" 4
  .IX Item "-mfpmath=unit"
! Generate floating-point arithmetic for selected unit \fIunit\fR.  The choices
  for \fIunit\fR are:
  .RS 4
! .IP "\fB387\fR" 4
  .IX Item "387"
! Use the standard 387 floating-point coprocessor present on the majority of chips and
  emulated otherwise.  Code compiled with this option runs almost everywhere.
  The temporary results are computed in 80\-bit precision instead of the precision
  specified by the type, resulting in slightly different results compared to most
  of other chips.  See \fB\-ffloat\-store\fR for more detailed description.
  .Sp
! This is the default choice for non-Darwin x86\-32 targets.
! .IP "\fBsse\fR" 4
  .IX Item "sse"
! Use scalar floating-point instructions present in the \s-1SSE\s0 instruction set.
! This instruction set is supported by Pentium \s-1III\s0 and newer chips,
! and in the \s-1AMD\s0 line
! by Athlon\-4, Athlon \s-1XP\s0 and Athlon \s-1MP\s0 chips.  The earlier version of the \s-1SSE\s0
! instruction set supports only single-precision arithmetic, thus the double and
! extended-precision arithmetic are still done using 387.  A later version, present
! only in Pentium 4 and \s-1AMD\s0 x86\-64 chips, supports double-precision
  arithmetic too.
  .Sp
! For the x86\-32 compiler, you must use \fB\-march=\fR\fIcpu-type\fR, \fB\-msse\fR
! or \fB\-msse2\fR switches to enable \s-1SSE\s0 extensions and make this option
  effective.  For the x86\-64 compiler, these extensions are enabled by default.
  .Sp
  The resulting code should be considerably faster in the majority of cases and avoid
--- 31911,31946 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-mcpu=\fR\fIcpu\-type\fR 4
  .IX Item "-mcpu=cpu-type"
  A deprecated synonym for \fB\-mtune\fR.
! .IP \fB\-mfpmath=\fR\fIunit\fR 4
  .IX Item "-mfpmath=unit"
! Generate floating\-point arithmetic for selected unit \fIunit\fR.  The choices
  for \fIunit\fR are:
  .RS 4
! .IP \fB387\fR 4
  .IX Item "387"
! Use the standard 387 floating\-point coprocessor present on the majority of chips and
  emulated otherwise.  Code compiled with this option runs almost everywhere.
  The temporary results are computed in 80\-bit precision instead of the precision
  specified by the type, resulting in slightly different results compared to most
  of other chips.  See \fB\-ffloat\-store\fR for more detailed description.
  .Sp
! This is the default choice for non\-Darwin x86\-32 targets.
! .IP \fBsse\fR 4
  .IX Item "sse"
! Use scalar floating\-point instructions present in the SSE instruction set.
! This instruction set is supported by Pentium III and newer chips,
! and in the AMD line
! by Athlon\-4, Athlon XP and Athlon MP chips.  The earlier version of the SSE
! instruction set supports only single\-precision arithmetic, thus the double and
! extended\-precision arithmetic are still done using 387.  A later version, present
! only in Pentium 4 and AMD x86\-64 chips, supports double\-precision
  arithmetic too.
  .Sp
! For the x86\-32 compiler, you must use \fB\-march=\fR\fIcpu\-type\fR, \fB\-msse\fR
! or \fB\-msse2\fR switches to enable SSE extensions and make this option
  effective.  For the x86\-64 compiler, these extensions are enabled by default.
  .Sp
  The resulting code should be considerably faster in the majority of cases and avoid
*************** the numerical instability problems of 38
*** 32017,32110 ****
  code that expects temporaries to be 80 bits.
  .Sp
  This is the default choice for the x86\-64 compiler, Darwin x86\-32 targets,
! and the default choice for x86\-32 targets with the \s-1SSE2\s0 instruction set
  when \fB\-ffast\-math\fR is enabled.
! .IP "\fBsse,387\fR" 4
  .IX Item "sse,387"
  .PD 0
! .IP "\fBsse+387\fR" 4
  .IX Item "sse+387"
! .IP "\fBboth\fR" 4
  .IX Item "both"
  .PD
  Attempt to utilize both instruction sets at once.  This effectively doubles the
  amount of available registers, and on chips with separate execution units for
! 387 and \s-1SSE\s0 the execution resources too.  Use this option with care, as it is
! still experimental, because the \s-1GCC\s0 register allocator does not model separate
  functional units well, resulting in unstable performance.
  .RE
  .RS 4
  .RE
! .IP "\fB\-masm=\fR\fIdialect\fR" 4
  .IX Item "-masm=dialect"
  Output assembly instructions using selected \fIdialect\fR.  Also affects
  which dialect is used for basic \f(CW\*(C`asm\*(C'\fR and
  extended \f(CW\*(C`asm\*(C'\fR. Supported choices (in dialect
  order) are \fBatt\fR or \fBintel\fR. The default is \fBatt\fR. Darwin does
  not support \fBintel\fR.
! .IP "\fB\-mieee\-fp\fR" 4
  .IX Item "-mieee-fp"
  .PD 0
! .IP "\fB\-mno\-ieee\-fp\fR" 4
  .IX Item "-mno-ieee-fp"
  .PD
! Control whether or not the compiler uses \s-1IEEE\s0 floating-point
  comparisons.  These correctly handle the case where the result of a
  comparison is unordered.
! .IP "\fB\-m80387\fR" 4
  .IX Item "-m80387"
  .PD 0
! .IP "\fB\-mhard\-float\fR" 4
  .IX Item "-mhard-float"
  .PD
  Generate output containing 80387 instructions for floating point.
! .IP "\fB\-mno\-80387\fR" 4
  .IX Item "-mno-80387"
  .PD 0
! .IP "\fB\-msoft\-float\fR" 4
  .IX Item "-msoft-float"
  .PD
  Generate output containing library calls for floating point.
  .Sp
! \&\fBWarning:\fR the requisite libraries are not part of \s-1GCC.\s0
! Normally the facilities of the machine's usual C compiler are used, but
! this cannot be done directly in cross-compilation.  You must make your
  own arrangements to provide suitable library functions for
! cross-compilation.
  .Sp
! On machines where a function returns floating-point results in the 80387
! register stack, some floating-point opcodes may be emitted even if
  \&\fB\-msoft\-float\fR is used.
! .IP "\fB\-mno\-fp\-ret\-in\-387\fR" 4
  .IX Item "-mno-fp-ret-in-387"
! Do not use the \s-1FPU\s0 registers for return values of functions.
  .Sp
  The usual calling convention has functions return values of types
! \&\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR in an \s-1FPU\s0 register, even if there
! is no \s-1FPU.\s0  The idea is that the operating system should emulate
! an \s-1FPU.\s0
  .Sp
  The option \fB\-mno\-fp\-ret\-in\-387\fR causes such values to be returned
! in ordinary \s-1CPU\s0 registers instead.
! .IP "\fB\-mno\-fancy\-math\-387\fR" 4
  .IX Item "-mno-fancy-math-387"
  Some 387 emulators do not support the \f(CW\*(C`sin\*(C'\fR, \f(CW\*(C`cos\*(C'\fR and
  \&\f(CW\*(C`sqrt\*(C'\fR instructions for the 387.  Specify this option to avoid
  generating those instructions.
  This option is overridden when \fB\-march\fR
! indicates that the target \s-1CPU\s0 always has an \s-1FPU\s0 and so the
  instruction does not need emulation.  These
  instructions are not generated unless you also use the
  \&\fB\-funsafe\-math\-optimizations\fR switch.
! .IP "\fB\-malign\-double\fR" 4
  .IX Item "-malign-double"
  .PD 0
! .IP "\fB\-mno\-align\-double\fR" 4
  .IX Item "-mno-align-double"
  .PD
! Control whether \s-1GCC\s0 aligns \f(CW\*(C`double\*(C'\fR, \f(CW\*(C`long double\*(C'\fR, and
! \&\f(CW\*(C`long long\*(C'\fR variables on a two-word boundary or a one-word
! boundary.  Aligning \f(CW\*(C`double\*(C'\fR variables on a two-word boundary
  produces code that runs somewhat faster on a Pentium at the
  expense of more memory.
  .Sp
--- 31948,32041 ----
  code that expects temporaries to be 80 bits.
  .Sp
  This is the default choice for the x86\-64 compiler, Darwin x86\-32 targets,
! and the default choice for x86\-32 targets with the SSE2 instruction set
  when \fB\-ffast\-math\fR is enabled.
! .IP \fBsse,387\fR 4
  .IX Item "sse,387"
  .PD 0
! .IP \fBsse+387\fR 4
  .IX Item "sse+387"
! .IP \fBboth\fR 4
  .IX Item "both"
  .PD
  Attempt to utilize both instruction sets at once.  This effectively doubles the
  amount of available registers, and on chips with separate execution units for
! 387 and SSE the execution resources too.  Use this option with care, as it is
! still experimental, because the GCC register allocator does not model separate
  functional units well, resulting in unstable performance.
  .RE
  .RS 4
  .RE
! .IP \fB\-masm=\fR\fIdialect\fR 4
  .IX Item "-masm=dialect"
  Output assembly instructions using selected \fIdialect\fR.  Also affects
  which dialect is used for basic \f(CW\*(C`asm\*(C'\fR and
  extended \f(CW\*(C`asm\*(C'\fR. Supported choices (in dialect
  order) are \fBatt\fR or \fBintel\fR. The default is \fBatt\fR. Darwin does
  not support \fBintel\fR.
! .IP \fB\-mieee\-fp\fR 4
  .IX Item "-mieee-fp"
  .PD 0
! .IP \fB\-mno\-ieee\-fp\fR 4
  .IX Item "-mno-ieee-fp"
  .PD
! Control whether or not the compiler uses IEEE floating\-point
  comparisons.  These correctly handle the case where the result of a
  comparison is unordered.
! .IP \fB\-m80387\fR 4
  .IX Item "-m80387"
  .PD 0
! .IP \fB\-mhard\-float\fR 4
  .IX Item "-mhard-float"
  .PD
  Generate output containing 80387 instructions for floating point.
! .IP \fB\-mno\-80387\fR 4
  .IX Item "-mno-80387"
  .PD 0
! .IP \fB\-msoft\-float\fR 4
  .IX Item "-msoft-float"
  .PD
  Generate output containing library calls for floating point.
  .Sp
! \&\fBWarning:\fR the requisite libraries are not part of GCC.
! Normally the facilities of the machine\*(Aqs usual C compiler are used, but
! this cannot be done directly in cross\-compilation.  You must make your
  own arrangements to provide suitable library functions for
! cross\-compilation.
  .Sp
! On machines where a function returns floating\-point results in the 80387
! register stack, some floating\-point opcodes may be emitted even if
  \&\fB\-msoft\-float\fR is used.
! .IP \fB\-mno\-fp\-ret\-in\-387\fR 4
  .IX Item "-mno-fp-ret-in-387"
! Do not use the FPU registers for return values of functions.
  .Sp
  The usual calling convention has functions return values of types
! \&\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR in an FPU register, even if there
! is no FPU.  The idea is that the operating system should emulate
! an FPU.
  .Sp
  The option \fB\-mno\-fp\-ret\-in\-387\fR causes such values to be returned
! in ordinary CPU registers instead.
! .IP \fB\-mno\-fancy\-math\-387\fR 4
  .IX Item "-mno-fancy-math-387"
  Some 387 emulators do not support the \f(CW\*(C`sin\*(C'\fR, \f(CW\*(C`cos\*(C'\fR and
  \&\f(CW\*(C`sqrt\*(C'\fR instructions for the 387.  Specify this option to avoid
  generating those instructions.
  This option is overridden when \fB\-march\fR
! indicates that the target CPU always has an FPU and so the
  instruction does not need emulation.  These
  instructions are not generated unless you also use the
  \&\fB\-funsafe\-math\-optimizations\fR switch.
! .IP \fB\-malign\-double\fR 4
  .IX Item "-malign-double"
  .PD 0
! .IP \fB\-mno\-align\-double\fR 4
  .IX Item "-mno-align-double"
  .PD
! Control whether GCC aligns \f(CW\*(C`double\*(C'\fR, \f(CW\*(C`long double\*(C'\fR, and
! \&\f(CW\*(C`long long\*(C'\fR variables on a two\-word boundary or a one\-word
! boundary.  Aligning \f(CW\*(C`double\*(C'\fR variables on a two\-word boundary
  produces code that runs somewhat faster on a Pentium at the
  expense of more memory.
  .Sp
*************** structures containing the above types ar
*** 32115,32124 ****
  the published application binary interface specifications for the x86\-32
  and are not binary compatible with structures in code compiled
  without that switch.
! .IP "\fB\-m96bit\-long\-double\fR" 4
  .IX Item "-m96bit-long-double"
  .PD 0
! .IP "\fB\-m128bit\-long\-double\fR" 4
  .IX Item "-m128bit-long-double"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type.  The x86\-32
--- 32046,32055 ----
  the published application binary interface specifications for the x86\-32
  and are not binary compatible with structures in code compiled
  without that switch.
! .IP \fB\-m96bit\-long\-double\fR 4
  .IX Item "-m96bit-long-double"
  .PD 0
! .IP \fB\-m128bit\-long\-double\fR 4
  .IX Item "-m128bit-long-double"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type.  The x86\-32
*************** so \fB\-m96bit\-long\-double\fR is the d
*** 32127,32155 ****
  .Sp
  Modern architectures (Pentium and newer) prefer \f(CW\*(C`long double\*(C'\fR
  to be aligned to an 8\- or 16\-byte boundary.  In arrays or structures
! conforming to the \s-1ABI,\s0 this is not possible.  So specifying
  \&\fB\-m128bit\-long\-double\fR aligns \f(CW\*(C`long double\*(C'\fR
  to a 16\-byte boundary by padding the \f(CW\*(C`long double\*(C'\fR with an additional
  32\-bit zero.
  .Sp
  In the x86\-64 compiler, \fB\-m128bit\-long\-double\fR is the default choice as
! its \s-1ABI\s0 specifies that \f(CW\*(C`long double\*(C'\fR is aligned on 16\-byte boundary.
  .Sp
  Notice that neither of these options enable any extra precision over the x87
  standard of 80 bits for a \f(CW\*(C`long double\*(C'\fR.
  .Sp
! \&\fBWarning:\fR if you override the default value for your target \s-1ABI,\s0 this
  changes the size of 
  structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
  as well as modifying the function calling convention for functions taking
! \&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary-compatible
  with code compiled without that switch.
! .IP "\fB\-mlong\-double\-64\fR" 4
  .IX Item "-mlong-double-64"
  .PD 0
! .IP "\fB\-mlong\-double\-80\fR" 4
  .IX Item "-mlong-double-80"
! .IP "\fB\-mlong\-double\-128\fR" 4
  .IX Item "-mlong-double-128"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
--- 32058,32086 ----
  .Sp
  Modern architectures (Pentium and newer) prefer \f(CW\*(C`long double\*(C'\fR
  to be aligned to an 8\- or 16\-byte boundary.  In arrays or structures
! conforming to the ABI, this is not possible.  So specifying
  \&\fB\-m128bit\-long\-double\fR aligns \f(CW\*(C`long double\*(C'\fR
  to a 16\-byte boundary by padding the \f(CW\*(C`long double\*(C'\fR with an additional
  32\-bit zero.
  .Sp
  In the x86\-64 compiler, \fB\-m128bit\-long\-double\fR is the default choice as
! its ABI specifies that \f(CW\*(C`long double\*(C'\fR is aligned on 16\-byte boundary.
  .Sp
  Notice that neither of these options enable any extra precision over the x87
  standard of 80 bits for a \f(CW\*(C`long double\*(C'\fR.
  .Sp
! \&\fBWarning:\fR if you override the default value for your target ABI, this
  changes the size of 
  structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
  as well as modifying the function calling convention for functions taking
! \&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary\-compatible
  with code compiled without that switch.
! .IP \fB\-mlong\-double\-64\fR 4
  .IX Item "-mlong-double-64"
  .PD 0
! .IP \fB\-mlong\-double\-80\fR 4
  .IX Item "-mlong-double-80"
! .IP \fB\-mlong\-double\-128\fR 4
  .IX Item "-mlong-double-128"
  .PD
  These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
*************** type. This is the default for 32\-bit Bi
*** 32158,32185 ****
  of 128 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the
  \&\f(CW\*(C`_\|_float128\*(C'\fR type. This is the default for 64\-bit Bionic C library.
  .Sp
! \&\fBWarning:\fR if you override the default value for your target \s-1ABI,\s0 this
  changes the size of
  structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
  as well as modifying the function calling convention for functions taking
! \&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary-compatible
  with code compiled without that switch.
! .IP "\fB\-malign\-data=\fR\fItype\fR" 4
  .IX Item "-malign-data=type"
! Control how \s-1GCC\s0 aligns variables.  Supported values for \fItype\fR are
! \&\fBcompat\fR uses increased alignment value compatible uses \s-1GCC 4.8\s0
  and earlier, \fBabi\fR uses alignment value as specified by the
  psABI, and \fBcacheline\fR uses increased alignment value to match
  the cache line size.  \fBcompat\fR is the default.
! .IP "\fB\-mlarge\-data\-threshold=\fR\fIthreshold\fR" 4
  .IX Item "-mlarge-data-threshold=threshold"
  When \fB\-mcmodel=medium\fR is specified, data objects larger than
  \&\fIthreshold\fR are placed in the large data section.  This value must be the
  same across all objects linked into the binary, and defaults to 65535.
! .IP "\fB\-mrtd\fR" 4
  .IX Item "-mrtd"
! Use a different function-calling convention, in which functions that
! take a fixed number of arguments return with the \f(CW\*(C`ret \f(CInum\f(CW\*(C'\fR
  instruction, which pops their arguments while returning.  This saves one
  instruction in the caller since there is no need to pop the arguments
  there.
--- 32089,32116 ----
  of 128 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the
  \&\f(CW\*(C`_\|_float128\*(C'\fR type. This is the default for 64\-bit Bionic C library.
  .Sp
! \&\fBWarning:\fR if you override the default value for your target ABI, this
  changes the size of
  structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
  as well as modifying the function calling convention for functions taking
! \&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary\-compatible
  with code compiled without that switch.
! .IP \fB\-malign\-data=\fR\fItype\fR 4
  .IX Item "-malign-data=type"
! Control how GCC aligns variables.  Supported values for \fItype\fR are
! \&\fBcompat\fR uses increased alignment value compatible uses GCC 4.8
  and earlier, \fBabi\fR uses alignment value as specified by the
  psABI, and \fBcacheline\fR uses increased alignment value to match
  the cache line size.  \fBcompat\fR is the default.
! .IP \fB\-mlarge\-data\-threshold=\fR\fIthreshold\fR 4
  .IX Item "-mlarge-data-threshold=threshold"
  When \fB\-mcmodel=medium\fR is specified, data objects larger than
  \&\fIthreshold\fR are placed in the large data section.  This value must be the
  same across all objects linked into the binary, and defaults to 65535.
! .IP \fB\-mrtd\fR 4
  .IX Item "-mrtd"
! Use a different function\-calling convention, in which functions that
! take a fixed number of arguments return with the \f(CW\*(C`ret \fR\f(CInum\fR\f(CW\*(C'\fR
  instruction, which pops their arguments while returning.  This saves one
  instruction in the caller since there is no need to pop the arguments
  there.
*************** functions.
*** 32201,32207 ****
  In addition, seriously incorrect code results if you call a
  function with too many arguments.  (Normally, extra arguments are
  harmlessly ignored.)
! .IP "\fB\-mregparm=\fR\fInum\fR" 4
  .IX Item "-mregparm=num"
  Control how many registers are used to pass integer arguments.  By
  default, no registers are used to pass arguments, and at most 3
--- 32132,32138 ----
  In addition, seriously incorrect code results if you call a
  function with too many arguments.  (Normally, extra arguments are
  harmlessly ignored.)
! .IP \fB\-mregparm=\fR\fInum\fR 4
  .IX Item "-mregparm=num"
  Control how many registers are used to pass integer arguments.  By
  default, no registers are used to pass arguments, and at most 3
*************** function by using the function attribute
*** 32212,32294 ****
  \&\fInum\fR is nonzero, then you must build all modules with the same
  value, including any libraries.  This includes the system libraries and
  startup modules.
! .IP "\fB\-msseregparm\fR" 4
  .IX Item "-msseregparm"
! Use \s-1SSE\s0 register passing conventions for float and double arguments
  and return values.  You can control this behavior for a specific
  function by using the function attribute \f(CW\*(C`sseregparm\*(C'\fR.
  .Sp
  \&\fBWarning:\fR if you use this switch then you must build all
  modules with the same value, including any libraries.  This includes
  the system libraries and startup modules.
! .IP "\fB\-mvect8\-ret\-in\-mem\fR" 4
  .IX Item "-mvect8-ret-in-mem"
! Return 8\-byte vectors in memory instead of \s-1MMX\s0 registers.  This is the
! default on VxWorks to match the \s-1ABI\s0 of the Sun Studio compilers until
  version 12.  \fIOnly\fR use this option if you need to remain
  compatible with existing code produced by those previous compiler
! versions or older versions of \s-1GCC.\s0
! .IP "\fB\-mpc32\fR" 4
  .IX Item "-mpc32"
  .PD 0
! .IP "\fB\-mpc64\fR" 4
  .IX Item "-mpc64"
! .IP "\fB\-mpc80\fR" 4
  .IX Item "-mpc80"
  .PD
! Set 80387 floating-point precision to 32, 64 or 80 bits.  When \fB\-mpc32\fR
! is specified, the significands of results of floating-point operations are
  rounded to 24 bits (single precision); \fB\-mpc64\fR rounds the
! significands of results of floating-point operations to 53 bits (double
  precision) and \fB\-mpc80\fR rounds the significands of results of
! floating-point operations to 64 bits (extended double precision), which is
! the default.  When this option is used, floating-point operations in higher
! precisions are not available to the programmer without setting the \s-1FPU\s0
  control word explicitly.
  .Sp
! Setting the rounding of floating-point operations to less than the default
  80 bits can speed some programs by 2% or more.  Note that some mathematical
! libraries assume that extended-precision (80\-bit) floating-point operations
  are enabled by default; routines in such libraries could suffer significant
! loss of accuracy, typically through so-called \*(L"catastrophic cancellation\*(R",
  when this option is used to set the precision to less than extended precision.
! .IP "\fB\-mdaz\-ftz\fR" 4
  .IX Item "-mdaz-ftz"
! The flush-to-zero (\s-1FTZ\s0) and denormals-are-zero (\s-1DAZ\s0) flags in the \s-1MXCSR\s0 register
! are used to control floating-point calculations.SSE and \s-1AVX\s0 instructions
! including scalar and vector instructions could benefit from enabling the \s-1FTZ\s0
! and \s-1DAZ\s0 flags when \fB\-mdaz\-ftz\fR is specified. Don't set \s-1FTZ/DAZ\s0 flags
  when \fB\-mno\-daz\-ftz\fR or \fB\-shared\fR is specified, \fB\-mdaz\-ftz\fR
! will set \s-1FTZ/DAZ\s0 flags even with \fB\-shared\fR.
! .IP "\fB\-mstackrealign\fR" 4
  .IX Item "-mstackrealign"
  Realign the stack at entry.  On the x86, the \fB\-mstackrealign\fR
  option generates an alternate prologue and epilogue that realigns the
! run-time stack if necessary.  This supports mixing legacy codes that keep
  4\-byte stack alignment with modern codes that keep 16\-byte stack alignment for
! \&\s-1SSE\s0 compatibility.  See also the attribute \f(CW\*(C`force_align_arg_pointer\*(C'\fR,
  applicable to individual functions.
! .IP "\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR" 4
  .IX Item "-mpreferred-stack-boundary=num"
  Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
  byte boundary.  If \fB\-mpreferred\-stack\-boundary\fR is not specified,
  the default is 4 (16 bytes or 128 bits).
  .Sp
  \&\fBWarning:\fR When generating code for the x86\-64 architecture with
! \&\s-1SSE\s0 extensions disabled, \fB\-mpreferred\-stack\-boundary=3\fR can be
  used to keep the stack boundary aligned to 8 byte boundary.  Since
! x86\-64 \s-1ABI\s0 require 16 byte stack alignment, this is \s-1ABI\s0 incompatible and
  intended to be used in controlled environment where stack space is
  important limitation.  This option leads to wrong code when functions
  compiled with 16 byte stack alignment (such as functions from a standard
! library) are called with misaligned stack.  In this case, \s-1SSE\s0
  instructions may lead to misaligned memory access traps.  In addition,
  variable arguments are handled incorrectly for 16 byte aligned
  objects (including x87 long double and _\|_int128), leading to wrong
  results.  You must build all modules with
  \&\fB\-mpreferred\-stack\-boundary=3\fR, including any libraries.  This
  includes the system libraries and startup modules.
! .IP "\fB\-mincoming\-stack\-boundary=\fR\fInum\fR" 4
  .IX Item "-mincoming-stack-boundary=num"
  Assume the incoming stack is aligned to a 2 raised to \fInum\fR byte
  boundary.  If \fB\-mincoming\-stack\-boundary\fR is not specified,
--- 32143,32225 ----
  \&\fInum\fR is nonzero, then you must build all modules with the same
  value, including any libraries.  This includes the system libraries and
  startup modules.
! .IP \fB\-msseregparm\fR 4
  .IX Item "-msseregparm"
! Use 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 \f(CW\*(C`sseregparm\*(C'\fR.
  .Sp
  \&\fBWarning:\fR if you use this switch then you must build all
  modules with the same value, including any libraries.  This includes
  the system libraries and startup modules.
! .IP \fB\-mvect8\-ret\-in\-mem\fR 4
  .IX Item "-mvect8-ret-in-mem"
! Return 8\-byte vectors in memory instead of MMX registers.  This is the
! default on VxWorks to match the ABI of the Sun Studio compilers until
  version 12.  \fIOnly\fR use this option if you need to remain
  compatible with existing code produced by those previous compiler
! versions or older versions of GCC.
! .IP \fB\-mpc32\fR 4
  .IX Item "-mpc32"
  .PD 0
! .IP \fB\-mpc64\fR 4
  .IX Item "-mpc64"
! .IP \fB\-mpc80\fR 4
  .IX Item "-mpc80"
  .PD
! Set 80387 floating\-point precision to 32, 64 or 80 bits.  When \fB\-mpc32\fR
! is specified, the significands of results of floating\-point operations are
  rounded to 24 bits (single precision); \fB\-mpc64\fR rounds the
! significands of results of floating\-point operations to 53 bits (double
  precision) and \fB\-mpc80\fR rounds the significands of results of
! floating\-point operations to 64 bits (extended double precision), which is
! the default.  When this option is used, floating\-point operations in higher
! precisions are not available to the programmer without setting the FPU
  control word explicitly.
  .Sp
! Setting the rounding of floating\-point operations to less than the default
  80 bits can speed some programs by 2% or more.  Note that some mathematical
! libraries assume that extended\-precision (80\-bit) floating\-point operations
  are enabled by default; routines in such libraries could suffer significant
! loss of accuracy, typically through so\-called "catastrophic cancellation",
  when this option is used to set the precision to less than extended precision.
! .IP \fB\-mdaz\-ftz\fR 4
  .IX Item "-mdaz-ftz"
! The flush\-to\-zero (FTZ) and denormals\-are\-zero (DAZ) flags in the MXCSR register
! are used to control floating\-point calculations.SSE and AVX instructions
! including scalar and vector instructions could benefit from enabling the FTZ
! and DAZ flags when \fB\-mdaz\-ftz\fR is specified. Don\*(Aqt set FTZ/DAZ flags
  when \fB\-mno\-daz\-ftz\fR or \fB\-shared\fR is specified, \fB\-mdaz\-ftz\fR
! will set FTZ/DAZ flags even with \fB\-shared\fR.
! .IP \fB\-mstackrealign\fR 4
  .IX Item "-mstackrealign"
  Realign the stack at entry.  On the x86, the \fB\-mstackrealign\fR
  option generates an alternate prologue and epilogue that realigns the
! run\-time stack if necessary.  This supports mixing legacy codes that keep
  4\-byte stack alignment with modern codes that keep 16\-byte stack alignment for
! SSE compatibility.  See also the attribute \f(CW\*(C`force_align_arg_pointer\*(C'\fR,
  applicable to individual functions.
! .IP \fB\-mpreferred\-stack\-boundary=\fR\fInum\fR 4
  .IX Item "-mpreferred-stack-boundary=num"
  Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
  byte boundary.  If \fB\-mpreferred\-stack\-boundary\fR is not specified,
  the default is 4 (16 bytes or 128 bits).
  .Sp
  \&\fBWarning:\fR When generating code for the x86\-64 architecture with
! SSE extensions disabled, \fB\-mpreferred\-stack\-boundary=3\fR can be
  used to keep the stack boundary aligned to 8 byte boundary.  Since
! x86\-64 ABI require 16 byte stack alignment, this is ABI incompatible and
  intended to be used in controlled environment where stack space is
  important limitation.  This option leads to wrong code when functions
  compiled with 16 byte stack alignment (such as functions from a standard
! library) are called with misaligned stack.  In this case, SSE
  instructions may lead to misaligned memory access traps.  In addition,
  variable arguments are handled incorrectly for 16 byte aligned
  objects (including x87 long double and _\|_int128), leading to wrong
  results.  You must build all modules with
  \&\fB\-mpreferred\-stack\-boundary=3\fR, including any libraries.  This
  includes the system libraries and startup modules.
! .IP \fB\-mincoming\-stack\-boundary=\fR\fInum\fR 4
  .IX Item "-mincoming-stack-boundary=num"
  Assume the incoming stack is aligned to a 2 raised to \fInum\fR byte
  boundary.  If \fB\-mincoming\-stack\-boundary\fR is not specified,
*************** the one specified by \fB\-mpreferred\-st
*** 32296,32303 ****
  .Sp
  On Pentium and Pentium Pro, \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long double\*(C'\fR values
  should be aligned to an 8\-byte boundary (see \fB\-malign\-double\fR) or
! suffer significant run time performance penalties.  On Pentium \s-1III,\s0 the
! Streaming \s-1SIMD\s0 Extension (\s-1SSE\s0) data type \f(CW\*(C`_\|_m128\*(C'\fR may not work
  properly if it is not 16\-byte aligned.
  .Sp
  To ensure proper alignment of this values on the stack, the stack boundary
--- 32227,32234 ----
  .Sp
  On Pentium and Pentium Pro, \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long double\*(C'\fR values
  should be aligned to an 8\-byte boundary (see \fB\-malign\-double\fR) or
! suffer significant run time performance penalties.  On Pentium III, the
! Streaming SIMD Extension (SSE) data type \f(CW\*(C`_\|_m128\*(C'\fR may not work
  properly if it is not 16\-byte aligned.
  .Sp
  To ensure proper alignment of this values on the stack, the stack boundary
*************** This extra alignment does consume extra
*** 32312,32693 ****
  increases code size.  Code that is sensitive to stack space usage, such
  as embedded systems and operating system kernels, may want to reduce the
  preferred alignment to \fB\-mpreferred\-stack\-boundary=2\fR.
! .IP "\fB\-mmmx\fR" 4
  .IX Item "-mmmx"
  .PD 0
! .IP "\fB\-msse\fR" 4
  .IX Item "-msse"
! .IP "\fB\-msse2\fR" 4
  .IX Item "-msse2"
! .IP "\fB\-msse3\fR" 4
  .IX Item "-msse3"
! .IP "\fB\-mssse3\fR" 4
  .IX Item "-mssse3"
! .IP "\fB\-msse4\fR" 4
  .IX Item "-msse4"
! .IP "\fB\-msse4a\fR" 4
  .IX Item "-msse4a"
! .IP "\fB\-msse4.1\fR" 4
  .IX Item "-msse4.1"
! .IP "\fB\-msse4.2\fR" 4
  .IX Item "-msse4.2"
! .IP "\fB\-mavx\fR" 4
  .IX Item "-mavx"
! .IP "\fB\-mavx2\fR" 4
  .IX Item "-mavx2"
! .IP "\fB\-mavx512f\fR" 4
  .IX Item "-mavx512f"
! .IP "\fB\-mavx512pf\fR" 4
  .IX Item "-mavx512pf"
! .IP "\fB\-mavx512er\fR" 4
  .IX Item "-mavx512er"
! .IP "\fB\-mavx512cd\fR" 4
  .IX Item "-mavx512cd"
! .IP "\fB\-mavx512vl\fR" 4
  .IX Item "-mavx512vl"
! .IP "\fB\-mavx512bw\fR" 4
  .IX Item "-mavx512bw"
! .IP "\fB\-mavx512dq\fR" 4
  .IX Item "-mavx512dq"
! .IP "\fB\-mavx512ifma\fR" 4
  .IX Item "-mavx512ifma"
! .IP "\fB\-mavx512vbmi\fR" 4
  .IX Item "-mavx512vbmi"
! .IP "\fB\-msha\fR" 4
  .IX Item "-msha"
! .IP "\fB\-maes\fR" 4
  .IX Item "-maes"
! .IP "\fB\-mpclmul\fR" 4
  .IX Item "-mpclmul"
! .IP "\fB\-mclflushopt\fR" 4
  .IX Item "-mclflushopt"
! .IP "\fB\-mclwb\fR" 4
  .IX Item "-mclwb"
! .IP "\fB\-mfsgsbase\fR" 4
  .IX Item "-mfsgsbase"
! .IP "\fB\-mptwrite\fR" 4
  .IX Item "-mptwrite"
! .IP "\fB\-mrdrnd\fR" 4
  .IX Item "-mrdrnd"
! .IP "\fB\-mf16c\fR" 4
  .IX Item "-mf16c"
! .IP "\fB\-mfma\fR" 4
  .IX Item "-mfma"
! .IP "\fB\-mpconfig\fR" 4
  .IX Item "-mpconfig"
! .IP "\fB\-mwbnoinvd\fR" 4
  .IX Item "-mwbnoinvd"
! .IP "\fB\-mfma4\fR" 4
  .IX Item "-mfma4"
! .IP "\fB\-mprfchw\fR" 4
  .IX Item "-mprfchw"
! .IP "\fB\-mrdpid\fR" 4
  .IX Item "-mrdpid"
! .IP "\fB\-mprefetchwt1\fR" 4
  .IX Item "-mprefetchwt1"
! .IP "\fB\-mrdseed\fR" 4
  .IX Item "-mrdseed"
! .IP "\fB\-msgx\fR" 4
  .IX Item "-msgx"
! .IP "\fB\-mxop\fR" 4
  .IX Item "-mxop"
! .IP "\fB\-mlwp\fR" 4
  .IX Item "-mlwp"
! .IP "\fB\-m3dnow\fR" 4
  .IX Item "-m3dnow"
! .IP "\fB\-m3dnowa\fR" 4
  .IX Item "-m3dnowa"
! .IP "\fB\-mpopcnt\fR" 4
  .IX Item "-mpopcnt"
! .IP "\fB\-mabm\fR" 4
  .IX Item "-mabm"
! .IP "\fB\-madx\fR" 4
  .IX Item "-madx"
! .IP "\fB\-mbmi\fR" 4
  .IX Item "-mbmi"
! .IP "\fB\-mbmi2\fR" 4
  .IX Item "-mbmi2"
! .IP "\fB\-mlzcnt\fR" 4
  .IX Item "-mlzcnt"
! .IP "\fB\-mfxsr\fR" 4
  .IX Item "-mfxsr"
! .IP "\fB\-mxsave\fR" 4
  .IX Item "-mxsave"
! .IP "\fB\-mxsaveopt\fR" 4
  .IX Item "-mxsaveopt"
! .IP "\fB\-mxsavec\fR" 4
  .IX Item "-mxsavec"
! .IP "\fB\-mxsaves\fR" 4
  .IX Item "-mxsaves"
! .IP "\fB\-mrtm\fR" 4
  .IX Item "-mrtm"
! .IP "\fB\-mhle\fR" 4
  .IX Item "-mhle"
! .IP "\fB\-mtbm\fR" 4
  .IX Item "-mtbm"
! .IP "\fB\-mmwaitx\fR" 4
  .IX Item "-mmwaitx"
! .IP "\fB\-mclzero\fR" 4
  .IX Item "-mclzero"
! .IP "\fB\-mpku\fR" 4
  .IX Item "-mpku"
! .IP "\fB\-mavx512vbmi2\fR" 4
  .IX Item "-mavx512vbmi2"
! .IP "\fB\-mavx512bf16\fR" 4
  .IX Item "-mavx512bf16"
! .IP "\fB\-mavx512fp16\fR" 4
  .IX Item "-mavx512fp16"
! .IP "\fB\-mgfni\fR" 4
  .IX Item "-mgfni"
! .IP "\fB\-mvaes\fR" 4
  .IX Item "-mvaes"
! .IP "\fB\-mwaitpkg\fR" 4
  .IX Item "-mwaitpkg"
! .IP "\fB\-mvpclmulqdq\fR" 4
  .IX Item "-mvpclmulqdq"
! .IP "\fB\-mavx512bitalg\fR" 4
  .IX Item "-mavx512bitalg"
! .IP "\fB\-mmovdiri\fR" 4
  .IX Item "-mmovdiri"
! .IP "\fB\-mmovdir64b\fR" 4
  .IX Item "-mmovdir64b"
! .IP "\fB\-menqcmd\fR" 4
  .IX Item "-menqcmd"
! .IP "\fB\-muintr\fR" 4
  .IX Item "-muintr"
! .IP "\fB\-mtsxldtrk\fR" 4
  .IX Item "-mtsxldtrk"
! .IP "\fB\-mavx512vpopcntdq\fR" 4
  .IX Item "-mavx512vpopcntdq"
! .IP "\fB\-mavx512vp2intersect\fR" 4
  .IX Item "-mavx512vp2intersect"
! .IP "\fB\-mavx5124fmaps\fR" 4
  .IX Item "-mavx5124fmaps"
! .IP "\fB\-mavx512vnni\fR" 4
  .IX Item "-mavx512vnni"
! .IP "\fB\-mavxvnni\fR" 4
  .IX Item "-mavxvnni"
! .IP "\fB\-mavx5124vnniw\fR" 4
  .IX Item "-mavx5124vnniw"
! .IP "\fB\-mcldemote\fR" 4
  .IX Item "-mcldemote"
! .IP "\fB\-mserialize\fR" 4
  .IX Item "-mserialize"
! .IP "\fB\-mamx\-tile\fR" 4
  .IX Item "-mamx-tile"
! .IP "\fB\-mamx\-int8\fR" 4
  .IX Item "-mamx-int8"
! .IP "\fB\-mamx\-bf16\fR" 4
  .IX Item "-mamx-bf16"
! .IP "\fB\-mhreset\fR" 4
  .IX Item "-mhreset"
! .IP "\fB\-mkl\fR" 4
  .IX Item "-mkl"
! .IP "\fB\-mwidekl\fR" 4
  .IX Item "-mwidekl"
! .IP "\fB\-mavxifma\fR" 4
  .IX Item "-mavxifma"
! .IP "\fB\-mavxvnniint8\fR" 4
  .IX Item "-mavxvnniint8"
! .IP "\fB\-mavxneconvert\fR" 4
  .IX Item "-mavxneconvert"
! .IP "\fB\-mcmpccxadd\fR" 4
  .IX Item "-mcmpccxadd"
! .IP "\fB\-mamx\-fp16\fR" 4
  .IX Item "-mamx-fp16"
! .IP "\fB\-mprefetchi\fR" 4
  .IX Item "-mprefetchi"
! .IP "\fB\-mraoint\fR" 4
  .IX Item "-mraoint"
! .IP "\fB\-mamx\-complex\fR" 4
  .IX Item "-mamx-complex"
  .PD
! These switches enable the use of instructions in the \s-1MMX, SSE,
  SSE2, SSE3, SSSE3, SSE4, SSE4A, SSE4.1, SSE4.2, AVX, AVX2, AVX512F, AVX512PF,
  AVX512ER, AVX512CD, AVX512VL, AVX512BW, AVX512DQ, AVX512IFMA, AVX512VBMI, SHA,
  AES, PCLMUL, CLFLUSHOPT, CLWB, FSGSBASE, PTWRITE, RDRND, F16C, FMA, PCONFIG,
! WBNOINVD, FMA4, PREFETCHW, RDPID, PREFETCHWT1, RDSEED, SGX, XOP, LWP,\s0
! 3DNow!, enhanced 3DNow!, \s-1POPCNT, ABM, ADX, BMI, BMI2, LZCNT, FXSR, XSAVE,
  XSAVEOPT, XSAVEC, XSAVES, RTM, HLE, TBM, MWAITX, CLZERO, PKU, AVX512VBMI2,
  GFNI, VAES, WAITPKG, VPCLMULQDQ, AVX512BITALG, MOVDIRI, MOVDIR64B, AVX512BF16,
  ENQCMD, AVX512VPOPCNTDQ, AVX5124FMAPS, AVX512VNNI, AVX5124VNNIW, SERIALIZE,
  UINTR, HRESET, AMXTILE, AMXINT8, AMXBF16, KL, WIDEKL, AVXVNNI, AVX512\-FP16,
! AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AMX\-FP16, PREFETCHI, RAOINT,\s0
! AMX-COMPLEX or \s-1CLDEMOTE\s0 extended instruction sets. Each has a corresponding
  \&\fB\-mno\-\fR option to disable use of these instructions.
  .Sp
! These extensions are also available as built-in functions: see
! \&\fBx86 Built-in Functions\fR, for details of the functions enabled and
  disabled by these switches.
  .Sp
! To generate \s-1SSE/SSE2\s0 instructions automatically from floating-point
  code (as opposed to 387 instructions), see \fB\-mfpmath=sse\fR.
  .Sp
! \&\s-1GCC\s0 depresses SSEx instructions when \fB\-mavx\fR is used. Instead, it
! generates new \s-1AVX\s0 instructions or \s-1AVX\s0 equivalence for all SSEx instructions
  when needed.
  .Sp
! These options enable \s-1GCC\s0 to use these extended instructions in
  generated code, even without \fB\-mfpmath=sse\fR.  Applications that
! perform run-time \s-1CPU\s0 detection must compile separate files for each
  supported architecture, using the appropriate flags.  In particular,
! the file containing the \s-1CPU\s0 detection code should be compiled without
  these options.
! .IP "\fB\-mdump\-tune\-features\fR" 4
  .IX Item "-mdump-tune-features"
! This option instructs \s-1GCC\s0 to dump the names of the x86 performance 
  tuning features and default settings. The names can be used in 
! \&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR.
! .IP "\fB\-mtune\-ctrl=\fR\fIfeature-list\fR" 4
  .IX Item "-mtune-ctrl=feature-list"
  This option is used to do fine grain control of x86 code generation features.
! \&\fIfeature-list\fR is a comma separated list of \fIfeature\fR names. See also
  \&\fB\-mdump\-tune\-features\fR. When specified, the \fIfeature\fR is turned
  on if it is not preceded with \fB^\fR, otherwise, it is turned off. 
! \&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR is intended to be used by \s-1GCC\s0
  developers. Using it may lead to code paths not covered by testing and can
  potentially result in compiler ICEs or runtime errors.
! .IP "\fB\-mno\-default\fR" 4
  .IX Item "-mno-default"
! This option instructs \s-1GCC\s0 to turn off all tunable features. See also 
! \&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR and \fB\-mdump\-tune\-features\fR.
! .IP "\fB\-mcld\fR" 4
  .IX Item "-mcld"
! This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`cld\*(C'\fR instruction in the prologue
  of functions that use string instructions.  String instructions depend on
! the \s-1DF\s0 flag to select between autoincrement or autodecrement mode.  While the
! \&\s-1ABI\s0 specifies the \s-1DF\s0 flag to be cleared on function entry, some operating
! systems violate this specification by not clearing the \s-1DF\s0 flag in their
! exception dispatchers.  The exception handler can be invoked with the \s-1DF\s0 flag
  set, which leads to wrong direction mode when string instructions are used.
  This option can be enabled by default on 32\-bit x86 targets by configuring
! \&\s-1GCC\s0 with the \fB\-\-enable\-cld\fR configure option.  Generation of \f(CW\*(C`cld\*(C'\fR
  instructions can be suppressed with the \fB\-mno\-cld\fR compiler option
  in this case.
! .IP "\fB\-mvzeroupper\fR" 4
  .IX Item "-mvzeroupper"
! This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`vzeroupper\*(C'\fR instruction
  before a transfer of control flow out of the function to minimize
! the \s-1AVX\s0 to \s-1SSE\s0 transition penalty as well as remove unnecessary \f(CW\*(C`zeroupper\*(C'\fR
  intrinsics.
! .IP "\fB\-mprefer\-avx128\fR" 4
  .IX Item "-mprefer-avx128"
! This option instructs \s-1GCC\s0 to use 128\-bit \s-1AVX\s0 instructions instead of
! 256\-bit \s-1AVX\s0 instructions in the auto-vectorizer.
! .IP "\fB\-mprefer\-vector\-width=\fR\fIopt\fR" 4
  .IX Item "-mprefer-vector-width=opt"
! This option instructs \s-1GCC\s0 to use \fIopt\fR\-bit vector width in instructions
  instead of default on the selected platform.
! .IP "\fB\-mmove\-max=\fR\fIbits\fR" 4
  .IX Item "-mmove-max=bits"
! This option instructs \s-1GCC\s0 to set the maximum number of bits can be
  moved from memory to memory efficiently to \fIbits\fR.  The valid
  \&\fIbits\fR are 128, 256 and 512.
! .IP "\fB\-mstore\-max=\fR\fIbits\fR" 4
  .IX Item "-mstore-max=bits"
! This option instructs \s-1GCC\s0 to set the maximum number of bits can be
  stored to memory efficiently to \fIbits\fR.  The valid \fIbits\fR are
  128, 256 and 512.
  .RS 4
! .IP "\fBnone\fR" 4
  .IX Item "none"
! No extra limitations applied to \s-1GCC\s0 other than defined by the selected platform.
! .IP "\fB128\fR" 4
  .IX Item "128"
  Prefer 128\-bit vector width for instructions.
! .IP "\fB256\fR" 4
  .IX Item "256"
  Prefer 256\-bit vector width for instructions.
! .IP "\fB512\fR" 4
  .IX Item "512"
  Prefer 512\-bit vector width for instructions.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mcx16\fR" 4
  .IX Item "-mcx16"
! This option enables \s-1GCC\s0 to generate \f(CW\*(C`CMPXCHG16B\*(C'\fR instructions in 64\-bit
! code to implement compare-and-exchange operations on 16\-byte aligned 128\-bit
  objects.  This is useful for atomic updates of data structures exceeding one
  machine word in size.  The compiler uses this instruction to implement
  \&\fB_\|_sync Builtins\fR.  However, for \fB_\|_atomic Builtins\fR operating on
  128\-bit integers, a library call is always used.
! .IP "\fB\-msahf\fR" 4
  .IX Item "-msahf"
  This option enables generation of \f(CW\*(C`SAHF\*(C'\fR instructions in 64\-bit code.
  Early Intel Pentium 4 CPUs with Intel 64 support,
  prior to the introduction of Pentium 4 G1 step in December 2005,
  lacked the \f(CW\*(C`LAHF\*(C'\fR and \f(CW\*(C`SAHF\*(C'\fR instructions
! which are supported by \s-1AMD64.\s0
  These are load and store instructions, respectively, for certain status flags.
  In 64\-bit mode, the \f(CW\*(C`SAHF\*(C'\fR instruction is used to optimize \f(CW\*(C`fmod\*(C'\fR,
! \&\f(CW\*(C`drem\*(C'\fR, and \f(CW\*(C`remainder\*(C'\fR built-in functions;
  see \fBOther Builtins\fR for details.
! .IP "\fB\-mmovbe\fR" 4
  .IX Item "-mmovbe"
  This option enables use of the \f(CW\*(C`movbe\*(C'\fR instruction to implement
  \&\f(CW\*(C`_\|_builtin_bswap32\*(C'\fR and \f(CW\*(C`_\|_builtin_bswap64\*(C'\fR.
! .IP "\fB\-mshstk\fR" 4
  .IX Item "-mshstk"
! The \fB\-mshstk\fR option enables shadow stack built-in functions
! from x86 Control-flow Enforcement Technology (\s-1CET\s0).
! .IP "\fB\-mcrc32\fR" 4
  .IX Item "-mcrc32"
! This option enables built-in functions \f(CW\*(C`_\|_builtin_ia32_crc32qi\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_ia32_crc32hi\*(C'\fR, \f(CW\*(C`_\|_builtin_ia32_crc32si\*(C'\fR and
  \&\f(CW\*(C`_\|_builtin_ia32_crc32di\*(C'\fR to generate the \f(CW\*(C`crc32\*(C'\fR machine instruction.
! .IP "\fB\-mmwait\fR" 4
  .IX Item "-mmwait"
! This option enables built-in functions \f(CW\*(C`_\|_builtin_ia32_monitor\*(C'\fR,
  and \f(CW\*(C`_\|_builtin_ia32_mwait\*(C'\fR to generate the \f(CW\*(C`monitor\*(C'\fR and
  \&\f(CW\*(C`mwait\*(C'\fR machine instructions.
! .IP "\fB\-mrecip\fR" 4
  .IX Item "-mrecip"
  This option enables use of \f(CW\*(C`RCPSS\*(C'\fR and \f(CW\*(C`RSQRTSS\*(C'\fR instructions
  (and their vectorized variants \f(CW\*(C`RCPPS\*(C'\fR and \f(CW\*(C`RSQRTPS\*(C'\fR)
! with an additional Newton-Raphson step
  to increase precision instead of \f(CW\*(C`DIVSS\*(C'\fR and \f(CW\*(C`SQRTSS\*(C'\fR
  (and their vectorized
! variants) for single-precision floating-point arguments.  These instructions
  are generated only when \fB\-funsafe\-math\-optimizations\fR is enabled
  together with \fB\-ffinite\-math\-only\fR and \fB\-fno\-trapping\-math\fR.
  Note that while the throughput of the sequence is higher than the throughput
! of the non-reciprocal instruction, the precision of the sequence can be
  decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.99999994).
  .Sp
! Note that \s-1GCC\s0 implements \f(CW\*(C`1.0f/sqrtf(\f(CIx\f(CW)\*(C'\fR in terms of \f(CW\*(C`RSQRTSS\*(C'\fR
  (or \f(CW\*(C`RSQRTPS\*(C'\fR) already with \fB\-ffast\-math\fR (or the above option
! combination), and doesn't need \fB\-mrecip\fR.
  .Sp
! Also note that \s-1GCC\s0 emits the above sequence with additional Newton-Raphson step
! for vectorized single-float division and vectorized \f(CW\*(C`sqrtf(\f(CIx\f(CW)\*(C'\fR
  already with \fB\-ffast\-math\fR (or the above option combination), and
! doesn't need \fB\-mrecip\fR.
! .IP "\fB\-mrecip=\fR\fIopt\fR" 4
  .IX Item "-mrecip=opt"
  This option controls which reciprocal estimate instructions
! may be used.  \fIopt\fR is a comma-separated list of options, which may
  be preceded by a \fB!\fR to invert the option:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
  Enable all estimate instructions.
! .IP "\fBdefault\fR" 4
  .IX Item "default"
  Enable the default instructions, equivalent to \fB\-mrecip\fR.
! .IP "\fBnone\fR" 4
  .IX Item "none"
  Disable all estimate instructions, equivalent to \fB\-mno\-recip\fR.
! .IP "\fBdiv\fR" 4
  .IX Item "div"
  Enable the approximation for scalar division.
! .IP "\fBvec-div\fR" 4
  .IX Item "vec-div"
  Enable the approximation for vectorized division.
! .IP "\fBsqrt\fR" 4
  .IX Item "sqrt"
  Enable the approximation for scalar square root.
! .IP "\fBvec-sqrt\fR" 4
  .IX Item "vec-sqrt"
  Enable the approximation for vectorized square root.
  .RE
--- 32243,32624 ----
  increases code size.  Code that is sensitive to stack space usage, such
  as embedded systems and operating system kernels, may want to reduce the
  preferred alignment to \fB\-mpreferred\-stack\-boundary=2\fR.
! .IP \fB\-mmmx\fR 4
  .IX Item "-mmmx"
  .PD 0
! .IP \fB\-msse\fR 4
  .IX Item "-msse"
! .IP \fB\-msse2\fR 4
  .IX Item "-msse2"
! .IP \fB\-msse3\fR 4
  .IX Item "-msse3"
! .IP \fB\-mssse3\fR 4
  .IX Item "-mssse3"
! .IP \fB\-msse4\fR 4
  .IX Item "-msse4"
! .IP \fB\-msse4a\fR 4
  .IX Item "-msse4a"
! .IP \fB\-msse4.1\fR 4
  .IX Item "-msse4.1"
! .IP \fB\-msse4.2\fR 4
  .IX Item "-msse4.2"
! .IP \fB\-mavx\fR 4
  .IX Item "-mavx"
! .IP \fB\-mavx2\fR 4
  .IX Item "-mavx2"
! .IP \fB\-mavx512f\fR 4
  .IX Item "-mavx512f"
! .IP \fB\-mavx512pf\fR 4
  .IX Item "-mavx512pf"
! .IP \fB\-mavx512er\fR 4
  .IX Item "-mavx512er"
! .IP \fB\-mavx512cd\fR 4
  .IX Item "-mavx512cd"
! .IP \fB\-mavx512vl\fR 4
  .IX Item "-mavx512vl"
! .IP \fB\-mavx512bw\fR 4
  .IX Item "-mavx512bw"
! .IP \fB\-mavx512dq\fR 4
  .IX Item "-mavx512dq"
! .IP \fB\-mavx512ifma\fR 4
  .IX Item "-mavx512ifma"
! .IP \fB\-mavx512vbmi\fR 4
  .IX Item "-mavx512vbmi"
! .IP \fB\-msha\fR 4
  .IX Item "-msha"
! .IP \fB\-maes\fR 4
  .IX Item "-maes"
! .IP \fB\-mpclmul\fR 4
  .IX Item "-mpclmul"
! .IP \fB\-mclflushopt\fR 4
  .IX Item "-mclflushopt"
! .IP \fB\-mclwb\fR 4
  .IX Item "-mclwb"
! .IP \fB\-mfsgsbase\fR 4
  .IX Item "-mfsgsbase"
! .IP \fB\-mptwrite\fR 4
  .IX Item "-mptwrite"
! .IP \fB\-mrdrnd\fR 4
  .IX Item "-mrdrnd"
! .IP \fB\-mf16c\fR 4
  .IX Item "-mf16c"
! .IP \fB\-mfma\fR 4
  .IX Item "-mfma"
! .IP \fB\-mpconfig\fR 4
  .IX Item "-mpconfig"
! .IP \fB\-mwbnoinvd\fR 4
  .IX Item "-mwbnoinvd"
! .IP \fB\-mfma4\fR 4
  .IX Item "-mfma4"
! .IP \fB\-mprfchw\fR 4
  .IX Item "-mprfchw"
! .IP \fB\-mrdpid\fR 4
  .IX Item "-mrdpid"
! .IP \fB\-mprefetchwt1\fR 4
  .IX Item "-mprefetchwt1"
! .IP \fB\-mrdseed\fR 4
  .IX Item "-mrdseed"
! .IP \fB\-msgx\fR 4
  .IX Item "-msgx"
! .IP \fB\-mxop\fR 4
  .IX Item "-mxop"
! .IP \fB\-mlwp\fR 4
  .IX Item "-mlwp"
! .IP \fB\-m3dnow\fR 4
  .IX Item "-m3dnow"
! .IP \fB\-m3dnowa\fR 4
  .IX Item "-m3dnowa"
! .IP \fB\-mpopcnt\fR 4
  .IX Item "-mpopcnt"
! .IP \fB\-mabm\fR 4
  .IX Item "-mabm"
! .IP \fB\-madx\fR 4
  .IX Item "-madx"
! .IP \fB\-mbmi\fR 4
  .IX Item "-mbmi"
! .IP \fB\-mbmi2\fR 4
  .IX Item "-mbmi2"
! .IP \fB\-mlzcnt\fR 4
  .IX Item "-mlzcnt"
! .IP \fB\-mfxsr\fR 4
  .IX Item "-mfxsr"
! .IP \fB\-mxsave\fR 4
  .IX Item "-mxsave"
! .IP \fB\-mxsaveopt\fR 4
  .IX Item "-mxsaveopt"
! .IP \fB\-mxsavec\fR 4
  .IX Item "-mxsavec"
! .IP \fB\-mxsaves\fR 4
  .IX Item "-mxsaves"
! .IP \fB\-mrtm\fR 4
  .IX Item "-mrtm"
! .IP \fB\-mhle\fR 4
  .IX Item "-mhle"
! .IP \fB\-mtbm\fR 4
  .IX Item "-mtbm"
! .IP \fB\-mmwaitx\fR 4
  .IX Item "-mmwaitx"
! .IP \fB\-mclzero\fR 4
  .IX Item "-mclzero"
! .IP \fB\-mpku\fR 4
  .IX Item "-mpku"
! .IP \fB\-mavx512vbmi2\fR 4
  .IX Item "-mavx512vbmi2"
! .IP \fB\-mavx512bf16\fR 4
  .IX Item "-mavx512bf16"
! .IP \fB\-mavx512fp16\fR 4
  .IX Item "-mavx512fp16"
! .IP \fB\-mgfni\fR 4
  .IX Item "-mgfni"
! .IP \fB\-mvaes\fR 4
  .IX Item "-mvaes"
! .IP \fB\-mwaitpkg\fR 4
  .IX Item "-mwaitpkg"
! .IP \fB\-mvpclmulqdq\fR 4
  .IX Item "-mvpclmulqdq"
! .IP \fB\-mavx512bitalg\fR 4
  .IX Item "-mavx512bitalg"
! .IP \fB\-mmovdiri\fR 4
  .IX Item "-mmovdiri"
! .IP \fB\-mmovdir64b\fR 4
  .IX Item "-mmovdir64b"
! .IP \fB\-menqcmd\fR 4
  .IX Item "-menqcmd"
! .IP \fB\-muintr\fR 4
  .IX Item "-muintr"
! .IP \fB\-mtsxldtrk\fR 4
  .IX Item "-mtsxldtrk"
! .IP \fB\-mavx512vpopcntdq\fR 4
  .IX Item "-mavx512vpopcntdq"
! .IP \fB\-mavx512vp2intersect\fR 4
  .IX Item "-mavx512vp2intersect"
! .IP \fB\-mavx5124fmaps\fR 4
  .IX Item "-mavx5124fmaps"
! .IP \fB\-mavx512vnni\fR 4
  .IX Item "-mavx512vnni"
! .IP \fB\-mavxvnni\fR 4
  .IX Item "-mavxvnni"
! .IP \fB\-mavx5124vnniw\fR 4
  .IX Item "-mavx5124vnniw"
! .IP \fB\-mcldemote\fR 4
  .IX Item "-mcldemote"
! .IP \fB\-mserialize\fR 4
  .IX Item "-mserialize"
! .IP \fB\-mamx\-tile\fR 4
  .IX Item "-mamx-tile"
! .IP \fB\-mamx\-int8\fR 4
  .IX Item "-mamx-int8"
! .IP \fB\-mamx\-bf16\fR 4
  .IX Item "-mamx-bf16"
! .IP \fB\-mhreset\fR 4
  .IX Item "-mhreset"
! .IP \fB\-mkl\fR 4
  .IX Item "-mkl"
! .IP \fB\-mwidekl\fR 4
  .IX Item "-mwidekl"
! .IP \fB\-mavxifma\fR 4
  .IX Item "-mavxifma"
! .IP \fB\-mavxvnniint8\fR 4
  .IX Item "-mavxvnniint8"
! .IP \fB\-mavxneconvert\fR 4
  .IX Item "-mavxneconvert"
! .IP \fB\-mcmpccxadd\fR 4
  .IX Item "-mcmpccxadd"
! .IP \fB\-mamx\-fp16\fR 4
  .IX Item "-mamx-fp16"
! .IP \fB\-mprefetchi\fR 4
  .IX Item "-mprefetchi"
! .IP \fB\-mraoint\fR 4
  .IX Item "-mraoint"
! .IP \fB\-mamx\-complex\fR 4
  .IX Item "-mamx-complex"
  .PD
! These switches enable the use of instructions in the MMX, SSE,
  SSE2, SSE3, SSSE3, SSE4, SSE4A, SSE4.1, SSE4.2, AVX, AVX2, AVX512F, AVX512PF,
  AVX512ER, AVX512CD, AVX512VL, AVX512BW, AVX512DQ, AVX512IFMA, AVX512VBMI, SHA,
  AES, PCLMUL, CLFLUSHOPT, CLWB, FSGSBASE, PTWRITE, RDRND, F16C, FMA, PCONFIG,
! WBNOINVD, FMA4, PREFETCHW, RDPID, PREFETCHWT1, RDSEED, SGX, XOP, LWP,
! 3DNow!, enhanced 3DNow!, POPCNT, ABM, ADX, BMI, BMI2, LZCNT, FXSR, XSAVE,
  XSAVEOPT, XSAVEC, XSAVES, RTM, HLE, TBM, MWAITX, CLZERO, PKU, AVX512VBMI2,
  GFNI, VAES, WAITPKG, VPCLMULQDQ, AVX512BITALG, MOVDIRI, MOVDIR64B, AVX512BF16,
  ENQCMD, AVX512VPOPCNTDQ, AVX5124FMAPS, AVX512VNNI, AVX5124VNNIW, SERIALIZE,
  UINTR, HRESET, AMXTILE, AMXINT8, AMXBF16, KL, WIDEKL, AVXVNNI, AVX512\-FP16,
! AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AMX\-FP16, PREFETCHI, RAOINT,
! AMX\-COMPLEX or CLDEMOTE extended instruction sets. Each has a corresponding
  \&\fB\-mno\-\fR option to disable use of these instructions.
  .Sp
! These extensions are also available as built\-in functions: see
! \&\fBx86 Built\-in Functions\fR, for details of the functions enabled and
  disabled by these switches.
  .Sp
! To generate SSE/SSE2 instructions automatically from floating\-point
  code (as opposed to 387 instructions), see \fB\-mfpmath=sse\fR.
  .Sp
! GCC depresses SSEx instructions when \fB\-mavx\fR is used. Instead, it
! generates new AVX instructions or AVX equivalence for all SSEx instructions
  when needed.
  .Sp
! These options enable GCC to use these extended instructions in
  generated code, even without \fB\-mfpmath=sse\fR.  Applications that
! perform run\-time CPU detection must compile separate files for each
  supported architecture, using the appropriate flags.  In particular,
! the file containing the CPU detection code should be compiled without
  these options.
! .IP \fB\-mdump\-tune\-features\fR 4
  .IX Item "-mdump-tune-features"
! This option instructs GCC to dump the names of the x86 performance 
  tuning features and default settings. The names can be used in 
! \&\fB\-mtune\-ctrl=\fR\fIfeature\-list\fR.
! .IP \fB\-mtune\-ctrl=\fR\fIfeature\-list\fR 4
  .IX Item "-mtune-ctrl=feature-list"
  This option is used to do fine grain control of x86 code generation features.
! \&\fIfeature\-list\fR is a comma separated list of \fIfeature\fR names. See also
  \&\fB\-mdump\-tune\-features\fR. When specified, the \fIfeature\fR is turned
  on if it is not preceded with \fB^\fR, otherwise, it is turned off. 
! \&\fB\-mtune\-ctrl=\fR\fIfeature\-list\fR is intended to be used by GCC
  developers. Using it may lead to code paths not covered by testing and can
  potentially result in compiler ICEs or runtime errors.
! .IP \fB\-mno\-default\fR 4
  .IX Item "-mno-default"
! This option instructs GCC to turn off all tunable features. See also 
! \&\fB\-mtune\-ctrl=\fR\fIfeature\-list\fR and \fB\-mdump\-tune\-features\fR.
! .IP \fB\-mcld\fR 4
  .IX Item "-mcld"
! This option instructs GCC to emit a \f(CW\*(C`cld\*(C'\fR 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 \fB\-\-enable\-cld\fR configure option.  Generation of \f(CW\*(C`cld\*(C'\fR
  instructions can be suppressed with the \fB\-mno\-cld\fR compiler option
  in this case.
! .IP \fB\-mvzeroupper\fR 4
  .IX Item "-mvzeroupper"
! This option instructs GCC to emit a \f(CW\*(C`vzeroupper\*(C'\fR instruction
  before a transfer of control flow out of the function to minimize
! the AVX to SSE transition penalty as well as remove unnecessary \f(CW\*(C`zeroupper\*(C'\fR
  intrinsics.
! .IP \fB\-mprefer\-avx128\fR 4
  .IX Item "-mprefer-avx128"
! This option instructs GCC to use 128\-bit AVX instructions instead of
! 256\-bit AVX instructions in the auto\-vectorizer.
! .IP \fB\-mprefer\-vector\-width=\fR\fIopt\fR 4
  .IX Item "-mprefer-vector-width=opt"
! This option instructs GCC to use \fIopt\fR\-bit vector width in instructions
  instead of default on the selected platform.
! .IP \fB\-mmove\-max=\fR\fIbits\fR 4
  .IX Item "-mmove-max=bits"
! This option instructs GCC to set the maximum number of bits can be
  moved from memory to memory efficiently to \fIbits\fR.  The valid
  \&\fIbits\fR are 128, 256 and 512.
! .IP \fB\-mstore\-max=\fR\fIbits\fR 4
  .IX Item "-mstore-max=bits"
! This option instructs GCC to set the maximum number of bits can be
  stored to memory efficiently to \fIbits\fR.  The valid \fIbits\fR are
  128, 256 and 512.
  .RS 4
! .IP \fBnone\fR 4
  .IX Item "none"
! No extra limitations applied to GCC other than defined by the selected platform.
! .IP \fB128\fR 4
  .IX Item "128"
  Prefer 128\-bit vector width for instructions.
! .IP \fB256\fR 4
  .IX Item "256"
  Prefer 256\-bit vector width for instructions.
! .IP \fB512\fR 4
  .IX Item "512"
  Prefer 512\-bit vector width for instructions.
  .RE
  .RS 4
  .RE
! .IP \fB\-mcx16\fR 4
  .IX Item "-mcx16"
! This option enables GCC to generate \f(CW\*(C`CMPXCHG16B\*(C'\fR instructions in 64\-bit
! code to implement compare\-and\-exchange operations on 16\-byte aligned 128\-bit
  objects.  This is useful for atomic updates of data structures exceeding one
  machine word in size.  The compiler uses this instruction to implement
  \&\fB_\|_sync Builtins\fR.  However, for \fB_\|_atomic Builtins\fR operating on
  128\-bit integers, a library call is always used.
! .IP \fB\-msahf\fR 4
  .IX Item "-msahf"
  This option enables generation of \f(CW\*(C`SAHF\*(C'\fR instructions in 64\-bit code.
  Early Intel Pentium 4 CPUs with Intel 64 support,
  prior to the introduction of Pentium 4 G1 step in December 2005,
  lacked the \f(CW\*(C`LAHF\*(C'\fR and \f(CW\*(C`SAHF\*(C'\fR instructions
! which are supported by AMD64.
  These are load and store instructions, respectively, for certain status flags.
  In 64\-bit mode, the \f(CW\*(C`SAHF\*(C'\fR instruction is used to optimize \f(CW\*(C`fmod\*(C'\fR,
! \&\f(CW\*(C`drem\*(C'\fR, and \f(CW\*(C`remainder\*(C'\fR built\-in functions;
  see \fBOther Builtins\fR for details.
! .IP \fB\-mmovbe\fR 4
  .IX Item "-mmovbe"
  This option enables use of the \f(CW\*(C`movbe\*(C'\fR instruction to implement
  \&\f(CW\*(C`_\|_builtin_bswap32\*(C'\fR and \f(CW\*(C`_\|_builtin_bswap64\*(C'\fR.
! .IP \fB\-mshstk\fR 4
  .IX Item "-mshstk"
! The \fB\-mshstk\fR option enables shadow stack built\-in functions
! from x86 Control\-flow Enforcement Technology (CET).
! .IP \fB\-mcrc32\fR 4
  .IX Item "-mcrc32"
! This option enables built\-in functions \f(CW\*(C`_\|_builtin_ia32_crc32qi\*(C'\fR,
  \&\f(CW\*(C`_\|_builtin_ia32_crc32hi\*(C'\fR, \f(CW\*(C`_\|_builtin_ia32_crc32si\*(C'\fR and
  \&\f(CW\*(C`_\|_builtin_ia32_crc32di\*(C'\fR to generate the \f(CW\*(C`crc32\*(C'\fR machine instruction.
! .IP \fB\-mmwait\fR 4
  .IX Item "-mmwait"
! This option enables built\-in functions \f(CW\*(C`_\|_builtin_ia32_monitor\*(C'\fR,
  and \f(CW\*(C`_\|_builtin_ia32_mwait\*(C'\fR to generate the \f(CW\*(C`monitor\*(C'\fR and
  \&\f(CW\*(C`mwait\*(C'\fR machine instructions.
! .IP \fB\-mrecip\fR 4
  .IX Item "-mrecip"
  This option enables use of \f(CW\*(C`RCPSS\*(C'\fR and \f(CW\*(C`RSQRTSS\*(C'\fR instructions
  (and their vectorized variants \f(CW\*(C`RCPPS\*(C'\fR and \f(CW\*(C`RSQRTPS\*(C'\fR)
! with an additional Newton\-Raphson step
  to increase precision instead of \f(CW\*(C`DIVSS\*(C'\fR and \f(CW\*(C`SQRTSS\*(C'\fR
  (and their vectorized
! variants) for single\-precision floating\-point arguments.  These instructions
  are generated only when \fB\-funsafe\-math\-optimizations\fR is enabled
  together with \fB\-ffinite\-math\-only\fR and \fB\-fno\-trapping\-math\fR.
  Note that while the throughput of the sequence is higher than the throughput
! of the non\-reciprocal instruction, the precision of the sequence can be
  decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.99999994).
  .Sp
! Note that GCC implements \f(CW\*(C`1.0f/sqrtf(\fR\f(CIx\fR\f(CW)\*(C'\fR in terms of \f(CW\*(C`RSQRTSS\*(C'\fR
  (or \f(CW\*(C`RSQRTPS\*(C'\fR) already with \fB\-ffast\-math\fR (or the above option
! combination), and doesn\*(Aqt need \fB\-mrecip\fR.
  .Sp
! Also note that GCC emits the above sequence with additional Newton\-Raphson step
! for vectorized single\-float division and vectorized \f(CWsqrtf(\fR\f(CIx\fR\f(CW)\fR
  already with \fB\-ffast\-math\fR (or the above option combination), and
! doesn\*(Aqt need \fB\-mrecip\fR.
! .IP \fB\-mrecip=\fR\fIopt\fR 4
  .IX Item "-mrecip=opt"
  This option controls which reciprocal estimate instructions
! may be used.  \fIopt\fR is a comma\-separated list of options, which may
  be preceded by a \fB!\fR to invert the option:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
  Enable all estimate instructions.
! .IP \fBdefault\fR 4
  .IX Item "default"
  Enable the default instructions, equivalent to \fB\-mrecip\fR.
! .IP \fBnone\fR 4
  .IX Item "none"
  Disable all estimate instructions, equivalent to \fB\-mno\-recip\fR.
! .IP \fBdiv\fR 4
  .IX Item "div"
  Enable the approximation for scalar division.
! .IP \fBvec\-div\fR 4
  .IX Item "vec-div"
  Enable the approximation for vectorized division.
! .IP \fBsqrt\fR 4
  .IX Item "sqrt"
  Enable the approximation for scalar square root.
! .IP \fBvec\-sqrt\fR 4
  .IX Item "vec-sqrt"
  Enable the approximation for vectorized square root.
  .RE
*************** Enable the approximation for vectorized
*** 32696,32712 ****
  So, for example, \fB\-mrecip=all,!sqrt\fR enables
  all of the reciprocal approximations, except for square root.
  .RE
! .IP "\fB\-mveclibabi=\fR\fItype\fR" 4
  .IX Item "-mveclibabi=type"
! Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
  external library.  Supported values for \fItype\fR are \fBsvml\fR 
  for the Intel short
! vector math library and \fBacml\fR for the \s-1AMD\s0 math core library.
  To use this option, both \fB\-ftree\-vectorize\fR and
! \&\fB\-funsafe\-math\-optimizations\fR have to be enabled, and an \s-1SVML\s0 or \s-1ACML\s0 
! ABI-compatible library must be specified at link time.
  .Sp
! \&\s-1GCC\s0 currently emits calls to \f(CW\*(C`vmldExp2\*(C'\fR,
  \&\f(CW\*(C`vmldLn2\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldPow2\*(C'\fR,
  \&\f(CW\*(C`vmldTanh2\*(C'\fR, \f(CW\*(C`vmldTan2\*(C'\fR, \f(CW\*(C`vmldAtan2\*(C'\fR, \f(CW\*(C`vmldAtanh2\*(C'\fR,
  \&\f(CW\*(C`vmldCbrt2\*(C'\fR, \f(CW\*(C`vmldSinh2\*(C'\fR, \f(CW\*(C`vmldSin2\*(C'\fR, \f(CW\*(C`vmldAsinh2\*(C'\fR,
--- 32627,32643 ----
  So, for example, \fB\-mrecip=all,!sqrt\fR enables
  all of the reciprocal approximations, except for square root.
  .RE
! .IP \fB\-mveclibabi=\fR\fItype\fR 4
  .IX Item "-mveclibabi=type"
! Specifies the ABI type to use for vectorizing intrinsics using an
  external library.  Supported values for \fItype\fR are \fBsvml\fR 
  for the Intel short
! vector math library and \fBacml\fR for the AMD math core library.
  To use this option, both \fB\-ftree\-vectorize\fR and
! \&\fB\-funsafe\-math\-optimizations\fR have to be enabled, and an SVML or ACML 
! ABI\-compatible library must be specified at link time.
  .Sp
! GCC currently emits calls to \f(CW\*(C`vmldExp2\*(C'\fR,
  \&\f(CW\*(C`vmldLn2\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldPow2\*(C'\fR,
  \&\f(CW\*(C`vmldTanh2\*(C'\fR, \f(CW\*(C`vmldTan2\*(C'\fR, \f(CW\*(C`vmldAtan2\*(C'\fR, \f(CW\*(C`vmldAtanh2\*(C'\fR,
  \&\f(CW\*(C`vmldCbrt2\*(C'\fR, \f(CW\*(C`vmldSinh2\*(C'\fR, \f(CW\*(C`vmldSin2\*(C'\fR, \f(CW\*(C`vmldAsinh2\*(C'\fR,
*************** function type when \fB\-mveclibabi=svml\
*** 32722,32808 ****
  \&\f(CW\*(C`_\|_vrs4_expf\*(C'\fR, \f(CW\*(C`_\|_vrs4_logf\*(C'\fR, \f(CW\*(C`_\|_vrs4_log2f\*(C'\fR,
  \&\f(CW\*(C`_\|_vrs4_log10f\*(C'\fR and \f(CW\*(C`_\|_vrs4_powf\*(C'\fR for the corresponding function type
  when \fB\-mveclibabi=acml\fR is used.
! .IP "\fB\-mabi=\fR\fIname\fR" 4
  .IX Item "-mabi=name"
  Generate code for the specified calling convention.  Permissible values
! are \fBsysv\fR for the \s-1ABI\s0 used on GNU/Linux and other systems, and
! \&\fBms\fR for the Microsoft \s-1ABI.\s0  The default is to use the Microsoft
! \&\s-1ABI\s0 when targeting Microsoft Windows and the SysV \s-1ABI\s0 on all other systems.
  You can control this behavior for specific functions by
  using the function attributes \f(CW\*(C`ms_abi\*(C'\fR and \f(CW\*(C`sysv_abi\*(C'\fR.
! .IP "\fB\-mforce\-indirect\-call\fR" 4
  .IX Item "-mforce-indirect-call"
  Force all calls to functions to be indirect. This is useful
  when using Intel Processor Trace where it generates more precise timing
  information for function calls.
! .IP "\fB\-mmanual\-endbr\fR" 4
  .IX Item "-mmanual-endbr"
! Insert \s-1ENDBR\s0 instruction at function entry only via the \f(CW\*(C`cf_check\*(C'\fR
  function attribute. This is useful when used with the option
! \&\fB\-fcf\-protection=branch\fR to control \s-1ENDBR\s0 insertion at the
  function entry.
! .IP "\fB\-mcet\-switch\fR" 4
  .IX Item "-mcet-switch"
! By default, \s-1CET\s0 instrumentation is turned off on switch statements that
  use a jump table and indirect branch track is disabled.  Since jump
! tables are stored in read-only memory, this does not result in a direct
! loss of hardening.  But if the jump table index is attacker-controlled,
! the indirect jump may not be constrained by \s-1CET.\s0  This option turns on
! \&\s-1CET\s0 instrumentation to enable indirect branch track for switch statements
  with jump tables which leads to the jump targets reachable via any indirect
  jumps.
! .IP "\fB\-mcall\-ms2sysv\-xlogues\fR" 4
  .IX Item "-mcall-ms2sysv-xlogues"
! Due to differences in 64\-bit ABIs, any Microsoft \s-1ABI\s0 function that calls a
! System V \s-1ABI\s0 function must consider \s-1RSI, RDI\s0 and \s-1XMM6\-15\s0 as clobbered.  By
  default, the code for saving and restoring these registers is emitted inline,
  resulting in fairly lengthy prologues and epilogues.  Using
  \&\fB\-mcall\-ms2sysv\-xlogues\fR emits prologues and epilogues that
  use stubs in the static portion of libgcc to perform these saves and restores,
  thus reducing function size at the cost of a few extra instructions.
! .IP "\fB\-mtls\-dialect=\fR\fItype\fR" 4
  .IX Item "-mtls-dialect=type"
! Generate code to access thread-local storage using the \fBgnu\fR or
  \&\fBgnu2\fR conventions.  \fBgnu\fR is the conservative default;
! \&\fBgnu2\fR is more efficient, but it may add compile\- and run-time
  requirements that cannot be satisfied on all systems.
! .IP "\fB\-mpush\-args\fR" 4
  .IX Item "-mpush-args"
  .PD 0
! .IP "\fB\-mno\-push\-args\fR" 4
  .IX Item "-mno-push-args"
  .PD
! Use \s-1PUSH\s0 operations to store outgoing parameters.  This method is shorter
! and usually equally fast as method using \s-1SUB/MOV\s0 operations and is enabled
  by default.  In some cases disabling it may improve performance because of
  improved scheduling and reduced dependencies.
! .IP "\fB\-maccumulate\-outgoing\-args\fR" 4
  .IX Item "-maccumulate-outgoing-args"
  If enabled, the maximum amount of space required for outgoing arguments is
  computed in the function prologue.  This is faster on most modern CPUs
  because of reduced dependencies, improved scheduling and reduced stack usage
  when the preferred stack boundary is not equal to 2.  The drawback is a notable
  increase in code size.  This switch implies \fB\-mno\-push\-args\fR.
! .IP "\fB\-mthreads\fR" 4
  .IX Item "-mthreads"
! Support thread-safe exception handling on MinGW.  Programs that rely
! on thread-safe exception handling must compile and link all code with the
  \&\fB\-mthreads\fR option.  When compiling, \fB\-mthreads\fR defines
  \&\fB\-D_MT\fR; when linking, it links in a special thread helper library
! \&\fB\-lmingwthrd\fR which cleans up per-thread exception-handling data.
! .IP "\fB\-mms\-bitfields\fR" 4
  .IX Item "-mms-bitfields"
  .PD 0
! .IP "\fB\-mno\-ms\-bitfields\fR" 4
  .IX Item "-mno-ms-bitfields"
  .PD
! Enable/disable bit-field layout compatible with the native Microsoft
  Windows compiler.
  .Sp
! If \f(CW\*(C`packed\*(C'\fR is used on a structure, or if bit-fields are used,
! it may be that the Microsoft \s-1ABI\s0 lays out the structure differently
! than the way \s-1GCC\s0 normally does.  Particularly when moving packed
! data between functions compiled with \s-1GCC\s0 and the native Microsoft compiler
  (either via function call or as data in a file), it may be necessary to access
  either format.
  .Sp
--- 32653,32739 ----
  \&\f(CW\*(C`_\|_vrs4_expf\*(C'\fR, \f(CW\*(C`_\|_vrs4_logf\*(C'\fR, \f(CW\*(C`_\|_vrs4_log2f\*(C'\fR,
  \&\f(CW\*(C`_\|_vrs4_log10f\*(C'\fR and \f(CW\*(C`_\|_vrs4_powf\*(C'\fR for the corresponding function type
  when \fB\-mveclibabi=acml\fR is used.
! .IP \fB\-mabi=\fR\fIname\fR 4
  .IX Item "-mabi=name"
  Generate code for the specified calling convention.  Permissible values
! are \fBsysv\fR for the ABI used on GNU/Linux and other systems, and
! \&\fBms\fR for the Microsoft ABI.  The default is to use the Microsoft
! ABI when targeting Microsoft Windows and the SysV ABI on all other systems.
  You can control this behavior for specific functions by
  using the function attributes \f(CW\*(C`ms_abi\*(C'\fR and \f(CW\*(C`sysv_abi\*(C'\fR.
! .IP \fB\-mforce\-indirect\-call\fR 4
  .IX Item "-mforce-indirect-call"
  Force all calls to functions to be indirect. This is useful
  when using Intel Processor Trace where it generates more precise timing
  information for function calls.
! .IP \fB\-mmanual\-endbr\fR 4
  .IX Item "-mmanual-endbr"
! Insert ENDBR instruction at function entry only via the \f(CW\*(C`cf_check\*(C'\fR
  function attribute. This is useful when used with the option
! \&\fB\-fcf\-protection=branch\fR to control ENDBR insertion at the
  function entry.
! .IP \fB\-mcet\-switch\fR 4
  .IX Item "-mcet-switch"
! By default, CET instrumentation is turned off on switch statements that
  use a jump table and indirect branch track is disabled.  Since jump
! tables are stored in read\-only memory, this does not result in a direct
! loss of hardening.  But if the jump table index is attacker\-controlled,
! the indirect jump may not be constrained by CET.  This option turns on
! CET instrumentation to enable indirect branch track for switch statements
  with jump tables which leads to the jump targets reachable via any indirect
  jumps.
! .IP \fB\-mcall\-ms2sysv\-xlogues\fR 4
  .IX Item "-mcall-ms2sysv-xlogues"
! Due to differences in 64\-bit ABIs, any Microsoft ABI function that calls a
! System V ABI function must consider RSI, RDI and XMM6\-15 as clobbered.  By
  default, the code for saving and restoring these registers is emitted inline,
  resulting in fairly lengthy prologues and epilogues.  Using
  \&\fB\-mcall\-ms2sysv\-xlogues\fR emits prologues and epilogues that
  use stubs in the static portion of libgcc to perform these saves and restores,
  thus reducing function size at the cost of a few extra instructions.
! .IP \fB\-mtls\-dialect=\fR\fItype\fR 4
  .IX Item "-mtls-dialect=type"
! Generate code to access thread\-local storage using the \fBgnu\fR or
  \&\fBgnu2\fR conventions.  \fBgnu\fR is the conservative default;
! \&\fBgnu2\fR is more efficient, but it may add compile\- and run\-time
  requirements that cannot be satisfied on all systems.
! .IP \fB\-mpush\-args\fR 4
  .IX Item "-mpush-args"
  .PD 0
! .IP \fB\-mno\-push\-args\fR 4
  .IX Item "-mno-push-args"
  .PD
! Use 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.
! .IP \fB\-maccumulate\-outgoing\-args\fR 4
  .IX Item "-maccumulate-outgoing-args"
  If enabled, the maximum amount of space required for outgoing arguments is
  computed in the function prologue.  This is faster on most modern CPUs
  because of reduced dependencies, improved scheduling and reduced stack usage
  when the preferred stack boundary is not equal to 2.  The drawback is a notable
  increase in code size.  This switch implies \fB\-mno\-push\-args\fR.
! .IP \fB\-mthreads\fR 4
  .IX Item "-mthreads"
! Support thread\-safe exception handling on MinGW.  Programs that rely
! on thread\-safe exception handling must compile and link all code with the
  \&\fB\-mthreads\fR option.  When compiling, \fB\-mthreads\fR defines
  \&\fB\-D_MT\fR; when linking, it links in a special thread helper library
! \&\fB\-lmingwthrd\fR which cleans up per\-thread exception\-handling data.
! .IP \fB\-mms\-bitfields\fR 4
  .IX Item "-mms-bitfields"
  .PD 0
! .IP \fB\-mno\-ms\-bitfields\fR 4
  .IX Item "-mno-ms-bitfields"
  .PD
! Enable/disable bit\-field layout compatible with the native Microsoft
  Windows compiler.
  .Sp
! If \f(CW\*(C`packed\*(C'\fR is used on a structure, or if bit\-fields are used,
! it may be that the Microsoft ABI lays out the structure differently
! than the way GCC normally does.  Particularly when moving packed
! data between functions compiled with GCC and the native Microsoft compiler
  (either via function call or as data in a file), it may be necessary to access
  either format.
  .Sp
*************** or type attributes.  For more informatio
*** 32812,32820 ****
  and \fBx86 Type Attributes\fR.
  .Sp
  The Microsoft structure layout algorithm is fairly simple with the exception
! of the bit-field packing.  
! The padding and alignment of members of structures and whether a bit-field 
! can straddle a storage-unit boundary are determine by these rules:
  .RS 4
  .IP "1. Structure members are stored sequentially in the order in which they are" 4
  .IX Item "1. Structure members are stored sequentially in the order in which they are"
--- 32743,32751 ----
  and \fBx86 Type Attributes\fR.
  .Sp
  The Microsoft structure layout algorithm is fairly simple with the exception
! of the bit\-field packing.  
! The padding and alignment of members of structures and whether a bit\-field 
! can straddle a storage\-unit boundary are determine by these rules:
  .RS 4
  .IP "1. Structure members are stored sequentially in the order in which they are" 4
  .IX Item "1. Structure members are stored sequentially in the order in which they are"
*************** Every object is allocated an offset so t
*** 32832,32849 ****
  .Vb 1
  \&        offset % alignment_requirement == 0
  .Ve
! .IP "3. Adjacent bit-fields are packed into the same 1\-, 2\-, or 4\-byte allocation" 4
  .IX Item "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.
  .RE
  .RS 4
  .Sp
! \&\s-1MSVC\s0 interprets zero-length bit-fields in the following ways:
! .IP "1. If a zero-length bit-field is inserted between two bit-fields that" 4
  .IX Item "1. If a zero-length bit-field is inserted between two bit-fields that"
! are normally coalesced, the bit-fields are not coalesced.
  .Sp
  For example:
  .Sp
--- 32763,32780 ----
  .Vb 1
  \&        offset % alignment_requirement == 0
  .Ve
! .IP "3. Adjacent bit\-fields are packed into the same 1\-, 2\-, or 4\-byte allocation" 4
  .IX Item "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.
  .RE
  .RS 4
  .Sp
! MSVC interprets zero\-length bit\-fields in the following ways:
! .IP "1. If a zero\-length bit\-field is inserted between two bit\-fields that" 4
  .IX Item "1. If a zero-length bit-field is inserted between two bit-fields that"
! are normally coalesced, the bit\-fields are not coalesced.
  .Sp
  For example:
  .Sp
*************** For example:
*** 32856,32868 ****
  \&         } t1;
  .Ve
  .Sp
! The size of \f(CW\*(C`t1\*(C'\fR is 8 bytes with the zero-length bit-field.  If the
! zero-length bit-field were removed, \f(CW\*(C`t1\*(C'\fR's size would be 4 bytes.
! .ie n .IP "2. If a zero-length bit-field is inserted after a bit-field, ""foo"", and the" 4
! .el .IP "2. If a zero-length bit-field is inserted after a bit-field, \f(CWfoo\fR, and the" 4
  .IX Item "2. If a zero-length bit-field is inserted after a bit-field, foo, and the"
! alignment of the zero-length bit-field is greater than the member that follows it,
! \&\f(CW\*(C`bar\*(C'\fR, \f(CW\*(C`bar\*(C'\fR is aligned as the type of the zero-length bit-field.
  .Sp
  For example:
  .Sp
--- 32787,32799 ----
  \&         } t1;
  .Ve
  .Sp
! The size of \f(CW\*(C`t1\*(C'\fR is 8 bytes with the zero\-length bit\-field.  If the
! zero\-length bit\-field were removed, \f(CW\*(C`t1\*(C'\fR\*(Aqs size would be 4 bytes.
! .ie n .IP "2. If a zero\-length bit\-field is inserted after a bit\-field, ""foo"", and the" 4
! .el .IP "2. If a zero\-length bit\-field is inserted after a bit\-field, \f(CWfoo\fR, and the" 4
  .IX Item "2. If a zero-length bit-field is inserted after a bit-field, foo, and the"
! alignment of the zero\-length bit\-field is greater than the member that follows it,
! \&\f(CW\*(C`bar\*(C'\fR, \f(CW\*(C`bar\*(C'\fR is aligned as the type of the zero\-length bit\-field.
  .Sp
  For example:
  .Sp
*************** For example:
*** 32883,32900 ****
  .Ve
  .Sp
  For \f(CW\*(C`t2\*(C'\fR, \f(CW\*(C`bar\*(C'\fR is placed at offset 2, rather than offset 1.
! Accordingly, the size of \f(CW\*(C`t2\*(C'\fR is 4.  For \f(CW\*(C`t3\*(C'\fR, the zero-length
! bit-field does not affect the alignment of \f(CW\*(C`bar\*(C'\fR or, as a result, the size
  of the structure.
  .Sp
  Taking this into account, it is important to note the following:
  .RS 4
! .IP "1. If a zero-length bit-field follows a normal bit-field, the type of the" 4
  .IX Item "1. If a zero-length bit-field follows a normal bit-field, the type of the"
! zero-length bit-field may affect the alignment of the structure as whole. For
! example, \f(CW\*(C`t2\*(C'\fR has a size of 4 bytes, since the zero-length bit-field follows a
! normal bit-field, and is of type short.
! .IP "2. Even if a zero-length bit-field is not followed by a normal bit-field, it may" 4
  .IX Item "2. Even if a zero-length bit-field is not followed by a normal bit-field, it may"
  still affect the alignment of the structure:
  .Sp
--- 32814,32831 ----
  .Ve
  .Sp
  For \f(CW\*(C`t2\*(C'\fR, \f(CW\*(C`bar\*(C'\fR is placed at offset 2, rather than offset 1.
! Accordingly, the size of \f(CW\*(C`t2\*(C'\fR is 4.  For \f(CW\*(C`t3\*(C'\fR, the zero\-length
! bit\-field does not affect the alignment of \f(CW\*(C`bar\*(C'\fR or, as a result, the size
  of the structure.
  .Sp
  Taking this into account, it is important to note the following:
  .RS 4
! .IP "1. If a zero\-length bit\-field follows a normal bit\-field, the type of the" 4
  .IX Item "1. If a zero-length bit-field follows a normal bit-field, the type of the"
! zero\-length bit\-field may affect the alignment of the structure as whole. For
! example, \f(CW\*(C`t2\*(C'\fR has a size of 4 bytes, since the zero\-length bit\-field follows a
! normal bit\-field, and is of type short.
! .IP "2. Even if a zero\-length bit\-field is not followed by a normal bit\-field, it may" 4
  .IX Item "2. Even if a zero-length bit-field is not followed by a normal bit-field, it may"
  still affect the alignment of the structure:
  .Sp
*************** Here, \f(CW\*(C`t4\*(C'\fR takes up 4 by
*** 32910,32916 ****
  .RE
  .RS 4
  .RE
! .IP "3. Zero-length bit-fields following non-bit-field members are ignored:" 4
  .IX Item "3. Zero-length bit-fields following non-bit-field members are ignored:"
  .Vb 6
  \&        struct
--- 32841,32847 ----
  .RE
  .RS 4
  .RE
! .IP "3. Zero\-length bit\-fields following non\-bit\-field members are ignored:" 4
  .IX Item "3. Zero-length bit-fields following non-bit-field members are ignored:"
  .Vb 6
  \&        struct
*************** Here, \f(CW\*(C`t5\*(C'\fR takes up 2 by
*** 32925,33114 ****
  .RE
  .RS 4
  .RE
! .IP "\fB\-mno\-align\-stringops\fR" 4
  .IX Item "-mno-align-stringops"
  Do not align the destination of inlined string operations.  This switch reduces
  code size and improves performance in case the destination is already aligned,
! but \s-1GCC\s0 doesn't know about it.
! .IP "\fB\-minline\-all\-stringops\fR" 4
  .IX Item "-minline-all-stringops"
! By default \s-1GCC\s0 inlines string operations only when the destination is 
  known to be aligned to least a 4\-byte boundary.  
  This enables more inlining and increases code
  size, but may improve performance of code that depends on fast
  \&\f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memset\*(C'\fR for short lengths.
  The option enables inline expansion of \f(CW\*(C`strlen\*(C'\fR for all
  pointer alignments.
! .IP "\fB\-minline\-stringops\-dynamically\fR" 4
  .IX Item "-minline-stringops-dynamically"
! For string operations of unknown size, use run-time checks with
  inline code for small blocks and a library call for large blocks.
! .IP "\fB\-mstringop\-strategy=\fR\fIalg\fR" 4
  .IX Item "-mstringop-strategy=alg"
  Override the internal decision heuristic for the particular algorithm to use
  for inlining string operations.  The allowed values for \fIalg\fR are:
  .RS 4
! .IP "\fBrep_byte\fR" 4
  .IX Item "rep_byte"
  .PD 0
! .IP "\fBrep_4byte\fR" 4
  .IX Item "rep_4byte"
! .IP "\fBrep_8byte\fR" 4
  .IX Item "rep_8byte"
  .PD
  Expand using i386 \f(CW\*(C`rep\*(C'\fR prefix of the specified size.
! .IP "\fBbyte_loop\fR" 4
  .IX Item "byte_loop"
  .PD 0
! .IP "\fBloop\fR" 4
  .IX Item "loop"
! .IP "\fBunrolled_loop\fR" 4
  .IX Item "unrolled_loop"
  .PD
  Expand into an inline loop.
! .IP "\fBlibcall\fR" 4
  .IX Item "libcall"
  Always use a library call.
  .RE
  .RS 4
  .RE
! .IP "\fB\-mmemcpy\-strategy=\fR\fIstrategy\fR" 4
  .IX Item "-mmemcpy-strategy=strategy"
  Override the internal decision heuristic to decide if \f(CW\*(C`_\|_builtin_memcpy\*(C'\fR
  should be inlined and what inline algorithm to use when the expected size
  of the copy operation is known. \fIstrategy\fR 
! is a comma-separated list of \fIalg\fR:\fImax_size\fR:\fIdest_align\fR triplets. 
  \&\fIalg\fR is specified in \fB\-mstringop\-strategy\fR, \fImax_size\fR specifies
  the max byte size with which inline algorithm \fIalg\fR is allowed.  For the last
! triplet, the \fImax_size\fR must be \f(CW\*(C`\-1\*(C'\fR. The \fImax_size\fR of the triplets
  in the list must be specified in increasing order.  The minimal byte size for 
! \&\fIalg\fR is \f(CW0\fR for the first triplet and \f(CW\*(C`\f(CImax_size\f(CW + 1\*(C'\fR of the 
  preceding range.
! .IP "\fB\-mmemset\-strategy=\fR\fIstrategy\fR" 4
  .IX Item "-mmemset-strategy=strategy"
  The option is similar to \fB\-mmemcpy\-strategy=\fR except that it is to control
  \&\f(CW\*(C`_\|_builtin_memset\*(C'\fR expansion.
! .IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
  .IX Item "-momit-leaf-frame-pointer"
! Don't keep the frame pointer in a register for leaf functions.  This
  avoids the instructions to save, set up, and restore frame pointers and
  makes an extra register available in leaf functions.  The option
  \&\fB\-fomit\-leaf\-frame\-pointer\fR removes the frame pointer for leaf functions,
  which might make debugging harder.
! .IP "\fB\-mtls\-direct\-seg\-refs\fR" 4
  .IX Item "-mtls-direct-seg-refs"
  .PD 0
! .IP "\fB\-mno\-tls\-direct\-seg\-refs\fR" 4
  .IX Item "-mno-tls-direct-seg-refs"
  .PD
! Controls whether \s-1TLS\s0 variables may be accessed with offsets from the
! \&\s-1TLS\s0 segment register (\f(CW%gs\fR for 32\-bit, \f(CW%fs\fR for 64\-bit),
  or whether the thread base pointer must be added.  Whether or not this
  is valid depends on the operating system, and whether it maps the
! segment to cover the entire \s-1TLS\s0 area.
  .Sp
! For systems that use the \s-1GNU C\s0 Library, the default is on.
! .IP "\fB\-msse2avx\fR" 4
  .IX Item "-msse2avx"
  .PD 0
! .IP "\fB\-mno\-sse2avx\fR" 4
  .IX Item "-mno-sse2avx"
  .PD
! Specify that the assembler should encode \s-1SSE\s0 instructions with \s-1VEX\s0
  prefix.  The option \fB\-mavx\fR turns this on by default.
! .IP "\fB\-mfentry\fR" 4
  .IX Item "-mfentry"
  .PD 0
! .IP "\fB\-mno\-fentry\fR" 4
  .IX Item "-mno-fentry"
  .PD
  If profiling is active (\fB\-pg\fR), put the profiling
  counter call before the prologue.
  Note: On x86 architectures the attribute \f(CW\*(C`ms_hook_prologue\*(C'\fR
! isn't possible at the moment for \fB\-mfentry\fR and \fB\-pg\fR.
! .IP "\fB\-mrecord\-mcount\fR" 4
  .IX Item "-mrecord-mcount"
  .PD 0
! .IP "\fB\-mno\-record\-mcount\fR" 4
  .IX Item "-mno-record-mcount"
  .PD
  If profiling is active (\fB\-pg\fR), generate a _\|_mcount_loc section
  that contains pointers to each profiling call. This is useful for
  automatically patching and out calls.
! .IP "\fB\-mnop\-mcount\fR" 4
  .IX Item "-mnop-mcount"
  .PD 0
! .IP "\fB\-mno\-nop\-mcount\fR" 4
  .IX Item "-mno-nop-mcount"
  .PD
  If profiling is active (\fB\-pg\fR), generate the calls to
  the profiling functions as NOPs. This is useful when they
  should be patched in later dynamically. This is likely only
  useful together with \fB\-mrecord\-mcount\fR.
! .IP "\fB\-minstrument\-return=\fR\fItype\fR" 4
  .IX Item "-minstrument-return=type"
  Instrument function exit in \-pg \-mfentry instrumented functions with
  call to specified function. This only instruments true returns ending
  with ret, but not sibling calls ending with jump. Valid types
  are \fInone\fR to not instrument, \fIcall\fR to generate a call to _\|_return_\|_,
  or \fInop5\fR to generate a 5 byte nop.
! .IP "\fB\-mrecord\-return\fR" 4
  .IX Item "-mrecord-return"
  .PD 0
! .IP "\fB\-mno\-record\-return\fR" 4
  .IX Item "-mno-record-return"
  .PD
  Generate a _\|_return_loc section pointing to all return instrumentation code.
! .IP "\fB\-mfentry\-name=\fR\fIname\fR" 4
  .IX Item "-mfentry-name=name"
  Set name of _\|_fentry_\|_ symbol called at function entry for \-pg \-mfentry functions.
! .IP "\fB\-mfentry\-section=\fR\fIname\fR" 4
  .IX Item "-mfentry-section=name"
  Set name of section to record \-mrecord\-mcount calls (default _\|_mcount_loc).
! .IP "\fB\-mskip\-rax\-setup\fR" 4
  .IX Item "-mskip-rax-setup"
  .PD 0
! .IP "\fB\-mno\-skip\-rax\-setup\fR" 4
  .IX Item "-mno-skip-rax-setup"
  .PD
! When generating code for the x86\-64 architecture with \s-1SSE\s0 extensions
! disabled, \fB\-mskip\-rax\-setup\fR can be used to skip setting up \s-1RAX\s0
  register when there are no variable arguments passed in vector registers.
  .Sp
! \&\fBWarning:\fR Since \s-1RAX\s0 register is used to avoid unnecessarily
  saving vector registers on stack when passing variable arguments, the
  impacts of this option are callees may waste some stack space,
! misbehave or jump to a random location.  \s-1GCC 4.4\s0 or newer don't have
! those issues, regardless the \s-1RAX\s0 register value.
! .IP "\fB\-m8bit\-idiv\fR" 4
  .IX Item "-m8bit-idiv"
  .PD 0
! .IP "\fB\-mno\-8bit\-idiv\fR" 4
  .IX Item "-mno-8bit-idiv"
  .PD
  On some processors, like Intel Atom, 8\-bit unsigned integer divide is
  much faster than 32\-bit/64\-bit integer divide.  This option generates a
! run-time check.  If both dividend and divisor are within range of 0
  to 255, 8\-bit unsigned integer divide is used instead of
  32\-bit/64\-bit integer divide.
! .IP "\fB\-mavx256\-split\-unaligned\-load\fR" 4
  .IX Item "-mavx256-split-unaligned-load"
  .PD 0
! .IP "\fB\-mavx256\-split\-unaligned\-store\fR" 4
  .IX Item "-mavx256-split-unaligned-store"
  .PD
! Split 32\-byte \s-1AVX\s0 unaligned load and store.
! .IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP "\fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR" 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP "\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR" 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for global canary or \fBtls\fR for per-thread
! canary in the \s-1TLS\s0 block (the default).  This option has effect only when
  \&\fB\-fstack\-protector\fR or \fB\-fstack\-protector\-all\fR is specified.
  .Sp
  With the latter choice the options
--- 32856,33045 ----
  .RE
  .RS 4
  .RE
! .IP \fB\-mno\-align\-stringops\fR 4
  .IX Item "-mno-align-stringops"
  Do not align the destination of inlined string operations.  This switch reduces
  code size and improves performance in case the destination is already aligned,
! but GCC doesn\*(Aqt know about it.
! .IP \fB\-minline\-all\-stringops\fR 4
  .IX Item "-minline-all-stringops"
! By default GCC inlines string operations only when the destination is 
  known to be aligned to least a 4\-byte boundary.  
  This enables more inlining and increases code
  size, but may improve performance of code that depends on fast
  \&\f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memset\*(C'\fR for short lengths.
  The option enables inline expansion of \f(CW\*(C`strlen\*(C'\fR for all
  pointer alignments.
! .IP \fB\-minline\-stringops\-dynamically\fR 4
  .IX Item "-minline-stringops-dynamically"
! For string operations of unknown size, use run\-time checks with
  inline code for small blocks and a library call for large blocks.
! .IP \fB\-mstringop\-strategy=\fR\fIalg\fR 4
  .IX Item "-mstringop-strategy=alg"
  Override the internal decision heuristic for the particular algorithm to use
  for inlining string operations.  The allowed values for \fIalg\fR are:
  .RS 4
! .IP \fBrep_byte\fR 4
  .IX Item "rep_byte"
  .PD 0
! .IP \fBrep_4byte\fR 4
  .IX Item "rep_4byte"
! .IP \fBrep_8byte\fR 4
  .IX Item "rep_8byte"
  .PD
  Expand using i386 \f(CW\*(C`rep\*(C'\fR prefix of the specified size.
! .IP \fBbyte_loop\fR 4
  .IX Item "byte_loop"
  .PD 0
! .IP \fBloop\fR 4
  .IX Item "loop"
! .IP \fBunrolled_loop\fR 4
  .IX Item "unrolled_loop"
  .PD
  Expand into an inline loop.
! .IP \fBlibcall\fR 4
  .IX Item "libcall"
  Always use a library call.
  .RE
  .RS 4
  .RE
! .IP \fB\-mmemcpy\-strategy=\fR\fIstrategy\fR 4
  .IX Item "-mmemcpy-strategy=strategy"
  Override the internal decision heuristic to decide if \f(CW\*(C`_\|_builtin_memcpy\*(C'\fR
  should be inlined and what inline algorithm to use when the expected size
  of the copy operation is known. \fIstrategy\fR 
! is a comma\-separated list of \fIalg\fR:\fImax_size\fR:\fIdest_align\fR triplets. 
  \&\fIalg\fR is specified in \fB\-mstringop\-strategy\fR, \fImax_size\fR specifies
  the max byte size with which inline algorithm \fIalg\fR is allowed.  For the last
! triplet, the \fImax_size\fR must be \f(CW\-1\fR. The \fImax_size\fR of the triplets
  in the list must be specified in increasing order.  The minimal byte size for 
! \&\fIalg\fR is \f(CW0\fR for the first triplet and \f(CW\*(C`\fR\f(CImax_size\fR\f(CW + 1\*(C'\fR of the 
  preceding range.
! .IP \fB\-mmemset\-strategy=\fR\fIstrategy\fR 4
  .IX Item "-mmemset-strategy=strategy"
  The option is similar to \fB\-mmemcpy\-strategy=\fR except that it is to control
  \&\f(CW\*(C`_\|_builtin_memset\*(C'\fR expansion.
! .IP \fB\-momit\-leaf\-frame\-pointer\fR 4
  .IX Item "-momit-leaf-frame-pointer"
! Don\*(Aqt keep the frame pointer in a register for leaf functions.  This
  avoids the instructions to save, set up, and restore frame pointers and
  makes an extra register available in leaf functions.  The option
  \&\fB\-fomit\-leaf\-frame\-pointer\fR removes the frame pointer for leaf functions,
  which might make debugging harder.
! .IP \fB\-mtls\-direct\-seg\-refs\fR 4
  .IX Item "-mtls-direct-seg-refs"
  .PD 0
! .IP \fB\-mno\-tls\-direct\-seg\-refs\fR 4
  .IX Item "-mno-tls-direct-seg-refs"
  .PD
! Controls whether TLS variables may be accessed with offsets from the
! TLS segment register (\f(CW%gs\fR for 32\-bit, \f(CW%fs\fR for 64\-bit),
  or whether the thread base pointer must be added.  Whether or not this
  is valid depends on the operating system, and whether it maps the
! segment to cover the entire TLS area.
  .Sp
! For systems that use the GNU C Library, the default is on.
! .IP \fB\-msse2avx\fR 4
  .IX Item "-msse2avx"
  .PD 0
! .IP \fB\-mno\-sse2avx\fR 4
  .IX Item "-mno-sse2avx"
  .PD
! Specify that the assembler should encode SSE instructions with VEX
  prefix.  The option \fB\-mavx\fR turns this on by default.
! .IP \fB\-mfentry\fR 4
  .IX Item "-mfentry"
  .PD 0
! .IP \fB\-mno\-fentry\fR 4
  .IX Item "-mno-fentry"
  .PD
  If profiling is active (\fB\-pg\fR), put the profiling
  counter call before the prologue.
  Note: On x86 architectures the attribute \f(CW\*(C`ms_hook_prologue\*(C'\fR
! isn\*(Aqt possible at the moment for \fB\-mfentry\fR and \fB\-pg\fR.
! .IP \fB\-mrecord\-mcount\fR 4
  .IX Item "-mrecord-mcount"
  .PD 0
! .IP \fB\-mno\-record\-mcount\fR 4
  .IX Item "-mno-record-mcount"
  .PD
  If profiling is active (\fB\-pg\fR), generate a _\|_mcount_loc section
  that contains pointers to each profiling call. This is useful for
  automatically patching and out calls.
! .IP \fB\-mnop\-mcount\fR 4
  .IX Item "-mnop-mcount"
  .PD 0
! .IP \fB\-mno\-nop\-mcount\fR 4
  .IX Item "-mno-nop-mcount"
  .PD
  If profiling is active (\fB\-pg\fR), generate the calls to
  the profiling functions as NOPs. This is useful when they
  should be patched in later dynamically. This is likely only
  useful together with \fB\-mrecord\-mcount\fR.
! .IP \fB\-minstrument\-return=\fR\fItype\fR 4
  .IX Item "-minstrument-return=type"
  Instrument function exit in \-pg \-mfentry instrumented functions with
  call to specified function. This only instruments true returns ending
  with ret, but not sibling calls ending with jump. Valid types
  are \fInone\fR to not instrument, \fIcall\fR to generate a call to _\|_return_\|_,
  or \fInop5\fR to generate a 5 byte nop.
! .IP \fB\-mrecord\-return\fR 4
  .IX Item "-mrecord-return"
  .PD 0
! .IP \fB\-mno\-record\-return\fR 4
  .IX Item "-mno-record-return"
  .PD
  Generate a _\|_return_loc section pointing to all return instrumentation code.
! .IP \fB\-mfentry\-name=\fR\fIname\fR 4
  .IX Item "-mfentry-name=name"
  Set name of _\|_fentry_\|_ symbol called at function entry for \-pg \-mfentry functions.
! .IP \fB\-mfentry\-section=\fR\fIname\fR 4
  .IX Item "-mfentry-section=name"
  Set name of section to record \-mrecord\-mcount calls (default _\|_mcount_loc).
! .IP \fB\-mskip\-rax\-setup\fR 4
  .IX Item "-mskip-rax-setup"
  .PD 0
! .IP \fB\-mno\-skip\-rax\-setup\fR 4
  .IX Item "-mno-skip-rax-setup"
  .PD
! When generating code for the x86\-64 architecture with SSE extensions
! disabled, \fB\-mskip\-rax\-setup\fR can be used to skip setting up RAX
  register when there are no variable arguments passed in vector registers.
  .Sp
! \&\fBWarning:\fR Since RAX register is used to avoid unnecessarily
  saving vector registers on stack when passing variable arguments, the
  impacts of this option are callees may waste some stack space,
! misbehave or jump to a random location.  GCC 4.4 or newer don\*(Aqt have
! those issues, regardless the RAX register value.
! .IP \fB\-m8bit\-idiv\fR 4
  .IX Item "-m8bit-idiv"
  .PD 0
! .IP \fB\-mno\-8bit\-idiv\fR 4
  .IX Item "-mno-8bit-idiv"
  .PD
  On some processors, like Intel Atom, 8\-bit unsigned integer divide is
  much faster than 32\-bit/64\-bit integer divide.  This option generates a
! run\-time check.  If both dividend and divisor are within range of 0
  to 255, 8\-bit unsigned integer divide is used instead of
  32\-bit/64\-bit integer divide.
! .IP \fB\-mavx256\-split\-unaligned\-load\fR 4
  .IX Item "-mavx256-split-unaligned-load"
  .PD 0
! .IP \fB\-mavx256\-split\-unaligned\-store\fR 4
  .IX Item "-mavx256-split-unaligned-store"
  .PD
! Split 32\-byte AVX unaligned load and store.
! .IP \fB\-mstack\-protector\-guard=\fR\fIguard\fR 4
  .IX Item "-mstack-protector-guard=guard"
  .PD 0
! .IP \fB\-mstack\-protector\-guard\-reg=\fR\fIreg\fR 4
  .IX Item "-mstack-protector-guard-reg=reg"
! .IP \fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR 4
  .IX Item "-mstack-protector-guard-offset=offset"
  .PD
  Generate stack protection code using canary at \fIguard\fR.  Supported
! locations are \fBglobal\fR for global canary or \fBtls\fR for per\-thread
! canary in the TLS block (the default).  This option has effect only when
  \&\fB\-fstack\-protector\fR or \fB\-fstack\-protector\-all\fR is specified.
  .Sp
  With the latter choice the options
*************** With the latter choice the options
*** 33116,33141 ****
  \&\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR furthermore specify
  which segment register (\f(CW%fs\fR or \f(CW%gs\fR) to use as base register
  for reading the canary, and from what offset from that base register.
! The default for those is as specified in the relevant \s-1ABI.\s0
! .IP "\fB\-mgeneral\-regs\-only\fR" 4
  .IX Item "-mgeneral-regs-only"
! Generate code that uses only the general-purpose registers.  This
! prevents the compiler from using floating-point, vector, mask and bound
  registers.
! .IP "\fB\-mrelax\-cmpxchg\-loop\fR" 4
  .IX Item "-mrelax-cmpxchg-loop"
! When emitting a compare-and-swap loop for \fB_\|_sync Builtins\fR
  and \fB_\|_atomic Builtins\fR lacking a native instruction, optimize
  for the highly contended case by issuing an atomic load before the
  \&\f(CW\*(C`CMPXCHG\*(C'\fR instruction, and using the \f(CW\*(C`PAUSE\*(C'\fR instruction
! to save \s-1CPU\s0 power when restarting the loop.
! .IP "\fB\-mindirect\-branch=\fR\fIchoice\fR" 4
  .IX Item "-mindirect-branch=choice"
  Convert indirect call and jump with \fIchoice\fR.  The default is
  \&\fBkeep\fR, which keeps indirect call and jump unmodified.
  \&\fBthunk\fR converts indirect call and jump to call and return thunk.
! \&\fBthunk-inline\fR converts indirect call and jump to inlined call
! and return thunk.  \fBthunk-extern\fR converts indirect call and jump
  to external call and return thunk provided in a separate object file.
  You can control this behavior for a specific function by using the
  function attribute \f(CW\*(C`indirect_branch\*(C'\fR.
--- 33047,33072 ----
  \&\fB\-mstack\-protector\-guard\-offset=\fR\fIoffset\fR furthermore specify
  which segment register (\f(CW%fs\fR or \f(CW%gs\fR) to use as base register
  for reading the canary, and from what offset from that base register.
! The default for those is as specified in the relevant ABI.
! .IP \fB\-mgeneral\-regs\-only\fR 4
  .IX Item "-mgeneral-regs-only"
! Generate code that uses only the general\-purpose registers.  This
! prevents the compiler from using floating\-point, vector, mask and bound
  registers.
! .IP \fB\-mrelax\-cmpxchg\-loop\fR 4
  .IX Item "-mrelax-cmpxchg-loop"
! When emitting a compare\-and\-swap loop for \fB_\|_sync Builtins\fR
  and \fB_\|_atomic Builtins\fR lacking a native instruction, optimize
  for the highly contended case by issuing an atomic load before the
  \&\f(CW\*(C`CMPXCHG\*(C'\fR instruction, and using the \f(CW\*(C`PAUSE\*(C'\fR instruction
! to save CPU power when restarting the loop.
! .IP \fB\-mindirect\-branch=\fR\fIchoice\fR 4
  .IX Item "-mindirect-branch=choice"
  Convert indirect call and jump with \fIchoice\fR.  The default is
  \&\fBkeep\fR, which keeps indirect call and jump unmodified.
  \&\fBthunk\fR converts indirect call and jump to call and return thunk.
! \&\fBthunk\-inline\fR converts indirect call and jump to inlined call
! and return thunk.  \fBthunk\-extern\fR converts indirect call and jump
  to external call and return thunk provided in a separate object file.
  You can control this behavior for a specific function by using the
  function attribute \f(CW\*(C`indirect_branch\*(C'\fR.
*************** not be reachable in the large code model
*** 33147,33200 ****
  .Sp
  Note that \fB\-mindirect\-branch=thunk\-extern\fR is compatible with
  \&\fB\-fcf\-protection=branch\fR since the external thunk can be made
! to enable control-flow check.
! .IP "\fB\-mfunction\-return=\fR\fIchoice\fR" 4
  .IX Item "-mfunction-return=choice"
  Convert function return with \fIchoice\fR.  The default is \fBkeep\fR,
  which keeps function return unmodified.  \fBthunk\fR converts function
! return to call and return thunk.  \fBthunk-inline\fR converts function
! return to inlined call and return thunk.  \fBthunk-extern\fR converts
  function return to external call and return thunk provided in a separate
  object file.  You can control this behavior for a specific function by
  using the function attribute \f(CW\*(C`function_return\*(C'\fR.
  .Sp
  Note that \fB\-mindirect\-return=thunk\-extern\fR is compatible with
  \&\fB\-fcf\-protection=branch\fR since the external thunk can be made
! to enable control-flow check.
  .Sp
  Note that \fB\-mcmodel=large\fR is incompatible with
  \&\fB\-mfunction\-return=thunk\fR and
  \&\fB\-mfunction\-return=thunk\-extern\fR since the thunk function may
  not be reachable in the large code model.
! .IP "\fB\-mindirect\-branch\-register\fR" 4
  .IX Item "-mindirect-branch-register"
  Force indirect call and jump via register.
! .IP "\fB\-mharden\-sls=\fR\fIchoice\fR" 4
  .IX Item "-mharden-sls=choice"
! Generate code to mitigate against straight line speculation (\s-1SLS\s0) with
! \&\fIchoice\fR.  The default is \fBnone\fR which disables all \s-1SLS\s0
! hardening.  \fBreturn\fR enables \s-1SLS\s0 hardening for function returns.
! \&\fBindirect-jmp\fR enables \s-1SLS\s0 hardening for indirect jumps.
! \&\fBall\fR enables all \s-1SLS\s0 hardening.
! .IP "\fB\-mindirect\-branch\-cs\-prefix\fR" 4
  .IX Item "-mindirect-branch-cs-prefix"
! Add \s-1CS\s0 prefix to call and jmp to indirect thunk with branch target in
  r8\-r15 registers so that the call and jmp instruction length is 6 bytes
  to allow them to be replaced with \fBlfence; call *%r8\-r15\fR or
! \&\fBlfence; jmp *%r8\-r15\fR at run-time.
  .PP
  These \fB\-m\fR switches are supported in addition to the above
  on x86\-64 processors in 64\-bit environments.
! .IP "\fB\-m32\fR" 4
  .IX Item "-m32"
  .PD 0
! .IP "\fB\-m64\fR" 4
  .IX Item "-m64"
! .IP "\fB\-mx32\fR" 4
  .IX Item "-mx32"
! .IP "\fB\-m16\fR" 4
  .IX Item "-m16"
! .IP "\fB\-miamcu\fR" 4
  .IX Item "-miamcu"
  .PD
  Generate code for a 16\-bit, 32\-bit or 64\-bit environment.
--- 33078,33131 ----
  .Sp
  Note that \fB\-mindirect\-branch=thunk\-extern\fR is compatible with
  \&\fB\-fcf\-protection=branch\fR since the external thunk can be made
! to enable control\-flow check.
! .IP \fB\-mfunction\-return=\fR\fIchoice\fR 4
  .IX Item "-mfunction-return=choice"
  Convert function return with \fIchoice\fR.  The default is \fBkeep\fR,
  which keeps function return unmodified.  \fBthunk\fR converts function
! return to call and return thunk.  \fBthunk\-inline\fR converts function
! return to inlined call and return thunk.  \fBthunk\-extern\fR converts
  function return to external call and return thunk provided in a separate
  object file.  You can control this behavior for a specific function by
  using the function attribute \f(CW\*(C`function_return\*(C'\fR.
  .Sp
  Note that \fB\-mindirect\-return=thunk\-extern\fR is compatible with
  \&\fB\-fcf\-protection=branch\fR since the external thunk can be made
! to enable control\-flow check.
  .Sp
  Note that \fB\-mcmodel=large\fR is incompatible with
  \&\fB\-mfunction\-return=thunk\fR and
  \&\fB\-mfunction\-return=thunk\-extern\fR since the thunk function may
  not be reachable in the large code model.
! .IP \fB\-mindirect\-branch\-register\fR 4
  .IX Item "-mindirect-branch-register"
  Force indirect call and jump via register.
! .IP \fB\-mharden\-sls=\fR\fIchoice\fR 4
  .IX Item "-mharden-sls=choice"
! Generate code to mitigate against straight line speculation (SLS) with
! \&\fIchoice\fR.  The default is \fBnone\fR which disables all SLS
! hardening.  \fBreturn\fR enables SLS hardening for function returns.
! \&\fBindirect\-jmp\fR enables SLS hardening for indirect jumps.
! \&\fBall\fR enables all SLS hardening.
! .IP \fB\-mindirect\-branch\-cs\-prefix\fR 4
  .IX Item "-mindirect-branch-cs-prefix"
! Add CS prefix to call and jmp to indirect thunk with branch target in
  r8\-r15 registers so that the call and jmp instruction length is 6 bytes
  to allow them to be replaced with \fBlfence; call *%r8\-r15\fR or
! \&\fBlfence; jmp *%r8\-r15\fR at run\-time.
  .PP
  These \fB\-m\fR switches are supported in addition to the above
  on x86\-64 processors in 64\-bit environments.
! .IP \fB\-m32\fR 4
  .IX Item "-m32"
  .PD 0
! .IP \fB\-m64\fR 4
  .IX Item "-m64"
! .IP \fB\-mx32\fR 4
  .IX Item "-mx32"
! .IP \fB\-m16\fR 4
  .IX Item "-m16"
! .IP \fB\-miamcu\fR 4
  .IX Item "-miamcu"
  .PD
  Generate code for a 16\-bit, 32\-bit or 64\-bit environment.
*************** The \fB\-m16\fR option is the same as \f
*** 33215,33272 ****
  it outputs the \f(CW\*(C`.code16gcc\*(C'\fR assembly directive at the beginning of
  the assembly output so that the binary can run in 16\-bit mode.
  .Sp
! The \fB\-miamcu\fR option generates code which conforms to Intel \s-1MCU\s0
  psABI.  It requires the \fB\-m32\fR option to be turned on.
! .IP "\fB\-mno\-red\-zone\fR" 4
  .IX Item "-mno-red-zone"
! Do not use a so-called \*(L"red zone\*(R" for x86\-64 code.  The red zone is mandated
! by the x86\-64 \s-1ABI\s0; it is a 128\-byte area beyond the location of the
  stack pointer that is not modified by signal or interrupt handlers
  and therefore can be used for temporary data without adjusting the stack
  pointer.  The flag \fB\-mno\-red\-zone\fR disables this red zone.
! .IP "\fB\-mcmodel=small\fR" 4
  .IX Item "-mcmodel=small"
  Generate code for the small code model: the program and its symbols must
! be linked in the lower 2 \s-1GB\s0 of the address space.  Pointers are 64 bits.
  Programs can be statically or dynamically linked.  This is the default
  code model.
! .IP "\fB\-mcmodel=kernel\fR" 4
  .IX Item "-mcmodel=kernel"
  Generate code for the kernel code model.  The kernel runs in the
! negative 2 \s-1GB\s0 of the address space.
  This model has to be used for Linux kernel code.
! .IP "\fB\-mcmodel=medium\fR" 4
  .IX Item "-mcmodel=medium"
  Generate code for the medium model: the program is linked in the lower 2
! \&\s-1GB\s0 of the address space.  Small symbols are also placed there.  Symbols
  with sizes larger than \fB\-mlarge\-data\-threshold\fR are put into
! large data or \s-1BSS\s0 sections and can be located above 2GB.  Programs can
  be statically or dynamically linked.
! .IP "\fB\-mcmodel=large\fR" 4
  .IX Item "-mcmodel=large"
  Generate code for the large model.  This model makes no assumptions
  about addresses and sizes of sections.
! .IP "\fB\-maddress\-mode=long\fR" 4
  .IX Item "-maddress-mode=long"
  Generate code for long address mode.  This is only supported for 64\-bit
  and x32 environments.  It is the default address mode for 64\-bit
  environments.
! .IP "\fB\-maddress\-mode=short\fR" 4
  .IX Item "-maddress-mode=short"
  Generate code for short address mode.  This is only supported for 32\-bit
  and x32 environments.  It is the default address mode for 32\-bit and
  x32 environments.
! .IP "\fB\-mneeded\fR" 4
  .IX Item "-mneeded"
  .PD 0
! .IP "\fB\-mno\-needed\fR" 4
  .IX Item "-mno-needed"
  .PD
! Emit \s-1GNU_PROPERTY_X86_ISA_1_NEEDED GNU\s0 property for Linux target to
! indicate the micro-architecture \s-1ISA\s0 level required to execute the binary.
! .IP "\fB\-mno\-direct\-extern\-access\fR" 4
  .IX Item "-mno-direct-extern-access"
! Without \fB\-fpic\fR nor \fB\-fPIC\fR, always use the \s-1GOT\s0 pointer
  to access external symbols.  With \fB\-fpic\fR or \fB\-fPIC\fR,
  treat access to protected symbols as local symbols.  The default is
  \&\fB\-mdirect\-extern\-access\fR.
--- 33146,33203 ----
  it outputs the \f(CW\*(C`.code16gcc\*(C'\fR assembly directive at the beginning of
  the assembly output so that the binary can run in 16\-bit mode.
  .Sp
! The \fB\-miamcu\fR option generates code which conforms to Intel MCU
  psABI.  It requires the \fB\-m32\fR option to be turned on.
! .IP \fB\-mno\-red\-zone\fR 4
  .IX Item "-mno-red-zone"
! Do not use a so\-called "red zone" for x86\-64 code.  The red zone is mandated
! by the x86\-64 ABI; it is a 128\-byte area beyond the location of the
  stack pointer that is not modified by signal or interrupt handlers
  and therefore can be used for temporary data without adjusting the stack
  pointer.  The flag \fB\-mno\-red\-zone\fR disables this red zone.
! .IP \fB\-mcmodel=small\fR 4
  .IX Item "-mcmodel=small"
  Generate code for the small code model: the program and its symbols must
! be linked in the lower 2 GB of the address space.  Pointers are 64 bits.
  Programs can be statically or dynamically linked.  This is the default
  code model.
! .IP \fB\-mcmodel=kernel\fR 4
  .IX Item "-mcmodel=kernel"
  Generate code for the kernel code model.  The kernel runs in the
! negative 2 GB of the address space.
  This model has to be used for Linux kernel code.
! .IP \fB\-mcmodel=medium\fR 4
  .IX Item "-mcmodel=medium"
  Generate code for the medium model: the program is linked in the lower 2
! GB of the address space.  Small symbols are also placed there.  Symbols
  with sizes larger than \fB\-mlarge\-data\-threshold\fR are put into
! large data or BSS sections and can be located above 2GB.  Programs can
  be statically or dynamically linked.
! .IP \fB\-mcmodel=large\fR 4
  .IX Item "-mcmodel=large"
  Generate code for the large model.  This model makes no assumptions
  about addresses and sizes of sections.
! .IP \fB\-maddress\-mode=long\fR 4
  .IX Item "-maddress-mode=long"
  Generate code for long address mode.  This is only supported for 64\-bit
  and x32 environments.  It is the default address mode for 64\-bit
  environments.
! .IP \fB\-maddress\-mode=short\fR 4
  .IX Item "-maddress-mode=short"
  Generate code for short address mode.  This is only supported for 32\-bit
  and x32 environments.  It is the default address mode for 32\-bit and
  x32 environments.
! .IP \fB\-mneeded\fR 4
  .IX Item "-mneeded"
  .PD 0
! .IP \fB\-mno\-needed\fR 4
  .IX Item "-mno-needed"
  .PD
! Emit GNU_PROPERTY_X86_ISA_1_NEEDED GNU property for Linux target to
! indicate the micro\-architecture ISA level required to execute the binary.
! .IP \fB\-mno\-direct\-extern\-access\fR 4
  .IX Item "-mno-direct-extern-access"
! Without \fB\-fpic\fR nor \fB\-fPIC\fR, always use the GOT pointer
  to access external symbols.  With \fB\-fpic\fR or \fB\-fPIC\fR,
  treat access to protected symbols as local symbols.  The default is
  \&\fB\-mdirect\-extern\-access\fR.
*************** treat access to protected symbols as loc
*** 33275,33289 ****
  \&\fB\-mno\-direct\-extern\-access\fR and executable compiled with
  \&\fB\-mdirect\-extern\-access\fR may not be binary compatible if
  protected symbols are used in shared libraries and executable.
! .IP "\fB\-munroll\-only\-small\-loops\fR" 4
  .IX Item "-munroll-only-small-loops"
  Controls conservative small loop unrolling. It is default enabled by
  O2, and unrolls loop with less than 4 insns by 1 time. Explicit
  \&\-f[no\-]unroll\-[all\-]loops would disable this flag to avoid any
  unintended unrolling behavior that user does not want.
! .IP "\fB\-mlam=\fR\fIchoice\fR" 4
  .IX Item "-mlam=choice"
! \&\s-1LAM\s0(linear\-address masking) allows special bits in the pointer to be used
  for metadata. The default is \fBnone\fR. With \fBu48\fR, pointer bits in
  positions 62:48 can be used for metadata; With \fBu57\fR, pointer bits in
  positions 62:57 can be used for metadata.
--- 33206,33220 ----
  \&\fB\-mno\-direct\-extern\-access\fR and executable compiled with
  \&\fB\-mdirect\-extern\-access\fR may not be binary compatible if
  protected symbols are used in shared libraries and executable.
! .IP \fB\-munroll\-only\-small\-loops\fR 4
  .IX Item "-munroll-only-small-loops"
  Controls conservative small loop unrolling. It is default enabled by
  O2, and unrolls loop with less than 4 insns by 1 time. Explicit
  \&\-f[no\-]unroll\-[all\-]loops would disable this flag to avoid any
  unintended unrolling behavior that user does not want.
! .IP \fB\-mlam=\fR\fIchoice\fR 4
  .IX Item "-mlam=choice"
! LAM(linear\-address masking) allows special bits in the pointer to be used
  for metadata. The default is \fBnone\fR. With \fBu48\fR, pointer bits in
  positions 62:48 can be used for metadata; With \fBu57\fR, pointer bits in
  positions 62:57 can be used for metadata.
*************** positions 62:57 can be used for metadata
*** 33292,33356 ****
  .IX Subsection "x86 Windows Options"
  .PP
  These additional options are available for Microsoft Windows targets:
! .IP "\fB\-mconsole\fR" 4
  .IX Item "-mconsole"
  This option
  specifies that a console application is to be generated, by
! instructing the linker to set the \s-1PE\s0 header subsystem type
  required for console applications.
  This option is available for Cygwin and MinGW targets and is
  enabled by default on those targets.
! .IP "\fB\-mdll\fR" 4
  .IX Item "-mdll"
  This option is available for Cygwin and MinGW targets.  It
  specifies that a DLL\-\-\-a dynamic link library\-\-\-is to be
  generated, enabling the selection of the required runtime
  startup object and entry point.
! .IP "\fB\-mnop\-fun\-dllimport\fR" 4
  .IX Item "-mnop-fun-dllimport"
  This option is available for Cygwin and MinGW targets.  It
  specifies that the \f(CW\*(C`dllimport\*(C'\fR attribute should be ignored.
! .IP "\fB\-mthreads\fR" 4
  .IX Item "-mthreads"
  This option is available for MinGW targets. It specifies
! that MinGW-specific thread support is to be used.
! .IP "\fB\-municode\fR" 4
  .IX Item "-municode"
  This option is available for MinGW\-w64 targets.  It causes
  the \f(CW\*(C`UNICODE\*(C'\fR preprocessor macro to be predefined, and
! chooses Unicode-capable runtime startup code.
! .IP "\fB\-mwin32\fR" 4
  .IX Item "-mwin32"
  This option is available for Cygwin and MinGW targets.  It
  specifies that the typical Microsoft Windows predefined macros are to
! be set in the pre-processor, but does not influence the choice
  of runtime library/startup code.
! .IP "\fB\-mwindows\fR" 4
  .IX Item "-mwindows"
  This option is available for Cygwin and MinGW targets.  It
! specifies that a \s-1GUI\s0 application is to be generated by
! instructing the linker to set the \s-1PE\s0 header subsystem type
  appropriately.
! .IP "\fB\-fno\-set\-stack\-executable\fR" 4
  .IX Item "-fno-set-stack-executable"
  This option is available for MinGW targets. It specifies that
! the executable flag for the stack used by nested functions isn't
  set. This is necessary for binaries running in kernel mode of
! Microsoft Windows, as there the User32 \s-1API,\s0 which is used to set executable
! privileges, isn't available.
! .IP "\fB\-fwritable\-relocated\-rdata\fR" 4
  .IX Item "-fwritable-relocated-rdata"
  This option is available for MinGW and Cygwin targets.  It specifies
! that relocated-data in read-only section is put into the \f(CW\*(C`.data\*(C'\fR
  section.  This is a necessary for older runtimes not supporting
! modification of \f(CW\*(C`.rdata\*(C'\fR sections for pseudo-relocation.
! .IP "\fB\-mpe\-aligned\-commons\fR" 4
  .IX Item "-mpe-aligned-commons"
  This option is available for Cygwin and MinGW targets.  It
! specifies that the \s-1GNU\s0 extension to the \s-1PE\s0 file format that
! permits the correct alignment of \s-1COMMON\s0 variables should be
  used when generating code.  It is enabled by default if
! \&\s-1GCC\s0 detects that the target assembler found during configuration
  supports the feature.
  .PP
  See also under \fBx86 Options\fR for standard options.
--- 33223,33287 ----
  .IX Subsection "x86 Windows Options"
  .PP
  These additional options are available for Microsoft Windows targets:
! .IP \fB\-mconsole\fR 4
  .IX Item "-mconsole"
  This option
  specifies that a console application is to be generated, by
! instructing the linker to set the PE header subsystem type
  required for console applications.
  This option is available for Cygwin and MinGW targets and is
  enabled by default on those targets.
! .IP \fB\-mdll\fR 4
  .IX Item "-mdll"
  This option is available for Cygwin and MinGW targets.  It
  specifies that a DLL\-\-\-a dynamic link library\-\-\-is to be
  generated, enabling the selection of the required runtime
  startup object and entry point.
! .IP \fB\-mnop\-fun\-dllimport\fR 4
  .IX Item "-mnop-fun-dllimport"
  This option is available for Cygwin and MinGW targets.  It
  specifies that the \f(CW\*(C`dllimport\*(C'\fR attribute should be ignored.
! .IP \fB\-mthreads\fR 4
  .IX Item "-mthreads"
  This option is available for MinGW targets. It specifies
! that MinGW\-specific thread support is to be used.
! .IP \fB\-municode\fR 4
  .IX Item "-municode"
  This option is available for MinGW\-w64 targets.  It causes
  the \f(CW\*(C`UNICODE\*(C'\fR preprocessor macro to be predefined, and
! chooses Unicode\-capable runtime startup code.
! .IP \fB\-mwin32\fR 4
  .IX Item "-mwin32"
  This option is available for Cygwin and MinGW targets.  It
  specifies that the typical Microsoft Windows predefined macros are to
! be set in the pre\-processor, but does not influence the choice
  of runtime library/startup code.
! .IP \fB\-mwindows\fR 4
  .IX Item "-mwindows"
  This option is available for Cygwin and MinGW targets.  It
! specifies that a GUI application is to be generated by
! instructing the linker to set the PE header subsystem type
  appropriately.
! .IP \fB\-fno\-set\-stack\-executable\fR 4
  .IX Item "-fno-set-stack-executable"
  This option is available for MinGW targets. It specifies that
! the executable flag for the stack used by nested functions isn\*(Aqt
  set. This is necessary for binaries running in kernel mode of
! Microsoft Windows, as there the User32 API, which is used to set executable
! privileges, isn\*(Aqt available.
! .IP \fB\-fwritable\-relocated\-rdata\fR 4
  .IX Item "-fwritable-relocated-rdata"
  This option is available for MinGW and Cygwin targets.  It specifies
! that relocated\-data in read\-only section is put into the \f(CW\*(C`.data\*(C'\fR
  section.  This is a necessary for older runtimes not supporting
! modification of \f(CW\*(C`.rdata\*(C'\fR sections for pseudo\-relocation.
! .IP \fB\-mpe\-aligned\-commons\fR 4
  .IX Item "-mpe-aligned-commons"
  This option is available for Cygwin and MinGW targets.  It
! specifies that the GNU extension to the PE file format that
! permits the correct alignment of COMMON variables should be
  used when generating code.  It is enabled by default if
! GCC detects that the target assembler found during configuration
  supports the feature.
  .PP
  See also under \fBx86 Options\fR for standard options.
*************** See also under \fBx86 Options\fR for sta
*** 33359,33365 ****
  .IX Subsection "Xstormy16 Options"
  .PP
  These options are defined for Xstormy16:
! .IP "\fB\-msim\fR" 4
  .IX Item "-msim"
  Choose startup files and linker script suitable for the simulator.
  .PP
--- 33290,33296 ----
  .IX Subsection "Xstormy16 Options"
  .PP
  These options are defined for Xstormy16:
! .IP \fB\-msim\fR 4
  .IX Item "-msim"
  Choose startup files and linker script suitable for the simulator.
  .PP
*************** Choose startup files and linker script s
*** 33367,33376 ****
  .IX Subsection "Xtensa Options"
  .PP
  These options are supported for Xtensa targets:
! .IP "\fB\-mconst16\fR" 4
  .IX Item "-mconst16"
  .PD 0
! .IP "\fB\-mno\-const16\fR" 4
  .IX Item "-mno-const16"
  .PD
  Enable or disable use of \f(CW\*(C`CONST16\*(C'\fR instructions for loading
--- 33298,33307 ----
  .IX Subsection "Xtensa Options"
  .PP
  These options are supported for Xtensa targets:
! .IP \fB\-mconst16\fR 4
  .IX Item "-mconst16"
  .PD 0
! .IP \fB\-mno\-const16\fR 4
  .IX Item "-mno-const16"
  .PD
  Enable or disable use of \f(CW\*(C`CONST16\*(C'\fR instructions for loading
*************** standard option from Tensilica.  When en
*** 33379,33436 ****
  instructions are always used in place of the standard \f(CW\*(C`L32R\*(C'\fR
  instructions.  The use of \f(CW\*(C`CONST16\*(C'\fR is enabled by default only if
  the \f(CW\*(C`L32R\*(C'\fR instruction is not available.
! .IP "\fB\-mfused\-madd\fR" 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP "\fB\-mno\-fused\-madd\fR" 4
  .IX Item "-mno-fused-madd"
  .PD
  Enable or disable use of fused multiply/add and multiply/subtract
! instructions in the floating-point option.  This has no effect if the
! floating-point option is not also enabled.  Disabling fused multiply/add
  and multiply/subtract instructions forces the compiler to use separate
  instructions for the multiply and add/subtract operations.  This may be
! desirable in some cases where strict \s-1IEEE\s0 754\-compliant results are
  required: the fused multiply add/subtract instructions do not round the
  intermediate result, thereby producing results with \fImore\fR bits of
! precision than specified by the \s-1IEEE\s0 standard.  Disabling fused multiply
  add/subtract instructions also ensures that the program output is not
! sensitive to the compiler's ability to combine multiply and add/subtract
  operations.
! .IP "\fB\-mserialize\-volatile\fR" 4
  .IX Item "-mserialize-volatile"
  .PD 0
! .IP "\fB\-mno\-serialize\-volatile\fR" 4
  .IX Item "-mno-serialize-volatile"
  .PD
! When this option is enabled, \s-1GCC\s0 inserts \f(CW\*(C`MEMW\*(C'\fR instructions before
  \&\f(CW\*(C`volatile\*(C'\fR memory references to guarantee sequential consistency.
  The default is \fB\-mserialize\-volatile\fR.  Use
  \&\fB\-mno\-serialize\-volatile\fR to omit the \f(CW\*(C`MEMW\*(C'\fR instructions.
! .IP "\fB\-mforce\-no\-pic\fR" 4
  .IX Item "-mforce-no-pic"
! For targets, like GNU/Linux, where all user-mode Xtensa code must be
! position-independent code (\s-1PIC\s0), this option disables \s-1PIC\s0 for compiling
  kernel code.
! .IP "\fB\-mtext\-section\-literals\fR" 4
  .IX Item "-mtext-section-literals"
  .PD 0
! .IP "\fB\-mno\-text\-section\-literals\fR" 4
  .IX Item "-mno-text-section-literals"
  .PD
  These options control the treatment of literal pools.  The default is
  \&\fB\-mno\-text\-section\-literals\fR, which places literals in a separate
  section in the output file.  This allows the literal pool to be placed
! in a data \s-1RAM/ROM,\s0 and it also allows the linker to combine literal
  pools from separate object files to remove redundant literals and
  improve code size.  With \fB\-mtext\-section\-literals\fR, the literals
  are interspersed in the text section in order to keep them as close as
  possible to their references.  This may be necessary for large assembly
  files.  Literals for each function are placed right before that function.
! .IP "\fB\-mauto\-litpools\fR" 4
  .IX Item "-mauto-litpools"
  .PD 0
! .IP "\fB\-mno\-auto\-litpools\fR" 4
  .IX Item "-mno-auto-litpools"
  .PD
  These options control the treatment of literal pools.  The default is
--- 33310,33367 ----
  instructions are always used in place of the standard \f(CW\*(C`L32R\*(C'\fR
  instructions.  The use of \f(CW\*(C`CONST16\*(C'\fR is enabled by default only if
  the \f(CW\*(C`L32R\*(C'\fR instruction is not available.
! .IP \fB\-mfused\-madd\fR 4
  .IX Item "-mfused-madd"
  .PD 0
! .IP \fB\-mno\-fused\-madd\fR 4
  .IX Item "-mno-fused-madd"
  .PD
  Enable or disable use of fused multiply/add and multiply/subtract
! instructions in the floating\-point option.  This has no effect if the
! floating\-point option is not also enabled.  Disabling fused multiply/add
  and multiply/subtract instructions forces the compiler to use separate
  instructions for the multiply and add/subtract operations.  This may be
! desirable in some cases where strict IEEE 754\-compliant results are
  required: the fused multiply add/subtract instructions do not round the
  intermediate result, thereby producing results with \fImore\fR bits of
! precision than specified by the IEEE standard.  Disabling fused multiply
  add/subtract instructions also ensures that the program output is not
! sensitive to the compiler\*(Aqs ability to combine multiply and add/subtract
  operations.
! .IP \fB\-mserialize\-volatile\fR 4
  .IX Item "-mserialize-volatile"
  .PD 0
! .IP \fB\-mno\-serialize\-volatile\fR 4
  .IX Item "-mno-serialize-volatile"
  .PD
! When this option is enabled, GCC inserts \f(CW\*(C`MEMW\*(C'\fR instructions before
  \&\f(CW\*(C`volatile\*(C'\fR memory references to guarantee sequential consistency.
  The default is \fB\-mserialize\-volatile\fR.  Use
  \&\fB\-mno\-serialize\-volatile\fR to omit the \f(CW\*(C`MEMW\*(C'\fR instructions.
! .IP \fB\-mforce\-no\-pic\fR 4
  .IX Item "-mforce-no-pic"
! For targets, like GNU/Linux, where all user\-mode Xtensa code must be
! position\-independent code (PIC), this option disables PIC for compiling
  kernel code.
! .IP \fB\-mtext\-section\-literals\fR 4
  .IX Item "-mtext-section-literals"
  .PD 0
! .IP \fB\-mno\-text\-section\-literals\fR 4
  .IX Item "-mno-text-section-literals"
  .PD
  These options control the treatment of literal pools.  The default is
  \&\fB\-mno\-text\-section\-literals\fR, which places literals in a separate
  section in the output file.  This allows the literal pool to be placed
! in a data 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 \fB\-mtext\-section\-literals\fR, the literals
  are interspersed in the text section in order to keep them as close as
  possible to their references.  This may be necessary for large assembly
  files.  Literals for each function are placed right before that function.
! .IP \fB\-mauto\-litpools\fR 4
  .IX Item "-mauto-litpools"
  .PD 0
! .IP \fB\-mno\-auto\-litpools\fR 4
  .IX Item "-mno-auto-litpools"
  .PD
  These options control the treatment of literal pools.  The default is
*************** do relaxation and place literals as nece
*** 33444,33472 ****
  assembler to create several literal pools per function and assemble
  very big functions, which may not be possible with
  \&\fB\-mtext\-section\-literals\fR.
! .IP "\fB\-mtarget\-align\fR" 4
  .IX Item "-mtarget-align"
  .PD 0
! .IP "\fB\-mno\-target\-align\fR" 4
  .IX Item "-mno-target-align"
  .PD
! When this option is enabled, \s-1GCC\s0 instructs the assembler to
  automatically align instructions to reduce branch penalties at the
  expense of some code density.  The assembler attempts to widen density
  instructions to align branch targets and the instructions following call
  instructions.  If there are not enough preceding safe density
  instructions to align a target, no widening is performed.  The
  default is \fB\-mtarget\-align\fR.  These options do not affect the
! treatment of auto-aligned instructions like \f(CW\*(C`LOOP\*(C'\fR, which the
  assembler always aligns, either by widening density instructions or
! by inserting \s-1NOP\s0 instructions.
! .IP "\fB\-mlongcalls\fR" 4
  .IX Item "-mlongcalls"
  .PD 0
! .IP "\fB\-mno\-longcalls\fR" 4
  .IX Item "-mno-longcalls"
  .PD
! When this option is enabled, \s-1GCC\s0 instructs the assembler to translate
  direct calls to indirect calls unless it can determine that the target
  of a direct call is in the range allowed by the call instruction.  This
  translation typically occurs for calls to functions in other source
--- 33375,33403 ----
  assembler to create several literal pools per function and assemble
  very big functions, which may not be possible with
  \&\fB\-mtext\-section\-literals\fR.
! .IP \fB\-mtarget\-align\fR 4
  .IX Item "-mtarget-align"
  .PD 0
! .IP \fB\-mno\-target\-align\fR 4
  .IX Item "-mno-target-align"
  .PD
! When this option is enabled, GCC instructs the assembler to
  automatically align instructions to reduce branch penalties at the
  expense of some code density.  The assembler attempts to widen density
  instructions to align branch targets and the instructions following call
  instructions.  If there are not enough preceding safe density
  instructions to align a target, no widening is performed.  The
  default is \fB\-mtarget\-align\fR.  These options do not affect the
! treatment of auto\-aligned instructions like \f(CW\*(C`LOOP\*(C'\fR, which the
  assembler always aligns, either by widening density instructions or
! by inserting NOP instructions.
! .IP \fB\-mlongcalls\fR 4
  .IX Item "-mlongcalls"
  .PD 0
! .IP \fB\-mno\-longcalls\fR 4
  .IX Item "-mno-longcalls"
  .PD
! When this option is enabled, 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
*************** instruction into an \f(CW\*(C`L32R\*(C'\
*** 33475,33507 ****
  The default is \fB\-mno\-longcalls\fR.  This option should be used in
  programs where the call target can potentially be out of range.  This
  option is implemented in the assembler, not the compiler, so the
! assembly code generated by \s-1GCC\s0 still shows direct call
  instructions\-\-\-look at the disassembled object code to see the actual
  instructions.  Note that the assembler uses an indirect call for
! every cross-file call, not just those that really are out of range.
! .IP "\fB\-mabi=\fR\fIname\fR" 4
  .IX Item "-mabi=name"
! Generate code for the specified \s-1ABI.\s0  Permissible values are: \fBcall0\fR,
! \&\fBwindowed\fR.  Default \s-1ABI\s0 is chosen by the Xtensa core configuration.
! .IP "\fB\-mabi=call0\fR" 4
  .IX Item "-mabi=call0"
  When this option is enabled function parameters are passed in registers
  \&\f(CW\*(C`a2\*(C'\fR through \f(CW\*(C`a7\*(C'\fR, registers \f(CW\*(C`a12\*(C'\fR through \f(CW\*(C`a15\*(C'\fR are
! caller-saved, and register \f(CW\*(C`a15\*(C'\fR may be used as a frame pointer.
! When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_XTENSA_CALL0_ABI_\|_\*(C'\fR is defined.
! .IP "\fB\-mabi=windowed\fR" 4
  .IX Item "-mabi=windowed"
  When this option is enabled function parameters are passed in registers
  \&\f(CW\*(C`a10\*(C'\fR through \f(CW\*(C`a15\*(C'\fR, and called function rotates register window
  by 8 registers on entry so that its arguments are found in registers
  \&\f(CW\*(C`a2\*(C'\fR through \f(CW\*(C`a7\*(C'\fR.  Register \f(CW\*(C`a7\*(C'\fR may be used as a frame
  pointer.  Register window is rotated 8 registers back upon return.
! When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_XTENSA_WINDOWED_ABI_\|_\*(C'\fR is defined.
! .IP "\fB\-mextra\-l32r\-costs=\fR\fIn\fR" 4
  .IX Item "-mextra-l32r-costs=n"
! Specify an extra cost of instruction \s-1RAM/ROM\s0 access for \f(CW\*(C`L32R\*(C'\fR
  instructions, in clock cycles.  This affects, when optimizing for speed,
  whether loading a constant from literal pool using \f(CW\*(C`L32R\*(C'\fR or
  synthesizing the constant from a small one with a couple of arithmetic
--- 33406,33438 ----
  The default is \fB\-mno\-longcalls\fR.  This option should be used in
  programs where the call target can potentially be out of range.  This
  option is implemented in the assembler, not the compiler, so the
! assembly code generated by GCC still shows direct call
  instructions\-\-\-look at the disassembled object code to see the actual
  instructions.  Note that the assembler uses an indirect call for
! every cross\-file call, not just those that really are out of range.
! .IP \fB\-mabi=\fR\fIname\fR 4
  .IX Item "-mabi=name"
! Generate code for the specified ABI.  Permissible values are: \fBcall0\fR,
! \&\fBwindowed\fR.  Default ABI is chosen by the Xtensa core configuration.
! .IP \fB\-mabi=call0\fR 4
  .IX Item "-mabi=call0"
  When this option is enabled function parameters are passed in registers
  \&\f(CW\*(C`a2\*(C'\fR through \f(CW\*(C`a7\*(C'\fR, registers \f(CW\*(C`a12\*(C'\fR through \f(CW\*(C`a15\*(C'\fR are
! caller\-saved, and register \f(CW\*(C`a15\*(C'\fR may be used as a frame pointer.
! When this version of the ABI is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_XTENSA_CALL0_ABI_\|_\*(C'\fR is defined.
! .IP \fB\-mabi=windowed\fR 4
  .IX Item "-mabi=windowed"
  When this option is enabled function parameters are passed in registers
  \&\f(CW\*(C`a10\*(C'\fR through \f(CW\*(C`a15\*(C'\fR, and called function rotates register window
  by 8 registers on entry so that its arguments are found in registers
  \&\f(CW\*(C`a2\*(C'\fR through \f(CW\*(C`a7\*(C'\fR.  Register \f(CW\*(C`a7\*(C'\fR may be used as a frame
  pointer.  Register window is rotated 8 registers back upon return.
! When this version of the ABI is enabled the C preprocessor symbol
  \&\f(CW\*(C`_\|_XTENSA_WINDOWED_ABI_\|_\*(C'\fR is defined.
! .IP \fB\-mextra\-l32r\-costs=\fR\fIn\fR 4
  .IX Item "-mextra-l32r-costs=n"
! Specify an extra cost of instruction RAM/ROM access for \f(CW\*(C`L32R\*(C'\fR
  instructions, in clock cycles.  This affects, when optimizing for speed,
  whether loading a constant from literal pool using \f(CW\*(C`L32R\*(C'\fR or
  synthesizing the constant from a small one with a couple of arithmetic
*************** instructions.  The default value is 0.
*** 33511,33519 ****
  .IX Subsection "zSeries Options"
  .PP
  These are listed under
! .SH "ENVIRONMENT"
  .IX Header "ENVIRONMENT"
! This section describes several environment variables that affect how \s-1GCC\s0
  operates.  Some of them work by specifying directories or prefixes to use
  when searching for various kinds of files.  Some are used to specify other
  aspects of the compilation environment.
--- 33442,33450 ----
  .IX Subsection "zSeries Options"
  .PP
  These are listed under
! .SH ENVIRONMENT
  .IX Header "ENVIRONMENT"
! 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.
*************** aspects of the compilation environment.
*** 33521,33586 ****
  Note that you can also specify places to search using options such as
  \&\fB\-B\fR, \fB\-I\fR and \fB\-L\fR.  These
  take precedence over places specified using environment variables, which
! in turn take precedence over those specified by the configuration of \s-1GCC.\s0
! .IP "\fB\s-1LANG\s0\fR" 4
  .IX Item "LANG"
  .PD 0
! .IP "\fB\s-1LC_CTYPE\s0\fR" 4
  .IX Item "LC_CTYPE"
! .IP "\fB\s-1LC_MESSAGES\s0\fR" 4
  .IX Item "LC_MESSAGES"
! .IP "\fB\s-1LC_ALL\s0\fR" 4
  .IX Item "LC_ALL"
  .PD
! These environment variables control the way that \s-1GCC\s0 uses
! localization information which allows \s-1GCC\s0 to work with different
! national conventions.  \s-1GCC\s0 inspects the locale categories
! \&\fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR if it has been configured to do
  so.  These locale categories can be set to any value supported by your
  installation.  A typical value is \fBen_GB.UTF\-8\fR for English in the United
! Kingdom encoded in \s-1UTF\-8.\s0
  .Sp
! The \fB\s-1LC_CTYPE\s0\fR environment variable specifies character
! classification.  \s-1GCC\s0 uses it to determine the character boundaries in
  a string; this is needed for some multibyte encodings that contain quote
  and escape characters that are otherwise interpreted as a string
  end or escape.
  .Sp
! The \fB\s-1LC_MESSAGES\s0\fR environment variable specifies the language to
  use in diagnostic messages.
  .Sp
! If the \fB\s-1LC_ALL\s0\fR environment variable is set, it overrides the value
! of \fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR; otherwise, \fB\s-1LC_CTYPE\s0\fR
! and \fB\s-1LC_MESSAGES\s0\fR default to the value of the \fB\s-1LANG\s0\fR
! environment variable.  If none of these variables are set, \s-1GCC\s0
  defaults to traditional C English behavior.
! .IP "\fB\s-1TMPDIR\s0\fR" 4
  .IX Item "TMPDIR"
! If \fB\s-1TMPDIR\s0\fR is set, it specifies the directory to use for temporary
! files.  \s-1GCC\s0 uses temporary files to hold the output of one stage of
  compilation which is to be used as input to the next stage: for example,
  the output of the preprocessor, which is the input to the compiler
  proper.
! .IP "\fB\s-1GCC_COMPARE_DEBUG\s0\fR" 4
  .IX Item "GCC_COMPARE_DEBUG"
! Setting \fB\s-1GCC_COMPARE_DEBUG\s0\fR is nearly equivalent to passing
  \&\fB\-fcompare\-debug\fR to the compiler driver.  See the documentation
  of this option for more details.
! .IP "\fB\s-1GCC_EXEC_PREFIX\s0\fR" 4
  .IX Item "GCC_EXEC_PREFIX"
! If \fB\s-1GCC_EXEC_PREFIX\s0\fR is set, it specifies a prefix to use in the
  names of the subprograms executed by the compiler.  No slash is added
  when this prefix is combined with the name of a subprogram, but you can
  specify a prefix that ends with a slash if you wish.
  .Sp
! If \fB\s-1GCC_EXEC_PREFIX\s0\fR is not set, \s-1GCC\s0 attempts to figure out
  an appropriate prefix to use based on the pathname it is invoked with.
  .Sp
! If \s-1GCC\s0 cannot find the subprogram using the specified prefix, it
  tries looking in the usual places for the subprogram.
  .Sp
! The default value of \fB\s-1GCC_EXEC_PREFIX\s0\fR is
! \&\fI\fIprefix\fI/lib/gcc/\fR where \fIprefix\fR is the prefix to
  the installed compiler. In many cases \fIprefix\fR is the value
  of \f(CW\*(C`prefix\*(C'\fR when you ran the \fIconfigure\fR script.
  .Sp
--- 33452,33517 ----
  Note that you can also specify places to search using options such as
  \&\fB\-B\fR, \fB\-I\fR and \fB\-L\fR.  These
  take precedence over places specified using environment variables, which
! in turn take precedence over those specified by the configuration of GCC.
! .IP \fBLANG\fR 4
  .IX Item "LANG"
  .PD 0
! .IP \fBLC_CTYPE\fR 4
  .IX Item "LC_CTYPE"
! .IP \fBLC_MESSAGES\fR 4
  .IX Item "LC_MESSAGES"
! .IP \fBLC_ALL\fR 4
  .IX Item "LC_ALL"
  .PD
! These environment variables control the way that GCC uses
! localization information which allows GCC to work with different
! national conventions.  GCC inspects the locale categories
! \&\fBLC_CTYPE\fR and \fBLC_MESSAGES\fR if it has been configured to do
  so.  These locale categories can be set to any value supported by your
  installation.  A typical value is \fBen_GB.UTF\-8\fR for English in the United
! Kingdom encoded in UTF\-8.
  .Sp
! The \fBLC_CTYPE\fR environment variable specifies character
! classification.  GCC uses it to determine the character boundaries in
  a string; this is needed for some multibyte encodings that contain quote
  and escape characters that are otherwise interpreted as a string
  end or escape.
  .Sp
! The \fBLC_MESSAGES\fR environment variable specifies the language to
  use in diagnostic messages.
  .Sp
! If the \fBLC_ALL\fR environment variable is set, it overrides the value
! of \fBLC_CTYPE\fR and \fBLC_MESSAGES\fR; otherwise, \fBLC_CTYPE\fR
! and \fBLC_MESSAGES\fR default to the value of the \fBLANG\fR
! environment variable.  If none of these variables are set, GCC
  defaults to traditional C English behavior.
! .IP \fBTMPDIR\fR 4
  .IX Item "TMPDIR"
! If \fBTMPDIR\fR 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.
! .IP \fBGCC_COMPARE_DEBUG\fR 4
  .IX Item "GCC_COMPARE_DEBUG"
! Setting \fBGCC_COMPARE_DEBUG\fR is nearly equivalent to passing
  \&\fB\-fcompare\-debug\fR to the compiler driver.  See the documentation
  of this option for more details.
! .IP \fBGCC_EXEC_PREFIX\fR 4
  .IX Item "GCC_EXEC_PREFIX"
! If \fBGCC_EXEC_PREFIX\fR is set, it specifies a prefix to use in the
  names of the subprograms executed by the compiler.  No slash is added
  when this prefix is combined with the name of a subprogram, but you can
  specify a prefix that ends with a slash if you wish.
  .Sp
! If \fBGCC_EXEC_PREFIX\fR is not set, GCC attempts to figure out
  an appropriate prefix to use based on the pathname it is invoked with.
  .Sp
! If GCC cannot find the subprogram using the specified prefix, it
  tries looking in the usual places for the subprogram.
  .Sp
! The default value of \fBGCC_EXEC_PREFIX\fR is
! \&\fIprefix/lib/gcc/\fR where \fIprefix\fR is the prefix to
  the installed compiler. In many cases \fIprefix\fR is the value
  of \f(CW\*(C`prefix\*(C'\fR when you ran the \fIconfigure\fR script.
  .Sp
*************** used for linking.
*** 33592,33658 ****
  In addition, the prefix is used in an unusual way in finding the
  directories to search for header files.  For each of the standard
  directories whose name normally begins with \fB/usr/local/lib/gcc\fR
! (more precisely, with the value of \fB\s-1GCC_INCLUDE_DIR\s0\fR), \s-1GCC\s0 tries
  replacing that beginning with the specified prefix to produce an
! alternate directory name.  Thus, with \fB\-Bfoo/\fR, \s-1GCC\s0 searches
  \&\fIfoo/bar\fR just before it searches the standard directory 
  \&\fI/usr/local/lib/bar\fR.
  If a standard directory begins with the configured
  \&\fIprefix\fR then the value of \fIprefix\fR is replaced by
! \&\fB\s-1GCC_EXEC_PREFIX\s0\fR when looking for header files.
! .IP "\fB\s-1COMPILER_PATH\s0\fR" 4
  .IX Item "COMPILER_PATH"
! The value of \fB\s-1COMPILER_PATH\s0\fR is a colon-separated list of
! directories, much like \fB\s-1PATH\s0\fR.  \s-1GCC\s0 tries the directories thus
  specified when searching for subprograms, if it cannot find the
! subprograms using \fB\s-1GCC_EXEC_PREFIX\s0\fR.
! .IP "\fB\s-1LIBRARY_PATH\s0\fR" 4
  .IX Item "LIBRARY_PATH"
! The value of \fB\s-1LIBRARY_PATH\s0\fR is a colon-separated list of
! directories, much like \fB\s-1PATH\s0\fR.  When configured as a native compiler,
! \&\s-1GCC\s0 tries the directories thus specified when searching for special
! linker files, if it cannot find them using \fB\s-1GCC_EXEC_PREFIX\s0\fR.  Linking
! using \s-1GCC\s0 also uses these directories when searching for ordinary
  libraries for the \fB\-l\fR option (but directories specified with
  \&\fB\-L\fR come first).
! .IP "\fB\s-1LANG\s0\fR" 4
  .IX Item "LANG"
  This variable is used to pass locale information to the compiler.  One way in
  which this information is used is to determine the character set to be used
! when character literals, string literals and comments are parsed in C and \*(C+.
  When the compiler is configured to allow multibyte characters,
! the following values for \fB\s-1LANG\s0\fR are recognized:
  .RS 4
! .IP "\fBC\-JIS\fR" 4
  .IX Item "C-JIS"
! Recognize \s-1JIS\s0 characters.
! .IP "\fBC\-SJIS\fR" 4
  .IX Item "C-SJIS"
! Recognize \s-1SJIS\s0 characters.
! .IP "\fBC\-EUCJP\fR" 4
  .IX Item "C-EUCJP"
! Recognize \s-1EUCJP\s0 characters.
  .RE
  .RS 4
  .Sp
! If \fB\s-1LANG\s0\fR is not defined, or if it has some other value, then the
  compiler uses \f(CW\*(C`mblen\*(C'\fR and \f(CW\*(C`mbtowc\*(C'\fR as defined by the default locale to
  recognize and translate multibyte characters.
  .RE
! .IP "\fB\s-1GCC_EXTRA_DIAGNOSTIC_OUTPUT\s0\fR" 4
  .IX Item "GCC_EXTRA_DIAGNOSTIC_OUTPUT"
! If \fB\s-1GCC_EXTRA_DIAGNOSTIC_OUTPUT\s0\fR is set to one of the following values,
! then additional text will be emitted to stderr when fix-it hints are
  emitted.  \fB\-fdiagnostics\-parseable\-fixits\fR and
  \&\fB\-fno\-diagnostics\-parseable\-fixits\fR take precedence over this
  environment variable.
  .RS 4
! .IP "\fBfixits\-v1\fR" 4
  .IX Item "fixits-v1"
! Emit parseable fix-it hints, equivalent to
  \&\fB\-fdiagnostics\-parseable\-fixits\fR.  In particular, columns are
  expressed as a count of bytes, starting at byte 1 for the initial column.
! .IP "\fBfixits\-v2\fR" 4
  .IX Item "fixits-v2"
  As \f(CW\*(C`fixits\-v1\*(C'\fR, but columns are expressed as display columns,
  as per \fB\-fdiagnostics\-column\-unit=display\fR.
--- 33523,33589 ----
  In addition, the prefix is used in an unusual way in finding the
  directories to search for header files.  For each of the standard
  directories whose name normally begins with \fB/usr/local/lib/gcc\fR
! (more precisely, with the value of \fBGCC_INCLUDE_DIR\fR), GCC tries
  replacing that beginning with the specified prefix to produce an
! alternate directory name.  Thus, with \fB\-Bfoo/\fR, GCC searches
  \&\fIfoo/bar\fR just before it searches the standard directory 
  \&\fI/usr/local/lib/bar\fR.
  If a standard directory begins with the configured
  \&\fIprefix\fR then the value of \fIprefix\fR is replaced by
! \&\fBGCC_EXEC_PREFIX\fR when looking for header files.
! .IP \fBCOMPILER_PATH\fR 4
  .IX Item "COMPILER_PATH"
! The value of \fBCOMPILER_PATH\fR is a colon\-separated list of
! directories, much like \fBPATH\fR.  GCC tries the directories thus
  specified when searching for subprograms, if it cannot find the
! subprograms using \fBGCC_EXEC_PREFIX\fR.
! .IP \fBLIBRARY_PATH\fR 4
  .IX Item "LIBRARY_PATH"
! The value of \fBLIBRARY_PATH\fR is a colon\-separated list of
! directories, much like \fBPATH\fR.  When configured as a native compiler,
! GCC tries the directories thus specified when searching for special
! linker files, if it cannot find them using \fBGCC_EXEC_PREFIX\fR.  Linking
! using GCC also uses these directories when searching for ordinary
  libraries for the \fB\-l\fR option (but directories specified with
  \&\fB\-L\fR come first).
! .IP \fBLANG\fR 4
  .IX Item "LANG"
  This variable is used to pass locale information to the compiler.  One way in
  which this information is used is to determine the character set to be used
! when character literals, string literals and comments are parsed in C and C++.
  When the compiler is configured to allow multibyte characters,
! the following values for \fBLANG\fR are recognized:
  .RS 4
! .IP \fBC\-JIS\fR 4
  .IX Item "C-JIS"
! Recognize JIS characters.
! .IP \fBC\-SJIS\fR 4
  .IX Item "C-SJIS"
! Recognize SJIS characters.
! .IP \fBC\-EUCJP\fR 4
  .IX Item "C-EUCJP"
! Recognize EUCJP characters.
  .RE
  .RS 4
  .Sp
! If \fBLANG\fR is not defined, or if it has some other value, then the
  compiler uses \f(CW\*(C`mblen\*(C'\fR and \f(CW\*(C`mbtowc\*(C'\fR as defined by the default locale to
  recognize and translate multibyte characters.
  .RE
! .IP \fBGCC_EXTRA_DIAGNOSTIC_OUTPUT\fR 4
  .IX Item "GCC_EXTRA_DIAGNOSTIC_OUTPUT"
! If \fBGCC_EXTRA_DIAGNOSTIC_OUTPUT\fR is set to one of the following values,
! then additional text will be emitted to stderr when fix\-it hints are
  emitted.  \fB\-fdiagnostics\-parseable\-fixits\fR and
  \&\fB\-fno\-diagnostics\-parseable\-fixits\fR take precedence over this
  environment variable.
  .RS 4
! .IP \fBfixits\-v1\fR 4
  .IX Item "fixits-v1"
! Emit parseable fix\-it hints, equivalent to
  \&\fB\-fdiagnostics\-parseable\-fixits\fR.  In particular, columns are
  expressed as a count of bytes, starting at byte 1 for the initial column.
! .IP \fBfixits\-v2\fR 4
  .IX Item "fixits-v2"
  As \f(CW\*(C`fixits\-v1\*(C'\fR, but columns are expressed as display columns,
  as per \fB\-fdiagnostics\-column\-unit=display\fR.
*************** as per \fB\-fdiagnostics\-column\-unit=d
*** 33662,33684 ****
  .PP
  Some additional environment variables affect the behavior of the
  preprocessor.
! .IP "\fB\s-1CPATH\s0\fR" 4
  .IX Item "CPATH"
  .PD 0
! .IP "\fBC_INCLUDE_PATH\fR" 4
  .IX Item "C_INCLUDE_PATH"
! .IP "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4
  .IX Item "CPLUS_INCLUDE_PATH"
! .IP "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4
  .IX Item "OBJC_INCLUDE_PATH"
  .PD
! Each variable's value is a list of directories separated by a special
! character, much like \fB\s-1PATH\s0\fR, in which to look for header files.
! The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, is target-dependent and
! determined at \s-1GCC\s0 build time.  For Microsoft Windows-based targets it is a
  semicolon, and for almost all other targets it is a colon.
  .Sp
! \&\fB\s-1CPATH\s0\fR specifies a list of directories to be searched as if
  specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
  options on the command line.  This environment variable is used
  regardless of which language is being preprocessed.
--- 33593,33615 ----
  .PP
  Some additional environment variables affect the behavior of the
  preprocessor.
! .IP \fBCPATH\fR 4
  .IX Item "CPATH"
  .PD 0
! .IP \fBC_INCLUDE_PATH\fR 4
  .IX Item "C_INCLUDE_PATH"
! .IP \fBCPLUS_INCLUDE_PATH\fR 4
  .IX Item "CPLUS_INCLUDE_PATH"
! .IP \fBOBJC_INCLUDE_PATH\fR 4
  .IX Item "OBJC_INCLUDE_PATH"
  .PD
! Each variable\*(Aqs value is a list of directories separated by a special
! character, much like \fBPATH\fR, in which to look for header files.
! The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, 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.
  .Sp
! \&\fBCPATH\fR specifies a list of directories to be searched as if
  specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
  options on the command line.  This environment variable is used
  regardless of which language is being preprocessed.
*************** paths given with \fB\-isystem\fR options
*** 33691,33706 ****
  In all these variables, an empty element instructs the compiler to
  search its current working directory.  Empty elements can appear at the
  beginning or end of a path.  For instance, if the value of
! \&\fB\s-1CPATH\s0\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
  effect as \fB\-I.\ \-I/special/include\fR.
! .IP "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4
  .IX Item "DEPENDENCIES_OUTPUT"
  If this variable is set, its value specifies how to output
! dependencies for Make based on the non-system header files processed
  by the compiler.  System header files are ignored in the dependency
  output.
  .Sp
! The value of \fB\s-1DEPENDENCIES_OUTPUT\s0\fR can be just a file name, in
  which case the Make rules are written to that file, guessing the target
  name from the source file name.  Or the value can have the form
  \&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
--- 33622,33637 ----
  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
! \&\fBCPATH\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
  effect as \fB\-I.\ \-I/special/include\fR.
! .IP \fBDEPENDENCIES_OUTPUT\fR 4
  .IX Item "DEPENDENCIES_OUTPUT"
  If this variable is set, its value specifies how to output
! dependencies for Make based on the non\-system header files processed
  by the compiler.  System header files are ignored in the dependency
  output.
  .Sp
! The value of \fBDEPENDENCIES_OUTPUT\fR can be just a file name, in
  which case the Make rules are written to that file, guessing the target
  name from the source file name.  Or the value can have the form
  \&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
*************** file \fIfile\fR using \fItarget\fR as th
*** 33709,33750 ****
  In other words, this environment variable is equivalent to combining
  the options \fB\-MM\fR and \fB\-MF\fR,
  with an optional \fB\-MT\fR switch too.
! .IP "\fB\s-1SUNPRO_DEPENDENCIES\s0\fR" 4
  .IX Item "SUNPRO_DEPENDENCIES"
! This variable is the same as \fB\s-1DEPENDENCIES_OUTPUT\s0\fR (see above),
  except that system header files are not ignored, so it implies
  \&\fB\-M\fR rather than \fB\-MM\fR.  However, the dependence on the
  main input file is omitted.
! .IP "\fB\s-1SOURCE_DATE_EPOCH\s0\fR" 4
  .IX Item "SOURCE_DATE_EPOCH"
! If this variable is set, its value specifies a \s-1UNIX\s0 timestamp to be
  used in replacement of the current date and time in the \f(CW\*(C`_\|_DATE_\|_\*(C'\fR
  and \f(CW\*(C`_\|_TIME_\|_\*(C'\fR macros, so that the embedded timestamps become
  reproducible.
  .Sp
! The value of \fB\s-1SOURCE_DATE_EPOCH\s0\fR must be a \s-1UNIX\s0 timestamp,
  defined as the number of seconds (excluding leap seconds) since
! 01 Jan 1970 00:00:00 represented in \s-1ASCII\s0; identical to the output of
  \&\f(CW\*(C`date +%s\*(C'\fR on GNU/Linux and other systems that support the
  \&\f(CW%s\fR extension in the \f(CW\*(C`date\*(C'\fR command.
  .Sp
  The value should be a known timestamp such as the last modification
  time of the source or package and it should be set by the build
  process.
! .SH "BUGS"
  .IX Header "BUGS"
  For instructions on reporting bugs, see
  <\fBhttps://gcc.gnu.org/bugs/\fR>.
! .SH "FOOTNOTES"
  .IX Header "FOOTNOTES"
! .IP "1." 4
  On some systems, \fBgcc \-shared\fR
  needs to build supplementary stub code for constructors to work.  On
! multi-libbed systems, \fBgcc \-shared\fR must select the correct support
  libraries to link against.  Failing to supply the correct flags may lead
  to subtle defects.  Supplying them in cases where they are not necessary
  is innocuous.  \fB\-shared\fR suppresses the addition of startup code
! to alter the floating-point environment as done with \fB\-ffast\-math\fR,
  \&\fB\-Ofast\fR or \fB\-funsafe\-math\-optimizations\fR on some targets.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
--- 33640,33681 ----
  In other words, this environment variable is equivalent to combining
  the options \fB\-MM\fR and \fB\-MF\fR,
  with an optional \fB\-MT\fR switch too.
! .IP \fBSUNPRO_DEPENDENCIES\fR 4
  .IX Item "SUNPRO_DEPENDENCIES"
! This variable is the same as \fBDEPENDENCIES_OUTPUT\fR (see above),
  except that system header files are not ignored, so it implies
  \&\fB\-M\fR rather than \fB\-MM\fR.  However, the dependence on the
  main input file is omitted.
! .IP \fBSOURCE_DATE_EPOCH\fR 4
  .IX Item "SOURCE_DATE_EPOCH"
! If this variable is set, its value specifies a UNIX timestamp to be
  used in replacement of the current date and time in the \f(CW\*(C`_\|_DATE_\|_\*(C'\fR
  and \f(CW\*(C`_\|_TIME_\|_\*(C'\fR macros, so that the embedded timestamps become
  reproducible.
  .Sp
! The value of \fBSOURCE_DATE_EPOCH\fR must be a UNIX timestamp,
  defined as the number of seconds (excluding leap seconds) since
! 01 Jan 1970 00:00:00 represented in ASCII; identical to the output of
  \&\f(CW\*(C`date +%s\*(C'\fR on GNU/Linux and other systems that support the
  \&\f(CW%s\fR extension in the \f(CW\*(C`date\*(C'\fR command.
  .Sp
  The value should be a known timestamp such as the last modification
  time of the source or package and it should be set by the build
  process.
! .SH BUGS
  .IX Header "BUGS"
  For instructions on reporting bugs, see
  <\fBhttps://gcc.gnu.org/bugs/\fR>.
! .SH FOOTNOTES
  .IX Header "FOOTNOTES"
! .IP 1. 4
  On some systems, \fBgcc \-shared\fR
  needs to build supplementary stub code for constructors to work.  On
! multi\-libbed systems, \fBgcc \-shared\fR must select the correct support
  libraries to link against.  Failing to supply the correct flags may lead
  to subtle defects.  Supplying them in cases where they are not necessary
  is innocuous.  \fB\-shared\fR suppresses the addition of startup code
! to alter the floating\-point environment as done with \fB\-ffast\-math\fR,
  \&\fB\-Ofast\fR or \fB\-funsafe\-math\-optimizations\fR on some targets.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
*************** to alter the floating-point environment
*** 33752,33781 ****
  \&\fBcpp\fR\|(1), \fBgcov\fR\|(1), \fBas\fR\|(1), \fBld\fR\|(1), \fBgdb\fR\|(1)
  and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIas\fR,
  \&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
! .SH "AUTHOR"
  .IX Header "AUTHOR"
  See the Info entry for \fBgcc\fR, or
  <\fBhttps://gcc.gnu.org/onlinedocs/gcc/Contributors.html\fR>,
! for contributors to \s-1GCC.\s0
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 1988\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
! Free Software\*(R", the Front-Cover texts being (a) (see below), and with
! the Back-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The \s-1FSF\s0's Front-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The \s-1FSF\s0's Back-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
--- 33683,33712 ----
  \&\fBcpp\fR\|(1), \fBgcov\fR\|(1), \fBas\fR\|(1), \fBld\fR\|(1), \fBgdb\fR\|(1)
  and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIas\fR,
  \&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
! .SH AUTHOR
  .IX Header "AUTHOR"
  See the Info entry for \fBgcc\fR, or
  <\fBhttps://gcc.gnu.org/onlinedocs/gcc/Contributors.html\fR>,
! for contributors to GCC.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 1988\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the GNU Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being "GNU General Public License" and "Funding
! Free Software", the Front\-Cover texts being (a) (see below), and with
! the Back\-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The FSF\*(Aqs Front\-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The FSF\*(Aqs Back\-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
diff -Nrcpad gcc-13.4.0/gcc/doc/gcc.info gcc-13.5.0-RC-20260904/gcc/doc/gcc.info
*** gcc-13.4.0/gcc/doc/gcc.info	Thu Jun  5 16:22:05 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gcc.info	Fri Sep  4 07:50:38 2026
***************
*** 1,8 ****
! This is gcc.info, produced by makeinfo version 6.8 from gcc.texi.
  
  This file documents the use of the GNU compilers.
  
!  Copyright (C) 1988-2023 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
--- 1,8 ----
! This is gcc.info, produced by makeinfo version 7.1 from gcc.texi.
  
  This file documents the use of the GNU compilers.
  
!  Copyright © 1988-2023 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
*************** INFO-DIR-SECTION Software development
*** 25,41 ****
  START-INFO-DIR-ENTRY
  * gcc: (gcc).                  The GNU Compiler Collection.
  * g++: (gcc).                  The GNU C++ compiler.
! * gcov: (gcc) Gcov.            'gcov'--a test coverage program.
! * gcov-tool: (gcc) Gcov-tool.  'gcov-tool'--an offline gcda profile processing program.
! * gcov-dump: (gcc) Gcov-dump.  'gcov-dump'--an offline gcda and gcno profile dump tool.
! * lto-dump: (gcc) lto-dump.    'lto-dump'--Tool for
  dumping LTO object files.
  END-INFO-DIR-ENTRY
  
  
   This file documents the use of the GNU compilers.
  
!  Copyright (C) 1988-2023 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
--- 25,41 ----
  START-INFO-DIR-ENTRY
  * gcc: (gcc).                  The GNU Compiler Collection.
  * g++: (gcc).                  The GNU C++ compiler.
! * gcov: (gcc) Gcov.            ‘gcov’--a test coverage program.
! * gcov-tool: (gcc) Gcov-tool.  ‘gcov-tool’--an offline gcda profile processing program.
! * gcov-dump: (gcc) Gcov-dump.  ‘gcov-dump’--an offline gcda and gcno profile dump tool.
! * lto-dump: (gcc) lto-dump.    ‘lto-dump’--Tool for
  dumping LTO object files.
  END-INFO-DIR-ENTRY
  
  
   This file documents the use of the GNU compilers.
  
!  Copyright © 1988-2023 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
*************** Introduction
*** 63,69 ****
  
  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 13.4.0.  The internals of the GNU
  compilers, including how to port them to new targets and some
  information about how to write front ends for new languages, are
  documented in a separate manual.  *Note Introduction: (gccint)Top.
--- 63,69 ----
  
  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 13.4.1.  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.
*************** documented in a separate manual.  *Note
*** 72,88 ****
  
  * G++ and GCC::     You can compile C or C++ programs.
  * Standards::       Language standards supported by GCC.
! * Invoking GCC::    Command options supported by 'gcc'.
  * C Implementation:: How GCC implements the ISO C specification.
  * C++ Implementation:: How GCC implements the ISO C++ specification.
  * C Extensions::    GNU extensions to the C language family.
  * C++ Extensions::  GNU extensions to the C++ language.
  * Objective-C::     GNU Objective-C runtime features.
  * Compatibility::   Binary Compatibility
! * Gcov::            'gcov'--a test coverage program.
! * Gcov-tool::       'gcov-tool'--an offline gcda profile processing program.
! * Gcov-dump::       'gcov-dump'--an offline gcda and gcno profile dump tool.
! * lto-dump::        'lto-dump'--Tool for dumping LTO
  object files.
  * Trouble::         If you have trouble using GCC.
  * Bugs::            How, why and where to report bugs.
--- 72,88 ----
  
  * G++ and GCC::     You can compile C or C++ programs.
  * Standards::       Language standards supported by GCC.
! * Invoking GCC::    Command options supported by ‘gcc’.
  * C Implementation:: How GCC implements the ISO C specification.
  * C++ Implementation:: How GCC implements the ISO C++ specification.
  * C Extensions::    GNU extensions to the C language family.
  * C++ Extensions::  GNU extensions to the C++ language.
  * Objective-C::     GNU Objective-C runtime features.
  * Compatibility::   Binary Compatibility
! * Gcov::            ‘gcov’--a test coverage program.
! * Gcov-tool::       ‘gcov-tool’--an offline gcda profile processing program.
! * Gcov-dump::       ‘gcov-dump’--an offline gcda and gcno profile dump tool.
! * lto-dump::        ‘lto-dump’--Tool for dumping LTO
  object files.
  * Trouble::         If you have trouble using GCC.
  * Bugs::            How, why and where to report bugs.
*************** distribution of compilers for several ma
*** 110,121 ****
  These languages currently include C, C++, Objective-C, Objective-C++,
  Fortran, Ada, D, 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
--- 110,121 ----
  These languages currently include C, C++, Objective-C, Objective-C++,
  Fortran, Ada, D, 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
*************** compiler by its own name, or as GCC.  Ei
*** 137,143 ****
  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.
  
--- 137,143 ----
  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.
  
*************** published in 1990.  This standard was ra
*** 160,170 ****
  between these publications, although the sections of the ANSI standard
  were renumbered and became clauses in the ISO standard.  The ANSI
  standard, but not the ISO standard, also came with a Rationale document.
! This standard, in both its forms, is commonly known as "C89", or
! occasionally as "C90", from the dates of ratification.  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.
  
--- 160,170 ----
  between these publications, although the sections of the ANSI standard
  were renumbered and became clauses in the ISO standard.  The ANSI
  standard, but not the ISO standard, also came with a Rationale document.
! This standard, in both its forms, is commonly known as “C89”, or
! occasionally as “C90”, from the dates of ratification.  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.
  
*************** Corrigenda published in 1994 and 1996.
*** 173,241 ****
  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".  (While in development,
! drafts of this standard version were referred to as "C9X".) GCC has
  substantially complete support for this standard version; see
   for details.  To select this
! standard, use '-std=c99' or '-std=iso9899:1999'.
  
   Errors in the 1999 ISO C standard were corrected in three Technical
  Corrigenda published in 2001, 2004 and 2007.  GCC does not support the
  uncorrected version.
  
!  A fourth version of the C standard, known as "C11", was published in
  2011 as ISO/IEC 9899:2011.  (While in development, drafts of this
! standard version were referred to as "C1X".) GCC has substantially
! complete support for this standard, enabled with '-std=c11' or
! '-std=iso9899:2011'.  A version with corrections integrated was prepared
! in 2017 and published in 2018 as ISO/IEC 9899:2018; it is known as "C17"
! and is supported with '-std=c17' or '-std=iso9899:2017'; the corrections
! are also applied with '-std=c11', and the only difference between the
! options is the value of '__STDC_VERSION__'.
  
!  A further version of the C standard, known as "C2X", is under
  development; experimental and incomplete support for this is enabled
! with '-std=c2x'.
  
   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.  Some features that are part of the C99
  standard are accepted as extensions in C90 mode, and some features that
  are part of the C11 standard are accepted as extensions in C90 and C99
! modes.  Use of the '-std' options listed above disables these extensions
  where they conflict with the C standard version selected.  You may also
  select an extended version of the C language explicitly with
! '-std=gnu90' (for C90 with GNU extensions), '-std=gnu99' (for C99 with
! GNU extensions) or '-std=gnu11' (for C11 with GNU extensions).
  
   The default, if no C language dialect options are given, is
! '-std=gnu17'.
  
   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 '', '', '', and
! ''; since AMD1, also those in ''; since C99, also
! those in '' and ''; and since C11, also those in
! '' and ''.  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 is an example of a program running in a freestanding
  environment; a program using the facilities of an operating system is an
  example of a program running in a hosted environment.
--- 173,241 ----
  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”.  (While in development,
! drafts of this standard version were referred to as “C9X”.) GCC has
  substantially complete support for this standard version; see
   for details.  To select this
! standard, use ‘-std=c99’ or ‘-std=iso9899:1999’.
  
   Errors in the 1999 ISO C standard were corrected in three Technical
  Corrigenda published in 2001, 2004 and 2007.  GCC does not support the
  uncorrected version.
  
!  A fourth version of the C standard, known as “C11”, was published in
  2011 as ISO/IEC 9899:2011.  (While in development, drafts of this
! standard version were referred to as “C1X”.) GCC has substantially
! complete support for this standard, enabled with ‘-std=c11’ or
! ‘-std=iso9899:2011’.  A version with corrections integrated was prepared
! in 2017 and published in 2018 as ISO/IEC 9899:2018; it is known as “C17”
! and is supported with ‘-std=c17’ or ‘-std=iso9899:2017’; the corrections
! are also applied with ‘-std=c11’, and the only difference between the
! options is the value of ‘__STDC_VERSION__’.
  
!  A further version of the C standard, known as “C2X”, is under
  development; experimental and incomplete support for this is enabled
! with ‘-std=c2x’.
  
   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.  Some features that are part of the C99
  standard are accepted as extensions in C90 mode, and some features that
  are part of the C11 standard are accepted as extensions in C90 and C99
! modes.  Use of the ‘-std’ options listed above disables these extensions
  where they conflict with the C standard version selected.  You may also
  select an extended version of the C language explicitly with
! ‘-std=gnu90’ (for C90 with GNU extensions), ‘-std=gnu99’ (for C99 with
! GNU extensions) or ‘-std=gnu11’ (for C11 with GNU extensions).
  
   The default, if no C language dialect options are given, is
! ‘-std=gnu17’.
  
   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 ‘’, ‘’, ‘’, and
! ‘’; since AMD1, also those in ‘’; since C99, also
! those in ‘’ and ‘’; and since C11, also those in
! ‘’ and ‘’.  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 is an example of a program running in a freestanding
  environment; a program using the facilities of an operating system is an
  example of a program running in a hosted environment.
*************** example of a program running in a hosted
*** 243,253 ****
   GCC aims towards being usable as a conforming freestanding
  implementation, or as the compiler for a conforming hosted
  implementation.  By default, it acts 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 then defines '__STDC_HOSTED__' to '0' and does 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.
--- 243,253 ----
   GCC aims towards being usable as a conforming freestanding
  implementation, or as the compiler for a conforming hosted
  implementation.  By default, it acts 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 then defines ‘__STDC_HOSTED__’ to ‘0’ and does 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.
*************** a hosted environment, you need to find t
*** 260,269 ****
  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 emits a call to 'abort'.
  
   For references to Technical Corrigenda, Rationale documents and
  information concerning the history of C that is available online, see
--- 260,269 ----
  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 emits a call to ‘abort’.
  
   For references to Technical Corrigenda, Rationale documents and
  information concerning the history of C that is available online, see
*************** GCC supports the original ISO C++ standa
*** 278,288 ****
   The original ISO C++ standard was published as the ISO standard
  (ISO/IEC 14882:1998) and amended by a Technical Corrigenda published in
  2003 (ISO/IEC 14882:2003).  These standards are referred to as C++98 and
! C++03, respectively.  GCC implements the majority of C++98 ('export' is
  a notable exception) and most of the changes in C++03.  To select this
! standard in GCC, use one of the options '-ansi', '-std=c++98', or
! '-std=c++03'; to obtain all the diagnostics required by the standard,
! you should also specify '-pedantic' (or '-pedantic-errors' if you want
  them to be errors rather than warnings).
  
   A revised ISO C++ standard was published in 2011 as ISO/IEC 14882:2011,
--- 278,288 ----
   The original ISO C++ standard was published as the ISO standard
  (ISO/IEC 14882:1998) and amended by a Technical Corrigenda published in
  2003 (ISO/IEC 14882:2003).  These standards are referred to as C++98 and
! C++03, respectively.  GCC implements the majority of C++98 (‘export’ is
  a notable exception) and most of the changes in C++03.  To select this
! standard in GCC, use one of the options ‘-ansi’, ‘-std=c++98’, or
! ‘-std=c++03’; to obtain all the diagnostics required by the standard,
! you should also specify ‘-pedantic’ (or ‘-pedantic-errors’ if you want
  them to be errors rather than warnings).
  
   A revised ISO C++ standard was published in 2011 as ISO/IEC 14882:2011,
*************** and is referred to as C++11; before its
*** 290,339 ****
  referred to as C++0x.  C++11 contains several changes to the C++
  language, all of which have been implemented in GCC.  For details see
  .  To select this
! standard in GCC, use the option '-std=c++11'.
  
   Another revised ISO C++ standard was published in 2014 as ISO/IEC
  14882:2014, and is referred to as C++14; before its publication it was
  sometimes referred to as C++1y.  C++14 contains several further changes
  to the C++ language, all of which have been implemented in GCC.  For
  details see .  To
! select this standard in GCC, use the option '-std=c++14'.
  
   The C++ language was further revised in 2017 and ISO/IEC 14882:2017 was
  published.  This is referred to as C++17, and before publication was
  often referred to as C++1z.  GCC supports all the changes in that
  specification.  For further details see
  .  Use the option
! '-std=c++17' to select this variant of C++.
  
   Another revised ISO C++ standard was published in 2020 as ISO/IEC
  14882:2020, and is referred to as C++20; before its publication it was
  sometimes referred to as C++2a.  GCC supports most of the changes in the
  new specification.  For further details see
  .  To select this
! standard in GCC, use the option '-std=c++20'.
  
   More information about the C++ standards is available on the ISO C++
  committee's web site at .
  
   To obtain all the diagnostics required by any of the standard versions
! described above you should specify '-pedantic' or '-pedantic-errors',
  otherwise GCC will allow some non-ISO C++ features as extensions.  *Note
  Warning Options::.
  
   By default, GCC also provides some additional extensions to the C++
  language that on rare occasions conflict with the C++ standard.  *Note
! Options Controlling C++ Dialect: C++ Dialect Options.  Use of the '-std'
  options listed above disables these extensions where they they conflict
  with the C++ standard version selected.  You may also select an extended
! version of the C++ language explicitly with '-std=gnu++98' (for C++98
! with GNU extensions), or '-std=gnu++11' (for C++11 with GNU extensions),
! or '-std=gnu++14' (for C++14 with GNU extensions), or '-std=gnu++17'
! (for C++17 with GNU extensions), or '-std=gnu++20' (for C++20 with GNU
  extensions).
  
   The default, if no C++ language dialect options are given, is
! '-std=gnu++17'.
  
  2.3 Objective-C and Objective-C++ Languages
  ===========================================
--- 290,339 ----
  referred to as C++0x.  C++11 contains several changes to the C++
  language, all of which have been implemented in GCC.  For details see
  .  To select this
! standard in GCC, use the option ‘-std=c++11’.
  
   Another revised ISO C++ standard was published in 2014 as ISO/IEC
  14882:2014, and is referred to as C++14; before its publication it was
  sometimes referred to as C++1y.  C++14 contains several further changes
  to the C++ language, all of which have been implemented in GCC.  For
  details see .  To
! select this standard in GCC, use the option ‘-std=c++14’.
  
   The C++ language was further revised in 2017 and ISO/IEC 14882:2017 was
  published.  This is referred to as C++17, and before publication was
  often referred to as C++1z.  GCC supports all the changes in that
  specification.  For further details see
  .  Use the option
! ‘-std=c++17’ to select this variant of C++.
  
   Another revised ISO C++ standard was published in 2020 as ISO/IEC
  14882:2020, and is referred to as C++20; before its publication it was
  sometimes referred to as C++2a.  GCC supports most of the changes in the
  new specification.  For further details see
  .  To select this
! standard in GCC, use the option ‘-std=c++20’.
  
   More information about the C++ standards is available on the ISO C++
  committee's web site at .
  
   To obtain all the diagnostics required by any of the standard versions
! described above you should specify ‘-pedantic’ or ‘-pedantic-errors’,
  otherwise GCC will allow some non-ISO C++ features as extensions.  *Note
  Warning Options::.
  
   By default, GCC also provides some additional extensions to the C++
  language that on rare occasions conflict with the C++ standard.  *Note
! Options Controlling C++ Dialect: C++ Dialect Options.  Use of the ‘-std’
  options listed above disables these extensions where they they conflict
  with the C++ standard version selected.  You may also select an extended
! version of the C++ language explicitly with ‘-std=gnu++98’ (for C++98
! with GNU extensions), or ‘-std=gnu++11’ (for C++11 with GNU extensions),
! or ‘-std=gnu++14’ (for C++14 with GNU extensions), or ‘-std=gnu++17’
! (for C++17 with GNU extensions), or ‘-std=gnu++20’ (for C++20 with GNU
  extensions).
  
   The default, if no C++ language dialect options are given, is
! ‘-std=gnu++17’.
  
  2.3 Objective-C and Objective-C++ Languages
  ===========================================
*************** Objective-C are also available in Object
*** 349,355 ****
   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.
--- 349,355 ----
   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.
*************** The authoritative manual on traditional
*** 361,386 ****
  the original NeXTstep document.
  
   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:
!    * 
       
  
   For more information concerning the history of Objective-C that is
--- 361,386 ----
  the original NeXTstep document.
  
   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:
!    • 
       
  
   For more information concerning the history of Objective-C that is
*************** File: gcc.info,  Node: Invoking GCC,  Ne
*** 416,422 ****
  
  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.  *Note Options Controlling the Kind of Output: Overall
  Options.
--- 416,422 ----
  
  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.  *Note Options Controlling the Kind of Output: Overall
  Options.
*************** for C programs; when an option is only u
*** 432,470 ****
  for a particular option does not mention a source language, you can use
  that option with all supported languages.
  
!  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
  specific version of GCC. When you compile C++ programs, you should
! invoke GCC as 'g++' instead.  *Note Compiling C++ Programs: Invoking
! G++, for information about the differences in behavior between 'gcc' and
! 'g++' when compiling C++ programs.
  
!  The 'gcc' program accepts options and file names as operands.  Many
  options have multi-letter names; therefore multiple single-letter
! options may _not_ be grouped: '-dv' is very different from '-d -v'.
  
   You can mix options and other arguments.  For the most part, the order
  you use doesn't matter.  Order does matter when you use several options
! of the same kind; for example, if you specify '-L' more than once, the
  directories are searched in the order specified.  Also, the placement of
! the '-l' option is significant.
  
!  Many options have long names starting with '-f' or with '-W'--for
! example, '-fmove-loop-invariants', '-Wformat' and so on.  Most of these
! have both positive and negative forms; the negative form of '-ffoo' is
! '-fno-foo'.  This manual documents only one of these two forms,
  whichever one is not the default.
  
   Some options take one or more arguments typically separated either by a
! space or by the equals sign ('=') from the option name.  Unless
  documented otherwise, an argument can be either numeric or a string.
  Numeric arguments must typically be small unsigned decimal or
! hexadecimal integers.  Hexadecimal arguments must begin with the '0x'
  prefix.  Arguments to options that specify a size threshold of some sort
  may be arbitrarily large decimal or hexadecimal integers followed by a
! byte size suffix designating a multiple of bytes such as 'kB' and 'KiB'
! for kilobyte and kibibyte, respectively, 'MB' and 'MiB' for megabyte and
! mebibyte, 'GB' and 'GiB' for gigabyte and gigibyte, and so on.  Such
  arguments are designated by BYTE-SIZE in the following text.  Refer to
  the NIST, IEC, and other relevant national and international standards
  for the full listing and explanation of the binary and decimal byte size
--- 432,470 ----
  for a particular option does not mention a source language, you can use
  that option with all supported languages.
  
!  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
  specific version of GCC. When you compile C++ programs, you should
! invoke GCC as ‘g++’ instead.  *Note Compiling C++ Programs: Invoking
! G++, for information about the differences in behavior between ‘gcc’ and
! ‘g++’ when compiling C++ programs.
  
!  The ‘gcc’ program accepts options and file names as operands.  Many
  options have multi-letter names; therefore multiple single-letter
! options may _not_ be grouped: ‘-dv’ is very different from ‘-d -v’.
  
   You can mix options and other arguments.  For the most part, the order
  you use doesn't matter.  Order does matter when you use several options
! of the same kind; for example, if you specify ‘-L’ more than once, the
  directories are searched in the order specified.  Also, the placement of
! the ‘-l’ option is significant.
  
!  Many options have long names starting with ‘-f’ or with ‘-W’--for
! example, ‘-fmove-loop-invariants’, ‘-Wformat’ and so on.  Most of these
! have both positive and negative forms; the negative form of ‘-ffoo’ is
! ‘-fno-foo’.  This manual documents only one of these two forms,
  whichever one is not the default.
  
   Some options take one or more arguments typically separated either by a
! space or by the equals sign (‘=’) from the option name.  Unless
  documented otherwise, an argument can be either numeric or a string.
  Numeric arguments must typically be small unsigned decimal or
! hexadecimal integers.  Hexadecimal arguments must begin with the ‘0x’
  prefix.  Arguments to options that specify a size threshold of some sort
  may be arbitrarily large decimal or hexadecimal integers followed by a
! byte size suffix designating a multiple of bytes such as ‘kB’ and ‘KiB’
! for kilobyte and kibibyte, respectively, ‘MB’ and ‘MiB’ for megabyte and
! mebibyte, ‘GB’ and ‘GiB’ for gigabyte and gigibyte, and so on.  Such
  arguments are designated by BYTE-SIZE in the following text.  Refer to
  the NIST, IEC, and other relevant national and international standards
  for the full listing and explanation of the binary and decimal byte size
*************** file.
*** 1823,2015 ****
   For any given input file, the file name suffix determines what kind of
  compilation is done:
  
! 'FILE.c'
       C source code that must be preprocessed.
  
! 'FILE.i'
       C source code that should not be preprocessed.
  
! 'FILE.ii'
       C++ source code that should not be preprocessed.
  
! 'FILE.m'
       Objective-C source code.  Note that you must link with the
!      'libobjc' library to make an Objective-C program work.
  
! 'FILE.mi'
       Objective-C source code that should not be preprocessed.
  
! 'FILE.mm'
! 'FILE.M'
       Objective-C++ source code.  Note that you must link with the
!      'libobjc' library to make an Objective-C++ program work.  Note that
!      '.M' refers to a literal capital M.
  
! 'FILE.mii'
       Objective-C++ source code that should not be preprocessed.
  
! 'FILE.h'
       C, C++, Objective-C or Objective-C++ header file to be turned into
       a precompiled header (default), or C, C++ header file to be turned
!      into an Ada spec (via the '-fdump-ada-spec' switch).
  
! 'FILE.cc'
! 'FILE.cp'
! 'FILE.cxx'
! 'FILE.cpp'
! 'FILE.CPP'
! 'FILE.c++'
! 'FILE.C'
!      C++ source code that must be preprocessed.  Note that in '.cxx',
!      the last two letters must both be literally 'x'.  Likewise, '.C'
       refers to a literal capital C.
  
! 'FILE.mm'
! 'FILE.M'
       Objective-C++ source code that must be preprocessed.
  
! 'FILE.mii'
       Objective-C++ source code that should not be preprocessed.
  
! 'FILE.hh'
! 'FILE.H'
! 'FILE.hp'
! 'FILE.hxx'
! 'FILE.hpp'
! 'FILE.HPP'
! 'FILE.h++'
! 'FILE.tcc'
       C++ header file to be turned into a precompiled header or Ada spec.
  
! 'FILE.f'
! 'FILE.for'
! 'FILE.ftn'
       Fixed form Fortran source code that should not be preprocessed.
  
! 'FILE.F'
! 'FILE.FOR'
! 'FILE.fpp'
! 'FILE.FPP'
! 'FILE.FTN'
       Fixed form Fortran source code that must be preprocessed (with the
       traditional preprocessor).
  
! 'FILE.f90'
! 'FILE.f95'
! 'FILE.f03'
! 'FILE.f08'
       Free form Fortran source code that should not be preprocessed.
  
! 'FILE.F90'
! 'FILE.F95'
! 'FILE.F03'
! 'FILE.F08'
       Free form Fortran source code that must be preprocessed (with the
       traditional preprocessor).
  
! 'FILE.go'
       Go source code.
  
! 'FILE.d'
       D source code.
  
! 'FILE.di'
       D interface file.
  
! 'FILE.dd'
       D documentation code (Ddoc).
  
! 'FILE.ads'
       Ada source code file that contains a library unit declaration (a
       declaration of a package, subprogram, or generic, or a generic
       instantiation), or a library unit renaming declaration (a package,
       generic, or subprogram renaming declaration).  Such files are also
!      called "specs".
  
! 'FILE.adb'
       Ada source code file containing a library unit body (a subprogram
!      or package body).  Such files are also called "bodies".
  
! 'FILE.s'
       Assembler code.
  
! 'FILE.S'
! 'FILE.sx'
       Assembler code that must be preprocessed.
  
! 'OTHER'
       An object file to be fed straight into linking.  Any file name with
       no recognized suffix is treated this way.
  
!  You can specify the input language explicitly with the '-x' option:
  
! '-x LANGUAGE'
       Specify explicitly the LANGUAGE for the following input files
       (rather than letting the compiler choose a default based on the
       file name suffix).  This option applies to all following input
!      files until the next '-x' option.  Possible values for LANGUAGE
       are:
            c  c-header  cpp-output
            c++  c++-header  c++-system-header c++-user-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
            d
!           f77  f77-cpp-input f95  f95-cpp-input
            go
  
! '-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).
  
!  If you only want some of the stages of compilation, you can use '-x'
! (or filename suffixes) to tell 'gcc' where to start, and one of the
! options '-c', '-S', or '-E' to say where 'gcc' is to stop.  Note that
! some combinations (for example, '-x cpp-output -E') instruct 'gcc' to do
  nothing at all.
  
! '-c'
       Compile or assemble the source files, but do not link.  The linking
       stage simply is not done.  The ultimate output is in the form of an
       object file for each source file.
  
       By default, the object file name for a source file is made by
!      replacing the suffix '.c', '.i', '.s', etc., with '.o'.
  
       Unrecognized input files, not requiring compilation or assembly,
       are ignored.
  
! '-S'
       Stop after the stage of compilation proper; do not assemble.  The
       output is in the form of an assembler code file for each
       non-assembler input file specified.
  
       By default, the assembler file name for a source file is made by
!      replacing the suffix '.c', '.i', etc., with '.s'.
  
       Input files that don't require compilation are ignored.
  
! '-E'
       Stop after the preprocessing stage; do not run the compiler proper.
       The output is in the form of preprocessed source code, which is
       sent to the standard output.
  
       Input files that don't require preprocessing are ignored.
  
! '-o FILE'
       Place the primary output in file FILE.  This applies to whatever
       sort of output is being produced, whether it be an executable file,
       an object file, an assembler file or preprocessed C code.
  
!      If '-o' is not specified, the default is to put an executable file
!      in 'a.out', the object file for 'SOURCE.SUFFIX' in 'SOURCE.o', its
!      assembler file in 'SOURCE.s', a precompiled header file in
!      'SOURCE.SUFFIX.gch', and all preprocessed C source on standard
       output.
  
!      Though '-o' names only the primary output, it also affects the
       naming of auxiliary and dump outputs.  See the examples below.
       Unless overridden, both auxiliary outputs and dump outputs are
       placed in the same directory as the primary output.  In auxiliary
--- 1823,2019 ----
   For any given input file, the file name suffix determines what kind of
  compilation is done:
  
! ‘FILE.c’
       C source code that must be preprocessed.
  
! ‘FILE.i’
       C source code that should not be preprocessed.
  
! ‘FILE.ii’
       C++ source code that should not be preprocessed.
  
! ‘FILE.m’
       Objective-C source code.  Note that you must link with the
!      ‘libobjc’ library to make an Objective-C program work.
  
! ‘FILE.mi’
       Objective-C source code that should not be preprocessed.
  
! ‘FILE.mm’
! ‘FILE.M’
       Objective-C++ source code.  Note that you must link with the
!      ‘libobjc’ library to make an Objective-C++ program work.  Note that
!      ‘.M’ refers to a literal capital M.
  
! ‘FILE.mii’
       Objective-C++ source code that should not be preprocessed.
  
! ‘FILE.h’
       C, C++, Objective-C or Objective-C++ header file to be turned into
       a precompiled header (default), or C, C++ header file to be turned
!      into an Ada spec (via the ‘-fdump-ada-spec’ switch).
  
! ‘FILE.cc’
! ‘FILE.cp’
! ‘FILE.cxx’
! ‘FILE.cpp’
! ‘FILE.CPP’
! ‘FILE.c++’
! ‘FILE.C’
!      C++ source code that must be preprocessed.  Note that in ‘.cxx’,
!      the last two letters must both be literally ‘x’.  Likewise, ‘.C’
       refers to a literal capital C.
  
! ‘FILE.mm’
! ‘FILE.M’
       Objective-C++ source code that must be preprocessed.
  
! ‘FILE.mii’
       Objective-C++ source code that should not be preprocessed.
  
! ‘FILE.hh’
! ‘FILE.H’
! ‘FILE.hp’
! ‘FILE.hxx’
! ‘FILE.hpp’
! ‘FILE.HPP’
! ‘FILE.h++’
! ‘FILE.tcc’
       C++ header file to be turned into a precompiled header or Ada spec.
  
! ‘FILE.f’
! ‘FILE.for’
! ‘FILE.ftn’
       Fixed form Fortran source code that should not be preprocessed.
  
! ‘FILE.F’
! ‘FILE.FOR’
! ‘FILE.fpp’
! ‘FILE.FPP’
! ‘FILE.FTN’
       Fixed form Fortran source code that must be preprocessed (with the
       traditional preprocessor).
  
! ‘FILE.f90’
! ‘FILE.f95’
! ‘FILE.f03’
! ‘FILE.f08’
       Free form Fortran source code that should not be preprocessed.
  
! ‘FILE.F90’
! ‘FILE.F95’
! ‘FILE.F03’
! ‘FILE.F08’
       Free form Fortran source code that must be preprocessed (with the
       traditional preprocessor).
  
! ‘FILE.go’
       Go source code.
  
! ‘FILE.d’
       D source code.
  
! ‘FILE.di’
       D interface file.
  
! ‘FILE.dd’
       D documentation code (Ddoc).
  
! ‘FILE.ads’
       Ada source code file that contains a library unit declaration (a
       declaration of a package, subprogram, or generic, or a generic
       instantiation), or a library unit renaming declaration (a package,
       generic, or subprogram renaming declaration).  Such files are also
!      called “specs”.
  
! ‘FILE.adb’
       Ada source code file containing a library unit body (a subprogram
!      or package body).  Such files are also called “bodies”.
  
! ‘FILE.s’
       Assembler code.
  
! ‘FILE.S’
! ‘FILE.sx’
       Assembler code that must be preprocessed.
  
! ‘OTHER’
       An object file to be fed straight into linking.  Any file name with
       no recognized suffix is treated this way.
  
!  You can specify the input language explicitly with the ‘-x’ option:
  
! ‘-x LANGUAGE’
       Specify explicitly the LANGUAGE for the following input files
       (rather than letting the compiler choose a default based on the
       file name suffix).  This option applies to all following input
!      files until the next ‘-x’ option.  Possible values for LANGUAGE
       are:
            c  c-header  cpp-output
            c++  c++-header  c++-system-header c++-user-header c++-cpp-output
!           objective-c  objective-c-header  objective-c-cpp-output  objc-cpp-output
!           objective-c++  objective-c++-header  objective-c++-cpp-output
!           objc++-cpp-output
            assembler  assembler-with-cpp
!           ada  adascil  adawhy
            d
!           f77  f77-cpp-input  f95  f95-cpp-input
            go
+           modula-2  modula-2-cpp-output
+           rust
+           lto
  
! ‘-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).
  
!  If you only want some of the stages of compilation, you can use ‘-x’
! (or filename suffixes) to tell ‘gcc’ where to start, and one of the
! options ‘-c’, ‘-S’, or ‘-E’ to say where ‘gcc’ is to stop.  Note that
! some combinations (for example, ‘-x cpp-output -E’) instruct ‘gcc’ to do
  nothing at all.
  
! ‘-c’
       Compile or assemble the source files, but do not link.  The linking
       stage simply is not done.  The ultimate output is in the form of an
       object file for each source file.
  
       By default, the object file name for a source file is made by
!      replacing the suffix ‘.c’, ‘.i’, ‘.s’, etc., with ‘.o’.
  
       Unrecognized input files, not requiring compilation or assembly,
       are ignored.
  
! ‘-S’
       Stop after the stage of compilation proper; do not assemble.  The
       output is in the form of an assembler code file for each
       non-assembler input file specified.
  
       By default, the assembler file name for a source file is made by
!      replacing the suffix ‘.c’, ‘.i’, etc., with ‘.s’.
  
       Input files that don't require compilation are ignored.
  
! ‘-E’
       Stop after the preprocessing stage; do not run the compiler proper.
       The output is in the form of preprocessed source code, which is
       sent to the standard output.
  
       Input files that don't require preprocessing are ignored.
  
! ‘-o FILE’
       Place the primary output in file FILE.  This applies to whatever
       sort of output is being produced, whether it be an executable file,
       an object file, an assembler file or preprocessed C code.
  
!      If ‘-o’ is not specified, the default is to put an executable file
!      in ‘a.out’, the object file for ‘SOURCE.SUFFIX’ in ‘SOURCE.o’, its
!      assembler file in ‘SOURCE.s’, a precompiled header file in
!      ‘SOURCE.SUFFIX.gch’, and all preprocessed C source on standard
       output.
  
!      Though ‘-o’ names only the primary output, it also affects the
       naming of auxiliary and dump outputs.  See the examples below.
       Unless overridden, both auxiliary outputs and dump outputs are
       placed in the same directory as the primary output.  In auxiliary
*************** nothing at all.
*** 2025,2063 ****
  
            gcc -c foo.c ...
  
!      will use 'foo.o' as the primary output, and place aux outputs and
!      dumps next to it, e.g., aux file 'foo.dwo' for '-gsplit-dwarf', and
!      dump file 'foo.c.???r.final' for '-fdump-rtl-final'.
  
       If a non-linker output file is explicitly specified, aux and dump
       files by default take the same base name:
  
            gcc -c foo.c -o dir/foobar.o ...
  
!      will name aux outputs 'dir/foobar.*' and dump outputs
!      'dir/foobar.c.*'.
  
       A linker output will instead prefix aux and dump outputs:
  
            gcc foo.c bar.c -o dir/foobar ...
  
!      will generally name aux outputs 'dir/foobar-foo.*' and
!      'dir/foobar-bar.*', and dump outputs 'dir/foobar-foo.c.*' and
!      'dir/foobar-bar.c.*'.
  
       The one exception to the above is when the executable shares the
       base name with the single input:
  
            gcc foo.c -o dir/foo ...
  
!      in which case aux outputs are named 'dir/foo.*' and dump outputs
!      named 'dir/foo.c.*'.
  
       The location and the names of auxiliary and dump outputs can be
!      adjusted by the options '-dumpbase', '-dumpbase-ext', '-dumpdir',
!      '-save-temps=cwd', and '-save-temps=obj'.
  
! '-dumpbase DUMPBASE'
       This option sets the base name for auxiliary and dump output files.
       It does not affect the name of the primary output file.
       Intermediate outputs, when preserved, are not regarded as primary
--- 2029,2067 ----
  
            gcc -c foo.c ...
  
!      will use ‘foo.o’ as the primary output, and place aux outputs and
!      dumps next to it, e.g., aux file ‘foo.dwo’ for ‘-gsplit-dwarf’, and
!      dump file ‘foo.c.???r.final’ for ‘-fdump-rtl-final’.
  
       If a non-linker output file is explicitly specified, aux and dump
       files by default take the same base name:
  
            gcc -c foo.c -o dir/foobar.o ...
  
!      will name aux outputs ‘dir/foobar.*’ and dump outputs
!      ‘dir/foobar.c.*’.
  
       A linker output will instead prefix aux and dump outputs:
  
            gcc foo.c bar.c -o dir/foobar ...
  
!      will generally name aux outputs ‘dir/foobar-foo.*’ and
!      ‘dir/foobar-bar.*’, and dump outputs ‘dir/foobar-foo.c.*’ and
!      ‘dir/foobar-bar.c.*’.
  
       The one exception to the above is when the executable shares the
       base name with the single input:
  
            gcc foo.c -o dir/foo ...
  
!      in which case aux outputs are named ‘dir/foo.*’ and dump outputs
!      named ‘dir/foo.c.*’.
  
       The location and the names of auxiliary and dump outputs can be
!      adjusted by the options ‘-dumpbase’, ‘-dumpbase-ext’, ‘-dumpdir’,
!      ‘-save-temps=cwd’, and ‘-save-temps=obj’.
  
! ‘-dumpbase DUMPBASE’
       This option sets the base name for auxiliary and dump output files.
       It does not affect the name of the primary output file.
       Intermediate outputs, when preserved, are not regarded as primary
*************** nothing at all.
*** 2065,2114 ****
  
            gcc -save-temps -S foo.c
  
!      saves the (no longer) temporary preprocessed file in 'foo.i', and
!      then compiles to the (implied) output file 'foo.s', whereas:
  
            gcc -save-temps -dumpbase save-foo -c foo.c
  
!      preprocesses to in 'save-foo.i', compiles to 'save-foo.s' (now an
       intermediate, thus auxiliary output), and then assembles to the
!      (implied) output file 'foo.o'.
  
       Absent this option, dump and aux files take their names from the
       input file, or from the (non-linker) output file, if one is
       explicitly specified: dump output files (e.g.  those requested by
!      '-fdump-*' options) with the input name suffix, and aux output
       files (those requested by other non-dump options, e.g.
!      '-save-temps', '-gsplit-dwarf', '-fcallgraph-info') without it.
  
       Similar suffix differentiation of dump and aux outputs can be
!      attained for explicitly-given '-dumpbase basename.suf' by also
!      specifying '-dumpbase-ext .suf'.
  
       If DUMPBASE is explicitly specified with any directory component,
!      any DUMPPFX specification (e.g.  '-dumpdir' or '-save-temps=*') is
       ignored, and instead of appending to it, DUMPBASE fully overrides
       it:
  
            gcc foo.c -c -o dir/foo.o -dumpbase alt/foo \
              -dumpdir pfx- -save-temps=cwd ...
  
!      creates auxiliary and dump outputs named 'alt/foo.*', disregarding
!      'dir/' in '-o', the './' prefix implied by '-save-temps=cwd', and
!      'pfx-' in '-dumpdir'.
  
!      When '-dumpbase' is specified in a command that compiles multiple
       inputs, or that compiles and then links, it may be combined with
!      DUMPPFX, as specified under '-dumpdir'.  Then, each input file is
       compiled using the combined DUMPPFX, and default values for
       DUMPBASE and AUXDROPSUF are computed for each input file:
  
            gcc foo.c bar.c -c -dumpbase main ...
  
!      creates 'foo.o' and 'bar.o' as primary outputs, and avoids
       overwriting the auxiliary and dump outputs by using the DUMPBASE as
!      a prefix, creating auxiliary and dump outputs named 'main-foo.*'
!      and 'main-bar.*'.
  
       An empty string specified as DUMPBASE avoids the influence of the
       output basename in the naming of auxiliary and dump outputs during
--- 2069,2118 ----
  
            gcc -save-temps -S foo.c
  
!      saves the (no longer) temporary preprocessed file in ‘foo.i’, and
!      then compiles to the (implied) output file ‘foo.s’, whereas:
  
            gcc -save-temps -dumpbase save-foo -c foo.c
  
!      preprocesses to in ‘save-foo.i’, compiles to ‘save-foo.s’ (now an
       intermediate, thus auxiliary output), and then assembles to the
!      (implied) output file ‘foo.o’.
  
       Absent this option, dump and aux files take their names from the
       input file, or from the (non-linker) output file, if one is
       explicitly specified: dump output files (e.g.  those requested by
!      ‘-fdump-*’ options) with the input name suffix, and aux output
       files (those requested by other non-dump options, e.g.
!      ‘-save-temps’, ‘-gsplit-dwarf’, ‘-fcallgraph-info’) without it.
  
       Similar suffix differentiation of dump and aux outputs can be
!      attained for explicitly-given ‘-dumpbase basename.suf’ by also
!      specifying ‘-dumpbase-ext .suf’.
  
       If DUMPBASE is explicitly specified with any directory component,
!      any DUMPPFX specification (e.g.  ‘-dumpdir’ or ‘-save-temps=*’) is
       ignored, and instead of appending to it, DUMPBASE fully overrides
       it:
  
            gcc foo.c -c -o dir/foo.o -dumpbase alt/foo \
              -dumpdir pfx- -save-temps=cwd ...
  
!      creates auxiliary and dump outputs named ‘alt/foo.*’, disregarding
!      ‘dir/’ in ‘-o’, the ‘./’ prefix implied by ‘-save-temps=cwd’, and
!      ‘pfx-’ in ‘-dumpdir’.
  
!      When ‘-dumpbase’ is specified in a command that compiles multiple
       inputs, or that compiles and then links, it may be combined with
!      DUMPPFX, as specified under ‘-dumpdir’.  Then, each input file is
       compiled using the combined DUMPPFX, and default values for
       DUMPBASE and AUXDROPSUF are computed for each input file:
  
            gcc foo.c bar.c -c -dumpbase main ...
  
!      creates ‘foo.o’ and ‘bar.o’ as primary outputs, and avoids
       overwriting the auxiliary and dump outputs by using the DUMPBASE as
!      a prefix, creating auxiliary and dump outputs named ‘main-foo.*’
!      and ‘main-bar.*’.
  
       An empty string specified as DUMPBASE avoids the influence of the
       output basename in the naming of auxiliary and dump outputs during
*************** nothing at all.
*** 2116,2122 ****
  
            gcc -c foo.c -o dir/foobar.o -dumpbase '' ...
  
!      will name aux outputs 'dir/foo.*' and dump outputs 'dir/foo.c.*'.
       Note how their basenames are taken from the input name, but the
       directory still defaults to that of the output.
  
--- 2120,2126 ----
  
            gcc -c foo.c -o dir/foobar.o -dumpbase '' ...
  
!      will name aux outputs ‘dir/foo.*’ and dump outputs ‘dir/foo.c.*’.
       Note how their basenames are taken from the input name, but the
       directory still defaults to that of the output.
  
*************** nothing at all.
*** 2126,2149 ****
            gcc foo.c bar.c -o dir/foobar -dumpbase '' -flto ...
  
       The compilation of the source files will name auxiliary outputs
!      'dir/foo.*' and 'dir/bar.*', and dump outputs 'dir/foo.c.*' and
!      'dir/bar.c.*'.  LTO recompilation during linking will use
!      'dir/foobar.' as the prefix for dumps and auxiliary files.
  
! '-dumpbase-ext AUXDROPSUF'
       When forming the name of an auxiliary (but not a dump) output file,
       drop trailing AUXDROPSUF from DUMPBASE before appending any
       suffixes.  If not specified, this option defaults to the suffix of
       a default DUMPBASE, i.e., the suffix of the input file when
!      '-dumpbase' is not present in the command line, or DUMPBASE is
       combined with DUMPPFX.
  
            gcc foo.c -c -o dir/foo.o -dumpbase x-foo.c -dumpbase-ext .c ...
  
!      creates 'dir/foo.o' as the main output, and generates auxiliary
!      outputs in 'dir/x-foo.*', taking the location of the primary
!      output, and dropping the '.c' suffix from the DUMPBASE.  Dump
!      outputs retain the suffix: 'dir/x-foo.c.*'.
  
       This option is disregarded if it does not match the suffix of a
       specified DUMPBASE, except as an alternative to the executable
--- 2130,2153 ----
            gcc foo.c bar.c -o dir/foobar -dumpbase '' -flto ...
  
       The compilation of the source files will name auxiliary outputs
!      ‘dir/foo.*’ and ‘dir/bar.*’, and dump outputs ‘dir/foo.c.*’ and
!      ‘dir/bar.c.*’.  LTO recompilation during linking will use
!      ‘dir/foobar.’ as the prefix for dumps and auxiliary files.
  
! ‘-dumpbase-ext AUXDROPSUF’
       When forming the name of an auxiliary (but not a dump) output file,
       drop trailing AUXDROPSUF from DUMPBASE before appending any
       suffixes.  If not specified, this option defaults to the suffix of
       a default DUMPBASE, i.e., the suffix of the input file when
!      ‘-dumpbase’ is not present in the command line, or DUMPBASE is
       combined with DUMPPFX.
  
            gcc foo.c -c -o dir/foo.o -dumpbase x-foo.c -dumpbase-ext .c ...
  
!      creates ‘dir/foo.o’ as the main output, and generates auxiliary
!      outputs in ‘dir/x-foo.*’, taking the location of the primary
!      output, and dropping the ‘.c’ suffix from the DUMPBASE.  Dump
!      outputs retain the suffix: ‘dir/x-foo.c.*’.
  
       This option is disregarded if it does not match the suffix of a
       specified DUMPBASE, except as an alternative to the executable
*************** nothing at all.
*** 2152,2200 ****
  
            gcc foo.c bar.c -o main.out -dumpbase-ext .out ...
  
!      creates 'main.out' as the primary output, and avoids overwriting
       the auxiliary and dump outputs by using the executable name minus
       AUXDROPSUF as a prefix, creating auxiliary outputs named
!      'main-foo.*' and 'main-bar.*' and dump outputs named 'main-foo.c.*'
!      and 'main-bar.c.*'.
  
! '-dumpdir DUMPPFX'
       When forming the name of an auxiliary or dump output file, use
       DUMPPFX as a prefix:
  
            gcc -dumpdir pfx- -c foo.c ...
  
!      creates 'foo.o' as the primary output, and auxiliary outputs named
!      'pfx-foo.*', combining the given DUMPPFX with the default DUMPBASE
       derived from the default primary output, derived in turn from the
       input name.  Dump outputs also take the input name suffix:
!      'pfx-foo.c.*'.
  
       If DUMPPFX is to be used as a directory name, it must end with a
       directory separator:
  
            gcc -dumpdir dir/ -c foo.c -o obj/bar.o ...
  
!      creates 'obj/bar.o' as the primary output, and auxiliary outputs
!      named 'dir/bar.*', combining the given DUMPPFX with the default
       DUMPBASE derived from the primary output name.  Dump outputs also
!      take the input name suffix: 'dir/bar.c.*'.
  
       It defaults to the location of the output file, unless the output
!      file is a special file like '/dev/null'.  Options '-save-temps=cwd'
!      and '-save-temps=obj' override this default, just like an explicit
!      '-dumpdir' option.  In case multiple such options are given, the
       last one prevails:
  
            gcc -dumpdir pfx- -c foo.c -save-temps=obj ...
  
!      outputs 'foo.o', with auxiliary outputs named 'foo.*' because
!      '-save-temps=*' overrides the DUMPPFX given by the earlier
!      '-dumpdir' option.  It does not matter that '=obj' is the default
!      for '-save-temps', nor that the output directory is implicitly the
!      current directory.  Dump outputs are named 'foo.c.*'.
  
!      When compiling from multiple input files, if '-dumpbase' is
       specified, DUMPBASE, minus a AUXDROPSUF suffix, and a dash are
       appended to (or override, if containing any directory components)
       an explicit or defaulted DUMPPFX, so that each of the multiple
--- 2156,2204 ----
  
            gcc foo.c bar.c -o main.out -dumpbase-ext .out ...
  
!      creates ‘main.out’ as the primary output, and avoids overwriting
       the auxiliary and dump outputs by using the executable name minus
       AUXDROPSUF as a prefix, creating auxiliary outputs named
!      ‘main-foo.*’ and ‘main-bar.*’ and dump outputs named ‘main-foo.c.*’
!      and ‘main-bar.c.*’.
  
! ‘-dumpdir DUMPPFX’
       When forming the name of an auxiliary or dump output file, use
       DUMPPFX as a prefix:
  
            gcc -dumpdir pfx- -c foo.c ...
  
!      creates ‘foo.o’ as the primary output, and auxiliary outputs named
!      ‘pfx-foo.*’, combining the given DUMPPFX with the default DUMPBASE
       derived from the default primary output, derived in turn from the
       input name.  Dump outputs also take the input name suffix:
!      ‘pfx-foo.c.*’.
  
       If DUMPPFX is to be used as a directory name, it must end with a
       directory separator:
  
            gcc -dumpdir dir/ -c foo.c -o obj/bar.o ...
  
!      creates ‘obj/bar.o’ as the primary output, and auxiliary outputs
!      named ‘dir/bar.*’, combining the given DUMPPFX with the default
       DUMPBASE derived from the primary output name.  Dump outputs also
!      take the input name suffix: ‘dir/bar.c.*’.
  
       It defaults to the location of the output file, unless the output
!      file is a special file like ‘/dev/null’.  Options ‘-save-temps=cwd’
!      and ‘-save-temps=obj’ override this default, just like an explicit
!      ‘-dumpdir’ option.  In case multiple such options are given, the
       last one prevails:
  
            gcc -dumpdir pfx- -c foo.c -save-temps=obj ...
  
!      outputs ‘foo.o’, with auxiliary outputs named ‘foo.*’ because
!      ‘-save-temps=*’ overrides the DUMPPFX given by the earlier
!      ‘-dumpdir’ option.  It does not matter that ‘=obj’ is the default
!      for ‘-save-temps’, nor that the output directory is implicitly the
!      current directory.  Dump outputs are named ‘foo.c.*’.
  
!      When compiling from multiple input files, if ‘-dumpbase’ is
       specified, DUMPBASE, minus a AUXDROPSUF suffix, and a dash are
       appended to (or override, if containing any directory components)
       an explicit or defaulted DUMPPFX, so that each of the multiple
*************** nothing at all.
*** 2202,2255 ****
  
            gcc foo.c bar.c -c -dumpdir dir/pfx- -dumpbase main ...
  
!      outputs auxiliary dumps to 'dir/pfx-main-foo.*' and
!      'dir/pfx-main-bar.*', appending DUMPBASE- to DUMPPFX.  Dump outputs
!      retain the input file suffix: 'dir/pfx-main-foo.c.*' and
!      'dir/pfx-main-bar.c.*', respectively.  Contrast with the
       single-input compilation:
  
            gcc foo.c -c -dumpdir dir/pfx- -dumpbase main ...
  
!      that, applying '-dumpbase' to a single source, does not compute and
       append a separate DUMPBASE per input file.  Its auxiliary and dump
!      outputs go in 'dir/pfx-main.*'.
  
       When compiling and then linking from multiple input files, a
       defaulted or explicitly specified DUMPPFX also undergoes the
!      DUMPBASE- transformation above (e.g.  the compilation of 'foo.c'
!      and 'bar.c' above, but without '-c').  If neither '-dumpdir' nor
!      '-dumpbase' are given, the linker output base name, minus
       AUXDROPSUF, if specified, or the executable suffix otherwise, plus
       a dash is appended to the default DUMPPFX instead.  Note, however,
       that unlike earlier cases of linking:
  
            gcc foo.c bar.c -dumpdir dir/pfx- -o main ...
  
!      does not append the output name 'main' to DUMPPFX, because
!      '-dumpdir' is explicitly specified.  The goal is that the
       explicitly-specified DUMPPFX may contain the specified output name
       as part of the prefix, if desired; only an explicitly-specified
!      '-dumpbase' would be combined with it, in order to avoid simply
       discarding a meaningful option.
  
       When compiling and then linking from a single input file, the
       linker output base name will only be appended to the default
       DUMPPFX as above if it does not share the base name with the single
       input file name.  This has been covered in single-input linking
!      cases above, but not with an explicit '-dumpdir' that inhibits the
!      combination, even if overridden by '-save-temps=*':
  
            gcc foo.c -dumpdir alt/pfx- -o dir/main.exe -save-temps=cwd ...
  
!      Auxiliary outputs are named 'foo.*', and dump outputs 'foo.c.*', in
       the current working directory as ultimately requested by
!      '-save-temps=cwd'.
  
       Summing it all up for an intuitive though slightly imprecise data
       flow: the primary output name is broken into a directory part and a
       basename part; DUMPPFX is set to the former, unless overridden by
!      '-dumpdir' or '-save-temps=*', and DUMPBASE is set to the latter,
!      unless overriden by '-dumpbase'.  If there are multiple inputs or
       linking, this DUMPBASE may be combined with DUMPPFX and taken from
       each input file.  Auxiliary output names for each input are formed
       by combining DUMPPFX, DUMPBASE minus suffix, and the auxiliary
--- 2206,2259 ----
  
            gcc foo.c bar.c -c -dumpdir dir/pfx- -dumpbase main ...
  
!      outputs auxiliary dumps to ‘dir/pfx-main-foo.*’ and
!      ‘dir/pfx-main-bar.*’, appending DUMPBASE- to DUMPPFX.  Dump outputs
!      retain the input file suffix: ‘dir/pfx-main-foo.c.*’ and
!      ‘dir/pfx-main-bar.c.*’, respectively.  Contrast with the
       single-input compilation:
  
            gcc foo.c -c -dumpdir dir/pfx- -dumpbase main ...
  
!      that, applying ‘-dumpbase’ to a single source, does not compute and
       append a separate DUMPBASE per input file.  Its auxiliary and dump
!      outputs go in ‘dir/pfx-main.*’.
  
       When compiling and then linking from multiple input files, a
       defaulted or explicitly specified DUMPPFX also undergoes the
!      DUMPBASE- transformation above (e.g.  the compilation of ‘foo.c’
!      and ‘bar.c’ above, but without ‘-c’).  If neither ‘-dumpdir’ nor
!      ‘-dumpbase’ are given, the linker output base name, minus
       AUXDROPSUF, if specified, or the executable suffix otherwise, plus
       a dash is appended to the default DUMPPFX instead.  Note, however,
       that unlike earlier cases of linking:
  
            gcc foo.c bar.c -dumpdir dir/pfx- -o main ...
  
!      does not append the output name ‘main’ to DUMPPFX, because
!      ‘-dumpdir’ is explicitly specified.  The goal is that the
       explicitly-specified DUMPPFX may contain the specified output name
       as part of the prefix, if desired; only an explicitly-specified
!      ‘-dumpbase’ would be combined with it, in order to avoid simply
       discarding a meaningful option.
  
       When compiling and then linking from a single input file, the
       linker output base name will only be appended to the default
       DUMPPFX as above if it does not share the base name with the single
       input file name.  This has been covered in single-input linking
!      cases above, but not with an explicit ‘-dumpdir’ that inhibits the
!      combination, even if overridden by ‘-save-temps=*’:
  
            gcc foo.c -dumpdir alt/pfx- -o dir/main.exe -save-temps=cwd ...
  
!      Auxiliary outputs are named ‘foo.*’, and dump outputs ‘foo.c.*’, in
       the current working directory as ultimately requested by
!      ‘-save-temps=cwd’.
  
       Summing it all up for an intuitive though slightly imprecise data
       flow: the primary output name is broken into a directory part and a
       basename part; DUMPPFX is set to the former, unless overridden by
!      ‘-dumpdir’ or ‘-save-temps=*’, and DUMPBASE is set to the latter,
!      unless overriden by ‘-dumpbase’.  If there are multiple inputs or
       linking, this DUMPBASE may be combined with DUMPPFX and taken from
       each input file.  Auxiliary output names for each input are formed
       by combining DUMPPFX, DUMPBASE minus suffix, and the auxiliary
*************** nothing at all.
*** 2261,2346 ****
       as derived from the linker output name but not from inputs, even in
       cases in which this combination would not otherwise be used as
       such, is passed down with a trailing period replacing the
!      compiler-added dash, if any, as a '-dumpdir' option to
!      'lto-wrapper'; being involved in linking, this program does not
!      normally get any '-dumpbase' and '-dumpbase-ext', and it ignores
       them.
  
!      When running sub-compilers, 'lto-wrapper' appends LTO stage names
       to the received DUMPPFX, ensures it contains a directory component
!      so that it overrides any '-dumpdir', and passes that as '-dumpbase'
       to sub-compilers.
  
! '-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.
  
! '--help'
       Print (on the standard output) a description of the command-line
!      options understood by 'gcc'.  If the '-v' option is also specified
!      then '--help' is also passed on to the various processes invoked by
!      'gcc', so that they can display the command-line options they
!      accept.  If the '-Wextra' option has also been specified (prior to
!      the '--help' option), then command-line options that have no
       documentation associated with them are also displayed.
  
! '--target-help'
       Print (on the standard output) a description of target-specific
       command-line options for each tool.  For some targets extra
       target-specific information may also be printed.
  
! '--help={CLASS|[^]QUALIFIER}[,...]'
       Print (on the standard output) a description of the command-line
       options understood by the compiler that fit into all specified
       classes and qualifiers.  These are the supported classes:
  
!      'optimizers'
            Display all of the optimization options supported by the
            compiler.
  
!      'warnings'
            Display all of the options controlling warning messages
            produced by the compiler.
  
!      'target'
!           Display target-specific options.  Unlike the '--target-help'
            option however, target-specific options of the linker and
            assembler are not displayed.  This is because those tools do
!           not currently support the extended '--help=' syntax.
  
!      'params'
!           Display the values recognized by the '--param' option.
  
       LANGUAGE
            Display the options supported for LANGUAGE, where LANGUAGE is
            the name of one of the languages supported in this version of
            GCC.  If an option is supported by all languages, one needs to
!           select 'common' class.
  
!      'common'
            Display the options that are common to all languages.
  
       These are the supported qualifiers:
  
!      'undocumented'
            Display only those options that are undocumented.
  
!      'joined'
            Display options taking an argument that appears after an equal
            sign in the same continuous piece of text, such as:
!           '--help=target'.
  
!      'separate'
            Display options taking an argument that appears as a separate
!           word following the original option, such as: '-o output-file'.
  
       Thus for example to display all the undocumented target-specific
       switches supported by the compiler, use:
--- 2265,2350 ----
       as derived from the linker output name but not from inputs, even in
       cases in which this combination would not otherwise be used as
       such, is passed down with a trailing period replacing the
!      compiler-added dash, if any, as a ‘-dumpdir’ option to
!      ‘lto-wrapper’; being involved in linking, this program does not
!      normally get any ‘-dumpbase’ and ‘-dumpbase-ext’, and it ignores
       them.
  
!      When running sub-compilers, ‘lto-wrapper’ appends LTO stage names
       to the received DUMPPFX, ensures it contains a directory component
!      so that it overrides any ‘-dumpdir’, and passes that as ‘-dumpbase’
       to sub-compilers.
  
! ‘-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.
  
! ‘--help’
       Print (on the standard output) a description of the command-line
!      options understood by ‘gcc’.  If the ‘-v’ option is also specified
!      then ‘--help’ is also passed on to the various processes invoked by
!      ‘gcc’, so that they can display the command-line options they
!      accept.  If the ‘-Wextra’ option has also been specified (prior to
!      the ‘--help’ option), then command-line options that have no
       documentation associated with them are also displayed.
  
! ‘--target-help’
       Print (on the standard output) a description of target-specific
       command-line options for each tool.  For some targets extra
       target-specific information may also be printed.
  
! ‘--help={CLASS|[^]QUALIFIER}[,...]’
       Print (on the standard output) a description of the command-line
       options understood by the compiler that fit into all specified
       classes and qualifiers.  These are the supported classes:
  
!      ‘optimizers’
            Display all of the optimization options supported by the
            compiler.
  
!      ‘warnings’
            Display all of the options controlling warning messages
            produced by the compiler.
  
!      ‘target’
!           Display target-specific options.  Unlike the ‘--target-help’
            option however, target-specific options of the linker and
            assembler are not displayed.  This is because those tools do
!           not currently support the extended ‘--help=’ syntax.
  
!      ‘params’
!           Display the values recognized by the ‘--param’ option.
  
       LANGUAGE
            Display the options supported for LANGUAGE, where LANGUAGE is
            the name of one of the languages supported in this version of
            GCC.  If an option is supported by all languages, one needs to
!           select ‘common’ class.
  
!      ‘common’
            Display the options that are common to all languages.
  
       These are the supported qualifiers:
  
!      ‘undocumented’
            Display only those options that are undocumented.
  
!      ‘joined’
            Display options taking an argument that appears after an equal
            sign in the same continuous piece of text, such as:
!           ‘--help=target’.
  
!      ‘separate’
            Display options taking an argument that appears as a separate
!           word following the original option, such as: ‘-o output-file’.
  
       Thus for example to display all the undocumented target-specific
       switches supported by the compiler, use:
*************** nothing at all.
*** 2348,2360 ****
            --help=target,undocumented
  
       The sense of a qualifier can be inverted by prefixing it with the
!      '^' character, so for example to display all binary warning options
       (i.e., ones that are either on or off and that do not take an
       argument) that have a description, use:
  
            --help=warnings,^joined,^undocumented
  
!      The argument to '--help=' should not consist solely of inverted
       qualifiers.
  
       Combining several classes is possible, although this usually
--- 2352,2364 ----
            --help=target,undocumented
  
       The sense of a qualifier can be inverted by prefixing it with the
!      ‘^’ character, so for example to display all binary warning options
       (i.e., ones that are either on or off and that do not take an
       argument) that have a description, use:
  
            --help=warnings,^joined,^undocumented
  
!      The argument to ‘--help=’ should not consist solely of inverted
       qualifiers.
  
       Combining several classes is possible, although this usually
*************** nothing at all.
*** 2365,2384 ****
  
            --help=target,optimizers
  
!      The '--help=' option can be repeated on the command line.  Each
       successive use displays its requested class of options, skipping
!      those that have already been displayed.  If '--help' is also
       specified anywhere on the command line then this takes precedence
!      over any '--help=' option.
  
!      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:
--- 2369,2388 ----
  
            --help=target,optimizers
  
!      The ‘--help=’ option can be repeated on the command line.  Each
       successive use displays its requested class of options, skipping
!      those that have already been displayed.  If ‘--help’ is also
       specified anywhere on the command line then this takes precedence
!      over any ‘--help=’ option.
  
!      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:
*************** nothing at all.
*** 2388,2488 ****
  
       The output is sensitive to the effects of previous command-line
       options, so for example it is possible to find out which
!      optimizations are enabled at '-O2' by using:
  
            -Q -O2 --help=optimizers
  
       Alternatively you can discover which binary optimizations are
!      enabled by '-O3' by using:
  
            gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
            gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
            diff /tmp/O2-opts /tmp/O3-opts | grep enabled
  
! '--version'
       Display the version number and copyrights of the invoked GCC.
  
! '-pass-exit-codes'
!      Normally the 'gcc' program exits with the code of 1 if any phase of
       the compiler returns a non-success return code.  If you specify
!      '-pass-exit-codes', the 'gcc' program instead returns with the
       numerically highest error produced by any phase returning an error
       indication.  The C, C++, and Fortran front ends return 4 if an
       internal compiler error is encountered.
  
! '-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.
  
! '-specs=FILE'
!      Process FILE after the compiler reads in the standard 'specs' file,
!      in order to override the defaults which the 'gcc' driver program
!      uses when determining what switches to pass to 'cc1', 'cc1plus',
!      'as', 'ld', etc.  More than one '-specs=FILE' can be specified on
       the command line, and they are processed in order, from left to
       right.  *Note Spec Files::, for information about the format of the
       FILE.
  
! '-wrapper'
       Invoke all subcommands under a wrapper program.  The name of the
       wrapper program and its parameters are passed as a comma separated
       list.
  
            gcc -c t.c -wrapper gdb,--args
  
!      This invokes all subprograms of 'gcc' under 'gdb --args', thus the
!      invocation of 'cc1' is 'gdb --args cc1 ...'.
  
! '-ffile-prefix-map=OLD=NEW'
!      When compiling files residing in directory 'OLD', record any
       references to them in the result of the compilation as if the files
!      resided in directory 'NEW' instead.  Specifying this option is
!      equivalent to specifying all the individual '-f*-prefix-map'
       options.  This can be used to make reproducible builds that are
       location independent.  Directories referenced by directives are not
!      affected by these options.  See also '-fmacro-prefix-map',
!      '-fdebug-prefix-map', '-fprofile-prefix-map' and
!      '-fcanon-prefix-map'.
  
! '-fcanon-prefix-map'
!      For the '-f*-prefix-map' options normally comparison of 'OLD'
       prefix against the filename that would be normally referenced in
       the result of the compilation is done using textual comparison of
       the prefixes, or ignoring character case for case insensitive
       filesystems and considering slashes and backslashes as equal on DOS
!      based filesystems.  The '-fcanon-prefix-map' causes such
!      comparisons to be done on canonicalized paths of 'OLD' and the
       referenced filename.
  
! '-fplugin=NAME.so'
       Load the plugin code in file NAME.so, assumed to be a shared object
       to be dlopen'd by the compiler.  The base name of the shared object
       file is used to identify the plugin for the purposes of argument
!      parsing (See '-fplugin-arg-NAME-KEY=VALUE' below).  Each plugin
       should define the callback functions specified in the Plugins API.
  
! '-fplugin-arg-NAME-KEY=VALUE'
       Define an argument called KEY with a value of VALUE for the plugin
       called NAME.
  
! '-fdump-ada-spec[-slim]'
       For C and C++ source and include files, generate corresponding Ada
       specs.  *Note (gnat_ugn)Generating Ada Bindings for C and C++
       headers::, which provides detailed documentation on this feature.
  
! '-fada-spec-parent=UNIT'
!      In conjunction with '-fdump-ada-spec[-slim]' above, generate Ada
       specs as child units of parent UNIT.
  
! '-fdump-go-spec=FILE'
       For input files in any language, generate corresponding Go
!      declarations in FILE.  This generates Go 'const', 'type', 'var',
!      and 'func' declarations which may be a useful way to start writing
       a Go interface to code written in some other language.
  
! '@FILE'
       Read command-line options from FILE.  The options read are inserted
       in place of the original @FILE option.  If FILE does not exist, or
       cannot be read, then the option will be treated literally, and not
--- 2392,2492 ----
  
       The output is sensitive to the effects of previous command-line
       options, so for example it is possible to find out which
!      optimizations are enabled at ‘-O2’ by using:
  
            -Q -O2 --help=optimizers
  
       Alternatively you can discover which binary optimizations are
!      enabled by ‘-O3’ by using:
  
            gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
            gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
            diff /tmp/O2-opts /tmp/O3-opts | grep enabled
  
! ‘--version’
       Display the version number and copyrights of the invoked GCC.
  
! ‘-pass-exit-codes’
!      Normally the ‘gcc’ program exits with the code of 1 if any phase of
       the compiler returns a non-success return code.  If you specify
!      ‘-pass-exit-codes’, the ‘gcc’ program instead returns with the
       numerically highest error produced by any phase returning an error
       indication.  The C, C++, and Fortran front ends return 4 if an
       internal compiler error is encountered.
  
! ‘-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.
  
! ‘-specs=FILE’
!      Process FILE after the compiler reads in the standard ‘specs’ file,
!      in order to override the defaults which the ‘gcc’ driver program
!      uses when determining what switches to pass to ‘cc1’, ‘cc1plus’,
!      ‘as’, ‘ld’, etc.  More than one ‘-specs=FILE’ can be specified on
       the command line, and they are processed in order, from left to
       right.  *Note Spec Files::, for information about the format of the
       FILE.
  
! ‘-wrapper’
       Invoke all subcommands under a wrapper program.  The name of the
       wrapper program and its parameters are passed as a comma separated
       list.
  
            gcc -c t.c -wrapper gdb,--args
  
!      This invokes all subprograms of ‘gcc’ under ‘gdb --args’, thus the
!      invocation of ‘cc1’ is ‘gdb --args cc1 ...’.
  
! ‘-ffile-prefix-map=OLD=NEW’
!      When compiling files residing in directory ‘OLD’, record any
       references to them in the result of the compilation as if the files
!      resided in directory ‘NEW’ instead.  Specifying this option is
!      equivalent to specifying all the individual ‘-f*-prefix-map’
       options.  This can be used to make reproducible builds that are
       location independent.  Directories referenced by directives are not
!      affected by these options.  See also ‘-fmacro-prefix-map’,
!      ‘-fdebug-prefix-map’, ‘-fprofile-prefix-map’ and
!      ‘-fcanon-prefix-map’.
  
! ‘-fcanon-prefix-map’
!      For the ‘-f*-prefix-map’ options normally comparison of ‘OLD’
       prefix against the filename that would be normally referenced in
       the result of the compilation is done using textual comparison of
       the prefixes, or ignoring character case for case insensitive
       filesystems and considering slashes and backslashes as equal on DOS
!      based filesystems.  The ‘-fcanon-prefix-map’ causes such
!      comparisons to be done on canonicalized paths of ‘OLD’ and the
       referenced filename.
  
! ‘-fplugin=NAME.so’
       Load the plugin code in file NAME.so, assumed to be a shared object
       to be dlopen'd by the compiler.  The base name of the shared object
       file is used to identify the plugin for the purposes of argument
!      parsing (See ‘-fplugin-arg-NAME-KEY=VALUE’ below).  Each plugin
       should define the callback functions specified in the Plugins API.
  
! ‘-fplugin-arg-NAME-KEY=VALUE’
       Define an argument called KEY with a value of VALUE for the plugin
       called NAME.
  
! ‘-fdump-ada-spec[-slim]’
       For C and C++ source and include files, generate corresponding Ada
       specs.  *Note (gnat_ugn)Generating Ada Bindings for C and C++
       headers::, which provides detailed documentation on this feature.
  
! ‘-fada-spec-parent=UNIT’
!      In conjunction with ‘-fdump-ada-spec[-slim]’ above, generate Ada
       specs as child units of parent UNIT.
  
! ‘-fdump-go-spec=FILE’
       For input files in any language, generate corresponding Go
!      declarations in FILE.  This generates Go ‘const’, ‘type’, ‘var’,
!      and ‘func’ declarations which may be a useful way to start writing
       a Go interface to code written in some other language.
  
! ‘@FILE’
       Read command-line options from FILE.  The options read are inserted
       in place of the original @FILE option.  If FILE does not exist, or
       cannot be read, then the option will be treated literally, and not
*************** File: gcc.info,  Node: Invoking G++,  Ne
*** 2501,2521 ****
  3.3 Compiling C++ Programs
  ==========================
  
! C++ source files conventionally use one of the suffixes '.C', '.cc',
! '.cpp', '.CPP', '.c++', '.cp', or '.cxx'; C++ header files often use
! '.hh', '.hpp', '.H', or (for shared template code) '.tcc'; and
! preprocessed C++ files use the suffix '.ii'.  GCC recognizes files with
  these names and compiles them as C++ programs even if you call the
  compiler the same way as for compiling C programs (usually with the name
! 'gcc').
  
!  However, the use of 'gcc' does not add the C++ library.  'g++' is a
  program that calls GCC and automatically specifies linking against the
! C++ library.  It treats '.c', '.h' and '.i' files as C++ source files
! instead of C source files unless '-x' is used.  This program is also
! useful when precompiling a C header file with a '.h' extension for use
! in C++ compilations.  On many systems, 'g++' is also installed with the
! name 'c++'.
  
   When you compile C++ programs, you may specify many of the same
  command-line options that you use for compiling programs in any
--- 2505,2525 ----
  3.3 Compiling C++ Programs
  ==========================
  
! C++ source files conventionally use one of the suffixes ‘.C’, ‘.cc’,
! ‘.cpp’, ‘.CPP’, ‘.c++’, ‘.cp’, or ‘.cxx’; C++ header files often use
! ‘.hh’, ‘.hpp’, ‘.H’, or (for shared template code) ‘.tcc’; and
! preprocessed C++ files use the suffix ‘.ii’.  GCC recognizes files with
  these names and compiles them as C++ programs even if you call the
  compiler the same way as for compiling C programs (usually with the name
! ‘gcc’).
  
!  However, the use of ‘gcc’ does not add the C++ library.  ‘g++’ is a
  program that calls GCC and automatically specifies linking against the
! C++ library.  It treats ‘.c’, ‘.h’ and ‘.i’ files as C++ source files
! instead of C source files unless ‘-x’ is used.  This program is also
! useful when precompiling a C header file with a ‘.h’ extension for use
! in C++ compilations.  On many systems, ‘g++’ is also installed with the
! name ‘c++’.
  
   When you compile C++ programs, you may specify many of the same
  command-line options that you use for compiling programs in any
*************** The following options control the dialec
*** 2536,2733 ****
  from C, such as C++, Objective-C and Objective-C++) that the compiler
  accepts:
  
! '-ansi'
!      In C mode, this is equivalent to '-std=c90'.  In C++ mode, it is
!      equivalent to '-std=c++98'.
  
       This turns off certain features of GCC that are incompatible with
       ISO C90 (when compiling C code), or of standard C++ (when compiling
!      C++ code), such as the 'asm' and 'typeof' keywords, and predefined
!      macros such as 'unix' and 'vax' that identify the type of system
       you are using.  It also enables the undesirable and rarely used ISO
       trigraph feature.  For the C compiler, it disables recognition of
!      C++ style '//' comments as well as the 'inline' keyword.
  
!      The alternate keywords '__asm__', '__extension__', '__inline__' and
!      '__typeof__' continue to work despite '-ansi'.  You would not want
       to use them in an ISO C program, of course, but it is useful to put
       them in header files that might be included in compilations done
!      with '-ansi'.  Alternate predefined macros such as '__unix__' and
!      '__vax__' are also available, with or without '-ansi'.
  
!      The '-ansi' option does not cause non-ISO programs to be rejected
!      gratuitously.  For that, '-Wpedantic' is required in addition to
!      '-ansi'.  *Note Warning Options::.
  
!      The macro '__STRICT_ANSI__' is predefined when the '-ansi' option
       is used.  Some header files may notice this macro and refrain from
       declaring certain functions or defining certain macros that the ISO
       standard doesn't call for; this is to avoid interfering with any
       programs that might use these names for other things.
  
       Functions that are normally built in but do not have semantics
!      defined by ISO C (such as 'alloca' and 'ffs') are not built-in
!      functions when '-ansi' is used.  *Note Other built-in functions
       provided by GCC: Other Builtins, for details of the functions
       affected.
  
! '-std='
       Determine the language standard.  *Note Language Standards
       Supported by GCC: Standards, for details of these standard
       versions.  This option is currently only supported when compiling C
       or C++.
  
!      The compiler can accept several base standards, such as 'c90' or
!      'c++98', and GNU dialects of those standards, such as 'gnu90' or
!      'gnu++98'.  When a base standard is specified, the compiler accepts
       all programs following that standard plus those using GNU
!      extensions that do not contradict it.  For example, '-std=c90'
       turns off certain features of GCC that are incompatible with ISO
!      C90, such as the 'asm' and 'typeof' keywords, but not other GNU
       extensions that do not have a meaning in ISO C90, such as omitting
!      the middle term of a '?:' expression.  On the other hand, when a
       GNU dialect of a standard is specified, all features supported by
       the compiler are enabled, even when those features change the
       meaning of the base standard.  As a result, some strict-conforming
       programs may be rejected.  The particular standard is used by
!      '-Wpedantic' to identify which features are GNU extensions given
!      that version of the standard.  For example '-std=gnu90 -Wpedantic'
!      warns about C++ style '//' comments, while '-std=gnu99 -Wpedantic'
       does not.
  
       A value for this option must be provided; possible values are
  
!      'c90'
!      'c89'
!      'iso9899:1990'
            Support all ISO C90 programs (certain GNU extensions that
!           conflict with ISO C90 are disabled).  Same as '-ansi' for C
            code.
  
!      'iso9899:199409'
            ISO C90 as modified in amendment 1.
  
!      'c99'
!      'c9x'
!      'iso9899:1999'
!      'iso9899:199x'
            ISO C99.  This standard is substantially completely supported,
            modulo bugs and floating-point issues (mainly but not entirely
            relating to optional C99 features from Annexes F and G). See
             for more information.
!           The names 'c9x' and 'iso9899:199x' are deprecated.
  
!      'c11'
!      'c1x'
!      'iso9899:2011'
            ISO C11, the 2011 revision of the ISO C standard.  This
            standard is substantially completely supported, modulo bugs,
            floating-point issues (mainly but not entirely relating to
            optional C11 features from Annexes F and G) and the optional
            Annexes K (Bounds-checking interfaces) and L (Analyzability).
!           The name 'c1x' is deprecated.
  
!      'c17'
!      'c18'
!      'iso9899:2017'
!      'iso9899:2018'
            ISO C17, the 2017 revision of the ISO C standard (published in
            2018).  This standard is same as C11 except for corrections of
!           defects (all of which are also applied with '-std=c11') and a
!           new value of '__STDC_VERSION__', and so is supported to the
            same extent as C11.
  
!      'c2x'
            The next version of the ISO C standard, still under
            development.  The support for this version is experimental and
            incomplete.
  
!      'gnu90'
!      'gnu89'
            GNU dialect of ISO C90 (including some C99 features).
  
!      'gnu99'
!      'gnu9x'
!           GNU dialect of ISO C99.  The name 'gnu9x' is deprecated.
  
!      'gnu11'
!      'gnu1x'
!           GNU dialect of ISO C11.  The name 'gnu1x' is deprecated.
  
!      'gnu17'
!      'gnu18'
            GNU dialect of ISO C17.  This is the default for C code.
  
!      'gnu2x'
            The next version of the ISO C standard, still under
            development, plus GNU extensions.  The support for this
            version is experimental and incomplete.
  
!      'c++98'
!      'c++03'
            The 1998 ISO C++ standard plus the 2003 technical corrigendum
!           and some additional defect reports.  Same as '-ansi' for C++
            code.
  
!      'gnu++98'
!      'gnu++03'
!           GNU dialect of '-std=c++98'.
  
!      'c++11'
!      'c++0x'
!           The 2011 ISO C++ standard plus amendments.  The name 'c++0x'
            is deprecated.
  
!      'gnu++11'
!      'gnu++0x'
!           GNU dialect of '-std=c++11'.  The name 'gnu++0x' is
            deprecated.
  
!      'c++14'
!      'c++1y'
!           The 2014 ISO C++ standard plus amendments.  The name 'c++1y'
            is deprecated.
  
!      'gnu++14'
!      'gnu++1y'
!           GNU dialect of '-std=c++14'.  The name 'gnu++1y' is
            deprecated.
  
!      'c++17'
!      'c++1z'
!           The 2017 ISO C++ standard plus amendments.  The name 'c++1z'
            is deprecated.
  
!      'gnu++17'
!      'gnu++1z'
!           GNU dialect of '-std=c++17'.  This is the default for C++
!           code.  The name 'gnu++1z' is deprecated.
  
!      'c++20'
!      'c++2a'
            The 2020 ISO C++ standard plus amendments.  Support is
            experimental, and could change in incompatible ways in future
!           releases.  The name 'c++2a' is deprecated.
  
!      'gnu++20'
!      'gnu++2a'
!           GNU dialect of '-std=c++20'.  Support is experimental, and
            could change in incompatible ways in future releases.  The
!           name 'gnu++2a' is deprecated.
  
!      'c++2b'
!      'c++23'
            The next revision of the ISO C++ standard, planned for 2023.
            Support is highly experimental, and will almost certainly
            change in incompatible ways in future releases.
  
!      'gnu++2b'
!      'gnu++23'
!           GNU dialect of '-std=c++2b'.  Support is highly experimental,
            and will almost certainly change in incompatible ways in
            future releases.
  
! '-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
--- 2540,2737 ----
  from C, such as C++, Objective-C and Objective-C++) that the compiler
  accepts:
  
! ‘-ansi’
!      In C mode, this is equivalent to ‘-std=c90’.  In C++ mode, it is
!      equivalent to ‘-std=c++98’.
  
       This turns off certain features of GCC that are incompatible with
       ISO C90 (when compiling C code), or of standard C++ (when compiling
!      C++ code), such as the ‘asm’ and ‘typeof’ keywords, and predefined
!      macros such as ‘unix’ and ‘vax’ that identify the type of system
       you are using.  It also enables the undesirable and rarely used ISO
       trigraph feature.  For the C compiler, it disables recognition of
!      C++ style ‘//’ comments as well as the ‘inline’ keyword.
  
!      The alternate keywords ‘__asm__’, ‘__extension__’, ‘__inline__’ and
!      ‘__typeof__’ continue to work despite ‘-ansi’.  You would not want
       to use them in an ISO C program, of course, but it is useful to put
       them in header files that might be included in compilations done
!      with ‘-ansi’.  Alternate predefined macros such as ‘__unix__’ and
!      ‘__vax__’ are also available, with or without ‘-ansi’.
  
!      The ‘-ansi’ option does not cause non-ISO programs to be rejected
!      gratuitously.  For that, ‘-Wpedantic’ is required in addition to
!      ‘-ansi’.  *Note Warning Options::.
  
!      The macro ‘__STRICT_ANSI__’ is predefined when the ‘-ansi’ option
       is used.  Some header files may notice this macro and refrain from
       declaring certain functions or defining certain macros that the ISO
       standard doesn't call for; this is to avoid interfering with any
       programs that might use these names for other things.
  
       Functions that are normally built in but do not have semantics
!      defined by ISO C (such as ‘alloca’ and ‘ffs’) are not built-in
!      functions when ‘-ansi’ is used.  *Note Other built-in functions
       provided by GCC: Other Builtins, for details of the functions
       affected.
  
! ‘-std=’
       Determine the language standard.  *Note Language Standards
       Supported by GCC: Standards, for details of these standard
       versions.  This option is currently only supported when compiling C
       or C++.
  
!      The compiler can accept several base standards, such as ‘c90’ or
!      ‘c++98’, and GNU dialects of those standards, such as ‘gnu90’ or
!      ‘gnu++98’.  When a base standard is specified, the compiler accepts
       all programs following that standard plus those using GNU
!      extensions that do not contradict it.  For example, ‘-std=c90’
       turns off certain features of GCC that are incompatible with ISO
!      C90, such as the ‘asm’ and ‘typeof’ keywords, but not other GNU
       extensions that do not have a meaning in ISO C90, such as omitting
!      the middle term of a ‘?:’ expression.  On the other hand, when a
       GNU dialect of a standard is specified, all features supported by
       the compiler are enabled, even when those features change the
       meaning of the base standard.  As a result, some strict-conforming
       programs may be rejected.  The particular standard is used by
!      ‘-Wpedantic’ to identify which features are GNU extensions given
!      that version of the standard.  For example ‘-std=gnu90 -Wpedantic’
!      warns about C++ style ‘//’ comments, while ‘-std=gnu99 -Wpedantic’
       does not.
  
       A value for this option must be provided; possible values are
  
!      ‘c90’
!      ‘c89’
!      ‘iso9899:1990’
            Support all ISO C90 programs (certain GNU extensions that
!           conflict with ISO C90 are disabled).  Same as ‘-ansi’ for C
            code.
  
!      ‘iso9899:199409’
            ISO C90 as modified in amendment 1.
  
!      ‘c99’
!      ‘c9x’
!      ‘iso9899:1999’
!      ‘iso9899:199x’
            ISO C99.  This standard is substantially completely supported,
            modulo bugs and floating-point issues (mainly but not entirely
            relating to optional C99 features from Annexes F and G). See
             for more information.
!           The names ‘c9x’ and ‘iso9899:199x’ are deprecated.
  
!      ‘c11’
!      ‘c1x’
!      ‘iso9899:2011’
            ISO C11, the 2011 revision of the ISO C standard.  This
            standard is substantially completely supported, modulo bugs,
            floating-point issues (mainly but not entirely relating to
            optional C11 features from Annexes F and G) and the optional
            Annexes K (Bounds-checking interfaces) and L (Analyzability).
!           The name ‘c1x’ is deprecated.
  
!      ‘c17’
!      ‘c18’
!      ‘iso9899:2017’
!      ‘iso9899:2018’
            ISO C17, the 2017 revision of the ISO C standard (published in
            2018).  This standard is same as C11 except for corrections of
!           defects (all of which are also applied with ‘-std=c11’) and a
!           new value of ‘__STDC_VERSION__’, and so is supported to the
            same extent as C11.
  
!      ‘c2x’
            The next version of the ISO C standard, still under
            development.  The support for this version is experimental and
            incomplete.
  
!      ‘gnu90’
!      ‘gnu89’
            GNU dialect of ISO C90 (including some C99 features).
  
!      ‘gnu99’
!      ‘gnu9x’
!           GNU dialect of ISO C99.  The name ‘gnu9x’ is deprecated.
  
!      ‘gnu11’
!      ‘gnu1x’
!           GNU dialect of ISO C11.  The name ‘gnu1x’ is deprecated.
  
!      ‘gnu17’
!      ‘gnu18’
            GNU dialect of ISO C17.  This is the default for C code.
  
!      ‘gnu2x’
            The next version of the ISO C standard, still under
            development, plus GNU extensions.  The support for this
            version is experimental and incomplete.
  
!      ‘c++98’
!      ‘c++03’
            The 1998 ISO C++ standard plus the 2003 technical corrigendum
!           and some additional defect reports.  Same as ‘-ansi’ for C++
            code.
  
!      ‘gnu++98’
!      ‘gnu++03’
!           GNU dialect of ‘-std=c++98’.
  
!      ‘c++11’
!      ‘c++0x’
!           The 2011 ISO C++ standard plus amendments.  The name ‘c++0x’
            is deprecated.
  
!      ‘gnu++11’
!      ‘gnu++0x’
!           GNU dialect of ‘-std=c++11’.  The name ‘gnu++0x’ is
            deprecated.
  
!      ‘c++14’
!      ‘c++1y’
!           The 2014 ISO C++ standard plus amendments.  The name ‘c++1y’
            is deprecated.
  
!      ‘gnu++14’
!      ‘gnu++1y’
!           GNU dialect of ‘-std=c++14’.  The name ‘gnu++1y’ is
            deprecated.
  
!      ‘c++17’
!      ‘c++1z’
!           The 2017 ISO C++ standard plus amendments.  The name ‘c++1z’
            is deprecated.
  
!      ‘gnu++17’
!      ‘gnu++1z’
!           GNU dialect of ‘-std=c++17’.  This is the default for C++
!           code.  The name ‘gnu++1z’ is deprecated.
  
!      ‘c++20’
!      ‘c++2a’
            The 2020 ISO C++ standard plus amendments.  Support is
            experimental, and could change in incompatible ways in future
!           releases.  The name ‘c++2a’ is deprecated.
  
!      ‘gnu++20’
!      ‘gnu++2a’
!           GNU dialect of ‘-std=c++20’.  Support is experimental, and
            could change in incompatible ways in future releases.  The
!           name ‘gnu++2a’ is deprecated.
  
!      ‘c++2b’
!      ‘c++23’
            The next revision of the ISO C++ standard, planned for 2023.
            Support is highly experimental, and will almost certainly
            change in incompatible ways in future releases.
  
!      ‘gnu++2b’
!      ‘gnu++23’
!           GNU dialect of ‘-std=c++2b’.  Support is highly experimental,
            and will almost certainly change in incompatible ways in
            future releases.
  
! ‘-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
*************** accepts:
*** 2735,2776 ****
  
       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.  In C, '-ansi'
!      implies '-fno-asm'.
  
!      In C++, 'inline' is a standard keyword and is not affected by this
!      switch.  You may want to use the '-fno-gnu-keywords' flag instead,
!      which disables 'typeof' but not 'asm' and 'inline'.  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.  In C2X mode ('-std=c2x' or '-std=gnu2x'), this switch only
!      affects the 'asm' keyword, since 'typeof' is a standard keyword in
       ISO C2X.
  
! '-fno-builtin'
! '-fno-builtin-FUNCTION'
       Don't recognize built-in functions that do not begin with
!      '__builtin_' as prefix.  *Note Other built-in functions provided by
       GCC: Other Builtins, for details of the functions affected,
!      including those which are not built-in functions when '-ansi' or
!      '-std' options for strict ISO C conformance are used because they
       do not have an ISO standard meaning.
  
       GCC normally generates special code to handle certain built-in
!      functions more efficiently; for instance, calls to 'alloca' may
       become single instructions which adjust the stack directly, and
!      calls to 'memcpy' may become inline copy loops.  The resulting code
       is often both smaller and faster, but since the function calls no
       longer appear as such, you cannot set a breakpoint on those calls,
       nor can you change the behavior of the functions by linking with a
--- 2739,2780 ----
  
       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.  In C, ‘-ansi’
!      implies ‘-fno-asm’.
  
!      In C++, ‘inline’ is a standard keyword and is not affected by this
!      switch.  You may want to use the ‘-fno-gnu-keywords’ flag instead,
!      which disables ‘typeof’ but not ‘asm’ and ‘inline’.  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.  In C2X mode (‘-std=c2x’ or ‘-std=gnu2x’), this switch only
!      affects the ‘asm’ keyword, since ‘typeof’ is a standard keyword in
       ISO C2X.
  
! ‘-fno-builtin’
! ‘-fno-builtin-FUNCTION’
       Don't recognize built-in functions that do not begin with
!      ‘__builtin_’ as prefix.  *Note Other built-in functions provided by
       GCC: Other Builtins, for details of the functions affected,
!      including those which are not built-in functions when ‘-ansi’ or
!      ‘-std’ options for strict ISO C conformance are used because they
       do not have an ISO standard meaning.
  
       GCC normally generates special code to handle certain built-in
!      functions more efficiently; for instance, calls to ‘alloca’ may
       become single instructions which adjust the stack directly, and
!      calls to ‘memcpy’ may become inline copy loops.  The resulting code
       is often both smaller and faster, but since the function calls no
       longer appear as such, you cannot set a breakpoint on those calls,
       nor can you change the behavior of the functions by linking with a
*************** accepts:
*** 2779,2822 ****
       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))
  
! '-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++.
  
! '-ffreestanding'
  
       Assert that compilation targets a freestanding environment.  This
!      implies '-fno-builtin'.  A freestanding environment is one in which
       the standard library may not exist, and program startup may not
!      necessarily be at 'main'.  The most obvious example is an OS
!      kernel.  This is equivalent to '-fno-hosted'.
  
       *Note Language Standards Supported by GCC: Standards, for details
       of freestanding and hosted environments.
  
! '-fgimple'
  
!      Enable parsing of function definitions marked with '__GIMPLE'.
       This is an experimental feature that allows unit testing of GIMPLE
       passes.
  
! '-fgnu-tm'
!      When the option '-fgnu-tm' is specified, the compiler generates
       code for the Linux variant of Intel's current Transactional Memory
       ABI specification document (Revision 1.1, May 6 2009).  This is an
       experimental feature whose interface may change in future versions
--- 2783,2826 ----
       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))
  
! ‘-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++.
  
! ‘-ffreestanding’
  
       Assert that compilation targets a freestanding environment.  This
!      implies ‘-fno-builtin’.  A freestanding environment is one in which
       the standard library may not exist, and program startup may not
!      necessarily be at ‘main’.  The most obvious example is an OS
!      kernel.  This is equivalent to ‘-fno-hosted’.
  
       *Note Language Standards Supported by GCC: Standards, for details
       of freestanding and hosted environments.
  
! ‘-fgimple’
  
!      Enable parsing of function definitions marked with ‘__GIMPLE’.
       This is an experimental feature that allows unit testing of GIMPLE
       passes.
  
! ‘-fgnu-tm’
!      When the option ‘-fgnu-tm’ is specified, the compiler generates
       code for the Linux variant of Intel's current Transactional Memory
       ABI specification document (Revision 1.1, May 6 2009).  This is an
       experimental feature whose interface may change in future versions
*************** accepts:
*** 2828,2866 ****
       libitm.
  
       Note that the transactional memory feature is not supported with
!      non-call exceptions ('-fnon-call-exceptions').
  
! '-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.  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 is not supported in
!      '-std=c90' or '-std=gnu90' mode.
  
!      The preprocessor macros '__GNUC_GNU_INLINE__' and
!      '__GNUC_STDC_INLINE__' may be used to check which semantics are in
!      effect for 'inline' functions.  *Note (cpp)Common Predefined
       Macros::.
  
! '-fhosted'
  
       Assert that compilation targets a hosted environment.  This implies
!      '-fbuiltin'.  A hosted environment is one in which the entire
!      standard library is available, and in which 'main' has a return
!      type of 'int'.  Examples are nearly everything except a kernel.
!      This is equivalent to '-fno-freestanding'.
  
! '-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.
  
! '-fms-extensions'
       Accept some non-standard constructs used in Microsoft header files.
  
       In C++ code, this allows member names in structures to be similar
--- 2832,2870 ----
       libitm.
  
       Note that the transactional memory feature is not supported with
!      non-call exceptions (‘-fnon-call-exceptions’).
  
! ‘-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.  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 is not supported in
!      ‘-std=c90’ or ‘-std=gnu90’ mode.
  
!      The preprocessor macros ‘__GNUC_GNU_INLINE__’ and
!      ‘__GNUC_STDC_INLINE__’ may be used to check which semantics are in
!      effect for ‘inline’ functions.  *Note (cpp)Common Predefined
       Macros::.
  
! ‘-fhosted’
  
       Assert that compilation targets a hosted environment.  This implies
!      ‘-fbuiltin’.  A hosted environment is one in which the entire
!      standard library is available, and in which ‘main’ has a return
!      type of ‘int’.  Examples are nearly everything except a kernel.
!      This is equivalent to ‘-fno-freestanding’.
  
! ‘-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.
  
! ‘-fms-extensions’
       Accept some non-standard constructs used in Microsoft header files.
  
       In C++ code, this allows member names in structures to be similar
*************** accepts:
*** 2878,2906 ****
       Note that this option is off for all targets except for x86 targets
       using ms-abi.
  
! '-foffload=disable'
! '-foffload=default'
! '-foffload=TARGET-LIST'
       Specify for which OpenMP and OpenACC offload targets code should be
       generated.  The default behavior, equivalent to
!      '-foffload=default', is to generate code for all supported offload
!      targets.  The '-foffload=disable' form generates code only for the
!      host fallback, while '-foffload=TARGET-LIST' generates code only
       for the specified comma-separated list of offload targets.
  
       Offload targets are specified in GCC's internal target-triplet
!      format.  You can run the compiler with '-v' to show the list of
!      configured offload targets under 'OFFLOAD_TARGET_NAMES'.
  
! '-foffload-options=OPTIONS'
! '-foffload-options=TARGET-TRIPLET-LIST=OPTIONS'
  
!      With '-foffload-options=OPTIONS', GCC passes the specified OPTIONS
       to the compilers for all enabled offloading targets.  You can
       specify options that apply only to a specific target or targets by
!      using the '-foffload-options=TARGET-LIST=OPTIONS' form.  The
       TARGET-LIST is a comma-separated list in the same format as for the
!      '-foffload=' option.
  
       Typical command lines are
  
--- 2882,2910 ----
       Note that this option is off for all targets except for x86 targets
       using ms-abi.
  
! ‘-foffload=disable’
! ‘-foffload=default’
! ‘-foffload=TARGET-LIST’
       Specify for which OpenMP and OpenACC offload targets code should be
       generated.  The default behavior, equivalent to
!      ‘-foffload=default’, is to generate code for all supported offload
!      targets.  The ‘-foffload=disable’ form generates code only for the
!      host fallback, while ‘-foffload=TARGET-LIST’ generates code only
       for the specified comma-separated list of offload targets.
  
       Offload targets are specified in GCC's internal target-triplet
!      format.  You can run the compiler with ‘-v’ to show the list of
!      configured offload targets under ‘OFFLOAD_TARGET_NAMES’.
  
! ‘-foffload-options=OPTIONS’
! ‘-foffload-options=TARGET-TRIPLET-LIST=OPTIONS’
  
!      With ‘-foffload-options=OPTIONS’, GCC passes the specified OPTIONS
       to the compilers for all enabled offloading targets.  You can
       specify options that apply only to a specific target or targets by
!      using the ‘-foffload-options=TARGET-LIST=OPTIONS’ form.  The
       TARGET-LIST is a comma-separated list in the same format as for the
!      ‘-foffload=’ option.
  
       Typical command lines are
  
*************** accepts:
*** 2908,3059 ****
            -foffload-options="-lgfortran -lm" -foffload-options=nvptx-none=-latomic
            -foffload-options=amdgcn-amdhsa=-march=gfx906 -foffload-options=-lm
  
! '-fopenacc'
!      Enable handling of OpenACC directives '#pragma acc' in C/C++ and
!      '!$acc' in Fortran.  When '-fopenacc' is specified, the compiler
       generates accelerated code according to the OpenACC Application
       Programming Interface v2.6 .  This option
!      implies '-pthread', and thus is only supported on targets that have
!      support for '-pthread'.
  
! '-fopenacc-dim=GEOM'
       Specify default compute dimensions for parallel offload regions
       that do not explicitly specify.  The GEOM value is a triple of
       ':'-separated sizes, in order 'gang', 'worker' and, 'vector'.  A
       size can be omitted, to use a target-specific default value.
  
! '-fopenmp'
!      Enable handling of OpenMP directives '#pragma omp' in C/C++,
!      '[[omp::directive(...)]]' and '[[omp::sequence(...)]]' in C++ and
!      '!$omp' in Fortran.  When '-fopenmp' is specified, the compiler
       generates parallel code according to the OpenMP Application Program
       Interface v4.5 .  This option implies
!      '-pthread', and thus is only supported on targets that have support
!      for '-pthread'.  '-fopenmp' implies '-fopenmp-simd'.
  
! '-fopenmp-simd'
!      Enable handling of OpenMP's 'simd', 'declare simd', 'declare
!      reduction', 'assume', 'ordered', 'scan', 'loop' directives and
!      combined or composite directives with 'simd' as constituent with
!      '#pragma omp' in C/C++, '[[omp::directive(...)]]' and
!      '[[omp::sequence(...)]]' in C++ and '!$omp' in Fortran.  Other
       OpenMP directives are ignored.
  
! '-fopenmp-target-simd-clone'
! '-fopenmp-target-simd-clone=DEVICE-TYPE'
       In addition to generating SIMD clones for functions marked with the
!      'declare simd' directive, GCC also generates clones for functions
!      marked with the OpenMP 'declare target' directive that are suitable
       for vectorization when this option is in effect.  The DEVICE-TYPE
!      may be one of 'none', 'host', 'nohost', and 'any', which correspond
!      to keywords for the 'device_type' clause of the 'declare target'
       directive; clones are generated for the intersection of devices
!      specified.  '-fopenmp-target-simd-clone' is equivalent to
!      '-fopenmp-target-simd-clone=any' and
!      '-fno-openmp-target-simd-clone' is equivalent to
!      '-fopenmp-target-simd-clone=none'.
  
!      At '-O2' and higher (but not '-Os' or '-Og') this optimization
!      defaults to '-fopenmp-target-simd-clone=nohost'; otherwise it is
       disabled by default.
  
! '-fpermitted-flt-eval-methods=STYLE'
       ISO/IEC TS 18661-3 defines new permissible values for
!      'FLT_EVAL_METHOD' that indicate that operations and constants with
       a semantic type that is an interchange or extended format should be
       evaluated to the precision and range of that type.  These new
       values are a superset of those permitted under C99/C11, which does
       not specify the meaning of other positive values of
!      'FLT_EVAL_METHOD'.  As such, code conforming to C11 may not have
       been written expecting the possibility of the new values.
  
!      '-fpermitted-flt-eval-methods' specifies whether the compiler
!      should allow only the values of 'FLT_EVAL_METHOD' specified in
       C99/C11, or the extended set of values specified in ISO/IEC TS
       18661-3.
  
!      STYLE is either 'c11' or 'ts-18661-3' as appropriate.
  
!      The default when in a standards compliant mode ('-std=c11' or
!      similar) is '-fpermitted-flt-eval-methods=c11'.  The default when
!      in a GNU dialect ('-std=gnu11' or similar) is
!      '-fpermitted-flt-eval-methods=ts-18661-3'.
  
! '-fplan9-extensions'
       Accept some non-standard constructs used in Plan 9 code.
  
!      This enables '-fms-extensions', permits passing pointers to
       structures with anonymous fields to functions that expect pointers
       to elements of the type of the field, and permits referring to
       anonymous fields declared using a typedef.  *Note Unnamed
       struct/union fields within structs/unions: Unnamed Fields, for
       details.  This is only supported for C, not C++.
  
! '-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.
  
! '-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'.
  
! '-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.
  
! '-fstrict-flex-arrays'
       Control when to treat the trailing array of a structure as a
       flexible array member for the purpose of accessing the elements of
       such an array.  The positive form is equivalent to
!      '-fstrict-flex-arrays=3', which is the strictest.  A trailing array
       is treated as a flexible array member only when it is declared as a
       flexible array member per C99 standard onwards.  The negative form
!      is equivalent to '-fstrict-flex-arrays=0', which is the least
       strict.  All trailing arrays of structures are treated as flexible
       array members.
  
! '-fstrict-flex-arrays=LEVEL'
       Control when to treat the trailing array of a structure as a
       flexible array member for the purpose of accessing the elements of
       such an array.  The value of LEVEL controls the level of
       strictness.
  
       The possible values of LEVEL are the same as for the
!      'strict_flex_array' attribute (*note Variable Attributes::).
  
       You can control this behavior for a specific trailing array field
!      of a structure by using the variable attribute 'strict_flex_array'
       attribute (*note Variable Attributes::).
  
! '-fsso-struct=ENDIANNESS'
       Set the default scalar storage order of structures and unions to
!      the specified endianness.  The accepted values are 'big-endian',
!      'little-endian' and 'native' for the native endianness of the
       target (the default).  This option is not supported for C++.
  
!      *Warning:* the '-fsso-struct' switch causes GCC to generate code
       that is not binary compatible with code generated without it if the
       specified endianness is not the native endianness of the target.
  
--- 2912,3063 ----
            -foffload-options="-lgfortran -lm" -foffload-options=nvptx-none=-latomic
            -foffload-options=amdgcn-amdhsa=-march=gfx906 -foffload-options=-lm
  
! ‘-fopenacc’
!      Enable handling of OpenACC directives ‘#pragma acc’ in C/C++ and
!      ‘!$acc’ in Fortran.  When ‘-fopenacc’ is specified, the compiler
       generates accelerated code according to the OpenACC Application
       Programming Interface v2.6 .  This option
!      implies ‘-pthread’, and thus is only supported on targets that have
!      support for ‘-pthread’.
  
! ‘-fopenacc-dim=GEOM’
       Specify default compute dimensions for parallel offload regions
       that do not explicitly specify.  The GEOM value is a triple of
       ':'-separated sizes, in order 'gang', 'worker' and, 'vector'.  A
       size can be omitted, to use a target-specific default value.
  
! ‘-fopenmp’
!      Enable handling of OpenMP directives ‘#pragma omp’ in C/C++,
!      ‘[[omp::directive(...)]]’ and ‘[[omp::sequence(...)]]’ in C++ and
!      ‘!$omp’ in Fortran.  When ‘-fopenmp’ is specified, the compiler
       generates parallel code according to the OpenMP Application Program
       Interface v4.5 .  This option implies
!      ‘-pthread’, and thus is only supported on targets that have support
!      for ‘-pthread’.  ‘-fopenmp’ implies ‘-fopenmp-simd’.
  
! ‘-fopenmp-simd’
!      Enable handling of OpenMP's ‘simd’, ‘declare simd’, ‘declare
!      reduction’, ‘assume’, ‘ordered’, ‘scan’, ‘loop’ directives and
!      combined or composite directives with ‘simd’ as constituent with
!      ‘#pragma omp’ in C/C++, ‘[[omp::directive(...)]]’ and
!      ‘[[omp::sequence(...)]]’ in C++ and ‘!$omp’ in Fortran.  Other
       OpenMP directives are ignored.
  
! ‘-fopenmp-target-simd-clone’
! ‘-fopenmp-target-simd-clone=DEVICE-TYPE’
       In addition to generating SIMD clones for functions marked with the
!      ‘declare simd’ directive, GCC also generates clones for functions
!      marked with the OpenMP ‘declare target’ directive that are suitable
       for vectorization when this option is in effect.  The DEVICE-TYPE
!      may be one of ‘none’, ‘host’, ‘nohost’, and ‘any’, which correspond
!      to keywords for the ‘device_type’ clause of the ‘declare target’
       directive; clones are generated for the intersection of devices
!      specified.  ‘-fopenmp-target-simd-clone’ is equivalent to
!      ‘-fopenmp-target-simd-clone=any’ and
!      ‘-fno-openmp-target-simd-clone’ is equivalent to
!      ‘-fopenmp-target-simd-clone=none’.
  
!      At ‘-O2’ and higher (but not ‘-Os’ or ‘-Og’) this optimization
!      defaults to ‘-fopenmp-target-simd-clone=nohost’; otherwise it is
       disabled by default.
  
! ‘-fpermitted-flt-eval-methods=STYLE’
       ISO/IEC TS 18661-3 defines new permissible values for
!      ‘FLT_EVAL_METHOD’ that indicate that operations and constants with
       a semantic type that is an interchange or extended format should be
       evaluated to the precision and range of that type.  These new
       values are a superset of those permitted under C99/C11, which does
       not specify the meaning of other positive values of
!      ‘FLT_EVAL_METHOD’.  As such, code conforming to C11 may not have
       been written expecting the possibility of the new values.
  
!      ‘-fpermitted-flt-eval-methods’ specifies whether the compiler
!      should allow only the values of ‘FLT_EVAL_METHOD’ specified in
       C99/C11, or the extended set of values specified in ISO/IEC TS
       18661-3.
  
!      STYLE is either ‘c11’ or ‘ts-18661-3’ as appropriate.
  
!      The default when in a standards compliant mode (‘-std=c11’ or
!      similar) is ‘-fpermitted-flt-eval-methods=c11’.  The default when
!      in a GNU dialect (‘-std=gnu11’ or similar) is
!      ‘-fpermitted-flt-eval-methods=ts-18661-3’.
  
! ‘-fplan9-extensions’
       Accept some non-standard constructs used in Plan 9 code.
  
!      This enables ‘-fms-extensions’, permits passing pointers to
       structures with anonymous fields to functions that expect pointers
       to elements of the type of the field, and permits referring to
       anonymous fields declared using a typedef.  *Note Unnamed
       struct/union fields within structs/unions: Unnamed Fields, for
       details.  This is only supported for C, not C++.
  
! ‘-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.
  
! ‘-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’.
  
! ‘-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.
  
! ‘-fstrict-flex-arrays’
       Control when to treat the trailing array of a structure as a
       flexible array member for the purpose of accessing the elements of
       such an array.  The positive form is equivalent to
!      ‘-fstrict-flex-arrays=3’, which is the strictest.  A trailing array
       is treated as a flexible array member only when it is declared as a
       flexible array member per C99 standard onwards.  The negative form
!      is equivalent to ‘-fstrict-flex-arrays=0’, which is the least
       strict.  All trailing arrays of structures are treated as flexible
       array members.
  
! ‘-fstrict-flex-arrays=LEVEL’
       Control when to treat the trailing array of a structure as a
       flexible array member for the purpose of accessing the elements of
       such an array.  The value of LEVEL controls the level of
       strictness.
  
       The possible values of LEVEL are the same as for the
!      ‘strict_flex_array’ attribute (*note Variable Attributes::).
  
       You can control this behavior for a specific trailing array field
!      of a structure by using the variable attribute ‘strict_flex_array’
       attribute (*note Variable Attributes::).
  
! ‘-fsso-struct=ENDIANNESS’
       Set the default scalar storage order of structures and unions to
!      the specified endianness.  The accepted values are ‘big-endian’,
!      ‘little-endian’ and ‘native’ for the native endianness of the
       target (the default).  This option is not supported for C++.
  
!      *Warning:* the ‘-fsso-struct’ switch causes GCC to generate code
       that is not binary compatible with code generated without it if the
       specified endianness is not the native endianness of the target.
  
*************** File: gcc.info,  Node: C++ Dialect Optio
*** 3066,3086 ****
  This section describes the command-line options that are only meaningful
  for C++ programs.  You can also use most of the GNU compiler options
  regardless of what language your program is in.  For example, you might
! compile a file 'firstClass.C' like this:
  
       g++ -g -fstrict-enums -O -c firstClass.C
  
! In this example, only '-fstrict-enums' is an option meant only for C++
  programs; you can use the other options with any language supported by
  GCC.
  
!  Some options for compiling C programs, such as '-std', are also
  relevant for C++ programs.  *Note Options Controlling C Dialect: C
  Dialect Options.
  
   Here is a list of options that are _only_ for compiling C++ programs:
  
! '-fabi-version=N'
       Use version N of the C++ ABI.  The default is version 0.
  
       Version 0 refers to the version conforming most closely to the C++
--- 3070,3090 ----
  This section describes the command-line options that are only meaningful
  for C++ programs.  You can also use most of the GNU compiler options
  regardless of what language your program is in.  For example, you might
! compile a file ‘firstClass.C’ like this:
  
       g++ -g -fstrict-enums -O -c firstClass.C
  
! In this example, only ‘-fstrict-enums’ is an option meant only for C++
  programs; you can use the other options with any language supported by
  GCC.
  
!  Some options for compiling C programs, such as ‘-std’, are also
  relevant for C++ programs.  *Note Options Controlling C Dialect: C
  Dialect Options.
  
   Here is a list of options that are _only_ for compiling C++ programs:
  
! ‘-fabi-version=N’
       Use version N of the C++ ABI.  The default is version 0.
  
       Version 0 refers to the version conforming most closely to the C++
*************** Dialect Options.
*** 3118,3134 ****
       function-cv-qualifiers.
  
       Version 9, which first appeared in G++ 5.2, corrects the alignment
!      of 'nullptr_t'.
  
       Version 10, which first appeared in G++ 6.1, adds mangling of
       attributes that affect type identity, such as ia32 calling
!      convention attributes (e.g. 'stdcall').
  
       Version 11, which first appeared in G++ 7, corrects the mangling of
       sizeof...  expressions and operator names.  For multiple entities
       with the same name within a function, that are declared in
       different scopes, the mangling now changes starting with the
!      twelfth occurrence.  It also implies '-fnew-inheriting-ctors'.
  
       Version 12, which first appeared in G++ 8, corrects the calling
       conventions for empty classes on the x86_64 target and for classes
--- 3122,3138 ----
       function-cv-qualifiers.
  
       Version 9, which first appeared in G++ 5.2, corrects the alignment
!      of ‘nullptr_t’.
  
       Version 10, which first appeared in G++ 6.1, adds mangling of
       attributes that affect type identity, such as ia32 calling
!      convention attributes (e.g. ‘stdcall’).
  
       Version 11, which first appeared in G++ 7, corrects the mangling of
       sizeof...  expressions and operator names.  For multiple entities
       with the same name within a function, that are declared in
       different scopes, the mangling now changes starting with the
!      twelfth occurrence.  It also implies ‘-fnew-inheriting-ctors’.
  
       Version 12, which first appeared in G++ 8, corrects the calling
       conventions for empty classes on the x86_64 target and for classes
*************** Dialect Options.
*** 3146,3152 ****
       tag regression.
  
       Version 16, which first appeared in G++ 11, changes the mangling of
!      '__alignof__' to be distinct from that of 'alignof', and dependent
       operator names.
  
       Version 17, which first appeared in G++ 12, fixes layout of classes
--- 3150,3156 ----
       tag regression.
  
       Version 16, which first appeared in G++ 11, changes the mangling of
!      ‘__alignof__’ to be distinct from that of ‘alignof’, and dependent
       operator names.
  
       Version 17, which first appeared in G++ 12, fixes layout of classes
*************** Dialect Options.
*** 3156,3199 ****
       Version 18, which first appeard in G++ 13, fixes manglings of
       lambdas that have additional context.
  
!      See also '-Wabi'.
  
! '-fabi-compat-version=N'
       On targets that support strong aliases, G++ works around mangling
       changes by creating an alias with the correct mangled name when
       defining a symbol with an incorrect mangled name.  This switch
       specifies which ABI version to use for the alias.
  
!      With '-fabi-version=0' (the default), this defaults to 13 (GCC 8.2
       compatibility).  If another ABI version is explicitly selected,
       this defaults to 0.  For compatibility with GCC versions 3.2
!      through 4.9, use '-fabi-compat-version=2'.
  
!      If this option is not provided but '-Wabi=N' is, that version is
       used for compatibility aliases.  If this option is provided along
!      with '-Wabi' (without the version), the version from this option is
       used for the warning.
  
! '-fno-access-control'
       Turn off all access checking.  This switch is mainly useful for
       working around bugs in the access control code.
  
! '-faligned-new'
!      Enable support for C++17 'new' of types that require more alignment
!      than 'void* ::operator new(std::size_t)' provides.  A numeric
!      argument such as '-faligned-new=32' can be used to specify how much
       alignment (in bytes) is provided by that function, but few users
!      will need to override the default of 'alignof(std::max_align_t)'.
  
!      This flag is enabled by default for '-std=c++17'.
  
! '-fchar8_t'
! '-fno-char8_t'
!      Enable support for 'char8_t' as adopted for C++20.  This includes
!      the addition of a new 'char8_t' fundamental type, changes to the
       types of UTF-8 string and character literals, new signatures for
       user-defined literals, associated standard library updates, and new
!      '__cpp_char8_t' and '__cpp_lib_char8_t' feature test macros.
  
       This option enables functions to be overloaded for ordinary and
       UTF-8 strings:
--- 3160,3203 ----
       Version 18, which first appeard in G++ 13, fixes manglings of
       lambdas that have additional context.
  
!      See also ‘-Wabi’.
  
! ‘-fabi-compat-version=N’
       On targets that support strong aliases, G++ works around mangling
       changes by creating an alias with the correct mangled name when
       defining a symbol with an incorrect mangled name.  This switch
       specifies which ABI version to use for the alias.
  
!      With ‘-fabi-version=0’ (the default), this defaults to 13 (GCC 8.2
       compatibility).  If another ABI version is explicitly selected,
       this defaults to 0.  For compatibility with GCC versions 3.2
!      through 4.9, use ‘-fabi-compat-version=2’.
  
!      If this option is not provided but ‘-Wabi=N’ is, that version is
       used for compatibility aliases.  If this option is provided along
!      with ‘-Wabi’ (without the version), the version from this option is
       used for the warning.
  
! ‘-fno-access-control’
       Turn off all access checking.  This switch is mainly useful for
       working around bugs in the access control code.
  
! ‘-faligned-new’
!      Enable support for C++17 ‘new’ of types that require more alignment
!      than ‘void* ::operator new(std::size_t)’ provides.  A numeric
!      argument such as ‘-faligned-new=32’ can be used to specify how much
       alignment (in bytes) is provided by that function, but few users
!      will need to override the default of ‘alignof(std::max_align_t)’.
  
!      This flag is enabled by default for ‘-std=c++17’.
  
! ‘-fchar8_t’
! ‘-fno-char8_t’
!      Enable support for ‘char8_t’ as adopted for C++20.  This includes
!      the addition of a new ‘char8_t’ fundamental type, changes to the
       types of UTF-8 string and character literals, new signatures for
       user-defined literals, associated standard library updates, and new
!      ‘__cpp_char8_t’ and ‘__cpp_lib_char8_t’ feature test macros.
  
       This option enables functions to be overloaded for ordinary and
       UTF-8 strings:
*************** Dialect Options.
*** 3215,3221 ****
       The change to the types of UTF-8 string and character literals
       introduces incompatibilities with ISO C++11 and later standards.
       For example, the following code is well-formed under ISO C++11, but
!      is ill-formed when '-fchar8_t' is specified.
  
            const char *cp = u8"xx";// error: invalid conversion from
                                    //        `const char8_t*' to `const char*'
--- 3219,3225 ----
       The change to the types of UTF-8 string and character literals
       introduces incompatibilities with ISO C++11 and later standards.
       For example, the following code is well-formed under ISO C++11, but
!      is ill-formed when ‘-fchar8_t’ is specified.
  
            const char *cp = u8"xx";// error: invalid conversion from
                                    //        `const char8_t*' to `const char*'
*************** Dialect Options.
*** 3229,3262 ****
                                    //        `basic_string' to non-scalar
                                    //        type `basic_string' requested
  
! '-fcheck-new'
!      Check that the pointer returned by 'operator new' is non-null
       before attempting to modify the storage allocated.  This check is
       normally unnecessary because the C++ standard specifies that
!      'operator new' only returns '0' if it is declared 'throw()', in
       which case the compiler always checks the return value even without
!      this option.  In all other cases, when 'operator new' has a
       non-empty exception specification, memory exhaustion is signalled
!      by throwing 'std::bad_alloc'.  See also 'new (nothrow)'.
  
! '-fconcepts'
! '-fconcepts-ts'
       Enable support for the C++ Concepts feature for constraining
!      template arguments.  With '-std=c++20' and above, Concepts are part
!      of the language standard, so '-fconcepts' defaults to on.
  
       Some constructs that were allowed by the earlier C++ Extensions for
       Concepts Technical Specification, ISO 19217 (2015), but didn't make
       it into the standard, can additionally be enabled by
!      '-fconcepts-ts'.
  
! '-fconstexpr-depth=N'
       Set the maximum nested evaluation depth for C++11 constexpr
       functions to N.  A limit is needed to detect endless recursion
       during constant expression evaluation.  The minimum specified by
       the standard is 512.
  
! '-fconstexpr-cache-depth=N'
       Set the maximum level of nested evaluation depth for C++11
       constexpr functions that will be cached to N.  This is a heuristic
       that trades off compilation speed (when the cache avoids repeated
--- 3233,3266 ----
                                    //        `basic_string' to non-scalar
                                    //        type `basic_string' requested
  
! ‘-fcheck-new’
!      Check that the pointer returned by ‘operator new’ is non-null
       before attempting to modify the storage allocated.  This check is
       normally unnecessary because the C++ standard specifies that
!      ‘operator new’ only returns ‘0’ if it is declared ‘throw()’, in
       which case the compiler always checks the return value even without
!      this option.  In all other cases, when ‘operator new’ has a
       non-empty exception specification, memory exhaustion is signalled
!      by throwing ‘std::bad_alloc’.  See also ‘new (nothrow)’.
  
! ‘-fconcepts’
! ‘-fconcepts-ts’
       Enable support for the C++ Concepts feature for constraining
!      template arguments.  With ‘-std=c++20’ and above, Concepts are part
!      of the language standard, so ‘-fconcepts’ defaults to on.
  
       Some constructs that were allowed by the earlier C++ Extensions for
       Concepts Technical Specification, ISO 19217 (2015), but didn't make
       it into the standard, can additionally be enabled by
!      ‘-fconcepts-ts’.
  
! ‘-fconstexpr-depth=N’
       Set the maximum nested evaluation depth for C++11 constexpr
       functions to N.  A limit is needed to detect endless recursion
       during constant expression evaluation.  The minimum specified by
       the standard is 512.
  
! ‘-fconstexpr-cache-depth=N’
       Set the maximum level of nested evaluation depth for C++11
       constexpr functions that will be cached to N.  This is a heuristic
       that trades off compilation speed (when the cache avoids repeated
*************** Dialect Options.
*** 3266,3272 ****
       heavy constexpr calculations you might want to experiment to find
       which value works best for you.
  
! '-fconstexpr-fp-except'
       Annex F of the C standard specifies that IEC559 floating point
       exceptions encountered at compile time should not stop compilation.
       C++ compilers have historically not followed this guidance, instead
--- 3270,3276 ----
       heavy constexpr calculations you might want to experiment to find
       which value works best for you.
  
! ‘-fconstexpr-fp-except’
       Annex F of the C standard specifies that IEC559 floating point
       exceptions encountered at compile time should not stop compilation.
       C++ compilers have historically not followed this guidance, instead
*************** Dialect Options.
*** 3277,3288 ****
  
            constexpr float inf = 1./0.; // OK with -fconstexpr-fp-except
  
! '-fconstexpr-loop-limit=N'
       Set the maximum number of iterations for a loop in C++14 constexpr
       functions to N.  A limit is needed to detect infinite loops during
       constant expression evaluation.  The default is 262144 (1<<18).
  
! '-fconstexpr-ops-limit=N'
       Set the maximum number of operations during a single constexpr
       evaluation.  Even when number of iterations of a single loop is
       limited with the above limit, if there are several nested loops and
--- 3281,3292 ----
  
            constexpr float inf = 1./0.; // OK with -fconstexpr-fp-except
  
! ‘-fconstexpr-loop-limit=N’
       Set the maximum number of iterations for a loop in C++14 constexpr
       functions to N.  A limit is needed to detect infinite loops during
       constant expression evaluation.  The default is 262144 (1<<18).
  
! ‘-fconstexpr-ops-limit=N’
       Set the maximum number of operations during a single constexpr
       evaluation.  Even when number of iterations of a single loop is
       limited with the above limit, if there are several nested loops and
*************** Dialect Options.
*** 3291,3297 ****
       many expressions need to be evaluated, the resulting constexpr
       evaluation might take too long.  The default is 33554432 (1<<25).
  
! '-fcontracts'
       Enable experimental support for the C++ Contracts feature, as
       briefly added to and then removed from the C++20 working paper
       (N4820).  The implementation also includes proposed enhancements
--- 3295,3301 ----
       many expressions need to be evaluated, the resulting constexpr
       evaluation might take too long.  The default is 33554432 (1<<25).
  
! ‘-fcontracts’
       Enable experimental support for the C++ Contracts feature, as
       briefly added to and then removed from the C++20 working paper
       (N4820).  The implementation also includes proposed enhancements
*************** Dialect Options.
*** 3310,3371 ****
       N4820 contracts, P1332 contracts, or P1429 contracts; these sets
       cannot be used together.
  
!      '-fcontract-mode=[on|off]'
            Control whether any contracts have any semantics at all.
            Defaults to on.
  
!      '-fcontract-assumption-mode=[on|off]'
!           [N4820] Control whether contracts with level 'axiom' should
            have the assume semantic.  Defaults to on.
  
!      '-fcontract-build-level=[off|default|audit]'
            [N4820] Specify which level of contracts to generate checks
!           for.  Defaults to 'default'.
  
!      '-fcontract-continuation-mode=[on|off]'
            [N4820] Control whether to allow the program to continue
            executing after a contract violation.  That is, do checked
!           contracts have the 'maybe' semantic described below rather
!           than the 'never' semantic.  Defaults to off.
  
!      '-fcontract-role=:,,'
            [P1332] Specify the concrete semantics for each contract level
            of a particular contract role.
  
!      '-fcontract-semantic=[default|audit|axiom]:'
            [P1429] Specify the concrete semantic for a particular
            contract level.
  
!      '-fcontract-strict-declarations=[on|off]'
            Control whether to reject adding contracts to a function after
            its first declaration.  Defaults to off.
  
       The possible concrete semantics for that can be specified with
!      '-fcontract-role' or '-fcontract-semantic' are:
  
!      'ignore'
            This contract has no effect.
  
!      'assume'
!           This contract is treated like C++23 '[[assume]]'.
  
!      'check_never_continue'
!      'never'
!      'abort'
            This contract is checked.  If it fails, the violation handler
!           is called.  If the handler returns, 'std::terminate' is
            called.
  
!      'check_maybe_continue'
!      'maybe'
            This contract is checked.  If it fails, the violation handler
            is called.  If the handler returns, execution continues
            normally.
  
! '-fcoroutines'
       Enable support for the C++ coroutines extension (experimental).
  
! '-fno-elide-constructors'
       The C++ standard allows an implementation to omit creating a
       temporary that is only used to initialize another object of the
       same type.  Specifying this option disables that optimization, and
--- 3314,3375 ----
       N4820 contracts, P1332 contracts, or P1429 contracts; these sets
       cannot be used together.
  
!      ‘-fcontract-mode=[on|off]’
            Control whether any contracts have any semantics at all.
            Defaults to on.
  
!      ‘-fcontract-assumption-mode=[on|off]’
!           [N4820] Control whether contracts with level ‘axiom’ should
            have the assume semantic.  Defaults to on.
  
!      ‘-fcontract-build-level=[off|default|audit]’
            [N4820] Specify which level of contracts to generate checks
!           for.  Defaults to ‘default’.
  
!      ‘-fcontract-continuation-mode=[on|off]’
            [N4820] Control whether to allow the program to continue
            executing after a contract violation.  That is, do checked
!           contracts have the ‘maybe’ semantic described below rather
!           than the ‘never’ semantic.  Defaults to off.
  
!      ‘-fcontract-role=:,,’
            [P1332] Specify the concrete semantics for each contract level
            of a particular contract role.
  
!      ‘-fcontract-semantic=[default|audit|axiom]:’
            [P1429] Specify the concrete semantic for a particular
            contract level.
  
!      ‘-fcontract-strict-declarations=[on|off]’
            Control whether to reject adding contracts to a function after
            its first declaration.  Defaults to off.
  
       The possible concrete semantics for that can be specified with
!      ‘-fcontract-role’ or ‘-fcontract-semantic’ are:
  
!      ‘ignore’
            This contract has no effect.
  
!      ‘assume’
!           This contract is treated like C++23 ‘[[assume]]’.
  
!      ‘check_never_continue’
!      ‘never’
!      ‘abort’
            This contract is checked.  If it fails, the violation handler
!           is called.  If the handler returns, ‘std::terminate’ is
            called.
  
!      ‘check_maybe_continue’
!      ‘maybe’
            This contract is checked.  If it fails, the violation handler
            is called.  If the handler returns, execution continues
            normally.
  
! ‘-fcoroutines’
       Enable support for the C++ coroutines extension (experimental).
  
! ‘-fno-elide-constructors’
       The C++ standard allows an implementation to omit creating a
       temporary that is only used to initialize another object of the
       same type.  Specifying this option disables that optimization, and
*************** Dialect Options.
*** 3376,3394 ****
       In C++17, the compiler is required to omit these temporaries, but
       this option still affects trivial member functions.
  
! '-fno-enforce-eh-specs'
       Don't generate code to check for violation of exception
       specifications at run time.  This option violates the C++ standard,
       but may be useful for reducing code size in production builds, much
!      like defining 'NDEBUG'.  This does not give user code permission to
       throw exceptions in violation of the exception specifications; the
       compiler still optimizes based on the specifications, so throwing
       an unexpected exception results in undefined behavior at run time.
  
! '-fextern-tls-init'
! '-fno-extern-tls-init'
!      The C++11 and OpenMP standards allow 'thread_local' and
!      'threadprivate' variables to have dynamic (runtime) initialization.
       To support this, any use of such a variable goes through a wrapper
       function that performs any necessary initialization.  When the use
       and definition of the variable are in the same translation unit,
--- 3380,3398 ----
       In C++17, the compiler is required to omit these temporaries, but
       this option still affects trivial member functions.
  
! ‘-fno-enforce-eh-specs’
       Don't generate code to check for violation of exception
       specifications at run time.  This option violates the C++ standard,
       but may be useful for reducing code size in production builds, much
!      like defining ‘NDEBUG’.  This does not give user code permission to
       throw exceptions in violation of the exception specifications; the
       compiler still optimizes based on the specifications, so throwing
       an unexpected exception results in undefined behavior at run time.
  
! ‘-fextern-tls-init’
! ‘-fno-extern-tls-init’
!      The C++11 and OpenMP standards allow ‘thread_local’ and
!      ‘threadprivate’ variables to have dynamic (runtime) initialization.
       To support this, any use of such a variable goes through a wrapper
       function that performs any necessary initialization.  When the use
       and definition of the variable are in the same translation unit,
*************** Dialect Options.
*** 3400,3432 ****
       because the variable is statically initialized, or a use of the
       variable in the defining TU will be executed before any uses in
       another TU), they can avoid this overhead with the
!      '-fno-extern-tls-init' option.
  
       On targets that support symbol aliases, the default is
!      '-fextern-tls-init'.  On targets that do not support symbol
!      aliases, the default is '-fno-extern-tls-init'.
  
! '-ffold-simple-inlines'
! '-fno-fold-simple-inlines'
!      Permit the C++ frontend to fold calls to 'std::move',
!      'std::forward', 'std::addressof' and 'std::as_const'.  In contrast
       to inlining, this means no debug information will be generated for
       such calls.  Since these functions are rarely interesting to debug,
!      this flag is enabled by default unless '-fno-inline' is active.
  
! '-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.  This option is implied by the strict ISO C++ dialects:
!      '-ansi', '-std=c++98', '-std=c++11', etc.
  
! '-fimplicit-constexpr'
       Make inline functions implicitly constexpr, if they satisfy the
       requirements for a constexpr function.  This option can be used in
       C++14 mode or later.  This can result in initialization changing
       from dynamic to static and other optimizations.
  
! '-fno-implicit-templates'
       Never emit code for non-inline templates that are instantiated
       implicitly (i.e. by use); only emit code for explicit
       instantiations.  If you use this option, you must take care to
--- 3404,3436 ----
       because the variable is statically initialized, or a use of the
       variable in the defining TU will be executed before any uses in
       another TU), they can avoid this overhead with the
!      ‘-fno-extern-tls-init’ option.
  
       On targets that support symbol aliases, the default is
!      ‘-fextern-tls-init’.  On targets that do not support symbol
!      aliases, the default is ‘-fno-extern-tls-init’.
  
! ‘-ffold-simple-inlines’
! ‘-fno-fold-simple-inlines’
!      Permit the C++ frontend to fold calls to ‘std::move’,
!      ‘std::forward’, ‘std::addressof’ and ‘std::as_const’.  In contrast
       to inlining, this means no debug information will be generated for
       such calls.  Since these functions are rarely interesting to debug,
!      this flag is enabled by default unless ‘-fno-inline’ is active.
  
! ‘-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.  This option is implied by the strict ISO C++ dialects:
!      ‘-ansi’, ‘-std=c++98’, ‘-std=c++11’, etc.
  
! ‘-fimplicit-constexpr’
       Make inline functions implicitly constexpr, if they satisfy the
       requirements for a constexpr function.  This option can be used in
       C++14 mode or later.  This can result in initialization changing
       from dynamic to static and other optimizations.
  
! ‘-fno-implicit-templates’
       Never emit code for non-inline templates that are instantiated
       implicitly (i.e. by use); only emit code for explicit
       instantiations.  If you use this option, you must take care to
*************** Dialect Options.
*** 3434,3463 ****
       instantiations to avoid getting undefined symbols at link time.
       *Note Template Instantiation::, for more information.
  
! '-fno-implicit-inline-templates'
       Don't emit code for implicit instantiations of inline templates,
       either.  The default is to handle inlines differently so that
       compiles with and without optimization need the same set of
       explicit instantiations.
  
! '-fno-implement-inlines'
       To save space, do not emit out-of-line copies of inline functions
!      controlled by '#pragma implementation'.  This causes linker errors
       if these functions are not inlined everywhere they are called.
  
! '-fmodules-ts'
! '-fno-modules-ts'
       Enable support for C++20 modules (*note C++ Modules::).  The
!      '-fno-modules-ts' is usually not needed, as that is the default.
       Even though this is a C++20 feature, it is not currently implicitly
       enabled by selecting that standard version.
  
! '-fmodule-header'
! '-fmodule-header=user'
! '-fmodule-header=system'
       Compile a header file to create an importable header unit.
  
! '-fmodule-implicit-inline'
       Member functions defined in their class definitions are not
       implicitly inline for modular code.  This is different to
       traditional C++ behavior, for good reasons.  However, it may result
--- 3438,3467 ----
       instantiations to avoid getting undefined symbols at link time.
       *Note Template Instantiation::, for more information.
  
! ‘-fno-implicit-inline-templates’
       Don't emit code for implicit instantiations of inline templates,
       either.  The default is to handle inlines differently so that
       compiles with and without optimization need the same set of
       explicit instantiations.
  
! ‘-fno-implement-inlines’
       To save space, do not emit out-of-line copies of inline functions
!      controlled by ‘#pragma implementation’.  This causes linker errors
       if these functions are not inlined everywhere they are called.
  
! ‘-fmodules-ts’
! ‘-fno-modules-ts’
       Enable support for C++20 modules (*note C++ Modules::).  The
!      ‘-fno-modules-ts’ is usually not needed, as that is the default.
       Even though this is a C++20 feature, it is not currently implicitly
       enabled by selecting that standard version.
  
! ‘-fmodule-header’
! ‘-fmodule-header=user’
! ‘-fmodule-header=system’
       Compile a header file to create an importable header unit.
  
! ‘-fmodule-implicit-inline’
       Member functions defined in their class definitions are not
       implicitly inline for modular code.  This is different to
       traditional C++ behavior, for good reasons.  However, it may result
*************** Dialect Options.
*** 3467,3575 ****
       (Such definitions outside of a named module remain implicitly
       inline, regardless.)
  
! '-fno-module-lazy'
       Disable lazy module importing and module mapper creation.
  
! '-fmodule-mapper=[HOSTNAME]:PORT[?IDENT]'
! '-fmodule-mapper=|PROGRAM[?IDENT] ARGS...'
! '-fmodule-mapper==SOCKET[?IDENT]'
! '-fmodule-mapper=<>[INOUT][?IDENT]'
! '-fmodule-mapper=OUT[?IDENT]'
! '-fmodule-mapper=FILE[?IDENT]'
       An oracle to query for module name to filename mappings.  If
!      unspecified the 'CXX_MODULE_MAPPER' environment variable is used,
       and if that is unset, an in-process default is provided.
  
! '-fmodule-only'
       Only emit the Compiled Module Interface, inhibiting any object
       file.
  
! '-fms-extensions'
       Disable Wpedantic warnings about constructs used in MFC, such as
       implicit int and getting a pointer to member function via
       non-standard syntax.
  
! '-fnew-inheriting-ctors'
       Enable the P0136 adjustment to the semantics of C++11 constructor
       inheritance.  This is part of C++17 but also considered to be a
       Defect Report against C++11 and C++14.  This flag is enabled by
!      default unless '-fabi-version=10' or lower is specified.
  
! '-fnew-ttp-matching'
       Enable the P0522 resolution to Core issue 150, template template
       parameters and default arguments: this allows a template with
       default template arguments as an argument for a template template
       parameter with fewer template parameters.  This flag is enabled by
!      default for '-std=c++17'.
  
! '-fno-nonansi-builtins'
       Disable built-in declarations of functions that are not mandated by
!      ANSI/ISO C.  These include 'ffs', 'alloca', '_exit', 'index',
!      'bzero', 'conjf', and other related functions.
  
! '-fnothrow-opt'
!      Treat a 'throw()' exception specification as if it were a
!      'noexcept' specification to reduce or eliminate the text size
       overhead relative to a function with no exception specification.
       If the function has local variables of types with non-trivial
       destructors, the exception specification actually makes the
       function smaller because the EH cleanups for those variables can be
       optimized away.  The semantic effect is that an exception thrown
       out of a function with such an exception specification results in a
!      call to 'terminate' rather than 'unexpected'.
  
! '-fno-operator-names'
!      Do not treat the operator name keywords 'and', 'bitand', 'bitor',
!      'compl', 'not', 'or' and 'xor' as synonyms as keywords.
  
! '-fno-optional-diags'
       Disable diagnostics that the standard says a compiler does not need
       to issue.  Currently, the only such diagnostic issued by G++ is the
       one for a name having multiple meanings within a class.
  
! '-fpermissive'
       Downgrade some diagnostics about nonconformant code from errors to
!      warnings.  Thus, using '-fpermissive' allows some nonconforming
       code to compile.
  
! '-fno-pretty-templates'
       When an error message refers to a specialization of a function
       template, the compiler normally prints the signature of the
       template followed by the template arguments and any typedefs or
!      typenames in the signature (e.g. 'void f(T) [with T = int]' rather
!      than 'void f(int)') so that it's clear which template is involved.
       When an error message refers to a specialization of a class
       template, the compiler omits any template arguments that match the
       default template arguments for that template.  If either of these
       behaviors make it harder to understand the error message rather
!      than easier, you can use '-fno-pretty-templates' to disable them.
  
! '-fno-rtti'
       Disable generation of information about every class with virtual
       functions for use by the C++ run-time type identification features
!      ('dynamic_cast' and 'typeid').  If you don't use those parts of the
       language, you can save some space by using this flag.  Note that
       exception handling uses the same information, but G++ generates it
!      as needed.  The 'dynamic_cast' operator can still be used for casts
!      that do not require run-time type information, i.e. casts to 'void
!      *' or to unambiguous base classes.
  
!      Mixing code compiled with '-frtti' with that compiled with
!      '-fno-rtti' may not work.  For example, programs may fail to link
!      if a class compiled with '-fno-rtti' is used as a base for a class
!      compiled with '-frtti'.
  
! '-fsized-deallocation'
       Enable the built-in global declarations
            void operator delete (void *, std::size_t) noexcept;
            void operator delete[] (void *, std::size_t) noexcept;
       as introduced in C++14.  This is useful for user-defined
       replacement deallocation functions that, for example, use the size
       of the object to make deallocation faster.  Enabled by default
!      under '-std=c++14' and above.  The flag '-Wsized-deallocation'
       warns about places that might want to add a definition.
  
! '-fstrict-enums'
       Allow the compiler to optimize using the assumption that a value of
       enumerated type can only be one of the values of the enumeration
       (as defined in the C++ standard; basically, a value that can be
--- 3471,3579 ----
       (Such definitions outside of a named module remain implicitly
       inline, regardless.)
  
! ‘-fno-module-lazy’
       Disable lazy module importing and module mapper creation.
  
! ‘-fmodule-mapper=[HOSTNAME]:PORT[?IDENT]’
! ‘-fmodule-mapper=|PROGRAM[?IDENT] ARGS...’
! ‘-fmodule-mapper==SOCKET[?IDENT]’
! ‘-fmodule-mapper=<>[INOUT][?IDENT]’
! ‘-fmodule-mapper=OUT[?IDENT]’
! ‘-fmodule-mapper=FILE[?IDENT]’
       An oracle to query for module name to filename mappings.  If
!      unspecified the ‘CXX_MODULE_MAPPER’ environment variable is used,
       and if that is unset, an in-process default is provided.
  
! ‘-fmodule-only’
       Only emit the Compiled Module Interface, inhibiting any object
       file.
  
! ‘-fms-extensions’
       Disable Wpedantic warnings about constructs used in MFC, such as
       implicit int and getting a pointer to member function via
       non-standard syntax.
  
! ‘-fnew-inheriting-ctors’
       Enable the P0136 adjustment to the semantics of C++11 constructor
       inheritance.  This is part of C++17 but also considered to be a
       Defect Report against C++11 and C++14.  This flag is enabled by
!      default unless ‘-fabi-version=10’ or lower is specified.
  
! ‘-fnew-ttp-matching’
       Enable the P0522 resolution to Core issue 150, template template
       parameters and default arguments: this allows a template with
       default template arguments as an argument for a template template
       parameter with fewer template parameters.  This flag is enabled by
!      default for ‘-std=c++17’.
  
! ‘-fno-nonansi-builtins’
       Disable built-in declarations of functions that are not mandated by
!      ANSI/ISO C.  These include ‘ffs’, ‘alloca’, ‘_exit’, ‘index’,
!      ‘bzero’, ‘conjf’, and other related functions.
  
! ‘-fnothrow-opt’
!      Treat a ‘throw()’ exception specification as if it were a
!      ‘noexcept’ specification to reduce or eliminate the text size
       overhead relative to a function with no exception specification.
       If the function has local variables of types with non-trivial
       destructors, the exception specification actually makes the
       function smaller because the EH cleanups for those variables can be
       optimized away.  The semantic effect is that an exception thrown
       out of a function with such an exception specification results in a
!      call to ‘terminate’ rather than ‘unexpected’.
  
! ‘-fno-operator-names’
!      Do not treat the operator name keywords ‘and’, ‘bitand’, ‘bitor’,
!      ‘compl’, ‘not’, ‘or’ and ‘xor’ as synonyms as keywords.
  
! ‘-fno-optional-diags’
       Disable diagnostics that the standard says a compiler does not need
       to issue.  Currently, the only such diagnostic issued by G++ is the
       one for a name having multiple meanings within a class.
  
! ‘-fpermissive’
       Downgrade some diagnostics about nonconformant code from errors to
!      warnings.  Thus, using ‘-fpermissive’ allows some nonconforming
       code to compile.
  
! ‘-fno-pretty-templates’
       When an error message refers to a specialization of a function
       template, the compiler normally prints the signature of the
       template followed by the template arguments and any typedefs or
!      typenames in the signature (e.g. ‘void f(T) [with T = int]’ rather
!      than ‘void f(int)’) so that it's clear which template is involved.
       When an error message refers to a specialization of a class
       template, the compiler omits any template arguments that match the
       default template arguments for that template.  If either of these
       behaviors make it harder to understand the error message rather
!      than easier, you can use ‘-fno-pretty-templates’ to disable them.
  
! ‘-fno-rtti’
       Disable generation of information about every class with virtual
       functions for use by the C++ run-time type identification features
!      (‘dynamic_cast’ and ‘typeid’).  If you don't use those parts of the
       language, you can save some space by using this flag.  Note that
       exception handling uses the same information, but G++ generates it
!      as needed.  The ‘dynamic_cast’ operator can still be used for casts
!      that do not require run-time type information, i.e. casts to ‘void
!      *’ or to unambiguous base classes.
  
!      Mixing code compiled with ‘-frtti’ with that compiled with
!      ‘-fno-rtti’ may not work.  For example, programs may fail to link
!      if a class compiled with ‘-fno-rtti’ is used as a base for a class
!      compiled with ‘-frtti’.
  
! ‘-fsized-deallocation’
       Enable the built-in global declarations
            void operator delete (void *, std::size_t) noexcept;
            void operator delete[] (void *, std::size_t) noexcept;
       as introduced in C++14.  This is useful for user-defined
       replacement deallocation functions that, for example, use the size
       of the object to make deallocation faster.  Enabled by default
!      under ‘-std=c++14’ and above.  The flag ‘-Wsized-deallocation’
       warns about places that might want to add a definition.
  
! ‘-fstrict-enums’
       Allow the compiler to optimize using the assumption that a value of
       enumerated type can only be one of the values of the enumeration
       (as defined in the C++ standard; basically, a value that can be
*************** Dialect Options.
*** 3578,3596 ****
       uses a cast to convert an arbitrary integer value to the enumerated
       type.
  
! '-fstrong-eval-order'
       Evaluate member access, array subscripting, and shift expressions
       in left-to-right order, and evaluate assignment in right-to-left
!      order, as adopted for C++17.  Enabled by default with '-std=c++17'.
!      '-fstrong-eval-order=some' enables just the ordering of member
       access and shift expressions, and is the default without
!      '-std=c++17'.
  
! '-ftemplate-backtrace-limit=N'
       Set the maximum number of template instantiation notes for a single
       warning or error to N.  The default value is 10.
  
! '-ftemplate-depth=N'
       Set the maximum instantiation depth for template classes to N.  A
       limit on the template instantiation depth is needed to detect
       endless recursions during template class instantiation.  ANSI/ISO
--- 3582,3600 ----
       uses a cast to convert an arbitrary integer value to the enumerated
       type.
  
! ‘-fstrong-eval-order’
       Evaluate member access, array subscripting, and shift expressions
       in left-to-right order, and evaluate assignment in right-to-left
!      order, as adopted for C++17.  Enabled by default with ‘-std=c++17’.
!      ‘-fstrong-eval-order=some’ enables just the ordering of member
       access and shift expressions, and is the default without
!      ‘-std=c++17’.
  
! ‘-ftemplate-backtrace-limit=N’
       Set the maximum number of template instantiation notes for a single
       warning or error to N.  The default value is 10.
  
! ‘-ftemplate-depth=N’
       Set the maximum instantiation depth for template classes to N.  A
       limit on the template instantiation depth is needed to detect
       endless recursions during template class instantiation.  ANSI/ISO
*************** Dialect Options.
*** 3599,3629 ****
       the compiler can run out of stack space before hitting 1024 in some
       situations.
  
! '-fno-threadsafe-statics'
       Do not emit the extra code to use the routines specified in the C++
       ABI for thread-safe initialization of local statics.  You can use
       this option to reduce code size slightly in code that doesn't need
       to be thread-safe.
  
! '-fuse-cxa-atexit'
       Register destructors for objects with static storage duration with
!      the '__cxa_atexit' function rather than the 'atexit' function.
       This option is required for fully standards-compliant handling of
       static destructors, but only works if your C library supports
!      '__cxa_atexit'.
  
! '-fno-use-cxa-get-exception-ptr'
!      Don't use the '__cxa_get_exception_ptr' runtime routine.  This
!      causes 'std::uncaught_exception' to be incorrect, but is necessary
       if the runtime routine is not available.
  
! '-fvisibility-inlines-hidden'
       This switch declares that the user does not attempt to compare
       pointers to inline functions or methods where the addresses of the
       two functions are taken in different shared objects.
  
       The effect of this is that GCC may, effectively, mark inline
!      methods with '__attribute__ ((visibility ("hidden")))' so that they
       do not appear in the export table of a DSO and do not require a PLT
       indirection when used within the DSO.  Enabling this option can
       have a dramatic effect on load and link times of a DSO as it
--- 3603,3633 ----
       the compiler can run out of stack space before hitting 1024 in some
       situations.
  
! ‘-fno-threadsafe-statics’
       Do not emit the extra code to use the routines specified in the C++
       ABI for thread-safe initialization of local statics.  You can use
       this option to reduce code size slightly in code that doesn't need
       to be thread-safe.
  
! ‘-fuse-cxa-atexit’
       Register destructors for objects with static storage duration with
!      the ‘__cxa_atexit’ function rather than the ‘atexit’ function.
       This option is required for fully standards-compliant handling of
       static destructors, but only works if your C library supports
!      ‘__cxa_atexit’.
  
! ‘-fno-use-cxa-get-exception-ptr’
!      Don't use the ‘__cxa_get_exception_ptr’ runtime routine.  This
!      causes ‘std::uncaught_exception’ to be incorrect, but is necessary
       if the runtime routine is not available.
  
! ‘-fvisibility-inlines-hidden’
       This switch declares that the user does not attempt to compare
       pointers to inline functions or methods where the addresses of the
       two functions are taken in different shared objects.
  
       The effect of this is that GCC may, effectively, mark inline
!      methods with ‘__attribute__ ((visibility ("hidden")))’ so that they
       do not appear in the export table of a DSO and do not require a PLT
       indirection when used within the DSO.  Enabling this option can
       have a dramatic effect on load and link times of a DSO as it
*************** Dialect Options.
*** 3645,3658 ****
       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.
  
--- 3649,3662 ----
       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.
  
*************** Dialect Options.
*** 3661,3667 ****
            shared object: those declarations are permitted if they are
            permitted when this option is not used.
  
!      In new code it is better to use '-fvisibility=hidden' and export
       those classes that are intended to be externally visible.
       Unfortunately it is possible for code to rely, perhaps
       accidentally, on the Visual Studio behavior.
--- 3665,3671 ----
            shared object: those declarations are permitted if they are
            permitted when this option is not used.
  
!      In new code it is better to use ‘-fvisibility=hidden’ and export
       those classes that are intended to be externally visible.
       Unfortunately it is possible for code to rely, perhaps
       accidentally, on the Visual Studio behavior.
*************** Dialect Options.
*** 3674,3739 ****
       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++ uses weak symbols if they are available.
       This option exists only for testing, and should not be used by
       end-users; it results in inferior code and has no benefits.  This
       option may be removed in a future release of G++.
  
! '-fext-numeric-literals (C++ and Objective-C++ only)'
       Accept imaginary, fixed-point, or machine-defined literal number
       suffixes as GNU extensions.  When this option is turned off these
       suffixes are treated as C++11 user-defined literal numeric
       suffixes.  This is on by default for all pre-C++11 dialects and all
!      GNU dialects: '-std=c++98', '-std=gnu++98', '-std=gnu++11',
!      '-std=gnu++14'.  This option is off by default for ISO C++11
!      onwards ('-std=c++11', ...).
  
! '-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.)
  
! '-flang-info-include-translate'
! '-flang-info-include-translate-not'
! '-flang-info-include-translate=HEADER'
       Inform of include translation events.  The first will note accepted
       include translations, the second will note declined include
       translations.  The HEADER form will inform of include translations
       relating to that specific header.  If HEADER is of the form
!      '"user"' or '' it will be resolved to a specific user or
       system header using the include path.
  
! '-flang-info-module-cmi'
! '-flang-info-module-cmi=MODULE'
       Inform of Compiled Module Interface pathnames.  The first will note
       all read CMI pathnames.  The MODULE form will not reading a
       specific module's CMI. MODULE may be a named module or a
       header-unit (the latter indicated by either being a pathname
!      containing directory separators or enclosed in '<>' or '""').
  
! '-stdlib=LIBSTDC++,LIBC++'
       When G++ is configured to support this option, it allows
       specification of alternate C++ runtime libraries.  Two options are
       available: LIBSTDC++ (the default, native C++ runtime for G++) and
       LIBC++ which is the C++ runtime installed on some operating systems
       (e.g.  Darwin versions from Darwin11 onwards).  The option switches
       G++ to use the headers from the specified library and to emit
!      '-lstdc++' or '-lc++' respectively, when a C++ runtime is required
       for linking.
  
   In addition, these warning options have meanings only for C++ programs:
  
! '-Wabi-tag (C++ and Objective-C++ only)'
       Warn when a type with an ABI tag is used in a context that does not
       have that ABI tag.  See *note C++ Attributes:: for more information
       about ABI tags.
  
! '-Wcomma-subscript (C++ and Objective-C++ only)'
       Warn about uses of a comma expression within a subscripting
       expression.  This usage was deprecated in C++20 and is going to be
!      removed in C++23.  However, a comma expression wrapped in '( )' is
       not deprecated.  Example:
  
            void f(int *a, int b, int c) {
--- 3678,3743 ----
       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++ uses weak symbols if they are available.
       This option exists only for testing, and should not be used by
       end-users; it results in inferior code and has no benefits.  This
       option may be removed in a future release of G++.
  
! ‘-fext-numeric-literals (C++ and Objective-C++ only)’
       Accept imaginary, fixed-point, or machine-defined literal number
       suffixes as GNU extensions.  When this option is turned off these
       suffixes are treated as C++11 user-defined literal numeric
       suffixes.  This is on by default for all pre-C++11 dialects and all
!      GNU dialects: ‘-std=c++98’, ‘-std=gnu++98’, ‘-std=gnu++11’,
!      ‘-std=gnu++14’.  This option is off by default for ISO C++11
!      onwards (‘-std=c++11’, ...).
  
! ‘-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.)
  
! ‘-flang-info-include-translate’
! ‘-flang-info-include-translate-not’
! ‘-flang-info-include-translate=HEADER’
       Inform of include translation events.  The first will note accepted
       include translations, the second will note declined include
       translations.  The HEADER form will inform of include translations
       relating to that specific header.  If HEADER is of the form
!      ‘"user"’ or ‘’ it will be resolved to a specific user or
       system header using the include path.
  
! ‘-flang-info-module-cmi’
! ‘-flang-info-module-cmi=MODULE’
       Inform of Compiled Module Interface pathnames.  The first will note
       all read CMI pathnames.  The MODULE form will not reading a
       specific module's CMI. MODULE may be a named module or a
       header-unit (the latter indicated by either being a pathname
!      containing directory separators or enclosed in ‘<>’ or ‘""’).
  
! ‘-stdlib=LIBSTDC++,LIBC++’
       When G++ is configured to support this option, it allows
       specification of alternate C++ runtime libraries.  Two options are
       available: LIBSTDC++ (the default, native C++ runtime for G++) and
       LIBC++ which is the C++ runtime installed on some operating systems
       (e.g.  Darwin versions from Darwin11 onwards).  The option switches
       G++ to use the headers from the specified library and to emit
!      ‘-lstdc++’ or ‘-lc++’ respectively, when a C++ runtime is required
       for linking.
  
   In addition, these warning options have meanings only for C++ programs:
  
! ‘-Wabi-tag (C++ and Objective-C++ only)’
       Warn when a type with an ABI tag is used in a context that does not
       have that ABI tag.  See *note C++ Attributes:: for more information
       about ABI tags.
  
! ‘-Wcomma-subscript (C++ and Objective-C++ only)’
       Warn about uses of a comma expression within a subscripting
       expression.  This usage was deprecated in C++20 and is going to be
!      removed in C++23.  However, a comma expression wrapped in ‘( )’ is
       not deprecated.  Example:
  
            void f(int *a, int b, int c) {
*************** Dialect Options.
*** 3746,3757 ****
       supports the right number and types of arguments.  G++ will accept
       the formerly valid syntax for code that is not valid in C++23 but
       used to be valid but deprecated in C++20 with a pedantic warning
!      that can be disabled with '-Wno-comma-subscript'.
  
!      Enabled by default with '-std=c++20' unless '-Wno-deprecated', and
!      with '-std=c++23' regardless of '-Wno-deprecated'.
  
! '-Wctad-maybe-unsupported (C++ and Objective-C++ only)'
       Warn when performing class template argument deduction (CTAD) on a
       type with no explicitly written deduction guides.  This warning
       will point out cases where CTAD succeeded only because the compiler
--- 3750,3761 ----
       supports the right number and types of arguments.  G++ will accept
       the formerly valid syntax for code that is not valid in C++23 but
       used to be valid but deprecated in C++20 with a pedantic warning
!      that can be disabled with ‘-Wno-comma-subscript’.
  
!      Enabled by default with ‘-std=c++20’ unless ‘-Wno-deprecated’, and
!      with ‘-std=c++23’ regardless of ‘-Wno-deprecated’.
  
! ‘-Wctad-maybe-unsupported (C++ and Objective-C++ only)’
       Warn when performing class template argument deduction (CTAD) on a
       type with no explicitly written deduction guides.  This warning
       will point out cases where CTAD succeeded only because the compiler
*************** Dialect Options.
*** 3768,3781 ****
            // Guide with incomplete parameter type will never be considered.
            S(allow_ctad_t) -> S;
  
! '-Wctor-dtor-privacy (C++ and Objective-C++ only)'
       Warn when a class seems unusable because all the constructors or
       destructors in that class are private, and it has neither friends
       nor public static member functions.  Also warn if there are no
       non-private methods, and there's at least one private member
       function that isn't a constructor or destructor.
  
! '-Wdangling-reference (C++ and Objective-C++ only)'
       Warn when a reference is bound to a temporary whose lifetime has
       ended.  For example:
  
--- 3772,3785 ----
            // Guide with incomplete parameter type will never be considered.
            S(allow_ctad_t) -> S;
  
! ‘-Wctor-dtor-privacy (C++ and Objective-C++ only)’
       Warn when a class seems unusable because all the constructors or
       destructors in that class are private, and it has neither friends
       nor public static member functions.  Also warn if there are no
       non-private methods, and there's at least one private member
       function that isn't a constructor or destructor.
  
! ‘-Wdangling-reference (C++ and Objective-C++ only)’
       Warn when a reference is bound to a temporary whose lifetime has
       ended.  For example:
  
*************** Dialect Options.
*** 3785,3791 ****
       In the example above, two temporaries are created, one for each
       argument, and a reference to one of the temporaries is returned.
       However, both temporaries are destroyed at the end of the full
!      expression, so the reference 'r' is dangling.  This warning also
       detects dangling references in member initializer lists:
  
            const int& f(const int& i) { return i; }
--- 3789,3795 ----
       In the example above, two temporaries are created, one for each
       argument, and a reference to one of the temporaries is returned.
       However, both temporaries are destroyed at the end of the full
!      expression, so the reference ‘r’ is dangling.  This warning also
       detects dangling references in member initializer lists:
  
            const int& f(const int& i) { return i; }
*************** Dialect Options.
*** 3803,3844 ****
            const S& s = S().self(); // s is dangling
  
       Certain functions are safe in this respect, for example
!      'std::use_facet': they take and return a reference, but they don't
       return one of its arguments, which can fool the warning.  Such
       functions can be excluded from the warning by wrapping them in a
!      '#pragma':
  
            #pragma GCC diagnostic push
            #pragma GCC diagnostic ignored "-Wdangling-reference"
            const T& foo (const T&) { ... }
            #pragma GCC diagnostic pop
  
!      '-Wdangling-reference' also warns about code like
  
            auto p = std::minmax(1, 2);
  
!      where 'std::minmax' returns 'std::pair',
       and both references dangle after the end of the full expression
!      that contains the call to 'std::minmax'.
  
!      This warning is enabled by '-Wextra'.
  
! '-Wdelete-non-virtual-dtor (C++ and Objective-C++ only)'
!      Warn when 'delete' is used to destroy an instance of a class that
       has virtual functions and non-virtual destructor.  It is unsafe to
       delete an instance of a derived class through a pointer to a base
       class if the base class does not have a virtual destructor.  This
!      warning is enabled by '-Wall'.
  
! '-Wdeprecated-copy (C++ and Objective-C++ only)'
       Warn that the implicit declaration of a copy constructor or copy
       assignment operator is deprecated if the class has a user-provided
       copy constructor or copy assignment operator, in C++11 and up.
!      This warning is enabled by '-Wextra'.  With
!      '-Wdeprecated-copy-dtor', also deprecate if the class has a
       user-provided destructor.
  
! '-Wno-deprecated-enum-enum-conversion (C++ and Objective-C++ only)'
       Disable the warning about the case when the usual arithmetic
       conversions are applied on operands where one is of enumeration
       type and the other is of a different enumeration type.  This
--- 3807,3848 ----
            const S& s = S().self(); // s is dangling
  
       Certain functions are safe in this respect, for example
!      ‘std::use_facet’: they take and return a reference, but they don't
       return one of its arguments, which can fool the warning.  Such
       functions can be excluded from the warning by wrapping them in a
!      ‘#pragma’:
  
            #pragma GCC diagnostic push
            #pragma GCC diagnostic ignored "-Wdangling-reference"
            const T& foo (const T&) { ... }
            #pragma GCC diagnostic pop
  
!      ‘-Wdangling-reference’ also warns about code like
  
            auto p = std::minmax(1, 2);
  
!      where ‘std::minmax’ returns ‘std::pair’,
       and both references dangle after the end of the full expression
!      that contains the call to ‘std::minmax’.
  
!      This warning is enabled by ‘-Wextra’.
  
! ‘-Wdelete-non-virtual-dtor (C++ and Objective-C++ only)’
!      Warn when ‘delete’ is used to destroy an instance of a class that
       has virtual functions and non-virtual destructor.  It is unsafe to
       delete an instance of a derived class through a pointer to a base
       class if the base class does not have a virtual destructor.  This
!      warning is enabled by ‘-Wall’.
  
! ‘-Wdeprecated-copy (C++ and Objective-C++ only)’
       Warn that the implicit declaration of a copy constructor or copy
       assignment operator is deprecated if the class has a user-provided
       copy constructor or copy assignment operator, in C++11 and up.
!      This warning is enabled by ‘-Wextra’.  With
!      ‘-Wdeprecated-copy-dtor’, also deprecate if the class has a
       user-provided destructor.
  
! ‘-Wno-deprecated-enum-enum-conversion (C++ and Objective-C++ only)’
       Disable the warning about the case when the usual arithmetic
       conversions are applied on operands where one is of enumeration
       type and the other is of a different enumeration type.  This
*************** Dialect Options.
*** 3848,3858 ****
            enum E2 { f };
            int k = f - e;
  
!      '-Wdeprecated-enum-enum-conversion' is enabled by default with
!      '-std=c++20'.  In pre-C++20 dialects, this warning can be enabled
!      by '-Wenum-conversion'.
  
! '-Wno-deprecated-enum-float-conversion (C++ and Objective-C++ only)'
       Disable the warning about the case when the usual arithmetic
       conversions are applied on operands where one is of enumeration
       type and the other is of a floating-point type.  This conversion
--- 3852,3862 ----
            enum E2 { f };
            int k = f - e;
  
!      ‘-Wdeprecated-enum-enum-conversion’ is enabled by default with
!      ‘-std=c++20’.  In pre-C++20 dialects, this warning can be enabled
!      by ‘-Wenum-conversion’.
  
! ‘-Wno-deprecated-enum-float-conversion (C++ and Objective-C++ only)’
       Disable the warning about the case when the usual arithmetic
       conversions are applied on operands where one is of enumeration
       type and the other is of a floating-point type.  This conversion
*************** Dialect Options.
*** 3862,3892 ****
            enum E2 { f };
            bool b = e <= 3.7;
  
!      '-Wdeprecated-enum-float-conversion' is enabled by default with
!      '-std=c++20'.  In pre-C++20 dialects, this warning can be enabled
!      by '-Wenum-conversion'.
  
! '-Wno-init-list-lifetime (C++ and Objective-C++ only)'
!      Do not warn about uses of 'std::initializer_list' that are likely
       to result in dangling pointers.  Since the underlying array for an
!      'initializer_list' is handled like a normal C++ temporary object,
       it is easy to inadvertently keep a pointer to the array past the
       end of the array's lifetime.  For example:
  
!         * If a function returns a temporary 'initializer_list', or a
!           local 'initializer_list' variable, the array's lifetime ends
            at the end of the return statement, so the value returned has
            a dangling pointer.
  
!         * If a new-expression creates an 'initializer_list', the array
            only lives until the end of the enclosing full-expression, so
!           the 'initializer_list' in the heap has a dangling pointer.
  
!         * When an 'initializer_list' variable is assigned from a
            brace-enclosed initializer list, the temporary array created
            for the right side of the assignment only lives until the end
            of the full-expression, so at the next statement the
!           'initializer_list' variable has a dangling pointer.
  
                 // li's initial underlying array lives as long as li
                 std::initializer_list li = { 1,2,3 };
--- 3866,3896 ----
            enum E2 { f };
            bool b = e <= 3.7;
  
!      ‘-Wdeprecated-enum-float-conversion’ is enabled by default with
!      ‘-std=c++20’.  In pre-C++20 dialects, this warning can be enabled
!      by ‘-Wenum-conversion’.
  
! ‘-Wno-init-list-lifetime (C++ and Objective-C++ only)’
!      Do not warn about uses of ‘std::initializer_list’ that are likely
       to result in dangling pointers.  Since the underlying array for an
!      ‘initializer_list’ is handled like a normal C++ temporary object,
       it is easy to inadvertently keep a pointer to the array past the
       end of the array's lifetime.  For example:
  
!         • If a function returns a temporary ‘initializer_list’, or a
!           local ‘initializer_list’ variable, the array's lifetime ends
            at the end of the return statement, so the value returned has
            a dangling pointer.
  
!         • If a new-expression creates an ‘initializer_list’, the array
            only lives until the end of the enclosing full-expression, so
!           the ‘initializer_list’ in the heap has a dangling pointer.
  
!         • When an ‘initializer_list’ variable is assigned from a
            brace-enclosed initializer list, the temporary array created
            for the right side of the assignment only lives until the end
            of the full-expression, so at the next statement the
!           ‘initializer_list’ variable has a dangling pointer.
  
                 // li's initial underlying array lives as long as li
                 std::initializer_list li = { 1,2,3 };
*************** Dialect Options.
*** 3895,3920 ****
                 // now the temporary is gone and li has a dangling pointer
                 int i = li.begin()[0] // undefined behavior
  
!         * When a list constructor stores the 'begin' pointer from the
!           'initializer_list' argument, this doesn't extend the lifetime
            of the array, so if a class variable is constructed from a
!           temporary 'initializer_list', the pointer is left dangling by
            the end of the variable declaration statement.
  
! '-Winvalid-constexpr'
  
       Warn when a function never produces a constant expression.  In
!      C++20 and earlier, for every 'constexpr' function and function
       template, there must be at least one set of function arguments in
       at least one instantiation such that an invocation of the function
       or constructor could be an evaluated subexpression of a core
       constant expression.  C++23 removed this restriction, so it's
       possible to have a function or a function template marked
!      'constexpr' for which no invocation satisfies the requirements of a
       core constant expression.
  
       This warning is enabled as a pedantic warning by default in C++20
!      and earlier.  In C++23, '-Winvalid-constexpr' can be turned on, in
       which case it will be an ordinary warning.  For example:
  
            void f (int& i);
--- 3899,3924 ----
                 // now the temporary is gone and li has a dangling pointer
                 int i = li.begin()[0] // undefined behavior
  
!         • When a list constructor stores the ‘begin’ pointer from the
!           ‘initializer_list’ argument, this doesn't extend the lifetime
            of the array, so if a class variable is constructed from a
!           temporary ‘initializer_list’, the pointer is left dangling by
            the end of the variable declaration statement.
  
! ‘-Winvalid-constexpr’
  
       Warn when a function never produces a constant expression.  In
!      C++20 and earlier, for every ‘constexpr’ function and function
       template, there must be at least one set of function arguments in
       at least one instantiation such that an invocation of the function
       or constructor could be an evaluated subexpression of a core
       constant expression.  C++23 removed this restriction, so it's
       possible to have a function or a function template marked
!      ‘constexpr’ for which no invocation satisfies the requirements of a
       core constant expression.
  
       This warning is enabled as a pedantic warning by default in C++20
!      and earlier.  In C++23, ‘-Winvalid-constexpr’ can be turned on, in
       which case it will be an ordinary warning.  For example:
  
            void f (int& i);
*************** Dialect Options.
*** 3925,3942 ****
              f(i);
            }
  
! '-Winvalid-imported-macros'
       Verify all imported macro definitions are valid at the end of
       compilation.  This is not enabled by default, as it requires
       additional processing to determine.  It may be useful when
       preparing sets of header-units to ensure consistent macros.
  
! '-Wno-literal-suffix (C++ and Objective-C++ only)'
       Do not warn when a string or character literal is followed by a
       ud-suffix which does not begin with an underscore.  As a conforming
       extension, GCC treats such suffixes as separate preprocessing
       tokens in order to maintain backwards compatibility with code that
!      uses formatting macros from ''.  For example:
  
            #define __STDC_FORMAT_MACROS
            #include 
--- 3929,3946 ----
              f(i);
            }
  
! ‘-Winvalid-imported-macros’
       Verify all imported macro definitions are valid at the end of
       compilation.  This is not enabled by default, as it requires
       additional processing to determine.  It may be useful when
       preparing sets of header-units to ensure consistent macros.
  
! ‘-Wno-literal-suffix (C++ and Objective-C++ only)’
       Do not warn when a string or character literal is followed by a
       ud-suffix which does not begin with an underscore.  As a conforming
       extension, GCC treats such suffixes as separate preprocessing
       tokens in order to maintain backwards compatibility with code that
!      uses formatting macros from ‘’.  For example:
  
            #define __STDC_FORMAT_MACROS
            #include 
*************** Dialect Options.
*** 3947,3953 ****
              printf("My int64: %" PRId64"\n", i64);
            }
  
!      In this case, 'PRId64' is treated as a separate preprocessing
       token.
  
       This option also controls warnings when a user-defined literal
--- 3951,3957 ----
              printf("My int64: %" PRId64"\n", i64);
            }
  
!      In this case, ‘PRId64’ is treated as a separate preprocessing
       token.
  
       This option also controls warnings when a user-defined literal
*************** Dialect Options.
*** 3957,3988 ****
  
       These warnings are enabled by default.
  
! '-Wno-narrowing (C++ and Objective-C++ only)'
       For C++11 and later standards, narrowing conversions are diagnosed
       by default, as required by the standard.  A narrowing conversion
       from a constant produces an error, and a narrowing conversion from
!      a non-constant produces a warning, but '-Wno-narrowing' suppresses
       the diagnostic.  Note that this does not affect the meaning of
       well-formed code; narrowing conversions are still considered
       ill-formed in SFINAE contexts.
  
!      With '-Wnarrowing' in C++98, warn when a narrowing conversion
!      prohibited by C++11 occurs within '{ }', e.g.
  
            int i = { 2.2 }; // error: narrowing from double to int
  
!      This flag is included in '-Wall' and '-Wc++11-compat'.
  
! '-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.
  
! '-Wnoexcept-type (C++ and Objective-C++ only)'
!      Warn if the C++17 feature making 'noexcept' part of a function type
       changes the mangled name of a symbol relative to C++14.  Enabled by
!      '-Wabi' and '-Wc++17-compat'.
  
       As an example:
  
--- 3961,3992 ----
  
       These warnings are enabled by default.
  
! ‘-Wno-narrowing (C++ and Objective-C++ only)’
       For C++11 and later standards, narrowing conversions are diagnosed
       by default, as required by the standard.  A narrowing conversion
       from a constant produces an error, and a narrowing conversion from
!      a non-constant produces a warning, but ‘-Wno-narrowing’ suppresses
       the diagnostic.  Note that this does not affect the meaning of
       well-formed code; narrowing conversions are still considered
       ill-formed in SFINAE contexts.
  
!      With ‘-Wnarrowing’ in C++98, warn when a narrowing conversion
!      prohibited by C++11 occurs within ‘{ }’, e.g.
  
            int i = { 2.2 }; // error: narrowing from double to int
  
!      This flag is included in ‘-Wall’ and ‘-Wc++11-compat’.
  
! ‘-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.
  
! ‘-Wnoexcept-type (C++ and Objective-C++ only)’
!      Warn if the C++17 feature making ‘noexcept’ part of a function type
       changes the mangled name of a symbol relative to C++14.  Enabled by
!      ‘-Wabi’ and ‘-Wc++17-compat’.
  
       As an example:
  
*************** Dialect Options.
*** 3990,4006 ****
            void g() noexcept;
            void h() { f(g); }
  
!      In C++14, 'f' calls 'f', but in C++17 it calls
!      'f'.
  
! '-Wclass-memaccess (C++ and Objective-C++ only)'
       Warn when the destination of a call to a raw memory function such
!      as 'memset' or 'memcpy' is an object of class type, and when
       writing into such an object might bypass the class non-trivial or
       deleted constructor or copy assignment, violate const-correctness
       or encapsulation, or corrupt virtual table pointers.  Modifying the
       representation of such objects may violate invariants maintained by
!      member functions of the class.  For example, the call to 'memset'
       below is undefined because it modifies a non-trivial class object
       and is, therefore, diagnosed.  The safe way to either initialize or
       clear the storage of objects of such types is by using the
--- 3994,4010 ----
            void g() noexcept;
            void h() { f(g); }
  
!      In C++14, ‘f’ calls ‘f’, but in C++17 it calls
!      ‘f’.
  
! ‘-Wclass-memaccess (C++ and Objective-C++ only)’
       Warn when the destination of a call to a raw memory function such
!      as ‘memset’ or ‘memcpy’ is an object of class type, and when
       writing into such an object might bypass the class non-trivial or
       deleted constructor or copy assignment, violate const-correctness
       or encapsulation, or corrupt virtual table pointers.  Modifying the
       representation of such objects may violate invariants maintained by
!      member functions of the class.  For example, the call to ‘memset’
       below is undefined because it modifies a non-trivial class object
       and is, therefore, diagnosed.  The safe way to either initialize or
       clear the storage of objects of such types is by using the
*************** Dialect Options.
*** 4008,4036 ****
       available.
            std::string str = "abc";
            memset (&str, 0, sizeof str);
!      The '-Wclass-memaccess' option is enabled by '-Wall'.  Explicitly
!      casting the pointer to the class object to 'void *' or to a type
       that can be safely accessed by the raw memory function suppresses
       the warning.
  
! '-Wnon-virtual-dtor (C++ and Objective-C++ only)'
       Warn when a class has virtual functions and an accessible
       non-virtual destructor itself or in an accessible polymorphic base
       class, in which case it is possible but unsafe to delete an
       instance of a derived class through a pointer to the class itself
!      or base class.  This warning is automatically enabled if '-Weffc++'
!      is specified.  The '-Wdelete-non-virtual-dtor' option (enabled by
!      '-Wall') should be preferred because it warns about the unsafe
       cases without false positives.
  
! '-Wregister (C++ and Objective-C++ only)'
!      Warn on uses of the 'register' storage class specifier, except when
       it is part of the GNU *note Explicit Register Variables::
!      extension.  The use of the 'register' keyword as storage class
       specifier has been deprecated in C++11 and removed in C++17.
!      Enabled by default with '-std=c++17'.
  
! '-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:
  
--- 4012,4040 ----
       available.
            std::string str = "abc";
            memset (&str, 0, sizeof str);
!      The ‘-Wclass-memaccess’ option is enabled by ‘-Wall’.  Explicitly
!      casting the pointer to the class object to ‘void *’ or to a type
       that can be safely accessed by the raw memory function suppresses
       the warning.
  
! ‘-Wnon-virtual-dtor (C++ and Objective-C++ only)’
       Warn when a class has virtual functions and an accessible
       non-virtual destructor itself or in an accessible polymorphic base
       class, in which case it is possible but unsafe to delete an
       instance of a derived class through a pointer to the class itself
!      or base class.  This warning is automatically enabled if ‘-Weffc++’
!      is specified.  The ‘-Wdelete-non-virtual-dtor’ option (enabled by
!      ‘-Wall’) should be preferred because it warns about the unsafe
       cases without false positives.
  
! ‘-Wregister (C++ and Objective-C++ only)’
!      Warn on uses of the ‘register’ storage class specifier, except when
       it is part of the GNU *note Explicit Register Variables::
!      extension.  The use of the ‘register’ keyword as storage class
       specifier has been deprecated in C++11 and removed in C++17.
!      Enabled by default with ‘-std=c++17’.
  
! ‘-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:
  
*************** Dialect Options.
*** 4040,4051 ****
              A(): j (0), i (1) { }
            };
  
!      The compiler rearranges the member initializers for 'i' and 'j' to
       match the declaration order of the members, emitting a warning to
!      that effect.  This warning is enabled by '-Wall'.
  
! '-Wno-pessimizing-move (C++ and Objective-C++ only)'
!      This warning warns when a call to 'std::move' prevents copy
       elision.  A typical scenario when copy elision can occur is when
       returning in a function with a class return type, when the
       expression being returned is the name of a non-volatile automatic
--- 4044,4055 ----
              A(): j (0), i (1) { }
            };
  
!      The compiler rearranges the member initializers for ‘i’ and ‘j’ to
       match the declaration order of the members, emitting a warning to
!      that effect.  This warning is enabled by ‘-Wall’.
  
! ‘-Wno-pessimizing-move (C++ and Objective-C++ only)’
!      This warning warns when a call to ‘std::move’ prevents copy
       elision.  A typical scenario when copy elision can occur is when
       returning in a function with a class return type, when the
       expression being returned is the name of a non-volatile automatic
*************** Dialect Options.
*** 4062,4075 ****
              return std::move (t);
            }
  
!      But in this example, the 'std::move' call prevents copy elision.
  
!      This warning is enabled by '-Wall'.
  
! '-Wno-redundant-move (C++ and Objective-C++ only)'
!      This warning warns about redundant calls to 'std::move'; that is,
       when a move operation would have been performed even without the
!      'std::move' call.  This happens because the compiler is forced to
       treat the object as if it were an rvalue in certain situations such
       as returning a local variable, where copy elision isn't applicable.
       Consider:
--- 4066,4079 ----
              return std::move (t);
            }
  
!      But in this example, the ‘std::move’ call prevents copy elision.
  
!      This warning is enabled by ‘-Wall’.
  
! ‘-Wno-redundant-move (C++ and Objective-C++ only)’
!      This warning warns about redundant calls to ‘std::move’; that is,
       when a move operation would have been performed even without the
!      ‘std::move’ call.  This happens because the compiler is forced to
       treat the object as if it were an rvalue in certain situations such
       as returning a local variable, where copy elision isn't applicable.
       Consider:
*************** Dialect Options.
*** 4083,4089 ****
              return std::move (t);
            }
  
!      Here, the 'std::move' call is redundant.  Because G++ implements
       Core Issue 1579, another example is:
  
            struct T { // convertible to U
--- 4087,4093 ----
              return std::move (t);
            }
  
!      Here, the ‘std::move’ call is redundant.  Because G++ implements
       Core Issue 1579, another example is:
  
            struct T { // convertible to U
*************** Dialect Options.
*** 4103,4111 ****
       yet G++ treats the return value as if it were designated by an
       rvalue.
  
!      This warning is enabled by '-Wextra'.
  
! '-Wrange-loop-construct (C++ and Objective-C++ only)'
       This warning warns when a C++ range-based for-loop is creating an
       unnecessary copy.  This can happen when the range declaration is
       not a reference, but probably should be.  For example:
--- 4107,4115 ----
       yet G++ treats the return value as if it were designated by an
       rvalue.
  
!      This warning is enabled by ‘-Wextra’.
  
! ‘-Wrange-loop-construct (C++ and Objective-C++ only)’
       This warning warns when a C++ range-based for-loop is creating an
       unnecessary copy.  This can happen when the range declaration is
       not a reference, but probably should be.  For example:
*************** Dialect Options.
*** 4129,4140 ****
            }
  
       In the example above, in every iteration of the loop a temporary
!      value of type 'double' is created and destroyed, to which the
!      reference 'const double &' is bound.
  
!      This warning is enabled by '-Wall'.
  
! '-Wredundant-tags (C++ and Objective-C++ only)'
       Warn about redundant class-key and enum-key in references to class
       types and enumerated types in contexts where the key can be
       eliminated without causing an ambiguity.  For example:
--- 4133,4144 ----
            }
  
       In the example above, in every iteration of the loop a temporary
!      value of type ‘double’ is created and destroyed, to which the
!      reference ‘const double &’ is bound.
  
!      This warning is enabled by ‘-Wall’.
  
! ‘-Wredundant-tags (C++ and Objective-C++ only)’
       Warn about redundant class-key and enum-key in references to class
       types and enumerated types in contexts where the key can be
       eliminated without causing an ambiguity.  For example:
*************** Dialect Options.
*** 4148,4154 ****
            void foo ();   // "hides" struct foo
            void bar (struct foo&);  // no warning, keyword struct is necessary
  
! '-Wno-subobject-linkage (C++ and Objective-C++ only)'
       Do not warn if a class type has a base or a field whose type uses
       the anonymous namespace or depends on a type with no linkage.  If a
       type A depends on a type B with no or internal linkage, defining it
--- 4152,4158 ----
            void foo ();   // "hides" struct foo
            void bar (struct foo&);  // no warning, keyword struct is necessary
  
! ‘-Wno-subobject-linkage (C++ and Objective-C++ only)’
       Do not warn if a class type has a base or a field whose type uses
       the anonymous namespace or depends on a type with no linkage.  If a
       type A depends on a type B with no or internal linkage, defining it
*************** Dialect Options.
*** 4158,4223 ****
       warning is to give it internal linkage by putting it in an
       anonymous namespace as well.  The compiler doesn't give this
       warning for types defined in the main .C file, as those are
!      unlikely to have multiple definitions.  '-Wsubobject-linkage' is
       enabled by default.
  
! '-Weffc++ (C++ and Objective-C++ only)'
       Warn about violations of the following style guidelines from Scott
!      Meyers' 'Effective C++' series of books:
  
!         * Define a copy constructor and an assignment operator for
            classes with dynamically-allocated memory.
  
!         * Prefer initialization to assignment in constructors.
  
!         * Have 'operator=' return a reference to '*this'.
  
!         * Don't try to return a reference when you must return an
            object.
  
!         * Distinguish between prefix and postfix forms of increment and
            decrement operators.
  
!         * Never overload '&&', '||', or ','.
  
!      This option also enables '-Wnon-virtual-dtor', which is also one of
       the effective C++ recommendations.  However, the check is extended
       to warn about the lack of virtual destructor in accessible
       non-polymorphic bases classes too.
  
       When selecting this option, be aware that the standard library
!      headers do not obey all of these guidelines; use 'grep -v' to
       filter out those warnings.
  
! '-Wno-exceptions (C++ and Objective-C++ only)'
       Disable the warning about the case when an exception handler is
       shadowed by another handler, which can point out a wrong ordering
       of exception handlers.
  
! '-Wstrict-null-sentinel (C++ and Objective-C++ only)'
!      Warn about the use of an uncasted 'NULL' as sentinel.  When
!      compiling only with GCC this is a valid sentinel, as 'NULL' is
!      defined to '__null'.  Although it is a null pointer constant rather
       than a null pointer, it is guaranteed to be of the same size as a
       pointer.  But this use is not portable across different compilers.
  
! '-Wno-non-template-friend (C++ and Objective-C++ only)'
       Disable warnings when non-template friend functions are declared
       within a template.  In very old versions of GCC that predate
!      implementation of the ISO standard, declarations such as 'friend
!      int foo(int)', where the name of the friend is an unqualified-id,
       could be interpreted as a particular specialization of a template
       function; the warning exists to diagnose compatibility problems,
       and is enabled by default.
  
! '-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)'
! '-Woverloaded-virtual=N'
       Warn when a function declaration hides virtual functions from a
       base class.  For example, in:
  
--- 4162,4227 ----
       warning is to give it internal linkage by putting it in an
       anonymous namespace as well.  The compiler doesn't give this
       warning for types defined in the main .C file, as those are
!      unlikely to have multiple definitions.  ‘-Wsubobject-linkage’ is
       enabled by default.
  
! ‘-Weffc++ (C++ and Objective-C++ only)’
       Warn about violations of the following style guidelines from Scott
!      Meyers' ‘Effective C++’ series of books:
  
!         • Define a copy constructor and an assignment operator for
            classes with dynamically-allocated memory.
  
!         • Prefer initialization to assignment in constructors.
  
!         • Have ‘operator=’ return a reference to ‘*this’.
  
!         • Don't try to return a reference when you must return an
            object.
  
!         • Distinguish between prefix and postfix forms of increment and
            decrement operators.
  
!         • Never overload ‘&&’, ‘||’, or ‘,’.
  
!      This option also enables ‘-Wnon-virtual-dtor’, which is also one of
       the effective C++ recommendations.  However, the check is extended
       to warn about the lack of virtual destructor in accessible
       non-polymorphic bases classes too.
  
       When selecting this option, be aware that the standard library
!      headers do not obey all of these guidelines; use ‘grep -v’ to
       filter out those warnings.
  
! ‘-Wno-exceptions (C++ and Objective-C++ only)’
       Disable the warning about the case when an exception handler is
       shadowed by another handler, which can point out a wrong ordering
       of exception handlers.
  
! ‘-Wstrict-null-sentinel (C++ and Objective-C++ only)’
!      Warn about the use of an uncasted ‘NULL’ as sentinel.  When
!      compiling only with GCC this is a valid sentinel, as ‘NULL’ is
!      defined to ‘__null’.  Although it is a null pointer constant rather
       than a null pointer, it is guaranteed to be of the same size as a
       pointer.  But this use is not portable across different compilers.
  
! ‘-Wno-non-template-friend (C++ and Objective-C++ only)’
       Disable warnings when non-template friend functions are declared
       within a template.  In very old versions of GCC that predate
!      implementation of the ISO standard, declarations such as ‘friend
!      int foo(int)’, where the name of the friend is an unqualified-id,
       could be interpreted as a particular specialization of a template
       function; the warning exists to diagnose compatibility problems,
       and is enabled by default.
  
! ‘-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)’
! ‘-Woverloaded-virtual=N’
       Warn when a function declaration hides virtual functions from a
       base class.  For example, in:
  
*************** Dialect Options.
*** 4229,4235 ****
              void f(int); // does not override
            };
  
!      the 'A' class version of 'f' is hidden in 'B', and code like:
  
            B* b;
            b->f();
--- 4233,4239 ----
              void f(int); // does not override
            };
  
!      the ‘A’ class version of ‘f’ is hidden in ‘B’, and code like:
  
            B* b;
            b->f();
*************** Dialect Options.
*** 4238,4244 ****
  
       In cases where the different signatures are not an accident, the
       simplest solution is to add a using-declaration to the derived
!      class to un-hide the base function, e.g.  add 'using A::f;' to 'B'.
  
       The optional level suffix controls the behavior when all the
       declarations in the derived class override virtual functions in the
--- 4242,4248 ----
  
       In cases where the different signatures are not an accident, the
       simplest solution is to add a using-declaration to the derived
!      class to un-hide the base function, e.g.  add ‘using A::f;’ to ‘B’.
  
       The optional level suffix controls the behavior when all the
       declarations in the derived class override virtual functions in the
*************** Dialect Options.
*** 4258,4298 ****
       semantics for some of the overloads are fine.
  
       At level 1, this case does not warn; at level 2, it does.
!      '-Woverloaded-virtual' by itself selects level 2.  Level 1 is
!      included in '-Wall'.
  
! '-Wno-pmf-conversions (C++ and Objective-C++ only)'
       Disable the diagnostic for converting a bound pointer to member
       function to a plain pointer.
  
! '-Wsign-promo (C++ and Objective-C++ only)'
       Warn when overload resolution chooses a promotion from unsigned or
       enumerated type to a signed type, over a conversion to an unsigned
       type of the same size.  Previous versions of G++ tried to preserve
       unsignedness, but the standard mandates the current behavior.
  
! '-Wtemplates (C++ and Objective-C++ only)'
       Warn when a primary template declaration is encountered.  Some
       coding rules disallow templates, and this may be used to enforce
       that rule.  The warning is inactive inside a system header file,
       such as the STL, so one can still use the STL. One may also
       instantiate or specialize templates.
  
! '-Wmismatched-new-delete (C++ and Objective-C++ only)'
!      Warn for mismatches between calls to 'operator new' or 'operator
!      delete' and the corresponding call to the allocation or
!      deallocation function.  This includes invocations of C++ 'operator
!      delete' with pointers returned from either mismatched forms of
!      'operator new', or from other functions that allocate objects for
!      which the 'operator delete' isn't a suitable deallocator, as well
       as calls to other deallocation functions with pointers returned
!      from 'operator new' for which the deallocation function isn't
       suitable.
  
!      For example, the 'delete' expression in the function below is
!      diagnosed because it doesn't match the array form of the 'new'
       expression the pointer argument was returned from.  Similarly, the
!      call to 'free' is also diagnosed.
  
            void f ()
            {
--- 4262,4302 ----
       semantics for some of the overloads are fine.
  
       At level 1, this case does not warn; at level 2, it does.
!      ‘-Woverloaded-virtual’ by itself selects level 2.  Level 1 is
!      included in ‘-Wall’.
  
! ‘-Wno-pmf-conversions (C++ and Objective-C++ only)’
       Disable the diagnostic for converting a bound pointer to member
       function to a plain pointer.
  
! ‘-Wsign-promo (C++ and Objective-C++ only)’
       Warn when overload resolution chooses a promotion from unsigned or
       enumerated type to a signed type, over a conversion to an unsigned
       type of the same size.  Previous versions of G++ tried to preserve
       unsignedness, but the standard mandates the current behavior.
  
! ‘-Wtemplates (C++ and Objective-C++ only)’
       Warn when a primary template declaration is encountered.  Some
       coding rules disallow templates, and this may be used to enforce
       that rule.  The warning is inactive inside a system header file,
       such as the STL, so one can still use the STL. One may also
       instantiate or specialize templates.
  
! ‘-Wmismatched-new-delete (C++ and Objective-C++ only)’
!      Warn for mismatches between calls to ‘operator new’ or ‘operator
!      delete’ and the corresponding call to the allocation or
!      deallocation function.  This includes invocations of C++ ‘operator
!      delete’ with pointers returned from either mismatched forms of
!      ‘operator new’, or from other functions that allocate objects for
!      which the ‘operator delete’ isn't a suitable deallocator, as well
       as calls to other deallocation functions with pointers returned
!      from ‘operator new’ for which the deallocation function isn't
       suitable.
  
!      For example, the ‘delete’ expression in the function below is
!      diagnosed because it doesn't match the array form of the ‘new’
       expression the pointer argument was returned from.  Similarly, the
!      call to ‘free’ is also diagnosed.
  
            void f ()
            {
*************** Dialect Options.
*** 4303,4323 ****
              free (p);   // warning: mismatch between new and free
            }
  
!      The related option '-Wmismatched-dealloc' diagnoses mismatches
       involving allocation and deallocation functions other than
!      'operator new' and 'operator delete'.
  
!      '-Wmismatched-new-delete' is included in '-Wall'.
  
! '-Wmismatched-tags (C++ and Objective-C++ only)'
       Warn for declarations of structs, classes, and class templates and
       their specializations with a class-key that does not match either
       the definition or the first declaration if no definition is
       provided.
  
!      For example, the declaration of 'struct Object' in the argument
!      list of 'draw' triggers the warning.  To avoid it, either remove
!      the redundant class-key 'struct' or replace it with 'class' to
       match its definition.
            class Object {
            public:
--- 4307,4327 ----
              free (p);   // warning: mismatch between new and free
            }
  
!      The related option ‘-Wmismatched-dealloc’ diagnoses mismatches
       involving allocation and deallocation functions other than
!      ‘operator new’ and ‘operator delete’.
  
!      ‘-Wmismatched-new-delete’ is included in ‘-Wall’.
  
! ‘-Wmismatched-tags (C++ and Objective-C++ only)’
       Warn for declarations of structs, classes, and class templates and
       their specializations with a class-key that does not match either
       the definition or the first declaration if no definition is
       provided.
  
!      For example, the declaration of ‘struct Object’ in the argument
!      list of ‘draw’ triggers the warning.  To avoid it, either remove
!      the redundant class-key ‘struct’ or replace it with ‘class’ to
       match its definition.
            class Object {
            public:
*************** Dialect Options.
*** 4325,4354 ****
            };
            void draw (struct Object*);
  
!      It is not wrong to declare a class with the class-key 'struct' as
!      the example above shows.  The '-Wmismatched-tags' option is
       intended to help achieve a consistent style of class declarations.
       In code that is intended to be portable to Windows-based compilers
       the warning helps prevent unresolved references due to the
       difference in the mangling of symbols declared with different
       class-keys.  The option can be used either on its own or in
!      conjunction with '-Wredundant-tags'.
  
! '-Wmultiple-inheritance (C++ and Objective-C++ only)'
       Warn when a class is defined with multiple direct base classes.
       Some coding rules disallow multiple inheritance, and this may be
       used to enforce that rule.  The warning is inactive inside a system
       header file, such as the STL, so one can still use the STL. One may
       also define classes that indirectly use multiple inheritance.
  
! '-Wvirtual-inheritance'
       Warn when a class is defined with a virtual direct base class.
       Some coding rules disallow multiple inheritance, and this may be
       used to enforce that rule.  The warning is inactive inside a system
       header file, such as the STL, so one can still use the STL. One may
       also define classes that indirectly use virtual inheritance.
  
! '-Wno-virtual-move-assign'
       Suppress warnings about inheriting from a virtual base with a
       non-trivial C++11 move assignment operator.  This is dangerous
       because if the virtual base is reachable along more than one path,
--- 4329,4358 ----
            };
            void draw (struct Object*);
  
!      It is not wrong to declare a class with the class-key ‘struct’ as
!      the example above shows.  The ‘-Wmismatched-tags’ option is
       intended to help achieve a consistent style of class declarations.
       In code that is intended to be portable to Windows-based compilers
       the warning helps prevent unresolved references due to the
       difference in the mangling of symbols declared with different
       class-keys.  The option can be used either on its own or in
!      conjunction with ‘-Wredundant-tags’.
  
! ‘-Wmultiple-inheritance (C++ and Objective-C++ only)’
       Warn when a class is defined with multiple direct base classes.
       Some coding rules disallow multiple inheritance, and this may be
       used to enforce that rule.  The warning is inactive inside a system
       header file, such as the STL, so one can still use the STL. One may
       also define classes that indirectly use multiple inheritance.
  
! ‘-Wvirtual-inheritance’
       Warn when a class is defined with a virtual direct base class.
       Some coding rules disallow multiple inheritance, and this may be
       used to enforce that rule.  The warning is inactive inside a system
       header file, such as the STL, so one can still use the STL. One may
       also define classes that indirectly use virtual inheritance.
  
! ‘-Wno-virtual-move-assign’
       Suppress warnings about inheriting from a virtual base with a
       non-trivial C++11 move assignment operator.  This is dangerous
       because if the virtual base is reachable along more than one path,
*************** Dialect Options.
*** 4357,4374 ****
       to avoid moving from a moved-from object, this warning can be
       disabled.
  
! '-Wnamespaces'
       Warn when a namespace definition is opened.  Some coding rules
       disallow namespaces, and this may be used to enforce that rule.
       The warning is inactive inside a system header file, such as the
       STL, so one can still use the STL. One may also use using
       directives and qualified names.
  
! '-Wno-terminate (C++ and Objective-C++ only)'
       Disable the warning about a throw-expression that will immediately
!      result in a call to 'terminate'.
  
! '-Wno-vexing-parse (C++ and Objective-C++ only)'
       Warn about the most vexing parse syntactic ambiguity.  This warns
       about the cases when a declaration looks like a variable
       definition, but the C++ language requires it to be interpreted as a
--- 4361,4378 ----
       to avoid moving from a moved-from object, this warning can be
       disabled.
  
! ‘-Wnamespaces’
       Warn when a namespace definition is opened.  Some coding rules
       disallow namespaces, and this may be used to enforce that rule.
       The warning is inactive inside a system header file, such as the
       STL, so one can still use the STL. One may also use using
       directives and qualified names.
  
! ‘-Wno-terminate (C++ and Objective-C++ only)’
       Disable the warning about a throw-expression that will immediately
!      result in a call to ‘terminate’.
  
! ‘-Wno-vexing-parse (C++ and Objective-C++ only)’
       Warn about the most vexing parse syntactic ambiguity.  This warns
       about the cases when a declaration looks like a variable
       definition, but the C++ language requires it to be interpreted as a
*************** Dialect Options.
*** 4394,4433 ****
  
       This warning is enabled by default.
  
! '-Wno-class-conversion (C++ and Objective-C++ only)'
       Do not warn when a conversion function converts an object to the
       same type, to a base class of that type, or to void; such a
       conversion function will never be called.
  
! '-Wvolatile (C++ and Objective-C++ only)'
!      Warn about deprecated uses of the 'volatile' qualifier.  This
!      includes postfix and prefix '++' and '--' expressions of
!      'volatile'-qualified types, using simple assignments where the left
!      operand is a 'volatile'-qualified non-class type for their value,
       compound assignments where the left operand is a
!      'volatile'-qualified non-class type, 'volatile'-qualified function
!      return type, 'volatile'-qualified parameter type, and structured
!      bindings of a 'volatile'-qualified type.  This usage was deprecated
       in C++20.
  
!      Enabled by default with '-std=c++20'.
  
! '-Wzero-as-null-pointer-constant (C++ and Objective-C++ only)'
!      Warn when a literal '0' is used as null pointer constant.  This can
!      be useful to facilitate the conversion to 'nullptr' in C++11.
  
! '-Waligned-new'
       Warn about a new-expression of a type that requires greater
!      alignment than the 'alignof(std::max_align_t)' but uses an
       allocation function without an explicit alignment parameter.  This
!      option is enabled by '-Wall'.
  
       Normally this only warns about global allocation functions, but
!      '-Waligned-new=all' also warns about class member allocation
       functions.
  
! '-Wno-placement-new'
! '-Wplacement-new=N'
       Warn about placement new expressions with undefined behavior, such
       as constructing an object in a buffer that is smaller than the type
       of the object.  For example, the placement new expression below is
--- 4398,4437 ----
  
       This warning is enabled by default.
  
! ‘-Wno-class-conversion (C++ and Objective-C++ only)’
       Do not warn when a conversion function converts an object to the
       same type, to a base class of that type, or to void; such a
       conversion function will never be called.
  
! ‘-Wvolatile (C++ and Objective-C++ only)’
!      Warn about deprecated uses of the ‘volatile’ qualifier.  This
!      includes postfix and prefix ‘++’ and ‘--’ expressions of
!      ‘volatile’-qualified types, using simple assignments where the left
!      operand is a ‘volatile’-qualified non-class type for their value,
       compound assignments where the left operand is a
!      ‘volatile’-qualified non-class type, ‘volatile’-qualified function
!      return type, ‘volatile’-qualified parameter type, and structured
!      bindings of a ‘volatile’-qualified type.  This usage was deprecated
       in C++20.
  
!      Enabled by default with ‘-std=c++20’.
  
! ‘-Wzero-as-null-pointer-constant (C++ and Objective-C++ only)’
!      Warn when a literal ‘0’ is used as null pointer constant.  This can
!      be useful to facilitate the conversion to ‘nullptr’ in C++11.
  
! ‘-Waligned-new’
       Warn about a new-expression of a type that requires greater
!      alignment than the ‘alignof(std::max_align_t)’ but uses an
       allocation function without an explicit alignment parameter.  This
!      option is enabled by ‘-Wall’.
  
       Normally this only warns about global allocation functions, but
!      ‘-Waligned-new=all’ also warns about class member allocation
       functions.
  
! ‘-Wno-placement-new’
! ‘-Wplacement-new=N’
       Warn about placement new expressions with undefined behavior, such
       as constructing an object in a buffer that is smaller than the type
       of the object.  For example, the placement new expression below is
*************** Dialect Options.
*** 4437,4455 ****
            new (buf) int[64];
       This warning is enabled by default.
  
!      '-Wplacement-new=1'
!           This is the default warning level of '-Wplacement-new'.  At
            this level the warning is not issued for some strictly
            undefined constructs that GCC allows as extensions for
            compatibility with legacy code.  For example, the following
!           'new' expression is not diagnosed at this level even though it
            has undefined behavior according to the C++ standard because
            it writes past the end of the one-element array.
                 struct S { int n, a[1]; };
                 S *s = (S *)malloc (sizeof *s + 31 * sizeof s->a[0]);
                 new (s->a)int [32]();
  
!      '-Wplacement-new=2'
            At this level, in addition to diagnosing all the same
            constructs as at level 1, a diagnostic is also issued for
            placement new expressions that construct an object in the last
--- 4441,4459 ----
            new (buf) int[64];
       This warning is enabled by default.
  
!      ‘-Wplacement-new=1’
!           This is the default warning level of ‘-Wplacement-new’.  At
            this level the warning is not issued for some strictly
            undefined constructs that GCC allows as extensions for
            compatibility with legacy code.  For example, the following
!           ‘new’ expression is not diagnosed at this level even though it
            has undefined behavior according to the C++ standard because
            it writes past the end of the one-element array.
                 struct S { int n, a[1]; };
                 S *s = (S *)malloc (sizeof *s + 31 * sizeof s->a[0]);
                 new (s->a)int [32]();
  
!      ‘-Wplacement-new=2’
            At this level, in addition to diagnosing all the same
            constructs as at level 1, a diagnostic is also issued for
            placement new expressions that construct an object in the last
*************** Dialect Options.
*** 4462,4517 ****
                 S *s = (S *)malloc (sizeof *s + 32 * sizeof s->a[0]);
                 new (s->a)int [32]();
  
! '-Wcatch-value'
! '-Wcatch-value=N (C++ and Objective-C++ only)'
       Warn about catch handlers that do not catch via reference.  With
!      '-Wcatch-value=1' (or '-Wcatch-value' for short) warn about
       polymorphic class types that are caught by value.  With
!      '-Wcatch-value=2' warn about all class types that are caught by
!      value.  With '-Wcatch-value=3' warn about all types that are not
!      caught by reference.  '-Wcatch-value' is enabled by '-Wall'.
  
! '-Wconditionally-supported (C++ and Objective-C++ only)'
       Warn for conditionally-supported (C++11 [intro.defs]) constructs.
  
! '-Wno-delete-incomplete (C++ and Objective-C++ only)'
       Do not warn when deleting a pointer to incomplete type, which may
       cause undefined behavior at runtime.  This warning is enabled by
       default.
  
! '-Wextra-semi (C++, Objective-C++ only)'
       Warn about redundant semicolons after in-class function
       definitions.
  
! '-Wno-inaccessible-base (C++, Objective-C++ only)'
       This option controls warnings when a base class is inaccessible in
       a class derived from it due to ambiguity.  The warning is enabled
       by default.  Note that the warning for ambiguous virtual bases is
!      enabled by the '-Wextra' option.
            struct A { int a; };
  
            struct B : A { };
  
            struct C : B, A { };
  
! '-Wno-inherited-variadic-ctor'
       Suppress warnings about use of C++11 inheriting constructors when
       the base class inherited from has a C variadic constructor; the
       warning is on by default because the ellipsis is not inherited.
  
! '-Wno-invalid-offsetof (C++ and Objective-C++ only)'
!      Suppress warnings from applying the 'offsetof' macro to a non-POD
!      type.  According to the 2014 ISO C++ standard, applying 'offsetof'
       to a non-standard-layout type is undefined.  In existing C++
!      implementations, however, 'offsetof' typically gives meaningful
       results.  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.
  
! '-Wsized-deallocation (C++ and Objective-C++ only)'
       Warn about a definition of an unsized deallocation function
            void operator delete (void *) noexcept;
            void operator delete[] (void *) noexcept;
--- 4466,4521 ----
                 S *s = (S *)malloc (sizeof *s + 32 * sizeof s->a[0]);
                 new (s->a)int [32]();
  
! ‘-Wcatch-value’
! ‘-Wcatch-value=N (C++ and Objective-C++ only)’
       Warn about catch handlers that do not catch via reference.  With
!      ‘-Wcatch-value=1’ (or ‘-Wcatch-value’ for short) warn about
       polymorphic class types that are caught by value.  With
!      ‘-Wcatch-value=2’ warn about all class types that are caught by
!      value.  With ‘-Wcatch-value=3’ warn about all types that are not
!      caught by reference.  ‘-Wcatch-value’ is enabled by ‘-Wall’.
  
! ‘-Wconditionally-supported (C++ and Objective-C++ only)’
       Warn for conditionally-supported (C++11 [intro.defs]) constructs.
  
! ‘-Wno-delete-incomplete (C++ and Objective-C++ only)’
       Do not warn when deleting a pointer to incomplete type, which may
       cause undefined behavior at runtime.  This warning is enabled by
       default.
  
! ‘-Wextra-semi (C++, Objective-C++ only)’
       Warn about redundant semicolons after in-class function
       definitions.
  
! ‘-Wno-inaccessible-base (C++, Objective-C++ only)’
       This option controls warnings when a base class is inaccessible in
       a class derived from it due to ambiguity.  The warning is enabled
       by default.  Note that the warning for ambiguous virtual bases is
!      enabled by the ‘-Wextra’ option.
            struct A { int a; };
  
            struct B : A { };
  
            struct C : B, A { };
  
! ‘-Wno-inherited-variadic-ctor’
       Suppress warnings about use of C++11 inheriting constructors when
       the base class inherited from has a C variadic constructor; the
       warning is on by default because the ellipsis is not inherited.
  
! ‘-Wno-invalid-offsetof (C++ and Objective-C++ only)’
!      Suppress warnings from applying the ‘offsetof’ macro to a non-POD
!      type.  According to the 2014 ISO C++ standard, applying ‘offsetof’
       to a non-standard-layout type is undefined.  In existing C++
!      implementations, however, ‘offsetof’ typically gives meaningful
       results.  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.
  
! ‘-Wsized-deallocation (C++ and Objective-C++ only)’
       Warn about a definition of an unsized deallocation function
            void operator delete (void *) noexcept;
            void operator delete[] (void *) noexcept;
*************** Dialect Options.
*** 4519,4572 ****
       function
            void operator delete (void *, std::size_t) noexcept;
            void operator delete[] (void *, std::size_t) noexcept;
!      or vice versa.  Enabled by '-Wextra' along with
!      '-fsized-deallocation'.
  
! '-Wsuggest-final-types'
       Warn about types with virtual methods where code quality would be
!      improved if the type were declared with the C++11 'final'
       specifier, or, if possible, declared in an anonymous namespace.
       This allows GCC to more aggressively devirtualize the polymorphic
       calls.  This warning is more effective with link-time optimization,
       where the information about the class hierarchy graph is more
       complete.
  
! '-Wsuggest-final-methods'
       Warn about virtual methods where code quality would be improved if
!      the method were declared with the C++11 'final' specifier, or, if
       possible, its type were declared in an anonymous namespace or with
!      the 'final' specifier.  This warning is more effective with
       link-time optimization, where the information about the class
       hierarchy graph is more complete.  It is recommended to first
!      consider suggestions of '-Wsuggest-final-types' and then rebuild
       with new annotations.
  
! '-Wsuggest-override'
       Warn about overriding virtual functions that are not marked with
!      the 'override' keyword.
  
! '-Wuse-after-free'
! '-Wuse-after-free=N'
       Warn about uses of pointers to dynamically allocated objects that
       have been rendered indeterminate by a call to a deallocation
       function.  The warning is enabled at all optimization levels but
       may yield different results with optimization than without.
  
!      '-Wuse-after-free=1'
            At level 1 the warning attempts to diagnose only unconditional
            uses of pointers made indeterminate by a deallocation call or
!           a successful call to 'realloc', regardless of whether or not
            the call resulted in an actual reallocatio of memory.  This
!           includes double-'free' calls as well as uses in arithmetic and
            relational expressions.  Although undefined, uses of
            indeterminate pointers in equality (or inequality) expressions
            are not diagnosed at this level.
!      '-Wuse-after-free=2'
            At level 2, in addition to unconditional uses, the warning
            also diagnoses conditional uses of pointers made indeterminate
            by a deallocation call.  As at level 2, uses in equality (or
            inequality) expressions are not diagnosed.  For example, the
!           second call to 'free' in the following function is diagnosed
            at this level:
                 struct A { int refcount; void *data; };
  
--- 4523,4576 ----
       function
            void operator delete (void *, std::size_t) noexcept;
            void operator delete[] (void *, std::size_t) noexcept;
!      or vice versa.  Enabled by ‘-Wextra’ along with
!      ‘-fsized-deallocation’.
  
! ‘-Wsuggest-final-types’
       Warn about types with virtual methods where code quality would be
!      improved if the type were declared with the C++11 ‘final’
       specifier, or, if possible, declared in an anonymous namespace.
       This allows GCC to more aggressively devirtualize the polymorphic
       calls.  This warning is more effective with link-time optimization,
       where the information about the class hierarchy graph is more
       complete.
  
! ‘-Wsuggest-final-methods’
       Warn about virtual methods where code quality would be improved if
!      the method were declared with the C++11 ‘final’ specifier, or, if
       possible, its type were declared in an anonymous namespace or with
!      the ‘final’ specifier.  This warning is more effective with
       link-time optimization, where the information about the class
       hierarchy graph is more complete.  It is recommended to first
!      consider suggestions of ‘-Wsuggest-final-types’ and then rebuild
       with new annotations.
  
! ‘-Wsuggest-override’
       Warn about overriding virtual functions that are not marked with
!      the ‘override’ keyword.
  
! ‘-Wuse-after-free’
! ‘-Wuse-after-free=N’
       Warn about uses of pointers to dynamically allocated objects that
       have been rendered indeterminate by a call to a deallocation
       function.  The warning is enabled at all optimization levels but
       may yield different results with optimization than without.
  
!      ‘-Wuse-after-free=1’
            At level 1 the warning attempts to diagnose only unconditional
            uses of pointers made indeterminate by a deallocation call or
!           a successful call to ‘realloc’, regardless of whether or not
            the call resulted in an actual reallocatio of memory.  This
!           includes double-‘free’ calls as well as uses in arithmetic and
            relational expressions.  Although undefined, uses of
            indeterminate pointers in equality (or inequality) expressions
            are not diagnosed at this level.
!      ‘-Wuse-after-free=2’
            At level 2, in addition to unconditional uses, the warning
            also diagnoses conditional uses of pointers made indeterminate
            by a deallocation call.  As at level 2, uses in equality (or
            inequality) expressions are not diagnosed.  For example, the
!           second call to ‘free’ in the following function is diagnosed
            at this level:
                 struct A { int refcount; void *data; };
  
*************** Dialect Options.
*** 4577,4587 ****
                   if (refcount == 0)
                     free (p->data);   // warning: p may be used after free
                 }
!      '-Wuse-after-free=3'
            At level 3, the warning also diagnoses uses of indeterminate
            pointers in equality expressions.  All uses of indeterminate
            pointers are undefined but equality tests sometimes appear
!           after calls to 'realloc' as an attempt to determine whether
            the call resulted in relocating the object to a different
            address.  They are diagnosed at a separate level to aid legacy
            code gradually transition to safe alternatives.  For example,
--- 4581,4591 ----
                   if (refcount == 0)
                     free (p->data);   // warning: p may be used after free
                 }
!      ‘-Wuse-after-free=3’
            At level 3, the warning also diagnoses uses of indeterminate
            pointers in equality expressions.  All uses of indeterminate
            pointers are undefined but equality tests sometimes appear
!           after calls to ‘realloc’ as an attempt to determine whether
            the call resulted in relocating the object to a different
            address.  They are diagnosed at a separate level to aid legacy
            code gradually transition to safe alternatives.  For example,
*************** Dialect Options.
*** 4600,4608 ****
            allocated memory instead of pointers.  This approach obviates
            needing to adjust the stored pointers after reallocation.
  
!      '-Wuse-after-free=2' is included in '-Wall'.
  
! '-Wuseless-cast (C++ and Objective-C++ only)'
       Warn when an expression is cast to its own type.  This warning does
       not occur when a class object is converted to a non-reference type
       as that is a way to create a temporary:
--- 4604,4612 ----
            allocated memory instead of pointers.  This approach obviates
            needing to adjust the stored pointers after reallocation.
  
!      ‘-Wuse-after-free=2’ is included in ‘-Wall’.
  
! ‘-Wuseless-cast (C++ and Objective-C++ only)’
       Warn when an expression is cast to its own type.  This warning does
       not occur when a class object is converted to a non-reference type
       as that is a way to create a temporary:
*************** Dialect Options.
*** 4614,4622 ****
              g (S(arg)); // make arg prvalue so that it can bind to S&&
            }
  
! '-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.
  
  
  File: gcc.info,  Node: Objective-C and Objective-C++ Dialect Options,  Next: Diagnostic Message Formatting Options,  Prev: C++ Dialect Options,  Up: Invoking GCC
--- 4618,4626 ----
              g (S(arg)); // make arg prvalue so that it can bind to S&&
            }
  
! ‘-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.
  
  
  File: gcc.info,  Node: Objective-C and Objective-C++ Dialect Options,  Next: Diagnostic Message Formatting Options,  Prev: C++ Dialect Options,  Up: Invoking GCC
*************** Standards, for references.)
*** 4631,4682 ****
   This section describes the command-line options that are only
  meaningful for Objective-C and Objective-C++ programs.  You can also use
  most of the language-independent GNU compiler options.  For example, you
! might compile a file 'some_class.m' like this:
  
       gcc -g -fgnu-runtime -O -c some_class.m
  
! In this example, '-fgnu-runtime' is an option meant only for Objective-C
  and Objective-C++ programs; you can use the other options with any
  language supported by GCC.
  
   Note that since Objective-C is an extension of the C language,
  Objective-C compilations may also use options specific to the C
! front-end (e.g., '-Wtraditional').  Similarly, Objective-C++
! compilations may use C++-specific options (e.g., '-Wabi').
  
   Here is a list of options that are _only_ for compiling Objective-C and
  Objective-C++ programs:
  
! '-fconstant-string-class=CLASS-NAME'
       Use CLASS-NAME as the name of the class to instantiate for each
!      literal string specified with the syntax '@"..."'.  The default
!      class name is 'NXConstantString' if the GNU runtime is being used,
!      and 'NSConstantString' if the NeXT runtime is being used (see
       below).  On Darwin (macOS, MacOS X) platforms, the
!      '-fconstant-cfstrings' option, if also present, overrides the
!      '-fconstant-string-class' setting and cause '@"..."' literals to be
       laid out as constant CoreFoundation strings.  Note that
!      '-fconstant-cfstrings' is an alias for the target-specific
!      '-mconstant-cfstrings' equivalent.
  
! '-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
--- 4635,4686 ----
   This section describes the command-line options that are only
  meaningful for Objective-C and Objective-C++ programs.  You can also use
  most of the language-independent GNU compiler options.  For example, you
! might compile a file ‘some_class.m’ like this:
  
       gcc -g -fgnu-runtime -O -c some_class.m
  
! In this example, ‘-fgnu-runtime’ is an option meant only for Objective-C
  and Objective-C++ programs; you can use the other options with any
  language supported by GCC.
  
   Note that since Objective-C is an extension of the C language,
  Objective-C compilations may also use options specific to the C
! front-end (e.g., ‘-Wtraditional’).  Similarly, Objective-C++
! compilations may use C++-specific options (e.g., ‘-Wabi’).
  
   Here is a list of options that are _only_ for compiling Objective-C and
  Objective-C++ programs:
  
! ‘-fconstant-string-class=CLASS-NAME’
       Use CLASS-NAME as the name of the class to instantiate for each
!      literal string specified with the syntax ‘@"..."’.  The default
!      class name is ‘NXConstantString’ if the GNU runtime is being used,
!      and ‘NSConstantString’ if the NeXT runtime is being used (see
       below).  On Darwin (macOS, MacOS X) platforms, the
!      ‘-fconstant-cfstrings’ option, if also present, overrides the
!      ‘-fconstant-string-class’ setting and cause ‘@"..."’ literals to be
       laid out as constant CoreFoundation strings.  Note that
!      ‘-fconstant-cfstrings’ is an alias for the target-specific
!      ‘-mconstant-cfstrings’ equivalent.
  
! ‘-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
*************** Objective-C++ programs:
*** 4687,4745 ****
       Version 0 on 32-bit target machines, and Version 2 on 64-bit target
       machines.
  
! '-fobjc-call-cxx-cdtors'
       For each Objective-C class, check if any of its instance variables
       is a C++ object with a non-trivial default constructor.  If so,
!      synthesize a special '- (id) .cxx_construct' instance method which
       runs non-trivial default constructors on any such instance
!      variables, in order, and then return 'self'.  Similarly, check if
       any instance variable is a C++ object with a non-trivial
!      destructor, and if so, synthesize a special '- (void)
!      .cxx_destruct' method which runs all such default destructors, in
       reverse order.
  
!      The '- (id) .cxx_construct' and '- (void) .cxx_destruct' methods
       thusly generated only operate on instance variables declared in the
       current Objective-C class, and not those inherited from
       superclasses.  It is the responsibility of the Objective-C runtime
       to invoke all such methods in an object's inheritance hierarchy.
!      The '- (id) .cxx_construct' methods are invoked by the runtime
!      immediately after a new object instance is allocated; the '- (void)
!      .cxx_destruct' methods are invoked immediately before the runtime
       deallocates an object instance.
  
       As of this writing, only the NeXT runtime on Mac OS X 10.4 and
!      later has support for invoking the '- (id) .cxx_construct' and '-
!      (void) .cxx_destruct' methods.
  
! '-fobjc-direct-dispatch'
       Allow fast jumps to the message dispatcher.  On Darwin this is
       accomplished via the comm page.
  
! '-fobjc-exceptions'
       Enable syntactic support for structured exception handling in
       Objective-C, similar to what is offered by C++.  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++
--- 4691,4749 ----
       Version 0 on 32-bit target machines, and Version 2 on 64-bit target
       machines.
  
! ‘-fobjc-call-cxx-cdtors’
       For each Objective-C class, check if any of its instance variables
       is a C++ object with a non-trivial default constructor.  If so,
!      synthesize a special ‘- (id) .cxx_construct’ instance method which
       runs non-trivial default constructors on any such instance
!      variables, in order, and then return ‘self’.  Similarly, check if
       any instance variable is a C++ object with a non-trivial
!      destructor, and if so, synthesize a special ‘- (void)
!      .cxx_destruct’ method which runs all such default destructors, in
       reverse order.
  
!      The ‘- (id) .cxx_construct’ and ‘- (void) .cxx_destruct’ methods
       thusly generated only operate on instance variables declared in the
       current Objective-C class, and not those inherited from
       superclasses.  It is the responsibility of the Objective-C runtime
       to invoke all such methods in an object's inheritance hierarchy.
!      The ‘- (id) .cxx_construct’ methods are invoked by the runtime
!      immediately after a new object instance is allocated; the ‘- (void)
!      .cxx_destruct’ methods are invoked immediately before the runtime
       deallocates an object instance.
  
       As of this writing, only the NeXT runtime on Mac OS X 10.4 and
!      later has support for invoking the ‘- (id) .cxx_construct’ and ‘-
!      (void) .cxx_destruct’ methods.
  
! ‘-fobjc-direct-dispatch’
       Allow fast jumps to the message dispatcher.  On Darwin this is
       accomplished via the comm page.
  
! ‘-fobjc-exceptions’
       Enable syntactic support for structured exception handling in
       Objective-C, similar to what is offered by C++.  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++
*************** Objective-C++ programs:
*** 4750,4758 ****
       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
--- 4754,4762 ----
       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
*************** Objective-C++ programs:
*** 4760,4853 ****
       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.
  
! '-fno-local-ivars'
       By default instance variables in Objective-C can be accessed as if
       they were local variables from within the methods of the class
       they're declared in.  This can lead to shadowing between instance
       variables and other variables declared either locally inside a
       class method or globally with the same name.  Specifying the
!      '-fno-local-ivars' flag disables this behavior thus avoiding
       variable shadowing issues.
  
! '-fivar-visibility=[public|protected|private|package]'
       Set the default instance variable visibility to the specified
       option so that instance variables declared outside the scope of any
       access modifier directives default to the specified visibility.
  
! '-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-property-assign-default (Objective-C and Objective-C++ only)'
       Do not warn if a property for an Objective-C object has no assign
       semantics specified.
  
! '-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.
  
! '-Wobjc-root-class (Objective-C and Objective-C++ only)'
       Warn if a class interface lacks a superclass.  Most classes will
!      inherit from 'NSObject' (or 'Object') for example.  When declaring
       classes intended to be root classes, the warning can be suppressed
       by marking their interfaces with
!      '__attribute__((objc_root_class))'.
  
! '-Wselector (Objective-C and Objective-C++ only)'
       Warn if multiple methods of different types for the same selector
       are found during compilation.  The check is performed on the list
       of methods in the final stage of compilation.  Additionally, a
       check is performed for each selector appearing in a
!      '@selector(...)' expression, and a corresponding method for that
       selector has been found during compilation.  Because these checks
       scan the method table only at the end of compilation, these
       warnings are not produced if the final stage of compilation is not
       reached, for example because an error is found during compilation,
!      or because the '-fsyntax-only' option is being used.
  
! '-Wstrict-selector-match (Objective-C and Objective-C++ only)'
       Warn if multiple methods with differing argument and/or return
       types are found for a given selector when attempting to send a
!      message using this selector to a receiver of type 'id' or 'Class'.
       When this flag is off (which is the default behavior), the compiler
       omits such warnings if any differences found are confined to types
       that share the same size and alignment.
  
! '-Wundeclared-selector (Objective-C and Objective-C++ only)'
!      Warn if a '@selector(...)' expression referring to an undeclared
       selector is found.  A selector is considered undeclared if no
!      method with that name has been declared before the '@selector(...)'
!      expression, either explicitly in an '@interface' or '@protocol'
!      declaration, or implicitly in an '@implementation' section.  This
!      option always performs its checks as soon as a '@selector(...)'
!      expression is found, while '-Wselector' only performs its checks in
       the final stage of compilation.  This also enforces the coding
       style convention that methods and selectors must be declared before
       being used.
  
! '-print-objc-runtime-info'
       Generate C header describing the largest structure that is passed
       by value, if any.
  
--- 4764,4857 ----
       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.
  
! ‘-fno-local-ivars’
       By default instance variables in Objective-C can be accessed as if
       they were local variables from within the methods of the class
       they're declared in.  This can lead to shadowing between instance
       variables and other variables declared either locally inside a
       class method or globally with the same name.  Specifying the
!      ‘-fno-local-ivars’ flag disables this behavior thus avoiding
       variable shadowing issues.
  
! ‘-fivar-visibility=[public|protected|private|package]’
       Set the default instance variable visibility to the specified
       option so that instance variables declared outside the scope of any
       access modifier directives default to the specified visibility.
  
! ‘-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-property-assign-default (Objective-C and Objective-C++ only)’
       Do not warn if a property for an Objective-C object has no assign
       semantics specified.
  
! ‘-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.
  
! ‘-Wobjc-root-class (Objective-C and Objective-C++ only)’
       Warn if a class interface lacks a superclass.  Most classes will
!      inherit from ‘NSObject’ (or ‘Object’) for example.  When declaring
       classes intended to be root classes, the warning can be suppressed
       by marking their interfaces with
!      ‘__attribute__((objc_root_class))’.
  
! ‘-Wselector (Objective-C and Objective-C++ only)’
       Warn if multiple methods of different types for the same selector
       are found during compilation.  The check is performed on the list
       of methods in the final stage of compilation.  Additionally, a
       check is performed for each selector appearing in a
!      ‘@selector(...)’ expression, and a corresponding method for that
       selector has been found during compilation.  Because these checks
       scan the method table only at the end of compilation, these
       warnings are not produced if the final stage of compilation is not
       reached, for example because an error is found during compilation,
!      or because the ‘-fsyntax-only’ option is being used.
  
! ‘-Wstrict-selector-match (Objective-C and Objective-C++ only)’
       Warn if multiple methods with differing argument and/or return
       types are found for a given selector when attempting to send a
!      message using this selector to a receiver of type ‘id’ or ‘Class’.
       When this flag is off (which is the default behavior), the compiler
       omits such warnings if any differences found are confined to types
       that share the same size and alignment.
  
! ‘-Wundeclared-selector (Objective-C and Objective-C++ only)’
!      Warn if a ‘@selector(...)’ expression referring to an undeclared
       selector is found.  A selector is considered undeclared if no
!      method with that name has been declared before the ‘@selector(...)’
!      expression, either explicitly in an ‘@interface’ or ‘@protocol’
!      declaration, or implicitly in an ‘@implementation’ section.  This
!      option always performs its checks as soon as a ‘@selector(...)’
!      expression is found, while ‘-Wselector’ only performs its checks in
       the final stage of compilation.  This also enforces the coding
       style convention that methods and selectors must be declared before
       being used.
  
! ‘-print-objc-runtime-info’
       Generate C header describing the largest structure that is passed
       by value, if any.
  
*************** diagnostic messages, e.g. how many chara
*** 4864,4885 ****
  location information should be reported.  Note that some language front
  ends may not honor these options.
  
! '-fmessage-length=N'
       Try to format error messages so that they fit on lines of about N
       characters.  If N is zero, then no line-wrapping is done; each
       error message appears on a single line.  This is the default for
       all front ends.
  
!      Note - this option also affects the display of the '#error' and
!      '#warning' pre-processor directives, and the 'deprecated'
       function/type/variable attribute.  It does not however affect the
!      'pragma GCC warning' and 'pragma GCC error' pragmas.
  
! '-fdiagnostics-plain-output'
       This option requests that diagnostic output look as plain as
!      possible, which may be useful when running 'dejagnu' or other
       utilities that need to parse diagnostics output and prefer that it
!      remain more stable over time.  '-fdiagnostics-plain-output' is
       currently equivalent to the following options:
            -fno-diagnostics-show-caret
            -fno-diagnostics-show-line-numbers
--- 4868,4889 ----
  location information should be reported.  Note that some language front
  ends may not honor these options.
  
! ‘-fmessage-length=N’
       Try to format error messages so that they fit on lines of about N
       characters.  If N is zero, then no line-wrapping is done; each
       error message appears on a single line.  This is the default for
       all front ends.
  
!      Note - this option also affects the display of the ‘#error’ and
!      ‘#warning’ pre-processor directives, and the ‘deprecated’
       function/type/variable attribute.  It does not however affect the
!      ‘pragma GCC warning’ and ‘pragma GCC error’ pragmas.
  
! ‘-fdiagnostics-plain-output’
       This option requests that diagnostic output look as plain as
!      possible, which may be useful when running ‘dejagnu’ or other
       utilities that need to parse diagnostics output and prefer that it
!      remain more stable over time.  ‘-fdiagnostics-plain-output’ is
       currently equivalent to the following options:
            -fno-diagnostics-show-caret
            -fno-diagnostics-show-line-numbers
*************** ends may not honor these options.
*** 4890,4896 ****
       diagnostics, the corresponding option to disable the new behavior
       will be added to this list.
  
! '-fdiagnostics-show-location=once'
       Only meaningful in line-wrapping mode.  Instructs the diagnostic
       messages reporter to emit source location information _once_; that
       is, in case the message is too long to fit on a single physical
--- 4894,4900 ----
       diagnostics, the corresponding option to disable the new behavior
       will be added to this list.
  
! ‘-fdiagnostics-show-location=once’
       Only meaningful in line-wrapping mode.  Instructs the diagnostic
       messages reporter to emit source location information _once_; that
       is, in case the message is too long to fit on a single physical
*************** ends may not honor these options.
*** 4898,5012 ****
       (as prefix) again, over and over, in subsequent continuation lines.
       This is the default behavior.
  
! '-fdiagnostics-show-location=every-line'
       Only meaningful in line-wrapping mode.  Instructs the diagnostic
       messages reporter to emit the same source location information (as
       prefix) for physical lines that result from the process of breaking
       a message which is too long to fit on a single line.
  
! '-fdiagnostics-color[=WHEN]'
! '-fno-diagnostics-color'
!      Use color in diagnostics.  WHEN is 'never', 'always', or 'auto'.
       The default depends on how the compiler has been configured, it can
!      be any of the above WHEN options or also 'never' if 'GCC_COLORS'
!      environment variable isn't present in the environment, and 'auto'
!      otherwise.  'auto' makes GCC use color only when the standard error
       is a terminal, and when not executing in an emacs shell.  The forms
!      '-fdiagnostics-color' and '-fno-diagnostics-color' are aliases for
!      '-fdiagnostics-color=always' and '-fdiagnostics-color=never',
       respectively.
  
!      The colors are defined by the environment variable 'GCC_COLORS'.
       Its value is a colon-separated list of capabilities and Select
       Graphic Rendition (SGR) substrings.  SGR commands are interpreted
       by the terminal or terminal emulator.  (See the section in the
       documentation of your text terminal for permitted values and their
       meanings as character attributes.)  These substring values are
       integers in decimal representation and can be concatenated with
!      semicolons.  Common values to concatenate include '1' for bold, '4'
!      for underline, '5' for blink, '7' for inverse, '39' for default
!      foreground color, '30' to '37' for foreground colors, '90' to '97'
!      for 16-color mode foreground colors, '38;5;0' to '38;5;255' for
!      88-color and 256-color modes foreground colors, '49' for default
!      background color, '40' to '47' for background colors, '100' to
!      '107' for 16-color mode background colors, and '48;5;0' to
!      '48;5;255' for 88-color and 256-color modes background colors.
  
!      The default 'GCC_COLORS' is
            error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\
            quote=01:path=01;36:fixit-insert=32:fixit-delete=31:\
            diff-filename=01:diff-hunk=32:diff-delete=31:diff-insert=32:\
            type-diff=01;32:fnname=01;32:targs=35
!      where '01;31' is bold red, '01;35' is bold magenta, '01;36' is bold
!      cyan, '32' is green, '34' is blue, '01' is bold, and '31' is red.
!      Setting 'GCC_COLORS' to the empty string disables colors.
       Supported capabilities are as follows.
  
!      'error='
            SGR substring for error: markers.
  
!      'warning='
            SGR substring for warning: markers.
  
!      'note='
            SGR substring for note: markers.
  
!      'path='
            SGR substring for colorizing paths of control-flow events as
!           printed via '-fdiagnostics-path-format=', such as the
            identifiers of individual events and lines indicating
            interprocedural calls and returns.
  
!      'range1='
            SGR substring for first additional range.
  
!      'range2='
            SGR substring for second additional range.
  
!      'locus='
!           SGR substring for location information, 'file:line' or
!           'file:line:column' etc.
  
!      'quote='
            SGR substring for information printed within quotes.
  
!      'fnname='
            SGR substring for names of C++ functions.
  
!      'targs='
            SGR substring for C++ function template parameter bindings.
  
!      'fixit-insert='
            SGR substring for fix-it hints suggesting text to be inserted
            or replaced.
  
!      'fixit-delete='
            SGR substring for fix-it hints suggesting text to be deleted.
  
!      'diff-filename='
            SGR substring for filename headers within generated patches.
  
!      'diff-hunk='
            SGR substring for the starts of hunks within generated
            patches.
  
!      'diff-delete='
            SGR substring for deleted lines within generated patches.
  
!      'diff-insert='
            SGR substring for inserted lines within generated patches.
  
!      'type-diff='
            SGR substring for highlighting mismatching types within
            template arguments in the C++ frontend.
  
! '-fdiagnostics-urls[=WHEN]'
       Use escape sequences to embed URLs in diagnostics.  For example,
!      when '-fdiagnostics-show-option' emits text showing the
       command-line option controlling a diagnostic, embed a URL for
       documentation of that option.
  
!      WHEN is 'never', 'always', or 'auto'.  'auto' makes GCC use URL
       escape sequences only when the standard error is a terminal, and
       when not executing in an emacs shell or any graphical terminal
       which is known to be incompatible with this feature, see below.
--- 4902,5016 ----
       (as prefix) again, over and over, in subsequent continuation lines.
       This is the default behavior.
  
! ‘-fdiagnostics-show-location=every-line’
       Only meaningful in line-wrapping mode.  Instructs the diagnostic
       messages reporter to emit the same source location information (as
       prefix) for physical lines that result from the process of breaking
       a message which is too long to fit on a single line.
  
! ‘-fdiagnostics-color[=WHEN]’
! ‘-fno-diagnostics-color’
!      Use color in diagnostics.  WHEN is ‘never’, ‘always’, or ‘auto’.
       The default depends on how the compiler has been configured, it can
!      be any of the above WHEN options or also ‘never’ if ‘GCC_COLORS’
!      environment variable isn't present in the environment, and ‘auto’
!      otherwise.  ‘auto’ makes GCC use color only when the standard error
       is a terminal, and when not executing in an emacs shell.  The forms
!      ‘-fdiagnostics-color’ and ‘-fno-diagnostics-color’ are aliases for
!      ‘-fdiagnostics-color=always’ and ‘-fdiagnostics-color=never’,
       respectively.
  
!      The colors are defined by the environment variable ‘GCC_COLORS’.
       Its value is a colon-separated list of capabilities and Select
       Graphic Rendition (SGR) substrings.  SGR commands are interpreted
       by the terminal or terminal emulator.  (See the section in the
       documentation of your text terminal for permitted values and their
       meanings as character attributes.)  These substring values are
       integers in decimal representation and can be concatenated with
!      semicolons.  Common values to concatenate include ‘1’ for bold, ‘4’
!      for underline, ‘5’ for blink, ‘7’ for inverse, ‘39’ for default
!      foreground color, ‘30’ to ‘37’ for foreground colors, ‘90’ to ‘97’
!      for 16-color mode foreground colors, ‘38;5;0’ to ‘38;5;255’ for
!      88-color and 256-color modes foreground colors, ‘49’ for default
!      background color, ‘40’ to ‘47’ for background colors, ‘100’ to
!      ‘107’ for 16-color mode background colors, and ‘48;5;0’ to
!      ‘48;5;255’ for 88-color and 256-color modes background colors.
  
!      The default ‘GCC_COLORS’ is
            error=01;31:warning=01;35:note=01;36:range1=32:range2=34:locus=01:\
            quote=01:path=01;36:fixit-insert=32:fixit-delete=31:\
            diff-filename=01:diff-hunk=32:diff-delete=31:diff-insert=32:\
            type-diff=01;32:fnname=01;32:targs=35
!      where ‘01;31’ is bold red, ‘01;35’ is bold magenta, ‘01;36’ is bold
!      cyan, ‘32’ is green, ‘34’ is blue, ‘01’ is bold, and ‘31’ is red.
!      Setting ‘GCC_COLORS’ to the empty string disables colors.
       Supported capabilities are as follows.
  
!      ‘error=’
            SGR substring for error: markers.
  
!      ‘warning=’
            SGR substring for warning: markers.
  
!      ‘note=’
            SGR substring for note: markers.
  
!      ‘path=’
            SGR substring for colorizing paths of control-flow events as
!           printed via ‘-fdiagnostics-path-format=’, such as the
            identifiers of individual events and lines indicating
            interprocedural calls and returns.
  
!      ‘range1=’
            SGR substring for first additional range.
  
!      ‘range2=’
            SGR substring for second additional range.
  
!      ‘locus=’
!           SGR substring for location information, ‘file:line’ or
!           ‘file:line:column’ etc.
  
!      ‘quote=’
            SGR substring for information printed within quotes.
  
!      ‘fnname=’
            SGR substring for names of C++ functions.
  
!      ‘targs=’
            SGR substring for C++ function template parameter bindings.
  
!      ‘fixit-insert=’
            SGR substring for fix-it hints suggesting text to be inserted
            or replaced.
  
!      ‘fixit-delete=’
            SGR substring for fix-it hints suggesting text to be deleted.
  
!      ‘diff-filename=’
            SGR substring for filename headers within generated patches.
  
!      ‘diff-hunk=’
            SGR substring for the starts of hunks within generated
            patches.
  
!      ‘diff-delete=’
            SGR substring for deleted lines within generated patches.
  
!      ‘diff-insert=’
            SGR substring for inserted lines within generated patches.
  
!      ‘type-diff=’
            SGR substring for highlighting mismatching types within
            template arguments in the C++ frontend.
  
! ‘-fdiagnostics-urls[=WHEN]’
       Use escape sequences to embed URLs in diagnostics.  For example,
!      when ‘-fdiagnostics-show-option’ emits text showing the
       command-line option controlling a diagnostic, embed a URL for
       documentation of that option.
  
!      WHEN is ‘never’, ‘always’, or ‘auto’.  ‘auto’ makes GCC use URL
       escape sequences only when the standard error is a terminal, and
       when not executing in an emacs shell or any graphical terminal
       which is known to be incompatible with this feature, see below.
*************** ends may not honor these options.
*** 5015,5033 ****
       can be any of the above WHEN options.
  
       GCC can also be configured (via the
!      '--with-diagnostics-urls=auto-if-env' configure-time option) so
       that the default is affected by environment variables.  Under such
!      a configuration, GCC defaults to using 'auto' if either 'GCC_URLS'
!      or 'TERM_URLS' environment variables are present and non-empty in
!      the environment of the compiler, or 'never' if neither are.
  
!      However, even with '-fdiagnostics-urls=always' the behavior is
!      dependent on those environment variables: If 'GCC_URLS' is set to
!      empty or 'no', do not embed URLs in diagnostics.  If set to 'st',
!      URLs use ST escape sequences.  If set to 'bel', the default, URLs
       use BEL escape sequences.  Any other non-empty value enables the
!      feature.  If 'GCC_URLS' is not set, use 'TERM_URLS' as a fallback.
!      Note: ST is an ANSI escape sequence, string terminator 'ESC \', BEL
       is an ASCII character, CTRL-G that usually sounds like a beep.
  
       At this time GCC tries to detect also a few terminals that are
--- 5019,5037 ----
       can be any of the above WHEN options.
  
       GCC can also be configured (via the
!      ‘--with-diagnostics-urls=auto-if-env’ configure-time option) so
       that the default is affected by environment variables.  Under such
!      a configuration, GCC defaults to using ‘auto’ if either ‘GCC_URLS’
!      or ‘TERM_URLS’ environment variables are present and non-empty in
!      the environment of the compiler, or ‘never’ if neither are.
  
!      However, even with ‘-fdiagnostics-urls=always’ the behavior is
!      dependent on those environment variables: If ‘GCC_URLS’ is set to
!      empty or ‘no’, do not embed URLs in diagnostics.  If set to ‘st’,
!      URLs use ST escape sequences.  If set to ‘bel’, the default, URLs
       use BEL escape sequences.  Any other non-empty value enables the
!      feature.  If ‘GCC_URLS’ is not set, use ‘TERM_URLS’ as a fallback.
!      Note: ST is an ANSI escape sequence, string terminator ‘ESC \’, BEL
       is an ASCII character, CTRL-G that usually sounds like a beep.
  
       At this time GCC tries to detect also a few terminals that are
*************** ends may not honor these options.
*** 5036,5061 ****
       escapes are likely to misbehave, i.e.  print garbage on the screen.
       That list is currently xfce4-terminal, certain known to be buggy
       gnome-terminal versions, the linux console, and mingw.  This check
!      can be skipped with the '-fdiagnostics-urls=always'.
  
! '-fno-diagnostics-show-option'
       By default, each diagnostic emitted includes text indicating the
       command-line option that directly controls the diagnostic (if such
       an option is known to the diagnostic machinery).  Specifying the
!      '-fno-diagnostics-show-option' flag suppresses that behavior.
  
! '-fno-diagnostics-show-caret'
       By default, each diagnostic emitted includes the original source
!      line and a caret '^' indicating the column.  This option suppresses
       this information.  The source line is truncated to N characters, if
!      the '-fmessage-length=n' option is given.  When the output is done
       to the terminal, the width is limited to the width given by the
!      'COLUMNS' environment variable or, if not set, to the terminal
       width.
  
! '-fno-diagnostics-show-labels'
       By default, when printing source code (via
!      '-fdiagnostics-show-caret'), diagnostics can label ranges of source
       code with pertinent information, such as the types of expressions:
  
                printf ("foo %s bar", long_i + long_j);
--- 5040,5065 ----
       escapes are likely to misbehave, i.e.  print garbage on the screen.
       That list is currently xfce4-terminal, certain known to be buggy
       gnome-terminal versions, the linux console, and mingw.  This check
!      can be skipped with the ‘-fdiagnostics-urls=always’.
  
! ‘-fno-diagnostics-show-option’
       By default, each diagnostic emitted includes text indicating the
       command-line option that directly controls the diagnostic (if such
       an option is known to the diagnostic machinery).  Specifying the
!      ‘-fno-diagnostics-show-option’ flag suppresses that behavior.
  
! ‘-fno-diagnostics-show-caret’
       By default, each diagnostic emitted includes the original source
!      line and a caret ‘^’ indicating the column.  This option suppresses
       this information.  The source line is truncated to N characters, if
!      the ‘-fmessage-length=n’ option is given.  When the output is done
       to the terminal, the width is limited to the width given by the
!      ‘COLUMNS’ environment variable or, if not set, to the terminal
       width.
  
! ‘-fno-diagnostics-show-labels’
       By default, when printing source code (via
!      ‘-fdiagnostics-show-caret’), diagnostics can label ranges of source
       code with pertinent information, such as the types of expressions:
  
                printf ("foo %s bar", long_i + long_j);
*************** ends may not honor these options.
*** 5066,5081 ****
       This option suppresses the printing of these labels (in the example
       above, the vertical bars and the "char *" and "long int" text).
  
! '-fno-diagnostics-show-cwe'
       Diagnostic messages can optionally have an associated CWE
       (https://cwe.mitre.org/index.html) identifier.  GCC itself only
!      provides such metadata for some of the '-fanalyzer' diagnostics.
       GCC plugins may also provide diagnostics with such metadata.  By
       default, if this information is present, it will be printed with
       the diagnostic.  This option suppresses the printing of this
       metadata.
  
! '-fno-diagnostics-show-rules'
       Diagnostic messages can optionally have rules associated with them,
       such as from a coding standard, or a specification.  GCC itself
       does not do this for any of its diagnostics, but plugins may do so.
--- 5070,5085 ----
       This option suppresses the printing of these labels (in the example
       above, the vertical bars and the "char *" and "long int" text).
  
! ‘-fno-diagnostics-show-cwe’
       Diagnostic messages can optionally have an associated CWE
       (https://cwe.mitre.org/index.html) identifier.  GCC itself only
!      provides such metadata for some of the ‘-fanalyzer’ diagnostics.
       GCC plugins may also provide diagnostics with such metadata.  By
       default, if this information is present, it will be printed with
       the diagnostic.  This option suppresses the printing of this
       metadata.
  
! ‘-fno-diagnostics-show-rules’
       Diagnostic messages can optionally have rules associated with them,
       such as from a coding standard, or a specification.  GCC itself
       does not do this for any of its diagnostics, but plugins may do so.
*************** ends may not honor these options.
*** 5083,5098 ****
       the diagnostic.  This option suppresses the printing of this
       metadata.
  
! '-fno-diagnostics-show-line-numbers'
       By default, when printing source code (via
!      '-fdiagnostics-show-caret'), a left margin is printed, showing line
       numbers.  This option suppresses this left margin.
  
! '-fdiagnostics-minimum-margin-width=WIDTH'
       This option controls the minimum width of the left margin printed
!      by '-fdiagnostics-show-line-numbers'.  It defaults to 6.
  
! '-fdiagnostics-parseable-fixits'
       Emit fix-it hints in a machine-parseable format, suitable for
       consumption by IDEs.  For each fix-it, a line will be printed after
       the relevant diagnostic, starting with the string "fix-it:".  For
--- 5087,5102 ----
       the diagnostic.  This option suppresses the printing of this
       metadata.
  
! ‘-fno-diagnostics-show-line-numbers’
       By default, when printing source code (via
!      ‘-fdiagnostics-show-caret’), a left margin is printed, showing line
       numbers.  This option suppresses this left margin.
  
! ‘-fdiagnostics-minimum-margin-width=WIDTH’
       This option controls the minimum width of the left margin printed
!      by ‘-fdiagnostics-show-line-numbers’.  It defaults to 6.
  
! ‘-fdiagnostics-parseable-fixits’
       Emit fix-it hints in a machine-parseable format, suitable for
       consumption by IDEs.  For each fix-it, a line will be printed after
       the relevant diagnostic, starting with the string "fix-it:".  For
*************** ends may not honor these options.
*** 5119,5125 ****
       removed.  An empty range (e.g.  "45:3-45:3") indicates that the
       string is to be inserted at the given position.
  
! '-fdiagnostics-generate-patch'
       Print fix-it hints to stderr in unified diff format, after any
       diagnostics are printed.  For example:
  
--- 5123,5129 ----
       removed.  An empty range (e.g.  "45:3-45:3") indicates that the
       string is to be inserted at the given position.
  
! ‘-fdiagnostics-generate-patch’
       Print fix-it hints to stderr in unified diff format, after any
       diagnostics are printed.  For example:
  
*************** ends may not honor these options.
*** 5135,5143 ****
  
  
       The diff may or may not be colorized, following the same rules as
!      for diagnostics (see '-fdiagnostics-color').
  
! '-fdiagnostics-show-template-tree'
  
       In the C++ frontend, when printing diagnostics showing mismatching
       template types, such as:
--- 5139,5147 ----
  
  
       The diff may or may not be colorized, following the same rules as
!      for diagnostics (see ‘-fdiagnostics-color’).
  
! ‘-fdiagnostics-show-template-tree’
  
       In the C++ frontend, when printing diagnostics showing mismatching
       template types, such as:
*************** ends may not honor these options.
*** 5145,5151 ****
              could not convert 'std::map >()'
                from 'map<[...],vector>' to 'map<[...],vector>
  
!      the '-fdiagnostics-show-template-tree' flag enables printing a
       tree-like structure showing the common and differing parts of the
       types, such as:
  
--- 5149,5155 ----
              could not convert 'std::map >()'
                from 'map<[...],vector>' to 'map<[...],vector>
  
!      the ‘-fdiagnostics-show-template-tree’ flag enables printing a
       tree-like structure showing the common and differing parts of the
       types, such as:
  
*************** ends may not honor these options.
*** 5157,5163 ****
       The parts that differ are highlighted with color ("double" and
       "float" in this case).
  
! '-fno-elide-type'
       By default when the C++ frontend prints diagnostics showing
       mismatching template types, common parts of the types are printed
       as "[...]"  to simplify the error message.  For example:
--- 5161,5167 ----
       The parts that differ are highlighted with color ("double" and
       "float" in this case).
  
! ‘-fno-elide-type’
       By default when the C++ frontend prints diagnostics showing
       mismatching template types, common parts of the types are printed
       as "[...]"  to simplify the error message.  For example:
*************** ends may not honor these options.
*** 5165,5183 ****
              could not convert 'std::map >()'
                from 'map<[...],vector>' to 'map<[...],vector>
  
!      Specifying the '-fno-elide-type' flag suppresses that behavior.
       This flag also affects the output of the
!      '-fdiagnostics-show-template-tree' flag.
  
! '-fdiagnostics-path-format=KIND'
       Specify how to print paths of control-flow events for diagnostics
       that have such a path associated with them.
  
!      KIND is 'none', 'separate-events', or 'inline-events', the default.
  
!      'none' means to not print diagnostic paths.
  
!      'separate-events' means to print a separate "note" diagnostic for
       each event within the diagnostic.  For example:
  
            test.c:29:5: error: passing NULL as argument 1 to 'PyList_Append' which requires a non-NULL parameter
--- 5169,5187 ----
              could not convert 'std::map >()'
                from 'map<[...],vector>' to 'map<[...],vector>
  
!      Specifying the ‘-fno-elide-type’ flag suppresses that behavior.
       This flag also affects the output of the
!      ‘-fdiagnostics-show-template-tree’ flag.
  
! ‘-fdiagnostics-path-format=KIND’
       Specify how to print paths of control-flow events for diagnostics
       that have such a path associated with them.
  
!      KIND is ‘none’, ‘separate-events’, or ‘inline-events’, the default.
  
!      ‘none’ means to not print diagnostic paths.
  
!      ‘separate-events’ means to print a separate "note" diagnostic for
       each event within the diagnostic.  For example:
  
            test.c:29:5: error: passing NULL as argument 1 to 'PyList_Append' which requires a non-NULL parameter
*************** ends may not honor these options.
*** 5185,5191 ****
            test.c:27:3: note: (2) when 'i < count'
            test.c:29:5: note: (3) when calling 'PyList_Append', passing NULL from (1) as argument 1
  
!      'inline-events' means to print the events "inline" within the
       source code.  This view attempts to consolidate the events into
       runs of sufficiently-close events, printing them as labelled ranges
       within the source.
--- 5189,5195 ----
            test.c:27:3: note: (2) when 'i < count'
            test.c:29:5: note: (3) when calling 'PyList_Append', passing NULL from (1) as argument 1
  
!      ‘inline-events’ means to print the events "inline" within the
       source code.  This view attempts to consolidate the events into
       runs of sufficiently-close events, printing them as labelled ranges
       within the source.
*************** ends may not honor these options.
*** 5260,5290 ****
                |
            (etc)
  
! '-fdiagnostics-show-path-depths'
       This option provides additional information when printing
       control-flow paths associated with a diagnostic.
  
       If this is option is provided then the stack depth will be printed
       for each run of events within
!      '-fdiagnostics-path-format=inline-events'.  If provided with
!      '-fdiagnostics-path-format=separate-events', then the stack depth
       and function declaration will be appended when printing each event.
  
       This is intended for use by GCC developers and plugin developers
       when debugging diagnostics that report interprocedural control
       flow.
  
! '-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'.
  
! '-fdiagnostics-column-unit=UNIT'
       Select the units for the column number.  This affects traditional
!      diagnostics (in the absence of '-fno-show-column'), as well as JSON
       format diagnostics if requested.
  
!      The default UNIT, 'display', considers the number of display
       columns occupied by each character.  This may be larger than the
       number of bytes required to encode the character, in the case of
       tab characters, or it may be smaller, in the case of multibyte
--- 5264,5294 ----
                |
            (etc)
  
! ‘-fdiagnostics-show-path-depths’
       This option provides additional information when printing
       control-flow paths associated with a diagnostic.
  
       If this is option is provided then the stack depth will be printed
       for each run of events within
!      ‘-fdiagnostics-path-format=inline-events’.  If provided with
!      ‘-fdiagnostics-path-format=separate-events’, then the stack depth
       and function declaration will be appended when printing each event.
  
       This is intended for use by GCC developers and plugin developers
       when debugging diagnostics that report interprocedural control
       flow.
  
! ‘-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’.
  
! ‘-fdiagnostics-column-unit=UNIT’
       Select the units for the column number.  This affects traditional
!      diagnostics (in the absence of ‘-fno-show-column’), as well as JSON
       format diagnostics if requested.
  
!      The default UNIT, ‘display’, considers the number of display
       columns occupied by each character.  This may be larger than the
       number of bytes required to encode the character, in the case of
       tab characters, or it may be smaller, in the case of multibyte
*************** ends may not honor these options.
*** 5294,5311 ****
       occupies two display columns, and its UTF-8 encoding requires four
       bytes.
  
!      Setting UNIT to 'byte' changes the column number to the raw byte
       count in all cases, as was traditionally output by GCC prior to
       version 11.1.0.
  
! '-fdiagnostics-column-origin=ORIGIN'
       Select the origin for column numbers, i.e.  the column number
       assigned to the first column.  The default value of 1 corresponds
       to traditional GCC behavior and to the GNU style guide.  Some
       utilities may perform better with an origin of 0; any non-negative
       value may be specified.
  
! '-fdiagnostics-escape-format=FORMAT'
       When GCC prints pertinent source lines for a diagnostic it normally
       attempts to print the source bytes directly.  However, some
       diagnostics relate to encoding issues in the source file, such as
--- 5298,5315 ----
       occupies two display columns, and its UTF-8 encoding requires four
       bytes.
  
!      Setting UNIT to ‘byte’ changes the column number to the raw byte
       count in all cases, as was traditionally output by GCC prior to
       version 11.1.0.
  
! ‘-fdiagnostics-column-origin=ORIGIN’
       Select the origin for column numbers, i.e.  the column number
       assigned to the first column.  The default value of 1 corresponds
       to traditional GCC behavior and to the GNU style guide.  Some
       utilities may perform better with an origin of 0; any non-negative
       value may be specified.
  
! ‘-fdiagnostics-escape-format=FORMAT’
       When GCC prints pertinent source lines for a diagnostic it normally
       attempts to print the source bytes directly.  However, some
       diagnostics relate to encoding issues in the source file, such as
*************** ends may not honor these options.
*** 5315,5356 ****
  
       This option controls how such bytes should be escaped.
  
!      The default FORMAT, 'unicode' displays Unicode characters that are
!      not printable ASCII in the form '', and bytes that do not
       correspond to a Unicode character validly-encoded in UTF-8-encoded
!      will be displayed as hexadecimal in the form ''.
  
!      For example, a source line containing the string 'before' followed
       by the Unicode character U+03C0 ("GREEK SMALL LETTER PI", with
       UTF-8 encoding 0xCF 0x80) followed by the byte 0xBF (a stray UTF-8
!      trailing byte), followed by the string 'after' will be printed for
       such a diagnostic as:
  
             beforeafter
  
!      Setting FORMAT to 'bytes' will display all non-printable-ASCII
!      bytes in the form '', thus showing the underlying encoding of
       non-ASCII Unicode characters.  For the example above, the following
       will be printed:
  
             before<80>after
  
! '-fdiagnostics-format=FORMAT'
       Select a different format for printing diagnostics.  FORMAT is
!      'text', 'sarif-stderr', 'sarif-file', 'json', 'json-stderr', or
!      'json-file'.
  
!      The default is 'text'.
  
!      The 'sarif-stderr' and 'sarif-file' formats both emit diagnostics
       in SARIF Version 2.1.0 format, either to stderr, or to a file named
!      'SOURCE.sarif', respectively.
  
!      The 'json' format is a synonym for 'json-stderr'.  The
!      'json-stderr' and 'json-file' formats are identical, apart from
       where the JSON is emitted to - with the former, the JSON is emitted
!      to stderr, whereas with 'json-file' it is written to
!      'SOURCE.gcc.json'.
  
       The emitted JSON consists of a top-level JSON array containing JSON
       objects representing the diagnostics.  The JSON is emitted as one
--- 5319,5360 ----
  
       This option controls how such bytes should be escaped.
  
!      The default FORMAT, ‘unicode’ displays Unicode characters that are
!      not printable ASCII in the form ‘’, and bytes that do not
       correspond to a Unicode character validly-encoded in UTF-8-encoded
!      will be displayed as hexadecimal in the form ‘’.
  
!      For example, a source line containing the string ‘before’ followed
       by the Unicode character U+03C0 ("GREEK SMALL LETTER PI", with
       UTF-8 encoding 0xCF 0x80) followed by the byte 0xBF (a stray UTF-8
!      trailing byte), followed by the string ‘after’ will be printed for
       such a diagnostic as:
  
             beforeafter
  
!      Setting FORMAT to ‘bytes’ will display all non-printable-ASCII
!      bytes in the form ‘’, thus showing the underlying encoding of
       non-ASCII Unicode characters.  For the example above, the following
       will be printed:
  
             before<80>after
  
! ‘-fdiagnostics-format=FORMAT’
       Select a different format for printing diagnostics.  FORMAT is
!      ‘text’, ‘sarif-stderr’, ‘sarif-file’, ‘json’, ‘json-stderr’, or
!      ‘json-file’.
  
!      The default is ‘text’.
  
!      The ‘sarif-stderr’ and ‘sarif-file’ formats both emit diagnostics
       in SARIF Version 2.1.0 format, either to stderr, or to a file named
!      ‘SOURCE.sarif’, respectively.
  
!      The ‘json’ format is a synonym for ‘json-stderr’.  The
!      ‘json-stderr’ and ‘json-file’ formats are identical, apart from
       where the JSON is emitted to - with the former, the JSON is emitted
!      to stderr, whereas with ‘json-file’ it is written to
!      ‘SOURCE.gcc.json’.
  
       The emitted JSON consists of a top-level JSON array containing JSON
       objects representing the diagnostics.  The JSON is emitted as one
*************** ends may not honor these options.
*** 5418,5448 ****
                }
            ]
  
!      where the 'note' is a child of the 'warning'.
  
!      A diagnostic has a 'kind'.  If this is 'warning', then there is an
!      'option' key describing the command-line option controlling the
       warning.
  
       A diagnostic can contain zero or more locations.  Each location has
!      an optional 'label' string and up to three positions within it: a
!      'caret' position and optional 'start' and 'finish' positions.  A
!      position is described by a 'file' name, a 'line' number, and three
       numbers indicating a column position:
  
!         * 'display-column' counts display columns, accounting for tabs
            and multibyte characters.
  
!         * 'byte-column' counts raw bytes.
  
!         * 'column' is equal to one of the previous two, as dictated by
!           the '-fdiagnostics-column-unit' option.
  
       All three columns are relative to the origin specified by
!      '-fdiagnostics-column-origin', which is typically equal to 1 but
       may be set, for instance, to 0 for compatibility with other
       utilities that number columns from 0.  The column origin is
!      recorded in the JSON output in the 'column-origin' tag.  In the
       remaining examples below, the extra column number outputs have been
       omitted for brevity.
  
--- 5422,5452 ----
                }
            ]
  
!      where the ‘note’ is a child of the ‘warning’.
  
!      A diagnostic has a ‘kind’.  If this is ‘warning’, then there is an
!      ‘option’ key describing the command-line option controlling the
       warning.
  
       A diagnostic can contain zero or more locations.  Each location has
!      an optional ‘label’ string and up to three positions within it: a
!      ‘caret’ position and optional ‘start’ and ‘finish’ positions.  A
!      position is described by a ‘file’ name, a ‘line’ number, and three
       numbers indicating a column position:
  
!         • ‘display-column’ counts display columns, accounting for tabs
            and multibyte characters.
  
!         • ‘byte-column’ counts raw bytes.
  
!         • ‘column’ is equal to one of the previous two, as dictated by
!           the ‘-fdiagnostics-column-unit’ option.
  
       All three columns are relative to the origin specified by
!      ‘-fdiagnostics-column-origin’, which is typically equal to 1 but
       may be set, for instance, to 0 for compatibility with other
       utilities that number columns from 0.  The column origin is
!      recorded in the JSON output in the ‘column-origin’ tag.  In the
       remaining examples below, the extra column number outputs have been
       omitted for brevity.
  
*************** ends may not honor these options.
*** 5493,5501 ****
                    "message": "invalid operands to binary + ..."
                }
  
!      If a diagnostic contains fix-it hints, it has a 'fixits' array,
       consisting of half-open intervals, similar to the output of
!      '-fdiagnostics-parseable-fixits'.  For example, this diagnostic
       with a replacement fix-it hint:
  
            demo.c:8:15: error: 'struct s' has no member named 'colour'; did you
--- 5497,5505 ----
                    "message": "invalid operands to binary + ..."
                }
  
!      If a diagnostic contains fix-it hints, it has a ‘fixits’ array,
       consisting of half-open intervals, similar to the output of
!      ‘-fdiagnostics-parseable-fixits’.  For example, this diagnostic
       with a replacement fix-it hint:
  
            demo.c:8:15: error: 'struct s' has no member named 'colour'; did you
*************** ends may not honor these options.
*** 5542,5563 ****
                    "message": "\u2018struct s\u2019 has no member named ..."
                }
  
!      where the fix-it hint suggests replacing the text from 'start' up
!      to but not including 'next' with 'string''s value.  Deletions are
!      expressed via an empty value for 'string', insertions by having
!      'start' equal 'next'.
  
       If the diagnostic has a path of control-flow events associated with
!      it, it has a 'path' array of objects representing the events.  Each
!      event object has a 'description' string, a 'location' object, along
!      with a 'function' string and a 'depth' number for representing
!      interprocedural paths.  The 'function' represents the current
!      function at that event, and the 'depth' represents the stack depth
       relative to some baseline: the higher, the more frames are within
       the stack.
  
       For example, the intraprocedural example shown for
!      '-fdiagnostics-path-format=' might have this JSON for its path:
  
                "path": [
                    {
--- 5546,5567 ----
                    "message": "\u2018struct s\u2019 has no member named ..."
                }
  
!      where the fix-it hint suggests replacing the text from ‘start’ up
!      to but not including ‘next’ with ‘string’'s value.  Deletions are
!      expressed via an empty value for ‘string’, insertions by having
!      ‘start’ equal ‘next’.
  
       If the diagnostic has a path of control-flow events associated with
!      it, it has a ‘path’ array of objects representing the events.  Each
!      event object has a ‘description’ string, a ‘location’ object, along
!      with a ‘function’ string and a ‘depth’ number for representing
!      interprocedural paths.  The ‘function’ represents the current
!      function at that event, and the ‘depth’ represents the stack depth
       relative to some baseline: the higher, the more frames are within
       the stack.
  
       For example, the intraprocedural example shown for
!      ‘-fdiagnostics-path-format=’ might have this JSON for its path:
  
                "path": [
                    {
*************** ends may not honor these options.
*** 5592,5600 ****
                    }
                ]
  
!      Diagnostics have a boolean attribute 'escape-source', hinting
       whether non-ASCII bytes should be escaped when printing the
!      pertinent lines of source code ('true' for diagnostics involving
       source encoding issues).
  
  
--- 5596,5604 ----
                    }
                ]
  
!      Diagnostics have a boolean attribute ‘escape-source’, hinting
       whether non-ASCII bytes should be escaped when printing the
!      pertinent lines of source code (‘true’ for diagnostics involving
       source encoding issues).
  
  
*************** an error.
*** 5610,5667 ****
   The following language-independent options do not enable specific
  warnings but control the kinds of diagnostics produced by GCC.
  
! '-fsyntax-only'
       Check the code for syntax errors, but don't do anything beyond
       that.
  
! '-fmax-errors=N'
       Limits the maximum number of error messages to N, at which point
       GCC bails out rather than attempting to continue processing the
       source code.  If N is 0 (the default), there is no limit on the
!      number of error messages produced.  If '-Wfatal-errors' is also
!      specified, then '-Wfatal-errors' takes precedence over this option.
  
! '-w'
       Inhibit all warning messages.
  
! '-Werror'
       Make all warnings into errors.
  
! '-Werror='
       Make the specified warning into an error.  The specifier for a
!      warning is appended; for example '-Werror=switch' turns the
!      warnings controlled by '-Wswitch' into errors.  This switch takes a
!      negative form, to be used to negate '-Werror' for specific
!      warnings; for example '-Wno-error=switch' makes '-Wswitch' warnings
!      not be errors, even when '-Werror' is in effect.
  
       The warning message for each controllable warning includes the
       option that controls the warning.  That option can then be used
!      with '-Werror=' and '-Wno-error=' as described above.  (Printing of
       the option in the warning message can be disabled using the
!      '-fno-diagnostics-show-option' flag.)
  
!      Note that specifying '-Werror='FOO automatically implies '-W'FOO.
!      However, '-Wno-error='FOO does not imply anything.
  
! '-Wfatal-errors'
       This option causes the compiler to abort compilation on the first
       error occurred rather than trying to keep going and printing
       further error messages.
  
   You can request many specific warnings with options beginning with
! '-W', for example '-Wimplicit' to request warnings on implicit
  declarations.  Each of these specific warning options also has a
! negative form beginning '-Wno-' to turn off warnings; for example,
! '-Wno-implicit'.  This manual lists only one of the two forms, whichever
  is not the default.  For further language-specific options also refer to
  *note C++ Dialect Options:: and *note Objective-C and Objective-C++
  Dialect Options::.  Additional warnings can be produced by enabling the
  static analyzer; *Note Static Analyzer Options::.
  
!  Some options, such as '-Wall' and '-Wextra', turn on other options,
! such as '-Wunused', which may turn on further options, such as
! '-Wunused-value'.  The combined effect of positive and negative forms is
  that more specific options have priority over less specific ones,
  independently of their position in the command-line.  For options of the
  same specificity, the last one takes effect.  Options enabled or
--- 5614,5671 ----
   The following language-independent options do not enable specific
  warnings but control the kinds of diagnostics produced by GCC.
  
! ‘-fsyntax-only’
       Check the code for syntax errors, but don't do anything beyond
       that.
  
! ‘-fmax-errors=N’
       Limits the maximum number of error messages to N, at which point
       GCC bails out rather than attempting to continue processing the
       source code.  If N is 0 (the default), there is no limit on the
!      number of error messages produced.  If ‘-Wfatal-errors’ is also
!      specified, then ‘-Wfatal-errors’ takes precedence over this option.
  
! ‘-w’
       Inhibit all warning messages.
  
! ‘-Werror’
       Make all warnings into errors.
  
! ‘-Werror=’
       Make the specified warning into an error.  The specifier for a
!      warning is appended; for example ‘-Werror=switch’ turns the
!      warnings controlled by ‘-Wswitch’ into errors.  This switch takes a
!      negative form, to be used to negate ‘-Werror’ for specific
!      warnings; for example ‘-Wno-error=switch’ makes ‘-Wswitch’ warnings
!      not be errors, even when ‘-Werror’ is in effect.
  
       The warning message for each controllable warning includes the
       option that controls the warning.  That option can then be used
!      with ‘-Werror=’ and ‘-Wno-error=’ as described above.  (Printing of
       the option in the warning message can be disabled using the
!      ‘-fno-diagnostics-show-option’ flag.)
  
!      Note that specifying ‘-Werror=’FOO automatically implies ‘-W’FOO.
!      However, ‘-Wno-error=’FOO does not imply anything.
  
! ‘-Wfatal-errors’
       This option causes the compiler to abort compilation on the first
       error occurred rather than trying to keep going and printing
       further error messages.
  
   You can request many specific warnings with options beginning with
! ‘-W’, for example ‘-Wimplicit’ to request warnings on implicit
  declarations.  Each of these specific warning options also has a
! negative form beginning ‘-Wno-’ to turn off warnings; for example,
! ‘-Wno-implicit’.  This manual lists only one of the two forms, whichever
  is not the default.  For further language-specific options also refer to
  *note C++ Dialect Options:: and *note Objective-C and Objective-C++
  Dialect Options::.  Additional warnings can be produced by enabling the
  static analyzer; *Note Static Analyzer Options::.
  
!  Some options, such as ‘-Wall’ and ‘-Wextra’, turn on other options,
! such as ‘-Wunused’, which may turn on further options, such as
! ‘-Wunused-value’.  The combined effect of positive and negative forms is
  that more specific options have priority over less specific ones,
  independently of their position in the command-line.  For options of the
  same specificity, the last one takes effect.  Options enabled or
*************** disabled via pragmas (*note Diagnostic P
*** 5669,5712 ****
  appeared at the end of the command-line.
  
   When an unrecognized warning option is requested (e.g.,
! '-Wunknown-warning'), GCC emits a diagnostic stating that the option is
! not recognized.  However, if the '-Wno-' form is used, the behavior is
! slightly different: no diagnostic is produced for '-Wno-unknown-warning'
  unless other diagnostics are being produced.  This allows the use of new
! '-Wno-' options with old compilers, but if something goes wrong, the
  compiler warns that an unrecognized option is present.
  
   The effectiveness of some warnings depends on optimizations also being
! enabled.  For example '-Wsuggest-final-types' is more effective with
  link-time optimization and some instances of other warnings may not be
  issued at all unless optimization is enabled.  While optimization in
  general improves the efficacy of control and data flow sensitive
  warnings, in some cases it may also cause false positives.
  
! '-Wpedantic'
! '-pedantic'
       Issue all the warnings demanded by strict ISO C and ISO C++; reject
       all programs that use forbidden extensions, and some other programs
       that do not follow ISO C and ISO C++.  For ISO C, follows the
!      version of the ISO C standard specified by any '-std' option used.
  
       Valid ISO C and ISO C++ programs should compile properly with or
!      without this option (though a rare few require '-ansi' or a '-std'
       option specifying the required version of ISO C).  However, without
       this option, certain GNU extensions and traditional C and C++
       features are supported as well.  With this option, they are
       rejected.
  
!      '-Wpedantic' does not cause warning messages for use of the
!      alternate keywords whose names begin and end with '__'.  This
       alternate format can also be used to disable warnings for non-ISO
!      '__intN' types, i.e.  '__intN__'.  Pedantic warnings are also
!      disabled in the expression that follows '__extension__'.  However,
       only system header files should use these escape routes;
       application programs should avoid them.  *Note Alternate
       Keywords::.
  
!      Some users try to use '-Wpedantic' to check programs for strict ISO
       C conformance.  They soon find that it does not do quite what they
       want: it finds some non-ISO practices, but not all--only those for
       which ISO C _requires_ a diagnostic, and some others for which
--- 5673,5716 ----
  appeared at the end of the command-line.
  
   When an unrecognized warning option is requested (e.g.,
! ‘-Wunknown-warning’), GCC emits a diagnostic stating that the option is
! not recognized.  However, if the ‘-Wno-’ form is used, the behavior is
! slightly different: no diagnostic is produced for ‘-Wno-unknown-warning’
  unless other diagnostics are being produced.  This allows the use of new
! ‘-Wno-’ options with old compilers, but if something goes wrong, the
  compiler warns that an unrecognized option is present.
  
   The effectiveness of some warnings depends on optimizations also being
! enabled.  For example ‘-Wsuggest-final-types’ is more effective with
  link-time optimization and some instances of other warnings may not be
  issued at all unless optimization is enabled.  While optimization in
  general improves the efficacy of control and data flow sensitive
  warnings, in some cases it may also cause false positives.
  
! ‘-Wpedantic’
! ‘-pedantic’
       Issue all the warnings demanded by strict ISO C and ISO C++; reject
       all programs that use forbidden extensions, and some other programs
       that do not follow ISO C and ISO C++.  For ISO C, follows the
!      version of the ISO C standard specified by any ‘-std’ option used.
  
       Valid ISO C and ISO C++ programs should compile properly with or
!      without this option (though a rare few require ‘-ansi’ or a ‘-std’
       option specifying the required version of ISO C).  However, without
       this option, certain GNU extensions and traditional C and C++
       features are supported as well.  With this option, they are
       rejected.
  
!      ‘-Wpedantic’ does not cause warning messages for use of the
!      alternate keywords whose names begin and end with ‘__’.  This
       alternate format can also be used to disable warnings for non-ISO
!      ‘__intN’ types, i.e.  ‘__intN__’.  Pedantic warnings are also
!      disabled in the expression that follows ‘__extension__’.  However,
       only system header files should use these escape routes;
       application programs should avoid them.  *Note Alternate
       Keywords::.
  
!      Some users try to use ‘-Wpedantic’ to check programs for strict ISO
       C conformance.  They soon find that it does not do quite what they
       want: it finds some non-ISO practices, but not all--only those for
       which ISO C _requires_ a diagnostic, and some others for which
*************** warnings, in some cases it may also caus
*** 5714,5742 ****
  
       A feature to report any failure to conform to ISO C might be useful
       in some instances, but would require considerable additional work
!      and would be quite different from '-Wpedantic'.  We don't have
       plans to support such a feature in the near future.
  
!      Where the standard specified with '-std' represents a GNU extended
!      dialect of C, such as 'gnu90' or 'gnu99', there is a corresponding
!      "base standard", the version of ISO C on which the GNU extended
!      dialect is based.  Warnings from '-Wpedantic' are given where they
       are required by the base standard.  (It does not make sense for
       such warnings to be given only for features not in the specified
       GNU C dialect, since by definition the GNU dialects of C include
       all features the compiler supports with the given option, and there
       would be nothing to warn about.)
  
! '-pedantic-errors'
!      Give an error whenever the "base standard" (see '-Wpedantic')
       requires a diagnostic, in some cases where there is undefined
       behavior at compile-time and in some other cases that do not
       prevent compilation of programs that are valid according to the
!      standard.  This is not equivalent to '-Werror=pedantic', since
       there are errors enabled by this option and not enabled by the
       latter and vice versa.
  
! '-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
--- 5718,5746 ----
  
       A feature to report any failure to conform to ISO C might be useful
       in some instances, but would require considerable additional work
!      and would be quite different from ‘-Wpedantic’.  We don't have
       plans to support such a feature in the near future.
  
!      Where the standard specified with ‘-std’ represents a GNU extended
!      dialect of C, such as ‘gnu90’ or ‘gnu99’, there is a corresponding
!      “base standard”, the version of ISO C on which the GNU extended
!      dialect is based.  Warnings from ‘-Wpedantic’ are given where they
       are required by the base standard.  (It does not make sense for
       such warnings to be given only for features not in the specified
       GNU C dialect, since by definition the GNU dialects of C include
       all features the compiler supports with the given option, and there
       would be nothing to warn about.)
  
! ‘-pedantic-errors’
!      Give an error whenever the “base standard” (see ‘-Wpedantic’)
       requires a diagnostic, in some cases where there is undefined
       behavior at compile-time and in some other cases that do not
       prevent compilation of programs that are valid according to the
!      standard.  This is not equivalent to ‘-Werror=pedantic’, since
       there are errors enabled by this option and not enabled by the
       latter and vice versa.
  
! ‘-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
*************** warnings, in some cases it may also caus
*** 5744,5750 ****
       Dialect Options:: and *note Objective-C and Objective-C++ Dialect
       Options::.
  
!      '-Wall' turns on the following warning flags:
  
            -Waddress
            -Warray-bounds=1 (only with -O2)
--- 5748,5754 ----
       Dialect Options:: and *note Objective-C and Objective-C++ Dialect
       Options::.
  
!      ‘-Wall’ turns on the following warning flags:
  
            -Waddress
            -Warray-bounds=1 (only with -O2)
*************** warnings, in some cases it may also caus
*** 5812,5828 ****
            -Wvolatile-register-var
            -Wzero-length-bounds
  
!      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
--- 5816,5832 ----
            -Wvolatile-register-var
            -Wzero-length-bounds
  
!      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
*************** warnings, in some cases it may also caus
*** 5846,5894 ****
            -Wunused-parameter (only with -Wunused or -Wall)
            -Wunused-but-set-parameter (only with -Wunused or -Wall)
  
!      The option '-Wextra' also prints warning messages for the following
       cases:
  
!         * A pointer is compared against integer zero with '<', '<=',
!           '>', or '>='.
  
!         * (C++ only) An enumerator and a non-enumerator both appear in a
            conditional expression.
  
!         * (C++ only) Ambiguous virtual bases.
  
!         * (C++ only) Subscripting an array that has been declared
!           'register'.
  
!         * (C++ only) Taking the address of a variable that has been
!           declared 'register'.
  
!         * (C++ only) A base class is not initialized in the copy
            constructor of a derived class.
  
! '-Wabi (C, Objective-C, C++ and Objective-C++ only)'
  
       Warn about code affected by ABI changes.  This includes code that
       may not be compatible with the vendor-neutral C++ ABI as well as
       the psABI for the particular target.
  
       Since G++ now defaults to updating the ABI with each major release,
!      normally '-Wabi' warns only about C++ ABI compatibility problems if
       there is a check added later in a release series for an ABI issue
!      discovered since the initial release.  '-Wabi' warns about more
       things if an older ABI version is selected (with
!      '-fabi-version=N').
  
!      '-Wabi' can also be used with an explicit version number to warn
!      about C++ ABI compatibility with a particular '-fabi-version'
!      level, e.g. '-Wabi=2' to warn about changes relative to
!      '-fabi-version=2'.
  
       If an explicit version number is provided and
!      '-fabi-compat-version' is not specified, the version number from
       this option is used for compatibility aliases.  If no explicit
       version number is provided with this option, but
!      '-fabi-compat-version' is specified, that version number is used
       for C++ ABI warnings.
  
       Although an effort has been made to warn about all such cases,
--- 5850,5898 ----
            -Wunused-parameter (only with -Wunused or -Wall)
            -Wunused-but-set-parameter (only with -Wunused or -Wall)
  
!      The option ‘-Wextra’ also prints warning messages for the following
       cases:
  
!         • A pointer is compared against integer zero with ‘<’, ‘<=’,
!           ‘>’, or ‘>=’.
  
!         • (C++ only) An enumerator and a non-enumerator both appear in a
            conditional expression.
  
!         • (C++ only) Ambiguous virtual bases.
  
!         • (C++ only) Subscripting an array that has been declared
!           ‘register’.
  
!         • (C++ only) Taking the address of a variable that has been
!           declared ‘register’.
  
!         • (C++ only) A base class is not initialized in the copy
            constructor of a derived class.
  
! ‘-Wabi (C, Objective-C, C++ and Objective-C++ only)’
  
       Warn about code affected by ABI changes.  This includes code that
       may not be compatible with the vendor-neutral C++ ABI as well as
       the psABI for the particular target.
  
       Since G++ now defaults to updating the ABI with each major release,
!      normally ‘-Wabi’ warns only about C++ ABI compatibility problems if
       there is a check added later in a release series for an ABI issue
!      discovered since the initial release.  ‘-Wabi’ warns about more
       things if an older ABI version is selected (with
!      ‘-fabi-version=N’).
  
!      ‘-Wabi’ can also be used with an explicit version number to warn
!      about C++ ABI compatibility with a particular ‘-fabi-version’
!      level, e.g. ‘-Wabi=2’ to warn about changes relative to
!      ‘-fabi-version=2’.
  
       If an explicit version number is provided and
!      ‘-fabi-compat-version’ is not specified, the version number from
       this option is used for compatibility aliases.  If no explicit
       version number is provided with this option, but
!      ‘-fabi-compat-version’ is specified, that version number is used
       for C++ ABI warnings.
  
       Although an effort has been made to warn about all such cases,
*************** warnings, in some cases it may also caus
*** 5901,5971 ****
       concerned about the fact that code generated by G++ may not be
       binary compatible with code generated by other compilers.
  
!      Known incompatibilities in '-fabi-version=2' (which was the default
       from GCC 3.4 to 4.9) include:
  
!         * A template with a non-type template parameter of reference
            type was mangled incorrectly:
                 extern int N;
                 template  struct S {};
                 void n (S) {2}
  
!           This was fixed in '-fabi-version=3'.
  
!         * SIMD vector types declared using '__attribute ((vector_size))'
            were mangled in a non-standard way that does not allow for
            overloading of functions taking vectors of different sizes.
  
!           The mangling was changed in '-fabi-version=4'.
  
!         * '__attribute ((const))' and 'noreturn' were mangled as type
!           qualifiers, and 'decltype' of a plain declaration was folded
            away.
  
!           These mangling issues were fixed in '-fabi-version=5'.
  
!         * Scoped enumerators passed as arguments to a variadic function
!           are promoted like unscoped enumerators, causing 'va_arg' to
            complain.  On most targets this does not actually affect the
            parameter passing ABI, as there is no way to pass an argument
!           smaller than 'int'.
  
            Also, the ABI changed the mangling of template argument packs,
!           'const_cast', 'static_cast', prefix increment/decrement, and a
            class scope function used as a template argument.
  
!           These issues were corrected in '-fabi-version=6'.
  
!         * Lambdas in default argument scope were mangled incorrectly,
!           and the ABI changed the mangling of 'nullptr_t'.
  
!           These issues were corrected in '-fabi-version=7'.
  
!         * When mangling a function type with function-cv-qualifiers, the
            un-qualified function type was incorrectly treated as a
            substitution candidate.
  
!           This was fixed in '-fabi-version=8', the default for GCC 5.1.
  
!         * 'decltype(nullptr)' incorrectly had an alignment of 1, leading
            to unaligned accesses.  Note that this did not affect the ABI
!           of a function with a 'nullptr_t' parameter, as parameters have
            a minimum alignment.
  
!           This was fixed in '-fabi-version=9', the default for GCC 5.2.
  
!         * Target-specific attributes that affect the identity of a type,
            such as ia32 calling conventions on a function type (stdcall,
            regparm, etc.), did not affect the mangled name, leading to
            name collisions when function pointers were used as template
            arguments.
  
!           This was fixed in '-fabi-version=10', the default for GCC 6.1.
  
       This option also enables warnings about psABI-related changes.  The
       known psABI changes at this point include:
  
!         * For SysV/x86-64, unions with 'long double' members are passed
            in memory as specified in psABI. Prior to GCC 4.4, this was
            not the case.  For example:
  
--- 5905,5975 ----
       concerned about the fact that code generated by G++ may not be
       binary compatible with code generated by other compilers.
  
!      Known incompatibilities in ‘-fabi-version=2’ (which was the default
       from GCC 3.4 to 4.9) include:
  
!         • A template with a non-type template parameter of reference
            type was mangled incorrectly:
                 extern int N;
                 template  struct S {};
                 void n (S) {2}
  
!           This was fixed in ‘-fabi-version=3’.
  
!         • SIMD vector types declared using ‘__attribute ((vector_size))’
            were mangled in a non-standard way that does not allow for
            overloading of functions taking vectors of different sizes.
  
!           The mangling was changed in ‘-fabi-version=4’.
  
!         • ‘__attribute ((const))’ and ‘noreturn’ were mangled as type
!           qualifiers, and ‘decltype’ of a plain declaration was folded
            away.
  
!           These mangling issues were fixed in ‘-fabi-version=5’.
  
!         • Scoped enumerators passed as arguments to a variadic function
!           are promoted like unscoped enumerators, causing ‘va_arg’ to
            complain.  On most targets this does not actually affect the
            parameter passing ABI, as there is no way to pass an argument
!           smaller than ‘int’.
  
            Also, the ABI changed the mangling of template argument packs,
!           ‘const_cast’, ‘static_cast’, prefix increment/decrement, and a
            class scope function used as a template argument.
  
!           These issues were corrected in ‘-fabi-version=6’.
  
!         • Lambdas in default argument scope were mangled incorrectly,
!           and the ABI changed the mangling of ‘nullptr_t’.
  
!           These issues were corrected in ‘-fabi-version=7’.
  
!         • When mangling a function type with function-cv-qualifiers, the
            un-qualified function type was incorrectly treated as a
            substitution candidate.
  
!           This was fixed in ‘-fabi-version=8’, the default for GCC 5.1.
  
!         • ‘decltype(nullptr)’ incorrectly had an alignment of 1, leading
            to unaligned accesses.  Note that this did not affect the ABI
!           of a function with a ‘nullptr_t’ parameter, as parameters have
            a minimum alignment.
  
!           This was fixed in ‘-fabi-version=9’, the default for GCC 5.2.
  
!         • Target-specific attributes that affect the identity of a type,
            such as ia32 calling conventions on a function type (stdcall,
            regparm, etc.), did not affect the mangled name, leading to
            name collisions when function pointers were used as template
            arguments.
  
!           This was fixed in ‘-fabi-version=10’, the default for GCC 6.1.
  
       This option also enables warnings about psABI-related changes.  The
       known psABI changes at this point include:
  
!         • For SysV/x86-64, unions with ‘long double’ members are passed
            in memory as specified in psABI. Prior to GCC 4.4, this was
            not the case.  For example:
  
*************** warnings, in some cases it may also caus
*** 5974,5982 ****
                   int i;
                 };
  
!           'union U' is now always passed in memory.
  
! '-Wno-changes-meaning (C++ and Objective-C++ only)'
       C++ requires that unqualified uses of a name within a class have
       the same meaning in the complete scope of the class, so declaring
       the name after using it is ill-formed:
--- 5978,5986 ----
                   int i;
                 };
  
!           ‘union U’ is now always passed in memory.
  
! ‘-Wno-changes-meaning (C++ and Objective-C++ only)’
       C++ requires that unqualified uses of a name within a class have
       the same meaning in the complete scope of the class, so declaring
       the name after using it is ill-formed:
*************** warnings, in some cases it may also caus
*** 5985,6063 ****
            struct B2 { A a; struct A { }; }; // error, 'A' changes meaning
       By default, the B1 case is only a warning because the two
       declarations have the same type, while the B2 case is an error.
!      Both diagnostics can be disabled with '-Wno-changes-meaning'.
       Alternately, the error case can be reduced to a warning with
!      '-Wno-error=changes-meaning' or '-fpermissive'.
  
!      Both diagnostics are also suppressed by '-fms-extensions'.
  
! '-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'.
  
! '-Wno-coverage-mismatch'
       Warn if feedback profiles do not match when using the
!      '-fprofile-use' option.  If a source file is changed between
!      compiling with '-fprofile-generate' and with '-fprofile-use', the
       files with the profile feedback can fail to match the source file
       and GCC cannot use the profile feedback information.  By default,
       this warning is enabled and is treated as an error.
!      '-Wno-coverage-mismatch' can be used to disable the warning or
!      '-Wno-error=coverage-mismatch' can be used to disable the error.
       Disabling the error for this warning can result in poorly optimized
       code and is useful only in the case of very minor changes such as
       bug fixes to an existing code-base.  Completely disabling the
       warning is not recommended.
  
! '-Wno-coverage-invalid-line-number'
       Warn in case a function ends earlier than it begins due to an
       invalid linenum macros.  The warning is emitted only with
!      '--coverage' enabled.
  
       By default, this warning is enabled and is treated as an error.
!      '-Wno-coverage-invalid-line-number' can be used to disable the
!      warning or '-Wno-error=coverage-invalid-line-number' can be used to
       disable the error.
  
! '-Wno-cpp (C, Objective-C, C++, Objective-C++ and Fortran only)'
!      Suppress warning messages emitted by '#warning' directives.
  
! '-Wdouble-promotion (C, C++, Objective-C and Objective-C++ only)'
!      Give a warning when a value of type 'float' is implicitly promoted
!      to 'double'.  CPUs with a 32-bit "single-precision" floating-point
!      unit implement 'float' in hardware, but emulate 'double' in
!      software.  On such a machine, doing computations using 'double'
       values is much more expensive because of the overhead required for
       software emulation.
  
!      It is easy to accidentally do computations with 'double' because
!      floating-point literals are implicitly of type 'double'.  For
       example, in:
            float area(float radius)
            {
               return 3.14159 * radius * radius;
            }
!      the compiler performs the entire computation with 'double' because
!      the floating-point literal is a 'double'.
  
! '-Wduplicate-decl-specifier (C and Objective-C only)'
!      Warn if a declaration has duplicate 'const', 'volatile', 'restrict'
!      or '_Atomic' specifier.  This warning is enabled by '-Wall'.
  
! '-Wformat'
! '-Wformat=N'
!      Check calls to 'printf' and 'scanf', etc., to make sure that the
       arguments supplied have types appropriate to the format string
       specified, and that the conversions specified in the format string
       make sense.  This includes standard functions, and others specified
       by format attributes (*note Function Attributes::), in the
!      'printf', 'scanf', 'strftime' and 'strfmon' (an X/Open extension,
       not in the C standard) families (or other target-specific
       families).  Which functions are checked without format attributes
       having been specified depends on the standard version selected, and
       such checks of functions without the attribute specified are
!      disabled by '-ffreestanding' or '-fno-builtin'.
  
       The formats are checked against the format features supported by
       GNU libc version 2.2.  These include all ISO C90 and C99 features,
--- 5989,6067 ----
            struct B2 { A a; struct A { }; }; // error, 'A' changes meaning
       By default, the B1 case is only a warning because the two
       declarations have the same type, while the B2 case is an error.
!      Both diagnostics can be disabled with ‘-Wno-changes-meaning’.
       Alternately, the error case can be reduced to a warning with
!      ‘-Wno-error=changes-meaning’ or ‘-fpermissive’.
  
!      Both diagnostics are also suppressed by ‘-fms-extensions’.
  
! ‘-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’.
  
! ‘-Wno-coverage-mismatch’
       Warn if feedback profiles do not match when using the
!      ‘-fprofile-use’ option.  If a source file is changed between
!      compiling with ‘-fprofile-generate’ and with ‘-fprofile-use’, the
       files with the profile feedback can fail to match the source file
       and GCC cannot use the profile feedback information.  By default,
       this warning is enabled and is treated as an error.
!      ‘-Wno-coverage-mismatch’ can be used to disable the warning or
!      ‘-Wno-error=coverage-mismatch’ can be used to disable the error.
       Disabling the error for this warning can result in poorly optimized
       code and is useful only in the case of very minor changes such as
       bug fixes to an existing code-base.  Completely disabling the
       warning is not recommended.
  
! ‘-Wno-coverage-invalid-line-number’
       Warn in case a function ends earlier than it begins due to an
       invalid linenum macros.  The warning is emitted only with
!      ‘--coverage’ enabled.
  
       By default, this warning is enabled and is treated as an error.
!      ‘-Wno-coverage-invalid-line-number’ can be used to disable the
!      warning or ‘-Wno-error=coverage-invalid-line-number’ can be used to
       disable the error.
  
! ‘-Wno-cpp (C, Objective-C, C++, Objective-C++ and Fortran only)’
!      Suppress warning messages emitted by ‘#warning’ directives.
  
! ‘-Wdouble-promotion (C, C++, Objective-C and Objective-C++ only)’
!      Give a warning when a value of type ‘float’ is implicitly promoted
!      to ‘double’.  CPUs with a 32-bit "single-precision" floating-point
!      unit implement ‘float’ in hardware, but emulate ‘double’ in
!      software.  On such a machine, doing computations using ‘double’
       values is much more expensive because of the overhead required for
       software emulation.
  
!      It is easy to accidentally do computations with ‘double’ because
!      floating-point literals are implicitly of type ‘double’.  For
       example, in:
            float area(float radius)
            {
               return 3.14159 * radius * radius;
            }
!      the compiler performs the entire computation with ‘double’ because
!      the floating-point literal is a ‘double’.
  
! ‘-Wduplicate-decl-specifier (C and Objective-C only)’
!      Warn if a declaration has duplicate ‘const’, ‘volatile’, ‘restrict’
!      or ‘_Atomic’ specifier.  This warning is enabled by ‘-Wall’.
  
! ‘-Wformat’
! ‘-Wformat=N’
!      Check calls to ‘printf’ and ‘scanf’, etc., to make sure that the
       arguments supplied have types appropriate to the format string
       specified, and that the conversions specified in the format string
       make sense.  This includes standard functions, and others specified
       by format attributes (*note Function Attributes::), in the
!      ‘printf’, ‘scanf’, ‘strftime’ and ‘strfmon’ (an X/Open extension,
       not in the C standard) families (or other target-specific
       families).  Which functions are checked without format attributes
       having been specified depends on the standard version selected, and
       such checks of functions without the attribute specified are
!      disabled by ‘-ffreestanding’ or ‘-fno-builtin’.
  
       The formats are checked against the format features supported by
       GNU libc version 2.2.  These include all ISO C90 and C99 features,
*************** warnings, in some cases it may also caus
*** 6065,6111 ****
       and GNU extensions.  Other library implementations may not support
       all these features; GCC does not support warning about features
       that go beyond a particular library's limitations.  However, if
!      '-Wpedantic' is used with '-Wformat', warnings are given about
       format features not in the selected standard version (but not for
!      'strfmon' formats, since those are not in any version of the C
       standard).  *Note Options Controlling C Dialect: C Dialect Options.
  
!      '-Wformat=1'
!      '-Wformat'
!           Option '-Wformat' is equivalent to '-Wformat=1', and
!           '-Wno-format' is equivalent to '-Wformat=0'.  Since '-Wformat'
            also checks for null format arguments for several functions,
!           '-Wformat' also implies '-Wnonnull'.  Some aspects of this
            level of format checking can be disabled by the options:
!           '-Wno-format-contains-nul', '-Wno-format-extra-args', and
!           '-Wno-format-zero-length'.  '-Wformat' is enabled by '-Wall'.
  
!      '-Wformat=2'
!           Enable '-Wformat' plus additional format checks.  Currently
!           equivalent to '-Wformat -Wformat-nonliteral -Wformat-security
!           -Wformat-y2k'.
  
! '-Wno-format-contains-nul'
!      If '-Wformat' is specified, do not warn about format strings that
       contain NUL bytes.
  
! '-Wno-format-extra-args'
!      If '-Wformat' is specified, do not warn about excess arguments to a
!      'printf' or 'scanf' format function.  The C standard specifies that
       such arguments are ignored.
  
       Where the unused arguments lie between used arguments that are
!      specified with '$' operand number specifications, normally warnings
       are still given, since the implementation could not know what type
!      to pass to 'va_arg' to skip the unused arguments.  However, in the
!      case of 'scanf' formats, this option suppresses the warning if the
       unused arguments are all pointers, since the Single Unix
       Specification says that such unused arguments are allowed.
  
! '-Wformat-overflow'
! '-Wformat-overflow=LEVEL'
       Warn about calls to formatted input/output functions such as
!      'sprintf' and 'vsprintf' that might overflow the destination
       buffer.  When the exact number of bytes written by a format
       directive cannot be determined at compile-time it is estimated
       based on heuristics that depend on the LEVEL argument and on
--- 6069,6115 ----
       and GNU extensions.  Other library implementations may not support
       all these features; GCC does not support warning about features
       that go beyond a particular library's limitations.  However, if
!      ‘-Wpedantic’ is used with ‘-Wformat’, warnings are given about
       format features not in the selected standard version (but not for
!      ‘strfmon’ formats, since those are not in any version of the C
       standard).  *Note Options Controlling C Dialect: C Dialect Options.
  
!      ‘-Wformat=1’
!      ‘-Wformat’
!           Option ‘-Wformat’ is equivalent to ‘-Wformat=1’, and
!           ‘-Wno-format’ is equivalent to ‘-Wformat=0’.  Since ‘-Wformat’
            also checks for null format arguments for several functions,
!           ‘-Wformat’ also implies ‘-Wnonnull’.  Some aspects of this
            level of format checking can be disabled by the options:
!           ‘-Wno-format-contains-nul’, ‘-Wno-format-extra-args’, and
!           ‘-Wno-format-zero-length’.  ‘-Wformat’ is enabled by ‘-Wall’.
  
!      ‘-Wformat=2’
!           Enable ‘-Wformat’ plus additional format checks.  Currently
!           equivalent to ‘-Wformat -Wformat-nonliteral -Wformat-security
!           -Wformat-y2k’.
  
! ‘-Wno-format-contains-nul’
!      If ‘-Wformat’ is specified, do not warn about format strings that
       contain NUL bytes.
  
! ‘-Wno-format-extra-args’
!      If ‘-Wformat’ is specified, do not warn about excess arguments to a
!      ‘printf’ or ‘scanf’ format function.  The C standard specifies that
       such arguments are ignored.
  
       Where the unused arguments lie between used arguments that are
!      specified with ‘$’ operand number specifications, normally warnings
       are still given, since the implementation could not know what type
!      to pass to ‘va_arg’ to skip the unused arguments.  However, in the
!      case of ‘scanf’ formats, this option suppresses the warning if the
       unused arguments are all pointers, since the Single Unix
       Specification says that such unused arguments are allowed.
  
! ‘-Wformat-overflow’
! ‘-Wformat-overflow=LEVEL’
       Warn about calls to formatted input/output functions such as
!      ‘sprintf’ and ‘vsprintf’ that might overflow the destination
       buffer.  When the exact number of bytes written by a format
       directive cannot be determined at compile-time it is estimated
       based on heuristics that depend on the LEVEL argument and on
*************** warnings, in some cases it may also caus
*** 6113,6121 ****
       improve the accuracy of the warning, it may also result in false
       positives.
  
!      '-Wformat-overflow'
!      '-Wformat-overflow=1'
!           Level 1 of '-Wformat-overflow' enabled by '-Wformat' employs a
            conservative approach that warns only about calls that most
            likely overflow the buffer.  At this level, numeric arguments
            to format directives with unknown values are assumed to have
--- 6117,6125 ----
       improve the accuracy of the warning, it may also result in false
       positives.
  
!      ‘-Wformat-overflow’
!      ‘-Wformat-overflow=1’
!           Level 1 of ‘-Wformat-overflow’ enabled by ‘-Wformat’ employs a
            conservative approach that warns only about calls that most
            likely overflow the buffer.  At this level, numeric arguments
            to format directives with unknown values are assumed to have
*************** warnings, in some cases it may also caus
*** 6125,6133 ****
            either by their directive's precision or by a finite set of
            string literals, are assumed to take on the value within the
            range that results in the most bytes on output.  For example,
!           the call to 'sprintf' below is diagnosed because even with
            both A and B equal to zero, the terminating NUL character
!           (''\0'') appended by the function to the destination buffer
            will be written past its end.  Increasing the size of the
            buffer by a single byte is sufficient to avoid the warning,
            though it may not be sufficient to avoid the overflow.
--- 6129,6137 ----
            either by their directive's precision or by a finite set of
            string literals, are assumed to take on the value within the
            range that results in the most bytes on output.  For example,
!           the call to ‘sprintf’ below is diagnosed because even with
            both A and B equal to zero, the terminating NUL character
!           (‘'\0'’) appended by the function to the destination buffer
            will be written past its end.  Increasing the size of the
            buffer by a single byte is sufficient to avoid the warning,
            though it may not be sufficient to avoid the overflow.
*************** warnings, in some cases it may also caus
*** 6138,6144 ****
                   sprintf (buf, "a = %i, b = %i\n", a, b);
                 }
  
!      '-Wformat-overflow=2'
            Level 2 warns also about calls that might overflow the
            destination buffer given an argument of sufficient length or
            magnitude.  At level 2, unknown numeric arguments are assumed
--- 6142,6148 ----
                   sprintf (buf, "a = %i, b = %i\n", a, b);
                 }
  
!      ‘-Wformat-overflow=2’
            Level 2 warns also about calls that might overflow the
            destination buffer given an argument of sufficient length or
            magnitude.  At level 2, unknown numeric arguments are assumed
*************** warnings, in some cases it may also caus
*** 6151,6158 ****
            character long.
  
            At level 2, the call in the example above is again diagnosed,
!           but this time because with A equal to a 32-bit 'INT_MIN' the
!           first '%i' directive will write some of its digits beyond the
            end of the destination buffer.  To make the call safe
            regardless of the values of the two variables, the size of the
            destination buffer must be increased to at least 34 bytes.
--- 6155,6162 ----
            character long.
  
            At level 2, the call in the example above is again diagnosed,
!           but this time because with A equal to a 32-bit ‘INT_MIN’ the
!           first ‘%i’ directive will write some of its digits beyond the
            end of the destination buffer.  To make the call safe
            regardless of the values of the two variables, the size of the
            destination buffer must be increased to at least 34 bytes.
*************** warnings, in some cases it may also caus
*** 6168,6175 ****
            appropriate length modifier to the format specifier will
            reduce the required buffer size.  For example, if A and B in
            the example above can be assumed to be within the precision of
!           the 'short int' type then using either the '%hi' format
!           directive or casting the argument to 'short' reduces the
            maximum required size of the buffer to 24 bytes.
  
                 void f (int a, int b)
--- 6172,6179 ----
            appropriate length modifier to the format specifier will
            reduce the required buffer size.  For example, if A and B in
            the example above can be assumed to be within the precision of
!           the ‘short int’ type then using either the ‘%hi’ format
!           directive or casting the argument to ‘short’ reduces the
            maximum required size of the buffer to 24 bytes.
  
                 void f (int a, int b)
*************** warnings, in some cases it may also caus
*** 6178,6302 ****
                   sprintf (buf, "a = %hi, b = %i\n", a, (short)b);
                 }
  
! '-Wno-format-zero-length'
!      If '-Wformat' is specified, do not warn about zero-length formats.
       The C standard specifies that zero-length formats are allowed.
  
! '-Wformat-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-signedness'
!      If '-Wformat' is specified, also warn if the format string requires
       an unsigned argument and the argument is signed and vice versa.
  
! '-Wformat-truncation'
! '-Wformat-truncation=LEVEL'
       Warn about calls to formatted input/output functions such as
!      'snprintf' and 'vsnprintf' that might result in output truncation.
       When the exact number of bytes written by a format directive cannot
       be determined at compile-time it is estimated based on heuristics
       that depend on the LEVEL argument and on optimization.  While
       enabling optimization will in most cases improve the accuracy of
       the warning, it may also result in false positives.  Except as
       noted otherwise, the option uses the same logic
!      '-Wformat-overflow'.
  
!      '-Wformat-truncation'
!      '-Wformat-truncation=1'
!           Level 1 of '-Wformat-truncation' enabled by '-Wformat' employs
            a conservative approach that warns only about calls to bounded
            functions whose return value is unused and that will most
            likely result in output truncation.
  
!      '-Wformat-truncation=2'
            Level 2 warns also about calls to bounded functions whose
            return value is used and that might result in truncation given
            an argument of sufficient length or magnitude.
  
! '-Wformat-y2k'
!      If '-Wformat' is specified, also warn about 'strftime' formats that
       may yield only a two-digit year.
  
! '-Wnonnull'
       Warn about passing a null pointer for arguments marked as requiring
!      a non-null value by the 'nonnull' function attribute.
  
!      '-Wnonnull' is included in '-Wall' and '-Wformat'.  It can be
!      disabled with the '-Wno-nonnull' option.
  
! '-Wnonnull-compare'
!      Warn when comparing an argument marked with the 'nonnull' function
       attribute against null inside the function.
  
!      '-Wnonnull-compare' is included in '-Wall'.  It can be disabled
!      with the '-Wno-nonnull-compare' option.
  
! '-Wnull-dereference'
       Warn if the compiler detects paths that trigger erroneous or
       undefined behavior due to dereferencing a null pointer.  This
!      option is only active when '-fdelete-null-pointer-checks' is
       active, which is enabled by optimizations in most targets.  The
       precision of the warnings depends on the optimization options used.
  
! '-Winfinite-recursion'
       Warn about infinitely recursive calls.  The warning is effective at
       all optimization levels but requires optimization in order to
       detect infinite recursion in calls between two or more functions.
!      '-Winfinite-recursion' is included in '-Wall'.
  
!      Compare with '-Wanalyzer-infinite-recursion' which provides a
       similar diagnostic, but is implemented in a different way (as part
!      of '-fanalyzer').
  
! '-Winit-self (C, C++, Objective-C and Objective-C++ only)'
       Warn about uninitialized variables that are initialized with
       themselves.  Note this option can only be used with the
!      '-Wuninitialized' option.
  
!      For example, GCC warns about 'i' being uninitialized in the
!      following snippet only when '-Winit-self' has been specified:
            int f()
            {
              int i = i;
              return i;
            }
  
!      This warning is enabled by '-Wall' in C++.
  
! '-Wno-implicit-int (C and Objective-C only)'
       This option controls warnings when a declaration does not specify a
       type.  This warning is enabled by default in C99 and later dialects
!      of C, and also by '-Wall'.
  
! '-Wno-implicit-function-declaration (C and Objective-C only)'
       This option controls warnings when a function is used before being
       declared.  This warning is enabled by default in C99 and later
!      dialects of C, and also by '-Wall'.  The warning is made into an
!      error by '-pedantic-errors'.
  
! '-Wimplicit (C and Objective-C only)'
!      Same as '-Wimplicit-int' and '-Wimplicit-function-declaration'.
!      This warning is enabled by '-Wall'.
  
! '-Wimplicit-fallthrough'
!      '-Wimplicit-fallthrough' is the same as '-Wimplicit-fallthrough=3'
!      and '-Wno-implicit-fallthrough' is the same as
!      '-Wimplicit-fallthrough=0'.
  
! '-Wimplicit-fallthrough=N'
       Warn when a switch case falls through.  For example:
  
            switch (cond)
--- 6182,6306 ----
                   sprintf (buf, "a = %hi, b = %i\n", a, (short)b);
                 }
  
! ‘-Wno-format-zero-length’
!      If ‘-Wformat’ is specified, do not warn about zero-length formats.
       The C standard specifies that zero-length formats are allowed.
  
! ‘-Wformat-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-signedness’
!      If ‘-Wformat’ is specified, also warn if the format string requires
       an unsigned argument and the argument is signed and vice versa.
  
! ‘-Wformat-truncation’
! ‘-Wformat-truncation=LEVEL’
       Warn about calls to formatted input/output functions such as
!      ‘snprintf’ and ‘vsnprintf’ that might result in output truncation.
       When the exact number of bytes written by a format directive cannot
       be determined at compile-time it is estimated based on heuristics
       that depend on the LEVEL argument and on optimization.  While
       enabling optimization will in most cases improve the accuracy of
       the warning, it may also result in false positives.  Except as
       noted otherwise, the option uses the same logic
!      ‘-Wformat-overflow’.
  
!      ‘-Wformat-truncation’
!      ‘-Wformat-truncation=1’
!           Level 1 of ‘-Wformat-truncation’ enabled by ‘-Wformat’ employs
            a conservative approach that warns only about calls to bounded
            functions whose return value is unused and that will most
            likely result in output truncation.
  
!      ‘-Wformat-truncation=2’
            Level 2 warns also about calls to bounded functions whose
            return value is used and that might result in truncation given
            an argument of sufficient length or magnitude.
  
! ‘-Wformat-y2k’
!      If ‘-Wformat’ is specified, also warn about ‘strftime’ formats that
       may yield only a two-digit year.
  
! ‘-Wnonnull’
       Warn about passing a null pointer for arguments marked as requiring
!      a non-null value by the ‘nonnull’ function attribute.
  
!      ‘-Wnonnull’ is included in ‘-Wall’ and ‘-Wformat’.  It can be
!      disabled with the ‘-Wno-nonnull’ option.
  
! ‘-Wnonnull-compare’
!      Warn when comparing an argument marked with the ‘nonnull’ function
       attribute against null inside the function.
  
!      ‘-Wnonnull-compare’ is included in ‘-Wall’.  It can be disabled
!      with the ‘-Wno-nonnull-compare’ option.
  
! ‘-Wnull-dereference’
       Warn if the compiler detects paths that trigger erroneous or
       undefined behavior due to dereferencing a null pointer.  This
!      option is only active when ‘-fdelete-null-pointer-checks’ is
       active, which is enabled by optimizations in most targets.  The
       precision of the warnings depends on the optimization options used.
  
! ‘-Winfinite-recursion’
       Warn about infinitely recursive calls.  The warning is effective at
       all optimization levels but requires optimization in order to
       detect infinite recursion in calls between two or more functions.
!      ‘-Winfinite-recursion’ is included in ‘-Wall’.
  
!      Compare with ‘-Wanalyzer-infinite-recursion’ which provides a
       similar diagnostic, but is implemented in a different way (as part
!      of ‘-fanalyzer’).
  
! ‘-Winit-self (C, C++, Objective-C and Objective-C++ only)’
       Warn about uninitialized variables that are initialized with
       themselves.  Note this option can only be used with the
!      ‘-Wuninitialized’ option.
  
!      For example, GCC warns about ‘i’ being uninitialized in the
!      following snippet only when ‘-Winit-self’ has been specified:
            int f()
            {
              int i = i;
              return i;
            }
  
!      This warning is enabled by ‘-Wall’ in C++.
  
! ‘-Wno-implicit-int (C and Objective-C only)’
       This option controls warnings when a declaration does not specify a
       type.  This warning is enabled by default in C99 and later dialects
!      of C, and also by ‘-Wall’.
  
! ‘-Wno-implicit-function-declaration (C and Objective-C only)’
       This option controls warnings when a function is used before being
       declared.  This warning is enabled by default in C99 and later
!      dialects of C, and also by ‘-Wall’.  The warning is made into an
!      error by ‘-pedantic-errors’.
  
! ‘-Wimplicit (C and Objective-C only)’
!      Same as ‘-Wimplicit-int’ and ‘-Wimplicit-function-declaration’.
!      This warning is enabled by ‘-Wall’.
  
! ‘-Wimplicit-fallthrough’
!      ‘-Wimplicit-fallthrough’ is the same as ‘-Wimplicit-fallthrough=3’
!      and ‘-Wno-implicit-fallthrough’ is the same as
!      ‘-Wimplicit-fallthrough=0’.
  
! ‘-Wimplicit-fallthrough=N’
       Warn when a switch case falls through.  For example:
  
            switch (cond)
*************** warnings, in some cases it may also caus
*** 6314,6320 ****
       This warning does not warn when the last statement of a case cannot
       fall through, e.g.  when there is a return statement or a call to
       function declared with the noreturn attribute.
!      '-Wimplicit-fallthrough=' also takes into account control flow
       statements, such as ifs, and only warns when appropriate.  E.g.
  
            switch (cond)
--- 6318,6324 ----
       This warning does not warn when the last statement of a case cannot
       fall through, e.g.  when there is a return statement or a call to
       function declared with the noreturn attribute.
!      ‘-Wimplicit-fallthrough=’ also takes into account control flow
       statements, such as ifs, and only warns when appropriate.  E.g.
  
            switch (cond)
*************** warnings, in some cases it may also caus
*** 6332,6339 ****
              }
  
       Since there are occasions where a switch case fall through is
!      desirable, GCC provides an attribute, '__attribute__
!      ((fallthrough))', that is to be used along with a null statement to
       suppress this warning that would normally occur:
  
            switch (cond)
--- 6336,6343 ----
              }
  
       Since there are occasions where a switch case fall through is
!      desirable, GCC provides an attribute, ‘__attribute__
!      ((fallthrough))’, that is to be used along with a null statement to
       suppress this warning that would normally occur:
  
            switch (cond)
*************** warnings, in some cases it may also caus
*** 6346,6402 ****
              }
  
       C++17 provides a standard way to suppress the
!      '-Wimplicit-fallthrough' warning using '[[fallthrough]];' instead
       of the GNU attribute.  In C++11 or C++14 users can use
!      '[[gnu::fallthrough]];', which is a GNU extension.  Instead of
       these attributes, it is also possible to add a fallthrough comment
       to silence the warning.  The whole body of the C or C++ style
       comment should match the given regular expressions listed below.
       The option argument N specifies what kind of comments are accepted:
  
!         * '-Wimplicit-fallthrough=0' disables the warning altogether.
  
!         * '-Wimplicit-fallthrough=1' matches '.*' regular expression,
            any comment is used as fallthrough comment.
  
!         * '-Wimplicit-fallthrough=2' case insensitively matches
!           '.*falls?[ \t-]*thr(ough|u).*' regular expression.
  
!         * '-Wimplicit-fallthrough=3' case sensitively matches one of the
            following regular expressions:
  
!              * '-fallthrough'
  
!              * '@fallthrough@'
  
!              * 'lint -fallthrough[ \t]*'
  
!              * '[ \t.!]*(ELSE,? |INTENTIONAL(LY)? )?
!                FALL(S | |-)?THR(OUGH|U)[ \t.!]*(-[^\n\r]*)?'
  
!              * '[ \t.!]*(Else,? |Intentional(ly)? )?
!                Fall((s | |-)[Tt]|t)hr(ough|u)[ \t.!]*(-[^\n\r]*)?'
  
!              * '[ \t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?
!                fall(s | |-)?thr(ough|u)[ \t.!]*(-[^\n\r]*)?'
  
!         * '-Wimplicit-fallthrough=4' case sensitively matches one of the
            following regular expressions:
  
!              * '-fallthrough'
  
!              * '@fallthrough@'
  
!              * 'lint -fallthrough[ \t]*'
  
!              * '[ \t]*FALLTHR(OUGH|U)[ \t]*'
  
!         * '-Wimplicit-fallthrough=5' doesn't recognize any comments as
            fallthrough comments, only attributes disable the warning.
  
       The comment needs to be followed after optional whitespace and
!      other comments by 'case' or 'default' keywords or by a user label
!      that precedes some 'case' or 'default' label.
  
            switch (cond)
              {
--- 6350,6406 ----
              }
  
       C++17 provides a standard way to suppress the
!      ‘-Wimplicit-fallthrough’ warning using ‘[[fallthrough]];’ instead
       of the GNU attribute.  In C++11 or C++14 users can use
!      ‘[[gnu::fallthrough]];’, which is a GNU extension.  Instead of
       these attributes, it is also possible to add a fallthrough comment
       to silence the warning.  The whole body of the C or C++ style
       comment should match the given regular expressions listed below.
       The option argument N specifies what kind of comments are accepted:
  
!         • ‘-Wimplicit-fallthrough=0’ disables the warning altogether.
  
!         • ‘-Wimplicit-fallthrough=1’ matches ‘.*’ regular expression,
            any comment is used as fallthrough comment.
  
!         • ‘-Wimplicit-fallthrough=2’ case insensitively matches
!           ‘.*falls?[ \t-]*thr(ough|u).*’ regular expression.
  
!         • ‘-Wimplicit-fallthrough=3’ case sensitively matches one of the
            following regular expressions:
  
!              • ‘-fallthrough’
  
!              • ‘@fallthrough@’
  
!              • ‘lint -fallthrough[ \t]*’
  
!              • ‘[ \t.!]*(ELSE,? |INTENTIONAL(LY)? )?
!                FALL(S | |-)?THR(OUGH|U)[ \t.!]*(-[^\n\r]*)?’
  
!              • ‘[ \t.!]*(Else,? |Intentional(ly)? )?
!                Fall((s | |-)[Tt]|t)hr(ough|u)[ \t.!]*(-[^\n\r]*)?’
  
!              • ‘[ \t.!]*([Ee]lse,? |[Ii]ntentional(ly)? )?
!                fall(s | |-)?thr(ough|u)[ \t.!]*(-[^\n\r]*)?’
  
!         • ‘-Wimplicit-fallthrough=4’ case sensitively matches one of the
            following regular expressions:
  
!              • ‘-fallthrough’
  
!              • ‘@fallthrough@’
  
!              • ‘lint -fallthrough[ \t]*’
  
!              • ‘[ \t]*FALLTHR(OUGH|U)[ \t]*’
  
!         • ‘-Wimplicit-fallthrough=5’ doesn't recognize any comments as
            fallthrough comments, only attributes disable the warning.
  
       The comment needs to be followed after optional whitespace and
!      other comments by ‘case’ or ‘default’ keywords or by a user label
!      that precedes some ‘case’ or ‘default’ label.
  
            switch (cond)
              {
*************** warnings, in some cases it may also caus
*** 6407,6447 ****
                ...
              }
  
!      The '-Wimplicit-fallthrough=3' warning is enabled by '-Wextra'.
  
! '-Wno-if-not-aligned (C, C++, Objective-C and Objective-C++ only)'
!      Control if warnings triggered by the 'warn_if_not_aligned'
       attribute should be issued.  These warnings are enabled by default.
  
! '-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'.
  
! '-Wno-ignored-attributes (C and C++ only)'
       This option controls warnings when an attribute is ignored.  This
!      is different from the '-Wattributes' option in that it warns
       whenever the compiler decides to drop an attribute, not that the
       attribute is either unknown, used in a wrong place, etc.  This
       warning is enabled by default.
  
! '-Wmain'
!      Warn if the type of 'main' is suspicious.  'main' should be a
       function with external linkage, returning int, taking either zero
       arguments, two, or three arguments of appropriate types.  This
       warning is enabled by default in C++ and is enabled by either
!      '-Wall' or '-Wpedantic'.
  
! '-Wmisleading-indentation (C and C++ only)'
       Warn when the indentation of the code does not reflect the block
!      structure.  Specifically, a warning is issued for 'if', 'else',
!      'while', and 'for' clauses with a guarded statement that does not
       use braces, followed by an unguarded statement with the same
       indentation.
  
--- 6411,6451 ----
                ...
              }
  
!      The ‘-Wimplicit-fallthrough=3’ warning is enabled by ‘-Wextra’.
  
! ‘-Wno-if-not-aligned (C, C++, Objective-C and Objective-C++ only)’
!      Control if warnings triggered by the ‘warn_if_not_aligned’
       attribute should be issued.  These warnings are enabled by default.
  
! ‘-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’.
  
! ‘-Wno-ignored-attributes (C and C++ only)’
       This option controls warnings when an attribute is ignored.  This
!      is different from the ‘-Wattributes’ option in that it warns
       whenever the compiler decides to drop an attribute, not that the
       attribute is either unknown, used in a wrong place, etc.  This
       warning is enabled by default.
  
! ‘-Wmain’
!      Warn if the type of ‘main’ is suspicious.  ‘main’ should be a
       function with external linkage, returning int, taking either zero
       arguments, two, or three arguments of appropriate types.  This
       warning is enabled by default in C++ and is enabled by either
!      ‘-Wall’ or ‘-Wpedantic’.
  
! ‘-Wmisleading-indentation (C and C++ only)’
       Warn when the indentation of the code does not reflect the block
!      structure.  Specifically, a warning is issued for ‘if’, ‘else’,
!      ‘while’, and ‘for’ clauses with a guarded statement that does not
       use braces, followed by an unguarded statement with the same
       indentation.
  
*************** warnings, in some cases it may also caus
*** 6453,6459 ****
                bar ();  /* Gotcha: this is not guarded by the "if".  */
  
       In the case of mixed tabs and spaces, the warning uses the
!      '-ftabstop=' option to determine if the statements line up
       (defaulting to 8).
  
       The warning is not issued for code involving multiline preprocessor
--- 6457,6463 ----
                bar ();  /* Gotcha: this is not guarded by the "if".  */
  
       In the case of mixed tabs and spaces, the warning uses the
!      ‘-ftabstop=’ option to determine if the statements line up
       (defaulting to 8).
  
       The warning is not issued for code involving multiline preprocessor
*************** warnings, in some cases it may also caus
*** 6466,6478 ****
            #endif
                foo (1);
  
!      The warning is not issued after a '#line' directive, since this
       typically indicates autogenerated code, and no assumptions can be
       made about the layout of the file that the directive references.
  
!      This warning is enabled by '-Wall' in C and C++.
  
! '-Wmissing-attributes'
       Warn when a declaration of a function is missing one or more
       attributes that a related function is declared with and whose
       absence may adversely affect the correctness or efficiency of
--- 6470,6482 ----
            #endif
                foo (1);
  
!      The warning is not issued after a ‘#line’ directive, since this
       typically indicates autogenerated code, and no assumptions can be
       made about the layout of the file that the directive references.
  
!      This warning is enabled by ‘-Wall’ in C and C++.
  
! ‘-Wmissing-attributes’
       Warn when a declaration of a function is missing one or more
       attributes that a related function is declared with and whose
       absence may adversely affect the correctness or efficiency of
*************** warnings, in some cases it may also caus
*** 6480,6510 ****
       declarations of aliases that use attributes to specify less
       restrictive requirements than those of their targets.  This
       typically represents a potential optimization opportunity.  By
!      contrast, the '-Wattribute-alias=2' option controls warnings issued
       when the alias is more restrictive than the target, which could
       lead to incorrect code generation.  Attributes considered include
!      'alloc_align', 'alloc_size', 'cold', 'const', 'hot', 'leaf',
!      'malloc', 'nonnull', 'noreturn', 'nothrow', 'pure',
!      'returns_nonnull', and 'returns_twice'.
  
       In C++, the warning is issued when an explicit specialization of a
!      primary template declared with attribute 'alloc_align',
!      'alloc_size', 'assume_aligned', 'format', 'format_arg', 'malloc',
!      or 'nonnull' is declared without it.  Attributes 'deprecated',
!      'error', and 'warning' suppress the warning.  (*note Function
       Attributes::).
  
!      You can use the 'copy' attribute to apply the same set of
       attributes to a declaration as that on another declaration without
       explicitly enumerating the attributes.  This attribute can be
       applied to declarations of functions (*note Common Function
       Attributes::), variables (*note Common Variable Attributes::), or
       types (*note Common Type Attributes::).
  
!      '-Wmissing-attributes' is enabled by '-Wall'.
  
       For example, since the declaration of the primary function template
!      below makes use of both attribute 'malloc' and 'alloc_size' the
       declaration of the explicit specialization of the template is
       diagnosed because it is missing one of the attributes.
  
--- 6484,6514 ----
       declarations of aliases that use attributes to specify less
       restrictive requirements than those of their targets.  This
       typically represents a potential optimization opportunity.  By
!      contrast, the ‘-Wattribute-alias=2’ option controls warnings issued
       when the alias is more restrictive than the target, which could
       lead to incorrect code generation.  Attributes considered include
!      ‘alloc_align’, ‘alloc_size’, ‘cold’, ‘const’, ‘hot’, ‘leaf’,
!      ‘malloc’, ‘nonnull’, ‘noreturn’, ‘nothrow’, ‘pure’,
!      ‘returns_nonnull’, and ‘returns_twice’.
  
       In C++, the warning is issued when an explicit specialization of a
!      primary template declared with attribute ‘alloc_align’,
!      ‘alloc_size’, ‘assume_aligned’, ‘format’, ‘format_arg’, ‘malloc’,
!      or ‘nonnull’ is declared without it.  Attributes ‘deprecated’,
!      ‘error’, and ‘warning’ suppress the warning.  (*note Function
       Attributes::).
  
!      You can use the ‘copy’ attribute to apply the same set of
       attributes to a declaration as that on another declaration without
       explicitly enumerating the attributes.  This attribute can be
       applied to declarations of functions (*note Common Function
       Attributes::), variables (*note Common Variable Attributes::), or
       types (*note Common Type Attributes::).
  
!      ‘-Wmissing-attributes’ is enabled by ‘-Wall’.
  
       For example, since the declaration of the primary function template
!      below makes use of both attribute ‘malloc’ and ‘alloc_size’ the
       declaration of the explicit specialization of the template is
       diagnosed because it is missing one of the attributes.
  
*************** warnings, in some cases it may also caus
*** 6516,6542 ****
            void* __attribute__ ((malloc))   // missing alloc_size
            allocate (size_t);
  
! '-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, Objective-C++ and Fortran only)'
       Warn if a user-supplied include directory does not exist.  This
       option is disabled by default for C, C++, Objective-C and
       Objective-C++.  For Fortran, it is partially enabled by default by
       warning for -I and -J, only.
  
! '-Wno-missing-profile'
       This option controls warnings if feedback profiles are missing when
!      using the '-fprofile-use' option.  This option diagnoses those
       cases where a new function or a new file is added between compiling
!      with '-fprofile-generate' and with '-fprofile-use', without
       regenerating the profiles.  In these cases, the profile feedback
       data files do not contain any profile feedback information for the
       newly added function or file respectively.  Also, in the case when
--- 6520,6546 ----
            void* __attribute__ ((malloc))   // missing alloc_size
            allocate (size_t);
  
! ‘-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, Objective-C++ and Fortran only)’
       Warn if a user-supplied include directory does not exist.  This
       option is disabled by default for C, C++, Objective-C and
       Objective-C++.  For Fortran, it is partially enabled by default by
       warning for -I and -J, only.
  
! ‘-Wno-missing-profile’
       This option controls warnings if feedback profiles are missing when
!      using the ‘-fprofile-use’ option.  This option diagnoses those
       cases where a new function or a new file is added between compiling
!      with ‘-fprofile-generate’ and with ‘-fprofile-use’, without
       regenerating the profiles.  In these cases, the profile feedback
       data files do not contain any profile feedback information for the
       newly added function or file respectively.  Also, in the case when
*************** warnings, in some cases it may also caus
*** 6544,6565 ****
       profile feedback information.  In all these cases, warnings are
       issued to inform you that a profile generation step is due.
       Ignoring the warning can result in poorly optimized code.
!      '-Wno-missing-profile' can be used to disable the warning, but this
       is not recommended and should be done only when non-existent
       profile data is justified.
  
! '-Wmismatched-dealloc'
  
       Warn for calls to deallocation functions with pointer arguments
       returned from from allocations functions for which the former isn't
       a suitable deallocator.  A pair of functions can be associated as
!      matching allocators and deallocators by use of attribute 'malloc'.
!      Unless disabled by the '-fno-builtin' option the standard functions
!      'calloc', 'malloc', 'realloc', and 'free', as well as the
!      corresponding forms of C++ 'operator new' and 'operator delete' are
       implicitly associated as matching allocators and deallocators.  In
!      the following example 'mydealloc' is the deallocator for pointers
!      returned from 'myalloc'.
  
            void mydealloc (void*);
  
--- 6548,6569 ----
       profile feedback information.  In all these cases, warnings are
       issued to inform you that a profile generation step is due.
       Ignoring the warning can result in poorly optimized code.
!      ‘-Wno-missing-profile’ can be used to disable the warning, but this
       is not recommended and should be done only when non-existent
       profile data is justified.
  
! ‘-Wmismatched-dealloc’
  
       Warn for calls to deallocation functions with pointer arguments
       returned from from allocations functions for which the former isn't
       a suitable deallocator.  A pair of functions can be associated as
!      matching allocators and deallocators by use of attribute ‘malloc’.
!      Unless disabled by the ‘-fno-builtin’ option the standard functions
!      ‘calloc’, ‘malloc’, ‘realloc’, and ‘free’, as well as the
!      corresponding forms of C++ ‘operator new’ and ‘operator delete’ are
       implicitly associated as matching allocators and deallocators.  In
!      the following example ‘mydealloc’ is the deallocator for pointers
!      returned from ‘myalloc’.
  
            void mydealloc (void*);
  
*************** warnings, in some cases it may also caus
*** 6574,6588 ****
              mydealloc (p);   // ok
            }
  
!      In C++, the related option '-Wmismatched-new-delete' diagnoses
!      mismatches involving either 'operator new' or 'operator delete'.
  
!      Option '-Wmismatched-dealloc' is included in '-Wall'.
  
! '-Wmultistatement-macros'
       Warn about unsafe multiple statement macros that appear to be
!      guarded by a clause such as 'if', 'else', 'for', 'switch', or
!      'while', in which only the first statement is actually guarded
       after the macro is expanded.
  
       For example:
--- 6578,6592 ----
              mydealloc (p);   // ok
            }
  
!      In C++, the related option ‘-Wmismatched-new-delete’ diagnoses
!      mismatches involving either ‘operator new’ or ‘operator delete’.
  
!      Option ‘-Wmismatched-dealloc’ is included in ‘-Wall’.
  
! ‘-Wmultistatement-macros’
       Warn about unsafe multiple statement macros that appear to be
!      guarded by a clause such as ‘if’, ‘else’, ‘for’, ‘switch’, or
!      ‘while’, in which only the first statement is actually guarded
       after the macro is expanded.
  
       For example:
*************** warnings, in some cases it may also caus
*** 6591,6616 ****
            if (c)
              DOIT;
  
!      will increment 'y' unconditionally, not just when 'c' holds.  The
       can usually be fixed by wrapping the macro in a do-while loop:
            #define DOIT do { x++; y++; } while (0)
            if (c)
              DOIT;
  
!      This warning is enabled by '-Wall' in C and C++.
  
! '-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 for dangerous uses of the GNU extension to '?:' with
!      omitted middle operand.  When the condition in the '?': operator is
       a boolean expression, the omitted value is always 1.  Often
       programmers expect it to be a value computed inside the conditional
       expression instead.
--- 6595,6620 ----
            if (c)
              DOIT;
  
!      will increment ‘y’ unconditionally, not just when ‘c’ holds.  The
       can usually be fixed by wrapping the macro in a do-while loop:
            #define DOIT do { x++; y++; } while (0)
            if (c)
              DOIT;
  
!      This warning is enabled by ‘-Wall’ in C and C++.
  
! ‘-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 for dangerous uses of the GNU extension to ‘?:’ with
!      omitted middle operand.  When the condition in the ‘?’: operator is
       a boolean expression, the omitted value is always 1.  Often
       programmers expect it to be a value computed inside the conditional
       expression instead.
*************** warnings, in some cases it may also caus
*** 6624,6634 ****
              // User meant std::unique_lock lock (mymutex);
            }
  
!      This warning is enabled by '-Wall'.
  
! '-Wno-self-move (C++ and Objective-C++ only)'
       This warning warns when a value is moved to itself with
!      'std::move'.  Such a 'std::move' typically has no effect.
  
            struct T {
            ...
--- 6628,6638 ----
              // User meant std::unique_lock lock (mymutex);
            }
  
!      This warning is enabled by ‘-Wall’.
  
! ‘-Wno-self-move (C++ and Objective-C++ only)’
       This warning warns when a value is moved to itself with
!      ‘std::move’.  Such a ‘std::move’ typically has no effect.
  
            struct T {
            ...
*************** warnings, in some cases it may also caus
*** 6640,6658 ****
              t = std::move (t);
            }
  
!      This warning is enabled by '-Wall'.
  
! '-Wsequence-point'
       Warn about code that may have undefined semantics because of
       violations of sequence point rules in the C and C++ standards.
  
       The C and C++ standards define the order in which expressions in a
!      C/C++ program are evaluated in terms of "sequence points", which
       represent a partial ordering between the execution of parts of the
       program: those executed before the sequence point, and those
       executed after it.  These occur after the evaluation of a full
       expression (one which is not part of a larger expression), after
!      the evaluation of the first operand of a '&&', '||', '? :' or ','
       (comma) operator, before a function is called (but after the
       evaluation of its arguments and the expression denoting the called
       function), and in certain other places.  Other than as expressed by
--- 6644,6662 ----
              t = std::move (t);
            }
  
!      This warning is enabled by ‘-Wall’.
  
! ‘-Wsequence-point’
       Warn about code that may have undefined semantics because of
       violations of sequence point rules in the C and C++ standards.
  
       The C and C++ standards define the order in which expressions in a
!      C/C++ program are evaluated in terms of “sequence points”, which
       represent a partial ordering between the execution of parts of the
       program: those executed before the sequence point, and those
       executed after it.  These occur after the evaluation of a full
       expression (one which is not part of a larger expression), after
!      the evaluation of the first operand of a ‘&&’, ‘||’, ‘? :’ or ‘,’
       (comma) operator, before a function is called (but after the
       evaluation of its arguments and the expression denoting the called
       function), and in certain other places.  Other than as expressed by
*************** warnings, in some cases it may also caus
*** 6674,6681 ****
       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.
--- 6678,6685 ----
       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.
*************** warnings, in some cases it may also caus
*** 6693,6743 ****
       formal definitions, may be found on the GCC readings page, at
       .
  
!      This warning is enabled by '-Wall' for C and C++.
  
! '-Wno-return-local-addr'
       Do not warn about returning a pointer (or in C++, a reference) to a
       variable that goes out of scope after the function returns.
  
! '-Wreturn-type'
       Warn whenever a function is defined with a return type that
!      defaults to 'int'.  Also warn about any 'return' statement with no
!      return value in a function whose return type is not 'void' (falling
       off the end of the function body is considered returning without a
       value).
  
!      For C only, warn about a 'return' statement with an expression in a
!      function whose return type is 'void', unless the expression type is
!      also 'void'.  As a GNU extension, the latter case is accepted
!      without a warning unless '-Wpedantic' is used.  Attempting to use
!      the return value of a non-'void' function other than 'main' that
       flows off the end by reaching the closing curly brace that
       terminates the function is undefined.
  
!      Unlike in C, in C++, flowing off the end of a non-'void' function
!      other than 'main' results in undefined behavior even when the value
       of the function is not used.
  
!      This warning is enabled by default in C++ and by '-Wall' otherwise.
  
! '-Wno-shift-count-negative'
       Controls warnings if a shift count is negative.  This warning is
       enabled by default.
  
! '-Wno-shift-count-overflow'
       Controls warnings if a shift count is greater than or equal to the
       bit width of the type.  This warning is enabled by default.
  
! '-Wshift-negative-value'
       Warn if left shifting a negative value.  This warning is enabled by
!      '-Wextra' in C99 (and newer) and C++11 to C++17 modes.
  
! '-Wno-shift-overflow'
! '-Wshift-overflow=N'
       These options control warnings about left shift overflows.
  
!      '-Wshift-overflow=1'
!           This is the warning level of '-Wshift-overflow' and is enabled
            by default in C99 and C++11 modes (and newer).  This warning
            level does not warn about left-shifting 1 into the sign bit.
            (However, in C, such an overflow is still rejected in contexts
--- 6697,6747 ----
       formal definitions, may be found on the GCC readings page, at
       .
  
!      This warning is enabled by ‘-Wall’ for C and C++.
  
! ‘-Wno-return-local-addr’
       Do not warn about returning a pointer (or in C++, a reference) to a
       variable that goes out of scope after the function returns.
  
! ‘-Wreturn-type’
       Warn whenever a function is defined with a return type that
!      defaults to ‘int’.  Also warn about any ‘return’ statement with no
!      return value in a function whose return type is not ‘void’ (falling
       off the end of the function body is considered returning without a
       value).
  
!      For C only, warn about a ‘return’ statement with an expression in a
!      function whose return type is ‘void’, unless the expression type is
!      also ‘void’.  As a GNU extension, the latter case is accepted
!      without a warning unless ‘-Wpedantic’ is used.  Attempting to use
!      the return value of a non-‘void’ function other than ‘main’ that
       flows off the end by reaching the closing curly brace that
       terminates the function is undefined.
  
!      Unlike in C, in C++, flowing off the end of a non-‘void’ function
!      other than ‘main’ results in undefined behavior even when the value
       of the function is not used.
  
!      This warning is enabled by default in C++ and by ‘-Wall’ otherwise.
  
! ‘-Wno-shift-count-negative’
       Controls warnings if a shift count is negative.  This warning is
       enabled by default.
  
! ‘-Wno-shift-count-overflow’
       Controls warnings if a shift count is greater than or equal to the
       bit width of the type.  This warning is enabled by default.
  
! ‘-Wshift-negative-value’
       Warn if left shifting a negative value.  This warning is enabled by
!      ‘-Wextra’ in C99 (and newer) and C++11 to C++17 modes.
  
! ‘-Wno-shift-overflow’
! ‘-Wshift-overflow=N’
       These options control warnings about left shift overflows.
  
!      ‘-Wshift-overflow=1’
!           This is the warning level of ‘-Wshift-overflow’ and is enabled
            by default in C99 and C++11 modes (and newer).  This warning
            level does not warn about left-shifting 1 into the sign bit.
            (However, in C, such an overflow is still rejected in contexts
*************** warnings, in some cases it may also caus
*** 6745,6792 ****
            is emitted in C++20 mode (and newer), as signed left shifts
            always wrap.
  
!      '-Wshift-overflow=2'
            This warning level also warns about left-shifting 1 into the
            sign bit, unless C++14 mode (or newer) is active.
  
! '-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.
  
! '-Wno-switch-bool'
!      Do not warn when a 'switch' statement has an index of boolean type
       and the case values are outside the range of a boolean type.  It is
       possible to suppress this warning by casting the controlling
!      expression to a type other than 'bool'.  For example:
            switch ((int) (a == 4))
              {
              ...
              }
       This warning is enabled by default for C and C++ programs.
  
! '-Wno-switch-outside-range'
!      This option controls warnings when a 'switch' case has a value that
       is outside of its respective type range.  This warning is enabled
       by default for C and C++ programs.
  
! '-Wno-switch-unreachable'
!      Do not warn when a 'switch' statement contains statements between
       the controlling expression and the first case label, which will
       never be executed.  For example:
            switch (cond)
--- 6749,6796 ----
            is emitted in C++20 mode (and newer), as signed left shifts
            always wrap.
  
!      ‘-Wshift-overflow=2’
            This warning level also warns about left-shifting 1 into the
            sign bit, unless C++14 mode (or newer) is active.
  
! ‘-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.
  
! ‘-Wno-switch-bool’
!      Do not warn when a ‘switch’ statement has an index of boolean type
       and the case values are outside the range of a boolean type.  It is
       possible to suppress this warning by casting the controlling
!      expression to a type other than ‘bool’.  For example:
            switch ((int) (a == 4))
              {
              ...
              }
       This warning is enabled by default for C and C++ programs.
  
! ‘-Wno-switch-outside-range’
!      This option controls warnings when a ‘switch’ case has a value that
       is outside of its respective type range.  This warning is enabled
       by default for C and C++ programs.
  
! ‘-Wno-switch-unreachable’
!      Do not warn when a ‘switch’ statement contains statements between
       the controlling expression and the first case label, which will
       never be executed.  For example:
            switch (cond)
*************** warnings, in some cases it may also caus
*** 6796,6802 ****
               case 5:
              ...
              }
!      '-Wswitch-unreachable' does not warn if the statement between the
       controlling expression and the first case label is just a
       declaration:
            switch (cond)
--- 6800,6806 ----
               case 5:
              ...
              }
!      ‘-Wswitch-unreachable’ does not warn if the statement between the
       controlling expression and the first case label is just a
       declaration:
            switch (cond)
*************** warnings, in some cases it may also caus
*** 6809,6940 ****
              }
       This warning is enabled by default for C and C++ programs.
  
! '-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.
  
! '-Wtrivial-auto-var-init'
!      Warn when '-ftrivial-auto-var-init' cannot initialize the automatic
       variable.  A common situation is an automatic variable that is
       declared between the controlling expression and the first case
!      label of a 'switch' statement.
  
! '-Wunused-but-set-parameter'
       Warn whenever a function parameter is assigned to, but otherwise
       unused (aside from its declaration).
  
!      To suppress this warning use the 'unused' attribute (*note Variable
       Attributes::).
  
!      This warning is also enabled by '-Wunused' together with '-Wextra'.
  
! '-Wunused-but-set-variable'
       Warn whenever a local variable is assigned to, but otherwise unused
!      (aside from its declaration).  This warning is enabled by '-Wall'.
  
!      To suppress this warning use the 'unused' attribute (*note Variable
       Attributes::).
  
!      This warning is also enabled by '-Wunused', which is enabled by
!      '-Wall'.
  
! '-Wunused-function'
       Warn whenever a static function is declared but not defined or a
       non-inline static function is unused.  This warning is enabled by
!      '-Wall'.
  
! '-Wunused-label'
       Warn whenever a label is declared but not used.  This warning is
!      enabled by '-Wall'.
  
!      To suppress this warning use the 'unused' attribute (*note Variable
       Attributes::).
  
! '-Wunused-local-typedefs (C, Objective-C, C++ and Objective-C++ only)'
       Warn when a typedef locally defined in a function is not used.
!      This warning is enabled by '-Wall'.
  
! '-Wunused-parameter'
       Warn whenever a function parameter is unused aside from its
       declaration.
  
!      To suppress this warning use the 'unused' attribute (*note Variable
       Attributes::).
  
! '-Wno-unused-result'
       Do not warn if a caller of a function marked with attribute
!      'warn_unused_result' (*note Function Attributes::) does not use its
!      return value.  The default is '-Wunused-result'.
  
! '-Wunused-variable'
       Warn whenever a local or static variable is unused aside from its
!      declaration.  This option implies '-Wunused-const-variable=1' for
!      C, but not for C++.  This warning is enabled by '-Wall'.
  
!      To suppress this warning use the 'unused' attribute (*note Variable
       Attributes::).
  
! '-Wunused-const-variable'
! '-Wunused-const-variable=N'
       Warn whenever a constant static variable is unused aside from its
!      declaration.  '-Wunused-const-variable=1' is enabled by
!      '-Wunused-variable' for C, but not for C++.  In C this declares
       variable storage, but in C++ this is not an error since const
!      variables take the place of '#define's.
  
!      To suppress this warning use the 'unused' attribute (*note Variable
       Attributes::).
  
!      '-Wunused-const-variable=1'
            This is the warning level that is enabled by
!           '-Wunused-variable' for C. It warns only about unused static
            const variables defined in the main compilation unit, but not
            about static const variables declared in any header included.
  
!      '-Wunused-const-variable=2'
            This warning level also warns for unused constant static
            variables in headers (excluding system headers).  This is the
!           warning level of '-Wunused-const-variable' and must be
            explicitly requested since in C++ this isn't an error and in C
            it might be harder to clean up all headers included.
  
! '-Wunused-value'
       Warn whenever a statement computes a result that is explicitly not
       used.  To suppress this warning cast the unused expression to
!      'void'.  This includes an expression-statement or the left-hand
       side of a comma expression that contains no side effects.  For
!      example, an expression such as 'x[i,j]' causes a warning, while
!      'x[(void)i,j]' does not.
  
!      This warning is enabled by '-Wall'.
  
! '-Wunused'
!      All the above '-Wunused' options combined.
  
       In order to get a warning about an unused function parameter, you
!      must either specify '-Wextra -Wunused' (note that '-Wall' implies
!      '-Wunused'), or separately specify '-Wunused-parameter'.
  
! '-Wuninitialized'
       Warn if an object with automatic or allocated storage duration is
       used without having been initialized.  In C++, also warn if a
!      non-static reference or non-static 'const' member appears in a
       class without constructors.
  
       In addition, passing a pointer (or in C++, a reference) to an
!      uninitialized object to a 'const'-qualified argument of a built-in
       function known to read the object is also diagnosed by this
!      warning.  ('-Wmaybe-uninitialized' is issued for ordinary
       functions.)
  
       If you want to warn about code that uses the uninitialized value of
!      the variable in its own initializer, use the '-Winit-self' option.
  
       These warnings occur for individual uninitialized elements of
       structure, union or array variables as well as for variables that
       are uninitialized 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 depend on the precise optimization options and version of
       GCC used.
--- 6813,6944 ----
              }
       This warning is enabled by default for C and C++ programs.
  
! ‘-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.
  
! ‘-Wtrivial-auto-var-init’
!      Warn when ‘-ftrivial-auto-var-init’ cannot initialize the automatic
       variable.  A common situation is an automatic variable that is
       declared between the controlling expression and the first case
!      label of a ‘switch’ statement.
  
! ‘-Wunused-but-set-parameter’
       Warn whenever a function parameter is assigned to, but otherwise
       unused (aside from its declaration).
  
!      To suppress this warning use the ‘unused’ attribute (*note Variable
       Attributes::).
  
!      This warning is also enabled by ‘-Wunused’ together with ‘-Wextra’.
  
! ‘-Wunused-but-set-variable’
       Warn whenever a local variable is assigned to, but otherwise unused
!      (aside from its declaration).  This warning is enabled by ‘-Wall’.
  
!      To suppress this warning use the ‘unused’ attribute (*note Variable
       Attributes::).
  
!      This warning is also enabled by ‘-Wunused’, which is enabled by
!      ‘-Wall’.
  
! ‘-Wunused-function’
       Warn whenever a static function is declared but not defined or a
       non-inline static function is unused.  This warning is enabled by
!      ‘-Wall’.
  
! ‘-Wunused-label’
       Warn whenever a label is declared but not used.  This warning is
!      enabled by ‘-Wall’.
  
!      To suppress this warning use the ‘unused’ attribute (*note Variable
       Attributes::).
  
! ‘-Wunused-local-typedefs (C, Objective-C, C++ and Objective-C++ only)’
       Warn when a typedef locally defined in a function is not used.
!      This warning is enabled by ‘-Wall’.
  
! ‘-Wunused-parameter’
       Warn whenever a function parameter is unused aside from its
       declaration.
  
!      To suppress this warning use the ‘unused’ attribute (*note Variable
       Attributes::).
  
! ‘-Wno-unused-result’
       Do not warn if a caller of a function marked with attribute
!      ‘warn_unused_result’ (*note Function Attributes::) does not use its
!      return value.  The default is ‘-Wunused-result’.
  
! ‘-Wunused-variable’
       Warn whenever a local or static variable is unused aside from its
!      declaration.  This option implies ‘-Wunused-const-variable=1’ for
!      C, but not for C++.  This warning is enabled by ‘-Wall’.
  
!      To suppress this warning use the ‘unused’ attribute (*note Variable
       Attributes::).
  
! ‘-Wunused-const-variable’
! ‘-Wunused-const-variable=N’
       Warn whenever a constant static variable is unused aside from its
!      declaration.  ‘-Wunused-const-variable=1’ is enabled by
!      ‘-Wunused-variable’ for C, but not for C++.  In C this declares
       variable storage, but in C++ this is not an error since const
!      variables take the place of ‘#define’s.
  
!      To suppress this warning use the ‘unused’ attribute (*note Variable
       Attributes::).
  
!      ‘-Wunused-const-variable=1’
            This is the warning level that is enabled by
!           ‘-Wunused-variable’ for C. It warns only about unused static
            const variables defined in the main compilation unit, but not
            about static const variables declared in any header included.
  
!      ‘-Wunused-const-variable=2’
            This warning level also warns for unused constant static
            variables in headers (excluding system headers).  This is the
!           warning level of ‘-Wunused-const-variable’ and must be
            explicitly requested since in C++ this isn't an error and in C
            it might be harder to clean up all headers included.
  
! ‘-Wunused-value’
       Warn whenever a statement computes a result that is explicitly not
       used.  To suppress this warning cast the unused expression to
!      ‘void’.  This includes an expression-statement or the left-hand
       side of a comma expression that contains no side effects.  For
!      example, an expression such as ‘x[i,j]’ causes a warning, while
!      ‘x[(void)i,j]’ does not.
  
!      This warning is enabled by ‘-Wall’.
  
! ‘-Wunused’
!      All the above ‘-Wunused’ options combined.
  
       In order to get a warning about an unused function parameter, you
!      must either specify ‘-Wextra -Wunused’ (note that ‘-Wall’ implies
!      ‘-Wunused’), or separately specify ‘-Wunused-parameter’.
  
! ‘-Wuninitialized’
       Warn if an object with automatic or allocated storage duration is
       used without having been initialized.  In C++, also warn if a
!      non-static reference or non-static ‘const’ member appears in a
       class without constructors.
  
       In addition, passing a pointer (or in C++, a reference) to an
!      uninitialized object to a ‘const’-qualified argument of a built-in
       function known to read the object is also diagnosed by this
!      warning.  (‘-Wmaybe-uninitialized’ is issued for ordinary
       functions.)
  
       If you want to warn about code that uses the uninitialized value of
!      the variable in its own initializer, use the ‘-Winit-self’ option.
  
       These warnings occur for individual uninitialized elements of
       structure, union or array variables as well as for variables that
       are uninitialized 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 depend on the precise optimization options and version of
       GCC used.
*************** warnings, in some cases it may also caus
*** 6945,6951 ****
       warnings are printed.
  
       In C++, this warning also warns about using uninitialized objects
!      in member-initializer-lists.  For example, GCC warns about 'b'
       being uninitialized in the following snippet:
  
            struct A {
--- 6949,6955 ----
       warnings are printed.
  
       In C++, this warning also warns about using uninitialized objects
!      in member-initializer-lists.  For example, GCC warns about ‘b’
       being uninitialized in the following snippet:
  
            struct A {
*************** warnings, in some cases it may also caus
*** 6954,6966 ****
              A() : a(b) { }
            };
  
! '-Wno-invalid-memory-model'
       This option controls warnings for invocations of *note __atomic
       Builtins::, *note __sync Builtins::, and the C11 atomic generic
       functions with a memory consistency argument that is either invalid
       for the operation or outside the range of values of the
!      'memory_order' enumeration.  For example, since the
!      '__atomic_store' and '__atomic_store_n' built-ins are only defined
       for the relaxed, release, and sequentially consistent memory orders
       the following code is diagnosed:
  
--- 6958,6970 ----
              A() : a(b) { }
            };
  
! ‘-Wno-invalid-memory-model’
       This option controls warnings for invocations of *note __atomic
       Builtins::, *note __sync Builtins::, and the C11 atomic generic
       functions with a memory consistency argument that is either invalid
       for the operation or outside the range of values of the
!      ‘memory_order’ enumeration.  For example, since the
!      ‘__atomic_store’ and ‘__atomic_store_n’ built-ins are only defined
       for the relaxed, release, and sequentially consistent memory orders
       the following code is diagnosed:
  
*************** warnings, in some cases it may also caus
*** 6969,6977 ****
              __atomic_store_n (i, 0, memory_order_consume);
            }
  
!      '-Winvalid-memory-model' is enabled by default.
  
! '-Wmaybe-uninitialized'
       For an object with automatic or allocated storage duration, if
       there exists a path from the function entry to a use of the object
       that is initialized, but there exist some other paths for which the
--- 6973,6981 ----
              __atomic_store_n (i, 0, memory_order_consume);
            }
  
!      ‘-Winvalid-memory-model’ is enabled by default.
  
! ‘-Wmaybe-uninitialized’
       For an object with automatic or allocated storage duration, if
       there exists a path from the function entry to a use of the object
       that is initialized, but there exist some other paths for which the
*************** warnings, in some cases it may also caus
*** 6979,6988 ****
       cannot prove the uninitialized paths are not executed at run time.
  
       In addition, passing a pointer (or in C++, a reference) to an
!      uninitialized object to a 'const'-qualified function argument is
!      also diagnosed by this warning.  ('-Wuninitialized' is issued for
       built-in functions known to read the object.)  Annotating the
!      function with attribute 'access (none)' indicates that the argument
       isn't used to access the object and avoids the warning (*note
       Common Function Attributes::).
  
--- 6983,6992 ----
       cannot prove the uninitialized paths are not executed at run time.
  
       In addition, passing a pointer (or in C++, a reference) to an
!      uninitialized object to a ‘const’-qualified function argument is
!      also diagnosed by this warning.  (‘-Wuninitialized’ is issued for
       built-in functions known to read the object.)  Annotating the
!      function with attribute ‘access (none)’ indicates that the argument
       isn't used to access the object and avoids the warning (*note
       Common Function Attributes::).
  
*************** warnings, in some cases it may also caus
*** 7006,7066 ****
              foo (x);
            }
  
!      If the value of 'y' is always 1, 2 or 3, then 'x' is always
       initialized, but GCC doesn't know this.  To suppress the warning,
       you need to provide a default case with assert(0) or similar code.
  
       This option also warns when a non-volatile automatic variable might
!      be changed by a call to 'longjmp'.  The compiler sees only the
!      calls to 'setjmp'.  It cannot know where 'longjmp' will be called;
       in fact, a signal handler could call it at any point in the code.
       As a result, you may get a warning even when there is in fact no
!      problem because 'longjmp' cannot in fact be called at the place
       that would cause a problem.
  
       Some spurious warnings can be avoided if you declare all the
!      functions you use that never return as 'noreturn'.  *Note Function
       Attributes::.
  
!      This warning is enabled by '-Wall' or '-Wextra'.
  
! '-Wunknown-pragmas'
!      Warn when a '#pragma' directive is encountered that is not
       understood by GCC.  If this command-line option is used, warnings
       are even issued for unknown pragmas in system header files.  This
!      is not the case if the warnings are only enabled by the '-Wall'
       command-line option.
  
! '-Wno-pragmas'
       Do not warn about misuses of pragmas, such as incorrect parameters,
       invalid syntax, or conflicts between pragmas.  See also
!      '-Wunknown-pragmas'.
  
! '-Wno-prio-ctor-dtor'
       Do not warn if a priority from 0 to 100 is used for constructor or
       destructor.  The use of constructor and destructor attributes allow
       you to assign a priority to the constructor/destructor to control
!      its order of execution before 'main' is called or after it returns.
       The priority values must be greater than 100 as the compiler
       reserves priority values between 0-100 for the implementation.
  
! '-Wstrict-aliasing'
!      This option is only active when '-fstrict-aliasing' is active.  It
       warns about code that might break the strict aliasing rules that
       the compiler is using for optimization.  The warning does not catch
       all cases, but does attempt to catch the more common pitfalls.  It
!      is included in '-Wall'.  It is equivalent to '-Wstrict-aliasing=3'
  
! '-Wstrict-aliasing=n'
!      This option is only active when '-fstrict-aliasing' is active.  It
       warns about code that might break the strict aliasing rules that
       the compiler is using for optimization.  Higher levels correspond
       to higher accuracy (fewer false positives).  Higher levels also
!      correspond to more effort, similar to the way '-O' works.
!      '-Wstrict-aliasing' is equivalent to '-Wstrict-aliasing=3'.
  
       Level 1: Most aggressive, quick, least accurate.  Possibly useful
!      when higher levels do not warn but '-fstrict-aliasing' still breaks
       the code, as it has very few false negatives.  However, it has many
       false positives.  Warns for all pointer conversions between
       possibly incompatible types, even if never dereferenced.  Runs in
--- 7010,7070 ----
              foo (x);
            }
  
!      If the value of ‘y’ is always 1, 2 or 3, then ‘x’ is always
       initialized, but GCC doesn't know this.  To suppress the warning,
       you need to provide a default case with assert(0) or similar code.
  
       This option also warns when a non-volatile automatic variable might
!      be changed by a call to ‘longjmp’.  The compiler sees only the
!      calls to ‘setjmp’.  It cannot know where ‘longjmp’ will be called;
       in fact, a signal handler could call it at any point in the code.
       As a result, you may get a warning even when there is in fact no
!      problem because ‘longjmp’ cannot in fact be called at the place
       that would cause a problem.
  
       Some spurious warnings can be avoided if you declare all the
!      functions you use that never return as ‘noreturn’.  *Note Function
       Attributes::.
  
!      This warning is enabled by ‘-Wall’ or ‘-Wextra’.
  
! ‘-Wunknown-pragmas’
!      Warn when a ‘#pragma’ directive is encountered that is not
       understood by GCC.  If this command-line option is used, warnings
       are even issued for unknown pragmas in system header files.  This
!      is not the case if the warnings are only enabled by the ‘-Wall’
       command-line option.
  
! ‘-Wno-pragmas’
       Do not warn about misuses of pragmas, such as incorrect parameters,
       invalid syntax, or conflicts between pragmas.  See also
!      ‘-Wunknown-pragmas’.
  
! ‘-Wno-prio-ctor-dtor’
       Do not warn if a priority from 0 to 100 is used for constructor or
       destructor.  The use of constructor and destructor attributes allow
       you to assign a priority to the constructor/destructor to control
!      its order of execution before ‘main’ is called or after it returns.
       The priority values must be greater than 100 as the compiler
       reserves priority values between 0-100 for the implementation.
  
! ‘-Wstrict-aliasing’
!      This option is only active when ‘-fstrict-aliasing’ is active.  It
       warns about code that might break the strict aliasing rules that
       the compiler is using for optimization.  The warning does not catch
       all cases, but does attempt to catch the more common pitfalls.  It
!      is included in ‘-Wall’.  It is equivalent to ‘-Wstrict-aliasing=3’
  
! ‘-Wstrict-aliasing=n’
!      This option is only active when ‘-fstrict-aliasing’ is active.  It
       warns about code that might break the strict aliasing rules that
       the compiler is using for optimization.  Higher levels correspond
       to higher accuracy (fewer false positives).  Higher levels also
!      correspond to more effort, similar to the way ‘-O’ works.
!      ‘-Wstrict-aliasing’ is equivalent to ‘-Wstrict-aliasing=3’.
  
       Level 1: Most aggressive, quick, least accurate.  Possibly useful
!      when higher levels do not warn but ‘-fstrict-aliasing’ still breaks
       the code, as it has very few false negatives.  However, it has many
       false positives.  Warns for all pointer conversions between
       possibly incompatible types, even if never dereferenced.  Runs in
*************** warnings, in some cases it may also caus
*** 7072,7089 ****
       only warns when an address is taken.  Warns about incomplete types.
       Runs in the front end only.
  
!      Level 3 (default for '-Wstrict-aliasing'): Should have very few
       false positives and few false negatives.  Slightly slower than
       levels 1 or 2 when optimization is enabled.  Takes care of the
       common pun+dereference pattern in the front end:
!      '*(int*)&some_float'.  If optimization is enabled, it also runs in
       the back end, where it deals with multiple statement cases using
       flow-sensitive points-to information.  Only warns when the
       converted pointer is dereferenced.  Does not warn about incomplete
       types.
  
! '-Wstrict-overflow'
! '-Wstrict-overflow=N'
       This option is only active when signed overflow is undefined.  It
       warns about cases where the compiler optimizes based on the
       assumption that signed overflow does not occur.  Note that it does
--- 7076,7093 ----
       only warns when an address is taken.  Warns about incomplete types.
       Runs in the front end only.
  
!      Level 3 (default for ‘-Wstrict-aliasing’): Should have very few
       false positives and few false negatives.  Slightly slower than
       levels 1 or 2 when optimization is enabled.  Takes care of the
       common pun+dereference pattern in the front end:
!      ‘*(int*)&some_float’.  If optimization is enabled, it also runs in
       the back end, where it deals with multiple statement cases using
       flow-sensitive points-to information.  Only warns when the
       converted pointer is dereferenced.  Does not warn about incomplete
       types.
  
! ‘-Wstrict-overflow’
! ‘-Wstrict-overflow=N’
       This option is only active when signed overflow is undefined.  It
       warns about cases where the compiler optimizes based on the
       assumption that signed overflow does not occur.  Note that it does
*************** warnings, in some cases it may also caus
*** 7101,7144 ****
       loop requires, in particular when determining whether a loop will
       be executed at all.
  
!      '-Wstrict-overflow=1'
            Warn about cases that are both questionable and easy to avoid.
!           For example the compiler simplifies 'x + 1 > x' to '1'.  This
!           level of '-Wstrict-overflow' is enabled by '-Wall'; higher
            levels are not, and must be explicitly requested.
  
!      '-Wstrict-overflow=2'
            Also warn about other cases where a comparison is simplified
!           to a constant.  For example: 'abs (x) >= 0'.  This can only be
            simplified when signed integer overflow is undefined, because
!           'abs (INT_MIN)' overflows to 'INT_MIN', which is less than
!           zero.  '-Wstrict-overflow' (with no level) is the same as
!           '-Wstrict-overflow=2'.
  
!      '-Wstrict-overflow=3'
            Also warn about other cases where a comparison is simplified.
!           For example: 'x + 1 > 1' is simplified to 'x > 0'.
  
!      '-Wstrict-overflow=4'
            Also warn about other simplifications not covered by the above
!           cases.  For example: '(x * 10) / 5' is simplified to 'x * 2'.
  
!      '-Wstrict-overflow=5'
            Also warn about cases where the compiler reduces the magnitude
!           of a constant involved in a comparison.  For example: 'x + 2 >
!           y' is simplified to 'x + 1 >= y'.  This is reported only at
            the highest warning level because this simplification applies
            to many comparisons, so this warning level gives a very large
            number of false positives.
  
! '-Wstring-compare'
!      Warn for calls to 'strcmp' and 'strncmp' whose result is determined
       to be either zero or non-zero in tests for such equality owing to
       the length of one argument being greater than the size of the array
       the other argument is stored in (or the bound in the case of
!      'strncmp').  Such calls could be mistakes.  For example, the call
!      to 'strcmp' below is diagnosed because its result is necessarily
!      non-zero irrespective of the contents of the array 'a'.
  
            extern char a[4];
            void f (char *d)
--- 7105,7148 ----
       loop requires, in particular when determining whether a loop will
       be executed at all.
  
!      ‘-Wstrict-overflow=1’
            Warn about cases that are both questionable and easy to avoid.
!           For example the compiler simplifies ‘x + 1 > x’ to ‘1’.  This
!           level of ‘-Wstrict-overflow’ is enabled by ‘-Wall’; higher
            levels are not, and must be explicitly requested.
  
!      ‘-Wstrict-overflow=2’
            Also warn about other cases where a comparison is simplified
!           to a constant.  For example: ‘abs (x) >= 0’.  This can only be
            simplified when signed integer overflow is undefined, because
!           ‘abs (INT_MIN)’ overflows to ‘INT_MIN’, which is less than
!           zero.  ‘-Wstrict-overflow’ (with no level) is the same as
!           ‘-Wstrict-overflow=2’.
  
!      ‘-Wstrict-overflow=3’
            Also warn about other cases where a comparison is simplified.
!           For example: ‘x + 1 > 1’ is simplified to ‘x > 0’.
  
!      ‘-Wstrict-overflow=4’
            Also warn about other simplifications not covered by the above
!           cases.  For example: ‘(x * 10) / 5’ is simplified to ‘x * 2’.
  
!      ‘-Wstrict-overflow=5’
            Also warn about cases where the compiler reduces the magnitude
!           of a constant involved in a comparison.  For example: ‘x + 2 >
!           y’ is simplified to ‘x + 1 >= y’.  This is reported only at
            the highest warning level because this simplification applies
            to many comparisons, so this warning level gives a very large
            number of false positives.
  
! ‘-Wstring-compare’
!      Warn for calls to ‘strcmp’ and ‘strncmp’ whose result is determined
       to be either zero or non-zero in tests for such equality owing to
       the length of one argument being greater than the size of the array
       the other argument is stored in (or the bound in the case of
!      ‘strncmp’).  Such calls could be mistakes.  For example, the call
!      to ‘strcmp’ below is diagnosed because its result is necessarily
!      non-zero irrespective of the contents of the array ‘a’.
  
            extern char a[4];
            void f (char *d)
*************** warnings, in some cases it may also caus
*** 7149,7177 ****
                puts ("a and d are the same");
            }
  
!      '-Wstring-compare' is enabled by '-Wextra'.
  
! '-Wno-stringop-overflow'
! '-Wstringop-overflow'
! '-Wstringop-overflow=TYPE'
!      Warn for calls to string manipulation functions such as 'memcpy'
!      and 'strcpy' that are determined to overflow the destination
       buffer.  The optional argument is one greater than the type of
       Object Size Checking to perform to determine the size of the
       destination.  *Note Object Size Checking::.  The argument is
       meaningful only for functions that operate on character arrays but
!      not for raw memory functions like 'memcpy' which always make use of
       Object Size type-0.  The option also warns for calls that specify a
!      size in excess of the largest possible object or at most 'SIZE_MAX
!      / 2' bytes.  The option produces the best results with optimization
       enabled but can detect a small subset of simple buffer overflows
       even without optimization in calls to the GCC built-in functions
!      like '__builtin_memcpy' that correspond to the standard functions.
       In any case, the option warns about just a subset of buffer
       overflows detected by the corresponding overflow checking
       built-ins.  For example, the option issues a warning for the
!      'strcpy' call below because it copies at least 5 characters (the
!      string '"blue"' including the terminating NUL) into the buffer of
       size 4.
  
            enum Color { blue, purple, yellow };
--- 7153,7181 ----
                puts ("a and d are the same");
            }
  
!      ‘-Wstring-compare’ is enabled by ‘-Wextra’.
  
! ‘-Wno-stringop-overflow’
! ‘-Wstringop-overflow’
! ‘-Wstringop-overflow=TYPE’
!      Warn for calls to string manipulation functions such as ‘memcpy’
!      and ‘strcpy’ that are determined to overflow the destination
       buffer.  The optional argument is one greater than the type of
       Object Size Checking to perform to determine the size of the
       destination.  *Note Object Size Checking::.  The argument is
       meaningful only for functions that operate on character arrays but
!      not for raw memory functions like ‘memcpy’ which always make use of
       Object Size type-0.  The option also warns for calls that specify a
!      size in excess of the largest possible object or at most ‘SIZE_MAX
!      / 2’ bytes.  The option produces the best results with optimization
       enabled but can detect a small subset of simple buffer overflows
       even without optimization in calls to the GCC built-in functions
!      like ‘__builtin_memcpy’ that correspond to the standard functions.
       In any case, the option warns about just a subset of buffer
       overflows detected by the corresponding overflow checking
       built-ins.  For example, the option issues a warning for the
!      ‘strcpy’ call below because it copies at least 5 characters (the
!      string ‘"blue"’ including the terminating NUL) into the buffer of
       size 4.
  
            enum Color { blue, purple, yellow };
*************** warnings, in some cases it may also caus
*** 7189,7199 ****
              return strcpy (buf, str);   // warning here
            }
  
!      Option '-Wstringop-overflow=2' is enabled by default.
  
!      '-Wstringop-overflow'
!      '-Wstringop-overflow=1'
!           The '-Wstringop-overflow=1' option uses type-zero Object Size
            Checking to determine the sizes of destination objects.  At
            this setting the option does not warn for writes past the end
            of subobjects of larger objects accessed by pointers unless
--- 7193,7203 ----
              return strcpy (buf, str);   // warning here
            }
  
!      Option ‘-Wstringop-overflow=2’ is enabled by default.
  
!      ‘-Wstringop-overflow’
!      ‘-Wstringop-overflow=1’
!           The ‘-Wstringop-overflow=1’ option uses type-zero Object Size
            Checking to determine the sizes of destination objects.  At
            this setting the option does not warn for writes past the end
            of subobjects of larger objects accessed by pointers unless
*************** warnings, in some cases it may also caus
*** 7201,7211 ****
            destination may be one of several objects it is assumed to be
            the largest one of them.  On Linux systems, when optimization
            is enabled at this setting the option warns for the same code
!           as when the '_FORTIFY_SOURCE' macro is defined to a non-zero
            value.
  
!      '-Wstringop-overflow=2'
!           The '-Wstringop-overflow=2' option uses type-one Object Size
            Checking to determine the sizes of destination objects.  At
            this setting the option warns about overflows when writing to
            members of the largest complete objects whose exact size is
--- 7205,7215 ----
            destination may be one of several objects it is assumed to be
            the largest one of them.  On Linux systems, when optimization
            is enabled at this setting the option warns for the same code
!           as when the ‘_FORTIFY_SOURCE’ macro is defined to a non-zero
            value.
  
!      ‘-Wstringop-overflow=2’
!           The ‘-Wstringop-overflow=2’ option uses type-one Object Size
            Checking to determine the sizes of destination objects.  At
            this setting the option warns about overflows when writing to
            members of the largest complete objects whose exact size is
*************** warnings, in some cases it may also caus
*** 7214,7251 ****
            they may point to arrays containing unknown numbers of
            elements.  This is the default setting of the option.
  
!      '-Wstringop-overflow=3'
!           The '-Wstringop-overflow=3' option uses type-two Object Size
            Checking to determine the sizes of destination objects.  At
            this setting the option warns about overflowing the smallest
            object or data member.  This is the most restrictive setting
            of the option that may result in warnings for safe code.
  
!      '-Wstringop-overflow=4'
!           The '-Wstringop-overflow=4' option uses type-three Object Size
            Checking to determine the sizes of destination objects.  At
            this setting the option warns about overflowing any data
            members, and when the destination is one of several objects it
            uses the size of the largest of them to decide whether to
!           issue a warning.  Similarly to '-Wstringop-overflow=3' this
            setting of the option may result in warnings for benign code.
  
! '-Wno-stringop-overread'
!      Warn for calls to string manipulation functions such as 'memchr',
!      or 'strcpy' that are determined to read past the end of the source
       sequence.
  
!      Option '-Wstringop-overread' is enabled by default.
  
! '-Wno-stringop-truncation'
       Do not warn for calls to bounded string manipulation functions such
!      as 'strncat', 'strncpy', and 'stpncpy' that may either truncate the
       copied string or leave the destination unchanged.
  
!      In the following example, the call to 'strncat' specifies a bound
       that is less than the length of the source string.  As a result,
       the copy of the source will be truncated and so the call is
!      diagnosed.  To avoid the warning use 'bufsize - strlen (buf) - 1)'
       as the bound.
  
            void append (char *buf, size_t bufsize)
--- 7218,7255 ----
            they may point to arrays containing unknown numbers of
            elements.  This is the default setting of the option.
  
!      ‘-Wstringop-overflow=3’
!           The ‘-Wstringop-overflow=3’ option uses type-two Object Size
            Checking to determine the sizes of destination objects.  At
            this setting the option warns about overflowing the smallest
            object or data member.  This is the most restrictive setting
            of the option that may result in warnings for safe code.
  
!      ‘-Wstringop-overflow=4’
!           The ‘-Wstringop-overflow=4’ option uses type-three Object Size
            Checking to determine the sizes of destination objects.  At
            this setting the option warns about overflowing any data
            members, and when the destination is one of several objects it
            uses the size of the largest of them to decide whether to
!           issue a warning.  Similarly to ‘-Wstringop-overflow=3’ this
            setting of the option may result in warnings for benign code.
  
! ‘-Wno-stringop-overread’
!      Warn for calls to string manipulation functions such as ‘memchr’,
!      or ‘strcpy’ that are determined to read past the end of the source
       sequence.
  
!      Option ‘-Wstringop-overread’ is enabled by default.
  
! ‘-Wno-stringop-truncation’
       Do not warn for calls to bounded string manipulation functions such
!      as ‘strncat’, ‘strncpy’, and ‘stpncpy’ that may either truncate the
       copied string or leave the destination unchanged.
  
!      In the following example, the call to ‘strncat’ specifies a bound
       that is less than the length of the source string.  As a result,
       the copy of the source will be truncated and so the call is
!      diagnosed.  To avoid the warning use ‘bufsize - strlen (buf) - 1)’
       as the bound.
  
            void append (char *buf, size_t bufsize)
*************** warnings, in some cases it may also caus
*** 7253,7264 ****
              strncat (buf, ".txt", 3);
            }
  
!      As another example, the following call to 'strncpy' results in
!      copying to 'd' just the characters preceding the terminating NUL,
       without appending the NUL to the end.  Assuming the result of
!      'strncpy' is necessarily a NUL-terminated string is a common
       mistake, and so the call is diagnosed.  To avoid the warning when
!      the result is not expected to be NUL-terminated, call 'memcpy'
       instead.
  
            void copy (char *d, const char *s)
--- 7257,7268 ----
              strncat (buf, ".txt", 3);
            }
  
!      As another example, the following call to ‘strncpy’ results in
!      copying to ‘d’ just the characters preceding the terminating NUL,
       without appending the NUL to the end.  Assuming the result of
!      ‘strncpy’ is necessarily a NUL-terminated string is a common
       mistake, and so the call is diagnosed.  To avoid the warning when
!      the result is not expected to be NUL-terminated, call ‘memcpy’
       instead.
  
            void copy (char *d, const char *s)
*************** warnings, in some cases it may also caus
*** 7266,7277 ****
              strncpy (d, s, strlen (s));
            }
  
!      In the following example, the call to 'strncpy' specifies the size
       of the destination buffer as the bound.  If the length of the
       source string is equal to or greater than this size the result of
       the copy will not be NUL-terminated.  Therefore, the call is also
!      diagnosed.  To avoid the warning, specify 'sizeof buf - 1' as the
!      bound and set the last element of the buffer to 'NUL'.
  
            void copy (const char *s)
            {
--- 7270,7281 ----
              strncpy (d, s, strlen (s));
            }
  
!      In the following example, the call to ‘strncpy’ specifies the size
       of the destination buffer as the bound.  If the length of the
       source string is equal to or greater than this size the result of
       the copy will not be NUL-terminated.  Therefore, the call is also
!      diagnosed.  To avoid the warning, specify ‘sizeof buf - 1’ as the
!      bound and set the last element of the buffer to ‘NUL’.
  
            void copy (const char *s)
            {
*************** warnings, in some cases it may also caus
*** 7281,7299 ****
            }
  
       In situations where a character array is intended to store a
!      sequence of bytes with no terminating 'NUL' such an array may be
!      annotated with attribute 'nonstring' to avoid this warning.  Such
       arrays, however, are not suitable arguments to functions that
!      expect 'NUL'-terminated strings.  To help detect accidental misuses
       of such arrays GCC issues warnings unless it can prove that the use
       is safe.  *Note Common Variable Attributes::.
  
! '-Wstrict-flex-arrays'
       Warn about inproper usages of flexible array members according to
!      the LEVEL of the 'strict_flex_array (LEVEL)' attribute attached to
       the trailing array field of a structure if it's available,
       otherwise according to the LEVEL of the option
!      '-fstrict-flex-arrays=LEVEL'.
  
       This option is effective only when LEVEL is bigger than 0.
       Otherwise, it will be ignored with a warning.
--- 7285,7303 ----
            }
  
       In situations where a character array is intended to store a
!      sequence of bytes with no terminating ‘NUL’ such an array may be
!      annotated with attribute ‘nonstring’ to avoid this warning.  Such
       arrays, however, are not suitable arguments to functions that
!      expect ‘NUL’-terminated strings.  To help detect accidental misuses
       of such arrays GCC issues warnings unless it can prove that the use
       is safe.  *Note Common Variable Attributes::.
  
! ‘-Wstrict-flex-arrays’
       Warn about inproper usages of flexible array members according to
!      the LEVEL of the ‘strict_flex_array (LEVEL)’ attribute attached to
       the trailing array field of a structure if it's available,
       otherwise according to the LEVEL of the option
!      ‘-fstrict-flex-arrays=LEVEL’.
  
       This option is effective only when LEVEL is bigger than 0.
       Otherwise, it will be ignored with a warning.
*************** warnings, in some cases it may also caus
*** 7310,7403 ****
       issued for a trailing zero-length array reference of a structure if
       the array is referenced as a flexible array member.
  
! '-Wsuggest-attribute=[pure|const|noreturn|format|cold|malloc]'
       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'
!      '-Wmissing-noreturn'
!      '-Wsuggest-attribute=malloc'
  
            Warn about functions that might be candidates for attributes
!           'pure', 'const' or 'noreturn' or 'malloc'.  The compiler only
            warns for functions visible in other compilation units or (in
!           the case of 'pure' and 'const') if it cannot prove that the
            function returns normally.  A function returns normally if it
            doesn't contain an infinite loop or return abnormally by
!           throwing, calling 'abort' or trapping.  This analysis requires
!           option '-fipa-pure-const', which is enabled by default at '-O'
            and higher.  Higher optimization levels improve the accuracy
            of the analysis.
  
!      '-Wsuggest-attribute=format'
!      '-Wmissing-format-attribute'
  
            Warn about function pointers that might be candidates for
!           'format' attributes.  Note these are only possible candidates,
            not absolute ones.  GCC guesses that function pointers with
!           'format' attributes that are used in assignment,
            initialization, parameter passing or return statements should
!           have a corresponding 'format' attribute in the resulting type.
            I.e. the left-hand side of the assignment or initialization,
            the type of the parameter variable, or the return type of the
!           containing function respectively should also have a 'format'
            attribute to avoid the warning.
  
            GCC also warns about function definitions that might be
!           candidates for 'format' attributes.  Again, these are only
!           possible candidates.  GCC guesses that 'format' attributes
            might be appropriate for any function that calls a function
!           like 'vprintf' or 'vscanf', but this might not always be the
!           case, and some functions for which 'format' attributes are
            appropriate may not be detected.
  
!      '-Wsuggest-attribute=cold'
  
!           Warn about functions that might be candidates for 'cold'
            attribute.  This is based on static detection and generally
            only warns about functions which always leads to a call to
!           another 'cold' function such as wrappers of C++ 'throw' or
!           fatal error reporting functions leading to 'abort'.
  
! '-Walloc-zero'
       Warn about calls to allocation functions decorated with attribute
!      'alloc_size' that specify zero bytes, including those to the
!      built-in forms of the functions 'aligned_alloc', 'alloca',
!      'calloc', 'malloc', and 'realloc'.  Because the behavior of these
       functions when called with a zero size differs among
!      implementations (and in the case of 'realloc' has been deprecated)
       relying on it may result in subtle portability bugs and should be
       avoided.
  
! '-Walloc-size-larger-than=BYTE-SIZE'
!      Warn about calls to functions decorated with attribute 'alloc_size'
       that attempt to allocate objects larger than the specified number
       of bytes, or where the result of the size computation in an integer
       type with infinite precision would exceed the value of
!      'PTRDIFF_MAX' on the target.
!      '-Walloc-size-larger-than=''PTRDIFF_MAX' is enabled by default.
       Warnings controlled by the option can be disabled either by
!      specifying BYTE-SIZE of 'SIZE_MAX' or more or by
!      '-Wno-alloc-size-larger-than'.  *Note Function Attributes::.
  
! '-Wno-alloc-size-larger-than'
!      Disable '-Walloc-size-larger-than=' warnings.  The option is
!      equivalent to '-Walloc-size-larger-than=''SIZE_MAX' or larger.
  
! '-Walloca'
!      This option warns on all uses of 'alloca' in the source.
  
! '-Walloca-larger-than=BYTE-SIZE'
!      This option warns on calls to 'alloca' with an integer argument
       whose value is either zero, or that is not bounded by a controlling
       predicate that limits its value to at most BYTE-SIZE.  It also
!      warns for calls to 'alloca' where the bound value is unknown.
       Arguments of non-integer types are considered unbounded even if
       they appear to be constrained to the expected range.
  
!      For example, a bounded case of 'alloca' could be:
  
            void func (size_t n)
            {
--- 7314,7407 ----
       issued for a trailing zero-length array reference of a structure if
       the array is referenced as a flexible array member.
  
! ‘-Wsuggest-attribute=[pure|const|noreturn|format|cold|malloc]’
       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’
!      ‘-Wmissing-noreturn’
!      ‘-Wsuggest-attribute=malloc’
  
            Warn about functions that might be candidates for attributes
!           ‘pure’, ‘const’ or ‘noreturn’ or ‘malloc’.  The compiler only
            warns for functions visible in other compilation units or (in
!           the case of ‘pure’ and ‘const’) if it cannot prove that the
            function returns normally.  A function returns normally if it
            doesn't contain an infinite loop or return abnormally by
!           throwing, calling ‘abort’ or trapping.  This analysis requires
!           option ‘-fipa-pure-const’, which is enabled by default at ‘-O’
            and higher.  Higher optimization levels improve the accuracy
            of the analysis.
  
!      ‘-Wsuggest-attribute=format’
!      ‘-Wmissing-format-attribute’
  
            Warn about function pointers that might be candidates for
!           ‘format’ attributes.  Note these are only possible candidates,
            not absolute ones.  GCC guesses that function pointers with
!           ‘format’ attributes that are used in assignment,
            initialization, parameter passing or return statements should
!           have a corresponding ‘format’ attribute in the resulting type.
            I.e. the left-hand side of the assignment or initialization,
            the type of the parameter variable, or the return type of the
!           containing function respectively should also have a ‘format’
            attribute to avoid the warning.
  
            GCC also warns about function definitions that might be
!           candidates for ‘format’ attributes.  Again, these are only
!           possible candidates.  GCC guesses that ‘format’ attributes
            might be appropriate for any function that calls a function
!           like ‘vprintf’ or ‘vscanf’, but this might not always be the
!           case, and some functions for which ‘format’ attributes are
            appropriate may not be detected.
  
!      ‘-Wsuggest-attribute=cold’
  
!           Warn about functions that might be candidates for ‘cold’
            attribute.  This is based on static detection and generally
            only warns about functions which always leads to a call to
!           another ‘cold’ function such as wrappers of C++ ‘throw’ or
!           fatal error reporting functions leading to ‘abort’.
  
! ‘-Walloc-zero’
       Warn about calls to allocation functions decorated with attribute
!      ‘alloc_size’ that specify zero bytes, including those to the
!      built-in forms of the functions ‘aligned_alloc’, ‘alloca’,
!      ‘calloc’, ‘malloc’, and ‘realloc’.  Because the behavior of these
       functions when called with a zero size differs among
!      implementations (and in the case of ‘realloc’ has been deprecated)
       relying on it may result in subtle portability bugs and should be
       avoided.
  
! ‘-Walloc-size-larger-than=BYTE-SIZE’
!      Warn about calls to functions decorated with attribute ‘alloc_size’
       that attempt to allocate objects larger than the specified number
       of bytes, or where the result of the size computation in an integer
       type with infinite precision would exceed the value of
!      ‘PTRDIFF_MAX’ on the target.
!      ‘-Walloc-size-larger-than=’‘PTRDIFF_MAX’ is enabled by default.
       Warnings controlled by the option can be disabled either by
!      specifying BYTE-SIZE of ‘SIZE_MAX’ or more or by
!      ‘-Wno-alloc-size-larger-than’.  *Note Function Attributes::.
  
! ‘-Wno-alloc-size-larger-than’
!      Disable ‘-Walloc-size-larger-than=’ warnings.  The option is
!      equivalent to ‘-Walloc-size-larger-than=’‘SIZE_MAX’ or larger.
  
! ‘-Walloca’
!      This option warns on all uses of ‘alloca’ in the source.
  
! ‘-Walloca-larger-than=BYTE-SIZE’
!      This option warns on calls to ‘alloca’ with an integer argument
       whose value is either zero, or that is not bounded by a controlling
       predicate that limits its value to at most BYTE-SIZE.  It also
!      warns for calls to ‘alloca’ where the bound value is unknown.
       Arguments of non-integer types are considered unbounded even if
       they appear to be constrained to the expected range.
  
!      For example, a bounded case of ‘alloca’ could be:
  
            void func (size_t n)
            {
*************** warnings, in some cases it may also caus
*** 7409,7420 ****
              f (p);
            }
  
!      In the above example, passing '-Walloca-larger-than=1000' would not
!      issue a warning because the call to 'alloca' is known to be at most
!      1000 bytes.  However, if '-Walloca-larger-than=500' were passed,
       the compiler would emit a warning.
  
!      Unbounded uses, on the other hand, are uses of 'alloca' with no
       controlling predicate constraining its integer argument.  For
       example:
  
--- 7413,7424 ----
              f (p);
            }
  
!      In the above example, passing ‘-Walloca-larger-than=1000’ would not
!      issue a warning because the call to ‘alloca’ is known to be at most
!      1000 bytes.  However, if ‘-Walloca-larger-than=500’ were passed,
       the compiler would emit a warning.
  
!      Unbounded uses, on the other hand, are uses of ‘alloca’ with no
       controlling predicate constraining its integer argument.  For
       example:
  
*************** warnings, in some cases it may also caus
*** 7424,7430 ****
              f (p);
            }
  
!      If '-Walloca-larger-than=500' were passed, the above would trigger
       a warning, but this time because of the lack of bounds checking.
  
       Note, that even seemingly correct code involving signed integers
--- 7428,7434 ----
              f (p);
            }
  
!      If ‘-Walloca-larger-than=500’ were passed, the above would trigger
       a warning, but this time because of the lack of bounds checking.
  
       Note, that even seemingly correct code involving signed integers
*************** warnings, in some cases it may also caus
*** 7440,7464 ****
            }
  
       In the above example, N could be negative, causing a larger than
!      expected argument to be implicitly cast into the 'alloca' call.
  
!      This option also warns when 'alloca' is used in a loop.
  
!      '-Walloca-larger-than=''PTRDIFF_MAX' is enabled by default but is
!      usually only effective when '-ftree-vrp' is active (default for
!      '-O2' and above).
  
!      See also '-Wvla-larger-than=''byte-size'.
  
! '-Wno-alloca-larger-than'
!      Disable '-Walloca-larger-than=' warnings.  The option is equivalent
!      to '-Walloca-larger-than=''SIZE_MAX' or larger.
  
! '-Warith-conversion'
       Do warn about implicit conversions from arithmetic operations even
       when conversion of the operands to the same type cannot change
!      their values.  This affects warnings from '-Wconversion',
!      '-Wfloat-conversion', and '-Wsign-conversion'.
  
            void f (char c, int i)
            {
--- 7444,7468 ----
            }
  
       In the above example, N could be negative, causing a larger than
!      expected argument to be implicitly cast into the ‘alloca’ call.
  
!      This option also warns when ‘alloca’ is used in a loop.
  
!      ‘-Walloca-larger-than=’‘PTRDIFF_MAX’ is enabled by default but is
!      usually only effective when ‘-ftree-vrp’ is active (default for
!      ‘-O2’ and above).
  
!      See also ‘-Wvla-larger-than=’‘byte-size’.
  
! ‘-Wno-alloca-larger-than’
!      Disable ‘-Walloca-larger-than=’ warnings.  The option is equivalent
!      to ‘-Walloca-larger-than=’‘SIZE_MAX’ or larger.
  
! ‘-Warith-conversion’
       Do warn about implicit conversions from arithmetic operations even
       when conversion of the operands to the same type cannot change
!      their values.  This affects warnings from ‘-Wconversion’,
!      ‘-Wfloat-conversion’, and ‘-Wsign-conversion’.
  
            void f (char c, int i)
            {
*************** warnings, in some cases it may also caus
*** 7466,7488 ****
              c = c + 1; // only warns with -Warith-conversion
            }
  
! '-Warray-bounds'
! '-Warray-bounds=N'
       Warn about out of bounds subscripts or offsets into arrays.  This
!      warning is enabled by '-Wall'.  It is more effective when
!      '-ftree-vrp' is active (the default for '-O2' and above) but a
       subset of instances are issued even without optimization.
  
       By default, the trailing array of a structure will be treated as a
!      flexible array member by '-Warray-bounds' or '-Warray-bounds=N' if
       it is declared as either a flexible array member per C99 standard
!      onwards ('[]'), a GCC zero-length array extension ('[0]'), or an
!      one-element array ('[1]').  As a result, out of bounds subscripts
       or offsets into zero-length arrays or one-element arrays are not
       warned by default.
  
!      You can add the option '-fstrict-flex-arrays' or
!      '-fstrict-flex-arrays=LEVEL' to control how this option treat
       trailing array of a structure as a flexible array member:
  
       when LEVEL<=1, no change to the default behavior.
--- 7470,7492 ----
              c = c + 1; // only warns with -Warith-conversion
            }
  
! ‘-Warray-bounds’
! ‘-Warray-bounds=N’
       Warn about out of bounds subscripts or offsets into arrays.  This
!      warning is enabled by ‘-Wall’.  It is more effective when
!      ‘-ftree-vrp’ is active (the default for ‘-O2’ and above) but a
       subset of instances are issued even without optimization.
  
       By default, the trailing array of a structure will be treated as a
!      flexible array member by ‘-Warray-bounds’ or ‘-Warray-bounds=N’ if
       it is declared as either a flexible array member per C99 standard
!      onwards (‘[]’), a GCC zero-length array extension (‘[0]’), or an
!      one-element array (‘[1]’).  As a result, out of bounds subscripts
       or offsets into zero-length arrays or one-element arrays are not
       warned by default.
  
!      You can add the option ‘-fstrict-flex-arrays’ or
!      ‘-fstrict-flex-arrays=LEVEL’ to control how this option treat
       trailing array of a structure as a flexible array member:
  
       when LEVEL<=1, no change to the default behavior.
*************** warnings, in some cases it may also caus
*** 7494,7511 ****
       issued for out of bounds subscripts or offsets into zero-length
       arrays.
  
!      '-Warray-bounds=1'
!           This is the default warning level of '-Warray-bounds' and is
!           enabled by '-Wall'; higher levels are not, and must be
            explicitly requested.
  
!      '-Warray-bounds=2'
            This warning level also warns about the intermediate results
            of pointer arithmetic that may yield out of bounds values.
            This warning level may give a larger number of false positives
            and is deactivated by default.
  
! '-Warray-compare'
       Warn about equality and relational comparisons between two operands
       of array type.  This comparison was deprecated in C++20.  For
       example:
--- 7498,7515 ----
       issued for out of bounds subscripts or offsets into zero-length
       arrays.
  
!      ‘-Warray-bounds=1’
!           This is the default warning level of ‘-Warray-bounds’ and is
!           enabled by ‘-Wall’; higher levels are not, and must be
            explicitly requested.
  
!      ‘-Warray-bounds=2’
            This warning level also warns about the intermediate results
            of pointer arithmetic that may yield out of bounds values.
            This warning level may give a larger number of false positives
            and is deactivated by default.
  
! ‘-Warray-compare’
       Warn about equality and relational comparisons between two operands
       of array type.  This comparison was deprecated in C++20.  For
       example:
*************** warnings, in some cases it may also caus
*** 7514,7527 ****
            int arr2[5];
            bool same = arr1 == arr2;
  
!      '-Warray-compare' is enabled by '-Wall'.
  
! '-Warray-parameter'
! '-Warray-parameter=N'
       Warn about redeclarations of functions involving arguments of array
       or pointer types of inconsistent kinds or forms, and enable the
       detection of out-of-bounds accesses to such parameters by warnings
!      such as '-Warray-bounds'.
  
       If the first function declaration uses the array form the bound
       specified in the array is assumed to be the minimum number of
--- 7518,7531 ----
            int arr2[5];
            bool same = arr1 == arr2;
  
!      ‘-Warray-compare’ is enabled by ‘-Wall’.
  
! ‘-Warray-parameter’
! ‘-Warray-parameter=N’
       Warn about redeclarations of functions involving arguments of array
       or pointer types of inconsistent kinds or forms, and enable the
       detection of out-of-bounds accesses to such parameters by warnings
!      such as ‘-Warray-bounds’.
  
       If the first function declaration uses the array form the bound
       specified in the array is assumed to be the minimum number of
*************** warnings, in some cases it may also caus
*** 7529,7540 ****
       maximum number of elements accessed by it.  Failing to provide
       arguments of sufficient size or accessing more than the maximum
       number of elements may be diagnosed by warnings such as
!      '-Warray-bounds'.  At level 1 the warning diagnoses inconsistencies
!      involving array parameters declared using the 'T[static N]' form.
  
       For example, the warning triggers for the following redeclarations
       because the first one allows an array of any size to be passed to
!      'f' while the second one with the keyword 'static' specifies that
       the array argument must have at least four elements.
  
            void f (int[static 4]);
--- 7533,7544 ----
       maximum number of elements accessed by it.  Failing to provide
       arguments of sufficient size or accessing more than the maximum
       number of elements may be diagnosed by warnings such as
!      ‘-Warray-bounds’.  At level 1 the warning diagnoses inconsistencies
!      involving array parameters declared using the ‘T[static N]’ form.
  
       For example, the warning triggers for the following redeclarations
       because the first one allows an array of any size to be passed to
!      ‘f’ while the second one with the keyword ‘static’ specifies that
       the array argument must have at least four elements.
  
            void f (int[static 4]);
*************** warnings, in some cases it may also caus
*** 7556,7599 ****
            void g (int[]);     // no warning
            void g (int[8]);    // warning (inconsistent array bound)
  
!      '-Warray-parameter=2' is included in '-Wall'.  The
!      '-Wvla-parameter' option triggers warnings for similar
       inconsistencies involving Variable Length Array arguments.
  
! '-Wattribute-alias=N'
! '-Wno-attribute-alias'
!      Warn about declarations using the 'alias' and similar attributes
       whose target is incompatible with the type of the alias.  *Note
       Declaring Attributes of Functions: Function Attributes.
  
!      '-Wattribute-alias=1'
!           The default warning level of the '-Wattribute-alias' option
            diagnoses incompatibilities between the type of the alias
            declaration and that of its target.  Such incompatibilities
            are typically indicative of bugs.
  
!      '-Wattribute-alias=2'
  
!           At this level '-Wattribute-alias' also diagnoses cases where
            the attributes of the alias declaration are more restrictive
            than the attributes applied to its target.  These mismatches
            can potentially result in incorrect code generation.  In other
            cases they may be benign and could be resolved simply by
            adding the missing attribute to the target.  For comparison,
!           see the '-Wmissing-attributes' option, which controls
            diagnostics when the alias declaration is less restrictive
            than the target, rather than more restrictive.
  
!           Attributes considered include 'alloc_align', 'alloc_size',
!           'cold', 'const', 'hot', 'leaf', 'malloc', 'nonnull',
!           'noreturn', 'nothrow', 'pure', 'returns_nonnull', and
!           'returns_twice'.
  
!      '-Wattribute-alias' is equivalent to '-Wattribute-alias=1'.  This
       is the default.  You can disable these warnings with either
!      '-Wno-attribute-alias' or '-Wattribute-alias=0'.
  
! '-Wbidi-chars=[none|unpaired|any|ucn]'
       Warn about possibly misleading UTF-8 bidirectional control
       characters in comments, string literals, character constants, and
       identifiers.  Such characters can change left-to-right writing
--- 7560,7603 ----
            void g (int[]);     // no warning
            void g (int[8]);    // warning (inconsistent array bound)
  
!      ‘-Warray-parameter=2’ is included in ‘-Wall’.  The
!      ‘-Wvla-parameter’ option triggers warnings for similar
       inconsistencies involving Variable Length Array arguments.
  
! ‘-Wattribute-alias=N’
! ‘-Wno-attribute-alias’
!      Warn about declarations using the ‘alias’ and similar attributes
       whose target is incompatible with the type of the alias.  *Note
       Declaring Attributes of Functions: Function Attributes.
  
!      ‘-Wattribute-alias=1’
!           The default warning level of the ‘-Wattribute-alias’ option
            diagnoses incompatibilities between the type of the alias
            declaration and that of its target.  Such incompatibilities
            are typically indicative of bugs.
  
!      ‘-Wattribute-alias=2’
  
!           At this level ‘-Wattribute-alias’ also diagnoses cases where
            the attributes of the alias declaration are more restrictive
            than the attributes applied to its target.  These mismatches
            can potentially result in incorrect code generation.  In other
            cases they may be benign and could be resolved simply by
            adding the missing attribute to the target.  For comparison,
!           see the ‘-Wmissing-attributes’ option, which controls
            diagnostics when the alias declaration is less restrictive
            than the target, rather than more restrictive.
  
!           Attributes considered include ‘alloc_align’, ‘alloc_size’,
!           ‘cold’, ‘const’, ‘hot’, ‘leaf’, ‘malloc’, ‘nonnull’,
!           ‘noreturn’, ‘nothrow’, ‘pure’, ‘returns_nonnull’, and
!           ‘returns_twice’.
  
!      ‘-Wattribute-alias’ is equivalent to ‘-Wattribute-alias=1’.  This
       is the default.  You can disable these warnings with either
!      ‘-Wno-attribute-alias’ or ‘-Wattribute-alias=0’.
  
! ‘-Wbidi-chars=[none|unpaired|any|ucn]’
       Warn about possibly misleading UTF-8 bidirectional control
       characters in comments, string literals, character constants, and
       identifiers.  Such characters can change left-to-right writing
*************** warnings, in some cases it may also caus
*** 7603,7630 ****
       commented out, whereas it in fact is.
  
       There are three levels of warning supported by GCC.  The default is
!      '-Wbidi-chars=unpaired', which warns about improperly terminated
!      bidi contexts.  '-Wbidi-chars=none' turns the warning off.
!      '-Wbidi-chars=any' warns about any use of bidirectional control
       characters.
  
       By default, this warning does not warn about UCNs.  It is, however,
       possible to turn on such checking by using
!      '-Wbidi-chars=unpaired,ucn' or '-Wbidi-chars=any,ucn'.  Using
!      '-Wbidi-chars=ucn' is valid, and is equivalent to
!      '-Wbidi-chars=unpaired,ucn', if no previous '-Wbidi-chars=any' was
       specified.
  
! '-Wbool-compare'
       Warn about boolean expression compared with an integer value
!      different from 'true'/'false'.  For instance, the following
       comparison is always false:
            int n = 5;
            ...
            if ((n > 1) == 2) { ... }
!      This warning is enabled by '-Wall'.
  
! '-Wbool-operation'
       Warn about suspicious operations on expressions of a boolean type.
       For instance, bitwise negation of a boolean is very likely a bug in
       the program.  For C, this warning also warns about incrementing or
--- 7607,7634 ----
       commented out, whereas it in fact is.
  
       There are three levels of warning supported by GCC.  The default is
!      ‘-Wbidi-chars=unpaired’, which warns about improperly terminated
!      bidi contexts.  ‘-Wbidi-chars=none’ turns the warning off.
!      ‘-Wbidi-chars=any’ warns about any use of bidirectional control
       characters.
  
       By default, this warning does not warn about UCNs.  It is, however,
       possible to turn on such checking by using
!      ‘-Wbidi-chars=unpaired,ucn’ or ‘-Wbidi-chars=any,ucn’.  Using
!      ‘-Wbidi-chars=ucn’ is valid, and is equivalent to
!      ‘-Wbidi-chars=unpaired,ucn’, if no previous ‘-Wbidi-chars=any’ was
       specified.
  
! ‘-Wbool-compare’
       Warn about boolean expression compared with an integer value
!      different from ‘true’/‘false’.  For instance, the following
       comparison is always false:
            int n = 5;
            ...
            if ((n > 1) == 2) { ... }
!      This warning is enabled by ‘-Wall’.
  
! ‘-Wbool-operation’
       Warn about suspicious operations on expressions of a boolean type.
       For instance, bitwise negation of a boolean is very likely a bug in
       the program.  For C, this warning also warns about incrementing or
*************** warnings, in some cases it may also caus
*** 7632,7640 ****
       decrementing a boolean is always invalid.  Incrementing a boolean
       is invalid in C++17, and deprecated otherwise.)
  
!      This warning is enabled by '-Wall'.
  
! '-Wduplicated-branches'
       Warn when an if-else has identical branches.  This warning detects
       cases like
            if (p != NULL)
--- 7636,7644 ----
       decrementing a boolean is always invalid.  Incrementing a boolean
       is invalid in C++17, and deprecated otherwise.)
  
!      This warning is enabled by ‘-Wall’.
  
! ‘-Wduplicated-branches’
       Warn when an if-else has identical branches.  This warning detects
       cases like
            if (p != NULL)
*************** warnings, in some cases it may also caus
*** 7645,7695 ****
       This warning also warn for conditional operators:
              int i = x ? *p : *p;
  
! '-Wduplicated-cond'
       Warn about duplicated conditions in an if-else-if chain.  For
       instance, warn for the following code:
            if (p->q != NULL) { ... }
            else if (p->q != NULL) { ... }
  
! '-Wframe-address'
!      Warn when the '__builtin_frame_address' or
!      '__builtin_return_address' is called with an argument greater than
       0.  Such calls may return indeterminate values or crash the
!      program.  The warning is included in '-Wall'.
  
! '-Wno-discarded-qualifiers (C and Objective-C only)'
       Do not warn if type qualifiers on pointers are being discarded.
!      Typically, the compiler warns if a 'const char *' variable is
!      passed to a function that takes a 'char *' parameter.  This option
       can be used to suppress such a warning.
  
! '-Wno-discarded-array-qualifiers (C and Objective-C only)'
       Do not warn if type qualifiers on arrays which are pointer targets
!      are being discarded.  Typically, the compiler warns if a 'const int
!      (*)[]' variable is passed to a function that takes a 'int (*)[]'
       parameter.  This option can be used to suppress such a warning.
  
! '-Wno-incompatible-pointer-types (C and Objective-C only)'
       Do not warn when there is a conversion between pointers that have
       incompatible types.  This warning is for cases not covered by
!      '-Wno-pointer-sign', which warns for pointer argument passing or
       assignment with different signedness.
  
! '-Wno-int-conversion (C and Objective-C only)'
       Do not warn about incompatible integer to pointer and pointer to
       integer conversions.  This warning is about implicit conversions;
!      for explicit conversions the warnings '-Wno-int-to-pointer-cast'
!      and '-Wno-pointer-to-int-cast' may be used.
  
! '-Wzero-length-bounds'
       Warn about accesses to elements of zero-length array members that
       might overlap other members of the same object.  Declaring interior
       zero-length arrays is discouraged because accesses to them are
       undefined.  *Note Zero Length::.
  
!      For example, the first two stores in function 'bad' are diagnosed
!      because the array elements overlap the subsequent members 'b' and
!      'c'.  The third store is diagnosed by '-Warray-bounds' because it
       is beyond the bounds of the enclosing object.
  
            struct X { int a[0]; int b, c; };
--- 7649,7699 ----
       This warning also warn for conditional operators:
              int i = x ? *p : *p;
  
! ‘-Wduplicated-cond’
       Warn about duplicated conditions in an if-else-if chain.  For
       instance, warn for the following code:
            if (p->q != NULL) { ... }
            else if (p->q != NULL) { ... }
  
! ‘-Wframe-address’
!      Warn when the ‘__builtin_frame_address’ or
!      ‘__builtin_return_address’ is called with an argument greater than
       0.  Such calls may return indeterminate values or crash the
!      program.  The warning is included in ‘-Wall’.
  
! ‘-Wno-discarded-qualifiers (C and Objective-C only)’
       Do not warn if type qualifiers on pointers are being discarded.
!      Typically, the compiler warns if a ‘const char *’ variable is
!      passed to a function that takes a ‘char *’ parameter.  This option
       can be used to suppress such a warning.
  
! ‘-Wno-discarded-array-qualifiers (C and Objective-C only)’
       Do not warn if type qualifiers on arrays which are pointer targets
!      are being discarded.  Typically, the compiler warns if a ‘const int
!      (*)[]’ variable is passed to a function that takes a ‘int (*)[]’
       parameter.  This option can be used to suppress such a warning.
  
! ‘-Wno-incompatible-pointer-types (C and Objective-C only)’
       Do not warn when there is a conversion between pointers that have
       incompatible types.  This warning is for cases not covered by
!      ‘-Wno-pointer-sign’, which warns for pointer argument passing or
       assignment with different signedness.
  
! ‘-Wno-int-conversion (C and Objective-C only)’
       Do not warn about incompatible integer to pointer and pointer to
       integer conversions.  This warning is about implicit conversions;
!      for explicit conversions the warnings ‘-Wno-int-to-pointer-cast’
!      and ‘-Wno-pointer-to-int-cast’ may be used.
  
! ‘-Wzero-length-bounds’
       Warn about accesses to elements of zero-length array members that
       might overlap other members of the same object.  Declaring interior
       zero-length arrays is discouraged because accesses to them are
       undefined.  *Note Zero Length::.
  
!      For example, the first two stores in function ‘bad’ are diagnosed
!      because the array elements overlap the subsequent members ‘b’ and
!      ‘c’.  The third store is diagnosed by ‘-Warray-bounds’ because it
       is beyond the bounds of the enclosing object.
  
            struct X { int a[0]; int b, c; };
*************** warnings, in some cases it may also caus
*** 7702,7726 ****
              x.a[2] = 2;   // -Warray-bounds
            }
  
!      Option '-Wzero-length-bounds' is enabled by '-Warray-bounds'.
  
! '-Wno-div-by-zero'
       Do not warn about compile-time integer division by zero.
       Floating-point division by zero is not warned about, as it can be a
       legitimate way of obtaining infinities and NaNs.
  
! '-Wsystem-headers'
       Print warning messages for constructs found in system header files.
       Warnings from system headers are normally suppressed, on the
       assumption that they usually do not indicate real problems and
       would only make the compiler output harder to read.  Using this
       command-line option tells GCC to emit warnings from system headers
!      as if they occurred in user code.  However, note that using '-Wall'
       in conjunction with this option does _not_ warn about unknown
!      pragmas in system headers--for that, '-Wunknown-pragmas' must also
       be used.
  
! '-Wtautological-compare'
       Warn if a self-comparison always evaluates to true or false.  This
       warning detects various mistakes such as:
            int i = 1;
--- 7706,7730 ----
              x.a[2] = 2;   // -Warray-bounds
            }
  
!      Option ‘-Wzero-length-bounds’ is enabled by ‘-Warray-bounds’.
  
! ‘-Wno-div-by-zero’
       Do not warn about compile-time integer division by zero.
       Floating-point division by zero is not warned about, as it can be a
       legitimate way of obtaining infinities and NaNs.
  
! ‘-Wsystem-headers’
       Print warning messages for constructs found in system header files.
       Warnings from system headers are normally suppressed, on the
       assumption that they usually do not indicate real problems and
       would only make the compiler output harder to read.  Using this
       command-line option tells GCC to emit warnings from system headers
!      as if they occurred in user code.  However, note that using ‘-Wall’
       in conjunction with this option does _not_ warn about unknown
!      pragmas in system headers--for that, ‘-Wunknown-pragmas’ must also
       be used.
  
! ‘-Wtautological-compare’
       Warn if a self-comparison always evaluates to true or false.  This
       warning detects various mistakes such as:
            int i = 1;
*************** warnings, in some cases it may also caus
*** 7732,7740 ****
            if ((a & 16) == 10) { ... }
       will always be false.
  
!      This warning is enabled by '-Wall'.
  
! '-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
--- 7736,7744 ----
            if ((a & 16) == 10) { ... }
       will always be false.
  
!      This warning is enabled by ‘-Wall’.
  
! ‘-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
*************** warnings, in some cases it may also caus
*** 7744,7750 ****
       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
--- 7748,7754 ----
       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
*************** warnings, in some cases it may also caus
*** 7759,7842 ****
       relational operators, so equality comparisons are probably
       mistaken.
  
! '-Wtraditional (C and Objective-C only)'
       Warn about certain constructs that behave differently in
       traditional and ISO C.  Also warn about ISO C constructs that have
       no traditional C equivalent, and/or problematic constructs that
       should be avoided.
  
!         * Macro parameters that appear within string literals in the
            macro body.  In traditional C macro replacement takes place
            within string literals, but in ISO C it does not.
  
!         * In traditional C, some preprocessor directives did not exist.
            Traditional preprocessors only considered a line to be a
!           directive if the '#' appeared in column 1 on the line.
!           Therefore '-Wtraditional' warns about directives that
!           traditional C understands but ignores because the '#' does not
            appear as the first character on the line.  It also suggests
!           you hide directives like '#pragma' not understood by
            traditional C by indenting them.  Some traditional
!           implementations do not recognize '#elif', so this option
            suggests avoiding it altogether.
  
!         * A function-like macro that appears without arguments.
  
!         * The unary plus operator.
  
!         * The 'U' integer constant suffix, or the 'F' or 'L'
            floating-point constant suffixes.  (Traditional C does support
!           the 'L' suffix on integer constants.)  Note, these suffixes
            appear in macros defined in the system headers of most modern
!           systems, e.g. the '_MIN'/'_MAX' macros in ''.  Use
            of these macros in user code might normally lead to spurious
            warnings, however GCC's integrated preprocessor has enough
            context to avoid warning in these cases.
  
!         * A function declared external in one block and then used after
            the end of the block.
  
!         * A 'switch' statement has an operand of type 'long'.
  
!         * A non-'static' function declaration follows a 'static' one.
            This construct is not accepted by some traditional C
            compilers.
  
!         * The ISO type of an integer constant has a different width or
            signedness from its traditional type.  This warning is only
            issued if the base of the constant is ten.  I.e. hexadecimal
            or octal values, which typically represent bit patterns, are
            not warned about.
  
!         * Usage of ISO string concatenation is detected.
  
!         * Initialization of automatic aggregates.
  
!         * Identifier conflicts with labels.  Traditional C lacks a
            separate namespace for labels.
  
!         * Initialization of unions.  If the initializer is zero, the
            warning is omitted.  This is done under the assumption that
            the zero initializer in user code appears conditioned on e.g.
!           '__STDC__' to avoid missing initializer warnings and relies on
            default initialization to zero in the traditional C case.
  
!         * Conversions by prototypes between fixed/floating-point values
            and vice versa.  The absence of these prototypes when
            compiling with traditional C causes serious problems.  This is
            a subset of the possible conversion warnings; for the full set
!           use '-Wtraditional-conversion'.
  
!         * Use of ISO C style function definitions.  This warning
            intentionally is _not_ issued for prototype declarations or
            variadic functions because these ISO C features appear in your
            code when using libiberty's traditional C compatibility
!           macros, 'PARAMS' and 'VPARAMS'.  This warning is also bypassed
            for nested functions because that feature is already a GCC
            extension and thus not relevant to traditional C
            compatibility.
  
! '-Wtraditional-conversion (C and Objective-C only)'
       Warn if a prototype causes a type conversion that is different from
       what would happen to the same argument in the absence of a
       prototype.  This includes conversions of fixed point to floating
--- 7763,7846 ----
       relational operators, so equality comparisons are probably
       mistaken.
  
! ‘-Wtraditional (C and Objective-C only)’
       Warn about certain constructs that behave differently in
       traditional and ISO C.  Also warn about ISO C constructs that have
       no traditional C equivalent, and/or problematic constructs that
       should be avoided.
  
!         • Macro parameters that appear within string literals in the
            macro body.  In traditional C macro replacement takes place
            within string literals, but in ISO C it does not.
  
!         • In traditional C, some preprocessor directives did not exist.
            Traditional preprocessors only considered a line to be a
!           directive if the ‘#’ appeared in column 1 on the line.
!           Therefore ‘-Wtraditional’ warns about directives that
!           traditional C understands but ignores because the ‘#’ does not
            appear as the first character on the line.  It also suggests
!           you hide directives like ‘#pragma’ not understood by
            traditional C by indenting them.  Some traditional
!           implementations do not recognize ‘#elif’, so this option
            suggests avoiding it altogether.
  
!         • A function-like macro that appears without arguments.
  
!         • The unary plus operator.
  
!         • The ‘U’ integer constant suffix, or the ‘F’ or ‘L’
            floating-point constant suffixes.  (Traditional C does support
!           the ‘L’ suffix on integer constants.)  Note, these suffixes
            appear in macros defined in the system headers of most modern
!           systems, e.g. the ‘_MIN’/‘_MAX’ macros in ‘’.  Use
            of these macros in user code might normally lead to spurious
            warnings, however GCC's integrated preprocessor has enough
            context to avoid warning in these cases.
  
!         • A function declared external in one block and then used after
            the end of the block.
  
!         • A ‘switch’ statement has an operand of type ‘long’.
  
!         • A non-‘static’ function declaration follows a ‘static’ one.
            This construct is not accepted by some traditional C
            compilers.
  
!         • The ISO type of an integer constant has a different width or
            signedness from its traditional type.  This warning is only
            issued if the base of the constant is ten.  I.e. hexadecimal
            or octal values, which typically represent bit patterns, are
            not warned about.
  
!         • Usage of ISO string concatenation is detected.
  
!         • Initialization of automatic aggregates.
  
!         • Identifier conflicts with labels.  Traditional C lacks a
            separate namespace for labels.
  
!         • Initialization of unions.  If the initializer is zero, the
            warning is omitted.  This is done under the assumption that
            the zero initializer in user code appears conditioned on e.g.
!           ‘__STDC__’ to avoid missing initializer warnings and relies on
            default initialization to zero in the traditional C case.
  
!         • Conversions by prototypes between fixed/floating-point values
            and vice versa.  The absence of these prototypes when
            compiling with traditional C causes serious problems.  This is
            a subset of the possible conversion warnings; for the full set
!           use ‘-Wtraditional-conversion’.
  
!         • Use of ISO C style function definitions.  This warning
            intentionally is _not_ issued for prototype declarations or
            variadic functions because these ISO C features appear in your
            code when using libiberty's traditional C compatibility
!           macros, ‘PARAMS’ and ‘VPARAMS’.  This warning is also bypassed
            for nested functions because that feature is already a GCC
            extension and thus not relevant to traditional C
            compatibility.
  
! ‘-Wtraditional-conversion (C and Objective-C only)’
       Warn if a prototype causes a type conversion that is different from
       what would happen to the same argument in the absence of a
       prototype.  This includes conversions of fixed point to floating
*************** warnings, in some cases it may also caus
*** 7844,7856 ****
       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.  *Note
       Mixed Labels and Declarations::.
  
! '-Wshadow'
       Warn whenever a local variable or type declaration shadows another
       variable, parameter, type, class member (in C++), or instance
       variable (in Objective-C) or whenever a built-in function is
--- 7848,7860 ----
       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.  *Note
       Mixed Labels and Declarations::.
  
! ‘-Wshadow’
       Warn whenever a local variable or type declaration shadows another
       variable, parameter, type, class member (in C++), or instance
       variable (in Objective-C) or whenever a built-in function is
*************** warnings, in some cases it may also caus
*** 7858,7884 ****
       shadows an explicit typedef, but not if it shadows a
       struct/class/enum.  If this warning is enabled, it includes also
       all instances of local shadowing.  This means that
!      '-Wno-shadow=local' and '-Wno-shadow=compatible-local' are ignored
!      when '-Wshadow' is used.  Same as '-Wshadow=global'.
  
! '-Wno-shadow-ivar (Objective-C only)'
       Do not warn whenever a local variable shadows an instance variable
       in an Objective-C method.
  
! '-Wshadow=global'
!      Warn for any shadowing.  Same as '-Wshadow'.
  
! '-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:
  
--- 7862,7888 ----
       shadows an explicit typedef, but not if it shadows a
       struct/class/enum.  If this warning is enabled, it includes also
       all instances of local shadowing.  This means that
!      ‘-Wno-shadow=local’ and ‘-Wno-shadow=compatible-local’ are ignored
!      when ‘-Wshadow’ is used.  Same as ‘-Wshadow=global’.
  
! ‘-Wno-shadow-ivar (Objective-C only)’
       Do not warn whenever a local variable shadows an instance variable
       in an Objective-C method.
  
! ‘-Wshadow=global’
!      Warn for any shadowing.  Same as ‘-Wshadow’.
  
! ‘-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:
  
*************** warnings, in some cases it may also caus
*** 7891,7947 ****
              ...
            }
  
!      Since the two variable 'i' in the example above have incompatible
!      types, enabling only '-Wshadow=compatible-local' does not emit a
       warning.  Because their types are incompatible, if a programmer
       accidentally uses one in place of the other, type checking is
       expected to catch that and emit an error or warning.  Use of this
!      flag instead of '-Wshadow=local' can possibly reduce the number of
       warnings triggered by intentional shadowing.  Note that this also
!      means that shadowing 'const char *i' by 'char *i' does not emit a
       warning.
  
!      This warning is also enabled by '-Wshadow=local'.
  
! '-Wlarger-than=BYTE-SIZE'
       Warn whenever an object is defined whose size exceeds BYTE-SIZE.
!      '-Wlarger-than=''PTRDIFF_MAX' is enabled by default.  Warnings
       controlled by the option can be disabled either by specifying
!      BYTE-SIZE of 'SIZE_MAX' or more or by '-Wno-larger-than'.
  
!      Also warn for calls to bounded functions such as 'memchr' or
!      'strnlen' that specify a bound greater than the largest possible
!      object, which is 'PTRDIFF_MAX' bytes by default.  These warnings
!      can only be disabled by '-Wno-larger-than'.
  
! '-Wno-larger-than'
!      Disable '-Wlarger-than=' warnings.  The option is equivalent to
!      '-Wlarger-than=''SIZE_MAX' or larger.
  
! '-Wframe-larger-than=BYTE-SIZE'
       Warn if the size of a function frame exceeds BYTE-SIZE.  The
       computation done to determine the stack frame size is approximate
       and not conservative.  The actual requirements may be somewhat
       greater than BYTE-SIZE 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.
!      '-Wframe-larger-than=''PTRDIFF_MAX' is enabled by default.
       Warnings controlled by the option can be disabled either by
!      specifying BYTE-SIZE of 'SIZE_MAX' or more or by
!      '-Wno-frame-larger-than'.
  
! '-Wno-frame-larger-than'
!      Disable '-Wframe-larger-than=' warnings.  The option is equivalent
!      to '-Wframe-larger-than=''SIZE_MAX' or larger.
  
! '-Wfree-nonheap-object'
       Warn when attempting to deallocate an object that was either not
       allocated on the heap, or by using a pointer that was not returned
       from a prior call to the corresponding allocation function.  For
!      example, because the call to 'stpcpy' returns a pointer to the
       terminating nul character and not to the beginning of the object,
!      the call to 'free' below is diagnosed.
  
            void f (char *p)
            {
--- 7895,7951 ----
              ...
            }
  
!      Since the two variable ‘i’ in the example above have incompatible
!      types, enabling only ‘-Wshadow=compatible-local’ does not emit a
       warning.  Because their types are incompatible, if a programmer
       accidentally uses one in place of the other, type checking is
       expected to catch that and emit an error or warning.  Use of this
!      flag instead of ‘-Wshadow=local’ can possibly reduce the number of
       warnings triggered by intentional shadowing.  Note that this also
!      means that shadowing ‘const char *i’ by ‘char *i’ does not emit a
       warning.
  
!      This warning is also enabled by ‘-Wshadow=local’.
  
! ‘-Wlarger-than=BYTE-SIZE’
       Warn whenever an object is defined whose size exceeds BYTE-SIZE.
!      ‘-Wlarger-than=’‘PTRDIFF_MAX’ is enabled by default.  Warnings
       controlled by the option can be disabled either by specifying
!      BYTE-SIZE of ‘SIZE_MAX’ or more or by ‘-Wno-larger-than’.
  
!      Also warn for calls to bounded functions such as ‘memchr’ or
!      ‘strnlen’ that specify a bound greater than the largest possible
!      object, which is ‘PTRDIFF_MAX’ bytes by default.  These warnings
!      can only be disabled by ‘-Wno-larger-than’.
  
! ‘-Wno-larger-than’
!      Disable ‘-Wlarger-than=’ warnings.  The option is equivalent to
!      ‘-Wlarger-than=’‘SIZE_MAX’ or larger.
  
! ‘-Wframe-larger-than=BYTE-SIZE’
       Warn if the size of a function frame exceeds BYTE-SIZE.  The
       computation done to determine the stack frame size is approximate
       and not conservative.  The actual requirements may be somewhat
       greater than BYTE-SIZE 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.
!      ‘-Wframe-larger-than=’‘PTRDIFF_MAX’ is enabled by default.
       Warnings controlled by the option can be disabled either by
!      specifying BYTE-SIZE of ‘SIZE_MAX’ or more or by
!      ‘-Wno-frame-larger-than’.
  
! ‘-Wno-frame-larger-than’
!      Disable ‘-Wframe-larger-than=’ warnings.  The option is equivalent
!      to ‘-Wframe-larger-than=’‘SIZE_MAX’ or larger.
  
! ‘-Wfree-nonheap-object’
       Warn when attempting to deallocate an object that was either not
       allocated on the heap, or by using a pointer that was not returned
       from a prior call to the corresponding allocation function.  For
!      example, because the call to ‘stpcpy’ returns a pointer to the
       terminating nul character and not to the beginning of the object,
!      the call to ‘free’ below is diagnosed.
  
            void f (char *p)
            {
*************** warnings, in some cases it may also caus
*** 7950,8005 ****
              free (p);   // warning
            }
  
!      '-Wfree-nonheap-object' is included in '-Wall'.
  
! '-Wstack-usage=BYTE-SIZE'
       Warn if the stack usage of a function might exceed BYTE-SIZE.  The
       computation done to determine the stack usage is conservative.  Any
!      space allocated via 'alloca', variable-length arrays, or related
       constructs is included by the compiler when determining whether or
       not to issue a warning.
  
!      The message is in keeping with the output of '-fstack-usage'.
  
!         * If the stack usage is fully static but exceeds the specified
            amount, it's:
  
                   warning: stack usage is 1120 bytes
!         * If the stack usage is (partly) dynamic but bounded, it's:
  
                   warning: stack usage might be 1648 bytes
!         * If the stack usage is (partly) dynamic and not bounded, it's:
  
                   warning: stack usage might be unbounded
  
!      '-Wstack-usage=''PTRDIFF_MAX' is enabled by default.  Warnings
       controlled by the option can be disabled either by specifying
!      BYTE-SIZE of 'SIZE_MAX' or more or by '-Wno-stack-usage'.
  
! '-Wno-stack-usage'
!      Disable '-Wstack-usage=' warnings.  The option is equivalent to
!      '-Wstack-usage=''SIZE_MAX' or larger.
  
! '-Wunsafe-loop-optimizations'
       Warn if the loop cannot be optimized because the compiler cannot
       assume anything on the bounds of the loop indices.  With
!      '-funsafe-loop-optimizations' warn if the compiler makes such
       assumptions.
  
! '-Wno-pedantic-ms-format (MinGW targets only)'
!      When used in combination with '-Wformat' and '-pedantic' without
       GNU extensions, this option disables the warnings about non-ISO
!      'printf' / 'scanf' format width specifiers 'I32', 'I64', and 'I'
       used on Windows targets, which depend on the MS runtime.
  
! '-Wpointer-arith'
       Warn about anything that depends on the "size of" a function type
!      or of 'void'.  GNU C assigns these types a size of 1, for
!      convenience in calculations with 'void *' pointers and pointers to
       functions.  In C++, warn also when an arithmetic operation involves
!      'NULL'.  This warning is also enabled by '-Wpedantic'.
  
! '-Wno-pointer-compare'
       Do not warn if a pointer is compared with a zero character
       constant.  This usually means that the pointer was meant to be
       dereferenced.  For example:
--- 7954,8009 ----
              free (p);   // warning
            }
  
!      ‘-Wfree-nonheap-object’ is included in ‘-Wall’.
  
! ‘-Wstack-usage=BYTE-SIZE’
       Warn if the stack usage of a function might exceed BYTE-SIZE.  The
       computation done to determine the stack usage is conservative.  Any
!      space allocated via ‘alloca’, variable-length arrays, or related
       constructs is included by the compiler when determining whether or
       not to issue a warning.
  
!      The message is in keeping with the output of ‘-fstack-usage’.
  
!         • If the stack usage is fully static but exceeds the specified
            amount, it's:
  
                   warning: stack usage is 1120 bytes
!         • If the stack usage is (partly) dynamic but bounded, it's:
  
                   warning: stack usage might be 1648 bytes
!         • If the stack usage is (partly) dynamic and not bounded, it's:
  
                   warning: stack usage might be unbounded
  
!      ‘-Wstack-usage=’‘PTRDIFF_MAX’ is enabled by default.  Warnings
       controlled by the option can be disabled either by specifying
!      BYTE-SIZE of ‘SIZE_MAX’ or more or by ‘-Wno-stack-usage’.
  
! ‘-Wno-stack-usage’
!      Disable ‘-Wstack-usage=’ warnings.  The option is equivalent to
!      ‘-Wstack-usage=’‘SIZE_MAX’ or larger.
  
! ‘-Wunsafe-loop-optimizations’
       Warn if the loop cannot be optimized because the compiler cannot
       assume anything on the bounds of the loop indices.  With
!      ‘-funsafe-loop-optimizations’ warn if the compiler makes such
       assumptions.
  
! ‘-Wno-pedantic-ms-format (MinGW targets only)’
!      When used in combination with ‘-Wformat’ and ‘-pedantic’ without
       GNU extensions, this option disables the warnings about non-ISO
!      ‘printf’ / ‘scanf’ format width specifiers ‘I32’, ‘I64’, and ‘I’
       used on Windows targets, which depend on the MS runtime.
  
! ‘-Wpointer-arith’
       Warn about anything that depends on the "size of" a function type
!      or of ‘void’.  GNU C assigns these types a size of 1, for
!      convenience in calculations with ‘void *’ pointers and pointers to
       functions.  In C++, warn also when an arithmetic operation involves
!      ‘NULL’.  This warning is also enabled by ‘-Wpedantic’.
  
! ‘-Wno-pointer-compare’
       Do not warn if a pointer is compared with a zero character
       constant.  This usually means that the pointer was meant to be
       dereferenced.  For example:
*************** warnings, in some cases it may also caus
*** 8012,8071 ****
  
       This warning is enabled by default.
  
! '-Wtsan'
       Warn about unsupported features in ThreadSanitizer.
  
!      ThreadSanitizer does not support 'std::atomic_thread_fence' and can
       report false positives.
  
       This warning is enabled by default.
  
! '-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'.
  
! '-Wabsolute-value (C and Objective-C only)'
       Warn for calls to standard functions that compute the absolute
       value of an argument when a more appropriate standard function is
!      available.  For example, calling 'abs(3.14)' triggers the warning
       because the appropriate function to call to compute the absolute
!      value of a double argument is 'fabs'.  The option also triggers
       warnings when the argument in a call to such a function has an
       unsigned type.  This warning can be suppressed with an explicit
!      type cast and it is also enabled by '-Wextra'.
  
! '-Wcomment'
! '-Wcomments'
!      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'.
  
! '-Wtrigraphs'
       Warn if any trigraphs are encountered that might change the meaning
       of the program.  Trigraphs within comments are not warned about,
       except those that would form escaped newlines.
  
!      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'.
  
! '-Wundef'
!      Warn if an undefined identifier is evaluated in an '#if' directive.
       Such identifiers are replaced with zero.
  
! '-Wexpansion-to-defined'
!      Warn whenever 'defined' is encountered in the expansion of a macro
!      (including the case where the macro is expanded by an '#if'
       directive).  Such usage is not portable.  This warning is also
!      enabled by '-Wpedantic' and '-Wextra'.
  
! '-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 also warns if the macro has not been used
       at the time it is redefined or undefined.
  
--- 8016,8075 ----
  
       This warning is enabled by default.
  
! ‘-Wtsan’
       Warn about unsupported features in ThreadSanitizer.
  
!      ThreadSanitizer does not support ‘std::atomic_thread_fence’ and can
       report false positives.
  
       This warning is enabled by default.
  
! ‘-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’.
  
! ‘-Wabsolute-value (C and Objective-C only)’
       Warn for calls to standard functions that compute the absolute
       value of an argument when a more appropriate standard function is
!      available.  For example, calling ‘abs(3.14)’ triggers the warning
       because the appropriate function to call to compute the absolute
!      value of a double argument is ‘fabs’.  The option also triggers
       warnings when the argument in a call to such a function has an
       unsigned type.  This warning can be suppressed with an explicit
!      type cast and it is also enabled by ‘-Wextra’.
  
! ‘-Wcomment’
! ‘-Wcomments’
!      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’.
  
! ‘-Wtrigraphs’
       Warn if any trigraphs are encountered that might change the meaning
       of the program.  Trigraphs within comments are not warned about,
       except those that would form escaped newlines.
  
!      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’.
  
! ‘-Wundef’
!      Warn if an undefined identifier is evaluated in an ‘#if’ directive.
       Such identifiers are replaced with zero.
  
! ‘-Wexpansion-to-defined’
!      Warn whenever ‘defined’ is encountered in the expansion of a macro
!      (including the case where the macro is expanded by an ‘#if’
       directive).  Such usage is not portable.  This warning is also
!      enabled by ‘-Wpedantic’ and ‘-Wextra’.
  
! ‘-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 also warns if the macro has not been used
       at the time it is redefined or undefined.
  
*************** warnings, in some cases it may also caus
*** 8082,8089 ****
            #if defined the_macro_causing_the_warning
            #endif
  
! '-Wno-endif-labels'
!      Do not warn whenever an '#else' or an '#endif' are followed by
       text.  This sometimes happens in older programs with code of the
       form
  
--- 8086,8093 ----
            #if defined the_macro_causing_the_warning
            #endif
  
! ‘-Wno-endif-labels’
!      Do not warn whenever an ‘#else’ or an ‘#endif’ are followed by
       text.  This sometimes happens in older programs with code of the
       form
  
*************** warnings, in some cases it may also caus
*** 8093,8184 ****
            ...
            #endif FOO
  
!      The second and third 'FOO' should be in comments.  This warning is
       on by default.
  
! '-Wbad-function-cast (C and Objective-C only)'
       Warn when a function call is cast to a non-matching type.  For
       example, warn if a call to a function returning an integer type is
       cast to a pointer type.
  
! '-Wc90-c99-compat (C and Objective-C only)'
       Warn about features not present in ISO C90, but present in ISO C99.
!      For instance, warn about use of variable length arrays, 'long long'
!      type, 'bool' type, compound literals, designated initializers, and
       so on.  This option is independent of the standards mode.  Warnings
!      are disabled in the expression that follows '__extension__'.
  
! '-Wc99-c11-compat (C and Objective-C only)'
       Warn about features not present in ISO C99, but present in ISO C11.
       For instance, warn about use of anonymous structures and unions,
!      '_Atomic' type qualifier, '_Thread_local' storage-class specifier,
!      '_Alignas' specifier, 'Alignof' operator, '_Generic' keyword, and
       so on.  This option is independent of the standards mode.  Warnings
!      are disabled in the expression that follows '__extension__'.
  
! '-Wc11-c2x-compat (C and Objective-C only)'
       Warn about features not present in ISO C11, but present in ISO C2X.
!      For instance, warn about omitting the string in '_Static_assert',
!      use of '[[]]' syntax for attributes, use of decimal floating-point
       types, and so on.  This option is independent of the standards
       mode.  Warnings are disabled in the expression that follows
!      '__extension__'.
  
! '-Wc++-compat (C and Objective-C only)'
       Warn about ISO C constructs that are outside of the common subset
       of ISO C and ISO C++, e.g. request for implicit conversion from
!      'void *' to a pointer to non-'void' type.
  
! '-Wc++11-compat (C++ and Objective-C++ only)'
       Warn about C++ constructs whose meaning differs between ISO C++
       1998 and ISO C++ 2011, e.g., identifiers in ISO C++ 1998 that are
!      keywords in ISO C++ 2011.  This warning turns on '-Wnarrowing' and
!      is enabled by '-Wall'.
  
! '-Wc++14-compat (C++ and Objective-C++ only)'
       Warn about C++ constructs whose meaning differs between ISO C++
!      2011 and ISO C++ 2014.  This warning is enabled by '-Wall'.
  
! '-Wc++17-compat (C++ and Objective-C++ only)'
       Warn about C++ constructs whose meaning differs between ISO C++
!      2014 and ISO C++ 2017.  This warning is enabled by '-Wall'.
  
! '-Wc++20-compat (C++ and Objective-C++ only)'
       Warn about C++ constructs whose meaning differs between ISO C++
!      2017 and ISO C++ 2020.  This warning is enabled by '-Wall'.
  
! '-Wno-c++11-extensions (C++ and Objective-C++ only)'
       Do not warn about C++11 constructs in code being compiled using an
       older C++ standard.  Even without this option, some C++11
!      constructs will only be diagnosed if '-Wpedantic' is used.
  
! '-Wno-c++14-extensions (C++ and Objective-C++ only)'
       Do not warn about C++14 constructs in code being compiled using an
       older C++ standard.  Even without this option, some C++14
!      constructs will only be diagnosed if '-Wpedantic' is used.
  
! '-Wno-c++17-extensions (C++ and Objective-C++ only)'
       Do not warn about C++17 constructs in code being compiled using an
       older C++ standard.  Even without this option, some C++17
!      constructs will only be diagnosed if '-Wpedantic' is used.
  
! '-Wno-c++20-extensions (C++ and Objective-C++ only)'
       Do not warn about C++20 constructs in code being compiled using an
       older C++ standard.  Even without this option, some C++20
!      constructs will only be diagnosed if '-Wpedantic' is used.
  
! '-Wno-c++23-extensions (C++ and Objective-C++ only)'
       Do not warn about C++23 constructs in code being compiled using an
       older C++ standard.  Even without this option, some C++23
!      constructs will only be diagnosed if '-Wpedantic' is used.
  
! '-Wcast-qual'
       Warn whenever a pointer is cast so as to remove a type qualifier
!      from the target type.  For example, warn if a 'const char *' is
!      cast to an ordinary 'char *'.
  
       Also warn when making a cast that introduces a type qualifier in an
!      unsafe way.  For example, casting 'char **' to 'const char **' is
       unsafe, as in this example:
  
              /* p is char ** value.  */
--- 8097,8188 ----
            ...
            #endif FOO
  
!      The second and third ‘FOO’ should be in comments.  This warning is
       on by default.
  
! ‘-Wbad-function-cast (C and Objective-C only)’
       Warn when a function call is cast to a non-matching type.  For
       example, warn if a call to a function returning an integer type is
       cast to a pointer type.
  
! ‘-Wc90-c99-compat (C and Objective-C only)’
       Warn about features not present in ISO C90, but present in ISO C99.
!      For instance, warn about use of variable length arrays, ‘long long’
!      type, ‘bool’ type, compound literals, designated initializers, and
       so on.  This option is independent of the standards mode.  Warnings
!      are disabled in the expression that follows ‘__extension__’.
  
! ‘-Wc99-c11-compat (C and Objective-C only)’
       Warn about features not present in ISO C99, but present in ISO C11.
       For instance, warn about use of anonymous structures and unions,
!      ‘_Atomic’ type qualifier, ‘_Thread_local’ storage-class specifier,
!      ‘_Alignas’ specifier, ‘Alignof’ operator, ‘_Generic’ keyword, and
       so on.  This option is independent of the standards mode.  Warnings
!      are disabled in the expression that follows ‘__extension__’.
  
! ‘-Wc11-c2x-compat (C and Objective-C only)’
       Warn about features not present in ISO C11, but present in ISO C2X.
!      For instance, warn about omitting the string in ‘_Static_assert’,
!      use of ‘[[]]’ syntax for attributes, use of decimal floating-point
       types, and so on.  This option is independent of the standards
       mode.  Warnings are disabled in the expression that follows
!      ‘__extension__’.
  
! ‘-Wc++-compat (C and Objective-C only)’
       Warn about ISO C constructs that are outside of the common subset
       of ISO C and ISO C++, e.g. request for implicit conversion from
!      ‘void *’ to a pointer to non-‘void’ type.
  
! ‘-Wc++11-compat (C++ and Objective-C++ only)’
       Warn about C++ constructs whose meaning differs between ISO C++
       1998 and ISO C++ 2011, e.g., identifiers in ISO C++ 1998 that are
!      keywords in ISO C++ 2011.  This warning turns on ‘-Wnarrowing’ and
!      is enabled by ‘-Wall’.
  
! ‘-Wc++14-compat (C++ and Objective-C++ only)’
       Warn about C++ constructs whose meaning differs between ISO C++
!      2011 and ISO C++ 2014.  This warning is enabled by ‘-Wall’.
  
! ‘-Wc++17-compat (C++ and Objective-C++ only)’
       Warn about C++ constructs whose meaning differs between ISO C++
!      2014 and ISO C++ 2017.  This warning is enabled by ‘-Wall’.
  
! ‘-Wc++20-compat (C++ and Objective-C++ only)’
       Warn about C++ constructs whose meaning differs between ISO C++
!      2017 and ISO C++ 2020.  This warning is enabled by ‘-Wall’.
  
! ‘-Wno-c++11-extensions (C++ and Objective-C++ only)’
       Do not warn about C++11 constructs in code being compiled using an
       older C++ standard.  Even without this option, some C++11
!      constructs will only be diagnosed if ‘-Wpedantic’ is used.
  
! ‘-Wno-c++14-extensions (C++ and Objective-C++ only)’
       Do not warn about C++14 constructs in code being compiled using an
       older C++ standard.  Even without this option, some C++14
!      constructs will only be diagnosed if ‘-Wpedantic’ is used.
  
! ‘-Wno-c++17-extensions (C++ and Objective-C++ only)’
       Do not warn about C++17 constructs in code being compiled using an
       older C++ standard.  Even without this option, some C++17
!      constructs will only be diagnosed if ‘-Wpedantic’ is used.
  
! ‘-Wno-c++20-extensions (C++ and Objective-C++ only)’
       Do not warn about C++20 constructs in code being compiled using an
       older C++ standard.  Even without this option, some C++20
!      constructs will only be diagnosed if ‘-Wpedantic’ is used.
  
! ‘-Wno-c++23-extensions (C++ and Objective-C++ only)’
       Do not warn about C++23 constructs in code being compiled using an
       older C++ standard.  Even without this option, some C++23
!      constructs will only be diagnosed if ‘-Wpedantic’ is used.
  
! ‘-Wcast-qual’
       Warn whenever a pointer is cast so as to remove a type qualifier
!      from the target type.  For example, warn if a ‘const char *’ is
!      cast to an ordinary ‘char *’.
  
       Also warn when making a cast that introduces a type qualifier in an
!      unsafe way.  For example, casting ‘char **’ to ‘const char **’ is
       unsafe, as in this example:
  
              /* p is char ** value.  */
*************** warnings, in some cases it may also caus
*** 8188,8273 ****
              /* 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.
  
! '-Wcast-align=strict'
       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 *' regardless of the target machine.
  
! '-Wcast-function-type'
       Warn when a function pointer is cast to an incompatible function
       pointer.  In a cast involving function types with a variable
       argument list only the types of initial arguments that are provided
       are considered.  Any parameter of pointer-type matches any other
       pointer-type.  Any benign differences in integral types are
!      ignored, like 'int' vs. 'long' on ILP32 targets.  Likewise type
!      qualifiers are ignored.  The function type 'void (*) (void)' is
       special and matches everything, which can be used to suppress this
       warning.  In a cast involving pointer to member types this warning
       warns whenever the type cast is changing the pointer to member
!      type.  This warning is enabled by '-Wextra'.
  
! '-Wwrite-strings'
!      When compiling C, give string constants the type 'const
!      char[LENGTH]' so that copying the address of one into a non-'const'
!      'char *' pointer produces a warning.  These warnings help you find
       at compile time code that can try to write into a string constant,
!      but only if you have been very careful about using 'const' in
       declarations and prototypes.  Otherwise, it is just a nuisance.
!      This is why we did not make '-Wall' request these warnings.
  
       When compiling C++, warn about the deprecated conversion from
!      string literals to 'char *'.  This warning is enabled by default
       for C++ programs.
  
! '-Wclobbered'
!      Warn for variables that might be changed by 'longjmp' or 'vfork'.
!      This warning is also enabled by '-Wextra'.
  
! '-Wno-complain-wrong-lang'
       By default, language front ends complain when a command-line option
       is valid, but not applicable to that front end.  This may be
!      disabled with '-Wno-complain-wrong-lang', which is mostly useful
       when invoking a single compiler driver for multiple source files
       written in different languages, for example:
  
            $ g++ -fno-rtti a.cc b.f90
  
!      The driver 'g++' invokes the C++ front end to compile 'a.cc' and
!      the Fortran front end to compile 'b.f90'.  The latter front end
!      diagnoses 'f951: Warning: command-line option '-fno-rtti' is valid
!      for C++/D/ObjC++ but not for Fortran', which may be disabled with
!      '-Wno-complain-wrong-lang'.
  
! '-Wconversion'
       Warn for implicit conversions that may alter a value.  This
!      includes conversions between real and integer, like 'abs (x)' when
!      'x' is 'double'; conversions between signed and unsigned, like
!      'unsigned ui = -1'; and conversions to smaller types, like 'sqrtf
!      (M_PI)'.  Do not warn for explicit casts like 'abs ((int) x)' and
!      'ui = (unsigned) -1', or if the value is not changed by the
!      conversion like in 'abs (2.0)'.  Warnings about conversions between
       signed and unsigned integers can be disabled by using
!      '-Wno-sign-conversion'.
  
       For C++, also warn for confusing overload resolution for
       user-defined conversions; and conversions that never use a type
!      conversion operator: conversions to 'void', the same type, a base
       class or a reference to them.  Warnings about conversions between
       signed and unsigned integers are disabled by default in C++ unless
!      '-Wsign-conversion' is explicitly enabled.
  
       Warnings about conversion from arithmetic on a small type back to
!      that type are only given with '-Warith-conversion'.
  
! '-Wdangling-else'
!      Warn about constructions where there may be confusion to which 'if'
!      statement an 'else' branch belongs.  Here is an example of such a
       case:
  
            {
--- 8192,8277 ----
              /* 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.
  
! ‘-Wcast-align=strict’
       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 *’ regardless of the target machine.
  
! ‘-Wcast-function-type’
       Warn when a function pointer is cast to an incompatible function
       pointer.  In a cast involving function types with a variable
       argument list only the types of initial arguments that are provided
       are considered.  Any parameter of pointer-type matches any other
       pointer-type.  Any benign differences in integral types are
!      ignored, like ‘int’ vs. ‘long’ on ILP32 targets.  Likewise type
!      qualifiers are ignored.  The function type ‘void (*) (void)’ is
       special and matches everything, which can be used to suppress this
       warning.  In a cast involving pointer to member types this warning
       warns whenever the type cast is changing the pointer to member
!      type.  This warning is enabled by ‘-Wextra’.
  
! ‘-Wwrite-strings’
!      When compiling C, give string constants the type ‘const
!      char[LENGTH]’ so that copying the address of one into a non-‘const’
!      ‘char *’ pointer produces a warning.  These warnings help you find
       at compile time code that can try to write into a string constant,
!      but only if you have been very careful about using ‘const’ in
       declarations and prototypes.  Otherwise, it is just a nuisance.
!      This is why we did not make ‘-Wall’ request these warnings.
  
       When compiling C++, warn about the deprecated conversion from
!      string literals to ‘char *’.  This warning is enabled by default
       for C++ programs.
  
! ‘-Wclobbered’
!      Warn for variables that might be changed by ‘longjmp’ or ‘vfork’.
!      This warning is also enabled by ‘-Wextra’.
  
! ‘-Wno-complain-wrong-lang’
       By default, language front ends complain when a command-line option
       is valid, but not applicable to that front end.  This may be
!      disabled with ‘-Wno-complain-wrong-lang’, which is mostly useful
       when invoking a single compiler driver for multiple source files
       written in different languages, for example:
  
            $ g++ -fno-rtti a.cc b.f90
  
!      The driver ‘g++’ invokes the C++ front end to compile ‘a.cc’ and
!      the Fortran front end to compile ‘b.f90’.  The latter front end
!      diagnoses ‘f951: Warning: command-line option '-fno-rtti' is valid
!      for C++/D/ObjC++ but not for Fortran’, which may be disabled with
!      ‘-Wno-complain-wrong-lang’.
  
! ‘-Wconversion’
       Warn for implicit conversions that may alter a value.  This
!      includes conversions between real and integer, like ‘abs (x)’ when
!      ‘x’ is ‘double’; conversions between signed and unsigned, like
!      ‘unsigned ui = -1’; and conversions to smaller types, like ‘sqrtf
!      (M_PI)’.  Do not warn for explicit casts like ‘abs ((int) x)’ and
!      ‘ui = (unsigned) -1’, or if the value is not changed by the
!      conversion like in ‘abs (2.0)’.  Warnings about conversions between
       signed and unsigned integers can be disabled by using
!      ‘-Wno-sign-conversion’.
  
       For C++, also warn for confusing overload resolution for
       user-defined conversions; and conversions that never use a type
!      conversion operator: conversions to ‘void’, the same type, a base
       class or a reference to them.  Warnings about conversions between
       signed and unsigned integers are disabled by default in C++ unless
!      ‘-Wsign-conversion’ is explicitly enabled.
  
       Warnings about conversion from arithmetic on a small type back to
!      that type are only given with ‘-Warith-conversion’.
  
! ‘-Wdangling-else’
!      Warn about constructions where there may be confusion to which ‘if’
!      statement an ‘else’ branch belongs.  Here is an example of such a
       case:
  
            {
*************** warnings, in some cases it may also caus
*** 8278,8291 ****
                bar ();
            }
  
!      In C/C++, every 'else' branch belongs to the innermost possible
!      'if' statement, which in this example is 'if (b)'.  This is often
       not what the programmer expected, as illustrated in the above
       example by indentation the programmer chose.  When there is the
       potential for this confusion, GCC issues a warning when this flag
       is specified.  To eliminate the warning, add explicit braces around
!      the innermost 'if' statement so there is no way the 'else' can
!      belong to the enclosing 'if'.  The resulting code looks like this:
  
            {
              if (a)
--- 8282,8295 ----
                bar ();
            }
  
!      In C/C++, every ‘else’ branch belongs to the innermost possible
!      ‘if’ statement, which in this example is ‘if (b)’.  This is often
       not what the programmer expected, as illustrated in the above
       example by indentation the programmer chose.  When there is the
       potential for this confusion, GCC issues a warning when this flag
       is specified.  To eliminate the warning, add explicit braces around
!      the innermost ‘if’ statement so there is no way the ‘else’ can
!      belong to the enclosing ‘if’.  The resulting code looks like this:
  
            {
              if (a)
*************** warnings, in some cases it may also caus
*** 8297,8306 ****
                }
            }
  
!      This warning is enabled by '-Wparentheses'.
  
! '-Wdangling-pointer'
! '-Wdangling-pointer=N'
       Warn about uses of pointers (or C++ references) to objects with
       automatic storage duration after their lifetime has ended.  This
       includes local variables declared in nested blocks, compound
--- 8301,8310 ----
                }
            }
  
!      This warning is enabled by ‘-Wparentheses’.
  
! ‘-Wdangling-pointer’
! ‘-Wdangling-pointer=N’
       Warn about uses of pointers (or C++ references) to objects with
       automatic storage duration after their lifetime has ended.  This
       includes local variables declared in nested blocks, compound
*************** warnings, in some cases it may also caus
*** 8309,8315 ****
       warning is enabled at all optimization levels but may yield
       different results with optimization than without.
  
!      '-Wdangling-pointer=1'
            At level 1 the warning diagnoses only unconditional uses of
            dangling pointers.  For example
                 int f (int c1, int c2, x)
--- 8313,8319 ----
       warning is enabled at all optimization levels but may yield
       different results with optimization than without.
  
!      ‘-Wdangling-pointer=1’
            At level 1 the warning diagnoses only unconditional uses of
            dangling pointers.  For example
                 int f (int c1, int c2, x)
*************** warnings, in some cases it may also caus
*** 8319,8325 ****
                   return p ? *p : 'x';
                 }
            In the following function the store of the address of the
!           local variable 'x' in the escaped pointer '*p' also triggers
            the warning.
                 void g (int **p)
                 {
--- 8323,8329 ----
                   return p ? *p : 'x';
                 }
            In the following function the store of the address of the
!           local variable ‘x’ in the escaped pointer ‘*p’ also triggers
            the warning.
                 void g (int **p)
                 {
*************** warnings, in some cases it may also caus
*** 8328,8334 ****
                   *p = &x;
                 }
  
!      '-Wdangling-pointer=2'
            At level 2, in addition to unconditional uses the warning also
            diagnoses conditional uses of dangling pointers.
  
--- 8332,8338 ----
                   *p = &x;
                 }
  
!      ‘-Wdangling-pointer=2’
            At level 2, in addition to unconditional uses the warning also
            diagnoses conditional uses of dangling pointers.
  
*************** warnings, in some cases it may also caus
*** 8348,8379 ****
                   ...
                 }
  
!      '-Wdangling-pointer=2' is included in '-Wall'.
  
! '-Wdate-time'
!      Warn when macros '__TIME__', '__DATE__' or '__TIMESTAMP__' are
       encountered as they might prevent bit-wise-identical reproducible
       compilations.
  
! '-Wempty-body'
!      Warn if an empty body occurs in an 'if', 'else' or 'do while'
!      statement.  This warning is also enabled by '-Wextra'.
  
! '-Wno-endif-labels'
!      Do not warn about stray tokens after '#else' and '#endif'.
  
! '-Wenum-compare'
       Warn about a comparison between values of different enumerated
       types.  In C++ enumerated type mismatches in conditional
       expressions are also diagnosed and the warning is enabled by
!      default.  In C this warning is enabled by '-Wall'.
  
! '-Wenum-conversion'
       Warn when a value of enumerated type is implicitly converted to a
!      different enumerated type.  This warning is enabled by '-Wextra' in
       C.
  
! '-Wenum-int-mismatch (C and Objective-C only)'
       Warn about mismatches between an enumerated type and an integer
       type in declarations.  For example:
  
--- 8352,8383 ----
                   ...
                 }
  
!      ‘-Wdangling-pointer=2’ is included in ‘-Wall’.
  
! ‘-Wdate-time’
!      Warn when macros ‘__TIME__’, ‘__DATE__’ or ‘__TIMESTAMP__’ are
       encountered as they might prevent bit-wise-identical reproducible
       compilations.
  
! ‘-Wempty-body’
!      Warn if an empty body occurs in an ‘if’, ‘else’ or ‘do while’
!      statement.  This warning is also enabled by ‘-Wextra’.
  
! ‘-Wno-endif-labels’
!      Do not warn about stray tokens after ‘#else’ and ‘#endif’.
  
! ‘-Wenum-compare’
       Warn about a comparison between values of different enumerated
       types.  In C++ enumerated type mismatches in conditional
       expressions are also diagnosed and the warning is enabled by
!      default.  In C this warning is enabled by ‘-Wall’.
  
! ‘-Wenum-conversion’
       Warn when a value of enumerated type is implicitly converted to a
!      different enumerated type.  This warning is enabled by ‘-Wextra’ in
       C.
  
! ‘-Wenum-int-mismatch (C and Objective-C only)’
       Warn about mismatches between an enumerated type and an integer
       type in declarations.  For example:
  
*************** warnings, in some cases it may also caus
*** 8381,8427 ****
            int foo(void);
            enum E foo(void);
  
!      In C, an enumerated type is compatible with 'char', a signed
       integer type, or an unsigned integer type.  However, since the
       choice of the underlying type of an enumerated type is
       implementation-defined, such mismatches may cause portability
       issues.  In C++, such mismatches are an error.  In C, this warning
!      is enabled by '-Wall' and '-Wc++-compat'.
  
! '-Wjump-misses-init (C, Objective-C only)'
!      Warn if a 'goto' statement or a 'switch' statement jumps forward
       across the initialization of a variable, or jumps backward to a
       label after the variable has been initialized.  This only warns
       about variables that are initialized when they are declared.  This
       warning is only supported for C and Objective-C; in C++ this sort
       of branch is an error in any case.
  
!      '-Wjump-misses-init' is included in '-Wc++-compat'.  It can be
!      disabled with the '-Wno-jump-misses-init' option.
  
! '-Wsign-compare'
       Warn when a comparison between signed and unsigned values could
       produce an incorrect result when the signed value is converted to
!      unsigned.  In C++, this warning is also enabled by '-Wall'.  In C,
!      it is also enabled by '-Wextra'.
  
! '-Wsign-conversion'
       Warn for implicit conversions that may change the sign of an
       integer value, like assigning a signed integer expression to an
       unsigned integer variable.  An explicit cast silences the warning.
!      In C, this option is enabled also by '-Wconversion'.
  
! '-Wfloat-conversion'
       Warn for implicit conversions that reduce the precision of a real
       value.  This includes conversions from real to integer, and from
       higher precision real to lower precision real values.  This option
!      is also enabled by '-Wconversion'.
  
! '-Wno-scalar-storage-order'
       Do not warn on suspicious constructs involving reverse scalar
       storage order.
  
! '-Wsizeof-array-div'
       Warn about divisions of two sizeof operators when the first one is
       applied to an array and the divisor does not equal the size of the
       array element.  In such a case, the computation will not yield the
--- 8385,8431 ----
            int foo(void);
            enum E foo(void);
  
!      In C, an enumerated type is compatible with ‘char’, a signed
       integer type, or an unsigned integer type.  However, since the
       choice of the underlying type of an enumerated type is
       implementation-defined, such mismatches may cause portability
       issues.  In C++, such mismatches are an error.  In C, this warning
!      is enabled by ‘-Wall’ and ‘-Wc++-compat’.
  
! ‘-Wjump-misses-init (C, Objective-C only)’
!      Warn if a ‘goto’ statement or a ‘switch’ statement jumps forward
       across the initialization of a variable, or jumps backward to a
       label after the variable has been initialized.  This only warns
       about variables that are initialized when they are declared.  This
       warning is only supported for C and Objective-C; in C++ this sort
       of branch is an error in any case.
  
!      ‘-Wjump-misses-init’ is included in ‘-Wc++-compat’.  It can be
!      disabled with the ‘-Wno-jump-misses-init’ option.
  
! ‘-Wsign-compare’
       Warn when a comparison between signed and unsigned values could
       produce an incorrect result when the signed value is converted to
!      unsigned.  In C++, this warning is also enabled by ‘-Wall’.  In C,
!      it is also enabled by ‘-Wextra’.
  
! ‘-Wsign-conversion’
       Warn for implicit conversions that may change the sign of an
       integer value, like assigning a signed integer expression to an
       unsigned integer variable.  An explicit cast silences the warning.
!      In C, this option is enabled also by ‘-Wconversion’.
  
! ‘-Wfloat-conversion’
       Warn for implicit conversions that reduce the precision of a real
       value.  This includes conversions from real to integer, and from
       higher precision real to lower precision real values.  This option
!      is also enabled by ‘-Wconversion’.
  
! ‘-Wno-scalar-storage-order’
       Do not warn on suspicious constructs involving reverse scalar
       storage order.
  
! ‘-Wsizeof-array-div’
       Warn about divisions of two sizeof operators when the first one is
       applied to an array and the divisor does not equal the size of the
       array element.  In such a case, the computation will not yield the
*************** warnings, in some cases it may also caus
*** 8433,8458 ****
              return sizeof (arr) / sizeof (short);
            }
  
!      This warning is enabled by '-Wall'.
  
! '-Wsizeof-pointer-div'
       Warn for suspicious divisions of two sizeof expressions that divide
       the pointer size by the element size, which is the usual way to
       compute the array size but won't work out correctly with pointers.
!      This warning warns e.g. about 'sizeof (ptr) / sizeof (ptr[0])' if
!      'ptr' is not an array, but a pointer.  This warning is enabled by
!      '-Wall'.
  
! '-Wsizeof-pointer-memaccess'
       Warn for suspicious length parameters to certain string and memory
!      built-in functions if the argument uses 'sizeof'.  This warning
!      triggers for example for 'memset (ptr, 0, sizeof (ptr));' if 'ptr'
       is not an array, but a pointer, and suggests a possible fix, or
!      about 'memcpy (&foo, ptr, sizeof (&foo));'.
!      '-Wsizeof-pointer-memaccess' also warns about calls to bounded
!      string copy functions like 'strncat' or 'strncpy' that specify as
!      the bound a 'sizeof' expression of the source array.  For example,
!      in the following function the call to 'strncat' specifies the size
       of the source string as the bound.  That is almost certainly a
       mistake and so the call is diagnosed.
            void make_file (const char *name)
--- 8437,8462 ----
              return sizeof (arr) / sizeof (short);
            }
  
!      This warning is enabled by ‘-Wall’.
  
! ‘-Wsizeof-pointer-div’
       Warn for suspicious divisions of two sizeof expressions that divide
       the pointer size by the element size, which is the usual way to
       compute the array size but won't work out correctly with pointers.
!      This warning warns e.g. about ‘sizeof (ptr) / sizeof (ptr[0])’ if
!      ‘ptr’ is not an array, but a pointer.  This warning is enabled by
!      ‘-Wall’.
  
! ‘-Wsizeof-pointer-memaccess’
       Warn for suspicious length parameters to certain string and memory
!      built-in functions if the argument uses ‘sizeof’.  This warning
!      triggers for example for ‘memset (ptr, 0, sizeof (ptr));’ if ‘ptr’
       is not an array, but a pointer, and suggests a possible fix, or
!      about ‘memcpy (&foo, ptr, sizeof (&foo));’.
!      ‘-Wsizeof-pointer-memaccess’ also warns about calls to bounded
!      string copy functions like ‘strncat’ or ‘strncpy’ that specify as
!      the bound a ‘sizeof’ expression of the source array.  For example,
!      in the following function the call to ‘strncat’ specifies the size
       of the source string as the bound.  That is almost certainly a
       mistake and so the call is diagnosed.
            void make_file (const char *name)
*************** warnings, in some cases it may also caus
*** 8463,8495 ****
              ...
            }
  
!      The '-Wsizeof-pointer-memaccess' option is enabled by '-Wall'.
  
! '-Wno-sizeof-array-argument'
!      Do not warn when the 'sizeof' operator is applied to a parameter
       that is declared as an array in a function definition.  This
       warning is enabled by default for C and C++ programs.
  
! '-Wmemset-elt-size'
!      Warn for suspicious calls to the 'memset' built-in function, if the
       first argument references an array, and the third argument is a
       number equal to the number of elements, but not equal to the size
       of the array in memory.  This indicates that the user has omitted a
       multiplication by the element size.  This warning is enabled by
!      '-Wall'.
  
! '-Wmemset-transposed-args'
!      Warn for suspicious calls to the 'memset' built-in function where
       the second argument is not zero and the third argument is zero.
!      For example, the call 'memset (buf, sizeof buf, 0)' is diagnosed
!      because 'memset (buf, 0, sizeof buf)' was meant instead.  The
       diagnostic is only emitted if the third argument is a literal zero.
       Otherwise, if it is an expression that is folded to zero, or a cast
       of zero to some type, it is far less likely that the arguments have
       been mistakenly transposed and no warning is emitted.  This warning
!      is enabled by '-Wall'.
  
! '-Waddress'
       Warn about suspicious uses of address expressions.  These include
       comparing the address of a function or a declared object to the
       null pointer constant such as in
--- 8467,8499 ----
              ...
            }
  
!      The ‘-Wsizeof-pointer-memaccess’ option is enabled by ‘-Wall’.
  
! ‘-Wno-sizeof-array-argument’
!      Do not warn when the ‘sizeof’ operator is applied to a parameter
       that is declared as an array in a function definition.  This
       warning is enabled by default for C and C++ programs.
  
! ‘-Wmemset-elt-size’
!      Warn for suspicious calls to the ‘memset’ built-in function, if the
       first argument references an array, and the third argument is a
       number equal to the number of elements, but not equal to the size
       of the array in memory.  This indicates that the user has omitted a
       multiplication by the element size.  This warning is enabled by
!      ‘-Wall’.
  
! ‘-Wmemset-transposed-args’
!      Warn for suspicious calls to the ‘memset’ built-in function where
       the second argument is not zero and the third argument is zero.
!      For example, the call ‘memset (buf, sizeof buf, 0)’ is diagnosed
!      because ‘memset (buf, 0, sizeof buf)’ was meant instead.  The
       diagnostic is only emitted if the third argument is a literal zero.
       Otherwise, if it is an expression that is folded to zero, or a cast
       of zero to some type, it is far less likely that the arguments have
       been mistakenly transposed and no warning is emitted.  This warning
!      is enabled by ‘-Wall’.
  
! ‘-Waddress’
       Warn about suspicious uses of address expressions.  These include
       comparing the address of a function or a declared object to the
       null pointer constant such as in
*************** warnings, in some cases it may also caus
*** 8517,8534 ****
       indicate missing parentheses in a function call or a missing
       dereference in an array expression.  The subset of the warning for
       object pointers can be suppressed by casting the pointer operand to
!      an integer type such as 'intptr_t' or 'uintptr_t'.  Comparisons
       against string literals result in unspecified behavior and are not
!      portable, and suggest the intent was to call 'strcmp'.  The warning
       is suppressed if the suspicious expression is the result of macro
!      expansion.  '-Waddress' warning is enabled by '-Wall'.
  
! '-Wno-address-of-packed-member'
       Do not warn when the address of packed member of struct or union is
       taken, which usually results in an unaligned pointer value.  This
       is enabled by default.
  
! '-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.  Also warns when the operands of
--- 8521,8538 ----
       indicate missing parentheses in a function call or a missing
       dereference in an array expression.  The subset of the warning for
       object pointers can be suppressed by casting the pointer operand to
!      an integer type such as ‘intptr_t’ or ‘uintptr_t’.  Comparisons
       against string literals result in unspecified behavior and are not
!      portable, and suggest the intent was to call ‘strcmp’.  The warning
       is suppressed if the suspicious expression is the result of macro
!      expansion.  ‘-Waddress’ warning is enabled by ‘-Wall’.
  
! ‘-Wno-address-of-packed-member’
       Do not warn when the address of packed member of struct or union is
       taken, which usually results in an unaligned pointer value.  This
       is enabled by default.
  
! ‘-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.  Also warns when the operands of
*************** warnings, in some cases it may also caus
*** 8536,8542 ****
            extern int a;
            if (a < 0 && a < 0) { ... }
  
! '-Wlogical-not-parentheses'
       Warn about logical not used on the left hand side operand of a
       comparison.  This option does not warn if the right operand is
       considered to be a boolean expression.  Its purpose is to detect
--- 8540,8546 ----
            extern int a;
            if (a < 0 && a < 0) { ... }
  
! ‘-Wlogical-not-parentheses’
       Warn about logical not used on the left hand side operand of a
       comparison.  This option does not warn if the right operand is
       considered to be a boolean expression.  Its purpose is to detect
*************** warnings, in some cases it may also caus
*** 8549,8602 ****
       parentheses:
            if ((!a) > 1) { ... }
  
!      This warning is enabled by '-Wall'.
  
! '-Waggregate-return'
       Warn if any functions that return structures or unions are defined
       or called.  (In languages where you can return an array, this also
       elicits a warning.)
  
! '-Wno-aggressive-loop-optimizations'
       Warn if in a loop with constant number of iterations the compiler
       detects undefined behavior in some statement during one or more of
       the iterations.
  
! '-Wno-attributes'
!      Do not warn if an unexpected '__attribute__' is used, such as
       unrecognized attributes, function attributes applied to variables,
       etc.  This does not stop errors for incorrect use of supported
       attributes.
  
!      Additionally, using '-Wno-attributes=', it is possible to suppress
       warnings about unknown scoped attributes (in C++11 and C2X). For
!      example, '-Wno-attributes=vendor::attr' disables warning about the
       following declaration:
  
            [[vendor::attr]] void f();
  
       It is also possible to disable warning about all attributes in a
!      namespace using '-Wno-attributes=vendor::' which prevents warning
       about both of these declarations:
  
            [[vendor::safe]] void f();
            [[vendor::unsafe]] void f2();
  
!      Note that '-Wno-attributes=' does not imply '-Wno-attributes'.
  
! '-Wno-builtin-declaration-mismatch'
       Warn if a built-in function is declared with an incompatible
       signature or as a non-function, or when a built-in function
       declared with a type that does not include a prototype is called
       with arguments whose promoted types do not match those expected by
!      the function.  When '-Wextra' is specified, also warn when a
       built-in function that takes arguments is declared without a
!      prototype.  The '-Wbuiltin-declaration-mismatch' warning is enabled
       by default.  To avoid the warning include the appropriate header to
       bring the prototypes of built-in functions into scope.
  
!      For example, the call to 'memset' below is diagnosed by the warning
!      because the function expects a value of type 'size_t' as its
!      argument but the type of '32' is 'int'.  With '-Wextra', the
       declaration of the function is diagnosed as well.
            extern void* memset ();
            void f (void *d)
--- 8553,8606 ----
       parentheses:
            if ((!a) > 1) { ... }
  
!      This warning is enabled by ‘-Wall’.
  
! ‘-Waggregate-return’
       Warn if any functions that return structures or unions are defined
       or called.  (In languages where you can return an array, this also
       elicits a warning.)
  
! ‘-Wno-aggressive-loop-optimizations’
       Warn if in a loop with constant number of iterations the compiler
       detects undefined behavior in some statement during one or more of
       the iterations.
  
! ‘-Wno-attributes’
!      Do not warn if an unexpected ‘__attribute__’ is used, such as
       unrecognized attributes, function attributes applied to variables,
       etc.  This does not stop errors for incorrect use of supported
       attributes.
  
!      Additionally, using ‘-Wno-attributes=’, it is possible to suppress
       warnings about unknown scoped attributes (in C++11 and C2X). For
!      example, ‘-Wno-attributes=vendor::attr’ disables warning about the
       following declaration:
  
            [[vendor::attr]] void f();
  
       It is also possible to disable warning about all attributes in a
!      namespace using ‘-Wno-attributes=vendor::’ which prevents warning
       about both of these declarations:
  
            [[vendor::safe]] void f();
            [[vendor::unsafe]] void f2();
  
!      Note that ‘-Wno-attributes=’ does not imply ‘-Wno-attributes’.
  
! ‘-Wno-builtin-declaration-mismatch’
       Warn if a built-in function is declared with an incompatible
       signature or as a non-function, or when a built-in function
       declared with a type that does not include a prototype is called
       with arguments whose promoted types do not match those expected by
!      the function.  When ‘-Wextra’ is specified, also warn when a
       built-in function that takes arguments is declared without a
!      prototype.  The ‘-Wbuiltin-declaration-mismatch’ warning is enabled
       by default.  To avoid the warning include the appropriate header to
       bring the prototypes of built-in functions into scope.
  
!      For example, the call to ‘memset’ below is diagnosed by the warning
!      because the function expects a value of type ‘size_t’ as its
!      argument but the type of ‘32’ is ‘int’.  With ‘-Wextra’, the
       declaration of the function is diagnosed as well.
            extern void* memset ();
            void f (void *d)
*************** warnings, in some cases it may also caus
*** 8604,8642 ****
              memset (d, '\0', 32);
            }
  
! '-Wno-builtin-macro-redefined'
       Do not warn if certain built-in macros are redefined.  This
!      suppresses warnings for redefinition of '__TIMESTAMP__',
!      '__TIME__', '__DATE__', '__FILE__', and '__BASE_FILE__'.
  
! '-Wstrict-prototypes (C and Objective-C only)'
       Warn if a function is declared or defined without specifying the
       argument types.  (An old-style function definition is permitted
       without a warning if preceded by a declaration that specifies the
       argument types.)
  
! '-Wold-style-declaration (C and Objective-C only)'
       Warn for obsolescent usages, according to the C Standard, in a
       declaration.  For example, warn if storage-class specifiers like
!      'static' are not the first things in a declaration.  This warning
!      is also enabled by '-Wextra'.
  
! '-Wold-style-definition (C and Objective-C only)'
       Warn if an old-style function definition is used.  A warning is
       given even if there is a previous prototype.  A definition using
!      '()' is not considered an old-style definition in C2X mode, because
!      it is equivalent to '(void)' in that case, but is considered an
       old-style definition for older standards.
  
! '-Wmissing-parameter-type (C and Objective-C only)'
       A function parameter is declared without a type specifier in
       K&R-style functions:
  
            void foo(bar) { }
  
!      This warning is also enabled by '-Wextra'.
  
! '-Wmissing-prototypes (C and Objective-C only)'
       Warn if a global function is defined without a previous prototype
       declaration.  This warning is issued even if the definition itself
       provides a prototype.  Use this option to detect global functions
--- 8608,8646 ----
              memset (d, '\0', 32);
            }
  
! ‘-Wno-builtin-macro-redefined’
       Do not warn if certain built-in macros are redefined.  This
!      suppresses warnings for redefinition of ‘__TIMESTAMP__’,
!      ‘__TIME__’, ‘__DATE__’, ‘__FILE__’, and ‘__BASE_FILE__’.
  
! ‘-Wstrict-prototypes (C and Objective-C only)’
       Warn if a function is declared or defined without specifying the
       argument types.  (An old-style function definition is permitted
       without a warning if preceded by a declaration that specifies the
       argument types.)
  
! ‘-Wold-style-declaration (C and Objective-C only)’
       Warn for obsolescent usages, according to the C Standard, in a
       declaration.  For example, warn if storage-class specifiers like
!      ‘static’ are not the first things in a declaration.  This warning
!      is also enabled by ‘-Wextra’.
  
! ‘-Wold-style-definition (C and Objective-C only)’
       Warn if an old-style function definition is used.  A warning is
       given even if there is a previous prototype.  A definition using
!      ‘()’ is not considered an old-style definition in C2X mode, because
!      it is equivalent to ‘(void)’ in that case, but is considered an
       old-style definition for older standards.
  
! ‘-Wmissing-parameter-type (C and Objective-C only)’
       A function parameter is declared without a type specifier in
       K&R-style functions:
  
            void foo(bar) { }
  
!      This warning is also enabled by ‘-Wextra’.
  
! ‘-Wmissing-prototypes (C and Objective-C only)’
       Warn if a global function is defined without a previous prototype
       declaration.  This warning is issued even if the definition itself
       provides a prototype.  Use this option to detect global functions
*************** warnings, in some cases it may also caus
*** 8644,8664 ****
       This option is not valid for C++ because all function declarations
       provide prototypes and a non-matching declaration declares an
       overload rather than conflict with an earlier declaration.  Use
!      '-Wmissing-declarations' to detect missing declarations in C++.
  
! '-Wmissing-declarations'
       Warn if a global function is defined without a previous
       declaration.  Do so even if the definition itself provides a
       prototype.  Use this option to detect global functions that are not
       declared in header files.  In C, no warnings are issued for
       functions with previous non-prototype declarations; use
!      '-Wmissing-prototypes' to detect missing prototypes.  In C++, no
       warnings are issued for function templates, or for inline
       functions, or for functions in anonymous namespaces.
  
! '-Wmissing-field-initializers'
       Warn if a structure's initializer has some fields missing.  For
!      example, the following code causes such a warning, because 'x.h' is
       implicitly zero:
  
            struct s { int f, g, h; };
--- 8648,8668 ----
       This option is not valid for C++ because all function declarations
       provide prototypes and a non-matching declaration declares an
       overload rather than conflict with an earlier declaration.  Use
!      ‘-Wmissing-declarations’ to detect missing declarations in C++.
  
! ‘-Wmissing-declarations’
       Warn if a global function is defined without a previous
       declaration.  Do so even if the definition itself provides a
       prototype.  Use this option to detect global functions that are not
       declared in header files.  In C, no warnings are issued for
       functions with previous non-prototype declarations; use
!      ‘-Wmissing-prototypes’ to detect missing prototypes.  In C++, no
       warnings are issued for function templates, or for inline
       functions, or for functions in anonymous namespaces.
  
! ‘-Wmissing-field-initializers’
       Warn if a structure's initializer has some fields missing.  For
!      example, the following code causes such a warning, because ‘x.h’ is
       implicitly zero:
  
            struct s { int f, g, h; };
*************** warnings, in some cases it may also caus
*** 8671,8677 ****
            struct s x = { .f = 3, .g = 4 };
  
       In C this option does not warn about the universal zero initializer
!      '{ 0 }':
  
            struct s { int f, g, h; };
            struct s x = { 0 };
--- 8675,8681 ----
            struct s x = { .f = 3, .g = 4 };
  
       In C this option does not warn about the universal zero initializer
!      ‘{ 0 }’:
  
            struct s { int f, g, h; };
            struct s x = { 0 };
*************** warnings, in some cases it may also caus
*** 8682,8712 ****
            struct s { int f, g, h; };
            s x = { };
  
!      This warning is included in '-Wextra'.  To get other '-Wextra'
!      warnings without this one, use '-Wextra
!      -Wno-missing-field-initializers'.
  
! '-Wno-missing-requires'
  
       By default, the compiler warns about a concept-id appearing as a
       C++20 simple-requirement:
  
            bool satisfied = requires { C };
  
!      Here 'satisfied' will be true if 'C' is a valid expression,
       which it is for all T. Presumably the user meant to write
  
            bool satisfied = requires { requires C };
  
!      so 'satisfied' is only true if concept 'C' is satisfied for type
!      'T'.
  
!      This warning can be disabled with '-Wno-missing-requires'.
  
! '-Wno-missing-template-keyword'
  
       The member access tokens ., -> and :: must be followed by the
!      'template' keyword if the parent object is dependent and the member
       being named is a template.
  
            template 
--- 8686,8716 ----
            struct s { int f, g, h; };
            s x = { };
  
!      This warning is included in ‘-Wextra’.  To get other ‘-Wextra’
!      warnings without this one, use ‘-Wextra
!      -Wno-missing-field-initializers’.
  
! ‘-Wno-missing-requires’
  
       By default, the compiler warns about a concept-id appearing as a
       C++20 simple-requirement:
  
            bool satisfied = requires { C };
  
!      Here ‘satisfied’ will be true if ‘C’ is a valid expression,
       which it is for all T. Presumably the user meant to write
  
            bool satisfied = requires { requires C };
  
!      so ‘satisfied’ is only true if concept ‘C’ is satisfied for type
!      ‘T’.
  
!      This warning can be disabled with ‘-Wno-missing-requires’.
  
! ‘-Wno-missing-template-keyword’
  
       The member access tokens ., -> and :: must be followed by the
!      ‘template’ keyword if the parent object is dependent and the member
       being named is a template.
  
            template 
*************** warnings, in some cases it may also caus
*** 8729,8837 ****
              test = (t.m < N) > (0); // Same meaning, but not treated as a template.
            }
  
!      This warning can be disabled with '-Wno-missing-template-keyword'.
  
! '-Wno-multichar'
!      Do not warn if a multicharacter constant (''FOOF'') is used.
       Usually they indicate a typo in the user's code, as they have
       implementation-defined values, and should not be used in portable
       code.
  
! '-Wnormalized=[none|id|nfc|nfkc]'
       In ISO C and ISO C++, two identifiers are different if they are
       different sequences of characters.  However, sometimes when
       characters outside the basic ASCII character set are used, you can
       have two different character sequences that look the same.  To
       avoid confusion, the ISO 10646 standard sets out some
!      "normalization rules" which when applied ensure that two sequences
       that look the same are turned into the same sequence.  GCC can warn
       you if you are using identifiers that have not been normalized;
       this option controls that warning.
  
       There are four levels of warning supported by GCC.  The default is
!      '-Wnormalized=nfc', which warns about any identifier that is not in
!      the ISO 10646 "C" normalized form, "NFC". NFC is the recommended
!      form for most uses.  It is equivalent to '-Wnormalized'.
  
       Unfortunately, there are some characters allowed in identifiers by
       ISO C and ISO C++ that, when turned into NFC, are not allowed in
       identifiers.  That is, there's no way to use these symbols in
       portable ISO C or C++ and have all your identifiers in NFC.
!      '-Wnormalized=id' suppresses the warning for these characters.  It
       is hoped that future versions of the standards involved will
       correct this, which is why this option is not the default.
  
       You can switch the warning off for all characters by writing
!      '-Wnormalized=none' or '-Wno-normalized'.  You should only do this
       if you are using some other normalization scheme (like "D"),
       because otherwise you can easily create bugs that are literally
       impossible to see.
  
       Some characters in ISO 10646 have distinct meanings but look
       identical in some fonts or display methodologies, especially once
!      formatting has been applied.  For instance '\u207F', "SUPERSCRIPT
!      LATIN SMALL LETTER N", displays just like a regular 'n' that has
!      been placed in a superscript.  ISO 10646 defines the "NFKC"
       normalization scheme to convert all these into a standard form as
       well, and GCC warns if your code is not in NFKC if you use
!      '-Wnormalized=nfkc'.  This warning is comparable to warning about
       every identifier that contains the letter O because it might be
       confused with the digit 0, and so is not the default, but may be
       useful as a local coding convention if the programming environment
       cannot be fixed to display these characters distinctly.
  
! '-Wno-attribute-warning'
       Do not warn about usage of functions (*note Function Attributes::)
!      declared with 'warning' attribute.  By default, this warning is
!      enabled.  '-Wno-attribute-warning' can be used to disable the
!      warning or '-Wno-error=attribute-warning' can be used to disable
!      the error when compiled with '-Werror' flag.
  
! '-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.
  
! '-Wno-odr'
       Warn about One Definition Rule violations during link-time
       optimization.  Enabled by default.
  
! '-Wopenacc-parallelism'
       Warn about potentially suboptimal choices related to OpenACC
       parallelism.
  
! '-Wopenmp-simd'
       Warn if the vectorizer cost model overrides the OpenMP simd
!      directive set by user.  The '-fsimd-cost-model=unlimited' option
       can be used to relax the cost model.
  
! '-Woverride-init (C and Objective-C only)'
       Warn if an initialized field without side effects is overridden
       when using designated initializers (*note Designated Initializers:
       Designated Inits.).
  
!      This warning is included in '-Wextra'.  To get other '-Wextra'
!      warnings without this one, use '-Wextra -Wno-override-init'.
  
! '-Wno-override-init-side-effects (C and Objective-C only)'
       Do not warn if an initialized field with side effects is overridden
       when using designated initializers (*note Designated Initializers:
       Designated Inits.).  This warning is enabled by default.
  
! '-Wpacked'
       Warn if a structure is given the packed attribute, but the packed
       attribute has no effect on the layout or size of the structure.
       Such structures may be mis-aligned for little benefit.  For
!      instance, in this code, the variable 'f.x' in 'struct bar' is
!      misaligned even though 'struct bar' does not itself have the packed
       attribute:
  
            struct foo {
--- 8733,8841 ----
              test = (t.m < N) > (0); // Same meaning, but not treated as a template.
            }
  
!      This warning can be disabled with ‘-Wno-missing-template-keyword’.
  
! ‘-Wno-multichar’
!      Do not warn if a multicharacter constant (‘'FOOF'’) is used.
       Usually they indicate a typo in the user's code, as they have
       implementation-defined values, and should not be used in portable
       code.
  
! ‘-Wnormalized=[none|id|nfc|nfkc]’
       In ISO C and ISO C++, two identifiers are different if they are
       different sequences of characters.  However, sometimes when
       characters outside the basic ASCII character set are used, you can
       have two different character sequences that look the same.  To
       avoid confusion, the ISO 10646 standard sets out some
!      “normalization rules” which when applied ensure that two sequences
       that look the same are turned into the same sequence.  GCC can warn
       you if you are using identifiers that have not been normalized;
       this option controls that warning.
  
       There are four levels of warning supported by GCC.  The default is
!      ‘-Wnormalized=nfc’, which warns about any identifier that is not in
!      the ISO 10646 "C" normalized form, “NFC”. NFC is the recommended
!      form for most uses.  It is equivalent to ‘-Wnormalized’.
  
       Unfortunately, there are some characters allowed in identifiers by
       ISO C and ISO C++ that, when turned into NFC, are not allowed in
       identifiers.  That is, there's no way to use these symbols in
       portable ISO C or C++ and have all your identifiers in NFC.
!      ‘-Wnormalized=id’ suppresses the warning for these characters.  It
       is hoped that future versions of the standards involved will
       correct this, which is why this option is not the default.
  
       You can switch the warning off for all characters by writing
!      ‘-Wnormalized=none’ or ‘-Wno-normalized’.  You should only do this
       if you are using some other normalization scheme (like "D"),
       because otherwise you can easily create bugs that are literally
       impossible to see.
  
       Some characters in ISO 10646 have distinct meanings but look
       identical in some fonts or display methodologies, especially once
!      formatting has been applied.  For instance ‘\u207F’, "SUPERSCRIPT
!      LATIN SMALL LETTER N", displays just like a regular ‘n’ that has
!      been placed in a superscript.  ISO 10646 defines the “NFKC”
       normalization scheme to convert all these into a standard form as
       well, and GCC warns if your code is not in NFKC if you use
!      ‘-Wnormalized=nfkc’.  This warning is comparable to warning about
       every identifier that contains the letter O because it might be
       confused with the digit 0, and so is not the default, but may be
       useful as a local coding convention if the programming environment
       cannot be fixed to display these characters distinctly.
  
! ‘-Wno-attribute-warning’
       Do not warn about usage of functions (*note Function Attributes::)
!      declared with ‘warning’ attribute.  By default, this warning is
!      enabled.  ‘-Wno-attribute-warning’ can be used to disable the
!      warning or ‘-Wno-error=attribute-warning’ can be used to disable
!      the error when compiled with ‘-Werror’ flag.
  
! ‘-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.
  
! ‘-Wno-odr’
       Warn about One Definition Rule violations during link-time
       optimization.  Enabled by default.
  
! ‘-Wopenacc-parallelism’
       Warn about potentially suboptimal choices related to OpenACC
       parallelism.
  
! ‘-Wopenmp-simd’
       Warn if the vectorizer cost model overrides the OpenMP simd
!      directive set by user.  The ‘-fsimd-cost-model=unlimited’ option
       can be used to relax the cost model.
  
! ‘-Woverride-init (C and Objective-C only)’
       Warn if an initialized field without side effects is overridden
       when using designated initializers (*note Designated Initializers:
       Designated Inits.).
  
!      This warning is included in ‘-Wextra’.  To get other ‘-Wextra’
!      warnings without this one, use ‘-Wextra -Wno-override-init’.
  
! ‘-Wno-override-init-side-effects (C and Objective-C only)’
       Do not warn if an initialized field with side effects is overridden
       when using designated initializers (*note Designated Initializers:
       Designated Inits.).  This warning is enabled by default.
  
! ‘-Wpacked’
       Warn if a structure is given the packed attribute, but the packed
       attribute has no effect on the layout or size of the structure.
       Such structures may be mis-aligned for little benefit.  For
!      instance, in this code, the variable ‘f.x’ in ‘struct bar’ is
!      misaligned even though ‘struct bar’ does not itself have the packed
       attribute:
  
            struct foo {
*************** warnings, in some cases it may also caus
*** 8843,8855 ****
              struct foo f;
            };
  
! '-Wnopacked-bitfield-compat'
!      The 4.1, 4.2 and 4.3 series of GCC ignore the 'packed' attribute on
!      bit-fields of type 'char'.  This was 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
            {
--- 8847,8859 ----
              struct foo f;
            };
  
! ‘-Wnopacked-bitfield-compat’
!      The 4.1, 4.2 and 4.3 series of GCC ignore the ‘packed’ attribute on
!      bit-fields of type ‘char’.  This was 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
            {
*************** warnings, in some cases it may also caus
*** 8858,8897 ****
            } __attribute__ ((packed));
  
       This warning is enabled by default.  Use
!      '-Wno-packed-bitfield-compat' to disable this warning.
  
! '-Wpacked-not-aligned (C, C++, Objective-C and Objective-C++ only)'
       Warn if a structure field with explicitly specified alignment in a
       packed struct or union is misaligned.  For example, a warning will
!      be issued on 'struct S', like, 'warning: alignment 1 of 'struct S'
!      is less than 8', in this code:
  
            struct __attribute__ ((aligned (8))) S8 { char a[8]; };
            struct __attribute__ ((packed)) S {
              struct S8 s8;
            };
  
!      This warning is enabled by '-Wall'.
  
! '-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.
  
! '-Wrestrict'
!      Warn when an object referenced by a 'restrict'-qualified parameter
!      (or, in C++, a '__restrict'-qualified parameter) is aliased by
       another argument, or when copies between such objects overlap.  For
!      example, the call to the 'strcpy' function below attempts to
       truncate the string by replacing its initial characters with the
       last four.  However, because the call writes the terminating NUL
!      into 'a[4]', the copies overlap and the call is diagnosed.
  
            void foo (void)
            {
--- 8862,8901 ----
            } __attribute__ ((packed));
  
       This warning is enabled by default.  Use
!      ‘-Wno-packed-bitfield-compat’ to disable this warning.
  
! ‘-Wpacked-not-aligned (C, C++, Objective-C and Objective-C++ only)’
       Warn if a structure field with explicitly specified alignment in a
       packed struct or union is misaligned.  For example, a warning will
!      be issued on ‘struct S’, like, ‘warning: alignment 1 of 'struct S'
!      is less than 8’, in this code:
  
            struct __attribute__ ((aligned (8))) S8 { char a[8]; };
            struct __attribute__ ((packed)) S {
              struct S8 s8;
            };
  
!      This warning is enabled by ‘-Wall’.
  
! ‘-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.
  
! ‘-Wrestrict’
!      Warn when an object referenced by a ‘restrict’-qualified parameter
!      (or, in C++, a ‘__restrict’-qualified parameter) is aliased by
       another argument, or when copies between such objects overlap.  For
!      example, the call to the ‘strcpy’ function below attempts to
       truncate the string by replacing its initial characters with the
       last four.  However, because the call writes the terminating NUL
!      into ‘a[4]’, the copies overlap and the call is diagnosed.
  
            void foo (void)
            {
*************** warnings, in some cases it may also caus
*** 8899,8912 ****
              strcpy (a, a + 4);
              ...
            }
!      The '-Wrestrict' option detects some instances of simple overlap
!      even without optimization but works best at '-O2' and above.  It is
!      included in '-Wall'.
  
! '-Wnested-externs (C and Objective-C only)'
!      Warn if an 'extern' declaration is encountered within a function.
  
! '-Winline'
       Warn if a function that is declared as inline cannot be inlined.
       Even with this option, the compiler does not warn about failures to
       inline functions declared in system headers.
--- 8903,8916 ----
              strcpy (a, a + 4);
              ...
            }
!      The ‘-Wrestrict’ option detects some instances of simple overlap
!      even without optimization but works best at ‘-O2’ and above.  It is
!      included in ‘-Wall’.
  
! ‘-Wnested-externs (C and Objective-C only)’
!      Warn if an ‘extern’ declaration is encountered within a function.
  
! ‘-Winline’
       Warn if a function that is declared as inline cannot be inlined.
       Even with this option, the compiler does not warn about failures to
       inline functions declared in system headers.
*************** warnings, in some cases it may also caus
*** 8916,8928 ****
       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.
  
! '-Winterference-size'
       Warn about use of C++17
!      'std::hardware_destructive_interference_size' without specifying
!      its value with '--param destructive-interference-size'.  Also warn
       about questionable values for that option.
  
       This variable is intended to be used for controlling class layout,
--- 8920,8932 ----
       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.
  
! ‘-Winterference-size’
       Warn about use of C++17
!      ‘std::hardware_destructive_interference_size’ without specifying
!      its value with ‘--param destructive-interference-size’.  Also warn
       about questionable values for that option.
  
       This variable is intended to be used for controlling class layout,
*************** warnings, in some cases it may also caus
*** 8935,9048 ****
                std::atomic two;
            };
  
!      Here 'one' and 'two' are intended to be far enough apart that
       stores to one won't require accesses to the other to reload the
       cache line.
  
!      By default, '--param destructive-interference-size' and '--param
!      constructive-interference-size' are set based on the current
!      '-mtune' option, typically to the L1 cache line size for the
       particular target CPU, sometimes to a range if tuning for a generic
       target.  So all translation units that depend on ABI compatibility
       for the use of these variables must be compiled with the same
!      '-mtune' (or '-mcpu').
  
       If ABI stability is important, such as if the use is in a header
       for a library, you should probably not use the hardware
       interference size variables at all.  Alternatively, you can force a
!      particular value with '--param'.
  
       If you are confident that your use of the variable does not affect
       ABI outside a single build of your project, you can turn off the
!      warning with '-Wno-interference-size'.
  
! '-Wint-in-bool-context'
       Warn for suspicious use of integer values where boolean values are
       expected, such as conditional expressions (?:) using non-boolean
!      integer constants in boolean context, like 'if (a <= b ? 2 : 3)'.
!      Or left shifting of signed integers in boolean context, like 'for
!      (a = 0; 1 << a; a++);'.  Likewise for all kinds of multiplications
!      regardless of the data type.  This warning is enabled by '-Wall'.
  
! '-Wno-int-to-pointer-cast'
       Suppress warnings from casts to pointer type of an integer of a
       different size.  In C++, casting to a pointer type of smaller size
!      is an error.  'Wint-to-pointer-cast' is enabled by default.
  
! '-Wno-pointer-to-int-cast (C and Objective-C only)'
       Suppress warnings from casts from a pointer to an integer type of a
       different size.
  
! '-Winvalid-pch'
       Warn if a precompiled header (*note Precompiled Headers::) is found
       in the search path but cannot be used.
  
! '-Winvalid-utf8'
       Warn if an invalid UTF-8 character is found.  This warning is on by
!      default for C++23 if '-finput-charset=UTF-8' is used and turned
!      into error with '-pedantic-errors'.
  
! '-Wno-unicode'
       Don't diagnose invalid forms of delimited or named escape sequences
!      which are treated as separate tokens.  'Wunicode' is enabled by
       default.
  
! '-Wlong-long'
!      Warn if 'long long' type is used.  This is enabled by either
!      '-Wpedantic' or '-Wtraditional' in ISO C90 and C++98 modes.  To
!      inhibit the warning messages, use '-Wno-long-long'.
  
! '-Wvariadic-macros'
       Warn if variadic macros are used in ISO C90 mode, or if the GNU
       alternate syntax is used in ISO C99 mode.  This is enabled by
!      either '-Wpedantic' or '-Wtraditional'.  To inhibit the warning
!      messages, use '-Wno-variadic-macros'.
  
! '-Wno-varargs'
       Do not warn upon questionable usage of the macros used to handle
!      variable arguments like 'va_start'.  These warnings are enabled by
       default.
  
! '-Wvector-operation-performance'
       Warn if vector operation is not implemented via SIMD capabilities
       of the architecture.  Mainly useful for the performance tuning.
!      Vector operation can be implemented 'piecewise', which means that
!      the scalar operation is performed on every vector element; 'in
!      parallel', which means that the vector operation is implemented
       using scalars of wider type, which normally is more performance
!      efficient; and 'as a single scalar', which means that vector fits
       into a scalar type.
  
! '-Wvla'
!      Warn if a variable-length array is used in the code.  '-Wno-vla'
!      prevents the '-Wpedantic' warning of the variable-length array.
  
! '-Wvla-larger-than=BYTE-SIZE'
       If this option is used, the compiler warns for declarations of
       variable-length arrays whose size is either unbounded, or bounded
       by an argument that allows the array size to exceed BYTE-SIZE
!      bytes.  This is similar to how '-Walloca-larger-than='BYTE-SIZE
       works, but with variable-length arrays.
  
       Note that GCC may optimize small variable-length arrays of a known
       value into plain arrays, so this warning may not get triggered for
       such arrays.
  
!      '-Wvla-larger-than=''PTRDIFF_MAX' is enabled by default but is
!      typically only effective when '-ftree-vrp' is active (default for
!      '-O2' and above).
  
!      See also '-Walloca-larger-than=BYTE-SIZE'.
  
! '-Wno-vla-larger-than'
!      Disable '-Wvla-larger-than=' warnings.  The option is equivalent to
!      '-Wvla-larger-than=''SIZE_MAX' or larger.
  
! '-Wvla-parameter'
       Warn about redeclarations of functions involving arguments of
       Variable Length Array types of inconsistent kinds or forms, and
       enable the detection of out-of-bounds accesses to such parameters
!      by warnings such as '-Warray-bounds'.
  
       If the first function declaration uses the VLA form the bound
       specified in the array is assumed to be the minimum number of
--- 8939,9052 ----
                std::atomic two;
            };
  
!      Here ‘one’ and ‘two’ are intended to be far enough apart that
       stores to one won't require accesses to the other to reload the
       cache line.
  
!      By default, ‘--param destructive-interference-size’ and ‘--param
!      constructive-interference-size’ are set based on the current
!      ‘-mtune’ option, typically to the L1 cache line size for the
       particular target CPU, sometimes to a range if tuning for a generic
       target.  So all translation units that depend on ABI compatibility
       for the use of these variables must be compiled with the same
!      ‘-mtune’ (or ‘-mcpu’).
  
       If ABI stability is important, such as if the use is in a header
       for a library, you should probably not use the hardware
       interference size variables at all.  Alternatively, you can force a
!      particular value with ‘--param’.
  
       If you are confident that your use of the variable does not affect
       ABI outside a single build of your project, you can turn off the
!      warning with ‘-Wno-interference-size’.
  
! ‘-Wint-in-bool-context’
       Warn for suspicious use of integer values where boolean values are
       expected, such as conditional expressions (?:) using non-boolean
!      integer constants in boolean context, like ‘if (a <= b ? 2 : 3)’.
!      Or left shifting of signed integers in boolean context, like ‘for
!      (a = 0; 1 << a; a++);’.  Likewise for all kinds of multiplications
!      regardless of the data type.  This warning is enabled by ‘-Wall’.
  
! ‘-Wno-int-to-pointer-cast’
       Suppress warnings from casts to pointer type of an integer of a
       different size.  In C++, casting to a pointer type of smaller size
!      is an error.  ‘Wint-to-pointer-cast’ is enabled by default.
  
! ‘-Wno-pointer-to-int-cast (C and Objective-C only)’
       Suppress warnings from casts from a pointer to an integer type of a
       different size.
  
! ‘-Winvalid-pch’
       Warn if a precompiled header (*note Precompiled Headers::) is found
       in the search path but cannot be used.
  
! ‘-Winvalid-utf8’
       Warn if an invalid UTF-8 character is found.  This warning is on by
!      default for C++23 if ‘-finput-charset=UTF-8’ is used and turned
!      into error with ‘-pedantic-errors’.
  
! ‘-Wno-unicode’
       Don't diagnose invalid forms of delimited or named escape sequences
!      which are treated as separate tokens.  ‘Wunicode’ is enabled by
       default.
  
! ‘-Wlong-long’
!      Warn if ‘long long’ type is used.  This is enabled by either
!      ‘-Wpedantic’ or ‘-Wtraditional’ in ISO C90 and C++98 modes.  To
!      inhibit the warning messages, use ‘-Wno-long-long’.
  
! ‘-Wvariadic-macros’
       Warn if variadic macros are used in ISO C90 mode, or if the GNU
       alternate syntax is used in ISO C99 mode.  This is enabled by
!      either ‘-Wpedantic’ or ‘-Wtraditional’.  To inhibit the warning
!      messages, use ‘-Wno-variadic-macros’.
  
! ‘-Wno-varargs’
       Do not warn upon questionable usage of the macros used to handle
!      variable arguments like ‘va_start’.  These warnings are enabled by
       default.
  
! ‘-Wvector-operation-performance’
       Warn if vector operation is not implemented via SIMD capabilities
       of the architecture.  Mainly useful for the performance tuning.
!      Vector operation can be implemented ‘piecewise’, which means that
!      the scalar operation is performed on every vector element; ‘in
!      parallel’, which means that the vector operation is implemented
       using scalars of wider type, which normally is more performance
!      efficient; and ‘as a single scalar’, which means that vector fits
       into a scalar type.
  
! ‘-Wvla’
!      Warn if a variable-length array is used in the code.  ‘-Wno-vla’
!      prevents the ‘-Wpedantic’ warning of the variable-length array.
  
! ‘-Wvla-larger-than=BYTE-SIZE’
       If this option is used, the compiler warns for declarations of
       variable-length arrays whose size is either unbounded, or bounded
       by an argument that allows the array size to exceed BYTE-SIZE
!      bytes.  This is similar to how ‘-Walloca-larger-than=’BYTE-SIZE
       works, but with variable-length arrays.
  
       Note that GCC may optimize small variable-length arrays of a known
       value into plain arrays, so this warning may not get triggered for
       such arrays.
  
!      ‘-Wvla-larger-than=’‘PTRDIFF_MAX’ is enabled by default but is
!      typically only effective when ‘-ftree-vrp’ is active (default for
!      ‘-O2’ and above).
  
!      See also ‘-Walloca-larger-than=BYTE-SIZE’.
  
! ‘-Wno-vla-larger-than’
!      Disable ‘-Wvla-larger-than=’ warnings.  The option is equivalent to
!      ‘-Wvla-larger-than=’‘SIZE_MAX’ or larger.
  
! ‘-Wvla-parameter’
       Warn about redeclarations of functions involving arguments of
       Variable Length Array types of inconsistent kinds or forms, and
       enable the detection of out-of-bounds accesses to such parameters
!      by warnings such as ‘-Warray-bounds’.
  
       If the first function declaration uses the VLA form the bound
       specified in the array is assumed to be the minimum number of
*************** warnings, in some cases it may also caus
*** 9053,9060 ****
  
       For example, the warning triggers for the following redeclarations
       because the first one allows an array of any size to be passed to
!      'f' while the second one specifies that the array argument must
!      have at least 'n' elements.  In addition, calling 'f' with the
       associated VLA bound parameter in excess of the actual VLA bound
       triggers a warning as well.
  
--- 9057,9064 ----
  
       For example, the warning triggers for the following redeclarations
       because the first one allows an array of any size to be passed to
!      ‘f’ while the second one specifies that the array argument must
!      have at least ‘n’ elements.  In addition, calling ‘f’ with the
       associated VLA bound parameter in excess of the actual VLA bound
       triggers a warning as well.
  
*************** warnings, in some cases it may also caus
*** 9073,9102 ****
            }
  
  
!      '-Wvla-parameter' is included in '-Wall'.  The '-Warray-parameter'
       option triggers warnings for similar problems involving ordinary
       array arguments.
  
! '-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'.
  
! '-Wxor-used-as-pow (C, C++, Objective-C and Objective-C++ only)'
!      Warn about uses of '^', the exclusive or operator, where it appears
       the user meant exponentiation.  Specifically, the warning occurs
       when the left-hand side is the decimal constant 2 or 10 and the
       right-hand side is also a decimal constant.
  
!      In C and C++, '^' means exclusive or, whereas in some other
       languages (e.g.  TeX and some versions of BASIC) it means
       exponentiation.
  
       This warning is enabled by default.  It can be silenced by
       converting one of the operands to hexadecimal.
  
! '-Wdisabled-optimization'
       Warn if a requested optimization pass is disabled.  This warning
       does not generally indicate that there is anything wrong with your
       code; it merely indicates that GCC's optimizers are unable to
--- 9077,9106 ----
            }
  
  
!      ‘-Wvla-parameter’ is included in ‘-Wall’.  The ‘-Warray-parameter’
       option triggers warnings for similar problems involving ordinary
       array arguments.
  
! ‘-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’.
  
! ‘-Wxor-used-as-pow (C, C++, Objective-C and Objective-C++ only)’
!      Warn about uses of ‘^’, the exclusive or operator, where it appears
       the user meant exponentiation.  Specifically, the warning occurs
       when the left-hand side is the decimal constant 2 or 10 and the
       right-hand side is also a decimal constant.
  
!      In C and C++, ‘^’ means exclusive or, whereas in some other
       languages (e.g.  TeX and some versions of BASIC) it means
       exponentiation.
  
       This warning is enabled by default.  It can be silenced by
       converting one of the operands to hexadecimal.
  
! ‘-Wdisabled-optimization’
       Warn if a requested optimization pass is disabled.  This warning
       does not generally indicate that there is anything wrong with your
       code; it merely indicates that GCC's optimizers are unable to
*************** warnings, in some cases it may also caus
*** 9105,9122 ****
       the optimization itself is likely to take inordinate amounts of
       time.
  
! '-Wpointer-sign (C and Objective-C only)'
       Warn for pointer argument passing or assignment with different
       signedness.  This option is only supported for C and Objective-C.
!      It is implied by '-Wall' and by '-Wpedantic', which can be disabled
!      with '-Wno-pointer-sign'.
  
! '-Wstack-protector'
!      This option is only active when '-fstack-protector' is active.  It
       warns about functions that are not protected against stack
       smashing.
  
! '-Woverlength-strings'
       Warn about string constants that are longer than the "minimum
       maximum" length specified in the C standard.  Modern compilers
       generally allow string constants that are much longer than the
--- 9109,9126 ----
       the optimization itself is likely to take inordinate amounts of
       time.
  
! ‘-Wpointer-sign (C and Objective-C only)’
       Warn for pointer argument passing or assignment with different
       signedness.  This option is only supported for C and Objective-C.
!      It is implied by ‘-Wall’ and by ‘-Wpedantic’, which can be disabled
!      with ‘-Wno-pointer-sign’.
  
! ‘-Wstack-protector’
!      This option is only active when ‘-fstack-protector’ is active.  It
       warns about functions that are not protected against stack
       smashing.
  
! ‘-Woverlength-strings’
       Warn about string constants that are longer than the "minimum
       maximum" length specified in the C standard.  Modern compilers
       generally allow string constants that are much longer than the
*************** warnings, in some cases it may also caus
*** 9128,9154 ****
       in C99, it was raised to 4095.  C++98 does not specify a normative
       minimum maximum, so we do not diagnose overlength strings in C++.
  
!      This option is implied by '-Wpedantic', and can be disabled with
!      '-Wno-overlength-strings'.
  
! '-Wunsuffixed-float-constants (C and Objective-C only)'
  
       Issue a warning for any floating constant that does not have a
!      suffix.  When used together with '-Wsystem-headers' it warns about
       such constants in system header files.  This can be useful when
!      preparing code to use with the 'FLOAT_CONST_DECIMAL64' pragma from
       the decimal floating-point extension to C99.
  
! '-Wno-lto-type-mismatch'
  
       During the link-time optimization, do not warn about type
       mismatches in global declarations from different compilation units.
!      Requires '-flto' to be enabled.  Enabled by default.
  
! '-Wno-designated-init (C and Objective-C only)'
       Suppress warnings when a positional initializer is used to
       initialize a structure that has been marked with the
!      'designated_init' attribute.
  
  
  File: gcc.info,  Node: Static Analyzer Options,  Next: Debugging Options,  Prev: Warning Options,  Up: Invoking GCC
--- 9132,9158 ----
       in C99, it was raised to 4095.  C++98 does not specify a normative
       minimum maximum, so we do not diagnose overlength strings in C++.
  
!      This option is implied by ‘-Wpedantic’, and can be disabled with
!      ‘-Wno-overlength-strings’.
  
! ‘-Wunsuffixed-float-constants (C and Objective-C only)’
  
       Issue a warning for any floating constant that does not have a
!      suffix.  When used together with ‘-Wsystem-headers’ it warns about
       such constants in system header files.  This can be useful when
!      preparing code to use with the ‘FLOAT_CONST_DECIMAL64’ pragma from
       the decimal floating-point extension to C99.
  
! ‘-Wno-lto-type-mismatch’
  
       During the link-time optimization, do not warn about type
       mismatches in global declarations from different compilation units.
!      Requires ‘-flto’ to be enabled.  Enabled by default.
  
! ‘-Wno-designated-init (C and Objective-C only)’
       Suppress warnings when a positional initializer is used to
       initialize a structure that has been marked with the
!      ‘designated_init’ attribute.
  
  
  File: gcc.info,  Node: Static Analyzer Options,  Next: Debugging Options,  Prev: Warning Options,  Up: Invoking GCC
*************** File: gcc.info,  Node: Static Analyzer O
*** 9156,9162 ****
  3.9 Options That Control Static Analysis
  ========================================
  
! '-fanalyzer'
       This option enables an static analysis of program flow which looks
       for "interesting" interprocedural paths through the code, and
       issues warnings for problems found on them.
--- 9160,9166 ----
  3.9 Options That Control Static Analysis
  ========================================
  
! ‘-fanalyzer’
       This option enables an static analysis of program flow which looks
       for "interesting" interprocedural paths through the code, and
       issues warnings for problems found on them.
*************** File: gcc.info,  Node: Static Analyzer O
*** 9216,9255 ****
       This option is only available if GCC was configured with analyzer
       support enabled.
  
! '-Wanalyzer-too-complex'
!      If '-fanalyzer' is enabled, the analyzer uses various heuristics to
       attempt to explore the control flow and data flow in the program,
       but these can be defeated by sufficiently complicated code.
  
       By default, the analysis silently stops if the code is too
       complicated for the analyzer to fully explore and it reaches an
!      internal limit.  The '-Wanalyzer-too-complex' option warns if this
       occurs.
  
! '-Wno-analyzer-allocation-size'
!      This warning requires '-fanalyzer', which enables it; to disable
!      it, use '-Wno-analyzer-allocation-size'.
  
       This diagnostic warns for paths through the code in which a pointer
       to a buffer is assigned to point at a buffer with a size that is
!      not a multiple of 'sizeof (*pointer)'.
  
       See CWE-131: Incorrect Calculation of Buffer Size
       (https://cwe.mitre.org/data/definitions/131.html).
  
! '-Wno-analyzer-deref-before-check'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-deref-before-check' to disable it.
  
       This diagnostic warns for paths through the code in which a pointer
!      is checked for 'NULL' *after* it has already been dereferenced,
       suggesting that the pointer could have been NULL. Such cases
       suggest that the check for NULL is either redundant, or that it
       needs to be moved to before the pointer is dereferenced.
  
       This diagnostic also considers values passed to a function argument
!      marked with '__attribute__((nonnull))' as requiring a non-NULL
!      value, and thus will complain if such values are checked for 'NULL'
       after returning from such a function call.
  
       This diagnostic is unlikely to be reported when any level of
--- 9220,9259 ----
       This option is only available if GCC was configured with analyzer
       support enabled.
  
! ‘-Wanalyzer-too-complex’
!      If ‘-fanalyzer’ is enabled, the analyzer uses various heuristics to
       attempt to explore the control flow and data flow in the program,
       but these can be defeated by sufficiently complicated code.
  
       By default, the analysis silently stops if the code is too
       complicated for the analyzer to fully explore and it reaches an
!      internal limit.  The ‘-Wanalyzer-too-complex’ option warns if this
       occurs.
  
! ‘-Wno-analyzer-allocation-size’
!      This warning requires ‘-fanalyzer’, which enables it; to disable
!      it, use ‘-Wno-analyzer-allocation-size’.
  
       This diagnostic warns for paths through the code in which a pointer
       to a buffer is assigned to point at a buffer with a size that is
!      not a multiple of ‘sizeof (*pointer)’.
  
       See CWE-131: Incorrect Calculation of Buffer Size
       (https://cwe.mitre.org/data/definitions/131.html).
  
! ‘-Wno-analyzer-deref-before-check’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-deref-before-check’ to disable it.
  
       This diagnostic warns for paths through the code in which a pointer
!      is checked for ‘NULL’ *after* it has already been dereferenced,
       suggesting that the pointer could have been NULL. Such cases
       suggest that the check for NULL is either redundant, or that it
       needs to be moved to before the pointer is dereferenced.
  
       This diagnostic also considers values passed to a function argument
!      marked with ‘__attribute__((nonnull))’ as requiring a non-NULL
!      value, and thus will complain if such values are checked for ‘NULL’
       after returning from such a function call.
  
       This diagnostic is unlikely to be reported when any level of
*************** File: gcc.info,  Node: Static Analyzer O
*** 9258,9287 ****
       away before the analyzer "sees" them.  Hence optimization should be
       disabled when attempting to trigger this diagnostic.
  
! '-Wno-analyzer-double-fclose'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-double-fclose' to disable it.
  
!      This diagnostic warns for paths through the code in which a 'FILE
!      *' can have 'fclose' called on it more than once.
  
       See CWE-1341: Multiple Releases of Same Resource or Handle
       (https://cwe.mitre.org/data/definitions/1341.html).
  
! '-Wno-analyzer-double-free'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-double-free' to disable it.
  
       This diagnostic warns for paths through the code in which a pointer
!      can have a deallocator called on it more than once, either 'free',
!      or a deallocator referenced by attribute 'malloc'.
  
       See CWE-415: Double Free
       (https://cwe.mitre.org/data/definitions/415.html).
  
! '-Wno-analyzer-exposure-through-output-file'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-exposure-through-output-file' to disable it.
  
       This diagnostic warns for paths through the code in which a
       security-sensitive value is written to an output file (such as
--- 9262,9291 ----
       away before the analyzer "sees" them.  Hence optimization should be
       disabled when attempting to trigger this diagnostic.
  
! ‘-Wno-analyzer-double-fclose’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-double-fclose’ to disable it.
  
!      This diagnostic warns for paths through the code in which a ‘FILE
!      *’ can have ‘fclose’ called on it more than once.
  
       See CWE-1341: Multiple Releases of Same Resource or Handle
       (https://cwe.mitre.org/data/definitions/1341.html).
  
! ‘-Wno-analyzer-double-free’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-double-free’ to disable it.
  
       This diagnostic warns for paths through the code in which a pointer
!      can have a deallocator called on it more than once, either ‘free’,
!      or a deallocator referenced by attribute ‘malloc’.
  
       See CWE-415: Double Free
       (https://cwe.mitre.org/data/definitions/415.html).
  
! ‘-Wno-analyzer-exposure-through-output-file’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-exposure-through-output-file’ to disable it.
  
       This diagnostic warns for paths through the code in which a
       security-sensitive value is written to an output file (such as
*************** File: gcc.info,  Node: Static Analyzer O
*** 9290,9299 ****
       See CWE-532: Information Exposure Through Log Files
       (https://cwe.mitre.org/data/definitions/532.html).
  
! '-Wanalyzer-exposure-through-uninit-copy'
!      This warning requires both '-fanalyzer' and the use of a plugin to
       specify a function that copies across a "trust boundary".  Use
!      '-Wno-analyzer-exposure-through-uninit-copy' to disable it.
  
       This diagnostic warns for "infoleaks" - paths through the code in
       which uninitialized values are copied across a security boundary
--- 9294,9303 ----
       See CWE-532: Information Exposure Through Log Files
       (https://cwe.mitre.org/data/definitions/532.html).
  
! ‘-Wanalyzer-exposure-through-uninit-copy’
!      This warning requires both ‘-fanalyzer’ and the use of a plugin to
       specify a function that copies across a "trust boundary".  Use
!      ‘-Wno-analyzer-exposure-through-uninit-copy’ to disable it.
  
       This diagnostic warns for "infoleaks" - paths through the code in
       which uninitialized values are copied across a security boundary
*************** File: gcc.info,  Node: Static Analyzer O
*** 9303,9324 ****
       See CWE-200: Exposure of Sensitive Information to an Unauthorized
       Actor (https://cwe.mitre.org/data/definitions/200.html).
  
! '-Wno-analyzer-fd-access-mode-mismatch'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-fd-access-mode-mismatch' to disable it.
  
!      This diagnostic warns for paths through code in which a 'read' on a
       write-only file descriptor is attempted, or vice versa.
  
       This diagnostic also warns for code paths in a which a function
!      with attribute 'fd_arg_read (N)' is called with a file descriptor
!      opened with 'O_WRONLY' at referenced argument 'N' or a function
!      with attribute 'fd_arg_write (N)' is called with a file descriptor
!      opened with 'O_RDONLY' at referenced argument N.
  
! '-Wno-analyzer-fd-double-close'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-fd-double-close' to disable it.
  
       This diagnostic warns for paths through code in which a file
       descriptor can be closed more than once.
--- 9307,9328 ----
       See CWE-200: Exposure of Sensitive Information to an Unauthorized
       Actor (https://cwe.mitre.org/data/definitions/200.html).
  
! ‘-Wno-analyzer-fd-access-mode-mismatch’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-fd-access-mode-mismatch’ to disable it.
  
!      This diagnostic warns for paths through code in which a ‘read’ on a
       write-only file descriptor is attempted, or vice versa.
  
       This diagnostic also warns for code paths in a which a function
!      with attribute ‘fd_arg_read (N)’ is called with a file descriptor
!      opened with ‘O_WRONLY’ at referenced argument ‘N’ or a function
!      with attribute ‘fd_arg_write (N)’ is called with a file descriptor
!      opened with ‘O_RDONLY’ at referenced argument N.
  
! ‘-Wno-analyzer-fd-double-close’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-fd-double-close’ to disable it.
  
       This diagnostic warns for paths through code in which a file
       descriptor can be closed more than once.
*************** File: gcc.info,  Node: Static Analyzer O
*** 9326,9334 ****
       See CWE-1341: Multiple Releases of Same Resource or Handle
       (https://cwe.mitre.org/data/definitions/1341.html).
  
! '-Wno-analyzer-fd-leak'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-fd-leak' to disable it.
  
       This diagnostic warns for paths through code in which an open file
       descriptor is leaked.
--- 9330,9338 ----
       See CWE-1341: Multiple Releases of Same Resource or Handle
       (https://cwe.mitre.org/data/definitions/1341.html).
  
! ‘-Wno-analyzer-fd-leak’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-fd-leak’ to disable it.
  
       This diagnostic warns for paths through code in which an open file
       descriptor is leaked.
*************** File: gcc.info,  Node: Static Analyzer O
*** 9337,9413 ****
       Effective Lifetime
       (https://cwe.mitre.org/data/definitions/775.html).
  
! '-Wno-analyzer-fd-phase-mismatch'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-fd-phase-mismatch' to disable it.
  
       This diagnostic warns for paths through code in which an operation
       is attempted in the wrong phase of a file descriptor's lifetime.
!      For example, it will warn on attempts to call 'accept' on a stream
!      socket that has not yet had 'listen' successfully called on it.
  
       See CWE-666: Operation on Resource in Wrong Phase of Lifetime
       (https://cwe.mitre.org/data/definitions/666.html).
  
! '-Wno-analyzer-fd-type-mismatch'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-fd-type-mismatch' to disable it.
  
       This diagnostic warns for paths through code in which an operation
       is attempted on the wrong type of file descriptor.  For example, it
       will warn on attempts to use socket operations on a file descriptor
!      obtained via 'open', or when attempting to use a stream socket
       operation on a datagram socket.
  
! '-Wno-analyzer-fd-use-after-close'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-fd-use-after-close' to disable it.
  
       This diagnostic warns for paths through code in which a read or
       write is called on a closed file descriptor.
  
       This diagnostic also warns for paths through code in which a
!      function with attribute 'fd_arg (N)' or 'fd_arg_read (N)' or
!      'fd_arg_write (N)' is called with a closed file descriptor at
!      referenced argument 'N'.
  
! '-Wno-analyzer-fd-use-without-check'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-fd-use-without-check' to disable it.
  
       This diagnostic warns for paths through code in which a file
       descriptor is used without being checked for validity.
  
       This diagnostic also warns for paths through code in which a
!      function with attribute 'fd_arg (N)' or 'fd_arg_read (N)' or
!      'fd_arg_write (N)' is called with a file descriptor, at referenced
!      argument 'N', without being checked for validity.
  
! '-Wno-analyzer-file-leak'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-file-leak' to disable it.
  
       This diagnostic warns for paths through the code in which a
!      '' 'FILE *' stream object is leaked.
  
       See CWE-775: Missing Release of File Descriptor or Handle after
       Effective Lifetime
       (https://cwe.mitre.org/data/definitions/775.html).
  
! '-Wno-analyzer-free-of-non-heap'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-free-of-non-heap' to disable it.
  
!      This diagnostic warns for paths through the code in which 'free' is
       called on a non-heap pointer (e.g.  an on-stack buffer, or a
       global).
  
       See CWE-590: Free of Memory not on the Heap
       (https://cwe.mitre.org/data/definitions/590.html).
  
! '-Wno-analyzer-imprecise-fp-arithmetic'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-imprecise-fp-arithmetic' to disable it.
  
       This diagnostic warns for paths through the code in which
       floating-point arithmetic is used in locations where precise
--- 9341,9417 ----
       Effective Lifetime
       (https://cwe.mitre.org/data/definitions/775.html).
  
! ‘-Wno-analyzer-fd-phase-mismatch’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-fd-phase-mismatch’ to disable it.
  
       This diagnostic warns for paths through code in which an operation
       is attempted in the wrong phase of a file descriptor's lifetime.
!      For example, it will warn on attempts to call ‘accept’ on a stream
!      socket that has not yet had ‘listen’ successfully called on it.
  
       See CWE-666: Operation on Resource in Wrong Phase of Lifetime
       (https://cwe.mitre.org/data/definitions/666.html).
  
! ‘-Wno-analyzer-fd-type-mismatch’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-fd-type-mismatch’ to disable it.
  
       This diagnostic warns for paths through code in which an operation
       is attempted on the wrong type of file descriptor.  For example, it
       will warn on attempts to use socket operations on a file descriptor
!      obtained via ‘open’, or when attempting to use a stream socket
       operation on a datagram socket.
  
! ‘-Wno-analyzer-fd-use-after-close’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-fd-use-after-close’ to disable it.
  
       This diagnostic warns for paths through code in which a read or
       write is called on a closed file descriptor.
  
       This diagnostic also warns for paths through code in which a
!      function with attribute ‘fd_arg (N)’ or ‘fd_arg_read (N)’ or
!      ‘fd_arg_write (N)’ is called with a closed file descriptor at
!      referenced argument ‘N’.
  
! ‘-Wno-analyzer-fd-use-without-check’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-fd-use-without-check’ to disable it.
  
       This diagnostic warns for paths through code in which a file
       descriptor is used without being checked for validity.
  
       This diagnostic also warns for paths through code in which a
!      function with attribute ‘fd_arg (N)’ or ‘fd_arg_read (N)’ or
!      ‘fd_arg_write (N)’ is called with a file descriptor, at referenced
!      argument ‘N’, without being checked for validity.
  
! ‘-Wno-analyzer-file-leak’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-file-leak’ to disable it.
  
       This diagnostic warns for paths through the code in which a
!      ‘’ ‘FILE *’ stream object is leaked.
  
       See CWE-775: Missing Release of File Descriptor or Handle after
       Effective Lifetime
       (https://cwe.mitre.org/data/definitions/775.html).
  
! ‘-Wno-analyzer-free-of-non-heap’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-free-of-non-heap’ to disable it.
  
!      This diagnostic warns for paths through the code in which ‘free’ is
       called on a non-heap pointer (e.g.  an on-stack buffer, or a
       global).
  
       See CWE-590: Free of Memory not on the Heap
       (https://cwe.mitre.org/data/definitions/590.html).
  
! ‘-Wno-analyzer-imprecise-fp-arithmetic’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-imprecise-fp-arithmetic’ to disable it.
  
       This diagnostic warns for paths through the code in which
       floating-point arithmetic is used in locations where precise
*************** File: gcc.info,  Node: Static Analyzer O
*** 9415,9423 ****
       floating-point operands inside the calculation of an allocation
       size at the moment.
  
! '-Wno-analyzer-infinite-recursion'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-infinite-recursion' to disable it.
  
       This diagnostics warns for paths through the code which appear to
       lead to infinite recursion.
--- 9419,9427 ----
       floating-point operands inside the calculation of an allocation
       size at the moment.
  
! ‘-Wno-analyzer-infinite-recursion’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-infinite-recursion’ to disable it.
  
       This diagnostics warns for paths through the code which appear to
       lead to infinite recursion.
*************** File: gcc.info,  Node: Static Analyzer O
*** 9434,9477 ****
       "sees" them.  Hence optimization should be disabled when attempting
       to trigger this diagnostic.
  
!      Compare with '-Winfinite-recursion', which provides a similar
       diagnostic, but is implemented in a different way.
  
! '-Wno-analyzer-jump-through-null'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-jump-through-null' to disable it.
  
!      This diagnostic warns for paths through the code in which a 'NULL'
       function pointer is called.
  
! '-Wno-analyzer-malloc-leak'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-malloc-leak' to disable it.
  
       This diagnostic warns for paths through the code in which a pointer
!      allocated via an allocator is leaked: either 'malloc', or a
!      function marked with attribute 'malloc'.
  
       See CWE-401: Missing Release of Memory after Effective Lifetime
       (https://cwe.mitre.org/data/definitions/401.html).
  
! '-Wno-analyzer-mismatching-deallocation'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-mismatching-deallocation' to disable it.
  
       This diagnostic warns for paths through the code in which the wrong
       deallocation function is called on a pointer value, based on which
       function was used to allocate the pointer value.  The diagnostic
!      will warn about mismatches between 'free', scalar 'delete' and
!      vector 'delete[]', and those marked as allocator/deallocator pairs
!      using attribute 'malloc'.
  
       See CWE-762: Mismatched Memory Management Routines
       (https://cwe.mitre.org/data/definitions/762.html).
  
! '-Wno-analyzer-out-of-bounds'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-out-of-bounds' to disable it.
  
       This diagnostic warns for paths through the code in which a buffer
       is definitely read or written out-of-bounds.  The diagnostic
--- 9438,9481 ----
       "sees" them.  Hence optimization should be disabled when attempting
       to trigger this diagnostic.
  
!      Compare with ‘-Winfinite-recursion’, which provides a similar
       diagnostic, but is implemented in a different way.
  
! ‘-Wno-analyzer-jump-through-null’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-jump-through-null’ to disable it.
  
!      This diagnostic warns for paths through the code in which a ‘NULL’
       function pointer is called.
  
! ‘-Wno-analyzer-malloc-leak’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-malloc-leak’ to disable it.
  
       This diagnostic warns for paths through the code in which a pointer
!      allocated via an allocator is leaked: either ‘malloc’, or a
!      function marked with attribute ‘malloc’.
  
       See CWE-401: Missing Release of Memory after Effective Lifetime
       (https://cwe.mitre.org/data/definitions/401.html).
  
! ‘-Wno-analyzer-mismatching-deallocation’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-mismatching-deallocation’ to disable it.
  
       This diagnostic warns for paths through the code in which the wrong
       deallocation function is called on a pointer value, based on which
       function was used to allocate the pointer value.  The diagnostic
!      will warn about mismatches between ‘free’, scalar ‘delete’ and
!      vector ‘delete[]’, and those marked as allocator/deallocator pairs
!      using attribute ‘malloc’.
  
       See CWE-762: Mismatched Memory Management Routines
       (https://cwe.mitre.org/data/definitions/762.html).
  
! ‘-Wno-analyzer-out-of-bounds’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-out-of-bounds’ to disable it.
  
       This diagnostic warns for paths through the code in which a buffer
       is definitely read or written out-of-bounds.  The diagnostic
*************** File: gcc.info,  Node: Static Analyzer O
*** 9485,9504 ****
       of a Memory Buffer
       (https://cwe.mitre.org/data/definitions/119.html).
  
! '-Wno-analyzer-possible-null-argument'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-possible-null-argument' to disable it.
  
       This diagnostic warns for paths through the code in which a
       possibly-NULL value is passed to a function argument marked with
!      '__attribute__((nonnull))' as requiring a non-NULL value.
  
       See CWE-690: Unchecked Return Value to NULL Pointer Dereference
       (https://cwe.mitre.org/data/definitions/690.html).
  
! '-Wno-analyzer-possible-null-dereference'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-possible-null-dereference' to disable it.
  
       This diagnostic warns for paths through the code in which a
       possibly-NULL value is dereferenced.
--- 9489,9508 ----
       of a Memory Buffer
       (https://cwe.mitre.org/data/definitions/119.html).
  
! ‘-Wno-analyzer-possible-null-argument’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-possible-null-argument’ to disable it.
  
       This diagnostic warns for paths through the code in which a
       possibly-NULL value is passed to a function argument marked with
!      ‘__attribute__((nonnull))’ as requiring a non-NULL value.
  
       See CWE-690: Unchecked Return Value to NULL Pointer Dereference
       (https://cwe.mitre.org/data/definitions/690.html).
  
! ‘-Wno-analyzer-possible-null-dereference’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-possible-null-dereference’ to disable it.
  
       This diagnostic warns for paths through the code in which a
       possibly-NULL value is dereferenced.
*************** File: gcc.info,  Node: Static Analyzer O
*** 9506,9525 ****
       See CWE-690: Unchecked Return Value to NULL Pointer Dereference
       (https://cwe.mitre.org/data/definitions/690.html).
  
! '-Wno-analyzer-null-argument'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-null-argument' to disable it.
  
       This diagnostic warns for paths through the code in which a value
       known to be NULL is passed to a function argument marked with
!      '__attribute__((nonnull))' as requiring a non-NULL value.
  
       See CWE-476: NULL Pointer Dereference
       (https://cwe.mitre.org/data/definitions/476.html).
  
! '-Wno-analyzer-null-dereference'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-null-dereference' to disable it.
  
       This diagnostic warns for paths through the code in which a value
       known to be NULL is dereferenced.
--- 9510,9529 ----
       See CWE-690: Unchecked Return Value to NULL Pointer Dereference
       (https://cwe.mitre.org/data/definitions/690.html).
  
! ‘-Wno-analyzer-null-argument’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-null-argument’ to disable it.
  
       This diagnostic warns for paths through the code in which a value
       known to be NULL is passed to a function argument marked with
!      ‘__attribute__((nonnull))’ as requiring a non-NULL value.
  
       See CWE-476: NULL Pointer Dereference
       (https://cwe.mitre.org/data/definitions/476.html).
  
! ‘-Wno-analyzer-null-dereference’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-null-dereference’ to disable it.
  
       This diagnostic warns for paths through the code in which a value
       known to be NULL is dereferenced.
*************** File: gcc.info,  Node: Static Analyzer O
*** 9527,9587 ****
       See CWE-476: NULL Pointer Dereference
       (https://cwe.mitre.org/data/definitions/476.html).
  
! '-Wno-analyzer-putenv-of-auto-var'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-putenv-of-auto-var' to disable it.
  
       This diagnostic warns for paths through the code in which a call to
!      'putenv' is passed a pointer to an automatic variable or an
       on-stack buffer.
  
       See POS34-C. Do not call putenv() with a pointer to an automatic
       variable as the argument
       (https://wiki.sei.cmu.edu/confluence/x/6NYxBQ).
  
! '-Wno-analyzer-shift-count-negative'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-shift-count-negative' to disable it.
  
       This diagnostic warns for paths through the code in which a shift
       is attempted with a negative count.  It is analogous to the
!      '-Wshift-count-negative' diagnostic implemented in the C/C++ front
       ends, but is implemented based on analyzing interprocedural paths,
       rather than merely parsing the syntax tree.  However, the analyzer
       does not prioritize detection of such paths, so false negatives are
       more likely relative to other warnings.
  
! '-Wno-analyzer-shift-count-overflow'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-shift-count-overflow' to disable it.
  
       This diagnostic warns for paths through the code in which a shift
       is attempted with a count greater than or equal to the precision of
       the operand's type.  It is analogous to the
!      '-Wshift-count-overflow' diagnostic implemented in the C/C++ front
       ends, but is implemented based on analyzing interprocedural paths,
       rather than merely parsing the syntax tree.  However, the analyzer
       does not prioritize detection of such paths, so false negatives are
       more likely relative to other warnings.
  
! '-Wno-analyzer-stale-setjmp-buffer'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-stale-setjmp-buffer' to disable it.
  
!      This diagnostic warns for paths through the code in which 'longjmp'
!      is called to rewind to a 'jmp_buf' relating to a 'setjmp' call in a
       function that has returned.
  
!      When 'setjmp' is called on a 'jmp_buf' to record a rewind location,
       it records the stack frame.  The stack frame becomes invalid when
!      the function containing the 'setjmp' call returns.  Attempting to
!      rewind to it via 'longjmp' would reference a stack frame that no
       longer exists, and likely lead to a crash (or worse).
  
! '-Wno-analyzer-tainted-allocation-size'
!      This warning requires both '-fanalyzer' and
!      '-fanalyzer-checker=taint' to enable it; use
!      '-Wno-analyzer-tainted-allocation-size' to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as the size of an
--- 9531,9591 ----
       See CWE-476: NULL Pointer Dereference
       (https://cwe.mitre.org/data/definitions/476.html).
  
! ‘-Wno-analyzer-putenv-of-auto-var’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-putenv-of-auto-var’ to disable it.
  
       This diagnostic warns for paths through the code in which a call to
!      ‘putenv’ is passed a pointer to an automatic variable or an
       on-stack buffer.
  
       See POS34-C. Do not call putenv() with a pointer to an automatic
       variable as the argument
       (https://wiki.sei.cmu.edu/confluence/x/6NYxBQ).
  
! ‘-Wno-analyzer-shift-count-negative’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-shift-count-negative’ to disable it.
  
       This diagnostic warns for paths through the code in which a shift
       is attempted with a negative count.  It is analogous to the
!      ‘-Wshift-count-negative’ diagnostic implemented in the C/C++ front
       ends, but is implemented based on analyzing interprocedural paths,
       rather than merely parsing the syntax tree.  However, the analyzer
       does not prioritize detection of such paths, so false negatives are
       more likely relative to other warnings.
  
! ‘-Wno-analyzer-shift-count-overflow’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-shift-count-overflow’ to disable it.
  
       This diagnostic warns for paths through the code in which a shift
       is attempted with a count greater than or equal to the precision of
       the operand's type.  It is analogous to the
!      ‘-Wshift-count-overflow’ diagnostic implemented in the C/C++ front
       ends, but is implemented based on analyzing interprocedural paths,
       rather than merely parsing the syntax tree.  However, the analyzer
       does not prioritize detection of such paths, so false negatives are
       more likely relative to other warnings.
  
! ‘-Wno-analyzer-stale-setjmp-buffer’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-stale-setjmp-buffer’ to disable it.
  
!      This diagnostic warns for paths through the code in which ‘longjmp’
!      is called to rewind to a ‘jmp_buf’ relating to a ‘setjmp’ call in a
       function that has returned.
  
!      When ‘setjmp’ is called on a ‘jmp_buf’ to record a rewind location,
       it records the stack frame.  The stack frame becomes invalid when
!      the function containing the ‘setjmp’ call returns.  Attempting to
!      rewind to it via ‘longjmp’ would reference a stack frame that no
       longer exists, and likely lead to a crash (or worse).
  
! ‘-Wno-analyzer-tainted-allocation-size’
!      This warning requires both ‘-fanalyzer’ and
!      ‘-fanalyzer-checker=taint’ to enable it; use
!      ‘-Wno-analyzer-tainted-allocation-size’ to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as the size of an
*************** File: gcc.info,  Node: Static Analyzer O
*** 9592,9608 ****
       See CWE-789: Memory Allocation with Excessive Size Value
       (https://cwe.mitre.org/data/definitions/789.html).
  
! '-Wno-analyzer-tainted-assertion'
  
!      This warning requires both '-fanalyzer' and
!      '-fanalyzer-checker=taint' to enable it; use
!      '-Wno-analyzer-tainted-assertion' to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as part of a
       condition without being first sanitized, and that condition guards
!      a call to a function marked with attribute 'noreturn' (such as the
!      function '__builtin_unreachable').  Such functions typically
       indicate abnormal termination of the program, such as for assertion
       failure handlers.  For example:
  
--- 9596,9612 ----
       See CWE-789: Memory Allocation with Excessive Size Value
       (https://cwe.mitre.org/data/definitions/789.html).
  
! ‘-Wno-analyzer-tainted-assertion’
  
!      This warning requires both ‘-fanalyzer’ and
!      ‘-fanalyzer-checker=taint’ to enable it; use
!      ‘-Wno-analyzer-tainted-assertion’ to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as part of a
       condition without being first sanitized, and that condition guards
!      a call to a function marked with attribute ‘noreturn’ (such as the
!      function ‘__builtin_unreachable’).  Such functions typically
       indicate abnormal termination of the program, such as for assertion
       failure handlers.  For example:
  
*************** File: gcc.info,  Node: Static Analyzer O
*** 9610,9620 ****
  
       In such cases:
  
!         * when assertion-checking is enabled: an attacker could trigger
            a denial of service by injecting an assertion failure
  
!         * when assertion-checking is disabled, such as by defining
!           'NDEBUG', an attacker could inject data that subverts the
            process, since it presumably violates a precondition that is
            being assumed by the code.
  
--- 9614,9624 ----
  
       In such cases:
  
!         • when assertion-checking is enabled: an attacker could trigger
            a denial of service by injecting an assertion failure
  
!         • when assertion-checking is disabled, such as by defining
!           ‘NDEBUG’, an attacker could inject data that subverts the
            process, since it presumably violates a precondition that is
            being assumed by the code.
  
*************** File: gcc.info,  Node: Static Analyzer O
*** 9624,9631 ****
       on builds in which assertion-checking is enabled.
  
       For the purpose of this warning, any function marked with attribute
!      'noreturn' is considered as a possible assertion failure handler,
!      including '__builtin_unreachable'.  Note that these functions are
       sometimes removed by the optimizer before the analyzer "sees" them.
       Hence optimization should be disabled when attempting to trigger
       this diagnostic.
--- 9628,9635 ----
       on builds in which assertion-checking is enabled.
  
       For the purpose of this warning, any function marked with attribute
!      ‘noreturn’ is considered as a possible assertion failure handler,
!      including ‘__builtin_unreachable’.  Note that these functions are
       sometimes removed by the optimizer before the analyzer "sees" them.
       Hence optimization should be disabled when attempting to trigger
       this diagnostic.
*************** File: gcc.info,  Node: Static Analyzer O
*** 9647,9656 ****
       despite the above not being an assertion failure, strictly
       speaking.
  
! '-Wno-analyzer-tainted-array-index'
!      This warning requires both '-fanalyzer' and
!      '-fanalyzer-checker=taint' to enable it; use
!      '-Wno-analyzer-tainted-array-index' to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as the index of
--- 9651,9660 ----
       despite the above not being an assertion failure, strictly
       speaking.
  
! ‘-Wno-analyzer-tainted-array-index’
!      This warning requires both ‘-fanalyzer’ and
!      ‘-fanalyzer-checker=taint’ to enable it; use
!      ‘-Wno-analyzer-tainted-array-index’ to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as the index of
*************** File: gcc.info,  Node: Static Analyzer O
*** 9660,9669 ****
       See CWE-129: Improper Validation of Array Index
       (https://cwe.mitre.org/data/definitions/129.html).
  
! '-Wno-analyzer-tainted-divisor'
!      This warning requires both '-fanalyzer' and
!      '-fanalyzer-checker=taint' to enable it; use
!      '-Wno-analyzer-tainted-divisor' to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as the divisor in
--- 9664,9673 ----
       See CWE-129: Improper Validation of Array Index
       (https://cwe.mitre.org/data/definitions/129.html).
  
! ‘-Wno-analyzer-tainted-divisor’
!      This warning requires both ‘-fanalyzer’ and
!      ‘-fanalyzer-checker=taint’ to enable it; use
!      ‘-Wno-analyzer-tainted-divisor’ to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as the divisor in
*************** File: gcc.info,  Node: Static Analyzer O
*** 9673,9682 ****
       See CWE-369: Divide By Zero
       (https://cwe.mitre.org/data/definitions/369.html).
  
! '-Wno-analyzer-tainted-offset'
!      This warning requires both '-fanalyzer' and
!      '-fanalyzer-checker=taint' to enable it; use
!      '-Wno-analyzer-tainted-offset' to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as a pointer
--- 9677,9686 ----
       See CWE-369: Divide By Zero
       (https://cwe.mitre.org/data/definitions/369.html).
  
! ‘-Wno-analyzer-tainted-offset’
!      This warning requires both ‘-fanalyzer’ and
!      ‘-fanalyzer-checker=taint’ to enable it; use
!      ‘-Wno-analyzer-tainted-offset’ to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as a pointer
*************** File: gcc.info,  Node: Static Analyzer O
*** 9686,9787 ****
       See CWE-823: Use of Out-of-range Pointer Offset
       (https://cwe.mitre.org/data/definitions/823.html).
  
! '-Wno-analyzer-tainted-size'
!      This warning requires both '-fanalyzer' and
!      '-fanalyzer-checker=taint' to enable it; use
!      '-Wno-analyzer-tainted-size' to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as the size of an
!      operation such as 'memset' without being sanitized, so that an
       attacker could inject an out-of-bounds access.
  
       See CWE-129: Improper Validation of Array Index
       (https://cwe.mitre.org/data/definitions/129.html).
  
! '-Wno-analyzer-unsafe-call-within-signal-handler'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-unsafe-call-within-signal-handler' to disable it.
  
       This diagnostic warns for paths through the code in which a
!      function known to be async-signal-unsafe (such as 'fprintf') is
       called from a signal handler.
  
       See CWE-479: Signal Handler Use of a Non-reentrant Function
       (https://cwe.mitre.org/data/definitions/479.html).
  
! '-Wno-analyzer-use-after-free'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-use-after-free' to disable it.
  
       This diagnostic warns for paths through the code in which a pointer
!      is used after a deallocator is called on it: either 'free', or a
!      deallocator referenced by attribute 'malloc'.
  
       See CWE-416: Use After Free
       (https://cwe.mitre.org/data/definitions/416.html).
  
! '-Wno-analyzer-use-of-pointer-in-stale-stack-frame'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-use-of-pointer-in-stale-stack-frame' to disable it.
  
       This diagnostic warns for paths through the code in which a pointer
       is dereferenced that points to a variable in a stale stack frame.
  
! '-Wno-analyzer-va-arg-type-mismatch'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-va-arg-type-mismatch' to disable it.
  
       This diagnostic warns for interprocedural paths through the code
!      for which the analyzer detects an attempt to use 'va_arg' to
       extract a value passed to a variadic call, but uses a type that
       does not match that of the expression passed to the call.
  
       See CWE-686: Function Call With Incorrect Argument Type
       (https://cwe.mitre.org/data/definitions/686.html).
  
! '-Wno-analyzer-va-list-exhausted'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-va-list-exhausted' to disable it.
  
       This diagnostic warns for interprocedural paths through the code
!      for which the analyzer detects an attempt to use 'va_arg' to access
       the next value passed to a variadic call, but all of the values in
!      the 'va_list' have already been consumed.
  
       See CWE-685: Function Call With Incorrect Number of Arguments
       (https://cwe.mitre.org/data/definitions/685.html).
  
! '-Wno-analyzer-va-list-leak'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-va-list-leak' to disable it.
  
       This diagnostic warns for interprocedural paths through the code
!      for which the analyzer detects that 'va_start' or 'va_copy' has
!      been called on a 'va_list' without a corresponding call to
!      'va_end'.
  
! '-Wno-analyzer-va-list-use-after-va-end'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-va-list-use-after-va-end' to disable it.
  
       This diagnostic warns for interprocedural paths through the code
!      for which the analyzer detects an attempt to use a 'va_list' after
!      'va_end' has been called on it.  'va_list'.
  
! '-Wno-analyzer-write-to-const'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-write-to-const' to disable it.
  
       This diagnostic warns for paths through the code in which the
!      analyzer detects an attempt to write through a pointer to a 'const'
       object.  However, the analyzer does not prioritize detection of
       such paths, so false negatives are more likely relative to other
       warnings.
  
! '-Wno-analyzer-write-to-string-literal'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-write-to-string-literal' to disable it.
  
       This diagnostic warns for paths through the code in which the
       analyzer detects an attempt to write through a pointer to a string
--- 9690,9791 ----
       See CWE-823: Use of Out-of-range Pointer Offset
       (https://cwe.mitre.org/data/definitions/823.html).
  
! ‘-Wno-analyzer-tainted-size’
!      This warning requires both ‘-fanalyzer’ and
!      ‘-fanalyzer-checker=taint’ to enable it; use
!      ‘-Wno-analyzer-tainted-size’ to disable it.
  
       This diagnostic warns for paths through the code in which a value
       that could be under an attacker's control is used as the size of an
!      operation such as ‘memset’ without being sanitized, so that an
       attacker could inject an out-of-bounds access.
  
       See CWE-129: Improper Validation of Array Index
       (https://cwe.mitre.org/data/definitions/129.html).
  
! ‘-Wno-analyzer-unsafe-call-within-signal-handler’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-unsafe-call-within-signal-handler’ to disable it.
  
       This diagnostic warns for paths through the code in which a
!      function known to be async-signal-unsafe (such as ‘fprintf’) is
       called from a signal handler.
  
       See CWE-479: Signal Handler Use of a Non-reentrant Function
       (https://cwe.mitre.org/data/definitions/479.html).
  
! ‘-Wno-analyzer-use-after-free’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-use-after-free’ to disable it.
  
       This diagnostic warns for paths through the code in which a pointer
!      is used after a deallocator is called on it: either ‘free’, or a
!      deallocator referenced by attribute ‘malloc’.
  
       See CWE-416: Use After Free
       (https://cwe.mitre.org/data/definitions/416.html).
  
! ‘-Wno-analyzer-use-of-pointer-in-stale-stack-frame’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-use-of-pointer-in-stale-stack-frame’ to disable it.
  
       This diagnostic warns for paths through the code in which a pointer
       is dereferenced that points to a variable in a stale stack frame.
  
! ‘-Wno-analyzer-va-arg-type-mismatch’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-va-arg-type-mismatch’ to disable it.
  
       This diagnostic warns for interprocedural paths through the code
!      for which the analyzer detects an attempt to use ‘va_arg’ to
       extract a value passed to a variadic call, but uses a type that
       does not match that of the expression passed to the call.
  
       See CWE-686: Function Call With Incorrect Argument Type
       (https://cwe.mitre.org/data/definitions/686.html).
  
! ‘-Wno-analyzer-va-list-exhausted’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-va-list-exhausted’ to disable it.
  
       This diagnostic warns for interprocedural paths through the code
!      for which the analyzer detects an attempt to use ‘va_arg’ to access
       the next value passed to a variadic call, but all of the values in
!      the ‘va_list’ have already been consumed.
  
       See CWE-685: Function Call With Incorrect Number of Arguments
       (https://cwe.mitre.org/data/definitions/685.html).
  
! ‘-Wno-analyzer-va-list-leak’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-va-list-leak’ to disable it.
  
       This diagnostic warns for interprocedural paths through the code
!      for which the analyzer detects that ‘va_start’ or ‘va_copy’ has
!      been called on a ‘va_list’ without a corresponding call to
!      ‘va_end’.
  
! ‘-Wno-analyzer-va-list-use-after-va-end’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-va-list-use-after-va-end’ to disable it.
  
       This diagnostic warns for interprocedural paths through the code
!      for which the analyzer detects an attempt to use a ‘va_list’ after
!      ‘va_end’ has been called on it.  ‘va_list’.
  
! ‘-Wno-analyzer-write-to-const’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-write-to-const’ to disable it.
  
       This diagnostic warns for paths through the code in which the
!      analyzer detects an attempt to write through a pointer to a ‘const’
       object.  However, the analyzer does not prioritize detection of
       such paths, so false negatives are more likely relative to other
       warnings.
  
! ‘-Wno-analyzer-write-to-string-literal’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-write-to-string-literal’ to disable it.
  
       This diagnostic warns for paths through the code in which the
       analyzer detects an attempt to write through a pointer to a string
*************** File: gcc.info,  Node: Static Analyzer O
*** 9789,9797 ****
       such paths, so false negatives are more likely relative to other
       warnings.
  
! '-Wno-analyzer-use-of-uninitialized-value'
!      This warning requires '-fanalyzer', which enables it; use
!      '-Wno-analyzer-use-of-uninitialized-value' to disable it.
  
       This diagnostic warns for paths through the code in which an
       uninitialized value is used.
--- 9793,9801 ----
       such paths, so false negatives are more likely relative to other
       warnings.
  
! ‘-Wno-analyzer-use-of-uninitialized-value’
!      This warning requires ‘-fanalyzer’, which enables it; use
!      ‘-Wno-analyzer-use-of-uninitialized-value’ to disable it.
  
       This diagnostic warns for paths through the code in which an
       uninitialized value is used.
*************** File: gcc.info,  Node: Static Analyzer O
*** 9802,9908 ****
   The analyzer has hardcoded knowledge about the behavior of the
  following memory-management functions:
  
!    * 'alloca'
!    * The built-in functions '__builtin_alloc',
!      '__builtin_alloc_with_align',
!    * '__builtin_calloc', '__builtin_free', '__builtin_malloc',
!      '__builtin_memcpy', '__builtin_memcpy_chk', '__builtin_memset',
!      '__builtin_memset_chk', '__builtin_realloc',
!      '__builtin_stack_restore', and '__builtin_stack_save'
!    * 'calloc'
!    * 'free'
!    * 'malloc'
!    * 'memset'
!    * 'operator delete'
!    * 'operator delete []'
!    * 'operator new'
!    * 'operator new []'
!    * 'realloc'
!    * 'strdup'
!    * 'strndup'
  
  of the following functions for working with file descriptors:
  
!    * 'open'
!    * 'close'
!    * 'creat'
!    * 'dup', 'dup2' and 'dup3'
!    * 'isatty'
!    * 'pipe', and 'pipe2'
!    * 'read'
!    * 'write'
!    * 'socket', 'bind', 'listen', 'accept', and 'connect'
  
! of the following functions for working with '' streams:
!    * The built-in functions '__builtin_fprintf',
!      '__builtin_fprintf_unlocked', '__builtin_fputc',
!      '__builtin_fputc_unlocked', '__builtin_fputs',
!      '__builtin_fputs_unlocked', '__builtin_fwrite',
!      '__builtin_fwrite_unlocked', '__builtin_printf',
!      '__builtin_printf_unlocked', '__builtin_putc', '__builtin_putchar',
!      '__builtin_putchar_unlocked', '__builtin_putc_unlocked',
!      '__builtin_puts', '__builtin_puts_unlocked', '__builtin_vfprintf',
!      and '__builtin_vprintf'
!    * 'fopen'
!    * 'fclose'
!    * 'ferror'
!    * 'fgets'
!    * 'fgets_unlocked'
!    * 'fileno'
!    * 'fread'
!    * 'getc'
!    * 'getchar'
!    * 'fprintf'
!    * 'printf'
!    * 'fwrite'
  
  and of the following functions:
  
!    * The built-in functions '__builtin_expect',
!      '__builtin_expect_with_probability', '__builtin_strchr',
!      '__builtin_strcpy', '__builtin_strcpy_chk', '__builtin_strlen',
!      '__builtin_va_copy', and '__builtin_va_start'
!    * The GNU extensions 'error' and 'error_at_line'
!    * 'getpass'
!    * 'longjmp'
!    * 'putenv'
!    * 'setjmp'
!    * 'siglongjmp'
!    * 'signal'
!    * 'sigsetjmp'
!    * 'strchr'
!    * 'strlen'
  
!  In addition, various functions with an '__analyzer_' prefix have
  special meaning to the analyzer, described in the GCC Internals manual.
  
   Pertinent parameters for controlling the exploration are:
!    * '--param analyzer-bb-explosion-factor=VALUE'
!    * '--param analyzer-max-enodes-per-program-point=VALUE'
!    * '--param analyzer-max-recursion-depth=VALUE'
!    * '--param analyzer-min-snodes-for-call-summary=VALUE'
  
   The following options control the analyzer.
  
! '-fanalyzer-call-summaries'
       Simplify interprocedural analysis by computing the effect of
       certain calls, rather than exploring all paths through the function
       from callsite to each possible return.
  
       If enabled, call summaries are only used for functions with more
       than one call site, and that are sufficiently complicated (as per
!      '--param analyzer-min-snodes-for-call-summary=VALUE').
  
! '-fanalyzer-checker=NAME'
       Restrict the analyzer to run just the named checker, and enable it.
  
!      Some checkers are disabled by default (even with '-fanalyzer'),
!      such as the 'taint' checker that implements
!      '-Wanalyzer-tainted-array-index', and this option is required to
       enable them.
  
!      _Note:_ currently, '-fanalyzer-checker=taint' disables the
!      following warnings from '-fanalyzer':
  
            -Wanalyzer-deref-before-check
            -Wanalyzer-double-fclose
--- 9806,9912 ----
   The analyzer has hardcoded knowledge about the behavior of the
  following memory-management functions:
  
!    • ‘alloca’
!    • The built-in functions ‘__builtin_alloc’,
!      ‘__builtin_alloc_with_align’,
!    • ‘__builtin_calloc’, ‘__builtin_free’, ‘__builtin_malloc’,
!      ‘__builtin_memcpy’, ‘__builtin_memcpy_chk’, ‘__builtin_memset’,
!      ‘__builtin_memset_chk’, ‘__builtin_realloc’,
!      ‘__builtin_stack_restore’, and ‘__builtin_stack_save’
!    • ‘calloc’
!    • ‘free’
!    • ‘malloc’
!    • ‘memset’
!    • ‘operator delete’
!    • ‘operator delete []’
!    • ‘operator new’
!    • ‘operator new []’
!    • ‘realloc’
!    • ‘strdup’
!    • ‘strndup’
  
  of the following functions for working with file descriptors:
  
!    • ‘open’
!    • ‘close’
!    • ‘creat’
!    • ‘dup’, ‘dup2’ and ‘dup3’
!    • ‘isatty’
!    • ‘pipe’, and ‘pipe2’
!    • ‘read’
!    • ‘write’
!    • ‘socket’, ‘bind’, ‘listen’, ‘accept’, and ‘connect’
  
! of the following functions for working with ‘’ streams:
!    • The built-in functions ‘__builtin_fprintf’,
!      ‘__builtin_fprintf_unlocked’, ‘__builtin_fputc’,
!      ‘__builtin_fputc_unlocked’, ‘__builtin_fputs’,
!      ‘__builtin_fputs_unlocked’, ‘__builtin_fwrite’,
!      ‘__builtin_fwrite_unlocked’, ‘__builtin_printf’,
!      ‘__builtin_printf_unlocked’, ‘__builtin_putc’, ‘__builtin_putchar’,
!      ‘__builtin_putchar_unlocked’, ‘__builtin_putc_unlocked’,
!      ‘__builtin_puts’, ‘__builtin_puts_unlocked’, ‘__builtin_vfprintf’,
!      and ‘__builtin_vprintf’
!    • ‘fopen’
!    • ‘fclose’
!    • ‘ferror’
!    • ‘fgets’
!    • ‘fgets_unlocked’
!    • ‘fileno’
!    • ‘fread’
!    • ‘getc’
!    • ‘getchar’
!    • ‘fprintf’
!    • ‘printf’
!    • ‘fwrite’
  
  and of the following functions:
  
!    • The built-in functions ‘__builtin_expect’,
!      ‘__builtin_expect_with_probability’, ‘__builtin_strchr’,
!      ‘__builtin_strcpy’, ‘__builtin_strcpy_chk’, ‘__builtin_strlen’,
!      ‘__builtin_va_copy’, and ‘__builtin_va_start’
!    • The GNU extensions ‘error’ and ‘error_at_line’
!    • ‘getpass’
!    • ‘longjmp’
!    • ‘putenv’
!    • ‘setjmp’
!    • ‘siglongjmp’
!    • ‘signal’
!    • ‘sigsetjmp’
!    • ‘strchr’
!    • ‘strlen’
  
!  In addition, various functions with an ‘__analyzer_’ prefix have
  special meaning to the analyzer, described in the GCC Internals manual.
  
   Pertinent parameters for controlling the exploration are:
!    • ‘--param analyzer-bb-explosion-factor=VALUE’
!    • ‘--param analyzer-max-enodes-per-program-point=VALUE’
!    • ‘--param analyzer-max-recursion-depth=VALUE’
!    • ‘--param analyzer-min-snodes-for-call-summary=VALUE’
  
   The following options control the analyzer.
  
! ‘-fanalyzer-call-summaries’
       Simplify interprocedural analysis by computing the effect of
       certain calls, rather than exploring all paths through the function
       from callsite to each possible return.
  
       If enabled, call summaries are only used for functions with more
       than one call site, and that are sufficiently complicated (as per
!      ‘--param analyzer-min-snodes-for-call-summary=VALUE’).
  
! ‘-fanalyzer-checker=NAME’
       Restrict the analyzer to run just the named checker, and enable it.
  
!      Some checkers are disabled by default (even with ‘-fanalyzer’),
!      such as the ‘taint’ checker that implements
!      ‘-Wanalyzer-tainted-array-index’, and this option is required to
       enable them.
  
!      _Note:_ currently, ‘-fanalyzer-checker=taint’ disables the
!      following warnings from ‘-fanalyzer’:
  
            -Wanalyzer-deref-before-check
            -Wanalyzer-double-fclose
*************** special meaning to the analyzer, describ
*** 9927,9943 ****
            -Wanalyzer-va-list-use-after-va-end
  
  
! '-fno-analyzer-feasibility'
       This option is intended for analyzer developers.
  
       By default the analyzer verifies that there is a feasible control
       flow path for each diagnostic it emits: that the conditions that
       hold are not mutually exclusive.  Diagnostics for which no feasible
       path can be found are rejected.  This filtering can be suppressed
!      with '-fno-analyzer-feasibility', for debugging issues in this
       code.
  
! '-fanalyzer-fine-grained'
       This option is intended for analyzer developers.
  
       Internally the analyzer builds an "exploded graph" that combines
--- 9931,9947 ----
            -Wanalyzer-va-list-use-after-va-end
  
  
! ‘-fno-analyzer-feasibility’
       This option is intended for analyzer developers.
  
       By default the analyzer verifies that there is a feasible control
       flow path for each diagnostic it emits: that the conditions that
       hold are not mutually exclusive.  Diagnostics for which no feasible
       path can be found are rejected.  This filtering can be suppressed
!      with ‘-fno-analyzer-feasibility’, for debugging issues in this
       code.
  
! ‘-fanalyzer-fine-grained’
       This option is intended for analyzer developers.
  
       Internally the analyzer builds an "exploded graph" that combines
*************** special meaning to the analyzer, describ
*** 9945,9968 ****
  
       By default, an edge in this graph can contain the effects of a run
       of multiple statements within a basic block.  With
!      '-fanalyzer-fine-grained', each statement gets its own edge.
  
! '-fanalyzer-show-duplicate-count'
       This option is intended for analyzer developers: if multiple
       diagnostics have been detected as being duplicates of each other,
       it emits a note when reporting the best diagnostic, giving the
       number of additional diagnostics that were suppressed by the
       deduplication logic.
  
! '-fno-analyzer-state-merge'
       This option is intended for analyzer developers.
  
       By default the analyzer attempts to simplify analysis by merging
       sufficiently similar states at each program point as it builds its
!      "exploded graph".  With '-fno-analyzer-state-merge' this merging
       can be suppressed, for debugging state-handling issues.
  
! '-fno-analyzer-state-purge'
       This option is intended for analyzer developers.
  
       By default the analyzer attempts to simplify analysis by purging
--- 9949,9972 ----
  
       By default, an edge in this graph can contain the effects of a run
       of multiple statements within a basic block.  With
!      ‘-fanalyzer-fine-grained’, each statement gets its own edge.
  
! ‘-fanalyzer-show-duplicate-count’
       This option is intended for analyzer developers: if multiple
       diagnostics have been detected as being duplicates of each other,
       it emits a note when reporting the best diagnostic, giving the
       number of additional diagnostics that were suppressed by the
       deduplication logic.
  
! ‘-fno-analyzer-state-merge’
       This option is intended for analyzer developers.
  
       By default the analyzer attempts to simplify analysis by merging
       sufficiently similar states at each program point as it builds its
!      "exploded graph".  With ‘-fno-analyzer-state-merge’ this merging
       can be suppressed, for debugging state-handling issues.
  
! ‘-fno-analyzer-state-purge’
       This option is intended for analyzer developers.
  
       By default the analyzer attempts to simplify analysis by purging
*************** special meaning to the analyzer, describ
*** 9970,9979 ****
       relevant e.g.  the values of locals that aren't accessed later in
       the function and which aren't relevant to leak analysis.
  
!      With '-fno-analyzer-state-purge' this purging of state can be
       suppressed, for debugging state-handling issues.
  
! '-fno-analyzer-suppress-followups'
       This option is intended for analyzer developers.
  
       By default the analyzer will stop exploring an execution path after
--- 9974,9983 ----
       relevant e.g.  the values of locals that aren't accessed later in
       the function and which aren't relevant to leak analysis.
  
!      With ‘-fno-analyzer-state-purge’ this purging of state can be
       suppressed, for debugging state-handling issues.
  
! ‘-fno-analyzer-suppress-followups’
       This option is intended for analyzer developers.
  
       By default the analyzer will stop exploring an execution path after
*************** special meaning to the analyzer, describ
*** 9982,10006 ****
  
       The diagnostics that terminate analysis along a path are:
  
!         * '-Wanalyzer-null-argument'
!         * '-Wanalyzer-null-dereference'
!         * '-Wanalyzer-use-after-free'
!         * '-Wanalyzer-use-of-pointer-in-stale-stack-frame'
!         * '-Wanalyzer-use-of-uninitialized-value'
  
!      With '-fno-analyzer-suppress-followups' the analyzer will continue
       to explore such paths even after such diagnostics, which may be
       helpful for debugging issues in the analyzer, or for
       microbenchmarks for detecting undefined behavior.
  
! '-fanalyzer-transitivity'
       This option enables transitivity of constraints within the
       analyzer.
  
! '-fno-analyzer-undo-inlining'
       This option is intended for analyzer developers.
  
!      '-fanalyzer' runs relatively late compared to other code analysis
       tools, and some optimizations have already been applied to the
       code.  In particular function inlining may have occurred, leading
       to the interprocedural execution paths emitted by the analyzer
--- 9986,10010 ----
  
       The diagnostics that terminate analysis along a path are:
  
!         • ‘-Wanalyzer-null-argument’
!         • ‘-Wanalyzer-null-dereference’
!         • ‘-Wanalyzer-use-after-free’
!         • ‘-Wanalyzer-use-of-pointer-in-stale-stack-frame’
!         • ‘-Wanalyzer-use-of-uninitialized-value’
  
!      With ‘-fno-analyzer-suppress-followups’ the analyzer will continue
       to explore such paths even after such diagnostics, which may be
       helpful for debugging issues in the analyzer, or for
       microbenchmarks for detecting undefined behavior.
  
! ‘-fanalyzer-transitivity’
       This option enables transitivity of constraints within the
       analyzer.
  
! ‘-fno-analyzer-undo-inlining’
       This option is intended for analyzer developers.
  
!      ‘-fanalyzer’ runs relatively late compared to other code analysis
       tools, and some optimizations have already been applied to the
       code.  In particular function inlining may have occurred, leading
       to the interprocedural execution paths emitted by the analyzer
*************** special meaning to the analyzer, describ
*** 10010,10120 ****
       By default the analyzer attempts to reconstruct the original
       function frames, and to emit events showing the inlined calls.
  
!      With '-fno-analyzer-undo-inlining' this attempt to reconstruct the
       original frame information can be be disabled, which may be of help
       when debugging issues in the analyzer.
  
! '-fanalyzer-verbose-edges'
       This option is intended for analyzer developers.  It enables more
       verbose, lower-level detail in the descriptions of control flow
       within diagnostic paths.
  
! '-fanalyzer-verbose-state-changes'
       This option is intended for analyzer developers.  It enables more
       verbose, lower-level detail in the descriptions of events relating
       to state machines within diagnostic paths.
  
! '-fanalyzer-verbosity=LEVEL'
       This option controls the complexity of the control flow paths that
       are emitted for analyzer diagnostics.
  
       The LEVEL can be one of:
  
!      '0'
            At this level, interprocedural call and return events are
            displayed, along with the most pertinent state-change events
!           relating to a diagnostic.  For example, for a double-'free'
!           diagnostic, both calls to 'free' will be shown.
  
!      '1'
            As per the previous level, but also show events for the entry
            to each function.
  
!      '2'
            As per the previous level, but also show events relating to
            control flow that are significant to triggering the issue
            (e.g.  "true path taken" at a conditional).
  
            This level is the default.
  
!      '3'
            As per the previous level, but show all control flow events,
            not just significant ones.
  
!      '4'
            This level is intended for analyzer developers; it adds
            various other events intended for debugging the analyzer.
  
! '-fdump-analyzer'
       Dump internal details about what the analyzer is doing to
!      'FILE.analyzer.txt'.  '-fdump-analyzer-stderr' overrides this
       option.
  
! '-fdump-analyzer-stderr'
       Dump internal details about what the analyzer is doing to stderr.
!      This option overrides '-fdump-analyzer'.
  
! '-fdump-analyzer-callgraph'
       Dump a representation of the call graph suitable for viewing with
!      GraphViz to 'FILE.callgraph.dot'.
  
! '-fdump-analyzer-exploded-graph'
       Dump a representation of the "exploded graph" suitable for viewing
!      with GraphViz to 'FILE.eg.dot'.  Nodes are color-coded based on
       state-machine states to emphasize state changes.
  
! '-fdump-analyzer-exploded-nodes'
       Emit diagnostics showing where nodes in the "exploded graph" are in
       relation to the program source.
  
! '-fdump-analyzer-exploded-nodes-2'
       Dump a textual representation of the "exploded graph" to
!      'FILE.eg.txt'.
  
! '-fdump-analyzer-exploded-nodes-3'
       Dump a textual representation of the "exploded graph" to one dump
!      file per node, to 'FILE.eg-ID.txt'.  This is typically a large
       number of dump files.
  
! '-fdump-analyzer-exploded-paths'
       Dump a textual representation of the "exploded path" for each
!      diagnostic to 'FILE.IDX.KIND.epath.txt'.
  
! '-fdump-analyzer-feasibility'
       Dump internal details about the analyzer's search for feasible
       paths.  The details are written in a form suitable for viewing with
!      GraphViz to filenames of the form 'FILE.*.fg.dot', 'FILE.*.tg.dot',
!      and 'FILE.*.fpath.txt'.
  
! '-fdump-analyzer-json'
       Dump a compressed JSON representation of analyzer internals to
!      'FILE.analyzer.json.gz'.  The precise format is subject to change.
  
! '-fdump-analyzer-state-purge'
!      As per '-fdump-analyzer-supergraph', dump a representation of the
       "supergraph" suitable for viewing with GraphViz, but annotate the
       graph with information on what state will be purged at each node.
!      The graph is written to 'FILE.state-purge.dot'.
  
! '-fdump-analyzer-supergraph'
       Dump representations of the "supergraph" suitable for viewing with
!      GraphViz to 'FILE.supergraph.dot' and to 'FILE.supergraph-eg.dot'.
       These show all of the control flow graphs in the program, with
       interprocedural edges for calls and returns.  The second dump
       contains annotations showing nodes in the "exploded graph" and
       diagnostics associated with them.
  
! '-fdump-analyzer-untracked'
       Emit custom warnings with internal details intended for analyzer
       developers.
  
--- 10014,10124 ----
       By default the analyzer attempts to reconstruct the original
       function frames, and to emit events showing the inlined calls.
  
!      With ‘-fno-analyzer-undo-inlining’ this attempt to reconstruct the
       original frame information can be be disabled, which may be of help
       when debugging issues in the analyzer.
  
! ‘-fanalyzer-verbose-edges’
       This option is intended for analyzer developers.  It enables more
       verbose, lower-level detail in the descriptions of control flow
       within diagnostic paths.
  
! ‘-fanalyzer-verbose-state-changes’
       This option is intended for analyzer developers.  It enables more
       verbose, lower-level detail in the descriptions of events relating
       to state machines within diagnostic paths.
  
! ‘-fanalyzer-verbosity=LEVEL’
       This option controls the complexity of the control flow paths that
       are emitted for analyzer diagnostics.
  
       The LEVEL can be one of:
  
!      ‘0’
            At this level, interprocedural call and return events are
            displayed, along with the most pertinent state-change events
!           relating to a diagnostic.  For example, for a double-‘free’
!           diagnostic, both calls to ‘free’ will be shown.
  
!      ‘1’
            As per the previous level, but also show events for the entry
            to each function.
  
!      ‘2’
            As per the previous level, but also show events relating to
            control flow that are significant to triggering the issue
            (e.g.  "true path taken" at a conditional).
  
            This level is the default.
  
!      ‘3’
            As per the previous level, but show all control flow events,
            not just significant ones.
  
!      ‘4’
            This level is intended for analyzer developers; it adds
            various other events intended for debugging the analyzer.
  
! ‘-fdump-analyzer’
       Dump internal details about what the analyzer is doing to
!      ‘FILE.analyzer.txt’.  ‘-fdump-analyzer-stderr’ overrides this
       option.
  
! ‘-fdump-analyzer-stderr’
       Dump internal details about what the analyzer is doing to stderr.
!      This option overrides ‘-fdump-analyzer’.
  
! ‘-fdump-analyzer-callgraph’
       Dump a representation of the call graph suitable for viewing with
!      GraphViz to ‘FILE.callgraph.dot’.
  
! ‘-fdump-analyzer-exploded-graph’
       Dump a representation of the "exploded graph" suitable for viewing
!      with GraphViz to ‘FILE.eg.dot’.  Nodes are color-coded based on
       state-machine states to emphasize state changes.
  
! ‘-fdump-analyzer-exploded-nodes’
       Emit diagnostics showing where nodes in the "exploded graph" are in
       relation to the program source.
  
! ‘-fdump-analyzer-exploded-nodes-2’
       Dump a textual representation of the "exploded graph" to
!      ‘FILE.eg.txt’.
  
! ‘-fdump-analyzer-exploded-nodes-3’
       Dump a textual representation of the "exploded graph" to one dump
!      file per node, to ‘FILE.eg-ID.txt’.  This is typically a large
       number of dump files.
  
! ‘-fdump-analyzer-exploded-paths’
       Dump a textual representation of the "exploded path" for each
!      diagnostic to ‘FILE.IDX.KIND.epath.txt’.
  
! ‘-fdump-analyzer-feasibility’
       Dump internal details about the analyzer's search for feasible
       paths.  The details are written in a form suitable for viewing with
!      GraphViz to filenames of the form ‘FILE.*.fg.dot’, ‘FILE.*.tg.dot’,
!      and ‘FILE.*.fpath.txt’.
  
! ‘-fdump-analyzer-json’
       Dump a compressed JSON representation of analyzer internals to
!      ‘FILE.analyzer.json.gz’.  The precise format is subject to change.
  
! ‘-fdump-analyzer-state-purge’
!      As per ‘-fdump-analyzer-supergraph’, dump a representation of the
       "supergraph" suitable for viewing with GraphViz, but annotate the
       graph with information on what state will be purged at each node.
!      The graph is written to ‘FILE.state-purge.dot’.
  
! ‘-fdump-analyzer-supergraph’
       Dump representations of the "supergraph" suitable for viewing with
!      GraphViz to ‘FILE.supergraph.dot’ and to ‘FILE.supergraph-eg.dot’.
       These show all of the control flow graphs in the program, with
       interprocedural edges for calls and returns.  The second dump
       contains annotations showing nodes in the "exploded graph" and
       diagnostics associated with them.
  
! ‘-fdump-analyzer-untracked’
       Emit custom warnings with internal details intended for analyzer
       developers.
  
*************** File: gcc.info,  Node: Debugging Options
*** 10125,10136 ****
  =======================================
  
  To tell GCC to emit extra information for use by a debugger, in almost
! all cases you need only to add '-g' to your other options.  Some debug
  formats can co-exist (like DWARF with CTF) when each of them is enabled
  explicitly by adding the respective command line option to your other
  options.
  
!  GCC allows you to use '-g' with '-O'.  The shortcuts taken by optimized
  code may occasionally be surprising: 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
--- 10129,10140 ----
  =======================================
  
  To tell GCC to emit extra information for use by a debugger, in almost
! all cases you need only to add ‘-g’ to your other options.  Some debug
  formats can co-exist (like DWARF with CTF) when each of them is enabled
  explicitly by adding the respective command line option to your other
  options.
  
!  GCC allows you to use ‘-g’ with ‘-O’.  The shortcuts taken by optimized
  code may occasionally be surprising: 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
*************** Nevertheless it is possible to debug opt
*** 10140,10170 ****
  reasonable to use the optimizer for programs that might have bugs.
  
   If you are not using some other optimization option, consider using
! '-Og' (*note Optimize Options::) with '-g'.  With no '-O' option at all,
  some compiler passes that collect information useful for debugging do
! not run at all, so that '-Og' may result in a better debugging
  experience.
  
! '-g'
       Produce debugging information in the operating system's native
       format (stabs, COFF, XCOFF, or DWARF).  GDB can work with this
       debugging information.
  
!      On most systems that use stabs format, '-g' enables use of extra
       debugging information that only GDB can use; this extra information
       makes debugging work better in GDB but probably makes other
       debuggers crash or refuse to read the program.  If you want to
       control for certain whether to generate the extra information, use
!      '-gvms' (see below).
  
! '-ggdb'
       Produce debugging information for use by GDB.  This means to use
       the most expressive format available (DWARF, stabs, or the native
       format if neither of those are supported), including GDB extensions
       if at all possible.
  
! '-gdwarf'
! '-gdwarf-VERSION'
       Produce debugging information in DWARF format (if that is
       supported).  The value of VERSION may be either 2, 3, 4 or 5; the
       default version for most targets is 5 (with the exception of
--- 10144,10174 ----
  reasonable to use the optimizer for programs that might have bugs.
  
   If you are not using some other optimization option, consider using
! ‘-Og’ (*note Optimize Options::) with ‘-g’.  With no ‘-O’ option at all,
  some compiler passes that collect information useful for debugging do
! not run at all, so that ‘-Og’ may result in a better debugging
  experience.
  
! ‘-g’
       Produce debugging information in the operating system's native
       format (stabs, COFF, XCOFF, or DWARF).  GDB can work with this
       debugging information.
  
!      On most systems that use stabs format, ‘-g’ enables use of extra
       debugging information that only GDB can use; this extra information
       makes debugging work better in GDB but probably makes other
       debuggers crash or refuse to read the program.  If you want to
       control for certain whether to generate the extra information, use
!      ‘-gvms’ (see below).
  
! ‘-ggdb’
       Produce debugging information for use by GDB.  This means to use
       the most expressive format available (DWARF, stabs, or the native
       format if neither of those are supported), including GDB extensions
       if at all possible.
  
! ‘-gdwarf’
! ‘-gdwarf-VERSION’
       Produce debugging information in DWARF format (if that is
       supported).  The value of VERSION may be either 2, 3, 4 or 5; the
       default version for most targets is 5 (with the exception of
*************** experience.
*** 10174,10199 ****
       Note that with DWARF Version 2, some ports require and always use
       some non-conflicting DWARF 3 extensions in the unwind tables.
  
!      Version 4 may require GDB 7.0 and '-fvar-tracking-assignments' for
       maximum benefit.  Version 5 requires GDB 8.0 or higher.
  
       GCC no longer supports DWARF Version 1, which is substantially
       different than Version 2 and later.  For historical reasons, some
!      other DWARF-related options such as '-fno-dwarf2-cfi-asm') retain a
       reference to DWARF Version 2 in their names, but apply to all
       currently-supported versions of DWARF.
  
! '-gbtf'
       Request BTF debug information.  BTF is the default debugging format
       for the eBPF target.  On other targets, like x86, BTF debug
       information can be generated along with DWARF debug information
       when both of the debug formats are enabled explicitly via their
       respective command line options.
  
! '-gctf'
! '-gctfLEVEL'
       Request CTF debug information and use level to specify how much CTF
!      debug information should be produced.  If '-gctf' is specified
       without a value for level, the default level of CTF debug
       information is 2.
  
--- 10178,10203 ----
       Note that with DWARF Version 2, some ports require and always use
       some non-conflicting DWARF 3 extensions in the unwind tables.
  
!      Version 4 may require GDB 7.0 and ‘-fvar-tracking-assignments’ for
       maximum benefit.  Version 5 requires GDB 8.0 or higher.
  
       GCC no longer supports DWARF Version 1, which is substantially
       different than Version 2 and later.  For historical reasons, some
!      other DWARF-related options such as ‘-fno-dwarf2-cfi-asm’) retain a
       reference to DWARF Version 2 in their names, but apply to all
       currently-supported versions of DWARF.
  
! ‘-gbtf’
       Request BTF debug information.  BTF is the default debugging format
       for the eBPF target.  On other targets, like x86, BTF debug
       information can be generated along with DWARF debug information
       when both of the debug formats are enabled explicitly via their
       respective command line options.
  
! ‘-gctf’
! ‘-gctfLEVEL’
       Request CTF debug information and use level to specify how much CTF
!      debug information should be produced.  If ‘-gctf’ is specified
       without a value for level, the default level of CTF debug
       information is 2.
  
*************** experience.
*** 10201,10208 ****
       information when both of the debug formats are enabled explicitly
       via their respective command line options.
  
!      Level 0 produces no CTF debug information at all.  Thus, '-gctf0'
!      negates '-gctf'.
  
       Level 1 produces CTF information for tracebacks only.  This
       includes callsite information, but does not include type
--- 10205,10212 ----
       information when both of the debug formats are enabled explicitly
       via their respective command line options.
  
!      Level 0 produces no CTF debug information at all.  Thus, ‘-gctf0’
!      negates ‘-gctf’.
  
       Level 1 produces CTF information for tracebacks only.  This
       includes callsite information, but does not include type
*************** experience.
*** 10211,10228 ****
       Level 2 produces type information for entities (functions, data
       objects etc.)  at file-scope or global-scope only.
  
! '-gvms'
       Produce debugging information in Alpha/VMS debug format (if that is
       supported).  This is the format used by DEBUG on Alpha/VMS systems.
  
! '-gLEVEL'
! '-ggdbLEVEL'
! '-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
--- 10215,10232 ----
       Level 2 produces type information for entities (functions, data
       objects etc.)  at file-scope or global-scope only.
  
! ‘-gvms’
       Produce debugging information in Alpha/VMS debug format (if that is
       supported).  This is the format used by DEBUG on Alpha/VMS systems.
  
! ‘-gLEVEL’
! ‘-ggdbLEVEL’
! ‘-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
*************** experience.
*** 10231,10251 ****
  
       Level 3 includes extra information, such as all the macro
       definitions present in the program.  Some debuggers support macro
!      expansion when you use '-g3'.
  
!      If you use multiple '-g' options, with or without level numbers,
       the last such option is the one that is effective.
  
!      '-gdwarf' does not accept a concatenated debug level, to avoid
!      confusion with '-gdwarf-LEVEL'.  Instead use an additional
!      '-gLEVEL' option to change the debug level for DWARF.
  
! '-fno-eliminate-unused-debug-symbols'
       By default, no debug information is produced for symbols that are
       not actually used.  Use this option if you want debug information
       for all symbols.
  
! '-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
--- 10235,10255 ----
  
       Level 3 includes extra information, such as all the macro
       definitions present in the program.  Some debuggers support macro
!      expansion when you use ‘-g3’.
  
!      If you use multiple ‘-g’ options, with or without level numbers,
       the last such option is the one that is effective.
  
!      ‘-gdwarf’ does not accept a concatenated debug level, to avoid
!      confusion with ‘-gdwarf-LEVEL’.  Instead use an additional
!      ‘-gLEVEL’ option to change the debug level for DWARF.
  
! ‘-fno-eliminate-unused-debug-symbols’
       By default, no debug information is produced for symbols that are
       not actually used.  Use this option if you want debug information
       for all symbols.
  
! ‘-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
*************** experience.
*** 10253,10359 ****
       because using this option increases the size of debugging
       information by as much as a factor of two.
  
! '-fno-merge-debug-strings'
       Direct the linker to not merge together strings in the debugging
       information that are identical in different object files.  Merging
       is not supported by all assemblers or linkers.  Merging decreases
       the size of the debug information in the output file at the cost of
       increasing link processing time.  Merging is enabled by default.
  
! '-fdebug-prefix-map=OLD=NEW'
!      When compiling files residing in directory 'OLD', record debugging
       information describing them as if the files resided in directory
!      'NEW' instead.  This can be used to replace a build-time path with
       an install-time path in the debug info.  It can also be used to
!      change an absolute path to a relative path by using '.' for NEW.
       This can give more reproducible builds, which are location
       independent, but may require an extra command to tell GDB where to
!      find the source files.  See also '-ffile-prefix-map' and
!      '-fcanon-prefix-map'.
  
! '-fvar-tracking'
       Run variable tracking pass.  It computes where variables are stored
       at each position in code.  Better debugging information is then
       generated (if the debugging information format supports this
       information).
  
!      It is enabled by default when compiling with optimization ('-Os',
!      '-O', '-O2', ...), debugging information ('-g') and the debug info
       format supports it.
  
! '-fvar-tracking-assignments'
       Annotate assignments to user variables early in the compilation and
       attempt to carry the annotations over throughout the compilation
       all the way to the end, in an attempt to improve debug information
!      while optimizing.  Use of '-gdwarf-4' is recommended along with it.
  
       It can be enabled even if var-tracking is disabled, in which case
       annotations are created and maintained, but discarded at the end.
!      By default, this flag is enabled together with '-fvar-tracking',
       except when selective scheduling is enabled.
  
! '-gsplit-dwarf'
       If DWARF debugging information is enabled, separate as much
       debugging information as possible into a separate output file with
!      the extension '.dwo'.  This option allows the build system to avoid
       linking files with debug information.  To be useful, this option
!      requires a debugger capable of reading '.dwo' files.
  
! '-gdwarf32'
! '-gdwarf64'
!      If DWARF debugging information is enabled, the '-gdwarf32' selects
!      the 32-bit DWARF format and the '-gdwarf64' selects the 64-bit
       DWARF format.  The default is target specific, on most targets it
!      is '-gdwarf32' though.  The 32-bit DWARF format is smaller, but
       can't support more than 2GiB of debug information in any of the
       DWARF debug information sections.  The 64-bit DWARF format allows
       larger debug information and might not be well supported by all
       consumers yet.
  
! '-gdescribe-dies'
       Add description attributes to some DWARF DIEs that have no name
       attribute, such as artificial variables, external references and
       call site parameter DIEs.
  
! '-gpubnames'
!      Generate DWARF '.debug_pubnames' and '.debug_pubtypes' sections.
  
! '-ggnu-pubnames'
!      Generate '.debug_pubnames' and '.debug_pubtypes' sections in a
       format suitable for conversion into a GDB index.  This option is
       only useful with a linker that can produce GDB index version 7.
  
! '-fdebug-types-section'
       When using DWARF Version 4 or higher, type DIEs can be put into
!      their own '.debug_types' section instead of making them part of the
!      '.debug_info' section.  It is more efficient to put them in a
       separate comdat section since the linker can then remove
!      duplicates.  But not all DWARF consumers support '.debug_types'
!      sections yet and on some objects '.debug_types' produces larger
       instead of smaller debugging information.
  
! '-grecord-gcc-switches'
! '-gno-record-gcc-switches'
       This switch causes the command-line options used to invoke the
       compiler that may affect code generation to be appended to the
       DW_AT_producer attribute in DWARF debugging information.  The
       options are concatenated with spaces separating them from each
       other and from the compiler version.  It is enabled by default.
!      See also '-frecord-gcc-switches' for another way of storing
       compiler options into the object file.
  
! '-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'.
  
! '-gas-loc-support'
!      Inform the compiler that the assembler supports '.loc' directives.
       It may then use them for the assembler to generate DWARF2+ line
       number tables.
  
--- 10257,10363 ----
       because using this option increases the size of debugging
       information by as much as a factor of two.
  
! ‘-fno-merge-debug-strings’
       Direct the linker to not merge together strings in the debugging
       information that are identical in different object files.  Merging
       is not supported by all assemblers or linkers.  Merging decreases
       the size of the debug information in the output file at the cost of
       increasing link processing time.  Merging is enabled by default.
  
! ‘-fdebug-prefix-map=OLD=NEW’
!      When compiling files residing in directory ‘OLD’, record debugging
       information describing them as if the files resided in directory
!      ‘NEW’ instead.  This can be used to replace a build-time path with
       an install-time path in the debug info.  It can also be used to
!      change an absolute path to a relative path by using ‘.’ for NEW.
       This can give more reproducible builds, which are location
       independent, but may require an extra command to tell GDB where to
!      find the source files.  See also ‘-ffile-prefix-map’ and
!      ‘-fcanon-prefix-map’.
  
! ‘-fvar-tracking’
       Run variable tracking pass.  It computes where variables are stored
       at each position in code.  Better debugging information is then
       generated (if the debugging information format supports this
       information).
  
!      It is enabled by default when compiling with optimization (‘-Os’,
!      ‘-O’, ‘-O2’, ...), debugging information (‘-g’) and the debug info
       format supports it.
  
! ‘-fvar-tracking-assignments’
       Annotate assignments to user variables early in the compilation and
       attempt to carry the annotations over throughout the compilation
       all the way to the end, in an attempt to improve debug information
!      while optimizing.  Use of ‘-gdwarf-4’ is recommended along with it.
  
       It can be enabled even if var-tracking is disabled, in which case
       annotations are created and maintained, but discarded at the end.
!      By default, this flag is enabled together with ‘-fvar-tracking’,
       except when selective scheduling is enabled.
  
! ‘-gsplit-dwarf’
       If DWARF debugging information is enabled, separate as much
       debugging information as possible into a separate output file with
!      the extension ‘.dwo’.  This option allows the build system to avoid
       linking files with debug information.  To be useful, this option
!      requires a debugger capable of reading ‘.dwo’ files.
  
! ‘-gdwarf32’
! ‘-gdwarf64’
!      If DWARF debugging information is enabled, the ‘-gdwarf32’ selects
!      the 32-bit DWARF format and the ‘-gdwarf64’ selects the 64-bit
       DWARF format.  The default is target specific, on most targets it
!      is ‘-gdwarf32’ though.  The 32-bit DWARF format is smaller, but
       can't support more than 2GiB of debug information in any of the
       DWARF debug information sections.  The 64-bit DWARF format allows
       larger debug information and might not be well supported by all
       consumers yet.
  
! ‘-gdescribe-dies’
       Add description attributes to some DWARF DIEs that have no name
       attribute, such as artificial variables, external references and
       call site parameter DIEs.
  
! ‘-gpubnames’
!      Generate DWARF ‘.debug_pubnames’ and ‘.debug_pubtypes’ sections.
  
! ‘-ggnu-pubnames’
!      Generate ‘.debug_pubnames’ and ‘.debug_pubtypes’ sections in a
       format suitable for conversion into a GDB index.  This option is
       only useful with a linker that can produce GDB index version 7.
  
! ‘-fdebug-types-section’
       When using DWARF Version 4 or higher, type DIEs can be put into
!      their own ‘.debug_types’ section instead of making them part of the
!      ‘.debug_info’ section.  It is more efficient to put them in a
       separate comdat section since the linker can then remove
!      duplicates.  But not all DWARF consumers support ‘.debug_types’
!      sections yet and on some objects ‘.debug_types’ produces larger
       instead of smaller debugging information.
  
! ‘-grecord-gcc-switches’
! ‘-gno-record-gcc-switches’
       This switch causes the command-line options used to invoke the
       compiler that may affect code generation to be appended to the
       DW_AT_producer attribute in DWARF debugging information.  The
       options are concatenated with spaces separating them from each
       other and from the compiler version.  It is enabled by default.
!      See also ‘-frecord-gcc-switches’ for another way of storing
       compiler options into the object file.
  
! ‘-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’.
  
! ‘-gas-loc-support’
!      Inform the compiler that the assembler supports ‘.loc’ directives.
       It may then use them for the assembler to generate DWARF2+ line
       number tables.
  
*************** experience.
*** 10364,10402 ****
       This option will be enabled by default if, at GCC configure time,
       the assembler was found to support such directives.
  
! '-gno-as-loc-support'
       Force GCC to generate DWARF2+ line number tables internally, if
       DWARF2+ line number tables are to be generated.
  
! '-gas-locview-support'
!      Inform the compiler that the assembler supports 'view' assignment
!      and reset assertion checking in '.loc' directives.
  
       This option will be enabled by default if, at GCC configure time,
       the assembler was found to support them.
  
! '-gno-as-locview-support'
       Force GCC to assign view numbers internally, if
!      '-gvariable-location-views' are explicitly requested.
  
! '-gcolumn-info'
! '-gno-column-info'
       Emit location column information into DWARF debugging information,
       rather than just file and line.  This option is enabled by default.
  
! '-gstatement-frontiers'
! '-gno-statement-frontiers'
       This option causes GCC to create markers in the internal
       representation at the beginning of statements, and to keep them
       roughly in place throughout compilation, using them to guide the
!      output of 'is_stmt' markers in the line number table.  This is
!      enabled by default when compiling with optimization ('-Os', '-O1',
!      '-O2', ...), and outputting DWARF 2 debug information at the normal
       level.
  
! '-gvariable-location-views'
! '-gvariable-location-views=incompat5'
! '-gno-variable-location-views'
       Augment variable location lists with progressive view numbers
       implied from the line number table.  This enables debug information
       consumers to inspect state at certain points of the program, even
--- 10368,10406 ----
       This option will be enabled by default if, at GCC configure time,
       the assembler was found to support such directives.
  
! ‘-gno-as-loc-support’
       Force GCC to generate DWARF2+ line number tables internally, if
       DWARF2+ line number tables are to be generated.
  
! ‘-gas-locview-support’
!      Inform the compiler that the assembler supports ‘view’ assignment
!      and reset assertion checking in ‘.loc’ directives.
  
       This option will be enabled by default if, at GCC configure time,
       the assembler was found to support them.
  
! ‘-gno-as-locview-support’
       Force GCC to assign view numbers internally, if
!      ‘-gvariable-location-views’ are explicitly requested.
  
! ‘-gcolumn-info’
! ‘-gno-column-info’
       Emit location column information into DWARF debugging information,
       rather than just file and line.  This option is enabled by default.
  
! ‘-gstatement-frontiers’
! ‘-gno-statement-frontiers’
       This option causes GCC to create markers in the internal
       representation at the beginning of statements, and to keep them
       roughly in place throughout compilation, using them to guide the
!      output of ‘is_stmt’ markers in the line number table.  This is
!      enabled by default when compiling with optimization (‘-Os’, ‘-O1’,
!      ‘-O2’, ...), and outputting DWARF 2 debug information at the normal
       level.
  
! ‘-gvariable-location-views’
! ‘-gvariable-location-views=incompat5’
! ‘-gno-variable-location-views’
       Augment variable location lists with progressive view numbers
       implied from the line number table.  This enables debug information
       consumers to inspect state at certain points of the program, even
*************** experience.
*** 10411,10445 ****
  
       This is enabled by default when outputting DWARF 2 debug
       information at the normal level, as long as there is assembler
!      support, '-fvar-tracking-assignments' is enabled and
!      '-gstrict-dwarf' is not.  When assembler support is not available,
       this may still be enabled, but it will force GCC to output internal
!      line number tables, and if '-ginternal-reset-location-views' is not
       enabled, that will most certainly lead to silently mismatching
       location views.
  
       There is a proposed representation for view numbers that is not
       backward compatible with the location list format introduced in
       DWARF 5, that can be enabled with
!      '-gvariable-location-views=incompat5'.  This option may be removed
       in the future, is only provided as a reference implementation of
       the proposed representation.  Debug information consumers are not
       expected to support this extended format, and they would be
       rendered unable to decode location lists using it.
  
! '-ginternal-reset-location-views'
! '-gno-internal-reset-location-views'
       Attempt to determine location views that can be omitted from
       location view lists.  This requires the compiler to have very
       accurate insn length estimates, which isn't always the case, and it
       may cause incorrect view lists to be generated silently when using
       an assembler that does not support location view lists.  The GNU
!      assembler will flag any such error as a 'view number mismatch'.
       This is only enabled on ports that define a reliable estimation
       function.
  
! '-ginline-points'
! '-gno-inline-points'
       Generate extended debug information for inlined functions.
       Location view tracking markers are inserted at inlined entry
       points, so that address and view numbers can be computed and output
--- 10415,10449 ----
  
       This is enabled by default when outputting DWARF 2 debug
       information at the normal level, as long as there is assembler
!      support, ‘-fvar-tracking-assignments’ is enabled and
!      ‘-gstrict-dwarf’ is not.  When assembler support is not available,
       this may still be enabled, but it will force GCC to output internal
!      line number tables, and if ‘-ginternal-reset-location-views’ is not
       enabled, that will most certainly lead to silently mismatching
       location views.
  
       There is a proposed representation for view numbers that is not
       backward compatible with the location list format introduced in
       DWARF 5, that can be enabled with
!      ‘-gvariable-location-views=incompat5’.  This option may be removed
       in the future, is only provided as a reference implementation of
       the proposed representation.  Debug information consumers are not
       expected to support this extended format, and they would be
       rendered unable to decode location lists using it.
  
! ‘-ginternal-reset-location-views’
! ‘-gno-internal-reset-location-views’
       Attempt to determine location views that can be omitted from
       location view lists.  This requires the compiler to have very
       accurate insn length estimates, which isn't always the case, and it
       may cause incorrect view lists to be generated silently when using
       an assembler that does not support location view lists.  The GNU
!      assembler will flag any such error as a ‘view number mismatch’.
       This is only enabled on ports that define a reliable estimation
       function.
  
! ‘-ginline-points’
! ‘-gno-inline-points’
       Generate extended debug information for inlined functions.
       Location view tracking markers are inserted at inlined entry
       points, so that address and view numbers can be computed and output
*************** experience.
*** 10448,10477 ****
       it can only be enabled along with statement frontiers, and it is
       only enabled by default if location views are enabled.
  
! '-gz[=TYPE]'
       Produce compressed debug sections in DWARF format, if that is
       supported.  If TYPE is not given, the default type depends on the
       capabilities of the assembler and linker used.  TYPE may be one of
!      'none' (don't compress debug sections), or 'zlib' (use zlib
       compression in ELF gABI format).  If the linker doesn't support
       writing compressed debug sections, the option is rejected.
!      Otherwise, if the assembler does not support them, '-gz' is
       silently ignored when producing object files.
  
! '-femit-struct-debug-baseonly'
       Emit debug information for struct-like types only when the base
       name of the compilation source file matches the base name of file
       in which the struct is defined.
  
       This option substantially reduces the size of debugging
       information, but at significant potential loss in type information
!      to the debugger.  See '-femit-struct-debug-reduced' for a less
!      aggressive option.  See '-femit-struct-debug-detailed' for more
       detailed control.
  
       This option works only with DWARF debug output.
  
! '-femit-struct-debug-reduced'
       Emit debug information for struct-like types only when the base
       name of the compilation source file matches the base name of file
       in which the type is defined, unless the struct is a template or
--- 10452,10481 ----
       it can only be enabled along with statement frontiers, and it is
       only enabled by default if location views are enabled.
  
! ‘-gz[=TYPE]’
       Produce compressed debug sections in DWARF format, if that is
       supported.  If TYPE is not given, the default type depends on the
       capabilities of the assembler and linker used.  TYPE may be one of
!      ‘none’ (don't compress debug sections), or ‘zlib’ (use zlib
       compression in ELF gABI format).  If the linker doesn't support
       writing compressed debug sections, the option is rejected.
!      Otherwise, if the assembler does not support them, ‘-gz’ is
       silently ignored when producing object files.
  
! ‘-femit-struct-debug-baseonly’
       Emit debug information for struct-like types only when the base
       name of the compilation source file matches the base name of file
       in which the struct is defined.
  
       This option substantially reduces the size of debugging
       information, but at significant potential loss in type information
!      to the debugger.  See ‘-femit-struct-debug-reduced’ for a less
!      aggressive option.  See ‘-femit-struct-debug-detailed’ for more
       detailed control.
  
       This option works only with DWARF debug output.
  
! ‘-femit-struct-debug-reduced’
       Emit debug information for struct-like types only when the base
       name of the compilation source file matches the base name of file
       in which the type is defined, unless the struct is a template or
*************** experience.
*** 10479,10537 ****
  
       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 debug output.
  
! '-femit-struct-debug-detailed[=SPEC-LIST]'
       Specify the struct-like types for which the compiler generates
       debug information.  The intent is to reduce duplicate struct debug
       information between different object files within the same program.
  
!      This option is a detailed version of '-femit-struct-debug-reduced'
!      and '-femit-struct-debug-baseonly', which serves for most needs.
  
       A specification has the syntax
!      ['dir:'|'ind:']['ord:'|'gen:']('any'|'sys'|'base'|'none')
  
       The optional first word limits the specification to structs that
!      are used directly ('dir:') or used indirectly ('ind:').  A struct
       type is used directly when it is the type of a variable, member.
       Indirect uses arise through pointers to structs.  That is, when use
       of an incomplete struct is valid, the use is indirect.  An example
!      is 'struct one direct; struct two * indirect;'.
  
       The optional second word limits the specification to ordinary
!      structs ('ord:') or generic structs ('gen:').  Generic structs are
       a bit complicated to explain.  For C++, these are non-explicit
       specializations of template classes, or non-template classes within
       the above.  Other programming languages have generics, but
!      '-femit-struct-debug-detailed' does not yet implement them.
  
       The third word specifies the source files for those structs for
       which the compiler should emit debug information.  The values
!      'none' and 'any' have the normal meaning.  The value 'base' means
       that the base of name of the file in which the type declaration
       appears must match the base of the name of the main compilation
!      file.  In practice, this means that when compiling 'foo.c', debug
       information is generated for types declared in that file and
!      'foo.h', but not other header files.  The value 'sys' means those
!      types satisfying 'base' or declared in system or compiler headers.
  
       You may need to experiment to determine the best settings for your
       application.
  
!      The default is '-femit-struct-debug-detailed=all'.
  
       This option works only with DWARF debug output.
  
! '-fno-dwarf2-cfi-asm'
!      Emit DWARF unwind info as compiler generated '.eh_frame' section
!      instead of using GAS '.cfi_*' directives.
  
! '-fno-eliminate-unused-debug-types'
       Normally, when producing DWARF output, GCC avoids producing debug
       symbol output for types that are nowhere used in the source file
       being compiled.  Sometimes it is useful to have GCC emit debugging
--- 10483,10541 ----
  
       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 debug output.
  
! ‘-femit-struct-debug-detailed[=SPEC-LIST]’
       Specify the struct-like types for which the compiler generates
       debug information.  The intent is to reduce duplicate struct debug
       information between different object files within the same program.
  
!      This option is a detailed version of ‘-femit-struct-debug-reduced’
!      and ‘-femit-struct-debug-baseonly’, which serves for most needs.
  
       A specification has the syntax
!      [‘dir:’|‘ind:’][‘ord:’|‘gen:’](‘any’|‘sys’|‘base’|‘none’)
  
       The optional first word limits the specification to structs that
!      are used directly (‘dir:’) or used indirectly (‘ind:’).  A struct
       type is used directly when it is the type of a variable, member.
       Indirect uses arise through pointers to structs.  That is, when use
       of an incomplete struct is valid, the use is indirect.  An example
!      is ‘struct one direct; struct two * indirect;’.
  
       The optional second word limits the specification to ordinary
!      structs (‘ord:’) or generic structs (‘gen:’).  Generic structs are
       a bit complicated to explain.  For C++, these are non-explicit
       specializations of template classes, or non-template classes within
       the above.  Other programming languages have generics, but
!      ‘-femit-struct-debug-detailed’ does not yet implement them.
  
       The third word specifies the source files for those structs for
       which the compiler should emit debug information.  The values
!      ‘none’ and ‘any’ have the normal meaning.  The value ‘base’ means
       that the base of name of the file in which the type declaration
       appears must match the base of the name of the main compilation
!      file.  In practice, this means that when compiling ‘foo.c’, debug
       information is generated for types declared in that file and
!      ‘foo.h’, but not other header files.  The value ‘sys’ means those
!      types satisfying ‘base’ or declared in system or compiler headers.
  
       You may need to experiment to determine the best settings for your
       application.
  
!      The default is ‘-femit-struct-debug-detailed=all’.
  
       This option works only with DWARF debug output.
  
! ‘-fno-dwarf2-cfi-asm’
!      Emit DWARF unwind info as compiler generated ‘.eh_frame’ section
!      instead of using GAS ‘.cfi_*’ directives.
  
! ‘-fno-eliminate-unused-debug-types’
       Normally, when producing DWARF output, GCC avoids producing debug
       symbol output for types that are nowhere used in the source file
       being compiled.  Sometimes it is useful to have GCC emit debugging
*************** compiling each of them.
*** 10569,10594 ****
   Not all optimizations are controlled directly by a flag.  Only
  optimizations that have a flag are listed in this section.
  
!  Most optimizations are completely disabled at '-O0' or if an '-O' level
  is not set on the command line, even if individual optimization flags
! are specified.  Similarly, '-Og' suppresses many optimization passes.
  
   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
            -fbranch-count-reg
--- 10573,10598 ----
   Not all optimizations are controlled directly by a flag.  Only
  optimizations that have a flag are listed in this section.
  
!  Most optimizations are completely disabled at ‘-O0’ or if an ‘-O’ level
  is not set on the command line, even if individual optimization flags
! are specified.  Similarly, ‘-Og’ suppresses many optimization passes.
  
   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
            -fbranch-count-reg
*************** find out the exact set of optimizations
*** 10638,10650 ****
            -ftree-ter
            -funit-at-a-time
  
! '-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 '-O1'.  It also
       turns on the following optimization flags:
  
            -falign-functions  -falign-jumps
--- 10642,10654 ----
            -ftree-ter
            -funit-at-a-time
  
! ‘-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 ‘-O1’.  It also
       turns on the following optimization flags:
  
            -falign-functions  -falign-jumps
*************** find out the exact set of optimizations
*** 10686,10697 ****
            -ftree-vrp
            -fvect-cost-model=very-cheap
  
!      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 following optimization flags:
  
            -fgcse-after-reload
            -fipa-cp-clone
--- 10690,10701 ----
            -ftree-vrp
            -fvect-cost-model=very-cheap
  
!      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 following optimization flags:
  
            -fgcse-after-reload
            -fipa-cp-clone
*************** find out the exact set of optimizations
*** 10707,10747 ****
            -fvect-cost-model=dynamic
            -fversion-loops-for-strides
  
! '-O0'
       Reduce compilation time and make debugging produce the expected
       results.  This is the default.
  
! '-Os'
!      Optimize for size.  '-Os' enables all '-O2' optimizations except
       those that often increase code size:
  
            -falign-functions  -falign-jumps
            -falign-labels  -falign-loops
            -fprefetch-loop-arrays  -freorder-blocks-algorithm=stc
  
!      It also enables '-finline-functions', causes the compiler to tune
       for code size rather than execution speed, and performs further
       optimizations designed to reduce code size.
  
! '-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',
!      '-fallow-store-data-races' and the Fortran-specific
!      '-fstack-arrays', unless '-fmax-stack-var-size' is specified, and
!      '-fno-protect-parens'.  It turns off '-fsemantic-interposition'.
  
! '-Og'
!      Optimize debugging experience.  '-Og' should be the optimization
       level of choice for the standard edit-compile-debug cycle, offering
       a reasonable level of optimization while maintaining fast
       compilation and a good debugging experience.  It is a better choice
!      than '-O0' for producing debuggable code because some compiler
!      passes that collect debug information are disabled at '-O0'.
  
!      Like '-O0', '-Og' completely disables a number of optimization
       passes so that individual options controlling them have no effect.
!      Otherwise '-Og' enables all '-O1' optimization flags except for
       those that may interfere with debugging:
  
            -fbranch-count-reg  -fdelayed-branch
--- 10711,10751 ----
            -fvect-cost-model=dynamic
            -fversion-loops-for-strides
  
! ‘-O0’
       Reduce compilation time and make debugging produce the expected
       results.  This is the default.
  
! ‘-Os’
!      Optimize for size.  ‘-Os’ enables all ‘-O2’ optimizations except
       those that often increase code size:
  
            -falign-functions  -falign-jumps
            -falign-labels  -falign-loops
            -fprefetch-loop-arrays  -freorder-blocks-algorithm=stc
  
!      It also enables ‘-finline-functions’, causes the compiler to tune
       for code size rather than execution speed, and performs further
       optimizations designed to reduce code size.
  
! ‘-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’,
!      ‘-fallow-store-data-races’ and the Fortran-specific
!      ‘-fstack-arrays’, unless ‘-fmax-stack-var-size’ is specified, and
!      ‘-fno-protect-parens’.  It turns off ‘-fsemantic-interposition’.
  
! ‘-Og’
!      Optimize debugging experience.  ‘-Og’ should be the optimization
       level of choice for the standard edit-compile-debug cycle, offering
       a reasonable level of optimization while maintaining fast
       compilation and a good debugging experience.  It is a better choice
!      than ‘-O0’ for producing debuggable code because some compiler
!      passes that collect debug information are disabled at ‘-O0’.
  
!      Like ‘-O0’, ‘-Og’ completely disables a number of optimization
       passes so that individual options controlling them have no effect.
!      Otherwise ‘-Og’ enables all ‘-O1’ optimization flags except for
       those that may interfere with debugging:
  
            -fbranch-count-reg  -fdelayed-branch
*************** find out the exact set of optimizations
*** 10750,10803 ****
            -fmove-loop-invariants  -fmove-loop-stores  -fssa-phiopt
            -ftree-bit-ccp  -ftree-dse  -ftree-pta  -ftree-sra
  
! '-Oz'
       Optimize aggressively for size rather than speed.  This may
       increase the number of instructions executed if those instructions
!      require fewer bytes to encode.  '-Oz' behaves similarly to '-Os'
!      including enabling most '-O2' optimizations.
  
!  If you use multiple '-O' options, with or without level numbers, the
  last such option is the one that is effective.
  
!  Options of the form '-fFLAG' specify machine-independent flags.  Most
  flags have both positive and negative forms; the negative form of
! '-ffoo' is '-fno-foo'.  In the table below, only one of the forms is
  listed--the one you typically use.  You can figure out the other form by
! either removing 'no-' or adding it.
  
   The following options control specific optimizations.  They are either
! activated by '-O' options or are related to ones that are.  You can use
  the following flags in the rare cases when "fine-tuning" of
  optimizations to be performed is desired.
  
! '-fno-defer-pop'
       For machines that must pop arguments after a function call, always
       pop the arguments as soon as each function returns.  At levels
!      '-O1' and higher, '-fdefer-pop' is the default; this allows the
       compiler to let arguments accumulate on the stack for several
       function calls and pop them all at once.
  
! '-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 '-O1',
!      '-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'
       Omit the frame pointer in functions that don't need one.  This
       avoids the instructions to save, set up and restore the frame
       pointer; on many targets it also makes an extra register available.
--- 10754,10807 ----
            -fmove-loop-invariants  -fmove-loop-stores  -fssa-phiopt
            -ftree-bit-ccp  -ftree-dse  -ftree-pta  -ftree-sra
  
! ‘-Oz’
       Optimize aggressively for size rather than speed.  This may
       increase the number of instructions executed if those instructions
!      require fewer bytes to encode.  ‘-Oz’ behaves similarly to ‘-Os’
!      including enabling most ‘-O2’ optimizations.
  
!  If you use multiple ‘-O’ options, with or without level numbers, the
  last such option is the one that is effective.
  
!  Options of the form ‘-fFLAG’ specify machine-independent flags.  Most
  flags have both positive and negative forms; the negative form of
! ‘-ffoo’ is ‘-fno-foo’.  In the table below, only one of the forms is
  listed--the one you typically use.  You can figure out the other form by
! either removing ‘no-’ or adding it.
  
   The following options control specific optimizations.  They are either
! activated by ‘-O’ options or are related to ones that are.  You can use
  the following flags in the rare cases when "fine-tuning" of
  optimizations to be performed is desired.
  
! ‘-fno-defer-pop’
       For machines that must pop arguments after a function call, always
       pop the arguments as soon as each function returns.  At levels
!      ‘-O1’ and higher, ‘-fdefer-pop’ is the default; this allows the
       compiler to let arguments accumulate on the stack for several
       function calls and pop them all at once.
  
! ‘-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 ‘-O1’,
!      ‘-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’
       Omit the frame pointer in functions that don't need one.  This
       avoids the instructions to save, set up and restore the frame
       pointer; on many targets it also makes an extra register available.
*************** optimizations to be performed is desired
*** 10806,10908 ****
       calling sequence always uses a frame pointer, so it cannot be
       omitted.
  
!      Note that '-fno-omit-frame-pointer' doesn't guarantee the frame
       pointer is used in all functions.  Several targets always omit the
       frame pointer in leaf functions.
  
!      Enabled by default at '-O1' and higher.
  
! '-foptimize-sibling-calls'
       Optimize sibling and tail recursive calls.
  
!      Enabled at levels '-O2', '-O3', '-Os'.
  
! '-foptimize-strlen'
!      Optimize various standard C string functions (e.g. 'strlen',
!      'strchr' or 'strcpy') and their '_FORTIFY_SOURCE' counterparts into
       faster alternatives.
  
!      Enabled at levels '-O2', '-O3'.
  
! '-fno-inline'
       Do not expand any functions inline apart from those marked with the
!      'always_inline' attribute.  This is the default when not
       optimizing.
  
       Single functions can be exempted from inlining by marking them with
!      the 'noinline' attribute.
  
! '-finline-small-functions'
       Integrate functions into their callers when their body is smaller
       than expected function call code (so overall size of program gets
       smaller).  The compiler heuristically decides which functions are
       simple enough to be worth integrating in this way.  This inlining
       applies to all functions, even those not declared inline.
  
!      Enabled at levels '-O2', '-O3', '-Os'.
  
! '-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 levels '-O2', '-O3', '-Os'.
  
! '-finline-functions'
       Consider all functions for inlining, even if they are not declared
       inline.  The compiler heuristically decides which functions are
       worth integrating in this way.
  
       If all calls to a given function are integrated, and the function
!      is declared 'static', then the function is normally not output as
       assembler code in its own right.
  
!      Enabled at levels '-O2', '-O3', '-Os'.  Also enabled by
!      '-fprofile-use' and '-fauto-profile'.
  
! '-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', but not '-Og'.
  
! '-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,
--- 10810,10912 ----
       calling sequence always uses a frame pointer, so it cannot be
       omitted.
  
!      Note that ‘-fno-omit-frame-pointer’ doesn't guarantee the frame
       pointer is used in all functions.  Several targets always omit the
       frame pointer in leaf functions.
  
!      Enabled by default at ‘-O1’ and higher.
  
! ‘-foptimize-sibling-calls’
       Optimize sibling and tail recursive calls.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-foptimize-strlen’
!      Optimize various standard C string functions (e.g. ‘strlen’,
!      ‘strchr’ or ‘strcpy’) and their ‘_FORTIFY_SOURCE’ counterparts into
       faster alternatives.
  
!      Enabled at levels ‘-O2’, ‘-O3’.
  
! ‘-fno-inline’
       Do not expand any functions inline apart from those marked with the
!      ‘always_inline’ attribute.  This is the default when not
       optimizing.
  
       Single functions can be exempted from inlining by marking them with
!      the ‘noinline’ attribute.
  
! ‘-finline-small-functions’
       Integrate functions into their callers when their body is smaller
       than expected function call code (so overall size of program gets
       smaller).  The compiler heuristically decides which functions are
       simple enough to be worth integrating in this way.  This inlining
       applies to all functions, even those not declared inline.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-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 levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-finline-functions’
       Consider all functions for inlining, even if they are not declared
       inline.  The compiler heuristically decides which functions are
       worth integrating in this way.
  
       If all calls to a given function are integrated, and the function
!      is declared ‘static’, then the function is normally not output as
       assembler code in its own right.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.  Also enabled by
!      ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-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’, but not ‘-Og’.
  
! ‘-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,
*************** optimizations to be performed is desired
*** 10910,10989 ****
       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-functions'
!      Emit 'static' functions into the object file, even if the function
       is never used.
  
! '-fkeep-static-consts'
!      Emit variables declared 'static const' when optimization isn't
       turned on, even if the variables aren't referenced.
  
       GCC enables this option by default.  If you want to force the
       compiler to check if a variable is referenced, regardless of
       whether or not optimization is turned on, use the
!      '-fno-keep-static-consts' option.
  
! '-fmerge-constants'
       Attempt to merge identical constants (string constants and
       floating-point constants) across compilation units.
  
       This option is the default for optimized compilation if the
!      assembler and linker support it.  Use '-fno-merge-constants' to
       inhibit this behavior.
  
!      Enabled at levels '-O1', '-O2', '-O3', '-Os'.
  
! '-fmerge-all-constants'
       Attempt to merge identical constants and identical variables.
  
!      This option implies '-fmerge-constants'.  In addition to
!      '-fmerge-constants' this considers e.g. even constant initialized
       arrays or initialized constant variables with integral or
       floating-point types.  Languages like C or C++ require each
       variable, including multiple instances of the same variable in
       recursive calls, to have distinct locations, so using this option
       results in non-conforming behavior.
  
! '-fmodulo-sched'
       Perform swing modulo scheduling immediately before the first
       scheduling pass.  This pass looks at innermost loops and reorders
       their instructions by overlapping different iterations.
  
! '-fmodulo-sched-allow-regmoves'
       Perform more aggressive SMS-based modulo scheduling with register
       moves allowed.  By setting this flag certain anti-dependences edges
       are deleted, which triggers the generation of reg-moves based on
       the life-range analysis.  This option is effective only with
!      '-fmodulo-sched' enabled.
  
! '-fno-branch-count-reg'
       Disable the optimization pass that scans for opportunities to use
       "decrement and branch" instructions on a count register instead of
       instruction sequences that decrement a register, compare it against
       zero, and 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.  Note that the
!      '-fno-branch-count-reg' option doesn't remove the decrement and
       branch instructions from the generated instruction stream
       introduced by other optimization passes.
  
!      The default is '-fbranch-count-reg' at '-O1' and higher, except for
!      '-Og'.
  
! '-fno-function-cse'
       Do not put function addresses in registers; make each instruction
       that calls a constant function contain the function's address
       explicitly.
--- 10914,10993 ----
       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-functions’
!      Emit ‘static’ functions into the object file, even if the function
       is never used.
  
! ‘-fkeep-static-consts’
!      Emit variables declared ‘static const’ when optimization isn't
       turned on, even if the variables aren't referenced.
  
       GCC enables this option by default.  If you want to force the
       compiler to check if a variable is referenced, regardless of
       whether or not optimization is turned on, use the
!      ‘-fno-keep-static-consts’ option.
  
! ‘-fmerge-constants’
       Attempt to merge identical constants (string constants and
       floating-point constants) across compilation units.
  
       This option is the default for optimized compilation if the
!      assembler and linker support it.  Use ‘-fno-merge-constants’ to
       inhibit this behavior.
  
!      Enabled at levels ‘-O1’, ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fmerge-all-constants’
       Attempt to merge identical constants and identical variables.
  
!      This option implies ‘-fmerge-constants’.  In addition to
!      ‘-fmerge-constants’ this considers e.g. even constant initialized
       arrays or initialized constant variables with integral or
       floating-point types.  Languages like C or C++ require each
       variable, including multiple instances of the same variable in
       recursive calls, to have distinct locations, so using this option
       results in non-conforming behavior.
  
! ‘-fmodulo-sched’
       Perform swing modulo scheduling immediately before the first
       scheduling pass.  This pass looks at innermost loops and reorders
       their instructions by overlapping different iterations.
  
! ‘-fmodulo-sched-allow-regmoves’
       Perform more aggressive SMS-based modulo scheduling with register
       moves allowed.  By setting this flag certain anti-dependences edges
       are deleted, which triggers the generation of reg-moves based on
       the life-range analysis.  This option is effective only with
!      ‘-fmodulo-sched’ enabled.
  
! ‘-fno-branch-count-reg’
       Disable the optimization pass that scans for opportunities to use
       "decrement and branch" instructions on a count register instead of
       instruction sequences that decrement a register, compare it against
       zero, and 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.  Note that the
!      ‘-fno-branch-count-reg’ option doesn't remove the decrement and
       branch instructions from the generated instruction stream
       introduced by other optimization passes.
  
!      The default is ‘-fbranch-count-reg’ at ‘-O1’ and higher, except for
!      ‘-Og’.
  
! ‘-fno-function-cse’
       Do not put function addresses in registers; make each instruction
       that calls a constant function contain the function's address
       explicitly.
*************** optimizations to be performed is desired
*** 10992,11000 ****
       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.
--- 10996,11004 ----
       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.
*************** optimizations to be performed is desired
*** 11004,11101 ****
       that the resulting executable can find the beginning of that
       section and/or make assumptions based on that.
  
!      The default is '-fzero-initialized-in-bss'.
  
! '-fthread-jumps'
       Perform optimizations that check to see if a jump branches to a
       location where another comparison subsumed by the first is found.
       If so, the first branch is redirected to either the destination of
       the second branch or a point immediately following it, depending on
       whether the condition is known to be true or false.
  
!      Enabled at levels '-O1', '-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 '-O1', '-O2', '-O3', '-Os'.
  
! '-fsplit-wide-types-early'
       Fully split wide types early, instead of very late.  This option
!      has no effect unless '-fsplit-wide-types' is turned on.
  
       This is the default on some targets.
  
! '-fcse-follow-jumps'
       In common subexpression elimination (CSE), scan through jump
       instructions when the target of the jump is not reached by any
!      other path.  For example, when CSE encounters an 'if' statement
!      with an 'else' clause, CSE follows the jump when the condition
       tested is false.
  
!      Enabled at levels '-O2', '-O3', '-Os'.
  
! '-fcse-skip-blocks'
!      This is similar to '-fcse-follow-jumps', but causes CSE to follow
       jumps that conditionally skip over blocks.  When CSE encounters a
!      simple 'if' statement with no else clause, '-fcse-skip-blocks'
!      causes CSE to follow the jump around the body of the 'if'.
  
!      Enabled at levels '-O2', '-O3', '-Os'.
  
! '-frerun-cse-after-loop'
       Re-run common subexpression elimination after loop optimizations
       are performed.
  
!      Enabled at levels '-O2', '-O3', '-Os'.
  
! '-fgcse'
       Perform a global common subexpression elimination pass.  This pass
       also performs global constant and copy propagation.
  
       _Note:_ When compiling a program using computed gotos, a GCC
       extension, you may get better run-time performance if you disable
       the global common subexpression elimination pass by adding
!      '-fno-gcse' to the command line.
  
!      Enabled at levels '-O2', '-O3', '-Os'.
  
! '-fgcse-lm'
!      When '-fgcse-lm' is enabled, global common subexpression
       elimination attempts to move loads that are only killed by stores
       into themselves.  This allows a loop containing a load/store
       sequence to be changed to a load outside the loop, and a copy/store
       within the loop.
  
!      Enabled by default when '-fgcse' is enabled.
  
! '-fgcse-sm'
!      When '-fgcse-sm' is enabled, a store motion pass is run after
       global common subexpression elimination.  This pass attempts to
       move stores out of loops.  When used in conjunction with
!      '-fgcse-lm', loops containing a load/store sequence can be changed
       to a load before the loop and a store after the loop.
  
       Not enabled at any optimization level.
  
! '-fgcse-las'
!      When '-fgcse-las' is enabled, the global common subexpression
       elimination pass eliminates redundant loads that come after stores
       to the same memory location (both partial and full redundancies).
  
       Not enabled at any optimization level.
  
! '-fgcse-after-reload'
!      When '-fgcse-after-reload' is enabled, a redundant load elimination
       pass is performed after reload.  The purpose of this pass is to
       clean up redundant spilling.
  
!      Enabled by '-O3', '-fprofile-use' and '-fauto-profile'.
  
! '-faggressive-loop-optimizations'
       This option tells the loop optimizer to use language constraints to
       derive bounds for the number of iterations of a loop.  This assumes
       that loop code does not invoke undefined behavior by for example
--- 11008,11105 ----
       that the resulting executable can find the beginning of that
       section and/or make assumptions based on that.
  
!      The default is ‘-fzero-initialized-in-bss’.
  
! ‘-fthread-jumps’
       Perform optimizations that check to see if a jump branches to a
       location where another comparison subsumed by the first is found.
       If so, the first branch is redirected to either the destination of
       the second branch or a point immediately following it, depending on
       whether the condition is known to be true or false.
  
!      Enabled at levels ‘-O1’, ‘-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 ‘-O1’, ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fsplit-wide-types-early’
       Fully split wide types early, instead of very late.  This option
!      has no effect unless ‘-fsplit-wide-types’ is turned on.
  
       This is the default on some targets.
  
! ‘-fcse-follow-jumps’
       In common subexpression elimination (CSE), scan through jump
       instructions when the target of the jump is not reached by any
!      other path.  For example, when CSE encounters an ‘if’ statement
!      with an ‘else’ clause, CSE follows the jump when the condition
       tested is false.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fcse-skip-blocks’
!      This is similar to ‘-fcse-follow-jumps’, but causes CSE to follow
       jumps that conditionally skip over blocks.  When CSE encounters a
!      simple ‘if’ statement with no else clause, ‘-fcse-skip-blocks’
!      causes CSE to follow the jump around the body of the ‘if’.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-frerun-cse-after-loop’
       Re-run common subexpression elimination after loop optimizations
       are performed.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fgcse’
       Perform a global common subexpression elimination pass.  This pass
       also performs global constant and copy propagation.
  
       _Note:_ When compiling a program using computed gotos, a GCC
       extension, you may get better run-time performance if you disable
       the global common subexpression elimination pass by adding
!      ‘-fno-gcse’ to the command line.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fgcse-lm’
!      When ‘-fgcse-lm’ is enabled, global common subexpression
       elimination attempts to move loads that are only killed by stores
       into themselves.  This allows a loop containing a load/store
       sequence to be changed to a load outside the loop, and a copy/store
       within the loop.
  
!      Enabled by default when ‘-fgcse’ is enabled.
  
! ‘-fgcse-sm’
!      When ‘-fgcse-sm’ is enabled, a store motion pass is run after
       global common subexpression elimination.  This pass attempts to
       move stores out of loops.  When used in conjunction with
!      ‘-fgcse-lm’, loops containing a load/store sequence can be changed
       to a load before the loop and a store after the loop.
  
       Not enabled at any optimization level.
  
! ‘-fgcse-las’
!      When ‘-fgcse-las’ is enabled, the global common subexpression
       elimination pass eliminates redundant loads that come after stores
       to the same memory location (both partial and full redundancies).
  
       Not enabled at any optimization level.
  
! ‘-fgcse-after-reload’
!      When ‘-fgcse-after-reload’ is enabled, a redundant load elimination
       pass is performed after reload.  The purpose of this pass is to
       clean up redundant spilling.
  
!      Enabled by ‘-O3’, ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-faggressive-loop-optimizations’
       This option tells the loop optimizer to use language constraints to
       derive bounds for the number of iterations of a loop.  This assumes
       that loop code does not invoke undefined behavior by for example
*************** optimizations to be performed is desired
*** 11104,11152 ****
       loop unrolling and peeling and loop exit test optimizations.  This
       option is enabled by default.
  
! '-funconstrained-commons'
       This option tells the compiler that variables declared in common
       blocks (e.g. Fortran) may later be overridden with longer trailing
       arrays.  This prevents certain optimizations that depend on knowing
       the array bounds.
  
! '-fcrossjumping'
       Perform cross-jumping transformation.  This transformation unifies
       equivalent code and saves code size.  The resulting code may or may
       not perform better than without cross-jumping.
  
!      Enabled at levels '-O2', '-O3', '-Os'.
  
! '-fauto-inc-dec'
       Combine increments or decrements of addresses with memory accesses.
       This pass is always skipped on architectures that do not have
!      instructions to support this.  Enabled by default at '-O1' and
       higher on architectures that support this.
  
! '-fdce'
       Perform dead code elimination (DCE) on RTL.  Enabled by default at
!      '-O1' and higher.
  
! '-fdse'
       Perform dead store elimination (DSE) on RTL.  Enabled by default at
!      '-O1' and higher.
  
! '-fif-conversion'
       Attempt to transform conditional jumps into branch-less
       equivalents.  This includes use of conditional moves, min, max, set
       flags and abs instructions, and some tricks doable by standard
       arithmetics.  The use of conditional execution on chips where it is
!      available is controlled by '-fif-conversion2'.
  
!      Enabled at levels '-O1', '-O2', '-O3', '-Os', but not with '-Og'.
  
! '-fif-conversion2'
       Use conditional execution (where available) to transform
       conditional jumps into branch-less equivalents.
  
!      Enabled at levels '-O1', '-O2', '-O3', '-Os', but not with '-Og'.
  
! '-fdeclone-ctor-dtor'
       The C++ ABI requires multiple entry points for constructors and
       destructors: one for a base subobject, one for a complete object,
       and one for a virtual destructor that calls operator delete
--- 11108,11156 ----
       loop unrolling and peeling and loop exit test optimizations.  This
       option is enabled by default.
  
! ‘-funconstrained-commons’
       This option tells the compiler that variables declared in common
       blocks (e.g. Fortran) may later be overridden with longer trailing
       arrays.  This prevents certain optimizations that depend on knowing
       the array bounds.
  
! ‘-fcrossjumping’
       Perform cross-jumping transformation.  This transformation unifies
       equivalent code and saves code size.  The resulting code may or may
       not perform better than without cross-jumping.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fauto-inc-dec’
       Combine increments or decrements of addresses with memory accesses.
       This pass is always skipped on architectures that do not have
!      instructions to support this.  Enabled by default at ‘-O1’ and
       higher on architectures that support this.
  
! ‘-fdce’
       Perform dead code elimination (DCE) on RTL.  Enabled by default at
!      ‘-O1’ and higher.
  
! ‘-fdse’
       Perform dead store elimination (DSE) on RTL.  Enabled by default at
!      ‘-O1’ and higher.
  
! ‘-fif-conversion’
       Attempt to transform conditional jumps into branch-less
       equivalents.  This includes use of conditional moves, min, max, set
       flags and abs instructions, and some tricks doable by standard
       arithmetics.  The use of conditional execution on chips where it is
!      available is controlled by ‘-fif-conversion2’.
  
!      Enabled at levels ‘-O1’, ‘-O2’, ‘-O3’, ‘-Os’, but not with ‘-Og’.
  
! ‘-fif-conversion2’
       Use conditional execution (where available) to transform
       conditional jumps into branch-less equivalents.
  
!      Enabled at levels ‘-O1’, ‘-O2’, ‘-O3’, ‘-Os’, but not with ‘-Og’.
  
! ‘-fdeclone-ctor-dtor’
       The C++ ABI requires multiple entry points for constructors and
       destructors: one for a base subobject, one for a complete object,
       and one for a virtual destructor that calls operator delete
*************** optimizations to be performed is desired
*** 11155,11163 ****
       function.  With this option, the base and complete variants are
       changed to be thunks that call a common implementation.
  
!      Enabled by '-Os'.
  
! '-fdelete-null-pointer-checks'
       Assume that programs cannot safely dereference null pointers, and
       that no code or data element resides at address zero.  This option
       enables simple constant folding optimizations at all optimization
--- 11159,11167 ----
       function.  With this option, the base and complete variants are
       changed to be thunks that call a common implementation.
  
!      Enabled by ‘-Os’.
  
! ‘-fdelete-null-pointer-checks’
       Assume that programs cannot safely dereference null pointers, and
       that no code or data element resides at address zero.  This option
       enables simple constant folding optimizations at all optimization
*************** optimizations to be performed is desired
*** 11168,11174 ****
       checked after it has already been dereferenced, it cannot be null.
  
       Note however that in some environments this assumption is not true.
!      Use '-fno-delete-null-pointer-checks' to disable this optimization
       for programs that depend on that behavior.
  
       This option is enabled by default on most targets.  On Nios II ELF,
--- 11172,11178 ----
       checked after it has already been dereferenced, it cannot be null.
  
       Note however that in some environments this assumption is not true.
!      Use ‘-fno-delete-null-pointer-checks’ to disable this optimization
       for programs that depend on that behavior.
  
       This option is enabled by default on most targets.  On Nios II ELF,
*************** optimizations to be performed is desired
*** 11178,11191 ****
       Passes that use the dataflow information are enabled independently
       at different optimization levels.
  
! '-fdevirtualize'
       Attempt to convert calls to virtual functions to direct calls.
       This is done both within a procedure and interprocedurally as part
!      of indirect inlining ('-findirect-inlining') and interprocedural
!      constant propagation ('-fipa-cp').  Enabled at levels '-O2', '-O3',
!      '-Os'.
  
! '-fdevirtualize-speculatively'
       Attempt to convert calls to virtual functions to speculative direct
       calls.  Based on the analysis of the type inheritance graph,
       determine for a given call the set of likely targets.  If the set
--- 11182,11195 ----
       Passes that use the dataflow information are enabled independently
       at different optimization levels.
  
! ‘-fdevirtualize’
       Attempt to convert calls to virtual functions to direct calls.
       This is done both within a procedure and interprocedurally as part
!      of indirect inlining (‘-findirect-inlining’) and interprocedural
!      constant propagation (‘-fipa-cp’).  Enabled at levels ‘-O2’, ‘-O3’,
!      ‘-Os’.
  
! ‘-fdevirtualize-speculatively’
       Attempt to convert calls to virtual functions to speculative direct
       calls.  Based on the analysis of the type inheritance graph,
       determine for a given call the set of likely targets.  If the set
*************** optimizations to be performed is desired
*** 11195,11222 ****
       useless after further optimization, they are converted back into
       original form.
  
! '-fdevirtualize-at-ltrans'
       Stream extra information needed for aggressive devirtualization
       when running the link-time optimizer in local transformation mode.
       This option enables more devirtualization but significantly
       increases the size of streamed data.  For this reason it is
       disabled by default.
  
! '-fexpensive-optimizations'
       Perform a number of minor optimizations that are relatively
       expensive.
  
!      Enabled at levels '-O2', '-O3', '-Os'.
  
! '-free'
       Attempt to remove redundant extension instructions.  This is
       especially helpful for the x86-64 architecture, which implicitly
       zero-extends in 64-bit registers after writing to their lower
       32-bit half.
  
!      Enabled for Alpha, AArch64 and x86 at levels '-O2', '-O3', '-Os'.
  
! '-fno-lifetime-dse'
       In C++ the value of an object is only affected by changes within
       its lifetime: when the constructor begins, the object has an
       indeterminate value, and any changes during the lifetime of the
--- 11199,11226 ----
       useless after further optimization, they are converted back into
       original form.
  
! ‘-fdevirtualize-at-ltrans’
       Stream extra information needed for aggressive devirtualization
       when running the link-time optimizer in local transformation mode.
       This option enables more devirtualization but significantly
       increases the size of streamed data.  For this reason it is
       disabled by default.
  
! ‘-fexpensive-optimizations’
       Perform a number of minor optimizations that are relatively
       expensive.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-free’
       Attempt to remove redundant extension instructions.  This is
       especially helpful for the x86-64 architecture, which implicitly
       zero-extends in 64-bit registers after writing to their lower
       32-bit half.
  
!      Enabled for Alpha, AArch64 and x86 at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fno-lifetime-dse’
       In C++ the value of an object is only affected by changes within
       its lifetime: when the constructor begins, the object has an
       indeterminate value, and any changes during the lifetime of the
*************** optimizations to be performed is desired
*** 11226,11312 ****
       object, you can use this flag to disable this optimization.  To
       preserve stores before the constructor starts (e.g. because your
       operator new clears the object storage) but still treat the object
!      as dead after the destructor, you can use '-flifetime-dse=1'.  The
       default behavior can be explicitly selected with
!      '-flifetime-dse=2'.  '-flifetime-dse=0' is equivalent to
!      '-fno-lifetime-dse'.
  
! '-flive-range-shrinkage'
       Attempt to decrease register pressure through register live range
       shrinkage.  This is helpful for fast processors with small or
       moderate size register sets.
  
! '-fira-algorithm=ALGORITHM'
       Use the specified coloring algorithm for the integrated register
!      allocator.  The ALGORITHM argument can be 'priority', which
!      specifies Chow's priority coloring, or 'CB', which specifies
       Chaitin-Briggs coloring.  Chaitin-Briggs coloring is not
       implemented for all architectures, but for those targets that do
       support it, it is the default because it generates better code.
  
! '-fira-region=REGION'
       Use specified regions for the integrated register allocator.  The
       REGION argument should be one of the following:
  
!      'all'
            Use all loops as register allocation regions.  This can give
            the best results for machines with a small and/or irregular
            register set.
  
!      'mixed'
            Use all loops except for loops with small register pressure as
            the regions.  This value usually gives the best results in
            most cases and for most architectures, and is enabled by
!           default when compiling with optimization for speed ('-O',
!           '-O2', ...).
  
!      'one'
            Use all functions as a single region.  This typically results
!           in the smallest code size, and is enabled by default for '-Os'
!           or '-O0'.
  
! '-fira-hoist-pressure'
       Use IRA to evaluate register pressure in the code hoisting pass for
       decisions to hoist expressions.  This option usually results in
       smaller code, but it can slow the compiler down.
  
!      This option is enabled at level '-Os' for all targets.
  
! '-fira-loop-pressure'
       Use IRA to evaluate register pressure in loops for decisions to
       move loop invariants.  This option usually results in generation of
       faster and smaller code on machines with large register files (>=
       32 registers), but it can slow the compiler down.
  
!      This option is enabled at level '-O3' for some targets.
  
! '-fno-ira-share-save-slots'
       Disable sharing of stack slots used for saving call-used hard
       registers living through a call.  Each hard register gets a
       separate stack slot, and as a result function stack frames are
       larger.
  
! '-fno-ira-share-spill-slots'
       Disable sharing of stack slots allocated for pseudo-registers.
       Each pseudo-register that does not get a hard register gets a
       separate stack slot, and as a result function stack frames are
       larger.
  
! '-flra-remat'
       Enable CFG-sensitive rematerialization in LRA. Instead of loading
       values of spilled pseudos, LRA tries to rematerialize (recalculate)
       values if it is profitable.
  
!      Enabled at levels '-O2', '-O3', '-Os'.
  
! '-fdelayed-branch'
       If supported for the target machine, attempt to reorder
       instructions to exploit instruction slots available after delayed
       branch instructions.
  
!      Enabled at levels '-O1', '-O2', '-O3', '-Os', but not at '-Og'.
  
! '-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
--- 11230,11316 ----
       object, you can use this flag to disable this optimization.  To
       preserve stores before the constructor starts (e.g. because your
       operator new clears the object storage) but still treat the object
!      as dead after the destructor, you can use ‘-flifetime-dse=1’.  The
       default behavior can be explicitly selected with
!      ‘-flifetime-dse=2’.  ‘-flifetime-dse=0’ is equivalent to
!      ‘-fno-lifetime-dse’.
  
! ‘-flive-range-shrinkage’
       Attempt to decrease register pressure through register live range
       shrinkage.  This is helpful for fast processors with small or
       moderate size register sets.
  
! ‘-fira-algorithm=ALGORITHM’
       Use the specified coloring algorithm for the integrated register
!      allocator.  The ALGORITHM argument can be ‘priority’, which
!      specifies Chow's priority coloring, or ‘CB’, which specifies
       Chaitin-Briggs coloring.  Chaitin-Briggs coloring is not
       implemented for all architectures, but for those targets that do
       support it, it is the default because it generates better code.
  
! ‘-fira-region=REGION’
       Use specified regions for the integrated register allocator.  The
       REGION argument should be one of the following:
  
!      ‘all’
            Use all loops as register allocation regions.  This can give
            the best results for machines with a small and/or irregular
            register set.
  
!      ‘mixed’
            Use all loops except for loops with small register pressure as
            the regions.  This value usually gives the best results in
            most cases and for most architectures, and is enabled by
!           default when compiling with optimization for speed (‘-O’,
!           ‘-O2’, ...).
  
!      ‘one’
            Use all functions as a single region.  This typically results
!           in the smallest code size, and is enabled by default for ‘-Os’
!           or ‘-O0’.
  
! ‘-fira-hoist-pressure’
       Use IRA to evaluate register pressure in the code hoisting pass for
       decisions to hoist expressions.  This option usually results in
       smaller code, but it can slow the compiler down.
  
!      This option is enabled at level ‘-Os’ for all targets.
  
! ‘-fira-loop-pressure’
       Use IRA to evaluate register pressure in loops for decisions to
       move loop invariants.  This option usually results in generation of
       faster and smaller code on machines with large register files (>=
       32 registers), but it can slow the compiler down.
  
!      This option is enabled at level ‘-O3’ for some targets.
  
! ‘-fno-ira-share-save-slots’
       Disable sharing of stack slots used for saving call-used hard
       registers living through a call.  Each hard register gets a
       separate stack slot, and as a result function stack frames are
       larger.
  
! ‘-fno-ira-share-spill-slots’
       Disable sharing of stack slots allocated for pseudo-registers.
       Each pseudo-register that does not get a hard register gets a
       separate stack slot, and as a result function stack frames are
       larger.
  
! ‘-flra-remat’
       Enable CFG-sensitive rematerialization in LRA. Instead of loading
       values of spilled pseudos, LRA tries to rematerialize (recalculate)
       values if it is profitable.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fdelayed-branch’
       If supported for the target machine, attempt to reorder
       instructions to exploit instruction slots available after delayed
       branch instructions.
  
!      Enabled at levels ‘-O1’, ‘-O2’, ‘-O3’, ‘-Os’, but not at ‘-Og’.
  
! ‘-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
*************** optimizations to be performed is desired
*** 11314,11380 ****
       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'
       Disable instruction scheduling across basic blocks, which is
       normally enabled when scheduling before register allocation, i.e.
!      with '-fschedule-insns' or at '-O2' or higher.
  
! '-fno-sched-spec'
       Disable speculative motion of non-load instructions, which is
       normally enabled when scheduling before register allocation, i.e.
!      with '-fschedule-insns' or at '-O2' or higher.
  
! '-fsched-pressure'
       Enable register pressure sensitive insn scheduling before register
       allocation.  This only makes sense when scheduling before register
!      allocation is enabled, i.e. with '-fschedule-insns' or at '-O2' or
       higher.  Usage of this option can improve the generated code and
       decrease its size by preventing register pressure increase above
       the number of available hard registers and subsequent spills in
       register allocation.
  
! '-fsched-spec-load'
       Allow speculative motion of some load instructions.  This only
       makes sense when scheduling before register allocation, i.e. with
!      '-fschedule-insns' or at '-O2' or higher.
  
! '-fsched-spec-load-dangerous'
       Allow speculative motion of more load instructions.  This only
       makes sense when scheduling before register allocation, i.e. with
!      '-fschedule-insns' or at '-O2' or higher.
  
! '-fsched-stalled-insns'
! '-fsched-stalled-insns=N'
       Define how many insns (if any) can be moved prematurely from the
       queue of stalled insns into the ready list during the second
!      scheduling pass.  '-fno-sched-stalled-insns' means that no insns
!      are moved prematurely, '-fsched-stalled-insns=0' means there is no
       limit on how many queued insns can be moved prematurely.
!      '-fsched-stalled-insns' without a value is equivalent to
!      '-fsched-stalled-insns=1'.
  
! '-fsched-stalled-insns-dep'
! '-fsched-stalled-insns-dep=N'
       Define how many insn groups (cycles) are examined for a dependency
       on a stalled insn that is a candidate for premature removal from
       the queue of stalled insns.  This has an effect only during the
!      second scheduling pass, and only if '-fsched-stalled-insns' is
!      used.  '-fno-sched-stalled-insns-dep' is equivalent to
!      '-fsched-stalled-insns-dep=0'.  '-fsched-stalled-insns-dep' without
!      a value is equivalent to '-fsched-stalled-insns-dep=1'.
  
! '-fsched2-use-superblocks'
       When scheduling after register allocation, use superblock
       scheduling.  This allows motion across basic block boundaries,
       resulting in faster schedules.  This option is experimental, as not
--- 11318,11384 ----
       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’
       Disable instruction scheduling across basic blocks, which is
       normally enabled when scheduling before register allocation, i.e.
!      with ‘-fschedule-insns’ or at ‘-O2’ or higher.
  
! ‘-fno-sched-spec’
       Disable speculative motion of non-load instructions, which is
       normally enabled when scheduling before register allocation, i.e.
!      with ‘-fschedule-insns’ or at ‘-O2’ or higher.
  
! ‘-fsched-pressure’
       Enable register pressure sensitive insn scheduling before register
       allocation.  This only makes sense when scheduling before register
!      allocation is enabled, i.e. with ‘-fschedule-insns’ or at ‘-O2’ or
       higher.  Usage of this option can improve the generated code and
       decrease its size by preventing register pressure increase above
       the number of available hard registers and subsequent spills in
       register allocation.
  
! ‘-fsched-spec-load’
       Allow speculative motion of some load instructions.  This only
       makes sense when scheduling before register allocation, i.e. with
!      ‘-fschedule-insns’ or at ‘-O2’ or higher.
  
! ‘-fsched-spec-load-dangerous’
       Allow speculative motion of more load instructions.  This only
       makes sense when scheduling before register allocation, i.e. with
!      ‘-fschedule-insns’ or at ‘-O2’ or higher.
  
! ‘-fsched-stalled-insns’
! ‘-fsched-stalled-insns=N’
       Define how many insns (if any) can be moved prematurely from the
       queue of stalled insns into the ready list during the second
!      scheduling pass.  ‘-fno-sched-stalled-insns’ means that no insns
!      are moved prematurely, ‘-fsched-stalled-insns=0’ means there is no
       limit on how many queued insns can be moved prematurely.
!      ‘-fsched-stalled-insns’ without a value is equivalent to
!      ‘-fsched-stalled-insns=1’.
  
! ‘-fsched-stalled-insns-dep’
! ‘-fsched-stalled-insns-dep=N’
       Define how many insn groups (cycles) are examined for a dependency
       on a stalled insn that is a candidate for premature removal from
       the queue of stalled insns.  This has an effect only during the
!      second scheduling pass, and only if ‘-fsched-stalled-insns’ is
!      used.  ‘-fno-sched-stalled-insns-dep’ is equivalent to
!      ‘-fsched-stalled-insns-dep=0’.  ‘-fsched-stalled-insns-dep’ without
!      a value is equivalent to ‘-fsched-stalled-insns-dep=1’.
  
! ‘-fsched2-use-superblocks’
       When scheduling after register allocation, use superblock
       scheduling.  This allows motion across basic block boundaries,
       resulting in faster schedules.  This option is experimental, as not
*************** optimizations to be performed is desired
*** 11382,11453 ****
       to avoid unreliable results from the algorithm.
  
       This only makes sense when scheduling after register allocation,
!      i.e. with '-fschedule-insns2' or at '-O2' or higher.
  
! '-fsched-group-heuristic'
       Enable the group heuristic in the scheduler.  This heuristic favors
       the instruction that belongs to a schedule group.  This is enabled
!      by default when scheduling is enabled, i.e. with '-fschedule-insns'
!      or '-fschedule-insns2' or at '-O2' or higher.
  
! '-fsched-critical-path-heuristic'
       Enable the critical-path heuristic in the scheduler.  This
       heuristic favors instructions on the critical path.  This is
       enabled by default when scheduling is enabled, i.e. with
!      '-fschedule-insns' or '-fschedule-insns2' or at '-O2' or higher.
  
! '-fsched-spec-insn-heuristic'
       Enable the speculative instruction heuristic in the scheduler.
       This heuristic favors speculative instructions with greater
       dependency weakness.  This is enabled by default when scheduling is
!      enabled, i.e. with '-fschedule-insns' or '-fschedule-insns2' or at
!      '-O2' or higher.
  
! '-fsched-rank-heuristic'
       Enable the rank heuristic in the scheduler.  This heuristic favors
       the instruction belonging to a basic block with greater size or
       frequency.  This is enabled by default when scheduling is enabled,
!      i.e. with '-fschedule-insns' or '-fschedule-insns2' or at '-O2' or
       higher.
  
! '-fsched-last-insn-heuristic'
       Enable the last-instruction heuristic in the scheduler.  This
       heuristic favors the instruction that is less dependent on the last
       instruction scheduled.  This is enabled by default when scheduling
!      is enabled, i.e. with '-fschedule-insns' or '-fschedule-insns2' or
!      at '-O2' or higher.
  
! '-fsched-dep-count-heuristic'
       Enable the dependent-count heuristic in the scheduler.  This
       heuristic favors the instruction that has more instructions
       depending on it.  This is enabled by default when scheduling is
!      enabled, i.e. with '-fschedule-insns' or '-fschedule-insns2' or at
!      '-O2' or higher.
  
! '-freschedule-modulo-scheduled-loops'
       Modulo scheduling is performed before traditional scheduling.  If a
       loop is modulo scheduled, later scheduling passes may change its
       schedule.  Use this option to control that behavior.
  
! '-fselective-scheduling'
       Schedule instructions using selective scheduling algorithm.
       Selective scheduling runs instead of the first scheduler pass.
  
! '-fselective-scheduling2'
       Schedule instructions using selective scheduling algorithm.
       Selective scheduling runs instead of the second scheduler pass.
  
! '-fsel-sched-pipelining'
       Enable software pipelining of innermost loops during selective
       scheduling.  This option has no effect unless one of
!      '-fselective-scheduling' or '-fselective-scheduling2' is turned on.
  
! '-fsel-sched-pipelining-outer-loops'
       When pipelining loops during selective scheduling, also pipeline
       outer loops.  This option has no effect unless
!      '-fsel-sched-pipelining' is turned on.
  
! '-fsemantic-interposition'
       Some object formats, like ELF, allow interposing of symbols by the
       dynamic linker.  This means that for symbols exported from the DSO,
       the compiler cannot perform interprocedural propagation, inlining
--- 11386,11457 ----
       to avoid unreliable results from the algorithm.
  
       This only makes sense when scheduling after register allocation,
!      i.e. with ‘-fschedule-insns2’ or at ‘-O2’ or higher.
  
! ‘-fsched-group-heuristic’
       Enable the group heuristic in the scheduler.  This heuristic favors
       the instruction that belongs to a schedule group.  This is enabled
!      by default when scheduling is enabled, i.e. with ‘-fschedule-insns’
!      or ‘-fschedule-insns2’ or at ‘-O2’ or higher.
  
! ‘-fsched-critical-path-heuristic’
       Enable the critical-path heuristic in the scheduler.  This
       heuristic favors instructions on the critical path.  This is
       enabled by default when scheduling is enabled, i.e. with
!      ‘-fschedule-insns’ or ‘-fschedule-insns2’ or at ‘-O2’ or higher.
  
! ‘-fsched-spec-insn-heuristic’
       Enable the speculative instruction heuristic in the scheduler.
       This heuristic favors speculative instructions with greater
       dependency weakness.  This is enabled by default when scheduling is
!      enabled, i.e. with ‘-fschedule-insns’ or ‘-fschedule-insns2’ or at
!      ‘-O2’ or higher.
  
! ‘-fsched-rank-heuristic’
       Enable the rank heuristic in the scheduler.  This heuristic favors
       the instruction belonging to a basic block with greater size or
       frequency.  This is enabled by default when scheduling is enabled,
!      i.e. with ‘-fschedule-insns’ or ‘-fschedule-insns2’ or at ‘-O2’ or
       higher.
  
! ‘-fsched-last-insn-heuristic’
       Enable the last-instruction heuristic in the scheduler.  This
       heuristic favors the instruction that is less dependent on the last
       instruction scheduled.  This is enabled by default when scheduling
!      is enabled, i.e. with ‘-fschedule-insns’ or ‘-fschedule-insns2’ or
!      at ‘-O2’ or higher.
  
! ‘-fsched-dep-count-heuristic’
       Enable the dependent-count heuristic in the scheduler.  This
       heuristic favors the instruction that has more instructions
       depending on it.  This is enabled by default when scheduling is
!      enabled, i.e. with ‘-fschedule-insns’ or ‘-fschedule-insns2’ or at
!      ‘-O2’ or higher.
  
! ‘-freschedule-modulo-scheduled-loops’
       Modulo scheduling is performed before traditional scheduling.  If a
       loop is modulo scheduled, later scheduling passes may change its
       schedule.  Use this option to control that behavior.
  
! ‘-fselective-scheduling’
       Schedule instructions using selective scheduling algorithm.
       Selective scheduling runs instead of the first scheduler pass.
  
! ‘-fselective-scheduling2’
       Schedule instructions using selective scheduling algorithm.
       Selective scheduling runs instead of the second scheduler pass.
  
! ‘-fsel-sched-pipelining’
       Enable software pipelining of innermost loops during selective
       scheduling.  This option has no effect unless one of
!      ‘-fselective-scheduling’ or ‘-fselective-scheduling2’ is turned on.
  
! ‘-fsel-sched-pipelining-outer-loops’
       When pipelining loops during selective scheduling, also pipeline
       outer loops.  This option has no effect unless
!      ‘-fsel-sched-pipelining’ is turned on.
  
! ‘-fsemantic-interposition’
       Some object formats, like ELF, allow interposing of symbols by the
       dynamic linker.  This means that for symbols exported from the DSO,
       the compiler cannot perform interprocedural propagation, inlining
*************** optimizations to be performed is desired
*** 11455,11461 ****
       variable in question may change.  While this feature is useful, for
       example, to rewrite memory allocation functions by a debugging
       implementation, it is expensive in the terms of code quality.  With
!      '-fno-semantic-interposition' the compiler assumes that if
       interposition happens for functions the overwriting function will
       have precisely the same semantics (and side effects).  Similarly if
       interposition happens for variables, the constructor of the
--- 11459,11465 ----
       variable in question may change.  While this feature is useful, for
       example, to rewrite memory allocation functions by a debugging
       implementation, it is expensive in the terms of code quality.  With
!      ‘-fno-semantic-interposition’ the compiler assumes that if
       interposition happens for functions the overwriting function will
       have precisely the same semantics (and side effects).  Similarly if
       interposition happens for variables, the constructor of the
*************** optimizations to be performed is desired
*** 11464,11481 ****
       interposition to change semantics) and for symbols explicitly
       declared weak.
  
! '-fshrink-wrap'
       Emit function prologues only before parts of the function that need
       it, rather than at the top of the function.  This flag is enabled
!      by default at '-O' and higher.
  
! '-fshrink-wrap-separate'
       Shrink-wrap separate parts of the prologue and epilogue separately,
       so that those parts are only executed when needed.  This option is
!      on by default, but has no effect unless '-fshrink-wrap' is also
       turned on and the target supports this.
  
! '-fcaller-saves'
       Enable allocation of values to registers that are clobbered by
       function calls, by emitting extra instructions to save and restore
       the registers around such calls.  Such allocation is done only when
--- 11468,11485 ----
       interposition to change semantics) and for symbols explicitly
       declared weak.
  
! ‘-fshrink-wrap’
       Emit function prologues only before parts of the function that need
       it, rather than at the top of the function.  This flag is enabled
!      by default at ‘-O’ and higher.
  
! ‘-fshrink-wrap-separate’
       Shrink-wrap separate parts of the prologue and epilogue separately,
       so that those parts are only executed when needed.  This option is
!      on by default, but has no effect unless ‘-fshrink-wrap’ is also
       turned on and the target supports this.
  
! ‘-fcaller-saves’
       Enable allocation of values to registers that are clobbered by
       function calls, by emitting extra instructions to save and restore
       the registers around such calls.  Such allocation is done only when
*************** optimizations to be performed is desired
*** 11485,11629 ****
       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.
  
! '-fipa-ra'
       Use caller save registers for allocation if those registers are not
       used by any called function.  In that case it is not necessary to
       save and restore them around calls.  This is only possible if
       called functions are part of same compilation unit as current
       function and they are compiled before it.
  
!      Enabled at levels '-O2', '-O3', '-Os', however the option is
       disabled if generated code will be instrumented for profiling
!      ('-p', or '-pg') or if callee's register usage cannot be known
       exactly (this happens on targets that do not expose prologues and
       epilogues in RTL).
  
! '-fconserve-stack'
       Attempt to minimize stack usage.  The compiler attempts to use less
       stack space, even if that makes the program slower.  This option
!      implies setting the 'large-stack-frame' parameter to 100 and the
!      'large-stack-frame-growth' parameter to 400.
  
! '-ftree-reassoc'
       Perform reassociation on trees.  This flag is enabled by default at
!      '-O1' and higher.
  
! '-fcode-hoisting'
       Perform code hoisting.  Code hoisting tries to move the evaluation
       of expressions executed on all paths to the function exit as early
       as possible.  This is especially useful as a code size
       optimization, but it often helps for code speed as well.  This flag
!      is enabled by default at '-O2' and higher.
  
! '-ftree-pre'
       Perform partial redundancy elimination (PRE) on trees.  This flag
!      is enabled by default at '-O2' and '-O3'.
  
! '-ftree-partial-pre'
       Make partial redundancy elimination (PRE) more aggressive.  This
!      flag is enabled by default at '-O3'.
  
! '-ftree-forwprop'
       Perform forward propagation on trees.  This flag is enabled by
!      default at '-O1' 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 '-O1' and higher.
  
! '-ftree-phiprop'
       Perform hoisting of loads from conditional pointers on trees.  This
!      pass is enabled by default at '-O1' and higher.
  
! '-fhoist-adjacent-loads'
       Speculatively hoist loads from both branches of an if-then-else if
       the loads are from adjacent locations in the same structure and the
       target architecture has a conditional move instruction.  This flag
!      is enabled by default at '-O2' and higher.
  
! '-ftree-copy-prop'
       Perform copy propagation on trees.  This pass eliminates
       unnecessary copy operations.  This flag is enabled by default at
!      '-O1' and higher.
  
! '-fipa-pure-const'
       Discover which functions are pure or constant.  Enabled by default
!      at '-O1' and higher.
  
! '-fipa-reference'
       Discover which static variables do not escape the compilation unit.
!      Enabled by default at '-O1' and higher.
  
! '-fipa-reference-addressable'
       Discover read-only, write-only and non-addressable static
!      variables.  Enabled by default at '-O1' and higher.
  
! '-fipa-stack-alignment'
       Reduce stack alignment on call sites if possible.  Enabled by
       default.
  
! '-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 '-O1' and higher.
  
! '-fipa-modref'
       Perform interprocedural mod/ref analysis.  This optimization
       analyzes the side effects of functions (memory locations that are
       modified or referenced) and enables better optimization across the
!      function call boundary.  This flag is enabled by default at '-O1'
       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'.  It is also enabled by '-fprofile-use' and
!      '-fauto-profile'.
  
! '-fipa-cp-clone'
       Perform function cloning to make interprocedural constant
       propagation stronger.  When enabled, interprocedural constant
       propagation performs function cloning when externally visible
       function can be called with constant arguments.  Because this
       optimization can create multiple copies of functions, it may
!      significantly increase code size (see '--param
!      ipa-cp-unit-growth=VALUE').  This flag is enabled by default at
!      '-O3'.  It is also enabled by '-fprofile-use' and '-fauto-profile'.
  
! '-fipa-bit-cp'
       When enabled, perform interprocedural bitwise constant propagation.
!      This flag is enabled by default at '-O2' and by '-fprofile-use' and
!      '-fauto-profile'.  It requires that '-fipa-cp' is enabled.
  
! '-fipa-vrp'
       When enabled, perform interprocedural propagation of value ranges.
!      This flag is enabled by default at '-O2'.  It requires that
!      '-fipa-cp' is enabled.
  
! '-fipa-icf'
       Perform Identical Code Folding for functions and read-only
       variables.  The optimization reduces code size and may disturb
       unwind stacks by replacing a function by equivalent one with a
--- 11489,11633 ----
       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.
  
! ‘-fipa-ra’
       Use caller save registers for allocation if those registers are not
       used by any called function.  In that case it is not necessary to
       save and restore them around calls.  This is only possible if
       called functions are part of same compilation unit as current
       function and they are compiled before it.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’, however the option is
       disabled if generated code will be instrumented for profiling
!      (‘-p’, or ‘-pg’) or if callee's register usage cannot be known
       exactly (this happens on targets that do not expose prologues and
       epilogues in RTL).
  
! ‘-fconserve-stack’
       Attempt to minimize stack usage.  The compiler attempts to use less
       stack space, even if that makes the program slower.  This option
!      implies setting the ‘large-stack-frame’ parameter to 100 and the
!      ‘large-stack-frame-growth’ parameter to 400.
  
! ‘-ftree-reassoc’
       Perform reassociation on trees.  This flag is enabled by default at
!      ‘-O1’ and higher.
  
! ‘-fcode-hoisting’
       Perform code hoisting.  Code hoisting tries to move the evaluation
       of expressions executed on all paths to the function exit as early
       as possible.  This is especially useful as a code size
       optimization, but it often helps for code speed as well.  This flag
!      is enabled by default at ‘-O2’ and higher.
  
! ‘-ftree-pre’
       Perform partial redundancy elimination (PRE) on trees.  This flag
!      is enabled by default at ‘-O2’ and ‘-O3’.
  
! ‘-ftree-partial-pre’
       Make partial redundancy elimination (PRE) more aggressive.  This
!      flag is enabled by default at ‘-O3’.
  
! ‘-ftree-forwprop’
       Perform forward propagation on trees.  This flag is enabled by
!      default at ‘-O1’ 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 ‘-O1’ and higher.
  
! ‘-ftree-phiprop’
       Perform hoisting of loads from conditional pointers on trees.  This
!      pass is enabled by default at ‘-O1’ and higher.
  
! ‘-fhoist-adjacent-loads’
       Speculatively hoist loads from both branches of an if-then-else if
       the loads are from adjacent locations in the same structure and the
       target architecture has a conditional move instruction.  This flag
!      is enabled by default at ‘-O2’ and higher.
  
! ‘-ftree-copy-prop’
       Perform copy propagation on trees.  This pass eliminates
       unnecessary copy operations.  This flag is enabled by default at
!      ‘-O1’ and higher.
  
! ‘-fipa-pure-const’
       Discover which functions are pure or constant.  Enabled by default
!      at ‘-O1’ and higher.
  
! ‘-fipa-reference’
       Discover which static variables do not escape the compilation unit.
!      Enabled by default at ‘-O1’ and higher.
  
! ‘-fipa-reference-addressable’
       Discover read-only, write-only and non-addressable static
!      variables.  Enabled by default at ‘-O1’ and higher.
  
! ‘-fipa-stack-alignment’
       Reduce stack alignment on call sites if possible.  Enabled by
       default.
  
! ‘-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 ‘-O1’ and higher.
  
! ‘-fipa-modref’
       Perform interprocedural mod/ref analysis.  This optimization
       analyzes the side effects of functions (memory locations that are
       modified or referenced) and enables better optimization across the
!      function call boundary.  This flag is enabled by default at ‘-O1’
       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’.  It is also enabled by ‘-fprofile-use’ and
!      ‘-fauto-profile’.
  
! ‘-fipa-cp-clone’
       Perform function cloning to make interprocedural constant
       propagation stronger.  When enabled, interprocedural constant
       propagation performs function cloning when externally visible
       function can be called with constant arguments.  Because this
       optimization can create multiple copies of functions, it may
!      significantly increase code size (see ‘--param
!      ipa-cp-unit-growth=VALUE’).  This flag is enabled by default at
!      ‘-O3’.  It is also enabled by ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-fipa-bit-cp’
       When enabled, perform interprocedural bitwise constant propagation.
!      This flag is enabled by default at ‘-O2’ and by ‘-fprofile-use’ and
!      ‘-fauto-profile’.  It requires that ‘-fipa-cp’ is enabled.
  
! ‘-fipa-vrp’
       When enabled, perform interprocedural propagation of value ranges.
!      This flag is enabled by default at ‘-O2’.  It requires that
!      ‘-fipa-cp’ is enabled.
  
! ‘-fipa-icf’
       Perform Identical Code Folding for functions and read-only
       variables.  The optimization reduces code size and may disturb
       unwind stacks by replacing a function by equivalent one with a
*************** optimizations to be performed is desired
*** 11635,11643 ****
       optimizations are not same - there are equivalences that are found
       only by GCC and equivalences found only by Gold.
  
!      This flag is enabled by default at '-O2' and '-Os'.
  
! '-flive-patching=LEVEL'
       Control GCC's optimizations to produce output suitable for
       live-patching.
  
--- 11639,11647 ----
       optimizations are not same - there are equivalences that are found
       only by GCC and equivalences found only by Gold.
  
!      This flag is enabled by default at ‘-O2’ and ‘-Os’.
  
! ‘-flive-patching=LEVEL’
       Control GCC's optimizations to produce output suitable for
       live-patching.
  
*************** optimizations to be performed is desired
*** 11662,11668 ****
  
       The LEVEL argument should be one of the following:
  
!      'inline-clone'
  
            Only enable inlining and cloning optimizations, which includes
            inlining, cloning, interprocedural scalar replacement of
--- 11666,11672 ----
  
       The LEVEL argument should be one of the following:
  
!      ‘inline-clone’
  
            Only enable inlining and cloning optimizations, which includes
            inlining, cloning, interprocedural scalar replacement of
*************** optimizations to be performed is desired
*** 11670,11676 ****
            function, all its callers and its clones' callers are
            impacted, therefore need to be patched as well.
  
!           '-flive-patching=inline-clone' disables the following
            optimization flags:
                 -fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra
                 -fipa-icf  -fipa-icf-functions  -fipa-icf-variables
--- 11674,11680 ----
            function, all its callers and its clones' callers are
            impacted, therefore need to be patched as well.
  
!           ‘-flive-patching=inline-clone’ disables the following
            optimization flags:
                 -fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra
                 -fipa-icf  -fipa-icf-functions  -fipa-icf-variables
*************** optimizations to be performed is desired
*** 11678,11849 ****
                 -fipa-reference-addressable
                 -fipa-stack-alignment -fipa-modref
  
!      'inline-only-static'
  
            Only enable inlining of static functions.  As a result, when
            patching a static function, all its callers are impacted and
            so need to be patched as well.
  
            In addition to all the flags that
!           '-flive-patching=inline-clone' disables,
!           '-flive-patching=inline-only-static' disables the following
            additional optimization flags:
                 -fipa-cp-clone  -fipa-sra  -fpartial-inlining  -fipa-cp
  
!      When '-flive-patching' is specified without any value, the default
       value is INLINE-CLONE.
  
       This flag is disabled by default.
  
!      Note that '-flive-patching' is not supported with link-time
!      optimization ('-flto').
  
! '-fisolate-erroneous-paths-dereference'
       Detect paths that trigger erroneous or undefined behavior due to
       dereferencing a null pointer.  Isolate those paths from the main
       control flow and turn the statement with erroneous or undefined
!      behavior into a trap.  This flag is enabled by default at '-O2' and
!      higher and depends on '-fdelete-null-pointer-checks' also being
       enabled.
  
! '-fisolate-erroneous-paths-attribute'
       Detect paths that trigger erroneous or undefined behavior due to a
!      null value being used in a way forbidden by a 'returns_nonnull' or
!      'nonnull' attribute.  Isolate those paths from the main control
       flow and turn the statement with erroneous or undefined behavior
       into a trap.  This is not currently enabled, but may be enabled by
!      '-O2' in the future.
  
! '-ftree-sink'
       Perform forward store motion on trees.  This flag is enabled by
!      default at '-O1' 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 '-O1' and
!      higher, except for '-Og'.  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 '-O1' and higher.
  
! '-fssa-backprop'
       Propagate information about uses of a value up the definition chain
       in order to simplify the definitions.  For example, this pass
       strips sign operations if the sign of a value never matters.  The
!      flag is enabled by default at '-O1' and higher.
  
! '-fssa-phiopt'
       Perform pattern matching on SSA PHI nodes to optimize conditional
!      code.  This pass is enabled by default at '-O1' and higher, except
!      for '-Og'.
  
! '-ftree-switch-conversion'
       Perform conversion of simple initializations in a switch to
       initializations from a scalar array.  This flag is enabled by
!      default at '-O2' and higher.
  
! '-ftree-tail-merge'
       Look for identical code sequences.  When found, replace one with a
       jump to the other.  This optimization is known as tail merging or
!      cross jumping.  This flag is enabled by default at '-O2' and
       higher.  The compilation time in this pass can be limited using
!      'max-tail-merge-comparisons' parameter and
!      'max-tail-merge-iterations' parameter.
  
! '-ftree-dce'
       Perform dead code elimination (DCE) on trees.  This flag is enabled
!      by default at '-O1' and higher.
  
! '-ftree-builtin-call-dce'
       Perform conditional dead code elimination (DCE) for calls to
!      built-in functions that may set 'errno' but are otherwise free of
!      side effects.  This flag is enabled by default at '-O2' and higher
!      if '-Os' is not also specified.
  
! '-ffinite-loops'
       Assume that a loop with an exit will eventually take the exit and
       not loop indefinitely.  This allows the compiler to remove loops
       that otherwise have no side-effects, not considering eventual
       endless looping as such.
  
!      This option is enabled by default at '-O2' for C++ with -std=c++11
       or higher.
  
! '-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 '-O1' and higher.
  
! '-ftree-dse'
       Perform dead store elimination (DSE) on trees.  A dead store is a
       store into a memory location that is later overwritten by another
       store without any intervening loads.  In this case the earlier
!      store can be deleted.  This flag is enabled by default at '-O1' 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 '-O1' 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 '-O1' and higher.
  
! '-ftree-loop-linear'
! '-floop-strip-mine'
! '-floop-block'
!      Perform loop nest optimizations.  Same as '-floop-nest-optimize'.
       To use this code transformation, GCC has to be configured with
!      '--with-isl' 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 isl,
       like index splitting and dead code elimination in loops.
  
! '-floop-nest-optimize'
       Enable the isl based loop nest optimizer.  This is a generic loop
       nest optimizer based on the Pluto optimization algorithms.  It
       calculates a loop structure optimized for data-locality and
       parallelism.  This option is experimental.
  
! '-floop-parallelize-all'
       Use the Graphite data dependence analysis to identify loops that
       can be parallelized.  Parallelize all the loops that can be
       analyzed to not contain loop carried dependences without checking
       that it is profitable to parallelize the loops.
  
! '-ftree-coalesce-vars'
       While transforming the program out of the SSA representation,
       attempt to reduce copying by coalescing versions of different
       user-defined variables, instead of just compiler temporaries.  This
       may severely limit the ability to debug an optimized program
!      compiled with '-fno-var-tracking-assignments'.  In the negated
       form, this flag prevents SSA coalescing of user variables.  This
       option is enabled by default if optimization is enabled, and it
       does very little otherwise.
  
! '-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-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
--- 11682,11853 ----
                 -fipa-reference-addressable
                 -fipa-stack-alignment -fipa-modref
  
!      ‘inline-only-static’
  
            Only enable inlining of static functions.  As a result, when
            patching a static function, all its callers are impacted and
            so need to be patched as well.
  
            In addition to all the flags that
!           ‘-flive-patching=inline-clone’ disables,
!           ‘-flive-patching=inline-only-static’ disables the following
            additional optimization flags:
                 -fipa-cp-clone  -fipa-sra  -fpartial-inlining  -fipa-cp
  
!      When ‘-flive-patching’ is specified without any value, the default
       value is INLINE-CLONE.
  
       This flag is disabled by default.
  
!      Note that ‘-flive-patching’ is not supported with link-time
!      optimization (‘-flto’).
  
! ‘-fisolate-erroneous-paths-dereference’
       Detect paths that trigger erroneous or undefined behavior due to
       dereferencing a null pointer.  Isolate those paths from the main
       control flow and turn the statement with erroneous or undefined
!      behavior into a trap.  This flag is enabled by default at ‘-O2’ and
!      higher and depends on ‘-fdelete-null-pointer-checks’ also being
       enabled.
  
! ‘-fisolate-erroneous-paths-attribute’
       Detect paths that trigger erroneous or undefined behavior due to a
!      null value being used in a way forbidden by a ‘returns_nonnull’ or
!      ‘nonnull’ attribute.  Isolate those paths from the main control
       flow and turn the statement with erroneous or undefined behavior
       into a trap.  This is not currently enabled, but may be enabled by
!      ‘-O2’ in the future.
  
! ‘-ftree-sink’
       Perform forward store motion on trees.  This flag is enabled by
!      default at ‘-O1’ 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 ‘-O1’ and
!      higher, except for ‘-Og’.  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 ‘-O1’ and higher.
  
! ‘-fssa-backprop’
       Propagate information about uses of a value up the definition chain
       in order to simplify the definitions.  For example, this pass
       strips sign operations if the sign of a value never matters.  The
!      flag is enabled by default at ‘-O1’ and higher.
  
! ‘-fssa-phiopt’
       Perform pattern matching on SSA PHI nodes to optimize conditional
!      code.  This pass is enabled by default at ‘-O1’ and higher, except
!      for ‘-Og’.
  
! ‘-ftree-switch-conversion’
       Perform conversion of simple initializations in a switch to
       initializations from a scalar array.  This flag is enabled by
!      default at ‘-O2’ and higher.
  
! ‘-ftree-tail-merge’
       Look for identical code sequences.  When found, replace one with a
       jump to the other.  This optimization is known as tail merging or
!      cross jumping.  This flag is enabled by default at ‘-O2’ and
       higher.  The compilation time in this pass can be limited using
!      ‘max-tail-merge-comparisons’ parameter and
!      ‘max-tail-merge-iterations’ parameter.
  
! ‘-ftree-dce’
       Perform dead code elimination (DCE) on trees.  This flag is enabled
!      by default at ‘-O1’ and higher.
  
! ‘-ftree-builtin-call-dce’
       Perform conditional dead code elimination (DCE) for calls to
!      built-in functions that may set ‘errno’ but are otherwise free of
!      side effects.  This flag is enabled by default at ‘-O2’ and higher
!      if ‘-Os’ is not also specified.
  
! ‘-ffinite-loops’
       Assume that a loop with an exit will eventually take the exit and
       not loop indefinitely.  This allows the compiler to remove loops
       that otherwise have no side-effects, not considering eventual
       endless looping as such.
  
!      This option is enabled by default at ‘-O2’ for C++ with -std=c++11
       or higher.
  
! ‘-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 ‘-O1’ and higher.
  
! ‘-ftree-dse’
       Perform dead store elimination (DSE) on trees.  A dead store is a
       store into a memory location that is later overwritten by another
       store without any intervening loads.  In this case the earlier
!      store can be deleted.  This flag is enabled by default at ‘-O1’ 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 ‘-O1’ 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 ‘-O1’ and higher.
  
! ‘-ftree-loop-linear’
! ‘-floop-strip-mine’
! ‘-floop-block’
!      Perform loop nest optimizations.  Same as ‘-floop-nest-optimize’.
       To use this code transformation, GCC has to be configured with
!      ‘--with-isl’ 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 isl,
       like index splitting and dead code elimination in loops.
  
! ‘-floop-nest-optimize’
       Enable the isl based loop nest optimizer.  This is a generic loop
       nest optimizer based on the Pluto optimization algorithms.  It
       calculates a loop structure optimized for data-locality and
       parallelism.  This option is experimental.
  
! ‘-floop-parallelize-all’
       Use the Graphite data dependence analysis to identify loops that
       can be parallelized.  Parallelize all the loops that can be
       analyzed to not contain loop carried dependences without checking
       that it is profitable to parallelize the loops.
  
! ‘-ftree-coalesce-vars’
       While transforming the program out of the SSA representation,
       attempt to reduce copying by coalescing versions of different
       user-defined variables, instead of just compiler temporaries.  This
       may severely limit the ability to debug an optimized program
!      compiled with ‘-fno-var-tracking-assignments’.  In the negated
       form, this flag prevents SSA coalescing of user variables.  This
       option is enabled by default if optimization is enabled, and it
       does very little otherwise.
  
! ‘-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-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
*************** optimizations to be performed is desired
*** 11859,11871 ****
            DO I = 1, N
               D(I) = E(I) * F
            ENDDO
!      This flag is enabled by default at '-O3'.  It is also enabled by
!      '-fprofile-use' and '-fauto-profile'.
  
! '-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 '-O2'
!      and higher, and by '-fprofile-use' and '-fauto-profile'.
  
       This pass distributes the initialization loops and generates a call
       to memset zero.  For example, the loop
--- 11863,11875 ----
            DO I = 1, N
               D(I) = E(I) * F
            ENDDO
!      This flag is enabled by default at ‘-O3’.  It is also enabled by
!      ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-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 ‘-O2’
!      and higher, and by ‘-fprofile-use’ and ‘-fauto-profile’.
  
       This pass distributes the initialization loops and generates a call
       to memset zero.  For example, the loop
*************** optimizations to be performed is desired
*** 11881,11890 ****
               B(I) = A(I) + I
            ENDDO
       and the initialization loop is transformed into a call to memset
!      zero.  This flag is enabled by default at '-O3'.  It is also
!      enabled by '-fprofile-use' and '-fauto-profile'.
  
! '-floop-interchange'
       Perform loop interchange outside of graphite.  This flag can
       improve cache performance on loop nest and allow further loop
       optimizations, like vectorization, to take place.  For example, the
--- 11885,11894 ----
               B(I) = A(I) + I
            ENDDO
       and the initialization loop is transformed into a call to memset
!      zero.  This flag is enabled by default at ‘-O3’.  It is also
!      enabled by ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-floop-interchange’
       Perform loop interchange outside of graphite.  This flag can
       improve cache performance on loop nest and allow further loop
       optimizations, like vectorization, to take place.  For example, the
*************** optimizations to be performed is desired
*** 11898,12018 ****
              for (int k = 0; k < N; k++)
                for (int j = 0; j < N; j++)
                  c[i][j] = c[i][j] + a[i][k]*b[k][j];
!      This flag is enabled by default at '-O3'.  It is also enabled by
!      '-fprofile-use' and '-fauto-profile'.
  
! '-floop-unroll-and-jam'
       Apply unroll and jam transformations on feasible loops.  In a loop
       nest this unrolls the outer loop by some factor and fuses the
       resulting multiple inner loops.  This flag is enabled by default at
!      '-O3'.  It is also enabled by '-fprofile-use' and '-fauto-profile'.
  
! '-ftree-loop-im'
       Perform loop invariant motion on trees.  This pass moves only
       invariants that are hard to handle at RTL level (function calls,
       operations that expand to nontrivial sequences of insns).  With
!      '-funswitch-loops' it also moves operands of conditions that are
       invariant out of the loop, so that we can use just trivial
       invariantness analysis in loop unswitching.  The pass also includes
       store motion.
  
! '-ftree-loop-ivcanon'
       Create a canonical counter for number of iterations in loops for
       which determining number of iterations requires complicated
       analysis.  Later optimizations then may determine the number
       easily.  Useful especially in connection with unrolling.
  
! '-ftree-scev-cprop'
       Perform final value replacement.  If a variable is modified in a
       loop in such a way that its value when exiting the loop can be
       determined using only its initial value and the number of loop
       iterations, replace uses of the final value by such a computation,
       provided it is sufficiently cheap.  This reduces data dependencies
!      and may allow further simplifications.  Enabled by default at '-O1'
       and higher.
  
! '-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 '-O1' and higher, except for '-Og'.
  
! '-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 '-O1' and
!      higher, except for '-Og'.
  
! '-fstore-merging'
       Perform merging of narrow stores to consecutive memory addresses.
       This pass merges contiguous stores of immediate values narrower
       than a word into fewer wider stores to reduce the number of
!      instructions.  This is enabled by default at '-O2' and higher as
!      well as '-Os'.
  
! '-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 '-O1' and higher.
  
! '-ftree-slsr'
       Perform straight-line strength reduction on trees.  This recognizes
       related expressions involving multiplications and replaces them by
       less expensive calculations when possible.  This is enabled by
!      default at '-O1' and higher.
  
! '-ftree-vectorize'
       Perform vectorization on trees.  This flag enables
!      '-ftree-loop-vectorize' and '-ftree-slp-vectorize' if not
       explicitly specified.
  
! '-ftree-loop-vectorize'
       Perform loop vectorization on trees.  This flag is enabled by
!      default at '-O2' and by '-ftree-vectorize', '-fprofile-use', and
!      '-fauto-profile'.
  
! '-ftree-slp-vectorize'
       Perform basic block vectorization on trees.  This flag is enabled
!      by default at '-O2' and by '-ftree-vectorize', '-fprofile-use', and
!      '-fauto-profile'.
  
! '-ftrivial-auto-var-init=CHOICE'
       Initialize automatic variables with either a pattern or with zeroes
       to increase the security and predictability of a program by
       preventing uninitialized memory disclosure and use.  GCC still
       considers an automatic variable that doesn't have an explicit
!      initializer as uninitialized, '-Wuninitialized' and
!      '-Wanalyzer-use-of-uninitialized-value' will still report warning
       messages on such automatic variables and the compiler will perform
       optimization as if the variable were uninitialized.  With this
       option, GCC will also initialize any padding of automatic variables
       that have structure or union types to zeroes.  However, the current
       implementation cannot initialize automatic variables that are
       declared between the controlling expression and the first case of a
!      'switch' statement.  Using '-Wtrivial-auto-var-init' to report all
       such cases.
  
       The three values of CHOICE are:
  
!         * 'uninitialized' doesn't initialize any automatic variables.
            This is C and C++'s default.
  
!         * 'pattern' Initialize automatic variables with values which
            will likely transform logic bugs into crashes down the line,
            are easily recognized in a crash dump and without being values
            that programmers can rely on for useful program semantics.
--- 11902,12022 ----
              for (int k = 0; k < N; k++)
                for (int j = 0; j < N; j++)
                  c[i][j] = c[i][j] + a[i][k]*b[k][j];
!      This flag is enabled by default at ‘-O3’.  It is also enabled by
!      ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-floop-unroll-and-jam’
       Apply unroll and jam transformations on feasible loops.  In a loop
       nest this unrolls the outer loop by some factor and fuses the
       resulting multiple inner loops.  This flag is enabled by default at
!      ‘-O3’.  It is also enabled by ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-ftree-loop-im’
       Perform loop invariant motion on trees.  This pass moves only
       invariants that are hard to handle at RTL level (function calls,
       operations that expand to nontrivial sequences of insns).  With
!      ‘-funswitch-loops’ it also moves operands of conditions that are
       invariant out of the loop, so that we can use just trivial
       invariantness analysis in loop unswitching.  The pass also includes
       store motion.
  
! ‘-ftree-loop-ivcanon’
       Create a canonical counter for number of iterations in loops for
       which determining number of iterations requires complicated
       analysis.  Later optimizations then may determine the number
       easily.  Useful especially in connection with unrolling.
  
! ‘-ftree-scev-cprop’
       Perform final value replacement.  If a variable is modified in a
       loop in such a way that its value when exiting the loop can be
       determined using only its initial value and the number of loop
       iterations, replace uses of the final value by such a computation,
       provided it is sufficiently cheap.  This reduces data dependencies
!      and may allow further simplifications.  Enabled by default at ‘-O1’
       and higher.
  
! ‘-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 ‘-O1’ and higher, except for ‘-Og’.
  
! ‘-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 ‘-O1’ and
!      higher, except for ‘-Og’.
  
! ‘-fstore-merging’
       Perform merging of narrow stores to consecutive memory addresses.
       This pass merges contiguous stores of immediate values narrower
       than a word into fewer wider stores to reduce the number of
!      instructions.  This is enabled by default at ‘-O2’ and higher as
!      well as ‘-Os’.
  
! ‘-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 ‘-O1’ and higher.
  
! ‘-ftree-slsr’
       Perform straight-line strength reduction on trees.  This recognizes
       related expressions involving multiplications and replaces them by
       less expensive calculations when possible.  This is enabled by
!      default at ‘-O1’ and higher.
  
! ‘-ftree-vectorize’
       Perform vectorization on trees.  This flag enables
!      ‘-ftree-loop-vectorize’ and ‘-ftree-slp-vectorize’ if not
       explicitly specified.
  
! ‘-ftree-loop-vectorize’
       Perform loop vectorization on trees.  This flag is enabled by
!      default at ‘-O2’ and by ‘-ftree-vectorize’, ‘-fprofile-use’, and
!      ‘-fauto-profile’.
  
! ‘-ftree-slp-vectorize’
       Perform basic block vectorization on trees.  This flag is enabled
!      by default at ‘-O2’ and by ‘-ftree-vectorize’, ‘-fprofile-use’, and
!      ‘-fauto-profile’.
  
! ‘-ftrivial-auto-var-init=CHOICE’
       Initialize automatic variables with either a pattern or with zeroes
       to increase the security and predictability of a program by
       preventing uninitialized memory disclosure and use.  GCC still
       considers an automatic variable that doesn't have an explicit
!      initializer as uninitialized, ‘-Wuninitialized’ and
!      ‘-Wanalyzer-use-of-uninitialized-value’ will still report warning
       messages on such automatic variables and the compiler will perform
       optimization as if the variable were uninitialized.  With this
       option, GCC will also initialize any padding of automatic variables
       that have structure or union types to zeroes.  However, the current
       implementation cannot initialize automatic variables that are
       declared between the controlling expression and the first case of a
!      ‘switch’ statement.  Using ‘-Wtrivial-auto-var-init’ to report all
       such cases.
  
       The three values of CHOICE are:
  
!         • ‘uninitialized’ doesn't initialize any automatic variables.
            This is C and C++'s default.
  
!         • ‘pattern’ Initialize automatic variables with values which
            will likely transform logic bugs into crashes down the line,
            are easily recognized in a crash dump and without being values
            that programmers can rely on for useful program semantics.
*************** optimizations to be performed is desired
*** 12020,12081 ****
            The values used for pattern initialization might be changed in
            the future.
  
!         * 'zero' Initialize automatic variables with zeroes.
  
!      The default is 'uninitialized'.
  
       You can control this behavior for a specific variable by using the
!      variable attribute 'uninitialized' (*note Variable Attributes::).
  
! '-fvect-cost-model=MODEL'
       Alter the cost model used for vectorization.  The MODEL argument
!      should be one of 'unlimited', 'dynamic', 'cheap' or 'very-cheap'.
!      With the 'unlimited' model the vectorized code-path is assumed to
!      be profitable while with the 'dynamic' model a runtime check guards
       the vectorized code-path to enable it only for iteration counts
       that will likely execute faster than when executing the original
!      scalar loop.  The 'cheap' model disables vectorization of loops
       where doing so would be cost prohibitive for example due to
       required runtime checks for data dependence or alignment but
!      otherwise is equal to the 'dynamic' model.  The 'very-cheap' model
       only allows vectorization if the vector code would entirely replace
       the scalar code that is being vectorized.  For example, if each
       iteration of a vectorized loop would only be able to handle exactly
!      four iterations of the scalar loop, the 'very-cheap' model would
       only allow vectorization if the scalar iteration count is known to
       be a multiple of four.
  
       The default cost model depends on other optimization flags and is
!      either 'dynamic' or 'cheap'.
  
! '-fsimd-cost-model=MODEL'
       Alter the cost model used for vectorization of loops marked with
       the OpenMP simd directive.  The MODEL argument should be one of
!      'unlimited', 'dynamic', 'cheap'.  All values of MODEL have the same
!      meaning as described in '-fvect-cost-model' and by default a cost
!      model defined with '-fvect-cost-model' is used.
  
! '-ftree-vrp'
       Perform Value Range Propagation on trees.  This is similar to the
       constant propagation pass, but instead of values, ranges of values
       are propagated.  This allows the optimizers to remove unnecessary
       range checks like array bound checks and null pointer checks.  This
!      is enabled by default at '-O2' and higher.  Null pointer check
!      elimination is only done if '-fdelete-null-pointer-checks' is
       enabled.
  
! '-fsplit-paths'
       Split paths leading to loop backedges.  This can improve dead code
       elimination and common subexpression elimination.  This is enabled
!      by default at '-O3' and above.
  
! '-fsplit-ivs-in-unroller'
       Enables expression of values of induction variables in later
       iterations of the unrolled loop using the value in the first
       iteration.  This breaks long dependency chains, thus improving
       efficiency of the scheduling passes.
  
!      A combination of '-fweb' and CSE is often sufficient to obtain the
       same effect.  However, that is not reliable in cases where the loop
       body is more complicated than a single basic block.  It also does
       not work at all on some architectures due to restrictions in the
--- 12024,12085 ----
            The values used for pattern initialization might be changed in
            the future.
  
!         • ‘zero’ Initialize automatic variables with zeroes.
  
!      The default is ‘uninitialized’.
  
       You can control this behavior for a specific variable by using the
!      variable attribute ‘uninitialized’ (*note Variable Attributes::).
  
! ‘-fvect-cost-model=MODEL’
       Alter the cost model used for vectorization.  The MODEL argument
!      should be one of ‘unlimited’, ‘dynamic’, ‘cheap’ or ‘very-cheap’.
!      With the ‘unlimited’ model the vectorized code-path is assumed to
!      be profitable while with the ‘dynamic’ model a runtime check guards
       the vectorized code-path to enable it only for iteration counts
       that will likely execute faster than when executing the original
!      scalar loop.  The ‘cheap’ model disables vectorization of loops
       where doing so would be cost prohibitive for example due to
       required runtime checks for data dependence or alignment but
!      otherwise is equal to the ‘dynamic’ model.  The ‘very-cheap’ model
       only allows vectorization if the vector code would entirely replace
       the scalar code that is being vectorized.  For example, if each
       iteration of a vectorized loop would only be able to handle exactly
!      four iterations of the scalar loop, the ‘very-cheap’ model would
       only allow vectorization if the scalar iteration count is known to
       be a multiple of four.
  
       The default cost model depends on other optimization flags and is
!      either ‘dynamic’ or ‘cheap’.
  
! ‘-fsimd-cost-model=MODEL’
       Alter the cost model used for vectorization of loops marked with
       the OpenMP simd directive.  The MODEL argument should be one of
!      ‘unlimited’, ‘dynamic’, ‘cheap’.  All values of MODEL have the same
!      meaning as described in ‘-fvect-cost-model’ and by default a cost
!      model defined with ‘-fvect-cost-model’ is used.
  
! ‘-ftree-vrp’
       Perform Value Range Propagation on trees.  This is similar to the
       constant propagation pass, but instead of values, ranges of values
       are propagated.  This allows the optimizers to remove unnecessary
       range checks like array bound checks and null pointer checks.  This
!      is enabled by default at ‘-O2’ and higher.  Null pointer check
!      elimination is only done if ‘-fdelete-null-pointer-checks’ is
       enabled.
  
! ‘-fsplit-paths’
       Split paths leading to loop backedges.  This can improve dead code
       elimination and common subexpression elimination.  This is enabled
!      by default at ‘-O3’ and above.
  
! ‘-fsplit-ivs-in-unroller’
       Enables expression of values of induction variables in later
       iterations of the unrolled loop using the value in the first
       iteration.  This breaks long dependency chains, thus improving
       efficiency of the scheduling passes.
  
!      A combination of ‘-fweb’ and CSE is often sufficient to obtain the
       same effect.  However, that is not reliable in cases where the loop
       body is more complicated than a single basic block.  It also does
       not work at all on some architectures due to restrictions in the
*************** optimizations to be performed is desired
*** 12083,12089 ****
  
       This optimization is enabled by default.
  
! '-fvariable-expansion-in-unroller'
       With this option, the compiler creates multiple copies of some
       local variables when unrolling a loop, which can result in superior
       code.
--- 12087,12093 ----
  
       This optimization is enabled by default.
  
! ‘-fvariable-expansion-in-unroller’
       With this option, the compiler creates multiple copies of some
       local variables when unrolling a loop, which can result in superior
       code.
*************** optimizations to be performed is desired
*** 12091,12112 ****
       This optimization is enabled by default for PowerPC targets, but
       disabled by default otherwise.
  
! '-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 levels '-O2', '-O3', '-Os'.
  
! '-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'.  It is also enabled by
!      '-fprofile-use' and '-fauto-profile'.
  
! '-fprefetch-loop-arrays'
       If supported by the target machine, generate instructions to
       prefetch memory to improve the performance of loops that access
       large arrays.
--- 12095,12116 ----
       This optimization is enabled by default for PowerPC targets, but
       disabled by default otherwise.
  
! ‘-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 levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-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’.  It is also enabled by
!      ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-fprefetch-loop-arrays’
       If supported by the target machine, generate instructions to
       prefetch memory to improve the performance of loops that access
       large arrays.
*************** optimizations to be performed is desired
*** 12114,12195 ****
       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-printf-return-value'
       Do not substitute constants for known return value of formatted
!      output functions such as 'sprintf', 'snprintf', 'vsprintf', and
!      'vsnprintf' (but not 'printf' of 'fprintf').  This transformation
       allows GCC to optimize or even eliminate branches based on the
       known return value of these functions called with arguments that
       are either constant, or whose values are known to be in a range
       that makes determining the exact return value possible.  For
!      example, when '-fprintf-return-value' is in effect, both the branch
!      and the body of the 'if' statement (but not the call to 'snprint')
!      can be optimized away when 'i' is a 32-bit or smaller integer
       because the return value is guaranteed to be at most 8.
  
            char buf[9];
            if (snprintf (buf, "%08x", i) >= sizeof buf)
              ...
  
!      The '-fprintf-return-value' option relies on other optimizations
!      and yields best results with '-O2' and above.  It works in tandem
!      with the '-Wformat-overflow' and '-Wformat-truncation' options.
!      The '-fprintf-return-value' option is enabled by default.
  
! '-fno-peephole'
! '-fno-peephole2'
       Disable any machine-specific peephole optimizations.  The
!      difference between '-fno-peephole' and '-fno-peephole2' is in how
       they are implemented in the compiler; some targets use one, some
       use the other, a few use both.
  
!      '-fpeephole' is enabled by default.  '-fpeephole2' enabled at
!      levels '-O2', '-O3', '-Os'.
  
! '-fno-guess-branch-probability'
       Do not guess branch probabilities using heuristics.
  
       GCC uses heuristics to guess branch probabilities if they are not
!      provided by profiling feedback ('-fprofile-arcs').  These
       heuristics are based on the control flow graph.  If some branch
!      probabilities are specified by '__builtin_expect', then the
       heuristics are used to guess branch probabilities for the rest of
!      the control flow graph, taking the '__builtin_expect' info into
       account.  The interactions between the heuristics and
!      '__builtin_expect' can be complex, and in some cases, it may be
       useful to disable the heuristics so that the effects of
!      '__builtin_expect' are easier to understand.
  
       It is also possible to specify expected probability of the
!      expression with '__builtin_expect_with_probability' built-in
       function.
  
!      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 '-O1', '-O2', '-O3', '-Os'.
  
! '-freorder-blocks-algorithm=ALGORITHM'
       Use the specified algorithm for basic block reordering.  The
!      ALGORITHM argument can be 'simple', which does not increase code
       size (except sometimes due to secondary effects like alignment), or
!      'stc', the "software trace cache" algorithm, which tries to put all
       often executed code together, minimizing the number of branches
       executed by making extra copies of code.
  
!      The default is 'simple' at levels '-O1', '-Os', and 'stc' 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
--- 12118,12199 ----
       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-printf-return-value’
       Do not substitute constants for known return value of formatted
!      output functions such as ‘sprintf’, ‘snprintf’, ‘vsprintf’, and
!      ‘vsnprintf’ (but not ‘printf’ of ‘fprintf’).  This transformation
       allows GCC to optimize or even eliminate branches based on the
       known return value of these functions called with arguments that
       are either constant, or whose values are known to be in a range
       that makes determining the exact return value possible.  For
!      example, when ‘-fprintf-return-value’ is in effect, both the branch
!      and the body of the ‘if’ statement (but not the call to ‘snprint’)
!      can be optimized away when ‘i’ is a 32-bit or smaller integer
       because the return value is guaranteed to be at most 8.
  
            char buf[9];
            if (snprintf (buf, "%08x", i) >= sizeof buf)
              ...
  
!      The ‘-fprintf-return-value’ option relies on other optimizations
!      and yields best results with ‘-O2’ and above.  It works in tandem
!      with the ‘-Wformat-overflow’ and ‘-Wformat-truncation’ options.
!      The ‘-fprintf-return-value’ option is enabled by default.
  
! ‘-fno-peephole’
! ‘-fno-peephole2’
       Disable any machine-specific peephole optimizations.  The
!      difference between ‘-fno-peephole’ and ‘-fno-peephole2’ is in how
       they are implemented in the compiler; some targets use one, some
       use the other, a few use both.
  
!      ‘-fpeephole’ is enabled by default.  ‘-fpeephole2’ enabled at
!      levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fno-guess-branch-probability’
       Do not guess branch probabilities using heuristics.
  
       GCC uses heuristics to guess branch probabilities if they are not
!      provided by profiling feedback (‘-fprofile-arcs’).  These
       heuristics are based on the control flow graph.  If some branch
!      probabilities are specified by ‘__builtin_expect’, then the
       heuristics are used to guess branch probabilities for the rest of
!      the control flow graph, taking the ‘__builtin_expect’ info into
       account.  The interactions between the heuristics and
!      ‘__builtin_expect’ can be complex, and in some cases, it may be
       useful to disable the heuristics so that the effects of
!      ‘__builtin_expect’ are easier to understand.
  
       It is also possible to specify expected probability of the
!      expression with ‘__builtin_expect_with_probability’ built-in
       function.
  
!      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 ‘-O1’, ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-freorder-blocks-algorithm=ALGORITHM’
       Use the specified algorithm for basic block reordering.  The
!      ALGORITHM argument can be ‘simple’, which does not increase code
       size (except sometimes due to secondary effects like alignment), or
!      ‘stc’, the "software trace cache" algorithm, which tries to put all
       often executed code together, minimizing the number of branches
       executed by making extra copies of code.
  
!      The default is ‘simple’ at levels ‘-O1’, ‘-Os’, and ‘stc’ 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
*************** optimizations to be performed is desired
*** 12197,12231 ****
       setjump/longjump or target specific scheme), for linkonce sections,
       for functions with a user-defined section attribute and on any
       architecture that does not support named sections.  When
!      '-fsplit-stack' is used this option is not enabled by default (to
       avoid linker errors), but may be enabled explicitly (if using a
       working linker).
  
!      Enabled for x86 at levels '-O2', '-O3', '-Os'.
  
! '-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.
  
       This option isn't effective unless you either provide profile
!      feedback (see '-fprofile-arcs' for details) or manually annotate
!      functions with 'hot' or 'cold' attributes (*note Common Function
       Attributes::).
  
!      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:
--- 12201,12235 ----
       setjump/longjump or target specific scheme), for linkonce sections,
       for functions with a user-defined section attribute and on any
       architecture that does not support named sections.  When
!      ‘-fsplit-stack’ is used this option is not enabled by default (to
       avoid linker errors), but may be enabled explicitly (if using a
       working linker).
  
!      Enabled for x86 at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-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.
  
       This option isn't effective unless you either provide profile
!      feedback (see ‘-fprofile-arcs’ for details) or manually annotate
!      functions with ‘hot’ or ‘cold’ attributes (*note Common Function
       Attributes::).
  
!      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:
*************** optimizations to be performed is desired
*** 12241,12247 ****
            }
       The practice of reading from a different union member than the one
       most recently written to (called "type-punning") is common.  Even
!      with '-fstrict-aliasing', type-punning is allowed, provided the
       memory is accessed through the union type.  So, the code above
       works as expected.  *Note Structures unions enumerations and
       bit-fields implementation::.  However, this code might not:
--- 12245,12251 ----
            }
       The practice of reading from a different union member than the one
       most recently written to (called "type-punning") is common.  Even
!      with ‘-fstrict-aliasing’, type-punning is allowed, provided the
       memory is accessed through the union type.  So, the code above
       works as expected.  *Note Structures unions enumerations and
       bit-fields implementation::.  However, this code might not:
*************** optimizations to be performed is desired
*** 12261,12283 ****
              return ((union a_union *) &d)->i;
            }
  
!      The '-fstrict-aliasing' option is enabled at levels '-O2', '-O3',
!      '-Os'.
  
! '-fipa-strict-aliasing'
!      Controls whether rules of '-fstrict-aliasing' are applied across
       function boundaries.  Note that if multiple functions gets inlined
       into a single function the memory accesses are no longer considered
       to be crossing a function boundary.
  
!      The '-fipa-strict-aliasing' option is enabled by default and is
!      effective only in combination with '-fstrict-aliasing'.
  
! '-falign-functions'
! '-falign-functions=N'
! '-falign-functions=N:M'
! '-falign-functions=N:M:N2'
! '-falign-functions=N:M:N2:M2'
       Align the start of functions to the next power-of-two greater than
       or equal to N, skipping up to M-1 bytes.  This ensures that at
       least the first M bytes of the function can be fetched by the CPU
--- 12265,12287 ----
              return ((union a_union *) &d)->i;
            }
  
!      The ‘-fstrict-aliasing’ option is enabled at levels ‘-O2’, ‘-O3’,
!      ‘-Os’.
  
! ‘-fipa-strict-aliasing’
!      Controls whether rules of ‘-fstrict-aliasing’ are applied across
       function boundaries.  Note that if multiple functions gets inlined
       into a single function the memory accesses are no longer considered
       to be crossing a function boundary.
  
!      The ‘-fipa-strict-aliasing’ option is enabled by default and is
!      effective only in combination with ‘-fstrict-aliasing’.
  
! ‘-falign-functions’
! ‘-falign-functions=N’
! ‘-falign-functions=N:M’
! ‘-falign-functions=N:M:N2’
! ‘-falign-functions=N:M:N2:M2’
       Align the start of functions to the next power-of-two greater than
       or equal to N, skipping up to M-1 bytes.  This ensures that at
       least the first M bytes of the function can be fetched by the CPU
*************** optimizations to be performed is desired
*** 12285,12298 ****
  
       If M is not specified, it defaults to N.
  
!      Examples: '-falign-functions=32' aligns functions to the next
!      32-byte boundary, '-falign-functions=24' aligns to the next 32-byte
       boundary only if this can be done by skipping 23 bytes or less,
!      '-falign-functions=32:7' aligns to the next 32-byte boundary only
       if this can be done by skipping 6 bytes or less.
  
       The second pair of N2:M2 values allows you to specify a secondary
!      alignment: '-falign-functions=64:7:32:3' aligns to the next 64-byte
       boundary if this can be done by skipping 6 bytes or less, otherwise
       aligns to the next 32-byte boundary if this can be done by skipping
       2 bytes or less.  If M2 is not specified, it defaults to N2.
--- 12289,12302 ----
  
       If M is not specified, it defaults to N.
  
!      Examples: ‘-falign-functions=32’ aligns functions to the next
!      32-byte boundary, ‘-falign-functions=24’ aligns to the next 32-byte
       boundary only if this can be done by skipping 23 bytes or less,
!      ‘-falign-functions=32:7’ aligns to the next 32-byte boundary only
       if this can be done by skipping 6 bytes or less.
  
       The second pair of N2:M2 values allows you to specify a secondary
!      alignment: ‘-falign-functions=64:7:32:3’ aligns to the next 64-byte
       boundary if this can be done by skipping 6 bytes or less, otherwise
       aligns to the next 32-byte boundary if this can be done by skipping
       2 bytes or less.  If M2 is not specified, it defaults to N2.
*************** optimizations to be performed is desired
*** 12300,12434 ****
       Some assemblers only support this flag when N is a power of two; in
       that case, it is rounded up.
  
!      '-fno-align-functions' and '-falign-functions=1' are equivalent and
       mean that functions are not aligned.
  
       If N is not specified or is zero, use a machine-dependent default.
       The maximum allowed N option value is 65536.
  
!      Enabled at levels '-O2', '-O3'.
  
! '-flimit-function-alignment'
       If this option is enabled, the compiler tries to avoid
       unnecessarily overaligning functions.  It attempts to instruct the
!      assembler to align by the amount specified by '-falign-functions',
       but not to skip more bytes than the size of the function.
  
! '-falign-labels'
! '-falign-labels=N'
! '-falign-labels=N:M'
! '-falign-labels=N:M:N2'
! '-falign-labels=N:M:N2:M2'
       Align all branch targets to a power-of-two boundary.
  
!      Parameters of this option are analogous to the '-falign-functions'
!      option.  '-fno-align-labels' and '-falign-labels=1' are equivalent
       and mean that labels are not aligned.
  
!      If '-falign-loops' or '-falign-jumps' are applicable and are
       greater than this value, then their values are used instead.
  
       If N is not specified or is zero, use a machine-dependent default
!      which is very likely to be '1', meaning no alignment.  The maximum
       allowed N option value is 65536.
  
!      Enabled at levels '-O2', '-O3'.
  
! '-falign-loops'
! '-falign-loops=N'
! '-falign-loops=N:M'
! '-falign-loops=N:M:N2'
! '-falign-loops=N:M:N2:M2'
       Align loops to a power-of-two boundary.  If the loops are executed
       many times, this makes up for any execution of the dummy padding
       instructions.
  
!      If '-falign-labels' is greater than this value, then its value is
       used instead.
  
!      Parameters of this option are analogous to the '-falign-functions'
!      option.  '-fno-align-loops' and '-falign-loops=1' are equivalent
       and mean that loops are not aligned.  The maximum allowed N option
       value is 65536.
  
       If N is not specified or is zero, use a machine-dependent default.
  
!      Enabled at levels '-O2', '-O3'.
  
! '-falign-jumps'
! '-falign-jumps=N'
! '-falign-jumps=N:M'
! '-falign-jumps=N:M:N2'
! '-falign-jumps=N:M:N2:M2'
       Align branch targets to a power-of-two boundary, for branch targets
       where the targets can only be reached by jumping.  In this case, no
       dummy operations need be executed.
  
!      If '-falign-labels' is greater than this value, then its value is
       used instead.
  
!      Parameters of this option are analogous to the '-falign-functions'
!      option.  '-fno-align-jumps' and '-falign-jumps=1' are equivalent
       and mean that loops are not aligned.
  
       If N is not specified or is zero, use a machine-dependent default.
       The maximum allowed N option value is 65536.
  
!      Enabled at levels '-O2', '-O3'.
  
! '-fno-allocation-dce'
       Do not remove unused C++ allocations in dead code elimination.
  
! '-fallow-store-data-races'
       Allow the compiler to perform optimizations that may introduce new
       data races on stores, without proving that the variable cannot be
       concurrently accessed by other threads.  Does not affect
       optimization of local data.  It is safe to use this option if it is
       known that global data will not be accessed by multiple threads.
  
!      Examples of optimizations enabled by '-fallow-store-data-races'
       include hoisting or if-conversions that may cause a value that was
       already in memory to be re-written with that same value.  Such
       re-writing is safe in a single threaded context but may be unsafe
       in a multi-threaded context.  Note that on some processors,
       if-conversions may be required in order to enable vectorization.
  
!      Enabled at level '-Ofast'.
  
! '-funit-at-a-time'
!      This option is left for compatibility reasons.  '-funit-at-a-time'
!      has no effect, while '-fno-unit-at-a-time' implies
!      '-fno-toplevel-reorder' and '-fno-section-anchors'.
  
       Enabled by default.
  
! '-fno-toplevel-reorder'
!      Do not reorder top-level functions, variables, and 'asm'
       statements.  Output them in the same order that they appear in the
       input file.  When this option is used, unreferenced static
       variables are not removed.  This option is intended to support
       existing code that relies on a particular ordering.  For new code,
       it is better to use attributes when possible.
  
!      '-ftoplevel-reorder' is the default at '-O1' and higher, and also
!      at '-O0' if '-fsection-anchors' is explicitly requested.
!      Additionally '-fno-toplevel-reorder' implies
!      '-fno-section-anchors'.
  
! '-funreachable-traps'
       With this option, the compiler turns calls to
!      '__builtin_unreachable' into traps, instead of using them for
       optimization.  This also affects any such calls implicitly
       generated by the compiler.
  
!      This option has the same effect as '-fsanitize=unreachable
!      -fsanitize-trap=unreachable', but does not affect the values of
!      those options.  If '-fsanitize=unreachable' is enabled, that option
       takes priority over this one.
  
!      This option is enabled by default at '-O0' and '-Og'.
  
! '-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
--- 12304,12438 ----
       Some assemblers only support this flag when N is a power of two; in
       that case, it is rounded up.
  
!      ‘-fno-align-functions’ and ‘-falign-functions=1’ are equivalent and
       mean that functions are not aligned.
  
       If N is not specified or is zero, use a machine-dependent default.
       The maximum allowed N option value is 65536.
  
!      Enabled at levels ‘-O2’, ‘-O3’.
  
! ‘-flimit-function-alignment’
       If this option is enabled, the compiler tries to avoid
       unnecessarily overaligning functions.  It attempts to instruct the
!      assembler to align by the amount specified by ‘-falign-functions’,
       but not to skip more bytes than the size of the function.
  
! ‘-falign-labels’
! ‘-falign-labels=N’
! ‘-falign-labels=N:M’
! ‘-falign-labels=N:M:N2’
! ‘-falign-labels=N:M:N2:M2’
       Align all branch targets to a power-of-two boundary.
  
!      Parameters of this option are analogous to the ‘-falign-functions’
!      option.  ‘-fno-align-labels’ and ‘-falign-labels=1’ are equivalent
       and mean that labels are not aligned.
  
!      If ‘-falign-loops’ or ‘-falign-jumps’ are applicable and are
       greater than this value, then their values are used instead.
  
       If N is not specified or is zero, use a machine-dependent default
!      which is very likely to be ‘1’, meaning no alignment.  The maximum
       allowed N option value is 65536.
  
!      Enabled at levels ‘-O2’, ‘-O3’.
  
! ‘-falign-loops’
! ‘-falign-loops=N’
! ‘-falign-loops=N:M’
! ‘-falign-loops=N:M:N2’
! ‘-falign-loops=N:M:N2:M2’
       Align loops to a power-of-two boundary.  If the loops are executed
       many times, this makes up for any execution of the dummy padding
       instructions.
  
!      If ‘-falign-labels’ is greater than this value, then its value is
       used instead.
  
!      Parameters of this option are analogous to the ‘-falign-functions’
!      option.  ‘-fno-align-loops’ and ‘-falign-loops=1’ are equivalent
       and mean that loops are not aligned.  The maximum allowed N option
       value is 65536.
  
       If N is not specified or is zero, use a machine-dependent default.
  
!      Enabled at levels ‘-O2’, ‘-O3’.
  
! ‘-falign-jumps’
! ‘-falign-jumps=N’
! ‘-falign-jumps=N:M’
! ‘-falign-jumps=N:M:N2’
! ‘-falign-jumps=N:M:N2:M2’
       Align branch targets to a power-of-two boundary, for branch targets
       where the targets can only be reached by jumping.  In this case, no
       dummy operations need be executed.
  
!      If ‘-falign-labels’ is greater than this value, then its value is
       used instead.
  
!      Parameters of this option are analogous to the ‘-falign-functions’
!      option.  ‘-fno-align-jumps’ and ‘-falign-jumps=1’ are equivalent
       and mean that loops are not aligned.
  
       If N is not specified or is zero, use a machine-dependent default.
       The maximum allowed N option value is 65536.
  
!      Enabled at levels ‘-O2’, ‘-O3’.
  
! ‘-fno-allocation-dce’
       Do not remove unused C++ allocations in dead code elimination.
  
! ‘-fallow-store-data-races’
       Allow the compiler to perform optimizations that may introduce new
       data races on stores, without proving that the variable cannot be
       concurrently accessed by other threads.  Does not affect
       optimization of local data.  It is safe to use this option if it is
       known that global data will not be accessed by multiple threads.
  
!      Examples of optimizations enabled by ‘-fallow-store-data-races’
       include hoisting or if-conversions that may cause a value that was
       already in memory to be re-written with that same value.  Such
       re-writing is safe in a single threaded context but may be unsafe
       in a multi-threaded context.  Note that on some processors,
       if-conversions may be required in order to enable vectorization.
  
!      Enabled at level ‘-Ofast’.
  
! ‘-funit-at-a-time’
!      This option is left for compatibility reasons.  ‘-funit-at-a-time’
!      has no effect, while ‘-fno-unit-at-a-time’ implies
!      ‘-fno-toplevel-reorder’ and ‘-fno-section-anchors’.
  
       Enabled by default.
  
! ‘-fno-toplevel-reorder’
!      Do not reorder top-level functions, variables, and ‘asm’
       statements.  Output them in the same order that they appear in the
       input file.  When this option is used, unreferenced static
       variables are not removed.  This option is intended to support
       existing code that relies on a particular ordering.  For new code,
       it is better to use attributes when possible.
  
!      ‘-ftoplevel-reorder’ is the default at ‘-O1’ and higher, and also
!      at ‘-O0’ if ‘-fsection-anchors’ is explicitly requested.
!      Additionally ‘-fno-toplevel-reorder’ implies
!      ‘-fno-section-anchors’.
  
! ‘-funreachable-traps’
       With this option, the compiler turns calls to
!      ‘__builtin_unreachable’ into traps, instead of using them for
       optimization.  This also affects any such calls implicitly
       generated by the compiler.
  
!      This option has the same effect as ‘-fsanitize=unreachable
!      -fsanitize-trap=unreachable’, but does not affect the values of
!      those options.  If ‘-fsanitize=unreachable’ is enabled, that option
       takes priority over this one.
  
!      This option is enabled by default at ‘-O0’ and ‘-Og’.
  
! ‘-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
*************** optimizations to be performed is desired
*** 12437,12459 ****
       debugging impossible, since variables no longer stay in a "home
       register".
  
!      Enabled by default with '-funroll-loops'.
  
! '-fwhole-program'
       Assume that the current compilation unit represents the whole
       program being compiled.  All public functions and variables with
!      the exception of 'main' and those merged by attribute
!      'externally_visible' become static functions and in effect are
       optimized more aggressively by interprocedural optimizers.
  
!      With '-flto' this option has a limited use.  In most cases the
       precise list of symbols used or exported from the binary is known
       the resolution info passed to the link-time optimizer by the linker
       plugin.  It is still useful if no linker plugin is used or during
!      incremental link step when final code is produced (with '-flto'
!      '-flinker-output=nolto-rel').
  
! '-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
--- 12441,12463 ----
       debugging impossible, since variables no longer stay in a "home
       register".
  
!      Enabled by default with ‘-funroll-loops’.
  
! ‘-fwhole-program’
       Assume that the current compilation unit represents the whole
       program being compiled.  All public functions and variables with
!      the exception of ‘main’ and those merged by attribute
!      ‘externally_visible’ become static functions and in effect are
       optimized more aggressively by interprocedural optimizers.
  
!      With ‘-flto’ this option has a limited use.  In most cases the
       precise list of symbols used or exported from the binary is known
       the resolution info passed to the link-time optimizer by the linker
       plugin.  It is still useful if no linker plugin is used or during
!      incremental link step when final code is produced (with ‘-flto’
!      ‘-flinker-output=nolto-rel’).
  
! ‘-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
*************** optimizations to be performed is desired
*** 12461,12467 ****
       function bodies are read from these ELF sections and instantiated
       as if they had been part of the same translation unit.
  
!      To use the link-time optimizer, '-flto' and optimization options
       should be specified at compile time and during the final link.  It
       is recommended that you compile all the files participating in the
       same link with the same options and also specify those options at
--- 12465,12471 ----
       function bodies are read from these ELF sections and instantiated
       as if they had been part of the same translation unit.
  
!      To use the link-time optimizer, ‘-flto’ and optimization options
       should be specified at compile time and during the final link.  It
       is recommended that you compile all the files participating in the
       same link with the same options and also specify those options at
*************** optimizations to be performed is desired
*** 12472,12520 ****
            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 important thing to keep in mind is that to enable link-time
       optimizations you need to use the GCC driver to perform the link
       step.  GCC automatically performs link-time optimization if any of
!      the objects involved were compiled with the '-flto' command-line
       option.  You can always override the automatic decision to do
!      link-time optimization by passing '-fno-lto' to the link command.
  
       To make whole program optimization effective, it is necessary to
       make certain whole program assumptions.  The compiler needs to know
       what functions and variables can be accessed by libraries and
       runtime outside of the link-time optimized unit.  When supported by
!      the linker, the linker plugin (see '-fuse-linker-plugin') passes
       information to the compiler about used and externally visible
       symbols.  When the linker plugin is not available,
!      '-fwhole-program' should be used to allow the compiler to make
       these assumptions, which leads to more aggressive optimization
       decisions.
  
!      When a file is compiled with '-flto' without '-fuse-linker-plugin',
       the generated object file is larger than a regular object file
       because it contains GIMPLE bytecodes and the usual final code (see
!      '-ffat-lto-objects').  This means that object files with LTO
!      information can be linked as normal object files; if '-fno-lto' is
       passed to the linker, no interprocedural optimizations are applied.
!      Note that when '-fno-fat-lto-objects' is enabled the compile stage
       is faster but you cannot perform a regular, non-LTO link on them.
  
       When producing the final binary, GCC only applies link-time
--- 12476,12524 ----
            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 important thing to keep in mind is that to enable link-time
       optimizations you need to use the GCC driver to perform the link
       step.  GCC automatically performs link-time optimization if any of
!      the objects involved were compiled with the ‘-flto’ command-line
       option.  You can always override the automatic decision to do
!      link-time optimization by passing ‘-fno-lto’ to the link command.
  
       To make whole program optimization effective, it is necessary to
       make certain whole program assumptions.  The compiler needs to know
       what functions and variables can be accessed by libraries and
       runtime outside of the link-time optimized unit.  When supported by
!      the linker, the linker plugin (see ‘-fuse-linker-plugin’) passes
       information to the compiler about used and externally visible
       symbols.  When the linker plugin is not available,
!      ‘-fwhole-program’ should be used to allow the compiler to make
       these assumptions, which leads to more aggressive optimization
       decisions.
  
!      When a file is compiled with ‘-flto’ without ‘-fuse-linker-plugin’,
       the generated object file is larger than a regular object file
       because it contains GIMPLE bytecodes and the usual final code (see
!      ‘-ffat-lto-objects’).  This means that object files with LTO
!      information can be linked as normal object files; if ‘-fno-lto’ is
       passed to the linker, no interprocedural optimizations are applied.
!      Note that when ‘-fno-fat-lto-objects’ is enabled the compile stage
       is faster but you cannot perform a regular, non-LTO link on them.
  
       When producing the final binary, GCC only applies link-time
*************** optimizations to be performed is desired
*** 12529,12535 ****
       link-time options from the settings used to compile the input
       files.
  
!      If you do not specify an optimization level option '-O' at link
       time, then GCC uses the highest optimization level used when
       compiling the object files.  Note that it is generally ineffective
       to specify an optimization level option only at link time and not
--- 12533,12539 ----
       link-time options from the settings used to compile the input
       files.
  
!      If you do not specify an optimization level option ‘-O’ at link
       time, then GCC uses the highest optimization level used when
       compiling the object files.  Note that it is generally ineffective
       to specify an optimization level option only at link time and not
*************** optimizations to be performed is desired
*** 12543,12552 ****
       generating bytecodes, as they need to be used during the final
       link.  Currently, the following options and their settings are
       taken from the first object file that explicitly specifies them:
!      '-fcommon', '-fexceptions', '-fnon-call-exceptions', '-fgnu-tm' and
!      all the '-m' target flags.
  
!      The following options '-fPIC', '-fpic', '-fpie' and '-fPIE' are
       combined based on the following scheme:
  
            -fPIC + -fpic = -fpic
--- 12547,12556 ----
       generating bytecodes, as they need to be used during the final
       link.  Currently, the following options and their settings are
       taken from the first object file that explicitly specifies them:
!      ‘-fcommon’, ‘-fexceptions’, ‘-fnon-call-exceptions’, ‘-fgnu-tm’ and
!      all the ‘-m’ target flags.
  
!      The following options ‘-fPIC’, ‘-fpic’, ‘-fpie’ and ‘-fPIE’ are
       combined based on the following scheme:
  
            -fPIC + -fpic = -fpic
*************** optimizations to be performed is desired
*** 12559,12575 ****
       Certain ABI-changing flags are required to match in all compilation
       units, and trying to override this at link time with a conflicting
       value is ignored.  This includes options such as
!      '-freg-struct-return' and '-fpcc-struct-return'.
  
!      Other options such as '-ffp-contract', '-fno-strict-overflow',
!      '-fwrapv', '-fno-trapv' or '-fno-strict-aliasing' are passed
       through to the link stage and merged conservatively for conflicting
!      translation units.  Specifically '-fno-strict-overflow', '-fwrapv'
!      and '-fno-trapv' take precedence; and for example
!      '-ffp-contract=off' takes precedence over '-ffp-contract=fast'.
       You can override them at link time.
  
!      Diagnostic options such as '-Wstringop-overflow' are passed through
       to the link stage and their setting matches that of the
       compile-step at function granularity.  Note that this matters only
       for diagnostics emitted during optimization.  Note that code
--- 12563,12579 ----
       Certain ABI-changing flags are required to match in all compilation
       units, and trying to override this at link time with a conflicting
       value is ignored.  This includes options such as
!      ‘-freg-struct-return’ and ‘-fpcc-struct-return’.
  
!      Other options such as ‘-ffp-contract’, ‘-fno-strict-overflow’,
!      ‘-fwrapv’, ‘-fno-trapv’ or ‘-fno-strict-aliasing’ are passed
       through to the link stage and merged conservatively for conflicting
!      translation units.  Specifically ‘-fno-strict-overflow’, ‘-fwrapv’
!      and ‘-fno-trapv’ take precedence; and for example
!      ‘-ffp-contract=off’ takes precedence over ‘-ffp-contract=fast’.
       You can override them at link time.
  
!      Diagnostic options such as ‘-Wstringop-overflow’ are passed through
       to the link stage and their setting matches that of the
       compile-step at function granularity.  Note that this matters only
       for diagnostics emitted during optimization.  Note that code
*************** optimizations to be performed is desired
*** 12577,12593 ****
       disabled for regions if code not consistent with the setting at
       compile time.
  
!      When you need to pass options to the assembler via '-Wa' or
!      '-Xassembler' make sure to either compile such translation units
!      with '-fno-lto' or consistently use the same assembler options on
       all translation units.  You can alternatively also specify
       assembler options at LTO link time.
  
!      To enable debug info generation you need to supply '-g' at compile
       time.  If any of the input files at link time were built with debug
       info generation enabled the link will enable debug info generation
       as well.  Any elaborate debug info settings like the dwarf level
!      '-gdwarf-5' need to be explicitly repeated at the linker command
       line and mixing different settings in different translation units
       is discouraged.
  
--- 12581,12597 ----
       disabled for regions if code not consistent with the setting at
       compile time.
  
!      When you need to pass options to the assembler via ‘-Wa’ or
!      ‘-Xassembler’ make sure to either compile such translation units
!      with ‘-fno-lto’ or consistently use the same assembler options on
       all translation units.  You can alternatively also specify
       assembler options at LTO link time.
  
!      To enable debug info generation you need to supply ‘-g’ at compile
       time.  If any of the input files at link time were built with debug
       info generation enabled the link will enable debug info generation
       as well.  Any elaborate debug info settings like the dwarf level
!      ‘-gdwarf-5’ need to be explicitly repeated at the linker command
       line and mixing different settings in different translation units
       is discouraged.
  
*************** optimizations to be performed is desired
*** 12606,12648 ****
            gfortran -c -flto baz.f90
            g++ -o myprog -flto -O3 foo.o bar.o baz.o -lgfortran
  
!      Notice that the final link is done with 'g++' to get the C++
!      runtime libraries and '-lgfortran' is added to get the Fortran
       runtime libraries.  In general, when mixing languages in LTO mode,
       you should use the same link command options as when mixing
       languages in a regular (non-LTO) compilation.
  
       If object files containing GIMPLE bytecode are stored in a library
!      archive, say 'libfoo.a', it is possible to extract and use them in
       an LTO link if you are using a linker with plugin support.  To
!      create static libraries suitable for LTO, use 'gcc-ar' and
!      'gcc-ranlib' instead of 'ar' and 'ranlib'; to show the symbols of
!      object files with GIMPLE bytecode, use 'gcc-nm'.  Those commands
!      require that 'ar', 'ranlib' and 'nm' have been compiled with plugin
!      support.  At link time, use the flag '-fuse-linker-plugin' to
       ensure that the library participates in the LTO optimization
       process:
  
            gcc -o myprog -O2 -flto -fuse-linker-plugin a.o b.o -lfoo
  
       With the linker plugin enabled, the linker extracts the needed
!      GIMPLE files from 'libfoo.a' and passes them on to the running GCC
       to make them part of the aggregated GIMPLE image to be optimized.
  
       If you are not using a linker with plugin support and/or do not
!      enable the linker plugin, then the objects inside 'libfoo.a' are
       extracted and linked as usual, but they do not participate in the
       LTO optimization process.  In order to make a static library
       suitable for both LTO optimization and usual linkage, compile its
!      object files with '-flto' '-ffat-lto-objects'.
  
       Link-time optimizations do not require the presence of the whole
       program to operate.  If the program does not require any symbols to
!      be exported, it is possible to combine '-flto' and
!      '-fwhole-program' to allow the interprocedural optimizers to use
       more aggressive assumptions which may lead to improved optimization
!      opportunities.  Use of '-fwhole-program' is not needed when linker
!      plugin is active (see '-fuse-linker-plugin').
  
       The current implementation of LTO makes no attempt to generate
       bytecode that is portable between different types of hosts.  The
--- 12610,12652 ----
            gfortran -c -flto baz.f90
            g++ -o myprog -flto -O3 foo.o bar.o baz.o -lgfortran
  
!      Notice that the final link is done with ‘g++’ to get the C++
!      runtime libraries and ‘-lgfortran’ is added to get the Fortran
       runtime libraries.  In general, when mixing languages in LTO mode,
       you should use the same link command options as when mixing
       languages in a regular (non-LTO) compilation.
  
       If object files containing GIMPLE bytecode are stored in a library
!      archive, say ‘libfoo.a’, it is possible to extract and use them in
       an LTO link if you are using a linker with plugin support.  To
!      create static libraries suitable for LTO, use ‘gcc-ar’ and
!      ‘gcc-ranlib’ instead of ‘ar’ and ‘ranlib’; to show the symbols of
!      object files with GIMPLE bytecode, use ‘gcc-nm’.  Those commands
!      require that ‘ar’, ‘ranlib’ and ‘nm’ have been compiled with plugin
!      support.  At link time, use the flag ‘-fuse-linker-plugin’ to
       ensure that the library participates in the LTO optimization
       process:
  
            gcc -o myprog -O2 -flto -fuse-linker-plugin a.o b.o -lfoo
  
       With the linker plugin enabled, the linker extracts the needed
!      GIMPLE files from ‘libfoo.a’ and passes them on to the running GCC
       to make them part of the aggregated GIMPLE image to be optimized.
  
       If you are not using a linker with plugin support and/or do not
!      enable the linker plugin, then the objects inside ‘libfoo.a’ are
       extracted and linked as usual, but they do not participate in the
       LTO optimization process.  In order to make a static library
       suitable for both LTO optimization and usual linkage, compile its
!      object files with ‘-flto’ ‘-ffat-lto-objects’.
  
       Link-time optimizations do not require the presence of the whole
       program to operate.  If the program does not require any symbols to
!      be exported, it is possible to combine ‘-flto’ and
!      ‘-fwhole-program’ to allow the interprocedural optimizers to use
       more aggressive assumptions which may lead to improved optimization
!      opportunities.  Use of ‘-fwhole-program’ is not needed when linker
!      plugin is active (see ‘-fuse-linker-plugin’).
  
       The current implementation of LTO makes no attempt to generate
       bytecode that is portable between different types of hosts.  The
*************** optimizations to be performed is desired
*** 12656,12694 ****
  
       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.
  
!      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.
       Even without the option value, GCC tries to automatically detect a
       running GNU make's job server.
  
!      Use '-flto=auto' to use GNU make's job server, if available, or
       otherwise fall back to autodetection of the number of CPU threads
       present in your system.
  
! '-flto-partition=ALG'
       Specify the partitioning algorithm used by the link-time optimizer.
!      The value is either '1to1' to specify a partitioning mirroring the
!      original source files or 'balanced' to specify partitioning into
!      equally sized chunks (whenever possible) or 'max' to create new
!      partition for every symbol where possible.  Specifying 'none' as an
       algorithm disables partitioning and streaming completely.  The
!      default value is 'balanced'.  While '1to1' can be used as an
!      workaround for various code ordering issues, the 'max' partitioning
!      is intended for internal testing only.  The value 'one' specifies
!      that exactly one partition should be used while the value 'none'
       bypasses partitioning and executes the link-time optimization step
       directly from the WPA phase.
  
! '-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').  GCC currently
       supports two LTO compression algorithms.  For zstd, valid values
       are 0 (no compression) to 19 (maximum compression), while zlib
       supports values from 0 to 9.  Values outside this range are clamped
--- 12660,12698 ----
  
       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.
  
!      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.
       Even without the option value, GCC tries to automatically detect a
       running GNU make's job server.
  
!      Use ‘-flto=auto’ to use GNU make's job server, if available, or
       otherwise fall back to autodetection of the number of CPU threads
       present in your system.
  
! ‘-flto-partition=ALG’
       Specify the partitioning algorithm used by the link-time optimizer.
!      The value is either ‘1to1’ to specify a partitioning mirroring the
!      original source files or ‘balanced’ to specify partitioning into
!      equally sized chunks (whenever possible) or ‘max’ to create new
!      partition for every symbol where possible.  Specifying ‘none’ as an
       algorithm disables partitioning and streaming completely.  The
!      default value is ‘balanced’.  While ‘1to1’ can be used as an
!      workaround for various code ordering issues, the ‘max’ partitioning
!      is intended for internal testing only.  The value ‘one’ specifies
!      that exactly one partition should be used while the value ‘none’
       bypasses partitioning and executes the link-time optimization step
       directly from the WPA phase.
  
! ‘-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’).  GCC currently
       supports two LTO compression algorithms.  For zstd, valid values
       are 0 (no compression) to 19 (maximum compression), while zlib
       supports values from 0 to 9.  Values outside this range are clamped
*************** optimizations to be performed is desired
*** 12696,12702 ****
       option is not given, a default balanced compression setting is
       used.
  
! '-fuse-linker-plugin'
       Enables the use of a linker plugin during link-time optimization.
       This option relies on plugin support in the linker, which is
       available in gold or in GNU ld 2.21 or newer.
--- 12700,12706 ----
       option is not given, a default balanced compression setting is
       used.
  
! ‘-fuse-linker-plugin’
       Enables the use of a linker plugin during link-time optimization.
       This option relies on plugin support in the linker, which is
       available in gold or in GNU ld 2.21 or newer.
*************** optimizations to be performed is desired
*** 12707,12743 ****
       This information specifies what symbols can be accessed externally
       (by non-LTO object or during dynamic linking).  Resulting code
       quality improvements on binaries (and shared libraries that use
!      hidden visibility) are similar to '-fwhole-program'.  See '-flto'
       for a description of the effect of this flag and how to use it.
  
       This option is enabled by default when LTO support in GCC is
       enabled and GCC was configured for use with a linker supporting
       plugins (GNU ld 2.21 or newer or gold).
  
! '-ffat-lto-objects'
       Fat LTO objects are object files that contain both the intermediate
       language and the object code.  This makes them usable for both LTO
       linking and normal linking.  This option is effective only when
!      compiling with '-flto' and is ignored at link time.
  
!      '-fno-fat-lto-objects' improves compilation time over plain LTO,
       but requires the complete toolchain to be aware of LTO. It requires
       a linker with linker plugin support for basic functionality.
!      Additionally, 'nm', 'ar' and 'ranlib' need to support linker
       plugins to allow a full-featured build environment (capable of
!      building static libraries etc).  GCC provides the 'gcc-ar',
!      'gcc-nm', 'gcc-ranlib' wrappers to pass the right options to these
       tools.  With non fat LTO makefiles need to be modified to use them.
  
       Note that modern binutils provide plugin auto-load mechanism.
!      Installing the linker plugin into '$libdir/bfd-plugins' has the
!      same effect as usage of the command wrappers ('gcc-ar', 'gcc-nm'
!      and 'gcc-ranlib').
  
!      The default is '-fno-fat-lto-objects' on targets with linker plugin
       support.
  
! '-fcompare-elim'
       After register allocation and post-register allocation instruction
       splitting, identify arithmetic instructions that compute processor
       flags similar to a comparison operation based on that arithmetic.
--- 12711,12747 ----
       This information specifies what symbols can be accessed externally
       (by non-LTO object or during dynamic linking).  Resulting code
       quality improvements on binaries (and shared libraries that use
!      hidden visibility) are similar to ‘-fwhole-program’.  See ‘-flto’
       for a description of the effect of this flag and how to use it.
  
       This option is enabled by default when LTO support in GCC is
       enabled and GCC was configured for use with a linker supporting
       plugins (GNU ld 2.21 or newer or gold).
  
! ‘-ffat-lto-objects’
       Fat LTO objects are object files that contain both the intermediate
       language and the object code.  This makes them usable for both LTO
       linking and normal linking.  This option is effective only when
!      compiling with ‘-flto’ and is ignored at link time.
  
!      ‘-fno-fat-lto-objects’ improves compilation time over plain LTO,
       but requires the complete toolchain to be aware of LTO. It requires
       a linker with linker plugin support for basic functionality.
!      Additionally, ‘nm’, ‘ar’ and ‘ranlib’ need to support linker
       plugins to allow a full-featured build environment (capable of
!      building static libraries etc).  GCC provides the ‘gcc-ar’,
!      ‘gcc-nm’, ‘gcc-ranlib’ wrappers to pass the right options to these
       tools.  With non fat LTO makefiles need to be modified to use them.
  
       Note that modern binutils provide plugin auto-load mechanism.
!      Installing the linker plugin into ‘$libdir/bfd-plugins’ has the
!      same effect as usage of the command wrappers (‘gcc-ar’, ‘gcc-nm’
!      and ‘gcc-ranlib’).
  
!      The default is ‘-fno-fat-lto-objects’ on targets with linker plugin
       support.
  
! ‘-fcompare-elim’
       After register allocation and post-register allocation instruction
       splitting, identify arithmetic instructions that compute processor
       flags similar to a comparison operation based on that arithmetic.
*************** optimizations to be performed is desired
*** 12747,12785 ****
       represent the comparison operation before register allocation is
       complete.
  
!      Enabled at levels '-O1', '-O2', '-O3', '-Os'.
  
! '-fcprop-registers'
       After register allocation and post-register allocation instruction
       splitting, perform a copy-propagation pass to try to reduce
       scheduling dependencies and occasionally eliminate the copy.
  
!      Enabled at levels '-O1', '-O2', '-O3', '-Os'.
  
! '-fprofile-correction'
       Profiles collected using an instrumented binary for multi-threaded
       programs may be inconsistent due to missed counter updates.  When
       this option is specified, GCC uses heuristics to correct or smooth
       out such inconsistencies.  By default, GCC emits an error message
       when an inconsistent profile is detected.
  
!      This option is enabled by '-fauto-profile'.
  
! '-fprofile-partial-training'
!      With '-fprofile-use' all portions of programs not executed during
       train run are optimized agressively for size rather than speed.  In
       some cases it is not practical to train all possible hot paths in
       the program.  (For example, program may contain functions specific
       for a given hardware and trianing may not cover all hardware
       configurations program is run on.)  With
!      '-fprofile-partial-training' profile feedback will be ignored for
       all functions not executed during the train run leading them to be
       optimized as if they were compiled without profile feedback.  This
       leads to better performance when train run is not representative
       but also leads to significantly bigger code.
  
! '-fprofile-use'
! '-fprofile-use=PATH'
       Enable profile feedback-directed optimizations, and the following
       optimizations, many of which are generally profitable only with
       profile feedback available:
--- 12751,12789 ----
       represent the comparison operation before register allocation is
       complete.
  
!      Enabled at levels ‘-O1’, ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fcprop-registers’
       After register allocation and post-register allocation instruction
       splitting, perform a copy-propagation pass to try to reduce
       scheduling dependencies and occasionally eliminate the copy.
  
!      Enabled at levels ‘-O1’, ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-fprofile-correction’
       Profiles collected using an instrumented binary for multi-threaded
       programs may be inconsistent due to missed counter updates.  When
       this option is specified, GCC uses heuristics to correct or smooth
       out such inconsistencies.  By default, GCC emits an error message
       when an inconsistent profile is detected.
  
!      This option is enabled by ‘-fauto-profile’.
  
! ‘-fprofile-partial-training’
!      With ‘-fprofile-use’ all portions of programs not executed during
       train run are optimized agressively for size rather than speed.  In
       some cases it is not practical to train all possible hot paths in
       the program.  (For example, program may contain functions specific
       for a given hardware and trianing may not cover all hardware
       configurations program is run on.)  With
!      ‘-fprofile-partial-training’ profile feedback will be ignored for
       all functions not executed during the train run leading them to be
       optimized as if they were compiled without profile feedback.  This
       leads to better performance when train run is not representative
       but also leads to significantly bigger code.
  
! ‘-fprofile-use’
! ‘-fprofile-use=PATH’
       Enable profile feedback-directed optimizations, and the following
       optimizations, many of which are generally profitable only with
       profile feedback available:
*************** optimizations to be performed is desired
*** 12794,12813 ****
  
       Before you can use this option, you must first generate profiling
       information.  *Note Instrumentation Options::, for information
!      about the '-fprofile-generate' option.
  
       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 '-Wno-error=coverage-mismatch'.  Note this may result in
       poorly optimized code.  Additionally, by default, GCC also emits a
       warning message if the feedback profiles do not exist (see
!      '-Wmissing-profile').
  
       If PATH is specified, GCC looks at the PATH to find the profile
!      feedback data files.  See '-fprofile-dir'.
  
! '-fauto-profile'
! '-fauto-profile=PATH'
       Enable sampling-based feedback-directed optimizations, and the
       following optimizations, many of which are generally profitable
       only with profile feedback available:
--- 12798,12817 ----
  
       Before you can use this option, you must first generate profiling
       information.  *Note Instrumentation Options::, for information
!      about the ‘-fprofile-generate’ option.
  
       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 ‘-Wno-error=coverage-mismatch’.  Note this may result in
       poorly optimized code.  Additionally, by default, GCC also emits a
       warning message if the feedback profiles do not exist (see
!      ‘-Wmissing-profile’).
  
       If PATH is specified, GCC looks at the PATH to find the profile
!      feedback data files.  See ‘-fprofile-dir’.
  
! ‘-fauto-profile’
! ‘-fauto-profile=PATH’
       Enable sampling-based feedback-directed optimizations, and the
       following optimizations, many of which are generally profitable
       only with profile feedback available:
*************** optimizations to be performed is desired
*** 12821,12837 ****
            -fprofile-correction
  
       PATH is the name of a file containing AutoFDO profile information.
!      If omitted, it defaults to 'fbdata.afdo' in the current directory.
  
       Producing an AutoFDO profile data file requires running your
!      program with the 'perf' utility on a supported GNU/Linux target
       system.  For more information, see .
  
       E.g.
            perf record -e br_inst_retired:near_taken -b -o perf.data \
                -- your_program
  
!      Then use the 'create_gcov' tool to convert the raw profile data to
       a format that can be used by GCC.  You must also supply the
       unstripped binary for your program to this tool.  See
       .
--- 12825,12841 ----
            -fprofile-correction
  
       PATH is the name of a file containing AutoFDO profile information.
!      If omitted, it defaults to ‘fbdata.afdo’ in the current directory.
  
       Producing an AutoFDO profile data file requires running your
!      program with the ‘perf’ utility on a supported GNU/Linux target
       system.  For more information, see .
  
       E.g.
            perf record -e br_inst_retired:near_taken -b -o perf.data \
                -- your_program
  
!      Then use the ‘create_gcov’ tool to convert the raw profile data to
       a format that can be used by GCC.  You must also supply the
       unstripped binary for your program to this tool.  See
       .
*************** optimizations to be performed is desired
*** 12844,12920 ****
  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 operations occur in a format with
       more precision or range than the IEEE standard and interchange
!      floating-point types.  By default, '-fexcess-precision=fast' is in
       effect; this means that operations may be carried out in a wider
       precision than the types specified in the source if that would
       result in faster code, and it is unpredictable when rounding to the
       types specified in the source code takes place.  When compiling C
!      or C++, if '-fexcess-precision=standard' is specified then excess
       precision follows the rules specified in ISO C99 or C++; 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 or C++ if a
!      strict conformance option such as '-std=c99' or '-std=c++17' is
!      used.  '-ffast-math' enables '-fexcess-precision=fast' by default
       regardless of whether a strict conformance option is used.
  
!      '-fexcess-precision=standard' is not implemented for languages
       other than C or C++.  On the x86, it 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 the options '-fno-math-errno', '-funsafe-math-optimizations',
!      '-ffinite-math-only', '-fno-rounding-math', '-fno-signaling-nans',
!      '-fcx-limited-range' and '-fexcess-precision=fast'.
  
!      This option causes the preprocessor macro '__FAST_MATH__' to be
       defined.
  
!      This option is not turned on by any '-O' option besides '-Ofast'
       since it can result in incorrect output for programs that depend on
       an exact implementation of IEEE or ISO rules/specifications for
       math functions.  It may, however, yield faster code for programs
       that do not require the guarantees of these specifications.
  
! '-fno-math-errno'
!      Do not set 'errno' after calling math functions that are executed
!      with a single instruction, e.g., 'sqrt'.  A program that relies on
       IEEE exceptions for math error handling may want to use this flag
       for speed while maintaining IEEE arithmetic compatibility.
  
!      This option is not turned on by any '-O' option since it can result
       in incorrect output for programs that depend on an exact
       implementation of IEEE or ISO rules/specifications for math
       functions.  It may, however, yield faster code for programs that do
       not require the guarantees of these specifications.
  
!      The default is '-fmath-errno'.
  
!      On Darwin systems, the math library never sets 'errno'.  There is
       therefore no reason for the compiler to consider the possibility
!      that it might, and '-fno-math-errno' is the default.
  
! '-funsafe-math-optimizations'
  
       Allow optimizations for floating-point arithmetic that (a) assume
       that arguments and results are valid and (b) may violate IEEE or
--- 12848,12924 ----
  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 operations occur in a format with
       more precision or range than the IEEE standard and interchange
!      floating-point types.  By default, ‘-fexcess-precision=fast’ is in
       effect; this means that operations may be carried out in a wider
       precision than the types specified in the source if that would
       result in faster code, and it is unpredictable when rounding to the
       types specified in the source code takes place.  When compiling C
!      or C++, if ‘-fexcess-precision=standard’ is specified then excess
       precision follows the rules specified in ISO C99 or C++; 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 or C++ if a
!      strict conformance option such as ‘-std=c99’ or ‘-std=c++17’ is
!      used.  ‘-ffast-math’ enables ‘-fexcess-precision=fast’ by default
       regardless of whether a strict conformance option is used.
  
!      ‘-fexcess-precision=standard’ is not implemented for languages
       other than C or C++.  On the x86, it 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 the options ‘-fno-math-errno’, ‘-funsafe-math-optimizations’,
!      ‘-ffinite-math-only’, ‘-fno-rounding-math’, ‘-fno-signaling-nans’,
!      ‘-fcx-limited-range’ and ‘-fexcess-precision=fast’.
  
!      This option causes the preprocessor macro ‘__FAST_MATH__’ to be
       defined.
  
!      This option is not turned on by any ‘-O’ option besides ‘-Ofast’
       since it can result in incorrect output for programs that depend on
       an exact implementation of IEEE or ISO rules/specifications for
       math functions.  It may, however, yield faster code for programs
       that do not require the guarantees of these specifications.
  
! ‘-fno-math-errno’
!      Do not set ‘errno’ after calling math functions that are executed
!      with a single instruction, e.g., ‘sqrt’.  A program that relies on
       IEEE exceptions for math error handling may want to use this flag
       for speed while maintaining IEEE arithmetic compatibility.
  
!      This option is not turned on by any ‘-O’ option since it can result
       in incorrect output for programs that depend on an exact
       implementation of IEEE or ISO rules/specifications for math
       functions.  It may, however, yield faster code for programs that do
       not require the guarantees of these specifications.
  
!      The default is ‘-fmath-errno’.
  
!      On Darwin systems, the math library never sets ‘errno’.  There is
       therefore no reason for the compiler to consider the possibility
!      that it might, and ‘-fno-math-errno’ is the default.
  
! ‘-funsafe-math-optimizations’
  
       Allow optimizations for floating-point arithmetic that (a) assume
       that arguments and results are valid and (b) may violate IEEE or
*************** correctness.  All must be specifically e
*** 12922,13007 ****
       or startup files that change the default FPU control word or other
       similar optimizations.
  
!      This option is not turned on by any '-O' option since it can result
       in incorrect output for programs that depend on an exact
       implementation of IEEE or ISO rules/specifications for math
       functions.  It may, however, yield faster code for programs that do
       not require the guarantees of these specifications.  Enables
!      '-fno-signed-zeros', '-fno-trapping-math', '-fassociative-math' and
!      '-freciprocal-math'.
  
!      The default is '-fno-unsafe-math-optimizations'.
  
! '-fassociative-math'
  
       Allow re-association of operands in series of floating-point
       operations.  This violates the ISO C and C++ language standard by
       possibly changing computation result.  NOTE: re-ordering may change
       the sign of zero as well as ignore NaNs and inhibit or create
       underflow or overflow (and thus cannot be used on code that relies
!      on rounding behavior like '(x + 2**52) - 2**52'.  May also reorder
       floating-point comparisons and thus may not be used when ordered
       comparisons are required.  This option requires that both
!      '-fno-signed-zeros' and '-fno-trapping-math' be in effect.
!      Moreover, it doesn't make much sense with '-frounding-math'.  For
       Fortran the option is automatically enabled when both
!      '-fno-signed-zeros' and '-fno-trapping-math' are in effect.
  
!      The default is '-fno-associative-math'.
  
! '-freciprocal-math'
  
       Allow the reciprocal of a value to be used instead of dividing by
!      the value if this enables optimizations.  For example 'x / y' can
!      be replaced with 'x * (1/y)', which is useful if '(1/y)' is subject
       to common subexpression elimination.  Note that this loses
       precision and increases the number of flops operating on the value.
  
!      The default is '-fno-reciprocal-math'.
  
! '-ffinite-math-only'
       Allow optimizations for floating-point arithmetic that assume that
       arguments and results are not NaNs or +-Infs.
  
!      This option is not turned on by any '-O' option since it can result
       in incorrect output for programs that depend on an exact
       implementation of IEEE or ISO rules/specifications for math
       functions.  It may, however, yield faster code for programs that do
       not require the guarantees of these specifications.
  
!      The default is '-fno-finite-math-only'.
  
! '-fno-signed-zeros'
       Allow optimizations for floating-point arithmetic that ignore the
       signedness of zero.  IEEE arithmetic specifies the behavior of
!      distinct +0.0 and -0.0 values, which then prohibits simplification
       of expressions such as x+0.0 or 0.0*x (even with
!      '-ffinite-math-only').  This option implies that the sign of a zero
       result isn't significant.
  
!      The default is '-fsigned-zeros'.
  
! '-fno-trapping-math'
       Compile code assuming that floating-point operations cannot
       generate user-visible traps.  These traps include division by zero,
       overflow, underflow, inexact result and invalid operation.  This
!      option requires that '-fno-signaling-nans' be in effect.  Setting
       this option may allow faster code if one relies on "non-stop" IEEE
       arithmetic, for example.
  
!      This option should never be turned on by any '-O' option since it
       can result in incorrect output for programs that depend on an exact
       implementation of IEEE or ISO rules/specifications for math
       functions.
  
!      The default is '-ftrapping-math'.
  
       Future versions of GCC may provide finer control of this setting
!      using C99's 'FENV_ACCESS' pragma.  This command-line option will be
!      used along with '-frounding-math' to specify the default state for
!      'FENV_ACCESS'.
  
! '-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
--- 12926,13011 ----
       or startup files that change the default FPU control word or other
       similar optimizations.
  
!      This option is not turned on by any ‘-O’ option since it can result
       in incorrect output for programs that depend on an exact
       implementation of IEEE or ISO rules/specifications for math
       functions.  It may, however, yield faster code for programs that do
       not require the guarantees of these specifications.  Enables
!      ‘-fno-signed-zeros’, ‘-fno-trapping-math’, ‘-fassociative-math’ and
!      ‘-freciprocal-math’.
  
!      The default is ‘-fno-unsafe-math-optimizations’.
  
! ‘-fassociative-math’
  
       Allow re-association of operands in series of floating-point
       operations.  This violates the ISO C and C++ language standard by
       possibly changing computation result.  NOTE: re-ordering may change
       the sign of zero as well as ignore NaNs and inhibit or create
       underflow or overflow (and thus cannot be used on code that relies
!      on rounding behavior like ‘(x + 2**52) - 2**52’.  May also reorder
       floating-point comparisons and thus may not be used when ordered
       comparisons are required.  This option requires that both
!      ‘-fno-signed-zeros’ and ‘-fno-trapping-math’ be in effect.
!      Moreover, it doesn't make much sense with ‘-frounding-math’.  For
       Fortran the option is automatically enabled when both
!      ‘-fno-signed-zeros’ and ‘-fno-trapping-math’ are in effect.
  
!      The default is ‘-fno-associative-math’.
  
! ‘-freciprocal-math’
  
       Allow the reciprocal of a value to be used instead of dividing by
!      the value if this enables optimizations.  For example ‘x / y’ can
!      be replaced with ‘x * (1/y)’, which is useful if ‘(1/y)’ is subject
       to common subexpression elimination.  Note that this loses
       precision and increases the number of flops operating on the value.
  
!      The default is ‘-fno-reciprocal-math’.
  
! ‘-ffinite-math-only’
       Allow optimizations for floating-point arithmetic that assume that
       arguments and results are not NaNs or +-Infs.
  
!      This option is not turned on by any ‘-O’ option since it can result
       in incorrect output for programs that depend on an exact
       implementation of IEEE or ISO rules/specifications for math
       functions.  It may, however, yield faster code for programs that do
       not require the guarantees of these specifications.
  
!      The default is ‘-fno-finite-math-only’.
  
! ‘-fno-signed-zeros’
       Allow optimizations for floating-point arithmetic that ignore the
       signedness of zero.  IEEE arithmetic specifies the behavior of
!      distinct +0.0 and −0.0 values, which then prohibits simplification
       of expressions such as x+0.0 or 0.0*x (even with
!      ‘-ffinite-math-only’).  This option implies that the sign of a zero
       result isn't significant.
  
!      The default is ‘-fsigned-zeros’.
  
! ‘-fno-trapping-math’
       Compile code assuming that floating-point operations cannot
       generate user-visible traps.  These traps include division by zero,
       overflow, underflow, inexact result and invalid operation.  This
!      option requires that ‘-fno-signaling-nans’ be in effect.  Setting
       this option may allow faster code if one relies on "non-stop" IEEE
       arithmetic, for example.
  
!      This option should never be turned on by any ‘-O’ option since it
       can result in incorrect output for programs that depend on an exact
       implementation of IEEE or ISO rules/specifications for math
       functions.
  
!      The default is ‘-ftrapping-math’.
  
       Future versions of GCC may provide finer control of this setting
!      using C99's ‘FENV_ACCESS’ pragma.  This command-line option will be
!      used along with ‘-frounding-math’ to specify the default state for
!      ‘FENV_ACCESS’.
  
! ‘-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
*************** correctness.  All must be specifically e
*** 13013,13140 ****
       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 along with '-ftrapping-math' 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.
  
! '-fno-fp-int-builtin-inexact'
!      Do not allow the built-in functions 'ceil', 'floor', 'round' and
!      'trunc', and their 'float' and 'long double' variants, to generate
       code that raises the "inexact" floating-point exception for
       noninteger arguments.  ISO C99 and C11 allow these functions to
       raise the "inexact" exception, but ISO/IEC TS 18661-1:2014, the C
       bindings to IEEE 754-2008, as integrated into ISO C2X, does not
       allow these functions to do so.
  
!      The default is '-ffp-int-builtin-inexact', allowing the exception
       to be raised, unless C2X or a later C standard is selected.  This
!      option does nothing unless '-ftrapping-math' is in effect.
  
!      Even if '-fno-fp-int-builtin-inexact' is used, if the functions
       generate a call to a library function then the "inexact" exception
       may be raised if the library implementation does not follow TS
       18661.
  
! '-fsingle-precision-constant'
       Treat floating-point constants as single precision instead of
       implicitly converting them to double-precision constants.
  
! '-fcx-limited-range'
       When enabled, this option states that a range reduction step is not
       needed when performing complex division.  Also, there is no
       checking whether the result of a complex multiplication or division
!      is 'NaN + I*NaN', with an attempt to rescue the situation in that
!      case.  The default is '-fno-cx-limited-range', but is enabled by
!      '-ffast-math'.
  
       This option controls the default setting of the ISO C99
!      'CX_LIMITED_RANGE' pragma.  Nevertheless, the option applies to all
       languages.
  
! '-fcx-fortran-rules'
       Complex multiplication and division follow Fortran rules.  Range
       reduction is done as part of complex division, but there is no
       checking whether the result of a complex multiplication or division
!      is 'NaN + I*NaN', with an attempt to rescue the situation in that
       case.
  
!      The default is '-fno-cx-fortran-rules'.
  
   The following options control optimizations that may improve
! performance, but are not enabled by any '-O' options.  This section
  includes experimental options that may produce broken code.
  
! '-fbranch-probabilities'
!      After running a program compiled with '-fprofile-arcs' (*note
       Instrumentation Options::), you can compile it a second time using
!      '-fbranch-probabilities', to improve optimizations based on the
       number of times each branch was taken.  When a program compiled
!      with '-fprofile-arcs' exits, it saves arc execution counts to a
!      file called 'SOURCENAME.gcda' for each source file.  The
       information in this data file is very dependent on the structure of
       the generated code, so you must use the same source code and the
       same optimization options for both compilations.  See details about
!      the file naming in '-fprofile-arcs'.
  
!      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.cc', 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.
  
!      Enabled by '-fprofile-use' and '-fauto-profile'.
  
! '-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 by '-fprofile-generate', '-fprofile-use', and
!      '-fauto-profile'.
  
! '-fprofile-reorder-functions'
       Function reordering based on profile instrumentation collects first
       time of execution of a function and orders these functions in
       ascending order.
  
!      Enabled with '-fprofile-use'.
  
! '-fvpt'
!      If combined with '-fprofile-arcs', this option instructs the
       compiler to add code to gather information about values of
       expressions.
  
!      With '-fbranch-probabilities', it reads back the data gathered and
       actually performs the optimizations based on them.  Currently the
       optimizations include specialization of division operations using
       the knowledge about the value of the denominator.
  
!      Enabled with '-fprofile-use' and '-fauto-profile'.
  
! '-frename-registers'
       Attempt to avoid false dependencies in scheduled code by making use
       of registers left over after register allocation.  This
       optimization most benefits processors with lots of registers.
--- 13017,13144 ----
       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 along with ‘-ftrapping-math’ 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.
  
! ‘-fno-fp-int-builtin-inexact’
!      Do not allow the built-in functions ‘ceil’, ‘floor’, ‘round’ and
!      ‘trunc’, and their ‘float’ and ‘long double’ variants, to generate
       code that raises the "inexact" floating-point exception for
       noninteger arguments.  ISO C99 and C11 allow these functions to
       raise the "inexact" exception, but ISO/IEC TS 18661-1:2014, the C
       bindings to IEEE 754-2008, as integrated into ISO C2X, does not
       allow these functions to do so.
  
!      The default is ‘-ffp-int-builtin-inexact’, allowing the exception
       to be raised, unless C2X or a later C standard is selected.  This
!      option does nothing unless ‘-ftrapping-math’ is in effect.
  
!      Even if ‘-fno-fp-int-builtin-inexact’ is used, if the functions
       generate a call to a library function then the "inexact" exception
       may be raised if the library implementation does not follow TS
       18661.
  
! ‘-fsingle-precision-constant’
       Treat floating-point constants as single precision instead of
       implicitly converting them to double-precision constants.
  
! ‘-fcx-limited-range’
       When enabled, this option states that a range reduction step is not
       needed when performing complex division.  Also, there is no
       checking whether the result of a complex multiplication or division
!      is ‘NaN + I*NaN’, with an attempt to rescue the situation in that
!      case.  The default is ‘-fno-cx-limited-range’, but is enabled by
!      ‘-ffast-math’.
  
       This option controls the default setting of the ISO C99
!      ‘CX_LIMITED_RANGE’ pragma.  Nevertheless, the option applies to all
       languages.
  
! ‘-fcx-fortran-rules’
       Complex multiplication and division follow Fortran rules.  Range
       reduction is done as part of complex division, but there is no
       checking whether the result of a complex multiplication or division
!      is ‘NaN + I*NaN’, with an attempt to rescue the situation in that
       case.
  
!      The default is ‘-fno-cx-fortran-rules’.
  
   The following options control optimizations that may improve
! performance, but are not enabled by any ‘-O’ options.  This section
  includes experimental options that may produce broken code.
  
! ‘-fbranch-probabilities’
!      After running a program compiled with ‘-fprofile-arcs’ (*note
       Instrumentation Options::), you can compile it a second time using
!      ‘-fbranch-probabilities’, to improve optimizations based on the
       number of times each branch was taken.  When a program compiled
!      with ‘-fprofile-arcs’ exits, it saves arc execution counts to a
!      file called ‘SOURCENAME.gcda’ for each source file.  The
       information in this data file is very dependent on the structure of
       the generated code, so you must use the same source code and the
       same optimization options for both compilations.  See details about
!      the file naming in ‘-fprofile-arcs’.
  
!      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.cc’, 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.
  
!      Enabled by ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-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 by ‘-fprofile-generate’, ‘-fprofile-use’, and
!      ‘-fauto-profile’.
  
! ‘-fprofile-reorder-functions’
       Function reordering based on profile instrumentation collects first
       time of execution of a function and orders these functions in
       ascending order.
  
!      Enabled with ‘-fprofile-use’.
  
! ‘-fvpt’
!      If combined with ‘-fprofile-arcs’, this option instructs the
       compiler to add code to gather information about values of
       expressions.
  
!      With ‘-fbranch-probabilities’, it reads back the data gathered and
       actually performs the optimizations based on them.  Currently the
       optimizations include specialization of division operations using
       the knowledge about the value of the denominator.
  
!      Enabled with ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-frename-registers’
       Attempt to avoid false dependencies in scheduled code by making use
       of registers left over after register allocation.  This
       optimization most benefits processors with lots of registers.
*************** includes experimental options that may p
*** 13142,13214 ****
       however, it can make debugging impossible, since variables no
       longer stay in a "home register".
  
!      Enabled by default with '-funroll-loops'.
  
! '-fschedule-fusion'
       Performs a target dependent pass over the instruction stream to
       schedule instructions of same type together because target machine
       can execute them more efficiently if they are adjacent to each
       other in the instruction flow.
  
!      Enabled at levels '-O2', '-O3', '-Os'.
  
! '-ftracer'
       Perform tail duplication to enlarge superblock size.  This
       transformation simplifies the control flow of the function allowing
       other optimizations to do a better job.
  
!      Enabled by '-fprofile-use' and '-fauto-profile'.
  
! '-funroll-loops'
       Unroll loops whose number of iterations can be determined at
!      compile time or upon entry to the loop.  '-funroll-loops' implies
!      '-frerun-cse-after-loop', '-fweb' and '-frename-registers'.  It
       also turns on complete loop peeling (i.e. complete removal of loops
       with a small constant number of iterations).  This option makes
       code larger, and may or may not make it run faster.
  
!      Enabled by '-fprofile-use' and '-fauto-profile'.
  
! '-funroll-all-loops'
       Unroll all loops, even if their number of iterations is uncertain
       when the loop is entered.  This usually makes programs run more
!      slowly.  '-funroll-all-loops' implies the same options as
!      '-funroll-loops'.
  
! '-fpeel-loops'
       Peels loops for which there is enough information that they do not
       roll much (from profile feedback or static analysis).  It also
       turns on complete loop peeling (i.e. complete removal of loops with
       small constant number of iterations).
  
!      Enabled by '-O3', '-fprofile-use', and '-fauto-profile'.
  
! '-fmove-loop-invariants'
       Enables the loop invariant motion pass in the RTL loop optimizer.
!      Enabled at level '-O1' and higher, except for '-Og'.
  
! '-fmove-loop-stores'
       Enables the loop store motion pass in the GIMPLE loop optimizer.
       This moves invariant stores to after the end of the loop in
       exchange for carrying the stored value in a register across the
!      iteration.  Note for this option to have an effect '-ftree-loop-im'
!      has to be enabled as well.  Enabled at level '-O1' and higher,
!      except for '-Og'.
  
! '-fsplit-loops'
       Split a loop into two if it contains a condition that's always true
       for one side of the iteration space and false for the other.
  
!      Enabled by '-fprofile-use' and '-fauto-profile'.
  
! '-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).
  
!      Enabled by '-fprofile-use' and '-fauto-profile'.
  
! '-fversion-loops-for-strides'
       If a loop iterates over an array with a variable stride, create
       another version of the loop that assumes the stride is always one.
       For example:
--- 13146,13218 ----
       however, it can make debugging impossible, since variables no
       longer stay in a "home register".
  
!      Enabled by default with ‘-funroll-loops’.
  
! ‘-fschedule-fusion’
       Performs a target dependent pass over the instruction stream to
       schedule instructions of same type together because target machine
       can execute them more efficiently if they are adjacent to each
       other in the instruction flow.
  
!      Enabled at levels ‘-O2’, ‘-O3’, ‘-Os’.
  
! ‘-ftracer’
       Perform tail duplication to enlarge superblock size.  This
       transformation simplifies the control flow of the function allowing
       other optimizations to do a better job.
  
!      Enabled by ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-funroll-loops’
       Unroll loops whose number of iterations can be determined at
!      compile time or upon entry to the loop.  ‘-funroll-loops’ implies
!      ‘-frerun-cse-after-loop’, ‘-fweb’ and ‘-frename-registers’.  It
       also turns on complete loop peeling (i.e. complete removal of loops
       with a small constant number of iterations).  This option makes
       code larger, and may or may not make it run faster.
  
!      Enabled by ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-funroll-all-loops’
       Unroll all loops, even if their number of iterations is uncertain
       when the loop is entered.  This usually makes programs run more
!      slowly.  ‘-funroll-all-loops’ implies the same options as
!      ‘-funroll-loops’.
  
! ‘-fpeel-loops’
       Peels loops for which there is enough information that they do not
       roll much (from profile feedback or static analysis).  It also
       turns on complete loop peeling (i.e. complete removal of loops with
       small constant number of iterations).
  
!      Enabled by ‘-O3’, ‘-fprofile-use’, and ‘-fauto-profile’.
  
! ‘-fmove-loop-invariants’
       Enables the loop invariant motion pass in the RTL loop optimizer.
!      Enabled at level ‘-O1’ and higher, except for ‘-Og’.
  
! ‘-fmove-loop-stores’
       Enables the loop store motion pass in the GIMPLE loop optimizer.
       This moves invariant stores to after the end of the loop in
       exchange for carrying the stored value in a register across the
!      iteration.  Note for this option to have an effect ‘-ftree-loop-im’
!      has to be enabled as well.  Enabled at level ‘-O1’ and higher,
!      except for ‘-Og’.
  
! ‘-fsplit-loops’
       Split a loop into two if it contains a condition that's always true
       for one side of the iteration space and false for the other.
  
!      Enabled by ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-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).
  
!      Enabled by ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-fversion-loops-for-strides’
       If a loop iterates over an array with a variable stride, create
       another version of the loop that assumes the stride is always one.
       For example:
*************** includes experimental options that may p
*** 13227,13237 ****
  
       This is particularly useful for assumed-shape arrays in Fortran
       where (for example) it allows better vectorization assuming
!      contiguous accesses.  This flag is enabled by default at '-O3'.  It
!      is also enabled by '-fprofile-use' and '-fauto-profile'.
  
! '-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
--- 13231,13241 ----
  
       This is particularly useful for assumed-shape arrays in Fortran
       where (for example) it allows better vectorization assuming
!      contiguous accesses.  This flag is enabled by default at ‘-O3’.  It
!      is also enabled by ‘-fprofile-use’ and ‘-fauto-profile’.
  
! ‘-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
*************** includes experimental options that may p
*** 13243,13249 ****
       such optimizations.  On AIX, the linker rearranges sections
       (CSECTs) based on the call graph.  The performance impact varies.
  
!      Together with a linker garbage collection (linker '--gc-sections'
       option) these options may lead to smaller statically-linked
       executables (after stripping).
  
--- 13247,13253 ----
       such optimizations.  On AIX, the linker rearranges sections
       (CSECTs) based on the call graph.  The performance impact varies.
  
!      Together with a linker garbage collection (linker ‘--gc-sections’
       option) these options may lead to smaller statically-linked
       executables (after stripping).
  
*************** includes experimental options that may p
*** 13260,13282 ****
       An example of such an optimization is relaxing calls to short call
       instructions.
  
! '-fstdarg-opt'
       Optimize the prologue of variadic argument functions with respect
       to usage of those arguments.
  
! '-fsection-anchors'
       Try to reduce the number of symbolic address calculations by using
       shared "anchor" symbols to address nearby objects.  This
       transformation can help to reduce the number of GOT entries and GOT
       accesses on some targets.
  
!      For example, the implementation of the following function 'foo':
  
            static int a, b, c;
            int foo (void) { return a + b + c; }
  
       usually calculates the addresses of all three variables, but if you
!      compile it with '-fsection-anchors', it accesses the variables from
       a common anchor point instead.  The effect is similar to the
       following pseudocode (which isn't valid C):
  
--- 13264,13286 ----
       An example of such an optimization is relaxing calls to short call
       instructions.
  
! ‘-fstdarg-opt’
       Optimize the prologue of variadic argument functions with respect
       to usage of those arguments.
  
! ‘-fsection-anchors’
       Try to reduce the number of symbolic address calculations by using
       shared "anchor" symbols to address nearby objects.  This
       transformation can help to reduce the number of GOT entries and GOT
       accesses on some targets.
  
!      For example, the implementation of the following function ‘foo’:
  
            static int a, b, c;
            int foo (void) { return a + b + c; }
  
       usually calculates the addresses of all three variables, but if you
!      compile it with ‘-fsection-anchors’, it accesses the variables from
       a common anchor point instead.  The effect is similar to the
       following pseudocode (which isn't valid C):
  
*************** includes experimental options that may p
*** 13288,13329 ****
  
       Not all targets support this option.
  
! '-fzero-call-used-regs=CHOICE'
       Zero call-used registers at function return to increase program
       security by either mitigating Return-Oriented Programming (ROP)
       attacks or preventing information leakage through registers.
  
       The possible values of CHOICE are the same as for the
!      'zero_call_used_regs' attribute (*note Function Attributes::).  The
!      default is 'skip'.
  
       You can control this behavior for a specific function by using the
!      function attribute 'zero_call_used_regs' (*note Function
       Attributes::).
  
! '--param NAME=VALUE'
       In some places, GCC uses various constants to control the amount of
       optimization that is done.  For example, GCC does not inline
       functions that contain more than a certain number of instructions.
       You can control some of these constants on the command line using
!      the '--param' option.
  
       The names of specific parameters, and the meaning of the values,
       are tied to the internals of the compiler, and are subject to
       change without notice in future releases.
  
       In order to get the minimal, maximal and default values of a
!      parameter, use the '--help=param -Q' options.
  
       In each case, the VALUE is an integer.  The following choices of
       NAME are recognized for all targets:
  
!      'predictable-branch-outcome'
            When branch is predicted to be taken with probability lower
            than this threshold (in percent), then it is considered well
            predictable.
  
!      'max-rtl-if-conversion-insns'
            RTL if-conversion tries to remove conditional branches around
            a block and replace them with conditionally executed
            instructions.  This parameter gives the maximum number of
--- 13292,13333 ----
  
       Not all targets support this option.
  
! ‘-fzero-call-used-regs=CHOICE’
       Zero call-used registers at function return to increase program
       security by either mitigating Return-Oriented Programming (ROP)
       attacks or preventing information leakage through registers.
  
       The possible values of CHOICE are the same as for the
!      ‘zero_call_used_regs’ attribute (*note Function Attributes::).  The
!      default is ‘skip’.
  
       You can control this behavior for a specific function by using the
!      function attribute ‘zero_call_used_regs’ (*note Function
       Attributes::).
  
! ‘--param NAME=VALUE’
       In some places, GCC uses various constants to control the amount of
       optimization that is done.  For example, GCC does not inline
       functions that contain more than a certain number of instructions.
       You can control some of these constants on the command line using
!      the ‘--param’ option.
  
       The names of specific parameters, and the meaning of the values,
       are tied to the internals of the compiler, and are subject to
       change without notice in future releases.
  
       In order to get the minimal, maximal and default values of a
!      parameter, use the ‘--help=param -Q’ options.
  
       In each case, the VALUE is an integer.  The following choices of
       NAME are recognized for all targets:
  
!      ‘predictable-branch-outcome’
            When branch is predicted to be taken with probability lower
            than this threshold (in percent), then it is considered well
            predictable.
  
!      ‘max-rtl-if-conversion-insns’
            RTL if-conversion tries to remove conditional branches around
            a block and replace them with conditionally executed
            instructions.  This parameter gives the maximum number of
*************** includes experimental options that may p
*** 13331,13337 ****
            if-conversion.  The compiler will also use other heuristics to
            decide whether if-conversion is likely to be profitable.
  
!      'max-rtl-if-conversion-predictable-cost'
            RTL if-conversion will try to remove conditional branches
            around a block and replace them with conditionally executed
            instructions.  These parameters give the maximum permissible
--- 13335,13341 ----
            if-conversion.  The compiler will also use other heuristics to
            decide whether if-conversion is likely to be profitable.
  
!      ‘max-rtl-if-conversion-predictable-cost’
            RTL if-conversion will try to remove conditional branches
            around a block and replace them with conditionally executed
            instructions.  These parameters give the maximum permissible
*************** includes experimental options that may p
*** 13342,13367 ****
            will try to provide a reasonable default for this parameter
            using the BRANCH_COST target macro.
  
!      'max-crossjump-edges'
            The maximum number of incoming edges to consider for
!           cross-jumping.  The algorithm used by '-fcrossjumping' is
            O(N^2) in the number of edges incoming to each block.
            Increasing values mean more aggressive optimization, making
            the compilation time increase with probably small improvement
            in executable size.
  
!      'min-crossjump-insns'
            The minimum number of instructions that must be matched at the
            end of two blocks before cross-jumping is performed on them.
            This value is ignored in the case where all instructions in
            the block being cross-jumped from are matched.
  
!      '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.
  
!      '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
--- 13346,13371 ----
            will try to provide a reasonable default for this parameter
            using the BRANCH_COST target macro.
  
!      ‘max-crossjump-edges’
            The maximum number of incoming edges to consider for
!           cross-jumping.  The algorithm used by ‘-fcrossjumping’ is
            O(N^2) in the number of edges incoming to each block.
            Increasing values mean more aggressive optimization, making
            the compilation time increase with probably small improvement
            in executable size.
  
!      ‘min-crossjump-insns’
            The minimum number of instructions that must be matched at the
            end of two blocks before cross-jumping is performed on them.
            This value is ignored in the case where all instructions in
            the block being cross-jumped from are matched.
  
!      ‘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.
  
!      ‘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
*************** includes experimental options that may p
*** 13369,13375 ****
            Only computed jumps at the end of a basic blocks with no more
            than max-goto-duplication-insns are unfactored.
  
!      'max-delay-slot-insn-search'
            The maximum number of instructions to consider when looking
            for an instruction to fill a delay slot.  If more than this
            arbitrary number of instructions are searched, the time
--- 13373,13379 ----
            Only computed jumps at the end of a basic blocks with no more
            than max-goto-duplication-insns are unfactored.
  
!      ‘max-delay-slot-insn-search’
            The maximum number of instructions to consider when looking
            for an instruction to fill a delay slot.  If more than this
            arbitrary number of instructions are searched, the time
*************** includes experimental options that may p
*** 13378,13384 ****
            optimization, making the compilation time increase with
            probably small improvement in execution time.
  
!      'max-delay-slot-live-search'
            When trying to fill delay slots, the maximum number of
            instructions to consider when searching for a block with valid
            live register information.  Increasing this arbitrarily chosen
--- 13382,13388 ----
            optimization, making the compilation time increase with
            probably small improvement in execution time.
  
!      ‘max-delay-slot-live-search’
            When trying to fill delay slots, the maximum number of
            instructions to consider when searching for a block with valid
            live register information.  Increasing this arbitrarily chosen
*************** includes experimental options that may p
*** 13387,13424 ****
            delay slot code is rewritten to maintain the control-flow
            graph.
  
!      'max-gcse-memory'
!           The approximate maximum amount of memory in 'kB' that can be
            allocated in order to perform the global common subexpression
            elimination optimization.  If more memory than specified is
            required, the optimization is not done.
  
!      'max-gcse-insertion-ratio'
            If the ratio of expression insertions to deletions is larger
            than this value for any expression, then RTL PRE inserts or
            removes the expression and thus leaves partially redundant
            computations in the instruction stream.
  
!      'max-pending-list-length'
            The maximum number of pending dependencies scheduling allows
            before flushing the current state and starting over.  Large
            functions with few branches or calls can create excessively
            large lists which needlessly consume memory and resources.
  
!      'max-modulo-backtrack-attempts'
            The maximum number of backtrack attempts the scheduler should
            make when modulo scheduling a loop.  Larger values can
            exponentially increase compilation time.
  
!      'max-inline-functions-called-once-loop-depth'
            Maximal loop depth of a call considered by inline heuristics
            that tries to inline all functions called once.
  
!      'max-inline-functions-called-once-insns'
            Maximal estimated size of functions produced while inlining
            functions called once.
  
!      '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
--- 13391,13428 ----
            delay slot code is rewritten to maintain the control-flow
            graph.
  
!      ‘max-gcse-memory’
!           The approximate maximum amount of memory in ‘kB’ that can be
            allocated in order to perform the global common subexpression
            elimination optimization.  If more memory than specified is
            required, the optimization is not done.
  
!      ‘max-gcse-insertion-ratio’
            If the ratio of expression insertions to deletions is larger
            than this value for any expression, then RTL PRE inserts or
            removes the expression and thus leaves partially redundant
            computations in the instruction stream.
  
!      ‘max-pending-list-length’
            The maximum number of pending dependencies scheduling allows
            before flushing the current state and starting over.  Large
            functions with few branches or calls can create excessively
            large lists which needlessly consume memory and resources.
  
!      ‘max-modulo-backtrack-attempts’
            The maximum number of backtrack attempts the scheduler should
            make when modulo scheduling a loop.  Larger values can
            exponentially increase compilation time.
  
!      ‘max-inline-functions-called-once-loop-depth’
            Maximal loop depth of a call considered by inline heuristics
            that tries to inline all functions called once.
  
!      ‘max-inline-functions-called-once-insns’
            Maximal estimated size of functions produced while inlining
            functions called once.
  
!      ‘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
*************** includes experimental options that may p
*** 13426,13489 ****
            functions declared inline and methods implemented in a class
            declaration (C++).
  
!      'max-inline-insns-auto'
!           When you use '-finline-functions' (included in '-O3'), a lot
            of functions that would otherwise not be considered for
            inlining by the compiler are investigated.  To those
            functions, a different (more restrictive) limit compared to
!           functions declared inline can be applied ('--param
!           max-inline-insns-auto').
  
!      'max-inline-insns-small'
            This is bound applied to calls which are considered relevant
!           with '-finline-small-functions'.
  
!      'max-inline-insns-size'
            This is bound applied to calls which are optimized for size.
            Small growth may be desirable to anticipate optimization
            oppurtunities exposed by inlining.
  
!      'uninlined-function-insns'
            Number of instructions accounted by inliner for function
            overhead such as function prologue and epilogue.
  
!      'uninlined-function-time'
            Extra time accounted by inliner for function overhead such as
            time needed to execute function prologue and epilogue.
  
!      'inline-heuristics-hint-percent'
!           The scale (in percents) applied to 'inline-insns-single',
!           'inline-insns-single-O2', 'inline-insns-auto' when inline
            heuristics hints that inlining is very profitable (will enable
            later optimizations).
  
!      'uninlined-thunk-insns'
!      'uninlined-thunk-time'
!           Same as '--param uninlined-function-insns' and '--param
!           uninlined-function-time' but applied to function thunks.
  
!      'inline-min-speedup'
            When estimated performance improvement of caller + callee
            runtime exceeds this threshold (in percent), the function can
!           be inlined regardless of the limit on '--param
!           max-inline-insns-single' and '--param max-inline-insns-auto'.
  
!      'large-function-insns'
            The limit specifying really large functions.  For functions
            larger than this limit after inlining, inlining is constrained
!           by '--param large-function-growth'.  This parameter is useful
            primarily to avoid extreme compilation time caused by
            non-linear algorithms used by the back end.
  
!      'large-function-growth'
            Specifies maximal growth of large function caused by inlining
            in percents.  For example, parameter value 100 limits large
            function growth to 2.0 times the original size.
  
!      'large-unit-insns'
            The limit specifying large translation unit.  Growth caused by
            inlining of units larger than this limit is limited by
!           '--param inline-unit-growth'.  For small units this might be
            too tight.  For example, consider a unit consisting of
            function A that is inline and B that just calls A three times.
            If B is small relative to A, the growth of unit is 300\% and
--- 13430,13493 ----
            functions declared inline and methods implemented in a class
            declaration (C++).
  
!      ‘max-inline-insns-auto’
!           When you use ‘-finline-functions’ (included in ‘-O3’), a lot
            of functions that would otherwise not be considered for
            inlining by the compiler are investigated.  To those
            functions, a different (more restrictive) limit compared to
!           functions declared inline can be applied (‘--param
!           max-inline-insns-auto’).
  
!      ‘max-inline-insns-small’
            This is bound applied to calls which are considered relevant
!           with ‘-finline-small-functions’.
  
!      ‘max-inline-insns-size’
            This is bound applied to calls which are optimized for size.
            Small growth may be desirable to anticipate optimization
            oppurtunities exposed by inlining.
  
!      ‘uninlined-function-insns’
            Number of instructions accounted by inliner for function
            overhead such as function prologue and epilogue.
  
!      ‘uninlined-function-time’
            Extra time accounted by inliner for function overhead such as
            time needed to execute function prologue and epilogue.
  
!      ‘inline-heuristics-hint-percent’
!           The scale (in percents) applied to ‘inline-insns-single’,
!           ‘inline-insns-single-O2’, ‘inline-insns-auto’ when inline
            heuristics hints that inlining is very profitable (will enable
            later optimizations).
  
!      ‘uninlined-thunk-insns’
!      ‘uninlined-thunk-time’
!           Same as ‘--param uninlined-function-insns’ and ‘--param
!           uninlined-function-time’ but applied to function thunks.
  
!      ‘inline-min-speedup’
            When estimated performance improvement of caller + callee
            runtime exceeds this threshold (in percent), the function can
!           be inlined regardless of the limit on ‘--param
!           max-inline-insns-single’ and ‘--param max-inline-insns-auto’.
  
!      ‘large-function-insns’
            The limit specifying really large functions.  For functions
            larger than this limit after inlining, inlining is constrained
!           by ‘--param large-function-growth’.  This parameter is useful
            primarily to avoid extreme compilation time caused by
            non-linear algorithms used by the back end.
  
!      ‘large-function-growth’
            Specifies maximal growth of large function caused by inlining
            in percents.  For example, parameter value 100 limits large
            function growth to 2.0 times the original size.
  
!      ‘large-unit-insns’
            The limit specifying large translation unit.  Growth caused by
            inlining of units larger than this limit is limited by
!           ‘--param inline-unit-growth’.  For small units this might be
            too tight.  For example, consider a unit consisting of
            function A that is inline and B that just calls A three times.
            If B is small relative to A, the growth of unit is 300\% and
*************** includes experimental options that may p
*** 13491,13625 ****
            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'.
  
!      'lazy-modules'
            Maximum number of concurrently open C++ module files when lazy
            loading.
  
!      'inline-unit-growth'
            Specifies maximal overall growth of the compilation unit
            caused by inlining.  For example, parameter value 20 limits
            unit growth to 1.2 times the original size.  Cold functions
            (either marked cold via an attribute or by profile feedback)
            are not accounted into the unit size.
  
!      'ipa-cp-unit-growth'
            Specifies maximal overall growth of the compilation unit
            caused by interprocedural constant propagation.  For example,
            parameter value 10 limits unit growth to 1.1 times the
            original size.
  
!      'ipa-cp-large-unit-insns'
            The size of translation unit that IPA-CP pass considers large.
  
!      'large-stack-frame'
            The limit specifying large stack frames.  While inlining the
            algorithm is trying to not grow past this limit too much.
  
!      'large-stack-frame-growth'
            Specifies maximal growth of large stack frames caused by
            inlining in percents.  For example, parameter value 1000
            limits large stack frame growth to 11 times the original size.
  
!      'max-inline-insns-recursive'
!      'max-inline-insns-recursive-auto'
            Specifies the maximum number of instructions an out-of-line
            copy of a self-recursive inline function can grow into by
            performing recursive inlining.
  
!           '--param max-inline-insns-recursive' applies to functions
            declared inline.  For functions not declared inline, recursive
!           inlining happens only when '-finline-functions' (included in
!           '-O3') is enabled; '--param max-inline-insns-recursive-auto'
            applies instead.
  
!      'max-inline-recursive-depth'
!      'max-inline-recursive-depth-auto'
            Specifies the maximum recursion depth used for recursive
            inlining.
  
!           '--param max-inline-recursive-depth' applies to functions
            declared inline.  For functions not declared inline, recursive
!           inlining happens only when '-finline-functions' (included in
!           '-O3') is enabled; '--param max-inline-recursive-depth-auto'
            applies instead.
  
!      '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 the probability
            that function recurses via a given call expression.  This
            parameter limits inlining only to call expressions whose
            probability exceeds the given threshold (in percents).
  
!      'early-inlining-insns'
            Specify growth that the early inliner can make.  In effect it
            increases the amount of inlining for code having a large
            abstraction penalty.
  
!      'max-early-inliner-iterations'
            Limit of iterations of the early inliner.  This basically
            bounds the number of nested indirect calls the early inliner
            can resolve.  Deeper chains are still handled by late
            inlining.
  
!      'comdat-sharing-probability'
            Probability (in percent) that C++ inline function with comdat
            visibility are shared across multiple compilation units.
  
!      'modref-max-bases'
!      'modref-max-refs'
!      'modref-max-accesses'
            Specifies the maximal number of base pointers, references and
            accesses stored for a single function by mod/ref analysis.
  
!      'modref-max-tests'
            Specifies the maxmal number of tests alias oracle can perform
            to disambiguate memory locations using the mod/ref
!           information.  This parameter ought to be bigger than '--param
!           modref-max-bases' and '--param modref-max-refs'.
  
!      'modref-max-depth'
            Specifies the maximum depth of DFS walk used by modref escape
            analysis.  Setting to 0 disables the analysis completely.
  
!      'modref-max-escape-points'
            Specifies the maximum number of escape points tracked by
            modref per SSA-name.
  
!      'modref-max-adjustments'
            Specifies the maximum number the access range is enlarged
            during modref dataflow analysis.
  
!      'profile-func-internal-id'
            A parameter to control whether to use function internal id in
            profile database lookup.  If the value is 0, the compiler uses
            an id that is based on function assembler name and filename,
            which makes old profile data more tolerant to source changes
            such as function reordering etc.
  
!      'min-vect-loop-bound'
            The minimum number of iterations under which loops are not
!           vectorized when '-ftree-vectorize' is used.  The number of
            iterations after vectorization needs to be greater than the
            value specified by this option to allow vectorization.
  
!      'gcse-cost-distance-ratio'
            Scaling factor in calculation of maximum distance an
            expression can be moved by GCSE optimizations.  This is
            currently supported only in the code hoisting pass.  The
            bigger the ratio, the more aggressive code hoisting is with
            simple expressions, i.e., the expressions that have cost less
!           than 'gcse-unrestricted-cost'.  Specifying 0 disables hoisting
            of simple expressions.
  
!      'gcse-unrestricted-cost'
            Cost, roughly measured as the cost of a single typical machine
            instruction, at which GCSE optimizations do not constrain the
            distance an expression can travel.  This is currently
--- 13495,13629 ----
            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’.
  
!      ‘lazy-modules’
            Maximum number of concurrently open C++ module files when lazy
            loading.
  
!      ‘inline-unit-growth’
            Specifies maximal overall growth of the compilation unit
            caused by inlining.  For example, parameter value 20 limits
            unit growth to 1.2 times the original size.  Cold functions
            (either marked cold via an attribute or by profile feedback)
            are not accounted into the unit size.
  
!      ‘ipa-cp-unit-growth’
            Specifies maximal overall growth of the compilation unit
            caused by interprocedural constant propagation.  For example,
            parameter value 10 limits unit growth to 1.1 times the
            original size.
  
!      ‘ipa-cp-large-unit-insns’
            The size of translation unit that IPA-CP pass considers large.
  
!      ‘large-stack-frame’
            The limit specifying large stack frames.  While inlining the
            algorithm is trying to not grow past this limit too much.
  
!      ‘large-stack-frame-growth’
            Specifies maximal growth of large stack frames caused by
            inlining in percents.  For example, parameter value 1000
            limits large stack frame growth to 11 times the original size.
  
!      ‘max-inline-insns-recursive’
!      ‘max-inline-insns-recursive-auto’
            Specifies the maximum number of instructions an out-of-line
            copy of a self-recursive inline function can grow into by
            performing recursive inlining.
  
!           ‘--param max-inline-insns-recursive’ applies to functions
            declared inline.  For functions not declared inline, recursive
!           inlining happens only when ‘-finline-functions’ (included in
!           ‘-O3’) is enabled; ‘--param max-inline-insns-recursive-auto’
            applies instead.
  
!      ‘max-inline-recursive-depth’
!      ‘max-inline-recursive-depth-auto’
            Specifies the maximum recursion depth used for recursive
            inlining.
  
!           ‘--param max-inline-recursive-depth’ applies to functions
            declared inline.  For functions not declared inline, recursive
!           inlining happens only when ‘-finline-functions’ (included in
!           ‘-O3’) is enabled; ‘--param max-inline-recursive-depth-auto’
            applies instead.
  
!      ‘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 the probability
            that function recurses via a given call expression.  This
            parameter limits inlining only to call expressions whose
            probability exceeds the given threshold (in percents).
  
!      ‘early-inlining-insns’
            Specify growth that the early inliner can make.  In effect it
            increases the amount of inlining for code having a large
            abstraction penalty.
  
!      ‘max-early-inliner-iterations’
            Limit of iterations of the early inliner.  This basically
            bounds the number of nested indirect calls the early inliner
            can resolve.  Deeper chains are still handled by late
            inlining.
  
!      ‘comdat-sharing-probability’
            Probability (in percent) that C++ inline function with comdat
            visibility are shared across multiple compilation units.
  
!      ‘modref-max-bases’
!      ‘modref-max-refs’
!      ‘modref-max-accesses’
            Specifies the maximal number of base pointers, references and
            accesses stored for a single function by mod/ref analysis.
  
!      ‘modref-max-tests’
            Specifies the maxmal number of tests alias oracle can perform
            to disambiguate memory locations using the mod/ref
!           information.  This parameter ought to be bigger than ‘--param
!           modref-max-bases’ and ‘--param modref-max-refs’.
  
!      ‘modref-max-depth’
            Specifies the maximum depth of DFS walk used by modref escape
            analysis.  Setting to 0 disables the analysis completely.
  
!      ‘modref-max-escape-points’
            Specifies the maximum number of escape points tracked by
            modref per SSA-name.
  
!      ‘modref-max-adjustments’
            Specifies the maximum number the access range is enlarged
            during modref dataflow analysis.
  
!      ‘profile-func-internal-id’
            A parameter to control whether to use function internal id in
            profile database lookup.  If the value is 0, the compiler uses
            an id that is based on function assembler name and filename,
            which makes old profile data more tolerant to source changes
            such as function reordering etc.
  
!      ‘min-vect-loop-bound’
            The minimum number of iterations under which loops are not
!           vectorized when ‘-ftree-vectorize’ is used.  The number of
            iterations after vectorization needs to be greater than the
            value specified by this option to allow vectorization.
  
!      ‘gcse-cost-distance-ratio’
            Scaling factor in calculation of maximum distance an
            expression can be moved by GCSE optimizations.  This is
            currently supported only in the code hoisting pass.  The
            bigger the ratio, the more aggressive code hoisting is with
            simple expressions, i.e., the expressions that have cost less
!           than ‘gcse-unrestricted-cost’.  Specifying 0 disables hoisting
            of simple expressions.
  
!      ‘gcse-unrestricted-cost’
            Cost, roughly measured as the cost of a single typical machine
            instruction, at which GCSE optimizations do not constrain the
            distance an expression can travel.  This is currently
*************** includes experimental options that may p
*** 13627,13782 ****
            cost, the more aggressive code hoisting is.  Specifying 0
            allows all expressions to travel unrestricted distances.
  
!      'max-hoist-depth'
            The depth of search in the dominator tree for expressions to
            hoist.  This is used to avoid quadratic behavior in hoisting
            algorithm.  The value of 0 does not limit on the search, but
            may slow down compilation of huge functions.
  
!      'max-tail-merge-comparisons'
            The maximum amount of similar bbs to compare a bb with.  This
            is used to avoid quadratic behavior in tree tail merging.
  
!      'max-tail-merge-iterations'
            The maximum amount of iterations of the pass over the
            function.  This is used to limit compilation time in tree tail
            merging.
  
!      'store-merging-allow-unaligned'
            Allow the store merging pass to introduce unaligned stores if
            it is legal to do so.
  
!      'max-stores-to-merge'
            The maximum number of stores to attempt to merge into wider
            stores in the store merging pass.
  
!      'max-store-chains-to-track'
            The maximum number of store chains to track at the same time
            in the attempt to merge them into wider stores in the store
            merging pass.
  
!      'max-stores-to-track'
            The maximum number of stores to track at the same time in the
            attemt to to merge them into wider stores in the store merging
            pass.
  
!      'max-unrolled-insns'
            The maximum number of instructions that a loop may have to be
            unrolled.  If a loop is unrolled, this parameter also
            determines how many times the loop code is unrolled.
  
!      'max-average-unrolled-insns'
            The maximum number of instructions biased by probabilities of
            their execution that a loop may have to be unrolled.  If a
            loop is unrolled, this parameter also determines how many
            times the loop code is unrolled.
  
!      'max-unroll-times'
            The maximum number of unrollings of a single loop.
  
!      'max-peeled-insns'
            The maximum number of instructions that a loop may have to be
            peeled.  If a loop is peeled, this parameter also determines
            how many times the loop code is peeled.
  
!      'max-peel-times'
            The maximum number of peelings of a single loop.
  
!      'max-peel-branches'
            The maximum number of branches on the hot path through the
            peeled sequence.
  
!      'max-completely-peeled-insns'
            The maximum number of insns of a completely peeled loop.
  
!      'max-completely-peel-times'
            The maximum number of iterations of a loop to be suitable for
            complete peeling.
  
!      'max-completely-peel-loop-nest-depth'
            The maximum depth of a loop nest suitable for complete
            peeling.
  
!      'max-unswitch-insns'
            The maximum number of insns of an unswitched loop.
  
!      'max-unswitch-depth'
            The maximum depth of a loop nest to be unswitched.
  
!      'lim-expensive'
            The minimum cost of an expensive expression in the loop
            invariant motion.
  
!      'min-loop-cond-split-prob'
            When FDO profile information is available,
!           'min-loop-cond-split-prob' specifies minimum threshold for
            probability of semi-invariant condition statement to trigger
            loop split.
  
!      'iv-consider-all-candidates-bound'
            Bound on number of candidates for induction variables, below
            which all candidates are considered for each use in induction
            variable optimizations.  If there are more candidates than
            this, only the most relevant ones are considered to avoid
            quadratic time complexity.
  
!      'iv-max-considered-uses'
            The induction variable optimizations give up on loops that
            contain more induction variable uses.
  
!      'iv-always-prune-cand-set-bound'
            If the number of candidates in the set is smaller than this
            value, always try to remove unnecessary ivs from the set when
            adding a new one.
  
!      'avg-loop-niter'
            Average number of iterations of a loop.
  
!      'dse-max-object-size'
            Maximum size (in bytes) of objects tracked bytewise by dead
            store elimination.  Larger values may result in larger
            compilation times.
  
!      'dse-max-alias-queries-per-store'
            Maximum number of queries into the alias oracle per store.
            Larger values result in larger compilation times and may
            result in more removed dead stores.
  
!      '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.
  
!      'max-tree-if-conversion-phi-args'
            Maximum number of arguments in a PHI supported by TREE if
            conversion unless the loop is marked with simd pragma.
  
!      'vect-max-layout-candidates'
            The maximum number of possible vector layouts (such as
            permutations) to consider when optimizing to-be-vectorized
            code.
  
!      'vect-max-version-for-alignment-checks'
            The maximum number of run-time checks that can be performed
            when doing loop versioning for alignment in the vectorizer.
  
!      'vect-max-version-for-alias-checks'
            The maximum number of run-time checks that can be performed
            when doing loop versioning for alias in the vectorizer.
  
!      'vect-max-peeling-for-alignment'
            The maximum number of loop peels to enhance access alignment
            for vectorizer.  Value -1 means no limit.
  
!      'max-iterations-to-track'
            The maximum number of iterations of a loop the brute-force
            algorithm for analysis of the number of iterations of the loop
            tries to evaluate.
  
!      'hot-bb-count-fraction'
            The denominator n of fraction 1/n of the maximal execution
            count of a basic block in the entire program that a basic
            block needs to at least have in order to be considered hot.
--- 13631,13786 ----
            cost, the more aggressive code hoisting is.  Specifying 0
            allows all expressions to travel unrestricted distances.
  
!      ‘max-hoist-depth’
            The depth of search in the dominator tree for expressions to
            hoist.  This is used to avoid quadratic behavior in hoisting
            algorithm.  The value of 0 does not limit on the search, but
            may slow down compilation of huge functions.
  
!      ‘max-tail-merge-comparisons’
            The maximum amount of similar bbs to compare a bb with.  This
            is used to avoid quadratic behavior in tree tail merging.
  
!      ‘max-tail-merge-iterations’
            The maximum amount of iterations of the pass over the
            function.  This is used to limit compilation time in tree tail
            merging.
  
!      ‘store-merging-allow-unaligned’
            Allow the store merging pass to introduce unaligned stores if
            it is legal to do so.
  
!      ‘max-stores-to-merge’
            The maximum number of stores to attempt to merge into wider
            stores in the store merging pass.
  
!      ‘max-store-chains-to-track’
            The maximum number of store chains to track at the same time
            in the attempt to merge them into wider stores in the store
            merging pass.
  
!      ‘max-stores-to-track’
            The maximum number of stores to track at the same time in the
            attemt to to merge them into wider stores in the store merging
            pass.
  
!      ‘max-unrolled-insns’
            The maximum number of instructions that a loop may have to be
            unrolled.  If a loop is unrolled, this parameter also
            determines how many times the loop code is unrolled.
  
!      ‘max-average-unrolled-insns’
            The maximum number of instructions biased by probabilities of
            their execution that a loop may have to be unrolled.  If a
            loop is unrolled, this parameter also determines how many
            times the loop code is unrolled.
  
!      ‘max-unroll-times’
            The maximum number of unrollings of a single loop.
  
!      ‘max-peeled-insns’
            The maximum number of instructions that a loop may have to be
            peeled.  If a loop is peeled, this parameter also determines
            how many times the loop code is peeled.
  
!      ‘max-peel-times’
            The maximum number of peelings of a single loop.
  
!      ‘max-peel-branches’
            The maximum number of branches on the hot path through the
            peeled sequence.
  
!      ‘max-completely-peeled-insns’
            The maximum number of insns of a completely peeled loop.
  
!      ‘max-completely-peel-times’
            The maximum number of iterations of a loop to be suitable for
            complete peeling.
  
!      ‘max-completely-peel-loop-nest-depth’
            The maximum depth of a loop nest suitable for complete
            peeling.
  
!      ‘max-unswitch-insns’
            The maximum number of insns of an unswitched loop.
  
!      ‘max-unswitch-depth’
            The maximum depth of a loop nest to be unswitched.
  
!      ‘lim-expensive’
            The minimum cost of an expensive expression in the loop
            invariant motion.
  
!      ‘min-loop-cond-split-prob’
            When FDO profile information is available,
!           ‘min-loop-cond-split-prob’ specifies minimum threshold for
            probability of semi-invariant condition statement to trigger
            loop split.
  
!      ‘iv-consider-all-candidates-bound’
            Bound on number of candidates for induction variables, below
            which all candidates are considered for each use in induction
            variable optimizations.  If there are more candidates than
            this, only the most relevant ones are considered to avoid
            quadratic time complexity.
  
!      ‘iv-max-considered-uses’
            The induction variable optimizations give up on loops that
            contain more induction variable uses.
  
!      ‘iv-always-prune-cand-set-bound’
            If the number of candidates in the set is smaller than this
            value, always try to remove unnecessary ivs from the set when
            adding a new one.
  
!      ‘avg-loop-niter’
            Average number of iterations of a loop.
  
!      ‘dse-max-object-size’
            Maximum size (in bytes) of objects tracked bytewise by dead
            store elimination.  Larger values may result in larger
            compilation times.
  
!      ‘dse-max-alias-queries-per-store’
            Maximum number of queries into the alias oracle per store.
            Larger values result in larger compilation times and may
            result in more removed dead stores.
  
!      ‘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.
  
!      ‘max-tree-if-conversion-phi-args’
            Maximum number of arguments in a PHI supported by TREE if
            conversion unless the loop is marked with simd pragma.
  
!      ‘vect-max-layout-candidates’
            The maximum number of possible vector layouts (such as
            permutations) to consider when optimizing to-be-vectorized
            code.
  
!      ‘vect-max-version-for-alignment-checks’
            The maximum number of run-time checks that can be performed
            when doing loop versioning for alignment in the vectorizer.
  
!      ‘vect-max-version-for-alias-checks’
            The maximum number of run-time checks that can be performed
            when doing loop versioning for alias in the vectorizer.
  
!      ‘vect-max-peeling-for-alignment’
            The maximum number of loop peels to enhance access alignment
            for vectorizer.  Value -1 means no limit.
  
!      ‘max-iterations-to-track’
            The maximum number of iterations of a loop the brute-force
            algorithm for analysis of the number of iterations of the loop
            tries to evaluate.
  
!      ‘hot-bb-count-fraction’
            The denominator n of fraction 1/n of the maximal execution
            count of a basic block in the entire program that a basic
            block needs to at least have in order to be considered hot.
*************** includes experimental options that may p
*** 13785,13791 ****
            of the maximal execution count.  0 means that it is never
            considered hot.  Used in non-LTO mode.
  
!      'hot-bb-count-ws-permille'
            The number of most executed permilles, ranging from 0 to 1000,
            of the profiled execution of the entire program to which the
            execution count of a basic block must be part of in order to
--- 13789,13795 ----
            of the maximal execution count.  0 means that it is never
            considered hot.  Used in non-LTO mode.
  
!      ‘hot-bb-count-ws-permille’
            The number of most executed permilles, ranging from 0 to 1000,
            of the profiled execution of the entire program to which the
            execution count of a basic block must be part of in order to
*************** includes experimental options that may p
*** 13795,13801 ****
            profiled execution of the entire program.  0 means that it is
            never considered hot.  Used in LTO mode.
  
!      'hot-bb-frequency-fraction'
            The denominator n of fraction 1/n of the execution frequency
            of the entry block of a function that a basic block of this
            function needs to at least have in order to be considered hot.
--- 13799,13805 ----
            profiled execution of the entire program.  0 means that it is
            never considered hot.  Used in LTO mode.
  
!      ‘hot-bb-frequency-fraction’
            The denominator n of fraction 1/n of the execution frequency
            of the entry block of a function that a basic block of this
            function needs to at least have in order to be considered hot.
*************** includes experimental options that may p
*** 13804,13810 ****
            than 1/1000 of the frequency of the entry block of the
            function.  0 means that it is never considered hot.
  
!      'unlikely-bb-count-fraction'
            The denominator n of fraction 1/n of the number of profiled
            runs of the entire program below which the execution count of
            a basic block must be in order for the basic block to be
--- 13808,13814 ----
            than 1/1000 of the frequency of the entry block of the
            function.  0 means that it is never considered hot.
  
!      ‘unlikely-bb-count-fraction’
            The denominator n of fraction 1/n of the number of profiled
            runs of the entire program below which the execution count of
            a basic block must be in order for the basic block to be
*************** includes experimental options that may p
*** 13814,13820 ****
            program.  0 means that it is always considered unlikely
            executed.
  
!      'max-predicted-iterations'
            The maximum number of loop iterations we predict statically.
            This is useful in cases where a function contains a single
            loop with known bound and another loop with unknown bound.
--- 13818,13824 ----
            program.  0 means that it is always considered unlikely
            executed.
  
!      ‘max-predicted-iterations’
            The maximum number of loop iterations we predict statically.
            This is useful in cases where a function contains a single
            loop with known bound and another loop with unknown bound.
*************** includes experimental options that may p
*** 13823,13891 ****
            means that the loop without bounds appears artificially cold
            relative to the other one.
  
!      'builtin-expect-probability'
            Control the probability of the expression having the specified
            value.  This parameter takes a percentage (i.e. 0 ...  100) as
            input.
  
!      'builtin-string-cmp-inline-length'
            The maximum length of a constant string for a builtin string
            cmp call eligible for inlining.
  
!      'align-threshold'
  
            Select fraction of the maximal frequency of executions of a
            basic block in a function to align the basic block.
  
!      'align-loop-iterations'
  
            A loop expected to iterate at least the selected number of
            iterations is aligned.
  
!      'tracer-dynamic-coverage'
!      'tracer-dynamic-coverage-feedback'
  
            This value is used to limit superblock formation once the
            given percentage of executed instructions is covered.  This
            limits unnecessary code size expansion.
  
!           The 'tracer-dynamic-coverage-feedback' parameter is used only
            when profile feedback is available.  The real profiles (as
            opposed to statically estimated ones) are much less balanced
            allowing the threshold to be larger value.
  
!      'tracer-max-code-growth'
            Stop tail duplication once code growth has reached given
            percentage.  This is a rather artificial limit, as most of the
            duplicates are eliminated later in cross jumping, so it may be
            set to much higher values than is the desired code growth.
  
!      'tracer-min-branch-ratio'
  
            Stop reverse growth when the reverse probability of best edge
            is less than this threshold (in percent).
  
!      'tracer-min-branch-probability'
!      'tracer-min-branch-probability-feedback'
  
            Stop forward growth if the best edge has probability lower
            than this threshold.
  
!           Similarly to 'tracer-dynamic-coverage' two parameters are
!           provided.  'tracer-min-branch-probability-feedback' is used
            for compilation with profile feedback and
!           'tracer-min-branch-probability' compilation without.  The
            value for compilation with profile feedback needs to be more
            conservative (higher) in order to make tracer effective.
  
!      'stack-clash-protection-guard-size'
            Specify the size of the operating system provided stack guard
            as 2 raised to NUM bytes.  Higher values may reduce the number
            of explicit probes, but a value larger than the operating
            system provided guard will leave code vulnerable to stack
            clash style attacks.
  
!      'stack-clash-protection-probe-interval'
            Stack clash protection involves probing stack space as it is
            allocated.  This param controls the maximum distance between
            probes into the stack as 2 raised to NUM bytes.  Higher values
--- 13827,13895 ----
            means that the loop without bounds appears artificially cold
            relative to the other one.
  
!      ‘builtin-expect-probability’
            Control the probability of the expression having the specified
            value.  This parameter takes a percentage (i.e. 0 ...  100) as
            input.
  
!      ‘builtin-string-cmp-inline-length’
            The maximum length of a constant string for a builtin string
            cmp call eligible for inlining.
  
!      ‘align-threshold’
  
            Select fraction of the maximal frequency of executions of a
            basic block in a function to align the basic block.
  
!      ‘align-loop-iterations’
  
            A loop expected to iterate at least the selected number of
            iterations is aligned.
  
!      ‘tracer-dynamic-coverage’
!      ‘tracer-dynamic-coverage-feedback’
  
            This value is used to limit superblock formation once the
            given percentage of executed instructions is covered.  This
            limits unnecessary code size expansion.
  
!           The ‘tracer-dynamic-coverage-feedback’ parameter is used only
            when profile feedback is available.  The real profiles (as
            opposed to statically estimated ones) are much less balanced
            allowing the threshold to be larger value.
  
!      ‘tracer-max-code-growth’
            Stop tail duplication once code growth has reached given
            percentage.  This is a rather artificial limit, as most of the
            duplicates are eliminated later in cross jumping, so it may be
            set to much higher values than is the desired code growth.
  
!      ‘tracer-min-branch-ratio’
  
            Stop reverse growth when the reverse probability of best edge
            is less than this threshold (in percent).
  
!      ‘tracer-min-branch-probability’
!      ‘tracer-min-branch-probability-feedback’
  
            Stop forward growth if the best edge has probability lower
            than this threshold.
  
!           Similarly to ‘tracer-dynamic-coverage’ two parameters are
!           provided.  ‘tracer-min-branch-probability-feedback’ is used
            for compilation with profile feedback and
!           ‘tracer-min-branch-probability’ compilation without.  The
            value for compilation with profile feedback needs to be more
            conservative (higher) in order to make tracer effective.
  
!      ‘stack-clash-protection-guard-size’
            Specify the size of the operating system provided stack guard
            as 2 raised to NUM bytes.  Higher values may reduce the number
            of explicit probes, but a value larger than the operating
            system provided guard will leave code vulnerable to stack
            clash style attacks.
  
!      ‘stack-clash-protection-probe-interval’
            Stack clash protection involves probing stack space as it is
            allocated.  This param controls the maximum distance between
            probes into the stack as 2 raised to NUM bytes.  Higher values
*************** includes experimental options that may p
*** 13893,13907 ****
            than the operating system provided guard will leave code
            vulnerable to stack clash style attacks.
  
!      'max-cse-path-length'
  
            The maximum number of basic blocks on path that CSE considers.
  
!      'max-cse-insns'
            The maximum number of instructions CSE processes before
            flushing.
  
!      'ggc-min-expand'
  
            GCC uses a garbage collector to manage its own memory
            allocation.  This parameter specifies the minimum percentage
--- 13897,13911 ----
            than the operating system provided guard will leave code
            vulnerable to stack clash style attacks.
  
!      ‘max-cse-path-length’
  
            The maximum number of basic blocks on path that CSE considers.
  
!      ‘max-cse-insns’
            The maximum number of instructions CSE processes before
            flushing.
  
!      ‘ggc-min-expand’
  
            GCC uses a garbage collector to manage its own memory
            allocation.  This parameter specifies the minimum percentage
*************** includes experimental options that may p
*** 13910,13929 ****
            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
--- 13914,13933 ----
            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
*************** includes experimental options that may p
*** 13933,14045 ****
            to calculate RAM on a particular platform, the lower bound is
            used.  Setting this parameter very large effectively disables
            garbage collection.  Setting this parameter and
!           'ggc-min-expand' to zero causes a full collection to occur at
            every opportunity.
  
!      'max-reload-search-insns'
            The maximum number of instruction reload should look backward
            for equivalent register.  Increasing values mean more
            aggressive optimization, making the compilation time increase
            with probably slightly better performance.
  
!      'max-cselib-memory-locations'
            The maximum number of memory locations cselib should take into
            account.  Increasing values mean more aggressive optimization,
            making the compilation time increase with probably slightly
            better performance.
  
!      '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.
  
!      'max-sched-region-blocks'
            The maximum number of blocks in a region to be considered for
            interblock scheduling.
  
!      'max-pipeline-region-blocks'
            The maximum number of blocks in a region to be considered for
            pipelining in the selective scheduler.
  
!      'max-sched-region-insns'
            The maximum number of insns in a region to be considered for
            interblock scheduling.
  
!      'max-pipeline-region-insns'
            The maximum number of insns in a region to be considered for
            pipelining in the selective scheduler.
  
!      'min-spec-prob'
            The minimum probability (in percents) of reaching a source
            block for interblock speculative scheduling.
  
!      'max-sched-extend-regions-iters'
            The maximum number of iterations through CFG to extend
            regions.  A value of 0 disables region extensions.
  
!      'max-sched-insn-conflict-delay'
            The maximum conflict delay for an insn to be considered for
            speculative motion.
  
!      'sched-spec-prob-cutoff'
            The minimal probability of speculation success (in percents),
            so that speculative insns are scheduled.
  
!      'sched-state-edge-prob-cutoff'
            The minimum probability an edge must have for the scheduler to
            save its state across it.
  
!      'sched-mem-true-dep-cost'
            Minimal distance (in CPU cycles) between store and load
            targeting same memory locations.
  
!      'selsched-max-lookahead'
            The maximum size of the lookahead window of selective
            scheduling.  It is a depth of search for available
            instructions.
  
!      'selsched-max-sched-times'
            The maximum number of times that an instruction is scheduled
            during selective scheduling.  This is the limit on the number
            of iterations through which the instruction may be pipelined.
  
!      'selsched-insns-to-rename'
            The maximum number of best instructions in the ready list that
            are considered for renaming in the selective scheduler.
  
!      'sms-min-sc'
            The minimum value of stage count that swing modulo scheduler
            generates.
  
!      '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.
  
!      'max-combine-insns'
            The maximum number of instructions the RTL combiner tries to
            combine.
  
!      '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.
  
!      'ssp-buffer-size'
            The minimum size of buffers (i.e. arrays) that receive stack
!           smashing protection when '-fstack-protector' is used.
  
!      'min-size-for-stack-sharing'
            The minimum size of variables taking part in stack slot
            sharing when not optimizing.
  
!      'max-jump-thread-duplication-stmts'
            Maximum number of statements allowed in a block that needs to
            be duplicated when threading jumps.
  
!      'max-jump-thread-paths'
            The maximum number of paths to consider when searching for
            jump threading opportunities.  When arriving at a block,
            incoming edges are only considered if the number of paths to
--- 13937,14049 ----
            to calculate RAM on a particular platform, the lower bound is
            used.  Setting this parameter very large effectively disables
            garbage collection.  Setting this parameter and
!           ‘ggc-min-expand’ to zero causes a full collection to occur at
            every opportunity.
  
!      ‘max-reload-search-insns’
            The maximum number of instruction reload should look backward
            for equivalent register.  Increasing values mean more
            aggressive optimization, making the compilation time increase
            with probably slightly better performance.
  
!      ‘max-cselib-memory-locations’
            The maximum number of memory locations cselib should take into
            account.  Increasing values mean more aggressive optimization,
            making the compilation time increase with probably slightly
            better performance.
  
!      ‘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.
  
!      ‘max-sched-region-blocks’
            The maximum number of blocks in a region to be considered for
            interblock scheduling.
  
!      ‘max-pipeline-region-blocks’
            The maximum number of blocks in a region to be considered for
            pipelining in the selective scheduler.
  
!      ‘max-sched-region-insns’
            The maximum number of insns in a region to be considered for
            interblock scheduling.
  
!      ‘max-pipeline-region-insns’
            The maximum number of insns in a region to be considered for
            pipelining in the selective scheduler.
  
!      ‘min-spec-prob’
            The minimum probability (in percents) of reaching a source
            block for interblock speculative scheduling.
  
!      ‘max-sched-extend-regions-iters’
            The maximum number of iterations through CFG to extend
            regions.  A value of 0 disables region extensions.
  
!      ‘max-sched-insn-conflict-delay’
            The maximum conflict delay for an insn to be considered for
            speculative motion.
  
!      ‘sched-spec-prob-cutoff’
            The minimal probability of speculation success (in percents),
            so that speculative insns are scheduled.
  
!      ‘sched-state-edge-prob-cutoff’
            The minimum probability an edge must have for the scheduler to
            save its state across it.
  
!      ‘sched-mem-true-dep-cost’
            Minimal distance (in CPU cycles) between store and load
            targeting same memory locations.
  
!      ‘selsched-max-lookahead’
            The maximum size of the lookahead window of selective
            scheduling.  It is a depth of search for available
            instructions.
  
!      ‘selsched-max-sched-times’
            The maximum number of times that an instruction is scheduled
            during selective scheduling.  This is the limit on the number
            of iterations through which the instruction may be pipelined.
  
!      ‘selsched-insns-to-rename’
            The maximum number of best instructions in the ready list that
            are considered for renaming in the selective scheduler.
  
!      ‘sms-min-sc’
            The minimum value of stage count that swing modulo scheduler
            generates.
  
!      ‘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.
  
!      ‘max-combine-insns’
            The maximum number of instructions the RTL combiner tries to
            combine.
  
!      ‘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.
  
!      ‘ssp-buffer-size’
            The minimum size of buffers (i.e. arrays) that receive stack
!           smashing protection when ‘-fstack-protector’ is used.
  
!      ‘min-size-for-stack-sharing’
            The minimum size of variables taking part in stack slot
            sharing when not optimizing.
  
!      ‘max-jump-thread-duplication-stmts’
            Maximum number of statements allowed in a block that needs to
            be duplicated when threading jumps.
  
!      ‘max-jump-thread-paths’
            The maximum number of paths to consider when searching for
            jump threading opportunities.  When arriving at a block,
            incoming edges are only considered if the number of paths to
*************** includes experimental options that may p
*** 14047,14076 ****
            does not exhaust the specified maximum number of paths to
            consider.
  
!      'max-fields-for-field-sensitive'
            Maximum number of fields in a structure treated in a field
            sensitive manner during pointer analysis.
  
!      'prefetch-latency'
            Estimate on average number of instructions that are executed
            before prefetch finishes.  The distance prefetched ahead is
            proportional to this constant.  Increasing this number may
            also lead to less streams being prefetched (see
!           'simultaneous-prefetches').
  
!      'simultaneous-prefetches'
            Maximum number of prefetches that can run at the same time.
  
!      'l1-cache-line-size'
            The size of cache line in L1 data cache, in bytes.
  
!      'l1-cache-size'
            The size of L1 data cache, in kilobytes.
  
!      'l2-cache-size'
            The size of L2 data cache, in kilobytes.
  
!      'prefetch-dynamic-strides'
            Whether the loop array prefetch pass should issue software
            prefetch hints for strides that are non-constant.  In some
            cases this may be beneficial, though the fact the stride is
--- 14051,14080 ----
            does not exhaust the specified maximum number of paths to
            consider.
  
!      ‘max-fields-for-field-sensitive’
            Maximum number of fields in a structure treated in a field
            sensitive manner during pointer analysis.
  
!      ‘prefetch-latency’
            Estimate on average number of instructions that are executed
            before prefetch finishes.  The distance prefetched ahead is
            proportional to this constant.  Increasing this number may
            also lead to less streams being prefetched (see
!           ‘simultaneous-prefetches’).
  
!      ‘simultaneous-prefetches’
            Maximum number of prefetches that can run at the same time.
  
!      ‘l1-cache-line-size’
            The size of cache line in L1 data cache, in bytes.
  
!      ‘l1-cache-size’
            The size of L1 data cache, in kilobytes.
  
!      ‘l2-cache-size’
            The size of L2 data cache, in kilobytes.
  
!      ‘prefetch-dynamic-strides’
            Whether the loop array prefetch pass should issue software
            prefetch hints for strides that are non-constant.  In some
            cases this may be beneficial, though the fact the stride is
*************** includes experimental options that may p
*** 14080,14088 ****
            Set to 1 if the prefetch hints should be issued for
            non-constant strides.  Set to 0 if prefetch hints should be
            issued only for strides that are known to be constant and
!           below 'prefetch-minimum-stride'.
  
!      'prefetch-minimum-stride'
            Minimum constant stride, in bytes, to start using prefetch
            hints for.  If the stride is less than this threshold,
            prefetch hints will not be issued.
--- 14084,14092 ----
            Set to 1 if the prefetch hints should be issued for
            non-constant strides.  Set to 0 if prefetch hints should be
            issued only for strides that are known to be constant and
!           below ‘prefetch-minimum-stride’.
  
!      ‘prefetch-minimum-stride’
            Minimum constant stride, in bytes, to start using prefetch
            hints for.  If the stride is less than this threshold,
            prefetch hints will not be issued.
*************** includes experimental options that may p
*** 14100,14110 ****
            This setting is only useful for strides that are known and
            constant.
  
!      'destructive-interference-size'
!      'constructive-interference-size'
            The values for the C++17 variables
!           'std::hardware_destructive_interference_size' and
!           'std::hardware_constructive_interference_size'.  The
            destructive interference size is the minimum recommended
            offset between two independent concurrently-accessed objects;
            the constructive interference size is the maximum recommended
--- 14104,14114 ----
            This setting is only useful for strides that are known and
            constant.
  
!      ‘destructive-interference-size’
!      ‘constructive-interference-size’
            The values for the C++17 variables
!           ‘std::hardware_destructive_interference_size’ and
!           ‘std::hardware_constructive_interference_size’.  The
            destructive interference size is the minimum recommended
            offset between two independent concurrently-accessed objects;
            the constructive interference size is the maximum recommended
*************** includes experimental options that may p
*** 14118,14150 ****
            The destructive interference size is intended to be used for
            layout, and thus has ABI impact.  The default value is not
            expected to be stable, and on some targets varies with
!           '-mtune', so use of this variable in a context where ABI
            stability is important, such as the public interface of a
            library, is strongly discouraged; if it is used in that
            context, users can stabilize the value using this option.
  
            The constructive interference size is less sensitive, as it is
!           typically only used in a 'static_assert' to make sure that a
            type fits within a cache line.
  
!           See also '-Winterference-size'.
  
!      'loop-interchange-max-num-stmts'
            The maximum number of stmts in a loop to be interchanged.
  
!      'loop-interchange-stride-ratio'
            The minimum ratio between stride of two loops for interchange
            to be profitable.
  
!      '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.
            Should always be 1, which uses a more efficient internal
            mechanism for comparing types in C++ and Objective-C++.
--- 14122,14154 ----
            The destructive interference size is intended to be used for
            layout, and thus has ABI impact.  The default value is not
            expected to be stable, and on some targets varies with
!           ‘-mtune’, so use of this variable in a context where ABI
            stability is important, such as the public interface of a
            library, is strongly discouraged; if it is used in that
            context, users can stabilize the value using this option.
  
            The constructive interference size is less sensitive, as it is
!           typically only used in a ‘static_assert’ to make sure that a
            type fits within a cache line.
  
!           See also ‘-Winterference-size’.
  
!      ‘loop-interchange-max-num-stmts’
            The maximum number of stmts in a loop to be interchanged.
  
!      ‘loop-interchange-stride-ratio’
            The minimum ratio between stride of two loops for interchange
            to be profitable.
  
!      ‘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.
            Should always be 1, which uses a more efficient internal
            mechanism for comparing types in C++ and Objective-C++.
*************** includes experimental options that may p
*** 14152,14166 ****
            compilation failures, set this value to 0 to disable canonical
            types.
  
!      'switch-conversion-max-branch-ratio'
            Switch initialization conversion refuses to create arrays that
!           are bigger than 'switch-conversion-max-branch-ratio' times the
            number of branches in the switch.
  
!      'max-partial-antic-length'
            Maximum length of the partial antic set computed during the
            tree partial redundancy elimination optimization
!           ('-ftree-pre') when optimizing at '-O3' and above.  For some
            sorts of source code the enhanced partial redundancy
            elimination optimization can run away, consuming all of the
            memory available on the host machine.  This parameter sets a
--- 14156,14170 ----
            compilation failures, set this value to 0 to disable canonical
            types.
  
!      ‘switch-conversion-max-branch-ratio’
            Switch initialization conversion refuses to create arrays that
!           are bigger than ‘switch-conversion-max-branch-ratio’ times the
            number of branches in the switch.
  
!      ‘max-partial-antic-length’
            Maximum length of the partial antic set computed during the
            tree partial redundancy elimination optimization
!           (‘-ftree-pre’) when optimizing at ‘-O3’ and above.  For some
            sorts of source code the enhanced partial redundancy
            elimination optimization can run away, consuming all of the
            memory available on the host machine.  This parameter sets a
*************** includes experimental options that may p
*** 14168,14180 ****
            prevents the runaway behavior.  Setting a value of 0 for this
            parameter allows an unlimited set length.
  
!      'rpo-vn-max-loop-depth'
            Maximum loop depth that is value-numbered optimistically.
            When the limit hits the innermost RPO-VN-MAX-LOOP-DEPTH loops
            and the outermost loop in the loop nest are value-numbered
            optimistically and the remaining ones not.
  
!      'sccvn-max-alias-queries-per-access'
            Maximum number of alias-oracle queries we perform when looking
            for redundancies for loads and stores.  If this limit is hit
            the search is aborted and the load or store is not considered
--- 14172,14184 ----
            prevents the runaway behavior.  Setting a value of 0 for this
            parameter allows an unlimited set length.
  
!      ‘rpo-vn-max-loop-depth’
            Maximum loop depth that is value-numbered optimistically.
            When the limit hits the innermost RPO-VN-MAX-LOOP-DEPTH loops
            and the outermost loop in the loop nest are value-numbered
            optimistically and the remaining ones not.
  
!      ‘sccvn-max-alias-queries-per-access’
            Maximum number of alias-oracle queries we perform when looking
            for redundancies for loads and stores.  If this limit is hit
            the search is aborted and the load or store is not considered
*************** includes experimental options that may p
*** 14182,14195 ****
            to the number of stores on all paths from the load to the
            function entry.
  
!      'ira-max-loops-num'
            IRA uses regional register allocation by default.  If a
            function contains more loops than the number given by this
            parameter, only at most the given number of the most
            frequently-executed loops form regions for regional register
            allocation.
  
!      'ira-max-conflict-table-size'
            Although IRA uses a sophisticated algorithm to compress the
            conflict table, the table can still require excessive amounts
            of memory for huge functions.  If the conflict table for a
--- 14186,14199 ----
            to the number of stores on all paths from the load to the
            function entry.
  
!      ‘ira-max-loops-num’
            IRA uses regional register allocation by default.  If a
            function contains more loops than the number given by this
            parameter, only at most the given number of the most
            frequently-executed loops form regions for regional register
            allocation.
  
!      ‘ira-max-conflict-table-size’
            Although IRA uses a sophisticated algorithm to compress the
            conflict table, the table can still require excessive amounts
            of memory for huge functions.  If the conflict table for a
*************** includes experimental options that may p
*** 14198,14211 ****
            simpler, and lower-quality algorithm that does not require
            building a pseudo-register conflict table.
  
!      'ira-loop-reserved-regs'
            IRA can be used to evaluate more accurate register pressure in
!           loops for decisions to move loop invariants (see '-O3').  The
            number of available registers reserved for some other purposes
            is given by this parameter.  Default of the parameter is the
            best found from numerous experiments.
  
!      'ira-consider-dup-in-all-alts'
            Make IRA to consider matching constraint (duplicated operand
            number) heavily in all available alternatives for preferred
            register class.  If it is set as zero, it means IRA only
--- 14202,14215 ----
            simpler, and lower-quality algorithm that does not require
            building a pseudo-register conflict table.
  
!      ‘ira-loop-reserved-regs’
            IRA can be used to evaluate more accurate register pressure in
!           loops for decisions to move loop invariants (see ‘-O3’).  The
            number of available registers reserved for some other purposes
            is given by this parameter.  Default of the parameter is the
            best found from numerous experiments.
  
!      ‘ira-consider-dup-in-all-alts’
            Make IRA to consider matching constraint (duplicated operand
            number) heavily in all available alternatives for preferred
            register class.  If it is set as zero, it means IRA only
*************** includes experimental options that may p
*** 14216,14226 ****
            with an appropriate register class and respect the found
            qualified matching constraint.
  
!      'ira-simple-lra-insn-threshold'
            Approximate function insn number in 1K units triggering simple
            local RA.
  
!      'lra-inheritance-ebb-probability-cutoff'
            LRA tries to reuse values reloaded in registers in subsequent
            insns.  This optimization is called inheritance.  EBB is used
            as a region to do this optimization.  The parameter defines a
--- 14220,14230 ----
            with an appropriate register class and respect the found
            qualified matching constraint.
  
!      ‘ira-simple-lra-insn-threshold’
            Approximate function insn number in 1K units triggering simple
            local RA.
  
!      ‘lra-inheritance-ebb-probability-cutoff’
            LRA tries to reuse values reloaded in registers in subsequent
            insns.  This optimization is called inheritance.  EBB is used
            as a region to do this optimization.  The parameter defines a
*************** includes experimental options that may p
*** 14228,14248 ****
            add BB to inheritance EBB in LRA. The default value was chosen
            from numerous runs of SPEC2000 on x86-64.
  
!      'loop-invariant-max-bbs-in-loop'
            Loop invariant motion can be very expensive, both in
            compilation time and in amount of needed compile-time memory,
            with very large loops.  Loops with more basic blocks than this
            parameter won't have loop invariant motion optimization
            performed on them.
  
!      'loop-max-datarefs-for-datadeps'
            Building data dependencies is expensive for very large loops.
            This parameter limits the number of data references in loops
            that are considered for data dependence analysis.  These large
            loops are no handled by the optimizations using loop data
            dependencies.
  
!      '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
--- 14232,14252 ----
            add BB to inheritance EBB in LRA. The default value was chosen
            from numerous runs of SPEC2000 on x86-64.
  
!      ‘loop-invariant-max-bbs-in-loop’
            Loop invariant motion can be very expensive, both in
            compilation time and in amount of needed compile-time memory,
            with very large loops.  Loops with more basic blocks than this
            parameter won't have loop invariant motion optimization
            performed on them.
  
!      ‘loop-max-datarefs-for-datadeps’
            Building data dependencies is expensive for very large loops.
            This parameter limits the number of data references in loops
            that are considered for data dependence analysis.  These large
            loops are no handled by the optimizations using loop data
            dependencies.
  
!      ‘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
*************** includes experimental options that may p
*** 14252,14258 ****
            analysis is completely disabled for the function.  Setting the
            parameter to zero makes it unlimited.
  
!      'max-vartrack-expr-depth'
            Sets a maximum number of recursion levels when attempting to
            map variable names or debug temporaries to value expressions.
            This trades compilation time for more complete debug
--- 14256,14262 ----
            analysis is completely disabled for the function.  Setting the
            parameter to zero makes it unlimited.
  
!      ‘max-vartrack-expr-depth’
            Sets a maximum number of recursion levels when attempting to
            map variable names or debug temporaries to value expressions.
            This trades compilation time for more complete debug
*************** includes experimental options that may p
*** 14262,14442 ****
            compiler to find more complex debug expressions, but compile
            time and memory use may grow.
  
!      'max-debug-marker-count'
            Sets a threshold on the number of debug markers (e.g. begin
            stmt markers) to avoid complexity explosion at inlining or
            expanding to RTL. If a function has more such gimple stmts
            than the set limit, such stmts will be dropped from the
            inlined copy of a function, and from its RTL expansion.
  
!      '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-deref-prob-threshold'
            IPA-SRA replaces a pointer which is known not be NULL with one
            or more new parameters only when the probability (in percent,
            relative to function entry) of it being dereferenced is higher
            than this parameter.
  
!      'ipa-sra-ptr-growth-factor'
            IPA-SRA replaces a pointer to an aggregate with one or more
            new parameters only when their cumulative size is less or
!           equal to 'ipa-sra-ptr-growth-factor' times the size of the
            original pointer parameter.
  
!      'ipa-sra-ptrwrap-growth-factor'
            Additional maximum allowed growth of total size of new
            parameters that ipa-sra replaces a pointer to an aggregate
            with, if it points to a local variable that the caller only
            writes to and passes it as an argument to other functions.
  
!      'ipa-sra-max-replacements'
            Maximum pieces of an aggregate that IPA-SRA tracks.  As a
            consequence, it is also the maximum number of replacements of
            a formal parameter.
  
!      'sra-max-scalarization-size-Ospeed'
!      'sra-max-scalarization-size-Osize'
            The two Scalar Reduction of Aggregates passes (SRA and
            IPA-SRA) aim to replace scalar parts of aggregates with uses
            of independent scalar variables.  These parameters control the
            maximum size, in storage units, of aggregate which is
            considered for replacement when compiling for speed
!           ('sra-max-scalarization-size-Ospeed') or size
!           ('sra-max-scalarization-size-Osize') respectively.
  
!      'sra-max-propagations'
            The maximum number of artificial accesses that Scalar
            Replacement of Aggregates (SRA) will track, per one local
            variable, in order to facilitate copy propagation.
  
!      'tm-max-aggregate-size'
            When making copies of thread-local variables in a transaction,
            this parameter specifies the size in bytes after which
            variables are saved with the logging functions as opposed to
            save/restore code sequence pairs.  This option only applies
!           when using '-fgnu-tm'.
  
!      'graphite-max-nb-scop-params'
            To avoid exponential effects in the Graphite loop transforms,
            the number of parameters in a Static Control Part (SCoP) is
            bounded.  A value of zero can be used to lift the bound.  A
            variable whose value is unknown at compilation time and
            defined outside a SCoP is a parameter of the SCoP.
  
!      '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.
  
!      'ipa-jump-function-lookups'
            Specifies number of statements visited during jump function
            offset discovery.
  
!      'ipa-cp-value-list-size'
            IPA-CP attempts to track all possible values and types passed
            to a function's parameter in order to propagate them and
!           perform devirtualization.  'ipa-cp-value-list-size' is the
            maximum number of values and types it stores per one formal
            parameter of a function.
  
!      'ipa-cp-eval-threshold'
            IPA-CP calculates its own score of cloning profitability
            heuristics and performs those cloning opportunities with
!           scores that exceed 'ipa-cp-eval-threshold'.
  
!      'ipa-cp-max-recursive-depth'
            Maximum depth of recursive cloning for self-recursive
            function.
  
!      'ipa-cp-min-recursive-probability'
            Recursive cloning only when the probability of call being
            executed exceeds the parameter.
  
!      'ipa-cp-profile-count-base'
!           When using '-fprofile-use' option, IPA-CP will consider the
            measured execution count of a call graph edge at this
            percentage position in their histogram as the basis for its
            heuristics calculation.
  
!      'ipa-cp-recursive-freq-factor'
            The number of times interprocedural copy propagation expects
            recursive functions to call themselves.
  
!      'ipa-cp-recursion-penalty'
            Percentage penalty the recursive functions will receive when
            they are evaluated for cloning.
  
!      'ipa-cp-single-call-penalty'
            Percentage penalty functions containing a single call to
            another function will receive when they are evaluated for
            cloning.
  
!      'ipa-max-agg-items'
            IPA-CP is also capable to propagate a number of scalar values
!           passed in an aggregate.  'ipa-max-agg-items' controls the
            maximum number of such values per one parameter.
  
!      'ipa-cp-loop-hint-bonus'
            When IPA-CP determines that a cloning candidate would make the
            number of iterations of a loop known, it adds a bonus of
!           'ipa-cp-loop-hint-bonus' to the profitability score of the
            candidate.
  
!      'ipa-max-loop-predicates'
            The maximum number of different predicates IPA will use to
            describe when loops in a function have known properties.
  
!      'ipa-max-aa-steps'
            During its analysis of function bodies, IPA-CP employs alias
            analysis in order to track values pointed to by function
            parameters.  In order not spend too much time analyzing huge
            functions, it gives up and consider all memory clobbered after
!           examining 'ipa-max-aa-steps' statements modifying memory.
  
!      'ipa-max-switch-predicate-bounds'
            Maximal number of boundary endpoints of case ranges of switch
            statement.  For switch exceeding this limit, IPA-CP will not
            construct cloning cost predicate, which is used to estimate
            cloning benefit, for default case of the switch statement.
  
!      'ipa-max-param-expr-ops'
            IPA-CP will analyze conditional statement that references some
            function parameter to estimate benefit for cloning upon
            certain constant value.  But if number of operations in a
!           parameter expression exceeds 'ipa-max-param-expr-ops', the
            expression is treated as complicated one, and is not handled
            by IPA analysis.
  
!      'lto-partitions'
            Specify desired number of partitions produced during WHOPR
            compilation.  The number of partitions should exceed the
            number of CPUs used for compilation.
  
!      'lto-min-partition'
            Size of minimal partition for WHOPR (in estimated
            instructions).  This prevents expenses of splitting very small
            programs into too many partitions.
  
!      'lto-max-partition'
            Size of max partition for WHOPR (in estimated instructions).
            to provide an upper bound for individual size of partition.
            Meant to be used only with balanced partitioning.
  
!      'lto-max-streaming-parallelism'
            Maximal number of parallel processes used for LTO streaming.
  
!      'cxx-max-namespaces-for-diagnostic-help'
            The maximum number of namespaces to consult for suggestions
            when C++ name lookup fails for an identifier.
  
!      'sink-frequency-threshold'
            The maximum relative execution frequency (in percents) of the
            target block relative to a statement's original block to allow
            statement sinking of a statement.  Larger numbers result in
--- 14266,14446 ----
            compiler to find more complex debug expressions, but compile
            time and memory use may grow.
  
!      ‘max-debug-marker-count’
            Sets a threshold on the number of debug markers (e.g. begin
            stmt markers) to avoid complexity explosion at inlining or
            expanding to RTL. If a function has more such gimple stmts
            than the set limit, such stmts will be dropped from the
            inlined copy of a function, and from its RTL expansion.
  
!      ‘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-deref-prob-threshold’
            IPA-SRA replaces a pointer which is known not be NULL with one
            or more new parameters only when the probability (in percent,
            relative to function entry) of it being dereferenced is higher
            than this parameter.
  
!      ‘ipa-sra-ptr-growth-factor’
            IPA-SRA replaces a pointer to an aggregate with one or more
            new parameters only when their cumulative size is less or
!           equal to ‘ipa-sra-ptr-growth-factor’ times the size of the
            original pointer parameter.
  
!      ‘ipa-sra-ptrwrap-growth-factor’
            Additional maximum allowed growth of total size of new
            parameters that ipa-sra replaces a pointer to an aggregate
            with, if it points to a local variable that the caller only
            writes to and passes it as an argument to other functions.
  
!      ‘ipa-sra-max-replacements’
            Maximum pieces of an aggregate that IPA-SRA tracks.  As a
            consequence, it is also the maximum number of replacements of
            a formal parameter.
  
!      ‘sra-max-scalarization-size-Ospeed’
!      ‘sra-max-scalarization-size-Osize’
            The two Scalar Reduction of Aggregates passes (SRA and
            IPA-SRA) aim to replace scalar parts of aggregates with uses
            of independent scalar variables.  These parameters control the
            maximum size, in storage units, of aggregate which is
            considered for replacement when compiling for speed
!           (‘sra-max-scalarization-size-Ospeed’) or size
!           (‘sra-max-scalarization-size-Osize’) respectively.
  
!      ‘sra-max-propagations’
            The maximum number of artificial accesses that Scalar
            Replacement of Aggregates (SRA) will track, per one local
            variable, in order to facilitate copy propagation.
  
!      ‘tm-max-aggregate-size’
            When making copies of thread-local variables in a transaction,
            this parameter specifies the size in bytes after which
            variables are saved with the logging functions as opposed to
            save/restore code sequence pairs.  This option only applies
!           when using ‘-fgnu-tm’.
  
!      ‘graphite-max-nb-scop-params’
            To avoid exponential effects in the Graphite loop transforms,
            the number of parameters in a Static Control Part (SCoP) is
            bounded.  A value of zero can be used to lift the bound.  A
            variable whose value is unknown at compilation time and
            defined outside a SCoP is a parameter of the SCoP.
  
!      ‘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.
  
!      ‘ipa-jump-function-lookups’
            Specifies number of statements visited during jump function
            offset discovery.
  
!      ‘ipa-cp-value-list-size’
            IPA-CP attempts to track all possible values and types passed
            to a function's parameter in order to propagate them and
!           perform devirtualization.  ‘ipa-cp-value-list-size’ is the
            maximum number of values and types it stores per one formal
            parameter of a function.
  
!      ‘ipa-cp-eval-threshold’
            IPA-CP calculates its own score of cloning profitability
            heuristics and performs those cloning opportunities with
!           scores that exceed ‘ipa-cp-eval-threshold’.
  
!      ‘ipa-cp-max-recursive-depth’
            Maximum depth of recursive cloning for self-recursive
            function.
  
!      ‘ipa-cp-min-recursive-probability’
            Recursive cloning only when the probability of call being
            executed exceeds the parameter.
  
!      ‘ipa-cp-profile-count-base’
!           When using ‘-fprofile-use’ option, IPA-CP will consider the
            measured execution count of a call graph edge at this
            percentage position in their histogram as the basis for its
            heuristics calculation.
  
!      ‘ipa-cp-recursive-freq-factor’
            The number of times interprocedural copy propagation expects
            recursive functions to call themselves.
  
!      ‘ipa-cp-recursion-penalty’
            Percentage penalty the recursive functions will receive when
            they are evaluated for cloning.
  
!      ‘ipa-cp-single-call-penalty’
            Percentage penalty functions containing a single call to
            another function will receive when they are evaluated for
            cloning.
  
!      ‘ipa-max-agg-items’
            IPA-CP is also capable to propagate a number of scalar values
!           passed in an aggregate.  ‘ipa-max-agg-items’ controls the
            maximum number of such values per one parameter.
  
!      ‘ipa-cp-loop-hint-bonus’
            When IPA-CP determines that a cloning candidate would make the
            number of iterations of a loop known, it adds a bonus of
!           ‘ipa-cp-loop-hint-bonus’ to the profitability score of the
            candidate.
  
!      ‘ipa-max-loop-predicates’
            The maximum number of different predicates IPA will use to
            describe when loops in a function have known properties.
  
!      ‘ipa-max-aa-steps’
            During its analysis of function bodies, IPA-CP employs alias
            analysis in order to track values pointed to by function
            parameters.  In order not spend too much time analyzing huge
            functions, it gives up and consider all memory clobbered after
!           examining ‘ipa-max-aa-steps’ statements modifying memory.
  
!      ‘ipa-max-switch-predicate-bounds’
            Maximal number of boundary endpoints of case ranges of switch
            statement.  For switch exceeding this limit, IPA-CP will not
            construct cloning cost predicate, which is used to estimate
            cloning benefit, for default case of the switch statement.
  
!      ‘ipa-max-param-expr-ops’
            IPA-CP will analyze conditional statement that references some
            function parameter to estimate benefit for cloning upon
            certain constant value.  But if number of operations in a
!           parameter expression exceeds ‘ipa-max-param-expr-ops’, the
            expression is treated as complicated one, and is not handled
            by IPA analysis.
  
!      ‘lto-partitions’
            Specify desired number of partitions produced during WHOPR
            compilation.  The number of partitions should exceed the
            number of CPUs used for compilation.
  
!      ‘lto-min-partition’
            Size of minimal partition for WHOPR (in estimated
            instructions).  This prevents expenses of splitting very small
            programs into too many partitions.
  
!      ‘lto-max-partition’
            Size of max partition for WHOPR (in estimated instructions).
            to provide an upper bound for individual size of partition.
            Meant to be used only with balanced partitioning.
  
!      ‘lto-max-streaming-parallelism’
            Maximal number of parallel processes used for LTO streaming.
  
!      ‘cxx-max-namespaces-for-diagnostic-help’
            The maximum number of namespaces to consult for suggestions
            when C++ name lookup fails for an identifier.
  
!      ‘sink-frequency-threshold’
            The maximum relative execution frequency (in percents) of the
            target block relative to a statement's original block to allow
            statement sinking of a statement.  Larger numbers result in
*************** includes experimental options that may p
*** 14444,14688 ****
            adjustment is applied for statements with memory operands as
            those are even more profitable so sink.
  
!      'max-stores-to-sink'
            The maximum number of conditional store pairs that can be
!           sunk.  Set to 0 if either vectorization ('-ftree-vectorize')
!           or if-conversion ('-ftree-loop-if-convert') is disabled.
  
!      'case-values-threshold'
            The smallest number of different values for which it is best
            to use a jump-table instead of a tree of conditional branches.
            If the value is 0, use the default for the machine.
  
!      'jump-table-max-growth-ratio-for-size'
            The maximum code size growth ratio when expanding into a jump
            table (in percent).  The parameter is used when optimizing for
            size.
  
!      'jump-table-max-growth-ratio-for-speed'
            The maximum code size growth ratio when expanding into a jump
            table (in percent).  The parameter is used when optimizing for
            speed.
  
!      'tree-reassoc-width'
            Set the maximum number of instructions executed in parallel in
            reassociated tree.  This parameter overrides target dependent
            heuristics used by default if has non zero value.
  
!      'sched-pressure-algorithm'
            Choose between the two available implementations of
!           '-fsched-pressure'.  Algorithm 1 is the original
            implementation and is the more likely to prevent instructions
            from being reordered.  Algorithm 2 was designed to be a
            compromise between the relatively conservative approach taken
            by algorithm 1 and the rather aggressive approach taken by the
            default scheduler.  It relies more heavily on having a regular
            register file and accurate register pressure classes.  See
!           'haifa-sched.cc' in the GCC sources for more details.
  
            The default choice depends on the target.
  
!      'max-slsr-cand-scan'
            Set the maximum number of existing candidates that are
            considered when seeking a basis for a new straight-line
            strength reduction candidate.
  
!      'asan-globals'
            Enable buffer overflow detection for global objects.  This
            kind of protection is enabled by default if you are using
!           '-fsanitize=address' option.  To disable global objects
!           protection use '--param asan-globals=0'.
  
!      'asan-stack'
            Enable buffer overflow detection for stack objects.  This kind
            of protection is enabled by default when using
!           '-fsanitize=address'.  To disable stack protection use
!           '--param asan-stack=0' option.
  
!      'asan-instrument-reads'
            Enable buffer overflow detection for memory reads.  This kind
            of protection is enabled by default when using
!           '-fsanitize=address'.  To disable memory reads protection use
!           '--param asan-instrument-reads=0'.
  
!      'asan-instrument-writes'
            Enable buffer overflow detection for memory writes.  This kind
            of protection is enabled by default when using
!           '-fsanitize=address'.  To disable memory writes protection use
!           '--param asan-instrument-writes=0' option.
  
!      'asan-memintrin'
            Enable detection for built-in functions.  This kind of
            protection is enabled by default when using
!           '-fsanitize=address'.  To disable built-in functions
!           protection use '--param asan-memintrin=0'.
  
!      'asan-use-after-return'
            Enable detection of use-after-return.  This kind of protection
!           is enabled by default when using the '-fsanitize=address'
!           option.  To disable it use '--param asan-use-after-return=0'.
  
            Note: By default the check is disabled at run time.  To enable
!           it, add 'detect_stack_use_after_return=1' to the environment
!           variable 'ASAN_OPTIONS'.
  
!      'asan-instrumentation-with-call-threshold'
            If number of memory accesses in function being instrumented is
            greater or equal to this number, use callbacks instead of
!           inline checks.  E.g.  to disable inline code use '--param
!           asan-instrumentation-with-call-threshold=0'.
  
!      'asan-kernel-mem-intrinsic-prefix'
!           If nonzero, prefix calls to 'memcpy', 'memset' and 'memmove'
!           with '__asan_' or '__hwasan_' for '-fsanitize=kernel-address'
!           or '-fsanitize=kernel-hwaddress', respectively.
  
!      'hwasan-instrument-stack'
            Enable hwasan instrumentation of statically sized
            stack-allocated variables.  This kind of instrumentation is
!           enabled by default when using '-fsanitize=hwaddress' and
!           disabled by default when using '-fsanitize=kernel-hwaddress'.
!           To disable stack instrumentation use '--param
!           hwasan-instrument-stack=0', and to enable it use '--param
!           hwasan-instrument-stack=1'.
  
!      'hwasan-random-frame-tag'
            When using stack instrumentation, decide tags for stack
            variables using a deterministic sequence beginning at a random
            tag for each frame.  With this parameter unset tags are chosen
            using the same sequence but beginning from 1.  This is enabled
!           by default for '-fsanitize=hwaddress' and unavailable for
!           '-fsanitize=kernel-hwaddress'.  To disable it use '--param
!           hwasan-random-frame-tag=0'.
  
!      'hwasan-instrument-allocas'
            Enable hwasan instrumentation of dynamically sized
            stack-allocated variables.  This kind of instrumentation is
!           enabled by default when using '-fsanitize=hwaddress' and
!           disabled by default when using '-fsanitize=kernel-hwaddress'.
!           To disable instrumentation of such variables use '--param
!           hwasan-instrument-allocas=0', and to enable it use '--param
!           hwasan-instrument-allocas=1'.
  
!      'hwasan-instrument-reads'
            Enable hwasan checks on memory reads.  Instrumentation of
!           reads is enabled by default for both '-fsanitize=hwaddress'
!           and '-fsanitize=kernel-hwaddress'.  To disable checking memory
!           reads use '--param hwasan-instrument-reads=0'.
  
!      'hwasan-instrument-writes'
            Enable hwasan checks on memory writes.  Instrumentation of
!           writes is enabled by default for both '-fsanitize=hwaddress'
!           and '-fsanitize=kernel-hwaddress'.  To disable checking memory
!           writes use '--param hwasan-instrument-writes=0'.
  
!      'hwasan-instrument-mem-intrinsics'
            Enable hwasan instrumentation of builtin functions.
            Instrumentation of these builtin functions is enabled by
!           default for both '-fsanitize=hwaddress' and
!           '-fsanitize=kernel-hwaddress'.  To disable instrumentation of
!           builtin functions use '--param
!           hwasan-instrument-mem-intrinsics=0'.
  
!      'use-after-scope-direct-emission-threshold'
            If the size of a local variable in bytes is smaller or equal
            to this number, directly poison (or unpoison) shadow memory
            instead of using run-time callbacks.
  
!      'tsan-distinguish-volatile'
            Emit special instrumentation for accesses to volatiles.
  
!      'tsan-instrument-func-entry-exit'
            Emit instrumentation calls to __tsan_func_entry() and
            __tsan_func_exit().
  
!      'max-fsm-thread-path-insns'
            Maximum number of instructions to copy when duplicating blocks
            on a finite state automaton jump thread path.
  
!      'threader-debug'
            threader-debug=[none|all] Enables verbose dumping of the
            threader solver.
  
!      'parloops-chunk-size'
            Chunk size of omp schedule for loops parallelized by parloops.
  
!      'parloops-schedule'
            Schedule type of omp schedule for loops parallelized by
            parloops (static, dynamic, guided, auto, runtime).
  
!      'parloops-min-per-thread'
            The minimum number of iterations per thread of an innermost
            parallelized loop for which the parallelized variant is
            preferred over the single threaded one.  Note that for a
            parallelized loop nest the minimum number of iterations of the
            outermost loop per thread is two.
  
!      'max-ssa-name-query-depth'
            Maximum depth of recursion when querying properties of SSA
            names in things like fold routines.  One level of recursion
            corresponds to following a use-def chain.
  
!      'max-speculative-devirt-maydefs'
            The maximum number of may-defs we analyze when looking for a
            must-def specifying the dynamic type of an object that invokes
            a virtual call we may be able to devirtualize speculatively.
  
!      'evrp-sparse-threshold'
            Maximum number of basic blocks before EVRP uses a sparse
            cache.
  
!      'ranger-debug'
            Specifies the type of debug output to be issued for ranges.
  
!      'evrp-switch-limit'
            Specifies the maximum number of switch cases before EVRP
            ignores a switch.
  
!      'unroll-jam-min-percent'
            The minimum percentage of memory references that must be
            optimized away for the unroll-and-jam transformation to be
            considered profitable.
  
!      'unroll-jam-max-unroll'
            The maximum number of times the outer loop should be unrolled
            by the unroll-and-jam transformation.
  
!      'max-rtl-if-conversion-unpredictable-cost'
            Maximum permissible cost for the sequence that would be
            generated by the RTL if-conversion pass for a branch that is
            considered unpredictable.
  
!      'max-variable-expansions-in-unroller'
!           If '-fvariable-expansion-in-unroller' is used, the maximum
            number of times that an individual variable will be expanded
            during loop unrolling.
  
!      'partial-inlining-entry-probability'
            Maximum probability of the entry BB of split region (in
            percent relative to entry BB of the function) to make partial
            inlining happen.
  
!      'max-tracked-strlens'
            Maximum number of strings for which strlen optimization pass
            will track string lengths.
  
!      'gcse-after-reload-partial-fraction'
            The threshold ratio for performing partial redundancy
            elimination after reload.
  
!      'gcse-after-reload-critical-fraction'
            The threshold ratio of critical edges execution count that
            permit performing redundancy elimination after reload.
  
!      'max-loop-header-insns'
            The maximum number of insns in loop header duplicated by the
            copy loop headers pass.
  
!      'vect-epilogues-nomask'
            Enable loop epilogue vectorization using smaller vector size.
  
!      'vect-partial-vector-usage'
            Controls when the loop vectorizer considers using partial
            vector loads and stores as an alternative to falling back to
            scalar code.  0 stops the vectorizer from ever using partial
--- 14448,14692 ----
            adjustment is applied for statements with memory operands as
            those are even more profitable so sink.
  
!      ‘max-stores-to-sink’
            The maximum number of conditional store pairs that can be
!           sunk.  Set to 0 if either vectorization (‘-ftree-vectorize’)
!           or if-conversion (‘-ftree-loop-if-convert’) is disabled.
  
!      ‘case-values-threshold’
            The smallest number of different values for which it is best
            to use a jump-table instead of a tree of conditional branches.
            If the value is 0, use the default for the machine.
  
!      ‘jump-table-max-growth-ratio-for-size’
            The maximum code size growth ratio when expanding into a jump
            table (in percent).  The parameter is used when optimizing for
            size.
  
!      ‘jump-table-max-growth-ratio-for-speed’
            The maximum code size growth ratio when expanding into a jump
            table (in percent).  The parameter is used when optimizing for
            speed.
  
!      ‘tree-reassoc-width’
            Set the maximum number of instructions executed in parallel in
            reassociated tree.  This parameter overrides target dependent
            heuristics used by default if has non zero value.
  
!      ‘sched-pressure-algorithm’
            Choose between the two available implementations of
!           ‘-fsched-pressure’.  Algorithm 1 is the original
            implementation and is the more likely to prevent instructions
            from being reordered.  Algorithm 2 was designed to be a
            compromise between the relatively conservative approach taken
            by algorithm 1 and the rather aggressive approach taken by the
            default scheduler.  It relies more heavily on having a regular
            register file and accurate register pressure classes.  See
!           ‘haifa-sched.cc’ in the GCC sources for more details.
  
            The default choice depends on the target.
  
!      ‘max-slsr-cand-scan’
            Set the maximum number of existing candidates that are
            considered when seeking a basis for a new straight-line
            strength reduction candidate.
  
!      ‘asan-globals’
            Enable buffer overflow detection for global objects.  This
            kind of protection is enabled by default if you are using
!           ‘-fsanitize=address’ option.  To disable global objects
!           protection use ‘--param asan-globals=0’.
  
!      ‘asan-stack’
            Enable buffer overflow detection for stack objects.  This kind
            of protection is enabled by default when using
!           ‘-fsanitize=address’.  To disable stack protection use
!           ‘--param asan-stack=0’ option.
  
!      ‘asan-instrument-reads’
            Enable buffer overflow detection for memory reads.  This kind
            of protection is enabled by default when using
!           ‘-fsanitize=address’.  To disable memory reads protection use
!           ‘--param asan-instrument-reads=0’.
  
!      ‘asan-instrument-writes’
            Enable buffer overflow detection for memory writes.  This kind
            of protection is enabled by default when using
!           ‘-fsanitize=address’.  To disable memory writes protection use
!           ‘--param asan-instrument-writes=0’ option.
  
!      ‘asan-memintrin’
            Enable detection for built-in functions.  This kind of
            protection is enabled by default when using
!           ‘-fsanitize=address’.  To disable built-in functions
!           protection use ‘--param asan-memintrin=0’.
  
!      ‘asan-use-after-return’
            Enable detection of use-after-return.  This kind of protection
!           is enabled by default when using the ‘-fsanitize=address’
!           option.  To disable it use ‘--param asan-use-after-return=0’.
  
            Note: By default the check is disabled at run time.  To enable
!           it, add ‘detect_stack_use_after_return=1’ to the environment
!           variable ‘ASAN_OPTIONS’.
  
!      ‘asan-instrumentation-with-call-threshold’
            If number of memory accesses in function being instrumented is
            greater or equal to this number, use callbacks instead of
!           inline checks.  E.g.  to disable inline code use ‘--param
!           asan-instrumentation-with-call-threshold=0’.
  
!      ‘asan-kernel-mem-intrinsic-prefix’
!           If nonzero, prefix calls to ‘memcpy’, ‘memset’ and ‘memmove’
!           with ‘__asan_’ or ‘__hwasan_’ for ‘-fsanitize=kernel-address’
!           or ‘-fsanitize=kernel-hwaddress’, respectively.
  
!      ‘hwasan-instrument-stack’
            Enable hwasan instrumentation of statically sized
            stack-allocated variables.  This kind of instrumentation is
!           enabled by default when using ‘-fsanitize=hwaddress’ and
!           disabled by default when using ‘-fsanitize=kernel-hwaddress’.
!           To disable stack instrumentation use ‘--param
!           hwasan-instrument-stack=0’, and to enable it use ‘--param
!           hwasan-instrument-stack=1’.
  
!      ‘hwasan-random-frame-tag’
            When using stack instrumentation, decide tags for stack
            variables using a deterministic sequence beginning at a random
            tag for each frame.  With this parameter unset tags are chosen
            using the same sequence but beginning from 1.  This is enabled
!           by default for ‘-fsanitize=hwaddress’ and unavailable for
!           ‘-fsanitize=kernel-hwaddress’.  To disable it use ‘--param
!           hwasan-random-frame-tag=0’.
  
!      ‘hwasan-instrument-allocas’
            Enable hwasan instrumentation of dynamically sized
            stack-allocated variables.  This kind of instrumentation is
!           enabled by default when using ‘-fsanitize=hwaddress’ and
!           disabled by default when using ‘-fsanitize=kernel-hwaddress’.
!           To disable instrumentation of such variables use ‘--param
!           hwasan-instrument-allocas=0’, and to enable it use ‘--param
!           hwasan-instrument-allocas=1’.
  
!      ‘hwasan-instrument-reads’
            Enable hwasan checks on memory reads.  Instrumentation of
!           reads is enabled by default for both ‘-fsanitize=hwaddress’
!           and ‘-fsanitize=kernel-hwaddress’.  To disable checking memory
!           reads use ‘--param hwasan-instrument-reads=0’.
  
!      ‘hwasan-instrument-writes’
            Enable hwasan checks on memory writes.  Instrumentation of
!           writes is enabled by default for both ‘-fsanitize=hwaddress’
!           and ‘-fsanitize=kernel-hwaddress’.  To disable checking memory
!           writes use ‘--param hwasan-instrument-writes=0’.
  
!      ‘hwasan-instrument-mem-intrinsics’
            Enable hwasan instrumentation of builtin functions.
            Instrumentation of these builtin functions is enabled by
!           default for both ‘-fsanitize=hwaddress’ and
!           ‘-fsanitize=kernel-hwaddress’.  To disable instrumentation of
!           builtin functions use ‘--param
!           hwasan-instrument-mem-intrinsics=0’.
  
!      ‘use-after-scope-direct-emission-threshold’
            If the size of a local variable in bytes is smaller or equal
            to this number, directly poison (or unpoison) shadow memory
            instead of using run-time callbacks.
  
!      ‘tsan-distinguish-volatile’
            Emit special instrumentation for accesses to volatiles.
  
!      ‘tsan-instrument-func-entry-exit’
            Emit instrumentation calls to __tsan_func_entry() and
            __tsan_func_exit().
  
!      ‘max-fsm-thread-path-insns’
            Maximum number of instructions to copy when duplicating blocks
            on a finite state automaton jump thread path.
  
!      ‘threader-debug’
            threader-debug=[none|all] Enables verbose dumping of the
            threader solver.
  
!      ‘parloops-chunk-size’
            Chunk size of omp schedule for loops parallelized by parloops.
  
!      ‘parloops-schedule’
            Schedule type of omp schedule for loops parallelized by
            parloops (static, dynamic, guided, auto, runtime).
  
!      ‘parloops-min-per-thread’
            The minimum number of iterations per thread of an innermost
            parallelized loop for which the parallelized variant is
            preferred over the single threaded one.  Note that for a
            parallelized loop nest the minimum number of iterations of the
            outermost loop per thread is two.
  
!      ‘max-ssa-name-query-depth’
            Maximum depth of recursion when querying properties of SSA
            names in things like fold routines.  One level of recursion
            corresponds to following a use-def chain.
  
!      ‘max-speculative-devirt-maydefs’
            The maximum number of may-defs we analyze when looking for a
            must-def specifying the dynamic type of an object that invokes
            a virtual call we may be able to devirtualize speculatively.
  
!      ‘evrp-sparse-threshold’
            Maximum number of basic blocks before EVRP uses a sparse
            cache.
  
!      ‘ranger-debug’
            Specifies the type of debug output to be issued for ranges.
  
!      ‘evrp-switch-limit’
            Specifies the maximum number of switch cases before EVRP
            ignores a switch.
  
!      ‘unroll-jam-min-percent’
            The minimum percentage of memory references that must be
            optimized away for the unroll-and-jam transformation to be
            considered profitable.
  
!      ‘unroll-jam-max-unroll’
            The maximum number of times the outer loop should be unrolled
            by the unroll-and-jam transformation.
  
!      ‘max-rtl-if-conversion-unpredictable-cost’
            Maximum permissible cost for the sequence that would be
            generated by the RTL if-conversion pass for a branch that is
            considered unpredictable.
  
!      ‘max-variable-expansions-in-unroller’
!           If ‘-fvariable-expansion-in-unroller’ is used, the maximum
            number of times that an individual variable will be expanded
            during loop unrolling.
  
!      ‘partial-inlining-entry-probability’
            Maximum probability of the entry BB of split region (in
            percent relative to entry BB of the function) to make partial
            inlining happen.
  
!      ‘max-tracked-strlens’
            Maximum number of strings for which strlen optimization pass
            will track string lengths.
  
!      ‘gcse-after-reload-partial-fraction’
            The threshold ratio for performing partial redundancy
            elimination after reload.
  
!      ‘gcse-after-reload-critical-fraction’
            The threshold ratio of critical edges execution count that
            permit performing redundancy elimination after reload.
  
!      ‘max-loop-header-insns’
            The maximum number of insns in loop header duplicated by the
            copy loop headers pass.
  
!      ‘vect-epilogues-nomask’
            Enable loop epilogue vectorization using smaller vector size.
  
!      ‘vect-partial-vector-usage’
            Controls when the loop vectorizer considers using partial
            vector loads and stores as an alternative to falling back to
            scalar code.  0 stops the vectorizer from ever using partial
*************** includes experimental options that may p
*** 14692,14873 ****
            loops.  The parameter only has an effect on targets that
            support partial vector loads and stores.
  
!      'vect-inner-loop-cost-factor'
            The maximum factor which the loop vectorizer applies to the
            cost of statements in an inner loop relative to the loop being
            vectorized.  The factor applied is the maximum of the
            estimated number of iterations of the inner loop and this
            parameter.  The default value of this parameter is 50.
  
!      'vect-induction-float'
            Enable loop vectorization of floating point inductions.
  
!      'avoid-fma-max-bits'
            Maximum number of bits for which we avoid creating FMAs.
  
!      'sms-loop-average-count-threshold'
            A threshold on the average loop count considered by the swing
            modulo scheduler.
  
!      'sms-dfa-history'
            The number of cycles the swing modulo scheduler considers when
            checking conflicts using DFA.
  
!      'graphite-allow-codegen-errors'
!           Whether codegen errors should be ICEs when '-fchecking'.
  
!      'sms-max-ii-factor'
            A factor for tuning the upper bound that swing modulo
            scheduler uses for scheduling a loop.
  
!      'lra-max-considered-reload-pseudos'
            The max number of reload pseudos which are considered during
            spilling a non-reload pseudo.
  
!      'max-pow-sqrt-depth'
            Maximum depth of sqrt chains to use when synthesizing
            exponentiation by a real constant.
  
!      'max-dse-active-local-stores'
            Maximum number of active local stores in RTL dead store
            elimination.
  
!      'asan-instrument-allocas'
            Enable asan allocas/VLAs protection.
  
!      'max-iterations-computation-cost'
            Bound on the cost of an expression to compute the number of
            iterations.
  
!      'max-isl-operations'
            Maximum number of isl operations, 0 means unlimited.
  
!      'graphite-max-arrays-per-scop'
            Maximum number of arrays per scop.
  
!      'max-vartrack-reverse-op-size'
            Max.  size of loc list for which reverse ops should be added.
  
!      'fsm-scale-path-stmts'
            Scale factor to apply to the number of statements in a
            threading path crossing a loop backedge when comparing to
!           '--param=max-jump-thread-duplication-stmts'.
  
!      'uninit-control-dep-attempts'
            Maximum number of nested calls to search for control
            dependencies during uninitialized variable analysis.
  
!      'uninit-max-chain-len'
            Maximum number of predicates anded for each predicate ored in
            the normalized predicate chain.
  
!      'uninit-max-num-chains'
            Maximum number of predicates ored in the normalized predicate
            chain.
  
!      'sched-autopref-queue-depth'
            Hardware autoprefetcher scheduler model control flag.  Number
            of lookahead cycles the model looks into; at ' ' only enable
            instruction sorting heuristic.
  
!      'loop-versioning-max-inner-insns'
            The maximum number of instructions that an inner loop can have
            before the loop versioning pass considers it too big to copy.
  
!      'loop-versioning-max-outer-insns'
            The maximum number of instructions that an outer loop can have
            before the loop versioning pass considers it too big to copy,
            discounting any instructions in inner loops that directly
            benefit from versioning.
  
!      'ssa-name-def-chain-limit'
            The maximum number of SSA_NAME assignments to follow in
            determining a property of a variable such as its value.  This
            limits the number of iterations or recursive calls GCC
            performs when optimizing certain statements or when
            determining their validity prior to issuing diagnostics.
  
!      'store-merging-max-size'
            Maximum size of a single store merging region in bytes.
  
!      'hash-table-verification-limit'
            The number of elements for which hash table verification is
            done for each searched element.
  
!      'max-find-base-term-values'
            Maximum number of VALUEs handled during a single
            find_base_term call.
  
!      'analyzer-max-enodes-per-program-point'
            The maximum number of exploded nodes per program point within
            the analyzer, before terminating analysis of that point.
  
!      'analyzer-max-constraints'
            The maximum number of constraints per state.
  
!      'analyzer-min-snodes-for-call-summary'
            The minimum number of supernodes within a function for the
            analyzer to consider summarizing its effects at call sites.
  
!      'analyzer-max-enodes-for-full-dump'
            The maximum depth of exploded nodes that should appear in a
            dot dump before switching to a less verbose format.
  
!      'analyzer-max-recursion-depth'
            The maximum number of times a callsite can appear in a call
            stack within the analyzer, before terminating analysis of a
            call that would recurse deeper.
  
!      'analyzer-max-svalue-depth'
            The maximum depth of a symbolic value, before approximating
            the value as unknown.
  
!      'analyzer-max-infeasible-edges'
            The maximum number of infeasible edges to reject before
            declaring a diagnostic as infeasible.
  
!      'gimple-fe-computed-hot-bb-threshold'
            The number of executions of a basic block which is considered
            hot.  The parameter is used only in GIMPLE FE.
  
!      'analyzer-bb-explosion-factor'
            The maximum number of 'after supernode' exploded nodes within
            the analyzer per supernode, before terminating analysis.
  
!      'ranger-logical-depth'
            Maximum depth of logical expression evaluation ranger will
            look through when evaluating outgoing edge ranges.
  
!      'ranger-recompute-depth'
            Maximum depth of instruction chains to consider for
            recomputation in the outgoing range calculator.
  
!      'relation-block-limit'
            Maximum number of relations the oracle will register in a
            basic block.
  
!      'min-pagesize'
            Minimum page size for warning purposes.
  
!      'openacc-kernels'
            Specify mode of OpenACC 'kernels' constructs handling.  With
!           '--param=openacc-kernels=decompose', OpenACC 'kernels'
            constructs are decomposed into parts, a sequence of compute
            constructs, each then handled individually.  This is work in
!           progress.  With '--param=openacc-kernels=parloops', OpenACC
!           'kernels' constructs are handled by the 'parloops' pass, en
            bloc.  This is the current default.
  
!      'openacc-privatization'
!           Control whether the '-fopt-info-omp-note' and applicable
!           '-fdump-tree-*-details' options emit OpenACC privatization
!           diagnostics.  With '--param=openacc-privatization=quiet',
            don't diagnose.  This is the current default.  With
!           '--param=openacc-privatization=noisy', do diagnose.
  
       The following choices of NAME are available on AArch64 targets:
  
!      'aarch64-sve-compare-costs'
            When vectorizing for SVE, consider using "unpacked" vectors
            for smaller elements and use the cost model to pick the
            cheapest approach.  Also use the cost model to choose between
--- 14696,14877 ----
            loops.  The parameter only has an effect on targets that
            support partial vector loads and stores.
  
!      ‘vect-inner-loop-cost-factor’
            The maximum factor which the loop vectorizer applies to the
            cost of statements in an inner loop relative to the loop being
            vectorized.  The factor applied is the maximum of the
            estimated number of iterations of the inner loop and this
            parameter.  The default value of this parameter is 50.
  
!      ‘vect-induction-float’
            Enable loop vectorization of floating point inductions.
  
!      ‘avoid-fma-max-bits’
            Maximum number of bits for which we avoid creating FMAs.
  
!      ‘sms-loop-average-count-threshold’
            A threshold on the average loop count considered by the swing
            modulo scheduler.
  
!      ‘sms-dfa-history’
            The number of cycles the swing modulo scheduler considers when
            checking conflicts using DFA.
  
!      ‘graphite-allow-codegen-errors’
!           Whether codegen errors should be ICEs when ‘-fchecking’.
  
!      ‘sms-max-ii-factor’
            A factor for tuning the upper bound that swing modulo
            scheduler uses for scheduling a loop.
  
!      ‘lra-max-considered-reload-pseudos’
            The max number of reload pseudos which are considered during
            spilling a non-reload pseudo.
  
!      ‘max-pow-sqrt-depth’
            Maximum depth of sqrt chains to use when synthesizing
            exponentiation by a real constant.
  
!      ‘max-dse-active-local-stores’
            Maximum number of active local stores in RTL dead store
            elimination.
  
!      ‘asan-instrument-allocas’
            Enable asan allocas/VLAs protection.
  
!      ‘max-iterations-computation-cost’
            Bound on the cost of an expression to compute the number of
            iterations.
  
!      ‘max-isl-operations’
            Maximum number of isl operations, 0 means unlimited.
  
!      ‘graphite-max-arrays-per-scop’
            Maximum number of arrays per scop.
  
!      ‘max-vartrack-reverse-op-size’
            Max.  size of loc list for which reverse ops should be added.
  
!      ‘fsm-scale-path-stmts’
            Scale factor to apply to the number of statements in a
            threading path crossing a loop backedge when comparing to
!           ‘--param=max-jump-thread-duplication-stmts’.
  
!      ‘uninit-control-dep-attempts’
            Maximum number of nested calls to search for control
            dependencies during uninitialized variable analysis.
  
!      ‘uninit-max-chain-len’
            Maximum number of predicates anded for each predicate ored in
            the normalized predicate chain.
  
!      ‘uninit-max-num-chains’
            Maximum number of predicates ored in the normalized predicate
            chain.
  
!      ‘sched-autopref-queue-depth’
            Hardware autoprefetcher scheduler model control flag.  Number
            of lookahead cycles the model looks into; at ' ' only enable
            instruction sorting heuristic.
  
!      ‘loop-versioning-max-inner-insns’
            The maximum number of instructions that an inner loop can have
            before the loop versioning pass considers it too big to copy.
  
!      ‘loop-versioning-max-outer-insns’
            The maximum number of instructions that an outer loop can have
            before the loop versioning pass considers it too big to copy,
            discounting any instructions in inner loops that directly
            benefit from versioning.
  
!      ‘ssa-name-def-chain-limit’
            The maximum number of SSA_NAME assignments to follow in
            determining a property of a variable such as its value.  This
            limits the number of iterations or recursive calls GCC
            performs when optimizing certain statements or when
            determining their validity prior to issuing diagnostics.
  
!      ‘store-merging-max-size’
            Maximum size of a single store merging region in bytes.
  
!      ‘hash-table-verification-limit’
            The number of elements for which hash table verification is
            done for each searched element.
  
!      ‘max-find-base-term-values’
            Maximum number of VALUEs handled during a single
            find_base_term call.
  
!      ‘analyzer-max-enodes-per-program-point’
            The maximum number of exploded nodes per program point within
            the analyzer, before terminating analysis of that point.
  
!      ‘analyzer-max-constraints’
            The maximum number of constraints per state.
  
!      ‘analyzer-min-snodes-for-call-summary’
            The minimum number of supernodes within a function for the
            analyzer to consider summarizing its effects at call sites.
  
!      ‘analyzer-max-enodes-for-full-dump’
            The maximum depth of exploded nodes that should appear in a
            dot dump before switching to a less verbose format.
  
!      ‘analyzer-max-recursion-depth’
            The maximum number of times a callsite can appear in a call
            stack within the analyzer, before terminating analysis of a
            call that would recurse deeper.
  
!      ‘analyzer-max-svalue-depth’
            The maximum depth of a symbolic value, before approximating
            the value as unknown.
  
!      ‘analyzer-max-infeasible-edges’
            The maximum number of infeasible edges to reject before
            declaring a diagnostic as infeasible.
  
!      ‘gimple-fe-computed-hot-bb-threshold’
            The number of executions of a basic block which is considered
            hot.  The parameter is used only in GIMPLE FE.
  
!      ‘analyzer-bb-explosion-factor’
            The maximum number of 'after supernode' exploded nodes within
            the analyzer per supernode, before terminating analysis.
  
!      ‘ranger-logical-depth’
            Maximum depth of logical expression evaluation ranger will
            look through when evaluating outgoing edge ranges.
  
!      ‘ranger-recompute-depth’
            Maximum depth of instruction chains to consider for
            recomputation in the outgoing range calculator.
  
!      ‘relation-block-limit’
            Maximum number of relations the oracle will register in a
            basic block.
  
!      ‘min-pagesize’
            Minimum page size for warning purposes.
  
!      ‘openacc-kernels’
            Specify mode of OpenACC 'kernels' constructs handling.  With
!           ‘--param=openacc-kernels=decompose’, OpenACC 'kernels'
            constructs are decomposed into parts, a sequence of compute
            constructs, each then handled individually.  This is work in
!           progress.  With ‘--param=openacc-kernels=parloops’, OpenACC
!           'kernels' constructs are handled by the ‘parloops’ pass, en
            bloc.  This is the current default.
  
!      ‘openacc-privatization’
!           Control whether the ‘-fopt-info-omp-note’ and applicable
!           ‘-fdump-tree-*-details’ options emit OpenACC privatization
!           diagnostics.  With ‘--param=openacc-privatization=quiet’,
            don't diagnose.  This is the current default.  With
!           ‘--param=openacc-privatization=noisy’, do diagnose.
  
       The following choices of NAME are available on AArch64 targets:
  
!      ‘aarch64-sve-compare-costs’
            When vectorizing for SVE, consider using "unpacked" vectors
            for smaller elements and use the cost model to pick the
            cheapest approach.  Also use the cost model to choose between
*************** includes experimental options that may p
*** 14877,14912 ****
            larger containers and accessing elements with extending loads
            and truncating stores.
  
!      'aarch64-float-recp-precision'
            The number of Newton iterations for calculating the reciprocal
            for float type.  The precision of division is proportional to
            this param when division approximation is enabled.  The
            default value is 1.
  
!      'aarch64-double-recp-precision'
            The number of Newton iterations for calculating the reciprocal
            for double type.  The precision of division is propotional to
            this param when division approximation is enabled.  The
            default value is 2.
  
!      'aarch64-autovec-preference'
            Force an ISA selection strategy for auto-vectorization.
            Accepts values from 0 to 4, inclusive.
!           '0'
                 Use the default heuristics.
!           '1'
                 Use only Advanced SIMD for auto-vectorization.
!           '2'
                 Use only SVE for auto-vectorization.
!           '3'
                 Use both Advanced SIMD and SVE. Prefer Advanced SIMD when
                 the costs are deemed equal.
!           '4'
                 Use both Advanced SIMD and SVE. Prefer SVE when the costs
                 are deemed equal.
            The default value is 0.
  
!      'aarch64-loop-vect-issue-rate-niters'
            The tuning for some AArch64 CPUs tries to take both latencies
            and issue rates into account when deciding whether a loop
            should be vectorized using SVE, vectorized using Advanced
--- 14881,14916 ----
            larger containers and accessing elements with extending loads
            and truncating stores.
  
!      ‘aarch64-float-recp-precision’
            The number of Newton iterations for calculating the reciprocal
            for float type.  The precision of division is proportional to
            this param when division approximation is enabled.  The
            default value is 1.
  
!      ‘aarch64-double-recp-precision’
            The number of Newton iterations for calculating the reciprocal
            for double type.  The precision of division is propotional to
            this param when division approximation is enabled.  The
            default value is 2.
  
!      ‘aarch64-autovec-preference’
            Force an ISA selection strategy for auto-vectorization.
            Accepts values from 0 to 4, inclusive.
!           ‘0’
                 Use the default heuristics.
!           ‘1’
                 Use only Advanced SIMD for auto-vectorization.
!           ‘2’
                 Use only SVE for auto-vectorization.
!           ‘3’
                 Use both Advanced SIMD and SVE. Prefer Advanced SIMD when
                 the costs are deemed equal.
!           ‘4’
                 Use both Advanced SIMD and SVE. Prefer SVE when the costs
                 are deemed equal.
            The default value is 0.
  
!      ‘aarch64-loop-vect-issue-rate-niters’
            The tuning for some AArch64 CPUs tries to take both latencies
            and issue rates into account when deciding whether a loop
            should be vectorized using SVE, vectorized using Advanced
*************** includes experimental options that may p
*** 14914,14920 ****
            N, GCC will not use this heuristic for loops that are known to
            execute in fewer than N Advanced SIMD iterations.
  
!      'aarch64-vect-unroll-limit'
            The vectorizer will use available tuning information to
            determine whether it would be beneficial to unroll the main
            vectorized loop and by how much.  This parameter set's the
--- 14918,14924 ----
            N, GCC will not use this heuristic for loops that are known to
            execute in fewer than N Advanced SIMD iterations.
  
!      ‘aarch64-vect-unroll-limit’
            The vectorizer will use available tuning information to
            determine whether it would be beneficial to unroll the main
            vectorized loop and by how much.  This parameter set's the
*************** includes experimental options that may p
*** 14924,14934 ****
       The following choices of NAME are available on i386 and x86_64
       targets:
  
!      'x86-stlf-window-ninsns'
            Instructions number above which STFL stall penalty can be
            compensated.
  
!      'x86-stv-max-visits'
            The maximum number of use and def visits when discovering a
            STV chain before the discovery is aborted.
  
--- 14928,14938 ----
       The following choices of NAME are available on i386 and x86_64
       targets:
  
!      ‘x86-stlf-window-ninsns’
            Instructions number above which STFL stall penalty can be
            compensated.
  
!      ‘x86-stv-max-visits’
            The maximum number of use and def visits when discovering a
            STV chain before the discovery is aborted.
  
*************** hijacking.  There is also a general hook
*** 14950,14968 ****
  other forms of tracing or function-level instrumentation for debug or
  program analysis purposes.
  
! '-p'
! '-pg'
       Generate extra code to write profile information suitable for the
!      analysis program 'prof' (for '-p') or 'gprof' (for '-pg').  You
       must use this option when compiling the source files you want data
       about, and you must also use it when linking.
  
!      You can use the function attribute 'no_instrument_function' to
       suppress profiling of individual functions when compiling with
       these options.  *Note Common Function Attributes::.
  
! '-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.  On targets
       that support constructors with priority support, profiling properly
--- 14954,14972 ----
  other forms of tracing or function-level instrumentation for debug or
  program analysis purposes.
  
! ‘-p’
! ‘-pg’
       Generate extra code to write profile information suitable for the
!      analysis program ‘prof’ (for ‘-p’) or ‘gprof’ (for ‘-pg’).  You
       must use this option when compiling the source files you want data
       about, and you must also use it when linking.
  
!      You can use the function attribute ‘no_instrument_function’ to
       suppress profiling of individual functions when compiling with
       these options.  *Note Common Function Attributes::.
  
! ‘-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.  On targets
       that support constructors with priority support, profiling properly
*************** program analysis purposes.
*** 14971,15035 ****
       variable.
  
       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 that if a command line directly links source files, the
       corresponding .GCDA files will be prefixed with the unsuffixed name
!      of the output file.  E.g.  'gcc a.c b.c -o binary' would generate
!      'binary-a.gcda' and 'binary-b.gcda' files.
  
       *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.
  
!         * Compile the source files additionally with
!           '-fprofile-abs-path' to create absolute path names in the
!           '.gcno' files.  This allows 'gcov' to find the correct sources
            in projects where compilations occur with different working
            directories.
  
!         * 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.  Unless a strict ISO C dialect
!           option is in effect, 'fork' calls are detected and correctly
            handled without double counting.
  
            Moreover, an object file can be recompiled multiple times and
!           the corresponding '.gcda' file merges as long as the source
            file and the compiler options are unchanged.
  
!         * 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
--- 14975,15039 ----
       variable.
  
       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 that if a command line directly links source files, the
       corresponding .GCDA files will be prefixed with the unsuffixed name
!      of the output file.  E.g.  ‘gcc a.c b.c -o binary’ would generate
!      ‘binary-a.gcda’ and ‘binary-b.gcda’ files.
  
       *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.
  
!         • Compile the source files additionally with
!           ‘-fprofile-abs-path’ to create absolute path names in the
!           ‘.gcno’ files.  This allows ‘gcov’ to find the correct sources
            in projects where compilations occur with different working
            directories.
  
!         • 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.  Unless a strict ISO C dialect
!           option is in effect, ‘fork’ calls are detected and correctly
            handled without double counting.
  
            Moreover, an object file can be recompiled multiple times and
!           the corresponding ‘.gcda’ file merges as long as the source
            file and the compiler options are unchanged.
  
!         • 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
*************** program analysis purposes.
*** 15038,15108 ****
       block; otherwise, a new basic block must be created to hold the
       instrumentation code.
  
! '-ftest-coverage'
!      Produce a notes file that the 'gcov' code-coverage utility (*note
!      'gcov'--a Test Coverage Program: Gcov.) can use to show program
!      coverage.  Each source file's note file is called 'AUXNAME.gcno'.
!      Refer to the '-fprofile-arcs' option above for a description of
       AUXNAME and instructions on how to generate test coverage data.
       Coverage data matches the source files more closely if you do not
       optimize.
  
! '-fprofile-abs-path'
       Automatically convert relative source file names to absolute path
!      names in the '.gcno' files.  This allows 'gcov' to find the correct
       sources in projects where compilations occur with different working
       directories.
  
! '-fprofile-dir=PATH'
  
       Set the directory to search for the profile data files in to PATH.
       This option affects only the profile data generated by
!      '-fprofile-generate', '-ftest-coverage', '-fprofile-arcs' and used
!      by '-fprofile-use' and '-fbranch-probabilities' and its related
       options.  Both absolute and relative paths can be used.  By
       default, GCC uses the current directory as PATH, thus the profile
       data file appears in the same directory as the object file.  In
       order to prevent the file name clashing, if the object file name is
       not an absolute path, we mangle the absolute path of the
!      'SOURCENAME.gcda' file and use it as the file name of a '.gcda'
!      file.  See details about the file naming in '-fprofile-arcs'.  See
!      similar option '-fprofile-note'.
  
       When an executable is run in a massive parallel environment, it is
       recommended to save profile to different folders.  That can be done
       with variables in PATH that are exported during run-time:
  
!      '%p'
            process ID.
  
!      '%q{VAR}'
            value of environment variable VAR
  
! '-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', '-finline-functions', and '-fipa-bit-cp'.
  
       If PATH is specified, GCC looks at the PATH to find the profile
!      feedback data files.  See '-fprofile-dir'.
  
       To optimize the program based on the collected profile information,
!      use '-fprofile-use'.  *Note Optimize Options::, for more
       information.
  
! '-fprofile-info-section'
! '-fprofile-info-section=NAME'
  
       Register the profile information in the specified section instead
       of using a constructor/destructor.  The section name is NAME if it
!      is specified, otherwise the section name defaults to '.gcov_info'.
!      A pointer to the profile information generated by '-fprofile-arcs'
       is placed in the specified section for each translation unit.  This
       option disables the profile information registration through a
       constructor and it disables the profile information processing
--- 15042,15112 ----
       block; otherwise, a new basic block must be created to hold the
       instrumentation code.
  
! ‘-ftest-coverage’
!      Produce a notes file that the ‘gcov’ code-coverage utility (*note
!      ‘gcov’--a Test Coverage Program: Gcov.) can use to show program
!      coverage.  Each source file's note file is called ‘AUXNAME.gcno’.
!      Refer to the ‘-fprofile-arcs’ option above for a description of
       AUXNAME and instructions on how to generate test coverage data.
       Coverage data matches the source files more closely if you do not
       optimize.
  
! ‘-fprofile-abs-path’
       Automatically convert relative source file names to absolute path
!      names in the ‘.gcno’ files.  This allows ‘gcov’ to find the correct
       sources in projects where compilations occur with different working
       directories.
  
! ‘-fprofile-dir=PATH’
  
       Set the directory to search for the profile data files in to PATH.
       This option affects only the profile data generated by
!      ‘-fprofile-generate’, ‘-ftest-coverage’, ‘-fprofile-arcs’ and used
!      by ‘-fprofile-use’ and ‘-fbranch-probabilities’ and its related
       options.  Both absolute and relative paths can be used.  By
       default, GCC uses the current directory as PATH, thus the profile
       data file appears in the same directory as the object file.  In
       order to prevent the file name clashing, if the object file name is
       not an absolute path, we mangle the absolute path of the
!      ‘SOURCENAME.gcda’ file and use it as the file name of a ‘.gcda’
!      file.  See details about the file naming in ‘-fprofile-arcs’.  See
!      similar option ‘-fprofile-note’.
  
       When an executable is run in a massive parallel environment, it is
       recommended to save profile to different folders.  That can be done
       with variables in PATH that are exported during run-time:
  
!      ‘%p’
            process ID.
  
!      ‘%q{VAR}’
            value of environment variable VAR
  
! ‘-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’, ‘-finline-functions’, and ‘-fipa-bit-cp’.
  
       If PATH is specified, GCC looks at the PATH to find the profile
!      feedback data files.  See ‘-fprofile-dir’.
  
       To optimize the program based on the collected profile information,
!      use ‘-fprofile-use’.  *Note Optimize Options::, for more
       information.
  
! ‘-fprofile-info-section’
! ‘-fprofile-info-section=NAME’
  
       Register the profile information in the specified section instead
       of using a constructor/destructor.  The section name is NAME if it
!      is specified, otherwise the section name defaults to ‘.gcov_info’.
!      A pointer to the profile information generated by ‘-fprofile-arcs’
       is placed in the specified section for each translation unit.  This
       option disables the profile information registration through a
       constructor and it disables the profile information processing
*************** program analysis purposes.
*** 15179,15222 ****
              return 0;
            }
  
!      The 'merge-stream' subcommand of 'gcov-tool' may be used to
       deserialize the data stream generated by the
!      '__gcov_filename_to_gcfn' and '__gcov_info_to_gcda' functions and
!      merge the profile information into '.gcda' files on the host
       filesystem.
  
! '-fprofile-note=PATH'
  
!      If PATH is specified, GCC saves '.gcno' file into PATH location.
!      If you combine the option with multiple source files, the '.gcno'
       file will be overwritten.
  
! '-fprofile-prefix-path=PATH'
  
       This option can be used in combination with
!      'profile-generate='PROFILE_DIR and 'profile-use='PROFILE_DIR to
       inform GCC where is the base directory of built source tree.  By
       default PROFILE_DIR will contain files with mangled absolute paths
       of all object files in the built project.  This is not desirable
       when directory used to build the instrumented binary differs from
       the directory used to build the binary optimized with profile
       feedback because the profile data will not be found during the
!      optimized build.  In such setups '-fprofile-prefix-path='PATH with
       PATH pointing to the base directory of the build can be used to
       strip the irrelevant part of the path and keep all file names
       relative to the main build directory.
  
! '-fprofile-prefix-map=OLD=NEW'
!      When compiling files residing in directory 'OLD', record profiling
!      information (with '--coverage') describing them as if the files
!      resided in directory 'NEW' instead.  See also '-ffile-prefix-map'
!      and '-fcanon-prefix-map'.
  
! '-fprofile-update=METHOD'
  
       Alter the update method for an application instrumented for profile
       feedback based optimization.  The METHOD argument should be one of
!      'single', 'atomic' or 'prefer-atomic'.  The first one is useful for
       single-threaded applications, while the second one prevents profile
       corruption by emitting thread-safe code.
  
--- 15183,15226 ----
              return 0;
            }
  
!      The ‘merge-stream’ subcommand of ‘gcov-tool’ may be used to
       deserialize the data stream generated by the
!      ‘__gcov_filename_to_gcfn’ and ‘__gcov_info_to_gcda’ functions and
!      merge the profile information into ‘.gcda’ files on the host
       filesystem.
  
! ‘-fprofile-note=PATH’
  
!      If PATH is specified, GCC saves ‘.gcno’ file into PATH location.
!      If you combine the option with multiple source files, the ‘.gcno’
       file will be overwritten.
  
! ‘-fprofile-prefix-path=PATH’
  
       This option can be used in combination with
!      ‘profile-generate=’PROFILE_DIR and ‘profile-use=’PROFILE_DIR to
       inform GCC where is the base directory of built source tree.  By
       default PROFILE_DIR will contain files with mangled absolute paths
       of all object files in the built project.  This is not desirable
       when directory used to build the instrumented binary differs from
       the directory used to build the binary optimized with profile
       feedback because the profile data will not be found during the
!      optimized build.  In such setups ‘-fprofile-prefix-path=’PATH with
       PATH pointing to the base directory of the build can be used to
       strip the irrelevant part of the path and keep all file names
       relative to the main build directory.
  
! ‘-fprofile-prefix-map=OLD=NEW’
!      When compiling files residing in directory ‘OLD’, record profiling
!      information (with ‘--coverage’) describing them as if the files
!      resided in directory ‘NEW’ instead.  See also ‘-ffile-prefix-map’
!      and ‘-fcanon-prefix-map’.
  
! ‘-fprofile-update=METHOD’
  
       Alter the update method for an application instrumented for profile
       feedback based optimization.  The METHOD argument should be one of
!      ‘single’, ‘atomic’ or ‘prefer-atomic’.  The first one is useful for
       single-threaded applications, while the second one prevents profile
       corruption by emitting thread-safe code.
  
*************** program analysis purposes.
*** 15224,15362 ****
       (or creates an detached thread), a profile file can be still
       corrupted.
  
!      Using 'prefer-atomic' would be transformed either to 'atomic', when
!      supported by a target, or to 'single' otherwise.  The GCC driver
!      automatically selects 'prefer-atomic' when '-pthread' is present in
       the command line.
  
! '-fprofile-filter-files=REGEX'
  
       Instrument only functions from files whose name matches any of the
       regular expressions (separated by semi-colons).
  
!      For example, '-fprofile-filter-files=main\.c;module.*\.c' will
!      instrument only 'main.c' and all C files starting with 'module'.
  
! '-fprofile-exclude-files=REGEX'
  
       Instrument only functions from files whose name does not match any
       of the regular expressions (separated by semi-colons).
  
!      For example, '-fprofile-exclude-files=/usr/.*' will prevent
!      instrumentation of all files that are located in the '/usr/'
       folder.
  
! '-fprofile-reproducible=[multithreaded|parallel-runs|serial]'
       Control level of reproducibility of profile gathered by
!      '-fprofile-generate'.  This makes it possible to rebuild program
       with same outcome which is useful, for example, for distribution
       packages.
  
!      With '-fprofile-reproducible=serial' the profile gathered by
!      '-fprofile-generate' is reproducible provided the trained program
       behaves the same at each invocation of the train run, it is not
       multi-threaded and profile data streaming is always done in the
       same order.  Note that profile streaming happens at the end of
!      program run but also before 'fork' function is invoked.
  
       Note that it is quite common that execution counts of some part of
       programs depends, for example, on length of temporary file names or
       memory space randomization (that may affect hash-table collision
       rate).  Such non-reproducible part of programs may be annotated by
!      'no_instrument_function' function attribute.  'gcov-dump' with '-l'
       can be used to dump gathered data and verify that they are indeed
       reproducible.
  
!      With '-fprofile-reproducible=parallel-runs' collected profile stays
       reproducible regardless the order of streaming of the data into
       gcda files.  This setting makes it possible to run multiple
!      instances of instrumented program in parallel (such as with 'make
!      -j').  This reduces quality of gathered data, in particular of
       indirect call profiling.
  
! '-fsanitize=address'
       Enable AddressSanitizer, a fast memory error detector.  Memory
       access instructions are instrumented to detect out-of-bounds and
       use-after-free bugs.  The option enables
!      '-fsanitize-address-use-after-scope'.  See
        for
       more details.  The run-time behavior can be influenced using the
!      'ASAN_OPTIONS' environment variable.  When set to 'help=1', the
       available options are shown at startup of the instrumented program.
       See
       
       for a list of supported options.  The option cannot be combined
!      with '-fsanitize=thread' or '-fsanitize=hwaddress'.  Note that the
!      only targets '-fsanitize=hwaddress' is currently supported on are
!      x86-64 (only with '-mlam=u48' or '-mlam=u57' options) and AArch64,
       in both cases only in ABIs with 64-bit pointers.
  
       To get more accurate stack traces, it is possible to use options
!      such as '-O0', '-O1', or '-Og' (which, for instance, prevent most
!      function inlining), '-fno-optimize-sibling-calls' (which prevents
       optimizing sibling and tail recursive calls; this option is
!      implicit for '-O0', '-O1', or '-Og'), or '-fno-ipa-icf' (which
       disables Identical Code Folding for functions).  Since multiple
       runs of the program may yield backtraces with different addresses
       due to ASLR (Address Space Layout Randomization), it may be
       desirable to turn ASLR off.  On Linux, this can be achieved with
!      'setarch `uname -m` -R ./prog'.
  
! '-fsanitize=kernel-address'
       Enable AddressSanitizer for Linux kernel.  See
        for more details.
  
! '-fsanitize=hwaddress'
       Enable Hardware-assisted AddressSanitizer, which uses a hardware
       ability to ignore the top byte of a pointer to allow the detection
       of memory errors with a low memory overhead.  Memory access
       instructions are instrumented to detect out-of-bounds and
       use-after-free bugs.  The option enables
!      '-fsanitize-address-use-after-scope'.  See
       
       for more details.  The run-time behavior can be influenced using
!      the 'HWASAN_OPTIONS' environment variable.  When set to 'help=1',
       the available options are shown at startup of the instrumented
!      program.  The option cannot be combined with '-fsanitize=thread' or
!      '-fsanitize=address', and is currently only available on AArch64.
  
! '-fsanitize=kernel-hwaddress'
       Enable Hardware-assisted AddressSanitizer for compilation of the
!      Linux kernel.  Similar to '-fsanitize=kernel-address' but using an
       alternate instrumentation method, and similar to
!      '-fsanitize=hwaddress' but with instrumentation differences
       necessary for compiling the Linux kernel.  These differences are to
       avoid hwasan library initialization calls and to account for the
       stack pointer having a different value in its top byte.
  
       _Note:_ This option has different defaults to the
!      '-fsanitize=hwaddress'.  Instrumenting the stack and alloca calls
       are not on by default but are still possible by specifying the
!      command-line options '--param hwasan-instrument-stack=1' and
!      '--param hwasan-instrument-allocas=1' respectively.  Using a random
       frame tag is not implemented for kernel instrumentation.
  
! '-fsanitize=pointer-compare'
       Instrument comparison operation (<, <=, >, >=) with pointer
       operands.  The option must be combined with either
!      '-fsanitize=kernel-address' or '-fsanitize=address' The option
!      cannot be combined with '-fsanitize=thread'.  Note: By default the
       check is disabled at run time.  To enable it, add
!      'detect_invalid_pointer_pairs=2' to the environment variable
!      'ASAN_OPTIONS'.  Using 'detect_invalid_pointer_pairs=1' detects
       invalid operation only when both pointers are non-null.
  
! '-fsanitize=pointer-subtract'
       Instrument subtraction with pointer operands.  The option must be
!      combined with either '-fsanitize=kernel-address' or
!      '-fsanitize=address' The option cannot be combined with
!      '-fsanitize=thread'.  Note: By default the check is disabled at run
!      time.  To enable it, add 'detect_invalid_pointer_pairs=2' to the
!      environment variable 'ASAN_OPTIONS'.  Using
!      'detect_invalid_pointer_pairs=1' detects invalid operation only
       when both pointers are non-null.
  
! '-fsanitize=shadow-call-stack'
       Enable ShadowCallStack, a security enhancement mechanism used to
       protect programs against return address overwrites (e.g.  stack
       buffer overflows.)  It works by saving a function's return address
--- 15228,15366 ----
       (or creates an detached thread), a profile file can be still
       corrupted.
  
!      Using ‘prefer-atomic’ would be transformed either to ‘atomic’, when
!      supported by a target, or to ‘single’ otherwise.  The GCC driver
!      automatically selects ‘prefer-atomic’ when ‘-pthread’ is present in
       the command line.
  
! ‘-fprofile-filter-files=REGEX’
  
       Instrument only functions from files whose name matches any of the
       regular expressions (separated by semi-colons).
  
!      For example, ‘-fprofile-filter-files=main\.c;module.*\.c’ will
!      instrument only ‘main.c’ and all C files starting with 'module'.
  
! ‘-fprofile-exclude-files=REGEX’
  
       Instrument only functions from files whose name does not match any
       of the regular expressions (separated by semi-colons).
  
!      For example, ‘-fprofile-exclude-files=/usr/.*’ will prevent
!      instrumentation of all files that are located in the ‘/usr/’
       folder.
  
! ‘-fprofile-reproducible=[multithreaded|parallel-runs|serial]’
       Control level of reproducibility of profile gathered by
!      ‘-fprofile-generate’.  This makes it possible to rebuild program
       with same outcome which is useful, for example, for distribution
       packages.
  
!      With ‘-fprofile-reproducible=serial’ the profile gathered by
!      ‘-fprofile-generate’ is reproducible provided the trained program
       behaves the same at each invocation of the train run, it is not
       multi-threaded and profile data streaming is always done in the
       same order.  Note that profile streaming happens at the end of
!      program run but also before ‘fork’ function is invoked.
  
       Note that it is quite common that execution counts of some part of
       programs depends, for example, on length of temporary file names or
       memory space randomization (that may affect hash-table collision
       rate).  Such non-reproducible part of programs may be annotated by
!      ‘no_instrument_function’ function attribute.  ‘gcov-dump’ with ‘-l’
       can be used to dump gathered data and verify that they are indeed
       reproducible.
  
!      With ‘-fprofile-reproducible=parallel-runs’ collected profile stays
       reproducible regardless the order of streaming of the data into
       gcda files.  This setting makes it possible to run multiple
!      instances of instrumented program in parallel (such as with ‘make
!      -j’).  This reduces quality of gathered data, in particular of
       indirect call profiling.
  
! ‘-fsanitize=address’
       Enable AddressSanitizer, a fast memory error detector.  Memory
       access instructions are instrumented to detect out-of-bounds and
       use-after-free bugs.  The option enables
!      ‘-fsanitize-address-use-after-scope’.  See
        for
       more details.  The run-time behavior can be influenced using the
!      ‘ASAN_OPTIONS’ environment variable.  When set to ‘help=1’, the
       available options are shown at startup of the instrumented program.
       See
       
       for a list of supported options.  The option cannot be combined
!      with ‘-fsanitize=thread’ or ‘-fsanitize=hwaddress’.  Note that the
!      only targets ‘-fsanitize=hwaddress’ is currently supported on are
!      x86-64 (only with ‘-mlam=u48’ or ‘-mlam=u57’ options) and AArch64,
       in both cases only in ABIs with 64-bit pointers.
  
       To get more accurate stack traces, it is possible to use options
!      such as ‘-O0’, ‘-O1’, or ‘-Og’ (which, for instance, prevent most
!      function inlining), ‘-fno-optimize-sibling-calls’ (which prevents
       optimizing sibling and tail recursive calls; this option is
!      implicit for ‘-O0’, ‘-O1’, or ‘-Og’), or ‘-fno-ipa-icf’ (which
       disables Identical Code Folding for functions).  Since multiple
       runs of the program may yield backtraces with different addresses
       due to ASLR (Address Space Layout Randomization), it may be
       desirable to turn ASLR off.  On Linux, this can be achieved with
!      ‘setarch `uname -m` -R ./prog’.
  
! ‘-fsanitize=kernel-address’
       Enable AddressSanitizer for Linux kernel.  See
        for more details.
  
! ‘-fsanitize=hwaddress’
       Enable Hardware-assisted AddressSanitizer, which uses a hardware
       ability to ignore the top byte of a pointer to allow the detection
       of memory errors with a low memory overhead.  Memory access
       instructions are instrumented to detect out-of-bounds and
       use-after-free bugs.  The option enables
!      ‘-fsanitize-address-use-after-scope’.  See
       
       for more details.  The run-time behavior can be influenced using
!      the ‘HWASAN_OPTIONS’ environment variable.  When set to ‘help=1’,
       the available options are shown at startup of the instrumented
!      program.  The option cannot be combined with ‘-fsanitize=thread’ or
!      ‘-fsanitize=address’, and is currently only available on AArch64.
  
! ‘-fsanitize=kernel-hwaddress’
       Enable Hardware-assisted AddressSanitizer for compilation of the
!      Linux kernel.  Similar to ‘-fsanitize=kernel-address’ but using an
       alternate instrumentation method, and similar to
!      ‘-fsanitize=hwaddress’ but with instrumentation differences
       necessary for compiling the Linux kernel.  These differences are to
       avoid hwasan library initialization calls and to account for the
       stack pointer having a different value in its top byte.
  
       _Note:_ This option has different defaults to the
!      ‘-fsanitize=hwaddress’.  Instrumenting the stack and alloca calls
       are not on by default but are still possible by specifying the
!      command-line options ‘--param hwasan-instrument-stack=1’ and
!      ‘--param hwasan-instrument-allocas=1’ respectively.  Using a random
       frame tag is not implemented for kernel instrumentation.
  
! ‘-fsanitize=pointer-compare’
       Instrument comparison operation (<, <=, >, >=) with pointer
       operands.  The option must be combined with either
!      ‘-fsanitize=kernel-address’ or ‘-fsanitize=address’ The option
!      cannot be combined with ‘-fsanitize=thread’.  Note: By default the
       check is disabled at run time.  To enable it, add
!      ‘detect_invalid_pointer_pairs=2’ to the environment variable
!      ‘ASAN_OPTIONS’.  Using ‘detect_invalid_pointer_pairs=1’ detects
       invalid operation only when both pointers are non-null.
  
! ‘-fsanitize=pointer-subtract’
       Instrument subtraction with pointer operands.  The option must be
!      combined with either ‘-fsanitize=kernel-address’ or
!      ‘-fsanitize=address’ The option cannot be combined with
!      ‘-fsanitize=thread’.  Note: By default the check is disabled at run
!      time.  To enable it, add ‘detect_invalid_pointer_pairs=2’ to the
!      environment variable ‘ASAN_OPTIONS’.  Using
!      ‘detect_invalid_pointer_pairs=1’ detects invalid operation only
       when both pointers are non-null.
  
! ‘-fsanitize=shadow-call-stack’
       Enable ShadowCallStack, a security enhancement mechanism used to
       protect programs against return address overwrites (e.g.  stack
       buffer overflows.)  It works by saving a function's return address
*************** program analysis purposes.
*** 15374,15458 ****
       may cause the ABI rules to be broken.
  
       On aarch64, the instrumentation makes use of the platform register
!      'x18'.  This generally means that any code that may run on the same
       thread as code compiled with ShadowCallStack must be compiled with
!      the flag '-ffixed-x18', otherwise functions compiled without
!      '-ffixed-x18' might clobber 'x18' and so corrupt the shadow stack
       pointer.
  
       Also, because there is no userspace runtime support, code compiled
       with ShadowCallStack cannot use exception handling.  Use
!      '-fno-exceptions' to turn off exceptions.
  
       See  for more
       details.
  
! '-fsanitize=thread'
       Enable ThreadSanitizer, a fast data race detector.  Memory access
       instructions are instrumented to detect data race bugs.  See
        for
       more details.  The run-time behavior can be influenced using the
!      'TSAN_OPTIONS' environment variable; see
       
       for a list of supported options.  The option cannot be combined
!      with '-fsanitize=address', '-fsanitize=leak'.
  
       Note that sanitized atomic builtins cannot throw exceptions when
       operating on invalid memory addresses with non-call exceptions
!      ('-fnon-call-exceptions').
  
! '-fsanitize=leak'
       Enable LeakSanitizer, a memory leak detector.  This option only
       matters for linking of executables.  The executable is linked
!      against a library that overrides 'malloc' and other allocator
       functions.  See
       
       for more details.  The run-time behavior can be influenced using
!      the 'LSAN_OPTIONS' environment variable.  The option cannot be
!      combined with '-fsanitize=thread'.
  
! '-fsanitize=undefined'
       Enable UndefinedBehaviorSanitizer, a fast undefined behavior
       detector.  Various computations are instrumented to detect
       undefined behavior at runtime.  See
        for
       more details.  The run-time behavior can be influenced using the
!      'UBSAN_OPTIONS' environment variable.  Current suboptions are:
  
!      '-fsanitize=shift'
            This option enables checking that the result of a shift
            operation is not undefined.  Note that what exactly is
            considered undefined differs slightly between C and C++, as
            well as between ISO C90 and C99, etc.  This option has two
!           suboptions, '-fsanitize=shift-base' and
!           '-fsanitize=shift-exponent'.
  
!      '-fsanitize=shift-exponent'
            This option enables checking that the second argument of a
            shift operation is not negative and is smaller than the
            precision of the promoted first argument.
  
!      '-fsanitize=shift-base'
            If the second argument of a shift operation is within range,
            check that the result of a shift operation is not undefined.
            Note that what exactly is considered undefined differs
            slightly between C and C++, as well as between ISO C90 and
            C99, etc.
  
!      '-fsanitize=integer-divide-by-zero'
            Detect integer division by zero.
  
!      '-fsanitize=unreachable'
            With this option, the compiler turns the
!           '__builtin_unreachable' call into a diagnostics message call
!           instead.  When reaching the '__builtin_unreachable' call, the
            behavior is undefined.
  
!      '-fsanitize=vla-bound'
            This option instructs the compiler to check that the size of a
            variable length array is positive.
  
!      '-fsanitize=null'
            This option enables pointer checking.  Particularly, the
            application built with this option turned on will issue an
            error message when it tries to dereference a NULL pointer, or
--- 15378,15462 ----
       may cause the ABI rules to be broken.
  
       On aarch64, the instrumentation makes use of the platform register
!      ‘x18’.  This generally means that any code that may run on the same
       thread as code compiled with ShadowCallStack must be compiled with
!      the flag ‘-ffixed-x18’, otherwise functions compiled without
!      ‘-ffixed-x18’ might clobber ‘x18’ and so corrupt the shadow stack
       pointer.
  
       Also, because there is no userspace runtime support, code compiled
       with ShadowCallStack cannot use exception handling.  Use
!      ‘-fno-exceptions’ to turn off exceptions.
  
       See  for more
       details.
  
! ‘-fsanitize=thread’
       Enable ThreadSanitizer, a fast data race detector.  Memory access
       instructions are instrumented to detect data race bugs.  See
        for
       more details.  The run-time behavior can be influenced using the
!      ‘TSAN_OPTIONS’ environment variable; see
       
       for a list of supported options.  The option cannot be combined
!      with ‘-fsanitize=address’, ‘-fsanitize=leak’.
  
       Note that sanitized atomic builtins cannot throw exceptions when
       operating on invalid memory addresses with non-call exceptions
!      (‘-fnon-call-exceptions’).
  
! ‘-fsanitize=leak’
       Enable LeakSanitizer, a memory leak detector.  This option only
       matters for linking of executables.  The executable is linked
!      against a library that overrides ‘malloc’ and other allocator
       functions.  See
       
       for more details.  The run-time behavior can be influenced using
!      the ‘LSAN_OPTIONS’ environment variable.  The option cannot be
!      combined with ‘-fsanitize=thread’.
  
! ‘-fsanitize=undefined’
       Enable UndefinedBehaviorSanitizer, a fast undefined behavior
       detector.  Various computations are instrumented to detect
       undefined behavior at runtime.  See
        for
       more details.  The run-time behavior can be influenced using the
!      ‘UBSAN_OPTIONS’ environment variable.  Current suboptions are:
  
!      ‘-fsanitize=shift’
            This option enables checking that the result of a shift
            operation is not undefined.  Note that what exactly is
            considered undefined differs slightly between C and C++, as
            well as between ISO C90 and C99, etc.  This option has two
!           suboptions, ‘-fsanitize=shift-base’ and
!           ‘-fsanitize=shift-exponent’.
  
!      ‘-fsanitize=shift-exponent’
            This option enables checking that the second argument of a
            shift operation is not negative and is smaller than the
            precision of the promoted first argument.
  
!      ‘-fsanitize=shift-base’
            If the second argument of a shift operation is within range,
            check that the result of a shift operation is not undefined.
            Note that what exactly is considered undefined differs
            slightly between C and C++, as well as between ISO C90 and
            C99, etc.
  
!      ‘-fsanitize=integer-divide-by-zero’
            Detect integer division by zero.
  
!      ‘-fsanitize=unreachable’
            With this option, the compiler turns the
!           ‘__builtin_unreachable’ call into a diagnostics message call
!           instead.  When reaching the ‘__builtin_unreachable’ call, the
            behavior is undefined.
  
!      ‘-fsanitize=vla-bound’
            This option instructs the compiler to check that the size of a
            variable length array is positive.
  
!      ‘-fsanitize=null’
            This option enables pointer checking.  Particularly, the
            application built with this option turned on will issue an
            error message when it tries to dereference a NULL pointer, or
*************** program analysis purposes.
*** 15460,15619 ****
            NULL pointer, or if a method is invoked on an object pointed
            by a NULL pointer.
  
!      '-fsanitize=return'
            This option enables return statement checking.  Programs built
            with this option turned on will issue an error message when
            the end of a non-void function is reached without actually
            returning a value.  This option works in C++ only.
  
!      '-fsanitize=signed-integer-overflow'
            This option enables signed integer overflow checking.  We
!           check that the result of '+', '*', and both unary and binary
!           '-' does not overflow in the signed arithmetics.  This also
!           detects 'INT_MIN / -1' signed division.  Note, integer
            promotion rules must be taken into account.  That is, the
            following is not an overflow:
                 signed char a = SCHAR_MAX;
                 a++;
  
!      '-fsanitize=bounds'
            This option enables instrumentation of array bounds.  Various
            out of bounds accesses are detected.  Flexible array members,
            flexible array member-like arrays, and initializers of
            variables with static storage are not instrumented, with the
            exception of flexible array member-like arrays for which
!           '-fstrict-flex-arrays' or '-fstrict-flex-arrays=' options or
!           'strict_flex_array' attributes say they shouldn't be treated
            like flexible array member-like arrays.
  
!      '-fsanitize=bounds-strict'
            This option enables strict instrumentation of array bounds.
            Most out of bounds accesses are detected, including flexible
            array member-like arrays.  Initializers of variables with
            static storage are not instrumented.
  
!      '-fsanitize=alignment'
  
            This option enables checking of alignment of pointers when
            they are dereferenced, or when a reference is bound to
            insufficiently aligned target, or when a method or constructor
            is invoked on insufficiently aligned object.
  
!      '-fsanitize=object-size'
            This option enables instrumentation of memory references using
!           the '__builtin_dynamic_object_size' function.  Various out of
            bounds pointer accesses are detected.
  
!      '-fsanitize=float-divide-by-zero'
            Detect floating-point division by zero.  Unlike other similar
!           options, '-fsanitize=float-divide-by-zero' is not enabled by
!           '-fsanitize=undefined', since floating-point division by zero
            can be a legitimate way of obtaining infinities and NaNs.
  
!      '-fsanitize=float-cast-overflow'
            This option enables floating-point type to integer conversion
            checking.  We check that the result of the conversion does not
            overflow.  Unlike other similar options,
!           '-fsanitize=float-cast-overflow' is not enabled by
!           '-fsanitize=undefined'.  This option does not work well with
!           'FE_INVALID' exceptions enabled.
  
!      '-fsanitize=nonnull-attribute'
  
            This option enables instrumentation of calls, checking whether
            null values are not passed to arguments marked as requiring a
!           non-null value by the 'nonnull' function attribute.
  
!      '-fsanitize=returns-nonnull-attribute'
  
            This option enables instrumentation of return statements in
!           functions marked with 'returns_nonnull' function attribute, to
            detect returning of null values from such functions.
  
!      '-fsanitize=bool'
  
            This option enables instrumentation of loads from bool.  If a
            value other than 0/1 is loaded, a run-time error is issued.
  
!      '-fsanitize=enum'
  
            This option enables instrumentation of loads from an enum
            type.  If a value outside the range of values for the enum
            type is loaded, a run-time error is issued.
  
!      '-fsanitize=vptr'
  
            This option enables instrumentation of C++ member function
            calls, member accesses and some conversions between pointers
            to base and derived classes, to verify the referenced object
            has the correct dynamic type.
  
!      '-fsanitize=pointer-overflow'
  
            This option enables instrumentation of pointer arithmetics.
            If the pointer arithmetics overflows, a run-time error is
            issued.
  
!      '-fsanitize=builtin'
  
            This option enables instrumentation of arguments to selected
            builtin functions.  If an invalid value is passed to such
            arguments, a run-time error is issued.  E.g. passing 0 as the
!           argument to '__builtin_ctz' or '__builtin_clz' invokes
            undefined behavior and is diagnosed by this option.
  
       Note that sanitizers tend to increase the rate of false positive
!      warnings, most notably those around '-Wmaybe-uninitialized'.  We
!      recommend against combining '-Werror' and [the use of] sanitizers.
  
!      While '-ftrapv' causes traps for signed overflows to be emitted,
!      '-fsanitize=undefined' gives a diagnostic message.  This currently
       works only for the C family of languages.
  
! '-fno-sanitize=all'
  
       This option disables all previously enabled sanitizers.
!      '-fsanitize=all' is not allowed, as some sanitizers cannot be used
       together.
  
! '-fasan-shadow-offset=NUMBER'
       This option forces GCC to use custom shadow offset in
       AddressSanitizer checks.  It is useful for experimenting with
       different shadow memory layouts in Kernel AddressSanitizer.
  
! '-fsanitize-sections=S1,S2,...'
       Sanitize global variables in selected user-defined sections.  SI
       may contain wildcards.
  
! '-fsanitize-recover[=OPTS]'
!      '-fsanitize-recover=' controls error recovery mode for sanitizers
       mentioned in comma-separated list of OPTS.  Enabling this option
       for a sanitizer component causes it to attempt to continue running
       the program as if no error happened.  This means multiple runtime
       errors can be reported in a single program run, and the exit code
       of the program may indicate success even when errors have been
!      reported.  The '-fno-sanitize-recover=' option can be used to alter
       this behavior: only the first detected error is reported and
       program then exits with a non-zero exit code.
  
!      Currently this feature only works for '-fsanitize=undefined' (and
!      its suboptions except for '-fsanitize=unreachable' and
!      '-fsanitize=return'), '-fsanitize=float-cast-overflow',
!      '-fsanitize=float-divide-by-zero', '-fsanitize=bounds-strict',
!      '-fsanitize=kernel-address' and '-fsanitize=address'.  For these
       sanitizers error recovery is turned on by default, except
!      '-fsanitize=address', for which this feature is experimental.
!      '-fsanitize-recover=all' and '-fno-sanitize-recover=all' is also
       accepted, the former enables recovery for all sanitizers that
       support it, the latter disables recovery for all sanitizers that
       support it.
  
       Even if a recovery mode is turned on the compiler side, it needs to
       be also enabled on the runtime library side, otherwise the failures
!      are still fatal.  The runtime library defaults to 'halt_on_error=0'
       for ThreadSanitizer and UndefinedBehaviorSanitizer, while default
!      value for AddressSanitizer is 'halt_on_error=1'.  This can be
!      overridden through setting the 'halt_on_error' flag in the
       corresponding environment variable.
  
       Syntax without an explicit OPTS parameter is deprecated.  It is
--- 15464,15623 ----
            NULL pointer, or if a method is invoked on an object pointed
            by a NULL pointer.
  
!      ‘-fsanitize=return’
            This option enables return statement checking.  Programs built
            with this option turned on will issue an error message when
            the end of a non-void function is reached without actually
            returning a value.  This option works in C++ only.
  
!      ‘-fsanitize=signed-integer-overflow’
            This option enables signed integer overflow checking.  We
!           check that the result of ‘+’, ‘*’, and both unary and binary
!           ‘-’ does not overflow in the signed arithmetics.  This also
!           detects ‘INT_MIN / -1’ signed division.  Note, integer
            promotion rules must be taken into account.  That is, the
            following is not an overflow:
                 signed char a = SCHAR_MAX;
                 a++;
  
!      ‘-fsanitize=bounds’
            This option enables instrumentation of array bounds.  Various
            out of bounds accesses are detected.  Flexible array members,
            flexible array member-like arrays, and initializers of
            variables with static storage are not instrumented, with the
            exception of flexible array member-like arrays for which
!           ‘-fstrict-flex-arrays’ or ‘-fstrict-flex-arrays=’ options or
!           ‘strict_flex_array’ attributes say they shouldn't be treated
            like flexible array member-like arrays.
  
!      ‘-fsanitize=bounds-strict’
            This option enables strict instrumentation of array bounds.
            Most out of bounds accesses are detected, including flexible
            array member-like arrays.  Initializers of variables with
            static storage are not instrumented.
  
!      ‘-fsanitize=alignment’
  
            This option enables checking of alignment of pointers when
            they are dereferenced, or when a reference is bound to
            insufficiently aligned target, or when a method or constructor
            is invoked on insufficiently aligned object.
  
!      ‘-fsanitize=object-size’
            This option enables instrumentation of memory references using
!           the ‘__builtin_dynamic_object_size’ function.  Various out of
            bounds pointer accesses are detected.
  
!      ‘-fsanitize=float-divide-by-zero’
            Detect floating-point division by zero.  Unlike other similar
!           options, ‘-fsanitize=float-divide-by-zero’ is not enabled by
!           ‘-fsanitize=undefined’, since floating-point division by zero
            can be a legitimate way of obtaining infinities and NaNs.
  
!      ‘-fsanitize=float-cast-overflow’
            This option enables floating-point type to integer conversion
            checking.  We check that the result of the conversion does not
            overflow.  Unlike other similar options,
!           ‘-fsanitize=float-cast-overflow’ is not enabled by
!           ‘-fsanitize=undefined’.  This option does not work well with
!           ‘FE_INVALID’ exceptions enabled.
  
!      ‘-fsanitize=nonnull-attribute’
  
            This option enables instrumentation of calls, checking whether
            null values are not passed to arguments marked as requiring a
!           non-null value by the ‘nonnull’ function attribute.
  
!      ‘-fsanitize=returns-nonnull-attribute’
  
            This option enables instrumentation of return statements in
!           functions marked with ‘returns_nonnull’ function attribute, to
            detect returning of null values from such functions.
  
!      ‘-fsanitize=bool’
  
            This option enables instrumentation of loads from bool.  If a
            value other than 0/1 is loaded, a run-time error is issued.
  
!      ‘-fsanitize=enum’
  
            This option enables instrumentation of loads from an enum
            type.  If a value outside the range of values for the enum
            type is loaded, a run-time error is issued.
  
!      ‘-fsanitize=vptr’
  
            This option enables instrumentation of C++ member function
            calls, member accesses and some conversions between pointers
            to base and derived classes, to verify the referenced object
            has the correct dynamic type.
  
!      ‘-fsanitize=pointer-overflow’
  
            This option enables instrumentation of pointer arithmetics.
            If the pointer arithmetics overflows, a run-time error is
            issued.
  
!      ‘-fsanitize=builtin’
  
            This option enables instrumentation of arguments to selected
            builtin functions.  If an invalid value is passed to such
            arguments, a run-time error is issued.  E.g. passing 0 as the
!           argument to ‘__builtin_ctz’ or ‘__builtin_clz’ invokes
            undefined behavior and is diagnosed by this option.
  
       Note that sanitizers tend to increase the rate of false positive
!      warnings, most notably those around ‘-Wmaybe-uninitialized’.  We
!      recommend against combining ‘-Werror’ and [the use of] sanitizers.
  
!      While ‘-ftrapv’ causes traps for signed overflows to be emitted,
!      ‘-fsanitize=undefined’ gives a diagnostic message.  This currently
       works only for the C family of languages.
  
! ‘-fno-sanitize=all’
  
       This option disables all previously enabled sanitizers.
!      ‘-fsanitize=all’ is not allowed, as some sanitizers cannot be used
       together.
  
! ‘-fasan-shadow-offset=NUMBER’
       This option forces GCC to use custom shadow offset in
       AddressSanitizer checks.  It is useful for experimenting with
       different shadow memory layouts in Kernel AddressSanitizer.
  
! ‘-fsanitize-sections=S1,S2,...’
       Sanitize global variables in selected user-defined sections.  SI
       may contain wildcards.
  
! ‘-fsanitize-recover[=OPTS]’
!      ‘-fsanitize-recover=’ controls error recovery mode for sanitizers
       mentioned in comma-separated list of OPTS.  Enabling this option
       for a sanitizer component causes it to attempt to continue running
       the program as if no error happened.  This means multiple runtime
       errors can be reported in a single program run, and the exit code
       of the program may indicate success even when errors have been
!      reported.  The ‘-fno-sanitize-recover=’ option can be used to alter
       this behavior: only the first detected error is reported and
       program then exits with a non-zero exit code.
  
!      Currently this feature only works for ‘-fsanitize=undefined’ (and
!      its suboptions except for ‘-fsanitize=unreachable’ and
!      ‘-fsanitize=return’), ‘-fsanitize=float-cast-overflow’,
!      ‘-fsanitize=float-divide-by-zero’, ‘-fsanitize=bounds-strict’,
!      ‘-fsanitize=kernel-address’ and ‘-fsanitize=address’.  For these
       sanitizers error recovery is turned on by default, except
!      ‘-fsanitize=address’, for which this feature is experimental.
!      ‘-fsanitize-recover=all’ and ‘-fno-sanitize-recover=all’ is also
       accepted, the former enables recovery for all sanitizers that
       support it, the latter disables recovery for all sanitizers that
       support it.
  
       Even if a recovery mode is turned on the compiler side, it needs to
       be also enabled on the runtime library side, otherwise the failures
!      are still fatal.  The runtime library defaults to ‘halt_on_error=0’
       for ThreadSanitizer and UndefinedBehaviorSanitizer, while default
!      value for AddressSanitizer is ‘halt_on_error=1’.  This can be
!      overridden through setting the ‘halt_on_error’ flag in the
       corresponding environment variable.
  
       Syntax without an explicit OPTS parameter is deprecated.  It is
*************** program analysis purposes.
*** 15621,15677 ****
  
            undefined,float-cast-overflow,float-divide-by-zero,bounds-strict
  
! '-fsanitize-address-use-after-scope'
       Enable sanitization of local variables to detect use-after-scope
!      bugs.  The option sets '-fstack-reuse' to 'none'.
  
! '-fsanitize-trap[=OPTS]'
!      The '-fsanitize-trap=' option instructs the compiler to report for
       sanitizers mentioned in comma-separated list of OPTS undefined
!      behavior using '__builtin_trap' rather than a 'libubsan' library
       routine.  If this option is enabled for certain sanitizer, it takes
!      precedence over the '-fsanitizer-recover=' for that sanitizer,
!      '__builtin_trap' will be emitted and be fatal regardless of whether
!      recovery is enabled or disabled using '-fsanitize-recover='.
  
!      The advantage of this is that the 'libubsan' library is not needed
       and is not linked in, so this is usable even in freestanding
       environments.
  
!      Currently this feature works with '-fsanitize=undefined' (and its
!      suboptions except for '-fsanitize=vptr'),
!      '-fsanitize=float-cast-overflow', '-fsanitize=float-divide-by-zero'
!      and '-fsanitize=bounds-strict'.  '-fsanitize-trap=all' can be also
!      specified, which enables it for 'undefined' suboptions,
!      '-fsanitize=float-cast-overflow', '-fsanitize=float-divide-by-zero'
!      and '-fsanitize=bounds-strict'.  If '-fsanitize-trap=undefined' or
!      '-fsanitize-trap=all' is used and '-fsanitize=vptr' is enabled on
       the command line, the instrumentation is silently ignored as the
!      instrumentation always needs 'libubsan' support,
!      '-fsanitize-trap=vptr' is not allowed.
  
! '-fsanitize-undefined-trap-on-error'
!      The '-fsanitize-undefined-trap-on-error' option is deprecated
!      equivalent of '-fsanitize-trap=all'.
  
! '-fsanitize-coverage=trace-pc'
       Enable coverage-guided fuzzing code instrumentation.  Inserts a
!      call to '__sanitizer_cov_trace_pc' into every basic block.
  
! '-fsanitize-coverage=trace-cmp'
       Enable dataflow guided fuzzing code instrumentation.  Inserts a
!      call to '__sanitizer_cov_trace_cmp1', '__sanitizer_cov_trace_cmp2',
!      '__sanitizer_cov_trace_cmp4' or '__sanitizer_cov_trace_cmp8' for
       integral comparison with both operands variable or
!      '__sanitizer_cov_trace_const_cmp1',
!      '__sanitizer_cov_trace_const_cmp2',
!      '__sanitizer_cov_trace_const_cmp4' or
!      '__sanitizer_cov_trace_const_cmp8' for integral comparison with one
!      operand constant, '__sanitizer_cov_trace_cmpf' or
!      '__sanitizer_cov_trace_cmpd' for float or double comparisons and
!      '__sanitizer_cov_trace_switch' for switch statements.
  
! '-fcf-protection=[full|branch|return|none|check]'
       Enable code instrumentation of control-flow transfers to increase
       program security by checking that target addresses of control-flow
       transfer instructions (such as indirect function call, function
--- 15625,15681 ----
  
            undefined,float-cast-overflow,float-divide-by-zero,bounds-strict
  
! ‘-fsanitize-address-use-after-scope’
       Enable sanitization of local variables to detect use-after-scope
!      bugs.  The option sets ‘-fstack-reuse’ to ‘none’.
  
! ‘-fsanitize-trap[=OPTS]’
!      The ‘-fsanitize-trap=’ option instructs the compiler to report for
       sanitizers mentioned in comma-separated list of OPTS undefined
!      behavior using ‘__builtin_trap’ rather than a ‘libubsan’ library
       routine.  If this option is enabled for certain sanitizer, it takes
!      precedence over the ‘-fsanitizer-recover=’ for that sanitizer,
!      ‘__builtin_trap’ will be emitted and be fatal regardless of whether
!      recovery is enabled or disabled using ‘-fsanitize-recover=’.
  
!      The advantage of this is that the ‘libubsan’ library is not needed
       and is not linked in, so this is usable even in freestanding
       environments.
  
!      Currently this feature works with ‘-fsanitize=undefined’ (and its
!      suboptions except for ‘-fsanitize=vptr’),
!      ‘-fsanitize=float-cast-overflow’, ‘-fsanitize=float-divide-by-zero’
!      and ‘-fsanitize=bounds-strict’.  ‘-fsanitize-trap=all’ can be also
!      specified, which enables it for ‘undefined’ suboptions,
!      ‘-fsanitize=float-cast-overflow’, ‘-fsanitize=float-divide-by-zero’
!      and ‘-fsanitize=bounds-strict’.  If ‘-fsanitize-trap=undefined’ or
!      ‘-fsanitize-trap=all’ is used and ‘-fsanitize=vptr’ is enabled on
       the command line, the instrumentation is silently ignored as the
!      instrumentation always needs ‘libubsan’ support,
!      ‘-fsanitize-trap=vptr’ is not allowed.
  
! ‘-fsanitize-undefined-trap-on-error’
!      The ‘-fsanitize-undefined-trap-on-error’ option is deprecated
!      equivalent of ‘-fsanitize-trap=all’.
  
! ‘-fsanitize-coverage=trace-pc’
       Enable coverage-guided fuzzing code instrumentation.  Inserts a
!      call to ‘__sanitizer_cov_trace_pc’ into every basic block.
  
! ‘-fsanitize-coverage=trace-cmp’
       Enable dataflow guided fuzzing code instrumentation.  Inserts a
!      call to ‘__sanitizer_cov_trace_cmp1’, ‘__sanitizer_cov_trace_cmp2’,
!      ‘__sanitizer_cov_trace_cmp4’ or ‘__sanitizer_cov_trace_cmp8’ for
       integral comparison with both operands variable or
!      ‘__sanitizer_cov_trace_const_cmp1’,
!      ‘__sanitizer_cov_trace_const_cmp2’,
!      ‘__sanitizer_cov_trace_const_cmp4’ or
!      ‘__sanitizer_cov_trace_const_cmp8’ for integral comparison with one
!      operand constant, ‘__sanitizer_cov_trace_cmpf’ or
!      ‘__sanitizer_cov_trace_cmpd’ for float or double comparisons and
!      ‘__sanitizer_cov_trace_switch’ for switch statements.
  
! ‘-fcf-protection=[full|branch|return|none|check]’
       Enable code instrumentation of control-flow transfers to increase
       program security by checking that target addresses of control-flow
       transfer instructions (such as indirect function call, function
*************** program analysis purposes.
*** 15680,15702 ****
       against such threats as Return-oriented Programming (ROP), and
       similarly call/jmp-oriented programming (COP/JOP).
  
!      The value 'branch' tells the compiler to implement checking of
       validity of control-flow transfer at the point of indirect branch
!      instructions, i.e. call/jmp instructions.  The value 'return'
       implements checking of validity at the point of returning from a
!      function.  The value 'full' is an alias for specifying both
!      'branch' and 'return'.  The value 'none' turns off instrumentation.
  
!      The value 'check' is used for the final link with link-time
       optimization (LTO). An error is issued if LTO object files are
!      compiled with different '-fcf-protection' values.  The value
!      'check' is ignored at the compile time.
  
!      The macro '__CET__' is defined when '-fcf-protection' is used.  The
!      first bit of '__CET__' is set to 1 for the value 'branch' and the
!      second bit of '__CET__' is set to 1 for the 'return'.
  
!      You can also use the 'nocf_check' attribute to identify which
       functions and calls should be skipped from instrumentation (*note
       Function Attributes::).
  
--- 15684,15706 ----
       against such threats as Return-oriented Programming (ROP), and
       similarly call/jmp-oriented programming (COP/JOP).
  
!      The value ‘branch’ tells the compiler to implement checking of
       validity of control-flow transfer at the point of indirect branch
!      instructions, i.e. call/jmp instructions.  The value ‘return’
       implements checking of validity at the point of returning from a
!      function.  The value ‘full’ is an alias for specifying both
!      ‘branch’ and ‘return’.  The value ‘none’ turns off instrumentation.
  
!      The value ‘check’ is used for the final link with link-time
       optimization (LTO). An error is issued if LTO object files are
!      compiled with different ‘-fcf-protection’ values.  The value
!      ‘check’ is ignored at the compile time.
  
!      The macro ‘__CET__’ is defined when ‘-fcf-protection’ is used.  The
!      first bit of ‘__CET__’ is set to 1 for the value ‘branch’ and the
!      second bit of ‘__CET__’ is set to 1 for the ‘return’.
  
!      You can also use the ‘nocf_check’ attribute to identify which
       functions and calls should be skipped from instrumentation (*note
       Function Attributes::).
  
*************** program analysis purposes.
*** 15704,15751 ****
       on Intel Control-flow Enforcement Technology (CET) which works for
       i686 processor or newer.
  
! '-fharden-compares'
       For every logical test that survives gimple optimizations and is
       _not_ the condition in a conditional branch (for example,
       conditions tested for conditional moves, or to store in boolean
       variables), emit extra code to compute and verify the reversed
!      condition, and to call '__builtin_trap' if the results do not
!      match.  Use with '-fharden-conditional-branches' to cover all
       conditionals.
  
! '-fharden-conditional-branches'
       For every non-vectorized conditional branch that survives gimple
       optimizations, emit extra code to compute and verify the reversed
!      condition, and to call '__builtin_trap' if the result is
!      unexpected.  Use with '-fharden-compares' to cover all
       conditionals.
  
! '-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 or equal to 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.  Only variables
       that are actually allocated on the stack are considered, optimized
       away variables or variables allocated in registers don't count.
  
! '-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.  Only variables that are
       actually allocated on the stack are considered, optimized away
       variables or variables allocated in registers don't count.
  
! '-fstack-protector-explicit'
!      Like '-fstack-protector' but only protects those functions which
!      have the 'stack_protect' attribute.
  
! '-fstack-check'
       Generate code to verify that you do not go beyond the boundary of
       the stack.  You should specify this flag if you are running in an
       environment with multiple threads, but you only rarely need to
--- 15708,15755 ----
       on Intel Control-flow Enforcement Technology (CET) which works for
       i686 processor or newer.
  
! ‘-fharden-compares’
       For every logical test that survives gimple optimizations and is
       _not_ the condition in a conditional branch (for example,
       conditions tested for conditional moves, or to store in boolean
       variables), emit extra code to compute and verify the reversed
!      condition, and to call ‘__builtin_trap’ if the results do not
!      match.  Use with ‘-fharden-conditional-branches’ to cover all
       conditionals.
  
! ‘-fharden-conditional-branches’
       For every non-vectorized conditional branch that survives gimple
       optimizations, emit extra code to compute and verify the reversed
!      condition, and to call ‘__builtin_trap’ if the result is
!      unexpected.  Use with ‘-fharden-compares’ to cover all
       conditionals.
  
! ‘-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 or equal to 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.  Only variables
       that are actually allocated on the stack are considered, optimized
       away variables or variables allocated in registers don't count.
  
! ‘-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.  Only variables that are
       actually allocated on the stack are considered, optimized away
       variables or variables allocated in registers don't count.
  
! ‘-fstack-protector-explicit’
!      Like ‘-fstack-protector’ but only protects those functions which
!      have the ‘stack_protect’ attribute.
  
! ‘-fstack-check’
       Generate code to verify that you do not go beyond the boundary of
       the stack.  You should specify this flag if you are running in an
       environment with multiple threads, but you only rarely need to
*************** program analysis purposes.
*** 15758,15767 ****
       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
--- 15762,15771 ----
       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
*************** program analysis purposes.
*** 15779,15793 ****
            and the generic implementation, code performance is hampered.
  
       Note that old-style stack checking is also the fallback method for
!      'specific' if no target support has been added in the compiler.
  
!      '-fstack-check=' is designed for Ada's needs to detect infinite
!      recursion and stack overflows.  'specific' is an excellent choice
       when compiling Ada code.  It is not generally sufficient to protect
       against stack-clash attacks.  To protect against those you want
!      '-fstack-clash-protection'.
  
! '-fstack-clash-protection'
       Generate code to prevent stack clash style attacks.  When this
       option is enabled, the compiler will only allocate one page of
       stack space at a time and each page is accessed immediately after
--- 15783,15797 ----
            and the generic implementation, code performance is hampered.
  
       Note that old-style stack checking is also the fallback method for
!      ‘specific’ if no target support has been added in the compiler.
  
!      ‘-fstack-check=’ is designed for Ada's needs to detect infinite
!      recursion and stack overflows.  ‘specific’ is an excellent choice
       when compiling Ada code.  It is not generally sufficient to protect
       against stack-clash attacks.  To protect against those you want
!      ‘-fstack-clash-protection’.
  
! ‘-fstack-clash-protection’
       Generate code to prevent stack clash style attacks.  When this
       option is enabled, the compiler will only allocate one page of
       stack space at a time and each page is accessed immediately after
*************** program analysis purposes.
*** 15795,15808 ****
       stack guard page provided by the operating system.
  
       Most targets do not fully support stack clash protection.  However,
!      on those targets '-fstack-clash-protection' will protect dynamic
!      stack allocations.  '-fstack-clash-protection' may also provide
       limited protection for static stack allocations if the target
!      supports '-fstack-check=specific'.
  
! '-fstack-limit-register=REG'
! '-fstack-limit-symbol=SYM'
! '-fno-stack-limit'
       Generate code to ensure that the stack does not grow beyond a
       certain value, either the value of a register or the address of a
       symbol.  If a larger stack is required, a signal is raised at run
--- 15799,15812 ----
       stack guard page provided by the operating system.
  
       Most targets do not fully support stack clash protection.  However,
!      on those targets ‘-fstack-clash-protection’ will protect dynamic
!      stack allocations.  ‘-fstack-clash-protection’ may also provide
       limited protection for static stack allocations if the target
!      supports ‘-fstack-check=specific’.
  
! ‘-fstack-limit-register=REG’
! ‘-fstack-limit-symbol=SYM’
! ‘-fno-stack-limit’
       Generate code to ensure that the stack does not grow beyond a
       certain value, either the value of a register or the address of a
       symbol.  If a larger stack is required, a signal is raised at run
*************** program analysis purposes.
*** 15810,15825 ****
       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.
  
       You can locally override stack limit checking by using the
!      'no_stack_limit' function attribute (*note Function Attributes::).
  
! '-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.
--- 15814,15829 ----
       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.
  
       You can locally override stack limit checking by using the
!      ‘no_stack_limit’ function attribute (*note Function Attributes::).
  
! ‘-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.
*************** program analysis purposes.
*** 15828,15845 ****
       thread.  This is currently only implemented for the x86 targets
       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.
  
! '-fvtable-verify=[std|preinit|none]'
       This option is only available when compiling C++ code.  It turns on
!      (or off, if using '-fvtable-verify=none') the security feature that
       verifies at run time, for every virtual call, that the vtable
       pointer through which the call is made is valid for the type of the
       object, and has not been corrupted or overwritten.  If an invalid
--- 15832,15849 ----
       thread.  This is currently only implemented for the x86 targets
       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.
  
! ‘-fvtable-verify=[std|preinit|none]’
       This option is only available when compiling C++ code.  It turns on
!      (or off, if using ‘-fvtable-verify=none’) the security feature that
       verifies at run time, for every virtual call, that the vtable
       pointer through which the call is made is valid for the type of the
       object, and has not been corrupted or overwritten.  If an invalid
*************** program analysis purposes.
*** 15848,15901 ****
  
       This option causes run-time data structures to be built at program
       startup, which are used for verifying the vtable pointers.  The
!      options 'std' and 'preinit' control the timing of when these data
       structures are built.  In both cases the data structures are built
!      before execution reaches 'main'.  Using '-fvtable-verify=std'
       causes the data structures to be built after shared libraries have
!      been loaded and initialized.  '-fvtable-verify=preinit' causes them
       to be built before shared libraries have been loaded and
       initialized.
  
       If this option appears multiple times in the command line with
!      different values specified, 'none' takes highest priority over both
!      'std' and 'preinit'; 'preinit' takes priority over 'std'.
  
! '-fvtv-debug'
!      When used in conjunction with '-fvtable-verify=std' or
!      '-fvtable-verify=preinit', causes debug versions of the runtime
       functions for the vtable verification feature to be called.  This
       flag also causes the compiler to log information about which vtable
       pointers it finds for each class.  This information is written to a
!      file named 'vtv_set_ptr_data.log' in the directory named by the
!      environment variable 'VTV_LOGS_DIR' if that is defined or the
       current working directory otherwise.
  
       Note: This feature _appends_ data to the log file.  If you want a
       fresh log file, be sure to delete any existing one.
  
! '-fvtv-counts'
       This is a debugging flag.  When used in conjunction with
!      '-fvtable-verify=std' or '-fvtable-verify=preinit', this causes the
       compiler to keep track of the total number of virtual calls it
       encounters and the number of verifications it inserts.  It also
       counts the number of calls to certain run-time library functions
       that it inserts and logs this information for each compilation
       unit.  The compiler writes this information to a file named
!      'vtv_count_data.log' in the directory named by the environment
!      variable 'VTV_LOGS_DIR' if that is defined or the current working
       directory otherwise.  It also counts the size of the vtable pointer
       sets for each class, and writes this information to
!      'vtv_class_set_sizes.log' in the same directory.
  
       Note: This feature _appends_ data to the log files.  To get fresh
       log files, be sure to delete any existing ones.
  
! '-finstrument-functions'
       Generate instrumentation calls for entry and exit to functions.
       Just after function entry and just before function exit, the
       following profiling functions are called with the address of the
       current function and its call site.  (On some platforms,
!      '__builtin_return_address' does not work beyond the current
       function, so the call site information may not be available to the
       profiling functions otherwise.)
  
--- 15852,15905 ----
  
       This option causes run-time data structures to be built at program
       startup, which are used for verifying the vtable pointers.  The
!      options ‘std’ and ‘preinit’ control the timing of when these data
       structures are built.  In both cases the data structures are built
!      before execution reaches ‘main’.  Using ‘-fvtable-verify=std’
       causes the data structures to be built after shared libraries have
!      been loaded and initialized.  ‘-fvtable-verify=preinit’ causes them
       to be built before shared libraries have been loaded and
       initialized.
  
       If this option appears multiple times in the command line with
!      different values specified, ‘none’ takes highest priority over both
!      ‘std’ and ‘preinit’; ‘preinit’ takes priority over ‘std’.
  
! ‘-fvtv-debug’
!      When used in conjunction with ‘-fvtable-verify=std’ or
!      ‘-fvtable-verify=preinit’, causes debug versions of the runtime
       functions for the vtable verification feature to be called.  This
       flag also causes the compiler to log information about which vtable
       pointers it finds for each class.  This information is written to a
!      file named ‘vtv_set_ptr_data.log’ in the directory named by the
!      environment variable ‘VTV_LOGS_DIR’ if that is defined or the
       current working directory otherwise.
  
       Note: This feature _appends_ data to the log file.  If you want a
       fresh log file, be sure to delete any existing one.
  
! ‘-fvtv-counts’
       This is a debugging flag.  When used in conjunction with
!      ‘-fvtable-verify=std’ or ‘-fvtable-verify=preinit’, this causes the
       compiler to keep track of the total number of virtual calls it
       encounters and the number of verifications it inserts.  It also
       counts the number of calls to certain run-time library functions
       that it inserts and logs this information for each compilation
       unit.  The compiler writes this information to a file named
!      ‘vtv_count_data.log’ in the directory named by the environment
!      variable ‘VTV_LOGS_DIR’ if that is defined or the current working
       directory otherwise.  It also counts the size of the vtable pointer
       sets for each class, and writes this information to
!      ‘vtv_class_set_sizes.log’ in the same directory.
  
       Note: This feature _appends_ data to the log files.  To get fresh
       log files, be sure to delete any existing ones.
  
! ‘-finstrument-functions’
       Generate instrumentation calls for entry and exit to functions.
       Just after function entry and just before function exit, the
       following profiling functions are called with the address of the
       current function and its call site.  (On some platforms,
!      ‘__builtin_return_address’ does not work beyond the current
       function, so the call site information may not be available to the
       profiling functions otherwise.)
  
*************** program analysis purposes.
*** 15912,15924 ****
       the inline function is entered and exited.  This means that
       addressable versions of such functions must be available.  If all
       your uses of a function are expanded inline, this may mean an
!      additional expansion of code size.  If you use 'extern inline' in
       your C code, an addressable version of such functions must be
       provided.  (This is normally the case anyway, but if you get lucky
       and the optimizer always expands the functions inline, you might
       have gotten away without providing static copies.)
  
!      A function may be given the attribute 'no_instrument_function', in
       which case this instrumentation is not done.  This can be used, for
       example, for the profiling functions listed above, high-priority
       interrupt routines, and any functions from which the profiling
--- 15916,15928 ----
       the inline function is entered and exited.  This means that
       addressable versions of such functions must be available.  If all
       your uses of a function are expanded inline, this may mean an
!      additional expansion of code size.  If you use ‘extern inline’ in
       your C code, an addressable version of such functions must be
       provided.  (This is normally the case anyway, but if you get lucky
       and the optimizer always expands the functions inline, you might
       have gotten away without providing static copies.)
  
!      A function may be given the attribute ‘no_instrument_function’, in
       which case this instrumentation is not done.  This can be used, for
       example, for the profiling functions listed above, high-priority
       interrupt routines, and any functions from which the profiling
*************** program analysis purposes.
*** 15926,15939 ****
       profiling routines generate output or allocate memory).  *Note
       Common Function Attributes::.
  
! '-finstrument-functions-once'
!      This is similar to '-finstrument-functions', but the profiling
       functions are called only once per instrumented function, i.e.  the
       first profiling function is called after the first entry into the
       instrumented function and the second profiling function is called
       before the exit corresponding to this first entry.
  
!      The definition of 'once' for the purpose of this option is a little
       vague because the implementation is not protected against data
       races.  As a result, the implementation only guarantees that the
       profiling functions are called at _least_ once per process and at
--- 15930,15943 ----
       profiling routines generate output or allocate memory).  *Note
       Common Function Attributes::.
  
! ‘-finstrument-functions-once’
!      This is similar to ‘-finstrument-functions’, but the profiling
       functions are called only once per instrumented function, i.e.  the
       first profiling function is called after the first entry into the
       instrumented function and the second profiling function is called
       before the exit corresponding to this first entry.
  
!      The definition of ‘once’ for the purpose of this option is a little
       vague because the implementation is not protected against data
       races.  As a result, the implementation only guarantees that the
       profiling functions are called at _least_ once per process and at
*************** program analysis purposes.
*** 15942,15951 ****
       second function, unless it never reaches the exit of the
       instrumented function.
  
! '-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,
--- 15946,15955 ----
       second function, unless it never reaches the exit of the
       instrumented function.
  
! ‘-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,
*************** program analysis purposes.
*** 15956,16003 ****
            -finstrument-functions-exclude-file-list=/bits/stl,include/sys
  
       excludes any inline function defined in files whose pathnames
!      contain '/bits/stl' or 'include/sys'.
  
!      If, for some reason, you want to include letter ',' in one of SYM,
!      write '\,'.  For example,
!      '-finstrument-functions-exclude-file-list='\,\,tmp'' (note the
       single quote surrounding the option).
  
! '-finstrument-functions-exclude-function-list=SYM,SYM,...'
  
!      This is similar to '-finstrument-functions-exclude-file-list', but
       this option sets the list of function names to be excluded from
       instrumentation.  The function name to be matched is its
!      user-visible name, such as 'vector blah(const vector &)',
!      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.
  
! '-fpatchable-function-entry=N[,M]'
       Generate N NOPs right at the beginning of each function, with the
       function entry point before the Mth NOP. If M is omitted, it
!      defaults to '0' so the function entry points to the address just at
       the first NOP. The NOP instructions reserve extra space which can
       be used to patch in any desired instrumentation at run time,
       provided that the code segment is writable.  The amount of space is
       controllable indirectly via the number of NOPs; the NOP instruction
       used corresponds to the instruction emitted by the internal GCC
!      back-end interface 'gen_nop'.  This behavior is target-specific and
       may also depend on the architecture variant and/or other
       compilation options.
  
       For run-time identification, the starting addresses of these areas,
       which correspond to their respective function entries minus M, are
!      additionally collected in the '__patchable_function_entries'
       section of the resulting binary.
  
!      Note that the value of '__attribute__ ((patchable_function_entry
!      (N,M)))' takes precedence over command-line option
!      '-fpatchable-function-entry=N,M'.  This can be used to increase the
       area size or to remove it completely on a single function.  If
!      'N=0', no pad location is recorded.
  
       The NOP instructions are inserted at--and maybe before, depending
       on M--the function entry address, even before the prologue.  On
--- 15960,16007 ----
            -finstrument-functions-exclude-file-list=/bits/stl,include/sys
  
       excludes any inline function defined in files whose pathnames
!      contain ‘/bits/stl’ or ‘include/sys’.
  
!      If, for some reason, you want to include letter ‘,’ in one of SYM,
!      write ‘\,’.  For example,
!      ‘-finstrument-functions-exclude-file-list='\,\,tmp'’ (note the
       single quote surrounding the option).
  
! ‘-finstrument-functions-exclude-function-list=SYM,SYM,...’
  
!      This is similar to ‘-finstrument-functions-exclude-file-list’, but
       this option sets the list of function names to be excluded from
       instrumentation.  The function name to be matched is its
!      user-visible name, such as ‘vector blah(const vector &)’,
!      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.
  
! ‘-fpatchable-function-entry=N[,M]’
       Generate N NOPs right at the beginning of each function, with the
       function entry point before the Mth NOP. If M is omitted, it
!      defaults to ‘0’ so the function entry points to the address just at
       the first NOP. The NOP instructions reserve extra space which can
       be used to patch in any desired instrumentation at run time,
       provided that the code segment is writable.  The amount of space is
       controllable indirectly via the number of NOPs; the NOP instruction
       used corresponds to the instruction emitted by the internal GCC
!      back-end interface ‘gen_nop’.  This behavior is target-specific and
       may also depend on the architecture variant and/or other
       compilation options.
  
       For run-time identification, the starting addresses of these areas,
       which correspond to their respective function entries minus M, are
!      additionally collected in the ‘__patchable_function_entries’
       section of the resulting binary.
  
!      Note that the value of ‘__attribute__ ((patchable_function_entry
!      (N,M)))’ takes precedence over command-line option
!      ‘-fpatchable-function-entry=N,M’.  This can be used to increase the
       area size or to remove it completely on a single function.  If
!      ‘N=0’, no pad location is recorded.
  
       The NOP instructions are inserted at--and maybe before, depending
       on M--the function entry address, even before the prologue.  On
*************** File: gcc.info,  Node: Preprocessor Opti
*** 16017,16024 ****
  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.
  
   In addition to the options listed here, there are a number of options
--- 16021,16028 ----
  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.
  
   In addition to the options listed here, there are a number of options
*************** to control search paths for include file
*** 16026,16037 ****
  Options::.  Options to control preprocessor diagnostics are listed in
  *note Warning Options::.
  
! '-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 is truncated by embedded newline
       characters.
  
--- 16030,16041 ----
  Options::.  Options to control preprocessor diagnostics are listed in
  *note Warning Options::.
  
! ‘-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 is truncated by embedded newline
       characters.
  
*************** Options::.  Options to control preproces
*** 16042,16152 ****
       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 should 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.
  
! '-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'.
  
! '-undef'
       Do not predefine any system-specific or GCC-specific macros.  The
       standard predefined macros remain defined.
  
! '-pthread'
       Define additional macros required for using the POSIX threads
       library.  You should use this option consistently for both
       compilation and linking.  This option is supported on GNU/Linux
       targets, most other Unix derivatives, and also on x86 Cygwin and
       MinGW targets.
  
! '-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 is still 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 appears in '-MM' dependency output.
  
! '-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 send preprocessed
       output.
  
!      When used with the driver options '-MD' or '-MMD', '-MF' overrides
       the default dependency output file.
  
!      If FILE is '-', then the dependencies are written to 'stdout'.
  
! '-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.
  
! '-Mno-modules'
       Disable dependency generation for compiled module interfaces.
  
! '-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:
  
--- 16046,16156 ----
       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 should 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.
  
! ‘-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’.
  
! ‘-undef’
       Do not predefine any system-specific or GCC-specific macros.  The
       standard predefined macros remain defined.
  
! ‘-pthread’
       Define additional macros required for using the POSIX threads
       library.  You should use this option consistently for both
       compilation and linking.  This option is supported on GNU/Linux
       targets, most other Unix derivatives, and also on x86 Cygwin and
       MinGW targets.
  
! ‘-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 is still 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 appears in ‘-MM’ dependency output.
  
! ‘-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 send preprocessed
       output.
  
!      When used with the driver options ‘-MD’ or ‘-MMD’, ‘-MF’ overrides
       the default dependency output file.
  
!      If FILE is ‘-’, then the dependencies are written to ‘stdout’.
  
! ‘-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.
  
! ‘-Mno-modules’
       Disable dependency generation for compiled module interfaces.
  
! ‘-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:
  
*************** Options::.  Options to control preproces
*** 16154,16301 ****
  
            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 sets 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.
  
! '-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'.
  
! '-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 and extended characters in
       identifiers.  This option is enabled by default for C99 (and later
       C standard versions) and C++.
  
! '-fno-canonical-system-headers'
       When preprocessing, do not shorten system header paths with
       canonicalization.
  
! '-fmax-include-depth=DEPTH'
       Set the maximum depth of the nested #include.  The default is 200.
  
! '-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.
  
! '-ftrack-macro-expansion[=LEVEL]'
       Track locations of tokens across macro expansions.  This allows the
       compiler to emit diagnostic about the current macro expansion stack
       when a compilation error occurs in a macro expansion.  Using this
       option makes the preprocessor and the compiler consume more memory.
       The LEVEL parameter can be used to choose the level of precision of
       token location tracking thus decreasing the memory consumption if
!      necessary.  Value '0' of LEVEL de-activates this option.  Value '1'
       tracks tokens locations in a degraded mode for the sake of minimal
       memory overhead.  In this mode all tokens resulting from the
       expansion of an argument of a function-like macro have the same
!      location.  Value '2' tracks tokens locations completely.  This
       value is the most memory hungry.  When this option is given no
!      argument, the default parameter value is '2'.
  
!      Note that '-ftrack-macro-expansion=2' is activated by default.
  
! '-fmacro-prefix-map=OLD=NEW'
!      When preprocessing files residing in directory 'OLD', expand the
!      '__FILE__' and '__BASE_FILE__' macros as if the files resided in
!      directory 'NEW' instead.  This can be used to change an absolute
!      path to a relative path by using '.' for NEW which can result in
       more reproducible builds that are location independent.  This
!      option also affects '__builtin_FILE()' during compilation.  See
!      also '-ffile-prefix-map' and '-fcanon-prefix-map'.
  
! '-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 one of UTF-32BE, UTF-32LE,
       UTF-16BE, or UTF-16LE, whichever corresponds to the width of
!      'wchar_t' and the big-endian or little-endian byte order being used
!      for code generation.  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
--- 16158,16305 ----
  
            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 sets 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.
  
! ‘-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’.
  
! ‘-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 and extended characters in
       identifiers.  This option is enabled by default for C99 (and later
       C standard versions) and C++.
  
! ‘-fno-canonical-system-headers’
       When preprocessing, do not shorten system header paths with
       canonicalization.
  
! ‘-fmax-include-depth=DEPTH’
       Set the maximum depth of the nested #include.  The default is 200.
  
! ‘-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.
  
! ‘-ftrack-macro-expansion[=LEVEL]’
       Track locations of tokens across macro expansions.  This allows the
       compiler to emit diagnostic about the current macro expansion stack
       when a compilation error occurs in a macro expansion.  Using this
       option makes the preprocessor and the compiler consume more memory.
       The LEVEL parameter can be used to choose the level of precision of
       token location tracking thus decreasing the memory consumption if
!      necessary.  Value ‘0’ of LEVEL de-activates this option.  Value ‘1’
       tracks tokens locations in a degraded mode for the sake of minimal
       memory overhead.  In this mode all tokens resulting from the
       expansion of an argument of a function-like macro have the same
!      location.  Value ‘2’ tracks tokens locations completely.  This
       value is the most memory hungry.  When this option is given no
!      argument, the default parameter value is ‘2’.
  
!      Note that ‘-ftrack-macro-expansion=2’ is activated by default.
  
! ‘-fmacro-prefix-map=OLD=NEW’
!      When preprocessing files residing in directory ‘OLD’, expand the
!      ‘__FILE__’ and ‘__BASE_FILE__’ macros as if the files resided in
!      directory ‘NEW’ instead.  This can be used to change an absolute
!      path to a relative path by using ‘.’ for NEW which can result in
       more reproducible builds that are location independent.  This
!      option also affects ‘__builtin_FILE()’ during compilation.  See
!      also ‘-ffile-prefix-map’ and ‘-fcanon-prefix-map’.
  
! ‘-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 one of UTF-32BE, UTF-32LE,
       UTF-16BE, or UTF-16LE, whichever corresponds to the width of
!      ‘wchar_t’ and the big-endian or little-endian byte order being used
!      for code generation.  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
*************** Options::.  Options to control preproces
*** 16303,16311 ****
       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.
  
! '-fpch-deps'
       When using precompiled headers (*note Precompiled Headers::), this
       flag causes the dependency-output flags to also list the files from
       the precompiled header's dependencies.  If not specified, only the
--- 16307,16315 ----
       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.
  
! ‘-fpch-deps’
       When using precompiled headers (*note Precompiled Headers::), this
       flag causes the dependency-output flags to also list the files from
       the precompiled header's dependencies.  If not specified, only the
*************** Options::.  Options to control preproces
*** 16313,16336 ****
       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.
  
! '-fworking-directory'
       Enable generation of linemarkers in the preprocessor output that
       let the compiler know the current working directory at the time of
       preprocessing.  When this option is enabled, the preprocessor
--- 16317,16340 ----
       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.
  
! ‘-fworking-directory’
       Enable generation of linemarkers in the preprocessor output that
       let the compiler know the current working directory at the time of
       preprocessing.  When this option is enabled, the preprocessor
*************** Options::.  Options to control preproces
*** 16340,16403 ****
       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.
  
! '-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.
  
! '-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.
  
! '-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.
  
! '-traditional'
! '-traditional-cpp'
  
       Try to imitate the behavior of pre-standard C preprocessors, as
       opposed to ISO C preprocessors.  See the GNU CPP manual for
       details.
  
       Note that GCC does not otherwise attempt to emulate a pre-standard
!      C compiler, and these options are only supported with the '-E'
       switch, or when invoking CPP explicitly.
  
! '-trigraphs'
       Support ISO C trigraphs.  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.
  
       The nine trigraphs and their replacements are
--- 16344,16407 ----
       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.
  
! ‘-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.
  
! ‘-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.
  
! ‘-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.
  
! ‘-traditional’
! ‘-traditional-cpp’
  
       Try to imitate the behavior of pre-standard C preprocessors, as
       opposed to ISO C preprocessors.  See the GNU CPP manual for
       details.
  
       Note that GCC does not otherwise attempt to emulate a pre-standard
!      C compiler, and these options are only supported with the ‘-E’
       switch, or when invoking CPP explicitly.
  
! ‘-trigraphs’
       Support ISO C trigraphs.  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.
  
       The nine trigraphs and their replacements are
*************** Options::.  Options to control preproces
*** 16406,16425 ****
            Replacement:      [    ]    {    }    #    \    ^    |    ~
  
       By default, GCC ignores trigraphs, but in standard-conforming modes
!      it converts them.  See the '-std' and '-ansi' options.
  
! '-remap'
       Enable special code to work around file systems which only permit
       very short file names, such as MS-DOS.
  
! '-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 '...!' .
  
! '-dLETTERS'
       Says to make debugging dumps during compilation as specified by
       LETTERS.  The flags documented here are those relevant to the
       preprocessor.  Other LETTERS are interpreted by the compiler
--- 16410,16429 ----
            Replacement:      [    ]    {    }    #    \    ^    |    ~
  
       By default, GCC ignores trigraphs, but in standard-conforming modes
!      it converts them.  See the ‘-std’ and ‘-ansi’ options.
  
! ‘-remap’
       Enable special code to work around file systems which only permit
       very short file names, such as MS-DOS.
  
! ‘-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 ‘...!’ .
  
! ‘-dLETTERS’
       Says to make debugging dumps during compilation as specified by
       LETTERS.  The flags documented here are those relevant to the
       preprocessor.  Other LETTERS are interpreted by the compiler
*************** Options::.  Options to control preproces
*** 16428,16510 ****
       result is undefined.  *Note Developer Options::, for more
       information.
  
!      '-dM'
!           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
  
            shows all the predefined macros.
  
!           If you use '-dM' without the '-E' option, '-dM' is interpreted
!           as a synonym for '-fdump-rtl-mach'.  *Note (gcc)Developer
            Options::.
  
!      '-dD'
!           Like '-dM' 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.
  
!      '-dN'
!           Like '-dD', but emit only the macro names, not their
            expansions.
  
!      '-dI'
!           Output '#include' directives in addition to the result of
            preprocessing.
  
!      '-dU'
!           Like '-dD' 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.
  
! '-fdebug-cpp'
       This option is only useful for debugging GCC. When used from CPP or
!      with '-E', it dumps debugging information about location maps.
       Every token in the output is preceded by the dump of the map its
       location belongs to.
  
!      When used from GCC without '-E', this option has no effect.
  
! '-Wp,OPTION'
!      You can use '-Wp,OPTION' to bypass the compiler driver and pass
       OPTION directly through to the preprocessor.  If OPTION contains
       commas, it is split into multiple options at the commas.  However,
       many options are modified, translated or interpreted by the
!      compiler driver before being passed to the preprocessor, and '-Wp'
       forcibly bypasses this phase.  The preprocessor's direct interface
       is undocumented and subject to change, so whenever possible you
!      should avoid using '-Wp' and let the driver handle the options
       instead.
  
! '-Xpreprocessor OPTION'
       Pass OPTION as an option to the preprocessor.  You can use this to
       supply system-specific preprocessor options that GCC does not
       recognize.
  
       If you want to pass an option that takes an argument, you must use
!      '-Xpreprocessor' twice, once for the option and once for the
       argument.
  
! '-no-integrated-cpp'
       Perform preprocessing as a separate pass before compilation.  By
       default, GCC performs preprocessing as an integrated part of input
       tokenization and parsing.  If this option is provided, the
!      appropriate language front end ('cc1', 'cc1plus', or 'cc1obj' for
       C, C++, and Objective-C, respectively) is instead invoked twice,
       once for preprocessing only and once for actual compilation of the
       preprocessed input.  This option may be useful in conjunction with
!      the '-B' or '-wrapper' options to specify an alternate preprocessor
       or perform additional processing of the program source between
       normal preprocessing and compilation.
  
! '-flarge-source-files'
       Adjust GCC to expect large source files, at the expense of slower
       compilation and higher memory usage.
  
--- 16432,16514 ----
       result is undefined.  *Note Developer Options::, for more
       information.
  
!      ‘-dM’
!           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
  
            shows all the predefined macros.
  
!           If you use ‘-dM’ without the ‘-E’ option, ‘-dM’ is interpreted
!           as a synonym for ‘-fdump-rtl-mach’.  *Note (gcc)Developer
            Options::.
  
!      ‘-dD’
!           Like ‘-dM’ 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.
  
!      ‘-dN’
!           Like ‘-dD’, but emit only the macro names, not their
            expansions.
  
!      ‘-dI’
!           Output ‘#include’ directives in addition to the result of
            preprocessing.
  
!      ‘-dU’
!           Like ‘-dD’ 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.
  
! ‘-fdebug-cpp’
       This option is only useful for debugging GCC. When used from CPP or
!      with ‘-E’, it dumps debugging information about location maps.
       Every token in the output is preceded by the dump of the map its
       location belongs to.
  
!      When used from GCC without ‘-E’, this option has no effect.
  
! ‘-Wp,OPTION’
!      You can use ‘-Wp,OPTION’ to bypass the compiler driver and pass
       OPTION directly through to the preprocessor.  If OPTION contains
       commas, it is split into multiple options at the commas.  However,
       many options are modified, translated or interpreted by the
!      compiler driver before being passed to the preprocessor, and ‘-Wp’
       forcibly bypasses this phase.  The preprocessor's direct interface
       is undocumented and subject to change, so whenever possible you
!      should avoid using ‘-Wp’ and let the driver handle the options
       instead.
  
! ‘-Xpreprocessor OPTION’
       Pass OPTION as an option to the preprocessor.  You can use this to
       supply system-specific preprocessor options that GCC does not
       recognize.
  
       If you want to pass an option that takes an argument, you must use
!      ‘-Xpreprocessor’ twice, once for the option and once for the
       argument.
  
! ‘-no-integrated-cpp’
       Perform preprocessing as a separate pass before compilation.  By
       default, GCC performs preprocessing as an integrated part of input
       tokenization and parsing.  If this option is provided, the
!      appropriate language front end (‘cc1’, ‘cc1plus’, or ‘cc1obj’ for
       C, C++, and Objective-C, respectively) is instead invoked twice,
       once for preprocessing only and once for actual compilation of the
       preprocessed input.  This option may be useful in conjunction with
!      the ‘-B’ or ‘-wrapper’ options to specify an alternate preprocessor
       or perform additional processing of the program source between
       normal preprocessing and compilation.
  
! ‘-flarge-source-files’
       Adjust GCC to expect large source files, at the expense of slower
       compilation and higher memory usage.
  
*************** Options::.  Options to control preproces
*** 16514,16522 ****
       number of source lines, it stops tracking column numbers and only
       tracks line numbers.  This means that diagnostics for later lines
       do not include column numbers.  It also means that options like
!      '-Wmisleading-indentation' cease to work at that point, although
       the compiler prints a note if this happens.  Passing
!      '-flarge-source-files' significantly increases the number of source
       lines that GCC can process before it stops tracking columns.
  
  
--- 16518,16526 ----
       number of source lines, it stops tracking column numbers and only
       tracks line numbers.  This means that diagnostics for later lines
       do not include column numbers.  It also means that options like
!      ‘-Wmisleading-indentation’ cease to work at that point, although
       the compiler prints a note if this happens.  Passing
!      ‘-flarge-source-files’ significantly increases the number of source
       lines that GCC can process before it stops tracking columns.
  
  
*************** File: gcc.info,  Node: Assembler Options
*** 16527,16543 ****
  
  You can pass options to the assembler.
  
! '-Wa,OPTION'
       Pass OPTION as an option to the assembler.  If OPTION contains
       commas, it is split into multiple options at the commas.
  
! '-Xassembler OPTION'
       Pass OPTION as an option to the assembler.  You can use this to
       supply system-specific assembler options that GCC does not
       recognize.
  
       If you want to pass an option that takes an argument, you must use
!      '-Xassembler' twice, once for the option and once for the argument.
  
  
  File: gcc.info,  Node: Link Options,  Next: Directory Options,  Prev: Assembler Options,  Up: Invoking GCC
--- 16531,16547 ----
  
  You can pass options to the assembler.
  
! ‘-Wa,OPTION’
       Pass OPTION as an option to the assembler.  If OPTION contains
       commas, it is split into multiple options at the commas.
  
! ‘-Xassembler OPTION’
       Pass OPTION as an option to the assembler.  You can use this to
       supply system-specific assembler options that GCC does not
       recognize.
  
       If you want to pass an option that takes an argument, you must use
!      ‘-Xassembler’ twice, once for the option and once for the argument.
  
  
  File: gcc.info,  Node: Link Options,  Next: Directory Options,  Prev: Assembler Options,  Up: Invoking GCC
*************** These options come into play when the co
*** 16549,16592 ****
  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::.
  
! '-flinker-output=TYPE'
       This option controls code generation of the link-time optimizer.
       By default the linker output is automatically determined by the
       linker plugin.  For debugging the compiler and if incremental
       linking with a non-LTO object file is desired, it may be useful to
       control the type manually.
  
!      If TYPE is 'exec', code generation produces a static binary.  In
!      this case '-fpic' and '-fpie' are both disabled.
  
!      If TYPE is 'dyn', code generation produces a shared library.  In
!      this case '-fpic' or '-fPIC' is preserved, but not enabled
       automatically.  This allows to build shared libraries without
       position-independent code on architectures where this is possible,
       i.e. on x86.
  
!      If TYPE is 'pie', code generation produces an '-fpie' executable.
!      This results in similar optimizations as 'exec' except that '-fpie'
       is not disabled if specified at compilation time.
  
!      If TYPE is 'rel', the compiler assumes that incremental linking is
       done.  The sections containing intermediate code for link-time
       optimization are merged, pre-optimized, and output to the resulting
!      object file.  In addition, if '-ffat-lto-objects' is specified,
       binary code is produced for future non-LTO linking.  The object
       file produced by incremental linking is smaller than a static
       library produced from the same object files.  At link time the
--- 16553,16596 ----
  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::.
  
! ‘-flinker-output=TYPE’
       This option controls code generation of the link-time optimizer.
       By default the linker output is automatically determined by the
       linker plugin.  For debugging the compiler and if incremental
       linking with a non-LTO object file is desired, it may be useful to
       control the type manually.
  
!      If TYPE is ‘exec’, code generation produces a static binary.  In
!      this case ‘-fpic’ and ‘-fpie’ are both disabled.
  
!      If TYPE is ‘dyn’, code generation produces a shared library.  In
!      this case ‘-fpic’ or ‘-fPIC’ is preserved, but not enabled
       automatically.  This allows to build shared libraries without
       position-independent code on architectures where this is possible,
       i.e. on x86.
  
!      If TYPE is ‘pie’, code generation produces an ‘-fpie’ executable.
!      This results in similar optimizations as ‘exec’ except that ‘-fpie’
       is not disabled if specified at compilation time.
  
!      If TYPE is ‘rel’, the compiler assumes that incremental linking is
       done.  The sections containing intermediate code for link-time
       optimization are merged, pre-optimized, and output to the resulting
!      object file.  In addition, if ‘-ffat-lto-objects’ is specified,
       binary code is produced for future non-LTO linking.  The object
       file produced by incremental linking is smaller than a static
       library produced from the same object files.  At link time the
*************** doing a link step.
*** 16594,16600 ****
       library assuming that the majority of objects in the library are
       used.
  
!      Finally 'nolto-rel' configures the compiler for incremental linking
       where code generation is forced, a final binary is produced, and
       the intermediate code for later link-time optimization is stripped.
       When multiple object files are linked together the resulting code
--- 16598,16604 ----
       library assuming that the majority of objects in the library are
       used.
  
!      Finally ‘nolto-rel’ configures the compiler for incremental linking
       where code generation is forced, a final binary is produced, and
       the intermediate code for later link-time optimization is stripped.
       When multiple object files are linked together the resulting code
*************** doing a link step.
*** 16602,16911 ****
       example, cross-module inlining happens), but most of benefits of
       whole program optimizations are lost.
  
!      During the incremental link (by '-r') the linker plugin defaults to
!      'rel'.  With current interfaces to GNU Binutils it is however not
       possible to incrementally link LTO objects and non-LTO objects into
       a single mixed object file.  If any of object files in incremental
       link cannot be used for link-time optimization, the linker plugin
!      issues a warning and uses 'nolto-rel'.  To maintain whole program
       optimization, it is recommended to link such objects into static
       library instead.  Alternatively it is possible to use H.J. Lu's
       binutils with support for mixed objects.
  
! '-fuse-ld=bfd'
!      Use the 'bfd' linker instead of the default linker.
  
! '-fuse-ld=gold'
!      Use the 'gold' linker instead of the default linker.
  
! '-fuse-ld=lld'
!      Use the LLVM 'lld' linker instead of the default linker.
  
! '-fuse-ld=mold'
!      Use the Modern Linker ('mold') instead of the default linker.
  
! '-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.)
  
!      The '-l' option is passed directly to the linker by GCC. Refer to
       your linker documentation for exact details.  The general
       description below applies to the GNU linker.
  
       The linker searches a standard list of directories for the library.
       The directories searched include several standard system
!      directories plus any that you specify with '-L'.
  
       Static libraries are archives of object files, and have file names
!      like 'libLIBRARY.a'.  Some targets also support shared libraries,
!      which typically have names like 'libLIBRARY.so'.  If both static
       and shared libraries are found, the linker gives preference to
!      linking with the shared library unless the '-static' option is
       used.
  
       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.
  
! '-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',
!      '-nolibc', or '-nodefaultlibs' is used.
  
! '-nodefaultlibs'
       Do not use the standard system libraries when linking.  Only the
       libraries you specify are passed to the linker, and options
       specifying linkage of the system libraries, such as
!      '-static-libgcc' or '-shared-libgcc', are ignored.  The standard
!      startup files are used normally, unless '-nostartfiles' is used.
  
!      The compiler may generate calls to 'memcmp', 'memset', 'memcpy' and
!      'memmove'.  These entries are usually resolved by entries in libc.
       These entry points should be supplied through some other mechanism
       when this option is specified.
  
! '-nolibc'
       Do not use the C library or system libraries tightly coupled with
!      it when linking.  Still link with the startup files, 'libgcc' or
!      toolchain provided language support libraries such as 'libgnat',
!      'libgfortran' or 'libstdc++' unless options preventing their
!      inclusion are used as well.  This typically removes '-lc' from the
       link command line, as well as system libraries that normally go
       with it and become meaningless when absence of a C library is
!      assumed, for example '-lpthread' or '-lm' in some configurations.
       This is intended for bare-board targets when there is indeed no C
       library available.
  
! '-nostdlib'
       Do not use the standard system startup files or libraries when
       linking.  No startup files and only the libraries you specify are
       passed to the linker, and options specifying linkage of the system
!      libraries, such as '-static-libgcc' or '-shared-libgcc', are
       ignored.
  
!      The compiler may generate calls to 'memcmp', 'memset', 'memcpy' and
!      'memmove'.  These entries are usually resolved by entries in libc.
       These entry points should be supplied through some other mechanism
       when this option is specified.
  
!      One of the standard libraries bypassed by '-nostdlib' and
!      '-nodefaultlibs' is 'libgcc.a', a library of internal subroutines
       which GCC uses to overcome shortcomings of particular machines, or
       special needs for some languages.  (*Note Interfacing to GCC
!      Output: (gccint)Interface, for more discussion of 'libgcc.a'.)  In
!      most cases, you need 'libgcc.a' even when you want to avoid other
!      standard libraries.  In other words, when you specify '-nostdlib'
!      or '-nodefaultlibs' you should usually specify '-lgcc' as well.
       This ensures that you have no unresolved references to internal GCC
       library subroutines.  (An example of such an internal subroutine is
!      '__main', used to ensure C++ constructors are called; *note
!      'collect2': (gccint)Collect2.)
  
! '-nostdlib++'
       Do not implicitly link with standard C++ libraries.
  
! '-e ENTRY'
! '--entry=ENTRY'
  
       Specify that the program entry point is ENTRY.  The argument is
       interpreted by the linker; the GNU linker accepts either a symbol
       name or an address.
  
! '-pie'
       Produce a dynamically linked position independent executable on
       targets that support it.  For predictable results, you must also
!      specify the same set of options used for compilation ('-fpie',
!      '-fPIE', or model suboptions) when you specify this linker option.
  
! '-no-pie'
       Don't produce a dynamically linked position independent executable.
  
! '-static-pie'
       Produce a static position independent executable on targets that
       support it.  A static position independent executable is similar to
       a static executable, but can be loaded at any address without a
       dynamic linker.  For predictable results, you must also specify the
!      same set of options used for compilation ('-fpie', '-fPIE', or
       model suboptions) when you specify this linker option.
  
! '-pthread'
       Link with the POSIX threads library.  This option is supported on
       GNU/Linux targets, most other Unix derivatives, and also on x86
       Cygwin and MinGW targets.  On some targets this option also sets
       flags for the preprocessor, so it should be used consistently for
       both compilation and linking.
  
! '-r'
       Produce a relocatable object as output.  This is also known as
       partial linking.
  
! '-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 overrides '-pie' and
       prevents linking with the shared libraries.  On other systems, this
       option has no effect.
  
! '-shared'
       Produce a shared object which can then be linked with other objects
       to form an executable.  Not all systems support this option.  For
       predictable results, you must also specify the same set of options
!      used for compilation ('-fpic', '-fPIC', or model suboptions) when
       you specify this linker option.(1)
  
! '-shared-libgcc'
! '-static-libgcc'
!      On systems that provide 'libgcc' as a shared library, these options
       force the use of either the shared or static version, respectively.
!      If no shared version of 'libgcc' was built when the compiler was
       configured, these options have no effect.
  
       There are several situations in which an application should use the
!      shared 'libgcc' instead of the static version.  The most common of
       these is when the application wishes to throw and catch exceptions
       across different shared libraries.  In that case, each of the
       libraries as well as the application itself should use the shared
!      'libgcc'.
  
!      Therefore, the G++ driver automatically adds '-shared-libgcc'
       whenever you build a shared library or a main executable, because
       C++ programs typically use exceptions, so this is the right thing
       to do.
  
       If, instead, you use the GCC driver to create shared libraries, you
!      may find that they are not always linked with the shared 'libgcc'.
       If GCC finds, at its configuration time, that you have a non-GNU
       linker or a GNU linker that does not support option
!      '--eh-frame-hdr', it links the shared version of 'libgcc' into
       shared libraries by default.  Otherwise, it takes advantage of the
       linker and optimizes away the linking with the shared version of
!      'libgcc', linking with the static version of libgcc by default.
       This allows exceptions to propagate through such shared libraries,
       without incurring relocation costs at library load time.
  
       However, if a library or main executable is supposed to throw or
       catch exceptions, you must link it using the G++ driver, or using
!      the option '-shared-libgcc', such that it is linked with the shared
!      'libgcc'.
  
! '-static-libasan'
!      When the '-fsanitize=address' option is used to link a program, the
!      GCC driver automatically links against 'libasan'.  If 'libasan' is
!      available as a shared library, and the '-static' option is not
!      used, then this links against the shared version of 'libasan'.  The
!      '-static-libasan' option directs the GCC driver to link 'libasan'
       statically, without necessarily linking other libraries statically.
  
! '-static-libtsan'
!      When the '-fsanitize=thread' option is used to link a program, the
!      GCC driver automatically links against 'libtsan'.  If 'libtsan' is
!      available as a shared library, and the '-static' option is not
!      used, then this links against the shared version of 'libtsan'.  The
!      '-static-libtsan' option directs the GCC driver to link 'libtsan'
       statically, without necessarily linking other libraries statically.
  
! '-static-liblsan'
!      When the '-fsanitize=leak' option is used to link a program, the
!      GCC driver automatically links against 'liblsan'.  If 'liblsan' is
!      available as a shared library, and the '-static' option is not
!      used, then this links against the shared version of 'liblsan'.  The
!      '-static-liblsan' option directs the GCC driver to link 'liblsan'
       statically, without necessarily linking other libraries statically.
  
! '-static-libubsan'
!      When the '-fsanitize=undefined' option is used to link a program,
!      the GCC driver automatically links against 'libubsan'.  If
!      'libubsan' is available as a shared library, and the '-static'
       option is not used, then this links against the shared version of
!      'libubsan'.  The '-static-libubsan' option directs the GCC driver
!      to link 'libubsan' statically, without necessarily linking other
       libraries statically.
  
! '-static-libstdc++'
!      When the 'g++' program is used to link a C++ program, it normally
!      automatically links against 'libstdc++'.  If 'libstdc++' is
!      available as a shared library, and the '-static' option is not
!      used, then this links against the shared version of 'libstdc++'.
       That is normally fine.  However, it is sometimes useful to freeze
!      the version of 'libstdc++' used by the program without going all
!      the way to a fully static link.  The '-static-libstdc++' option
!      directs the 'g++' driver to link 'libstdc++' statically, without
       necessarily linking other libraries statically.
  
! '-symbolic'
       Bind references to global symbols when building a shared object.
       Warn about any unresolved references (unless overridden by the link
!      editor option '-Xlinker -z -Xlinker defs').  Only a few systems
       support this option.
  
! '-T SCRIPT'
       Use SCRIPT as the linker script.  This option is supported by most
       systems using the GNU linker.  On some targets, such as bare-board
!      targets without an operating system, the '-T' option may be
       required when linking to avoid references to undefined symbols.
  
! '-Xlinker OPTION'
       Pass OPTION as an option to the linker.  You can use this to supply
       system-specific linker options that GCC does not recognize.
  
       If you want to pass an option that takes a separate argument, you
!      must use '-Xlinker' twice, once for the option and once for the
!      argument.  For example, to pass '-assert definitions', you must
!      write '-Xlinker -assert -Xlinker definitions'.  It does not work to
!      write '-Xlinker "-assert definitions"', because this passes the
       entire string as a single argument, which is not what the linker
       expects.
  
       When using the GNU linker, it is usually more convenient to pass
!      arguments to linker options using the 'OPTION=VALUE' syntax than as
!      separate arguments.  For example, you can specify '-Xlinker
!      -Map=output.map' rather than '-Xlinker -Map -Xlinker output.map'.
       Other linkers may not support this syntax for command-line options.
  
! '-Wl,OPTION'
       Pass OPTION as an option to the linker.  If OPTION contains commas,
       it is split into multiple options at the commas.  You can use this
       syntax to pass an argument to the option.  For example,
!      '-Wl,-Map,output.map' passes '-Map output.map' to the linker.  When
       using the GNU linker, you can also get the same effect with
!      '-Wl,-Map=output.map'.
  
! '-u SYMBOL'
       Pretend the symbol SYMBOL is undefined, to force linking of library
!      modules to define it.  You can use '-u' multiple times with
       different symbols to force loading of additional library modules.
  
! '-z KEYWORD'
!      '-z' is passed directly on to the linker along with the keyword
       KEYWORD.  See the section in the documentation of your linker for
       permitted values and their meanings.
  
     ---------- 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.  '-shared' suppresses
  the addition of startup code to alter the floating-point environment as
! done with '-ffast-math', '-Ofast' or '-funsafe-math-optimizations' on
  some targets.
  
  
--- 16606,16915 ----
       example, cross-module inlining happens), but most of benefits of
       whole program optimizations are lost.
  
!      During the incremental link (by ‘-r’) the linker plugin defaults to
!      ‘rel’.  With current interfaces to GNU Binutils it is however not
       possible to incrementally link LTO objects and non-LTO objects into
       a single mixed object file.  If any of object files in incremental
       link cannot be used for link-time optimization, the linker plugin
!      issues a warning and uses ‘nolto-rel’.  To maintain whole program
       optimization, it is recommended to link such objects into static
       library instead.  Alternatively it is possible to use H.J. Lu's
       binutils with support for mixed objects.
  
! ‘-fuse-ld=bfd’
!      Use the ‘bfd’ linker instead of the default linker.
  
! ‘-fuse-ld=gold’
!      Use the ‘gold’ linker instead of the default linker.
  
! ‘-fuse-ld=lld’
!      Use the LLVM ‘lld’ linker instead of the default linker.
  
! ‘-fuse-ld=mold’
!      Use the Modern Linker (‘mold’) instead of the default linker.
  
! ‘-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.)
  
!      The ‘-l’ option is passed directly to the linker by GCC. Refer to
       your linker documentation for exact details.  The general
       description below applies to the GNU linker.
  
       The linker searches a standard list of directories for the library.
       The directories searched include several standard system
!      directories plus any that you specify with ‘-L’.
  
       Static libraries are archives of object files, and have file names
!      like ‘libLIBRARY.a’.  Some targets also support shared libraries,
!      which typically have names like ‘libLIBRARY.so’.  If both static
       and shared libraries are found, the linker gives preference to
!      linking with the shared library unless the ‘-static’ option is
       used.
  
       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.
  
! ‘-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’,
!      ‘-nolibc’, or ‘-nodefaultlibs’ is used.
  
! ‘-nodefaultlibs’
       Do not use the standard system libraries when linking.  Only the
       libraries you specify are passed to the linker, and options
       specifying linkage of the system libraries, such as
!      ‘-static-libgcc’ or ‘-shared-libgcc’, are ignored.  The standard
!      startup files are used normally, unless ‘-nostartfiles’ is used.
  
!      The compiler may generate calls to ‘memcmp’, ‘memset’, ‘memcpy’ and
!      ‘memmove’.  These entries are usually resolved by entries in libc.
       These entry points should be supplied through some other mechanism
       when this option is specified.
  
! ‘-nolibc’
       Do not use the C library or system libraries tightly coupled with
!      it when linking.  Still link with the startup files, ‘libgcc’ or
!      toolchain provided language support libraries such as ‘libgnat’,
!      ‘libgfortran’ or ‘libstdc++’ unless options preventing their
!      inclusion are used as well.  This typically removes ‘-lc’ from the
       link command line, as well as system libraries that normally go
       with it and become meaningless when absence of a C library is
!      assumed, for example ‘-lpthread’ or ‘-lm’ in some configurations.
       This is intended for bare-board targets when there is indeed no C
       library available.
  
! ‘-nostdlib’
       Do not use the standard system startup files or libraries when
       linking.  No startup files and only the libraries you specify are
       passed to the linker, and options specifying linkage of the system
!      libraries, such as ‘-static-libgcc’ or ‘-shared-libgcc’, are
       ignored.
  
!      The compiler may generate calls to ‘memcmp’, ‘memset’, ‘memcpy’ and
!      ‘memmove’.  These entries are usually resolved by entries in libc.
       These entry points should be supplied through some other mechanism
       when this option is specified.
  
!      One of the standard libraries bypassed by ‘-nostdlib’ and
!      ‘-nodefaultlibs’ is ‘libgcc.a’, a library of internal subroutines
       which GCC uses to overcome shortcomings of particular machines, or
       special needs for some languages.  (*Note Interfacing to GCC
!      Output: (gccint)Interface, for more discussion of ‘libgcc.a’.)  In
!      most cases, you need ‘libgcc.a’ even when you want to avoid other
!      standard libraries.  In other words, when you specify ‘-nostdlib’
!      or ‘-nodefaultlibs’ you should usually specify ‘-lgcc’ as well.
       This ensures that you have no unresolved references to internal GCC
       library subroutines.  (An example of such an internal subroutine is
!      ‘__main’, used to ensure C++ constructors are called; *note
!      ‘collect2’: (gccint)Collect2.)
  
! ‘-nostdlib++’
       Do not implicitly link with standard C++ libraries.
  
! ‘-e ENTRY’
! ‘--entry=ENTRY’
  
       Specify that the program entry point is ENTRY.  The argument is
       interpreted by the linker; the GNU linker accepts either a symbol
       name or an address.
  
! ‘-pie’
       Produce a dynamically linked position independent executable on
       targets that support it.  For predictable results, you must also
!      specify the same set of options used for compilation (‘-fpie’,
!      ‘-fPIE’, or model suboptions) when you specify this linker option.
  
! ‘-no-pie’
       Don't produce a dynamically linked position independent executable.
  
! ‘-static-pie’
       Produce a static position independent executable on targets that
       support it.  A static position independent executable is similar to
       a static executable, but can be loaded at any address without a
       dynamic linker.  For predictable results, you must also specify the
!      same set of options used for compilation (‘-fpie’, ‘-fPIE’, or
       model suboptions) when you specify this linker option.
  
! ‘-pthread’
       Link with the POSIX threads library.  This option is supported on
       GNU/Linux targets, most other Unix derivatives, and also on x86
       Cygwin and MinGW targets.  On some targets this option also sets
       flags for the preprocessor, so it should be used consistently for
       both compilation and linking.
  
! ‘-r’
       Produce a relocatable object as output.  This is also known as
       partial linking.
  
! ‘-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 overrides ‘-pie’ and
       prevents linking with the shared libraries.  On other systems, this
       option has no effect.
  
! ‘-shared’
       Produce a shared object which can then be linked with other objects
       to form an executable.  Not all systems support this option.  For
       predictable results, you must also specify the same set of options
!      used for compilation (‘-fpic’, ‘-fPIC’, or model suboptions) when
       you specify this linker option.(1)
  
! ‘-shared-libgcc’
! ‘-static-libgcc’
!      On systems that provide ‘libgcc’ as a shared library, these options
       force the use of either the shared or static version, respectively.
!      If no shared version of ‘libgcc’ was built when the compiler was
       configured, these options have no effect.
  
       There are several situations in which an application should use the
!      shared ‘libgcc’ instead of the static version.  The most common of
       these is when the application wishes to throw and catch exceptions
       across different shared libraries.  In that case, each of the
       libraries as well as the application itself should use the shared
!      ‘libgcc’.
  
!      Therefore, the G++ driver automatically adds ‘-shared-libgcc’
       whenever you build a shared library or a main executable, because
       C++ programs typically use exceptions, so this is the right thing
       to do.
  
       If, instead, you use the GCC driver to create shared libraries, you
!      may find that they are not always linked with the shared ‘libgcc’.
       If GCC finds, at its configuration time, that you have a non-GNU
       linker or a GNU linker that does not support option
!      ‘--eh-frame-hdr’, it links the shared version of ‘libgcc’ into
       shared libraries by default.  Otherwise, it takes advantage of the
       linker and optimizes away the linking with the shared version of
!      ‘libgcc’, linking with the static version of libgcc by default.
       This allows exceptions to propagate through such shared libraries,
       without incurring relocation costs at library load time.
  
       However, if a library or main executable is supposed to throw or
       catch exceptions, you must link it using the G++ driver, or using
!      the option ‘-shared-libgcc’, such that it is linked with the shared
!      ‘libgcc’.
  
! ‘-static-libasan’
!      When the ‘-fsanitize=address’ option is used to link a program, the
!      GCC driver automatically links against ‘libasan’.  If ‘libasan’ is
!      available as a shared library, and the ‘-static’ option is not
!      used, then this links against the shared version of ‘libasan’.  The
!      ‘-static-libasan’ option directs the GCC driver to link ‘libasan’
       statically, without necessarily linking other libraries statically.
  
! ‘-static-libtsan’
!      When the ‘-fsanitize=thread’ option is used to link a program, the
!      GCC driver automatically links against ‘libtsan’.  If ‘libtsan’ is
!      available as a shared library, and the ‘-static’ option is not
!      used, then this links against the shared version of ‘libtsan’.  The
!      ‘-static-libtsan’ option directs the GCC driver to link ‘libtsan’
       statically, without necessarily linking other libraries statically.
  
! ‘-static-liblsan’
!      When the ‘-fsanitize=leak’ option is used to link a program, the
!      GCC driver automatically links against ‘liblsan’.  If ‘liblsan’ is
!      available as a shared library, and the ‘-static’ option is not
!      used, then this links against the shared version of ‘liblsan’.  The
!      ‘-static-liblsan’ option directs the GCC driver to link ‘liblsan’
       statically, without necessarily linking other libraries statically.
  
! ‘-static-libubsan’
!      When the ‘-fsanitize=undefined’ option is used to link a program,
!      the GCC driver automatically links against ‘libubsan’.  If
!      ‘libubsan’ is available as a shared library, and the ‘-static’
       option is not used, then this links against the shared version of
!      ‘libubsan’.  The ‘-static-libubsan’ option directs the GCC driver
!      to link ‘libubsan’ statically, without necessarily linking other
       libraries statically.
  
! ‘-static-libstdc++’
!      When the ‘g++’ program is used to link a C++ program, it normally
!      automatically links against ‘libstdc++’.  If ‘libstdc++’ is
!      available as a shared library, and the ‘-static’ option is not
!      used, then this links against the shared version of ‘libstdc++’.
       That is normally fine.  However, it is sometimes useful to freeze
!      the version of ‘libstdc++’ used by the program without going all
!      the way to a fully static link.  The ‘-static-libstdc++’ option
!      directs the ‘g++’ driver to link ‘libstdc++’ statically, without
       necessarily linking other libraries statically.
  
! ‘-symbolic’
       Bind references to global symbols when building a shared object.
       Warn about any unresolved references (unless overridden by the link
!      editor option ‘-Xlinker -z -Xlinker defs’).  Only a few systems
       support this option.
  
! ‘-T SCRIPT’
       Use SCRIPT as the linker script.  This option is supported by most
       systems using the GNU linker.  On some targets, such as bare-board
!      targets without an operating system, the ‘-T’ option may be
       required when linking to avoid references to undefined symbols.
  
! ‘-Xlinker OPTION’
       Pass OPTION as an option to the linker.  You can use this to supply
       system-specific linker options that GCC does not recognize.
  
       If you want to pass an option that takes a separate argument, you
!      must use ‘-Xlinker’ twice, once for the option and once for the
!      argument.  For example, to pass ‘-assert definitions’, you must
!      write ‘-Xlinker -assert -Xlinker definitions’.  It does not work to
!      write ‘-Xlinker "-assert definitions"’, because this passes the
       entire string as a single argument, which is not what the linker
       expects.
  
       When using the GNU linker, it is usually more convenient to pass
!      arguments to linker options using the ‘OPTION=VALUE’ syntax than as
!      separate arguments.  For example, you can specify ‘-Xlinker
!      -Map=output.map’ rather than ‘-Xlinker -Map -Xlinker output.map’.
       Other linkers may not support this syntax for command-line options.
  
! ‘-Wl,OPTION’
       Pass OPTION as an option to the linker.  If OPTION contains commas,
       it is split into multiple options at the commas.  You can use this
       syntax to pass an argument to the option.  For example,
!      ‘-Wl,-Map,output.map’ passes ‘-Map output.map’ to the linker.  When
       using the GNU linker, you can also get the same effect with
!      ‘-Wl,-Map=output.map’.
  
! ‘-u SYMBOL’
       Pretend the symbol SYMBOL is undefined, to force linking of library
!      modules to define it.  You can use ‘-u’ multiple times with
       different symbols to force loading of additional library modules.
  
! ‘-z KEYWORD’
!      ‘-z’ is passed directly on to the linker along with the keyword
       KEYWORD.  See the section in the documentation of your linker for
       permitted values and their meanings.
  
     ---------- 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.  ‘-shared’ suppresses
  the addition of startup code to alter the floating-point environment as
! done with ‘-ffast-math’, ‘-Ofast’ or ‘-funsafe-math-optimizations’ on
  some targets.
  
  
*************** File: gcc.info,  Node: Directory Options
*** 16917,16935 ****
  These options specify directories to search for header files, for
  libraries and for parts of the compiler:
  
! '-I DIR'
! '-iquote DIR'
! '-isystem DIR'
! '-idirafter DIR'
       Add the directory DIR to the list of directories to be searched for
!      header files during preprocessing.  If DIR begins with '=' or
!      '$SYSROOT', then the '=' or '$SYSROOT' is replaced by the sysroot
!      prefix; see '--sysroot' and '-isysroot'.
  
!      Directories specified with '-iquote' apply only to the quote form
!      of the directive, '#include "FILE"'.  Directories specified with
!      '-I', '-isystem', or '-idirafter' apply to lookup for both the
!      '#include "FILE"' and '#include ' directives.
  
       You can specify any number or combination of these options on the
       command line to search for header files in several directories.
--- 16921,16939 ----
  These options specify directories to search for header files, for
  libraries and for parts of the compiler:
  
! ‘-I DIR’
! ‘-iquote DIR’
! ‘-isystem DIR’
! ‘-idirafter DIR’
       Add the directory DIR to the list of directories to be searched for
!      header files during preprocessing.  If DIR begins with ‘=’ or
!      ‘$SYSROOT’, then the ‘=’ or ‘$SYSROOT’ is replaced by the sysroot
!      prefix; see ‘--sysroot’ and ‘-isysroot’.
  
!      Directories specified with ‘-iquote’ apply only to the quote form
!      of the directive, ‘#include "FILE"’.  Directories specified with
!      ‘-I’, ‘-isystem’, or ‘-idirafter’ apply to lookup for both the
!      ‘#include "FILE"’ and ‘#include ’ directives.
  
       You can specify any number or combination of these options on the
       command line to search for header files in several directories.
*************** libraries and for parts of the compiler:
*** 16939,17100 ****
            the current file is searched first.
  
         2. For the quote form of the include directive, the directories
!           specified by '-iquote' options are searched in left-to-right
            order, as they appear on the command line.
  
!        3. Directories specified with '-I' options are scanned in
            left-to-right order.
  
!        4. Directories specified with '-isystem' options are scanned in
            left-to-right order.
  
         5. Standard system directories are scanned.
  
!        6. Directories specified with '-idirafter' options are scanned in
            left-to-right order.
  
!      You can use '-I' to override a system header file, substituting
       your own version, since these directories are searched before the
       standard 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.
  
!      The '-isystem' and '-idirafter' options also mark the directory as
       a system directory, so that it gets the same special treatment that
       is applied to the standard system directories.
  
       If a standard system include directory, or a directory specified
!      with '-isystem', is also specified with '-I', the '-I' option is
       ignored.  The directory is still searched but as a system directory
       at its normal position in the system include chain.  This is to
       ensure that GCC's procedure to fix buggy system headers and the
!      ordering for the '#include_next' directive are not inadvertently
       changed.  If you really need to change the search order for system
!      directories, use the '-nostdinc' and/or '-isystem' options.
  
! '-I-'
       Split the include path.  This option has been deprecated.  Please
!      use '-iquote' instead for '-I' directories before the '-I-' and
!      remove the '-I-' option.
  
!      Any directories specified with '-I' options before '-I-' are
!      searched only for headers requested with '#include "FILE"'; they
!      are not searched for '#include '.  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"'.
!      There is no way to override this effect of '-I-'.
  
! '-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.
  
! '-nostdinc'
       Do not search the standard system directories for header files.
!      Only the directories explicitly specified with '-I', '-iquote',
!      '-isystem', and/or '-idirafter' 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.)
  
! '-iplugindir=DIR'
       Set the directory to search for plugins that are passed by
!      '-fplugin=NAME' instead of '-fplugin=PATH/NAME.so'.  This option is
       not meant to be used by the user, but only passed by the driver.
  
! '-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/'
       for the corresponding target machine and compiler version.
  
       For each subprogram to be run, the compiler driver first tries the
!      '-B' prefix, if any.  If that name is not found, or if '-B' is not
!      specified, the driver tries two standard prefixes, '/usr/lib/gcc/'
!      and '/usr/local/lib/gcc/'.  If neither of those results in a file
       name that is found, the unmodified program name is searched for
!      using the directories specified in your 'PATH' environment
       variable.
  
!      The compiler checks to see if the path provided by '-B' refers to a
       directory, and if necessary it adds a directory separator character
       at the end of the path.
  
!      '-B' prefixes that effectively specify directory names also apply
       to libraries in the linker, because the compiler translates these
!      options into '-L' options for the linker.  They also apply to
       include files in the preprocessor, because the compiler translates
!      these options into '-isystem' options for the preprocessor.  In
!      this case, the compiler appends 'include' to the prefix.
  
!      The runtime support file 'libgcc.a' can also be searched for using
!      the '-B' prefix, if needed.  If it is not found there, the two
       standard prefixes above are tried, and that is all.  The file is
       left out of the link if it is not found by those means.
  
!      Another way to specify a prefix much like the '-B' prefix is to use
!      the environment variable 'GCC_EXEC_PREFIX'.  *Note Environment
       Variables::.
  
!      As a special kludge, if the path provided by '-B' is
!      '[dir/]stageN/', where N is a number in the range 0 to 9, then it
!      is replaced by '[dir/]include'.  This is to help with
       boot-strapping the compiler.
  
! '-no-canonical-prefixes'
!      Do not expand any symbolic links, resolve references to '/../' or
!      '/./', or make the path absolute when generating a relative prefix.
  
! '--sysroot=DIR'
       Use DIR as the logical root directory for headers and libraries.
       For example, if the compiler normally searches for headers in
!      '/usr/include' and libraries in '/usr/lib', it instead searches
!      'DIR/usr/include' and 'DIR/usr/lib'.
  
!      If you use both this option and the '-isysroot' option, then the
!      '--sysroot' option applies to libraries, but the '-isysroot' option
       applies to header files.
  
       The GNU linker (beginning with version 2.16) has the necessary
       support for this option.  If your linker does not support this
!      option, the header file aspect of '--sysroot' still works, but the
       library aspect does not.
  
! '--no-sysroot-suffix'
       For some targets, a suffix is added to the root directory specified
!      with '--sysroot', depending on the other options used, so that
!      headers may for example be found in 'DIR/SUFFIX/usr/include'
!      instead of 'DIR/usr/include'.  This option disables the addition of
       such a suffix.
  
  
--- 16943,17104 ----
            the current file is searched first.
  
         2. For the quote form of the include directive, the directories
!           specified by ‘-iquote’ options are searched in left-to-right
            order, as they appear on the command line.
  
!        3. Directories specified with ‘-I’ options are scanned in
            left-to-right order.
  
!        4. Directories specified with ‘-isystem’ options are scanned in
            left-to-right order.
  
         5. Standard system directories are scanned.
  
!        6. Directories specified with ‘-idirafter’ options are scanned in
            left-to-right order.
  
!      You can use ‘-I’ to override a system header file, substituting
       your own version, since these directories are searched before the
       standard 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.
  
!      The ‘-isystem’ and ‘-idirafter’ options also mark the directory as
       a system directory, so that it gets the same special treatment that
       is applied to the standard system directories.
  
       If a standard system include directory, or a directory specified
!      with ‘-isystem’, is also specified with ‘-I’, the ‘-I’ option is
       ignored.  The directory is still searched but as a system directory
       at its normal position in the system include chain.  This is to
       ensure that GCC's procedure to fix buggy system headers and the
!      ordering for the ‘#include_next’ directive are not inadvertently
       changed.  If you really need to change the search order for system
!      directories, use the ‘-nostdinc’ and/or ‘-isystem’ options.
  
! ‘-I-’
       Split the include path.  This option has been deprecated.  Please
!      use ‘-iquote’ instead for ‘-I’ directories before the ‘-I-’ and
!      remove the ‘-I-’ option.
  
!      Any directories specified with ‘-I’ options before ‘-I-’ are
!      searched only for headers requested with ‘#include "FILE"’; they
!      are not searched for ‘#include ’.  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"’.
!      There is no way to override this effect of ‘-I-’.
  
! ‘-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.
  
! ‘-nostdinc’
       Do not search the standard system directories for header files.
!      Only the directories explicitly specified with ‘-I’, ‘-iquote’,
!      ‘-isystem’, and/or ‘-idirafter’ 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.)
  
! ‘-iplugindir=DIR’
       Set the directory to search for plugins that are passed by
!      ‘-fplugin=NAME’ instead of ‘-fplugin=PATH/NAME.so’.  This option is
       not meant to be used by the user, but only passed by the driver.
  
! ‘-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/’
       for the corresponding target machine and compiler version.
  
       For each subprogram to be run, the compiler driver first tries the
!      ‘-B’ prefix, if any.  If that name is not found, or if ‘-B’ is not
!      specified, the driver tries two standard prefixes, ‘/usr/lib/gcc/’
!      and ‘/usr/local/lib/gcc/’.  If neither of those results in a file
       name that is found, the unmodified program name is searched for
!      using the directories specified in your ‘PATH’ environment
       variable.
  
!      The compiler checks to see if the path provided by ‘-B’ refers to a
       directory, and if necessary it adds a directory separator character
       at the end of the path.
  
!      ‘-B’ prefixes that effectively specify directory names also apply
       to libraries in the linker, because the compiler translates these
!      options into ‘-L’ options for the linker.  They also apply to
       include files in the preprocessor, because the compiler translates
!      these options into ‘-isystem’ options for the preprocessor.  In
!      this case, the compiler appends ‘include’ to the prefix.
  
!      The runtime support file ‘libgcc.a’ can also be searched for using
!      the ‘-B’ prefix, if needed.  If it is not found there, the two
       standard prefixes above are tried, and that is all.  The file is
       left out of the link if it is not found by those means.
  
!      Another way to specify a prefix much like the ‘-B’ prefix is to use
!      the environment variable ‘GCC_EXEC_PREFIX’.  *Note Environment
       Variables::.
  
!      As a special kludge, if the path provided by ‘-B’ is
!      ‘[dir/]stageN/’, where N is a number in the range 0 to 9, then it
!      is replaced by ‘[dir/]include’.  This is to help with
       boot-strapping the compiler.
  
! ‘-no-canonical-prefixes’
!      Do not expand any symbolic links, resolve references to ‘/../’ or
!      ‘/./’, or make the path absolute when generating a relative prefix.
  
! ‘--sysroot=DIR’
       Use DIR as the logical root directory for headers and libraries.
       For example, if the compiler normally searches for headers in
!      ‘/usr/include’ and libraries in ‘/usr/lib’, it instead searches
!      ‘DIR/usr/include’ and ‘DIR/usr/lib’.
  
!      If you use both this option and the ‘-isysroot’ option, then the
!      ‘--sysroot’ option applies to libraries, but the ‘-isysroot’ option
       applies to header files.
  
       The GNU linker (beginning with version 2.16) has the necessary
       support for this option.  If your linker does not support this
!      option, the header file aspect of ‘--sysroot’ still works, but the
       library aspect does not.
  
! ‘--no-sysroot-suffix’
       For some targets, a suffix is added to the root directory specified
!      with ‘--sysroot’, depending on the other options used, so that
!      headers may for example be found in ‘DIR/SUFFIX/usr/include’
!      instead of ‘DIR/usr/include’.  This option disables the addition of
       such a suffix.
  
  
*************** These machine-independent options contro
*** 17107,17123 ****
  in code generation.
  
   Most of them have both positive and negative forms; the negative form
! of '-ffoo' is '-fno-foo'.  In the table below, only one of the forms is
  listed--the one that is not the default.  You can figure out the other
! form by either removing 'no-' or adding it.
  
! '-fstack-reuse=REUSE-LEVEL'
       This option controls stack space reuse for user declared local/auto
       variables and compiler generated temporaries.  REUSE_LEVEL can be
!      'all', 'named_vars', or 'none'.  'all' enables stack reuse for all
!      local variables and temporaries, 'named_vars' enables the reuse
!      only for user defined local variables with names, and 'none'
!      disables stack reuse completely.  The default value is 'all'.  The
       option is needed when the program extends the lifetime of a scoped
       local variable or a compiler generated temporary beyond the end
       point defined by the language.  When a lifetime of a variable ends,
--- 17111,17127 ----
  in code generation.
  
   Most of them have both positive and negative forms; the negative form
! of ‘-ffoo’ is ‘-fno-foo’.  In the table below, only one of the forms is
  listed--the one that is not the default.  You can figure out the other
! form by either removing ‘no-’ or adding it.
  
! ‘-fstack-reuse=REUSE-LEVEL’
       This option controls stack space reuse for user declared local/auto
       variables and compiler generated temporaries.  REUSE_LEVEL can be
!      ‘all’, ‘named_vars’, or ‘none’.  ‘all’ enables stack reuse for all
!      local variables and temporaries, ‘named_vars’ enables the reuse
!      only for user defined local variables with names, and ‘none’
!      disables stack reuse completely.  The default value is ‘all’.  The
       option is needed when the program extends the lifetime of a scoped
       local variable or a compiler generated temporary beyond the end
       point defined by the language.  When a lifetime of a variable ends,
*************** form by either removing 'no-' or adding
*** 17187,17221 ****
       reuse can lead to runtime errors.  This option is used to control
       the temporary stack reuse optimization.
  
! '-ftrapv'
       This option generates traps for signed overflow on addition,
!      subtraction, multiplication operations.  The options '-ftrapv' and
!      '-fwrapv' override each other, so using '-ftrapv' '-fwrapv' on the
!      command-line results in '-fwrapv' being effective.  Note that only
!      active options override, so using '-ftrapv' '-fwrapv' '-fno-wrapv'
!      on the command-line results in '-ftrapv' being effective.
  
! '-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.  The options '-ftrapv' and
!      '-fwrapv' override each other, so using '-ftrapv' '-fwrapv' on the
!      command-line results in '-fwrapv' being effective.  Note that only
!      active options override, so using '-ftrapv' '-fwrapv' '-fno-wrapv'
!      on the command-line results in '-ftrapv' being effective.
  
! '-fwrapv-pointer'
       This option instructs the compiler to assume that pointer
       arithmetic overflow on addition and subtraction wraps around using
       twos-complement representation.  This flag disables some
       optimizations which assume pointer overflow is invalid.
  
! '-fstrict-overflow'
!      This option implies '-fno-wrapv' '-fno-wrapv-pointer' and when
!      negated implies '-fwrapv' '-fwrapv-pointer'.
  
! '-fexceptions'
       Enable exception handling.  Generates extra code needed to
       propagate exceptions.  For some targets, this implies GCC generates
       frame unwind information for all functions, which can produce
--- 17191,17225 ----
       reuse can lead to runtime errors.  This option is used to control
       the temporary stack reuse optimization.
  
! ‘-ftrapv’
       This option generates traps for signed overflow on addition,
!      subtraction, multiplication operations.  The options ‘-ftrapv’ and
!      ‘-fwrapv’ override each other, so using ‘-ftrapv’ ‘-fwrapv’ on the
!      command-line results in ‘-fwrapv’ being effective.  Note that only
!      active options override, so using ‘-ftrapv’ ‘-fwrapv’ ‘-fno-wrapv’
!      on the command-line results in ‘-ftrapv’ being effective.
  
! ‘-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.  The options ‘-ftrapv’ and
!      ‘-fwrapv’ override each other, so using ‘-ftrapv’ ‘-fwrapv’ on the
!      command-line results in ‘-fwrapv’ being effective.  Note that only
!      active options override, so using ‘-ftrapv’ ‘-fwrapv’ ‘-fno-wrapv’
!      on the command-line results in ‘-ftrapv’ being effective.
  
! ‘-fwrapv-pointer’
       This option instructs the compiler to assume that pointer
       arithmetic overflow on addition and subtraction wraps around using
       twos-complement representation.  This flag disables some
       optimizations which assume pointer overflow is invalid.
  
! ‘-fstrict-overflow’
!      This option implies ‘-fno-wrapv’ ‘-fno-wrapv-pointer’ and when
!      negated implies ‘-fwrapv’ ‘-fwrapv-pointer’.
  
! ‘-fexceptions’
       Enable exception handling.  Generates extra code needed to
       propagate exceptions.  For some targets, this implies GCC generates
       frame unwind information for all functions, which can produce
*************** form by either removing 'no-' or adding
*** 17229,17281 ****
       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'.  This
!      enables '-fexceptions'.
  
! '-fdelete-dead-exceptions'
       Consider that instructions that may throw exceptions but don't
       otherwise contribute to the execution of the program can be
       optimized away.  This does not affect calls to functions except
!      those with the 'pure' or 'const' attributes.  This option is
       enabled by default for the Ada and C++ compilers, as permitted by
       the language specifications.  Optimization passes that cause dead
       exceptions to be removed are enabled independently at different
       optimization levels.
  
! '-funwind-tables'
!      Similar to '-fexceptions', except that it just generates any needed
       static data, but does not affect the generated code in any other
       way.  You normally do not need to enable this option; instead, a
       language processor that needs this handling enables it on your
       behalf.
  
! '-fasynchronous-unwind-tables'
       Generate unwind table in DWARF format, if supported by target
       machine.  The table is exact at each instruction boundary, so it
       can be used for stack unwinding from asynchronous events (such as
       debugger or garbage collector).
  
! '-fno-gnu-unique'
       On systems with recent GNU assembler and C library, the C++
!      compiler uses the 'STB_GNU_UNIQUE' binding to make sure that
       definitions of template static data members and static local
       variables in inline functions are unique even in the presence of
!      'RTLD_LOCAL'; this is necessary to avoid problems with a library
!      used by two different 'RTLD_LOCAL' plugins depending on a
       definition in one of them and therefore disagreeing with the other
!      one about the binding of the symbol.  But this causes 'dlclose' to
       be ignored for affected DSOs; if your program relies on
!      reinitialization of a DSO via 'dlclose' and 'dlopen', you can use
!      '-fno-gnu-unique'.
  
! '-fpcc-struct-return'
!      Return "short" 'struct' and 'union' values in memory like longer
       ones, rather than in registers.  This convention is less efficient,
       but it has the advantage of allowing intercallability between
       GCC-compiled files and files compiled with other compilers,
--- 17233,17285 ----
       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’.  This
!      enables ‘-fexceptions’.
  
! ‘-fdelete-dead-exceptions’
       Consider that instructions that may throw exceptions but don't
       otherwise contribute to the execution of the program can be
       optimized away.  This does not affect calls to functions except
!      those with the ‘pure’ or ‘const’ attributes.  This option is
       enabled by default for the Ada and C++ compilers, as permitted by
       the language specifications.  Optimization passes that cause dead
       exceptions to be removed are enabled independently at different
       optimization levels.
  
! ‘-funwind-tables’
!      Similar to ‘-fexceptions’, except that it just generates any needed
       static data, but does not affect the generated code in any other
       way.  You normally do not need to enable this option; instead, a
       language processor that needs this handling enables it on your
       behalf.
  
! ‘-fasynchronous-unwind-tables’
       Generate unwind table in DWARF format, if supported by target
       machine.  The table is exact at each instruction boundary, so it
       can be used for stack unwinding from asynchronous events (such as
       debugger or garbage collector).
  
! ‘-fno-gnu-unique’
       On systems with recent GNU assembler and C library, the C++
!      compiler uses the ‘STB_GNU_UNIQUE’ binding to make sure that
       definitions of template static data members and static local
       variables in inline functions are unique even in the presence of
!      ‘RTLD_LOCAL’; this is necessary to avoid problems with a library
!      used by two different ‘RTLD_LOCAL’ plugins depending on a
       definition in one of them and therefore disagreeing with the other
!      one about the binding of the symbol.  But this causes ‘dlclose’ to
       be ignored for affected DSOs; if your program relies on
!      reinitialization of a DSO via ‘dlclose’ and ‘dlopen’, you can use
!      ‘-fno-gnu-unique’.
  
! ‘-fpcc-struct-return’
!      Return "short" ‘struct’ and ‘union’ values in memory like longer
       ones, rather than in registers.  This convention is less efficient,
       but it has the advantage of allowing intercallability between
       GCC-compiled files and files compiled with other compilers,
*************** form by either removing 'no-' or adding
*** 17287,17349 ****
       Short structures and unions are those whose size and alignment
       match that of some integer type.
  
!      *Warning:* code compiled with the '-fpcc-struct-return' switch is
       not binary compatible with code compiled with the
!      '-freg-struct-return' switch.  Use it to conform to a non-default
       application binary interface.
  
! '-freg-struct-return'
!      Return 'struct' and 'union' values in registers when possible.
       This is more efficient for small structures than
!      '-fpcc-struct-return'.
  
!      If you specify neither '-fpcc-struct-return' nor
!      '-freg-struct-return', GCC defaults to whichever convention is
       standard for the target.  If there is no standard convention, GCC
!      defaults to '-fpcc-struct-return', except on targets where GCC is
       the principal compiler.  In those cases, we can choose the
       standard, and we chose the more efficient register return
       alternative.
  
!      *Warning:* code compiled with the '-freg-struct-return' switch is
       not binary compatible with code compiled with the
!      '-fpcc-struct-return' switch.  Use it to conform to a non-default
       application binary interface.
  
! '-fshort-enums'
!      Allocate to an 'enum' type only as many bytes as it needs for the
!      declared range of possible values.  Specifically, the 'enum' type
       is equivalent to the smallest integer type that has enough room.
  
!      *Warning:* the '-fshort-enums' switch causes GCC to generate code
       that is not binary compatible with code generated without that
       switch.  Use it to conform to a non-default application binary
       interface.
  
! '-fshort-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.
  
! '-fcommon'
       In C code, this option controls the placement of global variables
!      defined without an initializer, known as "tentative definitions" in
       the C standard.  Tentative definitions are distinct from
!      declarations of a variable with the 'extern' keyword, which do not
       allocate storage.
  
!      The default is '-fno-common', which specifies that the compiler
       places uninitialized global variables in the BSS section of the
       object file.  This inhibits the merging of tentative definitions by
       the linker so you get a multiple-definition error if the same
       variable is accidentally defined in more than one compilation unit.
  
!      The '-fcommon' places uninitialized global variables in a common
       block.  This allows the linker to resolve all tentative definitions
       of the same variable in different compilation units to the same
       object, or to a non-tentative definition.  This behavior is
--- 17291,17353 ----
       Short structures and unions are those whose size and alignment
       match that of some integer type.
  
!      *Warning:* code compiled with the ‘-fpcc-struct-return’ switch is
       not binary compatible with code compiled with the
!      ‘-freg-struct-return’ switch.  Use it to conform to a non-default
       application binary interface.
  
! ‘-freg-struct-return’
!      Return ‘struct’ and ‘union’ values in registers when possible.
       This is more efficient for small structures than
!      ‘-fpcc-struct-return’.
  
!      If you specify neither ‘-fpcc-struct-return’ nor
!      ‘-freg-struct-return’, GCC defaults to whichever convention is
       standard for the target.  If there is no standard convention, GCC
!      defaults to ‘-fpcc-struct-return’, except on targets where GCC is
       the principal compiler.  In those cases, we can choose the
       standard, and we chose the more efficient register return
       alternative.
  
!      *Warning:* code compiled with the ‘-freg-struct-return’ switch is
       not binary compatible with code compiled with the
!      ‘-fpcc-struct-return’ switch.  Use it to conform to a non-default
       application binary interface.
  
! ‘-fshort-enums’
!      Allocate to an ‘enum’ type only as many bytes as it needs for the
!      declared range of possible values.  Specifically, the ‘enum’ type
       is equivalent to the smallest integer type that has enough room.
  
!      *Warning:* the ‘-fshort-enums’ switch causes GCC to generate code
       that is not binary compatible with code generated without that
       switch.  Use it to conform to a non-default application binary
       interface.
  
! ‘-fshort-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.
  
! ‘-fcommon’
       In C code, this option controls the placement of global variables
!      defined without an initializer, known as “tentative definitions” in
       the C standard.  Tentative definitions are distinct from
!      declarations of a variable with the ‘extern’ keyword, which do not
       allocate storage.
  
!      The default is ‘-fno-common’, which specifies that the compiler
       places uninitialized global variables in the BSS section of the
       object file.  This inhibits the merging of tentative definitions by
       the linker so you get a multiple-definition error if the same
       variable is accidentally defined in more than one compilation unit.
  
!      The ‘-fcommon’ places uninitialized global variables in a common
       block.  This allows the linker to resolve all tentative definitions
       of the same variable in different compilation units to the same
       object, or to a non-tentative definition.  This behavior is
*************** form by either removing 'no-' or adding
*** 17351,17383 ****
       size penalty on global variable references.  It is mainly useful to
       enable legacy code to link without errors.
  
! '-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.
  
       The added comments include:
  
!         * information on the compiler version and command-line options,
  
!         * the source code lines associated with the assembly
            instructions, in the form FILENAME:LINENUMBER:CONTENT OF LINE,
  
!         * hints on which high-level expressions correspond to the
            various assembly instruction operands.
  
       For example, given this C source file:
--- 17355,17387 ----
       size penalty on global variable references.  It is mainly useful to
       enable legacy code to link without errors.
  
! ‘-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.
  
       The added comments include:
  
!         • information on the compiler version and command-line options,
  
!         • the source code lines associated with the assembly
            instructions, in the form FILENAME:LINENUMBER:CONTENT OF LINE,
  
!         • hints on which high-level expressions correspond to the
            various assembly instruction operands.
  
       For example, given this C source file:
*************** form by either removing 'no-' or adding
*** 17393,17400 ****
              return total;
            }
  
!      compiling to (x86_64) assembly via '-S' and emitting the result
!      direct to stdout via '-o' '-'
  
            gcc -S test.c -fverbose-asm -Os -o -
  
--- 17397,17404 ----
              return total;
            }
  
!      compiling to (x86_64) assembly via ‘-S’ and emitting the result
!      direct to stdout via ‘-o’ ‘-’
  
            gcc -S test.c -fverbose-asm -Os -o -
  
*************** form by either removing 'no-' or adding
*** 17440,17458 ****
       The comments are intended for humans rather than machines and hence
       the precise format of the comments is subject to change.
  
! '-frecord-gcc-switches'
       This switch causes the command line used to invoke the compiler to
       be recorded into the object file that is being created.  This
       switch is only implemented on some targets and the exact format of
       the recording is target and binary file format dependent, but it
       usually takes the form of a section containing ASCII text.  This
!      switch is related to the '-fverbose-asm' switch, but that switch
       only records information in the assembler output file as comments,
       so it never reaches the object file.  See also
!      '-grecord-gcc-switches' for another way of storing compiler options
       into the object file.
  
! '-fpic'
       Generate position-independent code (PIC) suitable for use in a
       shared library, if supported for the target machine.  Such code
       accesses all constant addresses through a global offset table
--- 17444,17462 ----
       The comments are intended for humans rather than machines and hence
       the precise format of the comments is subject to change.
  
! ‘-frecord-gcc-switches’
       This switch causes the command line used to invoke the compiler to
       be recorded into the object file that is being created.  This
       switch is only implemented on some targets and the exact format of
       the recording is target and binary file format dependent, but it
       usually takes the form of a section containing ASCII text.  This
!      switch is related to the ‘-fverbose-asm’ switch, but that switch
       only records information in the assembler output file as comments,
       so it never reaches the object file.  See also
!      ‘-grecord-gcc-switches’ for another way of storing compiler options
       into the object file.
  
! ‘-fpic’
       Generate position-independent code (PIC) suitable for use in a
       shared library, if supported for the target machine.  Such code
       accesses all constant addresses through a global offset table
*************** form by either removing 'no-' or adding
*** 17460,17467 ****
       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, 28k on AArch64 and 32k on the m68k
       and RS/6000.  The x86 has no such limit.)
  
--- 17464,17471 ----
       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, 28k on AArch64 and 32k on the m68k
       and RS/6000.  The x86 has no such limit.)
  
*************** form by either removing 'no-' or adding
*** 17470,17479 ****
       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
--- 17474,17483 ----
       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
*************** form by either removing 'no-' or adding
*** 17482,17501 ****
       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 the generated
       position-independent code can be only linked into executables.
       Usually these options are used to compile code that will be linked
!      using the '-pie' GCC option.
  
!      '-fpie' and '-fPIE' both define the macros '__pie__' and '__PIE__'.
!      The macros have the value 1 for '-fpie' and 2 for '-fPIE'.
  
! '-fno-plt'
       Do not use the PLT for external function calls in
       position-independent code.  Instead, load the callee address at
       call sites from the GOT and branch to it.  This leads to more
--- 17486,17505 ----
       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 the generated
       position-independent code can be only linked into executables.
       Usually these options are used to compile code that will be linked
!      using the ‘-pie’ GCC option.
  
!      ‘-fpie’ and ‘-fPIE’ both define the macros ‘__pie__’ and ‘__PIE__’.
!      The macros have the value 1 for ‘-fpie’ and 2 for ‘-fPIE’.
  
! ‘-fno-plt’
       Do not use the PLT for external function calls in
       position-independent code.  Instead, load the callee address at
       call sites from the GOT and branch to it.  This leads to more
*************** form by either removing 'no-' or adding
*** 17503,17543 ****
       optimizations.  On architectures such as 32-bit x86 where PLT stubs
       expect the GOT pointer in a specific register, this gives more
       register allocation freedom to the compiler.  Lazy binding requires
!      use of the PLT; with '-fno-plt' all external symbols are resolved
       at load time.
  
!      Alternatively, the function attribute 'noplt' can be used to avoid
       calls through the PLT for specific external functions.
  
       In position-dependent code, a few targets also convert calls to
       functions that are marked to not use the PLT to use the GOT
       instead.
  
! '-fno-jump-tables'
       Do not use jump tables for switch statements even where it would be
       more efficient than other code generation strategies.  This option
!      is of use in conjunction with '-fpic' or '-fPIC' for building code
       that forms part of a dynamic linker and cannot reference the
       address of a jump table.  On some targets, jump tables do not
       require a GOT and this option is not needed.
  
! '-fno-bit-tests'
       Do not use bit tests for switch statements even where it would be
       more efficient than other code generation strategies.
  
! '-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
--- 17507,17547 ----
       optimizations.  On architectures such as 32-bit x86 where PLT stubs
       expect the GOT pointer in a specific register, this gives more
       register allocation freedom to the compiler.  Lazy binding requires
!      use of the PLT; with ‘-fno-plt’ all external symbols are resolved
       at load time.
  
!      Alternatively, the function attribute ‘noplt’ can be used to avoid
       calls through the PLT for specific external functions.
  
       In position-dependent code, a few targets also convert calls to
       functions that are marked to not use the PLT to use the GOT
       instead.
  
! ‘-fno-jump-tables’
       Do not use jump tables for switch statements even where it would be
       more efficient than other code generation strategies.  This option
!      is of use in conjunction with ‘-fpic’ or ‘-fPIC’ for building code
       that forms part of a dynamic linker and cannot reference the
       address of a jump table.  On some targets, jump tables do not
       require a GOT and this option is not needed.
  
! ‘-fno-bit-tests’
       Do not use bit tests for switch statements even where it would be
       more efficient than other code generation strategies.
  
! ‘-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
*************** form by either removing 'no-' or adding
*** 17551,17557 ****
       This flag does not have a negative form, because it specifies a
       three-way choice.
  
! '-fcall-saved-REG'
       Treat the register named REG as an allocable register saved by
       functions.  It may be allocated even for temporaries or variables
       that live across a call.  Functions compiled this way save and
--- 17555,17561 ----
       This flag does not have a negative form, because it specifies a
       three-way choice.
  
! ‘-fcall-saved-REG’
       Treat the register named REG as an allocable register saved by
       functions.  It may be allocated even for temporaries or variables
       that live across a call.  Functions compiled this way save and
*************** form by either removing 'no-' or adding
*** 17568,17574 ****
       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,
--- 17572,17578 ----
       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,
*************** form by either removing 'no-' or adding
*** 17576,17609 ****
       alignment requirements larger than this are output potentially
       unaligned at the next fitting location.
  
!      *Warning:* the '-fpack-struct' switch causes GCC to generate code
       that is not binary compatible with code generated without that
       switch.  Additionally, it makes the code suboptimal.  Use it to
       conform to a non-default application binary interface.
  
! '-fleading-underscore'
!      This option and its counterpart, '-fno-leading-underscore',
       forcibly change the way C symbols are represented in the object
       file.  One use is to help link with legacy assembly code.
  
!      *Warning:* the '-fleading-underscore' switch causes GCC to generate
       code that is not binary compatible with code generated without that
       switch.  Use it to conform to a non-default application binary
       interface.  Not all targets provide complete support for this
       switch.
  
! '-ftls-model=MODEL'
       Alter the thread-local storage model to be used (*note
       Thread-Local::).  The MODEL argument should be one of
!      'global-dynamic', 'local-dynamic', 'initial-exec' or 'local-exec'.
       Note that the choice is subject to optimization: the compiler may
       use a more efficient model for symbols not visible outside of the
!      translation unit, or if '-fpic' is not given on the command line.
  
!      The default without '-fpic' is 'initial-exec'; with '-fpic' the
!      default is 'global-dynamic'.
  
! '-ftrampolines'
       For targets that normally need trampolines for nested functions,
       always generate them instead of using descriptors.  Otherwise, for
       targets that do not need them, like for example HP-PA or IA-64, do
--- 17580,17613 ----
       alignment requirements larger than this are output potentially
       unaligned at the next fitting location.
  
!      *Warning:* the ‘-fpack-struct’ switch causes GCC to generate code
       that is not binary compatible with code generated without that
       switch.  Additionally, it makes the code suboptimal.  Use it to
       conform to a non-default application binary interface.
  
! ‘-fleading-underscore’
!      This option and its counterpart, ‘-fno-leading-underscore’,
       forcibly change the way C symbols are represented in the object
       file.  One use is to help link with legacy assembly code.
  
!      *Warning:* the ‘-fleading-underscore’ switch causes GCC to generate
       code that is not binary compatible with code generated without that
       switch.  Use it to conform to a non-default application binary
       interface.  Not all targets provide complete support for this
       switch.
  
! ‘-ftls-model=MODEL’
       Alter the thread-local storage model to be used (*note
       Thread-Local::).  The MODEL argument should be one of
!      ‘global-dynamic’, ‘local-dynamic’, ‘initial-exec’ or ‘local-exec’.
       Note that the choice is subject to optimization: the compiler may
       use a more efficient model for symbols not visible outside of the
!      translation unit, or if ‘-fpic’ is not given on the command line.
  
!      The default without ‘-fpic’ is ‘initial-exec’; with ‘-fpic’ the
!      default is ‘global-dynamic’.
  
! ‘-ftrampolines’
       For targets that normally need trampolines for nested functions,
       always generate them instead of using descriptors.  Otherwise, for
       targets that do not need them, like for example HP-PA or IA-64, do
*************** form by either removing 'no-' or adding
*** 17615,17638 ****
       requires the stack to be made executable in order for the program
       to work properly.
  
!      '-fno-trampolines' is enabled by default on a language by language
       basis to let the compiler avoid generating them, if it computes
       that this is safe, and replace them with descriptors.  Descriptors
       are made up of data only, but the generated code must be prepared
!      to deal with them.  As of this writing, '-fno-trampolines' is
       enabled by default only for Ada.
  
!      Moreover, code compiled with '-ftrampolines' and code compiled with
!      '-fno-trampolines' are not binary compatible if nested functions
       are present.  This option must therefore be used on a program-wide
       basis and be manipulated with extreme care.
  
!      For languages other than Ada, the '-ftrampolines' and
!      '-fno-trampolines' options currently have no effect, and
       trampolines are always generated on platforms that need them for
       nested functions.
  
! '-fvisibility=[default|internal|hidden|protected]'
       Set the default ELF image symbol visibility to the specified
       option--all symbols are marked with this unless overridden within
       the code.  Using this feature can very substantially improve
--- 17619,17642 ----
       requires the stack to be made executable in order for the program
       to work properly.
  
!      ‘-fno-trampolines’ is enabled by default on a language by language
       basis to let the compiler avoid generating them, if it computes
       that this is safe, and replace them with descriptors.  Descriptors
       are made up of data only, but the generated code must be prepared
!      to deal with them.  As of this writing, ‘-fno-trampolines’ is
       enabled by default only for Ada.
  
!      Moreover, code compiled with ‘-ftrampolines’ and code compiled with
!      ‘-fno-trampolines’ are not binary compatible if nested functions
       are present.  This option must therefore be used on a program-wide
       basis and be manipulated with extreme care.
  
!      For languages other than Ada, the ‘-ftrampolines’ and
!      ‘-fno-trampolines’ options currently have no effect, and
       trampolines are always generated on platforms that need them for
       nested functions.
  
! ‘-fvisibility=[default|internal|hidden|protected]’
       Set the default ELF image symbol visibility to the specified
       option--all symbols are marked with this unless overridden within
       the code.  Using this feature can very substantially improve
*************** form by either removing 'no-' or adding
*** 17641,17651 ****
       clashes.  It is *strongly* recommended that you use this in any
       shared objects you distribute.
  
!      Despite the nomenclature, 'default' always means public; i.e.,
       available to be linked against from outside the shared object.
!      'protected' and 'internal' are pretty useless in real-world usage
!      so the only other commonly used option is 'hidden'.  The default if
!      '-fvisibility' isn't specified is 'default', i.e., make every
       symbol public.
  
       A good explanation of the benefits offered by ensuring ELF symbols
--- 17645,17655 ----
       clashes.  It is *strongly* recommended that you use this in any
       shared objects you distribute.
  
!      Despite the nomenclature, ‘default’ always means public; i.e.,
       available to be linked against from outside the shared object.
!      ‘protected’ and ‘internal’ are pretty useless in real-world usage
!      so the only other commonly used option is ‘hidden’.  The default if
!      ‘-fvisibility’ isn't specified is ‘default’, i.e., make every
       symbol public.
  
       A good explanation of the benefits offered by ensuring ELF symbols
*************** form by either removing 'no-' or adding
*** 17655,17709 ****
       made possible by this option to marking things hidden when the
       default is public is to make the default hidden and mark things
       public.  This is the norm with DLLs on Windows and with
!      '-fvisibility=hidden' and '__attribute__ ((visibility("default")))'
!      instead of '__declspec(dllexport)' you get almost identical
       semantics with identical syntax.  This is a great boon to those
       working with cross-platform projects.
  
       For those adding visibility support to existing code, you may find
!      '#pragma GCC visibility' of use.  This works by you enclosing the
       declarations you wish to set visibility for with (for example)
!      '#pragma GCC visibility push(hidden)' and '#pragma GCC visibility
!      pop'.  Bear in mind that symbol visibility should be viewed *as
       part of the API interface contract* and thus all new code should
       always specify visibility when it is not the default; i.e.,
       declarations only for use within the local DSO should *always* be
       marked explicitly as hidden as so to avoid PLT indirection
       overheads--making this abundantly clear also aids readability and
       self-documentation of the code.  Note that due to ISO C++
!      specification requirements, 'operator new' and 'operator delete'
       must always be of default visibility.
  
       Be aware that headers from outside your project, in particular
       system headers and headers from any other library you use, may not
       be expecting to be compiled with visibility other than the default.
!      You may need to explicitly say '#pragma GCC visibility
!      push(default)' before including any such headers.
  
!      'extern' declarations are not affected by '-fvisibility', so a lot
!      of code can be recompiled with '-fvisibility=hidden' with no
!      modifications.  However, this means that calls to 'extern'
       functions with no explicit visibility use the PLT, so it is more
!      effective to use '__attribute ((visibility))' and/or '#pragma GCC
!      visibility' to tell the compiler which 'extern' declarations should
       be treated as hidden.
  
!      Note that '-fvisibility' does affect C++ vague linkage entities.
       This means that, for instance, an exception class that is be thrown
       between DSOs must be explicitly marked with default visibility so
!      that the 'type_info' nodes are unified between the DSOs.
  
       An overview of these techniques, their benefits and how to use them
       is at .
  
! '-fstrict-volatile-bitfields'
       This option should be used if accesses to volatile bit-fields (or
       other structure fields, although the compiler usually honors those
       types anyway) should use a single access of the width of the
       field's type, aligned to a natural alignment if possible.  For
       example, targets with memory-mapped peripheral registers might
       require all such accesses to be 16 bits wide; with this flag you
!      can declare all peripheral bit-fields as 'unsigned short' (assuming
       short is 16 bits on these targets) to force GCC to use 16-bit
       accesses instead of, perhaps, a more efficient 32-bit access.
  
--- 17659,17713 ----
       made possible by this option to marking things hidden when the
       default is public is to make the default hidden and mark things
       public.  This is the norm with DLLs on Windows and with
!      ‘-fvisibility=hidden’ and ‘__attribute__ ((visibility("default")))’
!      instead of ‘__declspec(dllexport)’ you get almost identical
       semantics with identical syntax.  This is a great boon to those
       working with cross-platform projects.
  
       For those adding visibility support to existing code, you may find
!      ‘#pragma GCC visibility’ of use.  This works by you enclosing the
       declarations you wish to set visibility for with (for example)
!      ‘#pragma GCC visibility push(hidden)’ and ‘#pragma GCC visibility
!      pop’.  Bear in mind that symbol visibility should be viewed *as
       part of the API interface contract* and thus all new code should
       always specify visibility when it is not the default; i.e.,
       declarations only for use within the local DSO should *always* be
       marked explicitly as hidden as so to avoid PLT indirection
       overheads--making this abundantly clear also aids readability and
       self-documentation of the code.  Note that due to ISO C++
!      specification requirements, ‘operator new’ and ‘operator delete’
       must always be of default visibility.
  
       Be aware that headers from outside your project, in particular
       system headers and headers from any other library you use, may not
       be expecting to be compiled with visibility other than the default.
!      You may need to explicitly say ‘#pragma GCC visibility
!      push(default)’ before including any such headers.
  
!      ‘extern’ declarations are not affected by ‘-fvisibility’, so a lot
!      of code can be recompiled with ‘-fvisibility=hidden’ with no
!      modifications.  However, this means that calls to ‘extern’
       functions with no explicit visibility use the PLT, so it is more
!      effective to use ‘__attribute ((visibility))’ and/or ‘#pragma GCC
!      visibility’ to tell the compiler which ‘extern’ declarations should
       be treated as hidden.
  
!      Note that ‘-fvisibility’ does affect C++ vague linkage entities.
       This means that, for instance, an exception class that is be thrown
       between DSOs must be explicitly marked with default visibility so
!      that the ‘type_info’ nodes are unified between the DSOs.
  
       An overview of these techniques, their benefits and how to use them
       is at .
  
! ‘-fstrict-volatile-bitfields’
       This option should be used if accesses to volatile bit-fields (or
       other structure fields, although the compiler usually honors those
       types anyway) should use a single access of the width of the
       field's type, aligned to a natural alignment if possible.  For
       example, targets with memory-mapped peripheral registers might
       require all such accesses to be 16 bits wide; with this flag you
!      can declare all peripheral bit-fields as ‘unsigned short’ (assuming
       short is 16 bits on these targets) to force GCC to use 16-bit
       accesses instead of, perhaps, a more efficient 32-bit access.
  
*************** form by either removing 'no-' or adding
*** 17713,17719 ****
       any portion of the bit-field, or memory-mapped registers unrelated
       to the one being updated.
  
!      In some cases, such as when the 'packed' attribute is applied to a
       structure field, it may not be possible to access the field with a
       single read or write that is correctly aligned for the target
       machine.  In this case GCC falls back to generating multiple
--- 17717,17723 ----
       any portion of the bit-field, or memory-mapped registers unrelated
       to the one being updated.
  
!      In some cases, such as when the ‘packed’ attribute is applied to a
       structure field, it may not be possible to access the field with a
       single read or write that is correctly aligned for the target
       machine.  In this case GCC falls back to generating multiple
*************** form by either removing 'no-' or adding
*** 17728,17741 ****
       The default value of this option is determined by the application
       binary interface for the target processor.
  
! '-fsync-libcalls'
       This option controls whether any out-of-line instance of the
!      '__sync' family of functions may be used to implement the C++11
!      '__atomic' family of functions.
  
       The default value of this option is enabled, thus the only useful
!      form of the option is '-fno-sync-libcalls'.  This option is used in
!      the implementation of the 'libatomic' runtime library.
  
  
  File: gcc.info,  Node: Developer Options,  Next: Submodel Options,  Prev: Code Gen Options,  Up: Invoking GCC
--- 17732,17745 ----
       The default value of this option is determined by the application
       binary interface for the target processor.
  
! ‘-fsync-libcalls’
       This option controls whether any out-of-line instance of the
!      ‘__sync’ family of functions may be used to implement the C++11
!      ‘__atomic’ family of functions.
  
       The default value of this option is enabled, thus the only useful
!      form of the option is ‘-fno-sync-libcalls’.  This option is used in
!      the implementation of the ‘libatomic’ runtime library.
  
  
  File: gcc.info,  Node: Developer Options,  Next: Submodel Options,  Prev: Code Gen Options,  Up: Invoking GCC
*************** such as where it searches for libraries.
*** 17753,17762 ****
  any of these options for ordinary compilation and linking tasks.
  
   Many developer options that cause GCC to dump output to a file take an
! optional '=FILENAME' suffix.  You can specify 'stdout' or '-' to dump to
! standard output, and 'stderr' for standard error.
  
!  If '=FILENAME' is omitted, a default dump file name is constructed by
  concatenating the base dump file name, a pass number, phase letter, and
  pass name.  The base dump file name is the name of output file produced
  by the compiler if explicitly specified and not an executable; otherwise
--- 17757,17766 ----
  any of these options for ordinary compilation and linking tasks.
  
   Many developer options that cause GCC to dump output to a file take an
! optional ‘=FILENAME’ suffix.  You can specify ‘stdout’ or ‘-’ to dump to
! standard output, and ‘stderr’ for standard error.
  
!  If ‘=FILENAME’ is omitted, a default dump file name is constructed by
  concatenating the base dump file name, a pass number, phase letter, and
  pass name.  The base dump file name is the name of output file produced
  by the compiler if explicitly specified and not an executable; otherwise
*************** it is the source file name.  The pass nu
*** 17764,18082 ****
  passes are registered with the compiler's pass manager.  This is
  generally the same as the order of execution, but passes registered by
  plugins, target-specific passes, or passes that are otherwise registered
! late are numbered higher than the pass named 'final', even if they are
! executed earlier.  The phase letter is one of 'i' (inter-procedural
! analysis), 'l' (language-specific), 'r' (RTL), or 't' (tree).  The files
  are created in the directory of the output file.
  
! '-fcallgraph-info'
! '-fcallgraph-info=MARKERS'
       Makes the compiler output callgraph information for the program, on
       a per-object-file basis.  The information is generated in the
       common VCG format.  It can be decorated with additional, per-node
       and/or per-edge information, if a list of comma-separated markers
!      is additionally specified.  When the 'su' marker is specified, the
       callgraph is decorated with stack usage information; it is
!      equivalent to '-fstack-usage'.  When the 'da' marker is specified,
       the callgraph is decorated with information about dynamically
       allocated objects.
  
!      When compiling with '-flto', no callgraph information is output
!      along with the object file.  At LTO link time, '-fcallgraph-info'
       may generate multiple callgraph information files next to
       intermediate LTO output files.
  
! '-dLETTERS'
! '-fdump-rtl-PASS'
! '-fdump-rtl-PASS=FILENAME'
       Says to make debugging dumps during compilation at times specified
       by LETTERS.  This is used for debugging the RTL-based passes of the
       compiler.
  
!      Some '-dLETTERS' switches have different meaning when '-E' is used
       for preprocessing.  *Note Preprocessor Options::, for information
       about preprocessor-specific dump options.
  
!      Debug dumps can be enabled with a '-fdump-rtl' switch or some '-d'
       option LETTERS.  Here are the possible letters for use in PASS and
       LETTERS, and their meanings:
  
!      '-fdump-rtl-alignments'
            Dump after branch alignments have been computed.
  
!      '-fdump-rtl-asmcons'
            Dump after fixing rtl statements that have unsatisfied in/out
            constraints.
  
!      '-fdump-rtl-auto_inc_dec'
            Dump after auto-inc-dec discovery.  This pass is only run on
            architectures that have auto inc or auto dec instructions.
  
!      '-fdump-rtl-barriers'
            Dump after cleaning up the barrier instructions.
  
!      '-fdump-rtl-bbpart'
            Dump after partitioning hot and cold basic blocks.
  
!      '-fdump-rtl-bbro'
            Dump after block reordering.
  
!      '-fdump-rtl-btl1'
!      '-fdump-rtl-btl2'
!           '-fdump-rtl-btl1' and '-fdump-rtl-btl2' enable dumping after
            the two branch target load optimization passes.
  
!      '-fdump-rtl-bypass'
            Dump after jump bypassing and control flow optimizations.
  
!      '-fdump-rtl-combine'
            Dump after the RTL instruction combination pass.
  
!      '-fdump-rtl-compgotos'
            Dump after duplicating the computed gotos.
  
!      '-fdump-rtl-ce1'
!      '-fdump-rtl-ce2'
!      '-fdump-rtl-ce3'
!           '-fdump-rtl-ce1', '-fdump-rtl-ce2', and '-fdump-rtl-ce3'
            enable dumping after the three if conversion passes.
  
!      '-fdump-rtl-cprop_hardreg'
            Dump after hard register copy propagation.
  
!      '-fdump-rtl-csa'
            Dump after combining stack adjustments.
  
!      '-fdump-rtl-cse1'
!      '-fdump-rtl-cse2'
!           '-fdump-rtl-cse1' and '-fdump-rtl-cse2' enable dumping after
            the two common subexpression elimination passes.
  
!      '-fdump-rtl-dce'
            Dump after the standalone dead code elimination passes.
  
!      '-fdump-rtl-dbr'
            Dump after delayed branch scheduling.
  
!      '-fdump-rtl-dce1'
!      '-fdump-rtl-dce2'
!           '-fdump-rtl-dce1' and '-fdump-rtl-dce2' enable dumping after
            the two dead store elimination passes.
  
!      '-fdump-rtl-eh'
            Dump after finalization of EH handling code.
  
!      '-fdump-rtl-eh_ranges'
            Dump after conversion of EH handling range regions.
  
!      '-fdump-rtl-expand'
            Dump after RTL generation.
  
!      '-fdump-rtl-fwprop1'
!      '-fdump-rtl-fwprop2'
!           '-fdump-rtl-fwprop1' and '-fdump-rtl-fwprop2' enable dumping
            after the two forward propagation passes.
  
!      '-fdump-rtl-gcse1'
!      '-fdump-rtl-gcse2'
!           '-fdump-rtl-gcse1' and '-fdump-rtl-gcse2' enable dumping after
            global common subexpression elimination.
  
!      '-fdump-rtl-init-regs'
            Dump after the initialization of the registers.
  
!      '-fdump-rtl-initvals'
            Dump after the computation of the initial value sets.
  
!      '-fdump-rtl-into_cfglayout'
            Dump after converting to cfglayout mode.
  
!      '-fdump-rtl-ira'
            Dump after iterated register allocation.
  
!      '-fdump-rtl-jump'
            Dump after the second jump optimization.
  
!      '-fdump-rtl-loop2'
!           '-fdump-rtl-loop2' enables dumping after the rtl loop
            optimization passes.
  
!      '-fdump-rtl-mach'
            Dump after performing the machine dependent reorganization
            pass, if that pass exists.
  
!      '-fdump-rtl-mode_sw'
            Dump after removing redundant mode switches.
  
!      '-fdump-rtl-rnreg'
            Dump after register renumbering.
  
!      '-fdump-rtl-outof_cfglayout'
            Dump after converting from cfglayout mode.
  
!      '-fdump-rtl-peephole2'
            Dump after the peephole pass.
  
!      '-fdump-rtl-postreload'
            Dump after post-reload optimizations.
  
!      '-fdump-rtl-pro_and_epilogue'
            Dump after generating the function prologues and epilogues.
  
!      '-fdump-rtl-sched1'
!      '-fdump-rtl-sched2'
!           '-fdump-rtl-sched1' and '-fdump-rtl-sched2' enable dumping
            after the basic block scheduling passes.
  
!      '-fdump-rtl-ree'
            Dump after sign/zero extension elimination.
  
!      '-fdump-rtl-seqabstr'
            Dump after common sequence discovery.
  
!      '-fdump-rtl-shorten'
            Dump after shortening branches.
  
!      '-fdump-rtl-sibling'
            Dump after sibling call optimizations.
  
!      '-fdump-rtl-split1'
!      '-fdump-rtl-split2'
!      '-fdump-rtl-split3'
!      '-fdump-rtl-split4'
!      '-fdump-rtl-split5'
            These options enable dumping after five rounds of instruction
            splitting.
  
!      '-fdump-rtl-sms'
            Dump after modulo scheduling.  This pass is only run on some
            architectures.
  
!      '-fdump-rtl-stack'
            Dump after conversion from GCC's "flat register file"
            registers to the x87's stack-like registers.  This pass is
            only run on x86 variants.
  
!      '-fdump-rtl-subreg1'
!      '-fdump-rtl-subreg2'
!           '-fdump-rtl-subreg1' and '-fdump-rtl-subreg2' enable dumping
            after the two subreg expansion passes.
  
!      '-fdump-rtl-unshare'
            Dump after all rtl has been unshared.
  
!      '-fdump-rtl-vartrack'
            Dump after variable tracking.
  
!      '-fdump-rtl-vregs'
            Dump after converting virtual registers to hard registers.
  
!      '-fdump-rtl-web'
            Dump after live range splitting.
  
!      '-fdump-rtl-regclass'
!      '-fdump-rtl-subregs_of_mode_init'
!      '-fdump-rtl-subregs_of_mode_finish'
!      '-fdump-rtl-dfinit'
!      '-fdump-rtl-dfinish'
            These dumps are defined but always produce empty files.
  
!      '-da'
!      '-fdump-rtl-all'
            Produce all the dumps listed above.
  
!      '-dA'
            Annotate the assembler output with miscellaneous debugging
            information.
  
!      '-dD'
            Dump all macro definitions, at the end of preprocessing, in
            addition to normal output.
  
!      '-dH'
            Produce a core dump whenever an error occurs.
  
!      '-dp'
            Annotate the assembler output with a comment indicating which
            pattern and alternative is used.  The length and cost of each
            instruction are also printed.
  
!      '-dP'
            Dump the RTL in the assembler output as a comment before each
!           instruction.  Also turns on '-dp' annotation.
  
!      '-dx'
            Just generate RTL for a function instead of compiling it.
!           Usually used with '-fdump-rtl-expand'.
  
! '-fdump-debug'
       Dump debugging information generated during the debug generation
       phase.
  
! '-fdump-earlydebug'
       Dump debugging information generated during the early debug
       generation phase.
  
! '-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.
  
! '-freport-bug'
       Collect and dump debug information into a temporary file if an
       internal compiler error (ICE) occurs.
  
! '-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-ipa-SWITCH'
! '-fdump-ipa-SWITCH-OPTIONS'
       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.
  
!      Additionally, the options '-optimized', '-missed', '-note', and
!      '-all' can be provided, with the same meaning as for '-fopt-info',
!      defaulting to '-optimized'.
  
!      For example, '-fdump-ipa-inline-optimized-missed' will emit
       information on callsites that were inlined, along with callsites
       that were not inlined.
  
       By default, the dump will contain messages about successful
!      optimizations (equivalent to '-optimized') together with low-level
       details about the analysis.
  
! '-fdump-ipa-clones'
  
       Create a dump file containing information about creation of call
       graph node clones and removals of call graph nodes during
       inter-procedural optimizations and transformations.  Its main
       intended use is that tools that create live-patches can determine
       the set of functions that need to be live-patched to completely
!      replace a particular function (see '-flive-patching').  The file
!      name is generated by appending suffix 'ipa-clones' to the source
       file name, and the file is created in the same directory as the
       output file.  Each entry in the file is on a separate line
       containing semicolon separated fields.
--- 17768,18086 ----
  passes are registered with the compiler's pass manager.  This is
  generally the same as the order of execution, but passes registered by
  plugins, target-specific passes, or passes that are otherwise registered
! late are numbered higher than the pass named ‘final’, even if they are
! executed earlier.  The phase letter is one of ‘i’ (inter-procedural
! analysis), ‘l’ (language-specific), ‘r’ (RTL), or ‘t’ (tree).  The files
  are created in the directory of the output file.
  
! ‘-fcallgraph-info’
! ‘-fcallgraph-info=MARKERS’
       Makes the compiler output callgraph information for the program, on
       a per-object-file basis.  The information is generated in the
       common VCG format.  It can be decorated with additional, per-node
       and/or per-edge information, if a list of comma-separated markers
!      is additionally specified.  When the ‘su’ marker is specified, the
       callgraph is decorated with stack usage information; it is
!      equivalent to ‘-fstack-usage’.  When the ‘da’ marker is specified,
       the callgraph is decorated with information about dynamically
       allocated objects.
  
!      When compiling with ‘-flto’, no callgraph information is output
!      along with the object file.  At LTO link time, ‘-fcallgraph-info’
       may generate multiple callgraph information files next to
       intermediate LTO output files.
  
! ‘-dLETTERS’
! ‘-fdump-rtl-PASS’
! ‘-fdump-rtl-PASS=FILENAME’
       Says to make debugging dumps during compilation at times specified
       by LETTERS.  This is used for debugging the RTL-based passes of the
       compiler.
  
!      Some ‘-dLETTERS’ switches have different meaning when ‘-E’ is used
       for preprocessing.  *Note Preprocessor Options::, for information
       about preprocessor-specific dump options.
  
!      Debug dumps can be enabled with a ‘-fdump-rtl’ switch or some ‘-d’
       option LETTERS.  Here are the possible letters for use in PASS and
       LETTERS, and their meanings:
  
!      ‘-fdump-rtl-alignments’
            Dump after branch alignments have been computed.
  
!      ‘-fdump-rtl-asmcons’
            Dump after fixing rtl statements that have unsatisfied in/out
            constraints.
  
!      ‘-fdump-rtl-auto_inc_dec’
            Dump after auto-inc-dec discovery.  This pass is only run on
            architectures that have auto inc or auto dec instructions.
  
!      ‘-fdump-rtl-barriers’
            Dump after cleaning up the barrier instructions.
  
!      ‘-fdump-rtl-bbpart’
            Dump after partitioning hot and cold basic blocks.
  
!      ‘-fdump-rtl-bbro’
            Dump after block reordering.
  
!      ‘-fdump-rtl-btl1’
!      ‘-fdump-rtl-btl2’
!           ‘-fdump-rtl-btl1’ and ‘-fdump-rtl-btl2’ enable dumping after
            the two branch target load optimization passes.
  
!      ‘-fdump-rtl-bypass’
            Dump after jump bypassing and control flow optimizations.
  
!      ‘-fdump-rtl-combine’
            Dump after the RTL instruction combination pass.
  
!      ‘-fdump-rtl-compgotos’
            Dump after duplicating the computed gotos.
  
!      ‘-fdump-rtl-ce1’
!      ‘-fdump-rtl-ce2’
!      ‘-fdump-rtl-ce3’
!           ‘-fdump-rtl-ce1’, ‘-fdump-rtl-ce2’, and ‘-fdump-rtl-ce3’
            enable dumping after the three if conversion passes.
  
!      ‘-fdump-rtl-cprop_hardreg’
            Dump after hard register copy propagation.
  
!      ‘-fdump-rtl-csa’
            Dump after combining stack adjustments.
  
!      ‘-fdump-rtl-cse1’
!      ‘-fdump-rtl-cse2’
!           ‘-fdump-rtl-cse1’ and ‘-fdump-rtl-cse2’ enable dumping after
            the two common subexpression elimination passes.
  
!      ‘-fdump-rtl-dce’
            Dump after the standalone dead code elimination passes.
  
!      ‘-fdump-rtl-dbr’
            Dump after delayed branch scheduling.
  
!      ‘-fdump-rtl-dce1’
!      ‘-fdump-rtl-dce2’
!           ‘-fdump-rtl-dce1’ and ‘-fdump-rtl-dce2’ enable dumping after
            the two dead store elimination passes.
  
!      ‘-fdump-rtl-eh’
            Dump after finalization of EH handling code.
  
!      ‘-fdump-rtl-eh_ranges’
            Dump after conversion of EH handling range regions.
  
!      ‘-fdump-rtl-expand’
            Dump after RTL generation.
  
!      ‘-fdump-rtl-fwprop1’
!      ‘-fdump-rtl-fwprop2’
!           ‘-fdump-rtl-fwprop1’ and ‘-fdump-rtl-fwprop2’ enable dumping
            after the two forward propagation passes.
  
!      ‘-fdump-rtl-gcse1’
!      ‘-fdump-rtl-gcse2’
!           ‘-fdump-rtl-gcse1’ and ‘-fdump-rtl-gcse2’ enable dumping after
            global common subexpression elimination.
  
!      ‘-fdump-rtl-init-regs’
            Dump after the initialization of the registers.
  
!      ‘-fdump-rtl-initvals’
            Dump after the computation of the initial value sets.
  
!      ‘-fdump-rtl-into_cfglayout’
            Dump after converting to cfglayout mode.
  
!      ‘-fdump-rtl-ira’
            Dump after iterated register allocation.
  
!      ‘-fdump-rtl-jump’
            Dump after the second jump optimization.
  
!      ‘-fdump-rtl-loop2’
!           ‘-fdump-rtl-loop2’ enables dumping after the rtl loop
            optimization passes.
  
!      ‘-fdump-rtl-mach’
            Dump after performing the machine dependent reorganization
            pass, if that pass exists.
  
!      ‘-fdump-rtl-mode_sw’
            Dump after removing redundant mode switches.
  
!      ‘-fdump-rtl-rnreg’
            Dump after register renumbering.
  
!      ‘-fdump-rtl-outof_cfglayout’
            Dump after converting from cfglayout mode.
  
!      ‘-fdump-rtl-peephole2’
            Dump after the peephole pass.
  
!      ‘-fdump-rtl-postreload’
            Dump after post-reload optimizations.
  
!      ‘-fdump-rtl-pro_and_epilogue’
            Dump after generating the function prologues and epilogues.
  
!      ‘-fdump-rtl-sched1’
!      ‘-fdump-rtl-sched2’
!           ‘-fdump-rtl-sched1’ and ‘-fdump-rtl-sched2’ enable dumping
            after the basic block scheduling passes.
  
!      ‘-fdump-rtl-ree’
            Dump after sign/zero extension elimination.
  
!      ‘-fdump-rtl-seqabstr’
            Dump after common sequence discovery.
  
!      ‘-fdump-rtl-shorten’
            Dump after shortening branches.
  
!      ‘-fdump-rtl-sibling’
            Dump after sibling call optimizations.
  
!      ‘-fdump-rtl-split1’
!      ‘-fdump-rtl-split2’
!      ‘-fdump-rtl-split3’
!      ‘-fdump-rtl-split4’
!      ‘-fdump-rtl-split5’
            These options enable dumping after five rounds of instruction
            splitting.
  
!      ‘-fdump-rtl-sms’
            Dump after modulo scheduling.  This pass is only run on some
            architectures.
  
!      ‘-fdump-rtl-stack’
            Dump after conversion from GCC's "flat register file"
            registers to the x87's stack-like registers.  This pass is
            only run on x86 variants.
  
!      ‘-fdump-rtl-subreg1’
!      ‘-fdump-rtl-subreg2’
!           ‘-fdump-rtl-subreg1’ and ‘-fdump-rtl-subreg2’ enable dumping
            after the two subreg expansion passes.
  
!      ‘-fdump-rtl-unshare’
            Dump after all rtl has been unshared.
  
!      ‘-fdump-rtl-vartrack’
            Dump after variable tracking.
  
!      ‘-fdump-rtl-vregs’
            Dump after converting virtual registers to hard registers.
  
!      ‘-fdump-rtl-web’
            Dump after live range splitting.
  
!      ‘-fdump-rtl-regclass’
!      ‘-fdump-rtl-subregs_of_mode_init’
!      ‘-fdump-rtl-subregs_of_mode_finish’
!      ‘-fdump-rtl-dfinit’
!      ‘-fdump-rtl-dfinish’
            These dumps are defined but always produce empty files.
  
!      ‘-da’
!      ‘-fdump-rtl-all’
            Produce all the dumps listed above.
  
!      ‘-dA’
            Annotate the assembler output with miscellaneous debugging
            information.
  
!      ‘-dD’
            Dump all macro definitions, at the end of preprocessing, in
            addition to normal output.
  
!      ‘-dH’
            Produce a core dump whenever an error occurs.
  
!      ‘-dp’
            Annotate the assembler output with a comment indicating which
            pattern and alternative is used.  The length and cost of each
            instruction are also printed.
  
!      ‘-dP’
            Dump the RTL in the assembler output as a comment before each
!           instruction.  Also turns on ‘-dp’ annotation.
  
!      ‘-dx’
            Just generate RTL for a function instead of compiling it.
!           Usually used with ‘-fdump-rtl-expand’.
  
! ‘-fdump-debug’
       Dump debugging information generated during the debug generation
       phase.
  
! ‘-fdump-earlydebug’
       Dump debugging information generated during the early debug
       generation phase.
  
! ‘-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.
  
! ‘-freport-bug’
       Collect and dump debug information into a temporary file if an
       internal compiler error (ICE) occurs.
  
! ‘-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-ipa-SWITCH’
! ‘-fdump-ipa-SWITCH-OPTIONS’
       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.
  
!      Additionally, the options ‘-optimized’, ‘-missed’, ‘-note’, and
!      ‘-all’ can be provided, with the same meaning as for ‘-fopt-info’,
!      defaulting to ‘-optimized’.
  
!      For example, ‘-fdump-ipa-inline-optimized-missed’ will emit
       information on callsites that were inlined, along with callsites
       that were not inlined.
  
       By default, the dump will contain messages about successful
!      optimizations (equivalent to ‘-optimized’) together with low-level
       details about the analysis.
  
! ‘-fdump-ipa-clones’
  
       Create a dump file containing information about creation of call
       graph node clones and removals of call graph nodes during
       inter-procedural optimizations and transformations.  Its main
       intended use is that tools that create live-patches can determine
       the set of functions that need to be live-patched to completely
!      replace a particular function (see ‘-flive-patching’).  The file
!      name is generated by appending suffix ‘ipa-clones’ to the source
       file name, and the file is created in the same directory as the
       output file.  Each entry in the file is on a separate line
       containing semicolon separated fields.
*************** are created in the directory of the outp
*** 18084,18090 ****
       In the case of call graph clone creation, the individual fields
       are:
  
!        1. String 'Callgraph clone'.
  
         2. Name of the function being cloned as it is presented to the
            assembler.
--- 18088,18094 ----
       In the case of call graph clone creation, the individual fields
       are:
  
!        1. String ‘Callgraph clone’.
  
         2. Name of the function being cloned as it is presented to the
            assembler.
*************** are created in the directory of the outp
*** 18122,18128 ****
  
       In the case of call graph clone removal, the individual fields are:
  
!        1. String 'Callgraph removal'.
  
         2. Name of the function being removed as it would be presented to
            the assembler.
--- 18126,18132 ----
  
       In the case of call graph clone removal, the individual fields are:
  
!        1. String ‘Callgraph removal’.
  
         2. Name of the function being removed as it would be presented to
            the assembler.
*************** are created in the directory of the outp
*** 18139,18212 ****
  
         6. The column where the function definition is located.
  
! '-fdump-lang'
       Dump language-specific information.  The file name is made by
!      appending '.lang' to the source file name.
  
! '-fdump-lang-all'
! '-fdump-lang-SWITCH'
! '-fdump-lang-SWITCH-OPTIONS'
! '-fdump-lang-SWITCH-OPTIONS=FILENAME'
       Control the dumping of language-specific information.  The OPTIONS
!      and FILENAME portions behave as described in the '-fdump-tree'
       option.  The following SWITCH values are accepted:
  
!      'all'
  
            Enable all language-specific dumps.
  
!      'class'
            Dump class hierarchy information.  Virtual table information
!           is emitted unless ''slim'' is specified.  This option is
            applicable to C++ only.
  
!      'module'
!           Dump module information.  Options 'lineno' (locations),
!           'graph' (reachability), 'blocks' (clusters), 'uid'
!           (serialization), 'alias' (mergeable), 'asmname' (Elrond), 'eh'
!           (mapper) & 'vops' (macros) may provide additional information.
            This option is applicable to C++ only.
  
!      'raw'
            Dump the raw internal tree data.  This option is applicable to
            C++ only.
  
! '-fdump-passes'
!      Print on 'stderr' the list of optimization passes that are turned
       on and off by the current command-line options.
  
! '-fdump-statistics-OPTION'
       Enable and control dumping of pass statistics in a separate file.
       The file name is generated by appending a suffix ending in
!      '.statistics' to the source file name, and the file is created in
!      the same directory as the output file.  If the '-OPTION' form is
!      used, '-stats' causes counters to be summed over the whole
!      compilation unit while '-details' dumps every event as the passes
       generate them.  The default with no option is to sum counters for
       each function compiled.
  
! '-fdump-tree-all'
! '-fdump-tree-SWITCH'
! '-fdump-tree-SWITCH-OPTIONS'
! '-fdump-tree-SWITCH-OPTIONS=FILENAME'
       Control the dumping at various stages of processing the
!      intermediate language tree to a file.  If the '-OPTIONS' form is
!      used, OPTIONS is a list of '-' separated options which control the
       details of the dump.  Not all options are applicable to all dumps;
       those that are not meaningful are ignored.  The following options
       are available
  
!      'address'
            Print the address of each node.  Usually this is not
            meaningful as it changes according to the environment and
            source file.  Its primary use is for tying up a dump file with
            a debug environment.
!      'asmname'
!           If 'DECL_ASSEMBLER_NAME' has been set for a given decl, use
!           that in the dump instead of 'DECL_NAME'.  Its primary use is
            ease of use working backward from mangled names in the
            assembly file.
!      'slim'
            When dumping front-end intermediate representations, inhibit
            dumping of members of a scope or body of a function merely
            because that scope has been reached.  Only dump such items
--- 18143,18216 ----
  
         6. The column where the function definition is located.
  
! ‘-fdump-lang’
       Dump language-specific information.  The file name is made by
!      appending ‘.lang’ to the source file name.
  
! ‘-fdump-lang-all’
! ‘-fdump-lang-SWITCH’
! ‘-fdump-lang-SWITCH-OPTIONS’
! ‘-fdump-lang-SWITCH-OPTIONS=FILENAME’
       Control the dumping of language-specific information.  The OPTIONS
!      and FILENAME portions behave as described in the ‘-fdump-tree’
       option.  The following SWITCH values are accepted:
  
!      ‘all’
  
            Enable all language-specific dumps.
  
!      ‘class’
            Dump class hierarchy information.  Virtual table information
!           is emitted unless '‘slim’' is specified.  This option is
            applicable to C++ only.
  
!      ‘module’
!           Dump module information.  Options ‘lineno’ (locations),
!           ‘graph’ (reachability), ‘blocks’ (clusters), ‘uid’
!           (serialization), ‘alias’ (mergeable), ‘asmname’ (Elrond), ‘eh’
!           (mapper) & ‘vops’ (macros) may provide additional information.
            This option is applicable to C++ only.
  
!      ‘raw’
            Dump the raw internal tree data.  This option is applicable to
            C++ only.
  
! ‘-fdump-passes’
!      Print on ‘stderr’ the list of optimization passes that are turned
       on and off by the current command-line options.
  
! ‘-fdump-statistics-OPTION’
       Enable and control dumping of pass statistics in a separate file.
       The file name is generated by appending a suffix ending in
!      ‘.statistics’ to the source file name, and the file is created in
!      the same directory as the output file.  If the ‘-OPTION’ form is
!      used, ‘-stats’ causes counters to be summed over the whole
!      compilation unit while ‘-details’ dumps every event as the passes
       generate them.  The default with no option is to sum counters for
       each function compiled.
  
! ‘-fdump-tree-all’
! ‘-fdump-tree-SWITCH’
! ‘-fdump-tree-SWITCH-OPTIONS’
! ‘-fdump-tree-SWITCH-OPTIONS=FILENAME’
       Control the dumping at various stages of processing the
!      intermediate language tree to a file.  If the ‘-OPTIONS’ form is
!      used, OPTIONS is a list of ‘-’ separated options which control the
       details of the dump.  Not all options are applicable to all dumps;
       those that are not meaningful are ignored.  The following options
       are available
  
!      ‘address’
            Print the address of each node.  Usually this is not
            meaningful as it changes according to the environment and
            source file.  Its primary use is for tying up a dump file with
            a debug environment.
!      ‘asmname’
!           If ‘DECL_ASSEMBLER_NAME’ has been set for a given decl, use
!           that in the dump instead of ‘DECL_NAME’.  Its primary use is
            ease of use working backward from mangled names in the
            assembly file.
!      ‘slim’
            When dumping front-end intermediate representations, inhibit
            dumping of members of a scope or body of a function merely
            because that scope has been reached.  Only dump such items
*************** are created in the directory of the outp
*** 18217,18302 ****
  
            When dumping RTL, print the RTL in slim (condensed) form
            instead of the default LISP-like representation.
!      'raw'
            Print a raw representation of the tree.  By default, trees are
            pretty-printed into a C-like representation.
!      'details'
            Enable more detailed dumps (not honored by every dump option).
            Also include information from the optimization passes.
!      'stats'
            Enable dumping various statistics about the pass (not honored
            by every dump option).
!      'blocks'
            Enable showing basic block boundaries (disabled in raw dumps).
!      'graph'
            For each of the other indicated dump files
!           ('-fdump-rtl-PASS'), dump a representation of the control flow
            graph suitable for viewing with GraphViz to
!           'FILE.PASSID.PASS.dot'.  Each function in the file is
            pretty-printed as a subgraph, so that GraphViz can render them
            all in a single plot.
  
            This option currently only works for RTL dumps, and the RTL is
            always dumped in slim form.
!      'vops'
            Enable showing virtual operands for every statement.
!      'lineno'
            Enable showing line numbers for statements.
!      'uid'
!           Enable showing the unique ID ('DECL_UID') for each variable.
!      'verbose'
            Enable showing the tree dump for each statement.
!      'eh'
            Enable showing the EH region number holding each statement.
!      'scev'
            Enable showing scalar evolution analysis details.
!      'optimized'
            Enable showing optimization information (only available in
            certain passes).
!      'missed'
            Enable showing missed optimization information (only available
            in certain passes).
!      'note'
            Enable other detailed optimization information (only available
            in certain passes).
!      'all'
!           Turn on all options, except 'raw', 'slim', 'verbose' and
!           'lineno'.
!      'optall'
!           Turn on all optimization options, i.e., 'optimized', 'missed',
!           and 'note'.
  
       To determine what tree dumps are available or find the dump for a
       pass of interest follow the steps below.
  
!        1. Invoke GCC with '-fdump-passes' and in the 'stderr' output
            look for a code that corresponds to the pass you are
!           interested in.  For example, the codes 'tree-evrp',
!           'tree-vrp1', and 'tree-vrp2' correspond to the three Value
            Range Propagation passes.  The number at the end distinguishes
            distinct invocations of the same pass.
         2. To enable the creation of the dump file, append the pass code
!           to the '-fdump-' option prefix and invoke GCC with it.  For
            example, to enable the dump from the Early Value Range
!           Propagation pass, invoke GCC with the '-fdump-tree-evrp'
            option.  Optionally, you may specify the name of the dump
            file.  If you don't specify one, GCC creates as described
            below.
         3. Find the pass dump in a file whose name is composed of three
            components separated by a period: the name of the source file
            GCC was invoked to compile, a numeric suffix indicating the
!           pass number followed by the letter 't' for tree passes (and
!           the letter 'r' for RTL passes), and finally the pass code.
            For example, the Early VRP pass dump might be in a file named
!           'myfile.c.038t.evrp' in the current working directory.  Note
            that the numeric codes are not stable and may change from one
            version of GCC to another.
  
! '-fopt-info'
! '-fopt-info-OPTIONS'
! '-fopt-info-OPTIONS=FILENAME'
       Controls optimization dumps from various optimization passes.  If
!      the '-OPTIONS' form is used, OPTIONS is a list of '-' separated
       option keywords to select the dump details and optimizations.
  
       The OPTIONS can be divided into three groups:
--- 18221,18306 ----
  
            When dumping RTL, print the RTL in slim (condensed) form
            instead of the default LISP-like representation.
!      ‘raw’
            Print a raw representation of the tree.  By default, trees are
            pretty-printed into a C-like representation.
!      ‘details’
            Enable more detailed dumps (not honored by every dump option).
            Also include information from the optimization passes.
!      ‘stats’
            Enable dumping various statistics about the pass (not honored
            by every dump option).
!      ‘blocks’
            Enable showing basic block boundaries (disabled in raw dumps).
!      ‘graph’
            For each of the other indicated dump files
!           (‘-fdump-rtl-PASS’), dump a representation of the control flow
            graph suitable for viewing with GraphViz to
!           ‘FILE.PASSID.PASS.dot’.  Each function in the file is
            pretty-printed as a subgraph, so that GraphViz can render them
            all in a single plot.
  
            This option currently only works for RTL dumps, and the RTL is
            always dumped in slim form.
!      ‘vops’
            Enable showing virtual operands for every statement.
!      ‘lineno’
            Enable showing line numbers for statements.
!      ‘uid’
!           Enable showing the unique ID (‘DECL_UID’) for each variable.
!      ‘verbose’
            Enable showing the tree dump for each statement.
!      ‘eh’
            Enable showing the EH region number holding each statement.
!      ‘scev’
            Enable showing scalar evolution analysis details.
!      ‘optimized’
            Enable showing optimization information (only available in
            certain passes).
!      ‘missed’
            Enable showing missed optimization information (only available
            in certain passes).
!      ‘note’
            Enable other detailed optimization information (only available
            in certain passes).
!      ‘all’
!           Turn on all options, except ‘raw’, ‘slim’, ‘verbose’ and
!           ‘lineno’.
!      ‘optall’
!           Turn on all optimization options, i.e., ‘optimized’, ‘missed’,
!           and ‘note’.
  
       To determine what tree dumps are available or find the dump for a
       pass of interest follow the steps below.
  
!        1. Invoke GCC with ‘-fdump-passes’ and in the ‘stderr’ output
            look for a code that corresponds to the pass you are
!           interested in.  For example, the codes ‘tree-evrp’,
!           ‘tree-vrp1’, and ‘tree-vrp2’ correspond to the three Value
            Range Propagation passes.  The number at the end distinguishes
            distinct invocations of the same pass.
         2. To enable the creation of the dump file, append the pass code
!           to the ‘-fdump-’ option prefix and invoke GCC with it.  For
            example, to enable the dump from the Early Value Range
!           Propagation pass, invoke GCC with the ‘-fdump-tree-evrp’
            option.  Optionally, you may specify the name of the dump
            file.  If you don't specify one, GCC creates as described
            below.
         3. Find the pass dump in a file whose name is composed of three
            components separated by a period: the name of the source file
            GCC was invoked to compile, a numeric suffix indicating the
!           pass number followed by the letter ‘t’ for tree passes (and
!           the letter ‘r’ for RTL passes), and finally the pass code.
            For example, the Early VRP pass dump might be in a file named
!           ‘myfile.c.038t.evrp’ in the current working directory.  Note
            that the numeric codes are not stable and may change from one
            version of GCC to another.
  
! ‘-fopt-info’
! ‘-fopt-info-OPTIONS’
! ‘-fopt-info-OPTIONS=FILENAME’
       Controls optimization dumps from various optimization passes.  If
!      the ‘-OPTIONS’ form is used, OPTIONS is a list of ‘-’ separated
       option keywords to select the dump details and optimizations.
  
       The OPTIONS can be divided into three groups:
*************** are created in the directory of the outp
*** 18310,18333 ****
       The following options control which kinds of messages should be
       emitted:
  
!      'optimized'
            Print information when an optimization is successfully
            applied.  It is up to a pass to decide which information is
            relevant.  For example, the vectorizer passes print the source
            location of loops which are successfully vectorized.
!      'missed'
            Print information about missed optimizations.  Individual
            passes control which information to include in the output.
!      'note'
            Print verbose information about optimizations, such as certain
            transformations, more detailed messages about decisions etc.
!      'all'
            Print detailed optimization information.  This includes
!           'optimized', 'missed', and 'note'.
  
       The following option controls the dump verbosity:
  
!      'internals'
            By default, only "high-level" messages are emitted.  This
            option enables additional, more detailed, messages, which are
            likely to only be of interest to GCC developers.
--- 18314,18337 ----
       The following options control which kinds of messages should be
       emitted:
  
!      ‘optimized’
            Print information when an optimization is successfully
            applied.  It is up to a pass to decide which information is
            relevant.  For example, the vectorizer passes print the source
            location of loops which are successfully vectorized.
!      ‘missed’
            Print information about missed optimizations.  Individual
            passes control which information to include in the output.
!      ‘note’
            Print verbose information about optimizations, such as certain
            transformations, more detailed messages about decisions etc.
!      ‘all’
            Print detailed optimization information.  This includes
!           ‘optimized’, ‘missed’, and ‘note’.
  
       The following option controls the dump verbosity:
  
!      ‘internals’
            By default, only "high-level" messages are emitted.  This
            option enables additional, more detailed, messages, which are
            likely to only be of interest to GCC developers.
*************** are created in the directory of the outp
*** 18335,18372 ****
       One or more of the following option keywords can be used to
       describe a group of optimizations:
  
!      'ipa'
            Enable dumps from all interprocedural optimizations.
!      'loop'
            Enable dumps from all loop optimizations.
!      'inline'
            Enable dumps from all inlining optimizations.
!      'omp'
            Enable dumps from all OMP (Offloading and Multi Processing)
            optimizations.
!      'vec'
            Enable dumps from all vectorization optimizations.
!      'optall'
            Enable dumps from all optimizations.  This is a superset of
            the optimization groups listed above.
  
!      If OPTIONS is omitted, it defaults to 'optimized-optall', which
       means to dump messages about successful optimizations from all the
       passes, omitting messages that are treated as "internals".
  
       If the FILENAME is provided, then the dumps from all the applicable
       optimizations are concatenated into the FILENAME.  Otherwise the
!      dump is output onto 'stderr'.  Though multiple '-fopt-info' options
       are accepted, only one of them can include a FILENAME.  If other
       filenames are provided then all but the first such option are
       ignored.
  
       Note that the output FILENAME is overwritten in case of multiple
       translation units.  If a combined output from multiple translation
!      units is desired, 'stderr' should be used instead.
  
       In the following example, the optimization info is output to
!      'stderr':
  
            gcc -O3 -fopt-info
  
--- 18339,18376 ----
       One or more of the following option keywords can be used to
       describe a group of optimizations:
  
!      ‘ipa’
            Enable dumps from all interprocedural optimizations.
!      ‘loop’
            Enable dumps from all loop optimizations.
!      ‘inline’
            Enable dumps from all inlining optimizations.
!      ‘omp’
            Enable dumps from all OMP (Offloading and Multi Processing)
            optimizations.
!      ‘vec’
            Enable dumps from all vectorization optimizations.
!      ‘optall’
            Enable dumps from all optimizations.  This is a superset of
            the optimization groups listed above.
  
!      If OPTIONS is omitted, it defaults to ‘optimized-optall’, which
       means to dump messages about successful optimizations from all the
       passes, omitting messages that are treated as "internals".
  
       If the FILENAME is provided, then the dumps from all the applicable
       optimizations are concatenated into the FILENAME.  Otherwise the
!      dump is output onto ‘stderr’.  Though multiple ‘-fopt-info’ options
       are accepted, only one of them can include a FILENAME.  If other
       filenames are provided then all but the first such option are
       ignored.
  
       Note that the output FILENAME is overwritten in case of multiple
       translation units.  If a combined output from multiple translation
!      units is desired, ‘stderr’ should be used instead.
  
       In the following example, the optimization info is output to
!      ‘stderr’:
  
            gcc -O3 -fopt-info
  
*************** are created in the directory of the outp
*** 18374,18474 ****
            gcc -O3 -fopt-info-missed=missed.all
  
       outputs missed optimization report from all the passes into
!      'missed.all', and this one:
  
            gcc -O2 -ftree-vectorize -fopt-info-vec-missed
  
       prints information about missed optimization opportunities from
!      vectorization passes on 'stderr'.  Note that
!      '-fopt-info-vec-missed' is equivalent to '-fopt-info-missed-vec'.
       The order of the optimization group names and message types listed
!      after '-fopt-info' does not matter.
  
       As another example,
            gcc -O3 -fopt-info-inline-optimized-missed=inline.txt
  
       outputs information about missed optimizations as well as optimized
!      locations from all the inlining passes into 'inline.txt'.
  
       Finally, consider:
  
            gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt
  
!      Here the two output filenames 'vec.miss' and 'loop.opt' are in
       conflict since only one output file is allowed.  In this case, only
       the first option takes effect and the subsequent options are
!      ignored.  Thus only 'vec.miss' is produced which contains dumps
       from the vectorizer about missed opportunities.
  
! '-fsave-optimization-record'
       Write a SRCFILE.opt-record.json.gz file detailing what
       optimizations were performed, for those optimizations that support
!      '-fopt-info'.
  
       This option is experimental and the format of the data within the
       compressed JSON file is subject to change.
  
       It is roughly equivalent to a machine-readable version of
!      '-fopt-info-all', as a collection of messages with source file,
       line number and column number, with the following additional data
       for each message:
  
!         * the execution count of the code being optimized, along with
            metadata about whether this was from actual profile data, or
            just an estimate, allowing consumers to prioritize messages by
            code hotness,
  
!         * the function name of the code being optimized, where
            applicable,
  
!         * the "inlining chain" for the code being optimized, so that
            when a function is inlined into several different places
            (which might themselves be inlined), the reader can
            distinguish between the copies,
  
!         * objects identifying those parts of the message that refer to
            expressions, statements or symbol-table nodes, which of these
            categories they are, and, when available, their source code
            location,
  
!         * the GCC pass that emitted the message, and
  
!         * the location in GCC's own code from which the message was
            emitted
  
       Additionally, some messages are logically nested within other
       messages, reflecting implementation details of the optimization
       passes.
  
! '-fsched-verbose=N'
       On targets that use instruction scheduling, this option controls
       the amount of debugging output the scheduler prints to the dump
       files.
  
!      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.
  
! '-fenable-KIND-PASS'
! '-fdisable-KIND-PASS=RANGE-LIST'
  
       This is a set of options that are used to explicitly disable/enable
       optimization passes.  These options are intended for use for
       debugging GCC. Compiler users should use regular options for
       enabling/disabling passes instead.
  
!      '-fdisable-ipa-PASS'
            Disable IPA pass PASS.  PASS is the pass name.  If the same
            pass is statically invoked in the compiler multiple times, the
            pass name should be appended with a sequential number starting
            from 1.
  
!      '-fdisable-rtl-PASS'
!      '-fdisable-rtl-PASS=RANGE-LIST'
            Disable RTL pass PASS.  PASS is the pass name.  If the same
            pass is statically invoked in the compiler multiple times, the
            pass name should be appended with a sequential number starting
--- 18378,18478 ----
            gcc -O3 -fopt-info-missed=missed.all
  
       outputs missed optimization report from all the passes into
!      ‘missed.all’, and this one:
  
            gcc -O2 -ftree-vectorize -fopt-info-vec-missed
  
       prints information about missed optimization opportunities from
!      vectorization passes on ‘stderr’.  Note that
!      ‘-fopt-info-vec-missed’ is equivalent to ‘-fopt-info-missed-vec’.
       The order of the optimization group names and message types listed
!      after ‘-fopt-info’ does not matter.
  
       As another example,
            gcc -O3 -fopt-info-inline-optimized-missed=inline.txt
  
       outputs information about missed optimizations as well as optimized
!      locations from all the inlining passes into ‘inline.txt’.
  
       Finally, consider:
  
            gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt
  
!      Here the two output filenames ‘vec.miss’ and ‘loop.opt’ are in
       conflict since only one output file is allowed.  In this case, only
       the first option takes effect and the subsequent options are
!      ignored.  Thus only ‘vec.miss’ is produced which contains dumps
       from the vectorizer about missed opportunities.
  
! ‘-fsave-optimization-record’
       Write a SRCFILE.opt-record.json.gz file detailing what
       optimizations were performed, for those optimizations that support
!      ‘-fopt-info’.
  
       This option is experimental and the format of the data within the
       compressed JSON file is subject to change.
  
       It is roughly equivalent to a machine-readable version of
!      ‘-fopt-info-all’, as a collection of messages with source file,
       line number and column number, with the following additional data
       for each message:
  
!         • the execution count of the code being optimized, along with
            metadata about whether this was from actual profile data, or
            just an estimate, allowing consumers to prioritize messages by
            code hotness,
  
!         • the function name of the code being optimized, where
            applicable,
  
!         • the "inlining chain" for the code being optimized, so that
            when a function is inlined into several different places
            (which might themselves be inlined), the reader can
            distinguish between the copies,
  
!         • objects identifying those parts of the message that refer to
            expressions, statements or symbol-table nodes, which of these
            categories they are, and, when available, their source code
            location,
  
!         • the GCC pass that emitted the message, and
  
!         • the location in GCC's own code from which the message was
            emitted
  
       Additionally, some messages are logically nested within other
       messages, reflecting implementation details of the optimization
       passes.
  
! ‘-fsched-verbose=N’
       On targets that use instruction scheduling, this option controls
       the amount of debugging output the scheduler prints to the dump
       files.
  
!      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.
  
! ‘-fenable-KIND-PASS’
! ‘-fdisable-KIND-PASS=RANGE-LIST’
  
       This is a set of options that are used to explicitly disable/enable
       optimization passes.  These options are intended for use for
       debugging GCC. Compiler users should use regular options for
       enabling/disabling passes instead.
  
!      ‘-fdisable-ipa-PASS’
            Disable IPA pass PASS.  PASS is the pass name.  If the same
            pass is statically invoked in the compiler multiple times, the
            pass name should be appended with a sequential number starting
            from 1.
  
!      ‘-fdisable-rtl-PASS’
!      ‘-fdisable-rtl-PASS=RANGE-LIST’
            Disable RTL pass PASS.  PASS is the pass name.  If the same
            pass is statically invoked in the compiler multiple times, the
            pass name should be appended with a sequential number starting
*************** are created in the directory of the outp
*** 18480,18506 ****
            falls within one of the specified ranges, the PASS is disabled
            for that function.  The UID is shown in the function header of
            a dump file, and the pass names can be dumped by using option
!           '-fdump-passes'.
  
!      '-fdisable-tree-PASS'
!      '-fdisable-tree-PASS=RANGE-LIST'
!           Disable tree pass PASS.  See '-fdisable-rtl' for the
            description of option arguments.
  
!      '-fenable-ipa-PASS'
            Enable IPA pass PASS.  PASS is the pass name.  If the same
            pass is statically invoked in the compiler multiple times, the
            pass name should be appended with a sequential number starting
            from 1.
  
!      '-fenable-rtl-PASS'
!      '-fenable-rtl-PASS=RANGE-LIST'
!           Enable RTL pass PASS.  See '-fdisable-rtl' for option argument
            description and examples.
  
!      '-fenable-tree-PASS'
!      '-fenable-tree-PASS=RANGE-LIST'
!           Enable tree pass PASS.  See '-fdisable-rtl' for the
            description of option arguments.
  
       Here are some examples showing uses of these options.
--- 18484,18510 ----
            falls within one of the specified ranges, the PASS is disabled
            for that function.  The UID is shown in the function header of
            a dump file, and the pass names can be dumped by using option
!           ‘-fdump-passes’.
  
!      ‘-fdisable-tree-PASS’
!      ‘-fdisable-tree-PASS=RANGE-LIST’
!           Disable tree pass PASS.  See ‘-fdisable-rtl’ for the
            description of option arguments.
  
!      ‘-fenable-ipa-PASS’
            Enable IPA pass PASS.  PASS is the pass name.  If the same
            pass is statically invoked in the compiler multiple times, the
            pass name should be appended with a sequential number starting
            from 1.
  
!      ‘-fenable-rtl-PASS’
!      ‘-fenable-rtl-PASS=RANGE-LIST’
!           Enable RTL pass PASS.  See ‘-fdisable-rtl’ for option argument
            description and examples.
  
!      ‘-fenable-tree-PASS’
!      ‘-fenable-tree-PASS=RANGE-LIST’
!           Enable tree pass PASS.  See ‘-fdisable-rtl’ for the
            description of option arguments.
  
       Here are some examples showing uses of these options.
*************** are created in the directory of the outp
*** 18522,18539 ****
               -fenable-tree-unroll
  
  
! '-fchecking'
! '-fchecking=N'
       Enable internal consistency checking.  The default depends on the
!      compiler configuration.  '-fchecking=2' enables further internal
       consistency checking that might affect code generation.
  
! '-frandom-seed=STRING'
       This option provides a seed that GCC uses in place of random
       numbers in generating certain symbol names that have to be
       different in every compiled file.  It is also used to place unique
       stamps in coverage data files and the object files that produce
!      them.  You can use the '-frandom-seed' option to produce
       reproducibly identical object files.
  
       The STRING can either be a number (decimal, octal or hex) or an
--- 18526,18543 ----
               -fenable-tree-unroll
  
  
! ‘-fchecking’
! ‘-fchecking=N’
       Enable internal consistency checking.  The default depends on the
!      compiler configuration.  ‘-fchecking=2’ enables further internal
       consistency checking that might affect code generation.
  
! ‘-frandom-seed=STRING’
       This option provides a seed that GCC uses in place of random
       numbers in generating certain symbol names that have to be
       different in every compiled file.  It is also used to place unique
       stamps in coverage data files and the object files that produce
!      them.  You can use the ‘-frandom-seed’ option to produce
       reproducibly identical object files.
  
       The STRING can either be a number (decimal, octal or hex) or an
*************** are created in the directory of the outp
*** 18542,18568 ****
  
       The STRING should be different for every file you compile.
  
! '-save-temps'
       Store the usual "temporary" intermediate files permanently; name
       them as auxiliary output files, as specified described under
!      '-dumpbase' and '-dumpdir'.
  
!      When used in combination with the '-x' command-line option,
!      '-save-temps' is sensible enough to avoid overwriting 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'.
  
! '-save-temps=cwd'
!      Equivalent to '-save-temps -dumpdir ./'.
  
! '-save-temps=obj'
!      Equivalent to '-save-temps -dumpdir outdir/', where 'outdir/' is
!      the directory of the output file specified after the '-o' option,
!      including any directory separators.  If the '-o' option is not
!      used, the '-save-temps=obj' switch behaves like '-save-temps=cwd'.
  
! '-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).
--- 18546,18572 ----
  
       The STRING should be different for every file you compile.
  
! ‘-save-temps’
       Store the usual "temporary" intermediate files permanently; name
       them as auxiliary output files, as specified described under
!      ‘-dumpbase’ and ‘-dumpdir’.
  
!      When used in combination with the ‘-x’ command-line option,
!      ‘-save-temps’ is sensible enough to avoid overwriting 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’.
  
! ‘-save-temps=cwd’
!      Equivalent to ‘-save-temps -dumpdir ./’.
  
! ‘-save-temps=obj’
!      Equivalent to ‘-save-temps -dumpdir outdir/’, where ‘outdir/’ is
!      the directory of the output file specified after the ‘-o’ option,
!      including any directory separators.  If the ‘-o’ option is not
!      used, the ‘-save-temps=obj’ switch behaves like ‘-save-temps=cwd’.
  
! ‘-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).
*************** are created in the directory of the outp
*** 18589,18702 ****
       one can later tell what file was being compiled, and with which
       options.
  
! '-fdump-final-insns[=FILE]'
       Dump the final internal representation (RTL) to FILE.  If the
!      optional argument is omitted (or if FILE is '.'), the name of the
!      dump file is determined by appending '.gkd' to the dump base name,
!      see '-dumpbase'.
  
! '-fcompare-debug[=OPTS]'
       If no error occurs during compilation, run the compiler a second
!      time, adding OPTS and '-fcompare-debug-second' to the arguments
       passed to the second compilation.  Dump the final internal
       representation in both compilations, and print an error if they
       differ.
  
!      If the equal sign is omitted, the default '-gtoggle' is used.
  
!      The environment variable 'GCC_COMPARE_DEBUG', if defined, non-empty
!      and nonzero, implicitly enables '-fcompare-debug'.  If
!      'GCC_COMPARE_DEBUG' is defined to a string starting with a dash,
!      then it is used for OPTS, otherwise the default '-gtoggle' is used.
  
!      '-fcompare-debug=', with the equal sign but without OPTS, is
!      equivalent to '-fno-compare-debug', which disables the dumping of
       the final representation and the second compilation, preventing
!      even 'GCC_COMPARE_DEBUG' from taking effect.
  
!      To verify full coverage during '-fcompare-debug' testing, set
!      'GCC_COMPARE_DEBUG' to say '-fcompare-debug-not-overridden', which
       GCC rejects as an invalid option in any actual compilation (rather
       than preprocessing, assembly or linking).  To get just a warning,
!      setting 'GCC_COMPARE_DEBUG' to '-w%n-fcompare-debug not overridden'
       will do.
  
! '-fcompare-debug-second'
       This option is implicitly passed to the compiler for the second
!      compilation requested by '-fcompare-debug', along with options to
       silence warnings, and omitting other options that would cause the
       compiler to produce output to files or to standard output as a side
       effect.  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.
  
! '-gtoggle'
       Turn off generation of debug info, if leaving out this option
       generates it, or turn it on at level 2 otherwise.  The position of
       this argument in the command line does not matter; it takes effect
       after all other options are processed, and it does so only once, no
       matter how many times it is given.  This is mainly intended to be
!      used with '-fcompare-debug'.
  
! '-fvar-tracking-assignments-toggle'
!      Toggle '-fvar-tracking-assignments', in the same way that
!      '-gtoggle' toggles '-g'.
  
! '-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.
  
! '-ftime-report-details'
       Record the time consumed by infrastructure parts separately for
       each pass.
  
! '-fira-verbose=N'
       Control the verbosity of the dump file for the integrated register
       allocator.  The default value is 5.  If the value N is greater or
       equal to 10, the dump output is sent to stderr using the same
       format as N minus 10.
  
! '-flto-report'
       Prints a report with internal details on the workings of the
       link-time optimizer.  The contents of this report vary from version
       to version.  It is meant to be useful to GCC developers when
!      processing object files in LTO mode (via '-flto').
  
       Disabled by default.
  
! '-flto-report-wpa'
!      Like '-flto-report', but only print for the WPA phase of link-time
       optimization.
  
! '-fmem-report'
       Makes the compiler print some statistics about permanent memory
       allocation when it finishes.
  
! '-fmem-report-wpa'
       Makes the compiler print some statistics about permanent memory
       allocation for the WPA phase only.
  
! '-fpre-ipa-mem-report'
! '-fpost-ipa-mem-report'
       Makes the compiler print some statistics about permanent memory
       allocation before or after interprocedural optimization.
  
! '-fmultiflags'
!      This option enables multilib-aware 'TFLAGS' to be used to build
       target libraries with options different from those the compiler is
       configured to use by default, through the use of specs (*Note Spec
       Files::) set up by compiler internals, by the target, or by
       builders at configure time.
  
!      Like 'TFLAGS', this allows the target libraries to be built for
       portable baseline environments, while the compiler defaults to more
       demanding ones.  That's useful because users can easily override
       the defaults the compiler is configured to use to build their own
--- 18593,18706 ----
       one can later tell what file was being compiled, and with which
       options.
  
! ‘-fdump-final-insns[=FILE]’
       Dump the final internal representation (RTL) to FILE.  If the
!      optional argument is omitted (or if FILE is ‘.’), the name of the
!      dump file is determined by appending ‘.gkd’ to the dump base name,
!      see ‘-dumpbase’.
  
! ‘-fcompare-debug[=OPTS]’
       If no error occurs during compilation, run the compiler a second
!      time, adding OPTS and ‘-fcompare-debug-second’ to the arguments
       passed to the second compilation.  Dump the final internal
       representation in both compilations, and print an error if they
       differ.
  
!      If the equal sign is omitted, the default ‘-gtoggle’ is used.
  
!      The environment variable ‘GCC_COMPARE_DEBUG’, if defined, non-empty
!      and nonzero, implicitly enables ‘-fcompare-debug’.  If
!      ‘GCC_COMPARE_DEBUG’ is defined to a string starting with a dash,
!      then it is used for OPTS, otherwise the default ‘-gtoggle’ is used.
  
!      ‘-fcompare-debug=’, with the equal sign but without OPTS, is
!      equivalent to ‘-fno-compare-debug’, which disables the dumping of
       the final representation and the second compilation, preventing
!      even ‘GCC_COMPARE_DEBUG’ from taking effect.
  
!      To verify full coverage during ‘-fcompare-debug’ testing, set
!      ‘GCC_COMPARE_DEBUG’ to say ‘-fcompare-debug-not-overridden’, which
       GCC rejects as an invalid option in any actual compilation (rather
       than preprocessing, assembly or linking).  To get just a warning,
!      setting ‘GCC_COMPARE_DEBUG’ to ‘-w%n-fcompare-debug not overridden’
       will do.
  
! ‘-fcompare-debug-second’
       This option is implicitly passed to the compiler for the second
!      compilation requested by ‘-fcompare-debug’, along with options to
       silence warnings, and omitting other options that would cause the
       compiler to produce output to files or to standard output as a side
       effect.  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.
  
! ‘-gtoggle’
       Turn off generation of debug info, if leaving out this option
       generates it, or turn it on at level 2 otherwise.  The position of
       this argument in the command line does not matter; it takes effect
       after all other options are processed, and it does so only once, no
       matter how many times it is given.  This is mainly intended to be
!      used with ‘-fcompare-debug’.
  
! ‘-fvar-tracking-assignments-toggle’
!      Toggle ‘-fvar-tracking-assignments’, in the same way that
!      ‘-gtoggle’ toggles ‘-g’.
  
! ‘-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.
  
! ‘-ftime-report-details’
       Record the time consumed by infrastructure parts separately for
       each pass.
  
! ‘-fira-verbose=N’
       Control the verbosity of the dump file for the integrated register
       allocator.  The default value is 5.  If the value N is greater or
       equal to 10, the dump output is sent to stderr using the same
       format as N minus 10.
  
! ‘-flto-report’
       Prints a report with internal details on the workings of the
       link-time optimizer.  The contents of this report vary from version
       to version.  It is meant to be useful to GCC developers when
!      processing object files in LTO mode (via ‘-flto’).
  
       Disabled by default.
  
! ‘-flto-report-wpa’
!      Like ‘-flto-report’, but only print for the WPA phase of link-time
       optimization.
  
! ‘-fmem-report’
       Makes the compiler print some statistics about permanent memory
       allocation when it finishes.
  
! ‘-fmem-report-wpa’
       Makes the compiler print some statistics about permanent memory
       allocation for the WPA phase only.
  
! ‘-fpre-ipa-mem-report’
! ‘-fpost-ipa-mem-report’
       Makes the compiler print some statistics about permanent memory
       allocation before or after interprocedural optimization.
  
! ‘-fmultiflags’
!      This option enables multilib-aware ‘TFLAGS’ to be used to build
       target libraries with options different from those the compiler is
       configured to use by default, through the use of specs (*Note Spec
       Files::) set up by compiler internals, by the target, or by
       builders at configure time.
  
!      Like ‘TFLAGS’, this allows the target libraries to be built for
       portable baseline environments, while the compiler defaults to more
       demanding ones.  That's useful because users can easily override
       the defaults the compiler is configured to use to build their own
*************** are created in the directory of the outp
*** 18704,18860 ****
       environment, whereas rebuilding the runtime libraries is usually
       not as easy or desirable.
  
!      Unlike 'TFLAGS', the use of specs enables different flags to be
       selected for different multilibs.  The way to accomplish that is to
!      build with 'make TFLAGS=-fmultiflags', after configuring
!      '--with-specs=%{fmultiflags:...}'.
  
       This option is discarded by the driver once it's done processing
       driver self spec.
  
!      It is also useful to check that 'TFLAGS' are being used to build
       all target libraries, by configuring a non-bootstrap compiler
!      '--with-specs='%{!fmultiflags:%emissing TFLAGS}'' and building the
       compiler and target libraries.
  
! '-fprofile-report'
       Makes the compiler print some statistics about consistency of the
       (estimated) profile and effect of individual passes.
  
! '-fstack-usage'
       Makes the compiler output stack usage information for the program,
       on a per-function basis.  The filename for the dump is made by
!      appending '.su' to the AUXNAME.  AUXNAME is generated from the name
       of the output file, if explicitly specified and it is not an
       executable, otherwise it is the basename of the source file.  An
       entry is made up of three fields:
  
!         * The name of the function.
!         * A number of bytes.
!         * One or more qualifiers: 'static', 'dynamic', 'bounded'.
  
!      The qualifier 'static' means that the function manipulates the
       stack statically: a fixed number of bytes are allocated for the
       frame on function entry and released on function exit; no stack
       adjustments are otherwise made in the function.  The second field
       is this fixed number of bytes.
  
!      The qualifier 'dynamic' means that the function manipulates the
       stack dynamically: in addition to the static allocation described
       above, stack adjustments are made in the body of the function, for
       example to push/pop arguments around function calls.  If the
!      qualifier 'bounded' is also present, the amount of these
       adjustments is bounded at compile time and the second field is an
       upper bound of the total amount of stack used by the function.  If
       it is not present, the amount of these adjustments is not bounded
       at compile time and the second field only represents the bounded
       part.
  
! '-fstats'
       Emit statistics about front-end processing at the end of the
       compilation.  This option is supported only by the C++ front end,
       and the information is generally only useful to the G++ development
       team.
  
! '-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 lower and upper bound.
       COUNTER-VALUE-LIST is a comma-separated list of
       NAME:LOWER_BOUND1-UPPER_BOUND1 [:LOWER_BOUND2-UPPER_BOUND2...]
       tuples which sets the name of the counter and list of closed
       intervals.  The LOWER_BOUND is optional and is zero initialized if
!      not set.  For example, with '-fdbg-cnt=dce:2-4:10-11,tail_call:10',
!      'dbg_cnt(dce)' returns true only for second, third, fourth, tenth
!      and eleventh invocation.  For 'dbg_cnt(tail_call)' true is returned
       for first 10 invocations.
  
! '-print-file-name=LIBRARY'
       Print the full absolute name of the library file LIBRARY that would
       be used when linking--and don't do anything else.  With this
       option, GCC does not compile or link anything; it just prints the
       file name.
  
! '-print-multi-directory'
       Print the directory name corresponding to the multilib selected by
       any other switches present in the command line.  This directory is
!      supposed to exist in 'GCC_EXEC_PREFIX'.
  
! '-print-multi-lib'
       Print the mapping from multilib directory names to compiler
       switches that enable them.  The directory name is separated from
!      the switches by ';', and each switch starts with an '@' instead of
!      the '-', without spaces between multiple switches.  This is
       supposed to ease shell processing.
  
! '-print-multi-os-directory'
       Print the path to OS libraries for the selected multilib, relative
!      to some 'lib' subdirectory.  If OS libraries are present in the
!      'lib' subdirectory and no multilibs are used, this is usually just
!      '.', if OS libraries are present in 'libSUFFIX' sibling directories
!      this prints e.g. '../lib64', '../lib' or '../lib32', or if OS
!      libraries are present in 'lib/SUBDIR' subdirectories it prints e.g.
!      'amd64', 'sparcv9' or 'ev6'.
  
! '-print-multiarch'
       Print the path to OS libraries for the selected multiarch, relative
!      to some 'lib' subdirectory.
  
! '-print-prog-name=PROGRAM'
!      Like '-print-file-name', but searches for a program such as 'cpp'.
  
! '-print-libgcc-file-name'
!      Same as '-print-file-name=libgcc.a'.
  
!      This is useful when you use '-nostdlib' or '-nodefaultlibs' but you
!      do want to link with 'libgcc.a'.  You can do:
  
            gcc -nostdlib FILES... `gcc -print-libgcc-file-name`
  
! '-print-search-dirs'
       Print the name of the configured installation directory and a list
!      of program and library directories 'gcc' searches--and don't do
       anything else.
  
!      This is useful when 'gcc' prints the error message 'installation
!      problem, cannot exec cpp0: No such file or directory'.  To resolve
!      this you either need to put 'cpp0' and the other compiler
!      components where 'gcc' expects to find them, or you can set the
!      environment variable 'GCC_EXEC_PREFIX' to the directory where you
!      installed them.  Don't forget the trailing '/'.  *Note Environment
       Variables::.
  
! '-print-sysroot'
       Print the target sysroot directory that is used during compilation.
       This is the target sysroot specified either at configure time or
!      using the '--sysroot' option, possibly with an extra suffix that
       depends on compilation options.  If no target sysroot is specified,
       the option prints nothing.
  
! '-print-sysroot-headers-suffix'
       Print the suffix added to the target sysroot when searching for
       headers, or give an error if the compiler is not configured with
       such a suffix--and don't do anything else.
  
! '-dumpmachine'
       Print the compiler's target machine (for example,
!      'i686-pc-linux-gnu')--and don't do anything else.
  
! '-dumpversion'
!      Print the compiler version (for example, '3.0', '6.3.0' or
!      '7')--and don't do anything else.  This is the compiler version
       used in filesystem paths and specs.  Depending on how the compiler
       has been configured it can be just a single number (major version),
       two numbers separated by a dot (major and minor version) or three
       numbers separated by dots (major, minor and patchlevel version).
  
! '-dumpfullversion'
       Print the full compiler version--and don't do anything else.  The
       output is always three numbers separated by dots, major, minor and
       patchlevel version.
  
! '-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::.
  
--- 18708,18864 ----
       environment, whereas rebuilding the runtime libraries is usually
       not as easy or desirable.
  
!      Unlike ‘TFLAGS’, the use of specs enables different flags to be
       selected for different multilibs.  The way to accomplish that is to
!      build with ‘make TFLAGS=-fmultiflags’, after configuring
!      ‘--with-specs=%{fmultiflags:...}’.
  
       This option is discarded by the driver once it's done processing
       driver self spec.
  
!      It is also useful to check that ‘TFLAGS’ are being used to build
       all target libraries, by configuring a non-bootstrap compiler
!      ‘--with-specs='%{!fmultiflags:%emissing TFLAGS}'’ and building the
       compiler and target libraries.
  
! ‘-fprofile-report’
       Makes the compiler print some statistics about consistency of the
       (estimated) profile and effect of individual passes.
  
! ‘-fstack-usage’
       Makes the compiler output stack usage information for the program,
       on a per-function basis.  The filename for the dump is made by
!      appending ‘.su’ to the AUXNAME.  AUXNAME is generated from the name
       of the output file, if explicitly specified and it is not an
       executable, otherwise it is the basename of the source file.  An
       entry is made up of three fields:
  
!         • The name of the function.
!         • A number of bytes.
!         • One or more qualifiers: ‘static’, ‘dynamic’, ‘bounded’.
  
!      The qualifier ‘static’ means that the function manipulates the
       stack statically: a fixed number of bytes are allocated for the
       frame on function entry and released on function exit; no stack
       adjustments are otherwise made in the function.  The second field
       is this fixed number of bytes.
  
!      The qualifier ‘dynamic’ means that the function manipulates the
       stack dynamically: in addition to the static allocation described
       above, stack adjustments are made in the body of the function, for
       example to push/pop arguments around function calls.  If the
!      qualifier ‘bounded’ is also present, the amount of these
       adjustments is bounded at compile time and the second field is an
       upper bound of the total amount of stack used by the function.  If
       it is not present, the amount of these adjustments is not bounded
       at compile time and the second field only represents the bounded
       part.
  
! ‘-fstats’
       Emit statistics about front-end processing at the end of the
       compilation.  This option is supported only by the C++ front end,
       and the information is generally only useful to the G++ development
       team.
  
! ‘-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 lower and upper bound.
       COUNTER-VALUE-LIST is a comma-separated list of
       NAME:LOWER_BOUND1-UPPER_BOUND1 [:LOWER_BOUND2-UPPER_BOUND2...]
       tuples which sets the name of the counter and list of closed
       intervals.  The LOWER_BOUND is optional and is zero initialized if
!      not set.  For example, with ‘-fdbg-cnt=dce:2-4:10-11,tail_call:10’,
!      ‘dbg_cnt(dce)’ returns true only for second, third, fourth, tenth
!      and eleventh invocation.  For ‘dbg_cnt(tail_call)’ true is returned
       for first 10 invocations.
  
! ‘-print-file-name=LIBRARY’
       Print the full absolute name of the library file LIBRARY that would
       be used when linking--and don't do anything else.  With this
       option, GCC does not compile or link anything; it just prints the
       file name.
  
! ‘-print-multi-directory’
       Print the directory name corresponding to the multilib selected by
       any other switches present in the command line.  This directory is
!      supposed to exist in ‘GCC_EXEC_PREFIX’.
  
! ‘-print-multi-lib’
       Print the mapping from multilib directory names to compiler
       switches that enable them.  The directory name is separated from
!      the switches by ‘;’, and each switch starts with an ‘@’ instead of
!      the ‘-’, without spaces between multiple switches.  This is
       supposed to ease shell processing.
  
! ‘-print-multi-os-directory’
       Print the path to OS libraries for the selected multilib, relative
!      to some ‘lib’ subdirectory.  If OS libraries are present in the
!      ‘lib’ subdirectory and no multilibs are used, this is usually just
!      ‘.’, if OS libraries are present in ‘libSUFFIX’ sibling directories
!      this prints e.g. ‘../lib64’, ‘../lib’ or ‘../lib32’, or if OS
!      libraries are present in ‘lib/SUBDIR’ subdirectories it prints e.g.
!      ‘amd64’, ‘sparcv9’ or ‘ev6’.
  
! ‘-print-multiarch’
       Print the path to OS libraries for the selected multiarch, relative
!      to some ‘lib’ subdirectory.
  
! ‘-print-prog-name=PROGRAM’
!      Like ‘-print-file-name’, but searches for a program such as ‘cpp’.
  
! ‘-print-libgcc-file-name’
!      Same as ‘-print-file-name=libgcc.a’.
  
!      This is useful when you use ‘-nostdlib’ or ‘-nodefaultlibs’ but you
!      do want to link with ‘libgcc.a’.  You can do:
  
            gcc -nostdlib FILES... `gcc -print-libgcc-file-name`
  
! ‘-print-search-dirs’
       Print the name of the configured installation directory and a list
!      of program and library directories ‘gcc’ searches--and don't do
       anything else.
  
!      This is useful when ‘gcc’ prints the error message ‘installation
!      problem, cannot exec cpp0: No such file or directory’.  To resolve
!      this you either need to put ‘cpp0’ and the other compiler
!      components where ‘gcc’ expects to find them, or you can set the
!      environment variable ‘GCC_EXEC_PREFIX’ to the directory where you
!      installed them.  Don't forget the trailing ‘/’.  *Note Environment
       Variables::.
  
! ‘-print-sysroot’
       Print the target sysroot directory that is used during compilation.
       This is the target sysroot specified either at configure time or
!      using the ‘--sysroot’ option, possibly with an extra suffix that
       depends on compilation options.  If no target sysroot is specified,
       the option prints nothing.
  
! ‘-print-sysroot-headers-suffix’
       Print the suffix added to the target sysroot when searching for
       headers, or give an error if the compiler is not configured with
       such a suffix--and don't do anything else.
  
! ‘-dumpmachine’
       Print the compiler's target machine (for example,
!      ‘i686-pc-linux-gnu’)--and don't do anything else.
  
! ‘-dumpversion’
!      Print the compiler version (for example, ‘3.0’, ‘6.3.0’ or
!      ‘7’)--and don't do anything else.  This is the compiler version
       used in filesystem paths and specs.  Depending on how the compiler
       has been configured it can be just a single number (major version),
       two numbers separated by a dot (major and minor version) or three
       numbers separated by dots (major, minor and patchlevel version).
  
! ‘-dumpfullversion’
       Print the full compiler version--and don't do anything else.  The
       output is always three numbers separated by dots, major, minor and
       patchlevel version.
  
! ‘-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::.
  
*************** File: gcc.info,  Node: Submodel Options,
*** 18867,18873 ****
  Each target machine supported by GCC can have its own options--for
  example, to allow you to compile for a particular processor variant or
  ABI, or to control optimizations specific to that machine.  By
! convention, the names of machine-specific options start with '-m'.
  
   Some configurations of the compiler also support additional
  target-specific options, usually for compatibility with other compilers
--- 18871,18877 ----
  Each target machine supported by GCC can have its own options--for
  example, to allow you to compile for a particular processor variant or
  ABI, or to control optimizations specific to that machine.  By
! convention, the names of machine-specific options start with ‘-m’.
  
   Some configurations of the compiler also support additional
  target-specific options, usually for compatibility with other compilers
*************** File: gcc.info,  Node: AArch64 Options,
*** 18942,18951 ****
  
  These options are defined for AArch64 implementations:
  
! '-mabi=NAME'
       Generate code for the specified data model.  Permissible values are
!      'ilp32' for SysV-like data model where int, long int and pointers
!      are 32 bits, and 'lp64' for SysV-like data model where int is 32
       bits, but long int and pointers are 64 bits.
  
       The default depends on the specific target configuration.  Note
--- 18946,18955 ----
  
  These options are defined for AArch64 implementations:
  
! ‘-mabi=NAME’
       Generate code for the specified data model.  Permissible values are
!      ‘ilp32’ for SysV-like data model where int, long int and pointers
!      are 32 bits, and ‘lp64’ for SysV-like data model where int is 32
       bits, but long int and pointers are 64 bits.
  
       The default depends on the specific target configuration.  Note
*************** These options are defined for AArch64 im
*** 18953,19075 ****
       compile your entire program with the same ABI, and link with a
       compatible set of libraries.
  
! '-mbig-endian'
       Generate big-endian code.  This is the default when GCC is
!      configured for an 'aarch64_be-*-*' target.
  
! '-mgeneral-regs-only'
       Generate code which uses only the general-purpose registers.  This
       will prevent the compiler from using floating-point and Advanced
       SIMD registers but will not impose any restrictions on the
       assembler.
  
! '-mlittle-endian'
       Generate little-endian code.  This is the default when GCC is
!      configured for an 'aarch64-*-*' but not an 'aarch64_be-*-*' target.
  
! '-mcmodel=tiny'
       Generate code for the tiny code model.  The program and its
       statically defined symbols must be within 1MB of each other.
       Programs can be statically or dynamically linked.
  
! '-mcmodel=small'
       Generate code for the small code model.  The program and its
       statically defined symbols must be within 4GB of each other.
       Programs can be statically or dynamically linked.  This is the
       default code model.
  
! '-mcmodel=large'
       Generate code for the large code model.  This makes no assumptions
       about addresses and sizes of sections.  Programs can be statically
!      linked only.  The '-mcmodel=large' option is incompatible with
!      '-mabi=ilp32', '-fpic' and '-fPIC'.
  
! '-mstrict-align'
! '-mno-strict-align'
       Avoid or allow generating memory accesses that may not be aligned
       on a natural object boundary as described in the architecture
       specification.
  
! '-momit-leaf-frame-pointer'
! '-mno-omit-leaf-frame-pointer'
       Omit or keep the frame pointer in leaf functions.  The former
       behavior is the default.
  
! '-mstack-protector-guard=GUARD'
! '-mstack-protector-guard-reg=REG'
! '-mstack-protector-guard-offset=OFFSET'
       Generate stack protection code using canary at GUARD.  Supported
!      locations are 'global' for a global canary or 'sysreg' for a canary
       in an appropriate system register.
  
       With the latter choice the options
!      '-mstack-protector-guard-reg=REG' and
!      '-mstack-protector-guard-offset=OFFSET' furthermore specify which
       system register to use as base register for reading the canary, and
       from what offset from that base register.  There is no default
       register or offset as this is entirely for use within the Linux
       kernel.
  
! '-mtls-dialect=desc'
       Use TLS descriptors as the thread-local storage mechanism for
       dynamic accesses of TLS variables.  This is the default.
  
! '-mtls-dialect=traditional'
       Use traditional TLS as the thread-local storage mechanism for
       dynamic accesses of TLS variables.
  
! '-mtls-size=SIZE'
       Specify bit size of immediate TLS offsets.  Valid values are 12,
       24, 32, 48.  This option requires binutils 2.26 or newer.
  
! '-mfix-cortex-a53-835769'
! '-mno-fix-cortex-a53-835769'
       Enable or disable the workaround for the ARM Cortex-A53 erratum
       number 835769.  This involves inserting a NOP instruction between
       memory instructions and 64-bit integer multiply-accumulate
       instructions.
  
! '-mfix-cortex-a53-843419'
! '-mno-fix-cortex-a53-843419'
       Enable or disable the workaround for the ARM Cortex-A53 erratum
       number 843419.  This erratum workaround is made at link time and
       this will only pass the corresponding flag to the linker.
  
! '-mlow-precision-recip-sqrt'
! '-mno-low-precision-recip-sqrt'
       Enable or disable the reciprocal square root approximation.  This
!      option only has an effect if '-ffast-math' or
!      '-funsafe-math-optimizations' is used as well.  Enabling this
       reduces precision of reciprocal square root results to about 16
       bits for single precision and to 32 bits for double precision.
  
! '-mlow-precision-sqrt'
! '-mno-low-precision-sqrt'
       Enable or disable the square root approximation.  This option only
!      has an effect if '-ffast-math' or '-funsafe-math-optimizations' is
       used as well.  Enabling this reduces precision of square root
       results to about 16 bits for single precision and to 32 bits for
       double precision.  If enabled, it implies
!      '-mlow-precision-recip-sqrt'.
  
! '-mlow-precision-div'
! '-mno-low-precision-div'
       Enable or disable the division approximation.  This option only has
!      an effect if '-ffast-math' or '-funsafe-math-optimizations' is used
       as well.  Enabling this reduces precision of division results to
       about 16 bits for single precision and to 32 bits for double
       precision.
  
! '-mtrack-speculation'
! '-mno-track-speculation'
       Enable or disable generation of additional code to track
       speculative execution through conditional branches.  The tracking
       state can then be used by the compiler when expanding calls to
!      '__builtin_speculation_safe_copy' to permit a more efficient code
       sequence to be generated.
  
! '-moutline-atomics'
! '-mno-outline-atomics'
       Enable or disable calls to out-of-line helpers to implement atomic
       operations.  These helpers will, at runtime, determine if the LSE
       instructions from ARMv8.1-A can be used; if not, they will use the
--- 18957,19079 ----
       compile your entire program with the same ABI, and link with a
       compatible set of libraries.
  
! ‘-mbig-endian’
       Generate big-endian code.  This is the default when GCC is
!      configured for an ‘aarch64_be-*-*’ target.
  
! ‘-mgeneral-regs-only’
       Generate code which uses only the general-purpose registers.  This
       will prevent the compiler from using floating-point and Advanced
       SIMD registers but will not impose any restrictions on the
       assembler.
  
! ‘-mlittle-endian’
       Generate little-endian code.  This is the default when GCC is
!      configured for an ‘aarch64-*-*’ but not an ‘aarch64_be-*-*’ target.
  
! ‘-mcmodel=tiny’
       Generate code for the tiny code model.  The program and its
       statically defined symbols must be within 1MB of each other.
       Programs can be statically or dynamically linked.
  
! ‘-mcmodel=small’
       Generate code for the small code model.  The program and its
       statically defined symbols must be within 4GB of each other.
       Programs can be statically or dynamically linked.  This is the
       default code model.
  
! ‘-mcmodel=large’
       Generate code for the large code model.  This makes no assumptions
       about addresses and sizes of sections.  Programs can be statically
!      linked only.  The ‘-mcmodel=large’ option is incompatible with
!      ‘-mabi=ilp32’, ‘-fpic’ and ‘-fPIC’.
  
! ‘-mstrict-align’
! ‘-mno-strict-align’
       Avoid or allow generating memory accesses that may not be aligned
       on a natural object boundary as described in the architecture
       specification.
  
! ‘-momit-leaf-frame-pointer’
! ‘-mno-omit-leaf-frame-pointer’
       Omit or keep the frame pointer in leaf functions.  The former
       behavior is the default.
  
! ‘-mstack-protector-guard=GUARD’
! ‘-mstack-protector-guard-reg=REG’
! ‘-mstack-protector-guard-offset=OFFSET’
       Generate stack protection code using canary at GUARD.  Supported
!      locations are ‘global’ for a global canary or ‘sysreg’ for a canary
       in an appropriate system register.
  
       With the latter choice the options
!      ‘-mstack-protector-guard-reg=REG’ and
!      ‘-mstack-protector-guard-offset=OFFSET’ furthermore specify which
       system register to use as base register for reading the canary, and
       from what offset from that base register.  There is no default
       register or offset as this is entirely for use within the Linux
       kernel.
  
! ‘-mtls-dialect=desc’
       Use TLS descriptors as the thread-local storage mechanism for
       dynamic accesses of TLS variables.  This is the default.
  
! ‘-mtls-dialect=traditional’
       Use traditional TLS as the thread-local storage mechanism for
       dynamic accesses of TLS variables.
  
! ‘-mtls-size=SIZE’
       Specify bit size of immediate TLS offsets.  Valid values are 12,
       24, 32, 48.  This option requires binutils 2.26 or newer.
  
! ‘-mfix-cortex-a53-835769’
! ‘-mno-fix-cortex-a53-835769’
       Enable or disable the workaround for the ARM Cortex-A53 erratum
       number 835769.  This involves inserting a NOP instruction between
       memory instructions and 64-bit integer multiply-accumulate
       instructions.
  
! ‘-mfix-cortex-a53-843419’
! ‘-mno-fix-cortex-a53-843419’
       Enable or disable the workaround for the ARM Cortex-A53 erratum
       number 843419.  This erratum workaround is made at link time and
       this will only pass the corresponding flag to the linker.
  
! ‘-mlow-precision-recip-sqrt’
! ‘-mno-low-precision-recip-sqrt’
       Enable or disable the reciprocal square root approximation.  This
!      option only has an effect if ‘-ffast-math’ or
!      ‘-funsafe-math-optimizations’ is used as well.  Enabling this
       reduces precision of reciprocal square root results to about 16
       bits for single precision and to 32 bits for double precision.
  
! ‘-mlow-precision-sqrt’
! ‘-mno-low-precision-sqrt’
       Enable or disable the square root approximation.  This option only
!      has an effect if ‘-ffast-math’ or ‘-funsafe-math-optimizations’ is
       used as well.  Enabling this reduces precision of square root
       results to about 16 bits for single precision and to 32 bits for
       double precision.  If enabled, it implies
!      ‘-mlow-precision-recip-sqrt’.
  
! ‘-mlow-precision-div’
! ‘-mno-low-precision-div’
       Enable or disable the division approximation.  This option only has
!      an effect if ‘-ffast-math’ or ‘-funsafe-math-optimizations’ is used
       as well.  Enabling this reduces precision of division results to
       about 16 bits for single precision and to 32 bits for double
       precision.
  
! ‘-mtrack-speculation’
! ‘-mno-track-speculation’
       Enable or disable generation of additional code to track
       speculative execution through conditional branches.  The tracking
       state can then be used by the compiler when expanding calls to
!      ‘__builtin_speculation_safe_copy’ to permit a more efficient code
       sequence to be generated.
  
! ‘-moutline-atomics’
! ‘-mno-outline-atomics’
       Enable or disable calls to out-of-line helpers to implement atomic
       operations.  These helpers will, at runtime, determine if the LSE
       instructions from ARMv8.1-A can be used; if not, they will use the
*************** These options are defined for AArch64 im
*** 19078,19158 ****
  
       This option is only applicable when compiling for the base ARMv8.0
       instruction set.  If using a later revision, e.g.
!      '-march=armv8.1-a' or '-march=armv8-a+lse', the ARMv8.1-Atomics
       instructions will be used directly.  The same applies when using
!      '-mcpu=' when the selected cpu supports the 'lse' feature.  This
       option is on by default.
  
! '-march=NAME'
       Specify the name of the target architecture and, optionally, one or
       more feature modifiers.  This option has the form
!      '-march=ARCH{+[no]FEATURE}*'.
  
       The table below summarizes the permissible values for ARCH and the
       features that they enable by default:
  
       ARCH value     Architecture   Includes by default
       --------------------------------------------------------------------------
!      'armv8-a'      Armv8-A        '+fp', '+simd'
!      'armv8.1-a'    Armv8.1-A      'armv8-a', '+crc', '+lse', '+rdma'
!      'armv8.2-a'    Armv8.2-A      'armv8.1-a'
!      'armv8.3-a'    Armv8.3-A      'armv8.2-a', '+pauth'
!      'armv8.4-a'    Armv8.4-A      'armv8.3-a', '+flagm', '+fp16fml',
!                                    '+dotprod'
!      'armv8.5-a'    Armv8.5-A      'armv8.4-a', '+sb', '+ssbs', '+predres'
!      'armv8.6-a'    Armv8.6-A      'armv8.5-a', '+bf16', '+i8mm'
!      'armv8.7-a'    Armv8.7-A      'armv8.6-a', '+ls64'
!      'armv8.8-a'    Armv8.8-a      'armv8.7-a', '+mops'
!      'armv9-a'      Armv9-A        'armv8.5-a', '+sve', '+sve2'
!      'armv9.1-a'    Armv9.1-A      'armv9-a', '+bf16', '+i8mm'
!      'armv9.2-a'    Armv9.2-A      'armv9.1-a', '+ls64'
!      'armv9.3-a'    Armv9.3-A      'armv9.2-a', '+mops'
!      'armv8-r'      Armv8-R        'armv8-r'
  
!      The value 'native' is available on native AArch64 GNU/Linux and
       causes the compiler to pick the architecture of the host system.
       This option has no effect if the compiler is unable to recognize
       the architecture of the host system,
  
       The permissible values for FEATURE are listed in the sub-section on
!      *note '-march' and '-mcpu' Feature Modifiers:
       aarch64-feature-modifiers.  Where conflicting feature modifiers are
       specified, the right-most feature is used.
  
       GCC uses NAME to determine what kind of instructions it can emit
!      when generating assembly code.  If '-march' is specified without
!      either of '-mtune' or '-mcpu' also being specified, the code is
       tuned to perform well across a range of target processors
       implementing the target architecture.
  
! '-mtune=NAME'
       Specify the name of the target processor for which GCC should tune
       the performance of the code.  Permissible values for this option
!      are: 'generic', 'cortex-a35', 'cortex-a53', 'cortex-a55',
!      'cortex-a57', 'cortex-a72', 'cortex-a73', 'cortex-a75',
!      'cortex-a76', 'cortex-a76ae', 'cortex-a77', 'cortex-a65',
!      'cortex-a65ae', 'cortex-a34', 'cortex-a78', 'cortex-a78ae',
!      'cortex-a78c', 'ares', 'exynos-m1', 'emag', 'falkor',
!      'neoverse-512tvb', 'neoverse-e1', 'neoverse-n1', 'neoverse-n2',
!      'neoverse-v1', 'neoverse-v2', 'grace', 'qdf24xx', 'saphira',
!      'phecda', 'xgene1', 'vulcan', 'octeontx', 'octeontx81',
!      'octeontx83', 'octeontx2', 'octeontx2t98', 'octeontx2t96'
!      'octeontx2t93', 'octeontx2f95', 'octeontx2f95n', 'octeontx2f95mm',
!      'a64fx', 'thunderx', 'thunderxt88', 'thunderxt88p1', 'thunderxt81',
!      'tsv110', 'thunderxt83', 'thunderx2t99', 'thunderx3t110', 'zeus',
!      'cortex-a57.cortex-a53', 'cortex-a72.cortex-a53',
!      'cortex-a73.cortex-a35', 'cortex-a73.cortex-a53',
!      'cortex-a75.cortex-a55', 'cortex-a76.cortex-a55', 'cortex-r82',
!      'cortex-x1', 'cortex-x1c', 'cortex-x2', 'cortex-x3', 'cortex-a510',
!      'cortex-a710', 'cortex-a715', 'ampere1', 'ampere1a', 'cobalt-100'
!      and 'native'.
  
!      The values 'cortex-a57.cortex-a53', 'cortex-a72.cortex-a53',
!      'cortex-a73.cortex-a35', 'cortex-a73.cortex-a53',
!      'cortex-a75.cortex-a55', 'cortex-a76.cortex-a55' specify that GCC
       should tune for a big.LITTLE system.
  
!      The value 'neoverse-512tvb' specifies that GCC should tune for
       Neoverse cores that (a) implement SVE and (b) have a total vector
       bandwidth of 512 bits per cycle.  In other words, the option tells
       GCC to tune for Neoverse cores that can execute 4 128-bit Advanced
--- 19082,19162 ----
  
       This option is only applicable when compiling for the base ARMv8.0
       instruction set.  If using a later revision, e.g.
!      ‘-march=armv8.1-a’ or ‘-march=armv8-a+lse’, the ARMv8.1-Atomics
       instructions will be used directly.  The same applies when using
!      ‘-mcpu=’ when the selected cpu supports the ‘lse’ feature.  This
       option is on by default.
  
! ‘-march=NAME’
       Specify the name of the target architecture and, optionally, one or
       more feature modifiers.  This option has the form
!      ‘-march=ARCH{+[no]FEATURE}*’.
  
       The table below summarizes the permissible values for ARCH and the
       features that they enable by default:
  
       ARCH value     Architecture   Includes by default
       --------------------------------------------------------------------------
!      ‘armv8-a’      Armv8-A        ‘+fp’, ‘+simd’
!      ‘armv8.1-a’    Armv8.1-A      ‘armv8-a’, ‘+crc’, ‘+lse’, ‘+rdma’
!      ‘armv8.2-a’    Armv8.2-A      ‘armv8.1-a’
!      ‘armv8.3-a’    Armv8.3-A      ‘armv8.2-a’, ‘+pauth’
!      ‘armv8.4-a’    Armv8.4-A      ‘armv8.3-a’, ‘+flagm’, ‘+fp16fml’,
!                                    ‘+dotprod’
!      ‘armv8.5-a’    Armv8.5-A      ‘armv8.4-a’, ‘+sb’, ‘+ssbs’, ‘+predres’
!      ‘armv8.6-a’    Armv8.6-A      ‘armv8.5-a’, ‘+bf16’, ‘+i8mm’
!      ‘armv8.7-a’    Armv8.7-A      ‘armv8.6-a’, ‘+ls64’
!      ‘armv8.8-a’    Armv8.8-a      ‘armv8.7-a’, ‘+mops’
!      ‘armv9-a’      Armv9-A        ‘armv8.5-a’, ‘+sve’, ‘+sve2’
!      ‘armv9.1-a’    Armv9.1-A      ‘armv9-a’, ‘+bf16’, ‘+i8mm’
!      ‘armv9.2-a’    Armv9.2-A      ‘armv9.1-a’, ‘+ls64’
!      ‘armv9.3-a’    Armv9.3-A      ‘armv9.2-a’, ‘+mops’
!      ‘armv8-r’      Armv8-R        ‘armv8-r’
  
!      The value ‘native’ is available on native AArch64 GNU/Linux and
       causes the compiler to pick the architecture of the host system.
       This option has no effect if the compiler is unable to recognize
       the architecture of the host system,
  
       The permissible values for FEATURE are listed in the sub-section on
!      *note ‘-march’ and ‘-mcpu’ Feature Modifiers:
       aarch64-feature-modifiers.  Where conflicting feature modifiers are
       specified, the right-most feature is used.
  
       GCC uses NAME to determine what kind of instructions it can emit
!      when generating assembly code.  If ‘-march’ is specified without
!      either of ‘-mtune’ or ‘-mcpu’ also being specified, the code is
       tuned to perform well across a range of target processors
       implementing the target architecture.
  
! ‘-mtune=NAME’
       Specify the name of the target processor for which GCC should tune
       the performance of the code.  Permissible values for this option
!      are: ‘generic’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’,
!      ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’,
!      ‘cortex-a76’, ‘cortex-a76ae’, ‘cortex-a77’, ‘cortex-a65’,
!      ‘cortex-a65ae’, ‘cortex-a34’, ‘cortex-a78’, ‘cortex-a78ae’,
!      ‘cortex-a78c’, ‘ares’, ‘exynos-m1’, ‘emag’, ‘falkor’,
!      ‘neoverse-512tvb’, ‘neoverse-e1’, ‘neoverse-n1’, ‘neoverse-n2’,
!      ‘neoverse-v1’, ‘neoverse-v2’, ‘grace’, ‘qdf24xx’, ‘saphira’,
!      ‘phecda’, ‘xgene1’, ‘vulcan’, ‘octeontx’, ‘octeontx81’,
!      ‘octeontx83’, ‘octeontx2’, ‘octeontx2t98’, ‘octeontx2t96’
!      ‘octeontx2t93’, ‘octeontx2f95’, ‘octeontx2f95n’, ‘octeontx2f95mm’,
!      ‘a64fx’, ‘thunderx’, ‘thunderxt88’, ‘thunderxt88p1’, ‘thunderxt81’,
!      ‘tsv110’, ‘thunderxt83’, ‘thunderx2t99’, ‘thunderx3t110’, ‘zeus’,
!      ‘cortex-a57.cortex-a53’, ‘cortex-a72.cortex-a53’,
!      ‘cortex-a73.cortex-a35’, ‘cortex-a73.cortex-a53’,
!      ‘cortex-a75.cortex-a55’, ‘cortex-a76.cortex-a55’, ‘cortex-r82’,
!      ‘cortex-x1’, ‘cortex-x1c’, ‘cortex-x2’, ‘cortex-x3’, ‘cortex-a510’,
!      ‘cortex-a710’, ‘cortex-a715’, ‘ampere1’, ‘ampere1a’, ‘cobalt-100’
!      and ‘native’.
  
!      The values ‘cortex-a57.cortex-a53’, ‘cortex-a72.cortex-a53’,
!      ‘cortex-a73.cortex-a35’, ‘cortex-a73.cortex-a53’,
!      ‘cortex-a75.cortex-a55’, ‘cortex-a76.cortex-a55’ specify that GCC
       should tune for a big.LITTLE system.
  
!      The value ‘neoverse-512tvb’ specifies that GCC should tune for
       Neoverse cores that (a) implement SVE and (b) have a total vector
       bandwidth of 512 bits per cycle.  In other words, the option tells
       GCC to tune for Neoverse cores that can execute 4 128-bit Advanced
*************** These options are defined for AArch64 im
*** 19162,19252 ****
       for a specific core like Neoverse V1 but is more specific than the
       default tuning described below.
  
!      Additionally on native AArch64 GNU/Linux systems the value 'native'
       tunes performance to the host system.  This option has no effect if
       the compiler is unable to recognize the processor of the host
       system.
  
!      Where none of '-mtune=', '-mcpu=' or '-march=' are specified, the
       code is tuned to perform well across a range of target processors.
  
       This option cannot be suffixed by feature modifiers.
  
! '-mcpu=NAME'
       Specify the name of the target processor, optionally suffixed by
       one or more feature modifiers.  This option has the form
!      '-mcpu=CPU{+[no]FEATURE}*', where the permissible values for CPU
!      are the same as those available for '-mtune'.  The permissible
       values for FEATURE are documented in the sub-section on *note
!      '-march' and '-mcpu' Feature Modifiers: aarch64-feature-modifiers.
       Where conflicting feature modifiers are specified, the right-most
       feature is used.
  
       GCC uses NAME to determine what kind of instructions it can emit
!      when generating assembly code (as if by '-march') and to determine
       the target processor for which to tune for performance (as if by
!      '-mtune').  Where this option is used in conjunction with '-march'
!      or '-mtune', those options take precedence over the appropriate
       part of this option.
  
!      '-mcpu=neoverse-512tvb' is special in that it does not refer to a
       specific core, but instead refers to all Neoverse cores that (a)
       implement SVE and (b) have a total vector bandwidth of 512 bits a
!      cycle.  Unless overridden by '-march', '-mcpu=neoverse-512tvb'
       generates code that can run on a Neoverse V1 core, since Neoverse
       V1 is the first Neoverse core with these properties.  Unless
!      overridden by '-mtune', '-mcpu=neoverse-512tvb' tunes code in the
!      same way as for '-mtune=neoverse-512tvb'.
  
! '-moverride=STRING'
       Override tuning decisions made by the back-end in response to a
!      '-mtune=' switch.  The syntax, semantics, and accepted values for
       STRING in this option are not guaranteed to be consistent across
       releases.
  
       This option is only intended to be useful when developing GCC.
  
! '-mverbose-cost-dump'
       Enable verbose cost model dumping in the debug dump files.  This
       option is provided for use in debugging the compiler.
  
! '-mpc-relative-literal-loads'
! '-mno-pc-relative-literal-loads'
       Enable or disable PC-relative literal loads.  With this option
       literal pools are accessed using a single instruction and emitted
       after each function.  This limits the maximum size of functions to
!      1MB. This is enabled by default for '-mcmodel=tiny'.
  
! '-msign-return-address=SCOPE'
       Select the function scope on which return address signing will be
!      applied.  Permissible values are 'none', which disables return
!      address signing, 'non-leaf', which enables pointer signing for
!      functions which are not leaf functions, and 'all', which enables
!      pointer signing for all functions.  The default value is 'none'.
       This option has been deprecated by -mbranch-protection.
  
! '-mbranch-protection=NONE|STANDARD|PAC-RET[+LEAF+B-KEY]|BTI'
!      Select the branch protection features to use.  'none' is the
!      default and turns off all types of branch protection.  'standard'
       turns on all types of branch protection features.  If a feature has
!      additional tuning options, then 'standard' sets it to its standard
!      level.  'pac-ret[+LEAF]' turns on return address signing to its
       standard level: signing functions that save the return address to
       memory (non-leaf functions will practically always do this) using
!      the a-key.  The optional argument 'leaf' can be used to extend the
!      signing to include leaf functions.  The optional argument 'b-key'
       can be used to sign the functions with the B-key instead of the
!      A-key.  'bti' turns on branch target identification mechanism.
  
! '-mharden-sls=OPTS'
       Enable compiler hardening against straight line speculation (SLS).
       OPTS is a comma-separated list of the following options:
!      'retbr'
!      'blr'
!      In addition, '-mharden-sls=all' enables all SLS hardening while
!      '-mharden-sls=none' disables all SLS hardening.
  
! '-msve-vector-bits=BITS'
       Specify the number of bits in an SVE vector register.  This option
       only has an effect when SVE is enabled.
  
--- 19166,19256 ----
       for a specific core like Neoverse V1 but is more specific than the
       default tuning described below.
  
!      Additionally on native AArch64 GNU/Linux systems the value ‘native’
       tunes performance to the host system.  This option has no effect if
       the compiler is unable to recognize the processor of the host
       system.
  
!      Where none of ‘-mtune=’, ‘-mcpu=’ or ‘-march=’ are specified, the
       code is tuned to perform well across a range of target processors.
  
       This option cannot be suffixed by feature modifiers.
  
! ‘-mcpu=NAME’
       Specify the name of the target processor, optionally suffixed by
       one or more feature modifiers.  This option has the form
!      ‘-mcpu=CPU{+[no]FEATURE}*’, where the permissible values for CPU
!      are the same as those available for ‘-mtune’.  The permissible
       values for FEATURE are documented in the sub-section on *note
!      ‘-march’ and ‘-mcpu’ Feature Modifiers: aarch64-feature-modifiers.
       Where conflicting feature modifiers are specified, the right-most
       feature is used.
  
       GCC uses NAME to determine what kind of instructions it can emit
!      when generating assembly code (as if by ‘-march’) and to determine
       the target processor for which to tune for performance (as if by
!      ‘-mtune’).  Where this option is used in conjunction with ‘-march’
!      or ‘-mtune’, those options take precedence over the appropriate
       part of this option.
  
!      ‘-mcpu=neoverse-512tvb’ is special in that it does not refer to a
       specific core, but instead refers to all Neoverse cores that (a)
       implement SVE and (b) have a total vector bandwidth of 512 bits a
!      cycle.  Unless overridden by ‘-march’, ‘-mcpu=neoverse-512tvb’
       generates code that can run on a Neoverse V1 core, since Neoverse
       V1 is the first Neoverse core with these properties.  Unless
!      overridden by ‘-mtune’, ‘-mcpu=neoverse-512tvb’ tunes code in the
!      same way as for ‘-mtune=neoverse-512tvb’.
  
! ‘-moverride=STRING’
       Override tuning decisions made by the back-end in response to a
!      ‘-mtune=’ switch.  The syntax, semantics, and accepted values for
       STRING in this option are not guaranteed to be consistent across
       releases.
  
       This option is only intended to be useful when developing GCC.
  
! ‘-mverbose-cost-dump’
       Enable verbose cost model dumping in the debug dump files.  This
       option is provided for use in debugging the compiler.
  
! ‘-mpc-relative-literal-loads’
! ‘-mno-pc-relative-literal-loads’
       Enable or disable PC-relative literal loads.  With this option
       literal pools are accessed using a single instruction and emitted
       after each function.  This limits the maximum size of functions to
!      1MB. This is enabled by default for ‘-mcmodel=tiny’.
  
! ‘-msign-return-address=SCOPE’
       Select the function scope on which return address signing will be
!      applied.  Permissible values are ‘none’, which disables return
!      address signing, ‘non-leaf’, which enables pointer signing for
!      functions which are not leaf functions, and ‘all’, which enables
!      pointer signing for all functions.  The default value is ‘none’.
       This option has been deprecated by -mbranch-protection.
  
! ‘-mbranch-protection=NONE|STANDARD|PAC-RET[+LEAF+B-KEY]|BTI’
!      Select the branch protection features to use.  ‘none’ is the
!      default and turns off all types of branch protection.  ‘standard’
       turns on all types of branch protection features.  If a feature has
!      additional tuning options, then ‘standard’ sets it to its standard
!      level.  ‘pac-ret[+LEAF]’ turns on return address signing to its
       standard level: signing functions that save the return address to
       memory (non-leaf functions will practically always do this) using
!      the a-key.  The optional argument ‘leaf’ can be used to extend the
!      signing to include leaf functions.  The optional argument ‘b-key’
       can be used to sign the functions with the B-key instead of the
!      A-key.  ‘bti’ turns on branch target identification mechanism.
  
! ‘-mharden-sls=OPTS’
       Enable compiler hardening against straight line speculation (SLS).
       OPTS is a comma-separated list of the following options:
!      ‘retbr’
!      ‘blr’
!      In addition, ‘-mharden-sls=all’ enables all SLS hardening while
!      ‘-mharden-sls=none’ disables all SLS hardening.
  
! ‘-msve-vector-bits=BITS’
       Specify the number of bits in an SVE vector register.  This option
       only has an effect when SVE is enabled.
  
*************** These options are defined for AArch64 im
*** 19254,19407 ****
       agnostic" output that works with any size of vector register and
       "vector-length specific" output that allows GCC to make assumptions
       about the vector length when it is useful for optimization reasons.
!      The possible values of 'bits' are: 'scalable', '128', '256', '512',
!      '1024' and '2048'.  Specifying 'scalable' selects vector-length
!      agnostic output.  At present '-msve-vector-bits=128' also generates
       vector-length agnostic output for big-endian targets.  All other
       values generate vector-length specific code.  The behavior of these
!      values may change in future releases and no value except 'scalable'
       should be relied on for producing code that is portable across
       different hardware SVE vector lengths.
  
!      The default is '-msve-vector-bits=scalable', which produces
       vector-length agnostic code.
  
! 3.19.1.1 '-march' and '-mcpu' Feature Modifiers
  ...............................................
  
! Feature modifiers used with '-march' and '-mcpu' can be any of the
! following and their inverses 'noFEATURE':
  
! 'crc'
       Enable CRC extension.  This is on by default for
!      '-march=armv8.1-a'.
! 'crypto'
       Enable Crypto extension.  This also enables Advanced SIMD and
       floating-point instructions.
! 'fp'
       Enable floating-point instructions.  This is on by default for all
!      possible values for options '-march' and '-mcpu'.
! 'simd'
       Enable Advanced SIMD instructions.  This also enables
       floating-point instructions.  This is on by default for all
!      possible values for options '-march' and '-mcpu'.
! 'sve'
       Enable Scalable Vector Extension instructions.  This also enables
       Advanced SIMD and floating-point instructions.
! 'lse'
       Enable Large System Extension instructions.  This is on by default
!      for '-march=armv8.1-a'.
! 'rdma'
       Enable Round Double Multiply Accumulate instructions.  This is on
!      by default for '-march=armv8.1-a'.
! 'fp16'
       Enable FP16 extension.  This also enables floating-point
       instructions.
! 'fp16fml'
       Enable FP16 fmla extension.  This also enables FP16 extensions and
       floating-point instructions.  This option is enabled by default for
!      '-march=armv8.4-a'.  Use of this option with architectures prior to
       Armv8.2-A is not supported.
  
! 'rcpc'
       Enable the RCpc extension.  This enables the use of the LDAPR
       instructions for load-acquire atomic semantics, and passes it on to
       the assembler, enabling inline asm statements to use instructions
       from the RCpc extension.
! 'dotprod'
       Enable the Dot Product extension.  This also enables Advanced SIMD
       instructions.
! 'aes'
       Enable the Armv8-a aes and pmull crypto extension.  This also
       enables Advanced SIMD instructions.
! 'sha2'
       Enable the Armv8-a sha2 crypto extension.  This also enables
       Advanced SIMD instructions.
! 'sha3'
       Enable the sha512 and sha3 crypto extension.  This also enables
       Advanced SIMD instructions.  Use of this option with architectures
       prior to Armv8.2-A is not supported.
! 'sm4'
       Enable the sm3 and sm4 crypto extension.  This also enables
       Advanced SIMD instructions.  Use of this option with architectures
       prior to Armv8.2-A is not supported.
! 'profile'
       Enable the Statistical Profiling extension.  This option is only to
       enable the extension at the assembler level and does not affect
       code generation.
! 'rng'
       Enable the Armv8.5-a Random Number instructions.  This option is
       only to enable the extension at the assembler level and does not
       affect code generation.
! 'memtag'
       Enable the Armv8.5-a Memory Tagging Extensions.  Use of this option
       with architectures prior to Armv8.5-A is not supported.
! 'sb'
       Enable the Armv8-a Speculation Barrier instruction.  This option is
       only to enable the extension at the assembler level and does not
       affect code generation.  This option is enabled by default for
!      '-march=armv8.5-a'.
! 'ssbs'
       Enable the Armv8-a Speculative Store Bypass Safe instruction.  This
       option is only to enable the extension at the assembler level and
       does not affect code generation.  This option is enabled by default
!      for '-march=armv8.5-a'.
! 'predres'
       Enable the Armv8-a Execution and Data Prediction Restriction
       instructions.  This option is only to enable the extension at the
       assembler level and does not affect code generation.  This option
!      is enabled by default for '-march=armv8.5-a'.
! 'sve2'
       Enable the Armv8-a Scalable Vector Extension 2.  This also enables
       SVE instructions.
! 'sve2-bitperm'
       Enable SVE2 bitperm instructions.  This also enables SVE2
       instructions.
! 'sve2-sm4'
       Enable SVE2 sm4 instructions.  This also enables SVE2 instructions.
! 'sve2-aes'
       Enable SVE2 aes instructions.  This also enables SVE2 instructions.
! 'sve2-sha3'
       Enable SVE2 sha3 instructions.  This also enables SVE2
       instructions.
! 'tme'
       Enable the Transactional Memory Extension.
! 'i8mm'
       Enable 8-bit Integer Matrix Multiply instructions.  This also
       enables Advanced SIMD and floating-point instructions.  This option
!      is enabled by default for '-march=armv8.6-a'.  Use of this option
       with architectures prior to Armv8.2-A is not supported.
! 'f32mm'
       Enable 32-bit Floating point Matrix Multiply instructions.  This
       also enables SVE instructions.  Use of this option with
       architectures prior to Armv8.2-A is not supported.
! 'f64mm'
       Enable 64-bit Floating point Matrix Multiply instructions.  This
       also enables SVE instructions.  Use of this option with
       architectures prior to Armv8.2-A is not supported.
! 'bf16'
       Enable brain half-precision floating-point instructions.  This also
       enables Advanced SIMD and floating-point instructions.  This option
!      is enabled by default for '-march=armv8.6-a'.  Use of this option
       with architectures prior to Armv8.2-A is not supported.
! 'ls64'
       Enable the 64-byte atomic load and store instructions for
       accelerators.  This option is enabled by default for
!      '-march=armv8.7-a'.
! 'mops'
       Enable the instructions to accelerate memory operations like
!      'memcpy', 'memmove', 'memset'.  This option is enabled by default
!      for '-march=armv8.8-a'
! 'flagm'
       Enable the Flag Manipulation instructions Extension.
! 'pauth'
       Enable the Pointer Authentication Extension.
! 'cssc'
       Enable the Common Short Sequence Compression instructions.
  
!  Feature 'crypto' implies 'aes', 'sha2', and 'simd', which implies 'fp'.
! Conversely, 'nofp' implies 'nosimd', which implies 'nocrypto', 'noaes'
! and 'nosha2'.
  
  
  File: gcc.info,  Node: Adapteva Epiphany Options,  Next: AMD GCN Options,  Prev: AArch64 Options,  Up: Submodel Options
--- 19258,19411 ----
       agnostic" output that works with any size of vector register and
       "vector-length specific" output that allows GCC to make assumptions
       about the vector length when it is useful for optimization reasons.
!      The possible values of ‘bits’ are: ‘scalable’, ‘128’, ‘256’, ‘512’,
!      ‘1024’ and ‘2048’.  Specifying ‘scalable’ selects vector-length
!      agnostic output.  At present ‘-msve-vector-bits=128’ also generates
       vector-length agnostic output for big-endian targets.  All other
       values generate vector-length specific code.  The behavior of these
!      values may change in future releases and no value except ‘scalable’
       should be relied on for producing code that is portable across
       different hardware SVE vector lengths.
  
!      The default is ‘-msve-vector-bits=scalable’, which produces
       vector-length agnostic code.
  
! 3.19.1.1 ‘-march’ and ‘-mcpu’ Feature Modifiers
  ...............................................
  
! Feature modifiers used with ‘-march’ and ‘-mcpu’ can be any of the
! following and their inverses ‘noFEATURE’:
  
! ‘crc’
       Enable CRC extension.  This is on by default for
!      ‘-march=armv8.1-a’.
! ‘crypto’
       Enable Crypto extension.  This also enables Advanced SIMD and
       floating-point instructions.
! ‘fp’
       Enable floating-point instructions.  This is on by default for all
!      possible values for options ‘-march’ and ‘-mcpu’.
! ‘simd’
       Enable Advanced SIMD instructions.  This also enables
       floating-point instructions.  This is on by default for all
!      possible values for options ‘-march’ and ‘-mcpu’.
! ‘sve’
       Enable Scalable Vector Extension instructions.  This also enables
       Advanced SIMD and floating-point instructions.
! ‘lse’
       Enable Large System Extension instructions.  This is on by default
!      for ‘-march=armv8.1-a’.
! ‘rdma’
       Enable Round Double Multiply Accumulate instructions.  This is on
!      by default for ‘-march=armv8.1-a’.
! ‘fp16’
       Enable FP16 extension.  This also enables floating-point
       instructions.
! ‘fp16fml’
       Enable FP16 fmla extension.  This also enables FP16 extensions and
       floating-point instructions.  This option is enabled by default for
!      ‘-march=armv8.4-a’.  Use of this option with architectures prior to
       Armv8.2-A is not supported.
  
! ‘rcpc’
       Enable the RCpc extension.  This enables the use of the LDAPR
       instructions for load-acquire atomic semantics, and passes it on to
       the assembler, enabling inline asm statements to use instructions
       from the RCpc extension.
! ‘dotprod’
       Enable the Dot Product extension.  This also enables Advanced SIMD
       instructions.
! ‘aes’
       Enable the Armv8-a aes and pmull crypto extension.  This also
       enables Advanced SIMD instructions.
! ‘sha2’
       Enable the Armv8-a sha2 crypto extension.  This also enables
       Advanced SIMD instructions.
! ‘sha3’
       Enable the sha512 and sha3 crypto extension.  This also enables
       Advanced SIMD instructions.  Use of this option with architectures
       prior to Armv8.2-A is not supported.
! ‘sm4’
       Enable the sm3 and sm4 crypto extension.  This also enables
       Advanced SIMD instructions.  Use of this option with architectures
       prior to Armv8.2-A is not supported.
! ‘profile’
       Enable the Statistical Profiling extension.  This option is only to
       enable the extension at the assembler level and does not affect
       code generation.
! ‘rng’
       Enable the Armv8.5-a Random Number instructions.  This option is
       only to enable the extension at the assembler level and does not
       affect code generation.
! ‘memtag’
       Enable the Armv8.5-a Memory Tagging Extensions.  Use of this option
       with architectures prior to Armv8.5-A is not supported.
! ‘sb’
       Enable the Armv8-a Speculation Barrier instruction.  This option is
       only to enable the extension at the assembler level and does not
       affect code generation.  This option is enabled by default for
!      ‘-march=armv8.5-a’.
! ‘ssbs’
       Enable the Armv8-a Speculative Store Bypass Safe instruction.  This
       option is only to enable the extension at the assembler level and
       does not affect code generation.  This option is enabled by default
!      for ‘-march=armv8.5-a’.
! ‘predres’
       Enable the Armv8-a Execution and Data Prediction Restriction
       instructions.  This option is only to enable the extension at the
       assembler level and does not affect code generation.  This option
!      is enabled by default for ‘-march=armv8.5-a’.
! ‘sve2’
       Enable the Armv8-a Scalable Vector Extension 2.  This also enables
       SVE instructions.
! ‘sve2-bitperm’
       Enable SVE2 bitperm instructions.  This also enables SVE2
       instructions.
! ‘sve2-sm4’
       Enable SVE2 sm4 instructions.  This also enables SVE2 instructions.
! ‘sve2-aes’
       Enable SVE2 aes instructions.  This also enables SVE2 instructions.
! ‘sve2-sha3’
       Enable SVE2 sha3 instructions.  This also enables SVE2
       instructions.
! ‘tme’
       Enable the Transactional Memory Extension.
! ‘i8mm’
       Enable 8-bit Integer Matrix Multiply instructions.  This also
       enables Advanced SIMD and floating-point instructions.  This option
!      is enabled by default for ‘-march=armv8.6-a’.  Use of this option
       with architectures prior to Armv8.2-A is not supported.
! ‘f32mm’
       Enable 32-bit Floating point Matrix Multiply instructions.  This
       also enables SVE instructions.  Use of this option with
       architectures prior to Armv8.2-A is not supported.
! ‘f64mm’
       Enable 64-bit Floating point Matrix Multiply instructions.  This
       also enables SVE instructions.  Use of this option with
       architectures prior to Armv8.2-A is not supported.
! ‘bf16’
       Enable brain half-precision floating-point instructions.  This also
       enables Advanced SIMD and floating-point instructions.  This option
!      is enabled by default for ‘-march=armv8.6-a’.  Use of this option
       with architectures prior to Armv8.2-A is not supported.
! ‘ls64’
       Enable the 64-byte atomic load and store instructions for
       accelerators.  This option is enabled by default for
!      ‘-march=armv8.7-a’.
! ‘mops’
       Enable the instructions to accelerate memory operations like
!      ‘memcpy’, ‘memmove’, ‘memset’.  This option is enabled by default
!      for ‘-march=armv8.8-a’
! ‘flagm’
       Enable the Flag Manipulation instructions Extension.
! ‘pauth’
       Enable the Pointer Authentication Extension.
! ‘cssc’
       Enable the Common Short Sequence Compression instructions.
  
!  Feature ‘crypto’ implies ‘aes’, ‘sha2’, and ‘simd’, which implies ‘fp’.
! Conversely, ‘nofp’ implies ‘nosimd’, which implies ‘nocrypto’, ‘noaes’
! and ‘nosha2’.
  
  
  File: gcc.info,  Node: Adapteva Epiphany Options,  Next: AMD GCN Options,  Prev: AArch64 Options,  Up: Submodel Options
*************** File: gcc.info,  Node: Adapteva Epiphany
*** 19409,19449 ****
  3.19.2 Adapteva Epiphany Options
  --------------------------------
  
! These '-m' options are defined for Adapteva Epiphany:
  
! '-mhalf-reg-file'
!      Don't allocate any register in the range 'r32'...'r63'.  That
       allows code to run on hardware variants that lack these registers.
  
! '-mprefer-short-insn-regs'
       Preferentially allocate registers that allow short instruction
       generation.  This can result in increased instruction count, so
       this may either reduce or increase overall code size.
  
! '-mbranch-cost=NUM'
       Set the cost of branches to roughly NUM "simple" instructions.
       This cost is only a heuristic and is not guaranteed to produce
       consistent results across releases.
  
! '-mcmove'
       Enable the generation of conditional moves.
  
! '-mnops=NUM'
       Emit NUM NOPs before every other generated instruction.
  
! '-mno-soft-cmpsf'
!      For single-precision floating-point comparisons, emit an 'fsub'
       instruction and test the flags.  This is faster than a software
       comparison, but can get incorrect results in the presence of NaNs,
       or when two different small numbers are compared such that their
!      difference is calculated as zero.  The default is '-msoft-cmpsf',
       which uses slower, but IEEE-compliant, software comparisons.
  
! '-mstack-offset=NUM'
       Set the offset between the top of the stack and the stack pointer.
       E.g., a value of 8 means that the eight bytes in the range
!      'sp+0...sp+7' can be used by leaf functions without stack
!      allocation.  Values other than '8' or '16' are untested and
       unlikely to work.  Note also that this option changes the ABI;
       compiling a program with a different stack offset than the
       libraries have been compiled with generally does not work.  This
--- 19413,19453 ----
  3.19.2 Adapteva Epiphany Options
  --------------------------------
  
! These ‘-m’ options are defined for Adapteva Epiphany:
  
! ‘-mhalf-reg-file’
!      Don't allocate any register in the range ‘r32’...‘r63’.  That
       allows code to run on hardware variants that lack these registers.
  
! ‘-mprefer-short-insn-regs’
       Preferentially allocate registers that allow short instruction
       generation.  This can result in increased instruction count, so
       this may either reduce or increase overall code size.
  
! ‘-mbranch-cost=NUM’
       Set the cost of branches to roughly NUM "simple" instructions.
       This cost is only a heuristic and is not guaranteed to produce
       consistent results across releases.
  
! ‘-mcmove’
       Enable the generation of conditional moves.
  
! ‘-mnops=NUM’
       Emit NUM NOPs before every other generated instruction.
  
! ‘-mno-soft-cmpsf’
!      For single-precision floating-point comparisons, emit an ‘fsub’
       instruction and test the flags.  This is faster than a software
       comparison, but can get incorrect results in the presence of NaNs,
       or when two different small numbers are compared such that their
!      difference is calculated as zero.  The default is ‘-msoft-cmpsf’,
       which uses slower, but IEEE-compliant, software comparisons.
  
! ‘-mstack-offset=NUM’
       Set the offset between the top of the stack and the stack pointer.
       E.g., a value of 8 means that the eight bytes in the range
!      ‘sp+0...sp+7’ can be used by leaf functions without stack
!      allocation.  Values other than ‘8’ or ‘16’ are untested and
       unlikely to work.  Note also that this option changes the ABI;
       compiling a program with a different stack offset than the
       libraries have been compiled with generally does not work.  This
*************** These '-m' options are defined for Adapt
*** 19451,19479 ****
       offset would give you better code, but to actually use a different
       stack offset to build working programs, it is recommended to
       configure the toolchain with the appropriate
!      '--with-stack-offset=NUM' option.
  
! '-mno-round-nearest'
       Make the scheduler assume that the rounding mode has been set to
!      truncating.  The default is '-mround-nearest'.
  
! '-mlong-calls'
       If not otherwise specified by an attribute, assume all calls might
!      be beyond the offset range of the 'b' / 'bl' instructions, and
       therefore load the function address into a register before
       performing a (otherwise direct) call.  This is the default.
  
! '-mshort-calls'
       If not otherwise specified by an attribute, assume all direct calls
!      are in the range of the 'b' / 'bl' instructions, so use these
!      instructions for direct calls.  The default is '-mlong-calls'.
  
! '-msmall16'
       Assume addresses can be loaded as 16-bit unsigned values.  This
!      does not apply to function addresses for which '-mlong-calls'
       semantics are in effect.
  
! '-mfp-mode=MODE'
       Set the prevailing mode of the floating-point unit.  This
       determines the floating-point mode that is provided and expected at
       function call and return time.  Making this mode match the mode you
--- 19455,19483 ----
       offset would give you better code, but to actually use a different
       stack offset to build working programs, it is recommended to
       configure the toolchain with the appropriate
!      ‘--with-stack-offset=NUM’ option.
  
! ‘-mno-round-nearest’
       Make the scheduler assume that the rounding mode has been set to
!      truncating.  The default is ‘-mround-nearest’.
  
! ‘-mlong-calls’
       If not otherwise specified by an attribute, assume all calls might
!      be beyond the offset range of the ‘b’ / ‘bl’ instructions, and
       therefore load the function address into a register before
       performing a (otherwise direct) call.  This is the default.
  
! ‘-mshort-calls’
       If not otherwise specified by an attribute, assume all direct calls
!      are in the range of the ‘b’ / ‘bl’ instructions, so use these
!      instructions for direct calls.  The default is ‘-mlong-calls’.
  
! ‘-msmall16’
       Assume addresses can be loaded as 16-bit unsigned values.  This
!      does not apply to function addresses for which ‘-mlong-calls’
       semantics are in effect.
  
! ‘-mfp-mode=MODE’
       Set the prevailing mode of the floating-point unit.  This
       determines the floating-point mode that is provided and expected at
       function call and return time.  Making this mode match the mode you
*************** These '-m' options are defined for Adapt
*** 19482,19488 ****
  
       MODE can be set to one the following values:
  
!      'caller'
            Any mode at function entry is valid, and retained or restored
            when the function returns, and when it calls other functions.
            This mode is useful for compiling libraries or other
--- 19486,19492 ----
  
       MODE can be set to one the following values:
  
!      ‘caller’
            Any mode at function entry is valid, and retained or restored
            when the function returns, and when it calls other functions.
            This mode is useful for compiling libraries or other
*************** These '-m' options are defined for Adapt
*** 19493,19544 ****
            switching that might be needed, compared with what would be
            needed with a more specific choice of prevailing FPU mode.
  
!      'truncate'
            This is the mode used for floating-point calculations with
            truncating (i.e. round towards zero) rounding mode.  That
            includes conversion from floating point to integer.
  
!      'round-nearest'
            This is the mode used for floating-point calculations with
            round-to-nearest-or-even rounding mode.
  
!      'int'
            This is the mode used to perform integer calculations in the
            FPU, e.g. integer multiply, or integer
            multiply-and-accumulate.
  
!      The default is '-mfp-mode=caller'
  
! '-mno-split-lohi'
! '-mno-postinc'
! '-mno-postmodify'
       Code generation tweaks that disable, respectively, splitting of
       32-bit loads, generation of post-increment addresses, and
       generation of post-modify addresses.  The defaults are
!      'msplit-lohi', '-mpost-inc', and '-mpost-modify'.
  
! '-mnovect-double'
       Change the preferred SIMD mode to SImode.  The default is
!      '-mvect-double', which uses DImode as preferred SIMD mode.
  
! '-max-vect-align=NUM'
       The maximum alignment for SIMD vector mode types.  NUM may be 4 or
       8.  The default is 8.  Note that this is an ABI change, even though
       many library function interfaces are unaffected if they don't use
       SIMD vector modes in places that affect size and/or alignment of
       relevant types.
  
! '-msplit-vecmove-early'
       Split vector moves into single word moves before reload.  In theory
       this can give better register allocation, but so far the reverse
       seems to be generally the case.
  
! '-m1reg-REG'
!      Specify a register to hold the constant -1, which makes loading
       small negative constants and certain bitmasks faster.  Allowable
!      values for REG are 'r43' and 'r63', which specify use of that
!      register as a fixed register, and 'none', which means that no
!      register is used for this purpose.  The default is '-m1reg-none'.
  
  
  File: gcc.info,  Node: AMD GCN Options,  Next: ARC Options,  Prev: Adapteva Epiphany Options,  Up: Submodel Options
--- 19497,19548 ----
            switching that might be needed, compared with what would be
            needed with a more specific choice of prevailing FPU mode.
  
!      ‘truncate’
            This is the mode used for floating-point calculations with
            truncating (i.e. round towards zero) rounding mode.  That
            includes conversion from floating point to integer.
  
!      ‘round-nearest’
            This is the mode used for floating-point calculations with
            round-to-nearest-or-even rounding mode.
  
!      ‘int’
            This is the mode used to perform integer calculations in the
            FPU, e.g. integer multiply, or integer
            multiply-and-accumulate.
  
!      The default is ‘-mfp-mode=caller’
  
! ‘-mno-split-lohi’
! ‘-mno-postinc’
! ‘-mno-postmodify’
       Code generation tweaks that disable, respectively, splitting of
       32-bit loads, generation of post-increment addresses, and
       generation of post-modify addresses.  The defaults are
!      ‘msplit-lohi’, ‘-mpost-inc’, and ‘-mpost-modify’.
  
! ‘-mnovect-double’
       Change the preferred SIMD mode to SImode.  The default is
!      ‘-mvect-double’, which uses DImode as preferred SIMD mode.
  
! ‘-max-vect-align=NUM’
       The maximum alignment for SIMD vector mode types.  NUM may be 4 or
       8.  The default is 8.  Note that this is an ABI change, even though
       many library function interfaces are unaffected if they don't use
       SIMD vector modes in places that affect size and/or alignment of
       relevant types.
  
! ‘-msplit-vecmove-early’
       Split vector moves into single word moves before reload.  In theory
       this can give better register allocation, but so far the reverse
       seems to be generally the case.
  
! ‘-m1reg-REG’
!      Specify a register to hold the constant −1, which makes loading
       small negative constants and certain bitmasks faster.  Allowable
!      values for REG are ‘r43’ and ‘r63’, which specify use of that
!      register as a fixed register, and ‘none’, which means that no
!      register is used for this purpose.  The default is ‘-m1reg-none’.
  
  
  File: gcc.info,  Node: AMD GCN Options,  Next: ARC Options,  Prev: Adapteva Epiphany Options,  Up: Submodel Options
*************** File: gcc.info,  Node: AMD GCN Options,
*** 19548,19593 ****
  
  These options are defined specifically for the AMD GCN port.
  
! '-march=GPU'
! '-mtune=GPU'
       Set architecture type or tuning for GPU.  Supported values for GPU
       are
  
!      'fiji'
            Compile for GCN3 Fiji devices (gfx803).
  
!      'gfx900'
            Compile for GCN5 Vega 10 devices (gfx900).
  
!      'gfx906'
            Compile for GCN5 Vega 20 devices (gfx906).
  
!      'gfx908'
            Compile for CDNA1 Instinct MI100 series devices (gfx908).
  
!      'gfx90a'
            Compile for CDNA2 Instinct MI200 series devices (gfx90a).
  
! '-msram-ecc=on'
! '-msram-ecc=off'
! '-msram-ecc=any'
       Compile binaries suitable for devices with the SRAM-ECC feature
       enabled, disabled, or either mode.  This feature can be enabled
       per-process on some devices.  The compiled code must match the
!      device mode.  The default is 'any', for devices that support it.
  
! '-mstack-size=BYTES'
       Specify how many BYTES of stack space will be requested for each
       GPU thread (wave-front).  Beware that there may be many threads and
       limited memory available.  The size of the stack allocation may
       also have an impact on run-time performance.  The default is 32KB
       when using OpenACC or OpenMP, and 1MB otherwise.
  
! '-mxnack'
       Compile binaries suitable for devices with the XNACK feature
       enabled.  Some devices always require XNACK and some allow the user
       to configure XNACK. The compiled code must match the device mode.
!      The default is '-mno-xnack'.  At present this option is a
       placeholder for support that is not yet implemented.
  
  
--- 19552,19597 ----
  
  These options are defined specifically for the AMD GCN port.
  
! ‘-march=GPU’
! ‘-mtune=GPU’
       Set architecture type or tuning for GPU.  Supported values for GPU
       are
  
!      ‘fiji’
            Compile for GCN3 Fiji devices (gfx803).
  
!      ‘gfx900’
            Compile for GCN5 Vega 10 devices (gfx900).
  
!      ‘gfx906’
            Compile for GCN5 Vega 20 devices (gfx906).
  
!      ‘gfx908’
            Compile for CDNA1 Instinct MI100 series devices (gfx908).
  
!      ‘gfx90a’
            Compile for CDNA2 Instinct MI200 series devices (gfx90a).
  
! ‘-msram-ecc=on’
! ‘-msram-ecc=off’
! ‘-msram-ecc=any’
       Compile binaries suitable for devices with the SRAM-ECC feature
       enabled, disabled, or either mode.  This feature can be enabled
       per-process on some devices.  The compiled code must match the
!      device mode.  The default is ‘any’, for devices that support it.
  
! ‘-mstack-size=BYTES’
       Specify how many BYTES of stack space will be requested for each
       GPU thread (wave-front).  Beware that there may be many threads and
       limited memory available.  The size of the stack allocation may
       also have an impact on run-time performance.  The default is 32KB
       when using OpenACC or OpenMP, and 1MB otherwise.
  
! ‘-mxnack’
       Compile binaries suitable for devices with the XNACK feature
       enabled.  Some devices always require XNACK and some allow the user
       to configure XNACK. The compiled code must match the device mode.
!      The default is ‘-mno-xnack’.  At present this option is a
       placeholder for support that is not yet implemented.
  
  
*************** File: gcc.info,  Node: ARC Options,  Nex
*** 19599,19908 ****
  The following options control the architecture variant for which code is
  being compiled:
  
! '-mbarrel-shifter'
       Generate instructions supported by barrel shifter.  This is the
!      default unless '-mcpu=ARC601' or '-mcpu=ARCEM' is in effect.
  
! '-mjli-always'
       Force to call a function using jli_s instruction.  This option is
       valid only for ARCv2 architecture.
  
! '-mcpu=CPU'
       Set architecture type, register usage, and instruction scheduling
       parameters for CPU.  There are also shortcut alias options
       available for backward compatibility and convenience.  Supported
       values for CPU are
  
!      'arc600'
!           Compile for ARC600.  Aliases: '-mA6', '-mARC600'.
  
!      'arc601'
!           Compile for ARC601.  Alias: '-mARC601'.
  
!      'arc700'
!           Compile for ARC700.  Aliases: '-mA7', '-mARC700'.  This is the
!           default when configured with '--with-cpu=arc700'.
  
!      'arcem'
            Compile for ARC EM.
  
!      'archs'
            Compile for ARC HS.
  
!      'em'
            Compile for ARC EM CPU with no hardware extensions.
  
!      'em4'
            Compile for ARC EM4 CPU.
  
!      'em4_dmips'
            Compile for ARC EM4 DMIPS CPU.
  
!      'em4_fpus'
            Compile for ARC EM4 DMIPS CPU with the single-precision
            floating-point extension.
  
!      'em4_fpuda'
            Compile for ARC EM4 DMIPS CPU with single-precision
            floating-point and double assist instructions.
  
!      'hs'
            Compile for ARC HS CPU with no hardware extensions except the
            atomic instructions.
  
!      'hs34'
            Compile for ARC HS34 CPU.
  
!      'hs38'
            Compile for ARC HS38 CPU.
  
!      'hs38_linux'
            Compile for ARC HS38 CPU with all hardware extensions on.
  
!      'hs4x'
            Compile for ARC HS4x CPU.
  
!      'hs4xd'
            Compile for ARC HS4xD CPU.
  
!      'hs4x_rel31'
            Compile for ARC HS4x CPU release 3.10a.
  
!      'arc600_norm'
!           Compile for ARC 600 CPU with 'norm' instructions enabled.
  
!      'arc600_mul32x16'
!           Compile for ARC 600 CPU with 'norm' and 32x16-bit multiply
            instructions enabled.
  
!      'arc600_mul64'
!           Compile for ARC 600 CPU with 'norm' and 'mul64'-family
            instructions enabled.
  
!      'arc601_norm'
!           Compile for ARC 601 CPU with 'norm' instructions enabled.
  
!      'arc601_mul32x16'
!           Compile for ARC 601 CPU with 'norm' and 32x16-bit multiply
            instructions enabled.
  
!      'arc601_mul64'
!           Compile for ARC 601 CPU with 'norm' and 'mul64'-family
            instructions enabled.
  
!      'nps400'
            Compile for ARC 700 on NPS400 chip.
  
!      'em_mini'
            Compile for ARC EM minimalist configuration featuring reduced
            register set.
  
! '-mdpfp'
! '-mdpfp-compact'
       Generate double-precision FPX instructions, tuned for the compact
       implementation.
  
! '-mdpfp-fast'
       Generate double-precision FPX instructions, tuned for the fast
       implementation.
  
! '-mno-dpfp-lrsr'
!      Disable 'lr' and 'sr' instructions from using FPX extension aux
       registers.
  
! '-mea'
!      Generate extended arithmetic instructions.  Currently only 'divaw',
!      'adds', 'subs', and 'sat16' are supported.  Only valid for
!      '-mcpu=ARC700'.
  
! '-mno-mpy'
!      Do not generate 'mpy'-family instructions for ARC700.  This option
       is deprecated.
  
! '-mmul32x16'
       Generate 32x16-bit multiply and multiply-accumulate instructions.
  
! '-mmul64'
!      Generate 'mul64' and 'mulu64' instructions.  Only valid for
!      '-mcpu=ARC600'.
  
! '-mnorm'
!      Generate 'norm' instructions.  This is the default if
!      '-mcpu=ARC700' is in effect.
  
! '-mspfp'
! '-mspfp-compact'
       Generate single-precision FPX instructions, tuned for the compact
       implementation.
  
! '-mspfp-fast'
       Generate single-precision FPX instructions, tuned for the fast
       implementation.
  
! '-msimd'
       Enable generation of ARC SIMD instructions via target-specific
!      builtins.  Only valid for '-mcpu=ARC700'.
  
! '-msoft-float'
       This option ignored; it is provided for compatibility purposes
       only.  Software floating-point code is emitted by default, and this
!      default can overridden by FPX options; '-mspfp', '-mspfp-compact',
!      or '-mspfp-fast' for single precision, and '-mdpfp',
!      '-mdpfp-compact', or '-mdpfp-fast' for double precision.
  
! '-mswap'
!      Generate 'swap' instructions.
  
! '-matomic'
       This enables use of the locked load/store conditional extension to
       implement atomic memory built-in functions.  Not available for ARC
       6xx or ARC EM cores.
  
! '-mdiv-rem'
!      Enable 'div' and 'rem' instructions for ARCv2 cores.
  
! '-mcode-density'
       Enable code density instructions for ARC EM. This option is on by
       default for ARC HS.
  
! '-mll64'
       Enable double load/store operations for ARC HS cores.
  
! '-mtp-regno=REGNO'
       Specify thread pointer register number.
  
! '-mmpy-option=MULTO'
       Compile ARCv2 code with a multiplier design option.  You can
       specify the option using either a string or numeric value for
!      MULTO.  'wlh1' is the default value.  The recognized values are:
  
!      '0'
!      'none'
            No multiplier available.
  
!      '1'
!      'w'
            16x16 multiplier, fully pipelined.  The following instructions
!           are enabled: 'mpyw' and 'mpyuw'.
  
!      '2'
!      'wlh1'
            32x32 multiplier, fully pipelined (1 stage).  The following
!           instructions are additionally enabled: 'mpy', 'mpyu', 'mpym',
!           'mpymu', and 'mpy_s'.
  
!      '3'
!      'wlh2'
            32x32 multiplier, fully pipelined (2 stages).  The following
!           instructions are additionally enabled: 'mpy', 'mpyu', 'mpym',
!           'mpymu', and 'mpy_s'.
  
!      '4'
!      'wlh3'
            Two 16x16 multipliers, blocking, sequential.  The following
!           instructions are additionally enabled: 'mpy', 'mpyu', 'mpym',
!           'mpymu', and 'mpy_s'.
  
!      '5'
!      'wlh4'
            One 16x16 multiplier, blocking, sequential.  The following
!           instructions are additionally enabled: 'mpy', 'mpyu', 'mpym',
!           'mpymu', and 'mpy_s'.
  
!      '6'
!      'wlh5'
            One 32x4 multiplier, blocking, sequential.  The following
!           instructions are additionally enabled: 'mpy', 'mpyu', 'mpym',
!           'mpymu', and 'mpy_s'.
  
!      '7'
!      'plus_dmpy'
            ARC HS SIMD support.
  
!      '8'
!      'plus_macd'
            ARC HS SIMD support.
  
!      '9'
!      'plus_qmacw'
            ARC HS SIMD support.
  
       This option is only available for ARCv2 cores.
  
! '-mfpu=FPU'
       Enables support for specific floating-point hardware extensions for
       ARCv2 cores.  Supported values for FPU are:
  
!      'fpus'
            Enables support for single-precision floating-point hardware
            extensions.
  
!      'fpud'
            Enables support for double-precision floating-point hardware
            extensions.  The single-precision floating-point extension is
            also enabled.  Not available for ARC EM.
  
!      'fpuda'
            Enables support for double-precision floating-point hardware
            extensions using double-precision assist instructions.  The
            single-precision floating-point extension is also enabled.
            This option is only available for ARC EM.
  
!      'fpuda_div'
            Enables support for double-precision floating-point hardware
            extensions using double-precision assist instructions.  The
            single-precision floating-point, square-root, and divide
            extensions are also enabled.  This option is only available
            for ARC EM.
  
!      'fpuda_fma'
            Enables support for double-precision floating-point hardware
            extensions using double-precision assist instructions.  The
            single-precision floating-point and fused multiply and add
            hardware extensions are also enabled.  This option is only
            available for ARC EM.
  
!      'fpuda_all'
            Enables support for double-precision floating-point hardware
            extensions using double-precision assist instructions.  All
            single-precision floating-point hardware extensions are also
            enabled.  This option is only available for ARC EM.
  
!      'fpus_div'
            Enables support for single-precision floating-point,
            square-root and divide hardware extensions.
  
!      'fpud_div'
            Enables support for double-precision floating-point,
            square-root and divide hardware extensions.  This option
!           includes option 'fpus_div'.  Not available for ARC EM.
  
!      'fpus_fma'
            Enables support for single-precision floating-point and fused
            multiply and add hardware extensions.
  
!      'fpud_fma'
            Enables support for double-precision floating-point and fused
            multiply and add hardware extensions.  This option includes
!           option 'fpus_fma'.  Not available for ARC EM.
  
!      'fpus_all'
            Enables support for all single-precision floating-point
            hardware extensions.
  
!      'fpud_all'
            Enables support for all single- and double-precision
            floating-point hardware extensions.  Not available for ARC EM.
  
! '-mirq-ctrl-saved=REGISTER-RANGE, BLINK, LP_COUNT'
       Specifies general-purposes registers that the processor
       automatically saves/restores on interrupt entry and exit.
       REGISTER-RANGE is specified as two registers separated by a dash.
!      The register range always starts with 'r0', the upper limit is 'fp'
       register.  BLINK and LP_COUNT are optional.  This option is only
       valid for ARC EM and ARC HS cores.
  
! '-mrgf-banked-regs=NUMBER'
       Specifies the number of registers replicated in second register
       bank on entry to fast interrupt.  Fast interrupts are interrupts
       with the highest priority level P0.  These interrupts save only PC
--- 19603,19912 ----
  The following options control the architecture variant for which code is
  being compiled:
  
! ‘-mbarrel-shifter’
       Generate instructions supported by barrel shifter.  This is the
!      default unless ‘-mcpu=ARC601’ or ‘-mcpu=ARCEM’ is in effect.
  
! ‘-mjli-always’
       Force to call a function using jli_s instruction.  This option is
       valid only for ARCv2 architecture.
  
! ‘-mcpu=CPU’
       Set architecture type, register usage, and instruction scheduling
       parameters for CPU.  There are also shortcut alias options
       available for backward compatibility and convenience.  Supported
       values for CPU are
  
!      ‘arc600’
!           Compile for ARC600.  Aliases: ‘-mA6’, ‘-mARC600’.
  
!      ‘arc601’
!           Compile for ARC601.  Alias: ‘-mARC601’.
  
!      ‘arc700’
!           Compile for ARC700.  Aliases: ‘-mA7’, ‘-mARC700’.  This is the
!           default when configured with ‘--with-cpu=arc700’.
  
!      ‘arcem’
            Compile for ARC EM.
  
!      ‘archs’
            Compile for ARC HS.
  
!      ‘em’
            Compile for ARC EM CPU with no hardware extensions.
  
!      ‘em4’
            Compile for ARC EM4 CPU.
  
!      ‘em4_dmips’
            Compile for ARC EM4 DMIPS CPU.
  
!      ‘em4_fpus’
            Compile for ARC EM4 DMIPS CPU with the single-precision
            floating-point extension.
  
!      ‘em4_fpuda’
            Compile for ARC EM4 DMIPS CPU with single-precision
            floating-point and double assist instructions.
  
!      ‘hs’
            Compile for ARC HS CPU with no hardware extensions except the
            atomic instructions.
  
!      ‘hs34’
            Compile for ARC HS34 CPU.
  
!      ‘hs38’
            Compile for ARC HS38 CPU.
  
!      ‘hs38_linux’
            Compile for ARC HS38 CPU with all hardware extensions on.
  
!      ‘hs4x’
            Compile for ARC HS4x CPU.
  
!      ‘hs4xd’
            Compile for ARC HS4xD CPU.
  
!      ‘hs4x_rel31’
            Compile for ARC HS4x CPU release 3.10a.
  
!      ‘arc600_norm’
!           Compile for ARC 600 CPU with ‘norm’ instructions enabled.
  
!      ‘arc600_mul32x16’
!           Compile for ARC 600 CPU with ‘norm’ and 32x16-bit multiply
            instructions enabled.
  
!      ‘arc600_mul64’
!           Compile for ARC 600 CPU with ‘norm’ and ‘mul64’-family
            instructions enabled.
  
!      ‘arc601_norm’
!           Compile for ARC 601 CPU with ‘norm’ instructions enabled.
  
!      ‘arc601_mul32x16’
!           Compile for ARC 601 CPU with ‘norm’ and 32x16-bit multiply
            instructions enabled.
  
!      ‘arc601_mul64’
!           Compile for ARC 601 CPU with ‘norm’ and ‘mul64’-family
            instructions enabled.
  
!      ‘nps400’
            Compile for ARC 700 on NPS400 chip.
  
!      ‘em_mini’
            Compile for ARC EM minimalist configuration featuring reduced
            register set.
  
! ‘-mdpfp’
! ‘-mdpfp-compact’
       Generate double-precision FPX instructions, tuned for the compact
       implementation.
  
! ‘-mdpfp-fast’
       Generate double-precision FPX instructions, tuned for the fast
       implementation.
  
! ‘-mno-dpfp-lrsr’
!      Disable ‘lr’ and ‘sr’ instructions from using FPX extension aux
       registers.
  
! ‘-mea’
!      Generate extended arithmetic instructions.  Currently only ‘divaw’,
!      ‘adds’, ‘subs’, and ‘sat16’ are supported.  Only valid for
!      ‘-mcpu=ARC700’.
  
! ‘-mno-mpy’
!      Do not generate ‘mpy’-family instructions for ARC700.  This option
       is deprecated.
  
! ‘-mmul32x16’
       Generate 32x16-bit multiply and multiply-accumulate instructions.
  
! ‘-mmul64’
!      Generate ‘mul64’ and ‘mulu64’ instructions.  Only valid for
!      ‘-mcpu=ARC600’.
  
! ‘-mnorm’
!      Generate ‘norm’ instructions.  This is the default if
!      ‘-mcpu=ARC700’ is in effect.
  
! ‘-mspfp’
! ‘-mspfp-compact’
       Generate single-precision FPX instructions, tuned for the compact
       implementation.
  
! ‘-mspfp-fast’
       Generate single-precision FPX instructions, tuned for the fast
       implementation.
  
! ‘-msimd’
       Enable generation of ARC SIMD instructions via target-specific
!      builtins.  Only valid for ‘-mcpu=ARC700’.
  
! ‘-msoft-float’
       This option ignored; it is provided for compatibility purposes
       only.  Software floating-point code is emitted by default, and this
!      default can overridden by FPX options; ‘-mspfp’, ‘-mspfp-compact’,
!      or ‘-mspfp-fast’ for single precision, and ‘-mdpfp’,
!      ‘-mdpfp-compact’, or ‘-mdpfp-fast’ for double precision.
  
! ‘-mswap’
!      Generate ‘swap’ instructions.
  
! ‘-matomic’
       This enables use of the locked load/store conditional extension to
       implement atomic memory built-in functions.  Not available for ARC
       6xx or ARC EM cores.
  
! ‘-mdiv-rem’
!      Enable ‘div’ and ‘rem’ instructions for ARCv2 cores.
  
! ‘-mcode-density’
       Enable code density instructions for ARC EM. This option is on by
       default for ARC HS.
  
! ‘-mll64’
       Enable double load/store operations for ARC HS cores.
  
! ‘-mtp-regno=REGNO’
       Specify thread pointer register number.
  
! ‘-mmpy-option=MULTO’
       Compile ARCv2 code with a multiplier design option.  You can
       specify the option using either a string or numeric value for
!      MULTO.  ‘wlh1’ is the default value.  The recognized values are:
  
!      ‘0’
!      ‘none’
            No multiplier available.
  
!      ‘1’
!      ‘w’
            16x16 multiplier, fully pipelined.  The following instructions
!           are enabled: ‘mpyw’ and ‘mpyuw’.
  
!      ‘2’
!      ‘wlh1’
            32x32 multiplier, fully pipelined (1 stage).  The following
!           instructions are additionally enabled: ‘mpy’, ‘mpyu’, ‘mpym’,
!           ‘mpymu’, and ‘mpy_s’.
  
!      ‘3’
!      ‘wlh2’
            32x32 multiplier, fully pipelined (2 stages).  The following
!           instructions are additionally enabled: ‘mpy’, ‘mpyu’, ‘mpym’,
!           ‘mpymu’, and ‘mpy_s’.
  
!      ‘4’
!      ‘wlh3’
            Two 16x16 multipliers, blocking, sequential.  The following
!           instructions are additionally enabled: ‘mpy’, ‘mpyu’, ‘mpym’,
!           ‘mpymu’, and ‘mpy_s’.
  
!      ‘5’
!      ‘wlh4’
            One 16x16 multiplier, blocking, sequential.  The following
!           instructions are additionally enabled: ‘mpy’, ‘mpyu’, ‘mpym’,
!           ‘mpymu’, and ‘mpy_s’.
  
!      ‘6’
!      ‘wlh5’
            One 32x4 multiplier, blocking, sequential.  The following
!           instructions are additionally enabled: ‘mpy’, ‘mpyu’, ‘mpym’,
!           ‘mpymu’, and ‘mpy_s’.
  
!      ‘7’
!      ‘plus_dmpy’
            ARC HS SIMD support.
  
!      ‘8’
!      ‘plus_macd’
            ARC HS SIMD support.
  
!      ‘9’
!      ‘plus_qmacw’
            ARC HS SIMD support.
  
       This option is only available for ARCv2 cores.
  
! ‘-mfpu=FPU’
       Enables support for specific floating-point hardware extensions for
       ARCv2 cores.  Supported values for FPU are:
  
!      ‘fpus’
            Enables support for single-precision floating-point hardware
            extensions.
  
!      ‘fpud’
            Enables support for double-precision floating-point hardware
            extensions.  The single-precision floating-point extension is
            also enabled.  Not available for ARC EM.
  
!      ‘fpuda’
            Enables support for double-precision floating-point hardware
            extensions using double-precision assist instructions.  The
            single-precision floating-point extension is also enabled.
            This option is only available for ARC EM.
  
!      ‘fpuda_div’
            Enables support for double-precision floating-point hardware
            extensions using double-precision assist instructions.  The
            single-precision floating-point, square-root, and divide
            extensions are also enabled.  This option is only available
            for ARC EM.
  
!      ‘fpuda_fma’
            Enables support for double-precision floating-point hardware
            extensions using double-precision assist instructions.  The
            single-precision floating-point and fused multiply and add
            hardware extensions are also enabled.  This option is only
            available for ARC EM.
  
!      ‘fpuda_all’
            Enables support for double-precision floating-point hardware
            extensions using double-precision assist instructions.  All
            single-precision floating-point hardware extensions are also
            enabled.  This option is only available for ARC EM.
  
!      ‘fpus_div’
            Enables support for single-precision floating-point,
            square-root and divide hardware extensions.
  
!      ‘fpud_div’
            Enables support for double-precision floating-point,
            square-root and divide hardware extensions.  This option
!           includes option ‘fpus_div’.  Not available for ARC EM.
  
!      ‘fpus_fma’
            Enables support for single-precision floating-point and fused
            multiply and add hardware extensions.
  
!      ‘fpud_fma’
            Enables support for double-precision floating-point and fused
            multiply and add hardware extensions.  This option includes
!           option ‘fpus_fma’.  Not available for ARC EM.
  
!      ‘fpus_all’
            Enables support for all single-precision floating-point
            hardware extensions.
  
!      ‘fpud_all’
            Enables support for all single- and double-precision
            floating-point hardware extensions.  Not available for ARC EM.
  
! ‘-mirq-ctrl-saved=REGISTER-RANGE, BLINK, LP_COUNT’
       Specifies general-purposes registers that the processor
       automatically saves/restores on interrupt entry and exit.
       REGISTER-RANGE is specified as two registers separated by a dash.
!      The register range always starts with ‘r0’, the upper limit is ‘fp’
       register.  BLINK and LP_COUNT are optional.  This option is only
       valid for ARC EM and ARC HS cores.
  
! ‘-mrgf-banked-regs=NUMBER’
       Specifies the number of registers replicated in second register
       bank on entry to fast interrupt.  Fast interrupts are interrupts
       with the highest priority level P0.  These interrupts save only PC
*************** being compiled:
*** 19911,20060 ****
       using fast interrupts in an ARC V2 family processor.  Permitted
       values are 4, 8, 16, and 32.
  
! '-mlpc-width=WIDTH'
!      Specify the width of the 'lp_count' register.  Valid values for
       WIDTH are 8, 16, 20, 24, 28 and 32 bits.  The default width is
       fixed to 32 bits.  If the width is less than 32, the compiler does
       not attempt to transform loops in your program to use the
!      zero-delay loop mechanism unless it is known that the 'lp_count'
       register can hold the required loop-counter value.  Depending on
       the width specified, the compiler and run-time library might
       continue to use the loop mechanism for various needs.  This option
!      defines macro '__ARC_LPC_WIDTH__' with the value of WIDTH.
  
! '-mrf16'
       This option instructs the compiler to generate code for a 16-entry
!      register file.  This option defines the '__ARC_RF16__' preprocessor
       macro.
  
! '-mbranch-index'
!      Enable use of 'bi' or 'bih' instructions to implement jump tables.
  
   The following options are passed through to the assembler, and also
  define preprocessor macro symbols.
  
! '-mdsp-packa'
       Passed down to the assembler to enable the DSP Pack A extensions.
!      Also sets the preprocessor symbol '__Xdsp_packa'.  This option is
       deprecated.
  
! '-mdvbf'
       Passed down to the assembler to enable the dual Viterbi butterfly
!      extension.  Also sets the preprocessor symbol '__Xdvbf'.  This
       option is deprecated.
  
! '-mlock'
       Passed down to the assembler to enable the locked load/store
       conditional extension.  Also sets the preprocessor symbol
!      '__Xlock'.
  
! '-mmac-d16'
       Passed down to the assembler.  Also sets the preprocessor symbol
!      '__Xxmac_d16'.  This option is deprecated.
  
! '-mmac-24'
       Passed down to the assembler.  Also sets the preprocessor symbol
!      '__Xxmac_24'.  This option is deprecated.
  
! '-mrtsc'
       Passed down to the assembler to enable the 64-bit time-stamp
       counter extension instruction.  Also sets the preprocessor symbol
!      '__Xrtsc'.  This option is deprecated.
  
! '-mswape'
       Passed down to the assembler to enable the swap byte ordering
       extension instruction.  Also sets the preprocessor symbol
!      '__Xswape'.
  
! '-mtelephony'
       Passed down to the assembler to enable dual- and single-operand
       instructions for telephony.  Also sets the preprocessor symbol
!      '__Xtelephony'.  This option is deprecated.
  
! '-mxy'
       Passed down to the assembler to enable the XY memory extension.
!      Also sets the preprocessor symbol '__Xxy'.
  
   The following options control how the assembly code is annotated:
  
! '-misize'
       Annotate assembler instructions with estimated addresses.
  
! '-mannotate-align'
       Explain what alignment considerations lead to the decision to make
       an instruction short or long.
  
   The following options are passed through to the linker:
  
! '-marclinux'
!      Passed through to the linker, to specify use of the 'arclinux'
       emulation.  This option is enabled by default in tool chains built
!      for 'arc-linux-uclibc' and 'arceb-linux-uclibc' targets when
       profiling is not requested.
  
! '-marclinux_prof'
!      Passed through to the linker, to specify use of the 'arclinux_prof'
       emulation.  This option is enabled by default in tool chains built
!      for 'arc-linux-uclibc' and 'arceb-linux-uclibc' targets when
       profiling is requested.
  
   The following options control the semantics of generated code:
  
! '-mlong-calls'
       Generate calls as register indirect calls, thus providing access to
       the full 32-bit address range.
  
! '-mmedium-calls'
       Don't use less than 25-bit addressing range for calls, which is the
       offset available for an unconditional branch-and-link instruction.
       Conditional execution of function calls is suppressed, to allow use
       of the 25-bit range, rather than the 21-bit range with conditional
       branch-and-link.  This is the default for tool chains built for
!      'arc-linux-uclibc' and 'arceb-linux-uclibc' targets.
  
! '-G NUM'
       Put definitions of externally-visible data in a small data section
       if that data is no bigger than NUM bytes.  The default value of NUM
       is 4 for any ARC configuration, or 8 when we have double load/store
       operations.
  
! '-mno-sdata'
       Do not generate sdata references.  This is the default for tool
!      chains built for 'arc-linux-uclibc' and 'arceb-linux-uclibc'
       targets.
  
! '-mvolatile-cache'
       Use ordinarily cached memory accesses for volatile references.
       This is the default.
  
! '-mno-volatile-cache'
       Enable cache bypass for volatile references.
  
   The following options fine tune code generation:
! '-malign-call'
       Does nothing.  Preserved for backward compatibility.
  
! '-mauto-modify-reg'
       Enable the use of pre/post modify with register displacement.
  
! '-mbbit-peephole'
       Enable bbit peephole2.
  
! '-mno-brcc'
!      This option disables a target-specific pass in 'arc_reorg' to
!      generate compare-and-branch ('brCC') instructions.  It has no
       effect on generation of these instructions driven by the combiner
       pass.
  
! '-mcase-vector-pcrel'
       Use PC-relative switch case tables to enable case table shortening.
!      This is the default for '-Os'.
  
! '-mcompact-casesi'
!      Enable compact 'casesi' pattern.  This is the default for '-Os',
       and only available for ARCv1 cores.  This option is deprecated.
  
! '-mno-cond-exec'
       Disable the ARCompact-specific pass to generate conditional
       execution instructions.
  
--- 19915,20064 ----
       using fast interrupts in an ARC V2 family processor.  Permitted
       values are 4, 8, 16, and 32.
  
! ‘-mlpc-width=WIDTH’
!      Specify the width of the ‘lp_count’ register.  Valid values for
       WIDTH are 8, 16, 20, 24, 28 and 32 bits.  The default width is
       fixed to 32 bits.  If the width is less than 32, the compiler does
       not attempt to transform loops in your program to use the
!      zero-delay loop mechanism unless it is known that the ‘lp_count’
       register can hold the required loop-counter value.  Depending on
       the width specified, the compiler and run-time library might
       continue to use the loop mechanism for various needs.  This option
!      defines macro ‘__ARC_LPC_WIDTH__’ with the value of WIDTH.
  
! ‘-mrf16’
       This option instructs the compiler to generate code for a 16-entry
!      register file.  This option defines the ‘__ARC_RF16__’ preprocessor
       macro.
  
! ‘-mbranch-index’
!      Enable use of ‘bi’ or ‘bih’ instructions to implement jump tables.
  
   The following options are passed through to the assembler, and also
  define preprocessor macro symbols.
  
! ‘-mdsp-packa’
       Passed down to the assembler to enable the DSP Pack A extensions.
!      Also sets the preprocessor symbol ‘__Xdsp_packa’.  This option is
       deprecated.
  
! ‘-mdvbf’
       Passed down to the assembler to enable the dual Viterbi butterfly
!      extension.  Also sets the preprocessor symbol ‘__Xdvbf’.  This
       option is deprecated.
  
! ‘-mlock’
       Passed down to the assembler to enable the locked load/store
       conditional extension.  Also sets the preprocessor symbol
!      ‘__Xlock’.
  
! ‘-mmac-d16’
       Passed down to the assembler.  Also sets the preprocessor symbol
!      ‘__Xxmac_d16’.  This option is deprecated.
  
! ‘-mmac-24’
       Passed down to the assembler.  Also sets the preprocessor symbol
!      ‘__Xxmac_24’.  This option is deprecated.
  
! ‘-mrtsc’
       Passed down to the assembler to enable the 64-bit time-stamp
       counter extension instruction.  Also sets the preprocessor symbol
!      ‘__Xrtsc’.  This option is deprecated.
  
! ‘-mswape’
       Passed down to the assembler to enable the swap byte ordering
       extension instruction.  Also sets the preprocessor symbol
!      ‘__Xswape’.
  
! ‘-mtelephony’
       Passed down to the assembler to enable dual- and single-operand
       instructions for telephony.  Also sets the preprocessor symbol
!      ‘__Xtelephony’.  This option is deprecated.
  
! ‘-mxy’
       Passed down to the assembler to enable the XY memory extension.
!      Also sets the preprocessor symbol ‘__Xxy’.
  
   The following options control how the assembly code is annotated:
  
! ‘-misize’
       Annotate assembler instructions with estimated addresses.
  
! ‘-mannotate-align’
       Explain what alignment considerations lead to the decision to make
       an instruction short or long.
  
   The following options are passed through to the linker:
  
! ‘-marclinux’
!      Passed through to the linker, to specify use of the ‘arclinux’
       emulation.  This option is enabled by default in tool chains built
!      for ‘arc-linux-uclibc’ and ‘arceb-linux-uclibc’ targets when
       profiling is not requested.
  
! ‘-marclinux_prof’
!      Passed through to the linker, to specify use of the ‘arclinux_prof’
       emulation.  This option is enabled by default in tool chains built
!      for ‘arc-linux-uclibc’ and ‘arceb-linux-uclibc’ targets when
       profiling is requested.
  
   The following options control the semantics of generated code:
  
! ‘-mlong-calls’
       Generate calls as register indirect calls, thus providing access to
       the full 32-bit address range.
  
! ‘-mmedium-calls’
       Don't use less than 25-bit addressing range for calls, which is the
       offset available for an unconditional branch-and-link instruction.
       Conditional execution of function calls is suppressed, to allow use
       of the 25-bit range, rather than the 21-bit range with conditional
       branch-and-link.  This is the default for tool chains built for
!      ‘arc-linux-uclibc’ and ‘arceb-linux-uclibc’ targets.
  
! ‘-G NUM’
       Put definitions of externally-visible data in a small data section
       if that data is no bigger than NUM bytes.  The default value of NUM
       is 4 for any ARC configuration, or 8 when we have double load/store
       operations.
  
! ‘-mno-sdata’
       Do not generate sdata references.  This is the default for tool
!      chains built for ‘arc-linux-uclibc’ and ‘arceb-linux-uclibc’
       targets.
  
! ‘-mvolatile-cache’
       Use ordinarily cached memory accesses for volatile references.
       This is the default.
  
! ‘-mno-volatile-cache’
       Enable cache bypass for volatile references.
  
   The following options fine tune code generation:
! ‘-malign-call’
       Does nothing.  Preserved for backward compatibility.
  
! ‘-mauto-modify-reg’
       Enable the use of pre/post modify with register displacement.
  
! ‘-mbbit-peephole’
       Enable bbit peephole2.
  
! ‘-mno-brcc’
!      This option disables a target-specific pass in ‘arc_reorg’ to
!      generate compare-and-branch (‘brCC’) instructions.  It has no
       effect on generation of these instructions driven by the combiner
       pass.
  
! ‘-mcase-vector-pcrel’
       Use PC-relative switch case tables to enable case table shortening.
!      This is the default for ‘-Os’.
  
! ‘-mcompact-casesi’
!      Enable compact ‘casesi’ pattern.  This is the default for ‘-Os’,
       and only available for ARCv1 cores.  This option is deprecated.
  
! ‘-mno-cond-exec’
       Disable the ARCompact-specific pass to generate conditional
       execution instructions.
  
*************** define preprocessor macro symbols.
*** 20069,20105 ****
       the cost of extra compilation time, which is why there is an option
       to switch it off.  If you have a problem with call instructions
       exceeding their allowable offset range because they are
!      conditionalized, you should consider using '-mmedium-calls'
       instead.
  
! '-mearly-cbranchsi'
!      Enable pre-reload use of the 'cbranchsi' pattern.
  
! '-mexpand-adddi'
!      Expand 'adddi3' and 'subdi3' at RTL generation time into 'add.f',
!      'adc' etc.  This option is deprecated.
  
! '-mindexed-loads'
       Enable the use of indexed loads.  This can be problematic because
       some optimizers then assume that indexed stores exist, which is not
       the case.
  
! '-mlra'
       Enable Local Register Allocation.  This is still experimental for
       ARC, so by default the compiler uses standard reload (i.e.
!      '-mno-lra').
  
! '-mlra-priority-none'
       Don't indicate any priority for target registers.
  
! '-mlra-priority-compact'
       Indicate target register priority for r0..r3 / r12..r15.
  
! '-mlra-priority-noncompact'
       Reduce target register priority for r0..r3 / r12..r15.
  
! '-mmillicode'
!      When optimizing for size (using '-Os'), prologues and epilogues
       that have to save or restore a large number of registers are often
       shortened by using call to a special function in libgcc; this is
       referred to as a _millicode_ call.  As these calls can pose
--- 20073,20109 ----
       the cost of extra compilation time, which is why there is an option
       to switch it off.  If you have a problem with call instructions
       exceeding their allowable offset range because they are
!      conditionalized, you should consider using ‘-mmedium-calls’
       instead.
  
! ‘-mearly-cbranchsi’
!      Enable pre-reload use of the ‘cbranchsi’ pattern.
  
! ‘-mexpand-adddi’
!      Expand ‘adddi3’ and ‘subdi3’ at RTL generation time into ‘add.f’,
!      ‘adc’ etc.  This option is deprecated.
  
! ‘-mindexed-loads’
       Enable the use of indexed loads.  This can be problematic because
       some optimizers then assume that indexed stores exist, which is not
       the case.
  
! ‘-mlra’
       Enable Local Register Allocation.  This is still experimental for
       ARC, so by default the compiler uses standard reload (i.e.
!      ‘-mno-lra’).
  
! ‘-mlra-priority-none’
       Don't indicate any priority for target registers.
  
! ‘-mlra-priority-compact’
       Indicate target register priority for r0..r3 / r12..r15.
  
! ‘-mlra-priority-noncompact’
       Reduce target register priority for r0..r3 / r12..r15.
  
! ‘-mmillicode’
!      When optimizing for size (using ‘-Os’), prologues and epilogues
       that have to save or restore a large number of registers are often
       shortened by using call to a special function in libgcc; this is
       referred to as a _millicode_ call.  As these calls can pose
*************** define preprocessor macro symbols.
*** 20107,20243 ****
       nonstandard way, this option is provided to turn on or off
       millicode call generation.
  
! '-mcode-density-frame'
!      This option enable the compiler to emit 'enter' and 'leave'
       instructions.  These instructions are only valid for CPUs with
       code-density feature.
  
! '-mmixed-code'
       Does nothing.  Preserved for backward compatibility.
  
! '-mq-class'
!      Ths option is deprecated.  Enable 'q' instruction alternatives.
!      This is the default for '-Os'.
  
! '-mRcq'
       Does nothing.  Preserved for backward compatibility.
  
! '-mRcw'
       Does nothing.  Preserved for backward compatibility.
  
! '-msize-level=LEVEL'
       Fine-tune size optimization with regards to instruction lengths and
       alignment.  The recognized values for LEVEL are:
!      '0'
            No size optimization.  This level is deprecated and treated
!           like '1'.
  
!      '1'
            Short instructions are used opportunistically.
  
!      '2'
            In addition, alignment of loops and of code after barriers are
            dropped.
  
!      '3'
            In addition, optional data alignment is dropped, and the
!           option 'Os' is enabled.
  
!      This defaults to '3' when '-Os' is in effect.  Otherwise, the
!      behavior when this is not set is equivalent to level '1'.
  
! '-mtune=CPU'
       Set instruction scheduling parameters for CPU, overriding any
!      implied by '-mcpu='.
  
       Supported values for CPU are
  
!      'ARC600'
            Tune for ARC600 CPU.
  
!      'ARC601'
            Tune for ARC601 CPU.
  
!      'ARC700'
            Tune for ARC700 CPU with standard multiplier block.
  
!      'ARC700-xmac'
            Tune for ARC700 CPU with XMAC block.
  
!      'ARC725D'
            Tune for ARC725D CPU.
  
!      'ARC750D'
            Tune for ARC750D CPU.
  
!      'core3'
            Tune for ARCv2 core3 type CPU. This option enable usage of
!           'dbnz' instruction.
  
!      'release31a'
            Tune for ARC4x release 3.10a.
  
! '-mmultcost=NUM'
!      Cost to assume for a multiply instruction, with '4' being equal to
       a normal instruction.
  
! '-munalign-prob-threshold=PROBABILITY'
       Does nothing.  Preserved for backward compatibility.
  
   The following options are maintained for backward compatibility, but
  are now deprecated and will be removed in a future release:
  
! '-margonaut'
       Obsolete FPX.
  
! '-mbig-endian'
! '-EB'
       Compile code for big-endian targets.  Use of these options is now
       deprecated.  Big-endian code is supported by configuring GCC to
!      build 'arceb-elf32' and 'arceb-linux-uclibc' targets, for which big
       endian is the default.
  
! '-mlittle-endian'
! '-EL'
       Compile code for little-endian targets.  Use of these options is
       now deprecated.  Little-endian code is supported by configuring GCC
!      to build 'arc-elf32' and 'arc-linux-uclibc' targets, for which
       little endian is the default.
  
! '-mbarrel_shifter'
!      Replaced by '-mbarrel-shifter'.
  
! '-mdpfp_compact'
!      Replaced by '-mdpfp-compact'.
  
! '-mdpfp_fast'
!      Replaced by '-mdpfp-fast'.
  
! '-mdsp_packa'
!      Replaced by '-mdsp-packa'.
  
! '-mEA'
!      Replaced by '-mea'.
  
! '-mmac_24'
!      Replaced by '-mmac-24'.
  
! '-mmac_d16'
!      Replaced by '-mmac-d16'.
  
! '-mspfp_compact'
!      Replaced by '-mspfp-compact'.
  
! '-mspfp_fast'
!      Replaced by '-mspfp-fast'.
  
! '-mtune=CPU'
!      Values 'arc600', 'arc601', 'arc700' and 'arc700-xmac' for CPU are
!      replaced by 'ARC600', 'ARC601', 'ARC700' and 'ARC700-xmac'
       respectively.
  
! '-multcost=NUM'
!      Replaced by '-mmultcost'.
  
  
  File: gcc.info,  Node: ARM Options,  Next: AVR Options,  Prev: ARC Options,  Up: Submodel Options
--- 20111,20247 ----
       nonstandard way, this option is provided to turn on or off
       millicode call generation.
  
! ‘-mcode-density-frame’
!      This option enable the compiler to emit ‘enter’ and ‘leave’
       instructions.  These instructions are only valid for CPUs with
       code-density feature.
  
! ‘-mmixed-code’
       Does nothing.  Preserved for backward compatibility.
  
! ‘-mq-class’
!      Ths option is deprecated.  Enable ‘q’ instruction alternatives.
!      This is the default for ‘-Os’.
  
! ‘-mRcq’
       Does nothing.  Preserved for backward compatibility.
  
! ‘-mRcw’
       Does nothing.  Preserved for backward compatibility.
  
! ‘-msize-level=LEVEL’
       Fine-tune size optimization with regards to instruction lengths and
       alignment.  The recognized values for LEVEL are:
!      ‘0’
            No size optimization.  This level is deprecated and treated
!           like ‘1’.
  
!      ‘1’
            Short instructions are used opportunistically.
  
!      ‘2’
            In addition, alignment of loops and of code after barriers are
            dropped.
  
!      ‘3’
            In addition, optional data alignment is dropped, and the
!           option ‘Os’ is enabled.
  
!      This defaults to ‘3’ when ‘-Os’ is in effect.  Otherwise, the
!      behavior when this is not set is equivalent to level ‘1’.
  
! ‘-mtune=CPU’
       Set instruction scheduling parameters for CPU, overriding any
!      implied by ‘-mcpu=’.
  
       Supported values for CPU are
  
!      ‘ARC600’
            Tune for ARC600 CPU.
  
!      ‘ARC601’
            Tune for ARC601 CPU.
  
!      ‘ARC700’
            Tune for ARC700 CPU with standard multiplier block.
  
!      ‘ARC700-xmac’
            Tune for ARC700 CPU with XMAC block.
  
!      ‘ARC725D’
            Tune for ARC725D CPU.
  
!      ‘ARC750D’
            Tune for ARC750D CPU.
  
!      ‘core3’
            Tune for ARCv2 core3 type CPU. This option enable usage of
!           ‘dbnz’ instruction.
  
!      ‘release31a’
            Tune for ARC4x release 3.10a.
  
! ‘-mmultcost=NUM’
!      Cost to assume for a multiply instruction, with ‘4’ being equal to
       a normal instruction.
  
! ‘-munalign-prob-threshold=PROBABILITY’
       Does nothing.  Preserved for backward compatibility.
  
   The following options are maintained for backward compatibility, but
  are now deprecated and will be removed in a future release:
  
! ‘-margonaut’
       Obsolete FPX.
  
! ‘-mbig-endian’
! ‘-EB’
       Compile code for big-endian targets.  Use of these options is now
       deprecated.  Big-endian code is supported by configuring GCC to
!      build ‘arceb-elf32’ and ‘arceb-linux-uclibc’ targets, for which big
       endian is the default.
  
! ‘-mlittle-endian’
! ‘-EL’
       Compile code for little-endian targets.  Use of these options is
       now deprecated.  Little-endian code is supported by configuring GCC
!      to build ‘arc-elf32’ and ‘arc-linux-uclibc’ targets, for which
       little endian is the default.
  
! ‘-mbarrel_shifter’
!      Replaced by ‘-mbarrel-shifter’.
  
! ‘-mdpfp_compact’
!      Replaced by ‘-mdpfp-compact’.
  
! ‘-mdpfp_fast’
!      Replaced by ‘-mdpfp-fast’.
  
! ‘-mdsp_packa’
!      Replaced by ‘-mdsp-packa’.
  
! ‘-mEA’
!      Replaced by ‘-mea’.
  
! ‘-mmac_24’
!      Replaced by ‘-mmac-24’.
  
! ‘-mmac_d16’
!      Replaced by ‘-mmac-d16’.
  
! ‘-mspfp_compact’
!      Replaced by ‘-mspfp-compact’.
  
! ‘-mspfp_fast’
!      Replaced by ‘-mspfp-fast’.
  
! ‘-mtune=CPU’
!      Values ‘arc600’, ‘arc601’, ‘arc700’ and ‘arc700-xmac’ for CPU are
!      replaced by ‘ARC600’, ‘ARC601’, ‘ARC700’ and ‘ARC700-xmac’
       respectively.
  
! ‘-multcost=NUM’
!      Replaced by ‘-mmultcost’.
  
  
  File: gcc.info,  Node: ARM Options,  Next: AVR Options,  Prev: ARC Options,  Up: Submodel Options
*************** File: gcc.info,  Node: ARM Options,  Nex
*** 20245,20292 ****
  3.19.5 ARM Options
  ------------------
  
! These '-m' options are defined for the ARM port:
  
! '-mabi=NAME'
       Generate code for the specified ABI.  Permissible values are:
!      'apcs-gnu', 'atpcs', 'aapcs', 'aapcs-linux' and 'iwmmxt'.
  
! '-mapcs-frame'
       Generate a stack frame that is compliant with the ARM Procedure
       Call Standard for all functions, even if this is not strictly
       necessary for correct execution of the code.  Specifying
!      '-fomit-frame-pointer' with this option causes the stack frames not
       to be generated for leaf functions.  The default is
!      '-mno-apcs-frame'.  This option is deprecated.
  
! '-mapcs'
!      This is a synonym for '-mapcs-frame' and is deprecated.
  
! '-mthumb-interwork'
       Generate code that supports calling between the ARM and Thumb
       instruction sets.  Without this option, on pre-v5 architectures,
       the two instruction sets cannot be reliably used inside one
!      program.  The default is '-mno-thumb-interwork', since slightly
!      larger code is generated when '-mthumb-interwork' is specified.  In
       AAPCS configurations this option is meaningless.
  
! '-mno-sched-prolog'
       Prevent the reordering of instructions in the function prologue, or
       the merging of those instruction with the instructions in the
       function's body.  This means that all functions start with a
       recognizable set of instructions (or in fact one of a choice from a
       small set of different function prologues), and this information
       can be used to locate the start of functions inside an executable
!      piece of code.  The default is '-msched-prolog'.
  
! '-mfloat-abi=NAME'
       Specifies which floating-point ABI to use.  Permissible values are:
!      'soft', 'softfp' and 'hard'.
  
!      Specifying 'soft' causes GCC to generate output containing library
!      calls for floating-point operations.  'softfp' allows the
       generation of code using hardware floating-point instructions, but
!      still uses the soft-float calling conventions.  'hard' allows
       generation of floating-point instructions and uses FPU-specific
       calling conventions.
  
--- 20249,20296 ----
  3.19.5 ARM Options
  ------------------
  
! These ‘-m’ options are defined for the ARM port:
  
! ‘-mabi=NAME’
       Generate code for the specified ABI.  Permissible values are:
!      ‘apcs-gnu’, ‘atpcs’, ‘aapcs’, ‘aapcs-linux’ and ‘iwmmxt’.
  
! ‘-mapcs-frame’
       Generate a stack frame that is compliant with the ARM Procedure
       Call Standard for all functions, even if this is not strictly
       necessary for correct execution of the code.  Specifying
!      ‘-fomit-frame-pointer’ with this option causes the stack frames not
       to be generated for leaf functions.  The default is
!      ‘-mno-apcs-frame’.  This option is deprecated.
  
! ‘-mapcs’
!      This is a synonym for ‘-mapcs-frame’ and is deprecated.
  
! ‘-mthumb-interwork’
       Generate code that supports calling between the ARM and Thumb
       instruction sets.  Without this option, on pre-v5 architectures,
       the two instruction sets cannot be reliably used inside one
!      program.  The default is ‘-mno-thumb-interwork’, since slightly
!      larger code is generated when ‘-mthumb-interwork’ is specified.  In
       AAPCS configurations this option is meaningless.
  
! ‘-mno-sched-prolog’
       Prevent the reordering of instructions in the function prologue, or
       the merging of those instruction with the instructions in the
       function's body.  This means that all functions start with a
       recognizable set of instructions (or in fact one of a choice from a
       small set of different function prologues), and this information
       can be used to locate the start of functions inside an executable
!      piece of code.  The default is ‘-msched-prolog’.
  
! ‘-mfloat-abi=NAME’
       Specifies which floating-point ABI to use.  Permissible values are:
!      ‘soft’, ‘softfp’ and ‘hard’.
  
!      Specifying ‘soft’ causes GCC to generate output containing library
!      calls for floating-point operations.  ‘softfp’ allows the
       generation of code using hardware floating-point instructions, but
!      still uses the soft-float calling conventions.  ‘hard’ allows
       generation of floating-point instructions and uses FPU-specific
       calling conventions.
  
*************** These '-m' options are defined for the A
*** 20295,20316 ****
       you must compile your entire program with the same ABI, and link
       with a compatible set of libraries.
  
! '-mgeneral-regs-only'
       Generate code which uses only the general-purpose registers.  This
       will prevent the compiler from using floating-point and Advanced
       SIMD registers but will not impose any restrictions on the
       assembler.
  
! '-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.
  
! '-mbe8'
! '-mbe32'
       When linking a big-endian image select between BE8 and BE32
       formats.  The option has no effect for little-endian images and is
       ignored.  The default is dependent on the selected target
--- 20299,20320 ----
       you must compile your entire program with the same ABI, and link
       with a compatible set of libraries.
  
! ‘-mgeneral-regs-only’
       Generate code which uses only the general-purpose registers.  This
       will prevent the compiler from using floating-point and Advanced
       SIMD registers but will not impose any restrictions on the
       assembler.
  
! ‘-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.
  
! ‘-mbe8’
! ‘-mbe32’
       When linking a big-endian image select between BE8 and BE32
       formats.  The option has no effect for little-endian images and is
       ignored.  The default is dependent on the selected target
*************** These '-m' options are defined for the A
*** 20318,20855 ****
       BE8, for older architectures the default is BE32.  BE32 format has
       been deprecated by ARM.
  
! '-march=NAME[+extension...]'
       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: 'armv4t', 'armv5t', 'armv5te', 'armv6',
!      'armv6j', 'armv6k', 'armv6kz', 'armv6t2', 'armv6z', 'armv6zk',
!      'armv7', 'armv7-a', 'armv7ve', 'armv8-a', 'armv8.1-a', 'armv8.2-a',
!      'armv8.3-a', 'armv8.4-a', 'armv8.5-a', 'armv8.6-a', 'armv9-a',
!      'armv7-r', 'armv8-r', 'armv6-m', 'armv6s-m', 'armv7-m', 'armv7e-m',
!      'armv8-m.base', 'armv8-m.main', 'armv8.1-m.main', 'armv9-a',
!      'iwmmxt' and 'iwmmxt2'.
  
       Additionally, the following architectures, which lack support for
       the Thumb execution state, are recognized but support is
!      deprecated: 'armv4'.
  
       Many of the architectures support extensions.  These can be added
!      by appending '+EXTENSION' to the architecture name.  Extension
       options are processed in order and capabilities accumulate.  An
       extension will also enable any necessary base extensions upon which
!      it depends.  For example, the '+crypto' extension will always
!      enable the '+simd' extension.  The exception to the additive
!      construction is for extensions that are prefixed with '+no...':
       these extensions disable the specified option and any other
       extensions that may depend on the presence of that extension.
  
!      For example, '-march=armv7-a+simd+nofp+vfpv4' is equivalent to
!      writing '-march=armv7-a+vfpv4' since the '+simd' option is entirely
!      disabled by the '+nofp' option that follows it.
  
       Most extension names are generically named, but have an effect that
       is dependent upon the architecture to which it is applied.  For
!      example, the '+simd' option can be applied to both 'armv7-a' and
!      'armv8-a' architectures, but will enable the original ARMv7-A
!      Advanced SIMD (Neon) extensions for 'armv7-a' and the ARMv8-A
!      variant for 'armv8-a'.
  
       The table below lists the supported extensions for each
       architecture.  Architectures not mentioned do not support any
       extensions.
  
!      'armv5te'
!      'armv6'
!      'armv6j'
!      'armv6k'
!      'armv6kz'
!      'armv6t2'
!      'armv6z'
!      'armv6zk'
!           '+fp'
                 The VFPv2 floating-point instructions.  The extension
!                '+vfpv2' can be used as an alias for this extension.
  
!           '+nofp'
                 Disable the floating-point instructions.
  
!      'armv7'
            The common subset of the ARMv7-A, ARMv7-R and ARMv7-M
            architectures.
!           '+fp'
                 The VFPv3 floating-point instructions, with 16
!                double-precision registers.  The extension '+vfpv3-d16'
                 can be used as an alias for this extension.  Note that
                 floating-point is not supported by the base ARMv7-M
                 architecture, but is compatible with both the ARMv7-A and
                 ARMv7-R architectures.
  
!           '+nofp'
                 Disable the floating-point instructions.
  
!      'armv7-a'
!           '+mp'
                 The multiprocessing extension.
  
!           '+sec'
                 The security extension.
  
!           '+fp'
                 The VFPv3 floating-point instructions, with 16
!                double-precision registers.  The extension '+vfpv3-d16'
                 can be used as an alias for this extension.
  
!           '+simd'
                 The Advanced SIMD (Neon) v1 and the VFPv3 floating-point
!                instructions.  The extensions '+neon' and '+neon-vfpv3'
                 can be used as aliases for this extension.
  
!           '+vfpv3'
                 The VFPv3 floating-point instructions, with 32
                 double-precision registers.
  
!           '+vfpv3-d16-fp16'
                 The VFPv3 floating-point instructions, with 16
                 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           '+vfpv3-fp16'
                 The VFPv3 floating-point instructions, with 32
                 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           '+vfpv4-d16'
                 The VFPv4 floating-point instructions, with 16
                 double-precision registers.
  
!           '+vfpv4'
                 The VFPv4 floating-point instructions, with 32
                 double-precision registers.
  
!           '+neon-fp16'
                 The Advanced SIMD (Neon) v1 and the VFPv3 floating-point
                 instructions, with the half-precision floating-point
                 conversion operations.
  
!           '+neon-vfpv4'
                 The Advanced SIMD (Neon) v2 and the VFPv4 floating-point
                 instructions.
  
!           '+nosimd'
                 Disable the Advanced SIMD instructions (does not disable
                 floating point).
  
!           '+nofp'
                 Disable the floating-point and Advanced SIMD
                 instructions.
  
!      'armv7ve'
            The extended version of the ARMv7-A architecture with support
            for virtualization.
!           '+fp'
                 The VFPv4 floating-point instructions, with 16
!                double-precision registers.  The extension '+vfpv4-d16'
                 can be used as an alias for this extension.
  
!           '+simd'
                 The Advanced SIMD (Neon) v2 and the VFPv4 floating-point
!                instructions.  The extension '+neon-vfpv4' can be used as
                 an alias for this extension.
  
!           '+vfpv3-d16'
                 The VFPv3 floating-point instructions, with 16
                 double-precision registers.
  
!           '+vfpv3'
                 The VFPv3 floating-point instructions, with 32
                 double-precision registers.
  
!           '+vfpv3-d16-fp16'
                 The VFPv3 floating-point instructions, with 16
                 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           '+vfpv3-fp16'
                 The VFPv3 floating-point instructions, with 32
                 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           '+vfpv4-d16'
                 The VFPv4 floating-point instructions, with 16
                 double-precision registers.
  
!           '+vfpv4'
                 The VFPv4 floating-point instructions, with 32
                 double-precision registers.
  
!           '+neon'
                 The Advanced SIMD (Neon) v1 and the VFPv3 floating-point
!                instructions.  The extension '+neon-vfpv3' can be used as
                 an alias for this extension.
  
!           '+neon-fp16'
                 The Advanced SIMD (Neon) v1 and the VFPv3 floating-point
                 instructions, with the half-precision floating-point
                 conversion operations.
  
!           '+nosimd'
                 Disable the Advanced SIMD instructions (does not disable
                 floating point).
  
!           '+nofp'
                 Disable the floating-point and Advanced SIMD
                 instructions.
  
!      'armv8-a'
!           '+crc'
                 The Cyclic Redundancy Check (CRC) instructions.
!           '+simd'
                 The ARMv8-A Advanced SIMD and floating-point
                 instructions.
!           '+crypto'
                 The cryptographic instructions.
!           '+nocrypto'
                 Disable the cryptographic instructions.
!           '+nofp'
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
!           '+sb'
                 Speculation Barrier Instruction.
!           '+predres'
                 Execution and Data Prediction Restriction Instructions.
  
!      'armv8.1-a'
!           '+simd'
                 The ARMv8.1-A Advanced SIMD and floating-point
                 instructions.
  
!           '+crypto'
                 The cryptographic instructions.  This also enables the
                 Advanced SIMD and floating-point instructions.
  
!           '+nocrypto'
                 Disable the cryptographic instructions.
  
!           '+nofp'
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!           '+sb'
                 Speculation Barrier Instruction.
  
!           '+predres'
                 Execution and Data Prediction Restriction Instructions.
  
!      'armv8.2-a'
!      'armv8.3-a'
!           '+fp16'
                 The half-precision floating-point data processing
                 instructions.  This also enables the Advanced SIMD and
                 floating-point instructions.
  
!           '+fp16fml'
                 The half-precision floating-point fmla extension.  This
                 also enables the half-precision floating-point extension
                 and Advanced SIMD and floating-point instructions.
  
!           '+simd'
                 The ARMv8.1-A Advanced SIMD and floating-point
                 instructions.
  
!           '+crypto'
                 The cryptographic instructions.  This also enables the
                 Advanced SIMD and floating-point instructions.
  
!           '+dotprod'
                 Enable the Dot Product extension.  This also enables
                 Advanced SIMD instructions.
  
!           '+nocrypto'
                 Disable the cryptographic extension.
  
!           '+nofp'
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!           '+sb'
                 Speculation Barrier Instruction.
  
!           '+predres'
                 Execution and Data Prediction Restriction Instructions.
  
!           '+i8mm'
                 8-bit Integer Matrix Multiply instructions.  This also
                 enables Advanced SIMD and floating-point instructions.
  
!           '+bf16'
                 Brain half-precision floating-point instructions.  This
                 also enables Advanced SIMD and floating-point
                 instructions.
  
!      'armv8.4-a'
!           '+fp16'
                 The half-precision floating-point data processing
                 instructions.  This also enables the Advanced SIMD and
                 floating-point instructions as well as the Dot Product
                 extension and the half-precision floating-point fmla
                 extension.
  
!           '+simd'
                 The ARMv8.3-A Advanced SIMD and floating-point
                 instructions as well as the Dot Product extension.
  
!           '+crypto'
                 The cryptographic instructions.  This also enables the
                 Advanced SIMD and floating-point instructions as well as
                 the Dot Product extension.
  
!           '+nocrypto'
                 Disable the cryptographic extension.
  
!           '+nofp'
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!           '+sb'
                 Speculation Barrier Instruction.
  
!           '+predres'
                 Execution and Data Prediction Restriction Instructions.
  
!           '+i8mm'
                 8-bit Integer Matrix Multiply instructions.  This also
                 enables Advanced SIMD and floating-point instructions.
  
!           '+bf16'
                 Brain half-precision floating-point instructions.  This
                 also enables Advanced SIMD and floating-point
                 instructions.
  
!      'armv8.5-a'
!           '+fp16'
                 The half-precision floating-point data processing
                 instructions.  This also enables the Advanced SIMD and
                 floating-point instructions as well as the Dot Product
                 extension and the half-precision floating-point fmla
                 extension.
  
!           '+simd'
                 The ARMv8.3-A Advanced SIMD and floating-point
                 instructions as well as the Dot Product extension.
  
!           '+crypto'
                 The cryptographic instructions.  This also enables the
                 Advanced SIMD and floating-point instructions as well as
                 the Dot Product extension.
  
!           '+nocrypto'
                 Disable the cryptographic extension.
  
!           '+nofp'
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!           '+i8mm'
                 8-bit Integer Matrix Multiply instructions.  This also
                 enables Advanced SIMD and floating-point instructions.
  
!           '+bf16'
                 Brain half-precision floating-point instructions.  This
                 also enables Advanced SIMD and floating-point
                 instructions.
  
!      'armv8.6-a'
!           '+fp16'
                 The half-precision floating-point data processing
                 instructions.  This also enables the Advanced SIMD and
                 floating-point instructions as well as the Dot Product
                 extension and the half-precision floating-point fmla
                 extension.
  
!           '+simd'
                 The ARMv8.3-A Advanced SIMD and floating-point
                 instructions as well as the Dot Product extension.
  
!           '+crypto'
                 The cryptographic instructions.  This also enables the
                 Advanced SIMD and floating-point instructions as well as
                 the Dot Product extension.
  
!           '+nocrypto'
                 Disable the cryptographic extension.
  
!           '+nofp'
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!           '+i8mm'
                 8-bit Integer Matrix Multiply instructions.  This also
                 enables Advanced SIMD and floating-point instructions.
  
!           '+bf16'
                 Brain half-precision floating-point instructions.  This
                 also enables Advanced SIMD and floating-point
                 instructions.
  
!      'armv7-r'
!           '+fp.sp'
                 The single-precision VFPv3 floating-point instructions.
!                The extension '+vfpv3xd' can be used as an alias for this
                 extension.
  
!           '+fp'
                 The VFPv3 floating-point instructions with 16
                 double-precision registers.  The extension +vfpv3-d16 can
                 be used as an alias for this extension.
  
!           '+vfpv3xd-d16-fp16'
                 The single-precision VFPv3 floating-point instructions
                 with 16 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           '+vfpv3-d16-fp16'
                 The VFPv3 floating-point instructions with 16
                 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           '+nofp'
                 Disable the floating-point extension.
  
!           '+idiv'
                 The ARM-state integer division instructions.
  
!           '+noidiv'
                 Disable the ARM-state integer division extension.
  
!      'armv7e-m'
!           '+fp'
                 The single-precision VFPv4 floating-point instructions.
  
!           '+fpv5'
                 The single-precision FPv5 floating-point instructions.
  
!           '+fp.dp'
                 The single- and double-precision FPv5 floating-point
                 instructions.
  
!           '+nofp'
                 Disable the floating-point extensions.
  
!      'armv8.1-m.main'
  
!           '+dsp'
                 The DSP instructions.
  
!           '+mve'
                 The M-Profile Vector Extension (MVE) integer
                 instructions.
  
!           '+mve.fp'
                 The M-Profile Vector Extension (MVE) integer and single
                 precision floating-point instructions.
  
!           '+fp'
                 The single-precision floating-point instructions.
  
!           '+fp.dp'
                 The single- and double-precision floating-point
                 instructions.
  
!           '+nofp'
                 Disable the floating-point extension.
  
!           '+cdecp0, +cdecp1, ... , +cdecp7'
                 Enable the Custom Datapath Extension (CDE) on selected
                 coprocessors according to the numbers given in the
                 options in the range 0 to 7.
  
!           '+pacbti'
                 Enable the Pointer Authentication and Branch Target
                 Identification Extension.
  
!      'armv8-m.main'
!           '+dsp'
                 The DSP instructions.
  
!           '+nodsp'
                 Disable the DSP extension.
  
!           '+fp'
                 The single-precision floating-point instructions.
  
!           '+fp.dp'
                 The single- and double-precision floating-point
                 instructions.
  
!           '+nofp'
                 Disable the floating-point extension.
  
!           '+cdecp0, +cdecp1, ... , +cdecp7'
                 Enable the Custom Datapath Extension (CDE) on selected
                 coprocessors according to the numbers given in the
                 options in the range 0 to 7.
  
!      'armv8-r'
!           '+crc'
                 The Cyclic Redundancy Check (CRC) instructions.
!           '+fp.sp'
                 The single-precision FPv5 floating-point instructions.
!           '+simd'
                 The ARMv8-A Advanced SIMD and floating-point
                 instructions.
!           '+crypto'
                 The cryptographic instructions.
!           '+nocrypto'
                 Disable the cryptographic instructions.
!           '+nofp'
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!      '-march=native' causes the compiler to auto-detect the architecture
       of the build computer.  At present, this feature is only supported
       on GNU/Linux, and not all architectures are recognized.  If the
       auto-detect is unsuccessful the option has no effect.
  
! '-mtune=NAME'
       This option specifies the name of the target ARM processor for
       which GCC should tune the performance of the code.  For some ARM
       implementations better performance can be obtained by using this
!      option.  Permissible names are: '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',
!      'generic-armv7-a', 'cortex-a5', 'cortex-a7', 'cortex-a8',
!      'cortex-a9', 'cortex-a12', 'cortex-a15', 'cortex-a17',
!      'cortex-a32', 'cortex-a35', 'cortex-a53', 'cortex-a55',
!      'cortex-a57', 'cortex-a72', 'cortex-a73', 'cortex-a75',
!      'cortex-a76', 'cortex-a76ae', 'cortex-a77', 'cortex-a78',
!      'cortex-a78ae', 'cortex-a78c', 'cortex-a710', 'ares', 'cortex-r4',
!      'cortex-r4f', 'cortex-r5', 'cortex-r7', 'cortex-r8', 'cortex-r52',
!      'cortex-r52plus', 'cortex-m0', 'cortex-m0plus', 'cortex-m1',
!      'cortex-m3', 'cortex-m4', 'cortex-m7', 'cortex-m23', 'cortex-m33',
!      'cortex-m35p', 'cortex-m55', 'cortex-m85', 'cortex-x1',
!      'cortex-x1c', 'cortex-m1.small-multiply',
!      'cortex-m0.small-multiply', 'cortex-m0plus.small-multiply',
!      'exynos-m1', 'marvell-pj4', 'neoverse-n1', 'neoverse-n2',
!      'neoverse-v1', 'xscale', 'iwmmxt', 'iwmmxt2', 'ep9312', 'fa526',
!      'fa626', 'fa606te', 'fa626te', 'fmp626', 'fa726te', 'star-mc1',
!      'xgene1'.
  
       Additionally, this option can specify that GCC should tune the
       performance of the code for a big.LITTLE system.  Permissible names
!      are: 'cortex-a15.cortex-a7', 'cortex-a17.cortex-a7',
!      'cortex-a57.cortex-a53', 'cortex-a72.cortex-a53',
!      'cortex-a72.cortex-a35', 'cortex-a73.cortex-a53',
!      'cortex-a75.cortex-a55', 'cortex-a76.cortex-a55'.
  
!      '-mtune=generic-ARCH' specifies that GCC should tune the
       performance for a blend of processors within architecture ARCH.
       The aim is to generate code that run well on the current most
       popular processors, balancing between optimizations that benefit
--- 20322,20859 ----
       BE8, for older architectures the default is BE32.  BE32 format has
       been deprecated by ARM.
  
! ‘-march=NAME[+extension...]’
       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: ‘armv4t’, ‘armv5t’, ‘armv5te’, ‘armv6’,
!      ‘armv6j’, ‘armv6k’, ‘armv6kz’, ‘armv6t2’, ‘armv6z’, ‘armv6zk’,
!      ‘armv7’, ‘armv7-a’, ‘armv7ve’, ‘armv8-a’, ‘armv8.1-a’, ‘armv8.2-a’,
!      ‘armv8.3-a’, ‘armv8.4-a’, ‘armv8.5-a’, ‘armv8.6-a’, ‘armv9-a’,
!      ‘armv7-r’, ‘armv8-r’, ‘armv6-m’, ‘armv6s-m’, ‘armv7-m’, ‘armv7e-m’,
!      ‘armv8-m.base’, ‘armv8-m.main’, ‘armv8.1-m.main’, ‘armv9-a’,
!      ‘iwmmxt’ and ‘iwmmxt2’.
  
       Additionally, the following architectures, which lack support for
       the Thumb execution state, are recognized but support is
!      deprecated: ‘armv4’.
  
       Many of the architectures support extensions.  These can be added
!      by appending ‘+EXTENSION’ to the architecture name.  Extension
       options are processed in order and capabilities accumulate.  An
       extension will also enable any necessary base extensions upon which
!      it depends.  For example, the ‘+crypto’ extension will always
!      enable the ‘+simd’ extension.  The exception to the additive
!      construction is for extensions that are prefixed with ‘+no...’:
       these extensions disable the specified option and any other
       extensions that may depend on the presence of that extension.
  
!      For example, ‘-march=armv7-a+simd+nofp+vfpv4’ is equivalent to
!      writing ‘-march=armv7-a+vfpv4’ since the ‘+simd’ option is entirely
!      disabled by the ‘+nofp’ option that follows it.
  
       Most extension names are generically named, but have an effect that
       is dependent upon the architecture to which it is applied.  For
!      example, the ‘+simd’ option can be applied to both ‘armv7-a’ and
!      ‘armv8-a’ architectures, but will enable the original ARMv7-A
!      Advanced SIMD (Neon) extensions for ‘armv7-a’ and the ARMv8-A
!      variant for ‘armv8-a’.
  
       The table below lists the supported extensions for each
       architecture.  Architectures not mentioned do not support any
       extensions.
  
!      ‘armv5te’
!      ‘armv6’
!      ‘armv6j’
!      ‘armv6k’
!      ‘armv6kz’
!      ‘armv6t2’
!      ‘armv6z’
!      ‘armv6zk’
!           ‘+fp’
                 The VFPv2 floating-point instructions.  The extension
!                ‘+vfpv2’ can be used as an alias for this extension.
  
!           ‘+nofp’
                 Disable the floating-point instructions.
  
!      ‘armv7’
            The common subset of the ARMv7-A, ARMv7-R and ARMv7-M
            architectures.
!           ‘+fp’
                 The VFPv3 floating-point instructions, with 16
!                double-precision registers.  The extension ‘+vfpv3-d16’
                 can be used as an alias for this extension.  Note that
                 floating-point is not supported by the base ARMv7-M
                 architecture, but is compatible with both the ARMv7-A and
                 ARMv7-R architectures.
  
!           ‘+nofp’
                 Disable the floating-point instructions.
  
!      ‘armv7-a’
!           ‘+mp’
                 The multiprocessing extension.
  
!           ‘+sec’
                 The security extension.
  
!           ‘+fp’
                 The VFPv3 floating-point instructions, with 16
!                double-precision registers.  The extension ‘+vfpv3-d16’
                 can be used as an alias for this extension.
  
!           ‘+simd’
                 The Advanced SIMD (Neon) v1 and the VFPv3 floating-point
!                instructions.  The extensions ‘+neon’ and ‘+neon-vfpv3’
                 can be used as aliases for this extension.
  
!           ‘+vfpv3’
                 The VFPv3 floating-point instructions, with 32
                 double-precision registers.
  
!           ‘+vfpv3-d16-fp16’
                 The VFPv3 floating-point instructions, with 16
                 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           ‘+vfpv3-fp16’
                 The VFPv3 floating-point instructions, with 32
                 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           ‘+vfpv4-d16’
                 The VFPv4 floating-point instructions, with 16
                 double-precision registers.
  
!           ‘+vfpv4’
                 The VFPv4 floating-point instructions, with 32
                 double-precision registers.
  
!           ‘+neon-fp16’
                 The Advanced SIMD (Neon) v1 and the VFPv3 floating-point
                 instructions, with the half-precision floating-point
                 conversion operations.
  
!           ‘+neon-vfpv4’
                 The Advanced SIMD (Neon) v2 and the VFPv4 floating-point
                 instructions.
  
!           ‘+nosimd’
                 Disable the Advanced SIMD instructions (does not disable
                 floating point).
  
!           ‘+nofp’
                 Disable the floating-point and Advanced SIMD
                 instructions.
  
!      ‘armv7ve’
            The extended version of the ARMv7-A architecture with support
            for virtualization.
!           ‘+fp’
                 The VFPv4 floating-point instructions, with 16
!                double-precision registers.  The extension ‘+vfpv4-d16’
                 can be used as an alias for this extension.
  
!           ‘+simd’
                 The Advanced SIMD (Neon) v2 and the VFPv4 floating-point
!                instructions.  The extension ‘+neon-vfpv4’ can be used as
                 an alias for this extension.
  
!           ‘+vfpv3-d16’
                 The VFPv3 floating-point instructions, with 16
                 double-precision registers.
  
!           ‘+vfpv3’
                 The VFPv3 floating-point instructions, with 32
                 double-precision registers.
  
!           ‘+vfpv3-d16-fp16’
                 The VFPv3 floating-point instructions, with 16
                 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           ‘+vfpv3-fp16’
                 The VFPv3 floating-point instructions, with 32
                 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           ‘+vfpv4-d16’
                 The VFPv4 floating-point instructions, with 16
                 double-precision registers.
  
!           ‘+vfpv4’
                 The VFPv4 floating-point instructions, with 32
                 double-precision registers.
  
!           ‘+neon’
                 The Advanced SIMD (Neon) v1 and the VFPv3 floating-point
!                instructions.  The extension ‘+neon-vfpv3’ can be used as
                 an alias for this extension.
  
!           ‘+neon-fp16’
                 The Advanced SIMD (Neon) v1 and the VFPv3 floating-point
                 instructions, with the half-precision floating-point
                 conversion operations.
  
!           ‘+nosimd’
                 Disable the Advanced SIMD instructions (does not disable
                 floating point).
  
!           ‘+nofp’
                 Disable the floating-point and Advanced SIMD
                 instructions.
  
!      ‘armv8-a’
!           ‘+crc’
                 The Cyclic Redundancy Check (CRC) instructions.
!           ‘+simd’
                 The ARMv8-A Advanced SIMD and floating-point
                 instructions.
!           ‘+crypto’
                 The cryptographic instructions.
!           ‘+nocrypto’
                 Disable the cryptographic instructions.
!           ‘+nofp’
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
!           ‘+sb’
                 Speculation Barrier Instruction.
!           ‘+predres’
                 Execution and Data Prediction Restriction Instructions.
  
!      ‘armv8.1-a’
!           ‘+simd’
                 The ARMv8.1-A Advanced SIMD and floating-point
                 instructions.
  
!           ‘+crypto’
                 The cryptographic instructions.  This also enables the
                 Advanced SIMD and floating-point instructions.
  
!           ‘+nocrypto’
                 Disable the cryptographic instructions.
  
!           ‘+nofp’
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!           ‘+sb’
                 Speculation Barrier Instruction.
  
!           ‘+predres’
                 Execution and Data Prediction Restriction Instructions.
  
!      ‘armv8.2-a’
!      ‘armv8.3-a’
!           ‘+fp16’
                 The half-precision floating-point data processing
                 instructions.  This also enables the Advanced SIMD and
                 floating-point instructions.
  
!           ‘+fp16fml’
                 The half-precision floating-point fmla extension.  This
                 also enables the half-precision floating-point extension
                 and Advanced SIMD and floating-point instructions.
  
!           ‘+simd’
                 The ARMv8.1-A Advanced SIMD and floating-point
                 instructions.
  
!           ‘+crypto’
                 The cryptographic instructions.  This also enables the
                 Advanced SIMD and floating-point instructions.
  
!           ‘+dotprod’
                 Enable the Dot Product extension.  This also enables
                 Advanced SIMD instructions.
  
!           ‘+nocrypto’
                 Disable the cryptographic extension.
  
!           ‘+nofp’
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!           ‘+sb’
                 Speculation Barrier Instruction.
  
!           ‘+predres’
                 Execution and Data Prediction Restriction Instructions.
  
!           ‘+i8mm’
                 8-bit Integer Matrix Multiply instructions.  This also
                 enables Advanced SIMD and floating-point instructions.
  
!           ‘+bf16’
                 Brain half-precision floating-point instructions.  This
                 also enables Advanced SIMD and floating-point
                 instructions.
  
!      ‘armv8.4-a’
!           ‘+fp16’
                 The half-precision floating-point data processing
                 instructions.  This also enables the Advanced SIMD and
                 floating-point instructions as well as the Dot Product
                 extension and the half-precision floating-point fmla
                 extension.
  
!           ‘+simd’
                 The ARMv8.3-A Advanced SIMD and floating-point
                 instructions as well as the Dot Product extension.
  
!           ‘+crypto’
                 The cryptographic instructions.  This also enables the
                 Advanced SIMD and floating-point instructions as well as
                 the Dot Product extension.
  
!           ‘+nocrypto’
                 Disable the cryptographic extension.
  
!           ‘+nofp’
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!           ‘+sb’
                 Speculation Barrier Instruction.
  
!           ‘+predres’
                 Execution and Data Prediction Restriction Instructions.
  
!           ‘+i8mm’
                 8-bit Integer Matrix Multiply instructions.  This also
                 enables Advanced SIMD and floating-point instructions.
  
!           ‘+bf16’
                 Brain half-precision floating-point instructions.  This
                 also enables Advanced SIMD and floating-point
                 instructions.
  
!      ‘armv8.5-a’
!           ‘+fp16’
                 The half-precision floating-point data processing
                 instructions.  This also enables the Advanced SIMD and
                 floating-point instructions as well as the Dot Product
                 extension and the half-precision floating-point fmla
                 extension.
  
!           ‘+simd’
                 The ARMv8.3-A Advanced SIMD and floating-point
                 instructions as well as the Dot Product extension.
  
!           ‘+crypto’
                 The cryptographic instructions.  This also enables the
                 Advanced SIMD and floating-point instructions as well as
                 the Dot Product extension.
  
!           ‘+nocrypto’
                 Disable the cryptographic extension.
  
!           ‘+nofp’
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!           ‘+i8mm’
                 8-bit Integer Matrix Multiply instructions.  This also
                 enables Advanced SIMD and floating-point instructions.
  
!           ‘+bf16’
                 Brain half-precision floating-point instructions.  This
                 also enables Advanced SIMD and floating-point
                 instructions.
  
!      ‘armv8.6-a’
!           ‘+fp16’
                 The half-precision floating-point data processing
                 instructions.  This also enables the Advanced SIMD and
                 floating-point instructions as well as the Dot Product
                 extension and the half-precision floating-point fmla
                 extension.
  
!           ‘+simd’
                 The ARMv8.3-A Advanced SIMD and floating-point
                 instructions as well as the Dot Product extension.
  
!           ‘+crypto’
                 The cryptographic instructions.  This also enables the
                 Advanced SIMD and floating-point instructions as well as
                 the Dot Product extension.
  
!           ‘+nocrypto’
                 Disable the cryptographic extension.
  
!           ‘+nofp’
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!           ‘+i8mm’
                 8-bit Integer Matrix Multiply instructions.  This also
                 enables Advanced SIMD and floating-point instructions.
  
!           ‘+bf16’
                 Brain half-precision floating-point instructions.  This
                 also enables Advanced SIMD and floating-point
                 instructions.
  
!      ‘armv7-r’
!           ‘+fp.sp’
                 The single-precision VFPv3 floating-point instructions.
!                The extension ‘+vfpv3xd’ can be used as an alias for this
                 extension.
  
!           ‘+fp’
                 The VFPv3 floating-point instructions with 16
                 double-precision registers.  The extension +vfpv3-d16 can
                 be used as an alias for this extension.
  
!           ‘+vfpv3xd-d16-fp16’
                 The single-precision VFPv3 floating-point instructions
                 with 16 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           ‘+vfpv3-d16-fp16’
                 The VFPv3 floating-point instructions with 16
                 double-precision registers and the half-precision
                 floating-point conversion operations.
  
!           ‘+nofp’
                 Disable the floating-point extension.
  
!           ‘+idiv’
                 The ARM-state integer division instructions.
  
!           ‘+noidiv’
                 Disable the ARM-state integer division extension.
  
!      ‘armv7e-m’
!           ‘+fp’
                 The single-precision VFPv4 floating-point instructions.
  
!           ‘+fpv5’
                 The single-precision FPv5 floating-point instructions.
  
!           ‘+fp.dp’
                 The single- and double-precision FPv5 floating-point
                 instructions.
  
!           ‘+nofp’
                 Disable the floating-point extensions.
  
!      ‘armv8.1-m.main’
  
!           ‘+dsp’
                 The DSP instructions.
  
!           ‘+mve’
                 The M-Profile Vector Extension (MVE) integer
                 instructions.
  
!           ‘+mve.fp’
                 The M-Profile Vector Extension (MVE) integer and single
                 precision floating-point instructions.
  
!           ‘+fp’
                 The single-precision floating-point instructions.
  
!           ‘+fp.dp’
                 The single- and double-precision floating-point
                 instructions.
  
!           ‘+nofp’
                 Disable the floating-point extension.
  
!           ‘+cdecp0, +cdecp1, ... , +cdecp7’
                 Enable the Custom Datapath Extension (CDE) on selected
                 coprocessors according to the numbers given in the
                 options in the range 0 to 7.
  
!           ‘+pacbti’
                 Enable the Pointer Authentication and Branch Target
                 Identification Extension.
  
!      ‘armv8-m.main’
!           ‘+dsp’
                 The DSP instructions.
  
!           ‘+nodsp’
                 Disable the DSP extension.
  
!           ‘+fp’
                 The single-precision floating-point instructions.
  
!           ‘+fp.dp’
                 The single- and double-precision floating-point
                 instructions.
  
!           ‘+nofp’
                 Disable the floating-point extension.
  
!           ‘+cdecp0, +cdecp1, ... , +cdecp7’
                 Enable the Custom Datapath Extension (CDE) on selected
                 coprocessors according to the numbers given in the
                 options in the range 0 to 7.
  
!      ‘armv8-r’
!           ‘+crc’
                 The Cyclic Redundancy Check (CRC) instructions.
!           ‘+fp.sp’
                 The single-precision FPv5 floating-point instructions.
!           ‘+simd’
                 The ARMv8-A Advanced SIMD and floating-point
                 instructions.
!           ‘+crypto’
                 The cryptographic instructions.
!           ‘+nocrypto’
                 Disable the cryptographic instructions.
!           ‘+nofp’
                 Disable the floating-point, Advanced SIMD and
                 cryptographic instructions.
  
!      ‘-march=native’ causes the compiler to auto-detect the architecture
       of the build computer.  At present, this feature is only supported
       on GNU/Linux, and not all architectures are recognized.  If the
       auto-detect is unsuccessful the option has no effect.
  
! ‘-mtune=NAME’
       This option specifies the name of the target ARM processor for
       which GCC should tune the performance of the code.  For some ARM
       implementations better performance can be obtained by using this
!      option.  Permissible names are: ‘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’,
!      ‘generic-armv7-a’, ‘cortex-a5’, ‘cortex-a7’, ‘cortex-a8’,
!      ‘cortex-a9’, ‘cortex-a12’, ‘cortex-a15’, ‘cortex-a17’,
!      ‘cortex-a32’, ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’,
!      ‘cortex-a57’, ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’,
!      ‘cortex-a76’, ‘cortex-a76ae’, ‘cortex-a77’, ‘cortex-a78’,
!      ‘cortex-a78ae’, ‘cortex-a78c’, ‘cortex-a710’, ‘ares’, ‘cortex-r4’,
!      ‘cortex-r4f’, ‘cortex-r5’, ‘cortex-r7’, ‘cortex-r8’, ‘cortex-r52’,
!      ‘cortex-r52plus’, ‘cortex-m0’, ‘cortex-m0plus’, ‘cortex-m1’,
!      ‘cortex-m3’, ‘cortex-m4’, ‘cortex-m7’, ‘cortex-m23’, ‘cortex-m33’,
!      ‘cortex-m35p’, ‘cortex-m55’, ‘cortex-m85’, ‘cortex-x1’,
!      ‘cortex-x1c’, ‘cortex-m1.small-multiply’,
!      ‘cortex-m0.small-multiply’, ‘cortex-m0plus.small-multiply’,
!      ‘exynos-m1’, ‘marvell-pj4’, ‘neoverse-n1’, ‘neoverse-n2’,
!      ‘neoverse-v1’, ‘xscale’, ‘iwmmxt’, ‘iwmmxt2’, ‘ep9312’, ‘fa526’,
!      ‘fa626’, ‘fa606te’, ‘fa626te’, ‘fmp626’, ‘fa726te’, ‘star-mc1’,
!      ‘xgene1’.
  
       Additionally, this option can specify that GCC should tune the
       performance of the code for a big.LITTLE system.  Permissible names
!      are: ‘cortex-a15.cortex-a7’, ‘cortex-a17.cortex-a7’,
!      ‘cortex-a57.cortex-a53’, ‘cortex-a72.cortex-a53’,
!      ‘cortex-a72.cortex-a35’, ‘cortex-a73.cortex-a53’,
!      ‘cortex-a75.cortex-a55’, ‘cortex-a76.cortex-a55’.
  
!      ‘-mtune=generic-ARCH’ specifies that GCC should tune the
       performance for a blend of processors within architecture ARCH.
       The aim is to generate code that run well on the current most
       popular processors, balancing between optimizations that benefit
*************** These '-m' options are defined for the A
*** 20857,20876 ****
       CPUs.  The effects of this option may change in future GCC versions
       as CPU models come and go.
  
!      '-mtune' permits the same extension options as '-mcpu', but the
       extension options do not affect the tuning of the generated code.
  
!      '-mtune=native' causes the compiler to auto-detect the CPU of the
       build computer.  At present, this feature is only supported on
       GNU/Linux, and not all architectures are recognized.  If the
       auto-detect is unsuccessful the option has no effect.
  
! '-mcpu=NAME[+extension...]'
       This specifies the name of the target ARM processor.  GCC uses this
       name to derive the name of the target ARM architecture (as if
!      specified by '-march') and the ARM processor type for which to tune
!      for performance (as if specified by '-mtune').  Where this option
!      is used in conjunction with '-march' or '-mtune', those options
       take precedence over the appropriate part of this option.
  
       Many of the supported CPUs implement optional architectural
--- 20861,20880 ----
       CPUs.  The effects of this option may change in future GCC versions
       as CPU models come and go.
  
!      ‘-mtune’ permits the same extension options as ‘-mcpu’, but the
       extension options do not affect the tuning of the generated code.
  
!      ‘-mtune=native’ causes the compiler to auto-detect the CPU of the
       build computer.  At present, this feature is only supported on
       GNU/Linux, and not all architectures are recognized.  If the
       auto-detect is unsuccessful the option has no effect.
  
! ‘-mcpu=NAME[+extension...]’
       This specifies the name of the target ARM processor.  GCC uses this
       name to derive the name of the target ARM architecture (as if
!      specified by ‘-march’) and the ARM processor type for which to tune
!      for performance (as if specified by ‘-mtune’).  Where this option
!      is used in conjunction with ‘-march’ or ‘-mtune’, those options
       take precedence over the appropriate part of this option.
  
       Many of the supported CPUs implement optional architectural
*************** These '-m' options are defined for the A
*** 20879,21007 ****
       extension exist, then the extension syntax can be used to disable
       those extensions that have been omitted.  For floating-point and
       Advanced SIMD (Neon) instructions, the settings of the options
!      '-mfloat-abi' and '-mfpu' must also be considered: floating-point
!      and Advanced SIMD instructions will only be used if '-mfloat-abi'
!      is not set to 'soft'; and any setting of '-mfpu' other than 'auto'
       will override the available floating-point and SIMD extension
       instructions.
  
!      For example, 'cortex-a9' can be found in three major
       configurations: integer only, with just a floating-point unit or
       with floating-point and Advanced SIMD. The default is to enable all
!      the instructions, but the extensions '+nosimd' and '+nofp' can be
       used to disable just the SIMD or both the SIMD and floating-point
       instructions respectively.
  
       Permissible names for this option are the same as those for
!      '-mtune'.
  
       The following extension options are common to the listed CPUs:
  
!      '+nodsp'
!           Disable the DSP instructions on 'cortex-m33', 'cortex-m35p',
!           'cortex-m55' and 'cortex-m85'.  Also disable the M-Profile
            Vector Extension (MVE) integer and single precision
!           floating-point instructions on 'cortex-m55' and 'cortex-m85'.
  
!      '+nopacbti'
            Disable the Pointer Authentication and Branch Target
!           Identification Extension on 'cortex-m85'.
  
!      '+nomve'
            Disable the M-Profile Vector Extension (MVE) integer and
!           single precision floating-point instructions on 'cortex-m55'
!           and 'cortex-m85'.
  
!      '+nomve.fp'
            Disable the M-Profile Vector Extension (MVE) single precision
!           floating-point instructions on 'cortex-m55' and 'cortex-m85'.
  
!      '+cdecp0, +cdecp1, ... , +cdecp7'
            Enable the Custom Datapath Extension (CDE) on selected
            coprocessors according to the numbers given in the options in
!           the range 0 to 7 on 'cortex-m55'.
  
!      '+nofp'
!           Disables the floating-point instructions on 'arm9e',
!           'arm946e-s', 'arm966e-s', 'arm968e-s', 'arm10e', 'arm1020e',
!           'arm1022e', 'arm926ej-s', 'arm1026ej-s', 'cortex-r5',
!           'cortex-r7', 'cortex-r8', 'cortex-m4', 'cortex-m7',
!           'cortex-m33', 'cortex-m35p' 'cortex-m4', 'cortex-m7',
!           'cortex-m33', 'cortex-m35p', 'cortex-m55' and 'cortex-m85'.
            Disables the floating-point and SIMD instructions on
!           'generic-armv7-a', 'cortex-a5', 'cortex-a7', 'cortex-a8',
!           'cortex-a9', 'cortex-a12', 'cortex-a15', 'cortex-a17',
!           'cortex-a15.cortex-a7', 'cortex-a17.cortex-a7', 'cortex-a32',
!           'cortex-a35', 'cortex-a53' and 'cortex-a55'.
  
!      '+nofp.dp'
            Disables the double-precision component of the floating-point
!           instructions on 'cortex-r5', 'cortex-r7', 'cortex-r8',
!           'cortex-r52', 'cortex-r52plus' and 'cortex-m7'.
  
!      '+nosimd'
            Disables the SIMD (but not floating-point) instructions on
!           'generic-armv7-a', 'cortex-a5', 'cortex-a7' and 'cortex-a9'.
  
!      '+crypto'
!           Enables the cryptographic instructions on 'cortex-a32',
!           'cortex-a35', 'cortex-a53', 'cortex-a55', 'cortex-a57',
!           'cortex-a72', 'cortex-a73', 'cortex-a75', 'exynos-m1',
!           'xgene1', 'cortex-a57.cortex-a53', 'cortex-a72.cortex-a53',
!           'cortex-a73.cortex-a35', 'cortex-a73.cortex-a53' and
!           'cortex-a75.cortex-a55'.
  
!      Additionally the 'generic-armv7-a' pseudo target defaults to VFPv3
       with 16 double-precision registers.  It supports the following
!      extension options: 'mp', 'sec', 'vfpv3-d16', 'vfpv3',
!      'vfpv3-d16-fp16', 'vfpv3-fp16', 'vfpv4-d16', 'vfpv4', 'neon',
!      'neon-vfpv3', 'neon-fp16', 'neon-vfpv4'.  The meanings are the same
!      as for the extensions to '-march=armv7-a'.
  
!      '-mcpu=generic-ARCH' is also permissible, and is equivalent to
!      '-march=ARCH -mtune=generic-ARCH'.  See '-mtune' for more
       information.
  
!      '-mcpu=native' causes the compiler to auto-detect the CPU of the
       build computer.  At present, this feature is only supported on
       GNU/Linux, and not all architectures are recognized.  If the
       auto-detect is unsuccessful the option has no effect.
  
! '-mfpu=NAME'
       This specifies what floating-point hardware (or hardware emulation)
!      is available on the target.  Permissible names are: 'auto',
!      'vfpv2', 'vfpv3', 'vfpv3-fp16', 'vfpv3-d16', 'vfpv3-d16-fp16',
!      'vfpv3xd', 'vfpv3xd-fp16', 'neon-vfpv3', 'neon-fp16', 'vfpv4',
!      'vfpv4-d16', 'fpv4-sp-d16', 'neon-vfpv4', 'fpv5-d16',
!      'fpv5-sp-d16', 'fp-armv8', 'neon-fp-armv8' and
!      'crypto-neon-fp-armv8'.  Note that 'neon' is an alias for
!      'neon-vfpv3' and 'vfp' is an alias for 'vfpv2'.
  
!      The setting 'auto' is the default and is special.  It causes the
       compiler to select the floating-point and Advanced SIMD
!      instructions based on the settings of '-mcpu' and '-march'.
  
       If the selected floating-point hardware includes the NEON extension
!      (e.g. '-mfpu=neon'), note that floating-point operations are not
       generated by GCC's auto-vectorization pass unless
!      '-funsafe-math-optimizations' is also specified.  This is because
       NEON hardware does not fully implement the IEEE 754 standard for
       floating-point arithmetic (in particular denormal values are
       treated as zero), so the use of NEON instructions may lead to a
       loss of precision.
  
       You can also set the fpu name at function level by using the
!      'target("fpu=")' function attributes (*note ARM Function
       Attributes::) or pragmas (*note Function Specific Option
       Pragmas::).
  
! '-mfp16-format=NAME'
!      Specify the format of the '__fp16' half-precision floating-point
!      type.  Permissible names are 'none', 'ieee', and 'alternative'; the
!      default is 'none', in which case the '__fp16' type is not defined.
       *Note Half-Precision::, for more information.
  
! '-mstructure-size-boundary=N'
       The sizes of all structures and unions are rounded up to a multiple
       of the number of bits set by this option.  Permissible values are
       8, 32 and 64.  The default value varies for different toolchains.
--- 20883,21011 ----
       extension exist, then the extension syntax can be used to disable
       those extensions that have been omitted.  For floating-point and
       Advanced SIMD (Neon) instructions, the settings of the options
!      ‘-mfloat-abi’ and ‘-mfpu’ must also be considered: floating-point
!      and Advanced SIMD instructions will only be used if ‘-mfloat-abi’
!      is not set to ‘soft’; and any setting of ‘-mfpu’ other than ‘auto’
       will override the available floating-point and SIMD extension
       instructions.
  
!      For example, ‘cortex-a9’ can be found in three major
       configurations: integer only, with just a floating-point unit or
       with floating-point and Advanced SIMD. The default is to enable all
!      the instructions, but the extensions ‘+nosimd’ and ‘+nofp’ can be
       used to disable just the SIMD or both the SIMD and floating-point
       instructions respectively.
  
       Permissible names for this option are the same as those for
!      ‘-mtune’.
  
       The following extension options are common to the listed CPUs:
  
!      ‘+nodsp’
!           Disable the DSP instructions on ‘cortex-m33’, ‘cortex-m35p’,
!           ‘cortex-m55’ and ‘cortex-m85’.  Also disable the M-Profile
            Vector Extension (MVE) integer and single precision
!           floating-point instructions on ‘cortex-m55’ and ‘cortex-m85’.
  
!      ‘+nopacbti’
            Disable the Pointer Authentication and Branch Target
!           Identification Extension on ‘cortex-m85’.
  
!      ‘+nomve’
            Disable the M-Profile Vector Extension (MVE) integer and
!           single precision floating-point instructions on ‘cortex-m55’
!           and ‘cortex-m85’.
  
!      ‘+nomve.fp’
            Disable the M-Profile Vector Extension (MVE) single precision
!           floating-point instructions on ‘cortex-m55’ and ‘cortex-m85’.
  
!      ‘+cdecp0, +cdecp1, ... , +cdecp7’
            Enable the Custom Datapath Extension (CDE) on selected
            coprocessors according to the numbers given in the options in
!           the range 0 to 7 on ‘cortex-m55’.
  
!      ‘+nofp’
!           Disables the floating-point instructions on ‘arm9e’,
!           ‘arm946e-s’, ‘arm966e-s’, ‘arm968e-s’, ‘arm10e’, ‘arm1020e’,
!           ‘arm1022e’, ‘arm926ej-s’, ‘arm1026ej-s’, ‘cortex-r5’,
!           ‘cortex-r7’, ‘cortex-r8’, ‘cortex-m4’, ‘cortex-m7’,
!           ‘cortex-m33’, ‘cortex-m35p’ ‘cortex-m4’, ‘cortex-m7’,
!           ‘cortex-m33’, ‘cortex-m35p’, ‘cortex-m55’ and ‘cortex-m85’.
            Disables the floating-point and SIMD instructions on
!           ‘generic-armv7-a’, ‘cortex-a5’, ‘cortex-a7’, ‘cortex-a8’,
!           ‘cortex-a9’, ‘cortex-a12’, ‘cortex-a15’, ‘cortex-a17’,
!           ‘cortex-a15.cortex-a7’, ‘cortex-a17.cortex-a7’, ‘cortex-a32’,
!           ‘cortex-a35’, ‘cortex-a53’ and ‘cortex-a55’.
  
!      ‘+nofp.dp’
            Disables the double-precision component of the floating-point
!           instructions on ‘cortex-r5’, ‘cortex-r7’, ‘cortex-r8’,
!           ‘cortex-r52’, ‘cortex-r52plus’ and ‘cortex-m7’.
  
!      ‘+nosimd’
            Disables the SIMD (but not floating-point) instructions on
!           ‘generic-armv7-a’, ‘cortex-a5’, ‘cortex-a7’ and ‘cortex-a9’.
  
!      ‘+crypto’
!           Enables the cryptographic instructions on ‘cortex-a32’,
!           ‘cortex-a35’, ‘cortex-a53’, ‘cortex-a55’, ‘cortex-a57’,
!           ‘cortex-a72’, ‘cortex-a73’, ‘cortex-a75’, ‘exynos-m1’,
!           ‘xgene1’, ‘cortex-a57.cortex-a53’, ‘cortex-a72.cortex-a53’,
!           ‘cortex-a73.cortex-a35’, ‘cortex-a73.cortex-a53’ and
!           ‘cortex-a75.cortex-a55’.
  
!      Additionally the ‘generic-armv7-a’ pseudo target defaults to VFPv3
       with 16 double-precision registers.  It supports the following
!      extension options: ‘mp’, ‘sec’, ‘vfpv3-d16’, ‘vfpv3’,
!      ‘vfpv3-d16-fp16’, ‘vfpv3-fp16’, ‘vfpv4-d16’, ‘vfpv4’, ‘neon’,
!      ‘neon-vfpv3’, ‘neon-fp16’, ‘neon-vfpv4’.  The meanings are the same
!      as for the extensions to ‘-march=armv7-a’.
  
!      ‘-mcpu=generic-ARCH’ is also permissible, and is equivalent to
!      ‘-march=ARCH -mtune=generic-ARCH’.  See ‘-mtune’ for more
       information.
  
!      ‘-mcpu=native’ causes the compiler to auto-detect the CPU of the
       build computer.  At present, this feature is only supported on
       GNU/Linux, and not all architectures are recognized.  If the
       auto-detect is unsuccessful the option has no effect.
  
! ‘-mfpu=NAME’
       This specifies what floating-point hardware (or hardware emulation)
!      is available on the target.  Permissible names are: ‘auto’,
!      ‘vfpv2’, ‘vfpv3’, ‘vfpv3-fp16’, ‘vfpv3-d16’, ‘vfpv3-d16-fp16’,
!      ‘vfpv3xd’, ‘vfpv3xd-fp16’, ‘neon-vfpv3’, ‘neon-fp16’, ‘vfpv4’,
!      ‘vfpv4-d16’, ‘fpv4-sp-d16’, ‘neon-vfpv4’, ‘fpv5-d16’,
!      ‘fpv5-sp-d16’, ‘fp-armv8’, ‘neon-fp-armv8’ and
!      ‘crypto-neon-fp-armv8’.  Note that ‘neon’ is an alias for
!      ‘neon-vfpv3’ and ‘vfp’ is an alias for ‘vfpv2’.
  
!      The setting ‘auto’ is the default and is special.  It causes the
       compiler to select the floating-point and Advanced SIMD
!      instructions based on the settings of ‘-mcpu’ and ‘-march’.
  
       If the selected floating-point hardware includes the NEON extension
!      (e.g. ‘-mfpu=neon’), note that floating-point operations are not
       generated by GCC's auto-vectorization pass unless
!      ‘-funsafe-math-optimizations’ is also specified.  This is because
       NEON hardware does not fully implement the IEEE 754 standard for
       floating-point arithmetic (in particular denormal values are
       treated as zero), so the use of NEON instructions may lead to a
       loss of precision.
  
       You can also set the fpu name at function level by using the
!      ‘target("fpu=")’ function attributes (*note ARM Function
       Attributes::) or pragmas (*note Function Specific Option
       Pragmas::).
  
! ‘-mfp16-format=NAME’
!      Specify the format of the ‘__fp16’ half-precision floating-point
!      type.  Permissible names are ‘none’, ‘ieee’, and ‘alternative’; the
!      default is ‘none’, in which case the ‘__fp16’ type is not defined.
       *Note Half-Precision::, for more information.
  
! ‘-mstructure-size-boundary=N’
       The sizes of all structures and unions are rounded up to a multiple
       of the number of bits set by this option.  Permissible values are
       8, 32 and 64.  The default value varies for different toolchains.
*************** These '-m' options are defined for the A
*** 21017,21028 ****
  
       This option is deprecated.
  
! '-mabort-on-noreturn'
!      Generate a call to the function 'abort' at the end of a 'noreturn'
       function.  It is executed if the function tries to return.
  
! '-mlong-calls'
! '-mno-long-calls'
       Tells the compiler to perform function calls by first loading the
       address of the function into a register and then performing a
       subroutine call on this register.  This switch is needed if the
--- 21021,21032 ----
  
       This option is deprecated.
  
! ‘-mabort-on-noreturn’
!      Generate a call to the function ‘abort’ at the end of a ‘noreturn’
       function.  It is executed if the function tries to return.
  
! ‘-mlong-calls’
! ‘-mno-long-calls’
       Tells the compiler to perform function calls by first loading the
       address of the function into a register and then performing a
       subroutine call on this register.  This switch is needed if the
*************** These '-m' options are defined for the A
*** 21031,21073 ****
  
       Even if this switch is enabled, not all function calls are turned
       into long calls.  The heuristic is that static functions, functions
!      that have the 'short_call' attribute, functions that are inside the
!      scope of a '#pragma no_long_calls' directive, and functions whose
       definitions have already been compiled within the current
       compilation unit are not turned into long calls.  The exceptions to
       this rule are that weak function definitions, functions with the
!      'long_call' attribute or the 'section' attribute, and functions
!      that are within the scope of a '#pragma long_calls' directive are
       always turned into long calls.
  
       This feature is not enabled by default.  Specifying
!      '-mno-long-calls' restores the default behavior, as does placing
!      the function calls within the scope of a '#pragma long_calls_off'
       directive.  Note these switches have no effect on how the compiler
       generates code to handle function calls via function pointers.
  
! '-msingle-pic-base'
       Treat the register used for PIC addressing as read-only, rather
       than loading it in the prologue for each function.  The runtime
       system is responsible for initializing this register with an
       appropriate value before execution begins.
  
! '-mpic-register=REG'
       Specify the register to be used for PIC addressing.  For standard
       PIC base case, the default is any suitable register determined by
!      compiler.  For single PIC base case, the default is 'R9' if target
       is EABI based or stack-checking is enabled, otherwise the default
!      is 'R10'.
  
! '-mpic-data-is-text-relative'
       Assume that the displacement between the text and data segments is
       fixed at static link time.  This permits using PC-relative
       addressing operations to access data known to be in the data
       segment.  For non-VxWorks RTP targets, this option is enabled by
       default.  When disabled on such targets, it will enable
!      '-msingle-pic-base' by default.
  
! '-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:
--- 21035,21077 ----
  
       Even if this switch is enabled, not all function calls are turned
       into long calls.  The heuristic is that static functions, functions
!      that have the ‘short_call’ attribute, functions that are inside the
!      scope of a ‘#pragma no_long_calls’ directive, and functions whose
       definitions have already been compiled within the current
       compilation unit are not turned into long calls.  The exceptions to
       this rule are that weak function definitions, functions with the
!      ‘long_call’ attribute or the ‘section’ attribute, and functions
!      that are within the scope of a ‘#pragma long_calls’ directive are
       always turned into long calls.
  
       This feature is not enabled by default.  Specifying
!      ‘-mno-long-calls’ restores the default behavior, as does placing
!      the function calls within the scope of a ‘#pragma long_calls_off’
       directive.  Note these switches have no effect on how the compiler
       generates code to handle function calls via function pointers.
  
! ‘-msingle-pic-base’
       Treat the register used for PIC addressing as read-only, rather
       than loading it in the prologue for each function.  The runtime
       system is responsible for initializing this register with an
       appropriate value before execution begins.
  
! ‘-mpic-register=REG’
       Specify the register to be used for PIC addressing.  For standard
       PIC base case, the default is any suitable register determined by
!      compiler.  For single PIC base case, the default is ‘R9’ if target
       is EABI based or stack-checking is enabled, otherwise the default
!      is ‘R10’.
  
! ‘-mpic-data-is-text-relative’
       Assume that the displacement between the text and data segments is
       fixed at static link time.  This permits using PC-relative
       addressing operations to access data known to be in the data
       segment.  For non-VxWorks RTP targets, this option is enabled by
       default.  When disabled on such targets, it will enable
!      ‘-msingle-pic-base’ by default.
  
! ‘-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:
*************** These '-m' options are defined for the A
*** 21083,21131 ****
                     sub     fp, ip, #4
  
       When performing a stack backtrace, code can inspect the value of
!      'pc' stored at 'fp + 0'.  If the trace function then looks at
!      location 'pc - 12' and the top 8 bits are set, then we know that
       there is a function name embedded immediately preceding this
!      location and has length '((pc[-3]) & 0xff000000)'.
  
! '-mthumb'
! '-marm'
  
       Select between generating code that executes in ARM and Thumb
       states.  The default for most configurations is to generate code
       that executes in ARM state, but the default can be changed by
!      configuring GCC with the '--with-mode='STATE configure option.
  
       You can also override the ARM and Thumb mode for each function by
!      using the 'target("thumb")' and 'target("arm")' function attributes
       (*note ARM Function Attributes::) or pragmas (*note Function
       Specific Option Pragmas::).
  
! '-mflip-thumb'
       Switch ARM/Thumb modes on alternating functions.  This option is
       provided for regression testing of mixed Thumb/ARM code generation,
       and is not intended for ordinary use in compiling code.
  
! '-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
--- 21087,21135 ----
                     sub     fp, ip, #4
  
       When performing a stack backtrace, code can inspect the value of
!      ‘pc’ stored at ‘fp + 0’.  If the trace function then looks at
!      location ‘pc - 12’ and the top 8 bits are set, then we know that
       there is a function name embedded immediately preceding this
!      location and has length ‘((pc[-3]) & 0xff000000)’.
  
! ‘-mthumb’
! ‘-marm’
  
       Select between generating code that executes in ARM and Thumb
       states.  The default for most configurations is to generate code
       that executes in ARM state, but the default can be changed by
!      configuring GCC with the ‘--with-mode=’STATE configure option.
  
       You can also override the ARM and Thumb mode for each function by
!      using the ‘target("thumb")’ and ‘target("arm")’ function attributes
       (*note ARM Function Attributes::) or pragmas (*note Function
       Specific Option Pragmas::).
  
! ‘-mflip-thumb’
       Switch ARM/Thumb modes on alternating functions.  This option is
       provided for regression testing of mixed Thumb/ARM code generation,
       and is not intended for ordinary use in compiling code.
  
! ‘-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
*************** These '-m' options are defined for the A
*** 21133,21181 ****
       This option is not valid in AAPCS configurations because
       interworking is enabled by default.
  
! '-mtp=NAME'
       Specify the access model for the thread local storage pointer.  The
!      valid models are 'soft', which generates calls to
!      '__aeabi_read_tp', 'cp15', which fetches the thread pointer from
!      'cp15' directly (supported in the arm6k architecture), and 'auto',
       which uses the best available method for the selected processor.
!      The default setting is 'auto'.
  
! '-mtls-dialect=DIALECT'
       Specify the dialect to use for accessing thread local storage.  Two
!      DIALECTs are supported--'gnu' and 'gnu2'.  The 'gnu' dialect
       selects the original GNU scheme for supporting local and global
!      dynamic TLS models.  The 'gnu2' dialect selects the GNU descriptor
       scheme, which provides better performance for shared libraries.
       The GNU descriptor scheme is compatible with the original scheme,
       but does require new assembler, linker and library support.
       Initial and local exec TLS models are unaffected by this option and
       always use the original scheme.
  
! '-mword-relocations'
       Only generate absolute relocations on word-sized values (i.e.
       R_ARM_ABS32).  This is enabled by default on targets (uClinux,
       SymbianOS) where the runtime loader imposes this restriction, and
!      when '-fpic' or '-fPIC' is specified.  This option conflicts with
!      '-mslow-flash-data'.
  
! '-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.
  
! '-mfix-cortex-a57-aes-1742098'
! '-mno-fix-cortex-a57-aes-1742098'
! '-mfix-cortex-a72-aes-1655431'
! '-mno-fix-cortex-a72-aes-1655431'
       Enable (disable) mitigation for an erratum on Cortex-A57 and
       Cortex-A72 that affects the AES cryptographic instructions.  This
!      option is enabled by default when either '-mcpu=cortex-a57' or
!      '-mcpu=cortex-a72' is specified.
  
! '-munaligned-access'
! '-mno-unaligned-access'
       Enables (or disables) reading and writing of 16- and 32- bit values
       from addresses that are not 16- or 32- bit aligned.  By default
       unaligned access is disabled for all pre-ARMv6, all ARMv6-M and for
--- 21137,21185 ----
       This option is not valid in AAPCS configurations because
       interworking is enabled by default.
  
! ‘-mtp=NAME’
       Specify the access model for the thread local storage pointer.  The
!      valid models are ‘soft’, which generates calls to
!      ‘__aeabi_read_tp’, ‘cp15’, which fetches the thread pointer from
!      ‘cp15’ directly (supported in the arm6k architecture), and ‘auto’,
       which uses the best available method for the selected processor.
!      The default setting is ‘auto’.
  
! ‘-mtls-dialect=DIALECT’
       Specify the dialect to use for accessing thread local storage.  Two
!      DIALECTs are supported--‘gnu’ and ‘gnu2’.  The ‘gnu’ dialect
       selects the original GNU scheme for supporting local and global
!      dynamic TLS models.  The ‘gnu2’ dialect selects the GNU descriptor
       scheme, which provides better performance for shared libraries.
       The GNU descriptor scheme is compatible with the original scheme,
       but does require new assembler, linker and library support.
       Initial and local exec TLS models are unaffected by this option and
       always use the original scheme.
  
! ‘-mword-relocations’
       Only generate absolute relocations on word-sized values (i.e.
       R_ARM_ABS32).  This is enabled by default on targets (uClinux,
       SymbianOS) where the runtime loader imposes this restriction, and
!      when ‘-fpic’ or ‘-fPIC’ is specified.  This option conflicts with
!      ‘-mslow-flash-data’.
  
! ‘-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.
  
! ‘-mfix-cortex-a57-aes-1742098’
! ‘-mno-fix-cortex-a57-aes-1742098’
! ‘-mfix-cortex-a72-aes-1655431’
! ‘-mno-fix-cortex-a72-aes-1655431’
       Enable (disable) mitigation for an erratum on Cortex-A57 and
       Cortex-A72 that affects the AES cryptographic instructions.  This
!      option is enabled by default when either ‘-mcpu=cortex-a57’ or
!      ‘-mcpu=cortex-a72’ is specified.
  
! ‘-munaligned-access’
! ‘-mno-unaligned-access’
       Enables (or disables) reading and writing of 16- and 32- bit values
       from addresses that are not 16- or 32- bit aligned.  By default
       unaligned access is disabled for all pre-ARMv6, all ARMv6-M and for
*************** These '-m' options are defined for the A
*** 21183,21260 ****
       architectures.  If unaligned access is not enabled then words in
       packed data structures are accessed a byte at a time.
  
!      The ARM attribute 'Tag_CPU_unaligned_access' is set in the
       generated object file to either true or false, depending upon the
       setting of this option.  If unaligned access is enabled then the
!      preprocessor symbol '__ARM_FEATURE_UNALIGNED' is also defined.
  
! '-mneon-for-64bits'
       This option is deprecated and has no effect.
  
! '-mslow-flash-data'
       Assume loading data from flash is slower than fetching instruction.
       Therefore literal load is minimized for better performance.  This
       option is only supported when compiling for ARMv7 M-profile and off
!      by default.  It conflicts with '-mword-relocations'.
  
! '-masm-syntax-unified'
       Assume inline assembler is using unified asm syntax.  The default
       is currently off which implies divided syntax.  This option has no
       impact on Thumb2.  However, this may change in future releases of
       GCC. Divided syntax should be considered deprecated.
  
! '-mrestrict-it'
       Restricts generation of IT blocks to conform to the rules of
       ARMv8-A. IT blocks can only contain a single 16-bit instruction
       from a select set of instructions.  This option is on by default
       for ARMv8-A Thumb mode.
  
! '-mprint-tune-info'
       Print CPU tuning information as comment in assembler file.  This is
       an option used only for regression testing of the compiler and not
       intended for ordinary use in compiling code.  This option is
       disabled by default.
  
! '-mverbose-cost-dump'
       Enable verbose cost model dumping in the debug dump files.  This
       option is provided for use in debugging the compiler.
  
! '-mpure-code'
       Do not allow constant data to be placed in code sections.
       Additionally, when compiling for ELF object format give all text
       sections the ELF processor-specific section attribute
!      'SHF_ARM_PURECODE'.  This option is only available when generating
       non-pic code for M-profile targets.
  
! '-mcmse'
       Generate secure code as per the "ARMv8-M Security Extensions:
       Requirements on Development Tools Engineering Specification", which
       can be found on
       .
  
! '-mfix-cmse-cve-2021-35465'
!      Mitigate against a potential security issue with the 'VLLDM'
       instruction in some M-profile devices when using CMSE
       (CVE-2021-365465).  This option is enabled by default when the
!      option '-mcpu=' is used with 'cortex-m33', 'cortex-m35p',
!      'cortex-m55', 'cortex-m85' or 'star-mc1'.  The option
!      '-mno-fix-cmse-cve-2021-35465' can be used to disable the
       mitigation.
  
! '-mstack-protector-guard=GUARD'
! '-mstack-protector-guard-offset=OFFSET'
       Generate stack protection code using canary at GUARD.  Supported
!      locations are 'global' for a global canary or 'tls' for a canary
       accessible via the TLS register.  The option
!      '-mstack-protector-guard-offset=' is for use with
!      '-fstack-protector-guard=tls' and not for use in user-land code.
  
! '-mfdpic'
! '-mno-fdpic'
       Select the FDPIC ABI, which uses 64-bit function descriptors to
       represent pointers to functions.  When the compiler is configured
!      for 'arm-*-uclinuxfdpiceabi' targets, this option is on by default
!      and implies '-fPIE' if none of the PIC/PIE-related options is
       provided.  On other targets, it only enables the FDPIC-specific
       code generation features, and the user should explicitly provide
       the PIC/PIE-related options as needed.
--- 21187,21264 ----
       architectures.  If unaligned access is not enabled then words in
       packed data structures are accessed a byte at a time.
  
!      The ARM attribute ‘Tag_CPU_unaligned_access’ is set in the
       generated object file to either true or false, depending upon the
       setting of this option.  If unaligned access is enabled then the
!      preprocessor symbol ‘__ARM_FEATURE_UNALIGNED’ is also defined.
  
! ‘-mneon-for-64bits’
       This option is deprecated and has no effect.
  
! ‘-mslow-flash-data’
       Assume loading data from flash is slower than fetching instruction.
       Therefore literal load is minimized for better performance.  This
       option is only supported when compiling for ARMv7 M-profile and off
!      by default.  It conflicts with ‘-mword-relocations’.
  
! ‘-masm-syntax-unified’
       Assume inline assembler is using unified asm syntax.  The default
       is currently off which implies divided syntax.  This option has no
       impact on Thumb2.  However, this may change in future releases of
       GCC. Divided syntax should be considered deprecated.
  
! ‘-mrestrict-it’
       Restricts generation of IT blocks to conform to the rules of
       ARMv8-A. IT blocks can only contain a single 16-bit instruction
       from a select set of instructions.  This option is on by default
       for ARMv8-A Thumb mode.
  
! ‘-mprint-tune-info’
       Print CPU tuning information as comment in assembler file.  This is
       an option used only for regression testing of the compiler and not
       intended for ordinary use in compiling code.  This option is
       disabled by default.
  
! ‘-mverbose-cost-dump’
       Enable verbose cost model dumping in the debug dump files.  This
       option is provided for use in debugging the compiler.
  
! ‘-mpure-code’
       Do not allow constant data to be placed in code sections.
       Additionally, when compiling for ELF object format give all text
       sections the ELF processor-specific section attribute
!      ‘SHF_ARM_PURECODE’.  This option is only available when generating
       non-pic code for M-profile targets.
  
! ‘-mcmse’
       Generate secure code as per the "ARMv8-M Security Extensions:
       Requirements on Development Tools Engineering Specification", which
       can be found on
       .
  
! ‘-mfix-cmse-cve-2021-35465’
!      Mitigate against a potential security issue with the ‘VLLDM’
       instruction in some M-profile devices when using CMSE
       (CVE-2021-365465).  This option is enabled by default when the
!      option ‘-mcpu=’ is used with ‘cortex-m33’, ‘cortex-m35p’,
!      ‘cortex-m55’, ‘cortex-m85’ or ‘star-mc1’.  The option
!      ‘-mno-fix-cmse-cve-2021-35465’ can be used to disable the
       mitigation.
  
! ‘-mstack-protector-guard=GUARD’
! ‘-mstack-protector-guard-offset=OFFSET’
       Generate stack protection code using canary at GUARD.  Supported
!      locations are ‘global’ for a global canary or ‘tls’ for a canary
       accessible via the TLS register.  The option
!      ‘-mstack-protector-guard-offset=’ is for use with
!      ‘-fstack-protector-guard=tls’ and not for use in user-land code.
  
! ‘-mfdpic’
! ‘-mno-fdpic’
       Select the FDPIC ABI, which uses 64-bit function descriptors to
       represent pointers to functions.  When the compiler is configured
!      for ‘arm-*-uclinuxfdpiceabi’ targets, this option is on by default
!      and implies ‘-fPIE’ if none of the PIC/PIE-related options is
       provided.  On other targets, it only enables the FDPIC-specific
       code generation features, and the user should explicitly provide
       the PIC/PIE-related options as needed.
*************** These '-m' options are defined for the A
*** 21264,21298 ****
       such behavior is acceptable, use -static and -Wl,-dynamic-linker
       options.
  
!      The opposite '-mno-fdpic' option is useful (and required) to build
!      the Linux kernel using the same ('arm-*-uclinuxfdpiceabi')
       toolchain as the one used to build the userland programs.
  
! '-mbranch-protection=NONE|STANDARD|PAC-RET[+LEAF][+BTI]|BTI[+PAC-RET[+LEAF]]'
!      Enable branch protection features (armv8.1-m.main only).  'none'
       generate code without branch protection or return address signing.
!      'standard[+LEAF]' generate code with all branch protection features
!      enabled at their standard level.  'pac-ret[+LEAF]' generate code
       with return address signing set to its standard level, which is to
!      sign all functions that save the return address to memory.  'leaf'
       When return address signing is enabled, also sign leaf functions
!      even if they do not write the return address to memory.  +'bti' Add
       landing-pad instructions at the permitted targets of indirect
       branch instructions.
  
!      If the '+pacbti' architecture extension is not enabled, then all
       branch protection and return address signing operations are
       constrained to use only the instructions defined in the
       architectural-NOP space.  The generated code will remain
       backwards-compatible with earlier versions of the architecture, but
       the additional security can be enabled at run time on processors
!      that support the 'PACBTI' extension.
  
       Branch target enforcement using BTI can only be enabled at runtime
       if all code in the application has been compiled with at least
!      '-mbranch-protection=bti'.
  
!      Any setting other than 'none' is supported only on armv8-m.main or
       later.
  
       The default is to generate code without branch protection or return
--- 21268,21302 ----
       such behavior is acceptable, use -static and -Wl,-dynamic-linker
       options.
  
!      The opposite ‘-mno-fdpic’ option is useful (and required) to build
!      the Linux kernel using the same (‘arm-*-uclinuxfdpiceabi’)
       toolchain as the one used to build the userland programs.
  
! ‘-mbranch-protection=NONE|STANDARD|PAC-RET[+LEAF][+BTI]|BTI[+PAC-RET[+LEAF]]’
!      Enable branch protection features (armv8.1-m.main only).  ‘none’
       generate code without branch protection or return address signing.
!      ‘standard[+LEAF]’ generate code with all branch protection features
!      enabled at their standard level.  ‘pac-ret[+LEAF]’ generate code
       with return address signing set to its standard level, which is to
!      sign all functions that save the return address to memory.  ‘leaf’
       When return address signing is enabled, also sign leaf functions
!      even if they do not write the return address to memory.  +‘bti’ Add
       landing-pad instructions at the permitted targets of indirect
       branch instructions.
  
!      If the ‘+pacbti’ architecture extension is not enabled, then all
       branch protection and return address signing operations are
       constrained to use only the instructions defined in the
       architectural-NOP space.  The generated code will remain
       backwards-compatible with earlier versions of the architecture, but
       the additional security can be enabled at run time on processors
!      that support the ‘PACBTI’ extension.
  
       Branch target enforcement using BTI can only be enabled at runtime
       if all code in the application has been compiled with at least
!      ‘-mbranch-protection=bti’.
  
!      Any setting other than ‘none’ is supported only on armv8-m.main or
       later.
  
       The default is to generate code without branch protection or return
*************** File: gcc.info,  Node: AVR Options,  Nex
*** 21306,21499 ****
  
  These options are defined for AVR implementations:
  
! '-mmcu=MCU'
       Specify the AVR instruction set architecture (ISA) or device type.
!      The default for this option is 'avr2'.
  
       The following AVR devices and ISAs are supported.  _Note:_ A
!      complete device support consists of startup code 'crtMCU.o', a
!      device header 'avr/io*.h', a device library 'libMCU.a' and a
       device-specs (https://gcc.gnu.org/wiki/avr-gcc#spec-files) file
!      'specs-MCU'.  Only the latter is provided by the compiler according
!      the supported 'MCU's below.  The rest is supported by
       AVR-LibC (https://www.nongnu.org/avr-libc/), or by means of
!      'atpack' (https://gcc.gnu.org/wiki/avr-gcc#atpack) files from the
       hardware manufacturer.
  
!      'avr2'
            "Classic" devices with up to 8 KiB of program memory.
!           MCU = 'attiny22', 'attiny26', 'at90s2313', 'at90s2323',
!           'at90s2333', 'at90s2343', 'at90s4414', 'at90s4433',
!           'at90s4434', 'at90c8534', 'at90s8515', 'at90s8535'.
  
!      'avr25'
            "Classic" devices with up to 8 KiB of program memory and with
!           the 'MOVW' instruction.
!           MCU = 'attiny13', 'attiny13a', 'attiny24', 'attiny24a',
!           'attiny25', 'attiny261', 'attiny261a', 'attiny2313',
!           'attiny2313a', 'attiny43u', 'attiny44', 'attiny44a',
!           'attiny45', 'attiny48', 'attiny441', 'attiny461',
!           'attiny461a', 'attiny4313', 'attiny84', 'attiny84a',
!           'attiny85', 'attiny87', 'attiny88', 'attiny828', 'attiny841',
!           'attiny861', 'attiny861a', 'ata5272', 'ata6616c', 'at86rf401'.
  
!      'avr3'
            "Classic" devices with 16 KiB up to 64 KiB of program memory.
  
!           MCU = 'at76c711', 'at43usb355'.
  
!      'avr31'
            "Classic" devices with 128 KiB of program memory.
!           MCU = 'atmega103', 'at43usb320'.
  
!      'avr35'
            "Classic" devices with 16 KiB up to 64 KiB of program memory
!           and with the 'MOVW' instruction.
!           MCU = 'attiny167', 'attiny1634', 'atmega8u2', 'atmega16u2',
!           'atmega32u2', 'ata5505', 'ata6617c', 'ata664251', 'at90usb82',
!           'at90usb162'.
  
!      'avr4'
            "Enhanced" devices with up to 8 KiB of program memory.
!           MCU = 'atmega48', 'atmega48a', 'atmega48p', 'atmega48pa',
!           'atmega48pb', 'atmega8', 'atmega8a', 'atmega8hva', 'atmega88',
!           'atmega88a', 'atmega88p', 'atmega88pa', 'atmega88pb',
!           'atmega8515', 'atmega8535', 'ata5795', 'ata6285', 'ata6286',
!           'ata6289', 'ata6612c', 'at90pwm1', 'at90pwm2', 'at90pwm2b',
!           'at90pwm3', 'at90pwm3b', 'at90pwm81'.
  
!      'avr5'
            "Enhanced" devices with 16 KiB up to 64 KiB of program memory.
  
!           MCU = 'atmega16', 'atmega16a', 'atmega16hva', 'atmega16hva2',
!           'atmega16hvb', 'atmega16hvbrevb', 'atmega16m1', 'atmega16u4',
!           'atmega161', 'atmega162', 'atmega163', 'atmega164a',
!           'atmega164p', 'atmega164pa', 'atmega165', 'atmega165a',
!           'atmega165p', 'atmega165pa', 'atmega168', 'atmega168a',
!           'atmega168p', 'atmega168pa', 'atmega168pb', 'atmega169',
!           'atmega169a', 'atmega169p', 'atmega169pa', 'atmega32',
!           'atmega32a', 'atmega32c1', 'atmega32hvb', 'atmega32hvbrevb',
!           'atmega32m1', 'atmega32u4', 'atmega32u6', 'atmega323',
!           'atmega324a', 'atmega324p', 'atmega324pa', 'atmega324pb',
!           'atmega325', 'atmega325a', 'atmega325p', 'atmega325pa',
!           'atmega328', 'atmega328p', 'atmega328pb', 'atmega329',
!           'atmega329a', 'atmega329p', 'atmega329pa', 'atmega3250',
!           'atmega3250a', 'atmega3250p', 'atmega3250pa', 'atmega3290',
!           'atmega3290a', 'atmega3290p', 'atmega3290pa', 'atmega406',
!           'atmega64', 'atmega64a', 'atmega64c1', 'atmega64hve',
!           'atmega64hve2', 'atmega64m1', 'atmega64rfr2', 'atmega640',
!           'atmega644', 'atmega644a', 'atmega644p', 'atmega644pa',
!           'atmega644rfr2', 'atmega645', 'atmega645a', 'atmega645p',
!           'atmega649', 'atmega649a', 'atmega649p', 'atmega6450',
!           'atmega6450a', 'atmega6450p', 'atmega6490', 'atmega6490a',
!           'atmega6490p', 'ata5790', 'ata5790n', 'ata5791', 'ata6613c',
!           'ata6614q', 'ata5782', 'ata5831', 'ata8210', 'ata8510',
!           'ata5787', 'ata5835', 'ata5700m322', 'ata5702m322',
!           'at90pwm161', 'at90pwm216', 'at90pwm316', 'at90can32',
!           'at90can64', 'at90scr100', 'at90usb646', 'at90usb647',
!           'at94k', 'm3000'.
  
!      'avr51'
            "Enhanced" devices with 128 KiB of program memory.
!           MCU = 'atmega128', 'atmega128a', 'atmega128rfa1',
!           'atmega128rfr2', 'atmega1280', 'atmega1281', 'atmega1284',
!           'atmega1284p', 'atmega1284rfr2', 'at90can128', 'at90usb1286',
!           'at90usb1287'.
  
!      'avr6'
            "Enhanced" devices with 3-byte PC, i.e. with more than 128 KiB
            of program memory.
!           MCU = 'atmega256rfr2', 'atmega2560', 'atmega2561',
!           'atmega2564rfr2'.
  
!      'avrxmega2'
            "XMEGA" devices with more than 8 KiB and up to 64 KiB of
            program memory.
!           MCU = 'atxmega8e5', 'atxmega16a4', 'atxmega16a4u',
!           'atxmega16c4', 'atxmega16d4', 'atxmega16e5', 'atxmega32a4',
!           'atxmega32a4u', 'atxmega32c3', 'atxmega32c4', 'atxmega32d3',
!           'atxmega32d4', 'atxmega32e5', 'avr64da28', 'avr64da32',
!           'avr64da48', 'avr64da64', 'avr64db28', 'avr64db32',
!           'avr64db48', 'avr64db64', 'avr64dd14', 'avr64dd20',
!           'avr64dd28', 'avr64dd32', 'avr64du28', 'avr64du32',
!           'avr64ea28', 'avr64ea32', 'avr64ea48', 'avr64sd28',
!           'avr64sd32', 'avr64sd48'.
  
!      'avrxmega3'
            "XMEGA" devices with up to 64 KiB of combined program memory
            and RAM, and with program memory visible in the RAM address
            space.
!           MCU = 'attiny202', 'attiny204', 'attiny212', 'attiny214',
!           'attiny402', 'attiny404', 'attiny406', 'attiny412',
!           'attiny414', 'attiny416', 'attiny416auto', 'attiny417',
!           'attiny424', 'attiny426', 'attiny427', 'attiny804',
!           'attiny806', 'attiny807', 'attiny814', 'attiny816',
!           'attiny817', 'attiny824', 'attiny826', 'attiny827',
!           'attiny1604', 'attiny1606', 'attiny1607', 'attiny1614',
!           'attiny1616', 'attiny1617', 'attiny1624', 'attiny1626',
!           'attiny1627', 'attiny3214', 'attiny3216', 'attiny3217',
!           'attiny3224', 'attiny3226', 'attiny3227', 'atmega808',
!           'atmega809', 'atmega1608', 'atmega1609', 'atmega3208',
!           'atmega3209', 'atmega4808', 'atmega4809', 'avr16dd14',
!           'avr16dd20', 'avr16dd28', 'avr16dd32', 'avr16du14',
!           'avr16du20', 'avr16du28', 'avr16du32', 'avr16ea28',
!           'avr16ea32', 'avr16ea48', 'avr16eb14', 'avr16eb20',
!           'avr16eb28', 'avr16eb32', 'avr32da28', 'avr32da32',
!           'avr32da48', 'avr32db28', 'avr32db32', 'avr32db48',
!           'avr32dd14', 'avr32dd20', 'avr32dd28', 'avr32dd32',
!           'avr32du14', 'avr32du20', 'avr32du28', 'avr32du32',
!           'avr32ea28', 'avr32ea32', 'avr32ea48', 'avr32sd20',
!           'avr32sd28', 'avr32sd32'.
  
!      'avrxmega4'
            "XMEGA" devices with more than 64 KiB and up to 128 KiB of
            program memory.
!           MCU = 'atxmega64a3', 'atxmega64a3u', 'atxmega64a4u',
!           'atxmega64b1', 'atxmega64b3', 'atxmega64c3', 'atxmega64d3',
!           'atxmega64d4', 'avr128da28', 'avr128da32', 'avr128da48',
!           'avr128da64', 'avr128db28', 'avr128db32', 'avr128db48',
!           'avr128db64'.
  
!      'avrxmega5'
            "XMEGA" devices with more than 64 KiB and up to 128 KiB of
            program memory and more than 64 KiB of RAM.
!           MCU = 'atxmega64a1', 'atxmega64a1u'.
  
!      'avrxmega6'
            "XMEGA" devices with more than 128 KiB of program memory.
!           MCU = 'atxmega128a3', 'atxmega128a3u', 'atxmega128b1',
!           'atxmega128b3', 'atxmega128c3', 'atxmega128d3',
!           'atxmega128d4', 'atxmega192a3', 'atxmega192a3u',
!           'atxmega192c3', 'atxmega192d3', 'atxmega256a3',
!           'atxmega256a3b', 'atxmega256a3bu', 'atxmega256a3u',
!           'atxmega256c3', 'atxmega256d3', 'atxmega384c3',
!           'atxmega384d3'.
  
!      'avrxmega7'
            "XMEGA" devices with more than 128 KiB of program memory and
            more than 64 KiB of RAM.
!           MCU = 'atxmega128a1', 'atxmega128a1u', 'atxmega128a4u'.
  
!      'avrtiny'
            "TINY" Tiny core devices with 512 B up to 4 KiB of program
            memory.
!           MCU = 'attiny4', 'attiny5', 'attiny9', 'attiny10',
!           'attiny102', 'attiny104', 'attiny20', 'attiny40'.
  
!      'avr1'
            This ISA is implemented by the minimal AVR core and supported
            for assembler only.
!           MCU = 'attiny11', 'attiny12', 'attiny15', 'attiny28',
!           'at90s1200'.
  
! '-mabsdata'
  
       Assume that all data in static storage can be accessed by LDS / STS
       instructions.  This option has only an effect on reduced Tiny
!      devices like ATtiny40.  See also the 'absdata' *note variable
       attribute: AVR Variable Attributes.
  
! '-maccumulate-args'
       Accumulate outgoing function arguments and acquire/release the
       needed stack space for outgoing function arguments once in function
       prologue/epilogue.  Without this option, outgoing arguments are
--- 21310,21509 ----
  
  These options are defined for AVR implementations:
  
! ‘-mmcu=MCU’
       Specify the AVR instruction set architecture (ISA) or device type.
!      The default for this option is ‘avr2’.
  
       The following AVR devices and ISAs are supported.  _Note:_ A
!      complete device support consists of startup code ‘crtMCU.o’, a
!      device header ‘avr/io*.h’, a device library ‘libMCU.a’ and a
       device-specs (https://gcc.gnu.org/wiki/avr-gcc#spec-files) file
!      ‘specs-MCU’.  Only the latter is provided by the compiler according
!      the supported ‘MCU’s below.  The rest is supported by
       AVR-LibC (https://www.nongnu.org/avr-libc/), or by means of
!      ‘atpack’ (https://gcc.gnu.org/wiki/avr-gcc#atpack) files from the
       hardware manufacturer.
  
!      ‘avr2’
            "Classic" devices with up to 8 KiB of program memory.
!           MCU = ‘attiny22’, ‘attiny26’, ‘at90s2313’, ‘at90s2323’,
!           ‘at90s2333’, ‘at90s2343’, ‘at90s4414’, ‘at90s4433’,
!           ‘at90s4434’, ‘at90c8534’, ‘at90s8515’, ‘at90s8535’.
  
!      ‘avr25’
            "Classic" devices with up to 8 KiB of program memory and with
!           the ‘MOVW’ instruction.
!           MCU = ‘attiny13’, ‘attiny13a’, ‘attiny24’, ‘attiny24a’,
!           ‘attiny25’, ‘attiny261’, ‘attiny261a’, ‘attiny2313’,
!           ‘attiny2313a’, ‘attiny43u’, ‘attiny44’, ‘attiny44a’,
!           ‘attiny45’, ‘attiny48’, ‘attiny441’, ‘attiny461’,
!           ‘attiny461a’, ‘attiny4313’, ‘attiny84’, ‘attiny84a’,
!           ‘attiny85’, ‘attiny87’, ‘attiny88’, ‘attiny828’, ‘attiny841’,
!           ‘attiny861’, ‘attiny861a’, ‘ata5272’, ‘ata6616c’, ‘at86rf401’.
  
!      ‘avr3’
            "Classic" devices with 16 KiB up to 64 KiB of program memory.
  
!           MCU = ‘at76c711’, ‘at43usb355’.
  
!      ‘avr31’
            "Classic" devices with 128 KiB of program memory.
!           MCU = ‘atmega103’, ‘at43usb320’.
  
!      ‘avr35’
            "Classic" devices with 16 KiB up to 64 KiB of program memory
!           and with the ‘MOVW’ instruction.
!           MCU = ‘attiny167’, ‘attiny1634’, ‘atmega8u2’, ‘atmega16u2’,
!           ‘atmega32u2’, ‘ata5505’, ‘ata6617c’, ‘ata664251’, ‘at90usb82’,
!           ‘at90usb162’.
  
!      ‘avr4’
            "Enhanced" devices with up to 8 KiB of program memory.
!           MCU = ‘atmega48’, ‘atmega48a’, ‘atmega48p’, ‘atmega48pa’,
!           ‘atmega48pb’, ‘atmega8’, ‘atmega8a’, ‘atmega8hva’, ‘atmega88’,
!           ‘atmega88a’, ‘atmega88p’, ‘atmega88pa’, ‘atmega88pb’,
!           ‘atmega8515’, ‘atmega8535’, ‘ata5795’, ‘ata6285’, ‘ata6286’,
!           ‘ata6289’, ‘ata6612c’, ‘at90pwm1’, ‘at90pwm2’, ‘at90pwm2b’,
!           ‘at90pwm3’, ‘at90pwm3b’, ‘at90pwm81’.
  
!      ‘avr5’
            "Enhanced" devices with 16 KiB up to 64 KiB of program memory.
  
!           MCU = ‘atmega16’, ‘atmega16a’, ‘atmega16hva’, ‘atmega16hva2’,
!           ‘atmega16hvb’, ‘atmega16hvbrevb’, ‘atmega16m1’, ‘atmega16u4’,
!           ‘atmega161’, ‘atmega162’, ‘atmega163’, ‘atmega164a’,
!           ‘atmega164p’, ‘atmega164pa’, ‘atmega165’, ‘atmega165a’,
!           ‘atmega165p’, ‘atmega165pa’, ‘atmega168’, ‘atmega168a’,
!           ‘atmega168p’, ‘atmega168pa’, ‘atmega168pb’, ‘atmega169’,
!           ‘atmega169a’, ‘atmega169p’, ‘atmega169pa’, ‘atmega32’,
!           ‘atmega32a’, ‘atmega32c1’, ‘atmega32hvb’, ‘atmega32hvbrevb’,
!           ‘atmega32m1’, ‘atmega32u4’, ‘atmega32u6’, ‘atmega323’,
!           ‘atmega324a’, ‘atmega324p’, ‘atmega324pa’, ‘atmega324pb’,
!           ‘atmega325’, ‘atmega325a’, ‘atmega325p’, ‘atmega325pa’,
!           ‘atmega328’, ‘atmega328p’, ‘atmega328pb’, ‘atmega329’,
!           ‘atmega329a’, ‘atmega329p’, ‘atmega329pa’, ‘atmega3250’,
!           ‘atmega3250a’, ‘atmega3250p’, ‘atmega3250pa’, ‘atmega3290’,
!           ‘atmega3290a’, ‘atmega3290p’, ‘atmega3290pa’, ‘atmega406’,
!           ‘atmega64’, ‘atmega64a’, ‘atmega64c1’, ‘atmega64hve’,
!           ‘atmega64hve2’, ‘atmega64m1’, ‘atmega64rfr2’, ‘atmega640’,
!           ‘atmega644’, ‘atmega644a’, ‘atmega644p’, ‘atmega644pa’,
!           ‘atmega644rfr2’, ‘atmega645’, ‘atmega645a’, ‘atmega645p’,
!           ‘atmega649’, ‘atmega649a’, ‘atmega649p’, ‘atmega6450’,
!           ‘atmega6450a’, ‘atmega6450p’, ‘atmega6490’, ‘atmega6490a’,
!           ‘atmega6490p’, ‘ata5790’, ‘ata5790n’, ‘ata5791’, ‘ata6613c’,
!           ‘ata6614q’, ‘ata5782’, ‘ata5831’, ‘ata8210’, ‘ata8510’,
!           ‘ata5787’, ‘ata5835’, ‘ata5700m322’, ‘ata5702m322’,
!           ‘at90pwm161’, ‘at90pwm216’, ‘at90pwm316’, ‘at90can32’,
!           ‘at90can64’, ‘at90scr100’, ‘at90usb646’, ‘at90usb647’,
!           ‘at94k’, ‘m3000’.
  
!      ‘avr51’
            "Enhanced" devices with 128 KiB of program memory.
!           MCU = ‘atmega128’, ‘atmega128a’, ‘atmega128rfa1’,
!           ‘atmega128rfr2’, ‘atmega1280’, ‘atmega1281’, ‘atmega1284’,
!           ‘atmega1284p’, ‘atmega1284rfr2’, ‘at90can128’, ‘at90usb1286’,
!           ‘at90usb1287’.
  
!      ‘avr6’
            "Enhanced" devices with 3-byte PC, i.e. with more than 128 KiB
            of program memory.
!           MCU = ‘atmega256rfr2’, ‘atmega2560’, ‘atmega2561’,
!           ‘atmega2564rfr2’.
  
!      ‘avrxmega2’
            "XMEGA" devices with more than 8 KiB and up to 64 KiB of
            program memory.
!           MCU = ‘atxmega8e5’, ‘atxmega16a4’, ‘atxmega16a4u’,
!           ‘atxmega16c4’, ‘atxmega16d4’, ‘atxmega16e5’, ‘atxmega32a4’,
!           ‘atxmega32a4u’, ‘atxmega32c3’, ‘atxmega32c4’, ‘atxmega32d3’,
!           ‘atxmega32d4’, ‘atxmega32e5’, ‘avr64da28’, ‘avr64da28s’,
!           ‘avr64da32’, ‘avr64da32s’, ‘avr64da48’, ‘avr64da48s’,
!           ‘avr64da64’, ‘avr64da64s’, ‘avr64db28’, ‘avr64db32’,
!           ‘avr64db48’, ‘avr64db64’, ‘avr64dd14’, ‘avr64dd20’,
!           ‘avr64dd28’, ‘avr64dd32’, ‘avr64du28’, ‘avr64du32’,
!           ‘avr64ea28’, ‘avr64ea32’, ‘avr64ea48’, ‘avr64sd28’,
!           ‘avr64sd32’, ‘avr64sd48’.
  
!      ‘avrxmega3’
            "XMEGA" devices with up to 64 KiB of combined program memory
            and RAM, and with program memory visible in the RAM address
            space.
!           MCU = ‘attiny202’, ‘attiny204’, ‘attiny212’, ‘attiny214’,
!           ‘attiny402’, ‘attiny404’, ‘attiny406’, ‘attiny412’,
!           ‘attiny414’, ‘attiny416’, ‘attiny416auto’, ‘attiny417’,
!           ‘attiny424’, ‘attiny426’, ‘attiny427’, ‘attiny804’,
!           ‘attiny806’, ‘attiny807’, ‘attiny814’, ‘attiny816’,
!           ‘attiny817’, ‘attiny824’, ‘attiny826’, ‘attiny827’,
!           ‘attiny1604’, ‘attiny1606’, ‘attiny1607’, ‘attiny1614’,
!           ‘attiny1616’, ‘attiny1617’, ‘attiny1624’, ‘attiny1626’,
!           ‘attiny1627’, ‘attiny3214’, ‘attiny3216’, ‘attiny3217’,
!           ‘attiny3224’, ‘attiny3226’, ‘attiny3227’, ‘atmega808’,
!           ‘atmega809’, ‘atmega1608’, ‘atmega1609’, ‘atmega3208’,
!           ‘atmega3209’, ‘atmega4808’, ‘atmega4809’, ‘avr16dd14’,
!           ‘avr16dd20’, ‘avr16dd28’, ‘avr16dd32’, ‘avr16du14’,
!           ‘avr16du20’, ‘avr16du28’, ‘avr16du32’, ‘avr16ea28’,
!           ‘avr16ea32’, ‘avr16ea48’, ‘avr16eb14’, ‘avr16eb20’,
!           ‘avr16eb28’, ‘avr16eb32’, ‘avr16la14’, ‘avr16la20’,
!           ‘avr16la28’, ‘avr16la32’, ‘avr32da28’, ‘avr32da28s’,
!           ‘avr32da32’, ‘avr32da32s’, ‘avr32da48’, ‘avr32da48s’,
!           ‘avr32db28’, ‘avr32db32’, ‘avr32db48’, ‘avr32dd14’,
!           ‘avr32dd20’, ‘avr32dd28’, ‘avr32dd32’, ‘avr32du14’,
!           ‘avr32du20’, ‘avr32du28’, ‘avr32du32’, ‘avr32ea28’,
!           ‘avr32ea32’, ‘avr32ea48’, ‘avr32eb14’, ‘avr32eb20’,
!           ‘avr32eb28’, ‘avr32eb32’, ‘avr32la14’, ‘avr32la20’,
!           ‘avr32la28’, ‘avr32la32’, ‘avr32sd20’, ‘avr32sd28’,
!           ‘avr32sd32’.
  
!      ‘avrxmega4’
            "XMEGA" devices with more than 64 KiB and up to 128 KiB of
            program memory.
!           MCU = ‘atxmega64a3’, ‘atxmega64a3u’, ‘atxmega64a4u’,
!           ‘atxmega64b1’, ‘atxmega64b3’, ‘atxmega64c3’, ‘atxmega64d3’,
!           ‘atxmega64d4’, ‘avr128da28’, ‘avr128da28s’, ‘avr128da32’,
!           ‘avr128da32s’, ‘avr128da48’, ‘avr128da48s’, ‘avr128da64’,
!           ‘avr128da64s’, ‘avr128db28’, ‘avr128db32’, ‘avr128db48’,
!           ‘avr128db64’.
  
!      ‘avrxmega5’
            "XMEGA" devices with more than 64 KiB and up to 128 KiB of
            program memory and more than 64 KiB of RAM.
!           MCU = ‘atxmega64a1’, ‘atxmega64a1u’.
  
!      ‘avrxmega6’
            "XMEGA" devices with more than 128 KiB of program memory.
!           MCU = ‘atxmega128a3’, ‘atxmega128a3u’, ‘atxmega128b1’,
!           ‘atxmega128b3’, ‘atxmega128c3’, ‘atxmega128d3’,
!           ‘atxmega128d4’, ‘atxmega192a3’, ‘atxmega192a3u’,
!           ‘atxmega192c3’, ‘atxmega192d3’, ‘atxmega256a3’,
!           ‘atxmega256a3b’, ‘atxmega256a3bu’, ‘atxmega256a3u’,
!           ‘atxmega256c3’, ‘atxmega256d3’, ‘atxmega384c3’,
!           ‘atxmega384d3’.
  
!      ‘avrxmega7’
            "XMEGA" devices with more than 128 KiB of program memory and
            more than 64 KiB of RAM.
!           MCU = ‘atxmega128a1’, ‘atxmega128a1u’, ‘atxmega128a4u’.
  
!      ‘avrtiny’
            "TINY" Tiny core devices with 512 B up to 4 KiB of program
            memory.
!           MCU = ‘attiny4’, ‘attiny5’, ‘attiny9’, ‘attiny10’,
!           ‘attiny102’, ‘attiny104’, ‘attiny20’, ‘attiny40’.
  
!      ‘avr1’
            This ISA is implemented by the minimal AVR core and supported
            for assembler only.
!           MCU = ‘attiny11’, ‘attiny12’, ‘attiny15’, ‘attiny28’,
!           ‘at90s1200’.
  
! ‘-mabsdata’
  
       Assume that all data in static storage can be accessed by LDS / STS
       instructions.  This option has only an effect on reduced Tiny
!      devices like ATtiny40.  See also the ‘absdata’ *note variable
       attribute: AVR Variable Attributes.
  
! ‘-maccumulate-args’
       Accumulate outgoing function arguments and acquire/release the
       needed stack space for outgoing function arguments once in function
       prologue/epilogue.  Without this option, outgoing arguments are
*************** These options are defined for AVR implem
*** 21508,21560 ****
       perform several calls to functions that get their arguments on the
       stack like calls to printf-like functions.
  
! '-mbranch-cost=COST'
       Set the branch costs for conditional branch instructions to COST.
       Reasonable values for COST are small, non-negative integers.  The
       default branch cost is 0.
  
! '-mcall-prologues'
       Functions prologues/epilogues are expanded as calls to appropriate
       subroutines.  Code size is smaller.
  
! '-mdouble=BITS'
! '-mlong-double=BITS'
!      Set the size (in bits) of the 'double' or 'long double' type,
       respectively.  Possible values for BITS are 32 and 64.  Whether or
       not a specific value for BITS is allowed depends on the
!      '--with-double=' and '--with-long-double='
       configure options (https://gcc.gnu.org/install/configure.html#avr),
       and the same applies for the default values of the options.
  
! '-mgas-isr-prologues'
!      Interrupt service routines (ISRs) may use the '__gcc_isr' pseudo
       instruction supported by GNU Binutils.  If this option is on, the
       feature can still be disabled for individual ISRs by means of the
!      *note 'no_gccisr': AVR Function Attributes. function attribute.
       This feature is activated per default if optimization is on (but
!      not with '-Og', *note Optimize Options::), and if GNU Binutils
       support PR21683 (https://sourceware.org/PR21683).
  
! '-mint8'
!      Assume 'int' to be 8-bit integer.  This affects the sizes of all
!      types: a 'char' is 1 byte, an 'int' is 1 byte, a 'long' is 2 bytes,
!      and 'long long' is 4 bytes.  Please note that this option does not
       conform to the C standards, but it results in smaller code size.
  
! '-mmain-is-OS_task'
!      Do not save registers in 'main'.  The effect is the same like
!      attaching attribute *note 'OS_task': AVR Function Attributes. to
!      'main'.  It is activated per default if optimization is on.
  
! '-mno-interrupts'
       Generated code is not compatible with hardware interrupts.  Code
       size is smaller.
  
! '-mrelax'
!      Try to replace 'CALL' resp. 'JMP' instruction by the shorter
!      'RCALL' resp. 'RJMP' instruction if applicable.  Setting '-mrelax'
!      just adds the '--mlink-relax' option to the assembler's command
!      line and the '--relax' option to the linker's command line.
  
       Jump relaxing is performed by the linker because jump offsets are
       not known before code is located.  Therefore, the assembler code
--- 21518,21570 ----
       perform several calls to functions that get their arguments on the
       stack like calls to printf-like functions.
  
! ‘-mbranch-cost=COST’
       Set the branch costs for conditional branch instructions to COST.
       Reasonable values for COST are small, non-negative integers.  The
       default branch cost is 0.
  
! ‘-mcall-prologues’
       Functions prologues/epilogues are expanded as calls to appropriate
       subroutines.  Code size is smaller.
  
! ‘-mdouble=BITS’
! ‘-mlong-double=BITS’
!      Set the size (in bits) of the ‘double’ or ‘long double’ type,
       respectively.  Possible values for BITS are 32 and 64.  Whether or
       not a specific value for BITS is allowed depends on the
!      ‘--with-double=’ and ‘--with-long-double=’
       configure options (https://gcc.gnu.org/install/configure.html#avr),
       and the same applies for the default values of the options.
  
! ‘-mgas-isr-prologues’
!      Interrupt service routines (ISRs) may use the ‘__gcc_isr’ pseudo
       instruction supported by GNU Binutils.  If this option is on, the
       feature can still be disabled for individual ISRs by means of the
!      *note ‘no_gccisr’: AVR Function Attributes. function attribute.
       This feature is activated per default if optimization is on (but
!      not with ‘-Og’, *note Optimize Options::), and if GNU Binutils
       support PR21683 (https://sourceware.org/PR21683).
  
! ‘-mint8’
!      Assume ‘int’ to be 8-bit integer.  This affects the sizes of all
!      types: a ‘char’ is 1 byte, an ‘int’ is 1 byte, a ‘long’ is 2 bytes,
!      and ‘long long’ is 4 bytes.  Please note that this option does not
       conform to the C standards, but it results in smaller code size.
  
! ‘-mmain-is-OS_task’
!      Do not save registers in ‘main’.  The effect is the same like
!      attaching attribute *note ‘OS_task’: AVR Function Attributes. to
!      ‘main’.  It is activated per default if optimization is on.
  
! ‘-mno-interrupts’
       Generated code is not compatible with hardware interrupts.  Code
       size is smaller.
  
! ‘-mrelax’
!      Try to replace ‘CALL’ resp. ‘JMP’ instruction by the shorter
!      ‘RCALL’ resp. ‘RJMP’ instruction if applicable.  Setting ‘-mrelax’
!      just adds the ‘--mlink-relax’ option to the assembler's command
!      line and the ‘--relax’ option to the linker's command line.
  
       Jump relaxing is performed by the linker because jump offsets are
       not known before code is located.  Therefore, the assembler code
*************** These options are defined for AVR implem
*** 21562,21618 ****
       executable may differ from instructions in the assembler code.
  
       Relaxing must be turned on if linker stubs are needed, see the
!      section on 'EIND' and linker stubs below.
  
! '-mstrict-X'
!      Use address register 'X' in a way proposed by the hardware.  This
!      means that 'X' is only used in indirect, post-increment or
       pre-decrement addressing.
  
!      Without this option, the 'X' register may be used in the same way
!      as 'Y' or 'Z' which then is emulated by additional instructions.
!      For example, loading a value with 'X+const' addressing with a small
!      non-negative 'const < 64' to a register RN is performed as
  
            adiw r26, const   ; X += const
            ld   RN, X        ; RN = *X
            sbiw r26, const   ; X -= const
  
! '-mtiny-stack'
       Only change the lower 8 bits of the stack pointer.
  
! '-mfract-convert-truncate'
       Allow to use truncation instead of rounding towards zero for
       fractional fixed-point types.
  
! '-nodevicelib'
!      Don't link against AVR-LibC's device specific library 'lib.a'.
  
! '-nodevicespecs'
!      Don't add '-specs=device-specs/specs-MCU' to the compiler driver's
       command line.  The user takes responsibility for supplying the
       sub-processes like compiler proper, assembler and linker with
       appropriate command line options.  This means that the user has to
       supply her private device specs file by means of
!      '-specs=PATH-TO-SPECS-FILE'.  There is no more need for option
!      '-mmcu=MCU'.
  
       This option can also serve as a replacement for the older way of
!      specifying custom device-specs files that needed '-B SOME-PATH' to
!      point to a directory which contains a folder named 'device-specs'
!      which contains a specs file named 'specs-MCU', where MCU was
!      specified by '-mmcu=MCU'.
  
! '-Waddr-space-convert'
       Warn about conversions between address spaces in the case where the
       resulting address space is not contained in the incoming address
       space.
  
! '-Wmisspelled-isr'
       Warn if the ISR is misspelled, i.e. without __vector prefix.
       Enabled by default.
  
! 3.19.6.1 'EIND' and Devices with More Than 128 Ki Bytes of Flash
  ................................................................
  
  Pointers in the implementation are 16 bits wide.  The address of a
--- 21572,21628 ----
       executable may differ from instructions in the assembler code.
  
       Relaxing must be turned on if linker stubs are needed, see the
!      section on ‘EIND’ and linker stubs below.
  
! ‘-mstrict-X’
!      Use address register ‘X’ in a way proposed by the hardware.  This
!      means that ‘X’ is only used in indirect, post-increment or
       pre-decrement addressing.
  
!      Without this option, the ‘X’ register may be used in the same way
!      as ‘Y’ or ‘Z’ which then is emulated by additional instructions.
!      For example, loading a value with ‘X+const’ addressing with a small
!      non-negative ‘const < 64’ to a register RN is performed as
  
            adiw r26, const   ; X += const
            ld   RN, X        ; RN = *X
            sbiw r26, const   ; X -= const
  
! ‘-mtiny-stack’
       Only change the lower 8 bits of the stack pointer.
  
! ‘-mfract-convert-truncate’
       Allow to use truncation instead of rounding towards zero for
       fractional fixed-point types.
  
! ‘-nodevicelib’
!      Don't link against AVR-LibC's device specific library ‘lib.a’.
  
! ‘-nodevicespecs’
!      Don't add ‘-specs=device-specs/specs-MCU’ to the compiler driver's
       command line.  The user takes responsibility for supplying the
       sub-processes like compiler proper, assembler and linker with
       appropriate command line options.  This means that the user has to
       supply her private device specs file by means of
!      ‘-specs=PATH-TO-SPECS-FILE’.  There is no more need for option
!      ‘-mmcu=MCU’.
  
       This option can also serve as a replacement for the older way of
!      specifying custom device-specs files that needed ‘-B SOME-PATH’ to
!      point to a directory which contains a folder named ‘device-specs’
!      which contains a specs file named ‘specs-MCU’, where MCU was
!      specified by ‘-mmcu=MCU’.
  
! ‘-Waddr-space-convert’
       Warn about conversions between address spaces in the case where the
       resulting address space is not contained in the incoming address
       space.
  
! ‘-Wmisspelled-isr’
       Warn if the ISR is misspelled, i.e. without __vector prefix.
       Enabled by default.
  
! 3.19.6.1 ‘EIND’ and Devices with More Than 128 Ki Bytes of Flash
  ................................................................
  
  Pointers in the implementation are 16 bits wide.  The address of a
*************** and calls can target any code address in
*** 21621,21670 ****
  
   In order to facilitate indirect jump on devices with more than 128 Ki
  bytes of program memory space, there is a special function register
! called 'EIND' that serves as most significant part of the target address
! when 'EICALL' or 'EIJMP' instructions are used.
  
   Indirect jumps and calls on these devices are handled as follows by the
  compiler and are subject to some limitations:
  
!    * The compiler never sets 'EIND'.
  
!    * The compiler uses 'EIND' implicitly in 'EICALL'/'EIJMP'
!      instructions or might read 'EIND' directly in order to emulate an
!      indirect call/jump by means of a 'RET' instruction.
  
!    * The compiler assumes that 'EIND' never changes during the startup
!      code or during the application.  In particular, 'EIND' is not
       saved/restored in function or interrupt service routine
       prologue/epilogue.
  
!    * For indirect calls to functions and computed goto, the linker
       generates _stubs_.  Stubs are jump pads sometimes also called
       _trampolines_.  Thus, the indirect call/jump jumps to such a stub.
       The stub contains a direct jump to the desired address.
  
!    * Linker relaxation must be turned on so that the linker generates
       the stubs correctly in all situations.  See the compiler option
!      '-mrelax' and the linker option '--relax'.  There are corner cases
       where the linker is supposed to generate stubs but aborts without
       relaxation and without a helpful error message.
  
!    * The default linker script is arranged for code with 'EIND = 0'.  If
!      code is supposed to work for a setup with 'EIND != 0', a custom
       linker script has to be used in order to place the sections whose
!      name start with '.trampolines' into the segment where 'EIND' points
       to.
  
!    * The startup code from libgcc never sets 'EIND'.  Notice that
       startup code is a blend of code from libgcc and AVR-LibC. For the
!      impact of AVR-LibC on 'EIND', see the
       AVR-LibC user manual (https://www.nongnu.org/avr-libc/user-manual/).
  
!    * It is legitimate for user-specific startup code to set up 'EIND'
       early, for example by means of initialization code located in
!      section '.init3'.  Such code runs prior to general startup code
       that initializes RAM and calls constructors, but after the bit of
!      startup code from AVR-LibC that sets 'EIND' to the segment where
       the vector table is located.
            #include 
  
--- 21631,21680 ----
  
   In order to facilitate indirect jump on devices with more than 128 Ki
  bytes of program memory space, there is a special function register
! called ‘EIND’ that serves as most significant part of the target address
! when ‘EICALL’ or ‘EIJMP’ instructions are used.
  
   Indirect jumps and calls on these devices are handled as follows by the
  compiler and are subject to some limitations:
  
!    • The compiler never sets ‘EIND’.
  
!    • The compiler uses ‘EIND’ implicitly in ‘EICALL’/‘EIJMP’
!      instructions or might read ‘EIND’ directly in order to emulate an
!      indirect call/jump by means of a ‘RET’ instruction.
  
!    • The compiler assumes that ‘EIND’ never changes during the startup
!      code or during the application.  In particular, ‘EIND’ is not
       saved/restored in function or interrupt service routine
       prologue/epilogue.
  
!    • For indirect calls to functions and computed goto, the linker
       generates _stubs_.  Stubs are jump pads sometimes also called
       _trampolines_.  Thus, the indirect call/jump jumps to such a stub.
       The stub contains a direct jump to the desired address.
  
!    • Linker relaxation must be turned on so that the linker generates
       the stubs correctly in all situations.  See the compiler option
!      ‘-mrelax’ and the linker option ‘--relax’.  There are corner cases
       where the linker is supposed to generate stubs but aborts without
       relaxation and without a helpful error message.
  
!    • The default linker script is arranged for code with ‘EIND = 0’.  If
!      code is supposed to work for a setup with ‘EIND != 0’, a custom
       linker script has to be used in order to place the sections whose
!      name start with ‘.trampolines’ into the segment where ‘EIND’ points
       to.
  
!    • The startup code from libgcc never sets ‘EIND’.  Notice that
       startup code is a blend of code from libgcc and AVR-LibC. For the
!      impact of AVR-LibC on ‘EIND’, see the
       AVR-LibC user manual (https://www.nongnu.org/avr-libc/user-manual/).
  
!    • It is legitimate for user-specific startup code to set up ‘EIND’
       early, for example by means of initialization code located in
!      section ‘.init3’.  Such code runs prior to general startup code
       that initializes RAM and calls constructors, but after the bit of
!      startup code from AVR-LibC that sets ‘EIND’ to the segment where
       the vector table is located.
            #include 
  
*************** compiler and are subject to some limitat
*** 21676,21707 ****
                              "out %i0,r24" :: "n" (&EIND) : "r24","memory");
            }
  
!      The '__trampolines_start' symbol is defined in the linker script.
  
!    * Stubs are generated automatically by the linker if the following
       two conditions are met:
  
!         - The address of a label is taken by means of the 'gs' modifier
            (short for _generate stubs_) like so:
                 LDI r24, lo8(gs(FUNC))
                 LDI r25, hi8(gs(FUNC))
!         - The final location of that label is in a code segment
            _outside_ the segment where the stubs are located.
  
!    * The compiler emits such 'gs' modifiers for code labels in the
       following situations:
!         - Taking address of a function or code label.
!         - Computed goto.
!         - If prologue-save function is used, see '-mcall-prologues'
            command-line option.
!         - Switch/case dispatch tables.  If you do not want such dispatch
!           tables you can specify the '-fno-jump-tables' command-line
            option.
!         - C and C++ constructors/destructors called during
            startup/shutdown.
!         - If the tools hit a 'gs()' modifier explained above.
  
!    * Jumping to non-symbolic addresses like so is _not_ supported:
  
            int main (void)
            {
--- 21686,21717 ----
                              "out %i0,r24" :: "n" (&EIND) : "r24","memory");
            }
  
!      The ‘__trampolines_start’ symbol is defined in the linker script.
  
!    • Stubs are generated automatically by the linker if the following
       two conditions are met:
  
!         − The address of a label is taken by means of the ‘gs’ modifier
            (short for _generate stubs_) like so:
                 LDI r24, lo8(gs(FUNC))
                 LDI r25, hi8(gs(FUNC))
!         − The final location of that label is in a code segment
            _outside_ the segment where the stubs are located.
  
!    • The compiler emits such ‘gs’ modifiers for code labels in the
       following situations:
!         − Taking address of a function or code label.
!         − Computed goto.
!         − If prologue-save function is used, see ‘-mcall-prologues’
            command-line option.
!         − Switch/case dispatch tables.  If you do not want such dispatch
!           tables you can specify the ‘-fno-jump-tables’ command-line
            option.
!         − C and C++ constructors/destructors called during
            startup/shutdown.
!         − If the tools hit a ‘gs()’ modifier explained above.
  
!    • Jumping to non-symbolic addresses like so is _not_ supported:
  
            int main (void)
            {
*************** compiler and are subject to some limitat
*** 21710,21716 ****
            }
  
       Instead, a stub has to be set up, i.e. the function has to be
!      called through a symbol ('func_4' in the example):
  
            int main (void)
            {
--- 21720,21726 ----
            }
  
       Instead, a stub has to be set up, i.e. the function has to be
!      called through a symbol (‘func_4’ in the example):
  
            int main (void)
            {
*************** compiler and are subject to some limitat
*** 21720,21757 ****
                return func_4();
            }
  
!      and the application be linked with '-Wl,--defsym,func_4=0x4'.
!      Alternatively, 'func_4' can be defined in the linker script.
  
! 3.19.6.2 Handling of the 'RAMPD', 'RAMPX', 'RAMPY' and 'RAMPZ' Special Function Registers
  .........................................................................................
  
  Some AVR devices support memories larger than the 64 KiB range that can
  be accessed with 16-bit pointers.  To access memory locations outside
! this 64 KiB range, the content of a 'RAMP' register is used as high part
! of the address: The 'X', 'Y', 'Z' address register is concatenated with
! the 'RAMPX', 'RAMPY', 'RAMPZ' special function register, respectively,
! to get a wide address.  Similarly, 'RAMPD' is used together with direct
  addressing.
  
!    * The startup code initializes the 'RAMP' special function registers
       with zero.
  
!    * If a *note named address space: AVR Named Address Spaces. other
!      than generic or '__flash' is used, then 'RAMPZ' is set as needed
       before the operation.
  
!    * If the device supports RAM larger than 64 KiB and the compiler
!      needs to change 'RAMPZ' to accomplish an operation, 'RAMPZ' is
       reset to zero after the operation.
  
!    * If the device comes with a specific 'RAMP' register, the ISR
       prologue/epilogue saves/restores that SFR and initializes it with
       zero in case the ISR code might (implicitly) use it.
  
!    * RAM larger than 64 KiB is not supported by GCC for AVR targets.  If
       you use inline assembler to read from locations outside the 16-bit
!      address range and change one of the 'RAMP' registers, you must
       reset it to zero after the access.
  
  3.19.6.3 AVR Built-in Macros
--- 21730,21767 ----
                return func_4();
            }
  
!      and the application be linked with ‘-Wl,--defsym,func_4=0x4’.
!      Alternatively, ‘func_4’ can be defined in the linker script.
  
! 3.19.6.2 Handling of the ‘RAMPD’, ‘RAMPX’, ‘RAMPY’ and ‘RAMPZ’ Special Function Registers
  .........................................................................................
  
  Some AVR devices support memories larger than the 64 KiB range that can
  be accessed with 16-bit pointers.  To access memory locations outside
! this 64 KiB range, the content of a ‘RAMP’ register is used as high part
! of the address: The ‘X’, ‘Y’, ‘Z’ address register is concatenated with
! the ‘RAMPX’, ‘RAMPY’, ‘RAMPZ’ special function register, respectively,
! to get a wide address.  Similarly, ‘RAMPD’ is used together with direct
  addressing.
  
!    • The startup code initializes the ‘RAMP’ special function registers
       with zero.
  
!    • If a *note named address space: AVR Named Address Spaces. other
!      than generic or ‘__flash’ is used, then ‘RAMPZ’ is set as needed
       before the operation.
  
!    • If the device supports RAM larger than 64 KiB and the compiler
!      needs to change ‘RAMPZ’ to accomplish an operation, ‘RAMPZ’ is
       reset to zero after the operation.
  
!    • If the device comes with a specific ‘RAMP’ register, the ISR
       prologue/epilogue saves/restores that SFR and initializes it with
       zero in case the ISR code might (implicitly) use it.
  
!    • RAM larger than 64 KiB is not supported by GCC for AVR targets.  If
       you use inline assembler to read from locations outside the 16-bit
!      address range and change one of the ‘RAMP’ registers, you must
       reset it to zero after the access.
  
  3.19.6.3 AVR Built-in Macros
*************** addressing.
*** 21760,21935 ****
  GCC defines several built-in macros so that the user code can test for
  the presence or absence of features.  Almost any of the following
  built-in macros are deduced from device capabilities and thus triggered
! by the '-mmcu=' command-line option.
  
   For even more AVR-specific built-in macros see *note AVR Named Address
  Spaces:: and *note AVR Built-in Functions::.
  
! '__AVR_ARCH__'
       Build-in macro that resolves to a decimal number that identifies
!      the architecture and depends on the '-mmcu=MCU' option.  Possible
       values are:
  
!      '2', '25', '3', '31', '35', '4', '5', '51', '6'
  
!      for MCU='avr2', 'avr25', 'avr3', 'avr31', 'avr35', 'avr4', 'avr5',
!      'avr51', 'avr6',
  
       respectively and
  
!      '100', '102', '103', '104', '105', '106', '107'
  
!      for MCU='avrtiny', 'avrxmega2', 'avrxmega3', 'avrxmega4',
!      'avrxmega5', 'avrxmega6', 'avrxmega7', respectively.  If MCU
       specifies a device, this built-in macro is set accordingly.  For
!      example, with '-mmcu=atmega8' the macro is defined to '4'.
  
! '__AVR_DEVICE__'
!      Setting '-mmcu=DEVICE' defines this built-in macro which reflects
!      the device's name.  For example, '-mmcu=atmega8' defines the
!      built-in macro '__AVR_ATmega8__', '-mmcu=attiny261a' defines
!      '__AVR_ATtiny261A__', etc.
  
!      The built-in macros' names follow the scheme '__AVR_DEVICE__' where
       DEVICE is the device name as from the AVR user manual.  The
       difference between DEVICE in the built-in macro and DEVICE in
!      '-mmcu=DEVICE' is that the latter is always lowercase.
  
       If DEVICE is not a device but only a core architecture like
!      'avr51', this macro is not defined.
  
! '__AVR_DEVICE_NAME__'
!      Setting '-mmcu=DEVICE' defines this built-in macro to the device's
!      name.  For example, with '-mmcu=atmega8' the macro is defined to
!      'atmega8'.
  
       If DEVICE is not a device but only a core architecture like
!      'avr51', this macro is not defined.
  
! '__AVR_XMEGA__'
       The device / architecture belongs to the XMEGA family of devices.
  
! '__AVR_HAVE_ADIW__'
!      The device has the 'ADIW' and 'SBIW' instructions.
  
! '__AVR_HAVE_ELPM__'
!      The device has the 'ELPM' instruction.
  
! '__AVR_HAVE_ELPMX__'
!      The device has the 'ELPM RN,Z' and 'ELPM RN,Z+' instructions.
  
! '__AVR_HAVE_LPMX__'
!      The device has the 'LPM RN,Z' and 'LPM RN,Z+' instructions.
  
! '__AVR_HAVE_MOVW__'
!      The device has the 'MOVW' instruction to perform 16-bit
       register-register moves.
  
! '__AVR_HAVE_MUL__'
       The device has a hardware multiplier.
  
! '__AVR_HAVE_JMP_CALL__'
!      The device has the 'JMP' and 'CALL' instructions.  This is the case
       for devices with more than 8 KiB of program memory.
  
! '__AVR_HAVE_EIJMP_EICALL__'
! '__AVR_3_BYTE_PC__'
!      The device has the 'EIJMP' and 'EICALL' instructions.  This is the
       case for devices with more than 128 KiB of program memory.  This
       also means that the program counter (PC) is 3 bytes wide.
  
! '__AVR_2_BYTE_PC__'
       The program counter (PC) is 2 bytes wide.  This is the case for
       devices with up to 128 KiB of program memory.
  
! '__AVR_HAVE_8BIT_SP__'
! '__AVR_HAVE_16BIT_SP__'
       The stack pointer (SP) register is treated as 8-bit respectively
       16-bit register by the compiler.  The definition of these macros is
!      affected by '-mtiny-stack'.
  
! '__AVR_HAVE_SPH__'
! '__AVR_SP8__'
       The device has the SPH (high part of stack pointer) special
       function register or has an 8-bit stack pointer, respectively.  The
!      definition of these macros is affected by '-mmcu=' and in the cases
!      of '-mmcu=avr2' and '-mmcu=avr25' also by '-msp8'.
  
! '__AVR_HAVE_RAMPD__'
! '__AVR_HAVE_RAMPX__'
! '__AVR_HAVE_RAMPY__'
! '__AVR_HAVE_RAMPZ__'
!      The device has the 'RAMPD', 'RAMPX', 'RAMPY', 'RAMPZ' special
       function register, respectively.
  
! '__NO_INTERRUPTS__'
!      This macro reflects the '-mno-interrupts' command-line option.
  
! '__AVR_ERRATA_SKIP__'
! '__AVR_ERRATA_SKIP_JMP_CALL__'
       Some AVR devices (AT90S8515, ATmega103) must not skip 32-bit
       instructions because of a hardware erratum.  Skip instructions are
!      'SBRS', 'SBRC', 'SBIS', 'SBIC' and 'CPSE'.  The second macro is
!      only defined if '__AVR_HAVE_JMP_CALL__' is also set.
  
! '__AVR_ISA_RMW__'
       The device has Read-Modify-Write instructions (XCH, LAC, LAS and
       LAT).
  
! '__AVR_SFR_OFFSET__=OFFSET'
       Instructions that can address I/O special function registers
!      directly like 'IN', 'OUT', 'SBI', etc. may use a different address
!      as if addressed by an instruction to access RAM like 'LD' or 'STS'.
       This offset depends on the device architecture and has to be
       subtracted from the RAM address in order to get the respective
       I/O address.
  
! '__AVR_SHORT_CALLS__'
!      The '-mshort-calls' command line option is set.
  
! '__AVR_PM_BASE_ADDRESS__=ADDR'
!      Some devices support reading from flash memory by means of 'LD*'
       instructions.  The flash memory is seen in the data address space
!      at an offset of '__AVR_PM_BASE_ADDRESS__'.  If this macro is not
       defined, this feature is not available.  If defined, the address
!      space is linear and there is no need to put '.rodata' into RAM.
       This is handled by the default linker description file, and is
!      currently available for 'avrtiny' and 'avrxmega3'.  Even more
!      convenient, there is no need to use address spaces like '__flash'
!      or features like attribute 'progmem' and 'pgm_read_*'.
  
! '__WITH_AVRLIBC__'
       The compiler is configured to be used together with AVR-Libc.  See
!      the '--with-avrlibc' configure option.
  
! '__HAVE_DOUBLE_MULTILIB__'
!      Defined if '-mdouble=' acts as a multilib option.
  
! '__HAVE_DOUBLE32__'
! '__HAVE_DOUBLE64__'
       Defined if the compiler supports 32-bit double resp.  64-bit
!      double.  The actual layout is specified by option '-mdouble='.
  
! '__DEFAULT_DOUBLE__'
!      The size in bits of 'double' if '-mdouble=' is not set.  To test
!      the layout of 'double' in a program, use the built-in macro
!      '__SIZEOF_DOUBLE__'.
  
! '__HAVE_LONG_DOUBLE32__'
! '__HAVE_LONG_DOUBLE64__'
! '__HAVE_LONG_DOUBLE_MULTILIB__'
! '__DEFAULT_LONG_DOUBLE__'
!      Same as above, but for 'long double' instead of 'double'.
  
! '__WITH_DOUBLE_COMPARISON__'
!      Reflects the '--with-double-comparison={tristate|bool|libf7}'
       configure option (https://gcc.gnu.org/install/configure.html#avr)
!      and is defined to '2' or '3'.
  
! '__WITH_LIBF7_LIBGCC__'
! '__WITH_LIBF7_MATH__'
! '__WITH_LIBF7_MATH_SYMBOLS__'
!      Reflects the '--with-libf7={libgcc|math|math-symbols}'
       configure option (https://gcc.gnu.org/install/configure.html#avr).
  
  3.19.6.4 AVR Internal Options
--- 21770,21945 ----
  GCC defines several built-in macros so that the user code can test for
  the presence or absence of features.  Almost any of the following
  built-in macros are deduced from device capabilities and thus triggered
! by the ‘-mmcu=’ command-line option.
  
   For even more AVR-specific built-in macros see *note AVR Named Address
  Spaces:: and *note AVR Built-in Functions::.
  
! ‘__AVR_ARCH__’
       Build-in macro that resolves to a decimal number that identifies
!      the architecture and depends on the ‘-mmcu=MCU’ option.  Possible
       values are:
  
!      ‘2’, ‘25’, ‘3’, ‘31’, ‘35’, ‘4’, ‘5’, ‘51’, ‘6’
  
!      for MCU=‘avr2’, ‘avr25’, ‘avr3’, ‘avr31’, ‘avr35’, ‘avr4’, ‘avr5’,
!      ‘avr51’, ‘avr6’,
  
       respectively and
  
!      ‘100’, ‘102’, ‘103’, ‘104’, ‘105’, ‘106’, ‘107’
  
!      for MCU=‘avrtiny’, ‘avrxmega2’, ‘avrxmega3’, ‘avrxmega4’,
!      ‘avrxmega5’, ‘avrxmega6’, ‘avrxmega7’, respectively.  If MCU
       specifies a device, this built-in macro is set accordingly.  For
!      example, with ‘-mmcu=atmega8’ the macro is defined to ‘4’.
  
! ‘__AVR_DEVICE__’
!      Setting ‘-mmcu=DEVICE’ defines this built-in macro which reflects
!      the device's name.  For example, ‘-mmcu=atmega8’ defines the
!      built-in macro ‘__AVR_ATmega8__’, ‘-mmcu=attiny261a’ defines
!      ‘__AVR_ATtiny261A__’, etc.
  
!      The built-in macros' names follow the scheme ‘__AVR_DEVICE__’ where
       DEVICE is the device name as from the AVR user manual.  The
       difference between DEVICE in the built-in macro and DEVICE in
!      ‘-mmcu=DEVICE’ is that the latter is always lowercase.
  
       If DEVICE is not a device but only a core architecture like
!      ‘avr51’, this macro is not defined.
  
! ‘__AVR_DEVICE_NAME__’
!      Setting ‘-mmcu=DEVICE’ defines this built-in macro to the device's
!      name.  For example, with ‘-mmcu=atmega8’ the macro is defined to
!      ‘atmega8’.
  
       If DEVICE is not a device but only a core architecture like
!      ‘avr51’, this macro is not defined.
  
! ‘__AVR_XMEGA__’
       The device / architecture belongs to the XMEGA family of devices.
  
! ‘__AVR_HAVE_ADIW__’
!      The device has the ‘ADIW’ and ‘SBIW’ instructions.
  
! ‘__AVR_HAVE_ELPM__’
!      The device has the ‘ELPM’ instruction.
  
! ‘__AVR_HAVE_ELPMX__’
!      The device has the ‘ELPM RN,Z’ and ‘ELPM RN,Z+’ instructions.
  
! ‘__AVR_HAVE_LPMX__’
!      The device has the ‘LPM RN,Z’ and ‘LPM RN,Z+’ instructions.
  
! ‘__AVR_HAVE_MOVW__’
!      The device has the ‘MOVW’ instruction to perform 16-bit
       register-register moves.
  
! ‘__AVR_HAVE_MUL__’
       The device has a hardware multiplier.
  
! ‘__AVR_HAVE_JMP_CALL__’
!      The device has the ‘JMP’ and ‘CALL’ instructions.  This is the case
       for devices with more than 8 KiB of program memory.
  
! ‘__AVR_HAVE_EIJMP_EICALL__’
! ‘__AVR_3_BYTE_PC__’
!      The device has the ‘EIJMP’ and ‘EICALL’ instructions.  This is the
       case for devices with more than 128 KiB of program memory.  This
       also means that the program counter (PC) is 3 bytes wide.
  
! ‘__AVR_2_BYTE_PC__’
       The program counter (PC) is 2 bytes wide.  This is the case for
       devices with up to 128 KiB of program memory.
  
! ‘__AVR_HAVE_8BIT_SP__’
! ‘__AVR_HAVE_16BIT_SP__’
       The stack pointer (SP) register is treated as 8-bit respectively
       16-bit register by the compiler.  The definition of these macros is
!      affected by ‘-mtiny-stack’.
  
! ‘__AVR_HAVE_SPH__’
! ‘__AVR_SP8__’
       The device has the SPH (high part of stack pointer) special
       function register or has an 8-bit stack pointer, respectively.  The
!      definition of these macros is affected by ‘-mmcu=’ and in the cases
!      of ‘-mmcu=avr2’ and ‘-mmcu=avr25’ also by ‘-msp8’.
  
! ‘__AVR_HAVE_RAMPD__’
! ‘__AVR_HAVE_RAMPX__’
! ‘__AVR_HAVE_RAMPY__’
! ‘__AVR_HAVE_RAMPZ__’
!      The device has the ‘RAMPD’, ‘RAMPX’, ‘RAMPY’, ‘RAMPZ’ special
       function register, respectively.
  
! ‘__NO_INTERRUPTS__’
!      This macro reflects the ‘-mno-interrupts’ command-line option.
  
! ‘__AVR_ERRATA_SKIP__’
! ‘__AVR_ERRATA_SKIP_JMP_CALL__’
       Some AVR devices (AT90S8515, ATmega103) must not skip 32-bit
       instructions because of a hardware erratum.  Skip instructions are
!      ‘SBRS’, ‘SBRC’, ‘SBIS’, ‘SBIC’ and ‘CPSE’.  The second macro is
!      only defined if ‘__AVR_HAVE_JMP_CALL__’ is also set.
  
! ‘__AVR_ISA_RMW__’
       The device has Read-Modify-Write instructions (XCH, LAC, LAS and
       LAT).
  
! ‘__AVR_SFR_OFFSET__=OFFSET’
       Instructions that can address I/O special function registers
!      directly like ‘IN’, ‘OUT’, ‘SBI’, etc. may use a different address
!      as if addressed by an instruction to access RAM like ‘LD’ or ‘STS’.
       This offset depends on the device architecture and has to be
       subtracted from the RAM address in order to get the respective
       I/O address.
  
! ‘__AVR_SHORT_CALLS__’
!      The ‘-mshort-calls’ command line option is set.
  
! ‘__AVR_PM_BASE_ADDRESS__=ADDR’
!      Some devices support reading from flash memory by means of ‘LD*’
       instructions.  The flash memory is seen in the data address space
!      at an offset of ‘__AVR_PM_BASE_ADDRESS__’.  If this macro is not
       defined, this feature is not available.  If defined, the address
!      space is linear and there is no need to put ‘.rodata’ into RAM.
       This is handled by the default linker description file, and is
!      currently available for ‘avrtiny’ and ‘avrxmega3’.  Even more
!      convenient, there is no need to use address spaces like ‘__flash’
!      or features like attribute ‘progmem’ and ‘pgm_read_*’.
  
! ‘__WITH_AVRLIBC__’
       The compiler is configured to be used together with AVR-Libc.  See
!      the ‘--with-avrlibc’ configure option.
  
! ‘__HAVE_DOUBLE_MULTILIB__’
!      Defined if ‘-mdouble=’ acts as a multilib option.
  
! ‘__HAVE_DOUBLE32__’
! ‘__HAVE_DOUBLE64__’
       Defined if the compiler supports 32-bit double resp.  64-bit
!      double.  The actual layout is specified by option ‘-mdouble=’.
  
! ‘__DEFAULT_DOUBLE__’
!      The size in bits of ‘double’ if ‘-mdouble=’ is not set.  To test
!      the layout of ‘double’ in a program, use the built-in macro
!      ‘__SIZEOF_DOUBLE__’.
  
! ‘__HAVE_LONG_DOUBLE32__’
! ‘__HAVE_LONG_DOUBLE64__’
! ‘__HAVE_LONG_DOUBLE_MULTILIB__’
! ‘__DEFAULT_LONG_DOUBLE__’
!      Same as above, but for ‘long double’ instead of ‘double’.
  
! ‘__WITH_DOUBLE_COMPARISON__’
!      Reflects the ‘--with-double-comparison={tristate|bool|libf7}’
       configure option (https://gcc.gnu.org/install/configure.html#avr)
!      and is defined to ‘2’ or ‘3’.
  
! ‘__WITH_LIBF7_LIBGCC__’
! ‘__WITH_LIBF7_MATH__’
! ‘__WITH_LIBF7_MATH_SYMBOLS__’
!      Reflects the ‘--with-libf7={libgcc|math|math-symbols}’
       configure option (https://gcc.gnu.org/install/configure.html#avr).
  
  3.19.6.4 AVR Internal Options
*************** sub-optimal or wrong code.  They are doc
*** 21943,21973 ****
  order to get a better understanding of
  device specs (https://gcc.gnu.org/wiki/avr-gcc#spec-files) files.
  
! '-mn-flash=NUM'
       Assume that the flash memory has a size of NUM times 64 KiB. This
!      determines which '__flashN' address spaces are available.
  
! '-mrmw'
       Assume that the device supports the Read-Modify-Write instructions
!      'XCH', 'LAC', 'LAS' and 'LAT'.
  
! '-mshort-calls'
  
!      Assume that 'RJMP' and 'RCALL' can target the whole program memory.
       This option is used for multilib generation and selection for the
!      devices from architecture 'avrxmega3'.
  
! '-mskip-bug'
  
!      Generate code without skips ('CPSE', 'SBRS', 'SBRC', 'SBIS',
!      'SBIC') over 32-bit instructions.
  
! '-msp8'
       Treat the stack pointer register as an 8-bit register, i.e. assume
       the high byte of the stack pointer is zero.  This option is used by
!      the compiler to select and build multilibs for architectures 'avr2'
!      and 'avr25'.  These architectures mix devices with and without
!      'SPH'.
  
  
  File: gcc.info,  Node: Blackfin Options,  Next: C6X Options,  Prev: AVR Options,  Up: Submodel Options
--- 21953,21983 ----
  order to get a better understanding of
  device specs (https://gcc.gnu.org/wiki/avr-gcc#spec-files) files.
  
! ‘-mn-flash=NUM’
       Assume that the flash memory has a size of NUM times 64 KiB. This
!      determines which ‘__flashN’ address spaces are available.
  
! ‘-mrmw’
       Assume that the device supports the Read-Modify-Write instructions
!      ‘XCH’, ‘LAC’, ‘LAS’ and ‘LAT’.
  
! ‘-mshort-calls’
  
!      Assume that ‘RJMP’ and ‘RCALL’ can target the whole program memory.
       This option is used for multilib generation and selection for the
!      devices from architecture ‘avrxmega3’.
  
! ‘-mskip-bug’
  
!      Generate code without skips (‘CPSE’, ‘SBRS’, ‘SBRC’, ‘SBIS’,
!      ‘SBIC’) over 32-bit instructions.
  
! ‘-msp8’
       Treat the stack pointer register as an 8-bit register, i.e. assume
       the high byte of the stack pointer is zero.  This option is used by
!      the compiler to select and build multilibs for architectures ‘avr2’
!      and ‘avr25’.  These architectures mix devices with and without
!      ‘SPH’.
  
  
  File: gcc.info,  Node: Blackfin Options,  Next: C6X Options,  Prev: AVR Options,  Up: Submodel Options
*************** File: gcc.info,  Node: Blackfin Options,
*** 21975,22092 ****
  3.19.7 Blackfin Options
  -----------------------
  
! '-mcpu=CPU[-SIREVISION]'
       Specifies the name of the target Blackfin processor.  Currently,
!      CPU can be one of 'bf512', 'bf514', 'bf516', 'bf518', 'bf522',
!      'bf523', 'bf524', 'bf525', 'bf526', 'bf527', 'bf531', 'bf532',
!      'bf533', 'bf534', 'bf536', 'bf537', 'bf538', 'bf539', 'bf542',
!      'bf544', 'bf547', 'bf548', 'bf549', 'bf542m', 'bf544m', 'bf547m',
!      'bf548m', 'bf549m', 'bf561', 'bf592'.
  
       The optional SIREVISION specifies the silicon revision of the
       target Blackfin processor.  Any workarounds available for the
!      targeted silicon revision are enabled.  If SIREVISION is 'none', no
!      workarounds are enabled.  If SIREVISION is 'any', all workarounds
!      for the targeted processor are enabled.  The '__SILICON_REVISION__'
       macro is defined to two hexadecimal digits representing the major
       and minor numbers in the silicon revision.  If SIREVISION is
!      'none', the '__SILICON_REVISION__' is not defined.  If SIREVISION
!      is 'any', the '__SILICON_REVISION__' is defined to be '0xffff'.  If
       this optional SIREVISION is not used, GCC assumes the latest known
       silicon revision of the targeted Blackfin processor.
  
       GCC defines a preprocessor macro for the specified CPU.  For the
!      'bfin-elf' toolchain, this option causes the hardware BSP provided
!      by libgloss to be linked in if '-msim' is not given.
  
!      Without this option, 'bf532' is used as the processor by default.
  
!      Note that support for 'bf561' is incomplete.  For 'bf561', only the
       preprocessor macro is defined.
  
! '-msim'
       Specifies that the program will be run on the simulator.  This
       causes the simulator BSP provided by libgloss to be linked in.
!      This option has effect only for 'bfin-elf' toolchain.  Certain
!      other options, such as '-mid-shared-library' and '-mfdpic', imply
!      '-msim'.
  
! '-momit-leaf-frame-pointer'
       Don't keep the frame pointer in a register for leaf functions.
       This avoids the instructions to save, set up and restore frame
       pointers and makes an extra register available in leaf functions.
  
! '-mspecld-anomaly'
       When enabled, the compiler ensures that the generated code does not
       contain speculative loads after jump instructions.  If this option
!      is used, '__WORKAROUND_SPECULATIVE_LOADS' is defined.
  
! '-mno-specld-anomaly'
       Don't generate extra code to prevent speculative loads from
       occurring.
  
! '-mcsync-anomaly'
       When enabled, the compiler ensures that the generated code does not
       contain CSYNC or SSYNC instructions too soon after conditional
!      branches.  If this option is used, '__WORKAROUND_SPECULATIVE_SYNCS'
       is defined.
  
! '-mno-csync-anomaly'
       Don't generate extra code to prevent CSYNC or SSYNC instructions
       from occurring too soon after a conditional branch.
  
! '-mlow64k'
       When enabled, the compiler is free to take advantage of the
       knowledge that the entire program fits into the low 64k of memory.
  
! '-mno-low64k'
       Assume that the program is arbitrarily large.  This is the default.
  
! '-mstack-check-l1'
       Do stack checking using information placed into L1 scratchpad
       memory by the uClinux kernel.
  
! '-mid-shared-library'
       Generate code that supports shared libraries via the library ID
       method.  This allows for execute in place and shared libraries in
       an environment without virtual memory management.  This option
!      implies '-fPIC'.  With a 'bfin-elf' target, this option implies
!      '-msim'.
  
! '-mno-id-shared-library'
       Generate code that doesn't assume ID-based shared libraries are
       being used.  This is the default.
  
! '-mleaf-id-shared-library'
       Generate code that supports shared libraries via the library ID
       method, but assumes that this library or executable won't link
       against any other ID shared libraries.  That allows the compiler to
       use faster code for jumps and calls.
  
! '-mno-leaf-id-shared-library'
       Do not assume that the code being compiled won't link against any
       ID shared libraries.  Slower code is generated for jump and call
       insns.
  
! '-mshared-library-id=n'
       Specifies the identification number of the ID-based shared library
       being compiled.  Specifying a value of 0 generates more compact
       code; specifying other values forces the allocation of that number
       to the current library but is no more space- or time-efficient than
       omitting this option.
  
! '-msep-data'
       Generate code that allows the data segment to be located in a
       different area of memory from the text segment.  This allows for
       execute in place in an environment without virtual memory
       management by eliminating relocations against the text section.
  
! '-mno-sep-data'
       Generate code that assumes that the data segment follows the text
       segment.  This is the default.
  
! '-mlong-calls'
! '-mno-long-calls'
       Tells the compiler to perform function calls by first loading the
       address of the function into a register and then performing a
       subroutine call on this register.  This switch is needed if the
--- 21985,22102 ----
  3.19.7 Blackfin Options
  -----------------------
  
! ‘-mcpu=CPU[-SIREVISION]’
       Specifies the name of the target Blackfin processor.  Currently,
!      CPU can be one of ‘bf512’, ‘bf514’, ‘bf516’, ‘bf518’, ‘bf522’,
!      ‘bf523’, ‘bf524’, ‘bf525’, ‘bf526’, ‘bf527’, ‘bf531’, ‘bf532’,
!      ‘bf533’, ‘bf534’, ‘bf536’, ‘bf537’, ‘bf538’, ‘bf539’, ‘bf542’,
!      ‘bf544’, ‘bf547’, ‘bf548’, ‘bf549’, ‘bf542m’, ‘bf544m’, ‘bf547m’,
!      ‘bf548m’, ‘bf549m’, ‘bf561’, ‘bf592’.
  
       The optional SIREVISION specifies the silicon revision of the
       target Blackfin processor.  Any workarounds available for the
!      targeted silicon revision are enabled.  If SIREVISION is ‘none’, no
!      workarounds are enabled.  If SIREVISION is ‘any’, all workarounds
!      for the targeted processor are enabled.  The ‘__SILICON_REVISION__’
       macro is defined to two hexadecimal digits representing the major
       and minor numbers in the silicon revision.  If SIREVISION is
!      ‘none’, the ‘__SILICON_REVISION__’ is not defined.  If SIREVISION
!      is ‘any’, the ‘__SILICON_REVISION__’ is defined to be ‘0xffff’.  If
       this optional SIREVISION is not used, GCC assumes the latest known
       silicon revision of the targeted Blackfin processor.
  
       GCC defines a preprocessor macro for the specified CPU.  For the
!      ‘bfin-elf’ toolchain, this option causes the hardware BSP provided
!      by libgloss to be linked in if ‘-msim’ is not given.
  
!      Without this option, ‘bf532’ is used as the processor by default.
  
!      Note that support for ‘bf561’ is incomplete.  For ‘bf561’, only the
       preprocessor macro is defined.
  
! ‘-msim’
       Specifies that the program will be run on the simulator.  This
       causes the simulator BSP provided by libgloss to be linked in.
!      This option has effect only for ‘bfin-elf’ toolchain.  Certain
!      other options, such as ‘-mid-shared-library’ and ‘-mfdpic’, imply
!      ‘-msim’.
  
! ‘-momit-leaf-frame-pointer’
       Don't keep the frame pointer in a register for leaf functions.
       This avoids the instructions to save, set up and restore frame
       pointers and makes an extra register available in leaf functions.
  
! ‘-mspecld-anomaly’
       When enabled, the compiler ensures that the generated code does not
       contain speculative loads after jump instructions.  If this option
!      is used, ‘__WORKAROUND_SPECULATIVE_LOADS’ is defined.
  
! ‘-mno-specld-anomaly’
       Don't generate extra code to prevent speculative loads from
       occurring.
  
! ‘-mcsync-anomaly’
       When enabled, the compiler ensures that the generated code does not
       contain CSYNC or SSYNC instructions too soon after conditional
!      branches.  If this option is used, ‘__WORKAROUND_SPECULATIVE_SYNCS’
       is defined.
  
! ‘-mno-csync-anomaly’
       Don't generate extra code to prevent CSYNC or SSYNC instructions
       from occurring too soon after a conditional branch.
  
! ‘-mlow64k’
       When enabled, the compiler is free to take advantage of the
       knowledge that the entire program fits into the low 64k of memory.
  
! ‘-mno-low64k’
       Assume that the program is arbitrarily large.  This is the default.
  
! ‘-mstack-check-l1’
       Do stack checking using information placed into L1 scratchpad
       memory by the uClinux kernel.
  
! ‘-mid-shared-library’
       Generate code that supports shared libraries via the library ID
       method.  This allows for execute in place and shared libraries in
       an environment without virtual memory management.  This option
!      implies ‘-fPIC’.  With a ‘bfin-elf’ target, this option implies
!      ‘-msim’.
  
! ‘-mno-id-shared-library’
       Generate code that doesn't assume ID-based shared libraries are
       being used.  This is the default.
  
! ‘-mleaf-id-shared-library’
       Generate code that supports shared libraries via the library ID
       method, but assumes that this library or executable won't link
       against any other ID shared libraries.  That allows the compiler to
       use faster code for jumps and calls.
  
! ‘-mno-leaf-id-shared-library’
       Do not assume that the code being compiled won't link against any
       ID shared libraries.  Slower code is generated for jump and call
       insns.
  
! ‘-mshared-library-id=n’
       Specifies the identification number of the ID-based shared library
       being compiled.  Specifying a value of 0 generates more compact
       code; specifying other values forces the allocation of that number
       to the current library but is no more space- or time-efficient than
       omitting this option.
  
! ‘-msep-data’
       Generate code that allows the data segment to be located in a
       different area of memory from the text segment.  This allows for
       execute in place in an environment without virtual memory
       management by eliminating relocations against the text section.
  
! ‘-mno-sep-data’
       Generate code that assumes that the data segment follows the text
       segment.  This is the default.
  
! ‘-mlong-calls’
! ‘-mno-long-calls’
       Tells the compiler to perform function calls by first loading the
       address of the function into a register and then performing a
       subroutine call on this register.  This switch is needed if the
*************** File: gcc.info,  Node: Blackfin Options,
*** 22094,22149 ****
       offset-based version of subroutine call instruction.
  
       This feature is not enabled by default.  Specifying
!      '-mno-long-calls' restores the default behavior.  Note these
       switches have no effect on how the compiler generates code to
       handle function calls via function pointers.
  
! '-mfast-fp'
       Link with the fast floating-point library.  This library relaxes
       some of the IEEE floating-point standard's rules for checking
       inputs against Not-a-Number (NAN), in the interest of performance.
  
! '-minline-plt'
       Enable inlining of PLT entries in function calls to functions that
!      are not known to bind locally.  It has no effect without '-mfdpic'.
  
! '-mmulticore'
       Build a standalone application for multicore Blackfin processors.
       This option causes proper start files and link scripts supporting
!      multicore to be used, and defines the macro '__BFIN_MULTICORE'.  It
!      can only be used with '-mcpu=bf561[-SIREVISION]'.
  
!      This option can be used with '-mcorea' or '-mcoreb', which selects
!      the one-application-per-core programming model.  Without '-mcorea'
!      or '-mcoreb', the single-application/dual-core programming model is
       used.  In this model, the main function of Core B should be named
!      as 'coreb_main'.
  
       If this option is not used, the single-core application programming
       model is used.
  
! '-mcorea'
       Build a standalone application for Core A of BF561 when using the
       one-application-per-core programming model.  Proper start files and
       link scripts are used to support Core A, and the macro
!      '__BFIN_COREA' is defined.  This option can only be used in
!      conjunction with '-mmulticore'.
  
! '-mcoreb'
       Build a standalone application for Core B of BF561 when using the
       one-application-per-core programming model.  Proper start files and
       link scripts are used to support Core B, and the macro
!      '__BFIN_COREB' is defined.  When this option is used, 'coreb_main'
!      should be used instead of 'main'.  This option can only be used in
!      conjunction with '-mmulticore'.
  
! '-msdram'
       Build a standalone application for SDRAM. Proper start files and
       link scripts are used to put the application into SDRAM, and the
!      macro '__BFIN_SDRAM' is defined.  The loader should initialize
       SDRAM before loading the application.
  
! '-micplb'
       Assume that ICPLBs are enabled at run time.  This has an effect on
       certain anomaly workarounds.  For Linux targets, the default is to
       assume ICPLBs are enabled; for standalone applications the default
--- 22104,22159 ----
       offset-based version of subroutine call instruction.
  
       This feature is not enabled by default.  Specifying
!      ‘-mno-long-calls’ restores the default behavior.  Note these
       switches have no effect on how the compiler generates code to
       handle function calls via function pointers.
  
! ‘-mfast-fp’
       Link with the fast floating-point library.  This library relaxes
       some of the IEEE floating-point standard's rules for checking
       inputs against Not-a-Number (NAN), in the interest of performance.
  
! ‘-minline-plt’
       Enable inlining of PLT entries in function calls to functions that
!      are not known to bind locally.  It has no effect without ‘-mfdpic’.
  
! ‘-mmulticore’
       Build a standalone application for multicore Blackfin processors.
       This option causes proper start files and link scripts supporting
!      multicore to be used, and defines the macro ‘__BFIN_MULTICORE’.  It
!      can only be used with ‘-mcpu=bf561[-SIREVISION]’.
  
!      This option can be used with ‘-mcorea’ or ‘-mcoreb’, which selects
!      the one-application-per-core programming model.  Without ‘-mcorea’
!      or ‘-mcoreb’, the single-application/dual-core programming model is
       used.  In this model, the main function of Core B should be named
!      as ‘coreb_main’.
  
       If this option is not used, the single-core application programming
       model is used.
  
! ‘-mcorea’
       Build a standalone application for Core A of BF561 when using the
       one-application-per-core programming model.  Proper start files and
       link scripts are used to support Core A, and the macro
!      ‘__BFIN_COREA’ is defined.  This option can only be used in
!      conjunction with ‘-mmulticore’.
  
! ‘-mcoreb’
       Build a standalone application for Core B of BF561 when using the
       one-application-per-core programming model.  Proper start files and
       link scripts are used to support Core B, and the macro
!      ‘__BFIN_COREB’ is defined.  When this option is used, ‘coreb_main’
!      should be used instead of ‘main’.  This option can only be used in
!      conjunction with ‘-mmulticore’.
  
! ‘-msdram’
       Build a standalone application for SDRAM. Proper start files and
       link scripts are used to put the application into SDRAM, and the
!      macro ‘__BFIN_SDRAM’ is defined.  The loader should initialize
       SDRAM before loading the application.
  
! ‘-micplb’
       Assume that ICPLBs are enabled at run time.  This has an effect on
       certain anomaly workarounds.  For Linux targets, the default is to
       assume ICPLBs are enabled; for standalone applications the default
*************** File: gcc.info,  Node: C6X Options,  Nex
*** 22155,22194 ****
  3.19.8 C6X Options
  ------------------
  
! '-march=NAME'
       This specifies the name of the target architecture.  GCC uses this
       name to determine what kind of instructions it can emit when
!      generating assembly code.  Permissible names are: 'c62x', 'c64x',
!      'c64x+', 'c67x', 'c67x+', 'c674x'.
  
! '-mbig-endian'
       Generate code for a big-endian target.
  
! '-mlittle-endian'
       Generate code for a little-endian target.  This is the default.
  
! '-msim'
       Choose startup files and linker script suitable for the simulator.
  
! '-msdata=default'
!      Put small global and static data in the '.neardata' section, which
!      is pointed to by register 'B14'.  Put small uninitialized global
!      and static data in the '.bss' section, which is adjacent to the
!      '.neardata' section.  Put small read-only data into the '.rodata'
       section.  The corresponding sections used for large pieces of data
!      are '.fardata', '.far' and '.const'.
  
! '-msdata=all'
       Put all data, not just small objects, into the sections reserved
!      for small data, and use addressing relative to the 'B14' register
       to access them.
  
! '-msdata=none'
       Make no use of the sections reserved for small data, and use
       absolute addresses to access all data.  Put all initialized global
!      and static data in the '.fardata' section, and all uninitialized
!      data in the '.far' section.  Put all constant data into the
!      '.const' section.
  
  
  File: gcc.info,  Node: CRIS Options,  Next: C-SKY Options,  Prev: C6X Options,  Up: Submodel Options
--- 22165,22204 ----
  3.19.8 C6X Options
  ------------------
  
! ‘-march=NAME’
       This specifies the name of the target architecture.  GCC uses this
       name to determine what kind of instructions it can emit when
!      generating assembly code.  Permissible names are: ‘c62x’, ‘c64x’,
!      ‘c64x+’, ‘c67x’, ‘c67x+’, ‘c674x’.
  
! ‘-mbig-endian’
       Generate code for a big-endian target.
  
! ‘-mlittle-endian’
       Generate code for a little-endian target.  This is the default.
  
! ‘-msim’
       Choose startup files and linker script suitable for the simulator.
  
! ‘-msdata=default’
!      Put small global and static data in the ‘.neardata’ section, which
!      is pointed to by register ‘B14’.  Put small uninitialized global
!      and static data in the ‘.bss’ section, which is adjacent to the
!      ‘.neardata’ section.  Put small read-only data into the ‘.rodata’
       section.  The corresponding sections used for large pieces of data
!      are ‘.fardata’, ‘.far’ and ‘.const’.
  
! ‘-msdata=all’
       Put all data, not just small objects, into the sections reserved
!      for small data, and use addressing relative to the ‘B14’ register
       to access them.
  
! ‘-msdata=none’
       Make no use of the sections reserved for small data, and use
       absolute addresses to access all data.  Put all initialized global
!      and static data in the ‘.fardata’ section, and all uninitialized
!      data in the ‘.far’ section.  Put all constant data into the
!      ‘.const’ section.
  
  
  File: gcc.info,  Node: CRIS Options,  Next: C-SKY Options,  Prev: C6X Options,  Up: Submodel Options
*************** File: gcc.info,  Node: CRIS Options,  Ne
*** 22198,22265 ****
  
  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'.
  
! '-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 disabled by default.
  
! '-mpdebug'
       Enable CRIS-specific verbose debug-related information in the
       assembly code.  This option also has the effect of turning off the
!      '#NO_APP' formatted-code indicator to the assembler at the
       beginning of the assembly file.
  
! '-mcc-init'
       Do not use condition-code results from previous instruction; always
       emit compare and test instructions before use of condition codes.
  
! '-mno-side-effects'
       Do not emit instructions with side effects in addressing modes
       other than post-increment.
  
! '-mstack-align'
! '-mno-stack-align'
! '-mdata-align'
! '-mno-data-align'
! '-mconst-align'
! '-mno-const-align'
!      These options ('no-' options) arrange (eliminate arrangements) for
       the stack frame, individual data and constants to be aligned for
       the maximum single data access size for the chosen CPU model.  The
       default is to arrange for 32-bit alignment.  ABI details such as
       structure layout are not affected by these options.
  
! '-m32-bit'
! '-m16-bit'
! '-m8-bit'
       Similar to the stack- data- and const-align options above, these
       options arrange for stack frame, writable data and constants to all
       be 32-bit, 16-bit or 8-bit aligned.  The default is 32-bit
       alignment.
  
! '-mno-prologue-epilogue'
! '-mprologue-epilogue'
!      With '-mno-prologue-epilogue', the normal function prologue and
       epilogue which set up the stack frame are omitted and no return
       instructions or return sequences are generated in the code.  Use
       this option only together with visual inspection of the compiled
--- 22208,22275 ----
  
  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’.
  
! ‘-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 disabled by default.
  
! ‘-mpdebug’
       Enable CRIS-specific verbose debug-related information in the
       assembly code.  This option also has the effect of turning off the
!      ‘#NO_APP’ formatted-code indicator to the assembler at the
       beginning of the assembly file.
  
! ‘-mcc-init’
       Do not use condition-code results from previous instruction; always
       emit compare and test instructions before use of condition codes.
  
! ‘-mno-side-effects’
       Do not emit instructions with side effects in addressing modes
       other than post-increment.
  
! ‘-mstack-align’
! ‘-mno-stack-align’
! ‘-mdata-align’
! ‘-mno-data-align’
! ‘-mconst-align’
! ‘-mno-const-align’
!      These options (‘no-’ options) arrange (eliminate arrangements) for
       the stack frame, individual data and constants to be aligned for
       the maximum single data access size for the chosen CPU model.  The
       default is to arrange for 32-bit alignment.  ABI details such as
       structure layout are not affected by these options.
  
! ‘-m32-bit’
! ‘-m16-bit’
! ‘-m8-bit’
       Similar to the stack- data- and const-align options above, these
       options arrange for stack frame, writable data and constants to all
       be 32-bit, 16-bit or 8-bit aligned.  The default is 32-bit
       alignment.
  
! ‘-mno-prologue-epilogue’
! ‘-mprologue-epilogue’
!      With ‘-mno-prologue-epilogue’, the normal function prologue and
       epilogue which set up the stack frame are omitted and no return
       instructions or return sequences are generated in the code.  Use
       this option only together with visual inspection of the compiled
*************** These options are defined specifically f
*** 22267,22282 ****
       must be saved, or storage for local variables needs to be
       allocated.
  
! '-melf'
       Legacy no-op option.
  
! '-sim'
       This option 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.
  
  
--- 22277,22292 ----
       must be saved, or storage for local variables needs to be
       allocated.
  
! ‘-melf’
       Legacy no-op option.
  
! ‘-sim’
       This option 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: C-SKY Options,  N
*** 22287,22326 ****
  
  GCC supports these options when compiling for C-SKY V2 processors.
  
! '-march=ARCH'
       Specify the C-SKY target architecture.  Valid values for ARCH are:
!      'ck801', 'ck802', 'ck803', 'ck807', and 'ck810'.  The default is
!      'ck810'.
  
! '-mcpu=CPU'
       Specify the C-SKY target processor.  Valid values for CPU are:
!      'ck801', 'ck801t', 'ck802', 'ck802t', 'ck802j', 'ck803', 'ck803h',
!      'ck803t', 'ck803ht', 'ck803f', 'ck803fh', 'ck803e', 'ck803eh',
!      'ck803et', 'ck803eht', 'ck803ef', 'ck803efh', 'ck803ft',
!      'ck803eft', 'ck803efht', 'ck803r1', 'ck803hr1', 'ck803tr1',
!      'ck803htr1', 'ck803fr1', 'ck803fhr1', 'ck803er1', 'ck803ehr1',
!      'ck803etr1', 'ck803ehtr1', 'ck803efr1', 'ck803efhr1', 'ck803ftr1',
!      'ck803eftr1', 'ck803efhtr1', 'ck803s', 'ck803st', 'ck803se',
!      'ck803sf', 'ck803sef', 'ck803seft', 'ck807e', 'ck807ef', 'ck807',
!      'ck807f', 'ck810e', 'ck810et', 'ck810ef', 'ck810eft', 'ck810',
!      'ck810v', 'ck810f', 'ck810t', 'ck810fv', 'ck810tv', 'ck810ft', and
!      'ck810ftv'.
  
! '-mbig-endian'
! '-EB'
! '-mlittle-endian'
! '-EL'
  
       Select big- or little-endian code.  The default is little-endian.
  
! '-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.
  
--- 22297,22336 ----
  
  GCC supports these options when compiling for C-SKY V2 processors.
  
! ‘-march=ARCH’
       Specify the C-SKY target architecture.  Valid values for ARCH are:
!      ‘ck801’, ‘ck802’, ‘ck803’, ‘ck807’, and ‘ck810’.  The default is
!      ‘ck810’.
  
! ‘-mcpu=CPU’
       Specify the C-SKY target processor.  Valid values for CPU are:
!      ‘ck801’, ‘ck801t’, ‘ck802’, ‘ck802t’, ‘ck802j’, ‘ck803’, ‘ck803h’,
!      ‘ck803t’, ‘ck803ht’, ‘ck803f’, ‘ck803fh’, ‘ck803e’, ‘ck803eh’,
!      ‘ck803et’, ‘ck803eht’, ‘ck803ef’, ‘ck803efh’, ‘ck803ft’,
!      ‘ck803eft’, ‘ck803efht’, ‘ck803r1’, ‘ck803hr1’, ‘ck803tr1’,
!      ‘ck803htr1’, ‘ck803fr1’, ‘ck803fhr1’, ‘ck803er1’, ‘ck803ehr1’,
!      ‘ck803etr1’, ‘ck803ehtr1’, ‘ck803efr1’, ‘ck803efhr1’, ‘ck803ftr1’,
!      ‘ck803eftr1’, ‘ck803efhtr1’, ‘ck803s’, ‘ck803st’, ‘ck803se’,
!      ‘ck803sf’, ‘ck803sef’, ‘ck803seft’, ‘ck807e’, ‘ck807ef’, ‘ck807’,
!      ‘ck807f’, ‘ck810e’, ‘ck810et’, ‘ck810ef’, ‘ck810eft’, ‘ck810’,
!      ‘ck810v’, ‘ck810f’, ‘ck810t’, ‘ck810fv’, ‘ck810tv’, ‘ck810ft’, and
!      ‘ck810ftv’.
  
! ‘-mbig-endian’
! ‘-EB’
! ‘-mlittle-endian’
! ‘-EL’
  
       Select big- or little-endian code.  The default is little-endian.
  
! ‘-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.
  
*************** GCC supports these options when compilin
*** 22329,22454 ****
       you must compile your entire program with the same ABI, and link
       with a compatible set of libraries.
  
! '-mhard-float'
! '-msoft-float'
  
       Select hardware or software floating-point implementations.  The
       default is soft float.
  
! '-mdouble-float'
! '-mno-double-float'
!      When '-mhard-float' is in effect, enable generation of
       double-precision float instructions.  This is the default except
       when compiling for CK803.
  
! '-mfdivdu'
! '-mno-fdivdu'
!      When '-mhard-float' is in effect, enable generation of 'frecipd',
!      'fsqrtd', and 'fdivd' instructions.  This is the default except
       when compiling for CK803.
  
! '-mfpu=FPU'
       Select the floating-point processor.  This option can only be used
!      with '-mhard-float'.  Values for FPU are 'fpv2_sf' (equivalent to
!      '-mno-double-float -mno-fdivdu'), 'fpv2' ('-mdouble-float
!      -mno-divdu'), and 'fpv2_divd' ('-mdouble-float -mdivdu').
  
! '-melrw'
! '-mno-elrw'
!      Enable the extended 'lrw' instruction.  This option defaults to on
       for CK801 and off otherwise.
  
! '-mistack'
! '-mno-istack'
       Enable interrupt stack instructions; the default is off.
  
!      The '-mistack' option is required to handle the 'interrupt' and
!      'isr' function attributes (*note C-SKY Function Attributes::).
  
! '-mmp'
       Enable multiprocessor instructions; the default is off.
  
! '-mcp'
       Enable coprocessor instructions; the default is off.
  
! '-mcache'
       Enable coprocessor instructions; the default is off.
  
! '-msecurity'
       Enable C-SKY security instructions; the default is off.
  
! '-mtrust'
       Enable C-SKY trust instructions; the default is off.
  
! '-mdsp'
! '-medsp'
! '-mvdsp'
       Enable C-SKY DSP, Enhanced DSP, or Vector DSP instructions,
       respectively.  All of these options default to off.
  
! '-mdiv'
! '-mno-div'
       Generate divide instructions.  Default is off.
  
! '-msmart'
! '-mno-smart'
       Generate code for Smart Mode, using only registers numbered 0-7 to
       allow use of 16-bit instructions.  This option is ignored for CK801
       where this is the required behavior, and it defaults to on for
       CK802.  For other targets, the default is off.
  
! '-mhigh-registers'
! '-mno-high-registers'
       Generate code using the high registers numbered 16-31.  This option
       is not supported on CK801, CK802, or CK803, and is enabled by
       default for other processors.
  
! '-manchor'
! '-mno-anchor'
       Generate code using global anchor symbol addresses.
  
! '-mpushpop'
! '-mno-pushpop'
!      Generate code using 'push' and 'pop' instructions.  This option
       defaults to on.
  
! '-mmultiple-stld'
! '-mstm'
! '-mno-multiple-stld'
! '-mno-stm'
!      Generate code using 'stm' and 'ldm' instructions.  This option
       isn't supported on CK801 but is enabled by default on other
       processors.
  
! '-mconstpool'
! '-mno-constpool'
       Create constant pools in the compiler instead of deferring it to
       the assembler.  This option is the default and required for correct
       code generation on CK801 and CK802, and is optional on other
       processors.
  
! '-mstack-size'
! '-mno-stack-size'
!      Emit '.stack_size' directives for each function in the assembly
       output.  This option defaults to off.
  
! '-mccrt'
! '-mno-ccrt'
       Generate code for the C-SKY compiler runtime instead of libgcc.
       This option defaults to off.
  
! '-mbranch-cost=N'
!      Set the branch costs to roughly 'n' instructions.  The default is
       1.
  
! '-msched-prolog'
! '-mno-sched-prolog'
       Permit scheduling of function prologue and epilogue sequences.
       Using this option can result in code that is not compliant with the
       C-SKY V2 ABI prologue requirements and that cannot be debugged or
       backtraced.  It is disabled by default.
  
! '-msim'
       Links the library libsemi.a which is in compatible with simulator.
       Applicable to ELF compiler only.
  
--- 22339,22464 ----
       you must compile your entire program with the same ABI, and link
       with a compatible set of libraries.
  
! ‘-mhard-float’
! ‘-msoft-float’
  
       Select hardware or software floating-point implementations.  The
       default is soft float.
  
! ‘-mdouble-float’
! ‘-mno-double-float’
!      When ‘-mhard-float’ is in effect, enable generation of
       double-precision float instructions.  This is the default except
       when compiling for CK803.
  
! ‘-mfdivdu’
! ‘-mno-fdivdu’
!      When ‘-mhard-float’ is in effect, enable generation of ‘frecipd’,
!      ‘fsqrtd’, and ‘fdivd’ instructions.  This is the default except
       when compiling for CK803.
  
! ‘-mfpu=FPU’
       Select the floating-point processor.  This option can only be used
!      with ‘-mhard-float’.  Values for FPU are ‘fpv2_sf’ (equivalent to
!      ‘-mno-double-float -mno-fdivdu’), ‘fpv2’ (‘-mdouble-float
!      -mno-divdu’), and ‘fpv2_divd’ (‘-mdouble-float -mdivdu’).
  
! ‘-melrw’
! ‘-mno-elrw’
!      Enable the extended ‘lrw’ instruction.  This option defaults to on
       for CK801 and off otherwise.
  
! ‘-mistack’
! ‘-mno-istack’
       Enable interrupt stack instructions; the default is off.
  
!      The ‘-mistack’ option is required to handle the ‘interrupt’ and
!      ‘isr’ function attributes (*note C-SKY Function Attributes::).
  
! ‘-mmp’
       Enable multiprocessor instructions; the default is off.
  
! ‘-mcp’
       Enable coprocessor instructions; the default is off.
  
! ‘-mcache’
       Enable coprocessor instructions; the default is off.
  
! ‘-msecurity’
       Enable C-SKY security instructions; the default is off.
  
! ‘-mtrust’
       Enable C-SKY trust instructions; the default is off.
  
! ‘-mdsp’
! ‘-medsp’
! ‘-mvdsp’
       Enable C-SKY DSP, Enhanced DSP, or Vector DSP instructions,
       respectively.  All of these options default to off.
  
! ‘-mdiv’
! ‘-mno-div’
       Generate divide instructions.  Default is off.
  
! ‘-msmart’
! ‘-mno-smart’
       Generate code for Smart Mode, using only registers numbered 0-7 to
       allow use of 16-bit instructions.  This option is ignored for CK801
       where this is the required behavior, and it defaults to on for
       CK802.  For other targets, the default is off.
  
! ‘-mhigh-registers’
! ‘-mno-high-registers’
       Generate code using the high registers numbered 16-31.  This option
       is not supported on CK801, CK802, or CK803, and is enabled by
       default for other processors.
  
! ‘-manchor’
! ‘-mno-anchor’
       Generate code using global anchor symbol addresses.
  
! ‘-mpushpop’
! ‘-mno-pushpop’
!      Generate code using ‘push’ and ‘pop’ instructions.  This option
       defaults to on.
  
! ‘-mmultiple-stld’
! ‘-mstm’
! ‘-mno-multiple-stld’
! ‘-mno-stm’
!      Generate code using ‘stm’ and ‘ldm’ instructions.  This option
       isn't supported on CK801 but is enabled by default on other
       processors.
  
! ‘-mconstpool’
! ‘-mno-constpool’
       Create constant pools in the compiler instead of deferring it to
       the assembler.  This option is the default and required for correct
       code generation on CK801 and CK802, and is optional on other
       processors.
  
! ‘-mstack-size’
! ‘-mno-stack-size’
!      Emit ‘.stack_size’ directives for each function in the assembly
       output.  This option defaults to off.
  
! ‘-mccrt’
! ‘-mno-ccrt’
       Generate code for the C-SKY compiler runtime instead of libgcc.
       This option defaults to off.
  
! ‘-mbranch-cost=N’
!      Set the branch costs to roughly ‘n’ instructions.  The default is
       1.
  
! ‘-msched-prolog’
! ‘-mno-sched-prolog’
       Permit scheduling of function prologue and epilogue sequences.
       Using this option can result in code that is not compliant with the
       C-SKY V2 ABI prologue requirements and that cannot be debugged or
       backtraced.  It is disabled by default.
  
! ‘-msim’
       Links the library libsemi.a which is in compatible with simulator.
       Applicable to ELF compiler only.
  
*************** operating system.
*** 22463,22501 ****
  
   FSF GCC on Darwin does not create "fat" object files; it creates an
  object file for the single architecture that GCC was built to target.
! Apple's GCC on Darwin does create "fat" files if multiple '-arch'
  options are used; it does so by running the compiler or linker multiple
! times and joining the results together with 'lipo'.
  
!  The subtype of the file created (like 'ppc7400' or 'ppc970' or 'i686')
  is determined by the flags that specify the ISA that GCC is targeting,
! like '-mcpu' or '-march'.  The '-force_cpusubtype_ALL' option can be
  used to override this.
  
   The Darwin tools vary in their behavior when presented with an ISA
! mismatch.  The assembler, 'as', only permits instructions to be used
  that are valid for the subtype of the file it is generating, so you
! cannot put 64-bit instructions in a 'ppc750' object file.  The linker
! for shared libraries, '/usr/bin/libtool', fails and prints an error if
  asked to create a shared library with a less restrictive subtype than
! its input files (for instance, trying to put a 'ppc970' object file in a
! 'ppc7400' library).  The linker for executables, 'ld', quietly gives the
  executable the most restrictive subtype of any of its input files.
  
! '-FDIR'
       Add the framework directory DIR to the head of the list of
       directories to be searched for header files.  These directories are
!      interleaved with those specified by '-I' options and are scanned in
       a left-to-right order.
  
       A framework directory is a directory with frameworks in it.  A
!      framework is a directory with a 'Headers' and/or 'PrivateHeaders'
!      directory contained directly in it that ends in '.framework'.  The
       name of a framework is the name of this directory excluding the
!      '.framework'.  Headers associated with the framework are found in
!      one of those two directories, with 'Headers' being searched first.
       A subframework is a framework directory that is in a framework's
!      'Frameworks' directory.  Includes of subframework headers can only
       appear in a header of a framework that contains the subframework,
       or in a sibling subframework header.  Two subframeworks are
       siblings if they occur in the same framework.  A subframework
--- 22473,22511 ----
  
   FSF GCC on Darwin does not create "fat" object files; it creates an
  object file for the single architecture that GCC was built to target.
! Apple's GCC on Darwin does create "fat" files if multiple ‘-arch’
  options are used; it does so by running the compiler or linker multiple
! times and joining the results together with ‘lipo’.
  
!  The subtype of the file created (like ‘ppc7400’ or ‘ppc970’ or ‘i686’)
  is determined by the flags that specify the ISA that GCC is targeting,
! like ‘-mcpu’ or ‘-march’.  The ‘-force_cpusubtype_ALL’ option can be
  used to override this.
  
   The Darwin tools vary in their behavior when presented with an ISA
! mismatch.  The assembler, ‘as’, only permits instructions to be used
  that are valid for the subtype of the file it is generating, so you
! cannot put 64-bit instructions in a ‘ppc750’ object file.  The linker
! for shared libraries, ‘/usr/bin/libtool’, fails and prints an error if
  asked to create a shared library with a less restrictive subtype than
! its input files (for instance, trying to put a ‘ppc970’ object file in a
! ‘ppc7400’ library).  The linker for executables, ‘ld’, quietly gives the
  executable the most restrictive subtype of any of its input files.
  
! ‘-FDIR’
       Add the framework directory DIR to the head of the list of
       directories to be searched for header files.  These directories are
!      interleaved with those specified by ‘-I’ options and are scanned in
       a left-to-right order.
  
       A framework directory is a directory with frameworks in it.  A
!      framework is a directory with a ‘Headers’ and/or ‘PrivateHeaders’
!      directory contained directly in it that ends in ‘.framework’.  The
       name of a framework is the name of this directory excluding the
!      ‘.framework’.  Headers associated with the framework are found in
!      one of those two directories, with ‘Headers’ being searched first.
       A subframework is a framework directory that is in a framework's
!      ‘Frameworks’ directory.  Includes of subframework headers can only
       appear in a header of a framework that contains the subframework,
       or in a sibling subframework header.  Two subframeworks are
       siblings if they occur in the same framework.  A subframework
*************** executable the most restrictive subtype
*** 22503,22661 ****
       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 ', 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.
  
! '-fconstant-cfstrings'
!      The '-fconstant-cfstrings' is an alias for '-mconstant-cfstrings'.
  
! '-mconstant-cfstrings'
       When the NeXT runtime is being used (the default on these systems),
!      override any '-fconstant-string-class' setting and cause '@"..."'
       literals to be laid out as constant CoreFoundation strings.
  
! '-mmacosx-version-min=VERSION'
       The earliest version of MacOS X that this executable will run on is
!      VERSION.  Typical values supported for VERSION include '12',
!      '10.12', and '10.5.8'.
  
       If the compiler was built to use the system's headers by default,
       then the default for this option is the system version on which the
       compiler is running, otherwise the default is to make choices that
       are compatible with as many systems and code bases as possible.
  
! '-mkernel'
!      Enable kernel development mode.  The '-mkernel' option sets
!      '-static', '-fno-common', '-fno-use-cxa-atexit', '-fno-exceptions',
!      '-fno-non-call-exceptions', '-fapple-kext', '-fno-weak' and
!      '-fno-rtti' where applicable.  This mode also sets '-mno-altivec',
!      '-msoft-float', '-fno-builtin' and '-mlong-branch' for PowerPC
       targets.
  
! '-mone-byte-bool'
!      Override the defaults for 'bool' so that 'sizeof(bool)==1'.  By
!      default 'sizeof(bool)' is '4' when compiling for Darwin/PowerPC and
!      '1' when compiling for Darwin/x86, so this option has no effect on
       x86.
  
!      *Warning:* The '-mone-byte-bool' switch causes GCC to generate code
       that is not binary compatible with code generated without that
       switch.  Using this switch may require recompiling all other
       modules in a program, including system libraries.  Use this switch
       to conform to a non-default data model.
  
! '-mfix-and-continue'
! '-ffix-and-continue'
! '-findirect-data'
       Generate code suitable for fast turnaround development, such as to
!      allow GDB to dynamically load '.o' files into already-running
!      programs.  '-findirect-data' and '-ffix-and-continue' are provided
       for backwards compatibility.
  
! '-all_load'
       Loads all members of static archive libraries.  See man ld(1) for
       more information.
  
! '-arch_errors_fatal'
       Cause the errors having to do with files that have the wrong
       architecture to be fatal.
  
! '-bind_at_load'
       Causes the output file to be marked such that the dynamic linker
       will bind all undefined references when the file is loaded or
       launched.
  
! '-bundle'
       Produce a Mach-o bundle format file.  See man ld(1) for more
       information.
  
! '-bundle_loader EXECUTABLE'
       This option specifies the EXECUTABLE that will load the build
       output file being linked.  See man ld(1) for more information.
  
! '-dynamiclib'
       When passed this option, GCC produces a dynamic library instead of
!      an executable when linking, using the Darwin 'libtool' command.
  
! '-force_cpusubtype_ALL'
!      This causes GCC's output file to have the 'ALL' subtype, instead of
!      one controlled by the '-mcpu' or '-march' option.
  
! '-allowable_client CLIENT_NAME'
! '-client_name'
! '-compatibility_version'
! '-current_version'
! '-dead_strip'
! '-dependency-file'
! '-dylib_file'
! '-dylinker_install_name'
! '-dynamic'
! '-exported_symbols_list'
! '-filelist'
! '-flat_namespace'
! '-force_flat_namespace'
! '-headerpad_max_install_names'
! '-image_base'
! '-init'
! '-install_name'
! '-keep_private_externs'
! '-multi_module'
! '-multiply_defined'
! '-multiply_defined_unused'
! '-noall_load'
! '-no_dead_strip_inits_and_terms'
! '-nofixprebinding'
! '-nomultidefs'
! '-noprebind'
! '-noseglinkedit'
! '-pagezero_size'
! '-prebind'
! '-prebind_all_twolevel_modules'
! '-private_bundle'
! '-read_only_relocs'
! '-sectalign'
! '-sectobjectsymbols'
! '-whyload'
! '-seg1addr'
! '-sectcreate'
! '-sectobjectsymbols'
! '-sectorder'
! '-segaddr'
! '-segs_read_only_addr'
! '-segs_read_write_addr'
! '-seg_addr_table'
! '-seg_addr_table_filename'
! '-seglinkedit'
! '-segprot'
! '-segs_read_only_addr'
! '-segs_read_write_addr'
! '-single_module'
! '-static'
! '-sub_library'
! '-sub_umbrella'
! '-twolevel_namespace'
! '-umbrella'
! '-undefined'
! '-unexported_symbols_list'
! '-weak_reference_mismatches'
! '-whatsloaded'
       These options are passed to the Darwin linker.  The Darwin linker
       man page describes them in detail.
  
--- 22513,22671 ----
       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 ’, 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.
  
! ‘-fconstant-cfstrings’
!      The ‘-fconstant-cfstrings’ is an alias for ‘-mconstant-cfstrings’.
  
! ‘-mconstant-cfstrings’
       When the NeXT runtime is being used (the default on these systems),
!      override any ‘-fconstant-string-class’ setting and cause ‘@"..."’
       literals to be laid out as constant CoreFoundation strings.
  
! ‘-mmacosx-version-min=VERSION’
       The earliest version of MacOS X that this executable will run on is
!      VERSION.  Typical values supported for VERSION include ‘12’,
!      ‘10.12’, and ‘10.5.8’.
  
       If the compiler was built to use the system's headers by default,
       then the default for this option is the system version on which the
       compiler is running, otherwise the default is to make choices that
       are compatible with as many systems and code bases as possible.
  
! ‘-mkernel’
!      Enable kernel development mode.  The ‘-mkernel’ option sets
!      ‘-static’, ‘-fno-common’, ‘-fno-use-cxa-atexit’, ‘-fno-exceptions’,
!      ‘-fno-non-call-exceptions’, ‘-fapple-kext’, ‘-fno-weak’ and
!      ‘-fno-rtti’ where applicable.  This mode also sets ‘-mno-altivec’,
!      ‘-msoft-float’, ‘-fno-builtin’ and ‘-mlong-branch’ for PowerPC
       targets.
  
! ‘-mone-byte-bool’
!      Override the defaults for ‘bool’ so that ‘sizeof(bool)==1’.  By
!      default ‘sizeof(bool)’ is ‘4’ when compiling for Darwin/PowerPC and
!      ‘1’ when compiling for Darwin/x86, so this option has no effect on
       x86.
  
!      *Warning:* The ‘-mone-byte-bool’ switch causes GCC to generate code
       that is not binary compatible with code generated without that
       switch.  Using this switch may require recompiling all other
       modules in a program, including system libraries.  Use this switch
       to conform to a non-default data model.
  
! ‘-mfix-and-continue’
! ‘-ffix-and-continue’
! ‘-findirect-data’
       Generate code suitable for fast turnaround development, such as to
!      allow GDB to dynamically load ‘.o’ files into already-running
!      programs.  ‘-findirect-data’ and ‘-ffix-and-continue’ are provided
       for backwards compatibility.
  
! ‘-all_load’
       Loads all members of static archive libraries.  See man ld(1) for
       more information.
  
! ‘-arch_errors_fatal’
       Cause the errors having to do with files that have the wrong
       architecture to be fatal.
  
! ‘-bind_at_load’
       Causes the output file to be marked such that the dynamic linker
       will bind all undefined references when the file is loaded or
       launched.
  
! ‘-bundle’
       Produce a Mach-o bundle format file.  See man ld(1) for more
       information.
  
! ‘-bundle_loader EXECUTABLE’
       This option specifies the EXECUTABLE that will load the build
       output file being linked.  See man ld(1) for more information.
  
! ‘-dynamiclib’
       When passed this option, GCC produces a dynamic library instead of
!      an executable when linking, using the Darwin ‘libtool’ command.
  
! ‘-force_cpusubtype_ALL’
!      This causes GCC's output file to have the ‘ALL’ subtype, instead of
!      one controlled by the ‘-mcpu’ or ‘-march’ option.
  
! ‘-allowable_client CLIENT_NAME’
! ‘-client_name’
! ‘-compatibility_version’
! ‘-current_version’
! ‘-dead_strip’
! ‘-dependency-file’
! ‘-dylib_file’
! ‘-dylinker_install_name’
! ‘-dynamic’
! ‘-exported_symbols_list’
! ‘-filelist’
! ‘-flat_namespace’
! ‘-force_flat_namespace’
! ‘-headerpad_max_install_names’
! ‘-image_base’
! ‘-init’
! ‘-install_name’
! ‘-keep_private_externs’
! ‘-multi_module’
! ‘-multiply_defined’
! ‘-multiply_defined_unused’
! ‘-noall_load’
! ‘-no_dead_strip_inits_and_terms’
! ‘-nofixprebinding’
! ‘-nomultidefs’
! ‘-noprebind’
! ‘-noseglinkedit’
! ‘-pagezero_size’
! ‘-prebind’
! ‘-prebind_all_twolevel_modules’
! ‘-private_bundle’
! ‘-read_only_relocs’
! ‘-sectalign’
! ‘-sectobjectsymbols’
! ‘-whyload’
! ‘-seg1addr’
! ‘-sectcreate’
! ‘-sectobjectsymbols’
! ‘-sectorder’
! ‘-segaddr’
! ‘-segs_read_only_addr’
! ‘-segs_read_write_addr’
! ‘-seg_addr_table’
! ‘-seg_addr_table_filename’
! ‘-seglinkedit’
! ‘-segprot’
! ‘-segs_read_only_addr’
! ‘-segs_read_write_addr’
! ‘-single_module’
! ‘-static’
! ‘-sub_library’
! ‘-sub_umbrella’
! ‘-twolevel_namespace’
! ‘-umbrella’
! ‘-undefined’
! ‘-unexported_symbols_list’
! ‘-weak_reference_mismatches’
! ‘-whatsloaded’
       These options are passed to the Darwin linker.  The Darwin linker
       man page describes them in detail.
  
*************** File: gcc.info,  Node: DEC Alpha Options
*** 22665,22677 ****
  3.19.12 DEC Alpha Options
  -------------------------
  
! These '-m' options are defined for the DEC Alpha implementations:
  
! '-mno-soft-float'
! '-msoft-float'
       Use (do not use) the hardware floating-point instructions for
!      floating-point operations.  When '-msoft-float' is specified,
!      functions in 'libgcc.a' are used to perform floating-point
       operations.  Unless they are replaced by routines that emulate the
       floating-point operations, or compiled in such a way as to call
       such emulations routines, these routines issue floating-point
--- 22675,22687 ----
  3.19.12 DEC Alpha Options
  -------------------------
  
! These ‘-m’ options are defined for the DEC Alpha implementations:
  
! ‘-mno-soft-float’
! ‘-msoft-float’
       Use (do not use) the hardware floating-point instructions for
!      floating-point operations.  When ‘-msoft-float’ is specified,
!      functions in ‘libgcc.a’ are used to perform floating-point
       operations.  Unless they are replaced by routines that emulate the
       floating-point operations, or compiled in such a way as to call
       such emulations routines, these routines issue floating-point
*************** These '-m' options are defined for the D
*** 22682,22773 ****
       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
--- 22692,22783 ----
       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
*************** These '-m' options are defined for the D
*** 22776,22805 ****
       floating-point trap.  Depending on the requirements of an
       application, different levels of precisions can be selected:
  
!      'p'
            Program precision.  This option is the default and means a
            trap handler can only identify which program caused a
            floating-point exception.
  
!      'f'
            Function precision.  The trap handler can determine the
            function that caused a floating-point exception.
  
!      'i'
            Instruction precision.  The trap handler can determine the
            exact instruction that caused a floating-point exception.
  
       Other Alpha compilers provide the equivalent options called
!      '-scope_safe' and '-resumption_safe'.
  
! '-mieee-conformant'
       This option marks the generated code as IEEE conformant.  You must
!      not use this option unless you also specify '-mtrap-precision=i'
!      and either '-mfp-trap-mode=su' or '-mfp-trap-mode=sui'.  Its only
!      effect is to emit the line '.eflag 48' in the function prologue of
       the generated assembly file.
  
! '-mbuild-constants'
       Normally GCC examines a 32- or 64-bit integer constant to see if it
       can construct it from smaller constants in two or three
       instructions.  If it cannot, it outputs the constant as a literal
--- 22786,22815 ----
       floating-point trap.  Depending on the requirements of an
       application, different levels of precisions can be selected:
  
!      ‘p’
            Program precision.  This option is the default and means a
            trap handler can only identify which program caused a
            floating-point exception.
  
!      ‘f’
            Function precision.  The trap handler can determine the
            function that caused a floating-point exception.
  
!      ‘i’
            Instruction precision.  The trap handler can determine the
            exact instruction that caused a floating-point exception.
  
       Other Alpha compilers provide the equivalent options called
!      ‘-scope_safe’ and ‘-resumption_safe’.
  
! ‘-mieee-conformant’
       This option marks the generated code as IEEE conformant.  You must
!      not use this option unless you also specify ‘-mtrap-precision=i’
!      and either ‘-mfp-trap-mode=su’ or ‘-mfp-trap-mode=sui’.  Its only
!      effect is to emit the line ‘.eflag 48’ in the function prologue of
       the generated assembly file.
  
! ‘-mbuild-constants’
       Normally GCC examines a 32- or 64-bit integer constant to see if it
       can construct it from smaller constants in two or three
       instructions.  If it cannot, it outputs the constant as a literal
*************** These '-m' options are defined for the D
*** 22814,22840 ****
       before it can find the variables and constants in its own data
       segment.
  
! '-mbwx'
! '-mno-bwx'
! '-mcix'
! '-mno-cix'
! '-mfix'
! '-mno-fix'
! '-mmax'
! '-mno-max'
       Indicate whether GCC should generate code to use the optional BWX,
       CIX, FIX and MAX instruction sets.  The default is to use the
!      instruction sets supported by the CPU type specified via '-mcpu='
       option or that of the CPU on which GCC was built if none is
       specified.
  
! '-mfloat-vax'
! '-mfloat-ieee'
       Generate code that uses (does not use) VAX F and G floating-point
       arithmetic instead of IEEE single and double precision.
  
! '-mexplicit-relocs'
! '-mno-explicit-relocs'
       Older Alpha assemblers provided no way to generate symbol
       relocations except via assembler macros.  Use of these macros does
       not allow optimal instruction scheduling.  GNU binutils as of
--- 22824,22850 ----
       before it can find the variables and constants in its own data
       segment.
  
! ‘-mbwx’
! ‘-mno-bwx’
! ‘-mcix’
! ‘-mno-cix’
! ‘-mfix’
! ‘-mno-fix’
! ‘-mmax’
! ‘-mno-max’
       Indicate whether GCC should generate code to use the optional BWX,
       CIX, FIX and MAX instruction sets.  The default is to use the
!      instruction sets supported by the CPU type specified via ‘-mcpu=’
       option or that of the CPU on which GCC was built if none is
       specified.
  
! ‘-mfloat-vax’
! ‘-mfloat-ieee’
       Generate code that uses (does not use) VAX F and G floating-point
       arithmetic instead of IEEE single and double precision.
  
! ‘-mexplicit-relocs’
! ‘-mno-explicit-relocs’
       Older Alpha assemblers provided no way to generate symbol
       relocations except via assembler macros.  Use of these macros does
       not allow optimal instruction scheduling.  GNU binutils as of
*************** These '-m' options are defined for the D
*** 22844,22881 ****
       detects the capabilities of the assembler when it is built and sets
       the default accordingly.
  
! '-msmall-data'
! '-mlarge-data'
!      When '-mexplicit-relocs' is in effect, static data is accessed via
!      "gp-relative" relocations.  When '-msmall-data' is used, objects 8
!      bytes long or smaller are placed in a "small data area" (the
!      '.sdata' and '.sbss' sections) and are accessed via 16-bit
!      relocations off of the '$gp' register.  This limits the size of the
       small data area to 64KB, but allows the variables to be directly
       accessed via a single instruction.
  
!      The default is '-mlarge-data'.  With this option the data area is
       limited to just below 2GB.  Programs that require more than 2GB of
!      data must use 'malloc' or 'mmap' to allocate the data in the heap
       instead of in the program's data segment.
  
!      When generating code for shared libraries, '-fpic' implies
!      '-msmall-data' and '-fPIC' implies '-mlarge-data'.
  
! '-msmall-text'
! '-mlarge-text'
!      When '-msmall-text' is used, the compiler assumes that the code of
       the entire program (or shared library) fits in 4MB, and is thus
!      reachable with a branch instruction.  When '-msmall-data' is used,
!      the compiler can assume that all local symbols share the same '$gp'
       value, and thus reduce the number of instructions required for a
       function call from 4 to 1.
  
!      The default is '-mlarge-text'.
  
! '-mcpu=CPU_TYPE'
       Set the instruction set and instruction scheduling parameters for
!      machine type CPU_TYPE.  You can specify either the 'EV' style name
       or the corresponding chip number.  GCC supports scheduling
       parameters for the EV4, EV5 and EV6 family of processors and
       chooses the default values for the instruction set from the
--- 22854,22891 ----
       detects the capabilities of the assembler when it is built and sets
       the default accordingly.
  
! ‘-msmall-data’
! ‘-mlarge-data’
!      When ‘-mexplicit-relocs’ is in effect, static data is accessed via
!      “gp-relative” relocations.  When ‘-msmall-data’ is used, objects 8
!      bytes long or smaller are placed in a “small data area” (the
!      ‘.sdata’ and ‘.sbss’ sections) and are accessed via 16-bit
!      relocations off of the ‘$gp’ register.  This limits the size of the
       small data area to 64KB, but allows the variables to be directly
       accessed via a single instruction.
  
!      The default is ‘-mlarge-data’.  With this option the data area is
       limited to just below 2GB.  Programs that require more than 2GB of
!      data must use ‘malloc’ or ‘mmap’ to allocate the data in the heap
       instead of in the program's data segment.
  
!      When generating code for shared libraries, ‘-fpic’ implies
!      ‘-msmall-data’ and ‘-fPIC’ implies ‘-mlarge-data’.
  
! ‘-msmall-text’
! ‘-mlarge-text’
!      When ‘-msmall-text’ is used, the compiler assumes that the code of
       the entire program (or shared library) fits in 4MB, and is thus
!      reachable with a branch instruction.  When ‘-msmall-data’ is used,
!      the compiler can assume that all local symbols share the same ‘$gp’
       value, and thus reduce the number of instructions required for a
       function call from 4 to 1.
  
!      The default is ‘-mlarge-text’.
  
! ‘-mcpu=CPU_TYPE’
       Set the instruction set and instruction scheduling parameters for
!      machine type CPU_TYPE.  You can specify either the ‘EV’ style name
       or the corresponding chip number.  GCC supports scheduling
       parameters for the EV4, EV5 and EV6 family of processors and
       chooses the default values for the instruction set from the
*************** These '-m' options are defined for the D
*** 22884,22932 ****
  
       Supported values for CPU_TYPE are
  
!      'ev4'
!      'ev45'
!      '21064'
            Schedules as an EV4 and has no instruction set extensions.
  
!      'ev5'
!      '21164'
            Schedules as an EV5 and has no instruction set extensions.
  
!      'ev56'
!      '21164a'
            Schedules as an EV5 and supports the BWX extension.
  
!      'pca56'
!      '21164pc'
!      '21164PC'
            Schedules as an EV5 and supports the BWX and MAX extensions.
  
!      'ev6'
!      '21264'
            Schedules as an EV6 and supports the BWX, FIX, and MAX
            extensions.
  
!      'ev67'
!      '21264a'
            Schedules as an EV6 and supports the BWX, CIX, FIX, and MAX
            extensions.
  
!      Native toolchains also support the value 'native', which selects
       the best architecture option for the host processor.
!      '-mcpu=native' has no effect if GCC does not recognize the
       processor.
  
! '-mtune=CPU_TYPE'
       Set only the instruction scheduling parameters for machine type
       CPU_TYPE.  The instruction set is not changed.
  
!      Native toolchains also support the value 'native', which selects
       the best architecture option for the host processor.
!      '-mtune=native' has no effect if GCC does not recognize the
       processor.
  
! '-mmemory-latency=TIME'
       Sets the latency the scheduler should assume for typical memory
       references as seen by the application.  This number is highly
       dependent on the memory access patterns used by the application and
--- 22894,22942 ----
  
       Supported values for CPU_TYPE are
  
!      ‘ev4’
!      ‘ev45’
!      ‘21064’
            Schedules as an EV4 and has no instruction set extensions.
  
!      ‘ev5’
!      ‘21164’
            Schedules as an EV5 and has no instruction set extensions.
  
!      ‘ev56’
!      ‘21164a’
            Schedules as an EV5 and supports the BWX extension.
  
!      ‘pca56’
!      ‘21164pc’
!      ‘21164PC’
            Schedules as an EV5 and supports the BWX and MAX extensions.
  
!      ‘ev6’
!      ‘21264’
            Schedules as an EV6 and supports the BWX, FIX, and MAX
            extensions.
  
!      ‘ev67’
!      ‘21264a’
            Schedules as an EV6 and supports the BWX, CIX, FIX, and MAX
            extensions.
  
!      Native toolchains also support the value ‘native’, which selects
       the best architecture option for the host processor.
!      ‘-mcpu=native’ has no effect if GCC does not recognize the
       processor.
  
! ‘-mtune=CPU_TYPE’
       Set only the instruction scheduling parameters for machine type
       CPU_TYPE.  The instruction set is not changed.
  
!      Native toolchains also support the value ‘native’, which selects
       the best architecture option for the host processor.
!      ‘-mtune=native’ has no effect if GCC does not recognize the
       processor.
  
! ‘-mmemory-latency=TIME’
       Sets the latency the scheduler should assume for typical memory
       references as seen by the application.  This number is highly
       dependent on the memory access patterns used by the application and
*************** These '-m' options are defined for the D
*** 22934,22946 ****
  
       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
--- 22944,22956 ----
  
       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
*************** File: gcc.info,  Node: eBPF Options,  Ne
*** 22952,23019 ****
  3.19.13 eBPF Options
  --------------------
  
! '-mframe-limit=BYTES'
       This specifies the hard limit for frame sizes, in bytes.
       Currently, the value that can be specified should be less than or
!      equal to '32767'.  Defaults to whatever limit is imposed by the
       version of the Linux kernel targeted.
  
! '-mkernel=VERSION'
       This specifies the minimum version of the kernel that will run the
       compiled program.  GCC uses this version to determine which
       instructions to use, what kernel helpers to allow, etc.  Currently,
!      VERSION can be one of '4.0', '4.1', '4.2', '4.3', '4.4', '4.5',
!      '4.6', '4.7', '4.8', '4.9', '4.10', '4.11', '4.12', '4.13', '4.14',
!      '4.15', '4.16', '4.17', '4.18', '4.19', '4.20', '5.0', '5.1',
!      '5.2', 'latest' and 'native'.
  
! '-mbig-endian'
       Generate code for a big-endian target.
  
! '-mlittle-endian'
       Generate code for a little-endian target.  This is the default.
  
! '-mjmpext'
       Enable generation of extra conditional-branch instructions.
       Enabled for CPU v2 and above.
  
! '-mjmp32'
       Enable 32-bit jump instructions.  Enabled for CPU v3 and above.
  
! '-malu32'
       Enable 32-bit ALU instructions.  Enabled for CPU v3 and above.
  
! '-mcpu=VERSION'
       This specifies which version of the eBPF ISA to target.  Newer
!      versions may not be supported by all kernels.  The default is 'v3'.
  
       Supported values for VERSION are:
  
!      'v1'
            The first stable eBPF ISA with no special features or
            extensions.
  
!      'v2'
!           Supports the jump extensions, as in '-mjmpext'.
  
!      'v3'
            All features of v2, plus:
!              - 32-bit jump operations, as in '-mjmp32'
!              - 32-bit ALU operations, as in '-malu32'
  
! '-mco-re'
       Enable BPF Compile Once - Run Everywhere (CO-RE) support.  Requires
!      and is implied by '-gbtf'.
  
! '-mno-co-re'
       Disable BPF Compile Once - Run Everywhere (CO-RE) support.  BPF
       CO-RE support is enabled by default when generating BTF debug
       information for the BPF target.
  
! '-mxbpf'
       Generate code for an expanded version of BPF, which relaxes some of
       the restrictions imposed by the BPF architecture:
!         - Save and restore callee-saved registers at function entry and
            exit, respectively.
  
  
--- 22962,23029 ----
  3.19.13 eBPF Options
  --------------------
  
! ‘-mframe-limit=BYTES’
       This specifies the hard limit for frame sizes, in bytes.
       Currently, the value that can be specified should be less than or
!      equal to ‘32767’.  Defaults to whatever limit is imposed by the
       version of the Linux kernel targeted.
  
! ‘-mkernel=VERSION’
       This specifies the minimum version of the kernel that will run the
       compiled program.  GCC uses this version to determine which
       instructions to use, what kernel helpers to allow, etc.  Currently,
!      VERSION can be one of ‘4.0’, ‘4.1’, ‘4.2’, ‘4.3’, ‘4.4’, ‘4.5’,
!      ‘4.6’, ‘4.7’, ‘4.8’, ‘4.9’, ‘4.10’, ‘4.11’, ‘4.12’, ‘4.13’, ‘4.14’,
!      ‘4.15’, ‘4.16’, ‘4.17’, ‘4.18’, ‘4.19’, ‘4.20’, ‘5.0’, ‘5.1’,
!      ‘5.2’, ‘latest’ and ‘native’.
  
! ‘-mbig-endian’
       Generate code for a big-endian target.
  
! ‘-mlittle-endian’
       Generate code for a little-endian target.  This is the default.
  
! ‘-mjmpext’
       Enable generation of extra conditional-branch instructions.
       Enabled for CPU v2 and above.
  
! ‘-mjmp32’
       Enable 32-bit jump instructions.  Enabled for CPU v3 and above.
  
! ‘-malu32’
       Enable 32-bit ALU instructions.  Enabled for CPU v3 and above.
  
! ‘-mcpu=VERSION’
       This specifies which version of the eBPF ISA to target.  Newer
!      versions may not be supported by all kernels.  The default is ‘v3’.
  
       Supported values for VERSION are:
  
!      ‘v1’
            The first stable eBPF ISA with no special features or
            extensions.
  
!      ‘v2’
!           Supports the jump extensions, as in ‘-mjmpext’.
  
!      ‘v3’
            All features of v2, plus:
!              − 32-bit jump operations, as in ‘-mjmp32’
!              − 32-bit ALU operations, as in ‘-malu32’
  
! ‘-mco-re’
       Enable BPF Compile Once - Run Everywhere (CO-RE) support.  Requires
!      and is implied by ‘-gbtf’.
  
! ‘-mno-co-re’
       Disable BPF Compile Once - Run Everywhere (CO-RE) support.  BPF
       CO-RE support is enabled by default when generating BTF debug
       information for the BPF target.
  
! ‘-mxbpf’
       Generate code for an expanded version of BPF, which relaxes some of
       the restrictions imposed by the BPF architecture:
!         − Save and restore callee-saved registers at function entry and
            exit, respectively.
  
  
*************** File: gcc.info,  Node: FR30 Options,  Ne
*** 23024,23037 ****
  
  These options are defined specifically for the FR30 port.
  
! '-msmall-model'
       Use the small address space model.  This can produce smaller code,
       but it does assume that all symbolic values and addresses fit into
       a 20-bit range.
  
! '-mno-lsim'
       Assume that runtime support has been provided and so there is no
!      need to include the simulator library ('libsim.a') on the linker
       command line.
  
  
--- 23034,23047 ----
  
  These options are defined specifically for the FR30 port.
  
! ‘-msmall-model’
       Use the small address space model.  This can produce smaller code,
       but it does assume that all symbolic values and addresses fit into
       a 20-bit range.
  
! ‘-mno-lsim’
       Assume that runtime support has been provided and so there is no
!      need to include the simulator library (‘libsim.a’) on the linker
       command line.
  
  
*************** File: gcc.info,  Node: FT32 Options,  Ne
*** 23042,23068 ****
  
  These options are defined specifically for the FT32 port.
  
! '-msim'
       Specifies that the program will be run on the simulator.  This
       causes an alternate runtime startup and library to be linked.  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.
  
! '-mlra'
       Enable Local Register Allocation.  This is still experimental for
       FT32, so by default the compiler uses standard reload.
  
! '-mnodiv'
       Do not use div and mod instructions.
  
! '-mft32b'
       Enable use of the extended instructions of the FT32B processor.
  
! '-mcompress'
       Compress all code using the Ft32B code compression scheme.
  
! '-mnopm'
       Do not generate code that reads program memory.
  
  
--- 23052,23078 ----
  
  These options are defined specifically for the FT32 port.
  
! ‘-msim’
       Specifies that the program will be run on the simulator.  This
       causes an alternate runtime startup and library to be linked.  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.
  
! ‘-mlra’
       Enable Local Register Allocation.  This is still experimental for
       FT32, so by default the compiler uses standard reload.
  
! ‘-mnodiv’
       Do not use div and mod instructions.
  
! ‘-mft32b’
       Enable use of the extended instructions of the FT32B processor.
  
! ‘-mcompress’
       Compress all code using the Ft32B code compression scheme.
  
! ‘-mnopm’
       Do not generate code that reads program memory.
  
  
*************** File: gcc.info,  Node: FRV Options,  Nex
*** 23071,23332 ****
  3.19.16 FRV Options
  -------------------
  
! '-mgpr-32'
  
       Only use the first 32 general-purpose registers.
  
! '-mgpr-64'
  
       Use all 64 general-purpose registers.
  
! '-mfpr-32'
  
       Use only the first 32 floating-point registers.
  
! '-mfpr-64'
  
       Use all 64 floating-point registers.
  
! '-mhard-float'
  
       Use hardware instructions for floating-point operations.
  
! '-msoft-float'
  
       Use library routines for floating-point operations.
  
! '-malloc-cc'
  
       Dynamically allocate condition code registers.
  
! '-mfixed-cc'
  
       Do not try to dynamically allocate condition code registers, only
!      use 'icc0' and 'fcc0'.
  
! '-mdword'
  
       Change ABI to use double word insns.
  
! '-mno-dword'
  
       Do not use double word instructions.
  
! '-mdouble'
  
       Use floating-point double instructions.
  
! '-mno-double'
  
       Do not use floating-point double instructions.
  
! '-mmedia'
  
       Use media instructions.
  
! '-mno-media'
  
       Do not use media instructions.
  
! '-mmuladd'
  
       Use multiply and add/subtract instructions.
  
! '-mno-muladd'
  
       Do not use multiply and add/subtract instructions.
  
! '-mfdpic'
  
       Select the FDPIC ABI, which uses function descriptors to represent
       pointers to functions.  Without any PIC/PIE-related options, it
!      implies '-fPIE'.  With '-fpic' or '-fpie', it assumes GOT entries
       and small data are within a 12-bit range from the GOT base address;
!      with '-fPIC' or '-fPIE', GOT offsets are computed with 32 bits.
!      With a 'bfin-elf' target, this option implies '-msim'.
  
! '-minline-plt'
  
       Enable inlining of PLT entries in function calls to functions that
!      are not known to bind locally.  It has no effect without '-mfdpic'.
       It's enabled by default if optimizing for speed and compiling for
!      shared libraries (i.e., '-fPIC' or '-fpic'), or when an
!      optimization option such as '-O3' or above is present in the
       command line.
  
! '-mTLS'
  
       Assume a large TLS segment when generating thread-local code.
  
! '-mtls'
  
       Do not assume a large TLS segment when generating thread-local
       code.
  
! '-mgprel-ro'
  
!      Enable the use of 'GPREL' relocations in the FDPIC ABI for data
       that is known to be in read-only sections.  It's enabled by
!      default, except for '-fpic' or '-fpie': even though it may help
       make the global offset table smaller, it trades 1 instruction for
!      4.  With '-fPIC' or '-fPIE', it trades 3 instructions for 4, one of
       which may be shared by multiple symbols, and it avoids the need for
       a GOT entry for the referenced symbol, so it's more likely to be a
!      win.  If it is not, '-mno-gprel-ro' can be used to disable it.
  
! '-multilib-library-pic'
  
       Link with the (library, not FD) pic libraries.  It's implied by
!      '-mlibrary-pic', as well as by '-fPIC' and '-fpic' without
!      '-mfdpic'.  You should never have to use it explicitly.
  
! '-mlinked-fp'
  
       Follow the EABI requirement of always creating a frame pointer
       whenever a stack frame is allocated.  This option is enabled by
!      default and can be disabled with '-mno-linked-fp'.
  
! '-mlong-calls'
  
       Use indirect addressing to call functions outside the current
       compilation unit.  This allows the functions to be placed anywhere
       within the 32-bit address space.
  
! '-malign-labels'
  
       Try to align labels to an 8-byte boundary by inserting NOPs into
       the previous packet.  This option only has an effect when VLIW
       packing is enabled.  It doesn't create new packets; it merely adds
       NOPs to existing ones.
  
! '-mlibrary-pic'
  
       Generate position-independent EABI code.
  
! '-macc-4'
  
       Use only the first four media accumulator registers.
  
! '-macc-8'
  
       Use all eight media accumulator registers.
  
! '-mpack'
  
       Pack VLIW instructions.
  
! '-mno-pack'
  
       Do not pack VLIW instructions.
  
! '-mno-eflags'
  
       Do not mark ABI switches in e_flags.
  
! '-mcond-move'
  
       Enable the use of conditional-move instructions (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mno-cond-move'
  
       Disable the use of conditional-move instructions.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mscc'
  
       Enable the use of conditional set instructions (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mno-scc'
  
       Disable the use of conditional set instructions.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mcond-exec'
  
       Enable the use of conditional execution (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mno-cond-exec'
  
       Disable the use of conditional execution.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mvliw-branch'
  
       Run a pass to pack branches into VLIW instructions (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mno-vliw-branch'
  
       Do not run a pass to pack branches into VLIW instructions.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mmulti-cond-exec'
  
!      Enable optimization of '&&' and '||' in conditional execution
       (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mno-multi-cond-exec'
  
!      Disable optimization of '&&' and '||' in conditional execution.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mnested-cond-exec'
  
       Enable nested conditional execution optimizations (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-mno-nested-cond-exec'
  
       Disable nested conditional execution optimizations.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! '-moptimize-membar'
  
!      This switch removes redundant 'membar' instructions from the
       compiler-generated code.  It is enabled by default.
  
! '-mno-optimize-membar'
  
!      This switch disables the automatic removal of redundant 'membar'
       instructions from the generated code.
  
! '-mtomcat-stats'
  
       Cause gas to print out tomcat statistics.
  
! '-mcpu=CPU'
  
       Select the processor type for which to generate code.  Possible
!      values are 'frv', 'fr550', 'tomcat', 'fr500', 'fr450', 'fr405',
!      'fr400', 'fr300' and 'simple'.
  
  
  File: gcc.info,  Node: GNU/Linux Options,  Next: H8/300 Options,  Prev: FRV Options,  Up: Submodel Options
--- 23081,23342 ----
  3.19.16 FRV Options
  -------------------
  
! ‘-mgpr-32’
  
       Only use the first 32 general-purpose registers.
  
! ‘-mgpr-64’
  
       Use all 64 general-purpose registers.
  
! ‘-mfpr-32’
  
       Use only the first 32 floating-point registers.
  
! ‘-mfpr-64’
  
       Use all 64 floating-point registers.
  
! ‘-mhard-float’
  
       Use hardware instructions for floating-point operations.
  
! ‘-msoft-float’
  
       Use library routines for floating-point operations.
  
! ‘-malloc-cc’
  
       Dynamically allocate condition code registers.
  
! ‘-mfixed-cc’
  
       Do not try to dynamically allocate condition code registers, only
!      use ‘icc0’ and ‘fcc0’.
  
! ‘-mdword’
  
       Change ABI to use double word insns.
  
! ‘-mno-dword’
  
       Do not use double word instructions.
  
! ‘-mdouble’
  
       Use floating-point double instructions.
  
! ‘-mno-double’
  
       Do not use floating-point double instructions.
  
! ‘-mmedia’
  
       Use media instructions.
  
! ‘-mno-media’
  
       Do not use media instructions.
  
! ‘-mmuladd’
  
       Use multiply and add/subtract instructions.
  
! ‘-mno-muladd’
  
       Do not use multiply and add/subtract instructions.
  
! ‘-mfdpic’
  
       Select the FDPIC ABI, which uses function descriptors to represent
       pointers to functions.  Without any PIC/PIE-related options, it
!      implies ‘-fPIE’.  With ‘-fpic’ or ‘-fpie’, it assumes GOT entries
       and small data are within a 12-bit range from the GOT base address;
!      with ‘-fPIC’ or ‘-fPIE’, GOT offsets are computed with 32 bits.
!      With a ‘bfin-elf’ target, this option implies ‘-msim’.
  
! ‘-minline-plt’
  
       Enable inlining of PLT entries in function calls to functions that
!      are not known to bind locally.  It has no effect without ‘-mfdpic’.
       It's enabled by default if optimizing for speed and compiling for
!      shared libraries (i.e., ‘-fPIC’ or ‘-fpic’), or when an
!      optimization option such as ‘-O3’ or above is present in the
       command line.
  
! ‘-mTLS’
  
       Assume a large TLS segment when generating thread-local code.
  
! ‘-mtls’
  
       Do not assume a large TLS segment when generating thread-local
       code.
  
! ‘-mgprel-ro’
  
!      Enable the use of ‘GPREL’ relocations in the FDPIC ABI for data
       that is known to be in read-only sections.  It's enabled by
!      default, except for ‘-fpic’ or ‘-fpie’: even though it may help
       make the global offset table smaller, it trades 1 instruction for
!      4.  With ‘-fPIC’ or ‘-fPIE’, it trades 3 instructions for 4, one of
       which may be shared by multiple symbols, and it avoids the need for
       a GOT entry for the referenced symbol, so it's more likely to be a
!      win.  If it is not, ‘-mno-gprel-ro’ can be used to disable it.
  
! ‘-multilib-library-pic’
  
       Link with the (library, not FD) pic libraries.  It's implied by
!      ‘-mlibrary-pic’, as well as by ‘-fPIC’ and ‘-fpic’ without
!      ‘-mfdpic’.  You should never have to use it explicitly.
  
! ‘-mlinked-fp’
  
       Follow the EABI requirement of always creating a frame pointer
       whenever a stack frame is allocated.  This option is enabled by
!      default and can be disabled with ‘-mno-linked-fp’.
  
! ‘-mlong-calls’
  
       Use indirect addressing to call functions outside the current
       compilation unit.  This allows the functions to be placed anywhere
       within the 32-bit address space.
  
! ‘-malign-labels’
  
       Try to align labels to an 8-byte boundary by inserting NOPs into
       the previous packet.  This option only has an effect when VLIW
       packing is enabled.  It doesn't create new packets; it merely adds
       NOPs to existing ones.
  
! ‘-mlibrary-pic’
  
       Generate position-independent EABI code.
  
! ‘-macc-4’
  
       Use only the first four media accumulator registers.
  
! ‘-macc-8’
  
       Use all eight media accumulator registers.
  
! ‘-mpack’
  
       Pack VLIW instructions.
  
! ‘-mno-pack’
  
       Do not pack VLIW instructions.
  
! ‘-mno-eflags’
  
       Do not mark ABI switches in e_flags.
  
! ‘-mcond-move’
  
       Enable the use of conditional-move instructions (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mno-cond-move’
  
       Disable the use of conditional-move instructions.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mscc’
  
       Enable the use of conditional set instructions (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mno-scc’
  
       Disable the use of conditional set instructions.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mcond-exec’
  
       Enable the use of conditional execution (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mno-cond-exec’
  
       Disable the use of conditional execution.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mvliw-branch’
  
       Run a pass to pack branches into VLIW instructions (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mno-vliw-branch’
  
       Do not run a pass to pack branches into VLIW instructions.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mmulti-cond-exec’
  
!      Enable optimization of ‘&&’ and ‘||’ in conditional execution
       (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mno-multi-cond-exec’
  
!      Disable optimization of ‘&&’ and ‘||’ in conditional execution.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mnested-cond-exec’
  
       Enable nested conditional execution optimizations (default).
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-mno-nested-cond-exec’
  
       Disable nested conditional execution optimizations.
  
       This switch is mainly for debugging the compiler and will likely be
       removed in a future version.
  
! ‘-moptimize-membar’
  
!      This switch removes redundant ‘membar’ instructions from the
       compiler-generated code.  It is enabled by default.
  
! ‘-mno-optimize-membar’
  
!      This switch disables the automatic removal of redundant ‘membar’
       instructions from the generated code.
  
! ‘-mtomcat-stats’
  
       Cause gas to print out tomcat statistics.
  
! ‘-mcpu=CPU’
  
       Select the processor type for which to generate code.  Possible
!      values are ‘frv’, ‘fr550’, ‘tomcat’, ‘fr500’, ‘fr450’, ‘fr405’,
!      ‘fr400’, ‘fr300’ and ‘simple’.
  
  
  File: gcc.info,  Node: GNU/Linux Options,  Next: H8/300 Options,  Prev: FRV Options,  Up: Submodel Options
*************** File: gcc.info,  Node: GNU/Linux Options
*** 23334,23374 ****
  3.19.17 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*', '*-*-linux-*musl*' and '*-*-linux-*android*'
       targets.
  
! '-muclibc'
!      Use uClibc C library.  This is the default on '*-*-linux-*uclibc*'
       targets.
  
! '-mmusl'
!      Use the musl C library.  This is the default on '*-*-linux-*musl*'
       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.
  
  
--- 23344,23384 ----
  3.19.17 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*’, ‘*-*-linux-*musl*’ and ‘*-*-linux-*android*’
       targets.
  
! ‘-muclibc’
!      Use uClibc C library.  This is the default on ‘*-*-linux-*uclibc*’
       targets.
  
! ‘-mmusl’
!      Use the musl C library.  This is the default on ‘*-*-linux-*musl*’
       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,
*** 23377,23420 ****
  3.19.18 H8/300 Options
  ----------------------
  
! These '-m' options are defined for the H8/300 implementations:
  
! '-mrelax'
       Shorten some address references at link time, when possible; uses
!      the linker option '-relax'.  *Note 'ld' and the H8/300: (ld)H8/300,
       for a fuller description.
  
! '-mh'
       Generate code for the H8/300H.
  
! '-ms'
       Generate code for the H8S.
  
! '-mn'
       Generate code for the H8S and H8/300H in the normal mode.  This
!      switch must be used either with '-mh' or '-ms'.
  
! '-ms2600'
       Generate code for the H8S/2600.  This switch must be used with
!      '-ms'.
  
! '-mexr'
       Extended registers are stored on stack before execution of function
!      with monitor attribute.  Default option is '-mexr'.  This option is
       valid only for H8S targets.
  
! '-mno-exr'
       Extended registers are not stored on stack before execution of
!      function with monitor attribute.  Default option is '-mno-exr'.
       This option is valid only for H8S targets.
  
! '-mint32'
!      Make 'int' data 32 bits by default.
  
! '-malign-300'
       On the H8/300H and H8S, use the same alignment rules as for the
       H8/300.  The default for the H8/300H and H8S is to align longs and
!      floats on 4-byte boundaries.  '-malign-300' causes them to be
       aligned on 2-byte boundaries.  This option has no effect on the
       H8/300.
  
--- 23387,23430 ----
  3.19.18 H8/300 Options
  ----------------------
  
! These ‘-m’ options are defined for the H8/300 implementations:
  
! ‘-mrelax’
       Shorten some address references at link time, when possible; uses
!      the linker option ‘-relax’.  *Note ‘ld’ and the H8/300: (ld)H8/300,
       for a fuller description.
  
! ‘-mh’
       Generate code for the H8/300H.
  
! ‘-ms’
       Generate code for the H8S.
  
! ‘-mn’
       Generate code for the H8S and H8/300H in the normal mode.  This
!      switch must be used either with ‘-mh’ or ‘-ms’.
  
! ‘-ms2600’
       Generate code for the H8S/2600.  This switch must be used with
!      ‘-ms’.
  
! ‘-mexr’
       Extended registers are stored on stack before execution of function
!      with monitor attribute.  Default option is ‘-mexr’.  This option is
       valid only for H8S targets.
  
! ‘-mno-exr’
       Extended registers are not stored on stack before execution of
!      function with monitor attribute.  Default option is ‘-mno-exr’.
       This option is valid only for H8S targets.
  
! ‘-mint32’
!      Make ‘int’ data 32 bits by default.
  
! ‘-malign-300’
       On the H8/300H and H8S, use the same alignment rules as for the
       H8/300.  The default for the H8/300H and H8S is to align longs and
!      floats on 4-byte boundaries.  ‘-malign-300’ causes them to be
       aligned on 2-byte boundaries.  This option has no effect on the
       H8/300.
  
*************** File: gcc.info,  Node: HPPA Options,  Ne
*** 23424,23536 ****
  3.19.19 HPPA Options
  --------------------
  
! These '-m' options are defined for the HPPA family of computers:
  
! '-march=ARCHITECTURE-TYPE'
       Generate code for the specified architecture.  The choices for
!      ARCHITECTURE-TYPE are '1.0' for PA 1.0, '1.1' for PA 1.1, and '2.0'
!      for PA 2.0 processors.  Refer to '/usr/lib/sched.models' on an
       HP-UX system to determine the proper architecture option for your
       machine.  Code compiled for lower numbered architectures runs on
       higher numbered architectures, but not the other way around.
  
! '-mpa-risc-1-0'
! '-mpa-risc-1-1'
! '-mpa-risc-2-0'
!      Synonyms for '-march=1.0', '-march=1.1', and '-march=2.0'
       respectively.
  
! '-matomic-libcalls'
       Generate libcalls for atomic loads and stores when sync libcalls
       are disabled.  This option is enabled by default.  It only affects
       the generation of atomic libcalls by the HPPA backend.
  
!      Both the sync and 'libatomic' libcall implementations use locking.
       As a result, processor stores are not atomic with respect to other
       atomic operations.  Processor loads up to DImode are atomic with
       respect to other atomic operations provided they are implemented as
       a single access.
  
       The PA-RISC architecture does not support any atomic operations in
!      hardware except for the 'ldcw' instruction.  Thus, all atomic
       support is implemented using sync and atomic libcalls.  Sync
!      libcall support is in 'libgcc.a'.  Atomic libcall support is in
!      'libatomic'.
  
!      This option generates '__atomic_exchange' calls for atomic stores.
       It also provides special handling for atomic DImode accesses on
       32-bit targets.
  
! '-mbig-switch'
       Does nothing.  Preserved for backward compatibility.
  
! '-mcaller-copies'
       The caller copies function arguments passed by hidden reference.
       This option should be used with care as it is not compatible with
       the default 32-bit runtime.  However, only aggregates larger than
       eight bytes are passed by hidden reference and the option provides
       better compatibility with OpenMP.
  
! '-mcoherent-ldcw'
       Use ldcw/ldcd coherent cache-control hint.
  
! '-mdisable-fpregs'
!      Disable floating-point registers.  Equivalent to '-msoft-float'.
  
! '-mdisable-indexing'
       Prevent the compiler from using indexing address modes.  This
       avoids some rather obscure problems when compiling MIG generated
       code under MACH.
  
! '-mfast-indirect-calls'
       Generate code that assumes calls never cross space boundaries.
       This allows GCC to emit code that performs faster indirect calls.
  
       This option does not work in the presence of shared libraries or
       nested functions.
  
! '-mfixed-range=REGISTER-RANGE'
       Generate code treating the given register range as fixed registers.
       A fixed register is one that the register allocator cannot use.
       This is useful when compiling kernel code.  A register range is
       specified as two registers separated by a dash.  Multiple register
       ranges can be specified separated by a comma.
  
! '-mgas'
       Enable the use of assembler directives only GAS understands.
  
! '-mgnu-ld'
!      Use options specific to GNU 'ld'.  This passes '-shared' to 'ld'
       when building a shared library.  It is the default when GCC is
       configured, explicitly or implicitly, with the GNU linker.  This
!      option does not affect which 'ld' is called; it only changes what
!      parameters are passed to that 'ld'.  The 'ld' that is called is
!      determined by the '--with-ld' configure option, GCC's program
!      search path, and finally by the user's 'PATH'.  The linker used by
!      GCC can be printed using 'which `gcc -print-prog-name=ld`'.  This
       option is only available on the 64-bit HP-UX GCC, i.e. configured
!      with 'hppa*64*-*-hpux*'.
  
! '-mhp-ld'
!      Use options specific to HP 'ld'.  This passes '-b' to 'ld' when
!      building a shared library and passes '+Accept TypeMismatch' to 'ld'
       on all links.  It is the default when GCC is configured, explicitly
       or implicitly, with the HP linker.  This option does not affect
!      which 'ld' is called; it only changes what parameters are passed to
!      that 'ld'.  The 'ld' that is called is determined by the
!      '--with-ld' configure option, GCC's program search path, and
!      finally by the user's 'PATH'.  The linker used by GCC can be
!      printed using 'which `gcc -print-prog-name=ld`'.  This option is
       only available on the 64-bit HP-UX GCC, i.e. configured with
!      'hppa*64*-*-hpux*'.
  
! '-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.
  
! '-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
--- 23434,23546 ----
  3.19.19 HPPA Options
  --------------------
  
! These ‘-m’ options are defined for the HPPA family of computers:
  
! ‘-march=ARCHITECTURE-TYPE’
       Generate code for the specified architecture.  The choices for
!      ARCHITECTURE-TYPE are ‘1.0’ for PA 1.0, ‘1.1’ for PA 1.1, and ‘2.0’
!      for PA 2.0 processors.  Refer to ‘/usr/lib/sched.models’ on an
       HP-UX system to determine the proper architecture option for your
       machine.  Code compiled for lower numbered architectures runs on
       higher numbered architectures, but not the other way around.
  
! ‘-mpa-risc-1-0’
! ‘-mpa-risc-1-1’
! ‘-mpa-risc-2-0’
!      Synonyms for ‘-march=1.0’, ‘-march=1.1’, and ‘-march=2.0’
       respectively.
  
! ‘-matomic-libcalls’
       Generate libcalls for atomic loads and stores when sync libcalls
       are disabled.  This option is enabled by default.  It only affects
       the generation of atomic libcalls by the HPPA backend.
  
!      Both the sync and ‘libatomic’ libcall implementations use locking.
       As a result, processor stores are not atomic with respect to other
       atomic operations.  Processor loads up to DImode are atomic with
       respect to other atomic operations provided they are implemented as
       a single access.
  
       The PA-RISC architecture does not support any atomic operations in
!      hardware except for the ‘ldcw’ instruction.  Thus, all atomic
       support is implemented using sync and atomic libcalls.  Sync
!      libcall support is in ‘libgcc.a’.  Atomic libcall support is in
!      ‘libatomic’.
  
!      This option generates ‘__atomic_exchange’ calls for atomic stores.
       It also provides special handling for atomic DImode accesses on
       32-bit targets.
  
! ‘-mbig-switch’
       Does nothing.  Preserved for backward compatibility.
  
! ‘-mcaller-copies’
       The caller copies function arguments passed by hidden reference.
       This option should be used with care as it is not compatible with
       the default 32-bit runtime.  However, only aggregates larger than
       eight bytes are passed by hidden reference and the option provides
       better compatibility with OpenMP.
  
! ‘-mcoherent-ldcw’
       Use ldcw/ldcd coherent cache-control hint.
  
! ‘-mdisable-fpregs’
!      Disable floating-point registers.  Equivalent to ‘-msoft-float’.
  
! ‘-mdisable-indexing’
       Prevent the compiler from using indexing address modes.  This
       avoids some rather obscure problems when compiling MIG generated
       code under MACH.
  
! ‘-mfast-indirect-calls’
       Generate code that assumes calls never cross space boundaries.
       This allows GCC to emit code that performs faster indirect calls.
  
       This option does not work in the presence of shared libraries or
       nested functions.
  
! ‘-mfixed-range=REGISTER-RANGE’
       Generate code treating the given register range as fixed registers.
       A fixed register is one that the register allocator cannot use.
       This is useful when compiling kernel code.  A register range is
       specified as two registers separated by a dash.  Multiple register
       ranges can be specified separated by a comma.
  
! ‘-mgas’
       Enable the use of assembler directives only GAS understands.
  
! ‘-mgnu-ld’
!      Use options specific to GNU ‘ld’.  This passes ‘-shared’ to ‘ld’
       when building a shared library.  It is the default when GCC is
       configured, explicitly or implicitly, with the GNU linker.  This
!      option does not affect which ‘ld’ is called; it only changes what
!      parameters are passed to that ‘ld’.  The ‘ld’ that is called is
!      determined by the ‘--with-ld’ configure option, GCC's program
!      search path, and finally by the user's ‘PATH’.  The linker used by
!      GCC can be printed using ‘which `gcc -print-prog-name=ld`’.  This
       option is only available on the 64-bit HP-UX GCC, i.e. configured
!      with ‘hppa*64*-*-hpux*’.
  
! ‘-mhp-ld’
!      Use options specific to HP ‘ld’.  This passes ‘-b’ to ‘ld’ when
!      building a shared library and passes ‘+Accept TypeMismatch’ to ‘ld’
       on all links.  It is the default when GCC is configured, explicitly
       or implicitly, with the HP linker.  This option does not affect
!      which ‘ld’ is called; it only changes what parameters are passed to
!      that ‘ld’.  The ‘ld’ that is called is determined by the
!      ‘--with-ld’ configure option, GCC's program search path, and
!      finally by the user's ‘PATH’.  The linker used by GCC can be
!      printed using ‘which `gcc -print-prog-name=ld`’.  This option is
       only available on the 64-bit HP-UX GCC, i.e. configured with
!      ‘hppa*64*-*-hpux*’.
  
! ‘-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.
  
! ‘-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
*************** These '-m' options are defined for the H
*** 23541,23548 ****
       always limited at 240,000 bytes.
  
       Distances are measured from the beginning of functions when using
!      the '-ffunction-sections' option, or when using the '-mgas' and
!      '-mno-portable-runtime' options together under HP-UX with the SOM
       linker.
  
       It is normally not desirable to use this option as it degrades
--- 23551,23558 ----
       always limited at 240,000 bytes.
  
       Distances are measured from the beginning of functions when using
!      the ‘-ffunction-sections’ option, or when using the ‘-mgas’ and
!      ‘-mno-portable-runtime’ options together under HP-UX with the SOM
       linker.
  
       It is normally not desirable to use this option as it degrades
*************** These '-m' options are defined for the H
*** 23556,23598 ****
       However, an indirect call is used on 32-bit ELF systems in pic code
       and it is quite long.
  
! '-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.
  
! '-mjump-in-delay'
       This option is ignored and provided for compatibility purposes
       only.
  
! '-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.
  
! '-mordered'
       Assume memory references are ordered and barriers are not needed.
  
! '-mportable-runtime'
       Use the portable calling conventions proposed by HP for ELF
       systems.
  
! '-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'.
  
! '-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.
  
! '-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
--- 23566,23608 ----
       However, an indirect call is used on 32-bit ELF systems in pic code
       and it is quite long.
  
! ‘-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.
  
! ‘-mjump-in-delay’
       This option is ignored and provided for compatibility purposes
       only.
  
! ‘-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.
  
! ‘-mordered’
       Assume memory references are ordered and barriers are not needed.
  
! ‘-mportable-runtime’
       Use the portable calling conventions proposed by HP for ELF
       systems.
  
! ‘-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’.
  
! ‘-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.
  
! ‘-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
*************** These '-m' options are defined for the H
*** 23600,23631 ****
       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.
  
! '-msoft-mult'
       Use software integer multiplication.
  
!      This disables the use of the 'xmpyu' instruction.
  
! '-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
--- 23610,23641 ----
       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.
  
! ‘-msoft-mult’
       Use software integer multiplication.
  
!      This disables the use of the ‘xmpyu’ instruction.
  
! ‘-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
*************** These '-m' options are defined for the H
*** 23634,23661 ****
  
       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.
  
--- 23644,23671 ----
  
       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: IA-64 Options,  N
*** 23665,23882 ****
  3.19.20 IA-64 Options
  ---------------------
  
! These are the '-m' options defined for the Intel IA-64 architecture.
  
! '-mbig-endian'
       Generate code for a big-endian target.  This is the default for
       HP-UX.
  
! '-mlittle-endian'
       Generate code for a little-endian target.  This is the default for
       AIX5 and GNU/Linux.
  
! '-mgnu-as'
! '-mno-gnu-as'
       Generate (or don't) code for the GNU assembler.  This is the
       default.
  
! '-mgnu-ld'
! '-mno-gnu-ld'
       Generate (or don't) code for the GNU linker.  This is the default.
  
! '-mno-pic'
       Generate code that does not use a global pointer register.  The
       result is not position independent code, and violates the IA-64
       ABI.
  
! '-mvolatile-asm-stop'
! '-mno-volatile-asm-stop'
       Generate (or don't) a stop bit immediately before and after
       volatile asm statements.
  
! '-mregister-names'
! '-mno-register-names'
!      Generate (or don't) 'in', 'loc', and 'out' register names for the
       stacked registers.  This may make assembler output more readable.
  
! '-mno-sdata'
! '-msdata'
       Disable (or enable) optimizations that use the small data section.
       This may be useful for working around optimizer bugs.
  
! '-mconstant-gp'
       Generate code that uses a single constant global pointer value.
       This is useful when compiling kernel code.
  
! '-mauto-pic'
       Generate code that is self-relocatable.  This implies
!      '-mconstant-gp'.  This is useful when compiling firmware code.
  
! '-minline-float-divide-min-latency'
       Generate code for inline divides of floating-point values using the
       minimum latency algorithm.
  
! '-minline-float-divide-max-throughput'
       Generate code for inline divides of floating-point values using the
       maximum throughput algorithm.
  
! '-mno-inline-float-divide'
       Do not generate inline code for divides of floating-point values.
  
! '-minline-int-divide-min-latency'
       Generate code for inline divides of integer values using the
       minimum latency algorithm.
  
! '-minline-int-divide-max-throughput'
       Generate code for inline divides of integer values using the
       maximum throughput algorithm.
  
! '-mno-inline-int-divide'
       Do not generate inline code for divides of integer values.
  
! '-minline-sqrt-min-latency'
       Generate code for inline square roots using the minimum latency
       algorithm.
  
! '-minline-sqrt-max-throughput'
       Generate code for inline square roots using the maximum throughput
       algorithm.
  
! '-mno-inline-sqrt'
!      Do not generate inline code for 'sqrt'.
  
! '-mfused-madd'
! '-mno-fused-madd'
       Do (don't) generate code that uses the fused multiply/add or
       multiply/subtract instructions.  The default is to use these
       instructions.
  
! '-mno-dwarf2-asm'
! '-mdwarf2-asm'
       Don't (or do) generate assembler code for the DWARF line number
       debugging info.  This may be useful when not using the GNU
       assembler.
  
! '-mearly-stop-bits'
! '-mno-early-stop-bits'
       Allow stop bits to be placed earlier than immediately preceding the
       instruction that triggered the stop bit.  This can improve
       instruction scheduling, but does not always do so.
  
! '-mfixed-range=REGISTER-RANGE'
       Generate code treating the given register range as fixed registers.
       A fixed register is one that the register allocator cannot use.
       This is useful when compiling kernel code.  A register range is
       specified as two registers separated by a dash.  Multiple register
       ranges can be specified separated by a comma.
  
! '-mtls-size=TLS-SIZE'
       Specify bit size of immediate TLS offsets.  Valid values are 14,
       22, and 64.
  
! '-mtune=CPU-TYPE'
       Tune the instruction scheduling for a particular CPU, Valid values
!      are 'itanium', 'itanium1', 'merced', 'itanium2', and 'mckinley'.
  
! '-milp32'
! '-mlp64'
       Generate code for a 32-bit or 64-bit environment.  The 32-bit
       environment sets int, long and pointer to 32 bits.  The 64-bit
       environment sets int to 32 bits and long and pointer to 64 bits.
       These are HP-UX specific flags.
  
! '-mno-sched-br-data-spec'
! '-msched-br-data-spec'
       (Dis/En)able data speculative scheduling before reload.  This
!      results in generation of 'ld.a' instructions and the corresponding
!      check instructions ('ld.c' / 'chk.a').  The default setting is
       disabled.
  
! '-msched-ar-data-spec'
! '-mno-sched-ar-data-spec'
       (En/Dis)able data speculative scheduling after reload.  This
!      results in generation of 'ld.a' instructions and the corresponding
!      check instructions ('ld.c' / 'chk.a').  The default setting is
       enabled.
  
! '-mno-sched-control-spec'
! '-msched-control-spec'
       (Dis/En)able control speculative scheduling.  This feature is
       available only during region scheduling (i.e. before reload).  This
!      results in generation of the 'ld.s' instructions and the
!      corresponding check instructions 'chk.s'.  The default setting is
       disabled.
  
! '-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
       setting is enabled.
  
! '-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
       setting is enabled.
  
! '-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 setting is
       enabled.
  
! '-mno-sched-prefer-non-data-spec-insns'
! '-msched-prefer-non-data-spec-insns'
       If enabled, data-speculative instructions are chosen for schedule
       only if there are no other choices at the moment.  This makes the
       use of the data speculation much more conservative.  The default
       setting is disabled.
  
! '-mno-sched-prefer-non-control-spec-insns'
! '-msched-prefer-non-control-spec-insns'
       If enabled, control-speculative instructions are chosen for
       schedule only if there are no other choices at the moment.  This
       makes the use of the control speculation much more conservative.
       The default setting is disabled.
  
! '-mno-sched-count-spec-in-critical-path'
! '-msched-count-spec-in-critical-path'
       If enabled, speculative dependencies are considered during
       computation of the instructions priorities.  This makes the use of
       the speculation a bit more conservative.  The default setting is
       disabled.
  
! '-msched-spec-ldc'
       Use a simple data speculation check.  This option is on by default.
  
! '-msched-control-spec-ldc'
       Use a simple check for control speculation.  This option is on by
       default.
  
! '-msched-stop-bits-after-every-cycle'
       Place a stop bit after every cycle when scheduling.  This option is
       on by default.
  
! '-msched-fp-mem-deps-zero-cost'
       Assume that floating-point stores and loads are not likely to cause
       a conflict when placed into the same instruction group.  This
       option is disabled by default.
  
! '-msel-sched-dont-check-control-spec'
       Generate checks for control speculation in selective scheduling.
       This flag is disabled by default.
  
! '-msched-max-memory-insns=MAX-INSNS'
       Limit on the number of memory insns per instruction group, giving
       lower priority to subsequent memory insns attempting to schedule in
       the same instruction group.  Frequently useful to prevent cache
       bank conflicts.  The default value is 1.
  
! '-msched-max-memory-insns-hard-limit'
!      Makes the limit specified by 'msched-max-memory-insns' a hard
       limit, disallowing more than that number in an instruction group.
       Otherwise, the limit is "soft", meaning that non-memory operations
       are preferred when the limit is reached, but memory operations may
--- 23675,23892 ----
  3.19.20 IA-64 Options
  ---------------------
  
! These are the ‘-m’ options defined for the Intel IA-64 architecture.
  
! ‘-mbig-endian’
       Generate code for a big-endian target.  This is the default for
       HP-UX.
  
! ‘-mlittle-endian’
       Generate code for a little-endian target.  This is the default for
       AIX5 and GNU/Linux.
  
! ‘-mgnu-as’
! ‘-mno-gnu-as’
       Generate (or don't) code for the GNU assembler.  This is the
       default.
  
! ‘-mgnu-ld’
! ‘-mno-gnu-ld’
       Generate (or don't) code for the GNU linker.  This is the default.
  
! ‘-mno-pic’
       Generate code that does not use a global pointer register.  The
       result is not position independent code, and violates the IA-64
       ABI.
  
! ‘-mvolatile-asm-stop’
! ‘-mno-volatile-asm-stop’
       Generate (or don't) a stop bit immediately before and after
       volatile asm statements.
  
! ‘-mregister-names’
! ‘-mno-register-names’
!      Generate (or don't) ‘in’, ‘loc’, and ‘out’ register names for the
       stacked registers.  This may make assembler output more readable.
  
! ‘-mno-sdata’
! ‘-msdata’
       Disable (or enable) optimizations that use the small data section.
       This may be useful for working around optimizer bugs.
  
! ‘-mconstant-gp’
       Generate code that uses a single constant global pointer value.
       This is useful when compiling kernel code.
  
! ‘-mauto-pic’
       Generate code that is self-relocatable.  This implies
!      ‘-mconstant-gp’.  This is useful when compiling firmware code.
  
! ‘-minline-float-divide-min-latency’
       Generate code for inline divides of floating-point values using the
       minimum latency algorithm.
  
! ‘-minline-float-divide-max-throughput’
       Generate code for inline divides of floating-point values using the
       maximum throughput algorithm.
  
! ‘-mno-inline-float-divide’
       Do not generate inline code for divides of floating-point values.
  
! ‘-minline-int-divide-min-latency’
       Generate code for inline divides of integer values using the
       minimum latency algorithm.
  
! ‘-minline-int-divide-max-throughput’
       Generate code for inline divides of integer values using the
       maximum throughput algorithm.
  
! ‘-mno-inline-int-divide’
       Do not generate inline code for divides of integer values.
  
! ‘-minline-sqrt-min-latency’
       Generate code for inline square roots using the minimum latency
       algorithm.
  
! ‘-minline-sqrt-max-throughput’
       Generate code for inline square roots using the maximum throughput
       algorithm.
  
! ‘-mno-inline-sqrt’
!      Do not generate inline code for ‘sqrt’.
  
! ‘-mfused-madd’
! ‘-mno-fused-madd’
       Do (don't) generate code that uses the fused multiply/add or
       multiply/subtract instructions.  The default is to use these
       instructions.
  
! ‘-mno-dwarf2-asm’
! ‘-mdwarf2-asm’
       Don't (or do) generate assembler code for the DWARF line number
       debugging info.  This may be useful when not using the GNU
       assembler.
  
! ‘-mearly-stop-bits’
! ‘-mno-early-stop-bits’
       Allow stop bits to be placed earlier than immediately preceding the
       instruction that triggered the stop bit.  This can improve
       instruction scheduling, but does not always do so.
  
! ‘-mfixed-range=REGISTER-RANGE’
       Generate code treating the given register range as fixed registers.
       A fixed register is one that the register allocator cannot use.
       This is useful when compiling kernel code.  A register range is
       specified as two registers separated by a dash.  Multiple register
       ranges can be specified separated by a comma.
  
! ‘-mtls-size=TLS-SIZE’
       Specify bit size of immediate TLS offsets.  Valid values are 14,
       22, and 64.
  
! ‘-mtune=CPU-TYPE’
       Tune the instruction scheduling for a particular CPU, Valid values
!      are ‘itanium’, ‘itanium1’, ‘merced’, ‘itanium2’, and ‘mckinley’.
  
! ‘-milp32’
! ‘-mlp64’
       Generate code for a 32-bit or 64-bit environment.  The 32-bit
       environment sets int, long and pointer to 32 bits.  The 64-bit
       environment sets int to 32 bits and long and pointer to 64 bits.
       These are HP-UX specific flags.
  
! ‘-mno-sched-br-data-spec’
! ‘-msched-br-data-spec’
       (Dis/En)able data speculative scheduling before reload.  This
!      results in generation of ‘ld.a’ instructions and the corresponding
!      check instructions (‘ld.c’ / ‘chk.a’).  The default setting is
       disabled.
  
! ‘-msched-ar-data-spec’
! ‘-mno-sched-ar-data-spec’
       (En/Dis)able data speculative scheduling after reload.  This
!      results in generation of ‘ld.a’ instructions and the corresponding
!      check instructions (‘ld.c’ / ‘chk.a’).  The default setting is
       enabled.
  
! ‘-mno-sched-control-spec’
! ‘-msched-control-spec’
       (Dis/En)able control speculative scheduling.  This feature is
       available only during region scheduling (i.e. before reload).  This
!      results in generation of the ‘ld.s’ instructions and the
!      corresponding check instructions ‘chk.s’.  The default setting is
       disabled.
  
! ‘-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
       setting is enabled.
  
! ‘-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
       setting is enabled.
  
! ‘-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 setting is
       enabled.
  
! ‘-mno-sched-prefer-non-data-spec-insns’
! ‘-msched-prefer-non-data-spec-insns’
       If enabled, data-speculative instructions are chosen for schedule
       only if there are no other choices at the moment.  This makes the
       use of the data speculation much more conservative.  The default
       setting is disabled.
  
! ‘-mno-sched-prefer-non-control-spec-insns’
! ‘-msched-prefer-non-control-spec-insns’
       If enabled, control-speculative instructions are chosen for
       schedule only if there are no other choices at the moment.  This
       makes the use of the control speculation much more conservative.
       The default setting is disabled.
  
! ‘-mno-sched-count-spec-in-critical-path’
! ‘-msched-count-spec-in-critical-path’
       If enabled, speculative dependencies are considered during
       computation of the instructions priorities.  This makes the use of
       the speculation a bit more conservative.  The default setting is
       disabled.
  
! ‘-msched-spec-ldc’
       Use a simple data speculation check.  This option is on by default.
  
! ‘-msched-control-spec-ldc’
       Use a simple check for control speculation.  This option is on by
       default.
  
! ‘-msched-stop-bits-after-every-cycle’
       Place a stop bit after every cycle when scheduling.  This option is
       on by default.
  
! ‘-msched-fp-mem-deps-zero-cost’
       Assume that floating-point stores and loads are not likely to cause
       a conflict when placed into the same instruction group.  This
       option is disabled by default.
  
! ‘-msel-sched-dont-check-control-spec’
       Generate checks for control speculation in selective scheduling.
       This flag is disabled by default.
  
! ‘-msched-max-memory-insns=MAX-INSNS’
       Limit on the number of memory insns per instruction group, giving
       lower priority to subsequent memory insns attempting to schedule in
       the same instruction group.  Frequently useful to prevent cache
       bank conflicts.  The default value is 1.
  
! ‘-msched-max-memory-insns-hard-limit’
!      Makes the limit specified by ‘msched-max-memory-insns’ a hard
       limit, disallowing more than that number in an instruction group.
       Otherwise, the limit is "soft", meaning that non-memory operations
       are preferred when the limit is reached, but memory operations may
*************** File: gcc.info,  Node: LM32 Options,  Ne
*** 23888,23908 ****
  3.19.21 LM32 Options
  --------------------
  
! These '-m' options are defined for the LatticeMico32 architecture:
  
! '-mbarrel-shift-enabled'
       Enable barrel-shift instructions.
  
! '-mdivide-enabled'
       Enable divide and modulus instructions.
  
! '-mmultiply-enabled'
       Enable multiply instructions.
  
! '-msign-extend-enabled'
       Enable sign extend instructions.
  
! '-muser-enabled'
       Enable user-defined instructions.
  
  
--- 23898,23918 ----
  3.19.21 LM32 Options
  --------------------
  
! These ‘-m’ options are defined for the LatticeMico32 architecture:
  
! ‘-mbarrel-shift-enabled’
       Enable barrel-shift instructions.
  
! ‘-mdivide-enabled’
       Enable divide and modulus instructions.
  
! ‘-mmultiply-enabled’
       Enable multiply instructions.
  
! ‘-msign-extend-enabled’
       Enable sign extend instructions.
  
! ‘-muser-enabled’
       Enable user-defined instructions.
  
  
*************** File: gcc.info,  Node: LoongArch Options
*** 23913,24095 ****
  
  These command-line options are defined for LoongArch targets:
  
! '-march=CPU-TYPE'
       Generate instructions for the machine type CPU-TYPE.  In contrast
!      to '-mtune=CPU-TYPE', which merely tunes the generated code for the
!      specified CPU-TYPE, '-march=CPU-TYPE' allows GCC to generate code
       that may not run at all on processors other than the one indicated.
!      Specifying '-march=CPU-TYPE' implies '-mtune=CPU-TYPE', except
       where noted otherwise.
  
       The choices for CPU-TYPE are:
  
!      'native'
            This selects the CPU to generate code for at compilation time
            by determining the processor type of the compiling machine.
!           Using '-march=native' enables all instruction subsets
            supported by the local machine (hence the result might not run
!           on different machines).  Using '-mtune=native' produces code
            optimized for the local machine under the constraints of the
            selected instruction set.
!      'loongarch64'
            A generic CPU with 64-bit extensions.
!      'la464'
            LoongArch LA464 CPU with LBT, LSX, LASX, LVZ.
  
! '-mtune=CPU-TYPE'
       Optimize the output for the given processor, specified by
       microarchitecture name.
  
! '-mabi=BASE-ABI-TYPE'
       Generate code for the specified calling convention.  BASE-ABI-TYPE
       can be one of:
!      'lp64d'
            Uses 64-bit general purpose registers and 32/64-bit
            floating-point registers for parameter passing.  Data model is
!           LP64, where 'int' is 32 bits, while 'long int' and pointers
            are 64 bits.
!      'lp64f'
            Uses 64-bit general purpose registers and 32-bit
            floating-point registers for parameter passing.  Data model is
!           LP64, where 'int' is 32 bits, while 'long int' and pointers
            are 64 bits.
!      'lp64s'
            Uses 64-bit general purpose registers and no floating-point
            registers for parameter passing.  Data model is LP64, where
!           'int' is 32 bits, while 'long int' and pointers are 64 bits.
  
! '-mfpu=FPU-TYPE'
       Generate code for the specified FPU type, which can be one of:
!      '64'
            Allow the use of hardware floating-point instructions for
            32-bit and 64-bit operations.
!      '32'
            Allow the use of hardware floating-point instructions for
            32-bit operations.
!      'none'
!      '0'
            Prevent the use of hardware floating-point instructions.
  
! '-msoft-float'
!      Force '-mfpu=none' and prevents the use of floating-point registers
       for parameter passing.  This option may change the target ABI.
  
! '-msingle-float'
!      Force '-mfpu=32' and allow the use of 32-bit floating-point
       registers for parameter passing.  This option may change the target
       ABI.
  
! '-mdouble-float'
!      Force '-mfpu=64' and allow the use of 32/64-bit floating-point
       registers for parameter passing.  This option may change the target
       ABI.
  
! '-mbranch-cost=N'
       Set the cost of branches to roughly N instructions.
  
! '-mcheck-zero-division'
! '-mno-check-zero-divison'
       Trap (do not trap) on integer division by zero.  The default is
!      '-mcheck-zero-division' for '-O0' or '-Og', and
!      '-mno-check-zero-division' for other optimization levels.
  
! '-mcond-move-int'
! '-mno-cond-move-int'
       Conditional moves for integral data in general-purpose registers
!      are enabled (disabled).  The default is '-mcond-move-int'.
  
! '-mcond-move-float'
! '-mno-cond-move-float'
       Conditional moves for floating-point registers are enabled
!      (disabled).  The default is '-mcond-move-float'.
  
! '-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.  Setting optimization level to '-Os'
!      also forces the use of 'memcpy', but '-mno-memcpy' may override
       this behavior if explicitly specified, regardless of the order
       these options on the command line.
  
! '-mstrict-align'
! '-mno-strict-align'
       Avoid or allow generating memory accesses that may not be aligned
       on a natural object boundary as described in the architecture
!      specification.  The default is '-mno-strict-align'.
  
! '-msmall-data-limit=NUMBER'
       Put global and static data smaller than NUMBER bytes into a special
       section (on some targets).  The default value is 0.
  
! '-mmax-inline-memcpy-size=N'
!      Inline all block moves (such as calls to 'memcpy' or structure
       copies) less than or equal to N bytes.  The default value of N is
       1024.
  
! '-mcmodel=CODE-MODEL'
       Set the code model to one of:
!      'tiny-static (Not implemented yet)'
!      'tiny (Not implemented yet)'
  
!      'normal'
            The text segment must be within 128MB addressing space.  The
            data segment must be within 2GB addressing space.
  
!      'medium'
            The text segment and data segment must be within 2GB
            addressing space.
  
!      'large (Not implemented yet)'
  
!      'extreme'
            This mode does not limit the size of the code segment and data
!           segment.  The '-mcmodel=extreme' option is incompatible with
!           '-fplt' and '-mno-explicit-relocs'.
!      The default code model is 'normal'.
  
! '-mexplicit-relocs'
! '-mno-explicit-relocs'
       Use or do not use assembler relocation operators when dealing with
       symbolic addresses.  The alternative is to use assembler macros
       instead, which may limit instruction scheduling but allow linker
       relaxation.  The default value for the option is determined with
       the assembler capability detected during GCC build-time and the
!      setting of '-mrelax': '-mexplicit-relocs' if the assembler supports
!      relocation operators but '-mrelax' is not enabled,
!      '-mno-explicit-relocs' otherwise.
  
! '-mdirect-extern-access'
! '-mno-direct-extern-access'
       Do not use or use GOT to access external symbols.  The default is
!      '-mno-direct-extern-access': GOT is used for external symbols with
       default visibility, but not used for other external symbols.
  
!      With '-mdirect-extern-access', GOT is not used and all external
       symbols are PC-relatively addressed.  It is *only* suitable for
       environments where no dynamic link is performed, like firmwares, OS
!      kernels, executables linked with '-static' or '-static-pie'.
!      '-mdirect-extern-access' is not compatible with '-fPIC' or '-fpic'.
  
! '-mrelax'
! '-mno-relax'
       Take (do not take) advantage of linker relaxations.  If
!      '-mpass-mrelax-to-as' is enabled, this option is also passed to the
       assembler.  The default is determined during GCC build-time by
!      detecting corresponding assembler support: '-mrelax' if the
!      assembler supports both the '-mrelax' option and the conditional
!      branch relaxation (it's required or the '.align' directives and
       conditional branch instructions in the assembly code outputted by
       GCC may be rejected by the assembler because of a relocation
!      overflow), '-mno-relax' otherwise.
  
! '-mpass-mrelax-to-as'
! '-mno-pass-mrelax-to-as'
!      Pass (do not pass) the '-mrelax' or '-mno-relax' option to the
       assembler.  The default is determined during GCC build-time by
!      detecting corresponding assembler support: '-mpass-mrelax-to-as' if
!      the assembler supports the '-mrelax' option,
!      '-mno-pass-mrelax-to-as' otherwise.  This option is mostly useful
       for debugging, or interoperation with assemblers different from the
       build-time one.
  
--- 23923,24105 ----
  
  These command-line options are defined for LoongArch targets:
  
! ‘-march=CPU-TYPE’
       Generate instructions for the machine type CPU-TYPE.  In contrast
!      to ‘-mtune=CPU-TYPE’, which merely tunes the generated code for the
!      specified CPU-TYPE, ‘-march=CPU-TYPE’ allows GCC to generate code
       that may not run at all on processors other than the one indicated.
!      Specifying ‘-march=CPU-TYPE’ implies ‘-mtune=CPU-TYPE’, except
       where noted otherwise.
  
       The choices for CPU-TYPE are:
  
!      ‘native’
            This selects the CPU to generate code for at compilation time
            by determining the processor type of the compiling machine.
!           Using ‘-march=native’ enables all instruction subsets
            supported by the local machine (hence the result might not run
!           on different machines).  Using ‘-mtune=native’ produces code
            optimized for the local machine under the constraints of the
            selected instruction set.
!      ‘loongarch64’
            A generic CPU with 64-bit extensions.
!      ‘la464’
            LoongArch LA464 CPU with LBT, LSX, LASX, LVZ.
  
! ‘-mtune=CPU-TYPE’
       Optimize the output for the given processor, specified by
       microarchitecture name.
  
! ‘-mabi=BASE-ABI-TYPE’
       Generate code for the specified calling convention.  BASE-ABI-TYPE
       can be one of:
!      ‘lp64d’
            Uses 64-bit general purpose registers and 32/64-bit
            floating-point registers for parameter passing.  Data model is
!           LP64, where ‘int’ is 32 bits, while ‘long int’ and pointers
            are 64 bits.
!      ‘lp64f’
            Uses 64-bit general purpose registers and 32-bit
            floating-point registers for parameter passing.  Data model is
!           LP64, where ‘int’ is 32 bits, while ‘long int’ and pointers
            are 64 bits.
!      ‘lp64s’
            Uses 64-bit general purpose registers and no floating-point
            registers for parameter passing.  Data model is LP64, where
!           ‘int’ is 32 bits, while ‘long int’ and pointers are 64 bits.
  
! ‘-mfpu=FPU-TYPE’
       Generate code for the specified FPU type, which can be one of:
!      ‘64’
            Allow the use of hardware floating-point instructions for
            32-bit and 64-bit operations.
!      ‘32’
            Allow the use of hardware floating-point instructions for
            32-bit operations.
!      ‘none’
!      ‘0’
            Prevent the use of hardware floating-point instructions.
  
! ‘-msoft-float’
!      Force ‘-mfpu=none’ and prevents the use of floating-point registers
       for parameter passing.  This option may change the target ABI.
  
! ‘-msingle-float’
!      Force ‘-mfpu=32’ and allow the use of 32-bit floating-point
       registers for parameter passing.  This option may change the target
       ABI.
  
! ‘-mdouble-float’
!      Force ‘-mfpu=64’ and allow the use of 32/64-bit floating-point
       registers for parameter passing.  This option may change the target
       ABI.
  
! ‘-mbranch-cost=N’
       Set the cost of branches to roughly N instructions.
  
! ‘-mcheck-zero-division’
! ‘-mno-check-zero-divison’
       Trap (do not trap) on integer division by zero.  The default is
!      ‘-mcheck-zero-division’ for ‘-O0’ or ‘-Og’, and
!      ‘-mno-check-zero-division’ for other optimization levels.
  
! ‘-mcond-move-int’
! ‘-mno-cond-move-int’
       Conditional moves for integral data in general-purpose registers
!      are enabled (disabled).  The default is ‘-mcond-move-int’.
  
! ‘-mcond-move-float’
! ‘-mno-cond-move-float’
       Conditional moves for floating-point registers are enabled
!      (disabled).  The default is ‘-mcond-move-float’.
  
! ‘-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.  Setting optimization level to ‘-Os’
!      also forces the use of ‘memcpy’, but ‘-mno-memcpy’ may override
       this behavior if explicitly specified, regardless of the order
       these options on the command line.
  
! ‘-mstrict-align’
! ‘-mno-strict-align’
       Avoid or allow generating memory accesses that may not be aligned
       on a natural object boundary as described in the architecture
!      specification.  The default is ‘-mno-strict-align’.
  
! ‘-msmall-data-limit=NUMBER’
       Put global and static data smaller than NUMBER bytes into a special
       section (on some targets).  The default value is 0.
  
! ‘-mmax-inline-memcpy-size=N’
!      Inline all block moves (such as calls to ‘memcpy’ or structure
       copies) less than or equal to N bytes.  The default value of N is
       1024.
  
! ‘-mcmodel=CODE-MODEL’
       Set the code model to one of:
!      ‘tiny-static (Not implemented yet)’
!      ‘tiny (Not implemented yet)’
  
!      ‘normal’
            The text segment must be within 128MB addressing space.  The
            data segment must be within 2GB addressing space.
  
!      ‘medium’
            The text segment and data segment must be within 2GB
            addressing space.
  
!      ‘large (Not implemented yet)’
  
!      ‘extreme’
            This mode does not limit the size of the code segment and data
!           segment.  The ‘-mcmodel=extreme’ option is incompatible with
!           ‘-fplt’ and ‘-mno-explicit-relocs’.
!      The default code model is ‘normal’.
  
! ‘-mexplicit-relocs’
! ‘-mno-explicit-relocs’
       Use or do not use assembler relocation operators when dealing with
       symbolic addresses.  The alternative is to use assembler macros
       instead, which may limit instruction scheduling but allow linker
       relaxation.  The default value for the option is determined with
       the assembler capability detected during GCC build-time and the
!      setting of ‘-mrelax’: ‘-mexplicit-relocs’ if the assembler supports
!      relocation operators but ‘-mrelax’ is not enabled,
!      ‘-mno-explicit-relocs’ otherwise.
  
! ‘-mdirect-extern-access’
! ‘-mno-direct-extern-access’
       Do not use or use GOT to access external symbols.  The default is
!      ‘-mno-direct-extern-access’: GOT is used for external symbols with
       default visibility, but not used for other external symbols.
  
!      With ‘-mdirect-extern-access’, GOT is not used and all external
       symbols are PC-relatively addressed.  It is *only* suitable for
       environments where no dynamic link is performed, like firmwares, OS
!      kernels, executables linked with ‘-static’ or ‘-static-pie’.
!      ‘-mdirect-extern-access’ is not compatible with ‘-fPIC’ or ‘-fpic’.
  
! ‘-mrelax’
! ‘-mno-relax’
       Take (do not take) advantage of linker relaxations.  If
!      ‘-mpass-mrelax-to-as’ is enabled, this option is also passed to the
       assembler.  The default is determined during GCC build-time by
!      detecting corresponding assembler support: ‘-mrelax’ if the
!      assembler supports both the ‘-mrelax’ option and the conditional
!      branch relaxation (it's required or the ‘.align’ directives and
       conditional branch instructions in the assembly code outputted by
       GCC may be rejected by the assembler because of a relocation
!      overflow), ‘-mno-relax’ otherwise.
  
! ‘-mpass-mrelax-to-as’
! ‘-mno-pass-mrelax-to-as’
!      Pass (do not pass) the ‘-mrelax’ or ‘-mno-relax’ option to the
       assembler.  The default is determined during GCC build-time by
!      detecting corresponding assembler support: ‘-mpass-mrelax-to-as’ if
!      the assembler supports the ‘-mrelax’ option,
!      ‘-mno-pass-mrelax-to-as’ otherwise.  This option is mostly useful
       for debugging, or interoperation with assemblers different from the
       build-time one.
  
*************** File: gcc.info,  Node: M32C Options,  Ne
*** 24099,24111 ****
  3.19.23 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
--- 24109,24121 ----
  3.19.23 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
*************** File: gcc.info,  Node: M32C Options,  Ne
*** 24113,24119 ****
       provide your own runtime library for whatever I/O functions are
       needed.
  
! '-memregs=NUMBER'
       Specifies the number of memory-based pseudo-registers GCC uses
       during code generation.  These pseudo-registers are used like real
       registers, so there is a tradeoff between GCC's ability to fit the
--- 24123,24129 ----
       provide your own runtime library for whatever I/O functions are
       needed.
  
! ‘-memregs=NUMBER’
       Specifies the number of memory-based pseudo-registers GCC uses
       during code generation.  These pseudo-registers are used like real
       registers, so there is a tradeoff between GCC's ability to fit the
*************** File: gcc.info,  Node: M32R/D Options,
*** 24129,24226 ****
  3.19.24 M32R/D Options
  ----------------------
  
! These '-m' options are defined for Renesas M32R/D architectures:
  
! '-m32r2'
       Generate code for the M32R/2.
  
! '-m32rx'
       Generate code for the M32R/X.
  
! '-m32r'
       Generate code for the M32R.  This is the default.
  
! '-mmodel=small'
       Assume all objects live in the lower 16MB of memory (so that their
!      addresses can be loaded with the 'ld24' instruction), and assume
!      all subroutines are reachable with the 'bl' instruction.  This is
       the default.
  
       The addressability of a particular object can be set with the
!      'model' attribute.
  
! '-mmodel=medium'
       Assume objects may be anywhere in the 32-bit address space (the
!      compiler generates 'seth/add3' instructions to load their
!      addresses), and assume all subroutines are reachable with the 'bl'
       instruction.
  
! '-mmodel=large'
       Assume objects may be anywhere in the 32-bit address space (the
!      compiler generates 'seth/add3' instructions to load their
       addresses), and assume subroutines may not be reachable with the
!      'bl' instruction (the compiler generates the much slower
!      'seth/add3/jl' instruction sequence).
  
! '-msdata=none'
       Disable use of the small data area.  Variables are put into one of
!      '.data', '.bss', or '.rodata' (unless the 'section' attribute has
       been specified).  This is the default.
  
!      The small data area consists of sections '.sdata' and '.sbss'.
       Objects may be explicitly put in the small data area with the
!      'section' attribute using one of these sections.
  
! '-msdata=sdata'
       Put small global and static data in the small data area, but do not
       generate special code to reference them.
  
! '-msdata=use'
       Put small global and static data in the small data area, and
       generate special instructions to reference them.
  
! '-G NUM'
       Put global and static objects less than or equal to NUM bytes into
       the small data or BSS sections instead of the normal data or BSS
!      sections.  The default value of NUM is 8.  The '-msdata' option
!      must be set to one of 'sdata' or 'use' for this option to have any
       effect.
  
!      All modules should be compiled with the same '-G NUM' value.
       Compiling with different values of NUM may or may not work; if it
       doesn't the linker gives an error message--incorrect code is not
       generated.
  
! '-mdebug'
       Makes the M32R-specific code in the compiler display some
       statistics that might help in debugging programs.
  
! '-malign-loops'
       Align all loops to a 32-byte boundary.
  
! '-mno-align-loops'
       Do not enforce a 32-byte alignment for loops.  This is the default.
  
! '-missue-rate=NUMBER'
       Issue NUMBER instructions per cycle.  NUMBER can only be 1 or 2.
  
! '-mbranch-cost=NUMBER'
       NUMBER can only be 1 or 2.  If it is 1 then branches are preferred
       over conditional code, if it is 2, then the opposite applies.
  
! '-mflush-trap=NUMBER'
       Specifies the trap number to use to flush the cache.  The default
       is 12.  Valid numbers are between 0 and 15 inclusive.
  
! '-mno-flush-trap'
       Specifies that the cache cannot be flushed by using a trap.
  
! '-mflush-func=NAME'
       Specifies the name of the operating system function to call to
!      flush the cache.  The default is '_flush_cache', but a function
       call is only used if a trap is not available.
  
! '-mno-flush-func'
       Indicates that there is no OS function for flushing the cache.
  
  
--- 24139,24236 ----
  3.19.24 M32R/D Options
  ----------------------
  
! These ‘-m’ options are defined for Renesas M32R/D architectures:
  
! ‘-m32r2’
       Generate code for the M32R/2.
  
! ‘-m32rx’
       Generate code for the M32R/X.
  
! ‘-m32r’
       Generate code for the M32R.  This is the default.
  
! ‘-mmodel=small’
       Assume all objects live in the lower 16MB of memory (so that their
!      addresses can be loaded with the ‘ld24’ instruction), and assume
!      all subroutines are reachable with the ‘bl’ instruction.  This is
       the default.
  
       The addressability of a particular object can be set with the
!      ‘model’ attribute.
  
! ‘-mmodel=medium’
       Assume objects may be anywhere in the 32-bit address space (the
!      compiler generates ‘seth/add3’ instructions to load their
!      addresses), and assume all subroutines are reachable with the ‘bl’
       instruction.
  
! ‘-mmodel=large’
       Assume objects may be anywhere in the 32-bit address space (the
!      compiler generates ‘seth/add3’ instructions to load their
       addresses), and assume subroutines may not be reachable with the
!      ‘bl’ instruction (the compiler generates the much slower
!      ‘seth/add3/jl’ instruction sequence).
  
! ‘-msdata=none’
       Disable use of the small data area.  Variables are put into one of
!      ‘.data’, ‘.bss’, or ‘.rodata’ (unless the ‘section’ attribute has
       been specified).  This is the default.
  
!      The small data area consists of sections ‘.sdata’ and ‘.sbss’.
       Objects may be explicitly put in the small data area with the
!      ‘section’ attribute using one of these sections.
  
! ‘-msdata=sdata’
       Put small global and static data in the small data area, but do not
       generate special code to reference them.
  
! ‘-msdata=use’
       Put small global and static data in the small data area, and
       generate special instructions to reference them.
  
! ‘-G NUM’
       Put global and static objects less than or equal to NUM bytes into
       the small data or BSS sections instead of the normal data or BSS
!      sections.  The default value of NUM is 8.  The ‘-msdata’ option
!      must be set to one of ‘sdata’ or ‘use’ for this option to have any
       effect.
  
!      All modules should be compiled with the same ‘-G NUM’ value.
       Compiling with different values of NUM may or may not work; if it
       doesn't the linker gives an error message--incorrect code is not
       generated.
  
! ‘-mdebug’
       Makes the M32R-specific code in the compiler display some
       statistics that might help in debugging programs.
  
! ‘-malign-loops’
       Align all loops to a 32-byte boundary.
  
! ‘-mno-align-loops’
       Do not enforce a 32-byte alignment for loops.  This is the default.
  
! ‘-missue-rate=NUMBER’
       Issue NUMBER instructions per cycle.  NUMBER can only be 1 or 2.
  
! ‘-mbranch-cost=NUMBER’
       NUMBER can only be 1 or 2.  If it is 1 then branches are preferred
       over conditional code, if it is 2, then the opposite applies.
  
! ‘-mflush-trap=NUMBER’
       Specifies the trap number to use to flush the cache.  The default
       is 12.  Valid numbers are between 0 and 15 inclusive.
  
! ‘-mno-flush-trap’
       Specifies that the cache cannot be flushed by using a trap.
  
! ‘-mflush-func=NAME’
       Specifies the name of the operating system function to call to
!      flush the cache.  The default is ‘_flush_cache’, but a function
       call is only used if a trap is not available.
  
! ‘-mno-flush-func’
       Indicates that there is no OS function for flushing the cache.
  
  
*************** File: gcc.info,  Node: M680x0 Options,
*** 24229,24467 ****
  3.19.25 M680x0 Options
  ----------------------
  
! These are the '-m' options defined for M680x0 and ColdFire processors.
  The default settings depend on which architecture was selected when the
  compiler was configured; the defaults for the most common choices are
  given below.
  
! '-march=ARCH'
       Generate code for a specific M680x0 or ColdFire instruction set
       architecture.  Permissible values of ARCH for M680x0 architectures
!      are: '68000', '68010', '68020', '68030', '68040', '68060' and
!      'cpu32'.  ColdFire architectures are selected according to
       Freescale's ISA classification and the permissible values are:
!      'isaa', 'isaaplus', 'isab' and 'isac'.
  
!      GCC defines a macro '__mcfARCH__' whenever it is generating code
       for a ColdFire target.  The ARCH in this macro is one of the
!      '-march' arguments given above.
  
!      When used together, '-march' and '-mtune' select code that runs on
       a family of similar processors but that is optimized for a
       particular microarchitecture.
  
! '-mcpu=CPU'
       Generate code for a specific M680x0 or ColdFire processor.  The
!      M680x0 CPUs are: '68000', '68010', '68020', '68030', '68040',
!      '68060', '68302', '68332' and 'cpu32'.  The ColdFire CPUs are given
       by the table below, which also classifies the CPUs into families:
  
!      *Family*       *'-mcpu' arguments*
       --------------------------------------------------------------------------
!      '51'           '51' '51ac' '51ag' '51cn' '51em' '51je' '51jf' '51jg'
!                     '51jm' '51mm' '51qe' '51qm'
!      '5206'         '5202' '5204' '5206'
!      '5206e'        '5206e'
!      '5208'         '5207' '5208'
!      '5211a'        '5210a' '5211a'
!      '5213'         '5211' '5212' '5213'
!      '5216'         '5214' '5216'
!      '52235'        '52230' '52231' '52232' '52233' '52234' '52235'
!      '5225'         '5224' '5225'
!      '52259'        '52252' '52254' '52255' '52256' '52258' '52259'
!      '5235'         '5232' '5233' '5234' '5235' '523x'
!      '5249'         '5249'
!      '5250'         '5250'
!      '5271'         '5270' '5271'
!      '5272'         '5272'
!      '5275'         '5274' '5275'
!      '5282'         '5280' '5281' '5282' '528x'
!      '53017'        '53011' '53012' '53013' '53014' '53015' '53016' '53017'
!      '5307'         '5307'
!      '5329'         '5327' '5328' '5329' '532x'
!      '5373'         '5372' '5373' '537x'
!      '5407'         '5407'
!      '5475'         '5470' '5471' '5472' '5473' '5474' '5475' '547x' '5480'
!                     '5481' '5482' '5483' '5484' '5485'
  
!      '-mcpu=CPU' overrides '-march=ARCH' if ARCH is compatible with CPU.
!      Other combinations of '-mcpu' and '-march' are rejected.
  
!      GCC defines the macro '__mcf_cpu_CPU' when ColdFire target CPU is
!      selected.  It also defines '__mcf_family_FAMILY', where the value
       of FAMILY is given by the table above.
  
! '-mtune=TUNE'
       Tune the code for a particular microarchitecture within the
!      constraints set by '-march' and '-mcpu'.  The M680x0
!      microarchitectures are: '68000', '68010', '68020', '68030',
!      '68040', '68060' and 'cpu32'.  The ColdFire microarchitectures are:
!      'cfv1', 'cfv2', 'cfv3', 'cfv4' and 'cfv4e'.
  
!      You can also use '-mtune=68020-40' for code that needs to run
       relatively well on 68020, 68030 and 68040 targets.
!      '-mtune=68020-60' is similar but includes 68060 targets as well.
!      These two options select the same tuning decisions as '-m68020-40'
!      and '-m68020-60' respectively.
  
!      GCC defines the macros '__mcARCH' and '__mcARCH__' when tuning for
!      680x0 architecture ARCH.  It also defines 'mcARCH' unless either
!      '-ansi' or a non-GNU '-std' option is used.  If GCC is tuning for a
!      range of architectures, as selected by '-mtune=68020-40' or
!      '-mtune=68020-60', it defines the macros for every architecture in
       the range.
  
!      GCC also defines the macro '__mUARCH__' when tuning for ColdFire
       microarchitecture UARCH, where UARCH is one of the arguments given
       above.
  
! '-m68000'
! '-mc68000'
       Generate output for a 68000.  This is the default when the compiler
       is configured for 68000-based systems.  It is equivalent to
!      '-march=68000'.
  
       Use this option for microcontrollers with a 68000 or EC000 core,
       including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
  
! '-m68010'
       Generate output for a 68010.  This is the default when the compiler
       is configured for 68010-based systems.  It is equivalent to
!      '-march=68010'.
  
! '-m68020'
! '-mc68020'
       Generate output for a 68020.  This is the default when the compiler
       is configured for 68020-based systems.  It is equivalent to
!      '-march=68020'.
  
! '-m68030'
       Generate output for a 68030.  This is the default when the compiler
       is configured for 68030-based systems.  It is equivalent to
!      '-march=68030'.
  
! '-m68040'
       Generate output for a 68040.  This is the default when the compiler
       is configured for 68040-based systems.  It is equivalent to
!      '-march=68040'.
  
       This option inhibits the use of 68881/68882 instructions that have
       to be emulated by software on the 68040.  Use this option if your
       68040 does not have code to emulate those instructions.
  
! '-m68060'
       Generate output for a 68060.  This is the default when the compiler
       is configured for 68060-based systems.  It is equivalent to
!      '-march=68060'.
  
       This option inhibits the use of 68020 and 68881/68882 instructions
       that have to be emulated by software on the 68060.  Use this option
       if your 68060 does not have code to emulate those instructions.
  
! '-mcpu32'
       Generate output for a CPU32.  This is the default when the compiler
       is configured for CPU32-based systems.  It is equivalent to
!      '-march=cpu32'.
  
       Use this option for microcontrollers with a CPU32 or CPU32+ core,
       including the 68330, 68331, 68332, 68333, 68334, 68336, 68340,
       68341, 68349 and 68360.
  
! '-m5200'
       Generate output for a 520X ColdFire CPU.  This is the default when
       the compiler is configured for 520X-based systems.  It is
!      equivalent to '-mcpu=5206', and is now deprecated in favor of that
       option.
  
       Use this option for microcontroller with a 5200 core, including the
       MCF5202, MCF5203, MCF5204 and MCF5206.
  
! '-m5206e'
       Generate output for a 5206e ColdFire CPU.  The option is now
!      deprecated in favor of the equivalent '-mcpu=5206e'.
  
! '-m528x'
       Generate output for a member of the ColdFire 528X family.  The
!      option is now deprecated in favor of the equivalent '-mcpu=528x'.
  
! '-m5307'
       Generate output for a ColdFire 5307 CPU.  The option is now
!      deprecated in favor of the equivalent '-mcpu=5307'.
  
! '-m5407'
       Generate output for a ColdFire 5407 CPU.  The option is now
!      deprecated in favor of the equivalent '-mcpu=5407'.
  
! '-mcfv4e'
       Generate output for a ColdFire V4e family CPU (e.g. 547x/548x).
       This includes use of hardware floating-point instructions.  The
!      option is equivalent to '-mcpu=547x', and is now deprecated in
       favor of that option.
  
! '-m68020-40'
       Generate output for a 68040, without using any of the new
       instructions.  This results in code that can run relatively
       efficiently on either a 68020/68881 or a 68030 or a 68040.  The
       generated code does use the 68881 instructions that are emulated on
       the 68040.
  
!      The option is equivalent to '-march=68020' '-mtune=68020-40'.
  
! '-m68020-60'
       Generate output for a 68060, without using any of the new
       instructions.  This results in code that can run relatively
       efficiently on either a 68020/68881 or a 68030 or a 68040.  The
       generated code does use the 68881 instructions that are emulated on
       the 68060.
  
!      The option is equivalent to '-march=68020' '-mtune=68020-60'.
  
! '-mhard-float'
! '-m68881'
       Generate floating-point instructions.  This is the default for
       68020 and above, and for ColdFire devices that have an FPU.  It
!      defines the macro '__HAVE_68881__' on M680x0 targets and
!      '__mcffpu__' on ColdFire targets.
  
! '-msoft-float'
       Do not generate floating-point instructions; use library calls
       instead.  This is the default for 68000, 68010, and 68832 targets.
       It is also the default for ColdFire devices that have no FPU.
  
! '-mdiv'
! '-mno-div'
       Generate (do not generate) ColdFire hardware divide and remainder
!      instructions.  If '-march' is used without '-mcpu', the default is
       "on" for ColdFire architectures and "off" for M680x0 architectures.
       Otherwise, the default is taken from the target CPU (either the
!      default CPU, or the one specified by '-mcpu').  For example, the
!      default is "off" for '-mcpu=5206' and "on" for '-mcpu=5206e'.
  
!      GCC defines the macro '__mcfhwdiv__' when this option is enabled.
  
! '-mshort'
!      Consider type 'int' to be 16 bits wide, like 'short int'.
       Additionally, parameters passed on the stack are also aligned to a
       16-bit boundary even on targets whose API mandates promotion to
       32-bit.
  
! '-mno-short'
!      Do not consider type 'int' to be 16 bits wide.  This is the
       default.
  
! '-mnobitfield'
! '-mno-bitfield'
!      Do not use the bit-field instructions.  The '-m68000', '-mcpu32'
!      and '-m5200' options imply '-mnobitfield'.
  
! '-mbitfield'
!      Do use the bit-field instructions.  The '-m68020' option implies
!      '-mbitfield'.  This is the default if you use a configuration
       designed for a 68020.
  
! '-mrtd'
       Use a different function-calling convention, in which functions
!      that take a fixed number of arguments return with the 'rtd'
       instruction, which pops their arguments while returning.  This
       saves one instruction in the caller since there is no need to pop
       the arguments there.
--- 24239,24477 ----
  3.19.25 M680x0 Options
  ----------------------
  
! These are the ‘-m’ options defined for M680x0 and ColdFire processors.
  The default settings depend on which architecture was selected when the
  compiler was configured; the defaults for the most common choices are
  given below.
  
! ‘-march=ARCH’
       Generate code for a specific M680x0 or ColdFire instruction set
       architecture.  Permissible values of ARCH for M680x0 architectures
!      are: ‘68000’, ‘68010’, ‘68020’, ‘68030’, ‘68040’, ‘68060’ and
!      ‘cpu32’.  ColdFire architectures are selected according to
       Freescale's ISA classification and the permissible values are:
!      ‘isaa’, ‘isaaplus’, ‘isab’ and ‘isac’.
  
!      GCC defines a macro ‘__mcfARCH__’ whenever it is generating code
       for a ColdFire target.  The ARCH in this macro is one of the
!      ‘-march’ arguments given above.
  
!      When used together, ‘-march’ and ‘-mtune’ select code that runs on
       a family of similar processors but that is optimized for a
       particular microarchitecture.
  
! ‘-mcpu=CPU’
       Generate code for a specific M680x0 or ColdFire processor.  The
!      M680x0 CPUs are: ‘68000’, ‘68010’, ‘68020’, ‘68030’, ‘68040’,
!      ‘68060’, ‘68302’, ‘68332’ and ‘cpu32’.  The ColdFire CPUs are given
       by the table below, which also classifies the CPUs into families:
  
!      *Family*       *‘-mcpu’ arguments*
       --------------------------------------------------------------------------
!      ‘51’           ‘51’ ‘51ac’ ‘51ag’ ‘51cn’ ‘51em’ ‘51je’ ‘51jf’ ‘51jg’
!                     ‘51jm’ ‘51mm’ ‘51qe’ ‘51qm’
!      ‘5206’         ‘5202’ ‘5204’ ‘5206’
!      ‘5206e’        ‘5206e’
!      ‘5208’         ‘5207’ ‘5208’
!      ‘5211a’        ‘5210a’ ‘5211a’
!      ‘5213’         ‘5211’ ‘5212’ ‘5213’
!      ‘5216’         ‘5214’ ‘5216’
!      ‘52235’        ‘52230’ ‘52231’ ‘52232’ ‘52233’ ‘52234’ ‘52235’
!      ‘5225’         ‘5224’ ‘5225’
!      ‘52259’        ‘52252’ ‘52254’ ‘52255’ ‘52256’ ‘52258’ ‘52259’
!      ‘5235’         ‘5232’ ‘5233’ ‘5234’ ‘5235’ ‘523x’
!      ‘5249’         ‘5249’
!      ‘5250’         ‘5250’
!      ‘5271’         ‘5270’ ‘5271’
!      ‘5272’         ‘5272’
!      ‘5275’         ‘5274’ ‘5275’
!      ‘5282’         ‘5280’ ‘5281’ ‘5282’ ‘528x’
!      ‘53017’        ‘53011’ ‘53012’ ‘53013’ ‘53014’ ‘53015’ ‘53016’ ‘53017’
!      ‘5307’         ‘5307’
!      ‘5329’         ‘5327’ ‘5328’ ‘5329’ ‘532x’
!      ‘5373’         ‘5372’ ‘5373’ ‘537x’
!      ‘5407’         ‘5407’
!      ‘5475’         ‘5470’ ‘5471’ ‘5472’ ‘5473’ ‘5474’ ‘5475’ ‘547x’ ‘5480’
!                     ‘5481’ ‘5482’ ‘5483’ ‘5484’ ‘5485’
  
!      ‘-mcpu=CPU’ overrides ‘-march=ARCH’ if ARCH is compatible with CPU.
!      Other combinations of ‘-mcpu’ and ‘-march’ are rejected.
  
!      GCC defines the macro ‘__mcf_cpu_CPU’ when ColdFire target CPU is
!      selected.  It also defines ‘__mcf_family_FAMILY’, where the value
       of FAMILY is given by the table above.
  
! ‘-mtune=TUNE’
       Tune the code for a particular microarchitecture within the
!      constraints set by ‘-march’ and ‘-mcpu’.  The M680x0
!      microarchitectures are: ‘68000’, ‘68010’, ‘68020’, ‘68030’,
!      ‘68040’, ‘68060’ and ‘cpu32’.  The ColdFire microarchitectures are:
!      ‘cfv1’, ‘cfv2’, ‘cfv3’, ‘cfv4’ and ‘cfv4e’.
  
!      You can also use ‘-mtune=68020-40’ for code that needs to run
       relatively well on 68020, 68030 and 68040 targets.
!      ‘-mtune=68020-60’ is similar but includes 68060 targets as well.
!      These two options select the same tuning decisions as ‘-m68020-40’
!      and ‘-m68020-60’ respectively.
  
!      GCC defines the macros ‘__mcARCH’ and ‘__mcARCH__’ when tuning for
!      680x0 architecture ARCH.  It also defines ‘mcARCH’ unless either
!      ‘-ansi’ or a non-GNU ‘-std’ option is used.  If GCC is tuning for a
!      range of architectures, as selected by ‘-mtune=68020-40’ or
!      ‘-mtune=68020-60’, it defines the macros for every architecture in
       the range.
  
!      GCC also defines the macro ‘__mUARCH__’ when tuning for ColdFire
       microarchitecture UARCH, where UARCH is one of the arguments given
       above.
  
! ‘-m68000’
! ‘-mc68000’
       Generate output for a 68000.  This is the default when the compiler
       is configured for 68000-based systems.  It is equivalent to
!      ‘-march=68000’.
  
       Use this option for microcontrollers with a 68000 or EC000 core,
       including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
  
! ‘-m68010’
       Generate output for a 68010.  This is the default when the compiler
       is configured for 68010-based systems.  It is equivalent to
!      ‘-march=68010’.
  
! ‘-m68020’
! ‘-mc68020’
       Generate output for a 68020.  This is the default when the compiler
       is configured for 68020-based systems.  It is equivalent to
!      ‘-march=68020’.
  
! ‘-m68030’
       Generate output for a 68030.  This is the default when the compiler
       is configured for 68030-based systems.  It is equivalent to
!      ‘-march=68030’.
  
! ‘-m68040’
       Generate output for a 68040.  This is the default when the compiler
       is configured for 68040-based systems.  It is equivalent to
!      ‘-march=68040’.
  
       This option inhibits the use of 68881/68882 instructions that have
       to be emulated by software on the 68040.  Use this option if your
       68040 does not have code to emulate those instructions.
  
! ‘-m68060’
       Generate output for a 68060.  This is the default when the compiler
       is configured for 68060-based systems.  It is equivalent to
!      ‘-march=68060’.
  
       This option inhibits the use of 68020 and 68881/68882 instructions
       that have to be emulated by software on the 68060.  Use this option
       if your 68060 does not have code to emulate those instructions.
  
! ‘-mcpu32’
       Generate output for a CPU32.  This is the default when the compiler
       is configured for CPU32-based systems.  It is equivalent to
!      ‘-march=cpu32’.
  
       Use this option for microcontrollers with a CPU32 or CPU32+ core,
       including the 68330, 68331, 68332, 68333, 68334, 68336, 68340,
       68341, 68349 and 68360.
  
! ‘-m5200’
       Generate output for a 520X ColdFire CPU.  This is the default when
       the compiler is configured for 520X-based systems.  It is
!      equivalent to ‘-mcpu=5206’, and is now deprecated in favor of that
       option.
  
       Use this option for microcontroller with a 5200 core, including the
       MCF5202, MCF5203, MCF5204 and MCF5206.
  
! ‘-m5206e’
       Generate output for a 5206e ColdFire CPU.  The option is now
!      deprecated in favor of the equivalent ‘-mcpu=5206e’.
  
! ‘-m528x’
       Generate output for a member of the ColdFire 528X family.  The
!      option is now deprecated in favor of the equivalent ‘-mcpu=528x’.
  
! ‘-m5307’
       Generate output for a ColdFire 5307 CPU.  The option is now
!      deprecated in favor of the equivalent ‘-mcpu=5307’.
  
! ‘-m5407’
       Generate output for a ColdFire 5407 CPU.  The option is now
!      deprecated in favor of the equivalent ‘-mcpu=5407’.
  
! ‘-mcfv4e’
       Generate output for a ColdFire V4e family CPU (e.g. 547x/548x).
       This includes use of hardware floating-point instructions.  The
!      option is equivalent to ‘-mcpu=547x’, and is now deprecated in
       favor of that option.
  
! ‘-m68020-40’
       Generate output for a 68040, without using any of the new
       instructions.  This results in code that can run relatively
       efficiently on either a 68020/68881 or a 68030 or a 68040.  The
       generated code does use the 68881 instructions that are emulated on
       the 68040.
  
!      The option is equivalent to ‘-march=68020’ ‘-mtune=68020-40’.
  
! ‘-m68020-60’
       Generate output for a 68060, without using any of the new
       instructions.  This results in code that can run relatively
       efficiently on either a 68020/68881 or a 68030 or a 68040.  The
       generated code does use the 68881 instructions that are emulated on
       the 68060.
  
!      The option is equivalent to ‘-march=68020’ ‘-mtune=68020-60’.
  
! ‘-mhard-float’
! ‘-m68881’
       Generate floating-point instructions.  This is the default for
       68020 and above, and for ColdFire devices that have an FPU.  It
!      defines the macro ‘__HAVE_68881__’ on M680x0 targets and
!      ‘__mcffpu__’ on ColdFire targets.
  
! ‘-msoft-float’
       Do not generate floating-point instructions; use library calls
       instead.  This is the default for 68000, 68010, and 68832 targets.
       It is also the default for ColdFire devices that have no FPU.
  
! ‘-mdiv’
! ‘-mno-div’
       Generate (do not generate) ColdFire hardware divide and remainder
!      instructions.  If ‘-march’ is used without ‘-mcpu’, the default is
       "on" for ColdFire architectures and "off" for M680x0 architectures.
       Otherwise, the default is taken from the target CPU (either the
!      default CPU, or the one specified by ‘-mcpu’).  For example, the
!      default is "off" for ‘-mcpu=5206’ and "on" for ‘-mcpu=5206e’.
  
!      GCC defines the macro ‘__mcfhwdiv__’ when this option is enabled.
  
! ‘-mshort’
!      Consider type ‘int’ to be 16 bits wide, like ‘short int’.
       Additionally, parameters passed on the stack are also aligned to a
       16-bit boundary even on targets whose API mandates promotion to
       32-bit.
  
! ‘-mno-short’
!      Do not consider type ‘int’ to be 16 bits wide.  This is the
       default.
  
! ‘-mnobitfield’
! ‘-mno-bitfield’
!      Do not use the bit-field instructions.  The ‘-m68000’, ‘-mcpu32’
!      and ‘-m5200’ options imply ‘-mnobitfield’.
  
! ‘-mbitfield’
!      Do use the bit-field instructions.  The ‘-m68020’ option implies
!      ‘-mbitfield’.  This is the default if you use a configuration
       designed for a 68020.
  
! ‘-mrtd’
       Use a different function-calling convention, in which functions
!      that take a fixed number of arguments return with the ‘rtd’
       instruction, which pops their arguments while returning.  This
       saves one instruction in the caller since there is no need to pop
       the arguments there.
*************** given below.
*** 24471,24545 ****
       compiled with the Unix compiler.
  
       Also, you must provide function prototypes for all functions that
!      take variable numbers of arguments (including 'printf'); otherwise
       incorrect code is generated for calls to those functions.
  
       In addition, seriously incorrect code results if you call a
       function with too many arguments.  (Normally, extra arguments are
       harmlessly ignored.)
  
!      The 'rtd' instruction is supported by the 68010, 68020, 68030,
       68040, 68060 and CPU32 processors, but not by the 68000 or 5200.
  
!      The default is '-mno-rtd'.
  
! '-malign-int'
! '-mno-align-int'
!      Control whether GCC aligns 'int', 'long', 'long long', 'float',
!      'double', and 'long double' variables on a 32-bit boundary
!      ('-malign-int') or a 16-bit boundary ('-mno-align-int').  Aligning
       variables on 32-bit boundaries produces code that runs somewhat
       faster on processors with 32-bit busses at the expense of more
       memory.
  
!      *Warning:* if you use the '-malign-int' switch, GCC aligns
       structures containing the above types differently than most
       published application binary interface specifications for the m68k.
  
       Use the pc-relative addressing mode of the 68000 directly, instead
       of using a global offset table.  At present, this option implies
!      '-fpic', allowing at most a 16-bit offset for pc-relative
!      addressing.  '-fPIC' is not presently supported with '-mpcrel',
       though this could be supported for 68020 and higher processors.
  
! '-mno-strict-align'
! '-mstrict-align'
       Do not (do) assume that unaligned memory references are handled by
       the system.
  
! '-msep-data'
       Generate code that allows the data segment to be located in a
       different area of memory from the text segment.  This allows for
       execute-in-place in an environment without virtual memory
!      management.  This option implies '-fPIC'.
  
! '-mno-sep-data'
       Generate code that assumes that the data segment follows the text
       segment.  This is the default.
  
! '-mid-shared-library'
       Generate code that supports shared libraries via the library ID
       method.  This allows for execute-in-place and shared libraries in
       an environment without virtual memory management.  This option
!      implies '-fPIC'.
  
! '-mno-id-shared-library'
       Generate code that doesn't assume ID-based shared libraries are
       being used.  This is the default.
  
! '-mshared-library-id=n'
       Specifies the identification number of the ID-based shared library
       being compiled.  Specifying a value of 0 generates more compact
       code; specifying other values forces the allocation of that number
       to the current library, but is no more space- or time-efficient
       than omitting this option.
  
! '-mxgot'
! '-mno-xgot'
       When generating position-independent code for ColdFire, generate
       code that works if the GOT has more than 8192 entries.  This code
       is larger and slower than code generated without this option.  On
!      M680x0 processors, this option is not needed; '-fPIC' suffices.
  
       GCC normally uses a single instruction to load values from the GOT.
       While this is relatively efficient, it only works if the GOT is
--- 24481,24555 ----
       compiled with the Unix compiler.
  
       Also, you must provide function prototypes for all functions that
!      take variable numbers of arguments (including ‘printf’); otherwise
       incorrect code is generated for calls to those functions.
  
       In addition, seriously incorrect code results if you call a
       function with too many arguments.  (Normally, extra arguments are
       harmlessly ignored.)
  
!      The ‘rtd’ instruction is supported by the 68010, 68020, 68030,
       68040, 68060 and CPU32 processors, but not by the 68000 or 5200.
  
!      The default is ‘-mno-rtd’.
  
! ‘-malign-int’
! ‘-mno-align-int’
!      Control whether GCC aligns ‘int’, ‘long’, ‘long long’, ‘float’,
!      ‘double’, and ‘long double’ variables on a 32-bit boundary
!      (‘-malign-int’) or a 16-bit boundary (‘-mno-align-int’).  Aligning
       variables on 32-bit boundaries produces code that runs somewhat
       faster on processors with 32-bit busses at the expense of more
       memory.
  
!      *Warning:* if you use the ‘-malign-int’ switch, GCC aligns
       structures containing the above types differently than most
       published application binary interface specifications for the m68k.
  
       Use the pc-relative addressing mode of the 68000 directly, instead
       of using a global offset table.  At present, this option implies
!      ‘-fpic’, allowing at most a 16-bit offset for pc-relative
!      addressing.  ‘-fPIC’ is not presently supported with ‘-mpcrel’,
       though this could be supported for 68020 and higher processors.
  
! ‘-mno-strict-align’
! ‘-mstrict-align’
       Do not (do) assume that unaligned memory references are handled by
       the system.
  
! ‘-msep-data’
       Generate code that allows the data segment to be located in a
       different area of memory from the text segment.  This allows for
       execute-in-place in an environment without virtual memory
!      management.  This option implies ‘-fPIC’.
  
! ‘-mno-sep-data’
       Generate code that assumes that the data segment follows the text
       segment.  This is the default.
  
! ‘-mid-shared-library’
       Generate code that supports shared libraries via the library ID
       method.  This allows for execute-in-place and shared libraries in
       an environment without virtual memory management.  This option
!      implies ‘-fPIC’.
  
! ‘-mno-id-shared-library’
       Generate code that doesn't assume ID-based shared libraries are
       being used.  This is the default.
  
! ‘-mshared-library-id=n’
       Specifies the identification number of the ID-based shared library
       being compiled.  Specifying a value of 0 generates more compact
       code; specifying other values forces the allocation of that number
       to the current library, but is no more space- or time-efficient
       than omitting this option.
  
! ‘-mxgot’
! ‘-mno-xgot’
       When generating position-independent code for ColdFire, generate
       code that works if the GOT has more than 8192 entries.  This code
       is larger and slower than code generated without this option.  On
!      M680x0 processors, this option is not needed; ‘-fPIC’ suffices.
  
       GCC normally uses a single instruction to load values from the GOT.
       While this is relatively efficient, it only works if the GOT is
*************** given below.
*** 24548,24569 ****
  
            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.
  
! '-mlong-jump-table-offsets'
!      Use 32-bit offsets in 'switch' tables.  The default is to use
       16-bit offsets.
  
  
--- 24558,24579 ----
  
            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.
  
! ‘-mlong-jump-table-offsets’
!      Use 32-bit offsets in ‘switch’ tables.  The default is to use
       16-bit offsets.
  
  
*************** File: gcc.info,  Node: MCore Options,  N
*** 24572,24621 ****
  3.19.26 MCore Options
  ---------------------
  
! These are the '-m' options defined for the Motorola M*Core processors.
  
! '-mhardlit'
! '-mno-hardlit'
       Inline constants into the code stream if it can be done in two
       instructions or less.
  
! '-mdiv'
! '-mno-div'
       Use the divide instruction.  (Enabled by default).
  
! '-mrelax-immediate'
! '-mno-relax-immediate'
       Allow arbitrary-sized immediates in bit operations.
  
! '-mwide-bitfields'
! '-mno-wide-bitfields'
!      Always treat bit-fields as 'int'-sized.
  
! '-m4byte-functions'
! '-mno-4byte-functions'
       Force all functions to be aligned to a 4-byte boundary.
  
! '-mcallgraph-data'
! '-mno-callgraph-data'
       Emit callgraph information.
  
! '-mslow-bytes'
! '-mno-slow-bytes'
       Prefer word access when reading byte quantities.
  
! '-mlittle-endian'
! '-mbig-endian'
       Generate code for a little-endian target.
  
! '-m210'
! '-m340'
       Generate code for the 210 processor.
  
! '-mno-lsim'
       Assume that runtime support has been provided and so omit the
!      simulator library ('libsim.a)' from the linker command line.
  
! '-mstack-increment=SIZE'
       Set the maximum amount for a single stack increment operation.
       Large values can increase the speed of programs that contain
       functions that need a large amount of stack space, but they can
--- 24582,24631 ----
  3.19.26 MCore Options
  ---------------------
  
! These are the ‘-m’ options defined for the Motorola M*Core processors.
  
! ‘-mhardlit’
! ‘-mno-hardlit’
       Inline constants into the code stream if it can be done in two
       instructions or less.
  
! ‘-mdiv’
! ‘-mno-div’
       Use the divide instruction.  (Enabled by default).
  
! ‘-mrelax-immediate’
! ‘-mno-relax-immediate’
       Allow arbitrary-sized immediates in bit operations.
  
! ‘-mwide-bitfields’
! ‘-mno-wide-bitfields’
!      Always treat bit-fields as ‘int’-sized.
  
! ‘-m4byte-functions’
! ‘-mno-4byte-functions’
       Force all functions to be aligned to a 4-byte boundary.
  
! ‘-mcallgraph-data’
! ‘-mno-callgraph-data’
       Emit callgraph information.
  
! ‘-mslow-bytes’
! ‘-mno-slow-bytes’
       Prefer word access when reading byte quantities.
  
! ‘-mlittle-endian’
! ‘-mbig-endian’
       Generate code for a little-endian target.
  
! ‘-m210’
! ‘-m340’
       Generate code for the 210 processor.
  
! ‘-mno-lsim’
       Assume that runtime support has been provided and so omit the
!      simulator library (‘libsim.a)’ from the linker command line.
  
! ‘-mstack-increment=SIZE’
       Set the maximum amount for a single stack increment operation.
       Large values can increase the speed of programs that contain
       functions that need a large amount of stack space, but they can
*************** File: gcc.info,  Node: MicroBlaze Option
*** 24628,24719 ****
  3.19.27 MicroBlaze Options
  --------------------------
  
! '-msoft-float'
       Use software emulation for floating point (default).
  
! '-mhard-float'
       Use hardware floating-point instructions.
  
! '-mmemcpy'
!      Do not optimize block moves, use 'memcpy'.
  
! '-mno-clearbss'
!      This option is deprecated.  Use '-fno-zero-initialized-in-bss'
       instead.
  
! '-mcpu=CPU-TYPE'
       Use features of, and schedule code for, the given CPU. Supported
!      values are in the format 'vX.YY.Z', where X is a major version, YY
       is the minor version, and Z is compatibility code.  Example values
!      are 'v3.00.a', 'v4.00.b', 'v5.00.a', 'v5.00.b', 'v6.00.a'.
  
! '-mxl-soft-mul'
       Use software multiply emulation (default).
  
! '-mxl-soft-div'
       Use software emulation for divides (default).
  
! '-mxl-barrel-shift'
       Use the hardware barrel shifter.
  
! '-mxl-pattern-compare'
       Use pattern compare instructions.
  
! '-msmall-divides'
       Use table lookup optimization for small signed integer divisions.
  
! '-mxl-stack-check'
!      This option is deprecated.  Use '-fstack-check' instead.
  
! '-mxl-gp-opt'
!      Use GP-relative '.sdata'/'.sbss' sections.
  
! '-mxl-multiply-high'
       Use multiply high instructions for high part of 32x32 multiply.
  
! '-mxl-float-convert'
       Use hardware floating-point conversion instructions.
  
! '-mxl-float-sqrt'
       Use hardware floating-point square root instruction.
  
! '-mbig-endian'
       Generate code for a big-endian target.
  
! '-mlittle-endian'
       Generate code for a little-endian target.
  
! '-mxl-reorder'
       Use reorder instructions (swap and byte reversed load/store).
  
! '-mxl-mode-APP-MODEL'
       Select application model APP-MODEL.  Valid models are
!      'executable'
!           normal executable (default), uses startup code 'crt0.o'.
  
!      'xmdstub'
            for use with Xilinx Microprocessor Debugger (XMD) based
            software intrusive debug agent called xmdstub.  This uses
!           startup file 'crt1.o' and sets the start address of the
            program to 0x800.
  
!      'bootstrap'
            for applications that are loaded using a bootloader.  This
!           model uses startup file 'crt2.o' which does not contain a
            processor reset vector handler.  This is suitable for
            transferring control on a processor reset to the bootloader
            rather than the application.
  
!      'novectors'
            for applications that do not require any of the MicroBlaze
            vectors.  This option may be useful for applications running
!           within a monitoring application.  This model uses 'crt3.o' as
            a startup file.
  
!      Option '-xl-mode-APP-MODEL' is a deprecated alias for
!      '-mxl-mode-APP-MODEL'.
  
! '-mpic-data-is-text-relative'
       Assume that the displacement between the text and data segments is
       fixed at static link time.  This allows data to be referenced by
       offset from start of text address instead of GOT since PC-relative
--- 24638,24729 ----
  3.19.27 MicroBlaze Options
  --------------------------
  
! ‘-msoft-float’
       Use software emulation for floating point (default).
  
! ‘-mhard-float’
       Use hardware floating-point instructions.
  
! ‘-mmemcpy’
!      Do not optimize block moves, use ‘memcpy’.
  
! ‘-mno-clearbss’
!      This option is deprecated.  Use ‘-fno-zero-initialized-in-bss’
       instead.
  
! ‘-mcpu=CPU-TYPE’
       Use features of, and schedule code for, the given CPU. Supported
!      values are in the format ‘vX.YY.Z’, where X is a major version, YY
       is the minor version, and Z is compatibility code.  Example values
!      are ‘v3.00.a’, ‘v4.00.b’, ‘v5.00.a’, ‘v5.00.b’, ‘v6.00.a’.
  
! ‘-mxl-soft-mul’
       Use software multiply emulation (default).
  
! ‘-mxl-soft-div’
       Use software emulation for divides (default).
  
! ‘-mxl-barrel-shift’
       Use the hardware barrel shifter.
  
! ‘-mxl-pattern-compare’
       Use pattern compare instructions.
  
! ‘-msmall-divides’
       Use table lookup optimization for small signed integer divisions.
  
! ‘-mxl-stack-check’
!      This option is deprecated.  Use ‘-fstack-check’ instead.
  
! ‘-mxl-gp-opt’
!      Use GP-relative ‘.sdata’/‘.sbss’ sections.
  
! ‘-mxl-multiply-high’
       Use multiply high instructions for high part of 32x32 multiply.
  
! ‘-mxl-float-convert’
       Use hardware floating-point conversion instructions.
  
! ‘-mxl-float-sqrt’
       Use hardware floating-point square root instruction.
  
! ‘-mbig-endian’
       Generate code for a big-endian target.
  
! ‘-mlittle-endian’
       Generate code for a little-endian target.
  
! ‘-mxl-reorder’
       Use reorder instructions (swap and byte reversed load/store).
  
! ‘-mxl-mode-APP-MODEL’
       Select application model APP-MODEL.  Valid models are
!      ‘executable’
!           normal executable (default), uses startup code ‘crt0.o’.
  
!      ‘xmdstub’
            for use with Xilinx Microprocessor Debugger (XMD) based
            software intrusive debug agent called xmdstub.  This uses
!           startup file ‘crt1.o’ and sets the start address of the
            program to 0x800.
  
!      ‘bootstrap’
            for applications that are loaded using a bootloader.  This
!           model uses startup file ‘crt2.o’ which does not contain a
            processor reset vector handler.  This is suitable for
            transferring control on a processor reset to the bootloader
            rather than the application.
  
!      ‘novectors’
            for applications that do not require any of the MicroBlaze
            vectors.  This option may be useful for applications running
!           within a monitoring application.  This model uses ‘crt3.o’ as
            a startup file.
  
!      Option ‘-xl-mode-APP-MODEL’ is a deprecated alias for
!      ‘-mxl-mode-APP-MODEL’.
  
! ‘-mpic-data-is-text-relative’
       Assume that the displacement between the text and data segments is
       fixed at static link time.  This allows data to be referenced by
       offset from start of text address instead of GOT since PC-relative
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 24725,24953 ****
  3.19.28 MIPS Options
  --------------------
  
! '-EB'
       Generate big-endian code.
  
! '-EL'
!      Generate little-endian code.  This is the default for 'mips*el-*-*'
       configurations.
  
! '-march=ARCH'
       Generate code that runs on ARCH, which can be the name of a generic
       MIPS ISA, or the name of a particular processor.  The ISA names
!      are: 'mips1', 'mips2', 'mips3', 'mips4', 'mips32', 'mips32r2',
!      'mips32r3', 'mips32r5', 'mips32r6', 'mips64', 'mips64r2',
!      'mips64r3', 'mips64r5' and 'mips64r6'.  The processor names are:
!      '4kc', '4km', '4kp', '4ksc', '4kec', '4kem', '4kep', '4ksd', '5kc',
!      '5kf', '20kc', '24kc', '24kf2_1', '24kf1_1', '24kec', '24kef2_1',
!      '24kef1_1', '34kc', '34kf2_1', '34kf1_1', '34kn', '74kc',
!      '74kf2_1', '74kf1_1', '74kf3_2', '1004kc', '1004kf2_1',
!      '1004kf1_1', 'i6400', 'i6500', 'interaptiv', 'loongson2e',
!      'loongson2f', 'loongson3a', 'gs464', 'gs464e', 'gs264e', 'm4k',
!      'm14k', 'm14kc', 'm14ke', 'm14kec', 'm5100', 'm5101', 'octeon',
!      'octeon+', 'octeon2', 'octeon3', 'orion', 'p5600', 'p6600',
!      'r2000', 'r3000', 'r3900', 'r4000', 'r4400', 'r4600', 'r4650',
!      'r4700', 'r5900', 'r6000', 'r8000', 'rm7000', 'rm9000', 'r10000',
!      'r12000', 'r14000', 'r16000', 'sb1', 'sr71000', 'vr4100', 'vr4111',
!      'vr4120', 'vr4130', 'vr4300', 'vr5000', 'vr5400', 'vr5500', 'xlr'
!      and 'xlp'.  The special value 'from-abi' selects the most
!      compatible architecture for the selected ABI (that is, 'mips1' for
!      32-bit ABIs and 'mips3' for 64-bit ABIs).
  
!      The native Linux/GNU toolchain also supports the value 'native',
       which selects the best architecture option for the host processor.
!      '-march=native' has no effect if GCC does not recognize the
       processor.
  
!      In processor names, a final '000' can be abbreviated as 'k' (for
!      example, '-march=r2k').  Prefixes are optional, and 'vr' may be
!      written 'r'.
  
!      Names of the form 'Nf2_1' refer to processors with FPUs clocked at
!      half the rate of the core, names of the form 'Nf1_1' refer to
       processors with FPUs clocked at the same rate as the core, and
!      names of the form 'Nf3_2' refer to processors with FPUs clocked a
       ratio of 3:2 with respect to the core.  For compatibility reasons,
!      'Nf' is accepted as a synonym for 'Nf2_1' while 'Nx' and 'Bfx' are
!      accepted as synonyms for 'Nf1_1'.
  
       GCC defines two macros based on the value of this option.  The
!      first is '_MIPS_ARCH', which gives the name of target architecture,
!      as a string.  The second has the form '_MIPS_ARCH_FOO', where FOO
!      is the capitalized value of '_MIPS_ARCH'.  For example,
!      '-march=r2000' sets '_MIPS_ARCH' to '"r2000"' and defines the macro
!      '_MIPS_ARCH_R2000'.
  
!      Note that the '_MIPS_ARCH' macro uses the processor names given
       above.  In other words, it has the full prefix and does not
!      abbreviate '000' as 'k'.  In the case of 'from-abi', the macro
!      names the resolved architecture (either '"mips1"' or '"mips3"').
!      It names the default architecture when no '-march' option is given.
  
! '-mtune=ARCH'
       Optimize for ARCH.  Among other things, this option controls the
       way instructions are scheduled, and the perceived cost of
       arithmetic operations.  The list of ARCH values is the same as for
!      '-march'.
  
       When this option is not used, GCC optimizes for the processor
!      specified by '-march'.  By using '-march' and '-mtune' together, it
       is possible to generate code that runs on a family of processors,
       but optimize the code for one particular member of that family.
  
!      '-mtune' defines the macros '_MIPS_TUNE' and '_MIPS_TUNE_FOO',
!      which work in the same way as the '-march' ones described above.
  
! '-mips1'
!      Equivalent to '-march=mips1'.
  
! '-mips2'
!      Equivalent to '-march=mips2'.
  
! '-mips3'
!      Equivalent to '-march=mips3'.
  
! '-mips4'
!      Equivalent to '-march=mips4'.
  
! '-mips32'
!      Equivalent to '-march=mips32'.
  
! '-mips32r3'
!      Equivalent to '-march=mips32r3'.
  
! '-mips32r5'
!      Equivalent to '-march=mips32r5'.
  
! '-mips32r6'
!      Equivalent to '-march=mips32r6'.
  
! '-mips64'
!      Equivalent to '-march=mips64'.
  
! '-mips64r2'
!      Equivalent to '-march=mips64r2'.
  
! '-mips64r3'
!      Equivalent to '-march=mips64r3'.
  
! '-mips64r5'
!      Equivalent to '-march=mips64r5'.
  
! '-mips64r6'
!      Equivalent to '-march=mips64r6'.
  
! '-mips16'
! '-mno-mips16'
       Generate (do not generate) MIPS16 code.  If GCC is targeting a
       MIPS32 or MIPS64 architecture, it makes use of the MIPS16e ASE.
  
       MIPS16 code generation can also be controlled on a per-function
!      basis by means of 'mips16' and 'nomips16' attributes.  *Note
       Function Attributes::, for more information.
  
! '-mflip-mips16'
       Generate MIPS16 code on alternating functions.  This option is
       provided for regression testing of mixed MIPS16/non-MIPS16 code
       generation, and is not intended for ordinary use in compiling user
       code.
  
! '-minterlink-compressed'
! '-mno-interlink-compressed'
       Require (do not require) that code using the standard
       (uncompressed) MIPS ISA be link-compatible with MIPS16 and
       microMIPS code, and vice versa.
  
       For example, code using the standard ISA encoding cannot jump
       directly to MIPS16 or microMIPS code; it must either use a call or
!      an indirect jump.  '-minterlink-compressed' therefore disables
       direct jumps unless GCC knows that the target of the jump is not
       compressed.
  
! '-minterlink-mips16'
! '-mno-interlink-mips16'
!      Aliases of '-minterlink-compressed' and
!      '-mno-interlink-compressed'.  These options predate the microMIPS
       ASE and are retained for backwards compatibility.
  
! '-mabi=32'
! '-mabi=o64'
! '-mabi=n32'
! '-mabi=64'
! '-mabi=eabi'
       Generate code for the given ABI.
  
       Note that the EABI has a 32-bit and a 64-bit variant.  GCC normally
       generates 64-bit code when you select a 64-bit architecture, but
!      you can use '-mgp32' to get 32-bit code instead.
  
       For information about the O64 ABI, see
       .
  
       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, MIPS32R3 and MIPS32R5 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 in
       that the even-numbered double-precision registers are saved.
  
       Two additional variants of the o32 ABI are supported to enable a
       transition from 32-bit to 64-bit registers.  These are FPXX
!      ('-mfpxx') and FP64A ('-mfp64' '-mno-odd-spreg').  The FPXX
       extension mandates that all code must execute correctly when run
       using 32-bit or 64-bit registers.  The code can be interlinked with
       either FP32 or FP64, but not both.  The FP64A extension is similar
       to the FP64 extension but forbids the use of odd-numbered
       single-precision registers.  This can be used in conjunction with
!      the 'FRE' mode of FPUs in MIPS32R5 processors and allows both FP32
       and FP64A code to interlink and run in the same process without
       changing FPU modes.
  
! '-mabicalls'
! '-mno-abicalls'
       Generate (do not generate) code that is suitable for SVR4-style
!      dynamic objects.  '-mabicalls' is the default for SVR4-based
       systems.
  
! '-mshared'
! '-mno-shared'
       Generate (do not generate) code that is fully position-independent,
       and that can therefore be linked into shared libraries.  This
!      option only affects '-mabicalls'.
  
!      All '-mabicalls' code has traditionally been position-independent,
!      regardless of options like '-fPIC' and '-fpic'.  However, as an
       extension, the GNU toolchain allows executables to use absolute
       accesses for locally-binding symbols.  It can also use shorter GP
       initialization sequences and generate direct calls to
!      locally-defined functions.  This mode is selected by '-mno-shared'.
  
!      '-mno-shared' depends on binutils 2.16 or higher and generates
       objects that can only be linked by the GNU linker.  However, the
       option does not affect the ABI of the final executable; it only
!      affects the ABI of relocatable objects.  Using '-mno-shared'
       generally makes executables both smaller and quicker.
  
!      '-mshared' is the default.
  
! '-mplt'
! '-mno-plt'
       Assume (do not assume) that the static and dynamic linkers support
!      PLTs and copy relocations.  This option only affects '-mno-shared
!      -mabicalls'.  For the n64 ABI, this option has no effect without
!      '-msym32'.
  
!      You can make '-mplt' the default by configuring GCC with
!      '--with-mips-plt'.  The default is '-mno-plt' otherwise.
  
! '-mxgot'
! '-mno-xgot'
       Lift (do not lift) the usual restrictions on the size of the global
       offset table.
  
--- 24735,24963 ----
  3.19.28 MIPS Options
  --------------------
  
! ‘-EB’
       Generate big-endian code.
  
! ‘-EL’
!      Generate little-endian code.  This is the default for ‘mips*el-*-*’
       configurations.
  
! ‘-march=ARCH’
       Generate code that runs on ARCH, which can be the name of a generic
       MIPS ISA, or the name of a particular processor.  The ISA names
!      are: ‘mips1’, ‘mips2’, ‘mips3’, ‘mips4’, ‘mips32’, ‘mips32r2’,
!      ‘mips32r3’, ‘mips32r5’, ‘mips32r6’, ‘mips64’, ‘mips64r2’,
!      ‘mips64r3’, ‘mips64r5’ and ‘mips64r6’.  The processor names are:
!      ‘4kc’, ‘4km’, ‘4kp’, ‘4ksc’, ‘4kec’, ‘4kem’, ‘4kep’, ‘4ksd’, ‘5kc’,
!      ‘5kf’, ‘20kc’, ‘24kc’, ‘24kf2_1’, ‘24kf1_1’, ‘24kec’, ‘24kef2_1’,
!      ‘24kef1_1’, ‘34kc’, ‘34kf2_1’, ‘34kf1_1’, ‘34kn’, ‘74kc’,
!      ‘74kf2_1’, ‘74kf1_1’, ‘74kf3_2’, ‘1004kc’, ‘1004kf2_1’,
!      ‘1004kf1_1’, ‘i6400’, ‘i6500’, ‘interaptiv’, ‘loongson2e’,
!      ‘loongson2f’, ‘loongson3a’, ‘gs464’, ‘gs464e’, ‘gs264e’, ‘m4k’,
!      ‘m14k’, ‘m14kc’, ‘m14ke’, ‘m14kec’, ‘m5100’, ‘m5101’, ‘octeon’,
!      ‘octeon+’, ‘octeon2’, ‘octeon3’, ‘orion’, ‘p5600’, ‘p6600’,
!      ‘r2000’, ‘r3000’, ‘r3900’, ‘r4000’, ‘r4400’, ‘r4600’, ‘r4650’,
!      ‘r4700’, ‘r5900’, ‘r6000’, ‘r8000’, ‘rm7000’, ‘rm9000’, ‘r10000’,
!      ‘r12000’, ‘r14000’, ‘r16000’, ‘sb1’, ‘sr71000’, ‘vr4100’, ‘vr4111’,
!      ‘vr4120’, ‘vr4130’, ‘vr4300’, ‘vr5000’, ‘vr5400’, ‘vr5500’, ‘xlr’
!      and ‘xlp’.  The special value ‘from-abi’ selects the most
!      compatible architecture for the selected ABI (that is, ‘mips1’ for
!      32-bit ABIs and ‘mips3’ for 64-bit ABIs).
  
!      The native Linux/GNU toolchain also supports the value ‘native’,
       which selects the best architecture option for the host processor.
!      ‘-march=native’ has no effect if GCC does not recognize the
       processor.
  
!      In processor names, a final ‘000’ can be abbreviated as ‘k’ (for
!      example, ‘-march=r2k’).  Prefixes are optional, and ‘vr’ may be
!      written ‘r’.
  
!      Names of the form ‘Nf2_1’ refer to processors with FPUs clocked at
!      half the rate of the core, names of the form ‘Nf1_1’ refer to
       processors with FPUs clocked at the same rate as the core, and
!      names of the form ‘Nf3_2’ refer to processors with FPUs clocked a
       ratio of 3:2 with respect to the core.  For compatibility reasons,
!      ‘Nf’ is accepted as a synonym for ‘Nf2_1’ while ‘Nx’ and ‘Bfx’ are
!      accepted as synonyms for ‘Nf1_1’.
  
       GCC defines two macros based on the value of this option.  The
!      first is ‘_MIPS_ARCH’, which gives the name of target architecture,
!      as a string.  The second has the form ‘_MIPS_ARCH_FOO’, where FOO
!      is the capitalized value of ‘_MIPS_ARCH’.  For example,
!      ‘-march=r2000’ sets ‘_MIPS_ARCH’ to ‘"r2000"’ and defines the macro
!      ‘_MIPS_ARCH_R2000’.
  
!      Note that the ‘_MIPS_ARCH’ macro uses the processor names given
       above.  In other words, it has the full prefix and does not
!      abbreviate ‘000’ as ‘k’.  In the case of ‘from-abi’, the macro
!      names the resolved architecture (either ‘"mips1"’ or ‘"mips3"’).
!      It names the default architecture when no ‘-march’ option is given.
  
! ‘-mtune=ARCH’
       Optimize for ARCH.  Among other things, this option controls the
       way instructions are scheduled, and the perceived cost of
       arithmetic operations.  The list of ARCH values is the same as for
!      ‘-march’.
  
       When this option is not used, GCC optimizes for the processor
!      specified by ‘-march’.  By using ‘-march’ and ‘-mtune’ together, it
       is possible to generate code that runs on a family of processors,
       but optimize the code for one particular member of that family.
  
!      ‘-mtune’ defines the macros ‘_MIPS_TUNE’ and ‘_MIPS_TUNE_FOO’,
!      which work in the same way as the ‘-march’ ones described above.
  
! ‘-mips1’
!      Equivalent to ‘-march=mips1’.
  
! ‘-mips2’
!      Equivalent to ‘-march=mips2’.
  
! ‘-mips3’
!      Equivalent to ‘-march=mips3’.
  
! ‘-mips4’
!      Equivalent to ‘-march=mips4’.
  
! ‘-mips32’
!      Equivalent to ‘-march=mips32’.
  
! ‘-mips32r3’
!      Equivalent to ‘-march=mips32r3’.
  
! ‘-mips32r5’
!      Equivalent to ‘-march=mips32r5’.
  
! ‘-mips32r6’
!      Equivalent to ‘-march=mips32r6’.
  
! ‘-mips64’
!      Equivalent to ‘-march=mips64’.
  
! ‘-mips64r2’
!      Equivalent to ‘-march=mips64r2’.
  
! ‘-mips64r3’
!      Equivalent to ‘-march=mips64r3’.
  
! ‘-mips64r5’
!      Equivalent to ‘-march=mips64r5’.
  
! ‘-mips64r6’
!      Equivalent to ‘-march=mips64r6’.
  
! ‘-mips16’
! ‘-mno-mips16’
       Generate (do not generate) MIPS16 code.  If GCC is targeting a
       MIPS32 or MIPS64 architecture, it makes use of the MIPS16e ASE.
  
       MIPS16 code generation can also be controlled on a per-function
!      basis by means of ‘mips16’ and ‘nomips16’ attributes.  *Note
       Function Attributes::, for more information.
  
! ‘-mflip-mips16’
       Generate MIPS16 code on alternating functions.  This option is
       provided for regression testing of mixed MIPS16/non-MIPS16 code
       generation, and is not intended for ordinary use in compiling user
       code.
  
! ‘-minterlink-compressed’
! ‘-mno-interlink-compressed’
       Require (do not require) that code using the standard
       (uncompressed) MIPS ISA be link-compatible with MIPS16 and
       microMIPS code, and vice versa.
  
       For example, code using the standard ISA encoding cannot jump
       directly to MIPS16 or microMIPS code; it must either use a call or
!      an indirect jump.  ‘-minterlink-compressed’ therefore disables
       direct jumps unless GCC knows that the target of the jump is not
       compressed.
  
! ‘-minterlink-mips16’
! ‘-mno-interlink-mips16’
!      Aliases of ‘-minterlink-compressed’ and
!      ‘-mno-interlink-compressed’.  These options predate the microMIPS
       ASE and are retained for backwards compatibility.
  
! ‘-mabi=32’
! ‘-mabi=o64’
! ‘-mabi=n32’
! ‘-mabi=64’
! ‘-mabi=eabi’
       Generate code for the given ABI.
  
       Note that the EABI has a 32-bit and a 64-bit variant.  GCC normally
       generates 64-bit code when you select a 64-bit architecture, but
!      you can use ‘-mgp32’ to get 32-bit code instead.
  
       For information about the O64 ABI, see
       .
  
       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, MIPS32R3 and MIPS32R5 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 in
       that the even-numbered double-precision registers are saved.
  
       Two additional variants of the o32 ABI are supported to enable a
       transition from 32-bit to 64-bit registers.  These are FPXX
!      (‘-mfpxx’) and FP64A (‘-mfp64’ ‘-mno-odd-spreg’).  The FPXX
       extension mandates that all code must execute correctly when run
       using 32-bit or 64-bit registers.  The code can be interlinked with
       either FP32 or FP64, but not both.  The FP64A extension is similar
       to the FP64 extension but forbids the use of odd-numbered
       single-precision registers.  This can be used in conjunction with
!      the ‘FRE’ mode of FPUs in MIPS32R5 processors and allows both FP32
       and FP64A code to interlink and run in the same process without
       changing FPU modes.
  
! ‘-mabicalls’
! ‘-mno-abicalls’
       Generate (do not generate) code that is suitable for SVR4-style
!      dynamic objects.  ‘-mabicalls’ is the default for SVR4-based
       systems.
  
! ‘-mshared’
! ‘-mno-shared’
       Generate (do not generate) code that is fully position-independent,
       and that can therefore be linked into shared libraries.  This
!      option only affects ‘-mabicalls’.
  
!      All ‘-mabicalls’ code has traditionally been position-independent,
!      regardless of options like ‘-fPIC’ and ‘-fpic’.  However, as an
       extension, the GNU toolchain allows executables to use absolute
       accesses for locally-binding symbols.  It can also use shorter GP
       initialization sequences and generate direct calls to
!      locally-defined functions.  This mode is selected by ‘-mno-shared’.
  
!      ‘-mno-shared’ depends on binutils 2.16 or higher and generates
       objects that can only be linked by the GNU linker.  However, the
       option does not affect the ABI of the final executable; it only
!      affects the ABI of relocatable objects.  Using ‘-mno-shared’
       generally makes executables both smaller and quicker.
  
!      ‘-mshared’ is the default.
  
! ‘-mplt’
! ‘-mno-plt’
       Assume (do not assume) that the static and dynamic linkers support
!      PLTs and copy relocations.  This option only affects ‘-mno-shared
!      -mabicalls’.  For the n64 ABI, this option has no effect without
!      ‘-msym32’.
  
!      You can make ‘-mplt’ the default by configuring GCC with
!      ‘--with-mips-plt’.  The default is ‘-mno-plt’ otherwise.
  
! ‘-mxgot’
! ‘-mno-xgot’
       Lift (do not lift) the usual restrictions on the size of the global
       offset table.
  
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 24958,25262 ****
  
            relocation truncated to fit: R_MIPS_GOT16 foobar
  
!      If this happens, you should recompile your code with '-mxgot'.
       This works with very large GOTs, although the code is also less
       efficient, since it takes three instructions to fetch the value of
       a global symbol.
  
       Note that some linkers can create multiple GOTs.  If you have such
!      a linker, you should only need to use '-mxgot' when a single object
       file accesses more than 64k's worth of GOT entries.  Very few do.
  
       These options have no effect unless GCC is generating position
       independent code.
  
! '-mgp32'
       Assume that general-purpose registers are 32 bits wide.
  
! '-mgp64'
       Assume that general-purpose registers are 64 bits wide.
  
! '-mfp32'
       Assume that floating-point registers are 32 bits wide.
  
! '-mfp64'
       Assume that floating-point registers are 64 bits wide.
  
! '-mfpxx'
       Do not assume the width of floating-point registers.
  
! '-mhard-float'
       Use floating-point coprocessor instructions.
  
! '-msoft-float'
       Do not use floating-point coprocessor instructions.  Implement
       floating-point calculations using library calls instead.
  
! '-mno-float'
!      Equivalent to '-msoft-float', but additionally asserts that the
       program being compiled does not perform any floating-point
       operations.  This option is presently supported only by some
       bare-metal MIPS configurations, where it may select a special set
       of libraries that lack all floating-point support (including, for
!      example, the floating-point 'printf' formats).  If code compiled
!      with '-mno-float' accidentally contains floating-point operations,
       it is likely to suffer a link-time or run-time failure.
  
! '-msingle-float'
       Assume that the floating-point coprocessor only supports
       single-precision operations.
  
! '-mdouble-float'
       Assume that the floating-point coprocessor supports
       double-precision operations.  This is the default.
  
! '-modd-spreg'
! '-mno-odd-spreg'
       Enable the use of odd-numbered single-precision floating-point
       registers for the o32 ABI. This is the default for processors that
       are known to support these registers.  When using the o32 FPXX ABI,
!      '-mno-odd-spreg' is set by default.
  
! '-mabs=2008'
! '-mabs=legacy'
       These options control the treatment of the special not-a-number
!      (NaN) IEEE 754 floating-point data with the 'abs.fmt' and 'neg.fmt'
       machine instructions.
  
!      By default or when '-mabs=legacy' is used the legacy treatment is
       selected.  In this case these instructions are considered
       arithmetic and avoided where correct operation is required and the
       input operand might be a NaN. A longer sequence of instructions
       that manipulate the sign bit of floating-point datum manually is
!      used instead unless the '-ffinite-math-only' option has also been
       specified.
  
!      The '-mabs=2008' option selects the IEEE 754-2008 treatment.  In
       this case these instructions are considered non-arithmetic and
       therefore operating correctly in all cases, including in particular
       where the input operand is a NaN. These instructions are therefore
       always used for the respective operations.
  
! '-mnan=2008'
! '-mnan=legacy'
       These options control the encoding of the special not-a-number
       (NaN) IEEE 754 floating-point data.
  
!      The '-mnan=legacy' option selects the legacy encoding.  In this
       case quiet NaNs (qNaNs) are denoted by the first bit of their
       trailing significand field being 0, whereas signaling NaNs (sNaNs)
       are denoted by the first bit of their trailing significand field
       being 1.
  
!      The '-mnan=2008' option selects the IEEE 754-2008 encoding.  In
       this case qNaNs are denoted by the first bit of their trailing
       significand field being 1, whereas sNaNs are denoted by the first
       bit of their trailing significand field being 0.
  
!      The default is '-mnan=legacy' unless GCC has been configured with
!      '--with-nan=2008'.
  
! '-mllsc'
! '-mno-llsc'
!      Use (do not use) 'll', 'sc', and 'sync' instructions to implement
       atomic memory built-in functions.  When neither option is
       specified, GCC uses the instructions if the target architecture
       supports them.
  
!      '-mllsc' is useful if the runtime environment can emulate the
!      instructions and '-mno-llsc' can be useful when compiling for
       nonstandard ISAs.  You can make either option the default by
!      configuring GCC with '--with-llsc' and '--without-llsc'
!      respectively.  '--with-llsc' is the default for some
       configurations; see the installation documentation for details.
  
! '-mdsp'
! '-mno-dsp'
       Use (do not use) revision 1 of the MIPS DSP ASE.  *Note MIPS DSP
       Built-in Functions::.  This option defines the preprocessor macro
!      '__mips_dsp'.  It also defines '__mips_dsp_rev' to 1.
  
! '-mdspr2'
! '-mno-dspr2'
       Use (do not use) revision 2 of the MIPS DSP ASE.  *Note MIPS DSP
       Built-in Functions::.  This option defines the preprocessor macros
!      '__mips_dsp' and '__mips_dspr2'.  It also defines '__mips_dsp_rev'
       to 2.
  
! '-msmartmips'
! '-mno-smartmips'
       Use (do not use) the MIPS SmartMIPS ASE.
  
! '-mpaired-single'
! '-mno-paired-single'
       Use (do not use) paired-single floating-point instructions.  *Note
       MIPS Paired-Single Support::.  This option requires hardware
       floating-point support to be enabled.
  
! '-mdmx'
! '-mno-mdmx'
       Use (do not use) MIPS Digital Media Extension instructions.  This
       option can only be used when generating 64-bit code and requires
       hardware floating-point support to be enabled.
  
! '-mips3d'
! '-mno-mips3d'
       Use (do not use) the MIPS-3D ASE.  *Note MIPS-3D Built-in
!      Functions::.  The option '-mips3d' implies '-mpaired-single'.
  
! '-mmicromips'
! '-mno-micromips'
       Generate (do not generate) microMIPS code.
  
       MicroMIPS code generation can also be controlled on a per-function
!      basis by means of 'micromips' and 'nomicromips' attributes.  *Note
       Function Attributes::, for more information.
  
! '-mmt'
! '-mno-mt'
       Use (do not use) MT Multithreading instructions.
  
! '-mmcu'
! '-mno-mcu'
       Use (do not use) the MIPS MCU ASE instructions.
  
! '-meva'
! '-mno-eva'
       Use (do not use) the MIPS Enhanced Virtual Addressing instructions.
  
! '-mvirt'
! '-mno-virt'
       Use (do not use) the MIPS Virtualization (VZ) instructions.
  
! '-mxpa'
! '-mno-xpa'
       Use (do not use) the MIPS eXtended Physical Address (XPA)
       instructions.
  
! '-mcrc'
! '-mno-crc'
       Use (do not use) the MIPS Cyclic Redundancy Check (CRC)
       instructions.
  
! '-mginv'
! '-mno-ginv'
       Use (do not use) the MIPS Global INValidate (GINV) instructions.
  
! '-mloongson-mmi'
! '-mno-loongson-mmi'
       Use (do not use) the MIPS Loongson MultiMedia extensions
       Instructions (MMI).
  
! '-mloongson-ext'
! '-mno-loongson-ext'
       Use (do not use) the MIPS Loongson EXTensions (EXT) instructions.
  
! '-mloongson-ext2'
! '-mno-loongson-ext2'
       Use (do not use) the MIPS Loongson EXTensions r2 (EXT2)
       instructions.
  
! '-mlong64'
!      Force 'long' types to be 64 bits wide.  See '-mlong32' for an
       explanation of the default and the way that the pointer size is
       determined.
  
! '-mlong32'
!      Force 'long', 'int', and pointer types to be 32 bits wide.
  
!      The default size of 'int's, 'long's and pointers depends on the
!      ABI.  All the supported ABIs use 32-bit 'int's.  The n64 ABI uses
!      64-bit 'long's, as does the 64-bit EABI; the others use 32-bit
!      'long's.  Pointers are the same size as 'long's, or the same size
       as integer registers, whichever is smaller.
  
! '-msym32'
! '-mno-sym32'
       Assume (do not assume) that all symbols have 32-bit values,
       regardless of the selected ABI.  This option is useful in
!      combination with '-mabi=64' and '-mno-abicalls' because it allows
       GCC to generate shorter and faster references to symbolic
       addresses.
  
! '-G NUM'
       Put definitions of externally-visible data in a small data section
       if that data is no bigger than NUM bytes.  GCC can then generate
!      more efficient accesses to the data; see '-mgpopt' for details.
  
!      The default '-G' option depends on the configuration.
  
! '-mlocal-sdata'
! '-mno-local-sdata'
!      Extend (do not extend) the '-G' behavior to local data too, such as
!      to static variables in C.  '-mlocal-sdata' is the default for all
       configurations.
  
       If the linker complains that an application is using too much small
       data, you might want to try rebuilding the less
!      performance-critical parts with '-mno-local-sdata'.  You might also
!      want to build large libraries with '-mno-local-sdata', so that the
       libraries leave more room for the main program.
  
! '-mextern-sdata'
! '-mno-extern-sdata'
       Assume (do not assume) that externally-defined data is in a small
!      data section if the size of that data is within the '-G' limit.
!      '-mextern-sdata' is the default for all configurations.
  
!      If you compile a module MOD with '-mextern-sdata' '-G NUM'
!      '-mgpopt', and MOD references a variable VAR that is no bigger than
       NUM bytes, you must make sure that VAR is placed in a small data
       section.  If VAR is defined by another module, you must either
!      compile that module with a high-enough '-G' setting or attach a
!      'section' attribute to VAR's definition.  If VAR is common, you
!      must link the application with a high-enough '-G' setting.
  
       The easiest way of satisfying these restrictions is to compile and
!      link every module with the same '-G' option.  However, you may wish
       to build a library that supports several different small data
       limits.  You can do this by compiling the library with the highest
!      supported '-G' setting and additionally using '-mno-extern-sdata'
       to stop the library from making assumptions about
       externally-defined data.
  
! '-mgpopt'
! '-mno-gpopt'
       Use (do not use) GP-relative accesses for symbols that are known to
!      be in a small data section; see '-G', '-mlocal-sdata' and
!      '-mextern-sdata'.  '-mgpopt' is the default for all configurations.
  
!      '-mno-gpopt' is useful for cases where the '$gp' register might not
!      hold the value of '_gp'.  For example, if the code is part of a
       library that might be used in a boot monitor, programs that call
!      boot monitor routines pass an unknown value in '$gp'.  (In such
       situations, the boot monitor itself is usually compiled with
!      '-G0'.)
  
!      '-mno-gpopt' implies '-mno-local-sdata' and '-mno-extern-sdata'.
  
! '-membedded-data'
! '-mno-embedded-data'
       Allocate variables to the read-only data section first if possible,
       then next in the small data section if possible, otherwise in data.
       This gives slightly slower code than the default, but reduces the
       amount of RAM required when executing, and thus may be preferred
       for some embedded systems.
  
! '-muninit-const-in-rodata'
! '-mno-uninit-const-in-rodata'
!      Put uninitialized 'const' variables in the read-only data section.
       This option is only meaningful in conjunction with
!      '-membedded-data'.
  
! '-mcode-readable=SETTING'
       Specify whether GCC may generate code that reads from executable
       sections.  There are three possible settings:
  
!      '-mcode-readable=yes'
            Instructions may freely access executable sections.  This is
            the default setting.
  
!      '-mcode-readable=pcrel'
            MIPS16 PC-relative load instructions can access executable
            sections, but other instructions must not do so.  This option
            is useful on 4KSc and 4KSd processors when the code TLBs have
--- 24968,25272 ----
  
            relocation truncated to fit: R_MIPS_GOT16 foobar
  
!      If this happens, you should recompile your code with ‘-mxgot’.
       This works with very large GOTs, although the code is also less
       efficient, since it takes three instructions to fetch the value of
       a global symbol.
  
       Note that some linkers can create multiple GOTs.  If you have such
!      a linker, you should only need to use ‘-mxgot’ when a single object
       file accesses more than 64k's worth of GOT entries.  Very few do.
  
       These options have no effect unless GCC is generating position
       independent code.
  
! ‘-mgp32’
       Assume that general-purpose registers are 32 bits wide.
  
! ‘-mgp64’
       Assume that general-purpose registers are 64 bits wide.
  
! ‘-mfp32’
       Assume that floating-point registers are 32 bits wide.
  
! ‘-mfp64’
       Assume that floating-point registers are 64 bits wide.
  
! ‘-mfpxx’
       Do not assume the width of floating-point registers.
  
! ‘-mhard-float’
       Use floating-point coprocessor instructions.
  
! ‘-msoft-float’
       Do not use floating-point coprocessor instructions.  Implement
       floating-point calculations using library calls instead.
  
! ‘-mno-float’
!      Equivalent to ‘-msoft-float’, but additionally asserts that the
       program being compiled does not perform any floating-point
       operations.  This option is presently supported only by some
       bare-metal MIPS configurations, where it may select a special set
       of libraries that lack all floating-point support (including, for
!      example, the floating-point ‘printf’ formats).  If code compiled
!      with ‘-mno-float’ accidentally contains floating-point operations,
       it is likely to suffer a link-time or run-time failure.
  
! ‘-msingle-float’
       Assume that the floating-point coprocessor only supports
       single-precision operations.
  
! ‘-mdouble-float’
       Assume that the floating-point coprocessor supports
       double-precision operations.  This is the default.
  
! ‘-modd-spreg’
! ‘-mno-odd-spreg’
       Enable the use of odd-numbered single-precision floating-point
       registers for the o32 ABI. This is the default for processors that
       are known to support these registers.  When using the o32 FPXX ABI,
!      ‘-mno-odd-spreg’ is set by default.
  
! ‘-mabs=2008’
! ‘-mabs=legacy’
       These options control the treatment of the special not-a-number
!      (NaN) IEEE 754 floating-point data with the ‘abs.fmt’ and ‘neg.fmt’
       machine instructions.
  
!      By default or when ‘-mabs=legacy’ is used the legacy treatment is
       selected.  In this case these instructions are considered
       arithmetic and avoided where correct operation is required and the
       input operand might be a NaN. A longer sequence of instructions
       that manipulate the sign bit of floating-point datum manually is
!      used instead unless the ‘-ffinite-math-only’ option has also been
       specified.
  
!      The ‘-mabs=2008’ option selects the IEEE 754-2008 treatment.  In
       this case these instructions are considered non-arithmetic and
       therefore operating correctly in all cases, including in particular
       where the input operand is a NaN. These instructions are therefore
       always used for the respective operations.
  
! ‘-mnan=2008’
! ‘-mnan=legacy’
       These options control the encoding of the special not-a-number
       (NaN) IEEE 754 floating-point data.
  
!      The ‘-mnan=legacy’ option selects the legacy encoding.  In this
       case quiet NaNs (qNaNs) are denoted by the first bit of their
       trailing significand field being 0, whereas signaling NaNs (sNaNs)
       are denoted by the first bit of their trailing significand field
       being 1.
  
!      The ‘-mnan=2008’ option selects the IEEE 754-2008 encoding.  In
       this case qNaNs are denoted by the first bit of their trailing
       significand field being 1, whereas sNaNs are denoted by the first
       bit of their trailing significand field being 0.
  
!      The default is ‘-mnan=legacy’ unless GCC has been configured with
!      ‘--with-nan=2008’.
  
! ‘-mllsc’
! ‘-mno-llsc’
!      Use (do not use) ‘ll’, ‘sc’, and ‘sync’ instructions to implement
       atomic memory built-in functions.  When neither option is
       specified, GCC uses the instructions if the target architecture
       supports them.
  
!      ‘-mllsc’ is useful if the runtime environment can emulate the
!      instructions and ‘-mno-llsc’ can be useful when compiling for
       nonstandard ISAs.  You can make either option the default by
!      configuring GCC with ‘--with-llsc’ and ‘--without-llsc’
!      respectively.  ‘--with-llsc’ is the default for some
       configurations; see the installation documentation for details.
  
! ‘-mdsp’
! ‘-mno-dsp’
       Use (do not use) revision 1 of the MIPS DSP ASE.  *Note MIPS DSP
       Built-in Functions::.  This option defines the preprocessor macro
!      ‘__mips_dsp’.  It also defines ‘__mips_dsp_rev’ to 1.
  
! ‘-mdspr2’
! ‘-mno-dspr2’
       Use (do not use) revision 2 of the MIPS DSP ASE.  *Note MIPS DSP
       Built-in Functions::.  This option defines the preprocessor macros
!      ‘__mips_dsp’ and ‘__mips_dspr2’.  It also defines ‘__mips_dsp_rev’
       to 2.
  
! ‘-msmartmips’
! ‘-mno-smartmips’
       Use (do not use) the MIPS SmartMIPS ASE.
  
! ‘-mpaired-single’
! ‘-mno-paired-single’
       Use (do not use) paired-single floating-point instructions.  *Note
       MIPS Paired-Single Support::.  This option requires hardware
       floating-point support to be enabled.
  
! ‘-mdmx’
! ‘-mno-mdmx’
       Use (do not use) MIPS Digital Media Extension instructions.  This
       option can only be used when generating 64-bit code and requires
       hardware floating-point support to be enabled.
  
! ‘-mips3d’
! ‘-mno-mips3d’
       Use (do not use) the MIPS-3D ASE.  *Note MIPS-3D Built-in
!      Functions::.  The option ‘-mips3d’ implies ‘-mpaired-single’.
  
! ‘-mmicromips’
! ‘-mno-micromips’
       Generate (do not generate) microMIPS code.
  
       MicroMIPS code generation can also be controlled on a per-function
!      basis by means of ‘micromips’ and ‘nomicromips’ attributes.  *Note
       Function Attributes::, for more information.
  
! ‘-mmt’
! ‘-mno-mt’
       Use (do not use) MT Multithreading instructions.
  
! ‘-mmcu’
! ‘-mno-mcu’
       Use (do not use) the MIPS MCU ASE instructions.
  
! ‘-meva’
! ‘-mno-eva’
       Use (do not use) the MIPS Enhanced Virtual Addressing instructions.
  
! ‘-mvirt’
! ‘-mno-virt’
       Use (do not use) the MIPS Virtualization (VZ) instructions.
  
! ‘-mxpa’
! ‘-mno-xpa’
       Use (do not use) the MIPS eXtended Physical Address (XPA)
       instructions.
  
! ‘-mcrc’
! ‘-mno-crc’
       Use (do not use) the MIPS Cyclic Redundancy Check (CRC)
       instructions.
  
! ‘-mginv’
! ‘-mno-ginv’
       Use (do not use) the MIPS Global INValidate (GINV) instructions.
  
! ‘-mloongson-mmi’
! ‘-mno-loongson-mmi’
       Use (do not use) the MIPS Loongson MultiMedia extensions
       Instructions (MMI).
  
! ‘-mloongson-ext’
! ‘-mno-loongson-ext’
       Use (do not use) the MIPS Loongson EXTensions (EXT) instructions.
  
! ‘-mloongson-ext2’
! ‘-mno-loongson-ext2’
       Use (do not use) the MIPS Loongson EXTensions r2 (EXT2)
       instructions.
  
! ‘-mlong64’
!      Force ‘long’ types to be 64 bits wide.  See ‘-mlong32’ for an
       explanation of the default and the way that the pointer size is
       determined.
  
! ‘-mlong32’
!      Force ‘long’, ‘int’, and pointer types to be 32 bits wide.
  
!      The default size of ‘int’s, ‘long’s and pointers depends on the
!      ABI.  All the supported ABIs use 32-bit ‘int’s.  The n64 ABI uses
!      64-bit ‘long’s, as does the 64-bit EABI; the others use 32-bit
!      ‘long’s.  Pointers are the same size as ‘long’s, or the same size
       as integer registers, whichever is smaller.
  
! ‘-msym32’
! ‘-mno-sym32’
       Assume (do not assume) that all symbols have 32-bit values,
       regardless of the selected ABI.  This option is useful in
!      combination with ‘-mabi=64’ and ‘-mno-abicalls’ because it allows
       GCC to generate shorter and faster references to symbolic
       addresses.
  
! ‘-G NUM’
       Put definitions of externally-visible data in a small data section
       if that data is no bigger than NUM bytes.  GCC can then generate
!      more efficient accesses to the data; see ‘-mgpopt’ for details.
  
!      The default ‘-G’ option depends on the configuration.
  
! ‘-mlocal-sdata’
! ‘-mno-local-sdata’
!      Extend (do not extend) the ‘-G’ behavior to local data too, such as
!      to static variables in C.  ‘-mlocal-sdata’ is the default for all
       configurations.
  
       If the linker complains that an application is using too much small
       data, you might want to try rebuilding the less
!      performance-critical parts with ‘-mno-local-sdata’.  You might also
!      want to build large libraries with ‘-mno-local-sdata’, so that the
       libraries leave more room for the main program.
  
! ‘-mextern-sdata’
! ‘-mno-extern-sdata’
       Assume (do not assume) that externally-defined data is in a small
!      data section if the size of that data is within the ‘-G’ limit.
!      ‘-mextern-sdata’ is the default for all configurations.
  
!      If you compile a module MOD with ‘-mextern-sdata’ ‘-G NUM’
!      ‘-mgpopt’, and MOD references a variable VAR that is no bigger than
       NUM bytes, you must make sure that VAR is placed in a small data
       section.  If VAR is defined by another module, you must either
!      compile that module with a high-enough ‘-G’ setting or attach a
!      ‘section’ attribute to VAR's definition.  If VAR is common, you
!      must link the application with a high-enough ‘-G’ setting.
  
       The easiest way of satisfying these restrictions is to compile and
!      link every module with the same ‘-G’ option.  However, you may wish
       to build a library that supports several different small data
       limits.  You can do this by compiling the library with the highest
!      supported ‘-G’ setting and additionally using ‘-mno-extern-sdata’
       to stop the library from making assumptions about
       externally-defined data.
  
! ‘-mgpopt’
! ‘-mno-gpopt’
       Use (do not use) GP-relative accesses for symbols that are known to
!      be in a small data section; see ‘-G’, ‘-mlocal-sdata’ and
!      ‘-mextern-sdata’.  ‘-mgpopt’ is the default for all configurations.
  
!      ‘-mno-gpopt’ is useful for cases where the ‘$gp’ register might not
!      hold the value of ‘_gp’.  For example, if the code is part of a
       library that might be used in a boot monitor, programs that call
!      boot monitor routines pass an unknown value in ‘$gp’.  (In such
       situations, the boot monitor itself is usually compiled with
!      ‘-G0’.)
  
!      ‘-mno-gpopt’ implies ‘-mno-local-sdata’ and ‘-mno-extern-sdata’.
  
! ‘-membedded-data’
! ‘-mno-embedded-data’
       Allocate variables to the read-only data section first if possible,
       then next in the small data section if possible, otherwise in data.
       This gives slightly slower code than the default, but reduces the
       amount of RAM required when executing, and thus may be preferred
       for some embedded systems.
  
! ‘-muninit-const-in-rodata’
! ‘-mno-uninit-const-in-rodata’
!      Put uninitialized ‘const’ variables in the read-only data section.
       This option is only meaningful in conjunction with
!      ‘-membedded-data’.
  
! ‘-mcode-readable=SETTING’
       Specify whether GCC may generate code that reads from executable
       sections.  There are three possible settings:
  
!      ‘-mcode-readable=yes’
            Instructions may freely access executable sections.  This is
            the default setting.
  
!      ‘-mcode-readable=pcrel’
            MIPS16 PC-relative load instructions can access executable
            sections, but other instructions must not do so.  This option
            is useful on 4KSc and 4KSd processors when the code TLBs have
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 25265,25357 ****
            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'.
  
! '-mload-store-pairs'
! '-mno-load-store-pairs'
       Enable (disable) an optimization that pairs consecutive load or
       store instructions to enable load/store bonding.  This option is
       enabled by default but only takes effect when the selected
       architecture is known to support bonding.
  
! '-munaligned-access'
! '-mno-unaligned-access'
       Enable (disable) direct unaligned access for MIPS Release 6.
       MIPSr6 requires load/store unaligned-access support, by hardware or
!      trap&emulate.  So '-mno-unaligned-access' may be needed by kernel.
  
! '-mmemcpy'
! '-mno-memcpy'
!      Force (do not force) the use of 'memcpy' for non-trivial block
!      moves.  The default is '-mno-memcpy', which allows GCC to inline
       most constant-sized copies.
  
! '-mlong-calls'
! '-mno-long-calls'
!      Disable (do not disable) use of the 'jal' instruction.  Calling
!      functions using 'jal' is more efficient but requires the caller and
       callee to be in the same 256 megabyte segment.
  
       This option has no effect on abicalls code.  The default is
!      '-mno-long-calls'.
  
! '-mmad'
! '-mno-mad'
!      Enable (disable) use of the 'mad', 'madu' and 'mul' instructions,
       as provided by the R4650 ISA.
  
! '-mimadd'
! '-mno-imadd'
!      Enable (disable) use of the 'madd' and 'msub' integer instructions.
!      The default is '-mimadd' on architectures that support 'madd' and
!      'msub' except for the 74k architecture where it was found to
       generate slower code.
  
! '-mfused-madd'
! '-mno-fused-madd'
       Enable (disable) use of the floating-point multiply-accumulate
       instructions, when they are available.  The default is
!      '-mfused-madd'.
  
       On the R8000 CPU when multiply-accumulate instructions are used,
       the intermediate product is calculated to infinite precision and is
--- 25275,25367 ----
            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’.
  
! ‘-mload-store-pairs’
! ‘-mno-load-store-pairs’
       Enable (disable) an optimization that pairs consecutive load or
       store instructions to enable load/store bonding.  This option is
       enabled by default but only takes effect when the selected
       architecture is known to support bonding.
  
! ‘-munaligned-access’
! ‘-mno-unaligned-access’
       Enable (disable) direct unaligned access for MIPS Release 6.
       MIPSr6 requires load/store unaligned-access support, by hardware or
!      trap&emulate.  So ‘-mno-unaligned-access’ may be needed by kernel.
  
! ‘-mmemcpy’
! ‘-mno-memcpy’
!      Force (do not force) the use of ‘memcpy’ for non-trivial block
!      moves.  The default is ‘-mno-memcpy’, which allows GCC to inline
       most constant-sized copies.
  
! ‘-mlong-calls’
! ‘-mno-long-calls’
!      Disable (do not disable) use of the ‘jal’ instruction.  Calling
!      functions using ‘jal’ is more efficient but requires the caller and
       callee to be in the same 256 megabyte segment.
  
       This option has no effect on abicalls code.  The default is
!      ‘-mno-long-calls’.
  
! ‘-mmad’
! ‘-mno-mad’
!      Enable (disable) use of the ‘mad’, ‘madu’ and ‘mul’ instructions,
       as provided by the R4650 ISA.
  
! ‘-mimadd’
! ‘-mno-imadd’
!      Enable (disable) use of the ‘madd’ and ‘msub’ integer instructions.
!      The default is ‘-mimadd’ on architectures that support ‘madd’ and
!      ‘msub’ except for the 74k architecture where it was found to
       generate slower code.
  
! ‘-mfused-madd’
! ‘-mno-fused-madd’
       Enable (disable) use of the floating-point multiply-accumulate
       instructions, when they are available.  The default is
!      ‘-mfused-madd’.
  
       On the R8000 CPU when multiply-accumulate instructions are used,
       the intermediate product is calculated to infinite precision and is
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 25360,25444 ****
       numerically identical to the equivalent computation using separate
       multiply, add, subtract and negate instructions.
  
! '-nocpp'
       Tell the MIPS assembler to not run its preprocessor over user
!      assembler files (with a '.s' suffix) when assembling them.
  
! '-mfix-24k'
! '-mno-fix-24k'
       Work around the 24K E48 (lost data on stores during refill) errata.
       The workarounds are implemented by the assembler rather than by
       GCC.
  
! '-mfix-r4000'
! '-mno-fix-r4000'
       Work around certain R4000 CPU errata:
!         - A double-word or a variable shift may give an incorrect result
            if executed immediately after starting an integer division.
!         - A double-word or a variable shift may give an incorrect result
            if executed while an integer multiplication is in progress.
!         - An integer division may give an incorrect result if started in
            a delay slot of a taken branch or a jump.
  
! '-mfix-r4400'
! '-mno-fix-r4400'
       Work around certain R4400 CPU errata:
!         - A double-word or a variable shift may give an incorrect result
            if executed immediately after starting an integer division.
  
! '-mfix-r10000'
! '-mno-fix-r10000'
       Work around certain R10000 errata:
!         - 'll'/'sc' sequences may not behave atomically on revisions
            prior to 3.0.  They may deadlock on revisions 2.6 and earlier.
  
       This option can only be used if the target architecture supports
!      branch-likely instructions.  '-mfix-r10000' is the default when
!      '-march=r10000' is used; '-mno-fix-r10000' is the default
       otherwise.
  
! '-mfix-r5900'
! '-mno-fix-r5900'
       Do not attempt to schedule the preceding instruction into the delay
       slot of a branch instruction placed at the end of a short loop of
!      six instructions or fewer and always schedule a 'nop' instruction
       there instead.  The short loop bug under certain conditions causes
       loops to execute only once or twice, due to a hardware bug in the
       R5900 chip.  The workaround is implemented by the assembler rather
       than by GCC.
  
! '-mfix-rm7000'
! '-mno-fix-rm7000'
!      Work around the RM7000 'dmult'/'dmultu' errata.  The workarounds
       are implemented by the assembler rather than by GCC.
  
! '-mfix-vr4120'
! '-mno-fix-vr4120'
       Work around certain VR4120 errata:
!         - 'dmultu' does not always produce the correct result.
!         - 'div' and 'ddiv' do not always produce the correct result if
            one of the operands is negative.
       The workarounds for the division errata rely on special functions
!      in 'libgcc.a'.  At present, these functions are only provided by
!      the 'mips64vr*-elf' configurations.
  
       Other VR4120 errata require a NOP to be inserted between certain
       pairs of instructions.  These errata are handled by the assembler,
       not by GCC itself.
  
! '-mfix-vr4130'
!      Work around the VR4130 'mflo'/'mfhi' errata.  The workarounds are
       implemented by the assembler rather than by GCC, although GCC
!      avoids using 'mflo' and 'mfhi' if the VR4130 'macc', 'macchi',
!      'dmacc' and 'dmacchi' instructions are available instead.
  
! '-mfix-sb1'
! '-mno-fix-sb1'
       Work around certain SB-1 CPU core errata.  (This flag currently
       works around the SB-1 revision 2 "F1" and "F2" floating-point
       errata.)
  
! '-mr10k-cache-barrier=SETTING'
       Specify whether GCC should insert cache barriers to avoid the side
       effects of speculation on R10K processors.
  
--- 25370,25454 ----
       numerically identical to the equivalent computation using separate
       multiply, add, subtract and negate instructions.
  
! ‘-nocpp’
       Tell the MIPS assembler to not run its preprocessor over user
!      assembler files (with a ‘.s’ suffix) when assembling them.
  
! ‘-mfix-24k’
! ‘-mno-fix-24k’
       Work around the 24K E48 (lost data on stores during refill) errata.
       The workarounds are implemented by the assembler rather than by
       GCC.
  
! ‘-mfix-r4000’
! ‘-mno-fix-r4000’
       Work around certain R4000 CPU errata:
!         − A double-word or a variable shift may give an incorrect result
            if executed immediately after starting an integer division.
!         − A double-word or a variable shift may give an incorrect result
            if executed while an integer multiplication is in progress.
!         − An integer division may give an incorrect result if started in
            a delay slot of a taken branch or a jump.
  
! ‘-mfix-r4400’
! ‘-mno-fix-r4400’
       Work around certain R4400 CPU errata:
!         − A double-word or a variable shift may give an incorrect result
            if executed immediately after starting an integer division.
  
! ‘-mfix-r10000’
! ‘-mno-fix-r10000’
       Work around certain R10000 errata:
!         − ‘ll’/‘sc’ sequences may not behave atomically on revisions
            prior to 3.0.  They may deadlock on revisions 2.6 and earlier.
  
       This option can only be used if the target architecture supports
!      branch-likely instructions.  ‘-mfix-r10000’ is the default when
!      ‘-march=r10000’ is used; ‘-mno-fix-r10000’ is the default
       otherwise.
  
! ‘-mfix-r5900’
! ‘-mno-fix-r5900’
       Do not attempt to schedule the preceding instruction into the delay
       slot of a branch instruction placed at the end of a short loop of
!      six instructions or fewer and always schedule a ‘nop’ instruction
       there instead.  The short loop bug under certain conditions causes
       loops to execute only once or twice, due to a hardware bug in the
       R5900 chip.  The workaround is implemented by the assembler rather
       than by GCC.
  
! ‘-mfix-rm7000’
! ‘-mno-fix-rm7000’
!      Work around the RM7000 ‘dmult’/‘dmultu’ errata.  The workarounds
       are implemented by the assembler rather than by GCC.
  
! ‘-mfix-vr4120’
! ‘-mno-fix-vr4120’
       Work around certain VR4120 errata:
!         − ‘dmultu’ does not always produce the correct result.
!         − ‘div’ and ‘ddiv’ do not always produce the correct result if
            one of the operands is negative.
       The workarounds for the division errata rely on special functions
!      in ‘libgcc.a’.  At present, these functions are only provided by
!      the ‘mips64vr*-elf’ configurations.
  
       Other VR4120 errata require a NOP to be inserted between certain
       pairs of instructions.  These errata are handled by the assembler,
       not by GCC itself.
  
! ‘-mfix-vr4130’
!      Work around the VR4130 ‘mflo’/‘mfhi’ errata.  The workarounds are
       implemented by the assembler rather than by GCC, although GCC
!      avoids using ‘mflo’ and ‘mfhi’ if the VR4130 ‘macc’, ‘macchi’,
!      ‘dmacc’ and ‘dmacchi’ instructions are available instead.
  
! ‘-mfix-sb1’
! ‘-mno-fix-sb1’
       Work around certain SB-1 CPU core errata.  (This flag currently
       works around the SB-1 revision 2 "F1" and "F2" floating-point
       errata.)
  
! ‘-mr10k-cache-barrier=SETTING’
       Specify whether GCC should insert cache barriers to avoid the side
       effects of speculation on R10K processors.
  
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 25459,25465 ****
  
       One workaround is to insert cache barrier instructions before every
       memory access that might be speculatively executed and that might
!      have side effects even if aborted.  '-mr10k-cache-barrier=SETTING'
       controls GCC's implementation of this workaround.  It assumes that
       aborted accesses to any byte in the following regions does not have
       side effects:
--- 25469,25475 ----
  
       One workaround is to insert cache barrier instructions before every
       memory access that might be speculatively executed and that might
!      have side effects even if aborted.  ‘-mr10k-cache-barrier=SETTING’
       controls GCC's implementation of this workaround.  It assumes that
       aborted accesses to any byte in the following regions does not have
       side effects:
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 25478,25522 ****
  
            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
--- 25488,25532 ----
  
            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
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 25526,25541 ****
       default because the MIPS32 and MIPS64 architectures specifically
       deprecate their use.
  
! '-mcompact-branches=never'
! '-mcompact-branches=optimal'
! '-mcompact-branches=always'
       These options control which form of branches will be generated.
!      The default is '-mcompact-branches=optimal'.
  
!      The '-mcompact-branches=never' option ensures that compact branch
       instructions will never be generated.
  
!      The '-mcompact-branches=always' option ensures that a compact
       branch instruction will be generated if available for MIPS Release
       6 onwards.  If a compact branch instruction is not available (or
       pre-R6), a delay slot form of the branch will be used instead.
--- 25536,25551 ----
       default because the MIPS32 and MIPS64 architectures specifically
       deprecate their use.
  
! ‘-mcompact-branches=never’
! ‘-mcompact-branches=optimal’
! ‘-mcompact-branches=always’
       These options control which form of branches will be generated.
!      The default is ‘-mcompact-branches=optimal’.
  
!      The ‘-mcompact-branches=never’ option ensures that compact branch
       instructions will never be generated.
  
!      The ‘-mcompact-branches=always’ option ensures that a compact
       branch instruction will be generated if available for MIPS Release
       6 onwards.  If a compact branch instruction is not available (or
       pre-R6), a delay slot form of the branch will be used instead.
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 25544,25556 ****
       now.  The behaviour for MIPS16/microMIPS may change in future,
       since they do have some compact branch instructions.
  
!      The '-mcompact-branches=optimal' option will cause a delay slot
       branch to be used if one is available in the current ISA and the
       delay slot is successfully filled.  If the delay slot is not
       filled, a compact branch will be chosen if one is available.
  
! '-mfp-exceptions'
! '-mno-fp-exceptions'
       Specifies whether FP exceptions are enabled.  This affects how FP
       instructions are scheduled for some processors.  The default is
       that FP exceptions are enabled.
--- 25554,25566 ----
       now.  The behaviour for MIPS16/microMIPS may change in future,
       since they do have some compact branch instructions.
  
!      The ‘-mcompact-branches=optimal’ option will cause a delay slot
       branch to be used if one is available in the current ISA and the
       delay slot is successfully filled.  If the delay slot is not
       filled, a compact branch will be chosen if one is available.
  
! ‘-mfp-exceptions’
! ‘-mno-fp-exceptions’
       Specifies whether FP exceptions are enabled.  This affects how FP
       instructions are scheduled for some processors.  The default is
       that FP exceptions are enabled.
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 25559,25566 ****
       are emitting 64-bit code, then we can use both FP pipes.
       Otherwise, we can only use one FP pipe.
  
! '-mvr4130-align'
! '-mno-vr4130-align'
       The VR4130 pipeline is two-way superscalar, but can only issue two
       instructions together if the first one is 8-byte aligned.  When
       this option is enabled, GCC aligns pairs of instructions that it
--- 25569,25576 ----
       are emitting 64-bit code, then we can use both FP pipes.
       Otherwise, we can only use one FP pipe.
  
! ‘-mvr4130-align’
! ‘-mno-vr4130-align’
       The VR4130 pipeline is two-way superscalar, but can only issue two
       instructions together if the first one is 8-byte aligned.  When
       this option is enabled, GCC aligns pairs of instructions that it
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 25568,25617 ****
  
       This option only has an effect when optimizing for the VR4130.  It
       normally makes code faster, but at the expense of making it bigger.
!      It is enabled by default at optimization level '-O3'.
  
! '-msynci'
! '-mno-synci'
!      Enable (disable) generation of 'synci' instructions on
!      architectures that support it.  The 'synci' instructions (if
!      enabled) are generated when '__builtin___clear_cache' is compiled.
  
!      This option defaults to '-mno-synci', but the default can be
!      overridden by configuring GCC with '--with-synci'.
  
       When compiling code for single processor systems, it is generally
!      safe to use 'synci'.  However, on many multi-core (SMP) systems, it
       does not invalidate the instruction caches on all cores and may
       lead to undefined behavior.
  
! '-mrelax-pic-calls'
! '-mno-relax-pic-calls'
       Try to turn PIC calls that are normally dispatched via register
!      '$25' into direct calls.  This is only possible if the linker can
       resolve the destination at link time and if the destination is
       within range for a direct call.
  
!      '-mrelax-pic-calls' is the default if GCC was configured to use an
!      assembler and a linker that support the '.reloc' assembly directive
!      and '-mexplicit-relocs' is in effect.  With '-mno-explicit-relocs',
       this optimization can be performed by the assembler and the linker
       alone without help from the compiler.
  
! '-mmcount-ra-address'
! '-mno-mcount-ra-address'
!      Emit (do not emit) code that allows '_mcount' to modify the calling
       function's return address.  When enabled, this option extends the
!      usual '_mcount' interface with a new RA-ADDRESS parameter, which
!      has type 'intptr_t *' and is passed in register '$12'.  '_mcount'
       can then modify the return address by doing both of the following:
!         * Returning the new address in register '$31'.
!         * Storing the new address in '*RA-ADDRESS', if RA-ADDRESS is
            nonnull.
  
!      The default is '-mno-mcount-ra-address'.
  
! '-mframe-header-opt'
! '-mno-frame-header-opt'
       Enable (disable) frame header optimization in the o32 ABI. When
       using the o32 ABI, calling functions will allocate 16 bytes on the
       stack for the called function to write out register arguments.
--- 25578,25627 ----
  
       This option only has an effect when optimizing for the VR4130.  It
       normally makes code faster, but at the expense of making it bigger.
!      It is enabled by default at optimization level ‘-O3’.
  
! ‘-msynci’
! ‘-mno-synci’
!      Enable (disable) generation of ‘synci’ instructions on
!      architectures that support it.  The ‘synci’ instructions (if
!      enabled) are generated when ‘__builtin___clear_cache’ is compiled.
  
!      This option defaults to ‘-mno-synci’, but the default can be
!      overridden by configuring GCC with ‘--with-synci’.
  
       When compiling code for single processor systems, it is generally
!      safe to use ‘synci’.  However, on many multi-core (SMP) systems, it
       does not invalidate the instruction caches on all cores and may
       lead to undefined behavior.
  
! ‘-mrelax-pic-calls’
! ‘-mno-relax-pic-calls’
       Try to turn PIC calls that are normally dispatched via register
!      ‘$25’ into direct calls.  This is only possible if the linker can
       resolve the destination at link time and if the destination is
       within range for a direct call.
  
!      ‘-mrelax-pic-calls’ is the default if GCC was configured to use an
!      assembler and a linker that support the ‘.reloc’ assembly directive
!      and ‘-mexplicit-relocs’ is in effect.  With ‘-mno-explicit-relocs’,
       this optimization can be performed by the assembler and the linker
       alone without help from the compiler.
  
! ‘-mmcount-ra-address’
! ‘-mno-mcount-ra-address’
!      Emit (do not emit) code that allows ‘_mcount’ to modify the calling
       function's return address.  When enabled, this option extends the
!      usual ‘_mcount’ interface with a new RA-ADDRESS parameter, which
!      has type ‘intptr_t *’ and is passed in register ‘$12’.  ‘_mcount’
       can then modify the return address by doing both of the following:
!         • Returning the new address in register ‘$31’.
!         • Storing the new address in ‘*RA-ADDRESS’, if RA-ADDRESS is
            nonnull.
  
!      The default is ‘-mno-mcount-ra-address’.
  
! ‘-mframe-header-opt’
! ‘-mno-frame-header-opt’
       Enable (disable) frame header optimization in the o32 ABI. When
       using the o32 ABI, calling functions will allocate 16 bytes on the
       stack for the called function to write out register arguments.
*************** File: gcc.info,  Node: MIPS Options,  Ne
*** 25620,25634 ****
  
       This optimization is off by default at all optimization levels.
  
! '-mlxc1-sxc1'
! '-mno-lxc1-sxc1'
!      When applicable, enable (disable) the generation of 'lwxc1',
!      'swxc1', 'ldxc1', 'sdxc1' instructions.  Enabled by default.
  
! '-mmadd4'
! '-mno-madd4'
       When applicable, enable (disable) the generation of 4-operand
!      'madd.s', 'madd.d' and related instructions.  Enabled by default.
  
  
  File: gcc.info,  Node: MMIX Options,  Next: MN10300 Options,  Prev: MIPS Options,  Up: Submodel Options
--- 25630,25644 ----
  
       This optimization is off by default at all optimization levels.
  
! ‘-mlxc1-sxc1’
! ‘-mno-lxc1-sxc1’
!      When applicable, enable (disable) the generation of ‘lwxc1’,
!      ‘swxc1’, ‘ldxc1’, ‘sdxc1’ instructions.  Enabled by default.
  
! ‘-mmadd4’
! ‘-mno-madd4’
       When applicable, enable (disable) the generation of 4-operand
!      ‘madd.s’, ‘madd.d’ and related instructions.  Enabled by default.
  
  
  File: gcc.info,  Node: MMIX Options,  Next: MN10300 Options,  Prev: MIPS Options,  Up: Submodel Options
*************** File: gcc.info,  Node: MMIX Options,  Ne
*** 25638,25688 ****
  
  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
--- 25648,25698 ----
  
  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
*************** These options are defined for the MMIX:
*** 25691,25700 ****
       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.
  
--- 25701,25710 ----
       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,
*** 25704,25749 ****
  3.19.30 MN10300 Options
  -----------------------
  
! These '-m' options are defined for Matsushita MN10300 architectures:
  
! '-mmult-bug'
       Generate code to avoid bugs in the multiply instructions for the
       MN10300 processors.  This is the default.
  
! '-mno-mult-bug'
       Do not generate code to avoid bugs in the multiply instructions for
       the MN10300 processors.
  
! '-mam33'
       Generate code using features specific to the AM33 processor.
  
! '-mno-am33'
       Do not generate code using features specific to the AM33 processor.
       This is the default.
  
! '-mam33-2'
       Generate code using features specific to the AM33/2.0 processor.
  
! '-mam34'
       Generate code using features specific to the AM34 processor.
  
! '-mtune=CPU-TYPE'
       Use the timing characteristics of the indicated CPU type when
       scheduling instructions.  This does not change the targeted
!      processor type.  The CPU type must be one of 'mn10300', 'am33',
!      'am33-2' or 'am34'.
  
! '-mreturn-pointer-on-d0'
       When generating a function that returns a pointer, return the
!      pointer in both 'a0' and 'd0'.  Otherwise, the pointer is returned
!      only in 'a0', and attempts to call such functions without a
       prototype result in errors.  Note that this option is on by
!      default; use '-mno-return-pointer-on-d0' to disable it.
  
! '-mno-crt0'
       Do not link in the C run-time initialization object file.
  
! '-mrelax'
       Indicate to the linker that it should perform a relaxation
       optimization pass to shorten branches, calls and absolute memory
       addresses.  This option only has an effect when used on the command
--- 25714,25759 ----
  3.19.30 MN10300 Options
  -----------------------
  
! These ‘-m’ options are defined for Matsushita MN10300 architectures:
  
! ‘-mmult-bug’
       Generate code to avoid bugs in the multiply instructions for the
       MN10300 processors.  This is the default.
  
! ‘-mno-mult-bug’
       Do not generate code to avoid bugs in the multiply instructions for
       the MN10300 processors.
  
! ‘-mam33’
       Generate code using features specific to the AM33 processor.
  
! ‘-mno-am33’
       Do not generate code using features specific to the AM33 processor.
       This is the default.
  
! ‘-mam33-2’
       Generate code using features specific to the AM33/2.0 processor.
  
! ‘-mam34’
       Generate code using features specific to the AM34 processor.
  
! ‘-mtune=CPU-TYPE’
       Use the timing characteristics of the indicated CPU type when
       scheduling instructions.  This does not change the targeted
!      processor type.  The CPU type must be one of ‘mn10300’, ‘am33’,
!      ‘am33-2’ or ‘am34’.
  
! ‘-mreturn-pointer-on-d0’
       When generating a function that returns a pointer, return the
!      pointer in both ‘a0’ and ‘d0’.  Otherwise, the pointer is returned
!      only in ‘a0’, and attempts to call such functions without a
       prototype result in errors.  Note that this option is on by
!      default; use ‘-mno-return-pointer-on-d0’ to disable it.
  
! ‘-mno-crt0’
       Do not link in the C run-time initialization object file.
  
! ‘-mrelax’
       Indicate to the linker that it should perform a relaxation
       optimization pass to shorten branches, calls and absolute memory
       addresses.  This option only has an effect when used on the command
*************** These '-m' options are defined for Matsu
*** 25751,25775 ****
  
       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__'.
  
! '-mno-liw'
       Do not allow the compiler to generate _Long Instruction Word_
       instructions.  This option defines the preprocessor macro
!      '__NO_LIW__'.
  
! '-msetlb'
       Allow the compiler to generate the _SETLB_ and _Lcc_ instructions
!      if the target is the 'AM33' or later.  This is the default.  This
!      option defines the preprocessor macro '__SETLB__'.
  
! '-mno-setlb'
       Do not allow the compiler to generate _SETLB_ or _Lcc_
       instructions.  This option defines the preprocessor macro
!      '__NO_SETLB__'.
  
  
  File: gcc.info,  Node: Moxie Options,  Next: MSP430 Options,  Prev: MN10300 Options,  Up: Submodel Options
--- 25761,25785 ----
  
       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__’.
  
! ‘-mno-liw’
       Do not allow the compiler to generate _Long Instruction Word_
       instructions.  This option defines the preprocessor macro
!      ‘__NO_LIW__’.
  
! ‘-msetlb’
       Allow the compiler to generate the _SETLB_ and _Lcc_ instructions
!      if the target is the ‘AM33’ or later.  This is the default.  This
!      option defines the preprocessor macro ‘__SETLB__’.
  
! ‘-mno-setlb’
       Do not allow the compiler to generate _SETLB_ or _Lcc_
       instructions.  This option defines the preprocessor macro
!      ‘__NO_SETLB__’.
  
  
  File: gcc.info,  Node: Moxie Options,  Next: MSP430 Options,  Prev: MN10300 Options,  Up: Submodel Options
*************** File: gcc.info,  Node: Moxie Options,  N
*** 25777,25794 ****
  3.19.31 Moxie Options
  ---------------------
  
! '-meb'
!      Generate big-endian code.  This is the default for 'moxie-*-*'
       configurations.
  
! '-mel'
       Generate little-endian code.
  
! '-mmul.x'
       Generate mul.x and umul.x instructions.  This is the default for
!      'moxiebox-*-*' configurations.
  
! '-mno-crt0'
       Do not link in the C run-time initialization object file.
  
  
--- 25787,25804 ----
  3.19.31 Moxie Options
  ---------------------
  
! ‘-meb’
!      Generate big-endian code.  This is the default for ‘moxie-*-*’
       configurations.
  
! ‘-mel’
       Generate little-endian code.
  
! ‘-mmul.x’
       Generate mul.x and umul.x instructions.  This is the default for
!      ‘moxiebox-*-*’ configurations.
  
! ‘-mno-crt0’
       Do not link in the C run-time initialization object file.
  
  
*************** File: gcc.info,  Node: MSP430 Options,
*** 25799,25903 ****
  
  These options are defined for the MSP430:
  
! '-masm-hex'
       Force assembly output to always use hex constants.  Normally such
       constants are signed decimals, but this option is available for
       testsuite and/or aesthetic purposes.
  
! '-mmcu='
       Select the MCU to target.  This is used to create a C preprocessor
       symbol based upon the MCU name, converted to upper case and pre-
!      and post-fixed with '__'.  This in turn is used by the 'msp430.h'
       header file to select an MCU-specific supplementary header file.
  
       The option also sets the ISA to use.  If the MCU name is one that
       is known to only support the 430 ISA then that is selected,
!      otherwise the 430X ISA is selected.  A generic MCU name of 'msp430'
       can also be used to select the 430 ISA. Similarly the generic
!      'msp430x' MCU name selects the 430X ISA.
  
       In addition an MCU-specific linker script is added to the linker
!      command line.  The script's name is the name of the MCU with '.ld'
!      appended.  Thus specifying '-mmcu=xxx' on the 'gcc' command line
!      defines the C preprocessor symbol '__XXX__' and cause the linker to
!      search for a script called 'xxx.ld'.
  
       The ISA and hardware multiply supported for the different MCUs is
!      hard-coded into GCC. However, an external 'devices.csv' file can be
       used to extend device support beyond those that have been
       hard-coded.
  
!      GCC searches for the 'devices.csv' file using the following methods
       in the given precedence order, where the first method takes
       precendence over the second which takes precedence over the third.
  
!      Include path specified with '-I' and '-L'
!           'devices.csv' will be searched for in each of the directories
            specified by include paths and linker library search paths.
!      Path specified by the environment variable 'MSP430_GCC_INCLUDE_DIR'
            Define the value of the global environment variable
!           'MSP430_GCC_INCLUDE_DIR' to the full path to the directory
            containing devices.csv, and GCC will search this directory for
            devices.csv.  If devices.csv is found, this directory will
            also be registered as an include path, and linker library
            path.  Header files and linker scripts in this directory can
!           therefore be used without manually specifying '-I' and '-L' on
            the command line.
!      The 'msp430-elf{,bare}/include/devices' directory
!           Finally, GCC will examine 'msp430-elf{,bare}/include/devices'
            from the toolchain root directory.  This directory does not
            exist in a default installation, but if the user has created
!           it and copied 'devices.csv' there, then the MCU data will be
            read.  As above, this directory will also be registered as an
            include path, and linker library path.
  
!      If none of the above search methods find 'devices.csv', then the
       hard-coded MCU data is used.
  
! '-mwarn-mcu'
! '-mno-warn-mcu'
       This option enables or disables warnings about conflicts between
!      the MCU name specified by the '-mmcu' option and the ISA set by the
!      '-mcpu' option and/or the hardware multiply support set by the
!      '-mhwmult' option.  It also toggles warnings about unrecognized MCU
       names.  This option is on by default.
  
! '-mcpu='
!      Specifies the ISA to use.  Accepted values are 'msp430', 'msp430x'
!      and 'msp430xv2'.  This option is deprecated.  The '-mmcu=' option
       should be used to select the ISA.
  
! '-msim'
       Link to the simulator runtime libraries and linker script.
!      Overrides any scripts that would be selected by the '-mmcu='
       option.
  
! '-mlarge'
!      Use large-model addressing (20-bit pointers, 20-bit 'size_t').
  
! '-msmall'
!      Use small-model addressing (16-bit pointers, 16-bit 'size_t').
  
! '-mrelax'
       This option is passed to the assembler and linker, and allows the
       linker to perform certain optimizations that cannot be done until
       the final link.
  
! 'mhwmult='
       Describes the type of hardware multiply supported by the target.
!      Accepted values are 'none' for no hardware multiply, '16bit' for
!      the original 16-bit-only multiply supported by early MCUs.  '32bit'
!      for the 16/32-bit multiply supported by later MCUs and 'f5series'
       for the 16/32-bit multiply supported by F5-series MCUs.  A value of
!      'auto' can also be given.  This tells GCC to deduce the hardware
!      multiply support based upon the MCU name provided by the '-mmcu'
!      option.  If no '-mmcu' option is specified or if the MCU name is
       not recognized then no hardware multiply support is assumed.
!      'auto' is the default setting.
  
       Hardware multiplies are normally performed by calling a library
       routine.  This saves space in the generated code.  When compiling
!      at '-O3' or higher however the hardware multiplier is invoked
       inline.  This makes for bigger, but faster code.
  
       The hardware multiply routines disable interrupts whilst running
--- 25809,25913 ----
  
  These options are defined for the MSP430:
  
! ‘-masm-hex’
       Force assembly output to always use hex constants.  Normally such
       constants are signed decimals, but this option is available for
       testsuite and/or aesthetic purposes.
  
! ‘-mmcu=’
       Select the MCU to target.  This is used to create a C preprocessor
       symbol based upon the MCU name, converted to upper case and pre-
!      and post-fixed with ‘__’.  This in turn is used by the ‘msp430.h’
       header file to select an MCU-specific supplementary header file.
  
       The option also sets the ISA to use.  If the MCU name is one that
       is known to only support the 430 ISA then that is selected,
!      otherwise the 430X ISA is selected.  A generic MCU name of ‘msp430’
       can also be used to select the 430 ISA. Similarly the generic
!      ‘msp430x’ MCU name selects the 430X ISA.
  
       In addition an MCU-specific linker script is added to the linker
!      command line.  The script's name is the name of the MCU with ‘.ld’
!      appended.  Thus specifying ‘-mmcu=xxx’ on the ‘gcc’ command line
!      defines the C preprocessor symbol ‘__XXX__’ and cause the linker to
!      search for a script called ‘xxx.ld’.
  
       The ISA and hardware multiply supported for the different MCUs is
!      hard-coded into GCC. However, an external ‘devices.csv’ file can be
       used to extend device support beyond those that have been
       hard-coded.
  
!      GCC searches for the ‘devices.csv’ file using the following methods
       in the given precedence order, where the first method takes
       precendence over the second which takes precedence over the third.
  
!      Include path specified with ‘-I’ and ‘-L’
!           ‘devices.csv’ will be searched for in each of the directories
            specified by include paths and linker library search paths.
!      Path specified by the environment variable ‘MSP430_GCC_INCLUDE_DIR’
            Define the value of the global environment variable
!           ‘MSP430_GCC_INCLUDE_DIR’ to the full path to the directory
            containing devices.csv, and GCC will search this directory for
            devices.csv.  If devices.csv is found, this directory will
            also be registered as an include path, and linker library
            path.  Header files and linker scripts in this directory can
!           therefore be used without manually specifying ‘-I’ and ‘-L’ on
            the command line.
!      The ‘msp430-elf{,bare}/include/devices’ directory
!           Finally, GCC will examine ‘msp430-elf{,bare}/include/devices’
            from the toolchain root directory.  This directory does not
            exist in a default installation, but if the user has created
!           it and copied ‘devices.csv’ there, then the MCU data will be
            read.  As above, this directory will also be registered as an
            include path, and linker library path.
  
!      If none of the above search methods find ‘devices.csv’, then the
       hard-coded MCU data is used.
  
! ‘-mwarn-mcu’
! ‘-mno-warn-mcu’
       This option enables or disables warnings about conflicts between
!      the MCU name specified by the ‘-mmcu’ option and the ISA set by the
!      ‘-mcpu’ option and/or the hardware multiply support set by the
!      ‘-mhwmult’ option.  It also toggles warnings about unrecognized MCU
       names.  This option is on by default.
  
! ‘-mcpu=’
!      Specifies the ISA to use.  Accepted values are ‘msp430’, ‘msp430x’
!      and ‘msp430xv2’.  This option is deprecated.  The ‘-mmcu=’ option
       should be used to select the ISA.
  
! ‘-msim’
       Link to the simulator runtime libraries and linker script.
!      Overrides any scripts that would be selected by the ‘-mmcu=’
       option.
  
! ‘-mlarge’
!      Use large-model addressing (20-bit pointers, 20-bit ‘size_t’).
  
! ‘-msmall’
!      Use small-model addressing (16-bit pointers, 16-bit ‘size_t’).
  
! ‘-mrelax’
       This option is passed to the assembler and linker, and allows the
       linker to perform certain optimizations that cannot be done until
       the final link.
  
! ‘mhwmult=’
       Describes the type of hardware multiply supported by the target.
!      Accepted values are ‘none’ for no hardware multiply, ‘16bit’ for
!      the original 16-bit-only multiply supported by early MCUs.  ‘32bit’
!      for the 16/32-bit multiply supported by later MCUs and ‘f5series’
       for the 16/32-bit multiply supported by F5-series MCUs.  A value of
!      ‘auto’ can also be given.  This tells GCC to deduce the hardware
!      multiply support based upon the MCU name provided by the ‘-mmcu’
!      option.  If no ‘-mmcu’ option is specified or if the MCU name is
       not recognized then no hardware multiply support is assumed.
!      ‘auto’ is the default setting.
  
       Hardware multiplies are normally performed by calling a library
       routine.  This saves space in the generated code.  When compiling
!      at ‘-O3’ or higher however the hardware multiplier is invoked
       inline.  This makes for bigger, but faster code.
  
       The hardware multiply routines disable interrupts whilst running
*************** These options are defined for the MSP430
*** 25905,25930 ****
       makes them safe to use inside interrupt handlers as well as in
       normal code.
  
! '-minrt'
       Enable the use of a minimum runtime environment - no static
       initializers or constructors.  This is intended for
       memory-constrained devices.  The compiler includes special symbols
       in some objects that tell the linker and runtime which code
       fragments are required.
  
! '-mtiny-printf'
!      Enable reduced code size 'printf' and 'puts' library functions.
!      The 'tiny' implementations of these functions are not reentrant, so
       must be used with caution in multi-threaded applications.
  
       Support for streams has been removed and the string to be printed
!      will always be sent to stdout via the 'write' syscall.  The string
       is not buffered before it is sent to write.
  
       This option requires Newlib Nano IO, so GCC must be configured with
!      '--enable-newlib-nano-formatted-io'.
  
! '-mmax-inline-shift='
       This option takes an integer between 0 and 64 inclusive, and sets
       the maximum number of inline shift instructions which should be
       emitted to perform a shift operation by a constant amount.  When
--- 25915,25940 ----
       makes them safe to use inside interrupt handlers as well as in
       normal code.
  
! ‘-minrt’
       Enable the use of a minimum runtime environment - no static
       initializers or constructors.  This is intended for
       memory-constrained devices.  The compiler includes special symbols
       in some objects that tell the linker and runtime which code
       fragments are required.
  
! ‘-mtiny-printf’
!      Enable reduced code size ‘printf’ and ‘puts’ library functions.
!      The ‘tiny’ implementations of these functions are not reentrant, so
       must be used with caution in multi-threaded applications.
  
       Support for streams has been removed and the string to be printed
!      will always be sent to stdout via the ‘write’ syscall.  The string
       is not buffered before it is sent to write.
  
       This option requires Newlib Nano IO, so GCC must be configured with
!      ‘--enable-newlib-nano-formatted-io’.
  
! ‘-mmax-inline-shift=’
       This option takes an integer between 0 and 64 inclusive, and sets
       the maximum number of inline shift instructions which should be
       emitted to perform a shift operation by a constant amount.  When
*************** These options are defined for the MSP430
*** 25939,25965 ****
       passed for this option is divided by 2 and the resulting value used
       instead.
  
! '-mcode-region='
! '-mdata-region='
       These options tell the compiler where to place functions and data
!      that do not have one of the 'lower', 'upper', 'either' or 'section'
!      attributes.  Possible values are 'lower', 'upper', 'either' or
!      'any'.  The first three behave like the corresponding attribute.
!      The fourth possible value - 'any' - is the default.  It leaves
       placement entirely up to the linker script and how it assigns the
!      standard sections ('.text', '.data', etc) to the memory regions.
  
! '-msilicon-errata='
       This option passes on a request to assembler to enable the fixes
       for the named silicon errata.
  
! '-msilicon-errata-warn='
       This option passes on a request to the assembler to enable warning
       messages when a silicon errata might need to be applied.
  
! '-mwarn-devices-csv'
! '-mno-warn-devices-csv'
!      Warn if 'devices.csv' is not found or there are problem parsing it
       (default: on).
  
  
--- 25949,25975 ----
       passed for this option is divided by 2 and the resulting value used
       instead.
  
! ‘-mcode-region=’
! ‘-mdata-region=’
       These options tell the compiler where to place functions and data
!      that do not have one of the ‘lower’, ‘upper’, ‘either’ or ‘section’
!      attributes.  Possible values are ‘lower’, ‘upper’, ‘either’ or
!      ‘any’.  The first three behave like the corresponding attribute.
!      The fourth possible value - ‘any’ - is the default.  It leaves
       placement entirely up to the linker script and how it assigns the
!      standard sections (‘.text’, ‘.data’, etc) to the memory regions.
  
! ‘-msilicon-errata=’
       This option passes on a request to assembler to enable the fixes
       for the named silicon errata.
  
! ‘-msilicon-errata-warn=’
       This option passes on a request to the assembler to enable warning
       messages when a silicon errata might need to be applied.
  
! ‘-mwarn-devices-csv’
! ‘-mno-warn-devices-csv’
!      Warn if ‘devices.csv’ is not found or there are problem parsing it
       (default: on).
  
  
*************** File: gcc.info,  Node: NDS32 Options,  N
*** 25970,26051 ****
  
  These options are defined for NDS32 implementations:
  
! '-mbig-endian'
       Generate code in big-endian mode.
  
! '-mlittle-endian'
       Generate code in little-endian mode.
  
! '-mreduced-regs'
       Use reduced-set registers for register allocation.
  
! '-mfull-regs'
       Use full-set registers for register allocation.
  
! '-mcmov'
       Generate conditional move instructions.
  
! '-mno-cmov'
       Do not generate conditional move instructions.
  
! '-mext-perf'
       Generate performance extension instructions.
  
! '-mno-ext-perf'
       Do not generate performance extension instructions.
  
! '-mext-perf2'
       Generate performance extension 2 instructions.
  
! '-mno-ext-perf2'
       Do not generate performance extension 2 instructions.
  
! '-mext-string'
       Generate string extension instructions.
  
! '-mno-ext-string'
       Do not generate string extension instructions.
  
! '-mv3push'
       Generate v3 push25/pop25 instructions.
  
! '-mno-v3push'
       Do not generate v3 push25/pop25 instructions.
  
! '-m16-bit'
       Generate 16-bit instructions.
  
! '-mno-16-bit'
       Do not generate 16-bit instructions.
  
! '-misr-vector-size=NUM'
       Specify the size of each interrupt vector, which must be 4 or 16.
  
! '-mcache-block-size=NUM'
       Specify the size of each cache block, which must be a power of 2
       between 4 and 512.
  
! '-march=ARCH'
       Specify the name of the target architecture.
  
! '-mcmodel=CODE-MODEL'
       Set the code model to one of
!      'small'
            All the data and read-only data segments must be within 512KB
            addressing space.  The text segment must be within 16MB
            addressing space.
!      'medium'
            The data segment must be within 512KB while the read-only data
            segment can be within 4GB addressing space.  The text segment
            should be still within 16MB addressing space.
!      'large'
            All the text and data segments can be within 4GB addressing
            space.
  
! '-mctor-dtor'
       Enable constructor/destructor feature.
  
! '-mrelax'
       Guide linker to relax instructions.
  
  
--- 25980,26061 ----
  
  These options are defined for NDS32 implementations:
  
! ‘-mbig-endian’
       Generate code in big-endian mode.
  
! ‘-mlittle-endian’
       Generate code in little-endian mode.
  
! ‘-mreduced-regs’
       Use reduced-set registers for register allocation.
  
! ‘-mfull-regs’
       Use full-set registers for register allocation.
  
! ‘-mcmov’
       Generate conditional move instructions.
  
! ‘-mno-cmov’
       Do not generate conditional move instructions.
  
! ‘-mext-perf’
       Generate performance extension instructions.
  
! ‘-mno-ext-perf’
       Do not generate performance extension instructions.
  
! ‘-mext-perf2’
       Generate performance extension 2 instructions.
  
! ‘-mno-ext-perf2’
       Do not generate performance extension 2 instructions.
  
! ‘-mext-string’
       Generate string extension instructions.
  
! ‘-mno-ext-string’
       Do not generate string extension instructions.
  
! ‘-mv3push’
       Generate v3 push25/pop25 instructions.
  
! ‘-mno-v3push’
       Do not generate v3 push25/pop25 instructions.
  
! ‘-m16-bit’
       Generate 16-bit instructions.
  
! ‘-mno-16-bit’
       Do not generate 16-bit instructions.
  
! ‘-misr-vector-size=NUM’
       Specify the size of each interrupt vector, which must be 4 or 16.
  
! ‘-mcache-block-size=NUM’
       Specify the size of each cache block, which must be a power of 2
       between 4 and 512.
  
! ‘-march=ARCH’
       Specify the name of the target architecture.
  
! ‘-mcmodel=CODE-MODEL’
       Set the code model to one of
!      ‘small’
            All the data and read-only data segments must be within 512KB
            addressing space.  The text segment must be within 16MB
            addressing space.
!      ‘medium’
            The data segment must be within 512KB while the read-only data
            segment can be within 4GB addressing space.  The text segment
            should be still within 16MB addressing space.
!      ‘large’
            All the text and data segments can be within 4GB addressing
            space.
  
! ‘-mctor-dtor’
       Enable constructor/destructor feature.
  
! ‘-mrelax’
       Guide linker to relax instructions.
  
  
*************** File: gcc.info,  Node: Nios II Options,
*** 26056,26096 ****
  
  These are the options defined for the Altera Nios II processor.
  
! '-G NUM'
       Put global and static objects less than or equal to NUM bytes into
       the small data or BSS sections instead of the normal data or BSS
       sections.  The default value of NUM is 8.
  
! '-mgpopt=OPTION'
! '-mgpopt'
! '-mno-gpopt'
       Generate (do not generate) GP-relative accesses.  The following
       OPTION names are recognized:
  
!      'none'
            Do not generate GP-relative accesses.
  
!      'local'
            Generate GP-relative accesses for small data objects that are
            not external, weak, or uninitialized common symbols.  Also use
            GP-relative addressing for objects that have been explicitly
!           placed in a small data section via a 'section' attribute.
  
!      'global'
!           As for 'local', but also generate GP-relative accesses for
            small data objects that are external, weak, or common.  If you
            use this option, you must ensure that all parts of your
!           program (including libraries) are compiled with the same '-G'
            setting.
  
!      'data'
            Generate GP-relative accesses for all data objects in the
            program.  If you use this option, the entire data and BSS
            segments of your program must fit in 64K of memory and you
            must use an appropriate linker script to allocate them within
            the addressable range of the global pointer.
  
!      'all'
            Generate GP-relative addresses for function pointers as well
            as data pointers.  If you use this option, the entire text,
            data, and BSS segments of your program must fit in 64K of
--- 26066,26106 ----
  
  These are the options defined for the Altera Nios II processor.
  
! ‘-G NUM’
       Put global and static objects less than or equal to NUM bytes into
       the small data or BSS sections instead of the normal data or BSS
       sections.  The default value of NUM is 8.
  
! ‘-mgpopt=OPTION’
! ‘-mgpopt’
! ‘-mno-gpopt’
       Generate (do not generate) GP-relative accesses.  The following
       OPTION names are recognized:
  
!      ‘none’
            Do not generate GP-relative accesses.
  
!      ‘local’
            Generate GP-relative accesses for small data objects that are
            not external, weak, or uninitialized common symbols.  Also use
            GP-relative addressing for objects that have been explicitly
!           placed in a small data section via a ‘section’ attribute.
  
!      ‘global’
!           As for ‘local’, but also generate GP-relative accesses for
            small data objects that are external, weak, or common.  If you
            use this option, you must ensure that all parts of your
!           program (including libraries) are compiled with the same ‘-G’
            setting.
  
!      ‘data’
            Generate GP-relative accesses for all data objects in the
            program.  If you use this option, the entire data and BSS
            segments of your program must fit in 64K of memory and you
            must use an appropriate linker script to allocate them within
            the addressable range of the global pointer.
  
!      ‘all’
            Generate GP-relative addresses for function pointers as well
            as data pointers.  If you use this option, the entire text,
            data, and BSS segments of your program must fit in 64K of
*************** These are the options defined for the Al
*** 26098,26133 ****
            allocate them within the addressable range of the global
            pointer.
  
!      '-mgpopt' is equivalent to '-mgpopt=local', and '-mno-gpopt' is
!      equivalent to '-mgpopt=none'.
  
!      The default is '-mgpopt' except when '-fpic' or '-fPIC' is
       specified to generate position-independent code.  Note that the
       Nios II ABI does not permit GP-relative accesses from shared
       libraries.
  
!      You may need to specify '-mno-gpopt' explicitly when building
       programs that include large amounts of small data, including large
       GOT data sections.  In this case, the 16-bit offset for GP-relative
       addressing may not be large enough to allow access to the entire
       small data section.
  
! '-mgprel-sec=REGEXP'
       This option specifies additional section names that can be accessed
       via GP-relative addressing.  It is most useful in conjunction with
!      'section' attributes on variable declarations (*note Common
       Variable Attributes::) and a custom linker script.  The REGEXP is a
       POSIX Extended Regular Expression.
  
!      This option does not affect the behavior of the '-G' option, and
!      the specified sections are in addition to the standard '.sdata' and
!      '.sbss' small-data sections that are recognized by '-mgpopt'.
  
! '-mr0rel-sec=REGEXP'
       This option specifies names of sections that can be accessed via a
!      16-bit offset from 'r0'; that is, in the low 32K or high 32K of the
       32-bit address space.  It is most useful in conjunction with
!      'section' attributes on variable declarations (*note Common
       Variable Attributes::) and a custom linker script.  The REGEXP is a
       POSIX Extended Regular Expression.
  
--- 26108,26143 ----
            allocate them within the addressable range of the global
            pointer.
  
!      ‘-mgpopt’ is equivalent to ‘-mgpopt=local’, and ‘-mno-gpopt’ is
!      equivalent to ‘-mgpopt=none’.
  
!      The default is ‘-mgpopt’ except when ‘-fpic’ or ‘-fPIC’ is
       specified to generate position-independent code.  Note that the
       Nios II ABI does not permit GP-relative accesses from shared
       libraries.
  
!      You may need to specify ‘-mno-gpopt’ explicitly when building
       programs that include large amounts of small data, including large
       GOT data sections.  In this case, the 16-bit offset for GP-relative
       addressing may not be large enough to allow access to the entire
       small data section.
  
! ‘-mgprel-sec=REGEXP’
       This option specifies additional section names that can be accessed
       via GP-relative addressing.  It is most useful in conjunction with
!      ‘section’ attributes on variable declarations (*note Common
       Variable Attributes::) and a custom linker script.  The REGEXP is a
       POSIX Extended Regular Expression.
  
!      This option does not affect the behavior of the ‘-G’ option, and
!      the specified sections are in addition to the standard ‘.sdata’ and
!      ‘.sbss’ small-data sections that are recognized by ‘-mgpopt’.
  
! ‘-mr0rel-sec=REGEXP’
       This option specifies names of sections that can be accessed via a
!      16-bit offset from ‘r0’; that is, in the low 32K or high 32K of the
       32-bit address space.  It is most useful in conjunction with
!      ‘section’ attributes on variable declarations (*note Common
       Variable Attributes::) and a custom linker script.  The REGEXP is a
       POSIX Extended Regular Expression.
  
*************** These are the options defined for the Al
*** 26136,26195 ****
       no conventional section names used in standard linker scripts for
       sections in the low or high areas of memory.
  
! '-mel'
! '-meb'
       Generate little-endian (default) or big-endian (experimental) code,
       respectively.
  
! '-march=ARCH'
       This specifies the name of the target Nios II architecture.  GCC
       uses this name to determine what kind of instructions it can emit
!      when generating assembly code.  Permissible names are: 'r1', 'r2'.
  
!      The preprocessor macro '__nios2_arch__' is available to programs,
       with value 1 or 2, indicating the targeted ISA level.
  
! '-mbypass-cache'
! '-mno-bypass-cache'
       Force all load and store instructions to always bypass cache by
       using I/O variants of the instructions.  The default is not to
       bypass the cache.
  
! '-mno-cache-volatile'
! '-mcache-volatile'
       Volatile memory access bypass the cache using the I/O variants of
       the load and store instructions.  The default is not to bypass the
       cache.
  
! '-mno-fast-sw-div'
! '-mfast-sw-div'
       Do not use table-based fast divide for small numbers.  The default
!      is to use the fast divide at '-O3' and above.
  
! '-mno-hw-mul'
! '-mhw-mul'
! '-mno-hw-mulx'
! '-mhw-mulx'
! '-mno-hw-div'
! '-mhw-div'
!      Enable or disable emitting 'mul', 'mulx' and 'div' family of
!      instructions by the compiler.  The default is to emit 'mul' and not
!      emit 'div' and 'mulx'.
  
! '-mbmx'
! '-mno-bmx'
! '-mcdx'
! '-mno-cdx'
       Enable or disable generation of Nios II R2 BMX (bit manipulation)
       and CDX (code density) instructions.  Enabling these instructions
!      also requires '-march=r2'.  Since these instructions are optional
       extensions to the R2 architecture, the default is not to emit them.
  
! '-mcustom-INSN=N'
! '-mno-custom-INSN'
!      Each '-mcustom-INSN=N' option enables use of a custom instruction
       with encoding N when generating code that uses INSN.  For example,
!      '-mcustom-fadds=253' generates custom instruction 253 for
       single-precision floating-point add operations instead of the
       default behavior of using a library call.
  
--- 26146,26205 ----
       no conventional section names used in standard linker scripts for
       sections in the low or high areas of memory.
  
! ‘-mel’
! ‘-meb’
       Generate little-endian (default) or big-endian (experimental) code,
       respectively.
  
! ‘-march=ARCH’
       This specifies the name of the target Nios II architecture.  GCC
       uses this name to determine what kind of instructions it can emit
!      when generating assembly code.  Permissible names are: ‘r1’, ‘r2’.
  
!      The preprocessor macro ‘__nios2_arch__’ is available to programs,
       with value 1 or 2, indicating the targeted ISA level.
  
! ‘-mbypass-cache’
! ‘-mno-bypass-cache’
       Force all load and store instructions to always bypass cache by
       using I/O variants of the instructions.  The default is not to
       bypass the cache.
  
! ‘-mno-cache-volatile’
! ‘-mcache-volatile’
       Volatile memory access bypass the cache using the I/O variants of
       the load and store instructions.  The default is not to bypass the
       cache.
  
! ‘-mno-fast-sw-div’
! ‘-mfast-sw-div’
       Do not use table-based fast divide for small numbers.  The default
!      is to use the fast divide at ‘-O3’ and above.
  
! ‘-mno-hw-mul’
! ‘-mhw-mul’
! ‘-mno-hw-mulx’
! ‘-mhw-mulx’
! ‘-mno-hw-div’
! ‘-mhw-div’
!      Enable or disable emitting ‘mul’, ‘mulx’ and ‘div’ family of
!      instructions by the compiler.  The default is to emit ‘mul’ and not
!      emit ‘div’ and ‘mulx’.
  
! ‘-mbmx’
! ‘-mno-bmx’
! ‘-mcdx’
! ‘-mno-cdx’
       Enable or disable generation of Nios II R2 BMX (bit manipulation)
       and CDX (code density) instructions.  Enabling these instructions
!      also requires ‘-march=r2’.  Since these instructions are optional
       extensions to the R2 architecture, the default is not to emit them.
  
! ‘-mcustom-INSN=N’
! ‘-mno-custom-INSN’
!      Each ‘-mcustom-INSN=N’ option enables use of a custom instruction
       with encoding N when generating code that uses INSN.  For example,
!      ‘-mcustom-fadds=253’ generates custom instruction 253 for
       single-precision floating-point add operations instead of the
       default behavior of using a library call.
  
*************** These are the options defined for the Al
*** 26201,26274 ****
  
       Single-precision floating point:
  
!      'fadds', 'fsubs', 'fdivs', 'fmuls'
            Binary arithmetic operations.
  
!      'fnegs'
            Unary negation.
  
!      'fabss'
            Unary absolute value.
  
!      'fcmpeqs', 'fcmpges', 'fcmpgts', 'fcmples', 'fcmplts', 'fcmpnes'
            Comparison operations.
  
!      'fmins', 'fmaxs'
            Floating-point minimum and maximum.  These instructions are
!           only generated if '-ffinite-math-only' is specified.
  
!      'fsqrts'
            Unary square root operation.
  
!      'fcoss', 'fsins', 'ftans', 'fatans', 'fexps', 'flogs'
            Floating-point trigonometric and exponential functions.  These
            instructions are only generated if
!           '-funsafe-math-optimizations' is also specified.
  
       Double-precision floating point:
  
!      'faddd', 'fsubd', 'fdivd', 'fmuld'
            Binary arithmetic operations.
  
!      'fnegd'
            Unary negation.
  
!      'fabsd'
            Unary absolute value.
  
!      'fcmpeqd', 'fcmpged', 'fcmpgtd', 'fcmpled', 'fcmpltd', 'fcmpned'
            Comparison operations.
  
!      'fmind', 'fmaxd'
            Double-precision minimum and maximum.  These instructions are
!           only generated if '-ffinite-math-only' is specified.
  
!      'fsqrtd'
            Unary square root operation.
  
!      'fcosd', 'fsind', 'ftand', 'fatand', 'fexpd', 'flogd'
            Double-precision trigonometric and exponential functions.
            These instructions are only generated if
!           '-funsafe-math-optimizations' is also specified.
  
       Conversions:
!      'fextsd'
            Conversion from single precision to double precision.
  
!      'ftruncds'
            Conversion from double precision to single precision.
  
!      'fixsi', 'fixsu', 'fixdi', 'fixdu'
            Conversion from floating point to signed or unsigned integer
            types, with truncation towards zero.
  
!      'round'
            Conversion from single-precision floating point to signed
            integer, rounding to the nearest integer and ties away from
!           zero.  This corresponds to the '__builtin_lroundf' function
!           when '-fno-math-errno' is used.
  
!      'floatis', 'floatus', 'floatid', 'floatud'
            Conversion from signed or unsigned integer types to
            floating-point types.
  
--- 26211,26284 ----
  
       Single-precision floating point:
  
!      ‘fadds’, ‘fsubs’, ‘fdivs’, ‘fmuls’
            Binary arithmetic operations.
  
!      ‘fnegs’
            Unary negation.
  
!      ‘fabss’
            Unary absolute value.
  
!      ‘fcmpeqs’, ‘fcmpges’, ‘fcmpgts’, ‘fcmples’, ‘fcmplts’, ‘fcmpnes’
            Comparison operations.
  
!      ‘fmins’, ‘fmaxs’
            Floating-point minimum and maximum.  These instructions are
!           only generated if ‘-ffinite-math-only’ is specified.
  
!      ‘fsqrts’
            Unary square root operation.
  
!      ‘fcoss’, ‘fsins’, ‘ftans’, ‘fatans’, ‘fexps’, ‘flogs’
            Floating-point trigonometric and exponential functions.  These
            instructions are only generated if
!           ‘-funsafe-math-optimizations’ is also specified.
  
       Double-precision floating point:
  
!      ‘faddd’, ‘fsubd’, ‘fdivd’, ‘fmuld’
            Binary arithmetic operations.
  
!      ‘fnegd’
            Unary negation.
  
!      ‘fabsd’
            Unary absolute value.
  
!      ‘fcmpeqd’, ‘fcmpged’, ‘fcmpgtd’, ‘fcmpled’, ‘fcmpltd’, ‘fcmpned’
            Comparison operations.
  
!      ‘fmind’, ‘fmaxd’
            Double-precision minimum and maximum.  These instructions are
!           only generated if ‘-ffinite-math-only’ is specified.
  
!      ‘fsqrtd’
            Unary square root operation.
  
!      ‘fcosd’, ‘fsind’, ‘ftand’, ‘fatand’, ‘fexpd’, ‘flogd’
            Double-precision trigonometric and exponential functions.
            These instructions are only generated if
!           ‘-funsafe-math-optimizations’ is also specified.
  
       Conversions:
!      ‘fextsd’
            Conversion from single precision to double precision.
  
!      ‘ftruncds’
            Conversion from double precision to single precision.
  
!      ‘fixsi’, ‘fixsu’, ‘fixdi’, ‘fixdu’
            Conversion from floating point to signed or unsigned integer
            types, with truncation towards zero.
  
!      ‘round’
            Conversion from single-precision floating point to signed
            integer, rounding to the nearest integer and ties away from
!           zero.  This corresponds to the ‘__builtin_lroundf’ function
!           when ‘-fno-math-errno’ is used.
  
!      ‘floatis’, ‘floatus’, ‘floatid’, ‘floatud’
            Conversion from signed or unsigned integer types to
            floating-point types.
  
*************** These are the options defined for the Al
*** 26286,26331 ****
       sequences to write register X and/or read register Y when
       double-precision floating-point instructions are used.
  
!      'fwrx'
            Write SRC1 into the least significant half of X and SRC2 into
            the most significant half of X.
  
!      'fwry'
            Write SRC1 into Y.
  
!      'frdxhi', 'frdxlo'
            Read the most or least (respectively) significant half of X
            and store it in DEST.
  
!      'frdy'
            Read the value of Y and store it into DEST.
  
       Note that you can gain more local control over generation of Nios
!      II custom instructions by using the 'target("custom-INSN=N")' and
!      'target("no-custom-INSN")' function attributes (*note Function
       Attributes::) or pragmas (*note Function Specific Option
       Pragmas::).
  
! '-mcustom-fpu-cfg=NAME'
  
       This option enables a predefined, named set of custom instruction
!      encodings (see '-mcustom-INSN' above).  Currently, the following
       sets are defined:
  
!      '-mcustom-fpu-cfg=60-1' is equivalent to:
            -mcustom-fmuls=252
            -mcustom-fadds=253
            -mcustom-fsubs=254
            -fsingle-precision-constant
  
!      '-mcustom-fpu-cfg=60-2' is equivalent to:
            -mcustom-fmuls=252
            -mcustom-fadds=253
            -mcustom-fsubs=254
            -mcustom-fdivs=255
            -fsingle-precision-constant
  
!      '-mcustom-fpu-cfg=72-3' is equivalent to:
            -mcustom-floatus=243
            -mcustom-fixsi=244
            -mcustom-floatis=245
--- 26296,26341 ----
       sequences to write register X and/or read register Y when
       double-precision floating-point instructions are used.
  
!      ‘fwrx’
            Write SRC1 into the least significant half of X and SRC2 into
            the most significant half of X.
  
!      ‘fwry’
            Write SRC1 into Y.
  
!      ‘frdxhi’, ‘frdxlo’
            Read the most or least (respectively) significant half of X
            and store it in DEST.
  
!      ‘frdy’
            Read the value of Y and store it into DEST.
  
       Note that you can gain more local control over generation of Nios
!      II custom instructions by using the ‘target("custom-INSN=N")’ and
!      ‘target("no-custom-INSN")’ function attributes (*note Function
       Attributes::) or pragmas (*note Function Specific Option
       Pragmas::).
  
! ‘-mcustom-fpu-cfg=NAME’
  
       This option enables a predefined, named set of custom instruction
!      encodings (see ‘-mcustom-INSN’ above).  Currently, the following
       sets are defined:
  
!      ‘-mcustom-fpu-cfg=60-1’ is equivalent to:
            -mcustom-fmuls=252
            -mcustom-fadds=253
            -mcustom-fsubs=254
            -fsingle-precision-constant
  
!      ‘-mcustom-fpu-cfg=60-2’ is equivalent to:
            -mcustom-fmuls=252
            -mcustom-fadds=253
            -mcustom-fsubs=254
            -mcustom-fdivs=255
            -fsingle-precision-constant
  
!      ‘-mcustom-fpu-cfg=72-3’ is equivalent to:
            -mcustom-floatus=243
            -mcustom-fixsi=244
            -mcustom-floatis=245
*************** These are the options defined for the Al
*** 26339,26345 ****
            -mcustom-fdivs=255
            -fsingle-precision-constant
  
!      '-mcustom-fpu-cfg=fph2' is equivalent to:
            -mcustom-fabss=224
            -mcustom-fnegs=225
            -mcustom-fcmpnes=226
--- 26349,26355 ----
            -mcustom-fdivs=255
            -fsingle-precision-constant
  
!      ‘-mcustom-fpu-cfg=fph2’ is equivalent to:
            -mcustom-fabss=224
            -mcustom-fnegs=225
            -mcustom-fcmpnes=226
*************** These are the options defined for the Al
*** 26359,26402 ****
            -mcustom-fsubs=254
            -mcustom-fdivs=255
  
!      Custom instruction assignments given by individual '-mcustom-INSN='
!      options override those given by '-mcustom-fpu-cfg=', regardless of
       the order of the options on the command line.
  
       Note that you can gain more local control over selection of a FPU
!      configuration by using the 'target("custom-fpu-cfg=NAME")' function
       attribute (*note Function Attributes::) or pragma (*note Function
       Specific Option Pragmas::).
  
       The name FPH2 is an abbreviation for _Nios II Floating Point
       Hardware 2 Component_.  Please note that the custom instructions
!      enabled by '-mcustom-fmins=233' and '-mcustom-fmaxs=234' are only
!      generated if '-ffinite-math-only' is specified.  The custom
!      instruction enabled by '-mcustom-round=248' is only generated if
!      '-fno-math-errno' is specified.  In contrast to the other
!      configurations, '-fsingle-precision-constant' is not set.
  
!  These additional '-m' options are available for the Altera Nios II ELF
  (bare-metal) target:
  
! '-mhal'
       Link with HAL BSP. This suppresses linking with the GCC-provided C
       runtime startup and termination code, and is typically used in
!      conjunction with '-msys-crt0=' to specify the location of the
       alternate startup code provided by the HAL BSP.
  
! '-msmallc'
!      Link with a limited version of the C library, '-lsmallc', rather
       than Newlib.
  
! '-msys-crt0=STARTFILE'
       STARTFILE is the file name of the startfile (crt0) to use when
!      linking.  This option is only useful in conjunction with '-mhal'.
  
! '-msys-lib=SYSTEMLIB'
       SYSTEMLIB is the library name of the library that provides
!      low-level system calls required by the C library, e.g. 'read' and
!      'write'.  This option is typically used to link with a library
       provided by a HAL BSP.
  
  
--- 26369,26412 ----
            -mcustom-fsubs=254
            -mcustom-fdivs=255
  
!      Custom instruction assignments given by individual ‘-mcustom-INSN=’
!      options override those given by ‘-mcustom-fpu-cfg=’, regardless of
       the order of the options on the command line.
  
       Note that you can gain more local control over selection of a FPU
!      configuration by using the ‘target("custom-fpu-cfg=NAME")’ function
       attribute (*note Function Attributes::) or pragma (*note Function
       Specific Option Pragmas::).
  
       The name FPH2 is an abbreviation for _Nios II Floating Point
       Hardware 2 Component_.  Please note that the custom instructions
!      enabled by ‘-mcustom-fmins=233’ and ‘-mcustom-fmaxs=234’ are only
!      generated if ‘-ffinite-math-only’ is specified.  The custom
!      instruction enabled by ‘-mcustom-round=248’ is only generated if
!      ‘-fno-math-errno’ is specified.  In contrast to the other
!      configurations, ‘-fsingle-precision-constant’ is not set.
  
!  These additional ‘-m’ options are available for the Altera Nios II ELF
  (bare-metal) target:
  
! ‘-mhal’
       Link with HAL BSP. This suppresses linking with the GCC-provided C
       runtime startup and termination code, and is typically used in
!      conjunction with ‘-msys-crt0=’ to specify the location of the
       alternate startup code provided by the HAL BSP.
  
! ‘-msmallc’
!      Link with a limited version of the C library, ‘-lsmallc’, rather
       than Newlib.
  
! ‘-msys-crt0=STARTFILE’
       STARTFILE is the file name of the startfile (crt0) to use when
!      linking.  This option is only useful in conjunction with ‘-mhal’.
  
! ‘-msys-lib=SYSTEMLIB’
       SYSTEMLIB is the library name of the library that provides
!      low-level system calls required by the C library, e.g. ‘read’ and
!      ‘write’.  This option is typically used to link with a library
       provided by a HAL BSP.
  
  
*************** File: gcc.info,  Node: Nvidia PTX Option
*** 26407,26465 ****
  
  These options are defined for Nvidia PTX:
  
! '-m64'
       Ignored, but preserved for backward compatibility.  Only 64-bit ABI
       is supported.
  
! '-march=ARCHITECTURE-STRING'
       Generate code for the specified PTX ISA target architecture (e.g.
!      'sm_35').  Valid architecture strings are 'sm_30', 'sm_35',
!      'sm_53', 'sm_70', 'sm_75' and 'sm_80'.  The default depends on how
!      the compiler has been configured, see '--with-arch'.
  
!      This option sets the value of the preprocessor macro '__PTX_SM__';
!      for instance, for 'sm_35', it has the value '350'.
  
! '-misa=ARCHITECTURE-STRING'
!      Alias of '-march='.
  
! '-march-map=ARCHITECTURE-STRING'
!      Select the closest available '-march=' value that is not more
!      capable.  For instance, for '-march-map=sm_50' select
!      '-march=sm_35', and for '-march-map=sm_53' select '-march=sm_53'.
  
! '-mptx=VERSION-STRING'
!      Generate code for the specified PTX ISA version (e.g. '7.0').
!      Valid version strings include '3.1', '6.0', '6.3', and '7.0'.  The
       default PTX ISA version is 6.0, unless a higher version is required
!      for specified PTX ISA target architecture via option '-march='.
  
       This option sets the values of the preprocessor macros
!      '__PTX_ISA_VERSION_MAJOR__' and '__PTX_ISA_VERSION_MINOR__'; for
!      instance, for '3.1' the macros have the values '3' and '1',
       respectively.
  
! '-mmainkernel'
       Link in code for a __main kernel.  This is for stand-alone instead
       of offloading execution.
  
! '-moptimize'
       Apply partitioned execution optimizations.  This is the default
       when any level of optimization is selected.
  
! '-msoft-stack'
!      Generate code that does not use '.local' memory directly for stack
       storage.  Instead, a per-warp stack pointer is maintained
       explicitly.  This enables variable-length stack allocation (with
!      variable-length arrays or 'alloca'), and when global memory is used
       for underlying storage, makes it possible to access automatic
       variables from other threads, or with atomic instructions.  This
       code generation variant is used for OpenMP offloading, but the
       option is exposed on its own for the purpose of testing the
       compiler; to generate code suitable for linking into programs using
!      OpenMP offloading, use option '-mgomp'.
  
! '-muniform-simt'
       Switch to code generation variant that allows to execute all
       threads in each warp, while maintaining memory state and side
       effects as if only one thread in each warp was active outside of
--- 26417,26475 ----
  
  These options are defined for Nvidia PTX:
  
! ‘-m64’
       Ignored, but preserved for backward compatibility.  Only 64-bit ABI
       is supported.
  
! ‘-march=ARCHITECTURE-STRING’
       Generate code for the specified PTX ISA target architecture (e.g.
!      ‘sm_35’).  Valid architecture strings are ‘sm_30’, ‘sm_35’,
!      ‘sm_53’, ‘sm_70’, ‘sm_75’ and ‘sm_80’.  The default depends on how
!      the compiler has been configured, see ‘--with-arch’.
  
!      This option sets the value of the preprocessor macro ‘__PTX_SM__’;
!      for instance, for ‘sm_35’, it has the value ‘350’.
  
! ‘-misa=ARCHITECTURE-STRING’
!      Alias of ‘-march=’.
  
! ‘-march-map=ARCHITECTURE-STRING’
!      Select the closest available ‘-march=’ value that is not more
!      capable.  For instance, for ‘-march-map=sm_50’ select
!      ‘-march=sm_35’, and for ‘-march-map=sm_53’ select ‘-march=sm_53’.
  
! ‘-mptx=VERSION-STRING’
!      Generate code for the specified PTX ISA version (e.g. ‘7.0’).
!      Valid version strings include ‘3.1’, ‘6.0’, ‘6.3’, and ‘7.0’.  The
       default PTX ISA version is 6.0, unless a higher version is required
!      for specified PTX ISA target architecture via option ‘-march=’.
  
       This option sets the values of the preprocessor macros
!      ‘__PTX_ISA_VERSION_MAJOR__’ and ‘__PTX_ISA_VERSION_MINOR__’; for
!      instance, for ‘3.1’ the macros have the values ‘3’ and ‘1’,
       respectively.
  
! ‘-mmainkernel’
       Link in code for a __main kernel.  This is for stand-alone instead
       of offloading execution.
  
! ‘-moptimize’
       Apply partitioned execution optimizations.  This is the default
       when any level of optimization is selected.
  
! ‘-msoft-stack’
!      Generate code that does not use ‘.local’ memory directly for stack
       storage.  Instead, a per-warp stack pointer is maintained
       explicitly.  This enables variable-length stack allocation (with
!      variable-length arrays or ‘alloca’), and when global memory is used
       for underlying storage, makes it possible to access automatic
       variables from other threads, or with atomic instructions.  This
       code generation variant is used for OpenMP offloading, but the
       option is exposed on its own for the purpose of testing the
       compiler; to generate code suitable for linking into programs using
!      OpenMP offloading, use option ‘-mgomp’.
  
! ‘-muniform-simt’
       Switch to code generation variant that allows to execute all
       threads in each warp, while maintaining memory state and side
       effects as if only one thread in each warp was active outside of
*************** These options are defined for Nvidia PTX
*** 26468,26482 ****
       lane index equals the master lane index), and the register being
       assigned is copied via a shuffle instruction from the master lane.
       Outside of SIMD regions lane 0 is the master; inside, each thread
!      sees itself as the master.  Shared memory array 'int __nvptx_uni[]'
       stores all-zeros or all-ones bitmasks for each warp, indicating
       current mode (0 outside of SIMD regions).  Each thread can
!      bitwise-and the bitmask at position 'tid.y' with current lane index
       to compute the master lane index.
  
! '-mgomp'
!      Generate code for use in OpenMP offloading: enables '-msoft-stack'
!      and '-muniform-simt' options, and selects corresponding multilib
       variant.
  
  
--- 26478,26492 ----
       lane index equals the master lane index), and the register being
       assigned is copied via a shuffle instruction from the master lane.
       Outside of SIMD regions lane 0 is the master; inside, each thread
!      sees itself as the master.  Shared memory array ‘int __nvptx_uni[]’
       stores all-zeros or all-ones bitmasks for each warp, indicating
       current mode (0 outside of SIMD regions).  Each thread can
!      bitwise-and the bitmask at position ‘tid.y’ with current lane index
       to compute the master lane index.
  
! ‘-mgomp’
!      Generate code for use in OpenMP offloading: enables ‘-msoft-stack’
!      and ‘-muniform-simt’ options, and selects corresponding multilib
       variant.
  
  
*************** File: gcc.info,  Node: OpenRISC Options,
*** 26487,26561 ****
  
  These options are defined for OpenRISC:
  
! '-mboard=NAME'
       Configure a board specific runtime.  This will be passed to the
!      linker for newlib board library linking.  The default is 'or1ksim'.
  
! '-mnewlib'
       This option is ignored; it is for compatibility purposes only.
       This used to select linker and preprocessor options for use with
       newlib.
  
! '-msoft-div'
! '-mhard-div'
!      Select software or hardware divide ('l.div', 'l.divu')
       instructions.  This default is hardware divide.
  
! '-msoft-mul'
! '-mhard-mul'
!      Select software or hardware multiply ('l.mul', 'l.muli')
       instructions.  This default is hardware multiply.
  
! '-msoft-float'
! '-mhard-float'
       Select software or hardware for floating point operations.  The
       default is software.
  
! '-mdouble-float'
!      When '-mhard-float' is selected, enables generation of
       double-precision floating point instructions.  By default functions
!      from 'libgcc' are used to perform double-precision floating point
       operations.
  
! '-munordered-float'
!      When '-mhard-float' is selected, enables generation of unordered
!      floating point compare and set flag ('lf.sfun*') instructions.  By
!      default functions from 'libgcc' are used to perform unordered
       floating point compare and set flag operations.
  
! '-mcmov'
!      Enable generation of conditional move ('l.cmov') instructions.  By
       default the equivalent will be generated using set and branch.
  
! '-mror'
!      Enable generation of rotate right ('l.ror') instructions.  By
!      default functions from 'libgcc' are used to perform rotate right
       operations.
  
! '-mrori'
!      Enable generation of rotate right with immediate ('l.rori')
!      instructions.  By default functions from 'libgcc' are used to
       perform rotate right with immediate operations.
  
! '-msext'
!      Enable generation of sign extension ('l.ext*') instructions.  By
       default memory loads are used to perform sign extension.
  
! '-msfimm'
!      Enable generation of compare and set flag with immediate ('l.sf*i')
       instructions.  By default extra instructions will be generated to
       store the immediate to a register first.
  
! '-mshftimm'
!      Enable generation of shift with immediate ('l.srai', 'l.srli',
!      'l.slli') instructions.  By default extra instructions will be
       generated to store the immediate to a register first.
  
! '-mcmodel=small'
       Generate OpenRISC code for the small model: The GOT is limited to
       64k.  This is the default model.
  
! '-mcmodel=large'
       Generate OpenRISC code for the large model: The GOT may grow up to
       4G in size.
  
--- 26497,26571 ----
  
  These options are defined for OpenRISC:
  
! ‘-mboard=NAME’
       Configure a board specific runtime.  This will be passed to the
!      linker for newlib board library linking.  The default is ‘or1ksim’.
  
! ‘-mnewlib’
       This option is ignored; it is for compatibility purposes only.
       This used to select linker and preprocessor options for use with
       newlib.
  
! ‘-msoft-div’
! ‘-mhard-div’
!      Select software or hardware divide (‘l.div’, ‘l.divu’)
       instructions.  This default is hardware divide.
  
! ‘-msoft-mul’
! ‘-mhard-mul’
!      Select software or hardware multiply (‘l.mul’, ‘l.muli’)
       instructions.  This default is hardware multiply.
  
! ‘-msoft-float’
! ‘-mhard-float’
       Select software or hardware for floating point operations.  The
       default is software.
  
! ‘-mdouble-float’
!      When ‘-mhard-float’ is selected, enables generation of
       double-precision floating point instructions.  By default functions
!      from ‘libgcc’ are used to perform double-precision floating point
       operations.
  
! ‘-munordered-float’
!      When ‘-mhard-float’ is selected, enables generation of unordered
!      floating point compare and set flag (‘lf.sfun*’) instructions.  By
!      default functions from ‘libgcc’ are used to perform unordered
       floating point compare and set flag operations.
  
! ‘-mcmov’
!      Enable generation of conditional move (‘l.cmov’) instructions.  By
       default the equivalent will be generated using set and branch.
  
! ‘-mror’
!      Enable generation of rotate right (‘l.ror’) instructions.  By
!      default functions from ‘libgcc’ are used to perform rotate right
       operations.
  
! ‘-mrori’
!      Enable generation of rotate right with immediate (‘l.rori’)
!      instructions.  By default functions from ‘libgcc’ are used to
       perform rotate right with immediate operations.
  
! ‘-msext’
!      Enable generation of sign extension (‘l.ext*’) instructions.  By
       default memory loads are used to perform sign extension.
  
! ‘-msfimm’
!      Enable generation of compare and set flag with immediate (‘l.sf*i’)
       instructions.  By default extra instructions will be generated to
       store the immediate to a register first.
  
! ‘-mshftimm’
!      Enable generation of shift with immediate (‘l.srai’, ‘l.srli’,
!      ‘l.slli’) instructions.  By default extra instructions will be
       generated to store the immediate to a register first.
  
! ‘-mcmodel=small’
       Generate OpenRISC code for the small model: The GOT is limited to
       64k.  This is the default model.
  
! ‘-mcmodel=large’
       Generate OpenRISC code for the large model: The GOT may grow up to
       4G in size.
  
*************** File: gcc.info,  Node: PDP-11 Options,
*** 26567,26616 ****
  
  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.)  Implies -m45.
  
! '-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.  Implies -msoft-float -mno-split.
  
! '-m45'
       Generate code for a PDP-11/45.  This is the default.
  
! '-m10'
       Generate code for a PDP-11/10.  Implies -msoft-float -mno-split.
  
! '-mint16'
! '-mno-int32'
!      Use 16-bit 'int'.  This is the default.
  
! '-mint32'
! '-mno-int16'
!      Use 32-bit 'int'.
  
! '-msplit'
       Target has split instruction and data space.  Implies -m45.
  
! '-munix-asm'
       Use Unix assembler syntax.
  
! '-mdec-asm'
       Use DEC assembler syntax.
  
! '-mgnu-asm'
       Use GNU assembler syntax.  This is the default.
  
! '-mlra'
       Use the new LRA register allocator.  By default, the old "reload"
       allocator is used.
  
--- 26577,26626 ----
  
  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.)  Implies -m45.
  
! ‘-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.  Implies -msoft-float -mno-split.
  
! ‘-m45’
       Generate code for a PDP-11/45.  This is the default.
  
! ‘-m10’
       Generate code for a PDP-11/10.  Implies -msoft-float -mno-split.
  
! ‘-mint16’
! ‘-mno-int32’
!      Use 16-bit ‘int’.  This is the default.
  
! ‘-mint32’
! ‘-mno-int16’
!      Use 32-bit ‘int’.
  
! ‘-msplit’
       Target has split instruction and data space.  Implies -m45.
  
! ‘-munix-asm’
       Use Unix assembler syntax.
  
! ‘-mdec-asm’
       Use DEC assembler syntax.
  
! ‘-mgnu-asm’
       Use GNU assembler syntax.  This is the default.
  
! ‘-mlra’
       Use the new LRA register allocator.  By default, the old "reload"
       allocator is used.
  
*************** File: gcc.info,  Node: PRU Options,  Nex
*** 26630,26636 ****
  
  These command-line options are defined for PRU target:
  
! '-minrt'
       Link with a minimum runtime environment, with no support for static
       initializers and constructors.  Using this option can significantly
       reduce the size of the final ELF binary.  Beware that the compiler
--- 26640,26646 ----
  
  These command-line options are defined for PRU target:
  
! ‘-minrt’
       Link with a minimum runtime environment, with no support for static
       initializers and constructors.  Using this option can significantly
       reduce the size of the final ELF binary.  Beware that the compiler
*************** These command-line options are defined f
*** 26638,26678 ****
       constructors.  It is up to the programmer to ensure that the source
       program will not use those features.
  
! '-mmcu=MCU'
       Specify the PRU MCU variant to use.  Check Newlib for the exact
       list of supported MCUs.
  
! '-mno-relax'
!      Make GCC pass the '--no-relax' command-line option to the linker
!      instead of the '--relax' option.
  
! '-mloop'
       Allow (or do not allow) GCC to use the LOOP instruction.
  
! '-mabi=VARIANT'
!      Specify the ABI variant to output code for.  '-mabi=ti' selects the
!      unmodified TI ABI while '-mabi=gnu' selects a GNU variant that
       copes more naturally with certain GCC assumptions.  These are the
       differences:
  
!      'Function Pointer Size'
            TI ABI specifies that function (code) pointers are 16-bit,
            whereas GNU supports only 32-bit data and code pointers.
  
!      'Optional Return Value Pointer'
            Function return values larger than 64 bits are passed by using
            a hidden pointer as the first argument of the function.  TI
            ABI, though, mandates that the pointer can be NULL in case the
            caller is not using the returned value.  GNU always passes and
            expects a valid return value pointer.
  
!      The current '-mabi=ti' implementation simply raises a compile error
       when any of the above code constructs is detected.  As a
       consequence the standard C library cannot be built and it is
!      omitted when linking with '-mabi=ti'.
  
       Relaxation is a GNU feature and for safety reasons is disabled when
!      using '-mabi=ti'.  The TI toolchain does not emit relocations for
       QBBx instructions, so the GNU linker cannot adjust them when
       shortening adjacent LDI32 pseudo instructions.
  
--- 26648,26688 ----
       constructors.  It is up to the programmer to ensure that the source
       program will not use those features.
  
! ‘-mmcu=MCU’
       Specify the PRU MCU variant to use.  Check Newlib for the exact
       list of supported MCUs.
  
! ‘-mno-relax’
!      Make GCC pass the ‘--no-relax’ command-line option to the linker
!      instead of the ‘--relax’ option.
  
! ‘-mloop’
       Allow (or do not allow) GCC to use the LOOP instruction.
  
! ‘-mabi=VARIANT’
!      Specify the ABI variant to output code for.  ‘-mabi=ti’ selects the
!      unmodified TI ABI while ‘-mabi=gnu’ selects a GNU variant that
       copes more naturally with certain GCC assumptions.  These are the
       differences:
  
!      ‘Function Pointer Size’
            TI ABI specifies that function (code) pointers are 16-bit,
            whereas GNU supports only 32-bit data and code pointers.
  
!      ‘Optional Return Value Pointer’
            Function return values larger than 64 bits are passed by using
            a hidden pointer as the first argument of the function.  TI
            ABI, though, mandates that the pointer can be NULL in case the
            caller is not using the returned value.  GNU always passes and
            expects a valid return value pointer.
  
!      The current ‘-mabi=ti’ implementation simply raises a compile error
       when any of the above code constructs is detected.  As a
       consequence the standard C library cannot be built and it is
!      omitted when linking with ‘-mabi=ti’.
  
       Relaxation is a GNU feature and for safety reasons is disabled when
!      using ‘-mabi=ti’.  The TI toolchain does not emit relocations for
       QBBx instructions, so the GNU linker cannot adjust them when
       shortening adjacent LDI32 pseudo instructions.
  
*************** File: gcc.info,  Node: RISC-V Options,
*** 26684,26809 ****
  
  These command-line options are defined for RISC-V targets:
  
! '-mbranch-cost=N'
       Set the cost of branches to roughly N instructions.
  
! '-mplt'
! '-mno-plt'
       When generating PIC code, do or don't allow the use of PLTs.
!      Ignored for non-PIC. The default is '-mplt'.
  
! '-mabi=ABI-STRING'
       Specify integer and floating-point calling convention.  ABI-STRING
       contains two parts: the size of integer types and the registers
!      used for floating-point types.  For example '-march=rv64ifd
!      -mabi=lp64d' means that 'long' and pointers are 64-bit (implicitly
!      defining 'int' to be 32-bit), and that floating-point values up to
       64 bits wide are passed in F registers.  Contrast this with
!      '-march=rv64ifd -mabi=lp64f', which still allows the compiler to
       generate code that uses the F and D extensions but only allows
       floating-point values up to 32 bits long to be passed in registers;
!      or '-march=rv64ifd -mabi=lp64', in which no floating-point
       arguments will be passed in registers.
  
       The default for this argument is system dependent, users who want a
       specific calling convention should specify one explicitly.  The
!      valid calling conventions are: 'ilp32', 'ilp32f', 'ilp32d', 'lp64',
!      'lp64f', and 'lp64d'.  Some calling conventions are impossible to
!      implement on some ISAs: for example, '-march=rv32if -mabi=ilp32d'
       is invalid because the ABI requires 64-bit values be passed in F
       registers, but F registers are only 32 bits wide.  There is also
!      the 'ilp32e' ABI that can only be used with the 'rv32e'
       architecture.  This ABI is not well specified at present, and is
       subject to change.
  
! '-mfdiv'
! '-mno-fdiv'
       Do or don't use hardware floating-point divide and square root
       instructions.  This requires the F or D extensions for
       floating-point registers.  The default is to use them if the
       specified architecture has these instructions.
  
! '-mdiv'
! '-mno-div'
       Do or don't use hardware instructions for integer division.  This
       requires the M extension.  The default is to use them if the
       specified architecture has these instructions.
  
! '-misa-spec=ISA-SPEC-STRING'
       Specify the version of the RISC-V Unprivileged (formerly
       User-Level) ISA specification to produce code conforming to.  The
       possibilities for ISA-SPEC-STRING are:
!      '2.2'
            Produce code conforming to version 2.2.
!      '20190608'
            Produce code conforming to version 20190608.
!      '20191213'
            Produce code conforming to version 20191213.
!      The default is '-misa-spec=20191213' unless GCC has been configured
!      with '--with-isa-spec=' specifying a different default version.
  
! '-march=ISA-STRING'
!      Generate code for given RISC-V ISA (e.g. 'rv64im').  ISA strings
!      must be lower-case.  Examples include 'rv64i', 'rv32g', 'rv32e',
!      and 'rv32imaf'.
  
!      When '-march=' is not specified, use the setting from '-mcpu'.
  
!      If both '-march' and '-mcpu=' are not specified, the default for
       this argument is system dependent, users who want a specific
       architecture extensions should specify one explicitly.
  
! '-mcpu=PROCESSOR-STRING'
       Use architecture of and optimize the output for the given
       processor, specified by particular CPU name.  Permissible values
!      for this option are: 'sifive-e20', 'sifive-e21', 'sifive-e24',
!      'sifive-e31', 'sifive-e34', 'sifive-e76', 'sifive-s21',
!      'sifive-s51', 'sifive-s54', 'sifive-s76', 'sifive-u54', and
!      'sifive-u74'.
  
! '-mtune=PROCESSOR-STRING'
       Optimize the output for the given processor, specified by
       microarchitecture or particular CPU name.  Permissible values for
!      this option are: 'rocket', 'sifive-3-series', 'sifive-5-series',
!      'sifive-7-series', 'thead-c906', 'size', and all valid options for
!      '-mcpu='.
  
!      When '-mtune=' is not specified, use the setting from '-mcpu', the
!      default is 'rocket' if both are not specified.
  
!      The 'size' choice is not intended for use by end-users.  This is
!      used when '-Os' is specified.  It overrides the instruction cost
!      info provided by '-mtune=', but does not override the pipeline
       info.  This helps reduce code size while still giving good
       performance.
  
! '-mpreferred-stack-boundary=NUM'
       Attempt to keep the stack boundary aligned to a 2 raised to NUM
!      byte boundary.  If '-mpreferred-stack-boundary' is not specified,
       the default is 4 (16 bytes or 128-bits).
  
       *Warning:* 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.
  
! '-msmall-data-limit=N'
       Put global and static data smaller than N bytes into a special
       section (on some targets).
  
! '-msave-restore'
! '-mno-save-restore'
       Do or don't use smaller but slower prologue and epilogue code that
       uses library function calls.  The default is to use fast inline
       prologues and epilogues.
  
! '-minline-atomics'
! '-mno-inline-atomics'
       Do or don't use smaller but slower subword atomic emulation code
       that uses libatomic function calls.  The default is to use fast
       inline subword atomics that do not require libatomic.
  
! '-mshorten-memrefs'
! '-mno-shorten-memrefs'
       Do or do not attempt to make more use of compressed load/store
       instructions by replacing a load/store of 'base register + large
       offset' with a new load/store of 'new base + small offset'.  If the
--- 26694,26819 ----
  
  These command-line options are defined for RISC-V targets:
  
! ‘-mbranch-cost=N’
       Set the cost of branches to roughly N instructions.
  
! ‘-mplt’
! ‘-mno-plt’
       When generating PIC code, do or don't allow the use of PLTs.
!      Ignored for non-PIC. The default is ‘-mplt’.
  
! ‘-mabi=ABI-STRING’
       Specify integer and floating-point calling convention.  ABI-STRING
       contains two parts: the size of integer types and the registers
!      used for floating-point types.  For example ‘-march=rv64ifd
!      -mabi=lp64d’ means that ‘long’ and pointers are 64-bit (implicitly
!      defining ‘int’ to be 32-bit), and that floating-point values up to
       64 bits wide are passed in F registers.  Contrast this with
!      ‘-march=rv64ifd -mabi=lp64f’, which still allows the compiler to
       generate code that uses the F and D extensions but only allows
       floating-point values up to 32 bits long to be passed in registers;
!      or ‘-march=rv64ifd -mabi=lp64’, in which no floating-point
       arguments will be passed in registers.
  
       The default for this argument is system dependent, users who want a
       specific calling convention should specify one explicitly.  The
!      valid calling conventions are: ‘ilp32’, ‘ilp32f’, ‘ilp32d’, ‘lp64’,
!      ‘lp64f’, and ‘lp64d’.  Some calling conventions are impossible to
!      implement on some ISAs: for example, ‘-march=rv32if -mabi=ilp32d’
       is invalid because the ABI requires 64-bit values be passed in F
       registers, but F registers are only 32 bits wide.  There is also
!      the ‘ilp32e’ ABI that can only be used with the ‘rv32e’
       architecture.  This ABI is not well specified at present, and is
       subject to change.
  
! ‘-mfdiv’
! ‘-mno-fdiv’
       Do or don't use hardware floating-point divide and square root
       instructions.  This requires the F or D extensions for
       floating-point registers.  The default is to use them if the
       specified architecture has these instructions.
  
! ‘-mdiv’
! ‘-mno-div’
       Do or don't use hardware instructions for integer division.  This
       requires the M extension.  The default is to use them if the
       specified architecture has these instructions.
  
! ‘-misa-spec=ISA-SPEC-STRING’
       Specify the version of the RISC-V Unprivileged (formerly
       User-Level) ISA specification to produce code conforming to.  The
       possibilities for ISA-SPEC-STRING are:
!      ‘2.2’
            Produce code conforming to version 2.2.
!      ‘20190608’
            Produce code conforming to version 20190608.
!      ‘20191213’
            Produce code conforming to version 20191213.
!      The default is ‘-misa-spec=20191213’ unless GCC has been configured
!      with ‘--with-isa-spec=’ specifying a different default version.
  
! ‘-march=ISA-STRING’
!      Generate code for given RISC-V ISA (e.g. ‘rv64im’).  ISA strings
!      must be lower-case.  Examples include ‘rv64i’, ‘rv32g’, ‘rv32e’,
!      and ‘rv32imaf’.
  
!      When ‘-march=’ is not specified, use the setting from ‘-mcpu’.
  
!      If both ‘-march’ and ‘-mcpu=’ are not specified, the default for
       this argument is system dependent, users who want a specific
       architecture extensions should specify one explicitly.
  
! ‘-mcpu=PROCESSOR-STRING’
       Use architecture of and optimize the output for the given
       processor, specified by particular CPU name.  Permissible values
!      for this option are: ‘sifive-e20’, ‘sifive-e21’, ‘sifive-e24’,
!      ‘sifive-e31’, ‘sifive-e34’, ‘sifive-e76’, ‘sifive-s21’,
!      ‘sifive-s51’, ‘sifive-s54’, ‘sifive-s76’, ‘sifive-u54’, and
!      ‘sifive-u74’.
  
! ‘-mtune=PROCESSOR-STRING’
       Optimize the output for the given processor, specified by
       microarchitecture or particular CPU name.  Permissible values for
!      this option are: ‘rocket’, ‘sifive-3-series’, ‘sifive-5-series’,
!      ‘sifive-7-series’, ‘thead-c906’, ‘size’, and all valid options for
!      ‘-mcpu=’.
  
!      When ‘-mtune=’ is not specified, use the setting from ‘-mcpu’, the
!      default is ‘rocket’ if both are not specified.
  
!      The ‘size’ choice is not intended for use by end-users.  This is
!      used when ‘-Os’ is specified.  It overrides the instruction cost
!      info provided by ‘-mtune=’, but does not override the pipeline
       info.  This helps reduce code size while still giving good
       performance.
  
! ‘-mpreferred-stack-boundary=NUM’
       Attempt to keep the stack boundary aligned to a 2 raised to NUM
!      byte boundary.  If ‘-mpreferred-stack-boundary’ is not specified,
       the default is 4 (16 bytes or 128-bits).
  
       *Warning:* 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.
  
! ‘-msmall-data-limit=N’
       Put global and static data smaller than N bytes into a special
       section (on some targets).
  
! ‘-msave-restore’
! ‘-mno-save-restore’
       Do or don't use smaller but slower prologue and epilogue code that
       uses library function calls.  The default is to use fast inline
       prologues and epilogues.
  
! ‘-minline-atomics’
! ‘-mno-inline-atomics’
       Do or don't use smaller but slower subword atomic emulation code
       that uses libatomic function calls.  The default is to use fast
       inline subword atomics that do not require libatomic.
  
! ‘-mshorten-memrefs’
! ‘-mno-shorten-memrefs’
       Do or do not attempt to make more use of compressed load/store
       instructions by replacing a load/store of 'base register + large
       offset' with a new load/store of 'new base + small offset'.  If the
*************** These command-line options are defined f
*** 26811,26830 ****
       load/store can be compressed.  Currently targets 32-bit integer
       load/stores only.
  
! '-mstrict-align'
! '-mno-strict-align'
       Do not or do generate unaligned memory accesses.  The default is
       set depending on whether the processor we are optimizing for
       supports fast unaligned access or not.
  
! '-mcmodel=medlow'
       Generate code for the medium-low code model.  The program and its
       statically defined symbols must lie within a single 2 GiB address
!      range and must lie between absolute addresses -2 GiB and +2 GiB.
       Programs can be statically or dynamically linked.  This is the
       default code model.
  
! '-mcmodel=medany'
       Generate code for the medium-any code model.  The program and its
       statically defined symbols must be within any single 2 GiB address
       range.  Programs can be statically or dynamically linked.
--- 26821,26840 ----
       load/store can be compressed.  Currently targets 32-bit integer
       load/stores only.
  
! ‘-mstrict-align’
! ‘-mno-strict-align’
       Do not or do generate unaligned memory accesses.  The default is
       set depending on whether the processor we are optimizing for
       supports fast unaligned access or not.
  
! ‘-mcmodel=medlow’
       Generate code for the medium-low code model.  The program and its
       statically defined symbols must lie within a single 2 GiB address
!      range and must lie between absolute addresses −2 GiB and +2 GiB.
       Programs can be statically or dynamically linked.  This is the
       default code model.
  
! ‘-mcmodel=medany’
       Generate code for the medium-any code model.  The program and its
       statically defined symbols must be within any single 2 GiB address
       range.  Programs can be statically or dynamically linked.
*************** These command-line options are defined f
*** 26833,26884 ****
       position-independent, but is not guaranteed to function correctly
       when linked into position-independent executables or libraries.
  
! '-mexplicit-relocs'
! '-mno-exlicit-relocs'
       Use or do not use assembler relocation operators when dealing with
       symbolic addresses.  The alternative is to use assembler macros
       instead, which may limit optimization.
  
! '-mrelax'
! '-mno-relax'
       Take advantage of linker relaxations to reduce the number of
       instructions required to materialize symbol addresses.  The default
       is to take advantage of linker relaxations.
  
! '-mriscv-attribute'
! '-mno-riscv-attribute'
       Emit (do not emit) RISC-V attribute to record extra information
       into ELF objects.  This feature requires at least binutils 2.32.
  
! '-mcsr-check'
! '-mno-csr-check'
       Enables or disables the CSR checking.
  
! '-malign-data=TYPE'
       Control how GCC aligns variables and constants of array, structure,
!      or union types.  Supported values for TYPE are 'xlen' which uses x
!      register width as the alignment value, and 'natural' which uses
!      natural alignment.  'xlen' is the default.
  
! '-mbig-endian'
       Generate big-endian code.  This is the default when GCC is
!      configured for a 'riscv64be-*-*' or 'riscv32be-*-*' target.
  
! '-mlittle-endian'
       Generate little-endian code.  This is the default when GCC is
!      configured for a 'riscv64-*-*' or 'riscv32-*-*' but not a
!      'riscv64be-*-*' or 'riscv32be-*-*' target.
  
! '-mstack-protector-guard=GUARD'
! '-mstack-protector-guard-reg=REG'
! '-mstack-protector-guard-offset=OFFSET'
       Generate stack protection code using canary at GUARD.  Supported
!      locations are 'global' for a global canary or 'tls' for per-thread
       canary in the TLS block.
  
       With the latter choice the options
!      '-mstack-protector-guard-reg=REG' and
!      '-mstack-protector-guard-offset=OFFSET' furthermore specify which
       register to use as base register for reading the canary, and from
       what offset from that base register.  There is no default register
       or offset as this is entirely for use within the Linux kernel.
--- 26843,26894 ----
       position-independent, but is not guaranteed to function correctly
       when linked into position-independent executables or libraries.
  
! ‘-mexplicit-relocs’
! ‘-mno-exlicit-relocs’
       Use or do not use assembler relocation operators when dealing with
       symbolic addresses.  The alternative is to use assembler macros
       instead, which may limit optimization.
  
! ‘-mrelax’
! ‘-mno-relax’
       Take advantage of linker relaxations to reduce the number of
       instructions required to materialize symbol addresses.  The default
       is to take advantage of linker relaxations.
  
! ‘-mriscv-attribute’
! ‘-mno-riscv-attribute’
       Emit (do not emit) RISC-V attribute to record extra information
       into ELF objects.  This feature requires at least binutils 2.32.
  
! ‘-mcsr-check’
! ‘-mno-csr-check’
       Enables or disables the CSR checking.
  
! ‘-malign-data=TYPE’
       Control how GCC aligns variables and constants of array, structure,
!      or union types.  Supported values for TYPE are ‘xlen’ which uses x
!      register width as the alignment value, and ‘natural’ which uses
!      natural alignment.  ‘xlen’ is the default.
  
! ‘-mbig-endian’
       Generate big-endian code.  This is the default when GCC is
!      configured for a ‘riscv64be-*-*’ or ‘riscv32be-*-*’ target.
  
! ‘-mlittle-endian’
       Generate little-endian code.  This is the default when GCC is
!      configured for a ‘riscv64-*-*’ or ‘riscv32-*-*’ but not a
!      ‘riscv64be-*-*’ or ‘riscv32be-*-*’ target.
  
! ‘-mstack-protector-guard=GUARD’
! ‘-mstack-protector-guard-reg=REG’
! ‘-mstack-protector-guard-offset=OFFSET’
       Generate stack protection code using canary at GUARD.  Supported
!      locations are ‘global’ for a global canary or ‘tls’ for per-thread
       canary in the TLS block.
  
       With the latter choice the options
!      ‘-mstack-protector-guard-reg=REG’ and
!      ‘-mstack-protector-guard-offset=OFFSET’ furthermore specify which
       register to use as base register for reading the canary, and from
       what offset from that base register.  There is no default register
       or offset as this is entirely for use within the Linux kernel.
*************** File: gcc.info,  Node: RL78 Options,  Ne
*** 26889,26920 ****
  3.19.41 RL78 Options
  --------------------
  
! '-msim'
       Links in additional target libraries to support operation within a
       simulator.
  
! '-mmul=none'
! '-mmul=g10'
! '-mmul=g13'
! '-mmul=g14'
! '-mmul=rl78'
       Specifies the type of hardware multiplication and division support
!      to be used.  The simplest is 'none', which uses software for both
!      multiplication and division.  This is the default.  The 'g13' value
       is for the hardware multiply/divide peripheral found on the
!      RL78/G13 (S2 core) targets.  The 'g14' value selects the use of the
       multiplication and division instructions supported by the RL78/G14
!      (S3 core) parts.  The value 'rl78' is an alias for 'g14' and the
!      value 'mg10' is an alias for 'none'.
  
       In addition a C preprocessor macro is defined, based upon the
!      setting of this option.  Possible values are: '__RL78_MUL_NONE__',
!      '__RL78_MUL_G13__' or '__RL78_MUL_G14__'.
  
! '-mcpu=g10'
! '-mcpu=g13'
! '-mcpu=g14'
! '-mcpu=rl78'
       Specifies the RL78 core to target.  The default is the G14 core,
       also known as an S3 core or just RL78.  The G13 or S2 core does not
       have multiply or divide instructions, instead it uses a hardware
--- 26899,26930 ----
  3.19.41 RL78 Options
  --------------------
  
! ‘-msim’
       Links in additional target libraries to support operation within a
       simulator.
  
! ‘-mmul=none’
! ‘-mmul=g10’
! ‘-mmul=g13’
! ‘-mmul=g14’
! ‘-mmul=rl78’
       Specifies the type of hardware multiplication and division support
!      to be used.  The simplest is ‘none’, which uses software for both
!      multiplication and division.  This is the default.  The ‘g13’ value
       is for the hardware multiply/divide peripheral found on the
!      RL78/G13 (S2 core) targets.  The ‘g14’ value selects the use of the
       multiplication and division instructions supported by the RL78/G14
!      (S3 core) parts.  The value ‘rl78’ is an alias for ‘g14’ and the
!      value ‘mg10’ is an alias for ‘none’.
  
       In addition a C preprocessor macro is defined, based upon the
!      setting of this option.  Possible values are: ‘__RL78_MUL_NONE__’,
!      ‘__RL78_MUL_G13__’ or ‘__RL78_MUL_G14__’.
  
! ‘-mcpu=g10’
! ‘-mcpu=g13’
! ‘-mcpu=g14’
! ‘-mcpu=rl78’
       Specifies the RL78 core to target.  The default is the G14 core,
       also known as an S3 core or just RL78.  The G13 or S2 core does not
       have multiply or divide instructions, instead it uses a hardware
*************** File: gcc.info,  Node: RL78 Options,  Ne
*** 26923,26935 ****
  
       If this option is set it also selects the type of hardware multiply
       support to use, unless this is overridden by an explicit
!      '-mmul=none' option on the command line.  Thus specifying
!      '-mcpu=g13' enables the use of the G13 hardware multiply peripheral
!      and specifying '-mcpu=g10' disables the use of hardware
       multiplications altogether.
  
       Note, although the RL78/G14 core is the default target, specifying
!      '-mcpu=g14' or '-mcpu=rl78' on the command line does change the
       behavior of the toolchain since it also enables G14 hardware
       multiply support.  If these options are not specified on the
       command line then software multiplication routines will be used
--- 26933,26945 ----
  
       If this option is set it also selects the type of hardware multiply
       support to use, unless this is overridden by an explicit
!      ‘-mmul=none’ option on the command line.  Thus specifying
!      ‘-mcpu=g13’ enables the use of the G13 hardware multiply peripheral
!      and specifying ‘-mcpu=g10’ disables the use of hardware
       multiplications altogether.
  
       Note, although the RL78/G14 core is the default target, specifying
!      ‘-mcpu=g14’ or ‘-mcpu=rl78’ on the command line does change the
       behavior of the toolchain since it also enables G14 hardware
       multiply support.  If these options are not specified on the
       command line then software multiplication routines will be used
*************** File: gcc.info,  Node: RL78 Options,  Ne
*** 26938,26967 ****
       multiply and divide support.
  
       In addition a C preprocessor macro is defined, based upon the
!      setting of this option.  Possible values are: '__RL78_G10__',
!      '__RL78_G13__' or '__RL78_G14__'.
  
! '-mg10'
! '-mg13'
! '-mg14'
! '-mrl78'
!      These are aliases for the corresponding '-mcpu=' option.  They are
       provided for backwards compatibility.
  
! '-mallregs'
       Allow the compiler to use all of the available registers.  By
!      default registers 'r24..r31' are reserved for use in interrupt
       handlers.  With this option enabled these registers can be used in
       ordinary functions as well.
  
! '-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'.
  
! '-msave-mduc-in-interrupts'
! '-mno-save-mduc-in-interrupts'
       Specifies that interrupt handler functions should preserve the MDUC
       registers.  This is only necessary if normal code might use the
       MDUC registers, for example because it performs multiplication and
--- 26948,26977 ----
       multiply and divide support.
  
       In addition a C preprocessor macro is defined, based upon the
!      setting of this option.  Possible values are: ‘__RL78_G10__’,
!      ‘__RL78_G13__’ or ‘__RL78_G14__’.
  
! ‘-mg10’
! ‘-mg13’
! ‘-mg14’
! ‘-mrl78’
!      These are aliases for the corresponding ‘-mcpu=’ option.  They are
       provided for backwards compatibility.
  
! ‘-mallregs’
       Allow the compiler to use all of the available registers.  By
!      default registers ‘r24..r31’ are reserved for use in interrupt
       handlers.  With this option enabled these registers can be used in
       ordinary functions as well.
  
! ‘-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’.
  
! ‘-msave-mduc-in-interrupts’
! ‘-mno-save-mduc-in-interrupts’
       Specifies that interrupt handler functions should preserve the MDUC
       registers.  This is only necessary if normal code might use the
       MDUC registers, for example because it performs multiplication and
*************** File: gcc.info,  Node: RS/6000 and Power
*** 26978,27066 ****
  3.19.42 IBM RS/6000 and PowerPC Options
  ---------------------------------------
  
! These '-m' options are defined for the IBM RS/6000 and PowerPC:
! '-mpowerpc-gpopt'
! '-mno-powerpc-gpopt'
! '-mpowerpc-gfxopt'
! '-mno-powerpc-gfxopt'
! '-mpowerpc64'
! '-mno-powerpc64'
! '-mmfcrf'
! '-mno-mfcrf'
! '-mpopcntb'
! '-mno-popcntb'
! '-mpopcntd'
! '-mno-popcntd'
! '-mfprnd'
! '-mno-fprnd'
! '-mcmpb'
! '-mno-cmpb'
! '-mhard-dfp'
! '-mno-hard-dfp'
       You use these options to specify which instructions are available
       on the processor you are using.  The default value of these options
       is determined when configuring GCC.  Specifying the
!      '-mcpu=CPU_TYPE' overrides the specification of these options.  We
!      recommend you use the '-mcpu=CPU_TYPE' option rather than the
       options listed above.
  
!      Specifying '-mpowerpc-gpopt' allows GCC to use the optional PowerPC
       architecture instructions in the General Purpose group, including
!      floating-point square root.  Specifying '-mpowerpc-gfxopt' allows
       GCC to use the optional PowerPC architecture instructions in the
       Graphics group, including floating-point select.
  
!      The '-mmfcrf' option allows GCC to generate the move from condition
       register field instruction implemented on the POWER4 processor and
       other processors that support the PowerPC V2.01 architecture.  The
!      '-mpopcntb' option allows GCC to generate the popcount and
       double-precision FP reciprocal estimate instruction implemented on
       the POWER5 processor and other processors that support the PowerPC
!      V2.02 architecture.  The '-mpopcntd' option allows GCC to generate
       the popcount instruction implemented on the POWER7 processor and
       other processors that support the PowerPC V2.06 architecture.  The
!      '-mfprnd' option allows GCC to generate the FP round to integer
       instructions implemented on the POWER5+ processor and other
       processors that support the PowerPC V2.03 architecture.  The
!      '-mcmpb' option allows GCC to generate the compare bytes
       instruction implemented on the POWER6 processor and other
       processors that support the PowerPC V2.05 architecture.  The
!      '-mhard-dfp' option allows GCC to generate the decimal
       floating-point instructions implemented on some POWER processors.
  
!      The '-mpowerpc64' option allows GCC to generate the additional
       64-bit instructions that are found in the full PowerPC64
       architecture and to treat GPRs as 64-bit, doubleword quantities.
!      GCC defaults to '-mno-powerpc64'.
  
! '-mcpu=CPU_TYPE'
       Set architecture type, register usage, and instruction scheduling
       parameters for machine type CPU_TYPE.  Supported values for
!      CPU_TYPE are '401', '403', '405', '405fp', '440', '440fp', '464',
!      '464fp', '476', '476fp', '505', '601', '602', '603', '603e', '604',
!      '604e', '620', '630', '740', '7400', '7450', '750', '801', '821',
!      '823', '860', '970', '8540', 'a2', 'e300c2', 'e300c3', 'e500mc',
!      'e500mc64', 'e5500', 'e6500', 'ec603e', 'G3', 'G4', 'G5', 'titan',
!      'power3', 'power4', 'power5', 'power5+', 'power6', 'power6x',
!      'power7', 'power8', 'power9', 'power10', 'powerpc', 'powerpc64',
!      'powerpc64le', 'rs64', and 'native'.
  
!      '-mcpu=powerpc', '-mcpu=powerpc64', and '-mcpu=powerpc64le' specify
       pure 32-bit PowerPC (either endian), 64-bit big endian PowerPC and
       64-bit little endian PowerPC architecture machine types, with an
       appropriate, generic processor model assumed for scheduling
       purposes.
  
!      Specifying 'native' as cpu type detects and selects the
       architecture option that corresponds to the host processor of the
!      system performing the compilation.  '-mcpu=native' has no effect if
       GCC does not recognize the processor.
  
       The other options specify a specific processor.  Code generated
       under those options runs best on that processor, and may not run at
       all on others.
  
!      The '-mcpu' options automatically enable or disable the following
       options:
  
            -maltivec  -mfprnd  -mhard-float  -mmfcrf  -mmultiple
--- 26988,27076 ----
  3.19.42 IBM RS/6000 and PowerPC Options
  ---------------------------------------
  
! These ‘-m’ options are defined for the IBM RS/6000 and PowerPC:
! ‘-mpowerpc-gpopt’
! ‘-mno-powerpc-gpopt’
! ‘-mpowerpc-gfxopt’
! ‘-mno-powerpc-gfxopt’
! ‘-mpowerpc64’
! ‘-mno-powerpc64’
! ‘-mmfcrf’
! ‘-mno-mfcrf’
! ‘-mpopcntb’
! ‘-mno-popcntb’
! ‘-mpopcntd’
! ‘-mno-popcntd’
! ‘-mfprnd’
! ‘-mno-fprnd’
! ‘-mcmpb’
! ‘-mno-cmpb’
! ‘-mhard-dfp’
! ‘-mno-hard-dfp’
       You use these options to specify which instructions are available
       on the processor you are using.  The default value of these options
       is determined when configuring GCC.  Specifying the
!      ‘-mcpu=CPU_TYPE’ overrides the specification of these options.  We
!      recommend you use the ‘-mcpu=CPU_TYPE’ option rather than the
       options listed above.
  
!      Specifying ‘-mpowerpc-gpopt’ allows GCC to use the optional PowerPC
       architecture instructions in the General Purpose group, including
!      floating-point square root.  Specifying ‘-mpowerpc-gfxopt’ allows
       GCC to use the optional PowerPC architecture instructions in the
       Graphics group, including floating-point select.
  
!      The ‘-mmfcrf’ option allows GCC to generate the move from condition
       register field instruction implemented on the POWER4 processor and
       other processors that support the PowerPC V2.01 architecture.  The
!      ‘-mpopcntb’ option allows GCC to generate the popcount and
       double-precision FP reciprocal estimate instruction implemented on
       the POWER5 processor and other processors that support the PowerPC
!      V2.02 architecture.  The ‘-mpopcntd’ option allows GCC to generate
       the popcount instruction implemented on the POWER7 processor and
       other processors that support the PowerPC V2.06 architecture.  The
!      ‘-mfprnd’ option allows GCC to generate the FP round to integer
       instructions implemented on the POWER5+ processor and other
       processors that support the PowerPC V2.03 architecture.  The
!      ‘-mcmpb’ option allows GCC to generate the compare bytes
       instruction implemented on the POWER6 processor and other
       processors that support the PowerPC V2.05 architecture.  The
!      ‘-mhard-dfp’ option allows GCC to generate the decimal
       floating-point instructions implemented on some POWER processors.
  
!      The ‘-mpowerpc64’ option allows GCC to generate the additional
       64-bit instructions that are found in the full PowerPC64
       architecture and to treat GPRs as 64-bit, doubleword quantities.
!      GCC defaults to ‘-mno-powerpc64’.
  
! ‘-mcpu=CPU_TYPE’
       Set architecture type, register usage, and instruction scheduling
       parameters for machine type CPU_TYPE.  Supported values for
!      CPU_TYPE are ‘401’, ‘403’, ‘405’, ‘405fp’, ‘440’, ‘440fp’, ‘464’,
!      ‘464fp’, ‘476’, ‘476fp’, ‘505’, ‘601’, ‘602’, ‘603’, ‘603e’, ‘604’,
!      ‘604e’, ‘620’, ‘630’, ‘740’, ‘7400’, ‘7450’, ‘750’, ‘801’, ‘821’,
!      ‘823’, ‘860’, ‘970’, ‘8540’, ‘a2’, ‘e300c2’, ‘e300c3’, ‘e500mc’,
!      ‘e500mc64’, ‘e5500’, ‘e6500’, ‘ec603e’, ‘G3’, ‘G4’, ‘G5’, ‘titan’,
!      ‘power3’, ‘power4’, ‘power5’, ‘power5+’, ‘power6’, ‘power6x’,
!      ‘power7’, ‘power8’, ‘power9’, ‘power10’, ‘powerpc’, ‘powerpc64’,
!      ‘powerpc64le’, ‘rs64’, and ‘native’.
  
!      ‘-mcpu=powerpc’, ‘-mcpu=powerpc64’, and ‘-mcpu=powerpc64le’ specify
       pure 32-bit PowerPC (either endian), 64-bit big endian PowerPC and
       64-bit little endian PowerPC architecture machine types, with an
       appropriate, generic processor model assumed for scheduling
       purposes.
  
!      Specifying ‘native’ as cpu type detects and selects the
       architecture option that corresponds to the host processor of the
!      system performing the compilation.  ‘-mcpu=native’ has no effect if
       GCC does not recognize the processor.
  
       The other options specify a specific processor.  Code generated
       under those options runs best on that processor, and may not run at
       all on others.
  
!      The ‘-mcpu’ options automatically enable or disable the following
       options:
  
            -maltivec  -mfprnd  -mhard-float  -mmfcrf  -mmultiple
*************** These '-m' options are defined for the I
*** 27076,27235 ****
       compiler versions, depending on what setting seems to produce
       optimal code for that CPU; it doesn't necessarily reflect the
       actual hardware's capabilities.  If you wish to set an individual
!      option to a particular value, you may specify it after the '-mcpu'
!      option, like '-mcpu=970 -mno-altivec'.
  
!      On AIX, the '-maltivec' and '-mpowerpc64' options are not enabled
!      or disabled by the '-mcpu' option at present because AIX does not
       have full support for these options.  You may still enable or
       disable them individually if you're sure it'll work in your
       environment.
  
! '-mtune=CPU_TYPE'
       Set the instruction scheduling parameters for machine type
       CPU_TYPE, but do not set the architecture type or register usage,
!      as '-mcpu=CPU_TYPE' does.  The same values for CPU_TYPE are used
!      for '-mtune' as for '-mcpu'.  If both are specified, the code
!      generated uses the architecture and registers set by '-mcpu', but
!      the scheduling parameters set by '-mtune'.
  
! '-mcmodel=small'
       Generate PowerPC64 code for the small model: The TOC is limited to
       64k.
  
! '-mcmodel=medium'
       Generate PowerPC64 code for the medium model: The TOC and other
       static data may be up to a total of 4G in size.  This is the
       default for 64-bit Linux.
  
! '-mcmodel=large'
       Generate PowerPC64 code for the large model: The TOC may be up to
       4G in size.  Other data and code is only limited by the 64-bit
       address space.
  
! '-maltivec'
! '-mno-altivec'
       Generate code that uses (does not use) AltiVec instructions, and
       also enable the use of built-in functions that allow more direct
       access to the AltiVec instruction set.  You may also need to set
!      '-mabi=altivec' to adjust the current ABI with AltiVec ABI
       enhancements.
  
!      When '-maltivec' is used, the element order for AltiVec intrinsics
!      such as 'vec_splat', 'vec_extract', and 'vec_insert' match array
       element order corresponding to the endianness of the target.  That
       is, element zero identifies the leftmost element in a vector
       register when targeting a big-endian platform, and identifies the
       rightmost element in a vector register when targeting a
       little-endian platform.
  
! '-mvrsave'
! '-mno-vrsave'
       Generate VRSAVE instructions when generating AltiVec code.
  
! '-msecure-plt'
!      Generate code that allows 'ld' and 'ld.so' to build executables and
!      shared libraries with non-executable '.plt' and '.got' sections.
       This is a PowerPC 32-bit SYSV ABI option.
  
! '-mbss-plt'
!      Generate code that uses a BSS '.plt' section that 'ld.so' fills in,
!      and requires '.plt' and '.got' sections that are both writable and
       executable.  This is a PowerPC 32-bit SYSV ABI option.
  
! '-misel'
! '-mno-isel'
       This switch enables or disables the generation of ISEL
       instructions.
  
! '-mvsx'
! '-mno-vsx'
       Generate code that uses (does not use) vector/scalar (VSX)
       instructions, and also enable the use of built-in functions that
       allow more direct access to the VSX instruction set.
  
! '-mcrypto'
! '-mno-crypto'
       Enable the use (disable) of the built-in functions that allow
       direct access to the cryptographic instructions that were added in
       version 2.07 of the PowerPC ISA.
  
! '-mhtm'
! '-mno-htm'
       Enable (disable) the use of the built-in functions that allow
       direct access to the Hardware Transactional Memory (HTM)
       instructions that were added in version 2.07 of the PowerPC ISA.
  
! '-mpower8-fusion'
! '-mno-power8-fusion'
       Generate code that keeps (does not keeps) some integer operations
       adjacent so that the instructions can be fused together on power8
       and later processors.
  
! '-mpower8-vector'
! '-mno-power8-vector'
       Generate code that uses (does not use) the vector and scalar
       instructions that were added in version 2.07 of the PowerPC ISA.
       Also enable the use of built-in functions that allow more direct
       access to the vector instructions.
  
! '-mquad-memory'
! '-mno-quad-memory'
       Generate code that uses (does not use) the non-atomic quad word
!      memory instructions.  The '-mquad-memory' option requires use of
       64-bit mode.
  
! '-mquad-memory-atomic'
! '-mno-quad-memory-atomic'
       Generate code that uses (does not use) the atomic quad word memory
!      instructions.  The '-mquad-memory-atomic' option requires use of
       64-bit mode.
  
! '-mfloat128'
! '-mno-float128'
       Enable/disable the __FLOAT128 keyword for IEEE 128-bit floating
       point and use either software emulation for IEEE 128-bit floating
       point or hardware instructions.
  
!      The VSX instruction set ('-mvsx') must be enabled to use the IEEE
       128-bit floating point support.  The IEEE 128-bit floating point is
       only supported on Linux.
  
!      The default for '-mfloat128' is enabled on PowerPC Linux systems
       using the VSX instruction set, and disabled on other systems.
  
!      If you use the ISA 3.0 instruction set ('-mpower9-vector' or
!      '-mcpu=power9') on a 64-bit system, the IEEE 128-bit floating point
       support will also enable the generation of ISA 3.0 IEEE 128-bit
       floating point instructions.  Otherwise, if you do not specify to
       generate ISA 3.0 instructions or you are targeting a 32-bit big
       endian system, IEEE 128-bit floating point will be done with
       software emulation.
  
! '-mfloat128-hardware'
! '-mno-float128-hardware'
       Enable/disable using ISA 3.0 hardware instructions to support the
       __FLOAT128 data type.
  
!      The default for '-mfloat128-hardware' is enabled on PowerPC Linux
       systems using the ISA 3.0 instruction set, and disabled on other
       systems.
  
! '-m32'
! '-m64'
       Generate code for 32-bit or 64-bit environments of Darwin and SVR4
       targets (including GNU/Linux).  The 32-bit environment sets int,
       long and pointer to 32 bits and generates code that runs on any
       PowerPC variant.  The 64-bit environment sets int to 32 bits and
       long and pointer to 64 bits, and generates code for PowerPC64, as
!      for '-mpowerpc64'.
  
! '-mfull-toc'
! '-mno-fp-in-toc'
! '-mno-sum-in-toc'
! '-mminimal-toc'
       Modify generation of the TOC (Table Of Contents), which is created
!      for every executable file.  The '-mfull-toc' option is selected by
       default.  In that case, GCC allocates at least one TOC entry for
       each unique non-automatic variable reference in your program.  GCC
       also places floating-point constants in the TOC.  However, only
--- 27086,27245 ----
       compiler versions, depending on what setting seems to produce
       optimal code for that CPU; it doesn't necessarily reflect the
       actual hardware's capabilities.  If you wish to set an individual
!      option to a particular value, you may specify it after the ‘-mcpu’
!      option, like ‘-mcpu=970 -mno-altivec’.
  
!      On AIX, the ‘-maltivec’ and ‘-mpowerpc64’ options are not enabled
!      or disabled by the ‘-mcpu’ option at present because AIX does not
       have full support for these options.  You may still enable or
       disable them individually if you're sure it'll work in your
       environment.
  
! ‘-mtune=CPU_TYPE’
       Set the instruction scheduling parameters for machine type
       CPU_TYPE, but do not set the architecture type or register usage,
!      as ‘-mcpu=CPU_TYPE’ does.  The same values for CPU_TYPE are used
!      for ‘-mtune’ as for ‘-mcpu’.  If both are specified, the code
!      generated uses the architecture and registers set by ‘-mcpu’, but
!      the scheduling parameters set by ‘-mtune’.
  
! ‘-mcmodel=small’
       Generate PowerPC64 code for the small model: The TOC is limited to
       64k.
  
! ‘-mcmodel=medium’
       Generate PowerPC64 code for the medium model: The TOC and other
       static data may be up to a total of 4G in size.  This is the
       default for 64-bit Linux.
  
! ‘-mcmodel=large’
       Generate PowerPC64 code for the large model: The TOC may be up to
       4G in size.  Other data and code is only limited by the 64-bit
       address space.
  
! ‘-maltivec’
! ‘-mno-altivec’
       Generate code that uses (does not use) AltiVec instructions, and
       also enable the use of built-in functions that allow more direct
       access to the AltiVec instruction set.  You may also need to set
!      ‘-mabi=altivec’ to adjust the current ABI with AltiVec ABI
       enhancements.
  
!      When ‘-maltivec’ is used, the element order for AltiVec intrinsics
!      such as ‘vec_splat’, ‘vec_extract’, and ‘vec_insert’ match array
       element order corresponding to the endianness of the target.  That
       is, element zero identifies the leftmost element in a vector
       register when targeting a big-endian platform, and identifies the
       rightmost element in a vector register when targeting a
       little-endian platform.
  
! ‘-mvrsave’
! ‘-mno-vrsave’
       Generate VRSAVE instructions when generating AltiVec code.
  
! ‘-msecure-plt’
!      Generate code that allows ‘ld’ and ‘ld.so’ to build executables and
!      shared libraries with non-executable ‘.plt’ and ‘.got’ sections.
       This is a PowerPC 32-bit SYSV ABI option.
  
! ‘-mbss-plt’
!      Generate code that uses a BSS ‘.plt’ section that ‘ld.so’ fills in,
!      and requires ‘.plt’ and ‘.got’ sections that are both writable and
       executable.  This is a PowerPC 32-bit SYSV ABI option.
  
! ‘-misel’
! ‘-mno-isel’
       This switch enables or disables the generation of ISEL
       instructions.
  
! ‘-mvsx’
! ‘-mno-vsx’
       Generate code that uses (does not use) vector/scalar (VSX)
       instructions, and also enable the use of built-in functions that
       allow more direct access to the VSX instruction set.
  
! ‘-mcrypto’
! ‘-mno-crypto’
       Enable the use (disable) of the built-in functions that allow
       direct access to the cryptographic instructions that were added in
       version 2.07 of the PowerPC ISA.
  
! ‘-mhtm’
! ‘-mno-htm’
       Enable (disable) the use of the built-in functions that allow
       direct access to the Hardware Transactional Memory (HTM)
       instructions that were added in version 2.07 of the PowerPC ISA.
  
! ‘-mpower8-fusion’
! ‘-mno-power8-fusion’
       Generate code that keeps (does not keeps) some integer operations
       adjacent so that the instructions can be fused together on power8
       and later processors.
  
! ‘-mpower8-vector’
! ‘-mno-power8-vector’
       Generate code that uses (does not use) the vector and scalar
       instructions that were added in version 2.07 of the PowerPC ISA.
       Also enable the use of built-in functions that allow more direct
       access to the vector instructions.
  
! ‘-mquad-memory’
! ‘-mno-quad-memory’
       Generate code that uses (does not use) the non-atomic quad word
!      memory instructions.  The ‘-mquad-memory’ option requires use of
       64-bit mode.
  
! ‘-mquad-memory-atomic’
! ‘-mno-quad-memory-atomic’
       Generate code that uses (does not use) the atomic quad word memory
!      instructions.  The ‘-mquad-memory-atomic’ option requires use of
       64-bit mode.
  
! ‘-mfloat128’
! ‘-mno-float128’
       Enable/disable the __FLOAT128 keyword for IEEE 128-bit floating
       point and use either software emulation for IEEE 128-bit floating
       point or hardware instructions.
  
!      The VSX instruction set (‘-mvsx’) must be enabled to use the IEEE
       128-bit floating point support.  The IEEE 128-bit floating point is
       only supported on Linux.
  
!      The default for ‘-mfloat128’ is enabled on PowerPC Linux systems
       using the VSX instruction set, and disabled on other systems.
  
!      If you use the ISA 3.0 instruction set (‘-mpower9-vector’ or
!      ‘-mcpu=power9’) on a 64-bit system, the IEEE 128-bit floating point
       support will also enable the generation of ISA 3.0 IEEE 128-bit
       floating point instructions.  Otherwise, if you do not specify to
       generate ISA 3.0 instructions or you are targeting a 32-bit big
       endian system, IEEE 128-bit floating point will be done with
       software emulation.
  
! ‘-mfloat128-hardware’
! ‘-mno-float128-hardware’
       Enable/disable using ISA 3.0 hardware instructions to support the
       __FLOAT128 data type.
  
!      The default for ‘-mfloat128-hardware’ is enabled on PowerPC Linux
       systems using the ISA 3.0 instruction set, and disabled on other
       systems.
  
! ‘-m32’
! ‘-m64’
       Generate code for 32-bit or 64-bit environments of Darwin and SVR4
       targets (including GNU/Linux).  The 32-bit environment sets int,
       long and pointer to 32 bits and generates code that runs on any
       PowerPC variant.  The 64-bit environment sets int to 32 bits and
       long and pointer to 64 bits, and generates code for PowerPC64, as
!      for ‘-mpowerpc64’.
  
! ‘-mfull-toc’
! ‘-mno-fp-in-toc’
! ‘-mno-sum-in-toc’
! ‘-mminimal-toc’
       Modify generation of the TOC (Table Of Contents), which is created
!      for every executable file.  The ‘-mfull-toc’ option is selected by
       default.  In that case, GCC allocates at least one TOC entry for
       each unique non-automatic variable reference in your program.  GCC
       also places floating-point constants in the TOC.  However, only
*************** These '-m' options are defined for the I
*** 27237,27268 ****
  
       If you receive a linker error message that saying you have
       overflowed the available TOC space, you can reduce the amount of
!      TOC space used with the '-mno-fp-in-toc' and '-mno-sum-in-toc'
!      options.  '-mno-fp-in-toc' prevents GCC from putting floating-point
!      constants in the TOC and '-mno-sum-in-toc' forces GCC to generate
       code to calculate the sum of an address and a constant at run time
       instead of putting that sum into the TOC.  You may specify one or
       both of these options.  Each causes GCC to produce very slightly
       slower and larger code at the expense of conserving TOC space.
  
       If you still run out of space in the TOC even when you specify both
!      of these options, specify '-mminimal-toc' instead.  This option
       causes GCC to make only one TOC entry for every file.  When you
       specify this option, GCC produces code that is slower and larger
       but which uses extremely little TOC space.  You may wish to use
       this option only on files that contain less frequently-executed
       code.
  
! '-maix64'
! '-maix32'
       Enable 64-bit AIX ABI and calling convention: 64-bit pointers,
!      64-bit 'long' type, and the infrastructure needed to support them.
!      Specifying '-maix64' implies '-mpowerpc64', while '-maix32'
!      disables the 64-bit ABI and implies '-mno-powerpc64'.  GCC defaults
!      to '-maix32'.
  
! '-mxl-compat'
! '-mno-xl-compat'
       Produce code that conforms more closely to IBM XL compiler
       semantics when using AIX-compatible ABI.  Pass floating-point
       arguments to prototyped functions beyond the register save area
--- 27247,27278 ----
  
       If you receive a linker error message that saying you have
       overflowed the available TOC space, you can reduce the amount of
!      TOC space used with the ‘-mno-fp-in-toc’ and ‘-mno-sum-in-toc’
!      options.  ‘-mno-fp-in-toc’ prevents GCC from putting floating-point
!      constants in the TOC and ‘-mno-sum-in-toc’ forces GCC to generate
       code to calculate the sum of an address and a constant at run time
       instead of putting that sum into the TOC.  You may specify one or
       both of these options.  Each causes GCC to produce very slightly
       slower and larger code at the expense of conserving TOC space.
  
       If you still run out of space in the TOC even when you specify both
!      of these options, specify ‘-mminimal-toc’ instead.  This option
       causes GCC to make only one TOC entry for every file.  When you
       specify this option, GCC produces code that is slower and larger
       but which uses extremely little TOC space.  You may wish to use
       this option only on files that contain less frequently-executed
       code.
  
! ‘-maix64’
! ‘-maix32’
       Enable 64-bit AIX ABI and calling convention: 64-bit pointers,
!      64-bit ‘long’ type, and the infrastructure needed to support them.
!      Specifying ‘-maix64’ implies ‘-mpowerpc64’, while ‘-maix32’
!      disables the 64-bit ABI and implies ‘-mno-powerpc64’.  GCC defaults
!      to ‘-maix32’.
  
! ‘-mxl-compat’
! ‘-mno-xl-compat’
       Produce code that conforms more closely to IBM XL compiler
       semantics when using AIX-compatible ABI.  Pass floating-point
       arguments to prototyped functions beyond the register save area
*************** These '-m' options are defined for the I
*** 27281,27337 ****
       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.
  
! '-mmultiple'
! '-mno-multiple'
       Generate code that uses (does not use) the load multiple word
       instructions and the store multiple word instructions.  These
       instructions are generated by default on POWER systems, and not
!      generated on PowerPC systems.  Do not use '-mmultiple' on
       little-endian PowerPC systems, since those instructions do not work
       when the processor is in little-endian mode.  The exceptions are
       PPC740 and PPC750 which permit these instructions in little-endian
       mode.
  
! '-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,
--- 27291,27347 ----
       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.
  
! ‘-mmultiple’
! ‘-mno-multiple’
       Generate code that uses (does not use) the load multiple word
       instructions and the store multiple word instructions.  These
       instructions are generated by default on POWER systems, and not
!      generated on PowerPC systems.  Do not use ‘-mmultiple’ on
       little-endian PowerPC systems, since those instructions do not work
       when the processor is in little-endian mode.  The exceptions are
       PPC740 and PPC750 which permit these instructions in little-endian
       mode.
  
! ‘-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,
*************** These '-m' options are defined for the I
*** 27339,27474 ****
       boundary.  This option is enabled by default when targeting Power6
       and disabled otherwise.
  
! '-mfused-madd'
! '-mno-fused-madd'
       Generate code that uses (does not use) the floating-point multiply
       and accumulate instructions.  These instructions are generated by
       default if hardware floating point is used.  The machine-dependent
!      '-mfused-madd' option is now mapped to the machine-independent
!      '-ffp-contract=fast' option, and '-mno-fused-madd' is mapped to
!      '-ffp-contract=off'.
  
! '-mmulhw'
! '-mno-mulhw'
       Generate code that uses (does not use) the half-word multiply and
       multiply-accumulate instructions on the IBM 405, 440, 464 and 476
       processors.  These instructions are generated by default when
       targeting those processors.
  
! '-mdlmzb'
! '-mno-dlmzb'
!      Generate code that uses (does not use) the string-search 'dlmzb'
       instruction on the IBM 405, 440, 464 and 476 processors.  This
       instruction is generated by default when targeting those
       processors.
  
! '-mno-bit-align'
! '-mbit-align'
       On System V.4 and embedded PowerPC systems do not (do) force
       structures and unions that contain bit-fields to be aligned to the
       base type of the bit-field.
  
       For example, by default a structure containing nothing but 8
!      'unsigned' bit-fields of length 1 is aligned to a 4-byte boundary
!      and has a size of 4 bytes.  By using '-mno-bit-align', the
       structure is aligned to a 1-byte boundary and is 1 byte in size.
  
! '-mno-strict-align'
! '-mstrict-align'
       On System V.4 and embedded PowerPC systems do not (do) assume that
       unaligned memory references are handled by the system.
  
! '-mrelocatable'
! '-mno-relocatable'
       Generate code that allows (does not allow) a static executable to
       be relocated to a different address at run time.  A simple embedded
       PowerPC system loader should relocate the entire contents of
!      '.got2' and 4-byte locations listed in the '.fixup' section, a
       table of 32-bit addresses generated by this option.  For this to
       work, all objects linked together must be compiled with
!      '-mrelocatable' or '-mrelocatable-lib'.  '-mrelocatable' code
       aligns the stack to an 8-byte boundary.
  
! '-mrelocatable-lib'
! '-mno-relocatable-lib'
!      Like '-mrelocatable', '-mrelocatable-lib' generates a '.fixup'
       section to allow static executables to be relocated at run time,
!      but '-mrelocatable-lib' does not use the smaller stack alignment of
!      '-mrelocatable'.  Objects compiled with '-mrelocatable-lib' may be
       linked with objects compiled with any combination of the
!      '-mrelocatable' options.
  
! '-mno-toc'
! '-mtoc'
       On System V.4 and embedded PowerPC systems do not (do) assume that
       register 2 contains a pointer to a global area pointing to the
       addresses used in the program.
  
! '-mlittle'
! '-mlittle-endian'
       On System V.4 and embedded PowerPC systems compile code for the
!      processor in little-endian mode.  The '-mlittle-endian' option is
!      the same as '-mlittle'.
  
! '-mbig'
! '-mbig-endian'
       On System V.4 and embedded PowerPC systems compile code for the
!      processor in big-endian mode.  The '-mbig-endian' option is the
!      same as '-mbig'.
  
! '-mdynamic-no-pic'
       On Darwin and Mac OS X systems, compile code so that it is not
       relocatable, but that its external references are relocatable.  The
       resulting code is suitable for applications, but not shared
       libraries.
  
! '-msingle-pic-base'
       Treat the register used for PIC addressing as read-only, rather
       than loading it in the prologue for each function.  The runtime
       system is responsible for initializing this register with an
       appropriate value before execution begins.
  
! '-mprioritize-restricted-insns=PRIORITY'
       This option controls the priority that is assigned to dispatch-slot
       restricted instructions during the second scheduling pass.  The
!      argument PRIORITY takes the value '0', '1', or '2' to assign no,
       highest, or second-highest (respectively) priority to dispatch-slot
       restricted instructions.
  
! '-msched-costly-dep=DEPENDENCE_TYPE'
       This option controls which dependences are considered costly by the
       target during instruction scheduling.  The argument DEPENDENCE_TYPE
       takes one of the following values:
  
!      'no'
            No dependence is costly.
  
!      'all'
            All dependences are costly.
  
!      'true_store_to_load'
            A true dependence from store to load is costly.
  
!      'store_to_load'
            Any dependence from store to load is costly.
  
       NUMBER
            Any dependence for which the latency is greater than or equal
            to NUMBER is costly.
  
! '-minsert-sched-nops=SCHEME'
       This option controls which NOP insertion scheme is used during the
       second scheduling pass.  The argument SCHEME takes one of the
       following values:
  
!      'no'
            Don't insert NOPs.
  
!      'pad'
            Pad with NOPs any dispatch group that has vacant issue slots,
            according to the scheduler's grouping.
  
!      'regroup_exact'
            Insert NOPs to force costly dependent insns into separate
            groups.  Insert exactly as many NOPs as needed to force an
            insn to a new group, according to the estimated processor
--- 27349,27484 ----
       boundary.  This option is enabled by default when targeting Power6
       and disabled otherwise.
  
! ‘-mfused-madd’
! ‘-mno-fused-madd’
       Generate code that uses (does not use) the floating-point multiply
       and accumulate instructions.  These instructions are generated by
       default if hardware floating point is used.  The machine-dependent
!      ‘-mfused-madd’ option is now mapped to the machine-independent
!      ‘-ffp-contract=fast’ option, and ‘-mno-fused-madd’ is mapped to
!      ‘-ffp-contract=off’.
  
! ‘-mmulhw’
! ‘-mno-mulhw’
       Generate code that uses (does not use) the half-word multiply and
       multiply-accumulate instructions on the IBM 405, 440, 464 and 476
       processors.  These instructions are generated by default when
       targeting those processors.
  
! ‘-mdlmzb’
! ‘-mno-dlmzb’
!      Generate code that uses (does not use) the string-search ‘dlmzb’
       instruction on the IBM 405, 440, 464 and 476 processors.  This
       instruction is generated by default when targeting those
       processors.
  
! ‘-mno-bit-align’
! ‘-mbit-align’
       On System V.4 and embedded PowerPC systems do not (do) force
       structures and unions that contain bit-fields to be aligned to the
       base type of the bit-field.
  
       For example, by default a structure containing nothing but 8
!      ‘unsigned’ bit-fields of length 1 is aligned to a 4-byte boundary
!      and has a size of 4 bytes.  By using ‘-mno-bit-align’, the
       structure is aligned to a 1-byte boundary and is 1 byte in size.
  
! ‘-mno-strict-align’
! ‘-mstrict-align’
       On System V.4 and embedded PowerPC systems do not (do) assume that
       unaligned memory references are handled by the system.
  
! ‘-mrelocatable’
! ‘-mno-relocatable’
       Generate code that allows (does not allow) a static executable to
       be relocated to a different address at run time.  A simple embedded
       PowerPC system loader should relocate the entire contents of
!      ‘.got2’ and 4-byte locations listed in the ‘.fixup’ section, a
       table of 32-bit addresses generated by this option.  For this to
       work, all objects linked together must be compiled with
!      ‘-mrelocatable’ or ‘-mrelocatable-lib’.  ‘-mrelocatable’ code
       aligns the stack to an 8-byte boundary.
  
! ‘-mrelocatable-lib’
! ‘-mno-relocatable-lib’
!      Like ‘-mrelocatable’, ‘-mrelocatable-lib’ generates a ‘.fixup’
       section to allow static executables to be relocated at run time,
!      but ‘-mrelocatable-lib’ does not use the smaller stack alignment of
!      ‘-mrelocatable’.  Objects compiled with ‘-mrelocatable-lib’ may be
       linked with objects compiled with any combination of the
!      ‘-mrelocatable’ options.
  
! ‘-mno-toc’
! ‘-mtoc’
       On System V.4 and embedded PowerPC systems do not (do) assume that
       register 2 contains a pointer to a global area pointing to the
       addresses used in the program.
  
! ‘-mlittle’
! ‘-mlittle-endian’
       On System V.4 and embedded PowerPC systems compile code for the
!      processor in little-endian mode.  The ‘-mlittle-endian’ option is
!      the same as ‘-mlittle’.
  
! ‘-mbig’
! ‘-mbig-endian’
       On System V.4 and embedded PowerPC systems compile code for the
!      processor in big-endian mode.  The ‘-mbig-endian’ option is the
!      same as ‘-mbig’.
  
! ‘-mdynamic-no-pic’
       On Darwin and Mac OS X systems, compile code so that it is not
       relocatable, but that its external references are relocatable.  The
       resulting code is suitable for applications, but not shared
       libraries.
  
! ‘-msingle-pic-base’
       Treat the register used for PIC addressing as read-only, rather
       than loading it in the prologue for each function.  The runtime
       system is responsible for initializing this register with an
       appropriate value before execution begins.
  
! ‘-mprioritize-restricted-insns=PRIORITY’
       This option controls the priority that is assigned to dispatch-slot
       restricted instructions during the second scheduling pass.  The
!      argument PRIORITY takes the value ‘0’, ‘1’, or ‘2’ to assign no,
       highest, or second-highest (respectively) priority to dispatch-slot
       restricted instructions.
  
! ‘-msched-costly-dep=DEPENDENCE_TYPE’
       This option controls which dependences are considered costly by the
       target during instruction scheduling.  The argument DEPENDENCE_TYPE
       takes one of the following values:
  
!      ‘no’
            No dependence is costly.
  
!      ‘all’
            All dependences are costly.
  
!      ‘true_store_to_load’
            A true dependence from store to load is costly.
  
!      ‘store_to_load’
            Any dependence from store to load is costly.
  
       NUMBER
            Any dependence for which the latency is greater than or equal
            to NUMBER is costly.
  
! ‘-minsert-sched-nops=SCHEME’
       This option controls which NOP insertion scheme is used during the
       second scheduling pass.  The argument SCHEME takes one of the
       following values:
  
!      ‘no’
            Don't insert NOPs.
  
!      ‘pad’
            Pad with NOPs any dispatch group that has vacant issue slots,
            according to the scheduler's grouping.
  
!      ‘regroup_exact’
            Insert NOPs to force costly dependent insns into separate
            groups.  Insert exactly as many NOPs as needed to force an
            insn to a new group, according to the estimated processor
*************** These '-m' options are defined for the I
*** 27478,27711 ****
            Insert NOPs to force costly dependent insns into separate
            groups.  Insert NUMBER NOPs to force an insn to a new group.
  
! '-mcall-sysv'
       On System V.4 and embedded PowerPC systems compile code using
       calling conventions that adhere to the March 1995 draft of the
       System V Application Binary Interface, PowerPC processor
       supplement.  This is the default unless you configured GCC using
!      'powerpc-*-eabiaix'.
  
! '-mcall-sysv-eabi'
! '-mcall-eabi'
!      Specify both '-mcall-sysv' and '-meabi' options.
  
! '-mcall-sysv-noeabi'
!      Specify both '-mcall-sysv' and '-mno-eabi' options.
  
! '-mcall-aixdesc'
       On System V.4 and embedded PowerPC systems compile code for the AIX
       operating system.
  
! '-mcall-linux'
       On System V.4 and embedded PowerPC systems compile code for the
       Linux-based GNU system.
  
! '-mcall-freebsd'
       On System V.4 and embedded PowerPC systems compile code for the
       FreeBSD operating system.
  
! '-mcall-netbsd'
       On System V.4 and embedded PowerPC systems compile code for the
       NetBSD operating system.
  
! '-mcall-openbsd'
       On System V.4 and embedded PowerPC systems compile code for the
       OpenBSD operating system.
  
! '-mtraceback=TRACEBACK_TYPE'
       Select the type of traceback table.  Valid values for
!      TRACEBACK_TYPE are 'full', 'part', and 'no'.
  
! '-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',
!      'ibmlongdouble', 'ieeelongdouble', 'elfv1', 'elfv2', and for AIX:
!      'vec-extabi', 'vec-default'.
  
! '-mabi=ibmlongdouble'
       Change the current ABI to use IBM extended-precision long double.
       This is not likely to work if your system defaults to using IEEE
       extended-precision long double.  If you change the long double type
       from IEEE extended-precision, the compiler will issue a warning
!      unless you use the '-Wno-psabi' option.  Requires
!      '-mlong-double-128' to be enabled.
  
! '-mabi=ieeelongdouble'
       Change the current ABI to use IEEE extended-precision long double.
       This is not likely to work if your system defaults to using IBM
       extended-precision long double.  If you change the long double type
       from IBM extended-precision, the compiler will issue a warning
!      unless you use the '-Wno-psabi' option.  Requires
!      '-mlong-double-128' to be enabled.
  
! '-mabi=elfv1'
       Change the current ABI to use the ELFv1 ABI. This is the default
       ABI for big-endian PowerPC 64-bit Linux.  Overriding the default
       ABI requires special system support and is likely to fail in
       spectacular ways.
  
! '-mabi=elfv2'
       Change the current ABI to use the ELFv2 ABI. This is the default
       ABI for little-endian PowerPC 64-bit Linux.  Overriding the default
       ABI requires special system support and is likely to fail in
       spectacular ways.
  
! '-mgnu-attribute'
! '-mno-gnu-attribute'
       Emit .gnu_attribute assembly directives to set tag/value pairs in a
       .gnu.attributes section that specify ABI variations in function
       parameters or return values.
  
! '-mprototype'
! '-mno-prototype'
       On System V.4 and embedded PowerPC systems assume that all calls to
       variable argument functions are properly prototyped.  Otherwise,
       the compiler must insert an instruction before every non-prototyped
!      call to set or clear bit 6 of the condition code register ('CR') to
       indicate whether floating-point values are passed in the
       floating-point registers in case the function takes variable
!      arguments.  With '-mprototype', only calls to prototyped variable
       argument functions set or clear the bit.
  
! '-msim'
       On embedded PowerPC systems, assume that the startup module is
!      called 'sim-crt0.o' and that the standard C libraries are
!      'libsim.a' and 'libc.a'.  This is the default for
!      'powerpc-*-eabisim' configurations.
  
! '-mmvme'
       On embedded PowerPC systems, assume that the startup module is
!      called 'crt0.o' and the standard C libraries are 'libmvme.a' and
!      'libc.a'.
  
! '-mads'
       On embedded PowerPC systems, assume that the startup module is
!      called 'crt0.o' and the standard C libraries are 'libads.a' and
!      'libc.a'.
  
! '-myellowknife'
       On embedded PowerPC systems, assume that the startup module is
!      called 'crt0.o' and the standard C libraries are 'libyk.a' and
!      'libc.a'.
  
! '-mvxworks'
       On System V.4 and embedded PowerPC systems, specify that you are
       compiling for a VxWorks system.
  
! '-memb'
!      On embedded PowerPC systems, set the 'PPC_EMB' bit in the ELF flags
!      header to indicate that 'eabi' extended relocations are used.
  
! '-meabi'
! '-mno-eabi'
       On System V.4 and embedded PowerPC systems do (do not) adhere to
       the Embedded Applications Binary Interface (EABI), which is a set
       of modifications to the System V.4 specifications.  Selecting
!      '-meabi' means that the stack is aligned to an 8-byte boundary, a
!      function '__eabi' is called from 'main' to set up the EABI
!      environment, and the '-msdata' option can use both 'r2' and 'r13'
!      to point to two separate small data areas.  Selecting '-mno-eabi'
       means that the stack is aligned to a 16-byte boundary, no EABI
!      initialization function is called from 'main', and the '-msdata'
!      option only uses 'r13' to point to a single small data area.  The
!      '-meabi' option is on by default if you configured GCC using one of
!      the 'powerpc*-*-eabi*' options.
  
! '-msdata=eabi'
       On System V.4 and embedded PowerPC systems, put small initialized
!      'const' global and static data in the '.sdata2' section, which is
!      pointed to by register 'r2'.  Put small initialized non-'const'
!      global and static data in the '.sdata' section, which is pointed to
!      by register 'r13'.  Put small uninitialized global and static data
!      in the '.sbss' section, which is adjacent to the '.sdata' section.
!      The '-msdata=eabi' option is incompatible with the '-mrelocatable'
!      option.  The '-msdata=eabi' option also sets the '-memb' option.
  
! '-msdata=sysv'
       On System V.4 and embedded PowerPC systems, put small global and
!      static data in the '.sdata' section, which is pointed to by
!      register 'r13'.  Put small uninitialized global and static data in
!      the '.sbss' section, which is adjacent to the '.sdata' section.
!      The '-msdata=sysv' option is incompatible with the '-mrelocatable'
       option.
  
! '-msdata=default'
! '-msdata'
!      On System V.4 and embedded PowerPC systems, if '-meabi' is used,
!      compile code the same as '-msdata=eabi', otherwise compile code the
!      same as '-msdata=sysv'.
  
! '-msdata=data'
       On System V.4 and embedded PowerPC systems, put small global data
!      in the '.sdata' section.  Put small uninitialized global data in
!      the '.sbss' section.  Do not use register 'r13' to address small
!      data however.  This is the default behavior unless other '-msdata'
       options are used.
  
! '-msdata=none'
! '-mno-sdata'
       On embedded PowerPC systems, put all initialized global and static
!      data in the '.data' section, and all uninitialized data in the
!      '.bss' section.
  
! '-mreadonly-in-sdata'
!      Put read-only objects in the '.sdata' section as well.  This is the
       default.
  
! '-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.
  
! '-mblock-compare-inline-limit=NUM'
       Generate non-looping inline code for all block compares (such as
!      calls to 'memcmp' or structure compares) less than or equal to NUM
       bytes.  If NUM is 0, all inline expansion (non-loop and loop) of
       block compare is disabled.  The default value is target-specific.
  
! '-mblock-compare-inline-loop-limit=NUM'
       Generate an inline expansion using loop code for all block compares
       that are less than or equal to NUM bytes, but greater than the
       limit for non-loop inline block compare expansion.  If the block
       length is not constant, at most NUM bytes will be compared before
!      'memcmp' is called to compare the remainder of the block.  The
       default value is target-specific.
  
! '-mstring-compare-inline-limit=NUM'
       Compare at most NUM string bytes with inline code.  If the
       difference or end of string is not found at the end of the inline
!      compare a call to 'strcmp' or 'strncmp' will take care of the rest
       of the comparison.  The default is 64 bytes.
  
! '-G NUM'
       On embedded PowerPC systems, put global and static items less than
       or equal to NUM bytes into the small data or BSS sections instead
!      of the normal data or BSS section.  By default, NUM is 8.  The '-G
!      NUM' switch is also passed to the linker.  All modules should be
!      compiled with the same '-G NUM' value.
  
! '-mregnames'
! '-mno-regnames'
       On System V.4 and embedded PowerPC systems do (do not) emit
       register names in the assembly language output using symbolic
       forms.
  
! '-mlongcall'
! '-mno-longcall'
       By default assume that all calls are far away so that a longer and
       more expensive calling sequence is required.  This is required for
       calls farther than 32 megabytes (33,554,432 bytes) from the current
       location.  A short call is generated if the compiler knows the call
       cannot be that far away.  This setting can be overridden by the
!      'shortcall' function attribute, or by '#pragma longcall(0)'.
  
       Some linkers are capable of detecting out-of-range calls and
       generating glue code on the fly.  On these systems, long calls are
--- 27488,27721 ----
            Insert NOPs to force costly dependent insns into separate
            groups.  Insert NUMBER NOPs to force an insn to a new group.
  
! ‘-mcall-sysv’
       On System V.4 and embedded PowerPC systems compile code using
       calling conventions that adhere to the March 1995 draft of the
       System V Application Binary Interface, PowerPC processor
       supplement.  This is the default unless you configured GCC using
!      ‘powerpc-*-eabiaix’.
  
! ‘-mcall-sysv-eabi’
! ‘-mcall-eabi’
!      Specify both ‘-mcall-sysv’ and ‘-meabi’ options.
  
! ‘-mcall-sysv-noeabi’
!      Specify both ‘-mcall-sysv’ and ‘-mno-eabi’ options.
  
! ‘-mcall-aixdesc’
       On System V.4 and embedded PowerPC systems compile code for the AIX
       operating system.
  
! ‘-mcall-linux’
       On System V.4 and embedded PowerPC systems compile code for the
       Linux-based GNU system.
  
! ‘-mcall-freebsd’
       On System V.4 and embedded PowerPC systems compile code for the
       FreeBSD operating system.
  
! ‘-mcall-netbsd’
       On System V.4 and embedded PowerPC systems compile code for the
       NetBSD operating system.
  
! ‘-mcall-openbsd’
       On System V.4 and embedded PowerPC systems compile code for the
       OpenBSD operating system.
  
! ‘-mtraceback=TRACEBACK_TYPE’
       Select the type of traceback table.  Valid values for
!      TRACEBACK_TYPE are ‘full’, ‘part’, and ‘no’.
  
! ‘-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’,
!      ‘ibmlongdouble’, ‘ieeelongdouble’, ‘elfv1’, ‘elfv2’, and for AIX:
!      ‘vec-extabi’, ‘vec-default’.
  
! ‘-mabi=ibmlongdouble’
       Change the current ABI to use IBM extended-precision long double.
       This is not likely to work if your system defaults to using IEEE
       extended-precision long double.  If you change the long double type
       from IEEE extended-precision, the compiler will issue a warning
!      unless you use the ‘-Wno-psabi’ option.  Requires
!      ‘-mlong-double-128’ to be enabled.
  
! ‘-mabi=ieeelongdouble’
       Change the current ABI to use IEEE extended-precision long double.
       This is not likely to work if your system defaults to using IBM
       extended-precision long double.  If you change the long double type
       from IBM extended-precision, the compiler will issue a warning
!      unless you use the ‘-Wno-psabi’ option.  Requires
!      ‘-mlong-double-128’ to be enabled.
  
! ‘-mabi=elfv1’
       Change the current ABI to use the ELFv1 ABI. This is the default
       ABI for big-endian PowerPC 64-bit Linux.  Overriding the default
       ABI requires special system support and is likely to fail in
       spectacular ways.
  
! ‘-mabi=elfv2’
       Change the current ABI to use the ELFv2 ABI. This is the default
       ABI for little-endian PowerPC 64-bit Linux.  Overriding the default
       ABI requires special system support and is likely to fail in
       spectacular ways.
  
! ‘-mgnu-attribute’
! ‘-mno-gnu-attribute’
       Emit .gnu_attribute assembly directives to set tag/value pairs in a
       .gnu.attributes section that specify ABI variations in function
       parameters or return values.
  
! ‘-mprototype’
! ‘-mno-prototype’
       On System V.4 and embedded PowerPC systems assume that all calls to
       variable argument functions are properly prototyped.  Otherwise,
       the compiler must insert an instruction before every non-prototyped
!      call to set or clear bit 6 of the condition code register (‘CR’) to
       indicate whether floating-point values are passed in the
       floating-point registers in case the function takes variable
!      arguments.  With ‘-mprototype’, only calls to prototyped variable
       argument functions set or clear the bit.
  
! ‘-msim’
       On embedded PowerPC systems, assume that the startup module is
!      called ‘sim-crt0.o’ and that the standard C libraries are
!      ‘libsim.a’ and ‘libc.a’.  This is the default for
!      ‘powerpc-*-eabisim’ configurations.
  
! ‘-mmvme’
       On embedded PowerPC systems, assume that the startup module is
!      called ‘crt0.o’ and the standard C libraries are ‘libmvme.a’ and
!      ‘libc.a’.
  
! ‘-mads’
       On embedded PowerPC systems, assume that the startup module is
!      called ‘crt0.o’ and the standard C libraries are ‘libads.a’ and
!      ‘libc.a’.
  
! ‘-myellowknife’
       On embedded PowerPC systems, assume that the startup module is
!      called ‘crt0.o’ and the standard C libraries are ‘libyk.a’ and
!      ‘libc.a’.
  
! ‘-mvxworks’
       On System V.4 and embedded PowerPC systems, specify that you are
       compiling for a VxWorks system.
  
! ‘-memb’
!      On embedded PowerPC systems, set the ‘PPC_EMB’ bit in the ELF flags
!      header to indicate that ‘eabi’ extended relocations are used.
  
! ‘-meabi’
! ‘-mno-eabi’
       On System V.4 and embedded PowerPC systems do (do not) adhere to
       the Embedded Applications Binary Interface (EABI), which is a set
       of modifications to the System V.4 specifications.  Selecting
!      ‘-meabi’ means that the stack is aligned to an 8-byte boundary, a
!      function ‘__eabi’ is called from ‘main’ to set up the EABI
!      environment, and the ‘-msdata’ option can use both ‘r2’ and ‘r13’
!      to point to two separate small data areas.  Selecting ‘-mno-eabi’
       means that the stack is aligned to a 16-byte boundary, no EABI
!      initialization function is called from ‘main’, and the ‘-msdata’
!      option only uses ‘r13’ to point to a single small data area.  The
!      ‘-meabi’ option is on by default if you configured GCC using one of
!      the ‘powerpc*-*-eabi*’ options.
  
! ‘-msdata=eabi’
       On System V.4 and embedded PowerPC systems, put small initialized
!      ‘const’ global and static data in the ‘.sdata2’ section, which is
!      pointed to by register ‘r2’.  Put small initialized non-‘const’
!      global and static data in the ‘.sdata’ section, which is pointed to
!      by register ‘r13’.  Put small uninitialized global and static data
!      in the ‘.sbss’ section, which is adjacent to the ‘.sdata’ section.
!      The ‘-msdata=eabi’ option is incompatible with the ‘-mrelocatable’
!      option.  The ‘-msdata=eabi’ option also sets the ‘-memb’ option.
  
! ‘-msdata=sysv’
       On System V.4 and embedded PowerPC systems, put small global and
!      static data in the ‘.sdata’ section, which is pointed to by
!      register ‘r13’.  Put small uninitialized global and static data in
!      the ‘.sbss’ section, which is adjacent to the ‘.sdata’ section.
!      The ‘-msdata=sysv’ option is incompatible with the ‘-mrelocatable’
       option.
  
! ‘-msdata=default’
! ‘-msdata’
!      On System V.4 and embedded PowerPC systems, if ‘-meabi’ is used,
!      compile code the same as ‘-msdata=eabi’, otherwise compile code the
!      same as ‘-msdata=sysv’.
  
! ‘-msdata=data’
       On System V.4 and embedded PowerPC systems, put small global data
!      in the ‘.sdata’ section.  Put small uninitialized global data in
!      the ‘.sbss’ section.  Do not use register ‘r13’ to address small
!      data however.  This is the default behavior unless other ‘-msdata’
       options are used.
  
! ‘-msdata=none’
! ‘-mno-sdata’
       On embedded PowerPC systems, put all initialized global and static
!      data in the ‘.data’ section, and all uninitialized data in the
!      ‘.bss’ section.
  
! ‘-mreadonly-in-sdata’
!      Put read-only objects in the ‘.sdata’ section as well.  This is the
       default.
  
! ‘-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.
  
! ‘-mblock-compare-inline-limit=NUM’
       Generate non-looping inline code for all block compares (such as
!      calls to ‘memcmp’ or structure compares) less than or equal to NUM
       bytes.  If NUM is 0, all inline expansion (non-loop and loop) of
       block compare is disabled.  The default value is target-specific.
  
! ‘-mblock-compare-inline-loop-limit=NUM’
       Generate an inline expansion using loop code for all block compares
       that are less than or equal to NUM bytes, but greater than the
       limit for non-loop inline block compare expansion.  If the block
       length is not constant, at most NUM bytes will be compared before
!      ‘memcmp’ is called to compare the remainder of the block.  The
       default value is target-specific.
  
! ‘-mstring-compare-inline-limit=NUM’
       Compare at most NUM string bytes with inline code.  If the
       difference or end of string is not found at the end of the inline
!      compare a call to ‘strcmp’ or ‘strncmp’ will take care of the rest
       of the comparison.  The default is 64 bytes.
  
! ‘-G NUM’
       On embedded PowerPC systems, put global and static items less than
       or equal to NUM bytes into the small data or BSS sections instead
!      of the normal data or BSS section.  By default, NUM is 8.  The ‘-G
!      NUM’ switch is also passed to the linker.  All modules should be
!      compiled with the same ‘-G NUM’ value.
  
! ‘-mregnames’
! ‘-mno-regnames’
       On System V.4 and embedded PowerPC systems do (do not) emit
       register names in the assembly language output using symbolic
       forms.
  
! ‘-mlongcall’
! ‘-mno-longcall’
       By default assume that all calls are far away so that a longer and
       more expensive calling sequence is required.  This is required for
       calls farther than 32 megabytes (33,554,432 bytes) from the current
       location.  A short call is generated if the compiler knows the call
       cannot be that far away.  This setting can be overridden by the
!      ‘shortcall’ function attribute, or by ‘#pragma longcall(0)’.
  
       Some linkers are capable of detecting out-of-range calls and
       generating glue code on the fly.  On these systems, long calls are
*************** These '-m' options are defined for the I
*** 27716,27730 ****
  
       On PowerPC64 ELFv2 and 32-bit PowerPC systems with newer GNU
       linkers, GCC can generate long calls using an inline PLT call
!      sequence (see '-mpltseq').  PowerPC with '-mbss-plt' and PowerPC64
       ELFv1 (big-endian) do not support inline PLT calls.
  
!      On Darwin/PPC systems, '#pragma longcall' generates 'jbsr callee,
!      L42', plus a "branch island" (glue code).  The two target addresses
       represent the callee and the branch island.  The Darwin/PPC linker
!      prefers the first address and generates a 'bl callee' if the PPC
!      'bl' instruction reaches the callee directly; otherwise, the linker
!      generates 'bl L42' to call the branch island.  The branch island is
       appended to the body of the calling function; it computes the full
       32-bit address of the callee and jumps to it.
  
--- 27726,27740 ----
  
       On PowerPC64 ELFv2 and 32-bit PowerPC systems with newer GNU
       linkers, GCC can generate long calls using an inline PLT call
!      sequence (see ‘-mpltseq’).  PowerPC with ‘-mbss-plt’ and PowerPC64
       ELFv1 (big-endian) do not support inline PLT calls.
  
!      On Darwin/PPC systems, ‘#pragma longcall’ generates ‘jbsr callee,
!      L42’, plus a “branch island” (glue code).  The two target addresses
       represent the callee and the branch island.  The Darwin/PPC linker
!      prefers the first address and generates a ‘bl callee’ if the PPC
!      ‘bl’ instruction reaches the callee directly; otherwise, the linker
!      generates ‘bl L42’ to call the branch island.  The branch island is
       appended to the body of the calling function; it computes the full
       32-bit address of the callee and jumps to it.
  
*************** These '-m' options are defined for the I
*** 27735,27876 ****
       In the future, GCC may ignore all longcall specifications when the
       linker is known to generate glue.
  
! '-mpltseq'
! '-mno-pltseq'
       Implement (do not implement) -fno-plt and long calls using an
       inline PLT call sequence that supports lazy linking and long calls
       to functions in dlopen'd shared libraries.  Inline PLT calls are
       only supported on PowerPC64 ELFv2 and 32-bit PowerPC systems with
       newer GNU linkers, and are enabled by default if the support is
       detected when configuring GCC, and, in the case of 32-bit PowerPC,
!      if GCC is configured with '--enable-secureplt'.  '-mpltseq' code
!      and '-mbss-plt' 32-bit PowerPC relocatable objects may not be
       linked together.
  
! '-mtls-markers'
! '-mno-tls-markers'
!      Mark (do not mark) calls to '__tls_get_addr' with a relocation
       specifying the function argument.  The relocation allows the linker
       to reliably associate function call with argument setup
       instructions for TLS optimization, which in turn allows GCC to
       better schedule the sequence.
  
! '-mrecip'
! '-mno-recip'
       This option enables use of the reciprocal estimate and reciprocal
       square root estimate instructions with additional Newton-Raphson
       steps to increase precision instead of doing a divide or square
       root and divide for floating-point arguments.  You should use the
!      '-ffast-math' option when using '-mrecip' (or at least
!      '-funsafe-math-optimizations', '-ffinite-math-only',
!      '-freciprocal-math' and '-fno-trapping-math').  Note that while the
       throughput of the sequence is generally higher than the throughput
       of the non-reciprocal instruction, the precision of the sequence
       can be decreased by up to 2 ulp (i.e. the inverse of 1.0 equals
       0.99999994) for reciprocal square roots.
  
! '-mrecip=OPT'
       This option controls which reciprocal estimate instructions may be
       used.  OPT is a comma-separated list of options, which may be
!      preceded by a '!' to invert the option:
  
!      'all'
            Enable all estimate instructions.
  
!      'default'
!           Enable the default instructions, equivalent to '-mrecip'.
  
!      'none'
!           Disable all estimate instructions, equivalent to '-mno-recip'.
  
!      'div'
            Enable the reciprocal approximation instructions for both
            single and double precision.
  
!      'divf'
            Enable the single-precision reciprocal approximation
            instructions.
  
!      'divd'
            Enable the double-precision reciprocal approximation
            instructions.
  
!      'rsqrt'
            Enable the reciprocal square root approximation instructions
            for both single and double precision.
  
!      'rsqrtf'
            Enable the single-precision reciprocal square root
            approximation instructions.
  
!      'rsqrtd'
            Enable the double-precision reciprocal square root
            approximation instructions.
  
!      So, for example, '-mrecip=all,!rsqrtd' enables all of the
!      reciprocal estimate instructions, except for the 'FRSQRTE',
!      'XSRSQRTEDP', and 'XVRSQRTEDP' instructions which handle the
       double-precision reciprocal square root calculations.
  
! '-mrecip-precision'
! '-mno-recip-precision'
       Assume (do not assume) that the reciprocal estimate instructions
       provide higher-precision estimates than is mandated by the PowerPC
!      ABI. Selecting '-mcpu=power6', '-mcpu=power7' or '-mcpu=power8'
!      automatically selects '-mrecip-precision'.  The double-precision
       square root estimate instructions are not generated by default on
       low-precision machines, since they do not provide an estimate that
       converges after three steps.
  
! '-mveclibabi=TYPE'
       Specifies the ABI type to use for vectorizing intrinsics using an
!      external library.  The only type supported at present is 'mass',
       which specifies to use IBM's Mathematical Acceleration Subsystem
       (MASS) libraries for vectorizing intrinsics using external
!      libraries.  GCC currently emits calls to 'acosd2', 'acosf4',
!      'acoshd2', 'acoshf4', 'asind2', 'asinf4', 'asinhd2', 'asinhf4',
!      'atan2d2', 'atan2f4', 'atand2', 'atanf4', 'atanhd2', 'atanhf4',
!      'cbrtd2', 'cbrtf4', 'cosd2', 'cosf4', 'coshd2', 'coshf4', 'erfcd2',
!      'erfcf4', 'erfd2', 'erff4', 'exp2d2', 'exp2f4', 'expd2', 'expf4',
!      'expm1d2', 'expm1f4', 'hypotd2', 'hypotf4', 'lgammad2', 'lgammaf4',
!      'log10d2', 'log10f4', 'log1pd2', 'log1pf4', 'log2d2', 'log2f4',
!      'logd2', 'logf4', 'powd2', 'powf4', 'sind2', 'sinf4', 'sinhd2',
!      'sinhf4', 'sqrtd2', 'sqrtf4', 'tand2', 'tanf4', 'tanhd2', and
!      'tanhf4' when generating code for power7.  Both '-ftree-vectorize'
!      and '-funsafe-math-optimizations' must also be enabled.  The MASS
       libraries must be specified at link time.
  
! '-mfriz'
! '-mno-friz'
!      Generate (do not generate) the 'friz' instruction when the
!      '-funsafe-math-optimizations' option is used to optimize rounding
       of floating-point values to 64-bit integer and back to floating
!      point.  The 'friz' instruction does not return the same value if
       the floating-point number is too large to fit in an integer.
  
! '-mpointers-to-nested-functions'
! '-mno-pointers-to-nested-functions'
       Generate (do not generate) code to load up the static chain
!      register ('r11') when calling through a pointer on AIX and 64-bit
       Linux systems where a function pointer points to a 3-word
       descriptor giving the function address, TOC value to be loaded in
!      register 'r2', and static chain value to be loaded in register
!      'r11'.  The '-mpointers-to-nested-functions' is on by default.  You
       cannot call through pointers to nested functions or pointers to
       functions compiled in other languages that use the static chain if
!      you use '-mno-pointers-to-nested-functions'.
  
! '-msave-toc-indirect'
! '-mno-save-toc-indirect'
       Generate (do not generate) code to save the TOC value in the
       reserved stack location in the function prologue if the function
       calls through a pointer on AIX and 64-bit Linux systems.  If the
       TOC value is not saved in the prologue, it is saved just before the
!      call through the pointer.  The '-mno-save-toc-indirect' option is
       the default.
  
! '-mcompat-align-parm'
! '-mno-compat-align-parm'
       Generate (do not generate) code to pass structure parameters with a
       maximum alignment of 64 bits, for compatibility with older versions
       of GCC.
--- 27745,27886 ----
       In the future, GCC may ignore all longcall specifications when the
       linker is known to generate glue.
  
! ‘-mpltseq’
! ‘-mno-pltseq’
       Implement (do not implement) -fno-plt and long calls using an
       inline PLT call sequence that supports lazy linking and long calls
       to functions in dlopen'd shared libraries.  Inline PLT calls are
       only supported on PowerPC64 ELFv2 and 32-bit PowerPC systems with
       newer GNU linkers, and are enabled by default if the support is
       detected when configuring GCC, and, in the case of 32-bit PowerPC,
!      if GCC is configured with ‘--enable-secureplt’.  ‘-mpltseq’ code
!      and ‘-mbss-plt’ 32-bit PowerPC relocatable objects may not be
       linked together.
  
! ‘-mtls-markers’
! ‘-mno-tls-markers’
!      Mark (do not mark) calls to ‘__tls_get_addr’ with a relocation
       specifying the function argument.  The relocation allows the linker
       to reliably associate function call with argument setup
       instructions for TLS optimization, which in turn allows GCC to
       better schedule the sequence.
  
! ‘-mrecip’
! ‘-mno-recip’
       This option enables use of the reciprocal estimate and reciprocal
       square root estimate instructions with additional Newton-Raphson
       steps to increase precision instead of doing a divide or square
       root and divide for floating-point arguments.  You should use the
!      ‘-ffast-math’ option when using ‘-mrecip’ (or at least
!      ‘-funsafe-math-optimizations’, ‘-ffinite-math-only’,
!      ‘-freciprocal-math’ and ‘-fno-trapping-math’).  Note that while the
       throughput of the sequence is generally higher than the throughput
       of the non-reciprocal instruction, the precision of the sequence
       can be decreased by up to 2 ulp (i.e. the inverse of 1.0 equals
       0.99999994) for reciprocal square roots.
  
! ‘-mrecip=OPT’
       This option controls which reciprocal estimate instructions may be
       used.  OPT is a comma-separated list of options, which may be
!      preceded by a ‘!’ to invert the option:
  
!      ‘all’
            Enable all estimate instructions.
  
!      ‘default’
!           Enable the default instructions, equivalent to ‘-mrecip’.
  
!      ‘none’
!           Disable all estimate instructions, equivalent to ‘-mno-recip’.
  
!      ‘div’
            Enable the reciprocal approximation instructions for both
            single and double precision.
  
!      ‘divf’
            Enable the single-precision reciprocal approximation
            instructions.
  
!      ‘divd’
            Enable the double-precision reciprocal approximation
            instructions.
  
!      ‘rsqrt’
            Enable the reciprocal square root approximation instructions
            for both single and double precision.
  
!      ‘rsqrtf’
            Enable the single-precision reciprocal square root
            approximation instructions.
  
!      ‘rsqrtd’
            Enable the double-precision reciprocal square root
            approximation instructions.
  
!      So, for example, ‘-mrecip=all,!rsqrtd’ enables all of the
!      reciprocal estimate instructions, except for the ‘FRSQRTE’,
!      ‘XSRSQRTEDP’, and ‘XVRSQRTEDP’ instructions which handle the
       double-precision reciprocal square root calculations.
  
! ‘-mrecip-precision’
! ‘-mno-recip-precision’
       Assume (do not assume) that the reciprocal estimate instructions
       provide higher-precision estimates than is mandated by the PowerPC
!      ABI. Selecting ‘-mcpu=power6’, ‘-mcpu=power7’ or ‘-mcpu=power8’
!      automatically selects ‘-mrecip-precision’.  The double-precision
       square root estimate instructions are not generated by default on
       low-precision machines, since they do not provide an estimate that
       converges after three steps.
  
! ‘-mveclibabi=TYPE’
       Specifies the ABI type to use for vectorizing intrinsics using an
!      external library.  The only type supported at present is ‘mass’,
       which specifies to use IBM's Mathematical Acceleration Subsystem
       (MASS) libraries for vectorizing intrinsics using external
!      libraries.  GCC currently emits calls to ‘acosd2’, ‘acosf4’,
!      ‘acoshd2’, ‘acoshf4’, ‘asind2’, ‘asinf4’, ‘asinhd2’, ‘asinhf4’,
!      ‘atan2d2’, ‘atan2f4’, ‘atand2’, ‘atanf4’, ‘atanhd2’, ‘atanhf4’,
!      ‘cbrtd2’, ‘cbrtf4’, ‘cosd2’, ‘cosf4’, ‘coshd2’, ‘coshf4’, ‘erfcd2’,
!      ‘erfcf4’, ‘erfd2’, ‘erff4’, ‘exp2d2’, ‘exp2f4’, ‘expd2’, ‘expf4’,
!      ‘expm1d2’, ‘expm1f4’, ‘hypotd2’, ‘hypotf4’, ‘lgammad2’, ‘lgammaf4’,
!      ‘log10d2’, ‘log10f4’, ‘log1pd2’, ‘log1pf4’, ‘log2d2’, ‘log2f4’,
!      ‘logd2’, ‘logf4’, ‘powd2’, ‘powf4’, ‘sind2’, ‘sinf4’, ‘sinhd2’,
!      ‘sinhf4’, ‘sqrtd2’, ‘sqrtf4’, ‘tand2’, ‘tanf4’, ‘tanhd2’, and
!      ‘tanhf4’ when generating code for power7.  Both ‘-ftree-vectorize’
!      and ‘-funsafe-math-optimizations’ must also be enabled.  The MASS
       libraries must be specified at link time.
  
! ‘-mfriz’
! ‘-mno-friz’
!      Generate (do not generate) the ‘friz’ instruction when the
!      ‘-funsafe-math-optimizations’ option is used to optimize rounding
       of floating-point values to 64-bit integer and back to floating
!      point.  The ‘friz’ instruction does not return the same value if
       the floating-point number is too large to fit in an integer.
  
! ‘-mpointers-to-nested-functions’
! ‘-mno-pointers-to-nested-functions’
       Generate (do not generate) code to load up the static chain
!      register (‘r11’) when calling through a pointer on AIX and 64-bit
       Linux systems where a function pointer points to a 3-word
       descriptor giving the function address, TOC value to be loaded in
!      register ‘r2’, and static chain value to be loaded in register
!      ‘r11’.  The ‘-mpointers-to-nested-functions’ is on by default.  You
       cannot call through pointers to nested functions or pointers to
       functions compiled in other languages that use the static chain if
!      you use ‘-mno-pointers-to-nested-functions’.
  
! ‘-msave-toc-indirect’
! ‘-mno-save-toc-indirect’
       Generate (do not generate) code to save the TOC value in the
       reserved stack location in the function prologue if the function
       calls through a pointer on AIX and 64-bit Linux systems.  If the
       TOC value is not saved in the prologue, it is saved just before the
!      call through the pointer.  The ‘-mno-save-toc-indirect’ option is
       the default.
  
! ‘-mcompat-align-parm’
! ‘-mno-compat-align-parm’
       Generate (do not generate) code to pass structure parameters with a
       maximum alignment of 64 bits, for compatibility with older versions
       of GCC.
*************** These '-m' options are defined for the I
*** 27882,27940 ****
       code that is compatible with functions compiled with older versions
       of GCC.
  
!      The '-mno-compat-align-parm' option is the default.
  
! '-mstack-protector-guard=GUARD'
! '-mstack-protector-guard-reg=REG'
! '-mstack-protector-guard-offset=OFFSET'
! '-mstack-protector-guard-symbol=SYMBOL'
       Generate stack protection code using canary at GUARD.  Supported
!      locations are 'global' for global canary or 'tls' for per-thread
       canary in the TLS block (the default with GNU libc version 2.4 or
       later).
  
       With the latter choice the options
!      '-mstack-protector-guard-reg=REG' and
!      '-mstack-protector-guard-offset=OFFSET' furthermore specify which
       register to use as base register for reading the canary, and from
       what offset from that base register.  The default for those is as
       specified in the relevant ABI.
!      '-mstack-protector-guard-symbol=SYMBOL' overrides the offset with a
       symbol reference to a canary in the TLS block.
  
! '-mpcrel'
! '-mno-pcrel'
!      Generate (do not generate) pc-relative addressing.  The '-mpcrel'
!      option requires that the medium code model ('-mcmodel=medium') and
!      prefixed addressing ('-mprefixed') options are enabled.
  
! '-mprefixed'
! '-mno-prefixed'
       Generate (do not generate) addressing modes using prefixed load and
!      store instructions.  The '-mprefixed' option requires that the
!      option '-mcpu=power10' (or later) is enabled.
  
! '-mmma'
! '-mno-mma'
!      Generate (do not generate) the MMA instructions.  The '-mma' option
!      requires that the option '-mcpu=power10' (or later) is enabled.
  
! '-mrop-protect'
! '-mno-rop-protect'
       Generate (do not generate) ROP protection instructions when the
       target processor supports them.  Currently this option disables the
!      shrink-wrap optimization ('-fshrink-wrap').
  
! '-mprivileged'
! '-mno-privileged'
       Generate (do not generate) code that will run in privileged state.
  
! '-mblock-ops-unaligned-vsx'
! '-mno-block-ops-unaligned-vsx'
       Generate (do not generate) unaligned vsx loads and stores for
!      inline expansion of 'memcpy' and 'memmove'.
  
! '--param rs6000-vect-unroll-limit='
       The vectorizer will check with target information to determine
       whether it would be beneficial to unroll the main vectorized loop
       and by how much.  This parameter sets the upper bound of how much
--- 27892,27950 ----
       code that is compatible with functions compiled with older versions
       of GCC.
  
!      The ‘-mno-compat-align-parm’ option is the default.
  
! ‘-mstack-protector-guard=GUARD’
! ‘-mstack-protector-guard-reg=REG’
! ‘-mstack-protector-guard-offset=OFFSET’
! ‘-mstack-protector-guard-symbol=SYMBOL’
       Generate stack protection code using canary at GUARD.  Supported
!      locations are ‘global’ for global canary or ‘tls’ for per-thread
       canary in the TLS block (the default with GNU libc version 2.4 or
       later).
  
       With the latter choice the options
!      ‘-mstack-protector-guard-reg=REG’ and
!      ‘-mstack-protector-guard-offset=OFFSET’ furthermore specify which
       register to use as base register for reading the canary, and from
       what offset from that base register.  The default for those is as
       specified in the relevant ABI.
!      ‘-mstack-protector-guard-symbol=SYMBOL’ overrides the offset with a
       symbol reference to a canary in the TLS block.
  
! ‘-mpcrel’
! ‘-mno-pcrel’
!      Generate (do not generate) pc-relative addressing.  The ‘-mpcrel’
!      option requires that the medium code model (‘-mcmodel=medium’) and
!      prefixed addressing (‘-mprefixed’) options are enabled.
  
! ‘-mprefixed’
! ‘-mno-prefixed’
       Generate (do not generate) addressing modes using prefixed load and
!      store instructions.  The ‘-mprefixed’ option requires that the
!      option ‘-mcpu=power10’ (or later) is enabled.
  
! ‘-mmma’
! ‘-mno-mma’
!      Generate (do not generate) the MMA instructions.  The ‘-mma’ option
!      requires that the option ‘-mcpu=power10’ (or later) is enabled.
  
! ‘-mrop-protect’
! ‘-mno-rop-protect’
       Generate (do not generate) ROP protection instructions when the
       target processor supports them.  Currently this option disables the
!      shrink-wrap optimization (‘-fshrink-wrap’).
  
! ‘-mprivileged’
! ‘-mno-privileged’
       Generate (do not generate) code that will run in privileged state.
  
! ‘-mblock-ops-unaligned-vsx’
! ‘-mno-block-ops-unaligned-vsx’
       Generate (do not generate) unaligned vsx loads and stores for
!      inline expansion of ‘memcpy’ and ‘memmove’.
  
! ‘--param rs6000-vect-unroll-limit=’
       The vectorizer will check with target information to determine
       whether it would be beneficial to unroll the main vectorized loop
       and by how much.  This parameter sets the upper bound of how much
*************** File: gcc.info,  Node: RX Options,  Next
*** 27949,27999 ****
  
  These command-line options are defined for RX targets:
  
! '-m64bit-doubles'
! '-m32bit-doubles'
!      Make the 'double' data type be 64 bits ('-m64bit-doubles') or 32
!      bits ('-m32bit-doubles') in size.  The default is
!      '-m32bit-doubles'.  _Note_ RX floating-point hardware only works on
!      32-bit values, which is why the default is '-m32bit-doubles'.
  
! '-fpu'
! '-nofpu'
!      Enables ('-fpu') or disables ('-nofpu') the use of RX
       floating-point hardware.  The default is enabled for the RX600
       series and disabled for the RX200 series.
  
       Floating-point instructions are only generated for 32-bit
       floating-point values, however, so the FPU hardware is not used for
!      doubles if the '-m64bit-doubles' option is used.
  
!      _Note_ If the '-fpu' option is enabled then
!      '-funsafe-math-optimizations' is also enabled automatically.  This
       is because the RX FPU instructions are themselves unsafe.
  
! '-mcpu=NAME'
       Selects the type of RX CPU to be targeted.  Currently three types
!      are supported, the generic 'RX600' and 'RX200' series hardware and
!      the specific 'RX610' CPU. The default is 'RX600'.
  
!      The only difference between 'RX600' and 'RX610' is that the 'RX610'
!      does not support the 'MVTIPL' instruction.
  
!      The 'RX200' series does not have a hardware floating-point unit and
!      so '-nofpu' is enabled by default when this type is selected.
  
! '-mbig-endian-data'
! '-mlittle-endian-data'
       Store data (but not code) in the big-endian format.  The default is
!      '-mlittle-endian-data', i.e. to store data in the little-endian
       format.
  
! '-msmall-data-limit=N'
       Specifies the maximum size in bytes of global and static variables
       which can be placed into the small data area.  Using the small data
       area can lead to smaller and faster code, but the size of area is
       limited and it is up to the programmer to ensure that the area does
       not overflow.  Also when the small data area is used one of the
!      RX's registers (usually 'r13') is reserved for use pointing to this
       area, so it is no longer available for use by the compiler.  This
       could result in slower and/or larger code if variables are pushed
       onto the stack instead of being held in this register.
--- 27959,28009 ----
  
  These command-line options are defined for RX targets:
  
! ‘-m64bit-doubles’
! ‘-m32bit-doubles’
!      Make the ‘double’ data type be 64 bits (‘-m64bit-doubles’) or 32
!      bits (‘-m32bit-doubles’) in size.  The default is
!      ‘-m32bit-doubles’.  _Note_ RX floating-point hardware only works on
!      32-bit values, which is why the default is ‘-m32bit-doubles’.
  
! ‘-fpu’
! ‘-nofpu’
!      Enables (‘-fpu’) or disables (‘-nofpu’) the use of RX
       floating-point hardware.  The default is enabled for the RX600
       series and disabled for the RX200 series.
  
       Floating-point instructions are only generated for 32-bit
       floating-point values, however, so the FPU hardware is not used for
!      doubles if the ‘-m64bit-doubles’ option is used.
  
!      _Note_ If the ‘-fpu’ option is enabled then
!      ‘-funsafe-math-optimizations’ is also enabled automatically.  This
       is because the RX FPU instructions are themselves unsafe.
  
! ‘-mcpu=NAME’
       Selects the type of RX CPU to be targeted.  Currently three types
!      are supported, the generic ‘RX600’ and ‘RX200’ series hardware and
!      the specific ‘RX610’ CPU. The default is ‘RX600’.
  
!      The only difference between ‘RX600’ and ‘RX610’ is that the ‘RX610’
!      does not support the ‘MVTIPL’ instruction.
  
!      The ‘RX200’ series does not have a hardware floating-point unit and
!      so ‘-nofpu’ is enabled by default when this type is selected.
  
! ‘-mbig-endian-data’
! ‘-mlittle-endian-data’
       Store data (but not code) in the big-endian format.  The default is
!      ‘-mlittle-endian-data’, i.e. to store data in the little-endian
       format.
  
! ‘-msmall-data-limit=N’
       Specifies the maximum size in bytes of global and static variables
       which can be placed into the small data area.  Using the small data
       area can lead to smaller and faster code, but the size of area is
       limited and it is up to the programmer to ensure that the area does
       not overflow.  Also when the small data area is used one of the
!      RX's registers (usually ‘r13’) is reserved for use pointing to this
       area, so it is no longer available for use by the compiler.  This
       could result in slower and/or larger code if variables are pushed
       onto the stack instead of being held in this register.
*************** These command-line options are defined f
*** 28004,28028 ****
  
       The default value is zero, which disables this feature.  Note, this
       feature is not enabled by default with higher optimization levels
!      ('-O2' etc) because of the potentially detrimental effects of
       reserving a register.  It is up to the programmer to experiment and
       discover whether this feature is of benefit to their program.  See
!      the description of the '-mpid' option for a description of how the
       actual register to hold the small data area pointer is chosen.
  
! '-msim'
! '-mno-sim'
       Use the simulator runtime.  The default is to use the libgloss
       board-specific runtime.
  
! '-mas100-syntax'
! '-mno-as100-syntax'
       When generating assembler output use a syntax that is compatible
       with Renesas's AS100 assembler.  This syntax can also be handled by
       the GAS assembler, but it has some restrictions so it is not
       generated by default.
  
! '-mmax-constant-size=N'
       Specifies the maximum size, in bytes, of a constant that can be
       used as an operand in a RX instruction.  Although the RX
       instruction set does allow constants of up to 4 bytes in length to
--- 28014,28038 ----
  
       The default value is zero, which disables this feature.  Note, this
       feature is not enabled by default with higher optimization levels
!      (‘-O2’ etc) because of the potentially detrimental effects of
       reserving a register.  It is up to the programmer to experiment and
       discover whether this feature is of benefit to their program.  See
!      the description of the ‘-mpid’ option for a description of how the
       actual register to hold the small data area pointer is chosen.
  
! ‘-msim’
! ‘-mno-sim’
       Use the simulator runtime.  The default is to use the libgloss
       board-specific runtime.
  
! ‘-mas100-syntax’
! ‘-mno-as100-syntax’
       When generating assembler output use a syntax that is compatible
       with Renesas's AS100 assembler.  This syntax can also be handled by
       the GAS assembler, but it has some restrictions so it is not
       generated by default.
  
! ‘-mmax-constant-size=N’
       Specifies the maximum size, in bytes, of a constant that can be
       used as an operand in a RX instruction.  Although the RX
       instruction set does allow constants of up to 4 bytes in length to
*************** These command-line options are defined f
*** 28035,28063 ****
       The value N can be between 0 and 4.  A value of 0 (the default) or
       4 means that constants of any size are allowed.
  
! '-mrelax'
       Enable linker relaxation.  Linker relaxation is a process whereby
       the linker attempts to reduce the size of a program by finding
       shorter versions of various instructions.  Disabled by default.
  
! '-mint-register=N'
       Specify the number of registers to reserve for fast interrupt
       handler functions.  The value N can be between 0 and 4.  A value of
!      1 means that register 'r13' is reserved for the exclusive use of
!      fast interrupt handlers.  A value of 2 reserves 'r13' and 'r12'.  A
!      value of 3 reserves 'r13', 'r12' and 'r11', and a value of 4
!      reserves 'r13' through 'r10'.  A value of 0, the default, does not
       reserve any registers.
  
! '-msave-acc-in-interrupts'
       Specifies that interrupt handler functions should preserve the
       accumulator register.  This is only necessary if normal code might
       use the accumulator register, for example because it performs
       64-bit multiplications.  The default is to ignore the accumulator
       as this makes the interrupt handlers faster.
  
! '-mpid'
! '-mno-pid'
       Enables the generation of position independent data.  When enabled
       any access to constant data is done via an offset from a base
       address held in a register.  This allows the location of constant
--- 28045,28073 ----
       The value N can be between 0 and 4.  A value of 0 (the default) or
       4 means that constants of any size are allowed.
  
! ‘-mrelax’
       Enable linker relaxation.  Linker relaxation is a process whereby
       the linker attempts to reduce the size of a program by finding
       shorter versions of various instructions.  Disabled by default.
  
! ‘-mint-register=N’
       Specify the number of registers to reserve for fast interrupt
       handler functions.  The value N can be between 0 and 4.  A value of
!      1 means that register ‘r13’ is reserved for the exclusive use of
!      fast interrupt handlers.  A value of 2 reserves ‘r13’ and ‘r12’.  A
!      value of 3 reserves ‘r13’, ‘r12’ and ‘r11’, and a value of 4
!      reserves ‘r13’ through ‘r10’.  A value of 0, the default, does not
       reserve any registers.
  
! ‘-msave-acc-in-interrupts’
       Specifies that interrupt handler functions should preserve the
       accumulator register.  This is only necessary if normal code might
       use the accumulator register, for example because it performs
       64-bit multiplications.  The default is to ignore the accumulator
       as this makes the interrupt handlers faster.
  
! ‘-mpid’
! ‘-mno-pid’
       Enables the generation of position independent data.  When enabled
       any access to constant data is done via an offset from a base
       address held in a register.  This allows the location of constant
*************** These command-line options are defined f
*** 28066,28099 ****
       tight memory constraints.  Data that can be modified is not
       affected by this option.
  
!      Note, using this feature reserves a register, usually 'r13', for
       the constant data base address.  This can result in slower and/or
       larger code, especially in complicated functions.
  
       The actual register chosen to hold the constant data base address
!      depends upon whether the '-msmall-data-limit' and/or the
!      '-mint-register' command-line options are enabled.  Starting with
!      register 'r13' and proceeding downwards, registers are allocated
!      first to satisfy the requirements of '-mint-register', then '-mpid'
!      and finally '-msmall-data-limit'.  Thus it is possible for the
!      small data area register to be 'r8' if both '-mint-register=4' and
!      '-mpid' are specified on the command line.
  
       By default this feature is not enabled.  The default can be
!      restored via the '-mno-pid' command-line option.
  
! '-mno-warn-multiple-fast-interrupts'
! '-mwarn-multiple-fast-interrupts'
       Prevents GCC from issuing a warning message if it finds more than
       one fast interrupt handler when it is compiling a file.  The
       default is to issue a warning for each extra fast interrupt handler
       found, as the RX only supports one such interrupt.
  
! '-mallow-string-insns'
! '-mno-allow-string-insns'
       Enables or disables the use of the string manipulation instructions
!      'SMOVF', 'SCMPU', 'SMOVB', 'SMOVU', 'SUNTIL' 'SWHILE' and also the
!      'RMPA' instruction.  These instructions may prefetch data, which is
       not safe to do if accessing an I/O register.  (See section 12.2.7
       of the RX62N Group User's Manual for more information).
  
--- 28076,28109 ----
       tight memory constraints.  Data that can be modified is not
       affected by this option.
  
!      Note, using this feature reserves a register, usually ‘r13’, for
       the constant data base address.  This can result in slower and/or
       larger code, especially in complicated functions.
  
       The actual register chosen to hold the constant data base address
!      depends upon whether the ‘-msmall-data-limit’ and/or the
!      ‘-mint-register’ command-line options are enabled.  Starting with
!      register ‘r13’ and proceeding downwards, registers are allocated
!      first to satisfy the requirements of ‘-mint-register’, then ‘-mpid’
!      and finally ‘-msmall-data-limit’.  Thus it is possible for the
!      small data area register to be ‘r8’ if both ‘-mint-register=4’ and
!      ‘-mpid’ are specified on the command line.
  
       By default this feature is not enabled.  The default can be
!      restored via the ‘-mno-pid’ command-line option.
  
! ‘-mno-warn-multiple-fast-interrupts’
! ‘-mwarn-multiple-fast-interrupts’
       Prevents GCC from issuing a warning message if it finds more than
       one fast interrupt handler when it is compiling a file.  The
       default is to issue a warning for each extra fast interrupt handler
       found, as the RX only supports one such interrupt.
  
! ‘-mallow-string-insns’
! ‘-mno-allow-string-insns’
       Enables or disables the use of the string manipulation instructions
!      ‘SMOVF’, ‘SCMPU’, ‘SMOVB’, ‘SMOVU’, ‘SUNTIL’ ‘SWHILE’ and also the
!      ‘RMPA’ instruction.  These instructions may prefetch data, which is
       not safe to do if accessing an I/O register.  (See section 12.2.7
       of the RX62N Group User's Manual for more information).
  
*************** These command-line options are defined f
*** 28101,28127 ****
       for GCC to reliably detect all circumstances where a string
       instruction might be used to access an I/O register, so their use
       cannot be disabled automatically.  Instead it is reliant upon the
!      programmer to use the '-mno-allow-string-insns' option if their
       program accesses I/O space.
  
       When the instructions are enabled GCC defines the C preprocessor
!      symbol '__RX_ALLOW_STRING_INSNS__', otherwise it defines the symbol
!      '__RX_DISALLOW_STRING_INSNS__'.
  
! '-mjsr'
! '-mno-jsr'
!      Use only (or not only) 'JSR' instructions to access functions.
!      This option can be used when code size exceeds the range of 'BSR'
!      instructions.  Note that '-mno-jsr' does not mean to not use 'JSR'
       but instead means that any type of branch may be used.
  
!  _Note:_ The generic GCC command-line option '-ffixed-REG' has special
! significance to the RX port when used with the 'interrupt' function
  attribute.  This attribute indicates a function intended to process fast
! interrupts.  GCC ensures that it only uses the registers 'r10', 'r11',
! 'r12' and/or 'r13' and only provided that the normal use of the
! corresponding registers have been restricted via the '-ffixed-REG' or
! '-mint-register' command-line options.
  
  
  File: gcc.info,  Node: S/390 and zSeries Options,  Next: SH Options,  Prev: RX Options,  Up: Submodel Options
--- 28111,28137 ----
       for GCC to reliably detect all circumstances where a string
       instruction might be used to access an I/O register, so their use
       cannot be disabled automatically.  Instead it is reliant upon the
!      programmer to use the ‘-mno-allow-string-insns’ option if their
       program accesses I/O space.
  
       When the instructions are enabled GCC defines the C preprocessor
!      symbol ‘__RX_ALLOW_STRING_INSNS__’, otherwise it defines the symbol
!      ‘__RX_DISALLOW_STRING_INSNS__’.
  
! ‘-mjsr’
! ‘-mno-jsr’
!      Use only (or not only) ‘JSR’ instructions to access functions.
!      This option can be used when code size exceeds the range of ‘BSR’
!      instructions.  Note that ‘-mno-jsr’ does not mean to not use ‘JSR’
       but instead means that any type of branch may be used.
  
!  _Note:_ The generic GCC command-line option ‘-ffixed-REG’ has special
! significance to the RX port when used with the ‘interrupt’ function
  attribute.  This attribute indicates a function intended to process fast
! interrupts.  GCC ensures that it only uses the registers ‘r10’, ‘r11’,
! ‘r12’ and/or ‘r13’ and only provided that the normal use of the
! corresponding registers have been restricted via the ‘-ffixed-REG’ or
! ‘-mint-register’ command-line options.
  
  
  File: gcc.info,  Node: S/390 and zSeries Options,  Next: SH Options,  Prev: RX Options,  Up: Submodel Options
*************** File: gcc.info,  Node: S/390 and zSeries
*** 28129,28316 ****
  3.19.44 S/390 and zSeries Options
  ---------------------------------
  
! These are the '-m' options defined for the S/390 and zSeries
  architecture.
  
! '-mhard-float'
! '-msoft-float'
       Use (do not use) the hardware floating-point instructions and
!      registers for floating-point operations.  When '-msoft-float' is
!      specified, functions in 'libgcc.a' are used to perform
!      floating-point operations.  When '-mhard-float' is specified, the
       compiler generates IEEE floating-point instructions.  This is the
       default.
  
! '-mhard-dfp'
! '-mno-hard-dfp'
       Use (do not use) the hardware decimal-floating-point instructions
!      for decimal-floating-point operations.  When '-mno-hard-dfp' is
!      specified, functions in 'libgcc.a' are used to perform
!      decimal-floating-point operations.  When '-mhard-dfp' is specified,
       the compiler generates decimal-floating-point hardware
!      instructions.  This is the default for '-march=z9-ec' or higher.
  
! '-mlong-double-64'
! '-mlong-double-128'
!      These switches control the size of 'long double' type.  A size of
!      64 bits makes the 'long double' type equivalent to the 'double'
       type.  This is the default.
  
! '-mbackchain'
! '-mno-backchain'
       Store (do not store) the address of the caller's frame as backchain
       pointer into the callee's stack frame.  A backchain may be needed
       to allow debugging using tools that do not understand DWARF 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 '-mno-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'.
  
! '-mhtm'
! '-mno-htm'
!      The '-mhtm' option enables a set of builtins making use of
       instructions available with the transactional execution facility
       introduced with the IBM zEnterprise EC12 machine generation *note
!      S/390 System z Built-in Functions::.  '-mhtm' is enabled by default
!      when using '-march=zEC12'.
  
! '-mvx'
! '-mno-vx'
!      When '-mvx' is specified, generate code using the instructions
       available with the vector extension facility introduced with the
       IBM z13 machine generation.  This option changes the ABI for some
       vector type values with regard to alignment and calling
       conventions.  In case vector type values are being used in an
!      ABI-relevant context a GAS '.gnu_attribute' command will be added
!      to mark the resulting binary with the ABI used.  '-mvx' is enabled
!      by default when using '-march=z13'.
  
! '-mzvector'
! '-mno-zvector'
!      The '-mzvector' option enables vector language extensions and
       builtins using instructions available with the vector extension
       facility introduced with the IBM z13 machine generation.  This
!      option adds support for 'vector' to be used as a keyword to define
!      vector type variables and arguments.  'vector' is only available
       when GNU extensions are enabled.  It will not be expanded when
!      requesting strict standard compliance e.g. with '-std=c99'.  In
!      addition to the GCC low-level builtins '-mzvector' enables a set of
       builtins added for compatibility with AltiVec-style implementations
       like Power and Cell.  In order to make use of these builtins the
!      header file 'vecintrin.h' needs to be included.  '-mzvector' is
       disabled by default.
  
! '-mmvcle'
! '-mno-mvcle'
!      Generate (or do not generate) code using the 'mvcle' instruction to
!      perform block moves.  When '-mno-mvcle' is specified, use a 'mvc'
       loop instead.  This is the default unless optimizing for size.
  
! '-mdebug'
! '-mno-debug'
       Print (or do not print) additional debug information when
       compiling.  The default is to not print debug information.
  
! '-march=CPU-TYPE'
       Generate code that runs on CPU-TYPE, which is the name of a system
       representing a certain processor type.  Possible values for
!      CPU-TYPE are 'z900'/'arch5', 'z990'/'arch6', 'z9-109',
!      'z9-ec'/'arch7', 'z10'/'arch8', 'z196'/'arch9', 'zEC12',
!      'z13'/'arch11', 'z14'/'arch12', 'z15'/'arch13', 'z16'/'arch14', and
!      'native'.
  
!      The default is '-march=z900'.
  
!      Specifying 'native' as cpu type can be used to select the best
!      architecture option for the host processor.  '-march=native' has no
       effect if GCC does not recognize the processor.
  
! '-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.
  
! '-mtpf-trace-skip'
! '-mno-tpf-trace-skip'
       Generate code that changes (does not change) the default branch
!      targets enabled by '-mtpf-trace' to point to specialized trace
       routines providing the ability of selectively skipping function
       trace entries for the TPF OS. This option is off by default, even
!      when compiling for the TPF OS and specifying '-mtpf-trace'.
  
! '-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
--- 28139,28326 ----
  3.19.44 S/390 and zSeries Options
  ---------------------------------
  
! These are the ‘-m’ options defined for the S/390 and zSeries
  architecture.
  
! ‘-mhard-float’
! ‘-msoft-float’
       Use (do not use) the hardware floating-point instructions and
!      registers for floating-point operations.  When ‘-msoft-float’ is
!      specified, functions in ‘libgcc.a’ are used to perform
!      floating-point operations.  When ‘-mhard-float’ is specified, the
       compiler generates IEEE floating-point instructions.  This is the
       default.
  
! ‘-mhard-dfp’
! ‘-mno-hard-dfp’
       Use (do not use) the hardware decimal-floating-point instructions
!      for decimal-floating-point operations.  When ‘-mno-hard-dfp’ is
!      specified, functions in ‘libgcc.a’ are used to perform
!      decimal-floating-point operations.  When ‘-mhard-dfp’ is specified,
       the compiler generates decimal-floating-point hardware
!      instructions.  This is the default for ‘-march=z9-ec’ or higher.
  
! ‘-mlong-double-64’
! ‘-mlong-double-128’
!      These switches control the size of ‘long double’ type.  A size of
!      64 bits makes the ‘long double’ type equivalent to the ‘double’
       type.  This is the default.
  
! ‘-mbackchain’
! ‘-mno-backchain’
       Store (do not store) the address of the caller's frame as backchain
       pointer into the callee's stack frame.  A backchain may be needed
       to allow debugging using tools that do not understand DWARF 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 ‘-mno-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’.
  
! ‘-mhtm’
! ‘-mno-htm’
!      The ‘-mhtm’ option enables a set of builtins making use of
       instructions available with the transactional execution facility
       introduced with the IBM zEnterprise EC12 machine generation *note
!      S/390 System z Built-in Functions::.  ‘-mhtm’ is enabled by default
!      when using ‘-march=zEC12’.
  
! ‘-mvx’
! ‘-mno-vx’
!      When ‘-mvx’ is specified, generate code using the instructions
       available with the vector extension facility introduced with the
       IBM z13 machine generation.  This option changes the ABI for some
       vector type values with regard to alignment and calling
       conventions.  In case vector type values are being used in an
!      ABI-relevant context a GAS ‘.gnu_attribute’ command will be added
!      to mark the resulting binary with the ABI used.  ‘-mvx’ is enabled
!      by default when using ‘-march=z13’.
  
! ‘-mzvector’
! ‘-mno-zvector’
!      The ‘-mzvector’ option enables vector language extensions and
       builtins using instructions available with the vector extension
       facility introduced with the IBM z13 machine generation.  This
!      option adds support for ‘vector’ to be used as a keyword to define
!      vector type variables and arguments.  ‘vector’ is only available
       when GNU extensions are enabled.  It will not be expanded when
!      requesting strict standard compliance e.g. with ‘-std=c99’.  In
!      addition to the GCC low-level builtins ‘-mzvector’ enables a set of
       builtins added for compatibility with AltiVec-style implementations
       like Power and Cell.  In order to make use of these builtins the
!      header file ‘vecintrin.h’ needs to be included.  ‘-mzvector’ is
       disabled by default.
  
! ‘-mmvcle’
! ‘-mno-mvcle’
!      Generate (or do not generate) code using the ‘mvcle’ instruction to
!      perform block moves.  When ‘-mno-mvcle’ is specified, use a ‘mvc’
       loop instead.  This is the default unless optimizing for size.
  
! ‘-mdebug’
! ‘-mno-debug’
       Print (or do not print) additional debug information when
       compiling.  The default is to not print debug information.
  
! ‘-march=CPU-TYPE’
       Generate code that runs on CPU-TYPE, which is the name of a system
       representing a certain processor type.  Possible values for
!      CPU-TYPE are ‘z900’/‘arch5’, ‘z990’/‘arch6’, ‘z9-109’,
!      ‘z9-ec’/‘arch7’, ‘z10’/‘arch8’, ‘z196’/‘arch9’, ‘zEC12’,
!      ‘z13’/‘arch11’, ‘z14’/‘arch12’, ‘z15’/‘arch13’, ‘z16’/‘arch14’, and
!      ‘native’.
  
!      The default is ‘-march=z900’.
  
!      Specifying ‘native’ as cpu type can be used to select the best
!      architecture option for the host processor.  ‘-march=native’ has no
       effect if GCC does not recognize the processor.
  
! ‘-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.
  
! ‘-mtpf-trace-skip’
! ‘-mno-tpf-trace-skip’
       Generate code that changes (does not change) the default branch
!      targets enabled by ‘-mtpf-trace’ to point to specialized trace
       routines providing the ability of selectively skipping function
       trace entries for the TPF OS. This option is off by default, even
!      when compiling for the TPF OS and specifying ‘-mtpf-trace’.
  
! ‘-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
*************** architecture.
*** 28318,28330 ****
       to be used in an environment with limited stack size e.g. the linux
       kernel.
  
! '-mwarn-dynamicstack'
!      Emit a warning if the function calls 'alloca' or uses
       dynamically-sized arrays.  This is generally a bad idea with a
       limited stack size.
  
! '-mstack-guard=STACK-GUARD'
! '-mstack-size=STACK-SIZE'
       If these options are provided the S/390 back end emits additional
       instructions in the function prologue that trigger a trap if the
       stack size is STACK-GUARD bytes above the STACK-SIZE (remember that
--- 28328,28340 ----
       to be used in an environment with limited stack size e.g. the linux
       kernel.
  
! ‘-mwarn-dynamicstack’
!      Emit a warning if the function calls ‘alloca’ or uses
       dynamically-sized arrays.  This is generally a bad idea with a
       limited stack size.
  
! ‘-mstack-guard=STACK-GUARD’
! ‘-mstack-size=STACK-SIZE’
       If these options are provided the S/390 back end emits additional
       instructions in the function prologue that trigger a trap if the
       stack size is STACK-GUARD bytes above the STACK-SIZE (remember that
*************** architecture.
*** 28340,28346 ****
       at an address aligned to the value given by STACK-SIZE.  The
       STACK-GUARD option can only be used in conjunction with STACK-SIZE.
  
! '-mhotpatch=PRE-HALFWORDS,POST-HALFWORDS'
       If the hotpatch option is enabled, a "hot-patching" function
       prologue is generated for all functions in the compilation unit.
       The funtion label is prepended with the given number of two-byte
--- 28350,28356 ----
       at an address aligned to the value given by STACK-SIZE.  The
       STACK-GUARD option can only be used in conjunction with STACK-SIZE.
  
! ‘-mhotpatch=PRE-HALFWORDS,POST-HALFWORDS’
       If the hotpatch option is enabled, a "hot-patching" function
       prologue is generated for all functions in the compilation unit.
       The funtion label is prepended with the given number of two-byte
*************** architecture.
*** 28351,28357 ****
       If both arguments are zero, hotpatching is disabled.
  
       This option can be overridden for individual functions with the
!      'hotpatch' attribute.
  
  
  File: gcc.info,  Node: SH Options,  Next: Solaris 2 Options,  Prev: S/390 and zSeries Options,  Up: Submodel Options
--- 28361,28367 ----
       If both arguments are zero, hotpatching is disabled.
  
       This option can be overridden for individual functions with the
!      ‘hotpatch’ attribute.
  
  
  File: gcc.info,  Node: SH Options,  Next: Solaris 2 Options,  Prev: S/390 and zSeries Options,  Up: Submodel Options
*************** File: gcc.info,  Node: SH Options,  Next
*** 28359,28594 ****
  3.19.45 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.
  
! '-m4-100'
       Generate code for SH4-100.
  
! '-m4-100-nofpu'
       Generate code for SH4-100 in such a way that the floating-point
       unit is not used.
  
! '-m4-100-single'
       Generate code for SH4-100 assuming the floating-point unit is in
       single-precision mode by default.
  
! '-m4-100-single-only'
       Generate code for SH4-100 in such a way that no double-precision
       floating-point operations are used.
  
! '-m4-200'
       Generate code for SH4-200.
  
! '-m4-200-nofpu'
       Generate code for SH4-200 without in such a way that the
       floating-point unit is not used.
  
! '-m4-200-single'
       Generate code for SH4-200 assuming the floating-point unit is in
       single-precision mode by default.
  
! '-m4-200-single-only'
       Generate code for SH4-200 in such a way that no double-precision
       floating-point operations are used.
  
! '-m4-300'
       Generate code for SH4-300.
  
! '-m4-300-nofpu'
       Generate code for SH4-300 without in such a way that the
       floating-point unit is not used.
  
! '-m4-300-single'
       Generate code for SH4-300 in such a way that no double-precision
       floating-point operations are used.
  
! '-m4-300-single-only'
       Generate code for SH4-300 in such a way that no double-precision
       floating-point operations are used.
  
! '-m4-340'
       Generate code for SH4-340 (no MMU, no FPU).
  
! '-m4-500'
!      Generate code for SH4-500 (no FPU). Passes '-isa=sh4-nofpu' to the
       assembler.
  
! '-m4a-nofpu'
       Generate code for the SH4al-dsp, or for a SH4a in such a way that
       the floating-point unit is not used.
  
! '-m4a-single-only'
       Generate code for the SH4a, in such a way that no double-precision
       floating-point operations are used.
  
! '-m4a-single'
       Generate code for the SH4a assuming the floating-point unit is in
       single-precision mode by default.
  
! '-m4a'
       Generate code for the SH4a.
  
! '-m4al'
!      Same as '-m4a-nofpu', except that it implicitly passes '-dsp' to
       the assembler.  GCC doesn't generate any DSP instructions at the
       moment.
  
! '-mb'
       Compile code for the processor in big-endian mode.
  
! '-ml'
       Compile code for the processor in little-endian mode.
  
! '-mdalign'
       Align doubles at 64-bit boundaries.  Note that this changes the
       calling conventions, and thus some functions from the standard C
!      library do not work unless you recompile it first with '-mdalign'.
  
! '-mrelax'
       Shorten some address references at link time, when possible; uses
!      the linker option '-relax'.
  
! '-mbigtable'
!      Use 32-bit offsets in 'switch' tables.  The default is to use
       16-bit offsets.
  
! '-mbitops'
       Enable the use of bit manipulation instructions on SH2A.
  
! '-mfmovd'
!      Enable the use of the instruction 'fmovd'.  Check '-mdalign' for
       alignment constraints.
  
! '-mrenesas'
       Comply with the calling conventions defined by Renesas.
  
! '-mno-renesas'
       Comply with the calling conventions defined for GCC before the
       Renesas conventions were available.  This option is the default for
       all targets of the SH toolchain.
  
! '-mnomacsave'
!      Mark the 'MAC' register as call-clobbered, even if '-mrenesas' is
       given.
  
! '-mieee'
! '-mno-ieee'
       Control the IEEE compliance of floating-point comparisons, which
       affects the handling of cases where the result of a comparison is
!      unordered.  By default '-mieee' is implicitly enabled.  If
!      '-ffinite-math-only' is enabled '-mno-ieee' is implicitly set,
       which results in faster floating-point greater-equal and less-equal
       comparisons.  The implicit settings can be overridden by specifying
!      either '-mieee' or '-mno-ieee'.
  
! '-minline-ic_invalidate'
       Inline code to invalidate instruction cache entries after setting
       up nested function trampolines.  This option has no effect if
!      '-musermode' is in effect and the selected code generation option
!      (e.g. '-m4') does not allow the use of the 'icbi' instruction.  If
       the selected code generation option does not allow the use of the
!      'icbi' instruction, and '-musermode' is not in effect, the inlined
       code manipulates the instruction cache address array directly with
       an associative write.  This not only requires privileged mode at
       run time, but it also fails if the cache line had been mapped via
       the TLB and has become unmapped.
  
! '-misize'
       Dump instruction size and location in the assembly code.
  
! '-mpadstruct'
       This option is deprecated.  It pads structures to multiple of 4
       bytes, which is incompatible with the SH ABI.
  
! '-matomic-model=MODEL'
       Sets the model of atomic operations and additional parameters as a
       comma separated list.  For details on the atomic built-in functions
       see *note __atomic Builtins::.  The following models and parameters
       are supported:
  
!      'none'
            Disable compiler generated atomic sequences and emit library
            calls for atomic operations.  This is the default if the
!           target is not 'sh*-*-linux*'.
  
!      'soft-gusa'
            Generate GNU/Linux compatible gUSA software atomic sequences
            for the atomic built-in functions.  The generated atomic
            sequences require additional support from the
            interrupt/exception handling code of the system and are only
            suitable for SH3* and SH4* single-core systems.  This option
!           is enabled by default when the target is 'sh*-*-linux*' and
            SH3* or SH4*.  When the target is SH4A, this option also
!           partially utilizes the hardware atomic instructions 'movli.l'
!           and 'movco.l' to create more efficient code, unless 'strict'
            is specified.
  
!      'soft-tcb'
            Generate software atomic sequences that use a variable in the
            thread control block.  This is a variation of the gUSA
            sequences which can also be used on SH1* and SH2* targets.
            The generated atomic sequences require additional support from
            the interrupt/exception handling code of the system and are
            only suitable for single-core systems.  When using this model,
!           the 'gbr-offset=' parameter has to be specified as well.
  
!      'soft-imask'
            Generate software atomic sequences that temporarily disable
!           interrupts by setting 'SR.IMASK = 1111'.  This model works
            only when the program runs in privileged mode and is only
            suitable for single-core systems.  Additional support from the
            interrupt/exception handling code of the system is not
            required.  This model is enabled by default when the target is
!           'sh*-*-linux*' and SH1* or SH2*.
  
!      'hard-llcs'
!           Generate hardware atomic sequences using the 'movli.l' and
!           'movco.l' instructions only.  This is only available on SH4A
            and is suitable for multi-core systems.  Since the hardware
            instructions support only 32 bit atomic variables access to 8
            or 16 bit variables is emulated with 32 bit accesses.  Code
--- 28369,28604 ----
  3.19.45 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.
  
! ‘-m4-100’
       Generate code for SH4-100.
  
! ‘-m4-100-nofpu’
       Generate code for SH4-100 in such a way that the floating-point
       unit is not used.
  
! ‘-m4-100-single’
       Generate code for SH4-100 assuming the floating-point unit is in
       single-precision mode by default.
  
! ‘-m4-100-single-only’
       Generate code for SH4-100 in such a way that no double-precision
       floating-point operations are used.
  
! ‘-m4-200’
       Generate code for SH4-200.
  
! ‘-m4-200-nofpu’
       Generate code for SH4-200 without in such a way that the
       floating-point unit is not used.
  
! ‘-m4-200-single’
       Generate code for SH4-200 assuming the floating-point unit is in
       single-precision mode by default.
  
! ‘-m4-200-single-only’
       Generate code for SH4-200 in such a way that no double-precision
       floating-point operations are used.
  
! ‘-m4-300’
       Generate code for SH4-300.
  
! ‘-m4-300-nofpu’
       Generate code for SH4-300 without in such a way that the
       floating-point unit is not used.
  
! ‘-m4-300-single’
       Generate code for SH4-300 in such a way that no double-precision
       floating-point operations are used.
  
! ‘-m4-300-single-only’
       Generate code for SH4-300 in such a way that no double-precision
       floating-point operations are used.
  
! ‘-m4-340’
       Generate code for SH4-340 (no MMU, no FPU).
  
! ‘-m4-500’
!      Generate code for SH4-500 (no FPU). Passes ‘-isa=sh4-nofpu’ to the
       assembler.
  
! ‘-m4a-nofpu’
       Generate code for the SH4al-dsp, or for a SH4a in such a way that
       the floating-point unit is not used.
  
! ‘-m4a-single-only’
       Generate code for the SH4a, in such a way that no double-precision
       floating-point operations are used.
  
! ‘-m4a-single’
       Generate code for the SH4a assuming the floating-point unit is in
       single-precision mode by default.
  
! ‘-m4a’
       Generate code for the SH4a.
  
! ‘-m4al’
!      Same as ‘-m4a-nofpu’, except that it implicitly passes ‘-dsp’ to
       the assembler.  GCC doesn't generate any DSP instructions at the
       moment.
  
! ‘-mb’
       Compile code for the processor in big-endian mode.
  
! ‘-ml’
       Compile code for the processor in little-endian mode.
  
! ‘-mdalign’
       Align doubles at 64-bit boundaries.  Note that this changes the
       calling conventions, and thus some functions from the standard C
!      library do not work unless you recompile it first with ‘-mdalign’.
  
! ‘-mrelax’
       Shorten some address references at link time, when possible; uses
!      the linker option ‘-relax’.
  
! ‘-mbigtable’
!      Use 32-bit offsets in ‘switch’ tables.  The default is to use
       16-bit offsets.
  
! ‘-mbitops’
       Enable the use of bit manipulation instructions on SH2A.
  
! ‘-mfmovd’
!      Enable the use of the instruction ‘fmovd’.  Check ‘-mdalign’ for
       alignment constraints.
  
! ‘-mrenesas’
       Comply with the calling conventions defined by Renesas.
  
! ‘-mno-renesas’
       Comply with the calling conventions defined for GCC before the
       Renesas conventions were available.  This option is the default for
       all targets of the SH toolchain.
  
! ‘-mnomacsave’
!      Mark the ‘MAC’ register as call-clobbered, even if ‘-mrenesas’ is
       given.
  
! ‘-mieee’
! ‘-mno-ieee’
       Control the IEEE compliance of floating-point comparisons, which
       affects the handling of cases where the result of a comparison is
!      unordered.  By default ‘-mieee’ is implicitly enabled.  If
!      ‘-ffinite-math-only’ is enabled ‘-mno-ieee’ is implicitly set,
       which results in faster floating-point greater-equal and less-equal
       comparisons.  The implicit settings can be overridden by specifying
!      either ‘-mieee’ or ‘-mno-ieee’.
  
! ‘-minline-ic_invalidate’
       Inline code to invalidate instruction cache entries after setting
       up nested function trampolines.  This option has no effect if
!      ‘-musermode’ is in effect and the selected code generation option
!      (e.g. ‘-m4’) does not allow the use of the ‘icbi’ instruction.  If
       the selected code generation option does not allow the use of the
!      ‘icbi’ instruction, and ‘-musermode’ is not in effect, the inlined
       code manipulates the instruction cache address array directly with
       an associative write.  This not only requires privileged mode at
       run time, but it also fails if the cache line had been mapped via
       the TLB and has become unmapped.
  
! ‘-misize’
       Dump instruction size and location in the assembly code.
  
! ‘-mpadstruct’
       This option is deprecated.  It pads structures to multiple of 4
       bytes, which is incompatible with the SH ABI.
  
! ‘-matomic-model=MODEL’
       Sets the model of atomic operations and additional parameters as a
       comma separated list.  For details on the atomic built-in functions
       see *note __atomic Builtins::.  The following models and parameters
       are supported:
  
!      ‘none’
            Disable compiler generated atomic sequences and emit library
            calls for atomic operations.  This is the default if the
!           target is not ‘sh*-*-linux*’.
  
!      ‘soft-gusa’
            Generate GNU/Linux compatible gUSA software atomic sequences
            for the atomic built-in functions.  The generated atomic
            sequences require additional support from the
            interrupt/exception handling code of the system and are only
            suitable for SH3* and SH4* single-core systems.  This option
!           is enabled by default when the target is ‘sh*-*-linux*’ and
            SH3* or SH4*.  When the target is SH4A, this option also
!           partially utilizes the hardware atomic instructions ‘movli.l’
!           and ‘movco.l’ to create more efficient code, unless ‘strict’
            is specified.
  
!      ‘soft-tcb’
            Generate software atomic sequences that use a variable in the
            thread control block.  This is a variation of the gUSA
            sequences which can also be used on SH1* and SH2* targets.
            The generated atomic sequences require additional support from
            the interrupt/exception handling code of the system and are
            only suitable for single-core systems.  When using this model,
!           the ‘gbr-offset=’ parameter has to be specified as well.
  
!      ‘soft-imask’
            Generate software atomic sequences that temporarily disable
!           interrupts by setting ‘SR.IMASK = 1111’.  This model works
            only when the program runs in privileged mode and is only
            suitable for single-core systems.  Additional support from the
            interrupt/exception handling code of the system is not
            required.  This model is enabled by default when the target is
!           ‘sh*-*-linux*’ and SH1* or SH2*.
  
!      ‘hard-llcs’
!           Generate hardware atomic sequences using the ‘movli.l’ and
!           ‘movco.l’ instructions only.  This is only available on SH4A
            and is suitable for multi-core systems.  Since the hardware
            instructions support only 32 bit atomic variables access to 8
            or 16 bit variables is emulated with 32 bit accesses.  Code
*************** These '-m' options are defined for the S
*** 28598,28746 ****
            interrupt/exception handling code of the system is not
            required for this model.
  
!      'gbr-offset='
            This parameter specifies the offset in bytes of the variable
            in the thread control block structure that should be used by
!           the generated atomic sequences when the 'soft-tcb' model has
            been selected.  For other models this parameter is ignored.
            The specified value must be an integer multiple of four and in
            the range 0-1020.
  
!      'strict'
            This parameter prevents mixed usage of multiple atomic models,
            even if they are compatible, and makes the compiler generate
            atomic sequences of the specified model only.
  
! '-mtas'
!      Generate the 'tas.b' opcode for '__atomic_test_and_set'.  Notice
       that depending on the particular hardware and software
       configuration this can degrade overall performance due to the
!      operand cache line flushes that are implied by the 'tas.b'
!      instruction.  On multi-core SH4A processors the 'tas.b' instruction
       must be used with caution since it can result in data corruption
       for certain cache configurations.
  
! '-mprefergot'
       When generating position-independent code, emit function calls
       using the Global Offset Table instead of the Procedure Linkage
       Table.
  
! '-musermode'
! '-mno-usermode'
       Don't allow (allow) the compiler generating privileged mode code.
!      Specifying '-musermode' also implies '-mno-inline-ic_invalidate' if
!      the inlined code would not work in user mode.  '-musermode' is the
!      default when the target is 'sh*-*-linux*'.  If the target is SH1*
!      or SH2* '-musermode' has no effect, since there is no user mode.
  
! '-multcost=NUMBER'
       Set the cost to assume for a multiply insn.
  
! '-mdiv=STRATEGY'
       Set the division strategy to be used for integer division
       operations.  STRATEGY can be one of:
  
!      'call-div1'
            Calls a library function that uses the single-step division
!           instruction 'div1' to perform the operation.  Division by zero
            calculates an unspecified result and does not trap.  This is
            the default except for SH4, SH2A and SHcompact.
  
!      'call-fp'
            Calls a library function that performs the operation in double
            precision floating point.  Division by zero causes a
            floating-point exception.  This is the default for SHcompact
            with FPU. Specifying this for targets that do not have a
!           double precision FPU defaults to 'call-div1'.
  
!      'call-table'
            Calls a library function that uses a lookup table for small
!           divisors and the 'div1' instruction with case distinction for
            larger divisors.  Division by zero calculates an unspecified
            result and does not trap.  This is the default for SH4.
            Specifying this for targets that do not have dynamic shift
!           instructions defaults to 'call-div1'.
  
       When a division strategy has not been specified the default
       strategy is selected based on the current target.  For SH2A the
!      default strategy is to use the 'divs' and 'divu' instructions
       instead of library function calls.
  
! '-maccumulate-outgoing-args'
       Reserve space once for outgoing arguments in the function prologue
       rather than around each call.  Generally beneficial for performance
       and size.  Also needed for unwinding to avoid changing the stack
       frame around conditional code.
  
! '-mdivsi3_libfunc=NAME'
       Set the name of the library function used for 32-bit signed
!      division to NAME.  This only affects the name used in the 'call'
       division strategies, and the compiler still expects the same sets
       of input/output/clobbered registers as if this option were not
       present.
  
! '-mfixed-range=REGISTER-RANGE'
       Generate code treating the given register range as fixed registers.
       A fixed register is one that the register allocator cannot use.
       This is useful when compiling kernel code.  A register range is
       specified as two registers separated by a dash.  Multiple register
       ranges can be specified separated by a comma.
  
! '-mbranch-cost=NUM'
       Assume NUM to be the cost for a branch instruction.  Higher numbers
       make the compiler try to generate more branch-free code if
       possible.  If not specified the value is selected depending on the
       processor type that is being compiled for.
  
! '-mzdcbranch'
! '-mno-zdcbranch'
       Assume (do not assume) that zero displacement conditional branch
!      instructions 'bt' and 'bf' are fast.  If '-mzdcbranch' is
       specified, the compiler prefers zero displacement branch code
       sequences.  This is enabled by default when generating code for SH4
       and SH4A. It can be explicitly disabled by specifying
!      '-mno-zdcbranch'.
  
! '-mcbranch-force-delay-slot'
       Force the usage of delay slots for conditional branches, which
!      stuffs the delay slot with a 'nop' if a suitable instruction cannot
       be found.  By default this option is disabled.  It can be enabled
       to work around hardware bugs as found in the original SH7055.
  
! '-mfused-madd'
! '-mno-fused-madd'
       Generate code that uses (does not use) the floating-point multiply
       and accumulate instructions.  These instructions are generated by
       default if hardware floating point is used.  The machine-dependent
!      '-mfused-madd' option is now mapped to the machine-independent
!      '-ffp-contract=fast' option, and '-mno-fused-madd' is mapped to
!      '-ffp-contract=off'.
  
! '-mfsca'
! '-mno-fsca'
!      Allow or disallow the compiler to emit the 'fsca' instruction for
!      sine and cosine approximations.  The option '-mfsca' must be used
!      in combination with '-funsafe-math-optimizations'.  It is enabled
!      by default when generating code for SH4A. Using '-mno-fsca'
       disables sine and cosine approximations even if
!      '-funsafe-math-optimizations' is in effect.
  
! '-mfsrra'
! '-mno-fsrra'
!      Allow or disallow the compiler to emit the 'fsrra' instruction for
!      reciprocal square root approximations.  The option '-mfsrra' must
!      be used in combination with '-funsafe-math-optimizations' and
!      '-ffinite-math-only'.  It is enabled by default when generating
!      code for SH4A. Using '-mno-fsrra' disables reciprocal square root
!      approximations even if '-funsafe-math-optimizations' and
!      '-ffinite-math-only' are in effect.
  
! '-mpretend-cmove'
       Prefer zero-displacement conditional branches for conditional move
       instruction patterns.  This can result in faster code on the SH4
       processor.
  
! '-mfdpic'
       Generate code using the FDPIC ABI.
  
  
--- 28608,28756 ----
            interrupt/exception handling code of the system is not
            required for this model.
  
!      ‘gbr-offset=’
            This parameter specifies the offset in bytes of the variable
            in the thread control block structure that should be used by
!           the generated atomic sequences when the ‘soft-tcb’ model has
            been selected.  For other models this parameter is ignored.
            The specified value must be an integer multiple of four and in
            the range 0-1020.
  
!      ‘strict’
            This parameter prevents mixed usage of multiple atomic models,
            even if they are compatible, and makes the compiler generate
            atomic sequences of the specified model only.
  
! ‘-mtas’
!      Generate the ‘tas.b’ opcode for ‘__atomic_test_and_set’.  Notice
       that depending on the particular hardware and software
       configuration this can degrade overall performance due to the
!      operand cache line flushes that are implied by the ‘tas.b’
!      instruction.  On multi-core SH4A processors the ‘tas.b’ instruction
       must be used with caution since it can result in data corruption
       for certain cache configurations.
  
! ‘-mprefergot’
       When generating position-independent code, emit function calls
       using the Global Offset Table instead of the Procedure Linkage
       Table.
  
! ‘-musermode’
! ‘-mno-usermode’
       Don't allow (allow) the compiler generating privileged mode code.
!      Specifying ‘-musermode’ also implies ‘-mno-inline-ic_invalidate’ if
!      the inlined code would not work in user mode.  ‘-musermode’ is the
!      default when the target is ‘sh*-*-linux*’.  If the target is SH1*
!      or SH2* ‘-musermode’ has no effect, since there is no user mode.
  
! ‘-multcost=NUMBER’
       Set the cost to assume for a multiply insn.
  
! ‘-mdiv=STRATEGY’
       Set the division strategy to be used for integer division
       operations.  STRATEGY can be one of:
  
!      ‘call-div1’
            Calls a library function that uses the single-step division
!           instruction ‘div1’ to perform the operation.  Division by zero
            calculates an unspecified result and does not trap.  This is
            the default except for SH4, SH2A and SHcompact.
  
!      ‘call-fp’
            Calls a library function that performs the operation in double
            precision floating point.  Division by zero causes a
            floating-point exception.  This is the default for SHcompact
            with FPU. Specifying this for targets that do not have a
!           double precision FPU defaults to ‘call-div1’.
  
!      ‘call-table’
            Calls a library function that uses a lookup table for small
!           divisors and the ‘div1’ instruction with case distinction for
            larger divisors.  Division by zero calculates an unspecified
            result and does not trap.  This is the default for SH4.
            Specifying this for targets that do not have dynamic shift
!           instructions defaults to ‘call-div1’.
  
       When a division strategy has not been specified the default
       strategy is selected based on the current target.  For SH2A the
!      default strategy is to use the ‘divs’ and ‘divu’ instructions
       instead of library function calls.
  
! ‘-maccumulate-outgoing-args’
       Reserve space once for outgoing arguments in the function prologue
       rather than around each call.  Generally beneficial for performance
       and size.  Also needed for unwinding to avoid changing the stack
       frame around conditional code.
  
! ‘-mdivsi3_libfunc=NAME’
       Set the name of the library function used for 32-bit signed
!      division to NAME.  This only affects the name used in the ‘call’
       division strategies, and the compiler still expects the same sets
       of input/output/clobbered registers as if this option were not
       present.
  
! ‘-mfixed-range=REGISTER-RANGE’
       Generate code treating the given register range as fixed registers.
       A fixed register is one that the register allocator cannot use.
       This is useful when compiling kernel code.  A register range is
       specified as two registers separated by a dash.  Multiple register
       ranges can be specified separated by a comma.
  
! ‘-mbranch-cost=NUM’
       Assume NUM to be the cost for a branch instruction.  Higher numbers
       make the compiler try to generate more branch-free code if
       possible.  If not specified the value is selected depending on the
       processor type that is being compiled for.
  
! ‘-mzdcbranch’
! ‘-mno-zdcbranch’
       Assume (do not assume) that zero displacement conditional branch
!      instructions ‘bt’ and ‘bf’ are fast.  If ‘-mzdcbranch’ is
       specified, the compiler prefers zero displacement branch code
       sequences.  This is enabled by default when generating code for SH4
       and SH4A. It can be explicitly disabled by specifying
!      ‘-mno-zdcbranch’.
  
! ‘-mcbranch-force-delay-slot’
       Force the usage of delay slots for conditional branches, which
!      stuffs the delay slot with a ‘nop’ if a suitable instruction cannot
       be found.  By default this option is disabled.  It can be enabled
       to work around hardware bugs as found in the original SH7055.
  
! ‘-mfused-madd’
! ‘-mno-fused-madd’
       Generate code that uses (does not use) the floating-point multiply
       and accumulate instructions.  These instructions are generated by
       default if hardware floating point is used.  The machine-dependent
!      ‘-mfused-madd’ option is now mapped to the machine-independent
!      ‘-ffp-contract=fast’ option, and ‘-mno-fused-madd’ is mapped to
!      ‘-ffp-contract=off’.
  
! ‘-mfsca’
! ‘-mno-fsca’
!      Allow or disallow the compiler to emit the ‘fsca’ instruction for
!      sine and cosine approximations.  The option ‘-mfsca’ must be used
!      in combination with ‘-funsafe-math-optimizations’.  It is enabled
!      by default when generating code for SH4A. Using ‘-mno-fsca’
       disables sine and cosine approximations even if
!      ‘-funsafe-math-optimizations’ is in effect.
  
! ‘-mfsrra’
! ‘-mno-fsrra’
!      Allow or disallow the compiler to emit the ‘fsrra’ instruction for
!      reciprocal square root approximations.  The option ‘-mfsrra’ must
!      be used in combination with ‘-funsafe-math-optimizations’ and
!      ‘-ffinite-math-only’.  It is enabled by default when generating
!      code for SH4A. Using ‘-mno-fsrra’ disables reciprocal square root
!      approximations even if ‘-funsafe-math-optimizations’ and
!      ‘-ffinite-math-only’ are in effect.
  
! ‘-mpretend-cmove’
       Prefer zero-displacement conditional branches for conditional move
       instruction patterns.  This can result in faster code on the SH4
       processor.
  
! ‘-mfdpic’
       Generate code using the FDPIC ABI.
  
  
*************** File: gcc.info,  Node: Solaris 2 Options
*** 28749,28779 ****
  3.19.46 Solaris 2 Options
  -------------------------
  
! These '-m' options are supported on Solaris 2:
  
! '-mclear-hwcap'
!      '-mclear-hwcap' tells the compiler to remove the hardware
       capabilities generated by the Solaris assembler.  This is only
       necessary when object files use ISA extensions not supported by the
       current machine, but check at runtime whether or not to use them.
  
! '-mimpure-text'
!      '-mimpure-text', used in addition to '-shared', tells the compiler
!      to not pass '-z text' to the linker when linking a shared object.
       Using this option, you can link position-dependent code into a
       shared object.
  
!      '-mimpure-text' suppresses the "relocations remain against
       allocatable but non-writable sections" linker error message.
       However, the necessary relocations trigger copy-on-write, and the
       shared object is not actually shared across processes.  Instead of
!      using '-mimpure-text', you should compile all source code with
!      '-fpic' or '-fPIC'.
  
   These switches are supported in addition to the above on Solaris 2:
  
! '-pthreads'
!      This is a synonym for '-pthread'.
  
  
  File: gcc.info,  Node: SPARC Options,  Next: System V Options,  Prev: Solaris 2 Options,  Up: Submodel Options
--- 28759,28789 ----
  3.19.46 Solaris 2 Options
  -------------------------
  
! These ‘-m’ options are supported on Solaris 2:
  
! ‘-mclear-hwcap’
!      ‘-mclear-hwcap’ tells the compiler to remove the hardware
       capabilities generated by the Solaris assembler.  This is only
       necessary when object files use ISA extensions not supported by the
       current machine, but check at runtime whether or not to use them.
  
! ‘-mimpure-text’
!      ‘-mimpure-text’, used in addition to ‘-shared’, tells the compiler
!      to not pass ‘-z text’ to the linker when linking a shared object.
       Using this option, you can link position-dependent code into a
       shared object.
  
!      ‘-mimpure-text’ suppresses the "relocations remain against
       allocatable but non-writable sections" linker error message.
       However, the necessary relocations trigger copy-on-write, and the
       shared object is not actually shared across processes.  Instead of
!      using ‘-mimpure-text’, you should compile all source code with
!      ‘-fpic’ or ‘-fPIC’.
  
   These switches are supported in addition to the above on Solaris 2:
  
! ‘-pthreads’
!      This is a synonym for ‘-pthread’.
  
  
  File: gcc.info,  Node: SPARC Options,  Next: System V Options,  Prev: Solaris 2 Options,  Up: Submodel Options
*************** File: gcc.info,  Node: SPARC Options,  N
*** 28781,28839 ****
  3.19.47 SPARC Options
  ---------------------
  
! These '-m' options are supported on the SPARC:
  
! '-mno-app-regs'
! '-mapp-regs'
!      Specify '-mapp-regs' to generate output using the global registers
       2 through 4, which the SPARC SVR4 ABI reserves for applications.
       Like the global register 1, each global register 2 through 4 is
       then treated as an allocable register that is clobbered by function
       calls.  This is the default.
  
       To be fully SVR4 ABI-compliant at the cost of some performance
!      loss, specify '-mno-app-regs'.  You should compile libraries and
       system software with this option.
  
! '-mflat'
! '-mno-flat'
!      With '-mflat', the compiler does not generate save/restore
       instructions and uses a "flat" or single register window model.
       This model is compatible with the regular register window model.
       The local registers and the input registers (0-5) are still treated
       as "call-saved" registers and are saved on the stack as needed.
  
!      With '-mno-flat' (the default), the compiler generates save/restore
       instructions (except for leaf functions).  This is the normal
       operating mode.
  
! '-mfpu'
! '-mhard-float'
       Generate output containing floating-point instructions.  This is
       the default.
  
! '-mno-fpu'
! '-msoft-float'
       Generate output containing library calls for floating point.
       *Warning:* the requisite libraries are not available for all SPARC
       targets.  Normally the facilities of the machine's usual C compiler
       are used, but this cannot be done directly in cross-compilation.
       You must make your own arrangements to provide suitable library
       functions for cross-compilation.  The embedded targets
!      'sparc-*-aout' and 'sparclite-*-*' do provide software
       floating-point support.
  
!      '-msoft-float' changes the calling convention in the output file;
       therefore, it is only useful if you compile _all_ of a program with
!      this option.  In particular, you need to compile 'libgcc.a', the
!      library that comes with GCC, with '-msoft-float' in order for this
       to work.
  
! '-mhard-quad-float'
       Generate output containing quad-word (long double) floating-point
       instructions.
  
! '-msoft-quad-float'
       Generate output containing library calls for quad-word (long
       double) floating-point instructions.  The functions called are
       those specified in the SPARC ABI.  This is the default.
--- 28791,28849 ----
  3.19.47 SPARC Options
  ---------------------
  
! These ‘-m’ options are supported on the SPARC:
  
! ‘-mno-app-regs’
! ‘-mapp-regs’
!      Specify ‘-mapp-regs’ to generate output using the global registers
       2 through 4, which the SPARC SVR4 ABI reserves for applications.
       Like the global register 1, each global register 2 through 4 is
       then treated as an allocable register that is clobbered by function
       calls.  This is the default.
  
       To be fully SVR4 ABI-compliant at the cost of some performance
!      loss, specify ‘-mno-app-regs’.  You should compile libraries and
       system software with this option.
  
! ‘-mflat’
! ‘-mno-flat’
!      With ‘-mflat’, the compiler does not generate save/restore
       instructions and uses a "flat" or single register window model.
       This model is compatible with the regular register window model.
       The local registers and the input registers (0-5) are still treated
       as "call-saved" registers and are saved on the stack as needed.
  
!      With ‘-mno-flat’ (the default), the compiler generates save/restore
       instructions (except for leaf functions).  This is the normal
       operating mode.
  
! ‘-mfpu’
! ‘-mhard-float’
       Generate output containing floating-point instructions.  This is
       the default.
  
! ‘-mno-fpu’
! ‘-msoft-float’
       Generate output containing library calls for floating point.
       *Warning:* the requisite libraries are not available for all SPARC
       targets.  Normally the facilities of the machine's usual C compiler
       are used, but this cannot be done directly in cross-compilation.
       You must make your own arrangements to provide suitable library
       functions for cross-compilation.  The embedded targets
!      ‘sparc-*-aout’ and ‘sparclite-*-*’ do provide software
       floating-point support.
  
!      ‘-msoft-float’ changes the calling convention in the output file;
       therefore, it is only useful if you compile _all_ of a program with
!      this option.  In particular, you need to compile ‘libgcc.a’, the
!      library that comes with GCC, with ‘-msoft-float’ in order for this
       to work.
  
! ‘-mhard-quad-float’
       Generate output containing quad-word (long double) floating-point
       instructions.
  
! ‘-msoft-quad-float’
       Generate output containing library calls for quad-word (long
       double) floating-point instructions.  The functions called are
       those specified in the SPARC ABI.  This is the default.
*************** These '-m' options are supported on the
*** 28843,28856 ****
       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
--- 28853,28866 ----
       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
*************** These '-m' options are supported on the
*** 28858,28911 ****
       default because it results in a performance loss, especially for
       floating-point code.
  
! '-muser-mode'
! '-mno-user-mode'
       Do not generate code that can only run in supervisor mode.  This is
!      relevant only for the 'casa' instruction emitted for the LEON3
       processor.  This is the default.
  
! '-mfaster-structs'
! '-mno-faster-structs'
!      With '-mfaster-structs', the compiler assumes that structures
       should have 8-byte alignment.  This enables the use of pairs of
!      'ldd' and 'std' instructions for copies in structure assignment, in
!      place of twice as many 'ld' and 'st' pairs.  However, the use of
       this changed alignment directly violates the SPARC ABI.  Thus, it's
       intended only for use on targets where the developer acknowledges
       that their resulting code is not directly in line with the rules of
       the ABI.
  
! '-mstd-struct-return'
! '-mno-std-struct-return'
!      With '-mstd-struct-return', the compiler generates checking code in
       functions returning structures or unions to detect size mismatches
       between the two sides of function calls, as per the 32-bit ABI.
  
!      The default is '-mno-std-struct-return'.  This option has no effect
       in 64-bit mode.
  
! '-mlra'
! '-mno-lra'
       Enable Local Register Allocation.  This is the default for SPARC
!      since GCC 7 so '-mno-lra' needs to be passed to get old Reload.
  
! '-mcpu=CPU_TYPE'
       Set the instruction set, register set, and instruction scheduling
       parameters for machine type CPU_TYPE.  Supported values for
!      CPU_TYPE are 'v7', 'cypress', 'v8', 'supersparc', 'hypersparc',
!      'leon', 'leon3', 'leon3v7', 'leon5', 'sparclite', 'f930', 'f934',
!      'sparclite86x', 'sparclet', 'tsc701', 'v9', 'ultrasparc',
!      'ultrasparc3', 'niagara', 'niagara2', 'niagara3', 'niagara4',
!      'niagara7' and 'm8'.
  
       Native Solaris and GNU/Linux toolchains also support the value
!      'native', which selects the best architecture option for the host
!      processor.  '-mcpu=native' has no effect if GCC does not recognize
       the processor.
  
       Default instruction scheduling parameters are used for values that
!      select an architecture and not an implementation.  These are 'v7',
!      'v8', 'sparclite', 'sparclet', 'v9'.
  
       Here is a list of each supported architecture and their supported
       implementations.
--- 28868,28921 ----
       default because it results in a performance loss, especially for
       floating-point code.
  
! ‘-muser-mode’
! ‘-mno-user-mode’
       Do not generate code that can only run in supervisor mode.  This is
!      relevant only for the ‘casa’ instruction emitted for the LEON3
       processor.  This is the default.
  
! ‘-mfaster-structs’
! ‘-mno-faster-structs’
!      With ‘-mfaster-structs’, the compiler assumes that structures
       should have 8-byte alignment.  This enables the use of pairs of
!      ‘ldd’ and ‘std’ instructions for copies in structure assignment, in
!      place of twice as many ‘ld’ and ‘st’ pairs.  However, the use of
       this changed alignment directly violates the SPARC ABI.  Thus, it's
       intended only for use on targets where the developer acknowledges
       that their resulting code is not directly in line with the rules of
       the ABI.
  
! ‘-mstd-struct-return’
! ‘-mno-std-struct-return’
!      With ‘-mstd-struct-return’, the compiler generates checking code in
       functions returning structures or unions to detect size mismatches
       between the two sides of function calls, as per the 32-bit ABI.
  
!      The default is ‘-mno-std-struct-return’.  This option has no effect
       in 64-bit mode.
  
! ‘-mlra’
! ‘-mno-lra’
       Enable Local Register Allocation.  This is the default for SPARC
!      since GCC 7 so ‘-mno-lra’ needs to be passed to get old Reload.
  
! ‘-mcpu=CPU_TYPE’
       Set the instruction set, register set, and instruction scheduling
       parameters for machine type CPU_TYPE.  Supported values for
!      CPU_TYPE are ‘v7’, ‘cypress’, ‘v8’, ‘supersparc’, ‘hypersparc’,
!      ‘leon’, ‘leon3’, ‘leon3v7’, ‘leon5’, ‘sparclite’, ‘f930’, ‘f934’,
!      ‘sparclite86x’, ‘sparclet’, ‘tsc701’, ‘v9’, ‘ultrasparc’,
!      ‘ultrasparc3’, ‘niagara’, ‘niagara2’, ‘niagara3’, ‘niagara4’,
!      ‘niagara7’ and ‘m8’.
  
       Native Solaris and GNU/Linux toolchains also support the value
!      ‘native’, which selects the best architecture option for the host
!      processor.  ‘-mcpu=native’ has no effect if GCC does not recognize
       the processor.
  
       Default instruction scheduling parameters are used for values that
!      select an architecture and not an implementation.  These are ‘v7’,
!      ‘v8’, ‘sparclite’, ‘sparclet’, ‘v9’.
  
       Here is a list of each supported architecture and their supported
       implementations.
*************** These '-m' options are supported on the
*** 28927,29120 ****
            niagara4, niagara7, m8
  
       By default (unless configured otherwise), GCC generates code for
!      the V7 variant of the SPARC architecture.  With '-mcpu=cypress',
       the compiler additionally optimizes it for the Cypress CY7C602
       chip, as used in the SPARCStation/SPARCServer 3xx series.  This is
       also appropriate for the older SPARCStation 1, 2, IPX etc.
  
!      With '-mcpu=v8', GCC generates code for the V8 variant of the SPARC
       architecture.  The only difference from V7 code is that the
       compiler emits the integer multiply and integer divide instructions
       which exist in SPARC-V8 but not in SPARC-V7.  With
!      '-mcpu=supersparc', the compiler additionally optimizes it for the
       SuperSPARC chip, as used in the SPARCStation 10, 1000 and 2000
       series.
  
!      With '-mcpu=sparclite', GCC generates code for the SPARClite
       variant of the SPARC architecture.  This adds the integer multiply,
!      integer divide step and scan ('ffs') instructions which exist in
!      SPARClite but not in SPARC-V7.  With '-mcpu=f930', the compiler
       additionally optimizes it for the Fujitsu MB86930 chip, which is
!      the original SPARClite, with no FPU.  With '-mcpu=f934', the
       compiler additionally optimizes it for the Fujitsu MB86934 chip,
       which is the more recent SPARClite with FPU.
  
!      With '-mcpu=sparclet', GCC generates code for the SPARClet variant
       of the SPARC architecture.  This adds the integer multiply,
!      multiply/accumulate, integer divide step and scan ('ffs')
       instructions which exist in SPARClet but not in SPARC-V7.  With
!      '-mcpu=tsc701', the compiler additionally optimizes it for the
       TEMIC SPARClet chip.
  
!      With '-mcpu=v9', GCC generates code for the V9 variant of the SPARC
       architecture.  This adds 64-bit integer and floating-point move
       instructions, 3 additional floating-point condition code registers
!      and conditional move instructions.  With '-mcpu=ultrasparc', the
       compiler additionally optimizes it for the Sun UltraSPARC I/II/IIi
!      chips.  With '-mcpu=ultrasparc3', the compiler additionally
       optimizes it for the Sun UltraSPARC III/III+/IIIi/IIIi+/IV/IV+
!      chips.  With '-mcpu=niagara', the compiler additionally optimizes
!      it for Sun UltraSPARC T1 chips.  With '-mcpu=niagara2', the
       compiler additionally optimizes it for Sun UltraSPARC T2 chips.
!      With '-mcpu=niagara3', the compiler additionally optimizes it for
!      Sun UltraSPARC T3 chips.  With '-mcpu=niagara4', the compiler
       additionally optimizes it for Sun UltraSPARC T4 chips.  With
!      '-mcpu=niagara7', the compiler additionally optimizes it for Oracle
!      SPARC M7 chips.  With '-mcpu=m8', the compiler additionally
       optimizes it for Oracle M8 chips.
  
! '-mtune=CPU_TYPE'
       Set the instruction scheduling parameters for machine type
       CPU_TYPE, but do not set the instruction set or register set that
!      the option '-mcpu=CPU_TYPE' does.
  
!      The same values for '-mcpu=CPU_TYPE' can be used for
!      '-mtune=CPU_TYPE', but the only useful values are those that select
!      a particular CPU implementation.  Those are 'cypress',
!      'supersparc', 'hypersparc', 'leon', 'leon3', 'leon3v7', 'leon5',
!      'f930', 'f934', 'sparclite86x', 'tsc701', 'ultrasparc',
!      'ultrasparc3', 'niagara', 'niagara2', 'niagara3', 'niagara4',
!      'niagara7' and 'm8'.  With native Solaris and GNU/Linux toolchains,
!      'native' can also be used.
  
! '-mv8plus'
! '-mno-v8plus'
!      With '-mv8plus', GCC generates code for the SPARC-V8+ ABI.  The
       difference from the V8 ABI is that the global and out registers are
       considered 64 bits wide.  This is enabled by default on Solaris in
       32-bit mode for all SPARC-V9 processors.
  
! '-mvis'
! '-mno-vis'
!      With '-mvis', GCC generates code that takes advantage of the
       UltraSPARC Visual Instruction Set extensions.  The default is
!      '-mno-vis'.
  
! '-mvis2'
! '-mno-vis2'
!      With '-mvis2', GCC generates code that takes advantage of version
       2.0 of the UltraSPARC Visual Instruction Set extensions.  The
!      default is '-mvis2' when targeting a cpu that supports such
!      instructions, such as UltraSPARC-III and later.  Setting '-mvis2'
!      also sets '-mvis'.
  
! '-mvis3'
! '-mno-vis3'
!      With '-mvis3', GCC generates code that takes advantage of version
       3.0 of the UltraSPARC Visual Instruction Set extensions.  The
!      default is '-mvis3' when targeting a cpu that supports such
!      instructions, such as niagara-3 and later.  Setting '-mvis3' also
!      sets '-mvis2' and '-mvis'.
  
! '-mvis4'
! '-mno-vis4'
!      With '-mvis4', GCC generates code that takes advantage of version
       4.0 of the UltraSPARC Visual Instruction Set extensions.  The
!      default is '-mvis4' when targeting a cpu that supports such
!      instructions, such as niagara-7 and later.  Setting '-mvis4' also
!      sets '-mvis3', '-mvis2' and '-mvis'.
  
! '-mvis4b'
! '-mno-vis4b'
!      With '-mvis4b', GCC generates code that takes advantage of version
       4.0 of the UltraSPARC Visual Instruction Set extensions, plus the
       additional VIS instructions introduced in the Oracle SPARC
!      Architecture 2017.  The default is '-mvis4b' when targeting a cpu
       that supports such instructions, such as m8 and later.  Setting
!      '-mvis4b' also sets '-mvis4', '-mvis3', '-mvis2' and '-mvis'.
  
! '-mcbcond'
! '-mno-cbcond'
!      With '-mcbcond', GCC generates code that takes advantage of the
       UltraSPARC Compare-and-Branch-on-Condition instructions.  The
!      default is '-mcbcond' when targeting a CPU that supports such
       instructions, such as Niagara-4 and later.
  
! '-mfmaf'
! '-mno-fmaf'
!      With '-mfmaf', GCC generates code that takes advantage of the
       UltraSPARC Fused Multiply-Add Floating-point instructions.  The
!      default is '-mfmaf' when targeting a CPU that supports such
       instructions, such as Niagara-3 and later.
  
! '-mfsmuld'
! '-mno-fsmuld'
!      With '-mfsmuld', GCC generates code that takes advantage of the
       Floating-point Multiply Single to Double (FsMULd) instruction.  The
!      default is '-mfsmuld' when targeting a CPU supporting the
!      architecture versions V8 or V9 with FPU except '-mcpu=leon'.
  
! '-mpopc'
! '-mno-popc'
!      With '-mpopc', GCC generates code that takes advantage of the
!      UltraSPARC Population Count instruction.  The default is '-mpopc'
       when targeting a CPU that supports such an instruction, such as
       Niagara-2 and later.
  
! '-msubxc'
! '-mno-subxc'
!      With '-msubxc', GCC generates code that takes advantage of the
       UltraSPARC Subtract-Extended-with-Carry instruction.  The default
!      is '-msubxc' when targeting a CPU that supports such an
       instruction, such as Niagara-7 and later.
  
! '-mfix-at697f'
       Enable the documented workaround for the single erratum of the
       Atmel AT697F processor (which corresponds to erratum #13 of the
       AT697E processor).
  
! '-mfix-ut699'
       Enable the documented workarounds for the floating-point errata and
       the data cache nullify errata of the UT699 processor.
  
! '-mfix-ut700'
       Enable the documented workaround for the back-to-back store errata
       of the UT699E/UT700 processor.
  
! '-mfix-gr712rc'
       Enable the documented workaround for the back-to-back store errata
       of the GR712RC processor.
  
!  These '-m' options are supported in addition to the above on SPARC-V9
  processors in 64-bit environments:
  
! '-m32'
! '-m64'
       Generate code for a 32-bit or 64-bit environment.  The 32-bit
       environment sets int, long and pointer to 32 bits.  The 64-bit
       environment sets int to 32 bits and long and pointer to 64 bits.
  
! '-mcmodel=WHICH'
       Set the code model to one of
  
!      'medlow'
            The Medium/Low code model: 64-bit addresses, programs must be
            linked in the low 32 bits of memory.  Programs can be
            statically or dynamically linked.
  
!      'medmid'
            The Medium/Middle code model: 64-bit addresses, programs must
            be linked in the low 44 bits of memory, the text and data
            segments must be less than 2GB in size and the data segment
            must be located within 2GB of the text segment.
  
!      'medany'
            The Medium/Anywhere code model: 64-bit addresses, programs may
            be linked anywhere in memory, the text and data segments must
            be less than 2GB in size and the data segment must be located
            within 2GB of the text segment.
  
!      'embmedany'
            The Medium/Anywhere code model for embedded systems: 64-bit
            addresses, the text and data segments must be less than 2GB in
            size, both starting anywhere in memory (determined at link
--- 28937,29130 ----
            niagara4, niagara7, m8
  
       By default (unless configured otherwise), GCC generates code for
!      the V7 variant of the SPARC architecture.  With ‘-mcpu=cypress’,
       the compiler additionally optimizes it for the Cypress CY7C602
       chip, as used in the SPARCStation/SPARCServer 3xx series.  This is
       also appropriate for the older SPARCStation 1, 2, IPX etc.
  
!      With ‘-mcpu=v8’, GCC generates code for the V8 variant of the SPARC
       architecture.  The only difference from V7 code is that the
       compiler emits the integer multiply and integer divide instructions
       which exist in SPARC-V8 but not in SPARC-V7.  With
!      ‘-mcpu=supersparc’, the compiler additionally optimizes it for the
       SuperSPARC chip, as used in the SPARCStation 10, 1000 and 2000
       series.
  
!      With ‘-mcpu=sparclite’, GCC generates code for the SPARClite
       variant of the SPARC architecture.  This adds the integer multiply,
!      integer divide step and scan (‘ffs’) instructions which exist in
!      SPARClite but not in SPARC-V7.  With ‘-mcpu=f930’, the compiler
       additionally optimizes it for the Fujitsu MB86930 chip, which is
!      the original SPARClite, with no FPU.  With ‘-mcpu=f934’, the
       compiler additionally optimizes it for the Fujitsu MB86934 chip,
       which is the more recent SPARClite with FPU.
  
!      With ‘-mcpu=sparclet’, GCC generates code for the SPARClet variant
       of the SPARC architecture.  This adds the integer multiply,
!      multiply/accumulate, integer divide step and scan (‘ffs’)
       instructions which exist in SPARClet but not in SPARC-V7.  With
!      ‘-mcpu=tsc701’, the compiler additionally optimizes it for the
       TEMIC SPARClet chip.
  
!      With ‘-mcpu=v9’, GCC generates code for the V9 variant of the SPARC
       architecture.  This adds 64-bit integer and floating-point move
       instructions, 3 additional floating-point condition code registers
!      and conditional move instructions.  With ‘-mcpu=ultrasparc’, the
       compiler additionally optimizes it for the Sun UltraSPARC I/II/IIi
!      chips.  With ‘-mcpu=ultrasparc3’, the compiler additionally
       optimizes it for the Sun UltraSPARC III/III+/IIIi/IIIi+/IV/IV+
!      chips.  With ‘-mcpu=niagara’, the compiler additionally optimizes
!      it for Sun UltraSPARC T1 chips.  With ‘-mcpu=niagara2’, the
       compiler additionally optimizes it for Sun UltraSPARC T2 chips.
!      With ‘-mcpu=niagara3’, the compiler additionally optimizes it for
!      Sun UltraSPARC T3 chips.  With ‘-mcpu=niagara4’, the compiler
       additionally optimizes it for Sun UltraSPARC T4 chips.  With
!      ‘-mcpu=niagara7’, the compiler additionally optimizes it for Oracle
!      SPARC M7 chips.  With ‘-mcpu=m8’, the compiler additionally
       optimizes it for Oracle M8 chips.
  
! ‘-mtune=CPU_TYPE’
       Set the instruction scheduling parameters for machine type
       CPU_TYPE, but do not set the instruction set or register set that
!      the option ‘-mcpu=CPU_TYPE’ does.
  
!      The same values for ‘-mcpu=CPU_TYPE’ can be used for
!      ‘-mtune=CPU_TYPE’, but the only useful values are those that select
!      a particular CPU implementation.  Those are ‘cypress’,
!      ‘supersparc’, ‘hypersparc’, ‘leon’, ‘leon3’, ‘leon3v7’, ‘leon5’,
!      ‘f930’, ‘f934’, ‘sparclite86x’, ‘tsc701’, ‘ultrasparc’,
!      ‘ultrasparc3’, ‘niagara’, ‘niagara2’, ‘niagara3’, ‘niagara4’,
!      ‘niagara7’ and ‘m8’.  With native Solaris and GNU/Linux toolchains,
!      ‘native’ can also be used.
  
! ‘-mv8plus’
! ‘-mno-v8plus’
!      With ‘-mv8plus’, GCC generates code for the SPARC-V8+ ABI.  The
       difference from the V8 ABI is that the global and out registers are
       considered 64 bits wide.  This is enabled by default on Solaris in
       32-bit mode for all SPARC-V9 processors.
  
! ‘-mvis’
! ‘-mno-vis’
!      With ‘-mvis’, GCC generates code that takes advantage of the
       UltraSPARC Visual Instruction Set extensions.  The default is
!      ‘-mno-vis’.
  
! ‘-mvis2’
! ‘-mno-vis2’
!      With ‘-mvis2’, GCC generates code that takes advantage of version
       2.0 of the UltraSPARC Visual Instruction Set extensions.  The
!      default is ‘-mvis2’ when targeting a cpu that supports such
!      instructions, such as UltraSPARC-III and later.  Setting ‘-mvis2’
!      also sets ‘-mvis’.
  
! ‘-mvis3’
! ‘-mno-vis3’
!      With ‘-mvis3’, GCC generates code that takes advantage of version
       3.0 of the UltraSPARC Visual Instruction Set extensions.  The
!      default is ‘-mvis3’ when targeting a cpu that supports such
!      instructions, such as niagara-3 and later.  Setting ‘-mvis3’ also
!      sets ‘-mvis2’ and ‘-mvis’.
  
! ‘-mvis4’
! ‘-mno-vis4’
!      With ‘-mvis4’, GCC generates code that takes advantage of version
       4.0 of the UltraSPARC Visual Instruction Set extensions.  The
!      default is ‘-mvis4’ when targeting a cpu that supports such
!      instructions, such as niagara-7 and later.  Setting ‘-mvis4’ also
!      sets ‘-mvis3’, ‘-mvis2’ and ‘-mvis’.
  
! ‘-mvis4b’
! ‘-mno-vis4b’
!      With ‘-mvis4b’, GCC generates code that takes advantage of version
       4.0 of the UltraSPARC Visual Instruction Set extensions, plus the
       additional VIS instructions introduced in the Oracle SPARC
!      Architecture 2017.  The default is ‘-mvis4b’ when targeting a cpu
       that supports such instructions, such as m8 and later.  Setting
!      ‘-mvis4b’ also sets ‘-mvis4’, ‘-mvis3’, ‘-mvis2’ and ‘-mvis’.
  
! ‘-mcbcond’
! ‘-mno-cbcond’
!      With ‘-mcbcond’, GCC generates code that takes advantage of the
       UltraSPARC Compare-and-Branch-on-Condition instructions.  The
!      default is ‘-mcbcond’ when targeting a CPU that supports such
       instructions, such as Niagara-4 and later.
  
! ‘-mfmaf’
! ‘-mno-fmaf’
!      With ‘-mfmaf’, GCC generates code that takes advantage of the
       UltraSPARC Fused Multiply-Add Floating-point instructions.  The
!      default is ‘-mfmaf’ when targeting a CPU that supports such
       instructions, such as Niagara-3 and later.
  
! ‘-mfsmuld’
! ‘-mno-fsmuld’
!      With ‘-mfsmuld’, GCC generates code that takes advantage of the
       Floating-point Multiply Single to Double (FsMULd) instruction.  The
!      default is ‘-mfsmuld’ when targeting a CPU supporting the
!      architecture versions V8 or V9 with FPU except ‘-mcpu=leon’.
  
! ‘-mpopc’
! ‘-mno-popc’
!      With ‘-mpopc’, GCC generates code that takes advantage of the
!      UltraSPARC Population Count instruction.  The default is ‘-mpopc’
       when targeting a CPU that supports such an instruction, such as
       Niagara-2 and later.
  
! ‘-msubxc’
! ‘-mno-subxc’
!      With ‘-msubxc’, GCC generates code that takes advantage of the
       UltraSPARC Subtract-Extended-with-Carry instruction.  The default
!      is ‘-msubxc’ when targeting a CPU that supports such an
       instruction, such as Niagara-7 and later.
  
! ‘-mfix-at697f’
       Enable the documented workaround for the single erratum of the
       Atmel AT697F processor (which corresponds to erratum #13 of the
       AT697E processor).
  
! ‘-mfix-ut699’
       Enable the documented workarounds for the floating-point errata and
       the data cache nullify errata of the UT699 processor.
  
! ‘-mfix-ut700’
       Enable the documented workaround for the back-to-back store errata
       of the UT699E/UT700 processor.
  
! ‘-mfix-gr712rc’
       Enable the documented workaround for the back-to-back store errata
       of the GR712RC processor.
  
!  These ‘-m’ options are supported in addition to the above on SPARC-V9
  processors in 64-bit environments:
  
! ‘-m32’
! ‘-m64’
       Generate code for a 32-bit or 64-bit environment.  The 32-bit
       environment sets int, long and pointer to 32 bits.  The 64-bit
       environment sets int to 32 bits and long and pointer to 64 bits.
  
! ‘-mcmodel=WHICH’
       Set the code model to one of
  
!      ‘medlow’
            The Medium/Low code model: 64-bit addresses, programs must be
            linked in the low 32 bits of memory.  Programs can be
            statically or dynamically linked.
  
!      ‘medmid’
            The Medium/Middle code model: 64-bit addresses, programs must
            be linked in the low 44 bits of memory, the text and data
            segments must be less than 2GB in size and the data segment
            must be located within 2GB of the text segment.
  
!      ‘medany’
            The Medium/Anywhere code model: 64-bit addresses, programs may
            be linked anywhere in memory, the text and data segments must
            be less than 2GB in size and the data segment must be located
            within 2GB of the text segment.
  
!      ‘embmedany’
            The Medium/Anywhere code model for embedded systems: 64-bit
            addresses, the text and data segments must be less than 2GB in
            size, both starting anywhere in memory (determined at link
*************** processors in 64-bit environments:
*** 29122,29154 ****
            segment.  Programs are statically linked and PIC is not
            supported.
  
! '-mmemory-model=MEM-MODEL'
       Set the memory model in force on the processor to one of
  
!      'default'
            The default memory model for the processor and operating
            system.
  
!      'rmo'
            Relaxed Memory Order
  
!      'pso'
            Partial Store Order
  
!      'tso'
            Total Store Order
  
!      'sc'
            Sequential Consistency
  
       These memory models are formally defined in Appendix D of the
!      SPARC-V9 architecture manual, as set in the processor's 'PSTATE.MM'
       field.
  
! '-mstack-bias'
! '-mno-stack-bias'
!      With '-mstack-bias', GCC assumes that the stack pointer, and frame
!      pointer if present, are offset by -2047 which must be added back
       when making stack frame references.  This is the default in 64-bit
       mode.  Otherwise, assume no such offset is present.
  
--- 29132,29164 ----
            segment.  Programs are statically linked and PIC is not
            supported.
  
! ‘-mmemory-model=MEM-MODEL’
       Set the memory model in force on the processor to one of
  
!      ‘default’
            The default memory model for the processor and operating
            system.
  
!      ‘rmo’
            Relaxed Memory Order
  
!      ‘pso’
            Partial Store Order
  
!      ‘tso’
            Total Store Order
  
!      ‘sc’
            Sequential Consistency
  
       These memory models are formally defined in Appendix D of the
!      SPARC-V9 architecture manual, as set in the processor's ‘PSTATE.MM’
       field.
  
! ‘-mstack-bias’
! ‘-mno-stack-bias’
!      With ‘-mstack-bias’, GCC assumes that the stack pointer, and frame
!      pointer if present, are offset by −2047 which must be added back
       when making stack frame references.  This is the default in 64-bit
       mode.  Otherwise, assume no such offset is present.
  
*************** File: gcc.info,  Node: System V Options,
*** 29161,29183 ****
  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.
  
--- 29171,29193 ----
  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,  Ne
*** 29187,29371 ****
  3.19.49 V850 Options
  --------------------
  
! These '-m' options are defined for V850 implementations:
  
! '-mlong-calls'
! '-mno-long-calls'
       Treat all calls as being far away (near).  If calls are assumed to
       be far away, the compiler always loads the function's address into
       a register, and calls indirect through the pointer.
  
! '-mno-ep'
! '-mep'
       Do not optimize (do optimize) basic blocks that use the same index
!      pointer 4 or more times to copy pointer into the 'ep' register, and
!      use the shorter 'sld' and 'sst' instructions.  The '-mep' option is
       on by default if you optimize.
  
! '-mno-prolog-function'
! '-mprolog-function'
       Do not use (do use) external functions to save and restore
       registers at the prologue and epilogue of a function.  The external
       functions are slower, but use less code space if more than one
       function saves the same number of registers.  The
!      '-mprolog-function' option is on by default if you optimize.
  
! '-mspace'
       Try to make the code as small as possible.  At present, this just
!      turns on the '-mep' and '-mprolog-function' options.
  
! '-mtda=N'
       Put static or global variables whose size is N bytes or less into
!      the tiny data area that register 'ep' points to.  The tiny data
       area can hold up to 256 bytes in total (128 bytes for byte
       references).
  
! '-msda=N'
       Put static or global variables whose size is N bytes or less into
!      the small data area that register 'gp' points to.  The small data
       area can hold up to 64 kilobytes.
  
! '-mzda=N'
       Put static or global variables whose size is N bytes or less into
       the first 32 kilobytes of memory.
  
! '-mv850'
       Specify that the target processor is the V850.
  
! '-mv850e3v5'
       Specify that the target processor is the V850E3V5.  The
!      preprocessor constant '__v850e3v5__' is defined if this option is
       used.
  
! '-mv850e2v4'
       Specify that the target processor is the V850E3V5.  This is an
!      alias for the '-mv850e3v5' option.
  
! '-mv850e2v3'
       Specify that the target processor is the V850E2V3.  The
!      preprocessor constant '__v850e2v3__' is defined if this option is
       used.
  
! '-mv850e2'
       Specify that the target processor is the V850E2.  The preprocessor
!      constant '__v850e2__' is defined if this option is used.
  
! '-mv850e1'
       Specify that the target processor is the V850E1.  The preprocessor
!      constants '__v850e1__' and '__v850e__' are defined if this option
       is used.
  
! '-mv850es'
       Specify that the target processor is the V850ES. This is an alias
!      for the '-mv850e1' option.
  
! '-mv850e'
       Specify that the target processor is the V850E.  The preprocessor
!      constant '__v850e__' is defined if this option is used.
  
!      If neither '-mv850' nor '-mv850e' nor '-mv850e1' nor '-mv850e2' nor
!      '-mv850e2v3' nor '-mv850e3v5' are defined then a default target
!      processor is chosen and the relevant '__v850*__' preprocessor
       constant is defined.
  
!      The preprocessor constants '__v850' and '__v851__' are always
       defined, regardless of which processor variant is the target.
  
! '-mdisable-callt'
! '-mno-disable-callt'
!      This option suppresses generation of the 'CALLT' instruction for
       the v850e, v850e1, v850e2, v850e2v3 and v850e3v5 flavors of the
       v850 architecture.
  
       This option is enabled by default when the RH850 ABI is in use (see
!      '-mrh850-abi'), and disabled by default when the GCC ABI is in use.
!      If 'CALLT' instructions are being generated then the C preprocessor
!      symbol '__V850_CALLT__' is defined.
  
! '-mrelax'
! '-mno-relax'
!      Pass on (or do not pass on) the '-mrelax' command-line option to
       the assembler.
  
! '-mlong-jumps'
! '-mno-long-jumps'
       Disable (or re-enable) the generation of PC-relative jump
       instructions.
  
! '-msoft-float'
! '-mhard-float'
       Disable (or re-enable) the generation of hardware floating point
       instructions.  This option is only significant when the target
!      architecture is 'V850E2V3' or higher.  If hardware floating point
       instructions are being generated then the C preprocessor symbol
!      '__FPU_OK__' is defined, otherwise the symbol '__NO_FPU__' is
       defined.
  
! '-mloop'
       Enables the use of the e3v5 LOOP instruction.  The use of this
       instruction is not enabled by default when the e3v5 architecture is
       selected because its use is still experimental.
  
! '-mrh850-abi'
! '-mghs'
       Enables support for the RH850 version of the V850 ABI. This is the
       default.  With this version of the ABI the following rules apply:
  
!         * Integer sized structures and unions are returned via a memory
            pointer rather than a register.
  
!         * Large structures and unions (more than 8 bytes in size) are
            passed by value.
  
!         * Functions are aligned to 16-bit boundaries.
  
!         * The '-m8byte-align' command-line option is supported.
  
!         * The '-mdisable-callt' command-line option is enabled by
!           default.  The '-mno-disable-callt' command-line option is not
            supported.
  
       When this version of the ABI is enabled the C preprocessor symbol
!      '__V850_RH850_ABI__' is defined.
  
! '-mgcc-abi'
       Enables support for the old GCC version of the V850 ABI. With this
       version of the ABI the following rules apply:
  
!         * Integer sized structures and unions are returned in register
!           'r10'.
  
!         * Large structures and unions (more than 8 bytes in size) are
            passed by reference.
  
!         * Functions are aligned to 32-bit boundaries, unless optimizing
            for size.
  
!         * The '-m8byte-align' command-line option is not supported.
  
!         * The '-mdisable-callt' command-line option is supported but not
            enabled by default.
  
       When this version of the ABI is enabled the C preprocessor symbol
!      '__V850_GCC_ABI__' is defined.
  
! '-m8byte-align'
! '-mno-8byte-align'
!      Enables support for 'double' and 'long long' types to be aligned on
       8-byte boundaries.  The default is to restrict the alignment of all
!      objects to at most 4-bytes.  When '-m8byte-align' is in effect the
!      C preprocessor symbol '__V850_8BYTE_ALIGN__' is defined.
  
! '-mbig-switch'
       Generate code suitable for big switch tables.  Use this option only
       if the assembler/linker complain about out of range branches within
       a switch table.
  
! '-mapp-regs'
       This option causes r2 and r5 to be used in the code generated by
       the compiler.  This setting is the default.
  
! '-mno-app-regs'
       This option causes r2 and r5 to be treated as fixed registers.
  
  
--- 29197,29381 ----
  3.19.49 V850 Options
  --------------------
  
! These ‘-m’ options are defined for V850 implementations:
  
! ‘-mlong-calls’
! ‘-mno-long-calls’
       Treat all calls as being far away (near).  If calls are assumed to
       be far away, the compiler always loads the function's address into
       a register, and calls indirect through the pointer.
  
! ‘-mno-ep’
! ‘-mep’
       Do not optimize (do optimize) basic blocks that use the same index
!      pointer 4 or more times to copy pointer into the ‘ep’ register, and
!      use the shorter ‘sld’ and ‘sst’ instructions.  The ‘-mep’ option is
       on by default if you optimize.
  
! ‘-mno-prolog-function’
! ‘-mprolog-function’
       Do not use (do use) external functions to save and restore
       registers at the prologue and epilogue of a function.  The external
       functions are slower, but use less code space if more than one
       function saves the same number of registers.  The
!      ‘-mprolog-function’ option is on by default if you optimize.
  
! ‘-mspace’
       Try to make the code as small as possible.  At present, this just
!      turns on the ‘-mep’ and ‘-mprolog-function’ options.
  
! ‘-mtda=N’
       Put static or global variables whose size is N bytes or less into
!      the tiny data area that register ‘ep’ points to.  The tiny data
       area can hold up to 256 bytes in total (128 bytes for byte
       references).
  
! ‘-msda=N’
       Put static or global variables whose size is N bytes or less into
!      the small data area that register ‘gp’ points to.  The small data
       area can hold up to 64 kilobytes.
  
! ‘-mzda=N’
       Put static or global variables whose size is N bytes or less into
       the first 32 kilobytes of memory.
  
! ‘-mv850’
       Specify that the target processor is the V850.
  
! ‘-mv850e3v5’
       Specify that the target processor is the V850E3V5.  The
!      preprocessor constant ‘__v850e3v5__’ is defined if this option is
       used.
  
! ‘-mv850e2v4’
       Specify that the target processor is the V850E3V5.  This is an
!      alias for the ‘-mv850e3v5’ option.
  
! ‘-mv850e2v3’
       Specify that the target processor is the V850E2V3.  The
!      preprocessor constant ‘__v850e2v3__’ is defined if this option is
       used.
  
! ‘-mv850e2’
       Specify that the target processor is the V850E2.  The preprocessor
!      constant ‘__v850e2__’ is defined if this option is used.
  
! ‘-mv850e1’
       Specify that the target processor is the V850E1.  The preprocessor
!      constants ‘__v850e1__’ and ‘__v850e__’ are defined if this option
       is used.
  
! ‘-mv850es’
       Specify that the target processor is the V850ES. This is an alias
!      for the ‘-mv850e1’ option.
  
! ‘-mv850e’
       Specify that the target processor is the V850E.  The preprocessor
!      constant ‘__v850e__’ is defined if this option is used.
  
!      If neither ‘-mv850’ nor ‘-mv850e’ nor ‘-mv850e1’ nor ‘-mv850e2’ nor
!      ‘-mv850e2v3’ nor ‘-mv850e3v5’ are defined then a default target
!      processor is chosen and the relevant ‘__v850*__’ preprocessor
       constant is defined.
  
!      The preprocessor constants ‘__v850’ and ‘__v851__’ are always
       defined, regardless of which processor variant is the target.
  
! ‘-mdisable-callt’
! ‘-mno-disable-callt’
!      This option suppresses generation of the ‘CALLT’ instruction for
       the v850e, v850e1, v850e2, v850e2v3 and v850e3v5 flavors of the
       v850 architecture.
  
       This option is enabled by default when the RH850 ABI is in use (see
!      ‘-mrh850-abi’), and disabled by default when the GCC ABI is in use.
!      If ‘CALLT’ instructions are being generated then the C preprocessor
!      symbol ‘__V850_CALLT__’ is defined.
  
! ‘-mrelax’
! ‘-mno-relax’
!      Pass on (or do not pass on) the ‘-mrelax’ command-line option to
       the assembler.
  
! ‘-mlong-jumps’
! ‘-mno-long-jumps’
       Disable (or re-enable) the generation of PC-relative jump
       instructions.
  
! ‘-msoft-float’
! ‘-mhard-float’
       Disable (or re-enable) the generation of hardware floating point
       instructions.  This option is only significant when the target
!      architecture is ‘V850E2V3’ or higher.  If hardware floating point
       instructions are being generated then the C preprocessor symbol
!      ‘__FPU_OK__’ is defined, otherwise the symbol ‘__NO_FPU__’ is
       defined.
  
! ‘-mloop’
       Enables the use of the e3v5 LOOP instruction.  The use of this
       instruction is not enabled by default when the e3v5 architecture is
       selected because its use is still experimental.
  
! ‘-mrh850-abi’
! ‘-mghs’
       Enables support for the RH850 version of the V850 ABI. This is the
       default.  With this version of the ABI the following rules apply:
  
!         • Integer sized structures and unions are returned via a memory
            pointer rather than a register.
  
!         • Large structures and unions (more than 8 bytes in size) are
            passed by value.
  
!         • Functions are aligned to 16-bit boundaries.
  
!         • The ‘-m8byte-align’ command-line option is supported.
  
!         • The ‘-mdisable-callt’ command-line option is enabled by
!           default.  The ‘-mno-disable-callt’ command-line option is not
            supported.
  
       When this version of the ABI is enabled the C preprocessor symbol
!      ‘__V850_RH850_ABI__’ is defined.
  
! ‘-mgcc-abi’
       Enables support for the old GCC version of the V850 ABI. With this
       version of the ABI the following rules apply:
  
!         • Integer sized structures and unions are returned in register
!           ‘r10’.
  
!         • Large structures and unions (more than 8 bytes in size) are
            passed by reference.
  
!         • Functions are aligned to 32-bit boundaries, unless optimizing
            for size.
  
!         • The ‘-m8byte-align’ command-line option is not supported.
  
!         • The ‘-mdisable-callt’ command-line option is supported but not
            enabled by default.
  
       When this version of the ABI is enabled the C preprocessor symbol
!      ‘__V850_GCC_ABI__’ is defined.
  
! ‘-m8byte-align’
! ‘-mno-8byte-align’
!      Enables support for ‘double’ and ‘long long’ types to be aligned on
       8-byte boundaries.  The default is to restrict the alignment of all
!      objects to at most 4-bytes.  When ‘-m8byte-align’ is in effect the
!      C preprocessor symbol ‘__V850_8BYTE_ALIGN__’ is defined.
  
! ‘-mbig-switch’
       Generate code suitable for big switch tables.  Use this option only
       if the assembler/linker complain about out of range branches within
       a switch table.
  
! ‘-mapp-regs’
       This option causes r2 and r5 to be used in the code generated by
       the compiler.  This setting is the default.
  
! ‘-mno-app-regs’
       This option causes r2 and r5 to be treated as fixed registers.
  
  
*************** File: gcc.info,  Node: VAX Options,  Nex
*** 29374,29395 ****
  3.19.50 VAX Options
  -------------------
  
! These '-m' options are defined for the VAX:
  
! '-munix'
!      Do not output certain jump instructions ('aobleq' and so on) that
       the Unix assembler for the VAX cannot handle across long ranges.
  
! '-mgnu'
       Do output those jump instructions, on the assumption that the GNU
       assembler is being used.
  
! '-mg'
       Output code for G-format floating-point numbers instead of
       D-format.
  
! '-mlra'
! '-mno-lra'
       Enable Local Register Allocation.  This is still experimental for
       the VAX, so by default the compiler uses standard reload.
  
--- 29384,29405 ----
  3.19.50 VAX Options
  -------------------
  
! These ‘-m’ options are defined for the VAX:
  
! ‘-munix’
!      Do not output certain jump instructions (‘aobleq’ and so on) that
       the Unix assembler for the VAX cannot handle across long ranges.
  
! ‘-mgnu’
       Do output those jump instructions, on the assumption that the GNU
       assembler is being used.
  
! ‘-mg’
       Output code for G-format floating-point numbers instead of
       D-format.
  
! ‘-mlra’
! ‘-mno-lra’
       Enable Local Register Allocation.  This is still experimental for
       the VAX, so by default the compiler uses standard reload.
  
*************** File: gcc.info,  Node: Visium Options,
*** 29399,29455 ****
  3.19.51 Visium Options
  ----------------------
  
! '-mdebug'
       A program which performs file I/O and is destined to run on an MCM
       target should be linked with this option.  It causes the libraries
       libc.a and libdebug.a to be linked.  The program should be run on
       the target under the control of the GDB remote debugging stub.
  
! '-msim'
       A program which performs file I/O and is destined to run on the
       simulator should be linked with option.  This causes libraries
       libc.a and libsim.a to be linked.
  
! '-mfpu'
! '-mhard-float'
       Generate code containing floating-point instructions.  This is the
       default.
  
! '-mno-fpu'
! '-msoft-float'
       Generate code containing library calls for floating-point.
  
!      '-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.
  
! '-mcpu=CPU_TYPE'
       Set the instruction set, register set, and instruction scheduling
       parameters for machine type CPU_TYPE.  Supported values for
!      CPU_TYPE are 'mcm', 'gr5' and 'gr6'.
  
!      'mcm' is a synonym of 'gr5' present for backward compatibility.
  
       By default (unless configured otherwise), GCC generates code for
       the GR5 variant of the Visium architecture.
  
!      With '-mcpu=gr6', GCC generates code for the GR6 variant of the
       Visium architecture.  The only difference from GR5 code is that the
       compiler will generate block move instructions.
  
! '-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.
  
! '-msv-mode'
       Generate code for the supervisor mode, where there are no
       restrictions on the access to general registers.  This is the
       default.
  
! '-muser-mode'
       Generate code for the user mode, where the access to some general
       registers is forbidden: on the GR5, registers r24 to r31 cannot be
       accessed in this mode; on the GR6, only registers r29 to r31 are
--- 29409,29465 ----
  3.19.51 Visium Options
  ----------------------
  
! ‘-mdebug’
       A program which performs file I/O and is destined to run on an MCM
       target should be linked with this option.  It causes the libraries
       libc.a and libdebug.a to be linked.  The program should be run on
       the target under the control of the GDB remote debugging stub.
  
! ‘-msim’
       A program which performs file I/O and is destined to run on the
       simulator should be linked with option.  This causes libraries
       libc.a and libsim.a to be linked.
  
! ‘-mfpu’
! ‘-mhard-float’
       Generate code containing floating-point instructions.  This is the
       default.
  
! ‘-mno-fpu’
! ‘-msoft-float’
       Generate code containing library calls for floating-point.
  
!      ‘-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.
  
! ‘-mcpu=CPU_TYPE’
       Set the instruction set, register set, and instruction scheduling
       parameters for machine type CPU_TYPE.  Supported values for
!      CPU_TYPE are ‘mcm’, ‘gr5’ and ‘gr6’.
  
!      ‘mcm’ is a synonym of ‘gr5’ present for backward compatibility.
  
       By default (unless configured otherwise), GCC generates code for
       the GR5 variant of the Visium architecture.
  
!      With ‘-mcpu=gr6’, GCC generates code for the GR6 variant of the
       Visium architecture.  The only difference from GR5 code is that the
       compiler will generate block move instructions.
  
! ‘-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.
  
! ‘-msv-mode’
       Generate code for the supervisor mode, where there are no
       restrictions on the access to general registers.  This is the
       default.
  
! ‘-muser-mode’
       Generate code for the user mode, where the access to some general
       registers is forbidden: on the GR5, registers r24 to r31 cannot be
       accessed in this mode; on the GR6, only registers r29 to r31 are
*************** File: gcc.info,  Node: VMS Options,  Nex
*** 29461,29484 ****
  3.19.52 VMS Options
  -------------------
  
! These '-m' options are defined for the VMS implementations:
  
! '-mvms-return-codes'
!      Return VMS condition codes from 'main'.  The default is to return
       POSIX-style condition (e.g. error) codes.
  
! '-mdebug-main=PREFIX'
       Flag the first routine whose name starts with PREFIX as the main
       routine for the debugger.
  
! '-mmalloc64'
       Default to 64-bit memory allocation routines.
  
! '-mpointer-size=SIZE'
       Set the default size of pointers.  Possible options for SIZE are
!      '32' or 'short' for 32 bit pointers, '64' or 'long' for 64 bit
!      pointers, and 'no' for supporting only 32 bit pointers.  The later
!      option disables 'pragma pointer_size'.
  
  
  File: gcc.info,  Node: VxWorks Options,  Next: x86 Options,  Prev: VMS Options,  Up: Submodel Options
--- 29471,29494 ----
  3.19.52 VMS Options
  -------------------
  
! These ‘-m’ options are defined for the VMS implementations:
  
! ‘-mvms-return-codes’
!      Return VMS condition codes from ‘main’.  The default is to return
       POSIX-style condition (e.g. error) codes.
  
! ‘-mdebug-main=PREFIX’
       Flag the first routine whose name starts with PREFIX as the main
       routine for the debugger.
  
! ‘-mmalloc64’
       Default to 64-bit memory allocation routines.
  
! ‘-mpointer-size=SIZE’
       Set the default size of pointers.  Possible options for SIZE are
!      ‘32’ or ‘short’ for 32 bit pointers, ‘64’ or ‘long’ for 64 bit
!      pointers, and ‘no’ for supporting only 32 bit pointers.  The later
!      option disables ‘pragma pointer_size’.
  
  
  File: gcc.info,  Node: VxWorks Options,  Next: x86 Options,  Prev: VMS Options,  Up: Submodel Options
*************** The options in this section are defined
*** 29490,29515 ****
  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.
  
--- 29500,29525 ----
  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 Options,  Nex
*** 29519,29551 ****
  3.19.54 x86 Options
  -------------------
  
! These '-m' options are defined for the x86 family of computers.
  
! '-march=CPU-TYPE'
       Generate instructions for the machine type CPU-TYPE.  In contrast
!      to '-mtune=CPU-TYPE', which merely tunes the generated code for the
!      specified CPU-TYPE, '-march=CPU-TYPE' allows GCC to generate code
       that may not run at all on processors other than the one indicated.
!      Specifying '-march=CPU-TYPE' implies '-mtune=CPU-TYPE', except
       where noted otherwise.
  
       The choices for CPU-TYPE are:
  
!      'native'
            This selects the CPU to generate code for at compilation time
            by determining the processor type of the compiling machine.
!           Using '-march=native' enables all instruction subsets
            supported by the local machine (hence the result might not run
!           on different machines).  Using '-mtune=native' produces code
            optimized for the local machine under the constraints of the
            selected instruction set.
  
!      'x86-64'
            A generic CPU with 64-bit extensions.
  
!      'x86-64-v2'
!      'x86-64-v3'
!      'x86-64-v4'
            These choices for CPU-TYPE select the corresponding
            micro-architecture level from the x86-64 psABI. On ABIs other
            than the x86-64 psABI they select the same CPU features as the
--- 29529,29561 ----
  3.19.54 x86 Options
  -------------------
  
! These ‘-m’ options are defined for the x86 family of computers.
  
! ‘-march=CPU-TYPE’
       Generate instructions for the machine type CPU-TYPE.  In contrast
!      to ‘-mtune=CPU-TYPE’, which merely tunes the generated code for the
!      specified CPU-TYPE, ‘-march=CPU-TYPE’ allows GCC to generate code
       that may not run at all on processors other than the one indicated.
!      Specifying ‘-march=CPU-TYPE’ implies ‘-mtune=CPU-TYPE’, except
       where noted otherwise.
  
       The choices for CPU-TYPE are:
  
!      ‘native’
            This selects the CPU to generate code for at compilation time
            by determining the processor type of the compiling machine.
!           Using ‘-march=native’ enables all instruction subsets
            supported by the local machine (hence the result might not run
!           on different machines).  Using ‘-mtune=native’ produces code
            optimized for the local machine under the constraints of the
            selected instruction set.
  
!      ‘x86-64’
            A generic CPU with 64-bit extensions.
  
!      ‘x86-64-v2’
!      ‘x86-64-v3’
!      ‘x86-64-v4’
            These choices for CPU-TYPE select the corresponding
            micro-architecture level from the x86-64 psABI. On ABIs other
            than the x86-64 psABI they select the same CPU features as the
*************** These '-m' options are defined for the x
*** 29553,29666 ****
            level.
  
            Since these CPU-TYPE values do not have a corresponding
!           '-mtune' setting, using '-march' with these values enables
            generic tuning.  Specific tuning can be enabled using the
!           '-mtune=OTHER-CPU-TYPE' option with an appropriate
            OTHER-CPU-TYPE value.
  
!      'i386'
            Original Intel i386 CPU.
  
!      'i486'
            Intel i486 CPU.  (No scheduling is implemented for this chip.)
  
!      'i586'
!      'pentium'
            Intel Pentium CPU with no MMX support.
  
!      'lakemont'
            Intel Lakemont MCU, based on Intel Pentium CPU.
  
!      'pentium-mmx'
            Intel Pentium MMX CPU, based on Pentium core with MMX
            instruction set support.
  
!      'pentiumpro'
            Intel Pentium Pro CPU.
  
!      'i686'
!           When used with '-march', the Pentium Pro instruction set is
            used, so the code runs on all i686 family chips.  When used
!           with '-mtune', it has the same meaning as 'generic'.
  
!      'pentium2'
            Intel Pentium II CPU, based on Pentium Pro core with MMX and
            FXSR instruction set support.
  
!      'pentium3'
!      'pentium3m'
            Intel Pentium III CPU, based on Pentium Pro core with MMX,
            FXSR and SSE instruction set support.
  
!      'pentium-m'
            Intel Pentium M; low-power version of Intel Pentium III CPU
            with MMX, SSE, SSE2 and FXSR instruction set support.  Used by
            Centrino notebooks.
  
!      'pentium4'
!      'pentium4m'
            Intel Pentium 4 CPU with MMX, SSE, SSE2 and FXSR instruction
            set support.
  
!      'prescott'
            Improved version of Intel Pentium 4 CPU with MMX, SSE, SSE2,
            SSE3 and FXSR instruction set support.
  
!      'nocona'
            Improved version of Intel Pentium 4 CPU with 64-bit
            extensions, MMX, SSE, SSE2, SSE3 and FXSR instruction set
            support.
  
!      'core2'
            Intel Core 2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
            SSSE3, CX16, SAHF and FXSR instruction set support.
  
!      'nehalem'
!      'corei7'
            Intel Nehalem CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF and FXSR
            instruction set support.
  
!      'westmere'
            Intel Westmere CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR and
            PCLMUL instruction set support.
  
!      'sandybridge'
!      'corei7-avx'
            Intel Sandy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE and PCLMUL instruction set support.
  
!      'ivybridge'
!      'core-avx-i'
            Intel Ivy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND and F16C instruction set
            support.
  
!      'haswell'
!      'core-avx2'
            Intel Haswell CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT,
            FMA, MOVBE and HLE instruction set support.
  
!      'broadwell'
            Intel Broadwell CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
            LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX and PREFETCHW instruction
            set support.
  
!      'skylake'
            Intel Skylake CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
            LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
            CLFLUSHOPT, XSAVEC, XSAVES and SGX instruction set support.
  
!      'skylake-avx512'
            Intel Skylake Server CPU with 64-bit extensions, MOVBE, MMX,
            SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF,
            FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI,
--- 29563,29676 ----
            level.
  
            Since these CPU-TYPE values do not have a corresponding
!           ‘-mtune’ setting, using ‘-march’ with these values enables
            generic tuning.  Specific tuning can be enabled using the
!           ‘-mtune=OTHER-CPU-TYPE’ option with an appropriate
            OTHER-CPU-TYPE value.
  
!      ‘i386’
            Original Intel i386 CPU.
  
!      ‘i486’
            Intel i486 CPU.  (No scheduling is implemented for this chip.)
  
!      ‘i586’
!      ‘pentium’
            Intel Pentium CPU with no MMX support.
  
!      ‘lakemont’
            Intel Lakemont MCU, based on Intel Pentium CPU.
  
!      ‘pentium-mmx’
            Intel Pentium MMX CPU, based on Pentium core with MMX
            instruction set support.
  
!      ‘pentiumpro’
            Intel Pentium Pro CPU.
  
!      ‘i686’
!           When used with ‘-march’, the Pentium Pro instruction set is
            used, so the code runs on all i686 family chips.  When used
!           with ‘-mtune’, it has the same meaning as ‘generic’.
  
!      ‘pentium2’
            Intel Pentium II CPU, based on Pentium Pro core with MMX and
            FXSR instruction set support.
  
!      ‘pentium3’
!      ‘pentium3m’
            Intel Pentium III CPU, based on Pentium Pro core with MMX,
            FXSR and SSE instruction set support.
  
!      ‘pentium-m’
            Intel Pentium M; low-power version of Intel Pentium III CPU
            with MMX, SSE, SSE2 and FXSR instruction set support.  Used by
            Centrino notebooks.
  
!      ‘pentium4’
!      ‘pentium4m’
            Intel Pentium 4 CPU with MMX, SSE, SSE2 and FXSR instruction
            set support.
  
!      ‘prescott’
            Improved version of Intel Pentium 4 CPU with MMX, SSE, SSE2,
            SSE3 and FXSR instruction set support.
  
!      ‘nocona’
            Improved version of Intel Pentium 4 CPU with 64-bit
            extensions, MMX, SSE, SSE2, SSE3 and FXSR instruction set
            support.
  
!      ‘core2’
            Intel Core 2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3,
            SSSE3, CX16, SAHF and FXSR instruction set support.
  
!      ‘nehalem’
!      ‘corei7’
            Intel Nehalem CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF and FXSR
            instruction set support.
  
!      ‘westmere’
            Intel Westmere CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR and
            PCLMUL instruction set support.
  
!      ‘sandybridge’
!      ‘corei7-avx’
            Intel Sandy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE and PCLMUL instruction set support.
  
!      ‘ivybridge’
!      ‘core-avx-i’
            Intel Ivy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND and F16C instruction set
            support.
  
!      ‘haswell’
!      ‘core-avx2’
            Intel Haswell CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT,
            FMA, MOVBE and HLE instruction set support.
  
!      ‘broadwell’
            Intel Broadwell CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
            LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX and PREFETCHW instruction
            set support.
  
!      ‘skylake’
            Intel Skylake CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
            LZCNT, FMA, MOVBE, HLE, RDSEED, ADCX, PREFETCHW, AES,
            CLFLUSHOPT, XSAVEC, XSAVES and SGX instruction set support.
  
!      ‘skylake-avx512’
            Intel Skylake Server CPU with 64-bit extensions, MOVBE, MMX,
            SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF,
            FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI,
*************** These '-m' options are defined for the x
*** 29668,29674 ****
            CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL,
            AVX512BW, AVX512DQ and AVX512CD instruction set support.
  
!      'cascadelake'
            Intel Cascade Lake CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT,
--- 29678,29684 ----
            CLFLUSHOPT, XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL,
            AVX512BW, AVX512DQ and AVX512CD instruction set support.
  
!      ‘cascadelake’
            Intel Cascade Lake CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT,
*************** These '-m' options are defined for the x
*** 29676,29682 ****
            XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW,
            AVX512DQ, AVX512CD and AVX512VNNI instruction set support.
  
!      'cannonlake'
            Intel Cannon Lake Server CPU with 64-bit extensions, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
--- 29686,29692 ----
            XSAVEC, XSAVES, SGX, AVX512F, CLWB, AVX512VL, AVX512BW,
            AVX512DQ, AVX512CD and AVX512VNNI instruction set support.
  
!      ‘cannonlake’
            Intel Cannon Lake Server CPU with 64-bit extensions, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
*************** These '-m' options are defined for the x
*** 29685,29691 ****
            AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA and SHA
            instruction set support.
  
!      'cooperlake'
            Intel Cooper Lake CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT,
--- 29695,29701 ----
            AVX512DQ, AVX512CD, PKU, AVX512VBMI, AVX512IFMA and SHA
            instruction set support.
  
!      ‘cooperlake’
            Intel Cooper Lake CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT,
*************** These '-m' options are defined for the x
*** 29694,29700 ****
            AVX512DQ, AVX512CD, AVX512VNNI and AVX512BF16 instruction set
            support.
  
!      'icelake-client'
            Intel Ice Lake Client CPU with 64-bit extensions, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
--- 29704,29710 ----
            AVX512DQ, AVX512CD, AVX512VNNI and AVX512BF16 instruction set
            support.
  
!      ‘icelake-client’
            Intel Ice Lake Client CPU with 64-bit extensions, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
*************** These '-m' options are defined for the x
*** 29705,29711 ****
            AVX512BITALG, RDPID and AVX512VPOPCNTDQ instruction set
            support.
  
!      'icelake-server'
            Intel Ice Lake Server CPU with 64-bit extensions, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
--- 29715,29721 ----
            AVX512BITALG, RDPID and AVX512VPOPCNTDQ instruction set
            support.
  
!      ‘icelake-server’
            Intel Ice Lake Server CPU with 64-bit extensions, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
*************** These '-m' options are defined for the x
*** 29716,29722 ****
            AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD and
            CLWB instruction set support.
  
!      'tigerlake'
            Intel Tiger Lake CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT,
--- 29726,29732 ----
            AVX512BITALG, RDPID, AVX512VPOPCNTDQ, PCONFIG, WBNOINVD and
            CLWB instruction set support.
  
!      ‘tigerlake’
            Intel Tiger Lake CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT,
*************** These '-m' options are defined for the x
*** 29727,29733 ****
            AVX512VPOPCNTDQ, MOVDIRI, MOVDIR64B, CLWB, AVX512VP2INTERSECT
            and KEYLOCKER instruction set support.
  
!      'rocketlake'
            Intel Rocket Lake CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT,
--- 29737,29743 ----
            AVX512VPOPCNTDQ, MOVDIRI, MOVDIR64B, CLWB, AVX512VP2INTERSECT
            and KEYLOCKER instruction set support.
  
!      ‘rocketlake’
            Intel Rocket Lake CPU with 64-bit extensions, MMX, SSE, SSE2,
            SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR, AVX,
            XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2, LZCNT,
*************** These '-m' options are defined for the x
*** 29737,29756 ****
            VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID and
            AVX512VPOPCNTDQ instruction set support.
  
!      'alderlake'
!      'raptorlake'
!      'meteorlake'
            Intel Alder Lake/Raptor Lake/Meteor Lake CPU with 64-bit
            extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
            SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC,
            XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE,
!           CLWB, MOVDIRI, MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2,
!           BMI, BMI2, F16C, FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ,
!           SERIALIZE, HRESET, KL, WIDEKL and AVX-VNNI instruction set
!           support.
  
!      'sapphirerapids'
!      'emeraldrapids'
            Intel Sapphire Rapids/Emerald Rapids CPU with 64-bit
            extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2,
            POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
--- 29747,29765 ----
            VAES, AVX512VBMI2, VPCLMULQDQ, AVX512BITALG, RDPID and
            AVX512VPOPCNTDQ instruction set support.
  
!      ‘alderlake’
!      ‘raptorlake’
!      ‘meteorlake’
            Intel Alder Lake/Raptor Lake/Meteor Lake CPU with 64-bit
            extensions, MOVBE, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1,
            SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC,
            XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE,
!           CLWB, MOVDIRI, MOVDIR64B, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2,
!           F16C, FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE,
!           HRESET, KL, WIDEKL and AVX-VNNI instruction set support.
  
!      ‘sapphirerapids’
!      ‘emeraldrapids’
            Intel Sapphire Rapids/Emerald Rapids CPU with 64-bit
            extensions, MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2,
            POPCNT, CX16, SAHF, FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND,
*************** These '-m' options are defined for the x
*** 29764,29770 ****
            AMX-INT8, AVX-VNNI, AVX512-FP16 and AVX512BF16 instruction set
            support.
  
!      'graniterapids'
            Intel Granite Rapids CPU with 64-bit extensions, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
--- 29773,29779 ----
            AMX-INT8, AVX-VNNI, AVX512-FP16 and AVX512BF16 instruction set
            support.
  
!      ‘graniterapids’
            Intel Granite Rapids CPU with 64-bit extensions, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
*************** These '-m' options are defined for the x
*** 29778,29784 ****
            AVX512-FP16, AVX512BF16, AMX-FP16 and PREFETCHI instruction
            set support.
  
!      'graniterapids-d'
            Intel Granite Rapids D CPU with 64-bit extensions, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
--- 29787,29793 ----
            AVX512-FP16, AVX512BF16, AMX-FP16 and PREFETCHI instruction
            set support.
  
!      ‘graniterapids-d’
            Intel Granite Rapids D CPU with 64-bit extensions, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI, BMI2,
*************** These '-m' options are defined for the x
*** 29792,29823 ****
            AVX512FP16, AVX512BF16, AMX-FP16, PREFETCHI and AMX-COMPLEX
            instruction set support.
  
!      'bonnell'
!      'atom'
            Intel Bonnell CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3 and SSSE3 instruction set support.
  
!      'silvermont'
!      'slm'
            Intel Silvermont CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            PCLMUL, PREFETCHW and RDRND instruction set support.
  
!      'goldmont'
            Intel Goldmont CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            PCLMUL, PREFETCHW, RDRND, AES, SHA, RDSEED, XSAVE, XSAVEC,
            XSAVES, XSAVEOPT, CLFLUSHOPT and FSGSBASE instruction set
            support.
  
!      'goldmont-plus'
            Intel Goldmont Plus CPU with 64-bit extensions, MOVBE, MMX,
            SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF,
            FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA, RDSEED, XSAVE,
            XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE, RDPID
            and SGX instruction set support.
  
!      'tremont'
            Intel Tremont CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            PCLMUL, PREFETCHW, RDRND, AES, SHA, RDSEED, XSAVE, XSAVEC,
--- 29801,29832 ----
            AVX512FP16, AVX512BF16, AMX-FP16, PREFETCHI and AMX-COMPLEX
            instruction set support.
  
!      ‘bonnell’
!      ‘atom’
            Intel Bonnell CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3 and SSSE3 instruction set support.
  
!      ‘silvermont’
!      ‘slm’
            Intel Silvermont CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            PCLMUL, PREFETCHW and RDRND instruction set support.
  
!      ‘goldmont’
            Intel Goldmont CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            PCLMUL, PREFETCHW, RDRND, AES, SHA, RDSEED, XSAVE, XSAVEC,
            XSAVES, XSAVEOPT, CLFLUSHOPT and FSGSBASE instruction set
            support.
  
!      ‘goldmont-plus’
            Intel Goldmont Plus CPU with 64-bit extensions, MOVBE, MMX,
            SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF,
            FXSR, PCLMUL, PREFETCHW, RDRND, AES, SHA, RDSEED, XSAVE,
            XSAVEC, XSAVES, XSAVEOPT, CLFLUSHOPT, FSGSBASE, PTWRITE, RDPID
            and SGX instruction set support.
  
!      ‘tremont’
            Intel Tremont CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF, FXSR,
            PCLMUL, PREFETCHW, RDRND, AES, SHA, RDSEED, XSAVE, XSAVEC,
*************** These '-m' options are defined for the x
*** 29825,29831 ****
            CLWB, GFNI-SSE, MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG
            instruction set support.
  
!      'sierraforest'
            Intel Sierra Forest CPU with 64-bit extensions, MOVBE, MMX,
            SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES,
            PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT,
--- 29834,29840 ----
            CLWB, GFNI-SSE, MOVDIRI, MOVDIR64B, CLDEMOTE and WAITPKG
            instruction set support.
  
!      ‘sierraforest’
            Intel Sierra Forest CPU with 64-bit extensions, MOVBE, MMX,
            SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES,
            PREFETCHW, PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT,
*************** These '-m' options are defined for the x
*** 29836,29842 ****
            AVXNECONVERT, CMPCCXADD, ENQCMD and UINTR instruction set
            support.
  
!      'grandridge'
            Intel Grand Ridge CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW,
            PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE,
--- 29845,29851 ----
            AVXNECONVERT, CMPCCXADD, ENQCMD and UINTR instruction set
            support.
  
!      ‘grandridge’
            Intel Grand Ridge CPU with 64-bit extensions, MOVBE, MMX, SSE,
            SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW,
            PCLMUL, RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE,
*************** These '-m' options are defined for the x
*** 29846,29852 ****
            WIDEKL, AVX-VNNI, AVXIFMA, AVXVNNIINT8, AVXNECONVERT,
            CMPCCXADD, ENQCMD and UINTR instruction set support.
  
!      'knl'
            Intel Knights Landing CPU with 64-bit extensions, MOVBE, MMX,
            SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF,
            FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI,
--- 29855,29861 ----
            WIDEKL, AVX-VNNI, AVXIFMA, AVXVNNIINT8, AVXNECONVERT,
            CMPCCXADD, ENQCMD and UINTR instruction set support.
  
!      ‘knl’
            Intel Knights Landing CPU with 64-bit extensions, MOVBE, MMX,
            SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF,
            FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI,
*************** These '-m' options are defined for the x
*** 29854,29860 ****
            AVX512PF, AVX512ER, AVX512F, AVX512CD and PREFETCHWT1
            instruction set support.
  
!      'knm'
            Intel Knights Mill CPU with 64-bit extensions, MOVBE, MMX,
            SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF,
            FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI,
--- 29863,29869 ----
            AVX512PF, AVX512ER, AVX512F, AVX512CD and PREFETCHWT1
            instruction set support.
  
!      ‘knm’
            Intel Knights Mill CPU with 64-bit extensions, MOVBE, MMX,
            SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, CX16, SAHF,
            FXSR, AVX, XSAVE, PCLMUL, FSGSBASE, RDRND, F16C, AVX2, BMI,
*************** These '-m' options are defined for the x
*** 29863,29935 ****
            AVX5124VNNIW, AVX5124FMAPS and AVX512VPOPCNTDQ instruction set
            support.
  
!      'k6'
            AMD K6 CPU with MMX instruction set support.
  
!      'k6-2'
!      'k6-3'
            Improved versions of AMD K6 CPU with MMX and 3DNow!
            instruction set support.
  
!      'athlon'
!      'athlon-tbird'
            AMD Athlon CPU with MMX, 3dNOW!, enhanced 3DNow! and SSE
            prefetch instructions support.
  
!      'athlon-4'
!      'athlon-xp'
!      'athlon-mp'
            Improved AMD Athlon CPU with MMX, 3DNow!, enhanced 3DNow! and
            full SSE instruction set support.
  
!      'k8'
!      'opteron'
!      'athlon64'
!      'athlon-fx'
            Processors based on the AMD K8 core with x86-64 instruction
            set support, including the AMD Opteron, Athlon 64, and Athlon
            64 FX processors.  (This supersets MMX, SSE, SSE2, 3DNow!,
            enhanced 3DNow! and 64-bit instruction set extensions.)
  
!      'k8-sse3'
!      'opteron-sse3'
!      'athlon64-sse3'
            Improved versions of AMD K8 cores with SSE3 instruction set
            support.
  
!      'amdfam10'
!      'barcelona'
            CPUs based on AMD Family 10h cores with x86-64 instruction set
            support.  (This supersets MMX, SSE, SSE2, SSE3, SSE4A, 3DNow!,
            enhanced 3DNow!, ABM and 64-bit instruction set extensions.)
  
!      'bdver1'
            CPUs based on AMD Family 15h cores with x86-64 instruction set
            support.  (This supersets FMA4, AVX, XOP, LWP, AES, PCLMUL,
            CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM
            and 64-bit instruction set extensions.)
  
!      'bdver2'
            AMD Family 15h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, TBM, F16C, FMA, FMA4, AVX, XOP,
            LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3,
            SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.)
  
!      'bdver3'
            AMD Family 15h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, TBM, F16C, FMA, FMA4, FSGSBASE,
            AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A,
            SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set
            extensions.)
  
!      'bdver4'
            AMD Family 15h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, TBM, F16C, FMA, FMA4,
            FSGSBASE, AVX, AVX2, XOP, LWP, AES, PCLMUL, CX16, MOVBE, MMX,
            SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit
            instruction set extensions.)
  
!      'znver1'
            AMD Family 17h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, F16C, FMA, FSGSBASE, AVX,
            AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES, PCLMUL, CX16,
--- 29872,29944 ----
            AVX5124VNNIW, AVX5124FMAPS and AVX512VPOPCNTDQ instruction set
            support.
  
!      ‘k6’
            AMD K6 CPU with MMX instruction set support.
  
!      ‘k6-2’
!      ‘k6-3’
            Improved versions of AMD K6 CPU with MMX and 3DNow!
            instruction set support.
  
!      ‘athlon’
!      ‘athlon-tbird’
            AMD Athlon CPU with MMX, 3dNOW!, enhanced 3DNow! and SSE
            prefetch instructions support.
  
!      ‘athlon-4’
!      ‘athlon-xp’
!      ‘athlon-mp’
            Improved AMD Athlon CPU with MMX, 3DNow!, enhanced 3DNow! and
            full SSE instruction set support.
  
!      ‘k8’
!      ‘opteron’
!      ‘athlon64’
!      ‘athlon-fx’
            Processors based on the AMD K8 core with x86-64 instruction
            set support, including the AMD Opteron, Athlon 64, and Athlon
            64 FX processors.  (This supersets MMX, SSE, SSE2, 3DNow!,
            enhanced 3DNow! and 64-bit instruction set extensions.)
  
!      ‘k8-sse3’
!      ‘opteron-sse3’
!      ‘athlon64-sse3’
            Improved versions of AMD K8 cores with SSE3 instruction set
            support.
  
!      ‘amdfam10’
!      ‘barcelona’
            CPUs based on AMD Family 10h cores with x86-64 instruction set
            support.  (This supersets MMX, SSE, SSE2, SSE3, SSE4A, 3DNow!,
            enhanced 3DNow!, ABM and 64-bit instruction set extensions.)
  
!      ‘bdver1’
            CPUs based on AMD Family 15h cores with x86-64 instruction set
            support.  (This supersets FMA4, AVX, XOP, LWP, AES, PCLMUL,
            CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM
            and 64-bit instruction set extensions.)
  
!      ‘bdver2’
            AMD Family 15h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, TBM, F16C, FMA, FMA4, AVX, XOP,
            LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3,
            SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.)
  
!      ‘bdver3’
            AMD Family 15h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, TBM, F16C, FMA, FMA4, FSGSBASE,
            AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A,
            SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set
            extensions.)
  
!      ‘bdver4’
            AMD Family 15h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, TBM, F16C, FMA, FMA4,
            FSGSBASE, AVX, AVX2, XOP, LWP, AES, PCLMUL, CX16, MOVBE, MMX,
            SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit
            instruction set extensions.)
  
!      ‘znver1’
            AMD Family 17h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, F16C, FMA, FSGSBASE, AVX,
            AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES, PCLMUL, CX16,
*************** These '-m' options are defined for the x
*** 29937,29943 ****
            ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, and 64-bit
            instruction set extensions.)
  
!      'znver2'
            AMD Family 17h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, CLWB, F16C, FMA,
            FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES,
--- 29946,29952 ----
            ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, and 64-bit
            instruction set extensions.)
  
!      ‘znver2’
            AMD Family 17h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, CLWB, F16C, FMA,
            FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES,
*************** These '-m' options are defined for the x
*** 29945,29951 ****
            SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT,
            RDPID, WBNOINVD, and 64-bit instruction set extensions.)
  
!      'znver3'
            AMD Family 19h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, CLWB, F16C, FMA,
            FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES,
--- 29954,29960 ----
            SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT,
            RDPID, WBNOINVD, and 64-bit instruction set extensions.)
  
!      ‘znver3’
            AMD Family 19h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, CLWB, F16C, FMA,
            FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES,
*************** These '-m' options are defined for the x
*** 29954,29960 ****
            RDPID, WBNOINVD, PKU, VPCLMULQDQ, VAES, and 64-bit instruction
            set extensions.)
  
!      'znver4'
            AMD Family 19h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, CLWB, F16C, FMA,
            FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES,
--- 29963,29969 ----
            RDPID, WBNOINVD, PKU, VPCLMULQDQ, VAES, and 64-bit instruction
            set extensions.)
  
!      ‘znver4’
            AMD Family 19h core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, CLWB, F16C, FMA,
            FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES,
*************** These '-m' options are defined for the x
*** 29965,29971 ****
            AVX512VBMI, AVX512VBMI2, AVX512VNNI, AVX512BITALG,
            AVX512VPOPCNTDQ, GFNI and 64-bit instruction set extensions.)
  
!      'znver5'
            AMD Family 1ah core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, CLWB, F16C, FMA,
            FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES,
--- 29974,29980 ----
            AVX512VBMI, AVX512VBMI2, AVX512VNNI, AVX512BITALG,
            AVX512VPOPCNTDQ, GFNI and 64-bit instruction set extensions.)
  
!      ‘znver5’
            AMD Family 1ah core based CPUs with x86-64 instruction set
            support.  (This supersets BMI, BMI2, CLWB, F16C, FMA,
            FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES,
*************** These '-m' options are defined for the x
*** 29978,30096 ****
            AVX512VP2INTERSECT, PREFETCHI and 64-bit instruction set
            extensions.)
  
!      'btver1'
            CPUs based on AMD Family 14h cores with x86-64 instruction set
            support.  (This supersets MMX, SSE, SSE2, SSE3, SSSE3, SSE4A,
            CX16, ABM and 64-bit instruction set extensions.)
  
!      'btver2'
            CPUs based on AMD Family 16h cores with x86-64 instruction set
            support.  This includes MOVBE, F16C, BMI, AVX, PCLMUL, AES,
            SSE4.2, SSE4.1, CX16, ABM, SSE4A, SSSE3, SSE3, SSE2, SSE, MMX
            and 64-bit instruction set extensions.
  
!      'winchip-c6'
            IDT WinChip C6 CPU, dealt in same way as i486 with additional
            MMX instruction set support.
  
!      'winchip2'
            IDT WinChip 2 CPU, dealt in same way as i486 with additional
            MMX and 3DNow! instruction set support.
  
!      'c3'
            VIA C3 CPU with MMX and 3DNow! instruction set support.  (No
            scheduling is implemented for this chip.)
  
!      'c3-2'
            VIA C3-2 (Nehemiah/C5XL) CPU with MMX and SSE instruction set
            support.  (No scheduling is implemented for this chip.)
  
!      'c7'
            VIA C7 (Esther) CPU with MMX, SSE, SSE2 and SSE3 instruction
            set support.  (No scheduling is implemented for this chip.)
  
!      'samuel-2'
            VIA Eden Samuel 2 CPU with MMX and 3DNow! instruction set
            support.  (No scheduling is implemented for this chip.)
  
!      'nehemiah'
            VIA Eden Nehemiah CPU with MMX and SSE instruction set
            support.  (No scheduling is implemented for this chip.)
  
!      'esther'
            VIA Eden Esther CPU with MMX, SSE, SSE2 and SSE3 instruction
            set support.  (No scheduling is implemented for this chip.)
  
!      'eden-x2'
            VIA Eden X2 CPU with x86-64, MMX, SSE, SSE2 and SSE3
            instruction set support.  (No scheduling is implemented for
            this chip.)
  
!      'eden-x4'
            VIA Eden X4 CPU with x86-64, MMX, SSE, SSE2, SSE3, SSSE3,
            SSE4.1, SSE4.2, AVX and AVX2 instruction set support.  (No
            scheduling is implemented for this chip.)
  
!      'nano'
            Generic VIA Nano CPU with x86-64, MMX, SSE, SSE2, SSE3 and
            SSSE3 instruction set support.  (No scheduling is implemented
            for this chip.)
  
!      'nano-1000'
            VIA Nano 1xxx CPU with x86-64, MMX, SSE, SSE2, SSE3 and SSSE3
            instruction set support.  (No scheduling is implemented for
            this chip.)
  
!      'nano-2000'
            VIA Nano 2xxx CPU with x86-64, MMX, SSE, SSE2, SSE3 and SSSE3
            instruction set support.  (No scheduling is implemented for
            this chip.)
  
!      'nano-3000'
            VIA Nano 3xxx CPU with x86-64, MMX, SSE, SSE2, SSE3, SSSE3 and
            SSE4.1 instruction set support.  (No scheduling is implemented
            for this chip.)
  
!      'nano-x2'
            VIA Nano Dual Core CPU with x86-64, MMX, SSE, SSE2, SSE3,
            SSSE3 and SSE4.1 instruction set support.  (No scheduling is
            implemented for this chip.)
  
!      'nano-x4'
            VIA Nano Quad Core CPU with x86-64, MMX, SSE, SSE2, SSE3,
            SSSE3 and SSE4.1 instruction set support.  (No scheduling is
            implemented for this chip.)
  
!      'lujiazui'
            ZHAOXIN lujiazui CPU with x86-64, MOVBE, MMX, SSE, SSE2, SSE3,
            SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE,
            XSAVEOPT, FSGSBASE, CX16, ABM, BMI, BMI2, FXSR, RDSEED
            instruction set support.  While the CPUs do support AVX and
!           F16C, these aren't enabled by '-march=lujiazui' for
            performance reasons.
  
!      'geode'
            AMD Geode embedded processor with MMX and 3DNow! instruction
            set support.
  
! '-mtune=CPU-TYPE'
       Tune to CPU-TYPE everything applicable about the generated code,
       except for the ABI and the set of available instructions.  While
       picking a specific CPU-TYPE schedules things appropriately for that
       particular chip, the compiler does not generate any code that
       cannot run on the default machine type unless you use a
!      '-march=CPU-TYPE' option.  For example, if GCC is configured for
!      i686-pc-linux-gnu then '-mtune=pentium4' generates code that is
       tuned for Pentium 4 but still runs on i686 machines.
  
!      The choices for CPU-TYPE are the same as for '-march'.  In
!      addition, '-mtune' supports 2 extra choices for CPU-TYPE:
  
!      'generic'
            Produce code optimized for the most common IA32/AMD64/EM64T
            processors.  If you know the CPU on which your code will run,
!           then you should use the corresponding '-mtune' or '-march'
!           option instead of '-mtune=generic'.  But, if you do not know
            exactly what CPU users of your application will have, then you
            should use this option.
  
--- 29987,30105 ----
            AVX512VP2INTERSECT, PREFETCHI and 64-bit instruction set
            extensions.)
  
!      ‘btver1’
            CPUs based on AMD Family 14h cores with x86-64 instruction set
            support.  (This supersets MMX, SSE, SSE2, SSE3, SSSE3, SSE4A,
            CX16, ABM and 64-bit instruction set extensions.)
  
!      ‘btver2’
            CPUs based on AMD Family 16h cores with x86-64 instruction set
            support.  This includes MOVBE, F16C, BMI, AVX, PCLMUL, AES,
            SSE4.2, SSE4.1, CX16, ABM, SSE4A, SSSE3, SSE3, SSE2, SSE, MMX
            and 64-bit instruction set extensions.
  
!      ‘winchip-c6’
            IDT WinChip C6 CPU, dealt in same way as i486 with additional
            MMX instruction set support.
  
!      ‘winchip2’
            IDT WinChip 2 CPU, dealt in same way as i486 with additional
            MMX and 3DNow! instruction set support.
  
!      ‘c3’
            VIA C3 CPU with MMX and 3DNow! instruction set support.  (No
            scheduling is implemented for this chip.)
  
!      ‘c3-2’
            VIA C3-2 (Nehemiah/C5XL) CPU with MMX and SSE instruction set
            support.  (No scheduling is implemented for this chip.)
  
!      ‘c7’
            VIA C7 (Esther) CPU with MMX, SSE, SSE2 and SSE3 instruction
            set support.  (No scheduling is implemented for this chip.)
  
!      ‘samuel-2’
            VIA Eden Samuel 2 CPU with MMX and 3DNow! instruction set
            support.  (No scheduling is implemented for this chip.)
  
!      ‘nehemiah’
            VIA Eden Nehemiah CPU with MMX and SSE instruction set
            support.  (No scheduling is implemented for this chip.)
  
!      ‘esther’
            VIA Eden Esther CPU with MMX, SSE, SSE2 and SSE3 instruction
            set support.  (No scheduling is implemented for this chip.)
  
!      ‘eden-x2’
            VIA Eden X2 CPU with x86-64, MMX, SSE, SSE2 and SSE3
            instruction set support.  (No scheduling is implemented for
            this chip.)
  
!      ‘eden-x4’
            VIA Eden X4 CPU with x86-64, MMX, SSE, SSE2, SSE3, SSSE3,
            SSE4.1, SSE4.2, AVX and AVX2 instruction set support.  (No
            scheduling is implemented for this chip.)
  
!      ‘nano’
            Generic VIA Nano CPU with x86-64, MMX, SSE, SSE2, SSE3 and
            SSSE3 instruction set support.  (No scheduling is implemented
            for this chip.)
  
!      ‘nano-1000’
            VIA Nano 1xxx CPU with x86-64, MMX, SSE, SSE2, SSE3 and SSSE3
            instruction set support.  (No scheduling is implemented for
            this chip.)
  
!      ‘nano-2000’
            VIA Nano 2xxx CPU with x86-64, MMX, SSE, SSE2, SSE3 and SSSE3
            instruction set support.  (No scheduling is implemented for
            this chip.)
  
!      ‘nano-3000’
            VIA Nano 3xxx CPU with x86-64, MMX, SSE, SSE2, SSE3, SSSE3 and
            SSE4.1 instruction set support.  (No scheduling is implemented
            for this chip.)
  
!      ‘nano-x2’
            VIA Nano Dual Core CPU with x86-64, MMX, SSE, SSE2, SSE3,
            SSSE3 and SSE4.1 instruction set support.  (No scheduling is
            implemented for this chip.)
  
!      ‘nano-x4’
            VIA Nano Quad Core CPU with x86-64, MMX, SSE, SSE2, SSE3,
            SSSE3 and SSE4.1 instruction set support.  (No scheduling is
            implemented for this chip.)
  
!      ‘lujiazui’
            ZHAOXIN lujiazui CPU with x86-64, MOVBE, MMX, SSE, SSE2, SSE3,
            SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PCLMUL, RDRND, XSAVE,
            XSAVEOPT, FSGSBASE, CX16, ABM, BMI, BMI2, FXSR, RDSEED
            instruction set support.  While the CPUs do support AVX and
!           F16C, these aren't enabled by ‘-march=lujiazui’ for
            performance reasons.
  
!      ‘geode’
            AMD Geode embedded processor with MMX and 3DNow! instruction
            set support.
  
! ‘-mtune=CPU-TYPE’
       Tune to CPU-TYPE everything applicable about the generated code,
       except for the ABI and the set of available instructions.  While
       picking a specific CPU-TYPE schedules things appropriately for that
       particular chip, the compiler does not generate any code that
       cannot run on the default machine type unless you use a
!      ‘-march=CPU-TYPE’ option.  For example, if GCC is configured for
!      i686-pc-linux-gnu then ‘-mtune=pentium4’ generates code that is
       tuned for Pentium 4 but still runs on i686 machines.
  
!      The choices for CPU-TYPE are the same as for ‘-march’.  In
!      addition, ‘-mtune’ supports 2 extra choices for CPU-TYPE:
  
!      ‘generic’
            Produce code optimized for the most common IA32/AMD64/EM64T
            processors.  If you know the CPU on which your code will run,
!           then you should use the corresponding ‘-mtune’ or ‘-march’
!           option instead of ‘-mtune=generic’.  But, if you do not know
            exactly what CPU users of your application will have, then you
            should use this option.
  
*************** These '-m' options are defined for the x
*** 30100,30117 ****
            by this option will change to reflect the processors that are
            most common at the time that version of GCC is released.
  
!           There is no '-march=generic' option because '-march' indicates
            the instruction set the compiler can use, and there is no
            generic instruction set applicable to all processors.  In
!           contrast, '-mtune' indicates the processor (or, in this case,
            collection of processors) for which the code is optimized.
  
!      'intel'
            Produce code optimized for the most current Intel processors,
            which are Haswell and Silvermont for this version of GCC. If
            you know the CPU on which your code will run, then you should
!           use the corresponding '-mtune' or '-march' option instead of
!           '-mtune=intel'.  But, if you want your application performs
            better on both Haswell and Silvermont, then you should use
            this option.
  
--- 30109,30126 ----
            by this option will change to reflect the processors that are
            most common at the time that version of GCC is released.
  
!           There is no ‘-march=generic’ option because ‘-march’ indicates
            the instruction set the compiler can use, and there is no
            generic instruction set applicable to all processors.  In
!           contrast, ‘-mtune’ indicates the processor (or, in this case,
            collection of processors) for which the code is optimized.
  
!      ‘intel’
            Produce code optimized for the most current Intel processors,
            which are Haswell and Silvermont for this version of GCC. If
            you know the CPU on which your code will run, then you should
!           use the corresponding ‘-mtune’ or ‘-march’ option instead of
!           ‘-mtune=intel’.  But, if you want your application performs
            better on both Haswell and Silvermont, then you should use
            this option.
  
*************** These '-m' options are defined for the x
*** 30121,30151 ****
            by this option will change to reflect the most current Intel
            processors at the time that version of GCC is released.
  
!           There is no '-march=intel' option because '-march' indicates
            the instruction set the compiler can use, and there is no
            common instruction set applicable to all processors.  In
!           contrast, '-mtune' indicates the processor (or, in this case,
            collection of processors) for which the code is optimized.
  
! '-mcpu=CPU-TYPE'
!      A deprecated synonym for '-mtune'.
  
! '-mfpmath=UNIT'
       Generate floating-point arithmetic for selected unit UNIT.  The
       choices for UNIT are:
  
!      '387'
            Use the standard 387 floating-point coprocessor present on the
            majority of chips and emulated otherwise.  Code compiled with
            this option runs almost everywhere.  The temporary results are
            computed in 80-bit precision instead of the precision
            specified by the type, resulting in slightly different results
!           compared to most of other chips.  See '-ffloat-store' for more
            detailed description.
  
            This is the default choice for non-Darwin x86-32 targets.
  
!      'sse'
            Use scalar floating-point instructions present in the SSE
            instruction set.  This instruction set is supported by Pentium
            III and newer chips, and in the AMD line by Athlon-4, Athlon
--- 30130,30160 ----
            by this option will change to reflect the most current Intel
            processors at the time that version of GCC is released.
  
!           There is no ‘-march=intel’ option because ‘-march’ indicates
            the instruction set the compiler can use, and there is no
            common instruction set applicable to all processors.  In
!           contrast, ‘-mtune’ indicates the processor (or, in this case,
            collection of processors) for which the code is optimized.
  
! ‘-mcpu=CPU-TYPE’
!      A deprecated synonym for ‘-mtune’.
  
! ‘-mfpmath=UNIT’
       Generate floating-point arithmetic for selected unit UNIT.  The
       choices for UNIT are:
  
!      ‘387’
            Use the standard 387 floating-point coprocessor present on the
            majority of chips and emulated otherwise.  Code compiled with
            this option runs almost everywhere.  The temporary results are
            computed in 80-bit precision instead of the precision
            specified by the type, resulting in slightly different results
!           compared to most of other chips.  See ‘-ffloat-store’ for more
            detailed description.
  
            This is the default choice for non-Darwin x86-32 targets.
  
!      ‘sse’
            Use scalar floating-point instructions present in the SSE
            instruction set.  This instruction set is supported by Pentium
            III and newer chips, and in the AMD line by Athlon-4, Athlon
*************** These '-m' options are defined for the x
*** 30156,30163 ****
            and AMD x86-64 chips, supports double-precision arithmetic
            too.
  
!           For the x86-32 compiler, you must use '-march=CPU-TYPE',
!           '-msse' or '-msse2' switches to enable SSE extensions and make
            this option effective.  For the x86-64 compiler, these
            extensions are enabled by default.
  
--- 30165,30172 ----
            and AMD x86-64 chips, supports double-precision arithmetic
            too.
  
!           For the x86-32 compiler, you must use ‘-march=CPU-TYPE’,
!           ‘-msse’ or ‘-msse2’ switches to enable SSE extensions and make
            this option effective.  For the x86-64 compiler, these
            extensions are enabled by default.
  
*************** These '-m' options are defined for the x
*** 30168,30178 ****
  
            This is the default choice for the x86-64 compiler, Darwin
            x86-32 targets, and the default choice for x86-32 targets with
!           the SSE2 instruction set when '-ffast-math' is enabled.
  
!      'sse,387'
!      'sse+387'
!      'both'
            Attempt to utilize both instruction sets at once.  This
            effectively doubles the amount of available registers, and on
            chips with separate execution units for 387 and SSE the
--- 30177,30187 ----
  
            This is the default choice for the x86-64 compiler, Darwin
            x86-32 targets, and the default choice for x86-32 targets with
!           the SSE2 instruction set when ‘-ffast-math’ is enabled.
  
!      ‘sse,387’
!      ‘sse+387’
!      ‘both’
            Attempt to utilize both instruction sets at once.  This
            effectively doubles the amount of available registers, and on
            chips with separate execution units for 387 and SSE the
*************** These '-m' options are defined for the x
*** 30181,30205 ****
            not model separate functional units well, resulting in
            unstable performance.
  
! '-masm=DIALECT'
       Output assembly instructions using selected DIALECT.  Also affects
!      which dialect is used for basic 'asm' (*note Basic Asm::) and
!      extended 'asm' (*note Extended Asm::).  Supported choices (in
!      dialect order) are 'att' or 'intel'.  The default is 'att'.  Darwin
!      does not support 'intel'.
  
! '-mieee-fp'
! '-mno-ieee-fp'
       Control whether or not the compiler uses IEEE floating-point
       comparisons.  These correctly handle the case where the result of a
       comparison is unordered.
  
! '-m80387'
! '-mhard-float'
       Generate output containing 80387 instructions for floating point.
  
! '-mno-80387'
! '-msoft-float'
       Generate output containing library calls for floating point.
  
       *Warning:* the requisite libraries are not part of GCC.  Normally
--- 30190,30214 ----
            not model separate functional units well, resulting in
            unstable performance.
  
! ‘-masm=DIALECT’
       Output assembly instructions using selected DIALECT.  Also affects
!      which dialect is used for basic ‘asm’ (*note Basic Asm::) and
!      extended ‘asm’ (*note Extended Asm::).  Supported choices (in
!      dialect order) are ‘att’ or ‘intel’.  The default is ‘att’.  Darwin
!      does not support ‘intel’.
  
! ‘-mieee-fp’
! ‘-mno-ieee-fp’
       Control whether or not the compiler uses IEEE floating-point
       comparisons.  These correctly handle the case where the result of a
       comparison is unordered.
  
! ‘-m80387’
! ‘-mhard-float’
       Generate output containing 80387 instructions for floating point.
  
! ‘-mno-80387’
! ‘-msoft-float’
       Generate output containing library calls for floating point.
  
       *Warning:* the requisite libraries are not part of GCC.  Normally
*************** These '-m' options are defined for the x
*** 30210,30367 ****
  
       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 overridden when '-march'
       indicates that the target CPU always has an FPU and so the
       instruction does not need emulation.  These instructions are not
!      generated unless you also use the '-funsafe-math-optimizations'
       switch.
  
! '-malign-double'
! '-mno-align-double'
!      Control whether GCC aligns 'double', 'long double', and 'long long'
       variables on a two-word boundary or a one-word boundary.  Aligning
!      'double' variables on a two-word boundary produces code that runs
       somewhat faster on a Pentium at the expense of more memory.
  
!      On x86-64, '-malign-double' is enabled by default.
  
!      *Warning:* if you use the '-malign-double' switch, structures
       containing the above types are aligned differently than the
       published application binary interface specifications for the
       x86-32 and are not binary compatible with structures in code
       compiled without that switch.
  
! '-m96bit-long-double'
! '-m128bit-long-double'
!      These switches control the size of 'long double' type.  The x86-32
       application binary interface specifies the size to be 96 bits, so
!      '-m96bit-long-double' is the default in 32-bit mode.
  
!      Modern architectures (Pentium and newer) prefer 'long double' to be
       aligned to an 8- or 16-byte boundary.  In arrays or structures
       conforming to the ABI, this is not possible.  So specifying
!      '-m128bit-long-double' aligns 'long double' to a 16-byte boundary
!      by padding the 'long double' with an additional 32-bit zero.
  
!      In the x86-64 compiler, '-m128bit-long-double' is the default
!      choice as its ABI specifies that 'long double' is aligned on
       16-byte boundary.
  
       Notice that neither of these options enable any extra precision
!      over the x87 standard of 80 bits for a 'long double'.
  
       *Warning:* if you override the default value for your target ABI,
!      this changes the size of structures and arrays containing 'long
!      double' variables, as well as modifying the function calling
!      convention for functions taking 'long double'.  Hence they are not
       binary-compatible with code compiled without that switch.
  
! '-mlong-double-64'
! '-mlong-double-80'
! '-mlong-double-128'
!      These switches control the size of 'long double' type.  A size of
!      64 bits makes the 'long double' type equivalent to the 'double'
       type.  This is the default for 32-bit Bionic C library.  A size of
!      128 bits makes the 'long double' type equivalent to the
!      '__float128' type.  This is the default for 64-bit Bionic C
       library.
  
       *Warning:* if you override the default value for your target ABI,
!      this changes the size of structures and arrays containing 'long
!      double' variables, as well as modifying the function calling
!      convention for functions taking 'long double'.  Hence they are not
       binary-compatible with code compiled without that switch.
  
! '-malign-data=TYPE'
       Control how GCC aligns variables.  Supported values for TYPE are
!      'compat' uses increased alignment value compatible uses GCC 4.8 and
!      earlier, 'abi' uses alignment value as specified by the psABI, and
!      'cacheline' uses increased alignment value to match the cache line
!      size.  'compat' is the default.
  
! '-mlarge-data-threshold=THRESHOLD'
!      When '-mcmodel=medium' is specified, data objects larger than
       THRESHOLD are placed in the large data section.  This value must be
       the same across all objects linked into the binary, and defaults to
       65535.
  
! '-mrtd'
       Use a different function-calling convention, in which functions
!      that take a fixed number of arguments return with the 'ret NUM'
       instruction, which pops their arguments while returning.  This
       saves one instruction in the caller since there is no need to pop
       the arguments there.
  
       You can specify that an individual function is called with this
!      calling sequence with the function attribute 'stdcall'.  You can
!      also override the '-mrtd' option by using the function attribute
!      'cdecl'.  *Note Function Attributes::.
  
       *Warning:* this calling convention is incompatible with the one
       normally used on Unix, so you cannot use it if you need to call
       libraries compiled with the Unix compiler.
  
       Also, you must provide function prototypes for all functions that
!      take variable numbers of arguments (including 'printf'); otherwise
       incorrect code is generated for calls to those functions.
  
       In addition, seriously incorrect code results if you call a
       function with too many arguments.  (Normally, extra arguments are
       harmlessly ignored.)
  
! '-mregparm=NUM'
       Control how many registers are used to pass integer arguments.  By
       default, no registers are used to pass arguments, and at most 3
       registers can be used.  You can control this behavior for a
!      specific function by using the function attribute 'regparm'.  *Note
       Function Attributes::.
  
       *Warning:* if you use this switch, and NUM is nonzero, then you
       must build all modules with the same value, including any
       libraries.  This includes the system libraries and startup modules.
  
! '-msseregparm'
       Use SSE register passing conventions for float and double arguments
       and return values.  You can control this behavior for a specific
!      function by using the function attribute 'sseregparm'.  *Note
       Function Attributes::.
  
       *Warning:* if you use this switch then you must build all modules
       with the same value, including any libraries.  This includes the
       system libraries and startup modules.
  
! '-mvect8-ret-in-mem'
       Return 8-byte vectors in memory instead of MMX registers.  This is
       the default on VxWorks to match the ABI of the Sun Studio compilers
       until version 12.  _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
--- 30219,30376 ----
  
       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 overridden when ‘-march’
       indicates that the target CPU always has an FPU and so the
       instruction does not need emulation.  These instructions are not
!      generated unless you also use the ‘-funsafe-math-optimizations’
       switch.
  
! ‘-malign-double’
! ‘-mno-align-double’
!      Control whether GCC aligns ‘double’, ‘long double’, and ‘long long’
       variables on a two-word boundary or a one-word boundary.  Aligning
!      ‘double’ variables on a two-word boundary produces code that runs
       somewhat faster on a Pentium at the expense of more memory.
  
!      On x86-64, ‘-malign-double’ is enabled by default.
  
!      *Warning:* if you use the ‘-malign-double’ switch, structures
       containing the above types are aligned differently than the
       published application binary interface specifications for the
       x86-32 and are not binary compatible with structures in code
       compiled without that switch.
  
! ‘-m96bit-long-double’
! ‘-m128bit-long-double’
!      These switches control the size of ‘long double’ type.  The x86-32
       application binary interface specifies the size to be 96 bits, so
!      ‘-m96bit-long-double’ is the default in 32-bit mode.
  
!      Modern architectures (Pentium and newer) prefer ‘long double’ to be
       aligned to an 8- or 16-byte boundary.  In arrays or structures
       conforming to the ABI, this is not possible.  So specifying
!      ‘-m128bit-long-double’ aligns ‘long double’ to a 16-byte boundary
!      by padding the ‘long double’ with an additional 32-bit zero.
  
!      In the x86-64 compiler, ‘-m128bit-long-double’ is the default
!      choice as its ABI specifies that ‘long double’ is aligned on
       16-byte boundary.
  
       Notice that neither of these options enable any extra precision
!      over the x87 standard of 80 bits for a ‘long double’.
  
       *Warning:* if you override the default value for your target ABI,
!      this changes the size of structures and arrays containing ‘long
!      double’ variables, as well as modifying the function calling
!      convention for functions taking ‘long double’.  Hence they are not
       binary-compatible with code compiled without that switch.
  
! ‘-mlong-double-64’
! ‘-mlong-double-80’
! ‘-mlong-double-128’
!      These switches control the size of ‘long double’ type.  A size of
!      64 bits makes the ‘long double’ type equivalent to the ‘double’
       type.  This is the default for 32-bit Bionic C library.  A size of
!      128 bits makes the ‘long double’ type equivalent to the
!      ‘__float128’ type.  This is the default for 64-bit Bionic C
       library.
  
       *Warning:* if you override the default value for your target ABI,
!      this changes the size of structures and arrays containing ‘long
!      double’ variables, as well as modifying the function calling
!      convention for functions taking ‘long double’.  Hence they are not
       binary-compatible with code compiled without that switch.
  
! ‘-malign-data=TYPE’
       Control how GCC aligns variables.  Supported values for TYPE are
!      ‘compat’ uses increased alignment value compatible uses GCC 4.8 and
!      earlier, ‘abi’ uses alignment value as specified by the psABI, and
!      ‘cacheline’ uses increased alignment value to match the cache line
!      size.  ‘compat’ is the default.
  
! ‘-mlarge-data-threshold=THRESHOLD’
!      When ‘-mcmodel=medium’ is specified, data objects larger than
       THRESHOLD are placed in the large data section.  This value must be
       the same across all objects linked into the binary, and defaults to
       65535.
  
! ‘-mrtd’
       Use a different function-calling convention, in which functions
!      that take a fixed number of arguments return with the ‘ret NUM’
       instruction, which pops their arguments while returning.  This
       saves one instruction in the caller since there is no need to pop
       the arguments there.
  
       You can specify that an individual function is called with this
!      calling sequence with the function attribute ‘stdcall’.  You can
!      also override the ‘-mrtd’ option by using the function attribute
!      ‘cdecl’.  *Note Function Attributes::.
  
       *Warning:* this calling convention is incompatible with the one
       normally used on Unix, so you cannot use it if you need to call
       libraries compiled with the Unix compiler.
  
       Also, you must provide function prototypes for all functions that
!      take variable numbers of arguments (including ‘printf’); otherwise
       incorrect code is generated for calls to those functions.
  
       In addition, seriously incorrect code results if you call a
       function with too many arguments.  (Normally, extra arguments are
       harmlessly ignored.)
  
! ‘-mregparm=NUM’
       Control how many registers are used to pass integer arguments.  By
       default, no registers are used to pass arguments, and at most 3
       registers can be used.  You can control this behavior for a
!      specific function by using the function attribute ‘regparm’.  *Note
       Function Attributes::.
  
       *Warning:* if you use this switch, and NUM is nonzero, then you
       must build all modules with the same value, including any
       libraries.  This includes the system libraries and startup modules.
  
! ‘-msseregparm’
       Use SSE register passing conventions for float and double arguments
       and return values.  You can control this behavior for a specific
!      function by using the function attribute ‘sseregparm’.  *Note
       Function Attributes::.
  
       *Warning:* if you use this switch then you must build all modules
       with the same value, including any libraries.  This includes the
       system libraries and startup modules.
  
! ‘-mvect8-ret-in-mem’
       Return 8-byte vectors in memory instead of MMX registers.  This is
       the default on VxWorks to match the ABI of the Sun Studio compilers
       until version 12.  _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
*************** These '-m' options are defined for the x
*** 30375,30406 ****
       through so-called "catastrophic cancellation", when this option is
       used to set the precision to less than extended precision.
  
! '-mdaz-ftz'
  
       The flush-to-zero (FTZ) and denormals-are-zero (DAZ) flags in the
       MXCSR register are used to control floating-point calculations.SSE
       and AVX instructions including scalar and vector instructions could
!      benefit from enabling the FTZ and DAZ flags when '-mdaz-ftz' is
!      specified.  Don't set FTZ/DAZ flags when '-mno-daz-ftz' or
!      '-shared' is specified, '-mdaz-ftz' will set FTZ/DAZ flags even
!      with '-shared'.
  
! '-mstackrealign'
!      Realign the stack at entry.  On the x86, the '-mstackrealign'
       option generates an alternate prologue and epilogue that realigns
       the run-time stack if necessary.  This supports mixing legacy codes
       that keep 4-byte stack alignment with modern codes that keep
       16-byte stack alignment for SSE compatibility.  See also the
!      attribute 'force_align_arg_pointer', applicable to individual
       functions.
  
! '-mpreferred-stack-boundary=NUM'
       Attempt to keep the stack boundary aligned to a 2 raised to NUM
!      byte boundary.  If '-mpreferred-stack-boundary' is not specified,
       the default is 4 (16 bytes or 128 bits).
  
       *Warning:* When generating code for the x86-64 architecture with
!      SSE extensions disabled, '-mpreferred-stack-boundary=3' can be used
       to keep the stack boundary aligned to 8 byte boundary.  Since
       x86-64 ABI require 16 byte stack alignment, this is ABI
       incompatible and intended to be used in controlled environment
--- 30384,30415 ----
       through so-called "catastrophic cancellation", when this option is
       used to set the precision to less than extended precision.
  
! ‘-mdaz-ftz’
  
       The flush-to-zero (FTZ) and denormals-are-zero (DAZ) flags in the
       MXCSR register are used to control floating-point calculations.SSE
       and AVX instructions including scalar and vector instructions could
!      benefit from enabling the FTZ and DAZ flags when ‘-mdaz-ftz’ is
!      specified.  Don't set FTZ/DAZ flags when ‘-mno-daz-ftz’ or
!      ‘-shared’ is specified, ‘-mdaz-ftz’ will set FTZ/DAZ flags even
!      with ‘-shared’.
  
! ‘-mstackrealign’
!      Realign the stack at entry.  On the x86, the ‘-mstackrealign’
       option generates an alternate prologue and epilogue that realigns
       the run-time stack if necessary.  This supports mixing legacy codes
       that keep 4-byte stack alignment with modern codes that keep
       16-byte stack alignment for SSE compatibility.  See also the
!      attribute ‘force_align_arg_pointer’, applicable to individual
       functions.
  
! ‘-mpreferred-stack-boundary=NUM’
       Attempt to keep the stack boundary aligned to a 2 raised to NUM
!      byte boundary.  If ‘-mpreferred-stack-boundary’ is not specified,
       the default is 4 (16 bytes or 128 bits).
  
       *Warning:* When generating code for the x86-64 architecture with
!      SSE extensions disabled, ‘-mpreferred-stack-boundary=3’ can be used
       to keep the stack boundary aligned to 8 byte boundary.  Since
       x86-64 ABI require 16 byte stack alignment, this is ABI
       incompatible and intended to be used in controlled environment
*************** These '-m' options are defined for the x
*** 30411,30429 ****
       misaligned memory access traps.  In addition, variable arguments
       are handled incorrectly for 16 byte aligned objects (including x87
       long double and __int128), leading to wrong results.  You must
!      build all modules with '-mpreferred-stack-boundary=3', including
       any libraries.  This includes the system libraries and startup
       modules.
  
! '-mincoming-stack-boundary=NUM'
       Assume the incoming stack is aligned to a 2 raised to NUM byte
!      boundary.  If '-mincoming-stack-boundary' is not specified, the one
!      specified by '-mpreferred-stack-boundary' is used.
  
!      On Pentium and Pentium Pro, 'double' and 'long double' values
!      should be aligned to an 8-byte boundary (see '-malign-double') or
       suffer significant run time performance penalties.  On Pentium III,
!      the Streaming SIMD Extension (SSE) data type '__m128' may not work
       properly if it is not 16-byte aligned.
  
       To ensure proper alignment of this values on the stack, the stack
--- 30420,30438 ----
       misaligned memory access traps.  In addition, variable arguments
       are handled incorrectly for 16 byte aligned objects (including x87
       long double and __int128), leading to wrong results.  You must
!      build all modules with ‘-mpreferred-stack-boundary=3’, including
       any libraries.  This includes the system libraries and startup
       modules.
  
! ‘-mincoming-stack-boundary=NUM’
       Assume the incoming stack is aligned to a 2 raised to NUM byte
!      boundary.  If ‘-mincoming-stack-boundary’ is not specified, the one
!      specified by ‘-mpreferred-stack-boundary’ is used.
  
!      On Pentium and Pentium Pro, ‘double’ and ‘long double’ values
!      should be aligned to an 8-byte boundary (see ‘-malign-double’) or
       suffer significant run time performance penalties.  On Pentium III,
!      the Streaming SIMD Extension (SSE) data type ‘__m128’ may not work
       properly if it is not 16-byte aligned.
  
       To ensure proper alignment of this values on the stack, the stack
*************** These '-m' options are defined for the x
*** 30438,30539 ****
       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'
! '-msse'
! '-msse2'
! '-msse3'
! '-mssse3'
! '-msse4'
! '-msse4a'
! '-msse4.1'
! '-msse4.2'
! '-mavx'
! '-mavx2'
! '-mavx512f'
! '-mavx512pf'
! '-mavx512er'
! '-mavx512cd'
! '-mavx512vl'
! '-mavx512bw'
! '-mavx512dq'
! '-mavx512ifma'
! '-mavx512vbmi'
! '-msha'
! '-maes'
! '-mpclmul'
! '-mclflushopt'
! '-mclwb'
! '-mfsgsbase'
! '-mptwrite'
! '-mrdrnd'
! '-mf16c'
! '-mfma'
! '-mpconfig'
! '-mwbnoinvd'
! '-mfma4'
! '-mprfchw'
! '-mrdpid'
! '-mprefetchwt1'
! '-mrdseed'
! '-msgx'
! '-mxop'
! '-mlwp'
! '-m3dnow'
! '-m3dnowa'
! '-mpopcnt'
! '-mabm'
! '-madx'
! '-mbmi'
! '-mbmi2'
! '-mlzcnt'
! '-mfxsr'
! '-mxsave'
! '-mxsaveopt'
! '-mxsavec'
! '-mxsaves'
! '-mrtm'
! '-mhle'
! '-mtbm'
! '-mmwaitx'
! '-mclzero'
! '-mpku'
! '-mavx512vbmi2'
! '-mavx512bf16'
! '-mavx512fp16'
! '-mgfni'
! '-mvaes'
! '-mwaitpkg'
! '-mvpclmulqdq'
! '-mavx512bitalg'
! '-mmovdiri'
! '-mmovdir64b'
! '-menqcmd'
! '-muintr'
! '-mtsxldtrk'
! '-mavx512vpopcntdq'
! '-mavx512vp2intersect'
! '-mavx5124fmaps'
! '-mavx512vnni'
! '-mavxvnni'
! '-mavx5124vnniw'
! '-mcldemote'
! '-mserialize'
! '-mamx-tile'
! '-mamx-int8'
! '-mamx-bf16'
! '-mhreset'
! '-mkl'
! '-mwidekl'
! '-mavxifma'
! '-mavxvnniint8'
! '-mavxneconvert'
! '-mcmpccxadd'
! '-mamx-fp16'
! '-mprefetchi'
! '-mraoint'
! '-mamx-complex'
       These switches enable the use of instructions in the MMX, SSE,
       SSE2, SSE3, SSSE3, SSE4, SSE4A, SSE4.1, SSE4.2, AVX, AVX2, AVX512F,
       AVX512PF, AVX512ER, AVX512CD, AVX512VL, AVX512BW, AVX512DQ,
--- 30447,30548 ----
       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’
! ‘-msse’
! ‘-msse2’
! ‘-msse3’
! ‘-mssse3’
! ‘-msse4’
! ‘-msse4a’
! ‘-msse4.1’
! ‘-msse4.2’
! ‘-mavx’
! ‘-mavx2’
! ‘-mavx512f’
! ‘-mavx512pf’
! ‘-mavx512er’
! ‘-mavx512cd’
! ‘-mavx512vl’
! ‘-mavx512bw’
! ‘-mavx512dq’
! ‘-mavx512ifma’
! ‘-mavx512vbmi’
! ‘-msha’
! ‘-maes’
! ‘-mpclmul’
! ‘-mclflushopt’
! ‘-mclwb’
! ‘-mfsgsbase’
! ‘-mptwrite’
! ‘-mrdrnd’
! ‘-mf16c’
! ‘-mfma’
! ‘-mpconfig’
! ‘-mwbnoinvd’
! ‘-mfma4’
! ‘-mprfchw’
! ‘-mrdpid’
! ‘-mprefetchwt1’
! ‘-mrdseed’
! ‘-msgx’
! ‘-mxop’
! ‘-mlwp’
! ‘-m3dnow’
! ‘-m3dnowa’
! ‘-mpopcnt’
! ‘-mabm’
! ‘-madx’
! ‘-mbmi’
! ‘-mbmi2’
! ‘-mlzcnt’
! ‘-mfxsr’
! ‘-mxsave’
! ‘-mxsaveopt’
! ‘-mxsavec’
! ‘-mxsaves’
! ‘-mrtm’
! ‘-mhle’
! ‘-mtbm’
! ‘-mmwaitx’
! ‘-mclzero’
! ‘-mpku’
! ‘-mavx512vbmi2’
! ‘-mavx512bf16’
! ‘-mavx512fp16’
! ‘-mgfni’
! ‘-mvaes’
! ‘-mwaitpkg’
! ‘-mvpclmulqdq’
! ‘-mavx512bitalg’
! ‘-mmovdiri’
! ‘-mmovdir64b’
! ‘-menqcmd’
! ‘-muintr’
! ‘-mtsxldtrk’
! ‘-mavx512vpopcntdq’
! ‘-mavx512vp2intersect’
! ‘-mavx5124fmaps’
! ‘-mavx512vnni’
! ‘-mavxvnni’
! ‘-mavx5124vnniw’
! ‘-mcldemote’
! ‘-mserialize’
! ‘-mamx-tile’
! ‘-mamx-int8’
! ‘-mamx-bf16’
! ‘-mhreset’
! ‘-mkl’
! ‘-mwidekl’
! ‘-mavxifma’
! ‘-mavxvnniint8’
! ‘-mavxneconvert’
! ‘-mcmpccxadd’
! ‘-mamx-fp16’
! ‘-mprefetchi’
! ‘-mraoint’
! ‘-mamx-complex’
       These switches enable the use of instructions in the MMX, SSE,
       SSE2, SSE3, SSSE3, SSE4, SSE4A, SSE4.1, SSE4.2, AVX, AVX2, AVX512F,
       AVX512PF, AVX512ER, AVX512CD, AVX512VL, AVX512BW, AVX512DQ,
*************** These '-m' options are defined for the x
*** 30548,30554 ****
       AMXTILE, AMXINT8, AMXBF16, KL, WIDEKL, AVXVNNI, AVX512-FP16,
       AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AMX-FP16, PREFETCHI,
       RAOINT, AMX-COMPLEX or CLDEMOTE extended instruction sets.  Each
!      has a corresponding '-mno-' option to disable use of these
       instructions.
  
       These extensions are also available as built-in functions: see
--- 30557,30563 ----
       AMXTILE, AMXINT8, AMXBF16, KL, WIDEKL, AVXVNNI, AVX512-FP16,
       AVXIFMA, AVXVNNIINT8, AVXNECONVERT, CMPCCXADD, AMX-FP16, PREFETCHI,
       RAOINT, AMX-COMPLEX or CLDEMOTE extended instruction sets.  Each
!      has a corresponding ‘-mno-’ option to disable use of these
       instructions.
  
       These extensions are also available as built-in functions: see
*************** These '-m' options are defined for the x
*** 30556,30594 ****
       enabled and disabled by these switches.
  
       To generate SSE/SSE2 instructions automatically from floating-point
!      code (as opposed to 387 instructions), see '-mfpmath=sse'.
  
!      GCC depresses SSEx instructions when '-mavx' is used.  Instead, it
       generates new AVX instructions or AVX equivalence for all SSEx
       instructions when needed.
  
       These options enable GCC to use these extended instructions in
!      generated code, even without '-mfpmath=sse'.  Applications that
       perform run-time CPU detection must compile separate files for each
       supported architecture, using the appropriate flags.  In
       particular, the file containing the CPU detection code should be
       compiled without these options.
  
! '-mdump-tune-features'
       This option instructs GCC to dump the names of the x86 performance
       tuning features and default settings.  The names can be used in
!      '-mtune-ctrl=FEATURE-LIST'.
  
! '-mtune-ctrl=FEATURE-LIST'
       This option is used to do fine grain control of x86 code generation
       features.  FEATURE-LIST is a comma separated list of FEATURE names.
!      See also '-mdump-tune-features'.  When specified, the FEATURE is
!      turned on if it is not preceded with '^', otherwise, it is turned
!      off.  '-mtune-ctrl=FEATURE-LIST' is intended to be used by GCC
       developers.  Using it may lead to code paths not covered by testing
       and can potentially result in compiler ICEs or runtime errors.
  
! '-mno-default'
       This option instructs GCC to turn off all tunable features.  See
!      also '-mtune-ctrl=FEATURE-LIST' and '-mdump-tune-features'.
  
! '-mcld'
!      This option instructs GCC to emit a 'cld' instruction in the
       prologue of functions that use string instructions.  String
       instructions depend on the DF flag to select between autoincrement
       or autodecrement mode.  While the ABI specifies the DF flag to be
--- 30565,30603 ----
       enabled and disabled by these switches.
  
       To generate SSE/SSE2 instructions automatically from floating-point
!      code (as opposed to 387 instructions), see ‘-mfpmath=sse’.
  
!      GCC depresses SSEx instructions when ‘-mavx’ is used.  Instead, it
       generates new AVX instructions or AVX equivalence for all SSEx
       instructions when needed.
  
       These options enable GCC to use these extended instructions in
!      generated code, even without ‘-mfpmath=sse’.  Applications that
       perform run-time CPU detection must compile separate files for each
       supported architecture, using the appropriate flags.  In
       particular, the file containing the CPU detection code should be
       compiled without these options.
  
! ‘-mdump-tune-features’
       This option instructs GCC to dump the names of the x86 performance
       tuning features and default settings.  The names can be used in
!      ‘-mtune-ctrl=FEATURE-LIST’.
  
! ‘-mtune-ctrl=FEATURE-LIST’
       This option is used to do fine grain control of x86 code generation
       features.  FEATURE-LIST is a comma separated list of FEATURE names.
!      See also ‘-mdump-tune-features’.  When specified, the FEATURE is
!      turned on if it is not preceded with ‘^’, otherwise, it is turned
!      off.  ‘-mtune-ctrl=FEATURE-LIST’ is intended to be used by GCC
       developers.  Using it may lead to code paths not covered by testing
       and can potentially result in compiler ICEs or runtime errors.
  
! ‘-mno-default’
       This option instructs GCC to turn off all tunable features.  See
!      also ‘-mtune-ctrl=FEATURE-LIST’ and ‘-mdump-tune-features’.
  
! ‘-mcld’
!      This option instructs GCC to emit a ‘cld’ instruction in the
       prologue of functions that use string instructions.  String
       instructions depend on the DF flag to select between autoincrement
       or autodecrement mode.  While the ABI specifies the DF flag to be
*************** These '-m' options are defined for the x
*** 30597,30645 ****
       dispatchers.  The exception handler can be invoked with the DF flag
       set, which leads to wrong direction mode when string instructions
       are used.  This option can be enabled by default on 32-bit x86
!      targets by configuring GCC with the '--enable-cld' configure
!      option.  Generation of 'cld' instructions can be suppressed with
!      the '-mno-cld' compiler option in this case.
  
! '-mvzeroupper'
!      This option instructs GCC to emit a 'vzeroupper' instruction before
       a transfer of control flow out of the function to minimize the AVX
!      to SSE transition penalty as well as remove unnecessary 'zeroupper'
       intrinsics.
  
! '-mprefer-avx128'
       This option instructs GCC to use 128-bit AVX instructions instead
       of 256-bit AVX instructions in the auto-vectorizer.
  
! '-mprefer-vector-width=OPT'
       This option instructs GCC to use OPT-bit vector width in
       instructions instead of default on the selected platform.
  
! '-mmove-max=BITS'
       This option instructs GCC to set the maximum number of bits can be
       moved from memory to memory efficiently to BITS.  The valid BITS
       are 128, 256 and 512.
  
! '-mstore-max=BITS'
       This option instructs GCC to set the maximum number of bits can be
       stored to memory efficiently to BITS.  The valid BITS are 128, 256
       and 512.
  
!      'none'
            No extra limitations applied to GCC other than defined by the
            selected platform.
  
!      '128'
            Prefer 128-bit vector width for instructions.
  
!      '256'
            Prefer 256-bit vector width for instructions.
  
!      '512'
            Prefer 512-bit vector width for instructions.
  
! '-mcx16'
!      This option enables GCC to generate 'CMPXCHG16B' instructions in
       64-bit code to implement compare-and-exchange operations on 16-byte
       aligned 128-bit objects.  This is useful for atomic updates of data
       structures exceeding one machine word in size.  The compiler uses
--- 30606,30654 ----
       dispatchers.  The exception handler can be invoked with the DF flag
       set, which leads to wrong direction mode when string instructions
       are used.  This option can be enabled by default on 32-bit x86
!      targets by configuring GCC with the ‘--enable-cld’ configure
!      option.  Generation of ‘cld’ instructions can be suppressed with
!      the ‘-mno-cld’ compiler option in this case.
  
! ‘-mvzeroupper’
!      This option instructs GCC to emit a ‘vzeroupper’ instruction before
       a transfer of control flow out of the function to minimize the AVX
!      to SSE transition penalty as well as remove unnecessary ‘zeroupper’
       intrinsics.
  
! ‘-mprefer-avx128’
       This option instructs GCC to use 128-bit AVX instructions instead
       of 256-bit AVX instructions in the auto-vectorizer.
  
! ‘-mprefer-vector-width=OPT’
       This option instructs GCC to use OPT-bit vector width in
       instructions instead of default on the selected platform.
  
! ‘-mmove-max=BITS’
       This option instructs GCC to set the maximum number of bits can be
       moved from memory to memory efficiently to BITS.  The valid BITS
       are 128, 256 and 512.
  
! ‘-mstore-max=BITS’
       This option instructs GCC to set the maximum number of bits can be
       stored to memory efficiently to BITS.  The valid BITS are 128, 256
       and 512.
  
!      ‘none’
            No extra limitations applied to GCC other than defined by the
            selected platform.
  
!      ‘128’
            Prefer 128-bit vector width for instructions.
  
!      ‘256’
            Prefer 256-bit vector width for instructions.
  
!      ‘512’
            Prefer 512-bit vector width for instructions.
  
! ‘-mcx16’
!      This option enables GCC to generate ‘CMPXCHG16B’ instructions in
       64-bit code to implement compare-and-exchange operations on 16-byte
       aligned 128-bit objects.  This is useful for atomic updates of data
       structures exceeding one machine word in size.  The compiler uses
*************** These '-m' options are defined for the x
*** 30647,30775 ****
       for *note __atomic Builtins:: operating on 128-bit integers, a
       library call is always used.
  
! '-msahf'
!      This option enables generation of 'SAHF' instructions in 64-bit
       code.  Early Intel Pentium 4 CPUs with Intel 64 support, prior to
       the introduction of Pentium 4 G1 step in December 2005, lacked the
!      'LAHF' and 'SAHF' instructions which are supported by AMD64.  These
       are load and store instructions, respectively, for certain status
!      flags.  In 64-bit mode, the 'SAHF' instruction is used to optimize
!      'fmod', 'drem', and 'remainder' built-in functions; see *note Other
       Builtins:: for details.
  
! '-mmovbe'
!      This option enables use of the 'movbe' instruction to implement
!      '__builtin_bswap32' and '__builtin_bswap64'.
  
! '-mshstk'
!      The '-mshstk' option enables shadow stack built-in functions from
       x86 Control-flow Enforcement Technology (CET).
  
! '-mcrc32'
!      This option enables built-in functions '__builtin_ia32_crc32qi',
!      '__builtin_ia32_crc32hi', '__builtin_ia32_crc32si' and
!      '__builtin_ia32_crc32di' to generate the 'crc32' machine
       instruction.
  
! '-mmwait'
!      This option enables built-in functions '__builtin_ia32_monitor',
!      and '__builtin_ia32_mwait' to generate the 'monitor' and 'mwait'
       machine instructions.
  
! '-mrecip'
!      This option enables use of 'RCPSS' and 'RSQRTSS' instructions (and
!      their vectorized variants 'RCPPS' and 'RSQRTPS') with an additional
!      Newton-Raphson step to increase precision instead of 'DIVSS' and
!      'SQRTSS' (and their vectorized variants) for single-precision
       floating-point arguments.  These instructions are generated only
!      when '-funsafe-math-optimizations' is enabled together with
!      '-ffinite-math-only' and '-fno-trapping-math'.  Note that while the
       throughput of the sequence is higher than the throughput of the
       non-reciprocal instruction, the precision of the sequence can be
       decreased by up to 2 ulp (i.e. the inverse of 1.0 equals
       0.99999994).
  
!      Note that GCC implements '1.0f/sqrtf(X)' in terms of 'RSQRTSS' (or
!      'RSQRTPS') already with '-ffast-math' (or the above option
!      combination), and doesn't need '-mrecip'.
  
       Also note that GCC emits the above sequence with additional
       Newton-Raphson step for vectorized single-float division and
!      vectorized 'sqrtf(X)' already with '-ffast-math' (or the above
!      option combination), and doesn't need '-mrecip'.
  
! '-mrecip=OPT'
       This option controls which reciprocal estimate instructions may be
       used.  OPT is a comma-separated list of options, which may be
!      preceded by a '!' to invert the option:
  
!      'all'
            Enable all estimate instructions.
  
!      'default'
!           Enable the default instructions, equivalent to '-mrecip'.
  
!      'none'
!           Disable all estimate instructions, equivalent to '-mno-recip'.
  
!      'div'
            Enable the approximation for scalar division.
  
!      'vec-div'
            Enable the approximation for vectorized division.
  
!      'sqrt'
            Enable the approximation for scalar square root.
  
!      'vec-sqrt'
            Enable the approximation for vectorized square root.
  
!      So, for example, '-mrecip=all,!sqrt' enables all of the reciprocal
       approximations, except for square root.
  
! '-mveclibabi=TYPE'
       Specifies the ABI type to use for vectorizing intrinsics using an
!      external library.  Supported values for TYPE are 'svml' for the
!      Intel short vector math library and 'acml' for the AMD math core
!      library.  To use this option, both '-ftree-vectorize' and
!      '-funsafe-math-optimizations' have to be enabled, and an SVML or
       ACML ABI-compatible library must be specified at link time.
  
!      GCC currently emits calls to 'vmldExp2', 'vmldLn2', 'vmldLog102',
!      'vmldPow2', 'vmldTanh2', 'vmldTan2', 'vmldAtan2', 'vmldAtanh2',
!      'vmldCbrt2', 'vmldSinh2', 'vmldSin2', 'vmldAsinh2', 'vmldAsin2',
!      'vmldCosh2', 'vmldCos2', 'vmldAcosh2', 'vmldAcos2', 'vmlsExp4',
!      'vmlsLn4', 'vmlsLog104', 'vmlsPow4', 'vmlsTanh4', 'vmlsTan4',
!      'vmlsAtan4', 'vmlsAtanh4', 'vmlsCbrt4', 'vmlsSinh4', 'vmlsSin4',
!      'vmlsAsinh4', 'vmlsAsin4', 'vmlsCosh4', 'vmlsCos4', 'vmlsAcosh4'
!      and 'vmlsAcos4' for corresponding function type when
!      '-mveclibabi=svml' is used, and '__vrd2_sin', '__vrd2_cos',
!      '__vrd2_exp', '__vrd2_log', '__vrd2_log2', '__vrd2_log10',
!      '__vrs4_sinf', '__vrs4_cosf', '__vrs4_expf', '__vrs4_logf',
!      '__vrs4_log2f', '__vrs4_log10f' and '__vrs4_powf' for the
!      corresponding function type when '-mveclibabi=acml' is used.
  
! '-mabi=NAME'
       Generate code for the specified calling convention.  Permissible
!      values are 'sysv' for the ABI used on GNU/Linux and other systems,
!      and 'ms' for the Microsoft ABI. The default is to use the Microsoft
       ABI when targeting Microsoft Windows and the SysV ABI on all other
       systems.  You can control this behavior for specific functions by
!      using the function attributes 'ms_abi' and 'sysv_abi'.  *Note
       Function Attributes::.
  
! '-mforce-indirect-call'
       Force all calls to functions to be indirect.  This is useful when
       using Intel Processor Trace where it generates more precise timing
       information for function calls.
  
! '-mmanual-endbr'
!      Insert ENDBR instruction at function entry only via the 'cf_check'
       function attribute.  This is useful when used with the option
!      '-fcf-protection=branch' to control ENDBR insertion at the function
       entry.
  
! '-mcet-switch'
       By default, CET instrumentation is turned off on switch statements
       that use a jump table and indirect branch track is disabled.  Since
       jump tables are stored in read-only memory, this does not result in
--- 30656,30784 ----
       for *note __atomic Builtins:: operating on 128-bit integers, a
       library call is always used.
  
! ‘-msahf’
!      This option enables generation of ‘SAHF’ instructions in 64-bit
       code.  Early Intel Pentium 4 CPUs with Intel 64 support, prior to
       the introduction of Pentium 4 G1 step in December 2005, lacked the
!      ‘LAHF’ and ‘SAHF’ instructions which are supported by AMD64.  These
       are load and store instructions, respectively, for certain status
!      flags.  In 64-bit mode, the ‘SAHF’ instruction is used to optimize
!      ‘fmod’, ‘drem’, and ‘remainder’ built-in functions; see *note Other
       Builtins:: for details.
  
! ‘-mmovbe’
!      This option enables use of the ‘movbe’ instruction to implement
!      ‘__builtin_bswap32’ and ‘__builtin_bswap64’.
  
! ‘-mshstk’
!      The ‘-mshstk’ option enables shadow stack built-in functions from
       x86 Control-flow Enforcement Technology (CET).
  
! ‘-mcrc32’
!      This option enables built-in functions ‘__builtin_ia32_crc32qi’,
!      ‘__builtin_ia32_crc32hi’, ‘__builtin_ia32_crc32si’ and
!      ‘__builtin_ia32_crc32di’ to generate the ‘crc32’ machine
       instruction.
  
! ‘-mmwait’
!      This option enables built-in functions ‘__builtin_ia32_monitor’,
!      and ‘__builtin_ia32_mwait’ to generate the ‘monitor’ and ‘mwait’
       machine instructions.
  
! ‘-mrecip’
!      This option enables use of ‘RCPSS’ and ‘RSQRTSS’ instructions (and
!      their vectorized variants ‘RCPPS’ and ‘RSQRTPS’) with an additional
!      Newton-Raphson step to increase precision instead of ‘DIVSS’ and
!      ‘SQRTSS’ (and their vectorized variants) for single-precision
       floating-point arguments.  These instructions are generated only
!      when ‘-funsafe-math-optimizations’ is enabled together with
!      ‘-ffinite-math-only’ and ‘-fno-trapping-math’.  Note that while the
       throughput of the sequence is higher than the throughput of the
       non-reciprocal instruction, the precision of the sequence can be
       decreased by up to 2 ulp (i.e. the inverse of 1.0 equals
       0.99999994).
  
!      Note that GCC implements ‘1.0f/sqrtf(X)’ in terms of ‘RSQRTSS’ (or
!      ‘RSQRTPS’) already with ‘-ffast-math’ (or the above option
!      combination), and doesn't need ‘-mrecip’.
  
       Also note that GCC emits the above sequence with additional
       Newton-Raphson step for vectorized single-float division and
!      vectorized ‘sqrtf(X)’ already with ‘-ffast-math’ (or the above
!      option combination), and doesn't need ‘-mrecip’.
  
! ‘-mrecip=OPT’
       This option controls which reciprocal estimate instructions may be
       used.  OPT is a comma-separated list of options, which may be
!      preceded by a ‘!’ to invert the option:
  
!      ‘all’
            Enable all estimate instructions.
  
!      ‘default’
!           Enable the default instructions, equivalent to ‘-mrecip’.
  
!      ‘none’
!           Disable all estimate instructions, equivalent to ‘-mno-recip’.
  
!      ‘div’
            Enable the approximation for scalar division.
  
!      ‘vec-div’
            Enable the approximation for vectorized division.
  
!      ‘sqrt’
            Enable the approximation for scalar square root.
  
!      ‘vec-sqrt’
            Enable the approximation for vectorized square root.
  
!      So, for example, ‘-mrecip=all,!sqrt’ enables all of the reciprocal
       approximations, except for square root.
  
! ‘-mveclibabi=TYPE’
       Specifies the ABI type to use for vectorizing intrinsics using an
!      external library.  Supported values for TYPE are ‘svml’ for the
!      Intel short vector math library and ‘acml’ for the AMD math core
!      library.  To use this option, both ‘-ftree-vectorize’ and
!      ‘-funsafe-math-optimizations’ have to be enabled, and an SVML or
       ACML ABI-compatible library must be specified at link time.
  
!      GCC currently emits calls to ‘vmldExp2’, ‘vmldLn2’, ‘vmldLog102’,
!      ‘vmldPow2’, ‘vmldTanh2’, ‘vmldTan2’, ‘vmldAtan2’, ‘vmldAtanh2’,
!      ‘vmldCbrt2’, ‘vmldSinh2’, ‘vmldSin2’, ‘vmldAsinh2’, ‘vmldAsin2’,
!      ‘vmldCosh2’, ‘vmldCos2’, ‘vmldAcosh2’, ‘vmldAcos2’, ‘vmlsExp4’,
!      ‘vmlsLn4’, ‘vmlsLog104’, ‘vmlsPow4’, ‘vmlsTanh4’, ‘vmlsTan4’,
!      ‘vmlsAtan4’, ‘vmlsAtanh4’, ‘vmlsCbrt4’, ‘vmlsSinh4’, ‘vmlsSin4’,
!      ‘vmlsAsinh4’, ‘vmlsAsin4’, ‘vmlsCosh4’, ‘vmlsCos4’, ‘vmlsAcosh4’
!      and ‘vmlsAcos4’ for corresponding function type when
!      ‘-mveclibabi=svml’ is used, and ‘__vrd2_sin’, ‘__vrd2_cos’,
!      ‘__vrd2_exp’, ‘__vrd2_log’, ‘__vrd2_log2’, ‘__vrd2_log10’,
!      ‘__vrs4_sinf’, ‘__vrs4_cosf’, ‘__vrs4_expf’, ‘__vrs4_logf’,
!      ‘__vrs4_log2f’, ‘__vrs4_log10f’ and ‘__vrs4_powf’ for the
!      corresponding function type when ‘-mveclibabi=acml’ is used.
  
! ‘-mabi=NAME’
       Generate code for the specified calling convention.  Permissible
!      values are ‘sysv’ for the ABI used on GNU/Linux and other systems,
!      and ‘ms’ for the Microsoft ABI. The default is to use the Microsoft
       ABI when targeting Microsoft Windows and the SysV ABI on all other
       systems.  You can control this behavior for specific functions by
!      using the function attributes ‘ms_abi’ and ‘sysv_abi’.  *Note
       Function Attributes::.
  
! ‘-mforce-indirect-call’
       Force all calls to functions to be indirect.  This is useful when
       using Intel Processor Trace where it generates more precise timing
       information for function calls.
  
! ‘-mmanual-endbr’
!      Insert ENDBR instruction at function entry only via the ‘cf_check’
       function attribute.  This is useful when used with the option
!      ‘-fcf-protection=branch’ to control ENDBR insertion at the function
       entry.
  
! ‘-mcet-switch’
       By default, CET instrumentation is turned off on switch statements
       that use a jump table and indirect branch track is disabled.  Since
       jump tables are stored in read-only memory, this does not result in
*************** These '-m' options are defined for the x
*** 30779,30830 ****
       branch track for switch statements with jump tables which leads to
       the jump targets reachable via any indirect jumps.
  
! '-mcall-ms2sysv-xlogues'
       Due to differences in 64-bit ABIs, any Microsoft ABI function that
       calls a System V ABI function must consider RSI, RDI and XMM6-15 as
       clobbered.  By default, the code for saving and restoring these
       registers is emitted inline, resulting in fairly lengthy prologues
!      and epilogues.  Using '-mcall-ms2sysv-xlogues' emits prologues and
       epilogues that use stubs in the static portion of libgcc to perform
       these saves and restores, thus reducing function size at the cost
       of a few extra instructions.
  
! '-mtls-dialect=TYPE'
!      Generate code to access thread-local storage using the 'gnu' or
!      'gnu2' conventions.  'gnu' is the conservative default; 'gnu2' is
       more efficient, but it may add compile- and run-time requirements
       that cannot be satisfied on all systems.
  
! '-mpush-args'
! '-mno-push-args'
       Use PUSH operations to store outgoing parameters.  This method is
       shorter and usually equally fast as method using SUB/MOV operations
       and is enabled by default.  In some cases disabling it may improve
       performance because of improved scheduling and reduced
       dependencies.
  
! '-maccumulate-outgoing-args'
       If enabled, the maximum amount of space required for outgoing
       arguments is computed in the function prologue.  This is faster on
       most modern CPUs because of reduced dependencies, improved
       scheduling and reduced stack usage when the preferred stack
       boundary is not equal to 2.  The drawback is a notable increase in
!      code size.  This switch implies '-mno-push-args'.
  
! '-mthreads'
       Support thread-safe exception handling on MinGW. Programs that rely
       on thread-safe exception handling must compile and link all code
!      with the '-mthreads' option.  When compiling, '-mthreads' defines
!      '-D_MT'; when linking, it links in a special thread helper library
!      '-lmingwthrd' which cleans up per-thread exception-handling data.
  
! '-mms-bitfields'
! '-mno-ms-bitfields'
  
       Enable/disable bit-field layout compatible with the native
       Microsoft Windows compiler.
  
!      If 'packed' is used on a structure, or if bit-fields are used, it
       may be that the Microsoft ABI lays out the structure differently
       than the way GCC normally does.  Particularly when moving packed
       data between functions compiled with GCC and the native Microsoft
--- 30788,30839 ----
       branch track for switch statements with jump tables which leads to
       the jump targets reachable via any indirect jumps.
  
! ‘-mcall-ms2sysv-xlogues’
       Due to differences in 64-bit ABIs, any Microsoft ABI function that
       calls a System V ABI function must consider RSI, RDI and XMM6-15 as
       clobbered.  By default, the code for saving and restoring these
       registers is emitted inline, resulting in fairly lengthy prologues
!      and epilogues.  Using ‘-mcall-ms2sysv-xlogues’ emits prologues and
       epilogues that use stubs in the static portion of libgcc to perform
       these saves and restores, thus reducing function size at the cost
       of a few extra instructions.
  
! ‘-mtls-dialect=TYPE’
!      Generate code to access thread-local storage using the ‘gnu’ or
!      ‘gnu2’ conventions.  ‘gnu’ is the conservative default; ‘gnu2’ is
       more efficient, but it may add compile- and run-time requirements
       that cannot be satisfied on all systems.
  
! ‘-mpush-args’
! ‘-mno-push-args’
       Use PUSH operations to store outgoing parameters.  This method is
       shorter and usually equally fast as method using SUB/MOV operations
       and is enabled by default.  In some cases disabling it may improve
       performance because of improved scheduling and reduced
       dependencies.
  
! ‘-maccumulate-outgoing-args’
       If enabled, the maximum amount of space required for outgoing
       arguments is computed in the function prologue.  This is faster on
       most modern CPUs because of reduced dependencies, improved
       scheduling and reduced stack usage when the preferred stack
       boundary is not equal to 2.  The drawback is a notable increase in
!      code size.  This switch implies ‘-mno-push-args’.
  
! ‘-mthreads’
       Support thread-safe exception handling on MinGW. Programs that rely
       on thread-safe exception handling must compile and link all code
!      with the ‘-mthreads’ option.  When compiling, ‘-mthreads’ defines
!      ‘-D_MT’; when linking, it links in a special thread helper library
!      ‘-lmingwthrd’ which cleans up per-thread exception-handling data.
  
! ‘-mms-bitfields’
! ‘-mno-ms-bitfields’
  
       Enable/disable bit-field layout compatible with the native
       Microsoft Windows compiler.
  
!      If ‘packed’ is used on a structure, or if bit-fields are used, it
       may be that the Microsoft ABI lays out the structure differently
       than the way GCC normally does.  Particularly when moving packed
       data between functions compiled with GCC and the native Microsoft
*************** These '-m' options are defined for the x
*** 30848,30854 ****
         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
--- 30857,30863 ----
         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
*************** These '-m' options are defined for the x
*** 30876,30888 ****
                    unsigned long bf_2 : 12;
                  } t1;
  
!           The size of 't1' is 8 bytes with the zero-length bit-field.
!           If the zero-length bit-field were removed, 't1''s size would
            be 4 bytes.
  
         2. If a zero-length bit-field is inserted after a bit-field,
!           'foo', and the alignment of the zero-length bit-field is
!           greater than the member that follows it, 'bar', 'bar' is
            aligned as the type of the zero-length bit-field.
  
            For example:
--- 30885,30897 ----
                    unsigned long bf_2 : 12;
                  } t1;
  
!           The size of ‘t1’ is 8 bytes with the zero-length bit-field.
!           If the zero-length bit-field were removed, ‘t1’'s size would
            be 4 bytes.
  
         2. If a zero-length bit-field is inserted after a bit-field,
!           ‘foo’, and the alignment of the zero-length bit-field is
!           greater than the member that follows it, ‘bar’, ‘bar’ is
            aligned as the type of the zero-length bit-field.
  
            For example:
*************** These '-m' options are defined for the x
*** 30901,30909 ****
                    double bar;
                  } t3;
  
!           For 't2', 'bar' is placed at offset 2, rather than offset 1.
!           Accordingly, the size of 't2' is 4.  For 't3', the zero-length
!           bit-field does not affect the alignment of 'bar' or, as a
            result, the size of the structure.
  
            Taking this into account, it is important to note the
--- 30910,30918 ----
                    double bar;
                  } t3;
  
!           For ‘t2’, ‘bar’ is placed at offset 2, rather than offset 1.
!           Accordingly, the size of ‘t2’ is 4.  For ‘t3’, the zero-length
!           bit-field does not affect the alignment of ‘bar’ or, as a
            result, the size of the structure.
  
            Taking this into account, it is important to note the
*************** These '-m' options are defined for the x
*** 30911,30917 ****
  
              1. If a zero-length bit-field follows a normal bit-field,
                 the type of the zero-length bit-field may affect the
!                alignment of the structure as whole.  For example, 't2'
                 has a size of 4 bytes, since the zero-length bit-field
                 follows a normal bit-field, and is of type short.
  
--- 30920,30926 ----
  
              1. If a zero-length bit-field follows a normal bit-field,
                 the type of the zero-length bit-field may affect the
!                alignment of the structure as whole.  For example, ‘t2’
                 has a size of 4 bytes, since the zero-length bit-field
                 follows a normal bit-field, and is of type short.
  
*************** These '-m' options are defined for the x
*** 30925,30931 ****
                         long : 0;
                       } t4;
  
!                Here, 't4' takes up 4 bytes.
  
         3. Zero-length bit-fields following non-bit-field members are
            ignored:
--- 30934,30940 ----
                         long : 0;
                       } t4;
  
!                Here, ‘t4’ takes up 4 bytes.
  
         3. Zero-length bit-fields following non-bit-field members are
            ignored:
*************** These '-m' options are defined for the x
*** 30937,31061 ****
                    char bar;
                  } t5;
  
!           Here, 't5' takes up 2 bytes.
  
! '-mno-align-stringops'
       Do not align the destination of inlined string operations.  This
       switch reduces code size and improves performance in case the
       destination is already aligned, but GCC doesn't know about it.
  
! '-minline-all-stringops'
       By default GCC inlines string operations only when the destination
       is known to be aligned to least a 4-byte boundary.  This enables
       more inlining and increases code size, but may improve performance
!      of code that depends on fast 'memcpy' and 'memset' for short
!      lengths.  The option enables inline expansion of 'strlen' for all
       pointer alignments.
  
! '-minline-stringops-dynamically'
       For string operations of unknown size, use run-time checks with
       inline code for small blocks and a library call for large blocks.
  
! '-mstringop-strategy=ALG'
       Override the internal decision heuristic for the particular
       algorithm to use for inlining string operations.  The allowed
       values for ALG are:
  
!      'rep_byte'
!      'rep_4byte'
!      'rep_8byte'
!           Expand using i386 'rep' prefix of the specified size.
  
!      'byte_loop'
!      'loop'
!      'unrolled_loop'
            Expand into an inline loop.
  
!      'libcall'
            Always use a library call.
  
! '-mmemcpy-strategy=STRATEGY'
       Override the internal decision heuristic to decide if
!      '__builtin_memcpy' should be inlined and what inline algorithm to
       use when the expected size of the copy operation is known.
       STRATEGY is a comma-separated list of ALG:MAX_SIZE:DEST_ALIGN
!      triplets.  ALG is specified in '-mstringop-strategy', MAX_SIZE
       specifies the max byte size with which inline algorithm ALG is
!      allowed.  For the last triplet, the MAX_SIZE must be '-1'.  The
       MAX_SIZE of the triplets in the list must be specified in
!      increasing order.  The minimal byte size for ALG is '0' for the
!      first triplet and 'MAX_SIZE + 1' of the preceding range.
  
! '-mmemset-strategy=STRATEGY'
!      The option is similar to '-mmemcpy-strategy=' except that it is to
!      control '__builtin_memset' expansion.
  
! '-momit-leaf-frame-pointer'
       Don't keep the frame pointer in a register for leaf functions.
       This avoids the instructions to save, set up, and restore frame
       pointers and makes an extra register available in leaf functions.
!      The option '-fomit-leaf-frame-pointer' removes the frame pointer
       for leaf functions, which might make debugging harder.
  
! '-mtls-direct-seg-refs'
! '-mno-tls-direct-seg-refs'
       Controls whether TLS variables may be accessed with offsets from
!      the TLS segment register ('%gs' for 32-bit, '%fs' for 64-bit), or
       whether the thread base pointer must be added.  Whether or not this
       is valid depends on the operating system, and whether it maps the
       segment to cover the entire TLS area.
  
       For systems that use the GNU C Library, the default is on.
  
! '-msse2avx'
! '-mno-sse2avx'
       Specify that the assembler should encode SSE instructions with VEX
!      prefix.  The option '-mavx' turns this on by default.
  
! '-mfentry'
! '-mno-fentry'
!      If profiling is active ('-pg'), put the profiling counter call
       before the prologue.  Note: On x86 architectures the attribute
!      'ms_hook_prologue' isn't possible at the moment for '-mfentry' and
!      '-pg'.
  
! '-mrecord-mcount'
! '-mno-record-mcount'
!      If profiling is active ('-pg'), generate a __mcount_loc section
       that contains pointers to each profiling call.  This is useful for
       automatically patching and out calls.
  
! '-mnop-mcount'
! '-mno-nop-mcount'
!      If profiling is active ('-pg'), generate the calls to the profiling
       functions as NOPs.  This is useful when they should be patched in
       later dynamically.  This is likely only useful together with
!      '-mrecord-mcount'.
  
! '-minstrument-return=TYPE'
       Instrument function exit in -pg -mfentry instrumented functions
       with call to specified function.  This only instruments true
       returns ending with ret, but not sibling calls ending with jump.
       Valid types are NONE to not instrument, CALL to generate a call to
       __return__, or NOP5 to generate a 5 byte nop.
  
! '-mrecord-return'
! '-mno-record-return'
       Generate a __return_loc section pointing to all return
       instrumentation code.
  
! '-mfentry-name=NAME'
       Set name of __fentry__ symbol called at function entry for -pg
       -mfentry functions.
  
! '-mfentry-section=NAME'
       Set name of section to record -mrecord-mcount calls (default
       __mcount_loc).
  
! '-mskip-rax-setup'
! '-mno-skip-rax-setup'
       When generating code for the x86-64 architecture with SSE
!      extensions disabled, '-mskip-rax-setup' can be used to skip setting
       up RAX register when there are no variable arguments passed in
       vector registers.
  
--- 30946,31070 ----
                    char bar;
                  } t5;
  
!           Here, ‘t5’ takes up 2 bytes.
  
! ‘-mno-align-stringops’
       Do not align the destination of inlined string operations.  This
       switch reduces code size and improves performance in case the
       destination is already aligned, but GCC doesn't know about it.
  
! ‘-minline-all-stringops’
       By default GCC inlines string operations only when the destination
       is known to be aligned to least a 4-byte boundary.  This enables
       more inlining and increases code size, but may improve performance
!      of code that depends on fast ‘memcpy’ and ‘memset’ for short
!      lengths.  The option enables inline expansion of ‘strlen’ for all
       pointer alignments.
  
! ‘-minline-stringops-dynamically’
       For string operations of unknown size, use run-time checks with
       inline code for small blocks and a library call for large blocks.
  
! ‘-mstringop-strategy=ALG’
       Override the internal decision heuristic for the particular
       algorithm to use for inlining string operations.  The allowed
       values for ALG are:
  
!      ‘rep_byte’
!      ‘rep_4byte’
!      ‘rep_8byte’
!           Expand using i386 ‘rep’ prefix of the specified size.
  
!      ‘byte_loop’
!      ‘loop’
!      ‘unrolled_loop’
            Expand into an inline loop.
  
!      ‘libcall’
            Always use a library call.
  
! ‘-mmemcpy-strategy=STRATEGY’
       Override the internal decision heuristic to decide if
!      ‘__builtin_memcpy’ should be inlined and what inline algorithm to
       use when the expected size of the copy operation is known.
       STRATEGY is a comma-separated list of ALG:MAX_SIZE:DEST_ALIGN
!      triplets.  ALG is specified in ‘-mstringop-strategy’, MAX_SIZE
       specifies the max byte size with which inline algorithm ALG is
!      allowed.  For the last triplet, the MAX_SIZE must be ‘-1’.  The
       MAX_SIZE of the triplets in the list must be specified in
!      increasing order.  The minimal byte size for ALG is ‘0’ for the
!      first triplet and ‘MAX_SIZE + 1’ of the preceding range.
  
! ‘-mmemset-strategy=STRATEGY’
!      The option is similar to ‘-mmemcpy-strategy=’ except that it is to
!      control ‘__builtin_memset’ expansion.
  
! ‘-momit-leaf-frame-pointer’
       Don't keep the frame pointer in a register for leaf functions.
       This avoids the instructions to save, set up, and restore frame
       pointers and makes an extra register available in leaf functions.
!      The option ‘-fomit-leaf-frame-pointer’ removes the frame pointer
       for leaf functions, which might make debugging harder.
  
! ‘-mtls-direct-seg-refs’
! ‘-mno-tls-direct-seg-refs’
       Controls whether TLS variables may be accessed with offsets from
!      the TLS segment register (‘%gs’ for 32-bit, ‘%fs’ for 64-bit), or
       whether the thread base pointer must be added.  Whether or not this
       is valid depends on the operating system, and whether it maps the
       segment to cover the entire TLS area.
  
       For systems that use the GNU C Library, the default is on.
  
! ‘-msse2avx’
! ‘-mno-sse2avx’
       Specify that the assembler should encode SSE instructions with VEX
!      prefix.  The option ‘-mavx’ turns this on by default.
  
! ‘-mfentry’
! ‘-mno-fentry’
!      If profiling is active (‘-pg’), put the profiling counter call
       before the prologue.  Note: On x86 architectures the attribute
!      ‘ms_hook_prologue’ isn't possible at the moment for ‘-mfentry’ and
!      ‘-pg’.
  
! ‘-mrecord-mcount’
! ‘-mno-record-mcount’
!      If profiling is active (‘-pg’), generate a __mcount_loc section
       that contains pointers to each profiling call.  This is useful for
       automatically patching and out calls.
  
! ‘-mnop-mcount’
! ‘-mno-nop-mcount’
!      If profiling is active (‘-pg’), generate the calls to the profiling
       functions as NOPs.  This is useful when they should be patched in
       later dynamically.  This is likely only useful together with
!      ‘-mrecord-mcount’.
  
! ‘-minstrument-return=TYPE’
       Instrument function exit in -pg -mfentry instrumented functions
       with call to specified function.  This only instruments true
       returns ending with ret, but not sibling calls ending with jump.
       Valid types are NONE to not instrument, CALL to generate a call to
       __return__, or NOP5 to generate a 5 byte nop.
  
! ‘-mrecord-return’
! ‘-mno-record-return’
       Generate a __return_loc section pointing to all return
       instrumentation code.
  
! ‘-mfentry-name=NAME’
       Set name of __fentry__ symbol called at function entry for -pg
       -mfentry functions.
  
! ‘-mfentry-section=NAME’
       Set name of section to record -mrecord-mcount calls (default
       __mcount_loc).
  
! ‘-mskip-rax-setup’
! ‘-mno-skip-rax-setup’
       When generating code for the x86-64 architecture with SSE
!      extensions disabled, ‘-mskip-rax-setup’ can be used to skip setting
       up RAX register when there are no variable arguments passed in
       vector registers.
  
*************** These '-m' options are defined for the x
*** 31065,31257 ****
       misbehave or jump to a random location.  GCC 4.4 or newer don't
       have those issues, regardless the RAX register value.
  
! '-m8bit-idiv'
! '-mno-8bit-idiv'
       On some processors, like Intel Atom, 8-bit unsigned integer divide
       is much faster than 32-bit/64-bit integer divide.  This option
       generates a run-time check.  If both dividend and divisor are
       within range of 0 to 255, 8-bit unsigned integer divide is used
       instead of 32-bit/64-bit integer divide.
  
! '-mavx256-split-unaligned-load'
! '-mavx256-split-unaligned-store'
       Split 32-byte AVX unaligned load and store.
  
! '-mstack-protector-guard=GUARD'
! '-mstack-protector-guard-reg=REG'
! '-mstack-protector-guard-offset=OFFSET'
       Generate stack protection code using canary at GUARD.  Supported
!      locations are 'global' for global canary or 'tls' for per-thread
       canary in the TLS block (the default).  This option has effect only
!      when '-fstack-protector' or '-fstack-protector-all' is specified.
  
       With the latter choice the options
!      '-mstack-protector-guard-reg=REG' and
!      '-mstack-protector-guard-offset=OFFSET' furthermore specify which
!      segment register ('%fs' or '%gs') to use as base register for
       reading the canary, and from what offset from that base register.
       The default for those is as specified in the relevant ABI.
  
! '-mgeneral-regs-only'
       Generate code that uses only the general-purpose registers.  This
       prevents the compiler from using floating-point, vector, mask and
       bound registers.
  
! '-mrelax-cmpxchg-loop'
       When emitting a compare-and-swap loop for *note __sync Builtins::
       and *note __atomic Builtins:: lacking a native instruction,
       optimize for the highly contended case by issuing an atomic load
!      before the 'CMPXCHG' instruction, and using the 'PAUSE' instruction
       to save CPU power when restarting the loop.
  
! '-mindirect-branch=CHOICE'
!      Convert indirect call and jump with CHOICE.  The default is 'keep',
!      which keeps indirect call and jump unmodified.  'thunk' converts
!      indirect call and jump to call and return thunk.  'thunk-inline'
       converts indirect call and jump to inlined call and return thunk.
!      'thunk-extern' converts indirect call and jump to external call and
       return thunk provided in a separate object file.  You can control
       this behavior for a specific function by using the function
!      attribute 'indirect_branch'.  *Note Function Attributes::.
  
!      Note that '-mcmodel=large' is incompatible with
!      '-mindirect-branch=thunk' and '-mindirect-branch=thunk-extern'
       since the thunk function may not be reachable in the large code
       model.
  
!      Note that '-mindirect-branch=thunk-extern' is compatible with
!      '-fcf-protection=branch' since the external thunk can be made to
       enable control-flow check.
  
! '-mfunction-return=CHOICE'
!      Convert function return with CHOICE.  The default is 'keep', which
!      keeps function return unmodified.  'thunk' converts function return
!      to call and return thunk.  'thunk-inline' converts function return
!      to inlined call and return thunk.  'thunk-extern' converts function
       return to external call and return thunk provided in a separate
       object file.  You can control this behavior for a specific function
!      by using the function attribute 'function_return'.  *Note Function
       Attributes::.
  
!      Note that '-mindirect-return=thunk-extern' is compatible with
!      '-fcf-protection=branch' since the external thunk can be made to
       enable control-flow check.
  
!      Note that '-mcmodel=large' is incompatible with
!      '-mfunction-return=thunk' and '-mfunction-return=thunk-extern'
       since the thunk function may not be reachable in the large code
       model.
  
! '-mindirect-branch-register'
       Force indirect call and jump via register.
  
! '-mharden-sls=CHOICE'
       Generate code to mitigate against straight line speculation (SLS)
!      with CHOICE.  The default is 'none' which disables all SLS
!      hardening.  'return' enables SLS hardening for function returns.
!      'indirect-jmp' enables SLS hardening for indirect jumps.  'all'
       enables all SLS hardening.
  
! '-mindirect-branch-cs-prefix'
       Add CS prefix to call and jmp to indirect thunk with branch target
       in r8-r15 registers so that the call and jmp instruction length is
!      6 bytes to allow them to be replaced with 'lfence; call *%r8-r15'
!      or 'lfence; jmp *%r8-r15' at run-time.
  
!  These '-m' switches are supported in addition to the above on x86-64
  processors in 64-bit environments.
  
! '-m32'
! '-m64'
! '-mx32'
! '-m16'
! '-miamcu'
       Generate code for a 16-bit, 32-bit or 64-bit environment.  The
!      '-m32' option sets 'int', 'long', and pointer types to 32 bits, and
       generates code that runs in 32-bit mode.
  
!      The '-m64' option sets 'int' to 32 bits and 'long' and pointer
       types to 64 bits, and generates code for the x86-64 architecture.
!      For Darwin only the '-m64' option also turns off the '-fno-pic' and
!      '-mdynamic-no-pic' options.
  
!      The '-mx32' option sets 'int', 'long', and pointer types to 32
       bits, and generates code for the x86-64 architecture.
  
!      The '-m16' option is the same as '-m32', except for that it outputs
!      the '.code16gcc' assembly directive at the beginning of the
       assembly output so that the binary can run in 16-bit mode.
  
!      The '-miamcu' option generates code which conforms to Intel MCU
!      psABI. It requires the '-m32' option to be turned on.
  
! '-mno-red-zone'
       Do not use a so-called "red zone" for x86-64 code.  The red zone is
       mandated by the x86-64 ABI; it is a 128-byte area beyond the
       location of the stack pointer that is not modified by signal or
       interrupt handlers and therefore can be used for temporary data
!      without adjusting the stack pointer.  The flag '-mno-red-zone'
       disables this red zone.
  
! '-mcmodel=small'
       Generate code for the small code model: the program and its symbols
       must be linked in the lower 2 GB of the address space.  Pointers
       are 64 bits.  Programs can be statically or dynamically linked.
       This is the default code model.
  
! '-mcmodel=kernel'
       Generate code for the kernel code model.  The kernel runs in the
       negative 2 GB of the address space.  This model has to be used for
       Linux kernel code.
  
! '-mcmodel=medium'
       Generate code for the medium model: the program is linked in the
       lower 2 GB of the address space.  Small symbols are also placed
!      there.  Symbols with sizes larger than '-mlarge-data-threshold' are
       put into large data or BSS sections and can be located above 2GB.
       Programs can be statically or dynamically linked.
  
! '-mcmodel=large'
       Generate code for the large model.  This model makes no assumptions
       about addresses and sizes of sections.
  
! '-maddress-mode=long'
       Generate code for long address mode.  This is only supported for
       64-bit and x32 environments.  It is the default address mode for
       64-bit environments.
  
! '-maddress-mode=short'
       Generate code for short address mode.  This is only supported for
       32-bit and x32 environments.  It is the default address mode for
       32-bit and x32 environments.
  
! '-mneeded'
! '-mno-needed'
       Emit GNU_PROPERTY_X86_ISA_1_NEEDED GNU property for Linux target to
       indicate the micro-architecture ISA level required to execute the
       binary.
  
! '-mno-direct-extern-access'
!      Without '-fpic' nor '-fPIC', always use the GOT pointer to access
!      external symbols.  With '-fpic' or '-fPIC', treat access to
       protected symbols as local symbols.  The default is
!      '-mdirect-extern-access'.
  
       *Warning:* shared libraries compiled with
!      '-mno-direct-extern-access' and executable compiled with
!      '-mdirect-extern-access' may not be binary compatible if protected
       symbols are used in shared libraries and executable.
  
! '-munroll-only-small-loops'
       Controls conservative small loop unrolling.  It is default enabled
       by O2, and unrolls loop with less than 4 insns by 1 time.  Explicit
       -f[no-]unroll-[all-]loops would disable this flag to avoid any
       unintended unrolling behavior that user does not want.
  
! '-mlam=CHOICE'
       LAM(linear-address masking) allows special bits in the pointer to
!      be used for metadata.  The default is 'none'.  With 'u48', pointer
!      bits in positions 62:48 can be used for metadata; With 'u57',
       pointer bits in positions 62:57 can be used for metadata.
  
  
--- 31074,31266 ----
       misbehave or jump to a random location.  GCC 4.4 or newer don't
       have those issues, regardless the RAX register value.
  
! ‘-m8bit-idiv’
! ‘-mno-8bit-idiv’
       On some processors, like Intel Atom, 8-bit unsigned integer divide
       is much faster than 32-bit/64-bit integer divide.  This option
       generates a run-time check.  If both dividend and divisor are
       within range of 0 to 255, 8-bit unsigned integer divide is used
       instead of 32-bit/64-bit integer divide.
  
! ‘-mavx256-split-unaligned-load’
! ‘-mavx256-split-unaligned-store’
       Split 32-byte AVX unaligned load and store.
  
! ‘-mstack-protector-guard=GUARD’
! ‘-mstack-protector-guard-reg=REG’
! ‘-mstack-protector-guard-offset=OFFSET’
       Generate stack protection code using canary at GUARD.  Supported
!      locations are ‘global’ for global canary or ‘tls’ for per-thread
       canary in the TLS block (the default).  This option has effect only
!      when ‘-fstack-protector’ or ‘-fstack-protector-all’ is specified.
  
       With the latter choice the options
!      ‘-mstack-protector-guard-reg=REG’ and
!      ‘-mstack-protector-guard-offset=OFFSET’ furthermore specify which
!      segment register (‘%fs’ or ‘%gs’) to use as base register for
       reading the canary, and from what offset from that base register.
       The default for those is as specified in the relevant ABI.
  
! ‘-mgeneral-regs-only’
       Generate code that uses only the general-purpose registers.  This
       prevents the compiler from using floating-point, vector, mask and
       bound registers.
  
! ‘-mrelax-cmpxchg-loop’
       When emitting a compare-and-swap loop for *note __sync Builtins::
       and *note __atomic Builtins:: lacking a native instruction,
       optimize for the highly contended case by issuing an atomic load
!      before the ‘CMPXCHG’ instruction, and using the ‘PAUSE’ instruction
       to save CPU power when restarting the loop.
  
! ‘-mindirect-branch=CHOICE’
!      Convert indirect call and jump with CHOICE.  The default is ‘keep’,
!      which keeps indirect call and jump unmodified.  ‘thunk’ converts
!      indirect call and jump to call and return thunk.  ‘thunk-inline’
       converts indirect call and jump to inlined call and return thunk.
!      ‘thunk-extern’ converts indirect call and jump to external call and
       return thunk provided in a separate object file.  You can control
       this behavior for a specific function by using the function
!      attribute ‘indirect_branch’.  *Note Function Attributes::.
  
!      Note that ‘-mcmodel=large’ is incompatible with
!      ‘-mindirect-branch=thunk’ and ‘-mindirect-branch=thunk-extern’
       since the thunk function may not be reachable in the large code
       model.
  
!      Note that ‘-mindirect-branch=thunk-extern’ is compatible with
!      ‘-fcf-protection=branch’ since the external thunk can be made to
       enable control-flow check.
  
! ‘-mfunction-return=CHOICE’
!      Convert function return with CHOICE.  The default is ‘keep’, which
!      keeps function return unmodified.  ‘thunk’ converts function return
!      to call and return thunk.  ‘thunk-inline’ converts function return
!      to inlined call and return thunk.  ‘thunk-extern’ converts function
       return to external call and return thunk provided in a separate
       object file.  You can control this behavior for a specific function
!      by using the function attribute ‘function_return’.  *Note Function
       Attributes::.
  
!      Note that ‘-mindirect-return=thunk-extern’ is compatible with
!      ‘-fcf-protection=branch’ since the external thunk can be made to
       enable control-flow check.
  
!      Note that ‘-mcmodel=large’ is incompatible with
!      ‘-mfunction-return=thunk’ and ‘-mfunction-return=thunk-extern’
       since the thunk function may not be reachable in the large code
       model.
  
! ‘-mindirect-branch-register’
       Force indirect call and jump via register.
  
! ‘-mharden-sls=CHOICE’
       Generate code to mitigate against straight line speculation (SLS)
!      with CHOICE.  The default is ‘none’ which disables all SLS
!      hardening.  ‘return’ enables SLS hardening for function returns.
!      ‘indirect-jmp’ enables SLS hardening for indirect jumps.  ‘all’
       enables all SLS hardening.
  
! ‘-mindirect-branch-cs-prefix’
       Add CS prefix to call and jmp to indirect thunk with branch target
       in r8-r15 registers so that the call and jmp instruction length is
!      6 bytes to allow them to be replaced with ‘lfence; call *%r8-r15’
!      or ‘lfence; jmp *%r8-r15’ at run-time.
  
!  These ‘-m’ switches are supported in addition to the above on x86-64
  processors in 64-bit environments.
  
! ‘-m32’
! ‘-m64’
! ‘-mx32’
! ‘-m16’
! ‘-miamcu’
       Generate code for a 16-bit, 32-bit or 64-bit environment.  The
!      ‘-m32’ option sets ‘int’, ‘long’, and pointer types to 32 bits, and
       generates code that runs in 32-bit mode.
  
!      The ‘-m64’ option sets ‘int’ to 32 bits and ‘long’ and pointer
       types to 64 bits, and generates code for the x86-64 architecture.
!      For Darwin only the ‘-m64’ option also turns off the ‘-fno-pic’ and
!      ‘-mdynamic-no-pic’ options.
  
!      The ‘-mx32’ option sets ‘int’, ‘long’, and pointer types to 32
       bits, and generates code for the x86-64 architecture.
  
!      The ‘-m16’ option is the same as ‘-m32’, except for that it outputs
!      the ‘.code16gcc’ assembly directive at the beginning of the
       assembly output so that the binary can run in 16-bit mode.
  
!      The ‘-miamcu’ option generates code which conforms to Intel MCU
!      psABI. It requires the ‘-m32’ option to be turned on.
  
! ‘-mno-red-zone’
       Do not use a so-called "red zone" for x86-64 code.  The red zone is
       mandated by the x86-64 ABI; it is a 128-byte area beyond the
       location of the stack pointer that is not modified by signal or
       interrupt handlers and therefore can be used for temporary data
!      without adjusting the stack pointer.  The flag ‘-mno-red-zone’
       disables this red zone.
  
! ‘-mcmodel=small’
       Generate code for the small code model: the program and its symbols
       must be linked in the lower 2 GB of the address space.  Pointers
       are 64 bits.  Programs can be statically or dynamically linked.
       This is the default code model.
  
! ‘-mcmodel=kernel’
       Generate code for the kernel code model.  The kernel runs in the
       negative 2 GB of the address space.  This model has to be used for
       Linux kernel code.
  
! ‘-mcmodel=medium’
       Generate code for the medium model: the program is linked in the
       lower 2 GB of the address space.  Small symbols are also placed
!      there.  Symbols with sizes larger than ‘-mlarge-data-threshold’ are
       put into large data or BSS sections and can be located above 2GB.
       Programs can be statically or dynamically linked.
  
! ‘-mcmodel=large’
       Generate code for the large model.  This model makes no assumptions
       about addresses and sizes of sections.
  
! ‘-maddress-mode=long’
       Generate code for long address mode.  This is only supported for
       64-bit and x32 environments.  It is the default address mode for
       64-bit environments.
  
! ‘-maddress-mode=short’
       Generate code for short address mode.  This is only supported for
       32-bit and x32 environments.  It is the default address mode for
       32-bit and x32 environments.
  
! ‘-mneeded’
! ‘-mno-needed’
       Emit GNU_PROPERTY_X86_ISA_1_NEEDED GNU property for Linux target to
       indicate the micro-architecture ISA level required to execute the
       binary.
  
! ‘-mno-direct-extern-access’
!      Without ‘-fpic’ nor ‘-fPIC’, always use the GOT pointer to access
!      external symbols.  With ‘-fpic’ or ‘-fPIC’, treat access to
       protected symbols as local symbols.  The default is
!      ‘-mdirect-extern-access’.
  
       *Warning:* shared libraries compiled with
!      ‘-mno-direct-extern-access’ and executable compiled with
!      ‘-mdirect-extern-access’ may not be binary compatible if protected
       symbols are used in shared libraries and executable.
  
! ‘-munroll-only-small-loops’
       Controls conservative small loop unrolling.  It is default enabled
       by O2, and unrolls loop with less than 4 insns by 1 time.  Explicit
       -f[no-]unroll-[all-]loops would disable this flag to avoid any
       unintended unrolling behavior that user does not want.
  
! ‘-mlam=CHOICE’
       LAM(linear-address masking) allows special bits in the pointer to
!      be used for metadata.  The default is ‘none’.  With ‘u48’, pointer
!      bits in positions 62:48 can be used for metadata; With ‘u57’,
       pointer bits in positions 62:57 can be used for metadata.
  
  
*************** File: gcc.info,  Node: x86 Windows Optio
*** 31262,31318 ****
  
  These additional options are available for Microsoft Windows targets:
  
! '-mconsole'
       This option specifies that a console application is to be
       generated, by instructing the linker to set the PE header subsystem
       type required for console applications.  This option is available
       for Cygwin and MinGW targets and is enabled by default on those
       targets.
  
! '-mdll'
       This option is available for Cygwin and MinGW targets.  It
       specifies that a DLL--a dynamic link library--is to be generated,
       enabling the selection of the required runtime startup object and
       entry point.
  
! '-mnop-fun-dllimport'
       This option is available for Cygwin and MinGW targets.  It
!      specifies that the 'dllimport' attribute should be ignored.
  
! '-mthreads'
       This option is available for MinGW targets.  It specifies that
       MinGW-specific thread support is to be used.
  
! '-municode'
       This option is available for MinGW-w64 targets.  It causes the
!      'UNICODE' preprocessor macro to be predefined, and chooses
       Unicode-capable runtime startup code.
  
! '-mwin32'
       This option is available for Cygwin and MinGW targets.  It
       specifies that the typical Microsoft Windows predefined macros are
       to be set in the pre-processor, but does not influence the choice
       of runtime library/startup code.
  
! '-mwindows'
       This option is available for Cygwin and MinGW targets.  It
       specifies that a GUI application is to be generated by instructing
       the linker to set the PE header subsystem type appropriately.
  
! '-fno-set-stack-executable'
       This option is available for MinGW targets.  It specifies that the
       executable flag for the stack used by nested functions isn't set.
       This is necessary for binaries running in kernel mode of Microsoft
       Windows, as there the User32 API, which is used to set executable
       privileges, isn't available.
  
! '-fwritable-relocated-rdata'
       This option is available for MinGW and Cygwin targets.  It
       specifies that relocated-data in read-only section is put into the
!      '.data' section.  This is a necessary for older runtimes not
!      supporting modification of '.rdata' sections for pseudo-relocation.
  
! '-mpe-aligned-commons'
       This option is available for Cygwin and MinGW targets.  It
       specifies that the GNU extension to the PE file format that permits
       the correct alignment of COMMON variables should be used when
--- 31271,31327 ----
  
  These additional options are available for Microsoft Windows targets:
  
! ‘-mconsole’
       This option specifies that a console application is to be
       generated, by instructing the linker to set the PE header subsystem
       type required for console applications.  This option is available
       for Cygwin and MinGW targets and is enabled by default on those
       targets.
  
! ‘-mdll’
       This option is available for Cygwin and MinGW targets.  It
       specifies that a DLL--a dynamic link library--is to be generated,
       enabling the selection of the required runtime startup object and
       entry point.
  
! ‘-mnop-fun-dllimport’
       This option is available for Cygwin and MinGW targets.  It
!      specifies that the ‘dllimport’ attribute should be ignored.
  
! ‘-mthreads’
       This option is available for MinGW targets.  It specifies that
       MinGW-specific thread support is to be used.
  
! ‘-municode’
       This option is available for MinGW-w64 targets.  It causes the
!      ‘UNICODE’ preprocessor macro to be predefined, and chooses
       Unicode-capable runtime startup code.
  
! ‘-mwin32’
       This option is available for Cygwin and MinGW targets.  It
       specifies that the typical Microsoft Windows predefined macros are
       to be set in the pre-processor, but does not influence the choice
       of runtime library/startup code.
  
! ‘-mwindows’
       This option is available for Cygwin and MinGW targets.  It
       specifies that a GUI application is to be generated by instructing
       the linker to set the PE header subsystem type appropriately.
  
! ‘-fno-set-stack-executable’
       This option is available for MinGW targets.  It specifies that the
       executable flag for the stack used by nested functions isn't set.
       This is necessary for binaries running in kernel mode of Microsoft
       Windows, as there the User32 API, which is used to set executable
       privileges, isn't available.
  
! ‘-fwritable-relocated-rdata’
       This option is available for MinGW and Cygwin targets.  It
       specifies that relocated-data in read-only section is put into the
!      ‘.data’ section.  This is a necessary for older runtimes not
!      supporting modification of ‘.rdata’ sections for pseudo-relocation.
  
! ‘-mpe-aligned-commons’
       This option is available for Cygwin and MinGW targets.  It
       specifies that the GNU extension to the PE file format that permits
       the correct alignment of COMMON variables should be used when
*************** File: gcc.info,  Node: Xstormy16 Options
*** 31329,31335 ****
  
  These options are defined for Xstormy16:
  
! '-msim'
       Choose startup files and linker script suitable for the simulator.
  
  
--- 31338,31344 ----
  
  These options are defined for Xstormy16:
  
! ‘-msim’
       Choose startup files and linker script suitable for the simulator.
  
  
*************** File: gcc.info,  Node: Xtensa Options,
*** 31340,31356 ****
  
  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
--- 31349,31365 ----
  
  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
*************** These options are supported for Xtensa t
*** 31365,31431 ****
       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'
       These options 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.
       Literals for each function are placed right before that function.
  
! '-mauto-litpools'
! '-mno-auto-litpools'
       These options control the treatment of literal pools.  The default
!      is '-mno-auto-litpools', which places literals in a separate
!      section in the output file unless '-mtext-section-literals' is
!      used.  With '-mauto-litpools' the literals are interspersed in the
       text section by the assembler.  Compiler does not produce explicit
!      '.literal' directives and loads literals into registers with 'MOVI'
!      instructions instead of 'L32R' to let the assembler do relaxation
       and place literals as necessary.  This option allows assembler to
       create several literal pools per function and assemble very big
       functions, which may not be possible with
!      '-mtext-section-literals'.
  
! '-mtarget-align'
! '-mno-target-align'
       When this option is enabled, GCC instructs the assembler to
       automatically align instructions to reduce branch penalties at the
       expense of some code density.  The assembler attempts to widen
       density instructions to align branch targets and the instructions
       following call instructions.  If there are not enough preceding
       safe density instructions to align a target, no widening is
!      performed.  The default is '-mtarget-align'.  These options do not
!      affect the treatment of auto-aligned instructions like 'LOOP',
       which the assembler always aligns, either by widening density
       instructions or by inserting NOP instructions.
  
! '-mlongcalls'
! '-mno-longcalls'
       When this option is enabled, GCC instructs the assembler to
       translate direct calls to indirect calls unless it can determine
       that the target of a direct call is in the range allowed by the
       call instruction.  This translation typically occurs for calls to
       functions in other source files.  Specifically, the assembler
!      translates a direct 'CALL' instruction into an 'L32R' followed by a
!      'CALLX' instruction.  The default is '-mno-longcalls'.  This option
       should be used in programs where the call target can potentially be
       out of range.  This option is implemented in the assembler, not the
       compiler, so the assembly code generated by GCC still shows direct
--- 31374,31440 ----
       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’
       These options 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.
       Literals for each function are placed right before that function.
  
! ‘-mauto-litpools’
! ‘-mno-auto-litpools’
       These options control the treatment of literal pools.  The default
!      is ‘-mno-auto-litpools’, which places literals in a separate
!      section in the output file unless ‘-mtext-section-literals’ is
!      used.  With ‘-mauto-litpools’ the literals are interspersed in the
       text section by the assembler.  Compiler does not produce explicit
!      ‘.literal’ directives and loads literals into registers with ‘MOVI’
!      instructions instead of ‘L32R’ to let the assembler do relaxation
       and place literals as necessary.  This option allows assembler to
       create several literal pools per function and assemble very big
       functions, which may not be possible with
!      ‘-mtext-section-literals’.
  
! ‘-mtarget-align’
! ‘-mno-target-align’
       When this option is enabled, GCC instructs the assembler to
       automatically align instructions to reduce branch penalties at the
       expense of some code density.  The assembler attempts to widen
       density instructions to align branch targets and the instructions
       following call instructions.  If there are not enough preceding
       safe density instructions to align a target, no widening is
!      performed.  The default is ‘-mtarget-align’.  These options do not
!      affect the treatment of auto-aligned instructions like ‘LOOP’,
       which the assembler always aligns, either by widening density
       instructions or by inserting NOP instructions.
  
! ‘-mlongcalls’
! ‘-mno-longcalls’
       When this option is enabled, GCC instructs the assembler to
       translate direct calls to indirect calls unless it can determine
       that the target of a direct call is in the range allowed by the
       call instruction.  This translation typically occurs for calls to
       functions in other source files.  Specifically, the assembler
!      translates a direct ‘CALL’ instruction into an ‘L32R’ followed by a
!      ‘CALLX’ instruction.  The default is ‘-mno-longcalls’.  This option
       should be used in programs where the call target can potentially be
       out of range.  This option is implemented in the assembler, not the
       compiler, so the assembly code generated by GCC still shows direct
*************** These options are supported for Xtensa t
*** 31434,31464 ****
       for every cross-file call, not just those that really are out of
       range.
  
! '-mabi=NAME'
       Generate code for the specified ABI.  Permissible values are:
!      'call0', 'windowed'.  Default ABI is chosen by the Xtensa core
       configuration.
  
! '-mabi=call0'
       When this option is enabled function parameters are passed in
!      registers 'a2' through 'a7', registers 'a12' through 'a15' are
!      caller-saved, and register 'a15' may be used as a frame pointer.
       When this version of the ABI is enabled the C preprocessor symbol
!      '__XTENSA_CALL0_ABI__' is defined.
  
! '-mabi=windowed'
       When this option is enabled function parameters are passed in
!      registers 'a10' through 'a15', and called function rotates register
       window by 8 registers on entry so that its arguments are found in
!      registers 'a2' through 'a7'.  Register 'a7' may be used as a frame
       pointer.  Register window is rotated 8 registers back upon return.
       When this version of the ABI is enabled the C preprocessor symbol
!      '__XTENSA_WINDOWED_ABI__' is defined.
  
! '-mextra-l32r-costs=N'
!      Specify an extra cost of instruction RAM/ROM access for 'L32R'
       instructions, in clock cycles.  This affects, when optimizing for
!      speed, whether loading a constant from literal pool using 'L32R' or
       synthesizing the constant from a small one with a couple of
       arithmetic instructions.  The default value is 0.
  
--- 31443,31473 ----
       for every cross-file call, not just those that really are out of
       range.
  
! ‘-mabi=NAME’
       Generate code for the specified ABI.  Permissible values are:
!      ‘call0’, ‘windowed’.  Default ABI is chosen by the Xtensa core
       configuration.
  
! ‘-mabi=call0’
       When this option is enabled function parameters are passed in
!      registers ‘a2’ through ‘a7’, registers ‘a12’ through ‘a15’ are
!      caller-saved, and register ‘a15’ may be used as a frame pointer.
       When this version of the ABI is enabled the C preprocessor symbol
!      ‘__XTENSA_CALL0_ABI__’ is defined.
  
! ‘-mabi=windowed’
       When this option is enabled function parameters are passed in
!      registers ‘a10’ through ‘a15’, and called function rotates register
       window by 8 registers on entry so that its arguments are found in
!      registers ‘a2’ through ‘a7’.  Register ‘a7’ may be used as a frame
       pointer.  Register window is rotated 8 registers back upon return.
       When this version of the ABI is enabled the C preprocessor symbol
!      ‘__XTENSA_WINDOWED_ABI__’ is defined.
  
! ‘-mextra-l32r-costs=N’
!      Specify an extra cost of instruction RAM/ROM access for ‘L32R’
       instructions, in clock cycles.  This affects, when optimizing for
!      speed, whether loading a constant from literal pool using ‘L32R’ or
       synthesizing the constant from a small one with a couple of
       arithmetic instructions.  The default value is 0.
  
*************** File: gcc.info,  Node: Spec Files,  Next
*** 31476,31512 ****
  3.20 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 plain-text files that are used to construct spec
  strings.  They consist of a sequence of directives separated by blank
  lines.  The type of directive is determined by the first non-whitespace
  character on the line, which can be one of the following:
  
! '%COMMAND'
       Issues a COMMAND to the spec file processor.  The commands that can
       appear here are:
  
!      '%include '
            Search for FILE and insert its text at the current point in
            the specs file.
  
!      '%include_noerr '
!           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
--- 31485,31521 ----
  3.20 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 plain-text files that are used to construct spec
  strings.  They consist of a sequence of directives separated by blank
  lines.  The type of directive is determined by the first non-whitespace
  character on the line, which can be one of the following:
  
! ‘%COMMAND’
       Issues a COMMAND to the spec file processor.  The commands that can
       appear here are:
  
!      ‘%include ’
            Search for FILE and insert its text at the current point in
            the specs file.
  
!      ‘%include_noerr ’
!           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
*************** character on the line, which can be one
*** 31515,31525 ****
       Otherwise, if the spec does not currently exist a new spec is
       created.  If the spec does exist then its contents are overridden
       by the text of this directive, unless the first character of that
!      text is the '+' character, in which case the text is appended to
       the spec.
  
! '[SUFFIX]:'
!      Creates a new '[SUFFIX] spec' pair.  All lines after this directive
       and up to the next directive or blank line are considered to make
       up the spec string for the indicated suffix.  When the compiler
       encounters an input file with the named suffix, it processes the
--- 31524,31534 ----
       Otherwise, if the spec does not currently exist a new spec is
       created.  If the spec does exist then its contents are overridden
       by the text of this directive, unless the first character of that
!      text is the ‘+’ character, in which case the text is appended to
       the spec.
  
! ‘[SUFFIX]:’
!      Creates a new ‘[SUFFIX] spec’ pair.  All lines after this directive
       and up to the next directive or blank line are considered to make
       up the spec string for the indicated suffix.  When the compiler
       encounters an input file with the named suffix, it processes the
*************** character on the line, which can be one
*** 31529,31545 ****
            .ZZ:
            z-compile -input %i
  
!      This says that any input file whose name ends in '.ZZ' should be
!      passed to the program 'z-compile', which should be invoked with the
!      command-line switch '-input' and with the result of performing the
!      '%i' substitution.  (See below.)
  
       As an alternative to providing a spec string, the text following a
       suffix directive can be one of the following:
  
!      '@LANGUAGE'
            This says that the suffix is an alias for a known LANGUAGE.
!           This is similar to using the '-x' command-line switch to GCC
            to specify a language explicitly.  For example:
  
                 .ZZ:
--- 31538,31554 ----
            .ZZ:
            z-compile -input %i
  
!      This says that any input file whose name ends in ‘.ZZ’ should be
!      passed to the program ‘z-compile’, which should be invoked with the
!      command-line switch ‘-input’ and with the result of performing the
!      ‘%i’ substitution.  (See below.)
  
       As an alternative to providing a spec string, the text following a
       suffix directive can be one of the following:
  
!      ‘@LANGUAGE’
            This says that the suffix is an alias for a known LANGUAGE.
!           This is similar to using the ‘-x’ command-line switch to GCC
            to specify a language explicitly.  For example:
  
                 .ZZ:
*************** character on the line, which can be one
*** 31547,31553 ****
  
            Says that .ZZ files are, in fact, C++ source files.
  
!      '#NAME'
            This causes an error messages saying:
  
                 NAME compiler not installed on this system.
--- 31556,31562 ----
  
            Says that .ZZ files are, in fact, C++ source files.
  
!      ‘#NAME’
            This causes an error messages saying:
  
                 NAME compiler not installed on this system.
*************** targets can also add their own spec stri
*** 31584,31615 ****
       *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.
  
! '%"'
       Substitute an empty argument.
  
! '%i'
       Substitute the name of the input file being processed.
  
! '%b'
       Substitute the basename for outputs related with the input file
       being processed.  This is often the substring up to (and not
       including) the last period and not including the directory but,
--- 31593,31624 ----
       *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.
  
! ‘%"’
       Substitute an empty argument.
  
! ‘%i’
       Substitute the name of the input file being processed.
  
! ‘%b’
       Substitute the basename for outputs related with the input file
       being processed.  This is often the substring up to (and not
       including) the last period and not including the directory but,
*************** or combine them with constant text in a
*** 31617,31822 ****
       outputs, which may be influenced by an explicit output name, and by
       various other options that control how auxiliary outputs are named.
  
! '%B'
!      This is the same as '%b', but include the file suffix (text after
       the last period).  Without %w, it expands to the basename for dump
       outputs.
  
! '%d'
!      Marks the argument containing or following the '%d' as a temporary
       file name, so that that file is deleted if GCC exits successfully.
!      Unlike '%g', this contributes no text to the argument.
  
! '%gSUFFIX'
       Substitute a file name that has suffix SUFFIX and is chosen once
!      per compilation, and mark the argument in the same way as '%d'.  To
       reduce exposure to denial-of-service attacks, the file name is now
       chosen in a way that is hard to predict even when previously chosen
!      file names are known.  For example, '%g.s ... %g.o ... %g.s' might
!      turn into 'ccUVUUAU.s ccXYAXZ12.o ccUVUUAU.s'.  SUFFIX matches the
!      regexp '[.A-Za-z]*' or the special string '%O', which is treated
!      exactly as if '%O' had been preprocessed.  Previously, '%g' was
       simply substituted with a file name chosen once per compilation,
       without regard to any appended suffix (which was therefore treated
       just like ordinary text), making such attacks more likely to
       succeed.
  
! '%uSUFFIX'
!      Like '%g', but generates a new temporary file name each time it
       appears instead of once per compilation.
  
! '%USUFFIX'
!      Substitutes the last file name generated with '%uSUFFIX',
       generating a new one if there is no such last file name.  In the
!      absence of any '%uSUFFIX', this is just like '%gSUFFIX', except
!      they don't share the same suffix _space_, so '%g.s ... %U.s ...
!      %g.s ... %U.s' involves the generation of two distinct file names,
!      one for each '%g.s' and another for each '%U.s'.  Previously, '%U'
       was simply substituted with a file name chosen for the previous
!      '%u', without regard to any appended suffix.
  
! '%jSUFFIX'
!      Substitutes the name of the 'HOST_BIT_BUCKET', if any, and if it is
!      writable, and if '-save-temps' is not used; otherwise, substitute
!      the name of a temporary file, just like '%u'.  This temporary file
       is not meant for communication between processes, but rather as a
       junk disposal mechanism.
  
! '%|SUFFIX'
! '%mSUFFIX'
!      Like '%g', except if '-pipe' is in effect.  In that case '%|'
!      substitutes a single dash and '%m' substitutes nothing at all.
       These are the two most common ways to instruct a program that it
       should read from standard input or write to standard output.  If
!      you need something more elaborate you can use an '%{pipe:'X'}'
!      construct: see for example 'gcc/fortran/lang-specs.h'.
  
! '%.SUFFIX'
       Substitutes .SUFFIX for the suffixes of a matched switch's args
!      when it is subsequently output with '%*'.  SUFFIX is terminated by
       the next space or %.
  
! '%w'
!      Marks the argument containing or following the '%w' as the
       designated output file of this compilation.  This puts the argument
!      into the sequence of arguments that '%o' substitutes.
  
! '%V'
       Indicates that this compilation produces no output file.
  
! '%o'
       Substitutes the names of all the output files, with spaces
       automatically placed around them.  You should write spaces around
!      the '%o' as well or the results are undefined.  '%o' is for use in
       the specs for running the linker.  Input files whose names have no
       recognized suffix are not compiled at all, but they are included
       among the output files, so they are linked.
  
! '%O'
       Substitutes the suffix for object files.  Note that this is handled
!      specially when it immediately follows '%g, %u, or %U', because of
       the need for those to form complete file names.  The handling is
!      such that '%O' is treated exactly as if it had already been
!      substituted, except that '%g, %u, and %U' do not currently support
!      additional SUFFIX characters following '%O' as they do following,
!      for example, '.o'.
  
! '%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.
  
! '%nSTR'
       Print STR as a notice.  STR is terminated by a newline.
  
! '%(NAME)'
       Substitute the contents of spec string NAME at this point.
  
! '%x{OPTION}'
!      Accumulate an option for '%X'.
  
! '%X'
!      Output the accumulated linker options specified by a '%x' spec
       string.
  
! '%Y'
!      Output the accumulated assembler options specified by '-Wa'.
  
! '%Z'
!      Output the accumulated preprocessor options specified by '-Wp'.
  
! '%M'
!      Output 'multilib_os_dir'.
  
! '%R'
!      Output the concatenation of 'target_system_root' and
!      'target_sysroot_suffix'.
  
! '%a'
!      Process the 'asm' spec.  This is used to compute the switches to be
       passed to the assembler.
  
! '%A'
!      Process the 'asm_final' spec.  This is a spec string for passing
       switches to an assembler post-processor, if such a program is
       needed.
  
! '%l'
!      Process the 'link' spec.  This is the spec for computing the
       command line passed to the linker.  Typically it makes use of the
!      '%L %G %S %D and %E' sequences.
  
! '%D'
!      Dump out a '-L' option for each directory that GCC believes might
       contain startup files.  If the target supports multilibs then the
       current multilib directory is prepended to each of these paths.
  
! '%L'
!      Process the 'lib' spec.  This is a spec string for deciding which
       libraries are included on the command line to the linker.
  
! '%G'
!      Process the 'libgcc' spec.  This is a spec string for deciding
       which GCC support library is included on the command line to the
       linker.
  
! '%S'
!      Process the 'startfile' spec.  This is a spec for deciding which
       object files are the first ones passed to the linker.  Typically
!      this might be a file named 'crt0.o'.
  
! '%E'
!      Process the 'endfile' spec.  This is a spec string that specifies
       the last object files that are passed to the linker.
  
! '%C'
!      Process the 'cpp' spec.  This is used to construct the arguments to
       be passed to the C preprocessor.
  
! '%1'
!      Process the 'cc1' spec.  This is used to construct the options to
!      be passed to the actual C compiler ('cc1').
  
! '%2'
!      Process the 'cc1plus' spec.  This is used to construct the options
!      to be passed to the actual C++ compiler ('cc1plus').
  
! '%*'
       Substitute the variable part of a matched option.  See below.  Note
       that each comma in the substituted string is replaced by a single
       space.
  
! '%S'
!      Similar to '%S’
!      Similar to ‘%  []  
  
!           It returns 'result' if the comparison evaluates to true, and
!           NULL if it doesn't.  The supported 'comparison-op' values are:
  
!           '>='
!                True if 'switch' is a later (or same) version than 'arg1'
  
!           '!>'
!                Opposite of '>='
  
!           '<'
!                True if 'switch' is an earlier version than 'arg1'
  
!           '!<'
!                Opposite of '<'
  
!           '><'
!                True if 'switch' is 'arg1' or later, and earlier than
!                'arg2'
  
!           '<>'
!                True if 'switch' is earlier than 'arg1', or is 'arg2' or
                 later
  
!           If the 'switch' is not present at all, the condition is false
!           unless the first character of the 'comparison-op' is '!'.
  
                 %:version-compare(>= 10.3 mmacosx-version-min= -lmx)
  
!           The above example would add '-lmx' if
!           '-mmacosx-version-min=10.3.9' was passed.
  
!      'include'
!           The 'include' spec function behaves much like '%include', with
            the advantage that it can be nested inside a spec and thus be
            conditionalized.  It takes one argument, the filename, and
            looks for it in the startfile path.  It always returns NULL.
  
                 %{static-libasan|static:%:include(libsanitizer.spec)%(link_libasan)}
  
!      '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
--- 31880,31965 ----
  
                 -l%:if-exists-then-else(%:getenv(VSB_DIR rtnet.h) rtnet net)
  
!      ‘sanitize’
!           The ‘sanitize’ spec function takes no arguments.  It returns
            non-NULL if any address, thread or undefined behavior
            sanitizers are active.
  
                 %{%:sanitize(address):-funwind-tables}
  
!      ‘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)
  
!      ‘version-compare’
!           The ‘version-compare’ spec function takes four or five
            arguments of the following form:
  
                   []  
  
!           It returns ‘result’ if the comparison evaluates to true, and
!           NULL if it doesn't.  The supported ‘comparison-op’ values are:
  
!           ‘>=’
!                True if ‘switch’ is a later (or same) version than ‘arg1’
  
!           ‘!>’
!                Opposite of ‘>=’
  
!           ‘<’
!                True if ‘switch’ is an earlier version than ‘arg1’
  
!           ‘!<’
!                Opposite of ‘<’
  
!           ‘><’
!                True if ‘switch’ is ‘arg1’ or later, and earlier than
!                ‘arg2’
  
!           ‘<>’
!                True if ‘switch’ is earlier than ‘arg1’, or is ‘arg2’ or
                 later
  
!           If the ‘switch’ is not present at all, the condition is false
!           unless the first character of the ‘comparison-op’ is ‘!’.
  
                 %:version-compare(>= 10.3 mmacosx-version-min= -lmx)
  
!           The above example would add ‘-lmx’ if
!           ‘-mmacosx-version-min=10.3.9’ was passed.
  
!      ‘include’
!           The ‘include’ spec function behaves much like ‘%include’, with
            the advantage that it can be nested inside a spec and thus be
            conditionalized.  It takes one argument, the filename, and
            looks for it in the startfile path.  It always returns NULL.
  
                 %{static-libasan|static:%:include(libsanitizer.spec)%(link_libasan)}
  
!      ‘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
*************** or combine them with constant text in a
*** 31959,32054 ****
                 Use "-Wa,OPTION" to pass "OPTION" to the assembler.
  
            It is used to separate compiler options from assembler options
!           in the '--target-help' output.
  
!      'gt'
!           The 'gt' spec function takes two or more arguments.  It
!           returns '""' (the empty string) if the second-to-last argument
            is greater than the last argument, and NULL otherwise.  The
!           following example inserts the 'link_gomp' spec if the last
!           '-ftree-parallelize-loops=' option given on the command line
            is greater than 1:
  
                 %{%:gt(%{ftree-parallelize-loops=*:%*} 1):%:include(libgomp.spec)%(link_gomp)}
  
!      'debug-level-gt'
!           The 'debug-level-gt' spec function takes one argument and
!           returns '""' (the empty string) if 'debug_info_level' is
            greater than the specified number, and NULL otherwise.
  
                 %{%:debug-level-gt(0):%{gdwarf*:--gdwarf2}}
  
! '%{S}'
!      Substitutes the '-S' switch, if that switch is given to GCC.  If
       that switch is not specified, this substitutes nothing.  Note that
       the leading dash is omitted when specifying this option, and it is
       automatically inserted if the substitution is performed.  Thus the
!      spec string '%{foo}' matches the command-line option '-foo' and
!      outputs the command-line option '-foo'.
  
! '%W{S}'
!      Like %{'S'} but mark last argument supplied within as a file to be
       deleted on failure.
  
! '%@{S}'
!      Like %{'S'} but puts the result into a 'FILE' and substitutes
!      '@FILE' if an '@file' argument has been supplied.
  
! '%{S*}'
       Substitutes all the switches specified to GCC whose names start
!      with '-S', but which also take an argument.  This is used for
!      switches like '-o', '-D', '-I', etc.  GCC considers '-o foo' as
!      being one switch whose name starts with 'o'.  %{o*} substitutes
       this text, including the space.  Thus two arguments are generated.
  
! '%{S*&T*}'
!      Like %{'S'*}, but preserve order of 'S' and 'T' options (the order
!      of 'S' and 'T' in the spec is not significant).  There can be any
       number of ampersand-separated variables; for each the wild card is
!      optional.  Useful for CPP as '%{D*&U*&A*}'.
  
! '%{S:X}'
!      Substitutes 'X', if the '-S' switch is given to GCC.
  
! '%{!S:X}'
!      Substitutes 'X', if the '-S' switch is _not_ given to GCC.
  
! '%{S*:X}'
!      Substitutes 'X' if one or more switches whose names start with '-S'
!      are specified to GCC.  Normally 'X' is substituted only once, no
!      matter how many such switches appeared.  However, if '%*' appears
!      somewhere in 'X', then 'X' is substituted once for each matching
!      switch, with the '%*' replaced by the part of that switch matching
!      the '*'.
  
!      If '%*' appears as the last part of a spec sequence then a space is
       added after the end of the last substitution.  If there is more
       text in the sequence, however, then a space is not generated.  This
!      allows the '%*' substitution to be used as part of a larger string.
       For example, a spec string like this:
  
            %{mcu=*:--script=%*/memory.ld}
  
!      when matching an option like '-mcu=newchip' produces:
  
            --script=newchip/memory.ld
  
! '%{.S:X}'
!      Substitutes 'X', if processing a file with suffix 'S'.
  
! '%{!.S:X}'
!      Substitutes 'X', if _not_ processing a file with suffix 'S'.
  
! '%{,S:X}'
!      Substitutes 'X', if processing a file for language 'S'.
  
! '%{!,S:X}'
!      Substitutes 'X', if not processing a file for language 'S'.
  
! '%{S|P:X}'
!      Substitutes 'X' if either '-S' or '-P' is given to GCC.  This may
!      be combined with '!', '.', ',', and '*' sequences as well, although
!      they have a stronger binding than the '|'.  If '%*' appears in 'X',
       all of the alternatives must be starred, and only the first
       matching alternative is substituted.
  
--- 31968,32063 ----
                 Use "-Wa,OPTION" to pass "OPTION" to the assembler.
  
            It is used to separate compiler options from assembler options
!           in the ‘--target-help’ output.
  
!      ‘gt’
!           The ‘gt’ spec function takes two or more arguments.  It
!           returns ‘""’ (the empty string) if the second-to-last argument
            is greater than the last argument, and NULL otherwise.  The
!           following example inserts the ‘link_gomp’ spec if the last
!           ‘-ftree-parallelize-loops=’ option given on the command line
            is greater than 1:
  
                 %{%:gt(%{ftree-parallelize-loops=*:%*} 1):%:include(libgomp.spec)%(link_gomp)}
  
!      ‘debug-level-gt’
!           The ‘debug-level-gt’ spec function takes one argument and
!           returns ‘""’ (the empty string) if ‘debug_info_level’ is
            greater than the specified number, and NULL otherwise.
  
                 %{%:debug-level-gt(0):%{gdwarf*:--gdwarf2}}
  
! ‘%{S}’
!      Substitutes the ‘-S’ switch, if that switch is given to GCC.  If
       that switch is not specified, this substitutes nothing.  Note that
       the leading dash is omitted when specifying this option, and it is
       automatically inserted if the substitution is performed.  Thus the
!      spec string ‘%{foo}’ matches the command-line option ‘-foo’ and
!      outputs the command-line option ‘-foo’.
  
! ‘%W{S}’
!      Like %{‘S’} but mark last argument supplied within as a file to be
       deleted on failure.
  
! ‘%@{S}’
!      Like %{‘S’} but puts the result into a ‘FILE’ and substitutes
!      ‘@FILE’ if an ‘@file’ argument has been supplied.
  
! ‘%{S*}’
       Substitutes all the switches specified to GCC whose names start
!      with ‘-S’, but which also take an argument.  This is used for
!      switches like ‘-o’, ‘-D’, ‘-I’, etc.  GCC considers ‘-o foo’ as
!      being one switch whose name starts with ‘o’.  %{o*} substitutes
       this text, including the space.  Thus two arguments are generated.
  
! ‘%{S*&T*}’
!      Like %{‘S’*}, but preserve order of ‘S’ and ‘T’ options (the order
!      of ‘S’ and ‘T’ in the spec is not significant).  There can be any
       number of ampersand-separated variables; for each the wild card is
!      optional.  Useful for CPP as ‘%{D*&U*&A*}’.
  
! ‘%{S:X}’
!      Substitutes ‘X’, if the ‘-S’ switch is given to GCC.
  
! ‘%{!S:X}’
!      Substitutes ‘X’, if the ‘-S’ switch is _not_ given to GCC.
  
! ‘%{S*:X}’
!      Substitutes ‘X’ if one or more switches whose names start with ‘-S’
!      are specified to GCC.  Normally ‘X’ is substituted only once, no
!      matter how many such switches appeared.  However, if ‘%*’ appears
!      somewhere in ‘X’, then ‘X’ is substituted once for each matching
!      switch, with the ‘%*’ replaced by the part of that switch matching
!      the ‘*’.
  
!      If ‘%*’ appears as the last part of a spec sequence then a space is
       added after the end of the last substitution.  If there is more
       text in the sequence, however, then a space is not generated.  This
!      allows the ‘%*’ substitution to be used as part of a larger string.
       For example, a spec string like this:
  
            %{mcu=*:--script=%*/memory.ld}
  
!      when matching an option like ‘-mcu=newchip’ produces:
  
            --script=newchip/memory.ld
  
! ‘%{.S:X}’
!      Substitutes ‘X’, if processing a file with suffix ‘S’.
  
! ‘%{!.S:X}’
!      Substitutes ‘X’, if _not_ processing a file with suffix ‘S’.
  
! ‘%{,S:X}’
!      Substitutes ‘X’, if processing a file for language ‘S’.
  
! ‘%{!,S:X}’
!      Substitutes ‘X’, if not processing a file for language ‘S’.
  
! ‘%{S|P:X}’
!      Substitutes ‘X’ if either ‘-S’ or ‘-P’ is given to GCC.  This may
!      be combined with ‘!’, ‘.’, ‘,’, and ‘*’ sequences as well, although
!      they have a stronger binding than the ‘|’.  If ‘%*’ appears in ‘X’,
       all of the alternatives must be starred, and only the first
       matching alternative is substituted.
  
*************** or combine them with constant text in a
*** 32064,32104 ****
            -d fred.c     -foo -baz -boggle
            -d jim.d      -bar -baz -boggle
  
! '%{%:FUNCTION(ARGS):X}'
  
       Call function named FUNCTION with args ARGS.  If the function
!      returns non-NULL, then 'X' is substituted, if it returns NULL, it
       isn't substituted.
  
! '%{S:X; T:Y; :D}'
  
!      If 'S' is given to GCC, substitutes 'X'; else if 'T' is given to
!      GCC, substitutes 'Y'; else substitutes 'D'.  There can be as many
!      clauses as you need.  This may be combined with '.', ',', '!', '|',
!      and '*' as needed.
  
!  The switch matching text 'S' in a '%{S}', '%{S:X}' or similar construct
  can use a backslash to ignore the special meaning of the character
  following it, thus allowing literal matching of a character that is
! otherwise specially treated.  For example, '%{std=iso9899\:1999:X}'
! substitutes 'X' if the '-std=iso9899:1999' option is given.
  
!  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
--- 32073,32113 ----
            -d fred.c     -foo -baz -boggle
            -d jim.d      -bar -baz -boggle
  
! ‘%{%:FUNCTION(ARGS):X}’
  
       Call function named FUNCTION with args ARGS.  If the function
!      returns non-NULL, then ‘X’ is substituted, if it returns NULL, it
       isn't substituted.
  
! ‘%{S:X; T:Y; :D}’
  
!      If ‘S’ is given to GCC, substitutes ‘X’; else if ‘T’ is given to
!      GCC, substitutes ‘Y’; else substitutes ‘D’.  There can be as many
!      clauses as you need.  This may be combined with ‘.’, ‘,’, ‘!’, ‘|’,
!      and ‘*’ as needed.
  
!  The switch matching text ‘S’ in a ‘%{S}’, ‘%{S:X}’ or similar construct
  can use a backslash to ignore the special meaning of the character
  following it, thus allowing literal matching of a character that is
! otherwise specially treated.  For example, ‘%{std=iso9899\:1999:X}’
! substitutes ‘X’ if the ‘-std=iso9899:1999’ option is given.
  
!  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
*************** files have been specified without knowin
*** 32108,32114 ****
  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.
  
--- 32117,32123 ----
  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.
  
*************** use when searching for various kinds of
*** 32124,32321 ****
  other aspects of the compilation environment.
  
   Note that you can also specify places to search using options such as
! '-B', '-I' and '-L' (*note Directory Options::).  These take precedence
  over places specified using environment variables, which in turn take
  precedence over those specified by the configuration of GCC.  *Note
! Controlling the Compilation Driver 'gcc': (gccint)Driver.
  
! 'LANG'
! 'LC_CTYPE'
! 'LC_MESSAGES'
! 'LC_ALL'
       These environment variables control the way that GCC uses
       localization information which allows GCC to work with different
       national conventions.  GCC inspects the locale categories
!      'LC_CTYPE' and 'LC_MESSAGES' if it has been configured to do so.
       These locale categories can be set to any value supported by your
!      installation.  A typical value is 'en_GB.UTF-8' for English in the
       United Kingdom encoded in UTF-8.
  
!      The 'LC_CTYPE' environment variable specifies character
       classification.  GCC uses it to determine the character boundaries
       in a string; this is needed for some multibyte encodings that
       contain quote and escape characters that are otherwise interpreted
       as a string end or escape.
  
!      The 'LC_MESSAGES' environment variable specifies the language to
       use in diagnostic messages.
  
!      If the 'LC_ALL' environment variable is set, it overrides the value
!      of 'LC_CTYPE' and 'LC_MESSAGES'; otherwise, 'LC_CTYPE' and
!      'LC_MESSAGES' default to the value of the 'LANG' environment
       variable.  If none of these variables are set, GCC defaults to
       traditional C English behavior.
  
! 'TMPDIR'
!      If 'TMPDIR' is set, it specifies the directory to use for temporary
       files.  GCC uses temporary files to hold the output of one stage of
       compilation which is to be used as input to the next stage: for
       example, the output of the preprocessor, which is the input to the
       compiler proper.
  
! 'GCC_COMPARE_DEBUG'
!      Setting 'GCC_COMPARE_DEBUG' is nearly equivalent to passing
!      '-fcompare-debug' to the compiler driver.  See the documentation of
       this option for more details.
  
! 'GCC_EXEC_PREFIX'
!      If 'GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the
       names of the subprograms executed by the compiler.  No slash is
       added when this prefix is combined with the name of a subprogram,
       but you can specify a prefix that ends with a slash if you wish.
  
!      If 'GCC_EXEC_PREFIX' is not set, GCC attempts to figure out an
       appropriate prefix to use based on the pathname it is invoked with.
  
       If GCC cannot find the subprogram using the specified prefix, it
       tries looking in the usual places for the subprogram.
  
!      The default value of 'GCC_EXEC_PREFIX' is 'PREFIX/lib/gcc/' where
       PREFIX is the prefix to the installed compiler.  In many cases
!      PREFIX is the value of 'prefix' when you ran the 'configure'
       script.
  
!      Other prefixes specified with '-B' take precedence over this
       prefix.
  
!      This prefix is also used for finding files such as 'crt0.o' that
       are used for linking.
  
       In addition, the prefix is used in an unusual way in finding the
       directories to search for header files.  For each of the standard
!      directories whose name normally begins with '/usr/local/lib/gcc'
!      (more precisely, with the value of 'GCC_INCLUDE_DIR'), GCC tries
       replacing that beginning with the specified prefix to produce an
!      alternate directory name.  Thus, with '-Bfoo/', GCC searches
!      'foo/bar' just before it searches the standard directory
!      '/usr/local/lib/bar'.  If a standard directory begins with the
       configured PREFIX then the value of PREFIX is replaced by
!      'GCC_EXEC_PREFIX' when looking for header files.
  
! 'COMPILER_PATH'
!      The value of 'COMPILER_PATH' is a colon-separated list of
!      directories, much like 'PATH'.  GCC tries the directories thus
       specified when searching for subprograms, if it cannot 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 cannot find them using
!      'GCC_EXEC_PREFIX'.  Linking using GCC also uses these directories
!      when searching for ordinary libraries for the '-l' option (but
!      directories specified with '-L' come first).
  
! 'LANG'
       This variable is used to pass locale information to the compiler.
       One way in which this information is used is to determine the
       character set to be used when character literals, string literals
       and comments are parsed in C and C++.  When the compiler is
       configured to allow multibyte characters, the following values for
!      'LANG' are recognized:
  
!      'C-JIS'
            Recognize JIS characters.
!      'C-SJIS'
            Recognize SJIS characters.
!      'C-EUCJP'
            Recognize EUCJP characters.
  
!      If 'LANG' is not defined, or if it has some other value, then the
!      compiler uses 'mblen' and 'mbtowc' as defined by the default locale
       to recognize and translate multibyte characters.
  
! 'GCC_EXTRA_DIAGNOSTIC_OUTPUT'
!      If 'GCC_EXTRA_DIAGNOSTIC_OUTPUT' is set to one of the following
       values, then additional text will be emitted to stderr when fix-it
!      hints are emitted.  '-fdiagnostics-parseable-fixits' and
!      '-fno-diagnostics-parseable-fixits' take precedence over this
       environment variable.
  
!      'fixits-v1'
            Emit parseable fix-it hints, equivalent to
!           '-fdiagnostics-parseable-fixits'.  In particular, columns are
            expressed as a count of bytes, starting at byte 1 for the
            initial column.
  
!      'fixits-v2'
!           As 'fixits-v1', but columns are expressed as display columns,
!           as per '-fdiagnostics-column-unit=display'.
  
  Some additional environment variables affect the behavior of the
  preprocessor.
  
! 'CPATH'
! 'C_INCLUDE_PATH'
! 'CPLUS_INCLUDE_PATH'
! 'OBJC_INCLUDE_PATH'
       Each variable's value is a list of directories separated by a
!      special character, much like 'PATH', in which to look for header
!      files.  The special character, 'PATH_SEPARATOR', is
       target-dependent and determined at GCC build time.  For Microsoft
       Windows-based targets it is a semicolon, and for almost all other
       targets it is a colon.
  
!      'CPATH' specifies a list of directories to be searched as if
!      specified with '-I', but after any paths given with '-I' options on
       the command line.  This environment variable is used regardless of
       which language is being preprocessed.
  
       The remaining environment variables apply only when preprocessing
       the particular language indicated.  Each specifies a list of
!      directories to be searched as if specified with '-isystem', but
!      after any paths given with '-isystem' options on the command line.
  
       In all these variables, an empty element instructs the compiler to
       search its current working directory.  Empty elements can appear at
       the beginning or end of a path.  For instance, if the value of
!      'CPATH' is ':/special/include', that has the same effect as
!      '-I. -I/special/include'.
  
! 'DEPENDENCIES_OUTPUT'
       If this variable is set, its value specifies how to output
       dependencies for Make based on the non-system header files
       processed by the compiler.  System header files are ignored in the
       dependency output.
  
!      The value of 'DEPENDENCIES_OUTPUT' can be just a file name, in
       which case the Make rules are written to that file, guessing the
       target name from the source file name.  Or the value can have the
!      form 'FILE TARGET', in which case the rules are written to file
       FILE using TARGET as the target name.
  
       In other words, this environment variable is equivalent to
!      combining the options '-MM' and '-MF' (*note Preprocessor
!      Options::), with an optional '-MT' switch too.
  
! 'SUNPRO_DEPENDENCIES'
!      This variable is the same as 'DEPENDENCIES_OUTPUT' (see above),
!      except that system header files are not ignored, so it implies '-M'
!      rather than '-MM'.  However, the dependence on the main input file
       is omitted.  *Note Preprocessor Options::.
  
! 'SOURCE_DATE_EPOCH'
       If this variable is set, its value specifies a UNIX timestamp to be
!      used in replacement of the current date and time in the '__DATE__'
!      and '__TIME__' macros, so that the embedded timestamps become
       reproducible.
  
!      The value of 'SOURCE_DATE_EPOCH' must be a UNIX timestamp, defined
       as the number of seconds (excluding leap seconds) since 01 Jan 1970
!      00:00:00 represented in ASCII; identical to the output of 'date
!      +%s' on GNU/Linux and other systems that support the '%s' extension
!      in the 'date' command.
  
       The value should be a known timestamp such as the last modification
       time of the source or package and it should be set by the build
--- 32133,32330 ----
  other aspects of the compilation environment.
  
   Note that you can also specify places to search using options such as
! ‘-B’, ‘-I’ and ‘-L’ (*note Directory Options::).  These take precedence
  over places specified using environment variables, which in turn take
  precedence over those specified by the configuration of GCC.  *Note
! Controlling the Compilation Driver ‘gcc’: (gccint)Driver.
  
! ‘LANG’
! ‘LC_CTYPE’
! ‘LC_MESSAGES’
! ‘LC_ALL’
       These environment variables control the way that GCC uses
       localization information which allows GCC to work with different
       national conventions.  GCC inspects the locale categories
!      ‘LC_CTYPE’ and ‘LC_MESSAGES’ if it has been configured to do so.
       These locale categories can be set to any value supported by your
!      installation.  A typical value is ‘en_GB.UTF-8’ for English in the
       United Kingdom encoded in UTF-8.
  
!      The ‘LC_CTYPE’ environment variable specifies character
       classification.  GCC uses it to determine the character boundaries
       in a string; this is needed for some multibyte encodings that
       contain quote and escape characters that are otherwise interpreted
       as a string end or escape.
  
!      The ‘LC_MESSAGES’ environment variable specifies the language to
       use in diagnostic messages.
  
!      If the ‘LC_ALL’ environment variable is set, it overrides the value
!      of ‘LC_CTYPE’ and ‘LC_MESSAGES’; otherwise, ‘LC_CTYPE’ and
!      ‘LC_MESSAGES’ default to the value of the ‘LANG’ environment
       variable.  If none of these variables are set, GCC defaults to
       traditional C English behavior.
  
! ‘TMPDIR’
!      If ‘TMPDIR’ is set, it specifies the directory to use for temporary
       files.  GCC uses temporary files to hold the output of one stage of
       compilation which is to be used as input to the next stage: for
       example, the output of the preprocessor, which is the input to the
       compiler proper.
  
! ‘GCC_COMPARE_DEBUG’
!      Setting ‘GCC_COMPARE_DEBUG’ is nearly equivalent to passing
!      ‘-fcompare-debug’ to the compiler driver.  See the documentation of
       this option for more details.
  
! ‘GCC_EXEC_PREFIX’
!      If ‘GCC_EXEC_PREFIX’ is set, it specifies a prefix to use in the
       names of the subprograms executed by the compiler.  No slash is
       added when this prefix is combined with the name of a subprogram,
       but you can specify a prefix that ends with a slash if you wish.
  
!      If ‘GCC_EXEC_PREFIX’ is not set, GCC attempts to figure out an
       appropriate prefix to use based on the pathname it is invoked with.
  
       If GCC cannot find the subprogram using the specified prefix, it
       tries looking in the usual places for the subprogram.
  
!      The default value of ‘GCC_EXEC_PREFIX’ is ‘PREFIX/lib/gcc/’ where
       PREFIX is the prefix to the installed compiler.  In many cases
!      PREFIX is the value of ‘prefix’ when you ran the ‘configure’
       script.
  
!      Other prefixes specified with ‘-B’ take precedence over this
       prefix.
  
!      This prefix is also used for finding files such as ‘crt0.o’ that
       are used for linking.
  
       In addition, the prefix is used in an unusual way in finding the
       directories to search for header files.  For each of the standard
!      directories whose name normally begins with ‘/usr/local/lib/gcc’
!      (more precisely, with the value of ‘GCC_INCLUDE_DIR’), GCC tries
       replacing that beginning with the specified prefix to produce an
!      alternate directory name.  Thus, with ‘-Bfoo/’, GCC searches
!      ‘foo/bar’ just before it searches the standard directory
!      ‘/usr/local/lib/bar’.  If a standard directory begins with the
       configured PREFIX then the value of PREFIX is replaced by
!      ‘GCC_EXEC_PREFIX’ when looking for header files.
  
! ‘COMPILER_PATH’
!      The value of ‘COMPILER_PATH’ is a colon-separated list of
!      directories, much like ‘PATH’.  GCC tries the directories thus
       specified when searching for subprograms, if it cannot 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 cannot find them using
!      ‘GCC_EXEC_PREFIX’.  Linking using GCC also uses these directories
!      when searching for ordinary libraries for the ‘-l’ option (but
!      directories specified with ‘-L’ come first).
  
! ‘LANG’
       This variable is used to pass locale information to the compiler.
       One way in which this information is used is to determine the
       character set to be used when character literals, string literals
       and comments are parsed in C and C++.  When the compiler is
       configured to allow multibyte characters, the following values for
!      ‘LANG’ are recognized:
  
!      ‘C-JIS’
            Recognize JIS characters.
!      ‘C-SJIS’
            Recognize SJIS characters.
!      ‘C-EUCJP’
            Recognize EUCJP characters.
  
!      If ‘LANG’ is not defined, or if it has some other value, then the
!      compiler uses ‘mblen’ and ‘mbtowc’ as defined by the default locale
       to recognize and translate multibyte characters.
  
! ‘GCC_EXTRA_DIAGNOSTIC_OUTPUT’
!      If ‘GCC_EXTRA_DIAGNOSTIC_OUTPUT’ is set to one of the following
       values, then additional text will be emitted to stderr when fix-it
!      hints are emitted.  ‘-fdiagnostics-parseable-fixits’ and
!      ‘-fno-diagnostics-parseable-fixits’ take precedence over this
       environment variable.
  
!      ‘fixits-v1’
            Emit parseable fix-it hints, equivalent to
!           ‘-fdiagnostics-parseable-fixits’.  In particular, columns are
            expressed as a count of bytes, starting at byte 1 for the
            initial column.
  
!      ‘fixits-v2’
!           As ‘fixits-v1’, but columns are expressed as display columns,
!           as per ‘-fdiagnostics-column-unit=display’.
  
  Some additional environment variables affect the behavior of the
  preprocessor.
  
! ‘CPATH’
! ‘C_INCLUDE_PATH’
! ‘CPLUS_INCLUDE_PATH’
! ‘OBJC_INCLUDE_PATH’
       Each variable's value is a list of directories separated by a
!      special character, much like ‘PATH’, in which to look for header
!      files.  The special character, ‘PATH_SEPARATOR’, is
       target-dependent and determined at GCC build time.  For Microsoft
       Windows-based targets it is a semicolon, and for almost all other
       targets it is a colon.
  
!      ‘CPATH’ specifies a list of directories to be searched as if
!      specified with ‘-I’, but after any paths given with ‘-I’ options on
       the command line.  This environment variable is used regardless of
       which language is being preprocessed.
  
       The remaining environment variables apply only when preprocessing
       the particular language indicated.  Each specifies a list of
!      directories to be searched as if specified with ‘-isystem’, but
!      after any paths given with ‘-isystem’ options on the command line.
  
       In all these variables, an empty element instructs the compiler to
       search its current working directory.  Empty elements can appear at
       the beginning or end of a path.  For instance, if the value of
!      ‘CPATH’ is ‘:/special/include’, that has the same effect as
!      ‘-I. -I/special/include’.
  
! ‘DEPENDENCIES_OUTPUT’
       If this variable is set, its value specifies how to output
       dependencies for Make based on the non-system header files
       processed by the compiler.  System header files are ignored in the
       dependency output.
  
!      The value of ‘DEPENDENCIES_OUTPUT’ can be just a file name, in
       which case the Make rules are written to that file, guessing the
       target name from the source file name.  Or the value can have the
!      form ‘FILE TARGET’, in which case the rules are written to file
       FILE using TARGET as the target name.
  
       In other words, this environment variable is equivalent to
!      combining the options ‘-MM’ and ‘-MF’ (*note Preprocessor
!      Options::), with an optional ‘-MT’ switch too.
  
! ‘SUNPRO_DEPENDENCIES’
!      This variable is the same as ‘DEPENDENCIES_OUTPUT’ (see above),
!      except that system header files are not ignored, so it implies ‘-M’
!      rather than ‘-MM’.  However, the dependence on the main input file
       is omitted.  *Note Preprocessor Options::.
  
! ‘SOURCE_DATE_EPOCH’
       If this variable is set, its value specifies a UNIX timestamp to be
!      used in replacement of the current date and time in the ‘__DATE__’
!      and ‘__TIME__’ macros, so that the embedded timestamps become
       reproducible.
  
!      The value of ‘SOURCE_DATE_EPOCH’ must be a UNIX timestamp, defined
       as the number of seconds (excluding leap seconds) since 01 Jan 1970
!      00:00:00 represented in ASCII; identical to the output of ‘date
!      +%s’ on GNU/Linux and other systems that support the ‘%s’ extension
!      in the ‘date’ command.
  
       The value should be a known timestamp such as the last modification
       time of the source or package and it should be set by the build
*************** Often large projects have many header fi
*** 32331,32375 ****
  source file.  The time the compiler takes to process these header files
  over and over again can account for nearly all of the time required to
  build the project.  To make builds faster, GCC allows you to
! "precompile" a header file.
  
   To create a precompiled header file, simply compile it as you would any
! other file, if necessary using the '-x' option to make the driver treat
! it as a C or C++ header file.  You may want to use a tool like 'make' to
  keep the precompiled header up-to-date when the headers it contains
  change.
  
!  A precompiled header file is searched for when '#include' is seen in
  the compilation.  As it searches for the included file (*note Search
  Path: (cpp)Search Path.) the compiler looks for a precompiled header in
  each directory just before it looks for the include file in that
  directory.  The name searched for is the name specified in the
! '#include' with '.gch' appended.  If the precompiled header file cannot
  be used, it is ignored.
  
!  For instance, if you have '#include "all.h"', and you have 'all.h.gch'
! in the same directory as 'all.h', then the precompiled header file is
  used if possible, and the original header is used otherwise.
  
   Alternatively, you might decide to put the precompiled header file in a
! directory and use '-I' to ensure that directory is searched before (or
  instead of) the directory containing the original header.  Then, if you
  want to check that the precompiled header file is always used, you can
  put a file of the same name as the original header in this directory
! containing an '#error' command.
  
!  This also works with '-include'.  So yet another way to use precompiled
  headers, good for projects not designed with precompiled header files in
  mind, is to simply take most of the header files used by a project,
  include them from another header file, precompile that header file, and
! '-include' the precompiled header.  If the header files have guards
  against multiple inclusion, they are skipped because they've already
  been included (in the precompiled header).
  
   If you need to precompile the same header file for different languages,
  targets, or compiler options, you can instead make a _directory_ named
! like 'all.h.gch', and put each precompiled header in the directory,
! perhaps using '-o'.  It doesn't matter what you call the files in the
  directory; every precompiled header in the directory is considered.  The
  first precompiled header encountered in the directory that is valid for
  this compilation is used; they're searched in no particular order.
--- 32340,32384 ----
  source file.  The time the compiler takes to process these header files
  over and over again can account for nearly all of the time required to
  build the project.  To make builds faster, GCC allows you to
! “precompile” a header file.
  
   To create a precompiled header file, simply compile it as you would any
! other file, if necessary using the ‘-x’ option to make the driver treat
! it as a C or C++ header file.  You may want to use a tool like ‘make’ to
  keep the precompiled header up-to-date when the headers it contains
  change.
  
!  A precompiled header file is searched for when ‘#include’ is seen in
  the compilation.  As it searches for the included file (*note Search
  Path: (cpp)Search Path.) the compiler looks for a precompiled header in
  each directory just before it looks for the include file in that
  directory.  The name searched for is the name specified in the
! ‘#include’ with ‘.gch’ appended.  If the precompiled header file cannot
  be used, it is ignored.
  
!  For instance, if you have ‘#include "all.h"’, and you have ‘all.h.gch’
! in the same directory as ‘all.h’, then the precompiled header file is
  used if possible, and the original header is used otherwise.
  
   Alternatively, you might decide to put the precompiled header file in a
! directory and use ‘-I’ to ensure that directory is searched before (or
  instead of) the directory containing the original header.  Then, if you
  want to check that the precompiled header file is always used, you can
  put a file of the same name as the original header in this directory
! containing an ‘#error’ command.
  
!  This also works with ‘-include’.  So yet another way to use precompiled
  headers, good for projects not designed with precompiled header files in
  mind, is to simply take most of the header files used by a project,
  include them from another header file, precompile that header file, and
! ‘-include’ the precompiled header.  If the header files have guards
  against multiple inclusion, they are skipped because they've already
  been included (in the precompiled header).
  
   If you need to precompile the same header file for different languages,
  targets, or compiler options, you can instead make a _directory_ named
! like ‘all.h.gch’, and put each precompiled header in the directory,
! perhaps using ‘-o’.  It doesn't matter what you call the files in the
  directory; every precompiled header in the directory is considered.  The
  first precompiled header encountered in the directory that is valid for
  this compilation is used; they're searched in no particular order.
*************** good sense, and the constraints of your
*** 32379,32425 ****
  
   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 cannot be used once the first C token is seen.
       You can have preprocessor directives before a precompiled header;
       you cannot include a precompiled header from inside another header.
  
!    * The precompiled header file must be produced for the same language
       as the current compilation.  You cannot 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
--- 32388,32434 ----
  
   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 cannot be used once the first C token is seen.
       You can have preprocessor directives before a precompiled header;
       you cannot include a precompiled header from inside another header.
  
!    • The precompiled header file must be produced for the same language
       as the current compilation.  You cannot 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
*************** good sense, and the constraints of your
*** 32431,32437 ****
            -fsched-verbose=NUMBER  -fschedule-insns  -fvisibility=
            -pedantic-errors
  
!    * Address space layout randomization (ASLR) can lead to not binary
       identical PCH files.  If you rely on stable PCH file contents
       disable ASLR when generating PCH files.
  
--- 32440,32446 ----
            -fsched-verbose=NUMBER  -fschedule-insns  -fvisibility=
            -pedantic-errors
  
!    • Address space layout randomization (ASLR) can lead to not binary
       identical PCH files.  If you rely on stable PCH file contents
       disable ASLR when generating PCH files.
  
*************** Bugs::.
*** 32443,32449 ****
  
   If you do use differing options when generating and using the
  precompiled header, the actual behavior is a mixture of the behavior for
! the options.  For instance, if you use '-g' to generate the precompiled
  header but not when using it, you may or may not get debugging
  information for routines in the precompiled header.
  
--- 32452,32458 ----
  
   If you do use differing options when generating and using the
  precompiled header, the actual behavior is a mixture of the behavior for
! the options.  For instance, if you use ‘-g’ to generate the precompiled
  header but not when using it, you may or may not get debugging
  information for routines in the precompiled header.
  
*************** _Standard Library Header Units_
*** 32493,32506 ****
       resource usage can be affected by how you partition header files
       into header units.
  
!  Modular compilation is _not_ enabled with just the '-std=c++20' option.
! You must explicitly enable it with the '-fmodules-ts' option.  It is
  independent of the language version selected, although in pre-C++20
  versions, it is of course an extension.
  
   No new source file suffixes are required or supported.  If you wish to
  use a non-standard suffix (*note Overall Options::), you also need to
! provide a '-x c++' option too.(1)
  
   Compiling a module interface unit produces an additional output (to the
  assembly or object file), called a Compiled Module Interface (CMI). This
--- 32502,32515 ----
       resource usage can be affected by how you partition header files
       into header units.
  
!  Modular compilation is _not_ enabled with just the ‘-std=c++20’ option.
! You must explicitly enable it with the ‘-fmodules-ts’ option.  It is
  independent of the language version selected, although in pre-C++20
  versions, it is of course an extension.
  
   No new source file suffixes are required or supported.  If you wish to
  use a non-standard suffix (*note Overall Options::), you also need to
! provide a ‘-x c++’ option too.(1)
  
   Compiling a module interface unit produces an additional output (to the
  assembly or object file), called a Compiled Module Interface (CMI). This
*************** You must build imports before the import
*** 32510,32538 ****
  
   Header files may themselves be compiled to header units, which are a
  transitional ability aiming at faster compilation.  The
! '-fmodule-header' option is used to enable this, and implies the
! '-fmodules-ts' option.  These CMIs are named by the fully resolved
  underlying header file, and thus may be a complete pathname containing
  subdirectories.  If the header file is found at an absolute pathname,
  the CMI location is still relative to a CMI root directory.
  
   As header files often have no suffix, you commonly have to specify a
! '-x' option to tell the compiler the source is a header file.  You may
! use '-x c++-header', '-x c++-user-header' or '-x c++-system-header'.
! When used in conjunction with '-fmodules-ts', these all imply an
! appropriate '-fmodule-header' option.  The latter two variants use the
  user or system include path to search for the file specified.  This
  allows you to, for instance, compile standard library header files as
  header units, without needing to know exactly where they are installed.
  Specifying the language as one of these variants also inhibits output of
  the object file, as header files have no associated object file.
  
!  The '-fmodule-only' option disables generation of the associated object
  file for compiling a module interface.  Only the CMI is generated.  This
! option is implied when using the '-fmodule-header' option.
  
!  The '-flang-info-include-translate' and
! '-flang-info-include-translate-not' options notes whether include
  translation occurs or not.  With no argument, the first will note all
  include translation.  The second will note all non-translations of
  include files not known to intentionally be textual.  With an argument,
--- 32519,32547 ----
  
   Header files may themselves be compiled to header units, which are a
  transitional ability aiming at faster compilation.  The
! ‘-fmodule-header’ option is used to enable this, and implies the
! ‘-fmodules-ts’ option.  These CMIs are named by the fully resolved
  underlying header file, and thus may be a complete pathname containing
  subdirectories.  If the header file is found at an absolute pathname,
  the CMI location is still relative to a CMI root directory.
  
   As header files often have no suffix, you commonly have to specify a
! ‘-x’ option to tell the compiler the source is a header file.  You may
! use ‘-x c++-header’, ‘-x c++-user-header’ or ‘-x c++-system-header’.
! When used in conjunction with ‘-fmodules-ts’, these all imply an
! appropriate ‘-fmodule-header’ option.  The latter two variants use the
  user or system include path to search for the file specified.  This
  allows you to, for instance, compile standard library header files as
  header units, without needing to know exactly where they are installed.
  Specifying the language as one of these variants also inhibits output of
  the object file, as header files have no associated object file.
  
!  The ‘-fmodule-only’ option disables generation of the associated object
  file for compiling a module interface.  Only the CMI is generated.  This
! option is implied when using the ‘-fmodule-header’ option.
  
!  The ‘-flang-info-include-translate’ and
! ‘-flang-info-include-translate-not’ options notes whether include
  translation occurs or not.  With no argument, the first will note all
  include translation.  The second will note all non-translations of
  include files not known to intentionally be textual.  With an argument,
*************** different header files.  This option may
*** 32542,32559 ****
  whether include translation is happening--if it is working correctly, it
  behaves as if it isn't there at all.
  
!  The '-flang-info-module-cmi' option can be used to determine where the
  compiler is reading a CMI from.  Without the option, the compiler is
  silent when such a read is successful.  This option has an optional
  argument, which will restrict the notification to just the set of named
  modules or header units specified.
  
!  The '-Winvalid-imported-macros' option causes all imported macros to be
  resolved at the end of compilation.  Without this, imported macros are
  only resolved when expanded or (re)defined.  This option detects
  conflicting import definitions for all macros.
  
!  For details of the '-fmodule-mapper' family of options, *note C++
  Module Mapper::.
  
  * Menu:
--- 32551,32568 ----
  whether include translation is happening--if it is working correctly, it
  behaves as if it isn't there at all.
  
!  The ‘-flang-info-module-cmi’ option can be used to determine where the
  compiler is reading a CMI from.  Without the option, the compiler is
  silent when such a read is successful.  This option has an optional
  argument, which will restrict the notification to just the set of named
  modules or header units specified.
  
!  The ‘-Winvalid-imported-macros’ option causes all imported macros to be
  resolved at the end of compilation.  Without this, imported macros are
  only resolved when expanded or (re)defined.  This option detects
  conflicting import definitions for all macros.
  
!  For details of the ‘-fmodule-mapper’ family of options, *note C++
  Module Mapper::.
  
  * Menu:
*************** Module Mapper::.
*** 32565,32573 ****
     ---------- Footnotes ----------
  
     (1) Some users like to distinguish module interface files with a new
! suffix, such as naming the source 'module.cppm', which involves teaching
  all tools about the new suffix.  A different scheme, such as naming
! 'module-m.cpp' would be less invasive.
  
  
  File: gcc.info,  Node: C++ Module Mapper,  Next: C++ Module Preprocessing,  Up: C++ Modules
--- 32574,32582 ----
     ---------- Footnotes ----------
  
     (1) Some users like to distinguish module interface files with a new
! suffix, such as naming the source ‘module.cppm’, which involves teaching
  all tools about the new suffix.  A different scheme, such as naming
! ‘module-m.cpp’ would be less invasive.
  
  
  File: gcc.info,  Node: C++ Module Mapper,  Next: C++ Module Preprocessing,  Up: C++ Modules
*************** determine the mapping between module nam
*** 32580,32602 ****
  used to build CMIs on demand.  _Mapper functionality is in its infancy
  and is intended for experimentation with build system interactions._
  
!  You can specify a mapper with the '-fmodule-mapper=VAL' option or
! 'CXX_MODULE_MAPPER' environment variable.  The value may have one of the
  following forms:
  
! '[HOSTNAME]:PORT[?IDENT]'
       An optional hostname and a numeric port number to connect to.  If
       the hostname is omitted, the loopback address is used.  If the
       hostname corresponds to multiple IPV6 addresses, these are tried in
       turn, until one is successful.  If your host lacks IPv6, this form
       is non-functional.  If you must use IPv4 use
!      '-fmodule-mapper='|ncat IPV4HOST PORT''.
  
! '=SOCKET[?IDENT]'
       A local domain socket.  If your host lacks local domain sockets,
       this form is non-functional.
  
! '|PROGRAM[?IDENT] [ARGS...]'
       A program to spawn, and communicate with on its stdin/stdout
       streams.  Your PATH environment variable is searched for the
       program.  Arguments are separated by space characters, (it is not
--- 32589,32611 ----
  used to build CMIs on demand.  _Mapper functionality is in its infancy
  and is intended for experimentation with build system interactions._
  
!  You can specify a mapper with the ‘-fmodule-mapper=VAL’ option or
! ‘CXX_MODULE_MAPPER’ environment variable.  The value may have one of the
  following forms:
  
! ‘[HOSTNAME]:PORT[?IDENT]’
       An optional hostname and a numeric port number to connect to.  If
       the hostname is omitted, the loopback address is used.  If the
       hostname corresponds to multiple IPV6 addresses, these are tried in
       turn, until one is successful.  If your host lacks IPv6, this form
       is non-functional.  If you must use IPv4 use
!      ‘-fmodule-mapper='|ncat IPV4HOST PORT'’.
  
! ‘=SOCKET[?IDENT]’
       A local domain socket.  If your host lacks local domain sockets,
       this form is non-functional.
  
! ‘|PROGRAM[?IDENT] [ARGS...]’
       A program to spawn, and communicate with on its stdin/stdout
       streams.  Your PATH environment variable is searched for the
       program.  Arguments are separated by space characters, (it is not
*************** following forms:
*** 32604,32616 ****
       contain a space).  An exception is if PROGRAM begins with @.  In
       that case PROGRAM (sans @) is looked for in the compiler's internal
       binary directory.  Thus the sample mapper-server can be specified
!      with '@g++-mapper-server'.
  
! '<>[?IDENT]'
! '<>INOUT[?IDENT]'
! 'OUT[?IDENT]'
       Named pipes or file descriptors to communicate over.  The first
!      form, '<>', communicates over stdin and stdout.  The other forms
       allow you to specify a file descriptor or name a pipe.  A numeric
       value is interpreted as a file descriptor, otherwise named pipe is
       opened.  The second form specifies a bidirectional pipe and the
--- 32613,32625 ----
       contain a space).  An exception is if PROGRAM begins with @.  In
       that case PROGRAM (sans @) is looked for in the compiler's internal
       binary directory.  Thus the sample mapper-server can be specified
!      with ‘@g++-mapper-server’.
  
! ‘<>[?IDENT]’
! ‘<>INOUT[?IDENT]’
! ‘OUT[?IDENT]’
       Named pipes or file descriptors to communicate over.  The first
!      form, ‘<>’, communicates over stdin and stdout.  The other forms
       allow you to specify a file descriptor or name a pipe.  A numeric
       value is interpreted as a file descriptor, otherwise named pipe is
       opened.  The second form specifies a bidirectional pipe and the
*************** following forms:
*** 32622,32644 ****
       write stdout, and it can have unfortunate interactions with signal
       delivery from the terminal.
  
! 'FILE[?IDENT]'
       A mapping file consisting of space-separated module-name, filename
       pairs, one per line.  Only the mappings for the direct imports and
       any module export name need be provided.  If other mappings are
       provided, they override those stored in any imported CMI files.  A
       repository root may be specified in the mapping file by using
!      '$root' as the module name in the first active line.  Use of this
       option will disable any default module->CMI name mapping.
  
   As shown, an optional IDENT may suffix the first word of the option,
! indicated by a '?' prefix.  The value is used in the initial handshake
  with the module server, or to specify a prefix on mapping file lines.
  In the server case, the main source file name is used if no IDENT is
  specified.  In the file case, all non-blank lines are significant,
  unless a value is specified, in which case only lines beginning with
  IDENT are significant.  The IDENT must be separated by whitespace from
! the module name.  Be aware that '<', '>', '?', and '|' characters are
  often significant to the shell, and therefore may need quoting.
  
   The mapper is connected to or loaded lazily, when the first module
--- 32631,32653 ----
       write stdout, and it can have unfortunate interactions with signal
       delivery from the terminal.
  
! ‘FILE[?IDENT]’
       A mapping file consisting of space-separated module-name, filename
       pairs, one per line.  Only the mappings for the direct imports and
       any module export name need be provided.  If other mappings are
       provided, they override those stored in any imported CMI files.  A
       repository root may be specified in the mapping file by using
!      ‘$root’ as the module name in the first active line.  Use of this
       option will disable any default module->CMI name mapping.
  
   As shown, an optional IDENT may suffix the first word of the option,
! indicated by a ‘?’ prefix.  The value is used in the initial handshake
  with the module server, or to specify a prefix on mapping file lines.
  In the server case, the main source file name is used if no IDENT is
  specified.  In the file case, all non-blank lines are significant,
  unless a value is specified, in which case only lines beginning with
  IDENT are significant.  The IDENT must be separated by whitespace from
! the module name.  Be aware that ‘<’, ‘>’, ‘?’, and ‘|’ characters are
  often significant to the shell, and therefore may need quoting.
  
   The mapper is connected to or loaded lazily, when the first module
*************** the environment (such as working directo
*** 32654,32673 ****
  As it may parallelize builds, several compilations may connect to the
  same socket.
  
!  The default mapper generates CMI files in a 'gcm.cache' directory.  CMI
! files have a '.gcm' suffix.  The module unit name is used directly to
  provide the basename.  Header units construct a relative path using the
! underlying header file name.  If the path is already relative, a ','
! directory is prepended.  Internal '..' components are translated to
! ',,'.  No attempt is made to canonicalize these filenames beyond that
  done by the preprocessor's include search algorithm, as in general it is
  ambiguous when symbolic links are present.
  
   The mapper protocol was published as "A Module Mapper"
! .  The implementation is provided by 'libcody',
  , which specifies the canonical
  protocol definition.  A proof of concept server implementation embedded
! in 'make' was described in "Make Me A Module",
  .
  
  
--- 32663,32682 ----
  As it may parallelize builds, several compilations may connect to the
  same socket.
  
!  The default mapper generates CMI files in a ‘gcm.cache’ directory.  CMI
! files have a ‘.gcm’ suffix.  The module unit name is used directly to
  provide the basename.  Header units construct a relative path using the
! underlying header file name.  If the path is already relative, a ‘,’
! directory is prepended.  Internal ‘..’ components are translated to
! ‘,,’.  No attempt is made to canonicalize these filenames beyond that
  done by the preprocessor's include search algorithm, as in general it is
  ambiguous when symbolic links are present.
  
   The mapper protocol was published as "A Module Mapper"
! .  The implementation is provided by ‘libcody’,
  , which specifies the canonical
  protocol definition.  A proof of concept server implementation embedded
! in ‘make’ was described in "Make Me A Module",
  .
  
  
*************** just preprocessing, an error is emitted)
*** 32688,32707 ****
  requires preprocessor tokenization of the input stream to phase 4 (macro
  expansion).
  
!  Include translation converts '#include', '#include_next' and '#import'
! directives to internal 'import' declarations.  Whether a particular
  directive is translated is controlled by the module mapper.  Header unit
  names are canonicalized during preprocessing.
  
   Dependency information can be emitted for macro import, extending the
! functionality of '-MD' and '-MMD' options.  Detection of import
  declarations also requires phase 4 preprocessing, and thus requires full
  preprocessing (or compilation).
  
!  The '-M', '-MM' and '-E -fdirectives-only' options halt preprocessing
  before phase 4.
  
!  The '-save-temps' option uses '-fdirectives-only' for preprocessing,
  and preserve the macro definitions in the preprocessed output.  Usually
  you also want to use this option when explicitly preprocessing a
  header-unit, or consuming such preprocessed output:
--- 32697,32716 ----
  requires preprocessor tokenization of the input stream to phase 4 (macro
  expansion).
  
!  Include translation converts ‘#include’, ‘#include_next’ and ‘#import’
! directives to internal ‘import’ declarations.  Whether a particular
  directive is translated is controlled by the module mapper.  Header unit
  names are canonicalized during preprocessing.
  
   Dependency information can be emitted for macro import, extending the
! functionality of ‘-MD’ and ‘-MMD’ options.  Detection of import
  declarations also requires phase 4 preprocessing, and thus requires full
  preprocessing (or compilation).
  
!  The ‘-M’, ‘-MM’ and ‘-E -fdirectives-only’ options halt preprocessing
  before phase 4.
  
!  The ‘-save-temps’ option uses ‘-fdirectives-only’ for preprocessing,
  and preserve the macro definitions in the preprocessed output.  Usually
  you also want to use this option when explicitly preprocessing a
  header-unit, or consuming such preprocessed output:
*************** file), or complete new contents.  They d
*** 32731,32741 ****
  creation.  This is unlike object file writing, which may be observed by
  an external process.
  
!  CMIs are read in lazily, if the host OS provides 'mmap' functionality.
  Generally blocks are read when name lookup or template instantiation
! occurs.  To inhibit this, the '-fno-module-lazy' option may be used.
  
!  The '--param lazy-modules=N' parameter controls the limit on the number
  of concurrently open module files during lazy loading.  Should more
  modules be imported, an LRU algorithm is used to determine which files
  to close--until that file is needed again.  This limit may be exceeded
--- 32740,32750 ----
  creation.  This is unlike object file writing, which may be observed by
  an external process.
  
!  CMIs are read in lazily, if the host OS provides ‘mmap’ functionality.
  Generally blocks are read when name lookup or template instantiation
! occurs.  To inhibit this, the ‘-fno-module-lazy’ option may be used.
  
!  The ‘--param lazy-modules=N’ parameter controls the limit on the number
  of concurrently open module files during lazy loading.  Should more
  modules be imported, an LRU algorithm is used to determine which files
  to close--until that file is needed again.  This limit may be exceeded
*************** default, the limit is a few less than th
*** 32745,32754 ****
  hard limit, if that is determinable.(1)
  
   GCC CMIs use ELF32 as an architecture-neutral encapsulation mechanism.
! You may use 'readelf' to inspect them, although section contents are
! largely undecipherable.  There is a section named '.gnu.c++.README',
  which contains human-readable text.  Other than the first line, each
! line consists of 'TAG: value' tuples.
  
       > readelf -p.gnu.c++.README gcm.cache/foo.gcm
  
--- 32754,32763 ----
  hard limit, if that is determinable.(1)
  
   GCC CMIs use ELF32 as an architecture-neutral encapsulation mechanism.
! You may use ‘readelf’ to inspect them, although section contents are
! largely undecipherable.  There is a section named ‘.gnu.c++.README’,
  which contains human-readable text.  Other than the first line, each
! line consists of ‘TAG: value’ tuples.
  
       > readelf -p.gnu.c++.README gcm.cache/foo.gcm
  
*************** line consists of 'TAG: value' tuples.
*** 32767,32782 ****
  
   Amongst other things, this lists the source that was built, C++ dialect
  used and imports of the module.(2)  The timestamp is the same value as
! that provided by the '__DATE__' & '__TIME__' macros, and may be
! explicitly specified with the environment variable 'SOURCE_DATE_EPOCH'.
  For further details *note Environment Variables::.
  
   A set of related CMIs may be copied, provided the relative pathnames
  are preserved.
  
!  The '.gnu.c++.README' contents do not affect CMI integrity, and it may
  be removed or altered.  The section numbering of the sections whose
! names do not begin with '.gnu.c++.', or are not the string section is
  significant and must not be altered.
  
     ---------- Footnotes ----------
--- 32776,32791 ----
  
   Amongst other things, this lists the source that was built, C++ dialect
  used and imports of the module.(2)  The timestamp is the same value as
! that provided by the ‘__DATE__’ & ‘__TIME__’ macros, and may be
! explicitly specified with the environment variable ‘SOURCE_DATE_EPOCH’.
  For further details *note Environment Variables::.
  
   A set of related CMIs may be copied, provided the relative pathnames
  are preserved.
  
!  The ‘.gnu.c++.README’ contents do not affect CMI integrity, and it may
  be removed or altered.  The section numbering of the sections whose
! names do not begin with ‘.gnu.c++.’, or are not the string section is
  significant and must not be altered.
  
     ---------- Footnotes ----------
*************** File: gcc.info,  Node: Translation imple
*** 32834,32847 ****
  4.1 Translation
  ===============
  
!    * 'How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90,
!      C99 and C11 5.1.1.3).'
  
       Diagnostics consist of all the output sent to stderr by GCC.
  
!    * 'Whether each nonempty sequence of white-space characters other
       than new-line is retained or replaced by one space character in
!      translation phase 3 (C90, C99 and C11 5.1.1.2).'
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
--- 32843,32856 ----
  4.1 Translation
  ===============
  
!    • ‘How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90,
!      C99 and C11 5.1.1.3).’
  
       Diagnostics consist of all the output sent to stderr by GCC.
  
!    • ‘Whether each nonempty sequence of white-space characters other
       than new-line is retained or replaced by one space character in
!      translation phase 3 (C90, C99 and C11 5.1.1.2).’
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
*************** File: gcc.info,  Node: Environment imple
*** 32855,32863 ****
  The behavior of most of these points are dependent on the implementation
  of the C library, and are not defined by GCC itself.
  
!    * 'The mapping between physical source file multibyte characters and
       the source character set in translation phase 1 (C90, C99 and C11
!      5.1.1.2).'
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
--- 32864,32872 ----
  The behavior of most of these points are dependent on the implementation
  of the C library, and are not defined by GCC itself.
  
!    • ‘The mapping between physical source file multibyte characters and
       the source character set in translation phase 1 (C90, C99 and C11
!      5.1.1.2).’
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
*************** File: gcc.info,  Node: Identifiers imple
*** 32868,32889 ****
  4.3 Identifiers
  ===============
  
!    * 'Which additional multibyte characters may appear in identifiers
       and their correspondence to universal character names (C99 and C11
!      6.4.2).'
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    * 'The number of significant initial characters in an identifier (C90
!      6.1.2, C90, C99 and C11 5.2.4.1, C99 and C11 6.4.2).'
  
       For internal names, all characters are significant.  For external
       names, the number of significant characters are defined by the
       linker; for almost all targets, all characters are significant.
  
!    * 'Whether case distinctions are significant in an identifier with
!      external linkage (C90 6.1.2).'
  
       This is a property of the linker.  C99 and C11 require that case
       distinctions are always significant in identifiers with external
--- 32877,32898 ----
  4.3 Identifiers
  ===============
  
!    • ‘Which additional multibyte characters may appear in identifiers
       and their correspondence to universal character names (C99 and C11
!      6.4.2).’
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    • ‘The number of significant initial characters in an identifier (C90
!      6.1.2, C90, C99 and C11 5.2.4.1, C99 and C11 6.4.2).’
  
       For internal names, all characters are significant.  For external
       names, the number of significant characters are defined by the
       linker; for almost all targets, all characters are significant.
  
!    • ‘Whether case distinctions are significant in an identifier with
!      external linkage (C90 6.1.2).’
  
       This is a property of the linker.  C99 and C11 require that case
       distinctions are always significant in identifiers with external
*************** File: gcc.info,  Node: Characters implem
*** 32895,32988 ****
  4.4 Characters
  ==============
  
!    * 'The number of bits in a byte (C90 3.4, C99 and C11 3.6).'
  
       Determined by ABI.
  
!    * 'The values of the members of the execution character set (C90, C99
!      and C11 5.2.1).'
  
       Determined by ABI.
  
!    * 'The unique value of the member of the execution character set
       produced for each of the standard alphabetic escape sequences (C90,
!      C99 and C11 5.2.2).'
  
       Determined by ABI.
  
!    * 'The value of a 'char' object into which has been stored any
       character other than a member of the basic execution character set
!      (C90 6.1.2.5, C99 and C11 6.2.5).'
  
       Determined by ABI.
  
!    * 'Which of 'signed char' or 'unsigned char' has the same range,
!      representation, and behavior as "plain" 'char' (C90 6.1.2.5, C90
!      6.2.1.1, C99 and C11 6.2.5, C99 and C11 6.3.1.1).'
  
!      Determined by ABI.  The options '-funsigned-char' and
!      '-fsigned-char' change the default.  *Note Options Controlling C
       Dialect: C Dialect Options.
  
!    * 'The mapping of members of the source character set (in character
       constants and string literals) to members of the execution
       character set (C90 6.1.3.4, C99 and C11 6.4.4.4, C90, C99 and C11
!      5.1.1.2).'
  
       Determined by ABI.
  
!    * 'The value of an integer character constant containing more than
       one character or containing a character or escape sequence that
       does not map to a single-byte execution character (C90 6.1.3.4, C99
!      and C11 6.4.4.4).'
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    * 'The value of a wide character constant containing more than one
       multibyte character or a single multibyte character that maps to
       multiple members of the extended execution character set, or
       containing a multibyte character or escape sequence not represented
       in the extended execution character set (C90 6.1.3.4, C99 and C11
!      6.4.4.4).'
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    * 'The current locale used to convert a wide character constant
       consisting of a single multibyte character that maps to a member of
       the extended execution character set into a corresponding wide
!      character code (C90 6.1.3.4, C99 and C11 6.4.4.4).'
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    * 'Whether differently-prefixed wide string literal tokens can be
       concatenated and, if so, the treatment of the resulting multibyte
!      character sequence (C11 6.4.5).'
  
       Such tokens may not be concatenated.
  
!    * 'The current locale used to convert a wide string literal into
!      corresponding wide character codes (C90 6.1.4, C99 and C11 6.4.5).'
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    * 'The value of a string literal containing a multibyte character or
       escape sequence not represented in the execution character set (C90
!      6.1.4, C99 and C11 6.4.5).'
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    * 'The encoding of any of 'wchar_t', 'char16_t', and 'char32_t' where
!      the corresponding standard encoding macro ('__STDC_ISO_10646__',
!      '__STDC_UTF_16__', or '__STDC_UTF_32__') is not defined (C11
!      6.10.8.2).'
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
!      behavior.  'char16_t' and 'char32_t' literals are always encoded in
       UTF-16 and UTF-32 respectively.
  
  
--- 32904,32997 ----
  4.4 Characters
  ==============
  
!    • ‘The number of bits in a byte (C90 3.4, C99 and C11 3.6).’
  
       Determined by ABI.
  
!    • ‘The values of the members of the execution character set (C90, C99
!      and C11 5.2.1).’
  
       Determined by ABI.
  
!    • ‘The unique value of the member of the execution character set
       produced for each of the standard alphabetic escape sequences (C90,
!      C99 and C11 5.2.2).’
  
       Determined by ABI.
  
!    • ‘The value of a ‘char’ object into which has been stored any
       character other than a member of the basic execution character set
!      (C90 6.1.2.5, C99 and C11 6.2.5).’
  
       Determined by ABI.
  
!    • ‘Which of ‘signed char’ or ‘unsigned char’ has the same range,
!      representation, and behavior as "plain" ‘char’ (C90 6.1.2.5, C90
!      6.2.1.1, C99 and C11 6.2.5, C99 and C11 6.3.1.1).’
  
!      Determined by ABI.  The options ‘-funsigned-char’ and
!      ‘-fsigned-char’ change the default.  *Note Options Controlling C
       Dialect: C Dialect Options.
  
!    • ‘The mapping of members of the source character set (in character
       constants and string literals) to members of the execution
       character set (C90 6.1.3.4, C99 and C11 6.4.4.4, C90, C99 and C11
!      5.1.1.2).’
  
       Determined by ABI.
  
!    • ‘The value of an integer character constant containing more than
       one character or containing a character or escape sequence that
       does not map to a single-byte execution character (C90 6.1.3.4, C99
!      and C11 6.4.4.4).’
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    • ‘The value of a wide character constant containing more than one
       multibyte character or a single multibyte character that maps to
       multiple members of the extended execution character set, or
       containing a multibyte character or escape sequence not represented
       in the extended execution character set (C90 6.1.3.4, C99 and C11
!      6.4.4.4).’
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    • ‘The current locale used to convert a wide character constant
       consisting of a single multibyte character that maps to a member of
       the extended execution character set into a corresponding wide
!      character code (C90 6.1.3.4, C99 and C11 6.4.4.4).’
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    • ‘Whether differently-prefixed wide string literal tokens can be
       concatenated and, if so, the treatment of the resulting multibyte
!      character sequence (C11 6.4.5).’
  
       Such tokens may not be concatenated.
  
!    • ‘The current locale used to convert a wide string literal into
!      corresponding wide character codes (C90 6.1.4, C99 and C11 6.4.5).’
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    • ‘The value of a string literal containing a multibyte character or
       escape sequence not represented in the execution character set (C90
!      6.1.4, C99 and C11 6.4.5).’
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
       behavior.
  
!    • ‘The encoding of any of ‘wchar_t’, ‘char16_t’, and ‘char32_t’ where
!      the corresponding standard encoding macro (‘__STDC_ISO_10646__’,
!      ‘__STDC_UTF_16__’, or ‘__STDC_UTF_32__’) is not defined (C11
!      6.10.8.2).’
  
       *Note Implementation-defined behavior: (cpp)Implementation-defined
!      behavior.  ‘char16_t’ and ‘char32_t’ literals are always encoded in
       UTF-16 and UTF-32 respectively.
  
  
*************** File: gcc.info,  Node: Integers implemen
*** 32991,33036 ****
  4.5 Integers
  ============
  
!    * 'Any extended integer types that exist in the implementation (C99
!      and C11 6.2.5).'
  
       GCC does not support any extended integer types.
  
!    * 'Whether signed integer types are represented using sign and
       magnitude, two's complement, or one's complement, and whether the
       extraordinary value is a trap representation or an ordinary value
!      (C99 and C11 6.2.6.2).'
  
       GCC supports only two's complement integer types, and all bit
       patterns are ordinary values.
  
!    * 'The rank of any extended integer type relative to another extended
!      integer type with the same precision (C99 and C11 6.3.1.1).'
  
       GCC does not support any extended integer types.
  
!    * 'The result of, or the signal raised by, converting an integer to a
       signed integer type when the value cannot be represented in an
!      object of that type (C90 6.2.1.2, C99 and C11 6.3.1.3).'
  
       For conversion to a type of width N, the value is reduced modulo
       2^N to be within range of the type; no signal is raised.
  
!    * 'The results of some bitwise operations on signed integers (C90
!      6.3, C99 and C11 6.5).'
  
       Bitwise operators act on the representation of the value including
       both the sign and value bits, where the sign bit is considered
!      immediately above the highest-value value bit.  Signed '>>' acts on
       negative numbers by sign extension.
  
       As an extension to the C language, GCC does not use the latitude
!      given in C99 and C11 only to treat certain aspects of signed '<<'
!      as undefined.  However, '-fsanitize=shift' (and
!      '-fsanitize=undefined') will diagnose such cases.  They are also
       diagnosed where constant expressions are required.
  
!    * 'The sign of the remainder on integer division (C90 6.3.5).'
  
       GCC always follows the C99 and C11 requirement that the result of
       division is truncated towards zero.
--- 33000,33045 ----
  4.5 Integers
  ============
  
!    • ‘Any extended integer types that exist in the implementation (C99
!      and C11 6.2.5).’
  
       GCC does not support any extended integer types.
  
!    • ‘Whether signed integer types are represented using sign and
       magnitude, two's complement, or one's complement, and whether the
       extraordinary value is a trap representation or an ordinary value
!      (C99 and C11 6.2.6.2).’
  
       GCC supports only two's complement integer types, and all bit
       patterns are ordinary values.
  
!    • ‘The rank of any extended integer type relative to another extended
!      integer type with the same precision (C99 and C11 6.3.1.1).’
  
       GCC does not support any extended integer types.
  
!    • ‘The result of, or the signal raised by, converting an integer to a
       signed integer type when the value cannot be represented in an
!      object of that type (C90 6.2.1.2, C99 and C11 6.3.1.3).’
  
       For conversion to a type of width N, the value is reduced modulo
       2^N to be within range of the type; no signal is raised.
  
!    • ‘The results of some bitwise operations on signed integers (C90
!      6.3, C99 and C11 6.5).’
  
       Bitwise operators act on the representation of the value including
       both the sign and value bits, where the sign bit is considered
!      immediately above the highest-value value bit.  Signed ‘>>’ acts on
       negative numbers by sign extension.
  
       As an extension to the C language, GCC does not use the latitude
!      given in C99 and C11 only to treat certain aspects of signed ‘<<’
!      as undefined.  However, ‘-fsanitize=shift’ (and
!      ‘-fsanitize=undefined’) will diagnose such cases.  They are also
       diagnosed where constant expressions are required.
  
!    • ‘The sign of the remainder on integer division (C90 6.3.5).’
  
       GCC always follows the C99 and C11 requirement that the result of
       division is truncated towards zero.
*************** File: gcc.info,  Node: Floating point im
*** 33041,33119 ****
  4.6 Floating Point
  ==================
  
!    * 'The accuracy of the floating-point operations and of the library
!      functions in '' and '' that return
!      floating-point results (C90, C99 and C11 5.2.4.2.2).'
  
       The accuracy is unknown.
  
!    * 'The rounding behaviors characterized by non-standard values of
!      'FLT_ROUNDS' (C90, C99 and C11 5.2.4.2.2).'
  
       GCC does not use such values.
  
!    * 'The evaluation methods characterized by non-standard negative
!      values of 'FLT_EVAL_METHOD' (C99 and C11 5.2.4.2.2).'
  
       GCC does not use such values.
  
!    * 'The direction of rounding when an integer is converted to a
       floating-point number that cannot exactly represent the original
!      value (C90 6.2.1.3, C99 and C11 6.3.1.4).'
  
       C99 Annex F is followed.
  
!    * 'The direction of rounding when a floating-point number is
       converted to a narrower floating-point number (C90 6.2.1.4, C99 and
!      C11 6.3.1.5).'
  
       C99 Annex F is followed.
  
!    * 'How the nearest representable value or the larger or smaller
       representable value immediately adjacent to the nearest
       representable value is chosen for certain floating constants (C90
!      6.1.3.1, C99 and C11 6.4.4.2).'
  
       C99 Annex F is followed.
  
!    * 'Whether and how floating expressions are contracted when not
!      disallowed by the 'FP_CONTRACT' pragma (C99 and C11 6.5).'
  
!      Expressions are currently only contracted if '-ffp-contract=fast',
!      '-funsafe-math-optimizations' or '-ffast-math' are used.  This is
       subject to change.
  
!    * 'The default state for the 'FENV_ACCESS' pragma (C99 and C11
!      7.6.1).'
  
       This pragma is not implemented, but the default is to "off" unless
!      '-frounding-math' is used and '-fno-trapping-math' is not in which
       case it is "on".
  
!    * 'Additional floating-point exceptions, rounding modes,
       environments, and classifications, and their macro names (C99 and
!      C11 7.6, C99 and C11 7.12).'
  
       This is dependent on the implementation of the C library, and is
       not defined by GCC itself.
  
!    * 'The default state for the 'FP_CONTRACT' pragma (C99 and C11
!      7.12.2).'
  
       This pragma is not implemented.  Expressions are currently only
!      contracted if '-ffp-contract=fast', '-funsafe-math-optimizations'
!      or '-ffast-math' are used.  This is subject to change.
  
!    * 'Whether the "inexact" floating-point exception can be raised when
       the rounded result actually does equal the mathematical result in
!      an IEC 60559 conformant implementation (C99 F.9).'
  
       This is dependent on the implementation of the C library, and is
       not defined by GCC itself.
  
!    * 'Whether the "underflow" (and "inexact") floating-point exception
       can be raised when a result is tiny but not inexact in an IEC 60559
!      conformant implementation (C99 F.9).'
  
       This is dependent on the implementation of the C library, and is
       not defined by GCC itself.
--- 33050,33128 ----
  4.6 Floating Point
  ==================
  
!    • ‘The accuracy of the floating-point operations and of the library
!      functions in ‘’ and ‘’ that return
!      floating-point results (C90, C99 and C11 5.2.4.2.2).’
  
       The accuracy is unknown.
  
!    • ‘The rounding behaviors characterized by non-standard values of
!      ‘FLT_ROUNDS’ (C90, C99 and C11 5.2.4.2.2).’
  
       GCC does not use such values.
  
!    • ‘The evaluation methods characterized by non-standard negative
!      values of ‘FLT_EVAL_METHOD’ (C99 and C11 5.2.4.2.2).’
  
       GCC does not use such values.
  
!    • ‘The direction of rounding when an integer is converted to a
       floating-point number that cannot exactly represent the original
!      value (C90 6.2.1.3, C99 and C11 6.3.1.4).’
  
       C99 Annex F is followed.
  
!    • ‘The direction of rounding when a floating-point number is
       converted to a narrower floating-point number (C90 6.2.1.4, C99 and
!      C11 6.3.1.5).’
  
       C99 Annex F is followed.
  
!    • ‘How the nearest representable value or the larger or smaller
       representable value immediately adjacent to the nearest
       representable value is chosen for certain floating constants (C90
!      6.1.3.1, C99 and C11 6.4.4.2).’
  
       C99 Annex F is followed.
  
!    • ‘Whether and how floating expressions are contracted when not
!      disallowed by the ‘FP_CONTRACT’ pragma (C99 and C11 6.5).’
  
!      Expressions are currently only contracted if ‘-ffp-contract=fast’,
!      ‘-funsafe-math-optimizations’ or ‘-ffast-math’ are used.  This is
       subject to change.
  
!    • ‘The default state for the ‘FENV_ACCESS’ pragma (C99 and C11
!      7.6.1).’
  
       This pragma is not implemented, but the default is to "off" unless
!      ‘-frounding-math’ is used and ‘-fno-trapping-math’ is not in which
       case it is "on".
  
!    • ‘Additional floating-point exceptions, rounding modes,
       environments, and classifications, and their macro names (C99 and
!      C11 7.6, C99 and C11 7.12).’
  
       This is dependent on the implementation of the C library, and is
       not defined by GCC itself.
  
!    • ‘The default state for the ‘FP_CONTRACT’ pragma (C99 and C11
!      7.12.2).’
  
       This pragma is not implemented.  Expressions are currently only
!      contracted if ‘-ffp-contract=fast’, ‘-funsafe-math-optimizations’
!      or ‘-ffast-math’ are used.  This is subject to change.
  
!    • ‘Whether the "inexact" floating-point exception can be raised when
       the rounded result actually does equal the mathematical result in
!      an IEC 60559 conformant implementation (C99 F.9).’
  
       This is dependent on the implementation of the C library, and is
       not defined by GCC itself.
  
!    • ‘Whether the "underflow" (and "inexact") floating-point exception
       can be raised when a result is tiny but not inexact in an IEC 60559
!      conformant implementation (C99 F.9).’
  
       This is dependent on the implementation of the C library, and is
       not defined by GCC itself.
*************** File: gcc.info,  Node: Arrays and pointe
*** 33124,33131 ****
  4.7 Arrays and Pointers
  =======================
  
!    * 'The result of converting a pointer to an integer or vice versa
!      (C90 6.3.4, C99 and C11 6.3.2.3).'
  
       A cast from pointer to integer discards most-significant bits if
       the pointer representation is larger than the integer type,
--- 33133,33140 ----
  4.7 Arrays and Pointers
  =======================
  
!    • ‘The result of converting a pointer to an integer or vice versa
!      (C90 6.3.4, C99 and C11 6.3.2.3).’
  
       A cast from pointer to integer discards most-significant bits if
       the pointer representation is larger than the integer type,
*************** File: gcc.info,  Node: Arrays and pointe
*** 33144,33151 ****
       integer arithmetic to avoid the undefined behavior of pointer
       arithmetic as proscribed in C99 and C11 6.5.6/8.
  
!    * 'The size of the result of subtracting two pointers to elements of
!      the same array (C90 6.3.6, C99 and C11 6.5.6).'
  
       The value is as specified in the standard and the type is
       determined by the ABI.
--- 33153,33160 ----
       integer arithmetic to avoid the undefined behavior of pointer
       arithmetic as proscribed in C99 and C11 6.5.6/8.
  
!    • ‘The size of the result of subtracting two pointers to elements of
!      the same array (C90 6.3.6, C99 and C11 6.5.6).’
  
       The value is as specified in the standard and the type is
       determined by the ABI.
*************** File: gcc.info,  Node: Arrays and pointe
*** 33153,33159 ****
     ---------- 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
--- 33162,33168 ----
     ---------- 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
*************** File: gcc.info,  Node: Hints implementat
*** 33161,33192 ****
  4.8 Hints
  =========
  
!    * 'The extent to which suggestions made by using the 'register'
       storage-class specifier are effective (C90 6.5.1, C99 and C11
!      6.7.1).'
  
!      The 'register' specifier affects code generation only in these
       ways:
  
!         * When used as part of the register variable extension, see
            *note Explicit Register Variables::.
  
!         * When '-O0' is in use, the compiler allocates distinct stack
!           memory for all variables that do not have the 'register'
!           storage-class specifier; if 'register' is specified, the
            variable may have a shorter lifespan than the code would
            indicate and may never be placed in memory.
  
!         * On some rare x86 targets, 'setjmp' doesn't save the registers
            in all circumstances.  In those cases, GCC doesn't allocate
!           any variables in registers unless they are marked 'register'.
  
!    * 'The extent to which suggestions made by using the inline function
!      specifier are effective (C99 and C11 6.7.4).'
  
!      GCC will not inline any functions if the '-fno-inline' option is
!      used or if '-O0' is used.  Otherwise, GCC may still be unable to
!      inline a function for many reasons; the '-Winline' option may be
       used to determine if a function has not been inlined and why not.
  
  
--- 33170,33201 ----
  4.8 Hints
  =========
  
!    • ‘The extent to which suggestions made by using the ‘register’
       storage-class specifier are effective (C90 6.5.1, C99 and C11
!      6.7.1).’
  
!      The ‘register’ specifier affects code generation only in these
       ways:
  
!         • When used as part of the register variable extension, see
            *note Explicit Register Variables::.
  
!         • When ‘-O0’ is in use, the compiler allocates distinct stack
!           memory for all variables that do not have the ‘register’
!           storage-class specifier; if ‘register’ is specified, the
            variable may have a shorter lifespan than the code would
            indicate and may never be placed in memory.
  
!         • On some rare x86 targets, ‘setjmp’ doesn't save the registers
            in all circumstances.  In those cases, GCC doesn't allocate
!           any variables in registers unless they are marked ‘register’.
  
!    • ‘The extent to which suggestions made by using the inline function
!      specifier are effective (C99 and C11 6.7.4).’
  
!      GCC will not inline any functions if the ‘-fno-inline’ option is
!      used or if ‘-O0’ is used.  Otherwise, GCC may still be unable to
!      inline a function for many reasons; the ‘-Winline’ option may be
       used to determine if a function has not been inlined and why not.
  
  
*************** File: gcc.info,  Node: Structures unions
*** 33195,33250 ****
  4.9 Structures, Unions, Enumerations, and Bit-Fields
  ====================================================
  
!    * 'A member of a union object is accessed using a member of a
!      different type (C90 6.3.2.3).'
  
       The relevant bytes of the representation of the object are treated
       as an object of the type used for the access.  *Note
       Type-punning::.  This may be a trap representation.
  
!    * 'Whether a "plain" 'int' bit-field is treated as a 'signed int'
!      bit-field or as an 'unsigned int' bit-field (C90 6.5.2, C90
!      6.5.2.1, C99 and C11 6.7.2, C99 and C11 6.7.2.1).'
  
!      By default it is treated as 'signed int' but this may be changed by
!      the '-funsigned-bitfields' option.
  
!    * 'Allowable bit-field types other than '_Bool', 'signed int', and
!      'unsigned int' (C99 and C11 6.7.2.1).'
  
!      Other integer types, such as 'long int', and enumerated types are
       permitted even in strictly conforming mode.
  
!    * 'Whether atomic types are permitted for bit-fields (C11 6.7.2.1).'
  
       Atomic types are not permitted for bit-fields.
  
!    * 'Whether a bit-field can straddle a storage-unit boundary (C90
!      6.5.2.1, C99 and C11 6.7.2.1).'
  
       Determined by ABI.
  
!    * 'The order of allocation of bit-fields within a unit (C90 6.5.2.1,
!      C99 and C11 6.7.2.1).'
  
       Determined by ABI.
  
!    * 'The alignment of non-bit-field members of structures (C90 6.5.2.1,
!      C99 and C11 6.7.2.1).'
  
       Determined by ABI.
  
!    * 'The integer type compatible with each enumerated type (C90
!      6.5.2.2, C99 and C11 6.7.2.2).'
  
!      Normally, the type is 'unsigned int' if there are no negative
!      values in the enumeration, otherwise 'int'.  If '-fshort-enums' is
       specified, then if there are negative values it is the first of
!      'signed char', 'short' and 'int' that can represent all the values,
!      otherwise it is the first of 'unsigned char', 'unsigned short' and
!      'unsigned int' that can represent all the values.
  
!      On some targets, '-fshort-enums' is the default; this is determined
       by the ABI.
  
  
--- 33204,33259 ----
  4.9 Structures, Unions, Enumerations, and Bit-Fields
  ====================================================
  
!    • ‘A member of a union object is accessed using a member of a
!      different type (C90 6.3.2.3).’
  
       The relevant bytes of the representation of the object are treated
       as an object of the type used for the access.  *Note
       Type-punning::.  This may be a trap representation.
  
!    • ‘Whether a "plain" ‘int’ bit-field is treated as a ‘signed int’
!      bit-field or as an ‘unsigned int’ bit-field (C90 6.5.2, C90
!      6.5.2.1, C99 and C11 6.7.2, C99 and C11 6.7.2.1).’
  
!      By default it is treated as ‘signed int’ but this may be changed by
!      the ‘-funsigned-bitfields’ option.
  
!    • ‘Allowable bit-field types other than ‘_Bool’, ‘signed int’, and
!      ‘unsigned int’ (C99 and C11 6.7.2.1).’
  
!      Other integer types, such as ‘long int’, and enumerated types are
       permitted even in strictly conforming mode.
  
!    • ‘Whether atomic types are permitted for bit-fields (C11 6.7.2.1).’
  
       Atomic types are not permitted for bit-fields.
  
!    • ‘Whether a bit-field can straddle a storage-unit boundary (C90
!      6.5.2.1, C99 and C11 6.7.2.1).’
  
       Determined by ABI.
  
!    • ‘The order of allocation of bit-fields within a unit (C90 6.5.2.1,
!      C99 and C11 6.7.2.1).’
  
       Determined by ABI.
  
!    • ‘The alignment of non-bit-field members of structures (C90 6.5.2.1,
!      C99 and C11 6.7.2.1).’
  
       Determined by ABI.
  
!    • ‘The integer type compatible with each enumerated type (C90
!      6.5.2.2, C99 and C11 6.7.2.2).’
  
!      Normally, the type is ‘unsigned int’ if there are no negative
!      values in the enumeration, otherwise ‘int’.  If ‘-fshort-enums’ is
       specified, then if there are negative values it is the first of
!      ‘signed char’, ‘short’ and ‘int’ that can represent all the values,
!      otherwise it is the first of ‘unsigned char’, ‘unsigned short’ and
!      ‘unsigned int’ that can represent all the values.
  
!      On some targets, ‘-fshort-enums’ is the default; this is determined
       by the ABI.
  
  
*************** File: gcc.info,  Node: Qualifiers implem
*** 33253,33260 ****
  4.10 Qualifiers
  ===============
  
!    * 'What constitutes an access to an object that has
!      volatile-qualified type (C90 6.5.3, C99 and C11 6.7.3).'
  
       Such an object is normally accessed by pointers and used for
       accessing hardware.  In most expressions, it is intuitively obvious
--- 33262,33269 ----
  4.10 Qualifiers
  ===============
  
!    • ‘What constitutes an access to an object that has
!      volatile-qualified type (C90 6.5.3, C99 and C11 6.7.3).’
  
       Such an object is normally accessed by pointers and used for
       accessing hardware.  In most expressions, it is intuitively obvious
*************** File: gcc.info,  Node: Qualifiers implem
*** 33267,33273 ****
       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
--- 33276,33282 ----
       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
*************** File: gcc.info,  Node: Qualifiers implem
*** 33277,33283 ****
            *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.
--- 33286,33292 ----
            *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.
*************** File: gcc.info,  Node: Qualifiers implem
*** 33289,33297 ****
       expression is only evaluated for its side effects.
  
       When an object of an aggregate type, with the same size and
!      alignment as a scalar type 'S', is the subject of a volatile access
       by an assignment expression or an atomic function, the access to it
!      is performed as if the object's declared type were 'volatile S'.
  
  
  File: gcc.info,  Node: Declarators implementation,  Next: Statements implementation,  Prev: Qualifiers implementation,  Up: C Implementation
--- 33298,33306 ----
       expression is only evaluated for its side effects.
  
       When an object of an aggregate type, with the same size and
!      alignment as a scalar type ‘S’, is the subject of a volatile access
       by an assignment expression or an atomic function, the access to it
!      is performed as if the object's declared type were ‘volatile S’.
  
  
  File: gcc.info,  Node: Declarators implementation,  Next: Statements implementation,  Prev: Qualifiers implementation,  Up: C Implementation
*************** File: gcc.info,  Node: Declarators imple
*** 33299,33306 ****
  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.
  
--- 33308,33315 ----
  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 implem
*** 33310,33317 ****
  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.
  
--- 33319,33326 ----
  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 dir
*** 33325,33373 ****
  behavior, for details of these aspects of implementation-defined
  behavior.
  
!    * 'The locations within '#pragma' directives where header name
!      preprocessing tokens are recognized (C11 6.4, C11 6.4.7).'
  
!    * 'How sequences in both forms of header names are mapped to headers
!      or external source file names (C90 6.1.7, C99 and C11 6.4.7).'
  
!    * 'Whether the value of a character constant in a constant expression
       that controls conditional inclusion matches the value of the same
       character constant in the execution character set (C90 6.8.1, C99
!      and C11 6.10.1).'
  
!    * 'Whether the value of a single-character character constant in a
       constant expression that controls conditional inclusion may have a
!      negative value (C90 6.8.1, C99 and C11 6.10.1).'
  
!    * 'The places that are searched for an included '<>' delimited
       header, and how the places are specified or the header is
!      identified (C90 6.8.2, C99 and C11 6.10.2).'
  
!    * 'How the named source file is searched for in an included '""'
!      delimited header (C90 6.8.2, C99 and C11 6.10.2).'
  
!    * 'The method by which preprocessing tokens (possibly resulting from
!      macro expansion) in a '#include' directive are combined into a
!      header name (C90 6.8.2, C99 and C11 6.10.2).'
  
!    * 'The nesting limit for '#include' processing (C90 6.8.2, C99 and
!      C11 6.10.2).'
  
!    * 'Whether the '#' operator inserts a '\' character before the '\'
       character that begins a universal character name in a character
!      constant or string literal (C99 and C11 6.10.3.2).'
  
!    * 'The behavior on each recognized non-'STDC #pragma' directive (C90
!      6.8.6, C99 and C11 6.10.6).'
  
       *Note Pragmas: (cpp)Pragmas, for details of pragmas accepted by GCC
       on all targets.  *Note Pragmas Accepted by GCC: Pragmas, for
       details of target-specific pragmas.
  
!    * 'The definitions for '__DATE__' and '__TIME__' when respectively,
       the date and time of translation are not available (C90 6.8.8, C99
!      6.10.8, C11 6.10.8.1).'
  
  
  File: gcc.info,  Node: Library functions implementation,  Next: Architecture implementation,  Prev: Preprocessing directives implementation,  Up: C Implementation
--- 33334,33382 ----
  behavior, for details of these aspects of implementation-defined
  behavior.
  
!    • ‘The locations within ‘#pragma’ directives where header name
!      preprocessing tokens are recognized (C11 6.4, C11 6.4.7).’
  
!    • ‘How sequences in both forms of header names are mapped to headers
!      or external source file names (C90 6.1.7, C99 and C11 6.4.7).’
  
!    • ‘Whether the value of a character constant in a constant expression
       that controls conditional inclusion matches the value of the same
       character constant in the execution character set (C90 6.8.1, C99
!      and C11 6.10.1).’
  
!    • ‘Whether the value of a single-character character constant in a
       constant expression that controls conditional inclusion may have a
!      negative value (C90 6.8.1, C99 and C11 6.10.1).’
  
!    • ‘The places that are searched for an included ‘<>’ delimited
       header, and how the places are specified or the header is
!      identified (C90 6.8.2, C99 and C11 6.10.2).’
  
!    • ‘How the named source file is searched for in an included ‘""’
!      delimited header (C90 6.8.2, C99 and C11 6.10.2).’
  
!    • ‘The method by which preprocessing tokens (possibly resulting from
!      macro expansion) in a ‘#include’ directive are combined into a
!      header name (C90 6.8.2, C99 and C11 6.10.2).’
  
!    • ‘The nesting limit for ‘#include’ processing (C90 6.8.2, C99 and
!      C11 6.10.2).’
  
!    • ‘Whether the ‘#’ operator inserts a ‘\’ character before the ‘\’
       character that begins a universal character name in a character
!      constant or string literal (C99 and C11 6.10.3.2).’
  
!    • ‘The behavior on each recognized non-‘STDC #pragma’ directive (C90
!      6.8.6, C99 and C11 6.10.6).’
  
       *Note Pragmas: (cpp)Pragmas, for details of pragmas accepted by GCC
       on all targets.  *Note Pragmas Accepted by GCC: Pragmas, for
       details of target-specific pragmas.
  
!    • ‘The definitions for ‘__DATE__’ and ‘__TIME__’ when respectively,
       the date and time of translation are not available (C90 6.8.8, C99
!      6.10.8, C11 6.10.8.1).’
  
  
  File: gcc.info,  Node: Library functions implementation,  Next: Architecture implementation,  Prev: Preprocessing directives implementation,  Up: C Implementation
*************** File: gcc.info,  Node: Library functions
*** 33378,33388 ****
  The behavior of most of these points are dependent on the implementation
  of the C library, and are not defined by GCC itself.
  
!    * 'The null pointer constant to which the macro 'NULL' expands (C90
!      7.1.6, C99 7.17, C11 7.19).'
  
!      In '', '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.
  
  
--- 33387,33397 ----
  The behavior of most of these points are dependent on the implementation
  of the C library, and are not defined by GCC itself.
  
!    • ‘The null pointer constant to which the macro ‘NULL’ expands (C90
!      7.1.6, C99 7.17, C11 7.19).’
  
!      In ‘’, ‘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 impl
*** 33391,33430 ****
  4.15 Architecture
  =================
  
!    * 'The values or expressions assigned to the macros specified in the
!      headers '', '', and '' (C90, C99 and
!      C11 5.2.4.2, C99 7.18.2, C99 7.18.3, C11 7.20.2, C11 7.20.3).'
  
       Determined by ABI.
  
!    * 'The result of attempting to indirectly access an object with
       automatic or thread storage duration from a thread other than the
!      one with which it is associated (C11 6.2.4).'
  
       Such accesses are supported, subject to the same requirements for
       synchronization for concurrent accesses as for concurrent accesses
       to any object.
  
!    * 'The number, order, and encoding of bytes in any object (when not
       explicitly specified in this International Standard) (C99 and C11
!      6.2.6.1).'
  
       Determined by ABI.
  
!    * 'Whether any extended alignments are supported and the contexts in
!      which they are supported (C11 6.2.8).'
  
       Extended alignments up to 2^{28} (bytes) are supported for objects
       of automatic storage duration.  Alignments supported for objects of
       static and thread storage duration are determined by the ABI.
  
!    * 'Valid alignment values other than those returned by an _Alignof
!      expression for fundamental types, if any (C11 6.2.8).'
  
       Valid alignments are powers of 2 up to and including 2^{28}.
  
!    * 'The value of the result of the 'sizeof' and '_Alignof' operators
!      (C90 6.3.3.4, C99 and C11 6.5.3.4).'
  
       Determined by ABI.
  
--- 33400,33439 ----
  4.15 Architecture
  =================
  
!    • ‘The values or expressions assigned to the macros specified in the
!      headers ‘’, ‘’, and ‘’ (C90, C99 and
!      C11 5.2.4.2, C99 7.18.2, C99 7.18.3, C11 7.20.2, C11 7.20.3).’
  
       Determined by ABI.
  
!    • ‘The result of attempting to indirectly access an object with
       automatic or thread storage duration from a thread other than the
!      one with which it is associated (C11 6.2.4).’
  
       Such accesses are supported, subject to the same requirements for
       synchronization for concurrent accesses as for concurrent accesses
       to any object.
  
!    • ‘The number, order, and encoding of bytes in any object (when not
       explicitly specified in this International Standard) (C99 and C11
!      6.2.6.1).’
  
       Determined by ABI.
  
!    • ‘Whether any extended alignments are supported and the contexts in
!      which they are supported (C11 6.2.8).’
  
       Extended alignments up to 2^{28} (bytes) are supported for objects
       of automatic storage duration.  Alignments supported for objects of
       static and thread storage duration are determined by the ABI.
  
!    • ‘Valid alignment values other than those returned by an _Alignof
!      expression for fundamental types, if any (C11 6.2.8).’
  
       Valid alignments are powers of 2 up to and including 2^{28}.
  
!    • ‘The value of the result of the ‘sizeof’ and ‘_Alignof’ operators
!      (C90 6.3.3.4, C99 and C11 6.5.3.4).’
  
       Determined by ABI.
  
*************** File: gcc.info,  Node: Conditionally-sup
*** 33472,33483 ****
  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 supported, using the same
       pass-by-invisible-reference approach used for normal function
--- 33481,33492 ----
  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 supported, using the same
       pass-by-invisible-reference approach used for normal function
*************** File: gcc.info,  Node: Exception handlin
*** 33489,33497 ****
  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.
  
--- 33498,33506 ----
  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,  Ne
*** 33502,33510 ****
  *************************************
  
  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
--- 33511,33519 ----
  *************************************
  
  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
*************** extensions, accepted by GCC in C90 mode
*** 33522,33531 ****
  * Nested Functions::    Nested function in GNU C.
  * Nonlocal Gotos::      Nonlocal gotos.
  * Constructing Calls::  Dispatching a call to another function.
! * Typeof::              'typeof': referring to the type of an expression.
! * Conditionals::        Omitting the middle operand of a '?:' expression.
! * __int128::		128-bit integers--'__int128'.
! * Long Long::           Double-word integers--'long long int'.
  * Complex::             Data types for complex numbers.
  * Floating Types::      Additional Floating Types.
  * Half-Precision::      Half-Precision Floating Point.
--- 33531,33540 ----
  * Nested Functions::    Nested function in GNU C.
  * Nonlocal Gotos::      Nonlocal gotos.
  * Constructing Calls::  Dispatching a call to another function.
! * Typeof::              ‘typeof’: referring to the type of an expression.
! * Conditionals::        Omitting the middle operand of a ‘?:’ expression.
! * __int128::		128-bit integers--‘__int128’.
! * Long Long::           Double-word integers--‘long long int’.
  * Complex::             Data types for complex numbers.
  * Floating Types::      Additional Floating Types.
  * Half-Precision::      Half-Precision Floating Point.
*************** extensions, accepted by GCC in C90 mode
*** 33539,33545 ****
  * 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.
  * Variadic Pointer Args::  Pointer arguments to variadic functions.
  * Pointers to Arrays::  Pointers to arrays with qualifiers work as expected.
  * Initializers::        Non-constant initializers.
--- 33548,33554 ----
  * 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.
  * Variadic Pointer Args::  Pointer arguments to variadic functions.
  * Pointers to Arrays::  Pointers to arrays with qualifiers work as expected.
  * Initializers::        Non-constant initializers.
*************** extensions, accepted by GCC in C90 mode
*** 33560,33577 ****
  * 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 .
  * Alignment::           Determining the alignment of a function, type or variable.
  * Inline::              Defining inline functions (as fast as macros).
  * Volatiles::           What constitutes an access to a volatile object.
  * Using Assembly Language with C:: Instructions and extensions for interfacing C with assembler.
! * Alternate Keywords::  '__const__', '__asm__', etc., for header files.
! * Incomplete Enums::    'enum foo;', with details to follow.
  * Function Names::      Printable strings which are the name of the current
                          function.
  * Return Address::      Getting the return or frame address of a function.
  * Vector Extensions::   Using vector instructions through built-in functions.
! * Offsetof::            Special syntax for implementing 'offsetof'.
  * __sync Builtins::     Legacy built-in functions for atomic memory access.
  * __atomic Builtins::   Atomic built-in functions with memory model.
  * Integer Overflow Builtins:: Built-in functions to perform arithmetics and
--- 33569,33586 ----
  * 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 .
  * Alignment::           Determining the alignment of a function, type or variable.
  * Inline::              Defining inline functions (as fast as macros).
  * Volatiles::           What constitutes an access to a volatile object.
  * Using Assembly Language with C:: Instructions and extensions for interfacing C with assembler.
! * Alternate Keywords::  ‘__const__’, ‘__asm__’, etc., for header files.
! * Incomplete Enums::    ‘enum foo;’, with details to follow.
  * Function Names::      Printable strings which are the name of the current
                          function.
  * Return Address::      Getting the return or frame address of a function.
  * Vector Extensions::   Using vector instructions through built-in functions.
! * Offsetof::            Special syntax for implementing ‘offsetof’.
  * __sync Builtins::     Legacy built-in functions for atomic memory access.
  * __atomic Builtins::   Atomic built-in functions with memory model.
  * Integer Overflow Builtins:: Built-in functions to perform arithmetics and
*************** extensions, accepted by GCC in C90 mode
*** 33585,33591 ****
  * 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
--- 33594,33600 ----
  * 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
*************** example:
*** 33607,33618 ****
          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"
--- 33616,33627 ----
          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"
*************** follows:
*** 33624,33637 ****
  
  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 avoid this problem by defining
  the macro as follows:
  
       #define maxint(a,b) \
         ({int _a = (a), _b = (b); _a > _b ? _a : _b; })
  
!  Note that introducing variable declarations (as we do in 'maxint') can
! cause variable shadowing, so while this example using the 'max' macro
  produces correct results:
       int _a = 1, _b = 2, c;
       c = max (_a, _b);
--- 33633,33646 ----
  
  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 avoid this problem by defining
  the macro as follows:
  
       #define maxint(a,b) \
         ({int _a = (a), _b = (b); _a > _b ? _a : _b; })
  
!  Note that introducing variable declarations (as we do in ‘maxint’) can
! cause variable shadowing, so while this example using the ‘max’ macro
  produces correct results:
       int _a = 1, _b = 2, c;
       c = max (_a, _b);
*************** the value of an enumeration constant, th
*** 33650,33668 ****
  initial value of a static variable.
  
   If you don't know the type of the operand, you can still do this, but
! you must use 'typeof' or '__auto_type' (*note Typeof::).
  
   In G++, the result value of a statement expression undergoes array and
  function pointer decay, and is returned by value to the enclosing
! expression.  For instance, if 'A' is a class, then
  
               A a;
  
               ({a;}).Foo ()
  
! constructs a temporary 'A' object to hold the result of the statement
! expression, and that is used to invoke 'Foo'.  Therefore the 'this'
! pointer observed by 'Foo' is not the address of 'a'.
  
   In a statement expression, any temporaries created within a statement
  are destroyed at that statement's end.  This makes statement expressions
--- 33659,33677 ----
  initial value of a static variable.
  
   If you don't know the type of the operand, you can still do this, but
! you must use ‘typeof’ or ‘__auto_type’ (*note Typeof::).
  
   In G++, the result value of a statement expression undergoes array and
  function pointer decay, and is returned by value to the enclosing
! expression.  For instance, if ‘A’ is a class, then
  
               A a;
  
               ({a;}).Foo ()
  
! constructs a temporary ‘A’ object to hold the result of the statement
! expression, and that is used to invoke ‘Foo’.  Therefore the ‘this’
! pointer observed by ‘Foo’ is not the address of ‘a’.
  
   In a statement expression, any temporaries created within a statement
  are destroyed at that statement's end.  This makes statement expressions
*************** expression.  For instance,
*** 33681,33689 ****
         function (X ());
       }
  
! has different places where temporaries are destroyed.  For the 'macro'
! case, the temporary 'X' is destroyed just after the initialization of
! 'b'.  In the 'function' case that temporary is destroyed when the
  function returns.
  
   These considerations mean that it is probably a bad idea to use
--- 33690,33698 ----
         function (X ());
       }
  
! has different places where temporaries are destroyed.  For the ‘macro’
! case, the temporary ‘X’ is destroyed just after the initialization of
! ‘b’.  In the ‘function’ case that temporary is destroyed when the
  function returns.
  
   These considerations mean that it is probably a bad idea to use
*************** work with C++.  (Note that some versions
*** 33692,33711 ****
  header files using statement expressions that lead to precisely this
  bug.)
  
!  Jumping into a statement expression with 'goto' or using a 'switch'
! statement outside the statement expression with a 'case' or 'default'
  label inside the statement expression is not permitted.  Jumping into a
! statement expression with a computed 'goto' (*note Labels as Values::)
  has undefined behavior.  Jumping out of a statement expression is
  permitted, but if the statement expression is part of a larger
  expression then it is unspecified which other subexpressions of that
  expression have been evaluated except where the language definition
  requires certain subexpressions to be evaluated before or after the
! statement expression.  A 'break' or 'continue' statement inside of a
! statement expression used in 'while', 'do' or 'for' loop or 'switch'
! statement condition or 'for' statement init or increment expressions
! jumps to an outer loop or 'switch' statement if any (otherwise it is an
! error), rather than to the loop or 'switch' statement in whose condition
  or init or increment expression it appears.  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
--- 33701,33720 ----
  header files using statement expressions that lead to precisely this
  bug.)
  
!  Jumping into a statement expression with ‘goto’ or using a ‘switch’
! statement outside the statement expression with a ‘case’ or ‘default’
  label inside the statement expression is not permitted.  Jumping into a
! statement expression with a computed ‘goto’ (*note Labels as Values::)
  has undefined behavior.  Jumping out of a statement expression is
  permitted, but if the statement expression is part of a larger
  expression then it is unspecified which other subexpressions of that
  expression have been evaluated except where the language definition
  requires certain subexpressions to be evaluated before or after the
! statement expression.  A ‘break’ or ‘continue’ statement inside of a
! statement expression used in ‘while’, ‘do’ or ‘for’ loop or ‘switch’
! statement condition or ‘for’ statement init or increment expressions
! jumps to an outer loop or ‘switch’ statement if any (otherwise it is an
! error), rather than to the loop or ‘switch’ statement in whose condition
  or init or increment expression it appears.  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,
*** 33713,33721 ****
  
         foo (), (({ bar1 (); goto a; 0; }) + bar2 ()), baz();
  
! calls 'foo' and 'bar1' and does not call 'baz' but may or may not call
! 'bar2'.  If 'bar2' is called, it is called after 'foo' and before
! 'bar1'.
  
  
  File: gcc.info,  Node: Local Labels,  Next: Labels as Values,  Prev: Statement Exprs,  Up: C Extensions
--- 33722,33730 ----
  
         foo (), (({ bar1 (); goto a; 0; }) + bar2 ()), baz();
  
! calls ‘foo’ and ‘bar1’ and does not call ‘baz’ but may or may not call
! ‘bar2’.  If ‘bar2’ is called, it is called after ‘foo’ and before
! ‘bar1’.
  
  
  File: gcc.info,  Node: Local Labels,  Next: Labels as Values,  Prev: Statement Exprs,  Up: C Extensions
*************** File: gcc.info,  Node: Local Labels,  Ne
*** 33723,33731 ****
  6.2 Locally Declared Labels
  ===========================
  
! GCC allows you to declare "local labels" in any nested block scope.  A
  local label is just like an ordinary label, but you can only reference
! it (with a 'goto' statement, or by taking its address) within the block
  in which it is declared.
  
   A local label declaration looks like this:
--- 33732,33740 ----
  6.2 Locally Declared Labels
  ===========================
  
! GCC allows you to declare “local labels” in any nested block scope.  A
  local label is just like an ordinary label, but you can only reference
! it (with a ‘goto’ statement, or by taking its address) within the block
  in which it is declared.
  
   A local label declaration looks like this:
*************** or
*** 33740,33750 ****
  before any ordinary declarations or statements.
  
   The label declaration defines the label _name_, but does not define the
! label itself.  You must do this in the usual way, with 'LABEL:', within
  the statements of the statement expression.
  
   The local label feature is useful for complex macros.  If a macro
! contains nested loops, a 'goto' can be useful for breaking out of them.
  However, an ordinary label whose scope is the whole function cannot be
  used: if the macro can be expanded several times in one function, the
  label is multiply defined in that function.  A local label avoids this
--- 33749,33759 ----
  before any ordinary declarations or statements.
  
   The label declaration defines the label _name_, but does not define the
! label itself.  You must do this in the usual way, with ‘LABEL:’, within
  the statements of the statement expression.
  
   The local label feature is useful for complex macros.  If a macro
! contains nested loops, a ‘goto’ can be useful for breaking out of them.
  However, an ordinary label whose scope is the whole function cannot be
  used: if the macro can be expanded several times in one function, the
  label is multiply defined in that function.  A local label avoids this
*************** File: gcc.info,  Node: Labels as Values,
*** 33794,33801 ****
  ====================
  
  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;
--- 33803,33810 ----
  ====================
  
  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;
*************** of that type is valid.  For example:
*** 33803,33813 ****
       ptr = &&foo;
  
   To use these values, you need to be able to jump to one.  This is done
! with the computed goto statement(1), 'goto *EXP;'.  For example,
  
       goto *ptr;
  
! Any expression of type 'void *' is allowed.
  
   One way of using these constants is in initializing a static array that
  serves as a jump table:
--- 33812,33822 ----
       ptr = &&foo;
  
   To use these values, you need to be able to jump to one.  This is done
! with the computed goto statement(1), ‘goto *EXP;’.  For example,
  
       goto *ptr;
  
! Any expression of type ‘void *’ is allowed.
  
   One way of using these constants is in initializing a static array that
  serves as a jump table:
*************** Note that this does not check whether th
*** 33822,33829 ****
  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.
--- 33831,33838 ----
  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.
*************** allows the data to be read-only.  This a
*** 33847,33856 ****
  differences is not supported for the AVR target, please use the first
  approach for AVR programs.
  
!  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 ----------
--- 33856,33865 ----
  differences is not supported for the AVR target, please use the first
  approach for AVR programs.
  
!  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 ----------
*************** File: gcc.info,  Node: Nested Functions,
*** 33865,33876 ****
  6.4 Nested Functions
  ====================
  
! A "nested function" is a function defined inside another function.
  Nested functions are supported as an extension in GNU C, but are not
  supported by GNU C++.
  
   The nested function's name is local to the block where it is defined.
! For example, here we define a nested function named 'square', and call
  it twice:
  
       foo (double a, double b)
--- 33874,33885 ----
  6.4 Nested Functions
  ====================
  
! A “nested function” is a function defined inside another function.
  Nested functions are supported as an extension in GNU C, but are not
  supported by GNU C++.
  
   The nested function's name is local to the block where it is defined.
! For example, here we define a nested function named ‘square’, and call
  it twice:
  
       foo (double a, double b)
*************** it twice:
*** 33882,33889 ****
  
   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)
       {
--- 33891,33898 ----
  
   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)
       {
*************** function:
*** 33911,33920 ****
         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
--- 33920,33929 ----
         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
*************** wise to take the risk.  If, however, the
*** 33925,33938 ****
  to anything that has gone out of scope, you should be safe.
  
   GCC implements taking the address of a nested function using a
! technique called "trampolines".  This technique was described in
! 'Lexical Closures for C++' (Thomas M. Breuel, USENIX C++ Conference
  Proceedings, October 17-21, 1988).
  
   A nested function can jump to a label inherited from a containing
  function, provided the label is explicitly declared in the containing
  function (*note Local Labels::).  Such a jump returns instantly to the
! containing function, exiting the nested function that did the 'goto' and
  any intermediate functions as well.  Here is an example:
  
       bar (int *array, int offset, int size)
--- 33934,33947 ----
  to anything that has gone out of scope, you should be safe.
  
   GCC implements taking the address of a nested function using a
! technique called “trampolines”.  This technique was described in
! ‘Lexical Closures for C++’ (Thomas M. Breuel, USENIX C++ Conference
  Proceedings, October 17-21, 1988).
  
   A nested function can jump to a label inherited from a containing
  function, provided the label is explicitly declared in the containing
  function (*note Local Labels::).  Such a jump returns instantly to the
! containing function, exiting the nested function that did the ‘goto’ and
  any intermediate functions as well.  Here is an example:
  
       bar (int *array, int offset, int size)
*************** any intermediate functions as well.  Her
*** 33951,33965 ****
         /* ... */
         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)
--- 33960,33974 ----
         /* ... */
         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)
*************** File: gcc.info,  Node: Nonlocal Gotos,
*** 33982,33993 ****
  6.5 Nonlocal Gotos
  ==================
  
! GCC provides the built-in functions '__builtin_setjmp' and
! '__builtin_longjmp' which are similar to, but not interchangeable with,
! the C library functions 'setjmp' and 'longjmp'.  The built-in versions
  are used internally by GCC's libraries to implement exception handling
  on some targets.  You should use the standard C library functions
! declared in '' in user code instead of the builtins.
  
   The built-in versions of these functions use GCC's normal mechanisms to
  save and restore registers using the stack on function entry and exit.
--- 33991,34002 ----
  6.5 Nonlocal Gotos
  ==================
  
! GCC provides the built-in functions ‘__builtin_setjmp’ and
! ‘__builtin_longjmp’ which are similar to, but not interchangeable with,
! the C library functions ‘setjmp’ and ‘longjmp’.  The built-in versions
  are used internally by GCC's libraries to implement exception handling
  on some targets.  You should use the standard C library functions
! declared in ‘’ in user code instead of the builtins.
  
   The built-in versions of these functions use GCC's normal mechanisms to
  save and restore registers using the stack on function entry and exit.
*************** values.
*** 33997,34003 ****
  
   An important caveat is that GCC arranges to save and restore only those
  registers known to the specific architecture variant being compiled for.
! This can make '__builtin_setjmp' and '__builtin_longjmp' more efficient
  than their library counterparts in some cases, but it can also cause
  incorrect and mysterious behavior when mixing with code that uses the
  full register set.
--- 34006,34012 ----
  
   An important caveat is that GCC arranges to save and restore only those
  registers known to the specific architecture variant being compiled for.
! This can make ‘__builtin_setjmp’ and ‘__builtin_longjmp’ more efficient
  than their library counterparts in some cases, but it can also cause
  incorrect and mysterious behavior when mixing with code that uses the
  full register set.
*************** functions as:
*** 34010,34029 ****
  
   -- Built-in Function: int __builtin_setjmp (intptr_t *BUF)
       This function saves the current stack context in BUF.
!      '__builtin_setjmp' returns 0 when returning directly, and 1 when
!      returning from '__builtin_longjmp' using the same BUF.
  
   -- Built-in Function: void __builtin_longjmp (intptr_t *BUF, int VAL)
       This function restores the stack context in BUF, saved by a
!      previous call to '__builtin_setjmp'.  After '__builtin_longjmp' is
       finished, the program resumes execution as if the matching
!      '__builtin_setjmp' returns the value VAL, which must be 1.
  
!      Because '__builtin_longjmp' depends on the function return
       mechanism to restore the stack context, it cannot be called from
!      the same function calling '__builtin_setjmp' to initialize BUF.  It
       can only be called from a function called (directly or indirectly)
!      from the function calling '__builtin_setjmp'.
  
  
  File: gcc.info,  Node: Constructing Calls,  Next: Typeof,  Prev: Nonlocal Gotos,  Up: C Extensions
--- 34019,34038 ----
  
   -- Built-in Function: int __builtin_setjmp (intptr_t *BUF)
       This function saves the current stack context in BUF.
!      ‘__builtin_setjmp’ returns 0 when returning directly, and 1 when
!      returning from ‘__builtin_longjmp’ using the same BUF.
  
   -- Built-in Function: void __builtin_longjmp (intptr_t *BUF, int VAL)
       This function restores the stack context in BUF, saved by a
!      previous call to ‘__builtin_setjmp’.  After ‘__builtin_longjmp’ is
       finished, the program resumes execution as if the matching
!      ‘__builtin_setjmp’ returns the value VAL, which must be 1.
  
!      Because ‘__builtin_longjmp’ depends on the function return
       mechanism to restore the stack context, it cannot be called from
!      the same function calling ‘__builtin_setjmp’ to initialize BUF.  It
       can only be called from a function called (directly or indirectly)
!      from the function calling ‘__builtin_setjmp’.
  
  
  File: gcc.info,  Node: Constructing Calls,  Next: Typeof,  Prev: Nonlocal Gotos,  Up: C Extensions
*************** acting as mere forwarders for their argu
*** 34060,34066 ****
       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
--- 34069,34075 ----
       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
*************** acting as mere forwarders for their argu
*** 34068,34088 ****
       block of memory allocated on the stack.
  
       It is not always simple to compute the proper value for SIZE.  The
!      value is used by '__builtin_apply' to compute the amount of data
       that should be pushed on the stack and copied from the incoming
       argument area.
  
   -- Built-in Function: void __builtin_return (void *RESULT)
       This built-in function returns the value described by RESULT from
       the containing function.  You should specify, for RESULT, a value
!      returned by '__builtin_apply'.
  
   -- Built-in Function: __builtin_va_arg_pack ()
       This built-in function represents all anonymous arguments of an
       inline function.  It can be used only in inline functions that are
       always inlined, never compiled as a separate function, such as
!      those using '__attribute__ ((__always_inline__))' or '__attribute__
!      ((__gnu_inline__))' extern inline functions.  It must be only
       passed as last argument to some other function with variable
       arguments.  This is useful for writing small wrapper inlines for
       variable argument functions, when using preprocessor macros is
--- 34077,34097 ----
       block of memory allocated on the stack.
  
       It is not always simple to compute the proper value for SIZE.  The
!      value is used by ‘__builtin_apply’ to compute the amount of data
       that should be pushed on the stack and copied from the incoming
       argument area.
  
   -- Built-in Function: void __builtin_return (void *RESULT)
       This built-in function returns the value described by RESULT from
       the containing function.  You should specify, for RESULT, a value
!      returned by ‘__builtin_apply’.
  
   -- Built-in Function: __builtin_va_arg_pack ()
       This built-in function represents all anonymous arguments of an
       inline function.  It can be used only in inline functions that are
       always inlined, never compiled as a separate function, such as
!      those using ‘__attribute__ ((__always_inline__))’ or ‘__attribute__
!      ((__gnu_inline__))’ extern inline functions.  It must be only
       passed as last argument to some other function with variable
       arguments.  This is useful for writing small wrapper inlines for
       variable argument functions, when using preprocessor macros is
*************** acting as mere forwarders for their argu
*** 34104,34111 ****
       This built-in function returns the number of anonymous arguments of
       an inline function.  It can be used only in inline functions that
       are always inlined, never compiled as a separate function, such as
!      those using '__attribute__ ((__always_inline__))' or '__attribute__
!      ((__gnu_inline__))' extern inline functions.  For example following
       does link- or run-time checking of open arguments for optimized
       code:
            #ifdef __OPTIMIZE__
--- 34113,34120 ----
       This built-in function returns the number of anonymous arguments of
       an inline function.  It can be used only in inline functions that
       are always inlined, never compiled as a separate function, such as
!      those using ‘__attribute__ ((__always_inline__))’ or ‘__attribute__
!      ((__gnu_inline__))’ extern inline functions.  For example following
       does link- or run-time checking of open arguments for optimized
       code:
            #ifdef __OPTIMIZE__
*************** acting as mere forwarders for their argu
*** 34135,34174 ****
  
  File: gcc.info,  Node: Typeof,  Next: Conditionals,  Prev: Constructing Calls,  Up: C Extensions
  
! 6.7 Referring to a Type with 'typeof'
  =====================================
  
! Another way to refer to the type of an expression is with 'typeof'.  The
! syntax of using of this keyword looks like 'sizeof', but the construct
! acts semantically like a type name defined with 'typedef'.
  
!  There are two ways of writing the argument to 'typeof': with an
  expression or with a type.  Here is an example with an expression:
  
       typeof (x[0](1))
  
! This assumes that 'x' is an array of pointers to functions; the type
  described is that of the values of the functions.
  
   Here is an example with a typename as the argument:
  
       typeof (int *)
  
! Here the type described is that of pointers to 'int'.
  
   If you are writing a header file that must work when included in ISO C
! programs, write '__typeof__' instead of 'typeof'.  *Note Alternate
  Keywords::.
  
!  A 'typeof' construct can be used anywhere a typedef name can be used.
  For example, you can use it in a declaration, in a cast, or inside of
! 'sizeof' or 'typeof'.
  
!  The operand of 'typeof' is evaluated for its side effects if and only
  if it is an expression of variably modified type or the name of such a
  type.
  
!  'typeof' is often useful in conjunction with statement expressions
  (*note Statement Exprs::).  Here is how the two together can be used to
  define a safe "maximum" macro which operates on any arithmetic type and
  evaluates each of its arguments exactly once:
--- 34144,34183 ----
  
  File: gcc.info,  Node: Typeof,  Next: Conditionals,  Prev: Constructing Calls,  Up: C Extensions
  
! 6.7 Referring to a Type with ‘typeof’
  =====================================
  
! Another way to refer to the type of an expression is with ‘typeof’.  The
! syntax of using of this keyword looks like ‘sizeof’, but the construct
! acts semantically like a type name defined with ‘typedef’.
  
!  There are two ways of writing the argument to ‘typeof’: with an
  expression or with a type.  Here is an example with an expression:
  
       typeof (x[0](1))
  
! This assumes that ‘x’ is an array of pointers to functions; the type
  described is that of the values of the functions.
  
   Here is an example with a typename as the argument:
  
       typeof (int *)
  
! Here the type described is that of pointers to ‘int’.
  
   If you are writing a header file that must work when included in ISO C
! programs, write ‘__typeof__’ instead of ‘typeof’.  *Note Alternate
  Keywords::.
  
!  A ‘typeof’ construct can be used anywhere a typedef name can be used.
  For example, you can use it in a declaration, in a cast, or inside of
! ‘sizeof’ or ‘typeof’.
  
!  The operand of ‘typeof’ is evaluated for its side effects if and only
  if it is an expression of variably modified type or the name of such a
  type.
  
!  ‘typeof’ is often useful in conjunction with statement expressions
  (*note Statement Exprs::).  Here is how the two together can be used to
  define a safe "maximum" macro which operates on any arithmetic type and
  evaluates each of its arguments exactly once:
*************** evaluates each of its arguments exactly
*** 34180,34201 ****
  
   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;
  
--- 34189,34210 ----
  
   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;
  
*************** Some more examples of the use of 'typeof
*** 34203,34209 ****
  
            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 *)
--- 34212,34218 ----
  
            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 *)
*************** Some more examples of the use of 'typeof
*** 34213,34243 ****
  
            array (pointer (char), 4) y;
  
!      Thus, 'array (pointer (char), 4)' is the type of arrays of 4
!      pointers to 'char'.
  
   In GNU C, but not GNU C++, you may also declare the type of a variable
! as '__auto_type'.  In that case, the declaration must declare only one
  variable, whose declarator must just be an identifier, the declaration
  must be initialized, and the type of the variable is determined by the
  initializer; the name of the variable is not in scope until after the
! initializer.  (In C++, you should use C++11 'auto' for this purpose.)
! Using '__auto_type', the "maximum" macro above could be written as:
  
       #define max(a,b) \
         ({ __auto_type _a = (a); \
             __auto_type _b = (b); \
           _a > _b ? _a : _b; })
  
!  Using '__auto_type' instead of 'typeof' has two advantages:
  
!    * Each argument to the macro appears only once in the expansion of
       the macro.  This prevents the size of the macro expansion growing
       exponentially when calls to such macros are nested inside arguments
       of such macros.
  
!    * If the argument to the macro has variably modified type, it is
!      evaluated only once when using '__auto_type', but twice if 'typeof'
       is used.
  
  
--- 34222,34252 ----
  
            array (pointer (char), 4) y;
  
!      Thus, ‘array (pointer (char), 4)’ is the type of arrays of 4
!      pointers to ‘char’.
  
   In GNU C, but not GNU C++, you may also declare the type of a variable
! as ‘__auto_type’.  In that case, the declaration must declare only one
  variable, whose declarator must just be an identifier, the declaration
  must be initialized, and the type of the variable is determined by the
  initializer; the name of the variable is not in scope until after the
! initializer.  (In C++, you should use C++11 ‘auto’ for this purpose.)
! Using ‘__auto_type’, the "maximum" macro above could be written as:
  
       #define max(a,b) \
         ({ __auto_type _a = (a); \
             __auto_type _b = (b); \
           _a > _b ? _a : _b; })
  
!  Using ‘__auto_type’ instead of ‘typeof’ has two advantages:
  
!    • Each argument to the macro appears only once in the expansion of
       the macro.  This prevents the size of the macro expansion growing
       exponentially when calls to such macros are nested inside arguments
       of such macros.
  
!    • If the argument to the macro has variably modified type, it is
!      evaluated only once when using ‘__auto_type’, but twice if ‘typeof’
       is used.
  
  
*************** expression.
*** 34254,34260 ****
  
       x ? : y
  
! has the value of 'x' if that is nonzero; otherwise, the value of 'y'.
  
   This example is perfectly equivalent to
  
--- 34263,34269 ----
  
       x ? : y
  
! has the value of ‘x’ if that is nonzero; otherwise, the value of ‘y’.
  
   This example is perfectly equivalent to
  
*************** File: gcc.info,  Node: __int128,  Next:
*** 34273,34284 ****
  6.9 128-bit Integers
  ====================
  
! As an extension the integer scalar type '__int128' is supported for
  targets which have an integer mode wide enough to hold 128 bits.  Simply
! write '__int128' for a signed 128-bit integer, or 'unsigned __int128'
  for an unsigned 128-bit integer.  There is no support in GCC for
! expressing an integer constant of type '__int128' for targets with 'long
! long' integer less than 128 bits wide.
  
  
  File: gcc.info,  Node: Long Long,  Next: Complex,  Prev: __int128,  Up: C Extensions
--- 34282,34293 ----
  6.9 128-bit Integers
  ====================
  
! As an extension the integer scalar type ‘__int128’ is supported for
  targets which have an integer mode wide enough to hold 128 bits.  Simply
! write ‘__int128’ for a signed 128-bit integer, or ‘unsigned __int128’
  for an unsigned 128-bit integer.  There is no support in GCC for
! expressing an integer constant of type ‘__int128’ for targets with ‘long
! long’ integer less than 128 bits wide.
  
  
  File: gcc.info,  Node: Long Long,  Next: Complex,  Prev: __int128,  Up: C Extensions
*************** File: gcc.info,  Node: Long Long,  Next:
*** 34288,34297 ****
  
  ISO C99 and ISO C++11 support data types for integers that are at least
  64 bits wide, and as an extension GCC supports them in C90 and C++98
! modes.  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.
--- 34297,34306 ----
  
  ISO C99 and ISO C++11 support data types for integers that are at least
  64 bits wide, and as an extension GCC supports them in C90 and C++98
! modes.  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.
*************** instruction.  Division and shifts are op
*** 34302,34313 ****
  provide special support.  The operations that are not open-coded use
  special library routines that come with GCC.
  
!  There may be pitfalls when you use 'long long' types for function
! arguments without function prototypes.  If a function expects type 'int'
! for its argument, and you pass a value of type 'long long int',
  confusion results because the caller and the subroutine disagree about
  the number of bytes for the argument.  Likewise, if the function expects
! 'long long int' and you pass 'int'.  The best way to avoid such problems
  is to use prototypes.
  
  
--- 34311,34322 ----
  provide special support.  The operations that are not open-coded use
  special library routines that come with GCC.
  
!  There may be pitfalls when you use ‘long long’ types for function
! arguments without function prototypes.  If a function expects type ‘int’
! for its argument, and you pass a value of type ‘long long int’,
  confusion results because the caller and the subroutine disagree about
  the number of bytes for the argument.  Likewise, if the function expects
! ‘long long int’ and you pass ‘int’.  The best way to avoid such problems
  is to use prototypes.
  
  
*************** File: gcc.info,  Node: Complex,  Next: F
*** 34319,34385 ****
  ISO C99 supports complex floating data types, and as an extension GCC
  supports them in C90 mode and in C++.  GCC also supports complex integer
  data types which are not part of ISO C99.  You can declare complex types
! using the keyword '_Complex'.  As an extension, the older GNU keyword
! '__complex__' is also supported.
  
!  For example, '_Complex double x;' declares 'x' as a variable whose real
! part and imaginary part are both of type 'double'.  '_Complex short int
! y;' declares 'y' to have real and imaginary parts of type 'short int';
  this is not likely to be useful, but it shows that the set of complex
  types is complete.
  
!  To write a constant with a complex data type, use the suffix 'i' or 'j'
! (either one; they are equivalent).  For example, '2.5fi' has type
! '_Complex float' and '3i' has type '_Complex int'.  Such a constant
  always has a pure imaginary value, but you can form any complex value
  you like by adding one to a real constant.  This is a GNU extension; if
  you have an ISO C99 conforming C library (such as the GNU C Library),
  and want to construct complex constants of floating type, you should
! include '' and use the macros 'I' or '_Complex_I' instead.
  
!  The ISO C++14 library also defines the 'i' suffix, so C++14 code that
! includes the '' header cannot use 'i' for the GNU extension.
! The 'j' suffix still has the GNU meaning.
  
!  GCC can handle both implicit and explicit casts between the '_Complex'
! types and other '_Complex' types as casting both the real and imaginary
  parts to the scalar type.  GCC can handle implicit and explicit casts
! from a scalar type to a '_Complex' type and where the imaginary part
  will be considered zero.  The C front-end can handle implicit and
! explicit casts from a '_Complex' type to a scalar type where the
  imaginary part will be ignored.  In C++ code, this cast is considered
  illformed and G++ will error out.
  
!  GCC provides a built-in function '__builtin_complex' will can be used
  to construct a complex value.
  
   GCC has a few extensions which can be used to extract the real and the
  imaginary part of the complex-valued expression.  Note these expressions
  are lvalues if the EXP is an lvalue.  These expressions operands have
  the type of a complex type which might get prompoted to a complex type
! from a scalar type.  E.g.  '__real__ (int)X' is the same as casting to
! '_Complex int' before '__real__' is done.
  
  Expression                    Description
  --------------------------------------------------------------------------
! '__real__ EXP'                Extract the real part of EXP.
! '__imag__ EXP'                Extract the imaginary part of EXP.
  
   For values of floating point, you should use the ISO C99 functions,
! declared in '' and also provided as built-in functions by
  GCC.
  
  Expression                    float          double         long double
  ---------------------------------------------------------------------------
! '__real__ EXP'                'crealf'       'creal'        'creall'
! '__imag__ EXP'                'cimagf'       'cimag'        'cimagl'
  
!  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 '' and also provided as built-in functions by
! GCC.  Note unlike the '__real__' and '__imag__' operators, this operator
! will not do an implicit cast to the complex type because the '~' is
  already a normal operator.
  
   GCC can allocate complex automatic variables in a noncontiguous
--- 34328,34394 ----
  ISO C99 supports complex floating data types, and as an extension GCC
  supports them in C90 mode and in C++.  GCC also supports complex integer
  data types which are not part of ISO C99.  You can declare complex types
! using the keyword ‘_Complex’.  As an extension, the older GNU keyword
! ‘__complex__’ is also supported.
  
!  For example, ‘_Complex double x;’ declares ‘x’ as a variable whose real
! part and imaginary part are both of type ‘double’.  ‘_Complex short int
! y;’ declares ‘y’ to have real and imaginary parts of type ‘short int’;
  this is not likely to be useful, but it shows that the set of complex
  types is complete.
  
!  To write a constant with a complex data type, use the suffix ‘i’ or ‘j’
! (either one; they are equivalent).  For example, ‘2.5fi’ has type
! ‘_Complex float’ and ‘3i’ has type ‘_Complex int’.  Such a constant
  always has a pure imaginary value, but you can form any complex value
  you like by adding one to a real constant.  This is a GNU extension; if
  you have an ISO C99 conforming C library (such as the GNU C Library),
  and want to construct complex constants of floating type, you should
! include ‘’ and use the macros ‘I’ or ‘_Complex_I’ instead.
  
!  The ISO C++14 library also defines the ‘i’ suffix, so C++14 code that
! includes the ‘’ header cannot use ‘i’ for the GNU extension.
! The ‘j’ suffix still has the GNU meaning.
  
!  GCC can handle both implicit and explicit casts between the ‘_Complex’
! types and other ‘_Complex’ types as casting both the real and imaginary
  parts to the scalar type.  GCC can handle implicit and explicit casts
! from a scalar type to a ‘_Complex’ type and where the imaginary part
  will be considered zero.  The C front-end can handle implicit and
! explicit casts from a ‘_Complex’ type to a scalar type where the
  imaginary part will be ignored.  In C++ code, this cast is considered
  illformed and G++ will error out.
  
!  GCC provides a built-in function ‘__builtin_complex’ will can be used
  to construct a complex value.
  
   GCC has a few extensions which can be used to extract the real and the
  imaginary part of the complex-valued expression.  Note these expressions
  are lvalues if the EXP is an lvalue.  These expressions operands have
  the type of a complex type which might get prompoted to a complex type
! from a scalar type.  E.g.  ‘__real__ (int)X’ is the same as casting to
! ‘_Complex int’ before ‘__real__’ is done.
  
  Expression                    Description
  --------------------------------------------------------------------------
! ‘__real__ EXP’                Extract the real part of EXP.
! ‘__imag__ EXP’                Extract the imaginary part of EXP.
  
   For values of floating point, you should use the ISO C99 functions,
! declared in ‘’ and also provided as built-in functions by
  GCC.
  
  Expression                    float          double         long double
  ---------------------------------------------------------------------------
! ‘__real__ EXP’                ‘crealf’       ‘creal’        ‘creall’
! ‘__imag__ EXP’                ‘cimagf’       ‘cimag’        ‘cimagl’
  
!  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 ‘’ and also provided as built-in functions by
! GCC.  Note unlike the ‘__real__’ and ‘__imag__’ operators, this operator
! will not do an implicit cast to the complex type because the ‘~’ is
  already a normal operator.
  
   GCC can allocate complex automatic variables in a noncontiguous
*************** the imaginary part is on the stack (or v
*** 34388,34404 ****
  debug info format can represent this, so use of DWARF 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.
  
   -- Built-in Function: TYPE __builtin_complex (REAL, IMAG)
  
!      The built-in function '__builtin_complex' is provided for use in
!      implementing the ISO C11 macros 'CMPLXF', 'CMPLX' and 'CMPLXL'.
       REAL and IMAG must have the same type, a real binary floating-point
       type, and the result has the corresponding complex type with real
!      and imaginary parts REAL and IMAG.  Unlike 'REAL + I * IMAG', this
       works even when infinities, NaNs and negative zeros are involved.
  
  
--- 34397,34413 ----
  debug info format can represent this, so use of DWARF 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.
  
   -- Built-in Function: TYPE __builtin_complex (REAL, IMAG)
  
!      The built-in function ‘__builtin_complex’ is provided for use in
!      implementing the ISO C11 macros ‘CMPLXF’, ‘CMPLX’ and ‘CMPLXL’.
       REAL and IMAG must have the same type, a real binary floating-point
       type, and the result has the corresponding complex type with real
!      and imaginary parts REAL and IMAG.  Unlike ‘REAL + I * IMAG’, this
       works even when infinities, NaNs and negative zeros are involved.
  
  
*************** File: gcc.info,  Node: Floating Types,
*** 34408,34470 ****
  ==============================
  
  ISO/IEC TS 18661-3:2015 defines C support for additional floating types
! '_FloatN' and '_FloatNx', and GCC supports these type names; the set of
  types supported depends on the target architecture.  Constants with
! these types use suffixes 'fN' or 'FN' and 'fNx' or 'FNx'.  These type
! names can be used together with '_Complex' to declare complex types.
  
   As an extension, GNU C and GNU C++ support additional floating types,
  which are not supported by all targets.
!    * '__float128' is available on i386, x86_64, IA-64, and hppa HP-UX,
       as well as on PowerPC GNU/Linux targets that enable the vector
!      scalar (VSX) instruction set.  '__float128' supports the 128-bit
       floating type.  On i386, x86_64, PowerPC, and IA-64 other than
!      HP-UX, '__float128' is an alias for '_Float128'.  On hppa and IA-64
!      HP-UX, '__float128' is an alias for 'long double'.
  
!    * '__float80' is available on the i386, x86_64, and IA-64 targets,
!      and supports the 80-bit ('XFmode') floating type.  It is an alias
!      for the type name '_Float64x' on these targets.
  
!    * '__ibm128' is available on PowerPC targets, and provides access to
       the IBM extended double format which is the current format used for
!      'long double'.  When 'long double' transitions to '__float128' on
!      PowerPC in the future, '__ibm128' will remain for use in
       conversions between the two types.
  
   Support for these 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' or type '__ibm128'.  Use a suffix 'q' or 'Q' for
! '__float128'.
  
!  In order to use '_Float128', '__float128', and '__ibm128' on PowerPC
! Linux systems, you must use the '-mfloat128' option.  It is expected in
! future versions of GCC that '_Float128' and '__float128' will be enabled
  automatically.
  
!  The '_Float128' type is supported on all systems where '__float128' is
! supported or where 'long double' has the IEEE binary128 format.  The
! '_Float64x' type is supported on all systems where '__float128' is
! supported.  The '_Float32' type is supported on all systems supporting
! IEEE binary32; the '_Float64' and '_Float32x' types are supported on all
! systems supporting IEEE binary64.  The '_Float16' type is supported on
  AArch64 systems by default, on ARM systems when the IEEE format for
! 16-bit floating-point types is selected with '-mfp16-format=ieee' and,
  for both C and C++, on x86 systems with SSE2 enabled.  GCC does not
! currently support '_Float128x' on any systems.
  
   On the i386, x86_64, IA-64, and HP-UX targets, 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;
  
   On the PowerPC Linux VSX targets, you can declare complex types using
! the corresponding internal complex type, 'KCmode' for '__float128' type
! and 'ICmode' for '__ibm128' type:
  
       typedef _Complex float __attribute__((mode(KC))) _Complex_float128;
       typedef _Complex float __attribute__((mode(IC))) _Complex_ibm128;
--- 34417,34479 ----
  ==============================
  
  ISO/IEC TS 18661-3:2015 defines C support for additional floating types
! ‘_FloatN’ and ‘_FloatNx’, and GCC supports these type names; the set of
  types supported depends on the target architecture.  Constants with
! these types use suffixes ‘fN’ or ‘FN’ and ‘fNx’ or ‘FNx’.  These type
! names can be used together with ‘_Complex’ to declare complex types.
  
   As an extension, GNU C and GNU C++ support additional floating types,
  which are not supported by all targets.
!    • ‘__float128’ is available on i386, x86_64, IA-64, and hppa HP-UX,
       as well as on PowerPC GNU/Linux targets that enable the vector
!      scalar (VSX) instruction set.  ‘__float128’ supports the 128-bit
       floating type.  On i386, x86_64, PowerPC, and IA-64 other than
!      HP-UX, ‘__float128’ is an alias for ‘_Float128’.  On hppa and IA-64
!      HP-UX, ‘__float128’ is an alias for ‘long double’.
  
!    • ‘__float80’ is available on the i386, x86_64, and IA-64 targets,
!      and supports the 80-bit (‘XFmode’) floating type.  It is an alias
!      for the type name ‘_Float64x’ on these targets.
  
!    • ‘__ibm128’ is available on PowerPC targets, and provides access to
       the IBM extended double format which is the current format used for
!      ‘long double’.  When ‘long double’ transitions to ‘__float128’ on
!      PowerPC in the future, ‘__ibm128’ will remain for use in
       conversions between the two types.
  
   Support for these 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’ or type ‘__ibm128’.  Use a suffix ‘q’ or ‘Q’ for
! ‘__float128’.
  
!  In order to use ‘_Float128’, ‘__float128’, and ‘__ibm128’ on PowerPC
! Linux systems, you must use the ‘-mfloat128’ option.  It is expected in
! future versions of GCC that ‘_Float128’ and ‘__float128’ will be enabled
  automatically.
  
!  The ‘_Float128’ type is supported on all systems where ‘__float128’ is
! supported or where ‘long double’ has the IEEE binary128 format.  The
! ‘_Float64x’ type is supported on all systems where ‘__float128’ is
! supported.  The ‘_Float32’ type is supported on all systems supporting
! IEEE binary32; the ‘_Float64’ and ‘_Float32x’ types are supported on all
! systems supporting IEEE binary64.  The ‘_Float16’ type is supported on
  AArch64 systems by default, on ARM systems when the IEEE format for
! 16-bit floating-point types is selected with ‘-mfp16-format=ieee’ and,
  for both C and C++, on x86 systems with SSE2 enabled.  GCC does not
! currently support ‘_Float128x’ on any systems.
  
   On the i386, x86_64, IA-64, and HP-UX targets, 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;
  
   On the PowerPC Linux VSX targets, you can declare complex types using
! the corresponding internal complex type, ‘KCmode’ for ‘__float128’ type
! and ‘ICmode’ for ‘__ibm128’ type:
  
       typedef _Complex float __attribute__((mode(KC))) _Complex_float128;
       typedef _Complex float __attribute__((mode(IC))) _Complex_ibm128;
*************** File: gcc.info,  Node: Half-Precision,
*** 34476,34542 ****
  ==================================
  
  On ARM and AArch64 targets, GCC supports half-precision (16-bit)
! floating point via the '__fp16' type defined in the ARM C Language
  Extensions.  On ARM systems, you must enable this type explicitly with
! the '-mfp16-format' command-line option in order to use it.  On x86
  targets with SSE2 enabled, GCC supports half-precision (16-bit) floating
! point via the '_Float16' type.  For C++, x86 provides a builtin type
! named '_Float16' which contains same data format as C.
  
   ARM targets support 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 GCC port for AArch64 only supports the IEEE 754-2008 format, and
! does not require use of the '-mfp16-format' command-line option.
  
!  The '__fp16' type may only be used as an argument to intrinsics defined
! in '', or as a storage format.  For purposes of arithmetic
! and other operations, '__fp16' values in C or C++ expressions are
! automatically promoted to 'float'.
  
   The ARM target provides hardware support for conversions between
! '__fp16' and 'float' values as an extension to VFP and NEON (Advanced
  SIMD), and from ARMv8-A provides hardware support for conversions
! between '__fp16' and 'double' values.  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 other types as library calls.
  
!  It is recommended that portable code use the '_Float16' type defined by
  ISO/IEC TS 18661-3:2015.  *Note Floating Types::.
  
!  On x86 targets with SSE2 enabled, without '-mavx512fp16', all
! operations will be emulated by software emulation and the 'float'
! instructions.  The default behavior for 'FLT_EVAL_METHOD' is to keep the
  intermediate result of the operation as 32-bit precision.  This may lead
  to inconsistent behavior between software emulation and AVX512-FP16
! instructions.  Using '-fexcess-precision=16' will force round back after
  each operation.
  
!  Using '-mavx512fp16' will generate AVX512-FP16 instructions instead of
! software emulation.  The default behavior of 'FLT_EVAL_METHOD' is to
  round after each operation.  The same is true with
! '-fexcess-precision=standard' and '-mfpmath=sse'.  If there is no
! '-mfpmath=sse', '-fexcess-precision=standard' alone does the same thing
! as before, It is useful for code that does not have '_Float16' and runs
  on the x87 FPU.
  
  
--- 34485,34551 ----
  ==================================
  
  On ARM and AArch64 targets, GCC supports half-precision (16-bit)
! floating point via the ‘__fp16’ type defined in the ARM C Language
  Extensions.  On ARM systems, you must enable this type explicitly with
! the ‘-mfp16-format’ command-line option in order to use it.  On x86
  targets with SSE2 enabled, GCC supports half-precision (16-bit) floating
! point via the ‘_Float16’ type.  For C++, x86 provides a builtin type
! named ‘_Float16’ which contains same data format as C.
  
   ARM targets support 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 GCC port for AArch64 only supports the IEEE 754-2008 format, and
! does not require use of the ‘-mfp16-format’ command-line option.
  
!  The ‘__fp16’ type may only be used as an argument to intrinsics defined
! in ‘’, or as a storage format.  For purposes of arithmetic
! and other operations, ‘__fp16’ values in C or C++ expressions are
! automatically promoted to ‘float’.
  
   The ARM target provides hardware support for conversions between
! ‘__fp16’ and ‘float’ values as an extension to VFP and NEON (Advanced
  SIMD), and from ARMv8-A provides hardware support for conversions
! between ‘__fp16’ and ‘double’ values.  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 other types as library calls.
  
!  It is recommended that portable code use the ‘_Float16’ type defined by
  ISO/IEC TS 18661-3:2015.  *Note Floating Types::.
  
!  On x86 targets with SSE2 enabled, without ‘-mavx512fp16’, all
! operations will be emulated by software emulation and the ‘float’
! instructions.  The default behavior for ‘FLT_EVAL_METHOD’ is to keep the
  intermediate result of the operation as 32-bit precision.  This may lead
  to inconsistent behavior between software emulation and AVX512-FP16
! instructions.  Using ‘-fexcess-precision=16’ will force round back after
  each operation.
  
!  Using ‘-mavx512fp16’ will generate AVX512-FP16 instructions instead of
! software emulation.  The default behavior of ‘FLT_EVAL_METHOD’ is to
  round after each operation.  The same is true with
! ‘-fexcess-precision=standard’ and ‘-mfpmath=sse’.  If there is no
! ‘-mfpmath=sse’, ‘-fexcess-precision=standard’ alone does the same thing
! as before, It is useful for code that does not have ‘_Float16’ and runs
  on the x87 FPU.
  
  
*************** GCC will evolve as the draft technical r
*** 34551,34583 ****
  conventions for any target might also change.  Not all targets support
  decimal floating types.
  
!  The decimal floating types are '_Decimal32', '_Decimal64', and
! '_Decimal128'.  They use a radix of ten, unlike the floating types
! 'float', 'double', and 'long double' whose radix is not specified by the
  C standard but is usually two.
  
   Support for decimal floating types includes the arithmetic operators
  add, subtract, multiply, divide; unary arithmetic operators; relational
  operators; equality operators; and conversions to and from integer and
! other floating types.  Use a suffix 'df' or 'DF' in a literal constant
! of type '_Decimal32', 'dd' or 'DD' for '_Decimal64', and 'dl' or 'DL'
! for '_Decimal128'.
  
   GCC support of decimal float as specified by the draft technical report
  is incomplete:
  
!    * When the value of a decimal floating type cannot be represented in
       the integer type to which it is being converted, the result is
       undefined rather than the result value specified by the draft
       technical report.
  
!    * GCC does not provide the C library functionality associated with
!      'math.h', 'fenv.h', 'stdio.h', 'stdlib.h', and 'wchar.h', which
       must come from a separate C library implementation.  Because of
!      this the GNU C compiler does not define macro '__STDC_DEC_FP__' to
       indicate that the implementation conforms to the technical report.
  
!  Types '_Decimal32', '_Decimal64', and '_Decimal128' are supported by
  the DWARF debug information format.
  
  
--- 34560,34592 ----
  conventions for any target might also change.  Not all targets support
  decimal floating types.
  
!  The decimal floating types are ‘_Decimal32’, ‘_Decimal64’, and
! ‘_Decimal128’.  They use a radix of ten, unlike the floating types
! ‘float’, ‘double’, and ‘long double’ whose radix is not specified by the
  C standard but is usually two.
  
   Support for decimal floating types includes the arithmetic operators
  add, subtract, multiply, divide; unary arithmetic operators; relational
  operators; equality operators; and conversions to and from integer and
! other floating types.  Use a suffix ‘df’ or ‘DF’ in a literal constant
! of type ‘_Decimal32’, ‘dd’ or ‘DD’ for ‘_Decimal64’, and ‘dl’ or ‘DL’
! for ‘_Decimal128’.
  
   GCC support of decimal float as specified by the draft technical report
  is incomplete:
  
!    • When the value of a decimal floating type cannot be represented in
       the integer type to which it is being converted, the result is
       undefined rather than the result value specified by the draft
       technical report.
  
!    • GCC does not provide the C library functionality associated with
!      ‘math.h’, ‘fenv.h’, ‘stdio.h’, ‘stdlib.h’, and ‘wchar.h’, which
       must come from a separate C library implementation.  Because of
!      this the GNU C compiler does not define macro ‘__STDC_DEC_FP__’ to
       indicate that the implementation conforms to the technical report.
  
!  Types ‘_Decimal32’, ‘_Decimal64’, and ‘_Decimal128’ are supported by
  the DWARF debug information format.
  
  
*************** File: gcc.info,  Node: Hex Floats,  Next
*** 34587,34606 ****
  ===============
  
  ISO C99 and ISO C++17 support 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++98, C++11 and C++14 modes.  In that format the
! '0x' hex introducer and the 'p' or 'P' exponent field are mandatory.
  The exponent is a decimal number that indicates the power of 2 by which
! the significant part is multiplied.  Thus '0x1.f' is 1 15/16, 'p3'
! multiplies it by 8, and the value of '0x1.fp3' is the same as '1.55e1'.
  
   Unlike for floating-point numbers in the decimal notation the exponent
  is always required in the hexadecimal notation.  Otherwise the compiler
! would not be able to resolve the ambiguity of, e.g., '0x1.f'.  This
! could mean '1.0f' or '1.9375' since 'f' is also the extension for
! floating-point constants of type 'float'.
  
  
  File: gcc.info,  Node: Fixed-Point,  Next: Named Address Spaces,  Prev: Hex Floats,  Up: C Extensions
--- 34596,34615 ----
  ===============
  
  ISO C99 and ISO C++17 support 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++98, C++11 and C++14 modes.  In that format the
! ‘0x’ hex introducer and the ‘p’ or ‘P’ exponent field are mandatory.
  The exponent is a decimal number that indicates the power of 2 by which
! the significant part is multiplied.  Thus ‘0x1.f’ is 1 15/16, ‘p3’
! multiplies it by 8, and the value of ‘0x1.fp3’ is the same as ‘1.55e1’.
  
   Unlike for floating-point numbers in the decimal notation the exponent
  is always required in the hexadecimal notation.  Otherwise the compiler
! would not be able to resolve the ambiguity of, e.g., ‘0x1.f’.  This
! could mean ‘1.0f’ or ‘1.9375’ since ‘f’ is also the extension for
! floating-point constants of type ‘float’.
  
  
  File: gcc.info,  Node: Fixed-Point,  Next: Named Address Spaces,  Prev: Hex Floats,  Up: C Extensions
*************** will evolve as the draft technical repor
*** 34614,34673 ****
  for any target might also change.  Not all targets support fixed-point
  types.
  
!  The fixed-point types are 'short _Fract', '_Fract', 'long _Fract',
! 'long long _Fract', 'unsigned short _Fract', 'unsigned _Fract',
! 'unsigned long _Fract', 'unsigned long long _Fract', '_Sat short
! _Fract', '_Sat _Fract', '_Sat long _Fract', '_Sat long long _Fract',
! '_Sat unsigned short _Fract', '_Sat unsigned _Fract', '_Sat unsigned
! long _Fract', '_Sat unsigned long long _Fract', 'short _Accum',
! '_Accum', 'long _Accum', 'long long _Accum', 'unsigned short _Accum',
! 'unsigned _Accum', 'unsigned long _Accum', 'unsigned long long _Accum',
! '_Sat short _Accum', '_Sat _Accum', '_Sat long _Accum', '_Sat long long
! _Accum', '_Sat unsigned short _Accum', '_Sat unsigned _Accum', '_Sat
! unsigned long _Accum', '_Sat unsigned long long _Accum'.
  
   Fixed-point data values contain fractional and optional integral parts.
  The format of fixed-point data varies and depends on the target machine.
  
   Support for fixed-point types includes:
!    * prefix and postfix increment and decrement operators ('++', '--')
!    * unary arithmetic operators ('+', '-', '!')
!    * binary arithmetic operators ('+', '-', '*', '/')
!    * binary shift operators ('<<', '>>')
!    * relational operators ('<', '<=', '>=', '>')
!    * equality operators ('==', '!=')
!    * assignment operators ('+=', '-=', '*=', '/=', '<<=', '>>=')
!    * conversions to and from integer, floating-point, or fixed-point
       types
  
   Use a suffix in a fixed-point literal constant:
!    * 'hr' or 'HR' for 'short _Fract' and '_Sat short _Fract'
!    * 'r' or 'R' for '_Fract' and '_Sat _Fract'
!    * 'lr' or 'LR' for 'long _Fract' and '_Sat long _Fract'
!    * 'llr' or 'LLR' for 'long long _Fract' and '_Sat long long _Fract'
!    * 'uhr' or 'UHR' for 'unsigned short _Fract' and '_Sat unsigned short
!      _Fract'
!    * 'ur' or 'UR' for 'unsigned _Fract' and '_Sat unsigned _Fract'
!    * 'ulr' or 'ULR' for 'unsigned long _Fract' and '_Sat unsigned long
!      _Fract'
!    * 'ullr' or 'ULLR' for 'unsigned long long _Fract' and '_Sat unsigned
!      long long _Fract'
!    * 'hk' or 'HK' for 'short _Accum' and '_Sat short _Accum'
!    * 'k' or 'K' for '_Accum' and '_Sat _Accum'
!    * 'lk' or 'LK' for 'long _Accum' and '_Sat long _Accum'
!    * 'llk' or 'LLK' for 'long long _Accum' and '_Sat long long _Accum'
!    * 'uhk' or 'UHK' for 'unsigned short _Accum' and '_Sat unsigned short
!      _Accum'
!    * 'uk' or 'UK' for 'unsigned _Accum' and '_Sat unsigned _Accum'
!    * 'ulk' or 'ULK' for 'unsigned long _Accum' and '_Sat unsigned long
!      _Accum'
!    * 'ullk' or 'ULLK' for 'unsigned long long _Accum' and '_Sat unsigned
!      long long _Accum'
  
   GCC support of fixed-point types as specified by the draft technical
  report is incomplete:
  
!    * Pragmas to control overflow and rounding behaviors are not
       implemented.
  
   Fixed-point types are supported by the DWARF debug information format.
--- 34623,34682 ----
  for any target might also change.  Not all targets support fixed-point
  types.
  
!  The fixed-point types are ‘short _Fract’, ‘_Fract’, ‘long _Fract’,
! ‘long long _Fract’, ‘unsigned short _Fract’, ‘unsigned _Fract’,
! ‘unsigned long _Fract’, ‘unsigned long long _Fract’, ‘_Sat short
! _Fract’, ‘_Sat _Fract’, ‘_Sat long _Fract’, ‘_Sat long long _Fract’,
! ‘_Sat unsigned short _Fract’, ‘_Sat unsigned _Fract’, ‘_Sat unsigned
! long _Fract’, ‘_Sat unsigned long long _Fract’, ‘short _Accum’,
! ‘_Accum’, ‘long _Accum’, ‘long long _Accum’, ‘unsigned short _Accum’,
! ‘unsigned _Accum’, ‘unsigned long _Accum’, ‘unsigned long long _Accum’,
! ‘_Sat short _Accum’, ‘_Sat _Accum’, ‘_Sat long _Accum’, ‘_Sat long long
! _Accum’, ‘_Sat unsigned short _Accum’, ‘_Sat unsigned _Accum’, ‘_Sat
! unsigned long _Accum’, ‘_Sat unsigned long long _Accum’.
  
   Fixed-point data values contain fractional and optional integral parts.
  The format of fixed-point data varies and depends on the target machine.
  
   Support for fixed-point types includes:
!    • prefix and postfix increment and decrement operators (‘++’, ‘--’)
!    • unary arithmetic operators (‘+’, ‘-’, ‘!’)
!    • binary arithmetic operators (‘+’, ‘-’, ‘*’, ‘/’)
!    • binary shift operators (‘<<’, ‘>>’)
!    • relational operators (‘<’, ‘<=’, ‘>=’, ‘>’)
!    • equality operators (‘==’, ‘!=’)
!    • assignment operators (‘+=’, ‘-=’, ‘*=’, ‘/=’, ‘<<=’, ‘>>=’)
!    • conversions to and from integer, floating-point, or fixed-point
       types
  
   Use a suffix in a fixed-point literal constant:
!    • ‘hr’ or ‘HR’ for ‘short _Fract’ and ‘_Sat short _Fract’
!    • ‘r’ or ‘R’ for ‘_Fract’ and ‘_Sat _Fract’
!    • ‘lr’ or ‘LR’ for ‘long _Fract’ and ‘_Sat long _Fract’
!    • ‘llr’ or ‘LLR’ for ‘long long _Fract’ and ‘_Sat long long _Fract’
!    • ‘uhr’ or ‘UHR’ for ‘unsigned short _Fract’ and ‘_Sat unsigned short
!      _Fract’
!    • ‘ur’ or ‘UR’ for ‘unsigned _Fract’ and ‘_Sat unsigned _Fract’
!    • ‘ulr’ or ‘ULR’ for ‘unsigned long _Fract’ and ‘_Sat unsigned long
!      _Fract’
!    • ‘ullr’ or ‘ULLR’ for ‘unsigned long long _Fract’ and ‘_Sat unsigned
!      long long _Fract’
!    • ‘hk’ or ‘HK’ for ‘short _Accum’ and ‘_Sat short _Accum’
!    • ‘k’ or ‘K’ for ‘_Accum’ and ‘_Sat _Accum’
!    • ‘lk’ or ‘LK’ for ‘long _Accum’ and ‘_Sat long _Accum’
!    • ‘llk’ or ‘LLK’ for ‘long long _Accum’ and ‘_Sat long long _Accum’
!    • ‘uhk’ or ‘UHK’ for ‘unsigned short _Accum’ and ‘_Sat unsigned short
!      _Accum’
!    • ‘uk’ or ‘UK’ for ‘unsigned _Accum’ and ‘_Sat unsigned _Accum’
!    • ‘ulk’ or ‘ULK’ for ‘unsigned long _Accum’ and ‘_Sat unsigned long
!      _Accum’
!    • ‘ullk’ or ‘ULLK’ for ‘unsigned long long _Accum’ and ‘_Sat unsigned
!      long long _Accum’
  
   GCC support of fixed-point types as specified by the draft technical
  report is incomplete:
  
!    • Pragmas to control overflow and rounding behaviors are not
       implemented.
  
   Fixed-point types are supported by the DWARF debug information format.
*************** M32C, PRU, RL78, and x86 targets support
*** 34686,34692 ****
  generic address space.
  
   Address space identifiers may be used exactly like any other C type
! qualifier (e.g., 'const' or 'volatile').  See the N1275 document for
  more details.
  
  6.17.1 AVR Named Address Spaces
--- 34695,34701 ----
  generic address space.
  
   Address space identifiers may be used exactly like any other C type
! qualifier (e.g., ‘const’ or ‘volatile’).  See the N1275 document for
  more details.
  
  6.17.1 AVR Named Address Spaces
*************** more details.
*** 34694,34744 ****
  
  On the AVR target, there are several address spaces that can be used in
  order to put read-only data into the flash memory and access that data
! by means of the special instructions 'LPM' or 'ELPM' needed to read from
  flash.
  
!  Devices belonging to 'avrtiny' and 'avrxmega3' can access flash memory
! by means of 'LD*' instructions because the flash memory is mapped into
  the RAM address space.  There is _no need_ for language extensions like
! '__flash' or attribute *note 'progmem': AVR Variable Attributes.  The
  default linker description files for these devices cater for that
! feature and '.rodata' stays in flash: The compiler just generates 'LD*'
  instructions, and the linker script adds core specific offsets to all
! '.rodata' symbols: '0x4000' in the case of 'avrtiny' and '0x8000' in the
! case of 'avrxmega3'.  See *note AVR Options:: for a list of respective
  devices.
  
!  For devices not in 'avrtiny' or 'avrxmega3', any data including
  read-only data is located in RAM (the generic address space) because
  flash memory is not visible in the RAM address space.  In order to
  locate read-only data in flash memory _and_ to generate the right
  instructions to access this data without using (inline) assembler code,
  special address spaces are needed.
  
! '__flash'
!      The '__flash' qualifier locates data in the '.progmem.data'
!      section.  Data is read using the 'LPM' instruction.  Pointers to
       this address space are 16 bits wide.
  
! '__flash1'
! '__flash2'
! '__flash3'
! '__flash4'
! '__flash5'
       These are 16-bit address spaces locating data in section
!      '.progmemN.data' where N refers to address space '__flashN'.  The
!      compiler sets the 'RAMPZ' segment register appropriately before
!      reading data by means of the 'ELPM' instruction.
  
! '__memx'
       This is a 24-bit address space that linearizes flash and RAM: If
       the high bit of the address is set, data is read from RAM using the
       lower two bytes as RAM address.  If the high bit of the address is
!      clear, data is read from flash with 'RAMPZ' set according to the
!      high byte of the address.  *Note '__builtin_avr_flash_segment': AVR
       Built-in Functions.
  
!      Objects in this address space are located in '.progmemx.data'.
  
   Example
  
--- 34703,34753 ----
  
  On the AVR target, there are several address spaces that can be used in
  order to put read-only data into the flash memory and access that data
! by means of the special instructions ‘LPM’ or ‘ELPM’ needed to read from
  flash.
  
!  Devices belonging to ‘avrtiny’ and ‘avrxmega3’ can access flash memory
! by means of ‘LD*’ instructions because the flash memory is mapped into
  the RAM address space.  There is _no need_ for language extensions like
! ‘__flash’ or attribute *note ‘progmem’: AVR Variable Attributes.  The
  default linker description files for these devices cater for that
! feature and ‘.rodata’ stays in flash: The compiler just generates ‘LD*’
  instructions, and the linker script adds core specific offsets to all
! ‘.rodata’ symbols: ‘0x4000’ in the case of ‘avrtiny’ and ‘0x8000’ in the
! case of ‘avrxmega3’.  See *note AVR Options:: for a list of respective
  devices.
  
!  For devices not in ‘avrtiny’ or ‘avrxmega3’, any data including
  read-only data is located in RAM (the generic address space) because
  flash memory is not visible in the RAM address space.  In order to
  locate read-only data in flash memory _and_ to generate the right
  instructions to access this data without using (inline) assembler code,
  special address spaces are needed.
  
! ‘__flash’
!      The ‘__flash’ qualifier locates data in the ‘.progmem.data’
!      section.  Data is read using the ‘LPM’ instruction.  Pointers to
       this address space are 16 bits wide.
  
! ‘__flash1’
! ‘__flash2’
! ‘__flash3’
! ‘__flash4’
! ‘__flash5’
       These are 16-bit address spaces locating data in section
!      ‘.progmemN.data’ where N refers to address space ‘__flashN’.  The
!      compiler sets the ‘RAMPZ’ segment register appropriately before
!      reading data by means of the ‘ELPM’ instruction.
  
! ‘__memx’
       This is a 24-bit address space that linearizes flash and RAM: If
       the high bit of the address is set, data is read from RAM using the
       lower two bytes as RAM address.  If the high bit of the address is
!      clear, data is read from flash with ‘RAMPZ’ set according to the
!      high byte of the address.  *Note ‘__builtin_avr_flash_segment’: AVR
       Built-in Functions.
  
!      Objects in this address space are located in ‘.progmemx.data’.
  
   Example
  
*************** not:
*** 34786,34847 ****
       }
       #endif /* __FLASH */
  
! Notice that attribute *note 'progmem': AVR Variable Attributes. locates
  data in flash but accesses to these data read from generic address
  space, i.e. from RAM, so that you need special accessors like
! 'pgm_read_byte' from
  AVR-LibC (https://www.nongnu.org/avr-libc/user-manual/) together with
! attribute 'progmem'.
  
  Limitations and caveats
  
!    * Reading across the 64 KiB section boundary of the '__flash' or
!      '__flashN' address spaces shows undefined behavior.  The only
       address space that supports reading across the 64 KiB flash segment
!      boundaries is '__memx'.
  
!    * If you use one of the '__flashN' address spaces you must arrange
!      your linker script to locate the '.progmemN.data' sections
       according to your needs.
  
!    * Any data or pointers to the non-generic address spaces must be
!      qualified as 'const', i.e. as read-only data.  This still applies
       if the data in one of these address spaces like software version
       number or calibration lookup table are intended to be changed after
       load time by, say, a boot loader.  In this case the right
!      qualification is 'const' 'volatile' so that the compiler must not
       optimize away known values or insert them as immediates into
       operands of instructions.
  
!    * The following code initializes a variable 'pfoo' located in static
       storage with a 24-bit address:
            extern const __memx char foo;
            const __memx void *pfoo = &foo;
  
!    * On the reduced Tiny devices like ATtiny40, no address spaces are
       supported.  Just use vanilla C / C++ code without overhead as
!      outlined above.  Attribute 'progmem' is supported but works
       differently, see *note AVR Variable Attributes::.
  
  6.17.2 M32C Named Address Spaces
  --------------------------------
  
  On the M32C target, with the R8C and M16C CPU variants, variables
! qualified with '__far' are accessed using 32-bit addresses in order to
! access memory beyond the first 64 Ki bytes.  If '__far' is used with the
  M32CM or M32C CPU variants, it has no effect.
  
  6.17.3 PRU Named Address Spaces
  -------------------------------
  
! On the PRU target, variables qualified with '__regio_symbol' are aliases
  used to access the special I/O CPU registers.  They must be declared as
! 'extern' because such variables will not be allocated in any data
! memory.  They must also be marked as 'volatile', and can only be 32-bit
! integer types.  The only names those variables can have are '__R30' and
! '__R31', representing respectively the 'R30' and 'R31' special I/O CPU
  registers.  Hence the following example is the only valid usage of
! '__regio_symbol':
  
       extern volatile __regio_symbol uint32_t __R30;
       extern volatile __regio_symbol uint32_t __R31;
--- 34795,34856 ----
       }
       #endif /* __FLASH */
  
! Notice that attribute *note ‘progmem’: AVR Variable Attributes. locates
  data in flash but accesses to these data read from generic address
  space, i.e. from RAM, so that you need special accessors like
! ‘pgm_read_byte’ from
  AVR-LibC (https://www.nongnu.org/avr-libc/user-manual/) together with
! attribute ‘progmem’.
  
  Limitations and caveats
  
!    • Reading across the 64 KiB section boundary of the ‘__flash’ or
!      ‘__flashN’ address spaces shows undefined behavior.  The only
       address space that supports reading across the 64 KiB flash segment
!      boundaries is ‘__memx’.
  
!    • If you use one of the ‘__flashN’ address spaces you must arrange
!      your linker script to locate the ‘.progmemN.data’ sections
       according to your needs.
  
!    • Any data or pointers to the non-generic address spaces must be
!      qualified as ‘const’, i.e. as read-only data.  This still applies
       if the data in one of these address spaces like software version
       number or calibration lookup table are intended to be changed after
       load time by, say, a boot loader.  In this case the right
!      qualification is ‘const’ ‘volatile’ so that the compiler must not
       optimize away known values or insert them as immediates into
       operands of instructions.
  
!    • The following code initializes a variable ‘pfoo’ located in static
       storage with a 24-bit address:
            extern const __memx char foo;
            const __memx void *pfoo = &foo;
  
!    • On the reduced Tiny devices like ATtiny40, no address spaces are
       supported.  Just use vanilla C / C++ code without overhead as
!      outlined above.  Attribute ‘progmem’ is supported but works
       differently, see *note AVR Variable Attributes::.
  
  6.17.2 M32C Named Address Spaces
  --------------------------------
  
  On the M32C target, with the R8C and M16C CPU variants, variables
! qualified with ‘__far’ are accessed using 32-bit addresses in order to
! access memory beyond the first 64 Ki bytes.  If ‘__far’ is used with the
  M32CM or M32C CPU variants, it has no effect.
  
  6.17.3 PRU Named Address Spaces
  -------------------------------
  
! On the PRU target, variables qualified with ‘__regio_symbol’ are aliases
  used to access the special I/O CPU registers.  They must be declared as
! ‘extern’ because such variables will not be allocated in any data
! memory.  They must also be marked as ‘volatile’, and can only be 32-bit
! integer types.  The only names those variables can have are ‘__R30’ and
! ‘__R31’, representing respectively the ‘R30’ and ‘R31’ special I/O CPU
  registers.  Hence the following example is the only valid usage of
! ‘__regio_symbol’:
  
       extern volatile __regio_symbol uint32_t __R30;
       extern volatile __regio_symbol uint32_t __R31;
*************** registers.  Hence the following example
*** 34849,34855 ****
  6.17.4 RL78 Named Address Spaces
  --------------------------------
  
! On the RL78 target, variables qualified with '__far' are accessed with
  32-bit pointers (20-bit addresses) rather than the default 16-bit
  addresses.  Non-far variables are assumed to appear in the topmost
  64 KiB of the address space.
--- 34858,34864 ----
  6.17.4 RL78 Named Address Spaces
  --------------------------------
  
! On the RL78 target, variables qualified with ‘__far’ are accessed with
  32-bit pointers (20-bit addresses) rather than the default 16-bit
  addresses.  Non-far variables are assumed to appear in the topmost
  64 KiB of the address space.
*************** addresses.  Non-far variables are assume
*** 34858,34867 ****
  -------------------------------
  
  On the x86 target, variables may be declared as being relative to the
! '%fs' or '%gs' segments.
  
! '__seg_fs'
! '__seg_gs'
       The object is accessed with the respective segment override prefix.
  
       The respective segment base must be set via some method specific to
--- 34867,34876 ----
  -------------------------------
  
  On the x86 target, variables may be declared as being relative to the
! ‘%fs’ or ‘%gs’ segments.
  
! ‘__seg_fs’
! ‘__seg_gs’
       The object is accessed with the respective segment override prefix.
  
       The respective segment base must be set via some method specific to
*************** On the x86 target, variables may be decl
*** 34870,34879 ****
       considered to be subspaces of the generic (flat) address space.
       This means that explicit casts are required to convert pointers
       between these address spaces and the generic address space.  In
!      practice the application should cast to 'uintptr_t' and apply the
       segment base offset that it installed previously.
  
!      The preprocessor symbols '__SEG_FS' and '__SEG_GS' are defined when
       these address spaces are supported.
  
  
--- 34879,34888 ----
       considered to be subspaces of the generic (flat) address space.
       This means that explicit casts are required to convert pointers
       between these address spaces and the generic address space.  In
!      practice the application should cast to ‘uintptr_t’ and apply the
       segment base offset that it installed previously.
  
!      The preprocessor symbols ‘__SEG_FS’ and ‘__SEG_GS’ are defined when
       these address spaces are supported.
  
  
*************** Accessing elements of zero-length arrays
*** 34908,34914 ****
  undefined and may be diagnosed.
  
   In the absence of the zero-length array extension, in ISO C90 the
! 'contents' array in the example above would typically be declared to
  have a single element.  Unlike a zero-length array which only
  contributes to the size of the enclosing structure for the purposes of
  alignment, a one-element array always occupies at least as much space as
--- 34917,34923 ----
  undefined and may be diagnosed.
  
   In the absence of the zero-length array extension, in ISO C90 the
! ‘contents’ array in the example above would typically be declared to
  have a single element.  Unlike a zero-length array which only
  contributes to the size of the enclosing structure for the purposes of
  alignment, a one-element array always occupies at least as much space as
*************** a single object of the type.  Although u
*** 34916,34935 ****
  is discouraged, GCC handles accesses to trailing one-element array
  members analogously to zero-length arrays.
  
!  The preferred mechanism to declare variable-length types like 'struct
! line' above is the ISO C99 "flexible array member", with slightly
  different 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.)
--- 34925,34944 ----
  is discouraged, GCC handles accesses to trailing one-element array
  members analogously to zero-length arrays.
  
!  The preferred mechanism to declare variable-length types like ‘struct
! line’ above is the ISO C99 “flexible array member”, with slightly
  different 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.)
*************** excess elements (all of them, in this ca
*** 34942,34948 ****
   GCC allows static initialization of flexible array members.  This is
  equivalent to defining a new structure containing the original structure
  followed by an array of sufficient size to contain the data.  E.g. in
! the following, 'f1' is constructed as if it were declared like 'f2'.
  
       struct f1 {
         int x; int y[];
--- 34951,34957 ----
   GCC allows static initialization of flexible array members.  This is
  equivalent to defining a new structure containing the original structure
  followed by an array of sufficient size to contain the data.  E.g. in
! the following, ‘f1’ is constructed as if it were declared like ‘f2’.
  
       struct f1 {
         int x; int y[];
*************** the following, 'f1' is constructed as if
*** 34952,34962 ****
         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
--- 34961,34971 ----
         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
*************** GCC permits a C structure to have no mem
*** 34986,34992 ****
  
   The structure has size zero.  In C++, empty structures are part of the
  language.  G++ treats empty structures as if they had a single member of
! type 'char'.
  
  
  File: gcc.info,  Node: Variable Length,  Next: Variadic Macros,  Prev: Empty Structures,  Up: C Extensions
--- 34995,35001 ----
  
   The structure has size zero.  In C++, empty structures are part of the
  language.  G++ treats empty structures as if they had a single member of
! type ‘char’.
  
  
  File: gcc.info,  Node: Variable Length,  Next: Variadic Macros,  Prev: Empty Structures,  Up: C Extensions
*************** structure or a union.  For example:
*** 35023,35037 ****
         struct S { int x[n]; };
       }
  
!  You can use the function 'alloca' to get an effect much like
! variable-length arrays.  The function 'alloca' is available in many
  other C implementations (but not in all).  On the other hand,
  variable-length arrays are more elegant.
  
   There are other differences between these two methods.  Space allocated
! with 'alloca' exists until the containing _function_ returns.  The space
  for a variable-length array is deallocated as soon as the array name's
! scope ends, unless you also use 'alloca' in this scope.
  
   You can also use variable-length arrays as arguments to functions:
  
--- 35032,35046 ----
         struct S { int x[n]; };
       }
  
!  You can use the function ‘alloca’ to get an effect much like
! variable-length arrays.  The function ‘alloca’ is available in many
  other C implementations (but not in all).  On the other hand,
  variable-length arrays are more elegant.
  
   There are other differences between these two methods.  Space allocated
! with ‘alloca’ exists until the containing _function_ returns.  The space
  for a variable-length array is deallocated as soon as the array name's
! scope ends, unless you also use ‘alloca’ in this scope.
  
   You can also use variable-length arrays as arguments to functions:
  
*************** scope ends, unless you also use 'alloca'
*** 35043,35049 ****
  
   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.
--- 35052,35058 ----
  
   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.
*************** use a forward declaration in the paramet
*** 35054,35062 ****
         /* ... */
       }
  
!  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
--- 35063,35071 ----
         /* ... */
       }
  
!  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
*************** example:
*** 35078,35087 ****
  
       #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
--- 35087,35096 ----
  
       #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
*************** the expansion of the macro still has the
*** 35109,35120 ****
  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
--- 35118,35129 ----
  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
*************** File: gcc.info,  Node: Subscripting,  Ne
*** 35146,35152 ****
  
  In ISO C99, arrays that are not lvalues still decay to pointers, and may
  be subscripted, although they may not be modified or used after the next
! sequence point and the unary '&' operator may not be applied to them.
  As an extension, GNU C allows such arrays to be subscripted in C90 mode,
  though otherwise they do not decay to pointers outside C99 mode.  For
  example, this is valid in GNU C though not valid in C90:
--- 35155,35161 ----
  
  In ISO C99, arrays that are not lvalues still decay to pointers, and may
  be subscripted, although they may not be modified or used after the next
! sequence point and the unary ‘&’ operator may not be applied to them.
  As an extension, GNU C allows such arrays to be subscripted in C90 mode,
  though otherwise they do not decay to pointers outside C99 mode.  For
  example, this is valid in GNU C though not valid in C90:
*************** example, this is valid in GNU C though n
*** 35163,35179 ****
  
  File: gcc.info,  Node: Pointer Arith,  Next: Variadic Pointer Args,  Prev: Subscripting,  Up: C Extensions
  
! 6.24 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.
  
  
--- 35172,35188 ----
  
  File: gcc.info,  Node: Pointer Arith,  Next: Variadic Pointer Args,  Prev: Subscripting,  Up: C Extensions
  
! 6.24 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: Variadic Pointer
*** 35182,35195 ****
  6.25 Pointer Arguments in Variadic Functions
  ============================================
  
! Standard C requires that pointer types used with 'va_arg' in functions
  with variable argument lists either must be compatible with that of the
! actual argument, or that one type must be a pointer to 'void' and the
  other a pointer to a character type.  GNU C implements the POSIX XSI
! extension that additionally permits the use of 'va_arg' with a pointer
  type to receive arguments of any other pointer type.
  
!  In particular, in GNU C 'va_arg (ap, void *)' can safely be used to
  consume an argument of any pointer type.
  
  
--- 35191,35204 ----
  6.25 Pointer Arguments in Variadic Functions
  ============================================
  
! Standard C requires that pointer types used with ‘va_arg’ in functions
  with variable argument lists either must be compatible with that of the
! actual argument, or that one type must be a pointer to ‘void’ and the
  other a pointer to a character type.  GNU C implements the POSIX XSI
! extension that additionally permits the use of ‘va_arg’ with a pointer
  type to receive arguments of any other pointer type.
  
!  In particular, in GNU C ‘va_arg (ap, void *)’ can safely be used to
  consume an argument of any pointer type.
  
  
*************** File: gcc.info,  Node: Pointers to Array
*** 35199,35207 ****
  ========================================================
  
  In GNU C, pointers to arrays with qualifiers work similar to pointers to
! other qualified types.  For example, a value of type 'int (*)[5]' can be
! used to initialize a variable of type 'const int (*)[5]'.  These types
! are incompatible in ISO C because the 'const' qualifier is formally
  attached to the element type of the array and not the array itself.
  
       extern void
--- 35208,35216 ----
  ========================================================
  
  In GNU C, pointers to arrays with qualifiers work similar to pointers to
! other qualified types.  For example, a value of type ‘int (*)[5]’ can be
! used to initialize a variable of type ‘const int (*)[5]’.  These types
! are incompatible in ISO C because the ‘const’ qualifier is formally
  attached to the element type of the array and not the array itself.
  
       extern void
*************** literals also in C90 mode and in C++, al
*** 35243,35253 ****
  C++ semantics are somewhat different.
  
   Usually, the specified type of a compound literal 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});
--- 35252,35262 ----
  C++ semantics are somewhat different.
  
   Usually, the specified type of a compound literal 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});
*************** initializer, as shown here:
*** 35269,35276 ****
       char **foo = (char *[]) { "x", "y", "z" };
  
   Compound literals for scalar types and union types are also allowed.
! In the following example the variable 'i' is initialized to the value
! '2', the result of incrementing the unnamed object created by the
  compound literal.
  
       int i = ++(int) { 1 };
--- 35278,35285 ----
       char **foo = (char *[]) { "x", "y", "z" };
  
   Compound literals for scalar types and union types are also allowed.
! In the following example the variable ‘i’ is initialized to the value
! ‘2’, the result of incrementing the unnamed object created by the
  compound literal.
  
       int i = ++(int) { 1 };
*************** As a result, well-defined C code that ta
*** 35300,35312 ****
  of a compound literal can be undefined in C++, so G++ rejects the
  conversion of a temporary array to a pointer.  For instance, if the
  array compound literal example above appeared inside a function, any
! subsequent use of 'foo' in C++ would have undefined behavior because the
! lifetime of the array ends after the declaration of 'foo'.
  
   As an optimization, G++ sometimes gives array compound literals longer
  lifetimes: when the array either appears outside a function or has a
! 'const'-qualified type.  If 'foo' and its initializer had elements of
! type 'char *const' rather than 'char *', or if 'foo' were a global
  variable, the array would have static storage duration.  But it is
  probably safest just to avoid the use of array compound literals in C++
  code.
--- 35309,35321 ----
  of a compound literal can be undefined in C++, so G++ rejects the
  conversion of a temporary array to a pointer.  For instance, if the
  array compound literal example above appeared inside a function, any
! subsequent use of ‘foo’ in C++ would have undefined behavior because the
! lifetime of the array ends after the declaration of ‘foo’.
  
   As an optimization, G++ sometimes gives array compound literals longer
  lifetimes: when the array either appears outside a function or has a
! ‘const’-qualified type.  If ‘foo’ and its initializer had elements of
! type ‘char *const’ rather than ‘char *’, or if ‘foo’ were a global
  variable, the array would have static storage duration.  But it is
  probably safest just to avoid the use of array compound literals in C++
  code.
*************** indices or structure field names they ap
*** 35326,35332 ****
  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 };
--- 35335,35341 ----
  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 };
*************** The index values must be constant expres
*** 35339,35349 ****
  initialized is automatic.
  
   An alternative syntax for this that has been obsolete since GCC 2.5 but
! GCC still accepts is to write '[INDEX]' before the element value, with
! no '='.
  
!  To initialize a range of elements to the same value, write '[FIRST ...
! LAST] = VALUE'.  This is a GNU extension.  For example,
  
       int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
  
--- 35348,35358 ----
  initialized is automatic.
  
   An alternative syntax for this that has been obsolete since GCC 2.5 but
! GCC still accepts is to write ‘[INDEX]’ before the element value, with
! no ‘=’.
  
!  To initialize a range of elements to the same value, write ‘[FIRST ...
! LAST] = VALUE’.  This is a GNU extension.  For example,
  
       int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
  
*************** Note that the length of the array is the
*** 35354,35360 ****
  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; };
--- 35363,35369 ----
  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; };
*************** is equivalent to
*** 35368,35381 ****
       struct point p = { xvalue, yvalue };
  
   Another syntax that has the same meaning, obsolete since GCC 2.5, is
! 'FIELDNAME:', as shown here:
  
       struct point p = { y: yvalue, x: xvalue };
  
   Omitted fields are implicitly initialized the same as for objects that
  have static storage duration.
  
!  The '[INDEX]' or '.FIELDNAME' is known as a "designator".  You can also
  use a designator (or the obsolete colon syntax) when initializing a
  union, to specify which element of the union should be used.  For
  example,
--- 35377,35390 ----
       struct point p = { xvalue, yvalue };
  
   Another syntax that has the same meaning, obsolete since GCC 2.5, is
! ‘FIELDNAME:’, as shown here:
  
       struct point p = { y: yvalue, x: xvalue };
  
   Omitted fields are implicitly initialized the same as for objects that
  have static storage duration.
  
!  The ‘[INDEX]’ or ‘.FIELDNAME’ is known as a “designator”.  You can also
  use a designator (or the obsolete colon syntax) when initializing a
  union, to specify which element of the union should be used.  For
  example,
*************** example,
*** 35384,35392 ****
  
       union foo f = { .d = 4 };
  
! converts 4 to a 'double' to store it in the union using the second
! element.  By contrast, casting 4 to type 'union foo' stores it into the
! union as the integer 'i', since it is an integer.  *Note Cast to
  Union::.
  
   You can combine this technique of naming elements with ordinary C
--- 35393,35401 ----
  
       union foo f = { .d = 4 };
  
! converts 4 to a ‘double’ to store it in the union using the second
! element.  By contrast, casting 4 to type ‘union foo’ stores it into the
! union as the integer ‘i’, since it is an integer.  *Note Cast to
  Union::.
  
   You can combine this technique of naming elements with ordinary C
*************** is equivalent to
*** 35401,35416 ****
       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 };
  
--- 35410,35425 ----
       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 };
  
*************** File: gcc.info,  Node: Case Ranges,  Nex
*** 35428,35446 ****
  6.30 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:
  
--- 35437,35455 ----
  6.30 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:
  
*************** File: gcc.info,  Node: Cast to Union,  N
*** 35458,35465 ****
  
  A cast to a union type is a C extension not available in C++.  It looks
  just like ordinary casts with the constraint that the type specified is
! a union type.  You can specify the type either with the 'union' keyword
! or with a 'typedef' name that refers to a union.  The result of a cast
  to a union is a temporary rvalue of the union type with a member whose
  type matches that of the operand initialized to the value of the
  operand.  The effect of a cast to a union is similar to a compound
--- 35467,35474 ----
  
  A cast to a union type is a C extension not available in C++.  It looks
  just like ordinary casts with the constraint that the type specified is
! a union type.  You can specify the type either with the ‘union’ keyword
! or with a ‘typedef’ name that refers to a union.  The result of a cast
  to a union is a temporary rvalue of the union type with a member whose
  type matches that of the operand initialized to the value of the
  operand.  The effect of a cast to a union is similar to a compound
*************** following union and variables:
*** 35475,35481 ****
       double y;
       union foo z;
  
! both 'x' and 'y' can be cast to type 'union foo' and the following
  assignments
         z = (union foo) x;
         z = (union foo) y;
--- 35484,35490 ----
       double y;
       union foo z;
  
! both ‘x’ and ‘y’ can be cast to type ‘union foo’ and the following
  assignments
         z = (union foo) x;
         z = (union foo) y;
*************** assignments
*** 35483,35490 ****
         z = (union foo) { .i = x };
         z = (union foo) { .d = y };
  
!  However, '(union foo) FLT_MAX;' is not a valid cast because the union
! has no member of type 'float'.
  
   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 with the
--- 35492,35499 ----
         z = (union foo) { .i = x };
         z = (union foo) { .d = y };
  
!  However, ‘(union foo) FLT_MAX;’ is not a valid cast because the union
! has no member of type ‘float’.
  
   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 with the
*************** same type
*** 35492,35499 ****
  
       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:
  
--- 35501,35508 ----
  
       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:
  
*************** File: gcc.info,  Node: Function Attribut
*** 35529,35537 ****
  In GNU C and C++, you can use function attributes to specify certain
  function properties that may help the compiler optimize calls or check
  code more carefully for correctness.  For example, you can use
! attributes to specify that a function never returns ('noreturn'),
! returns a value depending only on the values of its arguments ('const'),
! or has 'printf'-style arguments ('format').
  
   You can also use attributes to control memory placement, code
  generation options or call/return conventions within the function being
--- 35538,35546 ----
  In GNU C and C++, you can use function attributes to specify certain
  function properties that may help the compiler optimize calls or check
  code more carefully for correctness.  For example, you can use
! attributes to specify that a function never returns (‘noreturn’),
! returns a value depending only on the values of its arguments (‘const’),
! or has ‘printf’-style arguments (‘format’).
  
   You can also use attributes to control memory placement, code
  generation options or call/return conventions within the function being
*************** target.  However, a considerable number
*** 35543,35549 ****
  most, if not all targets.  Those are described in the *note Common
  Function Attributes:: section.
  
!  Function attributes are introduced by the '__attribute__' keyword in
  the declaration of a function, followed by an attribute specification
  enclosed in double parentheses.  You can specify multiple attributes in
  a declaration by separating them by commas within the double parentheses
--- 35552,35558 ----
  most, if not all targets.  Those are described in the *note Common
  Function Attributes:: section.
  
!  Function attributes are introduced by the ‘__attribute__’ keyword in
  the declaration of a function, followed by an attribute specification
  enclosed in double parentheses.  You can specify multiple attributes in
  a declaration by separating them by commas within the double parentheses
*************** function is ignored with a warning.
*** 35556,35569 ****
  
   Some function attributes take one or more arguments that refer to the
  function's parameters by their positions within the function parameter
! list.  Such attribute arguments are referred to as "positional
! arguments".  Unless specified otherwise, positional arguments that
  specify properties of parameters with pointer types can also specify the
! same properties of the implicit C++ 'this' argument in non-static member
  functions, and of parameters of reference to a pointer type.  For
  ordinary functions, position one refers to the first parameter on the
  list.  In C++ non-static member functions, position one refers to the
! implicit 'this' pointer.  The same restrictions and effects apply to
  function attributes used with ordinary functions or C++ member
  functions.
  
--- 35565,35578 ----
  
   Some function attributes take one or more arguments that refer to the
  function's parameters by their positions within the function parameter
! list.  Such attribute arguments are referred to as “positional
! arguments”.  Unless specified otherwise, positional arguments that
  specify properties of parameters with pointer types can also specify the
! same properties of the implicit C++ ‘this’ argument in non-static member
  functions, and of parameters of reference to a pointer type.  For
  ordinary functions, position one refers to the first parameter on the
  list.  In C++ non-static member functions, position one refers to the
! implicit ‘this’ pointer.  The same restrictions and effects apply to
  function attributes used with ordinary functions or C++ member
  functions.
  
*************** functions.
*** 35571,35582 ****
  Attributes::), labels (*note Label Attributes::), enumerators (*note
  Enumerator Attributes::), statements (*note Statement Attributes::),
  types (*note Type Attributes::), and on field declarations (for
! 'tainted_args').
  
   There is some overlap between the purposes of attributes and pragmas
  (*note Pragmas Accepted by GCC: Pragmas.).  It has been found convenient
! to use '__attribute__' to achieve a natural attachment of attributes to
! their corresponding declarations, whereas '#pragma' is of use for
  compatibility with other compilers or constructs that do not naturally
  form part of the grammar.
  
--- 35580,35591 ----
  Attributes::), labels (*note Label Attributes::), enumerators (*note
  Enumerator Attributes::), statements (*note Statement Attributes::),
  types (*note Type Attributes::), and on field declarations (for
! ‘tainted_args’).
  
   There is some overlap between the purposes of attributes and pragmas
  (*note Pragmas Accepted by GCC: Pragmas.).  It has been found convenient
! to use ‘__attribute__’ to achieve a natural attachment of attributes to
! their corresponding declarations, whereas ‘#pragma’ is of use for
  compatibility with other compilers or constructs that do not naturally
  form part of the grammar.
  
*************** File: gcc.info,  Node: Common Function A
*** 35628,35673 ****
  
  The following attributes are supported on most targets.
  
! 'access (ACCESS-MODE, REF-INDEX)'
! 'access (ACCESS-MODE, REF-INDEX, SIZE-INDEX)'
  
!      The 'access' attribute enables the detection of invalid or unsafe
       accesses by functions to which they apply or their callers, as well
       as write-only accesses to objects that are never read from.  Such
       accesses may be diagnosed by warnings such as
!      '-Wstringop-overflow', '-Wuninitialized', '-Wunused', and others.
  
!      The 'access' attribute specifies that a function to whose
       by-reference arguments the attribute applies accesses the
       referenced object according to ACCESS-MODE.  The ACCESS-MODE
!      argument is required and must be one of four names: 'read_only',
!      'read_write', 'write_only', or 'none'.  The remaining two are
       positional arguments.
  
       The required REF-INDEX positional argument denotes a function
       argument of pointer (or in C++, reference) type that is subject to
       the access.  The same pointer argument can be referenced by at most
!      one distinct 'access' attribute.
  
       The optional SIZE-INDEX positional argument denotes a function
       argument of integer type that specifies the maximum size of the
       access.  The size is the number of elements of the type referenced
       by REF-INDEX, or the number of bytes when the pointer type is
!      'void*'.  When no SIZE-INDEX argument is specified, the pointer
       argument must be either null or point to a space that is suitably
       aligned and large for at least one object of the referenced type
       (this implies that a past-the-end pointer is not a valid argument).
       The actual size of the access may be less but it must not be more.
  
!      The 'read_only' access mode specifies that the pointer to which it
       applies is used to read the referenced object but not write to it.
       Unless the argument specifying the size of the access denoted by
       SIZE-INDEX is zero, the referenced object must be initialized.  The
!      mode implies a stronger guarantee than the 'const' qualifier which,
       when cast away from a pointer, does not prevent the pointed-to
!      object from being modified.  Examples of the use of the 'read_only'
!      access mode is the argument to the 'puts' function, or the second
!      and third arguments to the 'memcpy' function.
  
            __attribute__ ((access (read_only, 1)))
            int puts (const char*);
--- 35637,35682 ----
  
  The following attributes are supported on most targets.
  
! ‘access (ACCESS-MODE, REF-INDEX)’
! ‘access (ACCESS-MODE, REF-INDEX, SIZE-INDEX)’
  
!      The ‘access’ attribute enables the detection of invalid or unsafe
       accesses by functions to which they apply or their callers, as well
       as write-only accesses to objects that are never read from.  Such
       accesses may be diagnosed by warnings such as
!      ‘-Wstringop-overflow’, ‘-Wuninitialized’, ‘-Wunused’, and others.
  
!      The ‘access’ attribute specifies that a function to whose
       by-reference arguments the attribute applies accesses the
       referenced object according to ACCESS-MODE.  The ACCESS-MODE
!      argument is required and must be one of four names: ‘read_only’,
!      ‘read_write’, ‘write_only’, or ‘none’.  The remaining two are
       positional arguments.
  
       The required REF-INDEX positional argument denotes a function
       argument of pointer (or in C++, reference) type that is subject to
       the access.  The same pointer argument can be referenced by at most
!      one distinct ‘access’ attribute.
  
       The optional SIZE-INDEX positional argument denotes a function
       argument of integer type that specifies the maximum size of the
       access.  The size is the number of elements of the type referenced
       by REF-INDEX, or the number of bytes when the pointer type is
!      ‘void*’.  When no SIZE-INDEX argument is specified, the pointer
       argument must be either null or point to a space that is suitably
       aligned and large for at least one object of the referenced type
       (this implies that a past-the-end pointer is not a valid argument).
       The actual size of the access may be less but it must not be more.
  
!      The ‘read_only’ access mode specifies that the pointer to which it
       applies is used to read the referenced object but not write to it.
       Unless the argument specifying the size of the access denoted by
       SIZE-INDEX is zero, the referenced object must be initialized.  The
!      mode implies a stronger guarantee than the ‘const’ qualifier which,
       when cast away from a pointer, does not prevent the pointed-to
!      object from being modified.  Examples of the use of the ‘read_only’
!      access mode is the argument to the ‘puts’ function, or the second
!      and third arguments to the ‘memcpy’ function.
  
            __attribute__ ((access (read_only, 1)))
            int puts (const char*);
*************** The following attributes are supported o
*** 35675,35698 ****
            __attribute__ ((access (read_only, 2, 3)))
            void* memcpy (void*, const void*, size_t);
  
!      The 'read_write' access mode applies to arguments of pointer types
!      without the 'const' qualifier.  It specifies that the pointer to
       which it applies is used to both read and write the referenced
       object.  Unless the argument specifying the size of the access
       denoted by SIZE-INDEX is zero, the object referenced by the pointer
!      must be initialized.  An example of the use of the 'read_write'
!      access mode is the first argument to the 'strcat' function.
  
            __attribute__ ((access (read_write, 1), access (read_only, 2)))
            char* strcat (char*, const char*);
  
!      The 'write_only' access mode applies to arguments of pointer types
!      without the 'const' qualifier.  It specifies that the pointer to
       which it applies is used to write to the referenced object but not
       read from it.  The object referenced by the pointer need not be
!      initialized.  An example of the use of the 'write_only' access mode
!      is the first argument to the 'strcpy' function, or the first two
!      arguments to the 'fgets' function.
  
            __attribute__ ((access (write_only, 1), access (read_only, 2)))
            char* strcpy (char*, const char*);
--- 35684,35707 ----
            __attribute__ ((access (read_only, 2, 3)))
            void* memcpy (void*, const void*, size_t);
  
!      The ‘read_write’ access mode applies to arguments of pointer types
!      without the ‘const’ qualifier.  It specifies that the pointer to
       which it applies is used to both read and write the referenced
       object.  Unless the argument specifying the size of the access
       denoted by SIZE-INDEX is zero, the object referenced by the pointer
!      must be initialized.  An example of the use of the ‘read_write’
!      access mode is the first argument to the ‘strcat’ function.
  
            __attribute__ ((access (read_write, 1), access (read_only, 2)))
            char* strcat (char*, const char*);
  
!      The ‘write_only’ access mode applies to arguments of pointer types
!      without the ‘const’ qualifier.  It specifies that the pointer to
       which it applies is used to write to the referenced object but not
       read from it.  The object referenced by the pointer need not be
!      initialized.  An example of the use of the ‘write_only’ access mode
!      is the first argument to the ‘strcpy’ function, or the first two
!      arguments to the ‘fgets’ function.
  
            __attribute__ ((access (write_only, 1), access (read_only, 2)))
            char* strcpy (char*, const char*);
*************** The following attributes are supported o
*** 35700,35726 ****
            __attribute__ ((access (write_only, 1, 2), access (read_write, 3)))
            int fgets (char*, int, FILE*);
  
!      The access mode 'none' specifies that the pointer to which it
       applies is not used to access the referenced object at all.  Unless
       the pointer is null the pointed-to object must exist and have at
       least the size as denoted by the SIZE-INDEX argument.  When the
!      optional SIZE-INDEX argument is omitted for an argument of 'void*'
       type the actual pointer agument is ignored.  The referenced object
       need not be initialized.  The mode is intended to be used as a
       means to help validate the expected object size, for example in
!      functions that call '__builtin_object_size'.  *Note Object Size
       Checking::.
  
!      Note that the 'access' attribute merely specifies how an object
       referenced by the pointer argument can be accessed; it does not
!      imply that an access *will* happen.  Also, the 'access' attribute
!      does not imply the attribute 'nonnull'; it may be appropriate to
       add both attributes at the declaration of a function that
       unconditionally manipulates a buffer via a pointer argument.  See
!      the 'nonnull' attribute for more information and caveats.
  
! 'alias ("TARGET")'
!      The 'alias' attribute causes the declaration to be emitted as an
       alias for another symbol, which must have been previously declared
       with the same type, and for variables, also the same size and
       alignment.  Declaring an alias with a different type than the
--- 35709,35735 ----
            __attribute__ ((access (write_only, 1, 2), access (read_write, 3)))
            int fgets (char*, int, FILE*);
  
!      The access mode ‘none’ specifies that the pointer to which it
       applies is not used to access the referenced object at all.  Unless
       the pointer is null the pointed-to object must exist and have at
       least the size as denoted by the SIZE-INDEX argument.  When the
!      optional SIZE-INDEX argument is omitted for an argument of ‘void*’
       type the actual pointer agument is ignored.  The referenced object
       need not be initialized.  The mode is intended to be used as a
       means to help validate the expected object size, for example in
!      functions that call ‘__builtin_object_size’.  *Note Object Size
       Checking::.
  
!      Note that the ‘access’ attribute merely specifies how an object
       referenced by the pointer argument can be accessed; it does not
!      imply that an access *will* happen.  Also, the ‘access’ attribute
!      does not imply the attribute ‘nonnull’; it may be appropriate to
       add both attributes at the declaration of a function that
       unconditionally manipulates a buffer via a pointer argument.  See
!      the ‘nonnull’ attribute for more information and caveats.
  
! ‘alias ("TARGET")’
!      The ‘alias’ attribute causes the declaration to be emitted as an
       alias for another symbol, which must have been previously declared
       with the same type, and for variables, also the same size and
       alignment.  Declaring an alias with a different type than the
*************** The following attributes are supported o
*** 35730,35749 ****
            void __f () { /* Do something. */; }
            void f () __attribute__ ((weak, alias ("__f")));
  
!      define '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.
  
       This attribute requires assembler and object file support, and may
       not be available on all targets.
  
! 'aligned'
! 'aligned (ALIGNMENT)'
!      The 'aligned' attribute specifies a minimum alignment for the first
       instruction of the function, measured in bytes.  When specified,
       ALIGNMENT must be an integer constant power of 2.  Specifying no
       ALIGNMENT argument implies the ideal alignment for the target.  The
!      '__alignof__' operator can be used to determine what that is (*note
       Alignment::).  The attribute has no effect when a definition for
       the function is not provided in the same translation unit.
  
--- 35739,35758 ----
            void __f () { /* Do something. */; }
            void f () __attribute__ ((weak, alias ("__f")));
  
!      define ‘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.
  
       This attribute requires assembler and object file support, and may
       not be available on all targets.
  
! ‘aligned’
! ‘aligned (ALIGNMENT)’
!      The ‘aligned’ attribute specifies a minimum alignment for the first
       instruction of the function, measured in bytes.  When specified,
       ALIGNMENT must be an integer constant power of 2.  Specifying no
       ALIGNMENT argument implies the ideal alignment for the target.  The
!      ‘__alignof__’ operator can be used to determine what that is (*note
       Alignment::).  The attribute has no effect when a definition for
       the function is not provided in the same translation unit.
  
*************** The following attributes are supported o
*** 35753,35773 ****
       targets specify a minimum default alignment for functions that is
       greater than 1.  On such targets, specifying a less restrictive
       alignment is silently ignored.  Using the attribute overrides the
!      effect of the '-falign-functions' (*note Optimize Options::) option
       for this function.
  
!      Note that the effectiveness of 'aligned' attributes may be limited
       by inherent limitations in the system linker and/or object file
       format.  On some 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_align (POSITION)'
!      The 'alloc_align' attribute may be applied to a function that
       returns a pointer and takes at least one argument of an integer or
       enumerated type.  It indicates that the returned pointer is aligned
       on a boundary given by the function argument at POSITION.
--- 35762,35782 ----
       targets specify a minimum default alignment for functions that is
       greater than 1.  On such targets, specifying a less restrictive
       alignment is silently ignored.  Using the attribute overrides the
!      effect of the ‘-falign-functions’ (*note Optimize Options::) option
       for this function.
  
!      Note that the effectiveness of ‘aligned’ attributes may be limited
       by inherent limitations in the system linker and/or object file
       format.  On some 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_align (POSITION)’
!      The ‘alloc_align’ attribute may be applied to a function that
       returns a pointer and takes at least one argument of an integer or
       enumerated type.  It indicates that the returned pointer is aligned
       on a boundary given by the function argument at POSITION.
*************** The following attributes are supported o
*** 35782,35800 ****
  
            void* my_memalign (size_t, size_t) __attribute__ ((alloc_align (1)));
  
!      declares that 'my_memalign' returns memory with minimum alignment
       given by parameter 1.
  
! 'alloc_size (POSITION)'
! 'alloc_size (POSITION-1, POSITION-2)'
!      The 'alloc_size' attribute may be applied to a function that
       returns a pointer and takes at least one argument of an integer or
       enumerated type.  It indicates that the returned pointer points to
       memory whose size is given by the function argument at POSITION-1,
       or by the product of the arguments at POSITION-1 and POSITION-2.
!      Meaningful sizes are positive values less than 'PTRDIFF_MAX'.  GCC
       uses this information to improve the results 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
--- 35791,35809 ----
  
            void* my_memalign (size_t, size_t) __attribute__ ((alloc_align (1)));
  
!      declares that ‘my_memalign’ returns memory with minimum alignment
       given by parameter 1.
  
! ‘alloc_size (POSITION)’
! ‘alloc_size (POSITION-1, POSITION-2)’
!      The ‘alloc_size’ attribute may be applied to a function that
       returns a pointer and takes at least one argument of an integer or
       enumerated type.  It indicates that the returned pointer points to
       memory whose size is given by the function argument at POSITION-1,
       or by the product of the arguments at POSITION-1 and POSITION-2.
!      Meaningful sizes are positive values less than ‘PTRDIFF_MAX’.  GCC
       uses this information to improve the results 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
*************** The following attributes are supported o
*** 35808,35818 ****
            void* my_calloc (size_t, size_t) __attribute__ ((alloc_size (1, 2)));
            void* my_realloc (void*, size_t) __attribute__ ((alloc_size (2)));
  
!      declares that 'my_calloc' returns memory of the size given by the
!      product of parameter 1 and 2 and that 'my_realloc' returns memory
       of the size given by parameter 2.
  
! 'always_inline'
       Generally, functions are not inlined unless optimization is
       specified.  For functions declared inline, this attribute inlines
       the function independent of any restrictions that otherwise apply
--- 35817,35827 ----
            void* my_calloc (size_t, size_t) __attribute__ ((alloc_size (1, 2)));
            void* my_realloc (void*, size_t) __attribute__ ((alloc_size (2)));
  
!      declares that ‘my_calloc’ returns memory of the size given by the
!      product of parameter 1 and 2 and that ‘my_realloc’ returns memory
       of the size given by parameter 2.
  
! ‘always_inline’
       Generally, functions are not inlined unless optimization is
       specified.  For functions declared inline, this attribute inlines
       the function independent of any restrictions that otherwise apply
*************** The following attributes are supported o
*** 35822,35837 ****
       and a failure to inline an indirect call may or may not be
       diagnosed.
  
! 'artificial'
       This attribute is useful for small inline wrappers that if possible
       should appear during debugging as a unit.  Depending on the debug
       info format it either means marking the function as artificial or
       using the caller location for all instructions within the inlined
       body.
  
! 'assume_aligned (ALIGNMENT)'
! 'assume_aligned (ALIGNMENT, OFFSET)'
!      The 'assume_aligned' attribute may be applied to a function that
       returns a pointer.  It indicates that the returned pointer is
       aligned on a boundary given by ALIGNMENT.  If the attribute has two
       arguments, the second argument is misalignment OFFSET.  Meaningful
--- 35831,35846 ----
       and a failure to inline an indirect call may or may not be
       diagnosed.
  
! ‘artificial’
       This attribute is useful for small inline wrappers that if possible
       should appear during debugging as a unit.  Depending on the debug
       info format it either means marking the function as artificial or
       using the caller location for all instructions within the inlined
       body.
  
! ‘assume_aligned (ALIGNMENT)’
! ‘assume_aligned (ALIGNMENT, OFFSET)’
!      The ‘assume_aligned’ attribute may be applied to a function that
       returns a pointer.  It indicates that the returned pointer is
       aligned on a boundary given by ALIGNMENT.  If the attribute has two
       arguments, the second argument is misalignment OFFSET.  Meaningful
*************** The following attributes are supported o
*** 35843,35853 ****
            void* my_alloc1 (size_t) __attribute__((assume_aligned (16)));
            void* my_alloc2 (size_t) __attribute__((assume_aligned (32, 8)));
  
!      declares that 'my_alloc1' returns 16-byte aligned pointers and that
!      'my_alloc2' returns a pointer whose value modulo 32 is equal to 8.
  
! 'cold'
!      The 'cold' attribute on functions is used to inform the compiler
       that the function is unlikely to be executed.  The function is
       optimized for size rather than speed and on many targets it is
       placed into a special subsection of the text section so all cold
--- 35852,35862 ----
            void* my_alloc1 (size_t) __attribute__((assume_aligned (16)));
            void* my_alloc2 (size_t) __attribute__((assume_aligned (32, 8)));
  
!      declares that ‘my_alloc1’ returns 16-byte aligned pointers and that
!      ‘my_alloc2’ returns a pointer whose value modulo 32 is equal to 8.
  
! ‘cold’
!      The ‘cold’ attribute on functions is used to inform the compiler
       that the function is unlikely to be executed.  The function is
       optimized for size rather than speed and on many targets it is
       placed into a special subsection of the text section so all cold
*************** The following attributes are supported o
*** 35855,35873 ****
       non-cold parts of program.  The paths leading to calls of cold
       functions within code are marked as unlikely by the branch
       prediction mechanism.  It is thus useful to mark functions used to
!      handle unlikely conditions, such as 'perror', as cold to improve
       optimization of hot functions that do call marked functions in rare
       occasions.
  
!      When profile feedback is available, via '-fprofile-use', cold
       functions are automatically detected and this attribute is ignored.
  
! 'const'
       Calls to functions whose return value is not affected by changes to
       the observable state of the program and that have no observable
       effects on such state other than to return a value may lend
       themselves to optimizations such as common subexpression
!      elimination.  Declaring such functions with the 'const' attribute
       allows GCC to avoid emitting some calls in repeated invocations of
       the function with the same argument values.
  
--- 35864,35882 ----
       non-cold parts of program.  The paths leading to calls of cold
       functions within code are marked as unlikely by the branch
       prediction mechanism.  It is thus useful to mark functions used to
!      handle unlikely conditions, such as ‘perror’, as cold to improve
       optimization of hot functions that do call marked functions in rare
       occasions.
  
!      When profile feedback is available, via ‘-fprofile-use’, cold
       functions are automatically detected and this attribute is ignored.
  
! ‘const’
       Calls to functions whose return value is not affected by changes to
       the observable state of the program and that have no observable
       effects on such state other than to return a value may lend
       themselves to optimizations such as common subexpression
!      elimination.  Declaring such functions with the ‘const’ attribute
       allows GCC to avoid emitting some calls in repeated invocations of
       the function with the same argument values.
  
*************** The following attributes are supported o
*** 35875,35913 ****
  
            int square (int) __attribute__ ((const));
  
!      tells GCC that subsequent calls to function 'square' with the same
       argument value can be replaced by the result of the first call
       regardless of the statements in between.
  
!      The 'const' attribute prohibits a function from reading objects
       that affect its return value between successive invocations.
       However, functions declared with the attribute can safely read
       objects that do not change their return value, such as non-volatile
       constants.
  
!      The 'const' attribute imposes greater restrictions on a function's
!      definition than the similar 'pure' attribute.  Declaring the same
!      function with both the 'const' and the 'pure' attribute is
       diagnosed.  Because a const function cannot have any observable
!      side effects it does not make sense for it to return 'void'.
       Declaring such a function is diagnosed.
  
       Note that a function that has pointer arguments and examines the
!      data pointed to must _not_ be declared 'const' if the pointed-to
       data might change between successive invocations of the function.
       In general, since a function cannot distinguish data that might
       change from data that cannot, const functions should never take
       pointer or, in C++, reference arguments.  Likewise, a function that
       calls a non-const function usually must not be const itself.
  
! 'constructor'
! 'destructor'
! 'constructor (PRIORITY)'
! 'destructor (PRIORITY)'
!      The 'constructor' attribute causes the function to be called
!      automatically before execution enters 'main ()'.  Similarly, the
!      'destructor' attribute causes the function to be called
!      automatically after 'main ()' completes or 'exit ()' is called.
       Functions with these attributes are useful for initializing data
       that is used implicitly during the execution of the program.
  
--- 35884,35922 ----
  
            int square (int) __attribute__ ((const));
  
!      tells GCC that subsequent calls to function ‘square’ with the same
       argument value can be replaced by the result of the first call
       regardless of the statements in between.
  
!      The ‘const’ attribute prohibits a function from reading objects
       that affect its return value between successive invocations.
       However, functions declared with the attribute can safely read
       objects that do not change their return value, such as non-volatile
       constants.
  
!      The ‘const’ attribute imposes greater restrictions on a function's
!      definition than the similar ‘pure’ attribute.  Declaring the same
!      function with both the ‘const’ and the ‘pure’ attribute is
       diagnosed.  Because a const function cannot have any observable
!      side effects it does not make sense for it to return ‘void’.
       Declaring such a function is diagnosed.
  
       Note that a function that has pointer arguments and examines the
!      data pointed to must _not_ be declared ‘const’ if the pointed-to
       data might change between successive invocations of the function.
       In general, since a function cannot distinguish data that might
       change from data that cannot, const functions should never take
       pointer or, in C++, reference arguments.  Likewise, a function that
       calls a non-const function usually must not be const itself.
  
! ‘constructor’
! ‘destructor’
! ‘constructor (PRIORITY)’
! ‘destructor (PRIORITY)’
!      The ‘constructor’ attribute causes the function to be called
!      automatically before execution enters ‘main ()’.  Similarly, the
!      ‘destructor’ attribute causes the function to be called
!      automatically after ‘main ()’ completes or ‘exit ()’ is called.
       Functions with these attributes are useful for initializing data
       that is used implicitly during the execution of the program.
  
*************** The following attributes are supported o
*** 35923,35958 ****
       those specified for namespace-scope C++ objects (*note C++
       Attributes::).  However, at present, the order in which
       constructors for C++ objects with static storage duration and
!      functions decorated with attribute 'constructor' are invoked is
!      unspecified.  In mixed declarations, attribute 'init_priority' can
       be used to impose a specific ordering.
  
!      Using the argument forms of the 'constructor' and 'destructor'
       attributes on targets where the feature is not supported is
       rejected with an error.
  
! 'copy'
! 'copy (FUNCTION)'
!      The 'copy' attribute applies the set of attributes with which
       FUNCTION has been declared to the declaration of the function to
       which the attribute is applied.  The attribute is designed for
       libraries that define aliases or function resolvers that are
       expected to specify the same set of attributes as their targets.
!      The 'copy' attribute can be used with functions, variables, or
       types.  However, the kind of symbol to which the attribute is
       applied (either function or variable) must match the kind of symbol
!      to which the argument refers.  The 'copy' attribute copies only
       syntactic and semantic attributes but not attributes that affect a
!      symbol's linkage or visibility such as 'alias', 'visibility', or
!      'weak'.  The 'deprecated' and 'target_clones' attribute are also
       not copied.  *Note Common Type Attributes::.  *Note Common Variable
       Attributes::.
  
!      For example, the STRONGALIAS macro below makes use of the 'alias'
!      and 'copy' attributes to define an alias named ALLOC for function
       ALLOCATE declared with attributes ALLOC_SIZE, MALLOC, and NOTHROW.
!      Thanks to the '__typeof__' operator the alias has the same type as
!      the target function.  As a result of the 'copy' attribute the alias
       also shares the same attributes as the target.
  
            #define StrongAlias(TargetFunc, AliasDecl)  \
--- 35932,35967 ----
       those specified for namespace-scope C++ objects (*note C++
       Attributes::).  However, at present, the order in which
       constructors for C++ objects with static storage duration and
!      functions decorated with attribute ‘constructor’ are invoked is
!      unspecified.  In mixed declarations, attribute ‘init_priority’ can
       be used to impose a specific ordering.
  
!      Using the argument forms of the ‘constructor’ and ‘destructor’
       attributes on targets where the feature is not supported is
       rejected with an error.
  
! ‘copy’
! ‘copy (FUNCTION)’
!      The ‘copy’ attribute applies the set of attributes with which
       FUNCTION has been declared to the declaration of the function to
       which the attribute is applied.  The attribute is designed for
       libraries that define aliases or function resolvers that are
       expected to specify the same set of attributes as their targets.
!      The ‘copy’ attribute can be used with functions, variables, or
       types.  However, the kind of symbol to which the attribute is
       applied (either function or variable) must match the kind of symbol
!      to which the argument refers.  The ‘copy’ attribute copies only
       syntactic and semantic attributes but not attributes that affect a
!      symbol's linkage or visibility such as ‘alias’, ‘visibility’, or
!      ‘weak’.  The ‘deprecated’ and ‘target_clones’ attribute are also
       not copied.  *Note Common Type Attributes::.  *Note Common Variable
       Attributes::.
  
!      For example, the STRONGALIAS macro below makes use of the ‘alias’
!      and ‘copy’ attributes to define an alias named ALLOC for function
       ALLOCATE declared with attributes ALLOC_SIZE, MALLOC, and NOTHROW.
!      Thanks to the ‘__typeof__’ operator the alias has the same type as
!      the target function.  As a result of the ‘copy’ attribute the alias
       also shares the same attributes as the target.
  
            #define StrongAlias(TargetFunc, AliasDecl)  \
*************** The following attributes are supported o
*** 35963,35971 ****
              void* allocate (size_t);
            StrongAlias (allocate, alloc);
  
! '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
--- 35972,35980 ----
              void* allocate (size_t);
            StrongAlias (allocate, alloc);
  
! ‘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
*************** The following attributes are supported o
*** 35981,36079 ****
       argument, which must be a string, is printed in the warning if
       present.
  
!      The 'deprecated' attribute can also be used for variables and types
       (*note Variable Attributes::, *note Type Attributes::.)
  
       The message attached to the attribute is affected by the setting of
!      the '-fmessage-length' option.
  
! 'unavailable'
! 'unavailable (MSG)'
!      The 'unavailable' attribute results in an error if the function is
       used anywhere in the source file.  This is useful when identifying
       functions that have been removed from a particular variation of an
       interface.  Other than emitting an error rather than a warning, the
!      'unavailable' attribute behaves in the same manner as 'deprecated'.
  
!      The 'unavailable' attribute can also be used for variables and
       types (*note Variable Attributes::, *note Type Attributes::.)
  
! 'error ("MESSAGE")'
! 'warning ("MESSAGE")'
!      If the 'error' or 'warning' 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 or warning
       (respectively) that includes MESSAGE is diagnosed.  This is useful
       for compile-time checking, especially together with
!      '__builtin_constant_p' and inline functions where checking the
!      inline function arguments is not possible through 'extern char
!      [(condition) ? 1 : -1];' tricks.
  
       While it is possible to leave the function undefined and thus
       invoke a link failure (to define the function with a message in
!      '.gnu.warning*' section), when using these attributes the problem
       is diagnosed earlier and with exact location of the call even in
       presence of inline functions or when not emitting debugging
       information.
  
! '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.
  
! 'fd_arg'
! 'fd_arg (N)'
!      The 'fd_arg' attribute may be applied to a function that takes an
       open file descriptor at referenced argument N.
  
       It indicates that the passed filedescriptor must not have been
!      closed.  Therefore, when the analyzer is enabled with '-fanalyzer',
!      the analyzer may emit a '-Wanalyzer-fd-use-after-close' diagnostic
       if it detects a code path in which a function with this attribute
       is called with a closed file descriptor.
  
       The attribute also indicates that the file descriptor must have
       been checked for validity before usage.  Therefore, analyzer may
!      emit '-Wanalyzer-fd-use-without-check' diagnostic if it detects a
       code path in which a function with this attribute is called with a
       file descriptor that has not been checked for validity.
  
! 'fd_arg_read'
! 'fd_arg_read (N)'
!      The 'fd_arg_read' is identical to 'fd_arg', but with the additional
       requirement that it might read from the file descriptor, and thus,
       the file descriptor must not have been opened as write-only.
  
!      The analyzer may emit a '-Wanalyzer-access-mode-mismatch'
       diagnostic if it detects a code path in which a function with this
!      attribute is called on a file descriptor opened with 'O_WRONLY'.
  
! 'fd_arg_write'
! 'fd_arg_write (N)'
!      The 'fd_arg_write' is identical to 'fd_arg_read' except that the
!      analyzer may emit a '-Wanalyzer-access-mode-mismatch' diagnostic if
       it detects a code path in which a function with this attribute is
!      called on a file descriptor opened with 'O_RDONLY'.
  
! 'flatten'
       Generally, inlining into a function is limited.  For a function
       marked with this attribute, every call inside this function is
!      inlined, if possible.  Functions declared with attribute 'noinline'
       and similar are not inlined.  Whether the function itself is
       considered for inlining depends on its size and the current
       inlining parameters.
  
! 'format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)'
!      The 'format' attribute specifies that a function takes 'printf',
!      'scanf', 'strftime' or 'strfmon' style arguments that should be
       type-checked against a format string.  For example, the
       declaration:
  
--- 35990,36088 ----
       argument, which must be a string, is printed in the warning if
       present.
  
!      The ‘deprecated’ attribute can also be used for variables and types
       (*note Variable Attributes::, *note Type Attributes::.)
  
       The message attached to the attribute is affected by the setting of
!      the ‘-fmessage-length’ option.
  
! ‘unavailable’
! ‘unavailable (MSG)’
!      The ‘unavailable’ attribute results in an error if the function is
       used anywhere in the source file.  This is useful when identifying
       functions that have been removed from a particular variation of an
       interface.  Other than emitting an error rather than a warning, the
!      ‘unavailable’ attribute behaves in the same manner as ‘deprecated’.
  
!      The ‘unavailable’ attribute can also be used for variables and
       types (*note Variable Attributes::, *note Type Attributes::.)
  
! ‘error ("MESSAGE")’
! ‘warning ("MESSAGE")’
!      If the ‘error’ or ‘warning’ 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 or warning
       (respectively) that includes MESSAGE is diagnosed.  This is useful
       for compile-time checking, especially together with
!      ‘__builtin_constant_p’ and inline functions where checking the
!      inline function arguments is not possible through ‘extern char
!      [(condition) ? 1 : -1];’ tricks.
  
       While it is possible to leave the function undefined and thus
       invoke a link failure (to define the function with a message in
!      ‘.gnu.warning*’ section), when using these attributes the problem
       is diagnosed earlier and with exact location of the call even in
       presence of inline functions or when not emitting debugging
       information.
  
! ‘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.
  
! ‘fd_arg’
! ‘fd_arg (N)’
!      The ‘fd_arg’ attribute may be applied to a function that takes an
       open file descriptor at referenced argument N.
  
       It indicates that the passed filedescriptor must not have been
!      closed.  Therefore, when the analyzer is enabled with ‘-fanalyzer’,
!      the analyzer may emit a ‘-Wanalyzer-fd-use-after-close’ diagnostic
       if it detects a code path in which a function with this attribute
       is called with a closed file descriptor.
  
       The attribute also indicates that the file descriptor must have
       been checked for validity before usage.  Therefore, analyzer may
!      emit ‘-Wanalyzer-fd-use-without-check’ diagnostic if it detects a
       code path in which a function with this attribute is called with a
       file descriptor that has not been checked for validity.
  
! ‘fd_arg_read’
! ‘fd_arg_read (N)’
!      The ‘fd_arg_read’ is identical to ‘fd_arg’, but with the additional
       requirement that it might read from the file descriptor, and thus,
       the file descriptor must not have been opened as write-only.
  
!      The analyzer may emit a ‘-Wanalyzer-access-mode-mismatch’
       diagnostic if it detects a code path in which a function with this
!      attribute is called on a file descriptor opened with ‘O_WRONLY’.
  
! ‘fd_arg_write’
! ‘fd_arg_write (N)’
!      The ‘fd_arg_write’ is identical to ‘fd_arg_read’ except that the
!      analyzer may emit a ‘-Wanalyzer-access-mode-mismatch’ diagnostic if
       it detects a code path in which a function with this attribute is
!      called on a file descriptor opened with ‘O_RDONLY’.
  
! ‘flatten’
       Generally, inlining into a function is limited.  For a function
       marked with this attribute, every call inside this function is
!      inlined, if possible.  Functions declared with attribute ‘noinline’
       and similar are not inlined.  Whether the function itself is
       considered for inlining depends on its size and the current
       inlining parameters.
  
! ‘format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)’
!      The ‘format’ attribute specifies that a function takes ‘printf’,
!      ‘scanf’, ‘strftime’ or ‘strfmon’ style arguments that should be
       type-checked against a format string.  For example, the
       declaration:
  
*************** The following attributes are supported o
*** 36081,36132 ****
            my_printf (void *my_object, const char *my_format, ...)
                  __attribute__ ((format (printf, 2, 3)));
  
!      causes the compiler to check the arguments in calls to 'my_printf'
!      for consistency with the 'printf' style format string argument
!      'my_format'.
  
       The parameter ARCHETYPE determines how the format string is
!      interpreted, and should be 'printf', 'scanf', 'strftime',
!      'gnu_printf', 'gnu_scanf', 'gnu_strftime' or 'strfmon'.  (You can
!      also use '__printf__', '__scanf__', '__strftime__' or
!      '__strfmon__'.)  On MinGW targets, 'ms_printf', 'ms_scanf', and
!      'ms_strftime' are also present.  ARCHETYPE values such as 'printf'
       refer to the formats accepted by the system's C runtime library,
!      while values prefixed with 'gnu_' always refer to the formats
       accepted by the GNU C Library.  On Microsoft Windows targets,
!      values prefixed with 'ms_' refer to the formats accepted by the
!      'msvcrt.dll' library.  The parameter STRING-INDEX specifies which
       argument is the format string argument (starting from 1), while
       FIRST-TO-CHECK is the number of the first argument to check against
       the format string.  For functions where the arguments are not
!      available to be checked (such as 'vprintf'), specify the third
       parameter as zero.  In this case the compiler only checks the
!      format string for consistency.  For 'strftime' formats, the third
       parameter is required to be zero.  Since non-static C++ methods
!      have an implicit 'this' argument, the arguments of such methods
       should be counted from two, not one, when giving values for
       STRING-INDEX and FIRST-TO-CHECK.
  
!      In the example above, the format string ('my_format') is the second
!      argument of the function 'my_print', and the arguments to check
       start with the third argument, so the correct parameters for the
       format attribute are 2 and 3.
  
!      The 'format' attribute allows you to identify your own functions
       that take format strings as arguments, so that GCC can check the
       calls to these functions for errors.  The compiler always (unless
!      '-ffreestanding' or '-fno-builtin' is used) checks formats for the
!      standard library functions 'printf', 'fprintf', 'sprintf', 'scanf',
!      'fscanf', 'sscanf', 'strftime', 'vprintf', 'vfprintf' and
!      'vsprintf' whenever such warnings are requested (using '-Wformat'),
!      so there is no need to modify the header file 'stdio.h'.  In C99
!      mode, the functions 'snprintf', 'vsnprintf', 'vscanf', 'vfscanf'
!      and 'vsscanf' are also checked.  Except in strictly conforming C
!      standard modes, the X/Open function 'strfmon' is also checked as
!      are 'printf_unlocked' and 'fprintf_unlocked'.  *Note Options
       Controlling C Dialect: C Dialect Options.
  
!      For Objective-C dialects, 'NSString' (or '__NSString__') is
       recognized in the same context.  Declarations including these
       format attributes are parsed for correct syntax, however the result
       of checking of such format strings is not yet defined, and is not
--- 36090,36141 ----
            my_printf (void *my_object, const char *my_format, ...)
                  __attribute__ ((format (printf, 2, 3)));
  
!      causes the compiler to check the arguments in calls to ‘my_printf’
!      for consistency with the ‘printf’ style format string argument
!      ‘my_format’.
  
       The parameter ARCHETYPE determines how the format string is
!      interpreted, and should be ‘printf’, ‘scanf’, ‘strftime’,
!      ‘gnu_printf’, ‘gnu_scanf’, ‘gnu_strftime’ or ‘strfmon’.  (You can
!      also use ‘__printf__’, ‘__scanf__’, ‘__strftime__’ or
!      ‘__strfmon__’.)  On MinGW targets, ‘ms_printf’, ‘ms_scanf’, and
!      ‘ms_strftime’ are also present.  ARCHETYPE values such as ‘printf’
       refer to the formats accepted by the system's C runtime library,
!      while values prefixed with ‘gnu_’ always refer to the formats
       accepted by the GNU C Library.  On Microsoft Windows targets,
!      values prefixed with ‘ms_’ refer to the formats accepted by the
!      ‘msvcrt.dll’ library.  The parameter STRING-INDEX specifies which
       argument is the format string argument (starting from 1), while
       FIRST-TO-CHECK is the number of the first argument to check against
       the format string.  For functions where the arguments are not
!      available to be checked (such as ‘vprintf’), specify the third
       parameter as zero.  In this case the compiler only checks the
!      format string for consistency.  For ‘strftime’ formats, the third
       parameter is required to be zero.  Since non-static C++ methods
!      have an implicit ‘this’ argument, the arguments of such methods
       should be counted from two, not one, when giving values for
       STRING-INDEX and FIRST-TO-CHECK.
  
!      In the example above, the format string (‘my_format’) is the second
!      argument of the function ‘my_print’, and the arguments to check
       start with the third argument, so the correct parameters for the
       format attribute are 2 and 3.
  
!      The ‘format’ attribute allows you to identify your own functions
       that take format strings as arguments, so that GCC can check the
       calls to these functions for errors.  The compiler always (unless
!      ‘-ffreestanding’ or ‘-fno-builtin’ is used) checks formats for the
!      standard library functions ‘printf’, ‘fprintf’, ‘sprintf’, ‘scanf’,
!      ‘fscanf’, ‘sscanf’, ‘strftime’, ‘vprintf’, ‘vfprintf’ and
!      ‘vsprintf’ whenever such warnings are requested (using ‘-Wformat’),
!      so there is no need to modify the header file ‘stdio.h’.  In C99
!      mode, the functions ‘snprintf’, ‘vsnprintf’, ‘vscanf’, ‘vfscanf’
!      and ‘vsscanf’ are also checked.  Except in strictly conforming C
!      standard modes, the X/Open function ‘strfmon’ is also checked as
!      are ‘printf_unlocked’ and ‘fprintf_unlocked’.  *Note Options
       Controlling C Dialect: C Dialect Options.
  
!      For Objective-C dialects, ‘NSString’ (or ‘__NSString__’) is
       recognized in the same context.  Declarations including these
       format attributes are parsed for correct syntax, however the result
       of checking of such format strings is not yet defined, and is not
*************** The following attributes are supported o
*** 36136,36149 ****
       *Note Format Checks Specific to Particular Target Machines: Target
       Format Checks.
  
! 'format_arg (STRING-INDEX)'
!      The 'format_arg' attribute specifies that a function takes one or
!      more format strings 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).  Multiple 'format_arg'
       attributes may be applied to the same function, each designating a
       distinct parameter as a format string.  For example, the
       declaration:
--- 36145,36158 ----
       *Note Format Checks Specific to Particular Target Machines: Target
       Format Checks.
  
! ‘format_arg (STRING-INDEX)’
!      The ‘format_arg’ attribute specifies that a function takes one or
!      more format strings 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).  Multiple ‘format_arg’
       attributes may be applied to the same function, each designating a
       distinct parameter as a format string.  For example, the
       declaration:
*************** The following attributes are supported o
*** 36152,36244 ****
            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.
  
!      In calls to a function declared with more than one 'format_arg'
       attribute, each with a distinct argument value, the corresponding
       actual function arguments are checked against all format strings
       designated by the attributes.  This capability is designed to
!      support the GNU 'ngettext' family of functions.
  
       The parameter STRING-INDEX specifies which argument is the format
       string argument (starting from one).  Since non-static C++ methods
!      have an implicit 'this' argument, the arguments of such methods
       should be counted from two.
  
!      The 'format_arg' attribute allows you to identify your own
       functions that modify format strings, so that GCC can check the
!      calls to 'printf', 'scanf', 'strftime' or 'strfmon' type function
       whose operands are a call to one of your own function.  The
!      compiler always treats 'gettext', 'dgettext', and 'dcgettext' in
       this manner except when strict ISO C support is requested by
!      '-ansi' or an appropriate '-std' option, or '-ffreestanding' or
!      '-fno-builtin' is used.  *Note Options Controlling C Dialect: C
       Dialect Options.
  
!      For Objective-C dialects, the 'format-arg' attribute may refer to
!      an 'NSString' reference for compatibility with the 'format'
       attribute above.
  
!      The target may also allow additional types in 'format-arg'
       attributes.  *Note Format Checks Specific to Particular Target
       Machines: Target Format Checks.
  
! 'gnu_inline'
       This attribute should be used with a function that is also declared
!      with the 'inline' keyword.  It directs GCC to treat the function as
       if it were defined in gnu90 mode even when compiling in C99 or
       gnu99 mode.
  
!      If the function is declared 'extern', then this definition of the
       function is used only for inlining.  In no case is the function
       compiled as a standalone function, not even if you take its address
       explicitly.  Such an address becomes an external reference, as if
       you had only declared the function, and had not defined it.  This
       has almost the effect of a macro.  The way to use this is to put a
       function definition in a header file with this attribute, and put
!      another copy of the function, without 'extern', in a library file.
       The definition in the header file causes most calls to the function
       to be inlined.  If any uses of the function remain, they refer to
       the single copy in the library.  Note that the two definitions of
       the functions need not be precisely the same, although if they do
       not have the same effect your program may behave oddly.
  
!      In C, if the function is neither 'extern' nor 'static', then the
       function is compiled as a standalone function, as well as being
       inlined where possible.
  
!      This is how GCC traditionally handled functions declared 'inline'.
!      Since ISO C99 specifies a different semantics for 'inline', this
       function attribute is provided as a transition measure and as a
       useful feature in its own right.  This attribute is available in
       GCC 4.1.3 and later.  It is available if either of the preprocessor
!      macros '__GNUC_GNU_INLINE__' or '__GNUC_STDC_INLINE__' are defined.
       *Note An Inline Function is As Fast As a Macro: Inline.
  
!      In C++, this attribute does not depend on 'extern' in any way, but
!      it still requires the 'inline' keyword to enable its special
       behavior.
  
! 'hot'
!      The 'hot' attribute on a function is used to inform the compiler
       that the function is a hot spot of the compiled program.  The
       function is optimized more aggressively and on many targets it is
       placed into a special subsection of the text section so all hot
       functions appear close together, improving locality.
  
!      When profile feedback is available, via '-fprofile-use', hot
       functions are automatically detected and this attribute is ignored.
  
! '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
--- 36161,36253 ----
            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.
  
!      In calls to a function declared with more than one ‘format_arg’
       attribute, each with a distinct argument value, the corresponding
       actual function arguments are checked against all format strings
       designated by the attributes.  This capability is designed to
!      support the GNU ‘ngettext’ family of functions.
  
       The parameter STRING-INDEX specifies which argument is the format
       string argument (starting from one).  Since non-static C++ methods
!      have an implicit ‘this’ argument, the arguments of such methods
       should be counted from two.
  
!      The ‘format_arg’ attribute allows you to identify your own
       functions that modify format strings, so that GCC can check the
!      calls to ‘printf’, ‘scanf’, ‘strftime’ or ‘strfmon’ type function
       whose operands are a call to one of your own function.  The
!      compiler always treats ‘gettext’, ‘dgettext’, and ‘dcgettext’ in
       this manner except when strict ISO C support is requested by
!      ‘-ansi’ or an appropriate ‘-std’ option, or ‘-ffreestanding’ or
!      ‘-fno-builtin’ is used.  *Note Options Controlling C Dialect: C
       Dialect Options.
  
!      For Objective-C dialects, the ‘format-arg’ attribute may refer to
!      an ‘NSString’ reference for compatibility with the ‘format’
       attribute above.
  
!      The target may also allow additional types in ‘format-arg’
       attributes.  *Note Format Checks Specific to Particular Target
       Machines: Target Format Checks.
  
! ‘gnu_inline’
       This attribute should be used with a function that is also declared
!      with the ‘inline’ keyword.  It directs GCC to treat the function as
       if it were defined in gnu90 mode even when compiling in C99 or
       gnu99 mode.
  
!      If the function is declared ‘extern’, then this definition of the
       function is used only for inlining.  In no case is the function
       compiled as a standalone function, not even if you take its address
       explicitly.  Such an address becomes an external reference, as if
       you had only declared the function, and had not defined it.  This
       has almost the effect of a macro.  The way to use this is to put a
       function definition in a header file with this attribute, and put
!      another copy of the function, without ‘extern’, in a library file.
       The definition in the header file causes most calls to the function
       to be inlined.  If any uses of the function remain, they refer to
       the single copy in the library.  Note that the two definitions of
       the functions need not be precisely the same, although if they do
       not have the same effect your program may behave oddly.
  
!      In C, if the function is neither ‘extern’ nor ‘static’, then the
       function is compiled as a standalone function, as well as being
       inlined where possible.
  
!      This is how GCC traditionally handled functions declared ‘inline’.
!      Since ISO C99 specifies a different semantics for ‘inline’, this
       function attribute is provided as a transition measure and as a
       useful feature in its own right.  This attribute is available in
       GCC 4.1.3 and later.  It is available if either of the preprocessor
!      macros ‘__GNUC_GNU_INLINE__’ or ‘__GNUC_STDC_INLINE__’ are defined.
       *Note An Inline Function is As Fast As a Macro: Inline.
  
!      In C++, this attribute does not depend on ‘extern’ in any way, but
!      it still requires the ‘inline’ keyword to enable its special
       behavior.
  
! ‘hot’
!      The ‘hot’ attribute on a function is used to inform the compiler
       that the function is a hot spot of the compiled program.  The
       function is optimized more aggressively and on many targets it is
       placed into a special subsection of the text section so all hot
       functions appear close together, improving locality.
  
!      When profile feedback is available, via ‘-fprofile-use’, hot
       functions are automatically detected and this attribute is ignored.
  
! ‘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 following attributes are supported o
*** 36268,36274 ****
  
            extern void *memcpy (void *, const void *, size_t);
  
!      allowing the user to call 'memcpy' as a regular function, unaware
       of the actual implementation.  Finally, the indirect function needs
       to be defined in the same translation unit as the resolver
       function:
--- 36277,36283 ----
  
            extern void *memcpy (void *, const void *, size_t);
  
!      allowing the user to call ‘memcpy’ as a regular function, unaware
       of the actual implementation.  Finally, the indirect function needs
       to be defined in the same translation unit as the resolver
       function:
*************** The following attributes are supported o
*** 36276,36291 ****
            void *memcpy (void *, const void *, size_t)
                 __attribute__ ((ifunc ("resolve_memcpy")));
  
!      In C++, the 'ifunc' attribute takes a string that is the mangled
       name of the resolver function.  A C++ resolver for a non-static
!      member function of class 'C' should be declared to return a pointer
!      to a non-member function taking pointer to 'C' as the first
       argument, followed by the same arguments as of the implementation
       function.  G++ checks the signatures of the two functions and
!      issues a '-Wattribute-alias' warning for mismatches.  To suppress a
       warning for the necessary cast from a pointer to the implementation
       member function to the type of the corresponding non-member
!      function use the '-Wno-pmf-conversions' option.  For example:
  
            class S
            {
--- 36285,36300 ----
            void *memcpy (void *, const void *, size_t)
                 __attribute__ ((ifunc ("resolve_memcpy")));
  
!      In C++, the ‘ifunc’ attribute takes a string that is the mangled
       name of the resolver function.  A C++ resolver for a non-static
!      member function of class ‘C’ should be declared to return a pointer
!      to a non-member function taking pointer to ‘C’ as the first
       argument, followed by the same arguments as of the implementation
       function.  G++ checks the signatures of the two functions and
!      issues a ‘-Wattribute-alias’ warning for mismatches.  To suppress a
       warning for the necessary cast from a pointer to the implementation
       member function to the type of the corresponding non-member
!      function use the ‘-Wno-pmf-conversions’ option.  For example:
  
            class S
            {
*************** The following attributes are supported o
*** 36319,36338 ****
       higher and GNU C Library version 2.11.1 are required to use this
       feature.
  
! 'interrupt'
! 'interrupt_handler'
       Many GCC back ends support attributes to indicate that a function
       is an interrupt handler, which tells the compiler to generate
       function entry and exit sequences that differ from those from
       regular functions.  The exact syntax and behavior are
       target-specific; refer to the following subsections for details.
  
! 'leaf'
       Calls to external functions with this attribute must return to the
       current compilation unit only by return or by exception handling.
       In particular, a leaf function is not allowed to invoke callback
       functions passed to it from the current compilation unit, directly
!      call functions exported by the unit, or 'longjmp' into the unit.
       Leaf functions 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.
--- 36328,36347 ----
       higher and GNU C Library version 2.11.1 are required to use this
       feature.
  
! ‘interrupt’
! ‘interrupt_handler’
       Many GCC back ends support attributes to indicate that a function
       is an interrupt handler, which tells the compiler to generate
       function entry and exit sequences that differ from those from
       regular functions.  The exact syntax and behavior are
       target-specific; refer to the following subsections for details.
  
! ‘leaf’
       Calls to external functions with this attribute must return to the
       current compilation unit only by return or by exception handling.
       In particular, a leaf function is not allowed to invoke callback
       functions passed to it from the current compilation unit, directly
!      call functions exported by the unit, or ‘longjmp’ into the unit.
       Leaf functions 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 following attributes are supported o
*** 36340,36347 ****
       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 cannot 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 indirectly run a signal handler
       defined in the current compilation unit that uses static variables.
--- 36349,36356 ----
       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 cannot 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 indirectly run a signal handler
       defined in the current compilation unit that uses static variables.
*************** The following attributes are supported o
*** 36350,36357 ****
       implementation function is defined in the current compilation unit
       and uses static variables.  There is no standard-compliant way to
       write such a signal handler, resolver function, or implementation
!      function, and the best that you can do is to remove the 'leaf'
!      attribute or mark all such static variables 'volatile'.  Lastly,
       for ELF-based systems that support symbol interposition, care
       should be taken that functions defined in the current compilation
       unit do not unexpectedly interpose other symbols based on the
--- 36359,36366 ----
       implementation function is defined in the current compilation unit
       and uses static variables.  There is no standard-compliant way to
       write such a signal handler, resolver function, or implementation
!      function, and the best that you can do is to remove the ‘leaf’
!      attribute or mark all such static variables ‘volatile’.  Lastly,
       for ELF-based systems that support symbol interposition, care
       should be taken that functions defined in the current compilation
       unit do not unexpectedly interpose other symbols based on the
*************** The following attributes are supported o
*** 36364,36373 ****
       optimization.  For this reason the attribute is not allowed on
       types to annotate indirect calls.
  
! 'malloc'
! 'malloc (DEALLOCATOR)'
! 'malloc (DEALLOCATOR, PTR-INDEX)'
!      Attribute 'malloc' indicates that a function is 'malloc'-like,
       i.e., that the pointer P returned by the function cannot alias any
       other pointer valid when the function returns, and moreover no
       pointers to valid objects occur in any storage addressed by P.  In
--- 36373,36382 ----
       optimization.  For this reason the attribute is not allowed on
       types to annotate indirect calls.
  
! ‘malloc’
! ‘malloc (DEALLOCATOR)’
! ‘malloc (DEALLOCATOR, PTR-INDEX)’
!      Attribute ‘malloc’ indicates that a function is ‘malloc’-like,
       i.e., that the pointer P returned by the function cannot alias any
       other pointer valid when the function returns, and moreover no
       pointers to valid objects occur in any storage addressed by P.  In
*************** The following attributes are supported o
*** 36375,36390 ****
       non-null in most cases.
  
       Independently, the form of the attribute with one or two arguments
!      associates 'deallocator' as a suitable deallocation function for
!      pointers returned from the 'malloc'-like function.  PTR-INDEX
       denotes the positional argument to which when the pointer is passed
!      in calls to 'deallocator' has the effect of deallocating it.
  
       Using the attribute with no arguments is designed to improve
       optimization by relying on the aliasing property it implies.
!      Functions like 'malloc' and 'calloc' have this property because
       they return a pointer to uninitialized or zeroed-out, newly
!      obtained storage.  However, functions like 'realloc' do not have
       this property, as they may return pointers to storage containing
       pointers to existing objects.  Additionally, since all such
       functions are assumed to return null only infrequently, callers can
--- 36384,36399 ----
       non-null in most cases.
  
       Independently, the form of the attribute with one or two arguments
!      associates ‘deallocator’ as a suitable deallocation function for
!      pointers returned from the ‘malloc’-like function.  PTR-INDEX
       denotes the positional argument to which when the pointer is passed
!      in calls to ‘deallocator’ has the effect of deallocating it.
  
       Using the attribute with no arguments is designed to improve
       optimization by relying on the aliasing property it implies.
!      Functions like ‘malloc’ and ‘calloc’ have this property because
       they return a pointer to uninitialized or zeroed-out, newly
!      obtained storage.  However, functions like ‘realloc’ do not have
       this property, as they may return pointers to storage containing
       pointers to existing objects.  Additionally, since all such
       functions are assumed to return null only infrequently, callers can
*************** The following attributes are supported o
*** 36392,36415 ****
  
       Associating a function with a DEALLOCATOR helps detect calls to
       mismatched allocation and deallocation functions and diagnose them
!      under the control of options such as '-Wmismatched-dealloc'.  It
       also makes it possible to diagnose attempts to deallocate objects
!      that were not allocated dynamically, by '-Wfree-nonheap-object'.
       To indicate that an allocation function both satisifies the
       nonaliasing property and has a deallocator associated with it, both
       the plain form of the attribute and the one with the DEALLOCATOR
       argument must be used.  The same function can be both an allocator
       and a deallocator.  Since inlining one of the associated functions
       but not the other could result in apparent mismatches, this form of
!      attribute 'malloc' is not accepted on inline functions.  For the
       same reason, using the attribute prevents both the allocation and
       deallocation functions from being expanded inline.
  
       For example, besides stating that the functions return pointers
       that do not alias any others, the following declarations make
!      'fclose' a suitable deallocator for pointers returned from all
!      functions except 'popen', and 'pclose' as the only suitable
!      deallocator for pointers returned from 'popen'.  The deallocator
       functions must be declared before they can be referenced in the
       attribute.
  
--- 36401,36424 ----
  
       Associating a function with a DEALLOCATOR helps detect calls to
       mismatched allocation and deallocation functions and diagnose them
!      under the control of options such as ‘-Wmismatched-dealloc’.  It
       also makes it possible to diagnose attempts to deallocate objects
!      that were not allocated dynamically, by ‘-Wfree-nonheap-object’.
       To indicate that an allocation function both satisifies the
       nonaliasing property and has a deallocator associated with it, both
       the plain form of the attribute and the one with the DEALLOCATOR
       argument must be used.  The same function can be both an allocator
       and a deallocator.  Since inlining one of the associated functions
       but not the other could result in apparent mismatches, this form of
!      attribute ‘malloc’ is not accepted on inline functions.  For the
       same reason, using the attribute prevents both the allocation and
       deallocation functions from being expanded inline.
  
       For example, besides stating that the functions return pointers
       that do not alias any others, the following declarations make
!      ‘fclose’ a suitable deallocator for pointers returned from all
!      functions except ‘popen’, and ‘pclose’ as the only suitable
!      deallocator for pointers returned from ‘popen’.  The deallocator
       functions must be declared before they can be referenced in the
       attribute.
  
*************** The following attributes are supported o
*** 36427,36550 ****
            __attribute__ ((malloc, malloc (fclose, 1)))
              FILE* tmpfile (void);
  
!      The warnings guarded by '-fanalyzer' respect allocation and
!      deallocation pairs marked with the 'malloc'.  In particular:
  
!         * The analyzer emits a '-Wanalyzer-mismatching-deallocation'
            diagnostic if there is an execution path in which the result
            of an allocation call is passed to a different deallocator.
  
!         * The analyzer emits a '-Wanalyzer-double-free' diagnostic if
            there is an execution path in which a value is passed more
            than once to a deallocation call.
  
!         * The analyzer considers the possibility that an allocation
            function could fail and return null.  If there are execution
            paths in which an unchecked result of an allocation call is
            dereferenced or passed to a function requiring a non-null
!           argument, it emits '-Wanalyzer-possible-null-dereference' and
!           '-Wanalyzer-possible-null-argument' diagnostics.  If the
!           allocator always returns non-null, use '__attribute__
!           ((returns_nonnull))' to suppress these warnings.  For example:
                 char *xstrdup (const char *)
                   __attribute__((malloc (free), returns_nonnull));
  
!         * The analyzer emits a '-Wanalyzer-use-after-free' diagnostic if
            there is an execution path in which the memory passed by
            pointer to a deallocation call is used after the deallocation.
  
!         * The analyzer emits a '-Wanalyzer-malloc-leak' diagnostic if
            there is an execution path in which the result of an
            allocation call is leaked (without being passed to the
            deallocation function).
  
!         * The analyzer emits a '-Wanalyzer-free-of-non-heap' diagnostic
            if a deallocation function is used on a global or on-stack
            variable.
  
       The analyzer assumes that deallocators can gracefully handle the
       null pointer.  If this is not the case, the deallocator can be
!      marked with '__attribute__((nonnull))' so that '-fanalyzer' can
!      emit a '-Wanalyzer-possible-null-argument' diagnostic for code
       paths in which the deallocator is called with null.
  
! 'no_icf'
       This function attribute prevents a functions from being merged with
       another semantically equivalent function.
  
! 'no_instrument_function'
!      If any of '-finstrument-functions', '-p', or '-pg' are given,
       profiling function calls are generated at entry and exit of most
       user-compiled functions.  Functions with this attribute are not so
       instrumented.
  
! 'no_profile_instrument_function'
!      The 'no_profile_instrument_function' attribute on functions is used
       to inform the compiler that it should not process any profile
       feedback based optimization code instrumentation.
  
! 'no_reorder'
!      Do not reorder functions or variables marked 'no_reorder' against
       each other or top level assembler statements the executable.  The
       actual order in the program will depend on the linker command line.
       Static variables marked like this are also not removed.  This has a
!      similar effect as the '-fno-toplevel-reorder' option, but only
       applies to the marked symbols.
  
! 'no_sanitize ("SANITIZE_OPTION")'
!      The 'no_sanitize' attribute on functions is used to inform the
       compiler that it should not do sanitization of any option mentioned
       in SANITIZE_OPTION.  A list of values acceptable by the
!      '-fsanitize' option can be provided.
  
            void __attribute__ ((no_sanitize ("alignment", "object-size")))
            f () { /* Do something. */; }
            void __attribute__ ((no_sanitize ("alignment,object-size")))
            g () { /* Do something. */; }
  
! 'no_sanitize_address'
! 'no_address_safety_analysis'
!      The 'no_sanitize_address' attribute on functions is used to inform
       the compiler that it should not instrument memory accesses in the
!      function when compiling with the '-fsanitize=address' option.  The
!      'no_address_safety_analysis' is a deprecated alias of the
!      'no_sanitize_address' attribute, new code should use
!      'no_sanitize_address'.
  
! 'no_sanitize_thread'
!      The 'no_sanitize_thread' attribute on functions is used to inform
       the compiler that it should not instrument memory accesses in the
!      function when compiling with the '-fsanitize=thread' option.
  
! 'no_sanitize_undefined'
!      The 'no_sanitize_undefined' attribute on functions is used to
       inform the compiler that it should not check for undefined behavior
!      in the function when compiling with the '-fsanitize=undefined'
       option.
  
! 'no_sanitize_coverage'
!      The 'no_sanitize_coverage' attribute on functions is used to inform
       the compiler that it should not do coverage-guided fuzzing code
!      instrumentation ('-fsanitize-coverage').
  
! 'no_split_stack'
!      If '-fsplit-stack' is given, functions have a small prologue which
       decides whether to split the stack.  Functions with the
!      'no_split_stack' attribute do not have that prologue, and thus may
       run with only a small amount of stack space available.
  
! 'no_stack_limit'
!      This attribute locally overrides the '-fstack-limit-register' and
!      '-fstack-limit-symbol' command-line options; it has the effect of
       disabling stack limit checking in the function it applies to.
  
! 'noclone'
       This function attribute prevents a function from being considered
       for cloning--a mechanism that produces specialized copies of
       functions and which is (currently) performed by interprocedural
       constant propagation.
  
! 'noinline'
       This function attribute prevents a function from being considered
       for inlining.  If the function does not have side effects, there
       are optimizations other than inlining that cause function calls to
--- 36436,36559 ----
            __attribute__ ((malloc, malloc (fclose, 1)))
              FILE* tmpfile (void);
  
!      The warnings guarded by ‘-fanalyzer’ respect allocation and
!      deallocation pairs marked with the ‘malloc’.  In particular:
  
!         • The analyzer emits a ‘-Wanalyzer-mismatching-deallocation’
            diagnostic if there is an execution path in which the result
            of an allocation call is passed to a different deallocator.
  
!         • The analyzer emits a ‘-Wanalyzer-double-free’ diagnostic if
            there is an execution path in which a value is passed more
            than once to a deallocation call.
  
!         • The analyzer considers the possibility that an allocation
            function could fail and return null.  If there are execution
            paths in which an unchecked result of an allocation call is
            dereferenced or passed to a function requiring a non-null
!           argument, it emits ‘-Wanalyzer-possible-null-dereference’ and
!           ‘-Wanalyzer-possible-null-argument’ diagnostics.  If the
!           allocator always returns non-null, use ‘__attribute__
!           ((returns_nonnull))’ to suppress these warnings.  For example:
                 char *xstrdup (const char *)
                   __attribute__((malloc (free), returns_nonnull));
  
!         • The analyzer emits a ‘-Wanalyzer-use-after-free’ diagnostic if
            there is an execution path in which the memory passed by
            pointer to a deallocation call is used after the deallocation.
  
!         • The analyzer emits a ‘-Wanalyzer-malloc-leak’ diagnostic if
            there is an execution path in which the result of an
            allocation call is leaked (without being passed to the
            deallocation function).
  
!         • The analyzer emits a ‘-Wanalyzer-free-of-non-heap’ diagnostic
            if a deallocation function is used on a global or on-stack
            variable.
  
       The analyzer assumes that deallocators can gracefully handle the
       null pointer.  If this is not the case, the deallocator can be
!      marked with ‘__attribute__((nonnull))’ so that ‘-fanalyzer’ can
!      emit a ‘-Wanalyzer-possible-null-argument’ diagnostic for code
       paths in which the deallocator is called with null.
  
! ‘no_icf’
       This function attribute prevents a functions from being merged with
       another semantically equivalent function.
  
! ‘no_instrument_function’
!      If any of ‘-finstrument-functions’, ‘-p’, or ‘-pg’ are given,
       profiling function calls are generated at entry and exit of most
       user-compiled functions.  Functions with this attribute are not so
       instrumented.
  
! ‘no_profile_instrument_function’
!      The ‘no_profile_instrument_function’ attribute on functions is used
       to inform the compiler that it should not process any profile
       feedback based optimization code instrumentation.
  
! ‘no_reorder’
!      Do not reorder functions or variables marked ‘no_reorder’ against
       each other or top level assembler statements the executable.  The
       actual order in the program will depend on the linker command line.
       Static variables marked like this are also not removed.  This has a
!      similar effect as the ‘-fno-toplevel-reorder’ option, but only
       applies to the marked symbols.
  
! ‘no_sanitize ("SANITIZE_OPTION")’
!      The ‘no_sanitize’ attribute on functions is used to inform the
       compiler that it should not do sanitization of any option mentioned
       in SANITIZE_OPTION.  A list of values acceptable by the
!      ‘-fsanitize’ option can be provided.
  
            void __attribute__ ((no_sanitize ("alignment", "object-size")))
            f () { /* Do something. */; }
            void __attribute__ ((no_sanitize ("alignment,object-size")))
            g () { /* Do something. */; }
  
! ‘no_sanitize_address’
! ‘no_address_safety_analysis’
!      The ‘no_sanitize_address’ attribute on functions is used to inform
       the compiler that it should not instrument memory accesses in the
!      function when compiling with the ‘-fsanitize=address’ option.  The
!      ‘no_address_safety_analysis’ is a deprecated alias of the
!      ‘no_sanitize_address’ attribute, new code should use
!      ‘no_sanitize_address’.
  
! ‘no_sanitize_thread’
!      The ‘no_sanitize_thread’ attribute on functions is used to inform
       the compiler that it should not instrument memory accesses in the
!      function when compiling with the ‘-fsanitize=thread’ option.
  
! ‘no_sanitize_undefined’
!      The ‘no_sanitize_undefined’ attribute on functions is used to
       inform the compiler that it should not check for undefined behavior
!      in the function when compiling with the ‘-fsanitize=undefined’
       option.
  
! ‘no_sanitize_coverage’
!      The ‘no_sanitize_coverage’ attribute on functions is used to inform
       the compiler that it should not do coverage-guided fuzzing code
!      instrumentation (‘-fsanitize-coverage’).
  
! ‘no_split_stack’
!      If ‘-fsplit-stack’ is given, functions have a small prologue which
       decides whether to split the stack.  Functions with the
!      ‘no_split_stack’ attribute do not have that prologue, and thus may
       run with only a small amount of stack space available.
  
! ‘no_stack_limit’
!      This attribute locally overrides the ‘-fstack-limit-register’ and
!      ‘-fstack-limit-symbol’ command-line options; it has the effect of
       disabling stack limit checking in the function it applies to.
  
! ‘noclone’
       This function attribute prevents a function from being considered
       for cloning--a mechanism that produces specialized copies of
       functions and which is (currently) performed by interprocedural
       constant propagation.
  
! ‘noinline’
       This function attribute prevents a function from being considered
       for inlining.  If the function does not have side effects, there
       are optimizations other than inlining that cause function calls to
*************** The following attributes are supported o
*** 36555,36566 ****
       (*note Extended Asm::) in the called function, to serve as a
       special side effect.
  
! 'noipa'
       Disable interprocedural optimizations between the function with
       this attribute and its callers, as if the body of the function is
       not available when optimizing callers and the callers are
       unavailable when optimizing the body.  This attribute implies
!      'noinline', 'noclone' and 'no_icf' attributes.  However, this
       attribute is not equivalent to a combination of other attributes,
       because its purpose is to suppress existing and future
       optimizations employing interprocedural analysis, including those
--- 36564,36575 ----
       (*note Extended Asm::) in the called function, to serve as a
       special side effect.
  
! ‘noipa’
       Disable interprocedural optimizations between the function with
       this attribute and its callers, as if the body of the function is
       not available when optimizing callers and the callers are
       unavailable when optimizing the body.  This attribute implies
!      ‘noinline’, ‘noclone’ and ‘no_icf’ attributes.  However, this
       attribute is not equivalent to a combination of other attributes,
       because its purpose is to suppress existing and future
       optimizations employing interprocedural analysis, including those
*************** The following attributes are supported o
*** 36568,36576 ****
       individually.  This attribute is supported mainly for the purpose
       of testing the compiler.
  
! 'nonnull'
! 'nonnull (ARG-INDEX, ...)'
!      The 'nonnull' attribute may be applied to a function that takes at
       least one argument of a pointer type.  It indicates that the
       referenced arguments must be non-null pointers.  For instance, the
       declaration:
--- 36577,36585 ----
       individually.  This attribute is supported mainly for the purpose
       of testing the compiler.
  
! ‘nonnull’
! ‘nonnull (ARG-INDEX, ...)’
!      The ‘nonnull’ attribute may be applied to a function that takes at
       least one argument of a pointer type.  It indicates that the
       referenced arguments must be non-null pointers.  For instance, the
       declaration:
*************** The following attributes are supported o
*** 36579,36614 ****
            my_memcpy (void *dest, const void *src, size_t len)
                    __attribute__((nonnull (1, 2)));
  
!      informs the compiler that, in calls to 'my_memcpy', arguments DEST
       and SRC must be non-null.
  
       The attribute has an effect both on functions calls and function
       definitions.
  
       For function calls:
!         * 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.  *Note Warning Options::.
!         * The '-fisolate-erroneous-paths-attribute' option can be
            specified to have GCC transform calls with null arguments to
            non-null functions into traps.  *Note Optimize Options::.
!         * The compiler may also perform optimizations based on the
            knowledge that certain function arguments cannot be null.
            These optimizations can be disabled by the
!           '-fno-delete-null-pointer-checks' option.  *Note Optimize
            Options::.
  
       For function definitions:
!         * If the compiler determines that a function parameter that is
            marked with nonnull is compared with null, and
!           '-Wnonnull-compare' option is enabled, a warning is issued.
            *Note Warning Options::.
!         * The compiler may also perform optimizations based on the
!           knowledge that 'nonnull' parameters cannot be null.  This can
            currently not be disabled other than by removing the nonnull
            attribute.
  
!      If no ARG-INDEX 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:
  
--- 36588,36623 ----
            my_memcpy (void *dest, const void *src, size_t len)
                    __attribute__((nonnull (1, 2)));
  
!      informs the compiler that, in calls to ‘my_memcpy’, arguments DEST
       and SRC must be non-null.
  
       The attribute has an effect both on functions calls and function
       definitions.
  
       For function calls:
!         • 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.  *Note Warning Options::.
!         • The ‘-fisolate-erroneous-paths-attribute’ option can be
            specified to have GCC transform calls with null arguments to
            non-null functions into traps.  *Note Optimize Options::.
!         • The compiler may also perform optimizations based on the
            knowledge that certain function arguments cannot be null.
            These optimizations can be disabled by the
!           ‘-fno-delete-null-pointer-checks’ option.  *Note Optimize
            Options::.
  
       For function definitions:
!         • If the compiler determines that a function parameter that is
            marked with nonnull is compared with null, and
!           ‘-Wnonnull-compare’ option is enabled, a warning is issued.
            *Note Warning Options::.
!         • The compiler may also perform optimizations based on the
!           knowledge that ‘nonnull’ parameters cannot be null.  This can
            currently not be disabled other than by removing the nonnull
            attribute.
  
!      If no ARG-INDEX 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:
  
*************** The following attributes are supported o
*** 36616,36623 ****
            my_memcpy (void *dest, const void *src, size_t len)
                    __attribute__((nonnull));
  
! 'noplt'
!      The 'noplt' attribute is the counterpart to option '-fno-plt'.
       Calls to functions marked with this attribute in
       position-independent code do not use the PLT.
  
--- 36625,36632 ----
            my_memcpy (void *dest, const void *src, size_t len)
                    __attribute__((nonnull));
  
! ‘noplt’
!      The ‘noplt’ attribute is the counterpart to option ‘-fno-plt’.
       Calls to functions marked with this attribute in
       position-independent code do not use the PLT.
  
*************** The following attributes are supported o
*** 36632,36650 ****
              /* ... */
            }
  
!      The 'noplt' attribute on function 'foo' tells the compiler to
!      assume that the function 'foo' is externally defined and that the
!      call to 'foo' must avoid the PLT in position-independent code.
  
       In position-dependent code, a few targets also convert calls to
       functions that are marked to not use the PLT to use the GOT
       instead.
  
! '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));
  
--- 36641,36659 ----
              /* ... */
            }
  
!      The ‘noplt’ attribute on function ‘foo’ tells the compiler to
!      assume that the function ‘foo’ is externally defined and that the
!      call to ‘foo’ must avoid the PLT in position-independent code.
  
       In position-dependent code, a few targets also convert calls to
       functions that are marked to not use the PLT to use the GOT
       instead.
  
! ‘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));
  
*************** The following attributes are supported o
*** 36655,36689 ****
              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'.
  
       In order to preserve backtraces, GCC will never turn calls to
!      'noreturn' functions into tail calls.
  
       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'.
  
! '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.
  
! 'optimize (LEVEL, ...)'
! 'optimize (STRING, ...)'
!      The 'optimize' attribute is used to specify that a function is to
       be compiled with different optimization options than specified on
       the command line.  The optimize attribute arguments of a function
       behave as if appended to the command-line.
--- 36664,36698 ----
              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’.
  
       In order to preserve backtraces, GCC will never turn calls to
!      ‘noreturn’ functions into tail calls.
  
       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’.
  
! ‘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.
  
! ‘optimize (LEVEL, ...)’
! ‘optimize (STRING, ...)’
!      The ‘optimize’ attribute is used to specify that a function is to
       be compiled with different optimization options than specified on
       the command line.  The optimize attribute arguments of a function
       behave as if appended to the command-line.
*************** The following attributes are supported o
*** 36691,36746 ****
       Valid arguments are constant non-negative integers and strings.
       Each numeric argument specifies an optimization LEVEL.  Each STRING
       argument consists of one or more comma-separated substrings.  Each
!      substring that begins with the letter 'O' refers to an optimization
!      option such as '-O0' or '-Os'.  Other substrings are taken as
!      suffixes to the '-f' prefix jointly forming the name of an
       optimization option.  *Note Optimize Options::.
  
!      '#pragma GCC optimize' can be used to set optimization options for
       more than one function.  *Note Function Specific Option Pragmas::,
       for details about the pragma.
  
       Providing multiple strings as arguments separated by commas to
       specify multiple options is equivalent to separating the option
!      suffixes with a comma (',') within a single string.  Spaces are not
       permitted within the strings.
  
       Not every optimization option that starts with the -F prefix
       specified by the attribute necessarily has an effect on the
!      function.  The 'optimize' attribute should be used for debugging
       purposes only.  It is not suitable in production code.
  
! 'patchable_function_entry'
       In case the target's text segment can be made writable at run time
       by any means, padding the function entry with a number of NOPs can
       be used to provide a universal tool for instrumentation.
  
!      The 'patchable_function_entry' function attribute can be used to
       change the number of NOPs to any desired value.  The two-value
       syntax is the same as for the command-line switch
!      '-fpatchable-function-entry=N,M', generating N NOPs, with the
       function entry point before the Mth NOP instruction.  M defaults to
       0 if omitted e.g. function entry point is before the first NOP.
  
       If patchable function entries are enabled globally using the
!      command-line option '-fpatchable-function-entry=N,M', then you must
       disable instrumentation on all functions that are part of the
       instrumentation framework with the attribute
!      'patchable_function_entry (0)' to prevent recursion.
  
! 'pure'
  
       Calls to functions that have no observable effects on the state of
       the program other than to return a value may lend themselves to
       optimizations such as common subexpression elimination.  Declaring
!      such functions with the 'pure' attribute allows GCC to avoid
       emitting some calls in repeated invocations of the function with
       the same argument values.
  
!      The 'pure' attribute prohibits a function from modifying the state
       of the program that is observable by means other than inspecting
       the function's return value.  However, functions declared with the
!      'pure' attribute can safely read any non-volatile objects, and
       modify the value of objects in a way that does not affect their
       return value or the observable state of the program.
  
--- 36700,36755 ----
       Valid arguments are constant non-negative integers and strings.
       Each numeric argument specifies an optimization LEVEL.  Each STRING
       argument consists of one or more comma-separated substrings.  Each
!      substring that begins with the letter ‘O’ refers to an optimization
!      option such as ‘-O0’ or ‘-Os’.  Other substrings are taken as
!      suffixes to the ‘-f’ prefix jointly forming the name of an
       optimization option.  *Note Optimize Options::.
  
!      ‘#pragma GCC optimize’ can be used to set optimization options for
       more than one function.  *Note Function Specific Option Pragmas::,
       for details about the pragma.
  
       Providing multiple strings as arguments separated by commas to
       specify multiple options is equivalent to separating the option
!      suffixes with a comma (‘,’) within a single string.  Spaces are not
       permitted within the strings.
  
       Not every optimization option that starts with the -F prefix
       specified by the attribute necessarily has an effect on the
!      function.  The ‘optimize’ attribute should be used for debugging
       purposes only.  It is not suitable in production code.
  
! ‘patchable_function_entry’
       In case the target's text segment can be made writable at run time
       by any means, padding the function entry with a number of NOPs can
       be used to provide a universal tool for instrumentation.
  
!      The ‘patchable_function_entry’ function attribute can be used to
       change the number of NOPs to any desired value.  The two-value
       syntax is the same as for the command-line switch
!      ‘-fpatchable-function-entry=N,M’, generating N NOPs, with the
       function entry point before the Mth NOP instruction.  M defaults to
       0 if omitted e.g. function entry point is before the first NOP.
  
       If patchable function entries are enabled globally using the
!      command-line option ‘-fpatchable-function-entry=N,M’, then you must
       disable instrumentation on all functions that are part of the
       instrumentation framework with the attribute
!      ‘patchable_function_entry (0)’ to prevent recursion.
  
! ‘pure’
  
       Calls to functions that have no observable effects on the state of
       the program other than to return a value may lend themselves to
       optimizations such as common subexpression elimination.  Declaring
!      such functions with the ‘pure’ attribute allows GCC to avoid
       emitting some calls in repeated invocations of the function with
       the same argument values.
  
!      The ‘pure’ attribute prohibits a function from modifying the state
       of the program that is observable by means other than inspecting
       the function's return value.  However, functions declared with the
!      ‘pure’ attribute can safely read any non-volatile objects, and
       modify the value of objects in a way that does not affect their
       return value or the observable state of the program.
  
*************** The following attributes are supported o
*** 36748,36782 ****
  
            int hash (char *) __attribute__ ((pure));
  
!      tells GCC that subsequent calls to the function 'hash' with the
       same string can be replaced by the result of the first call
!      provided the state of the program observable by 'hash', including
       the contents of the array itself, does not change in between.  Even
!      though 'hash' takes a non-const pointer argument it must not modify
       the array it points to, or any other object whose value the rest of
       the program may depend on.  However, the caller may safely change
       the contents of the array between successive calls to the function
       (doing so disables the optimization).  The restriction also applies
!      to member objects referenced by the 'this' pointer in C++
       non-static member functions.
  
!      Some 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 consecutive calls (such as the standard C 'feof'
       function in a multithreading environment).
  
!      The 'pure' attribute imposes similar but looser restrictions on a
!      function's definition than the 'const' attribute: 'pure' allows the
       function to read any non-volatile memory, even if it changes in
       between successive invocations of the function.  Declaring the same
!      function with both the 'pure' and the 'const' attribute is
       diagnosed.  Because a pure function cannot have any observable side
       effects it does not make sense for such a function to return
!      'void'.  Declaring such a function is diagnosed.
  
! 'returns_nonnull'
!      The 'returns_nonnull' attribute specifies that the function return
       value should be a non-null pointer.  For instance, the declaration:
  
            extern void *
--- 36757,36791 ----
  
            int hash (char *) __attribute__ ((pure));
  
!      tells GCC that subsequent calls to the function ‘hash’ with the
       same string can be replaced by the result of the first call
!      provided the state of the program observable by ‘hash’, including
       the contents of the array itself, does not change in between.  Even
!      though ‘hash’ takes a non-const pointer argument it must not modify
       the array it points to, or any other object whose value the rest of
       the program may depend on.  However, the caller may safely change
       the contents of the array between successive calls to the function
       (doing so disables the optimization).  The restriction also applies
!      to member objects referenced by the ‘this’ pointer in C++
       non-static member functions.
  
!      Some 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 consecutive calls (such as the standard C ‘feof’
       function in a multithreading environment).
  
!      The ‘pure’ attribute imposes similar but looser restrictions on a
!      function's definition than the ‘const’ attribute: ‘pure’ allows the
       function to read any non-volatile memory, even if it changes in
       between successive invocations of the function.  Declaring the same
!      function with both the ‘pure’ and the ‘const’ attribute is
       diagnosed.  Because a pure function cannot have any observable side
       effects it does not make sense for such a function to return
!      ‘void’.  Declaring such a function is diagnosed.
  
! ‘returns_nonnull’
!      The ‘returns_nonnull’ attribute specifies that the function return
       value should be a non-null pointer.  For instance, the declaration:
  
            extern void *
*************** The following attributes are supported o
*** 36785,36819 ****
       lets the compiler optimize callers based on the knowledge that the
       return value will never be null.
  
! 'returns_twice'
!      The 'returns_twice' attribute tells the compiler that a function
       may return more than one time.  The compiler ensures that all
       registers are dead before calling such a function and emits a
       warning about the variables that may be clobbered after the second
!      return from the function.  Examples of such functions are 'setjmp'
!      and 'vfork'.  The 'longjmp'-like counterpart of such function, if
!      any, might need to be marked with the 'noreturn' attribute.
  
! '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'
! 'sentinel (POSITION)'
       This function attribute indicates that an argument in a call to the
!      function is expected to be an explicit 'NULL'.  The attribute is
       only valid on variadic functions.  By default, the sentinel is
       expected to be the last argument of the function call.  If the
       optional POSITION argument is specified to the attribute, the
--- 36794,36828 ----
       lets the compiler optimize callers based on the knowledge that the
       return value will never be null.
  
! ‘returns_twice’
!      The ‘returns_twice’ attribute tells the compiler that a function
       may return more than one time.  The compiler ensures that all
       registers are dead before calling such a function and emits a
       warning about the variables that may be clobbered after the second
!      return from the function.  Examples of such functions are ‘setjmp’
!      and ‘vfork’.  The ‘longjmp’-like counterpart of such function, if
!      any, might need to be marked with the ‘noreturn’ attribute.
  
! ‘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’
! ‘sentinel (POSITION)’
       This function attribute indicates that an argument in a call to the
!      function is expected to be an explicit ‘NULL’.  The attribute is
       only valid on variadic functions.  By default, the sentinel is
       expected to be the last argument of the function call.  If the
       optional POSITION argument is specified to the attribute, the
*************** The following attributes are supported o
*** 36825,36844 ****
            __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 object
!      pointer type.  If your system defines the 'NULL' macro with an
       integer type then you need to add an explicit cast.  During
!      installation GCC replaces the system '' header with a
       copy that redefines NULL appropriately.
  
       The warnings for missing or incorrect sentinels are enabled with
!      '-Wformat'.
  
! 'simd'
! 'simd("MASK")'
       This attribute enables creation of one or more function versions
       that can process multiple arguments using SIMD instructions from a
       single invocation.  Specifying this attribute allows compiler to
--- 36834,36853 ----
            __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 object
!      pointer type.  If your system defines the ‘NULL’ macro with an
       integer type then you need to add an explicit cast.  During
!      installation GCC replaces the system ‘’ header with a
       copy that redefines NULL appropriately.
  
       The warnings for missing or incorrect sentinels are enabled with
!      ‘-Wformat’.
  
! ‘simd’
! ‘simd("MASK")’
       This attribute enables creation of one or more function versions
       that can process multiple arguments using SIMD instructions from a
       single invocation.  Specifying this attribute allows compiler to
*************** The following attributes are supported o
*** 36848,36894 ****
       document.  For x86_64 target this document can be found
       here (https://sourceware.org/glibc/wiki/libmvec?action=AttachFile&do=view&target=VectorABI.txt).
  
!      The optional argument MASK may have the value 'notinbranch' or
!      'inbranch', and instructs the compiler to generate non-masked or
       masked clones correspondingly.  By default, all clones are
       generated.
  
!      If the attribute is specified and '#pragma omp declare simd' is
!      present on a declaration and the '-fopenmp' or '-fopenmp-simd'
       switch is specified, then the attribute is ignored.
  
! 'stack_protect'
       This attribute adds stack protection code to the function if flags
!      '-fstack-protector', '-fstack-protector-strong' or
!      '-fstack-protector-explicit' are set.
  
! 'no_stack_protector'
       This attribute prevents stack protection code for the function.
  
! 'target (STRING, ...)'
!      Multiple target back ends implement the 'target' attribute to
       specify that a function is to be compiled with different target
       options than specified on the command line.  The original target
       command-line options are ignored.  One or more strings can be
       provided as arguments.  Each string consists of one or more
!      comma-separated suffixes to the '-m' prefix jointly forming the
       name of a machine-dependent option.  *Note Machine-Dependent
       Options: Submodel Options.
  
!      The 'target' attribute can be used for instance to have a function
       compiled with a different ISA (instruction set architecture) than
!      the default.  '#pragma GCC target' can be used to specify
       target-specific options for more than one function.  *Note Function
       Specific Option Pragmas::, for details about the pragma.
  
       For instance, on an x86, you could declare one function with the
!      'target("sse4.1,arch=core2")' attribute and another with
!      'target("sse4a,arch=amdfam10")'.  This is equivalent to compiling
!      the first function with '-msse4.1' and '-march=core2' options, and
!      the second function with '-msse4a' and '-march=amdfam10' options.
       It is up to you to make sure that a function is only invoked on a
       machine that supports the particular ISA it is compiled for (for
!      example by using 'cpuid' on x86 to determine what feature bits and
       architecture family are used).
  
            int core2_func (void) __attribute__ ((__target__ ("arch=core2")));
--- 36857,36903 ----
       document.  For x86_64 target this document can be found
       here (https://sourceware.org/glibc/wiki/libmvec?action=AttachFile&do=view&target=VectorABI.txt).
  
!      The optional argument MASK may have the value ‘notinbranch’ or
!      ‘inbranch’, and instructs the compiler to generate non-masked or
       masked clones correspondingly.  By default, all clones are
       generated.
  
!      If the attribute is specified and ‘#pragma omp declare simd’ is
!      present on a declaration and the ‘-fopenmp’ or ‘-fopenmp-simd’
       switch is specified, then the attribute is ignored.
  
! ‘stack_protect’
       This attribute adds stack protection code to the function if flags
!      ‘-fstack-protector’, ‘-fstack-protector-strong’ or
!      ‘-fstack-protector-explicit’ are set.
  
! ‘no_stack_protector’
       This attribute prevents stack protection code for the function.
  
! ‘target (STRING, ...)’
!      Multiple target back ends implement the ‘target’ attribute to
       specify that a function is to be compiled with different target
       options than specified on the command line.  The original target
       command-line options are ignored.  One or more strings can be
       provided as arguments.  Each string consists of one or more
!      comma-separated suffixes to the ‘-m’ prefix jointly forming the
       name of a machine-dependent option.  *Note Machine-Dependent
       Options: Submodel Options.
  
!      The ‘target’ attribute can be used for instance to have a function
       compiled with a different ISA (instruction set architecture) than
!      the default.  ‘#pragma GCC target’ can be used to specify
       target-specific options for more than one function.  *Note Function
       Specific Option Pragmas::, for details about the pragma.
  
       For instance, on an x86, you could declare one function with the
!      ‘target("sse4.1,arch=core2")’ attribute and another with
!      ‘target("sse4a,arch=amdfam10")’.  This is equivalent to compiling
!      the first function with ‘-msse4.1’ and ‘-march=core2’ options, and
!      the second function with ‘-msse4a’ and ‘-march=amdfam10’ options.
       It is up to you to make sure that a function is only invoked on a
       machine that supports the particular ISA it is compiled for (for
!      example by using ‘cpuid’ on x86 to determine what feature bits and
       architecture family are used).
  
            int core2_func (void) __attribute__ ((__target__ ("arch=core2")));
*************** The following attributes are supported o
*** 36896,36902 ****
  
       Providing multiple strings as arguments separated by commas to
       specify multiple options is equivalent to separating the option
!      suffixes with a comma (',') within a single string.  Spaces are not
       permitted within the strings.
  
       The options supported are specific to each target; refer to *note
--- 36905,36911 ----
  
       Providing multiple strings as arguments separated by commas to
       specify multiple options is equivalent to separating the option
!      suffixes with a comma (‘,’) within a single string.  Spaces are not
       permitted within the strings.
  
       The options supported are specific to each target; refer to *note
*************** The following attributes are supported o
*** 36905,36914 ****
       Attributes::, *note Nios II Function Attributes::, and *note S/390
       Function Attributes:: for details.
  
! 'symver ("NAME2@NODENAME")'
       On ELF targets this attribute creates a symbol version.  The NAME2
       part of the parameter is the actual name of the symbol by which it
!      will be externally referenced.  The 'nodename' portion should be
       the name of a node specified in the version script supplied to the
       linker when building a shared library.  Versioned symbol must be
       defined and must be exported with default visibility.
--- 36914,36923 ----
       Attributes::, *note Nios II Function Attributes::, and *note S/390
       Function Attributes:: for details.
  
! ‘symver ("NAME2@NODENAME")’
       On ELF targets this attribute creates a symbol version.  The NAME2
       part of the parameter is the actual name of the symbol by which it
!      will be externally referenced.  The ‘nodename’ portion should be
       the name of a node specified in the version script supplied to the
       linker when building a shared library.  Versioned symbol must be
       defined and must be exported with default visibility.
*************** The following attributes are supported o
*** 36918,36924 ****
            {
            }
  
!      Will produce a '.symver foo_v1, foo@VERS_1' directive in the
       assembler output.
  
       One can also define multiple version for a given symbol (starting
--- 36927,36933 ----
            {
            }
  
!      Will produce a ‘.symver foo_v1, foo@VERS_1’ directive in the
       assembler output.
  
       One can also define multiple version for a given symbol (starting
*************** The following attributes are supported o
*** 36929,36936 ****
            {
            }
  
!      This example creates a symbol name 'symver_foo_v1' which will be
!      version 'VERS_2' and 'VERS_3' of 'foo'.
  
       If you have an older release of binutils, then symbol alias needs
       to be used:
--- 36938,36945 ----
            {
            }
  
!      This example creates a symbol name ‘symver_foo_v1’ which will be
!      version ‘VERS_2’ and ‘VERS_3’ of ‘foo’.
  
       If you have an older release of binutils, then symbol alias needs
       to be used:
*************** The following attributes are supported o
*** 36945,36956 ****
            __attribute__ ((alias ("foo_v1")))
            int symver_foo_v1 (void);
  
!      Finally if the parameter is '"NAME2@@NODENAME"' then in addition to
!      creating a symbol version (as if '"NAME2@NODENAME"' was used) the
       version will be also used to resolve NAME2 by the linker.
  
! 'tainted_args'
!      The 'tainted_args' attribute is used to specify that a function is
       called in a way that requires sanitization of its arguments, such
       as a system call in an operating system kernel.  Such a function
       can be considered part of the "attack surface" of the program.  The
--- 36954,36965 ----
            __attribute__ ((alias ("foo_v1")))
            int symver_foo_v1 (void);
  
!      Finally if the parameter is ‘"NAME2@@NODENAME"’ then in addition to
!      creating a symbol version (as if ‘"NAME2@NODENAME"’ was used) the
       version will be also used to resolve NAME2 by the linker.
  
! ‘tainted_args’
!      The ‘tainted_args’ attribute is used to specify that a function is
       called in a way that requires sanitization of its arguments, such
       as a system call in an operating system kernel.  Such a function
       can be considered part of the "attack surface" of the program.  The
*************** The following attributes are supported o
*** 36960,37004 ****
       treated as being called with tainted arguments.
  
       The analyzer will pay particular attention to such functions when
!      both '-fanalyzer' and '-fanalyzer-checker=taint' are supplied,
       potentially issuing warnings guarded by
!      '-Wanalyzer-tainted-allocation-size',
!      '-Wanalyzer-tainted-array-index', '-Wanalyzer-tainted-divisor',
!      '-Wanalyzer-tainted-offset', and '-Wanalyzer-tainted-size'.
  
! 'target_clones (OPTIONS)'
!      The 'target_clones' attribute is used to specify that a function be
       cloned into multiple versions compiled with different target
       options than specified on the command line.  The supported options
!      and restrictions are the same as for 'target' attribute.
  
       For instance, on an x86, you could compile a function with
!      'target_clones("sse4.1,avx")'.  GCC creates two function clones,
!      one compiled with '-msse4.1' and another with '-mavx'.
  
       On a PowerPC, you can compile a function with
!      'target_clones("cpu=power9,default")'.  GCC will create two
!      function clones, one compiled with '-mcpu=power9' and another with
       the default options.  GCC must be configured to use GLIBC 2.23 or
!      newer in order to use the 'target_clones' attribute.
  
!      It also creates a resolver function (see the 'ifunc' attribute
       above) that dynamically selects a clone suitable for current
       architecture.  The resolver is created only if there is a usage of
!      a function with 'target_clones' attribute.
  
!      Note that any subsequent call of a function without 'target_clone'
!      from a 'target_clone' caller will not lead to copying (target
       clone) of the called function.  If you want to enforce such
       behaviour, we recommend declaring the calling function with the
!      'flatten' attribute?
  
! 'unused'
       This attribute, attached to a function, means that the function is
       meant to be possibly unused.  GCC does not produce a warning for
       this function.
  
! 'used'
       This attribute, attached to a function, means that code must be
       emitted for the function even if it appears that the function is
       not referenced.  This is useful, for example, when the function is
--- 36969,37013 ----
       treated as being called with tainted arguments.
  
       The analyzer will pay particular attention to such functions when
!      both ‘-fanalyzer’ and ‘-fanalyzer-checker=taint’ are supplied,
       potentially issuing warnings guarded by
!      ‘-Wanalyzer-tainted-allocation-size’,
!      ‘-Wanalyzer-tainted-array-index’, ‘-Wanalyzer-tainted-divisor’,
!      ‘-Wanalyzer-tainted-offset’, and ‘-Wanalyzer-tainted-size’.
  
! ‘target_clones (OPTIONS)’
!      The ‘target_clones’ attribute is used to specify that a function be
       cloned into multiple versions compiled with different target
       options than specified on the command line.  The supported options
!      and restrictions are the same as for ‘target’ attribute.
  
       For instance, on an x86, you could compile a function with
!      ‘target_clones("sse4.1,avx")’.  GCC creates two function clones,
!      one compiled with ‘-msse4.1’ and another with ‘-mavx’.
  
       On a PowerPC, you can compile a function with
!      ‘target_clones("cpu=power9,default")’.  GCC will create two
!      function clones, one compiled with ‘-mcpu=power9’ and another with
       the default options.  GCC must be configured to use GLIBC 2.23 or
!      newer in order to use the ‘target_clones’ attribute.
  
!      It also creates a resolver function (see the ‘ifunc’ attribute
       above) that dynamically selects a clone suitable for current
       architecture.  The resolver is created only if there is a usage of
!      a function with ‘target_clones’ attribute.
  
!      Note that any subsequent call of a function without ‘target_clone’
!      from a ‘target_clone’ caller will not lead to copying (target
       clone) of the called function.  If you want to enforce such
       behaviour, we recommend declaring the calling function with the
!      ‘flatten’ attribute?
  
! ‘unused’
       This attribute, attached to a function, means that the function is
       meant to be possibly unused.  GCC does not produce a warning for
       this function.
  
! ‘used’
       This attribute, attached to a function, means that code must be
       emitted for the function even if it appears that the function is
       not referenced.  This is useful, for example, when the function is
*************** The following attributes are supported o
*** 37008,37025 ****
       attribute also means that the function is instantiated if the class
       itself is instantiated.
  
! 'retain'
       For ELF targets that support the GNU or FreeBSD OSABIs, this
       attribute will save the function from linker garbage collection.
       To support this behavior, functions that have not been placed in
!      specific sections (e.g.  by the 'section' attribute, or the
!      '-ffunction-sections' option), will be placed in new, unique
       sections.
  
       This additional functionality requires Binutils version 2.36 or
       later.
  
! 'visibility ("VISIBILITY_TYPE")'
       This attribute affects the linkage of the declaration to which it
       is attached.  It can be applied to variables (*note Common Variable
       Attributes::) and types (*note Common Type Attributes::) as well as
--- 37017,37034 ----
       attribute also means that the function is instantiated if the class
       itself is instantiated.
  
! ‘retain’
       For ELF targets that support the GNU or FreeBSD OSABIs, this
       attribute will save the function from linker garbage collection.
       To support this behavior, functions that have not been placed in
!      specific sections (e.g.  by the ‘section’ attribute, or the
!      ‘-ffunction-sections’ option), will be placed in new, unique
       sections.
  
       This additional functionality requires Binutils version 2.36 or
       later.
  
! ‘visibility ("VISIBILITY_TYPE")’
       This attribute affects the linkage of the declaration to which it
       is attached.  It can be applied to variables (*note Common Variable
       Attributes::) and types (*note Common Type Attributes::) as well as
*************** The following attributes are supported o
*** 37035,37041 ****
       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
--- 37044,37050 ----
       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
*************** The following attributes are supported o
*** 37051,37063 ****
            Default visibility corresponds to "external linkage" in the
            language.
  
!      'hidden'
            Hidden visibility indicates that the entity declared has a new
            form of linkage, which we call "hidden linkage".  Two
            declarations of an object with hidden linkage refer to the
            same object if they are in the same shared object.
  
!      'internal'
            Internal visibility is like hidden visibility, but with
            additional processor specific semantics.  Unless otherwise
            specified by the psABI, GCC defines internal visibility to
--- 37060,37072 ----
            Default visibility corresponds to "external linkage" in the
            language.
  
!      ‘hidden’
            Hidden visibility indicates that the entity declared has a new
            form of linkage, which we call "hidden linkage".  Two
            declarations of an object with hidden linkage refer to the
            same object if they are in the same shared object.
  
!      ‘internal’
            Internal visibility is like hidden visibility, but with
            additional processor specific semantics.  Unless otherwise
            specified by the psABI, GCC defines internal visibility to
*************** The following attributes are supported o
*** 37069,37082 ****
            instance omit the load of a PIC register since it is known
            that the calling function loaded the correct value.
  
!      'protected'
            Protected visibility is like default visibility except that it
            indicates that references within the defining module bind to
            the definition in that module.  That is, the declared entity
            cannot be overridden by another module.
  
       All visibilities are supported on many, but not all, ELF targets
!      (supported when the assembler supports the '.visibility'
       pseudo-op).  Default visibility is supported everywhere.  Hidden
       visibility is supported on Darwin targets.
  
--- 37078,37091 ----
            instance omit the load of a PIC register since it is known
            that the calling function loaded the correct value.
  
!      ‘protected’
            Protected visibility is like default visibility except that it
            indicates that references within the defining module bind to
            the definition in that module.  That is, the declared entity
            cannot be overridden by another module.
  
       All visibilities are supported on many, but not all, ELF targets
!      (supported when the assembler supports the ‘.visibility’
       pseudo-op).  Default visibility is supported everywhere.  Hidden
       visibility is supported on Darwin targets.
  
*************** The following attributes are supported o
*** 37108,37114 ****
  
       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
--- 37117,37123 ----
  
       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
*************** The following attributes are supported o
*** 37119,37130 ****
       If both the template and enclosing class have explicit visibility,
       the visibility from the template is used.
  
! 'warn_unused_result'
!      The 'warn_unused_result' attribute causes a warning to be emitted
       if a caller of the function with this attribute does not use its
       return value.  This is useful for functions where not checking the
       result is either a security problem or always a bug, such as
!      'realloc'.
  
            int fn () __attribute__ ((warn_unused_result));
            int foo ()
--- 37128,37139 ----
       If both the template and enclosing class have explicit visibility,
       the visibility from the template is used.
  
! ‘warn_unused_result’
!      The ‘warn_unused_result’ attribute causes a warning to be emitted
       if a caller of the function with this attribute does not use its
       return value.  This is useful for functions where not checking the
       result is either a security problem or always a bug, such as
!      ‘realloc’.
  
            int fn () __attribute__ ((warn_unused_result));
            int foo ()
*************** The following attributes are supported o
*** 37136,37143 ****
  
       results in warning on line 5.
  
! 'weak'
!      The 'weak' attribute causes a declaration of an external symbol to
       be emitted as a weak symbol rather than a global.  This is
       primarily useful in defining library functions that can be
       overridden in user code, though it can also be used with
--- 37145,37152 ----
  
       results in warning on line 5.
  
! ‘weak’
!      The ‘weak’ attribute causes a declaration of an external symbol to
       be emitted as a weak symbol rather than a global.  This is
       primarily useful in defining library functions that can be
       overridden in user code, though it can also be used with
*************** The following attributes are supported o
*** 37147,37165 ****
       symbol.  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.  Alternatively, TARGET may be given as an
!      argument to 'weakref' itself, naming the target definition of the
       alias.  The TARGET must have the same type as the declaration.  In
       addition, if it designates a variable it must also have the same
       size and alignment as the declaration.  In either form of the
!      declaration 'weakref' implicitly marks the declared symbol as
!      'weak'.  Without a TARGET given as an argument to 'weakref' or to
!      'alias', 'weakref' is equivalent to 'weak' (in that case the
!      declaration may be 'extern').
  
            /* Given the declaration: */
            extern int y (void);
--- 37156,37174 ----
       symbol.  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.  Alternatively, TARGET may be given as an
!      argument to ‘weakref’ itself, naming the target definition of the
       alias.  The TARGET must have the same type as the declaration.  In
       addition, if it designates a variable it must also have the same
       size and alignment as the declaration.  In either form of the
!      declaration ‘weakref’ implicitly marks the declared symbol as
!      ‘weak’.  Without a TARGET given as an argument to ‘weakref’ or to
!      ‘alias’, ‘weakref’ is equivalent to ‘weak’ (in that case the
!      declaration may be ‘extern’).
  
            /* Given the declaration: */
            extern int y (void);
*************** The following attributes are supported o
*** 37177,37183 ****
       A weak reference is an alias that does not by itself require a
       definition to be given for the target symbol.  If the target symbol
       is only referenced through weak references, then it becomes a
!      'weak' undefined symbol.  If it is directly referenced, however,
       then such strong references prevail, and a definition is required
       for the symbol, not necessarily in the same translation unit.
  
--- 37186,37192 ----
       A weak reference is an alias that does not by itself require a
       definition to be given for the target symbol.  If the target symbol
       is only referenced through weak references, then it becomes a
!      ‘weak’ undefined symbol.  If it is directly referenced, however,
       then such strong references prevail, and a definition is required
       for the symbol, not necessarily in the same translation unit.
  
*************** The following attributes are supported o
*** 37185,37198 ****
       separate translation unit, renaming the alias to the aliased
       symbol, declaring it as weak, compiling the two separate
       translation units and performing a link with relocatable output
!      (i.e. 'ld -r') on them.
  
!      A declaration to which 'weakref' is attached and that is associated
!      with a named 'target' must be 'static'.
  
! 'zero_call_used_regs ("CHOICE")'
  
!      The 'zero_call_used_regs' attribute causes the compiler to zero a
       subset of all call-used registers(1) at function return.  This is
       used to increase program security by either mitigating
       Return-Oriented Programming (ROP) attacks or preventing information
--- 37194,37207 ----
       separate translation unit, renaming the alias to the aliased
       symbol, declaring it as weak, compiling the two separate
       translation units and performing a link with relocatable output
!      (i.e. ‘ld -r’) on them.
  
!      A declaration to which ‘weakref’ is attached and that is associated
!      with a named ‘target’ must be ‘static’.
  
! ‘zero_call_used_regs ("CHOICE")’
  
!      The ‘zero_call_used_regs’ attribute causes the compiler to zero a
       subset of all call-used registers(1) at function return.  This is
       used to increase program security by either mitigating
       Return-Oriented Programming (ROP) attacks or preventing information
*************** The following attributes are supported o
*** 37203,37223 ****
       provides a flexible way to choose the subset of the call-used
       registers to be zeroed.  The three basic values of CHOICE are:
  
!         * 'skip' doesn't zero any call-used registers.
  
!         * 'used' only zeros call-used registers that are used in the
            function.  A "used" register is one whose content has been set
            or referenced in the function.
  
!         * 'all' zeros all call-used registers.
  
       In addition to these three basic choices, it is possible to modify
!      'used' or 'all' as follows:
  
!         * Adding '-gpr' restricts the zeroing to general-purpose
            registers.
  
!         * Adding '-arg' restricts the zeroing to registers that can
            sometimes be used to pass function arguments.  This includes
            all argument registers defined by the platform's calling
            conversion, regardless of whether the function uses those
--- 37212,37232 ----
       provides a flexible way to choose the subset of the call-used
       registers to be zeroed.  The three basic values of CHOICE are:
  
!         • ‘skip’ doesn't zero any call-used registers.
  
!         • ‘used’ only zeros call-used registers that are used in the
            function.  A "used" register is one whose content has been set
            or referenced in the function.
  
!         • ‘all’ zeros all call-used registers.
  
       In addition to these three basic choices, it is possible to modify
!      ‘used’ or ‘all’ as follows:
  
!         • Adding ‘-gpr’ restricts the zeroing to general-purpose
            registers.
  
!         • Adding ‘-arg’ restricts the zeroing to registers that can
            sometimes be used to pass function arguments.  This includes
            all argument registers defined by the platform's calling
            conversion, regardless of whether the function uses those
*************** The following attributes are supported o
*** 37228,37269 ****
  
       The full list of CHOICEs is therefore:
  
!      'skip'
            doesn't zero any call-used register.
  
!      'used'
            only zeros call-used registers that are used in the function.
  
!      'used-gpr'
            only zeros call-used general purpose registers that are used
            in the function.
  
!      'used-arg'
            only zeros call-used registers that are used in the function
            and pass arguments.
  
!      'used-gpr-arg'
            only zeros call-used general purpose registers that are used
            in the function and pass arguments.
  
!      'all'
            zeros all call-used registers.
  
!      'all-gpr'
            zeros all call-used general purpose registers.
  
!      'all-arg'
            zeros all call-used registers that pass arguments.
  
!      'all-gpr-arg'
            zeros all call-used general purpose registers that pass
            arguments.
  
!      Of this list, 'used-arg', 'used-gpr-arg', 'all-arg', and
!      'all-gpr-arg' are mainly used for ROP mitigation.
  
       The default for the attribute is controlled by
!      '-fzero-call-used-regs'.
  
     ---------- Footnotes ----------
  
--- 37237,37278 ----
  
       The full list of CHOICEs is therefore:
  
!      ‘skip’
            doesn't zero any call-used register.
  
!      ‘used’
            only zeros call-used registers that are used in the function.
  
!      ‘used-gpr’
            only zeros call-used general purpose registers that are used
            in the function.
  
!      ‘used-arg’
            only zeros call-used registers that are used in the function
            and pass arguments.
  
!      ‘used-gpr-arg’
            only zeros call-used general purpose registers that are used
            in the function and pass arguments.
  
!      ‘all’
            zeros all call-used registers.
  
!      ‘all-gpr’
            zeros all call-used general purpose registers.
  
!      ‘all-arg’
            zeros all call-used registers that pass arguments.
  
!      ‘all-gpr-arg’
            zeros all call-used general purpose registers that pass
            arguments.
  
!      Of this list, ‘used-arg’, ‘used-gpr-arg’, ‘all-arg’, and
!      ‘all-gpr-arg’ are mainly used for ROP mitigation.
  
       The default for the attribute is controlled by
!      ‘-fzero-call-used-regs’.
  
     ---------- Footnotes ----------
  
*************** AArch64 target.  For the most part, thes
*** 37284,37363 ****
  similar command-line options (*note AArch64 Options::), but on a
  per-function basis.
  
! 'general-regs-only'
       Indicates that no floating-point or Advanced SIMD registers should
       be used when generating code for this function.  If the function
       explicitly uses floating-point code, then the compiler gives an
       error.  This is the same behavior as that of the command-line
!      option '-mgeneral-regs-only'.
  
! 'fix-cortex-a53-835769'
       Indicates that the workaround for the Cortex-A53 erratum 835769
       should be applied to this function.  To explicitly disable the
       workaround for this function specify the negated form:
!      'no-fix-cortex-a53-835769'.  This corresponds to the behavior of
!      the command line options '-mfix-cortex-a53-835769' and
!      '-mno-fix-cortex-a53-835769'.
  
! 'cmodel='
       Indicates that code should be generated for a particular code model
       for this function.  The behavior and permissible arguments are the
!      same as for the command line option '-mcmodel='.
  
! 'strict-align'
! 'no-strict-align'
!      'strict-align' indicates that the compiler should not assume that
       unaligned memory references are handled by the system.  To allow
       the compiler to assume that aligned memory references are handled
!      by the system, the inverse attribute 'no-strict-align' can be
       specified.  The behavior is same as for the command-line option
!      '-mstrict-align' and '-mno-strict-align'.
  
! 'omit-leaf-frame-pointer'
       Indicates that the frame pointer should be omitted for a leaf
       function call.  To keep the frame pointer, the inverse attribute
!      'no-omit-leaf-frame-pointer' can be specified.  These attributes
       have the same behavior as the command-line options
!      '-momit-leaf-frame-pointer' and '-mno-omit-leaf-frame-pointer'.
  
! 'tls-dialect='
       Specifies the TLS dialect to use for this function.  The behavior
       and permissible arguments are the same as for the command-line
!      option '-mtls-dialect='.
  
! 'arch='
       Specifies the architecture version and architectural extensions to
       use for this function.  The behavior and permissible arguments are
!      the same as for the '-march=' command-line option.
  
! 'tune='
       Specifies the core for which to tune the performance of this
       function.  The behavior and permissible arguments are the same as
!      for the '-mtune=' command-line option.
  
! 'cpu='
       Specifies the core for which to tune the performance of this
       function and also whose architectural features to use.  The
!      behavior and valid arguments are the same as for the '-mcpu='
       command-line option.
  
! 'sign-return-address'
       Select the function scope on which return address signing will be
       applied.  The behavior and permissible arguments are the same as
!      for the command-line option '-msign-return-address='.  The default
!      value is 'none'.  This attribute is deprecated.  The
!      'branch-protection' attribute should be used instead.
  
! 'branch-protection'
       Select the function scope on which branch protection will be
       applied.  The behavior and permissible arguments are the same as
!      for the command-line option '-mbranch-protection='.  The default
!      value is 'none'.
  
! 'outline-atomics'
       Enable or disable calls to out-of-line helpers to implement atomic
       operations.  This corresponds to the behavior of the command line
!      options '-moutline-atomics' and '-mno-outline-atomics'.
  
   The above target attributes can be specified as follows:
  
--- 37293,37372 ----
  similar command-line options (*note AArch64 Options::), but on a
  per-function basis.
  
! ‘general-regs-only’
       Indicates that no floating-point or Advanced SIMD registers should
       be used when generating code for this function.  If the function
       explicitly uses floating-point code, then the compiler gives an
       error.  This is the same behavior as that of the command-line
!      option ‘-mgeneral-regs-only’.
  
! ‘fix-cortex-a53-835769’
       Indicates that the workaround for the Cortex-A53 erratum 835769
       should be applied to this function.  To explicitly disable the
       workaround for this function specify the negated form:
!      ‘no-fix-cortex-a53-835769’.  This corresponds to the behavior of
!      the command line options ‘-mfix-cortex-a53-835769’ and
!      ‘-mno-fix-cortex-a53-835769’.
  
! ‘cmodel=’
       Indicates that code should be generated for a particular code model
       for this function.  The behavior and permissible arguments are the
!      same as for the command line option ‘-mcmodel=’.
  
! ‘strict-align’
! ‘no-strict-align’
!      ‘strict-align’ indicates that the compiler should not assume that
       unaligned memory references are handled by the system.  To allow
       the compiler to assume that aligned memory references are handled
!      by the system, the inverse attribute ‘no-strict-align’ can be
       specified.  The behavior is same as for the command-line option
!      ‘-mstrict-align’ and ‘-mno-strict-align’.
  
! ‘omit-leaf-frame-pointer’
       Indicates that the frame pointer should be omitted for a leaf
       function call.  To keep the frame pointer, the inverse attribute
!      ‘no-omit-leaf-frame-pointer’ can be specified.  These attributes
       have the same behavior as the command-line options
!      ‘-momit-leaf-frame-pointer’ and ‘-mno-omit-leaf-frame-pointer’.
  
! ‘tls-dialect=’
       Specifies the TLS dialect to use for this function.  The behavior
       and permissible arguments are the same as for the command-line
!      option ‘-mtls-dialect=’.
  
! ‘arch=’
       Specifies the architecture version and architectural extensions to
       use for this function.  The behavior and permissible arguments are
!      the same as for the ‘-march=’ command-line option.
  
! ‘tune=’
       Specifies the core for which to tune the performance of this
       function.  The behavior and permissible arguments are the same as
!      for the ‘-mtune=’ command-line option.
  
! ‘cpu=’
       Specifies the core for which to tune the performance of this
       function and also whose architectural features to use.  The
!      behavior and valid arguments are the same as for the ‘-mcpu=’
       command-line option.
  
! ‘sign-return-address’
       Select the function scope on which return address signing will be
       applied.  The behavior and permissible arguments are the same as
!      for the command-line option ‘-msign-return-address=’.  The default
!      value is ‘none’.  This attribute is deprecated.  The
!      ‘branch-protection’ attribute should be used instead.
  
! ‘branch-protection’
       Select the function scope on which branch protection will be
       applied.  The behavior and permissible arguments are the same as
!      for the command-line option ‘-mbranch-protection=’.  The default
!      value is ‘none’.
  
! ‘outline-atomics’
       Enable or disable calls to out-of-line helpers to implement atomic
       operations.  This corresponds to the behavior of the command line
!      options ‘-moutline-atomics’ and ‘-mno-outline-atomics’.
  
   The above target attributes can be specified as follows:
  
*************** per-function basis.
*** 37368,37374 ****
         return a + 5;
       }
  
!  where 'ATTR-STRING' is one of the attribute strings specified above.
  
   Additionally, the architectural extension string may be specified on
  its own.  This can be used to turn on and off particular architectural
--- 37377,37383 ----
         return a + 5;
       }
  
!  where ‘ATTR-STRING’ is one of the attribute strings specified above.
  
   Additionally, the architectural extension string may be specified on
  its own.  This can be used to turn on and off particular architectural
*************** or core.  Example:
*** 37382,37390 ****
         return a + 5;
       }
  
!  In this example 'target("+crc+nocrypto")' enables the 'crc' extension
! and disables the 'crypto' extension for the function 'foo' without
! modifying an existing '-march=' or '-mcpu' option.
  
   Multiple target function attributes can be specified by separating them
  with a comma.  For example:
--- 37391,37399 ----
         return a + 5;
       }
  
!  In this example ‘target("+crc+nocrypto")’ enables the ‘crc’ extension
! and disables the ‘crypto’ extension for the function ‘foo’ without
! modifying an existing ‘-march=’ or ‘-mcpu’ option.
  
   Multiple target function attributes can be specified by separating them
  with a comma.  For example:
*************** with a comma.  For example:
*** 37395,37402 ****
         return a + 5;
       }
  
!  is valid and compiles function 'foo' for ARMv8-A with 'crc' and
! 'crypto' extensions and tunes it for 'cortex-a53'.
  
  6.33.2.1 Inlining rules
  .......................
--- 37404,37411 ----
         return a + 5;
       }
  
!  is valid and compiles function ‘foo’ for ARMv8-A with ‘crc’ and
! ‘crypto’ extensions and tunes it for ‘cortex-a53’.
  
  6.33.2.1 Inlining rules
  .......................
*************** target options can affect function inlin
*** 37407,37427 ****
  
   In particular, a caller function can inline a callee function only if
  the architectural features available to the callee are a subset of the
! features available to the caller.  For example: A function 'foo'
! compiled with '-march=armv8-a+crc', or tagged with the equivalent
! 'arch=armv8-a+crc' attribute, can inline a function 'bar' compiled with
! '-march=armv8-a+nocrc' because the all the architectural features that
! function 'bar' requires are available to function 'foo'.  Conversely,
! function 'bar' cannot inline function 'foo'.
  
!  Additionally inlining a function compiled with '-mstrict-align' into a
! function compiled without '-mstrict-align' is not allowed.  However,
! inlining a function compiled without '-mstrict-align' into a function
! compiled with '-mstrict-align' is allowed.
  
!  Note that CPU tuning options and attributes such as the '-mcpu=',
! '-mtune=' do not inhibit inlining unless the CPU specified by the
! '-mcpu=' option or the 'cpu=' attribute conflicts with the architectural
  feature rules specified above.
  
  
--- 37416,37436 ----
  
   In particular, a caller function can inline a callee function only if
  the architectural features available to the callee are a subset of the
! features available to the caller.  For example: A function ‘foo’
! compiled with ‘-march=armv8-a+crc’, or tagged with the equivalent
! ‘arch=armv8-a+crc’ attribute, can inline a function ‘bar’ compiled with
! ‘-march=armv8-a+nocrc’ because the all the architectural features that
! function ‘bar’ requires are available to function ‘foo’.  Conversely,
! function ‘bar’ cannot inline function ‘foo’.
  
!  Additionally inlining a function compiled with ‘-mstrict-align’ into a
! function compiled without ‘-mstrict-align’ is not allowed.  However,
! inlining a function compiled without ‘-mstrict-align’ into a function
! compiled with ‘-mstrict-align’ is allowed.
  
!  Note that CPU tuning options and attributes such as the ‘-mcpu=’,
! ‘-mtune=’ do not inhibit inlining unless the CPU specified by the
! ‘-mcpu=’ option or the ‘cpu=’ attribute conflicts with the architectural
  feature rules specified above.
  
  
*************** File: gcc.info,  Node: AMD GCN Function
*** 37432,37444 ****
  
  These function attributes are supported by the AMD GCN back end:
  
! 'amdgpu_hsa_kernel'
       This attribute indicates that the corresponding function should be
       compiled as a kernel function, that is an entry point that can be
       invoked from the host via the HSA runtime library.  By default
       functions are only callable only from other GCN functions.
  
!      This attribute is implicitly applied to any function named 'main',
       using default parameters.
  
       Kernel functions may return an integer value, which will be written
--- 37441,37453 ----
  
  These function attributes are supported by the AMD GCN back end:
  
! ‘amdgpu_hsa_kernel’
       This attribute indicates that the corresponding function should be
       compiled as a kernel function, that is an entry point that can be
       invoked from the host via the HSA runtime library.  By default
       functions are only callable only from other GCN functions.
  
!      This attribute is implicitly applied to any function named ‘main’,
       using default parameters.
  
       Kernel functions may return an integer value, which will be written
*************** These function attributes are supported
*** 37450,37516 ****
       Enabling other options may break assumptions in the compiler and/or
       run-time libraries.
  
!      'private_segment_buffer'
!           Set 'enable_sgpr_private_segment_buffer' flag.  Always on
            (required to locate the stack).
  
!      'dispatch_ptr'
!           Set 'enable_sgpr_dispatch_ptr' flag.  Always on (required to
            locate the launch dimensions).
  
!      'queue_ptr'
!           Set 'enable_sgpr_queue_ptr' flag.  Always on (required to
            convert address spaces).
  
!      'kernarg_segment_ptr'
!           Set 'enable_sgpr_kernarg_segment_ptr' flag.  Always on
            (required to locate the kernel arguments, "kernargs").
  
!      'dispatch_id'
!           Set 'enable_sgpr_dispatch_id' flag.
  
!      'flat_scratch_init'
!           Set 'enable_sgpr_flat_scratch_init' flag.
  
!      'private_segment_size'
!           Set 'enable_sgpr_private_segment_size' flag.
  
!      'grid_workgroup_count_X'
!           Set 'enable_sgpr_grid_workgroup_count_x' flag.  Always on
            (required to use OpenACC/OpenMP).
  
!      'grid_workgroup_count_Y'
!           Set 'enable_sgpr_grid_workgroup_count_y' flag.
  
!      'grid_workgroup_count_Z'
!           Set 'enable_sgpr_grid_workgroup_count_z' flag.
  
!      'workgroup_id_X'
!           Set 'enable_sgpr_workgroup_id_x' flag.
  
!      'workgroup_id_Y'
!           Set 'enable_sgpr_workgroup_id_y' flag.
  
!      'workgroup_id_Z'
!           Set 'enable_sgpr_workgroup_id_z' flag.
  
!      'workgroup_info'
!           Set 'enable_sgpr_workgroup_info' flag.
  
!      'private_segment_wave_offset'
!           Set 'enable_sgpr_private_segment_wave_byte_offset' flag.
            Always on (required to locate the stack).
  
!      'work_item_id_X'
!           Set 'enable_vgpr_workitem_id' parameter.  Always on (can't be
            disabled).
  
!      'work_item_id_Y'
!           Set 'enable_vgpr_workitem_id' parameter.  Always on (required
            to enable vectorization.)
  
!      'work_item_id_Z'
!           Set 'enable_vgpr_workitem_id' parameter.  Always on (required
            to use OpenACC/OpenMP).
  
  
--- 37459,37525 ----
       Enabling other options may break assumptions in the compiler and/or
       run-time libraries.
  
!      ‘private_segment_buffer’
!           Set ‘enable_sgpr_private_segment_buffer’ flag.  Always on
            (required to locate the stack).
  
!      ‘dispatch_ptr’
!           Set ‘enable_sgpr_dispatch_ptr’ flag.  Always on (required to
            locate the launch dimensions).
  
!      ‘queue_ptr’
!           Set ‘enable_sgpr_queue_ptr’ flag.  Always on (required to
            convert address spaces).
  
!      ‘kernarg_segment_ptr’
!           Set ‘enable_sgpr_kernarg_segment_ptr’ flag.  Always on
            (required to locate the kernel arguments, "kernargs").
  
!      ‘dispatch_id’
!           Set ‘enable_sgpr_dispatch_id’ flag.
  
!      ‘flat_scratch_init’
!           Set ‘enable_sgpr_flat_scratch_init’ flag.
  
!      ‘private_segment_size’
!           Set ‘enable_sgpr_private_segment_size’ flag.
  
!      ‘grid_workgroup_count_X’
!           Set ‘enable_sgpr_grid_workgroup_count_x’ flag.  Always on
            (required to use OpenACC/OpenMP).
  
!      ‘grid_workgroup_count_Y’
!           Set ‘enable_sgpr_grid_workgroup_count_y’ flag.
  
!      ‘grid_workgroup_count_Z’
!           Set ‘enable_sgpr_grid_workgroup_count_z’ flag.
  
!      ‘workgroup_id_X’
!           Set ‘enable_sgpr_workgroup_id_x’ flag.
  
!      ‘workgroup_id_Y’
!           Set ‘enable_sgpr_workgroup_id_y’ flag.
  
!      ‘workgroup_id_Z’
!           Set ‘enable_sgpr_workgroup_id_z’ flag.
  
!      ‘workgroup_info’
!           Set ‘enable_sgpr_workgroup_info’ flag.
  
!      ‘private_segment_wave_offset’
!           Set ‘enable_sgpr_private_segment_wave_byte_offset’ flag.
            Always on (required to locate the stack).
  
!      ‘work_item_id_X’
!           Set ‘enable_vgpr_workitem_id’ parameter.  Always on (can't be
            disabled).
  
!      ‘work_item_id_Y’
!           Set ‘enable_vgpr_workitem_id’ parameter.  Always on (required
            to enable vectorization.)
  
!      ‘work_item_id_Z’
!           Set ‘enable_vgpr_workitem_id’ parameter.  Always on (required
            to use OpenACC/OpenMP).
  
  
*************** File: gcc.info,  Node: ARC Function Attr
*** 37521,37527 ****
  
  These function attributes are supported by the ARC back end:
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 37530,37536 ----
  
  These function attributes are supported by the ARC back end:
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** These function attributes are supported
*** 37532,37583 ****
  
            void f () __attribute__ ((interrupt ("ilink1")));
  
!      Permissible values for this parameter are: 'ilink1' and 'ilink2'
!      for ARCv1 architecture, and 'ilink' and 'firq' for ARCv2
       architecture.
  
! 'long_call'
! 'medium_call'
! 'short_call'
       These attributes specify how a particular function is called.
!      These attributes override the '-mlong-calls' and '-mmedium-calls'
!      (*note ARC Options::) command-line switches and '#pragma
!      long_calls' settings.
  
!      For ARC, a function marked with the 'long_call' attribute is always
       called using register-indirect jump-and-link instructions, thereby
       enabling the called function to be placed anywhere within the
!      32-bit address space.  A function marked with the 'medium_call'
       attribute will always be close enough to be called with an
       unconditional branch-and-link instruction, which has a 25-bit
!      offset from the call site.  A function marked with the 'short_call'
       attribute will always be close enough to be called with a
       conditional branch-and-link instruction, which has a 21-bit offset
       from the call site.
  
! 'jli_always'
!      Forces a particular function to be called using 'jli' instruction.
!      The 'jli' instruction makes use of a table stored into '.jlitab'
       section, which holds the location of the functions which are
       addressed using this instruction.
  
! 'jli_fixed'
       Identical like the above one, but the location of the function in
!      the 'jli' table is known and given as an attribute parameter.
  
! 'secure_call'
       This attribute allows one to mark secure-code functions that are
       callable from normal mode.  The location of the secure call
!      function into the 'sjli' table needs to be passed as argument.
  
! 'naked'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
  
--- 37541,37592 ----
  
            void f () __attribute__ ((interrupt ("ilink1")));
  
!      Permissible values for this parameter are: ‘ilink1’ and ‘ilink2’
!      for ARCv1 architecture, and ‘ilink’ and ‘firq’ for ARCv2
       architecture.
  
! ‘long_call’
! ‘medium_call’
! ‘short_call’
       These attributes specify how a particular function is called.
!      These attributes override the ‘-mlong-calls’ and ‘-mmedium-calls’
!      (*note ARC Options::) command-line switches and ‘#pragma
!      long_calls’ settings.
  
!      For ARC, a function marked with the ‘long_call’ attribute is always
       called using register-indirect jump-and-link instructions, thereby
       enabling the called function to be placed anywhere within the
!      32-bit address space.  A function marked with the ‘medium_call’
       attribute will always be close enough to be called with an
       unconditional branch-and-link instruction, which has a 25-bit
!      offset from the call site.  A function marked with the ‘short_call’
       attribute will always be close enough to be called with a
       conditional branch-and-link instruction, which has a 21-bit offset
       from the call site.
  
! ‘jli_always’
!      Forces a particular function to be called using ‘jli’ instruction.
!      The ‘jli’ instruction makes use of a table stored into ‘.jlitab’
       section, which holds the location of the functions which are
       addressed using this instruction.
  
! ‘jli_fixed’
       Identical like the above one, but the location of the function in
!      the ‘jli’ table is known and given as an attribute parameter.
  
! ‘secure_call’
       This attribute allows one to mark secure-code functions that are
       callable from normal mode.  The location of the secure call
!      function into the ‘sjli’ table needs to be passed as argument.
  
! ‘naked’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
  
*************** File: gcc.info,  Node: ARM Function Attr
*** 37588,37601 ****
  
  These function attributes are supported for ARM targets:
  
! 'general-regs-only'
       Indicates that no floating-point or Advanced SIMD registers should
       be used when generating code for this function.  If the function
       explicitly uses floating-point code, then the compiler gives an
       error.  This is the same behavior as that of the command-line
!      option '-mgeneral-regs-only'.
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 37597,37610 ----
  
  These function attributes are supported for ARM targets:
  
! ‘general-regs-only’
       Indicates that no floating-point or Advanced SIMD registers should
       be used when generating code for this function.  If the function
       explicitly uses floating-point code, then the compiler gives an
       error.  This is the same behavior as that of the command-line
!      option ‘-mgeneral-regs-only’.
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** These function attributes are supported
*** 37606,37686 ****
  
            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.
  
! 'isr'
       Use this attribute on ARM to write Interrupt Service Routines.
!      This is an alias to the 'interrupt' attribute above.
  
! 'long_call'
! 'short_call'
       These attributes specify how a particular function is called.
!      These attributes override the '-mlong-calls' (*note ARM Options::)
!      command-line switch and '#pragma long_calls' settings.  For ARM,
!      the 'long_call' attribute indicates that the function might be far
       away from the call site and require a different (more expensive)
!      calling sequence.  The 'short_call' attribute always places the
!      offset to the function from the call site into the 'BL' instruction
       directly.
  
! 'naked'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! 'pcs'
  
!      The 'pcs' attribute can be used to control the calling convention
       used for a function on ARM. The attribute takes an argument that
       specifies the calling convention to use.
  
       When compiling using the AAPCS ABI (or a variant of it) then valid
!      values for the argument are '"aapcs"' and '"aapcs-vfp"'.  In order
!      to use a variant other than '"aapcs"' then the compiler must be
       permitted to use the appropriate co-processor registers (i.e., the
!      VFP registers must be available in order to use '"aapcs-vfp"').
       For example,
  
            /* Argument passed in r0, and result returned in r0+r1.  */
            double f2d (float) __attribute__((pcs("aapcs")));
  
!      Variadic functions always use the '"aapcs"' calling convention and
       the compiler rejects attempts to specify an alternative.
  
! 'target (OPTIONS)'
       As discussed in *note Common Function Attributes::, this attribute
       allows specification of target-specific compilation options.
  
       On ARM, the following options are allowed:
  
!      'thumb'
            Force code generation in the Thumb (T16/T32) ISA, depending on
            the architecture level.
  
!      'arm'
            Force code generation in the ARM (A32) ISA.
  
            Functions from different modes can be inlined in the caller's
            mode.
  
!      'fpu='
            Specifies the fpu for which to tune the performance of this
            function.  The behavior and permissible arguments are the same
!           as for the '-mfpu=' command-line option.
  
!      'arch='
            Specifies the architecture version and architectural
            extensions to use for this function.  The behavior and
!           permissible arguments are the same as for the '-march='
            command-line option.
  
            The above target attributes can be specified as follows:
--- 37615,37695 ----
  
            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.
  
! ‘isr’
       Use this attribute on ARM to write Interrupt Service Routines.
!      This is an alias to the ‘interrupt’ attribute above.
  
! ‘long_call’
! ‘short_call’
       These attributes specify how a particular function is called.
!      These attributes override the ‘-mlong-calls’ (*note ARM Options::)
!      command-line switch and ‘#pragma long_calls’ settings.  For ARM,
!      the ‘long_call’ attribute indicates that the function might be far
       away from the call site and require a different (more expensive)
!      calling sequence.  The ‘short_call’ attribute always places the
!      offset to the function from the call site into the ‘BL’ instruction
       directly.
  
! ‘naked’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! ‘pcs’
  
!      The ‘pcs’ attribute can be used to control the calling convention
       used for a function on ARM. The attribute takes an argument that
       specifies the calling convention to use.
  
       When compiling using the AAPCS ABI (or a variant of it) then valid
!      values for the argument are ‘"aapcs"’ and ‘"aapcs-vfp"’.  In order
!      to use a variant other than ‘"aapcs"’ then the compiler must be
       permitted to use the appropriate co-processor registers (i.e., the
!      VFP registers must be available in order to use ‘"aapcs-vfp"’).
       For example,
  
            /* Argument passed in r0, and result returned in r0+r1.  */
            double f2d (float) __attribute__((pcs("aapcs")));
  
!      Variadic functions always use the ‘"aapcs"’ calling convention and
       the compiler rejects attempts to specify an alternative.
  
! ‘target (OPTIONS)’
       As discussed in *note Common Function Attributes::, this attribute
       allows specification of target-specific compilation options.
  
       On ARM, the following options are allowed:
  
!      ‘thumb’
            Force code generation in the Thumb (T16/T32) ISA, depending on
            the architecture level.
  
!      ‘arm’
            Force code generation in the ARM (A32) ISA.
  
            Functions from different modes can be inlined in the caller's
            mode.
  
!      ‘fpu=’
            Specifies the fpu for which to tune the performance of this
            function.  The behavior and permissible arguments are the same
!           as for the ‘-mfpu=’ command-line option.
  
!      ‘arch=’
            Specifies the architecture version and architectural
            extensions to use for this function.  The behavior and
!           permissible arguments are the same as for the ‘-march=’
            command-line option.
  
            The above target attributes can be specified as follows:
*************** These function attributes are supported
*** 37704,37712 ****
                   return a + 5;
                 }
  
!           In this example 'target("+crc+nocrypto")' enables the 'crc'
!           extension and disables the 'crypto' extension for the function
!           'foo' without modifying an existing '-march=' or '-mcpu'
            option.
  
  
--- 37713,37721 ----
                   return a + 5;
                 }
  
!           In this example ‘target("+crc+nocrypto")’ enables the ‘crc’
!           extension and disables the ‘crypto’ extension for the function
!           ‘foo’ without modifying an existing ‘-march=’ or ‘-mcpu’
            option.
  
  
*************** File: gcc.info,  Node: AVR Function Attr
*** 37717,37723 ****
  
  These function attributes are supported by the AVR back end:
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 37726,37732 ----
  
  These function attributes are supported by the AVR back end:
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** These function attributes are supported
*** 37725,37749 ****
  
       On the AVR, the hardware globally disables interrupts when an
       interrupt is executed.  The first instruction of an interrupt
!      handler declared with this attribute is a 'SEI' instruction to
!      re-enable interrupts.  See also the 'signal' function attribute
!      that does not insert a 'SEI' instruction.  If both 'signal' and
!      'interrupt' are specified for the same function, 'signal' is
       silently ignored.
  
! 'naked'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! 'no_gccisr'
!      Do not use '__gcc_isr' pseudo instructions in a function with the
!      'interrupt' or 'signal' attribute aka.  interrupt service routine
       (ISR). Use this attribute if the preamble of the ISR prologue
       should always read
            push  __zero_reg__
--- 37734,37758 ----
  
       On the AVR, the hardware globally disables interrupts when an
       interrupt is executed.  The first instruction of an interrupt
!      handler declared with this attribute is a ‘SEI’ instruction to
!      re-enable interrupts.  See also the ‘signal’ function attribute
!      that does not insert a ‘SEI’ instruction.  If both ‘signal’ and
!      ‘interrupt’ are specified for the same function, ‘signal’ is
       silently ignored.
  
! ‘naked’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! ‘no_gccisr’
!      Do not use ‘__gcc_isr’ pseudo instructions in a function with the
!      ‘interrupt’ or ‘signal’ attribute aka.  interrupt service routine
       (ISR). Use this attribute if the preamble of the ISR prologue
       should always read
            push  __zero_reg__
*************** These function attributes are supported
*** 37755,37810 ****
       whether the mentioned registers are actually used in the ISR or
       not.  Situations where you might want to use this attribute
       include:
!         * Code that (effectively) clobbers bits of 'SREG' other than the
!           'I'-flag by writing to the memory location of 'SREG'.
!         * Code that uses inline assembler to jump to a different
            function which expects (parts of) the prologue code as
            outlined above to be present.
!      To disable '__gcc_isr' generation for the whole compilation unit,
!      there is option '-mno-gas-isr-prologues', *note AVR Options::.
  
! 'OS_main'
! 'OS_task'
!      On AVR, functions with the 'OS_main' or 'OS_task' attribute do not
       save/restore any call-saved register in their prologue/epilogue.
  
!      The 'OS_main' attribute can be used when there _is guarantee_ that
       interrupts are disabled at the time when the function is entered.
       This saves resources when the stack pointer has to be changed to
       set up a frame for local variables.
  
!      The 'OS_task' attribute can be used when there is _no guarantee_
       that interrupts are disabled at that time when the function is
       entered like for, e.g.  task functions in a multi-threading
       operating system.  In that case, changing the stack pointer
       register is guarded by save/clear/restore of the global interrupt
       enable flag.
  
!      The differences to the 'naked' function attribute are:
!         * 'naked' functions do not have a return instruction whereas
!           'OS_main' and 'OS_task' functions have a 'RET' or 'RETI'
            return instruction.
!         * 'naked' functions do not set up a frame for local variables or
!           a frame pointer whereas 'OS_main' and 'OS_task' do this as
            needed.
  
! 'signal'
       Use this attribute on the AVR to indicate that the specified
       function is an interrupt handler.  The compiler generates function
       entry and exit sequences suitable for use in an interrupt handler
       when this attribute is present.
  
!      See also the 'interrupt' function attribute.
  
       The AVR hardware globally disables interrupts when an interrupt is
!      executed.  Interrupt handler functions defined with the 'signal'
       attribute do not re-enable interrupts.  It is save to enable
!      interrupts in a 'signal' handler.  This "save" only applies to the
       code generated by the compiler and not to the IRQ layout of the
       application which is responsibility of the application.
  
!      If both 'signal' and 'interrupt' are specified for the same
!      function, 'signal' is silently ignored.
  
  
  File: gcc.info,  Node: Blackfin Function Attributes,  Next: BPF Function Attributes,  Prev: AVR Function Attributes,  Up: Function Attributes
--- 37764,37819 ----
       whether the mentioned registers are actually used in the ISR or
       not.  Situations where you might want to use this attribute
       include:
!         • Code that (effectively) clobbers bits of ‘SREG’ other than the
!           ‘I’-flag by writing to the memory location of ‘SREG’.
!         • Code that uses inline assembler to jump to a different
            function which expects (parts of) the prologue code as
            outlined above to be present.
!      To disable ‘__gcc_isr’ generation for the whole compilation unit,
!      there is option ‘-mno-gas-isr-prologues’, *note AVR Options::.
  
! ‘OS_main’
! ‘OS_task’
!      On AVR, functions with the ‘OS_main’ or ‘OS_task’ attribute do not
       save/restore any call-saved register in their prologue/epilogue.
  
!      The ‘OS_main’ attribute can be used when there _is guarantee_ that
       interrupts are disabled at the time when the function is entered.
       This saves resources when the stack pointer has to be changed to
       set up a frame for local variables.
  
!      The ‘OS_task’ attribute can be used when there is _no guarantee_
       that interrupts are disabled at that time when the function is
       entered like for, e.g.  task functions in a multi-threading
       operating system.  In that case, changing the stack pointer
       register is guarded by save/clear/restore of the global interrupt
       enable flag.
  
!      The differences to the ‘naked’ function attribute are:
!         • ‘naked’ functions do not have a return instruction whereas
!           ‘OS_main’ and ‘OS_task’ functions have a ‘RET’ or ‘RETI’
            return instruction.
!         • ‘naked’ functions do not set up a frame for local variables or
!           a frame pointer whereas ‘OS_main’ and ‘OS_task’ do this as
            needed.
  
! ‘signal’
       Use this attribute on the AVR to indicate that the specified
       function is an interrupt handler.  The compiler generates function
       entry and exit sequences suitable for use in an interrupt handler
       when this attribute is present.
  
!      See also the ‘interrupt’ function attribute.
  
       The AVR hardware globally disables interrupts when an interrupt is
!      executed.  Interrupt handler functions defined with the ‘signal’
       attribute do not re-enable interrupts.  It is save to enable
!      interrupts in a ‘signal’ handler.  This "save" only applies to the
       code generated by the compiler and not to the IRQ layout of the
       application which is responsibility of the application.
  
!      If both ‘signal’ and ‘interrupt’ are specified for the same
!      function, ‘signal’ is silently ignored.
  
  
  File: gcc.info,  Node: Blackfin Function Attributes,  Next: BPF Function Attributes,  Prev: AVR Function Attributes,  Up: Function Attributes
*************** File: gcc.info,  Node: Blackfin Function
*** 37814,37867 ****
  
  These function attributes are supported by the Blackfin back end:
  
! 'exception_handler'
       Use this attribute on the Blackfin to indicate that the specified
       function is an exception handler.  The compiler generates function
       entry and exit sequences suitable for use in an exception handler
       when this attribute is present.
  
! 'interrupt_handler'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
       attribute is present.
  
! 'kspisusp'
!      When used together with 'interrupt_handler', 'exception_handler' or
!      'nmi_handler', code is generated to load the stack pointer from the
       USP register in the function prologue.
  
! 'l1_text'
       This attribute specifies a function to be placed into L1
       Instruction SRAM.  The function is put into a specific section
!      named '.l1.text'.  With '-mfdpic', function calls with a such
       function as the callee or caller uses inlined PLT.
  
! 'l2'
       This attribute specifies a function to be placed into L2 SRAM. The
!      function is put into a specific section named '.l2.text'.  With
!      '-mfdpic', callers of such functions use an inlined PLT.
  
! 'longcall'
! 'shortcall'
!      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 the '-mlongcall' switch.
  
! 'nesting'
!      Use this attribute together with 'interrupt_handler',
!      'exception_handler' or 'nmi_handler' to indicate that the function
       entry code should enable nested interrupts or exceptions.
  
! 'nmi_handler'
       Use this attribute on the Blackfin to indicate that the specified
       function is an NMI handler.  The compiler generates function entry
       and exit sequences suitable for use in an NMI handler when this
       attribute is present.
  
! 'saveall'
       Use this attribute to indicate that all registers except the stack
       pointer should be saved in the prologue regardless of whether they
       are used or not.
--- 37823,37876 ----
  
  These function attributes are supported by the Blackfin back end:
  
! ‘exception_handler’
       Use this attribute on the Blackfin to indicate that the specified
       function is an exception handler.  The compiler generates function
       entry and exit sequences suitable for use in an exception handler
       when this attribute is present.
  
! ‘interrupt_handler’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
       attribute is present.
  
! ‘kspisusp’
!      When used together with ‘interrupt_handler’, ‘exception_handler’ or
!      ‘nmi_handler’, code is generated to load the stack pointer from the
       USP register in the function prologue.
  
! ‘l1_text’
       This attribute specifies a function to be placed into L1
       Instruction SRAM.  The function is put into a specific section
!      named ‘.l1.text’.  With ‘-mfdpic’, function calls with a such
       function as the callee or caller uses inlined PLT.
  
! ‘l2’
       This attribute specifies a function to be placed into L2 SRAM. The
!      function is put into a specific section named ‘.l2.text’.  With
!      ‘-mfdpic’, callers of such functions use an inlined PLT.
  
! ‘longcall’
! ‘shortcall’
!      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 the ‘-mlongcall’ switch.
  
! ‘nesting’
!      Use this attribute together with ‘interrupt_handler’,
!      ‘exception_handler’ or ‘nmi_handler’ to indicate that the function
       entry code should enable nested interrupts or exceptions.
  
! ‘nmi_handler’
       Use this attribute on the Blackfin to indicate that the specified
       function is an NMI handler.  The compiler generates function entry
       and exit sequences suitable for use in an NMI handler when this
       attribute is present.
  
! ‘saveall’
       Use this attribute to indicate that all registers except the stack
       pointer should be saved in the prologue regardless of whether they
       are used or not.
*************** File: gcc.info,  Node: BPF Function Attr
*** 37874,37880 ****
  
  These function attributes are supported by the BPF back end:
  
! 'kernel_helper'
       use this attribute to indicate the specified function declaration
       is a kernel helper.  The helper function is passed as an argument
       to the attribute.  Example:
--- 37883,37889 ----
  
  These function attributes are supported by the BPF back end:
  
! ‘kernel_helper’
       use this attribute to indicate the specified function declaration
       is a kernel helper.  The helper function is passed as an argument
       to the attribute.  Example:
*************** File: gcc.info,  Node: C-SKY Function At
*** 37890,37914 ****
  
  These function attributes are supported by the C-SKY back end:
  
! 'interrupt'
! 'isr'
       Use these attributes to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when either of
       these attributes are present.
  
!      Use of these options requires the '-mistack' command-line option to
       enable support for the necessary interrupt stack instructions.
       They are ignored with a warning otherwise.  *Note C-SKY Options::.
  
! 'naked'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
  
--- 37899,37923 ----
  
  These function attributes are supported by the C-SKY back end:
  
! ‘interrupt’
! ‘isr’
       Use these attributes to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when either of
       these attributes are present.
  
!      Use of these options requires the ‘-mistack’ command-line option to
       enable support for the necessary interrupt stack instructions.
       They are ignored with a warning otherwise.  *Note C-SKY Options::.
  
! ‘naked’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
  
*************** File: gcc.info,  Node: Epiphany Function
*** 37919,37936 ****
  
  These function attributes are supported by the Epiphany back end:
  
! 'disinterrupt'
       This attribute causes the compiler to emit instructions to disable
       interrupts for the duration of the given function.
  
! 'forwarder_section'
       This attribute modifies the behavior of an interrupt handler.  The
       interrupt handler may be in external memory which cannot be reached
       by a branch instruction, so generate a local memory trampoline to
       transfer control.  The single parameter identifies the section
       where the trampoline is placed.
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 37928,37945 ----
  
  These function attributes are supported by the Epiphany back end:
  
! ‘disinterrupt’
       This attribute causes the compiler to emit instructions to disable
       interrupts for the duration of the given function.
  
! ‘forwarder_section’
       This attribute modifies the behavior of an interrupt handler.  The
       interrupt handler may be in external memory which cannot be reached
       by a branch instruction, so generate a local memory trampoline to
       transfer control.  The single parameter identifies the section
       where the trampoline is placed.
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** These function attributes are supported
*** 37942,37950 ****
  
            void __attribute__ ((interrupt ("dma0, dma1"))) universal_dma_handler ();
  
!      Permissible values for these parameters are: 'reset',
!      'software_exception', 'page_miss', 'timer0', 'timer1', 'message',
!      'dma0', 'dma1', 'wand' and 'swi'.  Multiple parameters indicate
       that multiple entries in the interrupt vector table should be
       initialized for this function, i.e. for each parameter NAME, a jump
       to the function is emitted in the section ivt_entry_NAME.  The
--- 37951,37959 ----
  
            void __attribute__ ((interrupt ("dma0, dma1"))) universal_dma_handler ();
  
!      Permissible values for these parameters are: ‘reset’,
!      ‘software_exception’, ‘page_miss’, ‘timer0’, ‘timer1’, ‘message’,
!      ‘dma0’, ‘dma1’, ‘wand’ and ‘swi’.  Multiple parameters indicate
       that multiple entries in the interrupt vector table should be
       initialized for this function, i.e. for each parameter NAME, a jump
       to the function is emitted in the section ivt_entry_NAME.  The
*************** These function attributes are supported
*** 37952,37958 ****
       vector table entry is provided.
  
       Note that interrupts are enabled inside the function unless the
!      'disinterrupt' attribute is also specified.
  
       The following examples are all valid uses of these attributes on
       Epiphany targets:
--- 37961,37967 ----
       vector table entry is provided.
  
       Note that interrupts are enabled inside the function unless the
!      ‘disinterrupt’ attribute is also specified.
  
       The following examples are all valid uses of these attributes on
       Epiphany targets:
*************** These function attributes are supported
*** 37966,37976 ****
                                 forwarder_section ("tramp")))
              external_dma_handler ();
  
! 'long_call'
! 'short_call'
       These attributes specify how a particular function is called.
!      These attributes override the '-mlong-calls' (*note Adapteva
!      Epiphany Options::) command-line switch and '#pragma long_calls'
       settings.
  
  
--- 37975,37985 ----
                                 forwarder_section ("tramp")))
              external_dma_handler ();
  
! ‘long_call’
! ‘short_call’
       These attributes specify how a particular function is called.
!      These attributes override the ‘-mlong-calls’ (*note Adapteva
!      Epiphany Options::) command-line switch and ‘#pragma long_calls’
       settings.
  
  
*************** File: gcc.info,  Node: H8/300 Function A
*** 37981,37987 ****
  
  These function attributes are available for H8/300 targets:
  
! 'function_vector'
       Use this attribute on the H8/300, H8/300H, and H8S to indicate that
       the specified function should be called through the function
       vector.  Calling a function through the function vector reduces
--- 37990,37996 ----
  
  These function attributes are available for H8/300 targets:
  
! ‘function_vector’
       Use this attribute on the H8/300, H8/300H, and H8S to indicate that
       the specified function should be called through the function
       vector.  Calling a function through the function vector reduces
*************** These function attributes are available
*** 37989,38001 ****
       128 entries on the H8/300 and 64 entries on the H8/300H and H8S)
       and shares space with the interrupt vector.
  
! 'interrupt_handler'
       Use this attribute on the H8/300, H8/300H, and H8S to indicate that
       the specified function is an interrupt handler.  The compiler
       generates function entry and exit sequences suitable for use in an
       interrupt handler when this attribute is present.
  
! 'saveall'
       Use this attribute on the 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.
--- 37998,38010 ----
       128 entries on the H8/300 and 64 entries on the H8/300H and H8S)
       and shares space with the interrupt vector.
  
! ‘interrupt_handler’
       Use this attribute on the H8/300, H8/300H, and H8S to indicate that
       the specified function is an interrupt handler.  The compiler
       generates function entry and exit sequences suitable for use in an
       interrupt handler when this attribute is present.
  
! ‘saveall’
       Use this attribute on the 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.
*************** File: gcc.info,  Node: IA-64 Function At
*** 38008,38021 ****
  
  These function attributes are supported on IA-64 targets:
  
! 'syscall_linkage'
       This attribute is used to modify the IA-64 calling convention by
       marking all input registers as live at all function exits.  This
       makes it possible to restart a system call after an interrupt
       without having to save/restore the input registers.  This also
       prevents kernel data from leaking into application code.
  
! 'version_id'
       This IA-64 HP-UX attribute, attached to a global variable or
       function, renames a symbol to contain a version string, thus
       allowing for function level versioning.  HP-UX system header files
--- 38017,38030 ----
  
  These function attributes are supported on IA-64 targets:
  
! ‘syscall_linkage’
       This attribute is used to modify the IA-64 calling convention by
       marking all input registers as live at all function exits.  This
       makes it possible to restart a system call after an interrupt
       without having to save/restore the input registers.  This also
       prevents kernel data from leaking into application code.
  
! ‘version_id’
       This IA-64 HP-UX attribute, attached to a global variable or
       function, renames a symbol to contain a version string, thus
       allowing for function level versioning.  HP-UX system header files
*************** These function attributes are supported
*** 38023,38029 ****
  
            extern int foo () __attribute__((version_id ("20040821")));
  
!      Calls to 'foo' are mapped to calls to 'foo{20040821}'.
  
  
  File: gcc.info,  Node: M32C Function Attributes,  Next: M32R/D Function Attributes,  Prev: IA-64 Function Attributes,  Up: Function Attributes
--- 38032,38038 ----
  
            extern int foo () __attribute__((version_id ("20040821")));
  
!      Calls to ‘foo’ are mapped to calls to ‘foo{20040821}’.
  
  
  File: gcc.info,  Node: M32C Function Attributes,  Next: M32R/D Function Attributes,  Prev: IA-64 Function Attributes,  Up: Function Attributes
*************** File: gcc.info,  Node: M32C Function Att
*** 38033,38057 ****
  
  These function attributes are supported by the M32C back end:
  
! '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.
  
! 'fast_interrupt'
       Use this attribute on the M32C port 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'.
  
! 'function_vector'
!      On M16C/M32C targets, the 'function_vector' attribute declares a
       special page subroutine call function.  Use of this attribute
       reduces the code size by 2 bytes for each call generated to the
       subroutine.  The argument to the attribute is the vector number
       entry from the special page vector table which contains the 16
       low-order bits of the subroutine's entry address.  Each vector
!      table has special page number (18 to 255) that is used in 'jsrs'
       instructions.  Jump addresses of the routines are generated by
       adding 0x0F0000 (in case of M16C targets) or 0xFF0000 (in case of
       M32C targets), to the 2-byte addresses set in the vector table.
--- 38042,38066 ----
  
  These function attributes are supported by the M32C back end:
  
! ‘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.
  
! ‘fast_interrupt’
       Use this attribute on the M32C port 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’.
  
! ‘function_vector’
!      On M16C/M32C targets, the ‘function_vector’ attribute declares a
       special page subroutine call function.  Use of this attribute
       reduces the code size by 2 bytes for each call generated to the
       subroutine.  The argument to the attribute is the vector number
       entry from the special page vector table which contains the 16
       low-order bits of the subroutine's entry address.  Each vector
!      table has special page number (18 to 255) that is used in ‘jsrs’
       instructions.  Jump addresses of the routines are generated by
       adding 0x0F0000 (in case of M16C targets) or 0xFF0000 (in case of
       M32C targets), to the 2-byte addresses set in the vector table.
*************** These function attributes are supported
*** 38060,38066 ****
       0x0FFFFF (for M16C) and 0xFF0000 to 0xFFFFFF (for M32C).
  
       In the following example 2 bytes are saved for each call to
!      function 'foo'.
  
            void foo (void) __attribute__((function_vector(0x18)));
            void foo (void)
--- 38069,38075 ----
       0x0FFFFF (for M16C) and 0xFF0000 to 0xFFFFFF (for M32C).
  
       In the following example 2 bytes are saved for each call to
!      function ‘foo’.
  
            void foo (void) __attribute__((function_vector(0x18)));
            void foo (void)
*************** These function attributes are supported
*** 38077,38083 ****
  
       This attribute is ignored for R8C target.
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 38086,38092 ----
  
       This attribute is ignored for R8C target.
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** File: gcc.info,  Node: M32R/D Function A
*** 38091,38121 ****
  
  These function attributes are supported by the M32R/D back end:
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
       attribute is present.
  
! 'model (MODEL-NAME)'
  
       On the M32R/D, use this attribute to set the addressability of an
       object, and of the code generated for a function.  The identifier
!      MODEL-NAME is one of 'small', 'medium', or 'large', representing
       each of the code models.
  
       Small model objects live in the lower 16MB of memory (so that their
!      addresses can be loaded with the 'ld24' instruction), and are
!      callable with the 'bl' instruction.
  
       Medium model objects may live anywhere in the 32-bit address space
!      (the compiler generates 'seth/add3' instructions to load their
!      addresses), and are callable with the 'bl' instruction.
  
       Large model objects may live anywhere in the 32-bit address space
!      (the compiler generates 'seth/add3' instructions to load their
!      addresses), and may not be reachable with the 'bl' instruction (the
!      compiler generates the much slower 'seth/add3/jl' instruction
       sequence).
  
  
--- 38100,38130 ----
  
  These function attributes are supported by the M32R/D back end:
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
       attribute is present.
  
! ‘model (MODEL-NAME)’
  
       On the M32R/D, use this attribute to set the addressability of an
       object, and of the code generated for a function.  The identifier
!      MODEL-NAME is one of ‘small’, ‘medium’, or ‘large’, representing
       each of the code models.
  
       Small model objects live in the lower 16MB of memory (so that their
!      addresses can be loaded with the ‘ld24’ instruction), and are
!      callable with the ‘bl’ instruction.
  
       Medium model objects may live anywhere in the 32-bit address space
!      (the compiler generates ‘seth/add3’ instructions to load their
!      addresses), and are callable with the ‘bl’ instruction.
  
       Large model objects may live anywhere in the 32-bit address space
!      (the compiler generates ‘seth/add3’ instructions to load their
!      addresses), and may not be reachable with the ‘bl’ instruction (the
!      compiler generates the much slower ‘seth/add3/jl’ instruction
       sequence).
  
  
*************** File: gcc.info,  Node: m68k Function Att
*** 38126,38144 ****
  
  These function attributes are supported by the m68k back end:
  
! 'interrupt'
! 'interrupt_handler'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
       attribute is present.  Either name may be used.
  
! '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.
  
  
--- 38135,38153 ----
  
  These function attributes are supported by the m68k back end:
  
! ‘interrupt’
! ‘interrupt_handler’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
       attribute is present.  Either name may be used.
  
! ‘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.
  
  
*************** File: gcc.info,  Node: MCORE Function At
*** 38149,38162 ****
  
  These function attributes are supported by the MCORE back end:
  
! 'naked'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
  
--- 38158,38171 ----
  
  These function attributes are supported by the MCORE back end:
  
! ‘naked’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
  
*************** File: gcc.info,  Node: MicroBlaze Functi
*** 38167,38173 ****
  
  These function attributes are supported on MicroBlaze targets:
  
! 'save_volatiles'
       Use this attribute to indicate that the function is an interrupt
       handler.  All volatile registers (in addition to non-volatile
       registers) are saved in the function prologue.  If the function is
--- 38176,38182 ----
  
  These function attributes are supported on MicroBlaze targets:
  
! ‘save_volatiles’
       Use this attribute to indicate that the function is an interrupt
       handler.  All volatile registers (in addition to non-volatile
       registers) are saved in the function prologue.  If the function is
*************** These function attributes are supported
*** 38175,38197 ****
       normal function return is generated instead of a return from
       interrupt.
  
! 'break_handler'
       Use this attribute to indicate that the specified function is a
       break handler.  The compiler generates function entry and exit
       sequences suitable for use in an break handler when this attribute
!      is present.  The return from 'break_handler' is done through the
!      'rtbd' instead of 'rtsd'.
  
            void f () __attribute__ ((break_handler));
  
! 'interrupt_handler'
! 'fast_interrupt'
       These attributes indicate that the specified function is an
!      interrupt handler.  Use the 'fast_interrupt' attribute to indicate
       handlers used in low-latency interrupt mode, and
!      'interrupt_handler' for interrupts that do not use low-latency
       handlers.  In both cases, GCC emits appropriate prologue code and
!      generates a return from the handler using 'rtid' instead of 'rtsd'.
  
  
  File: gcc.info,  Node: Microsoft Windows Function Attributes,  Next: MIPS Function Attributes,  Prev: MicroBlaze Function Attributes,  Up: Function Attributes
--- 38184,38206 ----
       normal function return is generated instead of a return from
       interrupt.
  
! ‘break_handler’
       Use this attribute to indicate that the specified function is a
       break handler.  The compiler generates function entry and exit
       sequences suitable for use in an break handler when this attribute
!      is present.  The return from ‘break_handler’ is done through the
!      ‘rtbd’ instead of ‘rtsd’.
  
            void f () __attribute__ ((break_handler));
  
! ‘interrupt_handler’
! ‘fast_interrupt’
       These attributes indicate that the specified function is an
!      interrupt handler.  Use the ‘fast_interrupt’ attribute to indicate
       handlers used in low-latency interrupt mode, and
!      ‘interrupt_handler’ for interrupts that do not use low-latency
       handlers.  In both cases, GCC emits appropriate prologue code and
!      generates a return from the handler using ‘rtid’ instead of ‘rtsd’.
  
  
  File: gcc.info,  Node: Microsoft Windows Function Attributes,  Next: MIPS Function Attributes,  Prev: MicroBlaze Function Attributes,  Up: Function Attributes
*************** File: gcc.info,  Node: Microsoft Windows
*** 38202,38226 ****
  The following attributes are available on Microsoft Windows and Symbian
  OS targets.
  
! '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.
  
       GCC's default behavior is to emit all inline functions with the
!      'dllexport' attribute.  Since this can cause object file-size
!      bloat, you can use '-fno-keep-inline-dllexport', which tells GCC to
       ignore the attribute for inlined functions unless the
!      '-fkeep-inline-functions' flag is used instead.
  
       The attribute is ignored for undefined symbols.
  
--- 38211,38235 ----
  The following attributes are available on Microsoft Windows and Symbian
  OS targets.
  
! ‘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.
  
       GCC's default behavior is to emit all inline functions with the
!      ‘dllexport’ attribute.  Since this can cause object file-size
!      bloat, you can use ‘-fno-keep-inline-dllexport’, which tells GCC to
       ignore the attribute for inlined functions unless the
!      ‘-fkeep-inline-functions’ flag is used instead.
  
       The attribute is ignored for undefined symbols.
  
*************** OS targets.
*** 38231,38267 ****
  
       For Microsoft Windows targets there are alternative methods for
       including the symbol in the DLL's export table such as using a
!      '.def' file with an 'EXPORTS' section or, with GNU ld, using the
!      '--export-all' linker flag.
  
! 'dllimport'
!      On Microsoft Windows and Symbian OS targets, the 'dllimport'
       attribute causes the compiler to reference a function or variable
       via a global pointer to a pointer that is set up by the DLL
!      exporting the symbol.  The attribute implies 'extern'.  On
       Microsoft Windows targets, the pointer name is formed by combining
!      '_imp__' and the function or variable name.
  
!      You can use '__declspec(dllimport)' as a synonym for '__attribute__
!      ((dllimport))' for compatibility with other compilers.
  
!      On systems that support the 'visibility' attribute, this attribute
       also implies "default" visibility.  It is an error to explicitly
       specify any other visibility.
  
       Currently, the attribute is ignored for inlined functions.  If the
       attribute is applied to a symbol _definition_, an error is
!      reported.  If a symbol previously declared 'dllimport' is later
       defined, the attribute is ignored in subsequent references, and a
       warning is emitted.  The attribute is also overridden by a
!      subsequent declaration as 'dllexport'.
  
       When applied to C++ classes, the attribute marks non-inlined member
       functions and static data members as imports.  However, the
       attribute is ignored for virtual methods to allow creation of
       vtables using thunks.
  
!      On the SH Symbian OS target the 'dllimport' attribute also has
       another affect--it can cause the vtable and run-time type
       information for a class to be exported.  This happens when the
       class has a dllimported constructor or a non-inline, non-pure
--- 38240,38276 ----
  
       For Microsoft Windows targets there are alternative methods for
       including the symbol in the DLL's export table such as using a
!      ‘.def’ file with an ‘EXPORTS’ section or, with GNU ld, using the
!      ‘--export-all’ linker flag.
  
! ‘dllimport’
!      On Microsoft Windows and Symbian OS targets, the ‘dllimport’
       attribute causes the compiler to reference a function or variable
       via a global pointer to a pointer that is set up by the DLL
!      exporting the symbol.  The attribute implies ‘extern’.  On
       Microsoft Windows targets, the pointer name is formed by combining
!      ‘_imp__’ and the function or variable name.
  
!      You can use ‘__declspec(dllimport)’ as a synonym for ‘__attribute__
!      ((dllimport))’ for compatibility with other compilers.
  
!      On systems that support the ‘visibility’ attribute, this attribute
       also implies "default" visibility.  It is an error to explicitly
       specify any other visibility.
  
       Currently, the attribute is ignored for inlined functions.  If the
       attribute is applied to a symbol _definition_, an error is
!      reported.  If a symbol previously declared ‘dllimport’ is later
       defined, the attribute is ignored in subsequent references, and a
       warning is emitted.  The attribute is also overridden by a
!      subsequent declaration as ‘dllexport’.
  
       When applied to C++ classes, the attribute marks non-inlined member
       functions and static data members as imports.  However, the
       attribute is ignored for virtual methods to allow creation of
       vtables using thunks.
  
!      On the SH Symbian OS target the ‘dllimport’ attribute also has
       another affect--it can cause the vtable and run-time type
       information for a class to be exported.  This happens when the
       class has a dllimported constructor or a non-inline, non-pure
*************** OS targets.
*** 38269,38289 ****
       also has an inline constructor or destructor and has a key function
       that is defined in the current translation unit.
  
!      For Microsoft Windows targets the use of the 'dllimport' attribute
       on functions is not necessary, but provides a small performance
       benefit by eliminating a thunk in the DLL.  The use of the
!      'dllimport' attribute on imported variables can 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.
  
  
  File: gcc.info,  Node: MIPS Function Attributes,  Next: MSP430 Function Attributes,  Prev: Microsoft Windows Function Attributes,  Up: Function Attributes
--- 38278,38298 ----
       also has an inline constructor or destructor and has a key function
       that is defined in the current translation unit.
  
!      For Microsoft Windows targets the use of the ‘dllimport’ attribute
       on functions is not necessary, but provides a small performance
       benefit by eliminating a thunk in the DLL.  The use of the
!      ‘dllimport’ attribute on imported variables can 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.
  
  
  File: gcc.info,  Node: MIPS Function Attributes,  Next: MSP430 Function Attributes,  Prev: Microsoft Windows Function Attributes,  Up: Function Attributes
*************** File: gcc.info,  Node: MIPS Function Att
*** 38293,38299 ****
  
  These function attributes are supported by the MIPS back end:
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 38302,38308 ----
  
  These function attributes are supported by the MIPS back end:
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** These function attributes are supported
*** 38301,38331 ****
       interrupt attribute which allows the interrupt mode to be
       described.  By default GCC assumes the external interrupt
       controller (EIC) mode is in use, this can be explicitly set using
!      'eic'.  When interrupts are non-masked then the requested Interrupt
       Priority Level (IPL) is copied to the current IPL which has the
       effect of only enabling higher priority interrupts.  To use
       vectored interrupt mode use the argument
!      'vector=[sw0|sw1|hw0|hw1|hw2|hw3|hw4|hw5]', this will change the
       behavior of the non-masked interrupt support and GCC will arrange
       to mask all interrupts from sw0 up to and including the specified
       interrupt vector.
  
       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.  An optional argument
!           'intstack' is supported to indicate that the shadow register
            set contains a valid stack pointer.
  
!      '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 ();
--- 38310,38340 ----
       interrupt attribute which allows the interrupt mode to be
       described.  By default GCC assumes the external interrupt
       controller (EIC) mode is in use, this can be explicitly set using
!      ‘eic’.  When interrupts are non-masked then the requested Interrupt
       Priority Level (IPL) is copied to the current IPL which has the
       effect of only enabling higher priority interrupts.  To use
       vectored interrupt mode use the argument
!      ‘vector=[sw0|sw1|hw0|hw1|hw2|hw3|hw4|hw5]’, this will change the
       behavior of the non-masked interrupt support and GCC will arrange
       to mask all interrupts from sw0 up to and including the specified
       interrupt vector.
  
       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.  An optional argument
!           ‘intstack’ is supported to indicate that the shadow register
            set contains a valid stack pointer.
  
!      ‘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 ();
*************** These function attributes are supported
*** 38344,38404 ****
            void __attribute__ ((interrupt("eic"))) v8 ();
            void __attribute__ ((interrupt("vector=hw3"))) v9 ();
  
! 'long_call'
! 'short_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 'short_call' and 'near'
       attributes are synonyms, and have the opposite effect; they specify
!      that non-PIC calls should be made using the more efficient 'jal'
       instruction.
  
! 'mips16'
! 'nomips16'
  
!      On MIPS targets, you can use the 'mips16' and 'nomips16' function
       attributes to locally select or turn off MIPS16 code generation.  A
!      function with the 'mips16' attribute is emitted as MIPS16 code,
       while MIPS16 code generation is disabled for functions with the
!      'nomips16' attribute.  These attributes override the '-mips16' and
!      '-mno-mips16' options on the command line (*note MIPS Options::).
  
       When compiling files containing mixed MIPS16 and non-MIPS16 code,
!      the preprocessor symbol '__mips16' reflects the setting on the
       command line, not that within individual functions.  Mixed MIPS16
       and non-MIPS16 code may interact badly with some GCC extensions
!      such as '__builtin_apply' (*note Constructing Calls::).
  
! 'micromips, MIPS'
! 'nomicromips, MIPS'
  
!      On MIPS targets, you can use the 'micromips' and 'nomicromips'
       function attributes to locally select or turn off microMIPS code
!      generation.  A function with the 'micromips' attribute is emitted
       as microMIPS code, while microMIPS code generation is disabled for
!      functions with the 'nomicromips' attribute.  These attributes
!      override the '-mmicromips' and '-mno-micromips' options on the
       command line (*note MIPS Options::).
  
       When compiling files containing mixed microMIPS and non-microMIPS
!      code, the preprocessor symbol '__mips_micromips' reflects the
       setting on the command line, not that within individual functions.
       Mixed microMIPS and non-microMIPS code may interact badly with some
!      GCC extensions such as '__builtin_apply' (*note Constructing
       Calls::).
  
! 'nocompression'
!      On MIPS targets, you can use the 'nocompression' function attribute
       to locally turn off MIPS16 and microMIPS code generation.  This
!      attribute overrides the '-mips16' and '-mmicromips' options on the
       command line (*note MIPS Options::).
  
! 'use_hazard_barrier_return'
       This function attribute instructs the compiler to generate a hazard
       barrier return that clears all execution and instruction hazards
       while returning, instead of generating a normal return instruction.
--- 38353,38413 ----
            void __attribute__ ((interrupt("eic"))) v8 ();
            void __attribute__ ((interrupt("vector=hw3"))) v9 ();
  
! ‘long_call’
! ‘short_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 ‘short_call’ and ‘near’
       attributes are synonyms, and have the opposite effect; they specify
!      that non-PIC calls should be made using the more efficient ‘jal’
       instruction.
  
! ‘mips16’
! ‘nomips16’
  
!      On MIPS targets, you can use the ‘mips16’ and ‘nomips16’ function
       attributes to locally select or turn off MIPS16 code generation.  A
!      function with the ‘mips16’ attribute is emitted as MIPS16 code,
       while MIPS16 code generation is disabled for functions with the
!      ‘nomips16’ attribute.  These attributes override the ‘-mips16’ and
!      ‘-mno-mips16’ options on the command line (*note MIPS Options::).
  
       When compiling files containing mixed MIPS16 and non-MIPS16 code,
!      the preprocessor symbol ‘__mips16’ reflects the setting on the
       command line, not that within individual functions.  Mixed MIPS16
       and non-MIPS16 code may interact badly with some GCC extensions
!      such as ‘__builtin_apply’ (*note Constructing Calls::).
  
! ‘micromips, MIPS’
! ‘nomicromips, MIPS’
  
!      On MIPS targets, you can use the ‘micromips’ and ‘nomicromips’
       function attributes to locally select or turn off microMIPS code
!      generation.  A function with the ‘micromips’ attribute is emitted
       as microMIPS code, while microMIPS code generation is disabled for
!      functions with the ‘nomicromips’ attribute.  These attributes
!      override the ‘-mmicromips’ and ‘-mno-micromips’ options on the
       command line (*note MIPS Options::).
  
       When compiling files containing mixed microMIPS and non-microMIPS
!      code, the preprocessor symbol ‘__mips_micromips’ reflects the
       setting on the command line, not that within individual functions.
       Mixed microMIPS and non-microMIPS code may interact badly with some
!      GCC extensions such as ‘__builtin_apply’ (*note Constructing
       Calls::).
  
! ‘nocompression’
!      On MIPS targets, you can use the ‘nocompression’ function attribute
       to locally turn off MIPS16 and microMIPS code generation.  This
!      attribute overrides the ‘-mips16’ and ‘-mmicromips’ options on the
       command line (*note MIPS Options::).
  
! ‘use_hazard_barrier_return’
       This function attribute instructs the compiler to generate a hazard
       barrier return that clears all execution and instruction hazards
       while returning, instead of generating a normal return instruction.
*************** File: gcc.info,  Node: MSP430 Function A
*** 38411,38427 ****
  
  These function attributes are supported by the MSP430 back end:
  
! 'critical'
       Critical functions disable interrupts upon entry and restore the
       previous interrupt state upon exit.  Critical functions cannot also
!      have the 'naked', 'reentrant' or 'interrupt' attributes.
  
       The MSP430 hardware ensures that interrupts are disabled on entry
!      to 'interrupt' functions, and restores the previous interrupt state
!      on exit.  The 'critical' attribute is therefore redundant on
!      'interrupt' functions.
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 38420,38436 ----
  
  These function attributes are supported by the MSP430 back end:
  
! ‘critical’
       Critical functions disable interrupts upon entry and restore the
       previous interrupt state upon exit.  Critical functions cannot also
!      have the ‘naked’, ‘reentrant’ or ‘interrupt’ attributes.
  
       The MSP430 hardware ensures that interrupts are disabled on entry
!      to ‘interrupt’ functions, and restores the previous interrupt state
!      on exit.  The ‘critical’ attribute is therefore redundant on
!      ‘interrupt’ functions.
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** These function attributes are supported
*** 38433,38465 ****
       this handler should be assigned.  If the argument is a name it is
       treated as a symbolic name for the vector slot.  These names should
       match up with appropriate entries in the linker script.  By default
!      the names 'watchdog' for vector 26, 'nmi' for vector 30 and 'reset'
       for vector 31 are recognized.
  
! 'naked'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! 'reentrant'
       Reentrant functions disable interrupts upon entry and enable them
!      upon exit.  Reentrant functions cannot also have the 'naked' or
!      'critical' attributes.  They can have the 'interrupt' attribute.
  
! 'wakeup'
       This attribute only applies to interrupt functions.  It is silently
       ignored if applied to a non-interrupt function.  A wakeup interrupt
       function will rouse the processor from any low-power state that it
       might be in when the function exits.
  
! 'lower'
! 'upper'
! 'either'
       On the MSP430 target these attributes can be used to specify
       whether the function or variable should be placed into low memory,
       high memory, or the placement should be left to the linker to
--- 38442,38474 ----
       this handler should be assigned.  If the argument is a name it is
       treated as a symbolic name for the vector slot.  These names should
       match up with appropriate entries in the linker script.  By default
!      the names ‘watchdog’ for vector 26, ‘nmi’ for vector 30 and ‘reset’
       for vector 31 are recognized.
  
! ‘naked’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! ‘reentrant’
       Reentrant functions disable interrupts upon entry and enable them
!      upon exit.  Reentrant functions cannot also have the ‘naked’ or
!      ‘critical’ attributes.  They can have the ‘interrupt’ attribute.
  
! ‘wakeup’
       This attribute only applies to interrupt functions.  It is silently
       ignored if applied to a non-interrupt function.  A wakeup interrupt
       function will rouse the processor from any low-power state that it
       might be in when the function exits.
  
! ‘lower’
! ‘upper’
! ‘either’
       On the MSP430 target these attributes can be used to specify
       whether the function or variable should be placed into low memory,
       high memory, or the placement should be left to the linker to
*************** These function attributes are supported
*** 38467,38488 ****
       MSP430X architecture in the large memory model.
  
       The attributes work in conjunction with a linker script that has
!      been augmented to specify where to place sections with a '.lower'
!      and a '.upper' prefix.  So, for example, as well as placing the
!      '.data' section, the script also specifies the placement of a
!      '.lower.data' and a '.upper.data' section.  The intention is that
!      'lower' sections are placed into a small but easier to access
       memory region and the upper sections are placed into a larger, but
       slower to access, region.
  
!      The 'either' attribute is special.  It tells the linker to place
!      the object into the corresponding 'lower' section if there is room
       for it.  If there is insufficient room then the object is placed
!      into the corresponding 'upper' section instead.  Note that the
       placement algorithm is not very sophisticated.  It does not attempt
!      to find an optimal packing of the 'lower' sections.  It just makes
       one pass over the objects and does the best that it can.  Using the
!      '-ffunction-sections' and '-fdata-sections' command-line options
       can help the packing, however, since they produce smaller, easier
       to pack regions.
  
--- 38476,38497 ----
       MSP430X architecture in the large memory model.
  
       The attributes work in conjunction with a linker script that has
!      been augmented to specify where to place sections with a ‘.lower’
!      and a ‘.upper’ prefix.  So, for example, as well as placing the
!      ‘.data’ section, the script also specifies the placement of a
!      ‘.lower.data’ and a ‘.upper.data’ section.  The intention is that
!      ‘lower’ sections are placed into a small but easier to access
       memory region and the upper sections are placed into a larger, but
       slower to access, region.
  
!      The ‘either’ attribute is special.  It tells the linker to place
!      the object into the corresponding ‘lower’ section if there is room
       for it.  If there is insufficient room then the object is placed
!      into the corresponding ‘upper’ section instead.  Note that the
       placement algorithm is not very sophisticated.  It does not attempt
!      to find an optimal packing of the ‘lower’ sections.  It just makes
       one pass over the objects and does the best that it can.  Using the
!      ‘-ffunction-sections’ and ‘-fdata-sections’ command-line options
       can help the packing, however, since they produce smaller, easier
       to pack regions.
  
*************** File: gcc.info,  Node: NDS32 Function At
*** 38494,38543 ****
  
  These function attributes are supported by the NDS32 back end:
  
! 'exception'
       Use this attribute on the NDS32 target to indicate that the
       specified function is an exception handler.  The compiler will
       generate corresponding sections for use in an exception handler.
  
! 'interrupt'
       On NDS32 target, this attribute indicates that the specified
       function is an interrupt handler.  The compiler generates
       corresponding sections for use in an interrupt handler.  You can
       use the following attributes to modify the behavior:
!      'nested'
            This interrupt service routine is interruptible.
!      'not_nested'
            This interrupt service routine is not interruptible.
!      'nested_ready'
            This interrupt service routine is interruptible after
!           'PSW.GIE' (global interrupt enable) is set.  This allows
            interrupt service routine to finish some short critical code
            before enabling interrupts.
!      'save_all'
            The system will help save all registers into stack before
            entering interrupt handler.
!      'partial_save'
            The system will help save caller registers into stack before
            entering interrupt handler.
  
! 'naked'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! 'reset'
       Use this attribute on the NDS32 target to indicate that the
       specified function is a reset handler.  The compiler will generate
       corresponding sections for use in a reset handler.  You can use the
       following attributes to provide extra exception handling:
!      'nmi'
            Provide a user-defined function to handle NMI exception.
!      'warm'
            Provide a user-defined function to handle warm reset
            exception.
  
--- 38503,38552 ----
  
  These function attributes are supported by the NDS32 back end:
  
! ‘exception’
       Use this attribute on the NDS32 target to indicate that the
       specified function is an exception handler.  The compiler will
       generate corresponding sections for use in an exception handler.
  
! ‘interrupt’
       On NDS32 target, this attribute indicates that the specified
       function is an interrupt handler.  The compiler generates
       corresponding sections for use in an interrupt handler.  You can
       use the following attributes to modify the behavior:
!      ‘nested’
            This interrupt service routine is interruptible.
!      ‘not_nested’
            This interrupt service routine is not interruptible.
!      ‘nested_ready’
            This interrupt service routine is interruptible after
!           ‘PSW.GIE’ (global interrupt enable) is set.  This allows
            interrupt service routine to finish some short critical code
            before enabling interrupts.
!      ‘save_all’
            The system will help save all registers into stack before
            entering interrupt handler.
!      ‘partial_save’
            The system will help save caller registers into stack before
            entering interrupt handler.
  
! ‘naked’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! ‘reset’
       Use this attribute on the NDS32 target to indicate that the
       specified function is a reset handler.  The compiler will generate
       corresponding sections for use in a reset handler.  You can use the
       following attributes to provide extra exception handling:
!      ‘nmi’
            Provide a user-defined function to handle NMI exception.
!      ‘warm’
            Provide a user-defined function to handle warm reset
            exception.
  
*************** File: gcc.info,  Node: Nios II Function
*** 38549,38572 ****
  
  These function attributes are supported by the Nios II back end:
  
! 'target (OPTIONS)'
       As discussed in *note Common Function Attributes::, this attribute
       allows specification of target-specific compilation options.
  
       When compiling for Nios II, the following options are allowed:
  
!      'custom-INSN=N'
!      'no-custom-INSN'
!           Each 'custom-INSN=N' attribute locally enables use of a custom
            instruction with encoding N when generating code that uses
!           INSN.  Similarly, 'no-custom-INSN' locally inhibits use of the
            custom instruction INSN.  These target attributes correspond
!           to the '-mcustom-INSN=N' and '-mno-custom-INSN' command-line
            options, and support the same set of INSN keywords.  *Note
            Nios II Options::, for more information.
  
!      'custom-fpu-cfg=NAME'
!           This attribute corresponds to the '-mcustom-fpu-cfg=NAME'
            command-line option, to select a predefined set of custom
            instructions named NAME.  *Note Nios II Options::, for more
            information.
--- 38558,38581 ----
  
  These function attributes are supported by the Nios II back end:
  
! ‘target (OPTIONS)’
       As discussed in *note Common Function Attributes::, this attribute
       allows specification of target-specific compilation options.
  
       When compiling for Nios II, the following options are allowed:
  
!      ‘custom-INSN=N’
!      ‘no-custom-INSN’
!           Each ‘custom-INSN=N’ attribute locally enables use of a custom
            instruction with encoding N when generating code that uses
!           INSN.  Similarly, ‘no-custom-INSN’ locally inhibits use of the
            custom instruction INSN.  These target attributes correspond
!           to the ‘-mcustom-INSN=N’ and ‘-mno-custom-INSN’ command-line
            options, and support the same set of INSN keywords.  *Note
            Nios II Options::, for more information.
  
!      ‘custom-fpu-cfg=NAME’
!           This attribute corresponds to the ‘-mcustom-fpu-cfg=NAME’
            command-line option, to select a predefined set of custom
            instructions named NAME.  *Note Nios II Options::, for more
            information.
*************** File: gcc.info,  Node: Nvidia PTX Functi
*** 38579,38591 ****
  
  These function attributes are supported by the Nvidia PTX back end:
  
! 'kernel'
       This attribute indicates that the corresponding function should be
       compiled as a kernel function, which can be invoked from the host
       via the CUDA RT library.  By default functions are only callable
       only from other PTX functions.
  
!      Kernel functions must have 'void' return type.
  
  
  File: gcc.info,  Node: PowerPC Function Attributes,  Next: RISC-V Function Attributes,  Prev: Nvidia PTX Function Attributes,  Up: Function Attributes
--- 38588,38600 ----
  
  These function attributes are supported by the Nvidia PTX back end:
  
! ‘kernel’
       This attribute indicates that the corresponding function should be
       compiled as a kernel function, which can be invoked from the host
       via the CUDA RT library.  By default functions are only callable
       only from other PTX functions.
  
!      Kernel functions must have ‘void’ return type.
  
  
  File: gcc.info,  Node: PowerPC Function Attributes,  Next: RISC-V Function Attributes,  Prev: Nvidia PTX Function Attributes,  Up: Function Attributes
*************** File: gcc.info,  Node: PowerPC Function
*** 38595,38759 ****
  
  These function attributes are supported by the PowerPC back end:
  
! 'longcall'
! 'shortcall'
!      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 the '#pragma longcall' setting.
  
       *Note RS/6000 and PowerPC Options::, for more information on
       whether long calls are necessary.
  
! 'target (OPTIONS)'
       As discussed in *note Common Function Attributes::, this attribute
       allows specification of target-specific compilation options.
  
       On the PowerPC, the following options are allowed:
  
!      'altivec'
!      'no-altivec'
            Generate code that uses (does not use) AltiVec instructions.
            In 32-bit code, you cannot enable AltiVec instructions unless
!           '-mabi=altivec' is used on the command line.
  
!      'cmpb'
!      'no-cmpb'
            Generate code that uses (does not use) the compare bytes
            instruction implemented on the POWER6 processor and other
            processors that support the PowerPC V2.05 architecture.
  
!      'dlmzb'
!      'no-dlmzb'
            Generate code that uses (does not use) the string-search
!           'dlmzb' instruction on the IBM 405, 440, 464 and 476
            processors.  This instruction is generated by default when
            targeting those processors.
  
!      'fprnd'
!      'no-fprnd'
            Generate code that uses (does not use) the FP round to integer
            instructions implemented on the POWER5+ processor and other
            processors that support the PowerPC V2.03 architecture.
  
!      'hard-dfp'
!      'no-hard-dfp'
            Generate code that uses (does not use) the decimal
            floating-point instructions implemented on some POWER
            processors.
  
!      'isel'
!      'no-isel'
            Generate code that uses (does not use) ISEL instruction.
  
!      'mfcrf'
!      'no-mfcrf'
            Generate code that uses (does not use) the move from condition
            register field instruction implemented on the POWER4 processor
            and other processors that support the PowerPC V2.01
            architecture.
  
!      'mulhw'
!      'no-mulhw'
            Generate code that uses (does not use) the half-word multiply
            and multiply-accumulate instructions on the IBM 405, 440, 464
            and 476 processors.  These instructions are generated by
            default when targeting those processors.
  
!      'multiple'
!      'no-multiple'
            Generate code that uses (does not use) the load multiple word
            instructions and the store multiple word instructions.
  
!      'update'
!      'no-update'
            Generate code that uses (does not use) the load or store
            instructions that update the base register to the address of
            the calculated memory location.
  
!      'popcntb'
!      'no-popcntb'
            Generate code that uses (does not use) the popcount and
            double-precision FP reciprocal estimate instruction
            implemented on the POWER5 processor and other processors that
            support the PowerPC V2.02 architecture.
  
!      'popcntd'
!      'no-popcntd'
            Generate code that uses (does not use) the popcount
            instruction implemented on the POWER7 processor and other
            processors that support the PowerPC V2.06 architecture.
  
!      'powerpc-gfxopt'
!      'no-powerpc-gfxopt'
            Generate code that uses (does not use) the optional PowerPC
            architecture instructions in the Graphics group, including
            floating-point select.
  
!      'powerpc-gpopt'
!      'no-powerpc-gpopt'
            Generate code that uses (does not use) the optional PowerPC
            architecture instructions in the General Purpose group,
            including floating-point square root.
  
!      'recip-precision'
!      'no-recip-precision'
            Assume (do not assume) that the reciprocal estimate
            instructions provide higher-precision estimates than is
            mandated by the PowerPC ABI.
  
!      'string'
!      'no-string'
            Generate code that uses (does not use) the load string
            instructions and the store string word instructions to save
            multiple registers and do small block moves.
  
!      'vsx'
!      'no-vsx'
            Generate code that uses (does not use) vector/scalar (VSX)
            instructions, and also enable the use of built-in functions
            that allow more direct access to the VSX instruction set.  In
            32-bit code, you cannot enable VSX or AltiVec instructions
!           unless '-mabi=altivec' is used on the command line.
  
!      'friz'
!      'no-friz'
!           Generate (do not generate) the 'friz' instruction when the
!           '-funsafe-math-optimizations' option is used to optimize
            rounding a floating-point value to 64-bit integer and back to
!           floating point.  The 'friz' instruction does not return the
            same value if the floating-point number is too large to fit in
            an integer.
  
!      'avoid-indexed-addresses'
!      'no-avoid-indexed-addresses'
            Generate code that tries to avoid (not avoid) the use of
            indexed load or store instructions.
  
!      'paired'
!      'no-paired'
            Generate code that uses (does not use) the generation of
            PAIRED simd instructions.
  
!      'longcall'
!      'no-longcall'
            Generate code that assumes (does not assume) that all calls
            are far away so that a longer more expensive calling sequence
            is required.
  
!      'cpu=CPU'
            Specify the architecture to generate code for when compiling
!           the function.  If you select the 'target("cpu=power7")'
            attribute when generating 32-bit code, VSX and AltiVec
            instructions are not generated unless you use the
!           '-mabi=altivec' option on the command line.
  
!      'tune=TUNE'
            Specify the architecture to tune for when compiling the
!           function.  If you do not specify the 'target("tune=TUNE")'
!           attribute and you do specify the 'target("cpu=CPU")'
            attribute, compilation tunes for the CPU architecture, and not
            the default tuning specified on the command line.
  
--- 38604,38768 ----
  
  These function attributes are supported by the PowerPC back end:
  
! ‘longcall’
! ‘shortcall’
!      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 the ‘#pragma longcall’ setting.
  
       *Note RS/6000 and PowerPC Options::, for more information on
       whether long calls are necessary.
  
! ‘target (OPTIONS)’
       As discussed in *note Common Function Attributes::, this attribute
       allows specification of target-specific compilation options.
  
       On the PowerPC, the following options are allowed:
  
!      ‘altivec’
!      ‘no-altivec’
            Generate code that uses (does not use) AltiVec instructions.
            In 32-bit code, you cannot enable AltiVec instructions unless
!           ‘-mabi=altivec’ is used on the command line.
  
!      ‘cmpb’
!      ‘no-cmpb’
            Generate code that uses (does not use) the compare bytes
            instruction implemented on the POWER6 processor and other
            processors that support the PowerPC V2.05 architecture.
  
!      ‘dlmzb’
!      ‘no-dlmzb’
            Generate code that uses (does not use) the string-search
!           ‘dlmzb’ instruction on the IBM 405, 440, 464 and 476
            processors.  This instruction is generated by default when
            targeting those processors.
  
!      ‘fprnd’
!      ‘no-fprnd’
            Generate code that uses (does not use) the FP round to integer
            instructions implemented on the POWER5+ processor and other
            processors that support the PowerPC V2.03 architecture.
  
!      ‘hard-dfp’
!      ‘no-hard-dfp’
            Generate code that uses (does not use) the decimal
            floating-point instructions implemented on some POWER
            processors.
  
!      ‘isel’
!      ‘no-isel’
            Generate code that uses (does not use) ISEL instruction.
  
!      ‘mfcrf’
!      ‘no-mfcrf’
            Generate code that uses (does not use) the move from condition
            register field instruction implemented on the POWER4 processor
            and other processors that support the PowerPC V2.01
            architecture.
  
!      ‘mulhw’
!      ‘no-mulhw’
            Generate code that uses (does not use) the half-word multiply
            and multiply-accumulate instructions on the IBM 405, 440, 464
            and 476 processors.  These instructions are generated by
            default when targeting those processors.
  
!      ‘multiple’
!      ‘no-multiple’
            Generate code that uses (does not use) the load multiple word
            instructions and the store multiple word instructions.
  
!      ‘update’
!      ‘no-update’
            Generate code that uses (does not use) the load or store
            instructions that update the base register to the address of
            the calculated memory location.
  
!      ‘popcntb’
!      ‘no-popcntb’
            Generate code that uses (does not use) the popcount and
            double-precision FP reciprocal estimate instruction
            implemented on the POWER5 processor and other processors that
            support the PowerPC V2.02 architecture.
  
!      ‘popcntd’
!      ‘no-popcntd’
            Generate code that uses (does not use) the popcount
            instruction implemented on the POWER7 processor and other
            processors that support the PowerPC V2.06 architecture.
  
!      ‘powerpc-gfxopt’
!      ‘no-powerpc-gfxopt’
            Generate code that uses (does not use) the optional PowerPC
            architecture instructions in the Graphics group, including
            floating-point select.
  
!      ‘powerpc-gpopt’
!      ‘no-powerpc-gpopt’
            Generate code that uses (does not use) the optional PowerPC
            architecture instructions in the General Purpose group,
            including floating-point square root.
  
!      ‘recip-precision’
!      ‘no-recip-precision’
            Assume (do not assume) that the reciprocal estimate
            instructions provide higher-precision estimates than is
            mandated by the PowerPC ABI.
  
!      ‘string’
!      ‘no-string’
            Generate code that uses (does not use) the load string
            instructions and the store string word instructions to save
            multiple registers and do small block moves.
  
!      ‘vsx’
!      ‘no-vsx’
            Generate code that uses (does not use) vector/scalar (VSX)
            instructions, and also enable the use of built-in functions
            that allow more direct access to the VSX instruction set.  In
            32-bit code, you cannot enable VSX or AltiVec instructions
!           unless ‘-mabi=altivec’ is used on the command line.
  
!      ‘friz’
!      ‘no-friz’
!           Generate (do not generate) the ‘friz’ instruction when the
!           ‘-funsafe-math-optimizations’ option is used to optimize
            rounding a floating-point value to 64-bit integer and back to
!           floating point.  The ‘friz’ instruction does not return the
            same value if the floating-point number is too large to fit in
            an integer.
  
!      ‘avoid-indexed-addresses’
!      ‘no-avoid-indexed-addresses’
            Generate code that tries to avoid (not avoid) the use of
            indexed load or store instructions.
  
!      ‘paired’
!      ‘no-paired’
            Generate code that uses (does not use) the generation of
            PAIRED simd instructions.
  
!      ‘longcall’
!      ‘no-longcall’
            Generate code that assumes (does not assume) that all calls
            are far away so that a longer more expensive calling sequence
            is required.
  
!      ‘cpu=CPU’
            Specify the architecture to generate code for when compiling
!           the function.  If you select the ‘target("cpu=power7")’
            attribute when generating 32-bit code, VSX and AltiVec
            instructions are not generated unless you use the
!           ‘-mabi=altivec’ option on the command line.
  
!      ‘tune=TUNE’
            Specify the architecture to tune for when compiling the
!           function.  If you do not specify the ‘target("tune=TUNE")’
!           attribute and you do specify the ‘target("cpu=CPU")’
            attribute, compilation tunes for the CPU architecture, and not
            the default tuning specified on the command line.
  
*************** File: gcc.info,  Node: RISC-V Function A
*** 38769,38785 ****
  
  These function attributes are supported by the RISC-V back end:
  
! 'naked'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 38778,38794 ----
  
  These function attributes are supported by the RISC-V back end:
  
! ‘naked’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** These function attributes are supported
*** 38790,38798 ****
  
            void f (void) __attribute__ ((interrupt ("user")));
  
!      Permissible values for this parameter are 'user', 'supervisor', and
!      'machine'.  If there is no parameter, then it defaults to
!      'machine'.
  
  
  File: gcc.info,  Node: RL78 Function Attributes,  Next: RX Function Attributes,  Prev: RISC-V Function Attributes,  Up: Function Attributes
--- 38799,38807 ----
  
            void f (void) __attribute__ ((interrupt ("user")));
  
!      Permissible values for this parameter are ‘user’, ‘supervisor’, and
!      ‘machine’.  If there is no parameter, then it defaults to
!      ‘machine’.
  
  
  File: gcc.info,  Node: RL78 Function Attributes,  Next: RX Function Attributes,  Prev: RISC-V Function Attributes,  Up: Function Attributes
*************** File: gcc.info,  Node: RL78 Function Att
*** 38802,38826 ****
  
  These function attributes are supported by the RL78 back end:
  
! 'interrupt'
! 'brk_interrupt'
       These attributes indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
       attribute is present.
  
!      Use 'brk_interrupt' instead of 'interrupt' for handlers intended to
!      be used with the 'BRK' opcode (i.e. those that must end with 'RETB'
!      instead of 'RETI').
  
! 'naked'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
  
--- 38811,38835 ----
  
  These function attributes are supported by the RL78 back end:
  
! ‘interrupt’
! ‘brk_interrupt’
       These attributes indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
       attribute is present.
  
!      Use ‘brk_interrupt’ instead of ‘interrupt’ for handlers intended to
!      be used with the ‘BRK’ opcode (i.e. those that must end with ‘RETB’
!      instead of ‘RETI’).
  
! ‘naked’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
  
*************** File: gcc.info,  Node: RX Function Attri
*** 38831,38843 ****
  
  These function attributes are supported by the RX back end:
  
! 'fast_interrupt'
       Use this attribute on the RX port 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'.
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 38840,38852 ----
  
  These function attributes are supported by the RX back end:
  
! ‘fast_interrupt’
       Use this attribute on the RX port 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’.
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** These function attributes are supported
*** 38847,38853 ****
       as arguments to the attribute, as well as naming an alternate table
       name.  Parameters are handled sequentially, so one handler can be
       assigned to multiple entries in multiple tables.  One may also pass
!      the magic string '"$default"' which causes the function to be used
       for any unfilled slots in the current table.
  
       This example shows a simple assignment of a function to one vector
--- 38856,38862 ----
       as arguments to the attribute, as well as naming an alternate table
       name.  Parameters are handled sequentially, so one handler can be
       assigned to multiple entries in multiple tables.  One may also pass
!      the magic string ‘"$default"’ which causes the function to be used
       for any unfilled slots in the current table.
  
       This example shows a simple assignment of a function to one vector
*************** These function attributes are supported
*** 38857,38881 ****
  
       This example assigns a function to two slots in the default table
       (using preprocessor macros defined elsewhere) and makes it the
!      default for the 'dct' table:
            void __attribute__ ((interrupt (RXD1_VECT,RXD2_VECT,"dct","$default")))
            	txd1_handler ();
  
! 'naked'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! 'vector'
!      This RX attribute is similar to the 'interrupt' attribute,
       including its parameters, but does not make the function an
       interrupt-handler type function (i.e. it retains the normal C
!      function calling ABI). See the 'interrupt' attribute for a
       description of its arguments.
  
  
--- 38866,38890 ----
  
       This example assigns a function to two slots in the default table
       (using preprocessor macros defined elsewhere) and makes it the
!      default for the ‘dct’ table:
            void __attribute__ ((interrupt (RXD1_VECT,RXD2_VECT,"dct","$default")))
            	txd1_handler ();
  
! ‘naked’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! ‘vector’
!      This RX attribute is similar to the ‘interrupt’ attribute,
       including its parameters, but does not make the function an
       interrupt-handler type function (i.e. it retains the normal C
!      function calling ABI). See the ‘interrupt’ attribute for a
       description of its arguments.
  
  
*************** File: gcc.info,  Node: S/390 Function At
*** 38886,38897 ****
  
  These function attributes are supported on the S/390:
  
! 'hotpatch (HALFWORDS-BEFORE-FUNCTION-LABEL,HALFWORDS-AFTER-FUNCTION-LABEL)'
  
       On S/390 System z targets, you can use this function attribute to
       make GCC generate a "hot-patching" function prologue.  If the
!      '-mhotpatch=' command-line option is used at the same time, the
!      'hotpatch' attribute takes precedence.  The first of the two
       arguments specifies the number of halfwords to be added before the
       function label.  A second argument can be used to specify the
       number of halfwords to be added after the function label.  For both
--- 38895,38906 ----
  
  These function attributes are supported on the S/390:
  
! ‘hotpatch (HALFWORDS-BEFORE-FUNCTION-LABEL,HALFWORDS-AFTER-FUNCTION-LABEL)’
  
       On S/390 System z targets, you can use this function attribute to
       make GCC generate a "hot-patching" function prologue.  If the
!      ‘-mhotpatch=’ command-line option is used at the same time, the
!      ‘hotpatch’ attribute takes precedence.  The first of the two
       arguments specifies the number of halfwords to be added before the
       function label.  A second argument can be used to specify the
       number of halfwords to be added after the function label.  For both
*************** These function attributes are supported
*** 38899,38942 ****
  
       If both arguments are zero, hotpatching is disabled.
  
! 'target (OPTIONS)'
       As discussed in *note Common Function Attributes::, this attribute
       allows specification of target-specific compilation options.
  
       On S/390, the following options are supported:
  
!      'arch='
!      'tune='
!      'stack-guard='
!      'stack-size='
!      'branch-cost='
!      'warn-framesize='
!      'backchain'
!      'no-backchain'
!      'hard-dfp'
!      'no-hard-dfp'
!      'hard-float'
!      'soft-float'
!      'htm'
!      'no-htm'
!      'vx'
!      'no-vx'
!      'packed-stack'
!      'no-packed-stack'
!      'small-exec'
!      'no-small-exec'
!      'mvcle'
!      'no-mvcle'
!      'warn-dynamicstack'
!      'no-warn-dynamicstack'
  
       The options work exactly like the S/390 specific command line
!      options (without the prefix '-m') except that they do not change
       any feature macros.  For example,
  
            target("no-vx")
  
!      does not undefine the '__VEC__' macro.
  
  
  File: gcc.info,  Node: SH Function Attributes,  Next: Symbian OS Function Attributes,  Prev: S/390 Function Attributes,  Up: Function Attributes
--- 38908,38951 ----
  
       If both arguments are zero, hotpatching is disabled.
  
! ‘target (OPTIONS)’
       As discussed in *note Common Function Attributes::, this attribute
       allows specification of target-specific compilation options.
  
       On S/390, the following options are supported:
  
!      ‘arch=’
!      ‘tune=’
!      ‘stack-guard=’
!      ‘stack-size=’
!      ‘branch-cost=’
!      ‘warn-framesize=’
!      ‘backchain’
!      ‘no-backchain’
!      ‘hard-dfp’
!      ‘no-hard-dfp’
!      ‘hard-float’
!      ‘soft-float’
!      ‘htm’
!      ‘no-htm’
!      ‘vx’
!      ‘no-vx’
!      ‘packed-stack’
!      ‘no-packed-stack’
!      ‘small-exec’
!      ‘no-small-exec’
!      ‘mvcle’
!      ‘no-mvcle’
!      ‘warn-dynamicstack’
!      ‘no-warn-dynamicstack’
  
       The options work exactly like the S/390 specific command line
!      options (without the prefix ‘-m’) except that they do not change
       any feature macros.  For example,
  
            target("no-vx")
  
!      does not undefine the ‘__VEC__’ macro.
  
  
  File: gcc.info,  Node: SH Function Attributes,  Next: Symbian OS Function Attributes,  Prev: S/390 Function Attributes,  Up: Function Attributes
*************** File: gcc.info,  Node: SH Function Attri
*** 38946,38952 ****
  
  These function attributes are supported on the SH family of processors:
  
! 'function_vector'
       On SH2A targets, this attribute declares a function to be called
       using the TBR relative addressing mode.  The argument to this
       attribute is the entry number of the same function in a vector
--- 38955,38961 ----
  
  These function attributes are supported on the SH family of processors:
  
! ‘function_vector’
       On SH2A targets, this attribute declares a function to be called
       using the TBR relative addressing mode.  The argument to this
       attribute is the entry number of the same function in a vector
*************** These function attributes are supported
*** 38965,38990 ****
       being made to the same function, it saves 2 bytes of code per each
       of these calls.
  
! 'interrupt_handler'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
       attribute is present.
  
! 'nosave_low_regs'
       Use this attribute on SH targets to indicate that an
!      'interrupt_handler' function should not save and restore registers
       R0..R7.  This can be used on SH3* and SH4* targets that have a
       second R0..R7 register bank for non-reentrant interrupt handlers.
  
! 'renesas'
       On SH targets this attribute specifies that the function or struct
       follows the Renesas ABI.
  
! 'resbank'
       On the SH2A target, this attribute enables the high-speed register
       saving and restoration using a register bank for
!      'interrupt_handler' routines.  Saving to the bank is performed
       automatically after the CPU accepts an interrupt that uses a
       register bank.
  
--- 38974,38999 ----
       being made to the same function, it saves 2 bytes of code per each
       of these calls.
  
! ‘interrupt_handler’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
       attribute is present.
  
! ‘nosave_low_regs’
       Use this attribute on SH targets to indicate that an
!      ‘interrupt_handler’ function should not save and restore registers
       R0..R7.  This can be used on SH3* and SH4* targets that have a
       second R0..R7 register bank for non-reentrant interrupt handlers.
  
! ‘renesas’
       On SH targets this attribute specifies that the function or struct
       follows the Renesas ABI.
  
! ‘resbank’
       On the SH2A target, this attribute enables the high-speed register
       saving and restoration using a register bank for
!      ‘interrupt_handler’ routines.  Saving to the bank is performed
       automatically after the CPU accepts an interrupt that uses a
       register bank.
  
*************** These function attributes are supported
*** 38995,39002 ****
       Restoration from the bank is executed by issuing a RESBANK
       instruction.
  
! '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.
--- 39004,39011 ----
       Restoration from the bank is executed by issuing a RESBANK
       instruction.
  
! ‘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.
*************** These function attributes are supported
*** 39005,39018 ****
            void f () __attribute__ ((interrupt_handler,
                                      sp_switch ("alt_stack")));
  
! 'trap_exit'
!      Use this attribute on the SH for an 'interrupt_handler' to return
!      using 'trapa' instead of 'rte'.  This attribute expects an integer
       argument specifying the trap number to be used.
  
! 'trapa_handler'
       On SH targets this function attribute is similar to
!      'interrupt_handler' but it does not save and restore all registers.
  
  
  File: gcc.info,  Node: Symbian OS Function Attributes,  Next: V850 Function Attributes,  Prev: SH Function Attributes,  Up: Function Attributes
--- 39014,39027 ----
            void f () __attribute__ ((interrupt_handler,
                                      sp_switch ("alt_stack")));
  
! ‘trap_exit’
!      Use this attribute on the SH for an ‘interrupt_handler’ to return
!      using ‘trapa’ instead of ‘rte’.  This attribute expects an integer
       argument specifying the trap number to be used.
  
! ‘trapa_handler’
       On SH targets this function attribute is similar to
!      ‘interrupt_handler’ but it does not save and restore all registers.
  
  
  File: gcc.info,  Node: Symbian OS Function Attributes,  Next: V850 Function Attributes,  Prev: SH Function Attributes,  Up: Function Attributes
*************** File: gcc.info,  Node: Symbian OS Functi
*** 39021,39027 ****
  --------------------------------------
  
  *Note Microsoft Windows Function Attributes::, for discussion of the
! 'dllexport' and 'dllimport' attributes.
  
  
  File: gcc.info,  Node: V850 Function Attributes,  Next: Visium Function Attributes,  Prev: Symbian OS Function Attributes,  Up: Function Attributes
--- 39030,39036 ----
  --------------------------------------
  
  *Note Microsoft Windows Function Attributes::, for discussion of the
! ‘dllexport’ and ‘dllimport’ attributes.
  
  
  File: gcc.info,  Node: V850 Function Attributes,  Next: Visium Function Attributes,  Prev: Symbian OS Function Attributes,  Up: Function Attributes
*************** File: gcc.info,  Node: V850 Function Att
*** 39031,39038 ****
  
  The V850 back end supports these function attributes:
  
! 'interrupt'
! 'interrupt_handler'
       Use these attributes to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when either
--- 39040,39047 ----
  
  The V850 back end supports these function attributes:
  
! ‘interrupt’
! ‘interrupt_handler’
       Use these attributes to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when either
*************** File: gcc.info,  Node: Visium Function A
*** 39046,39052 ****
  
  These function attributes are supported by the Visium back end:
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 39055,39061 ----
  
  These function attributes are supported by the Visium back end:
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** File: gcc.info,  Node: x86 Function Attr
*** 39060,39104 ****
  
  These function attributes are supported by the x86 back end:
  
! 'cdecl'
!      On the x86-32 targets, the 'cdecl' attribute causes the compiler to
       assume that the calling function pops off the stack space used to
       pass arguments.  This is useful to override the effects of the
!      '-mrtd' switch.
  
! 'fastcall'
!      On x86-32 targets, the 'fastcall' attribute causes the compiler to
       pass the first argument (if of integral type) in the register ECX
       and the second argument (if of integral type) in the register EDX.
       Subsequent and other typed arguments are passed on the stack.  The
       called function pops the arguments off the stack.  If the number of
       arguments is variable all arguments are pushed on the stack.
  
! 'thiscall'
!      On x86-32 targets, the 'thiscall' attribute causes the compiler to
       pass the first argument (if of integral type) in the register ECX.
       Subsequent and other typed arguments are passed on the stack.  The
       called function pops the arguments off the stack.  If the number of
       arguments is variable all arguments are pushed on the stack.  The
!      'thiscall' attribute is intended for C++ non-static member
       functions.  As a GCC extension, this calling convention can be used
       for C functions and for static member methods.
  
! 'ms_abi'
! 'sysv_abi'
  
       On 32-bit and 64-bit x86 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 System
       V ELF ABI, which is 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 System V ELF ABI.
  
!      Note, the 'ms_abi' attribute for Microsoft Windows 64-bit targets
!      currently requires the '-maccumulate-outgoing-args' option.
  
! 'callee_pop_aggregate_return (NUMBER)'
  
       On x86-32 targets, you can use this attribute to control how
       aggregates are returned in memory.  If the caller is responsible
--- 39069,39113 ----
  
  These function attributes are supported by the x86 back end:
  
! ‘cdecl’
!      On the x86-32 targets, the ‘cdecl’ attribute causes the compiler to
       assume that the calling function pops off the stack space used to
       pass arguments.  This is useful to override the effects of the
!      ‘-mrtd’ switch.
  
! ‘fastcall’
!      On x86-32 targets, the ‘fastcall’ attribute causes the compiler to
       pass the first argument (if of integral type) in the register ECX
       and the second argument (if of integral type) in the register EDX.
       Subsequent and other typed arguments are passed on the stack.  The
       called function pops the arguments off the stack.  If the number of
       arguments is variable all arguments are pushed on the stack.
  
! ‘thiscall’
!      On x86-32 targets, the ‘thiscall’ attribute causes the compiler to
       pass the first argument (if of integral type) in the register ECX.
       Subsequent and other typed arguments are passed on the stack.  The
       called function pops the arguments off the stack.  If the number of
       arguments is variable all arguments are pushed on the stack.  The
!      ‘thiscall’ attribute is intended for C++ non-static member
       functions.  As a GCC extension, this calling convention can be used
       for C functions and for static member methods.
  
! ‘ms_abi’
! ‘sysv_abi’
  
       On 32-bit and 64-bit x86 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 System
       V ELF ABI, which is 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 System V ELF ABI.
  
!      Note, the ‘ms_abi’ attribute for Microsoft Windows 64-bit targets
!      currently requires the ‘-maccumulate-outgoing-args’ option.
  
! ‘callee_pop_aggregate_return (NUMBER)’
  
       On x86-32 targets, you can use this attribute to control how
       aggregates are returned in memory.  If the caller is responsible
*************** These function attributes are supported
*** 39110,39134 ****
       hidden pointer.  However, on x86-32 Microsoft Windows targets, the
       compiler assumes that the caller pops the stack for hidden pointer.
  
! 'ms_hook_prologue'
  
       On 32-bit and 64-bit x86 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'
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      'asm' statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended 'asm' or a mixture of basic
!      'asm' and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! 'regparm (NUMBER)'
!      On x86-32 targets, the 'regparm' attribute causes the compiler to
       pass arguments number one to NUMBER if they are of integral type in
       registers EAX, EDX, and ECX instead of on the stack.  Functions
       that take a variable number of arguments continue to be passed all
--- 39119,39143 ----
       hidden pointer.  However, on x86-32 Microsoft Windows targets, the
       compiler assumes that the caller pops the stack for hidden pointer.
  
! ‘ms_hook_prologue’
  
       On 32-bit and 64-bit x86 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’
       This attribute allows the compiler to construct the requisite
       function declaration, while allowing the body of the function to be
       assembly code.  The specified function will not have
       prologue/epilogue sequences generated by the compiler.  Only basic
!      ‘asm’ statements can safely be included in naked functions (*note
!      Basic Asm::).  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and C code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! ‘regparm (NUMBER)’
!      On x86-32 targets, the ‘regparm’ attribute causes the compiler to
       pass arguments number one to NUMBER if they are of integral type in
       registers EAX, EDX, and ECX instead of on the stack.  Functions
       that take a variable number of arguments continue to be passed all
*************** These function attributes are supported
*** 39144,39195 ****
       save EAX, EDX and ECX. (Lazy binding can be disabled with the
       linker or the loader if desired, to avoid the problem.)
  
! 'sseregparm'
!      On x86-32 targets with SSE support, the 'sseregparm' attribute
       causes the compiler to pass up to 3 floating-point arguments in SSE
       registers instead of on the stack.  Functions that take a variable
       number of arguments continue to pass all of their floating-point
       arguments on the stack.
  
! 'force_align_arg_pointer'
!      On x86 targets, the 'force_align_arg_pointer' attribute may be
       applied to individual function definitions, generating an alternate
       prologue and epilogue that realigns the run-time stack if
       necessary.  This supports mixing legacy codes that run with a
       4-byte aligned stack with modern codes that keep a 16-byte stack
       for SSE compatibility.
  
! 'stdcall'
!      On x86-32 targets, the 'stdcall' attribute causes the compiler to
       assume that the called function pops off the stack space used to
       pass arguments, unless it takes a variable number of arguments.
  
! 'no_caller_saved_registers'
       Use this attribute to indicate that the specified function has no
       caller-saved registers.  That is, all registers are callee-saved.
       For example, this attribute can be used for a function called from
       an interrupt handler.  The compiler generates proper function entry
       and exit sequences to save and restore any modified registers,
       except for the EFLAGS register.  Since GCC doesn't preserve SSE,
!      MMX nor x87 states, the GCC option '-mgeneral-regs-only' should be
!      used to compile functions with 'no_caller_saved_registers'
       attribute.
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler or an exception handler (depending on parameters
       passed to the function, explained further).  The compiler generates
       function entry and exit sequences suitable for use in an interrupt
!      handler when this attribute is present.  The 'IRET' instruction,
!      instead of the 'RET' instruction, is used to return from interrupt
       handlers.  All registers, except for the EFLAGS register which is
!      restored by the 'IRET' instruction, are preserved by the compiler.
       Since GCC doesn't preserve SSE, MMX nor x87 states, the GCC option
!      '-mgeneral-regs-only' should be used to compile interrupt and
       exception handlers.
  
       Any interruptible-without-stack-switch code must be compiled with
!      '-mno-red-zone' since interrupt handlers can and will, because of
       the hardware design, touch the red zone.
  
       An interrupt handler must be declared with a mandatory pointer
--- 39153,39204 ----
       save EAX, EDX and ECX. (Lazy binding can be disabled with the
       linker or the loader if desired, to avoid the problem.)
  
! ‘sseregparm’
!      On x86-32 targets with SSE support, the ‘sseregparm’ attribute
       causes the compiler to pass up to 3 floating-point arguments in SSE
       registers instead of on the stack.  Functions that take a variable
       number of arguments continue to pass all of their floating-point
       arguments on the stack.
  
! ‘force_align_arg_pointer’
!      On x86 targets, the ‘force_align_arg_pointer’ attribute may be
       applied to individual function definitions, generating an alternate
       prologue and epilogue that realigns the run-time stack if
       necessary.  This supports mixing legacy codes that run with a
       4-byte aligned stack with modern codes that keep a 16-byte stack
       for SSE compatibility.
  
! ‘stdcall’
!      On x86-32 targets, the ‘stdcall’ attribute causes the compiler to
       assume that the called function pops off the stack space used to
       pass arguments, unless it takes a variable number of arguments.
  
! ‘no_caller_saved_registers’
       Use this attribute to indicate that the specified function has no
       caller-saved registers.  That is, all registers are callee-saved.
       For example, this attribute can be used for a function called from
       an interrupt handler.  The compiler generates proper function entry
       and exit sequences to save and restore any modified registers,
       except for the EFLAGS register.  Since GCC doesn't preserve SSE,
!      MMX nor x87 states, the GCC option ‘-mgeneral-regs-only’ should be
!      used to compile functions with ‘no_caller_saved_registers’
       attribute.
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler or an exception handler (depending on parameters
       passed to the function, explained further).  The compiler generates
       function entry and exit sequences suitable for use in an interrupt
!      handler when this attribute is present.  The ‘IRET’ instruction,
!      instead of the ‘RET’ instruction, is used to return from interrupt
       handlers.  All registers, except for the EFLAGS register which is
!      restored by the ‘IRET’ instruction, are preserved by the compiler.
       Since GCC doesn't preserve SSE, MMX nor x87 states, the GCC option
!      ‘-mgeneral-regs-only’ should be used to compile interrupt and
       exception handlers.
  
       Any interruptible-without-stack-switch code must be compiled with
!      ‘-mno-red-zone’ since interrupt handlers can and will, because of
       the hardware design, touch the red zone.
  
       An interrupt handler must be declared with a mandatory pointer
*************** These function attributes are supported
*** 39203,39216 ****
            {
            }
  
!      and you must define 'struct interrupt_frame' as described in the
       processor's manual.
  
       Exception handlers differ from interrupt handlers because the
       system pushes an error code on the stack.  An exception handler
       declaration is similar to that for an interrupt handler, but with a
       different mandatory function signature.  The compiler arranges to
!      pop the error code off the stack before the 'IRET' instruction.
  
            #ifdef __x86_64__
            typedef unsigned long long int uword_t;
--- 39212,39225 ----
            {
            }
  
!      and you must define ‘struct interrupt_frame’ as described in the
       processor's manual.
  
       Exception handlers differ from interrupt handlers because the
       system pushes an error code on the stack.  An exception handler
       declaration is similar to that for an interrupt handler, but with a
       different mandatory function signature.  The compiler arranges to
!      pop the error code off the stack before the ‘IRET’ instruction.
  
            #ifdef __x86_64__
            typedef unsigned long long int uword_t;
*************** These function attributes are supported
*** 39231,39745 ****
       error code; you should use an interrupt handler in other cases.
       The system will crash if the wrong kind of handler is used.
  
! 'target (OPTIONS)'
       As discussed in *note Common Function Attributes::, this attribute
       allows specification of target-specific compilation options.
  
       On the x86, the following options are allowed:
!      '3dnow'
!      'no-3dnow'
            Enable/disable the generation of the 3DNow! instructions.
  
!      '3dnowa'
!      'no-3dnowa'
            Enable/disable the generation of the enhanced 3DNow!
            instructions.
  
!      'abm'
!      'no-abm'
            Enable/disable the generation of the advanced bit
            instructions.
  
!      'adx'
!      'no-adx'
            Enable/disable the generation of the ADX instructions.
  
!      'aes'
!      'no-aes'
            Enable/disable the generation of the AES instructions.
  
!      'avx'
!      'no-avx'
            Enable/disable the generation of the AVX instructions.
  
!      'avx2'
!      'no-avx2'
            Enable/disable the generation of the AVX2 instructions.
  
!      'avx5124fmaps'
!      'no-avx5124fmaps'
            Enable/disable the generation of the AVX5124FMAPS
            instructions.
  
!      'avx5124vnniw'
!      'no-avx5124vnniw'
            Enable/disable the generation of the AVX5124VNNIW
            instructions.
  
!      'avx512bitalg'
!      'no-avx512bitalg'
            Enable/disable the generation of the AVX512BITALG
            instructions.
  
!      'avx512bw'
!      'no-avx512bw'
            Enable/disable the generation of the AVX512BW instructions.
  
!      'avx512cd'
!      'no-avx512cd'
            Enable/disable the generation of the AVX512CD instructions.
  
!      'avx512dq'
!      'no-avx512dq'
            Enable/disable the generation of the AVX512DQ instructions.
  
!      'avx512er'
!      'no-avx512er'
            Enable/disable the generation of the AVX512ER instructions.
  
!      'avx512f'
!      'no-avx512f'
            Enable/disable the generation of the AVX512F instructions.
  
!      'avx512ifma'
!      'no-avx512ifma'
            Enable/disable the generation of the AVX512IFMA instructions.
  
!      'avx512pf'
!      'no-avx512pf'
            Enable/disable the generation of the AVX512PF instructions.
  
!      'avx512vbmi'
!      'no-avx512vbmi'
            Enable/disable the generation of the AVX512VBMI instructions.
  
!      'avx512vbmi2'
!      'no-avx512vbmi2'
            Enable/disable the generation of the AVX512VBMI2 instructions.
  
!      'avx512vl'
!      'no-avx512vl'
            Enable/disable the generation of the AVX512VL instructions.
  
!      'avx512vnni'
!      'no-avx512vnni'
            Enable/disable the generation of the AVX512VNNI instructions.
  
!      'avx512vpopcntdq'
!      'no-avx512vpopcntdq'
            Enable/disable the generation of the AVX512VPOPCNTDQ
            instructions.
  
!      'bmi'
!      'no-bmi'
            Enable/disable the generation of the BMI instructions.
  
!      'bmi2'
!      'no-bmi2'
            Enable/disable the generation of the BMI2 instructions.
  
!      'cldemote'
!      'no-cldemote'
            Enable/disable the generation of the CLDEMOTE instructions.
  
!      'clflushopt'
!      'no-clflushopt'
            Enable/disable the generation of the CLFLUSHOPT instructions.
  
!      'clwb'
!      'no-clwb'
            Enable/disable the generation of the CLWB instructions.
  
!      'clzero'
!      'no-clzero'
            Enable/disable the generation of the CLZERO instructions.
  
!      'crc32'
!      'no-crc32'
            Enable/disable the generation of the CRC32 instructions.
  
!      'cx16'
!      'no-cx16'
            Enable/disable the generation of the CMPXCHG16B instructions.
  
!      'default'
            *Note Function Multiversioning::, where it is used to specify
            the default function version.
  
!      'f16c'
!      'no-f16c'
            Enable/disable the generation of the F16C instructions.
  
!      'fma'
!      'no-fma'
            Enable/disable the generation of the FMA instructions.
  
!      'fma4'
!      'no-fma4'
            Enable/disable the generation of the FMA4 instructions.
  
!      'fsgsbase'
!      'no-fsgsbase'
            Enable/disable the generation of the FSGSBASE instructions.
  
!      'fxsr'
!      'no-fxsr'
            Enable/disable the generation of the FXSR instructions.
  
!      'gfni'
!      'no-gfni'
            Enable/disable the generation of the GFNI instructions.
  
!      'hle'
!      'no-hle'
            Enable/disable the generation of the HLE instruction prefixes.
  
!      'lwp'
!      'no-lwp'
            Enable/disable the generation of the LWP instructions.
  
!      'lzcnt'
!      'no-lzcnt'
            Enable/disable the generation of the LZCNT instructions.
  
!      'mmx'
!      'no-mmx'
            Enable/disable the generation of the MMX instructions.
  
!      'movbe'
!      'no-movbe'
            Enable/disable the generation of the MOVBE instructions.
  
!      'movdir64b'
!      'no-movdir64b'
            Enable/disable the generation of the MOVDIR64B instructions.
  
!      'movdiri'
!      'no-movdiri'
            Enable/disable the generation of the MOVDIRI instructions.
  
!      'mwait'
!      'no-mwait'
            Enable/disable the generation of the MWAIT and MONITOR
            instructions.
  
!      'mwaitx'
!      'no-mwaitx'
            Enable/disable the generation of the MWAITX instructions.
  
!      'pclmul'
!      'no-pclmul'
            Enable/disable the generation of the PCLMUL instructions.
  
!      'pconfig'
!      'no-pconfig'
            Enable/disable the generation of the PCONFIG instructions.
  
!      'pku'
!      'no-pku'
            Enable/disable the generation of the PKU instructions.
  
!      'popcnt'
!      'no-popcnt'
            Enable/disable the generation of the POPCNT instruction.
  
!      'prefetchwt1'
!      'no-prefetchwt1'
            Enable/disable the generation of the PREFETCHWT1 instructions.
  
!      'prfchw'
!      'no-prfchw'
            Enable/disable the generation of the PREFETCHW instruction.
  
!      'ptwrite'
!      'no-ptwrite'
            Enable/disable the generation of the PTWRITE instructions.
  
!      'rdpid'
!      'no-rdpid'
            Enable/disable the generation of the RDPID instructions.
  
!      'rdrnd'
!      'no-rdrnd'
            Enable/disable the generation of the RDRND instructions.
  
!      'rdseed'
!      'no-rdseed'
            Enable/disable the generation of the RDSEED instructions.
  
!      'rtm'
!      'no-rtm'
            Enable/disable the generation of the RTM instructions.
  
!      'sahf'
!      'no-sahf'
            Enable/disable the generation of the SAHF instructions.
  
!      'sgx'
!      'no-sgx'
            Enable/disable the generation of the SGX instructions.
  
!      'sha'
!      'no-sha'
            Enable/disable the generation of the SHA instructions.
  
!      'shstk'
!      'no-shstk'
            Enable/disable the shadow stack built-in functions from CET.
  
!      '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.
  
!      'ssse3'
!      'no-ssse3'
            Enable/disable the generation of the SSSE3 instructions.
  
!      'tbm'
!      'no-tbm'
            Enable/disable the generation of the TBM instructions.
  
!      'vaes'
!      'no-vaes'
            Enable/disable the generation of the VAES instructions.
  
!      'vpclmulqdq'
!      'no-vpclmulqdq'
            Enable/disable the generation of the VPCLMULQDQ instructions.
  
!      'waitpkg'
!      'no-waitpkg'
            Enable/disable the generation of the WAITPKG instructions.
  
!      'wbnoinvd'
!      'no-wbnoinvd'
            Enable/disable the generation of the WBNOINVD instructions.
  
!      'xop'
!      'no-xop'
            Enable/disable the generation of the XOP instructions.
  
!      'xsave'
!      'no-xsave'
            Enable/disable the generation of the XSAVE instructions.
  
!      'xsavec'
!      'no-xsavec'
            Enable/disable the generation of the XSAVEC instructions.
  
!      'xsaveopt'
!      'no-xsaveopt'
            Enable/disable the generation of the XSAVEOPT instructions.
  
!      'xsaves'
!      'no-xsaves'
            Enable/disable the generation of the XSAVES instructions.
  
!      'amx-tile'
!      'no-amx-tile'
            Enable/disable the generation of the AMX-TILE instructions.
  
!      'amx-int8'
!      'no-amx-int8'
            Enable/disable the generation of the AMX-INT8 instructions.
  
!      'amx-bf16'
!      'no-amx-bf16'
            Enable/disable the generation of the AMX-BF16 instructions.
  
!      'uintr'
!      'no-uintr'
            Enable/disable the generation of the UINTR instructions.
  
!      'hreset'
!      'no-hreset'
            Enable/disable the generation of the HRESET instruction.
  
!      'kl'
!      'no-kl'
            Enable/disable the generation of the KEYLOCKER instructions.
  
!      'widekl'
!      'no-widekl'
            Enable/disable the generation of the WIDEKL instructions.
  
!      'avxvnni'
!      'no-avxvnni'
            Enable/disable the generation of the AVXVNNI instructions.
  
!      'avxifma'
!      'no-avxifma'
            Enable/disable the generation of the AVXIFMA instructions.
  
!      'avxvnniint8'
!      'no-avxvnniint8'
            Enable/disable the generation of the AVXVNNIINT8 instructions.
  
!      'avxneconvert'
!      'no-avxneconvert'
            Enable/disable the generation of the AVXNECONVERT
            instructions.
  
!      'cmpccxadd'
!      'no-cmpccxadd'
            Enable/disable the generation of the CMPccXADD instructions.
  
!      'amx-fp16'
!      'no-amx-fp16'
            Enable/disable the generation of the AMX-FP16 instructions.
  
!      'prefetchi'
!      'no-prefetchi'
            Enable/disable the generation of the PREFETCHI instructions.
  
!      'raoint'
!      'no-raoint'
            Enable/disable the generation of the RAOINT instructions.
  
!      'amx-complex'
!      'no-amx-complex'
            Enable/disable the generation of the AMX-COMPLEX 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.
  
!      '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.
  
!      'general-regs-only'
            Generate code which uses only the general registers.
  
!      '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.  You must specify
!           the 'target("fpmath=sse,387")' option as
!           'target("fpmath=sse+387")' because the comma would separate
            different options.
  
!      'prefer-vector-width=OPT'
!           On x86 targets, the 'prefer-vector-width' attribute informs
            the compiler to use OPT-bit vector width in instructions
            instead of the default on the selected platform.
  
            Valid OPT values are:
  
!           'none'
                 No extra limitations applied to GCC other than defined by
                 the selected platform.
  
!           '128'
                 Prefer 128-bit vector width for instructions.
  
!           '256'
                 Prefer 256-bit vector width for instructions.
  
!           '512'
                 Prefer 512-bit vector width for instructions.
  
            On the x86, the inliner does not inline a function that has
            different target options than the caller, unless the callee
            has a subset of the target options of the caller.  For example
!           a function declared with 'target("sse3")' can inline a
!           function with 'target("sse2")', since '-msse3' implies
!           '-msse2'.
  
! 'indirect_branch("CHOICE")'
!      On x86 targets, the 'indirect_branch' attribute causes the compiler
!      to convert indirect call and jump with CHOICE.  'keep' keeps
!      indirect call and jump unmodified.  'thunk' converts indirect call
!      and jump to call and return thunk.  'thunk-inline' converts
       indirect call and jump to inlined call and return thunk.
!      'thunk-extern' converts indirect call and jump to external call and
       return thunk provided in a separate object file.
  
! 'function_return("CHOICE")'
!      On x86 targets, the 'function_return' attribute causes the compiler
!      to convert function return with CHOICE.  'keep' keeps function
!      return unmodified.  'thunk' converts function return to call and
!      return thunk.  'thunk-inline' converts function return to inlined
!      call and return thunk.  'thunk-extern' converts function return to
       external call and return thunk provided in a separate object file.
  
! 'nocf_check'
!      The 'nocf_check' attribute on a function is used to inform the
       compiler that the function's prologue should not be instrumented
!      when compiled with the '-fcf-protection=branch' option.  The
       compiler assumes that the function's address is a valid target for
       a control-flow transfer.
  
!      The 'nocf_check' attribute on a type of pointer to function is used
       to inform the compiler that a call through the pointer should not
!      be instrumented when compiled with the '-fcf-protection=branch'
       option.  The compiler assumes that the function's address from the
       pointer is a valid target for a control-flow transfer.  A direct
       function call through a function name is assumed to be a safe call
       thus direct calls are not instrumented by the compiler.
  
!      The 'nocf_check' attribute is applied to an object's type.  In case
       of assignment of a function address or a function pointer to
       another pointer, the attribute is not carried over from the
       right-hand object's type; the type of left-hand object stays
!      unchanged.  The compiler checks for 'nocf_check' attribute mismatch
       and reports a warning in case of mismatch.
  
            {
--- 39240,39754 ----
       error code; you should use an interrupt handler in other cases.
       The system will crash if the wrong kind of handler is used.
  
! ‘target (OPTIONS)’
       As discussed in *note Common Function Attributes::, this attribute
       allows specification of target-specific compilation options.
  
       On the x86, the following options are allowed:
!      ‘3dnow’
!      ‘no-3dnow’
            Enable/disable the generation of the 3DNow! instructions.
  
!      ‘3dnowa’
!      ‘no-3dnowa’
            Enable/disable the generation of the enhanced 3DNow!
            instructions.
  
!      ‘abm’
!      ‘no-abm’
            Enable/disable the generation of the advanced bit
            instructions.
  
!      ‘adx’
!      ‘no-adx’
            Enable/disable the generation of the ADX instructions.
  
!      ‘aes’
!      ‘no-aes’
            Enable/disable the generation of the AES instructions.
  
!      ‘avx’
!      ‘no-avx’
            Enable/disable the generation of the AVX instructions.
  
!      ‘avx2’
!      ‘no-avx2’
            Enable/disable the generation of the AVX2 instructions.
  
!      ‘avx5124fmaps’
!      ‘no-avx5124fmaps’
            Enable/disable the generation of the AVX5124FMAPS
            instructions.
  
!      ‘avx5124vnniw’
!      ‘no-avx5124vnniw’
            Enable/disable the generation of the AVX5124VNNIW
            instructions.
  
!      ‘avx512bitalg’
!      ‘no-avx512bitalg’
            Enable/disable the generation of the AVX512BITALG
            instructions.
  
!      ‘avx512bw’
!      ‘no-avx512bw’
            Enable/disable the generation of the AVX512BW instructions.
  
!      ‘avx512cd’
!      ‘no-avx512cd’
            Enable/disable the generation of the AVX512CD instructions.
  
!      ‘avx512dq’
!      ‘no-avx512dq’
            Enable/disable the generation of the AVX512DQ instructions.
  
!      ‘avx512er’
!      ‘no-avx512er’
            Enable/disable the generation of the AVX512ER instructions.
  
!      ‘avx512f’
!      ‘no-avx512f’
            Enable/disable the generation of the AVX512F instructions.
  
!      ‘avx512ifma’
!      ‘no-avx512ifma’
            Enable/disable the generation of the AVX512IFMA instructions.
  
!      ‘avx512pf’
!      ‘no-avx512pf’
            Enable/disable the generation of the AVX512PF instructions.
  
!      ‘avx512vbmi’
!      ‘no-avx512vbmi’
            Enable/disable the generation of the AVX512VBMI instructions.
  
!      ‘avx512vbmi2’
!      ‘no-avx512vbmi2’
            Enable/disable the generation of the AVX512VBMI2 instructions.
  
!      ‘avx512vl’
!      ‘no-avx512vl’
            Enable/disable the generation of the AVX512VL instructions.
  
!      ‘avx512vnni’
!      ‘no-avx512vnni’
            Enable/disable the generation of the AVX512VNNI instructions.
  
!      ‘avx512vpopcntdq’
!      ‘no-avx512vpopcntdq’
            Enable/disable the generation of the AVX512VPOPCNTDQ
            instructions.
  
!      ‘bmi’
!      ‘no-bmi’
            Enable/disable the generation of the BMI instructions.
  
!      ‘bmi2’
!      ‘no-bmi2’
            Enable/disable the generation of the BMI2 instructions.
  
!      ‘cldemote’
!      ‘no-cldemote’
            Enable/disable the generation of the CLDEMOTE instructions.
  
!      ‘clflushopt’
!      ‘no-clflushopt’
            Enable/disable the generation of the CLFLUSHOPT instructions.
  
!      ‘clwb’
!      ‘no-clwb’
            Enable/disable the generation of the CLWB instructions.
  
!      ‘clzero’
!      ‘no-clzero’
            Enable/disable the generation of the CLZERO instructions.
  
!      ‘crc32’
!      ‘no-crc32’
            Enable/disable the generation of the CRC32 instructions.
  
!      ‘cx16’
!      ‘no-cx16’
            Enable/disable the generation of the CMPXCHG16B instructions.
  
!      ‘default’
            *Note Function Multiversioning::, where it is used to specify
            the default function version.
  
!      ‘f16c’
!      ‘no-f16c’
            Enable/disable the generation of the F16C instructions.
  
!      ‘fma’
!      ‘no-fma’
            Enable/disable the generation of the FMA instructions.
  
!      ‘fma4’
!      ‘no-fma4’
            Enable/disable the generation of the FMA4 instructions.
  
!      ‘fsgsbase’
!      ‘no-fsgsbase’
            Enable/disable the generation of the FSGSBASE instructions.
  
!      ‘fxsr’
!      ‘no-fxsr’
            Enable/disable the generation of the FXSR instructions.
  
!      ‘gfni’
!      ‘no-gfni’
            Enable/disable the generation of the GFNI instructions.
  
!      ‘hle’
!      ‘no-hle’
            Enable/disable the generation of the HLE instruction prefixes.
  
!      ‘lwp’
!      ‘no-lwp’
            Enable/disable the generation of the LWP instructions.
  
!      ‘lzcnt’
!      ‘no-lzcnt’
            Enable/disable the generation of the LZCNT instructions.
  
!      ‘mmx’
!      ‘no-mmx’
            Enable/disable the generation of the MMX instructions.
  
!      ‘movbe’
!      ‘no-movbe’
            Enable/disable the generation of the MOVBE instructions.
  
!      ‘movdir64b’
!      ‘no-movdir64b’
            Enable/disable the generation of the MOVDIR64B instructions.
  
!      ‘movdiri’
!      ‘no-movdiri’
            Enable/disable the generation of the MOVDIRI instructions.
  
!      ‘mwait’
!      ‘no-mwait’
            Enable/disable the generation of the MWAIT and MONITOR
            instructions.
  
!      ‘mwaitx’
!      ‘no-mwaitx’
            Enable/disable the generation of the MWAITX instructions.
  
!      ‘pclmul’
!      ‘no-pclmul’
            Enable/disable the generation of the PCLMUL instructions.
  
!      ‘pconfig’
!      ‘no-pconfig’
            Enable/disable the generation of the PCONFIG instructions.
  
!      ‘pku’
!      ‘no-pku’
            Enable/disable the generation of the PKU instructions.
  
!      ‘popcnt’
!      ‘no-popcnt’
            Enable/disable the generation of the POPCNT instruction.
  
!      ‘prefetchwt1’
!      ‘no-prefetchwt1’
            Enable/disable the generation of the PREFETCHWT1 instructions.
  
!      ‘prfchw’
!      ‘no-prfchw’
            Enable/disable the generation of the PREFETCHW instruction.
  
!      ‘ptwrite’
!      ‘no-ptwrite’
            Enable/disable the generation of the PTWRITE instructions.
  
!      ‘rdpid’
!      ‘no-rdpid’
            Enable/disable the generation of the RDPID instructions.
  
!      ‘rdrnd’
!      ‘no-rdrnd’
            Enable/disable the generation of the RDRND instructions.
  
!      ‘rdseed’
!      ‘no-rdseed’
            Enable/disable the generation of the RDSEED instructions.
  
!      ‘rtm’
!      ‘no-rtm’
            Enable/disable the generation of the RTM instructions.
  
!      ‘sahf’
!      ‘no-sahf’
            Enable/disable the generation of the SAHF instructions.
  
!      ‘sgx’
!      ‘no-sgx’
            Enable/disable the generation of the SGX instructions.
  
!      ‘sha’
!      ‘no-sha’
            Enable/disable the generation of the SHA instructions.
  
!      ‘shstk’
!      ‘no-shstk’
            Enable/disable the shadow stack built-in functions from CET.
  
!      ‘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.
  
!      ‘ssse3’
!      ‘no-ssse3’
            Enable/disable the generation of the SSSE3 instructions.
  
!      ‘tbm’
!      ‘no-tbm’
            Enable/disable the generation of the TBM instructions.
  
!      ‘vaes’
!      ‘no-vaes’
            Enable/disable the generation of the VAES instructions.
  
!      ‘vpclmulqdq’
!      ‘no-vpclmulqdq’
            Enable/disable the generation of the VPCLMULQDQ instructions.
  
!      ‘waitpkg’
!      ‘no-waitpkg’
            Enable/disable the generation of the WAITPKG instructions.
  
!      ‘wbnoinvd’
!      ‘no-wbnoinvd’
            Enable/disable the generation of the WBNOINVD instructions.
  
!      ‘xop’
!      ‘no-xop’
            Enable/disable the generation of the XOP instructions.
  
!      ‘xsave’
!      ‘no-xsave’
            Enable/disable the generation of the XSAVE instructions.
  
!      ‘xsavec’
!      ‘no-xsavec’
            Enable/disable the generation of the XSAVEC instructions.
  
!      ‘xsaveopt’
!      ‘no-xsaveopt’
            Enable/disable the generation of the XSAVEOPT instructions.
  
!      ‘xsaves’
!      ‘no-xsaves’
            Enable/disable the generation of the XSAVES instructions.
  
!      ‘amx-tile’
!      ‘no-amx-tile’
            Enable/disable the generation of the AMX-TILE instructions.
  
!      ‘amx-int8’
!      ‘no-amx-int8’
            Enable/disable the generation of the AMX-INT8 instructions.
  
!      ‘amx-bf16’
!      ‘no-amx-bf16’
            Enable/disable the generation of the AMX-BF16 instructions.
  
!      ‘uintr’
!      ‘no-uintr’
            Enable/disable the generation of the UINTR instructions.
  
!      ‘hreset’
!      ‘no-hreset’
            Enable/disable the generation of the HRESET instruction.
  
!      ‘kl’
!      ‘no-kl’
            Enable/disable the generation of the KEYLOCKER instructions.
  
!      ‘widekl’
!      ‘no-widekl’
            Enable/disable the generation of the WIDEKL instructions.
  
!      ‘avxvnni’
!      ‘no-avxvnni’
            Enable/disable the generation of the AVXVNNI instructions.
  
!      ‘avxifma’
!      ‘no-avxifma’
            Enable/disable the generation of the AVXIFMA instructions.
  
!      ‘avxvnniint8’
!      ‘no-avxvnniint8’
            Enable/disable the generation of the AVXVNNIINT8 instructions.
  
!      ‘avxneconvert’
!      ‘no-avxneconvert’
            Enable/disable the generation of the AVXNECONVERT
            instructions.
  
!      ‘cmpccxadd’
!      ‘no-cmpccxadd’
            Enable/disable the generation of the CMPccXADD instructions.
  
!      ‘amx-fp16’
!      ‘no-amx-fp16’
            Enable/disable the generation of the AMX-FP16 instructions.
  
!      ‘prefetchi’
!      ‘no-prefetchi’
            Enable/disable the generation of the PREFETCHI instructions.
  
!      ‘raoint’
!      ‘no-raoint’
            Enable/disable the generation of the RAOINT instructions.
  
!      ‘amx-complex’
!      ‘no-amx-complex’
            Enable/disable the generation of the AMX-COMPLEX 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.
  
!      ‘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.
  
!      ‘general-regs-only’
            Generate code which uses only the general registers.
  
!      ‘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.  You must specify
!           the ‘target("fpmath=sse,387")’ option as
!           ‘target("fpmath=sse+387")’ because the comma would separate
            different options.
  
!      ‘prefer-vector-width=OPT’
!           On x86 targets, the ‘prefer-vector-width’ attribute informs
            the compiler to use OPT-bit vector width in instructions
            instead of the default on the selected platform.
  
            Valid OPT values are:
  
!           ‘none’
                 No extra limitations applied to GCC other than defined by
                 the selected platform.
  
!           ‘128’
                 Prefer 128-bit vector width for instructions.
  
!           ‘256’
                 Prefer 256-bit vector width for instructions.
  
!           ‘512’
                 Prefer 512-bit vector width for instructions.
  
            On the x86, the inliner does not inline a function that has
            different target options than the caller, unless the callee
            has a subset of the target options of the caller.  For example
!           a function declared with ‘target("sse3")’ can inline a
!           function with ‘target("sse2")’, since ‘-msse3’ implies
!           ‘-msse2’.
  
! ‘indirect_branch("CHOICE")’
!      On x86 targets, the ‘indirect_branch’ attribute causes the compiler
!      to convert indirect call and jump with CHOICE.  ‘keep’ keeps
!      indirect call and jump unmodified.  ‘thunk’ converts indirect call
!      and jump to call and return thunk.  ‘thunk-inline’ converts
       indirect call and jump to inlined call and return thunk.
!      ‘thunk-extern’ converts indirect call and jump to external call and
       return thunk provided in a separate object file.
  
! ‘function_return("CHOICE")’
!      On x86 targets, the ‘function_return’ attribute causes the compiler
!      to convert function return with CHOICE.  ‘keep’ keeps function
!      return unmodified.  ‘thunk’ converts function return to call and
!      return thunk.  ‘thunk-inline’ converts function return to inlined
!      call and return thunk.  ‘thunk-extern’ converts function return to
       external call and return thunk provided in a separate object file.
  
! ‘nocf_check’
!      The ‘nocf_check’ attribute on a function is used to inform the
       compiler that the function's prologue should not be instrumented
!      when compiled with the ‘-fcf-protection=branch’ option.  The
       compiler assumes that the function's address is a valid target for
       a control-flow transfer.
  
!      The ‘nocf_check’ attribute on a type of pointer to function is used
       to inform the compiler that a call through the pointer should not
!      be instrumented when compiled with the ‘-fcf-protection=branch’
       option.  The compiler assumes that the function's address from the
       pointer is a valid target for a control-flow transfer.  A direct
       function call through a function name is assumed to be a safe call
       thus direct calls are not instrumented by the compiler.
  
!      The ‘nocf_check’ attribute is applied to an object's type.  In case
       of assignment of a function address or a function pointer to
       another pointer, the attribute is not carried over from the
       right-hand object's type; the type of left-hand object stays
!      unchanged.  The compiler checks for ‘nocf_check’ attribute mismatch
       and reports a warning in case of mismatch.
  
            {
*************** These function attributes are supported
*** 39773,39804 ****
              return 0;
            }
  
! 'cf_check'
  
!      The 'cf_check' attribute on a function is used to inform the
       compiler that ENDBR instruction should be placed at the function
!      entry when '-fcf-protection=branch' is enabled.
  
! 'indirect_return'
  
!      The 'indirect_return' attribute can be applied to a function, as
       well as variable or type of function pointer to inform the compiler
       that the function may return via indirect branch.
  
! 'fentry_name("NAME")'
!      On x86 targets, the 'fentry_name' attribute sets the function to
       call on function entry when function instrumentation is enabled
!      with '-pg -mfentry'.  When NAME is nop then a 5 byte nop sequence
       is generated.
  
! 'fentry_section("NAME")'
!      On x86 targets, the 'fentry_section' attribute sets the name of the
       section to record function entry instrumentation calls in when
!      enabled with '-pg -mrecord-mcount'
  
! 'nodirect_extern_access'
       This attribute, attached to a global variable or function, is the
!      counterpart to option '-mno-direct-extern-access'.
  
  
  File: gcc.info,  Node: Xstormy16 Function Attributes,  Prev: x86 Function Attributes,  Up: Function Attributes
--- 39782,39813 ----
              return 0;
            }
  
! ‘cf_check’
  
!      The ‘cf_check’ attribute on a function is used to inform the
       compiler that ENDBR instruction should be placed at the function
!      entry when ‘-fcf-protection=branch’ is enabled.
  
! ‘indirect_return’
  
!      The ‘indirect_return’ attribute can be applied to a function, as
       well as variable or type of function pointer to inform the compiler
       that the function may return via indirect branch.
  
! ‘fentry_name("NAME")’
!      On x86 targets, the ‘fentry_name’ attribute sets the function to
       call on function entry when function instrumentation is enabled
!      with ‘-pg -mfentry’.  When NAME is nop then a 5 byte nop sequence
       is generated.
  
! ‘fentry_section("NAME")’
!      On x86 targets, the ‘fentry_section’ attribute sets the name of the
       section to record function entry instrumentation calls in when
!      enabled with ‘-pg -mrecord-mcount’
  
! ‘nodirect_extern_access’
       This attribute, attached to a global variable or function, is the
!      counterpart to option ‘-mno-direct-extern-access’.
  
  
  File: gcc.info,  Node: Xstormy16 Function Attributes,  Prev: x86 Function Attributes,  Up: Function Attributes
*************** File: gcc.info,  Node: Xstormy16 Functio
*** 39808,39814 ****
  
  These function attributes are supported by the Xstormy16 back end:
  
! 'interrupt'
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
--- 39817,39823 ----
  
  These function attributes are supported by the Xstormy16 back end:
  
! ‘interrupt’
       Use this attribute to indicate that the specified function is an
       interrupt handler.  The compiler generates function entry and exit
       sequences suitable for use in an interrupt handler when this
*************** File: gcc.info,  Node: Variable Attribut
*** 39820,39828 ****
  6.34 Specifying Attributes of Variables
  =======================================
  
! The keyword '__attribute__' allows you to specify special properties of
  variables, function parameters, or structure, union, and, in C++, class
! members.  This '__attribute__' keyword is followed by an attribute
  specification enclosed in double parentheses.  Some attributes are
  currently defined generically for variables.  Other attributes are
  defined for variables on particular target systems.  Other attributes
--- 39829,39837 ----
  6.34 Specifying Attributes of Variables
  =======================================
  
! The keyword ‘__attribute__’ allows you to specify special properties of
  variables, function parameters, or structure, union, and, in C++, class
! members.  This ‘__attribute__’ keyword is followed by an attribute
  specification enclosed in double parentheses.  Some attributes are
  currently defined generically for variables.  Other attributes are
  defined for variables on particular target systems.  Other attributes
*************** File: gcc.info,  Node: Common Variable A
*** 39862,39877 ****
  
  The following attributes are supported on most targets.
  
! 'alias ("TARGET")'
!      The 'alias' variable attribute causes the declaration to be emitted
!      as an alias for another symbol known as an "alias target".  Except
       for top-level qualifiers the alias target must have the same type
       as the alias.  For instance, the following
  
            int var_target;
            extern int __attribute__ ((alias ("var_target"))) var_alias;
  
!      defines 'var_alias' to be an alias for the 'var_target' variable.
  
       It is an error if the alias target is not defined in the same
       translation unit as the alias.
--- 39871,39886 ----
  
  The following attributes are supported on most targets.
  
! ‘alias ("TARGET")’
!      The ‘alias’ variable attribute causes the declaration to be emitted
!      as an alias for another symbol known as an “alias target”.  Except
       for top-level qualifiers the alias target must have the same type
       as the alias.  For instance, the following
  
            int var_target;
            extern int __attribute__ ((alias ("var_target"))) var_alias;
  
!      defines ‘var_alias’ to be an alias for the ‘var_target’ variable.
  
       It is an error if the alias target is not defined in the same
       translation unit as the alias.
*************** The following attributes are supported o
*** 39885,39893 ****
       This attribute requires assembler and object file support, and may
       not be available on all targets.
  
! 'aligned'
! 'aligned (ALIGNMENT)'
!      The 'aligned' attribute specifies a minimum alignment for the
       variable or structure field, measured in bytes.  When specified,
       ALIGNMENT must be an integer constant power of 2.  Specifying no
       ALIGNMENT argument implies the maximum alignment for the target,
--- 39894,39902 ----
       This attribute requires assembler and object file support, and may
       not be available on all targets.
  
! ‘aligned’
! ‘aligned (ALIGNMENT)’
!      The ‘aligned’ attribute specifies a minimum alignment for the
       variable or structure field, measured in bytes.  When specified,
       ALIGNMENT must be an integer constant power of 2.  Specifying no
       ALIGNMENT argument implies the maximum alignment for the target,
*************** The following attributes are supported o
*** 39897,39914 ****
  
            int x __attribute__ ((aligned (16))) = 0;
  
!      causes the compiler to allocate the global variable 'x' on a
       16-byte boundary.  On a 68040, this could be used in conjunction
!      with an 'asm' expression to access the 'move16' instruction which
       requires 16-byte aligned operands.
  
       You can also specify the alignment of structure fields.  For
!      example, to create a double-word aligned 'int' pair, you could
       write:
  
            struct foo { int x[2] __attribute__ ((aligned (8))); };
  
!      This is an alternative to creating a union with a 'double' member,
       which forces the union to be double-word aligned.
  
       As in the preceding examples, you can explicitly specify the
--- 39906,39923 ----
  
            int x __attribute__ ((aligned (16))) = 0;
  
!      causes the compiler to allocate the global variable ‘x’ on a
       16-byte boundary.  On a 68040, this could be used in conjunction
!      with an ‘asm’ expression to access the ‘move16’ instruction which
       requires 16-byte aligned operands.
  
       You can also specify the alignment of structure fields.  For
!      example, to create a double-word aligned ‘int’ pair, you could
       write:
  
            struct foo { int x[2] __attribute__ ((aligned (8))); };
  
!      This is an alternative to creating a union with a ‘double’ member,
       which forces the union to be double-word aligned.
  
       As in the preceding examples, you can explicitly specify the
*************** The following attributes are supported o
*** 39921,39927 ****
       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:
--- 39930,39936 ----
       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:
*************** The following attributes are supported o
*** 39929,39966 ****
            short array[3] __attribute__ ((aligned (__BIGGEST_ALIGNMENT__)));
  
       The compiler automatically sets the alignment for the declared
!      variable or field to '__BIGGEST_ALIGNMENT__'.  Doing this can often
       make copy operations more efficient, because the compiler can use
       whatever instructions copy the biggest chunks of memory when
       performing copies to or from the variables or fields that you have
!      aligned this way.  Note that the value of '__BIGGEST_ALIGNMENT__'
       may change depending on command-line options.
  
!      When used on a struct, or struct member, the 'aligned' attribute
       can only increase the alignment; in order to decrease it, the
!      'packed' attribute must be specified as well.  When used as part of
!      a typedef, the 'aligned' attribute can both increase and decrease
!      alignment, and specifying the 'packed' attribute generates a
       warning.
  
!      Note that the effectiveness of 'aligned' attributes for static
       variables may be limited by inherent limitations in the system
       linker and/or object file format.  On some systems, the linker is
       only able to arrange for variables to be aligned up to a certain
       maximum alignment.  (For some linkers, the maximum supported
       alignment may be very very small.)  If your linker is only able to
       align variables up to a maximum of 8-byte alignment, then
!      specifying 'aligned(16)' in an '__attribute__' still only provides
       you with 8-byte alignment.  See your linker documentation for
       further information.
  
       Stack variables are not affected by linker restrictions; GCC can
       properly align them on any target.
  
!      The 'aligned' attribute can also be used for functions (*note
       Common Function Attributes::.)
  
! 'warn_if_not_aligned (ALIGNMENT)'
       This attribute specifies a threshold for the structure field,
       measured in bytes.  If the structure field is aligned below the
       threshold, a warning will be issued.  For example, the declaration:
--- 39938,39975 ----
            short array[3] __attribute__ ((aligned (__BIGGEST_ALIGNMENT__)));
  
       The compiler automatically sets the alignment for the declared
!      variable or field to ‘__BIGGEST_ALIGNMENT__’.  Doing this can often
       make copy operations more efficient, because the compiler can use
       whatever instructions copy the biggest chunks of memory when
       performing copies to or from the variables or fields that you have
!      aligned this way.  Note that the value of ‘__BIGGEST_ALIGNMENT__’
       may change depending on command-line options.
  
!      When used on a struct, or struct member, the ‘aligned’ attribute
       can only increase the alignment; in order to decrease it, the
!      ‘packed’ attribute must be specified as well.  When used as part of
!      a typedef, the ‘aligned’ attribute can both increase and decrease
!      alignment, and specifying the ‘packed’ attribute generates a
       warning.
  
!      Note that the effectiveness of ‘aligned’ attributes for static
       variables may be limited by inherent limitations in the system
       linker and/or object file format.  On some systems, the linker is
       only able to arrange for variables to be aligned up to a certain
       maximum alignment.  (For some linkers, the maximum supported
       alignment may be very very small.)  If your linker is only able to
       align variables up to a maximum of 8-byte alignment, then
!      specifying ‘aligned(16)’ in an ‘__attribute__’ still only provides
       you with 8-byte alignment.  See your linker documentation for
       further information.
  
       Stack variables are not affected by linker restrictions; GCC can
       properly align them on any target.
  
!      The ‘aligned’ attribute can also be used for functions (*note
       Common Function Attributes::.)
  
! ‘warn_if_not_aligned (ALIGNMENT)’
       This attribute specifies a threshold for the structure field,
       measured in bytes.  If the structure field is aligned below the
       threshold, a warning will be issued.  For example, the declaration:
*************** The following attributes are supported o
*** 39972,39981 ****
              unsigned long long x __attribute__ ((warn_if_not_aligned (16)));
            };
  
!      causes the compiler to issue an warning on 'struct foo', like
!      'warning: alignment 8 of 'struct foo' is less than 16'.  The
!      compiler also issues a warning, like 'warning: 'x' offset 8 in
!      'struct foo' isn't aligned to 16', when the structure field has the
       misaligned offset:
  
            struct __attribute__ ((aligned (16))) foo
--- 39981,39990 ----
              unsigned long long x __attribute__ ((warn_if_not_aligned (16)));
            };
  
!      causes the compiler to issue an warning on ‘struct foo’, like
!      ‘warning: alignment 8 of 'struct foo' is less than 16’.  The
!      compiler also issues a warning, like ‘warning: 'x' offset 8 in
!      'struct foo' isn't aligned to 16’, when the structure field has the
       misaligned offset:
  
            struct __attribute__ ((aligned (16))) foo
*************** The following attributes are supported o
*** 39985,39996 ****
              unsigned long long x __attribute__ ((warn_if_not_aligned (16)));
            };
  
!      This warning can be disabled by '-Wno-if-not-aligned'.  The
!      'warn_if_not_aligned' attribute can also be used for types (*note
       Common Type Attributes::.)
  
! 'strict_flex_array (LEVEL)'
!      The 'strict_flex_array' attribute should be attached to the
       trailing array field of a structure.  It controls when to treat the
       trailing array field of a structure as a flexible array member for
       the purposes of accessing the elements of such an array.  LEVEL
--- 39994,40005 ----
              unsigned long long x __attribute__ ((warn_if_not_aligned (16)));
            };
  
!      This warning can be disabled by ‘-Wno-if-not-aligned’.  The
!      ‘warn_if_not_aligned’ attribute can also be used for types (*note
       Common Type Attributes::.)
  
! ‘strict_flex_array (LEVEL)’
!      The ‘strict_flex_array’ attribute should be attached to the
       trailing array field of a structure.  It controls when to treat the
       trailing array field of a structure as a flexible array member for
       the purposes of accessing the elements of such an array.  LEVEL
*************** The following attributes are supported o
*** 39999,40031 ****
       LEVEL=0 is the least strict level, all trailing arrays of
       structures are treated as flexible array members.  LEVEL=3 is the
       strictest level, only when the trailing array is declared as a
!      flexible array member per C99 standard onwards ('[]'), it is
       treated as a flexible array member.
  
       There are two more levels in between 0 and 3, which are provided to
       support older codes that use GCC zero-length array extension
!      ('[0]') or one-element array as flexible array members ('[1]'):
       When LEVEL is 1, the trailing array is treated as a flexible array
!      member when it is declared as either '[]', '[0]', or '[1]'; When
       LEVEL is 2, the trailing array is treated as a flexible array
!      member when it is declared as either '[]', or '[0]'.
  
       This attribute can be used with or without the
!      '-fstrict-flex-arrays'.  When both the attribute and the option
       present at the same time, the level of the strictness for the
       specific trailing array field is determined by the attribute.
  
! 'alloc_size (POSITION)'
! 'alloc_size (POSITION-1, POSITION-2)'
!      The 'alloc_size' variable attribute may be applied to the
       declaration of a pointer to a function that returns a pointer and
       takes at least one argument of an integer type.  It indicates that
       the returned pointer points to an object whose size is given by the
       function argument at POSITION, or by the product of the arguments
       at POSITION-1 and POSITION-2.  Meaningful sizes are positive values
!      less than 'PTRDIFF_MAX'.  Other sizes are diagnosed when detected.
       GCC uses this information to improve the results of
!      '__builtin_object_size'.
  
       For instance, the following declarations
  
--- 40008,40040 ----
       LEVEL=0 is the least strict level, all trailing arrays of
       structures are treated as flexible array members.  LEVEL=3 is the
       strictest level, only when the trailing array is declared as a
!      flexible array member per C99 standard onwards (‘[]’), it is
       treated as a flexible array member.
  
       There are two more levels in between 0 and 3, which are provided to
       support older codes that use GCC zero-length array extension
!      (‘[0]’) or one-element array as flexible array members (‘[1]’):
       When LEVEL is 1, the trailing array is treated as a flexible array
!      member when it is declared as either ‘[]’, ‘[0]’, or ‘[1]’; When
       LEVEL is 2, the trailing array is treated as a flexible array
!      member when it is declared as either ‘[]’, or ‘[0]’.
  
       This attribute can be used with or without the
!      ‘-fstrict-flex-arrays’.  When both the attribute and the option
       present at the same time, the level of the strictness for the
       specific trailing array field is determined by the attribute.
  
! ‘alloc_size (POSITION)’
! ‘alloc_size (POSITION-1, POSITION-2)’
!      The ‘alloc_size’ variable attribute may be applied to the
       declaration of a pointer to a function that returns a pointer and
       takes at least one argument of an integer type.  It indicates that
       the returned pointer points to an object whose size is given by the
       function argument at POSITION, or by the product of the arguments
       at POSITION-1 and POSITION-2.  Meaningful sizes are positive values
!      less than ‘PTRDIFF_MAX’.  Other sizes are diagnosed when detected.
       GCC uses this information to improve the results of
!      ‘__builtin_object_size’.
  
       For instance, the following declarations
  
*************** The following attributes are supported o
*** 40034,40087 ****
            typedef __attribute__ ((alloc_size (1))) void*
              (*malloc_ptr) (size_t);
  
!      specify that 'calloc_ptr' is a pointer of a function that, like the
!      standard C function 'calloc', returns an object whose size is given
       by the product of arguments 1 and 2, and similarly, that
!      'malloc_ptr', like the standard C function 'malloc', returns an
       object whose size is given by argument 1 to the function.
  
! 'cleanup (CLEANUP_FUNCTION)'
!      The 'cleanup' attribute runs a function when the variable goes out
       of scope.  This attribute can only be applied to auto function
       scope variables; it may not be applied to parameters or variables
       with static storage duration.  The function must take one
       parameter, a pointer to a type compatible with the variable.  The
       return value of the function (if any) is ignored.
  
!      If '-fexceptions' is enabled, then CLEANUP_FUNCTION is run during
       the stack unwinding that happens during the processing of the
!      exception.  Note that the 'cleanup' attribute does not allow the
       exception to be caught, only to perform an action.  It is undefined
       what happens if CLEANUP_FUNCTION does not return normally.
  
! 'common'
! 'nocommon'
!      The 'common' attribute requests GCC to place a variable in "common"
!      storage.  The 'nocommon' attribute requests the opposite--to
       allocate space for it directly.
  
!      These attributes override the default chosen by the '-fno-common'
!      and '-fcommon' flags respectively.
  
! 'copy'
! 'copy (VARIABLE)'
!      The 'copy' attribute applies the set of attributes with which
       VARIABLE has been declared to the declaration of the variable to
       which the attribute is applied.  The attribute is designed for
       libraries that define aliases that are expected to specify the same
!      set of attributes as the aliased symbols.  The 'copy' attribute can
       be used with variables, functions or types.  However, the kind of
       symbol to which the attribute is applied (either varible or
       function) must match the kind of symbol to which the argument
!      refers.  The 'copy' attribute copies only syntactic and semantic
       attributes but not attributes that affect a symbol's linkage or
!      visibility such as 'alias', 'visibility', or 'weak'.  The
!      'deprecated' attribute is also not copied.  *Note Common Function
       Attributes::.  *Note Common Type Attributes::.
  
! '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
--- 40043,40096 ----
            typedef __attribute__ ((alloc_size (1))) void*
              (*malloc_ptr) (size_t);
  
!      specify that ‘calloc_ptr’ is a pointer of a function that, like the
!      standard C function ‘calloc’, returns an object whose size is given
       by the product of arguments 1 and 2, and similarly, that
!      ‘malloc_ptr’, like the standard C function ‘malloc’, returns an
       object whose size is given by argument 1 to the function.
  
! ‘cleanup (CLEANUP_FUNCTION)’
!      The ‘cleanup’ attribute runs a function when the variable goes out
       of scope.  This attribute can only be applied to auto function
       scope variables; it may not be applied to parameters or variables
       with static storage duration.  The function must take one
       parameter, a pointer to a type compatible with the variable.  The
       return value of the function (if any) is ignored.
  
!      If ‘-fexceptions’ is enabled, then CLEANUP_FUNCTION is run during
       the stack unwinding that happens during the processing of the
!      exception.  Note that the ‘cleanup’ attribute does not allow the
       exception to be caught, only to perform an action.  It is undefined
       what happens if CLEANUP_FUNCTION does not return normally.
  
! ‘common’
! ‘nocommon’
!      The ‘common’ attribute requests GCC to place a variable in "common"
!      storage.  The ‘nocommon’ attribute requests the opposite--to
       allocate space for it directly.
  
!      These attributes override the default chosen by the ‘-fno-common’
!      and ‘-fcommon’ flags respectively.
  
! ‘copy’
! ‘copy (VARIABLE)’
!      The ‘copy’ attribute applies the set of attributes with which
       VARIABLE has been declared to the declaration of the variable to
       which the attribute is applied.  The attribute is designed for
       libraries that define aliases that are expected to specify the same
!      set of attributes as the aliased symbols.  The ‘copy’ attribute can
       be used with variables, functions or types.  However, the kind of
       symbol to which the attribute is applied (either varible or
       function) must match the kind of symbol to which the argument
!      refers.  The ‘copy’ attribute copies only syntactic and semantic
       attributes but not attributes that affect a symbol's linkage or
!      visibility such as ‘alias’, ‘visibility’, or ‘weak’.  The
!      ‘deprecated’ attribute is also not copied.  *Note Common Function
       Attributes::.  *Note Common Type Attributes::.
  
! ‘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
*************** The following attributes are supported o
*** 40097,40155 ****
       argument, which must be a string, is printed in the warning if
       present.
  
!      The 'deprecated' attribute can also be used for functions and types
       (*note Common Function Attributes::, *note Common Type
       Attributes::).
  
       The message attached to the attribute is affected by the setting of
!      the '-fmessage-length' option.
  
! 'unavailable'
! 'unavailable (MSG)'
!      The 'unavailable' attribute indicates that the variable so marked
       is not available, if it is used anywhere in the source file.  It
!      behaves in the same manner as the 'deprecated' attribute except
       that the compiler will emit an error rather than a warning.
  
!      It is expected that items marked as 'deprecated' will eventually be
       withdrawn from interfaces, and then become unavailable.  This
       attribute allows for marking them appropriately.
  
!      The 'unavailable' attribute can also be used for functions and
       types (*note Common Function Attributes::, *note Common 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.
  
       *Note (gccint)Machine Modes::, for a list of the possible keywords
!      for MODE.  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.
  
! 'nonstring'
!      The 'nonstring' variable attribute specifies that an object or
!      member declaration with type array of 'char', 'signed char', or
!      'unsigned char', or pointer to such a type is intended to store
       character arrays that do not necessarily contain a terminating
!      'NUL'.  This is useful in detecting uses of such arrays or pointers
!      with functions that expect 'NUL'-terminated strings, and to avoid
       warnings when such an array or pointer is used as an argument to a
!      bounded string manipulation function such as 'strncpy'.  For
       example, without the attribute, GCC will issue a warning for the
!      'strncpy' call below because it may truncate the copy without
!      appending the terminating 'NUL' character.  Using the attribute
       makes it possible to suppress the warning.  However, when the array
!      is declared with the attribute the call to 'strlen' is diagnosed
!      because when the array doesn't contain a 'NUL'-terminated string
       the call is undefined.  To copy, compare, of search non-string
!      character arrays use the 'memcpy', 'memcmp', 'memchr', and other
       functions that operate on arrays of bytes.  In addition, calling
!      'strnlen' and 'strndup' with such arrays is safe provided a
       suitable bound is specified, and not diagnosed.
  
            struct Data
--- 40106,40164 ----
       argument, which must be a string, is printed in the warning if
       present.
  
!      The ‘deprecated’ attribute can also be used for functions and types
       (*note Common Function Attributes::, *note Common Type
       Attributes::).
  
       The message attached to the attribute is affected by the setting of
!      the ‘-fmessage-length’ option.
  
! ‘unavailable’
! ‘unavailable (MSG)’
!      The ‘unavailable’ attribute indicates that the variable so marked
       is not available, if it is used anywhere in the source file.  It
!      behaves in the same manner as the ‘deprecated’ attribute except
       that the compiler will emit an error rather than a warning.
  
!      It is expected that items marked as ‘deprecated’ will eventually be
       withdrawn from interfaces, and then become unavailable.  This
       attribute allows for marking them appropriately.
  
!      The ‘unavailable’ attribute can also be used for functions and
       types (*note Common Function Attributes::, *note Common 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.
  
       *Note (gccint)Machine Modes::, for a list of the possible keywords
!      for MODE.  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.
  
! ‘nonstring’
!      The ‘nonstring’ variable attribute specifies that an object or
!      member declaration with type array of ‘char’, ‘signed char’, or
!      ‘unsigned char’, or pointer to such a type is intended to store
       character arrays that do not necessarily contain a terminating
!      ‘NUL’.  This is useful in detecting uses of such arrays or pointers
!      with functions that expect ‘NUL’-terminated strings, and to avoid
       warnings when such an array or pointer is used as an argument to a
!      bounded string manipulation function such as ‘strncpy’.  For
       example, without the attribute, GCC will issue a warning for the
!      ‘strncpy’ call below because it may truncate the copy without
!      appending the terminating ‘NUL’ character.  Using the attribute
       makes it possible to suppress the warning.  However, when the array
!      is declared with the attribute the call to ‘strlen’ is diagnosed
!      because when the array doesn't contain a ‘NUL’-terminated string
       the call is undefined.  To copy, compare, of search non-string
!      character arrays use the ‘memcpy’, ‘memcmp’, ‘memchr’, and other
       functions that operate on arrays of bytes.  In addition, calling
!      ‘strnlen’ and ‘strndup’ with such arrays is safe provided a
       suitable bound is specified, and not diagnosed.
  
            struct Data
*************** The following attributes are supported o
*** 40164,40178 ****
              return strlen (pd->name);   // unsafe, gets a warning
            }
  
! 'packed'
!      The 'packed' attribute specifies that a structure member should
       have the smallest possible alignment--one bit for a bit-field and
       one byte otherwise, unless a larger value is specified with the
!      'aligned' attribute.  The attribute does not apply to non-member
       objects.
  
!      For example in the structure below, the member array 'x' is packed
!      so that it immediately follows 'a' with no intervening padding:
  
            struct foo
            {
--- 40173,40187 ----
              return strlen (pd->name);   // unsafe, gets a warning
            }
  
! ‘packed’
!      The ‘packed’ attribute specifies that a structure member should
       have the smallest possible alignment--one bit for a bit-field and
       one byte otherwise, unless a larger value is specified with the
!      ‘aligned’ attribute.  The attribute does not apply to non-member
       objects.
  
!      For example in the structure below, the member array ‘x’ is packed
!      so that it immediately follows ‘a’ with no intervening padding:
  
            struct foo
            {
*************** The following attributes are supported o
*** 40180,40197 ****
              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:
  
--- 40189,40206 ----
              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:
  
*************** The following attributes are supported o
*** 40213,40251 ****
              init_duart (&b);
            }
  
!      Use the 'section' attribute with _global_ variables and not _local_
       variables, as shown in the example.
  
!      You may use the 'section' attribute with initialized or
       uninitialized global variables but the linker requires each object
       be defined once, with the exception that uninitialized variables
!      tentatively go in the 'common' (or 'bss') section and can be
!      multiply "defined".  Using the 'section' attribute changes what
       section the variable goes into and may cause the linker to issue an
       error if an uninitialized variable has multiple definitions.  You
!      can force a variable to be initialized with the '-fno-common' flag
!      or the 'nocommon' attribute.
  
       Some file formats do not support arbitrary sections so the
!      'section' attribute is not available on all platforms.  If you need
       to map the entire contents of a module to a particular section,
       consider using the facilities of the linker instead.
  
! '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 or structure field, means
       that the variable or field is meant to be possibly unused.  GCC
       does not produce a warning for this variable or field.
  
! 'used'
       This attribute, attached to a variable with static storage, means
       that the variable must be emitted even if it appears that the
       variable is not referenced.
--- 40222,40260 ----
              init_duart (&b);
            }
  
!      Use the ‘section’ attribute with _global_ variables and not _local_
       variables, as shown in the example.
  
!      You may use the ‘section’ attribute with initialized or
       uninitialized global variables but the linker requires each object
       be defined once, with the exception that uninitialized variables
!      tentatively go in the ‘common’ (or ‘bss’) section and can be
!      multiply "defined".  Using the ‘section’ attribute changes what
       section the variable goes into and may cause the linker to issue an
       error if an uninitialized variable has multiple definitions.  You
!      can force a variable to be initialized with the ‘-fno-common’ flag
!      or the ‘nocommon’ attribute.
  
       Some file formats do not support arbitrary sections so the
!      ‘section’ attribute is not available on all platforms.  If you need
       to map the entire contents of a module to a particular section,
       consider using the facilities of the linker instead.
  
! ‘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 or structure field, means
       that the variable or field is meant to be possibly unused.  GCC
       does not produce a warning for this variable or field.
  
! ‘used’
       This attribute, attached to a variable with static storage, means
       that the variable must be emitted even if it appears that the
       variable is not referenced.
*************** The following attributes are supported o
*** 40254,40275 ****
       attribute also means that the member is instantiated if the class
       itself is instantiated.
  
! 'retain'
       For ELF targets that support the GNU or FreeBSD OSABIs, this
       attribute will save the variable from linker garbage collection.
       To support this behavior, variables that have not been placed in
!      specific sections (e.g.  by the 'section' attribute, or the
!      '-fdata-sections' option), will be placed in new, unique sections.
  
       This additional functionality requires Binutils version 2.36 or
       later.
  
! 'uninitialized'
       This attribute, attached to a variable with automatic storage,
       means that the variable should not be automatically initialized by
!      the compiler when the option '-ftrivial-auto-var-init' presents.
  
!      With the option '-ftrivial-auto-var-init', all the automatic
       variables that do not have explicit initializers will be
       initialized by the compiler.  These additional compiler
       initializations might incur run-time overhead, sometimes
--- 40263,40284 ----
       attribute also means that the member is instantiated if the class
       itself is instantiated.
  
! ‘retain’
       For ELF targets that support the GNU or FreeBSD OSABIs, this
       attribute will save the variable from linker garbage collection.
       To support this behavior, variables that have not been placed in
!      specific sections (e.g.  by the ‘section’ attribute, or the
!      ‘-fdata-sections’ option), will be placed in new, unique sections.
  
       This additional functionality requires Binutils version 2.36 or
       later.
  
! ‘uninitialized’
       This attribute, attached to a variable with automatic storage,
       means that the variable should not be automatically initialized by
!      the compiler when the option ‘-ftrivial-auto-var-init’ presents.
  
!      With the option ‘-ftrivial-auto-var-init’, all the automatic
       variables that do not have explicit initializers will be
       initialized by the compiler.  These additional compiler
       initializations might incur run-time overhead, sometimes
*************** The following attributes are supported o
*** 40278,40298 ****
       runtime overhead.
  
       This attribute has no effect when the option
!      '-ftrivial-auto-var-init' is not present.
  
! 'vector_size (BYTES)'
       This attribute specifies the vector size for the type of the
       declared variable, measured in bytes.  The type to which it applies
!      is known as the "base type".  The BYTES argument must be a positive
       power-of-two multiple of the base type size.  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', 'foo''s
       type is a vector of four units of four bytes each, and the
!      corresponding mode of 'foo' is 'V4SI'.  *Note Vector Extensions::,
       for details of manipulating vector variables.
  
       This attribute is only applicable to integral and floating scalars,
--- 40287,40307 ----
       runtime overhead.
  
       This attribute has no effect when the option
!      ‘-ftrivial-auto-var-init’ is not present.
  
! ‘vector_size (BYTES)’
       This attribute specifies the vector size for the type of the
       declared variable, measured in bytes.  The type to which it applies
!      is known as the “base type”.  The BYTES argument must be a positive
       power-of-two multiple of the base type size.  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’, ‘foo’'s
       type is a vector of four units of four bytes each, and the
!      corresponding mode of ‘foo’ is ‘V4SI’.  *Note Vector Extensions::,
       for details of manipulating vector variables.
  
       This attribute is only applicable to integral and floating scalars,
*************** The following attributes are supported o
*** 40306,40366 ****
            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'.
  
! 'visibility ("VISIBILITY_TYPE")'
       This attribute affects the linkage of the declaration to which it
!      is attached.  The 'visibility' attribute is described in *note
       Common Function Attributes::.
  
! 'weak'
!      The 'weak' attribute is described in *note Common Function
       Attributes::.
  
! 'noinit'
!      Any data with the 'noinit' attribute will not be initialized by the
       C runtime startup code, or the program loader.  Not initializing
       data in this way can reduce program startup times.
  
       This attribute is specific to ELF targets and relies on the linker
!      script to place sections with the '.noinit' prefix in the right
       location.
  
! 'persistent'
!      Any data with the 'persistent' attribute will not be initialized by
       the C runtime startup code, but will be initialized by the program
!      loader.  This enables the value of the variable to 'persist'
       between processor resets.
  
       This attribute is specific to ELF targets and relies on the linker
!      script to place the sections with the '.persistent' prefix in the
       right location.  Specifically, some type of non-volatile, writeable
       memory is required.
  
! 'objc_nullability (NULLABILITY KIND) (Objective-C and Objective-C++ only)'
       This attribute applies to pointer variables only.  It allows
       marking the pointer with one of four possible values describing the
!      conditions under which the pointer might have a 'nil' value.  In
       most cases, the attribute is intended to be an internal
       representation for property and method nullability (specified by
       language keywords); it is not recommended to use it directly.
  
!      When NULLABILITY KIND is '"unspecified"' or '0', nothing is known
!      about the conditions in which the pointer might be 'nil'.  Making
       this state specific serves to avoid false positives in diagnostics.
  
!      When NULLABILITY KIND is '"nonnull"' or '1', the pointer has no
!      meaning if it is 'nil' and thus the compiler is free to emit
!      diagnostics if it can be determined that the value will be 'nil'.
  
!      When NULLABILITY KIND is '"nullable"' or '2', the pointer might be
!      'nil' and carry meaning as such.
  
!      When NULLABILITY KIND is '"resettable"' or '3' (used only in the
       context of property attribute lists) this describes the case in
!      which a property setter may take the value 'nil' (which perhaps
       causes the property to be reset in some manner to a default) but
!      for which the property getter will never validly return 'nil'.
  
  
  File: gcc.info,  Node: ARC Variable Attributes,  Next: AVR Variable Attributes,  Prev: Common Variable Attributes,  Up: Variable Attributes
--- 40315,40375 ----
            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’.
  
! ‘visibility ("VISIBILITY_TYPE")’
       This attribute affects the linkage of the declaration to which it
!      is attached.  The ‘visibility’ attribute is described in *note
       Common Function Attributes::.
  
! ‘weak’
!      The ‘weak’ attribute is described in *note Common Function
       Attributes::.
  
! ‘noinit’
!      Any data with the ‘noinit’ attribute will not be initialized by the
       C runtime startup code, or the program loader.  Not initializing
       data in this way can reduce program startup times.
  
       This attribute is specific to ELF targets and relies on the linker
!      script to place sections with the ‘.noinit’ prefix in the right
       location.
  
! ‘persistent’
!      Any data with the ‘persistent’ attribute will not be initialized by
       the C runtime startup code, but will be initialized by the program
!      loader.  This enables the value of the variable to ‘persist’
       between processor resets.
  
       This attribute is specific to ELF targets and relies on the linker
!      script to place the sections with the ‘.persistent’ prefix in the
       right location.  Specifically, some type of non-volatile, writeable
       memory is required.
  
! ‘objc_nullability (NULLABILITY KIND) (Objective-C and Objective-C++ only)’
       This attribute applies to pointer variables only.  It allows
       marking the pointer with one of four possible values describing the
!      conditions under which the pointer might have a ‘nil’ value.  In
       most cases, the attribute is intended to be an internal
       representation for property and method nullability (specified by
       language keywords); it is not recommended to use it directly.
  
!      When NULLABILITY KIND is ‘"unspecified"’ or ‘0’, nothing is known
!      about the conditions in which the pointer might be ‘nil’.  Making
       this state specific serves to avoid false positives in diagnostics.
  
!      When NULLABILITY KIND is ‘"nonnull"’ or ‘1’, the pointer has no
!      meaning if it is ‘nil’ and thus the compiler is free to emit
!      diagnostics if it can be determined that the value will be ‘nil’.
  
!      When NULLABILITY KIND is ‘"nullable"’ or ‘2’, the pointer might be
!      ‘nil’ and carry meaning as such.
  
!      When NULLABILITY KIND is ‘"resettable"’ or ‘3’ (used only in the
       context of property attribute lists) this describes the case in
!      which a property setter may take the value ‘nil’ (which perhaps
       causes the property to be reset in some manner to a default) but
!      for which the property getter will never validly return ‘nil’.
  
  
  File: gcc.info,  Node: ARC Variable Attributes,  Next: AVR Variable Attributes,  Prev: Common Variable Attributes,  Up: Variable Attributes
*************** File: gcc.info,  Node: ARC Variable Attr
*** 40368,40375 ****
  6.34.2 ARC Variable Attributes
  ------------------------------
  
! 'aux'
!      The 'aux' attribute is used to directly access the ARC's auxiliary
       register space from C. The auxilirary register number is given via
       attribute argument.
  
--- 40377,40384 ----
  6.34.2 ARC Variable Attributes
  ------------------------------
  
! ‘aux’
!      The ‘aux’ attribute is used to directly access the ARC's auxiliary
       register space from C. The auxilirary register number is given via
       attribute argument.
  
*************** File: gcc.info,  Node: AVR Variable Attr
*** 40379,40397 ****
  6.34.3 AVR Variable Attributes
  ------------------------------
  
! 'progmem'
!      The 'progmem' attribute is used on the AVR to place read-only data
!      in the non-volatile program memory (flash).  The 'progmem'
       attribute accomplishes this by putting respective variables into a
!      section whose name starts with '.progmem'.
  
!      This attribute works similar to the 'section' attribute but adds
       additional checking.
  
!      * Ordinary AVR cores with 32 general purpose registers:
!           'progmem' affects the location of the data but not how this
            data is accessed.  In order to read data located with the
!           'progmem' attribute (inline) assembler must be used.
                 /* Use custom macros from AVR-LibC */
                 #include 
  
--- 40388,40406 ----
  6.34.3 AVR Variable Attributes
  ------------------------------
  
! ‘progmem’
!      The ‘progmem’ attribute is used on the AVR to place read-only data
!      in the non-volatile program memory (flash).  The ‘progmem’
       attribute accomplishes this by putting respective variables into a
!      section whose name starts with ‘.progmem’.
  
!      This attribute works similar to the ‘section’ attribute but adds
       additional checking.
  
!      • Ordinary AVR cores with 32 general purpose registers:
!           ‘progmem’ affects the location of the data but not how this
            data is accessed.  In order to read data located with the
!           ‘progmem’ attribute (inline) assembler must be used.
                 /* Use custom macros from AVR-LibC */
                 #include 
  
*************** File: gcc.info,  Node: AVR Variable Attr
*** 40410,40436 ****
            See also the *note AVR Named Address Spaces:: section for an
            alternate way to locate and access data in flash memory.
  
!      * AVR cores with flash memory visible in the RAM address range:
!           On such devices, there is no need for attribute 'progmem' or
!           *note '__flash': AVR Named Address Spaces. qualifier at all.
!           Just use standard C / C++.  The compiler will generate 'LD*'
            instructions.  As flash memory is visible in the RAM address
            range, and the default linker script does _not_ locate
!           '.rodata' in RAM, no special features are needed in order not
            to waste RAM for read-only data or to read from flash.  You
            might even get slightly better performance by avoiding
!           'progmem' and '__flash'.  This applies to devices from
!           families 'avrtiny' and 'avrxmega3', see *note AVR Options::
            for an overview.
  
!      * Reduced AVR Tiny cores like ATtiny40:
!           The compiler adds '0x4000' to the addresses of objects and
!           declarations in 'progmem' and locates the objects in flash
!           memory, namely in section '.progmem.data'.  The offset is
            needed because the flash memory is visible in the RAM address
!           space starting at address '0x4000'.
  
!           Data in 'progmem' can be accessed by means of ordinary C code,
            no special functions or macros are needed.
  
                 /* var is located in flash memory */
--- 40419,40445 ----
            See also the *note AVR Named Address Spaces:: section for an
            alternate way to locate and access data in flash memory.
  
!      • AVR cores with flash memory visible in the RAM address range:
!           On such devices, there is no need for attribute ‘progmem’ or
!           *note ‘__flash’: AVR Named Address Spaces. qualifier at all.
!           Just use standard C / C++.  The compiler will generate ‘LD*’
            instructions.  As flash memory is visible in the RAM address
            range, and the default linker script does _not_ locate
!           ‘.rodata’ in RAM, no special features are needed in order not
            to waste RAM for read-only data or to read from flash.  You
            might even get slightly better performance by avoiding
!           ‘progmem’ and ‘__flash’.  This applies to devices from
!           families ‘avrtiny’ and ‘avrxmega3’, see *note AVR Options::
            for an overview.
  
!      • Reduced AVR Tiny cores like ATtiny40:
!           The compiler adds ‘0x4000’ to the addresses of objects and
!           declarations in ‘progmem’ and locates the objects in flash
!           memory, namely in section ‘.progmem.data’.  The offset is
            needed because the flash memory is visible in the RAM address
!           space starting at address ‘0x4000’.
  
!           Data in ‘progmem’ can be accessed by means of ordinary C code,
            no special functions or macros are needed.
  
                 /* var is located in flash memory */
*************** File: gcc.info,  Node: AVR Variable Attr
*** 40442,40452 ****
                 }
  
            Please notice that on these devices, there is no need for
!           'progmem' at all.
  
! 'io'
! 'io (ADDR)'
!      Variables with the 'io' attribute are used to address memory-mapped
       peripherals in the io address range.  If an address is specified,
       the variable is assigned that address, and the value is interpreted
       as an address in the data address space.  Example:
--- 40451,40461 ----
                 }
  
            Please notice that on these devices, there is no need for
!           ‘progmem’ at all.
  
! ‘io’
! ‘io (ADDR)’
!      Variables with the ‘io’ attribute are used to address memory-mapped
       peripherals in the io address range.  If an address is specified,
       the variable is assigned that address, and the value is interpreted
       as an address in the data address space.  Example:
*************** File: gcc.info,  Node: AVR Variable Attr
*** 40462,40501 ****
  
            extern volatile int porta __attribute__((io));
  
! 'io_low'
! 'io_low (ADDR)'
!      This is like the 'io' attribute, but additionally it informs the
       compiler that the object lies in the lower half of the I/O area,
!      allowing the use of 'cbi', 'sbi', 'sbic' and 'sbis' instructions.
  
! 'address'
! 'address (ADDR)'
!      Variables with the 'address' attribute are used to address
       memory-mapped peripherals that may lie outside the io address
       range.
  
            volatile int porta __attribute__((address (0x600)));
  
! 'absdata'
!      Variables in static storage and with the 'absdata' attribute can be
!      accessed by the 'LDS' and 'STS' instructions which take absolute
       addresses.
  
!         * This attribute is only supported for the reduced AVR Tiny core
            like ATtiny40.
  
!         * You must make sure that respective data is located in the
!           address range '0x40'...'0xbf' accessible by 'LDS' and 'STS'.
            One way to achieve this as an appropriate linker description
            file.
  
!         * If the location does not fit the address range of 'LDS' and
!           'STS', there is currently (Binutils 2.26) just an unspecific
            warning like
!                'module.cc:(.text+0x1c): warning: internal error: out of
!                range error'
  
!      See also the '-mabsdata' *note command-line option: AVR Options.
  
  
  File: gcc.info,  Node: Blackfin Variable Attributes,  Next: H8/300 Variable Attributes,  Prev: AVR Variable Attributes,  Up: Variable Attributes
--- 40471,40510 ----
  
            extern volatile int porta __attribute__((io));
  
! ‘io_low’
! ‘io_low (ADDR)’
!      This is like the ‘io’ attribute, but additionally it informs the
       compiler that the object lies in the lower half of the I/O area,
!      allowing the use of ‘cbi’, ‘sbi’, ‘sbic’ and ‘sbis’ instructions.
  
! ‘address’
! ‘address (ADDR)’
!      Variables with the ‘address’ attribute are used to address
       memory-mapped peripherals that may lie outside the io address
       range.
  
            volatile int porta __attribute__((address (0x600)));
  
! ‘absdata’
!      Variables in static storage and with the ‘absdata’ attribute can be
!      accessed by the ‘LDS’ and ‘STS’ instructions which take absolute
       addresses.
  
!         • This attribute is only supported for the reduced AVR Tiny core
            like ATtiny40.
  
!         • You must make sure that respective data is located in the
!           address range ‘0x40’...‘0xbf’ accessible by ‘LDS’ and ‘STS’.
            One way to achieve this as an appropriate linker description
            file.
  
!         • If the location does not fit the address range of ‘LDS’ and
!           ‘STS’, there is currently (Binutils 2.26) just an unspecific
            warning like
!                ‘module.cc:(.text+0x1c): warning: internal error: out of
!                range error’
  
!      See also the ‘-mabsdata’ *note command-line option: AVR Options.
  
  
  File: gcc.info,  Node: Blackfin Variable Attributes,  Next: H8/300 Variable Attributes,  Prev: AVR Variable Attributes,  Up: Variable Attributes
*************** File: gcc.info,  Node: Blackfin Variable
*** 40505,40524 ****
  
  Three attributes are currently defined for the Blackfin.
  
! 'l1_data'
! 'l1_data_A'
! 'l1_data_B'
       Use these attributes on the Blackfin to place the variable into L1
!      Data SRAM. Variables with 'l1_data' attribute are put into the
!      specific section named '.l1.data'.  Those with 'l1_data_A'
!      attribute are put into the specific section named '.l1.data.A'.
!      Those with 'l1_data_B' attribute are put into the specific section
!      named '.l1.data.B'.
  
! 'l2'
       Use this attribute on the Blackfin to place the variable into L2
!      SRAM. Variables with 'l2' attribute are put into the specific
!      section named '.l2.data'.
  
  
  File: gcc.info,  Node: H8/300 Variable Attributes,  Next: IA-64 Variable Attributes,  Prev: Blackfin Variable Attributes,  Up: Variable Attributes
--- 40514,40533 ----
  
  Three attributes are currently defined for the Blackfin.
  
! ‘l1_data’
! ‘l1_data_A’
! ‘l1_data_B’
       Use these attributes on the Blackfin to place the variable into L1
!      Data SRAM. Variables with ‘l1_data’ attribute are put into the
!      specific section named ‘.l1.data’.  Those with ‘l1_data_A’
!      attribute are put into the specific section named ‘.l1.data.A’.
!      Those with ‘l1_data_B’ attribute are put into the specific section
!      named ‘.l1.data.B’.
  
! ‘l2’
       Use this attribute on the Blackfin to place the variable into L2
!      SRAM. Variables with ‘l2’ attribute are put into the specific
!      section named ‘.l2.data’.
  
  
  File: gcc.info,  Node: H8/300 Variable Attributes,  Next: IA-64 Variable Attributes,  Prev: Blackfin Variable Attributes,  Up: Variable Attributes
*************** File: gcc.info,  Node: H8/300 Variable A
*** 40528,40534 ****
  
  These variable attributes are available for H8/300 targets:
  
! 'eightbit_data'
       Use this attribute on the H8/300, H8/300H, and H8S to indicate that
       the specified variable should be placed into the eight-bit data
       section.  The compiler generates more efficient code for certain
--- 40537,40543 ----
  
  These variable attributes are available for H8/300 targets:
  
! ‘eightbit_data’
       Use this attribute on the H8/300, H8/300H, and H8S to indicate that
       the specified variable should be placed into the eight-bit data
       section.  The compiler generates more efficient code for certain
*************** These variable attributes are available
*** 40538,40544 ****
       You must use GAS and GLD from GNU binutils version 2.7 or later for
       this attribute to work correctly.
  
! 'tiny_data'
       Use this attribute on the H8/300H and H8S to indicate that the
       specified variable should be placed into the tiny data section.
       The compiler generates more efficient code for loads and stores on
--- 40547,40553 ----
       You must use GAS and GLD from GNU binutils version 2.7 or later for
       this attribute to work correctly.
  
! ‘tiny_data’
       Use this attribute on the H8/300H and H8S to indicate that the
       specified variable should be placed into the tiny data section.
       The compiler generates more efficient code for loads and stores on
*************** File: gcc.info,  Node: IA-64 Variable At
*** 40553,40564 ****
  
  The IA-64 back end supports the following variable attribute:
  
! 'model (MODEL-NAME)'
  
       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.
--- 40562,40573 ----
  
  The IA-64 back end supports the following variable attribute:
  
! ‘model (MODEL-NAME)’
  
       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.
*************** File: gcc.info,  Node: LoongArch Variabl
*** 40571,40583 ****
  
  One attribute is currently defined for the LoongArch.
  
! 'model("NAME")'
       Use this attribute on the LoongArch to use a different code model
       for addressing this variable, than the code model specified by the
!      global '-mcmodel' option.  This attribute is mostly useful if a
!      'section' attribute and/or a linker script will locate this object
       specially.  Currently the only supported values of NAME are
!      'normal' and 'extreme'.
  
  
  File: gcc.info,  Node: M32R/D Variable Attributes,  Next: Microsoft Windows Variable Attributes,  Prev: LoongArch Variable Attributes,  Up: Variable Attributes
--- 40580,40592 ----
  
  One attribute is currently defined for the LoongArch.
  
! ‘model("NAME")’
       Use this attribute on the LoongArch to use a different code model
       for addressing this variable, than the code model specified by the
!      global ‘-mcmodel’ option.  This attribute is mostly useful if a
!      ‘section’ attribute and/or a linker script will locate this object
       specially.  Currently the only supported values of NAME are
!      ‘normal’ and ‘extreme’.
  
  
  File: gcc.info,  Node: M32R/D Variable Attributes,  Next: Microsoft Windows Variable Attributes,  Prev: LoongArch Variable Attributes,  Up: Variable Attributes
*************** File: gcc.info,  Node: M32R/D Variable A
*** 40587,40602 ****
  
  One attribute is currently defined for the M32R/D.
  
! 'model (MODEL-NAME)'
       Use this attribute on the M32R/D to set the addressability of an
!      object.  The identifier MODEL-NAME is one of 'small', 'medium', or
!      'large', representing each of the code models.
  
       Small model objects live in the lower 16MB of memory (so that their
!      addresses can be loaded with the 'ld24' instruction).
  
       Medium and large model objects may live anywhere in the 32-bit
!      address space (the compiler generates 'seth/add3' instructions to
       load their addresses).
  
  
--- 40596,40611 ----
  
  One attribute is currently defined for the M32R/D.
  
! ‘model (MODEL-NAME)’
       Use this attribute on the M32R/D to set the addressability of an
!      object.  The identifier MODEL-NAME is one of ‘small’, ‘medium’, or
!      ‘large’, representing each of the code models.
  
       Small model objects live in the lower 16MB of memory (so that their
!      addresses can be loaded with the ‘ld24’ instruction).
  
       Medium and large model objects may live anywhere in the 32-bit
!      address space (the compiler generates ‘seth/add3’ instructions to
       load their addresses).
  
  
*************** You can use these attributes on Microsof
*** 40609,40621 ****
  Variable Attributes:: for additional Windows compatibility attributes
  available on all x86 targets.
  
! 'dllimport'
! 'dllexport'
!      The 'dllimport' and 'dllexport' attributes are described in *note
       Microsoft Windows Function Attributes::.
  
! '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
--- 40618,40630 ----
  Variable Attributes:: for additional Windows compatibility attributes
  available on all x86 targets.
  
! ‘dllimport’
! ‘dllexport’
!      The ‘dllimport’ and ‘dllexport’ attributes are described in *note
       Microsoft Windows Function Attributes::.
  
! ‘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
*************** available on all x86 targets.
*** 40630,40646 ****
       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.
  
! '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;
  
--- 40639,40655 ----
       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.
  
! ‘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;
  
*************** available on all x86 targets.
*** 40652,40662 ****
              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.
  
  
  File: gcc.info,  Node: MSP430 Variable Attributes,  Next: Nvidia PTX Variable Attributes,  Prev: Microsoft Windows Variable Attributes,  Up: Variable Attributes
--- 40661,40671 ----
              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.
  
  
  File: gcc.info,  Node: MSP430 Variable Attributes,  Next: Nvidia PTX Variable Attributes,  Prev: Microsoft Windows Variable Attributes,  Up: Variable Attributes
*************** File: gcc.info,  Node: MSP430 Variable A
*** 40664,40690 ****
  6.34.10 MSP430 Variable Attributes
  ----------------------------------
  
! 'upper'
! 'either'
       These attributes are the same as the MSP430 function attributes of
       the same name (*note MSP430 Function Attributes::).
  
! 'lower'
       This option behaves mostly the same as the MSP430 function
       attribute of the same name (*note MSP430 Function Attributes::),
       but it has some additional functionality.
  
!      If '-mdata-region='{'upper,either,none'} has been passed, or the
!      'section' attribute is applied to a variable, the compiler will
       generate 430X instructions to handle it.  This is because the
       compiler has to assume that the variable could get placed in the
       upper memory region (above address 0xFFFF). Marking the variable
!      with the 'lower' attribute informs the compiler that the variable
       will be placed in lower memory so it is safe to use 430
       instructions to handle it.
  
!      In the case of the 'section' attribute, the section name given will
!      be used, and the '.lower' prefix will not be added.
  
  
  File: gcc.info,  Node: Nvidia PTX Variable Attributes,  Next: PowerPC Variable Attributes,  Prev: MSP430 Variable Attributes,  Up: Variable Attributes
--- 40673,40699 ----
  6.34.10 MSP430 Variable Attributes
  ----------------------------------
  
! ‘upper’
! ‘either’
       These attributes are the same as the MSP430 function attributes of
       the same name (*note MSP430 Function Attributes::).
  
! ‘lower’
       This option behaves mostly the same as the MSP430 function
       attribute of the same name (*note MSP430 Function Attributes::),
       but it has some additional functionality.
  
!      If ‘-mdata-region=’{‘upper,either,none’} has been passed, or the
!      ‘section’ attribute is applied to a variable, the compiler will
       generate 430X instructions to handle it.  This is because the
       compiler has to assume that the variable could get placed in the
       upper memory region (above address 0xFFFF). Marking the variable
!      with the ‘lower’ attribute informs the compiler that the variable
       will be placed in lower memory so it is safe to use 430
       instructions to handle it.
  
!      In the case of the ‘section’ attribute, the section name given will
!      be used, and the ‘.lower’ prefix will not be added.
  
  
  File: gcc.info,  Node: Nvidia PTX Variable Attributes,  Next: PowerPC Variable Attributes,  Prev: MSP430 Variable Attributes,  Up: Variable Attributes
*************** File: gcc.info,  Node: Nvidia PTX Variab
*** 40694,40701 ****
  
  These variable attributes are supported by the Nvidia PTX back end:
  
! 'shared'
!      Use this attribute to place a variable in the '.shared' memory
       space.  This memory space is private to each cooperative thread
       array; only threads within one thread block refer to the same
       instance of the variable.  The runtime does not initialize
--- 40703,40710 ----
  
  These variable attributes are supported by the Nvidia PTX back end:
  
! ‘shared’
!      Use this attribute to place a variable in the ‘.shared’ memory
       space.  This memory space is private to each cooperative thread
       array; only threads within one thread block refer to the same
       instance of the variable.  The runtime does not initialize
*************** File: gcc.info,  Node: PowerPC Variable
*** 40708,40719 ****
  -----------------------------------
  
  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 x86 Variable Attributes::.
  
!  For documentation of 'altivec' attribute please see the documentation
  in *note PowerPC Type Attributes::.
  
  
--- 40717,40728 ----
  -----------------------------------
  
  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 x86 Variable Attributes::.
  
!  For documentation of ‘altivec’ attribute please see the documentation
  in *note PowerPC Type Attributes::.
  
  
*************** File: gcc.info,  Node: RL78 Variable Att
*** 40722,40728 ****
  6.34.13 RL78 Variable Attributes
  --------------------------------
  
! The RL78 back end supports the 'saddr' variable attribute.  This
  specifies placement of the corresponding variable in the SADDR area,
  which can be accessed more efficiently than the default memory region.
  
--- 40731,40737 ----
  6.34.13 RL78 Variable Attributes
  --------------------------------
  
! The RL78 back end supports the ‘saddr’ variable attribute.  This
  specifies placement of the corresponding variable in the SADDR area,
  which can be accessed more efficiently than the default memory region.
  
*************** File: gcc.info,  Node: V850 Variable Att
*** 40734,40748 ****
  
  These variable attributes are supported by the V850 back end:
  
! 'sda'
       Use this attribute to explicitly place a variable in the small data
       area, which can hold up to 64 kilobytes.
  
! 'tda'
       Use this attribute to explicitly place a variable in the tiny data
       area, which can hold up to 256 bytes in total.
  
! 'zda'
       Use this attribute to explicitly place a variable in the first 32
       kilobytes of memory.
  
--- 40743,40757 ----
  
  These variable attributes are supported by the V850 back end:
  
! ‘sda’
       Use this attribute to explicitly place a variable in the small data
       area, which can hold up to 64 kilobytes.
  
! ‘tda’
       Use this attribute to explicitly place a variable in the tiny data
       area, which can hold up to 256 bytes in total.
  
! ‘zda’
       Use this attribute to explicitly place a variable in the first 32
       kilobytes of memory.
  
*************** File: gcc.info,  Node: x86 Variable Attr
*** 40752,40772 ****
  6.34.15 x86 Variable Attributes
  -------------------------------
  
! Two attributes are currently defined for x86 configurations: 'ms_struct'
! and 'gcc_struct'.
  
! 'ms_struct'
! 'gcc_struct'
  
!      If 'packed' is used on a structure, or if bit-fields are used, it
       may be that the Microsoft ABI lays out the structure differently
       than the way GCC normally does.  Particularly when moving packed
       data between functions compiled with GCC and the native Microsoft
       compiler (either via function call or as data in a file), it may be
       necessary to access either format.
  
!      The 'ms_struct' and 'gcc_struct' attributes correspond to the
!      '-mms-bitfields' and '-mno-ms-bitfields' command-line options,
       respectively; see *note x86 Options::, for details of how structure
       layout is affected.  *Note x86 Type Attributes::, for information
       about the corresponding attributes on types.
--- 40761,40781 ----
  6.34.15 x86 Variable Attributes
  -------------------------------
  
! Two attributes are currently defined for x86 configurations: ‘ms_struct’
! and ‘gcc_struct’.
  
! ‘ms_struct’
! ‘gcc_struct’
  
!      If ‘packed’ is used on a structure, or if bit-fields are used, it
       may be that the Microsoft ABI lays out the structure differently
       than the way GCC normally does.  Particularly when moving packed
       data between functions compiled with GCC and the native Microsoft
       compiler (either via function call or as data in a file), it may be
       necessary to access either format.
  
!      The ‘ms_struct’ and ‘gcc_struct’ attributes correspond to the
!      ‘-mms-bitfields’ and ‘-mno-ms-bitfields’ command-line options,
       respectively; see *note x86 Options::, for details of how structure
       layout is affected.  *Note x86 Type Attributes::, for information
       about the corresponding attributes on types.
*************** File: gcc.info,  Node: Xstormy16 Variabl
*** 40778,40791 ****
  -------------------------------------
  
  One attribute is currently defined for xstormy16 configurations:
! 'below100'.
  
! 'below100'
  
!      If a variable has the 'below100' attribute ('BELOW100' is allowed
       also), GCC places the variable in the first 0x100 bytes of memory
       and use special opcodes to access it.  Such variables are placed in
!      either the '.bss_below100' section or the '.data_below100' section.
  
  
  File: gcc.info,  Node: Type Attributes,  Next: Label Attributes,  Prev: Variable Attributes,  Up: C Extensions
--- 40787,40800 ----
  -------------------------------------
  
  One attribute is currently defined for xstormy16 configurations:
! ‘below100’.
  
! ‘below100’
  
!      If a variable has the ‘below100’ attribute (‘BELOW100’ is allowed
       also), GCC places the variable in the first 0x100 bytes of memory
       and use special opcodes to access it.  Such variables are placed in
!      either the ‘.bss_below100’ section or the ‘.data_below100’ section.
  
  
  File: gcc.info,  Node: Type Attributes,  Next: Label Attributes,  Prev: Variable Attributes,  Up: C Extensions
*************** File: gcc.info,  Node: Type Attributes,
*** 40793,40802 ****
  6.35 Specifying Attributes of Types
  ===================================
  
! The keyword '__attribute__' allows you to specify various special
  properties of types.  Some type attributes apply only to structure and
  union types, and in C++, also class types, while others can apply to any
! type defined via a 'typedef' declaration.  Unless otherwise specified,
  the same restrictions and effects apply to attributes regardless of
  whether a type is a trivial structure or a C++ class with user-defined
  constructors, destructors, or a copy assignment.
--- 40802,40811 ----
  6.35 Specifying Attributes of Types
  ===================================
  
! The keyword ‘__attribute__’ allows you to specify various special
  properties of types.  Some type attributes apply only to structure and
  union types, and in C++, also class types, while others can apply to any
! type defined via a ‘typedef’ declaration.  Unless otherwise specified,
  the same restrictions and effects apply to attributes regardless of
  whether a type is a trivial structure or a C++ class with user-defined
  constructors, destructors, or a copy assignment.
*************** Attributes::), labels (*note Label Attri
*** 40806,40821 ****
  Enumerator Attributes::), statements (*note Statement Attributes::), and
  for variables (*note Variable Attributes::).
  
!  The '__attribute__' keyword is followed by an attribute specification
  enclosed in double parentheses.
  
   You may specify type attributes in an enum, struct or union type
  declaration or definition by placing them immediately after the
! 'struct', 'union' or 'enum' keyword.  You can also place them just past
  the closing curly brace of the definition, but this is less preferred
  because logically the type should be fully defined at the closing brace.
  
!  You can also include type attributes in a 'typedef' declaration.  *Note
  Attribute Syntax::, for details of the exact syntax for using
  attributes.
  
--- 40815,40830 ----
  Enumerator Attributes::), statements (*note Statement Attributes::), and
  for variables (*note Variable Attributes::).
  
!  The ‘__attribute__’ keyword is followed by an attribute specification
  enclosed in double parentheses.
  
   You may specify type attributes in an enum, struct or union type
  declaration or definition by placing them immediately after the
! ‘struct’, ‘union’ or ‘enum’ keyword.  You can also place them just past
  the closing curly brace of the definition, but this is less preferred
  because logically the type should be fully defined at the closing brace.
  
!  You can also include type attributes in a ‘typedef’ declaration.  *Note
  Attribute Syntax::, for details of the exact syntax for using
  attributes.
  
*************** File: gcc.info,  Node: Common Type Attri
*** 40836,40844 ****
  
  The following type attributes are supported on most targets.
  
! 'aligned'
! 'aligned (ALIGNMENT)'
!      The 'aligned' attribute specifies a minimum alignment (in bytes)
       for variables of the specified type.  When specified, ALIGNMENT
       must be a power of 2.  Specifying no ALIGNMENT argument implies the
       maximum alignment for the target, which is often, but by no means
--- 40845,40853 ----
  
  The following type attributes are supported on most targets.
  
! ‘aligned’
! ‘aligned (ALIGNMENT)’
!      The ‘aligned’ attribute specifies a minimum alignment (in bytes)
       for variables of the specified type.  When specified, ALIGNMENT
       must be a power of 2.  Specifying no ALIGNMENT argument implies the
       maximum alignment for the target, which is often, but by no means
*************** The following type attributes are suppor
*** 40848,40880 ****
            typedef int more_aligned_int __attribute__ ((aligned (8)));
  
       force the compiler to ensure (as far as it can) that each variable
!      whose type is 'struct S' or 'more_aligned_int' is allocated and
       aligned _at least_ on a 8-byte boundary.  On a SPARC, having all
!      variables of type 'struct S' aligned to 8-byte boundaries allows
!      the compiler to use the 'ldd' and 'std' (doubleword load and store)
!      instructions when copying one variable of type 'struct S' to
       another, thus improving run-time efficiency.
  
!      Note that the alignment of any given 'struct' or 'union' type is
       required by the ISO C standard to be at least a perfect multiple of
       the lowest common multiple of the alignments of all of the members
!      of the 'struct' or 'union' in question.  This means that you _can_
!      effectively adjust the alignment of a 'struct' or 'union' type by
!      attaching an 'aligned' attribute to any one of the members of such
       a type, but the notation illustrated in the example above is a more
       obvious, intuitive, and readable way to request the compiler to
!      adjust the alignment of an entire 'struct' or 'union' type.
  
       As in the preceding example, you can explicitly specify the
       alignment (in bytes) that you wish the compiler to use for a given
!      'struct' or 'union' type.  Alternatively, you can leave out the
       alignment factor and just ask the compiler to align a type to the
       maximum useful alignment for the target machine you are compiling
       for.  For example, you could write:
  
            struct __attribute__ ((aligned)) S { short f[3]; };
  
!      Whenever you leave out the alignment factor in an 'aligned'
       attribute specification, the compiler automatically sets the
       alignment for the type to the largest alignment that is ever used
       for any data type on the target machine you are compiling for.
--- 40857,40889 ----
            typedef int more_aligned_int __attribute__ ((aligned (8)));
  
       force the compiler to ensure (as far as it can) that each variable
!      whose type is ‘struct S’ or ‘more_aligned_int’ is allocated and
       aligned _at least_ on a 8-byte boundary.  On a SPARC, having all
!      variables of type ‘struct S’ aligned to 8-byte boundaries allows
!      the compiler to use the ‘ldd’ and ‘std’ (doubleword load and store)
!      instructions when copying one variable of type ‘struct S’ to
       another, thus improving run-time efficiency.
  
!      Note that the alignment of any given ‘struct’ or ‘union’ type is
       required by the ISO C standard to be at least a perfect multiple of
       the lowest common multiple of the alignments of all of the members
!      of the ‘struct’ or ‘union’ in question.  This means that you _can_
!      effectively adjust the alignment of a ‘struct’ or ‘union’ type by
!      attaching an ‘aligned’ attribute to any one of the members of such
       a type, but the notation illustrated in the example above is a more
       obvious, intuitive, and readable way to request the compiler to
!      adjust the alignment of an entire ‘struct’ or ‘union’ type.
  
       As in the preceding example, you can explicitly specify the
       alignment (in bytes) that you wish the compiler to use for a given
!      ‘struct’ or ‘union’ type.  Alternatively, you can leave out the
       alignment factor and just ask the compiler to align a type to the
       maximum useful alignment for the target machine you are compiling
       for.  For example, you could write:
  
            struct __attribute__ ((aligned)) S { short f[3]; };
  
!      Whenever you leave out the alignment factor in an ‘aligned’
       attribute specification, the compiler automatically sets the
       alignment for the type to the largest alignment that is ever used
       for any data type on the target machine you are compiling for.
*************** The following type attributes are suppor
*** 40883,40892 ****
       of memory when performing copies to or from the variables that have
       types that you have aligned this way.
  
!      In the example above, if the size of each 'short' is 2 bytes, then
!      the size of the entire 'struct S' type is 6 bytes.  The smallest
       power of two that is greater than or equal to that is 8, so the
!      compiler sets the alignment for the entire 'struct S' type to 8
       bytes.
  
       Note that although you can ask the compiler to select a
--- 40892,40901 ----
       of memory when performing copies to or from the variables that have
       types that you have aligned this way.
  
!      In the example above, if the size of each ‘short’ is 2 bytes, then
!      the size of the entire ‘struct S’ type is 6 bytes.  The smallest
       power of two that is greater than or equal to that is 8, so the
!      compiler sets the alignment for the entire ‘struct S’ type to 8
       bytes.
  
       Note that although you can ask the compiler to select a
*************** The following type attributes are suppor
*** 40902,40925 ****
       operations is often more efficient for efficiently-aligned types
       than for other types.
  
!      Note that the effectiveness of 'aligned' attributes may be limited
       by inherent limitations in your linker.  On many systems, the
       linker is only able to arrange for variables to be aligned up to a
       certain maximum alignment.  (For some linkers, the maximum
       supported alignment may be very very small.)  If your linker is
       only able to align variables up to a maximum of 8-byte alignment,
!      then specifying 'aligned (16)' in an '__attribute__' still only
       provides you with 8-byte alignment.  See your linker documentation
       for further information.
  
!      When used on a struct, or struct member, the 'aligned' attribute
       can only increase the alignment; in order to decrease it, the
!      'packed' attribute must be specified as well.  When used as part of
!      a typedef, the 'aligned' attribute can both increase and decrease
!      alignment, and specifying the 'packed' attribute generates a
       warning.
  
! 'warn_if_not_aligned (ALIGNMENT)'
       This attribute specifies a threshold for the structure field,
       measured in bytes.  If the structure field is aligned below the
       threshold, a warning will be issued.  For example, the declaration:
--- 40911,40934 ----
       operations is often more efficient for efficiently-aligned types
       than for other types.
  
!      Note that the effectiveness of ‘aligned’ attributes may be limited
       by inherent limitations in your linker.  On many systems, the
       linker is only able to arrange for variables to be aligned up to a
       certain maximum alignment.  (For some linkers, the maximum
       supported alignment may be very very small.)  If your linker is
       only able to align variables up to a maximum of 8-byte alignment,
!      then specifying ‘aligned (16)’ in an ‘__attribute__’ still only
       provides you with 8-byte alignment.  See your linker documentation
       for further information.
  
!      When used on a struct, or struct member, the ‘aligned’ attribute
       can only increase the alignment; in order to decrease it, the
!      ‘packed’ attribute must be specified as well.  When used as part of
!      a typedef, the ‘aligned’ attribute can both increase and decrease
!      alignment, and specifying the ‘packed’ attribute generates a
       warning.
  
! ‘warn_if_not_aligned (ALIGNMENT)’
       This attribute specifies a threshold for the structure field,
       measured in bytes.  If the structure field is aligned below the
       threshold, a warning will be issued.  For example, the declaration:
*************** The following type attributes are suppor
*** 40934,40944 ****
              __u64 x;
            };
  
!      causes the compiler to issue an warning on 'struct foo', like
!      'warning: alignment 4 of 'struct foo' is less than 8'.  It is used
!      to define 'struct foo' in such a way that 'struct foo' has the same
!      layout and the structure field 'x' has the same alignment when
!      '__u64' is aligned at either 4 or 8 bytes.  Align 'struct foo' to 8
       bytes:
  
            struct __attribute__ ((aligned (8))) foo
--- 40943,40953 ----
              __u64 x;
            };
  
!      causes the compiler to issue an warning on ‘struct foo’, like
!      ‘warning: alignment 4 of 'struct foo' is less than 8’.  It is used
!      to define ‘struct foo’ in such a way that ‘struct foo’ has the same
!      layout and the structure field ‘x’ has the same alignment when
!      ‘__u64’ is aligned at either 4 or 8 bytes.  Align ‘struct foo’ to 8
       bytes:
  
            struct __attribute__ ((aligned (8))) foo
*************** The following type attributes are suppor
*** 40949,40955 ****
            };
  
       silences the warning.  The compiler also issues a warning, like
!      'warning: 'x' offset 12 in 'struct foo' isn't aligned to 8', when
       the structure field has the misaligned offset:
  
            struct __attribute__ ((aligned (8))) foo
--- 40958,40964 ----
            };
  
       silences the warning.  The compiler also issues a warning, like
!      ‘warning: 'x' offset 12 in 'struct foo' isn't aligned to 8’, when
       the structure field has the misaligned offset:
  
            struct __attribute__ ((aligned (8))) foo
*************** The following type attributes are suppor
*** 40960,40978 ****
              __u64 x;
            };
  
!      This warning can be disabled by '-Wno-if-not-aligned'.
  
! 'alloc_size (POSITION)'
! 'alloc_size (POSITION-1, POSITION-2)'
!      The 'alloc_size' type attribute may be applied to the definition of
       a type of a function that returns a pointer and takes at least one
       argument of an integer type.  It indicates that the returned
       pointer points to an object whose size is given by the function
       argument at POSITION-1, or by the product of the arguments at
       POSITION-1 and POSITION-2.  Meaningful sizes are positive values
!      less than 'PTRDIFF_MAX'.  Other sizes are disagnosed when detected.
       GCC uses this information to improve the results of
!      '__builtin_object_size'.
  
       For instance, the following declarations
  
--- 40969,40987 ----
              __u64 x;
            };
  
!      This warning can be disabled by ‘-Wno-if-not-aligned’.
  
! ‘alloc_size (POSITION)’
! ‘alloc_size (POSITION-1, POSITION-2)’
!      The ‘alloc_size’ type attribute may be applied to the definition of
       a type of a function that returns a pointer and takes at least one
       argument of an integer type.  It indicates that the returned
       pointer points to an object whose size is given by the function
       argument at POSITION-1, or by the product of the arguments at
       POSITION-1 and POSITION-2.  Meaningful sizes are positive values
!      less than ‘PTRDIFF_MAX’.  Other sizes are disagnosed when detected.
       GCC uses this information to improve the results of
!      ‘__builtin_object_size’.
  
       For instance, the following declarations
  
*************** The following type attributes are suppor
*** 40981,41023 ****
            typedef __attribute__ ((alloc_size (1))) void*
              malloc_type (size_t);
  
!      specify that 'calloc_type' is a type of a function that, like the
!      standard C function 'calloc', returns an object whose size is given
!      by the product of arguments 1 and 2, and that 'malloc_type', like
!      the standard C function 'malloc', returns an object whose size is
       given by argument 1 to the function.
  
! 'copy'
! 'copy (EXPRESSION)'
!      The 'copy' attribute applies the set of attributes with which the
       type of the EXPRESSION has been declared to the declaration of the
       type to which the attribute is applied.  The attribute is designed
       for libraries that define aliases that are expected to specify the
!      same set of attributes as the aliased symbols.  The 'copy'
       attribute can be used with types, variables, or functions.
       However, the kind of symbol to which the attribute is applied
       (either varible or function) must match the kind of symbol to which
!      the argument refers.  The 'copy' attribute copies only syntactic
       and semantic attributes but not attributes that affect a symbol's
!      linkage or visibility such as 'alias', 'visibility', or 'weak'.
!      The 'deprecated' attribute is also not copied.  *Note Common
       Function Attributes::.  *Note Common Variable Attributes::.
  
!      For example, suppose 'struct A' below is defined in some third
!      party library header to have the alignment requirement 'N' and to
       force a warning whenever a variable of the type is not so aligned
!      due to attribute 'packed'.  Specifying the 'copy' attribute on the
!      definition on the unrelated 'struct B' has the effect of copying
       all relevant attributes from the type referenced by the pointer
!      expression to 'struct B'.
  
            struct __attribute__ ((aligned (N), warn_if_not_aligned (N)))
            A { /* ... */ };
            struct __attribute__ ((copy ( (struct A *)0)) B { /* ... */ };
  
! '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
--- 40990,41032 ----
            typedef __attribute__ ((alloc_size (1))) void*
              malloc_type (size_t);
  
!      specify that ‘calloc_type’ is a type of a function that, like the
!      standard C function ‘calloc’, returns an object whose size is given
!      by the product of arguments 1 and 2, and that ‘malloc_type’, like
!      the standard C function ‘malloc’, returns an object whose size is
       given by argument 1 to the function.
  
! ‘copy’
! ‘copy (EXPRESSION)’
!      The ‘copy’ attribute applies the set of attributes with which the
       type of the EXPRESSION has been declared to the declaration of the
       type to which the attribute is applied.  The attribute is designed
       for libraries that define aliases that are expected to specify the
!      same set of attributes as the aliased symbols.  The ‘copy’
       attribute can be used with types, variables, or functions.
       However, the kind of symbol to which the attribute is applied
       (either varible or function) must match the kind of symbol to which
!      the argument refers.  The ‘copy’ attribute copies only syntactic
       and semantic attributes but not attributes that affect a symbol's
!      linkage or visibility such as ‘alias’, ‘visibility’, or ‘weak’.
!      The ‘deprecated’ attribute is also not copied.  *Note Common
       Function Attributes::.  *Note Common Variable Attributes::.
  
!      For example, suppose ‘struct A’ below is defined in some third
!      party library header to have the alignment requirement ‘N’ and to
       force a warning whenever a variable of the type is not so aligned
!      due to attribute ‘packed’.  Specifying the ‘copy’ attribute on the
!      definition on the unrelated ‘struct B’ has the effect of copying
       all relevant attributes from the type referenced by the pointer
!      expression to ‘struct B’.
  
            struct __attribute__ ((aligned (N), warn_if_not_aligned (N)))
            A { /* ... */ };
            struct __attribute__ ((copy ( (struct A *)0)) B { /* ... */ };
  
! ‘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
*************** The following type attributes are suppor
*** 41040,41067 ****
       deprecated.  Similarly for line 6.  The optional MSG argument,
       which must be a string, is printed in the warning if present.
       Control characters in the string will be replaced with escape
!      sequences, and if the '-fmessage-length' option is set to 0 (its
       default value) then any newline characters will be ignored.
  
!      The 'deprecated' attribute can also be used for functions and
       variables (*note Function Attributes::, *note Variable
       Attributes::.)
  
       The message attached to the attribute is affected by the setting of
!      the '-fmessage-length' option.
  
! 'unavailable'
! 'unavailable (MSG)'
!      The 'unavailable' attribute behaves in the same manner as the
!      'deprecated' one, but emits an error rather than a warning.  It is
!      used to indicate that a (perhaps previously 'deprecated') type is
       no longer usable.
  
!      The 'unavailable' attribute can also be used for functions and
       variables (*note Function Attributes::, *note Variable
       Attributes::.)
  
! 'designated_init'
       This attribute may only be applied to structure types.  It
       indicates that any initialization of an object of this type must
       use designated initializers rather than positional initializers.
--- 41049,41076 ----
       deprecated.  Similarly for line 6.  The optional MSG argument,
       which must be a string, is printed in the warning if present.
       Control characters in the string will be replaced with escape
!      sequences, and if the ‘-fmessage-length’ option is set to 0 (its
       default value) then any newline characters will be ignored.
  
!      The ‘deprecated’ attribute can also be used for functions and
       variables (*note Function Attributes::, *note Variable
       Attributes::.)
  
       The message attached to the attribute is affected by the setting of
!      the ‘-fmessage-length’ option.
  
! ‘unavailable’
! ‘unavailable (MSG)’
!      The ‘unavailable’ attribute behaves in the same manner as the
!      ‘deprecated’ one, but emits an error rather than a warning.  It is
!      used to indicate that a (perhaps previously ‘deprecated’) type is
       no longer usable.
  
!      The ‘unavailable’ attribute can also be used for functions and
       variables (*note Function Attributes::, *note Variable
       Attributes::.)
  
! ‘designated_init’
       This attribute may only be applied to structure types.  It
       indicates that any initialization of an object of this type must
       use designated initializers rather than positional initializers.
*************** The following type attributes are suppor
*** 41070,41084 ****
       positional initialization will result in future breakage.
  
       GCC emits warnings based on this attribute by default; use
!      '-Wno-designated-init' to suppress them.
  
! 'may_alias'
       Accesses through pointers to types with this attribute are not
       subject to type-based alias analysis, but are instead assumed to be
       able to alias any other type of objects.  In the context of section
       6.5 paragraph 7 of the C99 standard, an lvalue expression
       dereferencing such a pointer is treated like having a character
!      type.  See '-fstrict-aliasing' for more information on aliasing
       issues.  This extension exists to support some vector APIs, in
       which pointers to one vector type are permitted to alias pointers
       to a different vector type.
--- 41079,41093 ----
       positional initialization will result in future breakage.
  
       GCC emits warnings based on this attribute by default; use
!      ‘-Wno-designated-init’ to suppress them.
  
! ‘may_alias’
       Accesses through pointers to types with this attribute are not
       subject to type-based alias analysis, but are instead assumed to be
       able to alias any other type of objects.  In the context of section
       6.5 paragraph 7 of the C99 standard, an lvalue expression
       dereferencing such a pointer is treated like having a character
!      type.  See ‘-fstrict-aliasing’ for more information on aliasing
       issues.  This extension exists to support some vector APIs, in
       which pointers to one vector type are permitted to alias pointers
       to a different vector type.
*************** The following type attributes are suppor
*** 41104,41141 ****
              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.
  
! '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.
  
       *Note (gccint)Machine Modes::, for a list of the possible keywords
!      for MODE.  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'
!      This attribute, attached to a 'struct', 'union', or C++ 'class'
       type definition, specifies that each of its members (other than
       zero-width bit-fields) is placed to minimize the memory required.
!      This is equivalent to specifying the 'packed' attribute on each of
       the members.
  
!      When attached to an 'enum' definition, the 'packed' attribute
       indicates that the smallest integral type should be used.
!      Specifying the '-fshort-enums' flag on the command line is
!      equivalent to specifying the 'packed' attribute on all 'enum'
       definitions.
  
!      In the following example 'struct my_packed_struct''s members are
!      packed closely together, but the internal layout of its 's' member
!      is not packed--to do that, 'struct my_unpacked_struct' needs to be
       packed too.
  
            struct my_unpacked_struct
--- 41113,41150 ----
              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.
  
! ‘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.
  
       *Note (gccint)Machine Modes::, for a list of the possible keywords
!      for MODE.  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’
!      This attribute, attached to a ‘struct’, ‘union’, or C++ ‘class’
       type definition, specifies that each of its members (other than
       zero-width bit-fields) is placed to minimize the memory required.
!      This is equivalent to specifying the ‘packed’ attribute on each of
       the members.
  
!      When attached to an ‘enum’ definition, the ‘packed’ attribute
       indicates that the smallest integral type should be used.
!      Specifying the ‘-fshort-enums’ flag on the command line is
!      equivalent to specifying the ‘packed’ attribute on all ‘enum’
       definitions.
  
!      In the following example ‘struct my_packed_struct’'s members are
!      packed closely together, but the internal layout of its ‘s’ member
!      is not packed--to do that, ‘struct my_unpacked_struct’ needs to be
       packed too.
  
            struct my_unpacked_struct
*************** The following type attributes are suppor
*** 41151,41167 ****
                 struct my_unpacked_struct s;
              };
  
!      You may only specify the 'packed' attribute on the definition of an
!      'enum', 'struct', 'union', or 'class', not on a 'typedef' that does
       not also define the enumerated type, structure, union, or class.
  
! 'scalar_storage_order ("ENDIANNESS")'
!      When attached to a 'union' or a 'struct', this attribute sets the
       storage order, aka endianness, of the scalar fields of the type, as
       well as the array fields whose component is scalar.  The supported
!      endiannesses are 'big-endian' and 'little-endian'.  The attribute
!      has no effects on fields which are themselves a 'union', a 'struct'
!      or an array whose component is a 'union' or a 'struct', and it is
       possible for these fields to have a different scalar storage order
       than the enclosing type.
  
--- 41160,41176 ----
                 struct my_unpacked_struct s;
              };
  
!      You may only specify the ‘packed’ attribute on the definition of an
!      ‘enum’, ‘struct’, ‘union’, or ‘class’, not on a ‘typedef’ that does
       not also define the enumerated type, structure, union, or class.
  
! ‘scalar_storage_order ("ENDIANNESS")’
!      When attached to a ‘union’ or a ‘struct’, this attribute sets the
       storage order, aka endianness, of the scalar fields of the type, as
       well as the array fields whose component is scalar.  The supported
!      endiannesses are ‘big-endian’ and ‘little-endian’.  The attribute
!      has no effects on fields which are themselves a ‘union’, a ‘struct’
!      or an array whose component is a ‘union’ or a ‘struct’, and it is
       possible for these fields to have a different scalar storage order
       than the enclosing type.
  
*************** The following type attributes are suppor
*** 41178,41191 ****
       scalar storage order with regard to the scalar storage order of the
       target:
  
!         * Taking the address of a scalar field of a 'union' or a
!           'struct' with reverse scalar storage order is not permitted
            and yields an error.
!         * Taking the address of an array field, whose component is
!           scalar, of a 'union' or a 'struct' with reverse scalar storage
            order is permitted but yields a warning, unless
!           '-Wno-scalar-storage-order' is specified.
!         * Taking the address of a 'union' or a 'struct' with reverse
            scalar storage order is permitted.
  
       These restrictions exist because the storage order attribute is
--- 41187,41200 ----
       scalar storage order with regard to the scalar storage order of the
       target:
  
!         • Taking the address of a scalar field of a ‘union’ or a
!           ‘struct’ with reverse scalar storage order is not permitted
            and yields an error.
!         • Taking the address of an array field, whose component is
!           scalar, of a ‘union’ or a ‘struct’ with reverse scalar storage
            order is permitted but yields a warning, unless
!           ‘-Wno-scalar-storage-order’ is specified.
!         • Taking the address of a ‘union’ or a ‘struct’ with reverse
            scalar storage order is permitted.
  
       These restrictions exist because the storage order attribute is
*************** The following type attributes are suppor
*** 41199,41207 ****
       can be accessed through distinct types that assign a different
       storage order to it, then the behavior is undefined.
  
! '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.
  
--- 41208,41216 ----
       can be accessed through distinct types that assign a different
       storage order to it, then the behavior is undefined.
  
! ‘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.
  
*************** The following type attributes are suppor
*** 41211,41217 ****
       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
--- 41220,41226 ----
       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
*************** The following type attributes are suppor
*** 41222,41233 ****
  
       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, '' might define the
       interface as follows:
  
            typedef union __attribute__ ((__transparent_union__))
--- 41231,41242 ----
  
       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, ‘’ might define the
       interface as follows:
  
            typedef union __attribute__ ((__transparent_union__))
*************** The following type attributes are suppor
*** 41238,41259 ****
  
            pid_t wait (wait_status_ptr_t);
  
!      This interface allows either 'int *' or 'union wait *' arguments to
!      be passed, using the 'int *' calling convention.  The program can
!      call 'wait' with arguments of either type:
  
            int w1 () { int w; return wait (&w); }
            int w2 () { union wait w; return wait (&w); }
  
!      With this interface, 'wait''s implementation might look like this:
  
            pid_t wait (wait_status_ptr_t p)
            {
              return waitpid (-1, p.__ip, 0);
            }
  
! 'unused'
!      When attached to a type (including a 'union' or a 'struct'), this
       attribute means that variables of that type are meant to appear
       possibly unused.  GCC does not produce a warning for any variables
       of that type, even if the variable appears to do nothing.  This is
--- 41247,41268 ----
  
            pid_t wait (wait_status_ptr_t);
  
!      This interface allows either ‘int *’ or ‘union wait *’ arguments to
!      be passed, using the ‘int *’ calling convention.  The program can
!      call ‘wait’ with arguments of either type:
  
            int w1 () { int w; return wait (&w); }
            int w2 () { union wait w; return wait (&w); }
  
!      With this interface, ‘wait’'s implementation might look like this:
  
            pid_t wait (wait_status_ptr_t p)
            {
              return waitpid (-1, p.__ip, 0);
            }
  
! ‘unused’
!      When attached to a type (including a ‘union’ or a ‘struct’), this
       attribute means that variables of that type are meant to appear
       possibly unused.  GCC does not produce a warning for any variables
       of that type, even if the variable appears to do nothing.  This is
*************** The following type attributes are suppor
*** 41261,41269 ****
       defined and then not referenced, but contain constructors and
       destructors that have nontrivial bookkeeping functions.
  
! 'vector_size (BYTES)'
       This attribute specifies the vector size for the type, measured in
!      bytes.  The type to which it applies is known as the "base type".
       The BYTES argument must be a positive power-of-two multiple of the
       base type size.  For example, the following declarations:
  
--- 41270,41278 ----
       defined and then not referenced, but contain constructors and
       destructors that have nontrivial bookkeeping functions.
  
! ‘vector_size (BYTES)’
       This attribute specifies the vector size for the type, measured in
!      bytes.  The type to which it applies is known as the “base type”.
       The BYTES argument must be a positive power-of-two multiple of the
       base type size.  For example, the following declarations:
  
*************** The following type attributes are suppor
*** 41271,41281 ****
            typedef __attribute__ ((vector_size (32))) int* int_vec32_ptr_t;
            typedef __attribute__ ((vector_size (32))) int int_vec32_arr3_t[3];
  
!      define 'int_vec32_t' to be a 32-byte vector type composed of 'int'
!      sized units.  With 'int' having a size of 4 bytes, the type defines
       a vector of eight units, four bytes each.  The mode of variables of
!      type 'int_vec32_t' is 'V8SI'.  'int_vec32_ptr_t' is then defined to
!      be a pointer to such a vector type, and 'int_vec32_arr3_t' to be an
       array of three such vectors.  *Note Vector Extensions::, for
       details of manipulating objects of vector types.
  
--- 41280,41290 ----
            typedef __attribute__ ((vector_size (32))) int* int_vec32_ptr_t;
            typedef __attribute__ ((vector_size (32))) int int_vec32_arr3_t[3];
  
!      define ‘int_vec32_t’ to be a 32-byte vector type composed of ‘int’
!      sized units.  With ‘int’ having a size of 4 bytes, the type defines
       a vector of eight units, four bytes each.  The mode of variables of
!      type ‘int_vec32_t’ is ‘V8SI’.  ‘int_vec32_ptr_t’ is then defined to
!      be a pointer to such a vector type, and ‘int_vec32_arr3_t’ to be an
       array of three such vectors.  *Note Vector Extensions::, for
       details of manipulating objects of vector types.
  
*************** The following type attributes are suppor
*** 41285,41294 ****
  
       For example, the following:
            __attribute__ ((vector_size (16))) float get_flt_vec16 (void);
!      declares 'get_flt_vec16' to be a function returning a 16-byte
!      vector with the base type 'float'.
  
! '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
--- 41294,41303 ----
  
       For example, the following:
            __attribute__ ((vector_size (16))) float get_flt_vec16 (void);
!      declares ‘get_flt_vec16’ to be a function returning a 16-byte
!      vector with the base type ‘float’.
  
! ‘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
*************** The following type attributes are suppor
*** 41302,41315 ****
       visibility.  Otherwise the two shared objects are unable to use the
       same typeinfo node and exception handling will break.
  
! 'objc_root_class (Objective-C and Objective-C++ only)'
       This attribute marks a class as being a root class, and thus allows
       the compiler to elide any warnings about a missing superclass and
       to make additional checks for mandatory methods as needed.
  
   To specify multiple attributes, separate them by commas within the
! double parentheses: for example, '__attribute__ ((aligned (16),
! packed))'.
  
  
  File: gcc.info,  Node: ARC Type Attributes,  Next: ARM Type Attributes,  Prev: Common Type Attributes,  Up: Type Attributes
--- 41311,41324 ----
       visibility.  Otherwise the two shared objects are unable to use the
       same typeinfo node and exception handling will break.
  
! ‘objc_root_class (Objective-C and Objective-C++ only)’
       This attribute marks a class as being a root class, and thus allows
       the compiler to elide any warnings about a missing superclass and
       to make additional checks for mandatory methods as needed.
  
   To specify multiple attributes, separate them by commas within the
! double parentheses: for example, ‘__attribute__ ((aligned (16),
! packed))’.
  
  
  File: gcc.info,  Node: ARC Type Attributes,  Next: ARM Type Attributes,  Prev: Common Type Attributes,  Up: Type Attributes
*************** File: gcc.info,  Node: ARC Type Attribut
*** 41317,41327 ****
  6.35.2 ARC Type Attributes
  --------------------------
  
! Declaring objects with 'uncached' allows you to exclude data-cache
  participation in load and store operations on those objects without
! involving the additional semantic implications of 'volatile'.  The '.di'
  instruction suffix is used for all loads and stores of data declared
! 'uncached'.
  
  
  File: gcc.info,  Node: ARM Type Attributes,  Next: BPF Type Attributes,  Prev: ARC Type Attributes,  Up: Type Attributes
--- 41326,41336 ----
  6.35.2 ARC Type Attributes
  --------------------------
  
! Declaring objects with ‘uncached’ allows you to exclude data-cache
  participation in load and store operations on those objects without
! involving the additional semantic implications of ‘volatile’.  The ‘.di’
  instruction suffix is used for all loads and stores of data declared
! ‘uncached’.
  
  
  File: gcc.info,  Node: ARM Type Attributes,  Next: BPF Type Attributes,  Prev: ARC Type Attributes,  Up: Type Attributes
*************** File: gcc.info,  Node: ARM Type Attribut
*** 41329,41336 ****
  6.35.3 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:
  
--- 41338,41345 ----
  6.35.3 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:
  
*************** example:
*** 41343,41351 ****
       __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'.)
  
  
  File: gcc.info,  Node: BPF Type Attributes,  Next: PowerPC Type Attributes,  Prev: ARM Type Attributes,  Up: Type Attributes
--- 41352,41360 ----
       __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’.)
  
  
  File: gcc.info,  Node: BPF Type Attributes,  Next: PowerPC Type Attributes,  Prev: ARM Type Attributes,  Up: Type Attributes
*************** File: gcc.info,  Node: BPF Type Attribut
*** 41354,41363 ****
  --------------------------
  
  BPF Compile Once - Run Everywhere (CO-RE) support.  When attached to a
! 'struct' or 'union' type definition, indicates that CO-RE relocation
  information should be generated for any access to a variable of that
  type.  The behavior is equivalent to the programmer manually wrapping
! every such access with '__builtin_preserve_access_index'.
  
  
  File: gcc.info,  Node: PowerPC Type Attributes,  Next: x86 Type Attributes,  Prev: BPF Type Attributes,  Up: Type Attributes
--- 41363,41372 ----
  --------------------------
  
  BPF Compile Once - Run Everywhere (CO-RE) support.  When attached to a
! ‘struct’ or ‘union’ type definition, indicates that CO-RE relocation
  information should be generated for any access to a variable of that
  type.  The behavior is equivalent to the programmer manually wrapping
! every such access with ‘__builtin_preserve_access_index’.
  
  
  File: gcc.info,  Node: PowerPC Type Attributes,  Next: x86 Type Attributes,  Prev: BPF Type Attributes,  Up: Type Attributes
*************** File: gcc.info,  Node: PowerPC Type Attr
*** 41366,41388 ****
  ------------------------------
  
  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 x86 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.
  
  
  File: gcc.info,  Node: x86 Type Attributes,  Prev: PowerPC Type Attributes,  Up: Type Attributes
--- 41375,41397 ----
  ------------------------------
  
  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 x86 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.
  
  
  File: gcc.info,  Node: x86 Type Attributes,  Prev: PowerPC Type Attributes,  Up: Type Attributes
*************** File: gcc.info,  Node: x86 Type Attribut
*** 41390,41410 ****
  6.35.6 x86 Type Attributes
  --------------------------
  
! Two attributes are currently defined for x86 configurations: 'ms_struct'
! and 'gcc_struct'.
  
! 'ms_struct'
! 'gcc_struct'
  
!      If 'packed' is used on a structure, or if bit-fields are used it
       may be that the Microsoft ABI packs them differently than GCC
       normally packs them.  Particularly when moving packed data between
       functions compiled with GCC and the native Microsoft compiler
       (either via function call or as data in a file), it may be
       necessary to access either format.
  
!      The 'ms_struct' and 'gcc_struct' attributes correspond to the
!      '-mms-bitfields' and '-mno-ms-bitfields' command-line options,
       respectively; see *note x86 Options::, for details of how structure
       layout is affected.  *Note x86 Variable Attributes::, for
       information about the corresponding attributes on variables.
--- 41399,41419 ----
  6.35.6 x86 Type Attributes
  --------------------------
  
! Two attributes are currently defined for x86 configurations: ‘ms_struct’
! and ‘gcc_struct’.
  
! ‘ms_struct’
! ‘gcc_struct’
  
!      If ‘packed’ is used on a structure, or if bit-fields are used it
       may be that the Microsoft ABI packs them differently than GCC
       normally packs them.  Particularly when moving packed data between
       functions compiled with GCC and the native Microsoft compiler
       (either via function call or as data in a file), it may be
       necessary to access either format.
  
!      The ‘ms_struct’ and ‘gcc_struct’ attributes correspond to the
!      ‘-mms-bitfields’ and ‘-mno-ms-bitfields’ command-line options,
       respectively; see *note x86 Options::, for details of how structure
       layout is affected.  *Note x86 Variable Attributes::, for
       information about the corresponding attributes on variables.
*************** Attributes::), statements (*note Stateme
*** 41423,41431 ****
  (*note Type Attributes::).  A label attribute followed by a declaration
  appertains to the label and not the declaration.
  
!  This example uses the 'cold' label attribute to indicate the
! 'ErrorHandling' branch is unlikely to be taken and that the
! 'ErrorHandling' label is unused:
  
  
          asm goto ("some asm" : : : : NoError);
--- 41432,41440 ----
  (*note Type Attributes::).  A label attribute followed by a declaration
  appertains to the label and not the declaration.
  
!  This example uses the ‘cold’ label attribute to indicate the
! ‘ErrorHandling’ branch is unlikely to be taken and that the
! ‘ErrorHandling’ label is unused:
  
  
          asm goto ("some asm" : : : : NoError);
*************** appertains to the label and not the decl
*** 41440,41464 ****
          printf("no error\n");
          return 1;
  
! 'unused'
       This feature is intended for program-generated code that may
!      contain unused labels, but which is compiled with '-Wall'.  It is
       not normally appropriate to use in it human-written code, though it
       could be useful in cases where the code that jumps to the label is
!      contained within an '#ifdef' conditional.
  
! 'hot'
!      The 'hot' attribute on a label is used to inform the compiler that
       the path following the label is more likely than paths that are not
       so annotated.  This attribute is used in cases where
!      '__builtin_expect' cannot be used, for instance with computed goto
!      or 'asm goto'.
  
! 'cold'
!      The 'cold' attribute on labels is used to inform the compiler that
       the path following the label is unlikely to be executed.  This
!      attribute is used in cases where '__builtin_expect' cannot be used,
!      for instance with computed goto or 'asm goto'.
  
  
  File: gcc.info,  Node: Enumerator Attributes,  Next: Statement Attributes,  Prev: Label Attributes,  Up: C Extensions
--- 41449,41473 ----
          printf("no error\n");
          return 1;
  
! ‘unused’
       This feature is intended for program-generated code that may
!      contain unused labels, but which is compiled with ‘-Wall’.  It is
       not normally appropriate to use in it human-written code, though it
       could be useful in cases where the code that jumps to the label is
!      contained within an ‘#ifdef’ conditional.
  
! ‘hot’
!      The ‘hot’ attribute on a label is used to inform the compiler that
       the path following the label is more likely than paths that are not
       so annotated.  This attribute is used in cases where
!      ‘__builtin_expect’ cannot be used, for instance with computed goto
!      or ‘asm goto’.
  
! ‘cold’
!      The ‘cold’ attribute on labels is used to inform the compiler that
       the path following the label is unlikely to be executed.  This
!      attribute is used in cases where ‘__builtin_expect’ cannot be used,
!      for instance with computed goto or ‘asm goto’.
  
  
  File: gcc.info,  Node: Enumerator Attributes,  Next: Statement Attributes,  Prev: Label Attributes,  Up: C Extensions
*************** variables (*note Variable Attributes::),
*** 41473,41480 ****
  Attributes::), statements (*note Statement Attributes::), and for types
  (*note Type Attributes::).
  
!  This example uses the 'deprecated' enumerator attribute to indicate the
! 'oldval' enumerator is deprecated:
  
       enum E {
         oldval __attribute__((deprecated)),
--- 41482,41489 ----
  Attributes::), statements (*note Statement Attributes::), and for types
  (*note Type Attributes::).
  
!  This example uses the ‘deprecated’ enumerator attribute to indicate the
! ‘oldval’ enumerator is deprecated:
  
       enum E {
         oldval __attribute__((deprecated)),
*************** Attributes::), statements (*note Stateme
*** 41487,41494 ****
         return oldval;
       }
  
! 'deprecated'
!      The 'deprecated' attribute results in a warning if the enumerator
       is used anywhere in the source file.  This is useful when
       identifying enumerators that are expected to be removed in a future
       version of a program.  The warning also includes the location of
--- 41496,41503 ----
         return oldval;
       }
  
! ‘deprecated’
!      The ‘deprecated’ attribute results in a warning if the enumerator
       is used anywhere in the source file.  This is useful when
       identifying enumerators that are expected to be removed in a future
       version of a program.  The warning also includes the location of
*************** Attributes::), statements (*note Stateme
*** 41497,41506 ****
       deprecated, or what they should do instead.  Note that the warnings
       only occurs for uses.
  
! 'unavailable'
!      The 'unavailable' attribute results in an error if the enumerator
       is used anywhere in the source file.  In other respects it behaves
!      in the same manner as the 'deprecated' attribute.
  
  
  File: gcc.info,  Node: Statement Attributes,  Next: Attribute Syntax,  Prev: Enumerator Attributes,  Up: C Extensions
--- 41506,41515 ----
       deprecated, or what they should do instead.  Note that the warnings
       only occurs for uses.
  
! ‘unavailable’
!      The ‘unavailable’ attribute results in an error if the enumerator
       is used anywhere in the source file.  In other respects it behaves
!      in the same manner as the ‘deprecated’ attribute.
  
  
  File: gcc.info,  Node: Statement Attributes,  Next: Attribute Syntax,  Prev: Enumerator Attributes,  Up: C Extensions
*************** variables (*note Variable Attributes::),
*** 41515,41534 ****
  Attributes::), enumerators (*note Enumerator Attributes::), and for
  types (*note Type Attributes::).
  
! 'fallthrough'
!      The 'fallthrough' attribute with a null statement serves as a
       fallthrough statement.  It hints to the compiler that a statement
       that falls through to another case label, or user-defined label in
       a switch statement is intentional and thus the
!      '-Wimplicit-fallthrough' warning must not trigger.  The fallthrough
       attribute may appear at most once in each attribute list, and may
       not be mixed with other attributes.  It can only be used in a
       switch statement (the compiler will issue an error otherwise),
       after a preceding statement and before a logically succeeding case
       label, or user-defined label.
  
!      This example uses the 'fallthrough' statement attribute to indicate
!      that the '-Wimplicit-fallthrough' warning should not be emitted:
  
            switch (cond)
              {
--- 41524,41543 ----
  Attributes::), enumerators (*note Enumerator Attributes::), and for
  types (*note Type Attributes::).
  
! ‘fallthrough’
!      The ‘fallthrough’ attribute with a null statement serves as a
       fallthrough statement.  It hints to the compiler that a statement
       that falls through to another case label, or user-defined label in
       a switch statement is intentional and thus the
!      ‘-Wimplicit-fallthrough’ warning must not trigger.  The fallthrough
       attribute may appear at most once in each attribute list, and may
       not be mixed with other attributes.  It can only be used in a
       switch statement (the compiler will issue an error otherwise),
       after a preceding statement and before a logically succeeding case
       label, or user-defined label.
  
!      This example uses the ‘fallthrough’ statement attribute to indicate
!      that the ‘-Wimplicit-fallthrough’ warning should not be emitted:
  
            switch (cond)
              {
*************** types (*note Type Attributes::).
*** 41539,41551 ****
                ...
              }
  
! 'assume'
!      The 'assume' attribute with a null statement serves as portable
       assumption.  It should have a single argument, a conditional
       expression, which is not evaluated.  If the argument would evaluate
       to true at the point where it appears, it has no effect, otherwise
       there is undefined behavior.  This is a GNU variant of the ISO
!      C++23 standard 'assume' attribute, but it can be used in any
       version of both C and C++.
  
            int
--- 41548,41560 ----
                ...
              }
  
! ‘assume’
!      The ‘assume’ attribute with a null statement serves as portable
       assumption.  It should have a single argument, a conditional
       expression, which is not evaluated.  If the argument would evaluate
       to true at the point where it appears, it has no effect, otherwise
       there is undefined behavior.  This is a GNU variant of the ISO
!      C++23 standard ‘assume’ attribute, but it can be used in any
       version of both C and C++.
  
            int
*************** types (*note Type Attributes::).
*** 41556,41563 ****
              return x + y;
            }
  
!      'y' is not actually incremented and the compiler can but does not
!      have to optimize it to just 'return 42 + 42;'.
  
  
  File: gcc.info,  Node: Attribute Syntax,  Next: Function Prototypes,  Prev: Statement Attributes,  Up: C Extensions
--- 41565,41572 ----
              return x + y;
            }
  
!      ‘y’ is not actually incremented and the compiler can but does not
!      have to optimize it to just ‘return 42 + 42;’.
  
  
  File: gcc.info,  Node: Attribute Syntax,  Next: Function Prototypes,  Prev: Statement Attributes,  Up: C Extensions
*************** File: gcc.info,  Node: Attribute Syntax,
*** 41565,41571 ****
  6.39 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
  limitations in the grammar for attributes, some forms described here may
--- 41574,41580 ----
  6.39 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
  limitations in the grammar for attributes, some forms described here may
*************** not be successfully parsed in all cases.
*** 41574,41580 ****
   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.
--- 41583,41589 ----
   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.
*************** Attributes::, for details of the semanti
*** 41589,41633 ****
  enumerators.  *Note Statement Attributes::, for details of the semantics
  of attributes applying to statements.
  
!  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.
  
!    * An attribute name (which may be an identifier such as 'unused', or
!      a reserved word such as 'const').
  
!    * An attribute name followed by a parenthesized list of 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.
  
!  You may optionally specify attribute names with '__' preceding and
  following the name.  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 the attribute name '__noreturn__' instead of 'noreturn'.
  
  Label Attributes
  ................
  
  In GNU C, an attribute specifier list may appear after the colon
! following a label, other than a 'case' or 'default' label.  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
--- 41598,41642 ----
  enumerators.  *Note Statement Attributes::, for details of the semantics
  of attributes applying to statements.
  
!  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.
  
!    • An attribute name (which may be an identifier such as ‘unused’, or
!      a reserved word such as ‘const’).
  
!    • An attribute name followed by a parenthesized list of 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.
  
!  You may optionally specify attribute names with ‘__’ preceding and
  following the name.  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 the attribute name ‘__noreturn__’ instead of ‘noreturn’.
  
  Label Attributes
  ................
  
  In GNU C, an attribute specifier list may appear after the colon
! following a label, other than a ‘case’ or ‘default’ label.  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
*************** Enumerator Attributes
*** 41640,41646 ****
  
  In GNU C, an attribute specifier list may appear as part of an
  enumerator.  The attribute goes after the enumeration constant, before
! '=', if present.  The optional attribute in the enumerator appertains to
  the enumeration constant.  It is not possible to place the attribute
  after the constant expression, if present.
  
--- 41649,41655 ----
  
  In GNU C, an attribute specifier list may appear as part of an
  enumerator.  The attribute goes after the enumeration constant, before
! ‘=’, if present.  The optional attribute in the enumerator appertains to
  the enumeration constant.  It is not possible to place the attribute
  after the constant expression, if present.
  
*************** statement.  The attribute goes before th
*** 41653,41661 ****
  Type Attributes
  ...............
  
! 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
--- 41662,41670 ----
  Type Attributes
  ...............
  
! 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
*************** contain attribute specifiers, whether or
*** 41680,41700 ****
  context contain storage class specifiers.  (Some attributes, however,
  are essentially in the nature of storage class specifiers, and only make
  sense where storage class specifiers may be used; for example,
! 'section'.)  There is one necessary limitation to this syntax: the first
  old-style parameter declaration in a function definition cannot begin
  with an attribute specifier, because such an attribute applies to the
  function instead by syntax described below (which, however, is not yet
  implemented in this case).  In some other cases, attribute specifiers
  are permitted by this grammar but not yet supported by the compiler.
  All attribute specifiers in this place relate to the declaration as a
! whole.  In the obsolescent usage where a type of 'int' is implied by the
  absence of type specifiers, such a list of specifiers and qualifiers may
  be an attribute specifier list with no other specifiers or qualifiers.
  
   At present, the first parameter in a function prototype must have some
  type specifier that is not an attribute specifier; this resolves an
! ambiguity in the interpretation of 'void f(int (__attribute__((foo))
! x))', but is subject to change.  At present, if the parentheses of a
  function declarator contain only attributes then those attributes are
  ignored, rather than yielding an error or warning or implying a single
  parameter of type int, but this is subject to change.
--- 41689,41709 ----
  context contain storage class specifiers.  (Some attributes, however,
  are essentially in the nature of storage class specifiers, and only make
  sense where storage class specifiers may be used; for example,
! ‘section’.)  There is one necessary limitation to this syntax: the first
  old-style parameter declaration in a function definition cannot begin
  with an attribute specifier, because such an attribute applies to the
  function instead by syntax described below (which, however, is not yet
  implemented in this case).  In some other cases, attribute specifiers
  are permitted by this grammar but not yet supported by the compiler.
  All attribute specifiers in this place relate to the declaration as a
! whole.  In the obsolescent usage where a type of ‘int’ is implied by the
  absence of type specifiers, such a list of specifiers and qualifiers may
  be an attribute specifier list with no other specifiers or qualifiers.
  
   At present, the first parameter in a function prototype must have some
  type specifier that is not an attribute specifier; this resolves an
! ambiguity in the interpretation of ‘void f(int (__attribute__((foo))
! x))’, but is subject to change.  At present, if the parentheses of a
  function declarator contain only attributes then those attributes are
  ignored, rather than yielding an error or warning or implying a single
  parameter of type int, but this is subject to change.
*************** identifier before whose declarator they
*** 41709,41722 ****
           __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
--- 41718,41731 ----
           __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 defin
*** 41724,41730 ****
  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
--- 41733,41739 ----
  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.
*** 41734,41759 ****
  declarator.  At present, there are some limitations in this usage: the
  attributes correctly apply to the declarator, but for most individual
  attributes the semantics this implies are not implemented.  When
! attribute specifiers follow the '*' of a pointer declarator, they may be
  mixed with any type qualifiers present.  The following describes the
  formal semantics of this syntax.  It makes the most sense if you are
  familiar with the formal specification of declarators in the ISO C
  standard.
  
!  Consider (as in C99 subclause 6.7.5 paragraph 4) a declaration 'T D1',
! where 'T' contains declaration specifiers that specify a type TYPE (such
! as 'int') and 'D1' is a declarator that contains an identifier IDENT.
  The type specified for IDENT for derived declarators whose type does not
  include an attribute specifier is as in the ISO C standard.
  
!  If 'D1' has the form '( ATTRIBUTE-SPECIFIER-LIST D )', and the
! declaration 'T D' specifies the type "DERIVED-DECLARATOR-TYPE-LIST TYPE"
! for IDENT, then 'T D1' specifies the type "DERIVED-DECLARATOR-TYPE-LIST
  ATTRIBUTE-SPECIFIER-LIST TYPE" for IDENT.
  
!  If 'D1' has the form '* TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-LIST D',
! and the declaration 'T D' specifies the type
! "DERIVED-DECLARATOR-TYPE-LIST TYPE" for IDENT, then 'T D1' specifies the
  type "DERIVED-DECLARATOR-TYPE-LIST
  TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-LIST pointer to TYPE" for IDENT.
  
--- 41743,41768 ----
  declarator.  At present, there are some limitations in this usage: the
  attributes correctly apply to the declarator, but for most individual
  attributes the semantics this implies are not implemented.  When
! attribute specifiers follow the ‘*’ of a pointer declarator, they may be
  mixed with any type qualifiers present.  The following describes the
  formal semantics of this syntax.  It makes the most sense if you are
  familiar with the formal specification of declarators in the ISO C
  standard.
  
!  Consider (as in C99 subclause 6.7.5 paragraph 4) a declaration ‘T D1’,
! where ‘T’ contains declaration specifiers that specify a type TYPE (such
! as ‘int’) and ‘D1’ is a declarator that contains an identifier IDENT.
  The type specified for IDENT for derived declarators whose type does not
  include an attribute specifier is as in the ISO C standard.
  
!  If ‘D1’ has the form ‘( ATTRIBUTE-SPECIFIER-LIST D )’, and the
! declaration ‘T D’ specifies the type "DERIVED-DECLARATOR-TYPE-LIST TYPE"
! for IDENT, then ‘T D1’ specifies the type "DERIVED-DECLARATOR-TYPE-LIST
  ATTRIBUTE-SPECIFIER-LIST TYPE" for IDENT.
  
!  If ‘D1’ has the form ‘* TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-LIST D’,
! and the declaration ‘T D’ specifies the type
! "DERIVED-DECLARATOR-TYPE-LIST TYPE" for IDENT, then ‘T D1’ specifies the
  type "DERIVED-DECLARATOR-TYPE-LIST
  TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-LIST pointer to TYPE" for IDENT.
  
*************** TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-L
*** 41762,41774 ****
       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
--- 41771,41783 ----
       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
*************** old-style non-prototype definition.  Con
*** 41815,41829 ****
         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
--- 41824,41838 ----
         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
*************** File: gcc.info,  Node: C++ Comments,  Ne
*** 41847,41858 ****
  6.41 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
--- 41856,41867 ----
  6.41 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
*************** File: gcc.info,  Node: Character Escapes
*** 41871,41877 ****
  6.43 The Character  in Constants
  =====================================
  
! You can use the sequence '\e' in a string or character constant to stand
  for the ASCII character .
  
  
--- 41880,41886 ----
  6.43 The Character  in Constants
  =====================================
  
! You can use the sequence ‘\e’ in a string or character constant to stand
  for the ASCII character .
  
  
*************** File: gcc.info,  Node: Alignment,  Next:
*** 41880,41913 ****
  6.44 Determining the Alignment of Functions, Types or Variables
  ===============================================================
  
! The keyword '__alignof__' determines the alignment requirement of a
  function, object, or a type, or the minimum alignment usually required
! by a type.  Its syntax is just like 'sizeof' and C11 '_Alignof'.
  
!  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 references
  to any data type even at an odd address.  For these machines,
! '__alignof__' reports the smallest alignment that GCC gives the data
  type, usually as mandated by the target ABI.
  
!  If the operand of '__alignof__' is an lvalue rather than a type, its
  value is the required alignment for its type, taking into account any
! minimum alignment specified by attribute 'aligned' (*note Common
  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 other than 'void'.
  
!  If the operand of the '__alignof__' expression is a function, the
  expression evaluates to the alignment of the function which may be
! specified by attribute 'aligned' (*note Common Function Attributes::).
  
  
  File: gcc.info,  Node: Inline,  Next: Volatiles,  Prev: Alignment,  Up: C Extensions
--- 41889,41922 ----
  6.44 Determining the Alignment of Functions, Types or Variables
  ===============================================================
  
! The keyword ‘__alignof__’ determines the alignment requirement of a
  function, object, or a type, or the minimum alignment usually required
! by a type.  Its syntax is just like ‘sizeof’ and C11 ‘_Alignof’.
  
!  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 references
  to any data type even at an odd address.  For these machines,
! ‘__alignof__’ reports the smallest alignment that GCC gives the data
  type, usually as mandated by the target ABI.
  
!  If the operand of ‘__alignof__’ is an lvalue rather than a type, its
  value is the required alignment for its type, taking into account any
! minimum alignment specified by attribute ‘aligned’ (*note Common
  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 other than ‘void’.
  
!  If the operand of the ‘__alignof__’ expression is a function, the
  expression evaluates to the alignment of the function which may be
! specified by attribute ‘aligned’ (*note Common Function Attributes::).
  
  
  File: gcc.info,  Node: Inline,  Next: Volatiles,  Prev: Alignment,  Up: C Extensions
*************** code needs to be included.  The effect o
*** 41925,41939 ****
  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=gnu99' or an option for a later C version is used
! (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
--- 41934,41948 ----
  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=gnu99’ or an option for a later C version is used
! (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
*************** declaration, like this:
*** 41943,41954 ****
       }
  
   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
--- 41952,41963 ----
       }
  
   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
*************** example above, and when a function is fi
*** 41958,42013 ****
       }
  
   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'.  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 cannot be inlined.
  
   Note that certain usages in a function definition can make it
  unsuitable for inline substitution.  Among these usages are: variadic
! functions, use of 'alloca', use of computed goto (*note Labels as
  Values::), use of nonlocal goto, use of nested functions, use of
! 'setjmp', use of '__builtin_longjmp' and use of '__builtin_return' or
! '__builtin_apply_args'.  Using '-Winline' warns when a function marked
! 'inline' could not be substituted, and gives the reason for the failure.
  
   As required by ISO C++, GCC considers member functions defined within
  the body of a class to be marked inline even if they are not explicitly
! declared with the 'inline' keyword.  You can override this with
! '-fno-default-inline'; *note Options Controlling C++ Dialect: C++
  Dialect Options.
  
   GCC does not inline any functions when not optimizing unless you
! specify the 'always_inline' attribute for the function, like this:
  
       /* Prototype.  */
       inline void foo (const char) __attribute__((always_inline));
  
   The remainder of this section is specific to GNU C90 inlining.
  
!  When an inline function is not 'static', then the compiler must assume
  that there may be calls from other source files; since a global symbol
  can be defined only once in any program, the function must not be
  defined in the other source files, so the calls therein cannot be
! integrated.  Therefore, a non-'static' inline function is always
  compiled on its own in the usual fashion.
  
!  If you specify both 'inline' and 'extern' in the function definition,
  then the definition is used only for inlining.  In no case is the
  function compiled on its own, not even if you refer to its address
  explicitly.  Such an address becomes an external reference, as if you
  had only declared the function, and had not defined it.
  
!  This combination of 'inline' and 'extern' has almost the effect of a
  macro.  The way to use it is to put a function definition in a header
  file with these keywords, and put another copy of the definition
! (lacking 'inline' and 'extern') in a library file.  The definition in
  the header file causes most calls to the function to be inlined.  If any
  uses of the function remain, they refer to the single copy in the
  library.
--- 41967,42022 ----
       }
  
   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’.  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 cannot be inlined.
  
   Note that certain usages in a function definition can make it
  unsuitable for inline substitution.  Among these usages are: variadic
! functions, use of ‘alloca’, use of computed goto (*note Labels as
  Values::), use of nonlocal goto, use of nested functions, use of
! ‘setjmp’, use of ‘__builtin_longjmp’ and use of ‘__builtin_return’ or
! ‘__builtin_apply_args’.  Using ‘-Winline’ warns when a function marked
! ‘inline’ could not be substituted, and gives the reason for the failure.
  
   As required by ISO C++, GCC considers member functions defined within
  the body of a class to be marked inline even if they are not explicitly
! declared with the ‘inline’ keyword.  You can override this with
! ‘-fno-default-inline’; *note Options Controlling C++ Dialect: C++
  Dialect Options.
  
   GCC does not inline any functions when not optimizing unless you
! specify the ‘always_inline’ attribute for the function, like this:
  
       /* Prototype.  */
       inline void foo (const char) __attribute__((always_inline));
  
   The remainder of this section is specific to GNU C90 inlining.
  
!  When an inline function is not ‘static’, then the compiler must assume
  that there may be calls from other source files; since a global symbol
  can be defined only once in any program, the function must not be
  defined in the other source files, so the calls therein cannot be
! integrated.  Therefore, a non-‘static’ inline function is always
  compiled on its own in the usual fashion.
  
!  If you specify both ‘inline’ and ‘extern’ in the function definition,
  then the definition is used only for inlining.  In no case is the
  function compiled on its own, not even if you refer to its address
  explicitly.  Such an address becomes an external reference, as if you
  had only declared the function, and had not defined it.
  
!  This combination of ‘inline’ and ‘extern’ has almost the effect of a
  macro.  The way to use it is to put a function definition in a header
  file with these keywords, and put another copy of the definition
! (lacking ‘inline’ and ‘extern’) in a library file.  The definition in
  the header file causes most calls to the function to be inlined.  If any
  uses of the function remain, they refer to the single copy in the
  library.
*************** File: gcc.info,  Node: Using Assembly La
*** 42089,42114 ****
  6.47 How to Use Inline Assembly Language in C Code
  ==================================================
  
! The 'asm' keyword allows you to embed assembler instructions within C
! code.  GCC provides two forms of inline 'asm' statements.  A "basic
! 'asm'" statement is one with no operands (*note Basic Asm::), while an
! "extended 'asm'" statement (*note Extended Asm::) includes one or more
  operands.  The extended form is preferred for mixing C and assembly
  language within a function, but to include assembly language at top
! level you must use basic 'asm'.
  
!  You can also use the 'asm' keyword to override the assembler name for a
  C symbol, or to place a C variable in a specific register.
  
  * Menu:
  
  * Basic Asm::          Inline assembler without operands.
  * Extended Asm::       Inline assembler with operands.
! * Constraints::        Constraints for 'asm' operands
  * Asm Labels::         Specifying the assembler name to use for a C symbol.
  * Explicit Register Variables::  Defining variables residing in specified
                         registers.
! * Size of an asm::     How GCC calculates the size of an 'asm' block.
  
  
  File: gcc.info,  Node: Basic Asm,  Next: Extended Asm,  Up: Using Assembly Language with C
--- 42098,42123 ----
  6.47 How to Use Inline Assembly Language in C Code
  ==================================================
  
! The ‘asm’ keyword allows you to embed assembler instructions within C
! code.  GCC provides two forms of inline ‘asm’ statements.  A “basic
! ‘asm’” statement is one with no operands (*note Basic Asm::), while an
! “extended ‘asm’” statement (*note Extended Asm::) includes one or more
  operands.  The extended form is preferred for mixing C and assembly
  language within a function, but to include assembly language at top
! level you must use basic ‘asm’.
  
!  You can also use the ‘asm’ keyword to override the assembler name for a
  C symbol, or to place a C variable in a specific register.
  
  * Menu:
  
  * Basic Asm::          Inline assembler without operands.
  * Extended Asm::       Inline assembler with operands.
! * Constraints::        Constraints for ‘asm’ operands
  * Asm Labels::         Specifying the assembler name to use for a C symbol.
  * Explicit Register Variables::  Defining variables residing in specified
                         registers.
! * Size of an asm::     How GCC calculates the size of an ‘asm’ block.
  
  
  File: gcc.info,  Node: Basic Asm,  Next: Extended Asm,  Up: Using Assembly Language with C
*************** File: gcc.info,  Node: Basic Asm,  Next:
*** 42116,42141 ****
  6.47.1 Basic Asm -- Assembler Instructions Without Operands
  -----------------------------------------------------------
  
! A basic 'asm' statement has the following syntax:
  
       asm ASM-QUALIFIERS ( ASSEMBLERINSTRUCTIONS )
  
!  For the C language, the 'asm' keyword is a GNU extension.  When writing
! C code that can be compiled with '-ansi' and the '-std' options that
! select C dialects without GNU extensions, use '__asm__' instead of 'asm'
! (*note Alternate Keywords::).  For the C++ language, 'asm' is a standard
! keyword, but '__asm__' can be used for code compiled with '-fno-asm'.
  
  Qualifiers
  ..........
  
! 'volatile'
!      The optional 'volatile' qualifier has no effect.  All basic 'asm'
       blocks are implicitly volatile.
  
! 'inline'
!      If you use the 'inline' qualifier, then for inlining purposes the
!      size of the 'asm' statement is taken as the smallest size possible
       (*note Size of an asm::).
  
  Parameters
--- 42125,42150 ----
  6.47.1 Basic Asm -- Assembler Instructions Without Operands
  -----------------------------------------------------------
  
! A basic ‘asm’ statement has the following syntax:
  
       asm ASM-QUALIFIERS ( ASSEMBLERINSTRUCTIONS )
  
!  For the C language, the ‘asm’ keyword is a GNU extension.  When writing
! C code that can be compiled with ‘-ansi’ and the ‘-std’ options that
! select C dialects without GNU extensions, use ‘__asm__’ instead of ‘asm’
! (*note Alternate Keywords::).  For the C++ language, ‘asm’ is a standard
! keyword, but ‘__asm__’ can be used for code compiled with ‘-fno-asm’.
  
  Qualifiers
  ..........
  
! ‘volatile’
!      The optional ‘volatile’ qualifier has no effect.  All basic ‘asm’
       blocks are implicitly volatile.
  
! ‘inline’
!      If you use the ‘inline’ qualifier, then for inlining purposes the
!      size of the ‘asm’ statement is taken as the smallest size possible
       (*note Size of an asm::).
  
  Parameters
*************** ASSEMBLERINSTRUCTIONS
*** 42149,42235 ****
       whether they are valid assembler input.
  
       You may place multiple assembler instructions together in a single
!      'asm' string, 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 (written as
!      '\n\t').  Some assemblers allow semicolons as a line separator.
       However, note that some assembler dialects use semicolons to start
       a comment.
  
  Remarks
  .......
  
! Using extended 'asm' (*note Extended Asm::) typically produces smaller,
  safer, and more efficient code, and in most cases it is a better
! solution than basic 'asm'.  However, there are two situations where only
! basic 'asm' can be used:
  
!    * Extended 'asm' statements have to be inside a C function, so to
       write inline assembly language at file scope ("top-level"), outside
!      of C functions, you must use basic 'asm'.  You can use this
       technique to emit assembler directives, define assembly language
       macros that can be invoked elsewhere in the file, or write entire
!      functions in assembly language.  Basic 'asm' statements outside of
       functions may not use any qualifiers.
  
!    * Functions declared with the 'naked' attribute also require basic
!      'asm' (*note Function Attributes::).
  
!  Safely accessing C data and calling functions from basic 'asm' is more
  complex than it may appear.  To access C data, it is better to use
! extended 'asm'.
  
!  Do not expect a sequence of 'asm' statements to remain perfectly
  consecutive after compilation.  If certain instructions need to remain
! consecutive in the output, put them in a single multi-instruction 'asm'
! statement.  Note that GCC's optimizers can move 'asm' statements
  relative to other code, including across jumps.
  
!  'asm' statements may not perform jumps into other 'asm' statements.
  GCC does not know about these jumps, and therefore cannot take account
! of them when deciding how to optimize.  Jumps from 'asm' to C labels are
! only supported in extended 'asm'.
  
   Under certain circumstances, GCC may duplicate (or remove duplicates
  of) your assembly code when optimizing.  This can lead to unexpected
  duplicate symbol errors during compilation if your assembly code defines
  symbols or labels.
  
!  *Warning:* The C standards do not specify semantics for 'asm', making
  it a potential source of incompatibilities between compilers.  These
  incompatibilities may not produce compiler warnings/errors.
  
!  GCC does not parse basic 'asm''s ASSEMBLERINSTRUCTIONS, which means
  there is no way to communicate to the compiler what is happening inside
! them.  GCC has no visibility of symbols in the 'asm' and may discard
  them as unreferenced.  It also does not know about side effects of the
  assembler code, such as modifications to memory or registers.  Unlike
  some compilers, GCC assumes that no changes to general purpose registers
  occur.  This assumption may change in a future release.
  
   To avoid complications from future changes to the semantics and the
! compatibility issues between compilers, consider replacing basic 'asm'
! with extended 'asm'.  See How to convert from basic asm to extended asm
  (https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended) for information
  about how to perform this conversion.
  
!  The compiler copies the assembler instructions in a basic 'asm'
  verbatim to the assembly language output file, without processing
! dialects or any of the '%' operators that are available with extended
! 'asm'.  This results in minor differences between basic 'asm' strings
! and extended 'asm' templates.  For example, to refer to registers you
! might use '%eax' in basic 'asm' and '%%eax' in extended 'asm'.
  
   On targets such as x86 that support multiple assembler dialects, all
! basic 'asm' blocks use the assembler dialect specified by the '-masm'
! command-line option (*note x86 Options::).  Basic 'asm' provides no
  mechanism to provide different assembler strings for different dialects.
  
!  For basic 'asm' with non-empty assembler string GCC assumes the
  assembler block does not change any general purpose registers, but it
  may read or write any globally accessible variable.
  
!  Here is an example of basic 'asm' for i386:
  
       /* Note that this code will not compile with -masm=intel */
       #define DebugBreak() asm("int $3")
--- 42158,42244 ----
       whether they are valid assembler input.
  
       You may place multiple assembler instructions together in a single
!      ‘asm’ string, 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 (written as
!      ‘\n\t’).  Some assemblers allow semicolons as a line separator.
       However, note that some assembler dialects use semicolons to start
       a comment.
  
  Remarks
  .......
  
! Using extended ‘asm’ (*note Extended Asm::) typically produces smaller,
  safer, and more efficient code, and in most cases it is a better
! solution than basic ‘asm’.  However, there are two situations where only
! basic ‘asm’ can be used:
  
!    • Extended ‘asm’ statements have to be inside a C function, so to
       write inline assembly language at file scope ("top-level"), outside
!      of C functions, you must use basic ‘asm’.  You can use this
       technique to emit assembler directives, define assembly language
       macros that can be invoked elsewhere in the file, or write entire
!      functions in assembly language.  Basic ‘asm’ statements outside of
       functions may not use any qualifiers.
  
!    • Functions declared with the ‘naked’ attribute also require basic
!      ‘asm’ (*note Function Attributes::).
  
!  Safely accessing C data and calling functions from basic ‘asm’ is more
  complex than it may appear.  To access C data, it is better to use
! extended ‘asm’.
  
!  Do not expect a sequence of ‘asm’ statements to remain perfectly
  consecutive after compilation.  If certain instructions need to remain
! consecutive in the output, put them in a single multi-instruction ‘asm’
! statement.  Note that GCC's optimizers can move ‘asm’ statements
  relative to other code, including across jumps.
  
!  ‘asm’ statements may not perform jumps into other ‘asm’ statements.
  GCC does not know about these jumps, and therefore cannot take account
! of them when deciding how to optimize.  Jumps from ‘asm’ to C labels are
! only supported in extended ‘asm’.
  
   Under certain circumstances, GCC may duplicate (or remove duplicates
  of) your assembly code when optimizing.  This can lead to unexpected
  duplicate symbol errors during compilation if your assembly code defines
  symbols or labels.
  
!  *Warning:* The C standards do not specify semantics for ‘asm’, making
  it a potential source of incompatibilities between compilers.  These
  incompatibilities may not produce compiler warnings/errors.
  
!  GCC does not parse basic ‘asm’'s ASSEMBLERINSTRUCTIONS, which means
  there is no way to communicate to the compiler what is happening inside
! them.  GCC has no visibility of symbols in the ‘asm’ and may discard
  them as unreferenced.  It also does not know about side effects of the
  assembler code, such as modifications to memory or registers.  Unlike
  some compilers, GCC assumes that no changes to general purpose registers
  occur.  This assumption may change in a future release.
  
   To avoid complications from future changes to the semantics and the
! compatibility issues between compilers, consider replacing basic ‘asm’
! with extended ‘asm’.  See How to convert from basic asm to extended asm
  (https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended) for information
  about how to perform this conversion.
  
!  The compiler copies the assembler instructions in a basic ‘asm’
  verbatim to the assembly language output file, without processing
! dialects or any of the ‘%’ operators that are available with extended
! ‘asm’.  This results in minor differences between basic ‘asm’ strings
! and extended ‘asm’ templates.  For example, to refer to registers you
! might use ‘%eax’ in basic ‘asm’ and ‘%%eax’ in extended ‘asm’.
  
   On targets such as x86 that support multiple assembler dialects, all
! basic ‘asm’ blocks use the assembler dialect specified by the ‘-masm’
! command-line option (*note x86 Options::).  Basic ‘asm’ provides no
  mechanism to provide different assembler strings for different dialects.
  
!  For basic ‘asm’ with non-empty assembler string GCC assumes the
  assembler block does not change any general purpose registers, but it
  may read or write any globally accessible variable.
  
!  Here is an example of basic ‘asm’ for i386:
  
       /* Note that this code will not compile with -masm=intel */
       #define DebugBreak() asm("int $3")
*************** File: gcc.info,  Node: Extended Asm,  Ne
*** 42240,42248 ****
  6.47.2 Extended Asm - Assembler Instructions with C Expression Operands
  -----------------------------------------------------------------------
  
! With extended 'asm' you can read and write C variables from assembler
! and perform jumps from assembler code to C labels.  Extended 'asm'
! syntax uses colons (':') to delimit the operand parameters after the
  assembler template:
  
       asm ASM-QUALIFIERS ( ASSEMBLERTEMPLATE
--- 42249,42257 ----
  6.47.2 Extended Asm - Assembler Instructions with C Expression Operands
  -----------------------------------------------------------------------
  
! With extended ‘asm’ you can read and write C variables from assembler
! and perform jumps from assembler code to C labels.  Extended ‘asm’
! syntax uses colons (‘:’) to delimit the operand parameters after the
  assembler template:
  
       asm ASM-QUALIFIERS ( ASSEMBLERTEMPLATE
*************** assembler template:
*** 42255,42284 ****
                             : INPUTOPERANDS
                             : CLOBBERS
                             : GOTOLABELS)
!  where in the last form, ASM-QUALIFIERS contains 'goto' (and in the
  first form, not).
  
!  The 'asm' keyword is a GNU extension.  When writing code that can be
! compiled with '-ansi' and the various '-std' options, use '__asm__'
! instead of 'asm' (*note Alternate Keywords::).
  
  Qualifiers
  ..........
  
! 'volatile'
!      The typical use of extended 'asm' statements is to manipulate input
!      values to produce output values.  However, your 'asm' statements
       may also produce side effects.  If so, you may need to use the
!      'volatile' qualifier to disable certain optimizations.  *Note
       Volatile::.
  
! 'inline'
!      If you use the 'inline' qualifier, then for inlining purposes the
!      size of the 'asm' statement is taken as the smallest size possible
       (*note Size of an asm::).
  
! 'goto'
!      This qualifier informs the compiler that the 'asm' statement may
       perform a jump to one of the labels listed in the GOTOLABELS.
       *Note GotoLabels::.
  
--- 42264,42293 ----
                             : INPUTOPERANDS
                             : CLOBBERS
                             : GOTOLABELS)
!  where in the last form, ASM-QUALIFIERS contains ‘goto’ (and in the
  first form, not).
  
!  The ‘asm’ keyword is a GNU extension.  When writing code that can be
! compiled with ‘-ansi’ and the various ‘-std’ options, use ‘__asm__’
! instead of ‘asm’ (*note Alternate Keywords::).
  
  Qualifiers
  ..........
  
! ‘volatile’
!      The typical use of extended ‘asm’ statements is to manipulate input
!      values to produce output values.  However, your ‘asm’ statements
       may also produce side effects.  If so, you may need to use the
!      ‘volatile’ qualifier to disable certain optimizations.  *Note
       Volatile::.
  
! ‘inline’
!      If you use the ‘inline’ qualifier, then for inlining purposes the
!      size of the ‘asm’ statement is taken as the smallest size possible
       (*note Size of an asm::).
  
! ‘goto’
!      This qualifier informs the compiler that the ‘asm’ statement may
       perform a jump to one of the labels listed in the GOTOLABELS.
       *Note GotoLabels::.
  
*************** CLOBBERS
*** 42306,42316 ****
       is permitted.  *Note Clobbers and Scratch Registers::.
  
  GOTOLABELS
!      When you are using the 'goto' form of 'asm', this section contains
       the list of all C labels to which the code in the ASSEMBLERTEMPLATE
       may jump.  *Note GotoLabels::.
  
!      'asm' statements may not perform jumps into other 'asm' statements,
       only to the listed GOTOLABELS.  GCC's optimizers do not know about
       other jumps; therefore they cannot take account of them when
       deciding how to optimize.
--- 42315,42325 ----
       is permitted.  *Note Clobbers and Scratch Registers::.
  
  GOTOLABELS
!      When you are using the ‘goto’ form of ‘asm’, this section contains
       the list of all C labels to which the code in the ASSEMBLERTEMPLATE
       may jump.  *Note GotoLabels::.
  
!      ‘asm’ statements may not perform jumps into other ‘asm’ statements,
       only to the listed GOTOLABELS.  GCC's optimizers do not know about
       other jumps; therefore they cannot take account of them when
       deciding how to optimize.
*************** GOTOLABELS
*** 42320,42339 ****
  Remarks
  .......
  
! The 'asm' statement allows you to include assembly instructions directly
  within C code.  This may help you to maximize performance in
  time-sensitive code or to access assembly instructions that are not
  readily available to C programs.
  
!  Note that extended 'asm' statements must be inside a function.  Only
! basic 'asm' may be outside functions (*note Basic Asm::).  Functions
! declared with the 'naked' attribute also require basic 'asm' (*note
  Function Attributes::).
  
!  While the uses of 'asm' are many and varied, it may help to think of an
! 'asm' statement as a series of low-level instructions that convert input
  parameters to output parameters.  So a simple (if not particularly
! useful) example for i386 using 'asm' might look like this:
  
       int src = 1;
       int dst;
--- 42329,42348 ----
  Remarks
  .......
  
! The ‘asm’ statement allows you to include assembly instructions directly
  within C code.  This may help you to maximize performance in
  time-sensitive code or to access assembly instructions that are not
  readily available to C programs.
  
!  Note that extended ‘asm’ statements must be inside a function.  Only
! basic ‘asm’ may be outside functions (*note Basic Asm::).  Functions
! declared with the ‘naked’ attribute also require basic ‘asm’ (*note
  Function Attributes::).
  
!  While the uses of ‘asm’ are many and varied, it may help to think of an
! ‘asm’ statement as a series of low-level instructions that convert input
  parameters to output parameters.  So a simple (if not particularly
! useful) example for i386 using ‘asm’ might look like this:
  
       int src = 1;
       int dst;
*************** useful) example for i386 using 'asm' mig
*** 42345,42369 ****
  
       printf("%d\n", dst);
  
!  This code copies 'src' to 'dst' and add 1 to 'dst'.
  
  6.47.2.1 Volatile
  .................
  
! GCC's optimizers sometimes discard 'asm' statements if they determine
  there is no need for the output variables.  Also, the optimizers may
  move code out of loops if they believe that the code will always return
  the same result (i.e. none of its input values change between calls).
! Using the 'volatile' qualifier disables these optimizations.  'asm'
! statements that have no output operands and 'asm goto' statements, are
  implicitly volatile.
  
   This i386 code demonstrates a case that does not use (or require) the
! 'volatile' qualifier.  If it is performing assertion checking, this code
! uses 'asm' to perform the validation.  Otherwise, 'dwRes' is
  unreferenced by any code.  As a result, the optimizers can discard the
! 'asm' statement, which in turn removes the need for the entire 'DoCheck'
! routine.  By omitting the 'volatile' qualifier when it isn't needed you
  allow the optimizers to produce the most efficient code possible.
  
       void DoCheck(uint32_t dwSomeValue)
--- 42354,42378 ----
  
       printf("%d\n", dst);
  
!  This code copies ‘src’ to ‘dst’ and add 1 to ‘dst’.
  
  6.47.2.1 Volatile
  .................
  
! GCC's optimizers sometimes discard ‘asm’ statements if they determine
  there is no need for the output variables.  Also, the optimizers may
  move code out of loops if they believe that the code will always return
  the same result (i.e. none of its input values change between calls).
! Using the ‘volatile’ qualifier disables these optimizations.  ‘asm’
! statements that have no output operands and ‘asm goto’ statements, are
  implicitly volatile.
  
   This i386 code demonstrates a case that does not use (or require) the
! ‘volatile’ qualifier.  If it is performing assertion checking, this code
! uses ‘asm’ to perform the validation.  Otherwise, ‘dwRes’ is
  unreferenced by any code.  As a result, the optimizers can discard the
! ‘asm’ statement, which in turn removes the need for the entire ‘DoCheck’
! routine.  By omitting the ‘volatile’ qualifier when it isn't needed you
  allow the optimizers to produce the most efficient code possible.
  
       void DoCheck(uint32_t dwSomeValue)
*************** allow the optimizers to produce the most
*** 42380,42388 ****
       }
  
   The next example shows a case where the optimizers can recognize that
! the input ('dwSomeValue') never changes during the execution of the
! function and can therefore move the 'asm' outside the loop to produce
! more efficient code.  Again, using the 'volatile' qualifier disables
  this type of optimization.
  
       void do_print(uint32_t dwSomeValue)
--- 42389,42397 ----
       }
  
   The next example shows a case where the optimizers can recognize that
! the input (‘dwSomeValue’) never changes during the execution of the
! function and can therefore move the ‘asm’ outside the loop to produce
! more efficient code.  Again, using the ‘volatile’ qualifier disables
  this type of optimization.
  
       void do_print(uint32_t dwSomeValue)
*************** this type of optimization.
*** 42402,42410 ****
       }
  
   The following example demonstrates a case where you need to use the
! 'volatile' qualifier.  It uses the x86 'rdtsc' instruction, which reads
! the computer's time-stamp counter.  Without the 'volatile' qualifier,
! the optimizers might assume that the 'asm' block will always return the
  same value and therefore optimize away the second call.
  
       uint64_t msr;
--- 42411,42419 ----
       }
  
   The following example demonstrates a case where you need to use the
! ‘volatile’ qualifier.  It uses the x86 ‘rdtsc’ instruction, which reads
! the computer's time-stamp counter.  Without the ‘volatile’ qualifier,
! the optimizers might assume that the ‘asm’ block will always return the
  same value and therefore optimize away the second call.
  
       uint64_t msr;
*************** same value and therefore optimize away t
*** 42434,42460 ****
  the earlier examples.  They do not move it out of loops or omit it on
  the assumption that the result from a previous call is still valid.
  
!  Note that the compiler can move even 'volatile asm' instructions
  relative to other code, including across jump instructions.  For
  example, on many targets there is a system register that controls the
! rounding mode of floating-point operations.  Setting it with a 'volatile
! asm' statement, as in the following PowerPC example, does not work
  reliably.
  
       asm volatile("mtfsf 255, %0" : : "f" (fpenv));
       sum = x + y;
  
!  The compiler may move the addition back before the 'volatile asm'
  statement.  To make it work as expected, add an artificial dependency to
! the 'asm' by referencing a variable in the subsequent code, for example:
  
       asm volatile ("mtfsf 255,%1" : "=X" (sum) : "f" (fpenv));
       sum = x + y;
  
   Under certain circumstances, GCC may duplicate (or remove duplicates
  of) your assembly code when optimizing.  This can lead to unexpected
! duplicate symbol errors during compilation if your 'asm' code defines
! symbols or labels.  Using '%=' (*note AssemblerTemplate::) may help
  resolve this problem.
  
  6.47.2.2 Assembler Template
--- 42443,42469 ----
  the earlier examples.  They do not move it out of loops or omit it on
  the assumption that the result from a previous call is still valid.
  
!  Note that the compiler can move even ‘volatile asm’ instructions
  relative to other code, including across jump instructions.  For
  example, on many targets there is a system register that controls the
! rounding mode of floating-point operations.  Setting it with a ‘volatile
! asm’ statement, as in the following PowerPC example, does not work
  reliably.
  
       asm volatile("mtfsf 255, %0" : : "f" (fpenv));
       sum = x + y;
  
!  The compiler may move the addition back before the ‘volatile asm’
  statement.  To make it work as expected, add an artificial dependency to
! the ‘asm’ by referencing a variable in the subsequent code, for example:
  
       asm volatile ("mtfsf 255,%1" : "=X" (sum) : "f" (fpenv));
       sum = x + y;
  
   Under certain circumstances, GCC may duplicate (or remove duplicates
  of) your assembly code when optimizing.  This can lead to unexpected
! duplicate symbol errors during compilation if your ‘asm’ code defines
! symbols or labels.  Using ‘%=’ (*note AssemblerTemplate::) may help
  resolve this problem.
  
  6.47.2.2 Assembler Template
*************** or even whether they are valid assembler
*** 42470,42486 ****
  the statements (*note Size of an asm::).
  
   You may place multiple assembler instructions together in a single
! 'asm' string, 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').  Some assemblers allow semicolons as a line
  separator.  However, note that some assembler dialects use semicolons to
  start a comment.
  
!  Do not expect a sequence of 'asm' statements to remain perfectly
! consecutive after compilation, even when you are using the 'volatile'
  qualifier.  If certain instructions need to remain consecutive in the
! output, put them in a single multi-instruction 'asm' statement.
  
   Accessing data from C programs without using input/output operands
  (such as by using global symbols directly from the assembler template)
--- 42479,42495 ----
  the statements (*note Size of an asm::).
  
   You may place multiple assembler instructions together in a single
! ‘asm’ string, 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’).  Some assemblers allow semicolons as a line
  separator.  However, note that some assembler dialects use semicolons to
  start a comment.
  
!  Do not expect a sequence of ‘asm’ statements to remain perfectly
! consecutive after compilation, even when you are using the ‘volatile’
  qualifier.  If certain instructions need to remain consecutive in the
! output, put them in a single multi-instruction ‘asm’ statement.
  
   Accessing data from C programs without using input/output operands
  (such as by using global symbols directly from the assembler template)
*************** Special format strings
*** 42499,42527 ****
  In addition to the tokens described by the input, output, and goto
  operands, these tokens have special meanings in the assembler template:
  
! '%%'
!      Outputs a single '%' into the assembler code.
  
! '%='
!      Outputs a number that is unique to each instance of the 'asm'
       statement in the entire compilation.  This option is useful when
       creating local labels and referring to them multiple times in a
       single template that generates multiple assembler instructions.
  
! '%{'
! '%|'
! '%}'
!      Outputs '{', '|', and '}' characters (respectively) into the
       assembler code.  When unescaped, these characters have special
       meaning to indicate multiple assembler dialects, as described
       below.
  
! Multiple assembler dialects in 'asm' templates
  ..............................................
  
  On targets such as x86, GCC supports multiple assembler dialects.  The
! '-masm' option controls which dialect GCC uses as its default for inline
! assembler.  The target-specific documentation for the '-masm' option
  contains the list of supported dialects, as well as the default dialect
  if the option is not specified.  This information may be important to
  understand, since assembler code that works correctly when compiled
--- 42508,42536 ----
  In addition to the tokens described by the input, output, and goto
  operands, these tokens have special meanings in the assembler template:
  
! ‘%%’
!      Outputs a single ‘%’ into the assembler code.
  
! ‘%=’
!      Outputs a number that is unique to each instance of the ‘asm’
       statement in the entire compilation.  This option is useful when
       creating local labels and referring to them multiple times in a
       single template that generates multiple assembler instructions.
  
! ‘%{’
! ‘%|’
! ‘%}’
!      Outputs ‘{’, ‘|’, and ‘}’ characters (respectively) into the
       assembler code.  When unescaped, these characters have special
       meaning to indicate multiple assembler dialects, as described
       below.
  
! Multiple assembler dialects in ‘asm’ templates
  ..............................................
  
  On targets such as x86, GCC supports multiple assembler dialects.  The
! ‘-masm’ option controls which dialect GCC uses as its default for inline
! assembler.  The target-specific documentation for the ‘-masm’ option
  contains the list of supported dialects, as well as the default dialect
  if the option is not specified.  This information may be important to
  understand, since assembler code that works correctly when compiled
*************** compilation options), use constructs of
*** 42534,42545 ****
  
       { dialect0 | dialect1 | dialect2... }
  
!  This construct outputs 'dialect0' when using dialect #0 to compile the
! code, 'dialect1' for dialect #1, etc.  If there are fewer alternatives
  within the braces than the number of dialects the compiler supports, the
  construct outputs nothing.
  
!  For example, if an x86 compiler supports two dialects ('att', 'intel'),
  an assembler template such as this:
  
       "bt{l %[Offset],%[Base] | %[Base],%[Offset]}; jc %l2"
--- 42543,42554 ----
  
       { dialect0 | dialect1 | dialect2... }
  
!  This construct outputs ‘dialect0’ when using dialect #0 to compile the
! code, ‘dialect1’ for dialect #1, etc.  If there are fewer alternatives
  within the braces than the number of dialects the compiler supports, the
  construct outputs nothing.
  
!  For example, if an x86 compiler supports two dialects (‘att’, ‘intel’),
  an assembler template such as this:
  
       "bt{l %[Offset],%[Base] | %[Base],%[Offset]}; jc %l2"
*************** corresponds to either
*** 42563,42573 ****
  6.47.2.3 Output Operands
  ........................
  
! An 'asm' statement has zero or more output operands indicating the names
  of C variables modified by the assembler code.
  
!  In this i386 example, 'old' (referred to in the template string as
! '%0') and '*Base' (as '%1') are outputs and 'Offset' ('%2') is an input:
  
       bool old;
  
--- 42572,42582 ----
  6.47.2.3 Output Operands
  ........................
  
! An ‘asm’ statement has zero or more output operands indicating the names
  of C variables modified by the assembler code.
  
!  In this i386 example, ‘old’ (referred to in the template string as
! ‘%0’) and ‘*Base’ (as ‘%1’) are outputs and ‘Offset’ (‘%2’) is an input:
  
       bool old;
  
*************** of C variables modified by the assembler
*** 42586,42619 ****
  ASMSYMBOLICNAME
       Specifies a symbolic name for the operand.  Reference the name in
       the assembler template by enclosing it in square brackets (i.e.
!      '%[Value]').  The scope of the name is the 'asm' statement that
       contains the definition.  Any valid C variable name is acceptable,
       including names already defined in the surrounding code.  No two
!      operands within the same 'asm' statement can use the same symbolic
       name.
  
       When not using an ASMSYMBOLICNAME, use the (zero-based) position of
       the operand in the list of operands in the assembler template.  For
!      example if there are three output operands, use '%0' in the
!      template to refer to the first, '%1' for the second, and '%2' for
       the third.
  
  CONSTRAINT
       A string constant specifying constraints on the placement of the
       operand; *Note Constraints::, for details.
  
!      Output constraints must begin with either '=' (a variable
!      overwriting an existing value) or '+' (when reading and writing).
!      When using '=', do not assume the location contains the existing
!      value on entry to the 'asm', except when the operand is tied to an
       input; *note Input Operands: InputOperands.
  
       After the prefix, there must be one or more additional constraints
       (*note Constraints::) that describe where the value resides.
!      Common constraints include 'r' for register and 'm' for memory.
       When you list more than one possible location (for example,
!      '"=rm"'), the compiler chooses the most efficient one based on the
!      current context.  If you list as many alternates as the 'asm'
       statement allows, you permit the optimizers to produce the best
       possible code.  If you must use a specific register, but your
       Machine Constraints do not provide sufficient control to select the
--- 42595,42628 ----
  ASMSYMBOLICNAME
       Specifies a symbolic name for the operand.  Reference the name in
       the assembler template by enclosing it in square brackets (i.e.
!      ‘%[Value]’).  The scope of the name is the ‘asm’ statement that
       contains the definition.  Any valid C variable name is acceptable,
       including names already defined in the surrounding code.  No two
!      operands within the same ‘asm’ statement can use the same symbolic
       name.
  
       When not using an ASMSYMBOLICNAME, use the (zero-based) position of
       the operand in the list of operands in the assembler template.  For
!      example if there are three output operands, use ‘%0’ in the
!      template to refer to the first, ‘%1’ for the second, and ‘%2’ for
       the third.
  
  CONSTRAINT
       A string constant specifying constraints on the placement of the
       operand; *Note Constraints::, for details.
  
!      Output constraints must begin with either ‘=’ (a variable
!      overwriting an existing value) or ‘+’ (when reading and writing).
!      When using ‘=’, do not assume the location contains the existing
!      value on entry to the ‘asm’, except when the operand is tied to an
       input; *note Input Operands: InputOperands.
  
       After the prefix, there must be one or more additional constraints
       (*note Constraints::) that describe where the value resides.
!      Common constraints include ‘r’ for register and ‘m’ for memory.
       When you list more than one possible location (for example,
!      ‘"=rm"’), the compiler chooses the most efficient one based on the
!      current context.  If you list as many alternates as the ‘asm’
       statement allows, you permit the optimizers to produce the best
       possible code.  If you must use a specific register, but your
       Machine Constraints do not provide sufficient control to select the
*************** whether the operands have data types tha
*** 42634,42646 ****
  instruction being executed.  For output expressions that are not
  directly addressable (for example a bit-field), the constraint must
  allow a register.  In that case, GCC uses the register as the output of
! the 'asm', and then stores that register into the output.
  
!  Operands using the '+' constraint modifier count as two operands (that
  is, both as input and output) towards the total maximum of 30 operands
! per 'asm' statement.
  
!  Use the '&' constraint modifier (*note Modifiers::) on all output
  operands that must not overlap an input.  Otherwise, GCC may allocate
  the output operand in the same register as an unrelated input operand,
  on the assumption that the assembler code consumes its inputs before
--- 42643,42655 ----
  instruction being executed.  For output expressions that are not
  directly addressable (for example a bit-field), the constraint must
  allow a register.  In that case, GCC uses the register as the output of
! the ‘asm’, and then stores that register into the output.
  
!  Operands using the ‘+’ constraint modifier count as two operands (that
  is, both as input and output) towards the total maximum of 30 operands
! per ‘asm’ statement.
  
!  Use the ‘&’ constraint modifier (*note Modifiers::) on all output
  operands that must not overlap an input.  Otherwise, GCC may allocate
  the output operand in the same register as an unrelated input operand,
  on the assumption that the assembler code consumes its inputs before
*************** constraint.  The code generated by GCC t
*** 42653,42681 ****
  can contain registers which _might_ be shared by A, and GCC considers
  those registers to be inputs to the asm.  As above, GCC assumes that
  such input registers are consumed before any outputs are written.  This
! assumption may result in incorrect behavior if the 'asm' statement
! writes to A before using B.  Combining the '&' modifier with the
  register constraint on A ensures that modifying A does not affect the
  address referenced by B.  Otherwise, the location of B is undefined if A
  is modified before using B.
  
!  'asm' supports operand modifiers on operands (for example '%k2' instead
! of simply '%2').  *note Generic Operand modifiers:
  GenericOperandmodifiers. lists the modifiers that are available on all
  targets.  Other modifiers are hardware dependent.  For example, the list
  of supported modifiers for x86 is found at *note x86 Operand modifiers:
  x86Operandmodifiers.
  
!  If the C code that follows the 'asm' makes no use of any of the output
! operands, use 'volatile' for the 'asm' statement to prevent the
! optimizers from discarding the 'asm' statement as unneeded (see *note
  Volatile::).
  
   This code makes no use of the optional ASMSYMBOLICNAME.  Therefore it
! references the first output operand as '%0' (were there a second, it
! would be '%1', etc).  The number of the first input operand is one
  greater than that of the last output operand.  In this i386 example,
! that makes 'Mask' referenced as '%1':
  
       uint32_t Mask = 1234;
       uint32_t Index;
--- 42662,42690 ----
  can contain registers which _might_ be shared by A, and GCC considers
  those registers to be inputs to the asm.  As above, GCC assumes that
  such input registers are consumed before any outputs are written.  This
! assumption may result in incorrect behavior if the ‘asm’ statement
! writes to A before using B.  Combining the ‘&’ modifier with the
  register constraint on A ensures that modifying A does not affect the
  address referenced by B.  Otherwise, the location of B is undefined if A
  is modified before using B.
  
!  ‘asm’ supports operand modifiers on operands (for example ‘%k2’ instead
! of simply ‘%2’).  *note Generic Operand modifiers:
  GenericOperandmodifiers. lists the modifiers that are available on all
  targets.  Other modifiers are hardware dependent.  For example, the list
  of supported modifiers for x86 is found at *note x86 Operand modifiers:
  x86Operandmodifiers.
  
!  If the C code that follows the ‘asm’ makes no use of any of the output
! operands, use ‘volatile’ for the ‘asm’ statement to prevent the
! optimizers from discarding the ‘asm’ statement as unneeded (see *note
  Volatile::).
  
   This code makes no use of the optional ASMSYMBOLICNAME.  Therefore it
! references the first output operand as ‘%0’ (were there a second, it
! would be ‘%1’, etc).  The number of the first input operand is one
  greater than that of the last output operand.  In this i386 example,
! that makes ‘Mask’ referenced as ‘%1’:
  
       uint32_t Mask = 1234;
       uint32_t Index;
*************** that makes 'Mask' referenced as '%1':
*** 42685,42692 ****
            : "r" (Mask)
            : "cc");
  
!  That code overwrites the variable 'Index' ('='), placing the value in a
! register ('r').  Using the generic 'r' constraint instead of a
  constraint for a specific register allows the compiler to pick the
  register to use, which can result in more efficient code.  This may not
  be possible if an assembler instruction requires a specific register.
--- 42694,42701 ----
            : "r" (Mask)
            : "cc");
  
!  That code overwrites the variable ‘Index’ (‘=’), placing the value in a
! register (‘r’).  Using the generic ‘r’ constraint instead of a
  constraint for a specific register allows the compiler to pick the
  register to use, which can result in more efficient code.  This may not
  be possible if an assembler instruction requires a specific register.
*************** be possible if an assembler instruction
*** 42694,42702 ****
   The following i386 example uses the ASMSYMBOLICNAME syntax.  It
  produces the same result as the code above, but some may consider it
  more readable or more maintainable since reordering index numbers is not
! necessary when adding or removing operands.  The names 'aIndex' and
! 'aMask' are only used in this example to emphasize which names get used
! where.  It is acceptable to reuse the names 'Index' and 'Mask'.
  
       uint32_t Mask = 1234;
       uint32_t Index;
--- 42703,42711 ----
   The following i386 example uses the ASMSYMBOLICNAME syntax.  It
  produces the same result as the code above, but some may consider it
  more readable or more maintainable since reordering index numbers is not
! necessary when adding or removing operands.  The names ‘aIndex’ and
! ‘aMask’ are only used in this example to emphasize which names get used
! where.  It is acceptable to reuse the names ‘Index’ and ‘Mask’.
  
       uint32_t Mask = 1234;
       uint32_t Index;
*************** where.  It is acceptable to reuse the na
*** 42716,42732 ****
          : [d] "=rm" (d)
          : [e] "rm" (*e));
  
!  Here, 'd' may either be in a register or in memory.  Since the compiler
! might already have the current value of the 'uint32_t' location pointed
! to by 'e' in a register, you can enable it to choose the best location
! for 'd' by specifying both constraints.
  
  6.47.2.4 Flag Output Operands
  .............................
  
  Some targets have a special register that holds the "flags" for the
  result of an operation or comparison.  Normally, the contents of that
! register are either unmodifed by the asm, or the 'asm' statement is
  considered to clobber the contents.
  
   On some targets, a special form of output operand exists by which
--- 42725,42741 ----
          : [d] "=rm" (d)
          : [e] "rm" (*e));
  
!  Here, ‘d’ may either be in a register or in memory.  Since the compiler
! might already have the current value of the ‘uint32_t’ location pointed
! to by ‘e’ in a register, you can enable it to choose the best location
! for ‘d’ by specifying both constraints.
  
  6.47.2.4 Flag Output Operands
  .............................
  
  Some targets have a special register that holds the "flags" for the
  result of an operation or comparison.  Normally, the contents of that
! register are either unmodifed by the asm, or the ‘asm’ statement is
  considered to clobber the contents.
  
   On some targets, a special form of output operand exists by which
*************** conditions in the flags register may be
*** 42734,42834 ****
  conditions supported are target specific, but the general rule is that
  the output variable must be a scalar integer, and the value is boolean.
  When supported, the target defines the preprocessor symbol
! '__GCC_ASM_FLAG_OUTPUTS__'.
  
   Because of the special nature of the flag output operands, the
  constraint may not include alternatives.
  
   Most often, the target has only one flags register, and thus is an
  implied operand of many instructions.  In this case, the operand should
! not be referenced within the assembler template via '%0' etc, as there's
  no corresponding text in the assembly language.
  
  ARM
  AArch64
       The flag output constraints for the ARM family are of the form
!      '=@ccCOND' where COND is one of the standard conditions defined in
!      the ARM ARM for 'ConditionHolds'.
  
!      'eq'
            Z flag set, or equal
!      'ne'
            Z flag clear or not equal
!      'cs'
!      'hs'
            C flag set or unsigned greater than equal
!      'cc'
!      'lo'
            C flag clear or unsigned less than
!      'mi'
            N flag set or "minus"
!      'pl'
            N flag clear or "plus"
!      'vs'
            V flag set or signed overflow
!      'vc'
            V flag clear
!      'hi'
            unsigned greater than
!      'ls'
            unsigned less than equal
!      'ge'
            signed greater than equal
!      'lt'
            signed less than
!      'gt'
            signed greater than
!      'le'
            signed less than equal
  
       The flag output constraints are not supported in thumb1 mode.
  
  x86 family
       The flag output constraints for the x86 family are of the form
!      '=@ccCOND' where COND is one of the standard conditions defined in
!      the ISA manual for 'jCC' or 'setCC'.
  
!      'a'
            "above" or unsigned greater than
!      'ae'
            "above or equal" or unsigned greater than or equal
!      'b'
            "below" or unsigned less than
!      'be'
            "below or equal" or unsigned less than or equal
!      'c'
            carry flag set
!      'e'
!      'z'
            "equal" or zero flag set
!      'g'
            signed greater than
!      'ge'
            signed greater than or equal
!      'l'
            signed less than
!      'le'
            signed less than or equal
!      'o'
            overflow flag set
!      'p'
            parity flag set
!      's'
            sign flag set
!      'na'
!      'nae'
!      'nb'
!      'nbe'
!      'nc'
!      'ne'
!      'ng'
!      'nge'
!      'nl'
!      'nle'
!      'no'
!      'np'
!      'ns'
!      'nz'
            "not" FLAG, or inverted versions of those above
  
  6.47.2.5 Input Operands
--- 42743,42843 ----
  conditions supported are target specific, but the general rule is that
  the output variable must be a scalar integer, and the value is boolean.
  When supported, the target defines the preprocessor symbol
! ‘__GCC_ASM_FLAG_OUTPUTS__’.
  
   Because of the special nature of the flag output operands, the
  constraint may not include alternatives.
  
   Most often, the target has only one flags register, and thus is an
  implied operand of many instructions.  In this case, the operand should
! not be referenced within the assembler template via ‘%0’ etc, as there's
  no corresponding text in the assembly language.
  
  ARM
  AArch64
       The flag output constraints for the ARM family are of the form
!      ‘=@ccCOND’ where COND is one of the standard conditions defined in
!      the ARM ARM for ‘ConditionHolds’.
  
!      ‘eq’
            Z flag set, or equal
!      ‘ne’
            Z flag clear or not equal
!      ‘cs’
!      ‘hs’
            C flag set or unsigned greater than equal
!      ‘cc’
!      ‘lo’
            C flag clear or unsigned less than
!      ‘mi’
            N flag set or "minus"
!      ‘pl’
            N flag clear or "plus"
!      ‘vs’
            V flag set or signed overflow
!      ‘vc’
            V flag clear
!      ‘hi’
            unsigned greater than
!      ‘ls’
            unsigned less than equal
!      ‘ge’
            signed greater than equal
!      ‘lt’
            signed less than
!      ‘gt’
            signed greater than
!      ‘le’
            signed less than equal
  
       The flag output constraints are not supported in thumb1 mode.
  
  x86 family
       The flag output constraints for the x86 family are of the form
!      ‘=@ccCOND’ where COND is one of the standard conditions defined in
!      the ISA manual for ‘jCC’ or ‘setCC’.
  
!      ‘a’
            "above" or unsigned greater than
!      ‘ae’
            "above or equal" or unsigned greater than or equal
!      ‘b’
            "below" or unsigned less than
!      ‘be’
            "below or equal" or unsigned less than or equal
!      ‘c’
            carry flag set
!      ‘e’
!      ‘z’
            "equal" or zero flag set
!      ‘g’
            signed greater than
!      ‘ge’
            signed greater than or equal
!      ‘l’
            signed less than
!      ‘le’
            signed less than or equal
!      ‘o’
            overflow flag set
!      ‘p’
            parity flag set
!      ‘s’
            sign flag set
!      ‘na’
!      ‘nae’
!      ‘nb’
!      ‘nbe’
!      ‘nc’
!      ‘ne’
!      ‘ng’
!      ‘nge’
!      ‘nl’
!      ‘nle’
!      ‘no’
!      ‘np’
!      ‘ns’
!      ‘nz’
            "not" FLAG, or inverted versions of those above
  
  6.47.2.5 Input Operands
*************** the assembly code.
*** 42844,42882 ****
  ASMSYMBOLICNAME
       Specifies a symbolic name for the operand.  Reference the name in
       the assembler template by enclosing it in square brackets (i.e.
!      '%[Value]').  The scope of the name is the 'asm' statement that
       contains the definition.  Any valid C variable name is acceptable,
       including names already defined in the surrounding code.  No two
!      operands within the same 'asm' statement can use the same symbolic
       name.
  
       When not using an ASMSYMBOLICNAME, use the (zero-based) position of
       the operand in the list of operands in the assembler template.  For
!      example if there are two output operands and three inputs, use '%2'
!      in the template to refer to the first input operand, '%3' for the
!      second, and '%4' for the third.
  
  CONSTRAINT
       A string constant specifying constraints on the placement of the
       operand; *Note Constraints::, for details.
  
!      Input constraint strings may not begin with either '=' or '+'.
       When you list more than one possible location (for example,
!      '"irm"'), the compiler chooses the most efficient one based on the
       current context.  If you must use a specific register, but your
       Machine Constraints do not provide sufficient control to select the
       specific register you want, local register variables may provide a
       solution (*note Local Register Variables::).
  
!      Input constraints can also be digits (for example, '"0"').  This
       indicates that the specified input must be in the same place as the
       output constraint at the (zero-based) index in the output
       constraint list.  When using ASMSYMBOLICNAME syntax for the output
!      operands, you may use these names (enclosed in brackets '[]')
       instead of digits.
  
  CEXPRESSION
!      This is the C variable or expression being passed to the 'asm'
       statement as input.  The enclosing parentheses are a required part
       of the syntax.
  
--- 42853,42891 ----
  ASMSYMBOLICNAME
       Specifies a symbolic name for the operand.  Reference the name in
       the assembler template by enclosing it in square brackets (i.e.
!      ‘%[Value]’).  The scope of the name is the ‘asm’ statement that
       contains the definition.  Any valid C variable name is acceptable,
       including names already defined in the surrounding code.  No two
!      operands within the same ‘asm’ statement can use the same symbolic
       name.
  
       When not using an ASMSYMBOLICNAME, use the (zero-based) position of
       the operand in the list of operands in the assembler template.  For
!      example if there are two output operands and three inputs, use ‘%2’
!      in the template to refer to the first input operand, ‘%3’ for the
!      second, and ‘%4’ for the third.
  
  CONSTRAINT
       A string constant specifying constraints on the placement of the
       operand; *Note Constraints::, for details.
  
!      Input constraint strings may not begin with either ‘=’ or ‘+’.
       When you list more than one possible location (for example,
!      ‘"irm"’), the compiler chooses the most efficient one based on the
       current context.  If you must use a specific register, but your
       Machine Constraints do not provide sufficient control to select the
       specific register you want, local register variables may provide a
       solution (*note Local Register Variables::).
  
!      Input constraints can also be digits (for example, ‘"0"’).  This
       indicates that the specified input must be in the same place as the
       output constraint at the (zero-based) index in the output
       constraint list.  When using ASMSYMBOLICNAME syntax for the output
!      operands, you may use these names (enclosed in brackets ‘[]’)
       instead of digits.
  
  CEXPRESSION
!      This is the C variable or expression being passed to the ‘asm’
       statement as input.  The enclosing parentheses are a required part
       of the syntax.
  
*************** consecutive colons where the output oper
*** 42893,42921 ****
  
   *Warning:* Do _not_ modify the contents of input-only operands (except
  for inputs tied to outputs).  The compiler assumes that on exit from the
! 'asm' statement these operands contain the same values as they had
  before executing the statement.  It is _not_ possible to use clobbers to
  inform the compiler that the values in these inputs are changing.  One
  common work-around is to tie the changing input variable to an output
  variable that never gets used.  Note, however, that if the code that
! follows the 'asm' statement makes no use of any of the output operands,
! the GCC optimizers may discard the 'asm' statement as unneeded (see
  *note Volatile::).
  
!  'asm' supports operand modifiers on operands (for example '%k2' instead
! of simply '%2').  *note Generic Operand modifiers:
  GenericOperandmodifiers. lists the modifiers that are available on all
  targets.  Other modifiers are hardware dependent.  For example, the list
  of supported modifiers for x86 is found at *note x86 Operand modifiers:
  x86Operandmodifiers.
  
!  In this example using the fictitious 'combine' instruction, the
! constraint '"0"' for input operand 1 says that it must occupy the same
  location as output operand 0.  Only input operands may use numbers in
  constraints, and they must each refer to an output operand.  Only a
  number (or the symbolic assembler name) in the constraint can guarantee
  that one operand is in the same place as another.  The mere fact that
! 'foo' is the value of both operands is not enough to guarantee that they
  are in the same place in the generated assembler code.
  
       asm ("combine %2, %0"
--- 42902,42930 ----
  
   *Warning:* Do _not_ modify the contents of input-only operands (except
  for inputs tied to outputs).  The compiler assumes that on exit from the
! ‘asm’ statement these operands contain the same values as they had
  before executing the statement.  It is _not_ possible to use clobbers to
  inform the compiler that the values in these inputs are changing.  One
  common work-around is to tie the changing input variable to an output
  variable that never gets used.  Note, however, that if the code that
! follows the ‘asm’ statement makes no use of any of the output operands,
! the GCC optimizers may discard the ‘asm’ statement as unneeded (see
  *note Volatile::).
  
!  ‘asm’ supports operand modifiers on operands (for example ‘%k2’ instead
! of simply ‘%2’).  *note Generic Operand modifiers:
  GenericOperandmodifiers. lists the modifiers that are available on all
  targets.  Other modifiers are hardware dependent.  For example, the list
  of supported modifiers for x86 is found at *note x86 Operand modifiers:
  x86Operandmodifiers.
  
!  In this example using the fictitious ‘combine’ instruction, the
! constraint ‘"0"’ for input operand 1 says that it must occupy the same
  location as output operand 0.  Only input operands may use numbers in
  constraints, and they must each refer to an output operand.  Only a
  number (or the symbolic assembler name) in the constraint can guarantee
  that one operand is in the same place as another.  The mere fact that
! ‘foo’ is the value of both operands is not enough to guarantee that they
  are in the same place in the generated assembler code.
  
       asm ("combine %2, %0"
*************** are in the same place in the generated a
*** 42932,42938 ****
  .......................................
  
  While the compiler is aware of changes to entries listed in the output
! operands, the inline 'asm' code may modify more than just the outputs.
  For example, calculations may require additional registers, or the
  processor may overwrite a register as a side effect of a particular
  assembler instruction.  In order to inform the compiler of these
--- 42941,42947 ----
  .......................................
  
  While the compiler is aware of changes to entries listed in the output
! operands, the inline ‘asm’ code may modify more than just the outputs.
  For example, calculations may require additional registers, or the
  processor may overwrite a register as a side effect of a particular
  assembler instruction.  In order to inform the compiler of these
*************** by commas.
*** 42945,42951 ****
  operand.  For example, you may not have an operand describing a register
  class with one member when listing that register in the clobber list.
  Variables declared to live in specific registers (*note Explicit
! Register Variables::) and used as 'asm' input or output operands must
  have no part mentioned in the clobber description.  In particular, there
  is no way to specify that input operands get modified without also
  specifying them as output operands.
--- 42954,42960 ----
  operand.  For example, you may not have an operand describing a register
  class with one member when listing that register in the clobber list.
  Variables declared to live in specific registers (*note Explicit
! Register Variables::) and used as ‘asm’ input or output operands must
  have no part mentioned in the clobber description.  In particular, there
  is no way to specify that input operands get modified without also
  specifying them as output operands.
*************** code.
*** 42957,42963 ****
  
   Another restriction is that the clobber list should not contain the
  stack pointer register.  This is because the compiler requires the value
! of the stack pointer to be the same after an 'asm' statement as it was
  on entry to the statement.  However, previous versions of GCC did not
  enforce this rule and allowed the stack pointer to appear in the list,
  with unclear semantics.  This behavior is deprecated and listing the
--- 42966,42972 ----
  
   Another restriction is that the clobber list should not contain the
  stack pointer register.  This is because the compiler requires the value
! of the stack pointer to be the same after an ‘asm’ statement as it was
  on entry to the statement.  However, previous versions of GCC did not
  enforce this rule and allowed the stack pointer to appear in the list,
  with unclear semantics.  This behavior is deprecated and listing the
*************** registers:
*** 42973,43000 ****
  
   Also, there are two special clobber arguments:
  
! '"cc"'
!      The '"cc"' clobber indicates that the assembler code modifies the
       flags register.  On some machines, GCC represents the condition
!      codes as a specific hardware register; '"cc"' serves to name this
       register.  On other machines, condition code handling is different,
!      and specifying '"cc"' has no effect.  But it is valid no matter
       what the target.
  
! '"memory"'
!      The '"memory"' clobber tells the compiler that the assembly code
       performs memory reads or writes to items other than those listed in
       the input and output operands (for example, accessing the memory
       pointed to by one of the input parameters).  To ensure memory
       contains correct values, GCC may need to flush specific register
!      values to memory before executing the 'asm'.  Further, the compiler
!      does not assume that any values read from memory before an 'asm'
!      remain unchanged after that 'asm'; it reloads them as needed.
!      Using the '"memory"' clobber effectively forms a read/write memory
       barrier for the compiler.
  
       Note that this clobber does not prevent the _processor_ from doing
!      speculative reads past the 'asm' statement.  To prevent that, you
       need processor-specific fence instructions.
  
   Flushing registers to memory has performance implications and may be an
--- 42982,43009 ----
  
   Also, there are two special clobber arguments:
  
! ‘"cc"’
!      The ‘"cc"’ clobber indicates that the assembler code modifies the
       flags register.  On some machines, GCC represents the condition
!      codes as a specific hardware register; ‘"cc"’ serves to name this
       register.  On other machines, condition code handling is different,
!      and specifying ‘"cc"’ has no effect.  But it is valid no matter
       what the target.
  
! ‘"memory"’
!      The ‘"memory"’ clobber tells the compiler that the assembly code
       performs memory reads or writes to items other than those listed in
       the input and output operands (for example, accessing the memory
       pointed to by one of the input parameters).  To ensure memory
       contains correct values, GCC may need to flush specific register
!      values to memory before executing the ‘asm’.  Further, the compiler
!      does not assume that any values read from memory before an ‘asm’
!      remain unchanged after that ‘asm’; it reloads them as needed.
!      Using the ‘"memory"’ clobber effectively forms a read/write memory
       barrier for the compiler.
  
       Note that this clobber does not prevent the _processor_ from doing
!      speculative reads past the ‘asm’ statement.  To prevent that, you
       need processor-specific fence instructions.
  
   Flushing registers to memory has performance implications and may be an
*************** flushed.
*** 43005,43026 ****
  
   Here is a fictitious sum of squares instruction, that takes two
  pointers to floating point values in memory and produces a floating
! point register output.  Notice that 'x', and 'y' both appear twice in
! the 'asm' parameters, once to specify memory accessed, and once to
! specify a base register used by the 'asm'.  You won't normally be
  wasting a register by doing this as GCC can use the same register for
! both purposes.  However, it would be foolish to use both '%1' and '%3'
! for 'x' in this 'asm' and expect them to be the same.  In fact, '%3' may
  well not be a register.  It might be a symbolic memory reference to the
! object pointed to by 'x'.
  
       asm ("sumsq %0, %1, %2"
            : "+f" (result)
            : "r" (x), "r" (y), "m" (*x), "m" (*y));
  
!  Here is a fictitious '*z++ = *x++ * *y++' instruction.  Notice that the
! 'x', 'y' and 'z' pointer registers must be specified as input/output
! because the 'asm' modifies them.
  
       asm ("vecmul %0, %1, %2"
            : "+r" (z), "+r" (x), "+r" (y), "=m" (*z)
--- 43014,43035 ----
  
   Here is a fictitious sum of squares instruction, that takes two
  pointers to floating point values in memory and produces a floating
! point register output.  Notice that ‘x’, and ‘y’ both appear twice in
! the ‘asm’ parameters, once to specify memory accessed, and once to
! specify a base register used by the ‘asm’.  You won't normally be
  wasting a register by doing this as GCC can use the same register for
! both purposes.  However, it would be foolish to use both ‘%1’ and ‘%3’
! for ‘x’ in this ‘asm’ and expect them to be the same.  In fact, ‘%3’ may
  well not be a register.  It might be a symbolic memory reference to the
! object pointed to by ‘x’.
  
       asm ("sumsq %0, %1, %2"
            : "+f" (result)
            : "r" (x), "r" (y), "m" (*x), "m" (*y));
  
!  Here is a fictitious ‘*z++ = *x++ * *y++’ instruction.  Notice that the
! ‘x’, ‘y’ and ‘z’ pointer registers must be specified as input/output
! because the ‘asm’ modifies them.
  
       asm ("vecmul %0, %1, %2"
            : "+r" (z), "+r" (x), "+r" (y), "=m" (*z)
*************** because the 'asm' modifies them.
*** 43033,43043 ****
           : "m" (*(const char (*)[]) p), "0" (-1), "a" (0));
  
   If you know the above will only be reading a ten byte array then you
! could instead use a memory input like: '"m" (*(const char (*)[10]) p)'.
  
   Here is an example of a PowerPC vector scale implemented in assembly,
  complete with vector and condition code clobbers, and some initialized
! offset registers that are unchanged by the 'asm'.
  
       void
       dscal (size_t n, double *x, double alpha)
--- 43042,43052 ----
           : "m" (*(const char (*)[]) p), "0" (-1), "a" (0));
  
   If you know the above will only be reading a ten byte array then you
! could instead use a memory input like: ‘"m" (*(const char (*)[10]) p)’.
  
   Here is an example of a PowerPC vector scale implemented in assembly,
  complete with vector and condition code clobbers, and some initialized
! offset registers that are unchanged by the ‘asm’.
  
       void
       dscal (size_t n, double *x, double alpha)
*************** offset registers that are unchanged by t
*** 43052,43082 ****
       }
  
   Rather than allocating fixed registers via clobbers to provide scratch
! registers for an 'asm' statement, an alternative is to define a variable
! and make it an early-clobber output as with 'a2' and 'a3' in the example
  below.  This gives the compiler register allocator more freedom.  You
  can also define a variable and make it an output tied to an input as
! with 'a0' and 'a1', tied respectively to 'ap' and 'lda'.  Of course,
! with tied outputs your 'asm' can't use the input value after modifying
  the output register since they are one and the same register.  What's
  more, if you omit the early-clobber on the output, it is possible that
  GCC might allocate the same register to another of the inputs if GCC
! could prove they had the same value on entry to the 'asm'.  This is why
! 'a1' has an early-clobber.  Its tied input, 'lda' might conceivably be
  known to have the value 16 and without an early-clobber share the same
! register as '%11'.  On the other hand, 'ap' can't be the same as any of
! the other inputs, so an early-clobber on 'a0' is not needed.  It is also
! not desirable in this case.  An early-clobber on 'a0' would cause GCC to
! allocate a separate register for the '"m" (*(const double (*)[]) ap)'
  input.  Note that tying an input to an output is the way to set up an
! initialized temporary register modified by an 'asm' statement.  An input
  not tied to an output is assumed by GCC to be unchanged, for example
! '"b" (16)' below sets up '%11' to 16, and GCC might use that register in
  following code if the value 16 happened to be needed.  You can even use
! a normal 'asm' output for a scratch if all inputs that might share the
  same register are consumed before the scratch is used.  The VSX
! registers clobbered by the 'asm' statement could have used this
! technique except for GCC's limit on the number of 'asm' parameters.
  
       static void
       dgemv_kernel_4x4 (long n, const double *ap, long lda,
--- 43061,43091 ----
       }
  
   Rather than allocating fixed registers via clobbers to provide scratch
! registers for an ‘asm’ statement, an alternative is to define a variable
! and make it an early-clobber output as with ‘a2’ and ‘a3’ in the example
  below.  This gives the compiler register allocator more freedom.  You
  can also define a variable and make it an output tied to an input as
! with ‘a0’ and ‘a1’, tied respectively to ‘ap’ and ‘lda’.  Of course,
! with tied outputs your ‘asm’ can't use the input value after modifying
  the output register since they are one and the same register.  What's
  more, if you omit the early-clobber on the output, it is possible that
  GCC might allocate the same register to another of the inputs if GCC
! could prove they had the same value on entry to the ‘asm’.  This is why
! ‘a1’ has an early-clobber.  Its tied input, ‘lda’ might conceivably be
  known to have the value 16 and without an early-clobber share the same
! register as ‘%11’.  On the other hand, ‘ap’ can't be the same as any of
! the other inputs, so an early-clobber on ‘a0’ is not needed.  It is also
! not desirable in this case.  An early-clobber on ‘a0’ would cause GCC to
! allocate a separate register for the ‘"m" (*(const double (*)[]) ap)’
  input.  Note that tying an input to an output is the way to set up an
! initialized temporary register modified by an ‘asm’ statement.  An input
  not tied to an output is assumed by GCC to be unchanged, for example
! ‘"b" (16)’ below sets up ‘%11’ to 16, and GCC might use that register in
  following code if the value 16 happened to be needed.  You can even use
! a normal ‘asm’ output for a scratch if all inputs that might share the
  same register are consumed before the scratch is used.  The VSX
! registers clobbered by the ‘asm’ statement could have used this
! technique except for GCC's limit on the number of ‘asm’ parameters.
  
       static void
       dgemv_kernel_4x4 (long n, const double *ap, long lda,
*************** technique except for GCC's limit on the
*** 43118,43163 ****
  6.47.2.7 Goto Labels
  ....................
  
! 'asm goto' allows assembly code to jump to one or more C labels.  The
! GOTOLABELS section in an 'asm goto' statement contains a comma-separated
  list of all C labels to which the assembler code may jump.  GCC assumes
! that 'asm' execution falls through to the next statement (if this is not
! the case, consider using the '__builtin_unreachable' intrinsic after the
! 'asm' statement).  Optimization of 'asm goto' may be improved by using
! the 'hot' and 'cold' label attributes (*note Label Attributes::).
  
!  If the assembler code does modify anything, use the '"memory"' clobber
  to force the optimizers to flush all register values to memory and
! reload them if necessary after the 'asm' statement.
  
!  Also note that an 'asm goto' statement is always implicitly considered
  volatile.
  
!  Be careful when you set output operands inside 'asm goto' only on some
  possible control flow paths.  If you don't set up the output on given
  path and never use it on this path, it is okay.  Otherwise, you should
! use '+' constraint modifier meaning that the operand is input and output
  one.  With this modifier you will have the correct values on all
! possible paths from the 'asm goto'.
  
!  To reference a label in the assembler template, prefix it with '%l'
! (lowercase 'L') followed by its (zero-based) position in GOTOLABELS plus
  the number of input and output operands.  Output operand with constraint
! modifier '+' is counted as two operands because it is considered as one
! output and one input operand.  For example, if the 'asm' has three
! inputs, one output operand with constraint modifier '+' and one output
! operand with constraint modifier '=' and references two labels, refer to
! the first label as '%l6' and the second as '%l7').
  
   Alternately, you can reference labels using the actual C label name
! enclosed in brackets.  For example, to reference a label named 'carry',
! you can use '%l[carry]'.  The label must still be listed in the
  GOTOLABELS section when using this approach.  It is better to use the
  named references for labels as in this case you can avoid counting input
  and output operands and special treatment of output operands with
! constraint modifier '+'.
  
!  Here is an example of 'asm goto' for i386:
  
       asm goto (
           "btl %1, %0\n\t"
--- 43127,43172 ----
  6.47.2.7 Goto Labels
  ....................
  
! ‘asm goto’ allows assembly code to jump to one or more C labels.  The
! GOTOLABELS section in an ‘asm goto’ statement contains a comma-separated
  list of all C labels to which the assembler code may jump.  GCC assumes
! that ‘asm’ execution falls through to the next statement (if this is not
! the case, consider using the ‘__builtin_unreachable’ intrinsic after the
! ‘asm’ statement).  Optimization of ‘asm goto’ may be improved by using
! the ‘hot’ and ‘cold’ label attributes (*note Label Attributes::).
  
!  If the assembler code does modify anything, use the ‘"memory"’ clobber
  to force the optimizers to flush all register values to memory and
! reload them if necessary after the ‘asm’ statement.
  
!  Also note that an ‘asm goto’ statement is always implicitly considered
  volatile.
  
!  Be careful when you set output operands inside ‘asm goto’ only on some
  possible control flow paths.  If you don't set up the output on given
  path and never use it on this path, it is okay.  Otherwise, you should
! use ‘+’ constraint modifier meaning that the operand is input and output
  one.  With this modifier you will have the correct values on all
! possible paths from the ‘asm goto’.
  
!  To reference a label in the assembler template, prefix it with ‘%l’
! (lowercase ‘L’) followed by its (zero-based) position in GOTOLABELS plus
  the number of input and output operands.  Output operand with constraint
! modifier ‘+’ is counted as two operands because it is considered as one
! output and one input operand.  For example, if the ‘asm’ has three
! inputs, one output operand with constraint modifier ‘+’ and one output
! operand with constraint modifier ‘=’ and references two labels, refer to
! the first label as ‘%l6’ and the second as ‘%l7’).
  
   Alternately, you can reference labels using the actual C label name
! enclosed in brackets.  For example, to reference a label named ‘carry’,
! you can use ‘%l[carry]’.  The label must still be listed in the
  GOTOLABELS section when using this approach.  It is better to use the
  named references for labels as in this case you can avoid counting input
  and output operands and special treatment of output operands with
! constraint modifier ‘+’.
  
!  Here is an example of ‘asm goto’ for i386:
  
       asm goto (
           "btl %1, %0\n\t"
*************** constraint modifier '+'.
*** 43172,43178 ****
       carry:
       return 1;
  
!  The following example shows an 'asm goto' that uses a memory clobber.
  
       int frob(int x)
       {
--- 43181,43187 ----
       carry:
       return 1;
  
!  The following example shows an ‘asm goto’ that uses a memory clobber.
  
       int frob(int x)
       {
*************** constraint modifier '+'.
*** 43187,43193 ****
         return -1;
       }
  
!  The following example shows an 'asm goto' that uses an output.
  
       int foo(int count)
       {
--- 43196,43202 ----
         return -1;
       }
  
!  The following example shows an ‘asm goto’ that uses an output.
  
       int foo(int count)
       {
*************** constraint modifier '+'.
*** 43201,43210 ****
         return 0;
       }
  
!  The following artificial example shows an 'asm goto' that sets up an
! output only on one path inside the 'asm goto'.  Usage of constraint
! modifier '=' instead of '+' would be wrong as 'factor' is used on all
! paths from the 'asm goto'.
  
       int foo(int inp)
       {
--- 43210,43219 ----
         return 0;
       }
  
!  The following artificial example shows an ‘asm goto’ that sets up an
! output only on one path inside the ‘asm goto’.  Usage of constraint
! modifier ‘=’ instead of ‘+’ would be wrong as ‘factor’ is used on all
! paths from the ‘asm goto’.
  
       int foo(int inp)
       {
*************** their effects:
*** 43226,43250 ****
  
  Modifier    Description                                        Example
  ---------------------------------------------------------------------------
! 'c'         Require a constant operand and print the           '%c0'
              constant expression with no punctuation.
! 'n'         Like '%c' except that the value of the constant    '%n0'
              is negated before printing.
! 'a'         Substitute a memory reference, with the actual     '%a0'
              operand treated as the address.  This may be
              useful when outputting a "load address"
              instruction, because often the assembler syntax
              for such an instruction requires you to write
              the operand as if it were a memory reference.
! 'l'         Print the label name with no punctuation.          '%l0'
  
  6.47.2.9 x86 Operand Modifiers
  ..............................
  
  References to input, output, and goto operands in the assembler template
! of extended 'asm' statements can use modifiers to affect the way the
  operands are formatted in the code output to the assembler.  For
! example, the following code uses the 'h' and 'b' modifiers for x86:
  
       uint16_t  num;
       asm volatile ("xchg %h0, %b0" : "+a" (num) );
--- 43235,43259 ----
  
  Modifier    Description                                        Example
  ---------------------------------------------------------------------------
! ‘c’         Require a constant operand and print the           ‘%c0’
              constant expression with no punctuation.
! ‘n’         Like ‘%c’ except that the value of the constant    ‘%n0’
              is negated before printing.
! ‘a’         Substitute a memory reference, with the actual     ‘%a0’
              operand treated as the address.  This may be
              useful when outputting a "load address"
              instruction, because often the assembler syntax
              for such an instruction requires you to write
              the operand as if it were a memory reference.
! ‘l’         Print the label name with no punctuation.          ‘%l0’
  
  6.47.2.9 x86 Operand Modifiers
  ..............................
  
  References to input, output, and goto operands in the assembler template
! of extended ‘asm’ statements can use modifiers to affect the way the
  operands are formatted in the code output to the assembler.  For
! example, the following code uses the ‘h’ and ‘b’ modifiers for x86:
  
       uint16_t  num;
       asm volatile ("xchg %h0, %b0" : "+a" (num) );
*************** purposes.
*** 43270,43364 ****
       }
  
   With no modifiers, this is what the output from the operands would be
! for the 'att' and 'intel' dialects of assembler:
  
! Operand   'att'  'intel'
  -----------------------------------
! '%0'      '%eax' 'eax'
! '%1'      '$2'   '2'
! '%3'      '$.L3' 'OFFSET
!                  FLAT:.L3'
! '%4'      '$8'   '8'
! '%5'      '%xmm0''xmm0'
! '%7'      '$0'   '0'
  
   The table below shows the list of supported modifiers and their
  effects.
  
! Modifier   Description                                  Operand   'att'   'intel'
  ------------------------------------------------------------------------------------
! 'A'        Print an absolute memory reference.          '%A0'     '*%rax' 'rax'
! 'b'        Print the QImode name of the register.       '%b0'     '%al'   'al'
! 'B'        print the opcode suffix of b.                '%B0'     'b'
! 'c'        Require a constant operand and print the     '%c1'     '2'     '2'
             constant expression with no punctuation.
! 'd'        print duplicated register operand for AVX    '%d5'     '%xmm0, 'xmm0,
!            instruction.                                           %xmm0'  xmm0'
! 'E'        Print the address in Double Integer          '%E1'     '%(rax)''[rax]'
             (DImode) mode (8 bytes) when the target is
             64-bit.  Otherwise mode is unspecified
             (VOIDmode).
! 'g'        Print the V16SFmode name of the register.    '%g0'     '%zmm0' 'zmm0'
! 'h'        Print the QImode name for a "high"           '%h0'     '%ah'   'ah'
             register.
! 'H'        Add 8 bytes to an offsettable memory         '%H0'     '8(%rax)''8[rax]'
             reference.  Useful when accessing the high
             8 bytes of SSE values.  For a memref in
             (%rax), it generates
! 'k'        Print the SImode name of the register.       '%k0'     '%eax'  'eax'
! 'l'        Print the label name with no punctuation.    '%l3'     '.L3'   '.L3'
! 'L'        print the opcode suffix of l.                '%L0'     'l'
! 'N'        print maskz.                                 '%N7'     '{z}'   '{z}'
! 'p'        Print raw symbol name (without               '%p2'     '42'    '42'
             syntax-specific prefixes).
! 'P'        If used for a function, print the PLT
             suffix and generate PIC code.  For
!            example, emit 'foo@PLT' instead of 'foo'
             for the function foo().  If used for a
             constant, drop all syntax-specific
             prefixes and issue the bare constant.  See
!            'p' above.
! 'q'        Print the DImode name of the register.       '%q0'     '%rax'  'rax'
! 'Q'        print the opcode suffix of q.                '%Q0'     'q'
! 'R'        print embedded rounding and sae.             '%R4'     '{rn-sae},',
!                                                                   '       {rn-sae}'
! 'r'        print only sae.                              '%r4'     '{sae}, ',
!                                                                   '       {sae}'
! 's'        print a shift double count, followed by      '%s1'     '$2,    '2, '
!            the assemblers argument delimiterprint the             '
             opcode suffix of s.
! 'S'        print the opcode suffix of s.                '%S0'     's'
! 't'        print the V8SFmode name of the register.     '%t5'     '%ymm0' 'ymm0'
! 'T'        print the opcode suffix of t.                '%T0'     't'
! 'V'        print naked full integer register name       '%V0'     'eax'   'eax'
             without %.
! 'w'        Print the HImode name of the register.       '%w0'     '%ax'   'ax'
! 'W'        print the opcode suffix of w.                '%W0'     'w'
! 'x'        print the V4SFmode name of the register.     '%x5'     '%xmm0' 'xmm0'
! 'y'        print "st(0)" instead of "st" as a           '%y6'     '%st(0)''st(0)'
             register.
! 'z'        Print the opcode suffix for the size of      '%z0'     'l'
             the current integer operand (one of
!            'b'/'w'/'l'/'q').
! 'Z'        Like 'z', with special suffixes for x87
             instructions.
  
! 6.47.2.10 x86 Floating-Point 'asm' Operands
  ...........................................
  
  On x86 targets, there are several rules on the usage of stack-like
! registers in the operands of an 'asm'.  These rules apply only to the
  operands that are stack-like registers:
  
!   1. Given a set of input registers that die in an 'asm', it is
!      necessary to know which are implicitly popped by the 'asm', and
       which must be explicitly popped by GCC.
  
!      An input register that is implicitly popped by the 'asm' must be
       explicitly clobbered, unless it is constrained to match an output
       operand.
  
!   2. For any input register that is implicitly popped by an 'asm', it is
       necessary to know how to adjust the stack to compensate for the
       pop.  If any non-popped input is closer to the top of the reg-stack
       than the implicitly popped register, it would not be possible to
--- 43279,43373 ----
       }
  
   With no modifiers, this is what the output from the operands would be
! for the ‘att’ and ‘intel’ dialects of assembler:
  
! Operand   ‘att’  ‘intel’
  -----------------------------------
! ‘%0’      ‘%eax’ ‘eax’
! ‘%1’      ‘$2’   ‘2’
! ‘%3’      ‘$.L3’ ‘OFFSET
!                  FLAT:.L3’
! ‘%4’      ‘$8’   ‘8’
! ‘%5’      ‘%xmm0’‘xmm0’
! ‘%7’      ‘$0’   ‘0’
  
   The table below shows the list of supported modifiers and their
  effects.
  
! Modifier   Description                                  Operand   ‘att’   ‘intel’
  ------------------------------------------------------------------------------------
! ‘A’        Print an absolute memory reference.          ‘%A0’     ‘*%rax’ ‘rax’
! ‘b’        Print the QImode name of the register.       ‘%b0’     ‘%al’   ‘al’
! ‘B’        print the opcode suffix of b.                ‘%B0’     ‘b’
! ‘c’        Require a constant operand and print the     ‘%c1’     ‘2’     ‘2’
             constant expression with no punctuation.
! ‘d’        print duplicated register operand for AVX    ‘%d5’     ‘%xmm0, ‘xmm0,
!            instruction.                                           %xmm0’  xmm0’
! ‘E’        Print the address in Double Integer          ‘%E1’     ‘%(rax)’‘[rax]’
             (DImode) mode (8 bytes) when the target is
             64-bit.  Otherwise mode is unspecified
             (VOIDmode).
! ‘g’        Print the V16SFmode name of the register.    ‘%g0’     ‘%zmm0’ ‘zmm0’
! ‘h’        Print the QImode name for a "high"           ‘%h0’     ‘%ah’   ‘ah’
             register.
! ‘H’        Add 8 bytes to an offsettable memory         ‘%H0’     ‘8(%rax)’‘8[rax]’
             reference.  Useful when accessing the high
             8 bytes of SSE values.  For a memref in
             (%rax), it generates
! ‘k’        Print the SImode name of the register.       ‘%k0’     ‘%eax’  ‘eax’
! ‘l’        Print the label name with no punctuation.    ‘%l3’     ‘.L3’   ‘.L3’
! ‘L’        print the opcode suffix of l.                ‘%L0’     ‘l’
! ‘N’        print maskz.                                 ‘%N7’     ‘{z}’   ‘{z}’
! ‘p’        Print raw symbol name (without               ‘%p2’     ‘42’    ‘42’
             syntax-specific prefixes).
! ‘P’        If used for a function, print the PLT
             suffix and generate PIC code.  For
!            example, emit ‘foo@PLT’ instead of 'foo'
             for the function foo().  If used for a
             constant, drop all syntax-specific
             prefixes and issue the bare constant.  See
!            ‘p’ above.
! ‘q’        Print the DImode name of the register.       ‘%q0’     ‘%rax’  ‘rax’
! ‘Q’        print the opcode suffix of q.                ‘%Q0’     ‘q’
! ‘R’        print embedded rounding and sae.             ‘%R4’     ‘{rn-sae},‘,
!                                                                   ’       {rn-sae}’
! ‘r’        print only sae.                              ‘%r4’     ‘{sae}, ‘,
!                                                                   ’       {sae}’
! ‘s’        print a shift double count, followed by      ‘%s1’     ‘$2,    ‘2, ’
!            the assemblers argument delimiterprint the             ’
             opcode suffix of s.
! ‘S’        print the opcode suffix of s.                ‘%S0’     ‘s’
! ‘t’        print the V8SFmode name of the register.     ‘%t5’     ‘%ymm0’ ‘ymm0’
! ‘T’        print the opcode suffix of t.                ‘%T0’     ‘t’
! ‘V’        print naked full integer register name       ‘%V0’     ‘eax’   ‘eax’
             without %.
! ‘w’        Print the HImode name of the register.       ‘%w0’     ‘%ax’   ‘ax’
! ‘W’        print the opcode suffix of w.                ‘%W0’     ‘w’
! ‘x’        print the V4SFmode name of the register.     ‘%x5’     ‘%xmm0’ ‘xmm0’
! ‘y’        print "st(0)" instead of "st" as a           ‘%y6’     ‘%st(0)’‘st(0)’
             register.
! ‘z’        Print the opcode suffix for the size of      ‘%z0’     ‘l’
             the current integer operand (one of
!            ‘b’/‘w’/‘l’/‘q’).
! ‘Z’        Like ‘z’, with special suffixes for x87
             instructions.
  
! 6.47.2.10 x86 Floating-Point ‘asm’ Operands
  ...........................................
  
  On x86 targets, there are several rules on the usage of stack-like
! registers in the operands of an ‘asm’.  These rules apply only to the
  operands that are stack-like registers:
  
!   1. Given a set of input registers that die in an ‘asm’, it is
!      necessary to know which are implicitly popped by the ‘asm’, and
       which must be explicitly popped by GCC.
  
!      An input register that is implicitly popped by the ‘asm’ must be
       explicitly clobbered, unless it is constrained to match an output
       operand.
  
!   2. For any input register that is implicitly popped by an ‘asm’, it is
       necessary to know how to adjust the stack to compensate for the
       pop.  If any non-popped input is closer to the top of the reg-stack
       than the implicitly popped register, it would not be possible to
*************** operands that are stack-like registers:
*** 43368,43387 ****
       All implicitly popped input registers must be closer to the top of
       the reg-stack than any input that is not implicitly popped.
  
!      It is possible that if an input dies in an 'asm', the compiler
       might use the input register for an output reload.  Consider this
       example:
  
            asm ("foo" : "=t" (a) : "f" (b));
  
!      This code says that input 'b' is not popped by the 'asm', and that
!      the 'asm' pushes a result onto the reg-stack, i.e., the stack is
!      one deeper after the 'asm' than it was before.  But, it is possible
       that reload may think that it can use the same register for both
       the input and the output.
  
!      To prevent this from happening, if any input operand uses the 'f'
!      constraint, all output register constraints must use the '&'
       early-clobber modifier.
  
       The example above is correctly written as:
--- 43377,43396 ----
       All implicitly popped input registers must be closer to the top of
       the reg-stack than any input that is not implicitly popped.
  
!      It is possible that if an input dies in an ‘asm’, the compiler
       might use the input register for an output reload.  Consider this
       example:
  
            asm ("foo" : "=t" (a) : "f" (b));
  
!      This code says that input ‘b’ is not popped by the ‘asm’, and that
!      the ‘asm’ pushes a result onto the reg-stack, i.e., the stack is
!      one deeper after the ‘asm’ than it was before.  But, it is possible
       that reload may think that it can use the same register for both
       the input and the output.
  
!      To prevent this from happening, if any input operand uses the ‘f’
!      constraint, all output register constraints must use the ‘&’
       early-clobber modifier.
  
       The example above is correctly written as:
*************** operands that are stack-like registers:
*** 43394,43423 ****
       the constraints.
  
       Output operands must specifically indicate which register an output
!      appears in after an 'asm'.  '=f' is not allowed: the operand
       constraints must select a class with a single register.
  
    4. Output operands may not be "inserted" between existing stack
       registers.  Since no 387 opcode uses a read/write operand, all
!      output operands are dead before the 'asm', and are pushed by the
!      'asm'.  It makes no sense to push anywhere but the top of the
       reg-stack.
  
       Output operands must start at the top of the reg-stack: output
       operands may not "skip" a register.
  
!   5. Some 'asm' statements may need extra stack space for internal
       calculations.  This can be guaranteed by clobbering stack registers
       unrelated to the inputs and outputs.
  
!  This 'asm' takes one input, which is internally popped, and produces
  two outputs.
  
       asm ("fsincos" : "=t" (cos), "=u" (sin) : "0" (inp));
  
! This 'asm' takes two inputs, which are popped by the 'fyl2xp1' opcode,
! and replaces them with one output.  The 'st(1)' clobber is necessary for
! the compiler to know that 'fyl2xp1' pops both inputs.
  
       asm ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)");
  
--- 43403,43432 ----
       the constraints.
  
       Output operands must specifically indicate which register an output
!      appears in after an ‘asm’.  ‘=f’ is not allowed: the operand
       constraints must select a class with a single register.
  
    4. Output operands may not be "inserted" between existing stack
       registers.  Since no 387 opcode uses a read/write operand, all
!      output operands are dead before the ‘asm’, and are pushed by the
!      ‘asm’.  It makes no sense to push anywhere but the top of the
       reg-stack.
  
       Output operands must start at the top of the reg-stack: output
       operands may not "skip" a register.
  
!   5. Some ‘asm’ statements may need extra stack space for internal
       calculations.  This can be guaranteed by clobbering stack registers
       unrelated to the inputs and outputs.
  
!  This ‘asm’ takes one input, which is internally popped, and produces
  two outputs.
  
       asm ("fsincos" : "=t" (cos), "=u" (sin) : "0" (inp));
  
! This ‘asm’ takes two inputs, which are popped by the ‘fyl2xp1’ opcode,
! and replaces them with one output.  The ‘st(1)’ clobber is necessary for
! the compiler to know that ‘fyl2xp1’ pops both inputs.
  
       asm ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)");
  
*************** MSP430.
*** 43429,43459 ****
  
  ModifierDescription
  --------------------------------------------------------------------------
! 'A'     Select low 16-bits of the constant/register/memory operand.
! 'B'     Select high 16-bits of the constant/register/memory operand.
! 'C'     Select bits 32-47 of the constant/register/memory operand.
! 'D'     Select bits 48-63 of the constant/register/memory operand.
! 'H'     Equivalent to 'B' (for backwards compatibility).
! 'I'     Print the inverse (logical 'NOT') of the constant value.
! 'J'     Print an integer without a '#' prefix.
! 'L'     Equivalent to 'A' (for backwards compatibility).
! 'O'     Offset of the current frame from the top of the stack.
! 'Q'     Use the 'A' instruction postfix.
! 'R'     Inverse of condition code, for unsigned comparisons.
! 'W'     Subtract 16 from the constant value.
! 'X'     Use the 'X' instruction postfix.
! 'Y'     Subtract 4 from the constant value.
! 'Z'     Subtract 1 from the constant value.
! 'b'     Append '.B', '.W' or '.A' to the instruction, depending on the
          mode.
! 'd'     Offset 1 byte of a memory reference or constant value.
! 'e'     Offset 3 bytes of a memory reference or constant value.
! 'f'     Offset 5 bytes of a memory reference or constant value.
! 'g'     Offset 7 bytes of a memory reference or constant value.
! 'p'     Print the value of 2, raised to the power of the given
          constant.  Used to select the specified bit position.
! 'r'     Inverse of condition code, for signed comparisons.
! 'x'     Equivialent to 'X', but only for pointers.
  
  6.47.2.12 LoongArch Operand Modifiers
  .....................................
--- 43438,43468 ----
  
  ModifierDescription
  --------------------------------------------------------------------------
! ‘A’     Select low 16-bits of the constant/register/memory operand.
! ‘B’     Select high 16-bits of the constant/register/memory operand.
! ‘C’     Select bits 32-47 of the constant/register/memory operand.
! ‘D’     Select bits 48-63 of the constant/register/memory operand.
! ‘H’     Equivalent to ‘B’ (for backwards compatibility).
! ‘I’     Print the inverse (logical ‘NOT’) of the constant value.
! ‘J’     Print an integer without a ‘#’ prefix.
! ‘L’     Equivalent to ‘A’ (for backwards compatibility).
! ‘O’     Offset of the current frame from the top of the stack.
! ‘Q’     Use the ‘A’ instruction postfix.
! ‘R’     Inverse of condition code, for unsigned comparisons.
! ‘W’     Subtract 16 from the constant value.
! ‘X’     Use the ‘X’ instruction postfix.
! ‘Y’     Subtract 4 from the constant value.
! ‘Z’     Subtract 1 from the constant value.
! ‘b’     Append ‘.B’, ‘.W’ or ‘.A’ to the instruction, depending on the
          mode.
! ‘d’     Offset 1 byte of a memory reference or constant value.
! ‘e’     Offset 3 bytes of a memory reference or constant value.
! ‘f’     Offset 5 bytes of a memory reference or constant value.
! ‘g’     Offset 7 bytes of a memory reference or constant value.
! ‘p’     Print the value of 2, raised to the power of the given
          constant.  Used to select the specified bit position.
! ‘r’     Inverse of condition code, for signed comparisons.
! ‘x’     Equivialent to ‘X’, but only for pointers.
  
  6.47.2.12 LoongArch Operand Modifiers
  .....................................
*************** LoongArch.
*** 43463,43487 ****
  
  ModifierDescription
  --------------------------------------------------------------------------
! 'd'     Same as 'c'.
! 'i'     Print the character "'i'" if the operand is not a register.
! 'm'     Same as 'c', but the printed value is 'operand - 1'.
! 'X'     Print a constant integer operand in hexadecimal.
! 'z'     Print the operand in its unmodified form, followed by a comma.
  
  
  File: gcc.info,  Node: Constraints,  Next: Asm Labels,  Prev: Extended Asm,  Up: Using Assembly Language with C
  
! 6.47.3 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.
  
--- 43472,43496 ----
  
  ModifierDescription
  --------------------------------------------------------------------------
! ‘d’     Same as ‘c’.
! ‘i’     Print the character "‘i’" if the operand is not a register.
! ‘m’     Same as ‘c’, but the printed value is ‘operand - 1’.
! ‘X’     Print a constant integer operand in hexadecimal.
! ‘z’     Print the operand in its unmodified form, followed by a comma.
  
  
  File: gcc.info,  Node: Constraints,  Next: Asm Labels,  Prev: Extended Asm,  Up: Using Assembly Language with C
  
! 6.47.3 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.
  
*************** whitespace
*** 43509,43523 ****
       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.
--- 43518,43532 ----
       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.
*************** whitespace
*** 43531,43623 ****
       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.
--- 43540,43632 ----
       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.
*************** whitespace
*** 43625,43637 ****
       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:
--- 43634,43646 ----
       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:
*************** whitespace
*** 43644,43662 ****
       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.
  
  
--- 43653,43671 ----
       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.
  
  
*************** alternative.  All operands for a single
*** 43680,43696 ****
  number of alternatives.
  
   So the first alternative for the 68000's logical-or could be written as
! '"+m" (output) : "ir" (input)'.  The second could be '"+r" (output):
! "irm" (input)'.  However, the fact that two memory locations cannot be
! used in a single instruction prevents simply using '"+rm" (output) :
! "irm" (input)'.  Using multi-alternatives, this might be written as
! '"+m,r" (output) : "ir,irm" (input)'.  This describes all the available
  alternatives to the compiler, allowing it to choose the most efficient
  one for the current conditions.
  
   There is no way within the template to determine which alternative was
! chosen.  However you may be able to wrap your 'asm' statements with
! builtins such as '__builtin_constant_p' to achieve the desired results.
  
  
  File: gcc.info,  Node: Modifiers,  Next: Machine Constraints,  Prev: Multi-Alternative,  Up: Constraints
--- 43689,43705 ----
  number of alternatives.
  
   So the first alternative for the 68000's logical-or could be written as
! ‘"+m" (output) : "ir" (input)’.  The second could be ‘"+r" (output):
! "irm" (input)’.  However, the fact that two memory locations cannot be
! used in a single instruction prevents simply using ‘"+rm" (output) :
! "irm" (input)’.  Using multi-alternatives, this might be written as
! ‘"+m,r" (output) : "ir,irm" (input)’.  This describes all the available
  alternatives to the compiler, allowing it to choose the most efficient
  one for the current conditions.
  
   There is no way within the template to determine which alternative was
! chosen.  However you may be able to wrap your ‘asm’ statements with
! builtins such as ‘__builtin_constant_p’ to achieve the desired results.
  
  
  File: gcc.info,  Node: Modifiers,  Next: Machine Constraints,  Prev: Multi-Alternative,  Up: Constraints
*************** File: gcc.info,  Node: Modifiers,  Next:
*** 43700,43732 ****
  
  Here are constraint modifier characters.
  
! '='
       Means that this operand is written to by this instruction: the
       previous value is discarded and replaced by new 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 read by the instruction and
!      which are written by it.  '=' identifies an operand which is only
!      written; '+' identifies an operand that is both read and written;
       all other operands are assumed to only be read.
  
!      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 written before the instruction is
       finished using the input operands.  Therefore, this operand may not
       lie in a register that is read by the instruction 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 operand which is read by the instruction can be tied to an
--- 43709,43741 ----
  
  Here are constraint modifier characters.
  
! ‘=’
       Means that this operand is written to by this instruction: the
       previous value is discarded and replaced by new 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 read by the instruction and
!      which are written by it.  ‘=’ identifies an operand which is only
!      written; ‘+’ identifies an operand that is both read and written;
       all other operands are assumed to only be read.
  
!      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 written before the instruction is
       finished using the input operands.  Therefore, this operand may not
       lie in a register that is read by the instruction 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 operand which is read by the instruction can be tied to an
*************** Here are constraint modifier characters.
*** 43734,43756 ****
       early result is written.  Adding alternatives of this form often
       allows GCC to produce better code when only some of the read
       operands can be affected by the earlyclobber.  See, for example,
!      the 'mulsi3' insn of the ARM.
  
!      Furthermore, if the "earlyclobber" operand is also a read/write
       operand, then that operand is written only after it's used.
  
!      '&' does not obviate the need to write '=' or '+'.  As
!      "earlyclobber" operands are always written, a read-only
!      "earlyclobber" operand is ill-formed and will be rejected by the
       compiler.
  
! '%'
       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.  '%' applies to all alternatives and must
       appear as the first character in the constraint.  Only read-only
!      operands can use '%'.
  
       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
--- 43743,43765 ----
       early result is written.  Adding alternatives of this form often
       allows GCC to produce better code when only some of the read
       operands can be affected by the earlyclobber.  See, for example,
!      the ‘mulsi3’ insn of the ARM.
  
!      Furthermore, if the “earlyclobber” operand is also a read/write
       operand, then that operand is written only after it's used.
  
!      ‘&’ does not obviate the need to write ‘=’ or ‘+’.  As
!      “earlyclobber” operands are always written, a read-only
!      “earlyclobber” operand is ill-formed and will be rejected by the
       compiler.
  
! ‘%’
       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.  ‘%’ applies to all alternatives and must
       appear as the first character in the constraint.  Only read-only
!      operands can use ‘%’.
  
       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
*************** File: gcc.info,  Node: Machine Constrain
*** 43764,45268 ****
  ............................................
  
  Whenever possible, you should use the general-purpose constraint letters
! in 'asm' arguments, since they will convey meaning more readily to
  people reading your code.  Failing that, use the constraint letters that
  usually have very similar meanings across architectures.  The most
! commonly used constraints are 'm' and 'r' (for memory and
  general-purpose registers respectively; *note Simple Constraints::), and
! 'I', usually the letter indicating the most common immediate-constant
  format.
  
   Each architecture defines additional constraints.  These constraints
  are used by the compiler itself for instruction generation, as well as
! for 'asm' statements; therefore, some of the constraints are not
! particularly useful for 'asm'.  Here is a summary of some of the
  machine-dependent constraints available on some particular machines; it
! includes both constraints that are useful for 'asm' and constraints that
  aren't.  The compiler source file mentioned in the table heading for
  each architecture is the definitive reference for the meanings of that
  architecture's constraints.
  
! _AArch64 family--'config/aarch64/constraints.md'_
!      'k'
!           The stack pointer register ('SP')
  
!      'w'
            Floating point register, Advanced SIMD vector register or SVE
            vector register
  
!      'x'
!           Like 'w', but restricted to registers 0 to 15 inclusive.
  
!      'y'
!           Like 'w', but restricted to registers 0 to 7 inclusive.
  
!      'Upl'
!           One of the low eight SVE predicate registers ('P0' to 'P7')
  
!      'Upa'
!           Any of the SVE predicate registers ('P0' to 'P15')
  
!      'I'
            Integer constant that is valid as an immediate operand in an
!           'ADD' instruction
  
!      'J'
            Integer constant that is valid as an immediate operand in a
!           'SUB' instruction (once negated)
  
!      'K'
            Integer constant that can be used with a 32-bit logical
            instruction
  
!      'L'
            Integer constant that can be used with a 64-bit logical
            instruction
  
!      'M'
            Integer constant that is valid as an immediate operand in a
!           32-bit 'MOV' pseudo instruction.  The 'MOV' may be assembled
            to one of several different machine instructions depending on
            the value
  
!      'N'
            Integer constant that is valid as an immediate operand in a
!           64-bit 'MOV' pseudo instruction
  
!      'S'
            An absolute symbolic address or a label reference
  
!      'Y'
            Floating point constant zero
  
!      'Z'
            Integer constant zero
  
!      'Ush'
            The high part (bits 12 and upwards) of the pc-relative address
            of a symbol within 4GB of the instruction
  
!      'Q'
            A memory address which uses a single base register with no
            offset
  
!      'Ump'
            A memory address suitable for a load/store pair instruction in
            SI, DI, SF and DF modes
  
! _AMD GCN --'config/gcn/constraints.md'_
!      'I'
!           Immediate integer in the range -16 to 64
  
!      'J'
            Immediate 16-bit signed integer
  
!      'Kf'
!           Immediate constant -1
  
!      'L'
            Immediate 15-bit unsigned integer
  
!      'A'
            Immediate constant that can be inlined in an instruction
!           encoding: integer -16..64, or float 0.0, +/-0.5, +/-1.0,
!           +/-2.0, +/-4.0, 1.0/(2.0*PI)
  
!      'B'
            Immediate 32-bit signed integer that can be attached to an
            instruction encoding
  
!      'C'
!           Immediate 32-bit integer in range -16..4294967295 (i.e.
!           32-bit unsigned integer or 'A' constraint)
  
!      'DA'
!           Immediate 64-bit constant that can be split into two 'A'
            constants
  
!      'DB'
!           Immediate 64-bit constant that can be split into two 'B'
            constants
  
!      'U'
!           Any 'unspec'
  
!      'Y'
!           Any 'symbol_ref' or 'label_ref'
  
!      'v'
            VGPR register
  
!      'Sg'
            SGPR register
  
!      'SD'
            SGPR registers valid for instruction destinations, including
            VCC, M0 and EXEC
  
!      'SS'
            SGPR registers valid for instruction sources, including VCC,
            M0, EXEC and SCC
  
!      'Sm'
            SGPR registers valid as a source for scalar memory
            instructions (excludes M0 and EXEC)
  
!      'Sv'
            SGPR registers valid as a source or destination for vector
            instructions (excludes EXEC)
  
!      'ca'
            All condition registers: SCC, VCCZ, EXECZ
  
!      'cs'
            Scalar condition register: SCC
  
!      'cV'
            Vector condition register: VCC, VCC_LO, VCC_HI
  
!      'e'
            EXEC register (EXEC_LO and EXEC_HI)
  
!      'RB'
!           Memory operand with address space suitable for 'buffer_*'
            instructions
  
!      'RF'
!           Memory operand with address space suitable for 'flat_*'
            instructions
  
!      'RS'
!           Memory operand with address space suitable for 's_*'
            instructions
  
!      'RL'
!           Memory operand with address space suitable for 'ds_*' LDS
            instructions
  
!      'RG'
!           Memory operand with address space suitable for 'ds_*' GDS
            instructions
  
!      'RD'
!           Memory operand with address space suitable for any 'ds_*'
            instructions
  
!      'RM'
!           Memory operand with address space suitable for 'global_*'
            instructions
  
! _ARC --'config/arc/constraints.md'_
!      'q'
!           Registers usable in ARCompact 16-bit instructions: 'r0'-'r3',
!           'r12'-'r15'.  This constraint can only match when the '-mq'
            option is in effect.
  
!      'e'
            Registers usable as base-regs of memory addresses in ARCompact
!           16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'.
!           This constraint can only match when the '-mq' option is in
            effect.
!      'D'
!           ARC FPX (dpfp) 64-bit registers.  'D0', 'D1'.
  
!      'I'
            A signed 12-bit integer constant.
  
!      'Cal'
            constant for arithmetic/logical operations.  This might be any
            constant that can be put into a long immediate by the assmbler
            or linker without involving a PIC relocation.
  
!      'K'
            A 3-bit unsigned integer constant.
  
!      'L'
            A 6-bit unsigned integer constant.
  
!      'CnL'
            One's complement of a 6-bit unsigned integer constant.
  
!      'CmL'
            Two's complement of a 6-bit unsigned integer constant.
  
!      'M'
            A 5-bit unsigned integer constant.
  
!      'O'
            A 7-bit unsigned integer constant.
  
!      'P'
            A 8-bit unsigned integer constant.
  
!      'H'
            Any const_double value.
  
! _ARM family--'config/arm/constraints.md'_
  
!      'h'
!           In Thumb state, the core registers 'r8'-'r15'.
  
!      'k'
            The stack pointer register.
  
!      'l'
!           In Thumb State the core registers 'r0'-'r7'.  In ARM state
!           this is an alias for the 'r' constraint.
  
!      't'
!           VFP floating-point registers 's0'-'s31'.  Used for 32 bit
            values.
  
!      'w'
!           VFP floating-point registers 'd0'-'d31' and the appropriate
!           subset 'd0'-'d15' based on command line options.  Used for 64
            bit values only.  Not valid for Thumb1.
  
!      'y'
            The iWMMX co-processor registers.
  
!      'z'
            The iWMMX GR registers.
  
!      'G'
            The floating-point constant 0.0
  
!      'I'
            Integer that is valid as an immediate operand in a data
            processing instruction.  That is, an integer in the range 0 to
            255 rotated by a multiple of 2
  
!      'J'
!           Integer in the range -4095 to 4095
  
!      'K'
!           Integer that satisfies constraint 'I' when inverted (ones
            complement)
  
!      'L'
!           Integer that satisfies constraint 'I' when negated (twos
            complement)
  
!      'M'
            Integer in the range 0 to 32
  
!      'Q'
            A memory reference where the exact address is in a single
!           register (''m'' is preferable for 'asm' statements)
  
!      'R'
            An item in the constant pool
  
!      'S'
            A symbol in the text segment of the current file
  
!      'Uv'
            A memory reference suitable for VFP load/store insns
            (reg+constant offset)
  
!      'Uy'
            A memory reference suitable for iWMMXt load/store
            instructions.
  
!      'Uq'
            A memory reference suitable for the ARMv4 ldrsb instruction.
  
! _AVR family--'config/avr/constraints.md'_
!      'l'
            Registers from r0 to r15
  
!      'a'
            Registers from r16 to r23
  
!      'd'
            Registers from r16 to r31
  
!      'w'
            Registers from r24 to r31.  These registers can be used in
!           'adiw' command
  
!      'e'
            Pointer register (r26-r31)
  
!      'b'
            Base pointer register (r28-r31)
  
!      'q'
            Stack pointer register (SPH:SPL)
  
!      't'
            Temporary register r0
  
!      'x'
            Register pair X (r27:r26)
  
!      'y'
            Register pair Y (r29:r28)
  
!      'z'
            Register pair Z (r31:r30)
  
!      'I'
!           Constant greater than -1, less than 64
  
!      'J'
!           Constant greater than -64, less than 1
  
!      'K'
            Constant integer 2
  
!      'L'
            Constant integer 0
  
!      'M'
            Constant that fits in 8 bits
  
!      'N'
!           Constant integer -1
  
!      'O'
            Constant integer 8, 16, or 24
  
!      'P'
            Constant integer 1
  
!      'G'
            A floating point constant 0.0
  
!      'Q'
            A memory address based on Y or Z pointer with displacement.
  
! _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.
  
! _C-SKY--'config/csky/constraints.md'_
  
!      'a'
            The mini registers r0 - r7.
  
!      'b'
            The low registers r0 - r15.
  
!      'c'
            C register.
  
!      'y'
            HI and LO registers.
  
!      'l'
            LO register.
  
!      'h'
            HI register.
  
!      'v'
            Vector registers.
  
!      'z'
            Stack pointer register (SP).
  
!      'Q'
            A memory address which uses a base register with a short
            offset or with a index register with its scale.
  
!      'W'
            A memory address which uses a base register with a index
            register with its scale.
  
! _Epiphany--'config/epiphany/constraints.md'_
!      'U16'
            An unsigned 16-bit constant.
  
!      'K'
            An unsigned 5-bit constant.
  
!      'L'
            A signed 11-bit constant.
  
!      'Cm1'
!           A signed 11-bit constant added to -1.  Can only match when the
!           '-m1reg-REG' option is active.
  
!      'Cl1'
!           Left-shift of -1, i.e., a bit mask with a block of leading
            ones, the rest being a block of trailing zeroes.  Can only
!           match when the '-m1reg-REG' option is active.
  
!      'Cr1'
!           Right-shift of -1, i.e., a bit mask with a trailing block of
            ones, the rest being zeroes.  Or to put it another way, one
            less than a power of two.  Can only match when the
!           '-m1reg-REG' option is active.
  
!      'Cal'
!           Constant for arithmetic/logical operations.  This is like 'i',
            except that for position independent code, no symbols /
            expressions needing relocations are allowed.
  
!      'Csy'
            Symbolic constant for call/jump instruction.
  
!      'Rcs'
            The register class usable in short insns.  This is a register
            class constraint, and can thus drive register allocation.
!           This constraint won't match unless '-mprefer-short-insn-regs'
            is in effect.
  
!      'Rsc'
            The register class of registers that can be used to hold a
            sibcall call address.  I.e., a caller-saved register.
  
!      'Rct'
            Core control register class.
  
!      'Rgs'
            The register group usable in short insns.  This constraint
            does not use a register class, so that it only passively
            matches suitable registers, and doesn't drive register
            allocation.
  
!      'Rra'
            Matches the return address if it can be replaced with the link
            register.
  
!      'Rcc'
            Matches the integer condition code register.
  
!      'Sra'
            Matches the return address if it is in a stack slot.
  
!      'Cfm'
            Matches control register values to switch fp mode, which are
!           encapsulated in 'UNSPEC_FP_MODE'.
  
! _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.
  
! _FT32--'config/ft32/constraints.md'_
!      'A'
            An absolute address
  
!      'B'
            An offset address
  
!      'W'
            A register indirect memory operand
  
!      'e'
            An offset address.
  
!      'f'
            An offset address.
  
!      'O'
            The constant zero or one
  
!      'I'
!           A 16-bit signed constant (-32768 ... 32767)
  
!      'w'
            A bitfield mask suitable for bext or bins
  
!      'x'
            An inverted bitfield mask suitable for bext or bins
  
!      'L'
            A 16-bit unsigned constant, multiple of 4 (0 ... 65532)
  
!      'S'
!           A 20-bit signed constant (-524288 ... 524287)
  
!      'b'
            A constant for a bitfield width (1 ... 16)
  
!      'KA'
!           A 10-bit signed constant (-512 ... 511)
  
! _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
  
! _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 '>'.
  
! _M32C--'config/m32c/m32c.cc'_
!      '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
  
! _LoongArch--'config/loongarch/constraints.md'_
!      'f'
            A floating-point register (if available).
!      'k'
            A memory operand whose address is formed by a base register
            and (optionally scaled) index register.
!      'l'
            A signed 16-bit constant.
!      'm'
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as 'st.w' and 'ld.w'.
!      'I'
            A signed 12-bit constant (for arithmetic instructions).
!      'K'
            An unsigned 12-bit constant (for logic instructions).
!      'ZB'
            An address that is held in a general-purpose register.  The
            offset is zero.
!      'ZC'
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as 'll.w' and 'sc.w'.
  
! _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'
!           A general-purpose register.  This is equivalent to 'r' unless
            generating MIPS16 code, in which case the MIPS16 register set
            is used.
  
!      'f'
            A floating-point register (if available).
  
!      'h'
!           Formerly the 'hi' register.  This constraint is no longer
            supported.
  
!      'l'
!           The 'lo' register.  Use this register to store values that are
            no bigger than a word.
  
!      'x'
!           The concatenated 'hi' and 'lo' registers.  Use this register
            to store doubleword values.
  
!      'c'
            A register suitable for use in an indirect jump.  This will
!           always be '$25' for '-mabicalls'.
  
!      'v'
!           Register '$3'.  Do not use this constraint in new code; it is
            retained only for compatibility with glibc.
  
!      'y'
!           Equivalent to 'r'; retained for backwards compatibility.
  
!      'z'
            A floating-point condition code register.
  
!      'I'
            A signed 16-bit constant (for arithmetic instructions).
  
!      'J'
            Integer zero.
  
!      'K'
            An unsigned 16-bit constant (for logic instructions).
  
!      'L'
            A signed 32-bit constant in which the lower 16 bits are zero.
!           Such constants can be loaded using 'lui'.
  
!      'M'
!           A constant that cannot be loaded using 'lui', 'addiu' or
!           'ori'.
  
!      'N'
!           A constant in the range -65535 to -1 (inclusive).
  
!      'O'
            A signed 15-bit constant.
  
!      'P'
            A constant in the range 1 to 65535 (inclusive).
  
!      'G'
            Floating-point zero.
  
!      'R'
            An address that can be used in a non-macro load or store.
  
!      'ZC'
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as 'll' and 'sc'.
  
!      'ZD'
!           An address suitable for a 'prefetch' instruction, or for any
!           other instruction with the same addressing mode as 'prefetch'.
  
! _Motorola 680x0--'config/m68k/constraints.md'_
!      'a'
            Address register
  
!      'd'
            Data register
  
!      'f'
            68881 floating-point register, if available
  
!      'I'
            Integer in the range 1 to 8
  
!      'J'
            16-bit signed number
  
!      'K'
            Signed number whose magnitude is greater than 0x80
  
!      'L'
!           Integer in the range -8 to -1
  
!      'M'
            Signed number whose magnitude is greater than 0x100
  
!      'N'
            Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate
  
!      'O'
            16 (for rotate using swap)
  
!      'P'
            Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate
  
!      'R'
            Numbers that mov3q can handle
  
!      'G'
            Floating point constant that is not a 68881 constant
  
!      'S'
            Operands that satisfy 'm' when -mpcrel is in effect
  
!      'T'
            Operands that satisfy 's' when -mpcrel is not in effect
  
!      'Q'
            Address register indirect addressing mode
  
!      'U'
            Register offset addressing
  
!      'W'
            const_call_operand
  
!      'Cs'
            symbol_ref or const
  
!      'Ci'
            const_int
  
!      'C0'
            const_int 0
  
!      'Cj'
            Range of signed numbers that don't fit in 16 bits
  
!      'Cmvq'
            Integers valid for mvq
  
!      'Capsw'
            Integers valid for a moveq followed by a swap
  
!      'Cmvz'
            Integers valid for mvz
  
!      'Cmvs'
            Integers valid for mvs
  
!      'Ap'
            push_operand
  
!      'Ac'
            Non-register operands allowed in clr
  
! _Moxie--'config/moxie/constraints.md'_
!      'A'
            An absolute address
  
!      'B'
            An offset address
  
!      'W'
            A register indirect memory operand
  
!      'I'
            A constant in the range of 0 to 255.
  
!      'N'
!           A constant in the range of 0 to -255.
  
! _MSP430-'config/msp430/constraints.md'_
  
!      'R12'
            Register R12.
  
!      'R13'
            Register R13.
  
!      'K'
            Integer constant 1.
  
!      'L'
            Integer constant -1^20..1^19.
  
!      'M'
            Integer constant 1-4.
  
!      'Ya'
            Memory references which do not require an extended MOVX
            instruction.
  
!      'Yl'
            Memory reference, labels only.
  
!      'Ys'
            Memory reference, stack only.
  
! _NDS32--'config/nds32/constraints.md'_
!      'w'
            LOW register class $r0 to $r7 constraint for V3/V3M ISA.
!      'l'
            LOW register class $r0 to $r7.
!      'd'
            MIDDLE register class $r0 to $r11, $r16 to $r19.
!      'h'
            HIGH register class $r12 to $r14, $r20 to $r31.
!      't'
            Temporary assist register $ta (i.e. $r15).
!      'k'
            Stack register $sp.
!      'Iu03'
            Unsigned immediate 3-bit value.
!      'In03'
!           Negative immediate 3-bit value in the range of -7-0.
!      'Iu04'
            Unsigned immediate 4-bit value.
!      'Is05'
            Signed immediate 5-bit value.
!      'Iu05'
            Unsigned immediate 5-bit value.
!      'In05'
!           Negative immediate 5-bit value in the range of -31-0.
!      'Ip05'
            Unsigned immediate 5-bit value for movpi45 instruction with
            range 16-47.
!      'Iu06'
            Unsigned immediate 6-bit value constraint for addri36.sp
            instruction.
!      'Iu08'
            Unsigned immediate 8-bit value.
!      'Iu09'
            Unsigned immediate 9-bit value.
!      'Is10'
            Signed immediate 10-bit value.
!      'Is11'
            Signed immediate 11-bit value.
!      'Is15'
            Signed immediate 15-bit value.
!      'Iu15'
            Unsigned immediate 15-bit value.
!      'Ic15'
            A constant which is not in the range of imm15u but ok for bclr
            instruction.
!      'Ie15'
            A constant which is not in the range of imm15u but ok for bset
            instruction.
!      'It15'
            A constant which is not in the range of imm15u but ok for btgl
            instruction.
!      'Ii15'
            A constant whose compliment value is in the range of imm15u
            and ok for bitci instruction.
!      'Is16'
            Signed immediate 16-bit value.
!      'Is17'
            Signed immediate 17-bit value.
!      'Is19'
            Signed immediate 19-bit value.
!      'Is20'
            Signed immediate 20-bit value.
!      'Ihig'
            The immediate value that can be simply set high 20-bit.
!      'Izeb'
            The immediate value 0xff.
!      'Izeh'
            The immediate value 0xffff.
!      'Ixls'
            The immediate value 0x01.
!      'Ix11'
            The immediate value 0x7ff.
!      'Ibms'
            The immediate value with power of 2.
!      'Ifex'
            The immediate value with power of 2 minus 1.
!      'U33'
            Memory constraint for 333 format.
!      'U45'
            Memory constraint for 45 format.
!      'U37'
            Memory constraint for 37 format.
  
! _Nios II family--'config/nios2/constraints.md'_
  
!      'I'
            Integer that is valid as an immediate operand in an
!           instruction taking a signed 16-bit number.  Range -32768 to
            32767.
  
!      'J'
            Integer that is valid as an immediate operand in an
            instruction taking an unsigned 16-bit number.  Range 0 to
            65535.
  
!      'K'
            Integer that is valid as an immediate operand in an
            instruction taking only the upper 16-bits of a 32-bit number.
            Range 32-bit numbers with the lower 16-bits being 0.
  
!      'L'
            Integer that is valid as an immediate operand for a shift
            instruction.  Range 0 to 31.
  
!      'M'
            Integer that is valid as an immediate operand for only the
            value 0.  Can be used in conjunction with the format modifier
!           'z' to use 'r0' instead of '0' in the assembly output.
  
!      'N'
            Integer that is valid as an immediate operand for a custom
            instruction opcode.  Range 0 to 255.
  
!      'P'
            An immediate operand for R2 andchi/andci instructions.
  
!      'S'
            Matches immediates which are addresses in the small data
!           section and therefore can be added to 'gp' as a 16-bit
            immediate to re-create their 32-bit value.
  
!      'U'
            Matches constants suitable as an operand for the rdprs and
            cache instructions.
  
!      'v'
            A memory operand suitable for Nios II R2 load/store exclusive
            instructions.
  
!      'w'
            A memory operand suitable for load/store IO and cache
            instructions.
  
! _OpenRISC--'config/or1k/constraints.md'_
!      'I'
            Integer that is valid as an immediate operand in an
!           instruction taking a signed 16-bit number.  Range -32768 to
            32767.
  
!      'K'
            Integer that is valid as an immediate operand in an
            instruction taking an unsigned 16-bit number.  Range 0 to
            65535.
  
!      'M'
            Signed 16-bit constant shifted left 16 bits.  (Used with
!           'l.movhi')
  
!      'O'
            Zero
  
! _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.
  
!      'D'
            A memory reference that is encoded within the opcode, but not
            auto-increment or auto-decrement.
  
!      'f'
            Any of the floating point registers (AC0 through AC5).
  
!      'G'
            Floating point constant 0.
  
!      'h'
            Floating point registers AC4 and AC5.  These cannot be loaded
            from/to memory with a single instruction.
  
!      '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 0 through 3; 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.
  
! _PowerPC and IBM RS6000--'config/rs6000/constraints.md'_
!      'r'
!           A general purpose register (GPR), 'r0'...'r31'.
  
!      'b'
!           A base register.  Like 'r', but 'r0' is not allowed, so
!           'r1'...'r31'.
  
!      'f'
!           A floating point register (FPR), 'f0'...'f31'.
  
!      'd'
!           A floating point register.  This is the same as 'f' nowadays;
!           historically 'f' was for single-precision and 'd' was for
            double-precision floating point.
  
!      'v'
!           An Altivec vector register (VR), 'v0'...'v31'.
  
!      'wa'
!           A VSX register (VSR), 'vs0'...'vs63'.  This is either an FPR
!           ('vs0'...'vs31' are 'f0'...'f31') or a VR ('vs32'...'vs63' are
!           'v0'...'v31').
  
!           When using 'wa', you should use the '%x' output modifier, so
            that the correct register number is printed.  For example:
  
                 asm ("xvadddp %x0,%x1,%x2"
                      : "=wa" (v1)
                      : "wa" (v2), "wa" (v3));
  
!           You should not use '%x' for 'v' operands:
  
                 asm ("xsaddqp %0,%1,%2"
                      : "=v" (v1)
                      : "v" (v2), "v" (v3));
  
!      'c'
!           The count register, 'ctr'.
  
!      'l'
!           The link register, 'lr'.
  
!      'x'
!           Condition register field 0, 'cr0'.
  
!      'y'
!           Any condition register field, 'cr0'...'cr7'.
  
!      'I'
            A signed 16-bit constant.
  
!      'J'
!           An unsigned 16-bit constant shifted left 16 bits (use 'L'
!           instead for 'SImode' constants).
  
!      'K'
            An unsigned 16-bit constant.
  
!      'L'
            A signed 16-bit constant shifted left 16 bits.
  
!      'eI'
            A signed 34-bit integer constant if prefixed instructions are
            supported.
  
!      'eP'
            A scalar floating point constant or a vector constant that can
            be loaded to a VSX register with one prefixed instruction.
  
!      'eQ'
            An IEEE 128-bit constant that can be loaded into a VSX
!           register with the 'lxvkq' instruction.
  
!      'm'
!           A memory operand.  Normally, 'm' does not allow addresses that
!           update the base register.  If the '<' 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' as a
            placeholder for the "update" flag in the corresponding load or
            store instruction.  For example:
  
--- 43773,45277 ----
  ............................................
  
  Whenever possible, you should use the general-purpose constraint letters
! in ‘asm’ arguments, since they will convey meaning more readily to
  people reading your code.  Failing that, use the constraint letters that
  usually have very similar meanings across architectures.  The most
! commonly used constraints are ‘m’ and ‘r’ (for memory and
  general-purpose registers respectively; *note Simple Constraints::), and
! ‘I’, usually the letter indicating the most common immediate-constant
  format.
  
   Each architecture defines additional constraints.  These constraints
  are used by the compiler itself for instruction generation, as well as
! for ‘asm’ statements; therefore, some of the constraints are not
! particularly useful for ‘asm’.  Here is a summary of some of the
  machine-dependent constraints available on some particular machines; it
! includes both constraints that are useful for ‘asm’ and constraints that
  aren't.  The compiler source file mentioned in the table heading for
  each architecture is the definitive reference for the meanings of that
  architecture's constraints.
  
! _AArch64 family--‘config/aarch64/constraints.md’_
!      ‘k’
!           The stack pointer register (‘SP’)
  
!      ‘w’
            Floating point register, Advanced SIMD vector register or SVE
            vector register
  
!      ‘x’
!           Like ‘w’, but restricted to registers 0 to 15 inclusive.
  
!      ‘y’
!           Like ‘w’, but restricted to registers 0 to 7 inclusive.
  
!      ‘Upl’
!           One of the low eight SVE predicate registers (‘P0’ to ‘P7’)
  
!      ‘Upa’
!           Any of the SVE predicate registers (‘P0’ to ‘P15’)
  
!      ‘I’
            Integer constant that is valid as an immediate operand in an
!           ‘ADD’ instruction
  
!      ‘J’
            Integer constant that is valid as an immediate operand in a
!           ‘SUB’ instruction (once negated)
  
!      ‘K’
            Integer constant that can be used with a 32-bit logical
            instruction
  
!      ‘L’
            Integer constant that can be used with a 64-bit logical
            instruction
  
!      ‘M’
            Integer constant that is valid as an immediate operand in a
!           32-bit ‘MOV’ pseudo instruction.  The ‘MOV’ may be assembled
            to one of several different machine instructions depending on
            the value
  
!      ‘N’
            Integer constant that is valid as an immediate operand in a
!           64-bit ‘MOV’ pseudo instruction
  
!      ‘S’
            An absolute symbolic address or a label reference
  
!      ‘Y’
            Floating point constant zero
  
!      ‘Z’
            Integer constant zero
  
!      ‘Ush’
            The high part (bits 12 and upwards) of the pc-relative address
            of a symbol within 4GB of the instruction
  
!      ‘Q’
            A memory address which uses a single base register with no
            offset
  
!      ‘Ump’
            A memory address suitable for a load/store pair instruction in
            SI, DI, SF and DF modes
  
! _AMD GCN --‘config/gcn/constraints.md’_
!      ‘I’
!           Immediate integer in the range −16 to 64
  
!      ‘J’
            Immediate 16-bit signed integer
  
!      ‘Kf’
!           Immediate constant −1
  
!      ‘L’
            Immediate 15-bit unsigned integer
  
!      ‘A’
            Immediate constant that can be inlined in an instruction
!           encoding: integer −16..64, or float 0.0, +/−0.5, +/−1.0,
!           +/−2.0, +/−4.0, 1.0/(2.0*PI)
  
!      ‘B’
            Immediate 32-bit signed integer that can be attached to an
            instruction encoding
  
!      ‘C’
!           Immediate 32-bit integer in range −16..4294967295 (i.e.
!           32-bit unsigned integer or ‘A’ constraint)
  
!      ‘DA’
!           Immediate 64-bit constant that can be split into two ‘A’
            constants
  
!      ‘DB’
!           Immediate 64-bit constant that can be split into two ‘B’
            constants
  
!      ‘U’
!           Any ‘unspec’
  
!      ‘Y’
!           Any ‘symbol_ref’ or ‘label_ref’
  
!      ‘v’
            VGPR register
  
!      ‘Sg’
            SGPR register
  
!      ‘SD’
            SGPR registers valid for instruction destinations, including
            VCC, M0 and EXEC
  
!      ‘SS’
            SGPR registers valid for instruction sources, including VCC,
            M0, EXEC and SCC
  
!      ‘Sm’
            SGPR registers valid as a source for scalar memory
            instructions (excludes M0 and EXEC)
  
!      ‘Sv’
            SGPR registers valid as a source or destination for vector
            instructions (excludes EXEC)
  
!      ‘ca’
            All condition registers: SCC, VCCZ, EXECZ
  
!      ‘cs’
            Scalar condition register: SCC
  
!      ‘cV’
            Vector condition register: VCC, VCC_LO, VCC_HI
  
!      ‘e’
            EXEC register (EXEC_LO and EXEC_HI)
  
!      ‘RB’
!           Memory operand with address space suitable for ‘buffer_*’
            instructions
  
!      ‘RF’
!           Memory operand with address space suitable for ‘flat_*’
            instructions
  
!      ‘RS’
!           Memory operand with address space suitable for ‘s_*’
            instructions
  
!      ‘RL’
!           Memory operand with address space suitable for ‘ds_*’ LDS
            instructions
  
!      ‘RG’
!           Memory operand with address space suitable for ‘ds_*’ GDS
            instructions
  
!      ‘RD’
!           Memory operand with address space suitable for any ‘ds_*’
            instructions
  
!      ‘RM’
!           Memory operand with address space suitable for ‘global_*’
            instructions
  
! _ARC --‘config/arc/constraints.md’_
!      ‘q’
!           Registers usable in ARCompact 16-bit instructions: ‘r0’-‘r3’,
!           ‘r12’-‘r15’.  This constraint can only match when the ‘-mq’
            option is in effect.
  
!      ‘e’
            Registers usable as base-regs of memory addresses in ARCompact
!           16-bit memory instructions: ‘r0’-‘r3’, ‘r12’-‘r15’, ‘sp’.
!           This constraint can only match when the ‘-mq’ option is in
            effect.
!      ‘D’
!           ARC FPX (dpfp) 64-bit registers.  ‘D0’, ‘D1’.
  
!      ‘I’
            A signed 12-bit integer constant.
  
!      ‘Cal’
            constant for arithmetic/logical operations.  This might be any
            constant that can be put into a long immediate by the assmbler
            or linker without involving a PIC relocation.
  
!      ‘K’
            A 3-bit unsigned integer constant.
  
!      ‘L’
            A 6-bit unsigned integer constant.
  
!      ‘CnL’
            One's complement of a 6-bit unsigned integer constant.
  
!      ‘CmL’
            Two's complement of a 6-bit unsigned integer constant.
  
!      ‘M’
            A 5-bit unsigned integer constant.
  
!      ‘O’
            A 7-bit unsigned integer constant.
  
!      ‘P’
            A 8-bit unsigned integer constant.
  
!      ‘H’
            Any const_double value.
  
! _ARM family--‘config/arm/constraints.md’_
  
!      ‘h’
!           In Thumb state, the core registers ‘r8’-‘r15’.
  
!      ‘k’
            The stack pointer register.
  
!      ‘l’
!           In Thumb State the core registers ‘r0’-‘r7’.  In ARM state
!           this is an alias for the ‘r’ constraint.
  
!      ‘t’
!           VFP floating-point registers ‘s0’-‘s31’.  Used for 32 bit
            values.
  
!      ‘w’
!           VFP floating-point registers ‘d0’-‘d31’ and the appropriate
!           subset ‘d0’-‘d15’ based on command line options.  Used for 64
            bit values only.  Not valid for Thumb1.
  
!      ‘y’
            The iWMMX co-processor registers.
  
!      ‘z’
            The iWMMX GR registers.
  
!      ‘G’
            The floating-point constant 0.0
  
!      ‘I’
            Integer that is valid as an immediate operand in a data
            processing instruction.  That is, an integer in the range 0 to
            255 rotated by a multiple of 2
  
!      ‘J’
!           Integer in the range −4095 to 4095
  
!      ‘K’
!           Integer that satisfies constraint ‘I’ when inverted (ones
            complement)
  
!      ‘L’
!           Integer that satisfies constraint ‘I’ when negated (twos
            complement)
  
!      ‘M’
            Integer in the range 0 to 32
  
!      ‘Q’
            A memory reference where the exact address is in a single
!           register ('‘m’' is preferable for ‘asm’ statements)
  
!      ‘R’
            An item in the constant pool
  
!      ‘S’
            A symbol in the text segment of the current file
  
!      ‘Uv’
            A memory reference suitable for VFP load/store insns
            (reg+constant offset)
  
!      ‘Uy’
            A memory reference suitable for iWMMXt load/store
            instructions.
  
!      ‘Uq’
            A memory reference suitable for the ARMv4 ldrsb instruction.
  
! _AVR family--‘config/avr/constraints.md’_
!      ‘l’
            Registers from r0 to r15
  
!      ‘a’
            Registers from r16 to r23
  
!      ‘d’
            Registers from r16 to r31
  
!      ‘w’
            Registers from r24 to r31.  These registers can be used in
!           ‘adiw’ command
  
!      ‘e’
            Pointer register (r26-r31)
  
!      ‘b’
            Base pointer register (r28-r31)
  
!      ‘q’
            Stack pointer register (SPH:SPL)
  
!      ‘t’
            Temporary register r0
  
!      ‘x’
            Register pair X (r27:r26)
  
!      ‘y’
            Register pair Y (r29:r28)
  
!      ‘z’
            Register pair Z (r31:r30)
  
!      ‘I’
!           Constant greater than −1, less than 64
  
!      ‘J’
!           Constant greater than −64, less than 1
  
!      ‘K’
            Constant integer 2
  
!      ‘L’
            Constant integer 0
  
!      ‘M’
            Constant that fits in 8 bits
  
!      ‘N’
!           Constant integer −1
  
!      ‘O’
            Constant integer 8, 16, or 24
  
!      ‘P’
            Constant integer 1
  
!      ‘G’
            A floating point constant 0.0
  
!      ‘Q’
            A memory address based on Y or Z pointer with displacement.
  
! _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.
  
! _C-SKY--‘config/csky/constraints.md’_
  
!      ‘a’
            The mini registers r0 - r7.
  
!      ‘b’
            The low registers r0 - r15.
  
!      ‘c’
            C register.
  
!      ‘y’
            HI and LO registers.
  
!      ‘l’
            LO register.
  
!      ‘h’
            HI register.
  
!      ‘v’
            Vector registers.
  
!      ‘z’
            Stack pointer register (SP).
  
!      ‘Q’
            A memory address which uses a base register with a short
            offset or with a index register with its scale.
  
!      ‘W’
            A memory address which uses a base register with a index
            register with its scale.
  
! _Epiphany--‘config/epiphany/constraints.md’_
!      ‘U16’
            An unsigned 16-bit constant.
  
!      ‘K’
            An unsigned 5-bit constant.
  
!      ‘L’
            A signed 11-bit constant.
  
!      ‘Cm1’
!           A signed 11-bit constant added to −1.  Can only match when the
!           ‘-m1reg-REG’ option is active.
  
!      ‘Cl1’
!           Left-shift of −1, i.e., a bit mask with a block of leading
            ones, the rest being a block of trailing zeroes.  Can only
!           match when the ‘-m1reg-REG’ option is active.
  
!      ‘Cr1’
!           Right-shift of −1, i.e., a bit mask with a trailing block of
            ones, the rest being zeroes.  Or to put it another way, one
            less than a power of two.  Can only match when the
!           ‘-m1reg-REG’ option is active.
  
!      ‘Cal’
!           Constant for arithmetic/logical operations.  This is like ‘i’,
            except that for position independent code, no symbols /
            expressions needing relocations are allowed.
  
!      ‘Csy’
            Symbolic constant for call/jump instruction.
  
!      ‘Rcs’
            The register class usable in short insns.  This is a register
            class constraint, and can thus drive register allocation.
!           This constraint won't match unless ‘-mprefer-short-insn-regs’
            is in effect.
  
!      ‘Rsc’
            The register class of registers that can be used to hold a
            sibcall call address.  I.e., a caller-saved register.
  
!      ‘Rct’
            Core control register class.
  
!      ‘Rgs’
            The register group usable in short insns.  This constraint
            does not use a register class, so that it only passively
            matches suitable registers, and doesn't drive register
            allocation.
  
!      ‘Rra’
            Matches the return address if it can be replaced with the link
            register.
  
!      ‘Rcc’
            Matches the integer condition code register.
  
!      ‘Sra’
            Matches the return address if it is in a stack slot.
  
!      ‘Cfm’
            Matches control register values to switch fp mode, which are
!           encapsulated in ‘UNSPEC_FP_MODE’.
  
! _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.
  
! _FT32--‘config/ft32/constraints.md’_
!      ‘A’
            An absolute address
  
!      ‘B’
            An offset address
  
!      ‘W’
            A register indirect memory operand
  
!      ‘e’
            An offset address.
  
!      ‘f’
            An offset address.
  
!      ‘O’
            The constant zero or one
  
!      ‘I’
!           A 16-bit signed constant (−32768 ... 32767)
  
!      ‘w’
            A bitfield mask suitable for bext or bins
  
!      ‘x’
            An inverted bitfield mask suitable for bext or bins
  
!      ‘L’
            A 16-bit unsigned constant, multiple of 4 (0 ... 65532)
  
!      ‘S’
!           A 20-bit signed constant (−524288 ... 524287)
  
!      ‘b’
            A constant for a bitfield width (1 ... 16)
  
!      ‘KA’
!           A 10-bit signed constant (−512 ... 511)
  
! _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
  
! _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 ‘>’.
  
! _M32C--‘config/m32c/m32c.cc’_
!      ‘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
  
! _LoongArch--‘config/loongarch/constraints.md’_
!      ‘f’
            A floating-point register (if available).
!      ‘k’
            A memory operand whose address is formed by a base register
            and (optionally scaled) index register.
!      ‘l’
            A signed 16-bit constant.
!      ‘m’
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as ‘st.w’ and ‘ld.w’.
!      ‘I’
            A signed 12-bit constant (for arithmetic instructions).
!      ‘K’
            An unsigned 12-bit constant (for logic instructions).
!      ‘ZB’
            An address that is held in a general-purpose register.  The
            offset is zero.
!      ‘ZC’
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as ‘ll.w’ and ‘sc.w’.
  
! _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’
!           A general-purpose register.  This is equivalent to ‘r’ unless
            generating MIPS16 code, in which case the MIPS16 register set
            is used.
  
!      ‘f’
            A floating-point register (if available).
  
!      ‘h’
!           Formerly the ‘hi’ register.  This constraint is no longer
            supported.
  
!      ‘l’
!           The ‘lo’ register.  Use this register to store values that are
            no bigger than a word.
  
!      ‘x’
!           The concatenated ‘hi’ and ‘lo’ registers.  Use this register
            to store doubleword values.
  
!      ‘c’
            A register suitable for use in an indirect jump.  This will
!           always be ‘$25’ for ‘-mabicalls’.
  
!      ‘v’
!           Register ‘$3’.  Do not use this constraint in new code; it is
            retained only for compatibility with glibc.
  
!      ‘y’
!           Equivalent to ‘r’; retained for backwards compatibility.
  
!      ‘z’
            A floating-point condition code register.
  
!      ‘I’
            A signed 16-bit constant (for arithmetic instructions).
  
!      ‘J’
            Integer zero.
  
!      ‘K’
            An unsigned 16-bit constant (for logic instructions).
  
!      ‘L’
            A signed 32-bit constant in which the lower 16 bits are zero.
!           Such constants can be loaded using ‘lui’.
  
!      ‘M’
!           A constant that cannot be loaded using ‘lui’, ‘addiu’ or
!           ‘ori’.
  
!      ‘N’
!           A constant in the range −65535 to −1 (inclusive).
  
!      ‘O’
            A signed 15-bit constant.
  
!      ‘P’
            A constant in the range 1 to 65535 (inclusive).
  
!      ‘G’
            Floating-point zero.
  
!      ‘R’
            An address that can be used in a non-macro load or store.
  
!      ‘ZC’
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as ‘ll’ and ‘sc’.
  
!      ‘ZD’
!           An address suitable for a ‘prefetch’ instruction, or for any
!           other instruction with the same addressing mode as ‘prefetch’.
  
! _Motorola 680x0--‘config/m68k/constraints.md’_
!      ‘a’
            Address register
  
!      ‘d’
            Data register
  
!      ‘f’
            68881 floating-point register, if available
  
!      ‘I’
            Integer in the range 1 to 8
  
!      ‘J’
            16-bit signed number
  
!      ‘K’
            Signed number whose magnitude is greater than 0x80
  
!      ‘L’
!           Integer in the range −8 to −1
  
!      ‘M’
            Signed number whose magnitude is greater than 0x100
  
!      ‘N’
            Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate
  
!      ‘O’
            16 (for rotate using swap)
  
!      ‘P’
            Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate
  
!      ‘R’
            Numbers that mov3q can handle
  
!      ‘G’
            Floating point constant that is not a 68881 constant
  
!      ‘S’
            Operands that satisfy 'm' when -mpcrel is in effect
  
!      ‘T’
            Operands that satisfy 's' when -mpcrel is not in effect
  
!      ‘Q’
            Address register indirect addressing mode
  
!      ‘U’
            Register offset addressing
  
!      ‘W’
            const_call_operand
  
!      ‘Cs’
            symbol_ref or const
  
!      ‘Ci’
            const_int
  
!      ‘C0’
            const_int 0
  
!      ‘Cj’
            Range of signed numbers that don't fit in 16 bits
  
!      ‘Cmvq’
            Integers valid for mvq
  
!      ‘Capsw’
            Integers valid for a moveq followed by a swap
  
!      ‘Cmvz’
            Integers valid for mvz
  
!      ‘Cmvs’
            Integers valid for mvs
  
!      ‘Ap’
            push_operand
  
!      ‘Ac’
            Non-register operands allowed in clr
  
! _Moxie--‘config/moxie/constraints.md’_
!      ‘A’
            An absolute address
  
!      ‘B’
            An offset address
  
!      ‘W’
            A register indirect memory operand
  
!      ‘I’
            A constant in the range of 0 to 255.
  
!      ‘N’
!           A constant in the range of 0 to −255.
  
! _MSP430-‘config/msp430/constraints.md’_
  
!      ‘R12’
            Register R12.
  
!      ‘R13’
            Register R13.
  
!      ‘K’
            Integer constant 1.
  
!      ‘L’
            Integer constant -1^20..1^19.
  
!      ‘M’
            Integer constant 1-4.
  
!      ‘Ya’
            Memory references which do not require an extended MOVX
            instruction.
  
!      ‘Yl’
            Memory reference, labels only.
  
!      ‘Ys’
            Memory reference, stack only.
  
! _NDS32--‘config/nds32/constraints.md’_
!      ‘w’
            LOW register class $r0 to $r7 constraint for V3/V3M ISA.
!      ‘l’
            LOW register class $r0 to $r7.
!      ‘d’
            MIDDLE register class $r0 to $r11, $r16 to $r19.
!      ‘h’
            HIGH register class $r12 to $r14, $r20 to $r31.
!      ‘t’
            Temporary assist register $ta (i.e. $r15).
!      ‘k’
            Stack register $sp.
!      ‘Iu03’
            Unsigned immediate 3-bit value.
!      ‘In03’
!           Negative immediate 3-bit value in the range of −7-0.
!      ‘Iu04’
            Unsigned immediate 4-bit value.
!      ‘Is05’
            Signed immediate 5-bit value.
!      ‘Iu05’
            Unsigned immediate 5-bit value.
!      ‘In05’
!           Negative immediate 5-bit value in the range of −31-0.
!      ‘Ip05’
            Unsigned immediate 5-bit value for movpi45 instruction with
            range 16-47.
!      ‘Iu06’
            Unsigned immediate 6-bit value constraint for addri36.sp
            instruction.
!      ‘Iu08’
            Unsigned immediate 8-bit value.
!      ‘Iu09’
            Unsigned immediate 9-bit value.
!      ‘Is10’
            Signed immediate 10-bit value.
!      ‘Is11’
            Signed immediate 11-bit value.
!      ‘Is15’
            Signed immediate 15-bit value.
!      ‘Iu15’
            Unsigned immediate 15-bit value.
!      ‘Ic15’
            A constant which is not in the range of imm15u but ok for bclr
            instruction.
!      ‘Ie15’
            A constant which is not in the range of imm15u but ok for bset
            instruction.
!      ‘It15’
            A constant which is not in the range of imm15u but ok for btgl
            instruction.
!      ‘Ii15’
            A constant whose compliment value is in the range of imm15u
            and ok for bitci instruction.
!      ‘Is16’
            Signed immediate 16-bit value.
!      ‘Is17’
            Signed immediate 17-bit value.
!      ‘Is19’
            Signed immediate 19-bit value.
!      ‘Is20’
            Signed immediate 20-bit value.
!      ‘Ihig’
            The immediate value that can be simply set high 20-bit.
!      ‘Izeb’
            The immediate value 0xff.
!      ‘Izeh’
            The immediate value 0xffff.
!      ‘Ixls’
            The immediate value 0x01.
!      ‘Ix11’
            The immediate value 0x7ff.
!      ‘Ibms’
            The immediate value with power of 2.
!      ‘Ifex’
            The immediate value with power of 2 minus 1.
!      ‘U33’
            Memory constraint for 333 format.
!      ‘U45’
            Memory constraint for 45 format.
!      ‘U37’
            Memory constraint for 37 format.
  
! _Nios II family--‘config/nios2/constraints.md’_
  
!      ‘I’
            Integer that is valid as an immediate operand in an
!           instruction taking a signed 16-bit number.  Range −32768 to
            32767.
  
!      ‘J’
            Integer that is valid as an immediate operand in an
            instruction taking an unsigned 16-bit number.  Range 0 to
            65535.
  
!      ‘K’
            Integer that is valid as an immediate operand in an
            instruction taking only the upper 16-bits of a 32-bit number.
            Range 32-bit numbers with the lower 16-bits being 0.
  
!      ‘L’
            Integer that is valid as an immediate operand for a shift
            instruction.  Range 0 to 31.
  
!      ‘M’
            Integer that is valid as an immediate operand for only the
            value 0.  Can be used in conjunction with the format modifier
!           ‘z’ to use ‘r0’ instead of ‘0’ in the assembly output.
  
!      ‘N’
            Integer that is valid as an immediate operand for a custom
            instruction opcode.  Range 0 to 255.
  
!      ‘P’
            An immediate operand for R2 andchi/andci instructions.
  
!      ‘S’
            Matches immediates which are addresses in the small data
!           section and therefore can be added to ‘gp’ as a 16-bit
            immediate to re-create their 32-bit value.
  
!      ‘U’
            Matches constants suitable as an operand for the rdprs and
            cache instructions.
  
!      ‘v’
            A memory operand suitable for Nios II R2 load/store exclusive
            instructions.
  
!      ‘w’
            A memory operand suitable for load/store IO and cache
            instructions.
  
! _OpenRISC--‘config/or1k/constraints.md’_
!      ‘I’
            Integer that is valid as an immediate operand in an
!           instruction taking a signed 16-bit number.  Range −32768 to
            32767.
  
!      ‘K’
            Integer that is valid as an immediate operand in an
            instruction taking an unsigned 16-bit number.  Range 0 to
            65535.
  
!      ‘M’
            Signed 16-bit constant shifted left 16 bits.  (Used with
!           ‘l.movhi’)
  
!      ‘O’
            Zero
  
! _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.
  
!      ‘D’
            A memory reference that is encoded within the opcode, but not
            auto-increment or auto-decrement.
  
!      ‘f’
            Any of the floating point registers (AC0 through AC5).
  
!      ‘G’
            Floating point constant 0.
  
!      ‘h’
            Floating point registers AC4 and AC5.  These cannot be loaded
            from/to memory with a single instruction.
  
!      ‘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 0 through 3; 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.
  
! _PowerPC and IBM RS6000--‘config/rs6000/constraints.md’_
!      ‘r’
!           A general purpose register (GPR), ‘r0’...‘r31’.
  
!      ‘b’
!           A base register.  Like ‘r’, but ‘r0’ is not allowed, so
!           ‘r1’...‘r31’.
  
!      ‘f’
!           A floating point register (FPR), ‘f0’...‘f31’.
  
!      ‘d’
!           A floating point register.  This is the same as ‘f’ nowadays;
!           historically ‘f’ was for single-precision and ‘d’ was for
            double-precision floating point.
  
!      ‘v’
!           An Altivec vector register (VR), ‘v0’...‘v31’.
  
!      ‘wa’
!           A VSX register (VSR), ‘vs0’...‘vs63’.  This is either an FPR
!           (‘vs0’...‘vs31’ are ‘f0’...‘f31’) or a VR (‘vs32’...‘vs63’ are
!           ‘v0’...‘v31’).
  
!           When using ‘wa’, you should use the ‘%x’ output modifier, so
            that the correct register number is printed.  For example:
  
                 asm ("xvadddp %x0,%x1,%x2"
                      : "=wa" (v1)
                      : "wa" (v2), "wa" (v3));
  
!           You should not use ‘%x’ for ‘v’ operands:
  
                 asm ("xsaddqp %0,%1,%2"
                      : "=v" (v1)
                      : "v" (v2), "v" (v3));
  
!      ‘c’
!           The count register, ‘ctr’.
  
!      ‘l’
!           The link register, ‘lr’.
  
!      ‘x’
!           Condition register field 0, ‘cr0’.
  
!      ‘y’
!           Any condition register field, ‘cr0’...‘cr7’.
  
!      ‘I’
            A signed 16-bit constant.
  
!      ‘J’
!           An unsigned 16-bit constant shifted left 16 bits (use ‘L’
!           instead for ‘SImode’ constants).
  
!      ‘K’
            An unsigned 16-bit constant.
  
!      ‘L’
            A signed 16-bit constant shifted left 16 bits.
  
!      ‘eI’
            A signed 34-bit integer constant if prefixed instructions are
            supported.
  
!      ‘eP’
            A scalar floating point constant or a vector constant that can
            be loaded to a VSX register with one prefixed instruction.
  
!      ‘eQ’
            An IEEE 128-bit constant that can be loaded into a VSX
!           register with the ‘lxvkq’ instruction.
  
!      ‘m’
!           A memory operand.  Normally, ‘m’ does not allow addresses that
!           update the base register.  If the ‘<’ 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’ as a
            placeholder for the "update" flag in the corresponding load or
            store instruction.  For example:
  
*************** _PowerPC and IBM RS6000--'config/rs6000/
*** 45274,45763 ****
  
            is not.
  
!      'Q'
            A memory operand addressed by just a base register.
  
!      'Z'
            A memory operand accessed with indexed or indirect addressing.
  
!      'a'
            An indexed or indirect address.
  
! _PRU--'config/pru/constraints.md'_
!      'I'
            An unsigned 8-bit integer constant.
  
!      'J'
            An unsigned 16-bit integer constant.
  
!      'L'
            An unsigned 5-bit integer constant (for shift counts).
  
!      'T'
            A text segment (program memory) constant label.
  
!      'Z'
            Integer constant zero.
  
! _RL78--'config/rl78/constraints.md'_
  
!      'Int3'
            An integer constant in the range 1 ... 7.
!      'Int8'
            An integer constant in the range 0 ... 255.
!      'J'
!           An integer constant in the range -255 ... 0
!      'K'
            The integer constant 1.
!      'L'
            The integer constant -1.
!      'M'
            The integer constant 0.
!      'N'
            The integer constant 2.
!      'O'
            The integer constant -2.
!      'P'
            An integer constant in the range 1 ... 15.
!      'Qbi'
            The built-in compare types-eq, ne, gtu, ltu, geu, and leu.
!      'Qsc'
            The synthetic compare types-gt, lt, ge, and le.
!      'Wab'
            A memory reference with an absolute address.
!      'Wbc'
!           A memory reference using 'BC' as a base register, with an
            optional offset.
!      'Wca'
!           A memory reference using 'AX', 'BC', 'DE', or 'HL' for the
            address, for calls.
!      'Wcv'
            A memory reference using any 16-bit register pair for the
            address, for calls.
!      'Wd2'
!           A memory reference using 'DE' as a base register, with an
            optional offset.
!      'Wde'
!           A memory reference using 'DE' as a base register, without any
            offset.
!      'Wfr'
            Any memory reference to an address in the far address space.
!      'Wh1'
!           A memory reference using 'HL' as a base register, with an
            optional one-byte offset.
!      'Whb'
!           A memory reference using 'HL' as a base register, with 'B' or
!           'C' as the index register.
!      'Whl'
!           A memory reference using 'HL' as a base register, without any
            offset.
!      'Ws1'
!           A memory reference using 'SP' as a base register, with an
            optional one-byte offset.
!      'Y'
            Any memory reference to an address in the near address space.
!      'A'
!           The 'AX' register.
!      'B'
!           The 'BC' register.
!      'D'
!           The 'DE' register.
!      'R'
!           'A' through 'L' registers.
!      'S'
!           The 'SP' register.
!      'T'
!           The 'HL' register.
!      'Z08W'
!           The 16-bit 'R8' register.
!      'Z10W'
!           The 16-bit 'R10' register.
!      'Zint'
!           The registers reserved for interrupts ('R24' to 'R31').
!      'a'
!           The 'A' register.
!      'b'
!           The 'B' register.
!      'c'
!           The 'C' register.
!      'd'
!           The 'D' register.
!      'e'
!           The 'E' register.
!      'h'
!           The 'H' register.
!      'l'
!           The 'L' register.
!      'v'
            The virtual registers.
!      'w'
!           The 'PSW' register.
!      'x'
!           The 'X' register.
  
! _RISC-V--'config/riscv/constraints.md'_
  
!      'f'
            A floating-point register (if available).
  
!      'I'
            An I-type 12-bit signed immediate.
  
!      'J'
            Integer zero.
  
!      'K'
            A 5-bit unsigned immediate for CSR access instructions.
  
!      'A'
            An address that is held in a general-purpose register.
  
!      'S'
            A constraint that matches an absolute symbolic address.
  
!      'vr'
            A vector register (if available)..
  
!      'vd'
            A vector register, excluding v0 (if available).
  
!      'vm'
            A vector register, only v0 (if available).
  
! _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.
  
! _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.
  
! _SPARC--'config/sparc/sparc.h'_
!      'f'
            Floating-point register on the SPARC-V8 architecture and lower
            floating-point register on the SPARC-V9 architecture.
  
!      'e'
!           Floating-point register.  It is equivalent to 'f' on the
            SPARC-V8 architecture and contains both lower and upper
            floating-point registers on the SPARC-V9 architecture.
  
!      'c'
            Floating-point condition code register.
  
!      'd'
            Lower floating-point register.  It is only valid on the
            SPARC-V9 architecture when the Visual Instruction Set is
            available.
  
!      'b'
            Floating-point register.  It is only valid on the SPARC-V9
            architecture when the Visual Instruction Set is available.
  
!      'h'
            64-bit global or out register for the SPARC-V8+ architecture.
  
!      'C'
            The constant all-ones, for floating-point.
  
!      'A'
            Signed 5-bit constant
  
!      'D'
            A vector constant
  
!      'I'
            Signed 13-bit constant
  
!      'J'
            Zero
  
!      'K'
            32-bit constant with the low 12 bits clear (a constant that
!           can be loaded with the 'sethi' instruction)
  
!      'L'
!           A constant in the range supported by 'movcc' instructions
            (11-bit signed immediate)
  
!      'M'
!           A constant in the range supported by 'movrcc' instructions
            (10-bit signed immediate)
  
!      'N'
!           Same as 'K', except that it verifies that bits that are not in
            the lower 32-bit range are all zero.  Must be used instead of
!           'K' for modes wider than 'SImode'
  
!      'O'
            The constant 4096
  
!      'G'
            Floating-point zero
  
!      'H'
            Signed 13-bit constant, sign-extended to 32 or 64 bits
  
!      'P'
            The constant -1
  
!      'Q'
            Floating-point constant whose integral representation can be
            moved into an integer register using a single sethi
            instruction
  
!      'R'
            Floating-point constant whose integral representation can be
            moved into an integer register using a single mov instruction
  
!      'S'
            Floating-point constant whose integral representation can be
            moved into an integer register using a high/lo_sum instruction
            sequence
  
!      'T'
            Memory address aligned to an 8-byte boundary
  
!      'U'
            Even register
  
!      'W'
!           Memory address for 'e' constraint registers
  
!      'w'
            Memory address with only a base register
  
!      'Y'
            Vector zero
  
! _TI C6X family--'config/c6x/constraints.md'_
!      'a'
            Register file A (A0-A31).
  
!      'b'
            Register file B (B0-B31).
  
!      'A'
            Predicate registers in register file A (A0-A2 on C64X and
            higher, A1 and A2 otherwise).
  
!      'B'
            Predicate registers in register file B (B0-B2).
  
!      'C'
            A call-used register in register file B (B0-B9, B16-B31).
  
!      'Da'
            Register file A, excluding predicate registers (A3-A31, plus
            A0 if not C64X or higher).
  
!      'Db'
            Register file B, excluding predicate registers (B3-B31).
  
!      'Iu4'
            Integer constant in the range 0 ... 15.
  
!      'Iu5'
            Integer constant in the range 0 ... 31.
  
!      'In5'
!           Integer constant in the range -31 ... 0.
  
!      'Is5'
!           Integer constant in the range -16 ... 15.
  
!      'I5x'
            Integer constant that can be the operand of an ADDA or a SUBA
            insn.
  
!      'IuB'
            Integer constant in the range 0 ... 65535.
  
!      'IsB'
!           Integer constant in the range -32768 ... 32767.
  
!      'IsC'
            Integer constant in the range -2^{20} ... 2^{20} - 1.
  
!      'Jc'
            Integer constant that is a valid mask for the clr instruction.
  
!      'Js'
            Integer constant that is a valid mask for the set instruction.
  
!      'Q'
            Memory location with A base register.
  
!      'R'
            Memory location with B base register.
  
!      'Z'
            Register B14 (aka DP).
  
! _Visium--'config/visium/constraints.md'_
!      'b'
!           EAM register 'mdb'
  
!      'c'
!           EAM register 'mdc'
  
!      'f'
            Floating point register
  
!      'l'
!           General register, but not 'r29', 'r30' and 'r31'
  
!      't'
!           Register 'r1'
  
!      'u'
!           Register 'r2'
  
!      'v'
!           Register 'r3'
  
!      'G'
            Floating-point constant 0.0
  
!      'J'
            Integer constant in the range 0 ..  65535 (16-bit immediate)
  
!      'K'
            Integer constant in the range 1 ..  31 (5-bit immediate)
  
!      'L'
!           Integer constant in the range -65535 ..  -1 (16-bit negative
            immediate)
  
!      'M'
!           Integer constant -1
  
!      'O'
            Integer constant 0
  
!      'P'
            Integer constant 32
  
! _x86 family--'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)
                 {
--- 45283,45772 ----
  
            is not.
  
!      ‘Q’
            A memory operand addressed by just a base register.
  
!      ‘Z’
            A memory operand accessed with indexed or indirect addressing.
  
!      ‘a’
            An indexed or indirect address.
  
! _PRU--‘config/pru/constraints.md’_
!      ‘I’
            An unsigned 8-bit integer constant.
  
!      ‘J’
            An unsigned 16-bit integer constant.
  
!      ‘L’
            An unsigned 5-bit integer constant (for shift counts).
  
!      ‘T’
            A text segment (program memory) constant label.
  
!      ‘Z’
            Integer constant zero.
  
! _RL78--‘config/rl78/constraints.md’_
  
!      ‘Int3’
            An integer constant in the range 1 ... 7.
!      ‘Int8’
            An integer constant in the range 0 ... 255.
!      ‘J’
!           An integer constant in the range −255 ... 0
!      ‘K’
            The integer constant 1.
!      ‘L’
            The integer constant -1.
!      ‘M’
            The integer constant 0.
!      ‘N’
            The integer constant 2.
!      ‘O’
            The integer constant -2.
!      ‘P’
            An integer constant in the range 1 ... 15.
!      ‘Qbi’
            The built-in compare types-eq, ne, gtu, ltu, geu, and leu.
!      ‘Qsc’
            The synthetic compare types-gt, lt, ge, and le.
!      ‘Wab’
            A memory reference with an absolute address.
!      ‘Wbc’
!           A memory reference using ‘BC’ as a base register, with an
            optional offset.
!      ‘Wca’
!           A memory reference using ‘AX’, ‘BC’, ‘DE’, or ‘HL’ for the
            address, for calls.
!      ‘Wcv’
            A memory reference using any 16-bit register pair for the
            address, for calls.
!      ‘Wd2’
!           A memory reference using ‘DE’ as a base register, with an
            optional offset.
!      ‘Wde’
!           A memory reference using ‘DE’ as a base register, without any
            offset.
!      ‘Wfr’
            Any memory reference to an address in the far address space.
!      ‘Wh1’
!           A memory reference using ‘HL’ as a base register, with an
            optional one-byte offset.
!      ‘Whb’
!           A memory reference using ‘HL’ as a base register, with ‘B’ or
!           ‘C’ as the index register.
!      ‘Whl’
!           A memory reference using ‘HL’ as a base register, without any
            offset.
!      ‘Ws1’
!           A memory reference using ‘SP’ as a base register, with an
            optional one-byte offset.
!      ‘Y’
            Any memory reference to an address in the near address space.
!      ‘A’
!           The ‘AX’ register.
!      ‘B’
!           The ‘BC’ register.
!      ‘D’
!           The ‘DE’ register.
!      ‘R’
!           ‘A’ through ‘L’ registers.
!      ‘S’
!           The ‘SP’ register.
!      ‘T’
!           The ‘HL’ register.
!      ‘Z08W’
!           The 16-bit ‘R8’ register.
!      ‘Z10W’
!           The 16-bit ‘R10’ register.
!      ‘Zint’
!           The registers reserved for interrupts (‘R24’ to ‘R31’).
!      ‘a’
!           The ‘A’ register.
!      ‘b’
!           The ‘B’ register.
!      ‘c’
!           The ‘C’ register.
!      ‘d’
!           The ‘D’ register.
!      ‘e’
!           The ‘E’ register.
!      ‘h’
!           The ‘H’ register.
!      ‘l’
!           The ‘L’ register.
!      ‘v’
            The virtual registers.
!      ‘w’
!           The ‘PSW’ register.
!      ‘x’
!           The ‘X’ register.
  
! _RISC-V--‘config/riscv/constraints.md’_
  
!      ‘f’
            A floating-point register (if available).
  
!      ‘I’
            An I-type 12-bit signed immediate.
  
!      ‘J’
            Integer zero.
  
!      ‘K’
            A 5-bit unsigned immediate for CSR access instructions.
  
!      ‘A’
            An address that is held in a general-purpose register.
  
!      ‘S’
            A constraint that matches an absolute symbolic address.
  
!      ‘vr’
            A vector register (if available)..
  
!      ‘vd’
            A vector register, excluding v0 (if available).
  
!      ‘vm’
            A vector register, only v0 (if available).
  
! _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.
  
! _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.
  
! _SPARC--‘config/sparc/sparc.h’_
!      ‘f’
            Floating-point register on the SPARC-V8 architecture and lower
            floating-point register on the SPARC-V9 architecture.
  
!      ‘e’
!           Floating-point register.  It is equivalent to ‘f’ on the
            SPARC-V8 architecture and contains both lower and upper
            floating-point registers on the SPARC-V9 architecture.
  
!      ‘c’
            Floating-point condition code register.
  
!      ‘d’
            Lower floating-point register.  It is only valid on the
            SPARC-V9 architecture when the Visual Instruction Set is
            available.
  
!      ‘b’
            Floating-point register.  It is only valid on the SPARC-V9
            architecture when the Visual Instruction Set is available.
  
!      ‘h’
            64-bit global or out register for the SPARC-V8+ architecture.
  
!      ‘C’
            The constant all-ones, for floating-point.
  
!      ‘A’
            Signed 5-bit constant
  
!      ‘D’
            A vector constant
  
!      ‘I’
            Signed 13-bit constant
  
!      ‘J’
            Zero
  
!      ‘K’
            32-bit constant with the low 12 bits clear (a constant that
!           can be loaded with the ‘sethi’ instruction)
  
!      ‘L’
!           A constant in the range supported by ‘movcc’ instructions
            (11-bit signed immediate)
  
!      ‘M’
!           A constant in the range supported by ‘movrcc’ instructions
            (10-bit signed immediate)
  
!      ‘N’
!           Same as ‘K’, except that it verifies that bits that are not in
            the lower 32-bit range are all zero.  Must be used instead of
!           ‘K’ for modes wider than ‘SImode’
  
!      ‘O’
            The constant 4096
  
!      ‘G’
            Floating-point zero
  
!      ‘H’
            Signed 13-bit constant, sign-extended to 32 or 64 bits
  
!      ‘P’
            The constant -1
  
!      ‘Q’
            Floating-point constant whose integral representation can be
            moved into an integer register using a single sethi
            instruction
  
!      ‘R’
            Floating-point constant whose integral representation can be
            moved into an integer register using a single mov instruction
  
!      ‘S’
            Floating-point constant whose integral representation can be
            moved into an integer register using a high/lo_sum instruction
            sequence
  
!      ‘T’
            Memory address aligned to an 8-byte boundary
  
!      ‘U’
            Even register
  
!      ‘W’
!           Memory address for ‘e’ constraint registers
  
!      ‘w’
            Memory address with only a base register
  
!      ‘Y’
            Vector zero
  
! _TI C6X family--‘config/c6x/constraints.md’_
!      ‘a’
            Register file A (A0-A31).
  
!      ‘b’
            Register file B (B0-B31).
  
!      ‘A’
            Predicate registers in register file A (A0-A2 on C64X and
            higher, A1 and A2 otherwise).
  
!      ‘B’
            Predicate registers in register file B (B0-B2).
  
!      ‘C’
            A call-used register in register file B (B0-B9, B16-B31).
  
!      ‘Da’
            Register file A, excluding predicate registers (A3-A31, plus
            A0 if not C64X or higher).
  
!      ‘Db’
            Register file B, excluding predicate registers (B3-B31).
  
!      ‘Iu4’
            Integer constant in the range 0 ... 15.
  
!      ‘Iu5’
            Integer constant in the range 0 ... 31.
  
!      ‘In5’
!           Integer constant in the range −31 ... 0.
  
!      ‘Is5’
!           Integer constant in the range −16 ... 15.
  
!      ‘I5x’
            Integer constant that can be the operand of an ADDA or a SUBA
            insn.
  
!      ‘IuB’
            Integer constant in the range 0 ... 65535.
  
!      ‘IsB’
!           Integer constant in the range −32768 ... 32767.
  
!      ‘IsC’
            Integer constant in the range -2^{20} ... 2^{20} - 1.
  
!      ‘Jc’
            Integer constant that is a valid mask for the clr instruction.
  
!      ‘Js’
            Integer constant that is a valid mask for the set instruction.
  
!      ‘Q’
            Memory location with A base register.
  
!      ‘R’
            Memory location with B base register.
  
!      ‘Z’
            Register B14 (aka DP).
  
! _Visium--‘config/visium/constraints.md’_
!      ‘b’
!           EAM register ‘mdb’
  
!      ‘c’
!           EAM register ‘mdc’
  
!      ‘f’
            Floating point register
  
!      ‘l’
!           General register, but not ‘r29’, ‘r30’ and ‘r31’
  
!      ‘t’
!           Register ‘r1’
  
!      ‘u’
!           Register ‘r2’
  
!      ‘v’
!           Register ‘r3’
  
!      ‘G’
            Floating-point constant 0.0
  
!      ‘J’
            Integer constant in the range 0 ..  65535 (16-bit immediate)
  
!      ‘K’
            Integer constant in the range 1 ..  31 (5-bit immediate)
  
!      ‘L’
!           Integer constant in the range −65535 ..  −1 (16-bit negative
            immediate)
  
!      ‘M’
!           Integer constant −1
  
!      ‘O’
            Integer constant 0
  
!      ‘P’
            Integer constant 32
  
! _x86 family--‘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)
                 {
*************** _x86 family--'config/i386/constraints.md
*** 45767,45773 ****
                 }
  
            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)
--- 45776,45782 ----
                 }
  
            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)
*************** _x86 family--'config/i386/constraints.md
*** 45777,45949 ****
                   return ((unsigned long long)tickh << 32)|tickl;
                 }
  
!      'U'
            The call-clobbered integer registers.
  
!      '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.
  
!      'v'
!           Any EVEX encodable SSE register ('%xmm0-%xmm31').
  
!      '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'
            SSE constant zero operand.
  
!      'e'
            32-bit signed integer constant, or a symbolic reference known
            to fit that range (for immediate operands in sign-extending
            x86-64 instructions).
  
!      'We'
            32-bit signed integer constant, or a symbolic reference known
            to fit that range (for sign-extending conversion operations
!           that require non-'VOIDmode' immediate operands).
  
!      'Wz'
            32-bit unsigned integer constant, or a symbolic reference
            known to fit that range (for zero-extending conversion
!           operations that require non-'VOIDmode' immediate operands).
  
!      'Wd'
            128-bit integer constant where both the high and low 64-bit
!           word satisfy the 'e' constraint.
  
!      'Z'
            32-bit unsigned integer constant, or a symbolic reference
            known to fit that range (for immediate operands in
            zero-extending x86-64 instructions).
  
!      'Tv'
            VSIB address operand.
  
!      'Ts'
            Address operand without segment register.
  
! _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
  
  
--- 45786,45958 ----
                   return ((unsigned long long)tickh << 32)|tickl;
                 }
  
!      ‘U’
            The call-clobbered integer registers.
  
!      ‘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.
  
!      ‘v’
!           Any EVEX encodable SSE register (‘%xmm0-%xmm31’).
  
!      ‘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’
            SSE constant zero operand.
  
!      ‘e’
            32-bit signed integer constant, or a symbolic reference known
            to fit that range (for immediate operands in sign-extending
            x86-64 instructions).
  
!      ‘We’
            32-bit signed integer constant, or a symbolic reference known
            to fit that range (for sign-extending conversion operations
!           that require non-‘VOIDmode’ immediate operands).
  
!      ‘Wz’
            32-bit unsigned integer constant, or a symbolic reference
            known to fit that range (for zero-extending conversion
!           operations that require non-‘VOIDmode’ immediate operands).
  
!      ‘Wd’
            128-bit integer constant where both the high and low 64-bit
!           word satisfy the ‘e’ constraint.
  
!      ‘Z’
            32-bit unsigned integer constant, or a symbolic reference
            known to fit that range (for immediate operands in
            zero-extending x86-64 instructions).
  
!      ‘Tv’
            VSIB address operand.
  
!      ‘Ts’
            Address operand without segment register.
  
! _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
*** 45953,45959 ****
  -----------------------------------------------
  
  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.  It is up to you to make sure that the assembler names
  you choose do not conflict with any other assembler symbols, or
  reference registers.
--- 45962,45968 ----
  -----------------------------------------------
  
  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.  It is up to you to make sure that the assembler names
  you choose do not conflict with any other assembler symbols, or
  reference registers.
*************** This sample shows how to specify the ass
*** 45965,45972 ****
  
       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
  variable, this feature allows you to define names for the linker that do
--- 45974,45981 ----
  
       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
  variable, this feature allows you to define names for the linker that do
*************** Assembler names for functions
*** 45981,45987 ****
  .............................
  
  To specify the assembler name for functions, write a declaration for the
! function before its definition and put 'asm' there, like this:
  
       int func (int x, int y) asm ("MYFUNC");
  
--- 45990,45996 ----
  .............................
  
  To specify the assembler name for functions, write a declaration for the
! function before its definition and put ‘asm’ there, like this:
  
       int func (int x, int y) asm ("MYFUNC");
  
*************** function before its definition and put '
*** 45989,45996 ****
       {
          /* ... */
  
! This specifies that the name to be used for the function 'func' in the
! assembler code should be 'MYFUNC'.
  
  
  File: gcc.info,  Node: Explicit Register Variables,  Next: Size of an asm,  Prev: Asm Labels,  Up: Using Assembly Language with C
--- 45998,46005 ----
       {
          /* ... */
  
! This specifies that the name to be used for the function ‘func’ in the
! assembler code should be ‘MYFUNC’.
  
  
  File: gcc.info,  Node: Explicit Register Variables,  Next: Size of an asm,  Prev: Asm Labels,  Up: Using Assembly Language with C
*************** specified register like this:
*** 46024,46038 ****
  
       register int *foo asm ("r12");
  
! Here 'r12' is the name of the register that should be used.  Note that
  this is the same syntax used for defining local register variables, but
  for a global variable the declaration appears outside a function.  The
! 'register' keyword is required, and cannot be combined with 'static'.
  The register name must be a valid register name for the target platform.
  
!  Do not use type qualifiers such as 'const' and 'volatile', as the
  outcome may be contrary to expectations.  In particular, using the
! 'volatile' qualifier does not fully prevent the compiler from optimizing
  accesses to the register.
  
   Registers are a scarce resource on most systems and allowing the
--- 46033,46047 ----
  
       register int *foo asm ("r12");
  
! Here ‘r12’ is the name of the register that should be used.  Note that
  this is the same syntax used for defining local register variables, but
  for a global variable the declaration appears outside a function.  The
! ‘register’ keyword is required, and cannot be combined with ‘static’.
  The register name must be a valid register name for the target platform.
  
!  Do not use type qualifiers such as ‘const’ and ‘volatile’, as the
  outcome may be contrary to expectations.  In particular, using the
! ‘volatile’ qualifier does not fully prevent the compiler from optimizing
  accesses to the register.
  
   Registers are a scarce resource on most systems and allowing the
*************** that are accessed very often.
*** 46045,46063 ****
   After defining a global register variable, for the current compilation
  unit:
  
!    * If the register is a call-saved register, call ABI is affected: the
       register will not be restored in function epilogue sequences after
       the variable has been assigned.  Therefore, functions cannot safely
       return to callers that assume standard ABI.
!    * Conversely, if the register is a call-clobbered register, making
       calls to functions that use standard ABI may lose contents of the
       variable.  Such calls may be created by the compiler even if none
       are evident in the original program, for example when libgcc
       functions are used to make up for unavailable instructions.
!    * Accesses to the variable may be optimized as usual and the register
       remains available for allocation and use in any computations,
       provided that observable values of the variable are not affected.
!    * If the variable is referenced in inline assembly, the type of
       access must be provided to the compiler via constraints (*note
       Constraints::).  Accesses from basic asms are not supported.
  
--- 46054,46072 ----
   After defining a global register variable, for the current compilation
  unit:
  
!    • If the register is a call-saved register, call ABI is affected: the
       register will not be restored in function epilogue sequences after
       the variable has been assigned.  Therefore, functions cannot safely
       return to callers that assume standard ABI.
!    • Conversely, if the register is a call-clobbered register, making
       calls to functions that use standard ABI may lose contents of the
       variable.  Such calls may be created by the compiler even if none
       are evident in the original program, for example when libgcc
       functions are used to make up for unavailable instructions.
!    • Accesses to the variable may be optimized as usual and the register
       remains available for allocation and use in any computations,
       provided that observable values of the variable are not affected.
!    • If the variable is referenced in inline assembly, the type of
       access must be provided to the compiler via constraints (*note
       Constraints::).  Accesses from basic asms are not supported.
  
*************** code from libraries) is not affected.
*** 46069,46075 ****
  global register variable so they do not use the specified register for
  any other purpose, you need not actually add the global register
  declaration to their source code.  It suffices to specify the compiler
! option '-ffixed-REG' (*note Code Gen Options::) to reserve the register.
  
  Declaring the variable
  ......................
--- 46078,46084 ----
  global register variable so they do not use the specified register for
  any other purpose, you need not actually add the global register
  declaration to their source code.  It suffices to specify the compiler
! option ‘-ffixed-REG’ (*note Code Gen Options::) to reserve the register.
  
  Declaring the variable
  ......................
*************** Using the variable
*** 46090,46101 ****
  
  When calling routines that are not aware of the reservation, be cautious
  if those routines call back into code which uses them.  As an example,
! if you call the system library version of 'qsort', it may clobber your
  registers during execution, but (if you have selected appropriate
  registers) it will restore them before returning.  However it will _not_
! restore them before calling 'qsort''s comparison function.  As a result,
  global values will not reliably be available to the comparison function
! unless the 'qsort' function itself is rebuilt.
  
   Similarly, it is not safe to access the global register variables from
  signal handlers or from more than one thread of control.  Unless you
--- 46099,46110 ----
  
  When calling routines that are not aware of the reservation, be cautious
  if those routines call back into code which uses them.  As an example,
! if you call the system library version of ‘qsort’, it may clobber your
  registers during execution, but (if you have selected appropriate
  registers) it will restore them before returning.  However it will _not_
! restore them before calling ‘qsort’'s comparison function.  As a result,
  global values will not reliably be available to the comparison function
! unless the ‘qsort’ function itself is rebuilt.
  
   Similarly, it is not safe to access the global register variables from
  signal handlers or from more than one thread of control.  Unless you
*************** Furthermore, since the register is not r
*** 46105,46117 ****
  variable, accessing it from handlers of asynchronous signals may observe
  unrelated temporary values residing in the register.
  
!  On most machines, 'longjmp' restores to each global register variable
! the value it had at the time of the 'setjmp'.  On some machines,
! however, 'longjmp' does not change the value of global register
! variables.  To be portable, the function that called 'setjmp' should
  make other arrangements to save the values of the global register
! variables, and to restore them in a 'longjmp'.  This way, the same thing
! happens regardless of what 'longjmp' does.
  
  
  File: gcc.info,  Node: Local Register Variables,  Prev: Global Register Variables,  Up: Explicit Register Variables
--- 46114,46126 ----
  variable, accessing it from handlers of asynchronous signals may observe
  unrelated temporary values residing in the register.
  
!  On most machines, ‘longjmp’ restores to each global register variable
! the value it had at the time of the ‘setjmp’.  On some machines,
! however, ‘longjmp’ does not change the value of global register
! variables.  To be portable, the function that called ‘setjmp’ should
  make other arrangements to save the values of the global register
! variables, and to restore them in a ‘longjmp’.  This way, the same thing
! happens regardless of what ‘longjmp’ does.
  
  
  File: gcc.info,  Node: Local Register Variables,  Prev: Global Register Variables,  Up: Explicit Register Variables
*************** specified register like this:
*** 46124,46139 ****
  
       register int *foo asm ("r12");
  
! Here 'r12' is the name of the register that should be used.  Note that
  this is the same syntax used for defining global register variables, but
  for a local variable the declaration appears within a function.  The
! 'register' keyword is required, and cannot be combined with 'static'.
  The register name must be a valid register name for the target platform.
  
!  Do not use type qualifiers such as 'const' and 'volatile', as the
  outcome may be contrary to expectations.  In particular, when the
! 'const' qualifier is used, the compiler may substitute the variable with
! its initializer in 'asm' statements, which may cause the corresponding
  operand to appear in a different register.
  
   As with global register variables, it is recommended that you choose a
--- 46133,46148 ----
  
       register int *foo asm ("r12");
  
! Here ‘r12’ is the name of the register that should be used.  Note that
  this is the same syntax used for defining global register variables, but
  for a local variable the declaration appears within a function.  The
! ‘register’ keyword is required, and cannot be combined with ‘static’.
  The register name must be a valid register name for the target platform.
  
!  Do not use type qualifiers such as ‘const’ and ‘volatile’, as the
  outcome may be contrary to expectations.  In particular, when the
! ‘const’ qualifier is used, the compiler may substitute the variable with
! its initializer in ‘asm’ statements, which may cause the corresponding
  operand to appear in a different register.
  
   As with global register variables, it is recommended that you choose a
*************** register that is normally saved and rest
*** 46141,46152 ****
  machine, so that calls to library routines will not clobber it.
  
   The only supported use for this feature is to specify registers for
! input and output operands when calling Extended 'asm' (*note Extended
  Asm::).  This may be necessary if the constraints for a particular
  machine don't provide sufficient control to select the desired register.
  To force an operand into a register, create a local variable and specify
  the register name after the variable's declaration.  Then use the local
! variable for the 'asm' operand and specify any constraint letter that
  matches the register:
  
       register int *p1 asm ("r0") = ...;
--- 46150,46161 ----
  machine, so that calls to library routines will not clobber it.
  
   The only supported use for this feature is to specify registers for
! input and output operands when calling Extended ‘asm’ (*note Extended
  Asm::).  This may be necessary if the constraints for a particular
  machine don't provide sufficient control to select the desired register.
  To force an operand into a register, create a local variable and specify
  the register name after the variable's declaration.  Then use the local
! variable for the ‘asm’ operand and specify any constraint letter that
  matches the register:
  
       register int *p1 asm ("r0") = ...;
*************** matches the register:
*** 46155,46163 ****
       asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
  
   _Warning:_ In the above example, be aware that a register (for example
! 'r0') can be call-clobbered by subsequent code, including function calls
  and library calls for arithmetic operators on other variables (for
! example the initialization of 'p2').  In this case, use temporary
  variables for expressions between the register assignments:
  
       int t1 = ...;
--- 46164,46172 ----
       asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
  
   _Warning:_ In the above example, be aware that a register (for example
! ‘r0’) can be call-clobbered by subsequent code, including function calls
  and library calls for arithmetic operators on other variables (for
! example the initialization of ‘p2’).  In this case, use temporary
  variables for expressions between the register assignments:
  
       int t1 = ...;
*************** variables for expressions between the re
*** 46167,46183 ****
       asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
  
   Defining a register variable does not reserve the register.  Other than
! when invoking the Extended 'asm', the contents of the specified register
  are not guaranteed.  For this reason, the following uses are explicitly
  _not_ supported.  If they appear to work, it is only happenstance, and
  may stop working as intended due to (seemingly) unrelated changes in
  surrounding code, or even minor changes in the optimization of a future
  version of gcc:
  
!    * Passing parameters to or from Basic 'asm'
!    * Passing parameters to or from Extended 'asm' without using input or
       output operands.
!    * Passing parameters to or from routines written in assembler (or
       other languages) using non-standard calling conventions.
  
   Some developers use Local Register Variables in an attempt to improve
--- 46176,46192 ----
       asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
  
   Defining a register variable does not reserve the register.  Other than
! when invoking the Extended ‘asm’, the contents of the specified register
  are not guaranteed.  For this reason, the following uses are explicitly
  _not_ supported.  If they appear to work, it is only happenstance, and
  may stop working as intended due to (seemingly) unrelated changes in
  surrounding code, or even minor changes in the optimization of a future
  version of gcc:
  
!    • Passing parameters to or from Basic ‘asm’
!    • Passing parameters to or from Extended ‘asm’ without using input or
       output operands.
!    • Passing parameters to or from routines written in assembler (or
       other languages) using non-standard calling conventions.
  
   Some developers use Local Register Variables in an attempt to improve
*************** specifics for MIPS targets: (gccint)MIPS
*** 46195,46212 ****
  
  File: gcc.info,  Node: Size of an asm,  Prev: Explicit Register Variables,  Up: Using Assembly Language with C
  
! 6.47.6 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 the code
! produced by an 'asm' statement is only known by the assembler, GCC must
  make an estimate as to how big it will be.  It does this by counting the
! number of instructions in the pattern of the 'asm' and multiplying that
  by the length of the longest instruction supported by that processor.
  (When working out the number of instructions, it assumes that any
  occurrence of a newline or of whatever statement separator character is
! supported by the assembler -- typically ';' -- indicates the end of an
  instruction.)
  
   Normally, GCC's estimate is adequate to ensure that correct code is
--- 46204,46221 ----
  
  File: gcc.info,  Node: Size of an asm,  Prev: Explicit Register Variables,  Up: Using Assembly Language with C
  
! 6.47.6 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 the code
! produced by an ‘asm’ statement is only known by the assembler, GCC must
  make an estimate as to how big it will be.  It does this by counting the
! number of instructions in the pattern of the ‘asm’ and multiplying that
  by the length of the longest instruction supported by that processor.
  (When working out the number of instructions, it assumes that any
  occurrence of a newline or of whatever statement separator character is
! supported by the assembler -- typically ‘;’ -- indicates the end of an
  instruction.)
  
   Normally, GCC's estimate is adequate to ensure that correct code is
*************** space in the object file than is needed
*** 46217,46224 ****
  this happens then the assembler may produce a diagnostic saying that a
  label is unreachable.
  
!  This size is also used for inlining decisions.  If you use 'asm inline'
! instead of just 'asm', then for inlining purposes the size of the asm is
  taken as the minimum size, ignoring how many instructions GCC thinks it
  is.
  
--- 46226,46233 ----
  this happens then the assembler may produce a diagnostic saying that a
  label is unreachable.
  
!  This size is also used for inlining decisions.  If you use ‘asm inline’
! instead of just ‘asm’, then for inlining purposes the size of the asm is
  taken as the minimum size, ignoring how many instructions GCC thinks it
  is.
  
*************** File: gcc.info,  Node: Alternate Keyword
*** 46228,46247 ****
  6.48 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 a later
! standard).  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
--- 46237,46256 ----
  6.48 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 a later
! standard).  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
*************** this:
*** 46252,46278 ****
       #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.49 Incomplete 'enum' Types
  ============================
  
! You can define an 'enum' tag without specifying its possible values.
  This results in an incomplete type, much like what you get if you write
! 'struct foo' without describing the elements.  A later declaration that
  does specify the possible values completes the type.
  
   You cannot 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++.
  
--- 46261,46287 ----
       #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.49 Incomplete ‘enum’ Types
  ============================
  
! You can define an ‘enum’ tag without specifying its possible values.
  This results in an incomplete type, much like what you get if you write
! ‘struct foo’ without describing the elements.  A later declaration that
  does specify the possible values completes the type.
  
   You cannot 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,
*** 46284,46294 ****
  
  GCC provides three magic constants that hold the name of the current
  function as a string.  In C++11 and later modes, all three are treated
! as constant expressions and can be used in 'constexpr' constexts.  The
! first of these constants 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
  
--- 46293,46303 ----
  
  GCC provides three magic constants that hold the name of the current
  function as a string.  In C++11 and later modes, all three are treated
! as constant expressions and can be used in ‘constexpr’ constexts.  The
! first of these constants 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
  
*************** the declaration
*** 46296,46310 ****
  
  appeared, where function-name is the name of the lexically-enclosing
  function.  This name is the unadorned name of the function.  As an
! extension, at file (or, in C++, namespace scope), '__func__' evaluates
  to the empty string.
  
!  '__FUNCTION__' is another name for '__func__', provided for backward
  compatibility with old versions of GCC.
  
!  In C, '__PRETTY_FUNCTION__' is yet another name for '__func__', except
  that at file scope (or, in C++, namespace scope), it evaluates to the
! string '"top level"'.  In addition, in C++, '__PRETTY_FUNCTION__'
  contains the signature of the function as well as its bare name.  For
  example, this program:
  
--- 46305,46319 ----
  
  appeared, where function-name is the name of the lexically-enclosing
  function.  This name is the unadorned name of the function.  As an
! extension, at file (or, in C++, namespace scope), ‘__func__’ evaluates
  to the empty string.
  
!  ‘__FUNCTION__’ is another name for ‘__func__’, provided for backward
  compatibility with old versions of GCC.
  
!  In C, ‘__PRETTY_FUNCTION__’ is yet another name for ‘__func__’, except
  that at file scope (or, in C++, namespace scope), it evaluates to the
! string ‘"top level"’.  In addition, in C++, ‘__PRETTY_FUNCTION__’
  contains the signature of the function as well as its bare name.  For
  example, this program:
  
*************** gives this output:
*** 46333,46339 ****
       __PRETTY_FUNCTION__ = void a::sub(int)
  
   These identifiers are variables, not preprocessor macros, and may not
! be used to initialize 'char' arrays or be concatenated with string
  literals.
  
  
--- 46342,46348 ----
       __PRETTY_FUNCTION__ = void a::sub(int)
  
   These identifiers are variables, not preprocessor macros, and may not
! be used to initialize ‘char’ arrays or be concatenated with string
  literals.
  
  
*************** function.
*** 46349,46360 ****
            LEVEL)
       This function returns the return address of the current function,
       or of one of its callers.  The LEVEL argument is number of frames
!      to scan up the call stack.  A value of '0' yields the return
!      address of the current function, a value of '1' yields the return
       address of the caller of the current function, and so forth.  When
       inlining the expected behavior is that the function returns the
       address of the function that is returned to.  To work around this
!      behavior use the 'noinline' function attribute.
  
       The LEVEL argument must be a constant integer.
  
--- 46358,46369 ----
            LEVEL)
       This function returns the return address of the current function,
       or of one of its callers.  The LEVEL argument is number of frames
!      to scan up the call stack.  A value of ‘0’ yields the return
!      address of the current function, a value of ‘1’ yields the return
       address of the caller of the current function, and so forth.  When
       inlining the expected behavior is that the function returns the
       address of the function that is returned to.  To work around this
!      behavior use the ‘noinline’ function attribute.
  
       The LEVEL argument must be a constant integer.
  
*************** function.
*** 46362,46393 ****
       address of any function other than the current one; in such cases,
       or when the top of the stack has been reached, this function
       returns an unspecified value.  In addition,
!      '__builtin_frame_address' may be used to determine if the top of
       the stack has been reached.
  
       Additional post-processing of the returned value may be needed, see
!      '__builtin_extract_return_addr'.
  
       The stored representation of the return address in memory may be
!      different from the address returned by '__builtin_return_address'.
       For example, on AArch64 the stored address may be mangled with
       return address signing whereas the address returned by
!      '__builtin_return_address' is not.
  
       Calling this function with a nonzero argument can have
       unpredictable effects, including crashing the calling program.  As
       a result, calls that are considered unsafe are diagnosed when the
!      '-Wframe-address' option is in effect.  Such calls should only be
       made in debugging situations.
  
!      On targets where code addresses are representable as 'void *',
            void *addr = __builtin_extract_return_addr (__builtin_return_address (0));
       gives the code address where the current function would return.
!      For example, such an address may be used with 'dladdr' or other
       interfaces that work with code addresses.
  
   -- Built-in Function: void * __builtin_extract_return_addr (void *ADDR)
!      The address as returned by '__builtin_return_address' may have to
       be fed through this function to get the actual encoded address.
       For example, on the 31-bit S/390 platform the highest bit has to be
       masked out, or on SPARC platforms an offset has to be added for the
--- 46371,46402 ----
       address of any function other than the current one; in such cases,
       or when the top of the stack has been reached, this function
       returns an unspecified value.  In addition,
!      ‘__builtin_frame_address’ may be used to determine if the top of
       the stack has been reached.
  
       Additional post-processing of the returned value may be needed, see
!      ‘__builtin_extract_return_addr’.
  
       The stored representation of the return address in memory may be
!      different from the address returned by ‘__builtin_return_address’.
       For example, on AArch64 the stored address may be mangled with
       return address signing whereas the address returned by
!      ‘__builtin_return_address’ is not.
  
       Calling this function with a nonzero argument can have
       unpredictable effects, including crashing the calling program.  As
       a result, calls that are considered unsafe are diagnosed when the
!      ‘-Wframe-address’ option is in effect.  Such calls should only be
       made in debugging situations.
  
!      On targets where code addresses are representable as ‘void *’,
            void *addr = __builtin_extract_return_addr (__builtin_return_address (0));
       gives the code address where the current function would return.
!      For example, such an address may be used with ‘dladdr’ or other
       interfaces that work with code addresses.
  
   -- Built-in Function: void * __builtin_extract_return_addr (void *ADDR)
!      The address as returned by ‘__builtin_return_address’ may have to
       be fed through this function to get the actual encoded address.
       For example, on the 31-bit S/390 platform the highest bit has to be
       masked out, or on SPARC platforms an offset has to be added for the
*************** function.
*** 46396,46410 ****
       If no fixup is needed, this function simply passes through ADDR.
  
   -- Built-in Function: void * __builtin_frob_return_addr (void *ADDR)
!      This function does the reverse of '__builtin_extract_return_addr'.
  
   -- Built-in Function: void * __builtin_frame_address (unsigned int
            LEVEL)
!      This function is similar to '__builtin_return_address', but it
       returns the address of the function frame rather than the return
!      address of the function.  Calling '__builtin_frame_address' with a
!      value of '0' yields the frame address of the current function, a
!      value of '1' yields the frame address of the caller of the current
       function, and so forth.
  
       The frame is the area on the stack that holds local variables and
--- 46405,46419 ----
       If no fixup is needed, this function simply passes through ADDR.
  
   -- Built-in Function: void * __builtin_frob_return_addr (void *ADDR)
!      This function does the reverse of ‘__builtin_extract_return_addr’.
  
   -- Built-in Function: void * __builtin_frame_address (unsigned int
            LEVEL)
!      This function is similar to ‘__builtin_return_address’, but it
       returns the address of the function frame rather than the return
!      address of the function.  Calling ‘__builtin_frame_address’ with a
!      value of ‘0’ yields the frame address of the current function, a
!      value of ‘1’ yields the frame address of the caller of the current
       function, and so forth.
  
       The frame is the area on the stack that holds local variables and
*************** function.
*** 46413,46431 ****
       exact definition depends upon the processor and the calling
       convention.  If the processor has a dedicated frame pointer
       register, and the function has a frame, then
!      '__builtin_frame_address' returns the value of the frame pointer
       register.
  
       On some machines it may be impossible to determine the frame
       address of any function other than the current one; in such cases,
       or when the top of the stack has been reached, this function
!      returns '0' if the first frame pointer is properly initialized by
       the startup code.
  
       Calling this function with a nonzero argument can have
       unpredictable effects, including crashing the calling program.  As
       a result, calls that are considered unsafe are diagnosed when the
!      '-Wframe-address' option is in effect.  Such calls should only be
       made in debugging situations.
  
  
--- 46422,46440 ----
       exact definition depends upon the processor and the calling
       convention.  If the processor has a dedicated frame pointer
       register, and the function has a frame, then
!      ‘__builtin_frame_address’ returns the value of the frame pointer
       register.
  
       On some machines it may be impossible to determine the frame
       address of any function other than the current one; in such cases,
       or when the top of the stack has been reached, this function
!      returns ‘0’ if the first frame pointer is properly initialized by
       the startup code.
  
       Calling this function with a nonzero argument can have
       unpredictable effects, including crashing the calling program.  As
       a result, calls that are considered unsafe are diagnosed when the
!      ‘-Wframe-address’ option is in effect.  Such calls should only be
       made in debugging situations.
  
  
*************** same time.  For example, on the x86 the
*** 46440,46478 ****
  can be used this way.
  
   The first step in using these extensions is to provide the necessary
! data types.  This should be done using an appropriate 'typedef':
  
       typedef int v4si __attribute__ ((vector_size (16)));
  
! The 'int' type specifies the "base type", while the attribute specifies
  the vector size for the variable, measured in bytes.  For example, the
! declaration above causes the compiler to set the mode for the 'v4si'
! type to be 16 bytes wide and divided into 'int' sized units.  For a
! 32-bit 'int' this means a vector of 4 units of 4 bytes, and the
! corresponding mode of 'foo' is V4SI.
  
!  The 'vector_size' attribute is only applicable to integral and floating
  scalars, although arrays, pointers, and function return values are
  allowed in conjunction with this construct.  Only sizes that are
  positive power-of-two multiples of the base type size are currently
  allowed.
  
   All the basic integer types can be used as base types, both as signed
! and as unsigned: 'char', 'short', 'int', 'long', 'long long'.  In
! addition, 'float' and 'double' can be used to build floating-point
  vector types.
  
   Specifying a combination that is not valid for the current architecture
  causes GCC to synthesize the instructions using a narrower mode.  For
! example, if you specify a variable of type 'V4SI' and your architecture
  does not allow for this specific SIMD type, GCC produces code that uses
! 4 'SIs'.
  
   The types defined in this manner can be used with a subset of normal C
  operations.  Currently, GCC allows using the following operators on
! these types: '+, -, *, /, unary minus, ^, |, &, ~, %'.
  
!  The operations behave like C++ 'valarrays'.  Addition is defined as the
  addition of the corresponding elements of the operands.  For example, in
  the code below, each of the 4 elements in A is added to the
  corresponding 4 elements in B and the resulting vector is stored in C.
--- 46449,46487 ----
  can be used this way.
  
   The first step in using these extensions is to provide the necessary
! data types.  This should be done using an appropriate ‘typedef’:
  
       typedef int v4si __attribute__ ((vector_size (16)));
  
! The ‘int’ type specifies the “base type”, while the attribute specifies
  the vector size for the variable, measured in bytes.  For example, the
! declaration above causes the compiler to set the mode for the ‘v4si’
! type to be 16 bytes wide and divided into ‘int’ sized units.  For a
! 32-bit ‘int’ this means a vector of 4 units of 4 bytes, and the
! corresponding mode of ‘foo’ is V4SI.
  
!  The ‘vector_size’ attribute is only applicable to integral and floating
  scalars, although arrays, pointers, and function return values are
  allowed in conjunction with this construct.  Only sizes that are
  positive power-of-two multiples of the base type size are currently
  allowed.
  
   All the basic integer types can be used as base types, both as signed
! and as unsigned: ‘char’, ‘short’, ‘int’, ‘long’, ‘long long’.  In
! addition, ‘float’ and ‘double’ can be used to build floating-point
  vector types.
  
   Specifying a combination that is not valid for the current architecture
  causes GCC to synthesize the instructions using a narrower mode.  For
! example, if you specify a variable of type ‘V4SI’ and your architecture
  does not allow for this specific SIMD type, GCC produces code that uses
! 4 ‘SIs’.
  
   The types defined in this manner can be used with a subset of normal C
  operations.  Currently, GCC allows using the following operators on
! these types: ‘+, -, *, /, unary minus, ^, |, &, ~, %’.
  
!  The operations behave like C++ ‘valarrays’.  Addition is defined as the
  addition of the corresponding elements of the operands.  For example, in
  the code below, each of the 4 elements in A is added to the
  corresponding 4 elements in B and the resulting vector is stored in C.
*************** minus or complement operators on a vecto
*** 46489,46497 ****
  elements are the negative or complemented values of the corresponding
  elements in the operand.
  
!  It is possible to use shifting operators '<<', '>>' on integer-type
! vectors.  The operation is defined as following: '{a0, a1, ..., an} >>
! {b0, b1, ..., bn} == {a0 >> b0, a1 >> b1, ..., an >> bn}'.  Vector
  operands must have the same number of elements.
  
   For convenience, it is allowed to use a binary vector operation where
--- 46498,46506 ----
  elements are the negative or complemented values of the corresponding
  elements in the operand.
  
!  It is possible to use shifting operators ‘<<’, ‘>>’ on integer-type
! vectors.  The operation is defined as following: ‘{a0, a1, ..., an} >>
! {b0, b1, ..., bn} == {a0 >> b0, a1 >> b1, ..., an >> bn}’.  Vector
  operands must have the same number of elements.
  
   For convenience, it is allowed to use a binary vector operation where
*************** code.
*** 46514,46523 ****
   Vectors can be subscripted as if the vector were an array with the same
  number of elements and base type.  Out of bound accesses invoke
  undefined behavior at run time.  Warnings for out of bound accesses for
! vector subscription can be enabled with '-Warray-bounds'.
  
!  Vector comparison is supported with standard comparison operators: '==,
! !=, <, <=, >, >='.  Comparison operands can be vector expressions of
  integer-type or real-type.  Comparison between integer-type vectors and
  real-type vectors are not supported.  The result of the comparison is a
  vector of the same width and number of elements as the comparison
--- 46523,46532 ----
   Vectors can be subscripted as if the vector were an array with the same
  number of elements and base type.  Out of bound accesses invoke
  undefined behavior at run time.  Warnings for out of bound accesses for
! vector subscription can be enabled with ‘-Warray-bounds’.
  
!  Vector comparison is supported with standard comparison operators: ‘==,
! !=, <, <=, >, >=’.  Comparison operands can be vector expressions of
  integer-type or real-type.  Comparison between integer-type vectors and
  real-type vectors are not supported.  The result of the comparison is a
  vector of the same width and number of elements as the comparison
*************** otherwise.  Consider the following examp
*** 46536,46562 ****
       c = a >  b;     /* The result would be {0, 0,-1, 0}  */
       c = a == b;     /* The result would be {0,-1, 0,-1}  */
  
!  In C++, the ternary operator '?:' is available.  'a?b:c', where 'b' and
! 'c' are vectors of the same type and 'a' is an integer vector with the
! same number of elements of the same size as 'b' and 'c', computes all
! three arguments and creates a vector '{a[0]?b[0]:c[0], a[1]?b[1]:c[1],
! ...}'.  Note that unlike in OpenCL, 'a' is thus interpreted as 'a != 0'
! and not 'a < 0'.  As in the case of binary operations, this syntax is
! also accepted when one of 'b' or 'c' is a scalar that is then
! transformed into a vector.  If both 'b' and 'c' are scalars and the type
! of 'true?b:c' has the same size as the element type of 'a', then 'b' and
! 'c' are converted to a vector type whose elements have this type and
! with the same number of elements as 'a'.
  
!  In C++, the logic operators '!, &&, ||' are available for vectors.
! '!v' is equivalent to 'v == 0', 'a && b' is equivalent to 'a!=0 & b!=0'
! and 'a || b' is equivalent to 'a!=0 | b!=0'.  For mixed operations
! between a scalar 's' and a vector 'v', 's && v' is equivalent to
! 's?v!=0:0' (the evaluation is short-circuit) and 'v && s' is equivalent
! to 'v!=0 & (s?-1:0)'.
  
!  Vector shuffling is available using functions '__builtin_shuffle (vec,
! mask)' and '__builtin_shuffle (vec0, vec1, mask)'.  Both functions
  construct a permutation of elements from one or two vectors and return a
  vector of the same type as the input vector(s).  The MASK is an integral
  vector with the same width (W) and element count (N) as the output
--- 46545,46571 ----
       c = a >  b;     /* The result would be {0, 0,-1, 0}  */
       c = a == b;     /* The result would be {0,-1, 0,-1}  */
  
!  In C++, the ternary operator ‘?:’ is available.  ‘a?b:c’, where ‘b’ and
! ‘c’ are vectors of the same type and ‘a’ is an integer vector with the
! same number of elements of the same size as ‘b’ and ‘c’, computes all
! three arguments and creates a vector ‘{a[0]?b[0]:c[0], a[1]?b[1]:c[1],
! ...}’.  Note that unlike in OpenCL, ‘a’ is thus interpreted as ‘a != 0’
! and not ‘a < 0’.  As in the case of binary operations, this syntax is
! also accepted when one of ‘b’ or ‘c’ is a scalar that is then
! transformed into a vector.  If both ‘b’ and ‘c’ are scalars and the type
! of ‘true?b:c’ has the same size as the element type of ‘a’, then ‘b’ and
! ‘c’ are converted to a vector type whose elements have this type and
! with the same number of elements as ‘a’.
  
!  In C++, the logic operators ‘!, &&, ||’ are available for vectors.
! ‘!v’ is equivalent to ‘v == 0’, ‘a && b’ is equivalent to ‘a!=0 & b!=0’
! and ‘a || b’ is equivalent to ‘a!=0 | b!=0’.  For mixed operations
! between a scalar ‘s’ and a vector ‘v’, ‘s && v’ is equivalent to
! ‘s?v!=0:0’ (the evaluation is short-circuit) and ‘v && s’ is equivalent
! to ‘v!=0 & (s?-1:0)’.
  
!  Vector shuffling is available using functions ‘__builtin_shuffle (vec,
! mask)’ and ‘__builtin_shuffle (vec0, vec1, mask)’.  Both functions
  construct a permutation of elements from one or two vectors and return a
  vector of the same type as the input vector(s).  The MASK is an integral
  vector with the same width (W) and element count (N) as the output
*************** two-operand case.
*** 46580,46587 ****
       res = __builtin_shuffle (a, mask1);       /* res is {1,2,2,4}  */
       res = __builtin_shuffle (a, b, mask2);    /* res is {1,5,3,6}  */
  
!  Note that '__builtin_shuffle' is intentionally semantically compatible
! with the OpenCL 'shuffle' and 'shuffle2' functions.
  
   You can declare variables and use them in function calls and returns,
  as well as in assignments and some casts.  You can specify a vector type
--- 46589,46596 ----
       res = __builtin_shuffle (a, mask1);       /* res is {1,2,2,4}  */
       res = __builtin_shuffle (a, b, mask2);    /* res is {1,5,3,6}  */
  
!  Note that ‘__builtin_shuffle’ is intentionally semantically compatible
! with the OpenCL ‘shuffle’ and ‘shuffle2’ functions.
  
   You can declare variables and use them in function calls and returns,
  as well as in assignments and some casts.  You can specify a vector type
*************** vectors to and from other datatypes of t
*** 46593,46602 ****
   You cannot operate between vectors of different lengths or different
  signedness without a cast.
  
!  Vector shuffling is available using the '__builtin_shufflevector (vec1,
! vec2, index...)' function.  VEC1 and VEC2 must be expressions with
  vector type with a compatible element type.  The result of
! '__builtin_shufflevector' is a vector with the same element type as VEC1
  and VEC2 but that has an element count equal to the number of indices
  specified.
  
--- 46602,46611 ----
   You cannot operate between vectors of different lengths or different
  signedness without a cast.
  
!  Vector shuffling is available using the ‘__builtin_shufflevector (vec1,
! vec2, index...)’ function.  VEC1 and VEC2 must be expressions with
  vector type with a compatible element type.  The result of
! ‘__builtin_shufflevector’ is a vector with the same element type as VEC1
  and VEC2 but that has an element count equal to the number of indices
  specified.
  
*************** optimized the generated code sequence pe
*** 46617,46624 ****
       v4si c = {-2,-4,-6,-8};
       v8si d = __builtin_shufflevector (c, b, 4, 0, 5, 1, 6, 2, 7, 3); /* d is a */
  
!  Vector conversion is available using the '__builtin_convertvector (vec,
! vectype)' function.  VEC must be an expression with integral or floating
  vector type and VECTYPE an integral or floating vector type with the
  same number of elements.  The result has VECTYPE type and value of a C
  cast of every element of VEC to the element type of VECTYPE.
--- 46626,46633 ----
       v4si c = {-2,-4,-6,-8};
       v8si d = __builtin_shufflevector (c, b, 4, 0, 5, 1, 6, 2, 7, 3); /* d is a */
  
!  Vector conversion is available using the ‘__builtin_convertvector (vec,
! vectype)’ function.  VEC must be an expression with integral or floating
  vector type and VECTYPE an integral or floating vector type with the
  same number of elements.  The result has VECTYPE type and value of a C
  cast of every element of VEC to the element type of VECTYPE.
*************** cast of every element of VEC to the elem
*** 46644,46652 ****
  operations (for clarity) and machine-specific vector intrinsics (to
  access vector instructions that are not exposed via generic built-ins).
  On x86, intrinsic functions for integer vectors typically use the same
! vector type '__m128i' irrespective of how they interpret the vector,
  making it necessary to cast their arguments and return values from/to
! other vector types.  In C, you can make use of a 'union' type:
       #include 
  
       typedef unsigned char u8x16 __attribute__ ((vector_size (16)));
--- 46653,46661 ----
  operations (for clarity) and machine-specific vector intrinsics (to
  access vector instructions that are not exposed via generic built-ins).
  On x86, intrinsic functions for integer vectors typically use the same
! vector type ‘__m128i’ irrespective of how they interpret the vector,
  making it necessary to cast their arguments and return values from/to
! other vector types.  In C, you can make use of a ‘union’ type:
       #include 
  
       typedef unsigned char u8x16 __attribute__ ((vector_size (16)));
*************** intrinsics:
*** 46675,46685 ****
  
  File: gcc.info,  Node: Offsetof,  Next: __sync Builtins,  Prev: Vector Extensions,  Up: C Extensions
  
! 6.53 Support for 'offsetof'
  ===========================
  
  GCC implements for both C and C++ a syntactic extension to implement the
! 'offsetof' macro.
  
       primary:
               "__builtin_offsetof" "(" typename "," offsetof_member_designator ")"
--- 46684,46694 ----
  
  File: gcc.info,  Node: Offsetof,  Next: __sync Builtins,  Prev: Vector Extensions,  Up: C Extensions
  
! 6.53 Support for ‘offsetof’
  ===========================
  
  GCC implements for both C and C++ a syntactic extension to implement the
! ‘offsetof’ macro.
  
       primary:
               "__builtin_offsetof" "(" typename "," offsetof_member_designator ")"
*************** GCC implements for both C and C++ a synt
*** 46693,46734 ****
  
       #define offsetof(TYPE, MEMBER)  __builtin_offsetof (TYPE, MEMBER)
  
! is a suitable definition of the 'offsetof' macro.  In C++, TYPE may be
  dependent.  In either case, MEMBER may consist of a single identifier,
  or a sequence of member accesses and array references.
  
  
  File: gcc.info,  Node: __sync Builtins,  Next: __atomic Builtins,  Prev: Offsetof,  Up: C Extensions
  
! 6.54 Legacy '__sync' Built-in Functions for Atomic Memory Access
  ================================================================
  
  The following built-in functions are intended to be compatible with
! those described in the 'Intel Itanium Processor-specific Application
! Binary Interface', section 7.4.  As such, they depart from normal GCC
! practice by not using the '__builtin_' prefix and also by being
  overloaded so 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' or their unsigned counterparts.
  GCC allows any scalar type that is 1, 2, 4 or 8 bytes in size other than
! the C type '_Bool' or the C++ type 'bool'.  Operations on pointer
! arguments are performed as if the operands were of the 'uintptr_t' type.
  That is, they are not scaled by the size of the type to which the
  pointer points.
  
!  These functions are implemented in terms of the '__atomic' builtins
  (*note __atomic Builtins::).  They should not be used for new code which
! should use the '__atomic' builtins instead.
  
   Not all operations are supported by all target processors.  If a
  particular operation cannot be implemented on the target processor, a
  call to an external function is generated.  The external function
  carries the same name as the built-in version, with an additional suffix
! '_N' where N is the size of the data type.
  
!  In most cases, these built-in functions are considered a "full
! barrier".  That is, no memory operand is moved across the operation,
  either forward or backward.  Further, instructions are issued as
  necessary to prevent the processor from speculating loads across the
  operation and from queuing stores after the operation.
--- 46702,46743 ----
  
       #define offsetof(TYPE, MEMBER)  __builtin_offsetof (TYPE, MEMBER)
  
! is a suitable definition of the ‘offsetof’ macro.  In C++, TYPE may be
  dependent.  In either case, MEMBER may consist of a single identifier,
  or a sequence of member accesses and array references.
  
  
  File: gcc.info,  Node: __sync Builtins,  Next: __atomic Builtins,  Prev: Offsetof,  Up: C Extensions
  
! 6.54 Legacy ‘__sync’ Built-in Functions for Atomic Memory Access
  ================================================================
  
  The following built-in functions are intended to be compatible with
! those described in the ‘Intel Itanium Processor-specific Application
! Binary Interface’, section 7.4.  As such, they depart from normal GCC
! practice by not using the ‘__builtin_’ prefix and also by being
  overloaded so 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’ or their unsigned counterparts.
  GCC allows any scalar type that is 1, 2, 4 or 8 bytes in size other than
! the C type ‘_Bool’ or the C++ type ‘bool’.  Operations on pointer
! arguments are performed as if the operands were of the ‘uintptr_t’ type.
  That is, they are not scaled by the size of the type to which the
  pointer points.
  
!  These functions are implemented in terms of the ‘__atomic’ builtins
  (*note __atomic Builtins::).  They should not be used for new code which
! should use the ‘__atomic’ builtins instead.
  
   Not all operations are supported by all target processors.  If a
  particular operation cannot be implemented on the target processor, a
  call to an external function is generated.  The external function
  carries the same name as the built-in version, with an additional suffix
! ‘_N’ where N is the size of the data type.
  
!  In most cases, these built-in functions are considered a “full
! barrier”.  That is, no memory operand is moved across the operation,
  either forward or backward.  Further, instructions are issued as
  necessary to prevent the processor from speculating loads across the
  operation and from queuing stores after the operation.
*************** variables should be protected.
*** 46757,46763 ****
       name, and returns the value that had previously been in memory.
       That is, operations on integer operands have the following
       semantics.  Operations on pointer arguments are performed as if the
!      operands were of the 'uintptr_t' type.  That is, they are not
       scaled by the size of the type to which the pointer points.
  
            { tmp = *ptr; *ptr OP= value; return tmp; }
--- 46766,46772 ----
       name, and returns the value that had previously been in memory.
       That is, operations on integer operands have the following
       semantics.  Operations on pointer arguments are performed as if the
!      operands were of the ‘uintptr_t’ type.  That is, they are not
       scaled by the size of the type to which the pointer points.
  
            { tmp = *ptr; *ptr OP= value; return tmp; }
*************** variables should be protected.
*** 46766,46773 ****
       The object pointed to by the first argument must be of integer or
       pointer type.  It must not be a boolean type.
  
!      _Note:_ GCC 4.4 and later implement '__sync_fetch_and_nand' as
!      '*ptr = ~(tmp & value)' instead of '*ptr = ~tmp & value'.
  
   -- Built-in Function: TYPE __sync_add_and_fetch (TYPE *PTR, TYPE VALUE,
            ...)
--- 46775,46782 ----
       The object pointed to by the first argument must be of integer or
       pointer type.  It must not be a boolean type.
  
!      _Note:_ GCC 4.4 and later implement ‘__sync_fetch_and_nand’ as
!      ‘*ptr = ~(tmp & value)’ instead of ‘*ptr = ~tmp & value’.
  
   -- Built-in Function: TYPE __sync_add_and_fetch (TYPE *PTR, TYPE VALUE,
            ...)
*************** variables should be protected.
*** 46784,46811 ****
       These built-in functions perform the operation suggested by the
       name, and return the new value.  That is, operations on integer
       operands have the following semantics.  Operations on pointer
!      operands are performed as if the operand's type were 'uintptr_t'.
  
            { *ptr OP= value; return *ptr; }
            { *ptr = ~(*ptr & value); return *ptr; }   // nand
  
       The same constraints on arguments apply as for the corresponding
!      '__sync_op_and_fetch' built-in functions.
  
!      _Note:_ GCC 4.4 and later implement '__sync_nand_and_fetch' as
!      '*ptr = ~(*ptr & value)' instead of '*ptr = ~*ptr & value'.
  
   -- Built-in Function: bool __sync_bool_compare_and_swap (TYPE *PTR,
            TYPE OLDVAL, TYPE NEWVAL, ...)
   -- Built-in Function: TYPE __sync_val_compare_and_swap (TYPE *PTR, TYPE
            OLDVAL, TYPE NEWVAL, ...)
       These built-in functions perform an atomic compare and swap.  That
!      is, if the current value of '*PTR' is OLDVAL, then write NEWVAL
!      into '*PTR'.
  
!      The "bool" version returns 'true' if the comparison is successful
       and NEWVAL is written.  The "val" version returns the contents of
!      '*PTR' before the operation.
  
   -- Built-in Function: void __sync_synchronize (...)
       This built-in function issues a full memory barrier.
--- 46793,46820 ----
       These built-in functions perform the operation suggested by the
       name, and return the new value.  That is, operations on integer
       operands have the following semantics.  Operations on pointer
!      operands are performed as if the operand's type were ‘uintptr_t’.
  
            { *ptr OP= value; return *ptr; }
            { *ptr = ~(*ptr & value); return *ptr; }   // nand
  
       The same constraints on arguments apply as for the corresponding
!      ‘__sync_op_and_fetch’ built-in functions.
  
!      _Note:_ GCC 4.4 and later implement ‘__sync_nand_and_fetch’ as
!      ‘*ptr = ~(*ptr & value)’ instead of ‘*ptr = ~*ptr & value’.
  
   -- Built-in Function: bool __sync_bool_compare_and_swap (TYPE *PTR,
            TYPE OLDVAL, TYPE NEWVAL, ...)
   -- Built-in Function: TYPE __sync_val_compare_and_swap (TYPE *PTR, TYPE
            OLDVAL, TYPE NEWVAL, ...)
       These built-in functions perform an atomic compare and swap.  That
!      is, if the current value of ‘*PTR’ is OLDVAL, then write NEWVAL
!      into ‘*PTR’.
  
!      The "bool" version returns ‘true’ if the comparison is successful
       and NEWVAL is written.  The "val" version returns the contents of
!      ‘*PTR’ before the operation.
  
   -- Built-in Function: void __sync_synchronize (...)
       This built-in function issues a full memory barrier.
*************** variables should be protected.
*** 46814,46841 ****
            VALUE, ...)
       This built-in function, as described by Intel, is not a traditional
       test-and-set operation, but rather an atomic exchange operation.
!      It writes VALUE into '*PTR', and returns the previous contents of
!      '*PTR'.
  
       Many targets have only minimal support for such locks, and do not
       support a full exchange operation.  In this case, a target may
       support reduced functionality here by which the _only_ valid value
       to store is the immediate constant 1.  The exact value actually
!      stored in '*PTR' is implementation defined.
  
       This built-in function is not a full barrier, but rather an
!      "acquire barrier".  This means that references after the operation
       cannot move to (or be speculated to) before the operation, but
       previous memory stores may not be globally visible yet, and
       previous memory loads may not yet be satisfied.
  
   -- Built-in Function: void __sync_lock_release (TYPE *PTR, ...)
       This built-in function releases the lock acquired by
!      '__sync_lock_test_and_set'.  Normally this means writing the
!      constant 0 to '*PTR'.
  
!      This built-in function is not a full barrier, but rather a "release
!      barrier".  This means that all previous memory stores are globally
       visible, and all previous memory loads have been satisfied, but
       following memory reads are not prevented from being speculated to
       before the barrier.
--- 46823,46850 ----
            VALUE, ...)
       This built-in function, as described by Intel, is not a traditional
       test-and-set operation, but rather an atomic exchange operation.
!      It writes VALUE into ‘*PTR’, and returns the previous contents of
!      ‘*PTR’.
  
       Many targets have only minimal support for such locks, and do not
       support a full exchange operation.  In this case, a target may
       support reduced functionality here by which the _only_ valid value
       to store is the immediate constant 1.  The exact value actually
!      stored in ‘*PTR’ is implementation defined.
  
       This built-in function is not a full barrier, but rather an
!      “acquire barrier”.  This means that references after the operation
       cannot move to (or be speculated to) before the operation, but
       previous memory stores may not be globally visible yet, and
       previous memory loads may not yet be satisfied.
  
   -- Built-in Function: void __sync_lock_release (TYPE *PTR, ...)
       This built-in function releases the lock acquired by
!      ‘__sync_lock_test_and_set’.  Normally this means writing the
!      constant 0 to ‘*PTR’.
  
!      This built-in function is not a full barrier, but rather a “release
!      barrier”.  This means that all previous memory stores are globally
       visible, and all previous memory loads have been satisfied, but
       following memory reads are not prevented from being speculated to
       before the barrier.
*************** File: gcc.info,  Node: __atomic Builtins
*** 46848,46868 ****
  
  The following built-in functions approximately match the requirements
  for the C++11 memory model.  They are all identified by being prefixed
! with '__atomic' and most are overloaded so that they work with multiple
  types.
  
!  These functions are intended to replace the legacy '__sync' builtins.
  The main difference is that the memory order that is requested is a
! parameter to the functions.  New code should always use the '__atomic'
! builtins rather than the '__sync' builtins.
  
!  Note that the '__atomic' builtins assume that programs will conform to
  the C++11 memory model.  In particular, they assume that programs are
  free of data races.  See the C++11 standard for detailed requirements.
  
!  The '__atomic' builtins can be used with any integral scalar or pointer
  type that is 1, 2, 4, or 8 bytes in length.  16-byte integral types are
! also allowed if '__int128' (*note __int128::) is supported by the
  architecture.
  
   The four non-arithmetic functions (load, store, exchange, and
--- 46857,46877 ----
  
  The following built-in functions approximately match the requirements
  for the C++11 memory model.  They are all identified by being prefixed
! with ‘__atomic’ and most are overloaded so that they work with multiple
  types.
  
!  These functions are intended to replace the legacy ‘__sync’ builtins.
  The main difference is that the memory order that is requested is a
! parameter to the functions.  New code should always use the ‘__atomic’
! builtins rather than the ‘__sync’ builtins.
  
!  Note that the ‘__atomic’ builtins assume that programs will conform to
  the C++11 memory model.  In particular, they assume that programs are
  free of data races.  See the C++11 standard for detailed requirements.
  
!  The ‘__atomic’ builtins can be used with any integral scalar or pointer
  type that is 1, 2, 4, or 8 bytes in length.  16-byte integral types are
! also allowed if ‘__int128’ (*note __int128::) is supported by the
  architecture.
  
   The four non-arithmetic functions (load, store, exchange, and
*************** compare_exchange) all have a generic ver
*** 46870,46876 ****
  version works on any data type.  It uses the lock-free built-in function
  if the specific data type size makes that possible; otherwise, an
  external call is left to be resolved at run time.  This external call is
! the same format with the addition of a 'size_t' parameter inserted as
  the first parameter indicating the size of the object being pointed to.
  All objects must be the same size.
  
--- 46879,46885 ----
  version works on any data type.  It uses the lock-free built-in function
  if the specific data type size makes that possible; otherwise, an
  external call is left to be resolved at run time.  This external call is
! the same format with the addition of a ‘size_t’ parameter inserted as
  the first parameter indicating the size of the object being pointed to.
  All objects must be the same size.
  
*************** strength.  The description of each memor
*** 46890,46925 ****
  illustrate the effects and is not a specification; see the C++11 memory
  model for precise semantics.
  
! '__ATOMIC_RELAXED'
       Implies no inter-thread ordering constraints.
! '__ATOMIC_CONSUME'
!      This is currently implemented using the stronger '__ATOMIC_ACQUIRE'
       memory order because of a deficiency in C++11's semantics for
!      'memory_order_consume'.
! '__ATOMIC_ACQUIRE'
       Creates an inter-thread happens-before constraint from the release
       (or stronger) semantic store to this acquire load.  Can prevent
       hoisting of code to before the operation.
! '__ATOMIC_RELEASE'
       Creates an inter-thread happens-before constraint to acquire (or
       stronger) semantic loads that read from this release store.  Can
       prevent sinking of code to after the operation.
! '__ATOMIC_ACQ_REL'
!      Combines the effects of both '__ATOMIC_ACQUIRE' and
!      '__ATOMIC_RELEASE'.
! '__ATOMIC_SEQ_CST'
!      Enforces total ordering with all other '__ATOMIC_SEQ_CST'
       operations.
  
   Note that in the C++11 memory model, _fences_ (e.g.,
! '__atomic_thread_fence') take effect in combination with other atomic
  operations on specific memory locations (e.g., atomic loads); operations
  on specific memory locations do not necessarily affect other operations
  in the same way.
  
   Target architectures are encouraged to provide their own patterns for
  each of the atomic built-in functions.  If no target is provided, the
! original non-memory model set of '__sync' atomic built-in functions are
  used, along with any required synchronization fences surrounding it in
  order to achieve the proper behavior.  Execution in this case is subject
  to the same restrictions as those built-in functions.
--- 46899,46934 ----
  illustrate the effects and is not a specification; see the C++11 memory
  model for precise semantics.
  
! ‘__ATOMIC_RELAXED’
       Implies no inter-thread ordering constraints.
! ‘__ATOMIC_CONSUME’
!      This is currently implemented using the stronger ‘__ATOMIC_ACQUIRE’
       memory order because of a deficiency in C++11's semantics for
!      ‘memory_order_consume’.
! ‘__ATOMIC_ACQUIRE’
       Creates an inter-thread happens-before constraint from the release
       (or stronger) semantic store to this acquire load.  Can prevent
       hoisting of code to before the operation.
! ‘__ATOMIC_RELEASE’
       Creates an inter-thread happens-before constraint to acquire (or
       stronger) semantic loads that read from this release store.  Can
       prevent sinking of code to after the operation.
! ‘__ATOMIC_ACQ_REL’
!      Combines the effects of both ‘__ATOMIC_ACQUIRE’ and
!      ‘__ATOMIC_RELEASE’.
! ‘__ATOMIC_SEQ_CST’
!      Enforces total ordering with all other ‘__ATOMIC_SEQ_CST’
       operations.
  
   Note that in the C++11 memory model, _fences_ (e.g.,
! ‘__atomic_thread_fence’) take effect in combination with other atomic
  operations on specific memory locations (e.g., atomic loads); operations
  on specific memory locations do not necessarily affect other operations
  in the same way.
  
   Target architectures are encouraged to provide their own patterns for
  each of the atomic built-in functions.  If no target is provided, the
! original non-memory model set of ‘__sync’ atomic built-in functions are
  used, along with any required synchronization fences surrounding it in
  order to achieve the proper behavior.  Execution in this case is subject
  to the same restrictions as those built-in functions.
*************** to be resolved at run time.
*** 46930,46943 ****
  
   When implementing patterns for these built-in functions, the memory
  order parameter can be ignored as long as the pattern implements the
! most restrictive '__ATOMIC_SEQ_CST' memory order.  Any of the other
  memory orders execute correctly with this memory order but they may not
  execute as efficiently as they could with a more appropriate
  implementation of the relaxed requirements.
  
   Note that the C++11 standard allows for the memory order parameter to
  be determined at run time rather than at compile time.  These built-in
! functions map any run-time value to '__ATOMIC_SEQ_CST' rather than
  invoke a runtime library call or inline a switch statement.  This is
  standard compliant, safe, and the simplest approach for now.
  
--- 46939,46952 ----
  
   When implementing patterns for these built-in functions, the memory
  order parameter can be ignored as long as the pattern implements the
! most restrictive ‘__ATOMIC_SEQ_CST’ memory order.  Any of the other
  memory orders execute correctly with this memory order but they may not
  execute as efficiently as they could with a more appropriate
  implementation of the relaxed requirements.
  
   Note that the C++11 standard allows for the memory order parameter to
  be determined at run time rather than at compile time.  These built-in
! functions map any run-time value to ‘__ATOMIC_SEQ_CST’ rather than
  invoke a runtime library call or inline a switch statement.  This is
  standard compliant, safe, and the simplest approach for now.
  
*************** values ensures proper usage.
*** 46948,47020 ****
  
   -- Built-in Function: TYPE __atomic_load_n (TYPE *PTR, int MEMORDER)
       This built-in function implements an atomic load operation.  It
!      returns the contents of '*PTR'.
  
!      The valid memory order variants are '__ATOMIC_RELAXED',
!      '__ATOMIC_SEQ_CST', '__ATOMIC_ACQUIRE', and '__ATOMIC_CONSUME'.
  
   -- Built-in Function: void __atomic_load (TYPE *PTR, TYPE *RET, int
            MEMORDER)
       This is the generic version of an atomic load.  It returns the
!      contents of '*PTR' in '*RET'.
  
   -- Built-in Function: void __atomic_store_n (TYPE *PTR, TYPE VAL, int
            MEMORDER)
       This built-in function implements an atomic store operation.  It
!      writes 'VAL' into '*PTR'.
  
!      The valid memory order variants are '__ATOMIC_RELAXED',
!      '__ATOMIC_SEQ_CST', and '__ATOMIC_RELEASE'.
  
   -- Built-in Function: void __atomic_store (TYPE *PTR, TYPE *VAL, int
            MEMORDER)
       This is the generic version of an atomic store.  It stores the
!      value of '*VAL' into '*PTR'.
  
   -- Built-in Function: TYPE __atomic_exchange_n (TYPE *PTR, TYPE VAL,
            int MEMORDER)
       This built-in function implements an atomic exchange operation.  It
!      writes VAL into '*PTR', and returns the previous contents of
!      '*PTR'.
  
       All memory order variants are valid.
  
   -- Built-in Function: void __atomic_exchange (TYPE *PTR, TYPE *VAL,
            TYPE *RET, int MEMORDER)
       This is the generic version of an atomic exchange.  It stores the
!      contents of '*VAL' into '*PTR'.  The original value of '*PTR' is
!      copied into '*RET'.
  
   -- Built-in Function: bool __atomic_compare_exchange_n (TYPE *PTR, TYPE
            *EXPECTED, TYPE DESIRED, bool WEAK, int SUCCESS_MEMORDER, int
            FAILURE_MEMORDER)
       This built-in function implements an atomic compare and exchange
!      operation.  This compares the contents of '*PTR' with the contents
!      of '*EXPECTED'.  If equal, the operation is a _read-modify-write_
!      operation that writes DESIRED into '*PTR'.  If they are not equal,
!      the operation is a _read_ and the current contents of '*PTR' are
!      written into '*EXPECTED'.  WEAK is 'true' for weak
!      compare_exchange, which may fail spuriously, and 'false' for the
       strong variation, which never fails spuriously.  Many targets only
       offer the strong variation and ignore the parameter.  When in
       doubt, use the strong variation.
  
!      If DESIRED is written into '*PTR' then 'true' is returned and
       memory is affected according to the memory order specified by
       SUCCESS_MEMORDER.  There are no restrictions on what memory order
       can be used here.
  
!      Otherwise, 'false' is returned and memory is affected according to
!      FAILURE_MEMORDER.  This memory order cannot be '__ATOMIC_RELEASE'
!      nor '__ATOMIC_ACQ_REL'.  It also cannot be a stronger order than
       that specified by SUCCESS_MEMORDER.
  
   -- Built-in Function: bool __atomic_compare_exchange (TYPE *PTR, TYPE
            *EXPECTED, TYPE *DESIRED, bool WEAK, int SUCCESS_MEMORDER, int
            FAILURE_MEMORDER)
       This built-in function implements the generic version of
!      '__atomic_compare_exchange'.  The function is virtually identical
!      to '__atomic_compare_exchange_n', except the desired value is also
       a pointer.
  
   -- Built-in Function: TYPE __atomic_add_fetch (TYPE *PTR, TYPE VAL, int
--- 46957,47029 ----
  
   -- Built-in Function: TYPE __atomic_load_n (TYPE *PTR, int MEMORDER)
       This built-in function implements an atomic load operation.  It
!      returns the contents of ‘*PTR’.
  
!      The valid memory order variants are ‘__ATOMIC_RELAXED’,
!      ‘__ATOMIC_SEQ_CST’, ‘__ATOMIC_ACQUIRE’, and ‘__ATOMIC_CONSUME’.
  
   -- Built-in Function: void __atomic_load (TYPE *PTR, TYPE *RET, int
            MEMORDER)
       This is the generic version of an atomic load.  It returns the
!      contents of ‘*PTR’ in ‘*RET’.
  
   -- Built-in Function: void __atomic_store_n (TYPE *PTR, TYPE VAL, int
            MEMORDER)
       This built-in function implements an atomic store operation.  It
!      writes ‘VAL’ into ‘*PTR’.
  
!      The valid memory order variants are ‘__ATOMIC_RELAXED’,
!      ‘__ATOMIC_SEQ_CST’, and ‘__ATOMIC_RELEASE’.
  
   -- Built-in Function: void __atomic_store (TYPE *PTR, TYPE *VAL, int
            MEMORDER)
       This is the generic version of an atomic store.  It stores the
!      value of ‘*VAL’ into ‘*PTR’.
  
   -- Built-in Function: TYPE __atomic_exchange_n (TYPE *PTR, TYPE VAL,
            int MEMORDER)
       This built-in function implements an atomic exchange operation.  It
!      writes VAL into ‘*PTR’, and returns the previous contents of
!      ‘*PTR’.
  
       All memory order variants are valid.
  
   -- Built-in Function: void __atomic_exchange (TYPE *PTR, TYPE *VAL,
            TYPE *RET, int MEMORDER)
       This is the generic version of an atomic exchange.  It stores the
!      contents of ‘*VAL’ into ‘*PTR’.  The original value of ‘*PTR’ is
!      copied into ‘*RET’.
  
   -- Built-in Function: bool __atomic_compare_exchange_n (TYPE *PTR, TYPE
            *EXPECTED, TYPE DESIRED, bool WEAK, int SUCCESS_MEMORDER, int
            FAILURE_MEMORDER)
       This built-in function implements an atomic compare and exchange
!      operation.  This compares the contents of ‘*PTR’ with the contents
!      of ‘*EXPECTED’.  If equal, the operation is a _read-modify-write_
!      operation that writes DESIRED into ‘*PTR’.  If they are not equal,
!      the operation is a _read_ and the current contents of ‘*PTR’ are
!      written into ‘*EXPECTED’.  WEAK is ‘true’ for weak
!      compare_exchange, which may fail spuriously, and ‘false’ for the
       strong variation, which never fails spuriously.  Many targets only
       offer the strong variation and ignore the parameter.  When in
       doubt, use the strong variation.
  
!      If DESIRED is written into ‘*PTR’ then ‘true’ is returned and
       memory is affected according to the memory order specified by
       SUCCESS_MEMORDER.  There are no restrictions on what memory order
       can be used here.
  
!      Otherwise, ‘false’ is returned and memory is affected according to
!      FAILURE_MEMORDER.  This memory order cannot be ‘__ATOMIC_RELEASE’
!      nor ‘__ATOMIC_ACQ_REL’.  It also cannot be a stronger order than
       that specified by SUCCESS_MEMORDER.
  
   -- Built-in Function: bool __atomic_compare_exchange (TYPE *PTR, TYPE
            *EXPECTED, TYPE *DESIRED, bool WEAK, int SUCCESS_MEMORDER, int
            FAILURE_MEMORDER)
       This built-in function implements the generic version of
!      ‘__atomic_compare_exchange’.  The function is virtually identical
!      to ‘__atomic_compare_exchange_n’, except the desired value is also
       a pointer.
  
   -- Built-in Function: TYPE __atomic_add_fetch (TYPE *PTR, TYPE VAL, int
*************** values ensures proper usage.
*** 47032,47038 ****
       These built-in functions perform the operation suggested by the
       name, and return the result of the operation.  Operations on
       pointer arguments are performed as if the operands were of the
!      'uintptr_t' type.  That is, they are not scaled by the size of the
       type to which the pointer points.
  
            { *ptr OP= val; return *ptr; }
--- 47041,47047 ----
       These built-in functions perform the operation suggested by the
       name, and return the result of the operation.  Operations on
       pointer arguments are performed as if the operands were of the
!      ‘uintptr_t’ type.  That is, they are not scaled by the size of the
       type to which the pointer points.
  
            { *ptr OP= val; return *ptr; }
*************** values ensures proper usage.
*** 47055,47080 ****
   -- Built-in Function: TYPE __atomic_fetch_nand (TYPE *PTR, TYPE VAL,
            int MEMORDER)
       These built-in functions perform the operation suggested by the
!      name, and return the value that had previously been in '*PTR'.
       Operations on pointer arguments are performed as if the operands
!      were of the 'uintptr_t' type.  That is, they are not scaled by the
       size of the type to which the pointer points.
  
            { tmp = *ptr; *ptr OP= val; return tmp; }
            { tmp = *ptr; *ptr = ~(*ptr & val); return tmp; } // nand
  
       The same constraints on arguments apply as for the corresponding
!      '__atomic_op_fetch' built-in functions.  All memory orders are
       valid.
  
   -- Built-in Function: bool __atomic_test_and_set (void *PTR, int
            MEMORDER)
  
       This built-in function performs an atomic test-and-set operation on
!      the byte at '*PTR'.  The byte is set to some implementation defined
!      nonzero "set" value and the return value is 'true' if and only if
       the previous contents were "set".  It should be only used for
!      operands of type 'bool' or 'char'.  For other types only part of
       the value may be set.
  
       All memory orders are valid.
--- 47064,47089 ----
   -- Built-in Function: TYPE __atomic_fetch_nand (TYPE *PTR, TYPE VAL,
            int MEMORDER)
       These built-in functions perform the operation suggested by the
!      name, and return the value that had previously been in ‘*PTR’.
       Operations on pointer arguments are performed as if the operands
!      were of the ‘uintptr_t’ type.  That is, they are not scaled by the
       size of the type to which the pointer points.
  
            { tmp = *ptr; *ptr OP= val; return tmp; }
            { tmp = *ptr; *ptr = ~(*ptr & val); return tmp; } // nand
  
       The same constraints on arguments apply as for the corresponding
!      ‘__atomic_op_fetch’ built-in functions.  All memory orders are
       valid.
  
   -- Built-in Function: bool __atomic_test_and_set (void *PTR, int
            MEMORDER)
  
       This built-in function performs an atomic test-and-set operation on
!      the byte at ‘*PTR’.  The byte is set to some implementation defined
!      nonzero "set" value and the return value is ‘true’ if and only if
       the previous contents were "set".  It should be only used for
!      operands of type ‘bool’ or ‘char’.  For other types only part of
       the value may be set.
  
       All memory orders are valid.
*************** values ensures proper usage.
*** 47082,47095 ****
   -- Built-in Function: void __atomic_clear (bool *PTR, int MEMORDER)
  
       This built-in function performs an atomic clear operation on
!      '*PTR'.  After the operation, '*PTR' contains 0.  It should be only
!      used for operands of type 'bool' or 'char' and in conjunction with
!      '__atomic_test_and_set'.  For other types it may only clear
!      partially.  If the type is not 'bool' prefer using
!      '__atomic_store'.
  
!      The valid memory order variants are '__ATOMIC_RELAXED',
!      '__ATOMIC_SEQ_CST', and '__ATOMIC_RELEASE'.
  
   -- Built-in Function: void __atomic_thread_fence (int MEMORDER)
  
--- 47091,47104 ----
   -- Built-in Function: void __atomic_clear (bool *PTR, int MEMORDER)
  
       This built-in function performs an atomic clear operation on
!      ‘*PTR’.  After the operation, ‘*PTR’ contains 0.  It should be only
!      used for operands of type ‘bool’ or ‘char’ and in conjunction with
!      ‘__atomic_test_and_set’.  For other types it may only clear
!      partially.  If the type is not ‘bool’ prefer using
!      ‘__atomic_store’.
  
!      The valid memory order variants are ‘__ATOMIC_RELAXED’,
!      ‘__ATOMIC_SEQ_CST’, and ‘__ATOMIC_RELEASE’.
  
   -- Built-in Function: void __atomic_thread_fence (int MEMORDER)
  
*************** values ensures proper usage.
*** 47108,47114 ****
   -- Built-in Function: bool __atomic_always_lock_free (size_t SIZE, void
            *PTR)
  
!      This built-in function returns 'true' if objects of SIZE bytes
       always generate lock-free atomic instructions for the target
       architecture.  SIZE must resolve to a compile-time constant and the
       result also resolves to a compile-time constant.
--- 47117,47123 ----
   -- Built-in Function: bool __atomic_always_lock_free (size_t SIZE, void
            *PTR)
  
!      This built-in function returns ‘true’ if objects of SIZE bytes
       always generate lock-free atomic instructions for the target
       architecture.  SIZE must resolve to a compile-time constant and the
       result also resolves to a compile-time constant.
*************** values ensures proper usage.
*** 47122,47132 ****
   -- Built-in Function: bool __atomic_is_lock_free (size_t SIZE, void
            *PTR)
  
!      This built-in function returns 'true' if objects of SIZE bytes
       always generate lock-free atomic instructions for the target
       architecture.  If the built-in function is not known to be
       lock-free, a call is made to a runtime routine named
!      '__atomic_is_lock_free'.
  
       PTR is an optional pointer to the object that may be used to
       determine alignment.  A value of 0 indicates typical alignment
--- 47131,47141 ----
   -- Built-in Function: bool __atomic_is_lock_free (size_t SIZE, void
            *PTR)
  
!      This built-in function returns ‘true’ if objects of SIZE bytes
       always generate lock-free atomic instructions for the target
       architecture.  If the built-in function is not known to be
       lock-free, a call is made to a runtime routine named
!      ‘__atomic_is_lock_free’.
  
       PTR is an optional pointer to the object that may be used to
       determine alignment.  A value of 0 indicates typical alignment
*************** operations together with checking whethe
*** 47162,47168 ****
       promoted operands.  The result is then cast to the type the third
       pointer argument points to and stored there.  If the stored result
       is equal to the infinite precision result, the built-in functions
!      return 'false', otherwise they return 'true'.  As the addition is
       performed in infinite signed precision, these built-in functions
       have fully defined behavior for all argument values.
  
--- 47171,47177 ----
       promoted operands.  The result is then cast to the type the third
       pointer argument points to and stored there.  If the stored result
       is equal to the infinite precision result, the built-in functions
!      return ‘false’, otherwise they return ‘true’.  As the addition is
       performed in infinite signed precision, these built-in functions
       have fully defined behavior for all argument values.
  
*************** operation would overflow.
*** 47225,47232 ****
   -- Built-in Function: bool __builtin_mul_overflow_p (TYPE1 A, TYPE2 B,
            TYPE3 C)
  
!      These built-in functions are similar to '__builtin_add_overflow',
!      '__builtin_sub_overflow', or '__builtin_mul_overflow', except that
       they don't store the result of the arithmetic operation anywhere
       and the last argument is not a pointer, but some expression with
       integral type other than enumerated or boolean type.
--- 47234,47241 ----
   -- Built-in Function: bool __builtin_mul_overflow_p (TYPE1 A, TYPE2 B,
            TYPE3 C)
  
!      These built-in functions are similar to ‘__builtin_add_overflow’,
!      ‘__builtin_sub_overflow’, or ‘__builtin_mul_overflow’, except that
       they don't store the result of the arithmetic operation anywhere
       and the last argument is not a pointer, but some expression with
       integral type other than enumerated or boolean type.
*************** operation would overflow.
*** 47235,47242 ****
       precision signed type and perform addition on those promoted
       operands.  The result is then cast to the type of the third
       argument.  If the cast result is equal to the infinite precision
!      result, the built-in functions return 'false', otherwise they
!      return 'true'.  The value of the third argument is ignored, just
       the side effects in the third argument are evaluated, and no
       integral argument promotions are performed on the last argument.
       If the third argument is a bit-field, the type used for the result
--- 47244,47251 ----
       precision signed type and perform addition on those promoted
       operands.  The result is then cast to the type of the third
       argument.  If the cast result is equal to the infinite precision
!      result, the built-in functions return ‘false’, otherwise they
!      return ‘true’.  The value of the third argument is ignored, just
       the side effects in the third argument are evaluated, and no
       integral argument promotions are performed on the last argument.
       If the third argument is a bit-field, the type used for the result
*************** operation would overflow.
*** 47246,47252 ****
       For example, the following macro can be used to portably check, at
       compile-time, whether or not adding two constant integers will
       overflow, and perform the addition only when it is known to be safe
!      and not to trigger a '-Woverflow' warning.
  
            #define INT_ADD_OVERFLOW_P(a, b) \
               __builtin_add_overflow_p (a, b, (__typeof__ ((a) + (b))) 0)
--- 47255,47261 ----
       For example, the following macro can be used to portably check, at
       compile-time, whether or not adding two constant integers will
       overflow, and perform the addition only when it is known to be safe
!      and not to trigger a ‘-Woverflow’ warning.
  
            #define INT_ADD_OVERFLOW_P(a, b) \
               __builtin_add_overflow_p (a, b, (__typeof__ ((a) + (b))) 0)
*************** The x86 architecture supports additional
*** 47271,47285 ****
  critical sections for hardware lock elision.  These must be specified in
  addition to an existing memory order to atomic intrinsics.
  
! '__ATOMIC_HLE_ACQUIRE'
       Start lock elision on a lock variable.  Memory order must be
!      '__ATOMIC_ACQUIRE' or stronger.
! '__ATOMIC_HLE_RELEASE'
       End lock elision on a lock variable.  Memory order must be
!      '__ATOMIC_RELEASE' or stronger.
  
   When a lock acquire fails, it is required for good performance to abort
! the transaction quickly.  This can be done with a '_mm_pause'.
  
       #include  // For _mm_pause
  
--- 47280,47294 ----
  critical sections for hardware lock elision.  These must be specified in
  addition to an existing memory order to atomic intrinsics.
  
! ‘__ATOMIC_HLE_ACQUIRE’
       Start lock elision on a lock variable.  Memory order must be
!      ‘__ATOMIC_ACQUIRE’ or stronger.
! ‘__ATOMIC_HLE_RELEASE’
       End lock elision on a lock variable.  Memory order must be
!      ‘__ATOMIC_RELEASE’ or stronger.
  
   When a lock acquire fails, it is required for good performance to abort
! the transaction quickly.  This can be done with a ‘_mm_pause’.
  
       #include  // For _mm_pause
  
*************** the size isn't sufficient.  The built-in
*** 47308,47314 ****
  the best results when used together and when optimization is enabled.
  For example, to detect object sizes across function boundaries or to
  follow pointer assignments through non-trivial control flow they rely on
! various optimization passes enabled with '-O2'.  However, to a limited
  extent, they can be used without optimization as well.
  
   -- Built-in Function: size_t __builtin_object_size (const void * PTR,
--- 47317,47323 ----
  the best results when used together and when optimization is enabled.
  For example, to detect object sizes across function boundaries or to
  follow pointer assignments through non-trivial control flow they rely on
! various optimization passes enabled with ‘-O2’.  However, to a limited
  extent, they can be used without optimization as well.
  
   -- Built-in Function: size_t __builtin_object_size (const void * PTR,
*************** extent, they can be used without optimiz
*** 47317,47333 ****
       from PTR to the end of the object PTR pointer points to (if known
       at compile time).  To determine the sizes of dynamically allocated
       objects the function relies on the allocation functions called to
!      obtain the storage to be declared with the 'alloc_size' attribute
!      (*note Common Function Attributes::).  '__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
--- 47326,47342 ----
       from PTR to the end of the object PTR pointer points to (if known
       at compile time).  To determine the sizes of dynamically allocated
       objects the function relies on the allocation functions called to
!      obtain the storage to be declared with the ‘alloc_size’ attribute
!      (*note Common Function Attributes::).  ‘__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
*************** extent, they can be used without optimiz
*** 47350,47381 ****
  
   -- Built-in Function: size_t __builtin_dynamic_object_size (const void
            * PTR, int TYPE)
!      is similar to '__builtin_object_size' in that it returns a number
       of bytes from PTR to the end of the object PTR pointer points to,
       except that the size returned may not be a constant.  This results
       in successful evaluation of object size estimates in a wider range
!      of use cases and can be more precise than '__builtin_object_size',
       but it incurs a performance penalty since it may add a runtime
       overhead on size computation.  Semantics of TYPE as well as return
       values in case it is not possible to determine which objects PTR
       points to at compile time are the same as in the case of
!      '__builtin_object_size'.
  
  6.58.2 Object Size Checking and Source Fortification
  ----------------------------------------------------
  
! Hardening of function calls using the '_FORTIFY_SOURCE' macro is one of
  the key uses of the object size checking built-in functions.  To make
  implementation of these features more convenient and improve
  optimization and diagnostics, 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 the
! 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 overflowed.  If the
  compiler can determine at compile time that the object will always be
  overflowed, it issues a warning.
--- 47359,47390 ----
  
   -- Built-in Function: size_t __builtin_dynamic_object_size (const void
            * PTR, int TYPE)
!      is similar to ‘__builtin_object_size’ in that it returns a number
       of bytes from PTR to the end of the object PTR pointer points to,
       except that the size returned may not be a constant.  This results
       in successful evaluation of object size estimates in a wider range
!      of use cases and can be more precise than ‘__builtin_object_size’,
       but it incurs a performance penalty since it may add a runtime
       overhead on size computation.  Semantics of TYPE as well as return
       values in case it is not possible to determine which objects PTR
       points to at compile time are the same as in the case of
!      ‘__builtin_object_size’.
  
  6.58.2 Object Size Checking and Source Fortification
  ----------------------------------------------------
  
! Hardening of function calls using the ‘_FORTIFY_SOURCE’ macro is one of
  the key uses of the object size checking built-in functions.  To make
  implementation of these features more convenient and improve
  optimization and diagnostics, 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 the
! 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 overflowed.  If the
  compiler can determine at compile time that the object will always be
  overflowed, it issues a warning.
*************** overflowed, it issues a warning.
*** 47404,47412 ****
          will abort the program at run time.  */
       memcpy (&buf[6], "abcde", 5);
  
!  Such built-in functions are provided for 'memcpy', 'mempcpy',
! 'memmove', 'memset', 'strcpy', 'stpcpy', 'strncpy', 'strcat' and
! 'strncat'.
  
  6.58.2.1 Formatted Output Function Checking
  ...........................................
--- 47413,47421 ----
          will abort the program at run time.  */
       memcpy (&buf[6], "abcde", 5);
  
!  Such built-in functions are provided for ‘memcpy’, ‘mempcpy’,
! ‘memmove’, ‘memset’, ‘strcpy’, ‘stpcpy’, ‘strncpy’, ‘strcat’ and
! ‘strncat’.
  
  6.58.2.1 Formatted Output Function Checking
  ...........................................
*************** overflowed, it issues a warning.
*** 47420,47442 ****
   -- Built-in Function: int __builtin___vsnprintf_chk (char *S, size_t
            MAXLEN, int FLAG, size_t OS, const char *FMT, va_list AP)
  
!      The added FLAG argument is passed unchanged to '__sprintf_chk' etc.
       functions and can contain implementation specific flags on what
       additional security measures the checking function might take, such
!      as handling '%n' differently.
  
       The OS argument is the object size S points to, like in the other
       built-in functions.  There is a small difference in the behavior
!      though, if OS is '(size_t) -1', the built-in functions are
       optimized into the non-checking functions only if FLAG is 0,
       otherwise the checking function is called with OS argument set to
!      '(size_t) -1'.
  
       In addition to this, there are checking built-in functions
!      '__builtin___printf_chk', '__builtin___vprintf_chk',
!      '__builtin___fprintf_chk' and '__builtin___vfprintf_chk'.  These
       have just one additional argument, FLAG, right before format string
!      FMT.  If the compiler is able to optimize them to 'fputc' etc.
       functions, it does, otherwise the checking function is called and
       the FLAG argument passed to it.
  
--- 47429,47451 ----
   -- Built-in Function: int __builtin___vsnprintf_chk (char *S, size_t
            MAXLEN, int FLAG, size_t OS, const char *FMT, va_list AP)
  
!      The added FLAG argument is passed unchanged to ‘__sprintf_chk’ etc.
       functions and can contain implementation specific flags on what
       additional security measures the checking function might take, such
!      as handling ‘%n’ differently.
  
       The OS argument is the object size S points to, like in the other
       built-in functions.  There is a small difference in the behavior
!      though, if OS is ‘(size_t) -1’, the built-in functions are
       optimized into the non-checking functions only if FLAG is 0,
       otherwise the checking function is called with OS argument set to
!      ‘(size_t) -1’.
  
       In addition to this, there are checking built-in functions
!      ‘__builtin___printf_chk’, ‘__builtin___vprintf_chk’,
!      ‘__builtin___fprintf_chk’ and ‘__builtin___vfprintf_chk’.  These
       have just one additional argument, FLAG, right before format string
!      FMT.  If the compiler is able to optimize them to ‘fputc’ etc.
       functions, it does, otherwise the checking function is called and
       the FLAG argument passed to it.
  
*************** call results in a compile-time error.
*** 47463,47598 ****
  
   GCC includes built-in versions of many of the functions in the standard
  C library.  These functions come in two forms: one whose names start
! with the '__builtin_' prefix, and the other without.  Both forms have
  the same type (including prototype), the same address (when their
  address is taken), and the same meaning as the C library functions even
! if you specify the '-fno-builtin' option *note C Dialect Options::).
  Many of these functions are only optimized in certain cases; if they are
  not optimized in a particular case, a call to the library function is
  emitted.
  
!  Outside strict ISO C mode ('-ansi', '-std=c90', '-std=c99' or
! '-std=c11'), the functions '_exit', 'alloca', 'bcmp', 'bzero',
! 'dcgettext', 'dgettext', 'dremf', 'dreml', 'drem', 'exp10f', 'exp10l',
! 'exp10', 'ffsll', 'ffsl', 'ffs', 'fprintf_unlocked', 'fputs_unlocked',
! 'gammaf', 'gammal', 'gamma', 'gammaf_r', 'gammal_r', 'gamma_r',
! 'gettext', 'index', 'isascii', 'j0f', 'j0l', 'j0', 'j1f', 'j1l', 'j1',
! 'jnf', 'jnl', 'jn', 'lgammaf_r', 'lgammal_r', 'lgamma_r', 'mempcpy',
! 'pow10f', 'pow10l', 'pow10', 'printf_unlocked', 'rindex', 'roundeven',
! 'roundevenf', 'roundevenl', 'scalbf', 'scalbl', 'scalb', 'signbit',
! 'signbitf', 'signbitl', 'signbitd32', 'signbitd64', 'signbitd128',
! 'significandf', 'significandl', 'significand', 'sincosf', 'sincosl',
! 'sincos', 'stpcpy', 'stpncpy', 'strcasecmp', 'strdup', 'strfmon',
! 'strncasecmp', 'strndup', 'strnlen', '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', 'modff', '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_'.
  
!  There are also built-in functions '__builtin_fabsfN',
! '__builtin_fabsfNx', '__builtin_copysignfN' and '__builtin_copysignfNx',
! corresponding to the TS 18661-3 functions 'fabsfN', 'fabsfNx',
! 'copysignfN' and 'copysignfNx', for supported types '_FloatN' and
! '_FloatNx'.
  
!  There are also GNU extension functions 'clog10', 'clog10f' and
! 'clog10l' which names are reserved by ISO C99 for future use.  All these
! functions have 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', 'free', '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', 'realloc', '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',
! 'isnormal' and 'signbit' built-ins used with '__builtin_' prefixed.  The
! 'isinf' and 'isnan' built-in functions appear both with and without the
! '__builtin_' prefix.  With '-ffinite-math-only' option the 'isinf' and
! 'isnan' built-in functions will always return 0.
  
   GCC provides built-in versions of the ISO C99 floating-point rounding
! and exceptions handling functions 'fegetround', 'feclearexcept' and
! 'feraiseexcept'.  They may not be available for all targets, and because
  they need close interaction with libc internal values, they may not be
  available for all target libcs, but in all cases they will gracefully
  fallback to libc calls.  These built-in functions appear both with and
! without the '__builtin_' prefix.
  
   -- Built-in Function: void * __builtin_alloca (size_t SIZE)
!      The '__builtin_alloca' function must be called at block scope.  The
       function allocates an object SIZE bytes large on the stack of the
       calling function.  The object is aligned on the default stack
       alignment boundary for the target determined by the
!      '__BIGGEST_ALIGNMENT__' macro.  The '__builtin_alloca' function
       returns a pointer to the first byte of the allocated object.  The
       lifetime of the allocated object ends just before the calling
       function returns to its caller.  This is so even when
!      '__builtin_alloca' is called within a nested block.
  
!      For example, the following function allocates eight objects of 'n'
       bytes each on the stack, storing a pointer to each in consecutive
!      elements of the array 'a'.  It then passes the array to function
!      'g' which can safely use the storage pointed to by each of the
       array elements.
  
            void f (unsigned n)
--- 47472,47607 ----
  
   GCC includes built-in versions of many of the functions in the standard
  C library.  These functions come in two forms: one whose names start
! with the ‘__builtin_’ prefix, and the other without.  Both forms have
  the same type (including prototype), the same address (when their
  address is taken), and the same meaning as the C library functions even
! if you specify the ‘-fno-builtin’ option *note C Dialect Options::).
  Many of these functions are only optimized in certain cases; if they are
  not optimized in a particular case, a call to the library function is
  emitted.
  
!  Outside strict ISO C mode (‘-ansi’, ‘-std=c90’, ‘-std=c99’ or
! ‘-std=c11’), the functions ‘_exit’, ‘alloca’, ‘bcmp’, ‘bzero’,
! ‘dcgettext’, ‘dgettext’, ‘dremf’, ‘dreml’, ‘drem’, ‘exp10f’, ‘exp10l’,
! ‘exp10’, ‘ffsll’, ‘ffsl’, ‘ffs’, ‘fprintf_unlocked’, ‘fputs_unlocked’,
! ‘gammaf’, ‘gammal’, ‘gamma’, ‘gammaf_r’, ‘gammal_r’, ‘gamma_r’,
! ‘gettext’, ‘index’, ‘isascii’, ‘j0f’, ‘j0l’, ‘j0’, ‘j1f’, ‘j1l’, ‘j1’,
! ‘jnf’, ‘jnl’, ‘jn’, ‘lgammaf_r’, ‘lgammal_r’, ‘lgamma_r’, ‘mempcpy’,
! ‘pow10f’, ‘pow10l’, ‘pow10’, ‘printf_unlocked’, ‘rindex’, ‘roundeven’,
! ‘roundevenf’, ‘roundevenl’, ‘scalbf’, ‘scalbl’, ‘scalb’, ‘signbit’,
! ‘signbitf’, ‘signbitl’, ‘signbitd32’, ‘signbitd64’, ‘signbitd128’,
! ‘significandf’, ‘significandl’, ‘significand’, ‘sincosf’, ‘sincosl’,
! ‘sincos’, ‘stpcpy’, ‘stpncpy’, ‘strcasecmp’, ‘strdup’, ‘strfmon’,
! ‘strncasecmp’, ‘strndup’, ‘strnlen’, ‘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’, ‘modff’, ‘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_’.
  
!  There are also built-in functions ‘__builtin_fabsfN’,
! ‘__builtin_fabsfNx’, ‘__builtin_copysignfN’ and ‘__builtin_copysignfNx’,
! corresponding to the TS 18661-3 functions ‘fabsfN’, ‘fabsfNx’,
! ‘copysignfN’ and ‘copysignfNx’, for supported types ‘_FloatN’ and
! ‘_FloatNx’.
  
!  There are also GNU extension functions ‘clog10’, ‘clog10f’ and
! ‘clog10l’ which names are reserved by ISO C99 for future use.  All these
! functions have 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’, ‘free’, ‘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’, ‘realloc’, ‘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’,
! ‘isnormal’ and ‘signbit’ built-ins used with ‘__builtin_’ prefixed.  The
! ‘isinf’ and ‘isnan’ built-in functions appear both with and without the
! ‘__builtin_’ prefix.  With ‘-ffinite-math-only’ option the ‘isinf’ and
! ‘isnan’ built-in functions will always return 0.
  
   GCC provides built-in versions of the ISO C99 floating-point rounding
! and exceptions handling functions ‘fegetround’, ‘feclearexcept’ and
! ‘feraiseexcept’.  They may not be available for all targets, and because
  they need close interaction with libc internal values, they may not be
  available for all target libcs, but in all cases they will gracefully
  fallback to libc calls.  These built-in functions appear both with and
! without the ‘__builtin_’ prefix.
  
   -- Built-in Function: void * __builtin_alloca (size_t SIZE)
!      The ‘__builtin_alloca’ function must be called at block scope.  The
       function allocates an object SIZE bytes large on the stack of the
       calling function.  The object is aligned on the default stack
       alignment boundary for the target determined by the
!      ‘__BIGGEST_ALIGNMENT__’ macro.  The ‘__builtin_alloca’ function
       returns a pointer to the first byte of the allocated object.  The
       lifetime of the allocated object ends just before the calling
       function returns to its caller.  This is so even when
!      ‘__builtin_alloca’ is called within a nested block.
  
!      For example, the following function allocates eight objects of ‘n’
       bytes each on the stack, storing a pointer to each in consecutive
!      elements of the array ‘a’.  It then passes the array to function
!      ‘g’ which can safely use the storage pointed to by each of the
       array elements.
  
            void f (unsigned n)
*************** without the '__builtin_' prefix.
*** 47604,47613 ****
              g (a, n);   // safe
            }
  
!      Since the '__builtin_alloca' function doesn't validate its argument
       it is the responsibility of its caller to make sure the argument
       doesn't cause it to exceed the stack size limit.  The
!      '__builtin_alloca' function is provided to make it possible to
       allocate on the stack arrays of bytes with an upper bound that may
       be computed at run time.  Since C99 Variable Length Arrays offer
       similar functionality under a portable, more convenient, and safer
--- 47613,47622 ----
              g (a, n);   // safe
            }
  
!      Since the ‘__builtin_alloca’ function doesn't validate its argument
       it is the responsibility of its caller to make sure the argument
       doesn't cause it to exceed the stack size limit.  The
!      ‘__builtin_alloca’ function is provided to make it possible to
       allocate on the stack arrays of bytes with an upper bound that may
       be computed at run time.  Since C99 Variable Length Arrays offer
       similar functionality under a portable, more convenient, and safer
*************** without the '__builtin_' prefix.
*** 47617,47630 ****
  
   -- Built-in Function: void * __builtin_alloca_with_align (size_t SIZE,
            size_t ALIGNMENT)
!      The '__builtin_alloca_with_align' function must be called at block
       scope.  The function allocates an object SIZE bytes large on the
       stack of the calling function.  The allocated object is aligned on
       the boundary specified by the argument ALIGNMENT whose unit is
       given in bits (not bytes).  The SIZE argument must be positive and
       not exceed the stack size limit.  The ALIGNMENT argument must be a
       constant integer expression that evaluates to a power of 2 greater
!      than or equal to 'CHAR_BIT' and less than some unspecified maximum.
       Invocations with other values are rejected with an error indicating
       the valid bounds.  The function returns a pointer to the first byte
       of the allocated object.  The lifetime of the allocated object ends
--- 47626,47639 ----
  
   -- Built-in Function: void * __builtin_alloca_with_align (size_t SIZE,
            size_t ALIGNMENT)
!      The ‘__builtin_alloca_with_align’ function must be called at block
       scope.  The function allocates an object SIZE bytes large on the
       stack of the calling function.  The allocated object is aligned on
       the boundary specified by the argument ALIGNMENT whose unit is
       given in bits (not bytes).  The SIZE argument must be positive and
       not exceed the stack size limit.  The ALIGNMENT argument must be a
       constant integer expression that evaluates to a power of 2 greater
!      than or equal to ‘CHAR_BIT’ and less than some unspecified maximum.
       Invocations with other values are rejected with an error indicating
       the valid bounds.  The function returns a pointer to the first byte
       of the allocated object.  The lifetime of the allocated object ends
*************** without the '__builtin_' prefix.
*** 47633,47642 ****
       function returns to its caller, but may be released at the end of
       the block in which the function was called.
  
!      For example, in the following function the call to 'g' is unsafe
!      because when 'overalign' is non-zero, the space allocated by
!      '__builtin_alloca_with_align' may have been released at the end of
!      the 'if' statement in which it was called.
  
            void f (unsigned n, bool overalign)
            {
--- 47642,47651 ----
       function returns to its caller, but may be released at the end of
       the block in which the function was called.
  
!      For example, in the following function the call to ‘g’ is unsafe
!      because when ‘overalign’ is non-zero, the space allocated by
!      ‘__builtin_alloca_with_align’ may have been released at the end of
!      the ‘if’ statement in which it was called.
  
            void f (unsigned n, bool overalign)
            {
*************** without the '__builtin_' prefix.
*** 47649,47658 ****
              g (p, n);   // unsafe
            }
  
!      Since the '__builtin_alloca_with_align' function doesn't validate
       its SIZE argument it is the responsibility of its caller to make
       sure the argument doesn't cause it to exceed the stack size limit.
!      The '__builtin_alloca_with_align' function is provided to make it
       possible to allocate on the stack overaligned arrays of bytes with
       an upper bound that may be computed at run time.  Since C99
       Variable Length Arrays offer the same functionality under a
--- 47658,47667 ----
              g (p, n);   // unsafe
            }
  
!      Since the ‘__builtin_alloca_with_align’ function doesn't validate
       its SIZE argument it is the responsibility of its caller to make
       sure the argument doesn't cause it to exceed the stack size limit.
!      The ‘__builtin_alloca_with_align’ function is provided to make it
       possible to allocate on the stack overaligned arrays of bytes with
       an upper bound that may be computed at run time.  Since C99
       Variable Length Arrays offer the same functionality under a
*************** without the '__builtin_' prefix.
*** 47662,47713 ****
  
   -- Built-in Function: void * __builtin_alloca_with_align_and_max
            (size_t SIZE, size_t ALIGNMENT, size_t MAX_SIZE)
!      Similar to '__builtin_alloca_with_align' but takes an extra
       argument specifying an upper bound for SIZE in case its value
!      cannot be computed at compile time, for use by '-fstack-usage',
!      '-Wstack-usage' and '-Walloca-larger-than'.  MAX_SIZE must be a
       constant integer expression, it has no effect on code generation
       and no attempt is made to check its compatibility with SIZE.
  
   -- Built-in Function: bool __builtin_has_attribute (TYPE-OR-EXPRESSION,
            ATTRIBUTE)
!      The '__builtin_has_attribute' function evaluates to an integer
!      constant expression equal to 'true' if the symbol or type
       referenced by the TYPE-OR-EXPRESSION argument has been declared
       with the ATTRIBUTE referenced by the second argument.  For an
       TYPE-OR-EXPRESSION argument that does not reference a symbol, since
       attributes do not apply to expressions the built-in consider the
       type of the argument.  Neither argument is evaluated.  The
       TYPE-OR-EXPRESSION argument is subject to the same restrictions as
!      the argument to 'typeof' (*note Typeof::).  The ATTRIBUTE argument
       is an attribute name optionally followed by a comma-separated list
       of arguments enclosed in parentheses.  Both forms of attribute
       names--with and without double leading and trailing
       underscores--are recognized.  *Note Attribute Syntax::, for
       details.  When no attribute arguments are specified for an
       attribute that expects one or more arguments the function returns
!      'true' if TYPE-OR-EXPRESSION has been declared with the attribute
       regardless of the attribute argument values.  Arguments provided
       for an attribute that expects some are validated and matched up to
!      the provided number.  The function returns 'true' if all provided
       arguments match.  For example, the first call to the function below
!      evaluates to 'true' because 'x' is declared with the 'aligned'
!      attribute but the second call evaluates to 'false' because 'x' is
!      declared 'aligned (8)' and not 'aligned (4)'.
  
            __attribute__ ((aligned (8))) int x;
            _Static_assert (__builtin_has_attribute (x, aligned), "aligned");
            _Static_assert (!__builtin_has_attribute (x, aligned (4)), "aligned (4)");
  
!      Due to a limitation the '__builtin_has_attribute' function returns
!      'false' for the 'mode' attribute even if the type or variable
       referenced by the TYPE-OR-EXPRESSION argument was declared with
       one.  The function is also not supported with labels, and in C with
       enumerators.
  
!      Note that unlike the '__has_attribute' preprocessor operator which
!      is suitable for use in '#if' preprocessing directives
!      '__builtin_has_attribute' is an intrinsic function that is not
       recognized in such contexts.
  
   -- Built-in Function: TYPE __builtin_speculation_safe_value (TYPE VAL,
--- 47671,47722 ----
  
   -- Built-in Function: void * __builtin_alloca_with_align_and_max
            (size_t SIZE, size_t ALIGNMENT, size_t MAX_SIZE)
!      Similar to ‘__builtin_alloca_with_align’ but takes an extra
       argument specifying an upper bound for SIZE in case its value
!      cannot be computed at compile time, for use by ‘-fstack-usage’,
!      ‘-Wstack-usage’ and ‘-Walloca-larger-than’.  MAX_SIZE must be a
       constant integer expression, it has no effect on code generation
       and no attempt is made to check its compatibility with SIZE.
  
   -- Built-in Function: bool __builtin_has_attribute (TYPE-OR-EXPRESSION,
            ATTRIBUTE)
!      The ‘__builtin_has_attribute’ function evaluates to an integer
!      constant expression equal to ‘true’ if the symbol or type
       referenced by the TYPE-OR-EXPRESSION argument has been declared
       with the ATTRIBUTE referenced by the second argument.  For an
       TYPE-OR-EXPRESSION argument that does not reference a symbol, since
       attributes do not apply to expressions the built-in consider the
       type of the argument.  Neither argument is evaluated.  The
       TYPE-OR-EXPRESSION argument is subject to the same restrictions as
!      the argument to ‘typeof’ (*note Typeof::).  The ATTRIBUTE argument
       is an attribute name optionally followed by a comma-separated list
       of arguments enclosed in parentheses.  Both forms of attribute
       names--with and without double leading and trailing
       underscores--are recognized.  *Note Attribute Syntax::, for
       details.  When no attribute arguments are specified for an
       attribute that expects one or more arguments the function returns
!      ‘true’ if TYPE-OR-EXPRESSION has been declared with the attribute
       regardless of the attribute argument values.  Arguments provided
       for an attribute that expects some are validated and matched up to
!      the provided number.  The function returns ‘true’ if all provided
       arguments match.  For example, the first call to the function below
!      evaluates to ‘true’ because ‘x’ is declared with the ‘aligned’
!      attribute but the second call evaluates to ‘false’ because ‘x’ is
!      declared ‘aligned (8)’ and not ‘aligned (4)’.
  
            __attribute__ ((aligned (8))) int x;
            _Static_assert (__builtin_has_attribute (x, aligned), "aligned");
            _Static_assert (!__builtin_has_attribute (x, aligned (4)), "aligned (4)");
  
!      Due to a limitation the ‘__builtin_has_attribute’ function returns
!      ‘false’ for the ‘mode’ attribute even if the type or variable
       referenced by the TYPE-OR-EXPRESSION argument was declared with
       one.  The function is also not supported with labels, and in C with
       enumerators.
  
!      Note that unlike the ‘__has_attribute’ preprocessor operator which
!      is suitable for use in ‘#if’ preprocessing directives
!      ‘__builtin_has_attribute’ is an intrinsic function that is not
       recognized in such contexts.
  
   -- Built-in Function: TYPE __builtin_speculation_safe_value (TYPE VAL,
*************** without the '__builtin_' prefix.
*** 47720,47730 ****
         1. If the CPU is not speculatively executing the code, then VAL
            is returned.
         2. If the CPU is executing speculatively then either:
!              * The function may cause execution to pause until it is
                 known that the code is no-longer being executed
                 speculatively (in which case VAL can be returned, as
                 above); or
!              * The function may use target-dependent speculation
                 tracking state to cause FAILVAL to be returned when it is
                 known that speculative execution has incorrectly
                 predicted a conditional branch operation.
--- 47729,47739 ----
         1. If the CPU is not speculatively executing the code, then VAL
            is returned.
         2. If the CPU is executing speculatively then either:
!              • The function may cause execution to pause until it is
                 known that the code is no-longer being executed
                 speculatively (in which case VAL can be returned, as
                 above); or
!              • The function may use target-dependent speculation
                 tracking state to cause FAILVAL to be returned when it is
                 known that speculative execution has incorrectly
                 predicted a conditional branch operation.
*************** without the '__builtin_' prefix.
*** 47733,47739 ****
       omitted.
  
       GCC defines the preprocessor macro
!      '__HAVE_BUILTIN_SPECULATION_SAFE_VALUE' for targets that have been
       updated to support this builtin.
  
       The built-in function can be used where a variable appears to be
--- 47742,47748 ----
       omitted.
  
       GCC defines the preprocessor macro
!      ‘__HAVE_BUILTIN_SPECULATION_SAFE_VALUE’ for targets that have been
       updated to support this builtin.
  
       The built-in function can be used where a variable appears to be
*************** without the '__builtin_' prefix.
*** 47749,47757 ****
              return 0;
            }
  
!      If the function is called repeatedly with 'untrusted_index' less
       than the limit of 500, then a branch predictor will learn that the
!      block of code that returns a value stored in 'array' will be
       executed.  If the function is subsequently called with an
       out-of-range value it will still try to execute that block of code
       first until the CPU determines that the prediction was incorrect
--- 47758,47766 ----
              return 0;
            }
  
!      If the function is called repeatedly with ‘untrusted_index’ less
       than the limit of 500, then a branch predictor will learn that the
!      block of code that returns a value stored in ‘array’ will be
       executed.  If the function is subsequently called with an
       out-of-range value it will still try to execute that block of code
       first until the CPU determines that the prediction was incorrect
*************** without the '__builtin_' prefix.
*** 47773,47779 ****
       The built-in function will either cause execution to stall until
       the conditional branch has been fully resolved, or it may permit
       speculative execution to continue, but using 0 instead of
!      'untrusted_value' if that exceeds the limit.
  
       If accessing any memory location is potentially unsafe when
       speculative execution is incorrect, then the code can be rewritten
--- 47782,47788 ----
       The built-in function will either cause execution to stall until
       the conditional branch has been fully resolved, or it may permit
       speculative execution to continue, but using 0 instead of
!      ‘untrusted_value’ if that exceeds the limit.
  
       If accessing any memory location is potentially unsafe when
       speculative execution is incorrect, then the code can be rewritten
*************** without the '__builtin_' prefix.
*** 47787,47797 ****
              return 0;
            }
  
!      which will cause a 'NULL' pointer to be used for the unsafe case.
  
   -- 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
--- 47796,47806 ----
              return 0;
            }
  
!      which will cause a ‘NULL’ pointer to be used for the unsafe case.
  
   -- 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
*************** without the '__builtin_' prefix.
*** 47799,47819 ****
       compatible, 0 otherwise.  The result of this built-in function can
       be used in integer constant expressions.
  
!      This built-in function ignores top level qualifiers (e.g., 'const',
!      'volatile').  For example, 'int' is equivalent to 'const int'.
  
!      The type 'int[]' and 'int[5]' are compatible.  On the other hand,
!      'int' and 'char *' are not compatible, even if the size of their
       types, on the particular architecture are the same.  Also, the
       amount of pointer indirection is taken into account when
!      determining similarity.  Consequently, 'short *' is not similar to
!      'short **'.  Furthermore, two types that are typedefed are
       considered compatible if their underlying types are compatible.
  
!      An 'enum' type is not considered to be compatible with another
!      'enum' type even if both are compatible with the same integer type;
!      this is what the C standard specifies.  For example, 'enum {foo,
!      bar}' is not similar to 'enum {hot, dog}'.
  
       You typically use this function in code whose execution varies
       depending on the arguments' types.  For example:
--- 47808,47828 ----
       compatible, 0 otherwise.  The result of this built-in function can
       be used in integer constant expressions.
  
!      This built-in function ignores top level qualifiers (e.g., ‘const’,
!      ‘volatile’).  For example, ‘int’ is equivalent to ‘const int’.
  
!      The type ‘int[]’ and ‘int[5]’ are compatible.  On the other hand,
!      ‘int’ and ‘char *’ are not compatible, even if the size of their
       types, on the particular architecture are the same.  Also, the
       amount of pointer indirection is taken into account when
!      determining similarity.  Consequently, ‘short *’ is not similar to
!      ‘short **’.  Furthermore, two types that are typedefed are
       considered compatible if their underlying types are compatible.
  
!      An ‘enum’ type is not considered to be compatible with another
!      ‘enum’ type even if both are compatible with the same integer type;
!      this is what the C standard specifies.  For example, ‘enum {foo,
!      bar}’ is not similar to ‘enum {hot, dog}’.
  
       You typically use this function in code whose execution varies
       depending on the arguments' types.  For example:
*************** without the '__builtin_' prefix.
*** 47848,47864 ****
   -- Built-in Function: TYPE __builtin_choose_expr (CONST_EXP, EXP1,
            EXP2)
  
!      You can use the built-in function '__builtin_choose_expr' to
       evaluate code depending on the value of a constant expression.
       This built-in function returns EXP1 if CONST_EXP, which is an
       integer constant expression, is nonzero.  Otherwise it returns
       EXP2.
  
!      This built-in function is analogous to the '? :' operator in C,
       except that the expression returned has its type unaltered by
       promotion rules.  Also, the built-in function does not evaluate the
       expression that is not chosen.  For example, if CONST_EXP evaluates
!      to 'true', EXP2 is not evaluated even if it has side effects.
  
       This built-in function can return an lvalue if the chosen argument
       is an lvalue.
--- 47857,47873 ----
   -- Built-in Function: TYPE __builtin_choose_expr (CONST_EXP, EXP1,
            EXP2)
  
!      You can use the built-in function ‘__builtin_choose_expr’ to
       evaluate code depending on the value of a constant expression.
       This built-in function returns EXP1 if CONST_EXP, which is an
       integer constant expression, is nonzero.  Otherwise it returns
       EXP2.
  
!      This built-in function is analogous to the ‘? :’ operator in C,
       except that the expression returned has its type unaltered by
       promotion rules.  Also, the built-in function does not evaluate the
       expression that is not chosen.  For example, if CONST_EXP evaluates
!      to ‘true’, EXP2 is not evaluated even if it has side effects.
  
       This built-in function can return an lvalue if the chosen argument
       is an lvalue.
*************** without the '__builtin_' prefix.
*** 47887,47919 ****
  
   -- Built-in Function: TYPE __builtin_tgmath (FUNCTIONS, ARGUMENTS)
  
!      The built-in function '__builtin_tgmath', available only for C and
       Objective-C, calls a function determined according to the rules of
!      '' macros.  It is intended to be used in implementations
       of that header, so that expansions of macros from that header only
       expand each of their arguments once, to avoid problems when calls
       to such macros are nested inside the arguments of other calls to
       such macros; in addition, it results in better diagnostics for
!      invalid calls to '' macros than implementations using
!      other GNU C language features.  For example, the 'pow' type-generic
       macro might be defined as:
  
            #define pow(a, b) __builtin_tgmath (powf, pow, powl, \
                                                cpowf, cpow, cpowl, a, b)
  
!      The arguments to '__builtin_tgmath' are at least two pointers to
       functions, followed by the arguments to the type-generic macro
       (which will be passed as arguments to the selected function).  All
       the pointers to functions must be pointers to prototyped functions,
       none of which may have variable arguments, and all of which must
       have the same number of parameters; the number of parameters of the
!      first function determines how many arguments to '__builtin_tgmath'
       are interpreted as function pointers, and how many as the arguments
       to the called function.
  
       The types of the specified functions must all be different, but
       related to each other in the same way as a set of functions that
!      may be selected between by a macro in ''.  This means
       that the functions are parameterized by a floating-point type T,
       different for each such function.  The function return types may
       all be the same type, or they may be T for each function, or they
--- 47896,47928 ----
  
   -- Built-in Function: TYPE __builtin_tgmath (FUNCTIONS, ARGUMENTS)
  
!      The built-in function ‘__builtin_tgmath’, available only for C and
       Objective-C, calls a function determined according to the rules of
!      ‘’ macros.  It is intended to be used in implementations
       of that header, so that expansions of macros from that header only
       expand each of their arguments once, to avoid problems when calls
       to such macros are nested inside the arguments of other calls to
       such macros; in addition, it results in better diagnostics for
!      invalid calls to ‘’ macros than implementations using
!      other GNU C language features.  For example, the ‘pow’ type-generic
       macro might be defined as:
  
            #define pow(a, b) __builtin_tgmath (powf, pow, powl, \
                                                cpowf, cpow, cpowl, a, b)
  
!      The arguments to ‘__builtin_tgmath’ are at least two pointers to
       functions, followed by the arguments to the type-generic macro
       (which will be passed as arguments to the selected function).  All
       the pointers to functions must be pointers to prototyped functions,
       none of which may have variable arguments, and all of which must
       have the same number of parameters; the number of parameters of the
!      first function determines how many arguments to ‘__builtin_tgmath’
       are interpreted as function pointers, and how many as the arguments
       to the called function.
  
       The types of the specified functions must all be different, but
       related to each other in the same way as a set of functions that
!      may be selected between by a macro in ‘’.  This means
       that the functions are parameterized by a floating-point type T,
       different for each such function.  The function return types may
       all be the same type, or they may be T for each function, or they
*************** without the '__builtin_' prefix.
*** 47924,47930 ****
       for at least one parameter position), or may be the real type
       corresponding to T for each function.
  
!      The standard rules for '' macros are used to find a
       common type U from the types of the arguments for parameters whose
       types vary between the functions; complex integer types (a GNU
       extension) are treated like the complex type corresponding to the
--- 47933,47939 ----
       for at least one parameter position), or may be the real type
       corresponding to T for each function.
  
!      The standard rules for ‘’ macros are used to find a
       common type U from the types of the arguments for parameters whose
       types vary between the functions; complex integer types (a GNU
       extension) are treated like the complex type corresponding to the
*************** without the '__builtin_' prefix.
*** 47940,47946 ****
       error if there is no such function.
  
   -- 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
--- 47949,47955 ----
       error if there is no such function.
  
   -- 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
*************** without the '__builtin_' prefix.
*** 47948,47954 ****
       to be a compile-time constant and 0 if it is not known to be a
       compile-time constant.  A return of 0 does not indicate that the
       value is _not_ a constant, but merely that GCC cannot prove it is a
!      constant with the specified value of the '-O' option.
  
       You typically use this function in an embedded application where
       memory is a critical resource.  If you have some complex
--- 47957,47963 ----
       to be a compile-time constant and 0 if it is not known to be a
       compile-time constant.  A return of 0 does not indicate that the
       value is _not_ a constant, but merely that GCC cannot prove it is a
!      constant with the specified value of the ‘-O’ option.
  
       You typically use this function in an embedded application where
       memory is a critical resource.  If you have some complex
*************** without the '__builtin_' prefix.
*** 47965,47973 ****
       never returns 1 when you call the inline function with a string
       constant or compound literal (*note Compound Literals::) and does
       not return 1 when you pass a constant numeric value to the inline
!      function unless you specify the '-O' option.
  
!      You may also use '__builtin_constant_p' in initializers for static
       data.  For instance, you can write
  
            static const int table[] = {
--- 47974,47982 ----
       never returns 1 when you call the inline function with a string
       constant or compound literal (*note Compound Literals::) and does
       not return 1 when you pass a constant numeric value to the inline
!      function unless you specify the ‘-O’ option.
  
!      You may also use ‘__builtin_constant_p’ in initializers for static
       data.  For instance, you can write
  
            static const int table[] = {
*************** without the '__builtin_' prefix.
*** 47977,48009 ****
  
       This is an acceptable initializer even if EXPRESSION is not a
       constant expression, including the case where
!      '__builtin_constant_p' returns 1 because EXPRESSION can be folded
       to a constant but EXPRESSION contains operands that are not
!      otherwise permitted in a static initializer (for example, '0 && foo
!      ()').  GCC must be more conservative about evaluating the built-in
       in this case, because it has no opportunity to perform
       optimization.
  
   -- Built-in Function: bool __builtin_is_constant_evaluated (void)
!      The '__builtin_is_constant_evaluated' function is available only in
       C++.  The built-in is intended to be used by implementations of the
!      'std::is_constant_evaluated' C++ function.  Programs should make
       use of the latter function rather than invoking the built-in
       directly.
  
       The main use case of the built-in is to determine whether a
!      'constexpr' function is being called in a 'constexpr' context.  A
       call to the function evaluates to a core constant expression with
!      the value 'true' if and only if it occurs within the evaluation of
       an expression or conversion that is manifestly constant-evaluated
       as defined in the C++ standard.  Manifestly constant-evaluated
!      contexts include constant-expressions, the conditions of 'constexpr
!      if' statements, constraint-expressions, and initializers of
       variables usable in constant expressions.  For more details refer
       to the latest revision of the C++ standard.
  
   -- Built-in Function: void __builtin_clear_padding (PTR)
!      The built-in function '__builtin_clear_padding' function clears
       padding bits inside of the object representation of object pointed
       by PTR, which has to be a pointer.  The value representation of the
       object is not affected.  The type of the object is assumed to be
--- 47986,48018 ----
  
       This is an acceptable initializer even if EXPRESSION is not a
       constant expression, including the case where
!      ‘__builtin_constant_p’ returns 1 because EXPRESSION can be folded
       to a constant but EXPRESSION contains operands that are not
!      otherwise permitted in a static initializer (for example, ‘0 && foo
!      ()’).  GCC must be more conservative about evaluating the built-in
       in this case, because it has no opportunity to perform
       optimization.
  
   -- Built-in Function: bool __builtin_is_constant_evaluated (void)
!      The ‘__builtin_is_constant_evaluated’ function is available only in
       C++.  The built-in is intended to be used by implementations of the
!      ‘std::is_constant_evaluated’ C++ function.  Programs should make
       use of the latter function rather than invoking the built-in
       directly.
  
       The main use case of the built-in is to determine whether a
!      ‘constexpr’ function is being called in a ‘constexpr’ context.  A
       call to the function evaluates to a core constant expression with
!      the value ‘true’ if and only if it occurs within the evaluation of
       an expression or conversion that is manifestly constant-evaluated
       as defined in the C++ standard.  Manifestly constant-evaluated
!      contexts include constant-expressions, the conditions of ‘constexpr
!      if’ statements, constraint-expressions, and initializers of
       variables usable in constant expressions.  For more details refer
       to the latest revision of the C++ standard.
  
   -- Built-in Function: void __builtin_clear_padding (PTR)
!      The built-in function ‘__builtin_clear_padding’ function clears
       padding bits inside of the object representation of object pointed
       by PTR, which has to be a pointer.  The value representation of the
       object is not affected.  The type of the object is assumed to be
*************** without the '__builtin_' prefix.
*** 48023,48045 ****
       derived class.
  
   -- Built-in Function: TYPE __builtin_bit_cast (TYPE, ARG)
!      The '__builtin_bit_cast' function is available only in C++.  The
       built-in is intended to be used by implementations of the
!      'std::bit_cast' C++ template function.  Programs should make use of
       the latter function rather than invoking the built-in directly.
  
       This built-in function allows reinterpreting the bits of the ARG
       argument as if it had type TYPE.  TYPE and the type of the ARG
       argument need to be trivially copyable types with the same size.
       When manifestly constant-evaluated, it performs extra diagnostics
!      required for 'std::bit_cast' and returns a constant expression if
       ARG is a constant expression.  For more details refer to the latest
       revision of the C++ standard.
  
   -- 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.
--- 48032,48054 ----
       derived class.
  
   -- Built-in Function: TYPE __builtin_bit_cast (TYPE, ARG)
!      The ‘__builtin_bit_cast’ function is available only in C++.  The
       built-in is intended to be used by implementations of the
!      ‘std::bit_cast’ C++ template function.  Programs should make use of
       the latter function rather than invoking the built-in directly.
  
       This built-in function allows reinterpreting the bits of the ARG
       argument as if it had type TYPE.  TYPE and the type of the ARG
       argument need to be trivially copyable types with the same size.
       When manifestly constant-evaluated, it performs extra diagnostics
!      required for ‘std::bit_cast’ and returns a constant expression if
       ARG is a constant expression.  For more details refer to the latest
       revision of the C++ standard.
  
   -- 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.
*************** without the '__builtin_' prefix.
*** 48051,48057 ****
            if (__builtin_expect (x, 0))
              foo ();
  
!      indicates that we do not expect to call 'foo', since we expect 'x'
       to be zero.  Since you are limited to integral expressions for EXP,
       you should use constructions such as
  
--- 48060,48066 ----
            if (__builtin_expect (x, 0))
              foo ();
  
!      indicates that we do not expect to call ‘foo’, since we expect ‘x’
       to be zero.  Since you are limited to integral expressions for EXP,
       you should use constructions such as
  
*************** without the '__builtin_' prefix.
*** 48061,48071 ****
       when testing pointer or floating-point values.
  
       For the purposes of branch prediction optimizations, the
!      probability that a '__builtin_expect' expression is 'true' is
!      controlled by GCC's 'builtin-expect-probability' parameter, which
       defaults to 90%.
  
!      You can also use '__builtin_expect_with_probability' to explicitly
       assign a probability value to individual expressions.  If the
       built-in is used in a loop construct, the provided probability will
       influence the expected number of iterations made by loop
--- 48070,48080 ----
       when testing pointer or floating-point values.
  
       For the purposes of branch prediction optimizations, the
!      probability that a ‘__builtin_expect’ expression is ‘true’ is
!      controlled by GCC's ‘builtin-expect-probability’ parameter, which
       defaults to 90%.
  
!      You can also use ‘__builtin_expect_with_probability’ to explicitly
       assign a probability value to individual expressions.  If the
       built-in is used in a loop construct, the provided probability will
       influence the expected number of iterations made by loop
*************** without the '__builtin_' prefix.
*** 48074,48080 ****
   -- Built-in Function: long __builtin_expect_with_probability
       (long EXP, long C, double PROBABILITY)
  
!      This function has the same semantics as '__builtin_expect', but the
       caller provides the expected probability that EXP == C.  The last
       argument, PROBABILITY, is a floating-point value in the range 0.0
       to 1.0, inclusive.  The PROBABILITY argument must be constant
--- 48083,48089 ----
   -- Built-in Function: long __builtin_expect_with_probability
       (long EXP, long C, double PROBABILITY)
  
!      This function has the same semantics as ‘__builtin_expect’, but the
       caller provides the expected probability that EXP == C.  The last
       argument, PROBABILITY, is a floating-point value in the range 0.0
       to 1.0, inclusive.  The PROBABILITY argument must be constant
*************** without the '__builtin_' prefix.
*** 48084,48103 ****
       This function causes the program to exit abnormally.  GCC
       implements this function by using a target-dependent mechanism
       (such as intentionally executing an illegal instruction) or by
!      calling 'abort'.  The mechanism used may vary from release to
       release so you should not rely on any particular implementation.
  
   -- Built-in Function: void __builtin_unreachable (void)
!      If control flow reaches the point of the '__builtin_unreachable',
       the program is undefined.  It is useful in situations where the
       compiler cannot deduce the unreachability of the code.
  
!      One such case is immediately following an 'asm' statement that
       either never terminates, or one that transfers control elsewhere
       and never returns.  In this example, without the
!      '__builtin_unreachable', GCC issues a warning that control reaches
       the end of a non-void function.  It also generates code to return
!      after the 'asm'.
  
            int f (int c, int v)
            {
--- 48093,48112 ----
       This function causes the program to exit abnormally.  GCC
       implements this function by using a target-dependent mechanism
       (such as intentionally executing an illegal instruction) or by
!      calling ‘abort’.  The mechanism used may vary from release to
       release so you should not rely on any particular implementation.
  
   -- Built-in Function: void __builtin_unreachable (void)
!      If control flow reaches the point of the ‘__builtin_unreachable’,
       the program is undefined.  It is useful in situations where the
       compiler cannot deduce the unreachability of the code.
  
!      One such case is immediately following an ‘asm’ statement that
       either never terminates, or one that transfers control elsewhere
       and never returns.  In this example, without the
!      ‘__builtin_unreachable’, GCC issues a warning that control reaches
       the end of a non-void function.  It also generates code to return
!      after the ‘asm’.
  
            int f (int c, int v)
            {
*************** without the '__builtin_' prefix.
*** 48112,48125 ****
                }
            }
  
!      Because the 'asm' statement unconditionally transfers control out
       of the function, control never reaches the end of the function
!      body.  The '__builtin_unreachable' is in fact unreachable and
       communicates this fact to the compiler.
  
!      Another use for '__builtin_unreachable' is following a call a
       function that never returns but that is not declared
!      '__attribute__((noreturn))', as in this example:
  
            void function_that_never_returns (void);
  
--- 48121,48134 ----
                }
            }
  
!      Because the ‘asm’ statement unconditionally transfers control out
       of the function, control never reaches the end of the function
!      body.  The ‘__builtin_unreachable’ is in fact unreachable and
       communicates this fact to the compiler.
  
!      Another use for ‘__builtin_unreachable’ is following a call a
       function that never returns but that is not declared
!      ‘__attribute__((noreturn))’, as in this example:
  
            void function_that_never_returns (void);
  
*************** without the '__builtin_' prefix.
*** 48141,48155 ****
       expression EXPR with expressions consuming the return value of the
       built-in.  The expression EXPR itself can be reordered, and the
       whole expression EXPR can be reordered with operands after the
!      barrier.  The barrier is only relevant when '-fassociative-math' is
       active, since otherwise floating-point is not treated as
       associative.
  
            float x0 = a + b - b;
            float x1 = __builtin_assoc_barrier(a + b) - b;
  
!      means that, with '-fassociative-math', 'x0' can be optimized to 'x0
!      = a' but 'x1' cannot.
  
   -- Built-in Function: void * __builtin_assume_aligned (const void *EXP,
            size_t ALIGN, ...)
--- 48150,48164 ----
       expression EXPR with expressions consuming the return value of the
       built-in.  The expression EXPR itself can be reordered, and the
       whole expression EXPR can be reordered with operands after the
!      barrier.  The barrier is only relevant when ‘-fassociative-math’ is
       active, since otherwise floating-point is not treated as
       associative.
  
            float x0 = a + b - b;
            float x1 = __builtin_assoc_barrier(a + b) - b;
  
!      means that, with ‘-fassociative-math’, ‘x0’ can be optimized to ‘x0
!      = a’ but ‘x1’ cannot.
  
   -- Built-in Function: void * __builtin_assume_aligned (const void *EXP,
            size_t ALIGN, ...)
*************** without the '__builtin_' prefix.
*** 48161,48183 ****
  
            void *x = __builtin_assume_aligned (arg, 16);
  
!      means that the compiler can assume 'x', set to 'arg', is at least
       16-byte aligned, while:
  
            void *x = __builtin_assume_aligned (arg, 32, 8);
  
!      means that the compiler can assume for 'x', set to 'arg', that
!      '(char *) x - 8' is 32-byte aligned.
  
   -- Built-in Function: int __builtin_LINE ()
!      This function is the equivalent of the preprocessor '__LINE__'
       macro and returns a constant integer expression that evaluates to
       the line number of the invocation of the built-in.  When used as a
       C++ default argument for a function F, it returns the line number
       of the call to F.
  
   -- Built-in Function: const char * __builtin_FUNCTION ()
!      This function is the equivalent of the '__FUNCTION__' symbol and
       returns an address constant pointing to the name of the function
       from which the built-in was invoked, or the empty string if the
       invocation is not at function scope.  When used as a C++ default
--- 48170,48192 ----
  
            void *x = __builtin_assume_aligned (arg, 16);
  
!      means that the compiler can assume ‘x’, set to ‘arg’, is at least
       16-byte aligned, while:
  
            void *x = __builtin_assume_aligned (arg, 32, 8);
  
!      means that the compiler can assume for ‘x’, set to ‘arg’, that
!      ‘(char *) x - 8’ is 32-byte aligned.
  
   -- Built-in Function: int __builtin_LINE ()
!      This function is the equivalent of the preprocessor ‘__LINE__’
       macro and returns a constant integer expression that evaluates to
       the line number of the invocation of the built-in.  When used as a
       C++ default argument for a function F, it returns the line number
       of the call to F.
  
   -- Built-in Function: const char * __builtin_FUNCTION ()
!      This function is the equivalent of the ‘__FUNCTION__’ symbol and
       returns an address constant pointing to the name of the function
       from which the built-in was invoked, or the empty string if the
       invocation is not at function scope.  When used as a C++ default
*************** without the '__builtin_' prefix.
*** 48185,48191 ****
       empty string if the call was not made at function scope.
  
   -- Built-in Function: const char * __builtin_FILE ()
!      This function is the equivalent of the preprocessor '__FILE__'
       macro and returns an address constant pointing to the file name
       containing the invocation of the built-in, or the empty string if
       the invocation is not at function scope.  When used as a C++
--- 48194,48200 ----
       empty string if the call was not made at function scope.
  
   -- Built-in Function: const char * __builtin_FILE ()
!      This function is the equivalent of the preprocessor ‘__FILE__’
       macro and returns an address constant pointing to the file name
       containing the invocation of the built-in, or the empty string if
       the invocation is not at function scope.  When used as a C++
*************** without the '__builtin_' prefix.
*** 48193,48202 ****
       call to F or the empty string if the call was not made at function
       scope.
  
!      For example, in the following, each call to function 'foo' will
!      print a line similar to '"file.c:123: foo: message"' with the name
!      of the file and the line number of the 'printf' call, the name of
!      the function 'foo', followed by the word 'message'.
  
            const char*
            function (const char *func = __builtin_FUNCTION ())
--- 48202,48211 ----
       call to F or the empty string if the call was not made at function
       scope.
  
!      For example, in the following, each call to function ‘foo’ will
!      print a line similar to ‘"file.c:123: foo: message"’ with the name
!      of the file and the line number of the ‘printf’ call, the name of
!      the function ‘foo’, followed by the word ‘message’.
  
            const char*
            function (const char *func = __builtin_FUNCTION ())
*************** without the '__builtin_' prefix.
*** 48218,48231 ****
       behavior.
  
       If the target does not require instruction cache flushes,
!      '__builtin___clear_cache' has no effect.  Otherwise either
       instructions are emitted in-line to clear the instruction cache or
!      a call to the '__clear_cache' function in libgcc is made.
  
   -- Built-in Function: void __builtin_prefetch (const void *ADDR, ...)
       This function is used to minimize cache-miss latency by moving data
       into a cache before it is accessed.  You can insert calls to
!      '__builtin_prefetch' into code for which you know addresses of data
       in memory that is likely to be accessed soon.  If the target
       supports them, data prefetch instructions are generated.  If the
       prefetch is done early enough before the access then the data will
--- 48227,48240 ----
       behavior.
  
       If the target does not require instruction cache flushes,
!      ‘__builtin___clear_cache’ has no effect.  Otherwise either
       instructions are emitted in-line to clear the instruction cache or
!      a call to the ‘__clear_cache’ function in libgcc is made.
  
   -- Built-in Function: void __builtin_prefetch (const void *ADDR, ...)
       This function is used to minimize cache-miss latency by moving data
       into a cache before it is accessed.  You can insert calls to
!      ‘__builtin_prefetch’ into code for which you know addresses of data
       in memory that is likely to be accessed soon.  If the target
       supports them, data prefetch instructions are generated.  If the
       prefetch is done early enough before the access then the data will
*************** without the '__builtin_' prefix.
*** 48254,48261 ****
  
       Data prefetch does not generate faults if ADDR is invalid, but the
       address expression itself must be valid.  For example, a prefetch
!      of 'p->next' does not fault if 'p->next' is not a valid address,
!      but evaluation faults if 'p' is not a valid address.
  
       If the target does not support data prefetch, the address
       expression is evaluated if it includes side effects but no other
--- 48263,48270 ----
  
       Data prefetch does not generate faults if ADDR is invalid, but the
       address expression itself must be valid.  For example, a prefetch
!      of ‘p->next’ does not fault if ‘p->next’ is not a valid address,
!      but evaluation faults if ‘p’ is not a valid address.
  
       If the target does not support data prefetch, the address
       expression is evaluated if it includes side effects but no other
*************** without the '__builtin_' prefix.
*** 48269,48413 ****
  
   -- Built-in Function: size_t __builtin_dynamic_object_size (const void
            * PTR, int TYPE)
!      Similar to '__builtin_object_size' except that the return value
       need not be a constant.  *Note Object Size Checking::, for a
       detailed description of the function.
  
   -- 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: _FloatN __builtin_huge_valfN (void)
!      Similar to '__builtin_huge_val', except the return type is
!      '_FloatN'.
  
   -- Built-in Function: _FloatNx __builtin_huge_valfNx (void)
!      Similar to '__builtin_huge_val', except the return type is
!      '_FloatNx'.
  
   -- 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: _FloatN __builtin_inffN (void)
!      Similar to '__builtin_inf', except the return type is '_FloatN'.
  
   -- Built-in Function: _FloatN __builtin_inffNx (void)
!      Similar to '__builtin_inf', except the return type is '_FloatNx'.
  
   -- Built-in Function: int __builtin_isinf_sign (...)
!      Similar to 'isinf', except the return value is -1 for an argument
!      of '-Inf' and 1 for an argument of '+Inf'.  Note while the
       parameter list is an ellipsis, this function only accepts exactly
       one floating-point argument.  GCC treats this parameter as
       type-generic, which means it does not do default promotion from
       float to double.
  
   -- Built-in Function: double __builtin_nan (const char *STR)
!      This is an implementation of the ISO C99 function 'nan'.
  
!      Since ISO C99 defines this function in terms of 'strtod', which we
       do not implement, a description of the parsing is in order.  The
!      string is parsed as by 'strtol'; that is, the base is recognized by
!      leading '0' or '0x' prefixes.  The number parsed is placed in the
       significand such that the least significant bit of the number is at
       the least significant bit of the significand.  The number is
       truncated to fit the significand field provided.  The significand
       is forced to be a quiet NaN.
  
       This function, if given a string literal all of which would have
!      been consumed by 'strtol', is evaluated early enough that it is
       considered a compile-time constant.
  
   -- Built-in Function: _Decimal32 __builtin_nand32 (const char *STR)
!      Similar to '__builtin_nan', except the return type is '_Decimal32'.
  
   -- Built-in Function: _Decimal64 __builtin_nand64 (const char *STR)
!      Similar to '__builtin_nan', except the return type is '_Decimal64'.
  
   -- Built-in Function: _Decimal128 __builtin_nand128 (const char *STR)
!      Similar to '__builtin_nan', except the return type is
!      '_Decimal128'.
  
   -- Built-in Function: float __builtin_nanf (const char *STR)
!      Similar to '__builtin_nan', except the return type is 'float'.
  
   -- Built-in Function: long double __builtin_nanl (const char *STR)
!      Similar to '__builtin_nan', except the return type is 'long
!      double'.
  
   -- Built-in Function: _FloatN __builtin_nanfN (const char *STR)
!      Similar to '__builtin_nan', except the return type is '_FloatN'.
  
   -- Built-in Function: _FloatNx __builtin_nanfNx (const char *STR)
!      Similar to '__builtin_nan', except the return type is '_FloatNx'.
  
   -- 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: _Decimal32 __builtin_nansd32 (const char *STR)
!      Similar to '__builtin_nans', except the return type is
!      '_Decimal32'.
  
   -- Built-in Function: _Decimal64 __builtin_nansd64 (const char *STR)
!      Similar to '__builtin_nans', except the return type is
!      '_Decimal64'.
  
   -- Built-in Function: _Decimal128 __builtin_nansd128 (const char *STR)
!      Similar to '__builtin_nans', except the return type is
!      '_Decimal128'.
  
   -- 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: _FloatN __builtin_nansfN (const char *STR)
!      Similar to '__builtin_nans', except the return type is '_FloatN'.
  
   -- Built-in Function: _FloatNx __builtin_nansfNx (const char *STR)
!      Similar to '__builtin_nans', except the return type is '_FloatNx'.
  
   -- Built-in Function: int __builtin_issignaling (...)
       Return non-zero if the argument is a signaling NaN and zero
--- 48278,48422 ----
  
   -- Built-in Function: size_t __builtin_dynamic_object_size (const void
            * PTR, int TYPE)
!      Similar to ‘__builtin_object_size’ except that the return value
       need not be a constant.  *Note Object Size Checking::, for a
       detailed description of the function.
  
   -- 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: _FloatN __builtin_huge_valfN (void)
!      Similar to ‘__builtin_huge_val’, except the return type is
!      ‘_FloatN’.
  
   -- Built-in Function: _FloatNx __builtin_huge_valfNx (void)
!      Similar to ‘__builtin_huge_val’, except the return type is
!      ‘_FloatNx’.
  
   -- 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: _FloatN __builtin_inffN (void)
!      Similar to ‘__builtin_inf’, except the return type is ‘_FloatN’.
  
   -- Built-in Function: _FloatN __builtin_inffNx (void)
!      Similar to ‘__builtin_inf’, except the return type is ‘_FloatNx’.
  
   -- Built-in Function: int __builtin_isinf_sign (...)
!      Similar to ‘isinf’, except the return value is -1 for an argument
!      of ‘-Inf’ and 1 for an argument of ‘+Inf’.  Note while the
       parameter list is an ellipsis, this function only accepts exactly
       one floating-point argument.  GCC treats this parameter as
       type-generic, which means it does not do default promotion from
       float to double.
  
   -- Built-in Function: double __builtin_nan (const char *STR)
!      This is an implementation of the ISO C99 function ‘nan’.
  
!      Since ISO C99 defines this function in terms of ‘strtod’, which we
       do not implement, a description of the parsing is in order.  The
!      string is parsed as by ‘strtol’; that is, the base is recognized by
!      leading ‘0’ or ‘0x’ prefixes.  The number parsed is placed in the
       significand such that the least significant bit of the number is at
       the least significant bit of the significand.  The number is
       truncated to fit the significand field provided.  The significand
       is forced to be a quiet NaN.
  
       This function, if given a string literal all of which would have
!      been consumed by ‘strtol’, is evaluated early enough that it is
       considered a compile-time constant.
  
   -- Built-in Function: _Decimal32 __builtin_nand32 (const char *STR)
!      Similar to ‘__builtin_nan’, except the return type is ‘_Decimal32’.
  
   -- Built-in Function: _Decimal64 __builtin_nand64 (const char *STR)
!      Similar to ‘__builtin_nan’, except the return type is ‘_Decimal64’.
  
   -- Built-in Function: _Decimal128 __builtin_nand128 (const char *STR)
!      Similar to ‘__builtin_nan’, except the return type is
!      ‘_Decimal128’.
  
   -- Built-in Function: float __builtin_nanf (const char *STR)
!      Similar to ‘__builtin_nan’, except the return type is ‘float’.
  
   -- Built-in Function: long double __builtin_nanl (const char *STR)
!      Similar to ‘__builtin_nan’, except the return type is ‘long
!      double’.
  
   -- Built-in Function: _FloatN __builtin_nanfN (const char *STR)
!      Similar to ‘__builtin_nan’, except the return type is ‘_FloatN’.
  
   -- Built-in Function: _FloatNx __builtin_nanfNx (const char *STR)
!      Similar to ‘__builtin_nan’, except the return type is ‘_FloatNx’.
  
   -- 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: _Decimal32 __builtin_nansd32 (const char *STR)
!      Similar to ‘__builtin_nans’, except the return type is
!      ‘_Decimal32’.
  
   -- Built-in Function: _Decimal64 __builtin_nansd64 (const char *STR)
!      Similar to ‘__builtin_nans’, except the return type is
!      ‘_Decimal64’.
  
   -- Built-in Function: _Decimal128 __builtin_nansd128 (const char *STR)
!      Similar to ‘__builtin_nans’, except the return type is
!      ‘_Decimal128’.
  
   -- 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: _FloatN __builtin_nansfN (const char *STR)
!      Similar to ‘__builtin_nans’, except the return type is ‘_FloatN’.
  
   -- Built-in Function: _FloatNx __builtin_nansfNx (const char *STR)
!      Similar to ‘__builtin_nans’, except the return type is ‘_FloatNx’.
  
   -- Built-in Function: int __builtin_issignaling (...)
       Return non-zero if the argument is a signaling NaN and zero
*************** without the '__builtin_' prefix.
*** 48415,48425 ****
       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.  This built-in function can
!      work even without the non-default '-fsignaling-nans' option,
       although if a signaling NaN is computed, stored or passed as
       argument to some function other than this built-in in the current
!      translation unit, it is safer to use '-fsignaling-nans'.  With
!      '-ffinite-math-only' option this built-in function will always
       return 0.
  
   -- Built-in Function: int __builtin_ffs (int X)
--- 48424,48434 ----
       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.  This built-in function can
!      work even without the non-default ‘-fsignaling-nans’ option,
       although if a signaling NaN is computed, stored or passed as
       argument to some function other than this built-in in the current
!      translation unit, it is safer to use ‘-fsignaling-nans’.  With
!      ‘-ffinite-math-only’ option this built-in function will always
       return 0.
  
   -- Built-in Function: int __builtin_ffs (int X)
*************** without the '__builtin_' prefix.
*** 48446,48517 ****
       Returns the parity of X, i.e. the number of 1-bits in X modulo 2.
  
   -- Built-in Function: int __builtin_ffsl (long)
!      Similar to '__builtin_ffs', except the argument type is 'long'.
  
   -- Built-in Function: int __builtin_clzl (unsigned long)
!      Similar to '__builtin_clz', except the argument type is 'unsigned
!      long'.
  
   -- Built-in Function: int __builtin_ctzl (unsigned long)
!      Similar to '__builtin_ctz', except the argument type is 'unsigned
!      long'.
  
   -- Built-in Function: int __builtin_clrsbl (long)
!      Similar to '__builtin_clrsb', except the argument type is 'long'.
  
   -- Built-in Function: int __builtin_popcountl (unsigned long)
!      Similar to '__builtin_popcount', except the argument type is
!      'unsigned long'.
  
   -- Built-in Function: int __builtin_parityl (unsigned long)
!      Similar to '__builtin_parity', except the argument type is
!      'unsigned long'.
  
   -- Built-in Function: int __builtin_ffsll (long long)
!      Similar to '__builtin_ffs', except the argument type is 'long
!      long'.
  
   -- Built-in Function: int __builtin_clzll (unsigned long long)
!      Similar to '__builtin_clz', except the argument type is 'unsigned
!      long long'.
  
   -- Built-in Function: int __builtin_ctzll (unsigned long long)
!      Similar to '__builtin_ctz', except the argument type is 'unsigned
!      long long'.
  
   -- Built-in Function: int __builtin_clrsbll (long long)
!      Similar to '__builtin_clrsb', except the argument type is 'long
!      long'.
  
   -- Built-in Function: int __builtin_popcountll (unsigned long long)
!      Similar to '__builtin_popcount', except the argument type is
!      'unsigned long long'.
  
   -- Built-in Function: int __builtin_parityll (unsigned long long)
!      Similar to '__builtin_parity', except the argument type is
!      'unsigned long long'.
  
   -- Built-in Function: double __builtin_powi (double, int)
   -- Built-in Function: float __builtin_powif (float, int)
   -- Built-in Function: long double __builtin_powil (long 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: uint16_t __builtin_bswap16 (uint16_t X)
       Returns X with the order of the bytes reversed; for example,
!      '0xaabb' becomes '0xbbaa'.  Byte here always means exactly 8 bits.
  
   -- Built-in Function: uint32_t __builtin_bswap32 (uint32_t X)
!      Similar to '__builtin_bswap16', except the argument and return
       types are 32-bit.
  
   -- Built-in Function: uint64_t __builtin_bswap64 (uint64_t X)
!      Similar to '__builtin_bswap32', except the argument and return
       types are 64-bit.
  
   -- Built-in Function: uint128_t __builtin_bswap128 (uint128_t X)
!      Similar to '__builtin_bswap64', except the argument and return
       types are 128-bit.  Only supported on targets when 128-bit types
       are supported.
  
--- 48455,48526 ----
       Returns the parity of X, i.e. the number of 1-bits in X modulo 2.
  
   -- Built-in Function: int __builtin_ffsl (long)
!      Similar to ‘__builtin_ffs’, except the argument type is ‘long’.
  
   -- Built-in Function: int __builtin_clzl (unsigned long)
!      Similar to ‘__builtin_clz’, except the argument type is ‘unsigned
!      long’.
  
   -- Built-in Function: int __builtin_ctzl (unsigned long)
!      Similar to ‘__builtin_ctz’, except the argument type is ‘unsigned
!      long’.
  
   -- Built-in Function: int __builtin_clrsbl (long)
!      Similar to ‘__builtin_clrsb’, except the argument type is ‘long’.
  
   -- Built-in Function: int __builtin_popcountl (unsigned long)
!      Similar to ‘__builtin_popcount’, except the argument type is
!      ‘unsigned long’.
  
   -- Built-in Function: int __builtin_parityl (unsigned long)
!      Similar to ‘__builtin_parity’, except the argument type is
!      ‘unsigned long’.
  
   -- Built-in Function: int __builtin_ffsll (long long)
!      Similar to ‘__builtin_ffs’, except the argument type is ‘long
!      long’.
  
   -- Built-in Function: int __builtin_clzll (unsigned long long)
!      Similar to ‘__builtin_clz’, except the argument type is ‘unsigned
!      long long’.
  
   -- Built-in Function: int __builtin_ctzll (unsigned long long)
!      Similar to ‘__builtin_ctz’, except the argument type is ‘unsigned
!      long long’.
  
   -- Built-in Function: int __builtin_clrsbll (long long)
!      Similar to ‘__builtin_clrsb’, except the argument type is ‘long
!      long’.
  
   -- Built-in Function: int __builtin_popcountll (unsigned long long)
!      Similar to ‘__builtin_popcount’, except the argument type is
!      ‘unsigned long long’.
  
   -- Built-in Function: int __builtin_parityll (unsigned long long)
!      Similar to ‘__builtin_parity’, except the argument type is
!      ‘unsigned long long’.
  
   -- Built-in Function: double __builtin_powi (double, int)
   -- Built-in Function: float __builtin_powif (float, int)
   -- Built-in Function: long double __builtin_powil (long 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: uint16_t __builtin_bswap16 (uint16_t X)
       Returns X with the order of the bytes reversed; for example,
!      ‘0xaabb’ becomes ‘0xbbaa’.  Byte here always means exactly 8 bits.
  
   -- Built-in Function: uint32_t __builtin_bswap32 (uint32_t X)
!      Similar to ‘__builtin_bswap16’, except the argument and return
       types are 32-bit.
  
   -- Built-in Function: uint64_t __builtin_bswap64 (uint64_t X)
!      Similar to ‘__builtin_bswap32’, except the argument and return
       types are 64-bit.
  
   -- Built-in Function: uint128_t __builtin_bswap128 (uint128_t X)
!      Similar to ‘__builtin_bswap64’, except the argument and return
       types are 128-bit.  Only supported on targets when 128-bit types
       are supported.
  
*************** generate the machine instruction that is
*** 48639,48646 ****
       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);
--- 48648,48655 ----
       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);
*************** instruction that is part of the name.
*** 48657,48664 ****
       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);
--- 48666,48673 ----
       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);
*************** that is part of the name.
*** 48666,48674 ****
       long __builtin_alpha_ctpop (long);
  
   The following built-in functions are available on systems that use the
! OSF/1 PALcode.  Normally they invoke the 'rduniq' and 'wruniq' PAL
! calls, but when invoked with '-mtls-kernel', they invoke 'rdval' and
! 'wrval'.
  
       void *__builtin_thread_pointer (void);
       void __builtin_set_thread_pointer (void *);
--- 48675,48683 ----
       long __builtin_alpha_ctpop (long);
  
   The following built-in functions are available on systems that use the
! OSF/1 PALcode.  Normally they invoke the ‘rduniq’ and ‘wruniq’ PAL
! calls, but when invoked with ‘-mtls-kernel’, they invoke ‘rdval’ and
! ‘wrval’.
  
       void *__builtin_thread_pointer (void);
       void __builtin_set_thread_pointer (void *);
*************** generate the machine instruction that is
*** 48709,48731 ****
   The following built-in functions are always available.  They all
  generate a Nios II Custom Instruction.  The name of the function
  represents the types that the function takes and returns.  The letter
! before the 'n' is the return type or void if absent.  The 'n' represents
  the first parameter to all the custom instructions, the custom
! instruction number.  The two letters after the 'n' represent the up to
  two parameters to the function.
  
   The letters represent the following data types:
! ''
!      'void' for return type and no parameter for parameter types.
  
! 'i'
!      'int' for return type and parameter type
  
! 'f'
!      'float' for return type and parameter type
  
! 'p'
!      'void *' for return type and parameter type
  
   And the function names are:
       void __builtin_custom_n (void);
--- 48718,48740 ----
   The following built-in functions are always available.  They all
  generate a Nios II Custom Instruction.  The name of the function
  represents the types that the function takes and returns.  The letter
! before the ‘n’ is the return type or void if absent.  The ‘n’ represents
  the first parameter to all the custom instructions, the custom
! instruction number.  The two letters after the ‘n’ represent the up to
  two parameters to the function.
  
   The letters represent the following data types:
! ‘’
!      ‘void’ for return type and no parameter for parameter types.
  
! ‘i’
!      ‘int’ for return type and parameter type
  
! ‘f’
!      ‘float’ for return type and parameter type
  
! ‘p’
!      ‘void *’ for return type and parameter type
  
   And the function names are:
       void __builtin_custom_n (void);
*************** generated.
*** 48828,48834 ****
            mov  rREGNO, VAL
  
   -- Built-in Function: int __builtin_arc_divaw (int A, int B)
!      Only available if either '-mcpu=ARC700' or '-meA' is set.
       Generates:
            divaw  DEST, A, B
       where the value in DEST will be the result returned from the
--- 48837,48843 ----
            mov  rREGNO, VAL
  
   -- Built-in Function: int __builtin_arc_divaw (int A, int B)
!      Only available if either ‘-mcpu=ARC700’ or ‘-meA’ is set.
       Generates:
            divaw  DEST, A, B
       where the value in DEST will be the result returned from the
*************** generated.
*** 48846,48857 ****
       built-in.
  
   -- Built-in Function: void __builtin_arc_mul64 (int A, int B)
!      Only available with '-mmul64'.  Generates:
            mul64  A, B
  
   -- Built-in Function: void __builtin_arc_mulu64 (unsigned int A,
            unsigned int B)
!      Only available with '-mmul64'.  Generates:
            mulu64  A, B
  
   -- Built-in Function: void __builtin_arc_nop (void)
--- 48855,48866 ----
       built-in.
  
   -- Built-in Function: void __builtin_arc_mul64 (int A, int B)
!      Only available with ‘-mmul64’.  Generates:
            mul64  A, B
  
   -- Built-in Function: void __builtin_arc_mulu64 (unsigned int A,
            unsigned int B)
!      Only available with ‘-mmul64’.  Generates:
            mulu64  A, B
  
   -- Built-in Function: void __builtin_arc_nop (void)
*************** generated.
*** 48859,48873 ****
            nop
  
   -- Built-in Function: int __builtin_arc_norm (int SRC)
!      Only valid if the 'norm' instruction is available through the
!      '-mnorm' option or by default with '-mcpu=ARC700'.  Generates:
            norm  DEST, SRC
       Where the value in DEST will be the result returned from the
       built-in.
  
   -- Built-in Function: short int __builtin_arc_normw (short int SRC)
!      Only valid if the 'normw' instruction is available through the
!      '-mnorm' option or by default with '-mcpu=ARC700'.  Generates:
            normw  DEST, SRC
       Where the value in DEST will be the result returned from the
       built-in.
--- 48868,48882 ----
            nop
  
   -- Built-in Function: int __builtin_arc_norm (int SRC)
!      Only valid if the ‘norm’ instruction is available through the
!      ‘-mnorm’ option or by default with ‘-mcpu=ARC700’.  Generates:
            norm  DEST, SRC
       Where the value in DEST will be the result returned from the
       built-in.
  
   -- Built-in Function: short int __builtin_arc_normw (short int SRC)
!      Only valid if the ‘normw’ instruction is available through the
!      ‘-mnorm’ option or by default with ‘-mcpu=ARC700’.  Generates:
            normw  DEST, SRC
       Where the value in DEST will be the result returned from the
       built-in.
*************** generated.
*** 48888,48894 ****
            sr  VAL, [AUXR]
  
   -- Built-in Function: int __builtin_arc_swap (int SRC)
!      Only valid with '-mswap'.  Generates:
            swap  DEST, SRC
       Where the value in DEST will be the result returned from the
       built-in.
--- 48897,48903 ----
            sr  VAL, [AUXR]
  
   -- Built-in Function: int __builtin_arc_swap (int SRC)
!      Only valid with ‘-mswap’.  Generates:
            swap  DEST, SRC
       Where the value in DEST will be the result returned from the
       built-in.
*************** generated.
*** 48898,48912 ****
            swi
  
   -- Built-in Function: void __builtin_arc_sync (void)
!      Only available with '-mcpu=ARC700'.  Generates:
            sync
  
   -- Built-in Function: void __builtin_arc_trap_s (unsigned int C)
!      Only available with '-mcpu=ARC700'.  Generates:
            trap_s  C
  
   -- Built-in Function: void __builtin_arc_unimp_s (void)
!      Only available with '-mcpu=ARC700'.  Generates:
            unimp_s
  
   The instructions generated by the following builtins are not considered
--- 48907,48921 ----
            swi
  
   -- Built-in Function: void __builtin_arc_sync (void)
!      Only available with ‘-mcpu=ARC700’.  Generates:
            sync
  
   -- Built-in Function: void __builtin_arc_trap_s (unsigned int C)
!      Only available with ‘-mcpu=ARC700’.  Generates:
            trap_s  C
  
   -- Built-in Function: void __builtin_arc_unimp_s (void)
!      Only available with ‘-mcpu=ARC700’.  Generates:
            unimp_s
  
   The instructions generated by the following builtins are not considered
*************** File: gcc.info,  Node: ARC SIMD Built-in
*** 48930,48938 ****
  
  SIMD builtins provided by the compiler can be used to generate the
  vector instructions.  This section describes the available builtins and
! their usage in programs.  With the '-msimd' option, the compiler
  provides 128-bit vector types, which can be specified using the
! 'vector_size' attribute.  The header file 'arc-simd.h' can be included
  to use the following predefined types:
       typedef int __v4si   __attribute__((vector_size(16)));
       typedef short __v8hi __attribute__((vector_size(16)));
--- 48939,48947 ----
  
  SIMD builtins provided by the compiler can be used to generate the
  vector instructions.  This section describes the available builtins and
! their usage in programs.  With the ‘-msimd’ option, the compiler
  provides 128-bit vector types, which can be specified using the
! ‘vector_size’ attribute.  The header file ‘arc-simd.h’ can be included
  to use the following predefined types:
       typedef int __v4si   __attribute__((vector_size(16)));
       typedef short __v8hi __attribute__((vector_size(16)));
*************** to use the following predefined types:
*** 48941,48948 ****
  functions listed in the following section can be used on these variables
  to generate the vector operations.
  
!  For all builtins, '__builtin_arc_SOMEINSN', the header file
! 'arc-simd.h' also provides equivalent macros called '_SOMEINSN' that can
  be used for programming ease and improved readability.  The following
  macros for DMA control are also provided:
       #define _setup_dma_in_channel_reg _vdiwr
--- 48950,48957 ----
  functions listed in the following section can be used on these variables
  to generate the vector operations.
  
!  For all builtins, ‘__builtin_arc_SOMEINSN’, the header file
! ‘arc-simd.h’ also provides equivalent macros called ‘_SOMEINSN’ that can
  be used for programming ease and improved readability.  The following
  macros for DMA control are also provided:
       #define _setup_dma_in_channel_reg _vdiwr
*************** macros for DMA control are also provided
*** 48951,48957 ****
   The following is a complete list of all the SIMD built-ins provided for
  ARC, grouped by calling signature.
  
!  The following take two '__v8hi' arguments and return a '__v8hi' result:
       __v8hi __builtin_arc_vaddaw (__v8hi, __v8hi);
       __v8hi __builtin_arc_vaddw (__v8hi, __v8hi);
       __v8hi __builtin_arc_vand (__v8hi, __v8hi);
--- 48960,48966 ----
   The following is a complete list of all the SIMD built-ins provided for
  ARC, grouped by calling signature.
  
!  The following take two ‘__v8hi’ arguments and return a ‘__v8hi’ result:
       __v8hi __builtin_arc_vaddaw (__v8hi, __v8hi);
       __v8hi __builtin_arc_vaddw (__v8hi, __v8hi);
       __v8hi __builtin_arc_vand (__v8hi, __v8hi);
*************** ARC, grouped by calling signature.
*** 49001,49008 ****
       __v8hi __builtin_arc_vxor (__v8hi, __v8hi);
       __v8hi __builtin_arc_vxoraw (__v8hi, __v8hi);
  
!  The following take one '__v8hi' and one 'int' argument and return a
! '__v8hi' result:
  
       __v8hi __builtin_arc_vbaddw (__v8hi, int);
       __v8hi __builtin_arc_vbmaxw (__v8hi, int);
--- 49010,49017 ----
       __v8hi __builtin_arc_vxor (__v8hi, __v8hi);
       __v8hi __builtin_arc_vxoraw (__v8hi, __v8hi);
  
!  The following take one ‘__v8hi’ and one ‘int’ argument and return a
! ‘__v8hi’ result:
  
       __v8hi __builtin_arc_vbaddw (__v8hi, int);
       __v8hi __builtin_arc_vbmaxw (__v8hi, int);
*************** ARC, grouped by calling signature.
*** 49013,49027 ****
       __v8hi __builtin_arc_vbrsubw (__v8hi, int);
       __v8hi __builtin_arc_vbsubw (__v8hi, int);
  
!  The following take one '__v8hi' argument and one 'int' argument which
  must be a 3-bit compile time constant indicating a register number
! I0-I7.  They return a '__v8hi' result.
       __v8hi __builtin_arc_vasrw (__v8hi, const int);
       __v8hi __builtin_arc_vsr8 (__v8hi, const int);
       __v8hi __builtin_arc_vsr8aw (__v8hi, const int);
  
!  The following take one '__v8hi' argument and one 'int' argument which
! must be a 6-bit compile time constant.  They return a '__v8hi' result.
       __v8hi __builtin_arc_vasrpwbi (__v8hi, const int);
       __v8hi __builtin_arc_vasrrpwbi (__v8hi, const int);
       __v8hi __builtin_arc_vasrrwi (__v8hi, const int);
--- 49022,49036 ----
       __v8hi __builtin_arc_vbrsubw (__v8hi, int);
       __v8hi __builtin_arc_vbsubw (__v8hi, int);
  
!  The following take one ‘__v8hi’ argument and one ‘int’ argument which
  must be a 3-bit compile time constant indicating a register number
! I0-I7.  They return a ‘__v8hi’ result.
       __v8hi __builtin_arc_vasrw (__v8hi, const int);
       __v8hi __builtin_arc_vsr8 (__v8hi, const int);
       __v8hi __builtin_arc_vsr8aw (__v8hi, const int);
  
!  The following take one ‘__v8hi’ argument and one ‘int’ argument which
! must be a 6-bit compile time constant.  They return a ‘__v8hi’ result.
       __v8hi __builtin_arc_vasrpwbi (__v8hi, const int);
       __v8hi __builtin_arc_vasrrpwbi (__v8hi, const int);
       __v8hi __builtin_arc_vasrrwi (__v8hi, const int);
*************** must be a 6-bit compile time constant.
*** 49030,49049 ****
       __v8hi __builtin_arc_vsr8awi (__v8hi, const int);
       __v8hi __builtin_arc_vsr8i (__v8hi, const int);
  
!  The following take one '__v8hi' argument and one 'int' argument which
! must be a 8-bit compile time constant.  They return a '__v8hi' result.
       __v8hi __builtin_arc_vd6tapf (__v8hi, const int);
       __v8hi __builtin_arc_vmvaw (__v8hi, const int);
       __v8hi __builtin_arc_vmvw (__v8hi, const int);
       __v8hi __builtin_arc_vmvzw (__v8hi, const int);
  
!  The following take two 'int' arguments, the second of which which must
! be a 8-bit compile time constant.  They return a '__v8hi' result:
       __v8hi __builtin_arc_vmovaw (int, const int);
       __v8hi __builtin_arc_vmovw (int, const int);
       __v8hi __builtin_arc_vmovzw (int, const int);
  
!  The following take a single '__v8hi' argument and return a '__v8hi'
  result:
       __v8hi __builtin_arc_vabsaw (__v8hi);
       __v8hi __builtin_arc_vabsw (__v8hi);
--- 49039,49058 ----
       __v8hi __builtin_arc_vsr8awi (__v8hi, const int);
       __v8hi __builtin_arc_vsr8i (__v8hi, const int);
  
!  The following take one ‘__v8hi’ argument and one ‘int’ argument which
! must be a 8-bit compile time constant.  They return a ‘__v8hi’ result.
       __v8hi __builtin_arc_vd6tapf (__v8hi, const int);
       __v8hi __builtin_arc_vmvaw (__v8hi, const int);
       __v8hi __builtin_arc_vmvw (__v8hi, const int);
       __v8hi __builtin_arc_vmvzw (__v8hi, const int);
  
!  The following take two ‘int’ arguments, the second of which which must
! be a 8-bit compile time constant.  They return a ‘__v8hi’ result:
       __v8hi __builtin_arc_vmovaw (int, const int);
       __v8hi __builtin_arc_vmovw (int, const int);
       __v8hi __builtin_arc_vmovzw (int, const int);
  
!  The following take a single ‘__v8hi’ argument and return a ‘__v8hi’
  result:
       __v8hi __builtin_arc_vabsaw (__v8hi);
       __v8hi __builtin_arc_vabsw (__v8hi);
*************** result:
*** 49057,49094 ****
       __v8hi __builtin_arc_vupsbaw (__v8hi);
       __v8hi __builtin_arc_vupsbw (__v8hi);
  
!  The following take two 'int' arguments and return no result:
       void __builtin_arc_vdirun (int, int);
       void __builtin_arc_vdorun (int, int);
  
!  The following take two 'int' arguments and return no result.  The first
  argument must a 3-bit compile time constant indicating one of the
  DR0-DR7 DMA setup channels:
       void __builtin_arc_vdiwr (const int, int);
       void __builtin_arc_vdowr (const int, int);
  
!  The following take an 'int' argument and return no result:
       void __builtin_arc_vendrec (int);
       void __builtin_arc_vrec (int);
       void __builtin_arc_vrecrun (int);
       void __builtin_arc_vrun (int);
  
!  The following take a '__v8hi' argument and two 'int' arguments and
! return a '__v8hi' result.  The second argument must be a 3-bit compile
  time constants, indicating one the registers I0-I7, and the third
  argument must be an 8-bit compile time constant.
  
   _Note:_ Although the equivalent hardware instructions do not take an
  SIMD register as an operand, these builtins overwrite the relevant bits
! of the '__v8hi' register provided as the first argument with the value
! loaded from the '[Ib, u8]' location in the SDM.
  
       __v8hi __builtin_arc_vld32 (__v8hi, const int, const int);
       __v8hi __builtin_arc_vld32wh (__v8hi, const int, const int);
       __v8hi __builtin_arc_vld32wl (__v8hi, const int, const int);
       __v8hi __builtin_arc_vld64 (__v8hi, const int, const int);
  
!  The following take two 'int' arguments and return a '__v8hi' result.
  The first argument must be a 3-bit compile time constants, indicating
  one the registers I0-I7, and the second argument must be an 8-bit
  compile time constant.
--- 49066,49103 ----
       __v8hi __builtin_arc_vupsbaw (__v8hi);
       __v8hi __builtin_arc_vupsbw (__v8hi);
  
!  The following take two ‘int’ arguments and return no result:
       void __builtin_arc_vdirun (int, int);
       void __builtin_arc_vdorun (int, int);
  
!  The following take two ‘int’ arguments and return no result.  The first
  argument must a 3-bit compile time constant indicating one of the
  DR0-DR7 DMA setup channels:
       void __builtin_arc_vdiwr (const int, int);
       void __builtin_arc_vdowr (const int, int);
  
!  The following take an ‘int’ argument and return no result:
       void __builtin_arc_vendrec (int);
       void __builtin_arc_vrec (int);
       void __builtin_arc_vrecrun (int);
       void __builtin_arc_vrun (int);
  
!  The following take a ‘__v8hi’ argument and two ‘int’ arguments and
! return a ‘__v8hi’ result.  The second argument must be a 3-bit compile
  time constants, indicating one the registers I0-I7, and the third
  argument must be an 8-bit compile time constant.
  
   _Note:_ Although the equivalent hardware instructions do not take an
  SIMD register as an operand, these builtins overwrite the relevant bits
! of the ‘__v8hi’ register provided as the first argument with the value
! loaded from the ‘[Ib, u8]’ location in the SDM.
  
       __v8hi __builtin_arc_vld32 (__v8hi, const int, const int);
       __v8hi __builtin_arc_vld32wh (__v8hi, const int, const int);
       __v8hi __builtin_arc_vld32wl (__v8hi, const int, const int);
       __v8hi __builtin_arc_vld64 (__v8hi, const int, const int);
  
!  The following take two ‘int’ arguments and return a ‘__v8hi’ result.
  The first argument must be a 3-bit compile time constants, indicating
  one the registers I0-I7, and the second argument must be an 8-bit
  compile time constant.
*************** compile time constant.
*** 49096,49102 ****
       __v8hi __builtin_arc_vld128 (const int, const int);
       __v8hi __builtin_arc_vld64w (const int, const int);
  
!  The following take a '__v8hi' argument and two 'int' arguments and
  return no result.  The second argument must be a 3-bit compile time
  constants, indicating one the registers I0-I7, and the third argument
  must be an 8-bit compile time constant.
--- 49105,49111 ----
       __v8hi __builtin_arc_vld128 (const int, const int);
       __v8hi __builtin_arc_vld64w (const int, const int);
  
!  The following take a ‘__v8hi’ argument and two ‘int’ arguments and
  return no result.  The second argument must be a 3-bit compile time
  constants, indicating one the registers I0-I7, and the third argument
  must be an 8-bit compile time constant.
*************** must be an 8-bit compile time constant.
*** 49104,49110 ****
       void __builtin_arc_vst128 (__v8hi, const int, const int);
       void __builtin_arc_vst64 (__v8hi, const int, const int);
  
!  The following take a '__v8hi' argument and three 'int' arguments and
  return no result.  The second argument must be a 3-bit compile-time
  constant, identifying the 16-bit sub-register to be stored, the third
  argument must be a 3-bit compile time constants, indicating one the
--- 49113,49119 ----
       void __builtin_arc_vst128 (__v8hi, const int, const int);
       void __builtin_arc_vst64 (__v8hi, const int, const int);
  
!  The following take a ‘__v8hi’ argument and three ‘int’ arguments and
  return no result.  The second argument must be a 3-bit compile-time
  constant, identifying the 16-bit sub-register to be stored, the third
  argument must be a 3-bit compile time constants, indicating one the
*************** File: gcc.info,  Node: ARM iWMMXt Built-
*** 49121,49127 ****
  ------------------------------------
  
  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)));
--- 49130,49136 ----
  ------------------------------------
  
  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)));
*************** enabled.
*** 49287,49293 ****
  
   Currently, ARM and AArch64 back ends do not support ACLE 2.0 fully.
  Both back ends support CRC32 intrinsics and the ARM back end supports
! the Coprocessor intrinsics, all from 'arm_acle.h'.  The ARM back end's
  16-bit floating-point Advanced SIMD intrinsics currently comply to ACLE
  v1.1.  AArch64's back end does not have support for 16-bit floating
  point Advanced SIMD intrinsics yet.
--- 49296,49302 ----
  
   Currently, ARM and AArch64 back ends do not support ACLE 2.0 fully.
  Both back ends support CRC32 intrinsics and the ARM back end supports
! the Coprocessor intrinsics, all from ‘arm_acle.h’.  The ARM back end's
  16-bit floating-point Advanced SIMD intrinsics currently comply to ACLE
  v1.1.  AArch64's back end does not have support for 16-bit floating
  point Advanced SIMD intrinsics yet.
*************** Engineering Specification, which can be
*** 49319,49325 ****
  .
  
   As part of the Security Extensions GCC implements two new function
! attributes: 'cmse_nonsecure_entry' and 'cmse_nonsecure_call'.
  
   As part of the Security Extensions GCC implements the intrinsics below.
  FPTR is used here to mean any function pointer type.
--- 49328,49334 ----
  .
  
   As part of the Security Extensions GCC implements two new function
! attributes: ‘cmse_nonsecure_entry’ and ‘cmse_nonsecure_call’.
  
   As part of the Security Extensions GCC implements the intrinsics below.
  FPTR is used here to mean any function pointer type.
*************** File: gcc.info,  Node: AVR Built-in Func
*** 49346,49391 ****
  For each built-in function for AVR, there is an equally named, uppercase
  built-in macro defined.  That way users can easily query if or if not a
  specific built-in is implemented or not.  For example, if
! '__builtin_avr_nop' is available the macro '__BUILTIN_AVR_NOP' is
! defined to '1' and undefined otherwise.
  
! 'void __builtin_avr_nop (void)'
! 'void __builtin_avr_sei (void)'
! 'void __builtin_avr_cli (void)'
! 'void __builtin_avr_sleep (void)'
! 'void __builtin_avr_wdr (void)'
! 'unsigned char __builtin_avr_swap (unsigned char)'
! 'unsigned int __builtin_avr_fmul (unsigned char, unsigned char)'
! 'int __builtin_avr_fmuls (char, char)'
! 'int __builtin_avr_fmulsu (char, unsigned char)'
       These built-in functions map to the respective machine instruction,
!      i.e. 'nop', 'sei', 'cli', 'sleep', 'wdr', 'swap', 'fmul', 'fmuls'
!      resp.  'fmulsu'.  The three 'fmul*' built-ins are implemented as
       library call if no hardware multiplier is available.
  
! 'void __builtin_avr_delay_cycles (unsigned long ticks)'
       Delay execution for TICKS cycles.  Note that this built-in does not
       take into account the effect of interrupts that might increase
       delay time.  TICKS must be a compile-time integer constant; delays
       with a variable number of cycles are not supported.
  
! 'char __builtin_avr_flash_segment (const __memx void*)'
       This built-in takes a byte address to the 24-bit *note address
!      space: AVR Named Address Spaces. '__memx' and returns the number of
       the flash segment (the 64 KiB chunk) where the address points to.
!      Counting starts at '0'.  If the address does not point to flash
!      memory, return '-1'.
  
! 'uint8_t __builtin_avr_insert_bits (uint32_t map, uint8_t bits, uint8_t val)'
       Insert bits from BITS into VAL and return the resulting value.  The
       nibbles of MAP determine how the insertion is performed: Let X be
       the N-th nibble of MAP
!        1. If X is '0xf', then the N-th bit of VAL is returned unaltered.
  
         2. If X is in the range 0...7, then the N-th result bit is set to
            the X-th bit of BITS
  
!        3. If X is in the range 8...'0xe', then the N-th result bit is
            undefined.
  
       One typical use case for this built-in is adjusting input and
--- 49355,49400 ----
  For each built-in function for AVR, there is an equally named, uppercase
  built-in macro defined.  That way users can easily query if or if not a
  specific built-in is implemented or not.  For example, if
! ‘__builtin_avr_nop’ is available the macro ‘__BUILTIN_AVR_NOP’ is
! defined to ‘1’ and undefined otherwise.
  
! ‘void __builtin_avr_nop (void)’
! ‘void __builtin_avr_sei (void)’
! ‘void __builtin_avr_cli (void)’
! ‘void __builtin_avr_sleep (void)’
! ‘void __builtin_avr_wdr (void)’
! ‘unsigned char __builtin_avr_swap (unsigned char)’
! ‘unsigned int __builtin_avr_fmul (unsigned char, unsigned char)’
! ‘int __builtin_avr_fmuls (char, char)’
! ‘int __builtin_avr_fmulsu (char, unsigned char)’
       These built-in functions map to the respective machine instruction,
!      i.e. ‘nop’, ‘sei’, ‘cli’, ‘sleep’, ‘wdr’, ‘swap’, ‘fmul’, ‘fmuls’
!      resp.  ‘fmulsu’.  The three ‘fmul*’ built-ins are implemented as
       library call if no hardware multiplier is available.
  
! ‘void __builtin_avr_delay_cycles (unsigned long ticks)’
       Delay execution for TICKS cycles.  Note that this built-in does not
       take into account the effect of interrupts that might increase
       delay time.  TICKS must be a compile-time integer constant; delays
       with a variable number of cycles are not supported.
  
! ‘char __builtin_avr_flash_segment (const __memx void*)’
       This built-in takes a byte address to the 24-bit *note address
!      space: AVR Named Address Spaces. ‘__memx’ and returns the number of
       the flash segment (the 64 KiB chunk) where the address points to.
!      Counting starts at ‘0’.  If the address does not point to flash
!      memory, return ‘-1’.
  
! ‘uint8_t __builtin_avr_insert_bits (uint32_t map, uint8_t bits, uint8_t val)’
       Insert bits from BITS into VAL and return the resulting value.  The
       nibbles of MAP determine how the insertion is performed: Let X be
       the N-th nibble of MAP
!        1. If X is ‘0xf’, then the N-th bit of VAL is returned unaltered.
  
         2. If X is in the range 0...7, then the N-th result bit is set to
            the X-th bit of BITS
  
!        3. If X is in the range 8...‘0xe’, then the N-th result bit is
            undefined.
  
       One typical use case for this built-in is adjusting input and
*************** defined to '1' and undefined otherwise.
*** 49407,49420 ****
            // reverse the bit order of bits
            __builtin_avr_insert_bits (0x01234567, bits, 0);
  
! 'void __builtin_avr_nops (unsigned count)'
!      Insert COUNT 'NOP' instructions.  The number of instructions must
       be a compile-time integer constant.
  
  There are many more AVR-specific built-in functions that are used to
  implement the ISO/IEC TR 18037 "Embedded C" fixed-point functions of
  section 7.18a.6.  You don't need to use these built-ins directly.
! Instead, use the declarations as supplied by the 'stdfix.h' header with
  GNU-C99:
  
       #include 
--- 49416,49429 ----
            // reverse the bit order of bits
            __builtin_avr_insert_bits (0x01234567, bits, 0);
  
! ‘void __builtin_avr_nops (unsigned count)’
!      Insert COUNT ‘NOP’ instructions.  The number of instructions must
       be a compile-time integer constant.
  
  There are many more AVR-specific built-in functions that are used to
  implement the ISO/IEC TR 18037 "Embedded C" fixed-point functions of
  section 7.18a.6.  You don't need to use these built-ins directly.
! Instead, use the declarations as supplied by the ‘stdfix.h’ header with
  GNU-C99:
  
       #include 
*************** File: gcc.info,  Node: Blackfin Built-in
*** 49433,49439 ****
  -----------------------------------
  
  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:
--- 49442,49448 ----
  -----------------------------------
  
  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:
*************** The following built-in functions are ava
*** 49451,49468 ****
  
   -- Built-in Function: unsigned long long __builtin_bpf_load_byte
            (unsigned long long OFFSET)
!      Load a byte from the 'struct sk_buff' packet data pointed by the
!      register '%r6' and return it.
  
   -- Built-in Function: unsigned long long __builtin_bpf_load_half
            (unsigned long long OFFSET)
!      Load 16 bits from the 'struct sk_buff' packet data pointed by the
!      register '%r6' and return it.
  
   -- Built-in Function: unsigned long long __builtin_bpf_load_word
            (unsigned long long OFFSET)
!      Load 32 bits from the 'struct sk_buff' packet data pointed by the
!      register '%r6' and return it.
  
   -- Built-in Function: void * __builtin_preserve_access_index (EXPR)
       BPF Compile Once-Run Everywhere (CO-RE) support.  Instruct GCC to
--- 49460,49477 ----
  
   -- Built-in Function: unsigned long long __builtin_bpf_load_byte
            (unsigned long long OFFSET)
!      Load a byte from the ‘struct sk_buff’ packet data pointed by the
!      register ‘%r6’ and return it.
  
   -- Built-in Function: unsigned long long __builtin_bpf_load_half
            (unsigned long long OFFSET)
!      Load 16 bits from the ‘struct sk_buff’ packet data pointed by the
!      register ‘%r6’ and return it.
  
   -- Built-in Function: unsigned long long __builtin_bpf_load_word
            (unsigned long long OFFSET)
!      Load 32 bits from the ‘struct sk_buff’ packet data pointed by the
!      register ‘%r6’ and return it.
  
   -- Built-in Function: void * __builtin_preserve_access_index (EXPR)
       BPF Compile Once-Run Everywhere (CO-RE) support.  Instruct GCC to
*************** The following built-in functions are ava
*** 49471,49477 ****
       is otherwise transparent, the return value is whatever EXPR
       evaluates to.  It is also overloaded: EXPR may be of any type (not
       necessarily a pointer), the return type is the same.  Has no effect
!      if '-mco-re' is not in effect (either specified or implied).
  
   -- Built-in Function: unsigned int __builtin_preserve_field_info (EXPR,
            unsigned int KIND)
--- 49480,49486 ----
       is otherwise transparent, the return value is whatever EXPR
       evaluates to.  It is also overloaded: EXPR may be of any type (not
       necessarily a pointer), the return type is the same.  Has no effect
!      if ‘-mco-re’ is not in effect (either specified or implied).
  
   -- Built-in Function: unsigned int __builtin_preserve_field_info (EXPR,
            unsigned int KIND)
*************** The following built-in functions are ava
*** 49480,49520 ****
       EXPR is an access to a field of a struct or union.  Depending on
       KIND, different information is returned to the program.  A CO-RE
       relocation for the access in EXPR with kind KIND is recorded if
!      '-mco-re' is in effect.
  
       The following values are supported for KIND:
!      'FIELD_BYTE_OFFSET = 0'
            The returned value is the offset, in bytes, of the field from
            the beginning of the containing structure.  For bit-fields,
            this is the byte offset of the containing word.
  
!      'FIELD_BYTE_SIZE = 1'
            The returned value is the size, in bytes, of the field.  For
            bit-fields, this is the size in bytes of the containing word.
  
!      'FIELD_EXISTENCE = 2'
            The returned value is 1 if the field exists, 0 otherwise.
            Always 1 at compile time.
  
!      'FIELD_SIGNEDNESS = 3'
            The returned value is 1 if the field is signed, 0 otherwise.
  
!      'FIELD_LSHIFT_U64 = 4'
!      'FIELD_RSHIFT_U64 = 5'
            The returned value is the number of bits of left- or
            right-shifting (respectively) needed in order to recover the
            original value of the field, after it has been loaded by a
!           read of 'FIELD_BYTE_SIZE' bytes into an unsigned 64-bit value.
            Primarily useful for reading bit-field values from structures
            that may change between kernel versions.
  
       Note that the return value is a constant which is known at compile
!      time.  If the field has a variable offset then 'FIELD_BYTE_OFFSET',
!      'FIELD_LSHIFT_U64', and 'FIELD_RSHIFT_U64' are not supported.
!      Similarly, if the field has a variable size then 'FIELD_BYTE_SIZE',
!      'FIELD_LSHIFT_U64', and 'FIELD_RSHIFT_U64' are not supported.
  
!      For example, '__builtin_preserve_field_info' can be used to
       reliably extract bit-field values from a structure that may change
       between kernel versions:
  
--- 49489,49529 ----
       EXPR is an access to a field of a struct or union.  Depending on
       KIND, different information is returned to the program.  A CO-RE
       relocation for the access in EXPR with kind KIND is recorded if
!      ‘-mco-re’ is in effect.
  
       The following values are supported for KIND:
!      ‘FIELD_BYTE_OFFSET = 0’
            The returned value is the offset, in bytes, of the field from
            the beginning of the containing structure.  For bit-fields,
            this is the byte offset of the containing word.
  
!      ‘FIELD_BYTE_SIZE = 1’
            The returned value is the size, in bytes, of the field.  For
            bit-fields, this is the size in bytes of the containing word.
  
!      ‘FIELD_EXISTENCE = 2’
            The returned value is 1 if the field exists, 0 otherwise.
            Always 1 at compile time.
  
!      ‘FIELD_SIGNEDNESS = 3’
            The returned value is 1 if the field is signed, 0 otherwise.
  
!      ‘FIELD_LSHIFT_U64 = 4’
!      ‘FIELD_RSHIFT_U64 = 5’
            The returned value is the number of bits of left- or
            right-shifting (respectively) needed in order to recover the
            original value of the field, after it has been loaded by a
!           read of ‘FIELD_BYTE_SIZE’ bytes into an unsigned 64-bit value.
            Primarily useful for reading bit-field values from structures
            that may change between kernel versions.
  
       Note that the return value is a constant which is known at compile
!      time.  If the field has a variable offset then ‘FIELD_BYTE_OFFSET’,
!      ‘FIELD_LSHIFT_U64’, and ‘FIELD_RSHIFT_U64’ are not supported.
!      Similarly, if the field has a variable size then ‘FIELD_BYTE_SIZE’,
!      ‘FIELD_LSHIFT_U64’, and ‘FIELD_RSHIFT_U64’ are not supported.
  
!      For example, ‘__builtin_preserve_field_info’ can be used to
       reliably extract bit-field values from a structure that may change
       between kernel versions:
  
*************** File: gcc.info,  Node: FR-V Built-in Fun
*** 49556,49564 ****
  -------------------------------
  
  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
--- 49565,49573 ----
  -------------------------------
  
  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
*************** and return values are given the followin
*** 49586,49615 ****
  
  Pseudo type    Real C type            Constant?   Description
  ----------------------------------------------------------------------------
! 'uh'           'unsigned short'       No          an unsigned halfword
! 'uw1'          'unsigned int'         No          an unsigned word
! 'sw1'          'int'                  No          a signed word
! 'uw2'          'unsigned long long'   No          an unsigned doubleword
! 'sw2'          'long long'            No          a signed doubleword
! 'const'        'int'                  Yes         an integer constant
! 'acc'          'int'                  Yes         an ACC register number
! 'iacc'         'int'                  Yes         an IACC register number
  
   These pseudo types are not defined by GCC, they are simply a notational
  convenience used in this manual.
  
!  Arguments of type 'uh', 'uw1', 'sw1', 'uw2' and 'sw2' are evaluated at
  run time.  They correspond to register operands in the underlying FR-V
  instructions.
  
!  'const' arguments represent immediate operands in the underlying FR-V
  instructions.  They must be compile-time constants.
  
!  'acc' arguments are evaluated at compile time and specify the number of
! an accumulator register.  For example, an 'acc' argument of 2 selects
  the ACC2 register.
  
!  'iacc' arguments are similar to 'acc' arguments but specify the number
  of an IACC register.  See *note Other Built-in Functions:: for more
  details.
  
--- 49595,49624 ----
  
  Pseudo type    Real C type            Constant?   Description
  ----------------------------------------------------------------------------
! ‘uh’           ‘unsigned short’       No          an unsigned halfword
! ‘uw1’          ‘unsigned int’         No          an unsigned word
! ‘sw1’          ‘int’                  No          a signed word
! ‘uw2’          ‘unsigned long long’   No          an unsigned doubleword
! ‘sw2’          ‘long long’            No          a signed doubleword
! ‘const’        ‘int’                  Yes         an integer constant
! ‘acc’          ‘int’                  Yes         an ACC register number
! ‘iacc’         ‘int’                  Yes         an IACC register number
  
   These pseudo types are not defined by GCC, they are simply a notational
  convenience used in this manual.
  
!  Arguments of type ‘uh’, ‘uw1’, ‘sw1’, ‘uw2’ and ‘sw2’ are evaluated at
  run time.  They correspond to register operands in the underlying FR-V
  instructions.
  
!  ‘const’ arguments represent immediate operands in the underlying FR-V
  instructions.  They must be compile-time constants.
  
!  ‘acc’ arguments are evaluated at compile time and specify the number of
! an accumulator register.  For example, an ‘acc’ argument of 2 selects
  the ACC2 register.
  
!  ‘iacc’ arguments are similar to ‘acc’ arguments but specify the number
  of an IACC register.  See *note Other Built-in Functions:: for more
  details.
  
*************** The functions listed below map directly
*** 49623,49638 ****
  
  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
--- 49632,49647 ----
  
  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
*************** The functions listed below map directly
*** 49644,49786 ****
  
  Function prototype               Example usage           Assembly output
  ---------------------------------------------------------------------------
! 'uw1 __MABSHS (sw1)'             'B = __MABSHS (A)'      'MABSHS A,B'
! 'void __MADDACCS (acc, acc)'     '__MADDACCS (B, A)'     'MADDACCS A,B'
! 'sw1 __MADDHSS (sw1, sw1)'       'C = __MADDHSS (A,      'MADDHSS A,B,C'
!                                  B)'
! 'uw1 __MADDHUS (uw1, uw1)'       'C = __MADDHUS (A,      'MADDHUS A,B,C'
!                                  B)'
! 'uw1 __MAND (uw1, uw1)'          'C = __MAND (A, B)'     'MAND A,B,C'
! 'void __MASACCS (acc, acc)'      '__MASACCS (B, A)'      'MASACCS A,B'
! 'uw1 __MAVEH (uw1, uw1)'         'C = __MAVEH (A, B)'    'MAVEH A,B,C'
! 'uw2 __MBTOH (uw1)'              'B = __MBTOH (A)'       'MBTOH A,B'
! 'void __MBTOHE (uw1 *, uw1)'     '__MBTOHE (&B, A)'      'MBTOHE A,B'
! 'void __MCLRACC (acc)'           '__MCLRACC (A)'         'MCLRACC A'
! 'void __MCLRACCA (void)'         '__MCLRACCA ()'         'MCLRACCA'
! 'uw1 __Mcop1 (uw1, uw1)'         'C = __Mcop1 (A, B)'    'Mcop1 A,B,C'
! 'uw1 __Mcop2 (uw1, uw1)'         'C = __Mcop2 (A, B)'    'Mcop2 A,B,C'
! 'uw1 __MCPLHI (uw2, const)'      'C = __MCPLHI (A, B)'   'MCPLHI A,#B,C'
! 'uw1 __MCPLI (uw2, const)'       'C = __MCPLI (A, B)'    'MCPLI A,#B,C'
! 'void __MCPXIS (acc, sw1,        '__MCPXIS (C, A, B)'    'MCPXIS A,B,C'
! sw1)'
! 'void __MCPXIU (acc, uw1,        '__MCPXIU (C, A, B)'    'MCPXIU A,B,C'
! uw1)'
! 'void __MCPXRS (acc, sw1,        '__MCPXRS (C, A, B)'    'MCPXRS A,B,C'
! sw1)'
! 'void __MCPXRU (acc, uw1,        '__MCPXRU (C, A, B)'    'MCPXRU A,B,C'
! uw1)'
! 'uw1 __MCUT (acc, uw1)'          'C = __MCUT (A, B)'     'MCUT A,B,C'
! 'uw1 __MCUTSS (acc, sw1)'        'C = __MCUTSS (A, B)'   'MCUTSS A,B,C'
! 'void __MDADDACCS (acc, acc)'    '__MDADDACCS (B, A)'    'MDADDACCS A,B'
! 'void __MDASACCS (acc, acc)'     '__MDASACCS (B, A)'     'MDASACCS A,B'
! 'uw2 __MDCUTSSI (acc, const)'    'C = __MDCUTSSI (A,     'MDCUTSSI
!                                  B)'                     A,#B,C'
! 'uw2 __MDPACKH (uw2, uw2)'       'C = __MDPACKH (A,      'MDPACKH A,B,C'
!                                  B)'
! 'uw2 __MDROTLI (uw2, const)'     'C = __MDROTLI (A,      'MDROTLI
!                                  B)'                     A,#B,C'
! 'void __MDSUBACCS (acc, acc)'    '__MDSUBACCS (B, A)'    'MDSUBACCS A,B'
! 'void __MDUNPACKH (uw1 *,        '__MDUNPACKH (&B, A)'   'MDUNPACKH A,B'
! uw2)'
! 'uw2 __MEXPDHD (uw1, const)'     'C = __MEXPDHD (A,      'MEXPDHD
!                                  B)'                     A,#B,C'
! 'uw1 __MEXPDHW (uw1, const)'     'C = __MEXPDHW (A,      'MEXPDHW
!                                  B)'                     A,#B,C'
! 'uw1 __MHDSETH (uw1, const)'     'C = __MHDSETH (A,      'MHDSETH
!                                  B)'                     A,#B,C'
! 'sw1 __MHDSETS (const)'          'B = __MHDSETS (A)'     'MHDSETS #A,B'
! 'uw1 __MHSETHIH (uw1, const)'    'B = __MHSETHIH (B,     'MHSETHIH #A,B'
!                                  A)'
! 'sw1 __MHSETHIS (sw1, const)'    'B = __MHSETHIS (B,     'MHSETHIS #A,B'
!                                  A)'
! 'uw1 __MHSETLOH (uw1, const)'    'B = __MHSETLOH (B,     'MHSETLOH #A,B'
!                                  A)'
! 'sw1 __MHSETLOS (sw1, const)'    'B = __MHSETLOS (B,     'MHSETLOS #A,B'
!                                  A)'
! 'uw1 __MHTOB (uw2)'              'B = __MHTOB (A)'       'MHTOB A,B'
! 'void __MMACHS (acc, sw1,        '__MMACHS (C, A, B)'    'MMACHS A,B,C'
! sw1)'
! 'void __MMACHU (acc, uw1,        '__MMACHU (C, A, B)'    'MMACHU A,B,C'
! uw1)'
! 'void __MMRDHS (acc, sw1,        '__MMRDHS (C, A, B)'    'MMRDHS A,B,C'
! sw1)'
! 'void __MMRDHU (acc, uw1,        '__MMRDHU (C, A, B)'    'MMRDHU A,B,C'
! uw1)'
! 'void __MMULHS (acc, sw1,        '__MMULHS (C, A, B)'    'MMULHS A,B,C'
! sw1)'
! 'void __MMULHU (acc, uw1,        '__MMULHU (C, A, B)'    'MMULHU A,B,C'
! uw1)'
! 'void __MMULXHS (acc, sw1,       '__MMULXHS (C, A, B)'   'MMULXHS A,B,C'
! sw1)'
! 'void __MMULXHU (acc, uw1,       '__MMULXHU (C, A, B)'   'MMULXHU A,B,C'
! uw1)'
! 'uw1 __MNOT (uw1)'               'B = __MNOT (A)'        'MNOT A,B'
! 'uw1 __MOR (uw1, uw1)'           'C = __MOR (A, B)'      'MOR A,B,C'
! 'uw1 __MPACKH (uh, uh)'          'C = __MPACKH (A, B)'   'MPACKH A,B,C'
! 'sw2 __MQADDHSS (sw2, sw2)'      'C = __MQADDHSS (A,     'MQADDHSS
!                                  B)'                     A,B,C'
! 'uw2 __MQADDHUS (uw2, uw2)'      'C = __MQADDHUS (A,     'MQADDHUS
!                                  B)'                     A,B,C'
! 'void __MQCPXIS (acc, sw2,       '__MQCPXIS (C, A, B)'   'MQCPXIS A,B,C'
! sw2)'
! 'void __MQCPXIU (acc, uw2,       '__MQCPXIU (C, A, B)'   'MQCPXIU A,B,C'
! uw2)'
! 'void __MQCPXRS (acc, sw2,       '__MQCPXRS (C, A, B)'   'MQCPXRS A,B,C'
! sw2)'
! 'void __MQCPXRU (acc, uw2,       '__MQCPXRU (C, A, B)'   'MQCPXRU A,B,C'
! uw2)'
! 'sw2 __MQLCLRHS (sw2, sw2)'      'C = __MQLCLRHS (A,     'MQLCLRHS
!                                  B)'                     A,B,C'
! 'sw2 __MQLMTHS (sw2, sw2)'       'C = __MQLMTHS (A,      'MQLMTHS A,B,C'
!                                  B)'
! 'void __MQMACHS (acc, sw2,       '__MQMACHS (C, A, B)'   'MQMACHS A,B,C'
! sw2)'
! 'void __MQMACHU (acc, uw2,       '__MQMACHU (C, A, B)'   'MQMACHU A,B,C'
! uw2)'
! 'void __MQMACXHS (acc, sw2,      '__MQMACXHS (C, A,      'MQMACXHS
! sw2)'                            B)'                     A,B,C'
! 'void __MQMULHS (acc, sw2,       '__MQMULHS (C, A, B)'   'MQMULHS A,B,C'
! sw2)'
! 'void __MQMULHU (acc, uw2,       '__MQMULHU (C, A, B)'   'MQMULHU A,B,C'
! uw2)'
! 'void __MQMULXHS (acc, sw2,      '__MQMULXHS (C, A,      'MQMULXHS
! sw2)'                            B)'                     A,B,C'
! 'void __MQMULXHU (acc, uw2,      '__MQMULXHU (C, A,      'MQMULXHU
! uw2)'                            B)'                     A,B,C'
! 'sw2 __MQSATHS (sw2, sw2)'       'C = __MQSATHS (A,      'MQSATHS A,B,C'
!                                  B)'
! 'uw2 __MQSLLHI (uw2, int)'       'C = __MQSLLHI (A,      'MQSLLHI A,B,C'
!                                  B)'
! 'sw2 __MQSRAHI (sw2, int)'       'C = __MQSRAHI (A,      'MQSRAHI A,B,C'
!                                  B)'
! 'sw2 __MQSUBHSS (sw2, sw2)'      'C = __MQSUBHSS (A,     'MQSUBHSS
!                                  B)'                     A,B,C'
! 'uw2 __MQSUBHUS (uw2, uw2)'      'C = __MQSUBHUS (A,     'MQSUBHUS
!                                  B)'                     A,B,C'
! 'void __MQXMACHS (acc, sw2,      '__MQXMACHS (C, A,      'MQXMACHS
! sw2)'                            B)'                     A,B,C'
! 'void __MQXMACXHS (acc, sw2,     '__MQXMACXHS (C, A,     'MQXMACXHS
! sw2)'                            B)'                     A,B,C'
! 'uw1 __MRDACC (acc)'             'B = __MRDACC (A)'      'MRDACC A,B'
! 'uw1 __MRDACCG (acc)'            'B = __MRDACCG (A)'     'MRDACCG A,B'
! 'uw1 __MROTLI (uw1, const)'      'C = __MROTLI (A, B)'   'MROTLI A,#B,C'
! 'uw1 __MROTRI (uw1, const)'      'C = __MROTRI (A, B)'   'MROTRI A,#B,C'
! 'sw1 __MSATHS (sw1, sw1)'        'C = __MSATHS (A, B)'   'MSATHS A,B,C'
! 'uw1 __MSATHU (uw1, uw1)'        'C = __MSATHU (A, B)'   'MSATHU A,B,C'
! 'uw1 __MSLLHI (uw1, const)'      'C = __MSLLHI (A, B)'   'MSLLHI A,#B,C'
! 'sw1 __MSRAHI (sw1, const)'      'C = __MSRAHI (A, B)'   'MSRAHI A,#B,C'
! 'uw1 __MSRLHI (uw1, const)'      'C = __MSRLHI (A, B)'   'MSRLHI A,#B,C'
! 'void __MSUBACCS (acc, acc)'     '__MSUBACCS (B, A)'     'MSUBACCS A,B'
! 'sw1 __MSUBHSS (sw1, sw1)'       'C = __MSUBHSS (A,      'MSUBHSS A,B,C'
!                                  B)'
! 'uw1 __MSUBHUS (uw1, uw1)'       'C = __MSUBHUS (A,      'MSUBHUS A,B,C'
!                                  B)'
! 'void __MTRAP (void)'            '__MTRAP ()'            'MTRAP'
! 'uw2 __MUNPACKH (uw1)'           'B = __MUNPACKH (A)'    'MUNPACKH A,B'
! 'uw1 __MWCUT (uw2, uw1)'         'C = __MWCUT (A, B)'    'MWCUT A,B,C'
! 'void __MWTACC (acc, uw1)'       '__MWTACC (B, A)'       'MWTACC A,B'
! 'void __MWTACCG (acc, uw1)'      '__MWTACCG (B, A)'      'MWTACCG A,B'
! 'uw1 __MXOR (uw1, uw1)'          'C = __MXOR (A, B)'     'MXOR A,B,C'
  
  
  File: gcc.info,  Node: Raw read/write Functions,  Next: Other Built-in Functions,  Prev: Directly-mapped Media Functions,  Up: FR-V Built-in Functions
--- 49653,49795 ----
  
  Function prototype               Example usage           Assembly output
  ---------------------------------------------------------------------------
! ‘uw1 __MABSHS (sw1)’             ‘B = __MABSHS (A)’      ‘MABSHS A,B’
! ‘void __MADDACCS (acc, acc)’     ‘__MADDACCS (B, A)’     ‘MADDACCS A,B’
! ‘sw1 __MADDHSS (sw1, sw1)’       ‘C = __MADDHSS (A,      ‘MADDHSS A,B,C’
!                                  B)’
! ‘uw1 __MADDHUS (uw1, uw1)’       ‘C = __MADDHUS (A,      ‘MADDHUS A,B,C’
!                                  B)’
! ‘uw1 __MAND (uw1, uw1)’          ‘C = __MAND (A, B)’     ‘MAND A,B,C’
! ‘void __MASACCS (acc, acc)’      ‘__MASACCS (B, A)’      ‘MASACCS A,B’
! ‘uw1 __MAVEH (uw1, uw1)’         ‘C = __MAVEH (A, B)’    ‘MAVEH A,B,C’
! ‘uw2 __MBTOH (uw1)’              ‘B = __MBTOH (A)’       ‘MBTOH A,B’
! ‘void __MBTOHE (uw1 *, uw1)’     ‘__MBTOHE (&B, A)’      ‘MBTOHE A,B’
! ‘void __MCLRACC (acc)’           ‘__MCLRACC (A)’         ‘MCLRACC A’
! ‘void __MCLRACCA (void)’         ‘__MCLRACCA ()’         ‘MCLRACCA’
! ‘uw1 __Mcop1 (uw1, uw1)’         ‘C = __Mcop1 (A, B)’    ‘Mcop1 A,B,C’
! ‘uw1 __Mcop2 (uw1, uw1)’         ‘C = __Mcop2 (A, B)’    ‘Mcop2 A,B,C’
! ‘uw1 __MCPLHI (uw2, const)’      ‘C = __MCPLHI (A, B)’   ‘MCPLHI A,#B,C’
! ‘uw1 __MCPLI (uw2, const)’       ‘C = __MCPLI (A, B)’    ‘MCPLI A,#B,C’
! ‘void __MCPXIS (acc, sw1,        ‘__MCPXIS (C, A, B)’    ‘MCPXIS A,B,C’
! sw1)’
! ‘void __MCPXIU (acc, uw1,        ‘__MCPXIU (C, A, B)’    ‘MCPXIU A,B,C’
! uw1)’
! ‘void __MCPXRS (acc, sw1,        ‘__MCPXRS (C, A, B)’    ‘MCPXRS A,B,C’
! sw1)’
! ‘void __MCPXRU (acc, uw1,        ‘__MCPXRU (C, A, B)’    ‘MCPXRU A,B,C’
! uw1)’
! ‘uw1 __MCUT (acc, uw1)’          ‘C = __MCUT (A, B)’     ‘MCUT A,B,C’
! ‘uw1 __MCUTSS (acc, sw1)’        ‘C = __MCUTSS (A, B)’   ‘MCUTSS A,B,C’
! ‘void __MDADDACCS (acc, acc)’    ‘__MDADDACCS (B, A)’    ‘MDADDACCS A,B’
! ‘void __MDASACCS (acc, acc)’     ‘__MDASACCS (B, A)’     ‘MDASACCS A,B’
! ‘uw2 __MDCUTSSI (acc, const)’    ‘C = __MDCUTSSI (A,     ‘MDCUTSSI
!                                  B)’                     A,#B,C’
! ‘uw2 __MDPACKH (uw2, uw2)’       ‘C = __MDPACKH (A,      ‘MDPACKH A,B,C’
!                                  B)’
! ‘uw2 __MDROTLI (uw2, const)’     ‘C = __MDROTLI (A,      ‘MDROTLI
!                                  B)’                     A,#B,C’
! ‘void __MDSUBACCS (acc, acc)’    ‘__MDSUBACCS (B, A)’    ‘MDSUBACCS A,B’
! ‘void __MDUNPACKH (uw1 *,        ‘__MDUNPACKH (&B, A)’   ‘MDUNPACKH A,B’
! uw2)’
! ‘uw2 __MEXPDHD (uw1, const)’     ‘C = __MEXPDHD (A,      ‘MEXPDHD
!                                  B)’                     A,#B,C’
! ‘uw1 __MEXPDHW (uw1, const)’     ‘C = __MEXPDHW (A,      ‘MEXPDHW
!                                  B)’                     A,#B,C’
! ‘uw1 __MHDSETH (uw1, const)’     ‘C = __MHDSETH (A,      ‘MHDSETH
!                                  B)’                     A,#B,C’
! ‘sw1 __MHDSETS (const)’          ‘B = __MHDSETS (A)’     ‘MHDSETS #A,B’
! ‘uw1 __MHSETHIH (uw1, const)’    ‘B = __MHSETHIH (B,     ‘MHSETHIH #A,B’
!                                  A)’
! ‘sw1 __MHSETHIS (sw1, const)’    ‘B = __MHSETHIS (B,     ‘MHSETHIS #A,B’
!                                  A)’
! ‘uw1 __MHSETLOH (uw1, const)’    ‘B = __MHSETLOH (B,     ‘MHSETLOH #A,B’
!                                  A)’
! ‘sw1 __MHSETLOS (sw1, const)’    ‘B = __MHSETLOS (B,     ‘MHSETLOS #A,B’
!                                  A)’
! ‘uw1 __MHTOB (uw2)’              ‘B = __MHTOB (A)’       ‘MHTOB A,B’
! ‘void __MMACHS (acc, sw1,        ‘__MMACHS (C, A, B)’    ‘MMACHS A,B,C’
! sw1)’
! ‘void __MMACHU (acc, uw1,        ‘__MMACHU (C, A, B)’    ‘MMACHU A,B,C’
! uw1)’
! ‘void __MMRDHS (acc, sw1,        ‘__MMRDHS (C, A, B)’    ‘MMRDHS A,B,C’
! sw1)’
! ‘void __MMRDHU (acc, uw1,        ‘__MMRDHU (C, A, B)’    ‘MMRDHU A,B,C’
! uw1)’
! ‘void __MMULHS (acc, sw1,        ‘__MMULHS (C, A, B)’    ‘MMULHS A,B,C’
! sw1)’
! ‘void __MMULHU (acc, uw1,        ‘__MMULHU (C, A, B)’    ‘MMULHU A,B,C’
! uw1)’
! ‘void __MMULXHS (acc, sw1,       ‘__MMULXHS (C, A, B)’   ‘MMULXHS A,B,C’
! sw1)’
! ‘void __MMULXHU (acc, uw1,       ‘__MMULXHU (C, A, B)’   ‘MMULXHU A,B,C’
! uw1)’
! ‘uw1 __MNOT (uw1)’               ‘B = __MNOT (A)’        ‘MNOT A,B’
! ‘uw1 __MOR (uw1, uw1)’           ‘C = __MOR (A, B)’      ‘MOR A,B,C’
! ‘uw1 __MPACKH (uh, uh)’          ‘C = __MPACKH (A, B)’   ‘MPACKH A,B,C’
! ‘sw2 __MQADDHSS (sw2, sw2)’      ‘C = __MQADDHSS (A,     ‘MQADDHSS
!                                  B)’                     A,B,C’
! ‘uw2 __MQADDHUS (uw2, uw2)’      ‘C = __MQADDHUS (A,     ‘MQADDHUS
!                                  B)’                     A,B,C’
! ‘void __MQCPXIS (acc, sw2,       ‘__MQCPXIS (C, A, B)’   ‘MQCPXIS A,B,C’
! sw2)’
! ‘void __MQCPXIU (acc, uw2,       ‘__MQCPXIU (C, A, B)’   ‘MQCPXIU A,B,C’
! uw2)’
! ‘void __MQCPXRS (acc, sw2,       ‘__MQCPXRS (C, A, B)’   ‘MQCPXRS A,B,C’
! sw2)’
! ‘void __MQCPXRU (acc, uw2,       ‘__MQCPXRU (C, A, B)’   ‘MQCPXRU A,B,C’
! uw2)’
! ‘sw2 __MQLCLRHS (sw2, sw2)’      ‘C = __MQLCLRHS (A,     ‘MQLCLRHS
!                                  B)’                     A,B,C’
! ‘sw2 __MQLMTHS (sw2, sw2)’       ‘C = __MQLMTHS (A,      ‘MQLMTHS A,B,C’
!                                  B)’
! ‘void __MQMACHS (acc, sw2,       ‘__MQMACHS (C, A, B)’   ‘MQMACHS A,B,C’
! sw2)’
! ‘void __MQMACHU (acc, uw2,       ‘__MQMACHU (C, A, B)’   ‘MQMACHU A,B,C’
! uw2)’
! ‘void __MQMACXHS (acc, sw2,      ‘__MQMACXHS (C, A,      ‘MQMACXHS
! sw2)’                            B)’                     A,B,C’
! ‘void __MQMULHS (acc, sw2,       ‘__MQMULHS (C, A, B)’   ‘MQMULHS A,B,C’
! sw2)’
! ‘void __MQMULHU (acc, uw2,       ‘__MQMULHU (C, A, B)’   ‘MQMULHU A,B,C’
! uw2)’
! ‘void __MQMULXHS (acc, sw2,      ‘__MQMULXHS (C, A,      ‘MQMULXHS
! sw2)’                            B)’                     A,B,C’
! ‘void __MQMULXHU (acc, uw2,      ‘__MQMULXHU (C, A,      ‘MQMULXHU
! uw2)’                            B)’                     A,B,C’
! ‘sw2 __MQSATHS (sw2, sw2)’       ‘C = __MQSATHS (A,      ‘MQSATHS A,B,C’
!                                  B)’
! ‘uw2 __MQSLLHI (uw2, int)’       ‘C = __MQSLLHI (A,      ‘MQSLLHI A,B,C’
!                                  B)’
! ‘sw2 __MQSRAHI (sw2, int)’       ‘C = __MQSRAHI (A,      ‘MQSRAHI A,B,C’
!                                  B)’
! ‘sw2 __MQSUBHSS (sw2, sw2)’      ‘C = __MQSUBHSS (A,     ‘MQSUBHSS
!                                  B)’                     A,B,C’
! ‘uw2 __MQSUBHUS (uw2, uw2)’      ‘C = __MQSUBHUS (A,     ‘MQSUBHUS
!                                  B)’                     A,B,C’
! ‘void __MQXMACHS (acc, sw2,      ‘__MQXMACHS (C, A,      ‘MQXMACHS
! sw2)’                            B)’                     A,B,C’
! ‘void __MQXMACXHS (acc, sw2,     ‘__MQXMACXHS (C, A,     ‘MQXMACXHS
! sw2)’                            B)’                     A,B,C’
! ‘uw1 __MRDACC (acc)’             ‘B = __MRDACC (A)’      ‘MRDACC A,B’
! ‘uw1 __MRDACCG (acc)’            ‘B = __MRDACCG (A)’     ‘MRDACCG A,B’
! ‘uw1 __MROTLI (uw1, const)’      ‘C = __MROTLI (A, B)’   ‘MROTLI A,#B,C’
! ‘uw1 __MROTRI (uw1, const)’      ‘C = __MROTRI (A, B)’   ‘MROTRI A,#B,C’
! ‘sw1 __MSATHS (sw1, sw1)’        ‘C = __MSATHS (A, B)’   ‘MSATHS A,B,C’
! ‘uw1 __MSATHU (uw1, uw1)’        ‘C = __MSATHU (A, B)’   ‘MSATHU A,B,C’
! ‘uw1 __MSLLHI (uw1, const)’      ‘C = __MSLLHI (A, B)’   ‘MSLLHI A,#B,C’
! ‘sw1 __MSRAHI (sw1, const)’      ‘C = __MSRAHI (A, B)’   ‘MSRAHI A,#B,C’
! ‘uw1 __MSRLHI (uw1, const)’      ‘C = __MSRLHI (A, B)’   ‘MSRLHI A,#B,C’
! ‘void __MSUBACCS (acc, acc)’     ‘__MSUBACCS (B, A)’     ‘MSUBACCS A,B’
! ‘sw1 __MSUBHSS (sw1, sw1)’       ‘C = __MSUBHSS (A,      ‘MSUBHSS A,B,C’
!                                  B)’
! ‘uw1 __MSUBHUS (uw1, uw1)’       ‘C = __MSUBHUS (A,      ‘MSUBHUS A,B,C’
!                                  B)’
! ‘void __MTRAP (void)’            ‘__MTRAP ()’            ‘MTRAP’
! ‘uw2 __MUNPACKH (uw1)’           ‘B = __MUNPACKH (A)’    ‘MUNPACKH A,B’
! ‘uw1 __MWCUT (uw2, uw1)’         ‘C = __MWCUT (A, B)’    ‘MWCUT A,B,C’
! ‘void __MWTACC (acc, uw1)’       ‘__MWTACC (B, A)’       ‘MWTACC A,B’
! ‘void __MWTACCG (acc, uw1)’      ‘__MWTACCG (B, A)’      ‘MWTACCG A,B’
! ‘uw1 __MXOR (uw1, uw1)’          ‘C = __MXOR (A, B)’     ‘MXOR A,B,C’
  
  
  File: gcc.info,  Node: Raw read/write Functions,  Next: Other Built-in Functions,  Prev: Directly-mapped Media Functions,  Up: FR-V Built-in Functions
*************** File: gcc.info,  Node: Raw read/write Fu
*** 49789,49807 ****
  ..................................
  
  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
--- 49798,49816 ----
  ..................................
  
  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
*************** File: gcc.info,  Node: Other Built-in Fu
*** 49812,49839 ****
  This section describes built-in functions that are not named after a
  specific FR-V instruction.
  
! 'sw2 __IACCreadll (iacc REG)'
       Return the full 64-bit value of IACC0.  The REG argument is
       reserved for future expansion and must be 0.
  
! 'sw1 __IACCreadl (iacc REG)'
       Return the value of IACC0H if REG is 0 and IACC0L if REG is 1.
       Other values of REG are rejected as invalid.
  
! 'void __IACCsetll (iacc REG, sw2 X)'
       Set the full 64-bit value of IACC0 to X.  The REG argument is
       reserved for future expansion and must be 0.
  
! 'void __IACCsetl (iacc REG, sw1 X)'
       Set IACC0H to X if REG is 0 and IACC0L to X if REG is 1.  Other
       values of REG are rejected as invalid.
  
! 'void __data_prefetch0 (const void *X)'
!      Use the 'dcpl' instruction to load the contents of address X into
       the data cache.
  
! 'void __data_prefetch (const void *X)'
!      Use the 'nldub' instruction to load the contents of address X into
       the data cache.  The instruction is issued in slot I1.
  
  
--- 49821,49848 ----
  This section describes built-in functions that are not named after a
  specific FR-V instruction.
  
! ‘sw2 __IACCreadll (iacc REG)’
       Return the full 64-bit value of IACC0.  The REG argument is
       reserved for future expansion and must be 0.
  
! ‘sw1 __IACCreadl (iacc REG)’
       Return the value of IACC0H if REG is 0 and IACC0L if REG is 1.
       Other values of REG are rejected as invalid.
  
! ‘void __IACCsetll (iacc REG, sw2 X)’
       Set the full 64-bit value of IACC0 to X.  The REG argument is
       reserved for future expansion and must be 0.
  
! ‘void __IACCsetl (iacc REG, sw1 X)’
       Set IACC0H to X if REG is 0 and IACC0L to X if REG is 1.  Other
       values of REG are rejected as invalid.
  
! ‘void __data_prefetch0 (const void *X)’
!      Use the ‘dcpl’ instruction to load the contents of address X into
       the data cache.
  
! ‘void __data_prefetch (const void *X)’
!      Use the ‘nldub’ instruction to load the contents of address X into
       the data cache.  The instruction is issued in slot I1.
  
  
*************** File: gcc.info,  Node: LoongArch Base Bu
*** 49845,49854 ****
  These built-in functions are available for LoongArch.
  
   Data Type Description:
!    * 'imm0_31', a compile-time constant in range 0 to 31;
!    * 'imm0_16383', a compile-time constant in range 0 to 16383;
!    * 'imm0_32767', a compile-time constant in range 0 to 32767;
!    * 'imm_n2048_2047', a compile-time constant in range -2048 to 2047;
  
   The intrinsics provided are listed below:
           unsigned int __builtin_loongarch_movfcsr2gr (imm0_31)
--- 49854,49863 ----
  These built-in functions are available for LoongArch.
  
   Data Type Description:
!    • ‘imm0_31’, a compile-time constant in range 0 to 31;
!    • ‘imm0_16383’, a compile-time constant in range 0 to 16383;
!    • ‘imm0_32767’, a compile-time constant in range 0 to 32767;
!    • ‘imm_n2048_2047’, a compile-time constant in range -2048 to 2047;
  
   The intrinsics provided are listed below:
           unsigned int __builtin_loongarch_movfcsr2gr (imm0_31)
*************** implemented as follows:
*** 49901,49909 ****
         __builtin_loongarch_csrrd_d  // When reading the 64-bit control register use.
  
   For the convenience of use, the built-in functions are encapsulated,
! the encapsulated functions and '__drdtime_t, __rdtime_t' are defined in
! the 'larchintrin.h'.  So if you call the following function you need to
! include 'larchintrin.h'.
  
            typedef struct drdtime{
                   unsigned long dvalue;
--- 49910,49918 ----
         __builtin_loongarch_csrrd_d  // When reading the 64-bit control register use.
  
   For the convenience of use, the built-in functions are encapsulated,
! the encapsulated functions and ‘__drdtime_t, __rdtime_t’ are defined in
! the ‘larchintrin.h’.  So if you call the following function you need to
! include ‘larchintrin.h’.
  
            typedef struct drdtime{
                   unsigned long dvalue;
*************** include 'larchintrin.h'.
*** 49958,49964 ****
           void __syscall (imm0_32767)
           void __break (imm0_32767)
  
!  Returns the value that is currently set in the 'tp' register.
           void * __builtin_thread_pointer (void)
  
  
--- 49967,49973 ----
           void __syscall (imm0_32767)
           void __break (imm0_32767)
  
!  Returns the value that is currently set in the ‘tp’ register.
           void * __builtin_thread_pointer (void)
  
  
*************** media applications.  It provides instruc
*** 49974,49986 ****
  
   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
--- 49983,49995 ----
  
   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
*************** instructions.
*** 49990,50006 ****
  
   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};
--- 49999,50015 ----
  
   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};
*************** way as aggregates.  For example:
*** 50015,50046 ****
  packed.  On little-endian targets, the first value is the least
  significant and the last value is the most significant.  The opposite
  order applies to big-endian targets.  For example, the code above sets
! the lowest byte of 'a' to '1' on little-endian targets and '4' on
  big-endian targets.
  
   _Note:_ Q7, Q15 and Q31 values must be initialized with their integer
  representation.  As shown in this example, the integer representation of
  a Q7 value can be obtained by multiplying the fractional value by
! '0x1.0p7'.  The equivalent for Q15 values is to multiply by '0x1.0p15'.
! The equivalent for Q31 values is to multiply by '0x1.0p31'.
  
!  The table below lists the 'v4i8' and 'v2q15' operations for which
! hardware support exists.  'a' and 'b' are 'v4i8' values, and 'c' and 'd'
! are 'v2q15' values.
  
  C code                               MIPS instruction
  --------------------------------------------------------------------------
! 'a + b'                              'addu.qb'
! 'c + d'                              'addq.ph'
! 'a - b'                              'subu.qb'
! 'c - d'                              'subq.ph'
  
!  The table below lists the 'v2i16' operation for which hardware support
! exists for the DSP ASE REV 2.  'e' and 'f' are 'v2i16' values.
  
  C code                               MIPS instruction
  --------------------------------------------------------------------------
! 'e * f'                              'mul.ph'
  
   It is easier to describe the DSP built-in functions if we first define
  the following types:
--- 50024,50055 ----
  packed.  On little-endian targets, the first value is the least
  significant and the last value is the most significant.  The opposite
  order applies to big-endian targets.  For example, the code above sets
! the lowest byte of ‘a’ to ‘1’ on little-endian targets and ‘4’ on
  big-endian targets.
  
   _Note:_ Q7, Q15 and Q31 values must be initialized with their integer
  representation.  As shown in this example, the integer representation of
  a Q7 value can be obtained by multiplying the fractional value by
! ‘0x1.0p7’.  The equivalent for Q15 values is to multiply by ‘0x1.0p15’.
! The equivalent for Q31 values is to multiply by ‘0x1.0p31’.
  
!  The table below lists the ‘v4i8’ and ‘v2q15’ operations for which
! hardware support exists.  ‘a’ and ‘b’ are ‘v4i8’ values, and ‘c’ and ‘d’
! are ‘v2q15’ values.
  
  C code                               MIPS instruction
  --------------------------------------------------------------------------
! ‘a + b’                              ‘addu.qb’
! ‘c + d’                              ‘addq.ph’
! ‘a - b’                              ‘subu.qb’
! ‘c - d’                              ‘subq.ph’
  
!  The table below lists the ‘v2i16’ operation for which hardware support
! exists for the DSP ASE REV 2.  ‘e’ and ‘f’ are ‘v2i16’ values.
  
  C code                               MIPS instruction
  --------------------------------------------------------------------------
! ‘e * f’                              ‘mul.ph’
  
   It is easier to describe the DSP built-in functions if we first define
  the following types:
*************** the following types:
*** 50050,50060 ****
       typedef unsigned int ui32;
       typedef long long a64;
  
!  'q31' and 'i32' are actually the same as 'int', but we use 'q31' to
! indicate a Q31 fractional value and 'i32' to indicate a 32-bit integer
! value.  Similarly, 'a64' is the same as 'long long', but we use 'a64' to
  indicate values that are placed in one of the four DSP accumulators
! ('$ac0', '$ac1', '$ac2' or '$ac3').
  
   Also, some built-in functions prefer or require immediate numbers as
  parameters, because the corresponding DSP instructions accept both
--- 50059,50069 ----
       typedef unsigned int ui32;
       typedef long long a64;
  
!  ‘q31’ and ‘i32’ are actually the same as ‘int’, but we use ‘q31’ to
! indicate a Q31 fractional value and ‘i32’ to indicate a 32-bit integer
! value.  Similarly, ‘a64’ is the same as ‘long long’, but we use ‘a64’ to
  indicate values that are placed in one of the four DSP accumulators
! (‘$ac0’, ‘$ac1’, ‘$ac2’ or ‘$ac3’).
  
   Also, some built-in functions prefer or require immediate numbers as
  parameters, because the corresponding DSP instructions accept both
*************** the "upper half" and the other being des
*** 50250,50263 ****
   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};
--- 50259,50272 ----
   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};
*************** example:
*** 50269,50276 ****
  upper half of a register and which value is stored in the lower half.
  On little-endian targets, the first value is the lower one and the
  second value is the upper one.  The opposite order applies to big-endian
! targets.  For example, the code above sets the lower half of 'a' to
! '1.5' on little-endian targets and '9.1' on big-endian targets.
  
  
  File: gcc.info,  Node: MIPS Loongson Built-in Functions,  Next: MIPS SIMD Architecture (MSA) Support,  Prev: MIPS Paired-Single Support,  Up: Target Builtins
--- 50278,50285 ----
  upper half of a register and which value is stored in the lower half.
  On little-endian targets, the first value is the lower one and the
  second value is the upper one.  The opposite order applies to big-endian
! targets.  For example, the code above sets the lower half of ‘a’ to
! ‘1.5’ on little-endian targets and ‘9.1’ on big-endian targets.
  
  
  File: gcc.info,  Node: MIPS Loongson Built-in Functions,  Next: MIPS SIMD Architecture (MSA) Support,  Prev: MIPS Paired-Single Support,  Up: Target Builtins
*************** File: gcc.info,  Node: MIPS Loongson Bui
*** 50280,50294 ****
  
  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
--- 50289,50303 ----
  
  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
*************** File: gcc.info,  Node: Paired-Single Ari
*** 50409,50432 ****
  6.60.17.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
--- 50418,50441 ----
  6.60.17.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
*************** The following paired-single functions ma
*** 50438,50499 ****
  instruction.  Please refer to the architecture specification for details
  on what each instruction does.
  
! 'v2sf __builtin_mips_pll_ps (v2sf, v2sf)'
!      Pair lower lower ('pll.ps').
  
! 'v2sf __builtin_mips_pul_ps (v2sf, v2sf)'
!      Pair upper lower ('pul.ps').
  
! 'v2sf __builtin_mips_plu_ps (v2sf, v2sf)'
!      Pair lower upper ('plu.ps').
  
! 'v2sf __builtin_mips_puu_ps (v2sf, v2sf)'
!      Pair upper upper ('puu.ps').
  
! 'v2sf __builtin_mips_cvt_ps_s (float, float)'
!      Convert pair to paired single ('cvt.ps.s').
  
! 'float __builtin_mips_cvt_s_pl (v2sf)'
!      Convert pair lower to single ('cvt.s.pl').
  
! 'float __builtin_mips_cvt_s_pu (v2sf)'
!      Convert pair upper to single ('cvt.s.pu').
  
! 'v2sf __builtin_mips_abs_ps (v2sf)'
!      Absolute value ('abs.ps').
  
! 'v2sf __builtin_mips_alnv_ps (v2sf, v2sf, int)'
!      Align variable ('alnv.ps').
  
       _Note:_ The value of the third parameter must be 0 or 4 modulo 8,
       otherwise the result is unpredictable.  Please read the instruction
       description for details.
  
   The following multi-instruction functions are also available.  In each
! case, COND can be any of the 16 floating-point conditions: 'f', 'un',
! 'eq', 'ueq', 'olt', 'ult', 'ole', 'ule', 'sf', 'ngle', 'seq', 'ngl',
! 'lt', 'nge', 'le' or 'ngt'.
  
! 'v2sf __builtin_mips_movt_c_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)'
! 'v2sf __builtin_mips_movf_c_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)'
!      Conditional move based on floating-point comparison ('c.COND.ps',
!      'movt.ps'/'movf.ps').
  
!      The 'movt' functions return the value X computed by:
  
            c.COND.ps CC,A,B
            mov.ps X,C
            movt.ps X,D,CC
  
!      The 'movf' functions are similar but use 'movf.ps' instead of
!      'movt.ps'.
  
! 'int __builtin_mips_upper_c_COND_ps (v2sf A, v2sf B)'
! 'int __builtin_mips_lower_c_COND_ps (v2sf A, v2sf B)'
!      Comparison of two paired-single values ('c.COND.ps',
!      'bc1t'/'bc1f').
  
!      These functions compare A and B using 'c.COND.ps' and return either
       the upper or lower half of the result.  For example:
  
            v2sf a, b;
--- 50447,50508 ----
  instruction.  Please refer to the architecture specification for details
  on what each instruction does.
  
! ‘v2sf __builtin_mips_pll_ps (v2sf, v2sf)’
!      Pair lower lower (‘pll.ps’).
  
! ‘v2sf __builtin_mips_pul_ps (v2sf, v2sf)’
!      Pair upper lower (‘pul.ps’).
  
! ‘v2sf __builtin_mips_plu_ps (v2sf, v2sf)’
!      Pair lower upper (‘plu.ps’).
  
! ‘v2sf __builtin_mips_puu_ps (v2sf, v2sf)’
!      Pair upper upper (‘puu.ps’).
  
! ‘v2sf __builtin_mips_cvt_ps_s (float, float)’
!      Convert pair to paired single (‘cvt.ps.s’).
  
! ‘float __builtin_mips_cvt_s_pl (v2sf)’
!      Convert pair lower to single (‘cvt.s.pl’).
  
! ‘float __builtin_mips_cvt_s_pu (v2sf)’
!      Convert pair upper to single (‘cvt.s.pu’).
  
! ‘v2sf __builtin_mips_abs_ps (v2sf)’
!      Absolute value (‘abs.ps’).
  
! ‘v2sf __builtin_mips_alnv_ps (v2sf, v2sf, int)’
!      Align variable (‘alnv.ps’).
  
       _Note:_ The value of the third parameter must be 0 or 4 modulo 8,
       otherwise the result is unpredictable.  Please read the instruction
       description for details.
  
   The following multi-instruction functions are also available.  In each
! case, COND can be any of the 16 floating-point conditions: ‘f’, ‘un’,
! ‘eq’, ‘ueq’, ‘olt’, ‘ult’, ‘ole’, ‘ule’, ‘sf’, ‘ngle’, ‘seq’, ‘ngl’,
! ‘lt’, ‘nge’, ‘le’ or ‘ngt’.
  
! ‘v2sf __builtin_mips_movt_c_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)’
! ‘v2sf __builtin_mips_movf_c_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)’
!      Conditional move based on floating-point comparison (‘c.COND.ps’,
!      ‘movt.ps’/‘movf.ps’).
  
!      The ‘movt’ functions return the value X computed by:
  
            c.COND.ps CC,A,B
            mov.ps X,C
            movt.ps X,D,CC
  
!      The ‘movf’ functions are similar but use ‘movf.ps’ instead of
!      ‘movt.ps’.
  
! ‘int __builtin_mips_upper_c_COND_ps (v2sf A, v2sf B)’
! ‘int __builtin_mips_lower_c_COND_ps (v2sf A, v2sf B)’
!      Comparison of two paired-single values (‘c.COND.ps’,
!      ‘bc1t’/‘bc1f’).
  
!      These functions compare A and B using ‘c.COND.ps’ and return either
       the upper or lower half of the result.  For example:
  
            v2sf a, b;
*************** File: gcc.info,  Node: MIPS-3D Built-in
*** 50516,50573 ****
  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;
--- 50525,50582 ----
  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;
*************** case, COND can be any of the 16 floating
*** 50576,50587 ****
            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;
--- 50585,50596 ----
            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;
*************** case, COND can be any of the 16 floating
*** 50595,50625 ****
            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))
--- 50604,50634 ----
            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))
*************** case, COND can be any of the 16 floating
*** 50632,50648 ****
            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))
--- 50641,50657 ----
            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))
*************** File: gcc.info,  Node: MIPS SIMD Archite
*** 50667,50710 ****
  
  GCC provides intrinsics to access the SIMD instructions provided by the
  MSA MIPS SIMD Architecture.  The interface is made available by
! including '' and using '-mmsa -mhard-float -mfp64 -mnan=2008'.
! For each '__builtin_msa_*', there is a shortened name of the intrinsic,
! '__msa_*'.
  
   MSA implements 128-bit wide vector registers, operating on 8-, 16-, 32-
  and 64-bit integer, 16- and 32-bit fixed-point, or 32- and 64-bit
  floating point data elements.  The following vectors typedefs are
! included in 'msa.h':
!    * 'v16i8', a vector of sixteen signed 8-bit integers;
!    * 'v16u8', a vector of sixteen unsigned 8-bit integers;
!    * 'v8i16', a vector of eight signed 16-bit integers;
!    * 'v8u16', a vector of eight unsigned 16-bit integers;
!    * 'v4i32', a vector of four signed 32-bit integers;
!    * 'v4u32', a vector of four unsigned 32-bit integers;
!    * 'v2i64', a vector of two signed 64-bit integers;
!    * 'v2u64', a vector of two unsigned 64-bit integers;
!    * 'v4f32', a vector of four 32-bit floats;
!    * 'v2f64', a vector of two 64-bit doubles.
  
   Instructions and corresponding built-ins may have additional
  restrictions and/or input/output values manipulated:
!    * 'imm0_1', an integer literal in range 0 to 1;
!    * 'imm0_3', an integer literal in range 0 to 3;
!    * 'imm0_7', an integer literal in range 0 to 7;
!    * 'imm0_15', an integer literal in range 0 to 15;
!    * 'imm0_31', an integer literal in range 0 to 31;
!    * 'imm0_63', an integer literal in range 0 to 63;
!    * 'imm0_255', an integer literal in range 0 to 255;
!    * 'imm_n16_15', an integer literal in range -16 to 15;
!    * 'imm_n512_511', an integer literal in range -512 to 511;
!    * 'imm_n1024_1022', an integer literal in range -512 to 511 left
       shifted by 1 bit, i.e., -1024, -1022, ..., 1020, 1022;
!    * 'imm_n2048_2044', an integer literal in range -512 to 511 left
       shifted by 2 bits, i.e., -2048, -2044, ..., 2040, 2044;
!    * 'imm_n4096_4088', an integer literal in range -512 to 511 left
       shifted by 3 bits, i.e., -4096, -4088, ..., 4080, 4088;
!    * 'imm1_4', an integer literal in range 1 to 4;
!    * 'i32, i64, u32, u64, f32, f64', defined as follows:
  
       {
       typedef int i32;
--- 50676,50719 ----
  
  GCC provides intrinsics to access the SIMD instructions provided by the
  MSA MIPS SIMD Architecture.  The interface is made available by
! including ‘’ and using ‘-mmsa -mhard-float -mfp64 -mnan=2008’.
! For each ‘__builtin_msa_*’, there is a shortened name of the intrinsic,
! ‘__msa_*’.
  
   MSA implements 128-bit wide vector registers, operating on 8-, 16-, 32-
  and 64-bit integer, 16- and 32-bit fixed-point, or 32- and 64-bit
  floating point data elements.  The following vectors typedefs are
! included in ‘msa.h’:
!    • ‘v16i8’, a vector of sixteen signed 8-bit integers;
!    • ‘v16u8’, a vector of sixteen unsigned 8-bit integers;
!    • ‘v8i16’, a vector of eight signed 16-bit integers;
!    • ‘v8u16’, a vector of eight unsigned 16-bit integers;
!    • ‘v4i32’, a vector of four signed 32-bit integers;
!    • ‘v4u32’, a vector of four unsigned 32-bit integers;
!    • ‘v2i64’, a vector of two signed 64-bit integers;
!    • ‘v2u64’, a vector of two unsigned 64-bit integers;
!    • ‘v4f32’, a vector of four 32-bit floats;
!    • ‘v2f64’, a vector of two 64-bit doubles.
  
   Instructions and corresponding built-ins may have additional
  restrictions and/or input/output values manipulated:
!    • ‘imm0_1’, an integer literal in range 0 to 1;
!    • ‘imm0_3’, an integer literal in range 0 to 3;
!    • ‘imm0_7’, an integer literal in range 0 to 7;
!    • ‘imm0_15’, an integer literal in range 0 to 15;
!    • ‘imm0_31’, an integer literal in range 0 to 31;
!    • ‘imm0_63’, an integer literal in range 0 to 63;
!    • ‘imm0_255’, an integer literal in range 0 to 255;
!    • ‘imm_n16_15’, an integer literal in range -16 to 15;
!    • ‘imm_n512_511’, an integer literal in range -512 to 511;
!    • ‘imm_n1024_1022’, an integer literal in range -512 to 511 left
       shifted by 1 bit, i.e., -1024, -1022, ..., 1020, 1022;
!    • ‘imm_n2048_2044’, an integer literal in range -512 to 511 left
       shifted by 2 bits, i.e., -2048, -2044, ..., 2040, 2044;
!    • ‘imm_n4096_4088’, an integer literal in range -512 to 511 left
       shifted by 3 bits, i.e., -4096, -4088, ..., 4080, 4088;
!    • ‘imm1_4’, an integer literal in range 1 to 4;
!    • ‘i32, i64, u32, u64, f32, f64’, defined as follows:
  
       {
       typedef int i32;
*************** File: gcc.info,  Node: Other MIPS Built-
*** 51450,51468 ****
  
  GCC provides other MIPS-specific built-in functions:
  
! 'void __builtin_mips_cache (int OP, const volatile void *ADDR)'
!      Insert a 'cache' instruction with operands OP and ADDR.  GCC
!      defines the preprocessor macro '___GCC_HAVE_BUILTIN_MIPS_CACHE'
       when this function is available.
  
! 'unsigned int __builtin_mips_get_fcsr (void)'
! 'void __builtin_mips_set_fcsr (unsigned int VALUE)'
       Get and set the contents of the floating-point control and status
       register (FPU control register 31).  These functions are only
       available in hard-float code but can be called in both MIPS16 and
       non-MIPS16 contexts.
  
!      '__builtin_mips_set_fcsr' can be used to change any bit of the
       register except the condition codes, which GCC assumes are
       preserved.
  
--- 51459,51477 ----
  
  GCC provides other MIPS-specific built-in functions:
  
! ‘void __builtin_mips_cache (int OP, const volatile void *ADDR)’
!      Insert a ‘cache’ instruction with operands OP and ADDR.  GCC
!      defines the preprocessor macro ‘___GCC_HAVE_BUILTIN_MIPS_CACHE’
       when this function is available.
  
! ‘unsigned int __builtin_mips_get_fcsr (void)’
! ‘void __builtin_mips_set_fcsr (unsigned int VALUE)’
       Get and set the contents of the floating-point control and status
       register (FPU control register 31).  These functions are only
       available in hard-float code but can be called in both MIPS16 and
       non-MIPS16 contexts.
  
!      ‘__builtin_mips_set_fcsr’ can be used to change any bit of the
       register except the condition codes, which GCC assumes are
       preserved.
  
*************** File: gcc.info,  Node: MSP430 Built-in F
*** 51475,51493 ****
  GCC provides a couple of special builtin functions to aid in the writing
  of interrupt handlers in C.
  
! '__bic_SR_register_on_exit (int MASK)'
       This clears the indicated bits in the saved copy of the status
       register currently residing on the stack.  This only works inside
       interrupt handlers and the changes to the status register will only
       take affect once the handler returns.
  
! '__bis_SR_register_on_exit (int MASK)'
       This sets the indicated bits in the saved copy of the status
       register currently residing on the stack.  This only works inside
       interrupt handlers and the changes to the status register will only
       take affect once the handler returns.
  
! '__delay_cycles (long long CYCLES)'
       This inserts an instruction sequence that takes exactly CYCLES
       cycles (between 0 and about 17E9) to complete.  The inserted
       sequence may use jumps, loops, or no-ops, and does not interfere
--- 51484,51502 ----
  GCC provides a couple of special builtin functions to aid in the writing
  of interrupt handlers in C.
  
! ‘__bic_SR_register_on_exit (int MASK)’
       This clears the indicated bits in the saved copy of the status
       register currently residing on the stack.  This only works inside
       interrupt handlers and the changes to the status register will only
       take affect once the handler returns.
  
! ‘__bis_SR_register_on_exit (int MASK)’
       This sets the indicated bits in the saved copy of the status
       register currently residing on the stack.  This only works inside
       interrupt handlers and the changes to the status register will only
       take affect once the handler returns.
  
! ‘__delay_cycles (long long CYCLES)’
       This inserts an instruction sequence that takes exactly CYCLES
       cycles (between 0 and about 17E9) to complete.  The inserted
       sequence may use jumps, loops, or no-ops, and does not interfere
*************** File: gcc.info,  Node: Basic PowerPC Bui
*** 51556,51610 ****
  ..........................................................................
  
   -- Built-in Function: void __builtin_cpu_init (void)
!      This function is a 'nop' on the PowerPC platform and is included
       solely to maintain API compatibility with the x86 builtins.
  
   -- Built-in Function: int __builtin_cpu_is (const char *CPUNAME)
!      This function returns a value of '1' if the run-time CPU is of type
!      CPUNAME and returns '0' otherwise
  
!      The '__builtin_cpu_is' function requires GLIBC 2.23 or newer which
       exports the hardware capability bits.  GCC defines the macro
!      '__BUILTIN_CPU_SUPPORTS__' if the '__builtin_cpu_supports' built-in
       function is fully supported.
  
       If GCC was configured to use a GLIBC before 2.23, the built-in
!      function '__builtin_cpu_is' always returns a 0 and the compiler
       issues a warning.
  
       The following CPU names can be detected:
  
!      'power10'
            IBM POWER10 Server CPU.
!      'power9'
            IBM POWER9 Server CPU.
!      'power8'
            IBM POWER8 Server CPU.
!      'power7'
            IBM POWER7 Server CPU.
!      'power6x'
            IBM POWER6 Server CPU (RAW mode).
!      'power6'
            IBM POWER6 Server CPU (Architected mode).
!      'power5+'
            IBM POWER5+ Server CPU.
!      'power5'
            IBM POWER5 Server CPU.
!      'ppc970'
            IBM 970 Server CPU (ie, Apple G5).
!      'power4'
            IBM POWER4 Server CPU.
!      'ppca2'
            IBM A2 64-bit Embedded CPU
!      'ppc476'
            IBM PowerPC 476FP 32-bit Embedded CPU.
!      'ppc464'
            IBM PowerPC 464 32-bit Embedded CPU.
!      'ppc440'
            PowerPC 440 32-bit Embedded CPU.
!      'ppc405'
            PowerPC 405 32-bit Embedded CPU.
!      'ppc-cell-be'
            IBM PowerPC Cell Broadband Engine Architecture CPU.
  
       Here is an example:
--- 51565,51619 ----
  ..........................................................................
  
   -- Built-in Function: void __builtin_cpu_init (void)
!      This function is a ‘nop’ on the PowerPC platform and is included
       solely to maintain API compatibility with the x86 builtins.
  
   -- Built-in Function: int __builtin_cpu_is (const char *CPUNAME)
!      This function returns a value of ‘1’ if the run-time CPU is of type
!      CPUNAME and returns ‘0’ otherwise
  
!      The ‘__builtin_cpu_is’ function requires GLIBC 2.23 or newer which
       exports the hardware capability bits.  GCC defines the macro
!      ‘__BUILTIN_CPU_SUPPORTS__’ if the ‘__builtin_cpu_supports’ built-in
       function is fully supported.
  
       If GCC was configured to use a GLIBC before 2.23, the built-in
!      function ‘__builtin_cpu_is’ always returns a 0 and the compiler
       issues a warning.
  
       The following CPU names can be detected:
  
!      ‘power10’
            IBM POWER10 Server CPU.
!      ‘power9’
            IBM POWER9 Server CPU.
!      ‘power8’
            IBM POWER8 Server CPU.
!      ‘power7’
            IBM POWER7 Server CPU.
!      ‘power6x’
            IBM POWER6 Server CPU (RAW mode).
!      ‘power6’
            IBM POWER6 Server CPU (Architected mode).
!      ‘power5+’
            IBM POWER5+ Server CPU.
!      ‘power5’
            IBM POWER5 Server CPU.
!      ‘ppc970’
            IBM 970 Server CPU (ie, Apple G5).
!      ‘power4’
            IBM POWER4 Server CPU.
!      ‘ppca2’
            IBM A2 64-bit Embedded CPU
!      ‘ppc476’
            IBM PowerPC 476FP 32-bit Embedded CPU.
!      ‘ppc464’
            IBM PowerPC 464 32-bit Embedded CPU.
!      ‘ppc440’
            PowerPC 440 32-bit Embedded CPU.
!      ‘ppc405’
            PowerPC 405 32-bit Embedded CPU.
!      ‘ppc-cell-be’
            IBM PowerPC Cell Broadband Engine Architecture CPU.
  
       Here is an example:
*************** File: gcc.info,  Node: Basic PowerPC Bui
*** 51620,51727 ****
                }
  
   -- Built-in Function: int __builtin_cpu_supports (const char *FEATURE)
!      This function returns a value of '1' if the run-time CPU supports
!      the HWCAP feature FEATURE and returns '0' otherwise.
  
!      The '__builtin_cpu_supports' function requires GLIBC 2.23 or newer
       which exports the hardware capability bits.  GCC defines the macro
!      '__BUILTIN_CPU_SUPPORTS__' if the '__builtin_cpu_supports' built-in
       function is fully supported.
  
       If GCC was configured to use a GLIBC before 2.23, the built-in
!      function '__builtin_cpu_supports' always returns a 0 and the
       compiler issues a warning.
  
       The following features can be detected:
  
!      '4xxmac'
            4xx CPU has a Multiply Accumulator.
!      'altivec'
            CPU has a SIMD/Vector Unit.
!      'arch_2_05'
            CPU supports ISA 2.05 (eg, POWER6)
!      'arch_2_06'
            CPU supports ISA 2.06 (eg, POWER7)
!      'arch_2_07'
            CPU supports ISA 2.07 (eg, POWER8)
!      'arch_3_00'
            CPU supports ISA 3.0 (eg, POWER9)
!      'arch_3_1'
            CPU supports ISA 3.1 (eg, POWER10)
!      'archpmu'
            CPU supports the set of compatible performance monitoring
            events.
!      'booke'
            CPU supports the Embedded ISA category.
!      'cellbe'
            CPU has a CELL broadband engine.
!      'darn'
!           CPU supports the 'darn' (deliver a random number) instruction.
!      'dfp'
            CPU has a decimal floating point unit.
!      'dscr'
            CPU supports the data stream control register.
!      'ebb'
            CPU supports event base branching.
!      'efpdouble'
            CPU has a SPE double precision floating point unit.
!      'efpsingle'
            CPU has a SPE single precision floating point unit.
!      'fpu'
            CPU has a floating point unit.
!      'htm'
            CPU has hardware transaction memory instructions.
!      'htm-nosc'
            Kernel aborts hardware transactions when a syscall is made.
!      'htm-no-suspend'
            CPU supports hardware transaction memory but does not support
!           the 'tsuspend.' instruction.
!      'ic_snoop'
            CPU supports icache snooping capabilities.
!      'ieee128'
            CPU supports 128-bit IEEE binary floating point instructions.
!      'isel'
            CPU supports the integer select instruction.
!      'mma'
            CPU supports the matrix-multiply assist instructions.
!      'mmu'
            CPU has a memory management unit.
!      'notb'
            CPU does not have a timebase (eg, 601 and 403gx).
!      'pa6t'
            CPU supports the PA Semi 6T CORE ISA.
!      'power4'
            CPU supports ISA 2.00 (eg, POWER4)
!      'power5'
            CPU supports ISA 2.02 (eg, POWER5)
!      'power5+'
            CPU supports ISA 2.03 (eg, POWER5+)
!      'power6x'
            CPU supports ISA 2.05 (eg, POWER6) extended opcodes mffgpr and
            mftgpr.
!      'ppc32'
            CPU supports 32-bit mode execution.
!      'ppc601'
            CPU supports the old POWER ISA (eg, 601)
!      'ppc64'
            CPU supports 64-bit mode execution.
!      'ppcle'
            CPU supports a little-endian mode that uses address swizzling.
!      'scv'
            Kernel supports system call vectored.
!      'smt'
            CPU support simultaneous multi-threading.
!      'spe'
            CPU has a signal processing extension unit.
!      'tar'
            CPU supports the target address register.
!      'true_le'
            CPU supports true little-endian mode.
!      'ucache'
            CPU has unified I/D cache.
!      'vcrypto'
            CPU supports the vector cryptography instructions.
!      'vsx'
            CPU supports the vector-scalar extension.
  
       Here is an example:
--- 51629,51736 ----
                }
  
   -- Built-in Function: int __builtin_cpu_supports (const char *FEATURE)
!      This function returns a value of ‘1’ if the run-time CPU supports
!      the HWCAP feature FEATURE and returns ‘0’ otherwise.
  
!      The ‘__builtin_cpu_supports’ function requires GLIBC 2.23 or newer
       which exports the hardware capability bits.  GCC defines the macro
!      ‘__BUILTIN_CPU_SUPPORTS__’ if the ‘__builtin_cpu_supports’ built-in
       function is fully supported.
  
       If GCC was configured to use a GLIBC before 2.23, the built-in
!      function ‘__builtin_cpu_supports’ always returns a 0 and the
       compiler issues a warning.
  
       The following features can be detected:
  
!      ‘4xxmac’
            4xx CPU has a Multiply Accumulator.
!      ‘altivec’
            CPU has a SIMD/Vector Unit.
!      ‘arch_2_05’
            CPU supports ISA 2.05 (eg, POWER6)
!      ‘arch_2_06’
            CPU supports ISA 2.06 (eg, POWER7)
!      ‘arch_2_07’
            CPU supports ISA 2.07 (eg, POWER8)
!      ‘arch_3_00’
            CPU supports ISA 3.0 (eg, POWER9)
!      ‘arch_3_1’
            CPU supports ISA 3.1 (eg, POWER10)
!      ‘archpmu’
            CPU supports the set of compatible performance monitoring
            events.
!      ‘booke’
            CPU supports the Embedded ISA category.
!      ‘cellbe’
            CPU has a CELL broadband engine.
!      ‘darn’
!           CPU supports the ‘darn’ (deliver a random number) instruction.
!      ‘dfp’
            CPU has a decimal floating point unit.
!      ‘dscr’
            CPU supports the data stream control register.
!      ‘ebb’
            CPU supports event base branching.
!      ‘efpdouble’
            CPU has a SPE double precision floating point unit.
!      ‘efpsingle’
            CPU has a SPE single precision floating point unit.
!      ‘fpu’
            CPU has a floating point unit.
!      ‘htm’
            CPU has hardware transaction memory instructions.
!      ‘htm-nosc’
            Kernel aborts hardware transactions when a syscall is made.
!      ‘htm-no-suspend’
            CPU supports hardware transaction memory but does not support
!           the ‘tsuspend.’ instruction.
!      ‘ic_snoop’
            CPU supports icache snooping capabilities.
!      ‘ieee128’
            CPU supports 128-bit IEEE binary floating point instructions.
!      ‘isel’
            CPU supports the integer select instruction.
!      ‘mma’
            CPU supports the matrix-multiply assist instructions.
!      ‘mmu’
            CPU has a memory management unit.
!      ‘notb’
            CPU does not have a timebase (eg, 601 and 403gx).
!      ‘pa6t’
            CPU supports the PA Semi 6T CORE ISA.
!      ‘power4’
            CPU supports ISA 2.00 (eg, POWER4)
!      ‘power5’
            CPU supports ISA 2.02 (eg, POWER5)
!      ‘power5+’
            CPU supports ISA 2.03 (eg, POWER5+)
!      ‘power6x’
            CPU supports ISA 2.05 (eg, POWER6) extended opcodes mffgpr and
            mftgpr.
!      ‘ppc32’
            CPU supports 32-bit mode execution.
!      ‘ppc601’
            CPU supports the old POWER ISA (eg, 601)
!      ‘ppc64’
            CPU supports 64-bit mode execution.
!      ‘ppcle’
            CPU supports a little-endian mode that uses address swizzling.
!      ‘scv’
            Kernel supports system call vectored.
!      ‘smt’
            CPU support simultaneous multi-threading.
!      ‘spe’
            CPU has a signal processing extension unit.
!      ‘tar’
            CPU supports the target address register.
!      ‘true_le’
            CPU supports true little-endian mode.
!      ‘ucache’
            CPU has unified I/D cache.
!      ‘vcrypto’
            CPU supports the vector cryptography instructions.
!      ‘vsx’
            CPU supports the vector-scalar extension.
  
       Here is an example:
*************** processors:
*** 51748,51776 ****
       void __builtin_mtfsb1 (const int);
       void __builtin_set_fpscr_rn (int);
  
!  The '__builtin_ppc_get_timebase' and '__builtin_ppc_mftb' functions
  generate instructions to read the Time Base Register.  The
! '__builtin_ppc_get_timebase' function may generate multiple instructions
  and always returns the 64 bits of the Time Base Register.  The
! '__builtin_ppc_mftb' function always generates one instruction and
  returns the Time Base Register value as an unsigned long, throwing away
! the most significant word on 32-bit environments.  The '__builtin_mffs'
  return the value of the FPSCR register.  Note, ISA 3.0 supports the
! '__builtin_mffsl()' which permits software to read the control and
  non-sticky status bits in the FSPCR without the higher latency
! associated with accessing the sticky status bits.  The '__builtin_mtfsf'
  takes a constant 8-bit integer field mask and a double precision
! floating point argument and generates the 'mtfsf' (extended mnemonic)
  instruction to write new values to selected fields of the FPSCR. The
! '__builtin_mtfsb0' and '__builtin_mtfsb1' take the bit to change as an
  argument.  The valid bit range is between 0 and 31.  The builtins map to
! the 'mtfsb0' and 'mtfsb1' instructions which take the argument and add
  32.  Hence these instructions only modify the FPSCR[32:63] bits by
  changing the specified bit to a zero or one respectively.  The
! '__builtin_set_fpscr_rn' builtin allows changing both of the floating
  point rounding mode bits.  The argument is a 2-bit value.  The argument
! can either be a 'const int' or stored in a variable.  The builtin uses
! the ISA 3.0 instruction 'mffscrn' if available, otherwise it reads the
  FPSCR, masks the current rounding mode bits out and OR's in the new
  value.
  
--- 51757,51785 ----
       void __builtin_mtfsb1 (const int);
       void __builtin_set_fpscr_rn (int);
  
!  The ‘__builtin_ppc_get_timebase’ and ‘__builtin_ppc_mftb’ functions
  generate instructions to read the Time Base Register.  The
! ‘__builtin_ppc_get_timebase’ function may generate multiple instructions
  and always returns the 64 bits of the Time Base Register.  The
! ‘__builtin_ppc_mftb’ function always generates one instruction and
  returns the Time Base Register value as an unsigned long, throwing away
! the most significant word on 32-bit environments.  The ‘__builtin_mffs’
  return the value of the FPSCR register.  Note, ISA 3.0 supports the
! ‘__builtin_mffsl()’ which permits software to read the control and
  non-sticky status bits in the FSPCR without the higher latency
! associated with accessing the sticky status bits.  The ‘__builtin_mtfsf’
  takes a constant 8-bit integer field mask and a double precision
! floating point argument and generates the ‘mtfsf’ (extended mnemonic)
  instruction to write new values to selected fields of the FPSCR. The
! ‘__builtin_mtfsb0’ and ‘__builtin_mtfsb1’ take the bit to change as an
  argument.  The valid bit range is between 0 and 31.  The builtins map to
! the ‘mtfsb0’ and ‘mtfsb1’ instructions which take the argument and add
  32.  Hence these instructions only modify the FPSCR[32:63] bits by
  changing the specified bit to a zero or one respectively.  The
! ‘__builtin_set_fpscr_rn’ builtin allows changing both of the floating
  point rounding mode bits.  The argument is a 2-bit value.  The argument
! can either be a ‘const int’ or stored in a variable.  The builtin uses
! the ISA 3.0 instruction ‘mffscrn’ if available, otherwise it reads the
  FPSCR, masks the current rounding mode bits out and OR's in the new
  value.
  
*************** File: gcc.info,  Node: Basic PowerPC Bui
*** 51783,51809 ****
  The basic built-in functions described in this section are available on
  the PowerPC family of processors starting with ISA 2.05 or later.
  Unless specific options are explicitly disabled on the command line,
! specifying option '-mcpu=power6' has the effect of enabling the
! '-mpowerpc64', '-mpowerpc-gpopt', '-mpowerpc-gfxopt', '-mmfcrf',
! '-mpopcntb', '-mfprnd', '-mcmpb', '-mhard-dfp', and '-mrecip-precision'
! options.  Specify the '-maltivec' option explicitly in combination with
  the above options if desired.
  
!  The following functions require option '-mcmpb'.
       unsigned long long __builtin_cmpb (unsigned long long int, unsigned long long int);
       unsigned int __builtin_cmpb (unsigned int, unsigned int);
  
!  The '__builtin_cmpb' function performs a byte-wise compare on the
  contents of its two arguments, returning the result of the byte-wise
  comparison as the returned value.  For each byte comparison, the
  corresponding byte of the return value holds 0xff if the input bytes are
  equal and 0 if the input bytes are not equal.  If either of the
  arguments to this built-in function is wider than 32 bits, the function
! call expands into the form that expects 'unsigned long long int'
  arguments which is only available on 64-bit targets.
  
   The following built-in functions are available when hardware decimal
! floating point ('-mhard-dfp') is available:
       void __builtin_set_fpscr_drn(int);
       _Decimal64 __builtin_ddedpd (int, _Decimal64);
       _Decimal128 __builtin_ddedpdq (int, _Decimal128);
--- 51792,51818 ----
  The basic built-in functions described in this section are available on
  the PowerPC family of processors starting with ISA 2.05 or later.
  Unless specific options are explicitly disabled on the command line,
! specifying option ‘-mcpu=power6’ has the effect of enabling the
! ‘-mpowerpc64’, ‘-mpowerpc-gpopt’, ‘-mpowerpc-gfxopt’, ‘-mmfcrf’,
! ‘-mpopcntb’, ‘-mfprnd’, ‘-mcmpb’, ‘-mhard-dfp’, and ‘-mrecip-precision’
! options.  Specify the ‘-maltivec’ option explicitly in combination with
  the above options if desired.
  
!  The following functions require option ‘-mcmpb’.
       unsigned long long __builtin_cmpb (unsigned long long int, unsigned long long int);
       unsigned int __builtin_cmpb (unsigned int, unsigned int);
  
!  The ‘__builtin_cmpb’ function performs a byte-wise compare on the
  contents of its two arguments, returning the result of the byte-wise
  comparison as the returned value.  For each byte comparison, the
  corresponding byte of the return value holds 0xff if the input bytes are
  equal and 0 if the input bytes are not equal.  If either of the
  arguments to this built-in function is wider than 32 bits, the function
! call expands into the form that expects ‘unsigned long long int’
  arguments which is only available on 64-bit targets.
  
   The following built-in functions are available when hardware decimal
! floating point (‘-mhard-dfp’) is available:
       void __builtin_set_fpscr_drn(int);
       _Decimal64 __builtin_ddedpd (int, _Decimal64);
       _Decimal128 __builtin_ddedpdq (int, _Decimal128);
*************** floating point ('-mhard-dfp') is availab
*** 51829,51876 ****
       mode bits out and OR's in the new value.
  
  
!  The following functions require '-mhard-float', '-mpowerpc-gfxopt', and
! '-mpopcntb' options.
  
       double __builtin_recipdiv (double, double);
       float __builtin_recipdivf (float, float);
       double __builtin_rsqrt (double);
       float __builtin_rsqrtf (float);
  
!  The 'vec_rsqrt', '__builtin_rsqrt', and '__builtin_rsqrtf' functions
  generate multiple instructions to implement the reciprocal sqrt
  functionality using reciprocal sqrt estimate instructions.
  
!  The '__builtin_recipdiv', and '__builtin_recipdivf' functions generate
  multiple instructions to implement division using the reciprocal
  estimate instructions.
  
!  The following functions require '-mhard-float' and '-mmultiple'
  options.
  
!  The '__builtin_unpack_longdouble' function takes a 'long double'
  argument and a compile time constant of 0 or 1.  If the constant is 0,
! the first 'double' within the 'long double' is returned, otherwise the
! second 'double' is returned.  The '__builtin_unpack_longdouble' function
! is only available if 'long double' uses the IBM extended double
  representation.
  
!  The '__builtin_pack_longdouble' function takes two 'double' arguments
! and returns a 'long double' value that combines the two arguments.  The
! '__builtin_pack_longdouble' function is only available if 'long double'
  uses the IBM extended double representation.
  
!  The '__builtin_unpack_ibm128' function takes a '__ibm128' argument and
  a compile time constant of 0 or 1.  If the constant is 0, the first
! 'double' within the '__ibm128' is returned, otherwise the second
! 'double' is returned.
  
!  The '__builtin_pack_ibm128' function takes two 'double' arguments and
! returns a '__ibm128' value that combines the two arguments.
  
   Additional built-in functions are available for the 64-bit PowerPC
  family of processors, for efficient use of 128-bit floating point
! ('__float128') values.
  
  
  File: gcc.info,  Node: Basic PowerPC Built-in Functions Available on ISA 2.06,  Next: Basic PowerPC Built-in Functions Available on ISA 2.07,  Prev: Basic PowerPC Built-in Functions Available on ISA 2.05,  Up: Basic PowerPC Built-in Functions
--- 51838,51885 ----
       mode bits out and OR's in the new value.
  
  
!  The following functions require ‘-mhard-float’, ‘-mpowerpc-gfxopt’, and
! ‘-mpopcntb’ options.
  
       double __builtin_recipdiv (double, double);
       float __builtin_recipdivf (float, float);
       double __builtin_rsqrt (double);
       float __builtin_rsqrtf (float);
  
!  The ‘vec_rsqrt’, ‘__builtin_rsqrt’, and ‘__builtin_rsqrtf’ functions
  generate multiple instructions to implement the reciprocal sqrt
  functionality using reciprocal sqrt estimate instructions.
  
!  The ‘__builtin_recipdiv’, and ‘__builtin_recipdivf’ functions generate
  multiple instructions to implement division using the reciprocal
  estimate instructions.
  
!  The following functions require ‘-mhard-float’ and ‘-mmultiple’
  options.
  
!  The ‘__builtin_unpack_longdouble’ function takes a ‘long double’
  argument and a compile time constant of 0 or 1.  If the constant is 0,
! the first ‘double’ within the ‘long double’ is returned, otherwise the
! second ‘double’ is returned.  The ‘__builtin_unpack_longdouble’ function
! is only available if ‘long double’ uses the IBM extended double
  representation.
  
!  The ‘__builtin_pack_longdouble’ function takes two ‘double’ arguments
! and returns a ‘long double’ value that combines the two arguments.  The
! ‘__builtin_pack_longdouble’ function is only available if ‘long double’
  uses the IBM extended double representation.
  
!  The ‘__builtin_unpack_ibm128’ function takes a ‘__ibm128’ argument and
  a compile time constant of 0 or 1.  If the constant is 0, the first
! ‘double’ within the ‘__ibm128’ is returned, otherwise the second
! ‘double’ is returned.
  
!  The ‘__builtin_pack_ibm128’ function takes two ‘double’ arguments and
! returns a ‘__ibm128’ value that combines the two arguments.
  
   Additional built-in functions are available for the 64-bit PowerPC
  family of processors, for efficient use of 128-bit floating point
! (‘__float128’) values.
  
  
  File: gcc.info,  Node: Basic PowerPC Built-in Functions Available on ISA 2.06,  Next: Basic PowerPC Built-in Functions Available on ISA 2.07,  Prev: Basic PowerPC Built-in Functions Available on ISA 2.05,  Up: Basic PowerPC Built-in Functions
*************** File: gcc.info,  Node: Basic PowerPC Bui
*** 51881,51891 ****
  The basic built-in functions described in this section are available on
  the PowerPC family of processors starting with ISA 2.05 or later.
  Unless specific options are explicitly disabled on the command line,
! specifying option '-mcpu=power7' has the effect of enabling all the same
! options as for '-mcpu=power6' in addition to the '-maltivec',
! '-mpopcntd', and '-mvsx' options.
  
!  The following basic built-in functions require '-mpopcntd':
       unsigned int __builtin_addg6s (unsigned int, unsigned int);
       long long __builtin_bpermd (long long, long long);
       unsigned int __builtin_cbcdtd (unsigned int);
--- 51890,51900 ----
  The basic built-in functions described in this section are available on
  the PowerPC family of processors starting with ISA 2.05 or later.
  Unless specific options are explicitly disabled on the command line,
! specifying option ‘-mcpu=power7’ has the effect of enabling all the same
! options as for ‘-mcpu=power6’ in addition to the ‘-maltivec’,
! ‘-mpopcntd’, and ‘-mvsx’ options.
  
!  The following basic built-in functions require ‘-mpopcntd’:
       unsigned int __builtin_addg6s (unsigned int, unsigned int);
       long long __builtin_bpermd (long long, long long);
       unsigned int __builtin_cbcdtd (unsigned int);
*************** options as for '-mcpu=power6' in additio
*** 51898,51908 ****
       void __builtin_rs6000_speculation_barrier (void);
       long long __builtin_unpack_vector_int128 (vector __int128, signed char);
  
!  Of these, the '__builtin_divde' and '__builtin_divdeu' functions
  require a 64-bit environment.
  
   The following basic built-in functions, which are also supported on x86
! targets, require '-mfloat128'.
       __float128 __builtin_fabsq (__float128);
       __float128 __builtin_copysignq (__float128, __float128);
       __float128 __builtin_infq (void);
--- 51907,51917 ----
       void __builtin_rs6000_speculation_barrier (void);
       long long __builtin_unpack_vector_int128 (vector __int128, signed char);
  
!  Of these, the ‘__builtin_divde’ and ‘__builtin_divdeu’ functions
  require a 64-bit environment.
  
   The following basic built-in functions, which are also supported on x86
! targets, require ‘-mfloat128’.
       __float128 __builtin_fabsq (__float128);
       __float128 __builtin_copysignq (__float128, __float128);
       __float128 __builtin_infq (void);
*************** File: gcc.info,  Node: Basic PowerPC Bui
*** 51922,51931 ****
  The basic built-in functions described in this section are available on
  the PowerPC family of processors starting with ISA 2.07 or later.
  Unless specific options are explicitly disabled on the command line,
! specifying option '-mcpu=power8' has the effect of enabling all the same
! options as for '-mcpu=power7' in addition to the '-mpower8-fusion',
! '-mpower8-vector', '-mcrypto', '-mhtm', '-mquad-memory', and
! '-mquad-memory-atomic' options.
  
   This section intentionally empty.
  
--- 51931,51940 ----
  The basic built-in functions described in this section are available on
  the PowerPC family of processors starting with ISA 2.07 or later.
  Unless specific options are explicitly disabled on the command line,
! specifying option ‘-mcpu=power8’ has the effect of enabling all the same
! options as for ‘-mcpu=power7’ in addition to the ‘-mpower8-fusion’,
! ‘-mpower8-vector’, ‘-mcrypto’, ‘-mhtm’, ‘-mquad-memory’, and
! ‘-mquad-memory-atomic’ options.
  
   This section intentionally empty.
  
*************** File: gcc.info,  Node: Basic PowerPC Bui
*** 51938,51948 ****
  The basic built-in functions described in this section are available on
  the PowerPC family of processors starting with ISA 3.0 or later.  Unless
  specific options are explicitly disabled on the command line, specifying
! option '-mcpu=power9' has the effect of enabling all the same options as
! for '-mcpu=power8' in addition to the '-misel' option.
  
   The following built-in functions are available on Linux 64-bit systems
! that use the ISA 3.0 instruction set ('-mcpu=power9'):
  
   -- Built-in Function: __float128 __builtin_addf128_round_to_odd
            (__float128, __float128)
--- 51947,51957 ----
  The basic built-in functions described in this section are available on
  the PowerPC family of processors starting with ISA 3.0 or later.  Unless
  specific options are explicitly disabled on the command line, specifying
! option ‘-mcpu=power9’ has the effect of enabling all the same options as
! for ‘-mcpu=power8’ in addition to the ‘-misel’ option.
  
   The following built-in functions are available on Linux 64-bit systems
! that use the ISA 3.0 instruction set (‘-mcpu=power9’):
  
   -- Built-in Function: __float128 __builtin_addf128_round_to_odd
            (__float128, __float128)
*************** that use the ISA 3.0 instruction set ('-
*** 51976,51982 ****
  
   -- Built-in Function: double __builtin_truncf128_round_to_odd
            (__float128)
!      Convert a 128-bit IEEE floating point value to 'double' using round
       to odd as the rounding mode.
  
   The following additional built-in functions are also available for the
--- 51985,51991 ----
  
   -- Built-in Function: double __builtin_truncf128_round_to_odd
            (__float128)
!      Convert a 128-bit IEEE floating point value to ‘double’ using round
       to odd as the rounding mode.
  
   The following additional built-in functions are also available for the
*************** PowerPC family of processors, starting w
*** 51985,51995 ****
   -- Built-in Function: long long __builtin_darn (void)
   -- Built-in Function: long long __builtin_darn_raw (void)
   -- Built-in Function: int __builtin_darn_32 (void)
!      The '__builtin_darn' and '__builtin_darn_raw' functions require a
       64-bit environment supporting ISA 3.0 or later.  The
!      '__builtin_darn' function provides a 64-bit conditioned random
!      number.  The '__builtin_darn_raw' function provides a 64-bit raw
!      random number.  The '__builtin_darn_32' function provides a 32-bit
       conditioned random number.
  
   The following additional built-in functions are also available for the
--- 51994,52004 ----
   -- Built-in Function: long long __builtin_darn (void)
   -- Built-in Function: long long __builtin_darn_raw (void)
   -- Built-in Function: int __builtin_darn_32 (void)
!      The ‘__builtin_darn’ and ‘__builtin_darn_raw’ functions require a
       64-bit environment supporting ISA 3.0 or later.  The
!      ‘__builtin_darn’ function provides a 64-bit conditioned random
!      number.  The ‘__builtin_darn_raw’ function provides a 64-bit raw
!      random number.  The ‘__builtin_darn_32’ function provides a 32-bit
       conditioned random number.
  
   The following additional built-in functions are also available for the
*************** PowerPC family of processors, starting w
*** 52021,52074 ****
  
       double __builtin_mffsl(void);
  
!  The '__builtin_byte_in_set' function requires a 64-bit environment
  supporting ISA 3.0 or later.  This function returns a non-zero value if
! and only if its 'u' argument exactly equals one of the eight bytes
! contained within its 64-bit 'set' argument.
  
!  The '__builtin_byte_in_range' and '__builtin_byte_in_either_range'
  require an environment supporting ISA 3.0 or later.  For these two
! functions, the 'range' argument is encoded as 4 bytes, organized as
! 'hi_1:lo_1:hi_2:lo_2'.  The '__builtin_byte_in_range' function returns a
! non-zero value if and only if its 'u' argument is within the range
! bounded between 'lo_2' and 'hi_2' inclusive.  The
! '__builtin_byte_in_either_range' function returns non-zero if and only
! if its 'u' argument is within either the range bounded between 'lo_1'
! and 'hi_1' inclusive or the range bounded between 'lo_2' and 'hi_2'
  inclusive.
  
!  The '__builtin_dfp_dtstsfi_lt' function returns a non-zero value if and
! only if the number of signficant digits of its 'value' argument is less
! than its 'comparison' argument.  The '__builtin_dfp_dtstsfi_lt_dd' and
! '__builtin_dfp_dtstsfi_lt_td' functions behave similarly, but require
! that the type of the 'value' argument be '__Decimal64' and
! '__Decimal128' respectively.
  
!  The '__builtin_dfp_dtstsfi_gt' function returns a non-zero value if and
! only if the number of signficant digits of its 'value' argument is
! greater than its 'comparison' argument.  The
! '__builtin_dfp_dtstsfi_gt_dd' and '__builtin_dfp_dtstsfi_gt_td'
! functions behave similarly, but require that the type of the 'value'
! argument be '__Decimal64' and '__Decimal128' respectively.
  
!  The '__builtin_dfp_dtstsfi_eq' function returns a non-zero value if and
! only if the number of signficant digits of its 'value' argument equals
! its 'comparison' argument.  The '__builtin_dfp_dtstsfi_eq_dd' and
! '__builtin_dfp_dtstsfi_eq_td' functions behave similarly, but require
! that the type of the 'value' argument be '__Decimal64' and
! '__Decimal128' respectively.
  
!  The '__builtin_dfp_dtstsfi_ov' function returns a non-zero value if and
! only if its 'value' argument has an undefined number of significant
! digits, such as when 'value' is an encoding of 'NaN'.  The
! '__builtin_dfp_dtstsfi_ov_dd' and '__builtin_dfp_dtstsfi_ov_td'
! functions behave similarly, but require that the type of the 'value'
! argument be '__Decimal64' and '__Decimal128' respectively.
  
!  The '__builtin_mffsl' uses the ISA 3.0 'mffsl' instruction to read the
! FPSCR. The instruction is a lower latency version of the 'mffs'
! instruction.  If the 'mffsl' instruction is not available, then the
! builtin uses the older 'mffs' instruction to read the FPSCR.
  
  
  File: gcc.info,  Node: Basic PowerPC Built-in Functions Available on ISA 3.1,  Prev: Basic PowerPC Built-in Functions Available on ISA 3.0,  Up: Basic PowerPC Built-in Functions
--- 52030,52083 ----
  
       double __builtin_mffsl(void);
  
!  The ‘__builtin_byte_in_set’ function requires a 64-bit environment
  supporting ISA 3.0 or later.  This function returns a non-zero value if
! and only if its ‘u’ argument exactly equals one of the eight bytes
! contained within its 64-bit ‘set’ argument.
  
!  The ‘__builtin_byte_in_range’ and ‘__builtin_byte_in_either_range’
  require an environment supporting ISA 3.0 or later.  For these two
! functions, the ‘range’ argument is encoded as 4 bytes, organized as
! ‘hi_1:lo_1:hi_2:lo_2’.  The ‘__builtin_byte_in_range’ function returns a
! non-zero value if and only if its ‘u’ argument is within the range
! bounded between ‘lo_2’ and ‘hi_2’ inclusive.  The
! ‘__builtin_byte_in_either_range’ function returns non-zero if and only
! if its ‘u’ argument is within either the range bounded between ‘lo_1’
! and ‘hi_1’ inclusive or the range bounded between ‘lo_2’ and ‘hi_2’
  inclusive.
  
!  The ‘__builtin_dfp_dtstsfi_lt’ function returns a non-zero value if and
! only if the number of signficant digits of its ‘value’ argument is less
! than its ‘comparison’ argument.  The ‘__builtin_dfp_dtstsfi_lt_dd’ and
! ‘__builtin_dfp_dtstsfi_lt_td’ functions behave similarly, but require
! that the type of the ‘value’ argument be ‘__Decimal64’ and
! ‘__Decimal128’ respectively.
  
!  The ‘__builtin_dfp_dtstsfi_gt’ function returns a non-zero value if and
! only if the number of signficant digits of its ‘value’ argument is
! greater than its ‘comparison’ argument.  The
! ‘__builtin_dfp_dtstsfi_gt_dd’ and ‘__builtin_dfp_dtstsfi_gt_td’
! functions behave similarly, but require that the type of the ‘value’
! argument be ‘__Decimal64’ and ‘__Decimal128’ respectively.
  
!  The ‘__builtin_dfp_dtstsfi_eq’ function returns a non-zero value if and
! only if the number of signficant digits of its ‘value’ argument equals
! its ‘comparison’ argument.  The ‘__builtin_dfp_dtstsfi_eq_dd’ and
! ‘__builtin_dfp_dtstsfi_eq_td’ functions behave similarly, but require
! that the type of the ‘value’ argument be ‘__Decimal64’ and
! ‘__Decimal128’ respectively.
  
!  The ‘__builtin_dfp_dtstsfi_ov’ function returns a non-zero value if and
! only if its ‘value’ argument has an undefined number of significant
! digits, such as when ‘value’ is an encoding of ‘NaN’.  The
! ‘__builtin_dfp_dtstsfi_ov_dd’ and ‘__builtin_dfp_dtstsfi_ov_td’
! functions behave similarly, but require that the type of the ‘value’
! argument be ‘__Decimal64’ and ‘__Decimal128’ respectively.
  
!  The ‘__builtin_mffsl’ uses the ISA 3.0 ‘mffsl’ instruction to read the
! FPSCR. The instruction is a lower latency version of the ‘mffs’
! instruction.  If the ‘mffsl’ instruction is not available, then the
! builtin uses the older ‘mffs’ instruction to read the FPSCR.
  
  
  File: gcc.info,  Node: Basic PowerPC Built-in Functions Available on ISA 3.1,  Prev: Basic PowerPC Built-in Functions Available on ISA 3.0,  Up: Basic PowerPC Built-in Functions
*************** File: gcc.info,  Node: Basic PowerPC Bui
*** 52079,52114 ****
  The basic built-in functions described in this section are available on
  the PowerPC family of processors starting with ISA 3.1.  Unless specific
  options are explicitly disabled on the command line, specifying option
! '-mcpu=power10' has the effect of enabling all the same options as for
! '-mcpu=power9'.
  
   The following built-in functions are available on Linux 64-bit systems
! that use a future architecture instruction set ('-mcpu=power10'):
  
   -- Built-in Function: unsigned long long __builtin_cfuged (unsigned
            long long, unsigned long long)
       Perform a 64-bit centrifuge operation, as if implemented by the
!      'cfuged' instruction.
  
   -- Built-in Function: unsigned long long __builtin_cntlzdm (unsigned
            long long, unsigned long long)
       Perform a 64-bit count leading zeros operation under mask, as if
!      implemented by the 'cntlzdm' instruction.
  
   -- Built-in Function: unsigned long long __builtin_cnttzdm (unsigned
            long long, unsigned long long)
       Perform a 64-bit count trailing zeros operation under mask, as if
!      implemented by the 'cnttzdm' instruction.
  
   -- Built-in Function: unsigned long long __builtin_pdepd (unsigned long
            long, unsigned long long)
       Perform a 64-bit parallel bits deposit operation, as if implemented
!      by the 'pdepd' instruction.
  
   -- Built-in Function: unsigned long long __builtin_pextd (unsigned long
            long, unsigned long long)
       Perform a 64-bit parallel bits extract operation, as if implemented
!      by the 'pextd' instruction.
  
   -- Built-in Function: vector signed __int128 vsx_xl_sext (signed long
            long, signed char *)
--- 52088,52123 ----
  The basic built-in functions described in this section are available on
  the PowerPC family of processors starting with ISA 3.1.  Unless specific
  options are explicitly disabled on the command line, specifying option
! ‘-mcpu=power10’ has the effect of enabling all the same options as for
! ‘-mcpu=power9’.
  
   The following built-in functions are available on Linux 64-bit systems
! that use a future architecture instruction set (‘-mcpu=power10’):
  
   -- Built-in Function: unsigned long long __builtin_cfuged (unsigned
            long long, unsigned long long)
       Perform a 64-bit centrifuge operation, as if implemented by the
!      ‘cfuged’ instruction.
  
   -- Built-in Function: unsigned long long __builtin_cntlzdm (unsigned
            long long, unsigned long long)
       Perform a 64-bit count leading zeros operation under mask, as if
!      implemented by the ‘cntlzdm’ instruction.
  
   -- Built-in Function: unsigned long long __builtin_cnttzdm (unsigned
            long long, unsigned long long)
       Perform a 64-bit count trailing zeros operation under mask, as if
!      implemented by the ‘cnttzdm’ instruction.
  
   -- Built-in Function: unsigned long long __builtin_pdepd (unsigned long
            long, unsigned long long)
       Perform a 64-bit parallel bits deposit operation, as if implemented
!      by the ‘pdepd’ instruction.
  
   -- Built-in Function: unsigned long long __builtin_pextd (unsigned long
            long, unsigned long long)
       Perform a 64-bit parallel bits extract operation, as if implemented
!      by the ‘pextd’ instruction.
  
   -- Built-in Function: vector signed __int128 vsx_xl_sext (signed long
            long, signed char *)
*************** that use a future architecture instructi
*** 52128,52134 ****
            long, unsigned long long *)
  
       Load (and sign extend) to an __int128 vector, as if implemented by
!      the ISA 3.1 'lxvrbx', 'lxvrhx', 'lxvrwx', and 'lxvrdx'
       instructions.
  
   -- Built-in Function: void vec_xst_trunc (vector signed __int128,
--- 52137,52143 ----
            long, unsigned long long *)
  
       Load (and sign extend) to an __int128 vector, as if implemented by
!      the ISA 3.1 ‘lxvrbx’, ‘lxvrhx’, ‘lxvrwx’, and ‘lxvrdx’
       instructions.
  
   -- Built-in Function: void vec_xst_trunc (vector signed __int128,
*************** that use a future architecture instructi
*** 52149,52156 ****
            signed long long, unsigned long long *)
  
       Truncate and store the rightmost element of a vector, as if
!      implemented by the ISA 3.1 'stxvrbx', 'stxvrhx', 'stxvrwx', and
!      'stxvrdx' instructions.
  
  
  File: gcc.info,  Node: PowerPC AltiVec/VSX Built-in Functions,  Next: PowerPC Hardware Transactional Memory Built-in Functions,  Prev: Basic PowerPC Built-in Functions,  Up: Target Builtins
--- 52158,52165 ----
            signed long long, unsigned long long *)
  
       Truncate and store the rightmost element of a vector, as if
!      implemented by the ISA 3.1 ‘stxvrbx’, ‘stxvrhx’, ‘stxvrwx’, and
!      ‘stxvrdx’ instructions.
  
  
  File: gcc.info,  Node: PowerPC AltiVec/VSX Built-in Functions,  Next: PowerPC Hardware Transactional Memory Built-in Functions,  Prev: Basic PowerPC Built-in Functions,  Up: Target Builtins
*************** File: gcc.info,  Node: PowerPC AltiVec/V
*** 52161,52167 ****
  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
! '' and using '-maltivec' and '-mabi=altivec'.  The interface
  supports the following vector types.
  
       vector unsigned char
--- 52170,52176 ----
  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
! ‘’ and using ‘-maltivec’ and ‘-mabi=altivec’.  The interface
  supports the following vector types.
  
       vector unsigned char
*************** supports the following vector types.
*** 52182,52232 ****
  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
!      '' instead.
  
!    * GCC allows using a 'typedef' name as the type specifier for a
       vector type, but only under the following circumstances:
  
!         * When using '__vector' instead of 'vector'; for example,
  
                 typedef signed short int16;
                 __vector int16 data;
  
!         * When using 'vector' in keyword-and-predefine mode; for
            example,
  
                 typedef signed short int16;
                 vector int16 data;
  
            Note that keyword-and-predefine mode is enabled by disabling
!           GNU extensions (e.g., by using '-std=c11') and including
!           ''.
  
!    * 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 '' 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.
--- 52191,52241 ----
  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
!      ‘’ instead.
  
!    • GCC allows using a ‘typedef’ name as the type specifier for a
       vector type, but only under the following circumstances:
  
!         • When using ‘__vector’ instead of ‘vector’; for example,
  
                 typedef signed short int16;
                 __vector int16 data;
  
!         • When using ‘vector’ in keyword-and-predefine mode; for
            example,
  
                 typedef signed short int16;
                 vector int16 data;
  
            Note that keyword-and-predefine mode is enabled by disabling
!           GNU extensions (e.g., by using ‘-std=c11’) and including
!           ‘’.
  
!    • 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 ‘’ 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.
*************** same capabilities should be considered d
*** 52244,52313 ****
  
   The PVIPR documents the following overloaded functions:
  
! 'vec_abs'                'vec_absd'               'vec_abss'
! 'vec_add'                'vec_addc'               'vec_adde'
! 'vec_addec'              'vec_adds'               'vec_all_eq'
! 'vec_all_ge'             'vec_all_gt'             'vec_all_in'
! 'vec_all_le'             'vec_all_lt'             'vec_all_nan'
! 'vec_all_ne'             'vec_all_nge'            'vec_all_ngt'
! 'vec_all_nle'            'vec_all_nlt'            'vec_all_numeric'
! 'vec_and'                'vec_andc'               'vec_any_eq'
! 'vec_any_ge'             'vec_any_gt'             'vec_any_le'
! 'vec_any_lt'             'vec_any_nan'            'vec_any_ne'
! 'vec_any_nge'            'vec_any_ngt'            'vec_any_nle'
! 'vec_any_nlt'            'vec_any_numeric'        'vec_any_out'
! 'vec_avg'                'vec_bperm'              'vec_ceil'
! 'vec_cipher_be'          'vec_cipherlast_be'      'vec_cmpb'
! 'vec_cmpeq'              'vec_cmpge'              'vec_cmpgt'
! 'vec_cmple'              'vec_cmplt'              'vec_cmpne'
! 'vec_cmpnez'             'vec_cntlz'              'vec_cntlz_lsbb'
! 'vec_cnttz'              'vec_cnttz_lsbb'         'vec_cpsgn'
! 'vec_ctf'                'vec_cts'                'vec_ctu'
! 'vec_div'                'vec_double'             'vec_doublee'
! 'vec_doubleh'            'vec_doublel'            'vec_doubleo'
! 'vec_eqv'                'vec_expte'              'vec_extract'
! 'vec_extract_exp'        'vec_extract_fp32_from_shorth''vec_extract_fp32_from_shortl'
! 'vec_extract_sig'        'vec_extract_4b'         'vec_first_match_index'
! 'vec_first_match_or_eos_index''vec_first_mismatch_index''vec_first_mismatch_or_eos_index'
! 'vec_float'              'vec_float2'             'vec_floate'
! 'vec_floato'             'vec_floor'              'vec_gb'
! 'vec_insert'             'vec_insert_exp'         'vec_insert4b'
! 'vec_ld'                 'vec_lde'                'vec_ldl'
! 'vec_loge'               'vec_madd'               'vec_madds'
! 'vec_max'                'vec_mergee'             'vec_mergeh'
! 'vec_mergel'             'vec_mergeo'             'vec_mfvscr'
! 'vec_min'                'vec_mradds'             'vec_msub'
! 'vec_msum'               'vec_msums'              'vec_mtvscr'
! 'vec_mul'                'vec_mule'               'vec_mulo'
! 'vec_nabs'               'vec_nand'               'vec_ncipher_be'
! 'vec_ncipherlast_be'     'vec_nearbyint'          'vec_neg'
! 'vec_nmadd'              'vec_nmsub'              'vec_nor'
! 'vec_or'                 'vec_orc'                'vec_pack'
! 'vec_pack_to_short_fp32' 'vec_packpx'             'vec_packs'
! 'vec_packsu'             'vec_parity_lsbb'        'vec_perm'
! 'vec_permxor'            'vec_pmsum_be'           'vec_popcnt'
! 'vec_re'                 'vec_recipdiv'           'vec_revb'
! 'vec_reve'               'vec_rint'               'vec_rl'
! 'vec_rlmi'               'vec_rlnm'               'vec_round'
! 'vec_rsqrt'              'vec_rsqrte'             'vec_sbox_be'
! 'vec_sel'                'vec_shasigma_be'        'vec_signed'
! 'vec_signed2'            'vec_signede'            'vec_signedo'
! 'vec_sl'                 'vec_sld'                'vec_sldw'
! 'vec_sll'                'vec_slo'                'vec_slv'
! 'vec_splat'              'vec_splat_s8'           'vec_splat_s16'
! 'vec_splat_s32'          'vec_splat_u8'           'vec_splat_u16'
! 'vec_splat_u32'          'vec_splats'             'vec_sqrt'
! 'vec_sr'                 'vec_sra'                'vec_srl'
! 'vec_sro'                'vec_srv'                'vec_st'
! 'vec_ste'                'vec_stl'                'vec_sub'
! 'vec_subc'               'vec_sube'               'vec_subec'
! 'vec_subs'               'vec_sum2s'              'vec_sum4s'
! 'vec_sums'               'vec_test_data_class'    'vec_trunc'
! 'vec_unpackh'            'vec_unpackl'            'vec_unsigned'
! 'vec_unsigned2'          'vec_unsignede'          'vec_unsignedo'
! 'vec_xl'                 'vec_xl_be'              'vec_xl_len'
! 'vec_xl_len_r'           'vec_xor'                'vec_xst'
! 'vec_xst_be'             'vec_xst_len'            'vec_xst_len_r'
                                                    
  
  * Menu:
--- 52253,52322 ----
  
   The PVIPR documents the following overloaded functions:
  
! ‘vec_abs’                ‘vec_absd’               ‘vec_abss’
! ‘vec_add’                ‘vec_addc’               ‘vec_adde’
! ‘vec_addec’              ‘vec_adds’               ‘vec_all_eq’
! ‘vec_all_ge’             ‘vec_all_gt’             ‘vec_all_in’
! ‘vec_all_le’             ‘vec_all_lt’             ‘vec_all_nan’
! ‘vec_all_ne’             ‘vec_all_nge’            ‘vec_all_ngt’
! ‘vec_all_nle’            ‘vec_all_nlt’            ‘vec_all_numeric’
! ‘vec_and’                ‘vec_andc’               ‘vec_any_eq’
! ‘vec_any_ge’             ‘vec_any_gt’             ‘vec_any_le’
! ‘vec_any_lt’             ‘vec_any_nan’            ‘vec_any_ne’
! ‘vec_any_nge’            ‘vec_any_ngt’            ‘vec_any_nle’
! ‘vec_any_nlt’            ‘vec_any_numeric’        ‘vec_any_out’
! ‘vec_avg’                ‘vec_bperm’              ‘vec_ceil’
! ‘vec_cipher_be’          ‘vec_cipherlast_be’      ‘vec_cmpb’
! ‘vec_cmpeq’              ‘vec_cmpge’              ‘vec_cmpgt’
! ‘vec_cmple’              ‘vec_cmplt’              ‘vec_cmpne’
! ‘vec_cmpnez’             ‘vec_cntlz’              ‘vec_cntlz_lsbb’
! ‘vec_cnttz’              ‘vec_cnttz_lsbb’         ‘vec_cpsgn’
! ‘vec_ctf’                ‘vec_cts’                ‘vec_ctu’
! ‘vec_div’                ‘vec_double’             ‘vec_doublee’
! ‘vec_doubleh’            ‘vec_doublel’            ‘vec_doubleo’
! ‘vec_eqv’                ‘vec_expte’              ‘vec_extract’
! ‘vec_extract_exp’        ‘vec_extract_fp32_from_shorth’‘vec_extract_fp32_from_shortl’
! ‘vec_extract_sig’        ‘vec_extract_4b’         ‘vec_first_match_index’
! ‘vec_first_match_or_eos_index’‘vec_first_mismatch_index’‘vec_first_mismatch_or_eos_index’
! ‘vec_float’              ‘vec_float2’             ‘vec_floate’
! ‘vec_floato’             ‘vec_floor’              ‘vec_gb’
! ‘vec_insert’             ‘vec_insert_exp’         ‘vec_insert4b’
! ‘vec_ld’                 ‘vec_lde’                ‘vec_ldl’
! ‘vec_loge’               ‘vec_madd’               ‘vec_madds’
! ‘vec_max’                ‘vec_mergee’             ‘vec_mergeh’
! ‘vec_mergel’             ‘vec_mergeo’             ‘vec_mfvscr’
! ‘vec_min’                ‘vec_mradds’             ‘vec_msub’
! ‘vec_msum’               ‘vec_msums’              ‘vec_mtvscr’
! ‘vec_mul’                ‘vec_mule’               ‘vec_mulo’
! ‘vec_nabs’               ‘vec_nand’               ‘vec_ncipher_be’
! ‘vec_ncipherlast_be’     ‘vec_nearbyint’          ‘vec_neg’
! ‘vec_nmadd’              ‘vec_nmsub’              ‘vec_nor’
! ‘vec_or’                 ‘vec_orc’                ‘vec_pack’
! ‘vec_pack_to_short_fp32’ ‘vec_packpx’             ‘vec_packs’
! ‘vec_packsu’             ‘vec_parity_lsbb’        ‘vec_perm’
! ‘vec_permxor’            ‘vec_pmsum_be’           ‘vec_popcnt’
! ‘vec_re’                 ‘vec_recipdiv’           ‘vec_revb’
! ‘vec_reve’               ‘vec_rint’               ‘vec_rl’
! ‘vec_rlmi’               ‘vec_rlnm’               ‘vec_round’
! ‘vec_rsqrt’              ‘vec_rsqrte’             ‘vec_sbox_be’
! ‘vec_sel’                ‘vec_shasigma_be’        ‘vec_signed’
! ‘vec_signed2’            ‘vec_signede’            ‘vec_signedo’
! ‘vec_sl’                 ‘vec_sld’                ‘vec_sldw’
! ‘vec_sll’                ‘vec_slo’                ‘vec_slv’
! ‘vec_splat’              ‘vec_splat_s8’           ‘vec_splat_s16’
! ‘vec_splat_s32’          ‘vec_splat_u8’           ‘vec_splat_u16’
! ‘vec_splat_u32’          ‘vec_splats’             ‘vec_sqrt’
! ‘vec_sr’                 ‘vec_sra’                ‘vec_srl’
! ‘vec_sro’                ‘vec_srv’                ‘vec_st’
! ‘vec_ste’                ‘vec_stl’                ‘vec_sub’
! ‘vec_subc’               ‘vec_sube’               ‘vec_subec’
! ‘vec_subs’               ‘vec_sum2s’              ‘vec_sum4s’
! ‘vec_sums’               ‘vec_test_data_class’    ‘vec_trunc’
! ‘vec_unpackh’            ‘vec_unpackl’            ‘vec_unsigned’
! ‘vec_unsigned2’          ‘vec_unsignede’          ‘vec_unsignedo’
! ‘vec_xl’                 ‘vec_xl_be’              ‘vec_xl_len’
! ‘vec_xl_len_r’           ‘vec_xor’                ‘vec_xst’
! ‘vec_xst_be’             ‘vec_xst_len’            ‘vec_xst_len_r’
                                                    
  
  * Menu:
*************** a direct mapping between generic and spe
*** 52330,52336 ****
  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.
  
   Only functions excluded from the PVIPR are listed here.
--- 52339,52345 ----
  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.
  
   Only functions excluded from the PVIPR are listed here.
*************** File: gcc.info,  Node: PowerPC AltiVec B
*** 52808,52816 ****
  
  The AltiVec built-in functions described in this section are available
  on the PowerPC family of processors starting with ISA 2.06 or later.
! These are normally enabled by adding '-mvsx' to the command line.
  
!  When '-mvsx' is used, the following additional vector types are
  implemented.
  
       vector unsigned __int128
--- 52817,52825 ----
  
  The AltiVec built-in functions described in this section are available
  on the PowerPC family of processors starting with ISA 2.06 or later.
! These are normally enabled by adding ‘-mvsx’ to the command line.
  
!  When ‘-mvsx’ is used, the following additional vector types are
  implemented.
  
       vector unsigned __int128
*************** implemented.
*** 52923,52932 ****
       vector unsigned char vec_xxsldi (vector unsigned char,
                                        vector unsigned char, int);
  
!  Note that the 'vec_ld' and 'vec_st' built-in functions always generate
! the AltiVec 'LVX' and 'STVX' instructions even if the VSX instruction
! set is available.  The 'vec_vsx_ld' and 'vec_vsx_st' built-in functions
! always generate the VSX 'LXVD2X', 'LXVW4X', 'STXVD2X', and 'STXVW4X'
  instructions.
  
  
--- 52932,52941 ----
       vector unsigned char vec_xxsldi (vector unsigned char,
                                        vector unsigned char, int);
  
!  Note that the ‘vec_ld’ and ‘vec_st’ built-in functions always generate
! the AltiVec ‘LVX’ and ‘STVX’ instructions even if the VSX instruction
! set is available.  The ‘vec_vsx_ld’ and ‘vec_vsx_st’ built-in functions
! always generate the VSX ‘LXVD2X’, ‘LXVW4X’, ‘STXVD2X’, and ‘STXVW4X’
  instructions.
  
  
*************** File: gcc.info,  Node: PowerPC AltiVec B
*** 53125,53131 ****
  .................................................................
  
  The following additional built-in functions are also available for the
! PowerPC family of processors, starting with ISA 3.0 ('-mcpu=power9') or
  later.
  
   Only instructions excluded from the PVIPR are listed here.
--- 53134,53140 ----
  .................................................................
  
  The following additional built-in functions are also available for the
! PowerPC family of processors, starting with ISA 3.0 (‘-mcpu=power9’) or
  later.
  
   Only instructions excluded from the PVIPR are listed here.
*************** later.
*** 53157,53205 ****
       bool scalar_test_neg (double source);
       bool scalar_test_neg (__ieee128 source);
  
!  The 'scalar_extract_exp' and 'scalar_extract_sig' functions require a
  64-bit environment supporting ISA 3.0 or later.  The
! 'scalar_extract_exp' and 'scalar_extract_sig' built-in functions return
  the significand and the biased exponent value respectively of their
! 'source' arguments.  When supplied with a 64-bit 'source' argument, the
! result returned by 'scalar_extract_sig' has the '0x0010000000000000' bit
! set if the function's 'source' argument is in normalized form.
! Otherwise, this bit is set to 0.  When supplied with a 128-bit 'source'
! argument, the '0x00010000000000000000000000000000' bit of the result is
  treated similarly.  Note that the sign of the significand is not
! represented in the result returned from the 'scalar_extract_sig'
! function.  Use the 'scalar_test_neg' function to test the sign of its
! 'double' argument.
  
!  The 'scalar_insert_exp' functions require a 64-bit environment
  supporting ISA 3.0 or later.  When supplied with a 64-bit first
! argument, the 'scalar_insert_exp' built-in function returns a
  double-precision floating point value that is constructed by assembling
! the values of its 'significand' and 'exponent' arguments.  The sign of
! the result is copied from the most significant bit of the 'significand'
  argument.  The significand and exponent components of the result are
! composed of the least significant 11 bits of the 'exponent' argument and
! the least significant 52 bits of the 'significand' argument
  respectively.
  
!  When supplied with a 128-bit first argument, the 'scalar_insert_exp'
  built-in function returns a quad-precision ieee floating point value.
  The sign bit of the result is copied from the most significant bit of
! the 'significand' argument.  The significand and exponent components of
  the result are composed of the least significant 15 bits of the
! 'exponent' argument and the least significant 112 bits of the
! 'significand' argument respectively.
  
!  The 'scalar_cmp_exp_gt', 'scalar_cmp_exp_lt', 'scalar_cmp_exp_eq', and
! 'scalar_cmp_exp_unordered' built-in functions return a non-zero value if
! 'arg1' is greater than, less than, equal to, or not comparable to 'arg2'
  respectively.  The arguments are not comparable if one or the other
  equals NaN (not a number).
  
!  The 'scalar_test_data_class' built-in function returns 1 if any of the
! condition tests enabled by the value of the 'condition' variable are
! true, and 0 otherwise.  The 'condition' argument must be a compile-time
! constant integer with value not exceeding 127.  The 'condition' argument
  is encoded as a bitmask with each bit enabling the testing of a
  different condition, as characterized by the following:
       0x40    Test for NaN
--- 53166,53214 ----
       bool scalar_test_neg (double source);
       bool scalar_test_neg (__ieee128 source);
  
!  The ‘scalar_extract_exp’ and ‘scalar_extract_sig’ functions require a
  64-bit environment supporting ISA 3.0 or later.  The
! ‘scalar_extract_exp’ and ‘scalar_extract_sig’ built-in functions return
  the significand and the biased exponent value respectively of their
! ‘source’ arguments.  When supplied with a 64-bit ‘source’ argument, the
! result returned by ‘scalar_extract_sig’ has the ‘0x0010000000000000’ bit
! set if the function's ‘source’ argument is in normalized form.
! Otherwise, this bit is set to 0.  When supplied with a 128-bit ‘source’
! argument, the ‘0x00010000000000000000000000000000’ bit of the result is
  treated similarly.  Note that the sign of the significand is not
! represented in the result returned from the ‘scalar_extract_sig’
! function.  Use the ‘scalar_test_neg’ function to test the sign of its
! ‘double’ argument.
  
!  The ‘scalar_insert_exp’ functions require a 64-bit environment
  supporting ISA 3.0 or later.  When supplied with a 64-bit first
! argument, the ‘scalar_insert_exp’ built-in function returns a
  double-precision floating point value that is constructed by assembling
! the values of its ‘significand’ and ‘exponent’ arguments.  The sign of
! the result is copied from the most significant bit of the ‘significand’
  argument.  The significand and exponent components of the result are
! composed of the least significant 11 bits of the ‘exponent’ argument and
! the least significant 52 bits of the ‘significand’ argument
  respectively.
  
!  When supplied with a 128-bit first argument, the ‘scalar_insert_exp’
  built-in function returns a quad-precision ieee floating point value.
  The sign bit of the result is copied from the most significant bit of
! the ‘significand’ argument.  The significand and exponent components of
  the result are composed of the least significant 15 bits of the
! ‘exponent’ argument and the least significant 112 bits of the
! ‘significand’ argument respectively.
  
!  The ‘scalar_cmp_exp_gt’, ‘scalar_cmp_exp_lt’, ‘scalar_cmp_exp_eq’, and
! ‘scalar_cmp_exp_unordered’ built-in functions return a non-zero value if
! ‘arg1’ is greater than, less than, equal to, or not comparable to ‘arg2’
  respectively.  The arguments are not comparable if one or the other
  equals NaN (not a number).
  
!  The ‘scalar_test_data_class’ built-in function returns 1 if any of the
! condition tests enabled by the value of the ‘condition’ variable are
! true, and 0 otherwise.  The ‘condition’ argument must be a compile-time
! constant integer with value not exceeding 127.  The ‘condition’ argument
  is encoded as a bitmask with each bit enabling the testing of a
  different condition, as characterized by the following:
       0x40    Test for NaN
*************** different condition, as characterized by
*** 53210,53220 ****
       0x02    Test for +Denormal
       0x01    Test for -Denormal
  
!  The 'scalar_test_neg' built-in function returns 1 if its 'source'
  argument holds a negative value, 0 otherwise.
  
   The following built-in functions are also available for the PowerPC
! family of processors, starting with ISA 3.0 or later ('-mcpu=power9').
  These string functions are described separately in order to group the
  descriptions closer to the function prototypes.
  
--- 53219,53229 ----
       0x02    Test for +Denormal
       0x01    Test for -Denormal
  
!  The ‘scalar_test_neg’ built-in function returns 1 if its ‘source’
  argument holds a negative value, 0 otherwise.
  
   The following built-in functions are also available for the PowerPC
! family of processors, starting with ISA 3.0 or later (‘-mcpu=power9’).
  These string functions are described separately in order to group the
  descriptions closer to the function prototypes.
  
*************** descriptions closer to the function prot
*** 53250,53284 ****
       unsigned int vec_xrx (unsigned int index, vector unsigned int data);
       float vec_xrx (unsigned int index, vector float data);
  
!  The 'vec_all_nez', 'vec_any_eqz', and 'vec_cmpnez' perform pairwise
  comparisons between the elements at the same positions within their two
! vector arguments.  The 'vec_all_nez' function returns a non-zero value
  if and only if all pairwise comparisons are not equal and no element of
! either vector argument contains a zero.  The 'vec_any_eqz' function
  returns a non-zero value if and only if at least one pairwise comparison
  is equal or if at least one element of either vector argument contains a
! zero.  The 'vec_cmpnez' function returns a vector of the same type as
  its two arguments, within which each element consists of all ones to
  denote that either the corresponding elements of the incoming arguments
  are not equal or that at least one of the corresponding elements
  contains zero.  Otherwise, the element of the returned vector contains
  all zeros.
  
!  The 'vec_xlx' and 'vec_xrx' functions extract the single element
! selected by the 'index' argument from the vector represented by the
! 'data' argument.  The 'index' argument always specifies a byte offset,
! regardless of the size of the vector element.  With 'vec_xlx', 'index'
  is the offset of the first byte of the element to be extracted.  With
! 'vec_xrx', 'index' represents the last byte of the element to be
  extracted, measured from the right end of the vector.  In other words,
! the last byte of the element to be extracted is found at position '(15 -
! index)'.  There is no requirement that 'index' be a multiple of the
  vector element size.  However, if the size of the vector element added
! to 'index' is greater than 15, the content of the returned value is
  undefined.
  
   The following functions are also available if the ISA 3.0 instruction
! set additions ('-mcpu=power9') are available.
  
   Only functions excluded from the PVIPR are listed here.
  
--- 53259,53293 ----
       unsigned int vec_xrx (unsigned int index, vector unsigned int data);
       float vec_xrx (unsigned int index, vector float data);
  
!  The ‘vec_all_nez’, ‘vec_any_eqz’, and ‘vec_cmpnez’ perform pairwise
  comparisons between the elements at the same positions within their two
! vector arguments.  The ‘vec_all_nez’ function returns a non-zero value
  if and only if all pairwise comparisons are not equal and no element of
! either vector argument contains a zero.  The ‘vec_any_eqz’ function
  returns a non-zero value if and only if at least one pairwise comparison
  is equal or if at least one element of either vector argument contains a
! zero.  The ‘vec_cmpnez’ function returns a vector of the same type as
  its two arguments, within which each element consists of all ones to
  denote that either the corresponding elements of the incoming arguments
  are not equal or that at least one of the corresponding elements
  contains zero.  Otherwise, the element of the returned vector contains
  all zeros.
  
!  The ‘vec_xlx’ and ‘vec_xrx’ functions extract the single element
! selected by the ‘index’ argument from the vector represented by the
! ‘data’ argument.  The ‘index’ argument always specifies a byte offset,
! regardless of the size of the vector element.  With ‘vec_xlx’, ‘index’
  is the offset of the first byte of the element to be extracted.  With
! ‘vec_xrx’, ‘index’ represents the last byte of the element to be
  extracted, measured from the right end of the vector.  In other words,
! the last byte of the element to be extracted is found at position ‘(15 -
! index)’.  There is no requirement that ‘index’ be a multiple of the
  vector element size.  However, if the size of the vector element added
! to ‘index’ is greater than 15, the content of the returned value is
  undefined.
  
   The following functions are also available if the ISA 3.0 instruction
! set additions (‘-mcpu=power9’) are available.
  
   Only functions excluded from the PVIPR are listed here.
  
*************** set additions ('-mcpu=power9') are avail
*** 53314,53320 ****
       vector long long vec_vprtybd (vector long long);
       vector unsigned long long vec_vprtybd (vector unsigned long long);
  
!  On 64-bit targets, if the ISA 3.0 additions ('-mcpu=power9') are
  available:
  
       vector long vec_vprtyb (vector long);
--- 53323,53329 ----
       vector long long vec_vprtybd (vector long long);
       vector unsigned long long vec_vprtybd (vector unsigned long long);
  
!  On 64-bit targets, if the ISA 3.0 additions (‘-mcpu=power9’) are
  available:
  
       vector long vec_vprtyb (vector long);
*************** available:
*** 53329,53335 ****
       vector __uint128 vec_vprtybd (vector __uint128);
  
   The following built-in functions are available for the PowerPC family
! of processors, starting with ISA 3.0 or later ('-mcpu=power9').
  
   Only functions excluded from the PVIPR are listed here.
  
--- 53338,53344 ----
       vector __uint128 vec_vprtybd (vector __uint128);
  
   The following built-in functions are available for the PowerPC family
! of processors, starting with ISA 3.0 or later (‘-mcpu=power9’).
  
   Only functions excluded from the PVIPR are listed here.
  
*************** of processors, starting with ISA 3.0 or
*** 53340,53363 ****
       __vector unsigned int
       vec_absdw (__vector unsigned int arg1, __vector unsigned int arg2);
  
!  The 'vec_absd', 'vec_absdb', 'vec_absdh', and 'vec_absdw' built-in
  functions each computes the absolute differences of the pairs of vector
  elements supplied in its two vector arguments, placing the absolute
  differences into the corresponding elements of the vector result.
  
   The following built-in functions are available for the PowerPC family
! of processors, starting with ISA 3.0 or later ('-mcpu=power9'):
       vector unsigned int vec_vrlnm (vector unsigned int, vector unsigned int);
       vector unsigned long long vec_vrlnm (vector unsigned long long,
                                            vector unsigned long long);
  
!  The result of 'vec_vrlnm' is obtained by rotating each element of the
  first argument vector left and ANDing it with a mask.  The second
  argument vector contains the mask beginning in bits 11:15, the mask end
  in bits 19:23, and the shift count in bits 27:31, of each element.
  
!  If the cryptographic instructions are enabled ('-mcrypto' or
! '-mcpu=power8'), the following builtins are enabled.
  
   Only functions excluded from the PVIPR are listed here.
  
--- 53349,53372 ----
       __vector unsigned int
       vec_absdw (__vector unsigned int arg1, __vector unsigned int arg2);
  
!  The ‘vec_absd’, ‘vec_absdb’, ‘vec_absdh’, and ‘vec_absdw’ built-in
  functions each computes the absolute differences of the pairs of vector
  elements supplied in its two vector arguments, placing the absolute
  differences into the corresponding elements of the vector result.
  
   The following built-in functions are available for the PowerPC family
! of processors, starting with ISA 3.0 or later (‘-mcpu=power9’):
       vector unsigned int vec_vrlnm (vector unsigned int, vector unsigned int);
       vector unsigned long long vec_vrlnm (vector unsigned long long,
                                            vector unsigned long long);
  
!  The result of ‘vec_vrlnm’ is obtained by rotating each element of the
  first argument vector left and ANDing it with a mask.  The second
  argument vector contains the mask beginning in bits 11:15, the mask end
  in bits 19:23, and the shift count in bits 27:31, of each element.
  
!  If the cryptographic instructions are enabled (‘-mcrypto’ or
! ‘-mcpu=power8’), the following builtins are enabled.
  
   Only functions excluded from the PVIPR are listed here.
  
*************** File: gcc.info,  Node: PowerPC AltiVec B
*** 53436,53480 ****
  .................................................................
  
  The following additional built-in functions are also available for the
! PowerPC family of processors, starting with ISA 3.1 ('-mcpu=power10'):
  
  vector unsigned long long int
  vec_cfuge (vector unsigned long long int, vector unsigned long long int);
   Perform a vector centrifuge operation, as if implemented by the
! 'vcfuged' instruction.
  
  vector unsigned long long int
  vec_cntlzm (vector unsigned long long int, vector unsigned long long int);
   Perform a vector count leading zeros under bit mask operation, as if
! implemented by the 'vclzdm' instruction.
  
  vector unsigned long long int
  vec_cnttzm (vector unsigned long long int, vector unsigned long long int);
   Perform a vector count trailing zeros under bit mask operation, as if
! implemented by the 'vctzdm' instruction.
  
  vector signed char
  vec_clrl (vector signed char A, unsigned int N);
  vector unsigned char
  vec_clrl (vector unsigned char A, unsigned int N);
!  Clear the left-most '(16 - n)' bytes of vector argument 'a', as if
! implemented by the 'vclrlb' instruction on a big-endian target and by
! the 'vclrrb' instruction on a little-endian target.  A value of 'n' that
  is greater than 16 is treated as if it equaled 16.
  
  vector signed char
  vec_clrr (vector signed char A, unsigned int N);
  vector unsigned char
  vec_clrr (vector unsigned char A, unsigned int N);
!  Clear the right-most '(16 - n)' bytes of vector argument 'a', as if
! implemented by the 'vclrrb' instruction on a big-endian target and by
! the 'vclrlb' instruction on a little-endian target.  A value of 'n' that
  is greater than 16 is treated as if it equaled 16.
  
  vector unsigned long long int
  vec_gnb (vector unsigned __int128, const unsigned char);
   Perform a 128-bit vector gather operation, as if implemented by the
! 'vgnb' instruction.  The second argument must be a literal integer value
  between 2 and 7 inclusive.
  
   Vector Extract
--- 53445,53489 ----
  .................................................................
  
  The following additional built-in functions are also available for the
! PowerPC family of processors, starting with ISA 3.1 (‘-mcpu=power10’):
  
  vector unsigned long long int
  vec_cfuge (vector unsigned long long int, vector unsigned long long int);
   Perform a vector centrifuge operation, as if implemented by the
! ‘vcfuged’ instruction.
  
  vector unsigned long long int
  vec_cntlzm (vector unsigned long long int, vector unsigned long long int);
   Perform a vector count leading zeros under bit mask operation, as if
! implemented by the ‘vclzdm’ instruction.
  
  vector unsigned long long int
  vec_cnttzm (vector unsigned long long int, vector unsigned long long int);
   Perform a vector count trailing zeros under bit mask operation, as if
! implemented by the ‘vctzdm’ instruction.
  
  vector signed char
  vec_clrl (vector signed char A, unsigned int N);
  vector unsigned char
  vec_clrl (vector unsigned char A, unsigned int N);
!  Clear the left-most ‘(16 - n)’ bytes of vector argument ‘a’, as if
! implemented by the ‘vclrlb’ instruction on a big-endian target and by
! the ‘vclrrb’ instruction on a little-endian target.  A value of ‘n’ that
  is greater than 16 is treated as if it equaled 16.
  
  vector signed char
  vec_clrr (vector signed char A, unsigned int N);
  vector unsigned char
  vec_clrr (vector unsigned char A, unsigned int N);
!  Clear the right-most ‘(16 - n)’ bytes of vector argument ‘a’, as if
! implemented by the ‘vclrrb’ instruction on a big-endian target and by
! the ‘vclrlb’ instruction on a little-endian target.  A value of ‘n’ that
  is greater than 16 is treated as if it equaled 16.
  
  vector unsigned long long int
  vec_gnb (vector unsigned __int128, const unsigned char);
   Perform a 128-bit vector gather operation, as if implemented by the
! ‘vgnb’ instruction.  The second argument must be a literal integer value
  between 2 and 7 inclusive.
  
   Vector Extract
*************** rejected.  For little-endian, this outpu
*** 53495,53507 ****
  the hardware instruction, i.e., dword[0] in RTL notation.  For
  big-endian, an additional instruction is needed to move it from the
  "left" doubleword to the "right" one.  For little-endian, semantics
! matching the 'vextdubvrx', 'vextduhvrx', 'vextduwvrx' instruction will
! be generated, while for big-endian, semantics matching the 'vextdubvlx',
! 'vextduhvlx', 'vextduwvlx' instructions will be generated.  Note that
  some fairly anomalous results can be generated if the byte index is not
  aligned on an element boundary for the element being extracted.  This is
  a limitation of the bi-endian vector programming model is consistent
! with the limitation on 'vec_perm'.
  
  vector unsigned long long int
  vec_extracth (vector unsigned char, vector unsigned char, unsigned int);
--- 53504,53516 ----
  the hardware instruction, i.e., dword[0] in RTL notation.  For
  big-endian, an additional instruction is needed to move it from the
  "left" doubleword to the "right" one.  For little-endian, semantics
! matching the ‘vextdubvrx’, ‘vextduhvrx’, ‘vextduwvrx’ instruction will
! be generated, while for big-endian, semantics matching the ‘vextdubvlx’,
! ‘vextduhvlx’, ‘vextduwvlx’ instructions will be generated.  Note that
  some fairly anomalous results can be generated if the byte index is not
  aligned on an element boundary for the element being extracted.  This is
  a limitation of the bi-endian vector programming model is consistent
! with the limitation on ‘vec_perm’.
  
  vector unsigned long long int
  vec_extracth (vector unsigned char, vector unsigned char, unsigned int);
*************** little-endian, this output will match th
*** 53523,53540 ****
  instruction (vextdubvrx, vextduhvrx, vextduwvrx, vextddvrx) i.e.,
  dword[0] in RTL notation.  For big-endian, an additional instruction is
  needed to move it from the "left" doubleword to the "right" one.  For
! little-endian, semantics matching the 'vextdubvlx', 'vextduhvlx',
! 'vextduwvlx' instructions will be generated, while for big-endian,
! semantics matching the 'vextdubvrx', 'vextduhvrx', 'vextduwvrx'
  instructions will be generated.  Note that some fairly anomalous results
  can be generated if the byte index is not aligned on the element
  boundary for the element being extracted.  This is a limitation of the
  bi-endian vector programming model consistent with the limitation on
! 'vec_perm'.
  vector unsigned long long int
  vec_pdep (vector unsigned long long int, vector unsigned long long int);
   Perform a vector parallel bits deposit operation, as if implemented by
! the 'vpdepd' instruction.
  
   Vector Insert
  
--- 53532,53549 ----
  instruction (vextdubvrx, vextduhvrx, vextduwvrx, vextddvrx) i.e.,
  dword[0] in RTL notation.  For big-endian, an additional instruction is
  needed to move it from the "left" doubleword to the "right" one.  For
! little-endian, semantics matching the ‘vextdubvlx’, ‘vextduhvlx’,
! ‘vextduwvlx’ instructions will be generated, while for big-endian,
! semantics matching the ‘vextdubvrx’, ‘vextduhvrx’, ‘vextduwvrx’
  instructions will be generated.  Note that some fairly anomalous results
  can be generated if the byte index is not aligned on the element
  boundary for the element being extracted.  This is a limitation of the
  bi-endian vector programming model consistent with the limitation on
! ‘vec_perm’.
  vector unsigned long long int
  vec_pdep (vector unsigned long long int, vector unsigned long long int);
   Perform a vector parallel bits deposit operation, as if implemented by
! the ‘vpdepd’ instruction.
  
   Vector Insert
  
*************** in the second argument.  The rest of the
*** 53563,53570 ****
  If the byte index is greater than 14 for halfwords, greater than 12 for
  words, or greater than 8 for doublewords the result is undefined.  For
  little-endian, the generated code will be semantically equivalent to
! 'vins[bhwd]rx' instructions.  Similarly for big-endian it will be
! semantically equivalent to 'vins[bhwd]lx'.  Note that some fairly
  anomalous results can be generated if the byte index is not aligned on
  an element boundary for the type of element being inserted.
  
--- 53572,53579 ----
  If the byte index is greater than 14 for halfwords, greater than 12 for
  words, or greater than 8 for doublewords the result is undefined.  For
  little-endian, the generated code will be semantically equivalent to
! ‘vins[bhwd]rx’ instructions.  Similarly for big-endian it will be
! semantically equivalent to ‘vins[bhwd]lx’.  Note that some fairly
  anomalous results can be generated if the byte index is not aligned on
  an element boundary for the type of element being inserted.
  
*************** If the byte index is greater than 14 for
*** 53594,53601 ****
  for doublewords, the intrinsic will be rejected.  Note that the
  underlying hardware instruction uses the same register for the second
  argument and the result.  For little-endian, the code generation will be
! semantically equivalent to 'vins[bhwd]lx', while for big-endian it will
! be semantically equivalent to 'vins[bhwd]rx'.  Note that some fairly
  anomalous results can be generated if the byte index is not aligned on
  an element boundary for the sort of element being inserted.
  
--- 53603,53610 ----
  for doublewords, the intrinsic will be rejected.  Note that the
  underlying hardware instruction uses the same register for the second
  argument and the result.  For little-endian, the code generation will be
! semantically equivalent to ‘vins[bhwd]lx’, while for big-endian it will
! be semantically equivalent to ‘vins[bhwd]rx’.  Note that some fairly
  anomalous results can be generated if the byte index is not aligned on
  an element boundary for the sort of element being inserted.
  
*************** vector double vec_blendv (vector double,
*** 53735,53741 ****
  
   Blend the first and second argument vectors according to the sign bits
  of the corresponding elements of the third argument vector.  This is
! similar to the 'vsel' and 'xxsel' instructions but for bigger elements.
  
   Vector Permute Extended
  
--- 53744,53750 ----
  
   Blend the first and second argument vectors according to the sign bits
  of the corresponding elements of the third argument vector.  This is
! similar to the ‘vsel’ and ‘xxsel’ instructions but for bigger elements.
  
   Vector Permute Extended
  
*************** of the emulated vector is contained in t
*** 53769,53775 ****
  vector unsigned long long int
  vec_pext (vector unsigned long long int, vector unsigned long long int);
   Perform a vector parallel bit extract operation, as if implemented by
! the 'vpextd' instruction.
  
  vector unsigned char vec_stril (vector unsigned char);
  vector signed char vec_stril (vector signed char);
--- 53778,53784 ----
  vector unsigned long long int
  vec_pext (vector unsigned long long int, vector unsigned long long int);
   Perform a vector parallel bit extract operation, as if implemented by
! the ‘vpextd’ instruction.
  
  vector unsigned char vec_stril (vector unsigned char);
  vector signed char vec_stril (vector signed char);
*************** vector signed short vec_stril (vector si
*** 53778,53796 ****
   Isolate the left-most non-zero elements of the incoming vector
  argument, replacing all elements to the right of the left-most zero
  element found within the argument with zero.  The typical implementation
! uses the 'vstribl' or 'vstrihl' instruction on big-endian targets and
! uses the 'vstribr' or 'vstrihr' instruction on little-endian targets.
  
  int vec_stril_p (vector unsigned char);
  int vec_stril_p (vector signed char);
  int short vec_stril_p (vector unsigned short);
  int vec_stril_p (vector signed short);
   Return a non-zero value if and only if the argument contains a zero
! element.  The typical implementation uses the 'vstribl.' or 'vstrihl.'
! instruction on big-endian targets and uses the 'vstribr.' or 'vstrihr.'
  instruction on little-endian targets.  Choose this built-in to check for
  presence of zero element if the same argument is also passed to
! 'vec_stril'.
  
  vector unsigned char vec_strir (vector unsigned char);
  vector signed char vec_strir (vector signed char);
--- 53787,53805 ----
   Isolate the left-most non-zero elements of the incoming vector
  argument, replacing all elements to the right of the left-most zero
  element found within the argument with zero.  The typical implementation
! uses the ‘vstribl’ or ‘vstrihl’ instruction on big-endian targets and
! uses the ‘vstribr’ or ‘vstrihr’ instruction on little-endian targets.
  
  int vec_stril_p (vector unsigned char);
  int vec_stril_p (vector signed char);
  int short vec_stril_p (vector unsigned short);
  int vec_stril_p (vector signed short);
   Return a non-zero value if and only if the argument contains a zero
! element.  The typical implementation uses the ‘vstribl.’ or ‘vstrihl.’
! instruction on big-endian targets and uses the ‘vstribr.’ or ‘vstrihr.’
  instruction on little-endian targets.  Choose this built-in to check for
  presence of zero element if the same argument is also passed to
! ‘vec_stril’.
  
  vector unsigned char vec_strir (vector unsigned char);
  vector signed char vec_strir (vector signed char);
*************** vector signed short vec_strir (vector si
*** 53799,53817 ****
   Isolate the right-most non-zero elements of the incoming vector
  argument, replacing all elements to the left of the right-most zero
  element found within the argument with zero.  The typical implementation
! uses the 'vstribr' or 'vstrihr' instruction on big-endian targets and
! uses the 'vstribl' or 'vstrihl' instruction on little-endian targets.
  
  int vec_strir_p (vector unsigned char);
  int vec_strir_p (vector signed char);
  int short vec_strir_p (vector unsigned short);
  int vec_strir_p (vector signed short);
   Return a non-zero value if and only if the argument contains a zero
! element.  The typical implementation uses the 'vstribr.' or 'vstrihr.'
! instruction on big-endian targets and uses the 'vstribl.' or 'vstrihl.'
  instruction on little-endian targets.  Choose this built-in to check for
  presence of zero element if the same argument is also passed to
! 'vec_strir'.
  
  vector unsigned char
  vec_ternarylogic (vector unsigned char, vector unsigned char,
--- 53808,53826 ----
   Isolate the right-most non-zero elements of the incoming vector
  argument, replacing all elements to the left of the right-most zero
  element found within the argument with zero.  The typical implementation
! uses the ‘vstribr’ or ‘vstrihr’ instruction on big-endian targets and
! uses the ‘vstribl’ or ‘vstrihl’ instruction on little-endian targets.
  
  int vec_strir_p (vector unsigned char);
  int vec_strir_p (vector signed char);
  int short vec_strir_p (vector unsigned short);
  int vec_strir_p (vector signed short);
   Return a non-zero value if and only if the argument contains a zero
! element.  The typical implementation uses the ‘vstribr.’ or ‘vstrihr.’
! instruction on big-endian targets and uses the ‘vstribl.’ or ‘vstrihl.’
  instruction on little-endian targets.  Choose this built-in to check for
  presence of zero element if the same argument is also passed to
! ‘vec_strir’.
  
  vector unsigned char
  vec_ternarylogic (vector unsigned char, vector unsigned char,
*************** vector unsigned __int128
*** 53829,53835 ****
  vec_ternarylogic (vector unsigned __int128, vector unsigned __int128,
                   vector unsigned __int128, const unsigned int);
   Perform a 128-bit vector evaluate operation, as if implemented by the
! 'xxeval' instruction.  The fourth argument must be a literal integer
  value between 0 and 255 inclusive.
  
  vector unsigned char vec_genpcvm (vector unsigned char, const int);
--- 53838,53844 ----
  vec_ternarylogic (vector unsigned __int128, vector unsigned __int128,
                   vector unsigned __int128, const unsigned int);
   Perform a 128-bit vector evaluate operation, as if implemented by the
! ‘xxeval’ instruction.  The fourth argument must be a literal integer
  value between 0 and 255 inclusive.
  
  vector unsigned char vec_genpcvm (vector unsigned char, const int);
*************** vec_mulh (vector signed int A, vector si
*** 53845,53883 ****
  vector unsigned int
  vec_mulh (vector unsigned int A, vector unsigned int B);
  
!  For each integer value 'i' from 0 to 3, do the following.  The integer
! value in word element 'i' of a is multiplied by the integer value in
! word element 'i' of b.  The high-order 32 bits of the 64-bit product are
! placed into word element 'i' of the vector returned.
  
  vector signed long long
  vec_mulh (vector signed long long A, vector signed long long B);
  vector unsigned long long
  vec_mulh (vector unsigned long long A, vector unsigned long long B);
  
!  For each integer value 'i' from 0 to 1, do the following.  The integer
! value in doubleword element 'i' of a is multiplied by the integer value
! in doubleword element 'i' of b.  The high-order 64 bits of the 128-bit
! product are placed into doubleword element 'i' of the vector returned.
  
  vector unsigned long long
  vec_mul (vector unsigned long long A, vector unsigned long long B);
  vector signed long long
  vec_mul (vector signed long long A, vector signed long long B);
  
!  For each integer value 'i' from 0 to 1, do the following.  The integer
! value in doubleword element 'i' of a is multiplied by the integer value
! in doubleword element 'i' of b.  The low-order 64 bits of the 128-bit
! product are placed into doubleword element 'i' of the vector returned.
  
  vector signed int
  vec_div (vector signed int A, vector signed int B);
  vector unsigned int
  vec_div (vector unsigned int A, vector unsigned int B);
  
!  For each integer value 'i' from 0 to 3, do the following.  The integer
! in word element 'i' of a is divided by the integer in word element 'i'
! of b.  The unique integer quotient is placed into the word element 'i'
  of the vector returned.  If an attempt is made to perform any of the
  divisions  ÷ 0 then the quotient is undefined.
  
--- 53854,53892 ----
  vector unsigned int
  vec_mulh (vector unsigned int A, vector unsigned int B);
  
!  For each integer value ‘i’ from 0 to 3, do the following.  The integer
! value in word element ‘i’ of a is multiplied by the integer value in
! word element ‘i’ of b.  The high-order 32 bits of the 64-bit product are
! placed into word element ‘i’ of the vector returned.
  
  vector signed long long
  vec_mulh (vector signed long long A, vector signed long long B);
  vector unsigned long long
  vec_mulh (vector unsigned long long A, vector unsigned long long B);
  
!  For each integer value ‘i’ from 0 to 1, do the following.  The integer
! value in doubleword element ‘i’ of a is multiplied by the integer value
! in doubleword element ‘i’ of b.  The high-order 64 bits of the 128-bit
! product are placed into doubleword element ‘i’ of the vector returned.
  
  vector unsigned long long
  vec_mul (vector unsigned long long A, vector unsigned long long B);
  vector signed long long
  vec_mul (vector signed long long A, vector signed long long B);
  
!  For each integer value ‘i’ from 0 to 1, do the following.  The integer
! value in doubleword element ‘i’ of a is multiplied by the integer value
! in doubleword element ‘i’ of b.  The low-order 64 bits of the 128-bit
! product are placed into doubleword element ‘i’ of the vector returned.
  
  vector signed int
  vec_div (vector signed int A, vector signed int B);
  vector unsigned int
  vec_div (vector unsigned int A, vector unsigned int B);
  
!  For each integer value ‘i’ from 0 to 3, do the following.  The integer
! in word element ‘i’ of a is divided by the integer in word element ‘i’
! of b.  The unique integer quotient is placed into the word element ‘i’
  of the vector returned.  If an attempt is made to perform any of the
  divisions  ÷ 0 then the quotient is undefined.
  
*************** vec_div (vector signed long long A, vect
*** 53886,53895 ****
  vector unsigned long long
  vec_div (vector unsigned long long A, vector unsigned long long B);
  
!  For each integer value 'i' from 0 to 1, do the following.  The integer
! in doubleword element 'i' of a is divided by the integer in doubleword
! element 'i' of b.  The unique integer quotient is placed into the
! doubleword element 'i' of the vector returned.  If an attempt is made to
  perform any of the divisions 0x8000_0000_0000_0000 ÷ -1 or  ÷
  0 then the quotient is undefined.
  
--- 53895,53904 ----
  vector unsigned long long
  vec_div (vector unsigned long long A, vector unsigned long long B);
  
!  For each integer value ‘i’ from 0 to 1, do the following.  The integer
! in doubleword element ‘i’ of a is divided by the integer in doubleword
! element ‘i’ of b.  The unique integer quotient is placed into the
! doubleword element ‘i’ of the vector returned.  If an attempt is made to
  perform any of the divisions 0x8000_0000_0000_0000 ÷ -1 or  ÷
  0 then the quotient is undefined.
  
*************** vec_dive (vector signed int A, vector si
*** 53898,53907 ****
  vector unsigned int
  vec_dive (vector unsigned int A, vector unsigned int B);
  
!  For each integer value 'i' from 0 to 3, do the following.  The integer
! in word element 'i' of a is shifted left by 32 bits, then divided by the
! integer in word element 'i' of b.  The unique integer quotient is placed
! into the word element 'i' of the vector returned.  If the quotient
  cannot be represented in 32 bits, or if an attempt is made to perform
  any of the divisions  ÷ 0 then the quotient is undefined.
  
--- 53907,53916 ----
  vector unsigned int
  vec_dive (vector unsigned int A, vector unsigned int B);
  
!  For each integer value ‘i’ from 0 to 3, do the following.  The integer
! in word element ‘i’ of a is shifted left by 32 bits, then divided by the
! integer in word element ‘i’ of b.  The unique integer quotient is placed
! into the word element ‘i’ of the vector returned.  If the quotient
  cannot be represented in 32 bits, or if an attempt is made to perform
  any of the divisions  ÷ 0 then the quotient is undefined.
  
*************** vec_dive (vector signed long long A, vec
*** 53910,53919 ****
  vector unsigned long long
  vec_dive (vector unsigned long long A, vector unsigned long long B);
  
!  For each integer value 'i' from 0 to 1, do the following.  The integer
! in doubleword element 'i' of a is shifted left by 64 bits, then divided
! by the integer in doubleword element 'i' of b.  The unique integer
! quotient is placed into the doubleword element 'i' of the vector
  returned.  If the quotient cannot be represented in 64 bits, or if an
  attempt is made to perform  ÷ 0 then the quotient is
  undefined.
--- 53919,53928 ----
  vector unsigned long long
  vec_dive (vector unsigned long long A, vector unsigned long long B);
  
!  For each integer value ‘i’ from 0 to 1, do the following.  The integer
! in doubleword element ‘i’ of a is shifted left by 64 bits, then divided
! by the integer in doubleword element ‘i’ of b.  The unique integer
! quotient is placed into the doubleword element ‘i’ of the vector
  returned.  If the quotient cannot be represented in 64 bits, or if an
  attempt is made to perform  ÷ 0 then the quotient is
  undefined.
*************** vec_mod (vector signed int A, vector sig
*** 53923,53931 ****
  vector unsigned int
  vec_mod (vector unsigned int A, vector unsigned int B);
  
!  For each integer value 'i' from 0 to 3, do the following.  The integer
! in word element 'i' of a is divided by the integer in word element 'i'
! of b.  The unique integer remainder is placed into the word element 'i'
  of the vector returned.  If an attempt is made to perform any of the
  divisions 0x8000_0000 ÷ -1 or  ÷ 0 then the remainder is
  undefined.
--- 53932,53940 ----
  vector unsigned int
  vec_mod (vector unsigned int A, vector unsigned int B);
  
!  For each integer value ‘i’ from 0 to 3, do the following.  The integer
! in word element ‘i’ of a is divided by the integer in word element ‘i’
! of b.  The unique integer remainder is placed into the word element ‘i’
  of the vector returned.  If an attempt is made to perform any of the
  divisions 0x8000_0000 ÷ -1 or  ÷ 0 then the remainder is
  undefined.
*************** vec_mod (vector signed long long A, vect
*** 53935,53948 ****
  vector unsigned long long
  vec_mod (vector unsigned long long A, vector unsigned long long B);
  
!  For each integer value 'i' from 0 to 1, do the following.  The integer
! in doubleword element 'i' of a is divided by the integer in doubleword
! element 'i' of b.  The unique integer remainder is placed into the
! doubleword element 'i' of the vector returned.  If an attempt is made to
  perform  ÷ 0 then the remainder is undefined.
  
   Generate PCV from specified Mask size, as if implemented by the
! 'xxgenpcvbm', 'xxgenpcvhm', 'xxgenpcvwm' instructions, where immediate
  value is either 0, 1, 2 or 3.
  
  vector unsigned __int128 vec_rl (vector unsigned __int128 A,
--- 53944,53957 ----
  vector unsigned long long
  vec_mod (vector unsigned long long A, vector unsigned long long B);
  
!  For each integer value ‘i’ from 0 to 1, do the following.  The integer
! in doubleword element ‘i’ of a is divided by the integer in doubleword
! element ‘i’ of b.  The unique integer remainder is placed into the
! doubleword element ‘i’ of the vector returned.  If an attempt is made to
  perform  ÷ 0 then the remainder is undefined.
  
   Generate PCV from specified Mask size, as if implemented by the
! ‘xxgenpcvbm’, ‘xxgenpcvhm’, ‘xxgenpcvwm’ instructions, where immediate
  value is either 0, 1, 2 or 3.
  
  vector unsigned __int128 vec_rl (vector unsigned __int128 A,
*************** vector signed __int128 vec_mod (vector s
*** 54046,54058 ****
  second input.
  
   The following builtins perform 128-bit vector comparisons.  The
! 'vec_all_xx', 'vec_any_xx', and 'vec_cmpxx', where 'xx' is one of the
! operations 'eq, ne, gt, lt, ge, le' perform pairwise comparisons between
  the elements at the same positions within their two vector arguments.
! The 'vec_all_xx'function returns a non-zero value if and only if all
! pairwise comparisons are true.  The 'vec_any_xx' function returns a
  non-zero value if and only if at least one pairwise comparison is true.
! The 'vec_cmpxx'function returns a vector of the same type as its two
  arguments, within which each element consists of all ones to denote that
  specified logical comparison of the corresponding elements was true.
  Otherwise, the element of the returned vector contains all zeros.
--- 54055,54067 ----
  second input.
  
   The following builtins perform 128-bit vector comparisons.  The
! ‘vec_all_xx’, ‘vec_any_xx’, and ‘vec_cmpxx’, where ‘xx’ is one of the
! operations ‘eq, ne, gt, lt, ge, le’ perform pairwise comparisons between
  the elements at the same positions within their two vector arguments.
! The ‘vec_all_xx’function returns a non-zero value if and only if all
! pairwise comparisons are true.  The ‘vec_any_xx’ function returns a
  non-zero value if and only if at least one pairwise comparison is true.
! The ‘vec_cmpxx’function returns a vector of the same type as its two
  arguments, within which each element consists of all ones to denote that
  specified logical comparison of the corresponding elements was true.
  Otherwise, the element of the returned vector contains all zeros.
*************** between PowerPC and S/390.
*** 54112,54129 ****
  6.60.24.1 PowerPC HTM Low Level Built-in Functions
  ..................................................
  
! The following low level built-in functions are available with '-mhtm' or
! '-mcpu=CPU' where CPU is 'power8' or later.  They all generate the
  machine instruction that is part of the name.
  
!  The HTM builtins (with the exception of '__builtin_tbegin') return the
  full 4-bit condition register value set by their associated hardware
! instruction.  The header file 'htmintrin.h' defines some macros that can
! be used to decipher the return value.  The '__builtin_tbegin' builtin
! returns a simple 'true' or 'false' value depending on whether a
  transaction was successfully started or not.  The arguments of the
  builtins match exactly the type and order of the associated hardware
! instruction's operands, except for the '__builtin_tcheck' builtin, which
  does not take any input arguments.  Refer to the ISA manual for a
  description of each instruction's operands.
  
--- 54121,54138 ----
  6.60.24.1 PowerPC HTM Low Level Built-in Functions
  ..................................................
  
! The following low level built-in functions are available with ‘-mhtm’ or
! ‘-mcpu=CPU’ where CPU is 'power8' or later.  They all generate the
  machine instruction that is part of the name.
  
!  The HTM builtins (with the exception of ‘__builtin_tbegin’) return the
  full 4-bit condition register value set by their associated hardware
! instruction.  The header file ‘htmintrin.h’ defines some macros that can
! be used to decipher the return value.  The ‘__builtin_tbegin’ builtin
! returns a simple ‘true’ or ‘false’ value depending on whether a
  transaction was successfully started or not.  The arguments of the
  builtins match exactly the type and order of the associated hardware
! instruction's operands, except for the ‘__builtin_tcheck’ builtin, which
  does not take any input arguments.  Refer to the ISA manual for a
  description of each instruction's operands.
  
*************** the builtins in a way that would violate
*** 54166,54172 ****
  accomplished by adding memory barriers to the associated HTM
  instructions (which is a conservative approach to provide acquire and
  release semantics).  Earlier versions of the compiler did not treat the
! HTM instructions as memory barriers.  A '__TM_FENCE__' macro has been
  added, which can be used to determine whether the current compiler
  treats HTM instructions as memory barriers or not.  This allows the user
  to explicitly add memory barriers to their code when using an older
--- 54175,54181 ----
  accomplished by adding memory barriers to the associated HTM
  instructions (which is a conservative approach to provide acquire and
  release semantics).  Earlier versions of the compiler did not treat the
! HTM instructions as memory barriers.  A ‘__TM_FENCE__’ macro has been
  added, which can be used to determine whether the current compiler
  treats HTM instructions as memory barriers or not.  This allows the user
  to explicitly add memory barriers to their code when using an older
*************** the HTM specific special purpose registe
*** 54219,54225 ****
  
   One final built-in function has been added that returns the value of
  the 2-bit Transaction State field of the Machine Status Register (MSR)
! as stored in 'CR0'.
  
       unsigned long __builtin_ttest (void)
  
--- 54228,54234 ----
  
   One final built-in function has been added that returns the value of
  the 2-bit Transaction State field of the Machine Status Register (MSR)
! as stored in ‘CR0’.
  
       unsigned long __builtin_ttest (void)
  
*************** using the following code example:
*** 54247,54253 ****
  .................................................
  
  The following high level HTM interface is made available by including
! '' and using '-mhtm' or '-mcpu=CPU' where CPU is 'power8'
  or later.  This interface is common between PowerPC and S/390, allowing
  users to write one HTM source implementation that can be compiled and
  executed on either system.
--- 54256,54262 ----
  .................................................
  
  The following high level HTM interface is made available by including
! ‘’ and using ‘-mhtm’ or ‘-mcpu=CPU’ where CPU is 'power8'
  or later.  This interface is common between PowerPC and S/390, allowing
  users to write one HTM source implementation that can be compiled and
  executed on either system.
*************** File: gcc.info,  Node: PowerPC Atomic Me
*** 54315,54321 ****
  ISA 3.0 of the PowerPC added new atomic memory operation (amo)
  instructions.  GCC provides support for these instructions in 64-bit
  environments.  All of the functions are declared in the include file
! 'amo.h'.
  
   The functions supported are:
  
--- 54324,54330 ----
  ISA 3.0 of the PowerPC added new atomic memory operation (amo)
  instructions.  GCC provides support for these instructions in 64-bit
  environments.  All of the functions are declared in the include file
! ‘amo.h’.
  
   The functions supported are:
  
*************** File: gcc.info,  Node: PowerPC Matrix-Mu
*** 54377,54383 ****
  
  ISA 3.1 of the PowerPC added new Matrix-Multiply Assist (MMA)
  instructions.  GCC provides support for these instructions through the
! following built-in functions which are enabled with the '-mmma' option.
  The vec_t type below is defined to be a normal vector unsigned char
  type.  The uint2, uint4 and uint8 parameters are 2-bit, 4-bit and 8-bit
  unsigned integer constants respectively.  The compiler will verify that
--- 54386,54392 ----
  
  ISA 3.1 of the PowerPC added new Matrix-Multiply Assist (MMA)
  instructions.  GCC provides support for these instructions through the
! following built-in functions which are enabled with the ‘-mmma’ option.
  The vec_t type below is defined to be a normal vector unsigned char
  type.  The uint2, uint4 and uint8 parameters are 2-bit, 4-bit and 8-bit
  unsigned integer constants respectively.  The compiler will verify that
*************** These built-in functions are available f
*** 54507,54517 ****
  processors.
  
   -- Built-in Function: void * __builtin_thread_pointer (void)
!      Returns the value that is currently set in the 'tp' register.
  
   -- Built-in Function: void __builtin_riscv_pause (void)
!      Generates the 'pause' (hint) machine instruction.  This implies the
!      Xgnuzihintpausestate extension, which redefines the 'pause'
       instruction to change architectural state.
  
  
--- 54516,54526 ----
  processors.
  
   -- Built-in Function: void * __builtin_thread_pointer (void)
!      Returns the value that is currently set in the ‘tp’ register.
  
   -- Built-in Function: void __builtin_riscv_pause (void)
!      Generates the ‘pause’ (hint) machine instruction.  This implies the
!      Xgnuzihintpausestate extension, which redefines the ‘pause’
       instruction to change architectural state.
  
  
*************** GCC supports vector intrinsics as specif
*** 54524,54530 ****
  RISC-V vector intrinsic specification, which is available at the
  following link:
  .  All
! of these functions are declared in the include file 'riscv_vector.h'.
  
  
  File: gcc.info,  Node: RX Built-in Functions,  Next: S/390 System z Built-in Functions,  Prev: RISC-V Vector Intrinsics,  Up: Target Builtins
--- 54533,54539 ----
  RISC-V vector intrinsic specification, which is available at the
  following link:
  .  All
! of these functions are declared in the include file ‘riscv_vector.h’.
  
  
  File: gcc.info,  Node: RX Built-in Functions,  Next: S/390 System z Built-in Functions,  Prev: RISC-V Vector Intrinsics,  Up: Target Builtins
*************** the C programming language via the use o
*** 54537,54628 ****
  following functions are supported:
  
   -- Built-in Function: void __builtin_rx_brk (void)
!      Generates the 'brk' machine instruction.
  
   -- Built-in Function: void __builtin_rx_clrpsw (int)
!      Generates the 'clrpsw' machine instruction to clear the specified
       bit in the processor status word.
  
   -- Built-in Function: void __builtin_rx_int (int)
!      Generates the 'int' machine instruction to generate an interrupt
       with the specified value.
  
   -- Built-in Function: void __builtin_rx_machi (int, int)
!      Generates the 'machi' machine instruction to add the result of
       multiplying the top 16 bits of the two arguments into the
       accumulator.
  
   -- Built-in Function: void __builtin_rx_maclo (int, int)
!      Generates the 'maclo' machine instruction to add the result of
       multiplying the bottom 16 bits of the two arguments into the
       accumulator.
  
   -- Built-in Function: void __builtin_rx_mulhi (int, int)
!      Generates the 'mulhi' machine instruction to place the result of
       multiplying the top 16 bits of the two arguments into the
       accumulator.
  
   -- Built-in Function: void __builtin_rx_mullo (int, int)
!      Generates the 'mullo' machine instruction to place the result of
       multiplying the bottom 16 bits of the two arguments into the
       accumulator.
  
   -- Built-in Function: int __builtin_rx_mvfachi (void)
!      Generates the 'mvfachi' machine instruction to read the top 32 bits
       of the accumulator.
  
   -- Built-in Function: int __builtin_rx_mvfacmi (void)
!      Generates the 'mvfacmi' machine instruction to read the middle 32
       bits of the accumulator.
  
   -- Built-in Function: int __builtin_rx_mvfc (int)
!      Generates the 'mvfc' machine instruction which reads the control
       register specified in its argument and returns its value.
  
   -- Built-in Function: void __builtin_rx_mvtachi (int)
!      Generates the 'mvtachi' machine instruction to set the top 32 bits
       of the accumulator.
  
   -- Built-in Function: void __builtin_rx_mvtaclo (int)
!      Generates the 'mvtaclo' machine instruction to set the bottom 32
       bits of the accumulator.
  
   -- Built-in Function: void __builtin_rx_mvtc (int REG, int VAL)
!      Generates the 'mvtc' machine instruction which sets control
!      register number 'reg' to 'val'.
  
   -- Built-in Function: void __builtin_rx_mvtipl (int)
!      Generates the 'mvtipl' machine instruction set the interrupt
       priority level.
  
   -- Built-in Function: void __builtin_rx_racw (int)
!      Generates the 'racw' machine instruction to round the accumulator
       according to the specified mode.
  
   -- Built-in Function: int __builtin_rx_revw (int)
!      Generates the 'revw' machine instruction which swaps the bytes in
       the argument so that bits 0-7 now occupy bits 8-15 and vice versa,
       and also bits 16-23 occupy bits 24-31 and vice versa.
  
   -- Built-in Function: void __builtin_rx_rmpa (void)
!      Generates the 'rmpa' machine instruction which initiates a repeated
       multiply and accumulate sequence.
  
   -- Built-in Function: void __builtin_rx_round (float)
!      Generates the 'round' machine instruction which returns the
       floating-point argument rounded according to the current rounding
       mode set in the floating-point status word register.
  
   -- Built-in Function: int __builtin_rx_sat (int)
!      Generates the 'sat' machine instruction which returns the saturated
       value of the argument.
  
   -- Built-in Function: void __builtin_rx_setpsw (int)
!      Generates the 'setpsw' machine instruction to set the specified bit
       in the processor status word.
  
   -- Built-in Function: void __builtin_rx_wait (void)
!      Generates the 'wait' machine instruction.
  
  
  File: gcc.info,  Node: S/390 System z Built-in Functions,  Next: SH Built-in Functions,  Prev: RX Built-in Functions,  Up: Target Builtins
--- 54546,54637 ----
  following functions are supported:
  
   -- Built-in Function: void __builtin_rx_brk (void)
!      Generates the ‘brk’ machine instruction.
  
   -- Built-in Function: void __builtin_rx_clrpsw (int)
!      Generates the ‘clrpsw’ machine instruction to clear the specified
       bit in the processor status word.
  
   -- Built-in Function: void __builtin_rx_int (int)
!      Generates the ‘int’ machine instruction to generate an interrupt
       with the specified value.
  
   -- Built-in Function: void __builtin_rx_machi (int, int)
!      Generates the ‘machi’ machine instruction to add the result of
       multiplying the top 16 bits of the two arguments into the
       accumulator.
  
   -- Built-in Function: void __builtin_rx_maclo (int, int)
!      Generates the ‘maclo’ machine instruction to add the result of
       multiplying the bottom 16 bits of the two arguments into the
       accumulator.
  
   -- Built-in Function: void __builtin_rx_mulhi (int, int)
!      Generates the ‘mulhi’ machine instruction to place the result of
       multiplying the top 16 bits of the two arguments into the
       accumulator.
  
   -- Built-in Function: void __builtin_rx_mullo (int, int)
!      Generates the ‘mullo’ machine instruction to place the result of
       multiplying the bottom 16 bits of the two arguments into the
       accumulator.
  
   -- Built-in Function: int __builtin_rx_mvfachi (void)
!      Generates the ‘mvfachi’ machine instruction to read the top 32 bits
       of the accumulator.
  
   -- Built-in Function: int __builtin_rx_mvfacmi (void)
!      Generates the ‘mvfacmi’ machine instruction to read the middle 32
       bits of the accumulator.
  
   -- Built-in Function: int __builtin_rx_mvfc (int)
!      Generates the ‘mvfc’ machine instruction which reads the control
       register specified in its argument and returns its value.
  
   -- Built-in Function: void __builtin_rx_mvtachi (int)
!      Generates the ‘mvtachi’ machine instruction to set the top 32 bits
       of the accumulator.
  
   -- Built-in Function: void __builtin_rx_mvtaclo (int)
!      Generates the ‘mvtaclo’ machine instruction to set the bottom 32
       bits of the accumulator.
  
   -- Built-in Function: void __builtin_rx_mvtc (int REG, int VAL)
!      Generates the ‘mvtc’ machine instruction which sets control
!      register number ‘reg’ to ‘val’.
  
   -- Built-in Function: void __builtin_rx_mvtipl (int)
!      Generates the ‘mvtipl’ machine instruction set the interrupt
       priority level.
  
   -- Built-in Function: void __builtin_rx_racw (int)
!      Generates the ‘racw’ machine instruction to round the accumulator
       according to the specified mode.
  
   -- Built-in Function: int __builtin_rx_revw (int)
!      Generates the ‘revw’ machine instruction which swaps the bytes in
       the argument so that bits 0-7 now occupy bits 8-15 and vice versa,
       and also bits 16-23 occupy bits 24-31 and vice versa.
  
   -- Built-in Function: void __builtin_rx_rmpa (void)
!      Generates the ‘rmpa’ machine instruction which initiates a repeated
       multiply and accumulate sequence.
  
   -- Built-in Function: void __builtin_rx_round (float)
!      Generates the ‘round’ machine instruction which returns the
       floating-point argument rounded according to the current rounding
       mode set in the floating-point status word register.
  
   -- Built-in Function: int __builtin_rx_sat (int)
!      Generates the ‘sat’ machine instruction which returns the saturated
       value of the argument.
  
   -- Built-in Function: void __builtin_rx_setpsw (int)
!      Generates the ‘setpsw’ machine instruction to set the specified bit
       in the processor status word.
  
   -- Built-in Function: void __builtin_rx_wait (void)
!      Generates the ‘wait’ machine instruction.
  
  
  File: gcc.info,  Node: S/390 System z Built-in Functions,  Next: SH Built-in Functions,  Prev: RX Built-in Functions,  Up: Target Builtins
*************** File: gcc.info,  Node: S/390 System z Bu
*** 54631,54649 ****
  -----------------------------------------
  
   -- Built-in Function: int __builtin_tbegin (void*)
!      Generates the 'tbegin' machine instruction starting a
       non-constrained hardware transaction.  If the parameter is non-NULL
       the memory area is used to store the transaction diagnostic buffer
!      and will be passed as first operand to 'tbegin'.  This buffer can
!      be defined using the 'struct __htm_tdb' C struct defined in
!      'htmintrin.h' and must reside on a double-word boundary.  The
!      second tbegin operand is set to '0xff0c'.  This enables
       save/restore of all GPRs and disables aborts for FPR and AR
       manipulations inside the transaction body.  The condition code set
       by the tbegin instruction is returned as integer value.  The tbegin
       instruction by definition overwrites the content of all FPRs.  The
       compiler will generate code which saves and restores the FPRs.  For
!      soft-float code it is recommended to used the '*_nofloat' variant.
       In order to prevent a TDB from being written it is required to pass
       a constant zero value as parameter.  Passing a zero value through a
       variable is not sufficient.  Although modifications of access
--- 54640,54658 ----
  -----------------------------------------
  
   -- Built-in Function: int __builtin_tbegin (void*)
!      Generates the ‘tbegin’ machine instruction starting a
       non-constrained hardware transaction.  If the parameter is non-NULL
       the memory area is used to store the transaction diagnostic buffer
!      and will be passed as first operand to ‘tbegin’.  This buffer can
!      be defined using the ‘struct __htm_tdb’ C struct defined in
!      ‘htmintrin.h’ and must reside on a double-word boundary.  The
!      second tbegin operand is set to ‘0xff0c’.  This enables
       save/restore of all GPRs and disables aborts for FPR and AR
       manipulations inside the transaction body.  The condition code set
       by the tbegin instruction is returned as integer value.  The tbegin
       instruction by definition overwrites the content of all FPRs.  The
       compiler will generate code which saves and restores the FPRs.  For
!      soft-float code it is recommended to used the ‘*_nofloat’ variant.
       In order to prevent a TDB from being written it is required to pass
       a constant zero value as parameter.  Passing a zero value through a
       variable is not sufficient.  Although modifications of access
*************** File: gcc.info,  Node: S/390 System z Bu
*** 54653,54662 ****
       have undefined state when reaching the abort code.
  
   Macros for the possible return codes of tbegin are defined in the
! 'htmintrin.h' header file:
  
   -- Macro: _HTM_TBEGIN_STARTED
!      'tbegin' has been executed as part of normal processing.  The
       transaction body is supposed to be executed.
  
   -- Macro: _HTM_TBEGIN_INDETERMINATE
--- 54662,54671 ----
       have undefined state when reaching the abort code.
  
   Macros for the possible return codes of tbegin are defined in the
! ‘htmintrin.h’ header file:
  
   -- Macro: _HTM_TBEGIN_STARTED
!      ‘tbegin’ has been executed as part of normal processing.  The
       transaction body is supposed to be executed.
  
   -- Macro: _HTM_TBEGIN_INDETERMINATE
*************** File: gcc.info,  Node: S/390 System z Bu
*** 54672,54734 ****
       under same circumstances will not be productive.
  
   -- Macro: _HTM_FIRST_USER_ABORT_CODE
!      The '_HTM_FIRST_USER_ABORT_CODE' defined in 'htmintrin.h' specifies
!      the first abort code which can be used for '__builtin_tabort'.
       Values below this threshold are reserved for machine use.
  
   -- Data type: struct __htm_tdb
!      The 'struct __htm_tdb' defined in 'htmintrin.h' describes the
       structure of the transaction diagnostic block as specified in the
       Principles of Operation manual chapter 5-91.
  
   -- Built-in Function: int __builtin_tbegin_nofloat (void*)
!      Same as '__builtin_tbegin' but without FPR saves and restores.
       Using this variant in code making use of FPRs will leave the FPRs
       in undefined state when entering the transaction abort handler
       code.
  
   -- Built-in Function: int __builtin_tbegin_retry (void*, int)
!      In addition to '__builtin_tbegin' a loop for transient failures is
       generated.  If tbegin returns a condition code of 2 the transaction
       will be retried as often as specified in the second argument.  The
       perform processor assist instruction is used to tell the CPU about
       the number of fails so far.
  
   -- Built-in Function: int __builtin_tbegin_retry_nofloat (void*, int)
!      Same as '__builtin_tbegin_retry' but without FPR saves and
       restores.  Using this variant in code making use of FPRs will leave
       the FPRs in undefined state when entering the transaction abort
       handler code.
  
   -- Built-in Function: void __builtin_tbeginc (void)
!      Generates the 'tbeginc' machine instruction starting a constrained
!      hardware transaction.  The second operand is set to '0xff08'.
  
   -- Built-in Function: int __builtin_tend (void)
!      Generates the 'tend' machine instruction finishing a transaction
       and making the changes visible to other threads.  The condition
       code generated by tend is returned as integer value.
  
   -- Built-in Function: void __builtin_tabort (int)
!      Generates the 'tabort' machine instruction with the specified abort
       code.  Abort codes from 0 through 255 are reserved and will result
       in an error message.
  
   -- Built-in Function: void __builtin_tx_assist (int)
!      Generates the 'ppa rX,rY,1' machine instruction.  Where the integer
       parameter is loaded into rX and a value of zero is loaded into rY.
       The integer parameter specifies the number of times the transaction
       repeatedly aborted.
  
   -- Built-in Function: int __builtin_tx_nesting_depth (void)
!      Generates the 'etnd' machine instruction.  The current nesting
       depth is returned as integer value.  For a nesting depth of 0 the
       code is not executed as part of an transaction.
  
   -- Built-in Function: void __builtin_non_tx_store (uint64_t *,
            uint64_t)
  
!      Generates the 'ntstg' machine instruction.  The second argument is
       written to the first arguments location.  The store operation will
       not be rolled-back in case of an transaction abort.
  
--- 54681,54743 ----
       under same circumstances will not be productive.
  
   -- Macro: _HTM_FIRST_USER_ABORT_CODE
!      The ‘_HTM_FIRST_USER_ABORT_CODE’ defined in ‘htmintrin.h’ specifies
!      the first abort code which can be used for ‘__builtin_tabort’.
       Values below this threshold are reserved for machine use.
  
   -- Data type: struct __htm_tdb
!      The ‘struct __htm_tdb’ defined in ‘htmintrin.h’ describes the
       structure of the transaction diagnostic block as specified in the
       Principles of Operation manual chapter 5-91.
  
   -- Built-in Function: int __builtin_tbegin_nofloat (void*)
!      Same as ‘__builtin_tbegin’ but without FPR saves and restores.
       Using this variant in code making use of FPRs will leave the FPRs
       in undefined state when entering the transaction abort handler
       code.
  
   -- Built-in Function: int __builtin_tbegin_retry (void*, int)
!      In addition to ‘__builtin_tbegin’ a loop for transient failures is
       generated.  If tbegin returns a condition code of 2 the transaction
       will be retried as often as specified in the second argument.  The
       perform processor assist instruction is used to tell the CPU about
       the number of fails so far.
  
   -- Built-in Function: int __builtin_tbegin_retry_nofloat (void*, int)
!      Same as ‘__builtin_tbegin_retry’ but without FPR saves and
       restores.  Using this variant in code making use of FPRs will leave
       the FPRs in undefined state when entering the transaction abort
       handler code.
  
   -- Built-in Function: void __builtin_tbeginc (void)
!      Generates the ‘tbeginc’ machine instruction starting a constrained
!      hardware transaction.  The second operand is set to ‘0xff08’.
  
   -- Built-in Function: int __builtin_tend (void)
!      Generates the ‘tend’ machine instruction finishing a transaction
       and making the changes visible to other threads.  The condition
       code generated by tend is returned as integer value.
  
   -- Built-in Function: void __builtin_tabort (int)
!      Generates the ‘tabort’ machine instruction with the specified abort
       code.  Abort codes from 0 through 255 are reserved and will result
       in an error message.
  
   -- Built-in Function: void __builtin_tx_assist (int)
!      Generates the ‘ppa rX,rY,1’ machine instruction.  Where the integer
       parameter is loaded into rX and a value of zero is loaded into rY.
       The integer parameter specifies the number of times the transaction
       repeatedly aborted.
  
   -- Built-in Function: int __builtin_tx_nesting_depth (void)
!      Generates the ‘etnd’ machine instruction.  The current nesting
       depth is returned as integer value.  For a nesting depth of 0 the
       code is not executed as part of an transaction.
  
   -- Built-in Function: void __builtin_non_tx_store (uint64_t *,
            uint64_t)
  
!      Generates the ‘ntstg’ machine instruction.  The second argument is
       written to the first arguments location.  The store operation will
       not be rolled-back in case of an transaction abort.
  
*************** The following built-in functions are sup
*** 54742,54759 ****
  SH4 families of processors:
  
   -- Built-in Function: void __builtin_set_thread_pointer (void *PTR)
!      Sets the 'GBR' register to the specified value PTR.  This is
       usually used by system code that manages threads and execution
       contexts.  The compiler normally does not generate code that
!      modifies the contents of 'GBR' and thus the value is preserved
!      across function calls.  Changing the 'GBR' value in user code must
!      be done with caution, since the compiler might use 'GBR' in order
       to access thread local variables.
  
   -- Built-in Function: void * __builtin_thread_pointer (void)
!      Returns the value that is currently set in the 'GBR' register.
       Memory loads and stores that use the thread pointer as a base
!      address are turned into 'GBR' based displacement loads and stores,
       if possible.  For example:
            struct my_tcb
            {
--- 54751,54768 ----
  SH4 families of processors:
  
   -- Built-in Function: void __builtin_set_thread_pointer (void *PTR)
!      Sets the ‘GBR’ register to the specified value PTR.  This is
       usually used by system code that manages threads and execution
       contexts.  The compiler normally does not generate code that
!      modifies the contents of ‘GBR’ and thus the value is preserved
!      across function calls.  Changing the ‘GBR’ value in user code must
!      be done with caution, since the compiler might use ‘GBR’ in order
       to access thread local variables.
  
   -- Built-in Function: void * __builtin_thread_pointer (void)
!      Returns the value that is currently set in the ‘GBR’ register.
       Memory loads and stores that use the thread pointer as a base
!      address are turned into ‘GBR’ based displacement loads and stores,
       if possible.  For example:
            struct my_tcb
            {
*************** SH4 families of processors:
*** 54762,54777 ****
  
            int get_tcb_value (void)
            {
!             // Generate 'mov.l @(8,gbr),r0' instruction
              return ((my_tcb*)__builtin_thread_pointer ())->c;
            }
  
  
   -- Built-in Function: unsigned int __builtin_sh_get_fpscr (void)
!      Returns the value that is currently set in the 'FPSCR' register.
  
   -- Built-in Function: void __builtin_sh_set_fpscr (unsigned int VAL)
!      Sets the 'FPSCR' register to the specified value VAL, while
       preserving the current values of the FR, SZ and PR bits.
  
  
--- 54771,54786 ----
  
            int get_tcb_value (void)
            {
!             // Generate ‘mov.l @(8,gbr),r0’ instruction
              return ((my_tcb*)__builtin_thread_pointer ())->c;
            }
  
  
   -- Built-in Function: unsigned int __builtin_sh_get_fpscr (void)
!      Returns the value that is currently set in the ‘FPSCR’ register.
  
   -- Built-in Function: void __builtin_sh_set_fpscr (unsigned int VAL)
!      Sets the ‘FPSCR’ register to the specified value VAL, while
       preserving the current values of the FR, SZ and PR bits.
  
  
*************** File: gcc.info,  Node: SPARC VIS Built-i
*** 54782,54788 ****
  
  GCC supports SIMD operations on the SPARC using both the generic vector
  extensions (*note Vector Extensions::) as well as built-in functions for
! the SPARC Visual Instruction Set (VIS). When you use the '-mvis' switch,
  the VIS extension is exposed as the following built-in functions:
  
       typedef int v1si __attribute__ ((vector_size (4)));
--- 54791,54797 ----
  
  GCC supports SIMD operations on the SPARC using both the generic vector
  extensions (*note Vector Extensions::) as well as built-in functions for
! the SPARC Visual Instruction Set (VIS). When you use the ‘-mvis’ switch,
  the VIS extension is exposed as the following built-in functions:
  
       typedef int v1si __attribute__ ((vector_size (4)));
*************** the VIS extension is exposed as the foll
*** 54848,54854 ****
       long __builtin_vis_array16 (long, long);
       long __builtin_vis_array32 (long, long);
  
!  When you use the '-mvis2' switch, the VIS version 2.0 built-in
  functions also become available:
  
       long __builtin_vis_bmask (long, long);
--- 54857,54863 ----
       long __builtin_vis_array16 (long, long);
       long __builtin_vis_array32 (long, long);
  
!  When you use the ‘-mvis2’ switch, the VIS version 2.0 built-in
  functions also become available:
  
       long __builtin_vis_bmask (long, long);
*************** functions also become available:
*** 54864,54870 ****
       long __builtin_vis_edge32n (void *, void *);
       long __builtin_vis_edge32ln (void *, void *);
  
!  When you use the '-mvis3' switch, the VIS version 3.0 built-in
  functions also become available:
  
       void __builtin_vis_cmask8 (long);
--- 54873,54879 ----
       long __builtin_vis_edge32n (void *, void *);
       long __builtin_vis_edge32ln (void *, void *);
  
!  When you use the ‘-mvis3’ switch, the VIS version 3.0 built-in
  functions also become available:
  
       void __builtin_vis_cmask8 (long);
*************** functions also become available:
*** 54914,54920 ****
       int64_t __builtin_vis_xmulx (int64_t, int64_t);
       int64_t __builtin_vis_xmulxhi (int64_t, int64_t);
  
!  When you use the '-mvis4' switch, the VIS version 4.0 built-in
  functions also become available:
  
       v8qi __builtin_vis_fpadd8 (v8qi, v8qi);
--- 54923,54929 ----
       int64_t __builtin_vis_xmulx (int64_t, int64_t);
       int64_t __builtin_vis_xmulxhi (int64_t, int64_t);
  
!  When you use the ‘-mvis4’ switch, the VIS version 4.0 built-in
  functions also become available:
  
       v8qi __builtin_vis_fpadd8 (v8qi, v8qi);
*************** functions also become available:
*** 54950,54956 ****
       v4hi __builtin_vis_fpminu16 (v4hi, v4hi);
       v2si __builtin_vis_fpminu32 (v2si, v2si);
  
!  When you use the '-mvis4b' switch, the VIS version 4.0B built-in
  functions also become available:
  
       v8qi __builtin_vis_dictunpack8 (double, int);
--- 54959,54965 ----
       v4hi __builtin_vis_fpminu16 (v4hi, v4hi);
       v2si __builtin_vis_fpminu32 (v2si, v2si);
  
!  When you use the ‘-mvis4b’ switch, the VIS version 4.0B built-in
  functions also become available:
  
       v8qi __builtin_vis_dictunpack8 (double, int);
*************** File: gcc.info,  Node: TI C6X Built-in F
*** 54995,55001 ****
  
  GCC provides intrinsics to access certain instructions of the TI C6X
  processors.  These intrinsics, listed below, are available after
! inclusion of the 'c6x_intrinsics.h' header file.  They map directly to
  C6X instructions.
  
       int _sadd (int, int);
--- 55004,55010 ----
  
  GCC provides intrinsics to access certain instructions of the TI C6X
  processors.  These intrinsics, listed below, are available after
! inclusion of the ‘c6x_intrinsics.h’ header file.  They map directly to
  C6X instructions.
  
       int _sadd (int, int);
*************** File: gcc.info,  Node: x86 Built-in Func
*** 55034,55040 ****
  These built-in functions are available for the x86-32 and x86-64 family
  of computers, depending on the command-line switches used.
  
!  If you specify command-line switches such as '-msse', the compiler
  could use the extended instruction sets even if the built-ins are not
  used explicitly in the program.  For this reason, applications that
  perform run-time CPU detection must compile separate files for each
--- 55043,55049 ----
  These built-in functions are available for the x86-32 and x86-64 family
  of computers, depending on the command-line switches used.
  
!  If you specify command-line switches such as ‘-msse’, the compiler
  could use the extended instruction sets even if the built-ins are not
  used explicitly in the program.  For this reason, applications that
  perform run-time CPU detection must compile separate files for each
*************** file containing the CPU detection code s
*** 55043,55066 ****
  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'.
  
   The x86-32 and x86-64 family of processors use 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 always available:
  
--- 55052,55075 ----
  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’.
  
   The x86-32 and x86-64 family of processors use 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 always available:
  
*************** point and 'TC' 128-bit complex floating-
*** 55072,55094 ****
       Copies the sign of Y into X and returns the new value of X.
  
   -- Built-in Function: __float128 __builtin_infq (void)
!      Similar to '__builtin_inf', except the return type is '__float128'.
  
   -- Built-in Function: __float128 __builtin_huge_valq (void)
!      Similar to '__builtin_huge_val', except the return type is
!      '__float128'.
  
   -- Built-in Function: __float128 __builtin_nanq (void)
!      Similar to '__builtin_nan', except the return type is '__float128'.
  
   -- Built-in Function: __float128 __builtin_nansq (void)
!      Similar to '__builtin_nans', except the return type is
!      '__float128'.
  
   The following built-in function is always available.
  
   -- Built-in Function: void __builtin_ia32_pause (void)
!      Generates the 'pause' machine instruction with a compiler memory
       barrier.
  
   The following built-in functions are always available and can be used
--- 55081,55103 ----
       Copies the sign of Y into X and returns the new value of X.
  
   -- Built-in Function: __float128 __builtin_infq (void)
!      Similar to ‘__builtin_inf’, except the return type is ‘__float128’.
  
   -- Built-in Function: __float128 __builtin_huge_valq (void)
!      Similar to ‘__builtin_huge_val’, except the return type is
!      ‘__float128’.
  
   -- Built-in Function: __float128 __builtin_nanq (void)
!      Similar to ‘__builtin_nan’, except the return type is ‘__float128’.
  
   -- Built-in Function: __float128 __builtin_nansq (void)
!      Similar to ‘__builtin_nans’, except the return type is
!      ‘__float128’.
  
   The following built-in function is always available.
  
   -- Built-in Function: void __builtin_ia32_pause (void)
!      Generates the ‘pause’ machine instruction with a compiler memory
       barrier.
  
   The following built-in functions are always available and can be used
*************** to check the target platform type.
*** 55098,55111 ****
       This function runs the CPU detection code to check the type of CPU
       and the features supported.  This built-in function needs to be
       invoked along with the built-in functions to check CPU type and
!      features, '__builtin_cpu_is' and '__builtin_cpu_supports', only
       when used in a function that is executed before any constructors
       are called.  The CPU detection code is automatically executed in a
       very high priority constructor.
  
!      For example, this function has to be used in 'ifunc' resolvers that
!      check for CPU type using the built-in functions '__builtin_cpu_is'
!      and '__builtin_cpu_supports', or in constructors on targets that
       don't support constructor priority.
  
            static void (*resolve_memcpy (void)) (void)
--- 55107,55120 ----
       This function runs the CPU detection code to check the type of CPU
       and the features supported.  This built-in function needs to be
       invoked along with the built-in functions to check CPU type and
!      features, ‘__builtin_cpu_is’ and ‘__builtin_cpu_supports’, only
       when used in a function that is executed before any constructors
       are called.  The CPU detection code is automatically executed in a
       very high priority constructor.
  
!      For example, this function has to be used in ‘ifunc’ resolvers that
!      check for CPU type using the built-in functions ‘__builtin_cpu_is’
!      and ‘__builtin_cpu_supports’, or in constructors on targets that
       don't support constructor priority.
  
            static void (*resolve_memcpy (void)) (void)
*************** to check the target platform type.
*** 55124,55289 ****
  
   -- Built-in Function: int __builtin_cpu_is (const char *CPUNAME)
       This function returns a positive integer if the run-time CPU is of
!      type CPUNAME and returns '0' otherwise.  The following CPU names
       can be detected:
  
!      'amd'
            AMD CPU.
  
!      'intel'
            Intel CPU.
  
!      'atom'
            Intel Atom CPU.
  
!      'slm'
            Intel Silvermont CPU.
  
!      'core2'
            Intel Core 2 CPU.
  
!      'corei7'
            Intel Core i7 CPU.
  
!      'nehalem'
            Intel Core i7 Nehalem CPU.
  
!      'westmere'
            Intel Core i7 Westmere CPU.
  
!      'sandybridge'
            Intel Core i7 Sandy Bridge CPU.
  
!      'ivybridge'
            Intel Core i7 Ivy Bridge CPU.
  
!      'haswell'
            Intel Core i7 Haswell CPU.
  
!      'broadwell'
            Intel Core i7 Broadwell CPU.
  
!      'skylake'
            Intel Core i7 Skylake CPU.
  
!      'skylake-avx512'
            Intel Core i7 Skylake AVX512 CPU.
  
!      'cannonlake'
            Intel Core i7 Cannon Lake CPU.
  
!      'icelake-client'
            Intel Core i7 Ice Lake Client CPU.
  
!      'icelake-server'
            Intel Core i7 Ice Lake Server CPU.
  
!      'cascadelake'
            Intel Core i7 Cascadelake CPU.
  
!      'tigerlake'
            Intel Core i7 Tigerlake CPU.
  
!      'cooperlake'
            Intel Core i7 Cooperlake CPU.
  
!      'sapphirerapids'
            Intel Core i7 sapphirerapids CPU.
  
!      'alderlake'
            Intel Core i7 Alderlake CPU.
  
!      'rocketlake'
            Intel Core i7 Rocketlake CPU.
  
!      'graniterapids'
            Intel Core i7 graniterapids CPU.
  
!      'graniterapids-d'
            Intel Core i7 graniterapids D CPU.
  
!      'bonnell'
            Intel Atom Bonnell CPU.
  
!      'silvermont'
            Intel Atom Silvermont CPU.
  
!      'goldmont'
            Intel Atom Goldmont CPU.
  
!      'goldmont-plus'
            Intel Atom Goldmont Plus CPU.
  
!      'tremont'
            Intel Atom Tremont CPU.
  
!      'sierraforest'
            Intel Atom Sierra Forest CPU.
  
!      'grandridge'
            Intel Atom Grand Ridge CPU.
  
!      'knl'
            Intel Knights Landing CPU.
  
!      'knm'
            Intel Knights Mill CPU.
  
!      'lujiazui'
            ZHAOXIN lujiazui CPU.
  
!      'amdfam10h'
            AMD Family 10h CPU.
  
!      'barcelona'
            AMD Family 10h Barcelona CPU.
  
!      'shanghai'
            AMD Family 10h Shanghai CPU.
  
!      'istanbul'
            AMD Family 10h Istanbul CPU.
  
!      'btver1'
            AMD Family 14h CPU.
  
!      'amdfam15h'
            AMD Family 15h CPU.
  
!      'bdver1'
            AMD Family 15h Bulldozer version 1.
  
!      'bdver2'
            AMD Family 15h Bulldozer version 2.
  
!      'bdver3'
            AMD Family 15h Bulldozer version 3.
  
!      'bdver4'
            AMD Family 15h Bulldozer version 4.
  
!      'btver2'
            AMD Family 16h CPU.
  
!      'amdfam17h'
            AMD Family 17h CPU.
  
!      'znver1'
            AMD Family 17h Zen version 1.
  
!      'znver2'
            AMD Family 17h Zen version 2.
  
!      'amdfam19h'
            AMD Family 19h CPU.
  
!      'znver3'
            AMD Family 19h Zen version 3.
  
!      'znver4'
            AMD Family 19h Zen version 4.
  
!      'znver5'
            AMD Family 1ah Zen version 5.
  
       Here is an example:
--- 55133,55298 ----
  
   -- Built-in Function: int __builtin_cpu_is (const char *CPUNAME)
       This function returns a positive integer if the run-time CPU is of
!      type CPUNAME and returns ‘0’ otherwise.  The following CPU names
       can be detected:
  
!      ‘amd’
            AMD CPU.
  
!      ‘intel’
            Intel CPU.
  
!      ‘atom’
            Intel Atom CPU.
  
!      ‘slm’
            Intel Silvermont CPU.
  
!      ‘core2’
            Intel Core 2 CPU.
  
!      ‘corei7’
            Intel Core i7 CPU.
  
!      ‘nehalem’
            Intel Core i7 Nehalem CPU.
  
!      ‘westmere’
            Intel Core i7 Westmere CPU.
  
!      ‘sandybridge’
            Intel Core i7 Sandy Bridge CPU.
  
!      ‘ivybridge’
            Intel Core i7 Ivy Bridge CPU.
  
!      ‘haswell’
            Intel Core i7 Haswell CPU.
  
!      ‘broadwell’
            Intel Core i7 Broadwell CPU.
  
!      ‘skylake’
            Intel Core i7 Skylake CPU.
  
!      ‘skylake-avx512’
            Intel Core i7 Skylake AVX512 CPU.
  
!      ‘cannonlake’
            Intel Core i7 Cannon Lake CPU.
  
!      ‘icelake-client’
            Intel Core i7 Ice Lake Client CPU.
  
!      ‘icelake-server’
            Intel Core i7 Ice Lake Server CPU.
  
!      ‘cascadelake’
            Intel Core i7 Cascadelake CPU.
  
!      ‘tigerlake’
            Intel Core i7 Tigerlake CPU.
  
!      ‘cooperlake’
            Intel Core i7 Cooperlake CPU.
  
!      ‘sapphirerapids’
            Intel Core i7 sapphirerapids CPU.
  
!      ‘alderlake’
            Intel Core i7 Alderlake CPU.
  
!      ‘rocketlake’
            Intel Core i7 Rocketlake CPU.
  
!      ‘graniterapids’
            Intel Core i7 graniterapids CPU.
  
!      ‘graniterapids-d’
            Intel Core i7 graniterapids D CPU.
  
!      ‘bonnell’
            Intel Atom Bonnell CPU.
  
!      ‘silvermont’
            Intel Atom Silvermont CPU.
  
!      ‘goldmont’
            Intel Atom Goldmont CPU.
  
!      ‘goldmont-plus’
            Intel Atom Goldmont Plus CPU.
  
!      ‘tremont’
            Intel Atom Tremont CPU.
  
!      ‘sierraforest’
            Intel Atom Sierra Forest CPU.
  
!      ‘grandridge’
            Intel Atom Grand Ridge CPU.
  
!      ‘knl’
            Intel Knights Landing CPU.
  
!      ‘knm’
            Intel Knights Mill CPU.
  
!      ‘lujiazui’
            ZHAOXIN lujiazui CPU.
  
!      ‘amdfam10h’
            AMD Family 10h CPU.
  
!      ‘barcelona’
            AMD Family 10h Barcelona CPU.
  
!      ‘shanghai’
            AMD Family 10h Shanghai CPU.
  
!      ‘istanbul’
            AMD Family 10h Istanbul CPU.
  
!      ‘btver1’
            AMD Family 14h CPU.
  
!      ‘amdfam15h’
            AMD Family 15h CPU.
  
!      ‘bdver1’
            AMD Family 15h Bulldozer version 1.
  
!      ‘bdver2’
            AMD Family 15h Bulldozer version 2.
  
!      ‘bdver3’
            AMD Family 15h Bulldozer version 3.
  
!      ‘bdver4’
            AMD Family 15h Bulldozer version 4.
  
!      ‘btver2’
            AMD Family 16h CPU.
  
!      ‘amdfam17h’
            AMD Family 17h CPU.
  
!      ‘znver1’
            AMD Family 17h Zen version 1.
  
!      ‘znver2’
            AMD Family 17h Zen version 2.
  
!      ‘amdfam19h’
            AMD Family 19h CPU.
  
!      ‘znver3’
            AMD Family 19h Zen version 3.
  
!      ‘znver4’
            AMD Family 19h Zen version 4.
  
!      ‘znver5’
            AMD Family 1ah Zen version 5.
  
       Here is an example:
*************** to check the target platform type.
*** 55298,55386 ****
  
   -- Built-in Function: int __builtin_cpu_supports (const char *FEATURE)
       This function returns a positive integer if the run-time CPU
!      supports FEATURE and returns '0' otherwise.  The following features
       can be detected:
  
!      'cmov'
            CMOV instruction.
!      'mmx'
            MMX instructions.
!      'popcnt'
            POPCNT instruction.
!      'sse'
            SSE instructions.
!      'sse2'
            SSE2 instructions.
!      'sse3'
            SSE3 instructions.
!      'ssse3'
            SSSE3 instructions.
!      'sse4.1'
            SSE4.1 instructions.
!      'sse4.2'
            SSE4.2 instructions.
!      'avx'
            AVX instructions.
!      'avx2'
            AVX2 instructions.
!      'sse4a'
            SSE4A instructions.
!      'fma4'
            FMA4 instructions.
!      'xop'
            XOP instructions.
!      'fma'
            FMA instructions.
!      'avx512f'
            AVX512F instructions.
!      'bmi'
            BMI instructions.
!      'bmi2'
            BMI2 instructions.
!      'aes'
            AES instructions.
!      'pclmul'
            PCLMUL instructions.
!      'avx512vl'
            AVX512VL instructions.
!      'avx512bw'
            AVX512BW instructions.
!      'avx512dq'
            AVX512DQ instructions.
!      'avx512cd'
            AVX512CD instructions.
!      'avx512er'
            AVX512ER instructions.
!      'avx512pf'
            AVX512PF instructions.
!      'avx512vbmi'
            AVX512VBMI instructions.
!      'avx512ifma'
            AVX512IFMA instructions.
!      'avx5124vnniw'
            AVX5124VNNIW instructions.
!      'avx5124fmaps'
            AVX5124FMAPS instructions.
!      'avx512vpopcntdq'
            AVX512VPOPCNTDQ instructions.
!      'avx512vbmi2'
            AVX512VBMI2 instructions.
!      'gfni'
            GFNI instructions.
!      'vpclmulqdq'
            VPCLMULQDQ instructions.
!      'avx512vnni'
            AVX512VNNI instructions.
!      'avx512bitalg'
            AVX512BITALG instructions.
!      'x86-64'
            Baseline x86-64 microarchitecture level (as defined in x86-64
            psABI).
!      'x86-64-v2'
            x86-64-v2 microarchitecture level.
!      'x86-64-v3'
            x86-64-v3 microarchitecture level.
!      'x86-64-v4'
            x86-64-v4 microarchitecture level.
  
       Here is an example:
--- 55307,55395 ----
  
   -- Built-in Function: int __builtin_cpu_supports (const char *FEATURE)
       This function returns a positive integer if the run-time CPU
!      supports FEATURE and returns ‘0’ otherwise.  The following features
       can be detected:
  
!      ‘cmov’
            CMOV instruction.
!      ‘mmx’
            MMX instructions.
!      ‘popcnt’
            POPCNT instruction.
!      ‘sse’
            SSE instructions.
!      ‘sse2’
            SSE2 instructions.
!      ‘sse3’
            SSE3 instructions.
!      ‘ssse3’
            SSSE3 instructions.
!      ‘sse4.1’
            SSE4.1 instructions.
!      ‘sse4.2’
            SSE4.2 instructions.
!      ‘avx’
            AVX instructions.
!      ‘avx2’
            AVX2 instructions.
!      ‘sse4a’
            SSE4A instructions.
!      ‘fma4’
            FMA4 instructions.
!      ‘xop’
            XOP instructions.
!      ‘fma’
            FMA instructions.
!      ‘avx512f’
            AVX512F instructions.
!      ‘bmi’
            BMI instructions.
!      ‘bmi2’
            BMI2 instructions.
!      ‘aes’
            AES instructions.
!      ‘pclmul’
            PCLMUL instructions.
!      ‘avx512vl’
            AVX512VL instructions.
!      ‘avx512bw’
            AVX512BW instructions.
!      ‘avx512dq’
            AVX512DQ instructions.
!      ‘avx512cd’
            AVX512CD instructions.
!      ‘avx512er’
            AVX512ER instructions.
!      ‘avx512pf’
            AVX512PF instructions.
!      ‘avx512vbmi’
            AVX512VBMI instructions.
!      ‘avx512ifma’
            AVX512IFMA instructions.
!      ‘avx5124vnniw’
            AVX5124VNNIW instructions.
!      ‘avx5124fmaps’
            AVX5124FMAPS instructions.
!      ‘avx512vpopcntdq’
            AVX512VPOPCNTDQ instructions.
!      ‘avx512vbmi2’
            AVX512VBMI2 instructions.
!      ‘gfni’
            GFNI instructions.
!      ‘vpclmulqdq’
            VPCLMULQDQ instructions.
!      ‘avx512vnni’
            AVX512VNNI instructions.
!      ‘avx512bitalg’
            AVX512BITALG instructions.
!      ‘x86-64’
            Baseline x86-64 microarchitecture level (as defined in x86-64
            psABI).
!      ‘x86-64-v2’
            x86-64-v2 microarchitecture level.
!      ‘x86-64-v3’
            x86-64-v3 microarchitecture level.
!      ‘x86-64-v4’
            x86-64-v4 microarchitecture level.
  
       Here is an example:
*************** to check the target platform type.
*** 55393,55399 ****
                 count = generic_countbits (n); //generic implementation.
              }
  
!  The following built-in functions are made available by '-mmmx'.  All of
  them generate the machine instruction that is part of the name.
  
       v8qi __builtin_ia32_paddb (v8qi, v8qi);
--- 55402,55408 ----
                 count = generic_countbits (n); //generic implementation.
              }
  
!  The following built-in functions are made available by ‘-mmmx’.  All of
  them generate the machine instruction that is part of the name.
  
       v8qi __builtin_ia32_paddb (v8qi, v8qi);
*************** them generate the machine instruction th
*** 55450,55456 ****
       v2si __builtin_ia32_psradi (v2si, int);
  
   The following built-in functions are made available either with
! '-msse', or with '-m3dnowa'.  All of them generate the machine
  instruction that is part of the name.
  
       v4hi __builtin_ia32_pmulhuw (v4hi, v4hi);
--- 55459,55465 ----
       v2si __builtin_ia32_psradi (v2si, int);
  
   The following built-in functions are made available either with
! ‘-msse’, or with ‘-m3dnowa’.  All of them generate the machine
  instruction that is part of the name.
  
       v4hi __builtin_ia32_pmulhuw (v4hi, v4hi);
*************** instruction that is part of the name.
*** 55466,55472 ****
       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);
--- 55475,55481 ----
       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);
*************** All of them generate the machine instruc
*** 55538,55567 ****
       void __builtin_ia32_movntps (float *, v4sf);
       int __builtin_ia32_movmskps (v4sf);
  
!  The following built-in functions are available when '-msse' is used.
  
   -- Built-in Function: v4sf __builtin_ia32_loadups (float *)
!      Generates the 'movups' machine instruction as a load from memory.
  
   -- Built-in Function: void __builtin_ia32_storeups (float *, v4sf)
!      Generates the 'movups' machine instruction as a store to memory.
  
   -- Built-in Function: v4sf __builtin_ia32_loadss (float *)
!      Generates the 'movss' machine instruction as a load from memory.
  
   -- Built-in Function: v4sf __builtin_ia32_loadhps (v4sf, const v2sf *)
!      Generates the 'movhps' machine instruction as a load from memory.
  
   -- Built-in Function: v4sf __builtin_ia32_loadlps (v4sf, const v2sf *)
!      Generates the 'movlps' machine instruction as a load from memory
  
   -- Built-in Function: void __builtin_ia32_storehps (v2sf *, v4sf)
!      Generates the 'movhps' machine instruction as a store to memory.
  
   -- Built-in Function: 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);
--- 55547,55576 ----
       void __builtin_ia32_movntps (float *, v4sf);
       int __builtin_ia32_movmskps (v4sf);
  
!  The following built-in functions are available when ‘-msse’ is used.
  
   -- Built-in Function: v4sf __builtin_ia32_loadups (float *)
!      Generates the ‘movups’ machine instruction as a load from memory.
  
   -- Built-in Function: void __builtin_ia32_storeups (float *, v4sf)
!      Generates the ‘movups’ machine instruction as a store to memory.
  
   -- Built-in Function: v4sf __builtin_ia32_loadss (float *)
!      Generates the ‘movss’ machine instruction as a load from memory.
  
   -- Built-in Function: v4sf __builtin_ia32_loadhps (v4sf, const v2sf *)
!      Generates the ‘movhps’ machine instruction as a load from memory.
  
   -- Built-in Function: v4sf __builtin_ia32_loadlps (v4sf, const v2sf *)
!      Generates the ‘movlps’ machine instruction as a load from memory
  
   -- Built-in Function: void __builtin_ia32_storehps (v2sf *, v4sf)
!      Generates the ‘movhps’ machine instruction as a store to memory.
  
   -- Built-in Function: 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);
*************** All of them generate the machine instruc
*** 55720,55726 ****
       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);
--- 55729,55735 ----
       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);
*************** All of them generate the machine instruc
*** 55735,55741 ****
       v4sf __builtin_ia32_movsldup (v4sf);
       void __builtin_ia32_mwait (unsigned int, unsigned int);
  
!  The following built-in functions are available when '-mssse3' is used.
  All of them generate the machine instruction that is part of the name.
  
       v2si __builtin_ia32_phaddd (v2si, v2si);
--- 55744,55750 ----
       v4sf __builtin_ia32_movsldup (v4sf);
       void __builtin_ia32_mwait (unsigned int, unsigned int);
  
!  The following built-in functions are available when ‘-mssse3’ is used.
  All of them generate the machine instruction that is part of the name.
  
       v2si __builtin_ia32_phaddd (v2si, v2si);
*************** All of them generate the machine instruc
*** 55755,55761 ****
       v2si __builtin_ia32_pabsd (v2si);
       v4hi __builtin_ia32_pabsw (v4hi);
  
!  The following built-in functions are available when '-mssse3' is used.
  All of them generate the machine instruction that is part of the name.
  
       v4si __builtin_ia32_phaddd128 (v4si, v4si);
--- 55764,55770 ----
       v2si __builtin_ia32_pabsd (v2si);
       v4hi __builtin_ia32_pabsw (v4hi);
  
!  The following built-in functions are available when ‘-mssse3’ is used.
  All of them generate the machine instruction that is part of the name.
  
       v4si __builtin_ia32_phaddd128 (v4si, v4si);
*************** All of them generate the machine instruc
*** 55775,55781 ****
       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);
--- 55784,55790 ----
       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);
*************** All of them generate the machine instruc
*** 55822,55864 ****
       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.
  
   -- Built-in Function: v4sf __builtin_ia32_vec_set_v4sf (v4sf, float,
            const int)
!      Generates the 'insertps' machine instruction.
  
   -- Built-in Function: int __builtin_ia32_vec_ext_v16qi (v16qi, const
            int)
!      Generates the 'pextrb' machine instruction.
  
   -- Built-in Function: v16qi __builtin_ia32_vec_set_v16qi (v16qi, int,
            const int)
!      Generates the 'pinsrb' machine instruction.
  
   -- Built-in Function: v4si __builtin_ia32_vec_set_v4si (v4si, int,
            const int)
!      Generates the 'pinsrd' machine instruction.
  
   -- Built-in Function: 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.
  
   -- Built-in Function: float __builtin_ia32_vec_ext_v4sf (v4sf, const
            int)
!      Generates the 'extractps' machine instruction.
  
   -- Built-in Function: int __builtin_ia32_vec_ext_v4si (v4si, const int)
!      Generates the 'pextrd' machine instruction.
  
   -- Built-in Function: 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);
--- 55831,55873 ----
       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.
  
   -- Built-in Function: v4sf __builtin_ia32_vec_set_v4sf (v4sf, float,
            const int)
!      Generates the ‘insertps’ machine instruction.
  
   -- Built-in Function: int __builtin_ia32_vec_ext_v16qi (v16qi, const
            int)
!      Generates the ‘pextrb’ machine instruction.
  
   -- Built-in Function: v16qi __builtin_ia32_vec_set_v16qi (v16qi, int,
            const int)
!      Generates the ‘pinsrb’ machine instruction.
  
   -- Built-in Function: v4si __builtin_ia32_vec_set_v4si (v4si, int,
            const int)
!      Generates the ‘pinsrd’ machine instruction.
  
   -- Built-in Function: 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.
  
   -- Built-in Function: float __builtin_ia32_vec_ext_v4sf (v4sf, const
            int)
!      Generates the ‘extractps’ machine instruction.
  
   -- Built-in Function: int __builtin_ia32_vec_ext_v4si (v4si, const int)
!      Generates the ‘pextrd’ machine instruction.
  
   -- Built-in Function: 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);
*************** All of them generate the machine instruc
*** 55877,55914 ****
       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.
  
   -- Built-in Function: unsigned int __builtin_ia32_crc32qi (unsigned
            int, unsigned char)
!      Generates the 'crc32b' machine instruction.
  
   -- Built-in Function: unsigned int __builtin_ia32_crc32hi (unsigned
            int, unsigned short)
!      Generates the 'crc32w' machine instruction.
  
   -- Built-in Function: unsigned int __builtin_ia32_crc32si (unsigned
            int, unsigned int)
!      Generates the 'crc32l' machine instruction.
  
   -- Built-in Function: 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.
  
   -- Built-in Function: int __builtin_popcount (unsigned int)
!      Generates the 'popcntl' machine instruction.
  
   -- Built-in Function: int __builtin_popcountl (unsigned long)
!      Generates the 'popcntl' or 'popcntq' machine instruction, depending
!      on the size of 'unsigned long'.
  
   -- Built-in Function: 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);
--- 55886,55923 ----
       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.
  
   -- Built-in Function: unsigned int __builtin_ia32_crc32qi (unsigned
            int, unsigned char)
!      Generates the ‘crc32b’ machine instruction.
  
   -- Built-in Function: unsigned int __builtin_ia32_crc32hi (unsigned
            int, unsigned short)
!      Generates the ‘crc32w’ machine instruction.
  
   -- Built-in Function: unsigned int __builtin_ia32_crc32si (unsigned
            int, unsigned int)
!      Generates the ‘crc32l’ machine instruction.
  
   -- Built-in Function: 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.
  
   -- Built-in Function: int __builtin_popcount (unsigned int)
!      Generates the ‘popcntl’ machine instruction.
  
   -- Built-in Function: int __builtin_popcountl (unsigned long)
!      Generates the ‘popcntl’ or ‘popcntq’ machine instruction, depending
!      on the size of ‘unsigned long’.
  
   -- Built-in Function: 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);
*************** All of them generate the machine instruc
*** 56040,56046 ****
       v4df __builtin_ia32_xorpd256 (v4df,v4df);
       v8sf __builtin_ia32_xorps256 (v8sf,v8sf);
  
!  The following built-in functions are available when '-mavx2' is used.
  All of them generate the machine instruction that is part of the name.
  
       v32qi __builtin_ia32_mpsadbw256 (v32qi,v32qi,int);
--- 56049,56055 ----
       v4df __builtin_ia32_xorpd256 (v4df,v4df);
       v8sf __builtin_ia32_xorps256 (v8sf,v8sf);
  
!  The following built-in functions are available when ‘-mavx2’ is used.
  All of them generate the machine instruction that is part of the name.
  
       v32qi __builtin_ia32_mpsadbw256 (v32qi,v32qi,int);
*************** All of them generate the machine instruc
*** 56215,56221 ****
       v4si __builtin_ia32_gatherdiv4si (v4si, pcint,v2di,v4si,int);
       v4si __builtin_ia32_gatherdiv4si256 (v4si, pcint,v4di,v4si,int);
  
!  The following built-in functions are available when '-maes' is used.
  All of them generate the machine instruction that is part of the name.
  
       v2di __builtin_ia32_aesenc128 (v2di, v2di);
--- 56224,56230 ----
       v4si __builtin_ia32_gatherdiv4si (v4si, pcint,v2di,v4si,int);
       v4si __builtin_ia32_gatherdiv4si256 (v4si, pcint,v4di,v4si,int);
  
!  The following built-in functions are available when ‘-maes’ is used.
  All of them generate the machine instruction that is part of the name.
  
       v2di __builtin_ia32_aesenc128 (v2di, v2di);
*************** All of them generate the machine instruc
*** 56225,56237 ****
       v2di __builtin_ia32_aeskeygenassist128 (v2di, const int);
       v2di __builtin_ia32_aesimc128 (v2di);
  
!  The following built-in function is available when '-mpclmul' is used.
  
   -- Built-in Function: 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);
--- 56234,56246 ----
       v2di __builtin_ia32_aeskeygenassist128 (v2di, const int);
       v2di __builtin_ia32_aesimc128 (v2di);
  
!  The following built-in function is available when ‘-mpclmul’ is used.
  
   -- Built-in Function: 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);
*************** All of them generate the machine instruc
*** 56243,56262 ****
       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 function is available when '-mptwrite' is used.
  All of them generate the machine instruction that is part of the name.
  
       void __builtin_ia32_ptwrite32 (unsigned);
       void __builtin_ia32_ptwrite64 (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);
--- 56252,56271 ----
       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 function is available when ‘-mptwrite’ is used.
  All of them generate the machine instruction that is part of the name.
  
       void __builtin_ia32_ptwrite32 (unsigned);
       void __builtin_ia32_ptwrite64 (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);
*************** All of them generate the machine instruc
*** 56266,56272 ****
       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);
--- 56275,56281 ----
       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);
*************** All of them generate the machine instruc
*** 56392,56398 ****
       v2di __builtin_ia32_vpshlq (v2di, v2di);
       v8hi __builtin_ia32_vpshlw (v8hi, v8hi);
  
!  The following built-in functions are available when '-mfma4' is used.
  All of them generate the machine instruction that is part of the name.
  
       v2df __builtin_ia32_vfmaddpd (v2df, v2df, v2df);
--- 56401,56407 ----
       v2di __builtin_ia32_vpshlq (v2di, v2di);
       v8hi __builtin_ia32_vpshlw (v8hi, v8hi);
  
!  The following built-in functions are available when ‘-mfma4’ is used.
  All of them generate the machine instruction that is part of the name.
  
       v2df __builtin_ia32_vfmaddpd (v2df, v2df, v2df);
*************** All of them generate the machine instruc
*** 56429,56435 ****
       v8sf __builtin_ia32_vfmsubaddps256 (v8sf, v8sf, v8sf);
  
  
!  The following built-in functions are available when '-mlwp' is used.
  
       void __builtin_ia32_llwpcb16 (void *);
       void __builtin_ia32_llwpcb32 (void *);
--- 56438,56444 ----
       v8sf __builtin_ia32_vfmsubaddps256 (v8sf, v8sf, v8sf);
  
  
!  The following built-in functions are available when ‘-mlwp’ is used.
  
       void __builtin_ia32_llwpcb16 (void *);
       void __builtin_ia32_llwpcb32 (void *);
*************** All of them generate the machine instruc
*** 56444,56455 ****
       unsigned char __builtin_ia32_lwpins32 (unsigned int, unsigned int, unsigned int);
       unsigned char __builtin_ia32_lwpins64 (unsigned __int64, unsigned int, unsigned int);
  
!  The following built-in functions are available when '-mbmi' is used.
  All of them generate the machine instruction that is part of the name.
       unsigned int __builtin_ia32_bextr_u32(unsigned int, unsigned int);
       unsigned long long __builtin_ia32_bextr_u64 (unsigned long long, unsigned long long);
  
!  The following built-in functions are available when '-mbmi2' is used.
  All of them generate the machine instruction that is part of the name.
       unsigned int _bzhi_u32 (unsigned int, unsigned int);
       unsigned int _pdep_u32 (unsigned int, unsigned int);
--- 56453,56464 ----
       unsigned char __builtin_ia32_lwpins32 (unsigned int, unsigned int, unsigned int);
       unsigned char __builtin_ia32_lwpins64 (unsigned __int64, unsigned int, unsigned int);
  
!  The following built-in functions are available when ‘-mbmi’ is used.
  All of them generate the machine instruction that is part of the name.
       unsigned int __builtin_ia32_bextr_u32(unsigned int, unsigned int);
       unsigned long long __builtin_ia32_bextr_u64 (unsigned long long, unsigned long long);
  
!  The following built-in functions are available when ‘-mbmi2’ is used.
  All of them generate the machine instruction that is part of the name.
       unsigned int _bzhi_u32 (unsigned int, unsigned int);
       unsigned int _pdep_u32 (unsigned int, unsigned int);
*************** All of them generate the machine instruc
*** 56458,56490 ****
       unsigned long long _pdep_u64 (unsigned long long, unsigned long long);
       unsigned long long _pext_u64 (unsigned long long, unsigned long long);
  
!  The following built-in functions are available when '-mlzcnt' is used.
  All of them generate the machine instruction that is part of the name.
       unsigned short __builtin_ia32_lzcnt_u16(unsigned short);
       unsigned int __builtin_ia32_lzcnt_u32(unsigned int);
       unsigned long long __builtin_ia32_lzcnt_u64 (unsigned long long);
  
!  The following built-in functions are available when '-mfxsr' is used.
  All of them generate the machine instruction that is part of the name.
       void __builtin_ia32_fxsave (void *);
       void __builtin_ia32_fxrstor (void *);
       void __builtin_ia32_fxsave64 (void *);
       void __builtin_ia32_fxrstor64 (void *);
  
!  The following built-in functions are available when '-mxsave' is used.
  All of them generate the machine instruction that is part of the name.
       void __builtin_ia32_xsave (void *, long long);
       void __builtin_ia32_xrstor (void *, long long);
       void __builtin_ia32_xsave64 (void *, long long);
       void __builtin_ia32_xrstor64 (void *, long long);
  
!  The following built-in functions are available when '-mxsaveopt' is
  used.  All of them generate the machine instruction that is part of the
  name.
       void __builtin_ia32_xsaveopt (void *, long long);
       void __builtin_ia32_xsaveopt64 (void *, long long);
  
!  The following built-in functions are available when '-mtbm' is used.
  Both of them generate the immediate form of the bextr machine
  instruction.
       unsigned int __builtin_ia32_bextri_u32 (unsigned int,
--- 56467,56499 ----
       unsigned long long _pdep_u64 (unsigned long long, unsigned long long);
       unsigned long long _pext_u64 (unsigned long long, unsigned long long);
  
!  The following built-in functions are available when ‘-mlzcnt’ is used.
  All of them generate the machine instruction that is part of the name.
       unsigned short __builtin_ia32_lzcnt_u16(unsigned short);
       unsigned int __builtin_ia32_lzcnt_u32(unsigned int);
       unsigned long long __builtin_ia32_lzcnt_u64 (unsigned long long);
  
!  The following built-in functions are available when ‘-mfxsr’ is used.
  All of them generate the machine instruction that is part of the name.
       void __builtin_ia32_fxsave (void *);
       void __builtin_ia32_fxrstor (void *);
       void __builtin_ia32_fxsave64 (void *);
       void __builtin_ia32_fxrstor64 (void *);
  
!  The following built-in functions are available when ‘-mxsave’ is used.
  All of them generate the machine instruction that is part of the name.
       void __builtin_ia32_xsave (void *, long long);
       void __builtin_ia32_xrstor (void *, long long);
       void __builtin_ia32_xsave64 (void *, long long);
       void __builtin_ia32_xrstor64 (void *, long long);
  
!  The following built-in functions are available when ‘-mxsaveopt’ is
  used.  All of them generate the machine instruction that is part of the
  name.
       void __builtin_ia32_xsaveopt (void *, long long);
       void __builtin_ia32_xsaveopt64 (void *, long long);
  
!  The following built-in functions are available when ‘-mtbm’ is used.
  Both of them generate the immediate form of the bextr machine
  instruction.
       unsigned int __builtin_ia32_bextri_u32 (unsigned int,
*************** instruction.
*** 56492,56498 ****
       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);
--- 56501,56507 ----
       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);
*************** All of them generate the machine instruc
*** 56515,56521 ****
       v2sf __builtin_ia32_pi2fd (v2si);
       v4hi __builtin_ia32_pmulhrw (v4hi, v4hi);
  
!  The following built-in functions are available when '-m3dnowa' is used.
  All of them generate the machine instruction that is part of the name.
  
       v2si __builtin_ia32_pf2iw (v2sf);
--- 56524,56530 ----
       v2sf __builtin_ia32_pi2fd (v2si);
       v4hi __builtin_ia32_pmulhrw (v4hi, v4hi);
  
!  The following built-in functions are available when ‘-m3dnowa’ is used.
  All of them generate the machine instruction that is part of the name.
  
       v2si __builtin_ia32_pf2iw (v2sf);
*************** All of them generate the machine instruc
*** 56525,56531 ****
       v2sf __builtin_ia32_pswapdsf (v2sf);
       v2si __builtin_ia32_pswapdsi (v2si);
  
!  The following built-in functions are available when '-mrtm' is used
  They are used for restricted transactional memory.  These are the
  internal low level functions.  Normally the functions in *note x86
  transactional memory intrinsics:: should be used instead.
--- 56534,56540 ----
       v2sf __builtin_ia32_pswapdsf (v2sf);
       v2si __builtin_ia32_pswapdsi (v2si);
  
!  The following built-in functions are available when ‘-mrtm’ is used
  They are used for restricted transactional memory.  These are the
  internal low level functions.  Normally the functions in *note x86
  transactional memory intrinsics:: should be used instead.
*************** transactional memory intrinsics:: should
*** 56535,56555 ****
       void __builtin_ia32_xabort (status);
       int __builtin_ia32_xtest ();
  
!  The following built-in functions are available when '-mmwaitx' is used.
  All of them generate the machine instruction that is part of the name.
       void __builtin_ia32_monitorx (void *, unsigned int, unsigned int);
       void __builtin_ia32_mwaitx (unsigned int, unsigned int, unsigned int);
  
!  The following built-in functions are available when '-mclzero' is used.
  All of them generate the machine instruction that is part of the name.
       void __builtin_i32_clzero (void *);
  
!  The following built-in functions are available when '-mpku' is used.
  They generate reads and writes to PKRU.
       void __builtin_ia32_wrpkru (unsigned int);
       unsigned int __builtin_ia32_rdpkru ();
  
!  The following built-in functions are available when '-mshstk' option is
  used.  They support shadow stack machine instructions from Intel
  Control-flow Enforcement Technology (CET). Each built-in function
  generates the machine instruction that is part of the function's name.
--- 56544,56564 ----
       void __builtin_ia32_xabort (status);
       int __builtin_ia32_xtest ();
  
!  The following built-in functions are available when ‘-mmwaitx’ is used.
  All of them generate the machine instruction that is part of the name.
       void __builtin_ia32_monitorx (void *, unsigned int, unsigned int);
       void __builtin_ia32_mwaitx (unsigned int, unsigned int, unsigned int);
  
!  The following built-in functions are available when ‘-mclzero’ is used.
  All of them generate the machine instruction that is part of the name.
       void __builtin_i32_clzero (void *);
  
!  The following built-in functions are available when ‘-mpku’ is used.
  They generate reads and writes to PKRU.
       void __builtin_ia32_wrpkru (unsigned int);
       unsigned int __builtin_ia32_rdpkru ();
  
!  The following built-in functions are available when ‘-mshstk’ option is
  used.  They support shadow stack machine instructions from Intel
  Control-flow Enforcement Technology (CET). Each built-in function
  generates the machine instruction that is part of the function's name.
*************** File: gcc.info,  Node: x86 transactional
*** 56577,56583 ****
  
  These hardware transactional memory intrinsics for x86 allow you to use
  memory transactions with RTM (Restricted Transactional Memory).  This
! support is enabled with the '-mrtm' option.  For using HLE (Hardware
  Lock Elision) see *note x86 specific memory model extensions for
  transactional memory:: instead.
  
--- 56586,56592 ----
  
  These hardware transactional memory intrinsics for x86 allow you to use
  memory transactions with RTM (Restricted Transactional Memory).  This
! support is enabled with the ‘-mrtm’ option.  For using HLE (Hardware
  Lock Elision) see *note x86 specific memory model extensions for
  transactional memory:: instead.
  
*************** and suitable fallback code always needs
*** 56590,56596 ****
  
   -- RTM Function: unsigned _xbegin ()
       Start a RTM (Restricted Transactional Memory) transaction.  Returns
!      '_XBEGIN_STARTED' when the transaction started successfully (note
       this is not 0, so the constant has to be explicitly tested).
  
       If the transaction aborts, all side effects are undone and an abort
--- 56599,56605 ----
  
   -- RTM Function: unsigned _xbegin ()
       Start a RTM (Restricted Transactional Memory) transaction.  Returns
!      ‘_XBEGIN_STARTED’ when the transaction started successfully (note
       this is not 0, so the constant has to be explicitly tested).
  
       If the transaction aborts, all side effects are undone and an abort
*************** and suitable fallback code always needs
*** 56598,56606 ****
       defined:
  
        -- Macro: _XABORT_EXPLICIT
!           Transaction was explicitly aborted with '_xabort'.  The
!           parameter passed to '_xabort' is available with
!           '_XABORT_CODE(status)'.
  
        -- Macro: _XABORT_RETRY
            Transaction retry is possible.
--- 56607,56615 ----
       defined:
  
        -- Macro: _XABORT_EXPLICIT
!           Transaction was explicitly aborted with ‘_xabort’.  The
!           parameter passed to ‘_xabort’ is available with
!           ‘_XABORT_CODE(status)’.
  
        -- Macro: _XABORT_RETRY
            Transaction retry is possible.
*************** and suitable fallback code always needs
*** 56634,56642 ****
   -- RTM Function: void _xabort (status)
       Abort the current transaction.  When no transaction is active this
       is a no-op.  The STATUS is an 8-bit constant; its value is encoded
!      in the return value from '_xbegin'.
  
!  Here is an example showing handling for '_XABORT_RETRY' and a fallback
  path for other failures:
  
       #include 
--- 56643,56651 ----
   -- RTM Function: void _xabort (status)
       Abort the current transaction.  When no transaction is active this
       is a no-op.  The STATUS is an 8-bit constant; its value is encoded
!      in the return value from ‘_xbegin’.
  
!  Here is an example showing handling for ‘_XABORT_RETRY’ and a fallback
  path for other failures:
  
       #include 
*************** File: gcc.info,  Node: x86 control-flow
*** 56672,56680 ****
  
   -- CET Function: ret_type _get_ssp (void)
       Get the current value of shadow stack pointer if shadow stack
!      support from Intel CET is enabled in the hardware or '0' otherwise.
!      The 'ret_type' is 'unsigned long long' for 64-bit targets and
!      'unsigned int' for 32-bit targets.
  
   -- CET Function: void _inc_ssp (unsigned int)
       Increment the current shadow stack pointer by the size specified by
--- 56681,56689 ----
  
   -- CET Function: ret_type _get_ssp (void)
       Get the current value of shadow stack pointer if shadow stack
!      support from Intel CET is enabled in the hardware or ‘0’ otherwise.
!      The ‘ret_type’ is ‘unsigned long long’ for 64-bit targets and
!      ‘unsigned int’ for 32-bit targets.
  
   -- CET Function: void _inc_ssp (unsigned int)
       Increment the current shadow stack pointer by the size specified by
*************** File: gcc.info,  Node: Solaris Format Ch
*** 56729,56738 ****
  6.61.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
--- 56738,56747 ----
  6.61.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
*************** File: gcc.info,  Node: Darwin Format Che
*** 56741,56758 ****
  ---------------------------
  
  In addition to the full set of format archetypes (attribute format style
! arguments such as 'printf', 'scanf', 'strftime', and 'strfmon'), Darwin
! targets also support the 'CFString' (or '__CFString__') archetype in the
! 'format' attribute.  Declarations with this archetype are parsed for
  correct syntax and argument types.  However, parsing of the format
  string itself and validating arguments against it in calls to such
  functions is currently not performed.
  
!  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
--- 56750,56767 ----
  ---------------------------
  
  In addition to the full set of format archetypes (attribute format style
! arguments such as ‘printf’, ‘scanf’, ‘strftime’, and ‘strfmon’), Darwin
! targets also support the ‘CFString’ (or ‘__CFString__’) archetype in the
! ‘format’ attribute.  Declarations with this archetype are parsed for
  correct syntax and argument types.  However, parsing of the format
  string itself and validating arguments against it in calls to such
  functions is currently not performed.
  
!  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
*************** The pragmas defined by the AArch64 targe
*** 56798,56806 ****
  target function attributes.  They can be specified as below:
       #pragma GCC target("string")
  
!  where 'STRING' can be any string accepted as an AArch64 target
  attribute.  *Note AArch64 Function Attributes::, for more details on the
! permissible values of 'string'.
  
  
  File: gcc.info,  Node: ARM Pragmas,  Next: M32C Pragmas,  Prev: AArch64 Pragmas,  Up: Pragmas
--- 56807,56815 ----
  target function attributes.  They can be specified as below:
       #pragma GCC target("string")
  
!  where ‘STRING’ can be any string accepted as an AArch64 target
  attribute.  *Note AArch64 Function Attributes::, for more details on the
! permissible values of ‘string’.
  
  
  File: gcc.info,  Node: ARM Pragmas,  Next: M32C Pragmas,  Prev: AArch64 Pragmas,  Up: Pragmas
*************** File: gcc.info,  Node: ARM Pragmas,  Nex
*** 56809,56825 ****
  ------------------
  
  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.
  
  
--- 56818,56834 ----
  ------------------
  
  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,  Ne
*** 56828,56848 ****
  6.62.3 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
--- 56837,56857 ----
  6.62.3 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
*************** File: gcc.info,  Node: PRU Pragmas,  Nex
*** 56854,56860 ****
  6.62.4 PRU Pragmas
  ------------------
  
! 'ctable_entry INDEX CONSTANT_ADDRESS'
       Specifies that the PRU CTABLE entry given by INDEX has the value
       CONSTANT_ADDRESS.  This enables GCC to emit LBCO/SBCO instructions
       when the load/store address is known and can be addressed with some
--- 56863,56869 ----
  6.62.4 PRU Pragmas
  ------------------
  
! ‘ctable_entry INDEX CONSTANT_ADDRESS’
       Specifies that the PRU CTABLE entry given by INDEX has the value
       CONSTANT_ADDRESS.  This enables GCC to emit LBCO/SBCO instructions
       when the load/store address is known and can be addressed with some
*************** File: gcc.info,  Node: RS/6000 and Power
*** 56871,56888 ****
  ----------------------------------
  
  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.
  
  
--- 56880,56897 ----
  ----------------------------------
  
  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: S/390 Pragmas,  N
*** 56894,56904 ****
  The pragmas defined by the S/390 target correspond to the S/390 target
  function attributes and some the additional options:
  
! 'zvector'
! 'no-zvector'
  
   Note that options of the pragma, unlike options of the target
! attribute, do change the value of preprocessor macros like '__VEC__'.
  They can be specified as below:
  
       #pragma GCC target("string[,string]...")
--- 56903,56913 ----
  The pragmas defined by the S/390 target correspond to the S/390 target
  function attributes and some the additional options:
  
! ‘zvector’
! ‘no-zvector’
  
   Note that options of the pragma, unlike options of the target
! attribute, do change the value of preprocessor macros like ‘__VEC__’.
  They can be specified as below:
  
       #pragma GCC target("string[,string]...")
*************** The following pragmas are available for
*** 56914,56936 ****
  Darwin operating system.  These are useful for compatibility with other
  Mac OS compilers.
  
! 'mark TOKENS...'
       This pragma is accepted, but has no effect.
  
! 'options align=ALIGNMENT'
       This pragma sets the alignment of fields in structures.  The values
!      of ALIGNMENT may be 'mac68k', to emulate m68k alignment, or
!      'power', to emulate PowerPC alignment.  Uses of this pragma nest
!      properly; to restore the previous setting, use 'reset' for the
       ALIGNMENT.
  
! 'segment TOKENS...'
       This pragma is accepted, but has no effect.
  
! 'unused (VAR [, VAR]...)'
       This pragma declares variables to be possibly unused.  GCC does not
       produce warnings for the listed variables.  The effect is similar
!      to that of the 'unused' attribute, except that this pragma may
       appear anywhere within the variables' scopes.
  
  
--- 56923,56945 ----
  Darwin operating system.  These are useful for compatibility with other
  Mac OS compilers.
  
! ‘mark TOKENS...’
       This pragma is accepted, but has no effect.
  
! ‘options align=ALIGNMENT’
       This pragma sets the alignment of fields in structures.  The values
!      of ALIGNMENT may be ‘mac68k’, to emulate m68k alignment, or
!      ‘power’, to emulate PowerPC alignment.  Uses of this pragma nest
!      properly; to restore the previous setting, use ‘reset’ for the
       ALIGNMENT.
  
! ‘segment TOKENS...’
       This pragma is accepted, but has no effect.
  
! ‘unused (VAR [, VAR]...)’
       This pragma declares variables to be possibly unused.  GCC does not
       produce warnings for the listed variables.  The effect is similar
!      to that of the ‘unused’ attribute, except that this pragma may
       appear anywhere within the variables' scopes.
  
  
*************** File: gcc.info,  Node: Solaris Pragmas,
*** 56939,56968 ****
  6.62.8 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-Layout Pragmas,  Prev: Solaris Pragmas,  Up: Pragmas
--- 56948,56977 ----
  6.62.8 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-Layout Pragmas,  Prev: Solaris Pragmas,  Up: Pragmas
*************** File: gcc.info,  Node: Symbol-Renaming P
*** 56970,56995 ****
  6.62.9 Symbol-Renaming Pragmas
  ------------------------------
  
! GCC supports a '#pragma' directive that changes the name used in
  assembly for a given declaration.  While this pragma is supported on all
  platforms, it is intended primarily to provide compatibility with the
  Solaris system headers.  This effect can also be achieved using the asm
  labels extension (*note Asm Labels::).
  
! 'redefine_extname OLDNAME NEWNAME'
  
       This pragma gives the C function OLDNAME the assembly symbol
!      NEWNAME.  The preprocessor macro '__PRAGMA_REDEFINE_EXTNAME' is
       defined if this pragma is available (currently on all platforms).
  
!  This pragma and the 'asm' labels extension interact in a complicated
  manner.  Here are some corner cases you may want to be aware of:
  
    1. This pragma silently applies only to declarations with external
!      linkage.  The 'asm' label feature does not have this restriction.
  
    2. In C++, this pragma silently applies only to declarations with "C"
!      linkage.  Again, 'asm' labels do not have this restriction.
  
    3. If either of the ways of changing the assembly name of a
       declaration are applied to a declaration whose assembly name has
--- 56979,57004 ----
  6.62.9 Symbol-Renaming Pragmas
  ------------------------------
  
! GCC supports a ‘#pragma’ directive that changes the name used in
  assembly for a given declaration.  While this pragma is supported on all
  platforms, it is intended primarily to provide compatibility with the
  Solaris system headers.  This effect can also be achieved using the asm
  labels extension (*note Asm Labels::).
  
! ‘redefine_extname OLDNAME NEWNAME’
  
       This pragma gives the C function OLDNAME the assembly symbol
!      NEWNAME.  The preprocessor macro ‘__PRAGMA_REDEFINE_EXTNAME’ is
       defined if this pragma is available (currently on all platforms).
  
!  This pragma and the ‘asm’ labels extension interact in a complicated
  manner.  Here are some corner cases you may want to be aware of:
  
    1. This pragma silently applies only to declarations with external
!      linkage.  The ‘asm’ label feature does not have this restriction.
  
    2. In C++, this pragma silently applies only to declarations with "C"
!      linkage.  Again, ‘asm’ labels do not have this restriction.
  
    3. If either of the ways of changing the assembly name of a
       declaration are applied to a declaration whose assembly name has
*************** manner.  Here are some corner cases you
*** 56998,57004 ****
       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.
  
  
--- 57007,57013 ----
       to generate code), and the new name is different, a warning issues
       and the name does not change.
  
!   4. The OLDNAME used by ‘#pragma redefine_extname’ is always the
       C-language name.
  
  
*************** File: gcc.info,  Node: Structure-Layout
*** 57008,57050 ****
  --------------------------------
  
  For compatibility with Microsoft Windows compilers, GCC supports a set
! of '#pragma' directives that change the maximum alignment of members of
  structures (other than zero-width bit-fields), unions, and classes
  subsequently defined.  The N value below always is required to be a
  small power of two and specifies the new alignment in bytes.
  
!   1. '#pragma pack(N)' simply sets the new alignment.
!   2. '#pragma pack()' sets the alignment to the one that was in effect
       when compilation started (see also command-line option
!      '-fpack-struct[=N]' *note Code Gen Options::).
!   3. '#pragma pack(push[,N])' pushes the current alignment setting on an
       internal stack and then optionally sets the new alignment.
!   4. '#pragma pack(pop)' restores the alignment setting to the one saved
       at the top of the internal stack (and removes that stack entry).
!      Note that '#pragma pack([N])' does not influence this internal
!      stack; thus it is possible to have '#pragma pack(push)' followed by
!      multiple '#pragma pack(N)' instances and finalized by a single
!      '#pragma pack(pop)'.
  
!  Some targets, e.g. x86 and PowerPC, support the '#pragma ms_struct'
  directive which lays out structures and unions subsequently defined as
! the documented '__attribute__ ((ms_struct))'.
  
!   1. '#pragma ms_struct on' turns on the Microsoft layout.
!   2. '#pragma ms_struct off' turns off the Microsoft layout.
!   3. '#pragma ms_struct reset' goes back to the default layout.
  
!  Most targets also support the '#pragma scalar_storage_order' directive
  which lays out structures and unions subsequently defined as the
! documented '__attribute__ ((scalar_storage_order))'.
  
!   1. '#pragma scalar_storage_order big-endian' sets the storage order of
       the scalar fields to big-endian.
!   2. '#pragma scalar_storage_order little-endian' sets the storage order
       of the scalar fields to little-endian.
!   3. '#pragma scalar_storage_order default' goes back to the endianness
       that was in effect when compilation started (see also command-line
!      option '-fsso-struct=ENDIANNESS' *note C Dialect Options::).
  
  
  File: gcc.info,  Node: Weak Pragmas,  Next: Diagnostic Pragmas,  Prev: Structure-Layout Pragmas,  Up: Pragmas
--- 57017,57059 ----
  --------------------------------
  
  For compatibility with Microsoft Windows compilers, GCC supports a set
! of ‘#pragma’ directives that change the maximum alignment of members of
  structures (other than zero-width bit-fields), unions, and classes
  subsequently defined.  The N value below always is required to be a
  small power of two and specifies the new alignment in bytes.
  
!   1. ‘#pragma pack(N)’ simply sets the new alignment.
!   2. ‘#pragma pack()’ sets the alignment to the one that was in effect
       when compilation started (see also command-line option
!      ‘-fpack-struct[=N]’ *note Code Gen Options::).
!   3. ‘#pragma pack(push[,N])’ pushes the current alignment setting on an
       internal stack and then optionally sets the new alignment.
!   4. ‘#pragma pack(pop)’ restores the alignment setting to the one saved
       at the top of the internal stack (and removes that stack entry).
!      Note that ‘#pragma pack([N])’ does not influence this internal
!      stack; thus it is possible to have ‘#pragma pack(push)’ followed by
!      multiple ‘#pragma pack(N)’ instances and finalized by a single
!      ‘#pragma pack(pop)’.
  
!  Some targets, e.g. x86 and PowerPC, support the ‘#pragma ms_struct’
  directive which lays out structures and unions subsequently defined as
! the documented ‘__attribute__ ((ms_struct))’.
  
!   1. ‘#pragma ms_struct on’ turns on the Microsoft layout.
!   2. ‘#pragma ms_struct off’ turns off the Microsoft layout.
!   3. ‘#pragma ms_struct reset’ goes back to the default layout.
  
!  Most targets also support the ‘#pragma scalar_storage_order’ directive
  which lays out structures and unions subsequently defined as the
! documented ‘__attribute__ ((scalar_storage_order))’.
  
!   1. ‘#pragma scalar_storage_order big-endian’ sets the storage order of
       the scalar fields to big-endian.
!   2. ‘#pragma scalar_storage_order little-endian’ sets the storage order
       of the scalar fields to little-endian.
!   3. ‘#pragma scalar_storage_order default’ goes back to the endianness
       that was in effect when compilation started (see also command-line
!      option ‘-fsso-struct=ENDIANNESS’ *note C Dialect Options::).
  
  
  File: gcc.info,  Node: Weak Pragmas,  Next: Diagnostic Pragmas,  Prev: Structure-Layout Pragmas,  Up: Pragmas
*************** File: gcc.info,  Node: Weak Pragmas,  Ne
*** 57052,57067 ****
  6.62.11 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.
  
--- 57061,57076 ----
  6.62.11 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 Pragma
*** 57073,57094 ****
  
  GCC allows the user to selectively enable or disable certain types of
  diagnostics, and change the kind of the diagnostic.  For example, a
! project's policy might require that all sources compile with '-Werror'
  but certain files might have exceptions allowing specific types of
  warnings.  Or, a project might selectively enable diagnostics and treat
  them as errors depending on which preprocessor macros are defined.
  
! '#pragma GCC diagnostic KIND OPTION'
  
       Modifies the disposition of a diagnostic.  Note that not all
       diagnostics are modifiable; at the moment only warnings (normally
!      controlled by '-W...') can be controlled, and not all of them.  Use
!      '-fdiagnostics-show-option' to determine which diagnostics are
       controllable and which option controls them.
  
!      KIND is 'error' to treat this diagnostic as an error, 'warning' to
!      treat it like a warning (even if '-Werror' is in effect), or
!      'ignored' if the diagnostic is to be ignored.  OPTION is a double
       quoted string that matches the command-line option.
  
            #pragma GCC diagnostic warning "-Wformat"
--- 57082,57103 ----
  
  GCC allows the user to selectively enable or disable certain types of
  diagnostics, and change the kind of the diagnostic.  For example, a
! project's policy might require that all sources compile with ‘-Werror’
  but certain files might have exceptions allowing specific types of
  warnings.  Or, a project might selectively enable diagnostics and treat
  them as errors depending on which preprocessor macros are defined.
  
! ‘#pragma GCC diagnostic KIND OPTION’
  
       Modifies the disposition of a diagnostic.  Note that not all
       diagnostics are modifiable; at the moment only warnings (normally
!      controlled by ‘-W...’) can be controlled, and not all of them.  Use
!      ‘-fdiagnostics-show-option’ to determine which diagnostics are
       controllable and which option controls them.
  
!      KIND is ‘error’ to treat this diagnostic as an error, ‘warning’ to
!      treat it like a warning (even if ‘-Werror’ is in effect), or
!      ‘ignored’ if the diagnostic is to be ignored.  OPTION is a double
       quoted string that matches the command-line option.
  
            #pragma GCC diagnostic warning "-Wformat"
*************** them as errors depending on which prepro
*** 57101,57112 ****
       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 */
--- 57110,57121 ----
       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 */
*************** them as errors depending on which prepro
*** 57118,57133 ****
            #pragma GCC diagnostic pop
              foo(d);                       /* depends on command-line options */
  
! '#pragma GCC diagnostic ignored_attributes'
  
!      Similarly to '-Wno-attributes=', this pragma allows users to
       suppress warnings about unknown scoped attributes (in C++11 and
!      C2X). For example, '#pragma GCC diagnostic ignored_attributes
!      "vendor::attr"' disables warning about the following declaration:
  
            [[vendor::attr]] void f();
  
!      whereas '#pragma GCC diagnostic ignored_attributes "vendor::"'
       prevents warning about both of these declarations:
  
            [[vendor::safe]] void f();
--- 57127,57142 ----
            #pragma GCC diagnostic pop
              foo(d);                       /* depends on command-line options */
  
! ‘#pragma GCC diagnostic ignored_attributes’
  
!      Similarly to ‘-Wno-attributes=’, this pragma allows users to
       suppress warnings about unknown scoped attributes (in C++11 and
!      C2X).  For example, ‘#pragma GCC diagnostic ignored_attributes
!      "vendor::attr"’ disables warning about the following declaration:
  
            [[vendor::attr]] void f();
  
!      whereas ‘#pragma GCC diagnostic ignored_attributes "vendor::"’
       prevents warning about both of these declarations:
  
            [[vendor::safe]] void f();
*************** them as errors depending on which prepro
*** 57136,57146 ****
   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.  Newlines can be included in the string by using the '\n'
       escape sequence.
  
            #pragma message "Compiling " __FILE__ "..."
--- 57145,57155 ----
   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.  Newlines can be included in the string by using the ‘\n’
       escape sequence.
  
            #pragma message "Compiling " __FILE__ "..."
*************** compilation.
*** 57153,57169 ****
  
            TODO(Remember to fix this)
  
!      prints '/tmp/file.c:4: note: #pragma message: TODO - Remember to
!      fix this'.
  
! '#pragma GCC error MESSAGE'
       Generates an error message.  This pragma _is_ considered to
       indicate an error in the compilation, and it will be treated as
       such.
  
!      Newlines can be included in the string by using the '\n' escape
       sequence.  They will be displayed as newlines even if the
!      '-fmessage-length' option is set to zero.
  
       The error is only generated if the pragma is present in the code
       after pre-processing has been completed.  It does not matter
--- 57162,57178 ----
  
            TODO(Remember to fix this)
  
!      prints ‘/tmp/file.c:4: note: #pragma message: TODO - Remember to
!      fix this’.
  
! ‘#pragma GCC error MESSAGE’
       Generates an error message.  This pragma _is_ considered to
       indicate an error in the compilation, and it will be treated as
       such.
  
!      Newlines can be included in the string by using the ‘\n’ escape
       sequence.  They will be displayed as newlines even if the
!      ‘-fmessage-length’ option is set to zero.
  
       The error is only generated if the pragma is present in the code
       after pre-processing has been completed.  It does not matter
*************** compilation.
*** 57178,57186 ****
            #pragma GCC error "this error is seen"
            }
  
! '#pragma GCC warning MESSAGE'
!      This is just like 'pragma GCC error' except that a warning message
!      is issued instead of an error message.  Unless '-Werror' is in
       effect, in which case this pragma will generate an error as well.
  
  
--- 57187,57195 ----
            #pragma GCC error "this error is seen"
            }
  
! ‘#pragma GCC warning MESSAGE’
!      This is just like ‘pragma GCC error’ except that a warning message
!      is issued instead of an error message.  Unless ‘-Werror’ is in
       effect, in which case this pragma will generate an error as well.
  
  
*************** File: gcc.info,  Node: Visibility Pragma
*** 57189,57202 ****
  6.62.13 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::).
  
!      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.
--- 57198,57211 ----
  6.62.13 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::).
  
!      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 Pr
*** 57208,57221 ****
  ------------------------------
  
  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.
--- 57217,57230 ----
  ------------------------------
  
  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.
*************** pop_macro("MACRO_NAME")'.
*** 57229,57236 ****
       #pragma pop_macro("X")
       int x [X];
  
! In this example, the definition of X as 1 is saved by '#pragma
! push_macro' and restored by '#pragma pop_macro'.
  
  
  File: gcc.info,  Node: Function Specific Option Pragmas,  Next: Loop-Specific Pragmas,  Prev: Push/Pop Macro Pragmas,  Up: Pragmas
--- 57238,57245 ----
       #pragma pop_macro("X")
       int x [X];
  
! In this example, the definition of X as 1 is saved by ‘#pragma
! push_macro’ and restored by ‘#pragma pop_macro’.
  
  
  File: gcc.info,  Node: Function Specific Option Pragmas,  Next: Loop-Specific Pragmas,  Prev: Push/Pop Macro Pragmas,  Up: Pragmas
*************** File: gcc.info,  Node: Function Specific
*** 57238,57281 ****
  6.62.15 Function Specific Option Pragmas
  ----------------------------------------
  
! '#pragma GCC target (STRING, ...)'
  
       This pragma allows you to set target-specific options for functions
       defined later in the source file.  One or more strings can be
       specified.  Each function that is defined after this point is
!      treated as if it had been declared with one 'target('STRING')'
       attribute for each STRING argument.  The parentheses around the
       strings in the pragma are optional.  *Note Function Attributes::,
!      for more information about the 'target' attribute and the attribute
       syntax.
  
!      The '#pragma GCC target' pragma is presently implemented for x86,
       ARM, AArch64, PowerPC, S/390, and Nios II targets only.
  
! '#pragma GCC optimize (STRING, ...)'
  
       This pragma allows you to set global optimization options for
       functions defined later in the source file.  One or more strings
       can be specified.  Each function that is defined after this point
!      is treated as if it had been declared with one 'optimize('STRING')'
       attribute for each STRING argument.  The parentheses around the
       strings in the pragma are optional.  *Note Function Attributes::,
!      for more information about the 'optimize' attribute and the
       attribute syntax.
  
! '#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.
  
! '#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.
  
  
--- 57247,57290 ----
  6.62.15 Function Specific Option Pragmas
  ----------------------------------------
  
! ‘#pragma GCC target (STRING, ...)’
  
       This pragma allows you to set target-specific options for functions
       defined later in the source file.  One or more strings can be
       specified.  Each function that is defined after this point is
!      treated as if it had been declared with one ‘target(’STRING‘)’
       attribute for each STRING argument.  The parentheses around the
       strings in the pragma are optional.  *Note Function Attributes::,
!      for more information about the ‘target’ attribute and the attribute
       syntax.
  
!      The ‘#pragma GCC target’ pragma is presently implemented for x86,
       ARM, AArch64, PowerPC, S/390, and Nios II targets only.
  
! ‘#pragma GCC optimize (STRING, ...)’
  
       This pragma allows you to set global optimization options for
       functions defined later in the source file.  One or more strings
       can be specified.  Each function that is defined after this point
!      is treated as if it had been declared with one ‘optimize(’STRING‘)’
       attribute for each STRING argument.  The parentheses around the
       strings in the pragma are optional.  *Note Function Attributes::,
!      for more information about the ‘optimize’ attribute and the
       attribute syntax.
  
! ‘#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.
  
! ‘#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.
  
  
*************** File: gcc.info,  Node: Loop-Specific Pra
*** 57284,57290 ****
  6.62.16 Loop-Specific Pragmas
  -----------------------------
  
! '#pragma GCC ivdep'
  
       With this pragma, the programmer asserts that there are no
       loop-carried dependencies which would prevent consecutive
--- 57293,57299 ----
  6.62.16 Loop-Specific Pragmas
  -----------------------------
  
! ‘#pragma GCC ivdep’
  
       With this pragma, the programmer asserts that there are no
       loop-carried dependencies which would prevent consecutive
*************** File: gcc.info,  Node: Loop-Specific Pra
*** 57302,57308 ****
                a[i] = b[i] + c[i];
            }
  
!      In this example, using the 'restrict' qualifier had the same
       effect.  In the following example, that would not be possible.
       Assume k < -m or k >= m.  Only with the pragma, the compiler knows
       that it can unconditionally vectorize the following loop:
--- 57311,57317 ----
                a[i] = b[i] + c[i];
            }
  
!      In this example, using the ‘restrict’ qualifier had the same
       effect.  In the following example, that would not be possible.
       Assume k < -m or k >= m.  Only with the pragma, the compiler knows
       that it can unconditionally vectorize the following loop:
*************** File: gcc.info,  Node: Loop-Specific Pra
*** 57314,57324 ****
                a[i] = a[i + k] * c;
            }
  
! '#pragma GCC unroll N'
  
       You can use this pragma to control how many times a loop should be
!      unrolled.  It must be placed immediately before a 'for', 'while' or
!      'do' loop or a '#pragma GCC ivdep', and applies only to the loop
       that follows.  N is an integer constant expression specifying the
       unrolling factor.  The values of 0 and 1 block any unrolling of the
       loop.
--- 57323,57333 ----
                a[i] = a[i + k] * c;
            }
  
! ‘#pragma GCC unroll N’
  
       You can use this pragma to control how many times a loop should be
!      unrolled.  It must be placed immediately before a ‘for’, ‘while’ or
!      ‘do’ loop or a ‘#pragma GCC ivdep’, and applies only to the loop
       that follows.  N is an integer constant expression specifying the
       unrolling factor.  The values of 0 and 1 block any unrolling of the
       loop.
*************** structures and unions without names.  Fo
*** 57343,57350 ****
       } foo;
  
  In this example, you are able to access members of the unnamed union
! with code like 'foo.b'.  Note that only unnamed structs and unions are
! allowed, you may not have, for example, an unnamed 'int'.
  
   You must never create such structures that cause ambiguous field
  definitions.  For example, in this structure:
--- 57352,57359 ----
       } foo;
  
  In this example, you are able to access members of the unnamed union
! with code like ‘foo.b’.  Note that only unnamed structs and unions are
! allowed, you may not have, for example, an unnamed ‘int’.
  
   You must never create such structures that cause ambiguous field
  definitions.  For example, in this structure:
*************** definitions.  For example, in this struc
*** 57356,57372 ****
         };
       } 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:
--- 57365,57381 ----
         };
       } 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:
*************** function calls.  For example:
*** 57376,57387 ****
       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; };
--- 57385,57396 ----
       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; };
*************** allocated such that there is one instanc
*** 57400,57421 ****
  thread.  The runtime model GCC uses to implement this originates in the
  IA-64 processor-specific ABI, but has since been migrated to other
  processors as well.  It requires significant support from the linker
! ('ld'), dynamic linker ('ld.so'), and system libraries ('libc.so' and
! 'libpthread.so'), so it is not available everywhere.
  
   At the user level, the extension is visible with a new storage class
! keyword: '__thread'.  For example:
  
       __thread int i;
       extern __thread struct state s;
       static __thread char *p;
  
!  The '__thread' specifier may be used alone, with the 'extern' or
! 'static' specifiers, but with no other storage class specifier.  When
! used with 'extern' or 'static', '__thread' must appear immediately after
  the other storage class specifier.
  
!  The '__thread' specifier may be applied to any global, file-scoped
  static, function-scoped static, or static data member of a class.  It
  may not be applied to block-scoped automatic or non-static data member.
  
--- 57409,57430 ----
  thread.  The runtime model GCC uses to implement this originates in the
  IA-64 processor-specific ABI, but has since been migrated to other
  processors as well.  It requires significant support from the linker
! (‘ld’), dynamic linker (‘ld.so’), and system libraries (‘libc.so’ and
! ‘libpthread.so’), so it is not available everywhere.
  
   At the user level, the extension is visible with a new storage class
! keyword: ‘__thread’.  For example:
  
       __thread int i;
       extern __thread struct state s;
       static __thread char *p;
  
!  The ‘__thread’ specifier may be used alone, with the ‘extern’ or
! ‘static’ specifiers, but with no other storage class specifier.  When
! used with ‘extern’ or ‘static’, ‘__thread’ must appear immediately after
  the other storage class specifier.
  
!  The ‘__thread’ specifier may be applied to any global, file-scoped
  static, function-scoped static, or static data member of a class.  It
  may not be applied to block-scoped automatic or non-static data member.
  
*************** File: gcc.info,  Node: C99 Thread-Local
*** 57451,57461 ****
  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
--- 57460,57470 ----
  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
*************** document the exact semantics of the lang
*** 57464,57500 ****
            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
--- 57473,57509 ----
            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
*************** File: gcc.info,  Node: C++98 Thread-Loca
*** 57505,57515 ****
  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.
  
--- 57514,57524 ----
  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.
  
*************** that document the exact semantics of the
*** 57519,57542 ****
            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
  
--- 57528,57551 ----
            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
  
*************** that document the exact semantics of the
*** 57545,57551 ****
            thread startup function.  An object of thread storage duration
            shall not require dynamic initialization.
  
!    * [basic.start.term]
  
       Add after paragraph 3
  
--- 57554,57560 ----
            thread startup function.  An object of thread storage duration
            shall not require dynamic initialization.
  
!    • [basic.start.term]
  
       Add after paragraph 3
  
*************** that document the exact semantics of the
*** 57554,57560 ****
            whose elements (directly or indirectly) have non-trivial
            destructors.
  
!    * [basic.stc]
  
       Add "thread storage duration" to the list in paragraph 1.
  
--- 57563,57569 ----
            whose elements (directly or indirectly) have non-trivial
            destructors.
  
!    • [basic.stc]
  
       Add "thread storage duration" to the list in paragraph 1.
  
*************** that document the exact semantics of the
*** 57563,57619 ****
            Thread, static, and automatic storage durations are associated
            with objects introduced by declarations [...].
  
!      Add '__thread' to the list of specifiers in paragraph 3.
  
!    * [basic.stc.thread]
  
       New section before [basic.stc.static]
  
!           The keyword '__thread' applied to a non-local object gives the
            object thread storage duration.
  
!           A local variable or class data member declared both 'static'
!           and '__thread' gives the variable or member thread storage
            duration.
  
!    * [basic.stc.static]
  
       Change paragraph 1
  
            All objects that have neither thread storage duration, dynamic
            storage duration nor are local [...].
  
!    * [dcl.stc]
  
!      Add '__thread' to the list in paragraph 1.
  
       Change paragraph 1
  
!           With the exception of '__thread', at most one
            STORAGE-CLASS-SPECIFIER shall appear in a given
!           DECL-SPECIFIER-SEQ.  The '__thread' specifier may be used
!           alone, or immediately following the 'extern' or 'static'
            specifiers.  [...]
  
       Add after paragraph 5
  
!           The '__thread' specifier can be applied only to the names of
            objects and to anonymous unions.
  
!    * [class.mem]
  
       Add after paragraph 6
  
!           Non-'static' members shall not be '__thread'.
  
  
  File: gcc.info,  Node: Binary constants,  Prev: Thread-Local,  Up: C Extensions
  
! 6.65 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).
  
--- 57572,57628 ----
            Thread, static, and automatic storage durations are associated
            with objects introduced by declarations [...].
  
!      Add ‘__thread’ to the list of specifiers in paragraph 3.
  
!    • [basic.stc.thread]
  
       New section before [basic.stc.static]
  
!           The keyword ‘__thread’ applied to a non-local object gives the
            object thread storage duration.
  
!           A local variable or class data member declared both ‘static’
!           and ‘__thread’ gives the variable or member thread storage
            duration.
  
!    • [basic.stc.static]
  
       Change paragraph 1
  
            All objects that have neither thread storage duration, dynamic
            storage duration nor are local [...].
  
!    • [dcl.stc]
  
!      Add ‘__thread’ to the list in paragraph 1.
  
       Change paragraph 1
  
!           With the exception of ‘__thread’, at most one
            STORAGE-CLASS-SPECIFIER shall appear in a given
!           DECL-SPECIFIER-SEQ.  The ‘__thread’ specifier may be used
!           alone, or immediately following the ‘extern’ or ‘static’
            specifiers.  [...]
  
       Add after paragraph 5
  
!           The ‘__thread’ specifier can be applied only to the names of
            objects and to anonymous unions.
  
!    • [class.mem]
  
       Add after paragraph 6
  
!           Non-‘static’ members shall not be ‘__thread’.
  
  
  File: gcc.info,  Node: Binary constants,  Prev: Thread-Local,  Up: C Extensions
  
! 6.65 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).
  
*************** particularly useful in environments that
*** 57625,57631 ****
       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.
  
  
--- 57634,57640 ----
       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.
  
  
*************** The GNU compiler provides these extensio
*** 57638,57645 ****
  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:
--- 57647,57654 ----
  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:
*************** programs: check for a predefined macro '
*** 57652,57658 ****
  * Template Instantiation:: Methods for ensuring that exactly one copy of
                          each needed template instantiation is emitted.
  * Bound member functions:: You can extract a function pointer to the
!                         method denoted by a '->*' or '.*' expression.
  * C++ Attributes::      Variable, function, and type attributes for C++ only.
  * Function Multiversioning::   Declaring multiple function versions.
  * Type Traits::         Compiler support for type traits.
--- 57661,57667 ----
  * Template Instantiation:: Methods for ensuring that exactly one copy of
                          each needed template instantiation is emitted.
  * Bound member functions:: You can extract a function pointer to the
!                         method denoted by a ‘->*’ or ‘.*’ expression.
  * C++ Attributes::      Variable, function, and type attributes for C++ only.
  * Function Multiversioning::   Declaring multiple function versions.
  * Type Traits::         Compiler support for type traits.
*************** File: gcc.info,  Node: Restricted Pointe
*** 57717,57725 ****
  ================================
  
  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
--- 57726,57734 ----
  ================================
  
  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.
*** 57730,57756 ****
         /* ... */
       }
  
! In the body of 'fn', RPTR points to an unaliased integer and RREF refers
  to a (different) unaliased integer.
  
   You may also specify whether a member function's THIS pointer is
! unaliased by using '__restrict__' as a member function qualifier.
  
       void T::fn () __restrict__
       {
         /* ... */
       }
  
! Within the body of 'T::fn', THIS has the effective definition 'T
! *__restrict__ const this'.  Notice that the interpretation of a
! '__restrict__' member function qualifier is different to that of 'const'
! or 'volatile' qualifier, in that it is applied to the pointer rather
  than the object.  This is consistent with other compilers that implement
  restricted pointers.
  
!  As with all outermost parameter qualifiers, '__restrict__' is ignored
  in function definition matching.  This means you only need to specify
! '__restrict__' in a function definition, rather than in a function
  prototype as well.
  
  
--- 57739,57765 ----
         /* ... */
       }
  
! In the body of ‘fn’, RPTR points to an unaliased integer and RREF refers
  to a (different) unaliased integer.
  
   You may also specify whether a member function's THIS pointer is
! unaliased by using ‘__restrict__’ as a member function qualifier.
  
       void T::fn () __restrict__
       {
         /* ... */
       }
  
! Within the body of ‘T::fn’, THIS has the effective definition ‘T
! *__restrict__ const this’.  Notice that the interpretation of a
! ‘__restrict__’ member function qualifier is different to that of ‘const’
! or ‘volatile’ qualifier, in that it is applied to the pointer rather
  than the object.  This is consistent with other compilers that implement
  restricted pointers.
  
!  As with all outermost parameter qualifiers, ‘__restrict__’ is ignored
  in function definition matching.  This means you only need to specify
! ‘__restrict__’ in a function definition, rather than in a function
  prototype as well.
  
  
*************** VTables
*** 57794,57807 ****
       Make sure that any inline virtuals are declared inline in the class
       body, even if they are not defined there.
  
! 'type_info' objects
       C++ requires information about types to be written out in order to
!      implement 'dynamic_cast', 'typeid' and exception handling.  For
       polymorphic classes (classes with virtual functions), the
!      'type_info' object is written out along with the vtable so that
!      'dynamic_cast' can determine the dynamic type of a class object at
!      run time.  For all other types, we write out the 'type_info' object
!      when it is used: when applying 'typeid' to an expression, throwing
       an object, or referring to a type in a catch clause or exception
       specification.
  
--- 57803,57816 ----
       Make sure that any inline virtuals are declared inline in the class
       body, even if they are not defined there.
  
! ‘type_info’ objects
       C++ requires information about types to be written out in order to
!      implement ‘dynamic_cast’, ‘typeid’ and exception handling.  For
       polymorphic classes (classes with virtual functions), the
!      ‘type_info’ object is written out along with the vtable so that
!      ‘dynamic_cast’ can determine the dynamic type of a class object at
!      run time.  For all other types, we write out the ‘type_info’ object
!      when it is used: when applying ‘typeid’ to an expression, throwing
       an object, or referring to a type in a catch clause or exception
       specification.
  
*************** File: gcc.info,  Node: C++ Interface,  N
*** 57834,57850 ****
  7.4 C++ Interface and Implementation Pragmas
  ============================================
  
! '#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:_ These '#pragma's have been superceded as of GCC 2.7.2 by 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.
  
! '#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
--- 57843,57859 ----
  7.4 C++ Interface and Implementation Pragmas
  ============================================
  
! ‘#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:_ These ‘#pragma’s have been superceded as of GCC 2.7.2 by 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.
  
! ‘#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
*************** unnecessary out-of-line copies of inline
*** 57852,57911 ****
       tables that implement virtual functions) must be kept in each
       object file that includes class definitions.  You can use this
       pragma to avoid such duplication.  When a header file containing
!      '#pragma interface' is included in a compilation, this auxiliary
       information is not generated (unless the main input source file
!      itself uses '#pragma implementation').  Instead, the object files
       contain references to be resolved at link time.
  
       The second form of this directive is useful for the case where you
       have multiple headers with the same name in different directories.
!      If you use this form, you must specify the same string to '#pragma
!      implementation'.
  
! '#pragma implementation'
! '#pragma implementation "OBJECTS.h"'
       Use this pragma in a _main input file_, when you want full output
       from included header files to be generated (and made globally
!      visible).  The included header file, in turn, should use '#pragma
!      interface'.  Backup copies of inline member functions, debugging
       information, and the internal tables used to implement virtual
       functions are all generated in implementation files.
  
!      If you use '#pragma implementation' with no argument, it applies to
       an include file with the same basename(1) as your source file.  For
!      example, in 'allclass.cc', giving just '#pragma implementation' by
!      itself is equivalent to '#pragma implementation "allclass.h"'.
  
       Use the string argument if you want a single implementation file to
       include code from multiple header files.  (You must also use
!      '#include' to include the header file; '#pragma implementation'
       only specifies how to use the file--it doesn't actually include
       it.)
  
       There is no way to split up the contents of a single header file
       into multiple implementation files.
  
!  '#pragma implementation' and '#pragma interface' also have an effect on
  function inlining.
  
!  If you define a class in a header file marked with '#pragma interface',
  the effect on an inline function defined in that class is similar to an
! explicit 'extern' declaration--the compiler emits no code at all to
  define an independent version of the function.  Its definition is used
  only for inlining with its callers.
  
   Conversely, when you include the same header file in a main source file
! that declares it as '#pragma implementation', the compiler emits code
  for the function itself; this defines a version of the function that can
  be found via pointers (or by callers compiled without inlining).  If all
  calls to the function can be inlined, you can avoid emitting the
! function by compiling with '-fno-implement-inlines'.  If any calls are
  not inlined, you will get linker errors.
  
     ---------- Footnotes ----------
  
!    (1) A file's "basename" is the name stripped of all leading path
! information and of trailing suffixes, such as '.h' or '.C' or '.cc'.
  
  
  File: gcc.info,  Node: Template Instantiation,  Next: Bound member functions,  Prev: C++ Interface,  Up: C++ Extensions
--- 57861,57920 ----
       tables that implement virtual functions) must be kept in each
       object file that includes class definitions.  You can use this
       pragma to avoid such duplication.  When a header file containing
!      ‘#pragma interface’ is included in a compilation, this auxiliary
       information is not generated (unless the main input source file
!      itself uses ‘#pragma implementation’).  Instead, the object files
       contain references to be resolved at link time.
  
       The second form of this directive is useful for the case where you
       have multiple headers with the same name in different directories.
!      If you use this form, you must specify the same string to ‘#pragma
!      implementation’.
  
! ‘#pragma implementation’
! ‘#pragma implementation "OBJECTS.h"’
       Use this pragma in a _main input file_, when you want full output
       from included header files to be generated (and made globally
!      visible).  The included header file, in turn, should use ‘#pragma
!      interface’.  Backup copies of inline member functions, debugging
       information, and the internal tables used to implement virtual
       functions are all generated in implementation files.
  
!      If you use ‘#pragma implementation’ with no argument, it applies to
       an include file with the same basename(1) as your source file.  For
!      example, in ‘allclass.cc’, giving just ‘#pragma implementation’ by
!      itself is equivalent to ‘#pragma implementation "allclass.h"’.
  
       Use the string argument if you want a single implementation file to
       include code from multiple header files.  (You must also use
!      ‘#include’ to include the header file; ‘#pragma implementation’
       only specifies how to use the file--it doesn't actually include
       it.)
  
       There is no way to split up the contents of a single header file
       into multiple implementation files.
  
!  ‘#pragma implementation’ and ‘#pragma interface’ also have an effect on
  function inlining.
  
!  If you define a class in a header file marked with ‘#pragma interface’,
  the effect on an inline function defined in that class is similar to an
! explicit ‘extern’ declaration--the compiler emits no code at all to
  define an independent version of the function.  Its definition is used
  only for inlining with its callers.
  
   Conversely, when you include the same header file in a main source file
! that declares it as ‘#pragma implementation’, the compiler emits code
  for the function itself; this defines a version of the function that can
  be found via pointers (or by callers compiled without inlining).  If all
  calls to the function can be inlined, you can avoid emitting the
! function by compiling with ‘-fno-implement-inlines’.  If any calls are
  not inlined, you will get linker errors.
  
     ---------- Footnotes ----------
  
!    (1) A file's “basename” is the name stripped of all leading path
! information and of trailing suffixes, such as ‘.h’ or ‘.C’ or ‘.cc’.
  
  
  File: gcc.info,  Node: Template Instantiation,  Next: Bound member functions,  Prev: C++ Interface,  Up: C++ Extensions
*************** instantiations:
*** 57970,57976 ****
       explicit instantiation in one object file, and preventing the
       compiler from doing implicit instantiations in any other object
       files by using an explicit instantiation declaration, using the
!      'extern template' syntax:
  
            extern template int max (int, int);
  
--- 57979,57985 ----
       explicit instantiation in one object file, and preventing the
       compiler from doing implicit instantiations in any other object
       files by using an explicit instantiation declaration, using the
!      ‘extern template’ syntax:
  
            extern template int max (int, int);
  
*************** instantiations:
*** 58001,58007 ****
       alternative and programs using this approach will work with most
       modern compilers.
  
!   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,
--- 58010,58016 ----
       alternative and programs using this approach will work with most
       modern compilers.
  
!   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,
*************** instantiations:
*** 58009,58029 ****
       ensure that only the intended instances are used.
  
       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.
  
       In addition to forward declaration of explicit instantiations (with
!      'extern'), G++ has extended the template instantiation syntax to
       support instantiation of the compiler support data for a template
       class (i.e. the vtable) without instantiating any of its members
!      (with 'inline'), and instantiation of only the static data members
       of a template class, without the support data or member functions
!      (with 'static'):
  
            inline template class Foo;
            static template class Foo;
--- 58018,58038 ----
       ensure that only the intended instances are used.
  
       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.
  
       In addition to forward declaration of explicit instantiations (with
!      ‘extern’), G++ has extended the template instantiation syntax to
       support instantiation of the compiler support data for a template
       class (i.e. the vtable) without instantiating any of its members
!      (with ‘inline’), and instantiation of only the static data members
       of a template class, without the support data or member functions
!      (with ‘static’):
  
            inline template class Foo;
            static template class Foo;
*************** File: gcc.info,  Node: Bound member func
*** 58036,58042 ****
  
  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
--- 58045,58051 ----
  
  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
*************** function calls.
*** 58057,58069 ****
  
       fptr p = (fptr)(a.*fp);
  
!  For PMF constants (i.e. expressions of the form '&Klasse::Member'), no
  object is needed to obtain the address of the function.  They can be
  converted to function pointers directly:
  
       fptr p1 = (fptr)(&A::foo);
  
!  You must specify '-Wno-pmf-conversions' to use this extension.
  
  
  File: gcc.info,  Node: C++ Attributes,  Next: Function Multiversioning,  Prev: Bound member functions,  Up: C++ Extensions
--- 58066,58078 ----
  
       fptr p = (fptr)(a.*fp);
  
!  For PMF constants (i.e. expressions of the form ‘&Klasse::Member’), no
  object is needed to obtain the address of the function.  They can be
  converted to function pointers directly:
  
       fptr p1 = (fptr)(&A::foo);
  
!  You must specify ‘-Wno-pmf-conversions’ to use this extension.
  
  
  File: gcc.info,  Node: C++ Attributes,  Next: Function Multiversioning,  Prev: Bound member functions,  Up: C++ Extensions
*************** File: gcc.info,  Node: C++ Attributes,
*** 58073,58080 ****
  
  Some attributes only make sense for C++ programs.
  
! 'abi_tag ("TAG", ...)'
!      The 'abi_tag' attribute can be applied to a function, variable, or
       class declaration.  It modifies the mangled name of the entity to
       incorporate the tag name, in order to distinguish the function or
       class from an earlier version with a different ABI; perhaps the
--- 58082,58089 ----
  
  Some attributes only make sense for C++ programs.
  
! ‘abi_tag ("TAG", ...)’
!      The ‘abi_tag’ attribute can be applied to a function, variable, or
       class declaration.  It modifies the mangled name of the entity to
       incorporate the tag name, in order to distinguish the function or
       class from an earlier version with a different ABI; perhaps the
*************** Some attributes only make sense for C++
*** 58083,58089 ****
  
       The attribute can also be applied to an inline namespace, but does
       not affect the mangled name of the namespace; in this case it is
!      only used for '-Wabi-tag' warnings and automatic tagging of
       functions and variables.  Tagging inline namespaces is generally
       preferable to tagging individual declarations, but the latter is
       sometimes necessary, such as when only certain members of a class
--- 58092,58098 ----
  
       The attribute can also be applied to an inline namespace, but does
       not affect the mangled name of the namespace; in this case it is
!      only used for ‘-Wabi-tag’ warnings and automatic tagging of
       functions and variables.  Tagging inline namespaces is generally
       preferable to tagging individual declarations, but the latter is
       sometimes necessary, such as when only certain members of a class
*************** Some attributes only make sense for C++
*** 58101,58107 ****
       will be ignored if applied to an explicit specialization or
       instantiation.
  
!      The '-Wabi-tag' flag enables a warning about a class which does not
       have all the ABI tags used by its subobjects and virtual functions;
       for users with code that needs to coexist with an earlier ABI,
       using this option can help to find all affected types that need to
--- 58110,58116 ----
       will be ignored if applied to an explicit specialization or
       instantiation.
  
!      The ‘-Wabi-tag’ flag enables a warning about a class which does not
       have all the ABI tags used by its subobjects and virtual functions;
       for users with code that needs to coexist with an earlier ABI,
       using this option can help to find all affected types that need to
*************** Some attributes only make sense for C++
*** 58110,58133 ****
       When a type involving an ABI tag is used as the type of a variable
       or return type of a function where that tag is not already present
       in the signature of the function, the tag is automatically applied
!      to the variable or function.  '-Wabi-tag' also warns about this
       situation; this warning can be avoided by explicitly tagging the
       variable or function or moving it into a tagged inline namespace.
  
! 'init_priority (PRIORITY)'
  
       In Standard C++, objects defined at namespace scope are guaranteed
       to be initialized in an order in strict accordance with that of
       their definitions _in a given translation unit_.  No guarantee is
       made for initializations across translation units.  However, GNU
       C++ allows users to control the order of initialization of objects
!      defined at namespace scope with the 'init_priority' attribute by
       specifying a relative PRIORITY, a constant integral expression
       currently bounded between 101 and 65535 inclusive.  Lower numbers
       indicate a higher priority.
  
!      In the following example, 'A' would normally be created before 'B',
!      but the 'init_priority' attribute reverses that order:
  
            Some_Class  A  __attribute__ ((init_priority (2000)));
            Some_Class  B  __attribute__ ((init_priority (543)));
--- 58119,58142 ----
       When a type involving an ABI tag is used as the type of a variable
       or return type of a function where that tag is not already present
       in the signature of the function, the tag is automatically applied
!      to the variable or function.  ‘-Wabi-tag’ also warns about this
       situation; this warning can be avoided by explicitly tagging the
       variable or function or moving it into a tagged inline namespace.
  
! ‘init_priority (PRIORITY)’
  
       In Standard C++, objects defined at namespace scope are guaranteed
       to be initialized in an order in strict accordance with that of
       their definitions _in a given translation unit_.  No guarantee is
       made for initializations across translation units.  However, GNU
       C++ allows users to control the order of initialization of objects
!      defined at namespace scope with the ‘init_priority’ attribute by
       specifying a relative PRIORITY, a constant integral expression
       currently bounded between 101 and 65535 inclusive.  Lower numbers
       indicate a higher priority.
  
!      In the following example, ‘A’ would normally be created before ‘B’,
!      but the ‘init_priority’ attribute reverses that order:
  
            Some_Class  A  __attribute__ ((init_priority (2000)));
            Some_Class  B  __attribute__ ((init_priority (543)));
*************** Some attributes only make sense for C++
*** 58135,58141 ****
       Note that the particular values of PRIORITY do not matter; only
       their relative ordering.
  
! 'warn_unused'
  
       For C++ types with non-trivial constructors and/or destructors it
       is impossible for the compiler to determine whether a variable of
--- 58144,58150 ----
       Note that the particular values of PRIORITY do not matter; only
       their relative ordering.
  
! ‘warn_unused’
  
       For C++ types with non-trivial constructors and/or destructors it
       is impossible for the compiler to determine whether a variable of
*************** Some attributes only make sense for C++
*** 58145,58152 ****
       fundamental types.
  
       This attribute is appropriate for types which just represent a
!      value, such as 'std::string'; it is not appropriate for types which
!      control a resource, such as 'std::lock_guard'.
  
       This attribute is also accepted in C, but it is unnecessary because
       C does not have constructors or destructors.
--- 58154,58161 ----
       fundamental types.
  
       This attribute is appropriate for types which just represent a
!      value, such as ‘std::string’; it is not appropriate for types which
!      control a resource, such as ‘std::lock_guard’.
  
       This attribute is also accepted in C, but it is unnecessary because
       C does not have constructors or destructors.
*************** compile-time determination of various ch
*** 58220,58356 ****
  pair of types).
  
   -- Built-in Function: bool __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-qualified 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.
  
   -- Built-in Function: bool __has_nothrow_copy (TYPE)
!      If '__has_trivial_copy (type)' is 'true' then the trait is 'true',
       else if TYPE is a cv-qualified 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.
  
   -- Built-in Function: bool __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.
  
   -- Built-in Function: bool __has_trivial_assign (TYPE)
!      If TYPE is 'const'- qualified or is a reference type then the trait
!      is 'false'.  Otherwise if '__is_trivial (type)' is 'true' then the
!      trait is 'true', else if TYPE is a cv-qualified 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.
  
   -- Built-in Function: bool __has_trivial_copy (TYPE)
!      If '__is_trivial (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.
  
   -- Built-in Function: bool __has_trivial_constructor (TYPE)
!      If '__is_trivial (type)' is 'true' then the trait is 'true', else
       if TYPE is a cv-qualified 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.
  
   -- Built-in Function: bool __has_trivial_destructor (TYPE)
!      If '__is_trivial (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.
  
   -- Built-in Function: bool __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: If TYPE is
       a non-union class type, it shall be a complete type.
  
   -- Built-in Function: bool __is_abstract (TYPE)
       If TYPE is an abstract class ([class.abstract]) then the trait is
!      'true', else it is 'false'.  Requires: If TYPE is a non-union class
       type, it shall be a complete type.
  
   -- Built-in Function: bool __is_aggregate (TYPE)
!      If TYPE is an aggregate type ([dcl.init.aggr]) the trait is 'true',
!      else it is 'false'.  Requires: If TYPE is a class type, it shall be
       a complete type.
  
   -- Built-in Function: bool __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.  A diagnostic is produced if this requirement is not
       met.
  
   -- Built-in Function: bool __is_class (TYPE)
       If TYPE is a cv-qualified class type, and not a union type
!      ([basic.compound]) the trait is 'true', else it is 'false'.
  
   -- Built-in Function: bool __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:
       If TYPE is a non-union class type, it shall be a complete type.
  
   -- Built-in Function: bool __is_enum (TYPE)
       If TYPE is a cv enumeration type ([basic.compound]) the trait is
!      'true', else it is 'false'.
  
   -- Built-in Function: bool __is_final (TYPE)
!      If TYPE is a class or union type marked 'final', then the trait is
!      'true', else it is 'false'.  Requires: If TYPE is a class type, it
       shall be a complete type.
  
   -- Built-in Function: bool __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.
  
   -- Built-in Function: bool __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.
  
   -- Built-in Function: bool __is_polymorphic (TYPE)
       If TYPE is a polymorphic class ([class.virtual]) then the trait is
!      'true', else it is 'false'.  Requires: If TYPE is a non-union class
       type, it shall be a complete type.
  
   -- Built-in Function: bool __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, an array of complete types, or (possibly cv-qualified)
!      'void'.
  
   -- Built-in Function: bool __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, an array
!      of complete types, or (possibly cv-qualified) 'void'.
  
   -- Built-in Function: bool __is_union (TYPE)
!      If TYPE is a cv union type ([basic.compound]) the trait is 'true',
!      else it is 'false'.
  
   -- Built-in Function: bool __underlying_type (TYPE)
       The underlying type of TYPE.  Requires: TYPE shall be an
--- 58229,58365 ----
  pair of types).
  
   -- Built-in Function: bool __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-qualified 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.
  
   -- Built-in Function: bool __has_nothrow_copy (TYPE)
!      If ‘__has_trivial_copy (type)’ is ‘true’ then the trait is ‘true’,
       else if TYPE is a cv-qualified 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.
  
   -- Built-in Function: bool __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.
  
   -- Built-in Function: bool __has_trivial_assign (TYPE)
!      If TYPE is ‘const’- qualified or is a reference type then the trait
!      is ‘false’.  Otherwise if ‘__is_trivial (type)’ is ‘true’ then the
!      trait is ‘true’, else if TYPE is a cv-qualified 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.
  
   -- Built-in Function: bool __has_trivial_copy (TYPE)
!      If ‘__is_trivial (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.
  
   -- Built-in Function: bool __has_trivial_constructor (TYPE)
!      If ‘__is_trivial (type)’ is ‘true’ then the trait is ‘true’, else
       if TYPE is a cv-qualified 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.
  
   -- Built-in Function: bool __has_trivial_destructor (TYPE)
!      If ‘__is_trivial (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.
  
   -- Built-in Function: bool __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: If TYPE is
       a non-union class type, it shall be a complete type.
  
   -- Built-in Function: bool __is_abstract (TYPE)
       If TYPE is an abstract class ([class.abstract]) then the trait is
!      ‘true’, else it is ‘false’.  Requires: If TYPE is a non-union class
       type, it shall be a complete type.
  
   -- Built-in Function: bool __is_aggregate (TYPE)
!      If TYPE is an aggregate type ([dcl.init.aggr]) the trait is ‘true’,
!      else it is ‘false’.  Requires: If TYPE is a class type, it shall be
       a complete type.
  
   -- Built-in Function: bool __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.  A diagnostic is produced if this requirement is not
       met.
  
   -- Built-in Function: bool __is_class (TYPE)
       If TYPE is a cv-qualified class type, and not a union type
!      ([basic.compound]) the trait is ‘true’, else it is ‘false’.
  
   -- Built-in Function: bool __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:
       If TYPE is a non-union class type, it shall be a complete type.
  
   -- Built-in Function: bool __is_enum (TYPE)
       If TYPE is a cv enumeration type ([basic.compound]) the trait is
!      ‘true’, else it is ‘false’.
  
   -- Built-in Function: bool __is_final (TYPE)
!      If TYPE is a class or union type marked ‘final’, then the trait is
!      ‘true’, else it is ‘false’.  Requires: If TYPE is a class type, it
       shall be a complete type.
  
   -- Built-in Function: bool __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.
  
   -- Built-in Function: bool __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.
  
   -- Built-in Function: bool __is_polymorphic (TYPE)
       If TYPE is a polymorphic class ([class.virtual]) then the trait is
!      ‘true’, else it is ‘false’.  Requires: If TYPE is a non-union class
       type, it shall be a complete type.
  
   -- Built-in Function: bool __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, an array of complete types, or (possibly cv-qualified)
!      ‘void’.
  
   -- Built-in Function: bool __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, an array
!      of complete types, or (possibly cv-qualified) ‘void’.
  
   -- Built-in Function: bool __is_union (TYPE)
!      If TYPE is a cv union type ([basic.compound]) the trait is ‘true’,
!      else it is ‘false’.
  
   -- Built-in Function: bool __underlying_type (TYPE)
       The underlying type of TYPE.  Requires: TYPE shall be an
*************** pair of types).
*** 58359,58366 ****
   -- Built-in Function: bool __integer_pack (LENGTH)
       When used as the pattern of a pack expansion within a template
       definition, expands to a template argument pack containing integers
!      from '0' to 'LENGTH-1'.  This is provided for efficient
!      implementation of 'std::make_integer_sequence'.
  
  
  File: gcc.info,  Node: C++ Concepts,  Next: Deprecated Features,  Prev: Type Traits,  Up: C++ Extensions
--- 58368,58375 ----
   -- Built-in Function: bool __integer_pack (LENGTH)
       When used as the pattern of a pack expansion within a template
       definition, expands to a template argument pack containing integers
!      from ‘0’ to ‘LENGTH-1’.  This is provided for efficient
!      implementation of ‘std::make_integer_sequence’.
  
  
  File: gcc.info,  Node: C++ Concepts,  Next: Deprecated Features,  Prev: Type Traits,  Up: C++ Extensions
*************** rather than their type names.
*** 58377,58399 ****
  
   The following keywords are reserved for concepts.
  
! 'assumes'
       States an expression as an assumption, and if possible, verifies
!      that the assumption is valid.  For example, 'assume(n > 0)'.
  
! 'axiom'
       Introduces an axiom definition.  Axioms introduce requirements on
       values.
  
! 'forall'
       Introduces a universally quantified object in an axiom.  For
!      example, 'forall (int n) n + 0 == n').
  
! 'concept'
       Introduces a concept definition.  Concepts are sets of syntactic
       and semantic requirements on types and their values.
  
! 'requires'
       Introduces constraints on template arguments or requirements for a
       member function of a class template.
  
--- 58386,58408 ----
  
   The following keywords are reserved for concepts.
  
! ‘assumes’
       States an expression as an assumption, and if possible, verifies
!      that the assumption is valid.  For example, ‘assume(n > 0)’.
  
! ‘axiom’
       Introduces an axiom definition.  Axioms introduce requirements on
       values.
  
! ‘forall’
       Introduces a universally quantified object in an axiom.  For
!      example, ‘forall (int n) n + 0 == n’).
  
! ‘concept’
       Introduces a concept definition.  Concepts are sets of syntactic
       and semantic requirements on types and their values.
  
! ‘requires’
       Introduces constraints on template arguments or requirements for a
       member function of a class template.
  
*************** used to simplify the writing of type tra
*** 58402,58408 ****
  traits are likely to be removed in the future.
  
   -- Built-in Function: bool __is_same (TYPE1, TYPE2)
!      A binary type trait: 'true' whenever the TYPE1 and TYPE2 refer to
       the same type.
  
  
--- 58411,58417 ----
  traits are likely to be removed in the future.
  
   -- Built-in Function: bool __is_same (TYPE1, TYPE2)
!      A binary type trait: ‘true’ whenever the TYPE1 and TYPE2 refer to
       the same type.
  
  
*************** superior alternatives.  Using the old fe
*** 58418,58424 ****
  some cases that the feature will be dropped in the future.  In other
  cases, the feature might be gone already.
  
!  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.
--- 58427,58433 ----
  some cases that the feature will be dropped in the future.  In other
  cases, the feature might be gone already.
  
!  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.
*************** and other places where they are not perm
*** 58428,58434 ****
  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
--- 58437,58443 ----
  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
*************** enumeration types so this extension has
*** 58438,58444 ****
  removed from a future version.
  
   G++ allows attributes to follow a parenthesized direct initializer,
! e.g. ' int f (0) __attribute__ ((something)); ' This extension has been
  ignored since G++ 3.3 and is deprecated.
  
   G++ allows anonymous structs and unions to have members that are not
--- 58447,58453 ----
  removed from a future version.
  
   G++ allows attributes to follow a parenthesized direct initializer,
! e.g. ‘ int f (0) __attribute__ ((something)); ’ This extension has been
  ignored since G++ 3.3 and is deprecated.
  
   G++ allows anonymous structs and unions to have members that are not
*************** backwards compatibilities.  _All such ba
*** 58460,58471 ****
  are liable to disappear in future versions of G++._  They should be
  considered deprecated.  *Note Deprecated Features::.
  
! 'Implicit C language'
!      Old C system header files did not contain an 'extern "C" {...}'
       scope to set the language.  On such systems, all system header
       files are implicitly scoped inside a C language scope.  Such
       headers must correctly prototype function argument types, there is
!      no leeway for '()' to indicate an unspecified set of arguments.
  
  
  File: gcc.info,  Node: Objective-C,  Next: Compatibility,  Prev: C++ Extensions,  Up: Top
--- 58469,58480 ----
  are liable to disappear in future versions of G++._  They should be
  considered deprecated.  *Note Deprecated Features::.
  
! ‘Implicit C language’
!      Old C system header files did not contain an ‘extern "C" {...}’
       scope to set the language.  On such systems, all system header
       files are implicitly scoped inside a C language scope.  Such
       headers must correctly prototype function argument types, there is
!      no leeway for ‘()’ to indicate an unspecified set of arguments.
  
  
  File: gcc.info,  Node: Objective-C,  Next: Compatibility,  Prev: C++ Extensions,  Up: Top
*************** provided by the "Objective-C 2.0" Apple/
*** 58527,58566 ****
  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
--- 58536,58575 ----
  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
*************** File: gcc.info,  Node: Traditional GNU O
*** 58575,58583 ****
  The GNU Objective-C runtime used to provide a different API, which we
  call the "traditional" GNU Objective-C runtime API. Functions belonging
  to this API are easy to recognize because they use a different naming
! convention, such as 'class_get_super_class()' (traditional API) instead
! of 'class_getSuperclass()' (modern API). Software using this API
! includes the file 'objc/objc-api.h' where it is declared.
  
   Starting with GCC 4.7.0, the traditional GNU runtime API is no longer
  available.
--- 58584,58592 ----
  The GNU Objective-C runtime used to provide a different API, which we
  call the "traditional" GNU Objective-C runtime API. Functions belonging
  to this API are easy to recognize because they use a different naming
! convention, such as ‘class_get_super_class()’ (traditional API) instead
! of ‘class_getSuperclass()’ (modern API). Software using this API
! includes the file ‘objc/objc-api.h’ where it is declared.
  
   Starting with GCC 4.7.0, the traditional GNU runtime API is no longer
  available.
*************** available.
*** 58585,58610 ****
  
  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;
--- 58594,58619 ----
  
  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;
*************** some cases could be too late.
*** 58624,58639 ****
       @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
--- 58633,58648 ----
       @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
*************** instead of '+initialize':
*** 58649,58662 ****
       @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:
  
--- 58658,58671 ----
       @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:
  
*************** of '+initialize'.
*** 58665,58719 ****
  
  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 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.
  
--- 58674,58728 ----
  
  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 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.
  
*************** selectors and methods and about objects
*** 58733,58766 ****
  
   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)
--- 58742,58775 ----
  
   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)
*************** bit closest to the beginning of the stru
*** 58781,58799 ****
  
   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:
--- 58790,58808 ----
  
   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:
*************** compiler on an i386 machine:
*** 58801,58815 ****
  
  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
                                              depends on the machine)
  
  
--- 58810,58824 ----
  
  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
                                              depends on the machine)
  
  
*************** specifiers:
*** 58820,58861 ****
  
  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:
  
--- 58829,58870 ----
  
  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:
  
*************** encoding code.  The NeXT runtime expects
*** 58874,58908 ****
  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.
  
  
--- 58883,58917 ----
  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.
  
  
*************** arguments.
*** 58928,58953 ****
  
   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.
  
  
--- 58937,58962 ----
  
   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.
  
  
*************** using a powerful conservative garbage co
*** 58964,58973 ****
  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
--- 58973,58982 ----
  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
*************** on where pointers are located inside obj
*** 58977,58990 ****
  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
--- 58986,58999 ----
  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:
*** 59024,59030 ****
  
  
   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.
  
--- 59033,59039 ----
  
  
   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 o
*** 59036,59055 ****
  
  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
--- 59045,59064 ----
  
  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
*************** to a strict structure, the same as 'NXCo
*** 59061,59085 ****
       @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,
--- 59070,59094 ----
       @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,
*************** this.
*** 59089,59111 ****
  
  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
--- 59098,59120 ----
  
  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
*************** in the following example:
*** 59140,59184 ****
           ...
         }
  
!  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
--- 59149,59193 ----
           ...
         }
  
!  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
*************** GNU Objective-C provides support for syn
*** 59192,59214 ****
           ...
         }
  
!  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
--- 59201,59223 ----
           ...
         }
  
!  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
*************** GNU Objective-C provides support for the
*** 59239,59257 ****
           /* 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;
--- 59248,59266 ----
           /* 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;
*************** A c99-like declaration syntax is also al
*** 59288,59294 ****
  
   but can save some typing.
  
!  Note that the option '-std=c99' is not required to allow this syntax in
  Objective-C.
  
  
--- 59297,59303 ----
  
   but can save some typing.
  
!  Note that the option ‘-std=c99’ is not required to allow this syntax in
  Objective-C.
  
  
*************** the code
*** 59307,59348 ****
  
   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.
  
  
--- 59316,59357 ----
  
   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.
  
  
*************** enumeration, you need to have it impleme
*** 59358,59364 ****
                                             objects: (id *)objects
                                               count: (unsigned long)len;
  
!  where 'NSFastEnumerationState' must be defined in your code as follows:
  
       typedef struct
       {
--- 59367,59373 ----
                                             objects: (id *)objects
                                               count: (unsigned long)len;
  
!  where ‘NSFastEnumerationState’ must be defined in your code as follows:
  
       typedef struct
       {
*************** enumeration, you need to have it impleme
*** 59368,59378 ****
         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
--- 59377,59387 ----
         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
*** 59380,59407 ****
  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
--- 59389,59416 ----
  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
*** 59409,59417 ****
  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
--- 59418,59426 ----
  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
*************** designed to be portable, and so is based
*** 59427,59443 ****
  
   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:
--- 59436,59452 ----
  
   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:
*************** File: gcc.info,  Node: Dynamically regis
*** 59451,59457 ****
  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.
  
--- 59460,59466 ----
  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.
  
*************** the method
*** 59466,59487 ****
  
   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.
  
  
--- 59475,59496 ----
  
   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,
*** 59491,59543 ****
  ----------------------
  
  The GNU Objective-C runtime provides a hook, called
! '__objc_msg_forward2', which is called by 'objc_msg_lookup()' when it
  cannot find a method implementation in the runtime tables and after
! calling '+resolveInstanceMethod:' and '+resolveClassMethod:' has been
  attempted and did not succeed in dynamically registering the method.
  
   To configure the hook, you set the global variable
! '__objc_msg_forward2' to a function with the same argument and return
! types of 'objc_msg_lookup()'.  When 'objc_msg_lookup()' cannot 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.
--- 59500,59552 ----
  ----------------------
  
  The GNU Objective-C runtime provides a hook, called
! ‘__objc_msg_forward2’, which is called by ‘objc_msg_lookup()’ when it
  cannot find a method implementation in the runtime tables and after
! calling ‘+resolveInstanceMethod:’ and ‘+resolveClassMethod:’ has been
  attempted and did not succeed in dynamically registering the method.
  
   To configure the hook, you set the global variable
! ‘__objc_msg_forward2’ to a function with the same argument and return
! types of ‘objc_msg_lookup()’.  When ‘objc_msg_lookup()’ cannot 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,  N
*** 59550,59556 ****
  
  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
--- 59559,59565 ----
  
  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
*************** Binary compatibility encompasses several
*** 59558,59564 ****
       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
--- 59567,59573 ----
       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
*************** Binary compatibility encompasses several
*** 59566,59576 ****
       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
--- 59575,59585 ----
       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
*************** Binary compatibility encompasses several
*** 59579,59597 ****
       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.
--- 59588,59606 ----
       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.
*************** Binary compatibility encompasses several
*** 59599,59618 ****
   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
--- 59608,59627 ----
   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
*************** GCC releases, but it is possible that we
*** 59635,59641 ****
  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++
--- 59644,59650 ----
  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++
*************** with those compilers can be used in the
*** 59654,59660 ****
  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
  
--- 59663,59669 ----
  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
  
*************** files for that other library.
*** 59666,59690 ****
  
   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: Gcov-tool,  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:
--- 59675,59699 ----
  
   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: Gcov-tool,  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:
*************** coverage in your programs.
*** 59700,59729 ****
  
  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.
--- 59709,59738 ----
  
  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.
*************** to be added to the testsuites to create
*** 59734,59743 ****
  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
--- 59743,59752 ----
  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 wh
*** 59745,59808 ****
  your complex macros behave like functions, you can replace them with
  inline functions to solve this problem.
  
!  'gcov' creates a logfile called 'SOURCEFILE.gcov' which indicates how
! many times each line of a source file 'SOURCEFILE.c' has executed.  You
! can use these logfiles along with 'gprof' to aid in fine-tuning the
! performance of your programs.  'gprof' gives timing information you can
! use along with the information you get from 'gcov'.
  
!  'gcov' works only on code compiled with GCC.  It is not compatible with
  any other profiling or test coverage mechanism.
  
  
  File: gcc.info,  Node: Invoking Gcov,  Next: Gcov and Optimization,  Prev: Gcov Intro,  Up: Gcov
  
! 10.2 Invoking 'gcov'
  ====================
  
       gcov [OPTIONS] FILES
  
!  'gcov' accepts the following options:
  
! '-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.
  
! '-d'
! '--display-progress'
       Display the progress on the standard output.
  
! '-f'
! '--function-summaries'
       Output summaries for each function in addition to the file level
       summary.
  
! '-h'
! '--help'
!      Display help about using 'gcov' (on the standard output), and exit
       without doing any further processing.
  
! '-j'
! '--json-format'
       Output gcov file in an easy-to-parse JSON intermediate format which
       does not require source code for generation.  The JSON file is
       compressed with gzip compression algorithm and the files have
!      '.gcov.json.gz' extension.
  
       Structure of the JSON is following:
  
--- 59754,59817 ----
  your complex macros behave like functions, you can replace them with
  inline functions to solve this problem.
  
!  ‘gcov’ creates a logfile called ‘SOURCEFILE.gcov’ which indicates how
! many times each line of a source file ‘SOURCEFILE.c’ has executed.  You
! can use these logfiles along with ‘gprof’ to aid in fine-tuning the
! performance of your programs.  ‘gprof’ gives timing information you can
! use along with the information you get from ‘gcov’.
  
!  ‘gcov’ works only on code compiled with GCC.  It is not compatible with
  any other profiling or test coverage mechanism.
  
  
  File: gcc.info,  Node: Invoking Gcov,  Next: Gcov and Optimization,  Prev: Gcov Intro,  Up: Gcov
  
! 10.2 Invoking ‘gcov’
  ====================
  
       gcov [OPTIONS] FILES
  
!  ‘gcov’ accepts the following options:
  
! ‘-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.
  
! ‘-d’
! ‘--display-progress’
       Display the progress on the standard output.
  
! ‘-f’
! ‘--function-summaries’
       Output summaries for each function in addition to the file level
       summary.
  
! ‘-h’
! ‘--help’
!      Display help about using ‘gcov’ (on the standard output), and exit
       without doing any further processing.
  
! ‘-j’
! ‘--json-format’
       Output gcov file in an easy-to-parse JSON intermediate format which
       does not require source code for generation.  The JSON file is
       compressed with gzip compression algorithm and the files have
!      ‘.gcov.json.gz’ extension.
  
       Structure of the JSON is following:
  
*************** File: gcc.info,  Node: Invoking Gcov,  N
*** 59816,59829 ****
  
       Fields of the root element have following semantics:
  
!         * CURRENT_WORKING_DIRECTORY: working directory where a
            compilation unit was compiled
  
!         * DATA_FILE: name of the data file (GCDA)
  
!         * FORMAT_VERSION: semantic version of the format
  
!         * GCC_VERSION: version of the GCC compiler
  
       Each FILE has the following form:
  
--- 59825,59838 ----
  
       Fields of the root element have following semantics:
  
!         • CURRENT_WORKING_DIRECTORY: working directory where a
            compilation unit was compiled
  
!         • DATA_FILE: name of the data file (GCDA)
  
!         • FORMAT_VERSION: semantic version of the format
  
!         • GCC_VERSION: version of the GCC compiler
  
       Each FILE has the following form:
  
*************** File: gcc.info,  Node: Invoking Gcov,  N
*** 59835,59841 ****
  
       Fields of the FILE element have following semantics:
  
!         * FILE_NAME: name of the source file
  
       Each FUNCTION has the following form:
  
--- 59844,59850 ----
  
       Fields of the FILE element have following semantics:
  
!         • FILE_NAME: name of the source file
  
       Each FUNCTION has the following form:
  
*************** File: gcc.info,  Node: Invoking Gcov,  N
*** 59853,59876 ****
  
       Fields of the FUNCTION element have following semantics:
  
!         * BLOCKS: number of blocks that are in the function
  
!         * BLOCKS_EXECUTED: number of executed blocks of the function
  
!         * DEMANGLED_NAME: demangled name of the function
  
!         * END_COLUMN: column in the source file where the function ends
  
!         * END_LINE: line in the source file where the function ends
  
!         * EXECUTION_COUNT: number of executions of the function
  
!         * NAME: name of the function
  
!         * START_COLUMN: column in the source file where the function
            begins
  
!         * START_LINE: line in the source file where the function begins
  
       Note that line numbers and column numbers number from 1.  In the
       current implementation, START_LINE and START_COLUMN do not include
--- 59862,59885 ----
  
       Fields of the FUNCTION element have following semantics:
  
!         • BLOCKS: number of blocks that are in the function
  
!         • BLOCKS_EXECUTED: number of executed blocks of the function
  
!         • DEMANGLED_NAME: demangled name of the function
  
!         • END_COLUMN: column in the source file where the function ends
  
!         • END_LINE: line in the source file where the function ends
  
!         • EXECUTION_COUNT: number of executions of the function
  
!         • NAME: name of the function
  
!         • START_COLUMN: column in the source file where the function
            begins
  
!         • START_LINE: line in the source file where the function begins
  
       Note that line numbers and column numbers number from 1.  In the
       current implementation, START_LINE and START_COLUMN do not include
*************** File: gcc.info,  Node: Invoking Gcov,  N
*** 59890,59903 ****
       Branches are present only with -B option.  Fields of the LINE
       element have following semantics:
  
!         * COUNT: number of executions of the line
  
!         * LINE_NUMBER: line number
  
!         * UNEXECUTED_BLOCK: flag whether the line contains an unexecuted
            block (not all statements on the line are executed)
  
!         * FUNCTION_NAME: a name of a function this LINE belongs to (for
            a line with an inlined statements can be not set)
  
       Each BRANCH has the following form:
--- 59899,59912 ----
       Branches are present only with -B option.  Fields of the LINE
       element have following semantics:
  
!         • COUNT: number of executions of the line
  
!         • LINE_NUMBER: line number
  
!         • UNEXECUTED_BLOCK: flag whether the line contains an unexecuted
            block (not all statements on the line are executed)
  
!         • FUNCTION_NAME: a name of a function this LINE belongs to (for
            a line with an inlined statements can be not set)
  
       Each BRANCH has the following form:
*************** File: gcc.info,  Node: Invoking Gcov,  N
*** 59910,59986 ****
  
       Fields of the BRANCH element have following semantics:
  
!         * COUNT: number of executions of the branch
  
!         * FALLTHROUGH: true when the branch is a fall through branch
  
!         * THROW: true when the branch is an exceptional branch
  
! '-H'
! '--human-readable'
       Write counts in human readable format (like 24.6k).
  
! '-k'
! '--use-colors'
  
       Use colors for lines of code that have zero coverage.  We use red
       color for non-exceptional lines and cyan for exceptional.  Same
!      colors are used for basic blocks with '-a' option.
  
! '-l'
! '--long-file-names'
       Create long file names for included source files.  For example, if
!      the header file 'x.h' contains code, and was included in the file
!      'a.c', then running 'gcov' on the file 'a.c' will produce an output
!      file called 'a.c##x.h.gcov' instead of 'x.h.gcov'.  This can be
!      useful if 'x.h' is included in multiple source files and you want
!      to see the individual contributions.  If you use the '-p' option,
       both the including and included file names will be complete path
       names.
  
! '-m'
! '--demangled-names'
       Display demangled function names in output.  The default is to show
       mangled function names.
  
! '-n'
! '--no-output'
!      Do not create the 'gcov' output file.
  
! '-o DIRECTORY|FILE'
! '--object-directory DIRECTORY'
! '--object-file FILE'
       Specify either the directory containing the gcov data files, or the
!      object path name.  The '.gcno', and '.gcda' data files are searched
       for using this option.  If a directory is specified, the data files
       are in that directory and named after the input file name, without
       its extension.  If a file is specified here, the data files are
       named after that file, without its extension.
  
! '-p'
! '--preserve-paths'
       Preserve complete path information in the names of generated
!      '.gcov' files.  Without this option, just the filename component is
!      used.  With this option, all directories are used, with '/'
!      characters translated to '#' characters, '.' directory components
!      removed and unremoveable '..' components renamed to '^'.  This is
       useful if sourcefiles are in several different directories.
  
! '-q'
! '--use-hotness-colors'
  
       Emit perf-like colored output for hot lines.  Legend of the color
       scale is printed at the very beginning of the output file.
  
! '-r'
! '--relative-only'
       Only output information about source files with a relative pathname
       (after source prefix elision).  Absolute paths are usually system
       header files and coverage of any inline functions therein is
       normally uninteresting.
  
! '-s DIRECTORY'
! '--source-prefix DIRECTORY'
       A prefix for source file names to remove when generating the output
       coverage files.  This option is useful when building in a separate
       directory, and the pathname to the source directory is not wanted
--- 59919,59995 ----
  
       Fields of the BRANCH element have following semantics:
  
!         • COUNT: number of executions of the branch
  
!         • FALLTHROUGH: true when the branch is a fall through branch
  
!         • THROW: true when the branch is an exceptional branch
  
! ‘-H’
! ‘--human-readable’
       Write counts in human readable format (like 24.6k).
  
! ‘-k’
! ‘--use-colors’
  
       Use colors for lines of code that have zero coverage.  We use red
       color for non-exceptional lines and cyan for exceptional.  Same
!      colors are used for basic blocks with ‘-a’ option.
  
! ‘-l’
! ‘--long-file-names’
       Create long file names for included source files.  For example, if
!      the header file ‘x.h’ contains code, and was included in the file
!      ‘a.c’, then running ‘gcov’ on the file ‘a.c’ will produce an output
!      file called ‘a.c##x.h.gcov’ instead of ‘x.h.gcov’.  This can be
!      useful if ‘x.h’ is included in multiple source files and you want
!      to see the individual contributions.  If you use the ‘-p’ option,
       both the including and included file names will be complete path
       names.
  
! ‘-m’
! ‘--demangled-names’
       Display demangled function names in output.  The default is to show
       mangled function names.
  
! ‘-n’
! ‘--no-output’
!      Do not create the ‘gcov’ output file.
  
! ‘-o DIRECTORY|FILE’
! ‘--object-directory DIRECTORY’
! ‘--object-file FILE’
       Specify either the directory containing the gcov data files, or the
!      object path name.  The ‘.gcno’, and ‘.gcda’ data files are searched
       for using this option.  If a directory is specified, the data files
       are in that directory and named after the input file name, without
       its extension.  If a file is specified here, the data files are
       named after that file, without its extension.
  
! ‘-p’
! ‘--preserve-paths’
       Preserve complete path information in the names of generated
!      ‘.gcov’ files.  Without this option, just the filename component is
!      used.  With this option, all directories are used, with ‘/’
!      characters translated to ‘#’ characters, ‘.’ directory components
!      removed and unremoveable ‘..’ components renamed to ‘^’.  This is
       useful if sourcefiles are in several different directories.
  
! ‘-q’
! ‘--use-hotness-colors’
  
       Emit perf-like colored output for hot lines.  Legend of the color
       scale is printed at the very beginning of the output file.
  
! ‘-r’
! ‘--relative-only’
       Only output information about source files with a relative pathname
       (after source prefix elision).  Absolute paths are usually system
       header files and coverage of any inline functions therein is
       normally uninteresting.
  
! ‘-s DIRECTORY’
! ‘--source-prefix DIRECTORY’
       A prefix for source file names to remove when generating the output
       coverage files.  This option is useful when building in a separate
       directory, and the pathname to the source directory is not wanted
*************** File: gcc.info,  Node: Invoking Gcov,  N
*** 59988,60056 ****
       detection is applied before determining whether the source file is
       absolute.
  
! '-t'
! '--stdout'
       Output to standard output instead of output files.
  
! '-u'
! '--unconditional-branches'
       When branch probabilities are given, include those of unconditional
       branches.  Unconditional branches are normally not interesting.
  
! '-v'
! '--version'
!      Display the 'gcov' version number (on the standard output), and
       exit without doing any further processing.
  
! '-w'
! '--verbose'
       Print verbose informations related to basic blocks and arcs.
  
! '-x'
! '--hash-filenames'
       When using -PRESERVE-PATHS, gcov uses the full pathname of the
       source files to create an output filename.  This can lead to long
       filenames that can overflow filesystem limits.  This option creates
!      names of the form 'SOURCE-FILE##MD5.gcov', where the SOURCE-FILE
       component is the final filename part and the MD5 component is
       calculated from the full mangled name that would have been used
       otherwise.  The option is an alternative to the -PRESERVE-PATHS on
       systems which have a filesystem limit.
  
!  'gcov' should be run with the current directory the same as that when
  you invoked the compiler.  Otherwise it will not be able to locate the
! source files.  'gcov' produces files called 'MANGLEDNAME.gcov' in the
  current directory.  These contain the coverage information of the source
! file they correspond to.  One '.gcov' file is produced for each source
  (or header) file containing code, which was compiled to produce the data
  files.  The MANGLEDNAME part of the output file name is usually simply
! the source file name, but can be something more complicated if the '-l'
! or '-p' options are given.  Refer to those options for details.
  
!  If you invoke 'gcov' with multiple input files, the contributions from
  each input file are summed.  Typically you would invoke it with the same
  list of files as the final link of your executable.
  
!  The '.gcov' files contain the ':' separated fields along with program
  source code.  The format is
  
       EXECUTION_COUNT:LINE_NUMBER:SOURCE LINE TEXT
  
   Additional block information may succeed each line, when requested by
! command line option.  The EXECUTION_COUNT is '-' for lines containing no
! code.  Unexecuted lines are marked '#####' or '=====', depending on
  whether they are reachable by non-exceptional paths or only exceptional
! paths such as C++ exception handlers, respectively.  Given the '-a'
! option, unexecuted blocks are marked '$$$$$' or '%%%%%', depending on
  whether a basic block is reachable via non-exceptional or exceptional
  paths.  Executed basic blocks having a statement with zero
! EXECUTION_COUNT end with '*' character and are colored with magenta
! color with the '-k' option.  This functionality is not supported in Ada.
  
   Note that GCC can completely remove the bodies of functions that are
  not needed - for instance if they are inlined everywhere.  Such
! functions are marked with '-', which can be confusing.  Use the
! '-fkeep-inline-functions' and '-fkeep-static-functions' options to
  retain these functions and allow gcov to properly show their
  EXECUTION_COUNT.
  
--- 59997,60065 ----
       detection is applied before determining whether the source file is
       absolute.
  
! ‘-t’
! ‘--stdout’
       Output to standard output instead of output files.
  
! ‘-u’
! ‘--unconditional-branches’
       When branch probabilities are given, include those of unconditional
       branches.  Unconditional branches are normally not interesting.
  
! ‘-v’
! ‘--version’
!      Display the ‘gcov’ version number (on the standard output), and
       exit without doing any further processing.
  
! ‘-w’
! ‘--verbose’
       Print verbose informations related to basic blocks and arcs.
  
! ‘-x’
! ‘--hash-filenames’
       When using -PRESERVE-PATHS, gcov uses the full pathname of the
       source files to create an output filename.  This can lead to long
       filenames that can overflow filesystem limits.  This option creates
!      names of the form ‘SOURCE-FILE##MD5.gcov’, where the SOURCE-FILE
       component is the final filename part and the MD5 component is
       calculated from the full mangled name that would have been used
       otherwise.  The option is an alternative to the -PRESERVE-PATHS on
       systems which have a filesystem limit.
  
!  ‘gcov’ should be run with the current directory the same as that when
  you invoked the compiler.  Otherwise it will not be able to locate the
! source files.  ‘gcov’ produces files called ‘MANGLEDNAME.gcov’ in the
  current directory.  These contain the coverage information of the source
! file they correspond to.  One ‘.gcov’ file is produced for each source
  (or header) file containing code, which was compiled to produce the data
  files.  The MANGLEDNAME part of the output file name is usually simply
! the source file name, but can be something more complicated if the ‘-l’
! or ‘-p’ options are given.  Refer to those options for details.
  
!  If you invoke ‘gcov’ with multiple input files, the contributions from
  each input file are summed.  Typically you would invoke it with the same
  list of files as the final link of your executable.
  
!  The ‘.gcov’ files contain the ‘:’ separated fields along with program
  source code.  The format is
  
       EXECUTION_COUNT:LINE_NUMBER:SOURCE LINE TEXT
  
   Additional block information may succeed each line, when requested by
! command line option.  The EXECUTION_COUNT is ‘-’ for lines containing no
! code.  Unexecuted lines are marked ‘#####’ or ‘=====’, depending on
  whether they are reachable by non-exceptional paths or only exceptional
! paths such as C++ exception handlers, respectively.  Given the ‘-a’
! option, unexecuted blocks are marked ‘$$$$$’ or ‘%%%%%’, depending on
  whether a basic block is reachable via non-exceptional or exceptional
  paths.  Executed basic blocks having a statement with zero
! EXECUTION_COUNT end with ‘*’ character and are colored with magenta
! color with the ‘-k’ option.  This functionality is not supported in Ada.
  
   Note that GCC can completely remove the bodies of functions that are
  not needed - for instance if they are inlined everywhere.  Such
! functions are marked with ‘-’, which can be confusing.  Use the
! ‘-fkeep-inline-functions’ and ‘-fkeep-static-functions’ options to
  retain these functions and allow gcov to properly show their
  EXECUTION_COUNT.
  
*************** preamble lines are of the form
*** 60060,60066 ****
       -: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
--- 60069,60075 ----
       -: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
*************** are _exactly_ 0% and 100% respectively.
*** 60075,60095 ****
  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 a special
! GCC option '--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.cpp', this is
! what you see when you use the basic 'gcov' facility:
  
       $ g++ --coverage tmp.cpp -c
       $ g++ --coverage tmp.o
--- 60084,60104 ----
  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 a special
! GCC option ‘--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.cpp’, this is
! what you see when you use the basic ‘gcov’ facility:
  
       $ g++ --coverage tmp.cpp -c
       $ g++ --coverage tmp.o
*************** what you see when you use the basic 'gco
*** 60099,60105 ****
       Lines executed:92.86% of 14
       Creating 'tmp.cpp.gcov'
  
!  The file 'tmp.cpp.gcov' contains output from 'gcov'.  Here is a sample:
  
               -:    0:Source:tmp.cpp
               -:    0:Working directory:/home/gcc/testcase
--- 60108,60114 ----
       Lines executed:92.86% of 14
       Creating 'tmp.cpp.gcov'
  
!  The file ‘tmp.cpp.gcov’ contains output from ‘gcov’.  Here is a sample:
  
               -:    0:Source:tmp.cpp
               -:    0:Working directory:/home/gcc/testcase
*************** two belong to instances of class Foo con
*** 60165,60171 ****
  line 30 contains some unexecuted basic blocks and thus execution count
  has asterisk symbol.
  
!  When you use the '-a' option, you will get individual block counts, and
  the output looks like this:
  
               -:    0:Source:tmp.cpp
--- 60174,60180 ----
  line 30 contains some unexecuted basic blocks and thus execution count
  has asterisk symbol.
  
!  When you use the ‘-a’ option, you will get individual block counts, and
  the output looks like this:
  
               -:    0:Source:tmp.cpp
*************** contain code, unless previous blocks end
*** 60246,60258 ****
  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 33
  contains a basic block that was not executed.
  
!  When you use the '-b' option, your output looks like this:
  
               -:    0:Source:tmp.cpp
               -:    0:Working directory:/home/gcc/testcase
--- 60255,60267 ----
  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 33
  contains a basic block that was not executed.
  
!  When you use the ‘-b’ option, your output looks like this:
  
               -:    0:Source:tmp.cpp
               -:    0:Working directory:/home/gcc/testcase
*************** message "never executed" is printed.
*** 60359,60369 ****
   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
--- 60368,60378 ----
   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
*** 60371,60379 ****
  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.
--- 60380,60388 ----
  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.
*************** new execution counts and finally writes
*** 60381,60391 ****
  
  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 a special GCC option '--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
--- 60390,60400 ----
  
  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 a special GCC option ‘--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
*************** For example, code like this:
*** 60398,60406 ****
         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)
--- 60407,60415 ----
         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)
*************** shown depends on where the function is i
*** 60420,60429 ****
  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
--- 60429,60438 ----
  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
*************** now be calculable at compile time in som
*** 60436,60491 ****
  coverage of all the uses of the inline function will be shown for the
  same source lines, the line counts themselves might seem inconsistent.
  
!  Long-running applications can use the '__gcov_reset' and '__gcov_dump'
  facilities to restrict profile collection to the program region of
! interest.  Calling '__gcov_reset(void)' will clear all run-time profile
! counters to zero, and calling '__gcov_dump(void)' will cause the profile
! information collected at that point to be dumped to '.gcda' output
  files.  Instrumented applications use a static destructor with priority
! 99 to invoke the '__gcov_dump' function.  Thus '__gcov_dump' is executed
  after all user defined static destructors, as well as handlers
! registered with 'atexit'.
  
   If an executable loads a dynamic shared object via dlopen
! functionality, '-Wl,--dynamic-list-data' is needed to dump all profile
  data.
  
   Profiling run-time library reports various errors related to profile
  manipulation and profile saving.  Errors are printed into standard error
! output or 'GCOV_ERROR_FILE' file, if environment variable is used.  In
  order to terminate immediately after an errors occurs set
! 'GCOV_EXIT_AT_ERROR' environment variable.  That can help users to find
  profile clashing which leads to a misleading profile.
  
  
  File: gcc.info,  Node: Gcov Data Files,  Next: Cross-profiling,  Prev: Gcov and Optimization,  Up: Gcov
  
! 10.4 Brief Description of 'gcov' Data Files
  ===========================================
  
! 'gcov' uses two files for profiling.  The names of these files are
  derived from the original _object_ file by substituting the file suffix
! with either '.gcno', or '.gcda'.  The files contain coverage and profile
! data stored in a platform-independent format.  The '.gcno' files are
  placed in the same directory as the object file.  By default, the
! '.gcda' files are also stored in the same directory as the object file,
! but the GCC '-fprofile-dir' option may be used to store the '.gcda'
  files in a separate directory.
  
!  The '.gcno' notes file is generated when the source file is compiled
! with the GCC '-ftest-coverage' option.  It contains information to
  reconstruct the basic block graphs and assign source line numbers to
  blocks.
  
!  The '.gcda' count data file is generated when a program containing
! object files built with the GCC '-fprofile-arcs' option is executed.  A
! separate '.gcda' file is created for each object file compiled with this
  option.  It contains arc transition counts, value profile counts, and
  some summary information.
  
   It is not recommended to access the coverage files directly.  Consumers
! should use the intermediate format that is provided by 'gcov' tool via
! '--json-format' option.
  
  
  File: gcc.info,  Node: Cross-profiling,  Next: Freestanding Environments,  Prev: Gcov Data Files,  Up: Gcov
--- 60445,60500 ----
  coverage of all the uses of the inline function will be shown for the
  same source lines, the line counts themselves might seem inconsistent.
  
!  Long-running applications can use the ‘__gcov_reset’ and ‘__gcov_dump’
  facilities to restrict profile collection to the program region of
! interest.  Calling ‘__gcov_reset(void)’ will clear all run-time profile
! counters to zero, and calling ‘__gcov_dump(void)’ will cause the profile
! information collected at that point to be dumped to ‘.gcda’ output
  files.  Instrumented applications use a static destructor with priority
! 99 to invoke the ‘__gcov_dump’ function.  Thus ‘__gcov_dump’ is executed
  after all user defined static destructors, as well as handlers
! registered with ‘atexit’.
  
   If an executable loads a dynamic shared object via dlopen
! functionality, ‘-Wl,--dynamic-list-data’ is needed to dump all profile
  data.
  
   Profiling run-time library reports various errors related to profile
  manipulation and profile saving.  Errors are printed into standard error
! output or ‘GCOV_ERROR_FILE’ file, if environment variable is used.  In
  order to terminate immediately after an errors occurs set
! ‘GCOV_EXIT_AT_ERROR’ environment variable.  That can help users to find
  profile clashing which leads to a misleading profile.
  
  
  File: gcc.info,  Node: Gcov Data Files,  Next: Cross-profiling,  Prev: Gcov and Optimization,  Up: Gcov
  
! 10.4 Brief Description of ‘gcov’ Data Files
  ===========================================
  
! ‘gcov’ uses two files for profiling.  The names of these files are
  derived from the original _object_ file by substituting the file suffix
! with either ‘.gcno’, or ‘.gcda’.  The files contain coverage and profile
! data stored in a platform-independent format.  The ‘.gcno’ files are
  placed in the same directory as the object file.  By default, the
! ‘.gcda’ files are also stored in the same directory as the object file,
! but the GCC ‘-fprofile-dir’ option may be used to store the ‘.gcda’
  files in a separate directory.
  
!  The ‘.gcno’ notes file is generated when the source file is compiled
! with the GCC ‘-ftest-coverage’ option.  It contains information to
  reconstruct the basic block graphs and assign source line numbers to
  blocks.
  
!  The ‘.gcda’ count data file is generated when a program containing
! object files built with the GCC ‘-fprofile-arcs’ option is executed.  A
! separate ‘.gcda’ file is created for each object file compiled with this
  option.  It contains arc transition counts, value profile counts, and
  some summary information.
  
   It is not recommended to access the coverage files directly.  Consumers
! should use the intermediate format that is provided by ‘gcov’ tool via
! ‘--json-format’ option.
  
  
  File: gcc.info,  Node: Cross-profiling,  Next: Freestanding Environments,  Prev: Gcov Data Files,  Up: Gcov
*************** File: gcc.info,  Node: Cross-profiling,
*** 60494,60531 ****
  ====================================================
  
  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 ('-fprofile-use'), or to use
! the 'gcov' tool.
  
  
  File: gcc.info,  Node: Freestanding Environments,  Prev: Cross-profiling,  Up: Gcov
--- 60503,60540 ----
  ====================================================
  
  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 (‘-fprofile-use’), or to use
! the ‘gcov’ tool.
  
  
  File: gcc.info,  Node: Freestanding Environments,  Prev: Cross-profiling,  Up: Gcov
*************** then this section is likely not relevant
*** 60538,60546 ****
  intended for application developers targeting freestanding environments
  (for example embedded systems) with limited resources.  In particular,
  systems or test cases which do not support constructors/destructors or
! the C library file I/O. In this section, the "target system" runs your
  application instrumented for profiling or test coverage.  You develop
! and analyze your application on the "host system".  We now provide an
  overview how profiling and test coverage can be obtained in this
  scenario followed by a tutorial which can be exercised on the host
  system.  Finally, some system initialization caveats are listed.
--- 60547,60555 ----
  intended for application developers targeting freestanding environments
  (for example embedded systems) with limited resources.  In particular,
  systems or test cases which do not support constructors/destructors or
! the C library file I/O. In this section, the “target system” runs your
  application instrumented for profiling or test coverage.  You develop
! and analyze your application on the “host system”.  We now provide an
  overview how profiling and test coverage can be obtained in this
  scenario followed by a tutorial which can be exercised on the host
  system.  Finally, some system initialization caveats are listed.
*************** system.  Finally, some system initializa
*** 60551,60563 ****
  For an application instrumented for profiling or test coverage, the
  compiler generates some global data structures which are updated by
  instrumentation code while the application runs.  These data structures
! are called the "gcov information".  Normally, when the application
! exits, the gcov information is stored to '.gcda' files.  There is one
  file per translation unit instrumented for profiling or test coverage.
! The function '__gcov_exit()', which stores the gcov information to a
  file, is called by a global destructor function for each translation
  unit instrumented for profiling or test coverage.  It runs at process
! exit.  In a global constructor function, the '__gcov_init()' function is
  called to register the gcov information of a translation unit in a
  global list.  In some situations, this procedure does not work.
  Firstly, if you want to profile the global constructor or exit
--- 60560,60572 ----
  For an application instrumented for profiling or test coverage, the
  compiler generates some global data structures which are updated by
  instrumentation code while the application runs.  These data structures
! are called the “gcov information”.  Normally, when the application
! exits, the gcov information is stored to ‘.gcda’ files.  There is one
  file per translation unit instrumented for profiling or test coverage.
! The function ‘__gcov_exit()’, which stores the gcov information to a
  file, is called by a global destructor function for each translation
  unit instrumented for profiling or test coverage.  It runs at process
! exit.  In a global constructor function, the ‘__gcov_init()’ function is
  called to register the gcov information of a translation unit in a
  global list.  In some situations, this procedure does not work.
  Firstly, if you want to profile the global constructor or exit
*************** parts of the system initialization or ab
*** 60567,60578 ****
  do not allow a global constructor or exit processing.  Thirdly, you need
  a filesystem to store the files.
  
!  The '-fprofile-info-section' GCC option enables you to use profiling
  and test coverage in freestanding environments.  This option disables
  the use of global constructors and destructors for the gcov information.
  Instead, a pointer to the gcov information is stored in a special linker
  input section for each translation unit which is compiled with this
! option.  By default, the section name is '.gcov_info'.  The gcov
  information is statically initialized.  The pointers to the gcov
  information from all translation units of an executable can be collected
  by the linker in a contiguous memory block.  For the GNU linker, the
--- 60576,60587 ----
  do not allow a global constructor or exit processing.  Thirdly, you need
  a filesystem to store the files.
  
!  The ‘-fprofile-info-section’ GCC option enables you to use profiling
  and test coverage in freestanding environments.  This option disables
  the use of global constructors and destructors for the gcov information.
  Instead, a pointer to the gcov information is stored in a special linker
  input section for each translation unit which is compiled with this
! option.  By default, the section name is ‘.gcov_info’.  The gcov
  information is statically initialized.  The pointers to the gcov
  information from all translation units of an executable can be collected
  by the linker in a contiguous memory block.  For the GNU linker, the
*************** this:
*** 60586,60594 ****
           PROVIDE (__gcov_info_end = .);
         }
  
!  The linker will provide two global symbols, '__gcov_info_start' and
! '__gcov_info_end', which define the start and end of the array of
! pointers to gcov information blocks, respectively.  The 'KEEP ()'
  directive is required to prevent a garbage collection of the pointers.
  They are not directly referenced by anything in the executable.  The
  section may be placed in a read-only memory area.
--- 60595,60603 ----
           PROVIDE (__gcov_info_end = .);
         }
  
!  The linker will provide two global symbols, ‘__gcov_info_start’ and
! ‘__gcov_info_end’, which define the start and end of the array of
! pointers to gcov information blocks, respectively.  The ‘KEEP ()’
  directive is required to prevent a garbage collection of the pointers.
  They are not directly referenced by anything in the executable.  The
  section may be placed in a read-only memory area.
*************** target to the host system, the applicati
*** 60598,60608 ****
  produce a reliable in order byte stream from the target to the host.
  The byte stream may be compressed and encoded using error detection and
  correction codes to meet application-specific requirements.  The GCC
! provided 'libgcov' target library provides two functions,
! '__gcov_info_to_gcda()' and '__gcov_filename_to_gcfn()', to generate a
  byte stream from a gcov information bock.  The functions are declared in
! '#include '.  The byte stream can be deserialized by the
! 'merge-stream' subcommand of the 'gcov-tool' to create or update '.gcda'
  files in the host filesystem for the instrumented application.
  
  10.6.2 Tutorial
--- 60607,60617 ----
  produce a reliable in order byte stream from the target to the host.
  The byte stream may be compressed and encoded using error detection and
  correction codes to meet application-specific requirements.  The GCC
! provided ‘libgcov’ target library provides two functions,
! ‘__gcov_info_to_gcda()’ and ‘__gcov_filename_to_gcfn()’, to generate a
  byte stream from a gcov information bock.  The functions are declared in
! ‘#include ’.  The byte stream can be deserialized by the
! ‘merge-stream’ subcommand of the ‘gcov-tool’ to create or update ‘.gcda’
  files in the host filesystem for the instrumented application.
  
  10.6.2 Tutorial
*************** files in the host filesystem for the ins
*** 60610,60634 ****
  
  This tutorial should be exercised on the host system.  We will build a
  program instrumented for test coverage.  The program runs an application
! and dumps the gcov information to 'stderr' encoded as a printable
  character stream.  The application simply decodes such character streams
! from 'stdin' and writes the decoded character stream to 'stdout'
  (warning: this is binary data).  The decoded character stream is
! consumed by the 'merge-stream' subcommand of the 'gcov-tool' to create
! or update the '.gcda' files.
  
   To get started, create an empty directory.  Change into the new
  directory.  Then you will create the following three files in this
  directory
  
!   1. 'app.h' - a header file included by 'app.c' and 'main.c',
  
!   2. 'app.c' - a source file which contains an example application, and
  
!   3. 'main.c' - a source file which contains the program main function
       and code to dump the gcov information.
  
!  Firstly, create the header file 'app.h' with the following content:
  
       static const unsigned char a = 'a';
  
--- 60619,60643 ----
  
  This tutorial should be exercised on the host system.  We will build a
  program instrumented for test coverage.  The program runs an application
! and dumps the gcov information to ‘stderr’ encoded as a printable
  character stream.  The application simply decodes such character streams
! from ‘stdin’ and writes the decoded character stream to ‘stdout’
  (warning: this is binary data).  The decoded character stream is
! consumed by the ‘merge-stream’ subcommand of the ‘gcov-tool’ to create
! or update the ‘.gcda’ files.
  
   To get started, create an empty directory.  Change into the new
  directory.  Then you will create the following three files in this
  directory
  
!   1. ‘app.h’ - a header file included by ‘app.c’ and ‘main.c’,
  
!   2. ‘app.c’ - a source file which contains an example application, and
  
!   3. ‘main.c’ - a source file which contains the program main function
       and code to dump the gcov information.
  
!  Firstly, create the header file ‘app.h’ with the following content:
  
       static const unsigned char a = 'a';
  
*************** directory
*** 60642,60648 ****
  
       extern void application (void);
  
!  Secondly, create the source file 'app.c' with the following content:
  
       #include "app.h"
  
--- 60651,60657 ----
  
       extern void application (void);
  
!  Secondly, create the source file ‘app.c’ with the following content:
  
       #include "app.h"
  
*************** directory
*** 60681,60687 ****
           }
       }
  
!  Thirdly, create the source file 'main.c' with the following content:
  
       #include "app.h"
  
--- 60690,60696 ----
           }
       }
  
!  Thirdly, create the source file ‘main.c’ with the following content:
  
       #include "app.h"
  
*************** directory
*** 60762,60772 ****
         return 0;
       }
  
!  If we compile 'app.c' with test coverage and no extra profiling
! options, then a global constructor ('_sub_I_00100_0' here, it may have a
! different name in your environment) and destructor ('_sub_D_00100_1') is
  used to register and dump the gcov information, respectively.  We also
! see undefined references to '__gcov_init' and '__gcov_exit':
  
       $ gcc --coverage -c app.c
       $ nm app.o
--- 60771,60781 ----
         return 0;
       }
  
!  If we compile ‘app.c’ with test coverage and no extra profiling
! options, then a global constructor (‘_sub_I_00100_0’ here, it may have a
! different name in your environment) and destructor (‘_sub_D_00100_1’) is
  used to register and dump the gcov information, respectively.  We also
! see undefined references to ‘__gcov_init’ and ‘__gcov_exit’:
  
       $ gcc --coverage -c app.c
       $ nm app.o
*************** see undefined references to '__gcov_init
*** 60787,60796 ****
       0000000000000161 t _sub_D_00100_1
       0000000000000151 t _sub_I_00100_0
  
!  Compile 'app.c' and 'main.c' with test coverage and
! '-fprofile-info-section'.  Now, a read-only pointer size object is
! present in the '.gcov_info' section and there are no undefined
! references to '__gcov_init' and '__gcov_exit':
  
       $ gcc --coverage -fprofile-info-section -c main.c
       $ gcc --coverage -fprofile-info-section -c app.c
--- 60796,60805 ----
       0000000000000161 t _sub_D_00100_1
       0000000000000151 t _sub_I_00100_0
  
!  Compile ‘app.c’ and ‘main.c’ with test coverage and
! ‘-fprofile-info-section’.  Now, a read-only pointer size object is
! present in the ‘.gcov_info’ section and there are no undefined
! references to ‘__gcov_init’ and ‘__gcov_exit’:
  
       $ gcc --coverage -fprofile-info-section -c main.c
       $ gcc --coverage -fprofile-info-section -c app.c
*************** references to '__gcov_init' and '__gcov_
*** 60818,60840 ****
                         CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  
   We have to customize the program link procedure so that all the
! '.gcov_info' linker input sections are placed in a contiguous memory
  block with a begin and end symbol.  Firstly, get the default linker
  script using the following commands (we assume a GNU linker):
  
       $ ld --verbose | sed '1,/^===/d' | sed '/^===/d' > linkcmds
  
!  Secondly, open the file 'linkcmds' with a text editor and place the
! linker output section definition from the overview after the '.rodata'
  section definition.  Link the program executable using the customized
  linker script:
  
       $ gcc --coverage main.o app.o -T linkcmds -Wl,-Map,app.map
  
!  In the linker map file 'app.map', we see that the linker placed the
! read-only pointer size objects of our objects files 'main.o' and 'app.o'
  into a contiguous memory block and provided the symbols
! '__gcov_info_start' and '__gcov_info_end':
  
       $ grep -C 1 "\.gcov_info" app.map
  
--- 60827,60849 ----
                         CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
  
   We have to customize the program link procedure so that all the
! ‘.gcov_info’ linker input sections are placed in a contiguous memory
  block with a begin and end symbol.  Firstly, get the default linker
  script using the following commands (we assume a GNU linker):
  
       $ ld --verbose | sed '1,/^===/d' | sed '/^===/d' > linkcmds
  
!  Secondly, open the file ‘linkcmds’ with a text editor and place the
! linker output section definition from the overview after the ‘.rodata’
  section definition.  Link the program executable using the customized
  linker script:
  
       $ gcc --coverage main.o app.o -T linkcmds -Wl,-Map,app.map
  
!  In the linker map file ‘app.map’, we see that the linker placed the
! read-only pointer size objects of our objects files ‘main.o’ and ‘app.o’
  into a contiguous memory block and provided the symbols
! ‘__gcov_info_start’ and ‘__gcov_info_end’:
  
       $ grep -C 1 "\.gcov_info" app.map
  
*************** into a contiguous memory block and provi
*** 60845,60855 ****
        .gcov_info     0x0000000000403ac8        0x8 app.o
                       0x0000000000403ad0                PROVIDE (__gcov_info_end = .)
  
!  Make sure no '.gcda' files are present.  Run the program with nothing
! to decode and dump 'stderr' to the file 'gcda-0.txt' (first run).  Run
! the program to decode 'gcda-0.txt' and send it to the 'gcov-tool' using
! the 'merge-stream' subcommand to create the '.gcda' files (second run).
! Run 'gcov' to produce a report for 'app.c'.  We see that the first run
  with nothing to decode results in a partially covered application:
  
       $ rm -f app.gcda main.gcda
--- 60854,60864 ----
        .gcov_info     0x0000000000403ac8        0x8 app.o
                       0x0000000000403ad0                PROVIDE (__gcov_info_end = .)
  
!  Make sure no ‘.gcda’ files are present.  Run the program with nothing
! to decode and dump ‘stderr’ to the file ‘gcda-0.txt’ (first run).  Run
! the program to decode ‘gcda-0.txt’ and send it to the ‘gcov-tool’ using
! the ‘merge-stream’ subcommand to create the ‘.gcda’ files (second run).
! Run ‘gcov’ to produce a report for ‘app.c’.  We see that the first run
  with nothing to decode results in a partially covered application:
  
       $ rm -f app.gcda main.gcda
*************** with nothing to decode results in a part
*** 60865,60873 ****
  
       Lines executed:69.23% of 13
  
!  Run the program to decode 'gcda-1.txt' and send it to the 'gcov-tool'
! using the 'merge-stream' subcommand to update the '.gcda' files.  Run
! 'gcov' to produce a report for 'app.c'.  Since the second run decoded
  the gcov information of the first run, we have now a fully covered
  application:
  
--- 60874,60882 ----
  
       Lines executed:69.23% of 13
  
!  Run the program to decode ‘gcda-1.txt’ and send it to the ‘gcov-tool’
! using the ‘merge-stream’ subcommand to update the ‘.gcda’ files.  Run
! ‘gcov’ to produce a report for ‘app.c’.  Since the second run decoded
  the gcov information of the first run, we have now a fully covered
  application:
  
*************** flow graph edge counters in a zero-initi
*** 60891,60897 ****
  safe to run instrumented code before the zero-initialized data is
  cleared to zero.  The coverage information obtained before the
  zero-initialized data is cleared to zero is unusable.  Dumping the gcov
! information using '__gcov_info_to_gcda()' before the zero-initialized
  data is cleared to zero or the initialized data is loaded, is undefined
  behaviour.  Clearing the zero-initialized data to zero through a
  function instrumented for profiling or test coverage is undefined
--- 60900,60906 ----
  safe to run instrumented code before the zero-initialized data is
  cleared to zero.  The coverage information obtained before the
  zero-initialized data is cleared to zero is unusable.  Dumping the gcov
! information using ‘__gcov_info_to_gcda()’ before the zero-initialized
  data is cleared to zero or the initialized data is loaded, is undefined
  behaviour.  Clearing the zero-initialized data to zero through a
  function instrumented for profiling or test coverage is undefined
*************** counters for example.
*** 60901,60910 ****
  
  File: gcc.info,  Node: Gcov-tool,  Next: Gcov-dump,  Prev: Gcov,  Up: Top
  
! 11 'gcov-tool'--an Offline Gcda Profile Processing Tool
  *******************************************************
  
! 'gcov-tool' is a tool you can use in conjunction with GCC to manipulate
  or process gcda profile files offline.
  
  * Menu:
--- 60910,60919 ----
  
  File: gcc.info,  Node: Gcov-tool,  Next: Gcov-dump,  Prev: Gcov,  Up: Top
  
! 11 ‘gcov-tool’--an Offline Gcda Profile Processing Tool
  *******************************************************
  
! ‘gcov-tool’ is a tool you can use in conjunction with GCC to manipulate
  or process gcda profile files offline.
  
  * Menu:
*************** or process gcda profile files offline.
*** 60915,61055 ****
  
  File: gcc.info,  Node: Gcov-tool Intro,  Next: Invoking Gcov-tool,  Up: Gcov-tool
  
! 11.1 Introduction to 'gcov-tool'
  ================================
  
! 'gcov-tool' is an offline tool to process gcc's gcda profile files.
  
   Current gcov-tool supports the following functionalities:
  
!    * merge two sets of profiles with weights.
  
!    * read a stream of profiles with associated filenames and merge it
       with a set of profiles with weights.
  
!    * read one set of profile and rewrite profile contents.  One can
       scale or normalize the count values.
  
   Examples of the use cases for this tool are:
!    * Collect the profiles for different set of inputs, and use this tool
       to merge them.  One can specify the weight to factor in the
       relative importance of each input.
  
!    * Collect profiles from target systems without a filesystem
       (freestanding environments).  Merge the collected profiles with
       associated profiles present on the host system.  One can specify
       the weight to factor in the relative importance of each input.
  
!    * Rewrite the profile after removing a subset of the gcda files,
       while maintaining the consistency of the summary and the histogram.
  
!    * It can also be used to debug or libgcov code as the tools shares
       the majority code as the runtime library.
  
   Note that for the merging operation, this profile generated offline may
  contain slight different values from the online merged profile.  Here
  are a list of typical differences:
  
!    * histogram difference: This offline tool recomputes the histogram
       after merging the counters.  The resulting histogram, therefore, is
       precise.  The online merging does not have this capability - the
       histogram is merged from two histograms and the result is an
       approximation.
  
!    * summary checksum difference: Summary checksum uses a CRC32
       operation.  The value depends on the link list order of gcov-info
       objects.  This order is different in gcov-tool from that in the
       online merge.  It's expected to have different summary checksums.
       It does not really matter as the compiler does not use this
       checksum anywhere.
  
!    * value profile counter values difference: Some counter values for
       value profile are runtime dependent, like heap addresses.  It's
       normal to see some difference in these kind of counters.
  
  
  File: gcc.info,  Node: Invoking Gcov-tool,  Prev: Gcov-tool Intro,  Up: Gcov-tool
  
! 11.2 Invoking 'gcov-tool'
  =========================
  
       gcov-tool [GLOBAL-OPTIONS] SUB_COMMAND [SUB_COMMAND-OPTIONS] PROFILE_DIR
  
!  'gcov-tool' accepts the following options:
  
! '-h'
! '--help'
!      Display help about using 'gcov-tool' (on the standard output), and
       exit without doing any further processing.
  
! '-v'
! '--version'
!      Display the 'gcov-tool' version number (on the standard output),
       and exit without doing any further processing.
  
! 'merge'
       Merge two profile directories.
  
!      '-o DIRECTORY'
!      '--output DIRECTORY'
            Set the output profile directory.  Default output directory
            name is MERGED_PROFILE.
  
!      '-v'
!      '--verbose'
            Set the verbose mode.
  
!      '-w W1,W2'
!      '--weight W1,W2'
            Set the merge weights of the DIRECTORY1 and DIRECTORY2,
            respectively.  The default weights are 1 for both.
  
! 'merge-stream'
       Collect profiles with associated filenames from a _gcfn_ and _gcda_
       data stream.  Read the stream from the file specified by FILE or
!      from 'stdin'.  Merge the profiles with associated profiles in the
       host filesystem.  Apply the optional weights while merging
       profiles.
  
       For the generation of a _gcfn_ and _gcda_ data stream on the target
!      system, please have a look at the '__gcov_filename_to_gcfn()' and
!      '__gcov_info_to_gcda()' functions declared in '#include '.
  
!      '-v'
!      '--verbose'
            Set the verbose mode.
  
!      '-w W1,W2'
!      '--weight W1,W2'
            Set the merge weights of the profiles from the _gcfn_ and
            _gcda_ data stream and the associated profiles in the host
            filesystem, respectively.  The default weights are 1 for both.
  
! 'rewrite'
       Read the specified profile directory and rewrite to a new
       directory.
  
!      '-n LONG_LONG_VALUE'
!      '--normalize '
            Normalize the profile.  The specified value is the max counter
            value in the new profile.
  
!      '-o DIRECTORY'
!      '--output DIRECTORY'
            Set the output profile directory.  Default output name is
            REWRITE_PROFILE.
  
!      '-s FLOAT_OR_SIMPLE-FRAC_VALUE'
!      '--scale FLOAT_OR_SIMPLE-FRAC_VALUE'
            Scale the profile counters.  The specified value can be in
            floating point value, or simple fraction value form, such 1,
            2, 2/3, and 5/3.
  
!      '-v'
!      '--verbose'
            Set the verbose mode.
  
! 'overlap'
       Compute the overlap score between the two specified profile
       directories.  The overlap score is computed based on the arc
       profiles.  It is defined as the sum of min (p1_counter[i] /
--- 60924,61064 ----
  
  File: gcc.info,  Node: Gcov-tool Intro,  Next: Invoking Gcov-tool,  Up: Gcov-tool
  
! 11.1 Introduction to ‘gcov-tool’
  ================================
  
! ‘gcov-tool’ is an offline tool to process gcc's gcda profile files.
  
   Current gcov-tool supports the following functionalities:
  
!    • merge two sets of profiles with weights.
  
!    • read a stream of profiles with associated filenames and merge it
       with a set of profiles with weights.
  
!    • read one set of profile and rewrite profile contents.  One can
       scale or normalize the count values.
  
   Examples of the use cases for this tool are:
!    • Collect the profiles for different set of inputs, and use this tool
       to merge them.  One can specify the weight to factor in the
       relative importance of each input.
  
!    • Collect profiles from target systems without a filesystem
       (freestanding environments).  Merge the collected profiles with
       associated profiles present on the host system.  One can specify
       the weight to factor in the relative importance of each input.
  
!    • Rewrite the profile after removing a subset of the gcda files,
       while maintaining the consistency of the summary and the histogram.
  
!    • It can also be used to debug or libgcov code as the tools shares
       the majority code as the runtime library.
  
   Note that for the merging operation, this profile generated offline may
  contain slight different values from the online merged profile.  Here
  are a list of typical differences:
  
!    • histogram difference: This offline tool recomputes the histogram
       after merging the counters.  The resulting histogram, therefore, is
       precise.  The online merging does not have this capability - the
       histogram is merged from two histograms and the result is an
       approximation.
  
!    • summary checksum difference: Summary checksum uses a CRC32
       operation.  The value depends on the link list order of gcov-info
       objects.  This order is different in gcov-tool from that in the
       online merge.  It's expected to have different summary checksums.
       It does not really matter as the compiler does not use this
       checksum anywhere.
  
!    • value profile counter values difference: Some counter values for
       value profile are runtime dependent, like heap addresses.  It's
       normal to see some difference in these kind of counters.
  
  
  File: gcc.info,  Node: Invoking Gcov-tool,  Prev: Gcov-tool Intro,  Up: Gcov-tool
  
! 11.2 Invoking ‘gcov-tool’
  =========================
  
       gcov-tool [GLOBAL-OPTIONS] SUB_COMMAND [SUB_COMMAND-OPTIONS] PROFILE_DIR
  
!  ‘gcov-tool’ accepts the following options:
  
! ‘-h’
! ‘--help’
!      Display help about using ‘gcov-tool’ (on the standard output), and
       exit without doing any further processing.
  
! ‘-v’
! ‘--version’
!      Display the ‘gcov-tool’ version number (on the standard output),
       and exit without doing any further processing.
  
! ‘merge’
       Merge two profile directories.
  
!      ‘-o DIRECTORY’
!      ‘--output DIRECTORY’
            Set the output profile directory.  Default output directory
            name is MERGED_PROFILE.
  
!      ‘-v’
!      ‘--verbose’
            Set the verbose mode.
  
!      ‘-w W1,W2’
!      ‘--weight W1,W2’
            Set the merge weights of the DIRECTORY1 and DIRECTORY2,
            respectively.  The default weights are 1 for both.
  
! ‘merge-stream’
       Collect profiles with associated filenames from a _gcfn_ and _gcda_
       data stream.  Read the stream from the file specified by FILE or
!      from ‘stdin’.  Merge the profiles with associated profiles in the
       host filesystem.  Apply the optional weights while merging
       profiles.
  
       For the generation of a _gcfn_ and _gcda_ data stream on the target
!      system, please have a look at the ‘__gcov_filename_to_gcfn()’ and
!      ‘__gcov_info_to_gcda()’ functions declared in ‘#include ’.
  
!      ‘-v’
!      ‘--verbose’
            Set the verbose mode.
  
!      ‘-w W1,W2’
!      ‘--weight W1,W2’
            Set the merge weights of the profiles from the _gcfn_ and
            _gcda_ data stream and the associated profiles in the host
            filesystem, respectively.  The default weights are 1 for both.
  
! ‘rewrite’
       Read the specified profile directory and rewrite to a new
       directory.
  
!      ‘-n LONG_LONG_VALUE’
!      ‘--normalize ’
            Normalize the profile.  The specified value is the max counter
            value in the new profile.
  
!      ‘-o DIRECTORY’
!      ‘--output DIRECTORY’
            Set the output profile directory.  Default output name is
            REWRITE_PROFILE.
  
!      ‘-s FLOAT_OR_SIMPLE-FRAC_VALUE’
!      ‘--scale FLOAT_OR_SIMPLE-FRAC_VALUE’
            Scale the profile counters.  The specified value can be in
            floating point value, or simple fraction value form, such 1,
            2, 2/3, and 5/3.
  
!      ‘-v’
!      ‘--verbose’
            Set the verbose mode.
  
! ‘overlap’
       Compute the overlap score between the two specified profile
       directories.  The overlap score is computed based on the arc
       profiles.  It is defined as the sum of min (p1_counter[i] /
*************** File: gcc.info,  Node: Invoking Gcov-too
*** 61058,61091 ****
       p1_sum_all and p2_sum_all are the sum of counter values in profile
       1 and profile 2, respectively.
  
!      '-f'
!      '--function'
            Print function level overlap score.
  
!      '-F'
!      '--fullname'
            Print full gcda filename.
  
!      '-h'
!      '--hotonly'
            Only print info for hot objects/functions.
  
!      '-o'
!      '--object'
            Print object level overlap score.
  
!      '-t FLOAT'
!      '--hot_threshold '
            Set the threshold for hot counter value.
  
!      '-v'
!      '--verbose'
            Set the verbose mode.
  
  
  File: gcc.info,  Node: Gcov-dump,  Next: lto-dump,  Prev: Gcov-tool,  Up: Top
  
! 12 'gcov-dump'--an Offline Gcda and Gcno Profile Dump Tool
  **********************************************************
  
  * Menu:
--- 61067,61100 ----
       p1_sum_all and p2_sum_all are the sum of counter values in profile
       1 and profile 2, respectively.
  
!      ‘-f’
!      ‘--function’
            Print function level overlap score.
  
!      ‘-F’
!      ‘--fullname’
            Print full gcda filename.
  
!      ‘-h’
!      ‘--hotonly’
            Only print info for hot objects/functions.
  
!      ‘-o’
!      ‘--object’
            Print object level overlap score.
  
!      ‘-t FLOAT’
!      ‘--hot_threshold ’
            Set the threshold for hot counter value.
  
!      ‘-v’
!      ‘--verbose’
            Set the verbose mode.
  
  
  File: gcc.info,  Node: Gcov-dump,  Next: lto-dump,  Prev: Gcov-tool,  Up: Top
  
! 12 ‘gcov-dump’--an Offline Gcda and Gcno Profile Dump Tool
  **********************************************************
  
  * Menu:
*************** File: gcc.info,  Node: Gcov-dump,  Next:
*** 61096,61147 ****
  
  File: gcc.info,  Node: Gcov-dump Intro,  Next: Invoking Gcov-dump,  Up: Gcov-dump
  
! 12.1 Introduction to 'gcov-dump'
  ================================
  
! 'gcov-dump' is a tool you can use in conjunction with GCC to dump
  content of gcda and gcno profile files offline.
  
  
  File: gcc.info,  Node: Invoking Gcov-dump,  Prev: Gcov-dump Intro,  Up: Gcov-dump
  
! 12.2 Invoking 'gcov-dump'
  =========================
  
       Usage: gcov-dump [OPTION] ... GCOVFILES
  
!  'gcov-dump' accepts the following options:
  
! '-h'
! '--help'
!      Display help about using 'gcov-dump' (on the standard output), and
       exit without doing any further processing.
  
! '-l'
! '--long'
       Dump content of records.
  
! '-p'
! '--positions'
       Dump positions of records.
  
! '-r'
! '--raw'
       Print content records in raw format.
  
! '-s'
! '--stable'
       Print content in stable format usable for comparison.
  
! '-v'
! '--version'
!      Display the 'gcov-dump' version number (on the standard output),
       and exit without doing any further processing.
  
  
  File: gcc.info,  Node: lto-dump,  Next: Trouble,  Prev: Gcov-dump,  Up: Top
  
! 13 'lto-dump'--Tool for dumping LTO object files.
  *************************************************
  
  * Menu:
--- 61105,61156 ----
  
  File: gcc.info,  Node: Gcov-dump Intro,  Next: Invoking Gcov-dump,  Up: Gcov-dump
  
! 12.1 Introduction to ‘gcov-dump’
  ================================
  
! ‘gcov-dump’ is a tool you can use in conjunction with GCC to dump
  content of gcda and gcno profile files offline.
  
  
  File: gcc.info,  Node: Invoking Gcov-dump,  Prev: Gcov-dump Intro,  Up: Gcov-dump
  
! 12.2 Invoking ‘gcov-dump’
  =========================
  
       Usage: gcov-dump [OPTION] ... GCOVFILES
  
!  ‘gcov-dump’ accepts the following options:
  
! ‘-h’
! ‘--help’
!      Display help about using ‘gcov-dump’ (on the standard output), and
       exit without doing any further processing.
  
! ‘-l’
! ‘--long’
       Dump content of records.
  
! ‘-p’
! ‘--positions’
       Dump positions of records.
  
! ‘-r’
! ‘--raw’
       Print content records in raw format.
  
! ‘-s’
! ‘--stable’
       Print content in stable format usable for comparison.
  
! ‘-v’
! ‘--version’
!      Display the ‘gcov-dump’ version number (on the standard output),
       and exit without doing any further processing.
  
  
  File: gcc.info,  Node: lto-dump,  Next: Trouble,  Prev: Gcov-dump,  Up: Top
  
! 13 ‘lto-dump’--Tool for dumping LTO object files.
  *************************************************
  
  * Menu:
*************** File: gcc.info,  Node: lto-dump,  Next:
*** 61152,61219 ****
  
  File: gcc.info,  Node: lto-dump Intro,  Next: Invoking lto-dump,  Up: lto-dump
  
! 13.1 Introduction to 'lto-dump'
  ===============================
  
! 'lto-dump' is a tool you can use in conjunction with GCC to dump link
  time optimization object files.
  
  
  File: gcc.info,  Node: Invoking lto-dump,  Prev: lto-dump Intro,  Up: lto-dump
  
! 13.2 Invoking 'lto-dump'
  ========================
  
       Usage: lto-dump [OPTION] ... OBJFILES
  
!  'lto-dump' accepts the following options:
  
! '-list'
       Dumps list of details of functions and variables.
  
! '-demangle'
       Dump the demangled output.
  
! '-defined-only'
       Dump only the defined symbols.
  
! '-print-value'
       Dump initial values of the variables.
  
! '-name-sort'
       Sort the symbols alphabetically.
  
! '-size-sort'
       Sort the symbols according to size.
  
! '-reverse-sort'
       Dump the symbols in reverse order.
  
! '-no-sort'
       Dump the symbols in order of occurrence.
  
! '-symbol='
       Dump the details of specific symbol.
  
! '-objects'
       Dump the details of LTO objects.
  
! '-type-stats'
       Dump the statistics of tree types.
  
! '-tree-stats'
       Dump the statistics of trees.
  
! '-gimple-stats'
       Dump the statistics of gimple statements.
  
! '-dump-level='
       For deciding the optimization level of body.
  
! '-dump-body='
       Dump the specific gimple body.
  
! '-help'
       Display the dump tool help.
  
  
--- 61161,61228 ----
  
  File: gcc.info,  Node: lto-dump Intro,  Next: Invoking lto-dump,  Up: lto-dump
  
! 13.1 Introduction to ‘lto-dump’
  ===============================
  
! ‘lto-dump’ is a tool you can use in conjunction with GCC to dump link
  time optimization object files.
  
  
  File: gcc.info,  Node: Invoking lto-dump,  Prev: lto-dump Intro,  Up: lto-dump
  
! 13.2 Invoking ‘lto-dump’
  ========================
  
       Usage: lto-dump [OPTION] ... OBJFILES
  
!  ‘lto-dump’ accepts the following options:
  
! ‘-list’
       Dumps list of details of functions and variables.
  
! ‘-demangle’
       Dump the demangled output.
  
! ‘-defined-only’
       Dump only the defined symbols.
  
! ‘-print-value’
       Dump initial values of the variables.
  
! ‘-name-sort’
       Sort the symbols alphabetically.
  
! ‘-size-sort’
       Sort the symbols according to size.
  
! ‘-reverse-sort’
       Dump the symbols in reverse order.
  
! ‘-no-sort’
       Dump the symbols in order of occurrence.
  
! ‘-symbol=’
       Dump the details of specific symbol.
  
! ‘-objects’
       Dump the details of LTO objects.
  
! ‘-type-stats’
       Dump the statistics of tree types.
  
! ‘-tree-stats’
       Dump the statistics of trees.
  
! ‘-gimple-stats’
       Dump the statistics of gimple statements.
  
! ‘-dump-level=’
       For deciding the optimization level of body.
  
! ‘-dump-body=’
       Dump the specific gimple body.
  
! ‘-help’
       Display the dump tool help.
  
  
*************** File: gcc.info,  Node: Actual Bugs,  Nex
*** 61252,61260 ****
  14.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.
  
--- 61261,61269 ----
  14.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.
  
*************** This section lists various difficulties
*** 61268,61274 ****
  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.
  
--- 61277,61283 ----
  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.
  
*************** and debuggers on certain systems.
*** 61283,61300 ****
       Incompatible libraries are then detected at link time, rather than
       at run time.
  
!    * On some BSD systems, including some versions of Ultrix, use of
       profiling causes static variable destructors (currently used only
       in C++) not to be run.
  
!    * On a SPARC, GCC aligns all values of type 'double' on an 8-byte
!      boundary, and it expects every 'double' to be so aligned.  The Sun
!      compiler usually gives 'double' values 8-byte alignment, with one
!      exception: function arguments of type 'double' may not be aligned.
  
       As a result, if a function compiled with Sun CC takes the address
!      of an argument of type 'double' and passes this pointer of type
!      'double *' to a function compiled with GCC, dereferencing the
       pointer may cause a fatal signal.
  
       One way to solve this problem is to compile your entire program
--- 61292,61309 ----
       Incompatible libraries are then detected at link time, rather than
       at run time.
  
!    • On some BSD systems, including some versions of Ultrix, use of
       profiling causes static variable destructors (currently used only
       in C++) not to be run.
  
!    • On a SPARC, GCC aligns all values of type ‘double’ on an 8-byte
!      boundary, and it expects every ‘double’ to be so aligned.  The Sun
!      compiler usually gives ‘double’ values 8-byte alignment, with one
!      exception: function arguments of type ‘double’ may not be aligned.
  
       As a result, if a function compiled with Sun CC takes the address
!      of an argument of type ‘double’ and passes this pointer of type
!      ‘double *’ to a function compiled with GCC, dereferencing the
       pointer may cause a fatal signal.
  
       One way to solve this problem is to compile your entire program
*************** and debuggers on certain systems.
*** 61302,61309 ****
       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)
--- 61311,61318 ----
       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)
*************** and debuggers on certain systems.
*** 61321,61362 ****
  
       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
--- 61330,61371 ----
  
       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
*************** and debuggers on certain systems.
*** 61364,61406 ****
  
       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.
  
  
--- 61373,61415 ----
  
       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
*** 61412,61449 ****
  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:
  
--- 61421,61458 ----
  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:
  
*************** There are several noteworthy incompatibi
*** 61458,61476 ****
                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:
  
--- 61467,61485 ----
                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:
  
*************** There are several noteworthy incompatibi
*** 61480,61525 ****
  
       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
--- 61489,61534 ----
  
       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
*************** There are several noteworthy incompatibi
*** 61530,61555 ****
            #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 ('' 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.
--- 61539,61564 ----
            #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 (‘’ 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.
*************** There are several noteworthy incompatibi
*** 61559,61565 ****
       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
--- 61568,61574 ----
       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
*************** There are several noteworthy incompatibi
*** 61574,61594 ****
       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
--- 61583,61603 ----
       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
*************** incompatible with ISO C, and some depend
*** 61607,61622 ****
  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.
--- 61616,61631 ----
  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.
*************** what this means.  Beyond the library fac
*** 61642,61657 ****
  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
--- 61651,61666 ----
  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
*************** File: gcc.info,  Node: Disappointments,
*** 61667,61673 ****
  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
--- 61676,61682 ----
  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
*************** way around them.
*** 61679,61685 ****
       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 *);
--- 61688,61694 ----
       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 *);
*************** way around them.
*** 61689,61711 ****
            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
--- 61698,61720 ----
            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
*************** way around them.
*** 61714,61720 ****
       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
--- 61723,61729 ----
       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
*************** way around them.
*** 61723,61748 ****
  
       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
--- 61732,61757 ----
  
       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
*************** static member; you must also _define_ it
*** 61787,61804 ****
         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.
  
  
--- 61796,61813 ----
         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.
  
  
*************** looked up at the point of instantiation.
*** 61827,61846 ****
           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', 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
--- 61836,61855 ----
           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’, 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
*************** different from non-template codes.  The
*** 61857,61877 ****
           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 cannot 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*', so is obviously dependent), or using 'Base::i'.
! Alternatively, 'Base::i' might be brought into scope by a
! 'using'-declaration.
  
   Another, similar example involves calling member functions of a base
  class:
--- 61866,61886 ----
           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 cannot 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*’, so is obviously dependent), or using ‘Base::i’.
! Alternatively, ‘Base::i’ might be brought into scope by a
! ‘using’-declaration.
  
   Another, similar example involves calling member functions of a base
  class:
*************** class:
*** 61884,61891 ****
             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
--- 61893,61900 ----
             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 f
*** 61897,61908 ****
         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::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).
  
--- 61906,61917 ----
         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::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).
  
*************** It is dangerous to use pointers or refer
*** 61926,61940 ****
  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 *);
--- 61935,61949 ----
  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 *);
*************** pointers to 'char':
*** 61950,61959 ****
       }
  
  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
--- 61959,61968 ----
       }
  
  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
*************** such objects behave unspecified when bei
*** 62008,62024 ****
         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: 'name' (via 'strdup'),
! 'val', 'name' again, and 'bval'.
  
   If application code relies on copy-assignment, a user-defined
  copy-assignment operator removes any uncertainties.  With such an
--- 62017,62033 ----
         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: ‘name’ (via ‘strdup’),
! ‘val’, ‘name’ again, and ‘bval’.
  
   If application code relies on copy-assignment, a user-defined
  copy-assignment operator removes any uncertainties.  With such an
*************** File: gcc.info,  Node: Non-bugs,  Next:
*** 62034,62040 ****
  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
--- 62043,62049 ----
  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
*************** do not make because we think GCC is bett
*** 62043,62073 ****
       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
--- 62052,62082 ----
       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
*************** do not make because we think GCC is bett
*** 62075,62094 ****
       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.
  
--- 62084,62103 ----
       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.
  
*************** do not make because we think GCC is bett
*** 62132,62193 ****
       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
--- 62141,62202 ----
       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
*************** do not make because we think GCC is bett
*** 62205,62211 ****
  
       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;
--- 62214,62220 ----
  
       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;
*************** do not make because we think GCC is bett
*** 62215,62224 ****
                  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
--- 62224,62233 ----
                  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
*************** do not make because we think GCC is bett
*** 62232,62242 ****
  
       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.
--- 62241,62251 ----
  
       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.
*************** do not make because we think GCC is bett
*** 62245,62251 ****
       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.
  
  
--- 62254,62260 ----
       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 Erro
*** 62257,62285 ****
  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
--- 62266,62294 ----
  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
*************** File: gcc.info,  Node: Bug Criteria,  Ne
*** 62311,62338 ****
  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.
--- 62320,62347 ----
  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.
*************** guidelines:
*** 62341,62355 ****
       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.
  
--- 62350,62364 ----
       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: Service,  Next: C
*** 62371,62384 ****
  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
        (for help installing or using GCC), and if
       that brings no response, try .  For help changing
       GCC, ask .  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
       .
  
--- 62380,62393 ----
  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
        (for help installing or using GCC), and if
       that brings no response, try .  For help changing
       GCC, ask .  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
       .
  
*************** more; major new features or packages con
*** 62451,62457 ****
  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.
  
--- 62460,62466 ----
  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 © 1994 Free Software Foundation, Inc.
       Verbatim copying and redistribution of this section is permitted
       without royalty; alteration is not permitted.
  
*************** GNU General Public License
*** 62480,62486 ****
  
                          Version 3, 29 June 2007
  
!      Copyright (C) 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
--- 62489,62495 ----
  
                          Version 3, 29 June 2007
  
!      Copyright © 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
*************** mail.
*** 63167,63177 ****
  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".
--- 63176,63186 ----
  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".
*************** GNU Free Documentation License
*** 63196,63202 ****
  
                       Version 1.3, 3 November 2008
  
!      Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
--- 63205,63211 ----
  
                       Version 1.3, 3 November 2008
  
!      Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
*************** GNU Free Documentation License
*** 63205,63211 ****
    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
--- 63214,63220 ----
    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
*************** Any omissions in this list are accidenta
*** 63683,64067 ****
  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 DWARF 2 support, faster/better
       optimizations, improved alias analysis, plus migrating GCC to
       Bugzilla.
  
!    * Geoff Berry for his Java object serialization work and various
       patches.
  
!    * David Binderman tests weekly snapshots of GCC trunk against Fedora
       Rawhide for several architectures.
  
!    * Laurynas Biveinis for memory management work and DJGPP port fixes.
  
!    * 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.
  
!    * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
       other Java work.
  
!    * Segher Boessenkool for helping maintain the PowerPC port and the
       instruction combiner plus various contributions to the middle end.
  
!    * 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.
  
!    * James Bowman for the FT32 port.
  
!    * 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 from its
       creation to 2013.
  
!    * Iain Buclaw for the D frontend.
  
!    * Craig Burley for leadership of the G77 Fortran effort.
  
!    * Tobias Burnus for contributions to GNU Fortran.
  
!    * 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.
  
!    * Kito Cheng for his work on the RISC-V port, including bringing up
       the test suite and maintenance.
  
!    * Scott Christley for his Objective-C contributions.
  
!    * Eric Christopher for his Java porting help and clean-ups.
  
!    * Branko Cibej for more warning contributions.
  
!    * The GNU Classpath project for all of their merged runtime code.
  
!    * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work,
!      '--help', and other random hacking.
  
!    * Michael Cook for libstdc++ cleanup patches to reduce warnings.
  
!    * R. Kelley Cook for making GCC buildable from a read-only directory
       as well as other miscellaneous build process and documentation
       clean-ups.
  
!    * Ralf Corsepius for SH testing and minor bug fixing.
  
!    * François-Xavier Coudert for contributions to GNU Fortran.
  
!    * 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.
  
!    * Palmer Dabbelt for his work maintaining the RISC-V port.
  
!    * 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.
  
!    * Jerry DeLisle for contributions to GNU Fortran.
  
!    * DJ Delorie for the DJGPP port, build and libiberty maintenance,
       various bug fixes, and the M32C, MeP, MSP430, and RL78 ports.
  
!    * Arnaud Desitter for helping to debug GNU Fortran.
  
!    * Gabriel Dos Reis for contributions to G++, contributions and
       maintenance of GCC diagnostics infrastructure, libstdc++-v3,
!      including 'valarray<>', 'complex<>', maintaining the numerics
!      library (including that pesky '' :-) 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.
  
!    * François Dumont for his work on libstdc++-v3, especially
!      maintaining and improving 'debug-mode' and associative and
       unordered containers.
  
!    * Zdenek Dvorak for a new loop unroller and various fixes.
  
!    * Michael Eager for his work on the Xilinx MicroBlaze port.
  
!    * Richard Earnshaw for his ongoing work with the ARM.
  
!    * David Edelsohn for his direction via the steering committee,
       ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
       loop changes, doing the entire AIX port of libstdc++ with his bare
       hands, and for ensuring GCC properly keeps working on AIX.
  
!    * Kevin Ediger for the floating point formatting of num_put::do_put
       in libstdc++.
  
!    * Phil Edwards for libstdc++ work including configuration hackery,
       documentation maintainer, chief breaker of the web pages, the
       occasional iostream bug fix, and work on shared library symbol
       versioning.
  
!    * Paul Eggert for random hacking all over GCC.
  
!    * Mark Elbrecht for various DJGPP improvements, and for libstdc++
       configuration support for locales and fstream-related fixes.
  
!    * Vadim Egorov for libstdc++ fixes in strings, streambufs, and
       iostreams.
  
!    * Christian Ehrhardt for dealing with bug reports.
  
!    * Ben Elliston for his work to move the Objective-C runtime into its
       own subdirectory and for his work on autoconf.
  
!    * Revital Eres for work on the PowerPC 750CL port.
  
!    * Marc Espie for OpenBSD support.
  
!    * Doug Evans for much of the global optimization framework, arc,
       m32r, and SPARC work.
  
!    * Christopher Faylor for his work on the Cygwin port and for caring
       and feeding the gcc.gnu.org box and saving its users tons of spam.
  
!    * Fred Fish for BeOS support and Ada fixes.
  
!    * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
  
!    * Peter Gerwinski for various bug fixes and the Pascal front end.
  
!    * Kaveh R. Ghazi for his direction via the steering committee,
!      amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC
       on a plethora of platforms.  Kaveh extends his gratitude to the
       CAIP Center at Rutgers University for providing him with computing
       resources to work on Free Software from the late 1980s to 2010.
  
!    * John Gilmore for a donation to the FSF earmarked improving GNU
       Java.
  
!    * Judy Goldberg for c++ contributions.
  
!    * Torbjorn Granlund for various fixes and the c-torture testsuite,
       multiply- and divide-by-constant optimization, improved long long
       support, improved leaf function register allocation, and his
       direction via the steering committee.
  
!    * Jonny Grant for improvements to 'collect2's' '--help'
       documentation.
  
!    * Anthony Green for his '-Os' contributions, the moxie port, and Java
       front end work.
  
!    * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java
       code.
  
!    * Michael K. Gschwind contributed the port to the PDP-11.
  
!    * Richard Biener for his ongoing middle-end contributions and bug
       fixes and for release management.
  
!    * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools,
       the support for DWARF 1 symbolic debugging information, and much of
       the support for System V Release 4.  He has also worked heavily on
       the Intel 386 and 860 support.
  
!    * Sumanth Gundapaneni for contributing the CR16 port.
  
!    * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
       GCSE.
  
!    * Bruno Haible for improvements in the runtime overhead for EH, new
       warnings and assorted bug fixes.
  
!    * Andrew Haley for his amazing Java compiler and library efforts.
  
!    * Chris Hanson assisted in making GCC work on HP-UX for the 9000
       series 300.
  
!    * Michael Hayes for various thankless work he's done trying to get
       the c30/c40 ports functional.  Lots of loop and unroll improvements
       and fixes.
  
!    * Dara Hazeghi for wading through myriads of target-specific bug
       reports.
  
!    * Kate Hedstrom for staking the G77 folks with an initial testsuite.
  
!    * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
       work, loop opts, and generally fixing lots of old problems we've
       ignored for years, flow rewrite and lots of further stuff,
       including reviewing tons of patches.
  
!    * Aldy Hernandez for working on the PowerPC port, SIMD support, and
       various fixes.
  
!    * Nobuyuki Hikichi of Software Research Associates, Tokyo,
       contributed the support for the Sony NEWS machine.
  
!    * Kazu Hirata for caring and feeding the Renesas H8/300 port and
       various fixes.
  
!    * Katherine Holcomb for work on GNU Fortran.
  
!    * Manfred Hollstein for his ongoing work to keep the m88k alive, lots
       of testing and bug fixing, particularly of GCC configury code.
  
!    * Steve Holmgren for MachTen patches.
  
!    * Mat Hostetter for work on the TILE-Gx and TILEPro ports.
  
!    * Jan Hubicka for his x86 port improvements.
  
!    * Falk Hueffner for working on C and optimization bug reports.
  
!    * Bernardo Innocenti for his m68k work, including merging of ColdFire
       improvements and uClinux support.
  
!    * Christian Iseli for various bug fixes.
  
!    * Kamil Iskra for general m68k hacking.
  
!    * Lee Iverson for random fixes and MIPS testing.
  
!    * Balaji V. Iyer for Cilk+ development and merging.
  
!    * Andreas Jaeger for testing and benchmarking of GCC and various bug
       fixes.
  
!    * Martin Jambor for his work on inter-procedural optimizations, the
       switch conversion pass, and scalar replacement of aggregates.
  
!    * 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
--- 63692,64076 ----
  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 DWARF 2 support, faster/better
       optimizations, improved alias analysis, plus migrating GCC to
       Bugzilla.
  
!    • Geoff Berry for his Java object serialization work and various
       patches.
  
!    • David Binderman tests weekly snapshots of GCC trunk against Fedora
       Rawhide for several architectures.
  
!    • Laurynas Biveinis for memory management work and DJGPP port fixes.
  
!    • 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.
  
!    • Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
       other Java work.
  
!    • Segher Boessenkool for helping maintain the PowerPC port and the
       instruction combiner plus various contributions to the middle end.
  
!    • 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.
  
!    • James Bowman for the FT32 port.
  
!    • 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 from its
       creation to 2013.
  
!    • Iain Buclaw for the D frontend.
  
!    • Craig Burley for leadership of the G77 Fortran effort.
  
!    • Tobias Burnus for contributions to GNU Fortran.
  
!    • 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.
  
!    • Kito Cheng for his work on the RISC-V port, including bringing up
       the test suite and maintenance.
  
!    • Scott Christley for his Objective-C contributions.
  
!    • Eric Christopher for his Java porting help and clean-ups.
  
!    • Branko Cibej for more warning contributions.
  
!    • The GNU Classpath project for all of their merged runtime code.
  
!    • Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work,
!      ‘--help’, and other random hacking.
  
!    • Michael Cook for libstdc++ cleanup patches to reduce warnings.
  
!    • R. Kelley Cook for making GCC buildable from a read-only directory
       as well as other miscellaneous build process and documentation
       clean-ups.
  
!    • Ralf Corsepius for SH testing and minor bug fixing.
  
!    • François-Xavier Coudert for contributions to GNU Fortran.
  
!    • 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.
  
!    • Palmer Dabbelt for his work maintaining the RISC-V port.
  
!    • 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.
  
!    • Jerry DeLisle for contributions to GNU Fortran.
  
!    • DJ Delorie for the DJGPP port, build and libiberty maintenance,
       various bug fixes, and the M32C, MeP, MSP430, and RL78 ports.
  
!    • Arnaud Desitter for helping to debug GNU Fortran.
  
!    • Gabriel Dos Reis for contributions to G++, contributions and
       maintenance of GCC diagnostics infrastructure, libstdc++-v3,
!      including ‘valarray<>’, ‘complex<>’, maintaining the numerics
!      library (including that pesky ‘’ :-) 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.
  
!    • François Dumont for his work on libstdc++-v3, especially
!      maintaining and improving ‘debug-mode’ and associative and
       unordered containers.
  
!    • Zdenek Dvorak for a new loop unroller and various fixes.
  
!    • Michael Eager for his work on the Xilinx MicroBlaze port.
  
!    • Richard Earnshaw for his ongoing work with the ARM.
  
!    • David Edelsohn for his direction via the steering committee,
       ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
       loop changes, doing the entire AIX port of libstdc++ with his bare
       hands, and for ensuring GCC properly keeps working on AIX.
  
!    • Kevin Ediger for the floating point formatting of num_put::do_put
       in libstdc++.
  
!    • Phil Edwards for libstdc++ work including configuration hackery,
       documentation maintainer, chief breaker of the web pages, the
       occasional iostream bug fix, and work on shared library symbol
       versioning.
  
!    • Paul Eggert for random hacking all over GCC.
  
!    • Mark Elbrecht for various DJGPP improvements, and for libstdc++
       configuration support for locales and fstream-related fixes.
  
!    • Vadim Egorov for libstdc++ fixes in strings, streambufs, and
       iostreams.
  
!    • Christian Ehrhardt for dealing with bug reports.
  
!    • Ben Elliston for his work to move the Objective-C runtime into its
       own subdirectory and for his work on autoconf.
  
!    • Revital Eres for work on the PowerPC 750CL port.
  
!    • Marc Espie for OpenBSD support.
  
!    • Doug Evans for much of the global optimization framework, arc,
       m32r, and SPARC work.
  
!    • Christopher Faylor for his work on the Cygwin port and for caring
       and feeding the gcc.gnu.org box and saving its users tons of spam.
  
!    • Fred Fish for BeOS support and Ada fixes.
  
!    • Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
  
!    • Peter Gerwinski for various bug fixes and the Pascal front end.
  
!    • Kaveh R. Ghazi for his direction via the steering committee,
!      amazing work to make ‘-W -Wall -W* -Werror’ useful, and testing GCC
       on a plethora of platforms.  Kaveh extends his gratitude to the
       CAIP Center at Rutgers University for providing him with computing
       resources to work on Free Software from the late 1980s to 2010.
  
!    • John Gilmore for a donation to the FSF earmarked improving GNU
       Java.
  
!    • Judy Goldberg for c++ contributions.
  
!    • Torbjorn Granlund for various fixes and the c-torture testsuite,
       multiply- and divide-by-constant optimization, improved long long
       support, improved leaf function register allocation, and his
       direction via the steering committee.
  
!    • Jonny Grant for improvements to ‘collect2's’ ‘--help’
       documentation.
  
!    • Anthony Green for his ‘-Os’ contributions, the moxie port, and Java
       front end work.
  
!    • Stu Grossman for gdb hacking, allowing GCJ developers to debug Java
       code.
  
!    • Michael K. Gschwind contributed the port to the PDP-11.
  
!    • Richard Biener for his ongoing middle-end contributions and bug
       fixes and for release management.
  
!    • Ron Guilmette implemented the ‘protoize’ and ‘unprotoize’ tools,
       the support for DWARF 1 symbolic debugging information, and much of
       the support for System V Release 4.  He has also worked heavily on
       the Intel 386 and 860 support.
  
!    • Sumanth Gundapaneni for contributing the CR16 port.
  
!    • Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
       GCSE.
  
!    • Bruno Haible for improvements in the runtime overhead for EH, new
       warnings and assorted bug fixes.
  
!    • Andrew Haley for his amazing Java compiler and library efforts.
  
!    • Chris Hanson assisted in making GCC work on HP-UX for the 9000
       series 300.
  
!    • Michael Hayes for various thankless work he's done trying to get
       the c30/c40 ports functional.  Lots of loop and unroll improvements
       and fixes.
  
!    • Dara Hazeghi for wading through myriads of target-specific bug
       reports.
  
!    • Kate Hedstrom for staking the G77 folks with an initial testsuite.
  
!    • Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
       work, loop opts, and generally fixing lots of old problems we've
       ignored for years, flow rewrite and lots of further stuff,
       including reviewing tons of patches.
  
!    • Aldy Hernandez for working on the PowerPC port, SIMD support, and
       various fixes.
  
!    • Nobuyuki Hikichi of Software Research Associates, Tokyo,
       contributed the support for the Sony NEWS machine.
  
!    • Kazu Hirata for caring and feeding the Renesas H8/300 port and
       various fixes.
  
!    • Katherine Holcomb for work on GNU Fortran.
  
!    • Manfred Hollstein for his ongoing work to keep the m88k alive, lots
       of testing and bug fixing, particularly of GCC configury code.
  
!    • Steve Holmgren for MachTen patches.
  
!    • Mat Hostetter for work on the TILE-Gx and TILEPro ports.
  
!    • Jan Hubicka for his x86 port improvements.
  
!    • Falk Hueffner for working on C and optimization bug reports.
  
!    • Bernardo Innocenti for his m68k work, including merging of ColdFire
       improvements and uClinux support.
  
!    • Christian Iseli for various bug fixes.
  
!    • Kamil Iskra for general m68k hacking.
  
!    • Lee Iverson for random fixes and MIPS testing.
  
!    • Balaji V. Iyer for Cilk+ development and merging.
  
!    • Andreas Jaeger for testing and benchmarking of GCC and various bug
       fixes.
  
!    • Martin Jambor for his work on inter-procedural optimizations, the
       switch conversion pass, and scalar replacement of aggregates.
  
!    • 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
*************** in alphabetical order.
*** 64072,64984 ****
       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.
  
!    * Maxim Kuvyrkov for contributions to the instruction scheduler, the
       Android and m68k/Coldfire ports, and optimizations.
  
!    * Charles LaBrec contributed the support for the Integrated Solutions
       68020 system.
  
!    * Asher Langton and Mike Kumbera for contributing Cray pointer
       support to GNU Fortran, and for other GNU Fortran improvements.
  
!    * Jeff Law for his direction via the steering committee, coordinating
       the entire egcs project and GCC 2.95, rolling out snapshots and
       releases, handling merges from GCC2, reviewing tons of patches that
       might have fallen through the cracks else, and random but extensive
       hacking.
  
!    * Walter Lee for work on the TILE-Gx and TILEPro ports.
  
!    * Marc Lehmann for his direction via the steering committee and
       helping with analysis and improvements of x86 performance.
  
!    * Victor Leikehman for work on GNU Fortran.
  
!    * Ted Lemon wrote parts of the RTL reader and printer.
  
!    * Kriang Lerdsuwanakij for C++ improvements including template as
       template parameter support, and many C++ fixes.
  
!    * Warren Levy for tremendous work on libgcj (Java Runtime Library)
       and random work on the Java front end.
  
!    * Alain Lichnewsky ported GCC to the MIPS CPU.
  
!    * Oskar Liljeblad for hacking on AWT and his many Java bug reports
       and patches.
  
!    * Robert Lipe for OpenServer support, new testsuites, testing, etc.
  
!    * Chen Liqin for various S+core related fixes/improvement, and for
       maintaining the S+core port.
  
!    * Martin Liska for his work on identical code folding, the
       sanitizers, HSA, general bug fixing and for running automated
       regression testing of GCC and reporting numerous bugs.
  
!    * Weiwen Liu for testing and various bug fixes.
  
!    * Manuel López-Ibáñ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 Lö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, design and
       implementation of the automaton based instruction scheduler and
       design and implementation of the integrated and local register
       allocators.
  
!    * David Malcolm for his work on improving GCC diagnostics, JIT,
       self-tests and unit testing.
  
!    * Bob Manson for his behind the scenes work on dejagnu.
  
!    * Jose E. Marchesi for contributing the eBPF backend and his ongoing
       work maintaining it.
  
!    * John Marino for contributing the DragonFly BSD port.
  
!    * Philip Martin for lots of libstdc++ string and vector iterator
       fixes and improvements, and string clean up and testsuites.
  
!    * Michael Matz for his work on dominance tree discovery, the x86-64
       port, link-time optimization framework and general optimization
       improvements.
  
!    * 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.cc and interfacing with the Linux
       kernel developers.
  
!    * Gary Miller ported GCC to Charles River Data Systems machines.
  
!    * Alfred Minarik for libstdc++ string and ios bug fixes, and turning
       the entire libstdc++ testsuite namespace-compatible.
  
!    * Mark Mitchell for his direction via the steering committee,
       mountains of C++ work, load/store hoisting out of loops, alias
!      analysis improvements, ISO C 'restrict' support, and serving as
       release manager from 2000 to 2011.
  
!    * Alan Modra for various GNU/Linux bits and testing.
  
!    * Toon Moene for his direction via the steering committee, Fortran
       maintenance, and his ongoing work to make us make Fortran run fast.
  
!    * Jason Molenda for major help in the care and feeding of all the
       services on the gcc.gnu.org (formerly egcs.cygnus.com)
       machine--mail, web services, ftp services, etc etc.  Doing all this
       work on scrap paper and the backs of envelopes would have been...
       difficult.
  
!    * Catherine Moore for fixing various ugly problems we have sent her
       way, including the haifa bug which was killing the Alpha & PowerPC
       Linux kernels.
  
!    * Mike Moreton for his various Java patches.
  
!    * David Mosberger-Tang for various Alpha improvements, and for the
       initial IA-64 port.
  
!    * Stephen Moshier contributed the floating point emulator that
       assists in cross-compilation and permits support for floating point
       numbers wider than 64 bits and for ISO C99 support.
  
!    * Bill Moyer for his behind the scenes work on various issues.
  
!    * Philippe De Muyter for his work on the m68k port.
  
!    * Joseph S. Myers for his work on the PDP-11 port, format checking
       and ISO C99 support, and continuous emphasis on (and contributions
       to) documentation.
  
!    * Nathan Myers for his work on libstdc++-v3: architecture and
       authorship through the first three snapshots, including
       implementation of locale infrastructure, string, shadow C headers,
       and the initial project documentation (DESIGN, CHECKLIST, and so
       forth).  Later, more work on MT-safe string and shadow headers.
  
!    * Felix Natter for documentation on porting libstdc++.
  
!    * Nathanael Nerode for cleaning up the configuration/build process.
  
!    * NeXT, Inc. donated the front end that supports the Objective-C
       language.
  
!    * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the
       search engine setup, various documentation fixes and other small
       fixes.
  
!    * Geoff Noer for his work on getting cygwin native builds working.
  
!    * Vegard Nossum for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * 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.
  
!    * Steven Pemberton for his contribution of 'enquire' which allowed
       GCC to determine various properties of the floating point unit and
!      generate 'float.h' in older versions of GCC.
  
!    * 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.
  
!    * Marek Polacek for his work on the C front end, the sanitizers and
       general bug fixing.
  
!    * 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.
  
!    * John Regehr for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * Volker Reichelt for running automated regression testing of GCC and
       reporting numerous bugs and for keeping up with the problem
       reports.
  
!    * Joern Rennecke for maintaining the sh port, loop, regmove & reload
       hacking and developing and maintaining the Epiphany port.
  
!    * Loren J. Rittle for improvements to libstdc++-v3 including the
       FreeBSD port, threading fixes, thread-related configury changes,
       critical threading documentation, and solutions to really tricky
       I/O problems, as well as keeping GCC properly working on FreeBSD
       and continuous testing.
  
!    * Craig Rodrigues for processing tons of bug reports.
  
!    * Ola Rö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.
  
!    * Ira Rosen for her contributions to the auto-vectorizer.
  
!    * Paul Rubin wrote most of the preprocessor.
  
!    * Pétur Runó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 Schlüter for work on GNU Fortran.
  
!    * Bernd Schmidt for various code generation improvements and major
       work in the reload pass, serving as release manager for GCC 2.95.3,
       and work on the Blackfin and C6X ports.
  
!    * Peter Schmid for constant testing of libstdc++--especially
       application testing, going above and beyond what was requested for
       the release criteria--and libstdc++ header file tweaks.
  
!    * Jason Schroeder for jcf-dump patches.
  
!    * Andreas Schwab for his work on the m68k port.
  
!    * Lars Segerlund for work on GNU Fortran.
  
!    * Dodji Seketeli for numerous C++ bug fixes and debug info
       improvements.
  
!    * Tim Shen for major work on ''.
  
!    * 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.
       Retired from GCC maintainership August 2010, having mentored two
       new maintainers into the role.
  
!    * Randy Smith finished the Sun FPA support.
  
!    * Ed Smith-Rowland for his continuous work on libstdc++-v3, special
!      functions, '', and various improvements to C++11 features.
  
!    * Scott Snyder for queue, iterator, istream, and string fixes and
       libstdc++ testsuite entries.  Also for providing the patch to G77
!      to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and
!      'LOGICAL*1'.
  
!    * Zdenek Sojka for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * Arseny Solokha for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * Jayant Sonar for contributing the CR16 port.
  
!    * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
  
!    * Richard Stallman, for writing the original GCC and launching the
       GNU project.
  
!    * Jan Stein of the Chalmers Computer Society provided support for
       Genix, as well as part of the 32000 machine description.
  
!    * Gerhard Steinmetz for running automated regression testing of GCC
       and reporting numerous bugs.
  
!    * 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.
  
!    * Zhendong Su for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * Chengnian Sun for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * 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.
  
!    * Paul Thomas for contributions to GNU Fortran.
  
!    * 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.
  
!    * Andrew Waterman for contributing the RISC-V port, as well as
       maintaining it.
  
!    * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
       guidance and maintaining libstdc++.
  
!    * Dean Wakerley for converting the install documentation from HTML to
       texinfo in time for GCC 3.0.
  
!    * Krister Walfridsson for random bug fixes.
  
!    * Feng Wang for contributions to GNU Fortran.
  
!    * Stephen M. Webb for time and effort on making libstdc++ shadow
       files work with the tricky Solaris 8+ headers, and for pushing the
       build-time header tree.  Also, for starting and driving the
!      '' effort.
  
!    * John Wehle for various improvements for the x86 code generator,
       related infrastructure improvements to help x86 code generation,
       value range propagation and other work, WE32k port.
  
!    * Ulrich Weigand for work on the s390 port.
  
!    * Janus Weil for contributions to GNU Fortran.
  
!    * Zack Weinberg for major work on cpplib and various other bug fixes.
  
!    * Matt Welsh for help with Linux Threads support in GCJ.
  
!    * Urban Widmark for help fixing java.io.
  
!    * Mark Wielaard for new Java library code and his work integrating
       with Classpath.
  
!    * Dale Wiles helped port GCC to the Tahoe.
  
!    * Bob Wilson from Tensilica, Inc. for the Xtensa port.
  
!    * Jim Wilson for his direction via the steering committee, tackling
       hard problems in various places that nobody else wanted to work on,
       strength reduction and other loop optimizations.
  
!    * Paul Woegerer and Tal Agmon for the CRX port.
  
!    * Carlo Wood for various fixes.
  
!    * Tom Wood for work on the m88k port.
  
!    * Chung-Ju Wu for his work on the Andes NDS32 port.
  
!    * Canqun Yang for work on GNU Fortran.
  
!    * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
       description for the Tron architecture (specifically, the Gmicro).
  
!    * Kevin Zachmann helped port GCC to the Tahoe.
  
!    * Ayal Zaks for Swing Modulo Scheduling (SMS).
  
!    * Qirun Zhang for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * 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
  
!    * Jö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
--- 64081,64993 ----
       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.
  
!    • Maxim Kuvyrkov for contributions to the instruction scheduler, the
       Android and m68k/Coldfire ports, and optimizations.
  
!    • Charles LaBrec contributed the support for the Integrated Solutions
       68020 system.
  
!    • Asher Langton and Mike Kumbera for contributing Cray pointer
       support to GNU Fortran, and for other GNU Fortran improvements.
  
!    • Jeff Law for his direction via the steering committee, coordinating
       the entire egcs project and GCC 2.95, rolling out snapshots and
       releases, handling merges from GCC2, reviewing tons of patches that
       might have fallen through the cracks else, and random but extensive
       hacking.
  
!    • Walter Lee for work on the TILE-Gx and TILEPro ports.
  
!    • Marc Lehmann for his direction via the steering committee and
       helping with analysis and improvements of x86 performance.
  
!    • Victor Leikehman for work on GNU Fortran.
  
!    • Ted Lemon wrote parts of the RTL reader and printer.
  
!    • Kriang Lerdsuwanakij for C++ improvements including template as
       template parameter support, and many C++ fixes.
  
!    • Warren Levy for tremendous work on libgcj (Java Runtime Library)
       and random work on the Java front end.
  
!    • Alain Lichnewsky ported GCC to the MIPS CPU.
  
!    • Oskar Liljeblad for hacking on AWT and his many Java bug reports
       and patches.
  
!    • Robert Lipe for OpenServer support, new testsuites, testing, etc.
  
!    • Chen Liqin for various S+core related fixes/improvement, and for
       maintaining the S+core port.
  
!    • Martin Liska for his work on identical code folding, the
       sanitizers, HSA, general bug fixing and for running automated
       regression testing of GCC and reporting numerous bugs.
  
!    • Weiwen Liu for testing and various bug fixes.
  
!    • Manuel López-Ibáñ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 Lö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, design and
       implementation of the automaton based instruction scheduler and
       design and implementation of the integrated and local register
       allocators.
  
!    • David Malcolm for his work on improving GCC diagnostics, JIT,
       self-tests and unit testing.
  
!    • Bob Manson for his behind the scenes work on dejagnu.
  
!    • Jose E. Marchesi for contributing the eBPF backend and his ongoing
       work maintaining it.
  
!    • John Marino for contributing the DragonFly BSD port.
  
!    • Philip Martin for lots of libstdc++ string and vector iterator
       fixes and improvements, and string clean up and testsuites.
  
!    • Michael Matz for his work on dominance tree discovery, the x86-64
       port, link-time optimization framework and general optimization
       improvements.
  
!    • 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.cc and interfacing with the Linux
       kernel developers.
  
!    • Gary Miller ported GCC to Charles River Data Systems machines.
  
!    • Alfred Minarik for libstdc++ string and ios bug fixes, and turning
       the entire libstdc++ testsuite namespace-compatible.
  
!    • Mark Mitchell for his direction via the steering committee,
       mountains of C++ work, load/store hoisting out of loops, alias
!      analysis improvements, ISO C ‘restrict’ support, and serving as
       release manager from 2000 to 2011.
  
!    • Alan Modra for various GNU/Linux bits and testing.
  
!    • Toon Moene for his direction via the steering committee, Fortran
       maintenance, and his ongoing work to make us make Fortran run fast.
  
!    • Jason Molenda for major help in the care and feeding of all the
       services on the gcc.gnu.org (formerly egcs.cygnus.com)
       machine--mail, web services, ftp services, etc etc.  Doing all this
       work on scrap paper and the backs of envelopes would have been...
       difficult.
  
!    • Catherine Moore for fixing various ugly problems we have sent her
       way, including the haifa bug which was killing the Alpha & PowerPC
       Linux kernels.
  
!    • Mike Moreton for his various Java patches.
  
!    • David Mosberger-Tang for various Alpha improvements, and for the
       initial IA-64 port.
  
!    • Stephen Moshier contributed the floating point emulator that
       assists in cross-compilation and permits support for floating point
       numbers wider than 64 bits and for ISO C99 support.
  
!    • Bill Moyer for his behind the scenes work on various issues.
  
!    • Philippe De Muyter for his work on the m68k port.
  
!    • Joseph S. Myers for his work on the PDP-11 port, format checking
       and ISO C99 support, and continuous emphasis on (and contributions
       to) documentation.
  
!    • Nathan Myers for his work on libstdc++-v3: architecture and
       authorship through the first three snapshots, including
       implementation of locale infrastructure, string, shadow C headers,
       and the initial project documentation (DESIGN, CHECKLIST, and so
       forth).  Later, more work on MT-safe string and shadow headers.
  
!    • Felix Natter for documentation on porting libstdc++.
  
!    • Nathanael Nerode for cleaning up the configuration/build process.
  
!    • NeXT, Inc. donated the front end that supports the Objective-C
       language.
  
!    • Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the
       search engine setup, various documentation fixes and other small
       fixes.
  
!    • Geoff Noer for his work on getting cygwin native builds working.
  
!    • Vegard Nossum for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • 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.
  
!    • Steven Pemberton for his contribution of ‘enquire’ which allowed
       GCC to determine various properties of the floating point unit and
!      generate ‘float.h’ in older versions of GCC.
  
!    • 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.
  
!    • Marek Polacek for his work on the C front end, the sanitizers and
       general bug fixing.
  
!    • 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.
  
!    • John Regehr for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • Volker Reichelt for running automated regression testing of GCC and
       reporting numerous bugs and for keeping up with the problem
       reports.
  
!    • Joern Rennecke for maintaining the sh port, loop, regmove & reload
       hacking and developing and maintaining the Epiphany port.
  
!    • Loren J. Rittle for improvements to libstdc++-v3 including the
       FreeBSD port, threading fixes, thread-related configury changes,
       critical threading documentation, and solutions to really tricky
       I/O problems, as well as keeping GCC properly working on FreeBSD
       and continuous testing.
  
!    • Craig Rodrigues for processing tons of bug reports.
  
!    • Ola Rö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.
  
!    • Ira Rosen for her contributions to the auto-vectorizer.
  
!    • Paul Rubin wrote most of the preprocessor.
  
!    • Pétur Runó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 Schlüter for work on GNU Fortran.
  
!    • Bernd Schmidt for various code generation improvements and major
       work in the reload pass, serving as release manager for GCC 2.95.3,
       and work on the Blackfin and C6X ports.
  
!    • Peter Schmid for constant testing of libstdc++--especially
       application testing, going above and beyond what was requested for
       the release criteria--and libstdc++ header file tweaks.
  
!    • Jason Schroeder for jcf-dump patches.
  
!    • Andreas Schwab for his work on the m68k port.
  
!    • Lars Segerlund for work on GNU Fortran.
  
!    • Dodji Seketeli for numerous C++ bug fixes and debug info
       improvements.
  
!    • Tim Shen for major work on ‘’.
  
!    • 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.
       Retired from GCC maintainership August 2010, having mentored two
       new maintainers into the role.
  
!    • Randy Smith finished the Sun FPA support.
  
!    • Ed Smith-Rowland for his continuous work on libstdc++-v3, special
!      functions, ‘’, and various improvements to C++11 features.
  
!    • Scott Snyder for queue, iterator, istream, and string fixes and
       libstdc++ testsuite entries.  Also for providing the patch to G77
!      to add rudimentary support for ‘INTEGER*1’, ‘INTEGER*2’, and
!      ‘LOGICAL*1’.
  
!    • Zdenek Sojka for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • Arseny Solokha for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • Jayant Sonar for contributing the CR16 port.
  
!    • Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
  
!    • Richard Stallman, for writing the original GCC and launching the
       GNU project.
  
!    • Jan Stein of the Chalmers Computer Society provided support for
       Genix, as well as part of the 32000 machine description.
  
!    • Gerhard Steinmetz for running automated regression testing of GCC
       and reporting numerous bugs.
  
!    • 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.
  
!    • Zhendong Su for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • Chengnian Sun for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • 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.
  
!    • Paul Thomas for contributions to GNU Fortran.
  
!    • 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.
  
!    • Andrew Waterman for contributing the RISC-V port, as well as
       maintaining it.
  
!    • Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
       guidance and maintaining libstdc++.
  
!    • Dean Wakerley for converting the install documentation from HTML to
       texinfo in time for GCC 3.0.
  
!    • Krister Walfridsson for random bug fixes.
  
!    • Feng Wang for contributions to GNU Fortran.
  
!    • Stephen M. Webb for time and effort on making libstdc++ shadow
       files work with the tricky Solaris 8+ headers, and for pushing the
       build-time header tree.  Also, for starting and driving the
!      ‘’ effort.
  
!    • John Wehle for various improvements for the x86 code generator,
       related infrastructure improvements to help x86 code generation,
       value range propagation and other work, WE32k port.
  
!    • Ulrich Weigand for work on the s390 port.
  
!    • Janus Weil for contributions to GNU Fortran.
  
!    • Zack Weinberg for major work on cpplib and various other bug fixes.
  
!    • Matt Welsh for help with Linux Threads support in GCJ.
  
!    • Urban Widmark for help fixing java.io.
  
!    • Mark Wielaard for new Java library code and his work integrating
       with Classpath.
  
!    • Dale Wiles helped port GCC to the Tahoe.
  
!    • Bob Wilson from Tensilica, Inc. for the Xtensa port.
  
!    • Jim Wilson for his direction via the steering committee, tackling
       hard problems in various places that nobody else wanted to work on,
       strength reduction and other loop optimizations.
  
!    • Paul Woegerer and Tal Agmon for the CRX port.
  
!    • Carlo Wood for various fixes.
  
!    • Tom Wood for work on the m88k port.
  
!    • Chung-Ju Wu for his work on the Andes NDS32 port.
  
!    • Canqun Yang for work on GNU Fortran.
  
!    • Masanobu Yuhara of Fujitsu Laboratories implemented the machine
       description for the Tron architecture (specifically, the Gmicro).
  
!    • Kevin Zachmann helped port GCC to the Tahoe.
  
!    • Ayal Zaks for Swing Modulo Scheduling (SMS).
  
!    • Qirun Zhang for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • 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
  
!    • Jö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
*************** File: gcc.info,  Node: Option Index,  Ne
*** 65001,65020 ****
  A.1 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  471)
  * A:                                     Preprocessor Options.
                                                               (line  336)
- * allowable_client:                      Darwin Options.     (line  197)
  * all_load:                              Darwin Options.     (line  117)
  * analyzer:                              Static Analyzer Options.
                                                               (line    6)
  * ansi:                                  Standards.          (line   13)
--- 65010,65029 ----
  A.1 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  475)
  * A:                                     Preprocessor Options.
                                                               (line  336)
  * all_load:                              Darwin Options.     (line  117)
+ * allowable_client:                      Darwin Options.     (line  197)
  * analyzer:                              Static Analyzer Options.
                                                               (line    6)
  * ansi:                                  Standards.          (line   13)
*************** look up both forms.
*** 65031,65037 ****
  * Bstatic:                               VxWorks Options.    (line   20)
  * bundle:                                Darwin Options.     (line  130)
  * bundle_loader:                         Darwin Options.     (line  134)
! * c:                                     Overall Options.    (line  164)
  * C:                                     Preprocessor Options.
                                                               (line  345)
  * c <1>:                                 Link Options.       (line   17)
--- 65040,65046 ----
  * Bstatic:                               VxWorks Options.    (line   20)
  * bundle:                                Darwin Options.     (line  130)
  * bundle_loader:                         Darwin Options.     (line  134)
! * c:                                     Overall Options.    (line  168)
  * C:                                     Preprocessor Options.
                                                               (line  345)
  * c <1>:                                 Link Options.       (line   17)
*************** look up both forms.
*** 65073,65081 ****
                                                               (line  931)
  * dump-analyzer-feasibility:             Static Analyzer Options.
                                                               (line  940)
! * dumpbase:                              Overall Options.    (line  251)
! * dumpbase-ext:                          Overall Options.    (line  324)
! * dumpdir:                               Overall Options.    (line  352)
  * dumpfullversion:                       Developer Options.  (line 1112)
  * dumpmachine:                           Developer Options.  (line 1100)
  * dumpspecs:                             Developer Options.  (line 1117)
--- 65082,65090 ----
                                                               (line  931)
  * dump-analyzer-feasibility:             Static Analyzer Options.
                                                               (line  940)
! * dumpbase:                              Overall Options.    (line  255)
! * dumpbase-ext:                          Overall Options.    (line  328)
! * dumpdir:                               Overall Options.    (line  356)
  * dumpfullversion:                       Developer Options.  (line 1112)
  * dumpmachine:                           Developer Options.  (line 1100)
  * dumpspecs:                             Developer Options.  (line 1117)
*************** look up both forms.
*** 65085,65091 ****
  * dylinker_install_name:                 Darwin Options.     (line  197)
  * dynamic:                               Darwin Options.     (line  197)
  * dynamiclib:                            Darwin Options.     (line  138)
! * E:                                     Overall Options.    (line  185)
  * E <1>:                                 Link Options.       (line   17)
  * e:                                     Link Options.       (line  173)
  * EB:                                    ARC Options.        (line  600)
--- 65094,65100 ----
  * dylinker_install_name:                 Darwin Options.     (line  197)
  * dynamic:                               Darwin Options.     (line  197)
  * dynamiclib:                            Darwin Options.     (line  138)
! * E:                                     Overall Options.    (line  189)
  * E <1>:                                 Link Options.       (line   17)
  * e:                                     Link Options.       (line  173)
  * EB:                                    ARC Options.        (line  600)
*************** look up both forms.
*** 65103,65109 ****
                                                               (line   23)
  * faccess-control:                       C++ Dialect Options.
                                                               (line  117)
! * fada-spec-parent:                      Overall Options.    (line  666)
  * faggressive-loop-optimizations:        Optimize Options.   (line  553)
  * falign-functions:                      Optimize Options.   (line 1731)
  * falign-jumps:                          Optimize Options.   (line 1813)
--- 65112,65118 ----
                                                               (line   23)
  * faccess-control:                       C++ Dialect Options.
                                                               (line  117)
! * fada-spec-parent:                      Overall Options.    (line  670)
  * faggressive-loop-optimizations:        Optimize Options.   (line  553)
  * falign-functions:                      Optimize Options.   (line 1731)
  * falign-jumps:                          Optimize Options.   (line 1813)
*************** look up both forms.
*** 65149,65155 ****
  * fcall-used:                            Code Gen Options.   (line  440)
  * fcaller-saves:                         Optimize Options.   (line  933)
  * fcallgraph-info:                       Developer Options.  (line   32)
! * fcanon-prefix-map:                     Overall Options.    (line  640)
  * fcf-protection:                        Instrumentation Options.
                                                               (line  739)
  * fchar8_t:                              C++ Dialect Options.
--- 65158,65164 ----
  * fcall-used:                            Code Gen Options.   (line  440)
  * fcaller-saves:                         Optimize Options.   (line  933)
  * fcallgraph-info:                       Developer Options.  (line   32)
! * fcanon-prefix-map:                     Overall Options.    (line  644)
  * fcf-protection:                        Instrumentation Options.
                                                               (line  739)
  * fchar8_t:                              C++ Dialect Options.
*************** look up both forms.
*** 65268,65274 ****
  * fdollars-in-identifiers <1>:           Interoperation.     (line  141)
  * fdpic:                                 SH Options.         (line  387)
  * fdse:                                  Optimize Options.   (line  585)
! * fdump-ada-spec:                        Overall Options.    (line  661)
  * fdump-analyzer:                        Static Analyzer Options.
                                                               (line  905)
  * fdump-analyzer-callgraph:              Static Analyzer Options.
--- 65277,65283 ----
  * fdollars-in-identifiers <1>:           Interoperation.     (line  141)
  * fdpic:                                 SH Options.         (line  387)
  * fdse:                                  Optimize Options.   (line  585)
! * fdump-ada-spec:                        Overall Options.    (line  665)
  * fdump-analyzer:                        Static Analyzer Options.
                                                               (line  905)
  * fdump-analyzer-callgraph:              Static Analyzer Options.
*************** look up both forms.
*** 65290,65296 ****
  * fdump-debug:                           Developer Options.  (line  272)
  * fdump-earlydebug:                      Developer Options.  (line  276)
  * fdump-final-insns:                     Developer Options.  (line  852)
! * fdump-go-spec:                         Overall Options.    (line  670)
  * fdump-ipa:                             Developer Options.  (line  301)
  * fdump-ipa-clones:                      Developer Options.  (line  331)
  * fdump-lang:                            Developer Options.  (line  402)
--- 65299,65305 ----
  * fdump-debug:                           Developer Options.  (line  272)
  * fdump-earlydebug:                      Developer Options.  (line  276)
  * fdump-final-insns:                     Developer Options.  (line  852)
! * fdump-go-spec:                         Overall Options.    (line  674)
  * fdump-ipa:                             Developer Options.  (line  301)
  * fdump-ipa-clones:                      Developer Options.  (line  331)
  * fdump-lang:                            Developer Options.  (line  402)
*************** look up both forms.
*** 65399,65405 ****
                                                               (line  328)
  * ffast-math:                            Optimize Options.   (line 2340)
  * ffat-lto-objects:                      Optimize Options.   (line 2172)
! * ffile-prefix-map:                      Overall Options.    (line  629)
  * ffinite-loops:                         Optimize Options.   (line 1222)
  * ffinite-math-only:                     Optimize Options.   (line 2417)
  * ffix-and-continue:                     Darwin Options.     (line  109)
--- 65408,65414 ----
                                                               (line  328)
  * ffast-math:                            Optimize Options.   (line 2340)
  * ffat-lto-objects:                      Optimize Options.   (line 2172)
! * ffile-prefix-map:                      Overall Options.    (line  633)
  * ffinite-loops:                         Optimize Options.   (line 1222)
  * ffinite-math-only:                     Optimize Options.   (line 2417)
  * ffix-and-continue:                     Darwin Options.     (line  109)
*************** look up both forms.
*** 65786,65793 ****
  * fplan9-extensions:                     C Dialect Options.  (line  453)
  * fplan9-extensions <1>:                 Unnamed Fields.     (line   43)
  * fplt:                                  Code Gen Options.   (line  398)
! * fplugin:                               Overall Options.    (line  650)
! * fplugin-arg:                           Overall Options.    (line  657)
  * fpost-ipa-mem-report:                  Developer Options.  (line  947)
  * fpre-ipa-mem-report:                   Developer Options.  (line  947)
  * fpredictive-commoning:                 Optimize Options.   (line 1556)
--- 65795,65802 ----
  * fplan9-extensions:                     C Dialect Options.  (line  453)
  * fplan9-extensions <1>:                 Unnamed Fields.     (line   43)
  * fplt:                                  Code Gen Options.   (line  398)
! * fplugin:                               Overall Options.    (line  654)
! * fplugin-arg:                           Overall Options.    (line  661)
  * fpost-ipa-mem-report:                  Developer Options.  (line  947)
  * fpre-ipa-mem-report:                   Developer Options.  (line  947)
  * fpredictive-commoning:                 Optimize Options.   (line 1556)
*************** look up both forms.
*** 65986,65991 ****
--- 65995,66001 ----
  * fssa-backprop:                         Optimize Options.   (line 1188)
  * fssa-phiopt:                           Optimize Options.   (line 1194)
  * fsso-struct:                           C Dialect Options.  (line  521)
+ * fstack_reuse:                          Code Gen Options.   (line   14)
  * fstack-check:                          Instrumentation Options.
                                                               (line  813)
  * fstack-clash-protection:               Instrumentation Options.
*************** look up both forms.
*** 66003,66009 ****
  * fstack-protector-strong:               Instrumentation Options.
                                                               (line  802)
  * fstack-usage:                          Developer Options.  (line  984)
- * fstack_reuse:                          Code Gen Options.   (line   14)
  * fstats:                                Developer Options.  (line 1013)
  * fstdarg-opt:                           Optimize Options.   (line 2718)
  * fstore-merging:                        Optimize Options.   (line 1413)
--- 66013,66018 ----
*************** look up both forms.
*** 66180,66186 ****
  * H:                                     Preprocessor Options.
                                                               (line  404)
  * headerpad_max_install_names:           Darwin Options.     (line  197)
! * help:                                  Overall Options.    (line  477)
  * I:                                     Directory Options.  (line    9)
  * I-:                                    Directory Options.  (line   64)
  * idirafter:                             Directory Options.  (line    9)
--- 66189,66195 ----
  * H:                                     Preprocessor Options.
                                                               (line  404)
  * headerpad_max_install_names:           Darwin Options.     (line  197)
! * help:                                  Overall Options.    (line  481)
  * I:                                     Directory Options.  (line    9)
  * I-:                                    Directory Options.  (line   64)
  * idirafter:                             Directory Options.  (line    9)
*************** look up both forms.
*** 66208,66215 ****
                                                               (line   76)
  * m1:                                    SH Options.         (line    8)
  * m10:                                   PDP-11 Options.     (line   28)
! * m128bit-long-double:                   x86 Options.        (line  733)
! * m16:                                   x86 Options.        (line 1648)
  * m16-bit:                               CRIS Options.       (line   59)
  * m16-bit <1>:                           NDS32 Options.      (line   50)
  * m1reg-:                                Adapteva Epiphany Options.
--- 66217,66224 ----
                                                               (line   76)
  * m1:                                    SH Options.         (line    8)
  * m10:                                   PDP-11 Options.     (line   28)
! * m128bit-long-double:                   x86 Options.        (line  732)
! * m16:                                   x86 Options.        (line 1647)
  * m16-bit:                               CRIS Options.       (line   59)
  * m16-bit <1>:                           NDS32 Options.      (line   50)
  * m1reg-:                                Adapteva Epiphany Options.
*************** look up both forms.
*** 66226,66232 ****
  * m32:                                   RS/6000 and PowerPC Options.
                                                               (line  243)
  * m32 <1>:                               SPARC Options.      (line  313)
! * m32 <2>:                               x86 Options.        (line 1648)
  * m32-bit:                               CRIS Options.       (line   59)
  * m32bit-doubles:                        RL78 Options.       (line   71)
  * m32bit-doubles <1>:                    RX Options.         (line    8)
--- 66235,66241 ----
  * m32:                                   RS/6000 and PowerPC Options.
                                                               (line  243)
  * m32 <1>:                               SPARC Options.      (line  313)
! * m32 <2>:                               x86 Options.        (line 1647)
  * m32-bit:                               CRIS Options.       (line   59)
  * m32bit-doubles:                        RL78 Options.       (line   71)
  * m32bit-doubles <1>:                    RX Options.         (line    8)
*************** look up both forms.
*** 66234,66241 ****
  * m32r2:                                 M32R/D Options.     (line    8)
  * m32rx:                                 M32R/D Options.     (line   11)
  * m340:                                  MCore Options.      (line   41)
! * m3dnow:                                x86 Options.        (line  967)
! * m3dnowa:                               x86 Options.        (line  968)
  * m3e:                                   SH Options.         (line   36)
  * m4:                                    SH Options.         (line   50)
  * m4-100:                                SH Options.         (line   53)
--- 66243,66250 ----
  * m32r2:                                 M32R/D Options.     (line    8)
  * m32rx:                                 M32R/D Options.     (line   11)
  * m340:                                  MCore Options.      (line   41)
! * m3dnow:                                x86 Options.        (line  966)
! * m3dnowa:                               x86 Options.        (line  967)
  * m3e:                                   SH Options.         (line   36)
  * m4:                                    SH Options.         (line   50)
  * m4-100:                                SH Options.         (line   53)
*************** look up both forms.
*** 66274,66280 ****
  * m64 <2>:                               S/390 and zSeries Options.
                                                               (line   84)
  * m64 <3>:                               SPARC Options.      (line  313)
! * m64 <4>:                               x86 Options.        (line 1648)
  * m64bit-doubles:                        RL78 Options.       (line   71)
  * m64bit-doubles <1>:                    RX Options.         (line    8)
  * m68000:                                M680x0 Options.     (line   92)
--- 66283,66289 ----
  * m64 <2>:                               S/390 and zSeries Options.
                                                               (line   84)
  * m64 <3>:                               SPARC Options.      (line  313)
! * m64 <4>:                               x86 Options.        (line 1647)
  * m64bit-doubles:                        RL78 Options.       (line   71)
  * m64bit-doubles <1>:                    RX Options.         (line    8)
  * m68000:                                M680x0 Options.     (line   92)
*************** look up both forms.
*** 66287,66296 ****
  * m68060:                                M680x0 Options.     (line  126)
  * m68881:                                M680x0 Options.     (line  193)
  * m8-bit:                                CRIS Options.       (line   59)
! * m80387:                                x86 Options.        (line  681)
! * m8bit-idiv:                            x86 Options.        (line 1552)
  * m8byte-align:                          V850 Options.       (line  168)
! * m96bit-long-double:                    x86 Options.        (line  733)
  * mA6:                                   ARC Options.        (line   23)
  * mA7:                                   ARC Options.        (line   29)
  * mabi:                                  AArch64 Options.    (line    8)
--- 66296,66305 ----
  * m68060:                                M680x0 Options.     (line  126)
  * m68881:                                M680x0 Options.     (line  193)
  * m8-bit:                                CRIS Options.       (line   59)
! * m80387:                                x86 Options.        (line  680)
! * m8bit-idiv:                            x86 Options.        (line 1551)
  * m8byte-align:                          V850 Options.       (line  168)
! * m96bit-long-double:                    x86 Options.        (line  732)
  * mA6:                                   ARC Options.        (line   23)
  * mA7:                                   ARC Options.        (line   29)
  * mabi:                                  AArch64 Options.    (line    8)
*************** look up both forms.
*** 66300,66306 ****
  * mabi <4>:                              RISC-V Options.     (line   16)
  * mabi <5>:                              RS/6000 and PowerPC Options.
                                                               (line  551)
! * mabi <6>:                              x86 Options.        (line 1236)
  * mabi <7>:                              Xtensa Options.     (line  102)
  * mabi=32:                               MIPS Options.       (line  151)
  * mabi=64:                               MIPS Options.       (line  151)
--- 66309,66315 ----
  * mabi <4>:                              RISC-V Options.     (line   16)
  * mabi <5>:                              RS/6000 and PowerPC Options.
                                                               (line  551)
! * mabi <6>:                              x86 Options.        (line 1235)
  * mabi <7>:                              Xtensa Options.     (line  102)
  * mabi=32:                               MIPS Options.       (line  151)
  * mabi=64:                               MIPS Options.       (line  151)
*************** look up both forms.
*** 66320,66342 ****
  * mabi=o64:                              MIPS Options.       (line  151)
  * mabi=windowed:                         Xtensa Options.     (line  114)
  * mabicalls:                             MIPS Options.       (line  190)
! * mabm:                                  x86 Options.        (line  970)
  * mabort-on-noreturn:                    ARM Options.        (line  778)
  * mabs=2008:                             MIPS Options.       (line  298)
  * mabs=legacy:                           MIPS Options.       (line  298)
! * mabsdata:                              AVR Options.        (line  188)
  * mac0:                                  PDP-11 Options.     (line   15)
  * macc-4:                                FRV Options.        (line  138)
  * macc-8:                                FRV Options.        (line  142)
! * maccumulate-args:                      AVR Options.        (line  195)
  * maccumulate-outgoing-args:             SH Options.         (line  313)
! * maccumulate-outgoing-args <1>:         x86 Options.        (line 1290)
! * maddress-mode=long:                    x86 Options.        (line 1702)
! * maddress-mode=short:                   x86 Options.        (line 1707)
  * mads:                                  RS/6000 and PowerPC Options.
                                                               (line  613)
! * madx:                                  x86 Options.        (line  971)
! * maes:                                  x86 Options.        (line  948)
  * maix-struct-return:                    RS/6000 and PowerPC Options.
                                                               (line  544)
  * maix32:                                RS/6000 and PowerPC Options.
--- 66329,66351 ----
  * mabi=o64:                              MIPS Options.       (line  151)
  * mabi=windowed:                         Xtensa Options.     (line  114)
  * mabicalls:                             MIPS Options.       (line  190)
! * mabm:                                  x86 Options.        (line  969)
  * mabort-on-noreturn:                    ARM Options.        (line  778)
  * mabs=2008:                             MIPS Options.       (line  298)
  * mabs=legacy:                           MIPS Options.       (line  298)
! * mabsdata:                              AVR Options.        (line  194)
  * mac0:                                  PDP-11 Options.     (line   15)
  * macc-4:                                FRV Options.        (line  138)
  * macc-8:                                FRV Options.        (line  142)
! * maccumulate-args:                      AVR Options.        (line  201)
  * maccumulate-outgoing-args:             SH Options.         (line  313)
! * maccumulate-outgoing-args <1>:         x86 Options.        (line 1289)
! * maddress-mode=long:                    x86 Options.        (line 1701)
! * maddress-mode=short:                   x86 Options.        (line 1706)
  * mads:                                  RS/6000 and PowerPC Options.
                                                               (line  613)
! * madx:                                  x86 Options.        (line  970)
! * maes:                                  x86 Options.        (line  947)
  * maix-struct-return:                    RS/6000 and PowerPC Options.
                                                               (line  544)
  * maix32:                                RS/6000 and PowerPC Options.
*************** look up both forms.
*** 66346,66353 ****
  * malign-300:                            H8/300 Options.     (line   40)
  * malign-call:                           ARC Options.        (line  441)
  * malign-data:                           RISC-V Options.     (line  178)
! * malign-data <1>:                       x86 Options.        (line  774)
! * malign-double:                         x86 Options.        (line  718)
  * malign-int:                            M680x0 Options.     (line  260)
  * malign-labels:                         FRV Options.        (line  127)
  * malign-loops:                          M32R/D Options.     (line   72)
--- 66355,66362 ----
  * malign-300:                            H8/300 Options.     (line   40)
  * malign-call:                           ARC Options.        (line  441)
  * malign-data:                           RISC-V Options.     (line  178)
! * malign-data <1>:                       x86 Options.        (line  773)
! * malign-double:                         x86 Options.        (line  717)
  * malign-int:                            M680x0 Options.     (line  260)
  * malign-labels:                         FRV Options.        (line  127)
  * malign-loops:                          M32R/D Options.     (line   72)
*************** look up both forms.
*** 66355,66361 ****
                                                               (line  319)
  * malign-power:                          RS/6000 and PowerPC Options.
                                                               (line  319)
! * malign-stringops:                      x86 Options.        (line 1426)
  * malloc-cc:                             FRV Options.        (line   30)
  * mallow-string-insns:                   RX Options.         (line  148)
  * mallregs:                              RL78 Options.       (line   65)
--- 66364,66370 ----
                                                               (line  319)
  * malign-power:                          RS/6000 and PowerPC Options.
                                                               (line  319)
! * malign-stringops:                      x86 Options.        (line 1425)
  * malloc-cc:                             FRV Options.        (line   30)
  * mallow-string-insns:                   RX Options.         (line  148)
  * mallregs:                              RL78 Options.       (line   65)
*************** look up both forms.
*** 66365,66375 ****
  * mam33:                                 MN10300 Options.    (line   16)
  * mam33-2:                               MN10300 Options.    (line   23)
  * mam34:                                 MN10300 Options.    (line   26)
! * mamx-bf16:                             x86 Options.        (line 1009)
! * mamx-complex:                          x86 Options.        (line 1020)
! * mamx-fp16:                             x86 Options.        (line 1017)
! * mamx-int8:                             x86 Options.        (line 1008)
! * mamx-tile:                             x86 Options.        (line 1007)
  * manchor:                               C-SKY Options.      (line  124)
  * mandroid:                              GNU/Linux Options.  (line   25)
  * mannotate-align:                       ARC Options.        (line  390)
--- 66374,66384 ----
  * mam33:                                 MN10300 Options.    (line   16)
  * mam33-2:                               MN10300 Options.    (line   23)
  * mam34:                                 MN10300 Options.    (line   26)
! * mamx-bf16:                             x86 Options.        (line 1008)
! * mamx-complex:                          x86 Options.        (line 1019)
! * mamx-fp16:                             x86 Options.        (line 1016)
! * mamx-int8:                             x86 Options.        (line 1007)
! * mamx-tile:                             x86 Options.        (line 1006)
  * manchor:                               C-SKY Options.      (line  124)
  * mandroid:                              GNU/Linux Options.  (line   25)
  * mannotate-align:                       ARC Options.        (line  390)
*************** look up both forms.
*** 66406,66412 ****
  * mas100-syntax:                         RX Options.         (line   74)
  * masm-hex:                              MSP430 Options.     (line    8)
  * masm-syntax-unified:                   ARM Options.        (line  958)
! * masm=DIALECT:                          x86 Options.        (line  668)
  * matomic:                               ARC Options.        (line  163)
  * matomic-libcalls:                      HPPA Options.       (line   22)
  * matomic-model=MODEL:                   SH Options.         (line  192)
--- 66415,66421 ----
  * mas100-syntax:                         RX Options.         (line   74)
  * masm-hex:                              MSP430 Options.     (line    8)
  * masm-syntax-unified:                   ARM Options.        (line  958)
! * masm=DIALECT:                          x86 Options.        (line  667)
  * matomic:                               ARC Options.        (line  163)
  * matomic-libcalls:                      HPPA Options.       (line   22)
  * matomic-model=MODEL:                   SH Options.         (line  192)
*************** look up both forms.
*** 66415,66454 ****
  * mauto-pic:                             IA-64 Options.      (line   49)
  * mavoid-indexed-addresses:              RS/6000 and PowerPC Options.
                                                               (line  358)
! * mavx:                                  x86 Options.        (line  936)
! * mavx2:                                 x86 Options.        (line  937)
! * mavx256-split-unaligned-load:          x86 Options.        (line 1560)
! * mavx256-split-unaligned-store:         x86 Options.        (line 1560)
! * mavx5124fmaps:                         x86 Options.        (line 1001)
! * mavx5124vnniw:                         x86 Options.        (line 1004)
! * mavx512bf16:                           x86 Options.        (line  987)
! * mavx512bitalg:                         x86 Options.        (line  993)
! * mavx512bw:                             x86 Options.        (line  943)
! * mavx512cd:                             x86 Options.        (line  941)
! * mavx512dq:                             x86 Options.        (line  944)
! * mavx512er:                             x86 Options.        (line  940)
! * mavx512f:                              x86 Options.        (line  938)
! * mavx512fp16:                           x86 Options.        (line  988)
! * mavx512ifma:                           x86 Options.        (line  945)
! * mavx512pf:                             x86 Options.        (line  939)
! * mavx512vbmi:                           x86 Options.        (line  946)
! * mavx512vbmi2:                          x86 Options.        (line  986)
! * mavx512vl:                             x86 Options.        (line  942)
! * mavx512vnni:                           x86 Options.        (line 1002)
! * mavx512vp2intersect:                   x86 Options.        (line 1000)
! * mavx512vpopcntdq:                      x86 Options.        (line  999)
! * mavxifma:                              x86 Options.        (line 1013)
! * mavxneconvert:                         x86 Options.        (line 1015)
! * mavxvnni:                              x86 Options.        (line 1003)
! * mavxvnniint8:                          x86 Options.        (line 1014)
  * max-vect-align:                        Adapteva Epiphany Options.
                                                               (line  118)
  * mb:                                    SH Options.         (line  125)
  * mbackchain:                            S/390 and zSeries Options.
                                                               (line   33)
  * mbarrel-shift-enabled:                 LM32 Options.       (line    8)
  * mbarrel-shifter:                       ARC Options.        (line    9)
- * mbarrel_shifter:                       ARC Options.        (line  614)
  * mbase-addresses:                       MMIX Options.       (line   51)
  * mbbit-peephole:                        ARC Options.        (line  447)
  * mbe8:                                  ARM Options.        (line   70)
--- 66424,66463 ----
  * mauto-pic:                             IA-64 Options.      (line   49)
  * mavoid-indexed-addresses:              RS/6000 and PowerPC Options.
                                                               (line  358)
! * mavx:                                  x86 Options.        (line  935)
! * mavx2:                                 x86 Options.        (line  936)
! * mavx256-split-unaligned-load:          x86 Options.        (line 1559)
! * mavx256-split-unaligned-store:         x86 Options.        (line 1559)
! * mavx5124fmaps:                         x86 Options.        (line 1000)
! * mavx5124vnniw:                         x86 Options.        (line 1003)
! * mavx512bf16:                           x86 Options.        (line  986)
! * mavx512bitalg:                         x86 Options.        (line  992)
! * mavx512bw:                             x86 Options.        (line  942)
! * mavx512cd:                             x86 Options.        (line  940)
! * mavx512dq:                             x86 Options.        (line  943)
! * mavx512er:                             x86 Options.        (line  939)
! * mavx512f:                              x86 Options.        (line  937)
! * mavx512fp16:                           x86 Options.        (line  987)
! * mavx512ifma:                           x86 Options.        (line  944)
! * mavx512pf:                             x86 Options.        (line  938)
! * mavx512vbmi:                           x86 Options.        (line  945)
! * mavx512vbmi2:                          x86 Options.        (line  985)
! * mavx512vl:                             x86 Options.        (line  941)
! * mavx512vnni:                           x86 Options.        (line 1001)
! * mavx512vp2intersect:                   x86 Options.        (line  999)
! * mavx512vpopcntdq:                      x86 Options.        (line  998)
! * mavxifma:                              x86 Options.        (line 1012)
! * mavxneconvert:                         x86 Options.        (line 1014)
! * mavxvnni:                              x86 Options.        (line 1002)
! * mavxvnniint8:                          x86 Options.        (line 1013)
  * max-vect-align:                        Adapteva Epiphany Options.
                                                               (line  118)
  * mb:                                    SH Options.         (line  125)
  * mbackchain:                            S/390 and zSeries Options.
                                                               (line   33)
+ * mbarrel_shifter:                       ARC Options.        (line  614)
  * mbarrel-shift-enabled:                 LM32 Options.       (line    8)
  * mbarrel-shifter:                       ARC Options.        (line    9)
  * mbase-addresses:                       MMIX Options.       (line   51)
  * mbbit-peephole:                        ARC Options.        (line  447)
  * mbe8:                                  ARM Options.        (line   70)
*************** look up both forms.
*** 66482,66493 ****
                                                               (line  699)
  * mblock-move-inline-limit:              RS/6000 and PowerPC Options.
                                                               (line  687)
! * mbmi:                                  x86 Options.        (line  972)
! * mbmi2:                                 x86 Options.        (line  973)
  * mboard:                                OpenRISC Options.   (line    8)
  * mbranch-cost:                          Adapteva Epiphany Options.
                                                               (line   17)
! * mbranch-cost <1>:                      AVR Options.        (line  210)
  * mbranch-cost <2>:                      LoongArch Options.  (line   79)
  * mbranch-cost <3>:                      MIPS Options.       (line  790)
  * mbranch-cost <4>:                      RISC-V Options.     (line    8)
--- 66491,66502 ----
                                                               (line  699)
  * mblock-move-inline-limit:              RS/6000 and PowerPC Options.
                                                               (line  687)
! * mbmi:                                  x86 Options.        (line  971)
! * mbmi2:                                 x86 Options.        (line  972)
  * mboard:                                OpenRISC Options.   (line    8)
  * mbranch-cost:                          Adapteva Epiphany Options.
                                                               (line   17)
! * mbranch-cost <1>:                      AVR Options.        (line  216)
  * mbranch-cost <2>:                      LoongArch Options.  (line   79)
  * mbranch-cost <3>:                      MIPS Options.       (line  790)
  * mbranch-cost <4>:                      RISC-V Options.     (line    8)
*************** look up both forms.
*** 66517,66528 ****
                                                               (line  528)
  * mcall-linux:                           RS/6000 and PowerPC Options.
                                                               (line  524)
! * mcall-ms2sysv-xlogues:                 x86 Options.        (line 1266)
  * mcall-netbsd:                          RS/6000 and PowerPC Options.
                                                               (line  532)
  * mcall-openbsd:                         RS/6000 and PowerPC Options.
                                                               (line  536)
! * mcall-prologues:                       AVR Options.        (line  215)
  * mcall-sysv:                            RS/6000 and PowerPC Options.
                                                               (line  506)
  * mcall-sysv-eabi:                       RS/6000 and PowerPC Options.
--- 66526,66537 ----
                                                               (line  528)
  * mcall-linux:                           RS/6000 and PowerPC Options.
                                                               (line  524)
! * mcall-ms2sysv-xlogues:                 x86 Options.        (line 1265)
  * mcall-netbsd:                          RS/6000 and PowerPC Options.
                                                               (line  532)
  * mcall-openbsd:                         RS/6000 and PowerPC Options.
                                                               (line  536)
! * mcall-prologues:                       AVR Options.        (line  221)
  * mcall-sysv:                            RS/6000 and PowerPC Options.
                                                               (line  506)
  * mcall-sysv-eabi:                       RS/6000 and PowerPC Options.
*************** look up both forms.
*** 66538,66572 ****
  * mcbranch-force-delay-slot:             SH Options.         (line  348)
  * mcc-init:                              CRIS Options.       (line   39)
  * mccrt:                                 C-SKY Options.      (line  153)
! * mcet-switch:                           x86 Options.        (line 1256)
  * mcfv4e:                                M680x0 Options.     (line  169)
  * mcheck-zero-division:                  LoongArch Options.  (line   82)
  * mcheck-zero-division <1>:              MIPS Options.       (line  568)
  * mcix:                                  DEC Alpha Options.  (line  155)
! * mcld:                                  x86 Options.        (line 1074)
! * mcldemote:                             x86 Options.        (line 1005)
  * mclear-hwcap:                          Solaris 2 Options.  (line    8)
! * mclflushopt:                           x86 Options.        (line  950)
! * mclwb:                                 x86 Options.        (line  951)
! * mclzero:                               x86 Options.        (line  984)
  * mcmodel:                               NDS32 Options.      (line   66)
  * mcmodel <1>:                           SPARC Options.      (line  319)
! * mcmodel=kernel:                        x86 Options.        (line 1686)
  * mcmodel=large:                         AArch64 Options.    (line   44)
  * mcmodel=large <1>:                     OpenRISC Options.   (line   76)
  * mcmodel=large <2>:                     RS/6000 and PowerPC Options.
                                                               (line  130)
! * mcmodel=large <3>:                     x86 Options.        (line 1698)
  * mcmodel=medany:                        RISC-V Options.     (line  148)
  * mcmodel=medium:                        RS/6000 and PowerPC Options.
                                                               (line  125)
! * mcmodel=medium <1>:                    x86 Options.        (line 1691)
  * mcmodel=medlow:                        RISC-V Options.     (line  141)
  * mcmodel=small:                         AArch64 Options.    (line   38)
  * mcmodel=small <1>:                     OpenRISC Options.   (line   72)
  * mcmodel=small <2>:                     RS/6000 and PowerPC Options.
                                                               (line  121)
! * mcmodel=small <3>:                     x86 Options.        (line 1680)
  * mcmodel=tiny:                          AArch64 Options.    (line   33)
  * mcmov:                                 NDS32 Options.      (line   20)
  * mcmov <1>:                             OpenRISC Options.   (line   44)
--- 66547,66581 ----
  * mcbranch-force-delay-slot:             SH Options.         (line  348)
  * mcc-init:                              CRIS Options.       (line   39)
  * mccrt:                                 C-SKY Options.      (line  153)
! * mcet-switch:                           x86 Options.        (line 1255)
  * mcfv4e:                                M680x0 Options.     (line  169)
  * mcheck-zero-division:                  LoongArch Options.  (line   82)
  * mcheck-zero-division <1>:              MIPS Options.       (line  568)
  * mcix:                                  DEC Alpha Options.  (line  155)
! * mcld:                                  x86 Options.        (line 1073)
! * mcldemote:                             x86 Options.        (line 1004)
  * mclear-hwcap:                          Solaris 2 Options.  (line    8)
! * mclflushopt:                           x86 Options.        (line  949)
! * mclwb:                                 x86 Options.        (line  950)
! * mclzero:                               x86 Options.        (line  983)
  * mcmodel:                               NDS32 Options.      (line   66)
  * mcmodel <1>:                           SPARC Options.      (line  319)
! * mcmodel=kernel:                        x86 Options.        (line 1685)
  * mcmodel=large:                         AArch64 Options.    (line   44)
  * mcmodel=large <1>:                     OpenRISC Options.   (line   76)
  * mcmodel=large <2>:                     RS/6000 and PowerPC Options.
                                                               (line  130)
! * mcmodel=large <3>:                     x86 Options.        (line 1697)
  * mcmodel=medany:                        RISC-V Options.     (line  148)
  * mcmodel=medium:                        RS/6000 and PowerPC Options.
                                                               (line  125)
! * mcmodel=medium <1>:                    x86 Options.        (line 1690)
  * mcmodel=medlow:                        RISC-V Options.     (line  141)
  * mcmodel=small:                         AArch64 Options.    (line   38)
  * mcmodel=small <1>:                     OpenRISC Options.   (line   72)
  * mcmodel=small <2>:                     RS/6000 and PowerPC Options.
                                                               (line  121)
! * mcmodel=small <3>:                     x86 Options.        (line 1679)
  * mcmodel=tiny:                          AArch64 Options.    (line   33)
  * mcmov:                                 NDS32 Options.      (line   20)
  * mcmov <1>:                             OpenRISC Options.   (line   44)
*************** look up both forms.
*** 66574,66580 ****
                                                               (line   22)
  * mcmpb:                                 RS/6000 and PowerPC Options.
                                                               (line   21)
! * mcmpccxadd:                            x86 Options.        (line 1016)
  * mcmse:                                 ARM Options.        (line  987)
  * mco-re:                                eBPF Options.       (line   55)
  * mcode-density:                         ARC Options.        (line  171)
--- 66583,66589 ----
                                                               (line   22)
  * mcmpb:                                 RS/6000 and PowerPC Options.
                                                               (line   21)
! * mcmpccxadd:                            x86 Options.        (line 1015)
  * mcmse:                                 ARM Options.        (line  987)
  * mco-re:                                eBPF Options.       (line   55)
  * mcode-density:                         ARC Options.        (line  171)
*************** look up both forms.
*** 66618,66632 ****
  * mcpu <11>:                             RX Options.         (line   29)
  * mcpu <12>:                             SPARC Options.      (line  114)
  * mcpu <13>:                             Visium Options.     (line   32)
! * mcpu <14>:                             x86 Options.        (line  614)
! * mcpu32:                                M680x0 Options.     (line  135)
  * mcpu=:                                 Blackfin Options.   (line    6)
  * mcpu= <1>:                             C-SKY Options.      (line   13)
  * mcpu= <2>:                             M32C Options.       (line    6)
  * mcpu= <3>:                             MicroBlaze Options. (line   19)
  * mcpu= <4>:                             MSP430 Options.     (line   71)
  * mcrc:                                  MIPS Options.       (line  414)
! * mcrc32:                                x86 Options.        (line 1152)
  * mcrypto:                               RS/6000 and PowerPC Options.
                                                               (line  176)
  * mcsr-check:                            RISC-V Options.     (line  174)
--- 66627,66641 ----
  * mcpu <11>:                             RX Options.         (line   29)
  * mcpu <12>:                             SPARC Options.      (line  114)
  * mcpu <13>:                             Visium Options.     (line   32)
! * mcpu <14>:                             x86 Options.        (line  613)
  * mcpu=:                                 Blackfin Options.   (line    6)
  * mcpu= <1>:                             C-SKY Options.      (line   13)
  * mcpu= <2>:                             M32C Options.       (line    6)
  * mcpu= <3>:                             MicroBlaze Options. (line   19)
  * mcpu= <4>:                             MSP430 Options.     (line   71)
+ * mcpu32:                                M680x0 Options.     (line  135)
  * mcrc:                                  MIPS Options.       (line  414)
! * mcrc32:                                x86 Options.        (line 1151)
  * mcrypto:                               RS/6000 and PowerPC Options.
                                                               (line  176)
  * mcsr-check:                            RISC-V Options.     (line  174)
*************** look up both forms.
*** 66635,66647 ****
  * mctor-dtor:                            NDS32 Options.      (line   80)
  * mcustom-fpu-cfg:                       Nios II Options.    (line  258)
  * mcustom-INSN:                          Nios II Options.    (line  137)
! * mcx16:                                 x86 Options.        (line 1125)
  * MD:                                    Preprocessor Options.
                                                               (line  171)
  * mdalign:                               SH Options.         (line  131)
  * mdata-align:                           CRIS Options.       (line   47)
  * mdata-region:                          MSP430 Options.     (line  148)
! * mdaz-ftz:                              x86 Options.        (line  862)
  * mdebug:                                M32R/D Options.     (line   68)
  * mdebug <1>:                            S/390 and zSeries Options.
                                                               (line  142)
--- 66644,66656 ----
  * mctor-dtor:                            NDS32 Options.      (line   80)
  * mcustom-fpu-cfg:                       Nios II Options.    (line  258)
  * mcustom-INSN:                          Nios II Options.    (line  137)
! * mcx16:                                 x86 Options.        (line 1124)
  * MD:                                    Preprocessor Options.
                                                               (line  171)
  * mdalign:                               SH Options.         (line  131)
  * mdata-align:                           CRIS Options.       (line   47)
  * mdata-region:                          MSP430 Options.     (line  148)
! * mdaz-ftz:                              x86 Options.        (line  861)
  * mdebug:                                M32R/D Options.     (line   68)
  * mdebug <1>:                            S/390 and zSeries Options.
                                                               (line  142)
*************** look up both forms.
*** 66649,66655 ****
  * mdebug-main=PREFIX:                    VMS Options.        (line   12)
  * mdec-asm:                              PDP-11 Options.     (line   45)
  * mdirect-extern-access:                 LoongArch Options.  (line  154)
! * mdirect-extern-access <1>:             x86 Options.        (line 1718)
  * mdisable-callt:                        V850 Options.       (line   90)
  * mdisable-fpregs:                       HPPA Options.       (line   56)
  * mdisable-indexing:                     HPPA Options.       (line   59)
--- 66658,66664 ----
  * mdebug-main=PREFIX:                    VMS Options.        (line   12)
  * mdec-asm:                              PDP-11 Options.     (line   45)
  * mdirect-extern-access:                 LoongArch Options.  (line  154)
! * mdirect-extern-access <1>:             x86 Options.        (line 1717)
  * mdisable-callt:                        V850 Options.       (line   90)
  * mdisable-fpregs:                       HPPA Options.       (line   56)
  * mdisable-indexing:                     HPPA Options.       (line   59)
*************** look up both forms.
*** 66668,66690 ****
  * mdlmzb:                                RS/6000 and PowerPC Options.
                                                               (line  383)
  * mdmx:                                  MIPS Options.       (line  374)
! * mdouble:                               AVR Options.        (line  219)
  * mdouble <1>:                           FRV Options.        (line   47)
  * mdouble-float:                         C-SKY Options.      (line   56)
  * mdouble-float <1>:                     LoongArch Options.  (line   74)
  * mdouble-float <2>:                     MIPS Options.       (line  287)
  * mdouble-float <3>:                     OpenRISC Options.   (line   32)
  * mdpfp:                                 ARC Options.        (line  107)
- * mdpfp-compact:                         ARC Options.        (line  107)
- * mdpfp-fast:                            ARC Options.        (line  112)
  * mdpfp_compact:                         ARC Options.        (line  617)
  * mdpfp_fast:                            ARC Options.        (line  620)
  * mdsp:                                  C-SKY Options.      (line  101)
  * mdsp <1>:                              MIPS Options.       (line  351)
  * mdsp-packa:                            ARC Options.        (line  343)
  * mdspr2:                                MIPS Options.       (line  357)
! * mdsp_packa:                            ARC Options.        (line  623)
! * mdump-tune-features:                   x86 Options.        (line 1056)
  * mdvbf:                                 ARC Options.        (line  348)
  * mdwarf2-asm:                           IA-64 Options.      (line   92)
  * mdword:                                FRV Options.        (line   39)
--- 66677,66699 ----
  * mdlmzb:                                RS/6000 and PowerPC Options.
                                                               (line  383)
  * mdmx:                                  MIPS Options.       (line  374)
! * mdouble:                               AVR Options.        (line  225)
  * mdouble <1>:                           FRV Options.        (line   47)
  * mdouble-float:                         C-SKY Options.      (line   56)
  * mdouble-float <1>:                     LoongArch Options.  (line   74)
  * mdouble-float <2>:                     MIPS Options.       (line  287)
  * mdouble-float <3>:                     OpenRISC Options.   (line   32)
  * mdpfp:                                 ARC Options.        (line  107)
  * mdpfp_compact:                         ARC Options.        (line  617)
  * mdpfp_fast:                            ARC Options.        (line  620)
+ * mdpfp-compact:                         ARC Options.        (line  107)
+ * mdpfp-fast:                            ARC Options.        (line  112)
  * mdsp:                                  C-SKY Options.      (line  101)
  * mdsp <1>:                              MIPS Options.       (line  351)
+ * mdsp_packa:                            ARC Options.        (line  623)
  * mdsp-packa:                            ARC Options.        (line  343)
  * mdspr2:                                MIPS Options.       (line  357)
! * mdump-tune-features:                   x86 Options.        (line 1055)
  * mdvbf:                                 ARC Options.        (line  348)
  * mdwarf2-asm:                           IA-64 Options.      (line   92)
  * mdword:                                FRV Options.        (line   39)
*************** look up both forms.
*** 66709,66715 ****
                                                               (line  627)
  * membedded-data:                        MIPS Options.       (line  515)
  * memregs=:                              M32C Options.       (line   20)
! * menqcmd:                               x86 Options.        (line  996)
  * mep:                                   V850 Options.       (line   14)
  * mepsilon:                              MMIX Options.       (line   13)
  * mesa:                                  S/390 and zSeries Options.
--- 66718,66724 ----
                                                               (line  627)
  * membedded-data:                        MIPS Options.       (line  515)
  * memregs=:                              M32C Options.       (line   20)
! * menqcmd:                               x86 Options.        (line  995)
  * mep:                                   V850 Options.       (line   14)
  * mepsilon:                              MMIX Options.       (line   13)
  * mesa:                                  S/390 and zSeries Options.
*************** look up both forms.
*** 66730,66737 ****
  * mextra-l32r-costs:                     Xtensa Options.     (line  123)
  * MF:                                    Preprocessor Options.
                                                               (line  110)
! * mf16c:                                 x86 Options.        (line  955)
! * mfancy-math-387:                       x86 Options.        (line  709)
  * mfast-fp:                              Blackfin Options.   (line  129)
  * mfast-indirect-calls:                  HPPA Options.       (line   64)
  * mfast-sw-div:                          Nios II Options.    (line  113)
--- 66739,66746 ----
  * mextra-l32r-costs:                     Xtensa Options.     (line  123)
  * MF:                                    Preprocessor Options.
                                                               (line  110)
! * mf16c:                                 x86 Options.        (line  954)
! * mfancy-math-387:                       x86 Options.        (line  708)
  * mfast-fp:                              Blackfin Options.   (line  129)
  * mfast-indirect-calls:                  HPPA Options.       (line   64)
  * mfast-sw-div:                          Nios II Options.    (line  113)
*************** look up both forms.
*** 66740,66748 ****
  * mfdivdu:                               C-SKY Options.      (line   62)
  * mfdpic:                                ARM Options.        (line 1010)
  * mfdpic <1>:                            FRV Options.        (line   71)
! * mfentry:                               x86 Options.        (line 1499)
! * mfentry-name:                          x86 Options.        (line 1531)
! * mfentry-section:                       x86 Options.        (line 1535)
  * mfix:                                  DEC Alpha Options.  (line  155)
  * mfix-24k:                              MIPS Options.       (line  645)
  * mfix-and-continue:                     Darwin Options.     (line  109)
--- 66749,66757 ----
  * mfdivdu:                               C-SKY Options.      (line   62)
  * mfdpic:                                ARM Options.        (line 1010)
  * mfdpic <1>:                            FRV Options.        (line   71)
! * mfentry:                               x86 Options.        (line 1498)
! * mfentry-name:                          x86 Options.        (line 1530)
! * mfentry-section:                       x86 Options.        (line 1534)
  * mfix:                                  DEC Alpha Options.  (line  155)
  * mfix-24k:                              MIPS Options.       (line  645)
  * mfix-and-continue:                     Darwin Options.     (line  109)
*************** look up both forms.
*** 66780,66803 ****
  * mflush-func:                           MIPS Options.       (line  780)
  * mflush-func=NAME:                      M32R/D Options.     (line   92)
  * mflush-trap=NUMBER:                    M32R/D Options.     (line   85)
! * mfma:                                  x86 Options.        (line  956)
! * mfma4:                                 x86 Options.        (line  959)
  * mfmaf:                                 SPARC Options.      (line  265)
  * mfmovd:                                SH Options.         (line  147)
! * mforce-indirect-call:                  x86 Options.        (line 1245)
  * mforce-no-pic:                         Xtensa Options.     (line   40)
  * mfp-exceptions:                        MIPS Options.       (line  830)
  * mfp-mode:                              Adapteva Epiphany Options.
                                                               (line   70)
  * mfp-reg:                               DEC Alpha Options.  (line   23)
! * mfp-ret-in-387:                        x86 Options.        (line  699)
  * mfp-rounding-mode:                     DEC Alpha Options.  (line   84)
  * mfp-trap-mode:                         DEC Alpha Options.  (line   62)
  * mfp16-format:                          ARM Options.        (line  756)
  * mfp32:                                 MIPS Options.       (line  257)
  * mfp64:                                 MIPS Options.       (line  260)
  * mfpmath:                               Optimize Options.   (line 2334)
! * mfpmath <1>:                           x86 Options.        (line  617)
  * mfpr-32:                               FRV Options.        (line   14)
  * mfpr-64:                               FRV Options.        (line   18)
  * mfprnd:                                RS/6000 and PowerPC Options.
--- 66789,66812 ----
  * mflush-func:                           MIPS Options.       (line  780)
  * mflush-func=NAME:                      M32R/D Options.     (line   92)
  * mflush-trap=NUMBER:                    M32R/D Options.     (line   85)
! * mfma:                                  x86 Options.        (line  955)
! * mfma4:                                 x86 Options.        (line  958)
  * mfmaf:                                 SPARC Options.      (line  265)
  * mfmovd:                                SH Options.         (line  147)
! * mforce-indirect-call:                  x86 Options.        (line 1244)
  * mforce-no-pic:                         Xtensa Options.     (line   40)
  * mfp-exceptions:                        MIPS Options.       (line  830)
  * mfp-mode:                              Adapteva Epiphany Options.
                                                               (line   70)
  * mfp-reg:                               DEC Alpha Options.  (line   23)
! * mfp-ret-in-387:                        x86 Options.        (line  698)
  * mfp-rounding-mode:                     DEC Alpha Options.  (line   84)
  * mfp-trap-mode:                         DEC Alpha Options.  (line   62)
  * mfp16-format:                          ARM Options.        (line  756)
  * mfp32:                                 MIPS Options.       (line  257)
  * mfp64:                                 MIPS Options.       (line  260)
  * mfpmath:                               Optimize Options.   (line 2334)
! * mfpmath <1>:                           x86 Options.        (line  616)
  * mfpr-32:                               FRV Options.        (line   14)
  * mfpr-64:                               FRV Options.        (line   18)
  * mfprnd:                                RS/6000 and PowerPC Options.
*************** look up both forms.
*** 66810,66828 ****
  * mfpu <5>:                              Visium Options.     (line   17)
  * mfpu=:                                 C-SKY Options.      (line   68)
  * mfpxx:                                 MIPS Options.       (line  263)
! * mfract-convert-truncate:               AVR Options.        (line  283)
  * mframe-header-opt:                     MIPS Options.       (line  891)
  * mfriz:                                 RS/6000 and PowerPC Options.
                                                               (line  868)
  * mfsca:                                 SH Options.         (line  363)
! * mfsgsbase:                             x86 Options.        (line  952)
  * mfsmuld:                               SPARC Options.      (line  272)
  * mfsrra:                                SH Options.         (line  372)
  * mft32b:                                FT32 Options.       (line   22)
  * mfull-regs:                            NDS32 Options.      (line   17)
  * mfull-toc:                             RS/6000 and PowerPC Options.
                                                               (line  252)
! * mfunction-return:                      x86 Options.        (line 1610)
  * mfused-madd:                           IA-64 Options.      (line   86)
  * mfused-madd <1>:                       MIPS Options.       (line  628)
  * mfused-madd <2>:                       RS/6000 and PowerPC Options.
--- 66819,66837 ----
  * mfpu <5>:                              Visium Options.     (line   17)
  * mfpu=:                                 C-SKY Options.      (line   68)
  * mfpxx:                                 MIPS Options.       (line  263)
! * mfract-convert-truncate:               AVR Options.        (line  289)
  * mframe-header-opt:                     MIPS Options.       (line  891)
  * mfriz:                                 RS/6000 and PowerPC Options.
                                                               (line  868)
  * mfsca:                                 SH Options.         (line  363)
! * mfsgsbase:                             x86 Options.        (line  951)
  * mfsmuld:                               SPARC Options.      (line  272)
  * mfsrra:                                SH Options.         (line  372)
  * mft32b:                                FT32 Options.       (line   22)
  * mfull-regs:                            NDS32 Options.      (line   17)
  * mfull-toc:                             RS/6000 and PowerPC Options.
                                                               (line  252)
! * mfunction-return:                      x86 Options.        (line 1609)
  * mfused-madd:                           IA-64 Options.      (line   86)
  * mfused-madd <1>:                       MIPS Options.       (line  628)
  * mfused-madd <2>:                       RS/6000 and PowerPC Options.
*************** look up both forms.
*** 66831,66837 ****
                                                               (line  181)
  * mfused-madd <4>:                       SH Options.         (line  354)
  * mfused-madd <5>:                       Xtensa Options.     (line   17)
! * mfxsr:                                 x86 Options.        (line  975)
  * MG:                                    Preprocessor Options.
                                                               (line  121)
  * mg:                                    VAX Options.        (line   16)
--- 66840,66846 ----
                                                               (line  181)
  * mfused-madd <4>:                       SH Options.         (line  354)
  * mfused-madd <5>:                       Xtensa Options.     (line   17)
! * mfxsr:                                 x86 Options.        (line  974)
  * MG:                                    Preprocessor Options.
                                                               (line  121)
  * mg:                                    VAX Options.        (line   16)
*************** look up both forms.
*** 66839,66850 ****
  * mg13:                                  RL78 Options.       (line   58)
  * mg14:                                  RL78 Options.       (line   58)
  * mgas:                                  HPPA Options.       (line   78)
! * mgas-isr-prologues:                    AVR Options.        (line  228)
  * mgcc-abi:                              V850 Options.       (line  147)
  * mgeneral-regs-only:                    AArch64 Options.    (line   23)
  * mgeneral-regs-only <1>:                ARM Options.        (line   56)
! * mgeneral-regs-only <2>:                x86 Options.        (line 1579)
! * mgfni:                                 x86 Options.        (line  989)
  * mghs:                                  V850 Options.       (line  125)
  * mginv:                                 MIPS Options.       (line  419)
  * mglibc:                                GNU/Linux Options.  (line    8)
--- 66848,66859 ----
  * mg13:                                  RL78 Options.       (line   58)
  * mg14:                                  RL78 Options.       (line   58)
  * mgas:                                  HPPA Options.       (line   78)
! * mgas-isr-prologues:                    AVR Options.        (line  234)
  * mgcc-abi:                              V850 Options.       (line  147)
  * mgeneral-regs-only:                    AArch64 Options.    (line   23)
  * mgeneral-regs-only <1>:                ARM Options.        (line   56)
! * mgeneral-regs-only <2>:                x86 Options.        (line 1578)
! * mgfni:                                 x86 Options.        (line  988)
  * mghs:                                  V850 Options.       (line  125)
  * mginv:                                 MIPS Options.       (line  419)
  * mglibc:                                GNU/Linux Options.  (line    8)
*************** look up both forms.
*** 66886,66903 ****
  * mhard-float <8>:                       SPARC Options.      (line   32)
  * mhard-float <9>:                       V850 Options.       (line  111)
  * mhard-float <10>:                      Visium Options.     (line   17)
! * mhard-float <11>:                      x86 Options.        (line  681)
  * mhard-mul:                             OpenRISC Options.   (line   22)
  * mhard-quad-float:                      SPARC Options.      (line   54)
  * mharden-sls:                           AArch64 Options.    (line  304)
! * mharden-sls <1>:                       x86 Options.        (line 1632)
  * mhardlit:                              MCore Options.      (line    8)
  * mhigh-registers:                       C-SKY Options.      (line  118)
! * mhle:                                  x86 Options.        (line  981)
  * mhotpatch:                             S/390 and zSeries Options.
                                                               (line  217)
  * mhp-ld:                                HPPA Options.       (line   93)
! * mhreset:                               x86 Options.        (line 1010)
  * mhtm:                                  RS/6000 and PowerPC Options.
                                                               (line  182)
  * mhtm <1>:                              S/390 and zSeries Options.
--- 66895,66912 ----
  * mhard-float <8>:                       SPARC Options.      (line   32)
  * mhard-float <9>:                       V850 Options.       (line  111)
  * mhard-float <10>:                      Visium Options.     (line   17)
! * mhard-float <11>:                      x86 Options.        (line  680)
  * mhard-mul:                             OpenRISC Options.   (line   22)
  * mhard-quad-float:                      SPARC Options.      (line   54)
  * mharden-sls:                           AArch64 Options.    (line  304)
! * mharden-sls <1>:                       x86 Options.        (line 1631)
  * mhardlit:                              MCore Options.      (line    8)
  * mhigh-registers:                       C-SKY Options.      (line  118)
! * mhle:                                  x86 Options.        (line  980)
  * mhotpatch:                             S/390 and zSeries Options.
                                                               (line  217)
  * mhp-ld:                                HPPA Options.       (line   93)
! * mhreset:                               x86 Options.        (line 1009)
  * mhtm:                                  RS/6000 and PowerPC Options.
                                                               (line  182)
  * mhtm <1>:                              S/390 and zSeries Options.
*************** look up both forms.
*** 66906,66929 ****
  * mhw-mul:                               Nios II Options.    (line  118)
  * mhw-mulx:                              Nios II Options.    (line  118)
  * mhwmult=:                              MSP430 Options.     (line   92)
! * miamcu:                                x86 Options.        (line 1648)
  * micplb:                                Blackfin Options.   (line  174)
  * mid-shared-library:                    Blackfin Options.   (line   77)
  * mid-shared-library <1>:                Blackfin Options.   (line   84)
  * mieee:                                 DEC Alpha Options.  (line   38)
  * mieee <1>:                             SH Options.         (line  163)
  * mieee-conformant:                      DEC Alpha Options.  (line  133)
! * mieee-fp:                              x86 Options.        (line  675)
  * mieee-with-inexact:                    DEC Alpha Options.  (line   51)
  * milp32:                                IA-64 Options.      (line  119)
  * mimadd:                                MIPS Options.       (line  621)
  * mimpure-text:                          Solaris 2 Options.  (line   14)
! * mincoming-stack-boundary:              x86 Options.        (line  902)
  * mindexed-loads:                        ARC Options.        (line  489)
! * mindirect-branch:                      x86 Options.        (line 1591)
! * mindirect-branch-cs-prefix:            x86 Options.        (line 1639)
! * mindirect-branch-register:             x86 Options.        (line 1629)
! * minline-all-stringops:                 x86 Options.        (line 1431)
  * minline-atomics:                       RISC-V Options.     (line  120)
  * minline-float-divide-max-throughput:   IA-64 Options.      (line   57)
  * minline-float-divide-min-latency:      IA-64 Options.      (line   53)
--- 66915,66938 ----
  * mhw-mul:                               Nios II Options.    (line  118)
  * mhw-mulx:                              Nios II Options.    (line  118)
  * mhwmult=:                              MSP430 Options.     (line   92)
! * miamcu:                                x86 Options.        (line 1647)
  * micplb:                                Blackfin Options.   (line  174)
  * mid-shared-library:                    Blackfin Options.   (line   77)
  * mid-shared-library <1>:                Blackfin Options.   (line   84)
  * mieee:                                 DEC Alpha Options.  (line   38)
  * mieee <1>:                             SH Options.         (line  163)
  * mieee-conformant:                      DEC Alpha Options.  (line  133)
! * mieee-fp:                              x86 Options.        (line  674)
  * mieee-with-inexact:                    DEC Alpha Options.  (line   51)
  * milp32:                                IA-64 Options.      (line  119)
  * mimadd:                                MIPS Options.       (line  621)
  * mimpure-text:                          Solaris 2 Options.  (line   14)
! * mincoming-stack-boundary:              x86 Options.        (line  901)
  * mindexed-loads:                        ARC Options.        (line  489)
! * mindirect-branch:                      x86 Options.        (line 1590)
! * mindirect-branch-cs-prefix:            x86 Options.        (line 1638)
! * mindirect-branch-register:             x86 Options.        (line 1628)
! * minline-all-stringops:                 x86 Options.        (line 1430)
  * minline-atomics:                       RISC-V Options.     (line  120)
  * minline-float-divide-max-throughput:   IA-64 Options.      (line   57)
  * minline-float-divide-min-latency:      IA-64 Options.      (line   53)
*************** look up both forms.
*** 66935,66951 ****
  * minline-plt <1>:                       FRV Options.        (line   80)
  * minline-sqrt-max-throughput:           IA-64 Options.      (line   79)
  * minline-sqrt-min-latency:              IA-64 Options.      (line   75)
! * minline-stringops-dynamically:         x86 Options.        (line 1439)
  * minrt:                                 MSP430 Options.     (line  114)
  * minrt <1>:                             PRU Options.        (line    8)
  * minsert-sched-nops:                    RS/6000 and PowerPC Options.
                                                               (line  484)
! * minstrument-return:                    x86 Options.        (line 1519)
  * mint-register:                         RX Options.         (line   99)
  * mint16:                                PDP-11 Options.     (line   31)
  * mint32:                                H8/300 Options.     (line   37)
  * mint32 <1>:                            PDP-11 Options.     (line   35)
! * mint8:                                 AVR Options.        (line  237)
  * minterlink-compressed:                 MIPS Options.       (line  133)
  * minterlink-mips16:                     MIPS Options.       (line  145)
  * mips1:                                 MIPS Options.       (line   79)
--- 66944,66960 ----
  * minline-plt <1>:                       FRV Options.        (line   80)
  * minline-sqrt-max-throughput:           IA-64 Options.      (line   79)
  * minline-sqrt-min-latency:              IA-64 Options.      (line   75)
! * minline-stringops-dynamically:         x86 Options.        (line 1438)
  * minrt:                                 MSP430 Options.     (line  114)
  * minrt <1>:                             PRU Options.        (line    8)
  * minsert-sched-nops:                    RS/6000 and PowerPC Options.
                                                               (line  484)
! * minstrument-return:                    x86 Options.        (line 1518)
  * mint-register:                         RX Options.         (line   99)
  * mint16:                                PDP-11 Options.     (line   31)
  * mint32:                                H8/300 Options.     (line   37)
  * mint32 <1>:                            PDP-11 Options.     (line   35)
! * mint8:                                 AVR Options.        (line  243)
  * minterlink-compressed:                 MIPS Options.       (line  133)
  * minterlink-mips16:                     MIPS Options.       (line  145)
  * mips1:                                 MIPS Options.       (line   79)
*************** look up both forms.
*** 66980,66992 ****
  * mjump-in-delay:                        HPPA Options.       (line  143)
  * mkernel:                               Darwin Options.     (line   89)
  * mkernel <1>:                           eBPF Options.       (line   12)
! * mkl:                                   x86 Options.        (line 1010)
  * mknuthdiv:                             MMIX Options.       (line   30)
  * ml:                                    SH Options.         (line  128)
! * mlam:                                  x86 Options.        (line 1735)
  * mlarge:                                MSP430 Options.     (line   81)
  * mlarge-data:                           DEC Alpha Options.  (line  185)
! * mlarge-data-threshold:                 x86 Options.        (line  781)
  * mlarge-text:                           DEC Alpha Options.  (line  203)
  * mleaf-id-shared-library:               Blackfin Options.   (line   88)
  * mleaf-id-shared-library <1>:           Blackfin Options.   (line   94)
--- 66989,67001 ----
  * mjump-in-delay:                        HPPA Options.       (line  143)
  * mkernel:                               Darwin Options.     (line   89)
  * mkernel <1>:                           eBPF Options.       (line   12)
! * mkl:                                   x86 Options.        (line 1009)
  * mknuthdiv:                             MMIX Options.       (line   30)
  * ml:                                    SH Options.         (line  128)
! * mlam:                                  x86 Options.        (line 1734)
  * mlarge:                                MSP430 Options.     (line   81)
  * mlarge-data:                           DEC Alpha Options.  (line  185)
! * mlarge-data-threshold:                 x86 Options.        (line  780)
  * mlarge-text:                           DEC Alpha Options.  (line  203)
  * mleaf-id-shared-library:               Blackfin Options.   (line   88)
  * mleaf-id-shared-library <1>:           Blackfin Options.   (line   94)
*************** look up both forms.
*** 67025,67038 ****
  * mlong-calls <5>:                       HPPA Options.       (line  112)
  * mlong-calls <6>:                       MIPS Options.       (line  607)
  * mlong-calls <7>:                       V850 Options.       (line    8)
! * mlong-double:                          AVR Options.        (line  219)
  * mlong-double-128:                      S/390 and zSeries Options.
                                                               (line   27)
! * mlong-double-128 <1>:                  x86 Options.        (line  758)
  * mlong-double-64:                       S/390 and zSeries Options.
                                                               (line   27)
! * mlong-double-64 <1>:                   x86 Options.        (line  758)
! * mlong-double-80:                       x86 Options.        (line  758)
  * mlong-jump-table-offsets:              M680x0 Options.     (line  339)
  * mlong-jumps:                           V850 Options.       (line  106)
  * mlong-load-store:                      HPPA Options.       (line  138)
--- 67034,67047 ----
  * mlong-calls <5>:                       HPPA Options.       (line  112)
  * mlong-calls <6>:                       MIPS Options.       (line  607)
  * mlong-calls <7>:                       V850 Options.       (line    8)
! * mlong-double:                          AVR Options.        (line  225)
  * mlong-double-128:                      S/390 and zSeries Options.
                                                               (line   27)
! * mlong-double-128 <1>:                  x86 Options.        (line  757)
  * mlong-double-64:                       S/390 and zSeries Options.
                                                               (line   27)
! * mlong-double-64 <1>:                   x86 Options.        (line  757)
! * mlong-double-80:                       x86 Options.        (line  757)
  * mlong-jump-table-offsets:              M680x0 Options.     (line  339)
  * mlong-jumps:                           V850 Options.       (line  106)
  * mlong-load-store:                      HPPA Options.       (line  138)
*************** look up both forms.
*** 67060,67081 ****
  * mlra-priority-compact:                 ARC Options.        (line  502)
  * mlra-priority-noncompact:              ARC Options.        (line  505)
  * mlra-priority-none:                    ARC Options.        (line  499)
! * mlwp:                                  x86 Options.        (line  966)
  * mlxc1-sxc1:                            MIPS Options.       (line  901)
! * mlzcnt:                                x86 Options.        (line  974)
  * MM:                                    Preprocessor Options.
                                                               (line  101)
  * mmac-24:                               ARC Options.        (line  362)
  * mmac-d16:                              ARC Options.        (line  358)
  * mmacosx-version-min:                   Darwin Options.     (line   79)
- * mmac_24:                               ARC Options.        (line  629)
- * mmac_d16:                              ARC Options.        (line  632)
  * mmad:                                  MIPS Options.       (line  616)
  * mmadd4:                                MIPS Options.       (line  906)
! * mmain-is-OS_task:                      AVR Options.        (line  243)
  * mmainkernel:                           Nvidia PTX Options. (line   40)
  * mmalloc64:                             VMS Options.        (line   16)
! * mmanual-endbr:                         x86 Options.        (line 1250)
  * mmax:                                  DEC Alpha Options.  (line  155)
  * mmax-constant-size:                    RX Options.         (line   81)
  * mmax-inline-memcpy-size:               LoongArch Options.  (line  117)
--- 67069,67090 ----
  * mlra-priority-compact:                 ARC Options.        (line  502)
  * mlra-priority-noncompact:              ARC Options.        (line  505)
  * mlra-priority-none:                    ARC Options.        (line  499)
! * mlwp:                                  x86 Options.        (line  965)
  * mlxc1-sxc1:                            MIPS Options.       (line  901)
! * mlzcnt:                                x86 Options.        (line  973)
  * MM:                                    Preprocessor Options.
                                                               (line  101)
+ * mmac_24:                               ARC Options.        (line  629)
+ * mmac_d16:                              ARC Options.        (line  632)
  * mmac-24:                               ARC Options.        (line  362)
  * mmac-d16:                              ARC Options.        (line  358)
  * mmacosx-version-min:                   Darwin Options.     (line   79)
  * mmad:                                  MIPS Options.       (line  616)
  * mmadd4:                                MIPS Options.       (line  906)
! * mmain-is-OS_task:                      AVR Options.        (line  249)
  * mmainkernel:                           Nvidia PTX Options. (line   40)
  * mmalloc64:                             VMS Options.        (line   16)
! * mmanual-endbr:                         x86 Options.        (line 1249)
  * mmax:                                  DEC Alpha Options.  (line  155)
  * mmax-constant-size:                    RX Options.         (line   81)
  * mmax-inline-memcpy-size:               LoongArch Options.  (line  117)
*************** look up both forms.
*** 67093,67102 ****
  * mmemcpy:                               LoongArch Options.  (line   98)
  * mmemcpy <1>:                           MicroBlaze Options. (line   12)
  * mmemcpy <2>:                           MIPS Options.       (line  601)
! * mmemcpy-strategy=STRATEGY:             x86 Options.        (line 1461)
  * mmemory-latency:                       DEC Alpha Options.  (line  267)
  * mmemory-model:                         SPARC Options.      (line  347)
! * mmemset-strategy=STRATEGY:             x86 Options.        (line 1473)
  * mmfcrf:                                RS/6000 and PowerPC Options.
                                                               (line   21)
  * mmicromips:                            MIPS Options.       (line  385)
--- 67102,67111 ----
  * mmemcpy:                               LoongArch Options.  (line   98)
  * mmemcpy <1>:                           MicroBlaze Options. (line   12)
  * mmemcpy <2>:                           MIPS Options.       (line  601)
! * mmemcpy-strategy=STRATEGY:             x86 Options.        (line 1460)
  * mmemory-latency:                       DEC Alpha Options.  (line  267)
  * mmemory-model:                         SPARC Options.      (line  347)
! * mmemset-strategy=STRATEGY:             x86 Options.        (line 1472)
  * mmfcrf:                                RS/6000 and PowerPC Options.
                                                               (line   21)
  * mmicromips:                            MIPS Options.       (line  385)
*************** look up both forms.
*** 67106,67123 ****
  * mmixed-code:                           ARC Options.        (line  522)
  * mmma:                                  RS/6000 and PowerPC Options.
                                                               (line  942)
! * mmmx:                                  x86 Options.        (line  927)
  * mmodel=large:                          M32R/D Options.     (line   32)
  * mmodel=medium:                         M32R/D Options.     (line   26)
  * mmodel=small:                          M32R/D Options.     (line   17)
! * mmovbe:                                x86 Options.        (line 1144)
! * mmovdir64b:                            x86 Options.        (line  995)
! * mmovdiri:                              x86 Options.        (line  994)
! * mmove-max:                             x86 Options.        (line 1102)
  * mmp:                                   C-SKY Options.      (line   86)
  * mmpy:                                  ARC Options.        (line  125)
  * mmpy-option:                           ARC Options.        (line  181)
! * mms-bitfields:                         x86 Options.        (line 1305)
  * mmt:                                   MIPS Options.       (line  393)
  * mmul:                                  RL78 Options.       (line   10)
  * mmul-bug-workaround:                   CRIS Options.       (line   28)
--- 67115,67132 ----
  * mmixed-code:                           ARC Options.        (line  522)
  * mmma:                                  RS/6000 and PowerPC Options.
                                                               (line  942)
! * mmmx:                                  x86 Options.        (line  926)
  * mmodel=large:                          M32R/D Options.     (line   32)
  * mmodel=medium:                         M32R/D Options.     (line   26)
  * mmodel=small:                          M32R/D Options.     (line   17)
! * mmovbe:                                x86 Options.        (line 1143)
! * mmovdir64b:                            x86 Options.        (line  994)
! * mmovdiri:                              x86 Options.        (line  993)
! * mmove-max:                             x86 Options.        (line 1101)
  * mmp:                                   C-SKY Options.      (line   86)
  * mmpy:                                  ARC Options.        (line  125)
  * mmpy-option:                           ARC Options.        (line  181)
! * mms-bitfields:                         x86 Options.        (line 1304)
  * mmt:                                   MIPS Options.       (line  393)
  * mmul:                                  RL78 Options.       (line   10)
  * mmul-bug-workaround:                   CRIS Options.       (line   28)
*************** look up both forms.
*** 67139,67151 ****
                                                               (line  136)
  * mmvme:                                 RS/6000 and PowerPC Options.
                                                               (line  608)
! * mmwait:                                x86 Options.        (line 1158)
! * mmwaitx:                               x86 Options.        (line  983)
  * mn:                                    H8/300 Options.     (line   19)
! * mn-flash:                              AVR Options.        (line  645)
  * mnan=2008:                             MIPS Options.       (line  318)
  * mnan=legacy:                           MIPS Options.       (line  318)
! * mneeded:                               x86 Options.        (line 1712)
  * mneon-for-64bits:                      ARM Options.        (line  949)
  * mnested-cond-exec:                     FRV Options.        (line  229)
  * mnewlib:                               OpenRISC Options.   (line   12)
--- 67148,67160 ----
                                                               (line  136)
  * mmvme:                                 RS/6000 and PowerPC Options.
                                                               (line  608)
! * mmwait:                                x86 Options.        (line 1157)
! * mmwaitx:                               x86 Options.        (line  982)
  * mn:                                    H8/300 Options.     (line   19)
! * mn-flash:                              AVR Options.        (line  651)
  * mnan=2008:                             MIPS Options.       (line  318)
  * mnan=legacy:                           MIPS Options.       (line  318)
! * mneeded:                               x86 Options.        (line 1711)
  * mneon-for-64bits:                      ARM Options.        (line  949)
  * mnested-cond-exec:                     FRV Options.        (line  229)
  * mnewlib:                               OpenRISC Options.   (line   12)
*************** look up both forms.
*** 67154,67163 ****
  * mno-8byte-align:                       V850 Options.       (line  168)
  * mno-abicalls:                          MIPS Options.       (line  190)
  * mno-ac0:                               PDP-11 Options.     (line   19)
! * mno-align-double:                      x86 Options.        (line  718)
  * mno-align-int:                         M680x0 Options.     (line  260)
  * mno-align-loops:                       M32R/D Options.     (line   75)
! * mno-align-stringops:                   x86 Options.        (line 1426)
  * mno-allow-string-insns:                RX Options.         (line  148)
  * mno-altivec:                           RS/6000 and PowerPC Options.
                                                               (line  135)
--- 67163,67172 ----
  * mno-8byte-align:                       V850 Options.       (line  168)
  * mno-abicalls:                          MIPS Options.       (line  190)
  * mno-ac0:                               PDP-11 Options.     (line   19)
! * mno-align-double:                      x86 Options.        (line  717)
  * mno-align-int:                         M680x0 Options.     (line  260)
  * mno-align-loops:                       M32R/D Options.     (line   75)
! * mno-align-stringops:                   x86 Options.        (line 1425)
  * mno-allow-string-insns:                RX Options.         (line  148)
  * mno-altivec:                           RS/6000 and PowerPC Options.
                                                               (line  135)
*************** look up both forms.
*** 67181,67187 ****
  * mno-bwx:                               DEC Alpha Options.  (line  155)
  * mno-bypass-cache:                      Nios II Options.    (line  101)
  * mno-cache-volatile:                    Nios II Options.    (line  107)
! * mno-call-ms2sysv-xlogues:              x86 Options.        (line 1266)
  * mno-callgraph-data:                    MCore Options.      (line   29)
  * mno-cbcond:                            SPARC Options.      (line  258)
  * mno-check-zero-division:               MIPS Options.       (line  568)
--- 67190,67196 ----
  * mno-bwx:                               DEC Alpha Options.  (line  155)
  * mno-bypass-cache:                      Nios II Options.    (line  101)
  * mno-cache-volatile:                    Nios II Options.    (line  107)
! * mno-call-ms2sysv-xlogues:              x86 Options.        (line 1265)
  * mno-callgraph-data:                    MCore Options.      (line   29)
  * mno-cbcond:                            SPARC Options.      (line  258)
  * mno-check-zero-division:               MIPS Options.       (line  568)
*************** look up both forms.
*** 67206,67213 ****
  * mno-data-align:                        CRIS Options.       (line   47)
  * mno-debug:                             S/390 and zSeries Options.
                                                               (line  142)
! * mno-default:                           x86 Options.        (line 1070)
! * mno-direct-extern-access:              x86 Options.        (line 1718)
  * mno-direct-extern-access <1>:          x86 Function Attributes.
                                                               (line  744)
  * mno-disable-callt:                     V850 Options.       (line   90)
--- 67215,67222 ----
  * mno-data-align:                        CRIS Options.       (line   47)
  * mno-debug:                             S/390 and zSeries Options.
                                                               (line  142)
! * mno-default:                           x86 Options.        (line 1069)
! * mno-direct-extern-access:              x86 Options.        (line 1717)
  * mno-direct-extern-access <1>:          x86 Function Attributes.
                                                               (line  744)
  * mno-disable-callt:                     V850 Options.       (line   90)
*************** look up both forms.
*** 67237,67243 ****
  * mno-ext-perf2:                         NDS32 Options.      (line   35)
  * mno-ext-string:                        NDS32 Options.      (line   41)
  * mno-extern-sdata:                      MIPS Options.       (line  478)
! * mno-fancy-math-387:                    x86 Options.        (line  709)
  * mno-fast-sw-div:                       Nios II Options.    (line  113)
  * mno-faster-structs:                    SPARC Options.      (line   89)
  * mno-fdpic:                             ARM Options.        (line 1010)
--- 67246,67252 ----
  * mno-ext-perf2:                         NDS32 Options.      (line   35)
  * mno-ext-string:                        NDS32 Options.      (line   41)
  * mno-extern-sdata:                      MIPS Options.       (line  478)
! * mno-fancy-math-387:                    x86 Options.        (line  708)
  * mno-fast-sw-div:                       Nios II Options.    (line  113)
  * mno-faster-structs:                    SPARC Options.      (line   89)
  * mno-fdpic:                             ARM Options.        (line 1010)
*************** look up both forms.
*** 67260,67266 ****
  * mno-fp-in-toc:                         RS/6000 and PowerPC Options.
                                                               (line  252)
  * mno-fp-regs:                           DEC Alpha Options.  (line   23)
! * mno-fp-ret-in-387:                     x86 Options.        (line  699)
  * mno-fprnd:                             RS/6000 and PowerPC Options.
                                                               (line   21)
  * mno-fpu:                               SPARC Options.      (line   37)
--- 67269,67275 ----
  * mno-fp-in-toc:                         RS/6000 and PowerPC Options.
                                                               (line  252)
  * mno-fp-regs:                           DEC Alpha Options.  (line   23)
! * mno-fp-ret-in-387:                     x86 Options.        (line  698)
  * mno-fprnd:                             RS/6000 and PowerPC Options.
                                                               (line   21)
  * mno-fpu:                               SPARC Options.      (line   37)
*************** look up both forms.
*** 67297,67303 ****
  * mno-hw-mulx:                           Nios II Options.    (line  118)
  * mno-id-shared-library:                 Blackfin Options.   (line   84)
  * mno-ieee:                              SH Options.         (line  163)
! * mno-ieee-fp:                           x86 Options.        (line  675)
  * mno-imadd:                             MIPS Options.       (line  621)
  * mno-inline-float-divide:               IA-64 Options.      (line   61)
  * mno-inline-int-divide:                 IA-64 Options.      (line   72)
--- 67306,67312 ----
  * mno-hw-mulx:                           Nios II Options.    (line  118)
  * mno-id-shared-library:                 Blackfin Options.   (line   84)
  * mno-ieee:                              SH Options.         (line  163)
! * mno-ieee-fp:                           x86 Options.        (line  674)
  * mno-imadd:                             MIPS Options.       (line  621)
  * mno-inline-float-divide:               IA-64 Options.      (line   61)
  * mno-inline-int-divide:                 IA-64 Options.      (line   72)
*************** look up both forms.
*** 67306,67312 ****
  * mno-int32:                             PDP-11 Options.     (line   31)
  * mno-interlink-compressed:              MIPS Options.       (line  133)
  * mno-interlink-mips16:                  MIPS Options.       (line  145)
! * mno-interrupts:                        AVR Options.        (line  248)
  * mno-isel:                              RS/6000 and PowerPC Options.
                                                               (line  165)
  * mno-jsr:                               RX Options.         (line  167)
--- 67315,67321 ----
  * mno-int32:                             PDP-11 Options.     (line   31)
  * mno-interlink-compressed:              MIPS Options.       (line  133)
  * mno-interlink-mips16:                  MIPS Options.       (line  145)
! * mno-interrupts:                        AVR Options.        (line  254)
  * mno-isel:                              RS/6000 and PowerPC Options.
                                                               (line  165)
  * mno-jsr:                               RX Options.         (line  167)
*************** look up both forms.
*** 67354,67360 ****
  * Mno-modules:                           Preprocessor Options.
                                                               (line  131)
  * mno-mpy:                               ARC Options.        (line  125)
! * mno-ms-bitfields:                      x86 Options.        (line 1305)
  * mno-mt:                                MIPS Options.       (line  393)
  * mno-mul-bug-workaround:                CRIS Options.       (line   28)
  * mno-muladd:                            FRV Options.        (line   67)
--- 67363,67369 ----
  * Mno-modules:                           Preprocessor Options.
                                                               (line  131)
  * mno-mpy:                               ARC Options.        (line  125)
! * mno-ms-bitfields:                      x86 Options.        (line 1304)
  * mno-mt:                                MIPS Options.       (line  393)
  * mno-mul-bug-workaround:                CRIS Options.       (line   28)
  * mno-muladd:                            FRV Options.        (line   67)
*************** look up both forms.
*** 67409,67422 ****
  * mno-prologue-epilogue:                 CRIS Options.       (line   67)
  * mno-prototype:                         RS/6000 and PowerPC Options.
                                                               (line  591)
! * mno-push-args:                         x86 Options.        (line 1282)
  * mno-quad-memory:                       RS/6000 and PowerPC Options.
                                                               (line  201)
  * mno-quad-memory-atomic:                RS/6000 and PowerPC Options.
                                                               (line  207)
  * mno-readonly-in-sdata:                 RS/6000 and PowerPC Options.
                                                               (line  683)
! * mno-red-zone:                          x86 Options.        (line 1672)
  * mno-register-names:                    IA-64 Options.      (line   35)
  * mno-regnames:                          RS/6000 and PowerPC Options.
                                                               (line  720)
--- 67418,67431 ----
  * mno-prologue-epilogue:                 CRIS Options.       (line   67)
  * mno-prototype:                         RS/6000 and PowerPC Options.
                                                               (line  591)
! * mno-push-args:                         x86 Options.        (line 1281)
  * mno-quad-memory:                       RS/6000 and PowerPC Options.
                                                               (line  201)
  * mno-quad-memory-atomic:                RS/6000 and PowerPC Options.
                                                               (line  207)
  * mno-readonly-in-sdata:                 RS/6000 and PowerPC Options.
                                                               (line  683)
! * mno-red-zone:                          x86 Options.        (line 1671)
  * mno-register-names:                    IA-64 Options.      (line   35)
  * mno-regnames:                          RS/6000 and PowerPC Options.
                                                               (line  720)
*************** look up both forms.
*** 67493,67499 ****
  * mno-unaligned-access <1>:              MIPS Options.       (line  595)
  * mno-unaligned-doubles:                 SPARC Options.      (line   71)
  * mno-uninit-const-in-rodata:            MIPS Options.       (line  523)
! * mno-unroll-only-small-loops:           x86 Options.        (line 1729)
  * mno-update:                            RS/6000 and PowerPC Options.
                                                               (line  348)
  * mno-user-mode:                         SPARC Options.      (line   83)
--- 67502,67508 ----
  * mno-unaligned-access <1>:              MIPS Options.       (line  595)
  * mno-unaligned-doubles:                 SPARC Options.      (line   71)
  * mno-uninit-const-in-rodata:            MIPS Options.       (line  523)
! * mno-unroll-only-small-loops:           x86 Options.        (line 1728)
  * mno-update:                            RS/6000 and PowerPC Options.
                                                               (line  348)
  * mno-user-mode:                         SPARC Options.      (line   83)
*************** look up both forms.
*** 67535,67541 ****
  * mnomacsave:                            SH Options.         (line  159)
  * mnop-fun-dllimport:                    x86 Windows Options.
                                                               (line   21)
! * mnop-mcount:                           x86 Options.        (line 1512)
  * mnopm:                                 FT32 Options.       (line   28)
  * mnops:                                 Adapteva Epiphany Options.
                                                               (line   25)
--- 67544,67550 ----
  * mnomacsave:                            SH Options.         (line  159)
  * mnop-fun-dllimport:                    x86 Windows Options.
                                                               (line   21)
! * mnop-mcount:                           x86 Options.        (line 1511)
  * mnopm:                                 FT32 Options.       (line   28)
  * mnops:                                 Adapteva Epiphany Options.
                                                               (line   25)
*************** look up both forms.
*** 67543,67549 ****
  * modd-spreg:                            MIPS Options.       (line  291)
  * momit-leaf-frame-pointer:              AArch64 Options.    (line   56)
  * momit-leaf-frame-pointer <1>:          Blackfin Options.   (line   42)
! * momit-leaf-frame-pointer <2>:          x86 Options.        (line 1477)
  * mone-byte-bool:                        Darwin Options.     (line   97)
  * moptimize:                             Nvidia PTX Options. (line   44)
  * moptimize-membar:                      FRV Options.        (line  243)
--- 67552,67558 ----
  * modd-spreg:                            MIPS Options.       (line  291)
  * momit-leaf-frame-pointer:              AArch64 Options.    (line   56)
  * momit-leaf-frame-pointer <1>:          Blackfin Options.   (line   42)
! * momit-leaf-frame-pointer <2>:          x86 Options.        (line 1476)
  * mone-byte-bool:                        Darwin Options.     (line   97)
  * moptimize:                             Nvidia PTX Options. (line   44)
  * moptimize-membar:                      FRV Options.        (line  243)
*************** look up both forms.
*** 67561,67571 ****
  * mpadstruct:                            SH Options.         (line  188)
  * mpaired-single:                        MIPS Options.       (line  368)
  * mpc-relative-literal-loads:            AArch64 Options.    (line  276)
! * mpc32:                                 x86 Options.        (line  839)
! * mpc64:                                 x86 Options.        (line  839)
! * mpc80:                                 x86 Options.        (line  839)
! * mpclmul:                               x86 Options.        (line  949)
! * mpconfig:                              x86 Options.        (line  957)
  * mpcrel:                                M680x0 Options.     (line  273)
  * mpcrel <1>:                            RS/6000 and PowerPC Options.
                                                               (line  930)
--- 67570,67580 ----
  * mpadstruct:                            SH Options.         (line  188)
  * mpaired-single:                        MIPS Options.       (line  368)
  * mpc-relative-literal-loads:            AArch64 Options.    (line  276)
! * mpc32:                                 x86 Options.        (line  838)
! * mpc64:                                 x86 Options.        (line  838)
! * mpc80:                                 x86 Options.        (line  838)
! * mpclmul:                               x86 Options.        (line  948)
! * mpconfig:                              x86 Options.        (line  956)
  * mpcrel:                                M680x0 Options.     (line  273)
  * mpcrel <1>:                            RS/6000 and PowerPC Options.
                                                               (line  930)
*************** look up both forms.
*** 67578,67584 ****
  * mpic-data-is-text-relative <1>:        MicroBlaze Options. (line   91)
  * mpic-register:                         ARM Options.        (line  813)
  * mpid:                                  RX Options.         (line  115)
! * mpku:                                  x86 Options.        (line  985)
  * mplt:                                  MIPS Options.       (line  217)
  * mpltseq:                               RS/6000 and PowerPC Options.
                                                               (line  763)
--- 67587,67593 ----
  * mpic-data-is-text-relative <1>:        MicroBlaze Options. (line   91)
  * mpic-register:                         ARM Options.        (line  813)
  * mpid:                                  RX Options.         (line  115)
! * mpku:                                  x86 Options.        (line  984)
  * mplt:                                  MIPS Options.       (line  217)
  * mpltseq:                               RS/6000 and PowerPC Options.
                                                               (line  763)
*************** look up both forms.
*** 67587,67593 ****
                                                               (line  876)
  * mpoke-function-name:                   ARM Options.        (line  828)
  * mpopc:                                 SPARC Options.      (line  279)
! * mpopcnt:                               x86 Options.        (line  969)
  * mpopcntb:                              RS/6000 and PowerPC Options.
                                                               (line   21)
  * mpopcntd:                              RS/6000 and PowerPC Options.
--- 67596,67602 ----
                                                               (line  876)
  * mpoke-function-name:                   ARM Options.        (line  828)
  * mpopc:                                 SPARC Options.      (line  279)
! * mpopcnt:                               x86 Options.        (line  968)
  * mpopcntb:                              RS/6000 and PowerPC Options.
                                                               (line   21)
  * mpopcntd:                              RS/6000 and PowerPC Options.
*************** look up both forms.
*** 67607,67625 ****
                                                               (line   21)
  * mpowerpc64:                            RS/6000 and PowerPC Options.
                                                               (line   21)
! * mprefer-avx128:                        x86 Options.        (line 1094)
  * mprefer-short-insn-regs:               Adapteva Epiphany Options.
                                                               (line   12)
! * mprefer-vector-width:                  x86 Options.        (line 1098)
  * mprefergot:                            SH Options.         (line  267)
  * mpreferred-stack-boundary:             RISC-V Options.     (line  101)
! * mpreferred-stack-boundary <1>:         x86 Options.        (line  881)
! * mprefetchi:                            x86 Options.        (line 1018)
! * mprefetchwt1:                          x86 Options.        (line  962)
  * mprefixed:                             RS/6000 and PowerPC Options.
                                                               (line  936)
  * mpretend-cmove:                        SH Options.         (line  382)
! * mprfchw:                               x86 Options.        (line  960)
  * mprint-tune-info:                      ARM Options.        (line  970)
  * mprioritize-restricted-insns:          RS/6000 and PowerPC Options.
                                                               (line  456)
--- 67616,67634 ----
                                                               (line   21)
  * mpowerpc64:                            RS/6000 and PowerPC Options.
                                                               (line   21)
! * mprefer-avx128:                        x86 Options.        (line 1093)
  * mprefer-short-insn-regs:               Adapteva Epiphany Options.
                                                               (line   12)
! * mprefer-vector-width:                  x86 Options.        (line 1097)
  * mprefergot:                            SH Options.         (line  267)
  * mpreferred-stack-boundary:             RISC-V Options.     (line  101)
! * mpreferred-stack-boundary <1>:         x86 Options.        (line  880)
! * mprefetchi:                            x86 Options.        (line 1017)
! * mprefetchwt1:                          x86 Options.        (line  961)
  * mprefixed:                             RS/6000 and PowerPC Options.
                                                               (line  936)
  * mpretend-cmove:                        SH Options.         (line  382)
! * mprfchw:                               x86 Options.        (line  959)
  * mprint-tune-info:                      ARM Options.        (line  970)
  * mprioritize-restricted-insns:          RS/6000 and PowerPC Options.
                                                               (line  456)
*************** look up both forms.
*** 67629,67638 ****
  * mprologue-epilogue:                    CRIS Options.       (line   67)
  * mprototype:                            RS/6000 and PowerPC Options.
                                                               (line  591)
! * mptwrite:                              x86 Options.        (line  953)
  * mptx:                                  Nvidia PTX Options. (line   29)
  * mpure-code:                            ARM Options.        (line  980)
! * mpush-args:                            x86 Options.        (line 1282)
  * mpushpop:                              C-SKY Options.      (line  128)
  * MQ:                                    Preprocessor Options.
                                                               (line  161)
--- 67638,67647 ----
  * mprologue-epilogue:                    CRIS Options.       (line   67)
  * mprototype:                            RS/6000 and PowerPC Options.
                                                               (line  591)
! * mptwrite:                              x86 Options.        (line  952)
  * mptx:                                  Nvidia PTX Options. (line   29)
  * mpure-code:                            ARM Options.        (line  980)
! * mpush-args:                            x86 Options.        (line 1281)
  * mpushpop:                              C-SKY Options.      (line  128)
  * MQ:                                    Preprocessor Options.
                                                               (line  161)
*************** look up both forms.
*** 67643,67673 ****
                                                               (line  207)
  * mr0rel-sec:                            Nios II Options.    (line   75)
  * mr10k-cache-barrier:                   MIPS Options.       (line  719)
! * mraoint:                               x86 Options.        (line 1019)
  * mRcq:                                  ARC Options.        (line  529)
  * mRcw:                                  ARC Options.        (line  532)
! * mrdpid:                                x86 Options.        (line  961)
! * mrdrnd:                                x86 Options.        (line  954)
! * mrdseed:                               x86 Options.        (line  963)
  * mreadonly-in-sdata:                    RS/6000 and PowerPC Options.
                                                               (line  683)
  * mrecip:                                RS/6000 and PowerPC Options.
                                                               (line  783)
! * mrecip <1>:                            x86 Options.        (line 1163)
  * mrecip-precision:                      RS/6000 and PowerPC Options.
                                                               (line  840)
  * mrecip=opt:                            RS/6000 and PowerPC Options.
                                                               (line  797)
! * mrecip=opt <1>:                        x86 Options.        (line 1185)
! * mrecord-mcount:                        x86 Options.        (line 1506)
! * mrecord-return:                        x86 Options.        (line 1526)
! * mred-zone:                             x86 Options.        (line 1672)
  * mreduced-regs:                         NDS32 Options.      (line   14)
  * mregister-names:                       IA-64 Options.      (line   35)
  * mregnames:                             RS/6000 and PowerPC Options.
                                                               (line  720)
! * mregparm:                              x86 Options.        (line  811)
! * mrelax:                                AVR Options.        (line  252)
  * mrelax <1>:                            H8/300 Options.     (line    8)
  * mrelax <2>:                            MN10300 Options.    (line   45)
  * mrelax <3>:                            MSP430 Options.     (line   87)
--- 67652,67682 ----
                                                               (line  207)
  * mr0rel-sec:                            Nios II Options.    (line   75)
  * mr10k-cache-barrier:                   MIPS Options.       (line  719)
! * mraoint:                               x86 Options.        (line 1018)
  * mRcq:                                  ARC Options.        (line  529)
  * mRcw:                                  ARC Options.        (line  532)
! * mrdpid:                                x86 Options.        (line  960)
! * mrdrnd:                                x86 Options.        (line  953)
! * mrdseed:                               x86 Options.        (line  962)
  * mreadonly-in-sdata:                    RS/6000 and PowerPC Options.
                                                               (line  683)
  * mrecip:                                RS/6000 and PowerPC Options.
                                                               (line  783)
! * mrecip <1>:                            x86 Options.        (line 1162)
  * mrecip-precision:                      RS/6000 and PowerPC Options.
                                                               (line  840)
  * mrecip=opt:                            RS/6000 and PowerPC Options.
                                                               (line  797)
! * mrecip=opt <1>:                        x86 Options.        (line 1184)
! * mrecord-mcount:                        x86 Options.        (line 1505)
! * mrecord-return:                        x86 Options.        (line 1525)
! * mred-zone:                             x86 Options.        (line 1671)
  * mreduced-regs:                         NDS32 Options.      (line   14)
  * mregister-names:                       IA-64 Options.      (line   35)
  * mregnames:                             RS/6000 and PowerPC Options.
                                                               (line  720)
! * mregparm:                              x86 Options.        (line  810)
! * mrelax:                                AVR Options.        (line  258)
  * mrelax <1>:                            H8/300 Options.     (line    8)
  * mrelax <2>:                            MN10300 Options.    (line   45)
  * mrelax <3>:                            MSP430 Options.     (line   87)
*************** look up both forms.
*** 67676,67682 ****
  * mrelax <6>:                            RX Options.         (line   94)
  * mrelax <7>:                            SH Options.         (line  136)
  * mrelax <8>:                            V850 Options.       (line  101)
! * mrelax-cmpxchg-loop:                   x86 Options.        (line 1584)
  * mrelax-immediate:                      MCore Options.      (line   17)
  * mrelax-pic-calls:                      MIPS Options.       (line  865)
  * mrelocatable:                          RS/6000 and PowerPC Options.
--- 67685,67691 ----
  * mrelax <6>:                            RX Options.         (line   94)
  * mrelax <7>:                            SH Options.         (line  136)
  * mrelax <8>:                            V850 Options.       (line  101)
! * mrelax-cmpxchg-loop:                   x86 Options.        (line 1583)
  * mrelax-immediate:                      MCore Options.      (line   17)
  * mrelax-pic-calls:                      MIPS Options.       (line  865)
  * mrelocatable:                          RS/6000 and PowerPC Options.
*************** look up both forms.
*** 67691,67697 ****
  * mrh850-abi:                            V850 Options.       (line  125)
  * mriscv-attribute:                      RISC-V Options.     (line  169)
  * mrl78:                                 RL78 Options.       (line   58)
! * mrmw:                                  AVR Options.        (line  649)
  * mrop-protect:                          RS/6000 and PowerPC Options.
                                                               (line  947)
  * mror:                                  OpenRISC Options.   (line   48)
--- 67700,67706 ----
  * mrh850-abi:                            V850 Options.       (line  125)
  * mriscv-attribute:                      RISC-V Options.     (line  169)
  * mrl78:                                 RL78 Options.       (line   58)
! * mrmw:                                  AVR Options.        (line  655)
  * mrop-protect:                          RS/6000 and PowerPC Options.
                                                               (line  947)
  * mror:                                  OpenRISC Options.   (line   48)
*************** look up both forms.
*** 67699,67713 ****
  * mround-nearest:                        Adapteva Epiphany Options.
                                                               (line   50)
  * mrtd:                                  M680x0 Options.     (line  236)
! * mrtd <1>:                              x86 Options.        (line  787)
  * mrtd <2>:                              x86 Function Attributes.
                                                               (line    8)
! * mrtm:                                  x86 Options.        (line  980)
  * mrtp:                                  VxWorks Options.    (line   10)
  * mrtsc:                                 ARC Options.        (line  366)
  * ms:                                    H8/300 Options.     (line   16)
  * ms2600:                                H8/300 Options.     (line   23)
! * msahf:                                 x86 Options.        (line 1134)
  * msave-acc-in-interrupts:               RX Options.         (line  108)
  * msave-mduc-in-interrupts:              RL78 Options.       (line   77)
  * msave-restore:                         RISC-V Options.     (line  114)
--- 67708,67722 ----
  * mround-nearest:                        Adapteva Epiphany Options.
                                                               (line   50)
  * mrtd:                                  M680x0 Options.     (line  236)
! * mrtd <1>:                              x86 Options.        (line  786)
  * mrtd <2>:                              x86 Function Attributes.
                                                               (line    8)
! * mrtm:                                  x86 Options.        (line  979)
  * mrtp:                                  VxWorks Options.    (line   10)
  * mrtsc:                                 ARC Options.        (line  366)
  * ms:                                    H8/300 Options.     (line   16)
  * ms2600:                                H8/300 Options.     (line   23)
! * msahf:                                 x86 Options.        (line 1133)
  * msave-acc-in-interrupts:               RX Options.         (line  108)
  * msave-mduc-in-interrupts:              RL78 Options.       (line   77)
  * msave-restore:                         RISC-V Options.     (line  114)
*************** look up both forms.
*** 67762,67780 ****
  * msel-sched-dont-check-control-spec:    IA-64 Options.      (line  206)
  * msep-data:                             Blackfin Options.   (line  106)
  * msep-data <1>:                         Blackfin Options.   (line  112)
! * mserialize:                            x86 Options.        (line 1006)
  * mserialize-volatile:                   Xtensa Options.     (line   33)
  * msetlb:                                MN10300 Options.    (line   63)
  * msext:                                 OpenRISC Options.   (line   58)
  * msfimm:                                OpenRISC Options.   (line   62)
! * msgx:                                  x86 Options.        (line  964)
! * msha:                                  x86 Options.        (line  947)
  * mshared-library-id:                    Blackfin Options.   (line   99)
  * mshftimm:                              OpenRISC Options.   (line   67)
  * mshort:                                M680x0 Options.     (line  216)
! * mshort-calls:                          AVR Options.        (line  653)
  * mshorten-memrefs:                      RISC-V Options.     (line  126)
! * mshstk:                                x86 Options.        (line 1148)
  * mside-effects:                         CRIS Options.       (line   43)
  * msign-extend-enabled:                  LM32 Options.       (line   17)
  * msign-return-address:                  AArch64 Options.    (line  283)
--- 67771,67789 ----
  * msel-sched-dont-check-control-spec:    IA-64 Options.      (line  206)
  * msep-data:                             Blackfin Options.   (line  106)
  * msep-data <1>:                         Blackfin Options.   (line  112)
! * mserialize:                            x86 Options.        (line 1005)
  * mserialize-volatile:                   Xtensa Options.     (line   33)
  * msetlb:                                MN10300 Options.    (line   63)
  * msext:                                 OpenRISC Options.   (line   58)
  * msfimm:                                OpenRISC Options.   (line   62)
! * msgx:                                  x86 Options.        (line  963)
! * msha:                                  x86 Options.        (line  946)
  * mshared-library-id:                    Blackfin Options.   (line   99)
  * mshftimm:                              OpenRISC Options.   (line   67)
  * mshort:                                M680x0 Options.     (line  216)
! * mshort-calls:                          AVR Options.        (line  659)
  * mshorten-memrefs:                      RISC-V Options.     (line  126)
! * mshstk:                                x86 Options.        (line 1147)
  * mside-effects:                         CRIS Options.       (line   43)
  * msign-extend-enabled:                  LM32 Options.       (line   17)
  * msign-return-address:                  AArch64 Options.    (line  283)
*************** look up both forms.
*** 67801,67808 ****
                                                               (line  450)
  * msio:                                  HPPA Options.       (line  168)
  * msize-level:                           ARC Options.        (line  535)
! * mskip-bug:                             AVR Options.        (line  659)
! * mskip-rax-setup:                       x86 Options.        (line 1539)
  * mslow-bytes:                           MCore Options.      (line   33)
  * mslow-flash-data:                      ARM Options.        (line  952)
  * msmall:                                MSP430 Options.     (line   84)
--- 67810,67817 ----
                                                               (line  450)
  * msio:                                  HPPA Options.       (line  168)
  * msize-level:                           ARC Options.        (line  535)
! * mskip-bug:                             AVR Options.        (line  665)
! * mskip-rax-setup:                       x86 Options.        (line 1538)
  * mslow-bytes:                           MCore Options.      (line   33)
  * mslow-flash-data:                      ARM Options.        (line  952)
  * msmall:                                MSP430 Options.     (line   84)
*************** look up both forms.
*** 67841,67861 ****
  * msoft-float <13>:                      SPARC Options.      (line   37)
  * msoft-float <14>:                      V850 Options.       (line  111)
  * msoft-float <15>:                      Visium Options.     (line   22)
! * msoft-float <16>:                      x86 Options.        (line  685)
  * msoft-mul:                             OpenRISC Options.   (line   22)
  * msoft-mult:                            HPPA Options.       (line  188)
  * msoft-quad-float:                      SPARC Options.      (line   58)
  * msoft-stack:                           Nvidia PTX Options. (line   48)
! * msp8:                                  AVR Options.        (line  664)
  * mspace:                                V850 Options.       (line   29)
  * mspace-regs:                           HPPA Options.       (line  147)
  * mspecld-anomaly:                       Blackfin Options.   (line   47)
  * mspecld-anomaly <1>:                   Blackfin Options.   (line   52)
  * mspfp:                                 ARC Options.        (line  140)
- * mspfp-compact:                         ARC Options.        (line  140)
- * mspfp-fast:                            ARC Options.        (line  145)
  * mspfp_compact:                         ARC Options.        (line  635)
  * mspfp_fast:                            ARC Options.        (line  638)
  * msplit:                                PDP-11 Options.     (line   39)
  * msplit-addresses:                      MIPS Options.       (line  553)
  * msplit-lohi:                           Adapteva Epiphany Options.
--- 67850,67870 ----
  * msoft-float <13>:                      SPARC Options.      (line   37)
  * msoft-float <14>:                      V850 Options.       (line  111)
  * msoft-float <15>:                      Visium Options.     (line   22)
! * msoft-float <16>:                      x86 Options.        (line  684)
  * msoft-mul:                             OpenRISC Options.   (line   22)
  * msoft-mult:                            HPPA Options.       (line  188)
  * msoft-quad-float:                      SPARC Options.      (line   58)
  * msoft-stack:                           Nvidia PTX Options. (line   48)
! * msp8:                                  AVR Options.        (line  670)
  * mspace:                                V850 Options.       (line   29)
  * mspace-regs:                           HPPA Options.       (line  147)
  * mspecld-anomaly:                       Blackfin Options.   (line   47)
  * mspecld-anomaly <1>:                   Blackfin Options.   (line   52)
  * mspfp:                                 ARC Options.        (line  140)
  * mspfp_compact:                         ARC Options.        (line  635)
  * mspfp_fast:                            ARC Options.        (line  638)
+ * mspfp-compact:                         ARC Options.        (line  140)
+ * mspfp-fast:                            ARC Options.        (line  145)
  * msplit:                                PDP-11 Options.     (line   39)
  * msplit-addresses:                      MIPS Options.       (line  553)
  * msplit-lohi:                           Adapteva Epiphany Options.
*************** look up both forms.
*** 67863,67878 ****
  * msplit-vecmove-early:                  Adapteva Epiphany Options.
                                                               (line  125)
  * msram-ecc:                             AMD GCN Options.    (line   28)
! * msse:                                  x86 Options.        (line  928)
! * msse2:                                 x86 Options.        (line  929)
! * msse2avx:                              x86 Options.        (line 1494)
! * msse3:                                 x86 Options.        (line  930)
! * msse4:                                 x86 Options.        (line  932)
! * msse4.1:                               x86 Options.        (line  934)
! * msse4.2:                               x86 Options.        (line  935)
! * msse4a:                                x86 Options.        (line  933)
! * msseregparm:                           x86 Options.        (line  822)
! * mssse3:                                x86 Options.        (line  931)
  * mstack-align:                          CRIS Options.       (line   47)
  * mstack-bias:                           SPARC Options.      (line  370)
  * mstack-check-l1:                       Blackfin Options.   (line   73)
--- 67872,67887 ----
  * msplit-vecmove-early:                  Adapteva Epiphany Options.
                                                               (line  125)
  * msram-ecc:                             AMD GCN Options.    (line   28)
! * msse:                                  x86 Options.        (line  927)
! * msse2:                                 x86 Options.        (line  928)
! * msse2avx:                              x86 Options.        (line 1493)
! * msse3:                                 x86 Options.        (line  929)
! * msse4:                                 x86 Options.        (line  931)
! * msse4.1:                               x86 Options.        (line  933)
! * msse4.2:                               x86 Options.        (line  934)
! * msse4a:                                x86 Options.        (line  932)
! * msseregparm:                           x86 Options.        (line  821)
! * mssse3:                                x86 Options.        (line  930)
  * mstack-align:                          CRIS Options.       (line   47)
  * mstack-bias:                           SPARC Options.      (line  370)
  * mstack-check-l1:                       Blackfin Options.   (line   73)
*************** look up both forms.
*** 67886,67922 ****
  * mstack-protector-guard <2>:            RISC-V Options.     (line  193)
  * mstack-protector-guard <3>:            RS/6000 and PowerPC Options.
                                                               (line  912)
! * mstack-protector-guard <4>:            x86 Options.        (line 1564)
  * mstack-protector-guard-offset:         AArch64 Options.    (line   61)
  * mstack-protector-guard-offset <1>:     ARM Options.        (line 1002)
  * mstack-protector-guard-offset <2>:     RISC-V Options.     (line  193)
  * mstack-protector-guard-offset <3>:     RS/6000 and PowerPC Options.
                                                               (line  912)
! * mstack-protector-guard-offset <4>:     x86 Options.        (line 1564)
  * mstack-protector-guard-reg:            AArch64 Options.    (line   61)
  * mstack-protector-guard-reg <1>:        RISC-V Options.     (line  193)
  * mstack-protector-guard-reg <2>:        RS/6000 and PowerPC Options.
                                                               (line  912)
! * mstack-protector-guard-reg <3>:        x86 Options.        (line 1564)
  * mstack-protector-guard-symbol:         RS/6000 and PowerPC Options.
                                                               (line  912)
  * mstack-size:                           AMD GCN Options.    (line   36)
  * mstack-size <1>:                       C-SKY Options.      (line  148)
  * mstack-size <2>:                       S/390 and zSeries Options.
                                                               (line  200)
! * mstackrealign:                         x86 Options.        (line  872)
  * mstd-struct-return:                    SPARC Options.      (line  100)
! * mstore-max:                            x86 Options.        (line 1107)
  * mstrict-align:                         AArch64 Options.    (line   50)
  * mstrict-align <1>:                     LoongArch Options.  (line  107)
  * mstrict-align <2>:                     M680x0 Options.     (line  279)
  * mstrict-align <3>:                     RISC-V Options.     (line  135)
  * mstrict-align <4>:                     RS/6000 and PowerPC Options.
                                                               (line  401)
! * mstrict-X:                             AVR Options.        (line  266)
  * mstring-compare-inline-limit:          RS/6000 and PowerPC Options.
                                                               (line  707)
! * mstringop-strategy=ALG:                x86 Options.        (line 1443)
  * mstructure-size-boundary:              ARM Options.        (line  762)
  * msubxc:                                SPARC Options.      (line  286)
  * msv-mode:                              Visium Options.     (line   51)
--- 67895,67931 ----
  * mstack-protector-guard <2>:            RISC-V Options.     (line  193)
  * mstack-protector-guard <3>:            RS/6000 and PowerPC Options.
                                                               (line  912)
! * mstack-protector-guard <4>:            x86 Options.        (line 1563)
  * mstack-protector-guard-offset:         AArch64 Options.    (line   61)
  * mstack-protector-guard-offset <1>:     ARM Options.        (line 1002)
  * mstack-protector-guard-offset <2>:     RISC-V Options.     (line  193)
  * mstack-protector-guard-offset <3>:     RS/6000 and PowerPC Options.
                                                               (line  912)
! * mstack-protector-guard-offset <4>:     x86 Options.        (line 1563)
  * mstack-protector-guard-reg:            AArch64 Options.    (line   61)
  * mstack-protector-guard-reg <1>:        RISC-V Options.     (line  193)
  * mstack-protector-guard-reg <2>:        RS/6000 and PowerPC Options.
                                                               (line  912)
! * mstack-protector-guard-reg <3>:        x86 Options.        (line 1563)
  * mstack-protector-guard-symbol:         RS/6000 and PowerPC Options.
                                                               (line  912)
  * mstack-size:                           AMD GCN Options.    (line   36)
  * mstack-size <1>:                       C-SKY Options.      (line  148)
  * mstack-size <2>:                       S/390 and zSeries Options.
                                                               (line  200)
! * mstackrealign:                         x86 Options.        (line  871)
  * mstd-struct-return:                    SPARC Options.      (line  100)
! * mstore-max:                            x86 Options.        (line 1106)
  * mstrict-align:                         AArch64 Options.    (line   50)
  * mstrict-align <1>:                     LoongArch Options.  (line  107)
  * mstrict-align <2>:                     M680x0 Options.     (line  279)
  * mstrict-align <3>:                     RISC-V Options.     (line  135)
  * mstrict-align <4>:                     RS/6000 and PowerPC Options.
                                                               (line  401)
! * mstrict-X:                             AVR Options.        (line  272)
  * mstring-compare-inline-limit:          RS/6000 and PowerPC Options.
                                                               (line  707)
! * mstringop-strategy=ALG:                x86 Options.        (line 1442)
  * mstructure-size-boundary:              ARM Options.        (line  762)
  * msubxc:                                SPARC Options.      (line  286)
  * msv-mode:                              Visium Options.     (line   51)
*************** look up both forms.
*** 67933,67956 ****
                                                               (line  146)
  * mtarget-align:                         Xtensa Options.     (line   72)
  * mtas:                                  SH Options.         (line  258)
! * mtbm:                                  x86 Options.        (line  982)
  * mtda:                                  V850 Options.       (line   33)
  * mtelephony:                            ARC Options.        (line  376)
  * mtext-section-literals:                Xtensa Options.     (line   45)
! * mthreads:                              x86 Options.        (line 1298)
  * mthreads <1>:                          x86 Windows Options.
                                                               (line   25)
  * mthumb:                                ARM Options.        (line  849)
  * mthumb-interwork:                      ARM Options.        (line   23)
  * mtiny-printf:                          MSP430 Options.     (line  121)
! * mtiny-stack:                           AVR Options.        (line  280)
  * mTLS:                                  FRV Options.        (line   89)
  * mtls:                                  FRV Options.        (line   93)
  * mtls-dialect:                          ARM Options.        (line  902)
! * mtls-dialect <1>:                      x86 Options.        (line 1276)
  * mtls-dialect=desc:                     AArch64 Options.    (line   76)
  * mtls-dialect=traditional:              AArch64 Options.    (line   80)
! * mtls-direct-seg-refs:                  x86 Options.        (line 1484)
  * mtls-markers:                          RS/6000 and PowerPC Options.
                                                               (line  775)
  * mtls-size:                             AArch64 Options.    (line   84)
--- 67942,67965 ----
                                                               (line  146)
  * mtarget-align:                         Xtensa Options.     (line   72)
  * mtas:                                  SH Options.         (line  258)
! * mtbm:                                  x86 Options.        (line  981)
  * mtda:                                  V850 Options.       (line   33)
  * mtelephony:                            ARC Options.        (line  376)
  * mtext-section-literals:                Xtensa Options.     (line   45)
! * mthreads:                              x86 Options.        (line 1297)
  * mthreads <1>:                          x86 Windows Options.
                                                               (line   25)
  * mthumb:                                ARM Options.        (line  849)
  * mthumb-interwork:                      ARM Options.        (line   23)
  * mtiny-printf:                          MSP430 Options.     (line  121)
! * mtiny-stack:                           AVR Options.        (line  286)
  * mTLS:                                  FRV Options.        (line   89)
  * mtls:                                  FRV Options.        (line   93)
  * mtls-dialect:                          ARM Options.        (line  902)
! * mtls-dialect <1>:                      x86 Options.        (line 1275)
  * mtls-dialect=desc:                     AArch64 Options.    (line   76)
  * mtls-dialect=traditional:              AArch64 Options.    (line   80)
! * mtls-direct-seg-refs:                  x86 Options.        (line 1483)
  * mtls-markers:                          RS/6000 and PowerPC Options.
                                                               (line  775)
  * mtls-size:                             AArch64 Options.    (line   84)
*************** look up both forms.
*** 67971,67977 ****
                                                               (line  540)
  * mtrap-precision:                       DEC Alpha Options.  (line  108)
  * mtrust:                                C-SKY Options.      (line   98)
! * mtsxldtrk:                             x86 Options.        (line  998)
  * mtune:                                 AArch64 Options.    (line  191)
  * mtune <1>:                             AMD GCN Options.    (line    8)
  * mtune <2>:                             ARC Options.        (line  556)
--- 67980,67986 ----
                                                               (line  540)
  * mtrap-precision:                       DEC Alpha Options.  (line  108)
  * mtrust:                                C-SKY Options.      (line   98)
! * mtsxldtrk:                             x86 Options.        (line  997)
  * mtune:                                 AArch64 Options.    (line  191)
  * mtune <1>:                             AMD GCN Options.    (line    8)
  * mtune <2>:                             ARC Options.        (line  556)
*************** look up both forms.
*** 67991,68007 ****
                                                               (line  161)
  * mtune <15>:                            SPARC Options.      (line  198)
  * mtune <16>:                            Visium Options.     (line   46)
! * mtune <17>:                            x86 Options.        (line  560)
! * mtune-ctrl=FEATURE-LIST:               x86 Options.        (line 1061)
  * muclibc:                               GNU/Linux Options.  (line   13)
! * muintr:                                x86 Options.        (line  996)
  * multcost:                              ARC Options.        (line  646)
  * multcost=NUMBER:                       SH Options.         (line  280)
  * multilib-library-pic:                  FRV Options.        (line  109)
- * multiply-enabled:                      LM32 Options.       (line   14)
  * multiply_defined:                      Darwin Options.     (line  197)
  * multiply_defined_unused:               Darwin Options.     (line  197)
! * multi_module:                          Darwin Options.     (line  197)
  * munalign-prob-threshold:               ARC Options.        (line  591)
  * munaligned-access:                     ARM Options.        (line  935)
  * munaligned-access <1>:                 MIPS Options.       (line  595)
--- 68000,68016 ----
                                                               (line  161)
  * mtune <15>:                            SPARC Options.      (line  198)
  * mtune <16>:                            Visium Options.     (line   46)
! * mtune <17>:                            x86 Options.        (line  559)
! * mtune-ctrl=FEATURE-LIST:               x86 Options.        (line 1060)
  * muclibc:                               GNU/Linux Options.  (line   13)
! * muintr:                                x86 Options.        (line  995)
  * multcost:                              ARC Options.        (line  646)
  * multcost=NUMBER:                       SH Options.         (line  280)
+ * multi_module:                          Darwin Options.     (line  197)
  * multilib-library-pic:                  FRV Options.        (line  109)
  * multiply_defined:                      Darwin Options.     (line  197)
  * multiply_defined_unused:               Darwin Options.     (line  197)
! * multiply-enabled:                      LM32 Options.       (line   14)
  * munalign-prob-threshold:               ARC Options.        (line  591)
  * munaligned-access:                     ARM Options.        (line  935)
  * munaligned-access <1>:                 MIPS Options.       (line  595)
*************** look up both forms.
*** 68013,68019 ****
  * munix:                                 VAX Options.        (line    8)
  * munix-asm:                             PDP-11 Options.     (line   42)
  * munordered-float:                      OpenRISC Options.   (line   38)
! * munroll-only-small-loops:              x86 Options.        (line 1729)
  * mupdate:                               RS/6000 and PowerPC Options.
                                                               (line  348)
  * muser-enabled:                         LM32 Options.       (line   20)
--- 68022,68028 ----
  * munix:                                 VAX Options.        (line    8)
  * munix-asm:                             PDP-11 Options.     (line   42)
  * munordered-float:                      OpenRISC Options.   (line   38)
! * munroll-only-small-loops:              x86 Options.        (line 1728)
  * mupdate:                               RS/6000 and PowerPC Options.
                                                               (line  348)
  * muser-enabled:                         LM32 Options.       (line   20)
*************** look up both forms.
*** 68030,68043 ****
  * mv850e3v5:                             V850 Options.       (line   51)
  * mv850es:                               V850 Options.       (line   74)
  * mv8plus:                               SPARC Options.      (line  212)
! * mvaes:                                 x86 Options.        (line  990)
  * mvdsp:                                 C-SKY Options.      (line  101)
  * mveclibabi:                            RS/6000 and PowerPC Options.
                                                               (line  850)
! * mveclibabi <1>:                        x86 Options.        (line 1214)
  * mvect-double:                          Adapteva Epiphany Options.
                                                               (line  114)
! * mvect8-ret-in-mem:                     x86 Options.        (line  832)
  * mverbose-cost-dump:                    AArch64 Options.    (line  272)
  * mverbose-cost-dump <1>:                ARM Options.        (line  976)
  * mvirt:                                 MIPS Options.       (line  405)
--- 68039,68052 ----
  * mv850e3v5:                             V850 Options.       (line   51)
  * mv850es:                               V850 Options.       (line   74)
  * mv8plus:                               SPARC Options.      (line  212)
! * mvaes:                                 x86 Options.        (line  989)
  * mvdsp:                                 C-SKY Options.      (line  101)
  * mveclibabi:                            RS/6000 and PowerPC Options.
                                                               (line  850)
! * mveclibabi <1>:                        x86 Options.        (line 1213)
  * mvect-double:                          Adapteva Epiphany Options.
                                                               (line  114)
! * mvect8-ret-in-mem:                     x86 Options.        (line  831)
  * mverbose-cost-dump:                    AArch64 Options.    (line  272)
  * mverbose-cost-dump <1>:                ARM Options.        (line  976)
  * mvirt:                                 MIPS Options.       (line  405)
*************** look up both forms.
*** 68051,68057 ****
  * mvolatile-asm-stop:                    IA-64 Options.      (line   30)
  * mvolatile-cache:                       ARC Options.        (line  433)
  * mvolatile-cache <1>:                   ARC Options.        (line  437)
! * mvpclmulqdq:                           x86 Options.        (line  992)
  * mvr4130-align:                         MIPS Options.       (line  840)
  * mvrsave:                               RS/6000 and PowerPC Options.
                                                               (line  151)
--- 68060,68066 ----
  * mvolatile-asm-stop:                    IA-64 Options.      (line   30)
  * mvolatile-cache:                       ARC Options.        (line  433)
  * mvolatile-cache <1>:                   ARC Options.        (line  437)
! * mvpclmulqdq:                           x86 Options.        (line  991)
  * mvr4130-align:                         MIPS Options.       (line  840)
  * mvrsave:                               RS/6000 and PowerPC Options.
                                                               (line  151)
*************** look up both forms.
*** 68061,68068 ****
                                                               (line  110)
  * mvxworks:                              RS/6000 and PowerPC Options.
                                                               (line  623)
! * mvzeroupper:                           x86 Options.        (line 1088)
! * mwaitpkg:                              x86 Options.        (line  991)
  * mwarn-devices-csv:                     MSP430 Options.     (line  166)
  * mwarn-dynamicstack:                    S/390 and zSeries Options.
                                                               (line  195)
--- 68070,68077 ----
                                                               (line  110)
  * mvxworks:                              RS/6000 and PowerPC Options.
                                                               (line  623)
! * mvzeroupper:                           x86 Options.        (line 1087)
! * mwaitpkg:                              x86 Options.        (line  990)
  * mwarn-devices-csv:                     MSP430 Options.     (line  166)
  * mwarn-dynamicstack:                    S/390 and zSeries Options.
                                                               (line  195)
*************** look up both forms.
*** 68070,68084 ****
                                                               (line  187)
  * mwarn-mcu:                             MSP430 Options.     (line   63)
  * mwarn-multiple-fast-interrupts:        RX Options.         (line  141)
! * mwbnoinvd:                             x86 Options.        (line  958)
  * mwide-bitfields:                       MCore Options.      (line   21)
! * mwidekl:                               x86 Options.        (line 1012)
  * mwin32:                                x86 Windows Options.
                                                               (line   34)
  * mwindows:                              x86 Windows Options.
                                                               (line   40)
  * mword-relocations:                     ARM Options.        (line  913)
! * mx32:                                  x86 Options.        (line 1648)
  * mxgot:                                 M680x0 Options.     (line  311)
  * mxgot <1>:                             MIPS Options.       (line  227)
  * mxl-barrel-shift:                      MicroBlaze Options. (line   31)
--- 68079,68093 ----
                                                               (line  187)
  * mwarn-mcu:                             MSP430 Options.     (line   63)
  * mwarn-multiple-fast-interrupts:        RX Options.         (line  141)
! * mwbnoinvd:                             x86 Options.        (line  957)
  * mwide-bitfields:                       MCore Options.      (line   21)
! * mwidekl:                               x86 Options.        (line 1011)
  * mwin32:                                x86 Windows Options.
                                                               (line   34)
  * mwindows:                              x86 Windows Options.
                                                               (line   40)
  * mword-relocations:                     ARM Options.        (line  913)
! * mx32:                                  x86 Options.        (line 1647)
  * mxgot:                                 M680x0 Options.     (line  311)
  * mxgot <1>:                             MIPS Options.       (line  227)
  * mxl-barrel-shift:                      MicroBlaze Options. (line   31)
*************** look up both forms.
*** 68094,68105 ****
  * mxl-soft-mul:                          MicroBlaze Options. (line   25)
  * mxl-stack-check:                       MicroBlaze Options. (line   40)
  * mxnack:                                AMD GCN Options.    (line   43)
! * mxop:                                  x86 Options.        (line  965)
  * mxpa:                                  MIPS Options.       (line  409)
! * mxsave:                                x86 Options.        (line  976)
! * mxsavec:                               x86 Options.        (line  978)
! * mxsaveopt:                             x86 Options.        (line  977)
! * mxsaves:                               x86 Options.        (line  979)
  * mxy:                                   ARC Options.        (line  381)
  * myellowknife:                          RS/6000 and PowerPC Options.
                                                               (line  618)
--- 68103,68114 ----
  * mxl-soft-mul:                          MicroBlaze Options. (line   25)
  * mxl-stack-check:                       MicroBlaze Options. (line   40)
  * mxnack:                                AMD GCN Options.    (line   43)
! * mxop:                                  x86 Options.        (line  964)
  * mxpa:                                  MIPS Options.       (line  409)
! * mxsave:                                x86 Options.        (line  975)
! * mxsavec:                               x86 Options.        (line  977)
! * mxsaveopt:                             x86 Options.        (line  976)
! * mxsaves:                               x86 Options.        (line  978)
  * mxy:                                   ARC Options.        (line  381)
  * myellowknife:                          RS/6000 and PowerPC Options.
                                                               (line  618)
*************** look up both forms.
*** 68110,68116 ****
  * mzero-extend:                          MMIX Options.       (line   24)
  * mzvector:                              S/390 and zSeries Options.
                                                               (line  121)
! * no-80387:                              x86 Options.        (line  685)
  * no-block-ops-unaligned-vsx:            RS/6000 and PowerPC Options.
                                                               (line  957)
  * no-canonical-prefixes:                 Directory Options.  (line  163)
--- 68119,68126 ----
  * mzero-extend:                          MMIX Options.       (line   24)
  * mzvector:                              S/390 and zSeries Options.
                                                               (line  121)
! * no_dead_strip_inits_and_terms:         Darwin Options.     (line  197)
! * no-80387:                              x86 Options.        (line  684)
  * no-block-ops-unaligned-vsx:            RS/6000 and PowerPC Options.
                                                               (line  957)
  * no-canonical-prefixes:                 Directory Options.  (line  163)
*************** look up both forms.
*** 68121,68128 ****
  * noall_load:                            Darwin Options.     (line  197)
  * nocpp:                                 MIPS Options.       (line  641)
  * nodefaultlibs:                         Link Options.       (line  121)
! * nodevicelib:                           AVR Options.        (line  287)
! * nodevicespecs:                         AVR Options.        (line  290)
  * nofixprebinding:                       Darwin Options.     (line  197)
  * nofpu:                                 RX Options.         (line   15)
  * nolibc:                                Link Options.       (line  133)
--- 68131,68138 ----
  * noall_load:                            Darwin Options.     (line  197)
  * nocpp:                                 MIPS Options.       (line  641)
  * nodefaultlibs:                         Link Options.       (line  121)
! * nodevicelib:                           AVR Options.        (line  293)
! * nodevicespecs:                         AVR Options.        (line  296)
  * nofixprebinding:                       Darwin Options.     (line  197)
  * nofpu:                                 RX Options.         (line   15)
  * nolibc:                                Link Options.       (line  133)
*************** look up both forms.
*** 68138,68145 ****
  * nostdinc++ <1>:                        Directory Options.  (line  107)
  * nostdlib:                              Link Options.       (line  145)
  * nostdlib++:                            Link Options.       (line  170)
! * no_dead_strip_inits_and_terms:         Darwin Options.     (line  197)
! * o:                                     Overall Options.    (line  192)
  * O:                                     Optimize Options.   (line   37)
  * O0:                                    Optimize Options.   (line  165)
  * O1:                                    Optimize Options.   (line   37)
--- 68148,68154 ----
  * nostdinc++ <1>:                        Directory Options.  (line  107)
  * nostdlib:                              Link Options.       (line  145)
  * nostdlib++:                            Link Options.       (line  170)
! * o:                                     Overall Options.    (line  196)
  * O:                                     Optimize Options.   (line   37)
  * O0:                                    Optimize Options.   (line  165)
  * O1:                                    Optimize Options.   (line   37)
*************** look up both forms.
*** 68157,68163 ****
                                                               (line  852)
  * pagezero_size:                         Darwin Options.     (line  197)
  * param:                                 Optimize Options.   (line 2759)
! * pass-exit-codes:                       Overall Options.    (line  596)
  * pedantic:                              Standards.          (line   13)
  * pedantic <1>:                          Warning Options.    (line   86)
  * pedantic <2>:                          C Extensions.       (line    6)
--- 68166,68172 ----
                                                               (line  852)
  * pagezero_size:                         Darwin Options.     (line  197)
  * param:                                 Optimize Options.   (line 2759)
! * pass-exit-codes:                       Overall Options.    (line  600)
  * pedantic:                              Standards.          (line   13)
  * pedantic <1>:                          Warning Options.    (line   86)
  * pedantic <2>:                          C Extensions.       (line    6)
*************** look up both forms.
*** 68174,68180 ****
  * pg <1>:                                Common Function Attributes.
                                                               (line  852)
  * pie:                                   Link Options.       (line  180)
! * pipe:                                  Overall Options.    (line  604)
  * plt:                                   RISC-V Options.     (line   11)
  * prebind:                               Darwin Options.     (line  197)
  * prebind_all_twolevel_modules:          Darwin Options.     (line  197)
--- 68183,68189 ----
  * pg <1>:                                Common Function Attributes.
                                                               (line  852)
  * pie:                                   Link Options.       (line  180)
! * pipe:                                  Overall Options.    (line  608)
  * plt:                                   RISC-V Options.     (line   11)
  * prebind:                               Darwin Options.     (line  197)
  * prebind_all_twolevel_modules:          Darwin Options.     (line  197)
*************** look up both forms.
*** 68203,68209 ****
  * read_only_relocs:                      Darwin Options.     (line  197)
  * remap:                                 Preprocessor Options.
                                                               (line  400)
! * S:                                     Overall Options.    (line  175)
  * S <1>:                                 Link Options.       (line   17)
  * s:                                     Link Options.       (line  215)
  * save-temps:                            Developer Options.  (line  805)
--- 68212,68218 ----
  * read_only_relocs:                      Darwin Options.     (line  197)
  * remap:                                 Preprocessor Options.
                                                               (line  400)
! * S:                                     Overall Options.    (line  179)
  * S <1>:                                 Link Options.       (line   17)
  * s:                                     Link Options.       (line  215)
  * save-temps:                            Developer Options.  (line  805)
*************** look up both forms.
*** 68214,68219 ****
--- 68223,68230 ----
  * sectobjectsymbols:                     Darwin Options.     (line  197)
  * sectobjectsymbols <1>:                 Darwin Options.     (line  197)
  * sectorder:                             Darwin Options.     (line  197)
+ * seg_addr_table:                        Darwin Options.     (line  197)
+ * seg_addr_table_filename:               Darwin Options.     (line  197)
  * seg1addr:                              Darwin Options.     (line  197)
  * segaddr:                               Darwin Options.     (line  197)
  * seglinkedit:                           Darwin Options.     (line  197)
*************** look up both forms.
*** 68222,68229 ****
  * segs_read_only_addr <1>:               Darwin Options.     (line  197)
  * segs_read_write_addr:                  Darwin Options.     (line  197)
  * segs_read_write_addr <1>:              Darwin Options.     (line  197)
- * seg_addr_table:                        Darwin Options.     (line  197)
- * seg_addr_table_filename:               Darwin Options.     (line  197)
  * shared:                                Link Options.       (line  224)
  * shared-libgcc:                         Link Options.       (line  231)
  * short-calls:                           Adapteva Epiphany Options.
--- 68233,68238 ----
*************** look up both forms.
*** 68231,68237 ****
  * sim:                                   CRIS Options.       (line   80)
  * sim2:                                  CRIS Options.       (line   85)
  * single_module:                         Darwin Options.     (line  197)
! * specs:                                 Overall Options.    (line  610)
  * static:                                Link Options.       (line  219)
  * static <1>:                            Darwin Options.     (line  197)
  * static <2>:                            HPPA Options.       (line  223)
--- 68240,68246 ----
  * sim:                                   CRIS Options.       (line   80)
  * sim2:                                  CRIS Options.       (line   85)
  * single_module:                         Darwin Options.     (line  197)
! * specs:                                 Overall Options.    (line  614)
  * static:                                Link Options.       (line  219)
  * static <1>:                            Darwin Options.     (line  197)
  * static <2>:                            HPPA Options.       (line  223)
*************** look up both forms.
*** 68253,68259 ****
  * symbolic:                              Link Options.       (line  310)
  * sysroot:                               Directory Options.  (line  167)
  * T:                                     Link Options.       (line  316)
! * target-help:                           Overall Options.    (line  486)
  * threads:                               HPPA Options.       (line  236)
  * time:                                  Developer Options.  (line  825)
  * tno-android-cc:                        GNU/Linux Options.  (line   35)
--- 68262,68268 ----
  * symbolic:                              Link Options.       (line  310)
  * sysroot:                               Directory Options.  (line  167)
  * T:                                     Link Options.       (line  316)
! * target-help:                           Overall Options.    (line  490)
  * threads:                               HPPA Options.       (line  236)
  * time:                                  Developer Options.  (line  825)
  * tno-android-cc:                        GNU/Linux Options.  (line   35)
*************** look up both forms.
*** 68274,68281 ****
                                                               (line   65)
  * undefined:                             Darwin Options.     (line  197)
  * unexported_symbols_list:               Darwin Options.     (line  197)
! * v:                                     Overall Options.    (line  465)
! * version:                               Overall Options.    (line  593)
  * w:                                     Warning Options.    (line   24)
  * W:                                     Warning Options.    (line  223)
  * W <1>:                                 Warning Options.    (line 3059)
--- 68283,68290 ----
                                                               (line   65)
  * undefined:                             Darwin Options.     (line  197)
  * unexported_symbols_list:               Darwin Options.     (line  197)
! * v:                                     Overall Options.    (line  469)
! * version:                               Overall Options.    (line  597)
  * w:                                     Warning Options.    (line   24)
  * W:                                     Warning Options.    (line  223)
  * W <1>:                                 Warning Options.    (line 3059)
*************** look up both forms.
*** 68286,68292 ****
  * Wabi-tag:                              C++ Dialect Options.
                                                               (line  668)
  * Wabsolute-value:                       Warning Options.    (line 2430)
! * Waddr-space-convert:                   AVR Options.        (line  305)
  * Waddress:                              Warning Options.    (line 2892)
  * Waddress-of-packed-member:             Warning Options.    (line 2926)
  * Waggregate-return:                     Warning Options.    (line 2954)
--- 68295,68301 ----
  * Wabi-tag:                              C++ Dialect Options.
                                                               (line  668)
  * Wabsolute-value:                       Warning Options.    (line 2430)
! * Waddr-space-convert:                   AVR Options.        (line  311)
  * Waddress:                              Warning Options.    (line 2892)
  * Waddress-of-packed-member:             Warning Options.    (line 2926)
  * Waggregate-return:                     Warning Options.    (line 2954)
*************** look up both forms.
*** 68587,68593 ****
  * Wmissing-prototypes:                   Warning Options.    (line 3039)
  * Wmissing-requires:                     Warning Options.    (line 3089)
  * Wmissing-template-keyword:             Warning Options.    (line 3106)
! * Wmisspelled-isr:                       AVR Options.        (line  310)
  * Wmultichar:                            Warning Options.    (line 3134)
  * Wmultiple-inheritance:                 C++ Dialect Options.
                                                               (line 1277)
--- 68596,68602 ----
  * Wmissing-prototypes:                   Warning Options.    (line 3039)
  * Wmissing-requires:                     Warning Options.    (line 3089)
  * Wmissing-template-keyword:             Warning Options.    (line 3106)
! * Wmisspelled-isr:                       AVR Options.        (line  316)
  * Wmultichar:                            Warning Options.    (line 3134)
  * Wmultiple-inheritance:                 C++ Dialect Options.
                                                               (line 1277)
*************** look up both forms.
*** 68599,68605 ****
  * Wnested-externs:                       Warning Options.    (line 3306)
  * Wno-abi:                               Warning Options.    (line  269)
  * Wno-absolute-value:                    Warning Options.    (line 2430)
! * Wno-addr-space-convert:                AVR Options.        (line  305)
  * Wno-address:                           Warning Options.    (line 2892)
  * Wno-address-of-packed-member:          Warning Options.    (line 2926)
  * Wno-aggregate-return:                  Warning Options.    (line 2954)
--- 68608,68614 ----
  * Wnested-externs:                       Warning Options.    (line 3306)
  * Wno-abi:                               Warning Options.    (line  269)
  * Wno-absolute-value:                    Warning Options.    (line 2430)
! * Wno-addr-space-convert:                AVR Options.        (line  311)
  * Wno-address:                           Warning Options.    (line 2892)
  * Wno-address-of-packed-member:          Warning Options.    (line 2926)
  * Wno-aggregate-return:                  Warning Options.    (line 2954)
*************** look up both forms.
*** 68882,68888 ****
  * Wno-missing-prototypes:                Warning Options.    (line 3039)
  * Wno-missing-requires:                  Warning Options.    (line 3089)
  * Wno-missing-template-keyword:          Warning Options.    (line 3106)
! * Wno-misspelled-isr:                    AVR Options.        (line  310)
  * Wno-multichar:                         Warning Options.    (line 3134)
  * Wno-multiple-inheritance:              C++ Dialect Options.
                                                               (line 1277)
--- 68891,68897 ----
  * Wno-missing-prototypes:                Warning Options.    (line 3039)
  * Wno-missing-requires:                  Warning Options.    (line 3089)
  * Wno-missing-template-keyword:          Warning Options.    (line 3106)
! * Wno-misspelled-isr:                    AVR Options.        (line  316)
  * Wno-multichar:                         Warning Options.    (line 3134)
  * Wno-multiple-inheritance:              C++ Dialect Options.
                                                               (line 1277)
*************** look up both forms.
*** 69126,69132 ****
                                                               (line  180)
  * Wrange-loop-construct:                 C++ Dialect Options.
                                                               (line 1048)
! * wrapper:                               Overall Options.    (line  619)
  * Wredundant-decls:                      Warning Options.    (line 3283)
  * Wredundant-move:                       C++ Dialect Options.
                                                               (line 1009)
--- 69135,69141 ----
                                                               (line  180)
  * Wrange-loop-construct:                 C++ Dialect Options.
                                                               (line 1048)
! * wrapper:                               Overall Options.    (line  623)
  * Wredundant-decls:                      Warning Options.    (line 3283)
  * Wredundant-move:                       C++ Dialect Options.
                                                               (line 1009)
*************** A.2 Concept and Symbol Index
*** 69278,69356 ****
  [index]
  * Menu:
  
- * #pragma:                               Pragmas.            (line    6)
- * #pragma implementation:                C++ Interface.      (line   34)
- * #pragma implementation, implied:       C++ Interface.      (line   43)
- * #pragma interface:                     C++ Interface.      (line   15)
- * $:                                     Dollar Signs.       (line    6)
- * % in constraint:                       Modifiers.          (line   52)
- * %include:                              Spec Files.         (line   25)
- * %include_noerr:                        Spec Files.         (line   29)
- * %rename:                               Spec Files.         (line   33)
- * & in constraint:                       Modifiers.          (line   25)
- * ':                                     Incompatibilities.  (line  116)
- * + in constraint:                       Modifiers.          (line   12)
- * -lgcc, use with -nodefaultlibs:        Link Options.       (line  157)
- * -lgcc, use with -nostdlib:             Link Options.       (line  157)
- * -march feature modifiers:              AArch64 Options.    (line  335)
- * -mcpu feature modifiers:               AArch64 Options.    (line  335)
- * -nodefaultlibs and unresolved references: Link Options.    (line  157)
- * -nostdlib and unresolved references:   Link Options.       (line  157)
- * .sdata/.sdata2 references (PowerPC):   RS/6000 and PowerPC Options.
-                                                              (line  713)
- * //:                                    C++ Comments.       (line    6)
- * 0 in constraint:                       Simple Constraints. (line  125)
- * < in constraint:                       Simple Constraints. (line   47)
- * = in constraint:                       Modifiers.          (line    8)
- * > in constraint:                       Simple Constraints. (line   59)
- * ?: extensions:                         Conditionals.       (line    6)
- * ?: side effect:                        Conditionals.       (line   20)
  * _ in variables in macros:              Typeof.             (line   46)
- * _Accum data type:                      Fixed-Point.        (line    6)
- * _Complex keyword:                      Complex.            (line    6)
- * _Decimal128 data type:                 Decimal Float.      (line    6)
- * _Decimal32 data type:                  Decimal Float.      (line    6)
- * _Decimal64 data type:                  Decimal Float.      (line    6)
- * _Exit:                                 Other Builtins.     (line    6)
- * _exit:                                 Other Builtins.     (line    6)
- * _FloatN data types:                    Floating Types.     (line    6)
- * _FloatNx data types:                   Floating Types.     (line    6)
- * _Fract data type:                      Fixed-Point.        (line    6)
- * _get_ssp:                              x86 control-flow protection intrinsics.
-                                                              (line    6)
- * _HTM_FIRST_USER_ABORT_CODE:            S/390 System z Built-in Functions.
-                                                              (line   47)
- * _HTM_TBEGIN_INDETERMINATE:             S/390 System z Built-in Functions.
-                                                              (line   35)
- * _HTM_TBEGIN_PERSISTENT:                S/390 System z Built-in Functions.
-                                                              (line   43)
- * _HTM_TBEGIN_STARTED:                   S/390 System z Built-in Functions.
-                                                              (line   31)
- * _HTM_TBEGIN_TRANSIENT:                 S/390 System z Built-in Functions.
-                                                              (line   39)
- * _inc_ssp:                              x86 control-flow protection intrinsics.
-                                                              (line   12)
- * _Sat data type:                        Fixed-Point.        (line    6)
- * _xabort:                               x86 transactional memory intrinsics.
-                                                              (line   62)
- * _XABORT_CAPACITY:                      x86 transactional memory intrinsics.
-                                                              (line   40)
- * _XABORT_CONFLICT:                      x86 transactional memory intrinsics.
-                                                              (line   36)
- * _XABORT_DEBUG:                         x86 transactional memory intrinsics.
-                                                              (line   44)
- * _XABORT_EXPLICIT:                      x86 transactional memory intrinsics.
-                                                              (line   28)
- * _XABORT_NESTED:                        x86 transactional memory intrinsics.
-                                                              (line   47)
- * _XABORT_RETRY:                         x86 transactional memory intrinsics.
-                                                              (line   33)
- * _xbegin:                               x86 transactional memory intrinsics.
-                                                              (line   19)
- * _xend:                                 x86 transactional memory intrinsics.
-                                                              (line   53)
- * _xtest:                                x86 transactional memory intrinsics.
-                                                              (line   58)
  * __atomic_add_fetch:                    __atomic Builtins.  (line  177)
  * __atomic_always_lock_free:             __atomic Builtins.  (line  265)
  * __atomic_and_fetch:                    __atomic Builtins.  (line  181)
--- 69287,69293 ----
*************** A.2 Concept and Symbol Index
*** 69377,69388 ****
  * __atomic_test_and_set:                 __atomic Builtins.  (line  227)
  * __atomic_thread_fence:                 __atomic Builtins.  (line  251)
  * __atomic_xor_fetch:                    __atomic Builtins.  (line  183)
! * __builtin_addf128_round_to_odd:        Basic PowerPC Built-in Functions Available on ISA 3.0.
!                                                              (line   15)
  * __builtin_add_overflow:                Integer Overflow Builtins.
                                                               (line    9)
  * __builtin_add_overflow_p:              Integer Overflow Builtins.
                                                               (line   86)
  * __builtin_alloca:                      Other Builtins.     (line  138)
  * __builtin_alloca_with_align:           Other Builtins.     (line  175)
  * __builtin_alloca_with_align_and_max:   Other Builtins.     (line  220)
--- 69314,69352 ----
  * __atomic_test_and_set:                 __atomic Builtins.  (line  227)
  * __atomic_thread_fence:                 __atomic Builtins.  (line  251)
  * __atomic_xor_fetch:                    __atomic Builtins.  (line  183)
! * __builtin___clear_cache:               Other Builtins.     (line  769)
! * __builtin___memcpy_chk:                Object Size Checking.
!                                                              (line    9)
! * __builtin___memmove_chk:               Object Size Checking.
!                                                              (line    9)
! * __builtin___mempcpy_chk:               Object Size Checking.
!                                                              (line    9)
! * __builtin___memset_chk:                Object Size Checking.
!                                                              (line    9)
! * __builtin___snprintf_chk:              Object Size Checking.
!                                                              (line  121)
! * __builtin___sprintf_chk:               Object Size Checking.
!                                                              (line  119)
! * __builtin___stpcpy_chk:                Object Size Checking.
!                                                              (line    9)
! * __builtin___strcat_chk:                Object Size Checking.
!                                                              (line    9)
! * __builtin___strcpy_chk:                Object Size Checking.
!                                                              (line    9)
! * __builtin___strncat_chk:               Object Size Checking.
!                                                              (line    9)
! * __builtin___strncpy_chk:               Object Size Checking.
!                                                              (line    9)
! * __builtin___vsnprintf_chk:             Object Size Checking.
!                                                              (line  125)
! * __builtin___vsprintf_chk:              Object Size Checking.
!                                                              (line  123)
  * __builtin_add_overflow:                Integer Overflow Builtins.
                                                               (line    9)
  * __builtin_add_overflow_p:              Integer Overflow Builtins.
                                                               (line   86)
+ * __builtin_addf128_round_to_odd:        Basic PowerPC Built-in Functions Available on ISA 3.0.
+                                                              (line   15)
  * __builtin_alloca:                      Other Builtins.     (line  138)
  * __builtin_alloca_with_align:           Other Builtins.     (line  175)
  * __builtin_alloca_with_align_and_max:   Other Builtins.     (line  220)
*************** A.2 Concept and Symbol Index
*** 69565,69570 ****
--- 69529,69535 ----
  * __builtin_infl:                        Other Builtins.     (line  883)
  * __builtin_infq:                        x86 Built-in Functions.
                                                               (line   46)
+ * __builtin_is_constant_evaluated:       Other Builtins.     (line  544)
  * __builtin_isfinite:                    Other Builtins.     (line    6)
  * __builtin_isgreater:                   Other Builtins.     (line    6)
  * __builtin_isgreaterequal:              Other Builtins.     (line    6)
*************** A.2 Concept and Symbol Index
*** 69572,69586 ****
  * __builtin_isnormal:                    Other Builtins.     (line    6)
  * __builtin_issignaling:                 Other Builtins.     (line  969)
  * __builtin_isunordered:                 Other Builtins.     (line    6)
- * __builtin_is_constant_evaluated:       Other Builtins.     (line  544)
  * __builtin_LINE:                        Other Builtins.     (line  729)
  * __builtin_longjmp:                     Nonlocal Gotos.     (line   37)
- * __builtin_mulf128_round_to_odd:        Basic PowerPC Built-in Functions Available on ISA 3.0.
-                                                              (line   25)
  * __builtin_mul_overflow:                Integer Overflow Builtins.
                                                               (line   63)
  * __builtin_mul_overflow_p:              Integer Overflow Builtins.
                                                               (line   90)
  * __builtin_nan:                         Other Builtins.     (line  901)
  * __builtin_nand128:                     Other Builtins.     (line  923)
  * __builtin_nand32:                      Other Builtins.     (line  917)
--- 69537,69550 ----
  * __builtin_isnormal:                    Other Builtins.     (line    6)
  * __builtin_issignaling:                 Other Builtins.     (line  969)
  * __builtin_isunordered:                 Other Builtins.     (line    6)
  * __builtin_LINE:                        Other Builtins.     (line  729)
  * __builtin_longjmp:                     Nonlocal Gotos.     (line   37)
  * __builtin_mul_overflow:                Integer Overflow Builtins.
                                                               (line   63)
  * __builtin_mul_overflow_p:              Integer Overflow Builtins.
                                                               (line   90)
+ * __builtin_mulf128_round_to_odd:        Basic PowerPC Built-in Functions Available on ISA 3.0.
+                                                              (line   25)
  * __builtin_nan:                         Other Builtins.     (line  901)
  * __builtin_nand128:                     Other Builtins.     (line  923)
  * __builtin_nand32:                      Other Builtins.     (line  917)
*************** A.2 Concept and Symbol Index
*** 69693,69747 ****
                                                               (line   91)
  * __builtin_rx_wait:                     RX Built-in Functions.
                                                               (line   95)
- * __builtin_saddll_overflow:             Integer Overflow Builtins.
-                                                              (line   15)
- * __builtin_saddl_overflow:              Integer Overflow Builtins.
-                                                              (line   13)
  * __builtin_sadd_overflow:               Integer Overflow Builtins.
                                                               (line   11)
! * __builtin_setjmp:                      Nonlocal Gotos.     (line   32)
  * __builtin_set_thread_pointer:          SH Built-in Functions.
                                                               (line    9)
! * __builtin_shuffle:                     Vector Extensions.  (line  127)
! * __builtin_shufflevector:               Vector Extensions.  (line  165)
  * __builtin_sh_get_fpscr:                SH Built-in Functions.
                                                               (line   35)
  * __builtin_sh_set_fpscr:                SH Built-in Functions.
                                                               (line   38)
! * __builtin_smulll_overflow:             Integer Overflow Builtins.
!                                                              (line   69)
! * __builtin_smull_overflow:              Integer Overflow Builtins.
!                                                              (line   67)
  * __builtin_smul_overflow:               Integer Overflow Builtins.
                                                               (line   65)
  * __builtin_speculation_safe_value:      Other Builtins.     (line    6)
  * __builtin_speculation_safe_value <1>:  Other Builtins.     (line  270)
  * __builtin_sqrtf128_round_to_odd:       Basic PowerPC Built-in Functions Available on ISA 3.0.
                                                               (line   35)
- * __builtin_ssubll_overflow:             Integer Overflow Builtins.
-                                                              (line   49)
- * __builtin_ssubl_overflow:              Integer Overflow Builtins.
-                                                              (line   47)
  * __builtin_ssub_overflow:               Integer Overflow Builtins.
                                                               (line   45)
! * __builtin_subf128_round_to_odd:        Basic PowerPC Built-in Functions Available on ISA 3.0.
!                                                              (line   20)
  * __builtin_sub_overflow:                Integer Overflow Builtins.
                                                               (line   43)
  * __builtin_sub_overflow_p:              Integer Overflow Builtins.
                                                               (line   88)
  * __builtin_tabort:                      S/390 System z Built-in Functions.
                                                               (line   85)
  * __builtin_tbegin:                      S/390 System z Built-in Functions.
                                                               (line    6)
- * __builtin_tbeginc:                     S/390 System z Built-in Functions.
-                                                              (line   76)
  * __builtin_tbegin_nofloat:              S/390 System z Built-in Functions.
                                                               (line   57)
  * __builtin_tbegin_retry:                S/390 System z Built-in Functions.
                                                               (line   63)
  * __builtin_tbegin_retry_nofloat:        S/390 System z Built-in Functions.
                                                               (line   70)
  * __builtin_tend:                        S/390 System z Built-in Functions.
                                                               (line   80)
  * __builtin_tgmath:                      Other Builtins.     (line  445)
--- 69657,69711 ----
                                                               (line   91)
  * __builtin_rx_wait:                     RX Built-in Functions.
                                                               (line   95)
  * __builtin_sadd_overflow:               Integer Overflow Builtins.
                                                               (line   11)
! * __builtin_saddl_overflow:              Integer Overflow Builtins.
!                                                              (line   13)
! * __builtin_saddll_overflow:             Integer Overflow Builtins.
!                                                              (line   15)
  * __builtin_set_thread_pointer:          SH Built-in Functions.
                                                               (line    9)
! * __builtin_setjmp:                      Nonlocal Gotos.     (line   32)
  * __builtin_sh_get_fpscr:                SH Built-in Functions.
                                                               (line   35)
  * __builtin_sh_set_fpscr:                SH Built-in Functions.
                                                               (line   38)
! * __builtin_shuffle:                     Vector Extensions.  (line  127)
! * __builtin_shufflevector:               Vector Extensions.  (line  165)
  * __builtin_smul_overflow:               Integer Overflow Builtins.
                                                               (line   65)
+ * __builtin_smull_overflow:              Integer Overflow Builtins.
+                                                              (line   67)
+ * __builtin_smulll_overflow:             Integer Overflow Builtins.
+                                                              (line   69)
  * __builtin_speculation_safe_value:      Other Builtins.     (line    6)
  * __builtin_speculation_safe_value <1>:  Other Builtins.     (line  270)
  * __builtin_sqrtf128_round_to_odd:       Basic PowerPC Built-in Functions Available on ISA 3.0.
                                                               (line   35)
  * __builtin_ssub_overflow:               Integer Overflow Builtins.
                                                               (line   45)
! * __builtin_ssubl_overflow:              Integer Overflow Builtins.
!                                                              (line   47)
! * __builtin_ssubll_overflow:             Integer Overflow Builtins.
!                                                              (line   49)
  * __builtin_sub_overflow:                Integer Overflow Builtins.
                                                               (line   43)
  * __builtin_sub_overflow_p:              Integer Overflow Builtins.
                                                               (line   88)
+ * __builtin_subf128_round_to_odd:        Basic PowerPC Built-in Functions Available on ISA 3.0.
+                                                              (line   20)
  * __builtin_tabort:                      S/390 System z Built-in Functions.
                                                               (line   85)
  * __builtin_tbegin:                      S/390 System z Built-in Functions.
                                                               (line    6)
  * __builtin_tbegin_nofloat:              S/390 System z Built-in Functions.
                                                               (line   57)
  * __builtin_tbegin_retry:                S/390 System z Built-in Functions.
                                                               (line   63)
  * __builtin_tbegin_retry_nofloat:        S/390 System z Built-in Functions.
                                                               (line   70)
+ * __builtin_tbeginc:                     S/390 System z Built-in Functions.
+                                                              (line   76)
  * __builtin_tend:                        S/390 System z Built-in Functions.
                                                               (line   80)
  * __builtin_tgmath:                      Other Builtins.     (line  445)
*************** A.2 Concept and Symbol Index
*** 69757,69810 ****
  * __builtin_tx_nesting_depth:            S/390 System z Built-in Functions.
                                                               (line   96)
  * __builtin_types_compatible_p:          Other Builtins.     (line  349)
- * __builtin_uaddll_overflow:             Integer Overflow Builtins.
-                                                              (line   21)
- * __builtin_uaddl_overflow:              Integer Overflow Builtins.
-                                                              (line   19)
  * __builtin_uadd_overflow:               Integer Overflow Builtins.
                                                               (line   17)
! * __builtin_umulll_overflow:             Integer Overflow Builtins.
!                                                              (line   75)
! * __builtin_umull_overflow:              Integer Overflow Builtins.
!                                                              (line   73)
  * __builtin_umul_overflow:               Integer Overflow Builtins.
                                                               (line   71)
  * __builtin_unreachable:                 Other Builtins.     (line  647)
- * __builtin_usubll_overflow:             Integer Overflow Builtins.
-                                                              (line   55)
- * __builtin_usubl_overflow:              Integer Overflow Builtins.
-                                                              (line   53)
  * __builtin_usub_overflow:               Integer Overflow Builtins.
                                                               (line   51)
  * __builtin_va_arg_pack:                 Constructing Calls. (line   52)
  * __builtin_va_arg_pack_len:             Constructing Calls. (line   75)
- * __builtin___clear_cache:               Other Builtins.     (line  769)
- * __builtin___memcpy_chk:                Object Size Checking.
-                                                              (line    9)
- * __builtin___memmove_chk:               Object Size Checking.
-                                                              (line    9)
- * __builtin___mempcpy_chk:               Object Size Checking.
-                                                              (line    9)
- * __builtin___memset_chk:                Object Size Checking.
-                                                              (line    9)
- * __builtin___snprintf_chk:              Object Size Checking.
-                                                              (line  121)
- * __builtin___sprintf_chk:               Object Size Checking.
-                                                              (line  119)
- * __builtin___stpcpy_chk:                Object Size Checking.
-                                                              (line    9)
- * __builtin___strcat_chk:                Object Size Checking.
-                                                              (line    9)
- * __builtin___strcpy_chk:                Object Size Checking.
-                                                              (line    9)
- * __builtin___strncat_chk:               Object Size Checking.
-                                                              (line    9)
- * __builtin___strncpy_chk:               Object Size Checking.
-                                                              (line    9)
- * __builtin___vsnprintf_chk:             Object Size Checking.
-                                                              (line  125)
- * __builtin___vsprintf_chk:              Object Size Checking.
-                                                              (line  123)
  * __complex__ keyword:                   Complex.            (line    6)
  * __declspec(dllexport):                 Microsoft Windows Function Attributes.
                                                               (line    9)
--- 69721,69747 ----
  * __builtin_tx_nesting_depth:            S/390 System z Built-in Functions.
                                                               (line   96)
  * __builtin_types_compatible_p:          Other Builtins.     (line  349)
  * __builtin_uadd_overflow:               Integer Overflow Builtins.
                                                               (line   17)
! * __builtin_uaddl_overflow:              Integer Overflow Builtins.
!                                                              (line   19)
! * __builtin_uaddll_overflow:             Integer Overflow Builtins.
!                                                              (line   21)
  * __builtin_umul_overflow:               Integer Overflow Builtins.
                                                               (line   71)
+ * __builtin_umull_overflow:              Integer Overflow Builtins.
+                                                              (line   73)
+ * __builtin_umulll_overflow:             Integer Overflow Builtins.
+                                                              (line   75)
  * __builtin_unreachable:                 Other Builtins.     (line  647)
  * __builtin_usub_overflow:               Integer Overflow Builtins.
                                                               (line   51)
+ * __builtin_usubl_overflow:              Integer Overflow Builtins.
+                                                              (line   53)
+ * __builtin_usubll_overflow:             Integer Overflow Builtins.
+                                                              (line   55)
  * __builtin_va_arg_pack:                 Constructing Calls. (line   52)
  * __builtin_va_arg_pack_len:             Constructing Calls. (line   75)
  * __complex__ keyword:                   Complex.            (line    6)
  * __declspec(dllexport):                 Microsoft Windows Function Attributes.
                                                               (line    9)
*************** A.2 Concept and Symbol Index
*** 69833,69840 ****
  * __Float16 data type:                   Half-Precision.     (line    6)
  * __float80 data type:                   Floating Types.     (line    6)
  * __fp16 data type:                      Half-Precision.     (line    6)
- * __FUNCTION__ identifier:               Function Names.     (line    6)
  * __func__ identifier:                   Function Names.     (line    6)
  * __halt:                                PRU Built-in Functions.
                                                               (line   20)
  * __has_nothrow_assign:                  Type Traits.        (line   10)
--- 69770,69777 ----
  * __Float16 data type:                   Half-Precision.     (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)
  * __halt:                                PRU Built-in Functions.
                                                               (line   20)
  * __has_nothrow_assign:                  Type Traits.        (line   10)
*************** A.2 Concept and Symbol Index
*** 69895,69900 ****
--- 69832,69909 ----
  * __sync_xor_and_fetch:                  __sync Builtins.    (line   80)
  * __thread:                              Thread-Local.       (line    6)
  * __underlying_type:                     Type Traits.        (line  143)
+ * _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)
+ * _FloatN data types:                    Floating Types.     (line    6)
+ * _FloatNx data types:                   Floating Types.     (line    6)
+ * _Fract data type:                      Fixed-Point.        (line    6)
+ * _get_ssp:                              x86 control-flow protection intrinsics.
+                                                              (line    6)
+ * _HTM_FIRST_USER_ABORT_CODE:            S/390 System z Built-in Functions.
+                                                              (line   47)
+ * _HTM_TBEGIN_INDETERMINATE:             S/390 System z Built-in Functions.
+                                                              (line   35)
+ * _HTM_TBEGIN_PERSISTENT:                S/390 System z Built-in Functions.
+                                                              (line   43)
+ * _HTM_TBEGIN_STARTED:                   S/390 System z Built-in Functions.
+                                                              (line   31)
+ * _HTM_TBEGIN_TRANSIENT:                 S/390 System z Built-in Functions.
+                                                              (line   39)
+ * _inc_ssp:                              x86 control-flow protection intrinsics.
+                                                              (line   12)
+ * _Sat data type:                        Fixed-Point.        (line    6)
+ * _xabort:                               x86 transactional memory intrinsics.
+                                                              (line   62)
+ * _XABORT_CAPACITY:                      x86 transactional memory intrinsics.
+                                                              (line   40)
+ * _XABORT_CONFLICT:                      x86 transactional memory intrinsics.
+                                                              (line   36)
+ * _XABORT_DEBUG:                         x86 transactional memory intrinsics.
+                                                              (line   44)
+ * _XABORT_EXPLICIT:                      x86 transactional memory intrinsics.
+                                                              (line   28)
+ * _XABORT_NESTED:                        x86 transactional memory intrinsics.
+                                                              (line   47)
+ * _XABORT_RETRY:                         x86 transactional memory intrinsics.
+                                                              (line   33)
+ * _xbegin:                               x86 transactional memory intrinsics.
+                                                              (line   19)
+ * _xend:                                 x86 transactional memory intrinsics.
+                                                              (line   53)
+ * _xtest:                                x86 transactional memory intrinsics.
+                                                              (line   58)
+ * -lgcc, use with -nodefaultlibs:        Link Options.       (line  157)
+ * -lgcc, use with -nostdlib:             Link Options.       (line  157)
+ * -march feature modifiers:              AArch64 Options.    (line  335)
+ * -mcpu feature modifiers:               AArch64 Options.    (line  335)
+ * -nodefaultlibs and unresolved references: Link Options.    (line  157)
+ * -nostdlib and unresolved references:   Link Options.       (line  157)
+ * ?: extensions:                         Conditionals.       (line    6)
+ * ?: side effect:                        Conditionals.       (line   20)
+ * .sdata/.sdata2 references (PowerPC):   RS/6000 and PowerPC Options.
+                                                              (line  713)
+ * ':                                     Incompatibilities.  (line  116)
+ * //:                                    C++ Comments.       (line    6)
+ * & in constraint:                       Modifiers.          (line   25)
+ * #pragma:                               Pragmas.            (line    6)
+ * #pragma implementation:                C++ Interface.      (line   34)
+ * #pragma implementation, implied:       C++ Interface.      (line   43)
+ * #pragma interface:                     C++ Interface.      (line   15)
+ * % in constraint:                       Modifiers.          (line   52)
+ * %include:                              Spec Files.         (line   25)
+ * %include_noerr:                        Spec Files.         (line   29)
+ * %rename:                               Spec Files.         (line   33)
+ * + in constraint:                       Modifiers.          (line   12)
+ * < in constraint:                       Simple Constraints. (line   47)
+ * = in constraint:                       Modifiers.          (line    8)
+ * > in constraint:                       Simple Constraints. (line   59)
+ * $:                                     Dollar Signs.       (line    6)
+ * 0 in constraint:                       Simple Constraints. (line  125)
  * AArch64 Options:                       AArch64 Options.    (line    6)
  * ABI:                                   Compatibility.      (line    6)
  * abi_tag function attribute:            C++ Attributes.     (line    8)
*************** A.2 Concept and Symbol Index
*** 69931,69938 ****
  * aligned variable attribute:            Common Variable Attributes.
                                                               (line   31)
  * alignment:                             Alignment.          (line    6)
- * alloca:                                Other Builtins.     (line    6)
- * alloca vs variable-length arrays:      Variable Length.    (line   35)
  * alloc_align function attribute:        Common Function Attributes.
                                                               (line  146)
  * alloc_size function attribute:         Common Function Attributes.
--- 69940,69945 ----
*************** A.2 Concept and Symbol Index
*** 69941,69946 ****
--- 69948,69955 ----
                                                               (line  134)
  * alloc_size variable attribute:         Common Variable Attributes.
                                                               (line  161)
+ * alloca:                                Other Builtins.     (line    6)
+ * alloca vs variable-length arrays:      Variable Length.    (line   35)
  * Allow nesting in an interrupt handler on the Blackfin processor: Blackfin Function Attributes.
                                                               (line   44)
  * Altera Nios II options:                Nios II Options.    (line    6)
*************** A.2 Concept and Symbol Index
*** 69967,69975 ****
                                                               (line   52)
  * arch= function attribute, ARM:         ARM Function Attributes.
                                                               (line   97)
- * ARM options:                           ARM Options.        (line    6)
  * ARM [Annotated C++ Reference Manual]:  Backwards Compatibility.
                                                               (line    6)
  * arrays of length zero:                 Zero Length.        (line    6)
  * arrays of variable length:             Variable Length.    (line    6)
  * arrays, non-lvalue:                    Subscripting.       (line    6)
--- 69976,69984 ----
                                                               (line   52)
  * arch= function attribute, ARM:         ARM Function Attributes.
                                                               (line   97)
  * 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)
*************** A.2 Concept and Symbol Index
*** 70002,70010 ****
  * assembly language in C, extended:      Extended Asm.       (line    6)
  * assume statement attribute:            Statement Attributes.
                                                               (line   37)
- * assumes:                               C++ Concepts.       (line   15)
  * assume_aligned function attribute:     Common Function Attributes.
                                                               (line  209)
  * atan:                                  Other Builtins.     (line    6)
  * atan2:                                 Other Builtins.     (line    6)
  * atan2f:                                Other Builtins.     (line    6)
--- 70011,70019 ----
  * assembly language in C, extended:      Extended Asm.       (line    6)
  * assume statement attribute:            Statement Attributes.
                                                               (line   37)
  * assume_aligned function attribute:     Common Function Attributes.
                                                               (line  209)
+ * assumes:                               C++ Concepts.       (line   15)
  * atan:                                  Other Builtins.     (line    6)
  * atan2:                                 Other Builtins.     (line    6)
  * atan2f:                                Other Builtins.     (line    6)
*************** A.2 Concept and Symbol Index
*** 70061,70066 ****
--- 70070,70078 ----
                                                               (line  375)
  * C standard:                            Standards.          (line   13)
  * C standards:                           Standards.          (line   13)
+ * C_INCLUDE_PATH:                        Environment Variables.
+                                                              (line  145)
+ * C-SKY Options:                         C-SKY Options.      (line    6)
  * c++:                                   Invoking G++.       (line   14)
  * C++:                                   G++ and GCC.        (line   29)
  * C++ comments:                          C++ Comments.       (line    6)
*************** A.2 Concept and Symbol Index
*** 70080,70086 ****
  * C++ source file suffixes:              Invoking G++.       (line    6)
  * C++ static data, declaring and defining: Static Definitions.
                                                               (line    6)
- * C-SKY Options:                         C-SKY Options.      (line    6)
  * C11:                                   Standards.          (line   13)
  * C17:                                   Standards.          (line   13)
  * C1X:                                   Standards.          (line   13)
--- 70092,70097 ----
*************** A.2 Concept and Symbol Index
*** 70263,70270 ****
  * ctanl:                                 Other Builtins.     (line    6)
  * CXX_MODULE_MAPPER environment variable: C++ Dialect Options.
                                                               (line  413)
- * C_INCLUDE_PATH:                        Environment Variables.
-                                                              (line  145)
  * D:                                     G++ and GCC.        (line    6)
  * Darwin options:                        Darwin Options.     (line    6)
  * dcgettext:                             Other Builtins.     (line    6)
--- 70274,70279 ----
*************** A.2 Concept and Symbol Index
*** 70287,70296 ****
                                                               (line  171)
  * dependencies for make as output <1>:   Environment Variables.
                                                               (line  187)
- * dependencies, make:                    Preprocessor Options.
-                                                              (line   76)
  * DEPENDENCIES_OUTPUT:                   Environment Variables.
                                                               (line  171)
  * dependent name lookup:                 Name lookup.        (line    6)
  * deprecated enumerator attribute:       Enumerator Attributes.
                                                               (line   27)
--- 70296,70305 ----
                                                               (line  171)
  * dependencies for make as output <1>:   Environment Variables.
                                                               (line  187)
  * DEPENDENCIES_OUTPUT:                   Environment Variables.
                                                               (line  171)
+ * dependencies, make:                    Preprocessor Options.
+                                                              (line   76)
  * dependent name lookup:                 Name lookup.        (line    6)
  * deprecated enumerator attribute:       Enumerator Attributes.
                                                               (line   27)
*************** A.2 Concept and Symbol Index
*** 70350,70356 ****
                                                               (line    8)
  * eightbit_data variable attribute, H8/300: H8/300 Variable Attributes.
                                                               (line    8)
! * EIND:                                  AVR Options.        (line  317)
  * either function attribute, MSP430:     MSP430 Function Attributes.
                                                               (line   54)
  * either variable attribute, MSP430:     MSP430 Variable Attributes.
--- 70359,70365 ----
                                                               (line    8)
  * eightbit_data variable attribute, H8/300: H8/300 Variable Attributes.
                                                               (line    8)
! * EIND:                                  AVR Options.        (line  323)
  * either function attribute, MSP430:     MSP430 Function Attributes.
                                                               (line   54)
  * either variable attribute, MSP430:     MSP430 Variable Attributes.
*************** A.2 Concept and Symbol Index
*** 70416,70441 ****
                                                               (line   13)
  * far function attribute, MIPS:          MIPS Function Attributes.
                                                               (line   59)
- * fastcall function attribute, x86-32:   x86 Function Attributes.
-                                                              (line   14)
  * fast_interrupt function attribute, M32C: M32C Function Attributes.
                                                               (line   13)
  * fast_interrupt function attribute, MicroBlaze: MicroBlaze Function Attributes.
                                                               (line   25)
  * fast_interrupt function attribute, RX: RX Function Attributes.
                                                               (line    8)
  * 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)
  * fd_arg function attribute:             Common Function Attributes.
                                                               (line  409)
  * fd_arg_read function attribute:        Common Function Attributes.
                                                               (line  426)
  * fd_arg_write function attribute:       Common Function Attributes.
                                                               (line  436)
  * fentry_name function attribute, x86:   x86 Function Attributes.
                                                               (line  733)
  * fentry_section function attribute, x86: x86 Function Attributes.
--- 70425,70450 ----
                                                               (line   13)
  * far function attribute, MIPS:          MIPS Function Attributes.
                                                               (line   59)
  * fast_interrupt function attribute, M32C: M32C Function Attributes.
                                                               (line   13)
  * fast_interrupt function attribute, MicroBlaze: MicroBlaze Function Attributes.
                                                               (line   25)
  * fast_interrupt function attribute, RX: RX Function Attributes.
                                                               (line    8)
+ * fastcall function attribute, x86-32:   x86 Function Attributes.
+                                                              (line   14)
  * fatal signal:                          Bug Criteria.       (line    9)
  * fd_arg function attribute:             Common Function Attributes.
                                                               (line  409)
  * fd_arg_read function attribute:        Common Function Attributes.
                                                               (line  426)
  * fd_arg_write function attribute:       Common Function Attributes.
                                                               (line  436)
+ * 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)
  * fentry_name function attribute, x86:   x86 Function Attributes.
                                                               (line  733)
  * fentry_section function attribute, x86: x86 Function Attributes.
*************** A.2 Concept and Symbol Index
*** 70507,70512 ****
--- 70516,70529 ----
                                                               (line    6)
  * function versions:                     Function Multiversioning.
                                                               (line    6)
+ * function_return function attribute, x86: x86 Function Attributes.
+                                                              (line  660)
+ * function_vector function attribute, H8/300: H8/300 Function Attributes.
+                                                              (line    8)
+ * function_vector function attribute, M16C/M32C: M32C Function Attributes.
+                                                              (line   19)
+ * function_vector function attribute, SH: SH Function Attributes.
+                                                              (line    8)
  * function, size of pointer to:          Pointer Arith.      (line    6)
  * functions in arbitrary sections:       Common Function Attributes.
                                                               (line 1174)
*************** A.2 Concept and Symbol Index
*** 70536,70559 ****
                                                               (line  948)
  * functions with printf, scanf, strftime or strfmon style arguments: Common Function Attributes.
                                                               (line  451)
- * function_return function attribute, x86: x86 Function Attributes.
-                                                              (line  660)
- * function_vector function attribute, H8/300: H8/300 Function Attributes.
-                                                              (line    8)
- * function_vector function attribute, M16C/M32C: M32C Function Attributes.
-                                                              (line   19)
- * function_vector function attribute, SH: SH Function Attributes.
-                                                              (line    8)
  * G in constraint:                       Simple Constraints. (line   96)
  * g in constraint:                       Simple Constraints. (line  118)
  * g++:                                   Invoking G++.       (line   14)
  * G++:                                   G++ and GCC.        (line   29)
  * gamma:                                 Other Builtins.     (line    6)
  * gammaf:                                Other Builtins.     (line    6)
  * gammaf_r:                              Other Builtins.     (line    6)
  * gammal:                                Other Builtins.     (line    6)
  * gammal_r:                              Other Builtins.     (line    6)
- * gamma_r:                               Other Builtins.     (line    6)
  * GCC:                                   G++ and GCC.        (line    6)
  * GCC command options:                   Invoking GCC.       (line    6)
  * GCC_COLORS environment variable:       Diagnostic Message Formatting Options.
--- 70553,70568 ----
                                                               (line  948)
  * functions with printf, scanf, strftime or strfmon style arguments: Common Function Attributes.
                                                               (line  451)
  * G in constraint:                       Simple Constraints. (line   96)
  * g in constraint:                       Simple Constraints. (line  118)
  * g++:                                   Invoking G++.       (line   14)
  * G++:                                   G++ and GCC.        (line   29)
  * 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_COLORS environment variable:       Diagnostic Message Formatting Options.
*************** A.2 Concept and Symbol Index
*** 70659,70668 ****
                                                               (line  651)
  * indirect_return function attribute, x86: x86 Function Attributes.
                                                               (line  727)
  * initializations in expressions:        Compound Literals.  (line    6)
  * initializers with labeled elements:    Designated Inits.   (line    6)
  * initializers, non-constant:            Initializers.       (line    6)
- * init_priority variable attribute:      C++ Attributes.     (line   49)
  * inline assembly language:              Using Assembly Language with C.
                                                               (line    6)
  * inline automatic for C++ member fns:   Inline.             (line   68)
--- 70668,70677 ----
                                                               (line  651)
  * indirect_return function attribute, x86: x86 Function Attributes.
                                                               (line  727)
+ * init_priority variable attribute:      C++ Attributes.     (line   49)
  * initializations in expressions:        Compound Literals.  (line    6)
  * initializers with labeled elements:    Designated Inits.   (line    6)
  * initializers, non-constant:            Initializers.       (line    6)
  * inline assembly language:              Using Assembly Language with C.
                                                               (line    6)
  * inline automatic for C++ member fns:   Inline.             (line   68)
*************** A.2 Concept and Symbol Index
*** 70835,70845 ****
                                                               (line  707)
  * length-zero arrays:                    Zero Length.        (line    6)
  * lgamma:                                Other Builtins.     (line    6)
  * lgammaf:                               Other Builtins.     (line    6)
  * lgammaf_r:                             Other Builtins.     (line    6)
  * lgammal:                               Other Builtins.     (line    6)
  * lgammal_r:                             Other Builtins.     (line    6)
- * lgamma_r:                              Other Builtins.     (line    6)
  * Libraries:                             Link Options.       (line   85)
  * LIBRARY_PATH:                          Environment Variables.
                                                               (line   96)
--- 70844,70854 ----
                                                               (line  707)
  * 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   85)
  * LIBRARY_PATH:                          Environment Variables.
                                                               (line   96)
*************** A.2 Concept and Symbol Index
*** 70887,70900 ****
  * logf:                                  Other Builtins.     (line    6)
  * logl:                                  Other Builtins.     (line    6)
  * long long data types:                  Long Long.          (line    6)
- * longcall function attribute, Blackfin: Blackfin Function Attributes.
-                                                              (line   36)
- * longcall function attribute, PowerPC:  PowerPC Function Attributes.
-                                                              (line    8)
- * longjmp:                               Global Register Variables.
-                                                              (line   92)
- * longjmp incompatibilities:             Incompatibilities.  (line   39)
- * longjmp warnings:                      Warning Options.    (line 1413)
  * long_call function attribute, ARC:     ARC Function Attributes.
                                                               (line   23)
  * long_call function attribute, ARM:     ARM Function Attributes.
--- 70896,70901 ----
*************** A.2 Concept and Symbol Index
*** 70903,70908 ****
--- 70904,70917 ----
                                                               (line   55)
  * long_call function attribute, MIPS:    MIPS Function Attributes.
                                                               (line   59)
+ * longcall function attribute, Blackfin: Blackfin Function Attributes.
+                                                              (line   36)
+ * longcall function attribute, PowerPC:  PowerPC Function Attributes.
+                                                              (line    8)
+ * longjmp:                               Global Register Variables.
+                                                              (line   92)
+ * longjmp incompatibilities:             Incompatibilities.  (line   39)
+ * longjmp warnings:                      Warning Options.    (line 1413)
  * LoongArch Options:                     LoongArch Options.  (line    6)
  * lower function attribute, MSP430:      MSP430 Function Attributes.
                                                               (line   54)
*************** A.2 Concept and Symbol Index
*** 70986,70992 ****
  * modfl:                                 Other Builtins.     (line    6)
  * modifiers in constraints:              Modifiers.          (line    6)
  * Moxie Options:                         Moxie Options.      (line    6)
- * MSP430 Options:                        MSP430 Options.     (line    6)
  * ms_abi function attribute, x86:        x86 Function Attributes.
                                                               (line   32)
  * ms_hook_prologue function attribute, x86: x86 Function Attributes.
--- 70995,71000 ----
*************** A.2 Concept and Symbol Index
*** 70999,71004 ****
--- 71007,71013 ----
                                                               (line    9)
  * ms_struct variable attribute, x86:     x86 Variable Attributes.
                                                               (line    9)
+ * MSP430 Options:                        MSP430 Options.     (line    6)
  * multiple alternative constraints:      Multi-Alternative.  (line    6)
  * multiprecision arithmetic:             Long Long.          (line    6)
  * n in constraint:                       Simple Constraints. (line   73)
*************** A.2 Concept and Symbol Index
*** 71057,71062 ****
--- 71066,71099 ----
                                                               (line   49)
  * nmi_handler function attribute, Blackfin: Blackfin Function Attributes.
                                                               (line   49)
+ * no_caller_saved_registers function attribute, x86: x86 Function Attributes.
+                                                              (line  112)
+ * no_gccisr function attribute, AVR:     AVR Function Attributes.
+                                                              (line   32)
+ * no_icf function attribute:             Common Function Attributes.
+                                                              (line  848)
+ * no_instrument_function function attribute: Common Function Attributes.
+                                                              (line  852)
+ * no_profile_instrument_function function attribute: Common Function Attributes.
+                                                              (line  858)
+ * no_reorder function attribute:         Common Function Attributes.
+                                                              (line  863)
+ * no_sanitize function attribute:        Common Function Attributes.
+                                                              (line  871)
+ * no_sanitize_address function attribute: Common Function Attributes.
+                                                              (line  882)
+ * no_sanitize_coverage function attribute: Common Function Attributes.
+                                                              (line  902)
+ * no_sanitize_thread function attribute: Common Function Attributes.
+                                                              (line  891)
+ * no_sanitize_undefined function attribute: Common Function Attributes.
+                                                              (line  896)
+ * no_split_stack function attribute:     Common Function Attributes.
+                                                              (line  907)
+ * no_stack_limit function attribute:     Common Function Attributes.
+                                                              (line  913)
+ * no_stack_protector function attribute: Common Function Attributes.
+                                                              (line 1242)
  * nocf_check function attribute:         x86 Function Attributes.
                                                               (line  668)
  * noclone function attribute:            Common Function Attributes.
*************** A.2 Concept and Symbol Index
*** 71090,71131 ****
                                                               (line 1020)
  * nosave_low_regs function attribute, SH: SH Function Attributes.
                                                               (line   33)
  * note GCC_COLORS capability:            Diagnostic Message Formatting Options.
                                                               (line   97)
  * nothrow function attribute:            Common Function Attributes.
                                                               (line 1054)
  * notshared type attribute, ARM:         ARM Type Attributes.
                                                               (line    6)
- * not_nested function attribute, NDS32:  NDS32 Function Attributes.
-                                                              (line   19)
- * no_caller_saved_registers function attribute, x86: x86 Function Attributes.
-                                                              (line  112)
- * no_gccisr function attribute, AVR:     AVR Function Attributes.
-                                                              (line   32)
- * no_icf function attribute:             Common Function Attributes.
-                                                              (line  848)
- * no_instrument_function function attribute: Common Function Attributes.
-                                                              (line  852)
- * no_profile_instrument_function function attribute: Common Function Attributes.
-                                                              (line  858)
- * no_reorder function attribute:         Common Function Attributes.
-                                                              (line  863)
- * no_sanitize function attribute:        Common Function Attributes.
-                                                              (line  871)
- * no_sanitize_address function attribute: Common Function Attributes.
-                                                              (line  882)
- * no_sanitize_coverage function attribute: Common Function Attributes.
-                                                              (line  902)
- * no_sanitize_thread function attribute: Common Function Attributes.
-                                                              (line  891)
- * no_sanitize_undefined function attribute: Common Function Attributes.
-                                                              (line  896)
- * no_split_stack function attribute:     Common Function Attributes.
-                                                              (line  907)
- * no_stack_limit function attribute:     Common Function Attributes.
-                                                              (line  913)
- * no_stack_protector function attribute: Common Function Attributes.
-                                                              (line 1242)
  * Nvidia PTX options:                    Nvidia PTX Options. (line    6)
  * nvptx options:                         Nvidia PTX Options. (line    6)
  * o in constraint:                       Simple Constraints. (line   23)
--- 71127,71140 ----
                                                               (line 1020)
  * nosave_low_regs function attribute, SH: SH Function Attributes.
                                                               (line   33)
+ * not_nested function attribute, NDS32:  NDS32 Function Attributes.
+                                                              (line   19)
  * note GCC_COLORS capability:            Diagnostic Message Formatting Options.
                                                               (line   97)
  * nothrow function attribute:            Common Function Attributes.
                                                               (line 1054)
  * notshared type attribute, ARM:         ARM Type Attributes.
                                                               (line    6)
  * Nvidia PTX options:                    Nvidia PTX Options. (line    6)
  * nvptx options:                         Nvidia PTX Options. (line    6)
  * o in constraint:                       Simple Constraints. (line   23)
*************** A.2 Concept and Symbol Index
*** 71198,71204 ****
  * other register constraints:            Simple Constraints. (line  161)
  * outline-atomics function attribute, AArch64: AArch64 Function Attributes.
                                                               (line   81)
! * output file option:                    Overall Options.    (line  192)
  * overloaded virtual function, warning:  C++ Dialect Options.
                                                               (line 1159)
  * p in constraint:                       Simple Constraints. (line  152)
--- 71207,71213 ----
  * other register constraints:            Simple Constraints. (line  161)
  * outline-atomics function attribute, AArch64: AArch64 Function Attributes.
                                                               (line   81)
! * output file option:                    Overall Options.    (line  196)
  * overloaded virtual function, warning:  C++ Dialect Options.
                                                               (line 1159)
  * p in constraint:                       Simple Constraints. (line  152)
*************** A.2 Concept and Symbol Index
*** 71259,71268 ****
  * pragma, diagnostic <3>:                Diagnostic Pragmas. (line  113)
  * pragma, fini:                          Solaris Pragmas.    (line   19)
  * pragma, init:                          Solaris Pragmas.    (line   25)
- * pragma, longcall:                      RS/6000 and PowerPC Pragmas.
-                                                              (line   13)
  * pragma, long_calls:                    ARM Pragmas.        (line   10)
  * pragma, long_calls_off:                ARM Pragmas.        (line   16)
  * pragma, mark:                          Darwin Pragmas.     (line   10)
  * pragma, memregs:                       M32C Pragmas.       (line    6)
  * pragma, no_long_calls:                 ARM Pragmas.        (line   13)
--- 71268,71277 ----
  * pragma, diagnostic <3>:                Diagnostic Pragmas. (line  113)
  * pragma, fini:                          Solaris Pragmas.    (line   19)
  * pragma, init:                          Solaris Pragmas.    (line   25)
  * pragma, long_calls:                    ARM Pragmas.        (line   10)
  * pragma, long_calls_off:                ARM Pragmas.        (line   16)
+ * pragma, longcall:                      RS/6000 and PowerPC Pragmas.
+                                                              (line   13)
  * pragma, mark:                          Darwin Pragmas.     (line   10)
  * pragma, memregs:                       M32C Pragmas.       (line    6)
  * pragma, no_long_calls:                 ARM Pragmas.        (line   13)
*************** A.2 Concept and Symbol Index
*** 71318,71327 ****
  * r fixed-suffix:                        Fixed-Point.        (line    6)
  * R fixed-suffix:                        Fixed-Point.        (line    6)
  * r in constraint:                       Simple Constraints. (line   64)
! * RAMPD:                                 AVR Options.        (line  428)
! * RAMPX:                                 AVR Options.        (line  428)
! * RAMPY:                                 AVR Options.        (line  428)
! * RAMPZ:                                 AVR Options.        (line  428)
  * range1 GCC_COLORS capability:          Diagnostic Message Formatting Options.
                                                               (line  106)
  * range2 GCC_COLORS capability:          Diagnostic Message Formatting Options.
--- 71327,71336 ----
  * r fixed-suffix:                        Fixed-Point.        (line    6)
  * R fixed-suffix:                        Fixed-Point.        (line    6)
  * r in constraint:                       Simple Constraints. (line   64)
! * RAMPD:                                 AVR Options.        (line  434)
! * RAMPX:                                 AVR Options.        (line  434)
! * RAMPY:                                 AVR Options.        (line  434)
! * RAMPZ:                                 AVR Options.        (line  434)
  * range1 GCC_COLORS capability:          Diagnostic Message Formatting Options.
                                                               (line  106)
  * range2 GCC_COLORS capability:          Diagnostic Message Formatting Options.
*************** A.2 Concept and Symbol Index
*** 71402,71415 ****
                                                               (line   55)
  * save all registers on the H8/300, H8/300H, and H8S: H8/300 Function Attributes.
                                                               (line   22)
- * saveall function attribute, Blackfin:  Blackfin Function Attributes.
-                                                              (line   55)
- * saveall function attribute, H8/300:    H8/300 Function Attributes.
-                                                              (line   22)
  * save_all function attribute, NDS32:    NDS32 Function Attributes.
                                                               (line   26)
  * save_volatiles function attribute, MicroBlaze: MicroBlaze Function Attributes.
                                                               (line    8)
  * scalar_storage_order type attribute:   Common Type Attributes.
                                                               (line  327)
  * scalb:                                 Other Builtins.     (line    6)
--- 71411,71424 ----
                                                               (line   55)
  * save all registers on the H8/300, H8/300H, and H8S: H8/300 Function Attributes.
                                                               (line   22)
  * save_all function attribute, NDS32:    NDS32 Function Attributes.
                                                               (line   26)
  * save_volatiles function attribute, MicroBlaze: MicroBlaze Function Attributes.
                                                               (line    8)
+ * saveall function attribute, Blackfin:  Blackfin Function Attributes.
+                                                              (line   55)
+ * saveall function attribute, H8/300:    H8/300 Function Attributes.
+                                                              (line   22)
  * scalar_storage_order type attribute:   Common Type Attributes.
                                                               (line  327)
  * scalb:                                 Other Builtins.     (line    6)
*************** A.2 Concept and Symbol Index
*** 71446,71455 ****
  * shared strings:                        Incompatibilities.  (line    9)
  * shared variable attribute:             Microsoft Windows Variable Attributes.
                                                               (line   36)
- * shortcall function attribute, Blackfin: Blackfin Function Attributes.
-                                                              (line   36)
- * shortcall function attribute, PowerPC: PowerPC Function Attributes.
-                                                              (line    8)
  * short_call function attribute, ARC:    ARC Function Attributes.
                                                               (line   23)
  * short_call function attribute, ARM:    ARM Function Attributes.
--- 71455,71460 ----
*************** A.2 Concept and Symbol Index
*** 71458,71463 ****
--- 71463,71472 ----
                                                               (line   55)
  * short_call function attribute, MIPS:   MIPS Function Attributes.
                                                               (line   59)
+ * shortcall function attribute, Blackfin: Blackfin Function Attributes.
+                                                              (line   36)
+ * shortcall function attribute, PowerPC: PowerPC Function Attributes.
+                                                              (line    8)
  * side effect in ?::                     Conditionals.       (line   20)
  * side effects, macro argument:          Statement Exprs.    (line   35)
  * side effects, order of evaluation:     Non-bugs.           (line  196)
*************** A.2 Concept and Symbol Index
*** 71498,71503 ****
--- 71507,71514 ----
  * Solaris 2 options:                     Solaris 2 Options.  (line    6)
  * SOURCE_DATE_EPOCH:                     Environment Variables.
                                                               (line  193)
+ * sp_switch function attribute, SH:      SH Function Attributes.
+                                                              (line   57)
  * SPARC options:                         SPARC Options.      (line    6)
  * Spec Files:                            Spec Files.         (line    6)
  * specified registers:                   Explicit Register Variables.
*************** A.2 Concept and Symbol Index
*** 71512,71519 ****
                                                               (line    6)
  * speed of compilation <1>:              C++ Modules.        (line    6)
  * sprintf:                               Other Builtins.     (line    6)
- * sp_switch function attribute, SH:      SH Function Attributes.
-                                                              (line   57)
  * sqrt:                                  Other Builtins.     (line    6)
  * sqrtf:                                 Other Builtins.     (line    6)
  * sqrtl:                                 Other Builtins.     (line    6)
--- 71523,71528 ----
*************** A.2 Concept and Symbol Index
*** 71541,71550 ****
  * strdup:                                Other Builtins.     (line    6)
  * strfmon:                               Other Builtins.     (line    6)
  * strftime:                              Other Builtins.     (line    6)
- * strict-align function attribute, AArch64: AArch64 Function Attributes.
-                                                              (line   31)
  * strict_flex_array variable attribute:  Common Variable Attributes.
                                                               (line  135)
  * string constants:                      Incompatibilities.  (line    9)
  * strlen:                                Other Builtins.     (line    6)
  * strncasecmp:                           Other Builtins.     (line    6)
--- 71550,71559 ----
  * strdup:                                Other Builtins.     (line    6)
  * strfmon:                               Other Builtins.     (line    6)
  * strftime:                              Other Builtins.     (line    6)
  * strict_flex_array variable attribute:  Common Variable Attributes.
                                                               (line  135)
+ * strict-align function attribute, AArch64: AArch64 Function Attributes.
+                                                              (line   31)
  * string constants:                      Incompatibilities.  (line    9)
  * strlen:                                Other Builtins.     (line    6)
  * strncasecmp:                           Other Builtins.     (line    6)
*************** A.2 Concept and Symbol Index
*** 71600,71605 ****
--- 71609,71617 ----
  * target function attribute <5>:         x86 Function Attributes.
                                                               (line  179)
  * target machine, specifying:            Invoking GCC.       (line   24)
+ * target_clones function attribute:      Common Function Attributes.
+                                                              (line 1346)
+ * target-dependent options:              Submodel Options.   (line    6)
  * target("3dnow") function attribute, x86: x86 Function Attributes.
                                                               (line  184)
  * target("3dnowa") function attribute, x86: x86 Function Attributes.
*************** A.2 Concept and Symbol Index
*** 71804,71813 ****
                                                               (line  407)
  * target("rdseed") function attribute, x86: x86 Function Attributes.
                                                               (line  411)
- * target("recip") function attribute, x86: x86 Function Attributes.
-                                                              (line  601)
  * target("recip-precision") function attribute, PowerPC: PowerPC Function Attributes.
                                                               (line  111)
  * target("rtm") function attribute, x86: x86 Function Attributes.
                                                               (line  415)
  * target("sahf") function attribute, x86: x86 Function Attributes.
--- 71816,71825 ----
                                                               (line  407)
  * target("rdseed") function attribute, x86: x86 Function Attributes.
                                                               (line  411)
  * target("recip-precision") function attribute, PowerPC: PowerPC Function Attributes.
                                                               (line  111)
+ * target("recip") function attribute, x86: x86 Function Attributes.
+                                                              (line  601)
  * target("rtm") function attribute, x86: x86 Function Attributes.
                                                               (line  415)
  * target("sahf") function attribute, x86: x86 Function Attributes.
*************** A.2 Concept and Symbol Index
*** 71824,71835 ****
                                                               (line  439)
  * target("sse3") function attribute, x86: x86 Function Attributes.
                                                               (line  443)
- * target("sse4") function attribute, x86: x86 Function Attributes.
-                                                              (line  447)
  * target("sse4.1") function attribute, x86: x86 Function Attributes.
                                                               (line  452)
  * target("sse4.2") function attribute, x86: x86 Function Attributes.
                                                               (line  456)
  * target("sse4a") function attribute, x86: x86 Function Attributes.
                                                               (line  460)
  * target("ssse3") function attribute, x86: x86 Function Attributes.
--- 71836,71847 ----
                                                               (line  439)
  * target("sse3") function attribute, x86: x86 Function Attributes.
                                                               (line  443)
  * target("sse4.1") function attribute, x86: x86 Function Attributes.
                                                               (line  452)
  * target("sse4.2") function attribute, x86: x86 Function Attributes.
                                                               (line  456)
+ * target("sse4") function attribute, x86: x86 Function Attributes.
+                                                              (line  447)
  * target("sse4a") function attribute, x86: x86 Function Attributes.
                                                               (line  460)
  * target("ssse3") function attribute, x86: x86 Function Attributes.
*************** A.2 Concept and Symbol Index
*** 71870,71878 ****
                                                               (line  500)
  * target("xsaves") function attribute, x86: x86 Function Attributes.
                                                               (line  504)
- * target-dependent options:              Submodel Options.   (line    6)
- * target_clones function attribute:      Common Function Attributes.
-                                                              (line 1346)
  * targs GCC_COLORS capability:           Diagnostic Message Formatting Options.
                                                               (line  122)
  * TC1:                                   Standards.          (line   13)
--- 71882,71887 ----
*************** A.2 Concept and Symbol Index
*** 71902,71911 ****
  * tiny_data variable attribute, H8/300:  H8/300 Variable Attributes.
                                                               (line   18)
  * TLS:                                   Thread-Local.       (line    6)
- * tls-dialect= function attribute, AArch64: AArch64 Function Attributes.
-                                                              (line   47)
  * tls_model variable attribute:          Common Variable Attributes.
                                                               (line  377)
  * TMPDIR:                                Environment Variables.
                                                               (line   44)
  * toascii:                               Other Builtins.     (line    6)
--- 71911,71920 ----
  * tiny_data variable attribute, H8/300:  H8/300 Variable Attributes.
                                                               (line   18)
  * TLS:                                   Thread-Local.       (line    6)
  * tls_model variable attribute:          Common Variable Attributes.
                                                               (line  377)
+ * tls-dialect= function attribute, AArch64: AArch64 Function Attributes.
+                                                              (line   47)
  * TMPDIR:                                Environment Variables.
                                                               (line   44)
  * toascii:                               Other Builtins.     (line    6)
*************** A.2 Concept and Symbol Index
*** 71917,71926 ****
                                                               (line  375)
  * transparent_union type attribute:      Common Type Attributes.
                                                               (line  371)
- * trapa_handler function attribute, SH:  SH Function Attributes.
-                                                              (line   72)
  * trap_exit function attribute, SH:      SH Function Attributes.
                                                               (line   67)
  * trunc:                                 Other Builtins.     (line    6)
  * truncf:                                Other Builtins.     (line    6)
  * truncl:                                Other Builtins.     (line    6)
--- 71926,71935 ----
                                                               (line  375)
  * transparent_union type attribute:      Common Type Attributes.
                                                               (line  371)
  * trap_exit function attribute, SH:      SH Function Attributes.
                                                               (line   67)
+ * trapa_handler function attribute, SH:  SH Function Attributes.
+                                                              (line   72)
  * trunc:                                 Other Builtins.     (line    6)
  * truncf:                                Other Builtins.     (line    6)
  * truncl:                                Other Builtins.     (line    6)
*************** A.2 Concept and Symbol Index
*** 71929,71939 ****
  * two-stage name lookup:                 Name lookup.        (line    6)
  * type alignment:                        Alignment.          (line    6)
  * type attributes:                       Type Attributes.    (line    6)
  * type-diff GCC_COLORS capability:       Diagnostic Message Formatting Options.
                                                               (line  145)
  * typedef names as function parameters:  Incompatibilities.  (line   97)
  * typeof:                                Typeof.             (line    6)
- * type_info:                             Vague Linkage.      (line   41)
  * uhk fixed-suffix:                      Fixed-Point.        (line    6)
  * UHK fixed-suffix:                      Fixed-Point.        (line    6)
  * uhr fixed-suffix:                      Fixed-Point.        (line    6)
--- 71938,71948 ----
  * two-stage name lookup:                 Name lookup.        (line    6)
  * type alignment:                        Alignment.          (line    6)
  * type attributes:                       Type Attributes.    (line    6)
+ * type_info:                             Vague Linkage.      (line   41)
  * type-diff GCC_COLORS capability:       Diagnostic Message Formatting Options.
                                                               (line  145)
  * 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)
*************** A.2 Concept and Symbol Index
*** 71985,72002 ****
  * UR fixed-suffix:                       Fixed-Point.        (line    6)
  * urls:                                  Diagnostic Message Formatting Options.
                                                               (line  149)
- * used function attribute:               Common Function Attributes.
-                                                              (line 1378)
- * used variable attribute:               Common Variable Attributes.
-                                                              (line  391)
- * User stack pointer in interrupts on the Blackfin: Blackfin Function Attributes.
-                                                              (line   20)
  * use_debug_exception_return function attribute, MIPS: MIPS Function Attributes.
                                                               (line   38)
  * use_hazard_barrier_return function attribute, MIPS: MIPS Function Attributes.
                                                               (line  113)
  * use_shadow_register_set function attribute, MIPS: MIPS Function Attributes.
                                                               (line   27)
  * V in constraint:                       Simple Constraints. (line   43)
  * V850 Options:                          V850 Options.       (line    6)
  * vague linkage:                         Vague Linkage.      (line    6)
--- 71994,72011 ----
  * UR fixed-suffix:                       Fixed-Point.        (line    6)
  * urls:                                  Diagnostic Message Formatting Options.
                                                               (line  149)
  * use_debug_exception_return function attribute, MIPS: MIPS Function Attributes.
                                                               (line   38)
  * use_hazard_barrier_return function attribute, MIPS: MIPS Function Attributes.
                                                               (line  113)
  * use_shadow_register_set function attribute, MIPS: MIPS Function Attributes.
                                                               (line   27)
+ * used function attribute:               Common Function Attributes.
+                                                              (line 1378)
+ * used variable attribute:               Common Variable Attributes.
+                                                              (line  391)
+ * User stack pointer in interrupts on the Blackfin: Blackfin Function Attributes.
+                                                              (line   20)
  * V in constraint:                       Simple Constraints. (line   43)
  * V850 Options:                          V850 Options.       (line    6)
  * vague linkage:                         Vague Linkage.      (line    6)
*************** A.2 Concept and Symbol Index
*** 72018,72031 ****
                                                               (line    6)
  * variadic macros:                       Variadic Macros.    (line    6)
  * VAX options:                           VAX Options.        (line    6)
- * vector function attribute, RX:         RX Function Attributes.
-                                                              (line   48)
- * vector types, using with x86 intrinsics: Vector Extensions.
-                                                              (line  212)
- * vector_size type attribute:            Common Type Attributes.
-                                                              (line  433)
- * vector_size variable attribute:        Common Variable Attributes.
-                                                              (line  426)
  * vec_blendv:                            PowerPC AltiVec Built-in Functions Available on ISA 3.1.
                                                               (line  308)
  * vec_cfuge:                             PowerPC AltiVec Built-in Functions Available on ISA 3.1.
--- 72027,72032 ----
*************** A.2 Concept and Symbol Index
*** 72064,72073 ****
                                                               (line  235)
  * vec_splati:                            PowerPC AltiVec Built-in Functions Available on ISA 3.1.
                                                               (line  265)
- * vec_splatid:                           PowerPC AltiVec Built-in Functions Available on ISA 3.1.
-                                                              (line  270)
  * vec_splati_ins:                        PowerPC AltiVec Built-in Functions Available on ISA 3.1.
                                                               (line  281)
  * vec_srdb:                              PowerPC AltiVec Built-in Functions Available on ISA 3.1.
                                                               (line  258)
  * vec_stril:                             PowerPC AltiVec Built-in Functions Available on ISA 3.1.
--- 72065,72074 ----
                                                               (line  235)
  * vec_splati:                            PowerPC AltiVec Built-in Functions Available on ISA 3.1.
                                                               (line  265)
  * vec_splati_ins:                        PowerPC AltiVec Built-in Functions Available on ISA 3.1.
                                                               (line  281)
+ * vec_splatid:                           PowerPC AltiVec Built-in Functions Available on ISA 3.1.
+                                                              (line  270)
  * vec_srdb:                              PowerPC AltiVec Built-in Functions Available on ISA 3.1.
                                                               (line  258)
  * vec_stril:                             PowerPC AltiVec Built-in Functions Available on ISA 3.1.
*************** A.2 Concept and Symbol Index
*** 72096,72101 ****
--- 72097,72110 ----
                                                               (line   73)
  * vec_xst_trunc <7>:                     Basic PowerPC Built-in Functions Available on ISA 3.1.
                                                               (line   75)
+ * vector function attribute, RX:         RX Function Attributes.
+                                                              (line   48)
+ * vector types, using with x86 intrinsics: Vector Extensions.
+                                                              (line  212)
+ * vector_size type attribute:            Common Type Attributes.
+                                                              (line  433)
+ * vector_size variable attribute:        Common Variable Attributes.
+                                                              (line  426)
  * version_id function attribute, IA-64:  IA-64 Function Attributes.
                                                               (line   15)
  * vfprintf:                              Other Builtins.     (line    6)
*************** A.2 Concept and Symbol Index
*** 72148,72153 ****
--- 72157,72169 ----
                                                               (line   48)
  * warm function attribute, NDS32:        NDS32 Function Attributes.
                                                               (line   50)
+ * warn_if_not_aligned type attribute:    Common Type Attributes.
+                                                              (line   91)
+ * warn_if_not_aligned variable attribute: Common Variable Attributes.
+                                                              (line  106)
+ * warn_unused type attribute:            C++ Attributes.     (line   70)
+ * warn_unused_result function attribute: Common Function Attributes.
+                                                              (line 1499)
  * warning for comparison of signed and unsigned values: Warning Options.
                                                               (line 2802)
  * warning for overloaded virtual function: C++ Dialect Options.
*************** A.2 Concept and Symbol Index
*** 72163,72175 ****
  * warnings from system headers:          Warning Options.    (line 2112)
  * warnings vs errors:                    Warnings and Errors.
                                                               (line    6)
- * warn_if_not_aligned type attribute:    Common Type Attributes.
-                                                              (line   91)
- * warn_if_not_aligned variable attribute: Common Variable Attributes.
-                                                              (line  106)
- * warn_unused type attribute:            C++ Attributes.     (line   70)
- * warn_unused_result function attribute: Common Function Attributes.
-                                                              (line 1499)
  * weak function attribute:               Common Function Attributes.
                                                               (line 1516)
  * weak variable attribute:               Common Variable Attributes.
--- 72179,72184 ----
*************** A.2 Concept and Symbol Index
*** 72199,72642 ****
  * ynl:                                   Other Builtins.     (line    6)
  * zda variable attribute, V850:          V850 Variable Attributes.
                                                               (line   16)
- * zero-length arrays:                    Zero Length.        (line    6)
- * zero-size structures:                  Empty Structures.   (line    6)
  * zero_call_used_regs function attribute: Common Function Attributes.
                                                               (line 1570)
  * zSeries options:                       zSeries Options.    (line    6)
  
  
  
  Tag Table:
! Node: Top2226
! Node: G++ and GCC4141
! Node: Standards6187
! Node: Invoking GCC19813
! Node: Option Summary25040
! Node: Overall Options84993
! Node: Invoking G++113150
! Node: C Dialect Options114673
! Node: C++ Dialect Options137937
! Node: Objective-C and Objective-C++ Dialect Options207740
! Node: Diagnostic Message Formatting Options219645
! Node: Warning Options251486
! Ref: Wtrigraphs359709
! Node: Static Analyzer Options407474
! Node: Debugging Options447396
! Node: Optimize Options467342
! Ref: Type-punning539895
! Node: Instrumentation Options662783
! Node: Preprocessor Options714798
! Ref: dashMF719645
! Ref: fdollars-in-identifiers724307
! Node: Assembler Options737657
! Node: Link Options738348
! Ref: Link Options-Footnote-1755380
! Node: Directory Options755894
! Node: Code Gen Options764297
! Node: Developer Options793170
! Node: Submodel Options838685
! Node: AArch64 Options840405
! Ref: aarch64-feature-modifiers856226
! Node: Adapteva Epiphany Options861898
! Node: AMD GCN Options867850
! Node: ARC Options869579
! Node: ARM Options890583
! Node: AVR Options935346
! Node: Blackfin Options964060
! Node: C6X Options971952
! Node: CRIS Options973495
! Node: C-SKY Options976682
! Node: Darwin Options982409
! Node: DEC Alpha Options990189
! Node: eBPF Options1001805
! Node: FR30 Options1004181
! Node: FT32 Options1004741
! Node: FRV Options1005687
! Node: GNU/Linux Options1012451
! Node: H8/300 Options1013832
! Node: HPPA Options1015284
! Node: IA-64 Options1025929
! Node: LM32 Options1034057
! Node: LoongArch Options1034585
! Node: M32C Options1042231
! Node: M32R/D Options1043509
! Node: M680x0 Options1047054
! Node: MCore Options1061209
! Node: MicroBlaze Options1062718
! Node: MIPS Options1065785
! Node: MMIX Options1102761
! Node: MN10300 Options1105238
! Node: Moxie Options1107781
! Node: MSP430 Options1108268
! Node: NDS32 Options1116029
! Node: Nios II Options1118199
! Node: Nvidia PTX Options1131415
! Node: OpenRISC Options1134949
! Node: PDP-11 Options1137703
! Node: PowerPC Options1138951
! Node: PRU Options1139169
! Node: RISC-V Options1141378
! Node: RL78 Options1150115
! Node: RS/6000 and PowerPC Options1153890
! Node: RX Options1195733
! Node: S/390 and zSeries Options1204335
! Node: SH Options1215132
! Node: Solaris 2 Options1230284
! Node: SPARC Options1231522
! Node: System V Options1247174
! Node: V850 Options1247999
! Node: VAX Options1254687
! Node: Visium Options1255379
! Node: VMS Options1257687
! Node: VxWorks Options1258503
! Node: x86 Options1259655
! Node: x86 Windows Options1334619
! Node: Xstormy16 Options1337425
! Node: Xtensa Options1337719
! Node: zSeries Options1344211
! Node: Spec Files1344407
! Node: Environment Variables1370486
! Node: Precompiled Headers1379919
! Node: C++ Modules1386128
! Ref: C++ Modules-Footnote-11391791
! Node: C++ Module Mapper1392044
! Node: C++ Module Preprocessing1397197
! Node: C++ Compiled Module Interface1399026
! Ref: C++ Compiled Module Interface-Footnote-11402410
! Ref: C++ Compiled Module Interface-Footnote-21402499
! Node: C Implementation1402555
! Node: Translation implementation1404246
! Node: Environment implementation1404837
! Node: Identifiers implementation1405391
! Node: Characters implementation1406477
! Node: Integers implementation1410127
! Node: Floating point implementation1412176
! Node: Arrays and pointers implementation1415276
! Ref: Arrays and pointers implementation-Footnote-11416736
! Node: Hints implementation1416862
! Node: Structures unions enumerations and bit-fields implementation1418357
! Node: Qualifiers implementation1420581
! Node: Declarators implementation1422642
! Node: Statements implementation1422983
! Node: Preprocessing directives implementation1423309
! Node: Library functions implementation1425630
! Node: Architecture implementation1426279
! Node: Locale-specific behavior implementation1427924
! Node: C++ Implementation1428229
! Node: Conditionally-supported behavior1429513
! Node: Exception handling1430130
! Node: C Extensions1430538
! Node: Statement Exprs1435761
! Node: Local Labels1441133
! Node: Labels as Values1444106
! Ref: Labels as Values-Footnote-11446633
! Node: Nested Functions1446818
! Node: Nonlocal Gotos1450772
! Node: Constructing Calls1453038
! Node: Typeof1457750
! Node: Conditionals1461679
! Node: __int1281462568
! Node: Long Long1463093
! Node: Complex1464584
! Node: Floating Types1469329
! Node: Half-Precision1472800
! Node: Decimal Float1476268
! Node: Hex Floats1478122
! Node: Fixed-Point1479196
! Node: Named Address Spaces1482454
! Ref: AVR Named Address Spaces1483140
! Node: Zero Length1490439
! Node: Empty Structures1494620
! Node: Variable Length1495026
! Node: Variadic Macros1497744
! Node: Escaped Newlines1500122
! Node: Subscripting1500983
! Node: Pointer Arith1501708
! Node: Variadic Pointer Args1502285
! Node: Pointers to Arrays1503010
! Node: Initializers1503763
! Node: Compound Literals1504264
! Node: Designated Inits1507831
! Node: Case Ranges1511755
! Node: Cast to Union1512436
! Node: Mixed Labels and Declarations1514170
! Node: Function Attributes1514807
! Node: Common Function Attributes1519261
! Ref: Common Function Attributes-Footnote-11597773
! Node: AArch64 Function Attributes1598090
! Node: AMD GCN Function Attributes1604284
! Node: ARC Function Attributes1607337
! Node: ARM Function Attributes1610274
! Node: AVR Function Attributes1615413
! Node: Blackfin Function Attributes1619948
! Node: BPF Function Attributes1622445
! Node: C-SKY Function Attributes1623034
! Node: Epiphany Function Attributes1624330
! Node: H8/300 Function Attributes1627085
! Node: IA-64 Function Attributes1628283
! Node: M32C Function Attributes1629325
! Node: M32R/D Function Attributes1631663
! Node: m68k Function Attributes1633137
! Node: MCORE Function Attributes1634081
! Node: MicroBlaze Function Attributes1634899
! Node: Microsoft Windows Function Attributes1636408
! Node: MIPS Function Attributes1640977
! Node: MSP430 Function Attributes1646840
! Node: NDS32 Function Attributes1650919
! Node: Nios II Function Attributes1653343
! Node: Nvidia PTX Function Attributes1654640
! Node: PowerPC Function Attributes1655255
! Node: RISC-V Function Attributes1662029
! Node: RL78 Function Attributes1663445
! Node: RX Function Attributes1664684
! Node: S/390 Function Attributes1667231
! Node: SH Function Attributes1669059
! Node: Symbian OS Function Attributes1672487
! Node: V850 Function Attributes1672823
! Node: Visium Function Attributes1673368
! Node: x86 Function Attributes1673896
! Node: Xstormy16 Function Attributes1698736
! Node: Variable Attributes1699243
! Node: Common Variable Attributes1700782
! Node: ARC Variable Attributes1724076
! Node: AVR Variable Attributes1724458
! Node: Blackfin Variable Attributes1729577
! Node: H8/300 Variable Attributes1730435
! Node: IA-64 Variable Attributes1731508
! Node: LoongArch Variable Attributes1732262
! Node: M32R/D Variable Attributes1732938
! Node: Microsoft Windows Variable Attributes1733739
! Node: MSP430 Variable Attributes1736195
! Node: Nvidia PTX Variable Attributes1737409
! Node: PowerPC Variable Attributes1738026
! Node: RL78 Variable Attributes1738583
! Node: V850 Variable Attributes1739002
! Node: x86 Variable Attributes1739635
! Node: Xstormy16 Variable Attributes1740691
! Node: Type Attributes1741261
! Node: Common Type Attributes1742925
! Node: ARC Type Attributes1765286
! Node: ARM Type Attributes1765758
! Node: BPF Type Attributes1766540
! Node: PowerPC Type Attributes1767061
! Node: x86 Type Attributes1768050
! Node: Label Attributes1769042
! Node: Enumerator Attributes1771069
! Node: Statement Attributes1772601
! Node: Attribute Syntax1774901
! Node: Function Prototypes1786158
! Node: C++ Comments1787938
! Node: Dollar Signs1788457
! Node: Character Escapes1788922
! Node: Alignment1789206
! Node: Inline1790859
! Node: Volatiles1795676
! Node: Using Assembly Language with C1798575
! Node: Basic Asm1799812
! Node: Extended Asm1805435
! Ref: Volatile1809549
! Ref: AssemblerTemplate1813662
! Ref: OutputOperands1817902
! Ref: FlagOutputOperands1824982
! Ref: InputOperands1827929
! Ref: Clobbers and Scratch Registers1832314
! Ref: GotoLabels1840955
! Ref: GenericOperandmodifiers1844578
! Ref: x86Operandmodifiers1845536
! Ref: x86floatingpointasmoperands1850352
! Ref: msp430Operandmodifiers1853683
! Ref: loongarchOperandmodifiers1855341
! Node: Constraints1855875
! Node: Simple Constraints1856981
! Node: Multi-Alternative1864295
! Node: Modifiers1865970
! Node: Machine Constraints1868769
! Node: Asm Labels1922570
! Node: Explicit Register Variables1924186
! Ref: Explicit Reg Vars1924400
! Node: Global Register Variables1925009
! Ref: Global Reg Vars1925217
! Node: Local Register Variables1929999
! Ref: Local Reg Vars1930219
! Node: Size of an asm1933847
! Node: Alternate Keywords1935325
! Node: Incomplete Enums1936830
! Node: Function Names1937587
! Node: Return Address1939491
! Node: Vector Extensions1944078
! Node: Offsetof1955061
! Node: __sync Builtins1955894
! Node: __atomic Builtins1962823
! Node: Integer Overflow Builtins1976336
! Node: x86 specific memory model extensions for transactional memory1982819
! Node: Object Size Checking1984085
! Node: Other Builtins1991594
! Node: Target Builtins2045152
! Node: AArch64 Built-in Functions2046900
! Node: Alpha Built-in Functions2047596
! Node: Altera Nios II Built-in Functions2050690
! Node: ARC Built-in Functions2055129
! Node: ARC SIMD Built-in Functions2060341
! Node: ARM iWMMXt Built-in Functions2069339
! Node: ARM C Language Extensions (ACLE)2076475
! Node: ARM Floating Point Status and Control Intrinsics2077752
! Node: ARM ARMv8-M Security Extensions2078239
! Node: AVR Built-in Functions2079531
! Node: Blackfin Built-in Functions2083297
! Node: BPF Built-in Functions2083917
! Node: FR-V Built-in Functions2088459
! Node: Argument Types2089328
! Node: Directly-mapped Integer Functions2091159
! Node: Directly-mapped Media Functions2092319
! Node: Raw read/write Functions2100601
! Node: Other Built-in Functions2101509
! Node: LoongArch Base Built-in Functions2102695
! Node: MIPS DSP Built-in Functions2108441
! Node: MIPS Paired-Single Support2121206
! Node: MIPS Loongson Built-in Functions2122705
! Node: Paired-Single Arithmetic2129227
! Node: Paired-Single Built-in Functions2130250
! Node: MIPS-3D Built-in Functions2132917
! Node: MIPS SIMD Architecture (MSA) Support2138311
! Node: MIPS SIMD Architecture Built-in Functions2141151
! Node: Other MIPS Built-in Functions2168005
! Node: MSP430 Built-in Functions2169014
! Node: NDS32 Built-in Functions2170415
! Node: Basic PowerPC Built-in Functions2171713
! Node: Basic PowerPC Built-in Functions Available on all Configurations2172568
! Node: Basic PowerPC Built-in Functions Available on ISA 2.052181078
! Node: Basic PowerPC Built-in Functions Available on ISA 2.062185913
! Node: Basic PowerPC Built-in Functions Available on ISA 2.072187993
! Node: Basic PowerPC Built-in Functions Available on ISA 3.02188847
! Node: Basic PowerPC Built-in Functions Available on ISA 3.12196122
! Node: PowerPC AltiVec/VSX Built-in Functions2200039
! Node: PowerPC AltiVec Built-in Functions on ISA 2.052208108
! Node: PowerPC AltiVec Built-in Functions Available on ISA 2.062233508
! Node: PowerPC AltiVec Built-in Functions Available on ISA 2.072240574
! Node: PowerPC AltiVec Built-in Functions Available on ISA 3.02250384
! Node: PowerPC AltiVec Built-in Functions Available on ISA 3.12266107
! Node: PowerPC Hardware Transactional Memory Built-in Functions2299391
! Node: PowerPC Atomic Memory Operation Functions2307941
! Node: PowerPC Matrix-Multiply Assist Built-in Functions2310504
! Node: PRU Built-in Functions2316629
! Node: RISC-V Built-in Functions2317909
! Node: RISC-V Vector Intrinsics2318567
! Node: RX Built-in Functions2319062
! Node: S/390 System z Built-in Functions2323063
! Node: SH Built-in Functions2328332
! Node: SPARC VIS Built-in Functions2330060
! Node: TI C6X Built-in Functions2338591
! Node: x86 Built-in Functions2339638
! Node: x86 transactional memory intrinsics2406108
! Node: x86 control-flow protection intrinsics2409434
! Node: Target Format Checks2411205
! Node: Solaris Format Checks2411637
! Node: Darwin Format Checks2412063
! Node: Pragmas2413026
! Node: AArch64 Pragmas2413951
! Node: ARM Pragmas2414408
! Node: M32C Pragmas2415035
! Node: PRU Pragmas2416107
! Node: RS/6000 and PowerPC Pragmas2416686
! Node: S/390 Pragmas2417426
! Node: Darwin Pragmas2417992
! Node: Solaris Pragmas2419045
! Node: Symbol-Renaming Pragmas2420209
! Node: Structure-Layout Pragmas2421844
! Node: Weak Pragmas2424124
! Node: Diagnostic Pragmas2424859
! Node: Visibility Pragmas2429610
! Node: Push/Pop Macro Pragmas2430295
! Node: Function Specific Option Pragmas2431268
! Node: Loop-Specific Pragmas2433234
! Node: Unnamed Fields2434834
! Node: Thread-Local2437031
! Node: C99 Thread-Local Edits2439137
! Node: C++98 Thread-Local Edits2441135
! Node: Binary constants2444580
! Node: C++ Extensions2445251
! Node: C++ Volatiles2446881
! Node: Restricted Pointers2449229
! Node: Vague Linkage2450820
! Node: C++ Interface2454443
! Ref: C++ Interface-Footnote-12458240
! Node: Template Instantiation2458378
! Node: Bound member functions2464469
! Node: C++ Attributes2466001
! Node: Function Multiversioning2470073
! Node: Type Traits2471881
! Node: C++ Concepts2479603
! Node: Deprecated Features2481146
! Node: Backwards Compatibility2482971
! Node: Objective-C2484043
! Node: GNU Objective-C runtime API2484650
! Node: Modern GNU Objective-C runtime API2485657
! Node: Traditional GNU Objective-C runtime API2488093
! Node: Executing code before main2488820
! Node: What you can and what you cannot do in +load2491564
! Node: Type encoding2493934
! Node: Legacy type encoding2499300
! Node: @encode2500390
! Node: Method signatures2500935
! Node: Garbage Collection2502927
! Node: Constant string objects2505617
! Node: compatibility_alias2508126
! Node: Exceptions2508851
! Node: Synchronization2511561
! Node: Fast enumeration2512745
! Node: Using fast enumeration2513057
! Node: c99-like fast enumeration syntax2514268
! Node: Fast enumeration details2514971
! Node: Fast enumeration protocol2517311
! Node: Messaging with the GNU Objective-C runtime2520463
! Node: Dynamically registering methods2521835
! Node: Forwarding hook2523526
! Node: Compatibility2526566
! Node: Gcov2533122
! Node: Gcov Intro2533790
! Node: Invoking Gcov2536508
! Node: Gcov and Optimization2559241
! Node: Gcov Data Files2562994
! Node: Cross-profiling2564403
! Node: Freestanding Environments2566291
! Node: Gcov-tool2581154
! Node: Gcov-tool Intro2581579
! Node: Invoking Gcov-tool2583933
! Node: Gcov-dump2587346
! Node: Gcov-dump Intro2587669
! Node: Invoking Gcov-dump2587936
! Node: lto-dump2588669
! Node: lto-dump Intro2588968
! Node: Invoking lto-dump2589218
! Node: Trouble2590314
! Node: Actual Bugs2591731
! Node: Interoperation2592178
! Node: Incompatibilities2599069
! Node: Fixed Headers2607221
! Node: Standard Libraries2608879
! Node: Disappointments2610251
! Node: C++ Misunderstandings2614610
! Node: Static Definitions2615421
! Node: Name lookup2616474
! Ref: Name lookup-Footnote-12621255
! Node: Temporaries2621444
! Node: Copy Assignment2623420
! Node: Non-bugs2625255
! Node: Warnings and Errors2635761
! Node: Bugs2637523
! Node: Bug Criteria2637990
! Node: Bug Reporting2640200
! Node: Service2640418
! Node: Contributing2641239
! Node: Funding2641985
! Node: GNU Project2644475
! Node: Copying2645123
! Node: GNU Free Documentation License2682637
! Node: Contributors2707760
! Node: Indices2748835
! Node: Option Index2749081
! Node: Concept and Symbol Index3055865
  
  End Tag Table
  
--- 72208,72651 ----
  * ynl:                                   Other Builtins.     (line    6)
  * zda variable attribute, V850:          V850 Variable Attributes.
                                                               (line   16)
  * zero_call_used_regs function attribute: Common Function Attributes.
                                                               (line 1570)
+ * zero-length arrays:                    Zero Length.        (line    6)
+ * zero-size structures:                  Empty Structures.   (line    6)
  * zSeries options:                       zSeries Options.    (line    6)
  
  
  
  Tag Table:
! Node: Top2240
! Node: G++ and GCC4175
! Node: Standards6233
! Node: Invoking GCC20261
! Node: Option Summary25592
! Node: Overall Options85545
! Node: Invoking G++114984
! Node: C Dialect Options116595
! Node: C++ Dialect Options141039
! Node: Objective-C and Objective-C++ Dialect Options212610
! Node: Diagnostic Message Formatting Options224823
! Node: Warning Options257438
! Ref: Wtrigraphs369367
! Node: Static Analyzer Options418684
! Node: Debugging Options460222
! Node: Optimize Options480740
! Ref: Type-punning555955
! Node: Instrumentation Options682101
! Node: Preprocessor Options735696
! Ref: dashMF740723
! Ref: fdollars-in-identifiers745653
! Node: Assembler Options759423
! Node: Link Options760126
! Ref: Link Options-Footnote-1777866
! Node: Directory Options778404
! Node: Code Gen Options787247
! Node: Developer Options816846
! Node: Submodel Options864007
! Node: AArch64 Options865731
! Ref: aarch64-feature-modifiers882548
! Node: Adapteva Epiphany Options888488
! Node: AMD GCN Options894634
! Node: ARC Options896419
! Node: ARM Options918627
! Node: AVR Options965746
! Node: Blackfin Options997674
! Node: C6X Options1005942
! Node: CRIS Options1007585
! Node: C-SKY Options1010932
! Node: Darwin Options1017223
! Node: DEC Alpha Options1025575
! Node: eBPF Options1037631
! Node: FR30 Options1040197
! Node: FT32 Options1040769
! Node: FRV Options1041739
! Node: GNU/Linux Options1048847
! Node: H8/300 Options1050332
! Node: HPPA Options1051860
! Node: IA-64 Options1062957
! Node: LM32 Options1071417
! Node: LoongArch Options1071969
! Node: M32C Options1080007
! Node: M32R/D Options1081313
! Node: M680x0 Options1085018
! Node: MCore Options1100233
! Node: MicroBlaze Options1101834
! Node: MIPS Options1105065
! Node: MMIX Options1144127
! Node: MN10300 Options1146716
! Node: Moxie Options1149375
! Node: MSP430 Options1149886
! Node: NDS32 Options1157955
! Node: Nios II Options1160225
! Node: Nvidia PTX Options1174057
! Node: OpenRISC Options1177771
! Node: PDP-11 Options1180677
! Node: PowerPC Options1181997
! Node: PRU Options1182215
! Node: RISC-V Options1184480
! Node: RL78 Options1193643
! Node: RS/6000 and PowerPC Options1197590
! Node: RX Options1241617
! Node: S/390 and zSeries Options1250575
! Node: SH Options1261892
! Node: Solaris 2 Options1277636
! Node: SPARC Options1278926
! Node: System V Options1295364
! Node: V850 Options1296229
! Node: VAX Options1303265
! Node: Visium Options1303985
! Node: VMS Options1306373
! Node: VxWorks Options1307237
! Node: x86 Options1308433
! Node: x86 Windows Options1386101
! Node: Xstormy16 Options1388963
! Node: Xtensa Options1389261
! Node: zSeries Options1395997
! Node: Spec Files1396193
! Node: Environment Variables1423564
! Node: Precompiled Headers1433385
! Node: C++ Modules1439718
! Ref: C++ Modules-Footnote-11445453
! Node: C++ Module Mapper1445714
! Node: C++ Module Preprocessing1450967
! Node: C++ Compiled Module Interface1452840
! Ref: C++ Compiled Module Interface-Footnote-11456268
! Ref: C++ Compiled Module Interface-Footnote-21456357
! Node: C Implementation1456413
! Node: Translation implementation1458104
! Node: Environment implementation1458707
! Node: Identifiers implementation1459267
! Node: Characters implementation1460371
! Node: Integers implementation1464155
! Node: Floating point implementation1466256
! Node: Arrays and pointers implementation1469488
! Ref: Arrays and pointers implementation-Footnote-11470960
! Node: Hints implementation1471090
! Node: Structures unions enumerations and bit-fields implementation1472643
! Node: Qualifiers implementation1474991
! Node: Declarators implementation1477074
! Node: Statements implementation1477421
! Node: Preprocessing directives implementation1477761
! Node: Library functions implementation1480192
! Node: Architecture implementation1480867
! Node: Locale-specific behavior implementation1482568
! Node: C++ Implementation1482873
! Node: Conditionally-supported behavior1484157
! Node: Exception handling1484784
! Node: C Extensions1485198
! Node: Statement Exprs1490473
! Node: Local Labels1495997
! Node: Labels as Values1498986
! Ref: Labels as Values-Footnote-11501553
! Node: Nested Functions1501738
! Node: Nonlocal Gotos1505764
! Node: Constructing Calls1508090
! Node: Typeof1512830
! Node: Conditionals1516893
! Node: __int1281517790
! Node: Long Long1518335
! Node: Complex1519870
! Node: Floating Types1524839
! Node: Half-Precision1528528
! Node: Decimal Float1532120
! Node: Hex Floats1534074
! Node: Fixed-Point1535204
! Node: Named Address Spaces1538988
! Ref: AVR Named Address Spaces1539682
! Node: Zero Length1547247
! Node: Empty Structures1551488
! Node: Variable Length1551898
! Node: Variadic Macros1554652
! Node: Escaped Newlines1557050
! Node: Subscripting1557911
! Node: Pointer Arith1558640
! Node: Variadic Pointer Args1559241
! Node: Pointers to Arrays1559982
! Node: Initializers1560747
! Node: Compound Literals1561248
! Node: Designated Inits1564863
! Node: Case Ranges1568855
! Node: Cast to Union1569548
! Node: Mixed Labels and Declarations1571312
! Node: Function Attributes1571949
! Node: Common Function Attributes1576447
! Ref: Common Function Attributes-Footnote-11657207
! Node: AArch64 Function Attributes1657524
! Node: AMD GCN Function Attributes1663974
! Node: ARC Function Attributes1667179
! Node: ARM Function Attributes1670220
! Node: AVR Function Attributes1675523
! Node: Blackfin Function Attributes1680234
! Node: BPF Function Attributes1682823
! Node: C-SKY Function Attributes1683416
! Node: Epiphany Function Attributes1684740
! Node: H8/300 Function Attributes1687567
! Node: IA-64 Function Attributes1688777
! Node: M32C Function Attributes1689835
! Node: M32R/D Function Attributes1692213
! Node: m68k Function Attributes1693735
! Node: MCORE Function Attributes1694695
! Node: MicroBlaze Function Attributes1695529
! Node: Microsoft Windows Function Attributes1697082
! Node: MIPS Function Attributes1701767
! Node: MSP430 Function Attributes1707806
! Node: NDS32 Function Attributes1712025
! Node: Nios II Function Attributes1714509
! Node: Nvidia PTX Function Attributes1715842
! Node: PowerPC Function Attributes1716465
! Node: RISC-V Function Attributes1723483
! Node: RL78 Function Attributes1724935
! Node: RX Function Attributes1726218
! Node: S/390 Function Attributes1728821
! Node: SH Function Attributes1730769
! Node: Symbian OS Function Attributes1734257
! Node: V850 Function Attributes1734601
! Node: Visium Function Attributes1735154
! Node: x86 Function Attributes1735686
! Node: Xstormy16 Function Attributes1761702
! Node: Variable Attributes1762213
! Node: Common Variable Attributes1763760
! Node: ARC Variable Attributes1787762
! Node: AVR Variable Attributes1788152
! Node: Blackfin Variable Attributes1793467
! Node: H8/300 Variable Attributes1794373
! Node: IA-64 Variable Attributes1795454
! Node: LoongArch Variable Attributes1796220
! Node: M32R/D Variable Attributes1796916
! Node: Microsoft Windows Variable Attributes1797741
! Node: MSP430 Variable Attributes1800257
! Node: Nvidia PTX Variable Attributes1801507
! Node: PowerPC Variable Attributes1802132
! Node: RL78 Variable Attributes1802705
! Node: V850 Variable Attributes1803128
! Node: x86 Variable Attributes1803773
! Node: Xstormy16 Variable Attributes1804865
! Node: Type Attributes1805459
! Node: Common Type Attributes1807151
! Node: ARC Type Attributes1830154
! Node: ARM Type Attributes1830642
! Node: BPF Type Attributes1831452
! Node: PowerPC Type Attributes1831985
! Node: x86 Type Attributes1833022
! Node: Label Attributes1834050
! Node: Enumerator Attributes1836133
! Node: Statement Attributes1837693
! Node: Attribute Syntax1840033
! Node: Function Prototypes1851506
! Node: C++ Comments1853318
! Node: Dollar Signs1853853
! Node: Character Escapes1854318
! Node: Alignment1854606
! Node: Inline1856315
! Node: Volatiles1861272
! Node: Using Assembly Language with C1864171
! Node: Basic Asm1865448
! Node: Extended Asm1871287
! Ref: Volatile1875533
! Ref: AssemblerTemplate1879738
! Ref: OutputOperands1884066
! Ref: FlagOutputOperands1891346
! Ref: InputOperands1894501
! Ref: Clobbers and Scratch Registers1898970
! Ref: GotoLabels1907823
! Ref: GenericOperandmodifiers1911582
! Ref: x86Operandmodifiers1912576
! Ref: x86floatingpointasmoperands1917956
! Ref: msp430Operandmodifiers1921379
! Ref: loongarchOperandmodifiers1923169
! Node: Constraints1923739
! Node: Simple Constraints1924865
! Node: Multi-Alternative1932439
! Node: Modifiers1934138
! Node: Machine Constraints1937021
! Node: Asm Labels1994964
! Node: Explicit Register Variables1996612
! Ref: Explicit Reg Vars1996826
! Node: Global Register Variables1997435
! Ref: Global Reg Vars1997643
! Node: Local Register Variables2002497
! Ref: Local Reg Vars2002717
! Node: Size of an asm2006407
! Node: Alternate Keywords2007909
! Node: Incomplete Enums2009498
! Node: Function Names2010279
! Node: Return Address2012227
! Node: Vector Extensions2016890
! Node: Offsetof2028141
! Node: __sync Builtins2028986
! Node: __atomic Builtins2036047
! Node: Integer Overflow Builtins2049872
! Node: x86 specific memory model extensions for transactional memory2056387
! Node: Object Size Checking2057673
! Node: Other Builtins2065322
! Node: Target Builtins2121576
! Node: AArch64 Built-in Functions2123324
! Node: Alpha Built-in Functions2124020
! Node: Altera Nios II Built-in Functions2127158
! Node: ARC Built-in Functions2131641
! Node: ARC SIMD Built-in Functions2136909
! Node: ARM iWMMXt Built-in Functions2146059
! Node: ARM C Language Extensions (ACLE)2153199
! Node: ARM Floating Point Status and Control Intrinsics2154480
! Node: ARM ARMv8-M Security Extensions2154967
! Node: AVR Built-in Functions2156267
! Node: Blackfin Built-in Functions2160165
! Node: BPF Built-in Functions2160793
! Node: FR-V Built-in Functions2165423
! Node: Argument Types2166304
! Node: Directly-mapped Integer Functions2168239
! Node: Directly-mapped Media Functions2169519
! Node: Raw read/write Functions2178857
! Node: Other Built-in Functions2179801
! Node: LoongArch Base Built-in Functions2181019
! Node: MIPS DSP Built-in Functions2186805
! Node: MIPS Paired-Single Support2199774
! Node: MIPS Loongson Built-in Functions2201297
! Node: Paired-Single Arithmetic2207859
! Node: Paired-Single Built-in Functions2208986
! Node: MIPS-3D Built-in Functions2211849
! Node: MIPS SIMD Architecture (MSA) Support2217623
! Node: MIPS SIMD Architecture Built-in Functions2220627
! Node: Other MIPS Built-in Functions2247481
! Node: MSP430 Built-in Functions2248514
! Node: NDS32 Built-in Functions2249927
! Node: Basic PowerPC Built-in Functions2251225
! Node: Basic PowerPC Built-in Functions Available on all Configurations2252080
! Node: Basic PowerPC Built-in Functions Available on ISA 2.052260946
! Node: Basic PowerPC Built-in Functions Available on ISA 2.062265965
! Node: Basic PowerPC Built-in Functions Available on ISA 2.072268081
! Node: Basic PowerPC Built-in Functions Available on ISA 3.02268967
! Node: Basic PowerPC Built-in Functions Available on ISA 3.12276502
! Node: PowerPC AltiVec/VSX Built-in Functions2280483
! Node: PowerPC AltiVec Built-in Functions on ISA 2.052289432
! Node: PowerPC AltiVec Built-in Functions Available on ISA 2.062314836
! Node: PowerPC AltiVec Built-in Functions Available on ISA 2.072321950
! Node: PowerPC AltiVec Built-in Functions Available on ISA 3.02331760
! Node: PowerPC AltiVec Built-in Functions Available on ISA 3.12347755
! Node: PowerPC Hardware Transactional Memory Built-in Functions2381451
! Node: PowerPC Atomic Memory Operation Functions2390053
! Node: PowerPC Matrix-Multiply Assist Built-in Functions2392620
! Node: PRU Built-in Functions2398749
! Node: RISC-V Built-in Functions2400029
! Node: RISC-V Vector Intrinsics2400699
! Node: RX Built-in Functions2401198
! Node: S/390 System z Built-in Functions2405291
! Node: SH Built-in Functions2410652
! Node: SPARC VIS Built-in Functions2412416
! Node: TI C6X Built-in Functions2420967
! Node: x86 Built-in Functions2422018
! Node: x86 transactional memory intrinsics2489232
! Node: x86 control-flow protection intrinsics2492586
! Node: Target Format Checks2494373
! Node: Solaris Format Checks2494805
! Node: Darwin Format Checks2495255
! Node: Pragmas2496262
! Node: AArch64 Pragmas2497187
! Node: ARM Pragmas2497652
! Node: M32C Pragmas2498315
! Node: PRU Pragmas2499407
! Node: RS/6000 and PowerPC Pragmas2499990
! Node: S/390 Pragmas2500762
! Node: Darwin Pragmas2501340
! Node: Solaris Pragmas2502425
! Node: Symbol-Renaming Pragmas2503625
! Node: Structure-Layout Pragmas2505288
! Node: Weak Pragmas2507652
! Node: Diagnostic Pragmas2508399
! Node: Visibility Pragmas2513259
! Node: Push/Pop Macro Pragmas2513956
! Node: Function Specific Option Pragmas2514953
! Node: Loop-Specific Pragmas2516983
! Node: Unnamed Fields2518611
! Node: Thread-Local2520884
! Node: C99 Thread-Local Edits2523038
! Node: C++98 Thread-Local Edits2525112
! Node: Binary constants2528653
! Node: C++ Extensions2529352
! Node: C++ Volatiles2530998
! Node: Restricted Pointers2533346
! Node: Vague Linkage2534989
! Node: C++ Interface2538640
! Ref: C++ Interface-Footnote-12542529
! Node: Template Instantiation2542683
! Node: Bound member functions2548806
! Node: C++ Attributes2550350
! Node: Function Multiversioning2554474
! Node: Type Traits2556282
! Node: C++ Concepts2564356
! Node: Deprecated Features2565931
! Node: Backwards Compatibility2567768
! Node: Objective-C2568852
! Node: GNU Objective-C runtime API2569459
! Node: Modern GNU Objective-C runtime API2570466
! Node: Traditional GNU Objective-C runtime API2572978
! Node: Executing code before main2573717
! Node: What you can and what you cannot do in +load2576553
! Node: Type encoding2579037
! Node: Legacy type encoding2584799
! Node: @encode2585903
! Node: Method signatures2586484
! Node: Garbage Collection2588542
! Node: Constant string objects2591268
! Node: compatibility_alias2593833
! Node: Exceptions2594594
! Node: Synchronization2597392
! Node: Fast enumeration2598612
! Node: Using fast enumeration2598924
! Node: c99-like fast enumeration syntax2600163
! Node: Fast enumeration details2600870
! Node: Fast enumeration protocol2603296
! Node: Messaging with the GNU Objective-C runtime2606540
! Node: Dynamically registering methods2607932
! Node: Forwarding hook2609679
! Node: Compatibility2612791
! Node: Gcov2619429
! Node: Gcov Intro2620105
! Node: Invoking Gcov2622897
! Node: Gcov and Optimization2646108
! Node: Gcov Data Files2649941
! Node: Cross-profiling2651410
! Node: Freestanding Environments2653346
! Node: Gcov-tool2668477
! Node: Gcov-tool Intro2668910
! Node: Invoking Gcov-tool2671292
! Node: Gcov-dump2674889
! Node: Gcov-dump Intro2675216
! Node: Invoking Gcov-dump2675491
! Node: lto-dump2676288
! Node: lto-dump Intro2676591
! Node: Invoking lto-dump2676849
! Node: Trouble2678017
! Node: Actual Bugs2679434
! Node: Interoperation2679891
! Node: Incompatibilities2686940
! Node: Fixed Headers2695358
! Node: Standard Libraries2697032
! Node: Disappointments2698436
! Node: C++ Misunderstandings2702841
! Node: Static Definitions2703652
! Node: Name lookup2704737
! Ref: Name lookup-Footnote-12709646
! Node: Temporaries2709835
! Node: Copy Assignment2711863
! Node: Non-bugs2713730
! Node: Warnings and Errors2724422
! Node: Bugs2726212
! Node: Bug Criteria2726679
! Node: Bug Reporting2728921
! Node: Service2729139
! Node: Contributing2729964
! Node: Funding2730710
! Node: GNU Project2733199
! Node: Copying2733847
! Node: GNU Free Documentation License2771376
! Node: Contributors2796502
! Node: Indices2838937
! Node: Option Index2839183
! Node: Concept and Symbol Index3145983
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/doc/gccgo.1 gcc-13.5.0-RC-20260904/gcc/doc/gccgo.1
*** gcc-13.4.0/gcc/doc/gccgo.1	Thu Jun  5 16:30:33 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gccgo.1	Fri Sep  4 07:57:51 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,146 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GCCGO 1"
! .TH GCCGO 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gccgo \- A GCC\-based compiler for the Go language
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
  gccgo [\fB\-c\fR|\fB\-S\fR]
        [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
--- 53,71 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GCCGO 1"
! .TH GCCGO 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gccgo \- A GCC\-based compiler for the Go language
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
  gccgo [\fB\-c\fR|\fB\-S\fR]
        [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
*************** gccgo [\fB\-c\fR|\fB\-S\fR]
*** 149,155 ****
  .PP
  Only the most useful options are listed here; see below for the
  remainder.
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
  The \fBgccgo\fR command is a frontend to \fBgcc\fR and
  supports many of the same options.    This manual
--- 74,80 ----
  .PP
  Only the most useful options are listed here; see below for the
  remainder.
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
  The \fBgccgo\fR command is a frontend to \fBgcc\fR and
  supports many of the same options.    This manual
*************** the link command.
*** 174,190 ****
  Go programs must generally be compiled with debugging information, and
  \&\fB\-g1\fR is the default as described below.  Stripping a Go
  program will generally cause it to misbehave or fail.
! .SH "OPTIONS"
  .IX Header "OPTIONS"
! .IP "\fB\-I\fR\fIdir\fR" 4
  .IX Item "-Idir"
  Specify a directory to use when searching for an import package at
  compile time.
! .IP "\fB\-L\fR\fIdir\fR" 4
  .IX Item "-Ldir"
  When linking, specify a library search directory, as with
  \&\fBgcc\fR.
! .IP "\fB\-fgo\-pkgpath=\fR\fIstring\fR" 4
  .IX Item "-fgo-pkgpath=string"
  Set the package path to use.  This sets the value returned by the
  PkgPath method of reflect.Type objects.  It is also used for the names
--- 99,115 ----
  Go programs must generally be compiled with debugging information, and
  \&\fB\-g1\fR is the default as described below.  Stripping a Go
  program will generally cause it to misbehave or fail.
! .SH OPTIONS
  .IX Header "OPTIONS"
! .IP \fB\-I\fR\fIdir\fR 4
  .IX Item "-Idir"
  Specify a directory to use when searching for an import package at
  compile time.
! .IP \fB\-L\fR\fIdir\fR 4
  .IX Item "-Ldir"
  When linking, specify a library search directory, as with
  \&\fBgcc\fR.
! .IP \fB\-fgo\-pkgpath=\fR\fIstring\fR 4
  .IX Item "-fgo-pkgpath=string"
  Set the package path to use.  This sets the value returned by the
  PkgPath method of reflect.Type objects.  It is also used for the names
*************** of globally visible symbols.  The argume
*** 192,198 ****
  normally be the string that will be used to import this package after
  it has been installed; in other words, a pathname within the
  directories specified by the \fB\-I\fR option.
! .IP "\fB\-fgo\-prefix=\fR\fIstring\fR" 4
  .IX Item "-fgo-prefix=string"
  An alternative to \fB\-fgo\-pkgpath\fR.  The argument will be
  combined with the package name from the source file to produce the
--- 117,123 ----
  normally be the string that will be used to import this package after
  it has been installed; in other words, a pathname within the
  directories specified by the \fB\-I\fR option.
! .IP \fB\-fgo\-prefix=\fR\fIstring\fR 4
  .IX Item "-fgo-prefix=string"
  An alternative to \fB\-fgo\-pkgpath\fR.  The argument will be
  combined with the package name from the source file to produce the
*************** compiling a package.
*** 209,241 ****
  Using either \fB\-fgo\-pkgpath\fR or \fB\-fgo\-prefix\fR disables
  the special treatment of the \f(CW\*(C`main\*(C'\fR package and permits that
  package to be imported like any other.
! .IP "\fB\-fgo\-relative\-import\-path=\fR\fIdir\fR" 4
  .IX Item "-fgo-relative-import-path=dir"
  A relative import is an import that starts with \fI./\fR or
  \&\fI../\fR.  If this option is used, \fBgccgo\fR will use
  \&\fIdir\fR as a prefix for the relative import when searching for it.
! .IP "\fB\-frequire\-return\-statement\fR" 4
  .IX Item "-frequire-return-statement"
  .PD 0
! .IP "\fB\-fno\-require\-return\-statement\fR" 4
  .IX Item "-fno-require-return-statement"
  .PD
  By default \fBgccgo\fR will warn about functions which have one or
  more return parameters but lack an explicit \f(CW\*(C`return\*(C'\fR statement.
  This warning may be disabled using
  \&\fB\-fno\-require\-return\-statement\fR.
! .IP "\fB\-fgo\-check\-divide\-zero\fR" 4
  .IX Item "-fgo-check-divide-zero"
  Add explicit checks for division by zero.  In Go a division (or
  modulos) by zero causes a panic.  On Unix systems this is detected in
  the runtime by catching the \f(CW\*(C`SIGFPE\*(C'\fR signal.  Some processors,
! such as PowerPC, do not generate a \s-1SIGFPE\s0 on division by zero.  Some
  runtimes do not generate a signal that can be caught.  On those
  systems, this option may be used.  Or the checks may be removed via
  \&\fB\-fno\-go\-check\-divide\-zero\fR.  This option is currently on by
  default, but in the future may be off by default on systems that do
  not require it.
! .IP "\fB\-fgo\-check\-divide\-overflow\fR" 4
  .IX Item "-fgo-check-divide-overflow"
  Add explicit checks for division overflow.  For example, division
  overflow occurs when computing \f(CW\*(C`INT_MIN / \-1\*(C'\fR.  In Go this should
--- 134,166 ----
  Using either \fB\-fgo\-pkgpath\fR or \fB\-fgo\-prefix\fR disables
  the special treatment of the \f(CW\*(C`main\*(C'\fR package and permits that
  package to be imported like any other.
! .IP \fB\-fgo\-relative\-import\-path=\fR\fIdir\fR 4
  .IX Item "-fgo-relative-import-path=dir"
  A relative import is an import that starts with \fI./\fR or
  \&\fI../\fR.  If this option is used, \fBgccgo\fR will use
  \&\fIdir\fR as a prefix for the relative import when searching for it.
! .IP \fB\-frequire\-return\-statement\fR 4
  .IX Item "-frequire-return-statement"
  .PD 0
! .IP \fB\-fno\-require\-return\-statement\fR 4
  .IX Item "-fno-require-return-statement"
  .PD
  By default \fBgccgo\fR will warn about functions which have one or
  more return parameters but lack an explicit \f(CW\*(C`return\*(C'\fR statement.
  This warning may be disabled using
  \&\fB\-fno\-require\-return\-statement\fR.
! .IP \fB\-fgo\-check\-divide\-zero\fR 4
  .IX Item "-fgo-check-divide-zero"
  Add explicit checks for division by zero.  In Go a division (or
  modulos) by zero causes a panic.  On Unix systems this is detected in
  the runtime by catching the \f(CW\*(C`SIGFPE\*(C'\fR signal.  Some processors,
! such as PowerPC, do not generate a SIGFPE on division by zero.  Some
  runtimes do not generate a signal that can be caught.  On those
  systems, this option may be used.  Or the checks may be removed via
  \&\fB\-fno\-go\-check\-divide\-zero\fR.  This option is currently on by
  default, but in the future may be off by default on systems that do
  not require it.
! .IP \fB\-fgo\-check\-divide\-overflow\fR 4
  .IX Item "-fgo-check-divide-overflow"
  Add explicit checks for division overflow.  For example, division
  overflow occurs when computing \f(CW\*(C`INT_MIN / \-1\*(C'\fR.  In Go this should
*************** may be used.  Or the checks may be remov
*** 245,285 ****
  \&\fB\-fno\-go\-check\-divide\-overflow\fR.  This option is currently on
  by default, but in the future may be off by default on systems that do
  not require it.
! .IP "\fB\-fno\-go\-optimize\-allocs\fR" 4
  .IX Item "-fno-go-optimize-allocs"
  Disable escape analysis, which tries to allocate objects on the stack
  rather than the heap.
! .IP "\fB\-fgo\-debug\-escape\fR\fIn\fR" 4
  .IX Item "-fgo-debug-escapen"
  Output escape analysis debugging information.  Larger values of
  \&\fIn\fR generate more information.
! .IP "\fB\-fgo\-debug\-escape\-hash=\fR\fIn\fR" 4
  .IX Item "-fgo-debug-escape-hash=n"
  A hash value to debug escape analysis.  \fIn\fR is a binary string.
  This runs escape analysis only on functions whose names hash to values
  that match the given suffix \fIn\fR.  This can be used to binary
  search across functions to uncover escape analysis bugs.
! .IP "\fB\-fgo\-debug\-optimization\fR" 4
  .IX Item "-fgo-debug-optimization"
  Output optimization diagnostics.
! .IP "\fB\-fgo\-c\-header=\fR\fIfile\fR" 4
  .IX Item "-fgo-c-header=file"
! Write top-level named Go struct definitions to \fIfile\fR as C code.
  This is used when compiling the runtime package.
! .IP "\fB\-fgo\-compiling\-runtime\fR" 4
  .IX Item "-fgo-compiling-runtime"
  Apply special rules for compiling the runtime package.  Implicit
  memory allocation is forbidden.  Some additional compiler directives
  are supported.
! .IP "\fB\-fgo\-embedcfg=\fR\fIfile\fR" 4
  .IX Item "-fgo-embedcfg=file"
! Identify a \s-1JSON\s0 file used to map patterns used with special
  \&\f(CW\*(C`//go:embed\*(C'\fR comments to the files named by the patterns.  The
! \&\s-1JSON\s0 file should have two components: \f(CW\*(C`Patterns\*(C'\fR maps each
  pattern to a list of file names, and \f(CW\*(C`Files\*(C'\fR maps each file name
  to a full path to the file.  This option is intended for use by the
  \&\fBgo\fR command to implement \f(CW\*(C`//go:embed\*(C'\fR.
! .IP "\fB\-g\fR" 4
  .IX Item "-g"
  This is the standard \fBgcc\fR option.  It
  is mentioned here because by default \fBgccgo\fR turns on
--- 170,210 ----
  \&\fB\-fno\-go\-check\-divide\-overflow\fR.  This option is currently on
  by default, but in the future may be off by default on systems that do
  not require it.
! .IP \fB\-fno\-go\-optimize\-allocs\fR 4
  .IX Item "-fno-go-optimize-allocs"
  Disable escape analysis, which tries to allocate objects on the stack
  rather than the heap.
! .IP \fB\-fgo\-debug\-escape\fR\fIn\fR 4
  .IX Item "-fgo-debug-escapen"
  Output escape analysis debugging information.  Larger values of
  \&\fIn\fR generate more information.
! .IP \fB\-fgo\-debug\-escape\-hash=\fR\fIn\fR 4
  .IX Item "-fgo-debug-escape-hash=n"
  A hash value to debug escape analysis.  \fIn\fR is a binary string.
  This runs escape analysis only on functions whose names hash to values
  that match the given suffix \fIn\fR.  This can be used to binary
  search across functions to uncover escape analysis bugs.
! .IP \fB\-fgo\-debug\-optimization\fR 4
  .IX Item "-fgo-debug-optimization"
  Output optimization diagnostics.
! .IP \fB\-fgo\-c\-header=\fR\fIfile\fR 4
  .IX Item "-fgo-c-header=file"
! Write top\-level named Go struct definitions to \fIfile\fR as C code.
  This is used when compiling the runtime package.
! .IP \fB\-fgo\-compiling\-runtime\fR 4
  .IX Item "-fgo-compiling-runtime"
  Apply special rules for compiling the runtime package.  Implicit
  memory allocation is forbidden.  Some additional compiler directives
  are supported.
! .IP \fB\-fgo\-embedcfg=\fR\fIfile\fR 4
  .IX Item "-fgo-embedcfg=file"
! Identify a JSON file used to map patterns used with special
  \&\f(CW\*(C`//go:embed\*(C'\fR comments to the files named by the patterns.  The
! JSON file should have two components: \f(CW\*(C`Patterns\*(C'\fR maps each
  pattern to a list of file names, and \f(CW\*(C`Files\*(C'\fR maps each file name
  to a full path to the file.  This option is intended for use by the
  \&\fBgo\fR command to implement \f(CW\*(C`//go:embed\*(C'\fR.
! .IP \fB\-g\fR 4
  .IX Item "-g"
  This is the standard \fBgcc\fR option.  It
  is mentioned here because by default \fBgccgo\fR turns on
*************** functions, such as \f(CW\*(C`runtime.Cal
*** 293,317 ****
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7), \fBgcc\fR\|(1)
  and the Info entries for \fIgccgo\fR and \fIgcc\fR.
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 2010\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with no
! Invariant Sections, the Front-Cover Texts being (a) (see below), and
! with the Back-Cover Texts being (b) (see below).
  A copy of the license is included in the
  man page \fBgfdl\fR\|(7).
  .PP
! (a) The \s-1FSF\s0's Front-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The \s-1FSF\s0's Back-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
--- 218,242 ----
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7), \fBgcc\fR\|(1)
  and the Info entries for \fIgccgo\fR and \fIgcc\fR.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 2010\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the GNU Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with no
! Invariant Sections, the Front\-Cover Texts being (a) (see below), and
! with the Back\-Cover Texts being (b) (see below).
  A copy of the license is included in the
  man page \fBgfdl\fR\|(7).
  .PP
! (a) The FSF\*(Aqs Front\-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The FSF\*(Aqs Back\-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
diff -Nrcpad gcc-13.4.0/gcc/doc/gccgo.info gcc-13.5.0-RC-20260904/gcc/doc/gccgo.info
*** gcc-13.4.0/gcc/doc/gccgo.info	Thu Jun  5 16:30:33 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gccgo.info	Fri Sep  4 07:57:51 2026
***************
*** 1,6 ****
! This is gccgo.info, produced by makeinfo version 6.8 from gccgo.texi.
  
! Copyright (C) 2010-2023 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
--- 1,6 ----
! This is gccgo.info, produced by makeinfo version 7.1 from gccgo.texi.
  
! Copyright © 2010-2023 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
*************** START-INFO-DIR-ENTRY
*** 24,30 ****
  END-INFO-DIR-ENTRY
  
  
!    Copyright (C) 2010-2023 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
--- 24,30 ----
  END-INFO-DIR-ENTRY
  
  
!    Copyright © 2010-2023 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
*************** File: gccgo.info,  Node: Top,  Next: Cop
*** 49,56 ****
  Introduction
  ************
  
! This manual describes how to use 'gccgo', the GNU compiler for the Go
! programming language.  This manual is specifically about 'gccgo'.  For
  more information about the Go programming language in general, including
  language specifications and standard package documentation, see
  .
--- 49,56 ----
  Introduction
  ************
  
! This manual describes how to use ‘gccgo’, the GNU compiler for the Go
! programming language.  This manual is specifically about ‘gccgo’.  For
  more information about the Go programming language in general, including
  language specifications and standard package documentation, see
  .
*************** GNU General Public License
*** 74,80 ****
  
                          Version 3, 29 June 2007
  
!      Copyright (C) 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
--- 74,80 ----
  
                          Version 3, 29 June 2007
  
!      Copyright © 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
*************** mail.
*** 761,771 ****
  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".
--- 761,771 ----
  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".
*************** GNU Free Documentation License
*** 790,796 ****
  
                       Version 1.3, 3 November 2008
  
!      Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
--- 790,796 ----
  
                       Version 1.3, 3 November 2008
  
!      Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
*************** GNU Free Documentation License
*** 799,805 ****
    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
--- 799,805 ----
    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
*************** File: gccgo.info,  Node: Invoking gccgo,
*** 1270,1404 ****
  1 Invoking gccgo
  ****************
  
! The 'gccgo' command is a frontend to 'gcc' and supports many of the same
  options.  *Note Option Summary: (gcc)Option Summary.  This manual only
! documents the options specific to 'gccgo'.
  
!    The 'gccgo' command may be used to compile Go source code into an
  object file, link a collection of object files together, or do both in
  sequence.
  
     Go source code is compiled as packages.  A package consists of one or
  more Go source files.  All the files in a single package must be
! compiled together, by passing all the files as arguments to 'gccgo'.  A
! single invocation of 'gccgo' may only compile a single package.
  
!    One Go package may 'import' a different Go package.  The imported
! package must have already been compiled; 'gccgo' will read the import
  data directly from the compiled package.  When this package is later
  linked, the compiled form of the package must be included in the link
  command.
  
     Go programs must generally be compiled with debugging information,
! and '-g1' is the default as described below.  Stripping a Go program
  will generally cause it to misbehave or fail.
  
! '-IDIR'
       Specify a directory to use when searching for an import package at
       compile time.
  
! '-LDIR'
!      When linking, specify a library search directory, as with 'gcc'.
  
! '-fgo-pkgpath=STRING'
       Set the package path to use.  This sets the value returned by the
       PkgPath method of reflect.Type objects.  It is also used for the
       names of globally visible symbols.  The argument to this option
       should normally be the string that will be used to import this
       package after it has been installed; in other words, a pathname
!      within the directories specified by the '-I' option.
  
! '-fgo-prefix=STRING'
!      An alternative to '-fgo-pkgpath'.  The argument will be combined
       with the package name from the source file to produce the package
!      path.  If '-fgo-pkgpath' is used, '-fgo-prefix' will be ignored.
  
       Go permits a single program to include more than one package with
!      the same name in the 'package' clause in the source file, though
       obviously the two packages must be imported using different
!      pathnames.  In order for this to work with 'gccgo', either
!      '-fgo-pkgpath' or '-fgo-prefix' must be specified when compiling a
       package.
  
!      Using either '-fgo-pkgpath' or '-fgo-prefix' disables the special
!      treatment of the 'main' package and permits that package to be
       imported like any other.
  
! '-fgo-relative-import-path=DIR'
!      A relative import is an import that starts with './' or '../'.  If
!      this option is used, 'gccgo' will use DIR as a prefix for the
       relative import when searching for it.
  
! '-frequire-return-statement'
! '-fno-require-return-statement'
!      By default 'gccgo' will warn about functions which have one or more
!      return parameters but lack an explicit 'return' statement.  This
!      warning may be disabled using '-fno-require-return-statement'.
  
! '-fgo-check-divide-zero'
       Add explicit checks for division by zero.  In Go a division (or
       modulos) by zero causes a panic.  On Unix systems this is detected
!      in the runtime by catching the 'SIGFPE' signal.  Some processors,
       such as PowerPC, do not generate a SIGFPE on division by zero.
       Some runtimes do not generate a signal that can be caught.  On
       those systems, this option may be used.  Or the checks may be
!      removed via '-fno-go-check-divide-zero'.  This option is currently
       on by default, but in the future may be off by default on systems
       that do not require it.
  
! '-fgo-check-divide-overflow'
       Add explicit checks for division overflow.  For example, division
!      overflow occurs when computing 'INT_MIN / -1'.  In Go this should
!      be wrapped, to produce 'INT_MIN'.  Some processors, such as x86,
       generate a trap on division overflow.  On those systems, this
       option may be used.  Or the checks may be removed via
!      '-fno-go-check-divide-overflow'.  This option is currently on by
       default, but in the future may be off by default on systems that do
       not require it.
  
! '-fno-go-optimize-allocs'
       Disable escape analysis, which tries to allocate objects on the
       stack rather than the heap.
  
! '-fgo-debug-escapeN'
       Output escape analysis debugging information.  Larger values of N
       generate more information.
  
! '-fgo-debug-escape-hash=N'
       A hash value to debug escape analysis.  N is a binary string.  This
       runs escape analysis only on functions whose names hash to values
       that match the given suffix N.  This can be used to binary search
       across functions to uncover escape analysis bugs.
  
! '-fgo-debug-optimization'
       Output optimization diagnostics.
  
! '-fgo-c-header=FILE'
       Write top-level named Go struct definitions to FILE as C code.
       This is used when compiling the runtime package.
  
! '-fgo-compiling-runtime'
       Apply special rules for compiling the runtime package.  Implicit
       memory allocation is forbidden.  Some additional compiler
       directives are supported.
  
! '-fgo-embedcfg=FILE'
       Identify a JSON file used to map patterns used with special
!      '//go:embed' comments to the files named by the patterns.  The JSON
!      file should have two components: 'Patterns' maps each pattern to a
!      list of file names, and 'Files' maps each file name to a full path
!      to the file.  This option is intended for use by the 'go' command
!      to implement '//go:embed'.
  
! '-g'
!      This is the standard 'gcc' option (*note Debugging Options:
       (gcc)Debugging Options.).  It is mentioned here because by default
!      'gccgo' turns on debugging information generation with the
!      equivalent of the standard option '-g1'.  This is because Go
       programs require debugging information to be available in order to
!      get backtrace information.  An explicit '-g0' may be used to
       disable the generation of debugging information, in which case
!      certain standard library functions, such as 'runtime.Callers', will
       not operate correctly.
  
  
--- 1270,1404 ----
  1 Invoking gccgo
  ****************
  
! The ‘gccgo’ command is a frontend to ‘gcc’ and supports many of the same
  options.  *Note Option Summary: (gcc)Option Summary.  This manual only
! documents the options specific to ‘gccgo’.
  
!    The ‘gccgo’ command may be used to compile Go source code into an
  object file, link a collection of object files together, or do both in
  sequence.
  
     Go source code is compiled as packages.  A package consists of one or
  more Go source files.  All the files in a single package must be
! compiled together, by passing all the files as arguments to ‘gccgo’.  A
! single invocation of ‘gccgo’ may only compile a single package.
  
!    One Go package may ‘import’ a different Go package.  The imported
! package must have already been compiled; ‘gccgo’ will read the import
  data directly from the compiled package.  When this package is later
  linked, the compiled form of the package must be included in the link
  command.
  
     Go programs must generally be compiled with debugging information,
! and ‘-g1’ is the default as described below.  Stripping a Go program
  will generally cause it to misbehave or fail.
  
! ‘-IDIR’
       Specify a directory to use when searching for an import package at
       compile time.
  
! ‘-LDIR’
!      When linking, specify a library search directory, as with ‘gcc’.
  
! ‘-fgo-pkgpath=STRING’
       Set the package path to use.  This sets the value returned by the
       PkgPath method of reflect.Type objects.  It is also used for the
       names of globally visible symbols.  The argument to this option
       should normally be the string that will be used to import this
       package after it has been installed; in other words, a pathname
!      within the directories specified by the ‘-I’ option.
  
! ‘-fgo-prefix=STRING’
!      An alternative to ‘-fgo-pkgpath’.  The argument will be combined
       with the package name from the source file to produce the package
!      path.  If ‘-fgo-pkgpath’ is used, ‘-fgo-prefix’ will be ignored.
  
       Go permits a single program to include more than one package with
!      the same name in the ‘package’ clause in the source file, though
       obviously the two packages must be imported using different
!      pathnames.  In order for this to work with ‘gccgo’, either
!      ‘-fgo-pkgpath’ or ‘-fgo-prefix’ must be specified when compiling a
       package.
  
!      Using either ‘-fgo-pkgpath’ or ‘-fgo-prefix’ disables the special
!      treatment of the ‘main’ package and permits that package to be
       imported like any other.
  
! ‘-fgo-relative-import-path=DIR’
!      A relative import is an import that starts with ‘./’ or ‘../’.  If
!      this option is used, ‘gccgo’ will use DIR as a prefix for the
       relative import when searching for it.
  
! ‘-frequire-return-statement’
! ‘-fno-require-return-statement’
!      By default ‘gccgo’ will warn about functions which have one or more
!      return parameters but lack an explicit ‘return’ statement.  This
!      warning may be disabled using ‘-fno-require-return-statement’.
  
! ‘-fgo-check-divide-zero’
       Add explicit checks for division by zero.  In Go a division (or
       modulos) by zero causes a panic.  On Unix systems this is detected
!      in the runtime by catching the ‘SIGFPE’ signal.  Some processors,
       such as PowerPC, do not generate a SIGFPE on division by zero.
       Some runtimes do not generate a signal that can be caught.  On
       those systems, this option may be used.  Or the checks may be
!      removed via ‘-fno-go-check-divide-zero’.  This option is currently
       on by default, but in the future may be off by default on systems
       that do not require it.
  
! ‘-fgo-check-divide-overflow’
       Add explicit checks for division overflow.  For example, division
!      overflow occurs when computing ‘INT_MIN / -1’.  In Go this should
!      be wrapped, to produce ‘INT_MIN’.  Some processors, such as x86,
       generate a trap on division overflow.  On those systems, this
       option may be used.  Or the checks may be removed via
!      ‘-fno-go-check-divide-overflow’.  This option is currently on by
       default, but in the future may be off by default on systems that do
       not require it.
  
! ‘-fno-go-optimize-allocs’
       Disable escape analysis, which tries to allocate objects on the
       stack rather than the heap.
  
! ‘-fgo-debug-escapeN’
       Output escape analysis debugging information.  Larger values of N
       generate more information.
  
! ‘-fgo-debug-escape-hash=N’
       A hash value to debug escape analysis.  N is a binary string.  This
       runs escape analysis only on functions whose names hash to values
       that match the given suffix N.  This can be used to binary search
       across functions to uncover escape analysis bugs.
  
! ‘-fgo-debug-optimization’
       Output optimization diagnostics.
  
! ‘-fgo-c-header=FILE’
       Write top-level named Go struct definitions to FILE as C code.
       This is used when compiling the runtime package.
  
! ‘-fgo-compiling-runtime’
       Apply special rules for compiling the runtime package.  Implicit
       memory allocation is forbidden.  Some additional compiler
       directives are supported.
  
! ‘-fgo-embedcfg=FILE’
       Identify a JSON file used to map patterns used with special
!      ‘//go:embed’ comments to the files named by the patterns.  The JSON
!      file should have two components: ‘Patterns’ maps each pattern to a
!      list of file names, and ‘Files’ maps each file name to a full path
!      to the file.  This option is intended for use by the ‘go’ command
!      to implement ‘//go:embed’.
  
! ‘-g’
!      This is the standard ‘gcc’ option (*note Debugging Options:
       (gcc)Debugging Options.).  It is mentioned here because by default
!      ‘gccgo’ turns on debugging information generation with the
!      equivalent of the standard option ‘-g1’.  This is because Go
       programs require debugging information to be available in order to
!      get backtrace information.  An explicit ‘-g0’ may be used to
       disable the generation of debugging information, in which case
!      certain standard library functions, such as ‘runtime.Callers’, will
       not operate correctly.
  
  
*************** File: gccgo.info,  Node: Import and Expo
*** 1407,1444 ****
  2 Import and Export
  *******************
  
! When 'gccgo' compiles a package which exports anything, the export
  information will be stored directly in the object file.  When a package
! is imported, 'gccgo' must be able to find the file.
  
!    When Go code imports the package 'GOPACKAGE', 'gccgo' will look for
  the import data using the following filenames, using the first one that
  it finds.
  
! 'GOPACKAGE.gox'
! 'libGOPACKAGE.so'
! 'libGOPACKAGE.a'
! 'GOPACKAGE.o'
  
     The compiler will search for these files in the directories named by
! any '-I' options, in order in which the directories appear on the
  command line.  The compiler will then search several standard system
  directories.  Finally the compiler will search the current directory (to
! search the current directory earlier, use '-I.').
  
     The compiler will extract the export information directly from the
! compiled object file.  The file 'GOPACKAGE.gox' will typically contain
! nothing but export data.  This can be generated from 'GOPACKAGE.o' via
  
       objcopy -j .go_export GOPACKAGE.o GOPACKAGE.gox
  
     For example, it may be desirable to extract the export information
! from several different packages into their independent 'GOPACKAGE.gox'
  files, and then to combine the different package object files together
  into a single shared library or archive.
  
!    At link time you must explicitly tell 'gccgo' which files to link
! together into the executable, as is usual with 'gcc'.  This is different
  from the behavior of other Go compilers.
  
  
--- 1407,1444 ----
  2 Import and Export
  *******************
  
! When ‘gccgo’ compiles a package which exports anything, the export
  information will be stored directly in the object file.  When a package
! is imported, ‘gccgo’ must be able to find the file.
  
!    When Go code imports the package ‘GOPACKAGE’, ‘gccgo’ will look for
  the import data using the following filenames, using the first one that
  it finds.
  
! ‘GOPACKAGE.gox’
! ‘libGOPACKAGE.so’
! ‘libGOPACKAGE.a’
! ‘GOPACKAGE.o’
  
     The compiler will search for these files in the directories named by
! any ‘-I’ options, in order in which the directories appear on the
  command line.  The compiler will then search several standard system
  directories.  Finally the compiler will search the current directory (to
! search the current directory earlier, use ‘-I.’).
  
     The compiler will extract the export information directly from the
! compiled object file.  The file ‘GOPACKAGE.gox’ will typically contain
! nothing but export data.  This can be generated from ‘GOPACKAGE.o’ via
  
       objcopy -j .go_export GOPACKAGE.o GOPACKAGE.gox
  
     For example, it may be desirable to extract the export information
! from several different packages into their independent ‘GOPACKAGE.gox’
  files, and then to combine the different package object files together
  into a single shared library or archive.
  
!    At link time you must explicitly tell ‘gccgo’ which files to link
! together into the executable, as is usual with ‘gcc’.  This is different
  from the behavior of other Go compilers.
  
  
*************** File: gccgo.info,  Node: Compiler Direct
*** 1448,1474 ****
  *********************
  
  The Go compiler supports a few compiler directives.  A compiler
! directive uses a '//' comment at the start of a line.  There must be no
! space between the '//' and the name of the directive.
  
! '//line FILE:LINE'
!      The '//line' directive specifies that the source line that follows
       should be recorded as having come from the given file path and line
       number.  Successive lines are recorded using increasing line
       numbers, until the next directive.  This directive typically
       appears in machine-generated code, so that compilers and debuggers
       will show lines in the original input to the generator.
  
! '//extern EXTERN_NAME'
!      The 'extern' directive sets the externally visible name of the next
       function declaration.  See *note Function Names::.
  
! '//go:compile GO_NAME EXTERN_NAME'
!      The 'go:compile' directives sets the externally visible name of a
       function definition or declaration.  See *note Function Names::.
  
! '//go:noescape'
!      The '//go:noescape' directive specifies that the next declaration
       in the file, which must be a func without a body (meaning that it
       has an implementation not written in Go) does not allow any of the
       pointers passed as arguments to escape into the heap or into the
--- 1448,1474 ----
  *********************
  
  The Go compiler supports a few compiler directives.  A compiler
! directive uses a ‘//’ comment at the start of a line.  There must be no
! space between the ‘//’ and the name of the directive.
  
! ‘//line FILE:LINE’
!      The ‘//line’ directive specifies that the source line that follows
       should be recorded as having come from the given file path and line
       number.  Successive lines are recorded using increasing line
       numbers, until the next directive.  This directive typically
       appears in machine-generated code, so that compilers and debuggers
       will show lines in the original input to the generator.
  
! ‘//extern EXTERN_NAME’
!      The ‘extern’ directive sets the externally visible name of the next
       function declaration.  See *note Function Names::.
  
! ‘//go:compile GO_NAME EXTERN_NAME’
!      The ‘go:compile’ directives sets the externally visible name of a
       function definition or declaration.  See *note Function Names::.
  
! ‘//go:noescape’
!      The ‘//go:noescape’ directive specifies that the next declaration
       in the file, which must be a func without a body (meaning that it
       has an implementation not written in Go) does not allow any of the
       pointers passed as arguments to escape into the heap or into the
*************** space between the '//' and the name of t
*** 1476,1489 ****
       during the compiler's escape analysis of Go code calling the
       function.
  
! '//go:nosplit'
!      The '//go:nosplit' directive specifies that the next function
       declared in the file must not include a stack overflow check.  This
       is most commonly used by low-level runtime sources invoked at times
       when it is unsafe for the calling goroutine to be preempted.
  
! '//go:noinline'
!      The '//go:noinline' directive specifies that the next function
       defined in the file may not be inlined.
  
  
--- 1476,1489 ----
       during the compiler's escape analysis of Go code calling the
       function.
  
! ‘//go:nosplit’
!      The ‘//go:nosplit’ directive specifies that the next function
       declared in the file must not include a stack overflow check.  This
       is most commonly used by low-level runtime sources invoked at times
       when it is unsafe for the calling goroutine to be preempted.
  
! ‘//go:noinline’
!      The ‘//go:noinline’ directive specifies that the next function
       defined in the file may not be inlined.
  
  
*************** File: gccgo.info,  Node: C Interoperabil
*** 1492,1503 ****
  4 C Interoperability
  ********************
  
! When using 'gccgo' there is limited interoperability with C, or with C++
! code compiled using 'extern "C"'.
  
     This information is provided largely for documentation purposes.  For
  ordinary use it is best to build programs with the go tool and then use
! 'import "C"', as described at .
  
  * Menu:
  
--- 1492,1503 ----
  4 C Interoperability
  ********************
  
! When using ‘gccgo’ there is limited interoperability with C, or with C++
! code compiled using ‘extern "C"’.
  
     This information is provided largely for documentation purposes.  For
  ordinary use it is best to build programs with the go tool and then use
! ‘import "C"’, as described at .
  
  * Menu:
  
*************** File: gccgo.info,  Node: C Type Interope
*** 1510,1521 ****
  4.1 C Type Interoperability
  ===========================
  
! Basic types map directly: an 'int' in Go is an 'int' in C, etc.  Go
! 'byte' is equivalent to C 'unsigned char'.  Pointers in Go are pointers
! in C. A Go 'struct' is the same as C 'struct' with the same field names
  and types.
  
!    The Go 'string' type is currently defined as a two-element structure:
  
       struct __go_string {
         const unsigned char *__data;
--- 1510,1521 ----
  4.1 C Type Interoperability
  ===========================
  
! Basic types map directly: an ‘int’ in Go is an ‘int’ in C, etc.  Go
! ‘byte’ is equivalent to C ‘unsigned char’.  Pointers in Go are pointers
! in C. A Go ‘struct’ is the same as C ‘struct’ with the same field names
  and types.
  
!    The Go ‘string’ type is currently defined as a two-element structure:
  
       struct __go_string {
         const unsigned char *__data;
*************** and types.
*** 1524,1530 ****
  
     You can't pass arrays between C and Go.  However, a pointer to an
  array in Go is equivalent to a C pointer to the equivalent of the
! element type.  For example, Go '*[10]int' is equivalent to C 'int*',
  assuming that the C pointer does point to 10 elements.
  
     A slice in Go is a structure.  The current definition is:
--- 1524,1530 ----
  
     You can't pass arrays between C and Go.  However, a pointer to an
  array in Go is equivalent to a C pointer to the equivalent of the
! element type.  For example, Go ‘*[10]int’ is equivalent to C ‘int*’,
  assuming that the C pointer does point to 10 elements.
  
     A slice in Go is a structure.  The current definition is:
*************** example, these functions have equivalent
*** 1546,1558 ****
     A pointer to a Go function is equivalent to a pointer to a C function
  when the functions have equivalent types.
  
!    Go 'interface', 'channel', and 'map' types have no corresponding C
! type ('interface' is a two-element struct and 'channel' and 'map' are
  pointers to structs in C, but the structs are deliberately
! undocumented).  C 'enum' types correspond to some integer type, but
  precisely which one is difficult to predict in general; use a cast.  C
! 'union' types have no corresponding Go type.  C 'struct' types
! containing bitfields have no corresponding Go type.  C++ 'class' types
  have no corresponding Go type.
  
     Memory allocation is completely different between C and Go, as Go
--- 1546,1558 ----
     A pointer to a Go function is equivalent to a pointer to a C function
  when the functions have equivalent types.
  
!    Go ‘interface’, ‘channel’, and ‘map’ types have no corresponding C
! type (‘interface’ is a two-element struct and ‘channel’ and ‘map’ are
  pointers to structs in C, but the structs are deliberately
! undocumented).  C ‘enum’ types correspond to some integer type, but
  precisely which one is difficult to predict in general; use a cast.  C
! ‘union’ types have no corresponding Go type.  C ‘struct’ types
! containing bitfields have no corresponding Go type.  C++ ‘class’ types
  have no corresponding Go type.
  
     Memory allocation is completely different between C and Go, as Go
*************** File: gccgo.info,  Node: Function Names,
*** 1572,1614 ****
  4.2 Function Names
  ==================
  
! Go code can call C functions directly using the '//extern' or
! '//go:linkname' compiler directives.  An '//extern' directive must be at
! the beginning of the line and must start with '//extern'.  This must be
  followed by a space and then the external name of the function.  The
  function declaration must be on the line immediately after the comment.
! For example, here is how the C function 'open' can be declared in Go:
  
       //extern open
       func c_open(name *byte, mode int, perm int) int
  
!    You can do the same thing using the '//go:linkname' compiler
! directive.  The '//go:linkname' directive must be at the start of the
  line.  It is followed by whitespace, the name of the Go function, more
! whitespace, and the external name of the function.  Unlike '//extern',
! '//go:linkname' does not need to appear immediately adjacent to the
  function definition or declaration.
  
       //go:linkname c_open open
       func c_open(name *byte, mode int, perm int) int
  
     The C function naturally expects a nul terminated string, which in Go
! is equivalent to a pointer to an array (not a slice!)  of 'byte' with a
  terminating zero byte.  So a sample call from Go would look like (after
! importing the 'os' package):
  
       var name = [4]byte{'f', 'o', 'o', 0};
       i := c_open(&name[0], os.O_RDONLY, 0);
  
     Note that this serves as an example only.  To open a file in Go
! please use Go's 'os.Open' function instead.
  
     The name of Go functions accessed from C is subject to change.  At
  present the name of a Go function that does not have a receiver is
! 'pkgpath.Functionname'.  The PKGPATH is set by the '-fgo-pkgpath' option
  used when the package is compiled; if the option is not used, the
! default is 'go.PACKAGENAME'.  To call the function from C you must set
! the name using the 'gcc' '__asm__' extension.
  
       extern int go_function(int) __asm__ ("mypkgpath.Function");
  
--- 1572,1614 ----
  4.2 Function Names
  ==================
  
! Go code can call C functions directly using the ‘//extern’ or
! ‘//go:linkname’ compiler directives.  An ‘//extern’ directive must be at
! the beginning of the line and must start with ‘//extern’.  This must be
  followed by a space and then the external name of the function.  The
  function declaration must be on the line immediately after the comment.
! For example, here is how the C function ‘open’ can be declared in Go:
  
       //extern open
       func c_open(name *byte, mode int, perm int) int
  
!    You can do the same thing using the ‘//go:linkname’ compiler
! directive.  The ‘//go:linkname’ directive must be at the start of the
  line.  It is followed by whitespace, the name of the Go function, more
! whitespace, and the external name of the function.  Unlike ‘//extern’,
! ‘//go:linkname’ does not need to appear immediately adjacent to the
  function definition or declaration.
  
       //go:linkname c_open open
       func c_open(name *byte, mode int, perm int) int
  
     The C function naturally expects a nul terminated string, which in Go
! is equivalent to a pointer to an array (not a slice!)  of ‘byte’ with a
  terminating zero byte.  So a sample call from Go would look like (after
! importing the ‘os’ package):
  
       var name = [4]byte{'f', 'o', 'o', 0};
       i := c_open(&name[0], os.O_RDONLY, 0);
  
     Note that this serves as an example only.  To open a file in Go
! please use Go's ‘os.Open’ function instead.
  
     The name of Go functions accessed from C is subject to change.  At
  present the name of a Go function that does not have a receiver is
! ‘pkgpath.Functionname’.  The PKGPATH is set by the ‘-fgo-pkgpath’ option
  used when the package is compiled; if the option is not used, the
! default is ‘go.PACKAGENAME’.  To call the function from C you must set
! the name using the ‘gcc’ ‘__asm__’ extension.
  
       extern int go_function(int) __asm__ ("mypkgpath.Function");
  
*************** Index
*** 1654,1669 ****
  
  
  Tag Table:
! Node: Top1688
! Node: Copying2548
! Node: GNU Free Documentation License40087
! Node: Invoking gccgo65220
! Node: Import and Export71400
! Node: Compiler Directives72996
! Node: C Interoperability74980
! Node: C Type Interoperability75567
! Node: Function Names78126
! Node: Index80130
  
  End Tag Table
  
--- 1654,1669 ----
  
  
  Tag Table:
! Node: Top1686
! Node: Copying2554
! Node: GNU Free Documentation License40108
! Node: Invoking gccgo65244
! Node: Import and Export71660
! Node: Compiler Directives73316
! Node: C Interoperability75356
! Node: C Type Interoperability75955
! Node: Function Names78590
! Node: Index80662
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/doc/gccinstall.info gcc-13.5.0-RC-20260904/gcc/doc/gccinstall.info
*** gcc-13.4.0/gcc/doc/gccinstall.info	Thu Jun  5 16:21:56 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gccinstall.info	Fri Sep  4 07:50:36 2026
***************
*** 1,7 ****
! This is gccinstall.info, produced by makeinfo version 6.8 from
  install.texi.
  
! Copyright (C) 1988-2023 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
--- 1,7 ----
! This is gccinstall.info, produced by makeinfo version 7.1 from
  install.texi.
  
! Copyright © 1988-2023 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
*************** START-INFO-DIR-ENTRY
*** 24,30 ****
  * gccinstall: (gccinstall).    Installing the GNU Compiler Collection.
  END-INFO-DIR-ENTRY
  
!    Copyright (C) 1988-2023 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
--- 24,30 ----
  * gccinstall: (gccinstall).    Installing the GNU Compiler Collection.
  END-INFO-DIR-ENTRY
  
!    Copyright © 1988-2023 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
*************** information becomes available.
*** 95,101 ****
  * Testing:: (optional)
  * Final install::
  
!    Please note that GCC does not support 'make uninstall' and probably
  won't do so in the near future as this would open a can of worms.
  Instead, we suggest that you install GCC into a directory of its own and
  simply remove that directory when you do not need that specific version
--- 95,101 ----
  * Testing:: (optional)
  * Final install::
  
!    Please note that GCC does not support ‘make uninstall’ and probably
  won't do so in the near future as this would open a can of worms.
  Instead, we suggest that you install GCC into a directory of its own and
  simply remove that directory when you do not need that specific version
*************** C standard library and headers
*** 136,157 ****
       present for all target variants for which target libraries will be
       built (and not only the variant of the host C++ compiler).
  
!      This affects the popular 'x86_64-pc-linux-gnu' platform (among
!      other multilib targets), for which 64-bit ('x86_64') and 32-bit
!      ('i386') libc headers are usually packaged separately.  If you do a
!      build of a native compiler on 'x86_64-pc-linux-gnu', make sure you
       either have the 32-bit libc developer package properly installed
       (the exact name of the package depends on your distro) or you must
       build GCC as a 64-bit only compiler by configuring with the option
!      '--disable-multilib'.  Otherwise, you may encounter an error such
!      as 'fatal error: gnu/stubs-32.h: No such file'
  
  GNAT
  
       In order to build GNAT, the Ada compiler, you need a working GNAT
       compiler (GCC version 5.1 or later).
  
!      This includes GNAT tools such as 'gnatmake' and 'gnatlink', since
       the Ada front end is written in Ada and uses some GNAT-specific
       extensions.
  
--- 136,157 ----
       present for all target variants for which target libraries will be
       built (and not only the variant of the host C++ compiler).
  
!      This affects the popular ‘x86_64-pc-linux-gnu’ platform (among
!      other multilib targets), for which 64-bit (‘x86_64’) and 32-bit
!      (‘i386’) libc headers are usually packaged separately.  If you do a
!      build of a native compiler on ‘x86_64-pc-linux-gnu’, make sure you
       either have the 32-bit libc developer package properly installed
       (the exact name of the package depends on your distro) or you must
       build GCC as a 64-bit only compiler by configuring with the option
!      ‘--disable-multilib’.  Otherwise, you may encounter an error such
!      as ‘fatal error: gnu/stubs-32.h: No such file’
  
  GNAT
  
       In order to build GNAT, the Ada compiler, you need a working GNAT
       compiler (GCC version 5.1 or later).
  
!      This includes GNAT tools such as ‘gnatmake’ and ‘gnatlink’, since
       the Ada front end is written in Ada and uses some GNAT-specific
       extensions.
  
*************** GNAT
*** 166,187 ****
       built are not guaranteed to work and will often fail during the
       build with compilation errors.
  
!      Note that 'configure' does not test whether the GNAT installation
       works and has a sufficiently recent version; if too old a GNAT
!      version is installed and '--enable-languages=ada' is used, the
       build will fail.
  
!      'ADA_INCLUDE_PATH' and 'ADA_OBJECT_PATH' environment variables must
       not be set when building the Ada compiler, the Ada tools, or the
       Ada runtime libraries.  You can check that your build environment
!      is clean by verifying that 'gnatls -v' lists only one explicit path
       in each section.
  
  GDC
  
       In order to build GDC, the D compiler, you need a working GDC
       compiler (GCC version 9.4 or later) and D runtime library,
!      'libphobos', as the D front end is written in D.
  
       Versions of GDC prior to 12 can be built with an ISO C++11
       compiler, which can then be installed and used to bootstrap newer
--- 166,187 ----
       built are not guaranteed to work and will often fail during the
       build with compilation errors.
  
!      Note that ‘configure’ does not test whether the GNAT installation
       works and has a sufficiently recent version; if too old a GNAT
!      version is installed and ‘--enable-languages=ada’ is used, the
       build will fail.
  
!      ‘ADA_INCLUDE_PATH’ and ‘ADA_OBJECT_PATH’ environment variables must
       not be set when building the Ada compiler, the Ada tools, or the
       Ada runtime libraries.  You can check that your build environment
!      is clean by verifying that ‘gnatls -v’ lists only one explicit path
       in each section.
  
  GDC
  
       In order to build GDC, the D compiler, you need a working GDC
       compiler (GCC version 9.4 or later) and D runtime library,
!      ‘libphobos’, as the D front end is written in D.
  
       Versions of GDC prior to 12 can be built with an ISO C++11
       compiler, which can then be installed and used to bootstrap newer
*************** GDC
*** 192,229 ****
       guaranteed to work and will often fail during the build with
       compilation errors relating to deprecations or removed features.
  
!      Note that 'configure' does not test whether the GDC installation
       works and has a sufficiently recent version.  Though the
       implementation of the D front end does not make use of any
       GDC-specific extensions, or novel features of the D language, if
!      too old a GDC version is installed and '--enable-languages=d' is
       used, the build will fail.
  
!      On some targets, 'libphobos' isn't enabled by default, but compiles
!      and works if '--enable-libphobos' is used.  Specifics are
       documented for affected targets.
  
  GM2
  
       Python3 is required if you want to build the complete Modula-2
!      documentation including the target 'SYSTEM' definition module.  If
       Python3 is unavailable Modula-2 documentation will include a target
       independent version of the SYSTEM modules.
  
  A "working" POSIX compatible shell, or GNU bash
  
!      Necessary when running 'configure' because some '/bin/sh' shells
       have bugs and may crash when configuring the target libraries.  In
!      other cases, '/bin/sh' or 'ksh' have disastrous corner-case
!      performance problems.  This can cause target 'configure' runs to
       literally take days to complete in some cases.
  
!      So on some platforms '/bin/ksh' is sufficient, on others it isn't.
       See the host/target specific instructions for your platform, or use
!      'bash' to be sure.  Then set 'CONFIG_SHELL' in your environment to
!      your "good" shell prior to running 'configure'/'make'.
  
!      'zsh' is not a fully compliant POSIX shell and will not work when
       configuring GCC.
  
  A POSIX or SVR4 awk
--- 192,229 ----
       guaranteed to work and will often fail during the build with
       compilation errors relating to deprecations or removed features.
  
!      Note that ‘configure’ does not test whether the GDC installation
       works and has a sufficiently recent version.  Though the
       implementation of the D front end does not make use of any
       GDC-specific extensions, or novel features of the D language, if
!      too old a GDC version is installed and ‘--enable-languages=d’ is
       used, the build will fail.
  
!      On some targets, ‘libphobos’ isn't enabled by default, but compiles
!      and works if ‘--enable-libphobos’ is used.  Specifics are
       documented for affected targets.
  
  GM2
  
       Python3 is required if you want to build the complete Modula-2
!      documentation including the target ‘SYSTEM’ definition module.  If
       Python3 is unavailable Modula-2 documentation will include a target
       independent version of the SYSTEM modules.
  
  A "working" POSIX compatible shell, or GNU bash
  
!      Necessary when running ‘configure’ because some ‘/bin/sh’ shells
       have bugs and may crash when configuring the target libraries.  In
!      other cases, ‘/bin/sh’ or ‘ksh’ have disastrous corner-case
!      performance problems.  This can cause target ‘configure’ runs to
       literally take days to complete in some cases.
  
!      So on some platforms ‘/bin/ksh’ is sufficient, on others it isn't.
       See the host/target specific instructions for your platform, or use
!      ‘bash’ to be sure.  Then set ‘CONFIG_SHELL’ in your environment to
!      your "good" shell prior to running ‘configure’/‘make’.
  
!      ‘zsh’ is not a fully compliant POSIX shell and will not work when
       configuring GCC.
  
  A POSIX or SVR4 awk
*************** GNU binutils
*** 244,250 ****
  gzip version 1.2.4 (or later) or
  bzip2 version 1.0.2 (or later)
  
!      Necessary to uncompress GCC 'tar' files when source code is
       obtained via HTTPS mirror sites.
  
  GNU make version 3.80 (or later)
--- 244,250 ----
  gzip version 1.2.4 (or later) or
  bzip2 version 1.0.2 (or later)
  
!      Necessary to uncompress GCC ‘tar’ files when source code is
       obtained via HTTPS mirror sites.
  
  GNU make version 3.80 (or later)
*************** GNU make version 3.80 (or later)
*** 254,278 ****
  GNU tar version 1.14 (or later)
  
       Necessary (only on some platforms) to untar the source code.  Many
!      systems' 'tar' programs will also work, only try GNU 'tar' if you
       have problems.
  
  Perl version between 5.6.1 and 5.6.24
  
!      Necessary when targeting Darwin, building 'libstdc++', and not
!      using '--disable-symvers'.  Necessary when targeting Solaris with
!      Solaris 'ld' and not using '--disable-symvers'.
  
!      Necessary when regenerating 'Makefile' dependencies in libiberty.
!      Necessary when regenerating 'libiberty/functions.texi'.  Necessary
       when generating manpages from Texinfo manuals.  Used by various
       scripts to generate some files included in the source repository
       (mainly Unicode-related and rarely changing) from source tables.
  
!      Used by 'automake'.
  
!      If available, enables parallel testing of 'libgomp' in case that
!      'flock' is not available.
  
     Several support libraries are necessary to build GCC, some are
  required, others optional.  While any sufficiently new version of
--- 254,278 ----
  GNU tar version 1.14 (or later)
  
       Necessary (only on some platforms) to untar the source code.  Many
!      systems' ‘tar’ programs will also work, only try GNU ‘tar’ if you
       have problems.
  
  Perl version between 5.6.1 and 5.6.24
  
!      Necessary when targeting Darwin, building ‘libstdc++’, and not
!      using ‘--disable-symvers’.  Necessary when targeting Solaris with
!      Solaris ‘ld’ and not using ‘--disable-symvers’.
  
!      Necessary when regenerating ‘Makefile’ dependencies in libiberty.
!      Necessary when regenerating ‘libiberty/functions.texi’.  Necessary
       when generating manpages from Texinfo manuals.  Used by various
       scripts to generate some files included in the source repository
       (mainly Unicode-related and rarely changing) from source tables.
  
!      Used by ‘automake’.
  
!      If available, enables parallel testing of ‘libgomp’ in case that
!      ‘flock’ is not available.
  
     Several support libraries are necessary to build GCC, some are
  required, others optional.  While any sufficiently new version of
*************** GNU Multiple Precision Library (GMP) ver
*** 287,308 ****
  
       Necessary to build GCC.  It can be downloaded from
       .  If a GMP source distribution is found in a
!      subdirectory of your GCC sources named 'gmp', it will be built
       together with GCC. Alternatively, if GMP is already installed but
       it is not in your library search path, you will have to configure
!      with the '--with-gmp' configure option.  See also '--with-gmp-lib'
!      and '--with-gmp-include'.  The in-tree build is only supported with
       the GMP version that download_prerequisites installs.
  
  MPFR Library version 3.1.0 (or later)
  
       Necessary to build GCC.  It can be downloaded from
       .  If an MPFR source distribution is found in
!      a subdirectory of your GCC sources named 'mpfr', it will be built
       together with GCC. Alternatively, if MPFR is already installed but
!      it is not in your default library search path, the '--with-mpfr'
!      configure option should be used.  See also '--with-mpfr-lib' and
!      '--with-mpfr-include'.  The in-tree build is only supported with
       the MPFR version that download_prerequisites installs.
  
  MPC Library version 1.0.1 (or later)
--- 287,308 ----
  
       Necessary to build GCC.  It can be downloaded from
       .  If a GMP source distribution is found in a
!      subdirectory of your GCC sources named ‘gmp’, it will be built
       together with GCC. Alternatively, if GMP is already installed but
       it is not in your library search path, you will have to configure
!      with the ‘--with-gmp’ configure option.  See also ‘--with-gmp-lib’
!      and ‘--with-gmp-include’.  The in-tree build is only supported with
       the GMP version that download_prerequisites installs.
  
  MPFR Library version 3.1.0 (or later)
  
       Necessary to build GCC.  It can be downloaded from
       .  If an MPFR source distribution is found in
!      a subdirectory of your GCC sources named ‘mpfr’, it will be built
       together with GCC. Alternatively, if MPFR is already installed but
!      it is not in your default library search path, the ‘--with-mpfr’
!      configure option should be used.  See also ‘--with-mpfr-lib’ and
!      ‘--with-mpfr-include’.  The in-tree build is only supported with
       the MPFR version that download_prerequisites installs.
  
  MPC Library version 1.0.1 (or later)
*************** MPC Library version 1.0.1 (or later)
*** 310,319 ****
       Necessary to build GCC.  It can be downloaded from
       .  If an MPC source
       distribution is found in a subdirectory of your GCC sources named
!      'mpc', it will be built together with GCC. Alternatively, if MPC is
       already installed but it is not in your default library search
!      path, the '--with-mpc' configure option should be used.  See also
!      '--with-mpc-lib' and '--with-mpc-include'.  The in-tree build is
       only supported with the MPC version that download_prerequisites
       installs.
  
--- 310,319 ----
       Necessary to build GCC.  It can be downloaded from
       .  If an MPC source
       distribution is found in a subdirectory of your GCC sources named
!      ‘mpc’, it will be built together with GCC. Alternatively, if MPC is
       already installed but it is not in your default library search
!      path, the ‘--with-mpc’ configure option should be used.  See also
!      ‘--with-mpc-lib’ and ‘--with-mpc-include’.  The in-tree build is
       only supported with the MPC version that download_prerequisites
       installs.
  
*************** isl Library version 0.15 or later.
*** 323,337 ****
       can be downloaded from
       .  If an isl source
       distribution is found in a subdirectory of your GCC sources named
!      'isl', it will be built together with GCC. Alternatively, the
!      '--with-isl' configure option should be used if isl is not
       installed in your default library search path.
  
  zstd Library.
  
       Necessary to build GCC with zstd compression used for LTO bytecode.
       The library is searched in your default library patch search.
!      Alternatively, the '--with-zstd' configure option should be used.
  
  Python3 modules
  
--- 323,337 ----
       can be downloaded from
       .  If an isl source
       distribution is found in a subdirectory of your GCC sources named
!      ‘isl’, it will be built together with GCC. Alternatively, the
!      ‘--with-isl’ configure option should be used if isl is not
       installed in your default library search path.
  
  zstd Library.
  
       Necessary to build GCC with zstd compression used for LTO bytecode.
       The library is searched in your default library patch search.
!      Alternatively, the ‘--with-zstd’ configure option should be used.
  
  Python3 modules
  
*************** Python3 modules
*** 339,361 ****
       subcomponent is shown below:
  
       internal debugging in gdbhooks
!           'gdb', 'gdb.printing', 'gdb.types', 'os.path', 're', 'sys' and
!           'tempfile',
  
       g++ testsuite
!           'gcov', 'gzip', 'json', 'os' and 'pytest'.
  
       c++ cxx api generation
!           'csv', 'os', 'sys' and 'time'.
  
       modula-2 documentation
!           'argparse', 'os', 'pathlib', 'shutil' and 'sys'.
  
       git developer tools
!           'os' and 'sys'.
  
       ada documentation
!           'latex_elements', 'os', 'pygments', 're', 'sys' and 'time'.
  
  Tools/packages necessary for modifying GCC
  ==========================================
--- 339,361 ----
       subcomponent is shown below:
  
       internal debugging in gdbhooks
!           ‘gdb’, ‘gdb.printing’, ‘gdb.types’, ‘os.path’, ‘re’, ‘sys’ and
!           ‘tempfile’,
  
       g++ testsuite
!           ‘gcov’, ‘gzip’, ‘json’, ‘os’ and ‘pytest’.
  
       c++ cxx api generation
!           ‘csv’, ‘os’, ‘sys’ and ‘time’.
  
       modula-2 documentation
!           ‘argparse’, ‘os’, ‘pathlib’, ‘shutil’ and ‘sys’.
  
       git developer tools
!           ‘os’ and ‘sys’.
  
       ada documentation
!           ‘latex_elements’, ‘os’, ‘pygments’, ‘re’, ‘sys’ and ‘time’.
  
  Tools/packages necessary for modifying GCC
  ==========================================
*************** Tools/packages necessary for modifying G
*** 363,379 ****
  autoconf version 2.69
  GNU m4 version 1.4.6 (or later)
  
!      Necessary when modifying 'configure.ac', 'aclocal.m4', etc. to
!      regenerate 'configure' and 'config.in' files.
  
  automake version 1.15.1
  
!      Necessary when modifying a 'Makefile.am' file to regenerate its
!      associated 'Makefile.in'.
  
       Much of GCC does not use automake, so directly edit the
!      'Makefile.in' file.  Specifically this applies to the 'gcc',
!      'intl', 'libcpp', 'libiberty', 'libobjc' directories as well as any
       of their subdirectories.
  
       For directories that use automake, GCC requires the latest release
--- 363,379 ----
  autoconf version 2.69
  GNU m4 version 1.4.6 (or later)
  
!      Necessary when modifying ‘configure.ac’, ‘aclocal.m4’, etc. to
!      regenerate ‘configure’ and ‘config.in’ files.
  
  automake version 1.15.1
  
!      Necessary when modifying a ‘Makefile.am’ file to regenerate its
!      associated ‘Makefile.in’.
  
       Much of GCC does not use automake, so directly edit the
!      ‘Makefile.in’ file.  Specifically this applies to the ‘gcc’,
!      ‘intl’, ‘libcpp’, ‘libiberty’, ‘libobjc’ directories as well as any
       of their subdirectories.
  
       For directories that use automake, GCC requires the latest release
*************** automake version 1.15.1
*** 383,395 ****
  
  gettext version 0.14.5 (or later)
  
!      Needed to regenerate 'gcc.pot'.
  
  gperf version 2.7.2 (or later)
  
!      Necessary when modifying 'gperf' input files, e.g.
!      'gcc/cp/cfns.gperf' to regenerate its associated header file, e.g.
!      'gcc/cp/cfns.h'.
  
  DejaGnu version 1.5.3 (or later)
  Expect
--- 383,395 ----
  
  gettext version 0.14.5 (or later)
  
!      Needed to regenerate ‘gcc.pot’.
  
  gperf version 2.7.2 (or later)
  
!      Necessary when modifying ‘gperf’ input files, e.g.
!      ‘gcc/cp/cfns.gperf’ to regenerate its associated header file, e.g.
!      ‘gcc/cp/cfns.h’.
  
  DejaGnu version 1.5.3 (or later)
  Expect
*************** Tcl
*** 401,417 ****
  autogen version 5.5.4 (or later) and
  guile version 1.4.1 (or later)
  
!      Necessary to regenerate 'fixinc/fixincl.x' from
!      'fixinc/inclhack.def' and 'fixinc/*.tpl'.
  
!      Necessary to run 'make check' for 'fixinc'.
  
!      Necessary to regenerate the top level 'Makefile.in' file from
!      'Makefile.tpl' and 'Makefile.def'.
  
  Flex version 2.5.4 (or later)
  
!      Necessary when modifying '*.l' files.
  
       Necessary to build GCC during development because the generated
       output files are not included in the version-controlled source
--- 401,417 ----
  autogen version 5.5.4 (or later) and
  guile version 1.4.1 (or later)
  
!      Necessary to regenerate ‘fixinc/fixincl.x’ from
!      ‘fixinc/inclhack.def’ and ‘fixinc/*.tpl’.
  
!      Necessary to run ‘make check’ for ‘fixinc’.
  
!      Necessary to regenerate the top level ‘Makefile.in’ file from
!      ‘Makefile.tpl’ and ‘Makefile.def’.
  
  Flex version 2.5.4 (or later)
  
!      Necessary when modifying ‘*.l’ files.
  
       Necessary to build GCC during development because the generated
       output files are not included in the version-controlled source
*************** Flex version 2.5.4 (or later)
*** 419,430 ****
  
  Texinfo version 4.7 (or later)
  
!      Necessary for running 'makeinfo' when modifying '*.texi' files to
       test your changes.
  
!      Necessary for running 'make dvi', 'make pdf', or 'make html' to
       create formatted documentation.  Texinfo version 4.8 or later is
!      required for 'make pdf'.
  
       Necessary to build GCC documentation in info format during
       development because the generated output files are not included in
--- 419,430 ----
  
  Texinfo version 4.7 (or later)
  
!      Necessary for running ‘makeinfo’ when modifying ‘*.texi’ files to
       test your changes.
  
!      Necessary for running ‘make dvi’, ‘make pdf’, or ‘make html’ to
       create formatted documentation.  Texinfo version 4.8 or later is
!      required for ‘make pdf’.
  
       Necessary to build GCC documentation in info format during
       development because the generated output files are not included in
*************** Texinfo version 4.7 (or later)
*** 440,453 ****
  
  TeX (any working version)
  
!      Necessary for running 'texi2dvi' and 'texi2pdf', which are used
!      when running 'make dvi' or 'make pdf' to create DVI or PDF files,
       respectively.
  
  Sphinx version 1.0 (or later)
  
!      Necessary to regenerate 'jit/docs/_build/texinfo' from the '.rst'
!      files in the directories below 'jit/docs'.
  
  git (any version)
  SSH (any version)
--- 440,453 ----
  
  TeX (any working version)
  
!      Necessary for running ‘texi2dvi’ and ‘texi2pdf’, which are used
!      when running ‘make dvi’ or ‘make pdf’ to create DVI or PDF files,
       respectively.
  
  Sphinx version 1.0 (or later)
  
!      Necessary to regenerate ‘jit/docs/_build/texinfo’ from the ‘.rst’
!      files in the directories below ‘jit/docs’.
  
  git (any version)
  SSH (any version)
*************** GNU diffutils version 2.7 (or later)
*** 462,468 ****
  
  patch version 2.5.4 (or later)
  
!      Necessary when applying patches, created with 'diff', to one's own
       sources.
  
  
--- 462,468 ----
  
  patch version 2.5.4 (or later)
  
!      Necessary when applying patches, created with ‘diff’, to one's own
       sources.
  
  
*************** File: gccinstall.info,  Node: Downloadin
*** 472,478 ****
  *****************
  
  GCC is distributed via git and via HTTPS as tarballs compressed with
! 'gzip' or 'bzip2'.
  
     Please refer to the releases web page for information on how to
  obtain GCC.
--- 472,478 ----
  *****************
  
  GCC is distributed via git and via HTTPS as tarballs compressed with
! ‘gzip’ or ‘bzip2’.
  
     Please refer to the releases web page for information on how to
  obtain GCC.
*************** front end and the language runtime (wher
*** 489,504 ****
  installation or for use in place of the corresponding tools of your OS),
  unpack the binutils distribution either in the same directory or a
  separate one.  In the latter case, add symbolic links to any components
! of the binutils you intend to build alongside the compiler ('bfd',
! 'binutils', 'gas', 'gprof', 'ld', 'opcodes', ...) to the directory
  containing the GCC sources.
  
     Likewise the GMP, MPFR and MPC libraries can be automatically built
  together with GCC. You may simply run the
! 'contrib/download_prerequisites' script in the GCC source directory to
  set up everything.  Otherwise unpack the GMP, MPFR and/or MPC source
  distributions in the directory containing the GCC sources and rename
! their directories to 'gmp', 'mpfr' and 'mpc', respectively (or use
  symbolic links with the same name).
  
  
--- 489,504 ----
  installation or for use in place of the corresponding tools of your OS),
  unpack the binutils distribution either in the same directory or a
  separate one.  In the latter case, add symbolic links to any components
! of the binutils you intend to build alongside the compiler (‘bfd’,
! ‘binutils’, ‘gas’, ‘gprof’, ‘ld’, ‘opcodes’, ...) to the directory
  containing the GCC sources.
  
     Likewise the GMP, MPFR and MPC libraries can be automatically built
  together with GCC. You may simply run the
! ‘contrib/download_prerequisites’ script in the GCC source directory to
  set up everything.  Otherwise unpack the GMP, MPFR and/or MPC source
  distributions in the directory containing the GCC sources and rename
! their directories to ‘gmp’, ‘mpfr’ and ‘mpc’, respectively (or use
  symbolic links with the same name).
  
  
*************** native and cross targets.
*** 515,529 ****
  use OBJDIR to refer to the toplevel build/object directory.
  
     If you obtained the sources by cloning the repository, SRCDIR must
! refer to the top 'gcc' directory, the one where the 'MAINTAINERS' file
! can be found, and not its 'gcc' subdirectory, otherwise the build will
  fail.
  
     If either SRCDIR or OBJDIR is located on an automounted NFS file
! system, the shell's built-in 'pwd' command will return temporary
  pathnames.  Using these can lead to various sorts of build problems.  To
! avoid this issue, set the 'PWDCMD' environment variable to an
! automounter-aware 'pwd' command, e.g., 'pawd' or 'amq -w', during the
  configuration and build phases.
  
     First, we *highly* recommend that GCC be built into a separate
--- 515,529 ----
  use OBJDIR to refer to the toplevel build/object directory.
  
     If you obtained the sources by cloning the repository, SRCDIR must
! refer to the top ‘gcc’ directory, the one where the ‘MAINTAINERS’ file
! can be found, and not its ‘gcc’ subdirectory, otherwise the build will
  fail.
  
     If either SRCDIR or OBJDIR is located on an automounted NFS file
! system, the shell's built-in ‘pwd’ command will return temporary
  pathnames.  Using these can lead to various sorts of build problems.  To
! avoid this issue, set the ‘PWDCMD’ environment variable to an
! automounter-aware ‘pwd’ command, e.g., ‘pawd’ or ‘amq -w’, during the
  configuration and build phases.
  
     First, we *highly* recommend that GCC be built into a separate
*************** OBJDIR should still work, but doesn't ge
*** 533,548 ****
  where OBJDIR is a subdirectory of SRCDIR is unsupported.
  
     If you have previously built GCC in the same directory for a
! different target machine, do 'make distclean' to delete all files that
! might be invalid.  One of the files this deletes is 'Makefile'; if 'make
! distclean' complains that 'Makefile' does not exist or issues a message
  like "don't know how to make distclean" it probably means that the
  directory is already suitably clean.  However, with the recommended
  method of building in a separate OBJDIR, you should simply use a
  different OBJDIR for each target.
  
!    Second, when configuring a native system, either 'cc' or 'gcc' must
! be in your path or you must set 'CC' in your environment before running
  configure.  Otherwise the configuration scripts may fail.
  
     To configure GCC:
--- 533,548 ----
  where OBJDIR is a subdirectory of SRCDIR is unsupported.
  
     If you have previously built GCC in the same directory for a
! different target machine, do ‘make distclean’ to delete all files that
! might be invalid.  One of the files this deletes is ‘Makefile’; if ‘make
! distclean’ complains that ‘Makefile’ does not exist or issues a message
  like "don't know how to make distclean" it probably means that the
  directory is already suitably clean.  However, with the recommended
  method of building in a separate OBJDIR, you should simply use a
  different OBJDIR for each target.
  
!    Second, when configuring a native system, either ‘cc’ or ‘gcc’ must
! be in your path or you must set ‘CC’ in your environment before running
  configure.  Otherwise the configuration scripts may fail.
  
     To configure GCC:
*************** If you will be distributing binary versi
*** 558,572 ****
  to the source code, you should use the options described in this section
  to make clear that your version contains modifications.
  
! '--with-pkgversion=VERSION'
       Specify a string that identifies your package.  You may wish to
       include a build number or build date.  This version string will be
!      included in the output of 'gcc --version'.  This suffix does not
!      replace the default version string, only the 'GCC' part.
  
!      The default value is 'GCC'.
  
! '--with-bugurl=URL'
       Specify the URL that users should visit if they wish to report a
       bug.  You are of course welcome to forward bugs reported to you to
       the FSF, if you determine that they are not bugs in your
--- 558,572 ----
  to the source code, you should use the options described in this section
  to make clear that your version contains modifications.
  
! ‘--with-pkgversion=VERSION’
       Specify a string that identifies your package.  You may wish to
       include a build number or build date.  This version string will be
!      included in the output of ‘gcc --version’.  This suffix does not
!      replace the default version string, only the ‘GCC’ part.
  
!      The default value is ‘GCC’.
  
! ‘--with-bugurl=URL’
       Specify the URL that users should visit if they wish to report a
       bug.  You are of course welcome to forward bugs reported to you to
       the FSF, if you determine that they are not bugs in your
*************** to make clear that your version contains
*** 574,589 ****
  
       The default value refers to the FSF's GCC bug tracker.
  
! '--with-documentation-root-url=URL'
       Specify the URL root that contains GCC option documentation.  The
!      URL should end with a '/' character.
  
       The default value is https://gcc.gnu.org/onlinedocs/.
  
! '--with-changes-root-url=URL'
       Specify the URL root that contains information about changes in GCC
!      releases like 'gcc-VERSION/changes.html'.  The URL should end with
!      a '/' character.
  
       The default value is https://gcc.gnu.org/.
  
--- 574,589 ----
  
       The default value refers to the FSF's GCC bug tracker.
  
! ‘--with-documentation-root-url=URL’
       Specify the URL root that contains GCC option documentation.  The
!      URL should end with a ‘/’ character.
  
       The default value is https://gcc.gnu.org/onlinedocs/.
  
! ‘--with-changes-root-url=URL’
       Specify the URL root that contains information about changes in GCC
!      releases like ‘gcc-VERSION/changes.html’.  The URL should end with
!      a ‘/’ character.
  
       The default value is https://gcc.gnu.org/.
  
*************** Host, Build and Target specification
*** 591,613 ****
  ====================================
  
  Specify the host, build and target machine configurations.  You do this
! when you run the 'configure' script.
  
!    The "build" machine is the system which you are using, the "host"
  machine is the system where you want to run the resulting compiler
! (normally the build machine), and the "target" machine is the system for
  which you want the compiler to generate code.
  
     If you are building a compiler to produce code for the machine it
  runs on (a native compiler), you normally do not need to specify any
! operands to 'configure'; it will try to guess the type of machine you
  are on and use that as the build, host and target machines.  So you
  don't need to specify a configuration when building a native compiler
! unless 'configure' cannot figure out what your configuration is or
  guesses wrong.
  
!    In those cases, specify the build machine's "configuration name" with
! the '--host' option; the host and target will default to be the same as
  the host machine.
  
     Here is an example:
--- 591,613 ----
  ====================================
  
  Specify the host, build and target machine configurations.  You do this
! when you run the ‘configure’ script.
  
!    The “build” machine is the system which you are using, the “host”
  machine is the system where you want to run the resulting compiler
! (normally the build machine), and the “target” machine is the system for
  which you want the compiler to generate code.
  
     If you are building a compiler to produce code for the machine it
  runs on (a native compiler), you normally do not need to specify any
! operands to ‘configure’; it will try to guess the type of machine you
  are on and use that as the build, host and target machines.  So you
  don't need to specify a configuration when building a native compiler
! unless ‘configure’ cannot figure out what your configuration is or
  guesses wrong.
  
!    In those cases, specify the build machine's “configuration name” with
! the ‘--host’ option; the host and target will default to be the same as
  the host machine.
  
     Here is an example:
*************** the host machine.
*** 615,624 ****
       ./configure --host=x86_64-pc-linux-gnu
  
     A configuration name may be canonical or it may be more or less
! abbreviated ('config.sub' script produces canonical versions).
  
     A canonical configuration name has three parts, separated by dashes.
! It looks like this: 'CPU-COMPANY-SYSTEM'.
  
     Here are the possible CPU types:
  
--- 615,624 ----
       ./configure --host=x86_64-pc-linux-gnu
  
     A configuration name may be canonical or it may be more or less
! abbreviated (‘config.sub’ script produces canonical versions).
  
     A canonical configuration name has three parts, separated by dashes.
! It looks like this: ‘CPU-COMPANY-SYSTEM’.
  
     Here are the possible CPU types:
  
*************** Options specification
*** 650,767 ****
  =====================
  
  Use OPTIONS to override several configure time options for GCC.  A list
! of supported OPTIONS follows; 'configure --help' may list other options,
  but those not listed below may not work and should not normally be used.
  
!    Note that each '--enable' option has a corresponding '--disable'
! option and that each '--with' option has a corresponding '--without'
  option.
  
! '--prefix=DIRNAME'
       Specify the toplevel installation directory.  This is the
       recommended way to install the tools into a directory other than
       the default.  The toplevel installation directory defaults to
!      '/usr/local'.
  
       We *highly* recommend against DIRNAME being the same or a
       subdirectory of OBJDIR or vice versa.  If specifying a directory
       beneath a user's home directory tree, some shells will not expand
!      DIRNAME correctly if it contains the '~' metacharacter; use '$HOME'
       instead.
  
!      The following standard 'autoconf' options are supported.  Normally
       you should not need to use these options.
!      '--exec-prefix=DIRNAME'
            Specify the toplevel installation directory for
!           architecture-dependent files.  The default is 'PREFIX'.
  
!      '--bindir=DIRNAME'
            Specify the installation directory for the executables called
!           by users (such as 'gcc' and 'g++').  The default is
!           'EXEC-PREFIX/bin'.
  
!      '--libdir=DIRNAME'
            Specify the installation directory for object code libraries
            and internal data files of GCC.  The default is
!           'EXEC-PREFIX/lib'.
  
!      '--libexecdir=DIRNAME'
            Specify the installation directory for internal executables of
!           GCC.  The default is 'EXEC-PREFIX/libexec'.
  
!      '--with-slibdir=DIRNAME'
            Specify the installation directory for the shared libgcc
!           library.  The default is 'LIBDIR'.
  
!      '--datarootdir=DIRNAME'
            Specify the root of the directory tree for read-only
            architecture-independent data files referenced by GCC.  The
!           default is 'PREFIX/share'.
  
!      '--infodir=DIRNAME'
            Specify the installation directory for documentation in info
!           format.  The default is 'DATAROOTDIR/info'.
  
!      '--datadir=DIRNAME'
            Specify the installation directory for some
            architecture-independent data files referenced by GCC.  The
!           default is 'DATAROOTDIR'.
  
!      '--docdir=DIRNAME'
            Specify the installation directory for documentation files
!           (other than Info) for GCC.  The default is 'DATAROOTDIR/doc'.
  
!      '--htmldir=DIRNAME'
            Specify the installation directory for HTML documentation
!           files.  The default is 'DOCDIR'.
  
!      '--pdfdir=DIRNAME'
            Specify the installation directory for PDF documentation
!           files.  The default is 'DOCDIR'.
  
!      '--mandir=DIRNAME'
            Specify the installation directory for manual pages.  The
!           default is 'DATAROOTDIR/man'.  (Note that the manual pages are
            only extracts from the full GCC manuals, which are provided in
            Texinfo format.  The manpages are derived by an automatic
            conversion process from parts of the full manual.)
  
!      '--with-gxx-include-dir=DIRNAME'
            Specify the installation directory for G++ header files.  The
            default depends on other configuration options, and differs
            between cross and native configurations.
  
!      '--with-specs=SPECS'
            Specify additional command line driver SPECS. This can be
            useful if you need to turn on a non-standard feature by
            default without modifying the compiler's source code, for
            instance
!           '--with-specs=%{!fcommon:%{!fno-common:-fno-common}}'.  *Note
            Specifying subprocesses and the switches to pass to them:
            (gcc)Spec Files,
  
! '--program-prefix=PREFIX'
       GCC supports some transformations of the names of its programs when
       installing them.  This option prepends PREFIX to the names of
       programs to install in BINDIR (see above).  For example, specifying
!      '--program-prefix=foo-' would result in 'gcc' being installed as
!      '/usr/local/bin/foo-gcc'.
  
! '--program-suffix=SUFFIX'
       Appends SUFFIX to the names of programs to install in BINDIR (see
!      above).  For example, specifying '--program-suffix=-3.1' would
!      result in 'gcc' being installed as '/usr/local/bin/gcc-3.1'.
  
! '--program-transform-name=PATTERN'
!      Applies the 'sed' script PATTERN to be applied to the names of
       programs to install in BINDIR (see above).  PATTERN has to consist
!      of one or more basic 'sed' editing commands, separated by
!      semicolons.  For example, if you want the 'gcc' program name to be
!      transformed to the installed program '/usr/local/bin/myowngcc' and
!      the 'g++' program name to be transformed to
!      '/usr/local/bin/gspecial++' without changing other program names,
       you could use the pattern
!      '--program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/''
       to achieve this effect.
  
       All three options can be combined and used together, resulting in
--- 650,767 ----
  =====================
  
  Use OPTIONS to override several configure time options for GCC.  A list
! of supported OPTIONS follows; ‘configure --help’ may list other options,
  but those not listed below may not work and should not normally be used.
  
!    Note that each ‘--enable’ option has a corresponding ‘--disable’
! option and that each ‘--with’ option has a corresponding ‘--without’
  option.
  
! ‘--prefix=DIRNAME’
       Specify the toplevel installation directory.  This is the
       recommended way to install the tools into a directory other than
       the default.  The toplevel installation directory defaults to
!      ‘/usr/local’.
  
       We *highly* recommend against DIRNAME being the same or a
       subdirectory of OBJDIR or vice versa.  If specifying a directory
       beneath a user's home directory tree, some shells will not expand
!      DIRNAME correctly if it contains the ‘~’ metacharacter; use ‘$HOME’
       instead.
  
!      The following standard ‘autoconf’ options are supported.  Normally
       you should not need to use these options.
!      ‘--exec-prefix=DIRNAME’
            Specify the toplevel installation directory for
!           architecture-dependent files.  The default is ‘PREFIX’.
  
!      ‘--bindir=DIRNAME’
            Specify the installation directory for the executables called
!           by users (such as ‘gcc’ and ‘g++’).  The default is
!           ‘EXEC-PREFIX/bin’.
  
!      ‘--libdir=DIRNAME’
            Specify the installation directory for object code libraries
            and internal data files of GCC.  The default is
!           ‘EXEC-PREFIX/lib’.
  
!      ‘--libexecdir=DIRNAME’
            Specify the installation directory for internal executables of
!           GCC.  The default is ‘EXEC-PREFIX/libexec’.
  
!      ‘--with-slibdir=DIRNAME’
            Specify the installation directory for the shared libgcc
!           library.  The default is ‘LIBDIR’.
  
!      ‘--datarootdir=DIRNAME’
            Specify the root of the directory tree for read-only
            architecture-independent data files referenced by GCC.  The
!           default is ‘PREFIX/share’.
  
!      ‘--infodir=DIRNAME’
            Specify the installation directory for documentation in info
!           format.  The default is ‘DATAROOTDIR/info’.
  
!      ‘--datadir=DIRNAME’
            Specify the installation directory for some
            architecture-independent data files referenced by GCC.  The
!           default is ‘DATAROOTDIR’.
  
!      ‘--docdir=DIRNAME’
            Specify the installation directory for documentation files
!           (other than Info) for GCC.  The default is ‘DATAROOTDIR/doc’.
  
!      ‘--htmldir=DIRNAME’
            Specify the installation directory for HTML documentation
!           files.  The default is ‘DOCDIR’.
  
!      ‘--pdfdir=DIRNAME’
            Specify the installation directory for PDF documentation
!           files.  The default is ‘DOCDIR’.
  
!      ‘--mandir=DIRNAME’
            Specify the installation directory for manual pages.  The
!           default is ‘DATAROOTDIR/man’.  (Note that the manual pages are
            only extracts from the full GCC manuals, which are provided in
            Texinfo format.  The manpages are derived by an automatic
            conversion process from parts of the full manual.)
  
!      ‘--with-gxx-include-dir=DIRNAME’
            Specify the installation directory for G++ header files.  The
            default depends on other configuration options, and differs
            between cross and native configurations.
  
!      ‘--with-specs=SPECS’
            Specify additional command line driver SPECS. This can be
            useful if you need to turn on a non-standard feature by
            default without modifying the compiler's source code, for
            instance
!           ‘--with-specs=%{!fcommon:%{!fno-common:-fno-common}}’.  *Note
            Specifying subprocesses and the switches to pass to them:
            (gcc)Spec Files,
  
! ‘--program-prefix=PREFIX’
       GCC supports some transformations of the names of its programs when
       installing them.  This option prepends PREFIX to the names of
       programs to install in BINDIR (see above).  For example, specifying
!      ‘--program-prefix=foo-’ would result in ‘gcc’ being installed as
!      ‘/usr/local/bin/foo-gcc’.
  
! ‘--program-suffix=SUFFIX’
       Appends SUFFIX to the names of programs to install in BINDIR (see
!      above).  For example, specifying ‘--program-suffix=-3.1’ would
!      result in ‘gcc’ being installed as ‘/usr/local/bin/gcc-3.1’.
  
! ‘--program-transform-name=PATTERN’
!      Applies the ‘sed’ script PATTERN to be applied to the names of
       programs to install in BINDIR (see above).  PATTERN has to consist
!      of one or more basic ‘sed’ editing commands, separated by
!      semicolons.  For example, if you want the ‘gcc’ program name to be
!      transformed to the installed program ‘/usr/local/bin/myowngcc’ and
!      the ‘g++’ program name to be transformed to
!      ‘/usr/local/bin/gspecial++’ without changing other program names,
       you could use the pattern
!      ‘--program-transform-name='s/^gcc$/myowngcc/; s/^g++$/gspecial++/'’
       to achieve this effect.
  
       All three options can be combined and used together, resulting in
*************** option.
*** 776,810 ****
  
       For native builds, some of the installed programs are also
       installed with the target alias in front of their name, as in
!      'i686-pc-linux-gnu-gcc'.  All of the above transformations happen
       before the target alias is prepended to the name--so, specifying
!      '--program-prefix=foo-' and 'program-suffix=-3.1', the resulting
       binary would be installed as
!      '/usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1'.
  
       As a last shortcoming, none of the installed Ada programs are
       transformed yet, which will be fixed in some time.
  
! '--with-local-prefix=DIRNAME'
       Specify the installation directory for local include files.  The
!      default is '/usr/local'.  Specify this option if you want the
!      compiler to search directory 'DIRNAME/include' for locally
!      installed header files _instead_ of '/usr/local/include'.
  
!      You should specify '--with-local-prefix' *only* if your site has a
!      different convention (not '/usr/local') for where to put
       site-specific files.
  
!      The default value for '--with-local-prefix' is '/usr/local'
!      regardless of the value of '--prefix'.  Specifying '--prefix' has
       no effect on which directory GCC searches for local header files.
       This may seem counterintuitive, but actually it is logical.
  
!      The purpose of '--prefix' is to specify where to _install GCC_. The
!      local header files in '/usr/local/include'--if you put any in that
       directory--are not part of GCC.  They are part of other
       programs--perhaps many others.  (GCC installs its own header files
!      in another directory which is based on the '--prefix' value.)
  
       Both the local-prefix include directory and the GCC-prefix include
       directory are part of GCC's "system include" directories.  Although
--- 776,810 ----
  
       For native builds, some of the installed programs are also
       installed with the target alias in front of their name, as in
!      ‘i686-pc-linux-gnu-gcc’.  All of the above transformations happen
       before the target alias is prepended to the name--so, specifying
!      ‘--program-prefix=foo-’ and ‘program-suffix=-3.1’, the resulting
       binary would be installed as
!      ‘/usr/local/bin/i686-pc-linux-gnu-foo-gcc-3.1’.
  
       As a last shortcoming, none of the installed Ada programs are
       transformed yet, which will be fixed in some time.
  
! ‘--with-local-prefix=DIRNAME’
       Specify the installation directory for local include files.  The
!      default is ‘/usr/local’.  Specify this option if you want the
!      compiler to search directory ‘DIRNAME/include’ for locally
!      installed header files _instead_ of ‘/usr/local/include’.
  
!      You should specify ‘--with-local-prefix’ *only* if your site has a
!      different convention (not ‘/usr/local’) for where to put
       site-specific files.
  
!      The default value for ‘--with-local-prefix’ is ‘/usr/local’
!      regardless of the value of ‘--prefix’.  Specifying ‘--prefix’ has
       no effect on which directory GCC searches for local header files.
       This may seem counterintuitive, but actually it is logical.
  
!      The purpose of ‘--prefix’ is to specify where to _install GCC_. The
!      local header files in ‘/usr/local/include’--if you put any in that
       directory--are not part of GCC.  They are part of other
       programs--perhaps many others.  (GCC installs its own header files
!      in another directory which is based on the ‘--prefix’ value.)
  
       Both the local-prefix include directory and the GCC-prefix include
       directory are part of GCC's "system include" directories.  Although
*************** option.
*** 815,821 ****
       include directories is that pedantic warnings are turned off for
       headers in these directories.
  
!      Some autoconf macros add '-I DIRECTORY' options to the compiler
       command line, to ensure that directories containing installed
       packages' headers are searched.  When DIRECTORY is one of GCC's
       system include directories, GCC will ignore the option so that
--- 815,821 ----
       include directories is that pedantic warnings are turned off for
       headers in these directories.
  
!      Some autoconf macros add ‘-I DIRECTORY’ options to the compiler
       command line, to ensure that directories containing installed
       packages' headers are searched.  When DIRECTORY is one of GCC's
       system include directories, GCC will ignore the option so that
*************** option.
*** 824,874 ****
       but the directory will still be searched.
  
       GCC automatically searches for ordinary libraries using
!      'GCC_EXEC_PREFIX'.  Thus, when the same installation prefix is used
       for both GCC and packages, GCC will automatically search for both
       headers and libraries.  This provides a configuration that is easy
       to use.  GCC behaves in a manner similar to that when it is
!      installed as a system compiler in '/usr'.
  
       Sites that need to install multiple versions of GCC may not want to
       use the above simple configuration.  It is possible to use the
!      '--program-prefix', '--program-suffix' and
!      '--program-transform-name' options to install multiple versions
       into a single directory, but it may be simpler to use different
!      prefixes and the '--with-local-prefix' option to specify the
       location of the site-specific files for each version.  It will then
       be necessary for users to specify explicitly the location of local
!      site libraries (e.g., with 'LIBRARY_PATH').
  
!      The same value can be used for both '--with-local-prefix' and
!      '--prefix' provided it is not '/usr'.  This can be used to avoid
!      the default search of '/usr/local/include'.
  
!      *Do not* specify '/usr' as the '--with-local-prefix'!  The
!      directory you use for '--with-local-prefix' *must not* contain any
       of the system's standard header files.  If it did contain them,
       certain programs would be miscompiled (including GNU Emacs, on
       certain targets), because this would override and nullify the
!      header file corrections made by the 'fixincludes' script.
  
       Indications are that people who use this option use it based on
       mistaken ideas of what it is for.  People use it as if it specified
       where to install part of GCC.  Perhaps they make this assumption
       because installing GCC creates the directory.
  
! '--with-gcc-major-version-only'
       Specifies that GCC should use only the major number rather than
       MAJOR.MINOR.PATCHLEVEL in filesystem paths.
  
! '--with-native-system-header-dir=DIRNAME'
       Specifies that DIRNAME is the directory that contains native system
!      header files, rather than '/usr/include'.  This option is most
       useful if you are creating a compiler that should be isolated from
       the system as much as possible.  It is most commonly used with the
!      '--with-sysroot' option and will cause GCC to search DIRNAME inside
       the system root specified by that option.
  
! '--enable-shared[=PACKAGE[,...]]'
       Build shared versions of libraries, if shared libraries are
       supported on the target platform.  Unlike GCC 2.95.x and earlier,
       shared libraries are enabled by default on all platforms that
--- 824,874 ----
       but the directory will still be searched.
  
       GCC automatically searches for ordinary libraries using
!      ‘GCC_EXEC_PREFIX’.  Thus, when the same installation prefix is used
       for both GCC and packages, GCC will automatically search for both
       headers and libraries.  This provides a configuration that is easy
       to use.  GCC behaves in a manner similar to that when it is
!      installed as a system compiler in ‘/usr’.
  
       Sites that need to install multiple versions of GCC may not want to
       use the above simple configuration.  It is possible to use the
!      ‘--program-prefix’, ‘--program-suffix’ and
!      ‘--program-transform-name’ options to install multiple versions
       into a single directory, but it may be simpler to use different
!      prefixes and the ‘--with-local-prefix’ option to specify the
       location of the site-specific files for each version.  It will then
       be necessary for users to specify explicitly the location of local
!      site libraries (e.g., with ‘LIBRARY_PATH’).
  
!      The same value can be used for both ‘--with-local-prefix’ and
!      ‘--prefix’ provided it is not ‘/usr’.  This can be used to avoid
!      the default search of ‘/usr/local/include’.
  
!      *Do not* specify ‘/usr’ as the ‘--with-local-prefix’!  The
!      directory you use for ‘--with-local-prefix’ *must not* contain any
       of the system's standard header files.  If it did contain them,
       certain programs would be miscompiled (including GNU Emacs, on
       certain targets), because this would override and nullify the
!      header file corrections made by the ‘fixincludes’ script.
  
       Indications are that people who use this option use it based on
       mistaken ideas of what it is for.  People use it as if it specified
       where to install part of GCC.  Perhaps they make this assumption
       because installing GCC creates the directory.
  
! ‘--with-gcc-major-version-only’
       Specifies that GCC should use only the major number rather than
       MAJOR.MINOR.PATCHLEVEL in filesystem paths.
  
! ‘--with-native-system-header-dir=DIRNAME’
       Specifies that DIRNAME is the directory that contains native system
!      header files, rather than ‘/usr/include’.  This option is most
       useful if you are creating a compiler that should be isolated from
       the system as much as possible.  It is most commonly used with the
!      ‘--with-sysroot’ option and will cause GCC to search DIRNAME inside
       the system root specified by that option.
  
! ‘--enable-shared[=PACKAGE[,...]]’
       Build shared versions of libraries, if shared libraries are
       supported on the target platform.  Unlike GCC 2.95.x and earlier,
       shared libraries are enabled by default on all platforms that
*************** option.
*** 877,894 ****
       If a list of packages is given as an argument, build shared
       libraries only for the listed packages.  For other packages, only
       static libraries will be built.  Package names currently recognized
!      in the GCC tree are 'libgcc' (also known as 'gcc'), 'libstdc++'
!      (not 'libstdc++-v3'), 'libffi', 'zlib', 'boehm-gc', 'ada',
!      'libada', 'libgo', 'libobjc', and 'libphobos'.  Note 'libiberty'
       does not support shared libraries at all.
  
!      Use '--disable-shared' to build only static libraries.  Note that
!      '--disable-shared' does not accept a list of package names as
!      argument, only '--enable-shared' does.
  
!      Contrast with '--enable-host-shared', which affects _host_ code.
  
! '--enable-host-shared'
       Specify that the _host_ code should be built into
       position-independent machine code (with -fPIC), allowing it to be
       used within shared libraries, but yielding a slightly slower
--- 877,894 ----
       If a list of packages is given as an argument, build shared
       libraries only for the listed packages.  For other packages, only
       static libraries will be built.  Package names currently recognized
!      in the GCC tree are ‘libgcc’ (also known as ‘gcc’), ‘libstdc++’
!      (not ‘libstdc++-v3’), ‘libffi’, ‘zlib’, ‘boehm-gc’, ‘ada’,
!      ‘libada’, ‘libgo’, ‘libobjc’, and ‘libphobos’.  Note ‘libiberty’
       does not support shared libraries at all.
  
!      Use ‘--disable-shared’ to build only static libraries.  Note that
!      ‘--disable-shared’ does not accept a list of package names as
!      argument, only ‘--enable-shared’ does.
  
!      Contrast with ‘--enable-host-shared’, which affects _host_ code.
  
! ‘--enable-host-shared’
       Specify that the _host_ code should be built into
       position-independent machine code (with -fPIC), allowing it to be
       used within shared libraries, but yielding a slightly slower
*************** option.
*** 896,982 ****
  
       This option is required when building the libgccjit.so library.
  
!      Contrast with '--enable-shared', which affects _target_ libraries.
  
! '--with-gnu-as'
       Specify that the compiler should assume that the assembler it finds
       is the GNU assembler.  However, this does not modify the rules to
       find an assembler and will result in confusion if the assembler
       found is not actually the GNU assembler.  (Confusion may also
       result if the compiler finds the GNU assembler but has not been
!      configured with '--with-gnu-as'.)  If you have more than one
       assembler installed on your system, you may want to use this option
!      in connection with '--with-as=PATHNAME' or
!      '--with-build-time-tools=PATHNAME'.
  
       The following systems are the only ones where it makes a difference
       whether you use the GNU assembler.  On any other system,
!      '--with-gnu-as' has no effect.
  
!         * 'hppa1.0-ANY-ANY'
!         * 'hppa1.1-ANY-ANY'
!         * '*-*-solaris2.11'
  
! '--with-as=PATHNAME'
       Specify that the compiler should use the assembler pointed to by
       PATHNAME, rather than the one found by the standard rules to find
       an assembler, which are:
!         * Unless GCC is being built with a cross compiler, check the
!           'LIBEXEC/gcc/TARGET/VERSION' directory.  LIBEXEC defaults to
!           'EXEC-PREFIX/libexec'; EXEC-PREFIX defaults to PREFIX, which
!           defaults to '/usr/local' unless overridden by the
!           '--prefix=PATHNAME' switch described above.  TARGET is the
!           target system triple, such as 'sparc-sun-solaris2.11', and
            VERSION denotes the GCC version, such as 3.0.
  
!         * If the target system is the same that you are building on,
            check operating system specific directories.
  
!         * Check in the 'PATH' for a tool whose name is prefixed by the
            target system triple.
  
!         * Check in the 'PATH' for a tool whose name is not prefixed by
            the target system triple, if the host and target system triple
            are the same (in other words, we use a host tool if it can be
            used for the target as well).
  
!      You may want to use '--with-as' if no assembler is installed in the
       directories listed above, or if you have multiple assemblers
       installed and want to choose one that is not found by the above
       rules.
  
! '--with-gnu-ld'
!      Same as '--with-gnu-as' but for the linker.
  
! '--with-ld=PATHNAME'
!      Same as '--with-as' but for the linker.
  
! '--with-dsymutil=PATHNAME'
!      Same as '--with-as' but for the debug linker (only used on Darwin
       platforms so far).
  
! '--with-tls=DIALECT'
!      Specify the default TLS dialect, for systems were there is a
!      choice.  For ARM targets, possible values for DIALECT are 'gnu' or
!      'gnu2', which select between the original GNU dialect and the GNU
       TLS descriptor-based dialect.
  
! '--enable-multiarch'
       Specify whether to enable or disable multiarch support.  The
       default is to check for glibc start files in a multiarch location,
       and enable it if the files are found.  The auto detection is
       enabled for native builds, and for cross builds configured with
!      '--with-sysroot', and without '--with-native-system-header-dir'.
       More documentation about multiarch can be found at
       .
  
! '--enable-sjlj-exceptions'
!      Force use of the 'setjmp'/'longjmp'-based scheme for exceptions.
!      'configure' ordinarily picks the correct value based on the
       platform.  Only use this option if you are sure you need a
       different setting.
  
! '--enable-vtable-verify'
       Specify whether to enable or disable the vtable verification
       feature.  Enabling this feature causes libstdc++ to be built with
       its virtual calls in verifiable mode.  This means that, when linked
--- 896,982 ----
  
       This option is required when building the libgccjit.so library.
  
!      Contrast with ‘--enable-shared’, which affects _target_ libraries.
  
! ‘--with-gnu-as’
       Specify that the compiler should assume that the assembler it finds
       is the GNU assembler.  However, this does not modify the rules to
       find an assembler and will result in confusion if the assembler
       found is not actually the GNU assembler.  (Confusion may also
       result if the compiler finds the GNU assembler but has not been
!      configured with ‘--with-gnu-as’.)  If you have more than one
       assembler installed on your system, you may want to use this option
!      in connection with ‘--with-as=PATHNAME’ or
!      ‘--with-build-time-tools=PATHNAME’.
  
       The following systems are the only ones where it makes a difference
       whether you use the GNU assembler.  On any other system,
!      ‘--with-gnu-as’ has no effect.
  
!         • ‘hppa1.0-ANY-ANY’
!         • ‘hppa1.1-ANY-ANY’
!         • ‘*-*-solaris2.11’
  
! ‘--with-as=PATHNAME’
       Specify that the compiler should use the assembler pointed to by
       PATHNAME, rather than the one found by the standard rules to find
       an assembler, which are:
!         • Unless GCC is being built with a cross compiler, check the
!           ‘LIBEXEC/gcc/TARGET/VERSION’ directory.  LIBEXEC defaults to
!           ‘EXEC-PREFIX/libexec’; EXEC-PREFIX defaults to PREFIX, which
!           defaults to ‘/usr/local’ unless overridden by the
!           ‘--prefix=PATHNAME’ switch described above.  TARGET is the
!           target system triple, such as ‘sparc-sun-solaris2.11’, and
            VERSION denotes the GCC version, such as 3.0.
  
!         • If the target system is the same that you are building on,
            check operating system specific directories.
  
!         • Check in the ‘PATH’ for a tool whose name is prefixed by the
            target system triple.
  
!         • Check in the ‘PATH’ for a tool whose name is not prefixed by
            the target system triple, if the host and target system triple
            are the same (in other words, we use a host tool if it can be
            used for the target as well).
  
!      You may want to use ‘--with-as’ if no assembler is installed in the
       directories listed above, or if you have multiple assemblers
       installed and want to choose one that is not found by the above
       rules.
  
! ‘--with-gnu-ld’
!      Same as ‘--with-gnu-as’ but for the linker.
  
! ‘--with-ld=PATHNAME’
!      Same as ‘--with-as’ but for the linker.
  
! ‘--with-dsymutil=PATHNAME’
!      Same as ‘--with-as’ but for the debug linker (only used on Darwin
       platforms so far).
  
! ‘--with-tls=DIALECT’
!      Specify the default TLS dialect, for systems where there is a
!      choice.  For ARM targets, possible values for DIALECT are ‘gnu’ or
!      ‘gnu2’, which select between the original GNU dialect and the GNU
       TLS descriptor-based dialect.
  
! ‘--enable-multiarch’
       Specify whether to enable or disable multiarch support.  The
       default is to check for glibc start files in a multiarch location,
       and enable it if the files are found.  The auto detection is
       enabled for native builds, and for cross builds configured with
!      ‘--with-sysroot’, and without ‘--with-native-system-header-dir’.
       More documentation about multiarch can be found at
       .
  
! ‘--enable-sjlj-exceptions’
!      Force use of the ‘setjmp’/‘longjmp’-based scheme for exceptions.
!      ‘configure’ ordinarily picks the correct value based on the
       platform.  Only use this option if you are sure you need a
       different setting.
  
! ‘--enable-vtable-verify’
       Specify whether to enable or disable the vtable verification
       feature.  Enabling this feature causes libstdc++ to be built with
       its virtual calls in verifiable mode.  This means that, when linked
*************** option.
*** 986,1125 ****
       functions (in libstdc++ itself) and do nothing.  If vtable
       verification is disabled, then libstdc++ is not built with its
       virtual calls in verifiable mode at all.  However the libvtv
!      library will still be built (see '--disable-libvtv' to turn off
!      building libvtv).  '--disable-vtable-verify' is the default.
  
! '--disable-gcov'
       Specify that the run-time library used for coverage analysis and
       associated host tools should not be built.
  
! '--disable-multilib'
       Specify that multiple target libraries to support different target
       variants, calling conventions, etc. should not be built.  The
       default is to build a predefined set of them.
  
       Some targets provide finer-grained control over which multilibs are
!      built (e.g., '--disable-softfloat'):
!      'arm-*-*'
            fpu, 26bit, underscore, interwork, biendian, nofmult.
  
!      'm68*-*-*'
            softfloat, m68881, m68000, m68020.
  
!      'mips*-*-*'
            single-float, biendian, softfloat.
  
!      'msp430-*-*'
            no-exceptions
  
!      'powerpc*-*-*, rs6000*-*-*'
            aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos,
            biendian, sysv, aix.
  
! '--with-multilib-list=LIST'
! '--without-multilib-list'
       Specify what multilibs to build.  LIST is a comma separated list of
       values, possibly consisting of a single value.  Currently only
       implemented for aarch64*-*-*, arm*-*-*, loongarch64-*-*,
       riscv*-*-*, sh*-*-* and x86-64-*-linux*.  The accepted values and
       meaning for each target is given below.
  
!      'aarch64*-*-*'
!           LIST is a comma separated list of 'ilp32', and 'lp64' to
            enable ILP32 and LP64 run-time libraries, respectively.  If
            LIST is empty, then there will be no multilibs and only the
!           default run-time library will be built.  If LIST is 'default'
            or -with-multilib-list= is not specified, then the default set
!           of libraries is selected based on the value of '--target'.
  
!      'arm*-*-*'
!           LIST is a comma separated list of 'aprofile' and 'rmprofile'
            to build multilibs for A or R and M architecture profiles
            respectively.  Note that, due to some limitation of the
            current multilib framework, using the combined
!           'aprofile,rmprofile' multilibs selects in some cases a less
            optimal multilib than when using the multilib profile for the
!           architecture targetted.  The special value 'default' is also
            accepted and is equivalent to omitting the option, i.e., only
            the default run-time library will be enabled.
  
!           LIST may instead contain '@name', to use the multilib
!           configuration Makefile fragment 'name' in 'gcc/config/arm' in
            the source tree (it is part of the corresponding sources,
            after all).  It is recommended, but not required, that files
!           used for this purpose to be named starting with 't-ml-', to
            make their intended purpose self-evident, in line with GCC
            conventions.  Such files enable custom, user-chosen multilib
            lists to be configured.  Whether multiple such files can be
            used together depends on the contents of the supplied files.
!           See 'gcc/config/arm/t-multilib' and its supplementary
!           'gcc/config/arm/t-*profile' files for an example of what such
            Makefile fragments might look like for this version of GCC.
            The macros expected to be defined in these fragments are not
            stable across GCC releases, so make sure they define the
!           'MULTILIB'-related macros expected by the version of GCC you
            are building.  *Note Target Makefile Fragments: (gccint)Target
            Fragment.
  
            The table below gives the combination of ISAs, architectures,
            FPUs and floating-point ABIs for which multilibs are built for
            each predefined profile.  The union of these options is
!           considered when specifying both 'aprofile' and 'rmprofile'.
  
            Option      aprofile             rmprofile
!           ISAs        '-marm' and          '-mthumb'
!                       '-mthumb'
            Architecturesdefault             default architecture
!                       architecture         '-march=armv6s-m'
!                       '-march=armv7-a'     '-march=armv7-m'
!                       '-march=armv7ve'     '-march=armv7e-m'
!                       '-march=armv8-a'     '-march=armv8-m.base'
!                                            '-march=armv8-m.main'
!                                            '-march=armv7'
            FPUs        none                 none
!                       '-mfpu=vfpv3-d16'    '-mfpu=vfpv3-d16'
!                       '-mfpu=neon'         '-mfpu=fpv4-sp-d16'
!                       '-mfpu=vfpv4-d16'    '-mfpu=fpv5-sp-d16'
!                       '-mfpu=neon-vfpv4'   '-mfpu=fpv5-d16'
!                       '-mfpu=neon-fp-armv8'
!           floating-point'-mfloat-abi=soft' '-mfloat-abi=soft'
!           ABIs        '-mfloat-abi=softfp' '-mfloat-abi=softfp'
!                       '-mfloat-abi=hard'   '-mfloat-abi=hard'
  
!      'loongarch*-*-*'
            LIST is a comma-separated list of the following ABI
!           identifiers: 'lp64d[/base]' 'lp64f[/base]' 'lp64d[/base]',
!           where the '/base' suffix may be omitted, to enable their
!           respective run-time libraries.  If LIST is empty or 'default',
!           or if '--with-multilib-list' is not specified, then the
!           default ABI as specified by '--with-abi' or implied by
!           '--target' is selected.
  
!      'riscv*-*-*'
            LIST is a single ABI name.  The target architecture must be
!           either 'rv32gc' or 'rv64gc'.  This will build a single
            multilib for the specified architecture and ABI pair.  If
!           '--with-multilib-list' is not given, then a default set of
!           multilibs is selected based on the value of '--target'.  This
            is usually a large set of multilibs.
  
!      'sh*-*-*'
            LIST is a comma separated list of CPU names.  These must be of
!           the form 'sh*' or 'm*' (in which case they match the compiler
            option for that processor).  The list should not contain any
!           endian options - these are handled by '--with-endian'.
  
            If LIST is empty, then there will be no multilibs for extra
            processors.  The multilib for the secondary endian remains
            enabled.
  
!           As a special case, if an entry in the list starts with a '!'
            (exclamation point), then it is added to the list of excluded
            multilibs.  Entries of this sort should be compatible with
!           'MULTILIB_EXCLUDES' (once the leading '!' has been stripped).
  
!           If '--with-multilib-list' is not given, then a default set of
!           multilibs is selected based on the value of '--target'.  This
            is usually the complete set of libraries, but some targets
            imply a more specialized subset.
  
--- 986,1125 ----
       functions (in libstdc++ itself) and do nothing.  If vtable
       verification is disabled, then libstdc++ is not built with its
       virtual calls in verifiable mode at all.  However the libvtv
!      library will still be built (see ‘--disable-libvtv’ to turn off
!      building libvtv).  ‘--disable-vtable-verify’ is the default.
  
! ‘--disable-gcov’
       Specify that the run-time library used for coverage analysis and
       associated host tools should not be built.
  
! ‘--disable-multilib’
       Specify that multiple target libraries to support different target
       variants, calling conventions, etc. should not be built.  The
       default is to build a predefined set of them.
  
       Some targets provide finer-grained control over which multilibs are
!      built (e.g., ‘--disable-softfloat’):
!      ‘arm-*-*’
            fpu, 26bit, underscore, interwork, biendian, nofmult.
  
!      ‘m68*-*-*’
            softfloat, m68881, m68000, m68020.
  
!      ‘mips*-*-*’
            single-float, biendian, softfloat.
  
!      ‘msp430-*-*’
            no-exceptions
  
!      ‘powerpc*-*-*, rs6000*-*-*’
            aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos,
            biendian, sysv, aix.
  
! ‘--with-multilib-list=LIST’
! ‘--without-multilib-list’
       Specify what multilibs to build.  LIST is a comma separated list of
       values, possibly consisting of a single value.  Currently only
       implemented for aarch64*-*-*, arm*-*-*, loongarch64-*-*,
       riscv*-*-*, sh*-*-* and x86-64-*-linux*.  The accepted values and
       meaning for each target is given below.
  
!      ‘aarch64*-*-*’
!           LIST is a comma separated list of ‘ilp32’, and ‘lp64’ to
            enable ILP32 and LP64 run-time libraries, respectively.  If
            LIST is empty, then there will be no multilibs and only the
!           default run-time library will be built.  If LIST is ‘default’
            or -with-multilib-list= is not specified, then the default set
!           of libraries is selected based on the value of ‘--target’.
  
!      ‘arm*-*-*’
!           LIST is a comma separated list of ‘aprofile’ and ‘rmprofile’
            to build multilibs for A or R and M architecture profiles
            respectively.  Note that, due to some limitation of the
            current multilib framework, using the combined
!           ‘aprofile,rmprofile’ multilibs selects in some cases a less
            optimal multilib than when using the multilib profile for the
!           architecture targetted.  The special value ‘default’ is also
            accepted and is equivalent to omitting the option, i.e., only
            the default run-time library will be enabled.
  
!           LIST may instead contain ‘@name’, to use the multilib
!           configuration Makefile fragment ‘name’ in ‘gcc/config/arm’ in
            the source tree (it is part of the corresponding sources,
            after all).  It is recommended, but not required, that files
!           used for this purpose to be named starting with ‘t-ml-’, to
            make their intended purpose self-evident, in line with GCC
            conventions.  Such files enable custom, user-chosen multilib
            lists to be configured.  Whether multiple such files can be
            used together depends on the contents of the supplied files.
!           See ‘gcc/config/arm/t-multilib’ and its supplementary
!           ‘gcc/config/arm/t-*profile’ files for an example of what such
            Makefile fragments might look like for this version of GCC.
            The macros expected to be defined in these fragments are not
            stable across GCC releases, so make sure they define the
!           ‘MULTILIB’-related macros expected by the version of GCC you
            are building.  *Note Target Makefile Fragments: (gccint)Target
            Fragment.
  
            The table below gives the combination of ISAs, architectures,
            FPUs and floating-point ABIs for which multilibs are built for
            each predefined profile.  The union of these options is
!           considered when specifying both ‘aprofile’ and ‘rmprofile’.
  
            Option      aprofile             rmprofile
!           ISAs        ‘-marm’ and          ‘-mthumb’
!                       ‘-mthumb’
            Architecturesdefault             default architecture
!                       architecture         ‘-march=armv6s-m’
!                       ‘-march=armv7-a’     ‘-march=armv7-m’
!                       ‘-march=armv7ve’     ‘-march=armv7e-m’
!                       ‘-march=armv8-a’     ‘-march=armv8-m.base’
!                                            ‘-march=armv8-m.main’
!                                            ‘-march=armv7’
            FPUs        none                 none
!                       ‘-mfpu=vfpv3-d16’    ‘-mfpu=vfpv3-d16’
!                       ‘-mfpu=neon’         ‘-mfpu=fpv4-sp-d16’
!                       ‘-mfpu=vfpv4-d16’    ‘-mfpu=fpv5-sp-d16’
!                       ‘-mfpu=neon-vfpv4’   ‘-mfpu=fpv5-d16’
!                       ‘-mfpu=neon-fp-armv8’
!           floating-point‘-mfloat-abi=soft’ ‘-mfloat-abi=soft’
!           ABIs        ‘-mfloat-abi=softfp’ ‘-mfloat-abi=softfp’
!                       ‘-mfloat-abi=hard’   ‘-mfloat-abi=hard’
  
!      ‘loongarch*-*-*’
            LIST is a comma-separated list of the following ABI
!           identifiers: ‘lp64d[/base]’ ‘lp64f[/base]’ ‘lp64d[/base]’,
!           where the ‘/base’ suffix may be omitted, to enable their
!           respective run-time libraries.  If LIST is empty or ‘default’,
!           or if ‘--with-multilib-list’ is not specified, then the
!           default ABI as specified by ‘--with-abi’ or implied by
!           ‘--target’ is selected.
  
!      ‘riscv*-*-*’
            LIST is a single ABI name.  The target architecture must be
!           either ‘rv32gc’ or ‘rv64gc’.  This will build a single
            multilib for the specified architecture and ABI pair.  If
!           ‘--with-multilib-list’ is not given, then a default set of
!           multilibs is selected based on the value of ‘--target’.  This
            is usually a large set of multilibs.
  
!      ‘sh*-*-*’
            LIST is a comma separated list of CPU names.  These must be of
!           the form ‘sh*’ or ‘m*’ (in which case they match the compiler
            option for that processor).  The list should not contain any
!           endian options - these are handled by ‘--with-endian’.
  
            If LIST is empty, then there will be no multilibs for extra
            processors.  The multilib for the secondary endian remains
            enabled.
  
!           As a special case, if an entry in the list starts with a ‘!’
            (exclamation point), then it is added to the list of excluded
            multilibs.  Entries of this sort should be compatible with
!           ‘MULTILIB_EXCLUDES’ (once the leading ‘!’ has been stripped).
  
!           If ‘--with-multilib-list’ is not given, then a default set of
!           multilibs is selected based on the value of ‘--target’.  This
            is usually the complete set of libraries, but some targets
            imply a more specialized subset.
  
*************** option.
*** 1132,1148 ****
                 --with-cpu=sh4a --with-endian=little,big \
                 --with-multilib-list=sh4al,!mb/m4al
  
!      'x86-64-*-linux*'
!           LIST is a comma separated list of 'm32', 'm64' and 'mx32' to
            enable 32-bit, 64-bit and x32 run-time libraries,
            respectively.  If LIST is empty, then there will be no
            multilibs and only the default run-time library will be
            enabled.
  
!           If '--with-multilib-list' is not given, then only 32-bit and
            64-bit run-time libraries will be enabled.
  
! '--with-multilib-generator=CONFIG'
       Specify what multilibs to build.  CONFIG is a semicolon separated
       list of values, possibly consisting of a single value.  Currently
       only implemented for riscv*-*-elf*.  The accepted values and
--- 1132,1148 ----
                 --with-cpu=sh4a --with-endian=little,big \
                 --with-multilib-list=sh4al,!mb/m4al
  
!      ‘x86-64-*-linux*’
!           LIST is a comma separated list of ‘m32’, ‘m64’ and ‘mx32’ to
            enable 32-bit, 64-bit and x32 run-time libraries,
            respectively.  If LIST is empty, then there will be no
            multilibs and only the default run-time library will be
            enabled.
  
!           If ‘--with-multilib-list’ is not given, then only 32-bit and
            64-bit run-time libraries will be enabled.
  
! ‘--with-multilib-generator=CONFIG’
       Specify what multilibs to build.  CONFIG is a semicolon separated
       list of values, possibly consisting of a single value.  Currently
       only implemented for riscv*-*-elf*.  The accepted values and
*************** option.
*** 1168,1175 ****
       this multi-lib set.
            rv64ima-lp64--f,c,fc
  
!      '--with-multilib-generator' have an optional configuration argument
!      '--cmodel=val' for code model, this option will expand with other
       config options, VAL is a comma separated list of possible code
       model, currently we support medlow and medany.
  
--- 1168,1175 ----
       this multi-lib set.
            rv64ima-lp64--f,c,fc
  
!      ‘--with-multilib-generator’ have an optional configuration argument
!      ‘--cmodel=val’ for code model, this option will expand with other
       config options, VAL is a comma separated list of possible code
       model, currently we support medlow and medany.
  
*************** option.
*** 1182,1204 ****
       model
            rv64ima-lp64--;--cmodel=medlow,medany
  
! '--with-endian=ENDIANS'
       Specify what endians to use.  Currently only implemented for
       sh*-*-*.
  
       ENDIANS may be one of the following:
!      'big'
            Use big endian exclusively.
!      'little'
            Use little endian exclusively.
!      'big,little'
            Use big endian by default.  Provide a multilib for little
            endian.
!      'little,big'
            Use little endian by default.  Provide a multilib for big
            endian.
  
! '--enable-threads'
       Specify that the target supports threads.  This affects the
       Objective-C compiler and runtime library, and exception handling
       for other languages like C++.  On some systems, this is the
--- 1182,1204 ----
       model
            rv64ima-lp64--;--cmodel=medlow,medany
  
! ‘--with-endian=ENDIANS’
       Specify what endians to use.  Currently only implemented for
       sh*-*-*.
  
       ENDIANS may be one of the following:
!      ‘big’
            Use big endian exclusively.
!      ‘little’
            Use little endian exclusively.
!      ‘big,little’
            Use big endian by default.  Provide a multilib for little
            endian.
!      ‘little,big’
            Use little endian by default.  Provide a multilib for big
            endian.
  
! ‘--enable-threads’
       Specify that the target supports threads.  This affects the
       Objective-C compiler and runtime library, and exception handling
       for other languages like C++.  On some systems, this is the
*************** option.
*** 1208,1369 ****
       model available will be configured for use.  Beware that on some
       systems, GCC has not been taught what threading models are
       generally available for the system.  In this case,
!      '--enable-threads' is an alias for '--enable-threads=single'.
  
! '--disable-threads'
       Specify that threading support should be disabled for the system.
!      This is an alias for '--enable-threads=single'.
  
! '--enable-threads=LIB'
       Specify that LIB is the thread support library.  This affects the
       Objective-C compiler and runtime library, and exception handling
       for other languages like C++.  The possibilities for LIB are:
  
!      'aix'
            AIX thread support.
!      'dce'
            DCE thread support.
!      'lynx'
            LynxOS thread support.
!      'mipssde'
            MIPS SDE thread support.
!      'no'
!           This is an alias for 'single'.
!      'posix'
            Generic POSIX/Unix98 thread support.
!      'rtems'
            RTEMS thread support.
!      'single'
            Disable thread support, should work for all platforms.
!      'tpf'
            TPF thread support.
!      'vxworks'
            VxWorks thread support.
!      'win32'
            Microsoft Win32 API thread support.
  
! '--enable-tls'
       Specify that the target supports TLS (Thread Local Storage).
       Usually configure can correctly determine if TLS is supported.  In
       cases where it guesses incorrectly, TLS can be explicitly enabled
!      or disabled with '--enable-tls' or '--disable-tls'.  This can
       happen if the assembler supports TLS but the C library does not, or
       if the assumptions made by the configure test are incorrect.
  
! '--disable-tls'
       Specify that the target does not support TLS. This is an alias for
!      '--enable-tls=no'.
  
! '--disable-tm-clone-registry'
       Disable TM clone registry in libgcc.  It is enabled in libgcc by
       default.  This option helps to reduce code size for embedded
       targets which do not use transactional memory.
  
! '--with-cpu=CPU'
! '--with-cpu-32=CPU'
! '--with-cpu-64=CPU'
       Specify which cpu variant the compiler should generate code for by
!      default.  CPU will be used as the default value of the '-mcpu='
       switch.  This option is only supported on some targets, including
       ARC, ARM, i386, M68k, PowerPC, and SPARC.  It is mandatory for ARC.
!      The '--with-cpu-32' and '--with-cpu-64' options specify separate
       default CPUs for 32-bit and 64-bit modes; these options are only
       supported for aarch64, i386, x86-64, PowerPC, and SPARC.
  
! '--with-schedule=CPU'
! '--with-arch=CPU'
! '--with-arch-32=CPU'
! '--with-arch-64=CPU'
! '--with-tune=CPU'
! '--with-tune-32=CPU'
! '--with-tune-64=CPU'
! '--with-abi=ABI'
! '--with-fpu=TYPE'
! '--with-float=TYPE'
       These configure options provide default values for the
!      '-mschedule=', '-march=', '-mtune=', '-mabi=', and '-mfpu=' options
!      and for '-mhard-float' or '-msoft-float'.  As with '--with-cpu',
       which switches will be accepted and acceptable values of the
       arguments depend on the target.
  
! '--with-mode=MODE'
!      Specify if the compiler should default to '-marm' or '-mthumb'.
       This option is only supported on ARM targets.
  
! '--with-stack-offset=NUM'
       This option sets the default for the -mstack-offset=NUM option, and
       will thus generally also control the setting of this option for
       libraries.  This option is only supported on Epiphany targets.
  
! '--with-fpmath=ISA'
!      This options sets '-mfpmath=sse' by default and specifies the
       default ISA for floating-point arithmetics.  You can select either
!      'sse' which enables '-msse2' or 'avx' which enables '-mavx' by
       default.  This option is only supported on i386 and x86-64 targets.
  
! '--with-fp-32=MODE'
!      On MIPS targets, set the default value for the '-mfp' option when
       using the o32 ABI. The possibilities for MODE are:
!      '32'
!           Use the o32 FP32 ABI extension, as with the '-mfp32'
            command-line option.
!      'xx'
!           Use the o32 FPXX ABI extension, as with the '-mfpxx'
            command-line option.
!      '64'
!           Use the o32 FP64 ABI extension, as with the '-mfp64'
            command-line option.
       In the absence of this configuration option the default is to use
       the o32 FP32 ABI extension.
  
! '--with-odd-spreg-32'
!      On MIPS targets, set the '-modd-spreg' option by default when using
       the o32 ABI.
  
! '--without-odd-spreg-32'
!      On MIPS targets, set the '-mno-odd-spreg' option by default when
       using the o32 ABI. This is normally used in conjunction with
!      '--with-fp-32=64' in order to target the o32 FP64A ABI extension.
  
! '--with-nan=ENCODING'
       On MIPS targets, set the default encoding convention to use for the
       special not-a-number (NaN) IEEE 754 floating-point data.  The
       possibilities for ENCODING are:
!      'legacy'
!           Use the legacy encoding, as with the '-mnan=legacy'
            command-line option.
!      '2008'
!           Use the 754-2008 encoding, as with the '-mnan=2008'
            command-line option.
       To use this configuration option you must have an assembler version
!      installed that supports the '-mnan=' command-line option too.  In
       the absence of this configuration option the default convention is
!      the legacy encoding, as when neither of the '-mnan=2008' and
!      '-mnan=legacy' command-line options has been used.
  
! '--with-divide=TYPE'
       Specify how the compiler should generate code for checking for
       division by zero.  This option is only supported on the MIPS
       target.  The possibilities for TYPE are:
!      'traps'
            Division by zero checks use conditional traps (this is the
            default on systems that support conditional traps).
!      'breaks'
            Division by zero checks use the break instruction.
  
! '--with-compact-branches=POLICY'
       Specify how the compiler should generate branch instructions.  This
       option is only supported on the MIPS target.  The possibilities for
       TYPE are:
!      'optimal'
            Cause a delay slot branch to be used if one is available in
            the current ISA and the delay slot is successfully filled.  If
            the delay slot is not filled, a compact branch will be chosen
            if one is available.
!      'never'
            Ensures that compact branch instructions will never be
            generated.
!      'always'
            Ensures that a compact branch instruction will be generated if
            available.  If a compact branch instruction is not available,
            a delay slot form of the branch will be used instead.  This
--- 1208,1369 ----
       model available will be configured for use.  Beware that on some
       systems, GCC has not been taught what threading models are
       generally available for the system.  In this case,
!      ‘--enable-threads’ is an alias for ‘--enable-threads=single’.
  
! ‘--disable-threads’
       Specify that threading support should be disabled for the system.
!      This is an alias for ‘--enable-threads=single’.
  
! ‘--enable-threads=LIB’
       Specify that LIB is the thread support library.  This affects the
       Objective-C compiler and runtime library, and exception handling
       for other languages like C++.  The possibilities for LIB are:
  
!      ‘aix’
            AIX thread support.
!      ‘dce’
            DCE thread support.
!      ‘lynx’
            LynxOS thread support.
!      ‘mipssde’
            MIPS SDE thread support.
!      ‘no’
!           This is an alias for ‘single’.
!      ‘posix’
            Generic POSIX/Unix98 thread support.
!      ‘rtems’
            RTEMS thread support.
!      ‘single’
            Disable thread support, should work for all platforms.
!      ‘tpf’
            TPF thread support.
!      ‘vxworks’
            VxWorks thread support.
!      ‘win32’
            Microsoft Win32 API thread support.
  
! ‘--enable-tls’
       Specify that the target supports TLS (Thread Local Storage).
       Usually configure can correctly determine if TLS is supported.  In
       cases where it guesses incorrectly, TLS can be explicitly enabled
!      or disabled with ‘--enable-tls’ or ‘--disable-tls’.  This can
       happen if the assembler supports TLS but the C library does not, or
       if the assumptions made by the configure test are incorrect.
  
! ‘--disable-tls’
       Specify that the target does not support TLS. This is an alias for
!      ‘--enable-tls=no’.
  
! ‘--disable-tm-clone-registry’
       Disable TM clone registry in libgcc.  It is enabled in libgcc by
       default.  This option helps to reduce code size for embedded
       targets which do not use transactional memory.
  
! ‘--with-cpu=CPU’
! ‘--with-cpu-32=CPU’
! ‘--with-cpu-64=CPU’
       Specify which cpu variant the compiler should generate code for by
!      default.  CPU will be used as the default value of the ‘-mcpu=’
       switch.  This option is only supported on some targets, including
       ARC, ARM, i386, M68k, PowerPC, and SPARC.  It is mandatory for ARC.
!      The ‘--with-cpu-32’ and ‘--with-cpu-64’ options specify separate
       default CPUs for 32-bit and 64-bit modes; these options are only
       supported for aarch64, i386, x86-64, PowerPC, and SPARC.
  
! ‘--with-schedule=CPU’
! ‘--with-arch=CPU’
! ‘--with-arch-32=CPU’
! ‘--with-arch-64=CPU’
! ‘--with-tune=CPU’
! ‘--with-tune-32=CPU’
! ‘--with-tune-64=CPU’
! ‘--with-abi=ABI’
! ‘--with-fpu=TYPE’
! ‘--with-float=TYPE’
       These configure options provide default values for the
!      ‘-mschedule=’, ‘-march=’, ‘-mtune=’, ‘-mabi=’, and ‘-mfpu=’ options
!      and for ‘-mhard-float’ or ‘-msoft-float’.  As with ‘--with-cpu’,
       which switches will be accepted and acceptable values of the
       arguments depend on the target.
  
! ‘--with-mode=MODE’
!      Specify if the compiler should default to ‘-marm’ or ‘-mthumb’.
       This option is only supported on ARM targets.
  
! ‘--with-stack-offset=NUM’
       This option sets the default for the -mstack-offset=NUM option, and
       will thus generally also control the setting of this option for
       libraries.  This option is only supported on Epiphany targets.
  
! ‘--with-fpmath=ISA’
!      This options sets ‘-mfpmath=sse’ by default and specifies the
       default ISA for floating-point arithmetics.  You can select either
!      ‘sse’ which enables ‘-msse2’ or ‘avx’ which enables ‘-mavx’ by
       default.  This option is only supported on i386 and x86-64 targets.
  
! ‘--with-fp-32=MODE’
!      On MIPS targets, set the default value for the ‘-mfp’ option when
       using the o32 ABI. The possibilities for MODE are:
!      ‘32’
!           Use the o32 FP32 ABI extension, as with the ‘-mfp32’
            command-line option.
!      ‘xx’
!           Use the o32 FPXX ABI extension, as with the ‘-mfpxx’
            command-line option.
!      ‘64’
!           Use the o32 FP64 ABI extension, as with the ‘-mfp64’
            command-line option.
       In the absence of this configuration option the default is to use
       the o32 FP32 ABI extension.
  
! ‘--with-odd-spreg-32’
!      On MIPS targets, set the ‘-modd-spreg’ option by default when using
       the o32 ABI.
  
! ‘--without-odd-spreg-32’
!      On MIPS targets, set the ‘-mno-odd-spreg’ option by default when
       using the o32 ABI. This is normally used in conjunction with
!      ‘--with-fp-32=64’ in order to target the o32 FP64A ABI extension.
  
! ‘--with-nan=ENCODING’
       On MIPS targets, set the default encoding convention to use for the
       special not-a-number (NaN) IEEE 754 floating-point data.  The
       possibilities for ENCODING are:
!      ‘legacy’
!           Use the legacy encoding, as with the ‘-mnan=legacy’
            command-line option.
!      ‘2008’
!           Use the 754-2008 encoding, as with the ‘-mnan=2008’
            command-line option.
       To use this configuration option you must have an assembler version
!      installed that supports the ‘-mnan=’ command-line option too.  In
       the absence of this configuration option the default convention is
!      the legacy encoding, as when neither of the ‘-mnan=2008’ and
!      ‘-mnan=legacy’ command-line options has been used.
  
! ‘--with-divide=TYPE’
       Specify how the compiler should generate code for checking for
       division by zero.  This option is only supported on the MIPS
       target.  The possibilities for TYPE are:
!      ‘traps’
            Division by zero checks use conditional traps (this is the
            default on systems that support conditional traps).
!      ‘breaks’
            Division by zero checks use the break instruction.
  
! ‘--with-compact-branches=POLICY’
       Specify how the compiler should generate branch instructions.  This
       option is only supported on the MIPS target.  The possibilities for
       TYPE are:
!      ‘optimal’
            Cause a delay slot branch to be used if one is available in
            the current ISA and the delay slot is successfully filled.  If
            the delay slot is not filled, a compact branch will be chosen
            if one is available.
!      ‘never’
            Ensures that compact branch instructions will never be
            generated.
!      ‘always’
            Ensures that a compact branch instruction will be generated if
            available.  If a compact branch instruction is not available,
            a delay slot form of the branch will be used instead.  This
*************** option.
*** 1371,1400 ****
            pre-R6/microMIPS/MIPS16, this option is just same as
            never/optimal.
  
! '--with-llsc'
!      On MIPS targets, make '-mllsc' the default when no '-mno-llsc'
       option is passed.  This is the default for Linux-based targets, as
       the kernel will emulate them if the ISA does not provide them.
  
! '--without-llsc'
!      On MIPS targets, make '-mno-llsc' the default when no '-mllsc'
       option is passed.
  
! '--with-synci'
!      On MIPS targets, make '-msynci' the default when no '-mno-synci'
       option is passed.
  
! '--without-synci'
!      On MIPS targets, make '-mno-synci' the default when no '-msynci'
       option is passed.  This is the default.
  
! '--with-lxc1-sxc1'
!      On MIPS targets, make '-mlxc1-sxc1' the default when no
!      '-mno-lxc1-sxc1' option is passed.  This is the default.
  
! '--without-lxc1-sxc1'
!      On MIPS targets, make '-mno-lxc1-sxc1' the default when no
!      '-mlxc1-sxc1' option is passed.  The indexed load/store
       instructions are not directly a problem but can lead to unexpected
       behaviour when deployed in an application intended for a 32-bit
       address space but run on a 64-bit processor.  The issue is seen
--- 1371,1400 ----
            pre-R6/microMIPS/MIPS16, this option is just same as
            never/optimal.
  
! ‘--with-llsc’
!      On MIPS targets, make ‘-mllsc’ the default when no ‘-mno-llsc’
       option is passed.  This is the default for Linux-based targets, as
       the kernel will emulate them if the ISA does not provide them.
  
! ‘--without-llsc’
!      On MIPS targets, make ‘-mno-llsc’ the default when no ‘-mllsc’
       option is passed.
  
! ‘--with-synci’
!      On MIPS targets, make ‘-msynci’ the default when no ‘-mno-synci’
       option is passed.
  
! ‘--without-synci’
!      On MIPS targets, make ‘-mno-synci’ the default when no ‘-msynci’
       option is passed.  This is the default.
  
! ‘--with-lxc1-sxc1’
!      On MIPS targets, make ‘-mlxc1-sxc1’ the default when no
!      ‘-mno-lxc1-sxc1’ option is passed.  This is the default.
  
! ‘--without-lxc1-sxc1’
!      On MIPS targets, make ‘-mno-lxc1-sxc1’ the default when no
!      ‘-mlxc1-sxc1’ option is passed.  The indexed load/store
       instructions are not directly a problem but can lead to unexpected
       behaviour when deployed in an application intended for a 32-bit
       address space but run on a 64-bit processor.  The issue is seen
*************** option.
*** 1402,1420 ****
       applications with 64-bit addressing enabled which affects the
       overflow behaviour of the indexed addressing mode.  GCC will assume
       that ordinary 32-bit arithmetic overflow behaviour is the same
!      whether performed as an 'addu' instruction or as part of the
!      address calculation in 'lwxc1' type instructions.  This assumption
       holds true in a pure 32-bit environment and can hold true in a
       64-bit environment if the address space is accurately set to be
       32-bit for o32 and n32.
  
! '--with-madd4'
!      On MIPS targets, make '-mmadd4' the default when no '-mno-madd4'
       option is passed.  This is the default.
  
! '--without-madd4'
!      On MIPS targets, make '-mno-madd4' the default when no '-mmadd4'
!      option is passed.  The 'madd4' instruction family can be
       problematic when targeting a combination of cores that implement
       these instructions differently.  There are two known cores that
       implement these as fused operations instead of unfused (where
--- 1402,1420 ----
       applications with 64-bit addressing enabled which affects the
       overflow behaviour of the indexed addressing mode.  GCC will assume
       that ordinary 32-bit arithmetic overflow behaviour is the same
!      whether performed as an ‘addu’ instruction or as part of the
!      address calculation in ‘lwxc1’ type instructions.  This assumption
       holds true in a pure 32-bit environment and can hold true in a
       64-bit environment if the address space is accurately set to be
       32-bit for o32 and n32.
  
! ‘--with-madd4’
!      On MIPS targets, make ‘-mmadd4’ the default when no ‘-mno-madd4’
       option is passed.  This is the default.
  
! ‘--without-madd4’
!      On MIPS targets, make ‘-mno-madd4’ the default when no ‘-mmadd4’
!      option is passed.  The ‘madd4’ instruction family can be
       problematic when targeting a combination of cores that implement
       these instructions differently.  There are two known cores that
       implement these as fused operations instead of unfused (where
*************** option.
*** 1422,1498 ****
       only way to ensure compatible code is generated; this will incur a
       performance penalty.
  
! '--with-msa'
!      On MIPS targets, make '-mmsa' the default when no '-mno-msa' option
       is passed.
  
! '--without-msa'
!      On MIPS targets, make '-mno-msa' the default when no '-mmsa' option
       is passed.  This is the default.
  
! '--with-mips-plt'
       On MIPS targets, make use of copy relocations and PLTs.  These
       features are extensions to the traditional SVR4-based MIPS ABIs and
       require support from GNU binutils and the runtime C library.
  
! '--with-stack-clash-protection-guard-size=SIZE'
       On certain targets this option sets the default stack clash
       protection guard size as a power of two in bytes.  On AArch64 SIZE
       is required to be either 12 (4KB) or 16 (64KB).
  
! '--with-isa-spec=ISA-SPEC-STRING'
       On RISC-V targets specify the default version of the RISC-V
       Unprivileged (formerly User-Level) ISA specification to produce
       code conforming to.  The possibilities for ISA-SPEC-STRING are:
!      '2.2'
            Produce code conforming to version 2.2.
!      '20190608'
            Produce code conforming to version 20190608.
!      '20191213'
            Produce code conforming to version 20191213.
       In the absence of this configuration option the default version is
       20191213.
  
! '--enable-__cxa_atexit'
       Define if you want to use __cxa_atexit, rather than atexit, to
       register C++ destructors for local statics and global objects.
       This is essential for fully standards-compliant handling of
       destructors, but requires __cxa_atexit in libc.  This option is
       currently only available on systems with GNU libc.  When enabled,
!      this will cause '-fuse-cxa-atexit' to be passed by default.
  
! '--enable-gnu-indirect-function'
!      Define if you want to enable the 'ifunc' attribute.  This option is
       currently only available on systems with GNU libc on certain
       targets.
  
! '--enable-target-optspace'
       Specify that target libraries should be optimized for code space
       instead of code speed.  This is the default for the m32r platform.
  
! '--with-cpp-install-dir=DIRNAME'
!      Specify that the user visible 'cpp' program should be installed in
!      'PREFIX/DIRNAME/cpp', in addition to BINDIR.
  
! '--enable-comdat'
       Enable COMDAT group support.  This is primarily used to override
       the automatically detected value.
  
! '--enable-initfini-array'
!      Force the use of sections '.init_array' and '.fini_array' (instead
!      of '.init' and '.fini') for constructors and destructors.  Option
!      '--disable-initfini-array' has the opposite effect.  If neither
       option is specified, the configure script will try to guess whether
!      the '.init_array' and '.fini_array' sections are supported and, if
       they are, use them.
  
! '--enable-link-mutex'
       When building GCC, use a mutex to avoid linking the compilers for
       multiple languages at the same time, to avoid thrashing on build
       systems with limited free memory.  The default is not to use such a
       mutex.
  
! '--enable-link-serialization'
       When building GCC, use make dependencies to serialize linking the
       compilers for multiple languages, to avoid thrashing on build
       systems with limited free memory.  The default is not to add such
--- 1422,1498 ----
       only way to ensure compatible code is generated; this will incur a
       performance penalty.
  
! ‘--with-msa’
!      On MIPS targets, make ‘-mmsa’ the default when no ‘-mno-msa’ option
       is passed.
  
! ‘--without-msa’
!      On MIPS targets, make ‘-mno-msa’ the default when no ‘-mmsa’ option
       is passed.  This is the default.
  
! ‘--with-mips-plt’
       On MIPS targets, make use of copy relocations and PLTs.  These
       features are extensions to the traditional SVR4-based MIPS ABIs and
       require support from GNU binutils and the runtime C library.
  
! ‘--with-stack-clash-protection-guard-size=SIZE’
       On certain targets this option sets the default stack clash
       protection guard size as a power of two in bytes.  On AArch64 SIZE
       is required to be either 12 (4KB) or 16 (64KB).
  
! ‘--with-isa-spec=ISA-SPEC-STRING’
       On RISC-V targets specify the default version of the RISC-V
       Unprivileged (formerly User-Level) ISA specification to produce
       code conforming to.  The possibilities for ISA-SPEC-STRING are:
!      ‘2.2’
            Produce code conforming to version 2.2.
!      ‘20190608’
            Produce code conforming to version 20190608.
!      ‘20191213’
            Produce code conforming to version 20191213.
       In the absence of this configuration option the default version is
       20191213.
  
! ‘--enable-__cxa_atexit’
       Define if you want to use __cxa_atexit, rather than atexit, to
       register C++ destructors for local statics and global objects.
       This is essential for fully standards-compliant handling of
       destructors, but requires __cxa_atexit in libc.  This option is
       currently only available on systems with GNU libc.  When enabled,
!      this will cause ‘-fuse-cxa-atexit’ to be passed by default.
  
! ‘--enable-gnu-indirect-function’
!      Define if you want to enable the ‘ifunc’ attribute.  This option is
       currently only available on systems with GNU libc on certain
       targets.
  
! ‘--enable-target-optspace’
       Specify that target libraries should be optimized for code space
       instead of code speed.  This is the default for the m32r platform.
  
! ‘--with-cpp-install-dir=DIRNAME’
!      Specify that the user visible ‘cpp’ program should be installed in
!      ‘PREFIX/DIRNAME/cpp’, in addition to BINDIR.
  
! ‘--enable-comdat’
       Enable COMDAT group support.  This is primarily used to override
       the automatically detected value.
  
! ‘--enable-initfini-array’
!      Force the use of sections ‘.init_array’ and ‘.fini_array’ (instead
!      of ‘.init’ and ‘.fini’) for constructors and destructors.  Option
!      ‘--disable-initfini-array’ has the opposite effect.  If neither
       option is specified, the configure script will try to guess whether
!      the ‘.init_array’ and ‘.fini_array’ sections are supported and, if
       they are, use them.
  
! ‘--enable-link-mutex’
       When building GCC, use a mutex to avoid linking the compilers for
       multiple languages at the same time, to avoid thrashing on build
       systems with limited free memory.  The default is not to use such a
       mutex.
  
! ‘--enable-link-serialization’
       When building GCC, use make dependencies to serialize linking the
       compilers for multiple languages, to avoid thrashing on build
       systems with limited free memory.  The default is not to add such
*************** option.
*** 1501,1529 ****
       allow that number of concurrent link processes for the large
       binaries.
  
! '--enable-maintainer-mode'
       The build rules that regenerate the Autoconf and Automake output
!      files as well as the GCC master message catalog 'gcc.pot' are
       normally disabled.  This is because it can only be rebuilt if the
       complete source tree is present.  If you have changed the sources
       and want to rebuild the catalog, configuring with
!      '--enable-maintainer-mode' will enable this.  Note that you need a
!      recent version of the 'gettext' tools to do so.
  
! '--disable-bootstrap'
       For a native build, the default configuration is to perform a
!      3-stage bootstrap of the compiler when 'make' is invoked, testing
       that GCC can compile itself correctly.  If you want to disable this
!      process, you can configure with '--disable-bootstrap'.
  
! '--enable-bootstrap'
       In special cases, you may want to perform a 3-stage build even if
       the target and host triplets are different.  This is possible when
       the host can run code compiled for the target (e.g. host is
       i686-linux, target is i486-linux).  Starting from GCC 4.2, to do
!      this you have to configure explicitly with '--enable-bootstrap'.
  
! '--enable-generated-files-in-srcdir'
       Neither the .c and .h files that are generated from Bison and flex
       nor the info manuals and man pages that are built from the .texi
       files are present in the repository development tree.  When
--- 1501,1529 ----
       allow that number of concurrent link processes for the large
       binaries.
  
! ‘--enable-maintainer-mode’
       The build rules that regenerate the Autoconf and Automake output
!      files as well as the GCC master message catalog ‘gcc.pot’ are
       normally disabled.  This is because it can only be rebuilt if the
       complete source tree is present.  If you have changed the sources
       and want to rebuild the catalog, configuring with
!      ‘--enable-maintainer-mode’ will enable this.  Note that you need a
!      recent version of the ‘gettext’ tools to do so.
  
! ‘--disable-bootstrap’
       For a native build, the default configuration is to perform a
!      3-stage bootstrap of the compiler when ‘make’ is invoked, testing
       that GCC can compile itself correctly.  If you want to disable this
!      process, you can configure with ‘--disable-bootstrap’.
  
! ‘--enable-bootstrap’
       In special cases, you may want to perform a 3-stage build even if
       the target and host triplets are different.  This is possible when
       the host can run code compiled for the target (e.g. host is
       i686-linux, target is i486-linux).  Starting from GCC 4.2, to do
!      this you have to configure explicitly with ‘--enable-bootstrap’.
  
! ‘--enable-generated-files-in-srcdir’
       Neither the .c and .h files that are generated from Bison and flex
       nor the info manuals and man pages that are built from the .texi
       files are present in the repository development tree.  When
*************** option.
*** 1532,1723 ****
       directory, which allows for the source to be in a readonly
       directory.
  
!      If you configure with '--enable-generated-files-in-srcdir' then
       those generated files will go into the source directory.  This is
       mainly intended for generating release or prerelease tarballs of
       the GCC sources, since it is not a requirement that the users of
       source releases to have flex, Bison, or makeinfo.
  
! '--enable-version-specific-runtime-libs'
       Specify that runtime libraries should be installed in the compiler
!      specific subdirectory ('LIBDIR/gcc') rather than the usual places.
!      In addition, 'libstdc++''s include files will be installed into
!      'LIBDIR' unless you overruled it by using
!      '--with-gxx-include-dir=DIRNAME'.  Using this option is
       particularly useful if you intend to use several versions of GCC in
!      parallel.  The default is 'yes' for 'libada', and 'no' for the
       remaining libraries.
  
! '--with-aix-soname='aix', 'svr4' or 'both''
!      Traditional AIX shared library versioning (versioned 'Shared
!      Object' files as members of unversioned 'Archive Library' files
!      named 'lib.a') causes numerous headaches for package managers.
!      However, 'Import Files' as members of 'Archive Library' files allow
       for *filename-based versioning* of shared libraries as seen on
       Linux/SVR4, where this is called the "SONAME". But as they prevent
!      static linking, 'Import Files' may be used with 'Runtime Linking'
!      only, where the linker does search for 'libNAME.so' before
!      'libNAME.a' library filenames with the '-lNAME' linker flag.
  
       For detailed information please refer to the AIX ld Command
       reference.
  
       As long as shared library creation is enabled, upon:
!      '--with-aix-soname=aix'
!      '--with-aix-soname=both'
!           A (traditional AIX) 'Shared Archive Library' file is created:
!              * using the 'libNAME.a' filename scheme
!              * with the 'Shared Object' file as archive member named
!                'libNAME.so.V' (except for 'libgcc_s', where the 'Shared
!                Object' file is named 'shr.o' for backwards
                 compatibility), which
!                   - is used for runtime loading from inside the
!                     'libNAME.a' file
!                   - is used for dynamic loading via
!                     'dlopen("libNAME.a(libNAME.so.V)", RTLD_MEMBER)'
!                   - is used for shared linking
!                   - is used for static linking, so no separate 'Static
!                     Archive Library' file is needed
!      '--with-aix-soname=both'
!      '--with-aix-soname=svr4'
!           A (second) 'Shared Archive Library' file is created:
!              * using the 'libNAME.so.V' filename scheme
!              * with the 'Shared Object' file as archive member named
!                'shr.o', which
!                   - is created with the '-G linker flag'
!                   - has the 'F_LOADONLY' flag set
!                   - is used for runtime loading from inside the
!                     'libNAME.so.V' file
!                   - is used for dynamic loading via
!                     'dlopen("libNAME.so.V(shr.o)", RTLD_MEMBER)'
!              * with the 'Import File' as archive member named 'shr.imp',
                 which
!                   - refers to 'libNAME.so.V(shr.o)' as the "SONAME", to
!                     be recorded in the 'Loader Section' of subsequent
                      binaries
!                   - indicates whether 'libNAME.so.V(shr.o)' is 32 or 64
                      bit
!                   - lists all the public symbols exported by
!                     'lib.so.V(shr.o)', eventually decorated with the
!                     ''weak' Keyword'
!                   - is necessary for shared linking against
!                     'lib.so.V(shr.o)'
!           A symbolic link using the 'libNAME.so' filename scheme is
            created:
!              * pointing to the 'libNAME.so.V' 'Shared Archive Library'
                 file
!              * to permit the 'ld Command' to find 'lib.so.V(shr.imp)'
!                via the '-lNAME' argument (requires 'Runtime Linking' to
                 be enabled)
!              * to permit dynamic loading of 'lib.so.V(shr.o)' without
                 the need to specify the version number via
!                'dlopen("libNAME.so(shr.o)", RTLD_MEMBER)'
  
       As long as static library creation is enabled, upon:
!      '--with-aix-soname=svr4'
!           A 'Static Archive Library' is created:
!              * using the 'libNAME.a' filename scheme
!              * with all the 'Static Object' files as archive members,
                 which
!                   - are used for static linking
  
!      While the aix-soname='svr4' option does not create 'Shared Object'
!      files as members of unversioned 'Archive Library' files any more,
!      package managers still are responsible to transfer 'Shared Object'
       files found as member of a previously installed unversioned
!      'Archive Library' file into the newly installed 'Archive Library'
       file with the same filename.
  
!      _WARNING:_ Creating 'Shared Object' files with 'Runtime Linking'
!      enabled may bloat the TOC, eventually leading to 'TOC overflow'
!      errors, requiring the use of either the '-Wl,-bbigtoc' linker flag
!      (seen to break with the 'GDB' debugger) or some of the TOC-related
       compiler flags, *Note RS/6000 and PowerPC Options: (gcc)RS/6000 and
       PowerPC Options.
  
!      '--with-aix-soname' is currently supported by 'libgcc_s' only, so
       this option is still experimental and not for normal use yet.
  
!      Default is the traditional behavior '--with-aix-soname='aix''.
  
! '--enable-languages=LANG1,LANG2,...'
       Specify that only a particular subset of compilers and their
       runtime libraries should be built.  For a list of valid values for
!      LANGN you can issue the following command in the 'gcc' directory of
       your GCC source tree:
            grep ^language= */config-lang.in
!      Currently, you can use any of the following: 'all', 'default',
!      'ada', 'c', 'c++', 'd', 'fortran', 'go', 'jit', 'lto', 'm2',
!      'objc', 'obj-c++'.  Building the Ada compiler has special
       requirements, see below.  If you do not pass this flag, or specify
!      the option 'default', then the default languages available in the
!      'gcc' sub-tree will be configured.  Ada, D, Go, Jit, Objective-C++
       and Modula-2 are not default languages.  LTO is not a default
!      language, but is built by default because '--enable-lto' is enabled
!      by default.  The other languages are default languages.  If 'all'
       is specified, then all available languages are built.  An exception
!      is 'jit' language, which requires '--enable-host-shared' to be
!      included with 'all'.
  
! '--enable-stage1-languages=LANG1,LANG2,...'
       Specify that a particular subset of compilers and their runtime
       libraries should be built with the system C compiler during stage 1
       of the bootstrap process, rather than only in later stages with the
       bootstrapped C compiler.  The list of valid values is the same as
!      for '--enable-languages', and the option 'all' will select all of
!      the languages enabled by '--enable-languages'.  This option is
       primarily useful for GCC development; for instance, when a
       development version of the compiler cannot bootstrap due to
       compiler bugs, or when one is debugging front ends other than the C
       front end.  When this option is used, one can then build the target
       libraries for the specified languages with the stage-1 compiler by
!      using 'make stage1-bubble all-target', or run the testsuite on the
!      stage-1 compiler for the specified languages using 'make
!      stage1-start check-gcc'.
  
! '--disable-libada'
       Specify that the run-time libraries and tools used by GNAT should
       not be built.  This can be useful for debugging, or for
       compatibility with previous Ada build procedures, when it was
!      required to explicitly do a 'make -C gcc gnatlib_and_tools'.
  
! '--disable-libgm2'
       Specify that the run-time libraries and tools used by Modula-2
       should not be built.  This can be useful for debugging.
  
! '--disable-libsanitizer'
       Specify that the run-time libraries for the various sanitizers
       should not be built.
  
! '--disable-libssp'
       Specify that the run-time libraries for stack smashing protection
       should not be built or linked against.  On many targets library
       support is provided by the C library instead.
  
! '--disable-libquadmath'
       Specify that the GCC quad-precision math library should not be
       built.  On some systems, the library is required to be linkable
       when building the Fortran front end, unless
!      '--disable-libquadmath-support' is used.
  
! '--disable-libquadmath-support'
!      Specify that the Fortran front end and 'libgfortran' do not add
!      support for 'libquadmath' on systems supporting it.
  
! '--disable-libgomp'
       Specify that the GNU Offloading and Multi Processing Runtime
       Library should not be built.
  
! '--disable-libvtv'
       Specify that the run-time libraries used by vtable verification
       should not be built.
  
! '--with-dwarf2'
       Specify that the compiler should use DWARF debugging information as
       the default; the exact DWARF version that is the default is
       target-specific.
  
! '--with-advance-toolchain=AT'
       On 64-bit PowerPC Linux systems, configure the compiler to use the
       header files, library files, and the dynamic linker from the
       Advance Toolchain release AT instead of the default versions that
--- 1532,1723 ----
       directory, which allows for the source to be in a readonly
       directory.
  
!      If you configure with ‘--enable-generated-files-in-srcdir’ then
       those generated files will go into the source directory.  This is
       mainly intended for generating release or prerelease tarballs of
       the GCC sources, since it is not a requirement that the users of
       source releases to have flex, Bison, or makeinfo.
  
! ‘--enable-version-specific-runtime-libs’
       Specify that runtime libraries should be installed in the compiler
!      specific subdirectory (‘LIBDIR/gcc’) rather than the usual places.
!      In addition, ‘libstdc++’'s include files will be installed into
!      ‘LIBDIR’ unless you overruled it by using
!      ‘--with-gxx-include-dir=DIRNAME’.  Using this option is
       particularly useful if you intend to use several versions of GCC in
!      parallel.  The default is ‘yes’ for ‘libada’, and ‘no’ for the
       remaining libraries.
  
! ‘--with-aix-soname=‘aix’, ‘svr4’ or ‘both’’
!      Traditional AIX shared library versioning (versioned ‘Shared
!      Object’ files as members of unversioned ‘Archive Library’ files
!      named ‘lib.a’) causes numerous headaches for package managers.
!      However, ‘Import Files’ as members of ‘Archive Library’ files allow
       for *filename-based versioning* of shared libraries as seen on
       Linux/SVR4, where this is called the "SONAME". But as they prevent
!      static linking, ‘Import Files’ may be used with ‘Runtime Linking’
!      only, where the linker does search for ‘libNAME.so’ before
!      ‘libNAME.a’ library filenames with the ‘-lNAME’ linker flag.
  
       For detailed information please refer to the AIX ld Command
       reference.
  
       As long as shared library creation is enabled, upon:
!      ‘--with-aix-soname=aix’
!      ‘--with-aix-soname=both’
!           A (traditional AIX) ‘Shared Archive Library’ file is created:
!              • using the ‘libNAME.a’ filename scheme
!              • with the ‘Shared Object’ file as archive member named
!                ‘libNAME.so.V’ (except for ‘libgcc_s’, where the ‘Shared
!                Object’ file is named ‘shr.o’ for backwards
                 compatibility), which
!                   − is used for runtime loading from inside the
!                     ‘libNAME.a’ file
!                   − is used for dynamic loading via
!                     ‘dlopen("libNAME.a(libNAME.so.V)", RTLD_MEMBER)’
!                   − is used for shared linking
!                   − is used for static linking, so no separate ‘Static
!                     Archive Library’ file is needed
!      ‘--with-aix-soname=both’
!      ‘--with-aix-soname=svr4’
!           A (second) ‘Shared Archive Library’ file is created:
!              • using the ‘libNAME.so.V’ filename scheme
!              • with the ‘Shared Object’ file as archive member named
!                ‘shr.o’, which
!                   − is created with the ‘-G linker flag’
!                   − has the ‘F_LOADONLY’ flag set
!                   − is used for runtime loading from inside the
!                     ‘libNAME.so.V’ file
!                   − is used for dynamic loading via
!                     ‘dlopen("libNAME.so.V(shr.o)", RTLD_MEMBER)’
!              • with the ‘Import File’ as archive member named ‘shr.imp’,
                 which
!                   − refers to ‘libNAME.so.V(shr.o)’ as the "SONAME", to
!                     be recorded in the ‘Loader Section’ of subsequent
                      binaries
!                   − indicates whether ‘libNAME.so.V(shr.o)’ is 32 or 64
                      bit
!                   − lists all the public symbols exported by
!                     ‘lib.so.V(shr.o)’, eventually decorated with the
!                     ‘‘weak’ Keyword’
!                   − is necessary for shared linking against
!                     ‘lib.so.V(shr.o)’
!           A symbolic link using the ‘libNAME.so’ filename scheme is
            created:
!              • pointing to the ‘libNAME.so.V’ ‘Shared Archive Library’
                 file
!              • to permit the ‘ld Command’ to find ‘lib.so.V(shr.imp)’
!                via the ‘-lNAME’ argument (requires ‘Runtime Linking’ to
                 be enabled)
!              • to permit dynamic loading of ‘lib.so.V(shr.o)’ without
                 the need to specify the version number via
!                ‘dlopen("libNAME.so(shr.o)", RTLD_MEMBER)’
  
       As long as static library creation is enabled, upon:
!      ‘--with-aix-soname=svr4’
!           A ‘Static Archive Library’ is created:
!              • using the ‘libNAME.a’ filename scheme
!              • with all the ‘Static Object’ files as archive members,
                 which
!                   − are used for static linking
  
!      While the aix-soname=‘svr4’ option does not create ‘Shared Object’
!      files as members of unversioned ‘Archive Library’ files any more,
!      package managers still are responsible to transfer ‘Shared Object’
       files found as member of a previously installed unversioned
!      ‘Archive Library’ file into the newly installed ‘Archive Library’
       file with the same filename.
  
!      _WARNING:_ Creating ‘Shared Object’ files with ‘Runtime Linking’
!      enabled may bloat the TOC, eventually leading to ‘TOC overflow’
!      errors, requiring the use of either the ‘-Wl,-bbigtoc’ linker flag
!      (seen to break with the ‘GDB’ debugger) or some of the TOC-related
       compiler flags, *Note RS/6000 and PowerPC Options: (gcc)RS/6000 and
       PowerPC Options.
  
!      ‘--with-aix-soname’ is currently supported by ‘libgcc_s’ only, so
       this option is still experimental and not for normal use yet.
  
!      Default is the traditional behavior ‘--with-aix-soname=‘aix’’.
  
! ‘--enable-languages=LANG1,LANG2,...’
       Specify that only a particular subset of compilers and their
       runtime libraries should be built.  For a list of valid values for
!      LANGN you can issue the following command in the ‘gcc’ directory of
       your GCC source tree:
            grep ^language= */config-lang.in
!      Currently, you can use any of the following: ‘all’, ‘default’,
!      ‘ada’, ‘c’, ‘c++’, ‘d’, ‘fortran’, ‘go’, ‘jit’, ‘lto’, ‘m2’,
!      ‘objc’, ‘obj-c++’.  Building the Ada compiler has special
       requirements, see below.  If you do not pass this flag, or specify
!      the option ‘default’, then the default languages available in the
!      ‘gcc’ sub-tree will be configured.  Ada, D, Go, Jit, Objective-C++
       and Modula-2 are not default languages.  LTO is not a default
!      language, but is built by default because ‘--enable-lto’ is enabled
!      by default.  The other languages are default languages.  If ‘all’
       is specified, then all available languages are built.  An exception
!      is ‘jit’ language, which requires ‘--enable-host-shared’ to be
!      included with ‘all’.
  
! ‘--enable-stage1-languages=LANG1,LANG2,...’
       Specify that a particular subset of compilers and their runtime
       libraries should be built with the system C compiler during stage 1
       of the bootstrap process, rather than only in later stages with the
       bootstrapped C compiler.  The list of valid values is the same as
!      for ‘--enable-languages’, and the option ‘all’ will select all of
!      the languages enabled by ‘--enable-languages’.  This option is
       primarily useful for GCC development; for instance, when a
       development version of the compiler cannot bootstrap due to
       compiler bugs, or when one is debugging front ends other than the C
       front end.  When this option is used, one can then build the target
       libraries for the specified languages with the stage-1 compiler by
!      using ‘make stage1-bubble all-target’, or run the testsuite on the
!      stage-1 compiler for the specified languages using ‘make
!      stage1-start check-gcc’.
  
! ‘--disable-libada’
       Specify that the run-time libraries and tools used by GNAT should
       not be built.  This can be useful for debugging, or for
       compatibility with previous Ada build procedures, when it was
!      required to explicitly do a ‘make -C gcc gnatlib_and_tools’.
  
! ‘--disable-libgm2’
       Specify that the run-time libraries and tools used by Modula-2
       should not be built.  This can be useful for debugging.
  
! ‘--disable-libsanitizer’
       Specify that the run-time libraries for the various sanitizers
       should not be built.
  
! ‘--disable-libssp’
       Specify that the run-time libraries for stack smashing protection
       should not be built or linked against.  On many targets library
       support is provided by the C library instead.
  
! ‘--disable-libquadmath’
       Specify that the GCC quad-precision math library should not be
       built.  On some systems, the library is required to be linkable
       when building the Fortran front end, unless
!      ‘--disable-libquadmath-support’ is used.
  
! ‘--disable-libquadmath-support’
!      Specify that the Fortran front end and ‘libgfortran’ do not add
!      support for ‘libquadmath’ on systems supporting it.
  
! ‘--disable-libgomp’
       Specify that the GNU Offloading and Multi Processing Runtime
       Library should not be built.
  
! ‘--disable-libvtv’
       Specify that the run-time libraries used by vtable verification
       should not be built.
  
! ‘--with-dwarf2’
       Specify that the compiler should use DWARF debugging information as
       the default; the exact DWARF version that is the default is
       target-specific.
  
! ‘--with-advance-toolchain=AT’
       On 64-bit PowerPC Linux systems, configure the compiler to use the
       header files, library files, and the dynamic linker from the
       Advance Toolchain release AT instead of the default versions that
*************** option.
*** 1725,1732 ****
       intended for the developers of GCC, and it is not intended for
       general use.
  
! '--enable-targets=all'
! '--enable-targets=TARGET_LIST'
       Some GCC targets, e.g. powerpc64-linux, build bi-arch compilers.
       These are compilers that are able to generate either 64-bit or
       32-bit code.  Typically, the corresponding 32-bit target, e.g.
--- 1725,1732 ----
       intended for the developers of GCC, and it is not intended for
       general use.
  
! ‘--enable-targets=all’
! ‘--enable-targets=TARGET_LIST’
       Some GCC targets, e.g. powerpc64-linux, build bi-arch compilers.
       These are compilers that are able to generate either 64-bit or
       32-bit code.  Typically, the corresponding 32-bit target, e.g.
*************** option.
*** 1739,1804 ****
       affects sparc-linux, powerpc-linux, x86-linux, mips-linux and
       s390-linux.
  
! '--enable-default-pie'
!      Turn on '-fPIE' and '-pie' by default.
  
! '--enable-secureplt'
!      This option enables '-msecure-plt' by default for powerpc-linux.
       *Note RS/6000 and PowerPC Options: (gcc)RS/6000 and PowerPC
       Options,
  
! '--enable-default-ssp'
!      Turn on '-fstack-protector-strong' by default.
  
! '--enable-cld'
!      This option enables '-mcld' by default for 32-bit x86 targets.
       *Note i386 and x86-64 Options: (gcc)i386 and x86-64 Options,
  
! '--enable-large-address-aware'
!      The '--enable-large-address-aware' option arranges for MinGW
!      executables to be linked using the '--large-address-aware' option,
       that enables the use of more than 2GB of memory.  If GCC is
       configured with this option, its effects can be reversed by passing
!      the '-Wl,--disable-large-address-aware' option to the so-configured
       compiler driver.
  
! '--enable-win32-registry'
! '--enable-win32-registry=KEY'
! '--disable-win32-registry'
!      The '--enable-win32-registry' option enables Microsoft
       Windows-hosted GCC to look up installations paths in the registry
       using the following key:
  
            HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\KEY
  
       KEY defaults to GCC version number, and can be overridden by the
!      '--enable-win32-registry=KEY' option.  Vendors and distributors who
       use custom installers are encouraged to provide a different key,
       perhaps one comprised of vendor name and GCC version number, to
       avoid conflict with existing installations.  This feature is
       enabled by default, and can be disabled by
!      '--disable-win32-registry' option.  This option has no effect on
       the other hosts.
  
! '--nfp'
       Specify that the machine does not have a floating point unit.  This
!      option only applies to 'm68k-sun-sunosN'.  On any other system,
!      '--nfp' has no effect.
  
! '--enable-werror'
! '--disable-werror'
! '--enable-werror=yes'
! '--enable-werror=no'
       When you specify this option, it controls whether certain files in
!      the compiler are built with '-Werror' in bootstrap stage2 and
!      later.  If you don't specify it, '-Werror' is turned on for the
       main development trunk.  However it defaults to off for release
       branches and final releases.  The specific files which get
!      '-Werror' are controlled by the Makefiles.
  
! '--enable-checking'
! '--disable-checking'
! '--enable-checking=LIST'
       This option controls performing internal consistency checks in the
       compiler.  It does not change the generated code, but adds error
       checking of the requested complexity.  This slows down the compiler
--- 1739,1804 ----
       affects sparc-linux, powerpc-linux, x86-linux, mips-linux and
       s390-linux.
  
! ‘--enable-default-pie’
!      Turn on ‘-fPIE’ and ‘-pie’ by default.
  
! ‘--enable-secureplt’
!      This option enables ‘-msecure-plt’ by default for powerpc-linux.
       *Note RS/6000 and PowerPC Options: (gcc)RS/6000 and PowerPC
       Options,
  
! ‘--enable-default-ssp’
!      Turn on ‘-fstack-protector-strong’ by default.
  
! ‘--enable-cld’
!      This option enables ‘-mcld’ by default for 32-bit x86 targets.
       *Note i386 and x86-64 Options: (gcc)i386 and x86-64 Options,
  
! ‘--enable-large-address-aware’
!      The ‘--enable-large-address-aware’ option arranges for MinGW
!      executables to be linked using the ‘--large-address-aware’ option,
       that enables the use of more than 2GB of memory.  If GCC is
       configured with this option, its effects can be reversed by passing
!      the ‘-Wl,--disable-large-address-aware’ option to the so-configured
       compiler driver.
  
! ‘--enable-win32-registry’
! ‘--enable-win32-registry=KEY’
! ‘--disable-win32-registry’
!      The ‘--enable-win32-registry’ option enables Microsoft
       Windows-hosted GCC to look up installations paths in the registry
       using the following key:
  
            HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\KEY
  
       KEY defaults to GCC version number, and can be overridden by the
!      ‘--enable-win32-registry=KEY’ option.  Vendors and distributors who
       use custom installers are encouraged to provide a different key,
       perhaps one comprised of vendor name and GCC version number, to
       avoid conflict with existing installations.  This feature is
       enabled by default, and can be disabled by
!      ‘--disable-win32-registry’ option.  This option has no effect on
       the other hosts.
  
! ‘--nfp’
       Specify that the machine does not have a floating point unit.  This
!      option only applies to ‘m68k-sun-sunosN’.  On any other system,
!      ‘--nfp’ has no effect.
  
! ‘--enable-werror’
! ‘--disable-werror’
! ‘--enable-werror=yes’
! ‘--enable-werror=no’
       When you specify this option, it controls whether certain files in
!      the compiler are built with ‘-Werror’ in bootstrap stage2 and
!      later.  If you don't specify it, ‘-Werror’ is turned on for the
       main development trunk.  However it defaults to off for release
       branches and final releases.  The specific files which get
!      ‘-Werror’ are controlled by the Makefiles.
  
! ‘--enable-checking’
! ‘--disable-checking’
! ‘--enable-checking=LIST’
       This option controls performing internal consistency checks in the
       compiler.  It does not change the generated code, but adds error
       checking of the requested complexity.  This slows down the compiler
*************** option.
*** 1807,1899 ****
  
       When the option is not specified, the active set of checks depends
       on context.  Namely, bootstrap stage 1 defaults to
!      '--enable-checking=yes', builds from release branches or release
!      archives default to '--enable-checking=release', and otherwise
!      '--enable-checking=yes,extra' is used.  When the option is
       specified without a LIST, the result is the same as
!      '--enable-checking=yes'.  Likewise, '--disable-checking' is
!      equivalent to '--enable-checking=no'.
  
!      The categories of checks available in LIST are 'yes' (most common
!      checks 'assert,misc,gc,gimple,rtlflag,runtime,tree,types'), 'no'
!      (no checks at all), 'all' (all but 'valgrind'), 'release' (cheapest
!      checks 'assert,runtime') or 'none' (same as 'no').  'release'
!      checks are always on and to disable them '--disable-checking' or
!      '--enable-checking=no[,]' must be explicitly
       requested.  Disabling assertions makes the compiler and runtime
       slightly faster but increases the risk of undetected internal
       errors causing wrong code to be generated.
  
!      Individual checks can be enabled with these flags: 'assert', 'df',
!      'extra', 'fold', 'gc', 'gcac', 'gimple', 'misc', 'rtl', 'rtlflag',
!      'runtime', 'tree', 'types' and 'valgrind'.  'extra' extends 'misc'
       checking with extra checks that might affect code generation and
       should therefore not differ between stage1 and later stages in
       bootstrap.
  
!      The 'valgrind' check requires the external 'valgrind' simulator,
!      available from .  The 'rtl' checks are
!      expensive and the 'df', 'gcac' and 'valgrind' checks are very
       expensive.
  
! '--disable-stage1-checking'
! '--enable-stage1-checking'
! '--enable-stage1-checking=LIST'
       This option affects only bootstrap build.  If no
!      '--enable-checking' option is specified the stage1 compiler is
!      built with 'yes' checking enabled, otherwise the stage1 checking
!      flags are the same as specified by '--enable-checking'.  To build
       the stage1 compiler with different checking options use
!      '--enable-stage1-checking'.  The list of checking options is the
!      same as for '--enable-checking'.  If your system is too slow or too
       small to bootstrap a released compiler with checking for stage1
!      enabled, you can use '--disable-stage1-checking' to disable
       checking for the stage1 compiler.
  
! '--enable-coverage'
! '--enable-coverage=LEVEL'
       With this option, the compiler is built to collect self coverage
       information, every time it is run.  This is for internal
       development purposes, and only works when the compiler is being
       built with gcc.  The LEVEL argument controls whether the compiler
!      is built optimized or not, values are 'opt' and 'noopt'.  For
       coverage analysis you want to disable optimization, for performance
       analysis you want to enable optimization.  When coverage is
       enabled, the default level is without optimization.
  
! '--enable-gather-detailed-mem-stats'
       When this option is specified more detailed information on memory
       allocation is gathered.  This information is printed when using
!      '-fmem-report'.
  
! '--enable-valgrind-annotations'
       Mark selected memory related operations in the compiler when run
       under valgrind to suppress false positives.
  
! '--enable-nls'
! '--disable-nls'
!      The '--enable-nls' option enables Native Language Support (NLS),
       which lets GCC output diagnostics in languages other than American
       English.  Native Language Support is enabled by default if not
!      doing a canadian cross build.  The '--disable-nls' option disables
       NLS.
  
! '--with-included-gettext'
!      If NLS is enabled, the '--with-included-gettext' option causes the
!      build procedure to prefer its copy of GNU 'gettext'.
  
! '--with-catgets'
!      If NLS is enabled, and if the host lacks 'gettext' but has the
!      inferior 'catgets' interface, the GCC build procedure normally
!      ignores 'catgets' and instead uses GCC's copy of the GNU 'gettext'
!      library.  The '--with-catgets' option causes the build procedure to
!      use the host's 'catgets' in this situation.
  
! '--with-libiconv-prefix=DIR'
!      Search for libiconv header files in 'DIR/include' and libiconv
!      library files in 'DIR/lib'.
  
! '--enable-obsolete'
       Enable configuration for an obsoleted system.  If you attempt to
       configure GCC for a system (build, host, or target) which has been
       obsoleted, and you do not specify this flag, configure will halt
--- 1807,1899 ----
  
       When the option is not specified, the active set of checks depends
       on context.  Namely, bootstrap stage 1 defaults to
!      ‘--enable-checking=yes’, builds from release branches or release
!      archives default to ‘--enable-checking=release’, and otherwise
!      ‘--enable-checking=yes,extra’ is used.  When the option is
       specified without a LIST, the result is the same as
!      ‘--enable-checking=yes’.  Likewise, ‘--disable-checking’ is
!      equivalent to ‘--enable-checking=no’.
  
!      The categories of checks available in LIST are ‘yes’ (most common
!      checks ‘assert,misc,gc,gimple,rtlflag,runtime,tree,types’), ‘no’
!      (no checks at all), ‘all’ (all but ‘valgrind’), ‘release’ (cheapest
!      checks ‘assert,runtime’) or ‘none’ (same as ‘no’).  ‘release’
!      checks are always on and to disable them ‘--disable-checking’ or
!      ‘--enable-checking=no[,]’ must be explicitly
       requested.  Disabling assertions makes the compiler and runtime
       slightly faster but increases the risk of undetected internal
       errors causing wrong code to be generated.
  
!      Individual checks can be enabled with these flags: ‘assert’, ‘df’,
!      ‘extra’, ‘fold’, ‘gc’, ‘gcac’, ‘gimple’, ‘misc’, ‘rtl’, ‘rtlflag’,
!      ‘runtime’, ‘tree’, ‘types’ and ‘valgrind’.  ‘extra’ extends ‘misc’
       checking with extra checks that might affect code generation and
       should therefore not differ between stage1 and later stages in
       bootstrap.
  
!      The ‘valgrind’ check requires the external ‘valgrind’ simulator,
!      available from .  The ‘rtl’ checks are
!      expensive and the ‘df’, ‘gcac’ and ‘valgrind’ checks are very
       expensive.
  
! ‘--disable-stage1-checking’
! ‘--enable-stage1-checking’
! ‘--enable-stage1-checking=LIST’
       This option affects only bootstrap build.  If no
!      ‘--enable-checking’ option is specified the stage1 compiler is
!      built with ‘yes’ checking enabled, otherwise the stage1 checking
!      flags are the same as specified by ‘--enable-checking’.  To build
       the stage1 compiler with different checking options use
!      ‘--enable-stage1-checking’.  The list of checking options is the
!      same as for ‘--enable-checking’.  If your system is too slow or too
       small to bootstrap a released compiler with checking for stage1
!      enabled, you can use ‘--disable-stage1-checking’ to disable
       checking for the stage1 compiler.
  
! ‘--enable-coverage’
! ‘--enable-coverage=LEVEL’
       With this option, the compiler is built to collect self coverage
       information, every time it is run.  This is for internal
       development purposes, and only works when the compiler is being
       built with gcc.  The LEVEL argument controls whether the compiler
!      is built optimized or not, values are ‘opt’ and ‘noopt’.  For
       coverage analysis you want to disable optimization, for performance
       analysis you want to enable optimization.  When coverage is
       enabled, the default level is without optimization.
  
! ‘--enable-gather-detailed-mem-stats’
       When this option is specified more detailed information on memory
       allocation is gathered.  This information is printed when using
!      ‘-fmem-report’.
  
! ‘--enable-valgrind-annotations’
       Mark selected memory related operations in the compiler when run
       under valgrind to suppress false positives.
  
! ‘--enable-nls’
! ‘--disable-nls’
!      The ‘--enable-nls’ option enables Native Language Support (NLS),
       which lets GCC output diagnostics in languages other than American
       English.  Native Language Support is enabled by default if not
!      doing a canadian cross build.  The ‘--disable-nls’ option disables
       NLS.
  
! ‘--with-included-gettext’
!      If NLS is enabled, the ‘--with-included-gettext’ option causes the
!      build procedure to prefer its copy of GNU ‘gettext’.
  
! ‘--with-catgets’
!      If NLS is enabled, and if the host lacks ‘gettext’ but has the
!      inferior ‘catgets’ interface, the GCC build procedure normally
!      ignores ‘catgets’ and instead uses GCC's copy of the GNU ‘gettext’
!      library.  The ‘--with-catgets’ option causes the build procedure to
!      use the host's ‘catgets’ in this situation.
  
! ‘--with-libiconv-prefix=DIR’
!      Search for libiconv header files in ‘DIR/include’ and libiconv
!      library files in ‘DIR/lib’.
  
! ‘--enable-obsolete’
       Enable configuration for an obsoleted system.  If you attempt to
       configure GCC for a system (build, host, or target) which has been
       obsoleted, and you do not specify this flag, configure will halt
*************** option.
*** 1903,2003 ****
       GCC is removed entirely in the next major release, unless someone
       steps forward to maintain the port.
  
! '--enable-decimal-float'
! '--enable-decimal-float=yes'
! '--enable-decimal-float=no'
! '--enable-decimal-float=bid'
! '--enable-decimal-float=dpd'
! '--disable-decimal-float'
       Enable (or disable) support for the C decimal floating point
       extension that is in the IEEE 754-2008 standard.  This is enabled
       by default only on AArch64, PowerPC, i386, and x86_64 GNU/Linux
       systems.  Other systems may also support it, but require the user
       to specifically enable it.  You can optionally control which
!      decimal floating point format is used (either 'bid' or 'dpd').  The
!      'bid' (binary integer decimal) format is default on AArch64, i386
!      and x86_64 systems, and the 'dpd' (densely packed decimal) format
       is default on PowerPC systems.
  
! '--enable-fixed-point'
! '--disable-fixed-point'
       Enable (or disable) support for C fixed-point arithmetic.  This
       option is enabled by default for some targets (such as MIPS) which
       have hardware-support for fixed-point operations.  On other
       targets, you may enable this option manually.
  
! '--with-long-double-128'
!      Specify if 'long double' type should be 128-bit by default on
       selected GNU/Linux architectures.  If using
!      '--without-long-double-128', 'long double' will be by default
!      64-bit, the same as 'double' type.  When neither of these configure
!      options are used, the default will be 128-bit 'long double' when
!      built against GNU C Library 2.4 and later, 64-bit 'long double'
       otherwise.
  
! '--with-long-double-format=ibm'
! '--with-long-double-format=ieee'
!      Specify whether 'long double' uses the IBM extended double format
       or the IEEE 128-bit floating point format on PowerPC Linux systems.
       This configuration switch will only work on little endian PowerPC
       Linux systems and on big endian 64-bit systems where the default
!      cpu is at least power7 (i.e. '--with-cpu=power7',
!      '--with-cpu=power8', or '--with-cpu=power9' is used).
  
!      If you use the '--with-long-double-64' configuration option, the
!      '--with-long-double-format=ibm' and
!      '--with-long-double-format=ieee' options are ignored.
  
!      The default 'long double' format is to use IBM extended double.
       Until all of the libraries are converted to use IEEE 128-bit
       floating point, it is not recommended to use
!      '--with-long-double-format=ieee'.
  
! '--enable-fdpic'
       On SH Linux systems, generate ELF FDPIC code.
  
! '--with-gmp=PATHNAME'
! '--with-gmp-include=PATHNAME'
! '--with-gmp-lib=PATHNAME'
! '--with-mpfr=PATHNAME'
! '--with-mpfr-include=PATHNAME'
! '--with-mpfr-lib=PATHNAME'
! '--with-mpc=PATHNAME'
! '--with-mpc-include=PATHNAME'
! '--with-mpc-lib=PATHNAME'
       If you want to build GCC but do not have the GMP library, the MPFR
       library and/or the MPC library installed in a standard location and
       do not have their sources present in the GCC source tree then you
       can explicitly specify the directory where they are installed
!      ('--with-gmp=GMPINSTALLDIR', '--with-mpfr=MPFRINSTALLDIR',
!      '--with-mpc=MPCINSTALLDIR').  The '--with-gmp=GMPINSTALLDIR' option
!      is shorthand for '--with-gmp-lib=GMPINSTALLDIR/lib' and
!      '--with-gmp-include=GMPINSTALLDIR/include'.  Likewise the
!      '--with-mpfr=MPFRINSTALLDIR' option is shorthand for
!      '--with-mpfr-lib=MPFRINSTALLDIR/lib' and
!      '--with-mpfr-include=MPFRINSTALLDIR/include', also the
!      '--with-mpc=MPCINSTALLDIR' option is shorthand for
!      '--with-mpc-lib=MPCINSTALLDIR/lib' and
!      '--with-mpc-include=MPCINSTALLDIR/include'.  If these shorthand
       assumptions are not correct, you can use the explicit include and
       lib options directly.  You might also need to ensure the shared
       libraries can be found by the dynamic linker when building and
       using GCC, for example by setting the runtime shared library path
!      variable ('LD_LIBRARY_PATH' on GNU/Linux and Solaris systems).
  
       These flags are applicable to the host platform only.  When
       building a cross compiler, they will not be used to configure
       target libraries.
  
! '--with-isl=PATHNAME'
! '--with-isl-include=PATHNAME'
! '--with-isl-lib=PATHNAME'
       If you do not have the isl library installed in a standard location
       and you want to build GCC, you can explicitly specify the directory
!      where it is installed ('--with-isl=ISLINSTALLDIR').  The
!      '--with-isl=ISLINSTALLDIR' option is shorthand for
!      '--with-isl-lib=ISLINSTALLDIR/lib' and
!      '--with-isl-include=ISLINSTALLDIR/include'.  If this shorthand
       assumption is not correct, you can use the explicit include and lib
       options directly.
  
--- 1903,2003 ----
       GCC is removed entirely in the next major release, unless someone
       steps forward to maintain the port.
  
! ‘--enable-decimal-float’
! ‘--enable-decimal-float=yes’
! ‘--enable-decimal-float=no’
! ‘--enable-decimal-float=bid’
! ‘--enable-decimal-float=dpd’
! ‘--disable-decimal-float’
       Enable (or disable) support for the C decimal floating point
       extension that is in the IEEE 754-2008 standard.  This is enabled
       by default only on AArch64, PowerPC, i386, and x86_64 GNU/Linux
       systems.  Other systems may also support it, but require the user
       to specifically enable it.  You can optionally control which
!      decimal floating point format is used (either ‘bid’ or ‘dpd’).  The
!      ‘bid’ (binary integer decimal) format is default on AArch64, i386
!      and x86_64 systems, and the ‘dpd’ (densely packed decimal) format
       is default on PowerPC systems.
  
! ‘--enable-fixed-point’
! ‘--disable-fixed-point’
       Enable (or disable) support for C fixed-point arithmetic.  This
       option is enabled by default for some targets (such as MIPS) which
       have hardware-support for fixed-point operations.  On other
       targets, you may enable this option manually.
  
! ‘--with-long-double-128’
!      Specify if ‘long double’ type should be 128-bit by default on
       selected GNU/Linux architectures.  If using
!      ‘--without-long-double-128’, ‘long double’ will be by default
!      64-bit, the same as ‘double’ type.  When neither of these configure
!      options are used, the default will be 128-bit ‘long double’ when
!      built against GNU C Library 2.4 and later, 64-bit ‘long double’
       otherwise.
  
! ‘--with-long-double-format=ibm’
! ‘--with-long-double-format=ieee’
!      Specify whether ‘long double’ uses the IBM extended double format
       or the IEEE 128-bit floating point format on PowerPC Linux systems.
       This configuration switch will only work on little endian PowerPC
       Linux systems and on big endian 64-bit systems where the default
!      cpu is at least power7 (i.e. ‘--with-cpu=power7’,
!      ‘--with-cpu=power8’, or ‘--with-cpu=power9’ is used).
  
!      If you use the ‘--with-long-double-64’ configuration option, the
!      ‘--with-long-double-format=ibm’ and
!      ‘--with-long-double-format=ieee’ options are ignored.
  
!      The default ‘long double’ format is to use IBM extended double.
       Until all of the libraries are converted to use IEEE 128-bit
       floating point, it is not recommended to use
!      ‘--with-long-double-format=ieee’.
  
! ‘--enable-fdpic’
       On SH Linux systems, generate ELF FDPIC code.
  
! ‘--with-gmp=PATHNAME’
! ‘--with-gmp-include=PATHNAME’
! ‘--with-gmp-lib=PATHNAME’
! ‘--with-mpfr=PATHNAME’
! ‘--with-mpfr-include=PATHNAME’
! ‘--with-mpfr-lib=PATHNAME’
! ‘--with-mpc=PATHNAME’
! ‘--with-mpc-include=PATHNAME’
! ‘--with-mpc-lib=PATHNAME’
       If you want to build GCC but do not have the GMP library, the MPFR
       library and/or the MPC library installed in a standard location and
       do not have their sources present in the GCC source tree then you
       can explicitly specify the directory where they are installed
!      (‘--with-gmp=GMPINSTALLDIR’, ‘--with-mpfr=MPFRINSTALLDIR’,
!      ‘--with-mpc=MPCINSTALLDIR’).  The ‘--with-gmp=GMPINSTALLDIR’ option
!      is shorthand for ‘--with-gmp-lib=GMPINSTALLDIR/lib’ and
!      ‘--with-gmp-include=GMPINSTALLDIR/include’.  Likewise the
!      ‘--with-mpfr=MPFRINSTALLDIR’ option is shorthand for
!      ‘--with-mpfr-lib=MPFRINSTALLDIR/lib’ and
!      ‘--with-mpfr-include=MPFRINSTALLDIR/include’, also the
!      ‘--with-mpc=MPCINSTALLDIR’ option is shorthand for
!      ‘--with-mpc-lib=MPCINSTALLDIR/lib’ and
!      ‘--with-mpc-include=MPCINSTALLDIR/include’.  If these shorthand
       assumptions are not correct, you can use the explicit include and
       lib options directly.  You might also need to ensure the shared
       libraries can be found by the dynamic linker when building and
       using GCC, for example by setting the runtime shared library path
!      variable (‘LD_LIBRARY_PATH’ on GNU/Linux and Solaris systems).
  
       These flags are applicable to the host platform only.  When
       building a cross compiler, they will not be used to configure
       target libraries.
  
! ‘--with-isl=PATHNAME’
! ‘--with-isl-include=PATHNAME’
! ‘--with-isl-lib=PATHNAME’
       If you do not have the isl library installed in a standard location
       and you want to build GCC, you can explicitly specify the directory
!      where it is installed (‘--with-isl=ISLINSTALLDIR’).  The
!      ‘--with-isl=ISLINSTALLDIR’ option is shorthand for
!      ‘--with-isl-lib=ISLINSTALLDIR/lib’ and
!      ‘--with-isl-include=ISLINSTALLDIR/include’.  If this shorthand
       assumption is not correct, you can use the explicit include and lib
       options directly.
  
*************** option.
*** 2005,2088 ****
       building a cross compiler, they will not be used to configure
       target libraries.
  
! '--with-stage1-ldflags=FLAGS'
       This option may be used to set linker flags to be used when linking
       stage 1 of GCC. These are also used when linking GCC if configured
!      with '--disable-bootstrap'.  If '--with-stage1-libs' is not set to
!      a value, then the default is '-static-libstdc++ -static-libgcc', if
       supported.
  
! '--with-stage1-libs=LIBS'
       This option may be used to set libraries to be used when linking
       stage 1 of GCC. These are also used when linking GCC if configured
!      with '--disable-bootstrap'.
  
! '--with-boot-ldflags=FLAGS'
       This option may be used to set linker flags to be used when linking
       stage 2 and later when bootstrapping GCC. If -with-boot-libs is not
!      is set to a value, then the default is '-static-libstdc++
!      -static-libgcc'.
  
! '--with-boot-libs=LIBS'
       This option may be used to set libraries to be used when linking
       stage 2 and later when bootstrapping GCC.
  
! '--with-debug-prefix-map=MAP'
!      Convert source directory names using '-fdebug-prefix-map' when
!      building runtime libraries.  'MAP' is a space-separated list of
!      maps of the form 'OLD=NEW'.
  
! '--enable-linker-build-id'
!      Tells GCC to pass '--build-id' option to the linker for all final
!      links (links performed without the '-r' or '--relocatable' option),
       if the linker supports it.  If you specify
!      '--enable-linker-build-id', but your linker does not support
!      '--build-id' option, a warning is issued and the
!      '--enable-linker-build-id' option is ignored.  The default is off.
  
! '--with-linker-hash-style=CHOICE'
!      Tells GCC to pass '--hash-style=CHOICE' option to the linker for
!      all final links.  CHOICE can be one of 'sysv', 'gnu', and 'both'
!      where 'sysv' is the default.
  
! '--enable-gnu-unique-object'
! '--disable-gnu-unique-object'
       Tells GCC to use the gnu_unique_object relocation for C++ template
       static data members and inline function local statics.  Enabled by
       default for a toolchain with an assembler that accepts it and GLIBC
       2.11 or above, otherwise disabled.
  
! '--with-diagnostics-color=CHOICE'
!      Tells GCC to use CHOICE as the default for '-fdiagnostics-color='
       option (if not used explicitly on the command line).  CHOICE can be
!      one of 'never', 'auto', 'always', and 'auto-if-env' where 'auto' is
!      the default.  'auto-if-env' makes '-fdiagnostics-color=auto' the
!      default if 'GCC_COLORS' is present and non-empty in the environment
!      of the compiler, and '-fdiagnostics-color=never' otherwise.
  
! '--with-diagnostics-urls=CHOICE'
!      Tells GCC to use CHOICE as the default for '-fdiagnostics-urls='
       option (if not used explicitly on the command line).  CHOICE can be
!      one of 'never', 'auto', 'always', and 'auto-if-env' where 'auto' is
!      the default.  'auto-if-env' makes '-fdiagnostics-urls=auto' the
!      default if 'GCC_URLS' or 'TERM_URLS' is present and non-empty in
!      the environment of the compiler, and '-fdiagnostics-urls=never'
       otherwise.
  
! '--enable-lto'
! '--disable-lto'
       Enable support for link-time optimization (LTO). This is enabled by
!      default, and may be disabled using '--disable-lto'.
  
! '--enable-linker-plugin-configure-flags=FLAGS'
! '--enable-linker-plugin-flags=FLAGS'
       By default, linker plugins (such as the LTO plugin) are built for
       the host system architecture.  For the case that the linker has a
       different (but run-time compatible) architecture, these flags can
       be specified to build plugins that are compatible to the linker.
       For example, if you are building GCC for a 64-bit x86_64
!      ('x86_64-pc-linux-gnu') host system, but have a 32-bit x86
!      GNU/Linux ('i686-pc-linux-gnu') linker executable (which is
       executable on the former system), you can configure GCC as follows
       for getting compatible linker plugins:
  
--- 2005,2088 ----
       building a cross compiler, they will not be used to configure
       target libraries.
  
! ‘--with-stage1-ldflags=FLAGS’
       This option may be used to set linker flags to be used when linking
       stage 1 of GCC. These are also used when linking GCC if configured
!      with ‘--disable-bootstrap’.  If ‘--with-stage1-libs’ is not set to
!      a value, then the default is ‘-static-libstdc++ -static-libgcc’, if
       supported.
  
! ‘--with-stage1-libs=LIBS’
       This option may be used to set libraries to be used when linking
       stage 1 of GCC. These are also used when linking GCC if configured
!      with ‘--disable-bootstrap’.
  
! ‘--with-boot-ldflags=FLAGS’
       This option may be used to set linker flags to be used when linking
       stage 2 and later when bootstrapping GCC. If -with-boot-libs is not
!      is set to a value, then the default is ‘-static-libstdc++
!      -static-libgcc’.
  
! ‘--with-boot-libs=LIBS’
       This option may be used to set libraries to be used when linking
       stage 2 and later when bootstrapping GCC.
  
! ‘--with-debug-prefix-map=MAP’
!      Convert source directory names using ‘-fdebug-prefix-map’ when
!      building runtime libraries.  ‘MAP’ is a space-separated list of
!      maps of the form ‘OLD=NEW’.
  
! ‘--enable-linker-build-id’
!      Tells GCC to pass ‘--build-id’ option to the linker for all final
!      links (links performed without the ‘-r’ or ‘--relocatable’ option),
       if the linker supports it.  If you specify
!      ‘--enable-linker-build-id’, but your linker does not support
!      ‘--build-id’ option, a warning is issued and the
!      ‘--enable-linker-build-id’ option is ignored.  The default is off.
  
! ‘--with-linker-hash-style=CHOICE’
!      Tells GCC to pass ‘--hash-style=CHOICE’ option to the linker for
!      all final links.  CHOICE can be one of ‘sysv’, ‘gnu’, and ‘both’
!      where ‘sysv’ is the default.
  
! ‘--enable-gnu-unique-object’
! ‘--disable-gnu-unique-object’
       Tells GCC to use the gnu_unique_object relocation for C++ template
       static data members and inline function local statics.  Enabled by
       default for a toolchain with an assembler that accepts it and GLIBC
       2.11 or above, otherwise disabled.
  
! ‘--with-diagnostics-color=CHOICE’
!      Tells GCC to use CHOICE as the default for ‘-fdiagnostics-color=’
       option (if not used explicitly on the command line).  CHOICE can be
!      one of ‘never’, ‘auto’, ‘always’, and ‘auto-if-env’ where ‘auto’ is
!      the default.  ‘auto-if-env’ makes ‘-fdiagnostics-color=auto’ the
!      default if ‘GCC_COLORS’ is present and non-empty in the environment
!      of the compiler, and ‘-fdiagnostics-color=never’ otherwise.
  
! ‘--with-diagnostics-urls=CHOICE’
!      Tells GCC to use CHOICE as the default for ‘-fdiagnostics-urls=’
       option (if not used explicitly on the command line).  CHOICE can be
!      one of ‘never’, ‘auto’, ‘always’, and ‘auto-if-env’ where ‘auto’ is
!      the default.  ‘auto-if-env’ makes ‘-fdiagnostics-urls=auto’ the
!      default if ‘GCC_URLS’ or ‘TERM_URLS’ is present and non-empty in
!      the environment of the compiler, and ‘-fdiagnostics-urls=never’
       otherwise.
  
! ‘--enable-lto’
! ‘--disable-lto’
       Enable support for link-time optimization (LTO). This is enabled by
!      default, and may be disabled using ‘--disable-lto’.
  
! ‘--enable-linker-plugin-configure-flags=FLAGS’
! ‘--enable-linker-plugin-flags=FLAGS’
       By default, linker plugins (such as the LTO plugin) are built for
       the host system architecture.  For the case that the linker has a
       different (but run-time compatible) architecture, these flags can
       be specified to build plugins that are compatible to the linker.
       For example, if you are building GCC for a 64-bit x86_64
!      (‘x86_64-pc-linux-gnu’) host system, but have a 32-bit x86
!      GNU/Linux (‘i686-pc-linux-gnu’) linker executable (which is
       executable on the former system), you can configure GCC as follows
       for getting compatible linker plugins:
  
*************** option.
*** 2091,2112 ****
                --enable-linker-plugin-configure-flags=--host=i686-pc-linux-gnu \
                --enable-linker-plugin-flags='CC=gcc\ -m32\ -Wl,-rpath,[...]/i686-pc-linux-gnu/lib'
  
! '--with-plugin-ld=PATHNAME'
       Enable an alternate linker to be used at link-time optimization
!      (LTO) link time when '-fuse-linker-plugin' is enabled.  This linker
       should have plugin support such as gold starting with version 2.20
!      or GNU ld starting with version 2.21.  See '-fuse-linker-plugin'
       for details.
  
! '--enable-canonical-system-headers'
! '--disable-canonical-system-headers'
!      Enable system header path canonicalization for 'libcpp'.  This can
       produce shorter header file paths in diagnostics and dependency
       output files, but these changed header paths may conflict with some
       compilation environments.  Enabled by default, and may be disabled
!      using '--disable-canonical-system-headers'.
  
! '--with-glibc-version=MAJOR.MINOR'
       Tell GCC that when the GNU C Library (glibc) is used on the target
       it will be version MAJOR.MINOR or later.  Normally this can be
       detected from the C library's header files, but this option may be
--- 2091,2112 ----
                --enable-linker-plugin-configure-flags=--host=i686-pc-linux-gnu \
                --enable-linker-plugin-flags='CC=gcc\ -m32\ -Wl,-rpath,[...]/i686-pc-linux-gnu/lib'
  
! ‘--with-plugin-ld=PATHNAME’
       Enable an alternate linker to be used at link-time optimization
!      (LTO) link time when ‘-fuse-linker-plugin’ is enabled.  This linker
       should have plugin support such as gold starting with version 2.20
!      or GNU ld starting with version 2.21.  See ‘-fuse-linker-plugin’
       for details.
  
! ‘--enable-canonical-system-headers’
! ‘--disable-canonical-system-headers’
!      Enable system header path canonicalization for ‘libcpp’.  This can
       produce shorter header file paths in diagnostics and dependency
       output files, but these changed header paths may conflict with some
       compilation environments.  Enabled by default, and may be disabled
!      using ‘--disable-canonical-system-headers’.
  
! ‘--with-glibc-version=MAJOR.MINOR’
       Tell GCC that when the GNU C Library (glibc) is used on the target
       it will be version MAJOR.MINOR or later.  Normally this can be
       detected from the C library's header files, but this option may be
*************** option.
*** 2118,2137 ****
       glibc.  However, such configurations may not work well as not all
       the relevant configuration in GCC is on a per-multilib basis.
  
! '--enable-as-accelerator-for=TARGET'
       Build as offload target compiler.  Specify offload host triple by
       TARGET.
  
! '--enable-offload-targets=TARGET1[=PATH1],...,TARGETN[=PATHN]'
       Enable offloading to targets TARGET1, ..., TARGETN.  Offload
       compilers are expected to be already installed.  Default search
!      path for them is 'EXEC-PREFIX', but it can be changed by specifying
       paths PATH1, ..., PATHN.
  
            % SRCDIR/configure \
                --enable-offload-targets=amdgcn-amdhsa,nvptx-none
  
! '--enable-offload-defaulted'
  
       Tell GCC that configured but not installed offload compilers and
       libgomp plugins are silently ignored.  Useful for distribution
--- 2118,2137 ----
       glibc.  However, such configurations may not work well as not all
       the relevant configuration in GCC is on a per-multilib basis.
  
! ‘--enable-as-accelerator-for=TARGET’
       Build as offload target compiler.  Specify offload host triple by
       TARGET.
  
! ‘--enable-offload-targets=TARGET1[=PATH1],...,TARGETN[=PATHN]’
       Enable offloading to targets TARGET1, ..., TARGETN.  Offload
       compilers are expected to be already installed.  Default search
!      path for them is ‘EXEC-PREFIX’, but it can be changed by specifying
       paths PATH1, ..., PATHN.
  
            % SRCDIR/configure \
                --enable-offload-targets=amdgcn-amdhsa,nvptx-none
  
! ‘--enable-offload-defaulted’
  
       Tell GCC that configured but not installed offload compilers and
       libgomp plugins are silently ignored.  Useful for distribution
*************** option.
*** 2140,2185 ****
       the actual supported offloading target set rather than the GCC
       configure-time selection.
  
! '--enable-cet'
! '--disable-cet'
       Enable building target run-time libraries with control-flow
!      instrumentation, see '-fcf-protection' option.  When '--enable-cet'
       is specified target libraries are configured to add
!      '-fcf-protection' and, if needed, other target specific options to
       a set of building options.
  
!      '--enable-cet=auto' is default.  CET is enabled on Linux/x86 if
!      target binutils supports 'Intel CET' instructions and disabled
       otherwise.  In this case, the target libraries are configured to
!      get additional '-fcf-protection' option.
  
! '--with-riscv-attribute='yes', 'no' or 'default''
       Generate RISC-V attribute by default, in order to record extra
       build information in object.
  
       The option is disabled by default.  It is enabled on RISC-V/ELF
       (bare-metal) target if target binutils supported.
  
! '--enable-s390-excess-float-precision'
! '--disable-s390-excess-float-precision'
       On s390(x) targets, enable treatment of float expressions with
       double precision when in standards-compliant mode (e.g., when
!      '--std=c99' or '-fexcess-precision=standard' are given).
  
       For a native build and cross compiles that have target headers, the
       option's default is derived from glibc's behavior.  When glibc
       clamps float_t to double, GCC follows and enables the option.  For
       other cross compiles, the default is disabled.
  
! '--with-zstd=PATHNAME'
! '--with-zstd-include=PATHNAME'
! '--with-zstd-lib=PATHNAME'
!      If you do not have the 'zstd' library installed in a standard
       location and you want to build GCC, you can explicitly specify the
!      directory where it is installed ('--with-zstd=ZSTDINSTALLDIR').
!      The '--with-zstd=ZSTDINSTALLDIR' option is shorthand for
!      '--with-zstd-lib=ZSTDINSTALLDIR/lib' and
!      '--with-zstd-include=ZSTDINSTALLDIR/include'.  If this shorthand
       assumption is not correct, you can use the explicit include and lib
       options directly.
  
--- 2140,2185 ----
       the actual supported offloading target set rather than the GCC
       configure-time selection.
  
! ‘--enable-cet’
! ‘--disable-cet’
       Enable building target run-time libraries with control-flow
!      instrumentation, see ‘-fcf-protection’ option.  When ‘--enable-cet’
       is specified target libraries are configured to add
!      ‘-fcf-protection’ and, if needed, other target specific options to
       a set of building options.
  
!      ‘--enable-cet=auto’ is default.  CET is enabled on Linux/x86 if
!      target binutils supports ‘Intel CET’ instructions and disabled
       otherwise.  In this case, the target libraries are configured to
!      get additional ‘-fcf-protection’ option.
  
! ‘--with-riscv-attribute=‘yes’, ‘no’ or ‘default’’
       Generate RISC-V attribute by default, in order to record extra
       build information in object.
  
       The option is disabled by default.  It is enabled on RISC-V/ELF
       (bare-metal) target if target binutils supported.
  
! ‘--enable-s390-excess-float-precision’
! ‘--disable-s390-excess-float-precision’
       On s390(x) targets, enable treatment of float expressions with
       double precision when in standards-compliant mode (e.g., when
!      ‘--std=c99’ or ‘-fexcess-precision=standard’ are given).
  
       For a native build and cross compiles that have target headers, the
       option's default is derived from glibc's behavior.  When glibc
       clamps float_t to double, GCC follows and enables the option.  For
       other cross compiles, the default is disabled.
  
! ‘--with-zstd=PATHNAME’
! ‘--with-zstd-include=PATHNAME’
! ‘--with-zstd-lib=PATHNAME’
!      If you do not have the ‘zstd’ library installed in a standard
       location and you want to build GCC, you can explicitly specify the
!      directory where it is installed (‘--with-zstd=ZSTDINSTALLDIR’).
!      The ‘--with-zstd=ZSTDINSTALLDIR’ option is shorthand for
!      ‘--with-zstd-lib=ZSTDINSTALLDIR/lib’ and
!      ‘--with-zstd-include=ZSTDINSTALLDIR/include’.  If this shorthand
       assumption is not correct, you can use the explicit include and lib
       options directly.
  
*************** Cross-Compiler-Specific Options
*** 2192,2232 ****
  
  The following options only apply to building cross compilers.
  
! '--with-toolexeclibdir=DIR'
       Specify the installation directory for libraries built with a cross
!      compiler.  The default is '${gcc_tooldir}/lib'.
  
! '--with-sysroot'
! '--with-sysroot=DIR'
       Tells GCC to consider DIR as the root of a tree that contains (a
       subset of) the root filesystem of the target operating system.
       Target system headers, libraries and run-time object files will be
       searched for in there.  More specifically, this acts as if
!      '--sysroot=DIR' was added to the default options of the built
       compiler.  The specified directory is not copied into the install
!      tree, unlike the options '--with-headers' and '--with-libs' that
!      this option obsoletes.  The default value, in case '--with-sysroot'
!      is not given an argument, is '${gcc_tooldir}/sys-root'.  If the
!      specified directory is a subdirectory of '${exec_prefix}', then it
       will be found relative to the GCC binaries if the installation tree
       is moved.
  
       This option affects the system root for the compiler used to build
       target libraries (which runs on the build system) and the compiler
!      newly installed with 'make install'; it does not affect the
       compiler which is used to build GCC itself.
  
!      If you specify the '--with-native-system-header-dir=DIRNAME' option
       then the compiler will search that directory within DIRNAME for
!      native system headers rather than the default '/usr/include'.
  
! '--with-build-sysroot'
! '--with-build-sysroot=DIR'
!      Tells GCC to consider DIR as the system root (see '--with-sysroot')
       while building target libraries, instead of the directory specified
!      with '--with-sysroot'.  This option is only useful when you are
!      already using '--with-sysroot'.  You can use '--with-build-sysroot'
!      when you are configuring with '--prefix' set to a directory that is
       different from the one in which you are installing GCC and your
       target libraries.
  
--- 2192,2232 ----
  
  The following options only apply to building cross compilers.
  
! ‘--with-toolexeclibdir=DIR’
       Specify the installation directory for libraries built with a cross
!      compiler.  The default is ‘${gcc_tooldir}/lib’.
  
! ‘--with-sysroot’
! ‘--with-sysroot=DIR’
       Tells GCC to consider DIR as the root of a tree that contains (a
       subset of) the root filesystem of the target operating system.
       Target system headers, libraries and run-time object files will be
       searched for in there.  More specifically, this acts as if
!      ‘--sysroot=DIR’ was added to the default options of the built
       compiler.  The specified directory is not copied into the install
!      tree, unlike the options ‘--with-headers’ and ‘--with-libs’ that
!      this option obsoletes.  The default value, in case ‘--with-sysroot’
!      is not given an argument, is ‘${gcc_tooldir}/sys-root’.  If the
!      specified directory is a subdirectory of ‘${exec_prefix}’, then it
       will be found relative to the GCC binaries if the installation tree
       is moved.
  
       This option affects the system root for the compiler used to build
       target libraries (which runs on the build system) and the compiler
!      newly installed with ‘make install’; it does not affect the
       compiler which is used to build GCC itself.
  
!      If you specify the ‘--with-native-system-header-dir=DIRNAME’ option
       then the compiler will search that directory within DIRNAME for
!      native system headers rather than the default ‘/usr/include’.
  
! ‘--with-build-sysroot’
! ‘--with-build-sysroot=DIR’
!      Tells GCC to consider DIR as the system root (see ‘--with-sysroot’)
       while building target libraries, instead of the directory specified
!      with ‘--with-sysroot’.  This option is only useful when you are
!      already using ‘--with-sysroot’.  You can use ‘--with-build-sysroot’
!      when you are configuring with ‘--prefix’ set to a directory that is
       different from the one in which you are installing GCC and your
       target libraries.
  
*************** The following options only apply to buil
*** 2234,2371 ****
       target libraries (which runs on the build system); it does not
       affect the compiler which is used to build GCC itself.
  
!      If you specify the '--with-native-system-header-dir=DIRNAME' option
       then the compiler will search that directory within DIRNAME for
!      native system headers rather than the default '/usr/include'.
  
! '--with-headers'
! '--with-headers=DIR'
!      Deprecated in favor of '--with-sysroot'.  Specifies that target
       headers are available when building a cross compiler.  The DIR
       argument specifies a directory which has the target include files.
!      These include files will be copied into the 'gcc' install
       directory.  _This option with the DIR argument is required_ when
!      building a cross compiler, if 'PREFIX/TARGET/sys-include' doesn't
!      pre-exist.  If 'PREFIX/TARGET/sys-include' does pre-exist, the DIR
!      argument may be omitted.  'fixincludes' will be run on these files
       to make them compatible with GCC.
  
! '--without-headers'
       Tells GCC not use any target headers from a libc when building a
       cross compiler.  When crossing to GNU/Linux, you need the headers
       so GCC can build the exception handling for libgcc.
  
! '--with-libs'
! '--with-libs="DIR1 DIR2 ... DIRN"'
!      Deprecated in favor of '--with-sysroot'.  Specifies a list of
       directories which contain the target runtime libraries.  These
!      libraries will be copied into the 'gcc' install directory.  If the
       directory list is omitted, this option has no effect.
  
! '--with-newlib'
!      Specifies that 'newlib' is being used as the target C library.
!      This causes '__eprintf' to be omitted from 'libgcc.a' on the
!      assumption that it will be provided by 'newlib'.
  
! '--with-avrlibc'
!      Only supported for the AVR target.  Specifies that 'AVR-Libc' is
       being used as the target C  library.  This causes float support
!      functions like '__addsf3' to be omitted from 'libgcc.a' on the
!      assumption that it will be provided by 'libm.a'.  For more
       technical details, cf.  PR54461.  It is not supported for RTEMS
       configurations, which currently use newlib.  The option is
       supported since version 4.7.2 and is the default in 4.8.0 and
       newer.
  
! '--with-double={32|64|32,64|64,32}'
! '--with-long-double={32|64|32,64|64,32|double}'
       Only supported for the AVR target since version 10.  Specify the
!      default layout available for the C/C++ 'double' and 'long double'
       type, respectively.  The following rules apply:
!         * The first value after the '=' specifies the default layout (in
!           bits) of the type and also the default for the '-mdouble='
!           resp.  '-mlong-double=' compiler option.
!         * If more than one value is specified, respective multilib
!           variants are available, and '-mdouble=' resp.
!           '-mlong-double=' acts as a multilib option.
!         * If '--with-long-double=double' is specified, 'double' and
!           'long double' will have the same layout.
!         * The defaults are '--with-long-double=64,32' and
!           '--with-double=32,64'.  The default 'double' layout imposed by
            the latter is compatible with older versions of the compiler
!           that implement 'double' as a 32-bit type, which does not
            comply to the language standard.
!      Not all combinations of '--with-double=' and '--with-long-double='
!      are valid.  For example, the combination '--with-double=32,64'
!      '--with-long-double=32' will be rejected because the first option
!      specifies the availability of multilibs for 'double', whereas the
!      second option implies that 'long double' -- and hence also 'double'
       -- is always 32 bits wide.
  
! '--with-double-comparison={tristate|bool|libf7}'
       Only supported for the AVR target since version 10.  Specify what
       result format is returned by library functions that compare 64-bit
!      floating point values ('DFmode').  The GCC default is 'tristate'.
       If the floating point implementation returns a boolean instead, set
!      it to 'bool'.
  
! '--with-libf7={libgcc|math|math-symbols|no}'
       Only supported for the AVR target since version 10.  Specify to
       which degree code from LibF7 is included in libgcc.  LibF7 is an
       ad-hoc, AVR-specific, 64-bit floating point emulation written in C
!      and (inline) assembly.  'libgcc' adds support for functions that
       one would usually expect in libgcc like double addition, double
!      comparisons and double conversions.  'math' also adds routines that
!      one would expect in 'libm.a', but with '__' (two underscores)
!      prepended to the symbol names as specified by 'math.h'.
!      'math-symbols' also defines weak aliases for the functions declared
!      in 'math.h'.  However, '--with-libf7' won't install no 'math.h'
       header file whatsoever, this file must come from elsewhere.  This
!      option sets '--with-double-comparison' to 'bool'.
  
! '--with-nds32-lib=LIBRARY'
!      Specifies that LIBRARY setting is used for building 'libgcc.a'.
!      Currently, the valid LIBRARY is 'newlib' or 'mculib'.  This option
       is only supported for the NDS32 target.
  
! '--with-build-time-tools=DIR'
       Specifies where to find the set of target tools (assembler, linker,
       etc.)  that will be used while building GCC itself.  This option
       can be useful if the directory layouts are different between the
       system you are building GCC on, and the system where you will
       deploy it.
  
!      For example, on an 'ia64-hp-hpux' system, you may have the GNU
!      assembler and linker in '/usr/bin', and the native tools in a
       different path, and build a toolchain that expects to find the
!      native tools in '/usr/bin'.
  
!      When you use this option, you should ensure that DIR includes 'ar',
!      'as', 'ld', 'nm', 'ranlib' and 'strip' if necessary, and possibly
!      'objdump'.  Otherwise, GCC may use an inconsistent set of tools.
  
! Overriding 'configure' test results
  ...................................
  
  Sometimes, it might be necessary to override the result of some
! 'configure' test, for example in order to ease porting to a new system
! or work around a bug in a test.  The toplevel 'configure' script
  provides three variables for this:
  
! 'build_configargs'
!      The contents of this variable is passed to all build 'configure'
       scripts.
  
! 'host_configargs'
!      The contents of this variable is passed to all host 'configure'
       scripts.
  
! 'target_configargs'
!      The contents of this variable is passed to all target 'configure'
       scripts.
  
!    In order to avoid shell and 'make' quoting issues for complex
! overrides, you can pass a setting for 'CONFIG_SITE' and set variables in
  the site file.
  
  Objective-C-Specific Options
--- 2234,2371 ----
       target libraries (which runs on the build system); it does not
       affect the compiler which is used to build GCC itself.
  
!      If you specify the ‘--with-native-system-header-dir=DIRNAME’ option
       then the compiler will search that directory within DIRNAME for
!      native system headers rather than the default ‘/usr/include’.
  
! ‘--with-headers’
! ‘--with-headers=DIR’
!      Deprecated in favor of ‘--with-sysroot’.  Specifies that target
       headers are available when building a cross compiler.  The DIR
       argument specifies a directory which has the target include files.
!      These include files will be copied into the ‘gcc’ install
       directory.  _This option with the DIR argument is required_ when
!      building a cross compiler, if ‘PREFIX/TARGET/sys-include’ doesn't
!      pre-exist.  If ‘PREFIX/TARGET/sys-include’ does pre-exist, the DIR
!      argument may be omitted.  ‘fixincludes’ will be run on these files
       to make them compatible with GCC.
  
! ‘--without-headers’
       Tells GCC not use any target headers from a libc when building a
       cross compiler.  When crossing to GNU/Linux, you need the headers
       so GCC can build the exception handling for libgcc.
  
! ‘--with-libs’
! ‘--with-libs="DIR1 DIR2 ... DIRN"’
!      Deprecated in favor of ‘--with-sysroot’.  Specifies a list of
       directories which contain the target runtime libraries.  These
!      libraries will be copied into the ‘gcc’ install directory.  If the
       directory list is omitted, this option has no effect.
  
! ‘--with-newlib’
!      Specifies that ‘newlib’ is being used as the target C library.
!      This causes ‘__eprintf’ to be omitted from ‘libgcc.a’ on the
!      assumption that it will be provided by ‘newlib’.
  
! ‘--with-avrlibc’
!      Only supported for the AVR target.  Specifies that ‘AVR-Libc’ is
       being used as the target C  library.  This causes float support
!      functions like ‘__addsf3’ to be omitted from ‘libgcc.a’ on the
!      assumption that it will be provided by ‘libm.a’.  For more
       technical details, cf.  PR54461.  It is not supported for RTEMS
       configurations, which currently use newlib.  The option is
       supported since version 4.7.2 and is the default in 4.8.0 and
       newer.
  
! ‘--with-double={32|64|32,64|64,32}’
! ‘--with-long-double={32|64|32,64|64,32|double}’
       Only supported for the AVR target since version 10.  Specify the
!      default layout available for the C/C++ ‘double’ and ‘long double’
       type, respectively.  The following rules apply:
!         • The first value after the ‘=’ specifies the default layout (in
!           bits) of the type and also the default for the ‘-mdouble=’
!           resp.  ‘-mlong-double=’ compiler option.
!         • If more than one value is specified, respective multilib
!           variants are available, and ‘-mdouble=’ resp.
!           ‘-mlong-double=’ acts as a multilib option.
!         • If ‘--with-long-double=double’ is specified, ‘double’ and
!           ‘long double’ will have the same layout.
!         • The defaults are ‘--with-long-double=64,32’ and
!           ‘--with-double=32,64’.  The default ‘double’ layout imposed by
            the latter is compatible with older versions of the compiler
!           that implement ‘double’ as a 32-bit type, which does not
            comply to the language standard.
!      Not all combinations of ‘--with-double=’ and ‘--with-long-double=’
!      are valid.  For example, the combination ‘--with-double=32,64’
!      ‘--with-long-double=32’ will be rejected because the first option
!      specifies the availability of multilibs for ‘double’, whereas the
!      second option implies that ‘long double’ -- and hence also ‘double’
       -- is always 32 bits wide.
  
! ‘--with-double-comparison={tristate|bool|libf7}’
       Only supported for the AVR target since version 10.  Specify what
       result format is returned by library functions that compare 64-bit
!      floating point values (‘DFmode’).  The GCC default is ‘tristate’.
       If the floating point implementation returns a boolean instead, set
!      it to ‘bool’.
  
! ‘--with-libf7={libgcc|math|math-symbols|no}’
       Only supported for the AVR target since version 10.  Specify to
       which degree code from LibF7 is included in libgcc.  LibF7 is an
       ad-hoc, AVR-specific, 64-bit floating point emulation written in C
!      and (inline) assembly.  ‘libgcc’ adds support for functions that
       one would usually expect in libgcc like double addition, double
!      comparisons and double conversions.  ‘math’ also adds routines that
!      one would expect in ‘libm.a’, but with ‘__’ (two underscores)
!      prepended to the symbol names as specified by ‘math.h’.
!      ‘math-symbols’ also defines weak aliases for the functions declared
!      in ‘math.h’.  However, ‘--with-libf7’ won't install no ‘math.h’
       header file whatsoever, this file must come from elsewhere.  This
!      option sets ‘--with-double-comparison’ to ‘bool’.
  
! ‘--with-nds32-lib=LIBRARY’
!      Specifies that LIBRARY setting is used for building ‘libgcc.a’.
!      Currently, the valid LIBRARY is ‘newlib’ or ‘mculib’.  This option
       is only supported for the NDS32 target.
  
! ‘--with-build-time-tools=DIR’
       Specifies where to find the set of target tools (assembler, linker,
       etc.)  that will be used while building GCC itself.  This option
       can be useful if the directory layouts are different between the
       system you are building GCC on, and the system where you will
       deploy it.
  
!      For example, on an ‘ia64-hp-hpux’ system, you may have the GNU
!      assembler and linker in ‘/usr/bin’, and the native tools in a
       different path, and build a toolchain that expects to find the
!      native tools in ‘/usr/bin’.
  
!      When you use this option, you should ensure that DIR includes ‘ar’,
!      ‘as’, ‘ld’, ‘nm’, ‘ranlib’ and ‘strip’ if necessary, and possibly
!      ‘objdump’.  Otherwise, GCC may use an inconsistent set of tools.
  
! Overriding ‘configure’ test results
  ...................................
  
  Sometimes, it might be necessary to override the result of some
! ‘configure’ test, for example in order to ease porting to a new system
! or work around a bug in a test.  The toplevel ‘configure’ script
  provides three variables for this:
  
! ‘build_configargs’
!      The contents of this variable is passed to all build ‘configure’
       scripts.
  
! ‘host_configargs’
!      The contents of this variable is passed to all host ‘configure’
       scripts.
  
! ‘target_configargs’
!      The contents of this variable is passed to all target ‘configure’
       scripts.
  
!    In order to avoid shell and ‘make’ quoting issues for complex
! overrides, you can pass a setting for ‘CONFIG_SITE’ and set variables in
  the site file.
  
  Objective-C-Specific Options
*************** Objective-C-Specific Options
*** 2374,2406 ****
  The following options apply to the build of the Objective-C runtime
  library.
  
! '--enable-objc-gc'
       Specify that an additional variant of the GNU Objective-C runtime
       library is built, using an external build of the
       Boehm-Demers-Weiser garbage collector
       ().  This library needs to be
       available for each multilib variant, unless configured with
!      '--enable-objc-gc='auto'' in which case the build of the additional
       runtime library is skipped when not available and the build
       continues.
  
! '--with-target-bdw-gc=LIST'
! '--with-target-bdw-gc-include=LIST'
! '--with-target-bdw-gc-lib=LIST'
       Specify search directories for the garbage collector header files
       and libraries.  LIST is a comma separated list of key value pairs
!      of the form 'MULTILIBDIR=PATH', where the default multilib key is
!      named as '.' (dot), or is omitted (e.g.
!      '--with-target-bdw-gc=/opt/bdw-gc,32=/opt-bdw-gc32').
  
!      The options '--with-target-bdw-gc-include' and
!      '--with-target-bdw-gc-lib' must always be specified together for
       each multilib variant and they take precedence over
!      '--with-target-bdw-gc'.  If '--with-target-bdw-gc-include' is
       missing values for a multilib, then the value for the default
       multilib is used (e.g.
!      '--with-target-bdw-gc-include=/opt/bdw-gc/include'
!      '--with-target-bdw-gc-lib=/opt/bdw-gc/lib64,32=/opt-bdw-gc/lib32').
       If none of these options are specified, the library is assumed in
       default locations.
  
--- 2374,2406 ----
  The following options apply to the build of the Objective-C runtime
  library.
  
! ‘--enable-objc-gc’
       Specify that an additional variant of the GNU Objective-C runtime
       library is built, using an external build of the
       Boehm-Demers-Weiser garbage collector
       ().  This library needs to be
       available for each multilib variant, unless configured with
!      ‘--enable-objc-gc=‘auto’’ in which case the build of the additional
       runtime library is skipped when not available and the build
       continues.
  
! ‘--with-target-bdw-gc=LIST’
! ‘--with-target-bdw-gc-include=LIST’
! ‘--with-target-bdw-gc-lib=LIST’
       Specify search directories for the garbage collector header files
       and libraries.  LIST is a comma separated list of key value pairs
!      of the form ‘MULTILIBDIR=PATH’, where the default multilib key is
!      named as ‘.’ (dot), or is omitted (e.g.
!      ‘--with-target-bdw-gc=/opt/bdw-gc,32=/opt-bdw-gc32’).
  
!      The options ‘--with-target-bdw-gc-include’ and
!      ‘--with-target-bdw-gc-lib’ must always be specified together for
       each multilib variant and they take precedence over
!      ‘--with-target-bdw-gc’.  If ‘--with-target-bdw-gc-include’ is
       missing values for a multilib, then the value for the default
       multilib is used (e.g.
!      ‘--with-target-bdw-gc-include=/opt/bdw-gc/include’
!      ‘--with-target-bdw-gc-lib=/opt/bdw-gc/lib64,32=/opt-bdw-gc/lib32’).
       If none of these options are specified, the library is assumed in
       default locations.
  
*************** D-Specific Options
*** 2409,2451 ****
  
  The following options apply to the build of the D runtime library.
  
! '--enable-libphobos-checking'
! '--disable-libphobos-checking'
! '--enable-libphobos-checking=LIST'
       This option controls whether run-time checks and contracts are
       compiled into the D runtime library.  When the option is not
!      specified, the library is built with 'release' checking.  When the
       option is specified without a LIST, the result is the same as
!      '--enable-libphobos-checking=yes'.  Likewise,
!      '--disable-libphobos-checking' is equivalent to
!      '--enable-libphobos-checking=no'.
  
!      The categories of checks available in LIST are 'yes' (compiles
!      libphobos with '-fno-release'), 'no' (compiles libphobos with
!      '-frelease'), 'all' (same as 'yes'), 'none' or 'release' (same as
!      'no').
  
!      Individual checks available in LIST are 'assert' (compiles
!      libphobos with an extra option '-fassert').
  
! '--with-libphobos-druntime-only'
! '--with-libphobos-druntime-only=CHOICE'
       Specify whether to build only the core D runtime library
       (druntime), or both the core and standard library (phobos) into
       libphobos.  This is useful for targets that have full support in
       druntime, but no or incomplete support in phobos.  CHOICE can be
!      one of 'auto', 'yes', and 'no' where 'auto' is the default.
  
!      When the option is not specified, the default choice 'auto' means
       that it is inferred whether the target has support for the phobos
       standard library.  When the option is specified without a CHOICE,
!      the result is the same as '--with-libphobos-druntime-only=yes'.
  
! '--with-target-system-zlib'
!      Use installed 'zlib' rather than that included with GCC.  This
       needs to be available for each multilib variant, unless configured
!      with '--with-target-system-zlib='auto'' in which case the
!      GCC included 'zlib' is only used when the system installed library
       is not available.
  
  
--- 2409,2451 ----
  
  The following options apply to the build of the D runtime library.
  
! ‘--enable-libphobos-checking’
! ‘--disable-libphobos-checking’
! ‘--enable-libphobos-checking=LIST’
       This option controls whether run-time checks and contracts are
       compiled into the D runtime library.  When the option is not
!      specified, the library is built with ‘release’ checking.  When the
       option is specified without a LIST, the result is the same as
!      ‘--enable-libphobos-checking=yes’.  Likewise,
!      ‘--disable-libphobos-checking’ is equivalent to
!      ‘--enable-libphobos-checking=no’.
  
!      The categories of checks available in LIST are ‘yes’ (compiles
!      libphobos with ‘-fno-release’), ‘no’ (compiles libphobos with
!      ‘-frelease’), ‘all’ (same as ‘yes’), ‘none’ or ‘release’ (same as
!      ‘no’).
  
!      Individual checks available in LIST are ‘assert’ (compiles
!      libphobos with an extra option ‘-fassert’).
  
! ‘--with-libphobos-druntime-only’
! ‘--with-libphobos-druntime-only=CHOICE’
       Specify whether to build only the core D runtime library
       (druntime), or both the core and standard library (phobos) into
       libphobos.  This is useful for targets that have full support in
       druntime, but no or incomplete support in phobos.  CHOICE can be
!      one of ‘auto’, ‘yes’, and ‘no’ where ‘auto’ is the default.
  
!      When the option is not specified, the default choice ‘auto’ means
       that it is inferred whether the target has support for the phobos
       standard library.  When the option is specified without a CHOICE,
!      the result is the same as ‘--with-libphobos-druntime-only=yes’.
  
! ‘--with-target-system-zlib’
!      Use installed ‘zlib’ rather than that included with GCC.  This
       needs to be available for each multilib variant, unless configured
!      with ‘--with-target-system-zlib=‘auto’’ in which case the
!      GCC included ‘zlib’ is only used when the system installed library
       is not available.
  
  
*************** Now that GCC is configured, you are read
*** 2458,2464 ****
  runtime libraries.
  
     Some commands executed when making the compiler may fail (return a
! nonzero status) and be ignored by 'make'.  These failures, which are
  often due to files that were not found, are expected, and can safely be
  ignored.
  
--- 2458,2464 ----
  runtime libraries.
  
     Some commands executed when making the compiler may fail (return a
! nonzero status) and be ignored by ‘make’.  These failures, which are
  often due to files that were not found, are expected, and can safely be
  ignored.
  
*************** ignored.
*** 2466,2475 ****
  Unless you are a GCC developer, you can generally ignore these warnings
  unless they cause compilation to fail.  Developers should attempt to fix
  any warnings encountered, however they can temporarily continue past
! warnings-as-errors by specifying the configure flag '--disable-werror'.
  
     On certain old systems, defining certain environment variables such
! as 'CC' can interfere with the functioning of 'make'.
  
     If you encounter seemingly strange errors when trying to build the
  compiler in a directory other than the source directory, it could be
--- 2466,2475 ----
  Unless you are a GCC developer, you can generally ignore these warnings
  unless they cause compilation to fail.  Developers should attempt to fix
  any warnings encountered, however they can temporarily continue past
! warnings-as-errors by specifying the configure flag ‘--disable-werror’.
  
     On certain old systems, defining certain environment variables such
! as ‘CC’ can interfere with the functioning of ‘make’.
  
     If you encounter seemingly strange errors when trying to build the
  compiler in a directory other than the source directory, it could be
*************** because you have previously configured t
*** 2477,2493 ****
  directory.  Make sure you have done all the necessary preparations.
  
     If you build GCC on a BSD system using a directory stored in an old
! System V file system, problems may occur in running 'fixincludes' if the
  System V file system doesn't support symbolic links.  These problems
! result in a failure to fix the declaration of 'size_t' in 'sys/types.h'.
! If you find that 'size_t' is a signed type and that type mismatches
  occur, this could be the cause.
  
     The solution is not to use such a directory for building GCC.
  
     Similarly, when building from the source repository or snapshots, or
! if you modify '*.l' files, you need the Flex lexical analyzer generator
! installed.  If you do not modify '*.l' files, releases contain the
  Flex-generated files and you do not need Flex installed to build them.
  There is still one Flex-based lexical analyzer (part of the build
  machinery, not of GCC itself) that is used even if you only build the C
--- 2477,2493 ----
  directory.  Make sure you have done all the necessary preparations.
  
     If you build GCC on a BSD system using a directory stored in an old
! System V file system, problems may occur in running ‘fixincludes’ if the
  System V file system doesn't support symbolic links.  These problems
! result in a failure to fix the declaration of ‘size_t’ in ‘sys/types.h’.
! If you find that ‘size_t’ is a signed type and that type mismatches
  occur, this could be the cause.
  
     The solution is not to use such a directory for building GCC.
  
     Similarly, when building from the source repository or snapshots, or
! if you modify ‘*.l’ files, you need the Flex lexical analyzer generator
! installed.  If you do not modify ‘*.l’ files, releases contain the
  Flex-generated files and you do not need Flex installed to build them.
  There is still one Flex-based lexical analyzer (part of the build
  machinery, not of GCC itself) that is used even if you only build the C
*************** the release.
*** 2503,2538 ****
  ==============================
  
  For a native build, the default configuration is to perform a 3-stage
! bootstrap of the compiler when 'make' is invoked.  This will build the
  entire GCC system and ensure that it compiles itself correctly.  It can
! be disabled with the '--disable-bootstrap' parameter to 'configure', but
  bootstrapping is suggested because the compiler will be tested more
  completely and could also have better performance.
  
     The bootstrapping process will complete the following steps:
  
!    * Build tools necessary to build the compiler.
  
!    * Perform a 3-stage bootstrap of the compiler.  This includes
       building three times the target tools for use by the compiler such
       as binutils (bfd, binutils, gas, gprof, ld, and opcodes) if they
       have been individually linked or moved into the top level GCC
       source tree before configuring.
  
!    * Perform a comparison test of the stage2 and stage3 compilers.
  
!    * Build runtime libraries using the stage3 compiler from the previous
       step.
  
!    If you are short on disk space you might consider 'make
! bootstrap-lean' instead.  The sequence of compilation is the same
  described above, but object files from the stage1 and stage2 of the
  3-stage bootstrap of the compiler are deleted as soon as they are no
  longer needed.
  
     If you wish to use non-default GCC flags when compiling the stage2
! and stage3 compilers, set 'BOOT_CFLAGS' on the command line when doing
! 'make'.  For example, if you want to save additional space during the
  bootstrap and in the final installation as well, you can build the
  compiler binaries without debugging information as in the following
  example.  This will save roughly 40% of disk space both for the
--- 2503,2538 ----
  ==============================
  
  For a native build, the default configuration is to perform a 3-stage
! bootstrap of the compiler when ‘make’ is invoked.  This will build the
  entire GCC system and ensure that it compiles itself correctly.  It can
! be disabled with the ‘--disable-bootstrap’ parameter to ‘configure’, but
  bootstrapping is suggested because the compiler will be tested more
  completely and could also have better performance.
  
     The bootstrapping process will complete the following steps:
  
!    • Build tools necessary to build the compiler.
  
!    • Perform a 3-stage bootstrap of the compiler.  This includes
       building three times the target tools for use by the compiler such
       as binutils (bfd, binutils, gas, gprof, ld, and opcodes) if they
       have been individually linked or moved into the top level GCC
       source tree before configuring.
  
!    • Perform a comparison test of the stage2 and stage3 compilers.
  
!    • Build runtime libraries using the stage3 compiler from the previous
       step.
  
!    If you are short on disk space you might consider ‘make
! bootstrap-lean’ instead.  The sequence of compilation is the same
  described above, but object files from the stage1 and stage2 of the
  3-stage bootstrap of the compiler are deleted as soon as they are no
  longer needed.
  
     If you wish to use non-default GCC flags when compiling the stage2
! and stage3 compilers, set ‘BOOT_CFLAGS’ on the command line when doing
! ‘make’.  For example, if you want to save additional space during the
  bootstrap and in the final installation as well, you can build the
  compiler binaries without debugging information as in the following
  example.  This will save roughly 40% of disk space both for the
*************** debugging information.)
*** 2541,2685 ****
  
       make BOOT_CFLAGS='-O' bootstrap
  
!    You can place non-default optimization flags into 'BOOT_CFLAGS'; they
! are less well tested here than the default of '-g -O2', but should still
  work.  In a few cases, you may find that you need to specify special
! flags such as '-msoft-float' here to complete the bootstrap; or, if the
  native compiler miscompiles the stage1 compiler, you may need to work
! around this, by choosing 'BOOT_CFLAGS' to avoid the parts of the stage1
! compiler that were miscompiled, or by using 'make bootstrap4' to
  increase the number of stages of bootstrap.
  
!    'BOOT_CFLAGS' does not apply to bootstrapped target libraries.  Since
  these are always compiled with the compiler currently being
! bootstrapped, you can use 'CFLAGS_FOR_TARGET' to modify their
  compilation flags, as for non-bootstrapped target libraries.  Again, if
  the native compiler miscompiles the stage1 compiler, you may need to
  work around this by avoiding non-working parts of the stage1 compiler.
! Use 'STAGE1_TFLAGS' to this end.
  
!    If you used the flag '--enable-languages=...' to restrict the
  compilers to be built, only those you've actually enabled will be built.
  This will of course only build those runtime libraries, for which the
  particular compiler has been built.  Please note, that re-defining
! 'LANGUAGES' when calling 'make' *does not* work anymore!
  
     If the comparison of stage2 and stage3 fails, this normally indicates
  that the stage2 compiler has compiled GCC incorrectly, and is therefore
  a potentially serious bug which you should investigate and report.  (On
  a few systems, meaningful comparison of object files is impossible; they
  always appear "different".  If you encounter this problem, you will need
! to disable comparison in the 'Makefile'.)
  
     If you do not want to bootstrap your compiler, you can configure with
! '--disable-bootstrap'.  In particular cases, you may want to bootstrap
  your compiler even if the target system is not the same as the one you
  are building on: for example, you could build a
! 'powerpc-unknown-linux-gnu' toolchain on a 'powerpc64-unknown-linux-gnu'
! host.  In this case, pass '--enable-bootstrap' to the configure script.
  
!    'BUILD_CONFIG' can be used to bring in additional customization to
  the build.  It can be set to a whitespace-separated list of names.  For
! each such 'NAME', top-level 'config/NAME.mk' will be included by the
! top-level 'Makefile', bringing in any settings it contains.  The default
! 'BUILD_CONFIG' can be set using the configure option
! '--with-build-config=NAME...'.  Some examples of supported build
  configurations are:
  
! 'bootstrap-O1'
!      Removes any '-O'-started option from 'BOOT_CFLAGS', and adds '-O1'
!      to it.  'BUILD_CONFIG=bootstrap-O1' is equivalent to
!      'BOOT_CFLAGS='-g -O1''.
  
! 'bootstrap-O3'
! 'bootstrap-Og'
!      Analogous to 'bootstrap-O1'.
  
! 'bootstrap-lto'
       Enables Link-Time Optimization for host tools during bootstrapping.
!      'BUILD_CONFIG=bootstrap-lto' is equivalent to adding '-flto' to
!      'BOOT_CFLAGS'.  This option assumes that the host supports the
       linker plugin (e.g. GNU ld version 2.21 or later or GNU gold
       version 2.21 or later).
  
! 'bootstrap-lto-noplugin'
!      This option is similar to 'bootstrap-lto', but is intended for
       hosts that do not support the linker plugin.  Without the linker
       plugin static libraries are not compiled with link-time
       optimizations.  Since the GCC middle end and back end are in
!      'libbackend.a' this means that only the front end is actually LTO
       optimized.
  
! 'bootstrap-lto-lean'
!      This option is similar to 'bootstrap-lto', but is intended for
       faster build by only using LTO in the final bootstrap stage.  With
!      'make profiledbootstrap' the LTO frontend is trained only on
       generator files.
  
! 'bootstrap-debug'
       Verifies that the compiler generates the same executable code,
       whether or not it is asked to emit debug information.  To this end,
       this option builds stage2 host programs without debug information,
!      and uses 'contrib/compare-debug' to compare them with the stripped
!      stage3 object files.  If 'BOOT_CFLAGS' is overridden so as to not
       enable debug information, stage2 will have it, and stage3 won't.
       This option is enabled by default when GCC bootstrapping is
!      enabled, if 'strip' can turn object files compiled with and without
       debug info into identical object files.  In addition to better test
       coverage, this option makes default bootstraps faster and leaner.
  
! 'bootstrap-debug-big'
       Rather than comparing stripped object files, as in
!      'bootstrap-debug', this option saves internal compiler dumps during
       stage2 and stage3 and compares them as well, which helps catch
       additional potential problems, but at a great cost in terms of disk
!      space.  It can be specified in addition to 'bootstrap-debug'.
  
! 'bootstrap-debug-lean'
!      This option saves disk space compared with 'bootstrap-debug-big',
       but at the expense of some recompilation.  Instead of saving the
       dumps of stage2 and stage3 until the final compare, it uses
!      '-fcompare-debug' to generate, compare and remove the dumps during
       stage3, repeating the compilation that already took place in
       stage2, whose dumps were not saved.
  
! 'bootstrap-debug-lib'
       This option tests executable code invariance over debug information
!      generation on target libraries, just like 'bootstrap-debug-lean'
       tests it on host programs.  It builds stage3 libraries with
!      '-fcompare-debug', and it can be used along with any of the
!      'bootstrap-debug' options above.
  
!      There aren't '-lean' or '-big' counterparts to this option because
       most libraries are only build in stage3, so bootstrap compares
       would not get significant coverage.  Moreover, the few libraries
       built in stage2 are used in stage3 host programs, so we wouldn't
       want to compile stage2 libraries with different options for
       comparison purposes.
  
! 'bootstrap-debug-ckovw'
       Arranges for error messages to be issued if the compiler built on
!      any stage is run without the option '-fcompare-debug'.  This is
!      useful to verify the full '-fcompare-debug' testing coverage.  It
!      must be used along with 'bootstrap-debug-lean' and
!      'bootstrap-debug-lib'.
  
! 'bootstrap-cet'
       This option enables Intel CET for host tools during bootstrapping.
!      'BUILD_CONFIG=bootstrap-cet' is equivalent to adding
!      '-fcf-protection' to 'BOOT_CFLAGS'.  This option assumes that the
       host supports Intel CET (e.g. GNU assembler version 2.30 or later).
  
! 'bootstrap-time'
       Arranges for the run time of each program started by the GCC
!      driver, built in any stage, to be logged to 'time.log', in the top
       level of the build tree.
  
! 'bootstrap-asan'
       Compiles GCC itself using Address Sanitization in order to catch
       invalid memory accesses within the GCC code.
  
! 'bootstrap-hwasan'
       Compiles GCC itself using HWAddress Sanitization in order to catch
       invalid memory accesses within the GCC code.  This option is only
       available on AArch64 systems that are running Linux kernel version
--- 2541,2685 ----
  
       make BOOT_CFLAGS='-O' bootstrap
  
!    You can place non-default optimization flags into ‘BOOT_CFLAGS’; they
! are less well tested here than the default of ‘-g -O2’, but should still
  work.  In a few cases, you may find that you need to specify special
! flags such as ‘-msoft-float’ here to complete the bootstrap; or, if the
  native compiler miscompiles the stage1 compiler, you may need to work
! around this, by choosing ‘BOOT_CFLAGS’ to avoid the parts of the stage1
! compiler that were miscompiled, or by using ‘make bootstrap4’ to
  increase the number of stages of bootstrap.
  
!    ‘BOOT_CFLAGS’ does not apply to bootstrapped target libraries.  Since
  these are always compiled with the compiler currently being
! bootstrapped, you can use ‘CFLAGS_FOR_TARGET’ to modify their
  compilation flags, as for non-bootstrapped target libraries.  Again, if
  the native compiler miscompiles the stage1 compiler, you may need to
  work around this by avoiding non-working parts of the stage1 compiler.
! Use ‘STAGE1_TFLAGS’ to this end.
  
!    If you used the flag ‘--enable-languages=...’ to restrict the
  compilers to be built, only those you've actually enabled will be built.
  This will of course only build those runtime libraries, for which the
  particular compiler has been built.  Please note, that re-defining
! ‘LANGUAGES’ when calling ‘make’ *does not* work anymore!
  
     If the comparison of stage2 and stage3 fails, this normally indicates
  that the stage2 compiler has compiled GCC incorrectly, and is therefore
  a potentially serious bug which you should investigate and report.  (On
  a few systems, meaningful comparison of object files is impossible; they
  always appear "different".  If you encounter this problem, you will need
! to disable comparison in the ‘Makefile’.)
  
     If you do not want to bootstrap your compiler, you can configure with
! ‘--disable-bootstrap’.  In particular cases, you may want to bootstrap
  your compiler even if the target system is not the same as the one you
  are building on: for example, you could build a
! ‘powerpc-unknown-linux-gnu’ toolchain on a ‘powerpc64-unknown-linux-gnu’
! host.  In this case, pass ‘--enable-bootstrap’ to the configure script.
  
!    ‘BUILD_CONFIG’ can be used to bring in additional customization to
  the build.  It can be set to a whitespace-separated list of names.  For
! each such ‘NAME’, top-level ‘config/NAME.mk’ will be included by the
! top-level ‘Makefile’, bringing in any settings it contains.  The default
! ‘BUILD_CONFIG’ can be set using the configure option
! ‘--with-build-config=NAME...’.  Some examples of supported build
  configurations are:
  
! ‘bootstrap-O1’
!      Removes any ‘-O’-started option from ‘BOOT_CFLAGS’, and adds ‘-O1’
!      to it.  ‘BUILD_CONFIG=bootstrap-O1’ is equivalent to
!      ‘BOOT_CFLAGS='-g -O1'’.
  
! ‘bootstrap-O3’
! ‘bootstrap-Og’
!      Analogous to ‘bootstrap-O1’.
  
! ‘bootstrap-lto’
       Enables Link-Time Optimization for host tools during bootstrapping.
!      ‘BUILD_CONFIG=bootstrap-lto’ is equivalent to adding ‘-flto’ to
!      ‘BOOT_CFLAGS’.  This option assumes that the host supports the
       linker plugin (e.g. GNU ld version 2.21 or later or GNU gold
       version 2.21 or later).
  
! ‘bootstrap-lto-noplugin’
!      This option is similar to ‘bootstrap-lto’, but is intended for
       hosts that do not support the linker plugin.  Without the linker
       plugin static libraries are not compiled with link-time
       optimizations.  Since the GCC middle end and back end are in
!      ‘libbackend.a’ this means that only the front end is actually LTO
       optimized.
  
! ‘bootstrap-lto-lean’
!      This option is similar to ‘bootstrap-lto’, but is intended for
       faster build by only using LTO in the final bootstrap stage.  With
!      ‘make profiledbootstrap’ the LTO frontend is trained only on
       generator files.
  
! ‘bootstrap-debug’
       Verifies that the compiler generates the same executable code,
       whether or not it is asked to emit debug information.  To this end,
       this option builds stage2 host programs without debug information,
!      and uses ‘contrib/compare-debug’ to compare them with the stripped
!      stage3 object files.  If ‘BOOT_CFLAGS’ is overridden so as to not
       enable debug information, stage2 will have it, and stage3 won't.
       This option is enabled by default when GCC bootstrapping is
!      enabled, if ‘strip’ can turn object files compiled with and without
       debug info into identical object files.  In addition to better test
       coverage, this option makes default bootstraps faster and leaner.
  
! ‘bootstrap-debug-big’
       Rather than comparing stripped object files, as in
!      ‘bootstrap-debug’, this option saves internal compiler dumps during
       stage2 and stage3 and compares them as well, which helps catch
       additional potential problems, but at a great cost in terms of disk
!      space.  It can be specified in addition to ‘bootstrap-debug’.
  
! ‘bootstrap-debug-lean’
!      This option saves disk space compared with ‘bootstrap-debug-big’,
       but at the expense of some recompilation.  Instead of saving the
       dumps of stage2 and stage3 until the final compare, it uses
!      ‘-fcompare-debug’ to generate, compare and remove the dumps during
       stage3, repeating the compilation that already took place in
       stage2, whose dumps were not saved.
  
! ‘bootstrap-debug-lib’
       This option tests executable code invariance over debug information
!      generation on target libraries, just like ‘bootstrap-debug-lean’
       tests it on host programs.  It builds stage3 libraries with
!      ‘-fcompare-debug’, and it can be used along with any of the
!      ‘bootstrap-debug’ options above.
  
!      There aren't ‘-lean’ or ‘-big’ counterparts to this option because
       most libraries are only build in stage3, so bootstrap compares
       would not get significant coverage.  Moreover, the few libraries
       built in stage2 are used in stage3 host programs, so we wouldn't
       want to compile stage2 libraries with different options for
       comparison purposes.
  
! ‘bootstrap-debug-ckovw’
       Arranges for error messages to be issued if the compiler built on
!      any stage is run without the option ‘-fcompare-debug’.  This is
!      useful to verify the full ‘-fcompare-debug’ testing coverage.  It
!      must be used along with ‘bootstrap-debug-lean’ and
!      ‘bootstrap-debug-lib’.
  
! ‘bootstrap-cet’
       This option enables Intel CET for host tools during bootstrapping.
!      ‘BUILD_CONFIG=bootstrap-cet’ is equivalent to adding
!      ‘-fcf-protection’ to ‘BOOT_CFLAGS’.  This option assumes that the
       host supports Intel CET (e.g. GNU assembler version 2.30 or later).
  
! ‘bootstrap-time’
       Arranges for the run time of each program started by the GCC
!      driver, built in any stage, to be logged to ‘time.log’, in the top
       level of the build tree.
  
! ‘bootstrap-asan’
       Compiles GCC itself using Address Sanitization in order to catch
       invalid memory accesses within the GCC code.
  
! ‘bootstrap-hwasan’
       Compiles GCC itself using HWAddress Sanitization in order to catch
       invalid memory accesses within the GCC code.  This option is only
       available on AArch64 systems that are running Linux kernel version
*************** the cross compiler.  The installed nativ
*** 2698,2735 ****
  version 2.95 or later.
  
     Assuming you have already installed a native copy of GCC and
! configured your cross compiler, issue the command 'make', which performs
  the following steps:
  
!    * Build host tools necessary to build the compiler.
  
!    * Build target tools for use by the compiler such as binutils (bfd,
       binutils, gas, gprof, ld, and opcodes) if they have been
       individually linked or moved into the top level GCC source tree
       before configuring.
  
!    * Build the compiler (single stage only).
  
!    * Build runtime libraries using the compiler from the previous step.
  
     Note that if an error occurs in any step the make process will exit.
  
     If you are not building GNU binutils in the same source tree as GCC,
  you will need a cross-assembler and cross-linker installed before
! configuring GCC.  Put them in the directory 'PREFIX/TARGET/bin'.  Here
  is a table of the tools you should put in this directory:
  
! 'as'
       This should be the cross-assembler.
  
! 'ld'
       This should be the cross-linker.
  
! 'ar'
       This should be the cross-archiver: a program which can manipulate
       archive files (linker libraries) in the target machine's format.
  
! 'ranlib'
       This should be a program to construct a symbol table in an archive
       file.
  
--- 2698,2735 ----
  version 2.95 or later.
  
     Assuming you have already installed a native copy of GCC and
! configured your cross compiler, issue the command ‘make’, which performs
  the following steps:
  
!    • Build host tools necessary to build the compiler.
  
!    • Build target tools for use by the compiler such as binutils (bfd,
       binutils, gas, gprof, ld, and opcodes) if they have been
       individually linked or moved into the top level GCC source tree
       before configuring.
  
!    • Build the compiler (single stage only).
  
!    • Build runtime libraries using the compiler from the previous step.
  
     Note that if an error occurs in any step the make process will exit.
  
     If you are not building GNU binutils in the same source tree as GCC,
  you will need a cross-assembler and cross-linker installed before
! configuring GCC.  Put them in the directory ‘PREFIX/TARGET/bin’.  Here
  is a table of the tools you should put in this directory:
  
! ‘as’
       This should be the cross-assembler.
  
! ‘ld’
       This should be the cross-linker.
  
! ‘ar’
       This should be the cross-archiver: a program which can manipulate
       archive files (linker libraries) in the target machine's format.
  
! ‘ranlib’
       This should be a program to construct a symbol table in an archive
       file.
  
*************** and copy or link them to the proper plac
*** 2738,2763 ****
  find them when run later.
  
     The easiest way to provide these files is to build the Binutils
! package.  Configure it with the same '--host' and '--target' options
  that you use for configuring GCC, then build and install them.  They
  install their executables automatically into the proper directory.
  Alas, they do not support all the targets that GCC supports.
  
     If you are not building a C library in the same source tree as GCC,
  you should also provide the target libraries and headers before
! configuring GCC, specifying the directories with '--with-sysroot' or
! '--with-headers' and '--with-libs'.  Many targets also require "start
! files" such as 'crt0.o' and 'crtn.o' which are linked into each
! executable.  There may be several alternatives for 'crt0.o', for use
  with profiling or other compilation options.  Check your target's
! definition of 'STARTFILE_SPEC' to find out what start files it uses.
  
  5.3 Building in parallel
  ========================
  
  GNU Make 3.80 and above, which is necessary to build GCC, support
! building in parallel.  To activate this, you can use 'make -j 2' instead
! of 'make'.  You can also specify a bigger number, and in most cases
  using a value greater than the number of processors in your machine will
  result in fewer and shorter I/O latency hits, thus improving overall
  throughput; this is especially true for slow drives and network
--- 2738,2763 ----
  find them when run later.
  
     The easiest way to provide these files is to build the Binutils
! package.  Configure it with the same ‘--host’ and ‘--target’ options
  that you use for configuring GCC, then build and install them.  They
  install their executables automatically into the proper directory.
  Alas, they do not support all the targets that GCC supports.
  
     If you are not building a C library in the same source tree as GCC,
  you should also provide the target libraries and headers before
! configuring GCC, specifying the directories with ‘--with-sysroot’ or
! ‘--with-headers’ and ‘--with-libs’.  Many targets also require "start
! files" such as ‘crt0.o’ and ‘crtn.o’ which are linked into each
! executable.  There may be several alternatives for ‘crt0.o’, for use
  with profiling or other compilation options.  Check your target's
! definition of ‘STARTFILE_SPEC’ to find out what start files it uses.
  
  5.3 Building in parallel
  ========================
  
  GNU Make 3.80 and above, which is necessary to build GCC, support
! building in parallel.  To activate this, you can use ‘make -j 2’ instead
! of ‘make’.  You can also specify a bigger number, and in most cases
  using a value greater than the number of processors in your machine will
  result in fewer and shorter I/O latency hits, thus improving overall
  throughput; this is especially true for slow drives and network
*************** filesystems.
*** 2779,2802 ****
  It is possible to use profile feedback to optimize the compiler itself.
  This should result in a faster compiler binary.  Experiments done on x86
  using gcc 3.3 showed approximately 7 percent speedup on compiling C
! programs.  To bootstrap the compiler with profile feedback, use 'make
! profiledbootstrap'.
  
!    When 'make profiledbootstrap' is run, it will first build a 'stage1'
! compiler.  This compiler is used to build a 'stageprofile' compiler
  instrumented to collect execution counts of instruction and branch
! probabilities.  Training run is done by building 'stagetrain' compiler.
! Finally a 'stagefeedback' compiler is built using the information
  collected.
  
     Unlike standard bootstrap, several additional restrictions apply.
! The compiler used to build 'stage1' needs to support a 64-bit integral
  type.  It is recommended to only use GCC for this.
  
     On Linux/x86_64 hosts with some restrictions (no virtualization) it
! is also possible to do autofdo build with 'make autoprofiledback'.  This
  uses Linux perf to sample branches in the binary and then rebuild it
! with feedback derived from the profile.  Linux perf and the 'autofdo'
  toolkit needs to be installed for this.
  
     Only the profile from the current build is used, so when an error
--- 2779,2802 ----
  It is possible to use profile feedback to optimize the compiler itself.
  This should result in a faster compiler binary.  Experiments done on x86
  using gcc 3.3 showed approximately 7 percent speedup on compiling C
! programs.  To bootstrap the compiler with profile feedback, use ‘make
! profiledbootstrap’.
  
!    When ‘make profiledbootstrap’ is run, it will first build a ‘stage1’
! compiler.  This compiler is used to build a ‘stageprofile’ compiler
  instrumented to collect execution counts of instruction and branch
! probabilities.  Training run is done by building ‘stagetrain’ compiler.
! Finally a ‘stagefeedback’ compiler is built using the information
  collected.
  
     Unlike standard bootstrap, several additional restrictions apply.
! The compiler used to build ‘stage1’ needs to support a 64-bit integral
  type.  It is recommended to only use GCC for this.
  
     On Linux/x86_64 hosts with some restrictions (no virtualization) it
! is also possible to do autofdo build with ‘make autoprofiledback’.  This
  uses Linux perf to sample branches in the binary and then rebuild it
! with feedback derived from the profile.  Linux perf and the ‘autofdo’
  toolkit needs to be installed for this.
  
     Only the profile from the current build is used, so when an error
*************** in the source tarball.
*** 2826,2835 ****
  DejaGnu, Tcl, and Expect; the DejaGnu site has links to these.  Some
  optional tests also require Python3 and pytest module.
  
!    If the directories where 'runtest' and 'expect' were installed are
! not in the 'PATH', you may need to set the following environment
  variables appropriately, as in the following example (which assumes that
! DejaGnu has been installed under '/usr/local'):
  
       TCL_LIBRARY = /usr/local/share/tcl8.0
       DEJAGNULIBS = /usr/local/share/dejagnu
--- 2826,2835 ----
  DejaGnu, Tcl, and Expect; the DejaGnu site has links to these.  Some
  optional tests also require Python3 and pytest module.
  
!    If the directories where ‘runtest’ and ‘expect’ were installed are
! not in the ‘PATH’, you may need to set the following environment
  variables appropriately, as in the following example (which assumes that
! DejaGnu has been installed under ‘/usr/local’):
  
       TCL_LIBRARY = /usr/local/share/tcl8.0
       DEJAGNULIBS = /usr/local/share/dejagnu
*************** portability in the DejaGnu code.)
*** 2843,2850 ****
  
     This will test various components of GCC, such as compiler front ends
  and runtime libraries.  While running the testsuite, DejaGnu might emit
! some harmless messages resembling 'WARNING: Couldn't find the global
! config file.' or 'WARNING: Couldn't find tool init file' that can be
  ignored.
  
     If you are testing a cross-compiler, you may want to run the
--- 2843,2850 ----
  
     This will test various components of GCC, such as compiler front ends
  and runtime libraries.  While running the testsuite, DejaGnu might emit
! some harmless messages resembling ‘WARNING: Couldn't find the global
! config file.’ or ‘WARNING: Couldn't find tool init file’ that can be
  ignored.
  
     If you are testing a cross-compiler, you may want to run the
*************** testsuite on a simulator as described at
*** 2854,2877 ****
  6.1 How can you run the testsuite on selected tests?
  ====================================================
  
! In order to run sets of tests selectively, there are targets 'make
! check-gcc' and language specific 'make check-c', 'make check-c++', 'make
! check-d' 'make check-fortran', 'make check-ada', 'make check-m2', 'make
! check-objc', 'make check-obj-c++', 'make check-lto' in the 'gcc'
! subdirectory of the object directory.  You can also just run 'make
! check' in a subdirectory of the object directory.
  
!    A more selective way to just run all 'gcc' execute tests in the
  testsuite is to use
  
       make check-gcc RUNTESTFLAGS="execute.exp OTHER-OPTIONS"
  
!    Likewise, in order to run only the 'g++' "old-deja" tests in the
! testsuite with filenames matching '9805*', you would use
  
       make check-g++ RUNTESTFLAGS="old-deja.exp=9805* OTHER-OPTIONS"
  
!    The file-matching expression following FILENAME'.exp=' is treated as
  a series of whitespace-delimited glob expressions so that multiple
  patterns may be passed, although any whitespace must either be escaped
  or surrounded by single quotes if multiple expressions are desired.  For
--- 2854,2877 ----
  6.1 How can you run the testsuite on selected tests?
  ====================================================
  
! In order to run sets of tests selectively, there are targets ‘make
! check-gcc’ and language specific ‘make check-c’, ‘make check-c++’, ‘make
! check-d’ ‘make check-fortran’, ‘make check-ada’, ‘make check-m2’, ‘make
! check-objc’, ‘make check-obj-c++’, ‘make check-lto’ in the ‘gcc’
! subdirectory of the object directory.  You can also just run ‘make
! check’ in a subdirectory of the object directory.
  
!    A more selective way to just run all ‘gcc’ execute tests in the
  testsuite is to use
  
       make check-gcc RUNTESTFLAGS="execute.exp OTHER-OPTIONS"
  
!    Likewise, in order to run only the ‘g++’ "old-deja" tests in the
! testsuite with filenames matching ‘9805*’, you would use
  
       make check-g++ RUNTESTFLAGS="old-deja.exp=9805* OTHER-OPTIONS"
  
!    The file-matching expression following FILENAME‘.exp=’ is treated as
  a series of whitespace-delimited glob expressions so that multiple
  patterns may be passed, although any whitespace must either be escaped
  or surrounded by single quotes if multiple expressions are desired.  For
*************** example,
*** 2880,2903 ****
       make check-g++ RUNTESTFLAGS="old-deja.exp=9805*\ virtual2.c OTHER-OPTIONS"
       make check-g++ RUNTESTFLAGS="'old-deja.exp=9805* virtual2.c' OTHER-OPTIONS"
  
!    The '*.exp' files are located in the testsuite directories of the GCC
! source, the most important ones being 'compile.exp', 'execute.exp',
! 'dg.exp' and 'old-deja.exp'.  To get a list of the possible '*.exp'
! files, pipe the output of 'make check' into a file and look at the
! 'Running ... .exp' lines.
  
  6.2 Passing options and running multiple testsuites
  ===================================================
  
  You can pass multiple options to the testsuite using the
! '--target_board' option of DejaGNU, either passed as part of
! 'RUNTESTFLAGS', or directly to 'runtest' if you prefer to work outside
  the makefiles.  For example,
  
       make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
  
!    will run the standard 'g++' testsuites ("unix" is the target name for
! a standard native testsuite situation), passing '-O3 -fmerge-constants'
  to the compiler on every test, i.e., slashes separate options.
  
     You can run the testsuites multiple times using combinations of
--- 2880,2903 ----
       make check-g++ RUNTESTFLAGS="old-deja.exp=9805*\ virtual2.c OTHER-OPTIONS"
       make check-g++ RUNTESTFLAGS="'old-deja.exp=9805* virtual2.c' OTHER-OPTIONS"
  
!    The ‘*.exp’ files are located in the testsuite directories of the GCC
! source, the most important ones being ‘compile.exp’, ‘execute.exp’,
! ‘dg.exp’ and ‘old-deja.exp’.  To get a list of the possible ‘*.exp’
! files, pipe the output of ‘make check’ into a file and look at the
! ‘Running ... .exp’ lines.
  
  6.2 Passing options and running multiple testsuites
  ===================================================
  
  You can pass multiple options to the testsuite using the
! ‘--target_board’ option of DejaGNU, either passed as part of
! ‘RUNTESTFLAGS’, or directly to ‘runtest’ if you prefer to work outside
  the makefiles.  For example,
  
       make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
  
!    will run the standard ‘g++’ testsuites ("unix" is the target name for
! a standard native testsuite situation), passing ‘-O3 -fmerge-constants’
  to the compiler on every test, i.e., slashes separate options.
  
     You can run the testsuites multiple times using combinations of
*************** options with a syntax similar to the bra
*** 2907,2913 ****
  
     (Note the empty option caused by the trailing comma in the final
  group.)  The following will run each testsuite eight times using the
! 'arm-sim' target, as if you had specified all possible combinations
  yourself:
  
       --target_board='arm-sim/-mhard-float/-O1 \
--- 2907,2913 ----
  
     (Note the empty option caused by the trailing comma in the final
  group.)  The following will run each testsuite eight times using the
! ‘arm-sim’ target, as if you had specified all possible combinations
  yourself:
  
       --target_board='arm-sim/-mhard-float/-O1 \
*************** This list:
*** 2924,2936 ****
  
       ..."--target_board=unix/-Wextra\{-O3,-fno-strength\}\{-fomit-frame,\}"
  
!    will generate four combinations, all involving '-Wextra'.
  
     The disadvantage to this method is that the testsuites are run in
  serial, which is a waste on multiprocessor systems.  For users with GNU
  Make and a shell which performs brace expansion, you can run the
  testsuites in parallel by having the shell perform the combinations and
! 'make' do the parallel runs.  Instead of using '--target_board', use a
  special makefile target:
  
       make -jN check-TESTSUITE//TEST-TARGET/OPTION1/OPTION2/...
--- 2924,2936 ----
  
       ..."--target_board=unix/-Wextra\{-O3,-fno-strength\}\{-fomit-frame,\}"
  
!    will generate four combinations, all involving ‘-Wextra’.
  
     The disadvantage to this method is that the testsuites are run in
  serial, which is a waste on multiprocessor systems.  For users with GNU
  Make and a shell which performs brace expansion, you can run the
  testsuites in parallel by having the shell perform the combinations and
! ‘make’ do the parallel runs.  Instead of using ‘--target_board’, use a
  special makefile target:
  
       make -jN check-TESTSUITE//TEST-TARGET/OPTION1/OPTION2/...
*************** special makefile target:
*** 2941,2965 ****
  
     will run three concurrent "make-gcc" testsuites, eventually testing
  all ten combinations as described above.  Note that this is currently
! only supported in the 'gcc' subdirectory.  (To see how this works, try
! typing 'echo' before the example given here.)
  
  6.3 How to interpret test results
  =================================
  
! The result of running the testsuite are various '*.sum' and '*.log'
! files in the testsuite subdirectories.  The '*.log' files contain a
  detailed log of the compiler invocations and the corresponding results,
! the '*.sum' files summarize the results.  These summaries contain status
  codes for all tests:
  
!    * PASS: the test passed as expected
!    * XPASS: the test unexpectedly passed
!    * FAIL: the test unexpectedly failed
!    * XFAIL: the test failed as expected
!    * UNSUPPORTED: the test is not supported on this platform
!    * ERROR: the testsuite detected an error
!    * WARNING: the testsuite detected a possible problem
  
     It is normal for some tests to report unexpected failures.  At the
  current time the testing harness does not allow fine grained control
--- 2941,2965 ----
  
     will run three concurrent "make-gcc" testsuites, eventually testing
  all ten combinations as described above.  Note that this is currently
! only supported in the ‘gcc’ subdirectory.  (To see how this works, try
! typing ‘echo’ before the example given here.)
  
  6.3 How to interpret test results
  =================================
  
! The result of running the testsuite are various ‘*.sum’ and ‘*.log’
! files in the testsuite subdirectories.  The ‘*.log’ files contain a
  detailed log of the compiler invocations and the corresponding results,
! the ‘*.sum’ files summarize the results.  These summaries contain status
  codes for all tests:
  
!    • PASS: the test passed as expected
!    • XPASS: the test unexpectedly passed
!    • FAIL: the test unexpectedly failed
!    • XFAIL: the test failed as expected
!    • UNSUPPORTED: the test is not supported on this platform
!    • ERROR: the testsuite detected an error
!    • WARNING: the testsuite detected a possible problem
  
     It is normal for some tests to report unexpected failures.  At the
  current time the testing harness does not allow fine grained control
*************** fixed in future releases.
*** 2970,2982 ****
  ===========================
  
  If you want to report the results to the GCC project, use the
! 'contrib/test_summary' shell script.  Start it in the OBJDIR with
  
       SRCDIR/contrib/test_summary -p your_commentary.txt \
           -m gcc-testresults@gcc.gnu.org |sh
  
!    This script uses the 'Mail' program to send the results, so make sure
! it is in your 'PATH'.  The file 'your_commentary.txt' is prepended to
  the testsuite summary and should contain any special remarks you have on
  your results or your build environment.  Please do not edit the
  testsuite result block or the subject line, as these messages may be
--- 2970,2982 ----
  ===========================
  
  If you want to report the results to the GCC project, use the
! ‘contrib/test_summary’ shell script.  Start it in the OBJDIR with
  
       SRCDIR/contrib/test_summary -p your_commentary.txt \
           -m gcc-testresults@gcc.gnu.org |sh
  
!    This script uses the ‘Mail’ program to send the results, so make sure
! it is in your ‘PATH’.  The file ‘your_commentary.txt’ is prepended to
  the testsuite summary and should contain any special remarks you have on
  your results or your build environment.  Please do not edit the
  testsuite result block or the subject line, as these messages may be
*************** that depend on this debugging informatio
*** 2999,3035 ****
  instance).
  
     That step completes the installation of GCC; user level binaries can
! be found in 'PREFIX/bin' where PREFIX is the value you specified with
! the '--prefix' to configure (or '/usr/local' by default).  (If you
! specified '--bindir', that directory will be used instead; otherwise, if
! you specified '--exec-prefix', 'EXEC-PREFIX/bin' will be used.)  Headers
! for the C++ library are installed in 'PREFIX/include'; libraries in
! 'LIBDIR' (normally 'PREFIX/lib'); internal parts of the compiler in
! 'LIBDIR/gcc' and 'LIBEXECDIR/gcc'; documentation in info format in
! 'INFODIR' (normally 'PREFIX/info').
  
     When installing cross-compilers, GCC's executables are not only
! installed into 'BINDIR', that is, 'EXEC-PREFIX/bin', but additionally
! into 'EXEC-PREFIX/TARGET-ALIAS/bin', if that directory exists.
! Typically, such "tooldirs" hold target-specific binutils, including
  assembler and linker.
  
!    Installation into a temporary staging area or into a 'chroot' jail
  can be achieved with the command
  
       make DESTDIR=PATH-TO-ROOTDIR install
  
  where PATH-TO-ROOTDIR is the absolute path of a directory relative to
  which all installation paths will be interpreted.  Note that the
! directory specified by 'DESTDIR' need not exist yet; it will be created
  if necessary.
  
!    There is a subtle point with tooldirs and 'DESTDIR': If you relocate
! a cross-compiler installation with e.g. 'DESTDIR=ROOTDIR', then the
! directory 'ROOTDIR/EXEC-PREFIX/TARGET-ALIAS/bin' will be filled with
  duplicated GCC executables only if it already exists, it will not be
  created otherwise.  This is regarded as a feature, not as a bug, because
! it gives slightly more control to the packagers using the 'DESTDIR'
  feature.
  
     You can install stripped programs and libraries with
--- 2999,3035 ----
  instance).
  
     That step completes the installation of GCC; user level binaries can
! be found in ‘PREFIX/bin’ where PREFIX is the value you specified with
! the ‘--prefix’ to configure (or ‘/usr/local’ by default).  (If you
! specified ‘--bindir’, that directory will be used instead; otherwise, if
! you specified ‘--exec-prefix’, ‘EXEC-PREFIX/bin’ will be used.)  Headers
! for the C++ library are installed in ‘PREFIX/include’; libraries in
! ‘LIBDIR’ (normally ‘PREFIX/lib’); internal parts of the compiler in
! ‘LIBDIR/gcc’ and ‘LIBEXECDIR/gcc’; documentation in info format in
! ‘INFODIR’ (normally ‘PREFIX/info’).
  
     When installing cross-compilers, GCC's executables are not only
! installed into ‘BINDIR’, that is, ‘EXEC-PREFIX/bin’, but additionally
! into ‘EXEC-PREFIX/TARGET-ALIAS/bin’, if that directory exists.
! Typically, such “tooldirs” hold target-specific binutils, including
  assembler and linker.
  
!    Installation into a temporary staging area or into a ‘chroot’ jail
  can be achieved with the command
  
       make DESTDIR=PATH-TO-ROOTDIR install
  
  where PATH-TO-ROOTDIR is the absolute path of a directory relative to
  which all installation paths will be interpreted.  Note that the
! directory specified by ‘DESTDIR’ need not exist yet; it will be created
  if necessary.
  
!    There is a subtle point with tooldirs and ‘DESTDIR’: If you relocate
! a cross-compiler installation with e.g. ‘DESTDIR=ROOTDIR’, then the
! directory ‘ROOTDIR/EXEC-PREFIX/TARGET-ALIAS/bin’ will be filled with
  duplicated GCC executables only if it already exists, it will not be
  created otherwise.  This is regarded as a feature, not as a bug, because
! it gives slightly more control to the packagers using the ‘DESTDIR’
  feature.
  
     You can install stripped programs and libraries with
*************** the version of GCC that you built, send
*** 3060,3088 ****
  indicating that you successfully built and installed GCC.  Include the
  following information:
  
!    * Output from running 'SRCDIR/config.guess'.  Do not send that file
       itself, just the one-line output from running it.
  
!    * The output of 'gcc -v' for your newly installed 'gcc'.  This tells
       us which version of GCC you built and the options you passed to
       configure.
  
!    * If the build was for GNU/Linux, also include:
!         * The distribution name and version (e.g., Red Hat 7.1 or Debian
            2.2.3); this information should be available from
!           '/etc/issue'.
  
!         * The version of the Linux kernel, available from 'uname
!           --version' or 'uname -a'.
  
!         * The version of glibc you used; for RPM-based systems like Red
!           Hat, Mandrake, and SuSE type 'rpm -q glibc' to get the glibc
!           version, and on systems like Debian and Progeny use 'dpkg -l
!           libc6'.
       For other systems, you can include similar information if you think
       it is relevant.
  
!    * Any other information that you think would be useful to people
       building GCC on the same configuration.  The new entry in the build
       status list will include a link to the archived copy of your
       message.
--- 3060,3088 ----
  indicating that you successfully built and installed GCC.  Include the
  following information:
  
!    • Output from running ‘SRCDIR/config.guess’.  Do not send that file
       itself, just the one-line output from running it.
  
!    • The output of ‘gcc -v’ for your newly installed ‘gcc’.  This tells
       us which version of GCC you built and the options you passed to
       configure.
  
!    • If the build was for GNU/Linux, also include:
!         • The distribution name and version (e.g., Red Hat 7.1 or Debian
            2.2.3); this information should be available from
!           ‘/etc/issue’.
  
!         • The version of the Linux kernel, available from ‘uname
!           --version’ or ‘uname -a’.
  
!         • The version of glibc you used; for RPM-based systems like Red
!           Hat, Mandrake, and SuSE type ‘rpm -q glibc’ to get the glibc
!           version, and on systems like Debian and Progeny use ‘dpkg -l
!           libc6’.
       For other systems, you can include similar information if you think
       it is relevant.
  
!    • Any other information that you think would be useful to people
       building GCC on the same configuration.  The new entry in the build
       status list will include a link to the archived copy of your
       message.
*************** various reasons.
*** 3110,3134 ****
  them.  If you have any problems installing them, please contact their
  makers.
  
!    * AIX:
!         * AIX Open Source Packages (AIX5L AIX 6.1 AIX 7.1).
  
!    * DOS--DJGPP.
  
!    * HP-UX:
!         * HP-UX Porting Center;
  
!    * macOS:
!         * The Homebrew package manager;
!         * MacPorts.
  
!    * Microsoft Windows:
!         * The Cygwin project;
!         * The MinGW and mingw-w64 projects.
  
!    * OpenPKG offers binaries for quite a number of platforms.
  
!    * The GFortran Wiki has links to GNU Fortran binaries for several
       platforms.
  
  
--- 3110,3134 ----
  them.  If you have any problems installing them, please contact their
  makers.
  
!    • AIX:
!         • AIX Open Source Packages (AIX5L AIX 6.1 AIX 7.1).
  
!    • DOS--DJGPP.
  
!    • HP-UX:
!         • HP-UX Porting Center;
  
!    • macOS:
!         • The Homebrew package manager;
!         • MacPorts.
  
!    • Microsoft Windows:
!         • The Cygwin project;
!         • The MinGW and mingw-w64 projects.
  
!    • OpenPKG offers binaries for quite a number of platforms.
  
!    • The GFortran Wiki has links to GNU Fortran binaries for several
       platforms.
  
  
*************** have to.
*** 3148,3185 ****
  aarch64*-*-*
  ============
  
! Binutils pre 2.24 does not have support for selecting '-mabi' and does
  not support ILP32.  If it is used to build GCC 4.9 or later, GCC will
! not support option '-mabi=ilp32'.
  
     To enable a workaround for the Cortex-A53 erratum number 835769 by
  default (for all CPUs regardless of -mcpu option given) at configure
! time use the '--enable-fix-cortex-a53-835769' option.  This will enable
  the fix by default and can be explicitly disabled during compilation by
! passing the '-mno-fix-cortex-a53-835769' option.  Conversely,
! '--disable-fix-cortex-a53-835769' will disable the workaround by
  default.  The workaround is disabled by default if neither of
! '--enable-fix-cortex-a53-835769' or '--disable-fix-cortex-a53-835769' is
  given at configure time.
  
     To enable a workaround for the Cortex-A53 erratum number 843419 by
  default (for all CPUs regardless of -mcpu option given) at configure
! time use the '--enable-fix-cortex-a53-843419' option.  This workaround
  is applied at link time.  Enabling the workaround will cause GCC to pass
  the relevant option to the linker.  It can be explicitly disabled during
! compilation by passing the '-mno-fix-cortex-a53-843419' option.
! Conversely, '--disable-fix-cortex-a53-843419' will disable the
  workaround by default.  The workaround is disabled by default if neither
! of '--enable-fix-cortex-a53-843419' or '--disable-fix-cortex-a53-843419'
  is given at configure time.
  
     To enable Branch Target Identification Mechanism and Return Address
  Signing by default at configure time use the
! '--enable-standard-branch-protection' option.  This is equivalent to
! having '-mbranch-protection=standard' during compilation.  This can be
  explicitly disabled during compilation by passing the
! '-mbranch-protection=none' option which turns off all types of branch
! protections.  Conversely, '--disable-standard-branch-protection' will
  disable both the protections by default.  This mechanism is turned off
  by default if neither of the options are given at configure time.
  
--- 3148,3185 ----
  aarch64*-*-*
  ============
  
! Binutils pre 2.24 does not have support for selecting ‘-mabi’ and does
  not support ILP32.  If it is used to build GCC 4.9 or later, GCC will
! not support option ‘-mabi=ilp32’.
  
     To enable a workaround for the Cortex-A53 erratum number 835769 by
  default (for all CPUs regardless of -mcpu option given) at configure
! time use the ‘--enable-fix-cortex-a53-835769’ option.  This will enable
  the fix by default and can be explicitly disabled during compilation by
! passing the ‘-mno-fix-cortex-a53-835769’ option.  Conversely,
! ‘--disable-fix-cortex-a53-835769’ will disable the workaround by
  default.  The workaround is disabled by default if neither of
! ‘--enable-fix-cortex-a53-835769’ or ‘--disable-fix-cortex-a53-835769’ is
  given at configure time.
  
     To enable a workaround for the Cortex-A53 erratum number 843419 by
  default (for all CPUs regardless of -mcpu option given) at configure
! time use the ‘--enable-fix-cortex-a53-843419’ option.  This workaround
  is applied at link time.  Enabling the workaround will cause GCC to pass
  the relevant option to the linker.  It can be explicitly disabled during
! compilation by passing the ‘-mno-fix-cortex-a53-843419’ option.
! Conversely, ‘--disable-fix-cortex-a53-843419’ will disable the
  workaround by default.  The workaround is disabled by default if neither
! of ‘--enable-fix-cortex-a53-843419’ or ‘--disable-fix-cortex-a53-843419’
  is given at configure time.
  
     To enable Branch Target Identification Mechanism and Return Address
  Signing by default at configure time use the
! ‘--enable-standard-branch-protection’ option.  This is equivalent to
! having ‘-mbranch-protection=standard’ during compilation.  This can be
  explicitly disabled during compilation by passing the
! ‘-mbranch-protection=none’ option which turns off all types of branch
! protections.  Conversely, ‘--disable-standard-branch-protection’ will
  disable both the protections by default.  This mechanism is turned off
  by default if neither of the options are given at configure time.
  
*************** please read all other sections that matc
*** 3193,3199 ****
  amd64-*-solaris2*
  =================
  
! This is a synonym for 'x86_64-*-solaris2*'.
  
  amdgcn-*-amdhsa
  ===============
--- 3193,3199 ----
  amd64-*-solaris2*
  =================
  
! This is a synonym for ‘x86_64-*-solaris2*’.
  
  amdgcn-*-amdhsa
  ===============
*************** amdgcn-*-amdhsa
*** 3201,3229 ****
  AMD GCN GPU target.
  
     Instead of GNU Binutils, you will need to install LLVM 13.0.1, or
! later, and copy 'bin/llvm-mc' to 'amdgcn-amdhsa/bin/as', 'bin/lld' to
! 'amdgcn-amdhsa/bin/ld', 'bin/llvm-nm' to 'amdgcn-amdhsa/bin/nm', and
! 'bin/llvm-ar' to both 'bin/amdgcn-amdhsa-ar' and
! 'bin/amdgcn-amdhsa-ranlib'.
  
     Use Newlib (4.3.0 or newer).
  
     To run the binaries, install the HSA Runtime from the ROCm Platform,
! and use 'libexec/gcc/amdhsa-amdhsa/VERSION/gcn-run' to launch them on
  the GPU.
  
  arc-*-elf32
  ===========
  
! Use 'configure --target=arc-elf32 --with-cpu=CPU
! --enable-languages="c,c++"' to configure GCC, with CPU being one of
! 'arc600', 'arc601', or 'arc700'.
  
  arc-linux-uclibc
  ================
  
! Use 'configure --target=arc-linux-uclibc --with-cpu=arc700
! --enable-languages="c,c++"' to configure GCC.
  
  arm-*-eabi
  ==========
--- 3201,3229 ----
  AMD GCN GPU target.
  
     Instead of GNU Binutils, you will need to install LLVM 13.0.1, or
! later, and copy ‘bin/llvm-mc’ to ‘amdgcn-amdhsa/bin/as’, ‘bin/lld’ to
! ‘amdgcn-amdhsa/bin/ld’, ‘bin/llvm-nm’ to ‘amdgcn-amdhsa/bin/nm’, and
! ‘bin/llvm-ar’ to both ‘bin/amdgcn-amdhsa-ar’ and
! ‘bin/amdgcn-amdhsa-ranlib’.
  
     Use Newlib (4.3.0 or newer).
  
     To run the binaries, install the HSA Runtime from the ROCm Platform,
! and use ‘libexec/gcc/amdhsa-amdhsa/VERSION/gcn-run’ to launch them on
  the GPU.
  
  arc-*-elf32
  ===========
  
! Use ‘configure --target=arc-elf32 --with-cpu=CPU
! --enable-languages="c,c++"’ to configure GCC, with CPU being one of
! ‘arc600’, ‘arc601’, or ‘arc700’.
  
  arc-linux-uclibc
  ================
  
! Use ‘configure --target=arc-linux-uclibc --with-cpu=arc700
! --enable-languages="c,c++"’ to configure GCC.
  
  arm-*-eabi
  ==========
*************** arm-*-eabi
*** 3231,3237 ****
  ARM-family processors.
  
     Building the Ada frontend commonly fails (an infinite loop executing
! 'xsinfo') if the host compiler is GNAT 4.8.  Host compilers built from
  the GNAT 4.6, 4.9 or 5 release branches are known to succeed.
  
  avr
--- 3231,3237 ----
  ARM-family processors.
  
     Building the Ada frontend commonly fails (an infinite loop executing
! ‘xsinfo’) if the host compiler is GNAT 4.8.  Host compilers built from
  the GNAT 4.6, 4.9 or 5 release branches are known to succeed.
  
  avr
*************** ATMEL AVR-family micro controllers.  The
*** 3241,3253 ****
  applications.  There are no standard Unix configurations.  *Note AVR
  Options: (gcc)AVR Options, for the list of supported MCU types.
  
!    Use 'configure --target=avr --enable-languages="c"' to configure GCC.
  
     Further installation notes and other useful information about AVR
  tools can also be obtained from:
  
!    * http://www.nongnu.org/avr/
!    * http://www.amelek.gda.pl/avr/
  
     The following error:
       Error: register required
--- 3241,3253 ----
  applications.  There are no standard Unix configurations.  *Note AVR
  Options: (gcc)AVR Options, for the list of supported MCU types.
  
!    Use ‘configure --target=avr --enable-languages="c"’ to configure GCC.
  
     Further installation notes and other useful information about AVR
  tools can also be obtained from:
  
!    • http://www.nongnu.org/avr/
!    • http://www.amelek.gda.pl/avr/
  
     The following error:
       Error: register required
*************** example the ETRAX series.  These are use
*** 3273,3279 ****
     *Note CRIS Options: (gcc)CRIS Options, for a list of CRIS-specific
  options.
  
!    Use 'configure --target=cris-elf' to configure GCC for building a
  cross-compiler for CRIS.
  
  DOS
--- 3273,3279 ----
     *Note CRIS Options: (gcc)CRIS Options, for a list of CRIS-specific
  options.
  
!    Use ‘configure --target=cris-elf’ to configure GCC for building a
  cross-compiler for CRIS.
  
  DOS
*************** Adapteva Epiphany.  This configuration i
*** 3297,3321 ****
  In order to better utilize FreeBSD base system functionality and match
  the configuration of the system compiler, GCC 4.5 and above as well as
  GCC 4.4 past 2010-06-20 leverage SSP support in libc (which is present
! on FreeBSD 7 or later) and the use of '__cxa_atexit' by default (on
! FreeBSD 6 or later).  The use of 'dl_iterate_phdr' inside
! 'libgcc_s.so.1' and boehm-gc (on FreeBSD 7 or later) is enabled by GCC
  4.5 and above.
  
     We support FreeBSD using the ELF file format with DWARF 2 debugging
  for all CPU architectures.  There are no known issues with mixing object
  files and libraries with different debugging formats.  Otherwise, this
  release of GCC should now match more of the configuration used in the
! stock FreeBSD configuration of GCC.  In particular, '--enable-threads'
  is now configured by default.  However, as a general user, do not
  attempt to replace the system compiler with this release.  Known to
  bootstrap and check with good results on FreeBSD 7.2-STABLE.  In the
  past, known to bootstrap and check with good results on FreeBSD 3.0,
  3.4, 4.0, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9 and 5-CURRENT.
  
!    The version of binutils installed in '/usr/bin' probably works with
  this release of GCC.  Bootstrapping against the latest GNU binutils
! and/or the version found in '/usr/ports/devel/binutils' has been known
  to enable additional features and improve overall testsuite results.
  However, it is currently known that boehm-gc may not configure properly
  on FreeBSD prior to the FreeBSD 7.0 release with GNU binutils after
--- 3297,3321 ----
  In order to better utilize FreeBSD base system functionality and match
  the configuration of the system compiler, GCC 4.5 and above as well as
  GCC 4.4 past 2010-06-20 leverage SSP support in libc (which is present
! on FreeBSD 7 or later) and the use of ‘__cxa_atexit’ by default (on
! FreeBSD 6 or later).  The use of ‘dl_iterate_phdr’ inside
! ‘libgcc_s.so.1’ and boehm-gc (on FreeBSD 7 or later) is enabled by GCC
  4.5 and above.
  
     We support FreeBSD using the ELF file format with DWARF 2 debugging
  for all CPU architectures.  There are no known issues with mixing object
  files and libraries with different debugging formats.  Otherwise, this
  release of GCC should now match more of the configuration used in the
! stock FreeBSD configuration of GCC.  In particular, ‘--enable-threads’
  is now configured by default.  However, as a general user, do not
  attempt to replace the system compiler with this release.  Known to
  bootstrap and check with good results on FreeBSD 7.2-STABLE.  In the
  past, known to bootstrap and check with good results on FreeBSD 3.0,
  3.4, 4.0, 4.2, 4.3, 4.4, 4.5, 4.8, 4.9 and 5-CURRENT.
  
!    The version of binutils installed in ‘/usr/bin’ probably works with
  this release of GCC.  Bootstrapping against the latest GNU binutils
! and/or the version found in ‘/usr/ports/devel/binutils’ has been known
  to enable additional features and improve overall testsuite results.
  However, it is currently known that boehm-gc may not configure properly
  on FreeBSD prior to the FreeBSD 7.0 release with GNU binutils after
*************** Support for HP-UX version 9 and older wa
*** 3347,3364 ****
     We require using gas/binutils on all hppa platforms.  Version 2.19 or
  later is recommended.
  
!    It may be helpful to configure GCC with the '--with-gnu-as' and
! '--with-as=...' options to ensure that GCC can find GAS.
  
     The HP assembler should not be used with GCC. It is rarely tested and
  may not work.  It shouldn't be used with any languages other than C due
  to its many limitations.
  
!    Specifically, '-g' does not work (HP-UX uses a peculiar debugging
  format which GCC does not know about).  It also inserts timestamps into
  each object file it creates, causing the 3-stage comparison test to fail
! during a bootstrap.  You should be able to continue by saying 'make
! all-host all-target' after getting the failure from 'make'.
  
     Various GCC features are not supported.  For example, it does not
  support weak symbols or alias definitions.  As a result, explicit
--- 3347,3364 ----
     We require using gas/binutils on all hppa platforms.  Version 2.19 or
  later is recommended.
  
!    It may be helpful to configure GCC with the ‘--with-gnu-as’ and
! ‘--with-as=...’ options to ensure that GCC can find GAS.
  
     The HP assembler should not be used with GCC. It is rarely tested and
  may not work.  It shouldn't be used with any languages other than C due
  to its many limitations.
  
!    Specifically, ‘-g’ does not work (HP-UX uses a peculiar debugging
  format which GCC does not know about).  It also inserts timestamps into
  each object file it creates, causing the 3-stage comparison test to fail
! during a bootstrap.  You should be able to continue by saying ‘make
! all-host all-target’ after getting the failure from ‘make’.
  
     Various GCC features are not supported.  For example, it does not
  support weak symbols or alias definitions.  As a result, explicit
*************** difficult if not impossible to build man
*** 3369,3375 ****
  PROCESSOR_7100LC and PROCESSOR_8000.  They are selected from the pa-risc
  architecture specified for the target machine when configuring.
  PROCESSOR_8000 is the default.  PROCESSOR_7100LC is selected when the
! target is a 'hppa1*' machine.
  
     The PROCESSOR_8000 model is not well suited to older processors.
  Thus, it is important to completely specify the machine architecture
--- 3369,3375 ----
  PROCESSOR_7100LC and PROCESSOR_8000.  They are selected from the pa-risc
  architecture specified for the target machine when configuring.
  PROCESSOR_8000 is the default.  PROCESSOR_7100LC is selected when the
! target is a ‘hppa1*’ machine.
  
     The PROCESSOR_8000 model is not well suited to older processors.
  Thus, it is important to completely specify the machine architecture
*************** default scheduling model is desired.
*** 3382,3399 ****
  namespace change might cause problems when bootstrapping with an earlier
  version of GCC or the HP compiler as essentially the same namespace is
  required for an entire build.  This problem can be avoided in a number
! of ways.  With HP cc, 'UNIX_STD' can be set to '95' or '98'.  Another
! way is to add an appropriate set of predefines to 'CC'.  The description
! for the 'munix=' option contains a list of the predefines used with each
  standard.
  
!    More specific information to 'hppa*-hp-hpux*' targets follows.
  
  hppa*-hp-hpux10
  ===============
  
  For hpux10.20, we _highly_ recommend you pick up the latest sed patch
! 'PHCO_19798' from HP.
  
     The C++ ABI has changed incompatibly in GCC 4.0.  COMDAT subspaces
  are used for one-only code and data.  This resolves many of the previous
--- 3382,3399 ----
  namespace change might cause problems when bootstrapping with an earlier
  version of GCC or the HP compiler as essentially the same namespace is
  required for an entire build.  This problem can be avoided in a number
! of ways.  With HP cc, ‘UNIX_STD’ can be set to ‘95’ or ‘98’.  Another
! way is to add an appropriate set of predefines to ‘CC’.  The description
! for the ‘munix=’ option contains a list of the predefines used with each
  standard.
  
!    More specific information to ‘hppa*-hp-hpux*’ targets follows.
  
  hppa*-hp-hpux10
  ===============
  
  For hpux10.20, we _highly_ recommend you pick up the latest sed patch
! ‘PHCO_19798’ from HP.
  
     The C++ ABI has changed incompatibly in GCC 4.0.  COMDAT subspaces
  are used for one-only code and data.  This resolves many of the previous
*************** start from a binary distribution.
*** 3432,3462 ****
  
     On 64-bit capable systems, there are two distinct targets.  Different
  installation prefixes must be used if both are to be installed on the
! same system.  The 'hppa[1-2]*-hp-hpux11*' target generates code for the
  32-bit PA-RISC runtime architecture and uses the HP linker.  The
! 'hppa64-hp-hpux11*' target generates 64-bit code for the PA-RISC 2.0
  architecture.
  
     The script config.guess now selects the target type based on the
! compiler detected during configuration.  You must define 'PATH' or 'CC'
  so that configure finds an appropriate compiler for the initial
! bootstrap.  When 'CC' is used, the definition should contain the options
! that are needed whenever 'CC' is used.
  
     Specifically, options that determine the runtime architecture must be
! in 'CC' to correctly select the target for the build.  It is also
! convenient to place many other compiler options in 'CC'.  For example,
! 'CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE"' can be
  used to bootstrap the GCC 3.3 branch with the HP compiler in 64-bit
! K&R/bundled mode.  The '+DA2.0W' option will result in the automatic
! selection of the 'hppa64-hp-hpux11*' target.  The macro definition table
  of cpp needs to be increased for a successful build with the HP
  compiler.  _CLASSIC_TYPES and _HPUX_SOURCE need to be defined when
! building with the bundled compiler, or when using the '-Ac' option.
! These defines aren't necessary with '-Ae'.
  
!    It is best to explicitly configure the 'hppa64-hp-hpux11*' target
! with the '--with-ld=...' option.  This overrides the standard search for
  ld.  The two linkers supported on this target require different
  commands.  The default linker is determined during configuration.  As a
  result, it's not possible to switch linkers in the middle of a GCC
--- 3432,3462 ----
  
     On 64-bit capable systems, there are two distinct targets.  Different
  installation prefixes must be used if both are to be installed on the
! same system.  The ‘hppa[1-2]*-hp-hpux11*’ target generates code for the
  32-bit PA-RISC runtime architecture and uses the HP linker.  The
! ‘hppa64-hp-hpux11*’ target generates 64-bit code for the PA-RISC 2.0
  architecture.
  
     The script config.guess now selects the target type based on the
! compiler detected during configuration.  You must define ‘PATH’ or ‘CC’
  so that configure finds an appropriate compiler for the initial
! bootstrap.  When ‘CC’ is used, the definition should contain the options
! that are needed whenever ‘CC’ is used.
  
     Specifically, options that determine the runtime architecture must be
! in ‘CC’ to correctly select the target for the build.  It is also
! convenient to place many other compiler options in ‘CC’.  For example,
! ‘CC="cc -Ac +DA2.0W -Wp,-H16376 -D_CLASSIC_TYPES -D_HPUX_SOURCE"’ can be
  used to bootstrap the GCC 3.3 branch with the HP compiler in 64-bit
! K&R/bundled mode.  The ‘+DA2.0W’ option will result in the automatic
! selection of the ‘hppa64-hp-hpux11*’ target.  The macro definition table
  of cpp needs to be increased for a successful build with the HP
  compiler.  _CLASSIC_TYPES and _HPUX_SOURCE need to be defined when
! building with the bundled compiler, or when using the ‘-Ac’ option.
! These defines aren't necessary with ‘-Ae’.
  
!    It is best to explicitly configure the ‘hppa64-hp-hpux11*’ target
! with the ‘--with-ld=...’ option.  This overrides the standard search for
  ld.  The two linkers supported on this target require different
  commands.  The default linker is determined during configuration.  As a
  result, it's not possible to switch linkers in the middle of a GCC
*************** build.  This has been reported to someti
*** 3464,3472 ****
  binutils and GCC.
  
     A recent linker patch must be installed for the correct operation of
! GCC 3.3 and later.  'PHSS_26559' and 'PHSS_24304' are the oldest linker
  patches that are known to work.  They are for HP-UX 11.00 and 11.11,
! respectively.  'PHSS_24303', the companion to 'PHSS_24304', might be
  usable but it hasn't been tested.  These patches have been superseded.
  Consult the HP patch database to obtain the currently recommended linker
  patch for your system.
--- 3464,3472 ----
  binutils and GCC.
  
     A recent linker patch must be installed for the correct operation of
! GCC 3.3 and later.  ‘PHSS_26559’ and ‘PHSS_24304’ are the oldest linker
  patches that are known to work.  They are for HP-UX 11.00 and 11.11,
! respectively.  ‘PHSS_24303’, the companion to ‘PHSS_24304’, might be
  usable but it hasn't been tested.  These patches have been superseded.
  Consult the HP patch database to obtain the currently recommended linker
  patch for your system.
*************** issues involving secondary symbols.
*** 3481,3515 ****
  
     GCC 3.3 uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capabilities to
  run initializers and finalizers on the 64-bit port.  The 32-bit port
! uses the linker '+init' and '+fini' options for the same purpose.  The
  patches correct various problems with the +init/+fini options, including
  program core dumps.  Binutils 2.14 corrects a problem on the 64-bit port
  resulting from HP's non-standard use of the .init and .fini sections for
  array initializers and finalizers.
  
     Although the HP and GNU linkers are both supported for the
! 'hppa64-hp-hpux11*' target, it is strongly recommended that the HP
  linker be used for link editing on this target.
  
     At this time, the GNU linker does not support the creation of long
  branch stubs.  As a result, it cannot successfully link binaries
  containing branch offsets larger than 8 megabytes.  In addition, there
  are problems linking shared libraries, linking executables with
! '-static', and with dwarf2 unwind and exception support.  It also
  doesn't provide stubs for internal calls to global functions in shared
  libraries, so these calls cannot be overloaded.
  
     The HP dynamic loader does not support GNU symbol versioning, so
  symbol versioning is not supported.  It may be necessary to disable
! symbol versioning with '--disable-symvers' when using GNU ld.
  
     POSIX threads are the default.  The optional DCE thread library is
! not supported, so '--enable-threads=dce' does not work.
  
  *-*-linux-gnu
  =============
  
! The '.init_array' and '.fini_array' sections are enabled unconditionally
  which requires at least glibc 2.1 and binutils 2.12.
  
     Versions of libstdc++-v3 starting with 3.2.1 require bug fixes
--- 3481,3515 ----
  
     GCC 3.3 uses the ELF DT_INIT_ARRAY and DT_FINI_ARRAY capabilities to
  run initializers and finalizers on the 64-bit port.  The 32-bit port
! uses the linker ‘+init’ and ‘+fini’ options for the same purpose.  The
  patches correct various problems with the +init/+fini options, including
  program core dumps.  Binutils 2.14 corrects a problem on the 64-bit port
  resulting from HP's non-standard use of the .init and .fini sections for
  array initializers and finalizers.
  
     Although the HP and GNU linkers are both supported for the
! ‘hppa64-hp-hpux11*’ target, it is strongly recommended that the HP
  linker be used for link editing on this target.
  
     At this time, the GNU linker does not support the creation of long
  branch stubs.  As a result, it cannot successfully link binaries
  containing branch offsets larger than 8 megabytes.  In addition, there
  are problems linking shared libraries, linking executables with
! ‘-static’, and with dwarf2 unwind and exception support.  It also
  doesn't provide stubs for internal calls to global functions in shared
  libraries, so these calls cannot be overloaded.
  
     The HP dynamic loader does not support GNU symbol versioning, so
  symbol versioning is not supported.  It may be necessary to disable
! symbol versioning with ‘--disable-symvers’ when using GNU ld.
  
     POSIX threads are the default.  The optional DCE thread library is
! not supported, so ‘--enable-threads=dce’ does not work.
  
  *-*-linux-gnu
  =============
  
! The ‘.init_array’ and ‘.fini_array’ sections are enabled unconditionally
  which requires at least glibc 2.1 and binutils 2.12.
  
     Versions of libstdc++-v3 starting with 3.2.1 require bug fixes
*************** i?86-*-solaris2*
*** 3530,3538 ****
  ================
  
  Use this for Solaris 11.3 or later on x86 and x86-64 systems.  Starting
! with GCC 4.7, there is also a 64-bit 'amd64-*-solaris2*' or
! 'x86_64-*-solaris2*' configuration that corresponds to
! 'sparcv9-sun-solaris2*'.
  
  ia64-*-linux
  ============
--- 3530,3538 ----
  ================
  
  Use this for Solaris 11.3 or later on x86 and x86-64 systems.  Starting
! with GCC 4.7, there is also a 64-bit ‘amd64-*-solaris2*’ or
! ‘x86_64-*-solaris2*’ configuration that corresponds to
! ‘sparcv9-sun-solaris2*’.
  
  ia64-*-linux
  ============
*************** IA-64 processor (also known as IPF, or I
*** 3541,3559 ****
  GNU/Linux.
  
     If you are using the installed system libunwind library with
! '--with-system-libunwind', then you must use libunwind 0.98 or later.
  
  ia64-*-hpux*
  ============
  
  Building GCC on this target requires the GNU Assembler.  The bundled HP
  assembler will not work.  To prevent GCC from using the wrong assembler,
! the option '--with-gnu-as' may be necessary.
  
     The GCC libunwind library has not been ported to HPUX.  This means
! that for GCC versions 3.2.3 and earlier, '--enable-libunwind-exceptions'
  is required to build GCC.  For GCC 3.3 and later, this is the default.
! For gcc 3.4.3 and later, '--enable-libunwind-exceptions' is removed and
  the system libunwind library will always be used.
  
  *-ibm-aix*
--- 3541,3559 ----
  GNU/Linux.
  
     If you are using the installed system libunwind library with
! ‘--with-system-libunwind’, then you must use libunwind 0.98 or later.
  
  ia64-*-hpux*
  ============
  
  Building GCC on this target requires the GNU Assembler.  The bundled HP
  assembler will not work.  To prevent GCC from using the wrong assembler,
! the option ‘--with-gnu-as’ may be necessary.
  
     The GCC libunwind library has not been ported to HPUX.  This means
! that for GCC versions 3.2.3 and earlier, ‘--enable-libunwind-exceptions’
  is required to build GCC.  For GCC 3.3 and later, this is the default.
! For gcc 3.4.3 and later, ‘--enable-libunwind-exceptions’ is removed and
  the system libunwind library will always be used.
  
  *-ibm-aix*
*************** Support for AIX version 4.2 and older wa
*** 3564,3570 ****
  
     "out of memory" bootstrap failures may indicate a problem with
  process resource limits (ulimit).  Hard limits are configured in the
! '/etc/security/limits' system configuration file.
  
     GCC 4.9 and above require a C++ compiler for bootstrap.  IBM VAC++ /
  xlC cannot bootstrap GCC. xlc can bootstrap an older version of GCC and
--- 3564,3570 ----
  
     "out of memory" bootstrap failures may indicate a problem with
  process resource limits (ulimit).  Hard limits are configured in the
! ‘/etc/security/limits’ system configuration file.
  
     GCC 4.9 and above require a C++ compiler for bootstrap.  IBM VAC++ /
  xlC cannot bootstrap GCC. xlc can bootstrap an older version of GCC and
*************** sources.  One may delete GCC's "fixed" h
*** 3583,3589 ****
  version of GCC built for an earlier release of AIX.
  
     To speed up the configuration phases of bootstrapping and installing
! GCC, one may use GNU Bash instead of AIX '/bin/sh', e.g.,
  
       % CONFIG_SHELL=/opt/freeware/bin/bash
       % export CONFIG_SHELL
--- 3583,3589 ----
  version of GCC built for an earlier release of AIX.
  
     To speed up the configuration phases of bootstrapping and installing
! GCC, one may use GNU Bash instead of AIX ‘/bin/sh’, e.g.,
  
       % CONFIG_SHELL=/opt/freeware/bin/bash
       % export CONFIG_SHELL
*************** SRCDIR/configure.
*** 3597,3613 ****
  required by gfortran must be 32-bit libraries.  Building GMP and MPFR as
  static archive libraries works better than shared libraries.
  
!    Errors involving 'alloca' when building GCC generally are due to an
! incorrect definition of 'CC' in the Makefile or mixing files compiled
  with the native C compiler and GCC.  During the stage1 phase of the
! build, the native AIX compiler *must* be invoked as 'cc' (not 'xlc').
! Once 'configure' has been informed of 'xlc', one needs to use 'make
! distclean' to remove the configure cache files and ensure that 'CC'
  environment variable does not provide a definition that will confuse
! 'configure'.  If this error occurs during stage2 or later, then the
  problem most likely is the version of Make (see above).
  
!    The native 'as' and 'ld' are recommended for bootstrapping on AIX.
  The GNU Assembler, GNU Linker, and GNU Binutils version 2.20 is the
  minimum level that supports bootstrap on AIX 5.  The GNU Assembler has
  not been updated to support AIX 6 or AIX 7.  The native AIX tools do
--- 3597,3613 ----
  required by gfortran must be 32-bit libraries.  Building GMP and MPFR as
  static archive libraries works better than shared libraries.
  
!    Errors involving ‘alloca’ when building GCC generally are due to an
! incorrect definition of ‘CC’ in the Makefile or mixing files compiled
  with the native C compiler and GCC.  During the stage1 phase of the
! build, the native AIX compiler *must* be invoked as ‘cc’ (not ‘xlc’).
! Once ‘configure’ has been informed of ‘xlc’, one needs to use ‘make
! distclean’ to remove the configure cache files and ensure that ‘CC’
  environment variable does not provide a definition that will confuse
! ‘configure’.  If this error occurs during stage2 or later, then the
  problem most likely is the version of Make (see above).
  
!    The native ‘as’ and ‘ld’ are recommended for bootstrapping on AIX.
  The GNU Assembler, GNU Linker, and GNU Binutils version 2.20 is the
  minimum level that supports bootstrap on AIX 5.  The GNU Assembler has
  not been updated to support AIX 6 or AIX 7.  The native AIX tools do
*************** AIX 5.3 TL11 and IZ98134 for AIX 5.3 TL1
*** 3628,3662 ****
  TL12 SP5, AIX 6.1 TL04 SP11, AIX 6.1 TL05 SP7, AIX 6.1 TL06 SP6, AIX 6.1
  TL07 and AIX 7.1 TL01 should include the fix.
  
!    Building 'libstdc++.a' requires a fix for an AIX Assembler bug APAR
  IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1).  It also requires a fix for
  another AIX Assembler bug and a co-dependent AIX Archiver fix referenced
  as APAR IY53606 (AIX 5.2) or as APAR IY54774 (AIX 5.1)
  
!    'libstdc++' in GCC 3.4 increments the major version number of the
! shared object and GCC installation places the 'libstdc++.a' shared
  library in a common location which will overwrite the and GCC 3.3
  version of the shared library.  Applications either need to be re-linked
  against the new shared library or the GCC 3.1 and GCC 3.3 versions of
! the 'libstdc++' shared object needs to be available to the AIX runtime
! loader.  The GCC 3.1 'libstdc++.so.4', if present, and GCC 3.3
! 'libstdc++.so.5' shared objects can be installed for runtime dynamic
! loading using the following steps to set the 'F_LOADONLY' flag in the
! shared object for _each_ multilib 'libstdc++.a' installed:
  
!    Extract the shared objects from the currently installed 'libstdc++.a'
  archive:
       % ar -x libstdc++.a libstdc++.so.4 libstdc++.so.5
  
!    Enable the 'F_LOADONLY' flag so that the shared object will be
  available for runtime dynamic loading, but not linking:
       % strip -e libstdc++.so.4 libstdc++.so.5
  
!    Archive the runtime-only shared object in the GCC 3.4 'libstdc++.a'
  archive:
       % ar -q libstdc++.a libstdc++.so.4 libstdc++.so.5
  
!    Eventually, the '--with-aix-soname=svr4' configure option may drop
  the need for this procedure for libraries that support it.
  
     Linking executables and shared libraries may produce warnings of
--- 3628,3662 ----
  TL12 SP5, AIX 6.1 TL04 SP11, AIX 6.1 TL05 SP7, AIX 6.1 TL06 SP6, AIX 6.1
  TL07 and AIX 7.1 TL01 should include the fix.
  
!    Building ‘libstdc++.a’ requires a fix for an AIX Assembler bug APAR
  IY26685 (AIX 4.3) or APAR IY25528 (AIX 5.1).  It also requires a fix for
  another AIX Assembler bug and a co-dependent AIX Archiver fix referenced
  as APAR IY53606 (AIX 5.2) or as APAR IY54774 (AIX 5.1)
  
!    ‘libstdc++’ in GCC 3.4 increments the major version number of the
! shared object and GCC installation places the ‘libstdc++.a’ shared
  library in a common location which will overwrite the and GCC 3.3
  version of the shared library.  Applications either need to be re-linked
  against the new shared library or the GCC 3.1 and GCC 3.3 versions of
! the ‘libstdc++’ shared object needs to be available to the AIX runtime
! loader.  The GCC 3.1 ‘libstdc++.so.4’, if present, and GCC 3.3
! ‘libstdc++.so.5’ shared objects can be installed for runtime dynamic
! loading using the following steps to set the ‘F_LOADONLY’ flag in the
! shared object for _each_ multilib ‘libstdc++.a’ installed:
  
!    Extract the shared objects from the currently installed ‘libstdc++.a’
  archive:
       % ar -x libstdc++.a libstdc++.so.4 libstdc++.so.5
  
!    Enable the ‘F_LOADONLY’ flag so that the shared object will be
  available for runtime dynamic loading, but not linking:
       % strip -e libstdc++.so.4 libstdc++.so.5
  
!    Archive the runtime-only shared object in the GCC 3.4 ‘libstdc++.a’
  archive:
       % ar -q libstdc++.a libstdc++.so.4 libstdc++.so.5
  
!    Eventually, the ‘--with-aix-soname=svr4’ configure option may drop
  the need for this procedure for libraries that support it.
  
     Linking executables and shared libraries may produce warnings of
*************** executable.
*** 3671,3683 ****
  to parse archive libraries did not handle the new format correctly.
  These routines are used by GCC and result in error messages during
  linking such as "not a COFF file".  The version of the routines shipped
! with AIX 4.3.1 should work for a 32-bit environment.  The '-g' option of
  the archive command may be used to create archives of 32-bit objects
  using the original "small format".  A correct version of the routines is
  shipped with AIX 4.3.2 and above.
  
     Some versions of the AIX binder (linker) can fail with a relocation
! overflow severe error when the '-bbigtoc' option is used to link
  GCC-produced object files into an executable that overflows the TOC.  A
  fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC)
  is available from IBM Customer Support and from its
--- 3671,3683 ----
  to parse archive libraries did not handle the new format correctly.
  These routines are used by GCC and result in error messages during
  linking such as "not a COFF file".  The version of the routines shipped
! with AIX 4.3.1 should work for a 32-bit environment.  The ‘-g’ option of
  the archive command may be used to create archives of 32-bit objects
  using the original "small format".  A correct version of the routines is
  shipped with AIX 4.3.2 and above.
  
     Some versions of the AIX binder (linker) can fail with a relocation
! overflow severe error when the ‘-bbigtoc’ option is used to link
  GCC-produced object files into an executable that overflows the TOC.  A
  fix for APAR IX75823 (OVERFLOW DURING LINK WHEN USING GCC AND -BBIGTOC)
  is available from IBM Customer Support and from its
*************** fix is incorporated in AIX 4.3.1 and abo
*** 3697,3710 ****
  
     AIX provides National Language Support (NLS).  Compilers and
  assemblers use NLS to support locale-specific representations of various
! data formats including floating-point numbers (e.g., '.' vs ',' for
  separating decimal fractions).  There have been problems reported where
  GCC does not produce the same floating-point formats that the assembler
! expects.  If one encounters this problem, set the 'LANG' environment
! variable to 'C' or 'En_US'.
  
!    A default can be specified with the '-mcpu=CPU_TYPE' switch and using
! the configure option '--with-cpu-CPU_TYPE'.
  
  iq2000-*-elf
  ============
--- 3697,3710 ----
  
     AIX provides National Language Support (NLS).  Compilers and
  assemblers use NLS to support locale-specific representations of various
! data formats including floating-point numbers (e.g., ‘.’ vs ‘,’ for
  separating decimal fractions).  There have been problems reported where
  GCC does not produce the same floating-point formats that the assembler
! expects.  If one encounters this problem, set the ‘LANG’ environment
! variable to ‘C’ or ‘En_US’.
  
!    A default can be specified with the ‘-mcpu=CPU_TYPE’ switch and using
! the configure option ‘--with-cpu-CPU_TYPE’.
  
  iq2000-*-elf
  ============
*************** LoongArch
*** 3728,3747 ****
  =========
  
  LoongArch processor.  The following LoongArch targets are available:
! 'loongarch64-linux-gnu*'
       LoongArch processor running GNU/Linux.  This target triplet may be
       coupled with a small set of possible suffixes to identify their
       default ABI type:
!      'f64'
!           Uses 'lp64d/base' ABI by default.
!      'f32'
!           Uses 'lp64f/base' ABI by default.
!      'sf'
!           Uses 'lp64s/base' ABI by default.
  
! 'loongarch64-linux-gnu'
!      Same as 'loongarch64-linux-gnuf64', but may be used with
!      '--with-abi=*' to configure the default ABI type.
  
     More information about LoongArch can be found at
  .
--- 3728,3747 ----
  =========
  
  LoongArch processor.  The following LoongArch targets are available:
! ‘loongarch64-linux-gnu*’
       LoongArch processor running GNU/Linux.  This target triplet may be
       coupled with a small set of possible suffixes to identify their
       default ABI type:
!      ‘f64’
!           Uses ‘lp64d/base’ ABI by default.
!      ‘f32’
!           Uses ‘lp64f/base’ ABI by default.
!      ‘sf’
!           Uses ‘lp64s/base’ ABI by default.
  
! ‘loongarch64-linux-gnu’
!      Same as ‘loongarch64-linux-gnuf64’, but may be used with
!      ‘--with-abi=*’ to configure the default ABI type.
  
     More information about LoongArch can be found at
  .
*************** systems.
*** 3761,3782 ****
  m68k-*-*
  ========
  
! By default, 'm68k-*-elf*', 'm68k-*-rtems', 'm68k-*-uclinux' and
! 'm68k-*-linux' build libraries for both M680x0 and ColdFire processors.
  If you only need the M680x0 libraries, you can omit the ColdFire ones by
! passing '--with-arch=m68k' to 'configure'.  Alternatively, you can omit
! the M680x0 libraries by passing '--with-arch=cf' to 'configure'.  These
  targets default to 5206 or 5475 code as appropriate for the target
! system when configured with '--with-arch=cf' and 68020 code otherwise.
  
!    The 'm68k-*-netbsd' and 'm68k-*-openbsd' targets also support the
! '--with-arch' option.  They will generate ColdFire CFV4e code when
! configured with '--with-arch=cf' and 68020 code otherwise.
  
     You can override the default processors listed above by configuring
! with '--with-cpu=TARGET'.  This TARGET can either be a '-mcpu' argument
! or one of the following values: 'm68000', 'm68010', 'm68020', 'm68030',
! 'm68040', 'm68060', 'm68020-40' and 'm68020-60'.
  
     GCC requires at least binutils version 2.17 on these targets.
  
--- 3761,3782 ----
  m68k-*-*
  ========
  
! By default, ‘m68k-*-elf*’, ‘m68k-*-rtems’, ‘m68k-*-uclinux’ and
! ‘m68k-*-linux’ build libraries for both M680x0 and ColdFire processors.
  If you only need the M680x0 libraries, you can omit the ColdFire ones by
! passing ‘--with-arch=m68k’ to ‘configure’.  Alternatively, you can omit
! the M680x0 libraries by passing ‘--with-arch=cf’ to ‘configure’.  These
  targets default to 5206 or 5475 code as appropriate for the target
! system when configured with ‘--with-arch=cf’ and 68020 code otherwise.
  
!    The ‘m68k-*-netbsd’ and ‘m68k-*-openbsd’ targets also support the
! ‘--with-arch’ option.  They will generate ColdFire CFV4e code when
! configured with ‘--with-arch=cf’ and 68020 code otherwise.
  
     You can override the default processors listed above by configuring
! with ‘--with-cpu=TARGET’.  This TARGET can either be a ‘-mcpu’ argument
! or one of the following values: ‘m68000’, ‘m68010’, ‘m68020’, ‘m68030’,
! ‘m68040’, ‘m68060’, ‘m68020-40’ and ‘m68020-60’.
  
     GCC requires at least binutils version 2.17 on these targets.
  
*************** m68k-*-uclinux
*** 3784,3790 ****
  ==============
  
  GCC 4.3 changed the uClinux configuration so that it uses the
! 'm68k-linux-gnu' ABI rather than the 'm68k-elf' ABI. It also added
  improved support for C++ and flat shared libraries, both of which were
  ABI changes.
  
--- 3784,3790 ----
  ==============
  
  GCC 4.3 changed the uClinux configuration so that it uses the
! ‘m68k-linux-gnu’ ABI rather than the ‘m68k-elf’ ABI. It also added
  improved support for C++ and flat shared libraries, both of which were
  ABI changes.
  
*************** optional, and there should not be a warn
*** 3808,3834 ****
  
     The libstdc++ atomic locking routines for MIPS targets requires MIPS
  II and later.  A patch went in just after the GCC 3.3 release to make
! 'mips*-*-*' use the generic implementation instead.  You can also
! configure for 'mipsel-elf' as a workaround.  The 'mips*-*-linux*' target
  continues to use the MIPS II routines.  More work on this is expected in
  future releases.
  
!    The built-in '__sync_*' functions are available on MIPS II and later
! systems and others that support the 'll', 'sc' and 'sync' instructions.
! This can be overridden by passing '--with-llsc' or '--without-llsc' when
  configuring GCC. Since the Linux kernel emulates these instructions if
! they are missing, the default for 'mips*-*-linux*' targets is
! '--with-llsc'.  The '--with-llsc' and '--without-llsc' configure options
! may be overridden at compile time by passing the '-mllsc' or '-mno-llsc'
  options to the compiler.
  
     MIPS systems check for division by zero (unless
! '-mno-check-zero-division' is passed to the compiler) by generating
  either a conditional trap or a break instruction.  Using trap results in
  smaller code, but is only supported on MIPS II and later.  Also, some
  versions of the Linux kernel have a bug that prevents trap from
! generating the proper signal ('SIGFPE').  To enable the use of break,
! use the '--with-divide=breaks' 'configure' option when configuring GCC.
  The default is to use traps on systems that support them.
  
  moxie-*-elf
--- 3808,3834 ----
  
     The libstdc++ atomic locking routines for MIPS targets requires MIPS
  II and later.  A patch went in just after the GCC 3.3 release to make
! ‘mips*-*-*’ use the generic implementation instead.  You can also
! configure for ‘mipsel-elf’ as a workaround.  The ‘mips*-*-linux*’ target
  continues to use the MIPS II routines.  More work on this is expected in
  future releases.
  
!    The built-in ‘__sync_*’ functions are available on MIPS II and later
! systems and others that support the ‘ll’, ‘sc’ and ‘sync’ instructions.
! This can be overridden by passing ‘--with-llsc’ or ‘--without-llsc’ when
  configuring GCC. Since the Linux kernel emulates these instructions if
! they are missing, the default for ‘mips*-*-linux*’ targets is
! ‘--with-llsc’.  The ‘--with-llsc’ and ‘--without-llsc’ configure options
! may be overridden at compile time by passing the ‘-mllsc’ or ‘-mno-llsc’
  options to the compiler.
  
     MIPS systems check for division by zero (unless
! ‘-mno-check-zero-division’ is passed to the compiler) by generating
  either a conditional trap or a break instruction.  Using trap results in
  smaller code, but is only supported on MIPS II and later.  Also, some
  versions of the Linux kernel have a bug that prevents trap from
! generating the proper signal (‘SIGFPE’).  To enable the use of break,
! use the ‘--with-divide=breaks’ ‘configure’ option when configuring GCC.
  The default is to use traps on systems that support them.
  
  moxie-*-elf
*************** msp430-*-elf*
*** 3842,3858 ****
  TI MSP430 processor.  This configuration is intended for embedded
  systems.
  
!    'msp430-*-elf' is the standard configuration with most GCC features
  enabled by default.
  
!    'msp430-*-elfbare' is tuned for a bare-metal environment, and
  disables features related to shared libraries and other functionality
  not used for this device.  This reduces code and data usage of the GCC
  libraries, resulting in a minimal run-time environment by default.
  
     Features disabled by default include:
!    * transactional memory
!    * __cxa_atexit
  
  nds32le-*-elf
  =============
--- 3842,3858 ----
  TI MSP430 processor.  This configuration is intended for embedded
  systems.
  
!    ‘msp430-*-elf’ is the standard configuration with most GCC features
  enabled by default.
  
!    ‘msp430-*-elfbare’ is tuned for a bare-metal environment, and
  disables features related to shared libraries and other functionality
  not used for this device.  This reduces code and data usage of the GCC
  libraries, resulting in a minimal run-time environment by default.
  
     Features disabled by default include:
!    • transactional memory
!    • __cxa_atexit
  
  nds32le-*-elf
  =============
*************** Nvidia PTX target.
*** 3871,3892 ****
  
     Instead of GNU binutils, you will need to install nvptx-tools.  Tell
  GCC where to find it:
! '--with-build-time-tools=[install-nvptx-tools]/nvptx-none/bin'.
  
     You will need newlib 4.3.0 or later.  It can be automatically built
  together with GCC.  For this, add a symbolic link to nvptx-newlib's
! 'newlib' directory to the directory containing the GCC sources.
  
!    Use the '--disable-sjlj-exceptions' and
! '--enable-newlib-io-long-long' options when configuring.
  
!    The '--with-arch' option may be specified to override the default
! value for the '-march' option, and to also build corresponding target
! libraries.  The default is '--with-arch=sm_30'.
  
!    For example, if '--with-arch=sm_70' is specified, '-march=sm_30' and
! '-march=sm_70' target libraries are built, and code generation defaults
! to '-march=sm_70'.
  
  or1k-*-elf
  ==========
--- 3871,3892 ----
  
     Instead of GNU binutils, you will need to install nvptx-tools.  Tell
  GCC where to find it:
! ‘--with-build-time-tools=[install-nvptx-tools]/nvptx-none/bin’.
  
     You will need newlib 4.3.0 or later.  It can be automatically built
  together with GCC.  For this, add a symbolic link to nvptx-newlib's
! ‘newlib’ directory to the directory containing the GCC sources.
  
!    Use the ‘--disable-sjlj-exceptions’ and
! ‘--enable-newlib-io-long-long’ options when configuring.
  
!    The ‘--with-arch’ option may be specified to override the default
! value for the ‘-march’ option, and to also build corresponding target
! libraries.  The default is ‘--with-arch=sm_30’.
  
!    For example, if ‘--with-arch=sm_70’ is specified, ‘-march=sm_30’ and
! ‘-march=sm_70’ target libraries are built, and code generation defaults
! to ‘-march=sm_70’.
  
  or1k-*-elf
  ==========
*************** The OpenRISC 1000 32-bit processor with
*** 3902,3909 ****
  powerpc-*-*
  ===========
  
! You can specify a default version for the '-mcpu=CPU_TYPE' switch by
! using the configure option '--with-cpu-CPU_TYPE'.
  
     You will need GNU binutils 2.20 or newer.
  
--- 3902,3909 ----
  powerpc-*-*
  ===========
  
! You can specify a default version for the ‘-mcpu=CPU_TYPE’ switch by
! using the configure option ‘--with-cpu-CPU_TYPE’.
  
     You will need GNU binutils 2.20 or newer.
  
*************** cross-compilation target only.
*** 4020,4086 ****
  =============
  
  Support for Solaris 11.3 and earlier has been obsoleted in GCC 13, but
! can still be enabled by configuring with '--enable-obsolete'.  Support
  for Solaris 10 has been removed in GCC 10.  Support for Solaris 9 has
  been removed in GCC 5.  Support for Solaris 8 has been removed in GCC
  4.8.  Support for Solaris 7 has been removed in GCC 4.6.
  
     Solaris 11.3 provides GCC 4.5.2, 4.7.3, and 4.8.2 as
! '/usr/gcc/4.5/bin/gcc' or similar.  Solaris 11.4 provides one or more of
  GCC 5, 7, 9, 10, 11, and 12.
  
!    You need to install the 'system/header', 'system/linker', and
! 'developer/assembler' packages.
  
!    Trying to use the compatibility tools in '/usr/ucb', from the
! 'compatibility/ucb' package, to install GCC has been observed to cause
! trouble.  The fix is to remove '/usr/ucb' from your 'PATH'.
  
     The build process works more smoothly with the legacy Solaris tools
! so, if you have '/usr/xpg4/bin' in your 'PATH', we recommend that you
! place '/usr/bin' before '/usr/xpg4/bin' for the duration of the build.
  
     We recommend the use of the Solaris assembler or the GNU assembler,
  in conjunction with the Solaris linker.
  
!    The GNU 'as' versions included in Solaris 11.3, from GNU binutils
! 2.23.1 or newer (in '/usr/bin/gas' and '/usr/gnu/bin/as'), are known to
  work.  The version from GNU binutils 2.40 is known to work as well.
! Recent versions of the Solaris assembler in '/usr/bin/as' work almost as
! well, though.  To use GNU 'as', configure with the options
! '--with-gnu-as --with-as=/usr/gnu/bin/as'.
  
     For linking, the Solaris linker is preferred.  If you want to use the
  GNU linker instead, the version in Solaris 11.3, from GNU binutils
! 2.23.1 or newer (in '/usr/gnu/bin/ld' and '/usr/bin/gld'), works, as
  does the version from GNU binutils 2.40.  However, it generally lacks
! platform specific features, so better stay with Solaris 'ld'.  To use
! the LTO linker plugin ('-fuse-linker-plugin') with GNU 'ld', GNU
! binutils _must_ be configured with '--enable-largefile'.  To use Solaris
! 'ld', we recommend to configure with '--without-gnu-ld
! --with-ld=/usr/bin/ld' to guarantee the right linker is found
! irrespective of the user's 'PATH'.
  
     Note that your mileage may vary if you use a combination of the GNU
! tools and the Solaris tools: while the combination GNU 'as' and Solaris
! 'ld' works well, the reverse combination Solaris 'as' with GNU 'ld' may
  fail to build or cause memory corruption at runtime in some cases for
  C++ programs.
  
!    To enable symbol versioning in 'libstdc++' and other runtime
  libraries with the Solaris linker, you need to have any version of GNU
! 'c++filt', which is part of GNU binutils.  Symbol versioning will be
! disabled if no appropriate version is found.  Solaris 'c++filt' from the
  Solaris Studio compilers does _not_ work.
  
     In order to build the GNU Ada compiler, GNAT, a working GNAT is
  needed.  Since Solaris 11.4 SRU 39, GNAT 11 or 12 is bundled in the
! 'developer/gcc/gcc-gnat' package.
  
!    In order to build the GNU D compiler, GDC, a working 'libphobos' is
  needed.  That library wasn't built by default in GCC 9-11 on SPARC, or
  on x86 when the Solaris assembler is used, but can be enabled by
! configuring with '--enable-libphobos'.  Also, GDC 9.4.0 is required on
  x86, while GDC 9.3.0 is known to work on SPARC.
  
     The versions of the GNU Multiple Precision Library (GMP), the MPFR
--- 4020,4086 ----
  =============
  
  Support for Solaris 11.3 and earlier has been obsoleted in GCC 13, but
! can still be enabled by configuring with ‘--enable-obsolete’.  Support
  for Solaris 10 has been removed in GCC 10.  Support for Solaris 9 has
  been removed in GCC 5.  Support for Solaris 8 has been removed in GCC
  4.8.  Support for Solaris 7 has been removed in GCC 4.6.
  
     Solaris 11.3 provides GCC 4.5.2, 4.7.3, and 4.8.2 as
! ‘/usr/gcc/4.5/bin/gcc’ or similar.  Solaris 11.4 provides one or more of
  GCC 5, 7, 9, 10, 11, and 12.
  
!    You need to install the ‘system/header’, ‘system/linker’, and
! ‘developer/assembler’ packages.
  
!    Trying to use the compatibility tools in ‘/usr/ucb’, from the
! ‘compatibility/ucb’ package, to install GCC has been observed to cause
! trouble.  The fix is to remove ‘/usr/ucb’ from your ‘PATH’.
  
     The build process works more smoothly with the legacy Solaris tools
! so, if you have ‘/usr/xpg4/bin’ in your ‘PATH’, we recommend that you
! place ‘/usr/bin’ before ‘/usr/xpg4/bin’ for the duration of the build.
  
     We recommend the use of the Solaris assembler or the GNU assembler,
  in conjunction with the Solaris linker.
  
!    The GNU ‘as’ versions included in Solaris 11.3, from GNU binutils
! 2.23.1 or newer (in ‘/usr/bin/gas’ and ‘/usr/gnu/bin/as’), are known to
  work.  The version from GNU binutils 2.40 is known to work as well.
! Recent versions of the Solaris assembler in ‘/usr/bin/as’ work almost as
! well, though.  To use GNU ‘as’, configure with the options
! ‘--with-gnu-as --with-as=/usr/gnu/bin/as’.
  
     For linking, the Solaris linker is preferred.  If you want to use the
  GNU linker instead, the version in Solaris 11.3, from GNU binutils
! 2.23.1 or newer (in ‘/usr/gnu/bin/ld’ and ‘/usr/bin/gld’), works, as
  does the version from GNU binutils 2.40.  However, it generally lacks
! platform specific features, so better stay with Solaris ‘ld’.  To use
! the LTO linker plugin (‘-fuse-linker-plugin’) with GNU ‘ld’, GNU
! binutils _must_ be configured with ‘--enable-largefile’.  To use Solaris
! ‘ld’, we recommend to configure with ‘--without-gnu-ld
! --with-ld=/usr/bin/ld’ to guarantee the right linker is found
! irrespective of the user's ‘PATH’.
  
     Note that your mileage may vary if you use a combination of the GNU
! tools and the Solaris tools: while the combination GNU ‘as’ and Solaris
! ‘ld’ works well, the reverse combination Solaris ‘as’ with GNU ‘ld’ may
  fail to build or cause memory corruption at runtime in some cases for
  C++ programs.
  
!    To enable symbol versioning in ‘libstdc++’ and other runtime
  libraries with the Solaris linker, you need to have any version of GNU
! ‘c++filt’, which is part of GNU binutils.  Symbol versioning will be
! disabled if no appropriate version is found.  Solaris ‘c++filt’ from the
  Solaris Studio compilers does _not_ work.
  
     In order to build the GNU Ada compiler, GNAT, a working GNAT is
  needed.  Since Solaris 11.4 SRU 39, GNAT 11 or 12 is bundled in the
! ‘developer/gcc/gcc-gnat’ package.
  
!    In order to build the GNU D compiler, GDC, a working ‘libphobos’ is
  needed.  That library wasn't built by default in GCC 9-11 on SPARC, or
  on x86 when the Solaris assembler is used, but can be enabled by
! configuring with ‘--enable-libphobos’.  Also, GDC 9.4.0 is required on
  x86, while GDC 9.3.0 is known to work on SPARC.
  
     The versions of the GNU Multiple Precision Library (GMP), the MPFR
*************** library and the MPC library bundled with
*** 4088,4098 ****
  usually recent enough to match GCC's requirements.  There are two
  caveats:
  
!    * While the version of the GMP library in Solaris 11.3 works with
       GCC, you need to configure with
!      '--with-gmp-include=/usr/include/gmp'.
  
!    * The version of the MPFR libary included in Solaris 11.3 is too old;
       you need to provide a more recent one.
  
  sparc*-*-*
--- 4088,4098 ----
  usually recent enough to match GCC's requirements.  There are two
  caveats:
  
!    • While the version of the GMP library in Solaris 11.3 works with
       GCC, you need to configure with
!      ‘--with-gmp-include=/usr/include/gmp’.
  
!    • The version of the MPFR libary included in Solaris 11.3 is too old;
       you need to provide a more recent one.
  
  sparc*-*-*
*************** information.
*** 4118,4129 ****
  
     Starting with Solaris 7, the operating system is capable of executing
  64-bit SPARC V9 binaries.  GCC 3.1 and later properly supports this; the
! '-m64' option enables 64-bit code generation.
  
     When configuring the GNU Multiple Precision Library (GMP), the MPFR
  library or the MPC library on Solaris, the canonical target triplet must
! be specified as the 'build' parameter on the 'configure' line.  This
! target triplet can be obtained by invoking './config.guess' in the
  toplevel source directory of GCC (and not that of GMP or MPFR or MPC).
  For example:
  
--- 4118,4129 ----
  
     Starting with Solaris 7, the operating system is capable of executing
  64-bit SPARC V9 binaries.  GCC 3.1 and later properly supports this; the
! ‘-m64’ option enables 64-bit code generation.
  
     When configuring the GNU Multiple Precision Library (GMP), the MPFR
  library or the MPC library on Solaris, the canonical target triplet must
! be specified as the ‘build’ parameter on the ‘configure’ line.  This
! target triplet can be obtained by invoking ‘./config.guess’ in the
  toplevel source directory of GCC (and not that of GMP or MPFR or MPC).
  For example:
  
*************** sparc-*-linux*
*** 4135,4155 ****
  sparc64-*-solaris2*
  ===================
  
! This is a synonym for 'sparcv9-*-solaris2*'.
  
  sparcv9-*-solaris2*
  ===================
  
  When configuring a 64-bit-default GCC on Solaris/SPARC, you must use a
  build compiler that generates 64-bit code, either by default or by
! specifying 'CC='gcc -m64' CXX='g++ -m64' GDC='gdc -m64'' to 'configure'.
! Additionally, you _must_ pass '--build=sparcv9-sun-solaris2.11' or
! '--build=sparc64-sun-solaris2.11' because 'config.guess' misdetects this
  situation, which can cause build failures.
  
     When configuring the GNU Multiple Precision Library (GMP), the MPFR
  library or the MPC library, the canonical target triplet must be
! specified as the 'build' parameter on the 'configure' line.  For
  example:
  
       % SRCDIR/configure --build=sparcv9-sun-solaris2.11 --prefix=DIRNAME
--- 4135,4155 ----
  sparc64-*-solaris2*
  ===================
  
! This is a synonym for ‘sparcv9-*-solaris2*’.
  
  sparcv9-*-solaris2*
  ===================
  
  When configuring a 64-bit-default GCC on Solaris/SPARC, you must use a
  build compiler that generates 64-bit code, either by default or by
! specifying ‘CC='gcc -m64' CXX='g++ -m64' GDC='gdc -m64'’ to ‘configure’.
! Additionally, you _must_ pass ‘--build=sparcv9-sun-solaris2.11’ or
! ‘--build=sparc64-sun-solaris2.11’ because ‘config.guess’ misdetects this
  situation, which can cause build failures.
  
     When configuring the GNU Multiple Precision Library (GMP), the MPFR
  library or the MPC library, the canonical target triplet must be
! specified as the ‘build’ parameter on the ‘configure’ line.  For
  example:
  
       % SRCDIR/configure --build=sparcv9-sun-solaris2.11 --prefix=DIRNAME
*************** not interested in supporting older, a.ou
*** 4178,4199 ****
  VxWorks in GCC 3.
  
     VxWorks comes with an older version of GCC installed in
! '$WIND_BASE/host'; we recommend you do not overwrite it.  Choose an
  installation PREFIX entirely outside $WIND_BASE.  Before running
! 'configure', create the directories 'PREFIX' and 'PREFIX/bin'.  Link or
! copy the appropriate assembler, linker, etc. into 'PREFIX/bin', and set
! your PATH to include that directory while running both 'configure' and
! 'make'.
  
!    You must give 'configure' the '--with-headers=$WIND_BASE/target/h'
  switch so that it can find the VxWorks system headers.  Since VxWorks is
  a cross compilation target only, you must also specify
! '--target=TARGET'.  'configure' will attempt to create the directory
! 'PREFIX/TARGET/sys-include' and copy files into it; make sure the user
! running 'configure' has sufficient privilege to do so.
  
     GCC's exception handling runtime requires a special "configlette"
! module, 'contrib/gthr_supp_vxw_5x.c'.  Follow the instructions in that
  file to add the module to your kernel build.  (Future versions of
  VxWorks will incorporate this module.)
  
--- 4178,4199 ----
  VxWorks in GCC 3.
  
     VxWorks comes with an older version of GCC installed in
! ‘$WIND_BASE/host’; we recommend you do not overwrite it.  Choose an
  installation PREFIX entirely outside $WIND_BASE.  Before running
! ‘configure’, create the directories ‘PREFIX’ and ‘PREFIX/bin’.  Link or
! copy the appropriate assembler, linker, etc. into ‘PREFIX/bin’, and set
! your PATH to include that directory while running both ‘configure’ and
! ‘make’.
  
!    You must give ‘configure’ the ‘--with-headers=$WIND_BASE/target/h’
  switch so that it can find the VxWorks system headers.  Since VxWorks is
  a cross compilation target only, you must also specify
! ‘--target=TARGET’.  ‘configure’ will attempt to create the directory
! ‘PREFIX/TARGET/sys-include’ and copy files into it; make sure the user
! running ‘configure’ has sufficient privilege to do so.
  
     GCC's exception handling runtime requires a special "configlette"
! module, ‘contrib/gthr_supp_vxw_5x.c’.  Follow the instructions in that
  file to add the module to your kernel build.  (Future versions of
  VxWorks will incorporate this module.)
  
*************** x86_64-*-*, amd64-*-*
*** 4203,4233 ****
  GCC supports the x86-64 architecture implemented by the AMD64 processor
  (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD.
  On GNU/Linux the default is a bi-arch compiler which is able to generate
! both 64-bit x86-64 and 32-bit x86 code (via the '-m32' switch).
  
  x86_64-*-solaris2*
  ==================
  
  GCC also supports the x86-64 architecture implemented by the AMD64
! processor ('amd64-*-*' is an alias for 'x86_64-*-*').  Unlike other
  systems, without special options a bi-arch compiler is built which
  generates 32-bit code by default, but can generate 64-bit x86-64 code
! with the '-m64' switch.  Since GCC 4.7, there is also a configuration
! that defaults to 64-bit code, but can generate 32-bit code with '-m32'.
  To configure and build this way, you have to provide all support
! libraries like 'libgmp' as 64-bit code, configure with
! '--target=x86_64-pc-solaris2.11' and 'CC=gcc -m64'.
  
  xtensa*-*-elf
  =============
  
! This target is intended for embedded Xtensa systems using the 'newlib' C
  library.  It uses ELF but does not support shared objects.
  Designed-defined instructions specified via the Tensilica Instruction
  Extension (TIE) language are only supported through inline assembly.
  
     The Xtensa configuration information must be specified prior to
! building GCC.  The 'include/xtensa-config.h' header file contains the
  configuration information.  If you created your own Xtensa configuration
  with the Xtensa Processor Generator, the downloaded files include a
  customized copy of this header file, which you can use to replace the
--- 4203,4233 ----
  GCC supports the x86-64 architecture implemented by the AMD64 processor
  (amd64-*-* is an alias for x86_64-*-*) on GNU/Linux, FreeBSD and NetBSD.
  On GNU/Linux the default is a bi-arch compiler which is able to generate
! both 64-bit x86-64 and 32-bit x86 code (via the ‘-m32’ switch).
  
  x86_64-*-solaris2*
  ==================
  
  GCC also supports the x86-64 architecture implemented by the AMD64
! processor (‘amd64-*-*’ is an alias for ‘x86_64-*-*’).  Unlike other
  systems, without special options a bi-arch compiler is built which
  generates 32-bit code by default, but can generate 64-bit x86-64 code
! with the ‘-m64’ switch.  Since GCC 4.7, there is also a configuration
! that defaults to 64-bit code, but can generate 32-bit code with ‘-m32’.
  To configure and build this way, you have to provide all support
! libraries like ‘libgmp’ as 64-bit code, configure with
! ‘--target=x86_64-pc-solaris2.11’ and ‘CC=gcc -m64’.
  
  xtensa*-*-elf
  =============
  
! This target is intended for embedded Xtensa systems using the ‘newlib’ C
  library.  It uses ELF but does not support shared objects.
  Designed-defined instructions specified via the Tensilica Instruction
  Extension (TIE) language are only supported through inline assembly.
  
     The Xtensa configuration information must be specified prior to
! building GCC.  The ‘include/xtensa-config.h’ header file contains the
  configuration information.  If you created your own Xtensa configuration
  with the Xtensa Processor Generator, the downloaded files include a
  customized copy of this header file, which you can use to replace the
*************** xtensa*-*-linux*
*** 4238,4246 ****
  
  This target is for Xtensa systems running GNU/Linux.  It supports ELF
  shared objects and the GNU C library (glibc).  It also generates
! position-independent code (PIC) regardless of whether the '-fpic' or
! '-fPIC' options are used.  In other respects, this target is the same as
! the 'xtensa*-*-elf' target.
  
  Microsoft Windows
  =================
--- 4238,4246 ----
  
  This target is for Xtensa systems running GNU/Linux.  It supports ELF
  shared objects and the GNU C library (glibc).  It also generates
! position-independent code (PIC) regardless of whether the ‘-fpic’ or
! ‘-fPIC’ options are used.  In other respects, this target is the same as
! the ‘xtensa*-*-elf’ target.
  
  Microsoft Windows
  =================
*************** Windows XP, and Windows Vista, are suppo
*** 4262,4272 ****
  platforms.  These targets differ in which Windows subsystem they target
  and which C libraries are used.
  
!    * Cygwin *-*-cygwin: Cygwin provides a user-space Linux API emulation
       layer in the Win32 subsystem.
!    * MinGW *-*-mingw32: MinGW is a native GCC port for the Win32
       subsystem that provides a subset of POSIX.
!    * MKS i386-pc-mks: NuTCracker from MKS. See
        for more information.
  
  Intel 64-bit versions
--- 4262,4272 ----
  platforms.  These targets differ in which Windows subsystem they target
  and which C libraries are used.
  
!    • Cygwin *-*-cygwin: Cygwin provides a user-space Linux API emulation
       layer in the Win32 subsystem.
!    • MinGW *-*-mingw32: MinGW is a native GCC port for the Win32
       subsystem that provides a subset of POSIX.
!    • MKS i386-pc-mks: NuTCracker from MKS. See
        for more information.
  
  Intel 64-bit versions
*************** version 2.20 or above if building your o
*** 4314,4323 ****
  
  GCC will build with and support only MinGW runtime 3.12 and later.
  Earlier versions of headers are incompatible with the new default
! semantics of 'extern inline' in '-std=c99' and '-std=gnu99' modes.
  
     To support emitting DWARF debugging info you need to use GNU binutils
! version 2.16 or above containing support for the '.secrel32' assembler
  pseudo-op.
  
  Older systems
--- 4314,4323 ----
  
  GCC will build with and support only MinGW runtime 3.12 and later.
  Earlier versions of headers are incompatible with the new default
! semantics of ‘extern inline’ in ‘-std=c99’ and ‘-std=gnu99’ modes.
  
     To support emitting DWARF debugging info you need to use GNU binutils
! version 2.16 or above containing support for the ‘.secrel32’ assembler
  pseudo-op.
  
  Older systems
*************** and may suffer from bitrot.
*** 4330,4336 ****
  
     Starting with GCC 3.1, each release has a list of "obsoleted"
  systems.  Support for these systems is still present in that release,
! but 'configure' will fail unless the '--enable-obsolete' option is
  given.  Unless a maintainer steps forward, support for these systems
  will be removed from the next release of GCC.
  
--- 4330,4336 ----
  
     Starting with GCC 3.1, each release has a list of "obsoleted"
  systems.  Support for these systems is still present in that release,
! but ‘configure’ will fail unless the ‘--enable-obsolete’ option is
  given.  Unless a maintainer steps forward, support for these systems
  will be removed from the next release of GCC.
  
*************** bring GCC up on such a system, if still
*** 4341,4348 ****
  require first installing an old version of GCC which did work on that
  system, and using it to compile a more recent GCC, to avoid bugs in the
  vendor compiler.  Old releases of GCC 1 and GCC 2 are available in the
! 'old-releases' directory on the GCC mirror sites.  Header bugs may
! generally be avoided using 'fixincludes', but bugs or deficiencies in
  libraries and the operating system may still cause problems.
  
     Support for older systems as targets for cross-compilation is less
--- 4341,4348 ----
  require first installing an old version of GCC which did work on that
  system, and using it to compile a more recent GCC, to avoid bugs in the
  vendor compiler.  Old releases of GCC 1 and GCC 2 are available in the
! ‘old-releases’ directory on the GCC mirror sites.  Header bugs may
! generally be avoided using ‘fixincludes’, but bugs or deficiencies in
  libraries and the operating system may still cause problems.
  
     Support for older systems as targets for cross-compilation is less
*************** would be likely to be accepted, since th
*** 4354,4360 ****
  for more modern targets.
  
     For some systems, old versions of GNU binutils may also be useful,
! and are available from 'pub/binutils/old-releases' on sourceware.org
  mirror sites.
  
     Some of the information on specific systems above relates to such
--- 4354,4360 ----
  for more modern targets.
  
     For some systems, old versions of GNU binutils may also be useful,
! and are available from ‘pub/binutils/old-releases’ on sourceware.org
  mirror sites.
  
     Some of the information on specific systems above relates to such
*************** GNU Free Documentation License
*** 4377,4383 ****
  
                       Version 1.3, 3 November 2008
  
!      Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
--- 4377,4383 ----
  
                       Version 1.3, 3 November 2008
  
!      Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
*************** GNU Free Documentation License
*** 4386,4392 ****
    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
--- 4386,4392 ----
    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
*************** Concept Index
*** 4887,4991 ****
  
  
  Tag Table:
! Node: Top1696
! Node: Installing GCC2201
! Node: Prerequisites3837
! Ref: GNAT-prerequisite5825
! Ref: GDC-prerequisite7222
! Ref: GM2-prerequisite8405
! Node: Downloading the source18312
! Node: Configuration19983
! Ref: with-gnu-as38250
! Ref: with-as39101
! Ref: with-gnu-ld40466
! Ref: WithAixSoname67344
! Ref: AixLdCommand68005
! Node: Building110015
! Node: Testing126222
! Node: Final install133963
! Node: Binaries138632
! Node: Specific139617
! Ref: aarch64-x-x140151
! Ref: alpha-x-x142171
! Ref: amd64-x-solaris2142385
! Ref: amdgcn-x-amdhsa142467
! Ref: arc-x-elf32142992
! Ref: arc-linux-uclibc143168
! Ref: arm-x-eabi143309
! Ref: avr143562
! Ref: bfin144143
! Ref: cris144406
! Ref: dos144732
! Ref: epiphany-x-elf145057
! Ref: x-x-freebsd145162
! Ref: ft32-x-elf146726
! Ref: h8300-hms146824
! Ref: hppa-hp-hpux147176
! Ref: hppa-hp-hpux10149548
! Ref: hppa-hp-hpux11149961
! Ref: x-x-linux-gnu155363
! Ref: ix86-x-linux155686
! Ref: ix86-x-solaris2155999
! Ref: ia64-x-linux156247
! Ref: ia64-x-hpux156494
! Ref: x-ibm-aix157049
! Ref: TransferAixShobj160711
! Ref: iq2000-x-elf164521
! Ref: lm32-x-elf164661
! Ref: lm32-x-uclinux164765
! Ref: loongarch164893
! Ref: m32c-x-elf165587
! Ref: m32r-x-elf165689
! Ref: m68k-x-x165791
! Ref: m68k-x-uclinux166829
! Ref: microblaze-x-elf167074
! Ref: mips-x-x167193
! Ref: moxie-x-elf169103
! Ref: msp430-x-elf169150
! Ref: nds32le-x-elf169707
! Ref: nds32be-x-elf169779
! Ref: nvptx-x-none169848
! Ref: or1k-x-elf170711
! Ref: or1k-x-linux170842
! Ref: powerpc-x-x170923
! Ref: powerpc-x-darwin171114
! Ref: powerpc-x-elf171609
! Ref: powerpc-x-linux-gnu171694
! Ref: powerpc-x-netbsd171789
! Ref: powerpc-x-eabisim171877
! Ref: powerpc-x-eabi172003
! Ref: powerpcle-x-elf172079
! Ref: powerpcle-x-eabisim172171
! Ref: powerpcle-x-eabi172304
! Ref: rl78-x-elf172387
! Ref: riscv32-x-elf172493
! Ref: riscv32-x-linux172682
! Ref: riscv64-x-elf172839
! Ref: riscv64-x-linux173028
! Ref: rx-x-elf173185
! Ref: s390-x-linux173231
! Ref: s390x-x-linux173303
! Ref: s390x-ibm-tpf173390
! Ref: x-x-solaris2173521
! Ref: sparc-x-x177294
! Ref: sparc-sun-solaris2177796
! Ref: sparc-x-linux178695
! Ref: sparc64-x-solaris2178726
! Ref: sparcv9-x-solaris2178813
! Ref: c6x-x-x179534
! Ref: visium-x-elf179626
! Ref: x-x-vxworks179734
! Ref: x86-64-x-x181257
! Ref: x86-64-x-solaris2181585
! Ref: xtensa-x-elf182211
! Ref: xtensa-x-linux182882
! Ref: windows183223
! Ref: x-x-cygwin184870
! Ref: x-x-mingw32185423
! Ref: older185805
! Ref: elf187922
! Node: GNU Free Documentation License188176
! Node: Concept Index213314
  
  End Tag Table
  
--- 4887,4991 ----
  
  
  Tag Table:
! Node: Top1694
! Node: Installing GCC2199
! Node: Prerequisites3839
! Ref: GNAT-prerequisite5851
! Ref: GDC-prerequisite7276
! Ref: GM2-prerequisite8479
! Node: Downloading the source18814
! Node: Configuration20533
! Ref: with-gnu-as39390
! Ref: with-as40279
! Ref: with-gnu-ld41688
! Ref: WithAixSoname69663
! Ref: AixLdCommand70378
! Node: Building114514
! Node: Testing131185
! Node: Final install139136
! Node: Binaries143943
! Node: Specific144954
! Ref: aarch64-x-x145488
! Ref: alpha-x-x147572
! Ref: amd64-x-solaris2147786
! Ref: amdgcn-x-amdhsa147872
! Ref: arc-x-elf32148437
! Ref: arc-linux-uclibc148629
! Ref: arm-x-eabi148774
! Ref: avr149031
! Ref: bfin149620
! Ref: cris149883
! Ref: dos150213
! Ref: epiphany-x-elf150538
! Ref: x-x-freebsd150643
! Ref: ft32-x-elf152231
! Ref: h8300-hms152329
! Ref: hppa-hp-hpux152681
! Ref: hppa-hp-hpux10155101
! Ref: hppa-hp-hpux11155518
! Ref: x-x-linux-gnu161020
! Ref: ix86-x-linux161351
! Ref: ix86-x-solaris2161664
! Ref: ia64-x-linux161924
! Ref: ia64-x-hpux162175
! Ref: x-ibm-aix162742
! Ref: TransferAixShobj166460
! Ref: iq2000-x-elf170350
! Ref: lm32-x-elf170490
! Ref: lm32-x-uclinux170594
! Ref: loongarch170722
! Ref: m32c-x-elf171456
! Ref: m32r-x-elf171558
! Ref: m68k-x-x171660
! Ref: m68k-x-uclinux172790
! Ref: microblaze-x-elf173043
! Ref: mips-x-x173162
! Ref: moxie-x-elf175148
! Ref: msp430-x-elf175195
! Ref: nds32le-x-elf175764
! Ref: nds32be-x-elf175836
! Ref: nvptx-x-none175905
! Ref: or1k-x-elf176812
! Ref: or1k-x-linux176943
! Ref: powerpc-x-x177024
! Ref: powerpc-x-darwin177223
! Ref: powerpc-x-elf177718
! Ref: powerpc-x-linux-gnu177803
! Ref: powerpc-x-netbsd177898
! Ref: powerpc-x-eabisim177986
! Ref: powerpc-x-eabi178112
! Ref: powerpcle-x-elf178188
! Ref: powerpcle-x-eabisim178280
! Ref: powerpcle-x-eabi178413
! Ref: rl78-x-elf178496
! Ref: riscv32-x-elf178602
! Ref: riscv32-x-linux178791
! Ref: riscv64-x-elf178948
! Ref: riscv64-x-linux179137
! Ref: rx-x-elf179294
! Ref: s390-x-linux179340
! Ref: s390x-x-linux179412
! Ref: s390x-ibm-tpf179499
! Ref: x-x-solaris2179630
! Ref: sparc-x-x183563
! Ref: sparc-sun-solaris2184065
! Ref: sparc-x-linux184980
! Ref: sparc64-x-solaris2185011
! Ref: sparcv9-x-solaris2185102
! Ref: c6x-x-x185851
! Ref: visium-x-elf185943
! Ref: x-x-vxworks186051
! Ref: x86-64-x-x187630
! Ref: x86-64-x-solaris2187962
! Ref: xtensa-x-elf188616
! Ref: xtensa-x-linux189295
! Ref: windows189648
! Ref: x-x-cygwin191301
! Ref: x-x-mingw32191854
! Ref: older192252
! Ref: elf194389
! Node: GNU Free Documentation License194643
! Node: Concept Index219784
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/doc/gccint.info gcc-13.5.0-RC-20260904/gcc/doc/gccint.info
*** gcc-13.4.0/gcc/doc/gccint.info	Thu Jun  5 16:22:05 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gccint.info	Fri Sep  4 07:50:38 2026
***************
*** 1,6 ****
! This is gccint.info, produced by makeinfo version 6.8 from gccint.texi.
  
! Copyright (C) 1988-2023 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
--- 1,6 ----
! This is gccint.info, produced by makeinfo version 7.1 from gccint.texi.
  
! Copyright © 1988-2023 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
*************** END-INFO-DIR-ENTRY
*** 26,32 ****
  
   This file documents the internals of the GNU compilers.
  
!  Copyright (C) 1988-2023 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
--- 26,32 ----
  
   This file documents the internals of the GNU compilers.
  
!  Copyright © 1988-2023 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
*************** Introduction
*** 55,61 ****
  This manual documents the internals of the GNU compilers, including how
  to port them to new targets and some information about how to write
  front ends for new languages.  It corresponds to the compilers (GCC)
! version 13.4.0.  The use of the GNU compilers is documented in a
  separate manual.  *Note Introduction: (gcc)Top.
  
   This manual is mainly a reference manual rather than a tutorial.  It
--- 55,61 ----
  This manual documents the internals of the GNU compilers, including how
  to port them to new targets and some information about how to write
  front ends for new languages.  It corresponds to the compilers (GCC)
! version 13.4.1.  The use of the GNU compilers is documented in a
  separate manual.  *Note Introduction: (gcc)Top.
  
   This manual is mainly a reference manual rather than a tutorial.  It
*************** GCC.
*** 91,99 ****
  * Loop Analysis and Representation:: Analysis and representation of loops
  * Machine Desc::    How to write machine description instruction patterns.
  * Target Macros::   How to write the machine description C macros and functions.
! * Host Config::     Writing the 'xm-MACHINE.h' file.
! * Fragments::       Writing the 't-TARGET' and 'x-HOST' files.
! * Collect2::        How 'collect2' works; how it finds 'ld'.
  * Header Dirs::     Understanding the standard header file directories.
  * Type Information:: GCC's memory management; generating type information.
  * Plugins::         Extending the compiler with plugins.
--- 91,99 ----
  * Loop Analysis and Representation:: Analysis and representation of loops
  * Machine Desc::    How to write machine description instruction patterns.
  * Target Macros::   How to write the machine description C macros and functions.
! * Host Config::     Writing the ‘xm-MACHINE.h’ file.
! * Fragments::       Writing the ‘t-TARGET’ and ‘x-HOST’ files.
! * Collect2::        How ‘collect2’ works; how it finds ‘ld’.
  * Header Dirs::     Understanding the standard header file directories.
  * Type Information:: GCC's memory management; generating type information.
  * Plugins::         Extending the compiler with plugins.
*************** File: gccint.info,  Node: Portability,
*** 140,149 ****
  2 GCC and Portability
  *********************
  
! GCC itself aims to be portable to any machine where 'int' is at least a
  32-bit type.  It aims to target machines with a flat (non-segmented)
  byte addressed data address space (the code address space can be
! separate).  Target ABIs may have 8, 16, 32 or 64-bit 'int' type.  'char'
  can be wider than 8 bits.
  
   GCC gets most of the information about the target machine from a
--- 140,149 ----
  2 GCC and Portability
  *********************
  
! GCC itself aims to be portable to any machine where ‘int’ is at least a
  32-bit type.  It aims to target machines with a flat (non-segmented)
  byte addressed data address space (the code address space can be
! separate).  Target ABIs may have 8, 16, 32 or 64-bit ‘int’ type.  ‘char’
  can be wider than 8 bits.
  
   GCC gets most of the information about the target machine from a
*************** that are usable for different combinatio
*** 164,170 ****
  all possible cases have been addressed, but only the common ones or only
  the ones that have been encountered.  As a result, a new target may
  require additional strategies.  You will know if this happens because
! the compiler will call 'abort'.  Fortunately, the new strategies can be
  added in a machine-independent fashion, and will affect only the target
  machines that need them.
  
--- 164,170 ----
  all possible cases have been addressed, but only the common ones or only
  the ones that have been encountered.  As a result, a new target may
  require additional strategies.  You will know if this happens because
! the compiler will call ‘abort’.  Fortunately, the new strategies can be
  added in a machine-independent fashion, and will affect only the target
  machines that need them.
  
*************** vice versa.  This does not cause trouble
*** 185,195 ****
  routines return structures or unions.
  
   GCC code returns structures and unions that are 1, 2, 4 or 8 bytes long
! in the same registers used for 'int' or 'double' return values.  (GCC
  typically allocates variables of such types in registers also.)
  Structures and unions of other sizes are returned by storing them into
  an address passed by the caller (usually in a register).  The target
! hook 'TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address.
  
   By contrast, PCC on most target machines returns structures and unions
  of any size by copying the data into an area of static storage, and then
--- 185,195 ----
  routines return structures or unions.
  
   GCC code returns structures and unions that are 1, 2, 4 or 8 bytes long
! in the same registers used for ‘int’ or ‘double’ return values.  (GCC
  typically allocates variables of such types in registers also.)
  Structures and unions of other sizes are returned by storing them into
  an address passed by the caller (usually in a register).  The target
! hook ‘TARGET_STRUCT_VALUE_RTX’ tells GCC where to pass this address.
  
   By contrast, PCC on most target machines returns structures and unions
  of any size by copying the data into an area of static storage, and then
*************** are passed "by invisible reference".  Th
*** 220,228 ****
  stored in memory, and the address of the memory location is passed to
  the subroutine.
  
!  If you use 'longjmp', beware of automatic variables.  ISO C says that
! automatic variables that are not declared 'volatile' have undefined
! values after a 'longjmp'.  And this is all GCC promises to do, because
  it is very difficult to restore register variables correctly, and one of
  GCC's features is that it can put variables in registers without your
  asking it to.
--- 220,228 ----
  stored in memory, and the address of the memory location is passed to
  the subroutine.
  
!  If you use ‘longjmp’, beware of automatic variables.  ISO C says that
! automatic variables that are not declared ‘volatile’ have undefined
! values after a ‘longjmp’.  And this is all GCC promises to do, because
  it is very difficult to restore register variables correctly, and one of
  GCC's features is that it can put variables in registers without your
  asking it to.
*************** File: gccint.info,  Node: Libgcc,  Next:
*** 233,247 ****
  4 The GCC low-level runtime library
  ***********************************
  
! GCC provides a low-level runtime library, 'libgcc.a' or 'libgcc_s.so.1'
  on some platforms.  GCC generates calls to routines in this library
  automatically, whenever it needs to perform some operation that is too
  complicated to emit inline code for.
  
!  Most of the routines in 'libgcc' handle arithmetic operations that the
  target processor cannot perform directly.  This includes integer
  multiply and divide on some machines, and all floating-point and
! fixed-point operations on other machines.  'libgcc' also includes
  routines for exception handling, and a handful of miscellaneous
  operations.
  
--- 233,247 ----
  4 The GCC low-level runtime library
  ***********************************
  
! GCC provides a low-level runtime library, ‘libgcc.a’ or ‘libgcc_s.so.1’
  on some platforms.  GCC generates calls to routines in this library
  automatically, whenever it needs to perform some operation that is too
  complicated to emit inline code for.
  
!  Most of the routines in ‘libgcc’ handle arithmetic operations that the
  target processor cannot perform directly.  This includes integer
  multiply and divide on some machines, and all floating-point and
! fixed-point operations on other machines.  ‘libgcc’ also includes
  routines for exception handling, and a handful of miscellaneous
  operations.
  
*************** operations.
*** 249,266 ****
  Others must be hand-written in assembly language for each processor that
  needs them.
  
!  GCC will also generate calls to C library routines, such as 'memcpy'
! and 'memset', in some cases.  The set of routines that GCC may possibly
  use is documented in *note (gcc)Other Builtins::.
  
   These routines take arguments and return values of a specific machine
  mode, not a specific C type.  *Note Machine Modes::, for an explanation
  of this concept.  For illustrative purposes, in this chapter the
! floating point type 'float' is assumed to correspond to 'SFmode';
! 'double' to 'DFmode'; and 'long double' to both 'TFmode' and 'XFmode'.
! Similarly, the integer types 'int' and 'unsigned int' correspond to
! 'SImode'; 'long' and 'unsigned long' to 'DImode'; and 'long long' and
! 'unsigned long long' to 'TImode'.
  
  * Menu:
  
--- 249,266 ----
  Others must be hand-written in assembly language for each processor that
  needs them.
  
!  GCC will also generate calls to C library routines, such as ‘memcpy’
! and ‘memset’, in some cases.  The set of routines that GCC may possibly
  use is documented in *note (gcc)Other Builtins::.
  
   These routines take arguments and return values of a specific machine
  mode, not a specific C type.  *Note Machine Modes::, for an explanation
  of this concept.  For illustrative purposes, in this chapter the
! floating point type ‘float’ is assumed to correspond to ‘SFmode’;
! ‘double’ to ‘DFmode’; and ‘long double’ to both ‘TFmode’ and ‘XFmode’.
! Similarly, the integer types ‘int’ and ‘unsigned int’ correspond to
! ‘SImode’; ‘long’ and ‘unsigned long’ to ‘DImode’; and ‘long long’ and
! ‘unsigned long long’ to ‘TImode’.
  
  * Menu:
  
*************** result using either signed or unsigned c
*** 374,380 ****
  -----------------------------------
  
  The following functions implement trapping arithmetic.  These functions
! call the libc function 'abort' upon signed arithmetic overflow.
  
   -- Runtime Function: int __absvsi2 (int A)
   -- Runtime Function: long __absvdi2 (long A)
--- 374,380 ----
  -----------------------------------
  
  The following functions implement trapping arithmetic.  These functions
! call the libc function ‘abort’ upon signed arithmetic overflow.
  
   -- Runtime Function: int __absvsi2 (int A)
   -- Runtime Function: long __absvdi2 (long A)
*************** call the libc function 'abort' upon sign
*** 382,401 ****
  
   -- Runtime Function: int __addvsi3 (int A, int B)
   -- Runtime Function: long __addvdi3 (long A, long B)
!      These functions return the sum of A and B; that is 'A + B'.
  
   -- Runtime Function: int __mulvsi3 (int A, int B)
   -- Runtime Function: long __mulvdi3 (long A, long B)
!      The functions return the product of A and B; that is 'A * B'.
  
   -- Runtime Function: int __negvsi2 (int A)
   -- Runtime Function: long __negvdi2 (long A)
!      These functions return the negation of A; that is '-A'.
  
   -- Runtime Function: int __subvsi3 (int A, int B)
   -- Runtime Function: long __subvdi3 (long A, long B)
!      These functions return the difference between B and A; that is 'A -
!      B'.
  
  4.1.4 Bit operations
  --------------------
--- 382,401 ----
  
   -- Runtime Function: int __addvsi3 (int A, int B)
   -- Runtime Function: long __addvdi3 (long A, long B)
!      These functions return the sum of A and B; that is ‘A + B’.
  
   -- Runtime Function: int __mulvsi3 (int A, int B)
   -- Runtime Function: long __mulvdi3 (long A, long B)
!      The functions return the product of A and B; that is ‘A * B’.
  
   -- Runtime Function: int __negvsi2 (int A)
   -- Runtime Function: long __negvdi2 (long A)
!      These functions return the negation of A; that is ‘-A’.
  
   -- Runtime Function: int __subvsi3 (int A, int B)
   -- Runtime Function: long __subvdi3 (long A, long B)
!      These functions return the difference between B and A; that is ‘A -
!      B’.
  
  4.1.4 Bit operations
  --------------------
*************** File: gccint.info,  Node: Soft float lib
*** 443,457 ****
  
  The software floating point library is used on machines which do not
  have hardware support for floating point.  It is also used whenever
! '-msoft-float' is used to disable generation of floating point
  instructions.  (Not all targets support this switch.)
  
   For compatibility with other compilers, the floating point emulation
! routines can be renamed with the 'DECLARE_LIBRARY_RENAMES' macro (*note
  Library Calls::).  In this section, the default names are used.
  
!  Presently the library does not support 'XFmode', which is used for
! 'long double' on some architectures.
  
  4.2.1 Arithmetic functions
  --------------------------
--- 443,457 ----
  
  The software floating point library is used on machines which do not
  have hardware support for floating point.  It is also used whenever
! ‘-msoft-float’ is used to disable generation of floating point
  instructions.  (Not all targets support this switch.)
  
   For compatibility with other compilers, the floating point emulation
! routines can be renamed with the ‘DECLARE_LIBRARY_RENAMES’ macro (*note
  Library Calls::).  In this section, the default names are used.
  
!  Presently the library does not support ‘XFmode’, which is used for
! ‘long double’ on some architectures.
  
  4.2.1 Arithmetic functions
  --------------------------
*************** There are two sets of basic comparison f
*** 601,607 ****
   -- Runtime Function: int __cmpdf2 (double A, double B)
   -- Runtime Function: int __cmptf2 (long double A, long double B)
       These functions calculate a <=> b.  That is, if A is less than B,
!      they return -1; if A is greater than B, they return 1; and if A and
       B are equal they return 0.  If either argument is NaN they return
       1, but you should not rely on this; if NaN is a possibility, use
       one of the higher-level comparison functions.
--- 601,607 ----
   -- Runtime Function: int __cmpdf2 (double A, double B)
   -- Runtime Function: int __cmptf2 (long double A, long double B)
       These functions calculate a <=> b.  That is, if A is less than B,
!      they return −1; if A is greater than B, they return 1; and if A and
       B are equal they return 0.  If either argument is NaN they return
       1, but you should not rely on this; if NaN is a possibility, use
       one of the higher-level comparison functions.
*************** File: gccint.info,  Node: Fixed-point fr
*** 1012,1031 ****
  The software fixed-point library implements fixed-point fractional
  arithmetic, and is only activated on selected targets.
  
!  For ease of comprehension 'fract' is an alias for the '_Fract' type,
! 'accum' an alias for '_Accum', and 'sat' an alias for '_Sat'.
  
   For illustrative purposes, in this section the fixed-point fractional
! type 'short fract' is assumed to correspond to machine mode 'QQmode';
! 'unsigned short fract' to 'UQQmode'; 'fract' to 'HQmode';
! 'unsigned fract' to 'UHQmode'; 'long fract' to 'SQmode';
! 'unsigned long fract' to 'USQmode'; 'long long fract' to 'DQmode'; and
! 'unsigned long long fract' to 'UDQmode'.  Similarly the fixed-point
! accumulator type 'short accum' corresponds to 'HAmode';
! 'unsigned short accum' to 'UHAmode'; 'accum' to 'SAmode';
! 'unsigned accum' to 'USAmode'; 'long accum' to 'DAmode';
! 'unsigned long accum' to 'UDAmode'; 'long long accum' to 'TAmode'; and
! 'unsigned long long accum' to 'UTAmode'.
  
  4.4.1 Arithmetic functions
  --------------------------
--- 1012,1031 ----
  The software fixed-point library implements fixed-point fractional
  arithmetic, and is only activated on selected targets.
  
!  For ease of comprehension ‘fract’ is an alias for the ‘_Fract’ type,
! ‘accum’ an alias for ‘_Accum’, and ‘sat’ an alias for ‘_Sat’.
  
   For illustrative purposes, in this section the fixed-point fractional
! type ‘short fract’ is assumed to correspond to machine mode ‘QQmode’;
! ‘unsigned short fract’ to ‘UQQmode’; ‘fract’ to ‘HQmode’;
! ‘unsigned fract’ to ‘UHQmode’; ‘long fract’ to ‘SQmode’;
! ‘unsigned long fract’ to ‘USQmode’; ‘long long fract’ to ‘DQmode’; and
! ‘unsigned long long fract’ to ‘UDQmode’.  Similarly the fixed-point
! accumulator type ‘short accum’ corresponds to ‘HAmode’;
! ‘unsigned short accum’ to ‘UHAmode’; ‘accum’ to ‘SAmode’;
! ‘unsigned accum’ to ‘USAmode’; ‘long accum’ to ‘DAmode’;
! ‘unsigned long accum’ to ‘UDAmode’; ‘long long accum’ to ‘TAmode’; and
! ‘unsigned long long accum’ to ‘UTAmode’.
  
  4.4.1 Arithmetic functions
  --------------------------
*************** accumulator type 'short accum' correspon
*** 1120,1126 ****
            A, unsigned long accum B)
   -- Runtime Function: unsigned long long accum __subuta3 (unsigned long
            long accum A, unsigned long long accum B)
!      These functions return the difference of A and B; that is, 'A - B'.
  
   -- Runtime Function: short fract __sssubqq3 (short fract A, short fract
            B)
--- 1120,1126 ----
            A, unsigned long accum B)
   -- Runtime Function: unsigned long long accum __subuta3 (unsigned long
            long accum A, unsigned long long accum B)
!      These functions return the difference of A and B; that is, ‘A - B’.
  
   -- Runtime Function: short fract __sssubqq3 (short fract A, short fract
            B)
*************** accumulator type 'short accum' correspon
*** 1135,1141 ****
   -- Runtime Function: long long accum __sssubta3 (long long accum A,
            long long accum B)
       These functions return the difference of A and B with signed
!      saturation; that is, 'A - B'.
  
   -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short
            fract A, unsigned short fract B)
--- 1135,1141 ----
   -- Runtime Function: long long accum __sssubta3 (long long accum A,
            long long accum B)
       These functions return the difference of A and B with signed
!      saturation; that is, ‘A - B’.
  
   -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short
            fract A, unsigned short fract B)
*************** accumulator type 'short accum' correspon
*** 1154,1160 ****
   -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned
            long long accum A, unsigned long long accum B)
       These functions return the difference of A and B with unsigned
!      saturation; that is, 'A - B'.
  
   -- Runtime Function: short fract __mulqq3 (short fract A, short fract
            B)
--- 1154,1160 ----
   -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned
            long long accum A, unsigned long long accum B)
       These functions return the difference of A and B with unsigned
!      saturation; that is, ‘A - B’.
  
   -- Runtime Function: short fract __mulqq3 (short fract A, short fract
            B)
*************** File: gccint.info,  Node: Miscellaneous
*** 2943,2949 ****
   -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void
            *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void
            **INITIAL_SP)
!      When using '-fsplit-stack', this call may be used to iterate over
       the stack segments.  It may be called like this:
              void *next_segment = NULL;
              void *next_sp = NULL;
--- 2943,2949 ----
   -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void
            *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void
            **INITIAL_SP)
!      When using ‘-fsplit-stack’, this call may be used to iterate over
       the stack segments.  It may be called like this:
              void *next_segment = NULL;
              void *next_sp = NULL;
*************** File: gccint.info,  Node: Miscellaneous
*** 2964,2978 ****
       with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT,
       NEXT_SP, and INITIAL_SP to a different thread, and then to suspend
       one way or another.  A different thread may run the subsequent
!      '__splitstack_find' iterations.  Of course, this will only work if
       the first thread is suspended while the second thread is calling
!      '__splitstack_find'.  If not, the second thread could be looking at
       the stack while it is changing, and anything could happen.
  
   -- Variable: __morestack_segments
   -- Variable: __morestack_current_segment
   -- Variable: __morestack_initial_sp
!      Internal variables used by the '-fsplit-stack' implementation.
  
  
  File: gccint.info,  Node: Languages,  Next: Source Tree,  Prev: Libgcc,  Up: Top
--- 2964,2978 ----
       with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT,
       NEXT_SP, and INITIAL_SP to a different thread, and then to suspend
       one way or another.  A different thread may run the subsequent
!      ‘__splitstack_find’ iterations.  Of course, this will only work if
       the first thread is suspended while the second thread is calling
!      ‘__splitstack_find’.  If not, the second thread could be looking at
       the stack while it is changing, and anything could happen.
  
   -- Variable: __morestack_segments
   -- Variable: __morestack_current_segment
   -- Variable: __morestack_initial_sp
!      Internal variables used by the ‘-fsplit-stack’ implementation.
  
  
  File: gccint.info,  Node: Languages,  Next: Source Tree,  Prev: Libgcc,  Up: Top
*************** File: gccint.info,  Node: Languages,  Ne
*** 2981,2987 ****
  ****************************
  
  The interface to front ends for languages in GCC, and in particular the
! 'tree' structure (*note GENERIC::), was initially designed for C, and
  many aspects of it are still somewhat biased towards C and C-like
  languages.  It is, however, reasonably well suited to other procedural
  languages, and front ends for many such languages have been written for
--- 2981,2987 ----
  ****************************
  
  The interface to front ends for languages in GCC, and in particular the
! ‘tree’ structure (*note GENERIC::), was initially designed for C, and
  many aspects of it are still somewhat biased towards C and C-like
  languages.  It is, however, reasonably well suited to other procedural
  languages, and front ends for many such languages have been written for
*************** GCC.
*** 2991,3003 ****
  directly to assembler or generating C code which is then compiled by
  GCC, has several advantages:
  
!    * GCC front ends benefit from the support for many different target
       machines already present in GCC.
!    * GCC front ends benefit from all the optimizations in GCC.  Some of
       these, such as alias analysis, may work better when GCC is
       compiling directly from source code than when it is compiling from
       generated C code.
!    * Better debugging information is generated when compiling directly
       from source code than when going via intermediate generated C code.
  
   Because of the advantages of writing a compiler as a GCC front end, GCC
--- 2991,3003 ----
  directly to assembler or generating C code which is then compiled by
  GCC, has several advantages:
  
!    • GCC front ends benefit from the support for many different target
       machines already present in GCC.
!    • GCC front ends benefit from all the optimizations in GCC.  Some of
       these, such as alias analysis, may work better when GCC is
       compiling directly from source code than when it is compiling from
       generated C code.
!    • Better debugging information is generated when compiling directly
       from source code than when going via intermediate generated C code.
  
   Because of the advantages of writing a compiler as a GCC front end, GCC
*************** presumed that you are familiar.
*** 3022,3028 ****
  
  * Configure Terms:: Configuration terminology and history.
  * Top Level::       The top level source directory.
! * gcc Directory::   The 'gcc' subdirectory.
  
  
  File: gccint.info,  Node: Configure Terms,  Next: Top Level,  Up: Source Tree
--- 3022,3028 ----
  
  * Configure Terms:: Configuration terminology and history.
  * Top Level::       The top level source directory.
! * gcc Directory::   The ‘gcc’ subdirectory.
  
  
  File: gccint.info,  Node: Configure Terms,  Next: Top Level,  Up: Source Tree
*************** in detail, here are a few things that ev
*** 3037,3081 ****
  know.
  
   There are three system names that the build knows about: the machine
! you are building on ("build"), the machine that you are building for
! ("host"), and the machine that GCC will produce code for ("target").
! When you configure GCC, you specify these with '--build=', '--host=',
! and '--target='.
  
   Specifying the host without specifying the build should be avoided, as
! 'configure' may (and once did) assume that the host you specify is also
  the build, which may not be true.
  
!  If build, host, and target are all the same, this is called a "native".
  If build and host are the same but target is different, this is called a
! "cross".  If build, host, and target are all different this is called a
! "canadian" (for obscure reasons dealing with Canada's political party
  and the background of the person working on the build at that time).  If
  host and target are the same, but build is different, you are using a
  cross-compiler to build a native for a different system.  Some people
! call this a "host-x-host", "crossed native", or "cross-built native".
  If build and target are the same, but host is different, you are using a
  cross compiler to build a cross compiler that produces code for the
  machine you're building on.  This is rare, so there is no common way of
! describing it.  There is a proposal to call this a "crossback".
  
   If build and host are the same, the GCC you are building will also be
! used to build the target libraries (like 'libstdc++').  If build and
  host are different, you must have already built and installed a cross
  compiler that will be used to build the target libraries (if you
! configured with '--target=foo-bar', this compiler will be called
! 'foo-bar-gcc').
  
   In the case of target libraries, the machine you're building for is the
! machine you specified with '--target'.  So, build is the machine you're
  building on (no change there), host is the machine you're building for
  (the target libraries are built for the target, so host is the target
  you specified), and target doesn't apply (because you're not building a
  compiler, you're building libraries).  The configure/make process will
! adjust these variables as needed.  It also sets '$with_cross_host' to
! the original '--host' value in case you need it.
  
!  The 'libiberty' support library is built up to three times: once for
  the host, once for the target (even if they are the same), and once for
  the build if build and host are different.  This allows it to be used by
  all programs which are generated in the course of the build process.
--- 3037,3081 ----
  know.
  
   There are three system names that the build knows about: the machine
! you are building on (“build”), the machine that you are building for
! (“host”), and the machine that GCC will produce code for (“target”).
! When you configure GCC, you specify these with ‘--build=’, ‘--host=’,
! and ‘--target=’.
  
   Specifying the host without specifying the build should be avoided, as
! ‘configure’ may (and once did) assume that the host you specify is also
  the build, which may not be true.
  
!  If build, host, and target are all the same, this is called a “native”.
  If build and host are the same but target is different, this is called a
! “cross”.  If build, host, and target are all different this is called a
! “canadian” (for obscure reasons dealing with Canada's political party
  and the background of the person working on the build at that time).  If
  host and target are the same, but build is different, you are using a
  cross-compiler to build a native for a different system.  Some people
! call this a “host-x-host”, “crossed native”, or “cross-built native”.
  If build and target are the same, but host is different, you are using a
  cross compiler to build a cross compiler that produces code for the
  machine you're building on.  This is rare, so there is no common way of
! describing it.  There is a proposal to call this a “crossback”.
  
   If build and host are the same, the GCC you are building will also be
! used to build the target libraries (like ‘libstdc++’).  If build and
  host are different, you must have already built and installed a cross
  compiler that will be used to build the target libraries (if you
! configured with ‘--target=foo-bar’, this compiler will be called
! ‘foo-bar-gcc’).
  
   In the case of target libraries, the machine you're building for is the
! machine you specified with ‘--target’.  So, build is the machine you're
  building on (no change there), host is the machine you're building for
  (the target libraries are built for the target, so host is the target
  you specified), and target doesn't apply (because you're not building a
  compiler, you're building libraries).  The configure/make process will
! adjust these variables as needed.  It also sets ‘$with_cross_host’ to
! the original ‘--host’ value in case you need it.
  
!  The ‘libiberty’ support library is built up to three times: once for
  the host, once for the target (even if they are the same), and once for
  the build if build and host are different.  This allows it to be used by
  all programs which are generated in the course of the build process.
*************** files and directories that are shared wi
*** 3091,3217 ****
  such as that of GNU Binutils.  It also contains several subdirectories
  that contain parts of GCC and its runtime libraries:
  
! 'c++tools'
       Contains the sources for the g++-mapper-server, a tool used with
       C++ modules.
  
! 'config'
       Autoconf macros and Makefile fragments used throughout the tree.
  
! 'contrib'
       Contributed scripts that may be found useful in conjunction with
!      GCC.  One of these, 'contrib/texi2pod.pl', is used to generate man
       pages from Texinfo manuals as part of the GCC build process.
  
! 'fixincludes'
       The support for fixing system headers to work with GCC.  See
!      'fixincludes/README' for more information.  The headers fixed by
!      this mechanism are installed in 'LIBSUBDIR/include-fixed'.  Along
!      with those headers, 'README-fixinc' is also installed, as
!      'LIBSUBDIR/include-fixed/README'.
  
! 'gcc'
       The main sources of GCC itself (except for runtime libraries),
       including optimizers, support for different target architectures,
!      language front ends, and testsuites.  *Note The 'gcc' Subdirectory:
       gcc Directory, for details.
  
! 'gnattools'
       Support tools for GNAT.
  
! 'gotools'
       Support tools for Go.
  
! 'include'
!      Headers for the 'libiberty' library.
  
! 'intl'
!      GNU 'libintl', from GNU 'gettext', for systems which do not include
!      it in 'libc'.
  
! 'libada'
       The Ada runtime library.
  
! 'libatomic'
       The runtime support library for atomic operations (e.g. for
!      '__sync' and '__atomic').
  
! 'libbacktrace'
       A library that allows GCC to produce backtraces when it crashes.
  
! 'libcc1'
       A library that allows GDB to make use of the compiler.
  
! 'libcody'
       A compiler dynamism library to allow communication between
       compilers and build systems, for purposes such as C++ modules.
  
! 'libcpp'
       The C preprocessor library.
  
! 'libdecnumber'
       The Decimal Float support library.
  
! 'libffi'
!      The 'libffi' library, used as part of the Go runtime library.
  
! 'libgcc'
       The GCC runtime library.
  
! 'libgfortran'
       The Fortran runtime library.
  
! 'libgm2'
       The Modula-2 runtime library.
  
! 'libgo'
       The Go runtime library.  The bulk of this library is mirrored from
       the master Go repository (https://github.com/golang/go).
  
! 'libgomp'
       The GNU Offloading and Multi Processing Runtime Library.
  
! 'libiberty'
!      The 'libiberty' library, used for portability and for some
       generally useful data structures and algorithms.  *Note
       Introduction: (libiberty)Top, for more information about this
       library.
  
! 'libitm'
       The runtime support library for transactional memory.
  
! 'libobjc'
       The Objective-C and Objective-C++ runtime library.
  
! 'libphobos'
       The D standard and runtime library.  The bulk of this library is
       mirrored from the master D repositories (https://github.com/dlang).
  
! 'libquadmath'
       The runtime support library for quad-precision math operations.
  
! 'libsanitizer'
       Libraries for various sanitizers.  The bulk of this directory is
       mirrored from the Google sanitizers repositories
       (https://github.com/google/sanitizers).
  
! 'libssp'
       The Stack protector runtime library.
  
! 'libstdc++-v3'
       The C++ runtime library.
  
! 'libvtv'
       The vtable verification library.
  
! 'lto-plugin'
       Plugin used by the linker if link-time optimizations are enabled.
  
! 'maintainer-scripts'
!      Scripts used by the 'gccadmin' account on 'gcc.gnu.org'.
  
! 'zlib'
!      The 'zlib' compression library, used for compressing and
       uncompressing GCC's intermediate language in LTO object files.
  
   The build system in the top level directory, including how recursion
--- 3091,3217 ----
  such as that of GNU Binutils.  It also contains several subdirectories
  that contain parts of GCC and its runtime libraries:
  
! ‘c++tools’
       Contains the sources for the g++-mapper-server, a tool used with
       C++ modules.
  
! ‘config’
       Autoconf macros and Makefile fragments used throughout the tree.
  
! ‘contrib’
       Contributed scripts that may be found useful in conjunction with
!      GCC.  One of these, ‘contrib/texi2pod.pl’, is used to generate man
       pages from Texinfo manuals as part of the GCC build process.
  
! ‘fixincludes’
       The support for fixing system headers to work with GCC.  See
!      ‘fixincludes/README’ for more information.  The headers fixed by
!      this mechanism are installed in ‘LIBSUBDIR/include-fixed’.  Along
!      with those headers, ‘README-fixinc’ is also installed, as
!      ‘LIBSUBDIR/include-fixed/README’.
  
! ‘gcc’
       The main sources of GCC itself (except for runtime libraries),
       including optimizers, support for different target architectures,
!      language front ends, and testsuites.  *Note The ‘gcc’ Subdirectory:
       gcc Directory, for details.
  
! ‘gnattools’
       Support tools for GNAT.
  
! ‘gotools’
       Support tools for Go.
  
! ‘include’
!      Headers for the ‘libiberty’ library.
  
! ‘intl’
!      GNU ‘libintl’, from GNU ‘gettext’, for systems which do not include
!      it in ‘libc’.
  
! ‘libada’
       The Ada runtime library.
  
! ‘libatomic’
       The runtime support library for atomic operations (e.g. for
!      ‘__sync’ and ‘__atomic’).
  
! ‘libbacktrace’
       A library that allows GCC to produce backtraces when it crashes.
  
! ‘libcc1’
       A library that allows GDB to make use of the compiler.
  
! ‘libcody’
       A compiler dynamism library to allow communication between
       compilers and build systems, for purposes such as C++ modules.
  
! ‘libcpp’
       The C preprocessor library.
  
! ‘libdecnumber’
       The Decimal Float support library.
  
! ‘libffi’
!      The ‘libffi’ library, used as part of the Go runtime library.
  
! ‘libgcc’
       The GCC runtime library.
  
! ‘libgfortran’
       The Fortran runtime library.
  
! ‘libgm2’
       The Modula-2 runtime library.
  
! ‘libgo’
       The Go runtime library.  The bulk of this library is mirrored from
       the master Go repository (https://github.com/golang/go).
  
! ‘libgomp’
       The GNU Offloading and Multi Processing Runtime Library.
  
! ‘libiberty’
!      The ‘libiberty’ library, used for portability and for some
       generally useful data structures and algorithms.  *Note
       Introduction: (libiberty)Top, for more information about this
       library.
  
! ‘libitm’
       The runtime support library for transactional memory.
  
! ‘libobjc’
       The Objective-C and Objective-C++ runtime library.
  
! ‘libphobos’
       The D standard and runtime library.  The bulk of this library is
       mirrored from the master D repositories (https://github.com/dlang).
  
! ‘libquadmath’
       The runtime support library for quad-precision math operations.
  
! ‘libsanitizer’
       Libraries for various sanitizers.  The bulk of this directory is
       mirrored from the Google sanitizers repositories
       (https://github.com/google/sanitizers).
  
! ‘libssp’
       The Stack protector runtime library.
  
! ‘libstdc++-v3’
       The C++ runtime library.
  
! ‘libvtv’
       The vtable verification library.
  
! ‘lto-plugin’
       Plugin used by the linker if link-time optimizations are enabled.
  
! ‘maintainer-scripts’
!      Scripts used by the ‘gccadmin’ account on ‘gcc.gnu.org’.
  
! ‘zlib’
!      The ‘zlib’ compression library, used for compressing and
       uncompressing GCC's intermediate language in LTO object files.
  
   The build system in the top level directory, including how recursion
*************** GNU Binutils.
*** 3222,3231 ****
  
  File: gccint.info,  Node: gcc Directory,  Prev: Top Level,  Up: Source Tree
  
! 6.3 The 'gcc' Subdirectory
  ==========================
  
! The 'gcc' directory contains many files that are part of the C sources
  of GCC, other files used as part of the configuration and build process,
  and subdirectories including documentation and a testsuite.  The files
  that are sources of GCC are documented in a separate chapter.  *Note
--- 3222,3231 ----
  
  File: gccint.info,  Node: gcc Directory,  Prev: Top Level,  Up: Source Tree
  
! 6.3 The ‘gcc’ Subdirectory
  ==========================
  
! The ‘gcc’ directory contains many files that are part of the C sources
  of GCC, other files used as part of the configuration and build process,
  and subdirectories including documentation and a testsuite.  The files
  that are sources of GCC are documented in a separate chapter.  *Note
*************** Passes and Files of the Compiler: Passes
*** 3233,3243 ****
  
  * Menu:
  
! * Subdirectories:: Subdirectories of 'gcc'.
  * Configuration::  The configuration process, and the files it uses.
! * Build::          The build system in the 'gcc' directory.
! * Makefile::       Targets in 'gcc/Makefile'.
! * Library Files::  Library source files and headers under 'gcc/'.
  * Headers::        Headers installed by GCC.
  * Documentation::  Building documentation in GCC.
  * Front End::      Anatomy of a language front end.
--- 3233,3243 ----
  
  * Menu:
  
! * Subdirectories:: Subdirectories of ‘gcc’.
  * Configuration::  The configuration process, and the files it uses.
! * Build::          The build system in the ‘gcc’ directory.
! * Makefile::       Targets in ‘gcc/Makefile’.
! * Library Files::  Library source files and headers under ‘gcc/’.
  * Headers::        Headers installed by GCC.
  * Documentation::  Building documentation in GCC.
  * Front End::      Anatomy of a language front end.
*************** Passes and Files of the Compiler: Passes
*** 3246,3362 ****
  
  File: gccint.info,  Node: Subdirectories,  Next: Configuration,  Up: gcc Directory
  
! 6.3.1 Subdirectories of 'gcc'
  -----------------------------
  
! The 'gcc' directory contains the following subdirectories:
  
! 'LANGUAGE'
       Subdirectories for various languages.  Directories containing a
!      file 'config-lang.in' are language subdirectories.  The contents of
!      the subdirectories 'c' (for C), 'cp' (for C++), 'm2' (for
!      Modula-2), 'objc' (for Objective-C), 'objcp' (for Objective-C++),
!      and 'lto' (for LTO) are documented in this manual (*note Passes and
       Files of the Compiler: Passes.); those for other languages are not.
       *Note Anatomy of a Language Front End: Front End, for details of
       the files in these directories.
  
! 'common'
!      Source files shared between the compiler drivers (such as 'gcc')
!      and the compilers proper (such as 'cc1').  If an architecture
       defines target hooks shared between those places, it also has a
!      subdirectory in 'common/config'.  *Note Target Structure::.
  
! 'config'
       Configuration files for supported architectures and operating
       systems.  *Note Anatomy of a Target Back End: Back End, for details
       of the files in this directory.
  
! 'doc'
       Texinfo documentation for GCC, together with automatically
       generated man pages and support for converting the installation
       manual to HTML.  *Note Documentation::.
  
! 'ginclude'
       System headers installed by GCC, mainly those required by the C
       standard of freestanding implementations.  *Note Headers Installed
       by GCC: Headers, for details of when these and other headers are
       installed.
  
! 'po'
       Message catalogs with translations of messages produced by GCC into
!      various languages, 'LANGUAGE.po'.  This directory also contains
!      'gcc.pot', the template for these message catalogues, 'exgettext',
!      a wrapper around 'gettext' to extract the messages from the GCC
!      sources and create 'gcc.pot', which is run by 'make gcc.pot', and
!      'EXCLUDES', a list of files from which messages should not be
       extracted.
  
! 'testsuite'
       The GCC testsuites (except for those for runtime libraries).  *Note
       Testsuites::.
  
  
  File: gccint.info,  Node: Configuration,  Next: Build,  Prev: Subdirectories,  Up: gcc Directory
  
! 6.3.2 Configuration in the 'gcc' Directory
  ------------------------------------------
  
! The 'gcc' directory is configured with an Autoconf-generated script
! 'configure'.  The 'configure' script is generated from 'configure.ac'
! and 'aclocal.m4'.  From the files 'configure.ac' and 'acconfig.h',
! Autoheader generates the file 'config.in'.  The file 'cstamp-h.in' is
  used as a timestamp.
  
  * Menu:
  
! * Config Fragments::     Scripts used by 'configure'.
! * System Config::        The 'config.build', 'config.host', and
!                          'config.gcc' files.
! * Configuration Files::  Files created by running 'configure'.
  
  
  File: gccint.info,  Node: Config Fragments,  Next: System Config,  Up: Configuration
  
! 6.3.2.1 Scripts Used by 'configure'
  ...................................
  
! 'configure' uses some other scripts to help in its work:
  
!    * The standard GNU 'config.sub' and 'config.guess' files, kept in the
       top level directory, are used.
  
!    * The file 'config.gcc' is used to handle configuration specific to
!      the particular target machine.  The file 'config.build' is used to
       handle configuration specific to the particular build machine.  The
!      file 'config.host' is used to handle configuration specific to the
       particular host machine.  (In general, these should only be used
       for features that cannot reasonably be tested in Autoconf feature
!      tests.)  *Note The 'config.build'; 'config.host'; and 'config.gcc'
       Files: System Config, for details of the contents of these files.
  
!    * Each language subdirectory has a file 'LANGUAGE/config-lang.in'
       that is used for front-end-specific configuration.  *Note The Front
!      End 'config-lang.in' File: Front End Config, for details of this
       file.
  
!    * A helper script 'configure.frag' is used as part of creating the
!      output of 'configure'.
  
  
  File: gccint.info,  Node: System Config,  Next: Configuration Files,  Prev: Config Fragments,  Up: Configuration
  
! 6.3.2.2 The 'config.build'; 'config.host'; and 'config.gcc' Files
  .................................................................
  
! The 'config.build' file contains specific rules for particular systems
  which GCC is built on.  This should be used as rarely as possible, as
  the behavior of the build system can always be detected by autoconf.
  
!  The 'config.host' file contains specific rules for particular systems
  which GCC will run on.  This is rarely needed.
  
!  The 'config.gcc' file contains specific rules for particular systems
  which GCC will generate code for.  This is usually needed.
  
   Each file has a list of the shell variables it sets, with descriptions,
--- 3246,3362 ----
  
  File: gccint.info,  Node: Subdirectories,  Next: Configuration,  Up: gcc Directory
  
! 6.3.1 Subdirectories of ‘gcc’
  -----------------------------
  
! The ‘gcc’ directory contains the following subdirectories:
  
! ‘LANGUAGE’
       Subdirectories for various languages.  Directories containing a
!      file ‘config-lang.in’ are language subdirectories.  The contents of
!      the subdirectories ‘c’ (for C), ‘cp’ (for C++), ‘m2’ (for
!      Modula-2), ‘objc’ (for Objective-C), ‘objcp’ (for Objective-C++),
!      and ‘lto’ (for LTO) are documented in this manual (*note Passes and
       Files of the Compiler: Passes.); those for other languages are not.
       *Note Anatomy of a Language Front End: Front End, for details of
       the files in these directories.
  
! ‘common’
!      Source files shared between the compiler drivers (such as ‘gcc’)
!      and the compilers proper (such as ‘cc1’).  If an architecture
       defines target hooks shared between those places, it also has a
!      subdirectory in ‘common/config’.  *Note Target Structure::.
  
! ‘config’
       Configuration files for supported architectures and operating
       systems.  *Note Anatomy of a Target Back End: Back End, for details
       of the files in this directory.
  
! ‘doc’
       Texinfo documentation for GCC, together with automatically
       generated man pages and support for converting the installation
       manual to HTML.  *Note Documentation::.
  
! ‘ginclude’
       System headers installed by GCC, mainly those required by the C
       standard of freestanding implementations.  *Note Headers Installed
       by GCC: Headers, for details of when these and other headers are
       installed.
  
! ‘po’
       Message catalogs with translations of messages produced by GCC into
!      various languages, ‘LANGUAGE.po’.  This directory also contains
!      ‘gcc.pot’, the template for these message catalogues, ‘exgettext’,
!      a wrapper around ‘gettext’ to extract the messages from the GCC
!      sources and create ‘gcc.pot’, which is run by ‘make gcc.pot’, and
!      ‘EXCLUDES’, a list of files from which messages should not be
       extracted.
  
! ‘testsuite’
       The GCC testsuites (except for those for runtime libraries).  *Note
       Testsuites::.
  
  
  File: gccint.info,  Node: Configuration,  Next: Build,  Prev: Subdirectories,  Up: gcc Directory
  
! 6.3.2 Configuration in the ‘gcc’ Directory
  ------------------------------------------
  
! The ‘gcc’ directory is configured with an Autoconf-generated script
! ‘configure’.  The ‘configure’ script is generated from ‘configure.ac’
! and ‘aclocal.m4’.  From the files ‘configure.ac’ and ‘acconfig.h’,
! Autoheader generates the file ‘config.in’.  The file ‘cstamp-h.in’ is
  used as a timestamp.
  
  * Menu:
  
! * Config Fragments::     Scripts used by ‘configure’.
! * System Config::        The ‘config.build’, ‘config.host’, and
!                          ‘config.gcc’ files.
! * Configuration Files::  Files created by running ‘configure’.
  
  
  File: gccint.info,  Node: Config Fragments,  Next: System Config,  Up: Configuration
  
! 6.3.2.1 Scripts Used by ‘configure’
  ...................................
  
! ‘configure’ uses some other scripts to help in its work:
  
!    • The standard GNU ‘config.sub’ and ‘config.guess’ files, kept in the
       top level directory, are used.
  
!    • The file ‘config.gcc’ is used to handle configuration specific to
!      the particular target machine.  The file ‘config.build’ is used to
       handle configuration specific to the particular build machine.  The
!      file ‘config.host’ is used to handle configuration specific to the
       particular host machine.  (In general, these should only be used
       for features that cannot reasonably be tested in Autoconf feature
!      tests.)  *Note The ‘config.build’; ‘config.host’; and ‘config.gcc’
       Files: System Config, for details of the contents of these files.
  
!    • Each language subdirectory has a file ‘LANGUAGE/config-lang.in’
       that is used for front-end-specific configuration.  *Note The Front
!      End ‘config-lang.in’ File: Front End Config, for details of this
       file.
  
!    • A helper script ‘configure.frag’ is used as part of creating the
!      output of ‘configure’.
  
  
  File: gccint.info,  Node: System Config,  Next: Configuration Files,  Prev: Config Fragments,  Up: Configuration
  
! 6.3.2.2 The ‘config.build’; ‘config.host’; and ‘config.gcc’ Files
  .................................................................
  
! The ‘config.build’ file contains specific rules for particular systems
  which GCC is built on.  This should be used as rarely as possible, as
  the behavior of the build system can always be detected by autoconf.
  
!  The ‘config.host’ file contains specific rules for particular systems
  which GCC will run on.  This is rarely needed.
  
!  The ‘config.gcc’ file contains specific rules for particular systems
  which GCC will generate code for.  This is usually needed.
  
   Each file has a list of the shell variables it sets, with descriptions,
*************** be set to control build, host and target
*** 3368,3425 ****
  
  File: gccint.info,  Node: Configuration Files,  Prev: System Config,  Up: Configuration
  
! 6.3.2.3 Files Created by 'configure'
  ....................................
  
! Here we spell out what files will be set up by 'configure' in the 'gcc'
  directory.  Some other files are created as temporary files in the
  configuration process, and are not used in the subsequent build; these
  are not documented.
  
!    * 'Makefile' is constructed from 'Makefile.in', together with the
       host and target fragments (*note Makefile Fragments: Fragments.)
!      't-TARGET' and 'x-HOST' from 'config', if any, and language
!      Makefile fragments 'LANGUAGE/Make-lang.in'.
!    * 'auto-host.h' contains information about the host machine
!      determined by 'configure'.  If the host machine is different from
!      the build machine, then 'auto-build.h' is also created, containing
       such information about the build machine.
!    * 'config.status' is a script that may be run to recreate the current
       configuration.
!    * 'configargs.h' is a header containing details of the arguments
!      passed to 'configure' to configure GCC, and of the thread model
       used.
!    * 'cstamp-h' is used as a timestamp.
!    * If a language 'config-lang.in' file (*note The Front End
!      'config-lang.in' File: Front End Config.) sets 'outputs', then the
!      files listed in 'outputs' there are also generated.
  
   The following configuration headers are created from the Makefile,
! using 'mkconfig.sh', rather than directly by 'configure'.  'config.h',
! 'bconfig.h' and 'tconfig.h' all contain the 'xm-MACHINE.h' header, if
  any, appropriate to the host, build and target machines respectively,
  the configuration headers for the target, and some definitions; for the
  host and build machines, these include the autoconfigured headers
! generated by 'configure'.  The other configuration headers are
! determined by 'config.gcc'.  They also contain the typedefs for 'rtx',
! 'rtvec' and 'tree'.
  
!    * 'config.h', for use in programs that run on the host machine.
!    * 'bconfig.h', for use in programs that run on the build machine.
!    * 'tconfig.h', for use in programs and libraries for the target
       machine.
!    * 'tm_p.h', which includes the header 'MACHINE-protos.h' that
!      contains prototypes for functions in the target 'MACHINE.c' file.
!      The 'MACHINE-protos.h' header is included after the 'rtl.h' and/or
!      'tree.h' would have been included.  The 'tm_p.h' also includes the
!      header 'tm-preds.h' which is generated by 'genpreds' program during
       the build to define the declarations and inline functions for the
       predicate functions.
  
  
  File: gccint.info,  Node: Build,  Next: Makefile,  Prev: Configuration,  Up: gcc Directory
  
! 6.3.3 Build System in the 'gcc' Directory
  -----------------------------------------
  
  FIXME: describe the build system, including what is built in what
--- 3368,3425 ----
  
  File: gccint.info,  Node: Configuration Files,  Prev: System Config,  Up: Configuration
  
! 6.3.2.3 Files Created by ‘configure’
  ....................................
  
! Here we spell out what files will be set up by ‘configure’ in the ‘gcc’
  directory.  Some other files are created as temporary files in the
  configuration process, and are not used in the subsequent build; these
  are not documented.
  
!    • ‘Makefile’ is constructed from ‘Makefile.in’, together with the
       host and target fragments (*note Makefile Fragments: Fragments.)
!      ‘t-TARGET’ and ‘x-HOST’ from ‘config’, if any, and language
!      Makefile fragments ‘LANGUAGE/Make-lang.in’.
!    • ‘auto-host.h’ contains information about the host machine
!      determined by ‘configure’.  If the host machine is different from
!      the build machine, then ‘auto-build.h’ is also created, containing
       such information about the build machine.
!    • ‘config.status’ is a script that may be run to recreate the current
       configuration.
!    • ‘configargs.h’ is a header containing details of the arguments
!      passed to ‘configure’ to configure GCC, and of the thread model
       used.
!    • ‘cstamp-h’ is used as a timestamp.
!    • If a language ‘config-lang.in’ file (*note The Front End
!      ‘config-lang.in’ File: Front End Config.) sets ‘outputs’, then the
!      files listed in ‘outputs’ there are also generated.
  
   The following configuration headers are created from the Makefile,
! using ‘mkconfig.sh’, rather than directly by ‘configure’.  ‘config.h’,
! ‘bconfig.h’ and ‘tconfig.h’ all contain the ‘xm-MACHINE.h’ header, if
  any, appropriate to the host, build and target machines respectively,
  the configuration headers for the target, and some definitions; for the
  host and build machines, these include the autoconfigured headers
! generated by ‘configure’.  The other configuration headers are
! determined by ‘config.gcc’.  They also contain the typedefs for ‘rtx’,
! ‘rtvec’ and ‘tree’.
  
!    • ‘config.h’, for use in programs that run on the host machine.
!    • ‘bconfig.h’, for use in programs that run on the build machine.
!    • ‘tconfig.h’, for use in programs and libraries for the target
       machine.
!    • ‘tm_p.h’, which includes the header ‘MACHINE-protos.h’ that
!      contains prototypes for functions in the target ‘MACHINE.c’ file.
!      The ‘MACHINE-protos.h’ header is included after the ‘rtl.h’ and/or
!      ‘tree.h’ would have been included.  The ‘tm_p.h’ also includes the
!      header ‘tm-preds.h’ which is generated by ‘genpreds’ program during
       the build to define the declarations and inline functions for the
       predicate functions.
  
  
  File: gccint.info,  Node: Build,  Next: Makefile,  Prev: Configuration,  Up: gcc Directory
  
! 6.3.3 Build System in the ‘gcc’ Directory
  -----------------------------------------
  
  FIXME: describe the build system, including what is built in what
*************** File: gccint.info,  Node: Makefile,  Nex
*** 3433,3499 ****
  6.3.4 Makefile Targets
  ----------------------
  
! These targets are available from the 'gcc' directory:
  
! 'all'
       This is the default target.  Depending on what your
       build/host/target configuration is, it coordinates all the things
       that need to be built.
  
! 'doc'
       Produce info-formatted documentation and man pages.  Essentially it
!      calls 'make man' and 'make info'.
  
! 'dvi'
       Produce DVI-formatted documentation.
  
! 'pdf'
       Produce PDF-formatted documentation.
  
! 'html'
       Produce HTML-formatted documentation.
  
! 'man'
       Generate man pages.
  
! 'info'
       Generate info-formatted pages.
  
! 'mostlyclean'
       Delete the files made while building the compiler.
  
! 'clean'
!      That, and all the other files built by 'make all'.
  
! 'distclean'
!      That, and all the files created by 'configure'.
  
! 'maintainer-clean'
       Distclean plus any file that can be generated from other files.
       Note that additional tools may be required beyond what is normally
       needed to build GCC.
  
! 'srcextra'
       Generates files in the source directory that are not
       version-controlled but should go into a release tarball.
  
! 'srcinfo'
! 'srcman'
       Copies the info-formatted and manpage documentation into the source
       directory usually for the purpose of generating a release tarball.
  
! 'install'
       Installs GCC.
  
! 'uninstall'
       Deletes installed files, though this is not supported.
  
! 'check'
!      Run the testsuite.  This creates a 'testsuite' subdirectory that
!      has various '.sum' and '.log' files containing the results of the
!      testing.  You can run subsets with, for example, 'make check-gcc'.
!      You can specify specific tests by setting 'RUNTESTFLAGS' to be the
!      name of the '.exp' file, optionally followed by (for some tests) an
       equals and a file wildcard, like:
  
            make check-gcc RUNTESTFLAGS="execute.exp=19980413-*"
--- 3433,3499 ----
  6.3.4 Makefile Targets
  ----------------------
  
! These targets are available from the ‘gcc’ directory:
  
! ‘all’
       This is the default target.  Depending on what your
       build/host/target configuration is, it coordinates all the things
       that need to be built.
  
! ‘doc’
       Produce info-formatted documentation and man pages.  Essentially it
!      calls ‘make man’ and ‘make info’.
  
! ‘dvi’
       Produce DVI-formatted documentation.
  
! ‘pdf’
       Produce PDF-formatted documentation.
  
! ‘html’
       Produce HTML-formatted documentation.
  
! ‘man’
       Generate man pages.
  
! ‘info’
       Generate info-formatted pages.
  
! ‘mostlyclean’
       Delete the files made while building the compiler.
  
! ‘clean’
!      That, and all the other files built by ‘make all’.
  
! ‘distclean’
!      That, and all the files created by ‘configure’.
  
! ‘maintainer-clean’
       Distclean plus any file that can be generated from other files.
       Note that additional tools may be required beyond what is normally
       needed to build GCC.
  
! ‘srcextra’
       Generates files in the source directory that are not
       version-controlled but should go into a release tarball.
  
! ‘srcinfo’
! ‘srcman’
       Copies the info-formatted and manpage documentation into the source
       directory usually for the purpose of generating a release tarball.
  
! ‘install’
       Installs GCC.
  
! ‘uninstall’
       Deletes installed files, though this is not supported.
  
! ‘check’
!      Run the testsuite.  This creates a ‘testsuite’ subdirectory that
!      has various ‘.sum’ and ‘.log’ files containing the results of the
!      testing.  You can run subsets with, for example, ‘make check-gcc’.
!      You can specify specific tests by setting ‘RUNTESTFLAGS’ to be the
!      name of the ‘.exp’ file, optionally followed by (for some tests) an
       equals and a file wildcard, like:
  
            make check-gcc RUNTESTFLAGS="execute.exp=19980413-*"
*************** steps of the build, including bootstrapp
*** 3507,3517 ****
  new compiler to build target libraries.
  
   When GCC is configured for a native configuration, the default action
! for 'make' is to do a full three-stage bootstrap.  This means that GCC
  is built three times--once with the native compiler, once with the
  native-built compiler it just built, and once with the compiler it built
  the second time.  In theory, the last two should produce the same
! results, which 'make compare' can check.  Each stage is configured
  separately and compiled into a separate directory, to minimize problems
  due to ABI incompatibilities between the native compiler and GCC.
  
--- 3507,3517 ----
  new compiler to build target libraries.
  
   When GCC is configured for a native configuration, the default action
! for ‘make’ is to do a full three-stage bootstrap.  This means that GCC
  is built three times--once with the native compiler, once with the
  native-built compiler it just built, and once with the compiler it built
  the second time.  In theory, the last two should produce the same
! results, which ‘make compare’ can check.  Each stage is configured
  separately and compiled into a separate directory, to minimize problems
  due to ABI incompatibilities between the native compiler and GCC.
  
*************** mistake), and avoids spurious bootstrap
*** 3527,3606 ****
  
   Other targets available from the top level include:
  
! 'bootstrap-lean'
!      Like 'bootstrap', except that the various stages are removed once
       they're no longer needed.  This saves disk space.
  
! 'bootstrap2'
! 'bootstrap2-lean'
       Performs only the first two stages of bootstrap.  Unlike a
       three-stage bootstrap, this does not perform a comparison to test
       that the compiler is running properly.  Note that the disk space
       required by a "lean" bootstrap is approximately independent of the
       number of stages.
  
! 'stageN-bubble (N = 1...4, profile, feedback)'
       Rebuild all the stages up to N, with the appropriate flags,
       "bubbling" the changes as described above.
  
! 'all-stageN (N = 1...4, profile, feedback)'
       Assuming that stage N has already been built, rebuild it with the
       appropriate flags.  This is rarely needed.
  
! 'cleanstrap'
!      Remove everything ('make clean') and rebuilds ('make bootstrap').
  
! 'compare'
       Compares the results of stages 2 and 3.  This ensures that the
       compiler is running properly, since it should produce the same
       object files regardless of how it itself was compiled.
  
! 'distclean-stageN (N = 1...4, profile, feedback)'
       Wipe stage N and all the following ones.
  
!      For example, 'make distclean-stage3' wipes stage 3 and all the
!      following ones, so that another 'make' then rebuilds them from
       scratch.  This can be useful if you're doing changes where
       "bubbling" the changes as described above is not sufficient, but a
!      full 'make restrap' isn't necessary either.
  
! 'profiledbootstrap'
       Builds a compiler with profiling feedback information.  In this
!      case, the second and third stages are named 'profile' and
!      'feedback', respectively.  For more information, see the
       installation instructions.
  
! 'restrap'
       Restart a bootstrap, so that everything that was not built with the
       system compiler is rebuilt.
  
! 'stageN-start (N = 1...4, profile, feedback)'
       For each package that is bootstrapped, rename directories so that,
!      for example, 'gcc' points to the stageN GCC, compiled with the
       stageN-1 GCC(2).
  
       You will invoke this target if you need to test or debug the stageN
!      GCC.  If you only need to execute GCC (but you need not run 'make'
       either to rebuild it or to run test suites), you should be able to
!      work directly in the 'stageN-gcc' directory.  This makes it easier
       to debug multiple stages in parallel.
  
! 'stage'
       For each package that is bootstrapped, relocate its build directory
!      to indicate its stage.  For example, if the 'gcc' directory points
       to the stage2 GCC, after invoking this target it will be renamed to
!      'stage2-gcc'.
  
   If you wish to use non-default GCC flags when compiling the stage2 and
! stage3 compilers, set 'BOOT_CFLAGS' on the command line when doing
! 'make'.
  
   Usually, the first stage only builds the languages that the compiler is
  written in: typically, C and maybe Ada.  If you are debugging a
  miscompilation of a different stage2 front-end (for example, of the
  Fortran front-end), you may want to have front-ends for other languages
! in the first stage as well.  To do so, set 'STAGE1_LANGUAGES' on the
! command line when doing 'make'.
  
   For example, in the aforementioned scenario of debugging a Fortran
  front-end miscompilation caused by the stage1 compiler, you may need a
--- 3527,3606 ----
  
   Other targets available from the top level include:
  
! ‘bootstrap-lean’
!      Like ‘bootstrap’, except that the various stages are removed once
       they're no longer needed.  This saves disk space.
  
! ‘bootstrap2’
! ‘bootstrap2-lean’
       Performs only the first two stages of bootstrap.  Unlike a
       three-stage bootstrap, this does not perform a comparison to test
       that the compiler is running properly.  Note that the disk space
       required by a "lean" bootstrap is approximately independent of the
       number of stages.
  
! ‘stageN-bubble (N = 1...4, profile, feedback)’
       Rebuild all the stages up to N, with the appropriate flags,
       "bubbling" the changes as described above.
  
! ‘all-stageN (N = 1...4, profile, feedback)’
       Assuming that stage N has already been built, rebuild it with the
       appropriate flags.  This is rarely needed.
  
! ‘cleanstrap’
!      Remove everything (‘make clean’) and rebuilds (‘make bootstrap’).
  
! ‘compare’
       Compares the results of stages 2 and 3.  This ensures that the
       compiler is running properly, since it should produce the same
       object files regardless of how it itself was compiled.
  
! ‘distclean-stageN (N = 1...4, profile, feedback)’
       Wipe stage N and all the following ones.
  
!      For example, ‘make distclean-stage3’ wipes stage 3 and all the
!      following ones, so that another ‘make’ then rebuilds them from
       scratch.  This can be useful if you're doing changes where
       "bubbling" the changes as described above is not sufficient, but a
!      full ‘make restrap’ isn't necessary either.
  
! ‘profiledbootstrap’
       Builds a compiler with profiling feedback information.  In this
!      case, the second and third stages are named ‘profile’ and
!      ‘feedback’, respectively.  For more information, see the
       installation instructions.
  
! ‘restrap’
       Restart a bootstrap, so that everything that was not built with the
       system compiler is rebuilt.
  
! ‘stageN-start (N = 1...4, profile, feedback)’
       For each package that is bootstrapped, rename directories so that,
!      for example, ‘gcc’ points to the stageN GCC, compiled with the
       stageN-1 GCC(2).
  
       You will invoke this target if you need to test or debug the stageN
!      GCC.  If you only need to execute GCC (but you need not run ‘make’
       either to rebuild it or to run test suites), you should be able to
!      work directly in the ‘stageN-gcc’ directory.  This makes it easier
       to debug multiple stages in parallel.
  
! ‘stage’
       For each package that is bootstrapped, relocate its build directory
!      to indicate its stage.  For example, if the ‘gcc’ directory points
       to the stage2 GCC, after invoking this target it will be renamed to
!      ‘stage2-gcc’.
  
   If you wish to use non-default GCC flags when compiling the stage2 and
! stage3 compilers, set ‘BOOT_CFLAGS’ on the command line when doing
! ‘make’.
  
   Usually, the first stage only builds the languages that the compiler is
  written in: typically, C and maybe Ada.  If you are debugging a
  miscompilation of a different stage2 front-end (for example, of the
  Fortran front-end), you may want to have front-ends for other languages
! in the first stage as well.  To do so, set ‘STAGE1_LANGUAGES’ on the
! command line when doing ‘make’.
  
   For example, in the aforementioned scenario of debugging a Fortran
  front-end miscompilation caused by the stage1 compiler, you may need a
*************** command like
*** 3609,3636 ****
       make stage2-bubble STAGE1_LANGUAGES=c,fortran
  
   Alternatively, you can use per-language targets to build and test
! languages that are not enabled by default in stage1.  For example, 'make
! f951' will build a Fortran compiler even in the stage1 build directory.
  
     ---------- Footnotes ----------
  
     (1) Except if the compiler was buggy and miscompiled some of the
! files that were not modified.  In this case, it's best to use 'make
! restrap'.
  
!    (2) Customarily, the system compiler is also termed the 'stage0' GCC.
  
  
  File: gccint.info,  Node: Library Files,  Next: Headers,  Prev: Makefile,  Up: gcc Directory
  
! 6.3.5 Library Source Files and Headers under the 'gcc' Directory
  ----------------------------------------------------------------
  
  FIXME: list here, with explanation, all the C source files and headers
! under the 'gcc' directory that aren't built into the GCC executable but
  rather are part of runtime libraries and object files, such as
! 'crtstuff.c' and 'unwind-dw2.c'.  *Note Headers Installed by GCC:
! Headers, for more information about the 'ginclude' directory.
  
  
  File: gccint.info,  Node: Headers,  Next: Documentation,  Prev: Library Files,  Up: gcc Directory
--- 3609,3636 ----
       make stage2-bubble STAGE1_LANGUAGES=c,fortran
  
   Alternatively, you can use per-language targets to build and test
! languages that are not enabled by default in stage1.  For example, ‘make
! f951’ will build a Fortran compiler even in the stage1 build directory.
  
     ---------- Footnotes ----------
  
     (1) Except if the compiler was buggy and miscompiled some of the
! files that were not modified.  In this case, it's best to use ‘make
! restrap’.
  
!    (2) Customarily, the system compiler is also termed the ‘stage0’ GCC.
  
  
  File: gccint.info,  Node: Library Files,  Next: Headers,  Prev: Makefile,  Up: gcc Directory
  
! 6.3.5 Library Source Files and Headers under the ‘gcc’ Directory
  ----------------------------------------------------------------
  
  FIXME: list here, with explanation, all the C source files and headers
! under the ‘gcc’ directory that aren't built into the GCC executable but
  rather are part of runtime libraries and object files, such as
! ‘crtstuff.c’ and ‘unwind-dw2.c’.  *Note Headers Installed by GCC:
! Headers, for more information about the ‘ginclude’ directory.
  
  
  File: gccint.info,  Node: Headers,  Next: Documentation,  Prev: Library Files,  Up: gcc Directory
*************** In general, GCC expects the system C lib
*** 3642,3679 ****
  headers to be used with it.  However, GCC will fix those headers if
  necessary to make them work with GCC, and will install some headers
  required of freestanding implementations.  These headers are installed
! in 'LIBSUBDIR/include'.  Headers for non-C runtime libraries are also
  installed by GCC; these are not documented here.  (FIXME: document them
  somewhere.)
  
!  Several of the headers GCC installs are in the 'ginclude' directory.
! These headers, 'iso646.h', 'stdarg.h', 'stdbool.h', and 'stddef.h', are
! installed in 'LIBSUBDIR/include', unless the target Makefile fragment
! (*note Target Fragment::) overrides this by setting 'USER_H'.
  
   In addition to these headers and those generated by fixing system
  headers to work with GCC, some other headers may also be installed in
! 'LIBSUBDIR/include'.  'config.gcc' may set 'extra_headers'; this
! specifies additional headers under 'config' to be installed on some
  systems.
  
!  GCC installs its own version of '', from 'ginclude/float.h'.
  This is done to cope with command-line options that change the
  representation of floating point numbers.
  
!  GCC also installs its own version of ''; this is generated
! from 'glimits.h', together with 'limitx.h' and 'limity.h' if the system
! also has its own version of ''.  (GCC provides its own header
  because it is required of ISO C freestanding implementations, but needs
  to include the system header from its own header as well because other
  standards such as POSIX specify additional values to be defined in
! ''.)  The system's '' header is used via
! 'LIBSUBDIR/include/syslimits.h', which is copied from 'gsyslimits.h' if
  it does not need fixing to work with GCC; if it needs fixing,
! 'syslimits.h' is the fixed copy.
  
!  GCC can also install ''.  It will do this when 'config.gcc'
! sets 'use_gcc_tgmath' to 'yes'.
  
  
  File: gccint.info,  Node: Documentation,  Next: Front End,  Prev: Headers,  Up: gcc Directory
--- 3642,3679 ----
  headers to be used with it.  However, GCC will fix those headers if
  necessary to make them work with GCC, and will install some headers
  required of freestanding implementations.  These headers are installed
! in ‘LIBSUBDIR/include’.  Headers for non-C runtime libraries are also
  installed by GCC; these are not documented here.  (FIXME: document them
  somewhere.)
  
!  Several of the headers GCC installs are in the ‘ginclude’ directory.
! These headers, ‘iso646.h’, ‘stdarg.h’, ‘stdbool.h’, and ‘stddef.h’, are
! installed in ‘LIBSUBDIR/include’, unless the target Makefile fragment
! (*note Target Fragment::) overrides this by setting ‘USER_H’.
  
   In addition to these headers and those generated by fixing system
  headers to work with GCC, some other headers may also be installed in
! ‘LIBSUBDIR/include’.  ‘config.gcc’ may set ‘extra_headers’; this
! specifies additional headers under ‘config’ to be installed on some
  systems.
  
!  GCC installs its own version of ‘’, from ‘ginclude/float.h’.
  This is done to cope with command-line options that change the
  representation of floating point numbers.
  
!  GCC also installs its own version of ‘’; this is generated
! from ‘glimits.h’, together with ‘limitx.h’ and ‘limity.h’ if the system
! also has its own version of ‘’.  (GCC provides its own header
  because it is required of ISO C freestanding implementations, but needs
  to include the system header from its own header as well because other
  standards such as POSIX specify additional values to be defined in
! ‘’.)  The system's ‘’ header is used via
! ‘LIBSUBDIR/include/syslimits.h’, which is copied from ‘gsyslimits.h’ if
  it does not need fixing to work with GCC; if it needs fixing,
! ‘syslimits.h’ is the fixed copy.
  
!  GCC can also install ‘’.  It will do this when ‘config.gcc’
! sets ‘use_gcc_tgmath’ to ‘yes’.
  
  
  File: gccint.info,  Node: Documentation,  Next: Front End,  Prev: Headers,  Up: gcc Directory
*************** File: gccint.info,  Node: Documentation,
*** 3683,3693 ****
  
  The main GCC documentation is in the form of manuals in Texinfo format.
  These are installed in Info format; DVI versions may be generated by
! 'make dvi', PDF versions by 'make pdf', and HTML versions by 'make
! html'.  In addition, some man pages are generated from the Texinfo
  manuals, there are some other text files with miscellaneous
  documentation, and runtime libraries have their own documentation
! outside the 'gcc' directory.  FIXME: document the documentation for
  runtime libraries somewhere.
  
  * Menu:
--- 3683,3693 ----
  
  The main GCC documentation is in the form of manuals in Texinfo format.
  These are installed in Info format; DVI versions may be generated by
! ‘make dvi’, PDF versions by ‘make pdf’, and HTML versions by ‘make
! html’.  In addition, some man pages are generated from the Texinfo
  manuals, there are some other text files with miscellaneous
  documentation, and runtime libraries have their own documentation
! outside the ‘gcc’ directory.  FIXME: document the documentation for
  runtime libraries somewhere.
  
  * Menu:
*************** File: gccint.info,  Node: Texinfo Manual
*** 3703,3751 ****
  .......................
  
  The manuals for GCC as a whole, and the C and C++ front ends, are in
! files 'doc/*.texi'.  Other front ends have their own manuals in files
! 'LANGUAGE/*.texi'.  Common files 'doc/include/*.texi' are provided which
  may be included in multiple manuals; the following files are in
! 'doc/include':
  
! 'fdl.texi'
       The GNU Free Documentation License.
! 'funding.texi'
       The section "Funding Free Software".
! 'gcc-common.texi'
       Common definitions for manuals.
! 'gpl_v3.texi'
       The GNU General Public License.
! 'texinfo.tex'
!      A copy of 'texinfo.tex' known to work with the GCC manuals.
  
!  DVI-formatted manuals are generated by 'make dvi', which uses
! 'texi2dvi' (via the Makefile macro '$(TEXI2DVI)').  PDF-formatted
! manuals are generated by 'make pdf', which uses 'texi2pdf' (via the
! Makefile macro '$(TEXI2PDF)').  HTML formatted manuals are generated by
! 'make html'.  Info manuals are generated by 'make info' (which is run as
  part of a bootstrap); this generates the manuals in the source
! directory, using 'makeinfo' via the Makefile macro '$(MAKEINFO)', and
  they are included in release distributions.
  
   Manuals are also provided on the GCC web site, in both HTML and
  PostScript forms.  This is done via the script
! 'maintainer-scripts/update_web_docs_git'.  Each manual to be provided
! online must be listed in the definition of 'MANUALS' in that file; a
! file 'NAME.texi' must only appear once in the source tree, and the
  output manual must have the same name as the source file.  (However,
  other Texinfo files, included in manuals but not themselves the root
  files of manuals, may have names that appear more than once in the
! source tree.)  The manual file 'NAME.texi' should only include other
! files in its own directory or in 'doc/include'.  HTML manuals will be
! generated by 'makeinfo --html', PostScript manuals by 'texi2dvi' and
! 'dvips', and PDF manuals by 'texi2pdf'.  All Texinfo files that are
  parts of manuals must be version-controlled, even if they are generated
  files, for the generation of online manuals to work.
  
!  The installation manual, 'doc/install.texi', is also provided on the
  GCC web site.  The HTML version is generated by the script
! 'doc/install.texi2html'.
  
  
  File: gccint.info,  Node: Man Page Generation,  Next: Miscellaneous Docs,  Prev: Texinfo Manuals,  Up: Documentation
--- 3703,3751 ----
  .......................
  
  The manuals for GCC as a whole, and the C and C++ front ends, are in
! files ‘doc/*.texi’.  Other front ends have their own manuals in files
! ‘LANGUAGE/*.texi’.  Common files ‘doc/include/*.texi’ are provided which
  may be included in multiple manuals; the following files are in
! ‘doc/include’:
  
! ‘fdl.texi’
       The GNU Free Documentation License.
! ‘funding.texi’
       The section "Funding Free Software".
! ‘gcc-common.texi’
       Common definitions for manuals.
! ‘gpl_v3.texi’
       The GNU General Public License.
! ‘texinfo.tex’
!      A copy of ‘texinfo.tex’ known to work with the GCC manuals.
  
!  DVI-formatted manuals are generated by ‘make dvi’, which uses
! ‘texi2dvi’ (via the Makefile macro ‘$(TEXI2DVI)’).  PDF-formatted
! manuals are generated by ‘make pdf’, which uses ‘texi2pdf’ (via the
! Makefile macro ‘$(TEXI2PDF)’).  HTML formatted manuals are generated by
! ‘make html’.  Info manuals are generated by ‘make info’ (which is run as
  part of a bootstrap); this generates the manuals in the source
! directory, using ‘makeinfo’ via the Makefile macro ‘$(MAKEINFO)’, and
  they are included in release distributions.
  
   Manuals are also provided on the GCC web site, in both HTML and
  PostScript forms.  This is done via the script
! ‘maintainer-scripts/update_web_docs_git’.  Each manual to be provided
! online must be listed in the definition of ‘MANUALS’ in that file; a
! file ‘NAME.texi’ must only appear once in the source tree, and the
  output manual must have the same name as the source file.  (However,
  other Texinfo files, included in manuals but not themselves the root
  files of manuals, may have names that appear more than once in the
! source tree.)  The manual file ‘NAME.texi’ should only include other
! files in its own directory or in ‘doc/include’.  HTML manuals will be
! generated by ‘makeinfo --html’, PostScript manuals by ‘texi2dvi’ and
! ‘dvips’, and PDF manuals by ‘texi2pdf’.  All Texinfo files that are
  parts of manuals must be version-controlled, even if they are generated
  files, for the generation of online manuals to work.
  
!  The installation manual, ‘doc/install.texi’, is also provided on the
  GCC web site.  The HTML version is generated by the script
! ‘doc/install.texi2html’.
  
  
  File: gccint.info,  Node: Man Page Generation,  Next: Miscellaneous Docs,  Prev: Texinfo Manuals,  Up: Documentation
*************** File: gccint.info,  Node: Man Page Gener
*** 3755,3787 ****
  
  Because of user demand, in addition to full Texinfo manuals, man pages
  are provided which contain extracts from those manuals.  These man pages
! are generated from the Texinfo manuals using 'contrib/texi2pod.pl' and
! 'pod2man'.  (The man page for 'g++', 'cp/g++.1', just contains a '.so'
! reference to 'gcc.1', but all the other man pages are generated from
  Texinfo manuals.)
  
   Because many systems may not have the necessary tools installed to
! generate the man pages, they are only generated if the 'configure'
  script detects that recent enough tools are installed, and the Makefiles
  allow generating man pages to fail without aborting the build.  Man
  pages are also included in release distributions.  They are generated in
  the source directory.
  
!  Magic comments in Texinfo files starting '@c man' control what parts of
  a Texinfo file go into a man page.  Only a subset of Texinfo is
! supported by 'texi2pod.pl', and it may be necessary to add support for
  more Texinfo features to this script when generating new man pages.  To
  improve the man page output, some special Texinfo macros are provided in
! 'doc/include/gcc-common.texi' which 'texi2pod.pl' understands:
  
! '@gcctabopt'
!      Use in the form '@table @gcctabopt' for tables of options, where
!      for printed output the effect of '@code' is better than that of
!      '@option' but for man page output a different effect is wanted.
! '@gccoptlist'
       Use for summary lists of options in manuals.
  
!  FIXME: describe the 'texi2pod.pl' input language and magic comments in
  more detail.
  
  
--- 3755,3787 ----
  
  Because of user demand, in addition to full Texinfo manuals, man pages
  are provided which contain extracts from those manuals.  These man pages
! are generated from the Texinfo manuals using ‘contrib/texi2pod.pl’ and
! ‘pod2man’.  (The man page for ‘g++’, ‘cp/g++.1’, just contains a ‘.so’
! reference to ‘gcc.1’, but all the other man pages are generated from
  Texinfo manuals.)
  
   Because many systems may not have the necessary tools installed to
! generate the man pages, they are only generated if the ‘configure’
  script detects that recent enough tools are installed, and the Makefiles
  allow generating man pages to fail without aborting the build.  Man
  pages are also included in release distributions.  They are generated in
  the source directory.
  
!  Magic comments in Texinfo files starting ‘@c man’ control what parts of
  a Texinfo file go into a man page.  Only a subset of Texinfo is
! supported by ‘texi2pod.pl’, and it may be necessary to add support for
  more Texinfo features to this script when generating new man pages.  To
  improve the man page output, some special Texinfo macros are provided in
! ‘doc/include/gcc-common.texi’ which ‘texi2pod.pl’ understands:
  
! ‘@gcctabopt’
!      Use in the form ‘@table @gcctabopt’ for tables of options, where
!      for printed output the effect of ‘@code’ is better than that of
!      ‘@option’ but for man page output a different effect is wanted.
! ‘@gccoptlist’
       Use for summary lists of options in manuals.
  
!  FIXME: describe the ‘texi2pod.pl’ input language and magic comments in
  more detail.
  
  
*************** File: gccint.info,  Node: Miscellaneous
*** 3791,3827 ****
  ...................................
  
  In addition to the formal documentation that is installed by GCC, there
! are several other text files in the 'gcc' subdirectory with
  miscellaneous documentation:
  
! 'ABOUT-GCC-NLS'
       Notes on GCC's Native Language Support.  FIXME: this should be part
       of this manual rather than a separate file.
! 'ABOUT-NLS'
       Notes on the Free Translation Project.
! 'COPYING'
! 'COPYING3'
       The GNU General Public License, Versions 2 and 3.
! 'COPYING.LIB'
! 'COPYING3.LIB'
       The GNU Lesser General Public License, Versions 2.1 and 3.
! '*ChangeLog*'
! '*/ChangeLog*'
       Change log files for various parts of GCC.
! 'LANGUAGES'
       Details of a few changes to the GCC front-end interface.  FIXME:
       the information in this file should be part of general
       documentation of the front-end interface in this manual.
! 'ONEWS'
       Information about new features in old versions of GCC.  (For recent
       versions, the information is on the GCC web site.)
! 'README.Portability'
       Information about portability issues when writing code in GCC.
       FIXME: why isn't this part of this manual or of the GCC Coding
       Conventions?
  
!  FIXME: document such files in subdirectories, at least 'config', 'c',
! 'cp', 'objc', 'testsuite'.
  
  
  File: gccint.info,  Node: Front End,  Next: Back End,  Prev: Documentation,  Up: gcc Directory
--- 3791,3827 ----
  ...................................
  
  In addition to the formal documentation that is installed by GCC, there
! are several other text files in the ‘gcc’ subdirectory with
  miscellaneous documentation:
  
! ‘ABOUT-GCC-NLS’
       Notes on GCC's Native Language Support.  FIXME: this should be part
       of this manual rather than a separate file.
! ‘ABOUT-NLS’
       Notes on the Free Translation Project.
! ‘COPYING’
! ‘COPYING3’
       The GNU General Public License, Versions 2 and 3.
! ‘COPYING.LIB’
! ‘COPYING3.LIB’
       The GNU Lesser General Public License, Versions 2.1 and 3.
! ‘*ChangeLog*’
! ‘*/ChangeLog*’
       Change log files for various parts of GCC.
! ‘LANGUAGES’
       Details of a few changes to the GCC front-end interface.  FIXME:
       the information in this file should be part of general
       documentation of the front-end interface in this manual.
! ‘ONEWS’
       Information about new features in old versions of GCC.  (For recent
       versions, the information is on the GCC web site.)
! ‘README.Portability’
       Information about portability issues when writing code in GCC.
       FIXME: why isn't this part of this manual or of the GCC Coding
       Conventions?
  
!  FIXME: document such files in subdirectories, at least ‘config’, ‘c’,
! ‘cp’, ‘objc’, ‘testsuite’.
  
  
  File: gccint.info,  Node: Front End,  Next: Back End,  Prev: Documentation,  Up: gcc Directory
*************** File: gccint.info,  Node: Front End,  Ne
*** 3831,4077 ****
  
  A front end for a language in GCC has the following parts:
  
!    * A directory 'LANGUAGE' under 'gcc' containing source files for that
!      front end.  *Note The Front End 'LANGUAGE' Directory: Front End
       Directory, for details.
!    * A mention of the language in the list of supported languages in
!      'gcc/doc/install.texi'.
!    * A mention of the name under which the language's runtime library is
!      recognized by '--enable-shared=PACKAGE' in the documentation of
!      that option in 'gcc/doc/install.texi'.
!    * A mention of any special prerequisites for building the front end
!      in the documentation of prerequisites in 'gcc/doc/install.texi'.
!    * Details of contributors to that front end in
!      'gcc/doc/contrib.texi'.  If the details are in that front end's own
       manual then there should be a link to that manual's list in
!      'contrib.texi'.
!    * Information about support for that language in
!      'gcc/doc/frontends.texi'.
!    * Information about standards for that language, and the front end's
!      support for them, in 'gcc/doc/standards.texi'.  This may be a link
       to such information in the front end's own manual.
!    * Details of source file suffixes for that language and '-x LANG'
!      options supported, in 'gcc/doc/invoke.texi'.
!    * Entries in 'default_compilers' in 'gcc.cc' for source file suffixes
       for that language.
!    * Preferably testsuites, which may be under 'gcc/testsuite' or
       runtime library directories.  FIXME: document somewhere how to
       write testsuite harnesses.
!    * Probably a runtime library for the language, outside the 'gcc'
       directory.  FIXME: document this further.
!    * Details of the directories of any runtime libraries in
!      'gcc/doc/sourcebuild.texi'.
!    * Check targets in 'Makefile.def' for the top-level 'Makefile' to
       check just the compiler or the compiler and runtime library for the
       language.
  
   If the front end is added to the official GCC source repository, the
  following are also necessary:
  
!    * At least one Bugzilla component for bugs in that front end and
       runtime libraries.  This category needs to be added to the Bugzilla
       database.
!    * Normally, one or more maintainers of that front end listed in
!      'MAINTAINERS'.
!    * Mentions on the GCC web site in 'index.html' and 'frontends.html',
!      with any relevant links on 'readings.html'.  (Front ends that are
!      not an official part of GCC may also be listed on 'frontends.html',
       with relevant links.)
!    * A news item on 'index.html', and possibly an announcement on the
        mailing list.
!    * The front end's manuals should be mentioned in
!      'maintainer-scripts/update_web_docs_git' (*note Texinfo Manuals::)
       and the online manuals should be linked to from
!      'onlinedocs/index.html'.
!    * Any old releases or CVS repositories of the front end, before its
       inclusion in GCC, should be made available on the GCC web site at
       .
!    * The release and snapshot script 'maintainer-scripts/gcc_release'
       should be updated to generate appropriate tarballs for this front
       end.
!    * If this front end includes its own version files that include the
!      current date, 'maintainer-scripts/update_version' should be updated
       accordingly.
  
  * Menu:
  
! * Front End Directory::  The front end 'LANGUAGE' directory.
! * Front End Config::     The front end 'config-lang.in' file.
! * Front End Makefile::   The front end 'Make-lang.in' file.
  
  
  File: gccint.info,  Node: Front End Directory,  Next: Front End Config,  Up: Front End
  
! 6.3.8.1 The Front End 'LANGUAGE' Directory
  ..........................................
  
! A front end 'LANGUAGE' directory contains the source files of that front
! end (but not of any runtime libraries, which should be outside the 'gcc'
  directory).  This includes documentation, and possibly some subsidiary
  programs built alongside the front end.  Certain files are special and
  other parts of the compiler depend on their names:
  
! 'config-lang.in'
       This file is required in all language subdirectories.  *Note The
!      Front End 'config-lang.in' File: Front End Config, for details of
       its contents
! 'Make-lang.in'
       This file is required in all language subdirectories.  *Note The
!      Front End 'Make-lang.in' File: Front End Makefile, for details of
       its contents.
! 'lang.opt'
       This file registers the set of switches that the front end accepts
!      on the command line, and their '--help' text.  *Note Options::.
! 'lang-specs.h'
!      This file provides entries for 'default_compilers' in 'gcc.cc'
       which override the default of giving an error that a compiler for
       that language is not installed.
! 'LANGUAGE-tree.def'
       This file, which need not exist, defines any language-specific tree
       codes.
  
  
  File: gccint.info,  Node: Front End Config,  Next: Front End Makefile,  Prev: Front End Directory,  Up: Front End
  
! 6.3.8.2 The Front End 'config-lang.in' File
  ...........................................
  
! Each language subdirectory contains a 'config-lang.in' file.  This file
  is a shell script that may define some variables describing the
  language:
  
! 'language'
       This definition must be present, and gives the name of the language
!      for some purposes such as arguments to '--enable-languages'.
! 'lang_requires'
       If defined, this variable lists (space-separated) language front
       ends other than C that this front end requires to be enabled (with
!      the names given being their 'language' settings).  For example, the
       Obj-C++ front end depends on the C++ and ObjC front ends, so sets
!      'lang_requires="objc c++"'.
! 'subdir_requires'
       If defined, this variable lists (space-separated) front end
       directories other than C that this front end requires to be
       present.  For example, the Objective-C++ front end uses source
       files from the C++ and Objective-C front ends, so sets
!      'subdir_requires="cp objc"'.
! 'target_libs'
       If defined, this variable lists (space-separated) targets in the
!      top level 'Makefile' to build the runtime libraries for this
!      language, such as 'target-libobjc'.
! 'lang_dirs'
       If defined, this variable lists (space-separated) top level
!      directories (parallel to 'gcc'), apart from the runtime libraries,
       that should not be configured if this front end is not built.
! 'build_by_default'
!      If defined to 'no', this language front end is not built unless
!      enabled in a '--enable-languages' argument.  Otherwise, front ends
       are built by default, subject to any special logic in
!      'configure.ac' (as is present to disable the Ada front end if the
       Ada compiler is not already installed).
! 'boot_language'
!      If defined to 'yes', this front end is built in stage1 of the
       bootstrap.  This is only relevant to front ends written in their
       own languages.
! 'compilers'
       If defined, a space-separated list of compiler executables that
       will be run by the driver.  The names here will each end with
!      '\$(exeext)'.
! 'outputs'
       If defined, a space-separated list of files that should be
!      generated by 'configure' substituting values in them.  This
!      mechanism can be used to create a file 'LANGUAGE/Makefile' from
!      'LANGUAGE/Makefile.in', but this is deprecated, building everything
!      from the single 'gcc/Makefile' is preferred.
! 'gtfiles'
       If defined, a space-separated list of files that should be scanned
!      by 'gengtype.cc' to generate the garbage collection tables and
       routines for this language.  This excludes the files that are
       common to all front ends.  *Note Type Information::.
  
  
  File: gccint.info,  Node: Front End Makefile,  Prev: Front End Config,  Up: Front End
  
! 6.3.8.3 The Front End 'Make-lang.in' File
  .........................................
  
! Each language subdirectory contains a 'Make-lang.in' file.  It contains
! targets 'LANG.HOOK' (where 'LANG' is the setting of 'language' in
! 'config-lang.in') for the following values of 'HOOK', and any other
  Makefile rules required to build those targets (which may if necessary
! use other Makefiles specified in 'outputs' in 'config-lang.in', although
  this is deprecated).  It also adds any testsuite targets that can use
! the standard rule in 'gcc/Makefile.in' to the variable 'lang_checks'.
  
! 'all.cross'
! 'start.encap'
! 'rest.encap'
       FIXME: exactly what goes in each of these targets?
! 'tags'
!      Build an 'etags' 'TAGS' file in the language subdirectory in the
       source tree.
! 'info'
       Build info documentation for the front end, in the build directory.
!      This target is only called by 'make bootstrap' if a suitable
!      version of 'makeinfo' is available, so does not need to check for
       this, and should fail if an error occurs.
! 'dvi'
       Build DVI documentation for the front end, in the build directory.
!      This should be done using '$(TEXI2DVI)', with appropriate '-I'
       arguments pointing to directories of included files.
! 'pdf'
       Build PDF documentation for the front end, in the build directory.
!      This should be done using '$(TEXI2PDF)', with appropriate '-I'
       arguments pointing to directories of included files.
! 'html'
       Build HTML documentation for the front end, in the build directory.
! 'man'
       Build generated man pages for the front end from Texinfo manuals
       (*note Man Page Generation::), in the build directory.  This target
       is only called if the necessary tools are available, but should
       ignore errors so as not to stop the build if errors occur; man
       pages are optional and the tools involved may be installed in a
       broken way.
! 'install-common'
       Install everything that is part of the front end, apart from the
!      compiler executables listed in 'compilers' in 'config-lang.in'.
! 'install-info'
       Install info documentation for the front end, if it is present in
       the source directory.  This target should have dependencies on info
       files that should be installed.
! 'install-man'
       Install man pages for the front end.  This target should ignore
       errors.
! 'install-plugin'
       Install headers needed for plugins.
! 'srcextra'
       Copies its dependencies into the source directory.  This generally
       should be used for generated files such as Bison output files which
       are not version-controlled, but should be included in any release
       tarballs.  This target will be executed during a bootstrap if
!      '--enable-generated-files-in-srcdir' was specified as a 'configure'
       option.
! 'srcinfo'
! 'srcman'
       Copies its dependencies into the source directory.  These targets
       will be executed during a bootstrap if
!      '--enable-generated-files-in-srcdir' was specified as a 'configure'
       option.
! 'uninstall'
       Uninstall files installed by installing the compiler.  This is
       currently documented not to be supported, so the hook need not do
       anything.
! 'mostlyclean'
! 'clean'
! 'distclean'
! 'maintainer-clean'
!      The language parts of the standard GNU '*clean' targets.  *Note
       Standard Targets for Users: (standards)Standard Targets, for
!      details of the standard targets.  For GCC, 'maintainer-clean'
       should delete all generated files in the source directory that are
       not version-controlled, but should not delete anything that is.
  
!  'Make-lang.in' must also define a variable 'LANG_OBJS' to a list of
  host object files that are used by that language.
  
  
--- 3831,4077 ----
  
  A front end for a language in GCC has the following parts:
  
!    • A directory ‘LANGUAGE’ under ‘gcc’ containing source files for that
!      front end.  *Note The Front End ‘LANGUAGE’ Directory: Front End
       Directory, for details.
!    • A mention of the language in the list of supported languages in
!      ‘gcc/doc/install.texi’.
!    • A mention of the name under which the language's runtime library is
!      recognized by ‘--enable-shared=PACKAGE’ in the documentation of
!      that option in ‘gcc/doc/install.texi’.
!    • A mention of any special prerequisites for building the front end
!      in the documentation of prerequisites in ‘gcc/doc/install.texi’.
!    • Details of contributors to that front end in
!      ‘gcc/doc/contrib.texi’.  If the details are in that front end's own
       manual then there should be a link to that manual's list in
!      ‘contrib.texi’.
!    • Information about support for that language in
!      ‘gcc/doc/frontends.texi’.
!    • Information about standards for that language, and the front end's
!      support for them, in ‘gcc/doc/standards.texi’.  This may be a link
       to such information in the front end's own manual.
!    • Details of source file suffixes for that language and ‘-x LANG’
!      options supported, in ‘gcc/doc/invoke.texi’.
!    • Entries in ‘default_compilers’ in ‘gcc.cc’ for source file suffixes
       for that language.
!    • Preferably testsuites, which may be under ‘gcc/testsuite’ or
       runtime library directories.  FIXME: document somewhere how to
       write testsuite harnesses.
!    • Probably a runtime library for the language, outside the ‘gcc’
       directory.  FIXME: document this further.
!    • Details of the directories of any runtime libraries in
!      ‘gcc/doc/sourcebuild.texi’.
!    • Check targets in ‘Makefile.def’ for the top-level ‘Makefile’ to
       check just the compiler or the compiler and runtime library for the
       language.
  
   If the front end is added to the official GCC source repository, the
  following are also necessary:
  
!    • At least one Bugzilla component for bugs in that front end and
       runtime libraries.  This category needs to be added to the Bugzilla
       database.
!    • Normally, one or more maintainers of that front end listed in
!      ‘MAINTAINERS’.
!    • Mentions on the GCC web site in ‘index.html’ and ‘frontends.html’,
!      with any relevant links on ‘readings.html’.  (Front ends that are
!      not an official part of GCC may also be listed on ‘frontends.html’,
       with relevant links.)
!    • A news item on ‘index.html’, and possibly an announcement on the
        mailing list.
!    • The front end's manuals should be mentioned in
!      ‘maintainer-scripts/update_web_docs_git’ (*note Texinfo Manuals::)
       and the online manuals should be linked to from
!      ‘onlinedocs/index.html’.
!    • Any old releases or CVS repositories of the front end, before its
       inclusion in GCC, should be made available on the GCC web site at
       .
!    • The release and snapshot script ‘maintainer-scripts/gcc_release’
       should be updated to generate appropriate tarballs for this front
       end.
!    • If this front end includes its own version files that include the
!      current date, ‘maintainer-scripts/update_version’ should be updated
       accordingly.
  
  * Menu:
  
! * Front End Directory::  The front end ‘LANGUAGE’ directory.
! * Front End Config::     The front end ‘config-lang.in’ file.
! * Front End Makefile::   The front end ‘Make-lang.in’ file.
  
  
  File: gccint.info,  Node: Front End Directory,  Next: Front End Config,  Up: Front End
  
! 6.3.8.1 The Front End ‘LANGUAGE’ Directory
  ..........................................
  
! A front end ‘LANGUAGE’ directory contains the source files of that front
! end (but not of any runtime libraries, which should be outside the ‘gcc’
  directory).  This includes documentation, and possibly some subsidiary
  programs built alongside the front end.  Certain files are special and
  other parts of the compiler depend on their names:
  
! ‘config-lang.in’
       This file is required in all language subdirectories.  *Note The
!      Front End ‘config-lang.in’ File: Front End Config, for details of
       its contents
! ‘Make-lang.in’
       This file is required in all language subdirectories.  *Note The
!      Front End ‘Make-lang.in’ File: Front End Makefile, for details of
       its contents.
! ‘lang.opt’
       This file registers the set of switches that the front end accepts
!      on the command line, and their ‘--help’ text.  *Note Options::.
! ‘lang-specs.h’
!      This file provides entries for ‘default_compilers’ in ‘gcc.cc’
       which override the default of giving an error that a compiler for
       that language is not installed.
! ‘LANGUAGE-tree.def’
       This file, which need not exist, defines any language-specific tree
       codes.
  
  
  File: gccint.info,  Node: Front End Config,  Next: Front End Makefile,  Prev: Front End Directory,  Up: Front End
  
! 6.3.8.2 The Front End ‘config-lang.in’ File
  ...........................................
  
! Each language subdirectory contains a ‘config-lang.in’ file.  This file
  is a shell script that may define some variables describing the
  language:
  
! ‘language’
       This definition must be present, and gives the name of the language
!      for some purposes such as arguments to ‘--enable-languages’.
! ‘lang_requires’
       If defined, this variable lists (space-separated) language front
       ends other than C that this front end requires to be enabled (with
!      the names given being their ‘language’ settings).  For example, the
       Obj-C++ front end depends on the C++ and ObjC front ends, so sets
!      ‘lang_requires="objc c++"’.
! ‘subdir_requires’
       If defined, this variable lists (space-separated) front end
       directories other than C that this front end requires to be
       present.  For example, the Objective-C++ front end uses source
       files from the C++ and Objective-C front ends, so sets
!      ‘subdir_requires="cp objc"’.
! ‘target_libs’
       If defined, this variable lists (space-separated) targets in the
!      top level ‘Makefile’ to build the runtime libraries for this
!      language, such as ‘target-libobjc’.
! ‘lang_dirs’
       If defined, this variable lists (space-separated) top level
!      directories (parallel to ‘gcc’), apart from the runtime libraries,
       that should not be configured if this front end is not built.
! ‘build_by_default’
!      If defined to ‘no’, this language front end is not built unless
!      enabled in a ‘--enable-languages’ argument.  Otherwise, front ends
       are built by default, subject to any special logic in
!      ‘configure.ac’ (as is present to disable the Ada front end if the
       Ada compiler is not already installed).
! ‘boot_language’
!      If defined to ‘yes’, this front end is built in stage1 of the
       bootstrap.  This is only relevant to front ends written in their
       own languages.
! ‘compilers’
       If defined, a space-separated list of compiler executables that
       will be run by the driver.  The names here will each end with
!      ‘\$(exeext)’.
! ‘outputs’
       If defined, a space-separated list of files that should be
!      generated by ‘configure’ substituting values in them.  This
!      mechanism can be used to create a file ‘LANGUAGE/Makefile’ from
!      ‘LANGUAGE/Makefile.in’, but this is deprecated, building everything
!      from the single ‘gcc/Makefile’ is preferred.
! ‘gtfiles’
       If defined, a space-separated list of files that should be scanned
!      by ‘gengtype.cc’ to generate the garbage collection tables and
       routines for this language.  This excludes the files that are
       common to all front ends.  *Note Type Information::.
  
  
  File: gccint.info,  Node: Front End Makefile,  Prev: Front End Config,  Up: Front End
  
! 6.3.8.3 The Front End ‘Make-lang.in’ File
  .........................................
  
! Each language subdirectory contains a ‘Make-lang.in’ file.  It contains
! targets ‘LANG.HOOK’ (where ‘LANG’ is the setting of ‘language’ in
! ‘config-lang.in’) for the following values of ‘HOOK’, and any other
  Makefile rules required to build those targets (which may if necessary
! use other Makefiles specified in ‘outputs’ in ‘config-lang.in’, although
  this is deprecated).  It also adds any testsuite targets that can use
! the standard rule in ‘gcc/Makefile.in’ to the variable ‘lang_checks’.
  
! ‘all.cross’
! ‘start.encap’
! ‘rest.encap’
       FIXME: exactly what goes in each of these targets?
! ‘tags’
!      Build an ‘etags’ ‘TAGS’ file in the language subdirectory in the
       source tree.
! ‘info’
       Build info documentation for the front end, in the build directory.
!      This target is only called by ‘make bootstrap’ if a suitable
!      version of ‘makeinfo’ is available, so does not need to check for
       this, and should fail if an error occurs.
! ‘dvi’
       Build DVI documentation for the front end, in the build directory.
!      This should be done using ‘$(TEXI2DVI)’, with appropriate ‘-I’
       arguments pointing to directories of included files.
! ‘pdf’
       Build PDF documentation for the front end, in the build directory.
!      This should be done using ‘$(TEXI2PDF)’, with appropriate ‘-I’
       arguments pointing to directories of included files.
! ‘html’
       Build HTML documentation for the front end, in the build directory.
! ‘man’
       Build generated man pages for the front end from Texinfo manuals
       (*note Man Page Generation::), in the build directory.  This target
       is only called if the necessary tools are available, but should
       ignore errors so as not to stop the build if errors occur; man
       pages are optional and the tools involved may be installed in a
       broken way.
! ‘install-common’
       Install everything that is part of the front end, apart from the
!      compiler executables listed in ‘compilers’ in ‘config-lang.in’.
! ‘install-info’
       Install info documentation for the front end, if it is present in
       the source directory.  This target should have dependencies on info
       files that should be installed.
! ‘install-man’
       Install man pages for the front end.  This target should ignore
       errors.
! ‘install-plugin’
       Install headers needed for plugins.
! ‘srcextra’
       Copies its dependencies into the source directory.  This generally
       should be used for generated files such as Bison output files which
       are not version-controlled, but should be included in any release
       tarballs.  This target will be executed during a bootstrap if
!      ‘--enable-generated-files-in-srcdir’ was specified as a ‘configure’
       option.
! ‘srcinfo’
! ‘srcman’
       Copies its dependencies into the source directory.  These targets
       will be executed during a bootstrap if
!      ‘--enable-generated-files-in-srcdir’ was specified as a ‘configure’
       option.
! ‘uninstall’
       Uninstall files installed by installing the compiler.  This is
       currently documented not to be supported, so the hook need not do
       anything.
! ‘mostlyclean’
! ‘clean’
! ‘distclean’
! ‘maintainer-clean’
!      The language parts of the standard GNU ‘*clean’ targets.  *Note
       Standard Targets for Users: (standards)Standard Targets, for
!      details of the standard targets.  For GCC, ‘maintainer-clean’
       should delete all generated files in the source directory that are
       not version-controlled, but should not delete anything that is.
  
!  ‘Make-lang.in’ must also define a variable ‘LANG_OBJS’ to a list of
  host object files that are used by that language.
  
  
*************** File: gccint.info,  Node: Back End,  Pre
*** 4082,4172 ****
  
  A back end for a target architecture in GCC has the following parts:
  
!    * A directory 'MACHINE' under 'gcc/config', containing a machine
!      description 'MACHINE.md' file (*note Machine Descriptions: Machine
!      Desc.), header files 'MACHINE.h' and 'MACHINE-protos.h' and a
!      source file 'MACHINE.c' (*note Target Description Macros and
       Functions: Target Macros.), possibly a target Makefile fragment
!      't-MACHINE' (*note The Target Makefile Fragment: Target Fragment.),
       and maybe some other files.  The names of these files may be
       changed from the defaults given by explicit specifications in
!      'config.gcc'.
!    * If necessary, a file 'MACHINE-modes.def' in the 'MACHINE'
       directory, containing additional machine modes to represent
       condition codes.  *Note Condition Code::, for further details.
!    * An optional 'MACHINE.opt' file in the 'MACHINE' directory,
       containing a list of target-specific options.  You can also add
!      other option files using the 'extra_options' variable in
!      'config.gcc'.  *Note Options::.
!    * Entries in 'config.gcc' (*note The 'config.gcc' File: System
       Config.) for the systems with this target architecture.
!    * Documentation in 'gcc/doc/invoke.texi' for any command-line options
       supported by this target (*note Run-time Target Specification:
       Run-time Target.).  This means both entries in the summary table of
       options and details of the individual options.
!    * Documentation in 'gcc/doc/extend.texi' for any target-specific
       attributes supported (*note Defining target-specific uses of
!      '__attribute__': Target Attributes.), including where the same
       attribute is already supported on some targets, which are
       enumerated in the manual.
!    * Documentation in 'gcc/doc/extend.texi' for any target-specific
       pragmas supported.
!    * Documentation in 'gcc/doc/extend.texi' of any target-specific
       built-in functions supported.
!    * Documentation in 'gcc/doc/extend.texi' of any target-specific
       format checking styles supported.
!    * Documentation in 'gcc/doc/md.texi' of any target-specific
       constraint letters (*note Constraints for Particular Machines:
       Machine Constraints.).
!    * A note in 'gcc/doc/contrib.texi' under the person or people who
       contributed the target support.
!    * Entries in 'gcc/doc/install.texi' for all target triplets supported
       with this target architecture, giving details of any special notes
       about installation for this target, or saying that there are no
       special notes if there are none.
!    * Possibly other support outside the 'gcc' directory for runtime
!      libraries.  FIXME: reference docs for this.  The 'libstdc++'
       porting manual needs to be installed as info for this to work, or
       to be a chapter of this manual.
  
!  The 'MACHINE.h' header is included very early in GCC's standard
! sequence of header files, while 'MACHINE-protos.h' is included late in
! the sequence.  Thus 'MACHINE-protos.h' can include declarations
! referencing types that are not defined when 'MACHINE.h' is included,
! specifically including those from 'rtl.h' and 'tree.h'.  Since both RTL
  and tree types may not be available in every context where
! 'MACHINE-protos.h' is included, in this file you should guard
! declarations using these types inside appropriate '#ifdef RTX_CODE' or
! '#ifdef TREE_CODE' conditional code segments.
  
!  If the backend uses shared data structures that require 'GTY' markers
  for garbage collection (*note Type Information::), you must declare
! those in 'MACHINE.h' rather than 'MACHINE-protos.h'.  Any definitions
! required for building libgcc must also go in 'MACHINE.h'.
  
!  GCC uses the macro 'IN_TARGET_CODE' to distinguish between
! machine-specific '.c' and '.cc' files and machine-independent '.c' and
! '.cc' files.  Machine-specific files should use the directive:
  
       #define IN_TARGET_CODE 1
  
!  before including 'config.h'.
  
   If the back end is added to the official GCC source repository, the
  following are also necessary:
  
!    * An entry for the target architecture in 'readings.html' on the GCC
       web site, with any relevant links.
!    * Details of the properties of the back end and target architecture
!      in 'backends.html' on the GCC web site.
!    * A news item about the contribution of support for that target
!      architecture, in 'index.html' on the GCC web site.
!    * Normally, one or more maintainers of that target listed in
!      'MAINTAINERS'.  Some existing architectures may be unmaintained,
       but it would be unusual to add support for a target that does not
       have a maintainer when support is added.
!    * Target triplets covering all 'config.gcc' stanzas for the target,
!      in the list in 'contrib/config-list.mk'.
  
  
  File: gccint.info,  Node: Testsuites,  Next: Options,  Prev: Source Tree,  Up: Top
--- 4082,4172 ----
  
  A back end for a target architecture in GCC has the following parts:
  
!    • A directory ‘MACHINE’ under ‘gcc/config’, containing a machine
!      description ‘MACHINE.md’ file (*note Machine Descriptions: Machine
!      Desc.), header files ‘MACHINE.h’ and ‘MACHINE-protos.h’ and a
!      source file ‘MACHINE.c’ (*note Target Description Macros and
       Functions: Target Macros.), possibly a target Makefile fragment
!      ‘t-MACHINE’ (*note The Target Makefile Fragment: Target Fragment.),
       and maybe some other files.  The names of these files may be
       changed from the defaults given by explicit specifications in
!      ‘config.gcc’.
!    • If necessary, a file ‘MACHINE-modes.def’ in the ‘MACHINE’
       directory, containing additional machine modes to represent
       condition codes.  *Note Condition Code::, for further details.
!    • An optional ‘MACHINE.opt’ file in the ‘MACHINE’ directory,
       containing a list of target-specific options.  You can also add
!      other option files using the ‘extra_options’ variable in
!      ‘config.gcc’.  *Note Options::.
!    • Entries in ‘config.gcc’ (*note The ‘config.gcc’ File: System
       Config.) for the systems with this target architecture.
!    • Documentation in ‘gcc/doc/invoke.texi’ for any command-line options
       supported by this target (*note Run-time Target Specification:
       Run-time Target.).  This means both entries in the summary table of
       options and details of the individual options.
!    • Documentation in ‘gcc/doc/extend.texi’ for any target-specific
       attributes supported (*note Defining target-specific uses of
!      ‘__attribute__’: Target Attributes.), including where the same
       attribute is already supported on some targets, which are
       enumerated in the manual.
!    • Documentation in ‘gcc/doc/extend.texi’ for any target-specific
       pragmas supported.
!    • Documentation in ‘gcc/doc/extend.texi’ of any target-specific
       built-in functions supported.
!    • Documentation in ‘gcc/doc/extend.texi’ of any target-specific
       format checking styles supported.
!    • Documentation in ‘gcc/doc/md.texi’ of any target-specific
       constraint letters (*note Constraints for Particular Machines:
       Machine Constraints.).
!    • A note in ‘gcc/doc/contrib.texi’ under the person or people who
       contributed the target support.
!    • Entries in ‘gcc/doc/install.texi’ for all target triplets supported
       with this target architecture, giving details of any special notes
       about installation for this target, or saying that there are no
       special notes if there are none.
!    • Possibly other support outside the ‘gcc’ directory for runtime
!      libraries.  FIXME: reference docs for this.  The ‘libstdc++’
       porting manual needs to be installed as info for this to work, or
       to be a chapter of this manual.
  
!  The ‘MACHINE.h’ header is included very early in GCC's standard
! sequence of header files, while ‘MACHINE-protos.h’ is included late in
! the sequence.  Thus ‘MACHINE-protos.h’ can include declarations
! referencing types that are not defined when ‘MACHINE.h’ is included,
! specifically including those from ‘rtl.h’ and ‘tree.h’.  Since both RTL
  and tree types may not be available in every context where
! ‘MACHINE-protos.h’ is included, in this file you should guard
! declarations using these types inside appropriate ‘#ifdef RTX_CODE’ or
! ‘#ifdef TREE_CODE’ conditional code segments.
  
!  If the backend uses shared data structures that require ‘GTY’ markers
  for garbage collection (*note Type Information::), you must declare
! those in ‘MACHINE.h’ rather than ‘MACHINE-protos.h’.  Any definitions
! required for building libgcc must also go in ‘MACHINE.h’.
  
!  GCC uses the macro ‘IN_TARGET_CODE’ to distinguish between
! machine-specific ‘.c’ and ‘.cc’ files and machine-independent ‘.c’ and
! ‘.cc’ files.  Machine-specific files should use the directive:
  
       #define IN_TARGET_CODE 1
  
!  before including ‘config.h’.
  
   If the back end is added to the official GCC source repository, the
  following are also necessary:
  
!    • An entry for the target architecture in ‘readings.html’ on the GCC
       web site, with any relevant links.
!    • Details of the properties of the back end and target architecture
!      in ‘backends.html’ on the GCC web site.
!    • A news item about the contribution of support for that target
!      architecture, in ‘index.html’ on the GCC web site.
!    • Normally, one or more maintainers of that target listed in
!      ‘MAINTAINERS’.  Some existing architectures may be unmaintained,
       but it would be unusual to add support for a target that does not
       have a maintainer when support is added.
!    • Target triplets covering all ‘config.gcc’ stanzas for the target,
!      in the list in ‘contrib/config-list.mk’.
  
  
  File: gccint.info,  Node: Testsuites,  Next: Options,  Prev: Source Tree,  Up: Top
*************** File: gccint.info,  Node: Test Idioms,
*** 4199,4211 ****
  7.1 Idioms Used in Testsuite Code
  =================================
  
! In general, C testcases have a trailing '-N.c', starting with '-1.c', in
  case other testcases with similar names are added later.  If the test is
  a test of some well-defined feature, it should have a name referring to
! that feature such as 'FEATURE-1.c'.  If it does not test a well-defined
  feature but just happens to exercise a bug somewhere in the compiler,
  and a bug report has been filed for this bug in the GCC bug database,
! 'prBUG-NUMBER-1.c' is the appropriate form of name.  Otherwise (for
  miscellaneous bugs not filed in the GCC bug database), and previously
  more generally, test cases are named after the date on which they were
  added.  This allows people to tell at a glance whether a test failure is
--- 4199,4211 ----
  7.1 Idioms Used in Testsuite Code
  =================================
  
! In general, C testcases have a trailing ‘-N.c’, starting with ‘-1.c’, in
  case other testcases with similar names are added later.  If the test is
  a test of some well-defined feature, it should have a name referring to
! that feature such as ‘FEATURE-1.c’.  If it does not test a well-defined
  feature but just happens to exercise a bug somewhere in the compiler,
  and a bug report has been filed for this bug in the GCC bug database,
! ‘prBUG-NUMBER-1.c’ is the appropriate form of name.  Otherwise (for
  miscellaneous bugs not filed in the GCC bug database), and previously
  more generally, test cases are named after the date on which they were
  added.  This allows people to tell at a glance whether a test failure is
*************** it may be a regression, but does not giv
*** 4214,4223 ****
  the bug or where discussion of it may be found.  Some other language
  testsuites follow similar conventions.
  
!  In the 'gcc.dg' testsuite, it is often necessary to test that an error
  is indeed a hard error and not just a warning--for example, where it is
  a constraint violation in the C standard, which must become an error
! with '-pedantic-errors'.  The following idiom, where the first line
  shown is line LINE of the file and the line that generates the error, is
  used for this:
  
--- 4214,4223 ----
  the bug or where discussion of it may be found.  Some other language
  testsuites follow similar conventions.
  
!  In the ‘gcc.dg’ testsuite, it is often necessary to test that an error
  is indeed a hard error and not just a warning--for example, where it is
  a constraint violation in the C standard, which must become an error
! with ‘-pedantic-errors’.  The following idiom, where the first line
  shown is line LINE of the file and the line that generates the error, is
  used for this:
  
*************** used for this:
*** 4225,4240 ****
       /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */
  
   It may be necessary to check that an expression is an integer constant
! expression and has a certain value.  To check that 'E' has value 'V', an
  idiom similar to the following is used:
  
       char x[((E) == (V) ? 1 : -1)];
  
!  In 'gcc.dg' tests, '__typeof__' is sometimes used to make assertions
  about the types of expressions.  See, for example,
! 'gcc.dg/c99-condexpr-1.c'.  The more subtle uses depend on the exact
  rules for the types of conditional expressions in the C standard; see,
! for example, 'gcc.dg/c99-intconst-1.c'.
  
   It is useful to be able to test that optimizations are being made
  properly.  This cannot be done in all cases, but it can be done where
--- 4225,4240 ----
       /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */
  
   It may be necessary to check that an expression is an integer constant
! expression and has a certain value.  To check that ‘E’ has value ‘V’, an
  idiom similar to the following is used:
  
       char x[((E) == (V) ? 1 : -1)];
  
!  In ‘gcc.dg’ tests, ‘__typeof__’ is sometimes used to make assertions
  about the types of expressions.  See, for example,
! ‘gcc.dg/c99-condexpr-1.c’.  The more subtle uses depend on the exact
  rules for the types of conditional expressions in the C standard; see,
! for example, ‘gcc.dg/c99-intconst-1.c’.
  
   It is useful to be able to test that optimizations are being made
  properly.  This cannot be done in all cases, but it can be done where
*************** the optimization will lead to code being
*** 4242,4249 ****
  where flow analysis or alias analysis should show that certain code
  cannot be called) or to functions not being called because they have
  been expanded as built-in functions.  Such tests go in
! 'gcc.c-torture/execute'.  Where code should be optimized away, a call to
! a nonexistent function such as 'link_failure ()' may be inserted; a
  definition
  
       #ifndef __OPTIMIZE__
--- 4242,4249 ----
  where flow analysis or alias analysis should show that certain code
  cannot be called) or to functions not being called because they have
  been expanded as built-in functions.  Such tests go in
! ‘gcc.c-torture/execute’.  Where code should be optimized away, a call to
! a nonexistent function such as ‘link_failure ()’ may be inserted; a
  definition
  
       #ifndef __OPTIMIZE__
*************** definition
*** 4257,4264 ****
  will also be needed so that linking still succeeds when the test is run
  without optimization.  When all calls to a built-in function should have
  been optimized and no calls to the non-built-in version of the function
! should remain, that function may be defined as 'static' to call 'abort
! ()' (although redeclaring a function as static may not work on all
  targets).
  
   All testcases must be portable.  Target-specific testcases must have
--- 4257,4264 ----
  will also be needed so that linking still succeeds when the test is run
  without optimization.  When all calls to a built-in function should have
  been optimized and no calls to the non-built-in version of the function
! should remain, that function may be defined as ‘static’ to call ‘abort
! ()’ (although redeclaring a function as static may not work on all
  targets).
  
   All testcases must be portable.  Target-specific testcases must have
*************** File: gccint.info,  Node: Test Directive
*** 4278,4286 ****
  * Directives::  Syntax and descriptions of test directives.
  * Selectors:: Selecting targets to which a test applies.
  * Effective-Target Keywords:: Keywords describing target attributes.
! * Add Options:: Features for 'dg-add-options'
! * Require Support:: Variants of 'dg-require-SUPPORT'
! * Final Actions:: Commands for use in 'dg-final'
  
  
  File: gccint.info,  Node: Directives,  Next: Selectors,  Up: Test Directives
--- 4278,4286 ----
  * Directives::  Syntax and descriptions of test directives.
  * Selectors:: Selecting targets to which a test applies.
  * Effective-Target Keywords:: Keywords describing target attributes.
! * Add Options:: Features for ‘dg-add-options’
! * Require Support:: Variants of ‘dg-require-SUPPORT’
! * Final Actions:: Commands for use in ‘dg-final’
  
  
  File: gccint.info,  Node: Directives,  Next: Selectors,  Up: Test Directives
*************** File: gccint.info,  Node: Directives,  N
*** 4289,4295 ****
  ------------------------------------------------
  
  Test directives appear within comments in a test source file and begin
! with 'dg-'.  Some of these are defined within DejaGnu and others are
  local to the GCC testsuite.
  
   The order in which test directives appear in a test can be important:
--- 4289,4295 ----
  ------------------------------------------------
  
  Test directives appear within comments in a test source file and begin
! with ‘dg-’.  Some of these are defined within DejaGnu and others are
  local to the GCC testsuite.
  
   The order in which test directives appear in a test can be important:
*************** DejaGnu directives, which know nothing a
*** 4298,4352 ****
  DejaGnu directives must precede GCC directives.
  
   Several test directives include selectors (*note Selectors::) which are
! usually preceded by the keyword 'target' or 'xfail'.
  
  7.2.1.1 Specify how to build the test
  .....................................
  
! '{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }'
       DO-WHAT-KEYWORD specifies how the test is compiled and whether it
       is executed.  It is one of:
  
!      'preprocess'
!           Compile with '-E' to run only the preprocessor.
!      'compile'
!           Compile with '-S' to produce an assembly code file.
!      'assemble'
!           Compile with '-c' to produce a relocatable object file.
!      'link'
            Compile, assemble, and link to produce an executable file.
!      'run'
            Produce and run an executable file, which is expected to
            return an exit code of 0.
  
!      The default is 'compile'.  That can be overridden for a set of
!      tests by redefining 'dg-do-what-default' within the '.exp' file for
       those tests.
  
!      If the directive includes the optional '{ target SELECTOR }' then
       the test is skipped unless the target system matches the SELECTOR.
  
!      If DO-WHAT-KEYWORD is 'run' and the directive includes the optional
!      '{ xfail SELECTOR }' and the selector is met then the test is
!      expected to fail.  The 'xfail' clause is ignored for other values
!      of DO-WHAT-KEYWORD; those tests can use directive 'dg-xfail-if'.
  
  7.2.1.2 Specify additional compiler options
  ...........................................
  
! '{ dg-options OPTIONS [{ target SELECTOR }] }'
       This DejaGnu directive provides a list of compiler options, to be
       used if the target system matches SELECTOR, that replace the
       default options used for this set of tests.
  
! '{ dg-add-options FEATURE ... }'
       Add any compiler options that are needed to access certain
       features.  This directive does nothing on targets that enable the
       features by default, or that don't provide them at all.  It must
!      come after all 'dg-options' directives.  For supported values of
       FEATURE see *note Add Options::.
  
! '{ dg-additional-options OPTIONS [{ target SELECTOR }] }'
       This directive provides a list of compiler options, to be used if
       the target system matches SELECTOR, that are added to the default
       options used for this set of tests.
--- 4298,4352 ----
  DejaGnu directives must precede GCC directives.
  
   Several test directives include selectors (*note Selectors::) which are
! usually preceded by the keyword ‘target’ or ‘xfail’.
  
  7.2.1.1 Specify how to build the test
  .....................................
  
! ‘{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }’
       DO-WHAT-KEYWORD specifies how the test is compiled and whether it
       is executed.  It is one of:
  
!      ‘preprocess’
!           Compile with ‘-E’ to run only the preprocessor.
!      ‘compile’
!           Compile with ‘-S’ to produce an assembly code file.
!      ‘assemble’
!           Compile with ‘-c’ to produce a relocatable object file.
!      ‘link’
            Compile, assemble, and link to produce an executable file.
!      ‘run’
            Produce and run an executable file, which is expected to
            return an exit code of 0.
  
!      The default is ‘compile’.  That can be overridden for a set of
!      tests by redefining ‘dg-do-what-default’ within the ‘.exp’ file for
       those tests.
  
!      If the directive includes the optional ‘{ target SELECTOR }’ then
       the test is skipped unless the target system matches the SELECTOR.
  
!      If DO-WHAT-KEYWORD is ‘run’ and the directive includes the optional
!      ‘{ xfail SELECTOR }’ and the selector is met then the test is
!      expected to fail.  The ‘xfail’ clause is ignored for other values
!      of DO-WHAT-KEYWORD; those tests can use directive ‘dg-xfail-if’.
  
  7.2.1.2 Specify additional compiler options
  ...........................................
  
! ‘{ dg-options OPTIONS [{ target SELECTOR }] }’
       This DejaGnu directive provides a list of compiler options, to be
       used if the target system matches SELECTOR, that replace the
       default options used for this set of tests.
  
! ‘{ dg-add-options FEATURE ... }’
       Add any compiler options that are needed to access certain
       features.  This directive does nothing on targets that enable the
       features by default, or that don't provide them at all.  It must
!      come after all ‘dg-options’ directives.  For supported values of
       FEATURE see *note Add Options::.
  
! ‘{ dg-additional-options OPTIONS [{ target SELECTOR }] }’
       This directive provides a list of compiler options, to be used if
       the target system matches SELECTOR, that are added to the default
       options used for this set of tests.
*************** usually preceded by the keyword 'target'
*** 4357,4433 ****
  The normal timeout limit, in seconds, is found by searching the
  following in order:
  
!    * the value defined by an earlier 'dg-timeout' directive in the test
  
!    * variable TOOL_TIMEOUT defined by the set of tests
  
!    * GCC,TIMEOUT set in the target board
  
!    * 300
  
! '{ dg-timeout N [{target SELECTOR }] }'
       Set the time limit for the compilation and for the execution of the
       test to the specified number of seconds.
  
! '{ dg-timeout-factor X [{ target SELECTOR }] }'
       Multiply the normal time limit for compilation and execution of the
       test by the specified floating-point factor.
  
  7.2.1.4 Skip a test for some targets
  ....................................
  
! '{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }'
       Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each
       element is a string of zero or more GCC options.  Skip the test if
       all of the following conditions are met:
!         * the test system is included in SELECTOR
  
!         * for at least one of the option strings in INCLUDE-OPTS, every
            option from that string is in the set of options with which
!           the test would be compiled; use '"*"' for an INCLUDE-OPTS list
            that matches any options; that is the default if INCLUDE-OPTS
            is not specified
  
!         * for each of the option strings in EXCLUDE-OPTS, at least one
            option from that string is not in the set of options with
!           which the test would be compiled; use '""' for an empty
            EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not
            specified
  
!      For example, to skip a test if option '-Os' is present:
  
            /* { dg-skip-if "" { *-*-* }  { "-Os" } { "" } } */
  
!      To skip a test if both options '-O2' and '-g' are present:
  
            /* { dg-skip-if "" { *-*-* }  { "-O2 -g" } { "" } } */
  
!      To skip a test if either '-O2' or '-O3' is present:
  
            /* { dg-skip-if "" { *-*-* }  { "-O2" "-O3" } { "" } } */
  
!      To skip a test unless option '-Os' is present:
  
            /* { dg-skip-if "" { *-*-* }  { "*" } { "-Os" } } */
  
!      To skip a test if either '-O2' or '-O3' is used with '-g' but not
!      if '-fpic' is also present:
  
            /* { dg-skip-if "" { *-*-* }  { "-O2 -g" "-O3 -g" } { "-fpic" } } */
  
! '{ dg-require-effective-target KEYWORD [{ target SELECTOR }] }'
       Skip the test if the test target, including current multilib flags,
       is not covered by the effective-target keyword.  If the directive
!      includes the optional '{ SELECTOR }' then the effective-target test
       is only performed if the target system matches the SELECTOR.  This
!      directive must appear after any 'dg-do' directive in the test and
!      before any 'dg-additional-sources' directive.  *Note
       Effective-Target Keywords::.
  
! '{ dg-require-SUPPORT args }'
       Skip the test if the target does not provide the required support.
!      These directives must appear after any 'dg-do' directive in the
!      test and before any 'dg-additional-sources' directive.  They
       require at least one argument, which can be an empty string if the
       specific procedure does not examine the argument.  *Note Require
       Support::, for a complete list of these directives.
--- 4357,4433 ----
  The normal timeout limit, in seconds, is found by searching the
  following in order:
  
!    • the value defined by an earlier ‘dg-timeout’ directive in the test
  
!    • variable TOOL_TIMEOUT defined by the set of tests
  
!    • GCC,TIMEOUT set in the target board
  
!    • 300
  
! ‘{ dg-timeout N [{target SELECTOR }] }’
       Set the time limit for the compilation and for the execution of the
       test to the specified number of seconds.
  
! ‘{ dg-timeout-factor X [{ target SELECTOR }] }’
       Multiply the normal time limit for compilation and execution of the
       test by the specified floating-point factor.
  
  7.2.1.4 Skip a test for some targets
  ....................................
  
! ‘{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }’
       Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each
       element is a string of zero or more GCC options.  Skip the test if
       all of the following conditions are met:
!         • the test system is included in SELECTOR
  
!         • for at least one of the option strings in INCLUDE-OPTS, every
            option from that string is in the set of options with which
!           the test would be compiled; use ‘"*"’ for an INCLUDE-OPTS list
            that matches any options; that is the default if INCLUDE-OPTS
            is not specified
  
!         • for each of the option strings in EXCLUDE-OPTS, at least one
            option from that string is not in the set of options with
!           which the test would be compiled; use ‘""’ for an empty
            EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not
            specified
  
!      For example, to skip a test if option ‘-Os’ is present:
  
            /* { dg-skip-if "" { *-*-* }  { "-Os" } { "" } } */
  
!      To skip a test if both options ‘-O2’ and ‘-g’ are present:
  
            /* { dg-skip-if "" { *-*-* }  { "-O2 -g" } { "" } } */
  
!      To skip a test if either ‘-O2’ or ‘-O3’ is present:
  
            /* { dg-skip-if "" { *-*-* }  { "-O2" "-O3" } { "" } } */
  
!      To skip a test unless option ‘-Os’ is present:
  
            /* { dg-skip-if "" { *-*-* }  { "*" } { "-Os" } } */
  
!      To skip a test if either ‘-O2’ or ‘-O3’ is used with ‘-g’ but not
!      if ‘-fpic’ is also present:
  
            /* { dg-skip-if "" { *-*-* }  { "-O2 -g" "-O3 -g" } { "-fpic" } } */
  
! ‘{ dg-require-effective-target KEYWORD [{ target SELECTOR }] }’
       Skip the test if the test target, including current multilib flags,
       is not covered by the effective-target keyword.  If the directive
!      includes the optional ‘{ SELECTOR }’ then the effective-target test
       is only performed if the target system matches the SELECTOR.  This
!      directive must appear after any ‘dg-do’ directive in the test and
!      before any ‘dg-additional-sources’ directive.  *Note
       Effective-Target Keywords::.
  
! ‘{ dg-require-SUPPORT args }’
       Skip the test if the target does not provide the required support.
!      These directives must appear after any ‘dg-do’ directive in the
!      test and before any ‘dg-additional-sources’ directive.  They
       require at least one argument, which can be an empty string if the
       specific procedure does not examine the argument.  *Note Require
       Support::, for a complete list of these directives.
*************** following in order:
*** 4435,4570 ****
  7.2.1.5 Expect a test to fail for some targets
  ..............................................
  
! '{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }'
       Expect the test to fail if the conditions (which are the same as
!      for 'dg-skip-if') are met.  This does not affect the execute step.
  
! '{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }'
       Expect the execute step of a test to fail if the conditions (which
!      are the same as for 'dg-skip-if') are met.
  
  7.2.1.6 Expect the compiler to crash
  ....................................
  
! '{ dg-ice COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }'
       Expect the compiler to crash with an internal compiler error and
       return a nonzero exit status if the conditions (which are the same
!      as for 'dg-skip-if') are met.  Used for tests that test bugs that
       have not been fixed yet.
  
  7.2.1.7 Expect the test executable to fail
  ..........................................
  
! '{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }'
       Expect the test executable to return a nonzero exit status if the
!      conditions (which are the same as for 'dg-skip-if') are met.
  
  7.2.1.8 Verify compiler messages
  ................................
  
! Where LINE is an accepted argument for these commands, a value of '0'
  can be used if there is no line associated with the message.
  
! '{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }'
       This DejaGnu directive appears on a source line that is expected to
       get an error message, or else specifies the source line associated
       with the message.  If there is no message for that line or if the
       text of that message is not matched by REGEXP then the check fails
!      and COMMENT is included in the 'FAIL' message.  The check does not
!      look for the string 'error' unless it is part of REGEXP.
  
! '{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }'
       This DejaGnu directive appears on a source line that is expected to
       get a warning message, or else specifies the source line associated
       with the message.  If there is no message for that line or if the
       text of that message is not matched by REGEXP then the check fails
!      and COMMENT is included in the 'FAIL' message.  The check does not
!      look for the string 'warning' unless it is part of REGEXP.
  
! '{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }'
       The line is expected to get a message other than an error or
       warning.  If there is no message for that line or if the text of
       that message is not matched by REGEXP then the check fails and
!      COMMENT is included in the 'FAIL' message.
  
! '{ dg-note REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }'
!      The line is expected to get a 'note' message.  If there is no
       message for that line or if the text of that message is not matched
       by REGEXP then the check fails and COMMENT is included in the
!      'FAIL' message.
  
!      By default, any _excess_ 'note' messages are pruned, meaning their
!      appearance doesn't trigger _excess errors_.  However, if 'dg-note'
       is used at least once in a testcase, they're not pruned and instead
       must _all_ be handled explicitly.  Thus, if looking for just single
!      instances of messages with 'note: ' prefixes without caring for all
!      of them, use 'dg-message "note: [...]"' instead of 'dg-note', or
!      use 'dg-note' together with 'dg-prune-output "note: "'.
  
! '{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }'
       This DejaGnu directive appears on a source line that should not get
       a message matching REGEXP, or else specifies the source line
!      associated with the bogus message.  It is usually used with 'xfail'
       to indicate that the message is a known problem for a particular
       set of targets.
  
! '{ dg-line LINENUMVAR }'
       This DejaGnu directive sets the variable LINENUMVAR to the line
       number of the source line.  The variable LINENUMVAR can then be
!      used in subsequent 'dg-error', 'dg-warning', 'dg-message',
!      'dg-note' and 'dg-bogus' directives.  For example:
  
            int a;   /* { dg-line first_def_a } */
            float a; /* { dg-error "conflicting types of" } */
            /* { dg-message "previous declaration of" "" { target *-*-* } first_def_a } */
  
! '{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }'
       This DejaGnu directive indicates that the test is expected to fail
!      due to compiler messages that are not handled by 'dg-error',
!      'dg-warning', 'dg-message', 'dg-note' or 'dg-bogus'.  For this
!      directive 'xfail' has the same effect as 'target'.
  
! '{ dg-prune-output REGEXP }'
       Prune messages matching REGEXP from the test output.
  
  7.2.1.9 Verify output of the test executable
  ............................................
  
! '{ dg-output REGEXP [{ target/xfail SELECTOR }] }'
       This DejaGnu directive compares REGEXP to the combined output that
!      the test executable writes to 'stdout' and 'stderr'.
  
  7.2.1.10 Specify environment variables for a test
  .................................................
  
! '{ dg-set-compiler-env-var VAR_NAME "VAR_VALUE" }'
       Specify that the environment variable VAR_NAME needs to be set to
       VAR_VALUE before invoking the compiler on the test file.
  
! '{ dg-set-target-env-var VAR_NAME "VAR_VALUE" }'
       Specify that the environment variable VAR_NAME needs to be set to
       VAR_VALUE before execution of the program created by the test.
  
  7.2.1.11 Specify additional files for a test
  ............................................
  
! '{ dg-additional-files "FILELIST" }'
       Specify additional files, other than source files, that must be
       copied to the system where the compiler runs.
  
! '{ dg-additional-sources "FILELIST" }'
       Specify additional source files to appear in the compile line
       following the main test file.
  
  7.2.1.12 Add checks at the end of a test
  ........................................
  
! '{ dg-final { LOCAL-DIRECTIVE } }'
       This DejaGnu directive is placed within a comment anywhere in the
       source file and is processed after the test has been compiled and
!      run.  Multiple 'dg-final' commands are processed in the order in
       which they appear in the source file.  *Note Final Actions::, for a
!      list of directives that can be used within 'dg-final'.
  
  
  File: gccint.info,  Node: Selectors,  Next: Effective-Target Keywords,  Prev: Directives,  Up: Test Directives
--- 4435,4570 ----
  7.2.1.5 Expect a test to fail for some targets
  ..............................................
  
! ‘{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }’
       Expect the test to fail if the conditions (which are the same as
!      for ‘dg-skip-if’) are met.  This does not affect the execute step.
  
! ‘{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }’
       Expect the execute step of a test to fail if the conditions (which
!      are the same as for ‘dg-skip-if’) are met.
  
  7.2.1.6 Expect the compiler to crash
  ....................................
  
! ‘{ dg-ice COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }’
       Expect the compiler to crash with an internal compiler error and
       return a nonzero exit status if the conditions (which are the same
!      as for ‘dg-skip-if’) are met.  Used for tests that test bugs that
       have not been fixed yet.
  
  7.2.1.7 Expect the test executable to fail
  ..........................................
  
! ‘{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }’
       Expect the test executable to return a nonzero exit status if the
!      conditions (which are the same as for ‘dg-skip-if’) are met.
  
  7.2.1.8 Verify compiler messages
  ................................
  
! Where LINE is an accepted argument for these commands, a value of ‘0’
  can be used if there is no line associated with the message.
  
! ‘{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }’
       This DejaGnu directive appears on a source line that is expected to
       get an error message, or else specifies the source line associated
       with the message.  If there is no message for that line or if the
       text of that message is not matched by REGEXP then the check fails
!      and COMMENT is included in the ‘FAIL’ message.  The check does not
!      look for the string ‘error’ unless it is part of REGEXP.
  
! ‘{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }’
       This DejaGnu directive appears on a source line that is expected to
       get a warning message, or else specifies the source line associated
       with the message.  If there is no message for that line or if the
       text of that message is not matched by REGEXP then the check fails
!      and COMMENT is included in the ‘FAIL’ message.  The check does not
!      look for the string ‘warning’ unless it is part of REGEXP.
  
! ‘{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }’
       The line is expected to get a message other than an error or
       warning.  If there is no message for that line or if the text of
       that message is not matched by REGEXP then the check fails and
!      COMMENT is included in the ‘FAIL’ message.
  
! ‘{ dg-note REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }’
!      The line is expected to get a ‘note’ message.  If there is no
       message for that line or if the text of that message is not matched
       by REGEXP then the check fails and COMMENT is included in the
!      ‘FAIL’ message.
  
!      By default, any _excess_ ‘note’ messages are pruned, meaning their
!      appearance doesn't trigger _excess errors_.  However, if ‘dg-note’
       is used at least once in a testcase, they're not pruned and instead
       must _all_ be handled explicitly.  Thus, if looking for just single
!      instances of messages with ‘note: ’ prefixes without caring for all
!      of them, use ‘dg-message "note: [...]"’ instead of ‘dg-note’, or
!      use ‘dg-note’ together with ‘dg-prune-output "note: "’.
  
! ‘{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] ]] }’
       This DejaGnu directive appears on a source line that should not get
       a message matching REGEXP, or else specifies the source line
!      associated with the bogus message.  It is usually used with ‘xfail’
       to indicate that the message is a known problem for a particular
       set of targets.
  
! ‘{ dg-line LINENUMVAR }’
       This DejaGnu directive sets the variable LINENUMVAR to the line
       number of the source line.  The variable LINENUMVAR can then be
!      used in subsequent ‘dg-error’, ‘dg-warning’, ‘dg-message’,
!      ‘dg-note’ and ‘dg-bogus’ directives.  For example:
  
            int a;   /* { dg-line first_def_a } */
            float a; /* { dg-error "conflicting types of" } */
            /* { dg-message "previous declaration of" "" { target *-*-* } first_def_a } */
  
! ‘{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }’
       This DejaGnu directive indicates that the test is expected to fail
!      due to compiler messages that are not handled by ‘dg-error’,
!      ‘dg-warning’, ‘dg-message’, ‘dg-note’ or ‘dg-bogus’.  For this
!      directive ‘xfail’ has the same effect as ‘target’.
  
! ‘{ dg-prune-output REGEXP }’
       Prune messages matching REGEXP from the test output.
  
  7.2.1.9 Verify output of the test executable
  ............................................
  
! ‘{ dg-output REGEXP [{ target/xfail SELECTOR }] }’
       This DejaGnu directive compares REGEXP to the combined output that
!      the test executable writes to ‘stdout’ and ‘stderr’.
  
  7.2.1.10 Specify environment variables for a test
  .................................................
  
! ‘{ dg-set-compiler-env-var VAR_NAME "VAR_VALUE" }’
       Specify that the environment variable VAR_NAME needs to be set to
       VAR_VALUE before invoking the compiler on the test file.
  
! ‘{ dg-set-target-env-var VAR_NAME "VAR_VALUE" }’
       Specify that the environment variable VAR_NAME needs to be set to
       VAR_VALUE before execution of the program created by the test.
  
  7.2.1.11 Specify additional files for a test
  ............................................
  
! ‘{ dg-additional-files "FILELIST" }’
       Specify additional files, other than source files, that must be
       copied to the system where the compiler runs.
  
! ‘{ dg-additional-sources "FILELIST" }’
       Specify additional source files to appear in the compile line
       following the main test file.
  
  7.2.1.12 Add checks at the end of a test
  ........................................
  
! ‘{ dg-final { LOCAL-DIRECTIVE } }’
       This DejaGnu directive is placed within a comment anywhere in the
       source file and is processed after the test has been compiled and
!      run.  Multiple ‘dg-final’ commands are processed in the order in
       which they appear in the source file.  *Note Final Actions::, for a
!      list of directives that can be used within ‘dg-final’.
  
  
  File: gccint.info,  Node: Selectors,  Next: Effective-Target Keywords,  Prev: Directives,  Up: Test Directives
*************** a test is run or to declare that a test
*** 4577,4611 ****
  particular targets.
  
   A selector is:
!    * one or more target triplets, possibly including wildcard
!      characters; use '*-*-*' to match any target
!    * a single effective-target keyword (*note Effective-Target
       Keywords::)
!    * a list of compiler options that should be included or excluded (as
       described in more detail below)
!    * a logical expression
  
   Depending on the context, the selector specifies whether a test is
  skipped and reported as unsupported or is expected to fail.  A context
! that allows either 'target' or 'xfail' also allows '{ target SELECTOR1
! xfail SELECTOR2 }' to skip the test for targets that don't match
  SELECTOR1 and the test to fail for targets that match SELECTOR2.
  
   A selector expression appears within curly braces and uses a single
! logical operator: one of '!', '&&', or '||'.  An operand is one of the
  following:
  
!    * another selector expression, in curly braces
  
!    * an effective-target keyword, such as 'lp64'
  
!    * a single target triplet
  
!    * a list of target triplets within quotes or curly braces
  
!    * one of the following:
  
!      '{ any-opts OPT1 ... OPTN }'
            Each of OPT1 to OPTN is a space-separated list of option
            globs.  The selector expression evaluates to true if, for one
            of these strings, every glob in the string matches an option
--- 4577,4611 ----
  particular targets.
  
   A selector is:
!    • one or more target triplets, possibly including wildcard
!      characters; use ‘*-*-*’ to match any target
!    • a single effective-target keyword (*note Effective-Target
       Keywords::)
!    • a list of compiler options that should be included or excluded (as
       described in more detail below)
!    • a logical expression
  
   Depending on the context, the selector specifies whether a test is
  skipped and reported as unsupported or is expected to fail.  A context
! that allows either ‘target’ or ‘xfail’ also allows ‘{ target SELECTOR1
! xfail SELECTOR2 }’ to skip the test for targets that don't match
  SELECTOR1 and the test to fail for targets that match SELECTOR2.
  
   A selector expression appears within curly braces and uses a single
! logical operator: one of ‘!’, ‘&&’, or ‘||’.  An operand is one of the
  following:
  
!    • another selector expression, in curly braces
  
!    • an effective-target keyword, such as ‘lp64’
  
!    • a single target triplet
  
!    • a list of target triplets within quotes or curly braces
  
!    • one of the following:
  
!      ‘{ any-opts OPT1 ... OPTN }’
            Each of OPT1 to OPTN is a space-separated list of option
            globs.  The selector expression evaluates to true if, for one
            of these strings, every glob in the string matches an option
*************** following:
*** 4615,4633 ****
  
            is true if any of the following are true:
  
!              * '-O2' was passed to the compiler
  
!              * '-Og' was passed to the compiler
  
!              * both '-O3' and '-flto' were passed to the compiler
  
!           This kind of selector can only be used within 'dg-final'
!           directives.  Use 'dg-skip-if', 'dg-xfail-if' or
!           'dg-xfail-run-if' to skip whole tests based on options, or to
            mark them as expected to fail with certain options.
  
!      '{ no-opts OPT1 ... OPTN }'
!           As for 'any-opts' above, each of OPT1 to OPTN is a
            space-separated list of option globs.  The selector expression
            evaluates to true if, for all of these strings, there is at
            least one glob that does not match an option that was passed
--- 4615,4633 ----
  
            is true if any of the following are true:
  
!              • ‘-O2’ was passed to the compiler
  
!              • ‘-Og’ was passed to the compiler
  
!              • both ‘-O3’ and ‘-flto’ were passed to the compiler
  
!           This kind of selector can only be used within ‘dg-final’
!           directives.  Use ‘dg-skip-if’, ‘dg-xfail-if’ or
!           ‘dg-xfail-run-if’ to skip whole tests based on options, or to
            mark them as expected to fail with certain options.
  
!      ‘{ no-opts OPT1 ... OPTN }’
!           As for ‘any-opts’ above, each of OPT1 to OPTN is a
            space-separated list of option globs.  The selector expression
            evaluates to true if, for all of these strings, there is at
            least one glob that does not match an option that was passed
*************** following:
*** 4641,4655 ****
  
            is true if all of the following are true:
  
!              * '-O2' was not passed to the compiler
  
!              * '-Og' was not passed to the compiler
  
!              * at least one of '-O3' or '-flto' was not passed to the
                 compiler
  
!           Like 'any-opts', this kind of selector can only be used within
!           'dg-final' directives.
  
   Here are some examples of full target selectors:
  
--- 4641,4655 ----
  
            is true if all of the following are true:
  
!              • ‘-O2’ was not passed to the compiler
  
!              • ‘-Og’ was not passed to the compiler
  
!              • at least one of ‘-O3’ or ‘-flto’ was not passed to the
                 compiler
  
!           Like ‘any-opts’, this kind of selector can only be used within
!           ‘dg-final’ directives.
  
   Here are some examples of full target selectors:
  
*************** particular functionality.  They are used
*** 4669,4954 ****
  for particular targets, or to specify that particular sets of targets
  are expected to fail some tests.
  
!  Effective-target keywords are defined in 'lib/target-supports.exp' in
  the GCC testsuite, with the exception of those that are documented as
  being local to a particular test directory.
  
!  The 'effective target' takes into account all of the compiler options
  with which the test will be compiled, including the multilib options.
! By convention, keywords ending in '_nocache' can also include options
! specified for the particular test in an earlier 'dg-options' or
! 'dg-add-options' directive.
  
  7.2.3.1 Endianness
  ..................
  
! 'be'
       Target uses big-endian memory order for multi-byte and multi-word
       data.
  
! 'le'
       Target uses little-endian memory order for multi-byte and
       multi-word data.
  
  7.2.3.2 Data type sizes
  .......................
  
! 'ilp32'
!      Target has 32-bit 'int', 'long', and pointers.
  
! 'lp64'
!      Target has 32-bit 'int', 64-bit 'long' and pointers.
  
! 'llp64'
!      Target has 32-bit 'int' and 'long', 64-bit 'long long' and
       pointers.
  
! 'double64'
!      Target has 64-bit 'double'.
  
! 'double64plus'
!      Target has 'double' that is 64 bits or longer.
  
! 'longdouble128'
!      Target has 128-bit 'long double'.
  
! 'int32plus'
!      Target has 'int' that is at 32 bits or longer.
  
! 'int16'
!      Target has 'int' that is 16 bits or shorter.
  
! 'longlong64'
!      Target has 64-bit 'long long'.
  
! 'long_neq_int'
!      Target has 'int' and 'long' with different sizes.
  
! 'short_eq_int'
!      Target has 'short' and 'int' with the same size.
  
! 'ptr_eq_short'
!      Target has pointers ('void *') and 'short' with the same size.
  
! 'int_eq_float'
!      Target has 'int' and 'float' with the same size.
  
! 'ptr_eq_long'
!      Target has pointers ('void *') and 'long' with the same size.
  
! 'large_double'
!      Target supports 'double' that is longer than 'float'.
  
! 'large_long_double'
!      Target supports 'long double' that is longer than 'double'.
  
! 'ptr32plus'
       Target has pointers that are 32 bits or longer.
  
! 'size20plus'
       Target has a 20-bit or larger address space, so supports at least
       16-bit array and structure sizes.
  
! 'size24plus'
       Target has a 24-bit or larger address space, so supports at least
       20-bit array and structure sizes.
  
! 'size32plus'
       Target has a 32-bit or larger address space, so supports at least
       24-bit array and structure sizes.
  
! '4byte_wchar_t'
!      Target has 'wchar_t' that is at least 4 bytes.
  
! 'floatN'
!      Target has the '_FloatN' type.
  
! 'floatNx'
!      Target has the '_FloatNx' type.
  
! 'floatN_runtime'
!      Target has the '_FloatN' type, including runtime support for any
!      options added with 'dg-add-options'.
  
! 'floatNx_runtime'
!      Target has the '_FloatNx' type, including runtime support for any
!      options added with 'dg-add-options'.
  
! 'floatn_nx_runtime'
       Target has runtime support for any options added with
!      'dg-add-options' for any '_FloatN' or '_FloatNx' type.
  
! 'inf'
!      Target supports floating point infinite ('inf') for type 'double'.
  
! 'inff'
!      Target supports floating point infinite ('inf') for type 'float'.
  
  7.2.3.3 Fortran-specific attributes
  ...................................
  
! 'fortran_integer_16'
!      Target supports Fortran 'integer' that is 16 bytes or longer.
  
! 'fortran_real_10'
!      Target supports Fortran 'real' that is 10 bytes or longer.
  
! 'fortran_real_16'
!      Target supports Fortran 'real' that is 16 bytes or longer.
  
! 'fortran_large_int'
!      Target supports Fortran 'integer' kinds larger than 'integer(8)'.
  
! 'fortran_large_real'
!      Target supports Fortran 'real' kinds larger than 'real(8)'.
  
  7.2.3.4 Vector-specific attributes
  ..................................
  
! 'vect_align_stack_vars'
       The target's ABI allows stack variables to be aligned to the
       preferred vector alignment.
  
! 'vect_avg_qi'
       Target supports both signed and unsigned averaging operations on
       vectors of bytes.
  
! 'vect_mulhrs_hi'
       Target supports both signed and unsigned
       multiply-high-with-round-and-scale operations on vectors of
       half-words.
  
! 'vect_sdiv_pow2_si'
       Target supports signed division by constant power-of-2 operations
       on vectors of 4-byte integers.
  
! 'vect_condition'
       Target supports vector conditional operations.
  
! 'vect_cond_mixed'
       Target supports vector conditional operations where comparison
       operands have different type from the value operands.
  
! 'vect_double'
!      Target supports hardware vectors of 'double'.
  
! 'vect_double_cond_arith'
       Target supports conditional addition, subtraction, multiplication,
!      division, minimum and maximum on vectors of 'double', via the
!      'cond_' optabs.
  
! 'vect_element_align_preferred'
       The target's preferred vector alignment is the same as the element
       alignment.
  
! 'vect_float'
!      Target supports hardware vectors of 'float' when
!      '-funsafe-math-optimizations' is in effect.
  
! 'vect_float_strict'
!      Target supports hardware vectors of 'float' when
!      '-funsafe-math-optimizations' is not in effect.  This implies
!      'vect_float'.
  
! 'vect_int'
!      Target supports hardware vectors of 'int'.
  
! 'vect_long'
!      Target supports hardware vectors of 'long'.
  
! 'vect_long_long'
!      Target supports hardware vectors of 'long long'.
  
! 'vect_check_ptrs'
!      Target supports the 'check_raw_ptrs' and 'check_war_ptrs' optabs on
       vectors.
  
! 'vect_fully_masked'
       Target supports fully-masked (also known as fully-predicated)
       loops, so that vector loops can handle partial as well as full
       vectors.
  
! 'vect_masked_load'
       Target supports vector masked loads.
  
! 'vect_masked_store'
       Target supports vector masked stores.
  
! 'vect_gather_load_ifn'
       Target supports vector gather loads using internal functions
       (rather than via built-in functions or emulation).
  
! 'vect_scatter_store'
       Target supports vector scatter stores.
  
! 'vect_aligned_arrays'
       Target aligns arrays to vector alignment boundary.
  
! 'vect_hw_misalign'
       Target supports a vector misalign access.
  
! 'vect_no_align'
       Target does not support a vector alignment mechanism.
  
! 'vect_peeling_profitable'
       Target might require to peel loops for alignment purposes.
  
! 'vect_no_int_min_max'
!      Target does not support a vector min and max instruction on 'int'.
  
! 'vect_no_int_add'
!      Target does not support a vector add instruction on 'int'.
  
! 'vect_no_bitwise'
       Target does not support vector bitwise instructions.
  
! 'vect_bool_cmp'
!      Target supports comparison of 'bool' vectors for at least one
       vector length.
  
! 'vect_char_add'
!      Target supports addition of 'char' vectors for at least one vector
       length.
  
! 'vect_char_mult'
!      Target supports 'vector char' multiplication.
  
! 'vect_short_mult'
!      Target supports 'vector short' multiplication.
  
! 'vect_int_mult'
!      Target supports 'vector int' multiplication.
  
! 'vect_long_mult'
!      Target supports 64 bit 'vector long' multiplication.
  
! 'vect_extract_even_odd'
       Target supports vector even/odd element extraction.
  
! 'vect_extract_even_odd_wide'
       Target supports vector even/odd element extraction of vectors with
!      elements 'SImode' or larger.
  
! 'vect_interleave'
       Target supports vector interleaving.
  
! 'vect_strided'
       Target supports vector interleaving and extract even/odd.
  
! 'vect_strided_wide'
       Target supports vector interleaving and extract even/odd for wide
       element types.
  
! 'vect_perm'
       Target supports vector permutation.
  
! 'vect_perm_byte'
       Target supports permutation of vectors with 8-bit elements.
  
! 'vect_perm_short'
       Target supports permutation of vectors with 16-bit elements.
  
! 'vect_perm3_byte'
       Target supports permutation of vectors with 8-bit elements, and for
       the default vector length it is possible to permute:
            { a0, a1, a2, b0, b1, b2, ... }
--- 4669,4954 ----
  for particular targets, or to specify that particular sets of targets
  are expected to fail some tests.
  
!  Effective-target keywords are defined in ‘lib/target-supports.exp’ in
  the GCC testsuite, with the exception of those that are documented as
  being local to a particular test directory.
  
!  The ‘effective target’ takes into account all of the compiler options
  with which the test will be compiled, including the multilib options.
! By convention, keywords ending in ‘_nocache’ can also include options
! specified for the particular test in an earlier ‘dg-options’ or
! ‘dg-add-options’ directive.
  
  7.2.3.1 Endianness
  ..................
  
! ‘be’
       Target uses big-endian memory order for multi-byte and multi-word
       data.
  
! ‘le’
       Target uses little-endian memory order for multi-byte and
       multi-word data.
  
  7.2.3.2 Data type sizes
  .......................
  
! ‘ilp32’
!      Target has 32-bit ‘int’, ‘long’, and pointers.
  
! ‘lp64’
!      Target has 32-bit ‘int’, 64-bit ‘long’ and pointers.
  
! ‘llp64’
!      Target has 32-bit ‘int’ and ‘long’, 64-bit ‘long long’ and
       pointers.
  
! ‘double64’
!      Target has 64-bit ‘double’.
  
! ‘double64plus’
!      Target has ‘double’ that is 64 bits or longer.
  
! ‘longdouble128’
!      Target has 128-bit ‘long double’.
  
! ‘int32plus’
!      Target has ‘int’ that is at 32 bits or longer.
  
! ‘int16’
!      Target has ‘int’ that is 16 bits or shorter.
  
! ‘longlong64’
!      Target has 64-bit ‘long long’.
  
! ‘long_neq_int’
!      Target has ‘int’ and ‘long’ with different sizes.
  
! ‘short_eq_int’
!      Target has ‘short’ and ‘int’ with the same size.
  
! ‘ptr_eq_short’
!      Target has pointers (‘void *’) and ‘short’ with the same size.
  
! ‘int_eq_float’
!      Target has ‘int’ and ‘float’ with the same size.
  
! ‘ptr_eq_long’
!      Target has pointers (‘void *’) and ‘long’ with the same size.
  
! ‘large_double’
!      Target supports ‘double’ that is longer than ‘float’.
  
! ‘large_long_double’
!      Target supports ‘long double’ that is longer than ‘double’.
  
! ‘ptr32plus’
       Target has pointers that are 32 bits or longer.
  
! ‘size20plus’
       Target has a 20-bit or larger address space, so supports at least
       16-bit array and structure sizes.
  
! ‘size24plus’
       Target has a 24-bit or larger address space, so supports at least
       20-bit array and structure sizes.
  
! ‘size32plus’
       Target has a 32-bit or larger address space, so supports at least
       24-bit array and structure sizes.
  
! ‘4byte_wchar_t’
!      Target has ‘wchar_t’ that is at least 4 bytes.
  
! ‘floatN’
!      Target has the ‘_FloatN’ type.
  
! ‘floatNx’
!      Target has the ‘_FloatNx’ type.
  
! ‘floatN_runtime’
!      Target has the ‘_FloatN’ type, including runtime support for any
!      options added with ‘dg-add-options’.
  
! ‘floatNx_runtime’
!      Target has the ‘_FloatNx’ type, including runtime support for any
!      options added with ‘dg-add-options’.
  
! ‘floatn_nx_runtime’
       Target has runtime support for any options added with
!      ‘dg-add-options’ for any ‘_FloatN’ or ‘_FloatNx’ type.
  
! ‘inf’
!      Target supports floating point infinite (‘inf’) for type ‘double’.
  
! ‘inff’
!      Target supports floating point infinite (‘inf’) for type ‘float’.
  
  7.2.3.3 Fortran-specific attributes
  ...................................
  
! ‘fortran_integer_16’
!      Target supports Fortran ‘integer’ that is 16 bytes or longer.
  
! ‘fortran_real_10’
!      Target supports Fortran ‘real’ that is 10 bytes or longer.
  
! ‘fortran_real_16’
!      Target supports Fortran ‘real’ that is 16 bytes or longer.
  
! ‘fortran_large_int’
!      Target supports Fortran ‘integer’ kinds larger than ‘integer(8)’.
  
! ‘fortran_large_real’
!      Target supports Fortran ‘real’ kinds larger than ‘real(8)’.
  
  7.2.3.4 Vector-specific attributes
  ..................................
  
! ‘vect_align_stack_vars’
       The target's ABI allows stack variables to be aligned to the
       preferred vector alignment.
  
! ‘vect_avg_qi’
       Target supports both signed and unsigned averaging operations on
       vectors of bytes.
  
! ‘vect_mulhrs_hi’
       Target supports both signed and unsigned
       multiply-high-with-round-and-scale operations on vectors of
       half-words.
  
! ‘vect_sdiv_pow2_si’
       Target supports signed division by constant power-of-2 operations
       on vectors of 4-byte integers.
  
! ‘vect_condition’
       Target supports vector conditional operations.
  
! ‘vect_cond_mixed’
       Target supports vector conditional operations where comparison
       operands have different type from the value operands.
  
! ‘vect_double’
!      Target supports hardware vectors of ‘double’.
  
! ‘vect_double_cond_arith’
       Target supports conditional addition, subtraction, multiplication,
!      division, minimum and maximum on vectors of ‘double’, via the
!      ‘cond_’ optabs.
  
! ‘vect_element_align_preferred’
       The target's preferred vector alignment is the same as the element
       alignment.
  
! ‘vect_float’
!      Target supports hardware vectors of ‘float’ when
!      ‘-funsafe-math-optimizations’ is in effect.
  
! ‘vect_float_strict’
!      Target supports hardware vectors of ‘float’ when
!      ‘-funsafe-math-optimizations’ is not in effect.  This implies
!      ‘vect_float’.
  
! ‘vect_int’
!      Target supports hardware vectors of ‘int’.
  
! ‘vect_long’
!      Target supports hardware vectors of ‘long’.
  
! ‘vect_long_long’
!      Target supports hardware vectors of ‘long long’.
  
! ‘vect_check_ptrs’
!      Target supports the ‘check_raw_ptrs’ and ‘check_war_ptrs’ optabs on
       vectors.
  
! ‘vect_fully_masked’
       Target supports fully-masked (also known as fully-predicated)
       loops, so that vector loops can handle partial as well as full
       vectors.
  
! ‘vect_masked_load’
       Target supports vector masked loads.
  
! ‘vect_masked_store’
       Target supports vector masked stores.
  
! ‘vect_gather_load_ifn’
       Target supports vector gather loads using internal functions
       (rather than via built-in functions or emulation).
  
! ‘vect_scatter_store’
       Target supports vector scatter stores.
  
! ‘vect_aligned_arrays’
       Target aligns arrays to vector alignment boundary.
  
! ‘vect_hw_misalign’
       Target supports a vector misalign access.
  
! ‘vect_no_align’
       Target does not support a vector alignment mechanism.
  
! ‘vect_peeling_profitable’
       Target might require to peel loops for alignment purposes.
  
! ‘vect_no_int_min_max’
!      Target does not support a vector min and max instruction on ‘int’.
  
! ‘vect_no_int_add’
!      Target does not support a vector add instruction on ‘int’.
  
! ‘vect_no_bitwise’
       Target does not support vector bitwise instructions.
  
! ‘vect_bool_cmp’
!      Target supports comparison of ‘bool’ vectors for at least one
       vector length.
  
! ‘vect_char_add’
!      Target supports addition of ‘char’ vectors for at least one vector
       length.
  
! ‘vect_char_mult’
!      Target supports ‘vector char’ multiplication.
  
! ‘vect_short_mult’
!      Target supports ‘vector short’ multiplication.
  
! ‘vect_int_mult’
!      Target supports ‘vector int’ multiplication.
  
! ‘vect_long_mult’
!      Target supports 64 bit ‘vector long’ multiplication.
  
! ‘vect_extract_even_odd’
       Target supports vector even/odd element extraction.
  
! ‘vect_extract_even_odd_wide’
       Target supports vector even/odd element extraction of vectors with
!      elements ‘SImode’ or larger.
  
! ‘vect_interleave’
       Target supports vector interleaving.
  
! ‘vect_strided’
       Target supports vector interleaving and extract even/odd.
  
! ‘vect_strided_wide’
       Target supports vector interleaving and extract even/odd for wide
       element types.
  
! ‘vect_perm’
       Target supports vector permutation.
  
! ‘vect_perm_byte’
       Target supports permutation of vectors with 8-bit elements.
  
! ‘vect_perm_short’
       Target supports permutation of vectors with 16-bit elements.
  
! ‘vect_perm3_byte’
       Target supports permutation of vectors with 8-bit elements, and for
       the default vector length it is possible to permute:
            { a0, a1, a2, b0, b1, b2, ... }
*************** specified for the particular test in an
*** 4959,6242 ****
       using only two-vector permutes, regardless of how long the sequence
       is.
  
! 'vect_perm3_int'
!      Like 'vect_perm3_byte', but for 32-bit elements.
  
! 'vect_perm3_short'
!      Like 'vect_perm3_byte', but for 16-bit elements.
  
! 'vect_shift'
       Target supports a hardware vector shift operation.
  
! 'vect_unaligned_possible'
       Target prefers vectors to have an alignment greater than element
       alignment, but also allows unaligned vector accesses in some
       circumstances.
  
! 'vect_variable_length'
       Target has variable-length vectors.
  
! 'vect64'
       Target supports vectors of 64 bits.
  
! 'vect32'
       Target supports vectors of 32 bits.
  
! 'vect_widen_sum_hi_to_si'
!      Target supports a vector widening summation of 'short' operands
!      into 'int' results, or can promote (unpack) from 'short' to 'int'.
  
! 'vect_widen_sum_qi_to_hi'
!      Target supports a vector widening summation of 'char' operands into
!      'short' results, or can promote (unpack) from 'char' to 'short'.
  
! 'vect_widen_sum_qi_to_si'
!      Target supports a vector widening summation of 'char' operands into
!      'int' results.
  
! 'vect_widen_mult_qi_to_hi'
!      Target supports a vector widening multiplication of 'char' operands
!      into 'short' results, or can promote (unpack) from 'char' to
!      'short' and perform non-widening multiplication of 'short'.
  
! 'vect_widen_mult_hi_to_si'
!      Target supports a vector widening multiplication of 'short'
!      operands into 'int' results, or can promote (unpack) from 'short'
!      to 'int' and perform non-widening multiplication of 'int'.
  
! 'vect_widen_mult_si_to_di_pattern'
!      Target supports a vector widening multiplication of 'int' operands
!      into 'long' results.
  
! 'vect_sdot_qi'
!      Target supports a vector dot-product of 'signed char'.
  
! 'vect_udot_qi'
!      Target supports a vector dot-product of 'unsigned char'.
  
! 'vect_usdot_qi'
       Target supports a vector dot-product where one operand of the
!      multiply is 'signed char' and the other of 'unsigned char'.
  
! 'vect_sdot_hi'
!      Target supports a vector dot-product of 'signed short'.
  
! 'vect_udot_hi'
!      Target supports a vector dot-product of 'unsigned short'.
  
! 'vect_pack_trunc'
!      Target supports a vector demotion (packing) of 'short' to 'char'
!      and from 'int' to 'short' using modulo arithmetic.
  
! 'vect_unpack'
!      Target supports a vector promotion (unpacking) of 'char' to 'short'
!      and from 'char' to 'int'.
  
! 'vect_intfloat_cvt'
!      Target supports conversion from 'signed int' to 'float'.
  
! 'vect_uintfloat_cvt'
!      Target supports conversion from 'unsigned int' to 'float'.
  
! 'vect_floatint_cvt'
!      Target supports conversion from 'float' to 'signed int'.
  
! 'vect_floatuint_cvt'
!      Target supports conversion from 'float' to 'unsigned int'.
  
! 'vect_intdouble_cvt'
!      Target supports conversion from 'signed int' to 'double'.
  
! 'vect_doubleint_cvt'
!      Target supports conversion from 'double' to 'signed int'.
  
! 'vect_max_reduc'
       Target supports max reduction for vectors.
  
! 'vect_sizes_16B_8B'
       Target supports 16- and 8-bytes vectors.
  
! 'vect_sizes_32B_16B'
       Target supports 32- and 16-bytes vectors.
  
! 'vect_logical_reduc'
       Target supports AND, IOR and XOR reduction on vectors.
  
! 'vect_fold_extract_last'
!      Target supports the 'fold_extract_last' optab.
  
! 'vect_len_load_store'
!      Target supports the 'len_load' and 'len_store' optabs.
  
! 'vect_partial_vectors_usage_1'
       Target supports loop vectorization with partial vectors and
!      'vect-partial-vector-usage' is set to 1.
  
! 'vect_partial_vectors_usage_2'
       Target supports loop vectorization with partial vectors and
!      'vect-partial-vector-usage' is set to 2.
  
! 'vect_partial_vectors'
       Target supports loop vectorization with partial vectors and
!      'vect-partial-vector-usage' is nonzero.
  
! 'vect_slp_v2qi_store_align'
       Target supports vectorization of 2-byte char stores with 2-byte
!      aligned address at plain '-O2'.
  
! 'vect_slp_v4qi_store_align'
       Target supports vectorization of 4-byte char stores with 4-byte
!      aligned address at plain '-O2'.
  
! 'vect_slp_v4qi_store_unalign'
       Target supports vectorization of 4-byte char stores with unaligned
!      address at plain '-O2'.
  
! 'struct_4char_block_move'
       Target supports block move for 8-byte aligned 4-byte size struct
       initialization.
  
! 'vect_slp_v4qi_store_unalign_1'
       Target supports vectorization of 4-byte char stores with unaligned
!      address or store them with constant pool at plain '-O2'.
  
! 'struct_8char_block_move'
       Target supports block move for 8-byte aligned 8-byte size struct
       initialization.
  
! 'vect_slp_v8qi_store_unalign_1'
       Target supports vectorization of 8-byte char stores with unaligned
!      address or store them with constant pool at plain '-O2'.
  
! 'struct_16char_block_move'
       Target supports block move for 8-byte aligned 16-byte size struct
       initialization.
  
! 'vect_slp_v16qi_store_unalign_1'
       Target supports vectorization of 16-byte char stores with unaligned
!      address or store them with constant pool at plain '-O2'.
  
! 'vect_slp_v2hi_store_align'
       Target supports vectorization of 4-byte short stores with 4-byte
!      aligned addressat plain '-O2'.
  
! 'vect_slp_v2hi_store_unalign'
       Target supports vectorization of 4-byte short stores with unaligned
!      address at plain '-O2'.
  
! 'vect_slp_v4hi_store_unalign'
       Target supports vectorization of 8-byte short stores with unaligned
!      address at plain '-O2'.
  
! 'vect_slp_v2si_store_align'
       Target supports vectorization of 8-byte int stores with 8-byte
!      aligned address at plain '-O2'.
  
! 'vect_slp_v4si_store_unalign'
       Target supports vectorization of 16-byte int stores with unaligned
!      address at plain '-O2'.
  
  7.2.3.5 Thread Local Storage attributes
  .......................................
  
! 'tls'
       Target supports thread-local storage.
  
! 'tls_native'
       Target supports native (rather than emulated) thread-local storage.
  
! 'tls_runtime'
       Test system supports executing TLS executables.
  
  7.2.3.6 Decimal floating point attributes
  .........................................
  
! 'dfp'
       Targets supports compiling decimal floating point extension to C.
  
! 'dfp_nocache'
       Including the options used to compile this particular test, the
       target supports compiling decimal floating point extension to C.
  
! 'dfprt'
       Test system can execute decimal floating point tests.
  
! 'dfprt_nocache'
       Including the options used to compile this particular test, the
       test system can execute decimal floating point tests.
  
! 'hard_dfp'
       Target generates decimal floating point instructions with current
       options.
  
! 'dfp_bid'
       Target uses the BID format for decimal floating point.
  
  7.2.3.7 ARM-specific attributes
  ...............................
  
! 'arm32'
       ARM target generates 32-bit code.
  
! 'arm_little_endian'
       ARM target that generates little-endian code.
  
! 'arm_eabi'
       ARM target adheres to the ABI for the ARM Architecture.
  
! 'arm_fp_ok'
!      ARM target defines '__ARM_FP' using '-mfloat-abi=softfp' or
       equivalent options.  Some multilibs may be incompatible with these
       options.
  
! 'arm_fp_dp_ok'
!      ARM target defines '__ARM_FP' with double-precision support using
!      '-mfloat-abi=softfp' or equivalent options.  Some multilibs may be
       incompatible with these options.
  
! 'arm_hf_eabi'
       ARM target adheres to the VFP and Advanced SIMD Register Arguments
       variant of the ABI for the ARM Architecture (as selected with
!      '-mfloat-abi=hard').
  
! 'arm_softfloat'
       ARM target uses emulated floating point operations.
  
! 'arm_hard_vfp_ok'
!      ARM target supports '-mfpu=vfp -mfloat-abi=hard'.  Some multilibs
       may be incompatible with these options.
  
! 'arm_iwmmxt_ok'
!      ARM target supports '-mcpu=iwmmxt'.  Some multilibs may be
       incompatible with this option.
  
! 'arm_neon'
       ARM target supports generating NEON instructions.
  
! 'arm_tune_string_ops_prefer_neon'
       Test CPU tune supports inlining string operations with NEON
       instructions.
  
! 'arm_neon_hw'
       Test system supports executing NEON instructions.
  
! 'arm_neonv2_hw'
       Test system supports executing NEON v2 instructions.
  
! 'arm_neon_ok'
!      ARM Target supports '-mfpu=neon -mfloat-abi=softfp' or compatible
       options.  Some multilibs may be incompatible with these options.
  
! 'arm_neon_ok_no_float_abi'
!      ARM Target supports NEON with '-mfpu=neon', but without any
       -mfloat-abi= option.  Some multilibs may be incompatible with this
       option.
  
! 'arm_neonv2_ok'
!      ARM Target supports '-mfpu=neon-vfpv4 -mfloat-abi=softfp' or
       compatible options.  Some multilibs may be incompatible with these
       options.
  
! 'arm_fp16_ok'
       Target supports options to generate VFP half-precision
       floating-point instructions.  Some multilibs may be incompatible
       with these options.  This test is valid for ARM only.
  
! 'arm_fp16_hw'
       Target supports executing VFP half-precision floating-point
       instructions.  This test is valid for ARM only.
  
! 'arm_neon_fp16_ok'
!      ARM Target supports '-mfpu=neon-fp16 -mfloat-abi=softfp' or
!      compatible options, including '-mfp16-format=ieee' if necessary to
!      obtain the '__fp16' type.  Some multilibs may be incompatible with
       these options.
  
! 'arm_neon_fp16_hw'
       Test system supports executing Neon half-precision float
       instructions.  (Implies previous.)
  
! 'arm_fp16_alternative_ok'
       ARM target supports the ARM FP16 alternative format.  Some
       multilibs may be incompatible with the options needed.
  
! 'arm_fp16_none_ok'
       ARM target supports specifying none as the ARM FP16 format.
  
! 'arm_thumb1_ok'
!      ARM target generates Thumb-1 code for '-mthumb'.
  
! 'arm_thumb2_ok'
!      ARM target generates Thumb-2 code for '-mthumb'.
  
! 'arm_nothumb'
       ARM target that is not using Thumb.
  
! 'arm_vfp_ok'
!      ARM target supports '-mfpu=vfp -mfloat-abi=softfp'.  Some multilibs
       may be incompatible with these options.
  
! 'arm_vfp3_ok'
!      ARM target supports '-mfpu=vfp3 -mfloat-abi=softfp'.  Some
       multilibs may be incompatible with these options.
  
! 'arm_arch_v8a_hard_ok'
!      The compiler is targeting 'arm*-*-*' and can compile and assemble
!      code using the options '-march=armv8-a -mfpu=neon-fp-armv8
!      -mfloat-abi=hard'.  This is not enough to guarantee that linking
       works.
  
! 'arm_arch_v8a_hard_multilib'
!      The compiler is targeting 'arm*-*-*' and can build programs using
!      the options '-march=armv8-a -mfpu=neon-fp-armv8 -mfloat-abi=hard'.
       The target can also run the resulting binaries.
  
! 'arm_v8_vfp_ok'
!      ARM target supports '-mfpu=fp-armv8 -mfloat-abi=softfp'.  Some
       multilibs may be incompatible with these options.
  
! 'arm_v8_neon_ok'
!      ARM target supports '-mfpu=neon-fp-armv8 -mfloat-abi=softfp'.  Some
       multilibs may be incompatible with these options.
  
! 'arm_v8_1a_neon_ok'
       ARM target supports options to generate ARMv8.1-A Adv.SIMD
       instructions.  Some multilibs may be incompatible with these
       options.
  
! 'arm_v8_1a_neon_hw'
       ARM target supports executing ARMv8.1-A Adv.SIMD instructions.
       Some multilibs may be incompatible with the options needed.
       Implies arm_v8_1a_neon_ok.
  
! 'arm_acq_rel'
       ARM target supports acquire-release instructions.
  
! 'arm_v8_2a_fp16_scalar_ok'
       ARM target supports options to generate instructions for ARMv8.2-A
       and scalar instructions from the FP16 extension.  Some multilibs
       may be incompatible with these options.
  
! 'arm_v8_2a_fp16_scalar_hw'
       ARM target supports executing instructions for ARMv8.2-A and scalar
       instructions from the FP16 extension.  Some multilibs may be
       incompatible with these options.  Implies arm_v8_2a_fp16_neon_ok.
  
! 'arm_v8_2a_fp16_neon_ok'
       ARM target supports options to generate instructions from ARMv8.2-A
       with the FP16 extension.  Some multilibs may be incompatible with
       these options.  Implies arm_v8_2a_fp16_scalar_ok.
  
! 'arm_v8_2a_fp16_neon_hw'
       ARM target supports executing instructions from ARMv8.2-A with the
       FP16 extension.  Some multilibs may be incompatible with these
       options.  Implies arm_v8_2a_fp16_neon_ok and
       arm_v8_2a_fp16_scalar_hw.
  
! 'arm_v8_2a_dotprod_neon_ok'
       ARM target supports options to generate instructions from ARMv8.2-A
       with the Dot Product extension.  Some multilibs may be incompatible
       with these options.
  
! 'arm_v8_2a_dotprod_neon_hw'
       ARM target supports executing instructions from ARMv8.2-A with the
       Dot Product extension.  Some multilibs may be incompatible with
       these options.  Implies arm_v8_2a_dotprod_neon_ok.
  
! 'arm_v8_2a_i8mm_neon_hw'
       ARM target supports executing instructions from ARMv8.2-A with the
       8-bit Matrix Multiply extension.  Some multilibs may be
       incompatible with these options.  Implies arm_v8_2a_i8mm_ok.
  
! 'arm_fp16fml_neon_ok'
!      ARM target supports extensions to generate the 'VFMAL' and 'VFMLS'
       half-precision floating-point instructions available from ARMv8.2-A
       and onwards.  Some multilibs may be incompatible with these
       options.
  
! 'arm_v8_2a_bf16_neon_ok'
       ARM target supports options to generate instructions from ARMv8.2-A
       with the BFloat16 extension (bf16).  Some multilibs may be
       incompatible with these options.
  
! 'arm_v8_2a_i8mm_ok'
       ARM target supports options to generate instructions from ARMv8.2-A
       with the 8-Bit Integer Matrix Multiply extension (i8mm).  Some
       multilibs may be incompatible with these options.
  
! 'arm_v8_1m_mve_ok'
       ARM target supports options to generate instructions from ARMv8.1-M
       with the M-Profile Vector Extension (MVE). Some multilibs may be
       incompatible with these options.
  
! 'arm_v8_1m_mve_fp_ok'
       ARM target supports options to generate instructions from ARMv8.1-M
       with the Half-precision floating-point instructions (HP),
       Floating-point Extension (FP) along with M-Profile Vector Extension
       (MVE). Some multilibs may be incompatible with these options.
  
! 'arm_mve_hw'
       Test system supports executing MVE instructions.
  
! 'arm_v8m_main_cde'
       ARM target supports options to generate instructions from ARMv8-M
       with the Custom Datapath Extension (CDE). Some multilibs may be
       incompatible with these options.
  
! 'arm_v8m_main_cde_fp'
       ARM target supports options to generate instructions from ARMv8-M
       with the Custom Datapath Extension (CDE) and floating-point (VFP).
       Some multilibs may be incompatible with these options.
  
! 'arm_v8_1m_main_cde_mve'
       ARM target supports options to generate instructions from ARMv8.1-M
       with the Custom Datapath Extension (CDE) and M-Profile Vector
       Extension (MVE). Some multilibs may be incompatible with these
       options.
  
! 'arm_pacbti_hw'
       Test system supports executing Pointer Authentication and Branch
       Target Identification instructions.
  
! 'arm_prefer_ldrd_strd'
!      ARM target prefers 'LDRD' and 'STRD' instructions over 'LDM' and
!      'STM' instructions.
  
! 'arm_thumb1_movt_ok'
!      ARM target generates Thumb-1 code for '-mthumb' with 'MOVW' and
!      'MOVT' instructions available.
  
! 'arm_thumb1_cbz_ok'
!      ARM target generates Thumb-1 code for '-mthumb' with 'CBZ' and
!      'CBNZ' instructions available.
  
! 'arm_divmod_simode'
       ARM target for which divmod transform is disabled, if it supports
       hardware div instruction.
  
! 'arm_cmse_ok'
       ARM target supports ARMv8-M Security Extensions, enabled by the
!      '-mcmse' option.
  
! 'arm_cmse_hw'
       Test system supports executing CMSE instructions.
  
! 'arm_coproc1_ok'
!      ARM target supports the following coprocessor instructions: 'CDP',
!      'LDC', 'STC', 'MCR' and 'MRC'.
  
! 'arm_coproc2_ok'
       ARM target supports all the coprocessor instructions also listed as
       supported in *note arm_coproc1_ok:: in addition to the following:
!      'CDP2', 'LDC2', 'LDC2l', 'STC2', 'STC2l', 'MCR2' and 'MRC2'.
  
! 'arm_coproc3_ok'
       ARM target supports all the coprocessor instructions also listed as
       supported in *note arm_coproc2_ok:: in addition the following:
!      'MCRR' and 'MRRC'.
  
! 'arm_coproc4_ok'
       ARM target supports all the coprocessor instructions also listed as
       supported in *note arm_coproc3_ok:: in addition the following:
!      'MCRR2' and 'MRRC2'.
  
! 'arm_simd32_ok'
       ARM Target supports options suitable for accessing the SIMD32
!      intrinsics from 'arm_acle.h'.  Some multilibs may be incompatible
       with these options.
  
! 'arm_sat_ok'
       ARM Target supports options suitable for accessing the saturation
!      intrinsics from 'arm_acle.h'.  Some multilibs may be incompatible
       with these options.
  
! 'arm_dsp_ok'
       ARM Target supports options suitable for accessing the DSP
!      intrinsics from 'arm_acle.h'.  Some multilibs may be incompatible
       with these options.
  
! 'arm_softfp_ok'
!      ARM target supports the '-mfloat-abi=softfp' option.
  
! 'arm_hard_ok'
!      ARM target supports the '-mfloat-abi=hard' option.
  
! 'arm_mve'
       ARM target supports generating MVE instructions.
  
! 'arm_v8_1_lob_ok'
       ARM Target supports executing the Armv8.1-M Mainline Low Overhead
!      Loop instructions 'DLS' and 'LE'.  Some multilibs may be
       incompatible with these options.
  
! 'arm_thumb2_no_arm_v8_1_lob'
       ARM target where Thumb-2 is used without options but does not
       support executing the Armv8.1-M Mainline Low Overhead Loop
!      instructions 'DLS' and 'LE'.
  
! 'arm_thumb2_ok_no_arm_v8_1_lob'
!      ARM target generates Thumb-2 code for '-mthumb' but does not
       support executing the Armv8.1-M Mainline Low Overhead Loop
!      instructions 'DLS' and 'LE'.
  
! 'mbranch_protection_ok'
!      ARM target supporting '-mbranch-protection=standard'.
  
! 'arm_pacbti_hw'
       Test system supports for executing non nop pacbti instructions.
  
  7.2.3.8 AArch64-specific attributes
  ...................................
  
! 'aarch64_asm__ok'
!      AArch64 assembler supports the architecture extension 'ext' via the
!      '.arch_extension' pseudo-op.
! 'aarch64_tiny'
       AArch64 target which generates instruction sequences for tiny
       memory model.
! 'aarch64_small'
       AArch64 target which generates instruction sequences for small
       memory model.
! 'aarch64_large'
       AArch64 target which generates instruction sequences for large
       memory model.
! 'aarch64_little_endian'
       AArch64 target which generates instruction sequences for little
       endian.
! 'aarch64_big_endian'
       AArch64 target which generates instruction sequences for big
       endian.
! 'aarch64_small_fpic'
       Binutils installed on test system supports relocation types
       required by -fpic for AArch64 small memory model.
! 'aarch64_sve_hw'
       AArch64 target that is able to generate and execute SVE code
       (regardless of whether it does so by default).
! 'aarch64_sve128_hw'
! 'aarch64_sve256_hw'
! 'aarch64_sve512_hw'
! 'aarch64_sve1024_hw'
! 'aarch64_sve2048_hw'
!      Like 'aarch64_sve_hw', but also test for an exact hardware vector
       length.
  
! 'aarch64_fjcvtzs_hw'
       AArch64 target that is able to generate and execute armv8.3-a
       FJCVTZS instruction.
  
  7.2.3.9 MIPS-specific attributes
  ................................
  
! 'mips64'
       MIPS target supports 64-bit instructions.
  
! 'nomips16'
       MIPS target does not produce MIPS16 code.
  
! 'mips16_attribute'
       MIPS target can generate MIPS16 code.
  
! 'mips_loongson'
       MIPS target is a Loongson-2E or -2F target using an ABI that
       supports the Loongson vector modes.
  
! 'mips_msa'
!      MIPS target supports '-mmsa', MIPS SIMD Architecture (MSA).
  
! 'mips_newabi_large_long_double'
!      MIPS target supports 'long double' larger than 'double' when using
       the new ABI.
  
! 'mpaired_single'
!      MIPS target supports '-mpaired-single'.
  
  7.2.3.10 MSP430-specific attributes
  ...................................
  
! 'msp430_small'
!      MSP430 target has the small memory model enabled ('-msmall').
  
! 'msp430_large'
!      MSP430 target has the large memory model enabled ('-mlarge').
  
  7.2.3.11 PowerPC-specific attributes
  ....................................
  
! 'dfp_hw'
       PowerPC target supports executing hardware DFP instructions.
  
! 'p8vector_hw'
       PowerPC target supports executing VSX instructions (ISA 2.07).
  
! 'powerpc64'
       Test system supports executing 64-bit instructions.
  
! 'powerpc_altivec'
       PowerPC target supports AltiVec.
  
! 'powerpc_altivec_ok'
!      PowerPC target supports '-maltivec'.
  
! 'powerpc_eabi_ok'
!      PowerPC target supports '-meabi'.
  
! 'powerpc_elfv2'
!      PowerPC target supports '-mabi=elfv2'.
  
! 'powerpc_fprs'
       PowerPC target supports floating-point registers.
  
! 'powerpc_hard_double'
       PowerPC target supports hardware double-precision floating-point.
  
! 'powerpc_htm_ok'
!      PowerPC target supports '-mhtm'
  
! 'powerpc_p8vector_ok'
!      PowerPC target supports '-mpower8-vector'
  
! 'powerpc_popcntb_ok'
!      PowerPC target supports the 'popcntb' instruction, indicating that
!      this target supports '-mcpu=power5'.
  
! 'powerpc_ppu_ok'
!      PowerPC target supports '-mcpu=cell'.
  
! 'powerpc_spe'
       PowerPC target supports PowerPC SPE.
  
! 'powerpc_spe_nocache'
       Including the options used to compile this particular test, the
       PowerPC target supports PowerPC SPE.
  
! 'powerpc_spu'
       PowerPC target supports PowerPC SPU.
  
! 'powerpc_vsx_ok'
!      PowerPC target supports '-mvsx'.
  
! 'powerpc_405_nocache'
       Including the options used to compile this particular test, the
       PowerPC target supports PowerPC 405.
  
! 'ppc_recip_hw'
       PowerPC target supports executing reciprocal estimate instructions.
  
! 'vmx_hw'
       PowerPC target supports executing AltiVec instructions.
  
! 'vsx_hw'
       PowerPC target supports executing VSX instructions (ISA 2.06).
  
! 'has_arch_pwr5'
!      PowerPC target pre-defines macro _ARCH_PWR5 which means the '-mcpu'
       setting is Power5 or later.
  
! 'has_arch_pwr6'
!      PowerPC target pre-defines macro _ARCH_PWR6 which means the '-mcpu'
       setting is Power6 or later.
  
! 'has_arch_pwr7'
!      PowerPC target pre-defines macro _ARCH_PWR7 which means the '-mcpu'
       setting is Power7 or later.
  
! 'has_arch_pwr8'
!      PowerPC target pre-defines macro _ARCH_PWR8 which means the '-mcpu'
       setting is Power8 or later.
  
! 'has_arch_pwr9'
!      PowerPC target pre-defines macro _ARCH_PWR9 which means the '-mcpu'
       setting is Power9 or later.
  
  7.2.3.12 RISC-V specific attributes
  ...................................
  
! 'rv32'
       Test system has an integer register width of 32 bits.
  
! 'rv64'
       Test system has an integer register width of 64 bits.
  
  7.2.3.13 Other hardware attributes
  ..................................
  
! 'autoincdec'
       Target supports autoincrement/decrement addressing.
  
! 'avx'
!      Target supports compiling 'avx' instructions.
  
! 'avx_runtime'
!      Target supports the execution of 'avx' instructions.
  
! 'avx2'
!      Target supports compiling 'avx2' instructions.
  
! 'avx2_runtime'
!      Target supports the execution of 'avx2' instructions.
  
! 'avxvnni'
!      Target supports the execution of 'avxvnni' instructions.
  
! 'avx512f'
!      Target supports compiling 'avx512f' instructions.
  
! 'avx512f_runtime'
!      Target supports the execution of 'avx512f' instructions.
  
! 'avx512vp2intersect'
!      Target supports the execution of 'avx512vp2intersect' instructions.
  
! 'avxifma'
!      Target supports the execution of 'avxifma' instructions.
  
! 'avxneconvert'
!      Target supports the execution of 'avxneconvert' instructions.
  
! 'avxvnniint8'
!      Target supports the execution of 'avxvnniint8' instructions.
  
! 'amx_tile'
!      Target supports the execution of 'amx-tile' instructions.
  
! 'amx_int8'
!      Target supports the execution of 'amx-int8' instructions.
  
! 'amx_bf16'
!      Target supports the execution of 'amx-bf16' instructions.
  
! 'amx_complex'
!      Target supports the execution of 'amx-complex' instructions.
  
! 'amx_fp16'
!      Target supports the execution of 'amx-fp16' instructions.
  
! 'cell_hw'
       Test system can execute AltiVec and Cell PPU instructions.
  
! 'clz'
       Target supports a clz optab on int.
  
! 'clzl'
       Target supports a clz optab on long.
  
! 'clzll'
       Target supports a clz optab on long long.
  
! 'ctz'
       Target supports a ctz optab on int.
  
! 'ctzl'
       Target supports a ctz optab on long.
  
! 'ctzll'
       Target supports a ctz optab on long long.
  
! 'cmpccxadd'
!      Target supports the execution of 'cmpccxadd' instructions.
  
! 'coldfire_fpu'
       Target uses a ColdFire FPU.
  
! 'divmod'
       Target supporting hardware divmod insn or divmod libcall.
  
! 'divmod_simode'
       Target supporting hardware divmod insn or divmod libcall for
       SImode.
  
! 'hard_float'
       Target supports FPU instructions.
  
! 'non_strict_align'
       Target does not require strict alignment.
  
! 'pie_copyreloc'
       The x86-64 target linker supports PIE with copy reloc.
  
! 'popcount'
       Target supports a popcount optab on int.
  
! 'popcountl'
       Target supports a popcount optab on long.
  
! 'popcountll'
       Target supports a popcount optab on long long.
  
! 'prefetchi'
!      Target supports the execution of 'prefetchi' instructions.
  
! 'raoint'
!      Target supports the execution of 'raoint' instructions.
  
! 'rdrand'
!      Target supports x86 'rdrand' instruction.
  
! 'sqrt_insn'
       Target has a square root instruction that the compiler can
       generate.
  
! 'sse'
!      Target supports compiling 'sse' instructions.
  
! 'sse_runtime'
!      Target supports the execution of 'sse' instructions.
  
! 'sse2'
!      Target supports compiling 'sse2' instructions.
  
! 'sse2_runtime'
!      Target supports the execution of 'sse2' instructions.
  
! 'sync_char_short'
!      Target supports atomic operations on 'char' and 'short'.
  
! 'sync_int_long'
!      Target supports atomic operations on 'int' and 'long'.
  
! 'ultrasparc_hw'
       Test environment appears to run executables on a simulator that
!      accepts only 'EM_SPARC' executables and chokes on 'EM_SPARC32PLUS'
!      or 'EM_SPARCV9' executables.
  
! 'vect_cmdline_needed'
       Target requires a command line argument to enable a SIMD
       instruction set.
  
! 'xorsign'
       Target supports the xorsign optab expansion.
  
  7.2.3.14 Environment attributes
  ...............................
  
! 'c'
       The language for the compiler under test is C.
  
! 'c++'
       The language for the compiler under test is C++.
  
! 'c99_runtime'
       Target provides a full C99 runtime.
  
! 'correct_iso_cpp_string_wchar_protos'
!      Target 'string.h' and 'wchar.h' headers provide C++ required
!      overloads for 'strchr' etc.  functions.
  
! 'd_runtime'
       Target provides the D runtime.
  
! 'd_runtime_has_std_library'
       Target provides the D standard library (Phobos).
  
! 'dummy_wcsftime'
!      Target uses a dummy 'wcsftime' function that always returns zero.
  
! 'fd_truncate'
       Target can truncate a file from a file descriptor, as used by
!      'libgfortran/io/unix.c:fd_truncate'; i.e. 'ftruncate' or 'chsize'.
  
! 'fenv'
!      Target provides 'fenv.h' include file.
  
! 'fenv_exceptions'
!      Target supports 'fenv.h' with all the standard IEEE exceptions and
       floating-point exceptions are raised by arithmetic operations.
  
! 'fenv_exceptions_dfp'
!      Target supports 'fenv.h' with all the standard IEEE exceptions and
       floating-point exceptions are raised by arithmetic operations for
       decimal floating point.
  
! 'fileio'
!      Target offers such file I/O library functions as 'fopen', 'fclose',
!      'tmpnam', and 'remove'.  This is a link-time requirement for the
       presence of the functions in the library; even if they fail at
       runtime, the requirement is still regarded as satisfied.
  
! 'freestanding'
!      Target is 'freestanding' as defined in section 4 of the C99
       standard.  Effectively, it is a target which supports no extra
       headers or libraries other than what is considered essential.
  
! 'gettimeofday'
!      Target supports 'gettimeofday'.
  
! 'init_priority'
       Target supports constructors with initialization priority
       arguments.
  
! 'inttypes_types'
!      Target has the basic signed and unsigned types in 'inttypes.h'.
       This is for tests that GCC's notions of these types agree with
!      those in the header, as some systems have only 'inttypes.h'.
  
! 'lax_strtofp'
       Target might have errors of a few ULP in string to floating-point
       conversion functions and overflow is not always detected correctly
       by those functions.
  
! 'mempcpy'
!      Target provides 'mempcpy' function.
  
! 'mmap'
!      Target supports 'mmap'.
  
! 'newlib'
       Target supports Newlib.
  
! 'newlib_nano_io'
!      GCC was configured with '--enable-newlib-nano-formatted-io', which
       reduces the code size of Newlib formatted I/O functions.
  
! 'posix_memalign'
!      Target supports 'posix_memalign'.
  
! 'pow10'
!      Target provides 'pow10' function.
  
! 'pthread'
!      Target can compile using 'pthread.h' with no errors or warnings.
  
! 'pthread_h'
!      Target has 'pthread.h'.
  
! 'sockets'
!      Target can compile using 'sys/socket.h' with no errors or warnings.
  
! 'run_expensive_tests'
       Expensive testcases (usually those that consume excessive amounts
       of CPU time) should be run on this target.  This can be enabled by
!      setting the 'GCC_TEST_RUN_EXPENSIVE' environment variable to a
       non-empty string.
  
! 'simulator'
       Test system runs executables on a simulator (i.e. slowly) rather
       than hardware (i.e. fast).
  
! 'signal'
!      Target has 'signal.h'.
  
! 'stabs'
       Target supports the stabs debugging format.
  
! 'stdint_types'
!      Target has the basic signed and unsigned C types in 'stdint.h'.
!      This will be obsolete when GCC ensures a working 'stdint.h' for all
       targets.
  
! 'stdint_types_mbig_endian'
!      Target accepts the option '-mbig-endian' and 'stdint.h' can be
!      included without error when '-mbig-endian' is passed.
  
! 'stpcpy'
!      Target provides 'stpcpy' function.
  
! 'sysconf'
!      Target supports 'sysconf'.
  
! 'trampolines'
       Target supports trampolines.
  
! 'two_plus_gigs'
       Target supports linking programs with 2+GiB of data.
  
! 'uclibc'
       Target supports uClibc.
  
! 'unwrapped'
       Target does not use a status wrapper.
  
! 'vxworks_kernel'
       Target is a VxWorks kernel.
  
! 'vxworks_rtp'
       Target is a VxWorks RTP.
  
! 'wchar'
       Target supports wide characters.
  
! 'weak_undefined'
       Target supports weak undefined symbols
  
  7.2.3.15 Other attributes
  .........................
  
! 'R_flag_in_section'
       Target supports the 'R' flag in .section directive in assembly
       inputs.
  
! 'automatic_stack_alignment'
       Target supports automatic stack alignment.
  
! 'branch_cost'
!      Target supports '-branch-cost=N'.
  
! 'const_volatile_readonly_section'
       Target places const volatile variables in readonly sections.
  
! 'cxa_atexit'
!      Target uses '__cxa_atexit'.
  
! 'default_packed'
       Target has packed layout of structure members by default.
  
! 'exceptions'
       Target supports exceptions.
  
! 'exceptions_enabled'
       Target supports exceptions and they are enabled in the current
       testing configuration.
  
! 'fgraphite'
       Target supports Graphite optimizations.
  
! 'fixed_point'
       Target supports fixed-point extension to C.
  
! 'fopenacc'
!      Target supports OpenACC via '-fopenacc'.
  
! 'fopenmp'
!      Target supports OpenMP via '-fopenmp'.
  
! 'fpic'
!      Target supports '-fpic' and '-fPIC'.
  
! 'freorder'
!      Target supports '-freorder-blocks-and-partition'.
  
! 'fstack_protector'
!      Target supports '-fstack-protector'.
  
! 'gas'
!      Target uses GNU 'as'.
  
! 'gc_sections'
!      Target supports '--gc-sections'.
  
! 'gld'
!      Target uses GNU 'ld'.
  
! 'keeps_null_pointer_checks'
       Target keeps null pointer checks, either due to the use of
!      '-fno-delete-null-pointer-checks' or hardwired into the target.
  
! 'llvm_binutils'
       Target is using an LLVM assembler and/or linker, instead of GNU
       Binutils.
  
! 'lra'
       Target supports local register allocator (LRA).
  
! 'lto'
       Compiler has been configured to support link-time optimization
       (LTO).
  
! 'lto_incremental'
       Compiler and linker support link-time optimization relocatable
!      linking with '-r' and '-flto' options.
  
! 'naked_functions'
!      Target supports the 'naked' function attribute.
  
! 'named_sections'
       Target supports named sections.
  
! 'natural_alignment_32'
       Target uses natural alignment (aligned to type size) for types of
       32 bits or less.
  
! 'tail_call'
       Target supports tail-call optimizations.
  
! 'target_natural_alignment_64'
       Target uses natural alignment (aligned to type size) for types of
       64 bits or less.
  
! 'no_alignment_constraints'
       Target defines __BIGGEST_ALIGNMENT__=1.  Hence target imposes no
       alignment constraints.  This is similar, but not necessarily the
!      same as *note default_packed::.  Although 'BIGGEST_FIELD_ALIGNMENT'
!      defaults to 'BIGGEST_ALIGNMENT' for most targets, it is possible
       for a target to set those two with different values and have
       different alignment constraints for aggregate and non-aggregate
       types.
  
! 'noinit'
!      Target supports the 'noinit' variable attribute.
  
! 'nonpic'
       Target does not generate PIC by default.
  
! 'o_flag_in_section'
       Target supports the 'o' flag in .section directive in assembly
       inputs.
  
! 'offload_gcn'
       Target has been configured for OpenACC/OpenMP offloading on AMD
       GCN.
  
! 'persistent'
!      Target supports the 'persistent' variable attribute.
  
! 'pie_enabled'
       Target generates PIE by default.
  
! 'pcc_bitfield_type_matters'
!      Target defines 'PCC_BITFIELD_TYPE_MATTERS'.
  
! 'pe_aligned_commons'
!      Target supports '-mpe-aligned-commons'.
  
! 'pie'
!      Target supports '-pie', '-fpie' and '-fPIE'.
  
! 'rdynamic'
!      Target supports '-rdynamic'.
  
! 'scalar_all_fma'
!      Target supports all four fused multiply-add optabs for both 'float'
!      and 'double'.  These optabs are: 'fma_optab', 'fms_optab',
!      'fnma_optab' and 'fnms_optab'.
  
! 'section_anchors'
       Target supports section anchors.
  
! 'short_enums'
       Target defaults to short enums.
  
! 'stack_size'
       Target has limited stack size.  The stack size limit can be
       obtained using the STACK_SIZE macro defined by *note
!      'dg-add-options' feature 'stack_size': stack_size_ao.
  
! 'static'
!      Target supports '-static'.
  
! 'static_libgfortran'
!      Target supports statically linking 'libgfortran'.
  
! 'string_merging'
       Target supports merging string constants at link time.
  
! 'ucn'
       Target supports compiling and assembling UCN.
  
! 'ucn_nocache'
       Including the options used to compile this particular test, the
       target supports compiling and assembling UCN.
  
! 'unaligned_stack'
!      Target does not guarantee that its 'STACK_BOUNDARY' is greater than
       or equal to the required vector alignment.
  
! 'vector_alignment_reachable'
       Vector alignment is reachable for types of 32 bits or less.
  
! 'vector_alignment_reachable_for_64bit'
       Vector alignment is reachable for types of 64 bits or less.
  
! 'vma_equals_lma'
       Target generates executable with VMA equal to LMA for .data
       section.
  
! 'wchar_t_char16_t_compatible'
!      Target supports 'wchar_t' that is compatible with 'char16_t'.
  
! 'wchar_t_char32_t_compatible'
!      Target supports 'wchar_t' that is compatible with 'char32_t'.
  
! 'comdat_group'
       Target uses comdat groups.
  
! 'indirect_calls'
       Target supports indirect calls, i.e.  calls where the target is not
       constant.
  
! 'lgccjit'
       Target supports -lgccjit, i.e.  libgccjit.so can be linked into jit
       tests.
  
! '__OPTIMIZE__'
!      Optimizations are enabled ('__OPTIMIZE__') per the current compiler
       flags.
  
! 7.2.3.16 Local to tests in 'gcc.target/i386'
  ............................................
  
! '3dnow'
!      Target supports compiling '3dnow' instructions.
  
! 'aes'
!      Target supports compiling 'aes' instructions.
  
! 'fma4'
!      Target supports compiling 'fma4' instructions.
  
! 'mfentry'
!      Target supports the '-mfentry' option that alters the position of
       profiling calls such that they precede the prologue.
  
! 'ms_hook_prologue'
!      Target supports attribute 'ms_hook_prologue'.
  
! 'pclmul'
!      Target supports compiling 'pclmul' instructions.
  
! 'sse3'
!      Target supports compiling 'sse3' instructions.
  
! 'sse4'
!      Target supports compiling 'sse4' instructions.
  
! 'sse4a'
!      Target supports compiling 'sse4a' instructions.
  
! 'ssse3'
!      Target supports compiling 'ssse3' instructions.
  
! 'vaes'
!      Target supports compiling 'vaes' instructions.
  
! 'vpclmul'
!      Target supports compiling 'vpclmul' instructions.
  
! 'xop'
!      Target supports compiling 'xop' instructions.
  
! 7.2.3.17 Local to tests in 'gcc.test-framework'
  ...............................................
  
! 'no'
       Always returns 0.
  
! 'yes'
       Always returns 1.
  
  
  File: gccint.info,  Node: Add Options,  Next: Require Support,  Prev: Effective-Target Keywords,  Up: Test Directives
  
! 7.2.4 Features for 'dg-add-options'
  -----------------------------------
  
! The supported values of FEATURE for directive 'dg-add-options' are:
  
! 'arm_fp'
!      '__ARM_FP' definition.  Only ARM targets support this feature, and
       only then in certain modes; see the *note arm_fp_ok effective
       target keyword: arm_fp_ok.
  
! 'arm_fp_dp'
!      '__ARM_FP' definition with double-precision support.  Only ARM
       targets support this feature, and only then in certain modes; see
       the *note arm_fp_dp_ok effective target keyword: arm_fp_dp_ok.
  
! 'arm_neon'
       NEON support.  Only ARM targets support this feature, and only then
       in certain modes; see the *note arm_neon_ok effective target
       keyword: arm_neon_ok.
  
! 'arm_fp16'
       VFP half-precision floating point support.  This does not select
       the FP16 format; for that, use *note arm_fp16_ieee: arm_fp16_ieee.
       or *note arm_fp16_alternative: arm_fp16_alternative. instead.  This
--- 4959,6242 ----
       using only two-vector permutes, regardless of how long the sequence
       is.
  
! ‘vect_perm3_int’
!      Like ‘vect_perm3_byte’, but for 32-bit elements.
  
! ‘vect_perm3_short’
!      Like ‘vect_perm3_byte’, but for 16-bit elements.
  
! ‘vect_shift’
       Target supports a hardware vector shift operation.
  
! ‘vect_unaligned_possible’
       Target prefers vectors to have an alignment greater than element
       alignment, but also allows unaligned vector accesses in some
       circumstances.
  
! ‘vect_variable_length’
       Target has variable-length vectors.
  
! ‘vect64’
       Target supports vectors of 64 bits.
  
! ‘vect32’
       Target supports vectors of 32 bits.
  
! ‘vect_widen_sum_hi_to_si’
!      Target supports a vector widening summation of ‘short’ operands
!      into ‘int’ results, or can promote (unpack) from ‘short’ to ‘int’.
  
! ‘vect_widen_sum_qi_to_hi’
!      Target supports a vector widening summation of ‘char’ operands into
!      ‘short’ results, or can promote (unpack) from ‘char’ to ‘short’.
  
! ‘vect_widen_sum_qi_to_si’
!      Target supports a vector widening summation of ‘char’ operands into
!      ‘int’ results.
  
! ‘vect_widen_mult_qi_to_hi’
!      Target supports a vector widening multiplication of ‘char’ operands
!      into ‘short’ results, or can promote (unpack) from ‘char’ to
!      ‘short’ and perform non-widening multiplication of ‘short’.
  
! ‘vect_widen_mult_hi_to_si’
!      Target supports a vector widening multiplication of ‘short’
!      operands into ‘int’ results, or can promote (unpack) from ‘short’
!      to ‘int’ and perform non-widening multiplication of ‘int’.
  
! ‘vect_widen_mult_si_to_di_pattern’
!      Target supports a vector widening multiplication of ‘int’ operands
!      into ‘long’ results.
  
! ‘vect_sdot_qi’
!      Target supports a vector dot-product of ‘signed char’.
  
! ‘vect_udot_qi’
!      Target supports a vector dot-product of ‘unsigned char’.
  
! ‘vect_usdot_qi’
       Target supports a vector dot-product where one operand of the
!      multiply is ‘signed char’ and the other of ‘unsigned char’.
  
! ‘vect_sdot_hi’
!      Target supports a vector dot-product of ‘signed short’.
  
! ‘vect_udot_hi’
!      Target supports a vector dot-product of ‘unsigned short’.
  
! ‘vect_pack_trunc’
!      Target supports a vector demotion (packing) of ‘short’ to ‘char’
!      and from ‘int’ to ‘short’ using modulo arithmetic.
  
! ‘vect_unpack’
!      Target supports a vector promotion (unpacking) of ‘char’ to ‘short’
!      and from ‘char’ to ‘int’.
  
! ‘vect_intfloat_cvt’
!      Target supports conversion from ‘signed int’ to ‘float’.
  
! ‘vect_uintfloat_cvt’
!      Target supports conversion from ‘unsigned int’ to ‘float’.
  
! ‘vect_floatint_cvt’
!      Target supports conversion from ‘float’ to ‘signed int’.
  
! ‘vect_floatuint_cvt’
!      Target supports conversion from ‘float’ to ‘unsigned int’.
  
! ‘vect_intdouble_cvt’
!      Target supports conversion from ‘signed int’ to ‘double’.
  
! ‘vect_doubleint_cvt’
!      Target supports conversion from ‘double’ to ‘signed int’.
  
! ‘vect_max_reduc’
       Target supports max reduction for vectors.
  
! ‘vect_sizes_16B_8B’
       Target supports 16- and 8-bytes vectors.
  
! ‘vect_sizes_32B_16B’
       Target supports 32- and 16-bytes vectors.
  
! ‘vect_logical_reduc’
       Target supports AND, IOR and XOR reduction on vectors.
  
! ‘vect_fold_extract_last’
!      Target supports the ‘fold_extract_last’ optab.
  
! ‘vect_len_load_store’
!      Target supports the ‘len_load’ and ‘len_store’ optabs.
  
! ‘vect_partial_vectors_usage_1’
       Target supports loop vectorization with partial vectors and
!      ‘vect-partial-vector-usage’ is set to 1.
  
! ‘vect_partial_vectors_usage_2’
       Target supports loop vectorization with partial vectors and
!      ‘vect-partial-vector-usage’ is set to 2.
  
! ‘vect_partial_vectors’
       Target supports loop vectorization with partial vectors and
!      ‘vect-partial-vector-usage’ is nonzero.
  
! ‘vect_slp_v2qi_store_align’
       Target supports vectorization of 2-byte char stores with 2-byte
!      aligned address at plain ‘-O2’.
  
! ‘vect_slp_v4qi_store_align’
       Target supports vectorization of 4-byte char stores with 4-byte
!      aligned address at plain ‘-O2’.
  
! ‘vect_slp_v4qi_store_unalign’
       Target supports vectorization of 4-byte char stores with unaligned
!      address at plain ‘-O2’.
  
! ‘struct_4char_block_move’
       Target supports block move for 8-byte aligned 4-byte size struct
       initialization.
  
! ‘vect_slp_v4qi_store_unalign_1’
       Target supports vectorization of 4-byte char stores with unaligned
!      address or store them with constant pool at plain ‘-O2’.
  
! ‘struct_8char_block_move’
       Target supports block move for 8-byte aligned 8-byte size struct
       initialization.
  
! ‘vect_slp_v8qi_store_unalign_1’
       Target supports vectorization of 8-byte char stores with unaligned
!      address or store them with constant pool at plain ‘-O2’.
  
! ‘struct_16char_block_move’
       Target supports block move for 8-byte aligned 16-byte size struct
       initialization.
  
! ‘vect_slp_v16qi_store_unalign_1’
       Target supports vectorization of 16-byte char stores with unaligned
!      address or store them with constant pool at plain ‘-O2’.
  
! ‘vect_slp_v2hi_store_align’
       Target supports vectorization of 4-byte short stores with 4-byte
!      aligned addressat plain ‘-O2’.
  
! ‘vect_slp_v2hi_store_unalign’
       Target supports vectorization of 4-byte short stores with unaligned
!      address at plain ‘-O2’.
  
! ‘vect_slp_v4hi_store_unalign’
       Target supports vectorization of 8-byte short stores with unaligned
!      address at plain ‘-O2’.
  
! ‘vect_slp_v2si_store_align’
       Target supports vectorization of 8-byte int stores with 8-byte
!      aligned address at plain ‘-O2’.
  
! ‘vect_slp_v4si_store_unalign’
       Target supports vectorization of 16-byte int stores with unaligned
!      address at plain ‘-O2’.
  
  7.2.3.5 Thread Local Storage attributes
  .......................................
  
! ‘tls’
       Target supports thread-local storage.
  
! ‘tls_native’
       Target supports native (rather than emulated) thread-local storage.
  
! ‘tls_runtime’
       Test system supports executing TLS executables.
  
  7.2.3.6 Decimal floating point attributes
  .........................................
  
! ‘dfp’
       Targets supports compiling decimal floating point extension to C.
  
! ‘dfp_nocache’
       Including the options used to compile this particular test, the
       target supports compiling decimal floating point extension to C.
  
! ‘dfprt’
       Test system can execute decimal floating point tests.
  
! ‘dfprt_nocache’
       Including the options used to compile this particular test, the
       test system can execute decimal floating point tests.
  
! ‘hard_dfp’
       Target generates decimal floating point instructions with current
       options.
  
! ‘dfp_bid’
       Target uses the BID format for decimal floating point.
  
  7.2.3.7 ARM-specific attributes
  ...............................
  
! ‘arm32’
       ARM target generates 32-bit code.
  
! ‘arm_little_endian’
       ARM target that generates little-endian code.
  
! ‘arm_eabi’
       ARM target adheres to the ABI for the ARM Architecture.
  
! ‘arm_fp_ok’
!      ARM target defines ‘__ARM_FP’ using ‘-mfloat-abi=softfp’ or
       equivalent options.  Some multilibs may be incompatible with these
       options.
  
! ‘arm_fp_dp_ok’
!      ARM target defines ‘__ARM_FP’ with double-precision support using
!      ‘-mfloat-abi=softfp’ or equivalent options.  Some multilibs may be
       incompatible with these options.
  
! ‘arm_hf_eabi’
       ARM target adheres to the VFP and Advanced SIMD Register Arguments
       variant of the ABI for the ARM Architecture (as selected with
!      ‘-mfloat-abi=hard’).
  
! ‘arm_softfloat’
       ARM target uses emulated floating point operations.
  
! ‘arm_hard_vfp_ok’
!      ARM target supports ‘-mfpu=vfp -mfloat-abi=hard’.  Some multilibs
       may be incompatible with these options.
  
! ‘arm_iwmmxt_ok’
!      ARM target supports ‘-mcpu=iwmmxt’.  Some multilibs may be
       incompatible with this option.
  
! ‘arm_neon’
       ARM target supports generating NEON instructions.
  
! ‘arm_tune_string_ops_prefer_neon’
       Test CPU tune supports inlining string operations with NEON
       instructions.
  
! ‘arm_neon_hw’
       Test system supports executing NEON instructions.
  
! ‘arm_neonv2_hw’
       Test system supports executing NEON v2 instructions.
  
! ‘arm_neon_ok’
!      ARM Target supports ‘-mfpu=neon -mfloat-abi=softfp’ or compatible
       options.  Some multilibs may be incompatible with these options.
  
! ‘arm_neon_ok_no_float_abi’
!      ARM Target supports NEON with ‘-mfpu=neon’, but without any
       -mfloat-abi= option.  Some multilibs may be incompatible with this
       option.
  
! ‘arm_neonv2_ok’
!      ARM Target supports ‘-mfpu=neon-vfpv4 -mfloat-abi=softfp’ or
       compatible options.  Some multilibs may be incompatible with these
       options.
  
! ‘arm_fp16_ok’
       Target supports options to generate VFP half-precision
       floating-point instructions.  Some multilibs may be incompatible
       with these options.  This test is valid for ARM only.
  
! ‘arm_fp16_hw’
       Target supports executing VFP half-precision floating-point
       instructions.  This test is valid for ARM only.
  
! ‘arm_neon_fp16_ok’
!      ARM Target supports ‘-mfpu=neon-fp16 -mfloat-abi=softfp’ or
!      compatible options, including ‘-mfp16-format=ieee’ if necessary to
!      obtain the ‘__fp16’ type.  Some multilibs may be incompatible with
       these options.
  
! ‘arm_neon_fp16_hw’
       Test system supports executing Neon half-precision float
       instructions.  (Implies previous.)
  
! ‘arm_fp16_alternative_ok’
       ARM target supports the ARM FP16 alternative format.  Some
       multilibs may be incompatible with the options needed.
  
! ‘arm_fp16_none_ok’
       ARM target supports specifying none as the ARM FP16 format.
  
! ‘arm_thumb1_ok’
!      ARM target generates Thumb-1 code for ‘-mthumb’.
  
! ‘arm_thumb2_ok’
!      ARM target generates Thumb-2 code for ‘-mthumb’.
  
! ‘arm_nothumb’
       ARM target that is not using Thumb.
  
! ‘arm_vfp_ok’
!      ARM target supports ‘-mfpu=vfp -mfloat-abi=softfp’.  Some multilibs
       may be incompatible with these options.
  
! ‘arm_vfp3_ok’
!      ARM target supports ‘-mfpu=vfp3 -mfloat-abi=softfp’.  Some
       multilibs may be incompatible with these options.
  
! ‘arm_arch_v8a_hard_ok’
!      The compiler is targeting ‘arm*-*-*’ and can compile and assemble
!      code using the options ‘-march=armv8-a -mfpu=neon-fp-armv8
!      -mfloat-abi=hard’.  This is not enough to guarantee that linking
       works.
  
! ‘arm_arch_v8a_hard_multilib’
!      The compiler is targeting ‘arm*-*-*’ and can build programs using
!      the options ‘-march=armv8-a -mfpu=neon-fp-armv8 -mfloat-abi=hard’.
       The target can also run the resulting binaries.
  
! ‘arm_v8_vfp_ok’
!      ARM target supports ‘-mfpu=fp-armv8 -mfloat-abi=softfp’.  Some
       multilibs may be incompatible with these options.
  
! ‘arm_v8_neon_ok’
!      ARM target supports ‘-mfpu=neon-fp-armv8 -mfloat-abi=softfp’.  Some
       multilibs may be incompatible with these options.
  
! ‘arm_v8_1a_neon_ok’
       ARM target supports options to generate ARMv8.1-A Adv.SIMD
       instructions.  Some multilibs may be incompatible with these
       options.
  
! ‘arm_v8_1a_neon_hw’
       ARM target supports executing ARMv8.1-A Adv.SIMD instructions.
       Some multilibs may be incompatible with the options needed.
       Implies arm_v8_1a_neon_ok.
  
! ‘arm_acq_rel’
       ARM target supports acquire-release instructions.
  
! ‘arm_v8_2a_fp16_scalar_ok’
       ARM target supports options to generate instructions for ARMv8.2-A
       and scalar instructions from the FP16 extension.  Some multilibs
       may be incompatible with these options.
  
! ‘arm_v8_2a_fp16_scalar_hw’
       ARM target supports executing instructions for ARMv8.2-A and scalar
       instructions from the FP16 extension.  Some multilibs may be
       incompatible with these options.  Implies arm_v8_2a_fp16_neon_ok.
  
! ‘arm_v8_2a_fp16_neon_ok’
       ARM target supports options to generate instructions from ARMv8.2-A
       with the FP16 extension.  Some multilibs may be incompatible with
       these options.  Implies arm_v8_2a_fp16_scalar_ok.
  
! ‘arm_v8_2a_fp16_neon_hw’
       ARM target supports executing instructions from ARMv8.2-A with the
       FP16 extension.  Some multilibs may be incompatible with these
       options.  Implies arm_v8_2a_fp16_neon_ok and
       arm_v8_2a_fp16_scalar_hw.
  
! ‘arm_v8_2a_dotprod_neon_ok’
       ARM target supports options to generate instructions from ARMv8.2-A
       with the Dot Product extension.  Some multilibs may be incompatible
       with these options.
  
! ‘arm_v8_2a_dotprod_neon_hw’
       ARM target supports executing instructions from ARMv8.2-A with the
       Dot Product extension.  Some multilibs may be incompatible with
       these options.  Implies arm_v8_2a_dotprod_neon_ok.
  
! ‘arm_v8_2a_i8mm_neon_hw’
       ARM target supports executing instructions from ARMv8.2-A with the
       8-bit Matrix Multiply extension.  Some multilibs may be
       incompatible with these options.  Implies arm_v8_2a_i8mm_ok.
  
! ‘arm_fp16fml_neon_ok’
!      ARM target supports extensions to generate the ‘VFMAL’ and ‘VFMLS’
       half-precision floating-point instructions available from ARMv8.2-A
       and onwards.  Some multilibs may be incompatible with these
       options.
  
! ‘arm_v8_2a_bf16_neon_ok’
       ARM target supports options to generate instructions from ARMv8.2-A
       with the BFloat16 extension (bf16).  Some multilibs may be
       incompatible with these options.
  
! ‘arm_v8_2a_i8mm_ok’
       ARM target supports options to generate instructions from ARMv8.2-A
       with the 8-Bit Integer Matrix Multiply extension (i8mm).  Some
       multilibs may be incompatible with these options.
  
! ‘arm_v8_1m_mve_ok’
       ARM target supports options to generate instructions from ARMv8.1-M
       with the M-Profile Vector Extension (MVE). Some multilibs may be
       incompatible with these options.
  
! ‘arm_v8_1m_mve_fp_ok’
       ARM target supports options to generate instructions from ARMv8.1-M
       with the Half-precision floating-point instructions (HP),
       Floating-point Extension (FP) along with M-Profile Vector Extension
       (MVE). Some multilibs may be incompatible with these options.
  
! ‘arm_mve_hw’
       Test system supports executing MVE instructions.
  
! ‘arm_v8m_main_cde’
       ARM target supports options to generate instructions from ARMv8-M
       with the Custom Datapath Extension (CDE). Some multilibs may be
       incompatible with these options.
  
! ‘arm_v8m_main_cde_fp’
       ARM target supports options to generate instructions from ARMv8-M
       with the Custom Datapath Extension (CDE) and floating-point (VFP).
       Some multilibs may be incompatible with these options.
  
! ‘arm_v8_1m_main_cde_mve’
       ARM target supports options to generate instructions from ARMv8.1-M
       with the Custom Datapath Extension (CDE) and M-Profile Vector
       Extension (MVE). Some multilibs may be incompatible with these
       options.
  
! ‘arm_pacbti_hw’
       Test system supports executing Pointer Authentication and Branch
       Target Identification instructions.
  
! ‘arm_prefer_ldrd_strd’
!      ARM target prefers ‘LDRD’ and ‘STRD’ instructions over ‘LDM’ and
!      ‘STM’ instructions.
  
! ‘arm_thumb1_movt_ok’
!      ARM target generates Thumb-1 code for ‘-mthumb’ with ‘MOVW’ and
!      ‘MOVT’ instructions available.
  
! ‘arm_thumb1_cbz_ok’
!      ARM target generates Thumb-1 code for ‘-mthumb’ with ‘CBZ’ and
!      ‘CBNZ’ instructions available.
  
! ‘arm_divmod_simode’
       ARM target for which divmod transform is disabled, if it supports
       hardware div instruction.
  
! ‘arm_cmse_ok’
       ARM target supports ARMv8-M Security Extensions, enabled by the
!      ‘-mcmse’ option.
  
! ‘arm_cmse_hw’
       Test system supports executing CMSE instructions.
  
! ‘arm_coproc1_ok’
!      ARM target supports the following coprocessor instructions: ‘CDP’,
!      ‘LDC’, ‘STC’, ‘MCR’ and ‘MRC’.
  
! ‘arm_coproc2_ok’
       ARM target supports all the coprocessor instructions also listed as
       supported in *note arm_coproc1_ok:: in addition to the following:
!      ‘CDP2’, ‘LDC2’, ‘LDC2l’, ‘STC2’, ‘STC2l’, ‘MCR2’ and ‘MRC2’.
  
! ‘arm_coproc3_ok’
       ARM target supports all the coprocessor instructions also listed as
       supported in *note arm_coproc2_ok:: in addition the following:
!      ‘MCRR’ and ‘MRRC’.
  
! ‘arm_coproc4_ok’
       ARM target supports all the coprocessor instructions also listed as
       supported in *note arm_coproc3_ok:: in addition the following:
!      ‘MCRR2’ and ‘MRRC2’.
  
! ‘arm_simd32_ok’
       ARM Target supports options suitable for accessing the SIMD32
!      intrinsics from ‘arm_acle.h’.  Some multilibs may be incompatible
       with these options.
  
! ‘arm_sat_ok’
       ARM Target supports options suitable for accessing the saturation
!      intrinsics from ‘arm_acle.h’.  Some multilibs may be incompatible
       with these options.
  
! ‘arm_dsp_ok’
       ARM Target supports options suitable for accessing the DSP
!      intrinsics from ‘arm_acle.h’.  Some multilibs may be incompatible
       with these options.
  
! ‘arm_softfp_ok’
!      ARM target supports the ‘-mfloat-abi=softfp’ option.
  
! ‘arm_hard_ok’
!      ARM target supports the ‘-mfloat-abi=hard’ option.
  
! ‘arm_mve’
       ARM target supports generating MVE instructions.
  
! ‘arm_v8_1_lob_ok’
       ARM Target supports executing the Armv8.1-M Mainline Low Overhead
!      Loop instructions ‘DLS’ and ‘LE’.  Some multilibs may be
       incompatible with these options.
  
! ‘arm_thumb2_no_arm_v8_1_lob’
       ARM target where Thumb-2 is used without options but does not
       support executing the Armv8.1-M Mainline Low Overhead Loop
!      instructions ‘DLS’ and ‘LE’.
  
! ‘arm_thumb2_ok_no_arm_v8_1_lob’
!      ARM target generates Thumb-2 code for ‘-mthumb’ but does not
       support executing the Armv8.1-M Mainline Low Overhead Loop
!      instructions ‘DLS’ and ‘LE’.
  
! ‘mbranch_protection_ok’
!      ARM target supporting ‘-mbranch-protection=standard’.
  
! ‘arm_pacbti_hw’
       Test system supports for executing non nop pacbti instructions.
  
  7.2.3.8 AArch64-specific attributes
  ...................................
  
! ‘aarch64_asm__ok’
!      AArch64 assembler supports the architecture extension ‘ext’ via the
!      ‘.arch_extension’ pseudo-op.
! ‘aarch64_tiny’
       AArch64 target which generates instruction sequences for tiny
       memory model.
! ‘aarch64_small’
       AArch64 target which generates instruction sequences for small
       memory model.
! ‘aarch64_large’
       AArch64 target which generates instruction sequences for large
       memory model.
! ‘aarch64_little_endian’
       AArch64 target which generates instruction sequences for little
       endian.
! ‘aarch64_big_endian’
       AArch64 target which generates instruction sequences for big
       endian.
! ‘aarch64_small_fpic’
       Binutils installed on test system supports relocation types
       required by -fpic for AArch64 small memory model.
! ‘aarch64_sve_hw’
       AArch64 target that is able to generate and execute SVE code
       (regardless of whether it does so by default).
! ‘aarch64_sve128_hw’
! ‘aarch64_sve256_hw’
! ‘aarch64_sve512_hw’
! ‘aarch64_sve1024_hw’
! ‘aarch64_sve2048_hw’
!      Like ‘aarch64_sve_hw’, but also test for an exact hardware vector
       length.
  
! ‘aarch64_fjcvtzs_hw’
       AArch64 target that is able to generate and execute armv8.3-a
       FJCVTZS instruction.
  
  7.2.3.9 MIPS-specific attributes
  ................................
  
! ‘mips64’
       MIPS target supports 64-bit instructions.
  
! ‘nomips16’
       MIPS target does not produce MIPS16 code.
  
! ‘mips16_attribute’
       MIPS target can generate MIPS16 code.
  
! ‘mips_loongson’
       MIPS target is a Loongson-2E or -2F target using an ABI that
       supports the Loongson vector modes.
  
! ‘mips_msa’
!      MIPS target supports ‘-mmsa’, MIPS SIMD Architecture (MSA).
  
! ‘mips_newabi_large_long_double’
!      MIPS target supports ‘long double’ larger than ‘double’ when using
       the new ABI.
  
! ‘mpaired_single’
!      MIPS target supports ‘-mpaired-single’.
  
  7.2.3.10 MSP430-specific attributes
  ...................................
  
! ‘msp430_small’
!      MSP430 target has the small memory model enabled (‘-msmall’).
  
! ‘msp430_large’
!      MSP430 target has the large memory model enabled (‘-mlarge’).
  
  7.2.3.11 PowerPC-specific attributes
  ....................................
  
! ‘dfp_hw’
       PowerPC target supports executing hardware DFP instructions.
  
! ‘p8vector_hw’
       PowerPC target supports executing VSX instructions (ISA 2.07).
  
! ‘powerpc64’
       Test system supports executing 64-bit instructions.
  
! ‘powerpc_altivec’
       PowerPC target supports AltiVec.
  
! ‘powerpc_altivec_ok’
!      PowerPC target supports ‘-maltivec’.
  
! ‘powerpc_eabi_ok’
!      PowerPC target supports ‘-meabi’.
  
! ‘powerpc_elfv2’
!      PowerPC target supports ‘-mabi=elfv2’.
  
! ‘powerpc_fprs’
       PowerPC target supports floating-point registers.
  
! ‘powerpc_hard_double’
       PowerPC target supports hardware double-precision floating-point.
  
! ‘powerpc_htm_ok’
!      PowerPC target supports ‘-mhtm’
  
! ‘powerpc_p8vector_ok’
!      PowerPC target supports ‘-mpower8-vector’
  
! ‘powerpc_popcntb_ok’
!      PowerPC target supports the ‘popcntb’ instruction, indicating that
!      this target supports ‘-mcpu=power5’.
  
! ‘powerpc_ppu_ok’
!      PowerPC target supports ‘-mcpu=cell’.
  
! ‘powerpc_spe’
       PowerPC target supports PowerPC SPE.
  
! ‘powerpc_spe_nocache’
       Including the options used to compile this particular test, the
       PowerPC target supports PowerPC SPE.
  
! ‘powerpc_spu’
       PowerPC target supports PowerPC SPU.
  
! ‘powerpc_vsx_ok’
!      PowerPC target supports ‘-mvsx’.
  
! ‘powerpc_405_nocache’
       Including the options used to compile this particular test, the
       PowerPC target supports PowerPC 405.
  
! ‘ppc_recip_hw’
       PowerPC target supports executing reciprocal estimate instructions.
  
! ‘vmx_hw’
       PowerPC target supports executing AltiVec instructions.
  
! ‘vsx_hw’
       PowerPC target supports executing VSX instructions (ISA 2.06).
  
! ‘has_arch_pwr5’
!      PowerPC target pre-defines macro _ARCH_PWR5 which means the ‘-mcpu’
       setting is Power5 or later.
  
! ‘has_arch_pwr6’
!      PowerPC target pre-defines macro _ARCH_PWR6 which means the ‘-mcpu’
       setting is Power6 or later.
  
! ‘has_arch_pwr7’
!      PowerPC target pre-defines macro _ARCH_PWR7 which means the ‘-mcpu’
       setting is Power7 or later.
  
! ‘has_arch_pwr8’
!      PowerPC target pre-defines macro _ARCH_PWR8 which means the ‘-mcpu’
       setting is Power8 or later.
  
! ‘has_arch_pwr9’
!      PowerPC target pre-defines macro _ARCH_PWR9 which means the ‘-mcpu’
       setting is Power9 or later.
  
  7.2.3.12 RISC-V specific attributes
  ...................................
  
! ‘rv32’
       Test system has an integer register width of 32 bits.
  
! ‘rv64’
       Test system has an integer register width of 64 bits.
  
  7.2.3.13 Other hardware attributes
  ..................................
  
! ‘autoincdec’
       Target supports autoincrement/decrement addressing.
  
! ‘avx’
!      Target supports compiling ‘avx’ instructions.
  
! ‘avx_runtime’
!      Target supports the execution of ‘avx’ instructions.
  
! ‘avx2’
!      Target supports compiling ‘avx2’ instructions.
  
! ‘avx2_runtime’
!      Target supports the execution of ‘avx2’ instructions.
  
! ‘avxvnni’
!      Target supports the execution of ‘avxvnni’ instructions.
  
! ‘avx512f’
!      Target supports compiling ‘avx512f’ instructions.
  
! ‘avx512f_runtime’
!      Target supports the execution of ‘avx512f’ instructions.
  
! ‘avx512vp2intersect’
!      Target supports the execution of ‘avx512vp2intersect’ instructions.
  
! ‘avxifma’
!      Target supports the execution of ‘avxifma’ instructions.
  
! ‘avxneconvert’
!      Target supports the execution of ‘avxneconvert’ instructions.
  
! ‘avxvnniint8’
!      Target supports the execution of ‘avxvnniint8’ instructions.
  
! ‘amx_tile’
!      Target supports the execution of ‘amx-tile’ instructions.
  
! ‘amx_int8’
!      Target supports the execution of ‘amx-int8’ instructions.
  
! ‘amx_bf16’
!      Target supports the execution of ‘amx-bf16’ instructions.
  
! ‘amx_complex’
!      Target supports the execution of ‘amx-complex’ instructions.
  
! ‘amx_fp16’
!      Target supports the execution of ‘amx-fp16’ instructions.
  
! ‘cell_hw’
       Test system can execute AltiVec and Cell PPU instructions.
  
! ‘clz’
       Target supports a clz optab on int.
  
! ‘clzl’
       Target supports a clz optab on long.
  
! ‘clzll’
       Target supports a clz optab on long long.
  
! ‘ctz’
       Target supports a ctz optab on int.
  
! ‘ctzl’
       Target supports a ctz optab on long.
  
! ‘ctzll’
       Target supports a ctz optab on long long.
  
! ‘cmpccxadd’
!      Target supports the execution of ‘cmpccxadd’ instructions.
  
! ‘coldfire_fpu’
       Target uses a ColdFire FPU.
  
! ‘divmod’
       Target supporting hardware divmod insn or divmod libcall.
  
! ‘divmod_simode’
       Target supporting hardware divmod insn or divmod libcall for
       SImode.
  
! ‘hard_float’
       Target supports FPU instructions.
  
! ‘non_strict_align’
       Target does not require strict alignment.
  
! ‘pie_copyreloc’
       The x86-64 target linker supports PIE with copy reloc.
  
! ‘popcount’
       Target supports a popcount optab on int.
  
! ‘popcountl’
       Target supports a popcount optab on long.
  
! ‘popcountll’
       Target supports a popcount optab on long long.
  
! ‘prefetchi’
!      Target supports the execution of ‘prefetchi’ instructions.
  
! ‘raoint’
!      Target supports the execution of ‘raoint’ instructions.
  
! ‘rdrand’
!      Target supports x86 ‘rdrand’ instruction.
  
! ‘sqrt_insn’
       Target has a square root instruction that the compiler can
       generate.
  
! ‘sse’
!      Target supports compiling ‘sse’ instructions.
  
! ‘sse_runtime’
!      Target supports the execution of ‘sse’ instructions.
  
! ‘sse2’
!      Target supports compiling ‘sse2’ instructions.
  
! ‘sse2_runtime’
!      Target supports the execution of ‘sse2’ instructions.
  
! ‘sync_char_short’
!      Target supports atomic operations on ‘char’ and ‘short’.
  
! ‘sync_int_long’
!      Target supports atomic operations on ‘int’ and ‘long’.
  
! ‘ultrasparc_hw’
       Test environment appears to run executables on a simulator that
!      accepts only ‘EM_SPARC’ executables and chokes on ‘EM_SPARC32PLUS’
!      or ‘EM_SPARCV9’ executables.
  
! ‘vect_cmdline_needed’
       Target requires a command line argument to enable a SIMD
       instruction set.
  
! ‘xorsign’
       Target supports the xorsign optab expansion.
  
  7.2.3.14 Environment attributes
  ...............................
  
! ‘c’
       The language for the compiler under test is C.
  
! ‘c++’
       The language for the compiler under test is C++.
  
! ‘c99_runtime’
       Target provides a full C99 runtime.
  
! ‘correct_iso_cpp_string_wchar_protos’
!      Target ‘string.h’ and ‘wchar.h’ headers provide C++ required
!      overloads for ‘strchr’ etc.  functions.
  
! ‘d_runtime’
       Target provides the D runtime.
  
! ‘d_runtime_has_std_library’
       Target provides the D standard library (Phobos).
  
! ‘dummy_wcsftime’
!      Target uses a dummy ‘wcsftime’ function that always returns zero.
  
! ‘fd_truncate’
       Target can truncate a file from a file descriptor, as used by
!      ‘libgfortran/io/unix.c:fd_truncate’; i.e. ‘ftruncate’ or ‘chsize’.
  
! ‘fenv’
!      Target provides ‘fenv.h’ include file.
  
! ‘fenv_exceptions’
!      Target supports ‘fenv.h’ with all the standard IEEE exceptions and
       floating-point exceptions are raised by arithmetic operations.
  
! ‘fenv_exceptions_dfp’
!      Target supports ‘fenv.h’ with all the standard IEEE exceptions and
       floating-point exceptions are raised by arithmetic operations for
       decimal floating point.
  
! ‘fileio’
!      Target offers such file I/O library functions as ‘fopen’, ‘fclose’,
!      ‘tmpnam’, and ‘remove’.  This is a link-time requirement for the
       presence of the functions in the library; even if they fail at
       runtime, the requirement is still regarded as satisfied.
  
! ‘freestanding’
!      Target is ‘freestanding’ as defined in section 4 of the C99
       standard.  Effectively, it is a target which supports no extra
       headers or libraries other than what is considered essential.
  
! ‘gettimeofday’
!      Target supports ‘gettimeofday’.
  
! ‘init_priority’
       Target supports constructors with initialization priority
       arguments.
  
! ‘inttypes_types’
!      Target has the basic signed and unsigned types in ‘inttypes.h’.
       This is for tests that GCC's notions of these types agree with
!      those in the header, as some systems have only ‘inttypes.h’.
  
! ‘lax_strtofp’
       Target might have errors of a few ULP in string to floating-point
       conversion functions and overflow is not always detected correctly
       by those functions.
  
! ‘mempcpy’
!      Target provides ‘mempcpy’ function.
  
! ‘mmap’
!      Target supports ‘mmap’.
  
! ‘newlib’
       Target supports Newlib.
  
! ‘newlib_nano_io’
!      GCC was configured with ‘--enable-newlib-nano-formatted-io’, which
       reduces the code size of Newlib formatted I/O functions.
  
! ‘posix_memalign’
!      Target supports ‘posix_memalign’.
  
! ‘pow10’
!      Target provides ‘pow10’ function.
  
! ‘pthread’
!      Target can compile using ‘pthread.h’ with no errors or warnings.
  
! ‘pthread_h’
!      Target has ‘pthread.h’.
  
! ‘sockets’
!      Target can compile using ‘sys/socket.h’ with no errors or warnings.
  
! ‘run_expensive_tests’
       Expensive testcases (usually those that consume excessive amounts
       of CPU time) should be run on this target.  This can be enabled by
!      setting the ‘GCC_TEST_RUN_EXPENSIVE’ environment variable to a
       non-empty string.
  
! ‘simulator’
       Test system runs executables on a simulator (i.e. slowly) rather
       than hardware (i.e. fast).
  
! ‘signal’
!      Target has ‘signal.h’.
  
! ‘stabs’
       Target supports the stabs debugging format.
  
! ‘stdint_types’
!      Target has the basic signed and unsigned C types in ‘stdint.h’.
!      This will be obsolete when GCC ensures a working ‘stdint.h’ for all
       targets.
  
! ‘stdint_types_mbig_endian’
!      Target accepts the option ‘-mbig-endian’ and ‘stdint.h’ can be
!      included without error when ‘-mbig-endian’ is passed.
  
! ‘stpcpy’
!      Target provides ‘stpcpy’ function.
  
! ‘sysconf’
!      Target supports ‘sysconf’.
  
! ‘trampolines’
       Target supports trampolines.
  
! ‘two_plus_gigs’
       Target supports linking programs with 2+GiB of data.
  
! ‘uclibc’
       Target supports uClibc.
  
! ‘unwrapped’
       Target does not use a status wrapper.
  
! ‘vxworks_kernel’
       Target is a VxWorks kernel.
  
! ‘vxworks_rtp’
       Target is a VxWorks RTP.
  
! ‘wchar’
       Target supports wide characters.
  
! ‘weak_undefined’
       Target supports weak undefined symbols
  
  7.2.3.15 Other attributes
  .........................
  
! ‘R_flag_in_section’
       Target supports the 'R' flag in .section directive in assembly
       inputs.
  
! ‘automatic_stack_alignment’
       Target supports automatic stack alignment.
  
! ‘branch_cost’
!      Target supports ‘-branch-cost=N’.
  
! ‘const_volatile_readonly_section’
       Target places const volatile variables in readonly sections.
  
! ‘cxa_atexit’
!      Target uses ‘__cxa_atexit’.
  
! ‘default_packed’
       Target has packed layout of structure members by default.
  
! ‘exceptions’
       Target supports exceptions.
  
! ‘exceptions_enabled’
       Target supports exceptions and they are enabled in the current
       testing configuration.
  
! ‘fgraphite’
       Target supports Graphite optimizations.
  
! ‘fixed_point’
       Target supports fixed-point extension to C.
  
! ‘fopenacc’
!      Target supports OpenACC via ‘-fopenacc’.
  
! ‘fopenmp’
!      Target supports OpenMP via ‘-fopenmp’.
  
! ‘fpic’
!      Target supports ‘-fpic’ and ‘-fPIC’.
  
! ‘freorder’
!      Target supports ‘-freorder-blocks-and-partition’.
  
! ‘fstack_protector’
!      Target supports ‘-fstack-protector’.
  
! ‘gas’
!      Target uses GNU ‘as’.
  
! ‘gc_sections’
!      Target supports ‘--gc-sections’.
  
! ‘gld’
!      Target uses GNU ‘ld’.
  
! ‘keeps_null_pointer_checks’
       Target keeps null pointer checks, either due to the use of
!      ‘-fno-delete-null-pointer-checks’ or hardwired into the target.
  
! ‘llvm_binutils’
       Target is using an LLVM assembler and/or linker, instead of GNU
       Binutils.
  
! ‘lra’
       Target supports local register allocator (LRA).
  
! ‘lto’
       Compiler has been configured to support link-time optimization
       (LTO).
  
! ‘lto_incremental’
       Compiler and linker support link-time optimization relocatable
!      linking with ‘-r’ and ‘-flto’ options.
  
! ‘naked_functions’
!      Target supports the ‘naked’ function attribute.
  
! ‘named_sections’
       Target supports named sections.
  
! ‘natural_alignment_32’
       Target uses natural alignment (aligned to type size) for types of
       32 bits or less.
  
! ‘tail_call’
       Target supports tail-call optimizations.
  
! ‘target_natural_alignment_64’
       Target uses natural alignment (aligned to type size) for types of
       64 bits or less.
  
! ‘no_alignment_constraints’
       Target defines __BIGGEST_ALIGNMENT__=1.  Hence target imposes no
       alignment constraints.  This is similar, but not necessarily the
!      same as *note default_packed::.  Although ‘BIGGEST_FIELD_ALIGNMENT’
!      defaults to ‘BIGGEST_ALIGNMENT’ for most targets, it is possible
       for a target to set those two with different values and have
       different alignment constraints for aggregate and non-aggregate
       types.
  
! ‘noinit’
!      Target supports the ‘noinit’ variable attribute.
  
! ‘nonpic’
       Target does not generate PIC by default.
  
! ‘o_flag_in_section’
       Target supports the 'o' flag in .section directive in assembly
       inputs.
  
! ‘offload_gcn’
       Target has been configured for OpenACC/OpenMP offloading on AMD
       GCN.
  
! ‘persistent’
!      Target supports the ‘persistent’ variable attribute.
  
! ‘pie_enabled’
       Target generates PIE by default.
  
! ‘pcc_bitfield_type_matters’
!      Target defines ‘PCC_BITFIELD_TYPE_MATTERS’.
  
! ‘pe_aligned_commons’
!      Target supports ‘-mpe-aligned-commons’.
  
! ‘pie’
!      Target supports ‘-pie’, ‘-fpie’ and ‘-fPIE’.
  
! ‘rdynamic’
!      Target supports ‘-rdynamic’.
  
! ‘scalar_all_fma’
!      Target supports all four fused multiply-add optabs for both ‘float’
!      and ‘double’.  These optabs are: ‘fma_optab’, ‘fms_optab’,
!      ‘fnma_optab’ and ‘fnms_optab’.
  
! ‘section_anchors’
       Target supports section anchors.
  
! ‘short_enums’
       Target defaults to short enums.
  
! ‘stack_size’
       Target has limited stack size.  The stack size limit can be
       obtained using the STACK_SIZE macro defined by *note
!      ‘dg-add-options’ feature ‘stack_size’: stack_size_ao.
  
! ‘static’
!      Target supports ‘-static’.
  
! ‘static_libgfortran’
!      Target supports statically linking ‘libgfortran’.
  
! ‘string_merging’
       Target supports merging string constants at link time.
  
! ‘ucn’
       Target supports compiling and assembling UCN.
  
! ‘ucn_nocache’
       Including the options used to compile this particular test, the
       target supports compiling and assembling UCN.
  
! ‘unaligned_stack’
!      Target does not guarantee that its ‘STACK_BOUNDARY’ is greater than
       or equal to the required vector alignment.
  
! ‘vector_alignment_reachable’
       Vector alignment is reachable for types of 32 bits or less.
  
! ‘vector_alignment_reachable_for_64bit’
       Vector alignment is reachable for types of 64 bits or less.
  
! ‘vma_equals_lma’
       Target generates executable with VMA equal to LMA for .data
       section.
  
! ‘wchar_t_char16_t_compatible’
!      Target supports ‘wchar_t’ that is compatible with ‘char16_t’.
  
! ‘wchar_t_char32_t_compatible’
!      Target supports ‘wchar_t’ that is compatible with ‘char32_t’.
  
! ‘comdat_group’
       Target uses comdat groups.
  
! ‘indirect_calls’
       Target supports indirect calls, i.e.  calls where the target is not
       constant.
  
! ‘lgccjit’
       Target supports -lgccjit, i.e.  libgccjit.so can be linked into jit
       tests.
  
! ‘__OPTIMIZE__’
!      Optimizations are enabled (‘__OPTIMIZE__’) per the current compiler
       flags.
  
! 7.2.3.16 Local to tests in ‘gcc.target/i386’
  ............................................
  
! ‘3dnow’
!      Target supports compiling ‘3dnow’ instructions.
  
! ‘aes’
!      Target supports compiling ‘aes’ instructions.
  
! ‘fma4’
!      Target supports compiling ‘fma4’ instructions.
  
! ‘mfentry’
!      Target supports the ‘-mfentry’ option that alters the position of
       profiling calls such that they precede the prologue.
  
! ‘ms_hook_prologue’
!      Target supports attribute ‘ms_hook_prologue’.
  
! ‘pclmul’
!      Target supports compiling ‘pclmul’ instructions.
  
! ‘sse3’
!      Target supports compiling ‘sse3’ instructions.
  
! ‘sse4’
!      Target supports compiling ‘sse4’ instructions.
  
! ‘sse4a’
!      Target supports compiling ‘sse4a’ instructions.
  
! ‘ssse3’
!      Target supports compiling ‘ssse3’ instructions.
  
! ‘vaes’
!      Target supports compiling ‘vaes’ instructions.
  
! ‘vpclmul’
!      Target supports compiling ‘vpclmul’ instructions.
  
! ‘xop’
!      Target supports compiling ‘xop’ instructions.
  
! 7.2.3.17 Local to tests in ‘gcc.test-framework’
  ...............................................
  
! ‘no’
       Always returns 0.
  
! ‘yes’
       Always returns 1.
  
  
  File: gccint.info,  Node: Add Options,  Next: Require Support,  Prev: Effective-Target Keywords,  Up: Test Directives
  
! 7.2.4 Features for ‘dg-add-options’
  -----------------------------------
  
! The supported values of FEATURE for directive ‘dg-add-options’ are:
  
! ‘arm_fp’
!      ‘__ARM_FP’ definition.  Only ARM targets support this feature, and
       only then in certain modes; see the *note arm_fp_ok effective
       target keyword: arm_fp_ok.
  
! ‘arm_fp_dp’
!      ‘__ARM_FP’ definition with double-precision support.  Only ARM
       targets support this feature, and only then in certain modes; see
       the *note arm_fp_dp_ok effective target keyword: arm_fp_dp_ok.
  
! ‘arm_neon’
       NEON support.  Only ARM targets support this feature, and only then
       in certain modes; see the *note arm_neon_ok effective target
       keyword: arm_neon_ok.
  
! ‘arm_fp16’
       VFP half-precision floating point support.  This does not select
       the FP16 format; for that, use *note arm_fp16_ieee: arm_fp16_ieee.
       or *note arm_fp16_alternative: arm_fp16_alternative. instead.  This
*************** The supported values of FEATURE for dire
*** 6244,6492 ****
       modes; see the *note arm_fp16_ok effective target keyword:
       arm_fp16_ok.
  
! 'arm_fp16_ieee'
       ARM IEEE 754-2008 format VFP half-precision floating point support.
       This feature is only supported by ARM targets and then only in
       certain modes; see the *note arm_fp16_ok effective target keyword:
       arm_fp16_ok.
  
! 'arm_fp16_alternative'
       ARM Alternative format VFP half-precision floating point support.
       This feature is only supported by ARM targets and then only in
       certain modes; see the *note arm_fp16_ok effective target keyword:
       arm_fp16_ok.
  
! 'arm_neon_fp16'
       NEON and half-precision floating point support.  Only ARM targets
       support this feature, and only then in certain modes; see the *note
       arm_neon_fp16_ok effective target keyword: arm_neon_fp16_ok.
  
! 'arm_vfp3'
       arm vfp3 floating point support; see the *note arm_vfp3_ok
       effective target keyword: arm_vfp3_ok.
  
! 'arm_arch_v8a_hard'
       Add options for ARMv8-A and the hard-float variant of the AAPCS, if
       this is supported by the compiler; see the *note
       arm_arch_v8a_hard_ok: arm_arch_v8a_hard_ok. effective target
       keyword.
  
! 'arm_v8_1a_neon'
       Add options for ARMv8.1-A with Adv.SIMD support, if this is
       supported by the target; see the *note arm_v8_1a_neon_ok:
       arm_v8_1a_neon_ok. effective target keyword.
  
! 'arm_v8_2a_fp16_scalar'
       Add options for ARMv8.2-A with scalar FP16 support, if this is
       supported by the target; see the *note arm_v8_2a_fp16_scalar_ok:
       arm_v8_2a_fp16_scalar_ok. effective target keyword.
  
! 'arm_v8_2a_fp16_neon'
       Add options for ARMv8.2-A with Adv.SIMD FP16 support, if this is
       supported by the target; see the *note arm_v8_2a_fp16_neon_ok:
       arm_v8_2a_fp16_neon_ok. effective target keyword.
  
! 'arm_v8_2a_dotprod_neon'
       Add options for ARMv8.2-A with Adv.SIMD Dot Product support, if
       this is supported by the target; see the *note
       arm_v8_2a_dotprod_neon_ok:: effective target keyword.
  
! 'arm_fp16fml_neon'
!      Add options to enable generation of the 'VFMAL' and 'VFMSL'
       instructions, if this is supported by the target; see the *note
       arm_fp16fml_neon_ok:: effective target keyword.
  
! 'arm_dsp'
       Add options for ARM DSP intrinsics support, if this is supported by
       the target; see the *note arm_dsp_ok effective target keyword:
       arm_dsp_ok.
  
! 'bind_pic_locally'
       Add the target-specific flags needed to enable functions to bind
       locally when using pic/PIC passes in the testsuite.
  
! 'floatN'
!      Add the target-specific flags needed to use the '_FloatN' type.
  
! 'floatNx'
!      Add the target-specific flags needed to use the '_FloatNx' type.
  
! 'ieee'
       Add the target-specific flags needed to enable full IEEE compliance
       mode.
  
! 'mips16_attribute'
!      'mips16' function attributes.  Only MIPS targets support this
       feature, and only then in certain modes.
  
! 'stack_size'
       Add the flags needed to define macro STACK_SIZE and set it to the
!      stack size limit associated with the *note 'stack_size' effective
       target: stack_size_et.
  
! 'sqrt_insn'
       Add the target-specific flags needed to enable hardware square root
       instructions, if any.
  
! 'tls'
       Add the target-specific flags needed to use thread-local storage.
  
! 'weak_undefined'
       Add the flags needed to enable support for weak undefined symbols.
  
  
  File: gccint.info,  Node: Require Support,  Next: Final Actions,  Prev: Add Options,  Up: Test Directives
  
! 7.2.5 Variants of 'dg-require-SUPPORT'
  --------------------------------------
  
! A few of the 'dg-require' directives take arguments.
  
! 'dg-require-iconv CODESET'
       Skip the test if the target does not support iconv.  CODESET is the
       codeset to convert to.
  
! 'dg-require-profiling PROFOPT'
       Skip the test if the target does not support profiling with option
       PROFOPT.
  
! 'dg-require-stack-check CHECK'
!      Skip the test if the target does not support the '-fstack-check'
!      option.  If CHECK is '""', support for '-fstack-check' is checked,
!      for '-fstack-check=("CHECK")' otherwise.
  
! 'dg-require-stack-size SIZE'
       Skip the test if the target does not support a stack size of SIZE.
  
! 'dg-require-visibility VIS'
!      Skip the test if the target does not support the 'visibility'
!      attribute.  If VIS is '""', support for 'visibility("hidden")' is
!      checked, for 'visibility("VIS")' otherwise.
  
!  The original 'dg-require' directives were defined before there was
  support for effective-target keywords.  The directives that do not take
  arguments could be replaced with effective-target keywords.
  
! 'dg-require-alias ""'
!      Skip the test if the target does not support the 'alias' attribute.
  
! 'dg-require-ascii-locale ""'
       Skip the test if the host does not support an ASCII locale.
  
! 'dg-require-compat-dfp ""'
!      Skip this test unless both compilers in a 'compat' testsuite
       support decimal floating point.
  
! 'dg-require-cxa-atexit ""'
!      Skip the test if the target does not support '__cxa_atexit'.  This
!      is equivalent to 'dg-require-effective-target cxa_atexit'.
  
! 'dg-require-dll ""'
       Skip the test if the target does not support DLL attributes.
  
! 'dg-require-dot ""'
!      Skip the test if the host does not have 'dot'.
  
! 'dg-require-fork ""'
!      Skip the test if the target does not support 'fork'.
  
! 'dg-require-gc-sections ""'
       Skip the test if the target's linker does not support the
!      '--gc-sections' flags.  This is equivalent to
!      'dg-require-effective-target gc-sections'.
  
! 'dg-require-host-local ""'
       Skip the test if the host is remote, rather than the same as the
       build system.  Some tests are incompatible with DejaGnu's handling
       of remote hosts, which involves copying the source file to the host
!      and compiling it with a relative path and "'-o a.out'".
  
! 'dg-require-mkfifo ""'
!      Skip the test if the target does not support 'mkfifo'.
  
! 'dg-require-named-sections ""'
       Skip the test is the target does not support named sections.  This
!      is equivalent to 'dg-require-effective-target named_sections'.
  
! 'dg-require-weak ""'
       Skip the test if the target does not support weak symbols.
  
! 'dg-require-weak-override ""'
       Skip the test if the target does not support overriding weak
       symbols.
  
  
  File: gccint.info,  Node: Final Actions,  Prev: Require Support,  Up: Test Directives
  
! 7.2.6 Commands for use in 'dg-final'
  ------------------------------------
  
  The GCC testsuite defines the following directives to be used within
! 'dg-final'.
  
  7.2.6.1 Scan a particular file
  ..............................
  
! 'scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]'
       Passes if REGEXP matches text in FILENAME.
! 'scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]'
       Passes if REGEXP does not match text in FILENAME.
! 'scan-module MODULE REGEXP [{ target/xfail SELECTOR }]'
       Passes if REGEXP matches in Fortran module MODULE.
! 'dg-check-dot FILENAME'
!      Passes if FILENAME is a valid '.dot' file (by running 'dot -Tpng'
       on it, and verifying the exit code is 0).
! 'scan-sarif-file REGEXP [{ target/xfail SELECTOR }]'
       Passes if REGEXP matches text in the file generated by
!      '-fdiagnostics-format=sarif-file'.
! 'scan-sarif-file-not REGEXP [{ target/xfail SELECTOR }]'
       Passes if REGEXP does not match text in the file generated by
!      '-fdiagnostics-format=sarif-file'.
  
  7.2.6.2 Scan the assembly output
  ................................
  
! 'scan-assembler REGEX [{ target/xfail SELECTOR }]'
       Passes if REGEX matches text in the test's assembler output.
  
! 'scan-assembler-not REGEX [{ target/xfail SELECTOR }]'
       Passes if REGEX does not match text in the test's assembler output.
  
! 'scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]'
       Passes if REGEX is matched exactly NUM times in the test's
       assembler output.
  
! 'scan-assembler-dem REGEX [{ target/xfail SELECTOR }]'
       Passes if REGEX matches text in the test's demangled assembler
       output.
  
! 'scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]'
       Passes if REGEX does not match text in the test's demangled
       assembler output.
  
! 'scan-assembler-symbol-section FUNCTIONS SECTION [{ target/xfail SELECTOR }]'
       Passes if FUNCTIONS are all in SECTION.  The caller needs to allow
!      for 'USER_LABEL_PREFIX' and different section name conventions.
  
! 'scan-symbol-section FILENAME FUNCTIONS SECTION [{ target/xfail SELECTOR }]'
       Passes if FUNCTIONS are all in SECTIONin FILENAME.  The same
!      caveats as for 'scan-assembler-symbol-section' apply.
  
! 'scan-hidden SYMBOL [{ target/xfail SELECTOR }]'
       Passes if SYMBOL is defined as a hidden symbol in the test's
       assembly output.
  
! 'scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]'
       Passes if SYMBOL is not defined as a hidden symbol in the test's
       assembly output.
  
! 'check-function-bodies PREFIX TERMINATOR [OPTIONS [{ target/xfail SELECTOR }]]'
       Looks through the source file for comments that give the expected
       assembly output for selected functions.  Each line of expected
       output starts with the prefix string PREFIX and the expected output
       for a function as a whole is followed by a line that starts with
       the string TERMINATOR.  Specifying an empty terminator is
!      equivalent to specifying '"*/"'.
  
       OPTIONS, if specified, is a list of regular expressions, each of
       which matches a full command-line option.  A non-empty list
--- 6244,6492 ----
       modes; see the *note arm_fp16_ok effective target keyword:
       arm_fp16_ok.
  
! ‘arm_fp16_ieee’
       ARM IEEE 754-2008 format VFP half-precision floating point support.
       This feature is only supported by ARM targets and then only in
       certain modes; see the *note arm_fp16_ok effective target keyword:
       arm_fp16_ok.
  
! ‘arm_fp16_alternative’
       ARM Alternative format VFP half-precision floating point support.
       This feature is only supported by ARM targets and then only in
       certain modes; see the *note arm_fp16_ok effective target keyword:
       arm_fp16_ok.
  
! ‘arm_neon_fp16’
       NEON and half-precision floating point support.  Only ARM targets
       support this feature, and only then in certain modes; see the *note
       arm_neon_fp16_ok effective target keyword: arm_neon_fp16_ok.
  
! ‘arm_vfp3’
       arm vfp3 floating point support; see the *note arm_vfp3_ok
       effective target keyword: arm_vfp3_ok.
  
! ‘arm_arch_v8a_hard’
       Add options for ARMv8-A and the hard-float variant of the AAPCS, if
       this is supported by the compiler; see the *note
       arm_arch_v8a_hard_ok: arm_arch_v8a_hard_ok. effective target
       keyword.
  
! ‘arm_v8_1a_neon’
       Add options for ARMv8.1-A with Adv.SIMD support, if this is
       supported by the target; see the *note arm_v8_1a_neon_ok:
       arm_v8_1a_neon_ok. effective target keyword.
  
! ‘arm_v8_2a_fp16_scalar’
       Add options for ARMv8.2-A with scalar FP16 support, if this is
       supported by the target; see the *note arm_v8_2a_fp16_scalar_ok:
       arm_v8_2a_fp16_scalar_ok. effective target keyword.
  
! ‘arm_v8_2a_fp16_neon’
       Add options for ARMv8.2-A with Adv.SIMD FP16 support, if this is
       supported by the target; see the *note arm_v8_2a_fp16_neon_ok:
       arm_v8_2a_fp16_neon_ok. effective target keyword.
  
! ‘arm_v8_2a_dotprod_neon’
       Add options for ARMv8.2-A with Adv.SIMD Dot Product support, if
       this is supported by the target; see the *note
       arm_v8_2a_dotprod_neon_ok:: effective target keyword.
  
! ‘arm_fp16fml_neon’
!      Add options to enable generation of the ‘VFMAL’ and ‘VFMSL’
       instructions, if this is supported by the target; see the *note
       arm_fp16fml_neon_ok:: effective target keyword.
  
! ‘arm_dsp’
       Add options for ARM DSP intrinsics support, if this is supported by
       the target; see the *note arm_dsp_ok effective target keyword:
       arm_dsp_ok.
  
! ‘bind_pic_locally’
       Add the target-specific flags needed to enable functions to bind
       locally when using pic/PIC passes in the testsuite.
  
! ‘floatN’
!      Add the target-specific flags needed to use the ‘_FloatN’ type.
  
! ‘floatNx’
!      Add the target-specific flags needed to use the ‘_FloatNx’ type.
  
! ‘ieee’
       Add the target-specific flags needed to enable full IEEE compliance
       mode.
  
! ‘mips16_attribute’
!      ‘mips16’ function attributes.  Only MIPS targets support this
       feature, and only then in certain modes.
  
! ‘stack_size’
       Add the flags needed to define macro STACK_SIZE and set it to the
!      stack size limit associated with the *note ‘stack_size’ effective
       target: stack_size_et.
  
! ‘sqrt_insn’
       Add the target-specific flags needed to enable hardware square root
       instructions, if any.
  
! ‘tls’
       Add the target-specific flags needed to use thread-local storage.
  
! ‘weak_undefined’
       Add the flags needed to enable support for weak undefined symbols.
  
  
  File: gccint.info,  Node: Require Support,  Next: Final Actions,  Prev: Add Options,  Up: Test Directives
  
! 7.2.5 Variants of ‘dg-require-SUPPORT’
  --------------------------------------
  
! A few of the ‘dg-require’ directives take arguments.
  
! ‘dg-require-iconv CODESET’
       Skip the test if the target does not support iconv.  CODESET is the
       codeset to convert to.
  
! ‘dg-require-profiling PROFOPT’
       Skip the test if the target does not support profiling with option
       PROFOPT.
  
! ‘dg-require-stack-check CHECK’
!      Skip the test if the target does not support the ‘-fstack-check’
!      option.  If CHECK is ‘""’, support for ‘-fstack-check’ is checked,
!      for ‘-fstack-check=("CHECK")’ otherwise.
  
! ‘dg-require-stack-size SIZE’
       Skip the test if the target does not support a stack size of SIZE.
  
! ‘dg-require-visibility VIS’
!      Skip the test if the target does not support the ‘visibility’
!      attribute.  If VIS is ‘""’, support for ‘visibility("hidden")’ is
!      checked, for ‘visibility("VIS")’ otherwise.
  
!  The original ‘dg-require’ directives were defined before there was
  support for effective-target keywords.  The directives that do not take
  arguments could be replaced with effective-target keywords.
  
! ‘dg-require-alias ""’
!      Skip the test if the target does not support the ‘alias’ attribute.
  
! ‘dg-require-ascii-locale ""’
       Skip the test if the host does not support an ASCII locale.
  
! ‘dg-require-compat-dfp ""’
!      Skip this test unless both compilers in a ‘compat’ testsuite
       support decimal floating point.
  
! ‘dg-require-cxa-atexit ""’
!      Skip the test if the target does not support ‘__cxa_atexit’.  This
!      is equivalent to ‘dg-require-effective-target cxa_atexit’.
  
! ‘dg-require-dll ""’
       Skip the test if the target does not support DLL attributes.
  
! ‘dg-require-dot ""’
!      Skip the test if the host does not have ‘dot’.
  
! ‘dg-require-fork ""’
!      Skip the test if the target does not support ‘fork’.
  
! ‘dg-require-gc-sections ""’
       Skip the test if the target's linker does not support the
!      ‘--gc-sections’ flags.  This is equivalent to
!      ‘dg-require-effective-target gc-sections’.
  
! ‘dg-require-host-local ""’
       Skip the test if the host is remote, rather than the same as the
       build system.  Some tests are incompatible with DejaGnu's handling
       of remote hosts, which involves copying the source file to the host
!      and compiling it with a relative path and "‘-o a.out’".
  
! ‘dg-require-mkfifo ""’
!      Skip the test if the target does not support ‘mkfifo’.
  
! ‘dg-require-named-sections ""’
       Skip the test is the target does not support named sections.  This
!      is equivalent to ‘dg-require-effective-target named_sections’.
  
! ‘dg-require-weak ""’
       Skip the test if the target does not support weak symbols.
  
! ‘dg-require-weak-override ""’
       Skip the test if the target does not support overriding weak
       symbols.
  
  
  File: gccint.info,  Node: Final Actions,  Prev: Require Support,  Up: Test Directives
  
! 7.2.6 Commands for use in ‘dg-final’
  ------------------------------------
  
  The GCC testsuite defines the following directives to be used within
! ‘dg-final’.
  
  7.2.6.1 Scan a particular file
  ..............................
  
! ‘scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]’
       Passes if REGEXP matches text in FILENAME.
! ‘scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]’
       Passes if REGEXP does not match text in FILENAME.
! ‘scan-module MODULE REGEXP [{ target/xfail SELECTOR }]’
       Passes if REGEXP matches in Fortran module MODULE.
! ‘dg-check-dot FILENAME’
!      Passes if FILENAME is a valid ‘.dot’ file (by running ‘dot -Tpng’
       on it, and verifying the exit code is 0).
! ‘scan-sarif-file REGEXP [{ target/xfail SELECTOR }]’
       Passes if REGEXP matches text in the file generated by
!      ‘-fdiagnostics-format=sarif-file’.
! ‘scan-sarif-file-not REGEXP [{ target/xfail SELECTOR }]’
       Passes if REGEXP does not match text in the file generated by
!      ‘-fdiagnostics-format=sarif-file’.
  
  7.2.6.2 Scan the assembly output
  ................................
  
! ‘scan-assembler REGEX [{ target/xfail SELECTOR }]’
       Passes if REGEX matches text in the test's assembler output.
  
! ‘scan-assembler-not REGEX [{ target/xfail SELECTOR }]’
       Passes if REGEX does not match text in the test's assembler output.
  
! ‘scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]’
       Passes if REGEX is matched exactly NUM times in the test's
       assembler output.
  
! ‘scan-assembler-dem REGEX [{ target/xfail SELECTOR }]’
       Passes if REGEX matches text in the test's demangled assembler
       output.
  
! ‘scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]’
       Passes if REGEX does not match text in the test's demangled
       assembler output.
  
! ‘scan-assembler-symbol-section FUNCTIONS SECTION [{ target/xfail SELECTOR }]’
       Passes if FUNCTIONS are all in SECTION.  The caller needs to allow
!      for ‘USER_LABEL_PREFIX’ and different section name conventions.
  
! ‘scan-symbol-section FILENAME FUNCTIONS SECTION [{ target/xfail SELECTOR }]’
       Passes if FUNCTIONS are all in SECTIONin FILENAME.  The same
!      caveats as for ‘scan-assembler-symbol-section’ apply.
  
! ‘scan-hidden SYMBOL [{ target/xfail SELECTOR }]’
       Passes if SYMBOL is defined as a hidden symbol in the test's
       assembly output.
  
! ‘scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]’
       Passes if SYMBOL is not defined as a hidden symbol in the test's
       assembly output.
  
! ‘check-function-bodies PREFIX TERMINATOR [OPTIONS [{ target/xfail SELECTOR }]]’
       Looks through the source file for comments that give the expected
       assembly output for selected functions.  Each line of expected
       output starts with the prefix string PREFIX and the expected output
       for a function as a whole is followed by a line that starts with
       the string TERMINATOR.  Specifying an empty terminator is
!      equivalent to specifying ‘"*/"’.
  
       OPTIONS, if specified, is a list of regular expressions, each of
       which matches a full command-line option.  A non-empty list
*************** The GCC testsuite defines the following
*** 6503,6513 ****
       Subsequent lines of the expected output also start with PREFIX.  In
       both cases, whitespace after PREFIX is not significant.
  
!      The test discards assembly directives such as '.cfi_startproc' and
!      local label definitions such as '.LFB0' from the compiler's
       assembly output.  It then matches the result against the expected
       output for a function as a single regular expression.  This means
!      that later lines can use backslashes to refer back to '(...)'
       captures on earlier lines.  For example:
  
            /* { dg-final { check-function-bodies "**" "" "-DCHECK_ASM" } } */
--- 6503,6513 ----
       Subsequent lines of the expected output also start with PREFIX.  In
       both cases, whitespace after PREFIX is not significant.
  
!      The test discards assembly directives such as ‘.cfi_startproc’ and
!      local label definitions such as ‘.LFB0’ from the compiler's
       assembly output.  It then matches the result against the expected
       output for a function as a single regular expression.  This means
!      that later lines can use backslashes to refer back to ‘(...)’
       captures on earlier lines.  For example:
  
            /* { dg-final { check-function-bodies "**" "" "-DCHECK_ASM" } } */
*************** The GCC testsuite defines the following
*** 6528,6540 ****
            */
            svint8_t add_b0_s8_m (...) { ... }
  
!      checks whether the implementations of 'add_w0_s8_m' and
!      'add_b0_s8_m' match the regular expressions given.  The test only
!      runs when '-DCHECK_ASM' is passed on the command line.
  
       It is possible to create non-capturing multi-line regular
!      expression groups of the form '(A|B|...)' by putting the '(', '|'
!      and ')' on separate lines (each still using PREFIX).  For example:
  
            /*
            ** cmple_f16_tied:
--- 6528,6540 ----
            */
            svint8_t add_b0_s8_m (...) { ... }
  
!      checks whether the implementations of ‘add_w0_s8_m’ and
!      ‘add_b0_s8_m’ match the regular expressions given.  The test only
!      runs when ‘-DCHECK_ASM’ is passed on the command line.
  
       It is possible to create non-capturing multi-line regular
!      expression groups of the form ‘(A|B|...)’ by putting the ‘(’, ‘|’
!      and ‘)’ on separate lines (each still using PREFIX).  For example:
  
            /*
            ** cmple_f16_tied:
*************** The GCC testsuite defines the following
*** 6547,6555 ****
            */
            svbool_t cmple_f16_tied (...) { ... }
  
!      checks whether 'cmple_f16_tied' is implemented by the 'fcmge'
!      instruction followed by 'ret' or by the 'fcmle' instruction
!      followed by 'ret'.  The test is still a single regular rexpression.
  
       A line containing just:
  
--- 6547,6555 ----
            */
            svbool_t cmple_f16_tied (...) { ... }
  
!      checks whether ‘cmple_f16_tied’ is implemented by the ‘fcmge’
!      instruction followed by ‘ret’ or by the ‘fcmle’ instruction
!      followed by ‘ret’.  The test is still a single regular rexpression.
  
       A line containing just:
  
*************** The GCC testsuite defines the following
*** 6561,6585 ****
  7.2.6.3 Scan optimization dump files
  ....................................
  
! These commands are available for KIND of 'tree', 'ltrans-tree',
! 'offload-tree', 'rtl', 'offload-rtl', 'ipa', and 'wpa-ipa'.
  
! 'scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]'
       Passes if REGEX matches text in the dump file with suffix SUFFIX.
  
! 'scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
       Passes if REGEX does not match text in the dump file with suffix
       SUFFIX.
  
! 'scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]'
       Passes if REGEX is found exactly NUM times in the dump file with
       suffix SUFFIX.
  
! 'scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]'
       Passes if REGEX matches demangled text in the dump file with suffix
       SUFFIX.
  
! 'scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
       Passes if REGEX does not match demangled text in the dump file with
       suffix SUFFIX.
  
--- 6561,6585 ----
  7.2.6.3 Scan optimization dump files
  ....................................
  
! These commands are available for KIND of ‘tree’, ‘ltrans-tree’,
! ‘offload-tree’, ‘rtl’, ‘offload-rtl’, ‘ipa’, and ‘wpa-ipa’.
  
! ‘scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]’
       Passes if REGEX matches text in the dump file with suffix SUFFIX.
  
! ‘scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]’
       Passes if REGEX does not match text in the dump file with suffix
       SUFFIX.
  
! ‘scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]’
       Passes if REGEX is found exactly NUM times in the dump file with
       suffix SUFFIX.
  
! ‘scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]’
       Passes if REGEX matches demangled text in the dump file with suffix
       SUFFIX.
  
! ‘scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]’
       Passes if REGEX does not match demangled text in the dump file with
       suffix SUFFIX.
  
*************** instances 1, 2, 3 of a tree pass "mypass
*** 6596,6625 ****
  7.2.6.4 Check for output files
  ..............................
  
! 'output-exists [{ target/xfail SELECTOR }]'
       Passes if compiler output file exists.
  
! 'output-exists-not [{ target/xfail SELECTOR }]'
       Passes if compiler output file does not exist.
  
! 'scan-symbol REGEXP [{ target/xfail SELECTOR }]'
       Passes if the pattern is present in the final executable.
  
! 'scan-symbol-not REGEXP [{ target/xfail SELECTOR }]'
       Passes if the pattern is absent from the final executable.
  
! 7.2.6.5 Checks for 'gcov' tests
  ...............................
  
! 'run-gcov SOURCEFILE'
!      Check line counts in 'gcov' tests.
  
! 'run-gcov [branches] [calls] { OPTS SOURCEFILE }'
       Check branch and/or call counts, in addition to line counts, in
!      'gcov' tests.
  
! 'run-gcov-pytest { SOURCEFILE PYTEST_FILE }'
!      Check output of 'gcov' intermediate format with a pytest script.
  
  7.2.6.6 Clean up generated test files
  .....................................
--- 6596,6625 ----
  7.2.6.4 Check for output files
  ..............................
  
! ‘output-exists [{ target/xfail SELECTOR }]’
       Passes if compiler output file exists.
  
! ‘output-exists-not [{ target/xfail SELECTOR }]’
       Passes if compiler output file does not exist.
  
! ‘scan-symbol REGEXP [{ target/xfail SELECTOR }]’
       Passes if the pattern is present in the final executable.
  
! ‘scan-symbol-not REGEXP [{ target/xfail SELECTOR }]’
       Passes if the pattern is absent from the final executable.
  
! 7.2.6.5 Checks for ‘gcov’ tests
  ...............................
  
! ‘run-gcov SOURCEFILE’
!      Check line counts in ‘gcov’ tests.
  
! ‘run-gcov [branches] [calls] { OPTS SOURCEFILE }’
       Check branch and/or call counts, in addition to line counts, in
!      ‘gcov’ tests.
  
! ‘run-gcov-pytest { SOURCEFILE PYTEST_FILE }’
!      Check output of ‘gcov’ intermediate format with a pytest script.
  
  7.2.6.6 Clean up generated test files
  .....................................
*************** passed to the tool and schedules a final
*** 6631,6640 ****
  
   There are, however, following additional cleanup directives that can be
  used to annotate a testcase "manually".
! 'cleanup-coverage-files'
       Removes coverage data files generated for this test.
  
! 'cleanup-modules "LIST-OF-EXTRA-MODULES"'
       Removes Fortran module files generated for this test, excluding the
       module names listed in keep-modules.  Cleaning up module files is
       usually done automatically by the testsuite by looking at the
--- 6631,6640 ----
  
   There are, however, following additional cleanup directives that can be
  used to annotate a testcase "manually".
! ‘cleanup-coverage-files’
       Removes coverage data files generated for this test.
  
! ‘cleanup-modules "LIST-OF-EXTRA-MODULES"’
       Removes Fortran module files generated for this test, excluding the
       module names listed in keep-modules.  Cleaning up module files is
       usually done automatically by the testsuite by looking at the
*************** used to annotate a testcase "manually".
*** 6651,6657 ****
            ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant
            ! { dg-final { keep-modules "mod3 mod4" } }
  
! 'keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"'
       Whitespace separated list of module names that should not be
       deleted by cleanup-modules.  If the list of modules is empty, all
       modules defined in this file are kept.
--- 6651,6657 ----
            ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant
            ! { dg-final { keep-modules "mod3 mod4" } }
  
! ‘keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"’
       Whitespace separated list of module names that should not be
       deleted by cleanup-modules.  If the list of modules is empty, all
       modules defined in this file are kept.
*************** used to annotate a testcase "manually".
*** 6664,6679 ****
            ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two
            ! { dg-final { keep-modules "" } } ! keep all
  
! 'dg-keep-saved-temps "LIST-OF-SUFFIXES-NOT-TO-DELETE"'
       Whitespace separated list of suffixes that should not be deleted
!      automatically in a testcase that uses '-save-temps'.
            // { dg-options "-save-temps -fpch-preprocess -I." }
            int main() { return 0; }
            // { dg-keep-saved-temps ".s" } ! just keep assembler file
            // { dg-keep-saved-temps ".s" ".i" } ! ... and .i
            // { dg-keep-saved-temps ".ii" ".o" } ! or just .ii and .o
  
! 'cleanup-profile-file'
       Removes profiling files generated for this test.
  
  
--- 6664,6679 ----
            ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two
            ! { dg-final { keep-modules "" } } ! keep all
  
! ‘dg-keep-saved-temps "LIST-OF-SUFFIXES-NOT-TO-DELETE"’
       Whitespace separated list of suffixes that should not be deleted
!      automatically in a testcase that uses ‘-save-temps’.
            // { dg-options "-save-temps -fpch-preprocess -I." }
            int main() { return 0; }
            // { dg-keep-saved-temps ".s" } ! just keep assembler file
            // { dg-keep-saved-temps ".s" ".i" } ! ... and .i
            // { dg-keep-saved-temps ".ii" ".o" } ! or just .ii and .o
  
! ‘cleanup-profile-file’
       Removes profiling files generated for this test.
  
  
*************** File: gccint.info,  Node: Ada Tests,  Ne
*** 6685,6710 ****
  The Ada testsuite includes executable tests from the ACATS testsuite,
  publicly available at .
  
!  These tests are integrated in the GCC testsuite in the 'ada/acats'
! directory, and enabled automatically when running 'make check', assuming
  the Ada language has been enabled when configuring GCC.
  
!  You can also run the Ada testsuite independently, using 'make
! check-ada', or run a subset of the tests by specifying which chapter to
  run, e.g.:
  
       $ make check-ada CHAPTERS="c3 c9"
  
   The tests are organized by directory, each directory corresponding to a
! chapter of the Ada Reference Manual.  So for example, 'c9' corresponds
  to chapter 9, which deals with tasking features of the language.
  
!  The tests are run using two 'sh' scripts: 'run_acats' and 'run_all.sh'.
  To run the tests using a simulator or a cross target, see the small
! customization section at the top of 'run_all.sh'.
  
   These tests are run using the build tree: they can be run without doing
! a 'make install'.
  
  
  File: gccint.info,  Node: C Tests,  Next: LTO Testing,  Prev: Ada Tests,  Up: Testsuites
--- 6685,6710 ----
  The Ada testsuite includes executable tests from the ACATS testsuite,
  publicly available at .
  
!  These tests are integrated in the GCC testsuite in the ‘ada/acats’
! directory, and enabled automatically when running ‘make check’, assuming
  the Ada language has been enabled when configuring GCC.
  
!  You can also run the Ada testsuite independently, using ‘make
! check-ada’, or run a subset of the tests by specifying which chapter to
  run, e.g.:
  
       $ make check-ada CHAPTERS="c3 c9"
  
   The tests are organized by directory, each directory corresponding to a
! chapter of the Ada Reference Manual.  So for example, ‘c9’ corresponds
  to chapter 9, which deals with tasking features of the language.
  
!  The tests are run using two ‘sh’ scripts: ‘run_acats’ and ‘run_all.sh’.
  To run the tests using a simulator or a cross target, see the small
! customization section at the top of ‘run_all.sh’.
  
   These tests are run using the build tree: they can be run without doing
! a ‘make install’.
  
  
  File: gccint.info,  Node: C Tests,  Next: LTO Testing,  Prev: Ada Tests,  Up: Testsuites
*************** File: gccint.info,  Node: C Tests,  Next
*** 6712,6754 ****
  7.4 C Language Testsuites
  =========================
  
! GCC contains the following C language testsuites, in the 'gcc/testsuite'
  directory:
  
! 'gcc.dg'
       This contains tests of particular features of the C compiler, using
!      the more modern 'dg' harness.  Correctness tests for various
       compiler features should go here if possible.
  
       Magic comments determine whether the file is preprocessed,
       compiled, linked or run.  In these tests, error and warning message
       texts are compared against expected texts or regular expressions
!      given in comments.  These tests are run with the options '-ansi
!      -pedantic' unless other options are given in the test.  Except as
       noted below they are not run with multiple optimization options.
! 'gcc.dg/compat'
       This subdirectory contains tests for binary compatibility using
!      'lib/compat.exp', which in turn uses the language-independent
       support (*note Support for testing binary compatibility: compat
       Testing.).
! 'gcc.dg/cpp'
       This subdirectory contains tests of the preprocessor.
! 'gcc.dg/debug'
       This subdirectory contains tests for debug formats.  Tests in this
       subdirectory are run for each debug format that the compiler
       supports.
! 'gcc.dg/format'
!      This subdirectory contains tests of the '-Wformat' format checking.
!      Tests in this directory are run with and without '-DWIDE'.
! 'gcc.dg/noncompile'
       This subdirectory contains tests of code that should not compile
       and does not need any special compilation options.  They are run
       with multiple optimization options, since sometimes invalid code
       crashes the compiler with optimization.
! 'gcc.dg/special'
       FIXME: describe this.
  
! 'gcc.c-torture'
       This contains particular code fragments which have historically
       broken easily.  These tests are run with multiple optimization
       options, so tests for features which only break at some
--- 6712,6754 ----
  7.4 C Language Testsuites
  =========================
  
! GCC contains the following C language testsuites, in the ‘gcc/testsuite’
  directory:
  
! ‘gcc.dg’
       This contains tests of particular features of the C compiler, using
!      the more modern ‘dg’ harness.  Correctness tests for various
       compiler features should go here if possible.
  
       Magic comments determine whether the file is preprocessed,
       compiled, linked or run.  In these tests, error and warning message
       texts are compared against expected texts or regular expressions
!      given in comments.  These tests are run with the options ‘-ansi
!      -pedantic’ unless other options are given in the test.  Except as
       noted below they are not run with multiple optimization options.
! ‘gcc.dg/compat’
       This subdirectory contains tests for binary compatibility using
!      ‘lib/compat.exp’, which in turn uses the language-independent
       support (*note Support for testing binary compatibility: compat
       Testing.).
! ‘gcc.dg/cpp’
       This subdirectory contains tests of the preprocessor.
! ‘gcc.dg/debug’
       This subdirectory contains tests for debug formats.  Tests in this
       subdirectory are run for each debug format that the compiler
       supports.
! ‘gcc.dg/format’
!      This subdirectory contains tests of the ‘-Wformat’ format checking.
!      Tests in this directory are run with and without ‘-DWIDE’.
! ‘gcc.dg/noncompile’
       This subdirectory contains tests of code that should not compile
       and does not need any special compilation options.  They are run
       with multiple optimization options, since sometimes invalid code
       crashes the compiler with optimization.
! ‘gcc.dg/special’
       FIXME: describe this.
  
! ‘gcc.c-torture’
       This contains particular code fragments which have historically
       broken easily.  These tests are run with multiple optimization
       options, so tests for features which only break at some
*************** directory:
*** 6757,6812 ****
       separate the correctness tests cleanly from the code quality tests,
       but it hasn't been done yet.
  
! 'gcc.c-torture/compat'
       FIXME: describe this.
  
       This directory should probably not be used for new tests.
! 'gcc.c-torture/compile'
       This testsuite contains test cases that should compile, but do not
       need to link or run.  These test cases are compiled with several
       different combinations of optimization options.  All warnings are
       disabled for these test cases, so this directory is not suitable if
       you wish to test for the presence or absence of compiler warnings.
       While special options can be set, and tests disabled on specific
!      platforms, by the use of '.x' files, mostly these test cases should
       not contain platform dependencies.  FIXME: discuss how defines such
!      as 'STACK_SIZE' are used.
! 'gcc.c-torture/execute'
       This testsuite contains test cases that should compile, link and
!      run; otherwise the same comments as for 'gcc.c-torture/compile'
       apply.
! 'gcc.c-torture/execute/ieee'
       This contains tests which are specific to IEEE floating point.
! 'gcc.c-torture/unsorted'
       FIXME: describe this.
  
       This directory should probably not be used for new tests.
! 'gcc.misc-tests'
       This directory contains C tests that require special handling.
       Some of these tests have individual expect files, and others share
       special-purpose expect files:
  
!      'bprob*.c'
!           Test '-fbranch-probabilities' using
!           'gcc.misc-tests/bprob.exp', which in turn uses the generic,
            language-independent framework (*note Support for testing
            profile-directed optimizations: profopt Testing.).
  
!      'gcov*.c'
!           Test 'gcov' output using 'gcov.exp', which in turn uses the
            language-independent support (*note Support for testing gcov:
            gcov Testing.).
  
!      'i386-pf-*.c'
            Test i386-specific support for data prefetch using
!           'i386-prefetch.exp'.
  
! 'gcc.test-framework'
!      'dg-*.c'
            Test the testsuite itself using
!           'gcc.test-framework/test-framework.exp'.
  
!  FIXME: merge in 'testsuite/README.gcc' and discuss the format of test
  cases and magic comments more.
  
  
--- 6757,6812 ----
       separate the correctness tests cleanly from the code quality tests,
       but it hasn't been done yet.
  
! ‘gcc.c-torture/compat’
       FIXME: describe this.
  
       This directory should probably not be used for new tests.
! ‘gcc.c-torture/compile’
       This testsuite contains test cases that should compile, but do not
       need to link or run.  These test cases are compiled with several
       different combinations of optimization options.  All warnings are
       disabled for these test cases, so this directory is not suitable if
       you wish to test for the presence or absence of compiler warnings.
       While special options can be set, and tests disabled on specific
!      platforms, by the use of ‘.x’ files, mostly these test cases should
       not contain platform dependencies.  FIXME: discuss how defines such
!      as ‘STACK_SIZE’ are used.
! ‘gcc.c-torture/execute’
       This testsuite contains test cases that should compile, link and
!      run; otherwise the same comments as for ‘gcc.c-torture/compile’
       apply.
! ‘gcc.c-torture/execute/ieee’
       This contains tests which are specific to IEEE floating point.
! ‘gcc.c-torture/unsorted’
       FIXME: describe this.
  
       This directory should probably not be used for new tests.
! ‘gcc.misc-tests’
       This directory contains C tests that require special handling.
       Some of these tests have individual expect files, and others share
       special-purpose expect files:
  
!      ‘bprob*.c’
!           Test ‘-fbranch-probabilities’ using
!           ‘gcc.misc-tests/bprob.exp’, which in turn uses the generic,
            language-independent framework (*note Support for testing
            profile-directed optimizations: profopt Testing.).
  
!      ‘gcov*.c’
!           Test ‘gcov’ output using ‘gcov.exp’, which in turn uses the
            language-independent support (*note Support for testing gcov:
            gcov Testing.).
  
!      ‘i386-pf-*.c’
            Test i386-specific support for data prefetch using
!           ‘i386-prefetch.exp’.
  
! ‘gcc.test-framework’
!      ‘dg-*.c’
            Test the testsuite itself using
!           ‘gcc.test-framework/test-framework.exp’.
  
!  FIXME: merge in ‘testsuite/README.gcc’ and discuss the format of test
  cases and magic comments more.
  
  
*************** Tests for link-time optimizations usuall
*** 6819,6895 ****
  that are compiled separately, perhaps with different sets of options.
  There are several special-purpose test directives used for these tests.
  
! '{ dg-lto-do DO-WHAT-KEYWORD }'
       DO-WHAT-KEYWORD specifies how the test is compiled and whether it
       is executed.  It is one of:
  
!      'assemble'
!           Compile with '-c' to produce a relocatable object file.
!      'link'
            Compile, assemble, and link to produce an executable file.
!      'run'
            Produce and run an executable file, which is expected to
            return an exit code of 0.
  
!      The default is 'assemble'.  That can be overridden for a set of
!      tests by redefining 'dg-do-what-default' within the '.exp' file for
       those tests.
  
!      Unlike 'dg-do', 'dg-lto-do' does not support an optional 'target'
!      or 'xfail' list.  Use 'dg-skip-if', 'dg-xfail-if', or
!      'dg-xfail-run-if'.
  
! '{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}'
       This directive provides a list of one or more sets of compiler
       options to override LTO_OPTIONS.  Each test will be compiled and
       run with each of these sets of options.
  
! '{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}'
       This directive adds OPTIONS to the linker options used.
  
! '{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}'
       This directive removes OPTIONS from the set of linker options used.
  
  
  File: gccint.info,  Node: gcov Testing,  Next: profopt Testing,  Prev: LTO Testing,  Up: Testsuites
  
! 7.6 Support for testing 'gcov'
  ==============================
  
! Language-independent support for testing 'gcov', and for checking that
  branch profiling produces expected values, is provided by the expect
! file 'lib/gcov.exp'.  'gcov' tests also rely on procedures in
! 'lib/gcc-dg.exp' to compile and run the test program.  A typical 'gcov'
  test contains the following DejaGnu commands within comments:
  
       { dg-options "--coverage" }
       { dg-do run { target native } }
       { dg-final { run-gcov sourcefile } }
  
!  Checks of 'gcov' output can include line counts, branch percentages,
  and call return percentages.  All of these checks are requested via
  commands that appear in comments in the test's source file.  Commands to
  check line counts are processed by default.  Commands to check branch
! percentages and call return percentages are processed if the 'run-gcov'
! command has arguments 'branches' or 'calls', respectively.  For example,
! the following specifies checking both, as well as passing '-b' to
! 'gcov':
  
       { dg-final { run-gcov branches calls { -b sourcefile } } }
  
   A line count command appears within a comment on the source line that
! is expected to get the specified count and has the form 'count(CNT)'.  A
  test should only check line counts for lines that will get the same
  count for any architecture.
  
!  Commands to check branch percentages ('branch') and call return
! percentages ('returns') are very similar to each other.  A beginning
  command appears on or before the first of a range of lines that will
  report the percentage, and the ending command follows that range of
  lines.  The beginning command can include a list of percentages, all of
  which are expected to be found within the range.  A range is terminated
! by the next command of the same kind.  A command 'branch(end)' or
! 'returns(end)' marks the end of a range without starting a new one.  For
  example:
  
       if (i > 10 && j > i && j < 20)  /* branch(27 50 75) */
--- 6819,6895 ----
  that are compiled separately, perhaps with different sets of options.
  There are several special-purpose test directives used for these tests.
  
! ‘{ dg-lto-do DO-WHAT-KEYWORD }’
       DO-WHAT-KEYWORD specifies how the test is compiled and whether it
       is executed.  It is one of:
  
!      ‘assemble’
!           Compile with ‘-c’ to produce a relocatable object file.
!      ‘link’
            Compile, assemble, and link to produce an executable file.
!      ‘run’
            Produce and run an executable file, which is expected to
            return an exit code of 0.
  
!      The default is ‘assemble’.  That can be overridden for a set of
!      tests by redefining ‘dg-do-what-default’ within the ‘.exp’ file for
       those tests.
  
!      Unlike ‘dg-do’, ‘dg-lto-do’ does not support an optional ‘target’
!      or ‘xfail’ list.  Use ‘dg-skip-if’, ‘dg-xfail-if’, or
!      ‘dg-xfail-run-if’.
  
! ‘{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}’
       This directive provides a list of one or more sets of compiler
       options to override LTO_OPTIONS.  Each test will be compiled and
       run with each of these sets of options.
  
! ‘{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}’
       This directive adds OPTIONS to the linker options used.
  
! ‘{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}’
       This directive removes OPTIONS from the set of linker options used.
  
  
  File: gccint.info,  Node: gcov Testing,  Next: profopt Testing,  Prev: LTO Testing,  Up: Testsuites
  
! 7.6 Support for testing ‘gcov’
  ==============================
  
! Language-independent support for testing ‘gcov’, and for checking that
  branch profiling produces expected values, is provided by the expect
! file ‘lib/gcov.exp’.  ‘gcov’ tests also rely on procedures in
! ‘lib/gcc-dg.exp’ to compile and run the test program.  A typical ‘gcov’
  test contains the following DejaGnu commands within comments:
  
       { dg-options "--coverage" }
       { dg-do run { target native } }
       { dg-final { run-gcov sourcefile } }
  
!  Checks of ‘gcov’ output can include line counts, branch percentages,
  and call return percentages.  All of these checks are requested via
  commands that appear in comments in the test's source file.  Commands to
  check line counts are processed by default.  Commands to check branch
! percentages and call return percentages are processed if the ‘run-gcov’
! command has arguments ‘branches’ or ‘calls’, respectively.  For example,
! the following specifies checking both, as well as passing ‘-b’ to
! ‘gcov’:
  
       { dg-final { run-gcov branches calls { -b sourcefile } } }
  
   A line count command appears within a comment on the source line that
! is expected to get the specified count and has the form ‘count(CNT)’.  A
  test should only check line counts for lines that will get the same
  count for any architecture.
  
!  Commands to check branch percentages (‘branch’) and call return
! percentages (‘returns’) are very similar to each other.  A beginning
  command appears on or before the first of a range of lines that will
  report the percentage, and the ending command follows that range of
  lines.  The beginning command can include a list of percentages, all of
  which are expected to be found within the range.  A range is terminated
! by the next command of the same kind.  A command ‘branch(end)’ or
! ‘returns(end)’ marks the end of a range without starting a new one.  For
  example:
  
       if (i > 10 && j > i && j < 20)  /* branch(27 50 75) */
*************** File: gccint.info,  Node: profopt Testin
*** 6918,6924 ****
  7.7 Support for testing profile-directed optimizations
  ======================================================
  
! The file 'profopt.exp' provides language-independent support for
  checking correct execution of a test built with profile-directed
  optimization.  This testing requires that a test program be built and
  executed twice.  The first time it is compiled to generate profile data,
--- 6918,6924 ----
  7.7 Support for testing profile-directed optimizations
  ======================================================
  
! The file ‘profopt.exp’ provides language-independent support for
  checking correct execution of a test built with profile-directed
  optimization.  This testing requires that a test program be built and
  executed twice.  The first time it is compiled to generate profile data,
*************** test produces the expected results.
*** 6929,6961 ****
   To check that the optimization actually generated better code, a test
  can be built and run a third time with normal optimizations to verify
  that the performance is better with the profile-directed optimizations.
! 'profopt.exp' has the beginnings of this kind of support.
  
!  'profopt.exp' provides generic support for profile-directed
  optimizations.  Each set of tests that uses it provides information
  about a specific optimization:
  
! 'tool'
!      tool being tested, e.g., 'gcc'
  
! 'profile_option'
       options used to generate profile data
  
! 'feedback_option'
       options used to optimize using that profile data
  
! 'prof_ext'
       suffix of profile data files
  
! 'PROFOPT_OPTIONS'
       list of options with which to run each test, similar to the lists
       for torture tests
  
! '{ dg-final-generate { LOCAL-DIRECTIVE } }'
!      This directive is similar to 'dg-final', but the LOCAL-DIRECTIVE is
       run after the generation of profile data.
  
! '{ dg-final-use { LOCAL-DIRECTIVE } }'
       The LOCAL-DIRECTIVE is run after the profile data have been used.
  
  
--- 6929,6961 ----
   To check that the optimization actually generated better code, a test
  can be built and run a third time with normal optimizations to verify
  that the performance is better with the profile-directed optimizations.
! ‘profopt.exp’ has the beginnings of this kind of support.
  
!  ‘profopt.exp’ provides generic support for profile-directed
  optimizations.  Each set of tests that uses it provides information
  about a specific optimization:
  
! ‘tool’
!      tool being tested, e.g., ‘gcc’
  
! ‘profile_option’
       options used to generate profile data
  
! ‘feedback_option’
       options used to optimize using that profile data
  
! ‘prof_ext’
       suffix of profile data files
  
! ‘PROFOPT_OPTIONS’
       list of options with which to run each test, similar to the lists
       for torture tests
  
! ‘{ dg-final-generate { LOCAL-DIRECTIVE } }’
!      This directive is similar to ‘dg-final’, but the LOCAL-DIRECTIVE is
       run after the generation of profile data.
  
! ‘{ dg-final-use { LOCAL-DIRECTIVE } }’
       The LOCAL-DIRECTIVE is run after the profile data have been used.
  
  
*************** File: gccint.info,  Node: compat Testing
*** 6964,6970 ****
  7.8 Support for testing binary compatibility
  ============================================
  
! The file 'compat.exp' provides language-independent support for binary
  compatibility testing.  It supports testing interoperability of two
  compilers that follow the same ABI, or of multiple sets of compiler
  options that should not affect binary compatibility.  It is intended to
--- 6964,6970 ----
  7.8 Support for testing binary compatibility
  ============================================
  
! The file ‘compat.exp’ provides language-independent support for binary
  compatibility testing.  It supports testing interoperability of two
  compilers that follow the same ABI, or of multiple sets of compiler
  options that should not affect binary compatibility.  It is intended to
*************** be used for testsuites that complement A
*** 6974,6988 ****
  source file: a main program and two pieces that interact with each other
  to split up the functionality being tested.
  
! 'TESTNAME_main.SUFFIX'
       Contains the main program, which calls a function in file
!      'TESTNAME_x.SUFFIX'.
  
! 'TESTNAME_x.SUFFIX'
!      Contains at least one call to a function in 'TESTNAME_y.SUFFIX'.
  
! 'TESTNAME_y.SUFFIX'
!      Shares data with, or gets arguments from, 'TESTNAME_x.SUFFIX'.
  
   Within each test, the main program and one functional piece are
  compiled by the GCC under test.  The other piece can be compiled by an
--- 6974,6988 ----
  source file: a main program and two pieces that interact with each other
  to split up the functionality being tested.
  
! ‘TESTNAME_main.SUFFIX’
       Contains the main program, which calls a function in file
!      ‘TESTNAME_x.SUFFIX’.
  
! ‘TESTNAME_x.SUFFIX’
!      Contains at least one call to a function in ‘TESTNAME_y.SUFFIX’.
  
! ‘TESTNAME_y.SUFFIX’
!      Shares data with, or gets arguments from, ‘TESTNAME_x.SUFFIX’.
  
   Within each test, the main program and one functional piece are
  compiled by the GCC under test.  The other piece can be compiled by an
*************** pair specifies options used with the GCC
*** 6993,7025 ****
  element of the pair specifies options used with the alternate compiler.
  Each test is compiled with each pair of options.
  
!  'compat.exp' defines default pairs of compiler options.  These can be
! overridden by defining the environment variable 'COMPAT_OPTIONS' as:
  
       COMPAT_OPTIONS="[list [list {TST1} {ALT1}]
         ...[list {TSTN} {ALTN}]]"
  
   where TSTI and ALTI are lists of options, with TSTI used by the
  compiler under test and ALTI used by the alternate compiler.  For
! example, with '[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]',
! the test is first built with '-g -O0' by the compiler under test and
! with '-O3' by the alternate compiler.  The test is built a second time
! using '-fpic' by the compiler under test and '-fPIC -O2' by the
  alternate compiler.
  
   An alternate compiler is specified by defining an environment variable
  to be the full pathname of an installed compiler; for C define
! 'ALT_CC_UNDER_TEST', and for C++ define 'ALT_CXX_UNDER_TEST'.  These
! will be written to the 'site.exp' file used by DejaGnu.  The default is
  to build each test with the compiler under test using the first of each
! pair of compiler options from 'COMPAT_OPTIONS'.  When
! 'ALT_CC_UNDER_TEST' or 'ALT_CXX_UNDER_TEST' is 'same', each test is
  built using the compiler under test but with combinations of the options
! from 'COMPAT_OPTIONS'.
  
   To run only the C++ compatibility suite using the compiler under test
  and another version of GCC using specific compiler options, do the
! following from 'OBJDIR/gcc':
  
       rm site.exp
       make -k \
--- 6993,7025 ----
  element of the pair specifies options used with the alternate compiler.
  Each test is compiled with each pair of options.
  
!  ‘compat.exp’ defines default pairs of compiler options.  These can be
! overridden by defining the environment variable ‘COMPAT_OPTIONS’ as:
  
       COMPAT_OPTIONS="[list [list {TST1} {ALT1}]
         ...[list {TSTN} {ALTN}]]"
  
   where TSTI and ALTI are lists of options, with TSTI used by the
  compiler under test and ALTI used by the alternate compiler.  For
! example, with ‘[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]’,
! the test is first built with ‘-g -O0’ by the compiler under test and
! with ‘-O3’ by the alternate compiler.  The test is built a second time
! using ‘-fpic’ by the compiler under test and ‘-fPIC -O2’ by the
  alternate compiler.
  
   An alternate compiler is specified by defining an environment variable
  to be the full pathname of an installed compiler; for C define
! ‘ALT_CC_UNDER_TEST’, and for C++ define ‘ALT_CXX_UNDER_TEST’.  These
! will be written to the ‘site.exp’ file used by DejaGnu.  The default is
  to build each test with the compiler under test using the first of each
! pair of compiler options from ‘COMPAT_OPTIONS’.  When
! ‘ALT_CC_UNDER_TEST’ or ‘ALT_CXX_UNDER_TEST’ is ‘same’, each test is
  built using the compiler under test but with combinations of the options
! from ‘COMPAT_OPTIONS’.
  
   To run only the C++ compatibility suite using the compiler under test
  and another version of GCC using specific compiler options, do the
! following from ‘OBJDIR/gcc’:
  
       rm site.exp
       make -k \
*************** compiler under test but is present in th
*** 7038,7054 ****
   The binary compatibility tests support a small number of test framework
  commands that appear within comments in a test file.
  
! 'dg-require-*'
!      These commands can be used in 'TESTNAME_main.SUFFIX' to skip the
       test if specific support is not available on the target.
  
! 'dg-options'
       The specified options are used for compiling this particular source
!      file, appended to the options from 'COMPAT_OPTIONS'.  When this
!      command appears in 'TESTNAME_main.SUFFIX' the options are also used
       to link the test program.
  
! 'dg-xfail-if'
       This command can be used in a secondary source file to specify that
       compilation is expected to fail for particular options on
       particular targets.
--- 7038,7054 ----
   The binary compatibility tests support a small number of test framework
  commands that appear within comments in a test file.
  
! ‘dg-require-*’
!      These commands can be used in ‘TESTNAME_main.SUFFIX’ to skip the
       test if specific support is not available on the target.
  
! ‘dg-options’
       The specified options are used for compiling this particular source
!      file, appended to the options from ‘COMPAT_OPTIONS’.  When this
!      command appears in ‘TESTNAME_main.SUFFIX’ the options are also used
       to link the test program.
  
! ‘dg-xfail-if’
       This command can be used in a secondary source file to specify that
       compilation is expected to fail for particular options on
       particular targets.
*************** File: gccint.info,  Node: Torture Tests,
*** 7061,7096 ****
  
  Throughout the compiler testsuite there are several directories whose
  tests are run multiple times, each with a different set of options.
! These are known as torture tests.  'lib/torture-options.exp' defines
  procedures to set up these lists:
  
! 'torture-init'
       Initialize use of torture lists.
! 'set-torture-options'
       Set lists of torture options to use for tests with and without
       loops.  Optionally combine a set of torture options with a set of
       other options, as is done with Objective-C runtime options.
! 'torture-finish'
       Finalize use of torture lists.
  
!  The '.exp' file for a set of tests that use torture options must
  include calls to these three procedures if:
  
!    * It calls 'gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS.
  
!    * It calls ${TOOL}'-torture' or ${TOOL}'-torture-execute', where TOOL
!      is 'c', 'fortran', or 'objc'.
  
!    * It calls 'dg-pch'.
  
!  It is not necessary for a '.exp' file that calls 'gcc-dg-runtest' to
  call the torture procedures if the tests should use the list in
! DG_TORTURE_OPTIONS defined in 'gcc-dg.exp'.
  
   Most uses of torture options can override the default lists by defining
  TORTURE_OPTIONS or add to the default list by defining
! ADDITIONAL_TORTURE_OPTIONS.  Define these in a '.dejagnurc' file or add
! them to the 'site.exp' file; for example
  
       set ADDITIONAL_TORTURE_OPTIONS  [list \
         { -O2 -ftree-loop-linear } \
--- 7061,7096 ----
  
  Throughout the compiler testsuite there are several directories whose
  tests are run multiple times, each with a different set of options.
! These are known as torture tests.  ‘lib/torture-options.exp’ defines
  procedures to set up these lists:
  
! ‘torture-init’
       Initialize use of torture lists.
! ‘set-torture-options’
       Set lists of torture options to use for tests with and without
       loops.  Optionally combine a set of torture options with a set of
       other options, as is done with Objective-C runtime options.
! ‘torture-finish’
       Finalize use of torture lists.
  
!  The ‘.exp’ file for a set of tests that use torture options must
  include calls to these three procedures if:
  
!    • It calls ‘gcc-dg-runtest’ and overrides DG_TORTURE_OPTIONS.
  
!    • It calls ${TOOL}‘-torture’ or ${TOOL}‘-torture-execute’, where TOOL
!      is ‘c’, ‘fortran’, or ‘objc’.
  
!    • It calls ‘dg-pch’.
  
!  It is not necessary for a ‘.exp’ file that calls ‘gcc-dg-runtest’ to
  call the torture procedures if the tests should use the list in
! DG_TORTURE_OPTIONS defined in ‘gcc-dg.exp’.
  
   Most uses of torture options can override the default lists by defining
  TORTURE_OPTIONS or add to the default list by defining
! ADDITIONAL_TORTURE_OPTIONS.  Define these in a ‘.dejagnurc’ file or add
! them to the ‘site.exp’ file; for example
  
       set ADDITIONAL_TORTURE_OPTIONS  [list \
         { -O2 -ftree-loop-linear } \
*************** File: gccint.info,  Node: GIMPLE Tests,
*** 7102,7110 ****
  7.10 Support for testing GIMPLE passes
  ======================================
  
! As of gcc 7, C functions can be tagged with '__GIMPLE' to indicate that
  the function body will be GIMPLE, rather than C. The compiler requires
! the option '-fgimple' to enable this functionality.  For example:
  
       /* { dg-do compile } */
       /* { dg-options "-O -fgimple" } */
--- 7102,7110 ----
  7.10 Support for testing GIMPLE passes
  ======================================
  
! As of gcc 7, C functions can be tagged with ‘__GIMPLE’ to indicate that
  the function body will be GIMPLE, rather than C. The compiler requires
! the option ‘-fgimple’ to enable this functionality.  For example:
  
       /* { dg-do compile } */
       /* { dg-options "-O -fgimple" } */
*************** the option '-fgimple' to enable this fun
*** 7133,7147 ****
         return;
       }
  
!  The 'startwith' argument indicates at which pass to begin.
  
!  Use the dump modifier '-gimple' (e.g. '-fdump-tree-all-gimple') to make
  tree dumps more closely follow the format accepted by the GIMPLE parser.
  
   Example DejaGnu tests of GIMPLE can be seen in the source tree at
! 'gcc/testsuite/gcc.dg/gimplefe-*.c'.
  
!  The '__GIMPLE' parser is integrated with the C tokenizer and
  preprocessor, so it should be possible to use macros to build out test
  coverage.
  
--- 7133,7147 ----
         return;
       }
  
!  The ‘startwith’ argument indicates at which pass to begin.
  
!  Use the dump modifier ‘-gimple’ (e.g. ‘-fdump-tree-all-gimple’) to make
  tree dumps more closely follow the format accepted by the GIMPLE parser.
  
   Example DejaGnu tests of GIMPLE can be seen in the source tree at
! ‘gcc/testsuite/gcc.dg/gimplefe-*.c’.
  
!  The ‘__GIMPLE’ parser is integrated with the C tokenizer and
  preprocessor, so it should be possible to use macros to build out test
  coverage.
  
*************** File: gccint.info,  Node: RTL Tests,  Pr
*** 7151,7157 ****
  7.11 Support for testing RTL passes
  ===================================
  
! As of gcc 7, C functions can be tagged with '__RTL' to indicate that the
  function body will be RTL, rather than C. For example:
  
       double __RTL (startwith ("ira")) test (struct foo *f, const struct bar *b)
--- 7151,7157 ----
  7.11 Support for testing RTL passes
  ===================================
  
! As of gcc 7, C functions can be tagged with ‘__RTL’ to indicate that the
  function body will be RTL, rather than C. For example:
  
       double __RTL (startwith ("ira")) test (struct foo *f, const struct bar *b)
*************** function body will be RTL, rather than C
*** 7161,7167 ****
         ) ;; function "test"
       }
  
!  The 'startwith' argument indicates at which pass to begin.
  
   The parser expects the RTL body to be in the format emitted by this
  dumping function:
--- 7161,7167 ----
         ) ;; function "test"
       }
  
!  The ‘startwith’ argument indicates at which pass to begin.
  
   The parser expects the RTL body to be in the format emitted by this
  dumping function:
*************** from the debugger using:
*** 7177,7185 ****
   and copy and paste the output into the body of the C function.
  
   Example DejaGnu tests of RTL can be seen in the source tree under
! 'gcc/testsuite/gcc.dg/rtl'.
  
!  The '__RTL' parser is not integrated with the C tokenizer or
  preprocessor, and works simply by reading the relevant lines within the
  braces.  In particular, the RTL body must be on separate lines from the
  enclosing braces, and the preprocessor is not usable within it.
--- 7177,7185 ----
   and copy and paste the output into the body of the C function.
  
   Example DejaGnu tests of RTL can be seen in the source tree under
! ‘gcc/testsuite/gcc.dg/rtl’.
  
!  The ‘__RTL’ parser is not integrated with the C tokenizer or
  preprocessor, and works simply by reading the relevant lines within the
  braces.  In particular, the RTL body must be on separate lines from the
  enclosing braces, and the preprocessor is not usable within it.
*************** File: gccint.info,  Node: Options,  Next
*** 7191,7197 ****
  ****************************
  
  Most GCC command-line options are described by special option definition
! files, the names of which conventionally end in '.opt'.  This chapter
  describes the format of these files.
  
  * Menu:
--- 7191,7197 ----
  ****************************
  
  Most GCC command-line options are described by special option definition
! files, the names of which conventionally end in ‘.opt’.  This chapter
  describes the format of these files.
  
  * Menu:
*************** semicolon.
*** 7213,7340 ****
  
   The files can contain the following types of record:
  
!    * A language definition record.  These records have two fields: the
!      string 'Language' and the name of the language.  Once a language
       has been declared in this way, it can be used as an option
       property.  *Note Option properties::.
  
!    * A target specific save record to save additional information.
!      These records have two fields: the string 'TargetSave', and a
!      declaration type to go in the 'cl_target_option' structure.
  
!    * A variable record to define a variable used to store option
!      information.  These records have two fields: the string 'Variable',
       and a declaration of the type and name of the variable, optionally
!      with an initializer (but without any trailing ';').  These records
       may be used for variables used for many options where declaring the
       initializer in a single option definition record, or duplicating it
       in many records, would be inappropriate, or for variables set in
!      option handlers rather than referenced by 'Var' properties.
  
!    * A variable record to define a variable used to store option
       information.  These records have two fields: the string
!      'TargetVariable', and a declaration of the type and name of the
       variable, optionally with an initializer (but without any trailing
!      ';').  'TargetVariable' is a combination of 'Variable' and
!      'TargetSave' records in that the variable is defined in the
!      'gcc_options' structure, but these variables are also stored in the
!      'cl_target_option' structure.  The variables are saved in the
       target save code and restored in the target restore code.
  
!    * A variable record to record any additional files that the
!      'options.h' file should include.  This is useful to provide
       enumeration or structure definitions needed for target variables.
!      These records have two fields: the string 'HeaderInclude' and the
       name of the include file.
  
!    * A variable record to record any additional files that the
!      'options.cc' or 'options-save.cc' file should include.  This is
       useful to provide inline functions needed for target variables
!      and/or '#ifdef' sequences to properly set up the initialization.
!      These records have two fields: the string 'SourceInclude' and the
       name of the include file.
  
!    * An enumeration record to define a set of strings that may be used
       as arguments to an option or options.  These records have three
!      fields: the string 'Enum', a space-separated list of properties and
!      help text used to describe the set of strings in '--help' output.
       Properties use the same format as option properties; the following
       are valid:
!      'Name(NAME)'
            This property is required; NAME must be a name (suitable for
            use in C identifiers) used to identify the set of strings in
!           'Enum' option properties.
  
!      'Type(TYPE)'
            This property is required; TYPE is the C type for variables
!           set by options using this enumeration together with 'Var'.
  
!      'UnknownError(MESSAGE)'
            The message MESSAGE will be used as an error message if the
!           argument is invalid; for enumerations without 'UnknownError',
            a generic error message is used.  MESSAGE should contain a
!           single '%qs' format, which will be used to format the invalid
            argument.
  
!    * An enumeration value record to define one of the strings in a set
!      given in an 'Enum' record.  These records have two fields: the
!      string 'EnumValue' and a space-separated list of properties.
       Properties use the same format as option properties; the following
       are valid:
!      'Enum(NAME)'
!           This property is required; NAME says which 'Enum' record this
!           'EnumValue' record corresponds to.
  
!      'String(STRING)'
            This property is required; STRING is the string option
            argument being described by this record.
  
!      'Value(VALUE)'
            This property is required; it says what value (representable
!           as 'int') should be used for the given string.
  
!      'Canonical'
            This property is optional.  If present, it says the present
            string is the canonical one among all those with the given
            value.  Other strings yielding that value will be mapped to
            this one so specs do not need to handle them.
  
!      'DriverOnly'
            This property is optional.  If present, the present string
            will only be accepted by the driver.  This is used for cases
!           such as '-march=native' that are processed by the driver so
!           that 'gcc -v' shows how the options chosen depended on the
            system on which the compiler was run.
  
!      'Set(NUMBER)'
            This property is optional, required for enumerations used in
!           'EnumSet' options.  NUMBER should be decimal number between 1
            and 64 inclusive and divides the enumeration into a set of
            sets of mutually exclusive arguments.  Arguments with the same
            NUMBER can't be specified together in the same option, but
            arguments with different NUMBER can.  VALUE needs to be chosen
            such that a mask of all VALUE values from the same set NUMBER
            bitwise ored doesn't overlap with masks for other sets.  When
!           '-foption=arg_from_set1,arg_from_set4' and
!           '-fno-option=arg_from_set3' are used, the effect is that
!           previous value of the 'Var' will get bits from set 1 and 4
!           masks cleared, ored 'Value' of 'arg_from_set1' and
!           'arg_from_set4' and then will get bits from set 3 mask
            cleared.
  
!    * An option definition record.  These records have the following
       fields:
         1. the name of the option, with the leading "-" removed
         2. a space-separated list of option properties (*note Option
            properties::)
!        3. the help text to use for '--help' (omitted if the second field
!           contains the 'Undocumented' property).
  
       By default, all options beginning with "f", "g", "W" or "m" are
       implicitly assumed to take a "no-" form.  This form should not be
       listed separately.  If an option beginning with one of these
       letters does not have a "no-" form, you can use the
!      'RejectNegative' property to reject it.
  
       The help text is automatically line-wrapped before being displayed.
       Normally the name of the option is printed on the left-hand side of
--- 7213,7340 ----
  
   The files can contain the following types of record:
  
!    • A language definition record.  These records have two fields: the
!      string ‘Language’ and the name of the language.  Once a language
       has been declared in this way, it can be used as an option
       property.  *Note Option properties::.
  
!    • A target specific save record to save additional information.
!      These records have two fields: the string ‘TargetSave’, and a
!      declaration type to go in the ‘cl_target_option’ structure.
  
!    • A variable record to define a variable used to store option
!      information.  These records have two fields: the string ‘Variable’,
       and a declaration of the type and name of the variable, optionally
!      with an initializer (but without any trailing ‘;’).  These records
       may be used for variables used for many options where declaring the
       initializer in a single option definition record, or duplicating it
       in many records, would be inappropriate, or for variables set in
!      option handlers rather than referenced by ‘Var’ properties.
  
!    • A variable record to define a variable used to store option
       information.  These records have two fields: the string
!      ‘TargetVariable’, and a declaration of the type and name of the
       variable, optionally with an initializer (but without any trailing
!      ‘;’).  ‘TargetVariable’ is a combination of ‘Variable’ and
!      ‘TargetSave’ records in that the variable is defined in the
!      ‘gcc_options’ structure, but these variables are also stored in the
!      ‘cl_target_option’ structure.  The variables are saved in the
       target save code and restored in the target restore code.
  
!    • A variable record to record any additional files that the
!      ‘options.h’ file should include.  This is useful to provide
       enumeration or structure definitions needed for target variables.
!      These records have two fields: the string ‘HeaderInclude’ and the
       name of the include file.
  
!    • A variable record to record any additional files that the
!      ‘options.cc’ or ‘options-save.cc’ file should include.  This is
       useful to provide inline functions needed for target variables
!      and/or ‘#ifdef’ sequences to properly set up the initialization.
!      These records have two fields: the string ‘SourceInclude’ and the
       name of the include file.
  
!    • An enumeration record to define a set of strings that may be used
       as arguments to an option or options.  These records have three
!      fields: the string ‘Enum’, a space-separated list of properties and
!      help text used to describe the set of strings in ‘--help’ output.
       Properties use the same format as option properties; the following
       are valid:
!      ‘Name(NAME)’
            This property is required; NAME must be a name (suitable for
            use in C identifiers) used to identify the set of strings in
!           ‘Enum’ option properties.
  
!      ‘Type(TYPE)’
            This property is required; TYPE is the C type for variables
!           set by options using this enumeration together with ‘Var’.
  
!      ‘UnknownError(MESSAGE)’
            The message MESSAGE will be used as an error message if the
!           argument is invalid; for enumerations without ‘UnknownError’,
            a generic error message is used.  MESSAGE should contain a
!           single ‘%qs’ format, which will be used to format the invalid
            argument.
  
!    • An enumeration value record to define one of the strings in a set
!      given in an ‘Enum’ record.  These records have two fields: the
!      string ‘EnumValue’ and a space-separated list of properties.
       Properties use the same format as option properties; the following
       are valid:
!      ‘Enum(NAME)’
!           This property is required; NAME says which ‘Enum’ record this
!           ‘EnumValue’ record corresponds to.
  
!      ‘String(STRING)’
            This property is required; STRING is the string option
            argument being described by this record.
  
!      ‘Value(VALUE)’
            This property is required; it says what value (representable
!           as ‘int’) should be used for the given string.
  
!      ‘Canonical’
            This property is optional.  If present, it says the present
            string is the canonical one among all those with the given
            value.  Other strings yielding that value will be mapped to
            this one so specs do not need to handle them.
  
!      ‘DriverOnly’
            This property is optional.  If present, the present string
            will only be accepted by the driver.  This is used for cases
!           such as ‘-march=native’ that are processed by the driver so
!           that ‘gcc -v’ shows how the options chosen depended on the
            system on which the compiler was run.
  
!      ‘Set(NUMBER)’
            This property is optional, required for enumerations used in
!           ‘EnumSet’ options.  NUMBER should be decimal number between 1
            and 64 inclusive and divides the enumeration into a set of
            sets of mutually exclusive arguments.  Arguments with the same
            NUMBER can't be specified together in the same option, but
            arguments with different NUMBER can.  VALUE needs to be chosen
            such that a mask of all VALUE values from the same set NUMBER
            bitwise ored doesn't overlap with masks for other sets.  When
!           ‘-foption=arg_from_set1,arg_from_set4’ and
!           ‘-fno-option=arg_from_set3’ are used, the effect is that
!           previous value of the ‘Var’ will get bits from set 1 and 4
!           masks cleared, ored ‘Value’ of ‘arg_from_set1’ and
!           ‘arg_from_set4’ and then will get bits from set 3 mask
            cleared.
  
!    • An option definition record.  These records have the following
       fields:
         1. the name of the option, with the leading "-" removed
         2. a space-separated list of option properties (*note Option
            properties::)
!        3. the help text to use for ‘--help’ (omitted if the second field
!           contains the ‘Undocumented’ property).
  
       By default, all options beginning with "f", "g", "W" or "m" are
       implicitly assumed to take a "no-" form.  This form should not be
       listed separately.  If an option beginning with one of these
       letters does not have a "no-" form, you can use the
!      ‘RejectNegative’ property to reject it.
  
       The help text is automatically line-wrapped before being displayed.
       Normally the name of the option is printed on the left-hand side of
*************** semicolon.
*** 7349,7366 ****
       generic description that is correct for all of them.
  
       If an option has multiple option definition records (in different
!      front ends' '*.opt' files, and/or 'gcc/common.opt', for example),
       convention is to not duplicate the help text for each of them, but
!      instead put a comment like '; documented in common.opt' in place of
       the help text for all but one of the multiple option definition
       records.
  
!    * A target mask record.  These records have one field of the form
!      'Mask(X)'.  The options-processing script will automatically
!      allocate a bit in 'target_flags' (*note Run-time Target::) for each
!      mask name X and set the macro 'MASK_X' to the appropriate bitmask.
!      It will also declare a 'TARGET_X' macro that has the value 1 when
!      bit 'MASK_X' is set and 0 otherwise.
  
       They are primarily intended to declare target masks that are not
       associated with user options, either because these masks represent
--- 7349,7366 ----
       generic description that is correct for all of them.
  
       If an option has multiple option definition records (in different
!      front ends' ‘*.opt’ files, and/or ‘gcc/common.opt’, for example),
       convention is to not duplicate the help text for each of them, but
!      instead put a comment like ‘; documented in common.opt’ in place of
       the help text for all but one of the multiple option definition
       records.
  
!    • A target mask record.  These records have one field of the form
!      ‘Mask(X)’.  The options-processing script will automatically
!      allocate a bit in ‘target_flags’ (*note Run-time Target::) for each
!      mask name X and set the macro ‘MASK_X’ to the appropriate bitmask.
!      It will also declare a ‘TARGET_X’ macro that has the value 1 when
!      bit ‘MASK_X’ is set and 0 otherwise.
  
       They are primarily intended to declare target masks that are not
       associated with user options, either because these masks represent
*************** demarcate it, e.g.:
*** 7383,7740 ****
  
       Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)})
  
! 'Common'
       The option is available for all languages and targets.
  
! 'Target'
       The option is available for all languages but is target-specific.
  
! 'Driver'
       The option is handled by the compiler driver using code not shared
!      with the compilers proper ('cc1' etc.).
  
! 'LANGUAGE'
       The option is available when compiling for the given language.
  
       It is possible to specify several different languages for the same
       option.  Each LANGUAGE must have been declared by an earlier
!      'Language' record.  *Note Option file format::.
  
! 'RejectDriver'
!      The option is only handled by the compilers proper ('cc1' etc.) and
       should not be accepted by the driver.
  
! 'RejectNegative'
       The option does not have a "no-" form.  All options beginning with
       "f", "g", "W" or "m" are assumed to have a "no-" form unless this
       property is used.
  
! 'Negative(OTHERNAME)'
       The option will turn off another option OTHERNAME, which is the
       option name with the leading "-" removed.  This chain action will
!      propagate through the 'Negative' property of the option to be
       turned off.  The driver will prune options, removing those that are
       turned off by some later option.  This pruning is not done for
!      options with 'Joined' or 'JoinedOrMissing' properties, unless the
!      options have both the 'RejectNegative' property and the 'Negative'
       property mentions itself.
  
       As a consequence, if you have a group of mutually-exclusive
!      options, their 'Negative' properties should form a circular chain.
!      For example, if options '-A', '-B' and '-C' are mutually exclusive,
!      their respective 'Negative' properties should be 'Negative(B)',
!      'Negative(C)' and 'Negative(A)'.
  
! 'Joined'
! 'Separate'
!      The option takes a mandatory argument.  'Joined' indicates that the
!      option and argument can be included in the same 'argv' entry (as
!      with '-mflush-func=NAME', for example).  'Separate' indicates that
!      the option and argument can be separate 'argv' entries (as with
!      '-o').  An option is allowed to have both of these properties.
  
! 'JoinedOrMissing'
       The option takes an optional argument.  If the argument is given,
!      it will be part of the same 'argv' entry as the option itself.
  
!      This property cannot be used alongside 'Joined' or 'Separate'.
  
! 'MissingArgError(MESSAGE)'
!      For an option marked 'Joined' or 'Separate', the message MESSAGE
       will be used as an error message if the mandatory argument is
!      missing; for options without 'MissingArgError', a generic error
!      message is used.  MESSAGE should contain a single '%qs' format,
       which will be used to format the name of the option passed.
  
! 'Args(N)'
!      For an option marked 'Separate', indicate that it takes N
       arguments.  The default is 1.
  
! 'UInteger'
       The option's argument is a non-negative integer consisting of
!      either decimal or hexadecimal digits interpreted as 'int'.
!      Hexadecimal integers may optionally start with the '0x' or '0X'
       prefix.  The option parser validates and converts the argument
!      before passing it to the relevant option handler.  'UInteger'
!      should also be used with options like '-falign-loops' where both
!      '-falign-loops' and '-falign-loops'=N are supported to make sure
       the saved options are given a full integer.  Positive values of the
!      argument in excess of 'INT_MAX' wrap around zero.
  
! 'Host_Wide_Int'
       The option's argument is a non-negative integer consisting of
       either decimal or hexadecimal digits interpreted as the widest
!      integer type on the host.  As with an 'UInteger' argument,
!      hexadecimal integers may optionally start with the '0x' or '0X'
       prefix.  The option parser validates and converts the argument
!      before passing it to the relevant option handler.  'Host_Wide_Int'
       should be used with options that need to accept very large values.
!      Positive values of the argument in excess of 'HOST_WIDE_INT_M1U'
!      are assigned 'HOST_WIDE_INT_M1U'.
  
! 'IntegerRange(N, M)'
!      The options's arguments are integers of type 'int'.  The option's
       parser validates that the value of an option integer argument is
       within the closed range [N, M].
  
! 'ByteSize'
!      A property applicable only to 'UInteger' or 'Host_Wide_Int'
       arguments.  The option's integer argument is interpreted as if in
       infinite precision using saturation arithmetic in the corresponding
!      type.  The argument may be followed by a 'byte-size' suffix
!      designating a multiple of bytes such as 'kB' and 'KiB' for kilobyte
!      and kibibyte, respectively, 'MB' and 'MiB' for megabyte and
!      mebibyte, 'GB' and 'GiB' for gigabyte and gigibyte, and so on.
!      'ByteSize' should be used for with options that take a very large
!      argument representing a size in bytes, such as '-Wlarger-than='.
  
! 'ToLower'
       The option's argument should be converted to lowercase as part of
       putting it in canonical form, and before comparing with the strings
!      indicated by any 'Enum' property.
  
! 'NoDriverArg'
!      For an option marked 'Separate', the option only takes an argument
       in the compiler proper, not in the driver.  This is for
       compatibility with existing options that are used both directly and
!      via '-Wp,'; new options should not have this property.
  
! 'Var(VAR)'
       The state of this option should be stored in variable VAR (actually
!      a macro for 'global_options.x_VAR').  The way that the state is
       stored depends on the type of option:
  
!         * If the option uses the 'Mask' or 'InverseMask' properties, VAR
            is the integer variable that contains the mask.
  
!         * If the option is a normal on/off switch, VAR is an integer
            variable that is nonzero when the option is enabled.  The
            options parser will set the variable to 1 when the positive
            form of the option is used and 0 when the "no-" form is used.
  
!         * If the option takes an argument and has the 'UInteger'
            property, VAR is an integer variable that stores the value of
            the argument.
  
!         * If the option takes an argument and has the 'Enum' property,
!           VAR is a variable (type given in the 'Type' property of the
!           'Enum' record whose 'Name' property has the same argument as
!           the 'Enum' property of this option) that stores the value of
            the argument.
  
!         * If the option has the 'Defer' property, VAR is a pointer to a
!           'VEC(cl_deferred_option,heap)' that stores the option for
!           later processing.  (VAR is declared with type 'void *' and
!           needs to be cast to 'VEC(cl_deferred_option,heap)' before
            use.)
  
!         * Otherwise, if the option takes an argument, VAR is a pointer
            to the argument string.  The pointer will be null if the
            argument is optional and wasn't given.
  
       The option-processing script will usually zero-initialize VAR.  You
!      can modify this behavior using 'Init'.
  
! 'Var(VAR, SET)'
       The option controls an integer variable VAR and is active when VAR
       equals SET.  The option parser will set VAR to SET when the
!      positive form of the option is used and '!SET' when the "no-" form
       is used.
  
       VAR is declared in the same way as for the single-argument form
       described above.
  
! 'Init(VALUE)'
!      The variable specified by the 'Var' property should be statically
       initialized to VALUE.  If more than one option using the same
!      variable specifies 'Init', all must specify the same initializer.
  
! 'WarnRemoved'
       The option is removed and every usage of such option will result in
       a warning.  We use it option backward compatibility.
  
! 'Mask(NAME)'
!      The option is associated with a bit in the 'target_flags' variable
       (*note Run-time Target::) and is active when that bit is set.  You
!      may also specify 'Var' to select a variable other than
!      'target_flags'.
  
       The options-processing script will automatically allocate a unique
!      bit for the option.  If the option is attached to 'target_flags',
!      the script will set the macro 'MASK_NAME' to the appropriate
!      bitmask.  It will also declare a 'TARGET_NAME' macro that has the
       value 1 when the option is active and 0 otherwise.  If you use
!      'Var' to attach the option to a different variable, the bitmask
!      macro with be called 'OPTION_MASK_NAME'.
  
! 'InverseMask(OTHERNAME)'
! 'InverseMask(OTHERNAME, THISNAME)'
       The option is the inverse of another option that has the
!      'Mask(OTHERNAME)' property.  If THISNAME is given, the
!      options-processing script will declare a 'TARGET_THISNAME' macro
       that is 1 when the option is active and 0 otherwise.
  
! 'Enum(NAME)'
       The option's argument is a string from the set of strings
!      associated with the corresponding 'Enum' record.  The string is
       checked and converted to the integer specified in the corresponding
!      'EnumValue' record before being passed to option handlers.
  
! 'EnumSet'
!      Must be used together with the 'Enum(NAME)' property.
!      Corresponding 'Enum' record must use 'Set' properties.  The
       option's argument is either a string from the set like for
!      'Enum(NAME)', but with a slightly different behavior that the whole
!      'Var' isn't overwritten, but only the bits in all the enumeration
       values with the same set bitwise ored together.  Or option's
       argument can be a comma separated list of strings where each string
!      is from a different 'Set(NUMBER)'.
  
! 'EnumBitSet'
!      Must be used together with the 'Enum(NAME)' property.  Similar to
!      'EnumSet', but corresponding 'Enum' record must not use 'Set'
!      properties, each 'EnumValue' should have 'Value' that is a power of
       2, each value is treated as its own set and its value as the set's
       mask, so there are no mutually exclusive arguments.
  
! 'Defer'
!      The option should be stored in a vector, specified with 'Var', for
       later processing.
  
! 'Alias(OPT)'
! 'Alias(OPT, ARG)'
! 'Alias(OPT, POSARG, NEGARG)'
!      The option is an alias for '-OPT' (or the negative form of that
!      option, depending on 'NegativeAlias').  In the first form, any
!      argument passed to the alias is considered to be passed to '-OPT',
!      and '-OPT' is considered to be negated if the alias is used in
       negated form.  In the second form, the alias may not be negated or
       have an argument, and POSARG is considered to be passed as an
!      argument to '-OPT'.  In the third form, the alias may not have an
       argument, if the alias is used in the positive form then POSARG is
!      considered to be passed to '-OPT', and if the alias is used in the
!      negative form then NEGARG is considered to be passed to '-OPT'.
  
!      Aliases should not specify 'Var' or 'Mask' or 'UInteger'.  Aliases
       should normally specify the same languages as the target of the
       alias; the flags on the target will be used to determine any
       diagnostic for use of an option for the wrong language, while those
       on the alias will be used to identify what command-line text is the
       option and what text is any argument to that option.
  
!      When an 'Alias' definition is used for an option, driver specs do
!      not need to handle it and no 'OPT_' enumeration value is defined
       for it; only the canonical form of the option will be seen in those
       places.
  
! 'NegativeAlias'
!      For an option marked with 'Alias(OPT)', the option is considered to
!      be an alias for the positive form of '-OPT' if negated and for the
!      negative form of '-OPT' if not negated.  'NegativeAlias' may not be
!      used with the forms of 'Alias' taking more than one argument.
  
! 'Ignore'
       This option is ignored apart from printing any warning specified
!      using 'Warn'.  The option will not be seen by specs and no 'OPT_'
       enumeration value is defined for it.
  
! 'SeparateAlias'
!      For an option marked with 'Joined', 'Separate' and 'Alias', the
       option only acts as an alias when passed a separate argument; with
!      a joined argument it acts as a normal option, with an 'OPT_'
!      enumeration value.  This is for compatibility with the Java '-d'
       option and should not be used for new options.
  
! 'Warn(MESSAGE)'
       If this option is used, output the warning MESSAGE.  MESSAGE is a
!      format string, either taking a single operand with a '%qs' format
       which is the option name, or not taking any operands, which is
!      passed to the 'warning' function.  If an alias is marked 'Warn',
!      the target of the alias must not also be marked 'Warn'.
  
! 'Warning'
!      This is a warning option and should be shown as such in '--help'
       output.  This flag does not currently affect anything other than
!      '--help'.
  
! 'Optimization'
       This is an optimization option.  It should be shown as such in
!      '--help' output, and any associated variable named using 'Var'
       should be saved and restored when the optimization level is changed
!      with 'optimize' attributes.
  
! 'PerFunction'
       This is an option that can be overridden on a per-function basis.
!      'Optimization' implies 'PerFunction', but options that do not
       affect executable code generation may use this flag instead, so
       that the option is not taken into account in ways that might affect
       executable code generation.
  
! 'Param'
       This is an option that is a parameter.
  
! 'Undocumented'
       The option is deliberately missing documentation and should not be
!      included in the '--help' output.
  
! 'Condition(COND)'
       The option should only be accepted if preprocessor condition COND
       is true.  Note that any C declarations associated with the option
       will be present even if COND is false; COND simply controls whether
!      the option is accepted and whether it is printed in the '--help'
       output.
  
! 'Save'
!      Build the 'cl_target_option' structure to hold a copy of the
!      option, add the functions 'cl_target_option_save' and
!      'cl_target_option_restore' to save and restore the options.
  
! 'SetByCombined'
       The option may also be set by a combined option such as
!      '-ffast-math'.  This causes the 'gcc_options' struct to have a
!      field 'frontend_set_NAME', where 'NAME' is the name of the field
!      holding the value of this option (without the leading 'x_').  This
       gives the front end a way to indicate that the value has been set
       explicitly and should not be changed by the combined option.  For
!      example, some front ends use this to prevent '-ffast-math' and
!      '-fno-fast-math' from changing the value of '-fmath-errno' for
!      languages that do not use 'errno'.
  
! 'EnabledBy(OPT)'
! 'EnabledBy(OPT || OPT2)'
! 'EnabledBy(OPT && OPT2)'
!      If not explicitly set, the option is set to the value of '-OPT';
!      multiple options can be given, separated by '||'.  The third form
!      using '&&' specifies that the option is only set if both OPT and
!      OPT2 are set.  The options OPT and OPT2 must have the 'Common'
!      property; otherwise, use 'LangEnabledBy'.
  
! 'LangEnabledBy(LANGUAGE, OPT)'
! 'LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)'
       When compiling for the given language, the option is set to the
!      value of '-OPT', if not explicitly set.  OPT can be also a list of
!      '||' separated options.  In the second form, if OPT is used in the
       positive form then POSARG is considered to be passed to the option,
       and if OPT is used in the negative form then NEGARG is considered
       to be passed to the option.  It is possible to specify several
       different languages.  Each LANGUAGE must have been declared by an
!      earlier 'Language' record.  *Note Option file format::.
  
! 'NoDWARFRecord'
       The option is omitted from the producer string written by
!      '-grecord-gcc-switches'.
  
! 'PchIgnore'
       Even if this is a target option, this option will not be recorded /
       compared to determine if a precompiled header file matches.
  
! 'CPP(VAR)'
       The state of this option should be kept in sync with the
       preprocessor option VAR.  If this property is set, then properties
!      'Var' and 'Init' must be set as well.
  
! 'CppReason(CPP_W_ENUM)'
!      This warning option corresponds to 'cpplib.h' warning reason code
       CPP_W_ENUM.  This should only be used for warning options of the
       C-family front-ends.
  
--- 7383,7740 ----
  
       Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)})
  
! ‘Common’
       The option is available for all languages and targets.
  
! ‘Target’
       The option is available for all languages but is target-specific.
  
! ‘Driver’
       The option is handled by the compiler driver using code not shared
!      with the compilers proper (‘cc1’ etc.).
  
! ‘LANGUAGE’
       The option is available when compiling for the given language.
  
       It is possible to specify several different languages for the same
       option.  Each LANGUAGE must have been declared by an earlier
!      ‘Language’ record.  *Note Option file format::.
  
! ‘RejectDriver’
!      The option is only handled by the compilers proper (‘cc1’ etc.) and
       should not be accepted by the driver.
  
! ‘RejectNegative’
       The option does not have a "no-" form.  All options beginning with
       "f", "g", "W" or "m" are assumed to have a "no-" form unless this
       property is used.
  
! ‘Negative(OTHERNAME)’
       The option will turn off another option OTHERNAME, which is the
       option name with the leading "-" removed.  This chain action will
!      propagate through the ‘Negative’ property of the option to be
       turned off.  The driver will prune options, removing those that are
       turned off by some later option.  This pruning is not done for
!      options with ‘Joined’ or ‘JoinedOrMissing’ properties, unless the
!      options have both the ‘RejectNegative’ property and the ‘Negative’
       property mentions itself.
  
       As a consequence, if you have a group of mutually-exclusive
!      options, their ‘Negative’ properties should form a circular chain.
!      For example, if options ‘-A’, ‘-B’ and ‘-C’ are mutually exclusive,
!      their respective ‘Negative’ properties should be ‘Negative(B)’,
!      ‘Negative(C)’ and ‘Negative(A)’.
  
! ‘Joined’
! ‘Separate’
!      The option takes a mandatory argument.  ‘Joined’ indicates that the
!      option and argument can be included in the same ‘argv’ entry (as
!      with ‘-mflush-func=NAME’, for example).  ‘Separate’ indicates that
!      the option and argument can be separate ‘argv’ entries (as with
!      ‘-o’).  An option is allowed to have both of these properties.
  
! ‘JoinedOrMissing’
       The option takes an optional argument.  If the argument is given,
!      it will be part of the same ‘argv’ entry as the option itself.
  
!      This property cannot be used alongside ‘Joined’ or ‘Separate’.
  
! ‘MissingArgError(MESSAGE)’
!      For an option marked ‘Joined’ or ‘Separate’, the message MESSAGE
       will be used as an error message if the mandatory argument is
!      missing; for options without ‘MissingArgError’, a generic error
!      message is used.  MESSAGE should contain a single ‘%qs’ format,
       which will be used to format the name of the option passed.
  
! ‘Args(N)’
!      For an option marked ‘Separate’, indicate that it takes N
       arguments.  The default is 1.
  
! ‘UInteger’
       The option's argument is a non-negative integer consisting of
!      either decimal or hexadecimal digits interpreted as ‘int’.
!      Hexadecimal integers may optionally start with the ‘0x’ or ‘0X’
       prefix.  The option parser validates and converts the argument
!      before passing it to the relevant option handler.  ‘UInteger’
!      should also be used with options like ‘-falign-loops’ where both
!      ‘-falign-loops’ and ‘-falign-loops’=N are supported to make sure
       the saved options are given a full integer.  Positive values of the
!      argument in excess of ‘INT_MAX’ wrap around zero.
  
! ‘Host_Wide_Int’
       The option's argument is a non-negative integer consisting of
       either decimal or hexadecimal digits interpreted as the widest
!      integer type on the host.  As with an ‘UInteger’ argument,
!      hexadecimal integers may optionally start with the ‘0x’ or ‘0X’
       prefix.  The option parser validates and converts the argument
!      before passing it to the relevant option handler.  ‘Host_Wide_Int’
       should be used with options that need to accept very large values.
!      Positive values of the argument in excess of ‘HOST_WIDE_INT_M1U’
!      are assigned ‘HOST_WIDE_INT_M1U’.
  
! ‘IntegerRange(N, M)’
!      The options's arguments are integers of type ‘int’.  The option's
       parser validates that the value of an option integer argument is
       within the closed range [N, M].
  
! ‘ByteSize’
!      A property applicable only to ‘UInteger’ or ‘Host_Wide_Int’
       arguments.  The option's integer argument is interpreted as if in
       infinite precision using saturation arithmetic in the corresponding
!      type.  The argument may be followed by a ‘byte-size’ suffix
!      designating a multiple of bytes such as ‘kB’ and ‘KiB’ for kilobyte
!      and kibibyte, respectively, ‘MB’ and ‘MiB’ for megabyte and
!      mebibyte, ‘GB’ and ‘GiB’ for gigabyte and gigibyte, and so on.
!      ‘ByteSize’ should be used for with options that take a very large
!      argument representing a size in bytes, such as ‘-Wlarger-than=’.
  
! ‘ToLower’
       The option's argument should be converted to lowercase as part of
       putting it in canonical form, and before comparing with the strings
!      indicated by any ‘Enum’ property.
  
! ‘NoDriverArg’
!      For an option marked ‘Separate’, the option only takes an argument
       in the compiler proper, not in the driver.  This is for
       compatibility with existing options that are used both directly and
!      via ‘-Wp,’; new options should not have this property.
  
! ‘Var(VAR)’
       The state of this option should be stored in variable VAR (actually
!      a macro for ‘global_options.x_VAR’).  The way that the state is
       stored depends on the type of option:
  
!         • If the option uses the ‘Mask’ or ‘InverseMask’ properties, VAR
            is the integer variable that contains the mask.
  
!         • If the option is a normal on/off switch, VAR is an integer
            variable that is nonzero when the option is enabled.  The
            options parser will set the variable to 1 when the positive
            form of the option is used and 0 when the "no-" form is used.
  
!         • If the option takes an argument and has the ‘UInteger’
            property, VAR is an integer variable that stores the value of
            the argument.
  
!         • If the option takes an argument and has the ‘Enum’ property,
!           VAR is a variable (type given in the ‘Type’ property of the
!           ‘Enum’ record whose ‘Name’ property has the same argument as
!           the ‘Enum’ property of this option) that stores the value of
            the argument.
  
!         • If the option has the ‘Defer’ property, VAR is a pointer to a
!           ‘VEC(cl_deferred_option,heap)’ that stores the option for
!           later processing.  (VAR is declared with type ‘void *’ and
!           needs to be cast to ‘VEC(cl_deferred_option,heap)’ before
            use.)
  
!         • Otherwise, if the option takes an argument, VAR is a pointer
            to the argument string.  The pointer will be null if the
            argument is optional and wasn't given.
  
       The option-processing script will usually zero-initialize VAR.  You
!      can modify this behavior using ‘Init’.
  
! ‘Var(VAR, SET)’
       The option controls an integer variable VAR and is active when VAR
       equals SET.  The option parser will set VAR to SET when the
!      positive form of the option is used and ‘!SET’ when the "no-" form
       is used.
  
       VAR is declared in the same way as for the single-argument form
       described above.
  
! ‘Init(VALUE)’
!      The variable specified by the ‘Var’ property should be statically
       initialized to VALUE.  If more than one option using the same
!      variable specifies ‘Init’, all must specify the same initializer.
  
! ‘WarnRemoved’
       The option is removed and every usage of such option will result in
       a warning.  We use it option backward compatibility.
  
! ‘Mask(NAME)’
!      The option is associated with a bit in the ‘target_flags’ variable
       (*note Run-time Target::) and is active when that bit is set.  You
!      may also specify ‘Var’ to select a variable other than
!      ‘target_flags’.
  
       The options-processing script will automatically allocate a unique
!      bit for the option.  If the option is attached to ‘target_flags’,
!      the script will set the macro ‘MASK_NAME’ to the appropriate
!      bitmask.  It will also declare a ‘TARGET_NAME’ macro that has the
       value 1 when the option is active and 0 otherwise.  If you use
!      ‘Var’ to attach the option to a different variable, the bitmask
!      macro with be called ‘OPTION_MASK_NAME’.
  
! ‘InverseMask(OTHERNAME)’
! ‘InverseMask(OTHERNAME, THISNAME)’
       The option is the inverse of another option that has the
!      ‘Mask(OTHERNAME)’ property.  If THISNAME is given, the
!      options-processing script will declare a ‘TARGET_THISNAME’ macro
       that is 1 when the option is active and 0 otherwise.
  
! ‘Enum(NAME)’
       The option's argument is a string from the set of strings
!      associated with the corresponding ‘Enum’ record.  The string is
       checked and converted to the integer specified in the corresponding
!      ‘EnumValue’ record before being passed to option handlers.
  
! ‘EnumSet’
!      Must be used together with the ‘Enum(NAME)’ property.
!      Corresponding ‘Enum’ record must use ‘Set’ properties.  The
       option's argument is either a string from the set like for
!      ‘Enum(NAME)’, but with a slightly different behavior that the whole
!      ‘Var’ isn't overwritten, but only the bits in all the enumeration
       values with the same set bitwise ored together.  Or option's
       argument can be a comma separated list of strings where each string
!      is from a different ‘Set(NUMBER)’.
  
! ‘EnumBitSet’
!      Must be used together with the ‘Enum(NAME)’ property.  Similar to
!      ‘EnumSet’, but corresponding ‘Enum’ record must not use ‘Set’
!      properties, each ‘EnumValue’ should have ‘Value’ that is a power of
       2, each value is treated as its own set and its value as the set's
       mask, so there are no mutually exclusive arguments.
  
! ‘Defer’
!      The option should be stored in a vector, specified with ‘Var’, for
       later processing.
  
! ‘Alias(OPT)’
! ‘Alias(OPT, ARG)’
! ‘Alias(OPT, POSARG, NEGARG)’
!      The option is an alias for ‘-OPT’ (or the negative form of that
!      option, depending on ‘NegativeAlias’).  In the first form, any
!      argument passed to the alias is considered to be passed to ‘-OPT’,
!      and ‘-OPT’ is considered to be negated if the alias is used in
       negated form.  In the second form, the alias may not be negated or
       have an argument, and POSARG is considered to be passed as an
!      argument to ‘-OPT’.  In the third form, the alias may not have an
       argument, if the alias is used in the positive form then POSARG is
!      considered to be passed to ‘-OPT’, and if the alias is used in the
!      negative form then NEGARG is considered to be passed to ‘-OPT’.
  
!      Aliases should not specify ‘Var’ or ‘Mask’ or ‘UInteger’.  Aliases
       should normally specify the same languages as the target of the
       alias; the flags on the target will be used to determine any
       diagnostic for use of an option for the wrong language, while those
       on the alias will be used to identify what command-line text is the
       option and what text is any argument to that option.
  
!      When an ‘Alias’ definition is used for an option, driver specs do
!      not need to handle it and no ‘OPT_’ enumeration value is defined
       for it; only the canonical form of the option will be seen in those
       places.
  
! ‘NegativeAlias’
!      For an option marked with ‘Alias(OPT)’, the option is considered to
!      be an alias for the positive form of ‘-OPT’ if negated and for the
!      negative form of ‘-OPT’ if not negated.  ‘NegativeAlias’ may not be
!      used with the forms of ‘Alias’ taking more than one argument.
  
! ‘Ignore’
       This option is ignored apart from printing any warning specified
!      using ‘Warn’.  The option will not be seen by specs and no ‘OPT_’
       enumeration value is defined for it.
  
! ‘SeparateAlias’
!      For an option marked with ‘Joined’, ‘Separate’ and ‘Alias’, the
       option only acts as an alias when passed a separate argument; with
!      a joined argument it acts as a normal option, with an ‘OPT_’
!      enumeration value.  This is for compatibility with the Java ‘-d’
       option and should not be used for new options.
  
! ‘Warn(MESSAGE)’
       If this option is used, output the warning MESSAGE.  MESSAGE is a
!      format string, either taking a single operand with a ‘%qs’ format
       which is the option name, or not taking any operands, which is
!      passed to the ‘warning’ function.  If an alias is marked ‘Warn’,
!      the target of the alias must not also be marked ‘Warn’.
  
! ‘Warning’
!      This is a warning option and should be shown as such in ‘--help’
       output.  This flag does not currently affect anything other than
!      ‘--help’.
  
! ‘Optimization’
       This is an optimization option.  It should be shown as such in
!      ‘--help’ output, and any associated variable named using ‘Var’
       should be saved and restored when the optimization level is changed
!      with ‘optimize’ attributes.
  
! ‘PerFunction’
       This is an option that can be overridden on a per-function basis.
!      ‘Optimization’ implies ‘PerFunction’, but options that do not
       affect executable code generation may use this flag instead, so
       that the option is not taken into account in ways that might affect
       executable code generation.
  
! ‘Param’
       This is an option that is a parameter.
  
! ‘Undocumented’
       The option is deliberately missing documentation and should not be
!      included in the ‘--help’ output.
  
! ‘Condition(COND)’
       The option should only be accepted if preprocessor condition COND
       is true.  Note that any C declarations associated with the option
       will be present even if COND is false; COND simply controls whether
!      the option is accepted and whether it is printed in the ‘--help’
       output.
  
! ‘Save’
!      Build the ‘cl_target_option’ structure to hold a copy of the
!      option, add the functions ‘cl_target_option_save’ and
!      ‘cl_target_option_restore’ to save and restore the options.
  
! ‘SetByCombined’
       The option may also be set by a combined option such as
!      ‘-ffast-math’.  This causes the ‘gcc_options’ struct to have a
!      field ‘frontend_set_NAME’, where ‘NAME’ is the name of the field
!      holding the value of this option (without the leading ‘x_’).  This
       gives the front end a way to indicate that the value has been set
       explicitly and should not be changed by the combined option.  For
!      example, some front ends use this to prevent ‘-ffast-math’ and
!      ‘-fno-fast-math’ from changing the value of ‘-fmath-errno’ for
!      languages that do not use ‘errno’.
  
! ‘EnabledBy(OPT)’
! ‘EnabledBy(OPT || OPT2)’
! ‘EnabledBy(OPT && OPT2)’
!      If not explicitly set, the option is set to the value of ‘-OPT’;
!      multiple options can be given, separated by ‘||’.  The third form
!      using ‘&&’ specifies that the option is only set if both OPT and
!      OPT2 are set.  The options OPT and OPT2 must have the ‘Common’
!      property; otherwise, use ‘LangEnabledBy’.
  
! ‘LangEnabledBy(LANGUAGE, OPT)’
! ‘LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)’
       When compiling for the given language, the option is set to the
!      value of ‘-OPT’, if not explicitly set.  OPT can be also a list of
!      ‘||’ separated options.  In the second form, if OPT is used in the
       positive form then POSARG is considered to be passed to the option,
       and if OPT is used in the negative form then NEGARG is considered
       to be passed to the option.  It is possible to specify several
       different languages.  Each LANGUAGE must have been declared by an
!      earlier ‘Language’ record.  *Note Option file format::.
  
! ‘NoDWARFRecord’
       The option is omitted from the producer string written by
!      ‘-grecord-gcc-switches’.
  
! ‘PchIgnore’
       Even if this is a target option, this option will not be recorded /
       compared to determine if a precompiled header file matches.
  
! ‘CPP(VAR)’
       The state of this option should be kept in sync with the
       preprocessor option VAR.  If this property is set, then properties
!      ‘Var’ and ‘Init’ must be set as well.
  
! ‘CppReason(CPP_W_ENUM)’
!      This warning option corresponds to ‘cpplib.h’ warning reason code
       CPP_W_ENUM.  This should only be used for warning options of the
       C-family front-ends.
  
*************** File: gccint.info,  Node: Parsing pass,
*** 7766,7775 ****
  ================
  
  The language front end is invoked only once, via
! 'lang_hooks.parse_file', to parse the entire input.  The language front
  end may use any intermediate language representation deemed appropriate.
  The C front end uses GENERIC trees (*note GENERIC::), plus a double
! handful of language specific tree codes defined in 'c-common.def'.  The
  Fortran front end uses a completely different private representation.
  
   At some point the front end must translate the representation used in
--- 7766,7775 ----
  ================
  
  The language front end is invoked only once, via
! ‘lang_hooks.parse_file’, to parse the entire input.  The language front
  end may use any intermediate language representation deemed appropriate.
  The C front end uses GENERIC trees (*note GENERIC::), plus a double
! handful of language specific tree codes defined in ‘c-common.def’.  The
  Fortran front end uses a completely different private representation.
  
   At some point the front end must translate the representation used in
*************** all be passed as well.
*** 7812,7820 ****
  
   In any case, the front end needs each complete top-level function or
  data declaration, and each data definition should be passed to
! 'rest_of_decl_compilation'.  Each complete type definition should be
! passed to 'rest_of_type_compilation'.  Each function definition should
! be passed to 'cgraph_finalize_function'.
  
   TODO: I know rest_of_compilation currently has all sorts of RTL
  generation semantics.  I plan to move all code generation bits (both
--- 7812,7820 ----
  
   In any case, the front end needs each complete top-level function or
  data declaration, and each data definition should be passed to
! ‘rest_of_decl_compilation’.  Each complete type definition should be
! passed to ‘rest_of_type_compilation’.  Each function definition should
! be passed to ‘cgraph_finalize_function’.
  
   TODO: I know rest_of_compilation currently has all sorts of RTL
  generation semantics.  I plan to move all code generation bits (both
*************** File: gccint.info,  Node: Gimplification
*** 7832,7838 ****
  9.2 Gimplification pass
  =======================
  
! "Gimplification" is a whimsical term for the process of converting the
  intermediate representation of a function into the GIMPLE language
  (*note GIMPLE::).  The term stuck, and so words like "gimplification",
  "gimplify", "gimplifier" and the like are sprinkled throughout this
--- 7832,7838 ----
  9.2 Gimplification pass
  =======================
  
! “Gimplification” is a whimsical term for the process of converting the
  intermediate representation of a function into the GIMPLE language
  (*note GIMPLE::).  The term stuck, and so words like "gimplification",
  "gimplify", "gimplifier" and the like are sprinkled throughout this
*************** intermediate language used by the front
*** 7844,7866 ****
  Usually it is easier to generate GENERIC trees plus extensions and let
  the language-independent gimplifier do most of the work.
  
!  The main entry point to this pass is 'gimplify_function_tree' located
! in 'gimplify.cc'.  From here we process the entire function gimplifying
  each statement in turn.  The main workhorse for this pass is
! 'gimplify_expr'.  Approximately everything passes through here at least
! once, and it is from here that we invoke the 'lang_hooks.gimplify_expr'
  callback.
  
   The callback should examine the expression in question and return
! 'GS_UNHANDLED' if the expression is not a language specific construct
  that requires attention.  Otherwise it should alter the expression in
  some way to such that forward progress is made toward producing valid
  GIMPLE.  If the callback is certain that the transformation is complete
! and the expression is valid GIMPLE, it should return 'GS_ALL_DONE'.
! Otherwise it should return 'GS_OK', which will cause the expression to
  be processed again.  If the callback encounters an error during the
  transformation (because the front end is relying on the gimplification
! process to finish semantic checks), it should return 'GS_ERROR'.
  
  
  File: gccint.info,  Node: Pass manager,  Next: IPA passes,  Prev: Gimplification pass,  Up: Passes
--- 7844,7866 ----
  Usually it is easier to generate GENERIC trees plus extensions and let
  the language-independent gimplifier do most of the work.
  
!  The main entry point to this pass is ‘gimplify_function_tree’ located
! in ‘gimplify.cc’.  From here we process the entire function gimplifying
  each statement in turn.  The main workhorse for this pass is
! ‘gimplify_expr’.  Approximately everything passes through here at least
! once, and it is from here that we invoke the ‘lang_hooks.gimplify_expr’
  callback.
  
   The callback should examine the expression in question and return
! ‘GS_UNHANDLED’ if the expression is not a language specific construct
  that requires attention.  Otherwise it should alter the expression in
  some way to such that forward progress is made toward producing valid
  GIMPLE.  If the callback is certain that the transformation is complete
! and the expression is valid GIMPLE, it should return ‘GS_ALL_DONE’.
! Otherwise it should return ‘GS_OK’, which will cause the expression to
  be processed again.  If the callback encounters an error during the
  transformation (because the front end is relying on the gimplification
! process to finish semantic checks), it should return ‘GS_ERROR’.
  
  
  File: gccint.info,  Node: Pass manager,  Next: IPA passes,  Prev: Gimplification pass,  Up: Passes
*************** File: gccint.info,  Node: Pass manager,
*** 7868,7875 ****
  9.3 Pass manager
  ================
  
! The pass manager is located in 'passes.cc', 'tree-optimize.c' and
! 'tree-pass.h'.  It processes passes as described in 'passes.def'.  Its
  job is to run all of the individual passes in the correct order, and
  take care of standard bookkeeping that applies to every pass.
  
--- 7868,7875 ----
  9.3 Pass manager
  ================
  
! The pass manager is located in ‘passes.cc’, ‘tree-optimize.c’ and
! ‘tree-pass.h’.  It processes passes as described in ‘passes.def’.  Its
  job is to run all of the individual passes in the correct order, and
  take care of standard bookkeeping that applies to every pass.
  
*************** some particular order, and the pass mana
*** 7881,7887 ****
  happen in the correct order.
  
   The actuality doesn't completely live up to the theory at present.
! Command-line switches and 'timevar_id_t' enumerations must still be
  defined elsewhere.  The pass manager validates constraints but does not
  attempt to (re-)generate data structures or lower intermediate language
  form based on the requirements of the next pass.  Nevertheless, what is
--- 7881,7887 ----
  happen in the correct order.
  
   The actuality doesn't completely live up to the theory at present.
! Command-line switches and ‘timevar_id_t’ enumerations must still be
  defined elsewhere.  The pass manager validates constraints but does not
  attempt to (re-)generate data structures or lower intermediate language
  form based on the requirements of the next pass.  Nevertheless, what is
*************** File: gccint.info,  Node: Small IPA pass
*** 7929,8021 ****
  9.4.1 Small IPA passes
  ----------------------
  
! A small IPA pass is a pass derived from 'simple_ipa_opt_pass'.  As
  described in *note IPA::, it does everything at once and defines only
  the _Execute_ stage.  During this stage it accesses and modifies the
! function bodies.  No 'generate_summary', 'read_summary', or
! 'write_summary' hooks are defined.
  
!    * IPA free lang data
  
       This pass frees resources that are used by the front end but are
!      not needed once it is done.  It is located in 'tree.cc' and is
!      described by 'pass_ipa_free_lang_data'.
  
!    * IPA function and variable visibility
  
       This is a local function pass handling visibilities of all symbols.
!      This happens before LTO streaming, so '-fwhole-program' should be
!      ignored at this level.  It is located in 'ipa-visibility.cc' and is
!      described by 'pass_ipa_function_and_variable_visibility'.
  
!    * IPA remove symbols
  
       This pass performs reachability analysis and reclaims all
!      unreachable nodes.  It is located in 'passes.cc' and is described
!      by 'pass_ipa_remove_symbols'.
  
!    * IPA OpenACC
  
       This is a pass group for OpenACC processing.  It is located in
!      'tree-ssa-loop.cc' and is described by 'pass_ipa_oacc'.
  
!    * IPA points-to analysis
  
       This is a tree-based points-to analysis pass.  The idea behind this
       analyzer is to generate set constraints from the program, then
       solve the resulting constraints in order to generate the points-to
!      sets.  It is located in 'tree-ssa-structalias.cc' and is described
!      by 'pass_ipa_pta'.
  
!    * IPA OpenACC kernels
  
       This is a pass group for processing OpenACC kernels regions.  It is
       a subpass of the IPA OpenACC pass group that runs on offloaded
       functions containing OpenACC kernels loops.  It is located in
!      'tree-ssa-loop.cc' and is described by 'pass_ipa_oacc_kernels'.
  
!    * Target clone
  
       This is a pass for parsing functions with multiple target
!      attributes.  It is located in 'multiple_target.cc' and is described
!      by 'pass_target_clone'.
  
!    * IPA auto profile
  
       This pass uses AutoFDO profiling data to annotate the control flow
!      graph.  It is located in 'auto-profile.cc' and is described by
!      'pass_ipa_auto_profile'.
  
!    * IPA tree profile
  
       This pass does profiling for all functions in the call graph.  It
       calculates branch probabilities and basic block execution counts.
!      It is located in 'tree-profile.cc' and is described by
!      'pass_ipa_tree_profile'.
  
!    * IPA free function summary
  
!      This pass is a small IPA pass when argument 'small_p' is true.  It
       releases inline function summaries and call summaries.  It is
!      located in 'ipa-fnsummary.cc' and is described by
!      'pass_ipa_free_free_fn_summary'.
  
!    * IPA increase alignment
  
       This pass increases the alignment of global arrays to improve
!      vectorization.  It is located in 'tree-vectorizer.cc' and is
!      described by 'pass_ipa_increase_alignment'.
  
!    * IPA transactional memory
  
       This pass is for transactional memory support.  It is located in
!      'trans-mem.cc' and is described by 'pass_ipa_tm'.
  
!    * IPA lower emulated TLS
  
       This pass lowers thread-local storage (TLS) operations to emulation
!      functions provided by libgcc.  It is located in 'tree-emutls.cc'
!      and is described by 'pass_ipa_lower_emutls'.
  
  
  File: gccint.info,  Node: Regular IPA passes,  Next: Late IPA passes,  Prev: Small IPA passes,  Up: IPA passes
--- 7929,8021 ----
  9.4.1 Small IPA passes
  ----------------------
  
! A small IPA pass is a pass derived from ‘simple_ipa_opt_pass’.  As
  described in *note IPA::, it does everything at once and defines only
  the _Execute_ stage.  During this stage it accesses and modifies the
! function bodies.  No ‘generate_summary’, ‘read_summary’, or
! ‘write_summary’ hooks are defined.
  
!    • IPA free lang data
  
       This pass frees resources that are used by the front end but are
!      not needed once it is done.  It is located in ‘tree.cc’ and is
!      described by ‘pass_ipa_free_lang_data’.
  
!    • IPA function and variable visibility
  
       This is a local function pass handling visibilities of all symbols.
!      This happens before LTO streaming, so ‘-fwhole-program’ should be
!      ignored at this level.  It is located in ‘ipa-visibility.cc’ and is
!      described by ‘pass_ipa_function_and_variable_visibility’.
  
!    • IPA remove symbols
  
       This pass performs reachability analysis and reclaims all
!      unreachable nodes.  It is located in ‘passes.cc’ and is described
!      by ‘pass_ipa_remove_symbols’.
  
!    • IPA OpenACC
  
       This is a pass group for OpenACC processing.  It is located in
!      ‘tree-ssa-loop.cc’ and is described by ‘pass_ipa_oacc’.
  
!    • IPA points-to analysis
  
       This is a tree-based points-to analysis pass.  The idea behind this
       analyzer is to generate set constraints from the program, then
       solve the resulting constraints in order to generate the points-to
!      sets.  It is located in ‘tree-ssa-structalias.cc’ and is described
!      by ‘pass_ipa_pta’.
  
!    • IPA OpenACC kernels
  
       This is a pass group for processing OpenACC kernels regions.  It is
       a subpass of the IPA OpenACC pass group that runs on offloaded
       functions containing OpenACC kernels loops.  It is located in
!      ‘tree-ssa-loop.cc’ and is described by ‘pass_ipa_oacc_kernels’.
  
!    • Target clone
  
       This is a pass for parsing functions with multiple target
!      attributes.  It is located in ‘multiple_target.cc’ and is described
!      by ‘pass_target_clone’.
  
!    • IPA auto profile
  
       This pass uses AutoFDO profiling data to annotate the control flow
!      graph.  It is located in ‘auto-profile.cc’ and is described by
!      ‘pass_ipa_auto_profile’.
  
!    • IPA tree profile
  
       This pass does profiling for all functions in the call graph.  It
       calculates branch probabilities and basic block execution counts.
!      It is located in ‘tree-profile.cc’ and is described by
!      ‘pass_ipa_tree_profile’.
  
!    • IPA free function summary
  
!      This pass is a small IPA pass when argument ‘small_p’ is true.  It
       releases inline function summaries and call summaries.  It is
!      located in ‘ipa-fnsummary.cc’ and is described by
!      ‘pass_ipa_free_free_fn_summary’.
  
!    • IPA increase alignment
  
       This pass increases the alignment of global arrays to improve
!      vectorization.  It is located in ‘tree-vectorizer.cc’ and is
!      described by ‘pass_ipa_increase_alignment’.
  
!    • IPA transactional memory
  
       This pass is for transactional memory support.  It is located in
!      ‘trans-mem.cc’ and is described by ‘pass_ipa_tm’.
  
!    • IPA lower emulated TLS
  
       This pass lowers thread-local storage (TLS) operations to emulation
!      functions provided by libgcc.  It is located in ‘tree-emutls.cc’
!      and is described by ‘pass_ipa_lower_emutls’.
  
  
  File: gccint.info,  Node: Regular IPA passes,  Next: Late IPA passes,  Prev: Small IPA passes,  Up: IPA passes
*************** File: gccint.info,  Node: Regular IPA pa
*** 8023,8138 ****
  9.4.2 Regular IPA passes
  ------------------------
  
! A regular IPA pass is a pass derived from 'ipa_opt_pass_d' that is
  executed in WHOPR compilation.  Regular IPA passes may have summary
  hooks implemented in any of the LGEN, WPA or LTRANS stages (*note
  IPA::).
  
!    * IPA whole program visibility
  
       This pass performs various optimizations involving symbol
!      visibility with '-fwhole-program', including symbol privatization,
       discovering local functions, and dismantling comdat groups.  It is
!      located in 'ipa-visibility.cc' and is described by
!      'pass_ipa_whole_program_visibility'.
  
!    * IPA profile
  
       The IPA profile pass propagates profiling frequencies across the
!      call graph.  It is located in 'ipa-profile.cc' and is described by
!      'pass_ipa_profile'.
  
!    * IPA identical code folding
  
       This is the inter-procedural identical code folding pass.  The goal
       of this transformation is to discover functions and read-only
       variables that have exactly the same semantics.  It is located in
!      'ipa-icf.cc' and is described by 'pass_ipa_icf'.
  
!    * IPA devirtualization
  
       This pass performs speculative devirtualization based on the type
       inheritance graph.  When a polymorphic call has only one likely
       target in the unit, it is turned into a speculative call.  It is
!      located in 'ipa-devirt.cc' and is described by 'pass_ipa_devirt'.
  
!    * IPA constant propagation
  
       The goal of this pass is to discover functions that are always
       invoked with some arguments with the same known constant values and
       to modify the functions accordingly.  It can also do partial
       specialization and type-based devirtualization.  It is located in
!      'ipa-cp.cc' and is described by 'pass_ipa_cp'.
  
!    * IPA scalar replacement of aggregates
  
       This pass can replace an aggregate parameter with a set of other
       parameters representing part of the original, turning those passed
       by reference into new ones which pass the value directly.  It also
       removes unused function return values and unused function
!      parameters.  This pass is located in 'ipa-sra.cc' and is described
!      by 'pass_ipa_sra'.
  
!    * IPA constructor/destructor merge
  
       This pass merges multiple constructors and destructors for static
       objects into single functions.  It's only run at LTO time unless
       the target doesn't support constructors and destructors natively.
!      The pass is located in 'ipa.cc' and is described by
!      'pass_ipa_cdtor_merge'.
  
!    * IPA function summary
  
       This pass provides function analysis for inter-procedural passes.
       It collects estimates of function body size, execution time, and
       frame size for each function.  It also estimates information about
       function calls: call statement size, time and how often the
       parameters change for each call.  It is located in
!      'ipa-fnsummary.cc' and is described by 'pass_ipa_fn_summary'.
  
!    * IPA inline
  
       The IPA inline pass handles function inlining with whole-program
       knowledge.  Small functions that are candidates for inlining are
       ordered in increasing badness, bounded by unit growth parameters.
       Unreachable functions are removed from the call graph.  Functions
       called once and not exported from the unit are inlined.  This pass
!      is located in 'ipa-inline.cc' and is described by
!      'pass_ipa_inline'.
  
!    * IPA pure/const analysis
  
!      This pass marks functions as being either const ('TREE_READONLY')
!      or pure ('DECL_PURE_P').  The per-function information is produced
!      by 'pure_const_generate_summary', then the global information is
       computed by performing a transitive closure over the call graph.
!      It is located in 'ipa-pure-const.cc' and is described by
!      'pass_ipa_pure_const'.
  
!    * IPA free function summary
  
!      This pass is a regular IPA pass when argument 'small_p' is false.
       It releases inline function summaries and call summaries.  It is
!      located in 'ipa-fnsummary.cc' and is described by
!      'pass_ipa_free_fn_summary'.
  
!    * IPA reference
  
       This pass gathers information about how variables whose scope is
       confined to the compilation unit are used.  It is located in
!      'ipa-reference.cc' and is described by 'pass_ipa_reference'.
  
!    * IPA single use
  
       This pass checks whether variables are used by a single function.
!      It is located in 'ipa.cc' and is described by
!      'pass_ipa_single_use'.
  
!    * IPA comdats
  
       This pass looks for static symbols that are used exclusively within
       one comdat group, and moves them into that comdat group.  It is
!      located in 'ipa-comdats.cc' and is described by 'pass_ipa_comdats'.
  
  
  File: gccint.info,  Node: Late IPA passes,  Prev: Regular IPA passes,  Up: IPA passes
--- 8023,8138 ----
  9.4.2 Regular IPA passes
  ------------------------
  
! A regular IPA pass is a pass derived from ‘ipa_opt_pass_d’ that is
  executed in WHOPR compilation.  Regular IPA passes may have summary
  hooks implemented in any of the LGEN, WPA or LTRANS stages (*note
  IPA::).
  
!    • IPA whole program visibility
  
       This pass performs various optimizations involving symbol
!      visibility with ‘-fwhole-program’, including symbol privatization,
       discovering local functions, and dismantling comdat groups.  It is
!      located in ‘ipa-visibility.cc’ and is described by
!      ‘pass_ipa_whole_program_visibility’.
  
!    • IPA profile
  
       The IPA profile pass propagates profiling frequencies across the
!      call graph.  It is located in ‘ipa-profile.cc’ and is described by
!      ‘pass_ipa_profile’.
  
!    • IPA identical code folding
  
       This is the inter-procedural identical code folding pass.  The goal
       of this transformation is to discover functions and read-only
       variables that have exactly the same semantics.  It is located in
!      ‘ipa-icf.cc’ and is described by ‘pass_ipa_icf’.
  
!    • IPA devirtualization
  
       This pass performs speculative devirtualization based on the type
       inheritance graph.  When a polymorphic call has only one likely
       target in the unit, it is turned into a speculative call.  It is
!      located in ‘ipa-devirt.cc’ and is described by ‘pass_ipa_devirt’.
  
!    • IPA constant propagation
  
       The goal of this pass is to discover functions that are always
       invoked with some arguments with the same known constant values and
       to modify the functions accordingly.  It can also do partial
       specialization and type-based devirtualization.  It is located in
!      ‘ipa-cp.cc’ and is described by ‘pass_ipa_cp’.
  
!    • IPA scalar replacement of aggregates
  
       This pass can replace an aggregate parameter with a set of other
       parameters representing part of the original, turning those passed
       by reference into new ones which pass the value directly.  It also
       removes unused function return values and unused function
!      parameters.  This pass is located in ‘ipa-sra.cc’ and is described
!      by ‘pass_ipa_sra’.
  
!    • IPA constructor/destructor merge
  
       This pass merges multiple constructors and destructors for static
       objects into single functions.  It's only run at LTO time unless
       the target doesn't support constructors and destructors natively.
!      The pass is located in ‘ipa.cc’ and is described by
!      ‘pass_ipa_cdtor_merge’.
  
!    • IPA function summary
  
       This pass provides function analysis for inter-procedural passes.
       It collects estimates of function body size, execution time, and
       frame size for each function.  It also estimates information about
       function calls: call statement size, time and how often the
       parameters change for each call.  It is located in
!      ‘ipa-fnsummary.cc’ and is described by ‘pass_ipa_fn_summary’.
  
!    • IPA inline
  
       The IPA inline pass handles function inlining with whole-program
       knowledge.  Small functions that are candidates for inlining are
       ordered in increasing badness, bounded by unit growth parameters.
       Unreachable functions are removed from the call graph.  Functions
       called once and not exported from the unit are inlined.  This pass
!      is located in ‘ipa-inline.cc’ and is described by
!      ‘pass_ipa_inline’.
  
!    • IPA pure/const analysis
  
!      This pass marks functions as being either const (‘TREE_READONLY’)
!      or pure (‘DECL_PURE_P’).  The per-function information is produced
!      by ‘pure_const_generate_summary’, then the global information is
       computed by performing a transitive closure over the call graph.
!      It is located in ‘ipa-pure-const.cc’ and is described by
!      ‘pass_ipa_pure_const’.
  
!    • IPA free function summary
  
!      This pass is a regular IPA pass when argument ‘small_p’ is false.
       It releases inline function summaries and call summaries.  It is
!      located in ‘ipa-fnsummary.cc’ and is described by
!      ‘pass_ipa_free_fn_summary’.
  
!    • IPA reference
  
       This pass gathers information about how variables whose scope is
       confined to the compilation unit are used.  It is located in
!      ‘ipa-reference.cc’ and is described by ‘pass_ipa_reference’.
  
!    • IPA single use
  
       This pass checks whether variables are used by a single function.
!      It is located in ‘ipa.cc’ and is described by
!      ‘pass_ipa_single_use’.
  
!    • IPA comdats
  
       This pass looks for static symbols that are used exclusively within
       one comdat group, and moves them into that comdat group.  It is
!      located in ‘ipa-comdats.cc’ and is described by ‘pass_ipa_comdats’.
  
  
  File: gccint.info,  Node: Late IPA passes,  Prev: Regular IPA passes,  Up: IPA passes
*************** Late IPA passes are simple IPA passes ex
*** 8144,8166 ****
  In WHOPR mode the passes are executed after partitioning and thus see
  just parts of the compiled unit.
  
!    * Materialize all clones
  
       Once all functions from compilation unit are in memory, produce all
!      clones and update all calls.  It is located in 'ipa.cc' and is
!      described by 'pass_materialize_all_clones'.
  
!    * IPA points-to analysis
  
       Points-to analysis; this is the same as the points-to-analysis pass
       run with the small IPA passes (*note Small IPA passes::).
  
!    * OpenMP simd clone
  
       This is the OpenMP constructs' SIMD clone pass.  It creates the
       appropriate SIMD clones for functions tagged as elemental SIMD
!      functions.  It is located in 'omp-simd-clone.cc' and is described
!      by 'pass_omp_simd_clone'.
  
  
  File: gccint.info,  Node: Tree SSA passes,  Next: RTL passes,  Prev: IPA passes,  Up: Passes
--- 8144,8166 ----
  In WHOPR mode the passes are executed after partitioning and thus see
  just parts of the compiled unit.
  
!    • Materialize all clones
  
       Once all functions from compilation unit are in memory, produce all
!      clones and update all calls.  It is located in ‘ipa.cc’ and is
!      described by ‘pass_materialize_all_clones’.
  
!    • IPA points-to analysis
  
       Points-to analysis; this is the same as the points-to-analysis pass
       run with the small IPA passes (*note Small IPA passes::).
  
!    • OpenMP simd clone
  
       This is the OpenMP constructs' SIMD clone pass.  It creates the
       appropriate SIMD clones for functions tagged as elemental SIMD
!      functions.  It is located in ‘omp-simd-clone.cc’ and is described
!      by ‘pass_omp_simd_clone’.
  
  
  File: gccint.info,  Node: Tree SSA passes,  Next: RTL passes,  Prev: IPA passes,  Up: Passes
*************** File: gccint.info,  Node: Tree SSA passe
*** 8171,8488 ****
  The following briefly describes the Tree optimization passes that are
  run after gimplification and what source files they are located in.
  
!    * Remove useless statements
  
       This pass is an extremely simple sweep across the gimple code in
       which we identify obviously dead code and remove it.  Here we do
!      things like simplify 'if' statements with constant conditions,
       remove exception handling constructs surrounding code that
       obviously cannot throw, remove lexical bindings that contain no
       variables, and other assorted simplistic cleanups.  The idea is to
       get rid of the obvious stuff quickly rather than wait until later
       when it's more work to get rid of it.  This pass is located in
!      'tree-cfg.cc' and described by 'pass_remove_useless_stmts'.
  
!    * OpenMP lowering
  
!      If OpenMP generation ('-fopenmp') is enabled, this pass lowers
       OpenMP constructs into GIMPLE.
  
       Lowering of OpenMP constructs involves creating replacement
       expressions for local variables that have been mapped using data
       sharing clauses, exposing the control flow of most synchronization
       directives and adding region markers to facilitate the creation of
!      the control flow graph.  The pass is located in 'omp-low.cc' and is
!      described by 'pass_lower_omp'.
  
!    * OpenMP expansion
  
!      If OpenMP generation ('-fopenmp') is enabled, this pass expands
       parallel regions into their own functions to be invoked by the
!      thread library.  The pass is located in 'omp-low.cc' and is
!      described by 'pass_expand_omp'.
  
!    * Lower control flow
  
!      This pass flattens 'if' statements ('COND_EXPR') and moves lexical
!      bindings ('BIND_EXPR') out of line.  After this pass, all 'if'
!      statements will have exactly two 'goto' statements in its 'then'
!      and 'else' arms.  Lexical binding information for each statement
!      will be found in 'TREE_BLOCK' rather than being inferred from its
!      position under a 'BIND_EXPR'.  This pass is found in
!      'gimple-low.cc' and is described by 'pass_lower_cf'.
  
!    * Lower exception handling control flow
  
       This pass decomposes high-level exception handling constructs
!      ('TRY_FINALLY_EXPR' and 'TRY_CATCH_EXPR') into a form that
       explicitly represents the control flow involved.  After this pass,
!      'lookup_stmt_eh_region' will return a non-negative number for any
       statement that may have EH control flow semantics; examine
!      'tree_can_throw_internal' or 'tree_can_throw_external' for exact
       semantics.  Exact control flow may be extracted from
!      'foreach_reachable_handler'.  The EH region nesting tree is defined
!      in 'except.h' and built in 'except.cc'.  The lowering pass itself
!      is in 'tree-eh.cc' and is described by 'pass_lower_eh'.
  
!    * Build the control flow graph
  
       This pass decomposes a function into basic blocks and creates all
!      of the edges that connect them.  It is located in 'tree-cfg.cc' and
!      is described by 'pass_build_cfg'.
  
!    * Find all referenced variables
  
       This pass walks the entire function and collects an array of all
!      variables referenced in the function, 'referenced_vars'.  The index
       at which a variable is found in the array is used as a UID for the
       variable within this function.  This data is needed by the SSA
!      rewriting routines.  The pass is located in 'tree-dfa.cc' and is
!      described by 'pass_referenced_vars'.
  
!    * Enter static single assignment form
  
       This pass rewrites the function such that it is in SSA form.  After
!      this pass, all 'is_gimple_reg' variables will be referenced by
!      'SSA_NAME', and all occurrences of other variables will be
!      annotated with 'VDEFS' and 'VUSES'; PHI nodes will have been
       inserted as necessary for each basic block.  This pass is located
!      in 'tree-ssa.cc' and is described by 'pass_build_ssa'.
  
!    * Warn for uninitialized variables
  
!      This pass scans the function for uses of 'SSA_NAME's that are fed
       by default definition.  For non-parameter variables, such uses are
       uninitialized.  The pass is run twice, before and after
       optimization (if turned on).  In the first pass we only warn for
       uses that are positively uninitialized; in the second pass we warn
       for uses that are possibly uninitialized.  The pass is located in
!      'tree-ssa.cc' and is defined by 'pass_early_warn_uninitialized' and
!      'pass_late_warn_uninitialized'.
  
!    * Dead code elimination
  
       This pass scans the function for statements without side effects
       whose result is unused.  It does not do memory life analysis, so
       any value that is stored in memory is considered used.  The pass is
       run multiple times throughout the optimization process.  It is
!      located in 'tree-ssa-dce.cc' and is described by 'pass_dce'.
  
!    * Dominator optimizations
  
       This pass performs trivial dominator-based copy and constant
       propagation, expression simplification, and jump threading.  It is
       run multiple times throughout the optimization process.  It is
!      located in 'tree-ssa-dom.cc' and is described by 'pass_dominator'.
  
!    * Forward propagation of single-use variables
  
       This pass attempts to remove redundant computation by substituting
       variables that are used once into the expression that uses them and
       seeing if the result can be simplified.  It is located in
!      'tree-ssa-forwprop.cc' and is described by 'pass_forwprop'.
  
!    * Copy Renaming
  
       This pass attempts to change the name of compiler temporaries
       involved in copy operations such that SSA->normal can coalesce the
       copy away.  When compiler temporaries are copies of user variables,
       it also renames the compiler temporary to the user variable
       resulting in better use of user symbols.  It is located in
!      'tree-ssa-copyrename.c' and is described by 'pass_copyrename'.
  
!    * PHI node optimizations
  
       This pass recognizes forms of PHI inputs that can be represented as
       conditional expressions and rewrites them into straight line code.
!      It is located in 'tree-ssa-phiopt.cc' and is described by
!      'pass_phiopt'.
  
!    * May-alias optimization
  
       This pass performs a flow sensitive SSA-based points-to analysis.
       The resulting may-alias, must-alias, and escape analysis
       information is used to promote variables from in-memory addressable
       objects to non-aliased variables that can be renamed into SSA form.
!      We also update the 'VDEF'/'VUSE' memory tags for non-renameable
       aggregates so that we get fewer false kills.  The pass is located
!      in 'tree-ssa-alias.cc' and is described by 'pass_may_alias'.
  
       Interprocedural points-to information is located in
!      'tree-ssa-structalias.cc' and described by 'pass_ipa_pta'.
  
!    * Profiling
  
       This pass instruments the function in order to collect runtime
       block and value profiling data.  Such data may be fed back into the
       compiler on a subsequent run so as to allow optimization based on
       expected execution frequencies.  The pass is located in
!      'tree-profile.cc' and is described by 'pass_ipa_tree_profile'.
  
!    * Static profile estimation
  
       This pass implements series of heuristics to guess propababilities
       of branches.  The resulting predictions are turned into edge
       profile by propagating branches across the control flow graphs.
!      The pass is located in 'tree-profile.cc' and is described by
!      'pass_profile'.
  
!    * Lower complex arithmetic
  
       This pass rewrites complex arithmetic operations into their
       component scalar arithmetic operations.  The pass is located in
!      'tree-complex.cc' and is described by 'pass_lower_complex'.
  
!    * Scalar replacement of aggregates
  
       This pass rewrites suitable non-aliased local aggregate variables
       into a set of scalar variables.  The resulting scalar variables are
       rewritten into SSA form, which allows subsequent optimization
       passes to do a significantly better job with them.  The pass is
!      located in 'tree-sra.cc' and is described by 'pass_sra'.
  
!    * Dead store elimination
  
       This pass eliminates stores to memory that are subsequently
       overwritten by another store, without any intervening loads.  The
!      pass is located in 'tree-ssa-dse.cc' and is described by
!      'pass_dse'.
  
!    * Tail recursion elimination
  
       This pass transforms tail recursion into a loop.  It is located in
!      'tree-tailcall.cc' and is described by 'pass_tail_recursion'.
  
!    * Forward store motion
  
       This pass sinks stores and assignments down the flowgraph closer to
!      their use point.  The pass is located in 'tree-ssa-sink.cc' and is
!      described by 'pass_sink_code'.
  
!    * Partial redundancy elimination
  
       This pass eliminates partially redundant computations, as well as
!      performing load motion.  The pass is located in 'tree-ssa-pre.cc'
!      and is described by 'pass_pre'.
  
       Just before partial redundancy elimination, if
!      '-funsafe-math-optimizations' is on, GCC tries to convert divisions
       to multiplications by the reciprocal.  The pass is located in
!      'tree-ssa-math-opts.cc' and is described by 'pass_cse_reciprocal'.
  
!    * Full redundancy elimination
  
       This is a simpler form of PRE that only eliminates redundancies
!      that occur on all paths.  It is located in 'tree-ssa-pre.cc' and
!      described by 'pass_fre'.
  
!    * Loop optimization
  
!      The main driver of the pass is placed in 'tree-ssa-loop.cc' and
!      described by 'pass_loop'.
  
       The optimizations performed by this pass are:
  
       Loop invariant motion.  This pass moves only invariants that would
       be hard to handle on RTL level (function calls, operations that
!      expand to nontrivial sequences of insns).  With '-funswitch-loops'
       it also moves operands of conditions that are invariant out of the
       loop, so that we can use just trivial invariantness analysis in
       loop unswitching.  The pass also includes store motion.  The pass
!      is implemented in 'tree-ssa-loop-im.cc'.
  
       Canonical induction variable creation.  This pass creates a simple
       counter for number of iterations of the loop and replaces the exit
       condition of the loop using it, in case when a complicated analysis
       is necessary to determine the number of iterations.  Later
       optimizations then may determine the number easily.  The pass is
!      implemented in 'tree-ssa-loop-ivcanon.cc'.
  
       Induction variable optimizations.  This pass performs standard
       induction variable optimizations, including strength reduction,
       induction variable merging and induction variable elimination.  The
!      pass is implemented in 'tree-ssa-loop-ivopts.cc'.
  
       Loop unswitching.  This pass moves the conditional jumps that are
       invariant out of the loops.  To achieve this, a duplicate of the
       loop is created for each possible outcome of conditional jump(s).
!      The pass is implemented in 'tree-ssa-loop-unswitch.cc'.
  
       Loop splitting.  If a loop contains a conditional statement that is
       always true for one part of the iteration space and false for the
       other this pass splits the loop into two, one dealing with one side
       the other only with the other, thereby removing one inner-loop
!      conditional.  The pass is implemented in 'tree-ssa-loop-split.cc'.
  
       The optimizations also use various utility functions contained in
!      'tree-ssa-loop-manip.cc', 'cfgloop.cc', 'cfgloopanal.cc' and
!      'cfgloopmanip.cc'.
  
       Vectorization.  This pass transforms loops to operate on vector
       types instead of scalar types.  Data parallelism across loop
       iterations is exploited to group data elements from consecutive
       iterations into a vector and operate on them in parallel.
       Depending on available target support the loop is conceptually
!      unrolled by a factor 'VF' (vectorization factor), which is the
       number of elements operated upon in parallel in each iteration, and
!      the 'VF' copies of each scalar operation are fused to form a vector
       operation.  Additional loop transformations such as peeling and
       versioning may take place to align the number of iterations, and to
       align the memory accesses in the loop.  The pass is implemented in
!      'tree-vectorizer.cc' (the main driver), 'tree-vect-loop.cc' and
!      'tree-vect-loop-manip.cc' (loop specific parts and general loop
!      utilities), 'tree-vect-slp' (loop-aware SLP functionality),
!      'tree-vect-stmts.cc', 'tree-vect-data-refs.cc' and
!      'tree-vect-slp-patterns.cc' containing the SLP pattern matcher.
!      Analysis of data references is in 'tree-data-ref.cc'.
  
       SLP Vectorization.  This pass performs vectorization of
       straight-line code.  The pass is implemented in
!      'tree-vectorizer.cc' (the main driver), 'tree-vect-slp.cc',
!      'tree-vect-stmts.cc' and 'tree-vect-data-refs.cc'.
  
       Autoparallelization.  This pass splits the loop iteration space to
       run into several threads.  The pass is implemented in
!      'tree-parloops.cc'.
  
       Graphite is a loop transformation framework based on the polyhedral
       model.  Graphite stands for Gimple Represented as Polyhedra.  The
       internals of this infrastructure are documented in
       .  The passes working on this
!      representation are implemented in the various 'graphite-*' files.
  
!    * Tree level if-conversion for vectorizer
  
       This pass applies if-conversion to simple loops to help vectorizer.
       We identify if convertible loops, if-convert statements and merge
       basic blocks in one big block.  The idea is to present loop in such
       form so that vectorizer can have one to one mapping between
       statements and available vector operations.  This pass is located
!      in 'tree-if-conv.cc' and is described by 'pass_if_conversion'.
  
!    * Conditional constant propagation
  
       This pass relaxes a lattice of values in order to identify those
       that must be constant even in the presence of conditional branches.
!      The pass is located in 'tree-ssa-ccp.cc' and is described by
!      'pass_ccp'.
  
       A related pass that works on memory loads and stores, and not just
!      register values, is located in 'tree-ssa-ccp.cc' and described by
!      'pass_store_ccp'.
  
!    * Conditional copy propagation
  
       This is similar to constant propagation but the lattice of values
       is the "copy-of" relation.  It eliminates redundant copies from the
!      code.  The pass is located in 'tree-ssa-copy.cc' and described by
!      'pass_copy_prop'.
  
       A related pass that works on memory copies, and not just register
!      copies, is located in 'tree-ssa-copy.cc' and described by
!      'pass_store_copy_prop'.
  
!    * Value range propagation
  
       This transformation is similar to constant propagation but instead
       of propagating single constant values, it propagates known value
--- 8171,8488 ----
  The following briefly describes the Tree optimization passes that are
  run after gimplification and what source files they are located in.
  
!    • Remove useless statements
  
       This pass is an extremely simple sweep across the gimple code in
       which we identify obviously dead code and remove it.  Here we do
!      things like simplify ‘if’ statements with constant conditions,
       remove exception handling constructs surrounding code that
       obviously cannot throw, remove lexical bindings that contain no
       variables, and other assorted simplistic cleanups.  The idea is to
       get rid of the obvious stuff quickly rather than wait until later
       when it's more work to get rid of it.  This pass is located in
!      ‘tree-cfg.cc’ and described by ‘pass_remove_useless_stmts’.
  
!    • OpenMP lowering
  
!      If OpenMP generation (‘-fopenmp’) is enabled, this pass lowers
       OpenMP constructs into GIMPLE.
  
       Lowering of OpenMP constructs involves creating replacement
       expressions for local variables that have been mapped using data
       sharing clauses, exposing the control flow of most synchronization
       directives and adding region markers to facilitate the creation of
!      the control flow graph.  The pass is located in ‘omp-low.cc’ and is
!      described by ‘pass_lower_omp’.
  
!    • OpenMP expansion
  
!      If OpenMP generation (‘-fopenmp’) is enabled, this pass expands
       parallel regions into their own functions to be invoked by the
!      thread library.  The pass is located in ‘omp-low.cc’ and is
!      described by ‘pass_expand_omp’.
  
!    • Lower control flow
  
!      This pass flattens ‘if’ statements (‘COND_EXPR’) and moves lexical
!      bindings (‘BIND_EXPR’) out of line.  After this pass, all ‘if’
!      statements will have exactly two ‘goto’ statements in its ‘then’
!      and ‘else’ arms.  Lexical binding information for each statement
!      will be found in ‘TREE_BLOCK’ rather than being inferred from its
!      position under a ‘BIND_EXPR’.  This pass is found in
!      ‘gimple-low.cc’ and is described by ‘pass_lower_cf’.
  
!    • Lower exception handling control flow
  
       This pass decomposes high-level exception handling constructs
!      (‘TRY_FINALLY_EXPR’ and ‘TRY_CATCH_EXPR’) into a form that
       explicitly represents the control flow involved.  After this pass,
!      ‘lookup_stmt_eh_region’ will return a non-negative number for any
       statement that may have EH control flow semantics; examine
!      ‘tree_can_throw_internal’ or ‘tree_can_throw_external’ for exact
       semantics.  Exact control flow may be extracted from
!      ‘foreach_reachable_handler’.  The EH region nesting tree is defined
!      in ‘except.h’ and built in ‘except.cc’.  The lowering pass itself
!      is in ‘tree-eh.cc’ and is described by ‘pass_lower_eh’.
  
!    • Build the control flow graph
  
       This pass decomposes a function into basic blocks and creates all
!      of the edges that connect them.  It is located in ‘tree-cfg.cc’ and
!      is described by ‘pass_build_cfg’.
  
!    • Find all referenced variables
  
       This pass walks the entire function and collects an array of all
!      variables referenced in the function, ‘referenced_vars’.  The index
       at which a variable is found in the array is used as a UID for the
       variable within this function.  This data is needed by the SSA
!      rewriting routines.  The pass is located in ‘tree-dfa.cc’ and is
!      described by ‘pass_referenced_vars’.
  
!    • Enter static single assignment form
  
       This pass rewrites the function such that it is in SSA form.  After
!      this pass, all ‘is_gimple_reg’ variables will be referenced by
!      ‘SSA_NAME’, and all occurrences of other variables will be
!      annotated with ‘VDEFS’ and ‘VUSES’; PHI nodes will have been
       inserted as necessary for each basic block.  This pass is located
!      in ‘tree-ssa.cc’ and is described by ‘pass_build_ssa’.
  
!    • Warn for uninitialized variables
  
!      This pass scans the function for uses of ‘SSA_NAME’s that are fed
       by default definition.  For non-parameter variables, such uses are
       uninitialized.  The pass is run twice, before and after
       optimization (if turned on).  In the first pass we only warn for
       uses that are positively uninitialized; in the second pass we warn
       for uses that are possibly uninitialized.  The pass is located in
!      ‘tree-ssa.cc’ and is defined by ‘pass_early_warn_uninitialized’ and
!      ‘pass_late_warn_uninitialized’.
  
!    • Dead code elimination
  
       This pass scans the function for statements without side effects
       whose result is unused.  It does not do memory life analysis, so
       any value that is stored in memory is considered used.  The pass is
       run multiple times throughout the optimization process.  It is
!      located in ‘tree-ssa-dce.cc’ and is described by ‘pass_dce’.
  
!    • Dominator optimizations
  
       This pass performs trivial dominator-based copy and constant
       propagation, expression simplification, and jump threading.  It is
       run multiple times throughout the optimization process.  It is
!      located in ‘tree-ssa-dom.cc’ and is described by ‘pass_dominator’.
  
!    • Forward propagation of single-use variables
  
       This pass attempts to remove redundant computation by substituting
       variables that are used once into the expression that uses them and
       seeing if the result can be simplified.  It is located in
!      ‘tree-ssa-forwprop.cc’ and is described by ‘pass_forwprop’.
  
!    • Copy Renaming
  
       This pass attempts to change the name of compiler temporaries
       involved in copy operations such that SSA->normal can coalesce the
       copy away.  When compiler temporaries are copies of user variables,
       it also renames the compiler temporary to the user variable
       resulting in better use of user symbols.  It is located in
!      ‘tree-ssa-copyrename.c’ and is described by ‘pass_copyrename’.
  
!    • PHI node optimizations
  
       This pass recognizes forms of PHI inputs that can be represented as
       conditional expressions and rewrites them into straight line code.
!      It is located in ‘tree-ssa-phiopt.cc’ and is described by
!      ‘pass_phiopt’.
  
!    • May-alias optimization
  
       This pass performs a flow sensitive SSA-based points-to analysis.
       The resulting may-alias, must-alias, and escape analysis
       information is used to promote variables from in-memory addressable
       objects to non-aliased variables that can be renamed into SSA form.
!      We also update the ‘VDEF’/‘VUSE’ memory tags for non-renameable
       aggregates so that we get fewer false kills.  The pass is located
!      in ‘tree-ssa-alias.cc’ and is described by ‘pass_may_alias’.
  
       Interprocedural points-to information is located in
!      ‘tree-ssa-structalias.cc’ and described by ‘pass_ipa_pta’.
  
!    • Profiling
  
       This pass instruments the function in order to collect runtime
       block and value profiling data.  Such data may be fed back into the
       compiler on a subsequent run so as to allow optimization based on
       expected execution frequencies.  The pass is located in
!      ‘tree-profile.cc’ and is described by ‘pass_ipa_tree_profile’.
  
!    • Static profile estimation
  
       This pass implements series of heuristics to guess propababilities
       of branches.  The resulting predictions are turned into edge
       profile by propagating branches across the control flow graphs.
!      The pass is located in ‘tree-profile.cc’ and is described by
!      ‘pass_profile’.
  
!    • Lower complex arithmetic
  
       This pass rewrites complex arithmetic operations into their
       component scalar arithmetic operations.  The pass is located in
!      ‘tree-complex.cc’ and is described by ‘pass_lower_complex’.
  
!    • Scalar replacement of aggregates
  
       This pass rewrites suitable non-aliased local aggregate variables
       into a set of scalar variables.  The resulting scalar variables are
       rewritten into SSA form, which allows subsequent optimization
       passes to do a significantly better job with them.  The pass is
!      located in ‘tree-sra.cc’ and is described by ‘pass_sra’.
  
!    • Dead store elimination
  
       This pass eliminates stores to memory that are subsequently
       overwritten by another store, without any intervening loads.  The
!      pass is located in ‘tree-ssa-dse.cc’ and is described by
!      ‘pass_dse’.
  
!    • Tail recursion elimination
  
       This pass transforms tail recursion into a loop.  It is located in
!      ‘tree-tailcall.cc’ and is described by ‘pass_tail_recursion’.
  
!    • Forward store motion
  
       This pass sinks stores and assignments down the flowgraph closer to
!      their use point.  The pass is located in ‘tree-ssa-sink.cc’ and is
!      described by ‘pass_sink_code’.
  
!    • Partial redundancy elimination
  
       This pass eliminates partially redundant computations, as well as
!      performing load motion.  The pass is located in ‘tree-ssa-pre.cc’
!      and is described by ‘pass_pre’.
  
       Just before partial redundancy elimination, if
!      ‘-funsafe-math-optimizations’ is on, GCC tries to convert divisions
       to multiplications by the reciprocal.  The pass is located in
!      ‘tree-ssa-math-opts.cc’ and is described by ‘pass_cse_reciprocal’.
  
!    • Full redundancy elimination
  
       This is a simpler form of PRE that only eliminates redundancies
!      that occur on all paths.  It is located in ‘tree-ssa-pre.cc’ and
!      described by ‘pass_fre’.
  
!    • Loop optimization
  
!      The main driver of the pass is placed in ‘tree-ssa-loop.cc’ and
!      described by ‘pass_loop’.
  
       The optimizations performed by this pass are:
  
       Loop invariant motion.  This pass moves only invariants that would
       be hard to handle on RTL level (function calls, operations that
!      expand to nontrivial sequences of insns).  With ‘-funswitch-loops’
       it also moves operands of conditions that are invariant out of the
       loop, so that we can use just trivial invariantness analysis in
       loop unswitching.  The pass also includes store motion.  The pass
!      is implemented in ‘tree-ssa-loop-im.cc’.
  
       Canonical induction variable creation.  This pass creates a simple
       counter for number of iterations of the loop and replaces the exit
       condition of the loop using it, in case when a complicated analysis
       is necessary to determine the number of iterations.  Later
       optimizations then may determine the number easily.  The pass is
!      implemented in ‘tree-ssa-loop-ivcanon.cc’.
  
       Induction variable optimizations.  This pass performs standard
       induction variable optimizations, including strength reduction,
       induction variable merging and induction variable elimination.  The
!      pass is implemented in ‘tree-ssa-loop-ivopts.cc’.
  
       Loop unswitching.  This pass moves the conditional jumps that are
       invariant out of the loops.  To achieve this, a duplicate of the
       loop is created for each possible outcome of conditional jump(s).
!      The pass is implemented in ‘tree-ssa-loop-unswitch.cc’.
  
       Loop splitting.  If a loop contains a conditional statement that is
       always true for one part of the iteration space and false for the
       other this pass splits the loop into two, one dealing with one side
       the other only with the other, thereby removing one inner-loop
!      conditional.  The pass is implemented in ‘tree-ssa-loop-split.cc’.
  
       The optimizations also use various utility functions contained in
!      ‘tree-ssa-loop-manip.cc’, ‘cfgloop.cc’, ‘cfgloopanal.cc’ and
!      ‘cfgloopmanip.cc’.
  
       Vectorization.  This pass transforms loops to operate on vector
       types instead of scalar types.  Data parallelism across loop
       iterations is exploited to group data elements from consecutive
       iterations into a vector and operate on them in parallel.
       Depending on available target support the loop is conceptually
!      unrolled by a factor ‘VF’ (vectorization factor), which is the
       number of elements operated upon in parallel in each iteration, and
!      the ‘VF’ copies of each scalar operation are fused to form a vector
       operation.  Additional loop transformations such as peeling and
       versioning may take place to align the number of iterations, and to
       align the memory accesses in the loop.  The pass is implemented in
!      ‘tree-vectorizer.cc’ (the main driver), ‘tree-vect-loop.cc’ and
!      ‘tree-vect-loop-manip.cc’ (loop specific parts and general loop
!      utilities), ‘tree-vect-slp’ (loop-aware SLP functionality),
!      ‘tree-vect-stmts.cc’, ‘tree-vect-data-refs.cc’ and
!      ‘tree-vect-slp-patterns.cc’ containing the SLP pattern matcher.
!      Analysis of data references is in ‘tree-data-ref.cc’.
  
       SLP Vectorization.  This pass performs vectorization of
       straight-line code.  The pass is implemented in
!      ‘tree-vectorizer.cc’ (the main driver), ‘tree-vect-slp.cc’,
!      ‘tree-vect-stmts.cc’ and ‘tree-vect-data-refs.cc’.
  
       Autoparallelization.  This pass splits the loop iteration space to
       run into several threads.  The pass is implemented in
!      ‘tree-parloops.cc’.
  
       Graphite is a loop transformation framework based on the polyhedral
       model.  Graphite stands for Gimple Represented as Polyhedra.  The
       internals of this infrastructure are documented in
       .  The passes working on this
!      representation are implemented in the various ‘graphite-*’ files.
  
!    • Tree level if-conversion for vectorizer
  
       This pass applies if-conversion to simple loops to help vectorizer.
       We identify if convertible loops, if-convert statements and merge
       basic blocks in one big block.  The idea is to present loop in such
       form so that vectorizer can have one to one mapping between
       statements and available vector operations.  This pass is located
!      in ‘tree-if-conv.cc’ and is described by ‘pass_if_conversion’.
  
!    • Conditional constant propagation
  
       This pass relaxes a lattice of values in order to identify those
       that must be constant even in the presence of conditional branches.
!      The pass is located in ‘tree-ssa-ccp.cc’ and is described by
!      ‘pass_ccp’.
  
       A related pass that works on memory loads and stores, and not just
!      register values, is located in ‘tree-ssa-ccp.cc’ and described by
!      ‘pass_store_ccp’.
  
!    • Conditional copy propagation
  
       This is similar to constant propagation but the lattice of values
       is the "copy-of" relation.  It eliminates redundant copies from the
!      code.  The pass is located in ‘tree-ssa-copy.cc’ and described by
!      ‘pass_copy_prop’.
  
       A related pass that works on memory copies, and not just register
!      copies, is located in ‘tree-ssa-copy.cc’ and described by
!      ‘pass_store_copy_prop’.
  
!    • Value range propagation
  
       This transformation is similar to constant propagation but instead
       of propagating single constant values, it propagates known value
*************** run after gimplification and what source
*** 8493,8610 ****
       branch probabilities nor it uses more than a single range per SSA
       name.  This means that the current implementation cannot be used
       for branch prediction (though adapting it would not be difficult).
!      The pass is located in 'tree-vrp.cc' and is described by
!      'pass_vrp'.
  
!    * Folding built-in functions
  
       This pass simplifies built-in functions, as applicable, with
       constant arguments or with inferable string lengths.  It is located
!      in 'tree-ssa-ccp.cc' and is described by 'pass_fold_builtins'.
  
!    * Split critical edges
  
       This pass identifies critical edges and inserts empty basic blocks
       such that the edge is no longer critical.  The pass is located in
!      'tree-cfg.cc' and is described by 'pass_split_crit_edges'.
  
!    * Control dependence dead code elimination
  
       This pass is a stronger form of dead code elimination that can
       eliminate unnecessary control flow statements.  It is located in
!      'tree-ssa-dce.cc' and is described by 'pass_cd_dce'.
  
!    * Tail call elimination
  
       This pass identifies function calls that may be rewritten into
       jumps.  No code transformation is actually applied here, but the
       data and control flow problem is solved.  The code transformation
       requires target support, and so is delayed until RTL.  In the
!      meantime 'CALL_EXPR_TAILCALL' is set indicating the possibility.
!      The pass is located in 'tree-tailcall.cc' and is described by
!      'pass_tail_calls'.  The RTL transformation is handled by
!      'fixup_tail_calls' in 'calls.cc'.
  
!    * Warn for function return without value
  
       For non-void functions, this pass locates return statements that do
       not specify a value and issues a warning.  Such a statement may
       have been injected by falling off the end of the function.  This
       pass is run last so that we have as much time as possible to prove
       that the statement is not reachable.  It is located in
!      'tree-cfg.cc' and is described by 'pass_warn_function_return'.
  
!    * Leave static single assignment form
  
       This pass rewrites the function such that it is in normal form.  At
       the same time, we eliminate as many single-use temporaries as
       possible, so the intermediate language is no longer GIMPLE, but
!      GENERIC.  The pass is located in 'tree-outof-ssa.cc' and is
!      described by 'pass_del_ssa'.
  
!    * Merge PHI nodes that feed into one another
  
       This is part of the CFG cleanup passes.  It attempts to join PHI
       nodes from a forwarder CFG block into another block with PHI nodes.
!      The pass is located in 'tree-cfgcleanup.cc' and is described by
!      'pass_merge_phi'.
  
!    * Return value optimization
  
       If a function always returns the same local variable, and that
       local variable is an aggregate type, then the variable is replaced
       with the return value for the function (i.e., the function's
       DECL_RESULT). This is equivalent to the C++ named return value
       optimization applied to GIMPLE.  The pass is located in
!      'tree-nrv.cc' and is described by 'pass_nrv'.
  
!    * Return slot optimization
  
!      If a function returns a memory object and is called as 'var =
!      foo()', this pass tries to change the call so that the address of
!      'var' is sent to the caller to avoid an extra memory copy.  This
!      pass is located in 'tree-nrv.cc' and is described by
!      'pass_return_slot'.
  
!    * Optimize calls to '__builtin_object_size' or
!      '__builtin_dynamic_object_size'
  
       This is a propagation pass similar to CCP that tries to remove
!      calls to '__builtin_object_size' when the upper or lower bound for
       the size of the object can be computed at compile-time.  It also
!      tries to replace calls to '__builtin_dynamic_object_size' with an
       expression that evaluates the upper or lower bound for the size of
!      the object.  This pass is located in 'tree-object-size.cc' and is
!      described by 'pass_object_sizes'.
  
!    * Loop invariant motion
  
       This pass removes expensive loop-invariant computations out of
!      loops.  The pass is located in 'tree-ssa-loop.cc' and described by
!      'pass_lim'.
  
!    * Loop nest optimizations
  
       This is a family of loop transformations that works on loop nests.
       It includes loop interchange, scaling, skewing and reversal and
       they are all geared to the optimization of data locality in array
       traversals and the removal of dependencies that hamper
       optimizations such as loop parallelization and vectorization.  The
!      pass is located in 'tree-loop-linear.c' and described by
!      'pass_linear_transform'.
  
!    * Removal of empty loops
  
       This pass removes loops with no code in them.  The pass is located
!      in 'tree-ssa-loop-ivcanon.cc' and described by 'pass_empty_loop'.
  
!    * Unrolling of small loops
  
       This pass completely unrolls loops with few iterations.  The pass
!      is located in 'tree-ssa-loop-ivcanon.cc' and described by
!      'pass_complete_unroll'.
  
!    * Predictive commoning
  
       This pass makes the code reuse the computations from the previous
       iterations of the loops, especially loads and stores to memory.  It
--- 8493,8610 ----
       branch probabilities nor it uses more than a single range per SSA
       name.  This means that the current implementation cannot be used
       for branch prediction (though adapting it would not be difficult).
!      The pass is located in ‘tree-vrp.cc’ and is described by
!      ‘pass_vrp’.
  
!    • Folding built-in functions
  
       This pass simplifies built-in functions, as applicable, with
       constant arguments or with inferable string lengths.  It is located
!      in ‘tree-ssa-ccp.cc’ and is described by ‘pass_fold_builtins’.
  
!    • Split critical edges
  
       This pass identifies critical edges and inserts empty basic blocks
       such that the edge is no longer critical.  The pass is located in
!      ‘tree-cfg.cc’ and is described by ‘pass_split_crit_edges’.
  
!    • Control dependence dead code elimination
  
       This pass is a stronger form of dead code elimination that can
       eliminate unnecessary control flow statements.  It is located in
!      ‘tree-ssa-dce.cc’ and is described by ‘pass_cd_dce’.
  
!    • Tail call elimination
  
       This pass identifies function calls that may be rewritten into
       jumps.  No code transformation is actually applied here, but the
       data and control flow problem is solved.  The code transformation
       requires target support, and so is delayed until RTL.  In the
!      meantime ‘CALL_EXPR_TAILCALL’ is set indicating the possibility.
!      The pass is located in ‘tree-tailcall.cc’ and is described by
!      ‘pass_tail_calls’.  The RTL transformation is handled by
!      ‘fixup_tail_calls’ in ‘calls.cc’.
  
!    • Warn for function return without value
  
       For non-void functions, this pass locates return statements that do
       not specify a value and issues a warning.  Such a statement may
       have been injected by falling off the end of the function.  This
       pass is run last so that we have as much time as possible to prove
       that the statement is not reachable.  It is located in
!      ‘tree-cfg.cc’ and is described by ‘pass_warn_function_return’.
  
!    • Leave static single assignment form
  
       This pass rewrites the function such that it is in normal form.  At
       the same time, we eliminate as many single-use temporaries as
       possible, so the intermediate language is no longer GIMPLE, but
!      GENERIC.  The pass is located in ‘tree-outof-ssa.cc’ and is
!      described by ‘pass_del_ssa’.
  
!    • Merge PHI nodes that feed into one another
  
       This is part of the CFG cleanup passes.  It attempts to join PHI
       nodes from a forwarder CFG block into another block with PHI nodes.
!      The pass is located in ‘tree-cfgcleanup.cc’ and is described by
!      ‘pass_merge_phi’.
  
!    • Return value optimization
  
       If a function always returns the same local variable, and that
       local variable is an aggregate type, then the variable is replaced
       with the return value for the function (i.e., the function's
       DECL_RESULT). This is equivalent to the C++ named return value
       optimization applied to GIMPLE.  The pass is located in
!      ‘tree-nrv.cc’ and is described by ‘pass_nrv’.
  
!    • Return slot optimization
  
!      If a function returns a memory object and is called as ‘var =
!      foo()’, this pass tries to change the call so that the address of
!      ‘var’ is sent to the caller to avoid an extra memory copy.  This
!      pass is located in ‘tree-nrv.cc’ and is described by
!      ‘pass_return_slot’.
  
!    • Optimize calls to ‘__builtin_object_size’ or
!      ‘__builtin_dynamic_object_size’
  
       This is a propagation pass similar to CCP that tries to remove
!      calls to ‘__builtin_object_size’ when the upper or lower bound for
       the size of the object can be computed at compile-time.  It also
!      tries to replace calls to ‘__builtin_dynamic_object_size’ with an
       expression that evaluates the upper or lower bound for the size of
!      the object.  This pass is located in ‘tree-object-size.cc’ and is
!      described by ‘pass_object_sizes’.
  
!    • Loop invariant motion
  
       This pass removes expensive loop-invariant computations out of
!      loops.  The pass is located in ‘tree-ssa-loop.cc’ and described by
!      ‘pass_lim’.
  
!    • Loop nest optimizations
  
       This is a family of loop transformations that works on loop nests.
       It includes loop interchange, scaling, skewing and reversal and
       they are all geared to the optimization of data locality in array
       traversals and the removal of dependencies that hamper
       optimizations such as loop parallelization and vectorization.  The
!      pass is located in ‘tree-loop-linear.c’ and described by
!      ‘pass_linear_transform’.
  
!    • Removal of empty loops
  
       This pass removes loops with no code in them.  The pass is located
!      in ‘tree-ssa-loop-ivcanon.cc’ and described by ‘pass_empty_loop’.
  
!    • Unrolling of small loops
  
       This pass completely unrolls loops with few iterations.  The pass
!      is located in ‘tree-ssa-loop-ivcanon.cc’ and described by
!      ‘pass_complete_unroll’.
  
!    • Predictive commoning
  
       This pass makes the code reuse the computations from the previous
       iterations of the loops, especially loads and stores to memory.  It
*************** run after gimplification and what source
*** 8613,8644 ****
       the need for this rotation, the loop is then unrolled and the
       copies of the loop body are rewritten to use the appropriate
       version of the temporary variable.  This pass is located in
!      'tree-predcom.cc' and described by 'pass_predcom'.
  
!    * Array prefetching
  
       This pass issues prefetch instructions for array references inside
!      loops.  The pass is located in 'tree-ssa-loop-prefetch.cc' and
!      described by 'pass_loop_prefetch'.
  
!    * Reassociation
  
       This pass rewrites arithmetic expressions to enable optimizations
       that operate on them, like redundancy elimination and
!      vectorization.  The pass is located in 'tree-ssa-reassoc.cc' and
!      described by 'pass_reassoc'.
  
!    * Optimization of 'stdarg' functions
  
       This pass tries to avoid the saving of register arguments into the
!      stack on entry to 'stdarg' functions.  If the function doesn't use
!      any 'va_start' macros, no registers need to be saved.  If
!      'va_start' macros are used, the 'va_list' variables don't escape
       the function, it is only necessary to save registers that will be
!      used in 'va_arg' macros.  For instance, if 'va_arg' is only used
       with integral types in the function, floating point registers don't
!      need to be saved.  This pass is located in 'tree-stdarg.cc' and
!      described by 'pass_stdarg'.
  
  
  File: gccint.info,  Node: RTL passes,  Next: Optimization info,  Prev: Tree SSA passes,  Up: Passes
--- 8613,8644 ----
       the need for this rotation, the loop is then unrolled and the
       copies of the loop body are rewritten to use the appropriate
       version of the temporary variable.  This pass is located in
!      ‘tree-predcom.cc’ and described by ‘pass_predcom’.
  
!    • Array prefetching
  
       This pass issues prefetch instructions for array references inside
!      loops.  The pass is located in ‘tree-ssa-loop-prefetch.cc’ and
!      described by ‘pass_loop_prefetch’.
  
!    • Reassociation
  
       This pass rewrites arithmetic expressions to enable optimizations
       that operate on them, like redundancy elimination and
!      vectorization.  The pass is located in ‘tree-ssa-reassoc.cc’ and
!      described by ‘pass_reassoc’.
  
!    • Optimization of ‘stdarg’ functions
  
       This pass tries to avoid the saving of register arguments into the
!      stack on entry to ‘stdarg’ functions.  If the function doesn't use
!      any ‘va_start’ macros, no registers need to be saved.  If
!      ‘va_start’ macros are used, the ‘va_list’ variables don't escape
       the function, it is only necessary to save registers that will be
!      used in ‘va_arg’ macros.  For instance, if ‘va_arg’ is only used
       with integral types in the function, floating point registers don't
!      need to be saved.  This pass is located in ‘tree-stdarg.cc’ and
!      described by ‘pass_stdarg’.
  
  
  File: gccint.info,  Node: RTL passes,  Next: Optimization info,  Prev: Tree SSA passes,  Up: Passes
*************** File: gccint.info,  Node: RTL passes,  N
*** 8649,8701 ****
  The following briefly describes the RTL generation and optimization
  passes that are run after the Tree optimization passes.
  
!    * RTL generation
  
!      The source files for RTL generation include 'stmt.cc', 'calls.cc',
!      'expr.cc', 'explow.cc', 'expmed.cc', 'function.cc', 'optabs.cc' and
!      'emit-rtl.cc'.  Also, the file 'insn-emit.cc', generated from the
!      machine description by the program 'genemit', is used in this pass.
!      The header file 'expr.h' is used for communication within this
       pass.
  
!      The header files 'insn-flags.h' and 'insn-codes.h', generated from
!      the machine description by the programs 'genflags' and 'gencodes',
       tell this pass which standard names are available for use and which
       patterns correspond to them.
  
!    * Generation of exception landing pads
  
       This pass generates the glue that handles communication between the
       exception handling library routines and the exception handlers
       within the function.  Entry points in the function that are invoked
!      by the exception handling library are called "landing pads".  The
!      code for this pass is located in 'except.cc'.
  
!    * Control flow graph cleanup
  
       This pass removes unreachable code, simplifies jumps to next, jumps
       to jump, jumps across jumps, etc.  The pass is run multiple times.
       For historical reasons, it is occasionally referred to as the "jump
       optimization pass".  The bulk of the code for this pass is in
!      'cfgcleanup.cc', and there are support routines in 'cfgrtl.cc' and
!      'jump.cc'.
  
!    * Forward propagation of single-def values
  
       This pass attempts to remove redundant computation by substituting
       variables that come from a single definition, and seeing if the
       result can be simplified.  It performs copy propagation and
       addressing mode selection.  The pass is run twice, with values
       being propagated into loops only on the second run.  The code is
!      located in 'fwprop.cc'.
  
!    * Common subexpression elimination
  
       This pass removes redundant computation within basic blocks, and
       optimizes addressing modes based on cost.  The pass is run twice.
!      The code for this pass is located in 'cse.cc'.
  
!    * Global common subexpression elimination
  
       This pass performs two different types of GCSE depending on whether
       you are optimizing for size or not (LCM based GCSE tends to
--- 8649,8701 ----
  The following briefly describes the RTL generation and optimization
  passes that are run after the Tree optimization passes.
  
!    • RTL generation
  
!      The source files for RTL generation include ‘stmt.cc’, ‘calls.cc’,
!      ‘expr.cc’, ‘explow.cc’, ‘expmed.cc’, ‘function.cc’, ‘optabs.cc’ and
!      ‘emit-rtl.cc’.  Also, the file ‘insn-emit.cc’, generated from the
!      machine description by the program ‘genemit’, is used in this pass.
!      The header file ‘expr.h’ is used for communication within this
       pass.
  
!      The header files ‘insn-flags.h’ and ‘insn-codes.h’, generated from
!      the machine description by the programs ‘genflags’ and ‘gencodes’,
       tell this pass which standard names are available for use and which
       patterns correspond to them.
  
!    • Generation of exception landing pads
  
       This pass generates the glue that handles communication between the
       exception handling library routines and the exception handlers
       within the function.  Entry points in the function that are invoked
!      by the exception handling library are called “landing pads”.  The
!      code for this pass is located in ‘except.cc’.
  
!    • Control flow graph cleanup
  
       This pass removes unreachable code, simplifies jumps to next, jumps
       to jump, jumps across jumps, etc.  The pass is run multiple times.
       For historical reasons, it is occasionally referred to as the "jump
       optimization pass".  The bulk of the code for this pass is in
!      ‘cfgcleanup.cc’, and there are support routines in ‘cfgrtl.cc’ and
!      ‘jump.cc’.
  
!    • Forward propagation of single-def values
  
       This pass attempts to remove redundant computation by substituting
       variables that come from a single definition, and seeing if the
       result can be simplified.  It performs copy propagation and
       addressing mode selection.  The pass is run twice, with values
       being propagated into loops only on the second run.  The code is
!      located in ‘fwprop.cc’.
  
!    • Common subexpression elimination
  
       This pass removes redundant computation within basic blocks, and
       optimizes addressing modes based on cost.  The pass is run twice.
!      The code for this pass is located in ‘cse.cc’.
  
!    • Global common subexpression elimination
  
       This pass performs two different types of GCSE depending on whether
       you are optimizing for size or not (LCM based GCSE tends to
*************** passes that are run after the Tree optim
*** 8711,8777 ****
       perform load and store motion when optimizing for speed.
       Regardless of which type of GCSE is used, the GCSE pass also
       performs global constant and copy propagation.  The source file for
!      this pass is 'gcse.cc', and the LCM routines are in 'lcm.cc'.
  
!    * Loop optimization
  
       This pass performs several loop related optimizations.  The source
!      files 'cfgloopanal.cc' and 'cfgloopmanip.cc' contain generic loop
       analysis and manipulation code.  Initialization and finalization of
!      loop structures is handled by 'loop-init.cc'.  A loop invariant
!      motion pass is implemented in 'loop-invariant.cc'.  Basic block
       level optimizations--unrolling, and peeling loops-- are implemented
!      in 'loop-unroll.cc'.  Replacing of the exit condition of loops by
       special machine-dependent instructions is handled by
!      'loop-doloop.cc'.
  
!    * Jump bypassing
  
       This pass is an aggressive form of GCSE that transforms the control
       flow graph of a function by propagating constants into conditional
!      branch instructions.  The source file for this pass is 'gcse.cc'.
  
!    * If conversion
  
       This pass attempts to replace conditional branches and surrounding
       assignments with arithmetic, boolean value producing comparison
       instructions, and conditional move instructions.  In the very last
       invocation after reload/LRA, it will generate predicated
       instructions when supported by the target.  The code is located in
!      'ifcvt.cc'.
  
!    * Web construction
  
       This pass splits independent uses of each pseudo-register.  This
       can improve effect of the other transformation, such as CSE or
       register allocation.  The code for this pass is located in
!      'web.cc'.
  
!    * Instruction combination
  
       This pass attempts to combine groups of two or three instructions
       that are related by data flow into single instructions.  It
       combines the RTL expressions for the instructions by substitution,
       simplifies the result using algebra, and then attempts to match the
       result against the machine description.  The code is located in
!      'combine.cc'.
  
!    * Mode switching optimization
  
       This pass looks for instructions that require the processor to be
       in a specific "mode" and minimizes the number of mode changes
       required to satisfy all users.  What these modes are, and what they
       apply to are completely target-specific.  The code for this pass is
!      located in 'mode-switching.cc'.
  
!    * Modulo scheduling
  
       This pass looks at innermost loops and reorders their instructions
       by overlapping different iterations.  Modulo scheduling is
       performed immediately before instruction scheduling.  The code for
!      this pass is located in 'modulo-sched.cc'.
  
!    * Instruction scheduling
  
       This pass looks for instructions whose output will not be available
       by the time that it is used in subsequent instructions.  Memory
--- 8711,8777 ----
       perform load and store motion when optimizing for speed.
       Regardless of which type of GCSE is used, the GCSE pass also
       performs global constant and copy propagation.  The source file for
!      this pass is ‘gcse.cc’, and the LCM routines are in ‘lcm.cc’.
  
!    • Loop optimization
  
       This pass performs several loop related optimizations.  The source
!      files ‘cfgloopanal.cc’ and ‘cfgloopmanip.cc’ contain generic loop
       analysis and manipulation code.  Initialization and finalization of
!      loop structures is handled by ‘loop-init.cc’.  A loop invariant
!      motion pass is implemented in ‘loop-invariant.cc’.  Basic block
       level optimizations--unrolling, and peeling loops-- are implemented
!      in ‘loop-unroll.cc’.  Replacing of the exit condition of loops by
       special machine-dependent instructions is handled by
!      ‘loop-doloop.cc’.
  
!    • Jump bypassing
  
       This pass is an aggressive form of GCSE that transforms the control
       flow graph of a function by propagating constants into conditional
!      branch instructions.  The source file for this pass is ‘gcse.cc’.
  
!    • If conversion
  
       This pass attempts to replace conditional branches and surrounding
       assignments with arithmetic, boolean value producing comparison
       instructions, and conditional move instructions.  In the very last
       invocation after reload/LRA, it will generate predicated
       instructions when supported by the target.  The code is located in
!      ‘ifcvt.cc’.
  
!    • Web construction
  
       This pass splits independent uses of each pseudo-register.  This
       can improve effect of the other transformation, such as CSE or
       register allocation.  The code for this pass is located in
!      ‘web.cc’.
  
!    • Instruction combination
  
       This pass attempts to combine groups of two or three instructions
       that are related by data flow into single instructions.  It
       combines the RTL expressions for the instructions by substitution,
       simplifies the result using algebra, and then attempts to match the
       result against the machine description.  The code is located in
!      ‘combine.cc’.
  
!    • Mode switching optimization
  
       This pass looks for instructions that require the processor to be
       in a specific "mode" and minimizes the number of mode changes
       required to satisfy all users.  What these modes are, and what they
       apply to are completely target-specific.  The code for this pass is
!      located in ‘mode-switching.cc’.
  
!    • Modulo scheduling
  
       This pass looks at innermost loops and reorders their instructions
       by overlapping different iterations.  Modulo scheduling is
       performed immediately before instruction scheduling.  The code for
!      this pass is located in ‘modulo-sched.cc’.
  
!    • Instruction scheduling
  
       This pass looks for instructions whose output will not be available
       by the time that it is used in subsequent instructions.  Memory
*************** passes that are run after the Tree optim
*** 8780,8796 ****
       try to separate the definition and use of items that otherwise
       would cause pipeline stalls.  This pass is performed twice, before
       and after register allocation.  The code for this pass is located
!      in 'haifa-sched.cc', 'sched-deps.cc', 'sched-ebb.cc',
!      'sched-rgn.cc' and 'sched-vis.c'.
  
!    * Register allocation
  
       These passes make sure that all occurrences of pseudo registers are
       eliminated, either by allocating them to a hard register, replacing
       them by an equivalent expression (e.g. a constant) or by placing
       them on the stack.  This is done in several subpasses:
  
!         * The integrated register allocator (IRA).  It is called
            integrated because coalescing, register live range splitting,
            and hard register preferencing are done on-the-fly during
            coloring.  It also has better integration with the reload/LRA
--- 8780,8796 ----
       try to separate the definition and use of items that otherwise
       would cause pipeline stalls.  This pass is performed twice, before
       and after register allocation.  The code for this pass is located
!      in ‘haifa-sched.cc’, ‘sched-deps.cc’, ‘sched-ebb.cc’,
!      ‘sched-rgn.cc’ and ‘sched-vis.c’.
  
!    • Register allocation
  
       These passes make sure that all occurrences of pseudo registers are
       eliminated, either by allocating them to a hard register, replacing
       them by an equivalent expression (e.g. a constant) or by placing
       them on the stack.  This is done in several subpasses:
  
!         • The integrated register allocator (IRA).  It is called
            integrated because coalescing, register live range splitting,
            and hard register preferencing are done on-the-fly during
            coloring.  It also has better integration with the reload/LRA
*************** passes that are run after the Tree optim
*** 8805,8817 ****
            regions using register pressure but the user can force it to
            use one region or regions corresponding to all loops.
  
!           Source files of the allocator are 'ira.cc', 'ira-build.cc',
!           'ira-costs.cc', 'ira-conflicts.cc', 'ira-color.cc',
!           'ira-emit.cc', 'ira-lives', plus header files 'ira.h' and
!           'ira-int.h' used for the communication between the allocator
            and the rest of the compiler and between the IRA files.
  
!         * Reloading.  This pass renumbers pseudo registers with the
            hardware registers numbers they were allocated.  Pseudo
            registers that did not get hard registers are replaced with
            stack slots.  Then it finds instructions that are invalid
--- 8805,8817 ----
            regions using register pressure but the user can force it to
            use one region or regions corresponding to all loops.
  
!           Source files of the allocator are ‘ira.cc’, ‘ira-build.cc’,
!           ‘ira-costs.cc’, ‘ira-conflicts.cc’, ‘ira-color.cc’,
!           ‘ira-emit.cc’, ‘ira-lives’, plus header files ‘ira.h’ and
!           ‘ira-int.h’ used for the communication between the allocator
            and the rest of the compiler and between the IRA files.
  
!         • Reloading.  This pass renumbers pseudo registers with the
            hardware registers numbers they were allocated.  Pseudo
            registers that did not get hard registers are replaced with
            stack slots.  Then it finds instructions that are invalid
*************** passes that are run after the Tree optim
*** 8825,8838 ****
            and inserts instructions to save and restore call-clobbered
            registers around calls.
  
!           Source files are 'reload.cc' and 'reload1.cc', plus the header
!           'reload.h' used for communication between them.
  
!         * This pass is a modern replacement of the reload pass.  Source
!           files are 'lra.cc', 'lra-assign.c', 'lra-coalesce.cc',
!           'lra-constraints.cc', 'lra-eliminations.cc', 'lra-lives.cc',
!           'lra-remat.cc', 'lra-spills.cc', the header 'lra-int.h' used
!           for communication between them, and the header 'lra.h' used
            for communication between LRA and the rest of compiler.
  
            Unlike the reload pass, intermediate LRA decisions are
--- 8825,8838 ----
            and inserts instructions to save and restore call-clobbered
            registers around calls.
  
!           Source files are ‘reload.cc’ and ‘reload1.cc’, plus the header
!           ‘reload.h’ used for communication between them.
  
!         • This pass is a modern replacement of the reload pass.  Source
!           files are ‘lra.cc’, ‘lra-assign.c’, ‘lra-coalesce.cc’,
!           ‘lra-constraints.cc’, ‘lra-eliminations.cc’, ‘lra-lives.cc’,
!           ‘lra-remat.cc’, ‘lra-spills.cc’, the header ‘lra-int.h’ used
!           for communication between them, and the header ‘lra.h’ used
            for communication between LRA and the rest of compiler.
  
            Unlike the reload pass, intermediate LRA decisions are
*************** passes that are run after the Tree optim
*** 8842,8871 ****
  
            LRA is run on targets for which TARGET_LRA_P returns true.
  
!    * Basic block reordering
  
       This pass implements profile guided code positioning.  If profile
       information is not available, various types of static analysis are
       performed to make the predictions normally coming from the profile
       feedback (IE execution frequency, branch probability, etc).  It is
!      implemented in the file 'bb-reorder.cc', and the various prediction
!      routines are in 'predict.cc'.
  
!    * Variable tracking
  
       This pass computes where the variables are stored at each position
       in code and generates notes describing the variable locations to
       RTL code.  The location lists are then generated according to these
       notes to debug information if the debugging information format
!      supports location lists.  The code is located in 'var-tracking.cc'.
  
!    * Delayed branch scheduling
  
       This optional pass attempts to find instructions that can go into
       the delay slots of other instructions, usually jumps and calls.
!      The code for this pass is located in 'reorg.cc'.
  
!    * Branch shortening
  
       On many RISC machines, branch instructions have a limited range.
       Thus, longer sequences of instructions must be used for long
--- 8842,8871 ----
  
            LRA is run on targets for which TARGET_LRA_P returns true.
  
!    • Basic block reordering
  
       This pass implements profile guided code positioning.  If profile
       information is not available, various types of static analysis are
       performed to make the predictions normally coming from the profile
       feedback (IE execution frequency, branch probability, etc).  It is
!      implemented in the file ‘bb-reorder.cc’, and the various prediction
!      routines are in ‘predict.cc’.
  
!    • Variable tracking
  
       This pass computes where the variables are stored at each position
       in code and generates notes describing the variable locations to
       RTL code.  The location lists are then generated according to these
       notes to debug information if the debugging information format
!      supports location lists.  The code is located in ‘var-tracking.cc’.
  
!    • Delayed branch scheduling
  
       This optional pass attempts to find instructions that can go into
       the delay slots of other instructions, usually jumps and calls.
!      The code for this pass is located in ‘reorg.cc’.
  
!    • Branch shortening
  
       On many RISC machines, branch instructions have a limited range.
       Thus, longer sequences of instructions must be used for long
*************** passes that are run after the Tree optim
*** 8873,8902 ****
       instruction will be from each other instruction, and therefore
       whether the usual instructions, or the longer sequences, must be
       used for each branch.  The code for this pass is located in
!      'final.cc'.
  
!    * Register-to-stack conversion
  
       Conversion from usage of some hard registers to usage of a register
       stack may be done at this point.  Currently, this is supported only
       for the floating-point registers of the Intel 80387 coprocessor.
!      The code for this pass is located in 'reg-stack.cc'.
  
!    * Final
  
       This pass outputs the assembler code for the function.  The source
!      files are 'final.cc' plus 'insn-output.cc'; the latter is generated
!      automatically from the machine description by the tool 'genoutput'.
!      The header file 'conditions.h' is used for communication between
       these files.
  
!    * Debugging information output
  
       This is run after final because it must output the stack slot
       offsets for pseudo registers that did not get hard registers.
!      Source files are 'dwarfout.c' for DWARF symbol table format, files
!      'dwarf2out.cc' and 'dwarf2asm.cc' for DWARF2 symbol table format,
!      and 'vmsdbgout.cc' for VMS debug symbol table format.
  
  
  File: gccint.info,  Node: Optimization info,  Prev: RTL passes,  Up: Passes
--- 8873,8902 ----
       instruction will be from each other instruction, and therefore
       whether the usual instructions, or the longer sequences, must be
       used for each branch.  The code for this pass is located in
!      ‘final.cc’.
  
!    • Register-to-stack conversion
  
       Conversion from usage of some hard registers to usage of a register
       stack may be done at this point.  Currently, this is supported only
       for the floating-point registers of the Intel 80387 coprocessor.
!      The code for this pass is located in ‘reg-stack.cc’.
  
!    • Final
  
       This pass outputs the assembler code for the function.  The source
!      files are ‘final.cc’ plus ‘insn-output.cc’; the latter is generated
!      automatically from the machine description by the tool ‘genoutput’.
!      The header file ‘conditions.h’ is used for communication between
       these files.
  
!    • Debugging information output
  
       This is run after final because it must output the stack slot
       offsets for pseudo registers that did not get hard registers.
!      Source files are ‘dwarfout.c’ for DWARF symbol table format, files
!      ‘dwarf2out.cc’ and ‘dwarf2asm.cc’ for DWARF2 symbol table format,
!      and ‘vmsdbgout.cc’ for VMS debug symbol table format.
  
  
  File: gccint.info,  Node: Optimization info,  Prev: RTL passes,  Up: Passes
*************** File: gccint.info,  Node: Dump setup,  N
*** 8924,8947 ****
  9.7.1 Dump setup
  ----------------
  
! A dump_manager class is defined in 'dumpfile.h'.  Various passes
! register dumping pass-specific information via 'dump_register' in
! 'passes.cc'.  During the registration, an optimization pass can select
  its optimization group (*note Optimization groups::).  After that
  optimization information corresponding to the entire group (presumably
  from multiple passes) can be output via command-line switches.  Note
  that if a pass does not fit into any of the pre-defined groups, it can
! select 'OPTGROUP_NONE'.
  
   Note that in general, a pass need not know its dump output file name,
  whether certain flags are enabled, etc.  However, for legacy reasons,
! passes could also call 'dump_begin' which returns a stream in case the
  particular pass has optimization dumps enabled.  A pass could call
! 'dump_end' when the dump has ended.  These methods should go away once
  all the passes are converted to use the new dump infrastructure.
  
!  The recommended way to setup the dump output is via 'dump_start' and
! 'dump_end'.
  
  
  File: gccint.info,  Node: Optimization groups,  Next: Dump files and streams,  Prev: Dump setup,  Up: Optimization info
--- 8924,8947 ----
  9.7.1 Dump setup
  ----------------
  
! A dump_manager class is defined in ‘dumpfile.h’.  Various passes
! register dumping pass-specific information via ‘dump_register’ in
! ‘passes.cc’.  During the registration, an optimization pass can select
  its optimization group (*note Optimization groups::).  After that
  optimization information corresponding to the entire group (presumably
  from multiple passes) can be output via command-line switches.  Note
  that if a pass does not fit into any of the pre-defined groups, it can
! select ‘OPTGROUP_NONE’.
  
   Note that in general, a pass need not know its dump output file name,
  whether certain flags are enabled, etc.  However, for legacy reasons,
! passes could also call ‘dump_begin’ which returns a stream in case the
  particular pass has optimization dumps enabled.  A pass could call
! ‘dump_end’ when the dump has ended.  These methods should go away once
  all the passes are converted to use the new dump infrastructure.
  
!  The recommended way to setup the dump output is via ‘dump_start’ and
! ‘dump_end’.
  
  
  File: gccint.info,  Node: Optimization groups,  Next: Dump files and streams,  Prev: Dump setup,  Up: Optimization info
*************** File: gccint.info,  Node: Optimization g
*** 8950,8978 ****
  -------------------------
  
  The optimization passes are grouped into several categories.  Currently
! defined categories in 'dumpfile.h' are
  
! 'OPTGROUP_IPA'
!      IPA optimization passes.  Enabled by '-ipa'
  
! 'OPTGROUP_LOOP'
!      Loop optimization passes.  Enabled by '-loop'.
  
! 'OPTGROUP_INLINE'
!      Inlining passes.  Enabled by '-inline'.
  
! 'OPTGROUP_OMP'
!      OMP (Offloading and Multi Processing) passes.  Enabled by '-omp'.
  
! 'OPTGROUP_VEC'
!      Vectorization passes.  Enabled by '-vec'.
  
! 'OPTGROUP_OTHER'
       All other optimization passes which do not fall into one of the
       above.
  
! 'OPTGROUP_ALL'
!      All optimization passes.  Enabled by '-optall'.
  
   By using groups a user could selectively enable optimization
  information only for a group of passes.  By default, the optimization
--- 8950,8978 ----
  -------------------------
  
  The optimization passes are grouped into several categories.  Currently
! defined categories in ‘dumpfile.h’ are
  
! ‘OPTGROUP_IPA’
!      IPA optimization passes.  Enabled by ‘-ipa’
  
! ‘OPTGROUP_LOOP’
!      Loop optimization passes.  Enabled by ‘-loop’.
  
! ‘OPTGROUP_INLINE’
!      Inlining passes.  Enabled by ‘-inline’.
  
! ‘OPTGROUP_OMP’
!      OMP (Offloading and Multi Processing) passes.  Enabled by ‘-omp’.
  
! ‘OPTGROUP_VEC’
!      Vectorization passes.  Enabled by ‘-vec’.
  
! ‘OPTGROUP_OTHER’
       All other optimization passes which do not fall into one of the
       above.
  
! ‘OPTGROUP_ALL’
!      All optimization passes.  Enabled by ‘-optall’.
  
   By using groups a user could selectively enable optimization
  information only for a group of passes.  By default, the optimization
*************** File: gccint.info,  Node: Dump files and
*** 8986,9009 ****
  
  There are two separate output streams available for outputting
  optimization information from passes.  Note that both these streams
! accept 'stderr' and 'stdout' as valid streams and thus it is possible to
  dump output to standard output or error.  This is specially handy for
  outputting all available information in a single file by redirecting
! 'stderr'.
  
! 'pstream'
       This stream is for pass-specific dump output.  For example,
!      '-fdump-tree-vect=foo.v' dumps tree vectorization pass output into
!      the given file name 'foo.v'.  If the file name is not provided, the
       default file name is based on the source file and pass number.
!      Note that one could also use special file names 'stdout' and
!      'stderr' for dumping to standard output and standard error
       respectively.
  
! 'alt_stream'
       This steam is used for printing optimization specific output in
!      response to the '-fopt-info'.  Again a file name can be given.  If
!      the file name is not given, it defaults to 'stderr'.
  
  
  File: gccint.info,  Node: Dump output verbosity,  Next: Dump types,  Prev: Dump files and streams,  Up: Optimization info
--- 8986,9009 ----
  
  There are two separate output streams available for outputting
  optimization information from passes.  Note that both these streams
! accept ‘stderr’ and ‘stdout’ as valid streams and thus it is possible to
  dump output to standard output or error.  This is specially handy for
  outputting all available information in a single file by redirecting
! ‘stderr’.
  
! ‘pstream’
       This stream is for pass-specific dump output.  For example,
!      ‘-fdump-tree-vect=foo.v’ dumps tree vectorization pass output into
!      the given file name ‘foo.v’.  If the file name is not provided, the
       default file name is based on the source file and pass number.
!      Note that one could also use special file names ‘stdout’ and
!      ‘stderr’ for dumping to standard output and standard error
       respectively.
  
! ‘alt_stream’
       This steam is used for printing optimization specific output in
!      response to the ‘-fopt-info’.  Again a file name can be given.  If
!      the file name is not given, it defaults to ‘stderr’.
  
  
  File: gccint.info,  Node: Dump output verbosity,  Next: Dump types,  Prev: Dump files and streams,  Up: Optimization info
*************** File: gccint.info,  Node: Dump output ve
*** 9013,9025 ****
  
  The dump verbosity has the following options
  
! 'optimized'
       Print information when an optimization is successfully applied.  It
       is up to a pass to decide which information is relevant.  For
       example, the vectorizer passes print the source location of loops
       which got successfully vectorized.
  
! 'missed'
       Print information about missed optimizations.  Individual passes
       control which information to include in the output.  For example,
  
--- 9013,9025 ----
  
  The dump verbosity has the following options
  
! ‘optimized’
       Print information when an optimization is successfully applied.  It
       is up to a pass to decide which information is relevant.  For
       example, the vectorizer passes print the source location of loops
       which got successfully vectorized.
  
! ‘missed’
       Print information about missed optimizations.  Individual passes
       control which information to include in the output.  For example,
  
*************** The dump verbosity has the following opt
*** 9028,9038 ****
       will print information about missed optimization opportunities from
       vectorization passes on stderr.
  
! 'note'
       Print verbose information about optimizations, such as certain
       transformations, more detailed messages about decisions etc.
  
! 'all'
       Print detailed optimization information.  This includes OPTIMIZED,
       MISSED, and NOTE.
  
--- 9028,9038 ----
       will print information about missed optimization opportunities from
       vectorization passes on stderr.
  
! ‘note’
       Print verbose information about optimizations, such as certain
       transformations, more detailed messages about decisions etc.
  
! ‘all’
       Print detailed optimization information.  This includes OPTIMIZED,
       MISSED, and NOTE.
  
*************** File: gccint.info,  Node: Dump types,  N
*** 9042,9092 ****
  9.7.5 Dump types
  ----------------
  
! 'dump_printf'
  
       This is a generic method for doing formatted output.  It takes an
!      additional argument 'dump_kind' which signifies the type of dump.
       This method outputs information only when the dumps are enabled for
!      this particular 'dump_kind'.  Note that the caller doesn't need to
       know if the particular dump is enabled or not, or even the file
       name.  The caller only needs to decide which dump output
       information is relevant, and under what conditions.  This
       determines the associated flags.
  
!      Consider the following example from 'loop-unroll.cc' where an
       informative message about a loop (along with its location) is
       printed when any of the following flags is enabled
  
!         - optimization messages
!         - RTL dumps
!         - detailed dumps
  
            int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS;
            dump_printf_loc (report_flags, insn,
                             "loop turned into non-loop; it never loops.\n");
  
! 'dump_basic_block'
       Output basic block.
! 'dump_generic_expr'
       Output generic expression.
! 'dump_gimple_stmt'
       Output gimple statement.
  
       Note that the above methods also have variants prefixed with
!      '_loc', such as 'dump_printf_loc', which are similar except they
!      also output the source location information.  The '_loc' variants
!      take a 'const dump_location_t &'.  This class can be constructed
!      from a 'gimple *' or from a 'rtx_insn *', and so callers can pass a
!      'gimple *' or a 'rtx_insn *' as the '_loc' argument.  The
!      'dump_location_t' constructor will extract the source location from
       the statement or instruction, along with the profile count, and the
       location in GCC's own source code (or the plugin) from which the
       dump call was emitted.  Only the source location is currently used.
!      There is also a 'dump_user_location_t' class, capturing the source
       location and profile count, but not the dump emission location, so
       that locations in the user's code can be passed around.  This can
!      also be constructed from a 'gimple *' and from a 'rtx_insn *', and
!      it too can be passed as the '_loc' argument.
  
  
  File: gccint.info,  Node: Dump examples,  Prev: Dump types,  Up: Optimization info
--- 9042,9092 ----
  9.7.5 Dump types
  ----------------
  
! ‘dump_printf’
  
       This is a generic method for doing formatted output.  It takes an
!      additional argument ‘dump_kind’ which signifies the type of dump.
       This method outputs information only when the dumps are enabled for
!      this particular ‘dump_kind’.  Note that the caller doesn't need to
       know if the particular dump is enabled or not, or even the file
       name.  The caller only needs to decide which dump output
       information is relevant, and under what conditions.  This
       determines the associated flags.
  
!      Consider the following example from ‘loop-unroll.cc’ where an
       informative message about a loop (along with its location) is
       printed when any of the following flags is enabled
  
!         − optimization messages
!         − RTL dumps
!         − detailed dumps
  
            int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS;
            dump_printf_loc (report_flags, insn,
                             "loop turned into non-loop; it never loops.\n");
  
! ‘dump_basic_block’
       Output basic block.
! ‘dump_generic_expr’
       Output generic expression.
! ‘dump_gimple_stmt’
       Output gimple statement.
  
       Note that the above methods also have variants prefixed with
!      ‘_loc’, such as ‘dump_printf_loc’, which are similar except they
!      also output the source location information.  The ‘_loc’ variants
!      take a ‘const dump_location_t &’.  This class can be constructed
!      from a ‘gimple *’ or from a ‘rtx_insn *’, and so callers can pass a
!      ‘gimple *’ or a ‘rtx_insn *’ as the ‘_loc’ argument.  The
!      ‘dump_location_t’ constructor will extract the source location from
       the statement or instruction, along with the profile count, and the
       location in GCC's own source code (or the plugin) from which the
       dump call was emitted.  Only the source location is currently used.
!      There is also a ‘dump_user_location_t’ class, capturing the source
       location and profile count, but not the dump emission location, so
       that locations in the user's code can be passed around.  This can
!      also be constructed from a ‘gimple *’ and from a ‘rtx_insn *’, and
!      it too can be passed as the ‘_loc’ argument.
  
  
  File: gccint.info,  Node: Dump examples,  Prev: Dump types,  Up: Optimization info
*************** File: gccint.info,  Node: Dump examples,
*** 9097,9131 ****
       gcc -O3 -fopt-info-missed=missed.all
  
   outputs missed optimization report from all the passes into
! 'missed.all'.
  
   As another example,
       gcc -O3 -fopt-info-inline-optimized-missed=inline.txt
  
   will output information about missed optimizations as well as optimized
! locations from all the inlining passes into 'inline.txt'.
  
   If the FILENAME is provided, then the dumps from all the applicable
! optimizations are concatenated into the 'filename'.  Otherwise the dump
! is output onto 'stderr'.  If OPTIONS is omitted, it defaults to
! 'optimized-optall', which means dump all information about successful
  optimizations from all the passes.  In the following example, the
! optimization information is output on to 'stderr'.
  
       gcc -O3 -fopt-info
  
!  Note that '-fopt-info-vec-missed' behaves the same as
! '-fopt-info-missed-vec'.  The order of the optimization group names and
! message types listed after '-fopt-info' does not matter.
  
   As another example, consider
  
       gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt
  
!  Here the two output file names 'vec.miss' and 'loop.opt' are in
  conflict since only one output file is allowed.  In this case, only the
  first option takes effect and the subsequent options are ignored.  Thus
! only the 'vec.miss' is produced which containts dumps from the
  vectorizer about missed opportunities.
  
  
--- 9097,9131 ----
       gcc -O3 -fopt-info-missed=missed.all
  
   outputs missed optimization report from all the passes into
! ‘missed.all’.
  
   As another example,
       gcc -O3 -fopt-info-inline-optimized-missed=inline.txt
  
   will output information about missed optimizations as well as optimized
! locations from all the inlining passes into ‘inline.txt’.
  
   If the FILENAME is provided, then the dumps from all the applicable
! optimizations are concatenated into the ‘filename’.  Otherwise the dump
! is output onto ‘stderr’.  If OPTIONS is omitted, it defaults to
! ‘optimized-optall’, which means dump all information about successful
  optimizations from all the passes.  In the following example, the
! optimization information is output on to ‘stderr’.
  
       gcc -O3 -fopt-info
  
!  Note that ‘-fopt-info-vec-missed’ behaves the same as
! ‘-fopt-info-missed-vec’.  The order of the optimization group names and
! message types listed after ‘-fopt-info’ does not matter.
  
   As another example, consider
  
       gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt
  
!  Here the two output file names ‘vec.miss’ and ‘loop.opt’ are in
  conflict since only one output file is allowed.  In this case, only the
  first option takes effect and the subsequent options are ignored.  Thus
! only the ‘vec.miss’ is produced which containts dumps from the
  vectorizer about missed opportunities.
  
  
*************** rather than a compile-time constant.  Th
*** 9139,9163 ****
  sizes and offsets must also be runtime invariants rather than
  compile-time constants, such as:
  
!    * the size of a general 'machine_mode' (*note Machine Modes::);
  
!    * the size of a spill slot;
  
!    * the offset of something within a stack frame;
  
!    * the number of elements in a vector;
  
!    * the size and offset of a 'mem' rtx (*note Regs and Memory::); and
  
!    * the byte offset in a 'subreg' rtx (*note Regs and Memory::).
  
   The motivating example is the Arm SVE ISA, whose vector registers can
  be any multiple of 128 bits between 128 and 2048 inclusive.  The
  compiler normally produces code that works for all SVE register sizes,
  with the actual size only being known at runtime.
  
!  GCC's main representation of such runtime invariants is the 'poly_int'
! class.  This chapter describes what 'poly_int' does, lists the available
  operations, and gives some general usage guidelines.
  
  * Menu:
--- 9139,9163 ----
  sizes and offsets must also be runtime invariants rather than
  compile-time constants, such as:
  
!    • the size of a general ‘machine_mode’ (*note Machine Modes::);
  
!    • the size of a spill slot;
  
!    • the offset of something within a stack frame;
  
!    • the number of elements in a vector;
  
!    • the size and offset of a ‘mem’ rtx (*note Regs and Memory::); and
  
!    • the byte offset in a ‘subreg’ rtx (*note Regs and Memory::).
  
   The motivating example is the Arm SVE ISA, whose vector registers can
  be any multiple of 128 bits between 128 and 2048 inclusive.  The
  compiler normally produces code that works for all SVE register sizes,
  with the actual size only being known at runtime.
  
!  GCC's main representation of such runtime invariants is the ‘poly_int’
! class.  This chapter describes what ‘poly_int’ does, lists the available
  operations, and gives some general usage guidelines.
  
  * Menu:
*************** operations, and gives some general usage
*** 9175,9181 ****
  
  File: gccint.info,  Node: Overview of poly_int,  Next: Consequences of using poly_int,  Up: poly_int
  
! 10.1 Overview of 'poly_int'
  ===========================
  
  We define indeterminates X1, ..., XN whose values are only known at
--- 9175,9181 ----
  
  File: gccint.info,  Node: Overview of poly_int,  Next: Consequences of using poly_int,  Up: poly_int
  
! 10.1 Overview of ‘poly_int’
  ===========================
  
  We define indeterminates X1, ..., XN whose values are only known at
*************** indeterminates.  The coefficients C0, ..
*** 9188,9209 ****
  compile time, with the C0 term being the "constant" part that does not
  depend on any runtime value.
  
!  GCC uses the 'poly_int' class to represent these coefficients.  The
  class has two template parameters: the first specifies the number of
  coefficients (N + 1) and the second specifies the type of the
! coefficients.  For example, 'poly_int<2, unsigned short>' represents a
  polynomial with two coefficients (and thus one indeterminate), with each
! coefficient having type 'unsigned short'.  When N is 0, the class
  degenerates to a single compile-time constant C0.
  
   The number of coefficients needed for compilation is a fixed property
  of each target and is specified by the configuration macro
! 'NUM_POLY_INT_COEFFS'.  The default value is 1, since most targets do
  not have such runtime invariants.  Targets that need a different value
! should '#define' the macro in their 'CPU-modes.def' file.  *Note Back
  End::.
  
!  'poly_int' makes the simplifying requirement that each indeterminate
  must be a nonnegative integer.  An indeterminate value of 0 should
  usually represent the minimum possible runtime value, with C0 specifying
  the value in that case.
--- 9188,9209 ----
  compile time, with the C0 term being the "constant" part that does not
  depend on any runtime value.
  
!  GCC uses the ‘poly_int’ class to represent these coefficients.  The
  class has two template parameters: the first specifies the number of
  coefficients (N + 1) and the second specifies the type of the
! coefficients.  For example, ‘poly_int<2, unsigned short>’ represents a
  polynomial with two coefficients (and thus one indeterminate), with each
! coefficient having type ‘unsigned short’.  When N is 0, the class
  degenerates to a single compile-time constant C0.
  
   The number of coefficients needed for compilation is a fixed property
  of each target and is specified by the configuration macro
! ‘NUM_POLY_INT_COEFFS’.  The default value is 1, since most targets do
  not have such runtime invariants.  Targets that need a different value
! should ‘#define’ the macro in their ‘CPU-modes.def’ file.  *Note Back
  End::.
  
!  ‘poly_int’ makes the simplifying requirement that each indeterminate
  must be a nonnegative integer.  An indeterminate value of 0 should
  usually represent the minimum possible runtime value, with C0 specifying
  the value in that case.
*************** length of 128 bits_.  Thus the number of
*** 9214,9257 ****
  is 2 + 2 * X1.  If an aggregate has a single SVE vector and 16
  additional bytes, its total size is 32 + 16 * X1 bytes.
  
!  The header file 'poly-int-types.h' provides typedefs for the most
! common forms of 'poly_int', all having 'NUM_POLY_INT_COEFFS'
  coefficients:
  
! 'poly_uint16'
!      a 'poly_int' with 'unsigned short' coefficients.
  
! 'poly_int64'
!      a 'poly_int' with 'HOST_WIDE_INT' coefficients.
  
! 'poly_uint64'
!      a 'poly_int' with 'unsigned HOST_WIDE_INT' coefficients.
  
! 'poly_offset_int'
!      a 'poly_int' with 'offset_int' coefficients.
  
! 'poly_wide_int'
!      a 'poly_int' with 'wide_int' coefficients.
  
! 'poly_widest_int'
!      a 'poly_int' with 'widest_int' coefficients.
  
!  Since the main purpose of 'poly_int' is to represent sizes and offsets,
  the last two typedefs are only rarely used.
  
  
  File: gccint.info,  Node: Consequences of using poly_int,  Next: Comparisons involving poly_int,  Prev: Overview of poly_int,  Up: poly_int
  
! 10.2 Consequences of using 'poly_int'
  =====================================
  
  The two main consequences of using polynomial sizes and offsets are
  that:
  
!    * there is no total ordering between the values at compile time, and
  
!    * some operations might yield results that cannot be expressed as a
!      'poly_int'.
  
   For example, if X is a runtime invariant, we cannot tell at compile
  time whether:
--- 9214,9257 ----
  is 2 + 2 * X1.  If an aggregate has a single SVE vector and 16
  additional bytes, its total size is 32 + 16 * X1 bytes.
  
!  The header file ‘poly-int-types.h’ provides typedefs for the most
! common forms of ‘poly_int’, all having ‘NUM_POLY_INT_COEFFS’
  coefficients:
  
! ‘poly_uint16’
!      a ‘poly_int’ with ‘unsigned short’ coefficients.
  
! ‘poly_int64’
!      a ‘poly_int’ with ‘HOST_WIDE_INT’ coefficients.
  
! ‘poly_uint64’
!      a ‘poly_int’ with ‘unsigned HOST_WIDE_INT’ coefficients.
  
! ‘poly_offset_int’
!      a ‘poly_int’ with ‘offset_int’ coefficients.
  
! ‘poly_wide_int’
!      a ‘poly_int’ with ‘wide_int’ coefficients.
  
! ‘poly_widest_int’
!      a ‘poly_int’ with ‘widest_int’ coefficients.
  
!  Since the main purpose of ‘poly_int’ is to represent sizes and offsets,
  the last two typedefs are only rarely used.
  
  
  File: gccint.info,  Node: Consequences of using poly_int,  Next: Comparisons involving poly_int,  Prev: Overview of poly_int,  Up: poly_int
  
! 10.2 Consequences of using ‘poly_int’
  =====================================
  
  The two main consequences of using polynomial sizes and offsets are
  that:
  
!    • there is no total ordering between the values at compile time, and
  
!    • some operations might yield results that cannot be expressed as a
!      ‘poly_int’.
  
   For example, if X is a runtime invariant, we cannot tell at compile
  time whether:
*************** time whether:
*** 9260,9266 ****
  
   since the condition is false when X <= 1 and true when X >= 2.
  
!  Similarly, 'poly_int' cannot represent the result of:
  
       (3 + 4X) * (1 + 5X)
  
--- 9260,9266 ----
  
   since the condition is false when X <= 1 and true when X >= 2.
  
!  Similarly, ‘poly_int’ cannot represent the result of:
  
       (3 + 4X) * (1 + 5X)
  
*************** than one.  It also cannot represent the
*** 9271,9293 ****
  
   The following sections describe how we deal with these restrictions.
  
!  As described earlier, a 'poly_int<1, T>' has no indeterminates and so
  degenerates to a compile-time constant of type T.  It would be possible
  in that case to do all normal arithmetic on the T, and to compare the T
  using the normal C++ operators.  We deliberately prevent
  target-independent code from doing this, since the compiler needs to
! support other 'poly_int' as well, regardless of the current
! target's 'NUM_POLY_INT_COEFFS'.
  
   However, it would be very artificial to force target-specific code to
  follow these restrictions if the target has no runtime indeterminates.
! There is therefore an implicit conversion from 'poly_int<1, T>' to T
  when compiling target-specific translation units.
  
  
  File: gccint.info,  Node: Comparisons involving poly_int,  Next: Arithmetic on poly_ints,  Prev: Consequences of using poly_int,  Up: poly_int
  
! 10.3 Comparisons involving 'poly_int'
  =====================================
  
  In general we need to compare sizes and offsets in two situations: those
--- 9271,9293 ----
  
   The following sections describe how we deal with these restrictions.
  
!  As described earlier, a ‘poly_int<1, T>’ has no indeterminates and so
  degenerates to a compile-time constant of type T.  It would be possible
  in that case to do all normal arithmetic on the T, and to compare the T
  using the normal C++ operators.  We deliberately prevent
  target-independent code from doing this, since the compiler needs to
! support other ‘poly_int’ as well, regardless of the current
! target's ‘NUM_POLY_INT_COEFFS’.
  
   However, it would be very artificial to force target-specific code to
  follow these restrictions if the target has no runtime indeterminates.
! There is therefore an implicit conversion from ‘poly_int<1, T>’ to T
  when compiling target-specific translation units.
  
  
  File: gccint.info,  Node: Comparisons involving poly_int,  Next: Arithmetic on poly_ints,  Prev: Consequences of using poly_int,  Up: poly_int
  
! 10.3 Comparisons involving ‘poly_int’
  =====================================
  
  In general we need to compare sizes and offsets in two situations: those
*************** latter is alias analysis: we might want
*** 9302,9310 ****
  memory references overlap.
  
   Referring back to the examples in the previous section, it makes sense
! to ask whether a memory reference of size '3 + 4X' overlaps one of size
! '1 + 5X', but it does not make sense to have a subreg in which the outer
! mode has '3 + 4X' bytes and the inner mode has '1 + 5X' bytes (or vice
  versa).  Such subregs are always invalid and should trigger an internal
  compiler error if formed.
  
--- 9302,9310 ----
  memory references overlap.
  
   Referring back to the examples in the previous section, it makes sense
! to ask whether a memory reference of size ‘3 + 4X’ overlaps one of size
! ‘1 + 5X’, but it does not make sense to have a subreg in which the outer
! mode has ‘3 + 4X’ bytes and the inner mode has ‘1 + 5X’ bytes (or vice
  versa).  Such subregs are always invalid and should trigger an internal
  compiler error if formed.
  
*************** distinction affects how they are used.
*** 9324,9333 ****
  
  File: gccint.info,  Node: Comparison functions for poly_int,  Next: Properties of the poly_int comparisons,  Up: Comparisons involving poly_int
  
! 10.3.1 Comparison functions for 'poly_int'
  ------------------------------------------
  
! 'poly_int' provides the following routines for checking whether a
  particular condition "may be" (might be) true:
  
       maybe_lt maybe_le maybe_eq maybe_ge maybe_gt
--- 9324,9333 ----
  
  File: gccint.info,  Node: Comparison functions for poly_int,  Next: Properties of the poly_int comparisons,  Up: Comparisons involving poly_int
  
! 10.3.1 Comparison functions for ‘poly_int’
  ------------------------------------------
  
! ‘poly_int’ provides the following routines for checking whether a
  particular condition "may be" (might be) true:
  
       maybe_lt maybe_le maybe_eq maybe_ge maybe_gt
*************** particular condition "may be" (might be)
*** 9335,9359 ****
  
   The functions have their natural meaning:
  
! 'maybe_lt(A, B)'
       Return true if A might be less than B.
  
! 'maybe_le(A, B)'
       Return true if A might be less than or equal to B.
  
! 'maybe_eq(A, B)'
       Return true if A might be equal to B.
  
! 'maybe_ne(A, B)'
       Return true if A might not be equal to B.
  
! 'maybe_ge(A, B)'
       Return true if A might be greater than or equal to B.
  
! 'maybe_gt(A, B)'
       Return true if A might be greater than B.
  
!  For readability, 'poly_int' also provides "known" inverses of these
  functions:
  
       known_lt (A, B) == !maybe_ge (A, B)
--- 9335,9359 ----
  
   The functions have their natural meaning:
  
! ‘maybe_lt(A, B)’
       Return true if A might be less than B.
  
! ‘maybe_le(A, B)’
       Return true if A might be less than or equal to B.
  
! ‘maybe_eq(A, B)’
       Return true if A might be equal to B.
  
! ‘maybe_ne(A, B)’
       Return true if A might not be equal to B.
  
! ‘maybe_ge(A, B)’
       Return true if A might be greater than or equal to B.
  
! ‘maybe_gt(A, B)’
       Return true if A might be greater than B.
  
!  For readability, ‘poly_int’ also provides "known" inverses of these
  functions:
  
       known_lt (A, B) == !maybe_ge (A, B)
*************** functions:
*** 9366,9389 ****
  
  File: gccint.info,  Node: Properties of the poly_int comparisons,  Next: Comparing potentially-unordered poly_ints,  Prev: Comparison functions for poly_int,  Up: Comparisons involving poly_int
  
! 10.3.2 Properties of the 'poly_int' comparisons
  -----------------------------------------------
  
! All "maybe" relations except 'maybe_ne' are transitive, so for example:
  
       maybe_lt (A, B) && maybe_lt (B, C) implies maybe_lt (A, C)
  
!  for all A, B and C.  'maybe_lt', 'maybe_gt' and 'maybe_ne' are
  irreflexive, so for example:
  
       !maybe_lt (A, A)
  
!  is true for all A.  'maybe_le', 'maybe_eq' and 'maybe_ge' are
  reflexive, so for example:
  
       maybe_le (A, A)
  
!  is true for all A.  'maybe_eq' and 'maybe_ne' are symmetric, so:
  
       maybe_eq (A, B) == maybe_eq (B, A)
       maybe_ne (A, B) == maybe_ne (B, A)
--- 9366,9389 ----
  
  File: gccint.info,  Node: Properties of the poly_int comparisons,  Next: Comparing potentially-unordered poly_ints,  Prev: Comparison functions for poly_int,  Up: Comparisons involving poly_int
  
! 10.3.2 Properties of the ‘poly_int’ comparisons
  -----------------------------------------------
  
! All "maybe" relations except ‘maybe_ne’ are transitive, so for example:
  
       maybe_lt (A, B) && maybe_lt (B, C) implies maybe_lt (A, C)
  
!  for all A, B and C.  ‘maybe_lt’, ‘maybe_gt’ and ‘maybe_ne’ are
  irreflexive, so for example:
  
       !maybe_lt (A, A)
  
!  is true for all A.  ‘maybe_le’, ‘maybe_eq’ and ‘maybe_ge’ are
  reflexive, so for example:
  
       maybe_le (A, A)
  
!  is true for all A.  ‘maybe_eq’ and ‘maybe_ne’ are symmetric, so:
  
       maybe_eq (A, B) == maybe_eq (B, A)
       maybe_ne (A, B) == maybe_ne (B, A)
*************** reflexive, so for example:
*** 9400,9417 ****
       maybe_le (A, B) && maybe_le (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)]
       maybe_ge (A, B) && maybe_ge (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)]
  
!  One example is again 'A == 3 + 4X' and 'B == 1 + 5X', where 'maybe_le
! (A, B)', 'maybe_ge (A, B)' and 'maybe_ne (A, B)' all hold.  'maybe_le'
! and 'maybe_ge' are therefore not antisymetric and do not form a partial
  order.
  
   From the above, it follows that:
  
!    * All "known" relations except 'known_ne' are transitive.
  
!    * 'known_lt', 'known_ne' and 'known_gt' are irreflexive.
  
!    * 'known_le', 'known_eq' and 'known_ge' are reflexive.
  
   Also:
  
--- 9400,9417 ----
       maybe_le (A, B) && maybe_le (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)]
       maybe_ge (A, B) && maybe_ge (B, A) does not imply !maybe_ne (A, B) [== known_eq (A, B)]
  
!  One example is again ‘A == 3 + 4X’ and ‘B == 1 + 5X’, where ‘maybe_le
! (A, B)’, ‘maybe_ge (A, B)’ and ‘maybe_ne (A, B)’ all hold.  ‘maybe_le’
! and ‘maybe_ge’ are therefore not antisymetric and do not form a partial
  order.
  
   From the above, it follows that:
  
!    • All "known" relations except ‘known_ne’ are transitive.
  
!    • ‘known_lt’, ‘known_ne’ and ‘known_gt’ are irreflexive.
  
!    • ‘known_le’, ‘known_eq’ and ‘known_ge’ are reflexive.
  
   Also:
  
*************** order.
*** 9422,9450 ****
       known_le (A, B) && known_le (B, A) == known_eq (A, B) [== !maybe_ne (A, B)]
       known_ge (A, B) && known_ge (B, A) == known_eq (A, B) [== !maybe_ne (A, B)]
  
!  'known_le' and 'known_ge' are therefore antisymmetric and are partial
  orders.  However:
  
       known_le (A, B) does not imply known_lt (A, B) || known_eq (A, B)
       known_ge (A, B) does not imply known_gt (A, B) || known_eq (A, B)
  
!  For example, 'known_le (4, 4 + 4X)' holds because the runtime
! indeterminate X is a nonnegative integer, but neither 'known_lt (4, 4 +
! 4X)' nor 'known_eq (4, 4 + 4X)' hold.
  
  
  File: gccint.info,  Node: Comparing potentially-unordered poly_ints,  Next: Comparing ordered poly_ints,  Prev: Properties of the poly_int comparisons,  Up: Comparisons involving poly_int
  
! 10.3.3 Comparing potentially-unordered 'poly_int's
  --------------------------------------------------
  
! In cases where there is no definite link between two 'poly_int's, we can
  usually make a conservatively-correct assumption.  For example, the
  conservative assumption for alias analysis is that two references
  _might_ alias.
  
   One way of checking whether [BEGIN1, END1) might overlap [BEGIN2, END2)
! using the 'poly_int' comparisons is:
  
       maybe_gt (END1, BEGIN2) && maybe_gt (END2, BEGIN1)
  
--- 9422,9450 ----
       known_le (A, B) && known_le (B, A) == known_eq (A, B) [== !maybe_ne (A, B)]
       known_ge (A, B) && known_ge (B, A) == known_eq (A, B) [== !maybe_ne (A, B)]
  
!  ‘known_le’ and ‘known_ge’ are therefore antisymmetric and are partial
  orders.  However:
  
       known_le (A, B) does not imply known_lt (A, B) || known_eq (A, B)
       known_ge (A, B) does not imply known_gt (A, B) || known_eq (A, B)
  
!  For example, ‘known_le (4, 4 + 4X)’ holds because the runtime
! indeterminate X is a nonnegative integer, but neither ‘known_lt (4, 4 +
! 4X)’ nor ‘known_eq (4, 4 + 4X)’ hold.
  
  
  File: gccint.info,  Node: Comparing potentially-unordered poly_ints,  Next: Comparing ordered poly_ints,  Prev: Properties of the poly_int comparisons,  Up: Comparisons involving poly_int
  
! 10.3.3 Comparing potentially-unordered ‘poly_int’s
  --------------------------------------------------
  
! In cases where there is no definite link between two ‘poly_int’s, we can
  usually make a conservatively-correct assumption.  For example, the
  conservative assumption for alias analysis is that two references
  _might_ alias.
  
   One way of checking whether [BEGIN1, END1) might overlap [BEGIN2, END2)
! using the ‘poly_int’ comparisons is:
  
       maybe_gt (END1, BEGIN2) && maybe_gt (END2, BEGIN1)
  
*************** helper functions instead.  *Note Range c
*** 9458,9516 ****
  
  File: gccint.info,  Node: Comparing ordered poly_ints,  Next: Checking for a poly_int marker value,  Prev: Comparing potentially-unordered poly_ints,  Up: Comparisons involving poly_int
  
! 10.3.4 Comparing ordered 'poly_int's
  ------------------------------------
  
! In cases where there is a definite link between two 'poly_int's, such as
  the outer and inner sizes of subregs, we usually require the sizes to be
! ordered by the 'known_le' partial order.  'poly_int' provides the
  following utility functions for ordered values:
  
! 'ordered_p (A, B)'
!      Return true if A and B are ordered by the 'known_le' partial order.
  
! 'ordered_min (A, B)'
!      Assert that A and B are ordered by 'known_le' and return the
       minimum of the two.  When using this function, please add a comment
       explaining why the values are known to be ordered.
  
! 'ordered_max (A, B)'
!      Assert that A and B are ordered by 'known_le' and return the
       maximum of the two.  When using this function, please add a comment
       explaining why the values are known to be ordered.
  
   For example, if a subreg has an outer mode of size OUTER and an inner
  mode of size INNER:
  
!    * the subreg is complete if known_eq (INNER, OUTER)
  
!    * otherwise, the subreg is paradoxical if known_le (INNER, OUTER)
  
!    * otherwise, the subreg is partial if known_le (OUTER, INNER)
  
!    * otherwise, the subreg is ill-formed
  
!  Thus the subreg is only valid if 'ordered_p (OUTER, INNER)' is true.
  If this condition is already known to be true then:
  
!    * the subreg is complete if known_eq (INNER, OUTER)
  
!    * the subreg is paradoxical if maybe_lt (INNER, OUTER)
  
!    * the subreg is partial if maybe_lt (OUTER, INNER)
  
   with the three conditions being mutually exclusive.
  
   Code that checks whether a subreg is valid would therefore generally
! check whether 'ordered_p' holds (in addition to whatever other checks
  are required for subreg validity).  Code that is dealing with existing
! subregs can assert that 'ordered_p' holds and use either of the
  classifications above.
  
  
  File: gccint.info,  Node: Checking for a poly_int marker value,  Next: Range checks on poly_ints,  Prev: Comparing ordered poly_ints,  Up: Comparisons involving poly_int
  
! 10.3.5 Checking for a 'poly_int' marker value
  ---------------------------------------------
  
  It is sometimes useful to have a special "marker value" that is not
--- 9458,9516 ----
  
  File: gccint.info,  Node: Comparing ordered poly_ints,  Next: Checking for a poly_int marker value,  Prev: Comparing potentially-unordered poly_ints,  Up: Comparisons involving poly_int
  
! 10.3.4 Comparing ordered ‘poly_int’s
  ------------------------------------
  
! In cases where there is a definite link between two ‘poly_int’s, such as
  the outer and inner sizes of subregs, we usually require the sizes to be
! ordered by the ‘known_le’ partial order.  ‘poly_int’ provides the
  following utility functions for ordered values:
  
! ‘ordered_p (A, B)’
!      Return true if A and B are ordered by the ‘known_le’ partial order.
  
! ‘ordered_min (A, B)’
!      Assert that A and B are ordered by ‘known_le’ and return the
       minimum of the two.  When using this function, please add a comment
       explaining why the values are known to be ordered.
  
! ‘ordered_max (A, B)’
!      Assert that A and B are ordered by ‘known_le’ and return the
       maximum of the two.  When using this function, please add a comment
       explaining why the values are known to be ordered.
  
   For example, if a subreg has an outer mode of size OUTER and an inner
  mode of size INNER:
  
!    • the subreg is complete if known_eq (INNER, OUTER)
  
!    • otherwise, the subreg is paradoxical if known_le (INNER, OUTER)
  
!    • otherwise, the subreg is partial if known_le (OUTER, INNER)
  
!    • otherwise, the subreg is ill-formed
  
!  Thus the subreg is only valid if ‘ordered_p (OUTER, INNER)’ is true.
  If this condition is already known to be true then:
  
!    • the subreg is complete if known_eq (INNER, OUTER)
  
!    • the subreg is paradoxical if maybe_lt (INNER, OUTER)
  
!    • the subreg is partial if maybe_lt (OUTER, INNER)
  
   with the three conditions being mutually exclusive.
  
   Code that checks whether a subreg is valid would therefore generally
! check whether ‘ordered_p’ holds (in addition to whatever other checks
  are required for subreg validity).  Code that is dealing with existing
! subregs can assert that ‘ordered_p’ holds and use either of the
  classifications above.
  
  
  File: gccint.info,  Node: Checking for a poly_int marker value,  Next: Range checks on poly_ints,  Prev: Comparing ordered poly_ints,  Up: Comparisons involving poly_int
  
! 10.3.5 Checking for a ‘poly_int’ marker value
  ---------------------------------------------
  
  It is sometimes useful to have a special "marker value" that is not
*************** to represent an unknown size, rather tha
*** 9519,9539 ****
  separate boolean to say whether the size is known.
  
   The best way of checking whether something is a marker value is
! 'known_eq'.  Conversely the best way of checking whether something is
! _not_ a marker value is 'maybe_ne'.
  
!  Thus in the size example just mentioned, 'known_eq (size, -1)' would
! check for an unknown size and 'maybe_ne (size, -1)' would check for a
  known size.
  
  
  File: gccint.info,  Node: Range checks on poly_ints,  Next: Sorting poly_ints,  Prev: Checking for a poly_int marker value,  Up: Comparisons involving poly_int
  
! 10.3.6 Range checks on 'poly_int's
  ----------------------------------
  
  As well as the core comparisons (*note Comparison functions for
! poly_int::), 'poly_int' provides utilities for various kinds of range
  check.  In each case the range is represented by a start position and a
  size rather than a start position and an end position; this is because
  the former is used much more often than the latter in GCC.  Also, the
--- 9519,9539 ----
  separate boolean to say whether the size is known.
  
   The best way of checking whether something is a marker value is
! ‘known_eq’.  Conversely the best way of checking whether something is
! _not_ a marker value is ‘maybe_ne’.
  
!  Thus in the size example just mentioned, ‘known_eq (size, -1)’ would
! check for an unknown size and ‘maybe_ne (size, -1)’ would check for a
  known size.
  
  
  File: gccint.info,  Node: Range checks on poly_ints,  Next: Sorting poly_ints,  Prev: Checking for a poly_int marker value,  Up: Comparisons involving poly_int
  
! 10.3.6 Range checks on ‘poly_int’s
  ----------------------------------
  
  As well as the core comparisons (*note Comparison functions for
! poly_int::), ‘poly_int’ provides utilities for various kinds of range
  check.  In each case the range is represented by a start position and a
  size rather than a start position and an end position; this is because
  the former is used much more often than the latter in GCC.  Also, the
*************** with a known start position but an unkno
*** 9542,9598 ****
  be nonnegative.  A range of size 0 does not contain anything or overlap
  anything.
  
! 'known_size_p (SIZE)'
       Return true if SIZE represents a known range size, false if it is
       -1 or all ones (for signed and unsigned types respectively).
  
! 'ranges_maybe_overlap_p (POS1, SIZE1, POS2, SIZE2)'
       Return true if the range described by POS1 and SIZE1 _might_
       overlap the range described by POS2 and SIZE2 (in other words,
       return true if we cannot prove that the ranges are disjoint).
  
! 'ranges_known_overlap_p (POS1, SIZE1, POS2, SIZE2)'
       Return true if the range described by POS1 and SIZE1 is known to
       overlap the range described by POS2 and SIZE2.
  
! 'known_subrange_p (POS1, SIZE1, POS2, SIZE2)'
       Return true if the range described by POS1 and SIZE1 is known to be
       contained in the range described by POS2 and SIZE2.
  
! 'maybe_in_range_p (VALUE, POS, SIZE)'
       Return true if VALUE _might_ be in the range described by POS and
       SIZE (in other words, return true if we cannot prove that VALUE is
       outside that range).
  
! 'known_in_range_p (VALUE, POS, SIZE)'
       Return true if VALUE is known to be in the range described by POS
       and SIZE.
  
! 'endpoint_representable_p (POS, SIZE)'
       Return true if the range described by POS and SIZE is open-ended or
       if the endpoint (POS + SIZE) is representable in the same type as
       POS and SIZE.  The function returns false if adding SIZE to POS
       makes conceptual sense but could overflow.
  
!  There is also a 'poly_int' version of the 'IN_RANGE_P' macro:
  
! 'coeffs_in_range_p (X, LOWER, UPPER)'
       Return true if every coefficient of X is in the inclusive range
       [LOWER, UPPER].  This function can be useful when testing whether
       an operation would cause the values of coefficients to overflow.
  
       Note that the function does not indicate whether X itself is in the
!      given range.  X can be either a constant or a 'poly_int'.
  
  
  File: gccint.info,  Node: Sorting poly_ints,  Prev: Range checks on poly_ints,  Up: Comparisons involving poly_int
  
! 10.3.7 Sorting 'poly_int's
  --------------------------
  
! 'poly_int' provides the following routine for sorting:
  
! 'compare_sizes_for_sort (A, B)'
       Compare A and B in reverse lexicographical order (that is, compare
       the highest-indexed coefficients first).  This can be useful when
       sorting data structures, since it has the effect of separating
--- 9542,9598 ----
  be nonnegative.  A range of size 0 does not contain anything or overlap
  anything.
  
! ‘known_size_p (SIZE)’
       Return true if SIZE represents a known range size, false if it is
       -1 or all ones (for signed and unsigned types respectively).
  
! ‘ranges_maybe_overlap_p (POS1, SIZE1, POS2, SIZE2)’
       Return true if the range described by POS1 and SIZE1 _might_
       overlap the range described by POS2 and SIZE2 (in other words,
       return true if we cannot prove that the ranges are disjoint).
  
! ‘ranges_known_overlap_p (POS1, SIZE1, POS2, SIZE2)’
       Return true if the range described by POS1 and SIZE1 is known to
       overlap the range described by POS2 and SIZE2.
  
! ‘known_subrange_p (POS1, SIZE1, POS2, SIZE2)’
       Return true if the range described by POS1 and SIZE1 is known to be
       contained in the range described by POS2 and SIZE2.
  
! ‘maybe_in_range_p (VALUE, POS, SIZE)’
       Return true if VALUE _might_ be in the range described by POS and
       SIZE (in other words, return true if we cannot prove that VALUE is
       outside that range).
  
! ‘known_in_range_p (VALUE, POS, SIZE)’
       Return true if VALUE is known to be in the range described by POS
       and SIZE.
  
! ‘endpoint_representable_p (POS, SIZE)’
       Return true if the range described by POS and SIZE is open-ended or
       if the endpoint (POS + SIZE) is representable in the same type as
       POS and SIZE.  The function returns false if adding SIZE to POS
       makes conceptual sense but could overflow.
  
!  There is also a ‘poly_int’ version of the ‘IN_RANGE_P’ macro:
  
! ‘coeffs_in_range_p (X, LOWER, UPPER)’
       Return true if every coefficient of X is in the inclusive range
       [LOWER, UPPER].  This function can be useful when testing whether
       an operation would cause the values of coefficients to overflow.
  
       Note that the function does not indicate whether X itself is in the
!      given range.  X can be either a constant or a ‘poly_int’.
  
  
  File: gccint.info,  Node: Sorting poly_ints,  Prev: Range checks on poly_ints,  Up: Comparisons involving poly_int
  
! 10.3.7 Sorting ‘poly_int’s
  --------------------------
  
! ‘poly_int’ provides the following routine for sorting:
  
! ‘compare_sizes_for_sort (A, B)’
       Compare A and B in reverse lexicographical order (that is, compare
       the highest-indexed coefficients first).  This can be useful when
       sorting data structures, since it has the effect of separating
*************** File: gccint.info,  Node: Sorting poly_i
*** 9600,9618 ****
       the constant values come first.
  
       Note that the values do not necessarily end up in numerical order.
!      For example, '1 + 1X' would come after '100' in the sort order, but
!      may well be less than '100' at run time.
  
  
  File: gccint.info,  Node: Arithmetic on poly_ints,  Next: Alignment of poly_ints,  Prev: Comparisons involving poly_int,  Up: poly_int
  
! 10.4 Arithmetic on 'poly_int's
  ==============================
  
  Addition, subtraction, negation and bit inversion all work normally for
! 'poly_int's.  Multiplication by a constant multiplier and left shifting
  by a constant shift amount also work normally.  General multiplication
! of two 'poly_int's is not supported and is not useful in practice.
  
   Other operations are only conditionally supported: the operation might
  succeed or might fail, depending on the inputs.
--- 9600,9618 ----
       the constant values come first.
  
       Note that the values do not necessarily end up in numerical order.
!      For example, ‘1 + 1X’ would come after ‘100’ in the sort order, but
!      may well be less than ‘100’ at run time.
  
  
  File: gccint.info,  Node: Arithmetic on poly_ints,  Next: Alignment of poly_ints,  Prev: Comparisons involving poly_int,  Up: poly_int
  
! 10.4 Arithmetic on ‘poly_int’s
  ==============================
  
  Addition, subtraction, negation and bit inversion all work normally for
! ‘poly_int’s.  Multiplication by a constant multiplier and left shifting
  by a constant shift amount also work normally.  General multiplication
! of two ‘poly_int’s is not supported and is not useful in practice.
  
   Other operations are only conditionally supported: the operation might
  succeed or might fail, depending on the inputs.
*************** succeed or might fail, depending on the
*** 9629,9639 ****
  
  File: gccint.info,  Node: Using poly_int with C++ arithmetic operators,  Next: wi arithmetic on poly_ints,  Up: Arithmetic on poly_ints
  
! 10.4.1 Using 'poly_int' with C++ arithmetic operators
  -----------------------------------------------------
  
  The following C++ expressions are supported, where P1 and P2 are
! 'poly_int's and where C1 and C2 are scalars:
  
       -P1
       ~P1
--- 9629,9639 ----
  
  File: gccint.info,  Node: Using poly_int with C++ arithmetic operators,  Next: wi arithmetic on poly_ints,  Up: Arithmetic on poly_ints
  
! 10.4.1 Using ‘poly_int’ with C++ arithmetic operators
  -----------------------------------------------------
  
  The following C++ expressions are supported, where P1 and P2 are
! ‘poly_int’s and where C1 and C2 are scalars:
  
       -P1
       ~P1
*************** The following C++ expressions are suppor
*** 9662,9669 ****
  
   These arithmetic operations handle integer ranks in a similar way to
  C++.  The main difference is that every coefficient narrower than
! 'HOST_WIDE_INT' promotes to 'HOST_WIDE_INT', whereas in C++ everything
! narrower than 'int' promotes to 'int'.  For example:
  
       poly_uint16     + int          -> poly_int64
       unsigned int    + poly_uint16  -> poly_int64
--- 9662,9669 ----
  
   These arithmetic operations handle integer ranks in a similar way to
  C++.  The main difference is that every coefficient narrower than
! ‘HOST_WIDE_INT’ promotes to ‘HOST_WIDE_INT’, whereas in C++ everything
! narrower than ‘int’ promotes to ‘int’.  For example:
  
       poly_uint16     + int          -> poly_int64
       unsigned int    + poly_uint16  -> poly_int64
*************** narrower than 'int' promotes to 'int'.
*** 9674,9692 ****
       offset_int      + poly_uint16  -> poly_offset_int
  
   In the first two examples, both coefficients are narrower than
! 'HOST_WIDE_INT', so the result has coefficients of type 'HOST_WIDE_INT'.
  In the other examples, the coefficient with the highest rank "wins".
  
!  If one of the operands is 'wide_int' or 'poly_wide_int', the rules are
! the same as for 'wide_int' arithmetic.
  
  
  File: gccint.info,  Node: wi arithmetic on poly_ints,  Next: Division of poly_ints,  Prev: Using poly_int with C++ arithmetic operators,  Up: Arithmetic on poly_ints
  
! 10.4.2 'wi' arithmetic on 'poly_int's
  -------------------------------------
  
! As well as the C++ operators, 'poly_int' supports the following 'wi'
  routines:
  
       wi::neg (P1, &OVERFLOW)
--- 9674,9692 ----
       offset_int      + poly_uint16  -> poly_offset_int
  
   In the first two examples, both coefficients are narrower than
! ‘HOST_WIDE_INT’, so the result has coefficients of type ‘HOST_WIDE_INT’.
  In the other examples, the coefficient with the highest rank "wins".
  
!  If one of the operands is ‘wide_int’ or ‘poly_wide_int’, the rules are
! the same as for ‘wide_int’ arithmetic.
  
  
  File: gccint.info,  Node: wi arithmetic on poly_ints,  Next: Division of poly_ints,  Prev: Using poly_int with C++ arithmetic operators,  Up: Arithmetic on poly_ints
  
! 10.4.2 ‘wi’ arithmetic on ‘poly_int’s
  -------------------------------------
  
! As well as the C++ operators, ‘poly_int’ supports the following ‘wi’
  routines:
  
       wi::neg (P1, &OVERFLOW)
*************** final runtime value would overflow.
*** 9714,9785 ****
  
  File: gccint.info,  Node: Division of poly_ints,  Next: Other poly_int arithmetic,  Prev: wi arithmetic on poly_ints,  Up: Arithmetic on poly_ints
  
! 10.4.3 Division of 'poly_int's
  ------------------------------
  
! Division of 'poly_int's is possible for certain inputs.  The functions
  for division return true if the operation is possible and in most cases
  return the results by pointer.  The routines are:
  
! 'multiple_p (A, B)'
! 'multiple_p (A, B, "IENT)'
       Return true if A is an exact multiple of B, storing the result in
       QUOTIENT if so.  There are overloads for various combinations of
       polynomial and constant A, B and QUOTIENT.
  
! 'constant_multiple_p (A, B)'
! 'constant_multiple_p (A, B, "IENT)'
!      Like 'multiple_p', but also test whether the multiple is a
       compile-time constant.
  
! 'can_div_trunc_p (A, B, "IENT)'
! 'can_div_trunc_p (A, B, "IENT, &REMAINDER)'
!      Return true if we can calculate 'trunc (A / B)' at compile time,
       storing the result in QUOTIENT and REMAINDER if so.
  
! 'can_div_away_from_zero_p (A, B, "IENT)'
!      Return true if we can calculate 'A / B' at compile time, rounding
       away from zero.  Store the result in QUOTIENT if so.
  
!      Note that this is true if and only if 'can_div_trunc_p' is true.
       The only difference is in the rounding of the result.
  
   There is also an asserting form of division:
  
! 'exact_div (A, B)'
!      Assert that A is a multiple of B and return 'A / B'.  The result is
!      a 'poly_int' if A is a 'poly_int'.
  
  
  File: gccint.info,  Node: Other poly_int arithmetic,  Prev: Division of poly_ints,  Up: Arithmetic on poly_ints
  
! 10.4.4 Other 'poly_int' arithmetic
  ----------------------------------
  
  There are tentative routines for other operations besides division:
  
! 'can_ior_p (A, B, &RESULT)'
!      Return true if we can calculate 'A | B' at compile time, storing
       the result in RESULT if so.
  
!  Also, ANDs with a value '(1 << Y) - 1' or its inverse can be treated as
  alignment operations.  *Note Alignment of poly_ints::.
  
   In addition, the following miscellaneous routines are available:
  
! 'coeff_gcd (A)'
       Return the greatest common divisor of all nonzero coefficients in
       A, or zero if A is known to be zero.
  
! 'common_multiple (A, B)'
       Return a value that is a multiple of both A and B, where one value
!      is a 'poly_int' and the other is a scalar.  The result will be the
       least common multiple for some indeterminate values but not
       necessarily for all.
  
! 'force_common_multiple (A, B)'
!      Return a value that is a multiple of both 'poly_int' A and
!      'poly_int' B, asserting that such a value exists.  The result will
       be the least common multiple for some indeterminate values but not
       necessarily for all.
  
--- 9714,9785 ----
  
  File: gccint.info,  Node: Division of poly_ints,  Next: Other poly_int arithmetic,  Prev: wi arithmetic on poly_ints,  Up: Arithmetic on poly_ints
  
! 10.4.3 Division of ‘poly_int’s
  ------------------------------
  
! Division of ‘poly_int’s is possible for certain inputs.  The functions
  for division return true if the operation is possible and in most cases
  return the results by pointer.  The routines are:
  
! ‘multiple_p (A, B)’
! ‘multiple_p (A, B, "IENT)’
       Return true if A is an exact multiple of B, storing the result in
       QUOTIENT if so.  There are overloads for various combinations of
       polynomial and constant A, B and QUOTIENT.
  
! ‘constant_multiple_p (A, B)’
! ‘constant_multiple_p (A, B, "IENT)’
!      Like ‘multiple_p’, but also test whether the multiple is a
       compile-time constant.
  
! ‘can_div_trunc_p (A, B, "IENT)’
! ‘can_div_trunc_p (A, B, "IENT, &REMAINDER)’
!      Return true if we can calculate ‘trunc (A / B)’ at compile time,
       storing the result in QUOTIENT and REMAINDER if so.
  
! ‘can_div_away_from_zero_p (A, B, "IENT)’
!      Return true if we can calculate ‘A / B’ at compile time, rounding
       away from zero.  Store the result in QUOTIENT if so.
  
!      Note that this is true if and only if ‘can_div_trunc_p’ is true.
       The only difference is in the rounding of the result.
  
   There is also an asserting form of division:
  
! ‘exact_div (A, B)’
!      Assert that A is a multiple of B and return ‘A / B’.  The result is
!      a ‘poly_int’ if A is a ‘poly_int’.
  
  
  File: gccint.info,  Node: Other poly_int arithmetic,  Prev: Division of poly_ints,  Up: Arithmetic on poly_ints
  
! 10.4.4 Other ‘poly_int’ arithmetic
  ----------------------------------
  
  There are tentative routines for other operations besides division:
  
! ‘can_ior_p (A, B, &RESULT)’
!      Return true if we can calculate ‘A | B’ at compile time, storing
       the result in RESULT if so.
  
!  Also, ANDs with a value ‘(1 << Y) - 1’ or its inverse can be treated as
  alignment operations.  *Note Alignment of poly_ints::.
  
   In addition, the following miscellaneous routines are available:
  
! ‘coeff_gcd (A)’
       Return the greatest common divisor of all nonzero coefficients in
       A, or zero if A is known to be zero.
  
! ‘common_multiple (A, B)’
       Return a value that is a multiple of both A and B, where one value
!      is a ‘poly_int’ and the other is a scalar.  The result will be the
       least common multiple for some indeterminate values but not
       necessarily for all.
  
! ‘force_common_multiple (A, B)’
!      Return a value that is a multiple of both ‘poly_int’ A and
!      ‘poly_int’ B, asserting that such a value exists.  The result will
       be the least common multiple for some indeterminate values but not
       necessarily for all.
  
*************** alignment operations.  *Note Alignment o
*** 9791,9825 ****
  
  File: gccint.info,  Node: Alignment of poly_ints,  Next: Computing bounds on poly_ints,  Prev: Arithmetic on poly_ints,  Up: poly_int
  
! 10.5 Alignment of 'poly_int's
  =============================
  
! 'poly_int' provides various routines for aligning values and for
  querying misalignments.  In each case the alignment must be a power of
  2.
  
! 'can_align_p (VALUE, ALIGN)'
       Return true if we can align VALUE up or down to the nearest
       multiple of ALIGN at compile time.  The answer is the same for both
       directions.
  
! 'can_align_down (VALUE, ALIGN, &ALIGNED)'
!      Return true if 'can_align_p'; if so, set ALIGNED to the greatest
       aligned value that is less than or equal to VALUE.
  
! 'can_align_up (VALUE, ALIGN, &ALIGNED)'
!      Return true if 'can_align_p'; if so, set ALIGNED to the lowest
       aligned value that is greater than or equal to VALUE.
  
! 'known_equal_after_align_down (A, B, ALIGN)'
       Return true if we can align A and B down to the nearest ALIGN
       boundary at compile time and if the two results are equal.
  
! 'known_equal_after_align_up (A, B, ALIGN)'
       Return true if we can align A and B up to the nearest ALIGN
       boundary at compile time and if the two results are equal.
  
! 'aligned_lower_bound (VALUE, ALIGN)'
       Return a result that is no greater than VALUE and that is aligned
       to ALIGN.  The result will the closest aligned value for some
       indeterminate values but not necessarily for all.
--- 9791,9825 ----
  
  File: gccint.info,  Node: Alignment of poly_ints,  Next: Computing bounds on poly_ints,  Prev: Arithmetic on poly_ints,  Up: poly_int
  
! 10.5 Alignment of ‘poly_int’s
  =============================
  
! ‘poly_int’ provides various routines for aligning values and for
  querying misalignments.  In each case the alignment must be a power of
  2.
  
! ‘can_align_p (VALUE, ALIGN)’
       Return true if we can align VALUE up or down to the nearest
       multiple of ALIGN at compile time.  The answer is the same for both
       directions.
  
! ‘can_align_down (VALUE, ALIGN, &ALIGNED)’
!      Return true if ‘can_align_p’; if so, set ALIGNED to the greatest
       aligned value that is less than or equal to VALUE.
  
! ‘can_align_up (VALUE, ALIGN, &ALIGNED)’
!      Return true if ‘can_align_p’; if so, set ALIGNED to the lowest
       aligned value that is greater than or equal to VALUE.
  
! ‘known_equal_after_align_down (A, B, ALIGN)’
       Return true if we can align A and B down to the nearest ALIGN
       boundary at compile time and if the two results are equal.
  
! ‘known_equal_after_align_up (A, B, ALIGN)’
       Return true if we can align A and B up to the nearest ALIGN
       boundary at compile time and if the two results are equal.
  
! ‘aligned_lower_bound (VALUE, ALIGN)’
       Return a result that is no greater than VALUE and that is aligned
       to ALIGN.  The result will the closest aligned value for some
       indeterminate values but not necessarily for all.
*************** querying misalignments.  In each case th
*** 9831,9869 ****
  
            aligned_lower_bound (LIMIT - SIZE, ALIGN)
  
! 'aligned_upper_bound (VALUE, ALIGN)'
       Likewise return a result that is no less than VALUE and that is
       aligned to ALIGN.  This is the routine that would be used for
       upward-growing stacks in the scenario just described.
  
! 'known_misalignment (VALUE, ALIGN, &MISALIGN)'
       Return true if we can calculate the misalignment of VALUE with
       respect to ALIGN at compile time, storing the result in MISALIGN if
       so.
  
! 'known_alignment (VALUE)'
       Return the minimum alignment that VALUE is known to have (in other
       words, the largest alignment that can be guaranteed whatever the
       values of the indeterminates turn out to be).  Return 0 if VALUE is
       known to be 0.
  
! 'force_align_down (VALUE, ALIGN)'
       Assert that VALUE can be aligned down to ALIGN at compile time and
       return the result.  When using this routine, please add a comment
       explaining why the assertion is known to hold.
  
! 'force_align_up (VALUE, ALIGN)'
       Likewise, but aligning up.
  
! 'force_align_down_and_div (VALUE, ALIGN)'
!      Divide the result of 'force_align_down' by ALIGN.  Again, please
!      add a comment explaining why the assertion in 'force_align_down' is
       known to hold.
  
! 'force_align_up_and_div (VALUE, ALIGN)'
!      Likewise for 'force_align_up'.
  
! 'force_get_misalignment (VALUE, ALIGN)'
       Assert that we can calculate the misalignment of VALUE with respect
       to ALIGN at compile time and return the misalignment.  When using
       this function, please add a comment explaining why the assertion is
--- 9831,9869 ----
  
            aligned_lower_bound (LIMIT - SIZE, ALIGN)
  
! ‘aligned_upper_bound (VALUE, ALIGN)’
       Likewise return a result that is no less than VALUE and that is
       aligned to ALIGN.  This is the routine that would be used for
       upward-growing stacks in the scenario just described.
  
! ‘known_misalignment (VALUE, ALIGN, &MISALIGN)’
       Return true if we can calculate the misalignment of VALUE with
       respect to ALIGN at compile time, storing the result in MISALIGN if
       so.
  
! ‘known_alignment (VALUE)’
       Return the minimum alignment that VALUE is known to have (in other
       words, the largest alignment that can be guaranteed whatever the
       values of the indeterminates turn out to be).  Return 0 if VALUE is
       known to be 0.
  
! ‘force_align_down (VALUE, ALIGN)’
       Assert that VALUE can be aligned down to ALIGN at compile time and
       return the result.  When using this routine, please add a comment
       explaining why the assertion is known to hold.
  
! ‘force_align_up (VALUE, ALIGN)’
       Likewise, but aligning up.
  
! ‘force_align_down_and_div (VALUE, ALIGN)’
!      Divide the result of ‘force_align_down’ by ALIGN.  Again, please
!      add a comment explaining why the assertion in ‘force_align_down’ is
       known to hold.
  
! ‘force_align_up_and_div (VALUE, ALIGN)’
!      Likewise for ‘force_align_up’.
  
! ‘force_get_misalignment (VALUE, ALIGN)’
       Assert that we can calculate the misalignment of VALUE with respect
       to ALIGN at compile time and return the misalignment.  When using
       this function, please add a comment explaining why the assertion is
*************** querying misalignments.  In each case th
*** 9872,9905 ****
  
  File: gccint.info,  Node: Computing bounds on poly_ints,  Next: Converting poly_ints,  Prev: Alignment of poly_ints,  Up: poly_int
  
! 10.6 Computing bounds on 'poly_int's
  ====================================
  
! 'poly_int' also provides routines for calculating lower and upper
  bounds:
  
! 'constant_lower_bound (A)'
       Assert that A is nonnegative and return the smallest value it can
       have.
  
! 'constant_lower_bound_with_limit (A, B)'
       Return the least value A can have, given that the context in which
       A appears guarantees that the answer is no less than B.  In other
       words, the caller is asserting that A is greater than or equal to B
!      even if 'known_ge (A, B)' doesn't hold.
  
! 'constant_upper_bound_with_limit (A, B)'
       Return the greatest value A can have, given that the context in
       which A appears guarantees that the answer is no greater than B.
       In other words, the caller is asserting that A is less than or
!      equal to B even if 'known_le (A, B)' doesn't hold.
  
! 'lower_bound (A, B)'
       Return a value that is always less than or equal to both A and B.
       It will be the greatest such value for some indeterminate values
       but necessarily for all.
  
! 'upper_bound (A, B)'
       Return a value that is always greater than or equal to both A and
       B.  It will be the least such value for some indeterminate values
       but necessarily for all.
--- 9872,9905 ----
  
  File: gccint.info,  Node: Computing bounds on poly_ints,  Next: Converting poly_ints,  Prev: Alignment of poly_ints,  Up: poly_int
  
! 10.6 Computing bounds on ‘poly_int’s
  ====================================
  
! ‘poly_int’ also provides routines for calculating lower and upper
  bounds:
  
! ‘constant_lower_bound (A)’
       Assert that A is nonnegative and return the smallest value it can
       have.
  
! ‘constant_lower_bound_with_limit (A, B)’
       Return the least value A can have, given that the context in which
       A appears guarantees that the answer is no less than B.  In other
       words, the caller is asserting that A is greater than or equal to B
!      even if ‘known_ge (A, B)’ doesn't hold.
  
! ‘constant_upper_bound_with_limit (A, B)’
       Return the greatest value A can have, given that the context in
       which A appears guarantees that the answer is no greater than B.
       In other words, the caller is asserting that A is less than or
!      equal to B even if ‘known_le (A, B)’ doesn't hold.
  
! ‘lower_bound (A, B)’
       Return a value that is always less than or equal to both A and B.
       It will be the greatest such value for some indeterminate values
       but necessarily for all.
  
! ‘upper_bound (A, B)’
       Return a value that is always greater than or equal to both A and
       B.  It will be the least such value for some indeterminate values
       but necessarily for all.
*************** bounds:
*** 9907,10039 ****
  
  File: gccint.info,  Node: Converting poly_ints,  Next: Miscellaneous poly_int routines,  Prev: Computing bounds on poly_ints,  Up: poly_int
  
! 10.7 Converting 'poly_int's
  ===========================
  
! A 'poly_int' can be constructed from up to N individual T
  coefficients, with the remaining coefficients being implicitly zero.  In
! particular, this means that every 'poly_int' can be constructed
  from a single scalar T, or something compatible with T.
  
!  Also, a 'poly_int' can be constructed from a 'poly_int' if
  T can be constructed from U.
  
   The following functions provide other forms of conversion, or test
  whether such a conversion would succeed.
  
! 'VALUE.is_constant ()'
!      Return true if 'poly_int' VALUE is a compile-time constant.
  
! 'VALUE.is_constant (&C1)'
!      Return true if 'poly_int' VALUE is a compile-time constant, storing
       it in C1 if so.  C1 must be able to hold all constant values of
       VALUE without loss of precision.
  
! 'VALUE.to_constant ()'
       Assert that VALUE is a compile-time constant and return its value.
       When using this function, please add a comment explaining why the
       condition is known to hold (for example, because an earlier phase
       of analysis rejected non-constants).
  
! 'VALUE.to_shwi (&P2)'
!      Return true if 'poly_int' VALUE can be represented without
!      loss of precision as a 'poly_int', storing it
       in that form in P2 if so.
  
! 'VALUE.to_uhwi (&P2)'
!      Return true if 'poly_int' VALUE can be represented without
!      loss of precision as a 'poly_int',
       storing it in that form in P2 if so.
  
! 'VALUE.force_shwi ()'
!      Forcibly convert each coefficient of 'poly_int' VALUE to
!      'HOST_WIDE_INT', truncating any that are out of range.  Return the
!      result as a 'poly_int'.
  
! 'VALUE.force_uhwi ()'
!      Forcibly convert each coefficient of 'poly_int' VALUE to
!      'unsigned HOST_WIDE_INT', truncating any that are out of range.
!      Return the result as a 'poly_int'.
  
! 'wi::shwi (VALUE, PRECISION)'
!      Return a 'poly_int' with the same value as VALUE, but with the
!      coefficients converted from 'HOST_WIDE_INT' to 'wide_int'.
!      PRECISION specifies the precision of the 'wide_int' cofficients; if
!      this is wider than a 'HOST_WIDE_INT', the coefficients of VALUE
       will be sign-extended to fit.
  
! 'wi::uhwi (VALUE, PRECISION)'
!      Like 'wi::shwi', except that VALUE has coefficients of type
!      'unsigned HOST_WIDE_INT'.  If PRECISION is wider than a
!      'HOST_WIDE_INT', the coefficients of VALUE will be zero-extended to
       fit.
  
! 'wi::sext (VALUE, PRECISION)'
!      Return a 'poly_int' of the same type as VALUE, sign-extending every
       coefficient from the low PRECISION bits.  This in effect applies
!      'wi::sext' to each coefficient individually.
  
! 'wi::zext (VALUE, PRECISION)'
!      Like 'wi::sext', but for zero extension.
  
! 'poly_wide_int::from (VALUE, PRECISION, SIGN)'
!      Convert VALUE to a 'poly_wide_int' in which each coefficient has
       PRECISION bits.  Extend the coefficients according to SIGN if the
       coefficients have fewer bits.
  
! 'poly_offset_int::from (VALUE, SIGN)'
!      Convert VALUE to a 'poly_offset_int', extending its coefficients
!      according to SIGN if they have fewer bits than 'offset_int'.
  
! 'poly_widest_int::from (VALUE, SIGN)'
!      Convert VALUE to a 'poly_widest_int', extending its coefficients
!      according to SIGN if they have fewer bits than 'widest_int'.
  
  
  File: gccint.info,  Node: Miscellaneous poly_int routines,  Next: Guidelines for using poly_int,  Prev: Converting poly_ints,  Up: poly_int
  
! 10.8 Miscellaneous 'poly_int' routines
  ======================================
  
! 'print_dec (VALUE, FILE, SIGN)'
! 'print_dec (VALUE, FILE)'
       Print VALUE to FILE as a decimal value, interpreting the
       coefficients according to SIGN.  The final argument is optional if
!      VALUE has an inherent sign; for example, 'poly_int64' values print
!      as signed by default and 'poly_uint64' values print as unsigned by
       default.
  
!      This is a simply a 'poly_int' version of a wide-int routine.
  
  
  File: gccint.info,  Node: Guidelines for using poly_int,  Prev: Miscellaneous poly_int routines,  Up: poly_int
  
! 10.9 Guidelines for using 'poly_int'
  ====================================
  
! One of the main design goals of 'poly_int' was to make it easy to write
  target-independent code that handles variable-sized registers even when
  the current target has fixed-sized registers.  There are two aspects to
  this:
  
!    * The set of 'poly_int' operations should be complete enough that the
       question in most cases becomes "Can we do this operation on these
!      particular 'poly_int' values?  If not, bail out" rather than "Are
!      these 'poly_int' values constant?  If so, do the operation,
       otherwise bail out".
  
!    * If target-independent code compiles and runs correctly on a target
!      with one value of 'NUM_POLY_INT_COEFFS', and if the code does not
!      use asserting functions like 'to_constant', it is reasonable to
       assume that the code also works on targets with other values of
!      'NUM_POLY_INT_COEFFS'.  There is no need to check this during
       everyday development.
  
   So the general principle is: if target-independent code is dealing with
! a 'poly_int' value, it is better to operate on it as a 'poly_int' if at
  all possible, choosing conservatively-correct behavior if a particular
! operation fails.  For example, the following code handles an index 'pos'
! into a sequence of vectors that each have 'nunits' elements:
  
       /* Calculate which vector contains the result, and which lane of
          that vector we need.  */
--- 9907,10039 ----
  
  File: gccint.info,  Node: Converting poly_ints,  Next: Miscellaneous poly_int routines,  Prev: Computing bounds on poly_ints,  Up: poly_int
  
! 10.7 Converting ‘poly_int’s
  ===========================
  
! A ‘poly_int’ can be constructed from up to N individual T
  coefficients, with the remaining coefficients being implicitly zero.  In
! particular, this means that every ‘poly_int’ can be constructed
  from a single scalar T, or something compatible with T.
  
!  Also, a ‘poly_int’ can be constructed from a ‘poly_int’ if
  T can be constructed from U.
  
   The following functions provide other forms of conversion, or test
  whether such a conversion would succeed.
  
! ‘VALUE.is_constant ()’
!      Return true if ‘poly_int’ VALUE is a compile-time constant.
  
! ‘VALUE.is_constant (&C1)’
!      Return true if ‘poly_int’ VALUE is a compile-time constant, storing
       it in C1 if so.  C1 must be able to hold all constant values of
       VALUE without loss of precision.
  
! ‘VALUE.to_constant ()’
       Assert that VALUE is a compile-time constant and return its value.
       When using this function, please add a comment explaining why the
       condition is known to hold (for example, because an earlier phase
       of analysis rejected non-constants).
  
! ‘VALUE.to_shwi (&P2)’
!      Return true if ‘poly_int’ VALUE can be represented without
!      loss of precision as a ‘poly_int’, storing it
       in that form in P2 if so.
  
! ‘VALUE.to_uhwi (&P2)’
!      Return true if ‘poly_int’ VALUE can be represented without
!      loss of precision as a ‘poly_int’,
       storing it in that form in P2 if so.
  
! ‘VALUE.force_shwi ()’
!      Forcibly convert each coefficient of ‘poly_int’ VALUE to
!      ‘HOST_WIDE_INT’, truncating any that are out of range.  Return the
!      result as a ‘poly_int’.
  
! ‘VALUE.force_uhwi ()’
!      Forcibly convert each coefficient of ‘poly_int’ VALUE to
!      ‘unsigned HOST_WIDE_INT’, truncating any that are out of range.
!      Return the result as a ‘poly_int’.
  
! ‘wi::shwi (VALUE, PRECISION)’
!      Return a ‘poly_int’ with the same value as VALUE, but with the
!      coefficients converted from ‘HOST_WIDE_INT’ to ‘wide_int’.
!      PRECISION specifies the precision of the ‘wide_int’ cofficients; if
!      this is wider than a ‘HOST_WIDE_INT’, the coefficients of VALUE
       will be sign-extended to fit.
  
! ‘wi::uhwi (VALUE, PRECISION)’
!      Like ‘wi::shwi’, except that VALUE has coefficients of type
!      ‘unsigned HOST_WIDE_INT’.  If PRECISION is wider than a
!      ‘HOST_WIDE_INT’, the coefficients of VALUE will be zero-extended to
       fit.
  
! ‘wi::sext (VALUE, PRECISION)’
!      Return a ‘poly_int’ of the same type as VALUE, sign-extending every
       coefficient from the low PRECISION bits.  This in effect applies
!      ‘wi::sext’ to each coefficient individually.
  
! ‘wi::zext (VALUE, PRECISION)’
!      Like ‘wi::sext’, but for zero extension.
  
! ‘poly_wide_int::from (VALUE, PRECISION, SIGN)’
!      Convert VALUE to a ‘poly_wide_int’ in which each coefficient has
       PRECISION bits.  Extend the coefficients according to SIGN if the
       coefficients have fewer bits.
  
! ‘poly_offset_int::from (VALUE, SIGN)’
!      Convert VALUE to a ‘poly_offset_int’, extending its coefficients
!      according to SIGN if they have fewer bits than ‘offset_int’.
  
! ‘poly_widest_int::from (VALUE, SIGN)’
!      Convert VALUE to a ‘poly_widest_int’, extending its coefficients
!      according to SIGN if they have fewer bits than ‘widest_int’.
  
  
  File: gccint.info,  Node: Miscellaneous poly_int routines,  Next: Guidelines for using poly_int,  Prev: Converting poly_ints,  Up: poly_int
  
! 10.8 Miscellaneous ‘poly_int’ routines
  ======================================
  
! ‘print_dec (VALUE, FILE, SIGN)’
! ‘print_dec (VALUE, FILE)’
       Print VALUE to FILE as a decimal value, interpreting the
       coefficients according to SIGN.  The final argument is optional if
!      VALUE has an inherent sign; for example, ‘poly_int64’ values print
!      as signed by default and ‘poly_uint64’ values print as unsigned by
       default.
  
!      This is a simply a ‘poly_int’ version of a wide-int routine.
  
  
  File: gccint.info,  Node: Guidelines for using poly_int,  Prev: Miscellaneous poly_int routines,  Up: poly_int
  
! 10.9 Guidelines for using ‘poly_int’
  ====================================
  
! One of the main design goals of ‘poly_int’ was to make it easy to write
  target-independent code that handles variable-sized registers even when
  the current target has fixed-sized registers.  There are two aspects to
  this:
  
!    • The set of ‘poly_int’ operations should be complete enough that the
       question in most cases becomes "Can we do this operation on these
!      particular ‘poly_int’ values?  If not, bail out" rather than "Are
!      these ‘poly_int’ values constant?  If so, do the operation,
       otherwise bail out".
  
!    • If target-independent code compiles and runs correctly on a target
!      with one value of ‘NUM_POLY_INT_COEFFS’, and if the code does not
!      use asserting functions like ‘to_constant’, it is reasonable to
       assume that the code also works on targets with other values of
!      ‘NUM_POLY_INT_COEFFS’.  There is no need to check this during
       everyday development.
  
   So the general principle is: if target-independent code is dealing with
! a ‘poly_int’ value, it is better to operate on it as a ‘poly_int’ if at
  all possible, choosing conservatively-correct behavior if a particular
! operation fails.  For example, the following code handles an index ‘pos’
! into a sequence of vectors that each have ‘nunits’ elements:
  
       /* Calculate which vector contains the result, and which lane of
          that vector we need.  */
*************** into a sequence of vectors that each hav
*** 10046,10052 ****
           return false;
         }
  
!  However, there are some contexts in which operating on a 'poly_int' is
  not possible or does not make sense.  One example is when handling
  static initializers, since no current target supports the concept of a
  variable-length static initializer.  In these situations, a reasonable
--- 10046,10052 ----
           return false;
         }
  
!  However, there are some contexts in which operating on a ‘poly_int’ is
  not possible or does not make sense.  One example is when handling
  static initializers, since no current target supports the concept of a
  variable-length static initializer.  In these situations, a reasonable
*************** fallback is:
*** 10065,10082 ****
           ...
         }
  
!  'poly_int' also provides some asserting functions like 'to_constant'.
  Please only use these functions if there is a good theoretical reason to
  believe that the assertion cannot fire.  For example, if some work is
  divided into an analysis phase and an implementation phase, the analysis
! phase might reject inputs that are not 'is_constant', in which case the
! implementation phase can reasonably use 'to_constant' on the remaining
  inputs.  The assertions should not be used to discover whether a
  condition ever occurs "in the field"; in other words, they should not be
  used to restrict code to constants at first, with the intention of only
! implementing a 'poly_int' version if a user hits the assertion.
  
!  If a particular asserting function like 'to_constant' is needed more
  than once for the same reason, it is probably worth adding a helper
  function or macro for that situation, so that the justification only
  needs to be given once.  For example:
--- 10065,10082 ----
           ...
         }
  
!  ‘poly_int’ also provides some asserting functions like ‘to_constant’.
  Please only use these functions if there is a good theoretical reason to
  believe that the assertion cannot fire.  For example, if some work is
  divided into an analysis phase and an implementation phase, the analysis
! phase might reject inputs that are not ‘is_constant’, in which case the
! implementation phase can reasonably use ‘to_constant’ on the remaining
  inputs.  The assertions should not be used to discover whether a
  condition ever occurs "in the field"; in other words, they should not be
  used to restrict code to constants at first, with the intention of only
! implementing a ‘poly_int’ version if a user hits the assertion.
  
!  If a particular asserting function like ‘to_constant’ is needed more
  than once for the same reason, it is probably worth adding a helper
  function or macro for that situation, so that the justification only
  needs to be given once.  For example:
*************** needs to be given once.  For example:
*** 10090,10117 ****
       #define vector_element_size(SIZE, NELTS) \
         (exact_div (SIZE, NELTS).to_constant ())
  
!  Target-specific code in 'config/CPU' only needs to handle non-constant
! 'poly_int's if 'NUM_POLY_INT_COEFFS' is greater than one.  For other
! targets, 'poly_int' degenerates to a compile-time constant and is often
  interchangable with a normal scalar integer.  There are two main
  exceptions:
  
!    * Sometimes an explicit cast to an integer type might be needed, such
!      as to resolve ambiguities in a '?:' expression, or when passing
!      values through '...' to things like print functions.
  
!    * Target macros are included in target-independent code and so do not
       have access to the implicit conversion to a scalar integer.  If
       this becomes a problem for a particular target macro, the possible
       solutions, in order of preference, are:
  
!         * Convert the target macro to a target hook (for all targets).
  
!         * Put the target's implementation of the target macro in its
!           'CPU.c' file and call it from the target macro in the 'CPU.h'
            file.
  
!         * Add 'to_constant ()' calls where necessary.  The previous
            option is preferable because it will help with any future
            conversion of the macro to a hook.
  
--- 10090,10117 ----
       #define vector_element_size(SIZE, NELTS) \
         (exact_div (SIZE, NELTS).to_constant ())
  
!  Target-specific code in ‘config/CPU’ only needs to handle non-constant
! ‘poly_int’s if ‘NUM_POLY_INT_COEFFS’ is greater than one.  For other
! targets, ‘poly_int’ degenerates to a compile-time constant and is often
  interchangable with a normal scalar integer.  There are two main
  exceptions:
  
!    • Sometimes an explicit cast to an integer type might be needed, such
!      as to resolve ambiguities in a ‘?:’ expression, or when passing
!      values through ‘...’ to things like print functions.
  
!    • Target macros are included in target-independent code and so do not
       have access to the implicit conversion to a scalar integer.  If
       this becomes a problem for a particular target macro, the possible
       solutions, in order of preference, are:
  
!         • Convert the target macro to a target hook (for all targets).
  
!         • Put the target's implementation of the target macro in its
!           ‘CPU.c’ file and call it from the target macro in the ‘CPU.h’
            file.
  
!         • Add ‘to_constant ()’ calls where necessary.  The previous
            option is preferable because it will help with any future
            conversion of the macro to a hook.
  
*************** The purpose of GENERIC is simply to prov
*** 10125,10137 ****
  of representing an entire function in trees.  To this end, it was
  necessary to add a few new tree codes to the back end, but almost
  everything was already there.  If you can express it with the codes in
! 'gcc/tree.def', it's GENERIC.
  
   Early on, there was a great deal of debate about how to think about
  statements in a tree IL.  In GENERIC, a statement is defined as any
  expression whose value, if any, is ignored.  A statement will always
! have 'TREE_SIDE_EFFECTS' set (or it will be discarded), but a
! non-statement expression may also have side effects.  A 'CALL_EXPR', for
  instance.
  
   It would be possible for some local optimizations to work on the
--- 10125,10137 ----
  of representing an entire function in trees.  To this end, it was
  necessary to add a few new tree codes to the back end, but almost
  everything was already there.  If you can express it with the codes in
! ‘gcc/tree.def’, it's GENERIC.
  
   Early on, there was a great deal of debate about how to think about
  statements in a tree IL.  In GENERIC, a statement is defined as any
  expression whose value, if any, is ignored.  A statement will always
! have ‘TREE_SIDE_EFFECTS’ set (or it will be discarded), but a
! non-statement expression may also have side effects.  A ‘CALL_EXPR’, for
  instance.
  
   It would be possible for some local optimizations to work on the
*************** GENERIC form of a function; indeed, the
*** 10139,10150 ****
  on GENERIC, but the current compiler performs inlining after lowering to
  GIMPLE (a restricted form described in the next section).  Indeed,
  currently the frontends perform this lowering before handing off to
! 'tree_rest_of_compilation', but this seems inelegant.
  
  * Menu:
  
  * Deficiencies::                Topics not yet covered in this document.
! * Tree overview::               All about 'tree's.
  * Types::                       Fundamental and aggregate types.
  * Declarations::                Type declarations and variables.
  * Attributes::                  Declaration and type attributes.
--- 10139,10150 ----
  on GENERIC, but the current compiler performs inlining after lowering to
  GIMPLE (a restricted form described in the next section).  Indeed,
  currently the frontends perform this lowering before handing off to
! ‘tree_rest_of_compilation’, but this seems inelegant.
  
  * Menu:
  
  * Deficiencies::                Topics not yet covered in this document.
! * Tree overview::               All about ‘tree’s.
  * Types::                       Fundamental and aggregate types.
  * Declarations::                Type declarations and variables.
  * Attributes::                  Declaration and type attributes.
*************** File: gccint.info,  Node: Tree overview,
*** 10170,10203 ****
  =============
  
  The central data structure used by the internal representation is the
! 'tree'.  These nodes, while all of the C type 'tree', are of many
! varieties.  A 'tree' is a pointer type, but the object to which it
  points may be of a variety of types.  From this point forward, we will
! refer to trees in ordinary type, rather than in 'this font', except when
! talking about the actual C type 'tree'.
  
   You can tell what kind of node a particular tree is by using the
! 'TREE_CODE' macro.  Many, many macros take trees as input and return
  trees as output.  However, most macros require a certain kind of tree
  node as input.  In other words, there is a type-system for trees, but it
  is not reflected in the C type-system.
  
!  For safety, it is useful to configure GCC with '--enable-checking'.
  Although this results in a significant performance penalty (since all
  tree types are checked at run-time), and is therefore inappropriate in a
  release version, it is extremely helpful during the development process.
  
   Many macros behave as predicates.  Many, although not all, of these
! predicates end in '_P'.  Do not rely on the result type of these macros
  being of any particular type.  You may, however, rely on the fact that
! the type can be compared to '0', so that statements like
       if (TEST_P (t) && !TEST_P (y))
         x = 1;
  and
       int i = (TEST_P (t) != 0);
! are legal.  Macros that return 'int' values now may be changed to return
! 'tree' values, or other pointers in the future.  Even those that
! continue to return 'int' may return multiple nonzero codes where
  previously they returned only zero and one.  Therefore, you should not
  write code like
       if (TEST_P (t) == 1)
--- 10170,10203 ----
  =============
  
  The central data structure used by the internal representation is the
! ‘tree’.  These nodes, while all of the C type ‘tree’, are of many
! varieties.  A ‘tree’ is a pointer type, but the object to which it
  points may be of a variety of types.  From this point forward, we will
! refer to trees in ordinary type, rather than in ‘this font’, except when
! talking about the actual C type ‘tree’.
  
   You can tell what kind of node a particular tree is by using the
! ‘TREE_CODE’ macro.  Many, many macros take trees as input and return
  trees as output.  However, most macros require a certain kind of tree
  node as input.  In other words, there is a type-system for trees, but it
  is not reflected in the C type-system.
  
!  For safety, it is useful to configure GCC with ‘--enable-checking’.
  Although this results in a significant performance penalty (since all
  tree types are checked at run-time), and is therefore inappropriate in a
  release version, it is extremely helpful during the development process.
  
   Many macros behave as predicates.  Many, although not all, of these
! predicates end in ‘_P’.  Do not rely on the result type of these macros
  being of any particular type.  You may, however, rely on the fact that
! the type can be compared to ‘0’, so that statements like
       if (TEST_P (t) && !TEST_P (y))
         x = 1;
  and
       int i = (TEST_P (t) != 0);
! are legal.  Macros that return ‘int’ values now may be changed to return
! ‘tree’ values, or other pointers in the future.  Even those that
! continue to return ‘int’ may return multiple nonzero codes where
  previously they returned only zero and one.  Therefore, you should not
  write code like
       if (TEST_P (t) == 1)
*************** made up entirely of uppercase letters ma
*** 10214,10230 ****
  than once.  You may assume that a macro or function whose name is made
  up entirely of lowercase letters will evaluate its arguments only once.
  
!  The 'error_mark_node' is a special tree.  Its tree code is
! 'ERROR_MARK', but since there is only ever one node with that code, the
! usual practice is to compare the tree against 'error_mark_node'.  (This
  test is just a test for pointer equality.)  If an error has occurred
! during front-end processing the flag 'errorcount' will be set.  If the
  front end has encountered code it cannot handle, it will issue a message
! to the user and set 'sorrycount'.  When these flags are set, any macro
  or function which normally returns a tree of a particular kind may
! instead return the 'error_mark_node'.  Thus, if you intend to do any
  processing of erroneous code, you must be prepared to deal with the
! 'error_mark_node'.
  
   Occasionally, a particular tree slot (like an operand to an expression,
  or a particular field in a declaration) will be referred to as "reserved
--- 10214,10230 ----
  than once.  You may assume that a macro or function whose name is made
  up entirely of lowercase letters will evaluate its arguments only once.
  
!  The ‘error_mark_node’ is a special tree.  Its tree code is
! ‘ERROR_MARK’, but since there is only ever one node with that code, the
! usual practice is to compare the tree against ‘error_mark_node’.  (This
  test is just a test for pointer equality.)  If an error has occurred
! during front-end processing the flag ‘errorcount’ will be set.  If the
  front end has encountered code it cannot handle, it will issue a message
! to the user and set ‘sorrycount’.  When these flags are set, any macro
  or function which normally returns a tree of a particular kind may
! instead return the ‘error_mark_node’.  Thus, if you intend to do any
  processing of erroneous code, you must be prepared to deal with the
! ‘error_mark_node’.
  
   Occasionally, a particular tree slot (like an operand to an expression,
  or a particular field in a declaration) will be referred to as "reserved
*************** File: gccint.info,  Node: Macros and Fun
*** 10252,10279 ****
  11.2.1 Trees
  ------------
  
! All GENERIC trees have two fields in common.  First, 'TREE_CHAIN' is a
  pointer that can be used as a singly-linked list to other trees.  The
! other is 'TREE_TYPE'.  Many trees store the type of an expression or
  declaration in this field.
  
   These are some other functions for handling trees:
  
! 'tree_size'
       Return the number of bytes a tree takes.
  
! 'build0'
! 'build1'
! 'build2'
! 'build3'
! 'build4'
! 'build5'
! 'build6'
  
       These functions build a tree and supply values to put in each
!      parameter.  The basic signature is 'code, type, [operands]'.
!      'code' is the 'TREE_CODE', and 'type' is a tree representing the
!      'TREE_TYPE'.  These are followed by the operands, each of which is
       also a tree.
  
  
--- 10252,10279 ----
  11.2.1 Trees
  ------------
  
! All GENERIC trees have two fields in common.  First, ‘TREE_CHAIN’ is a
  pointer that can be used as a singly-linked list to other trees.  The
! other is ‘TREE_TYPE’.  Many trees store the type of an expression or
  declaration in this field.
  
   These are some other functions for handling trees:
  
! ‘tree_size’
       Return the number of bytes a tree takes.
  
! ‘build0’
! ‘build1’
! ‘build2’
! ‘build3’
! ‘build4’
! ‘build5’
! ‘build6’
  
       These functions build a tree and supply values to put in each
!      parameter.  The basic signature is ‘code, type, [operands]’.
!      ‘code’ is the ‘TREE_CODE’, and ‘type’ is a tree representing the
!      ‘TREE_TYPE’.  These are followed by the operands, each of which is
       also a tree.
  
  
*************** File: gccint.info,  Node: Identifiers,
*** 10282,10318 ****
  11.2.2 Identifiers
  ------------------
  
! An 'IDENTIFIER_NODE' represents a slightly more general concept than the
  standard C or C++ concept of identifier.  In particular, an
! 'IDENTIFIER_NODE' may contain a '$', or other extraordinary characters.
  
!  There are never two distinct 'IDENTIFIER_NODE's representing the same
  identifier.  Therefore, you may use pointer equality to compare
! 'IDENTIFIER_NODE's, rather than using a routine like 'strcmp'.  Use
! 'get_identifier' to obtain the unique 'IDENTIFIER_NODE' for a supplied
  string.
  
   You can use the following macros to access identifiers:
! 'IDENTIFIER_POINTER'
!      The string represented by the identifier, represented as a 'char*'.
!      This string is always 'NUL'-terminated, and contains no embedded
!      'NUL' characters.
  
! 'IDENTIFIER_LENGTH'
!      The length of the string returned by 'IDENTIFIER_POINTER', not
!      including the trailing 'NUL'.  This value of 'IDENTIFIER_LENGTH
!      (x)' is always the same as 'strlen (IDENTIFIER_POINTER (x))'.
  
! 'IDENTIFIER_OPNAME_P'
       This predicate holds if the identifier represents the name of an
       overloaded operator.  In this case, you should not depend on the
!      contents of either the 'IDENTIFIER_POINTER' or the
!      'IDENTIFIER_LENGTH'.
  
! 'IDENTIFIER_TYPENAME_P'
       This predicate holds if the identifier represents the name of a
!      user-defined conversion operator.  In this case, the 'TREE_TYPE' of
!      the 'IDENTIFIER_NODE' holds the type to which the conversion
       operator converts.
  
  
--- 10282,10318 ----
  11.2.2 Identifiers
  ------------------
  
! An ‘IDENTIFIER_NODE’ represents a slightly more general concept than the
  standard C or C++ concept of identifier.  In particular, an
! ‘IDENTIFIER_NODE’ may contain a ‘$’, or other extraordinary characters.
  
!  There are never two distinct ‘IDENTIFIER_NODE’s representing the same
  identifier.  Therefore, you may use pointer equality to compare
! ‘IDENTIFIER_NODE’s, rather than using a routine like ‘strcmp’.  Use
! ‘get_identifier’ to obtain the unique ‘IDENTIFIER_NODE’ for a supplied
  string.
  
   You can use the following macros to access identifiers:
! ‘IDENTIFIER_POINTER’
!      The string represented by the identifier, represented as a ‘char*’.
!      This string is always ‘NUL’-terminated, and contains no embedded
!      ‘NUL’ characters.
  
! ‘IDENTIFIER_LENGTH’
!      The length of the string returned by ‘IDENTIFIER_POINTER’, not
!      including the trailing ‘NUL’.  This value of ‘IDENTIFIER_LENGTH
!      (x)’ is always the same as ‘strlen (IDENTIFIER_POINTER (x))’.
  
! ‘IDENTIFIER_OPNAME_P’
       This predicate holds if the identifier represents the name of an
       overloaded operator.  In this case, you should not depend on the
!      contents of either the ‘IDENTIFIER_POINTER’ or the
!      ‘IDENTIFIER_LENGTH’.
  
! ‘IDENTIFIER_TYPENAME_P’
       This predicate holds if the identifier represents the name of a
!      user-defined conversion operator.  In this case, the ‘TREE_TYPE’ of
!      the ‘IDENTIFIER_NODE’ holds the type to which the conversion
       operator converts.
  
  
*************** File: gccint.info,  Node: Containers,  P
*** 10322,10341 ****
  -----------------
  
  Two common container data structures can be represented directly with
! tree nodes.  A 'TREE_LIST' is a singly linked list containing two trees
! per node.  These are the 'TREE_PURPOSE' and 'TREE_VALUE' of each node.
! (Often, the 'TREE_PURPOSE' contains some kind of tag, or additional
! information, while the 'TREE_VALUE' contains the majority of the
! payload.  In other cases, the 'TREE_PURPOSE' is simply 'NULL_TREE',
! while in still others both the 'TREE_PURPOSE' and 'TREE_VALUE' are of
! equal stature.)  Given one 'TREE_LIST' node, the next node is found by
! following the 'TREE_CHAIN'.  If the 'TREE_CHAIN' is 'NULL_TREE', then
  you have reached the end of the list.
  
!  A 'TREE_VEC' is a simple vector.  The 'TREE_VEC_LENGTH' is an integer
  (not a tree) giving the number of nodes in the vector.  The nodes
! themselves are accessed using the 'TREE_VEC_ELT' macro, which takes two
! arguments.  The first is the 'TREE_VEC' in question; the second is an
  integer indicating which element in the vector is desired.  The elements
  are indexed from zero.
  
--- 10322,10341 ----
  -----------------
  
  Two common container data structures can be represented directly with
! tree nodes.  A ‘TREE_LIST’ is a singly linked list containing two trees
! per node.  These are the ‘TREE_PURPOSE’ and ‘TREE_VALUE’ of each node.
! (Often, the ‘TREE_PURPOSE’ contains some kind of tag, or additional
! information, while the ‘TREE_VALUE’ contains the majority of the
! payload.  In other cases, the ‘TREE_PURPOSE’ is simply ‘NULL_TREE’,
! while in still others both the ‘TREE_PURPOSE’ and ‘TREE_VALUE’ are of
! equal stature.)  Given one ‘TREE_LIST’ node, the next node is found by
! following the ‘TREE_CHAIN’.  If the ‘TREE_CHAIN’ is ‘NULL_TREE’, then
  you have reached the end of the list.
  
!  A ‘TREE_VEC’ is a simple vector.  The ‘TREE_VEC_LENGTH’ is an integer
  (not a tree) giving the number of nodes in the vector.  The nodes
! themselves are accessed using the ‘TREE_VEC_ELT’ macro, which takes two
! arguments.  The first is the ‘TREE_VEC’ in question; the second is an
  integer indicating which element in the vector is desired.  The elements
  are indexed from zero.
  
*************** that there is exactly one tree node corr
*** 10350,10601 ****
  are often multiple nodes corresponding to the same type.
  
   For the most part, different kinds of types have different tree codes.
! (For example, pointer types use a 'POINTER_TYPE' code while arrays use
! an 'ARRAY_TYPE' code.)  However, pointers to member functions use the
! 'RECORD_TYPE' code.  Therefore, when writing a 'switch' statement that
  depends on the code associated with a particular type, you should take
! care to handle pointers to member functions under the 'RECORD_TYPE' case
  label.
  
   The following functions and macros deal with cv-qualification of types:
! 'TYPE_MAIN_VARIANT'
       This macro returns the unqualified version of a type.  It may be
       applied to an unqualified type, but it is not always the identity
       function in that case.
  
   A few other macros and functions are usable with all types:
! 'TYPE_SIZE'
       The number of bits required to represent the type, represented as
!      an 'INTEGER_CST'.  For an incomplete type, 'TYPE_SIZE' will be
!      'NULL_TREE'.
  
! 'TYPE_ALIGN'
!      The alignment of the type, in bits, represented as an 'int'.
  
! 'TYPE_NAME'
!      This macro returns a declaration (in the form of a 'TYPE_DECL') for
!      the type.  (Note this macro does _not_ return an 'IDENTIFIER_NODE',
       as you might expect, given its name!)  You can look at the
!      'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the
!      type.  The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a
       built-in type, the result of a typedef, or a named class type.
  
! 'TYPE_CANONICAL'
       This macro returns the "canonical" type for the given type node.
       Canonical types are used to improve performance in the C++ and
       Objective-C++ front ends by allowing efficient comparison between
!      two type nodes in 'same_type_p': if the 'TYPE_CANONICAL' values of
       the types are equal, the types are equivalent; otherwise, the types
       are not equivalent.  The notion of equivalence for canonical types
       is the same as the notion of type equivalence in the language
       itself.  For instance,
  
!      When 'TYPE_CANONICAL' is 'NULL_TREE', there is no canonical type
       for the given type node.  In this case, comparison between this
       type and any other type requires the compiler to perform a deep,
       "structural" comparison to see if the two type nodes have the same
       form and properties.
  
       The canonical type for a node is always the most fundamental type
!      in the equivalence class of types.  For instance, 'int' is its own
!      canonical type.  A typedef 'I' of 'int' will have 'int' as its
!      canonical type.  Similarly, 'I*' and a typedef 'IP' (defined to
!      'I*') will has 'int*' as their canonical type.  When building a new
!      type node, be sure to set 'TYPE_CANONICAL' to the appropriate
       canonical type.  If the new type is a compound type (built from
       other types), and any of those other types require structural
!      equality, use 'SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the new
       type also requires structural equality.  Finally, if for some
!      reason you cannot guarantee that 'TYPE_CANONICAL' will point to the
!      canonical type, use 'SET_TYPE_STRUCTURAL_EQUALITY' to make sure
       that the new type-and any type constructed based on it-requires
       structural equality.  If you suspect that the canonical type system
!      is miscomparing types, pass '--param verify-canonical-types=1' to
!      the compiler or configure with '--enable-checking' to force the
       compiler to verify its canonical-type comparisons against the
       structural comparisons; the compiler will then print any warnings
       if the canonical types miscompare.
  
! 'TYPE_STRUCTURAL_EQUALITY_P'
       This predicate holds when the node requires structural equality
!      checks, e.g., when 'TYPE_CANONICAL' is 'NULL_TREE'.
  
! 'SET_TYPE_STRUCTURAL_EQUALITY'
       This macro states that the type node it is given requires
!      structural equality checks, e.g., it sets 'TYPE_CANONICAL' to
!      'NULL_TREE'.
  
! 'same_type_p'
       This predicate takes two types as input, and holds if they are the
!      same type.  For example, if one type is a 'typedef' for the other,
!      or both are 'typedef's for the same type.  This predicate also
       holds if the two trees given as input are simply copies of one
       another; i.e., there is no difference between them at the source
       level, but, for whatever reason, a duplicate has been made in the
!      representation.  You should never use '==' (pointer equality) to
!      compare types; always use 'same_type_p' instead.
  
   Detailed below are the various kinds of types, and the macros that can
  be used to access them.  Although other kinds of types are used
  elsewhere in G++, the types described here are the only ones that you
  will encounter while examining the intermediate representation.
  
! 'VOID_TYPE'
!      Used to represent the 'void' type.
  
! 'INTEGER_TYPE'
!      Used to represent the various integral types, including 'char',
!      'short', 'int', 'long', and 'long long'.  This code is not used for
!      enumeration types, nor for the 'bool' type.  The 'TYPE_PRECISION'
       is the number of bits used in the representation, represented as an
!      'unsigned int'.  (Note that in the general case this is not the
!      same value as 'TYPE_SIZE'; suppose that there were a 24-bit integer
       type, but that alignment requirements for the ABI required 32-bit
!      alignment.  Then, 'TYPE_SIZE' would be an 'INTEGER_CST' for 32,
!      while 'TYPE_PRECISION' would be 24.)  The integer type is unsigned
!      if 'TYPE_UNSIGNED' holds; otherwise, it is signed.
  
!      The 'TYPE_MIN_VALUE' is an 'INTEGER_CST' for the smallest integer
       that may be represented by this type.  Similarly, the
!      'TYPE_MAX_VALUE' is an 'INTEGER_CST' for the largest integer that
       may be represented by this type.
  
! 'REAL_TYPE'
!      Used to represent the 'float', 'double', and 'long double' types.
       The number of bits in the floating-point representation is given by
!      'TYPE_PRECISION', as in the 'INTEGER_TYPE' case.
  
! 'FIXED_POINT_TYPE'
!      Used to represent the 'short _Fract', '_Fract', 'long _Fract',
!      'long long _Fract', 'short _Accum', '_Accum', 'long _Accum', and
!      'long long _Accum' types.  The number of bits in the fixed-point
!      representation is given by 'TYPE_PRECISION', as in the
!      'INTEGER_TYPE' case.  There may be padding bits, fractional bits
       and integral bits.  The number of fractional bits is given by
!      'TYPE_FBIT', and the number of integral bits is given by
!      'TYPE_IBIT'.  The fixed-point type is unsigned if 'TYPE_UNSIGNED'
       holds; otherwise, it is signed.  The fixed-point type is saturating
!      if 'TYPE_SATURATING' holds; otherwise, it is not saturating.
  
! 'COMPLEX_TYPE'
!      Used to represent GCC built-in '__complex__' data types.  The
!      'TREE_TYPE' is the type of the real and imaginary parts.
  
! 'ENUMERAL_TYPE'
!      Used to represent an enumeration type.  The 'TYPE_PRECISION' gives
!      (as an 'int'), the number of bits used to represent the type.  If
!      there are no negative enumeration constants, 'TYPE_UNSIGNED' will
       hold.  The minimum and maximum enumeration constants may be
!      obtained with 'TYPE_MIN_VALUE' and 'TYPE_MAX_VALUE', respectively;
!      each of these macros returns an 'INTEGER_CST'.
  
       The actual enumeration constants themselves may be obtained by
!      looking at the 'TYPE_VALUES'.  This macro will return a
!      'TREE_LIST', containing the constants.  The 'TREE_PURPOSE' of each
!      node will be an 'IDENTIFIER_NODE' giving the name of the constant;
!      the 'TREE_VALUE' will be an 'INTEGER_CST' giving the value assigned
       to that constant.  These constants will appear in the order in
!      which they were declared.  The 'TREE_TYPE' of each of these
       constants will be the type of enumeration type itself.
  
! 'OPAQUE_TYPE'
!      Used for things that have a 'MODE_OPAQUE' mode class in the
       backend.  Opaque types have a size and precision, and can be held
       in memory or registers.  They are used when we do not want the
       compiler to make assumptions about the availability of other
       operations as would happen with integer types.
  
! 'BOOLEAN_TYPE'
!      Used to represent the 'bool' type.
  
! 'POINTER_TYPE'
       Used to represent pointer types, and pointer to data member types.
!      The 'TREE_TYPE' gives the type to which this type points.
  
! 'REFERENCE_TYPE'
!      Used to represent reference types.  The 'TREE_TYPE' gives the type
       to which this type refers.
  
! 'FUNCTION_TYPE'
       Used to represent the type of non-member functions and of static
!      member functions.  The 'TREE_TYPE' gives the return type of the
!      function.  The 'TYPE_ARG_TYPES' are a 'TREE_LIST' of the argument
!      types.  The 'TREE_VALUE' of each node in this list is the type of
!      the corresponding argument; the 'TREE_PURPOSE' is an expression for
       the default argument value, if any.  If the last node in the list
!      is 'void_list_node' (a 'TREE_LIST' node whose 'TREE_VALUE' is the
!      'void_type_node'), then functions of this type do not take variable
       arguments.  Otherwise, they do take a variable number of arguments.
  
!      Note that in C (but not in C++) a function declared like 'void f()'
       is an unprototyped function taking a variable number of arguments;
!      the 'TYPE_ARG_TYPES' of such a function will be 'NULL'.
  
! 'METHOD_TYPE'
       Used to represent the type of a non-static member function.  Like a
!      'FUNCTION_TYPE', the return type is given by the 'TREE_TYPE'.  The
!      type of '*this', i.e., the class of which functions of this type
!      are a member, is given by the 'TYPE_METHOD_BASETYPE'.  The
!      'TYPE_ARG_TYPES' is the parameter list, as for a 'FUNCTION_TYPE',
!      and includes the 'this' argument.
  
! 'ARRAY_TYPE'
!      Used to represent array types.  The 'TREE_TYPE' gives the type of
       the elements in the array.  If the array-bound is present in the
!      type, the 'TYPE_DOMAIN' is an 'INTEGER_TYPE' whose 'TYPE_MIN_VALUE'
!      and 'TYPE_MAX_VALUE' will be the lower and upper bounds of the
!      array, respectively.  The 'TYPE_MIN_VALUE' will always be an
!      'INTEGER_CST' for zero, while the 'TYPE_MAX_VALUE' will be one less
       than the number of elements in the array, i.e., the highest value
       which may be used to index an element in the array.
  
! 'RECORD_TYPE'
!      Used to represent 'struct' and 'class' types, as well as pointers
       to member functions and similar constructs in other languages.
!      'TYPE_FIELDS' contains the items contained in this type, each of
!      which can be a 'FIELD_DECL', 'VAR_DECL', 'CONST_DECL', or
!      'TYPE_DECL'.  You may not make any assumptions about the ordering
       of the fields in the type or whether one or more of them overlap.
  
! 'UNION_TYPE'
!      Used to represent 'union' types.  Similar to 'RECORD_TYPE' except
!      that all 'FIELD_DECL' nodes in 'TYPE_FIELD' start at bit position
       zero.
  
! 'QUAL_UNION_TYPE'
       Used to represent part of a variant record in Ada.  Similar to
!      'UNION_TYPE' except that each 'FIELD_DECL' has a 'DECL_QUALIFIER'
       field, which contains a boolean expression that indicates whether
       the field is present in the object.  The type will only have one
!      field, so each field's 'DECL_QUALIFIER' is only evaluated if none
!      of the expressions in the previous fields in 'TYPE_FIELDS' are
       nonzero.  Normally these expressions will reference a field in the
!      outer object using a 'PLACEHOLDER_EXPR'.
  
! 'LANG_TYPE'
       This node is used to represent a language-specific type.  The front
       end must handle it.
  
! 'OFFSET_TYPE'
       This node is used to represent a pointer-to-data member.  For a
!      data member 'X::m' the 'TYPE_OFFSET_BASETYPE' is 'X' and the
!      'TREE_TYPE' is the type of 'm'.
  
   There are variables whose values represent some of the basic types.
  These include:
! 'void_type_node'
!      A node for 'void'.
  
! 'integer_type_node'
!      A node for 'int'.
  
! 'unsigned_type_node.'
!      A node for 'unsigned int'.
  
! 'char_type_node.'
!      A node for 'char'.
  It may sometimes be useful to compare one of these variables with a type
! in hand, using 'same_type_p'.
  
  
  File: gccint.info,  Node: Declarations,  Next: Attributes,  Prev: Types,  Up: GENERIC
--- 10350,10601 ----
  are often multiple nodes corresponding to the same type.
  
   For the most part, different kinds of types have different tree codes.
! (For example, pointer types use a ‘POINTER_TYPE’ code while arrays use
! an ‘ARRAY_TYPE’ code.)  However, pointers to member functions use the
! ‘RECORD_TYPE’ code.  Therefore, when writing a ‘switch’ statement that
  depends on the code associated with a particular type, you should take
! care to handle pointers to member functions under the ‘RECORD_TYPE’ case
  label.
  
   The following functions and macros deal with cv-qualification of types:
! ‘TYPE_MAIN_VARIANT’
       This macro returns the unqualified version of a type.  It may be
       applied to an unqualified type, but it is not always the identity
       function in that case.
  
   A few other macros and functions are usable with all types:
! ‘TYPE_SIZE’
       The number of bits required to represent the type, represented as
!      an ‘INTEGER_CST’.  For an incomplete type, ‘TYPE_SIZE’ will be
!      ‘NULL_TREE’.
  
! ‘TYPE_ALIGN’
!      The alignment of the type, in bits, represented as an ‘int’.
  
! ‘TYPE_NAME’
!      This macro returns a declaration (in the form of a ‘TYPE_DECL’) for
!      the type.  (Note this macro does _not_ return an ‘IDENTIFIER_NODE’,
       as you might expect, given its name!)  You can look at the
!      ‘DECL_NAME’ of the ‘TYPE_DECL’ to obtain the actual name of the
!      type.  The ‘TYPE_NAME’ will be ‘NULL_TREE’ for a type that is not a
       built-in type, the result of a typedef, or a named class type.
  
! ‘TYPE_CANONICAL’
       This macro returns the "canonical" type for the given type node.
       Canonical types are used to improve performance in the C++ and
       Objective-C++ front ends by allowing efficient comparison between
!      two type nodes in ‘same_type_p’: if the ‘TYPE_CANONICAL’ values of
       the types are equal, the types are equivalent; otherwise, the types
       are not equivalent.  The notion of equivalence for canonical types
       is the same as the notion of type equivalence in the language
       itself.  For instance,
  
!      When ‘TYPE_CANONICAL’ is ‘NULL_TREE’, there is no canonical type
       for the given type node.  In this case, comparison between this
       type and any other type requires the compiler to perform a deep,
       "structural" comparison to see if the two type nodes have the same
       form and properties.
  
       The canonical type for a node is always the most fundamental type
!      in the equivalence class of types.  For instance, ‘int’ is its own
!      canonical type.  A typedef ‘I’ of ‘int’ will have ‘int’ as its
!      canonical type.  Similarly, ‘I*’ and a typedef ‘IP’ (defined to
!      ‘I*’) will has ‘int*’ as their canonical type.  When building a new
!      type node, be sure to set ‘TYPE_CANONICAL’ to the appropriate
       canonical type.  If the new type is a compound type (built from
       other types), and any of those other types require structural
!      equality, use ‘SET_TYPE_STRUCTURAL_EQUALITY’ to ensure that the new
       type also requires structural equality.  Finally, if for some
!      reason you cannot guarantee that ‘TYPE_CANONICAL’ will point to the
!      canonical type, use ‘SET_TYPE_STRUCTURAL_EQUALITY’ to make sure
       that the new type-and any type constructed based on it-requires
       structural equality.  If you suspect that the canonical type system
!      is miscomparing types, pass ‘--param verify-canonical-types=1’ to
!      the compiler or configure with ‘--enable-checking’ to force the
       compiler to verify its canonical-type comparisons against the
       structural comparisons; the compiler will then print any warnings
       if the canonical types miscompare.
  
! ‘TYPE_STRUCTURAL_EQUALITY_P’
       This predicate holds when the node requires structural equality
!      checks, e.g., when ‘TYPE_CANONICAL’ is ‘NULL_TREE’.
  
! ‘SET_TYPE_STRUCTURAL_EQUALITY’
       This macro states that the type node it is given requires
!      structural equality checks, e.g., it sets ‘TYPE_CANONICAL’ to
!      ‘NULL_TREE’.
  
! ‘same_type_p’
       This predicate takes two types as input, and holds if they are the
!      same type.  For example, if one type is a ‘typedef’ for the other,
!      or both are ‘typedef’s for the same type.  This predicate also
       holds if the two trees given as input are simply copies of one
       another; i.e., there is no difference between them at the source
       level, but, for whatever reason, a duplicate has been made in the
!      representation.  You should never use ‘==’ (pointer equality) to
!      compare types; always use ‘same_type_p’ instead.
  
   Detailed below are the various kinds of types, and the macros that can
  be used to access them.  Although other kinds of types are used
  elsewhere in G++, the types described here are the only ones that you
  will encounter while examining the intermediate representation.
  
! ‘VOID_TYPE’
!      Used to represent the ‘void’ type.
  
! ‘INTEGER_TYPE’
!      Used to represent the various integral types, including ‘char’,
!      ‘short’, ‘int’, ‘long’, and ‘long long’.  This code is not used for
!      enumeration types, nor for the ‘bool’ type.  The ‘TYPE_PRECISION’
       is the number of bits used in the representation, represented as an
!      ‘unsigned int’.  (Note that in the general case this is not the
!      same value as ‘TYPE_SIZE’; suppose that there were a 24-bit integer
       type, but that alignment requirements for the ABI required 32-bit
!      alignment.  Then, ‘TYPE_SIZE’ would be an ‘INTEGER_CST’ for 32,
!      while ‘TYPE_PRECISION’ would be 24.)  The integer type is unsigned
!      if ‘TYPE_UNSIGNED’ holds; otherwise, it is signed.
  
!      The ‘TYPE_MIN_VALUE’ is an ‘INTEGER_CST’ for the smallest integer
       that may be represented by this type.  Similarly, the
!      ‘TYPE_MAX_VALUE’ is an ‘INTEGER_CST’ for the largest integer that
       may be represented by this type.
  
! ‘REAL_TYPE’
!      Used to represent the ‘float’, ‘double’, and ‘long double’ types.
       The number of bits in the floating-point representation is given by
!      ‘TYPE_PRECISION’, as in the ‘INTEGER_TYPE’ case.
  
! ‘FIXED_POINT_TYPE’
!      Used to represent the ‘short _Fract’, ‘_Fract’, ‘long _Fract’,
!      ‘long long _Fract’, ‘short _Accum’, ‘_Accum’, ‘long _Accum’, and
!      ‘long long _Accum’ types.  The number of bits in the fixed-point
!      representation is given by ‘TYPE_PRECISION’, as in the
!      ‘INTEGER_TYPE’ case.  There may be padding bits, fractional bits
       and integral bits.  The number of fractional bits is given by
!      ‘TYPE_FBIT’, and the number of integral bits is given by
!      ‘TYPE_IBIT’.  The fixed-point type is unsigned if ‘TYPE_UNSIGNED’
       holds; otherwise, it is signed.  The fixed-point type is saturating
!      if ‘TYPE_SATURATING’ holds; otherwise, it is not saturating.
  
! ‘COMPLEX_TYPE’
!      Used to represent GCC built-in ‘__complex__’ data types.  The
!      ‘TREE_TYPE’ is the type of the real and imaginary parts.
  
! ‘ENUMERAL_TYPE’
!      Used to represent an enumeration type.  The ‘TYPE_PRECISION’ gives
!      (as an ‘int’), the number of bits used to represent the type.  If
!      there are no negative enumeration constants, ‘TYPE_UNSIGNED’ will
       hold.  The minimum and maximum enumeration constants may be
!      obtained with ‘TYPE_MIN_VALUE’ and ‘TYPE_MAX_VALUE’, respectively;
!      each of these macros returns an ‘INTEGER_CST’.
  
       The actual enumeration constants themselves may be obtained by
!      looking at the ‘TYPE_VALUES’.  This macro will return a
!      ‘TREE_LIST’, containing the constants.  The ‘TREE_PURPOSE’ of each
!      node will be an ‘IDENTIFIER_NODE’ giving the name of the constant;
!      the ‘TREE_VALUE’ will be an ‘INTEGER_CST’ giving the value assigned
       to that constant.  These constants will appear in the order in
!      which they were declared.  The ‘TREE_TYPE’ of each of these
       constants will be the type of enumeration type itself.
  
! ‘OPAQUE_TYPE’
!      Used for things that have a ‘MODE_OPAQUE’ mode class in the
       backend.  Opaque types have a size and precision, and can be held
       in memory or registers.  They are used when we do not want the
       compiler to make assumptions about the availability of other
       operations as would happen with integer types.
  
! ‘BOOLEAN_TYPE’
!      Used to represent the ‘bool’ type.
  
! ‘POINTER_TYPE’
       Used to represent pointer types, and pointer to data member types.
!      The ‘TREE_TYPE’ gives the type to which this type points.
  
! ‘REFERENCE_TYPE’
!      Used to represent reference types.  The ‘TREE_TYPE’ gives the type
       to which this type refers.
  
! ‘FUNCTION_TYPE’
       Used to represent the type of non-member functions and of static
!      member functions.  The ‘TREE_TYPE’ gives the return type of the
!      function.  The ‘TYPE_ARG_TYPES’ are a ‘TREE_LIST’ of the argument
!      types.  The ‘TREE_VALUE’ of each node in this list is the type of
!      the corresponding argument; the ‘TREE_PURPOSE’ is an expression for
       the default argument value, if any.  If the last node in the list
!      is ‘void_list_node’ (a ‘TREE_LIST’ node whose ‘TREE_VALUE’ is the
!      ‘void_type_node’), then functions of this type do not take variable
       arguments.  Otherwise, they do take a variable number of arguments.
  
!      Note that in C (but not in C++) a function declared like ‘void f()’
       is an unprototyped function taking a variable number of arguments;
!      the ‘TYPE_ARG_TYPES’ of such a function will be ‘NULL’.
  
! ‘METHOD_TYPE’
       Used to represent the type of a non-static member function.  Like a
!      ‘FUNCTION_TYPE’, the return type is given by the ‘TREE_TYPE’.  The
!      type of ‘*this’, i.e., the class of which functions of this type
!      are a member, is given by the ‘TYPE_METHOD_BASETYPE’.  The
!      ‘TYPE_ARG_TYPES’ is the parameter list, as for a ‘FUNCTION_TYPE’,
!      and includes the ‘this’ argument.
  
! ‘ARRAY_TYPE’
!      Used to represent array types.  The ‘TREE_TYPE’ gives the type of
       the elements in the array.  If the array-bound is present in the
!      type, the ‘TYPE_DOMAIN’ is an ‘INTEGER_TYPE’ whose ‘TYPE_MIN_VALUE’
!      and ‘TYPE_MAX_VALUE’ will be the lower and upper bounds of the
!      array, respectively.  The ‘TYPE_MIN_VALUE’ will always be an
!      ‘INTEGER_CST’ for zero, while the ‘TYPE_MAX_VALUE’ will be one less
       than the number of elements in the array, i.e., the highest value
       which may be used to index an element in the array.
  
! ‘RECORD_TYPE’
!      Used to represent ‘struct’ and ‘class’ types, as well as pointers
       to member functions and similar constructs in other languages.
!      ‘TYPE_FIELDS’ contains the items contained in this type, each of
!      which can be a ‘FIELD_DECL’, ‘VAR_DECL’, ‘CONST_DECL’, or
!      ‘TYPE_DECL’.  You may not make any assumptions about the ordering
       of the fields in the type or whether one or more of them overlap.
  
! ‘UNION_TYPE’
!      Used to represent ‘union’ types.  Similar to ‘RECORD_TYPE’ except
!      that all ‘FIELD_DECL’ nodes in ‘TYPE_FIELD’ start at bit position
       zero.
  
! ‘QUAL_UNION_TYPE’
       Used to represent part of a variant record in Ada.  Similar to
!      ‘UNION_TYPE’ except that each ‘FIELD_DECL’ has a ‘DECL_QUALIFIER’
       field, which contains a boolean expression that indicates whether
       the field is present in the object.  The type will only have one
!      field, so each field's ‘DECL_QUALIFIER’ is only evaluated if none
!      of the expressions in the previous fields in ‘TYPE_FIELDS’ are
       nonzero.  Normally these expressions will reference a field in the
!      outer object using a ‘PLACEHOLDER_EXPR’.
  
! ‘LANG_TYPE’
       This node is used to represent a language-specific type.  The front
       end must handle it.
  
! ‘OFFSET_TYPE’
       This node is used to represent a pointer-to-data member.  For a
!      data member ‘X::m’ the ‘TYPE_OFFSET_BASETYPE’ is ‘X’ and the
!      ‘TREE_TYPE’ is the type of ‘m’.
  
   There are variables whose values represent some of the basic types.
  These include:
! ‘void_type_node’
!      A node for ‘void’.
  
! ‘integer_type_node’
!      A node for ‘int’.
  
! ‘unsigned_type_node.’
!      A node for ‘unsigned int’.
  
! ‘char_type_node.’
!      A node for ‘char’.
  It may sometimes be useful to compare one of these variables with a type
! in hand, using ‘same_type_p’.
  
  
  File: gccint.info,  Node: Declarations,  Next: Attributes,  Prev: Types,  Up: GENERIC
*************** File: gccint.info,  Node: Declarations,
*** 10605,10611 ****
  
  This section covers the various kinds of declarations that appear in the
  internal representation, except for declarations of functions
! (represented by 'FUNCTION_DECL' nodes), which are described in *note
  Functions::.
  
  * Menu:
--- 10605,10611 ----
  
  This section covers the various kinds of declarations that appear in the
  internal representation, except for declarations of functions
! (represented by ‘FUNCTION_DECL’ nodes), which are described in *note
  Functions::.
  
  * Menu:
*************** File: gccint.info,  Node: Working with d
*** 10621,10743 ****
  --------------------------------
  
  Some macros can be used with any kind of declaration.  These include:
! 'DECL_NAME'
!      This macro returns an 'IDENTIFIER_NODE' giving the name of the
       entity.
  
! 'TREE_TYPE'
       This macro returns the type of the entity declared.
  
! 'EXPR_FILENAME'
       This macro returns the name of the file in which the entity was
!      declared, as a 'char*'.  For an entity declared implicitly by the
!      compiler (like '__builtin_memcpy'), this will be the string
!      '""'.
  
! 'EXPR_LINENO'
       This macro returns the line number at which the entity was
!      declared, as an 'int'.
  
! 'DECL_ARTIFICIAL'
       This predicate holds if the declaration was implicitly generated by
       the compiler.  For example, this predicate will hold of an
!      implicitly declared member function, or of the 'TYPE_DECL'
       implicitly generated for a class type.  Recall that in C++ code
       like:
            struct S {};
       is roughly equivalent to C code like:
            struct S {};
            typedef struct S S;
!      The implicitly generated 'typedef' declaration is represented by a
!      'TYPE_DECL' for which 'DECL_ARTIFICIAL' holds.
  
   The various kinds of declarations include:
! 'LABEL_DECL'
       These nodes are used to represent labels in function bodies.  For
       more information, see *note Functions::.  These nodes only appear
       in block scopes.
  
! 'CONST_DECL'
       These nodes are used to represent enumeration constants.  The value
!      of the constant is given by 'DECL_INITIAL' which will be an
!      'INTEGER_CST' with the same type as the 'TREE_TYPE' of the
!      'CONST_DECL', i.e., an 'ENUMERAL_TYPE'.
  
! 'RESULT_DECL'
       These nodes represent the value returned by a function.  When a
!      value is assigned to a 'RESULT_DECL', that indicates that the value
       should be returned, via bitwise copy, by the function.  You can use
!      'DECL_SIZE' and 'DECL_ALIGN' on a 'RESULT_DECL', just as with a
!      'VAR_DECL'.
  
! 'TYPE_DECL'
!      These nodes represent 'typedef' declarations.  The 'TREE_TYPE' is
!      the type declared to have the name given by 'DECL_NAME'.  In some
       cases, there is no associated name.
  
! 'VAR_DECL'
       These nodes represent variables with namespace or block scope, as
!      well as static data members.  The 'DECL_SIZE' and 'DECL_ALIGN' are
!      analogous to 'TYPE_SIZE' and 'TYPE_ALIGN'.  For a declaration, you
!      should always use the 'DECL_SIZE' and 'DECL_ALIGN' rather than the
!      'TYPE_SIZE' and 'TYPE_ALIGN' given by the 'TREE_TYPE', since
       special attributes may have been applied to the variable to give it
       a particular size and alignment.  You may use the predicates
!      'DECL_THIS_STATIC' or 'DECL_THIS_EXTERN' to test whether the
!      storage class specifiers 'static' or 'extern' were used to declare
       a variable.
  
       If this variable is initialized (but does not require a
!      constructor), the 'DECL_INITIAL' will be an expression for the
       initializer.  The initializer should be evaluated, and a bitwise
!      copy into the variable performed.  If the 'DECL_INITIAL' is the
!      'error_mark_node', there is an initializer, but it is given by an
       explicit statement later in the code; no bitwise copy is required.
  
       GCC provides an extension that allows either automatic variables,
       or global variables, to be placed in particular registers.  This
!      extension is being used for a particular 'VAR_DECL' if
!      'DECL_REGISTER' holds for the 'VAR_DECL', and if
!      'DECL_ASSEMBLER_NAME' is not equal to 'DECL_NAME'.  In that case,
!      'DECL_ASSEMBLER_NAME' is the name of the register into which the
       variable will be placed.
  
! 'PARM_DECL'
       Used to represent a parameter to a function.  Treat these nodes
!      similarly to 'VAR_DECL' nodes.  These nodes only appear in the
!      'DECL_ARGUMENTS' for a 'FUNCTION_DECL'.
  
!      The 'DECL_ARG_TYPE' for a 'PARM_DECL' is the type that will
       actually be used when a value is passed to this function.  It may
!      be a wider type than the 'TREE_TYPE' of the parameter; for example,
!      the ordinary type might be 'short' while the 'DECL_ARG_TYPE' is
!      'int'.
  
! 'DEBUG_EXPR_DECL'
       Used to represent an anonymous debug-information temporary created
       to hold an expression as it is optimized away, so that its value
       can be referenced in debug bind statements.
  
! 'FIELD_DECL'
!      These nodes represent non-static data members.  The 'DECL_SIZE' and
!      'DECL_ALIGN' behave as for 'VAR_DECL' nodes.  The position of the
       field within the parent record is specified by a combination of
!      three attributes.  'DECL_FIELD_OFFSET' is the position, counting in
!      bytes, of the 'DECL_OFFSET_ALIGN'-bit sized word containing the bit
       of the field closest to the beginning of the structure.
!      'DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the
       field within this word; this may be nonzero even for fields that
!      are not bit-fields, since 'DECL_OFFSET_ALIGN' may be greater than
       the natural alignment of the field's type.
  
!      If 'DECL_C_BIT_FIELD' holds, this field is a bit-field.  In a
!      bit-field, 'DECL_BIT_FIELD_TYPE' also contains the type that was
       originally specified for it, while DECL_TYPE may be a modified type
       with lesser precision, according to the size of the bit field.
  
! 'NAMESPACE_DECL'
       Namespaces provide a name hierarchy for other declarations.  They
!      appear in the 'DECL_CONTEXT' of other '_DECL' nodes.
  
  
  File: gccint.info,  Node: Internal structure,  Prev: Working with declarations,  Up: Declarations
--- 10621,10743 ----
  --------------------------------
  
  Some macros can be used with any kind of declaration.  These include:
! ‘DECL_NAME’
!      This macro returns an ‘IDENTIFIER_NODE’ giving the name of the
       entity.
  
! ‘TREE_TYPE’
       This macro returns the type of the entity declared.
  
! ‘EXPR_FILENAME’
       This macro returns the name of the file in which the entity was
!      declared, as a ‘char*’.  For an entity declared implicitly by the
!      compiler (like ‘__builtin_memcpy’), this will be the string
!      ‘""’.
  
! ‘EXPR_LINENO’
       This macro returns the line number at which the entity was
!      declared, as an ‘int’.
  
! ‘DECL_ARTIFICIAL’
       This predicate holds if the declaration was implicitly generated by
       the compiler.  For example, this predicate will hold of an
!      implicitly declared member function, or of the ‘TYPE_DECL’
       implicitly generated for a class type.  Recall that in C++ code
       like:
            struct S {};
       is roughly equivalent to C code like:
            struct S {};
            typedef struct S S;
!      The implicitly generated ‘typedef’ declaration is represented by a
!      ‘TYPE_DECL’ for which ‘DECL_ARTIFICIAL’ holds.
  
   The various kinds of declarations include:
! ‘LABEL_DECL’
       These nodes are used to represent labels in function bodies.  For
       more information, see *note Functions::.  These nodes only appear
       in block scopes.
  
! ‘CONST_DECL’
       These nodes are used to represent enumeration constants.  The value
!      of the constant is given by ‘DECL_INITIAL’ which will be an
!      ‘INTEGER_CST’ with the same type as the ‘TREE_TYPE’ of the
!      ‘CONST_DECL’, i.e., an ‘ENUMERAL_TYPE’.
  
! ‘RESULT_DECL’
       These nodes represent the value returned by a function.  When a
!      value is assigned to a ‘RESULT_DECL’, that indicates that the value
       should be returned, via bitwise copy, by the function.  You can use
!      ‘DECL_SIZE’ and ‘DECL_ALIGN’ on a ‘RESULT_DECL’, just as with a
!      ‘VAR_DECL’.
  
! ‘TYPE_DECL’
!      These nodes represent ‘typedef’ declarations.  The ‘TREE_TYPE’ is
!      the type declared to have the name given by ‘DECL_NAME’.  In some
       cases, there is no associated name.
  
! ‘VAR_DECL’
       These nodes represent variables with namespace or block scope, as
!      well as static data members.  The ‘DECL_SIZE’ and ‘DECL_ALIGN’ are
!      analogous to ‘TYPE_SIZE’ and ‘TYPE_ALIGN’.  For a declaration, you
!      should always use the ‘DECL_SIZE’ and ‘DECL_ALIGN’ rather than the
!      ‘TYPE_SIZE’ and ‘TYPE_ALIGN’ given by the ‘TREE_TYPE’, since
       special attributes may have been applied to the variable to give it
       a particular size and alignment.  You may use the predicates
!      ‘DECL_THIS_STATIC’ or ‘DECL_THIS_EXTERN’ to test whether the
!      storage class specifiers ‘static’ or ‘extern’ were used to declare
       a variable.
  
       If this variable is initialized (but does not require a
!      constructor), the ‘DECL_INITIAL’ will be an expression for the
       initializer.  The initializer should be evaluated, and a bitwise
!      copy into the variable performed.  If the ‘DECL_INITIAL’ is the
!      ‘error_mark_node’, there is an initializer, but it is given by an
       explicit statement later in the code; no bitwise copy is required.
  
       GCC provides an extension that allows either automatic variables,
       or global variables, to be placed in particular registers.  This
!      extension is being used for a particular ‘VAR_DECL’ if
!      ‘DECL_REGISTER’ holds for the ‘VAR_DECL’, and if
!      ‘DECL_ASSEMBLER_NAME’ is not equal to ‘DECL_NAME’.  In that case,
!      ‘DECL_ASSEMBLER_NAME’ is the name of the register into which the
       variable will be placed.
  
! ‘PARM_DECL’
       Used to represent a parameter to a function.  Treat these nodes
!      similarly to ‘VAR_DECL’ nodes.  These nodes only appear in the
!      ‘DECL_ARGUMENTS’ for a ‘FUNCTION_DECL’.
  
!      The ‘DECL_ARG_TYPE’ for a ‘PARM_DECL’ is the type that will
       actually be used when a value is passed to this function.  It may
!      be a wider type than the ‘TREE_TYPE’ of the parameter; for example,
!      the ordinary type might be ‘short’ while the ‘DECL_ARG_TYPE’ is
!      ‘int’.
  
! ‘DEBUG_EXPR_DECL’
       Used to represent an anonymous debug-information temporary created
       to hold an expression as it is optimized away, so that its value
       can be referenced in debug bind statements.
  
! ‘FIELD_DECL’
!      These nodes represent non-static data members.  The ‘DECL_SIZE’ and
!      ‘DECL_ALIGN’ behave as for ‘VAR_DECL’ nodes.  The position of the
       field within the parent record is specified by a combination of
!      three attributes.  ‘DECL_FIELD_OFFSET’ is the position, counting in
!      bytes, of the ‘DECL_OFFSET_ALIGN’-bit sized word containing the bit
       of the field closest to the beginning of the structure.
!      ‘DECL_FIELD_BIT_OFFSET’ is the bit offset of the first bit of the
       field within this word; this may be nonzero even for fields that
!      are not bit-fields, since ‘DECL_OFFSET_ALIGN’ may be greater than
       the natural alignment of the field's type.
  
!      If ‘DECL_C_BIT_FIELD’ holds, this field is a bit-field.  In a
!      bit-field, ‘DECL_BIT_FIELD_TYPE’ also contains the type that was
       originally specified for it, while DECL_TYPE may be a modified type
       with lesser precision, according to the size of the bit field.
  
! ‘NAMESPACE_DECL’
       Namespaces provide a name hierarchy for other declarations.  They
!      appear in the ‘DECL_CONTEXT’ of other ‘_DECL’ nodes.
  
  
  File: gccint.info,  Node: Internal structure,  Prev: Working with declarations,  Up: Declarations
*************** File: gccint.info,  Node: Internal struc
*** 10745,10751 ****
  11.4.2 Internal structure
  -------------------------
  
! 'DECL' nodes are represented internally as a hierarchy of structures.
  
  * Menu:
  
--- 10745,10751 ----
  11.4.2 Internal structure
  -------------------------
  
! ‘DECL’ nodes are represented internally as a hierarchy of structures.
  
  * Menu:
  
*************** File: gccint.info,  Node: Current struct
*** 10760,10816 ****
  11.4.2.1 Current structure hierarchy
  ....................................
  
! 'struct tree_decl_minimal'
       This is the minimal structure to inherit from in order for common
!      'DECL' macros to work.  The fields it contains are a unique ID,
       source location, context, and name.
  
! 'struct tree_decl_common'
!      This structure inherits from 'struct tree_decl_minimal'.  It
!      contains fields that most 'DECL' nodes need, such as a field to
       store alignment, machine mode, size, and attributes.
  
! 'struct tree_field_decl'
!      This structure inherits from 'struct tree_decl_common'.  It is used
!      to represent 'FIELD_DECL'.
  
! 'struct tree_label_decl'
!      This structure inherits from 'struct tree_decl_common'.  It is used
!      to represent 'LABEL_DECL'.
  
! 'struct tree_translation_unit_decl'
!      This structure inherits from 'struct tree_decl_common'.  It is used
!      to represent 'TRANSLATION_UNIT_DECL'.
  
! 'struct tree_decl_with_rtl'
!      This structure inherits from 'struct tree_decl_common'.  It
       contains a field to store the low-level RTL associated with a
!      'DECL' node.
  
! 'struct tree_result_decl'
!      This structure inherits from 'struct tree_decl_with_rtl'.  It is
!      used to represent 'RESULT_DECL'.
  
! 'struct tree_const_decl'
!      This structure inherits from 'struct tree_decl_with_rtl'.  It is
!      used to represent 'CONST_DECL'.
  
! 'struct tree_parm_decl'
!      This structure inherits from 'struct tree_decl_with_rtl'.  It is
!      used to represent 'PARM_DECL'.
  
! 'struct tree_decl_with_vis'
!      This structure inherits from 'struct tree_decl_with_rtl'.  It
       contains fields necessary to store visibility information, as well
       as a section name and assembler name.
  
! 'struct tree_var_decl'
!      This structure inherits from 'struct tree_decl_with_vis'.  It is
!      used to represent 'VAR_DECL'.
  
! 'struct tree_function_decl'
!      This structure inherits from 'struct tree_decl_with_vis'.  It is
!      used to represent 'FUNCTION_DECL'.
  
  
  File: gccint.info,  Node: Adding new DECL node types,  Prev: Current structure hierarchy,  Up: Internal structure
--- 10760,10816 ----
  11.4.2.1 Current structure hierarchy
  ....................................
  
! ‘struct tree_decl_minimal’
       This is the minimal structure to inherit from in order for common
!      ‘DECL’ macros to work.  The fields it contains are a unique ID,
       source location, context, and name.
  
! ‘struct tree_decl_common’
!      This structure inherits from ‘struct tree_decl_minimal’.  It
!      contains fields that most ‘DECL’ nodes need, such as a field to
       store alignment, machine mode, size, and attributes.
  
! ‘struct tree_field_decl’
!      This structure inherits from ‘struct tree_decl_common’.  It is used
!      to represent ‘FIELD_DECL’.
  
! ‘struct tree_label_decl’
!      This structure inherits from ‘struct tree_decl_common’.  It is used
!      to represent ‘LABEL_DECL’.
  
! ‘struct tree_translation_unit_decl’
!      This structure inherits from ‘struct tree_decl_common’.  It is used
!      to represent ‘TRANSLATION_UNIT_DECL’.
  
! ‘struct tree_decl_with_rtl’
!      This structure inherits from ‘struct tree_decl_common’.  It
       contains a field to store the low-level RTL associated with a
!      ‘DECL’ node.
  
! ‘struct tree_result_decl’
!      This structure inherits from ‘struct tree_decl_with_rtl’.  It is
!      used to represent ‘RESULT_DECL’.
  
! ‘struct tree_const_decl’
!      This structure inherits from ‘struct tree_decl_with_rtl’.  It is
!      used to represent ‘CONST_DECL’.
  
! ‘struct tree_parm_decl’
!      This structure inherits from ‘struct tree_decl_with_rtl’.  It is
!      used to represent ‘PARM_DECL’.
  
! ‘struct tree_decl_with_vis’
!      This structure inherits from ‘struct tree_decl_with_rtl’.  It
       contains fields necessary to store visibility information, as well
       as a section name and assembler name.
  
! ‘struct tree_var_decl’
!      This structure inherits from ‘struct tree_decl_with_vis’.  It is
!      used to represent ‘VAR_DECL’.
  
! ‘struct tree_function_decl’
!      This structure inherits from ‘struct tree_decl_with_vis’.  It is
!      used to represent ‘FUNCTION_DECL’.
  
  
  File: gccint.info,  Node: Adding new DECL node types,  Prev: Current structure hierarchy,  Up: Internal structure
*************** File: gccint.info,  Node: Adding new DEC
*** 10818,10832 ****
  11.4.2.2 Adding new DECL node types
  ...................................
  
! Adding a new 'DECL' tree consists of the following steps
  
! Add a new tree code for the 'DECL' node
!      For language specific 'DECL' nodes, there is a '.def' file in each
!      frontend directory where the tree code should be added.  For 'DECL'
       nodes that are part of the middle-end, the code should be added to
!      'tree.def'.
  
! Create a new structure type for the 'DECL' node
       These structures should inherit from one of the existing structures
       in the language hierarchy by using that structure as the first
       member.
--- 10818,10832 ----
  11.4.2.2 Adding new DECL node types
  ...................................
  
! Adding a new ‘DECL’ tree consists of the following steps
  
! Add a new tree code for the ‘DECL’ node
!      For language specific ‘DECL’ nodes, there is a ‘.def’ file in each
!      frontend directory where the tree code should be added.  For ‘DECL’
       nodes that are part of the middle-end, the code should be added to
!      ‘tree.def’.
  
! Create a new structure type for the ‘DECL’ node
       These structures should inherit from one of the existing structures
       in the language hierarchy by using that structure as the first
       member.
*************** Create a new structure type for the 'DEC
*** 10836,10894 ****
               struct tree_decl_with_vis common;
            }
  
!      Would create a structure name 'tree_foo_decl' that inherits from
!      'struct tree_decl_with_vis'.
  
!      For language specific 'DECL' nodes, this new structure type should
!      go in the appropriate '.h' file.  For 'DECL' nodes that are part of
!      the middle-end, the structure type should go in 'tree.h'.
  
  Add a member to the tree structure enumerator for the node
!      For garbage collection and dynamic checking purposes, each 'DECL'
       node structure type is required to have a unique enumerator value
!      specified with it.  For language specific 'DECL' nodes, this new
!      enumerator value should go in the appropriate '.def' file.  For
!      'DECL' nodes that are part of the middle-end, the enumerator values
!      are specified in 'treestruct.def'.
  
! Update 'union tree_node'
       In order to make your new structure type usable, it must be added
!      to 'union tree_node'.  For language specific 'DECL' nodes, a new
!      entry should be added to the appropriate '.h' file of the form
              struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl;
!      For 'DECL' nodes that are part of the middle-end, the additional
!      member goes directly into 'union tree_node' in 'tree.h'.
  
  Update dynamic checking info
       In order to be able to check whether accessing a named portion of
!      'union tree_node' is legal, and whether a certain 'DECL' node
!      contains one of the enumerated 'DECL' node structures in the
       hierarchy, a simple lookup table is used.  This lookup table needs
       to be kept up to date with the tree structure hierarchy, or else
       checking and containment macros will fail inappropriately.
  
!      For language specific 'DECL' nodes, there is an 'init_ts' function
!      in an appropriate '.c' file, which initializes the lookup table.
!      Code setting up the table for new 'DECL' nodes should be added
!      there.  For each 'DECL' tree code and enumerator value representing
       a member of the inheritance hierarchy, the table should contain 1
       if that tree code inherits (directly or indirectly) from that
!      member.  Thus, a 'FOO_DECL' node derived from 'struct
!      decl_with_rtl', and enumerator value 'TS_FOO_DECL', would be set up
       as follows
            tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1;
            tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1;
            tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1;
            tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1;
  
!      For 'DECL' nodes that are part of the middle-end, the setup code
!      goes into 'tree.cc'.
  
  Add macros to access any new fields and flags
  
       Each added field or flag should have a macro that is used to access
       it, that performs appropriate checking to ensure only the right
!      type of 'DECL' nodes access the field.
  
       These macros generally take the following form
            #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname
--- 10836,10894 ----
               struct tree_decl_with_vis common;
            }
  
!      Would create a structure name ‘tree_foo_decl’ that inherits from
!      ‘struct tree_decl_with_vis’.
  
!      For language specific ‘DECL’ nodes, this new structure type should
!      go in the appropriate ‘.h’ file.  For ‘DECL’ nodes that are part of
!      the middle-end, the structure type should go in ‘tree.h’.
  
  Add a member to the tree structure enumerator for the node
!      For garbage collection and dynamic checking purposes, each ‘DECL’
       node structure type is required to have a unique enumerator value
!      specified with it.  For language specific ‘DECL’ nodes, this new
!      enumerator value should go in the appropriate ‘.def’ file.  For
!      ‘DECL’ nodes that are part of the middle-end, the enumerator values
!      are specified in ‘treestruct.def’.
  
! Update ‘union tree_node’
       In order to make your new structure type usable, it must be added
!      to ‘union tree_node’.  For language specific ‘DECL’ nodes, a new
!      entry should be added to the appropriate ‘.h’ file of the form
              struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl;
!      For ‘DECL’ nodes that are part of the middle-end, the additional
!      member goes directly into ‘union tree_node’ in ‘tree.h’.
  
  Update dynamic checking info
       In order to be able to check whether accessing a named portion of
!      ‘union tree_node’ is legal, and whether a certain ‘DECL’ node
!      contains one of the enumerated ‘DECL’ node structures in the
       hierarchy, a simple lookup table is used.  This lookup table needs
       to be kept up to date with the tree structure hierarchy, or else
       checking and containment macros will fail inappropriately.
  
!      For language specific ‘DECL’ nodes, there is an ‘init_ts’ function
!      in an appropriate ‘.c’ file, which initializes the lookup table.
!      Code setting up the table for new ‘DECL’ nodes should be added
!      there.  For each ‘DECL’ tree code and enumerator value representing
       a member of the inheritance hierarchy, the table should contain 1
       if that tree code inherits (directly or indirectly) from that
!      member.  Thus, a ‘FOO_DECL’ node derived from ‘struct
!      decl_with_rtl’, and enumerator value ‘TS_FOO_DECL’, would be set up
       as follows
            tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1;
            tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1;
            tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1;
            tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1;
  
!      For ‘DECL’ nodes that are part of the middle-end, the setup code
!      goes into ‘tree.cc’.
  
  Add macros to access any new fields and flags
  
       Each added field or flag should have a macro that is used to access
       it, that performs appropriate checking to ensure only the right
!      type of ‘DECL’ nodes access the field.
  
       These macros generally take the following form
            #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname
*************** Add macros to access any new fields and
*** 10898,10906 ****
            #define BASE_STRUCT_FIELDNAME(NODE) \
               (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname
  
!      Reading them from the generated 'all-tree.def' file (which in turn
!      includes all the 'tree.def' files), 'gencheck.cc' is used during
!      GCC's build to generate the '*_CHECK' macros for all tree codes.
  
  
  File: gccint.info,  Node: Attributes,  Next: Expression trees,  Prev: Declarations,  Up: GENERIC
--- 10898,10906 ----
            #define BASE_STRUCT_FIELDNAME(NODE) \
               (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname
  
!      Reading them from the generated ‘all-tree.def’ file (which in turn
!      includes all the ‘tree.def’ files), ‘gencheck.cc’ is used during
!      GCC's build to generate the ‘*_CHECK’ macros for all tree codes.
  
  
  File: gccint.info,  Node: Attributes,  Next: Expression trees,  Prev: Declarations,  Up: GENERIC
*************** File: gccint.info,  Node: Attributes,  N
*** 10908,10921 ****
  11.5 Attributes in trees
  ========================
  
! Attributes, as specified using the '__attribute__' keyword, are
! represented internally as a 'TREE_LIST'.  The 'TREE_PURPOSE' is the name
! of the attribute, as an 'IDENTIFIER_NODE'.  The 'TREE_VALUE' is a
! 'TREE_LIST' of the arguments of the attribute, if any, or 'NULL_TREE' if
! there are no arguments; the arguments are stored as the 'TREE_VALUE' of
  successive entries in the list, and may be identifiers or expressions.
! The 'TREE_CHAIN' of the attribute is the next attribute in a list of
! attributes applying to the same declaration or type, or 'NULL_TREE' if
  there are no further attributes in the list.
  
   Attributes may be attached to declarations and to types; these
--- 10908,10921 ----
  11.5 Attributes in trees
  ========================
  
! Attributes, as specified using the ‘__attribute__’ keyword, are
! represented internally as a ‘TREE_LIST’.  The ‘TREE_PURPOSE’ is the name
! of the attribute, as an ‘IDENTIFIER_NODE’.  The ‘TREE_VALUE’ is a
! ‘TREE_LIST’ of the arguments of the attribute, if any, or ‘NULL_TREE’ if
! there are no arguments; the arguments are stored as the ‘TREE_VALUE’ of
  successive entries in the list, and may be identifiers or expressions.
! The ‘TREE_CHAIN’ of the attribute is the next attribute in a list of
! attributes applying to the same declaration or type, or ‘NULL_TREE’ if
  there are no further attributes in the list.
  
   Attributes may be attached to declarations and to types; these
*************** of nodes being unshared.
*** 10946,10958 ****
  
   The following macros can be used with all expression nodes:
  
! 'TREE_TYPE'
       Returns the type of the expression.  This value may not be
       precisely the same type that would be given the expression in the
       original program.
  
   In what follows, some nodes that one might expect to always have type
! 'bool' are documented to have either integral or boolean type.  At some
  point in the future, the C front end may also make use of this same
  intermediate representation, and at this point these nodes will
  certainly have integral type.  The previous sentence is not meant to
--- 10946,10958 ----
  
   The following macros can be used with all expression nodes:
  
! ‘TREE_TYPE’
       Returns the type of the expression.  This value may not be
       precisely the same type that would be given the expression in the
       original program.
  
   In what follows, some nodes that one might expect to always have type
! ‘bool’ are documented to have either integral or boolean type.  At some
  point in the future, the C front end may also make use of this same
  intermediate representation, and at this point these nodes will
  certainly have integral type.  The previous sentence is not meant to
*************** integral type.
*** 10961,10968 ****
  
   Below, we list the various kinds of expression nodes.  Except where
  noted otherwise, the operands to an expression are accessed using the
! 'TREE_OPERAND' macro.  For example, to access the first operand to a
! binary plus expression 'expr', use:
  
       TREE_OPERAND (expr, 0)
  
--- 10961,10968 ----
  
   Below, we list the various kinds of expression nodes.  Except where
  noted otherwise, the operands to an expression are accessed using the
! ‘TREE_OPERAND’ macro.  For example, to access the first operand to a
! binary plus expression ‘expr’, use:
  
       TREE_OPERAND (expr, 0)
  
*************** The table below begins with constants, m
*** 10985,11031 ****
  then proceeds to binary expressions, and concludes with various other
  kinds of expressions:
  
! 'INTEGER_CST'
       These nodes represent integer constants.  Note that the type of
!      these constants is obtained with 'TREE_TYPE'; they are not always
!      of type 'int'.  In particular, 'char' constants are represented
!      with 'INTEGER_CST' nodes.  The value of the integer constant 'e' is
       represented in an array of HOST_WIDE_INT. There are enough elements
       in the array to represent the value without taking extra elements
       for redundant 0s or -1.  The number of elements used to represent
!      'e' is available via 'TREE_INT_CST_NUNITS'.  Element 'i' can be
!      extracted by using 'TREE_INT_CST_ELT (e, i)'.  'TREE_INT_CST_LOW'
!      is a shorthand for 'TREE_INT_CST_ELT (e, 0)'.
  
!      The functions 'tree_fits_shwi_p' and 'tree_fits_uhwi_p' can be used
       to tell if the value is small enough to fit in a signed
       HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively.  The value
!      can then be extracted using 'tree_to_shwi' and 'tree_to_uhwi'.
  
! 'REAL_CST'
  
       FIXME: Talk about how to obtain representations of this constant,
       do comparisons, and so forth.
  
! 'FIXED_CST'
  
       These nodes represent fixed-point constants.  The type of these
!      constants is obtained with 'TREE_TYPE'.  'TREE_FIXED_CST_PTR'
!      points to a 'struct fixed_value'; 'TREE_FIXED_CST' returns the
!      structure itself.  'struct fixed_value' contains 'data' with the
!      size of two 'HOST_BITS_PER_WIDE_INT' and 'mode' as the associated
!      fixed-point machine mode for 'data'.
  
! 'COMPLEX_CST'
       These nodes are used to represent complex number constants, that is
!      a '__complex__' whose parts are constant nodes.  The
!      'TREE_REALPART' and 'TREE_IMAGPART' return the real and the
       imaginary parts respectively.
  
! 'VECTOR_CST'
       These nodes are used to represent vector constants.  Each vector
       constant V is treated as a specific instance of an arbitrary-length
!      sequence that itself contains 'VECTOR_CST_NPATTERNS (V)'
       interleaved patterns.  Each pattern has the form:
  
            { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... }
--- 10985,11031 ----
  then proceeds to binary expressions, and concludes with various other
  kinds of expressions:
  
! ‘INTEGER_CST’
       These nodes represent integer constants.  Note that the type of
!      these constants is obtained with ‘TREE_TYPE’; they are not always
!      of type ‘int’.  In particular, ‘char’ constants are represented
!      with ‘INTEGER_CST’ nodes.  The value of the integer constant ‘e’ is
       represented in an array of HOST_WIDE_INT. There are enough elements
       in the array to represent the value without taking extra elements
       for redundant 0s or -1.  The number of elements used to represent
!      ‘e’ is available via ‘TREE_INT_CST_NUNITS’.  Element ‘i’ can be
!      extracted by using ‘TREE_INT_CST_ELT (e, i)’.  ‘TREE_INT_CST_LOW’
!      is a shorthand for ‘TREE_INT_CST_ELT (e, 0)’.
  
!      The functions ‘tree_fits_shwi_p’ and ‘tree_fits_uhwi_p’ can be used
       to tell if the value is small enough to fit in a signed
       HOST_WIDE_INT or an unsigned HOST_WIDE_INT respectively.  The value
!      can then be extracted using ‘tree_to_shwi’ and ‘tree_to_uhwi’.
  
! ‘REAL_CST’
  
       FIXME: Talk about how to obtain representations of this constant,
       do comparisons, and so forth.
  
! ‘FIXED_CST’
  
       These nodes represent fixed-point constants.  The type of these
!      constants is obtained with ‘TREE_TYPE’.  ‘TREE_FIXED_CST_PTR’
!      points to a ‘struct fixed_value’; ‘TREE_FIXED_CST’ returns the
!      structure itself.  ‘struct fixed_value’ contains ‘data’ with the
!      size of two ‘HOST_BITS_PER_WIDE_INT’ and ‘mode’ as the associated
!      fixed-point machine mode for ‘data’.
  
! ‘COMPLEX_CST’
       These nodes are used to represent complex number constants, that is
!      a ‘__complex__’ whose parts are constant nodes.  The
!      ‘TREE_REALPART’ and ‘TREE_IMAGPART’ return the real and the
       imaginary parts respectively.
  
! ‘VECTOR_CST’
       These nodes are used to represent vector constants.  Each vector
       constant V is treated as a specific instance of an arbitrary-length
!      sequence that itself contains ‘VECTOR_CST_NPATTERNS (V)’
       interleaved patterns.  Each pattern has the form:
  
            { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... }
*************** kinds of expressions:
*** 11035,11041 ****
       only the first two elements are needed.  If in addition each BASE1
       is equal to the corresponding BASE0, only the first element in each
       pattern is needed.  The number of encoded elements per pattern is
!      given by 'VECTOR_CST_NELTS_PER_PATTERN (V)'.
  
       For example, the constant:
  
--- 11035,11041 ----
       only the first two elements are needed.  If in addition each BASE1
       is equal to the corresponding BASE0, only the first element in each
       pattern is needed.  The number of encoded elements per pattern is
!      given by ‘VECTOR_CST_NELTS_PER_PATTERN (V)’.
  
       For example, the constant:
  
*************** kinds of expressions:
*** 11056,11063 ****
            VECTOR_CST_NPATTERNS (V) == 2
            VECTOR_CST_NELTS_PER_PATTERN (V) == 3
  
!      The vector is therefore encoded using the first 6 elements ('{ 0,
!      1, 2, 6, 3, 8 }'), with the remaining 10 elements being implicit
       extensions of them.
  
       Sometimes this scheme can create two possible encodings of the same
--- 11056,11063 ----
            VECTOR_CST_NPATTERNS (V) == 2
            VECTOR_CST_NELTS_PER_PATTERN (V) == 3
  
!      The vector is therefore encoded using the first 6 elements (‘{ 0,
!      1, 2, 6, 3, 8 }’), with the remaining 10 elements being implicit
       extensions of them.
  
       Sometimes this scheme can create two possible encodings of the same
*************** kinds of expressions:
*** 11067,11118 ****
       patterns or (if both encodings have the same number of patterns)
       the one with the fewest encoded elements.
  
!      'vector_cst_encoding_nelts (V)' gives the total number of encoded
       elements in V, which is 6 in the example above.
!      'VECTOR_CST_ENCODED_ELTS (V)' gives a pointer to the elements
!      encoded in V and 'VECTOR_CST_ENCODED_ELT (V, I)' accesses the value
       of encoded element I.
  
!      'VECTOR_CST_DUPLICATE_P (V)' is true if V simply contains repeated
!      instances of 'VECTOR_CST_NPATTERNS (V)' values.  This is a
!      shorthand for testing 'VECTOR_CST_NELTS_PER_PATTERN (V) == 1'.
  
!      'VECTOR_CST_STEPPED_P (V)' is true if at least one pattern in V has
       a nonzero step.  This is a shorthand for testing
!      'VECTOR_CST_NELTS_PER_PATTERN (V) == 3'.
  
!      The utility function 'vector_cst_elt' gives the value of an
!      arbitrary index as a 'tree'.  'vector_cst_int_elt' gives the same
!      value as a 'wide_int'.
  
! 'STRING_CST'
!      These nodes represent string-constants.  The 'TREE_STRING_LENGTH'
!      returns the length of the string, as an 'int'.  The
!      'TREE_STRING_POINTER' is a 'char*' containing the string itself.
!      The string may not be 'NUL'-terminated, and it may contain embedded
!      'NUL' characters.  Therefore, the 'TREE_STRING_LENGTH' includes the
!      trailing 'NUL' if it is present.
  
!      For wide string constants, the 'TREE_STRING_LENGTH' is the number
!      of bytes in the string, and the 'TREE_STRING_POINTER' points to an
       array of the bytes of the string, as represented on the target
       system (that is, as integers in the target endianness).  Wide and
!      non-wide string constants are distinguished only by the 'TREE_TYPE'
!      of the 'STRING_CST'.
  
       FIXME: The formats of string constants are not well-defined when
       the target system bytes are not the same width as host system
       bytes.
  
! 'POLY_INT_CST'
       These nodes represent invariants that depend on some
       target-specific runtime parameters.  They consist of
!      'NUM_POLY_INT_COEFFS' coefficients, with the first coefficient
       being the constant term and the others being multipliers that are
       applied to the runtime parameters.
  
!      'POLY_INT_CST_ELT (X, I)' references coefficient number I of
!      'POLY_INT_CST' node X.  Each coefficient is an 'INTEGER_CST'.
  
  
  File: gccint.info,  Node: Storage References,  Next: Unary and Binary Expressions,  Prev: Constant expressions,  Up: Expression trees
--- 11067,11118 ----
       patterns or (if both encodings have the same number of patterns)
       the one with the fewest encoded elements.
  
!      ‘vector_cst_encoding_nelts (V)’ gives the total number of encoded
       elements in V, which is 6 in the example above.
!      ‘VECTOR_CST_ENCODED_ELTS (V)’ gives a pointer to the elements
!      encoded in V and ‘VECTOR_CST_ENCODED_ELT (V, I)’ accesses the value
       of encoded element I.
  
!      ‘VECTOR_CST_DUPLICATE_P (V)’ is true if V simply contains repeated
!      instances of ‘VECTOR_CST_NPATTERNS (V)’ values.  This is a
!      shorthand for testing ‘VECTOR_CST_NELTS_PER_PATTERN (V) == 1’.
  
!      ‘VECTOR_CST_STEPPED_P (V)’ is true if at least one pattern in V has
       a nonzero step.  This is a shorthand for testing
!      ‘VECTOR_CST_NELTS_PER_PATTERN (V) == 3’.
  
!      The utility function ‘vector_cst_elt’ gives the value of an
!      arbitrary index as a ‘tree’.  ‘vector_cst_int_elt’ gives the same
!      value as a ‘wide_int’.
  
! ‘STRING_CST’
!      These nodes represent string-constants.  The ‘TREE_STRING_LENGTH’
!      returns the length of the string, as an ‘int’.  The
!      ‘TREE_STRING_POINTER’ is a ‘char*’ containing the string itself.
!      The string may not be ‘NUL’-terminated, and it may contain embedded
!      ‘NUL’ characters.  Therefore, the ‘TREE_STRING_LENGTH’ includes the
!      trailing ‘NUL’ if it is present.
  
!      For wide string constants, the ‘TREE_STRING_LENGTH’ is the number
!      of bytes in the string, and the ‘TREE_STRING_POINTER’ points to an
       array of the bytes of the string, as represented on the target
       system (that is, as integers in the target endianness).  Wide and
!      non-wide string constants are distinguished only by the ‘TREE_TYPE’
!      of the ‘STRING_CST’.
  
       FIXME: The formats of string constants are not well-defined when
       the target system bytes are not the same width as host system
       bytes.
  
! ‘POLY_INT_CST’
       These nodes represent invariants that depend on some
       target-specific runtime parameters.  They consist of
!      ‘NUM_POLY_INT_COEFFS’ coefficients, with the first coefficient
       being the constant term and the others being multipliers that are
       applied to the runtime parameters.
  
!      ‘POLY_INT_CST_ELT (X, I)’ references coefficient number I of
!      ‘POLY_INT_CST’ node X.  Each coefficient is an ‘INTEGER_CST’.
  
  
  File: gccint.info,  Node: Storage References,  Next: Unary and Binary Expressions,  Prev: Constant expressions,  Up: Expression trees
*************** File: gccint.info,  Node: Storage Refere
*** 11120,11126 ****
  11.6.2 References to storage
  ----------------------------
  
! 'ARRAY_REF'
       These nodes represent array accesses.  The first operand is the
       array; the second is the index.  To calculate the address of the
       memory accessed, you must scale the index by the size of the type
--- 11120,11126 ----
  11.6.2 References to storage
  ----------------------------
  
! ‘ARRAY_REF’
       These nodes represent array accesses.  The first operand is the
       array; the second is the index.  To calculate the address of the
       memory accessed, you must scale the index by the size of the type
*************** File: gccint.info,  Node: Storage Refere
*** 11128,11168 ****
       type of a component of the array.  The third and fourth operands
       are used after gimplification to represent the lower bound and
       component size but should not be used directly; call
!      'array_ref_low_bound' and 'array_ref_element_size' instead.
  
! 'ARRAY_RANGE_REF'
       These nodes represent access to a range (or "slice") of an array.
!      The operands are the same as that for 'ARRAY_REF' and have the same
       meanings.  The type of these expressions must be an array whose
       component type is the same as that of the first operand.  The range
       of that array type determines the amount of data these expressions
       access.
  
! 'COMPONENT_REF'
       These nodes represent non-static data member accesses.  The first
       operand is the object (rather than a pointer to it); the second
!      operand is the 'FIELD_DECL' for the data member.  The third operand
       represents the byte offset of the field, but should not be used
!      directly; call 'component_ref_field_offset' instead.
  
! 'ADDR_EXPR'
       These nodes are used to represent the address of an object.  (These
       expressions will always have pointer or reference type.)  The
       operand may be another expression, or it may be a declaration.
  
       As an extension, GCC allows users to take the address of a label.
!      In this case, the operand of the 'ADDR_EXPR' will be a
!      'LABEL_DECL'.  The type of such an expression is 'void*'.
  
       If the object addressed is not an lvalue, a temporary is created,
       and the address of the temporary is used.
  
! 'INDIRECT_REF'
       These nodes are used to represent the object pointed to by a
       pointer.  The operand is the pointer being dereferenced; it will
       always have pointer or reference type.
  
! 'MEM_REF'
       These nodes are used to represent the object pointed to by a
       pointer offset by a constant.  The first operand is the pointer
       being dereferenced; it will always have pointer or reference type.
--- 11128,11168 ----
       type of a component of the array.  The third and fourth operands
       are used after gimplification to represent the lower bound and
       component size but should not be used directly; call
!      ‘array_ref_low_bound’ and ‘array_ref_element_size’ instead.
  
! ‘ARRAY_RANGE_REF’
       These nodes represent access to a range (or "slice") of an array.
!      The operands are the same as that for ‘ARRAY_REF’ and have the same
       meanings.  The type of these expressions must be an array whose
       component type is the same as that of the first operand.  The range
       of that array type determines the amount of data these expressions
       access.
  
! ‘COMPONENT_REF’
       These nodes represent non-static data member accesses.  The first
       operand is the object (rather than a pointer to it); the second
!      operand is the ‘FIELD_DECL’ for the data member.  The third operand
       represents the byte offset of the field, but should not be used
!      directly; call ‘component_ref_field_offset’ instead.
  
! ‘ADDR_EXPR’
       These nodes are used to represent the address of an object.  (These
       expressions will always have pointer or reference type.)  The
       operand may be another expression, or it may be a declaration.
  
       As an extension, GCC allows users to take the address of a label.
!      In this case, the operand of the ‘ADDR_EXPR’ will be a
!      ‘LABEL_DECL’.  The type of such an expression is ‘void*’.
  
       If the object addressed is not an lvalue, a temporary is created,
       and the address of the temporary is used.
  
! ‘INDIRECT_REF’
       These nodes are used to represent the object pointed to by a
       pointer.  The operand is the pointer being dereferenced; it will
       always have pointer or reference type.
  
! ‘MEM_REF’
       These nodes are used to represent the object pointed to by a
       pointer offset by a constant.  The first operand is the pointer
       being dereferenced; it will always have pointer or reference type.
*************** File: gccint.info,  Node: Storage Refere
*** 11171,11191 ****
       the type to be used for type-based alias analysis.  The type of the
       node specifies the alignment of the access.
  
! 'TARGET_MEM_REF'
       These nodes represent memory accesses whose address directly map to
       an addressing mode of the target architecture.  The first argument
!      is 'TMR_BASE' and is a pointer to the object being accessed.  The
!      second argument is 'TMR_OFFSET' which is a pointer constant with
       dual purpose serving both as constant offset and holder of the type
       used for type-based alias analysis.  The first two operands have
!      exactly the same semantics as 'MEM_REF'.  The third and fourth
!      operand are 'TMR_INDEX' and 'TMR_STEP' where the former is an
       integer and the latter an integer constant.  The fifth and last
!      operand is 'TMR_INDEX2' which is an alternate non-constant offset.
!      Any of the third to last operands may be 'NULL' if the
       corresponding component does not appear in the address, but
!      'TMR_INDEX' and 'TMR_STEP' shall be always supplied in pair.  The
!      Address of the 'TARGET_MEM_REF' is determined in the following way.
  
            TMR_BASE + TMR_OFFSET + TMR_INDEX * TMR_STEP + TMR_INDEX2
  
--- 11171,11191 ----
       the type to be used for type-based alias analysis.  The type of the
       node specifies the alignment of the access.
  
! ‘TARGET_MEM_REF’
       These nodes represent memory accesses whose address directly map to
       an addressing mode of the target architecture.  The first argument
!      is ‘TMR_BASE’ and is a pointer to the object being accessed.  The
!      second argument is ‘TMR_OFFSET’ which is a pointer constant with
       dual purpose serving both as constant offset and holder of the type
       used for type-based alias analysis.  The first two operands have
!      exactly the same semantics as ‘MEM_REF’.  The third and fourth
!      operand are ‘TMR_INDEX’ and ‘TMR_STEP’ where the former is an
       integer and the latter an integer constant.  The fifth and last
!      operand is ‘TMR_INDEX2’ which is an alternate non-constant offset.
!      Any of the third to last operands may be ‘NULL’ if the
       corresponding component does not appear in the address, but
!      ‘TMR_INDEX’ and ‘TMR_STEP’ shall be always supplied in pair.  The
!      Address of the ‘TARGET_MEM_REF’ is determined in the following way.
  
            TMR_BASE + TMR_OFFSET + TMR_INDEX * TMR_STEP + TMR_INDEX2
  
*************** File: gccint.info,  Node: Unary and Bina
*** 11197,11306 ****
  11.6.3 Unary and Binary Expressions
  -----------------------------------
  
! 'NEGATE_EXPR'
       These nodes represent unary negation of the single operand, for
       both integer and floating-point types.  The type of negation can be
       determined by looking at the type of the expression.
  
       The behavior of this operation on signed arithmetic overflow is
!      controlled by the 'flag_wrapv' and 'flag_trapv' variables.
  
! 'ABS_EXPR'
       These nodes represent the absolute value of the single operand, for
       both integer and floating-point types.  This is typically used to
!      implement the 'abs', 'labs' and 'llabs' builtins for integer types,
!      and the 'fabs', 'fabsf' and 'fabsl' builtins for floating point
       types.  The type of abs operation can be determined by looking at
       the type of the expression.
  
       This node is not used for complex types.  To represent the modulus
!      or complex abs of a complex value, use the 'BUILT_IN_CABS',
!      'BUILT_IN_CABSF' or 'BUILT_IN_CABSL' builtins, as used to implement
!      the C99 'cabs', 'cabsf' and 'cabsl' built-in functions.
  
! 'ABSU_EXPR'
       These nodes represent the absolute value of the single operand in
!      equivalent unsigned type such that 'ABSU_EXPR' of 'TYPE_MIN' is
       well defined.
  
! 'BIT_NOT_EXPR'
       These nodes represent bitwise complement, and will always have
       integral type.  The only operand is the value to be complemented.
  
! 'TRUTH_NOT_EXPR'
       These nodes represent logical negation, and will always have
       integral (or boolean) type.  The operand is the value being
       negated.  The type of the operand and that of the result are always
!      of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'.
  
! 'PREDECREMENT_EXPR'
! 'PREINCREMENT_EXPR'
! 'POSTDECREMENT_EXPR'
! 'POSTINCREMENT_EXPR'
       These nodes represent increment and decrement expressions.  The
       value of the single operand is computed, and the operand
!      incremented or decremented.  In the case of 'PREDECREMENT_EXPR' and
!      'PREINCREMENT_EXPR', the value of the expression is the value
       resulting after the increment or decrement; in the case of
!      'POSTDECREMENT_EXPR' and 'POSTINCREMENT_EXPR' is the value before
       the increment or decrement occurs.  The type of the operand, like
       that of the result, will be either integral, boolean, or
       floating-point.
  
! 'FIX_TRUNC_EXPR'
       These nodes represent conversion of a floating-point value to an
       integer.  The single operand will have a floating-point type, while
       the complete expression will have an integral (or boolean) type.
       The operand is rounded towards zero.
  
! 'FLOAT_EXPR'
       These nodes represent conversion of an integral (or boolean) value
       to a floating-point value.  The single operand will have integral
       type, while the complete expression will have a floating-point
       type.
  
       FIXME: How is the operand supposed to be rounded?  Is this
!      dependent on '-mieee'?
  
! 'COMPLEX_EXPR'
       These nodes are used to represent complex numbers constructed from
       two expressions of the same (integer or real) type.  The first
       operand is the real part and the second operand is the imaginary
       part.
  
! 'CONJ_EXPR'
       These nodes represent the conjugate of their operand.
  
! 'REALPART_EXPR'
! 'IMAGPART_EXPR'
       These nodes represent respectively the real and the imaginary parts
       of complex numbers (their sole argument).
  
! 'NON_LVALUE_EXPR'
       These nodes indicate that their one and only operand is not an
       lvalue.  A back end can treat these identically to the single
       operand.
  
! 'NOP_EXPR'
       These nodes are used to represent conversions that do not require
!      any code-generation.  For example, conversion of a 'char*' to an
!      'int*' does not require any code be generated; such a conversion is
!      represented by a 'NOP_EXPR'.  The single operand is the expression
       to be converted.  The conversion from a pointer to a reference is
!      also represented with a 'NOP_EXPR'.
  
! 'CONVERT_EXPR'
!      These nodes are similar to 'NOP_EXPR's, but are used in those
       situations where code may need to be generated.  For example, if an
!      'int*' is converted to an 'int' code may need to be generated on
       some platforms.  These nodes are never used for C++-specific
       conversions, like conversions between pointers to different classes
       in an inheritance hierarchy.  Any adjustments that need to be made
       in such cases are always indicated explicitly.  Similarly, a
!      user-defined conversion is never represented by a 'CONVERT_EXPR';
       instead, the function calls are made explicit.
  
! 'FIXED_CONVERT_EXPR'
       These nodes are used to represent conversions that involve
       fixed-point values.  For example, from a fixed-point value to
       another fixed-point value, from an integer to a fixed-point value,
--- 11197,11306 ----
  11.6.3 Unary and Binary Expressions
  -----------------------------------
  
! ‘NEGATE_EXPR’
       These nodes represent unary negation of the single operand, for
       both integer and floating-point types.  The type of negation can be
       determined by looking at the type of the expression.
  
       The behavior of this operation on signed arithmetic overflow is
!      controlled by the ‘flag_wrapv’ and ‘flag_trapv’ variables.
  
! ‘ABS_EXPR’
       These nodes represent the absolute value of the single operand, for
       both integer and floating-point types.  This is typically used to
!      implement the ‘abs’, ‘labs’ and ‘llabs’ builtins for integer types,
!      and the ‘fabs’, ‘fabsf’ and ‘fabsl’ builtins for floating point
       types.  The type of abs operation can be determined by looking at
       the type of the expression.
  
       This node is not used for complex types.  To represent the modulus
!      or complex abs of a complex value, use the ‘BUILT_IN_CABS’,
!      ‘BUILT_IN_CABSF’ or ‘BUILT_IN_CABSL’ builtins, as used to implement
!      the C99 ‘cabs’, ‘cabsf’ and ‘cabsl’ built-in functions.
  
! ‘ABSU_EXPR’
       These nodes represent the absolute value of the single operand in
!      equivalent unsigned type such that ‘ABSU_EXPR’ of ‘TYPE_MIN’ is
       well defined.
  
! ‘BIT_NOT_EXPR’
       These nodes represent bitwise complement, and will always have
       integral type.  The only operand is the value to be complemented.
  
! ‘TRUTH_NOT_EXPR’
       These nodes represent logical negation, and will always have
       integral (or boolean) type.  The operand is the value being
       negated.  The type of the operand and that of the result are always
!      of ‘BOOLEAN_TYPE’ or ‘INTEGER_TYPE’.
  
! ‘PREDECREMENT_EXPR’
! ‘PREINCREMENT_EXPR’
! ‘POSTDECREMENT_EXPR’
! ‘POSTINCREMENT_EXPR’
       These nodes represent increment and decrement expressions.  The
       value of the single operand is computed, and the operand
!      incremented or decremented.  In the case of ‘PREDECREMENT_EXPR’ and
!      ‘PREINCREMENT_EXPR’, the value of the expression is the value
       resulting after the increment or decrement; in the case of
!      ‘POSTDECREMENT_EXPR’ and ‘POSTINCREMENT_EXPR’ is the value before
       the increment or decrement occurs.  The type of the operand, like
       that of the result, will be either integral, boolean, or
       floating-point.
  
! ‘FIX_TRUNC_EXPR’
       These nodes represent conversion of a floating-point value to an
       integer.  The single operand will have a floating-point type, while
       the complete expression will have an integral (or boolean) type.
       The operand is rounded towards zero.
  
! ‘FLOAT_EXPR’
       These nodes represent conversion of an integral (or boolean) value
       to a floating-point value.  The single operand will have integral
       type, while the complete expression will have a floating-point
       type.
  
       FIXME: How is the operand supposed to be rounded?  Is this
!      dependent on ‘-mieee’?
  
! ‘COMPLEX_EXPR’
       These nodes are used to represent complex numbers constructed from
       two expressions of the same (integer or real) type.  The first
       operand is the real part and the second operand is the imaginary
       part.
  
! ‘CONJ_EXPR’
       These nodes represent the conjugate of their operand.
  
! ‘REALPART_EXPR’
! ‘IMAGPART_EXPR’
       These nodes represent respectively the real and the imaginary parts
       of complex numbers (their sole argument).
  
! ‘NON_LVALUE_EXPR’
       These nodes indicate that their one and only operand is not an
       lvalue.  A back end can treat these identically to the single
       operand.
  
! ‘NOP_EXPR’
       These nodes are used to represent conversions that do not require
!      any code-generation.  For example, conversion of a ‘char*’ to an
!      ‘int*’ does not require any code be generated; such a conversion is
!      represented by a ‘NOP_EXPR’.  The single operand is the expression
       to be converted.  The conversion from a pointer to a reference is
!      also represented with a ‘NOP_EXPR’.
  
! ‘CONVERT_EXPR’
!      These nodes are similar to ‘NOP_EXPR’s, but are used in those
       situations where code may need to be generated.  For example, if an
!      ‘int*’ is converted to an ‘int’ code may need to be generated on
       some platforms.  These nodes are never used for C++-specific
       conversions, like conversions between pointers to different classes
       in an inheritance hierarchy.  Any adjustments that need to be made
       in such cases are always indicated explicitly.  Similarly, a
!      user-defined conversion is never represented by a ‘CONVERT_EXPR’;
       instead, the function calls are made explicit.
  
! ‘FIXED_CONVERT_EXPR’
       These nodes are used to represent conversions that involve
       fixed-point values.  For example, from a fixed-point value to
       another fixed-point value, from an integer to a fixed-point value,
*************** File: gccint.info,  Node: Unary and Bina
*** 11308,11315 ****
       to a fixed-point value, or from a fixed-point value to a
       floating-point value.
  
! 'LSHIFT_EXPR'
! 'RSHIFT_EXPR'
       These nodes represent left and right shifts, respectively.  The
       first operand is the value to shift; it will always be of integral
       type.  The second operand is an expression for the number of bits
--- 11308,11315 ----
       to a fixed-point value, or from a fixed-point value to a
       floating-point value.
  
! ‘LSHIFT_EXPR’
! ‘RSHIFT_EXPR’
       These nodes represent left and right shifts, respectively.  The
       first operand is the value to shift; it will always be of integral
       type.  The second operand is an expression for the number of bits
*************** File: gccint.info,  Node: Unary and Bina
*** 11321,11360 ****
       Unlike most nodes, these can have a vector as first operand and a
       scalar as second operand.
  
! 'BIT_IOR_EXPR'
! 'BIT_XOR_EXPR'
! 'BIT_AND_EXPR'
       These nodes represent bitwise inclusive or, bitwise exclusive or,
       and bitwise and, respectively.  Both operands will always have
       integral type.
  
! 'TRUTH_ANDIF_EXPR'
! 'TRUTH_ORIF_EXPR'
       These nodes represent logical "and" and logical "or", respectively.
       These operators are not strict; i.e., the second operand is
       evaluated only if the value of the expression is not determined by
       evaluation of the first operand.  The type of the operands and that
!      of the result are always of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'.
  
! 'TRUTH_AND_EXPR'
! 'TRUTH_OR_EXPR'
! 'TRUTH_XOR_EXPR'
       These nodes represent logical and, logical or, and logical
       exclusive or.  They are strict; both arguments are always
       evaluated.  There are no corresponding operators in C or C++, but
       the front end will sometimes generate these expressions anyhow, if
       it can tell that strictness does not matter.  The type of the
!      operands and that of the result are always of 'BOOLEAN_TYPE' or
!      'INTEGER_TYPE'.
  
! 'POINTER_PLUS_EXPR'
       This node represents pointer arithmetic.  The first operand is
       always a pointer/reference type.  The second operand is always an
       unsigned integer type compatible with sizetype.  This and
       POINTER_DIFF_EXPR are the only binary arithmetic operators that can
       operate on pointer types.
  
! 'POINTER_DIFF_EXPR'
       This node represents pointer subtraction.  The two operands always
       have pointer/reference type.  It returns a signed integer of the
       same precision as the pointers.  The behavior is undefined if the
--- 11321,11360 ----
       Unlike most nodes, these can have a vector as first operand and a
       scalar as second operand.
  
! ‘BIT_IOR_EXPR’
! ‘BIT_XOR_EXPR’
! ‘BIT_AND_EXPR’
       These nodes represent bitwise inclusive or, bitwise exclusive or,
       and bitwise and, respectively.  Both operands will always have
       integral type.
  
! ‘TRUTH_ANDIF_EXPR’
! ‘TRUTH_ORIF_EXPR’
       These nodes represent logical "and" and logical "or", respectively.
       These operators are not strict; i.e., the second operand is
       evaluated only if the value of the expression is not determined by
       evaluation of the first operand.  The type of the operands and that
!      of the result are always of ‘BOOLEAN_TYPE’ or ‘INTEGER_TYPE’.
  
! ‘TRUTH_AND_EXPR’
! ‘TRUTH_OR_EXPR’
! ‘TRUTH_XOR_EXPR’
       These nodes represent logical and, logical or, and logical
       exclusive or.  They are strict; both arguments are always
       evaluated.  There are no corresponding operators in C or C++, but
       the front end will sometimes generate these expressions anyhow, if
       it can tell that strictness does not matter.  The type of the
!      operands and that of the result are always of ‘BOOLEAN_TYPE’ or
!      ‘INTEGER_TYPE’.
  
! ‘POINTER_PLUS_EXPR’
       This node represents pointer arithmetic.  The first operand is
       always a pointer/reference type.  The second operand is always an
       unsigned integer type compatible with sizetype.  This and
       POINTER_DIFF_EXPR are the only binary arithmetic operators that can
       operate on pointer types.
  
! ‘POINTER_DIFF_EXPR’
       This node represents pointer subtraction.  The two operands always
       have pointer/reference type.  It returns a signed integer of the
       same precision as the pointers.  The behavior is undefined if the
*************** File: gccint.info,  Node: Unary and Bina
*** 11363,11371 ****
       does not depend on the pointer type, it is not divided by the size
       of the pointed-to type.
  
! 'PLUS_EXPR'
! 'MINUS_EXPR'
! 'MULT_EXPR'
       These nodes represent various binary arithmetic operations.
       Respectively, these operations are addition, subtraction (of the
       second operand from the first) and multiplication.  Their operands
--- 11363,11371 ----
       does not depend on the pointer type, it is not divided by the size
       of the pointed-to type.
  
! ‘PLUS_EXPR’
! ‘MINUS_EXPR’
! ‘MULT_EXPR’
       These nodes represent various binary arithmetic operations.
       Respectively, these operations are addition, subtraction (of the
       second operand from the first) and multiplication.  Their operands
*************** File: gccint.info,  Node: Unary and Bina
*** 11374,11438 ****
       integral type.
  
       The behavior of these operations on signed arithmetic overflow is
!      controlled by the 'flag_wrapv' and 'flag_trapv' variables.
  
! 'WIDEN_MULT_EXPR'
       This node represents a widening multiplication.  The operands have
       integral types with same B bits of precision, producing an integral
       type result with at least 2B bits of precision.  The behaviour is
       equivalent to extending both operands, possibly of different
       signedness, to the result type, then multiplying them.
  
! 'MULT_HIGHPART_EXPR'
       This node represents the "high-part" of a widening multiplication.
       For an integral type with B bits of precision, the result is the
       most significant B bits of the full 2B product.  Both operands must
       have the same precision and same signedness.
  
! 'RDIV_EXPR'
       This node represents a floating point division operation.
  
! 'TRUNC_DIV_EXPR'
! 'FLOOR_DIV_EXPR'
! 'CEIL_DIV_EXPR'
! 'ROUND_DIV_EXPR'
       These nodes represent integer division operations that return an
!      integer result.  'TRUNC_DIV_EXPR' rounds towards zero,
!      'FLOOR_DIV_EXPR' rounds towards negative infinity, 'CEIL_DIV_EXPR'
!      rounds towards positive infinity and 'ROUND_DIV_EXPR' rounds to the
       closest integer.  Integer division in C and C++ is truncating, i.e.
!      'TRUNC_DIV_EXPR'.
  
       The behavior of these operations on signed arithmetic overflow,
       when dividing the minimum signed integer by minus one, is
!      controlled by the 'flag_wrapv' and 'flag_trapv' variables.
  
! 'TRUNC_MOD_EXPR'
! 'FLOOR_MOD_EXPR'
! 'CEIL_MOD_EXPR'
! 'ROUND_MOD_EXPR'
       These nodes represent the integer remainder or modulus operation.
!      The integer modulus of two operands 'a' and 'b' is defined as 'a -
!      (a/b)*b' where the division calculated using the corresponding
!      division operator.  Hence for 'TRUNC_MOD_EXPR' this definition
       assumes division using truncation towards zero, i.e.
!      'TRUNC_DIV_EXPR'.  Integer remainder in C and C++ uses truncating
!      division, i.e. 'TRUNC_MOD_EXPR'.
  
! 'EXACT_DIV_EXPR'
!      The 'EXACT_DIV_EXPR' code is used to represent integer divisions
       where the numerator is known to be an exact multiple of the
       denominator.  This allows the backend to choose between the faster
!      of 'TRUNC_DIV_EXPR', 'CEIL_DIV_EXPR' and 'FLOOR_DIV_EXPR' for the
       current target.
  
! 'LT_EXPR'
! 'LE_EXPR'
! 'GT_EXPR'
! 'GE_EXPR'
! 'LTGT_EXPR'
! 'EQ_EXPR'
! 'NE_EXPR'
       These nodes represent the less than, less than or equal to, greater
       than, greater than or equal to, less or greater than, equal, and
       not equal comparison operators.  The first and second operands will
--- 11374,11438 ----
       integral type.
  
       The behavior of these operations on signed arithmetic overflow is
!      controlled by the ‘flag_wrapv’ and ‘flag_trapv’ variables.
  
! ‘WIDEN_MULT_EXPR’
       This node represents a widening multiplication.  The operands have
       integral types with same B bits of precision, producing an integral
       type result with at least 2B bits of precision.  The behaviour is
       equivalent to extending both operands, possibly of different
       signedness, to the result type, then multiplying them.
  
! ‘MULT_HIGHPART_EXPR’
       This node represents the "high-part" of a widening multiplication.
       For an integral type with B bits of precision, the result is the
       most significant B bits of the full 2B product.  Both operands must
       have the same precision and same signedness.
  
! ‘RDIV_EXPR’
       This node represents a floating point division operation.
  
! ‘TRUNC_DIV_EXPR’
! ‘FLOOR_DIV_EXPR’
! ‘CEIL_DIV_EXPR’
! ‘ROUND_DIV_EXPR’
       These nodes represent integer division operations that return an
!      integer result.  ‘TRUNC_DIV_EXPR’ rounds towards zero,
!      ‘FLOOR_DIV_EXPR’ rounds towards negative infinity, ‘CEIL_DIV_EXPR’
!      rounds towards positive infinity and ‘ROUND_DIV_EXPR’ rounds to the
       closest integer.  Integer division in C and C++ is truncating, i.e.
!      ‘TRUNC_DIV_EXPR’.
  
       The behavior of these operations on signed arithmetic overflow,
       when dividing the minimum signed integer by minus one, is
!      controlled by the ‘flag_wrapv’ and ‘flag_trapv’ variables.
  
! ‘TRUNC_MOD_EXPR’
! ‘FLOOR_MOD_EXPR’
! ‘CEIL_MOD_EXPR’
! ‘ROUND_MOD_EXPR’
       These nodes represent the integer remainder or modulus operation.
!      The integer modulus of two operands ‘a’ and ‘b’ is defined as ‘a -
!      (a/b)*b’ where the division calculated using the corresponding
!      division operator.  Hence for ‘TRUNC_MOD_EXPR’ this definition
       assumes division using truncation towards zero, i.e.
!      ‘TRUNC_DIV_EXPR’.  Integer remainder in C and C++ uses truncating
!      division, i.e. ‘TRUNC_MOD_EXPR’.
  
! ‘EXACT_DIV_EXPR’
!      The ‘EXACT_DIV_EXPR’ code is used to represent integer divisions
       where the numerator is known to be an exact multiple of the
       denominator.  This allows the backend to choose between the faster
!      of ‘TRUNC_DIV_EXPR’, ‘CEIL_DIV_EXPR’ and ‘FLOOR_DIV_EXPR’ for the
       current target.
  
! ‘LT_EXPR’
! ‘LE_EXPR’
! ‘GT_EXPR’
! ‘GE_EXPR’
! ‘LTGT_EXPR’
! ‘EQ_EXPR’
! ‘NE_EXPR’
       These nodes represent the less than, less than or equal to, greater
       than, greater than or equal to, less or greater than, equal, and
       not equal comparison operators.  The first and second operands will
*************** File: gccint.info,  Node: Unary and Bina
*** 11445,11457 ****
       zero (false) or minus one (true) for vectors.
  
       For floating point comparisons, if we honor IEEE NaNs and either
!      operand is NaN, then 'NE_EXPR' always returns true and the
       remaining operators always return false.  On some targets,
       comparisons against an IEEE NaN, other than equality and
       inequality, may generate a floating-point exception.
  
! 'ORDERED_EXPR'
! 'UNORDERED_EXPR'
       These nodes represent non-trapping ordered and unordered comparison
       operators.  These operations take two floating point operands and
       determine whether they are ordered or unordered relative to each
--- 11445,11457 ----
       zero (false) or minus one (true) for vectors.
  
       For floating point comparisons, if we honor IEEE NaNs and either
!      operand is NaN, then ‘NE_EXPR’ always returns true and the
       remaining operators always return false.  On some targets,
       comparisons against an IEEE NaN, other than equality and
       inequality, may generate a floating-point exception.
  
! ‘ORDERED_EXPR’
! ‘UNORDERED_EXPR’
       These nodes represent non-trapping ordered and unordered comparison
       operators.  These operations take two floating point operands and
       determine whether they are ordered or unordered relative to each
*************** File: gccint.info,  Node: Unary and Bina
*** 11462,11509 ****
       type's zero value for false, and the result type's one value for
       true.
  
! 'UNLT_EXPR'
! 'UNLE_EXPR'
! 'UNGT_EXPR'
! 'UNGE_EXPR'
! 'UNEQ_EXPR'
       These nodes represent the unordered comparison operators.  These
       operations take two floating point operands and determine whether
       the operands are unordered or are less than, less than or equal to,
       greater than, greater than or equal to, or equal respectively.  For
!      example, 'UNLT_EXPR' returns true if either operand is an IEEE NaN
       or the first operand is less than the second.  All these operations
       are guaranteed not to generate a floating point exception.  The
       result type of these expressions will always be of integral or
       boolean type.  These operations return the result type's zero value
       for false, and the result type's one value for true.
  
! 'MODIFY_EXPR'
       These nodes represent assignment.  The left-hand side is the first
       operand; the right-hand side is the second operand.  The left-hand
!      side will be a 'VAR_DECL', 'INDIRECT_REF', 'COMPONENT_REF', or
       other lvalue.
  
!      These nodes are used to represent not only assignment with '=' but
!      also compound assignments (like '+='), by reduction to '='
!      assignment.  In other words, the representation for 'i += 3' looks
!      just like that for 'i = i + 3'.
  
! 'INIT_EXPR'
!      These nodes are just like 'MODIFY_EXPR', but are used only when a
       variable is initialized, rather than assigned to subsequently.
       This means that we can assume that the target of the initialization
       is not used in computing its own value; any reference to the lhs in
       computing the rhs is undefined.
  
! 'COMPOUND_EXPR'
       These nodes represent comma-expressions.  The first operand is an
       expression whose value is computed and thrown away prior to the
       evaluation of the second operand.  The value of the entire
       expression is the value of the second operand.
  
! 'COND_EXPR'
!      These nodes represent '?:' expressions.  The first operand is of
       boolean or integral type.  If it evaluates to a nonzero value, the
       second operand should be evaluated, and returned as the value of
       the expression.  Otherwise, the third operand is evaluated, and
--- 11462,11509 ----
       type's zero value for false, and the result type's one value for
       true.
  
! ‘UNLT_EXPR’
! ‘UNLE_EXPR’
! ‘UNGT_EXPR’
! ‘UNGE_EXPR’
! ‘UNEQ_EXPR’
       These nodes represent the unordered comparison operators.  These
       operations take two floating point operands and determine whether
       the operands are unordered or are less than, less than or equal to,
       greater than, greater than or equal to, or equal respectively.  For
!      example, ‘UNLT_EXPR’ returns true if either operand is an IEEE NaN
       or the first operand is less than the second.  All these operations
       are guaranteed not to generate a floating point exception.  The
       result type of these expressions will always be of integral or
       boolean type.  These operations return the result type's zero value
       for false, and the result type's one value for true.
  
! ‘MODIFY_EXPR’
       These nodes represent assignment.  The left-hand side is the first
       operand; the right-hand side is the second operand.  The left-hand
!      side will be a ‘VAR_DECL’, ‘INDIRECT_REF’, ‘COMPONENT_REF’, or
       other lvalue.
  
!      These nodes are used to represent not only assignment with ‘=’ but
!      also compound assignments (like ‘+=’), by reduction to ‘=’
!      assignment.  In other words, the representation for ‘i += 3’ looks
!      just like that for ‘i = i + 3’.
  
! ‘INIT_EXPR’
!      These nodes are just like ‘MODIFY_EXPR’, but are used only when a
       variable is initialized, rather than assigned to subsequently.
       This means that we can assume that the target of the initialization
       is not used in computing its own value; any reference to the lhs in
       computing the rhs is undefined.
  
! ‘COMPOUND_EXPR’
       These nodes represent comma-expressions.  The first operand is an
       expression whose value is computed and thrown away prior to the
       evaluation of the second operand.  The value of the entire
       expression is the value of the second operand.
  
! ‘COND_EXPR’
!      These nodes represent ‘?:’ expressions.  The first operand is of
       boolean or integral type.  If it evaluates to a nonzero value, the
       second operand should be evaluated, and returned as the value of
       the expression.  Otherwise, the third operand is evaluated, and
*************** File: gccint.info,  Node: Unary and Bina
*** 11513,11544 ****
       expression, unless it unconditionally throws an exception or calls
       a noreturn function, in which case it should have void type.  The
       same constraints apply to the third operand.  This allows array
!      bounds checks to be represented conveniently as '(i >= 0 && i < 10)
!      ? i : abort()'.
  
       As a GNU extension, the C language front-ends allow the second
!      operand of the '?:' operator may be omitted in the source.  For
!      example, 'x ? : 3' is equivalent to 'x ? x : 3', assuming that 'x'
       is an expression without side effects.  In the tree representation,
       however, the second operand is always present, possibly protected
!      by 'SAVE_EXPR' if the first argument does cause side effects.
  
! 'CALL_EXPR'
       These nodes are used to represent calls to functions, including
!      non-static member functions.  'CALL_EXPR's are implemented as
       expression nodes with a variable number of operands.  Rather than
!      using 'TREE_OPERAND' to extract them, it is preferable to use the
       specialized accessor macros and functions that operate specifically
!      on 'CALL_EXPR' nodes.
  
!      'CALL_EXPR_FN' returns a pointer to the function to call; it is
!      always an expression whose type is a 'POINTER_TYPE'.
  
       The number of arguments to the call is returned by
!      'call_expr_nargs', while the arguments themselves can be accessed
!      with the 'CALL_EXPR_ARG' macro.  The arguments are zero-indexed and
       numbered left-to-right.  You can iterate over the arguments using
!      'FOR_EACH_CALL_EXPR_ARG', as in:
  
            tree call, arg;
            call_expr_arg_iterator iter;
--- 11513,11544 ----
       expression, unless it unconditionally throws an exception or calls
       a noreturn function, in which case it should have void type.  The
       same constraints apply to the third operand.  This allows array
!      bounds checks to be represented conveniently as ‘(i >= 0 && i < 10)
!      ? i : abort()’.
  
       As a GNU extension, the C language front-ends allow the second
!      operand of the ‘?:’ operator may be omitted in the source.  For
!      example, ‘x ? : 3’ is equivalent to ‘x ? x : 3’, assuming that ‘x’
       is an expression without side effects.  In the tree representation,
       however, the second operand is always present, possibly protected
!      by ‘SAVE_EXPR’ if the first argument does cause side effects.
  
! ‘CALL_EXPR’
       These nodes are used to represent calls to functions, including
!      non-static member functions.  ‘CALL_EXPR’s are implemented as
       expression nodes with a variable number of operands.  Rather than
!      using ‘TREE_OPERAND’ to extract them, it is preferable to use the
       specialized accessor macros and functions that operate specifically
!      on ‘CALL_EXPR’ nodes.
  
!      ‘CALL_EXPR_FN’ returns a pointer to the function to call; it is
!      always an expression whose type is a ‘POINTER_TYPE’.
  
       The number of arguments to the call is returned by
!      ‘call_expr_nargs’, while the arguments themselves can be accessed
!      with the ‘CALL_EXPR_ARG’ macro.  The arguments are zero-indexed and
       numbered left-to-right.  You can iterate over the arguments using
!      ‘FOR_EACH_CALL_EXPR_ARG’, as in:
  
            tree call, arg;
            call_expr_arg_iterator iter;
*************** File: gccint.info,  Node: Unary and Bina
*** 11547,11586 ****
              ...;
  
       For non-static member functions, there will be an operand
!      corresponding to the 'this' pointer.  There will always be
       expressions corresponding to all of the arguments, even if the
       function is declared with default arguments and some arguments are
       not explicitly provided at the call sites.
  
!      'CALL_EXPR's also have a 'CALL_EXPR_STATIC_CHAIN' operand that is
       used to implement nested functions.  This operand is otherwise
       null.
  
! 'CLEANUP_POINT_EXPR'
       These nodes represent full-expressions.  The single operand is an
       expression to evaluate.  Any destructor calls engendered by the
       creation of temporaries during the evaluation of that expression
       should be performed immediately after the expression is evaluated.
  
! 'CONSTRUCTOR'
       These nodes represent the brace-enclosed initializers for a
       structure or an array.  They contain a sequence of component values
!      made out of a vector of constructor_elt, which is a ('INDEX',
!      'VALUE') pair.
  
!      If the 'TREE_TYPE' of the 'CONSTRUCTOR' is a 'RECORD_TYPE',
!      'UNION_TYPE' or 'QUAL_UNION_TYPE' then the 'INDEX' of each node in
!      the sequence will be a 'FIELD_DECL' and the 'VALUE' will be the
       expression used to initialize that field.
  
!      If the 'TREE_TYPE' of the 'CONSTRUCTOR' is an 'ARRAY_TYPE', then
!      the 'INDEX' of each node in the sequence will be an 'INTEGER_CST'
!      or a 'RANGE_EXPR' of two 'INTEGER_CST's.  A single 'INTEGER_CST'
       indicates which element of the array is being assigned to.  A
!      'RANGE_EXPR' indicates an inclusive range of elements to
!      initialize.  In both cases the 'VALUE' is the corresponding
       initializer.  It is re-evaluated for each element of a
!      'RANGE_EXPR'.  If the 'INDEX' is 'NULL_TREE', then the initializer
       is for the next available array element.
  
       In the front end, you should not depend on the fields appearing in
--- 11547,11586 ----
              ...;
  
       For non-static member functions, there will be an operand
!      corresponding to the ‘this’ pointer.  There will always be
       expressions corresponding to all of the arguments, even if the
       function is declared with default arguments and some arguments are
       not explicitly provided at the call sites.
  
!      ‘CALL_EXPR’s also have a ‘CALL_EXPR_STATIC_CHAIN’ operand that is
       used to implement nested functions.  This operand is otherwise
       null.
  
! ‘CLEANUP_POINT_EXPR’
       These nodes represent full-expressions.  The single operand is an
       expression to evaluate.  Any destructor calls engendered by the
       creation of temporaries during the evaluation of that expression
       should be performed immediately after the expression is evaluated.
  
! ‘CONSTRUCTOR’
       These nodes represent the brace-enclosed initializers for a
       structure or an array.  They contain a sequence of component values
!      made out of a vector of constructor_elt, which is a (‘INDEX’,
!      ‘VALUE’) pair.
  
!      If the ‘TREE_TYPE’ of the ‘CONSTRUCTOR’ is a ‘RECORD_TYPE’,
!      ‘UNION_TYPE’ or ‘QUAL_UNION_TYPE’ then the ‘INDEX’ of each node in
!      the sequence will be a ‘FIELD_DECL’ and the ‘VALUE’ will be the
       expression used to initialize that field.
  
!      If the ‘TREE_TYPE’ of the ‘CONSTRUCTOR’ is an ‘ARRAY_TYPE’, then
!      the ‘INDEX’ of each node in the sequence will be an ‘INTEGER_CST’
!      or a ‘RANGE_EXPR’ of two ‘INTEGER_CST’s.  A single ‘INTEGER_CST’
       indicates which element of the array is being assigned to.  A
!      ‘RANGE_EXPR’ indicates an inclusive range of elements to
!      initialize.  In both cases the ‘VALUE’ is the corresponding
       initializer.  It is re-evaluated for each element of a
!      ‘RANGE_EXPR’.  If the ‘INDEX’ is ‘NULL_TREE’, then the initializer
       is for the next available array element.
  
       In the front end, you should not depend on the fields appearing in
*************** File: gccint.info,  Node: Unary and Bina
*** 11590,11651 ****
       (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which
       case their value becomes undefined.
  
! 'COMPOUND_LITERAL_EXPR'
       These nodes represent ISO C99 compound literals.  The
!      'COMPOUND_LITERAL_EXPR_DECL_EXPR' is a 'DECL_EXPR' containing an
!      anonymous 'VAR_DECL' for the unnamed object represented by the
!      compound literal; the 'DECL_INITIAL' of that 'VAR_DECL' is a
!      'CONSTRUCTOR' representing the brace-enclosed list of initializers
!      in the compound literal.  That anonymous 'VAR_DECL' can also be
!      accessed directly by the 'COMPOUND_LITERAL_EXPR_DECL' macro.
  
! 'SAVE_EXPR'
  
!      A 'SAVE_EXPR' represents an expression (possibly involving side
       effects) that is used more than once.  The side effects should
       occur only the first time the expression is evaluated.  Subsequent
       uses should just reuse the computed value.  The first operand to
!      the 'SAVE_EXPR' is the expression to evaluate.  The side effects
!      should be executed where the 'SAVE_EXPR' is first encountered in a
       depth-first preorder traversal of the expression tree.
  
! 'TARGET_EXPR'
!      A 'TARGET_EXPR' represents a temporary object.  The first operand
!      is a 'VAR_DECL' for the temporary variable.  The second operand is
       the initializer for the temporary.  The initializer is evaluated
       and, if non-void, copied (bitwise) into the temporary.  If the
       initializer is void, that means that it will perform the
       initialization itself.
  
!      Often, a 'TARGET_EXPR' occurs on the right-hand side of an
       assignment, or as the second operand to a comma-expression which is
       itself the right-hand side of an assignment, etc.  In this case, we
!      say that the 'TARGET_EXPR' is "normal"; otherwise, we say it is
!      "orphaned".  For a normal 'TARGET_EXPR' the temporary variable
       should be treated as an alias for the left-hand side of the
       assignment, rather than as a new temporary variable.
  
!      The third operand to the 'TARGET_EXPR', if present, is a
       cleanup-expression (i.e., destructor call) for the temporary.  If
       this expression is orphaned, then this expression must be executed
       when the statement containing this expression is complete.  These
       cleanups must always be executed in the order opposite to that in
       which they were encountered.  Note that if a temporary is created
       on one branch of a conditional operator (i.e., in the second or
!      third operand to a 'COND_EXPR'), the cleanup must be run only if
       that branch is actually executed.
  
! 'VA_ARG_EXPR'
       This node is used to implement support for the C/C++ variable
!      argument-list mechanism.  It represents expressions like 'va_arg
!      (ap, type)'.  Its 'TREE_TYPE' yields the tree representation for
!      'type' and its sole argument yields the representation for 'ap'.
  
! 'ANNOTATE_EXPR'
       This node is used to attach markers to an expression.  The first
!      operand is the annotated expression, the second is an 'INTEGER_CST'
!      with a value from 'enum annot_expr_kind', the third is an
!      'INTEGER_CST'.
  
  
  File: gccint.info,  Node: Vectors,  Prev: Unary and Binary Expressions,  Up: Expression trees
--- 11590,11651 ----
       (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which
       case their value becomes undefined.
  
! ‘COMPOUND_LITERAL_EXPR’
       These nodes represent ISO C99 compound literals.  The
!      ‘COMPOUND_LITERAL_EXPR_DECL_EXPR’ is a ‘DECL_EXPR’ containing an
!      anonymous ‘VAR_DECL’ for the unnamed object represented by the
!      compound literal; the ‘DECL_INITIAL’ of that ‘VAR_DECL’ is a
!      ‘CONSTRUCTOR’ representing the brace-enclosed list of initializers
!      in the compound literal.  That anonymous ‘VAR_DECL’ can also be
!      accessed directly by the ‘COMPOUND_LITERAL_EXPR_DECL’ macro.
  
! ‘SAVE_EXPR’
  
!      A ‘SAVE_EXPR’ represents an expression (possibly involving side
       effects) that is used more than once.  The side effects should
       occur only the first time the expression is evaluated.  Subsequent
       uses should just reuse the computed value.  The first operand to
!      the ‘SAVE_EXPR’ is the expression to evaluate.  The side effects
!      should be executed where the ‘SAVE_EXPR’ is first encountered in a
       depth-first preorder traversal of the expression tree.
  
! ‘TARGET_EXPR’
!      A ‘TARGET_EXPR’ represents a temporary object.  The first operand
!      is a ‘VAR_DECL’ for the temporary variable.  The second operand is
       the initializer for the temporary.  The initializer is evaluated
       and, if non-void, copied (bitwise) into the temporary.  If the
       initializer is void, that means that it will perform the
       initialization itself.
  
!      Often, a ‘TARGET_EXPR’ occurs on the right-hand side of an
       assignment, or as the second operand to a comma-expression which is
       itself the right-hand side of an assignment, etc.  In this case, we
!      say that the ‘TARGET_EXPR’ is "normal"; otherwise, we say it is
!      "orphaned".  For a normal ‘TARGET_EXPR’ the temporary variable
       should be treated as an alias for the left-hand side of the
       assignment, rather than as a new temporary variable.
  
!      The third operand to the ‘TARGET_EXPR’, if present, is a
       cleanup-expression (i.e., destructor call) for the temporary.  If
       this expression is orphaned, then this expression must be executed
       when the statement containing this expression is complete.  These
       cleanups must always be executed in the order opposite to that in
       which they were encountered.  Note that if a temporary is created
       on one branch of a conditional operator (i.e., in the second or
!      third operand to a ‘COND_EXPR’), the cleanup must be run only if
       that branch is actually executed.
  
! ‘VA_ARG_EXPR’
       This node is used to implement support for the C/C++ variable
!      argument-list mechanism.  It represents expressions like ‘va_arg
!      (ap, type)’.  Its ‘TREE_TYPE’ yields the tree representation for
!      ‘type’ and its sole argument yields the representation for ‘ap’.
  
! ‘ANNOTATE_EXPR’
       This node is used to attach markers to an expression.  The first
!      operand is the annotated expression, the second is an ‘INTEGER_CST’
!      with a value from ‘enum annot_expr_kind’, the third is an
!      ‘INTEGER_CST’.
  
  
  File: gccint.info,  Node: Vectors,  Prev: Unary and Binary Expressions,  Up: Expression trees
*************** File: gccint.info,  Node: Vectors,  Prev
*** 11653,11672 ****
  11.6.4 Vectors
  --------------
  
! 'VEC_DUPLICATE_EXPR'
       This node has a single operand and represents a vector in which
       every element is equal to that operand.
  
! 'VEC_SERIES_EXPR'
       This node represents a vector formed from a scalar base and step,
       given as the first and second operands respectively.  Element I of
!      the result is equal to 'BASE + I*STEP'.
  
       This node is restricted to integral types, in order to avoid
       specifying the rounding behavior for floating-point types.
  
! 'VEC_LSHIFT_EXPR'
! 'VEC_RSHIFT_EXPR'
       These nodes represent whole vector left and right shifts,
       respectively.  The first operand is the vector to shift; it will
       always be of vector type.  The second operand is an expression for
--- 11653,11672 ----
  11.6.4 Vectors
  --------------
  
! ‘VEC_DUPLICATE_EXPR’
       This node has a single operand and represents a vector in which
       every element is equal to that operand.
  
! ‘VEC_SERIES_EXPR’
       This node represents a vector formed from a scalar base and step,
       given as the first and second operands respectively.  Element I of
!      the result is equal to ‘BASE + I*STEP’.
  
       This node is restricted to integral types, in order to avoid
       specifying the rounding behavior for floating-point types.
  
! ‘VEC_LSHIFT_EXPR’
! ‘VEC_RSHIFT_EXPR’
       These nodes represent whole vector left and right shifts,
       respectively.  The first operand is the vector to shift; it will
       always be of vector type.  The second operand is an expression for
*************** File: gccint.info,  Node: Vectors,  Prev
*** 11674,11758 ****
       undefined if the second operand is larger than or equal to the
       first operand's type size.
  
! 'VEC_WIDEN_MULT_HI_EXPR'
! 'VEC_WIDEN_MULT_LO_EXPR'
       These nodes represent widening vector multiplication of the high
       and low parts of the two input vectors, respectively.  Their
!      operands are vectors that contain the same number of elements ('N')
       of the same integral type.  The result is a vector that contains
       half as many elements, of an integral type whose size is twice as
!      wide.  In the case of 'VEC_WIDEN_MULT_HI_EXPR' the high 'N/2'
       elements of the two vector are multiplied to produce the vector of
!      'N/2' products.  In the case of 'VEC_WIDEN_MULT_LO_EXPR' the low
!      'N/2' elements of the two vector are multiplied to produce the
!      vector of 'N/2' products.
  
! 'VEC_WIDEN_PLUS_HI_EXPR'
! 'VEC_WIDEN_PLUS_LO_EXPR'
       These nodes represent widening vector addition of the high and low
       parts of the two input vectors, respectively.  Their operands are
!      vectors that contain the same number of elements ('N') of the same
       integral type.  The result is a vector that contains half as many
       elements, of an integral type whose size is twice as wide.  In the
!      case of 'VEC_WIDEN_PLUS_HI_EXPR' the high 'N/2' elements of the two
!      vectors are added to produce the vector of 'N/2' products.  In the
!      case of 'VEC_WIDEN_PLUS_LO_EXPR' the low 'N/2' elements of the two
!      vectors are added to produce the vector of 'N/2' products.
  
! 'VEC_WIDEN_MINUS_HI_EXPR'
! 'VEC_WIDEN_MINUS_LO_EXPR'
       These nodes represent widening vector subtraction of the high and
       low parts of the two input vectors, respectively.  Their operands
!      are vectors that contain the same number of elements ('N') of the
       same integral type.  The high/low elements of the second vector are
       subtracted from the high/low elements of the first.  The result is
       a vector that contains half as many elements, of an integral type
       whose size is twice as wide.  In the case of
!      'VEC_WIDEN_MINUS_HI_EXPR' the high 'N/2' elements of the second
!      vector are subtracted from the high 'N/2' of the first to produce
!      the vector of 'N/2' products.  In the case of
!      'VEC_WIDEN_MINUS_LO_EXPR' the low 'N/2' elements of the second
!      vector are subtracted from the low 'N/2' of the first to produce
!      the vector of 'N/2' products.
  
! 'VEC_UNPACK_HI_EXPR'
! 'VEC_UNPACK_LO_EXPR'
       These nodes represent unpacking of the high and low parts of the
       input vector, respectively.  The single operand is a vector that
!      contains 'N' elements of the same integral or floating point type.
       The result is a vector that contains half as many elements, of an
       integral or floating point type whose size is twice as wide.  In
!      the case of 'VEC_UNPACK_HI_EXPR' the high 'N/2' elements of the
       vector are extracted and widened (promoted).  In the case of
!      'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the vector are
       extracted and widened (promoted).
  
! 'VEC_UNPACK_FLOAT_HI_EXPR'
! 'VEC_UNPACK_FLOAT_LO_EXPR'
       These nodes represent unpacking of the high and low parts of the
       input vector, where the values are converted from fixed point to
!      floating point.  The single operand is a vector that contains 'N'
       elements of the same integral type.  The result is a vector that
       contains half as many elements of a floating point type whose size
!      is twice as wide.  In the case of 'VEC_UNPACK_FLOAT_HI_EXPR' the
!      high 'N/2' elements of the vector are extracted, converted and
!      widened.  In the case of 'VEC_UNPACK_FLOAT_LO_EXPR' the low 'N/2'
       elements of the vector are extracted, converted and widened.
  
! 'VEC_UNPACK_FIX_TRUNC_HI_EXPR'
! 'VEC_UNPACK_FIX_TRUNC_LO_EXPR'
       These nodes represent unpacking of the high and low parts of the
       input vector, where the values are truncated from floating point to
!      fixed point.  The single operand is a vector that contains 'N'
       elements of the same floating point type.  The result is a vector
       that contains half as many elements of an integral type whose size
!      is twice as wide.  In the case of 'VEC_UNPACK_FIX_TRUNC_HI_EXPR'
!      the high 'N/2' elements of the vector are extracted and converted
!      with truncation.  In the case of 'VEC_UNPACK_FIX_TRUNC_LO_EXPR' the
!      low 'N/2' elements of the vector are extracted and converted with
       truncation.
  
! 'VEC_PACK_TRUNC_EXPR'
       This node represents packing of truncated elements of the two input
       vectors into the output vector.  Input operands are vectors that
       contain the same number of elements of the same integral or
--- 11674,11758 ----
       undefined if the second operand is larger than or equal to the
       first operand's type size.
  
! ‘VEC_WIDEN_MULT_HI_EXPR’
! ‘VEC_WIDEN_MULT_LO_EXPR’
       These nodes represent widening vector multiplication of the high
       and low parts of the two input vectors, respectively.  Their
!      operands are vectors that contain the same number of elements (‘N’)
       of the same integral type.  The result is a vector that contains
       half as many elements, of an integral type whose size is twice as
!      wide.  In the case of ‘VEC_WIDEN_MULT_HI_EXPR’ the high ‘N/2’
       elements of the two vector are multiplied to produce the vector of
!      ‘N/2’ products.  In the case of ‘VEC_WIDEN_MULT_LO_EXPR’ the low
!      ‘N/2’ elements of the two vector are multiplied to produce the
!      vector of ‘N/2’ products.
  
! ‘VEC_WIDEN_PLUS_HI_EXPR’
! ‘VEC_WIDEN_PLUS_LO_EXPR’
       These nodes represent widening vector addition of the high and low
       parts of the two input vectors, respectively.  Their operands are
!      vectors that contain the same number of elements (‘N’) of the same
       integral type.  The result is a vector that contains half as many
       elements, of an integral type whose size is twice as wide.  In the
!      case of ‘VEC_WIDEN_PLUS_HI_EXPR’ the high ‘N/2’ elements of the two
!      vectors are added to produce the vector of ‘N/2’ products.  In the
!      case of ‘VEC_WIDEN_PLUS_LO_EXPR’ the low ‘N/2’ elements of the two
!      vectors are added to produce the vector of ‘N/2’ products.
  
! ‘VEC_WIDEN_MINUS_HI_EXPR’
! ‘VEC_WIDEN_MINUS_LO_EXPR’
       These nodes represent widening vector subtraction of the high and
       low parts of the two input vectors, respectively.  Their operands
!      are vectors that contain the same number of elements (‘N’) of the
       same integral type.  The high/low elements of the second vector are
       subtracted from the high/low elements of the first.  The result is
       a vector that contains half as many elements, of an integral type
       whose size is twice as wide.  In the case of
!      ‘VEC_WIDEN_MINUS_HI_EXPR’ the high ‘N/2’ elements of the second
!      vector are subtracted from the high ‘N/2’ of the first to produce
!      the vector of ‘N/2’ products.  In the case of
!      ‘VEC_WIDEN_MINUS_LO_EXPR’ the low ‘N/2’ elements of the second
!      vector are subtracted from the low ‘N/2’ of the first to produce
!      the vector of ‘N/2’ products.
  
! ‘VEC_UNPACK_HI_EXPR’
! ‘VEC_UNPACK_LO_EXPR’
       These nodes represent unpacking of the high and low parts of the
       input vector, respectively.  The single operand is a vector that
!      contains ‘N’ elements of the same integral or floating point type.
       The result is a vector that contains half as many elements, of an
       integral or floating point type whose size is twice as wide.  In
!      the case of ‘VEC_UNPACK_HI_EXPR’ the high ‘N/2’ elements of the
       vector are extracted and widened (promoted).  In the case of
!      ‘VEC_UNPACK_LO_EXPR’ the low ‘N/2’ elements of the vector are
       extracted and widened (promoted).
  
! ‘VEC_UNPACK_FLOAT_HI_EXPR’
! ‘VEC_UNPACK_FLOAT_LO_EXPR’
       These nodes represent unpacking of the high and low parts of the
       input vector, where the values are converted from fixed point to
!      floating point.  The single operand is a vector that contains ‘N’
       elements of the same integral type.  The result is a vector that
       contains half as many elements of a floating point type whose size
!      is twice as wide.  In the case of ‘VEC_UNPACK_FLOAT_HI_EXPR’ the
!      high ‘N/2’ elements of the vector are extracted, converted and
!      widened.  In the case of ‘VEC_UNPACK_FLOAT_LO_EXPR’ the low ‘N/2’
       elements of the vector are extracted, converted and widened.
  
! ‘VEC_UNPACK_FIX_TRUNC_HI_EXPR’
! ‘VEC_UNPACK_FIX_TRUNC_LO_EXPR’
       These nodes represent unpacking of the high and low parts of the
       input vector, where the values are truncated from floating point to
!      fixed point.  The single operand is a vector that contains ‘N’
       elements of the same floating point type.  The result is a vector
       that contains half as many elements of an integral type whose size
!      is twice as wide.  In the case of ‘VEC_UNPACK_FIX_TRUNC_HI_EXPR’
!      the high ‘N/2’ elements of the vector are extracted and converted
!      with truncation.  In the case of ‘VEC_UNPACK_FIX_TRUNC_LO_EXPR’ the
!      low ‘N/2’ elements of the vector are extracted and converted with
       truncation.
  
! ‘VEC_PACK_TRUNC_EXPR’
       This node represents packing of truncated elements of the two input
       vectors into the output vector.  Input operands are vectors that
       contain the same number of elements of the same integral or
*************** File: gccint.info,  Node: Vectors,  Prev
*** 11761,11767 ****
       half as wide.  The elements of the two vectors are demoted and
       merged (concatenated) to form the output vector.
  
! 'VEC_PACK_SAT_EXPR'
       This node represents packing of elements of the two input vectors
       into the output vector using saturation.  Input operands are
       vectors that contain the same number of elements of the same
--- 11761,11767 ----
       half as wide.  The elements of the two vectors are demoted and
       merged (concatenated) to form the output vector.
  
! ‘VEC_PACK_SAT_EXPR’
       This node represents packing of elements of the two input vectors
       into the output vector using saturation.  Input operands are
       vectors that contain the same number of elements of the same
*************** File: gccint.info,  Node: Vectors,  Prev
*** 11770,11776 ****
       elements of the two vectors are demoted and merged (concatenated)
       to form the output vector.
  
! 'VEC_PACK_FIX_TRUNC_EXPR'
       This node represents packing of elements of the two input vectors
       into the output vector, where the values are converted from
       floating point to fixed point.  Input operands are vectors that
--- 11770,11776 ----
       elements of the two vectors are demoted and merged (concatenated)
       to form the output vector.
  
! ‘VEC_PACK_FIX_TRUNC_EXPR’
       This node represents packing of elements of the two input vectors
       into the output vector, where the values are converted from
       floating point to fixed point.  Input operands are vectors that
*************** File: gccint.info,  Node: Vectors,  Prev
*** 11779,11785 ****
       integral type whose size is half as wide.  The elements of the two
       vectors are merged (concatenated) to form the output vector.
  
! 'VEC_PACK_FLOAT_EXPR'
       This node represents packing of elements of the two input vectors
       into the output vector, where the values are converted from fixed
       point to floating point.  Input operands are vectors that contain
--- 11779,11785 ----
       integral type whose size is half as wide.  The elements of the two
       vectors are merged (concatenated) to form the output vector.
  
! ‘VEC_PACK_FLOAT_EXPR’
       This node represents packing of elements of the two input vectors
       into the output vector, where the values are converted from fixed
       point to floating point.  Input operands are vectors that contain
*************** File: gccint.info,  Node: Vectors,  Prev
*** 11788,11795 ****
       whose size is half as wide.  The elements of the two vectors are
       merged (concatenated) to form the output vector.
  
! 'VEC_COND_EXPR'
!      These nodes represent '?:' expressions.  The three operands must be
       vectors of the same size and number of elements.  The second and
       third operands must have the same type as the entire expression.
       The first operand is of signed integral vector type.  If an element
--- 11788,11795 ----
       whose size is half as wide.  The elements of the two vectors are
       merged (concatenated) to form the output vector.
  
! ‘VEC_COND_EXPR’
!      These nodes represent ‘?:’ expressions.  The three operands must be
       vectors of the same size and number of elements.  The second and
       third operands must have the same type as the entire expression.
       The first operand is of signed integral vector type.  If an element
*************** File: gccint.info,  Node: Vectors,  Prev
*** 11798,11806 ****
       evaluates to a minus one value, it is taken from the second
       operand.  It should never evaluate to any other value currently,
       but optimizations should not rely on that property.  In contrast
!      with a 'COND_EXPR', all operands are always evaluated.
  
! 'SAD_EXPR'
       This node represents the Sum of Absolute Differences operation.
       The three operands must be vectors of integral types.  The first
       and second operand must have the same type.  The size of the vector
--- 11798,11806 ----
       evaluates to a minus one value, it is taken from the second
       operand.  It should never evaluate to any other value currently,
       but optimizations should not rely on that property.  In contrast
!      with a ‘COND_EXPR’, all operands are always evaluated.
  
! ‘SAD_EXPR’
       This node represents the Sum of Absolute Differences operation.
       The three operands must be vectors of integral types.  The first
       and second operand must have the same type.  The size of the vector
*************** File: gccint.info,  Node: Statements,  N
*** 11816,11823 ****
  ===============
  
  Most statements in GIMPLE are assignment statements, represented by
! 'GIMPLE_ASSIGN'.  No other C expressions can appear at statement level;
! a reference to a volatile object is converted into a 'GIMPLE_ASSIGN'.
  
   There are also several varieties of complex statements.
  
--- 11816,11823 ----
  ===============
  
  Most statements in GIMPLE are assignment statements, represented by
! ‘GIMPLE_ASSIGN’.  No other C expressions can appear at statement level;
! a reference to a volatile object is converted into a ‘GIMPLE_ASSIGN’.
  
   There are also several varieties of complex statements.
  
*************** File: gccint.info,  Node: Basic Statemen
*** 11838,11943 ****
  11.7.1 Basic Statements
  -----------------------
  
! 'ASM_EXPR'
  
       Used to represent an inline assembly statement.  For an inline
       assembly statement like:
            asm ("mov x, y");
!      The 'ASM_STRING' macro will return a 'STRING_CST' node for '"mov x,
!      y"'.  If the original statement made use of the extended-assembly
!      syntax, then 'ASM_OUTPUTS', 'ASM_INPUTS', and 'ASM_CLOBBERS' will
       be the outputs, inputs, and clobbers for the statement, represented
!      as 'STRING_CST' nodes.  The extended-assembly syntax looks like:
            asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
!      The first string is the 'ASM_STRING', containing the instruction
       template.  The next two strings are the output and inputs,
       respectively; this statement has no clobbers.  As this example
       indicates, "plain" assembly statements are merely a special case of
       extended assembly statements; they have no cv-qualifiers, outputs,
!      inputs, or clobbers.  All of the strings will be 'NUL'-terminated,
!      and will contain no embedded 'NUL'-characters.
  
!      If the assembly statement is declared 'volatile', or if the
       statement was not an extended assembly statement, and is therefore
!      implicitly volatile, then the predicate 'ASM_VOLATILE_P' will hold
!      of the 'ASM_EXPR'.
  
! 'DECL_EXPR'
  
!      Used to represent a local declaration.  The 'DECL_EXPR_DECL' macro
       can be used to obtain the entity declared.  This declaration may be
!      a 'LABEL_DECL', indicating that the label declared is a local
       label.  (As an extension, GCC allows the declaration of labels with
!      scope.)  In C, this declaration may be a 'FUNCTION_DECL',
       indicating the use of the GCC nested function extension.  For more
       information, *note Functions::.
  
! 'LABEL_EXPR'
  
!      Used to represent a label.  The 'LABEL_DECL' declared by this
!      statement can be obtained with the 'LABEL_EXPR_LABEL' macro.  The
!      'IDENTIFIER_NODE' giving the name of the label can be obtained from
!      the 'LABEL_DECL' with 'DECL_NAME'.
  
! 'GOTO_EXPR'
  
!      Used to represent a 'goto' statement.  The 'GOTO_DESTINATION' will
!      usually be a 'LABEL_DECL'.  However, if the "computed goto"
!      extension has been used, the 'GOTO_DESTINATION' will be an
       arbitrary expression indicating the destination.  This expression
       will always have pointer type.
  
! 'RETURN_EXPR'
  
!      Used to represent a 'return' statement.  Operand 0 represents the
!      value to return.  It should either be the 'RESULT_DECL' for the
!      containing function, or a 'MODIFY_EXPR' or 'INIT_EXPR' setting the
!      function's 'RESULT_DECL'.  It will be 'NULL_TREE' if the statement
       was just
            return;
  
! 'LOOP_EXPR'
!      These nodes represent "infinite" loops.  The 'LOOP_EXPR_BODY'
       represents the body of the loop.  It should be executed forever,
!      unless an 'EXIT_EXPR' is encountered.
  
! 'EXIT_EXPR'
       These nodes represent conditional exits from the nearest enclosing
!      'LOOP_EXPR'.  The single operand is the condition; if it is
!      nonzero, then the loop should be exited.  An 'EXIT_EXPR' will only
!      appear within a 'LOOP_EXPR'.
  
! 'SWITCH_EXPR'
  
!      Used to represent a 'switch' statement.  The 'SWITCH_COND' is the
!      expression on which the switch is occurring.  The 'SWITCH_BODY' is
!      the body of the switch statement.  'SWITCH_ALL_CASES_P' is true if
       the switch includes a default label or the case label ranges cover
       all possible values of the condition expression.
  
!      Note that 'TREE_TYPE' for a 'SWITCH_EXPR' represents the original
       type of switch expression as given in the source, before any
       compiler conversions, instead of the type of the switch expression
       itself (which is not meaningful).
  
! 'CASE_LABEL_EXPR'
  
!      Use to represent a 'case' label, range of 'case' labels, or a
!      'default' label.  If 'CASE_LOW' is 'NULL_TREE', then this is a
!      'default' label.  Otherwise, if 'CASE_HIGH' is 'NULL_TREE', then
!      this is an ordinary 'case' label.  In this case, 'CASE_LOW' is an
!      expression giving the value of the label.  Both 'CASE_LOW' and
!      'CASE_HIGH' are 'INTEGER_CST' nodes.  These values will have the
       same type as the condition expression in the switch statement.
  
!      Otherwise, if both 'CASE_LOW' and 'CASE_HIGH' are defined, the
       statement is a range of case labels.  Such statements originate
       with the extension that allows users to write things of the form:
            case 2 ... 5:
!      The first value will be 'CASE_LOW', while the second will be
!      'CASE_HIGH'.
  
! 'DEBUG_BEGIN_STMT'
  
       Marks the beginning of a source statement, for purposes of debug
       information generation.
--- 11838,11943 ----
  11.7.1 Basic Statements
  -----------------------
  
! ‘ASM_EXPR’
  
       Used to represent an inline assembly statement.  For an inline
       assembly statement like:
            asm ("mov x, y");
!      The ‘ASM_STRING’ macro will return a ‘STRING_CST’ node for ‘"mov x,
!      y"’.  If the original statement made use of the extended-assembly
!      syntax, then ‘ASM_OUTPUTS’, ‘ASM_INPUTS’, and ‘ASM_CLOBBERS’ will
       be the outputs, inputs, and clobbers for the statement, represented
!      as ‘STRING_CST’ nodes.  The extended-assembly syntax looks like:
            asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
!      The first string is the ‘ASM_STRING’, containing the instruction
       template.  The next two strings are the output and inputs,
       respectively; this statement has no clobbers.  As this example
       indicates, "plain" assembly statements are merely a special case of
       extended assembly statements; they have no cv-qualifiers, outputs,
!      inputs, or clobbers.  All of the strings will be ‘NUL’-terminated,
!      and will contain no embedded ‘NUL’-characters.
  
!      If the assembly statement is declared ‘volatile’, or if the
       statement was not an extended assembly statement, and is therefore
!      implicitly volatile, then the predicate ‘ASM_VOLATILE_P’ will hold
!      of the ‘ASM_EXPR’.
  
! ‘DECL_EXPR’
  
!      Used to represent a local declaration.  The ‘DECL_EXPR_DECL’ macro
       can be used to obtain the entity declared.  This declaration may be
!      a ‘LABEL_DECL’, indicating that the label declared is a local
       label.  (As an extension, GCC allows the declaration of labels with
!      scope.)  In C, this declaration may be a ‘FUNCTION_DECL’,
       indicating the use of the GCC nested function extension.  For more
       information, *note Functions::.
  
! ‘LABEL_EXPR’
  
!      Used to represent a label.  The ‘LABEL_DECL’ declared by this
!      statement can be obtained with the ‘LABEL_EXPR_LABEL’ macro.  The
!      ‘IDENTIFIER_NODE’ giving the name of the label can be obtained from
!      the ‘LABEL_DECL’ with ‘DECL_NAME’.
  
! ‘GOTO_EXPR’
  
!      Used to represent a ‘goto’ statement.  The ‘GOTO_DESTINATION’ will
!      usually be a ‘LABEL_DECL’.  However, if the "computed goto"
!      extension has been used, the ‘GOTO_DESTINATION’ will be an
       arbitrary expression indicating the destination.  This expression
       will always have pointer type.
  
! ‘RETURN_EXPR’
  
!      Used to represent a ‘return’ statement.  Operand 0 represents the
!      value to return.  It should either be the ‘RESULT_DECL’ for the
!      containing function, or a ‘MODIFY_EXPR’ or ‘INIT_EXPR’ setting the
!      function's ‘RESULT_DECL’.  It will be ‘NULL_TREE’ if the statement
       was just
            return;
  
! ‘LOOP_EXPR’
!      These nodes represent "infinite" loops.  The ‘LOOP_EXPR_BODY’
       represents the body of the loop.  It should be executed forever,
!      unless an ‘EXIT_EXPR’ is encountered.
  
! ‘EXIT_EXPR’
       These nodes represent conditional exits from the nearest enclosing
!      ‘LOOP_EXPR’.  The single operand is the condition; if it is
!      nonzero, then the loop should be exited.  An ‘EXIT_EXPR’ will only
!      appear within a ‘LOOP_EXPR’.
  
! ‘SWITCH_EXPR’
  
!      Used to represent a ‘switch’ statement.  The ‘SWITCH_COND’ is the
!      expression on which the switch is occurring.  The ‘SWITCH_BODY’ is
!      the body of the switch statement.  ‘SWITCH_ALL_CASES_P’ is true if
       the switch includes a default label or the case label ranges cover
       all possible values of the condition expression.
  
!      Note that ‘TREE_TYPE’ for a ‘SWITCH_EXPR’ represents the original
       type of switch expression as given in the source, before any
       compiler conversions, instead of the type of the switch expression
       itself (which is not meaningful).
  
! ‘CASE_LABEL_EXPR’
  
!      Use to represent a ‘case’ label, range of ‘case’ labels, or a
!      ‘default’ label.  If ‘CASE_LOW’ is ‘NULL_TREE’, then this is a
!      ‘default’ label.  Otherwise, if ‘CASE_HIGH’ is ‘NULL_TREE’, then
!      this is an ordinary ‘case’ label.  In this case, ‘CASE_LOW’ is an
!      expression giving the value of the label.  Both ‘CASE_LOW’ and
!      ‘CASE_HIGH’ are ‘INTEGER_CST’ nodes.  These values will have the
       same type as the condition expression in the switch statement.
  
!      Otherwise, if both ‘CASE_LOW’ and ‘CASE_HIGH’ are defined, the
       statement is a range of case labels.  Such statements originate
       with the extension that allows users to write things of the form:
            case 2 ... 5:
!      The first value will be ‘CASE_LOW’, while the second will be
!      ‘CASE_HIGH’.
  
! ‘DEBUG_BEGIN_STMT’
  
       Marks the beginning of a source statement, for purposes of debug
       information generation.
*************** File: gccint.info,  Node: Blocks,  Next:
*** 11949,11980 ****
  -------------
  
  Block scopes and the variables they declare in GENERIC are expressed
! using the 'BIND_EXPR' code, which in previous versions of GCC was
  primarily used for the C statement-expression extension.
  
!  Variables in a block are collected into 'BIND_EXPR_VARS' in declaration
! order through their 'TREE_CHAIN' field.  Any runtime initialization is
! moved out of 'DECL_INITIAL' and into a statement in the controlled
  block.  When gimplifying from C or C++, this initialization replaces the
! 'DECL_STMT'.  These variables will never require cleanups.  The scope of
  these variables is just the body
  
   Variable-length arrays (VLAs) complicate this process, as their size
  often refers to variables initialized earlier in the block and their
  initialization involves an explicit stack allocation.  To handle this,
  we add an indirection and replace them with a pointer to stack space
! allocated by means of 'alloca'.  In most cases, we also arrange for this
! space to be reclaimed when the enclosing 'BIND_EXPR' is exited, the
! exception to this being when there is an explicit call to 'alloca' in
  the source code, in which case the stack is left depressed on exit of
! the 'BIND_EXPR'.
  
!  A C++ program will usually contain more 'BIND_EXPR's than there are
  syntactic blocks in the source code, since several C++ constructs have
  implicit scopes associated with them.  On the other hand, although the
  C++ front end uses pseudo-scopes to handle cleanups for objects with
  destructors, these don't translate into the GIMPLE form; multiple
! declarations at the same level use the same 'BIND_EXPR'.
  
  
  File: gccint.info,  Node: Statement Sequences,  Next: Empty Statements,  Prev: Blocks,  Up: Statements
--- 11949,11980 ----
  -------------
  
  Block scopes and the variables they declare in GENERIC are expressed
! using the ‘BIND_EXPR’ code, which in previous versions of GCC was
  primarily used for the C statement-expression extension.
  
!  Variables in a block are collected into ‘BIND_EXPR_VARS’ in declaration
! order through their ‘TREE_CHAIN’ field.  Any runtime initialization is
! moved out of ‘DECL_INITIAL’ and into a statement in the controlled
  block.  When gimplifying from C or C++, this initialization replaces the
! ‘DECL_STMT’.  These variables will never require cleanups.  The scope of
  these variables is just the body
  
   Variable-length arrays (VLAs) complicate this process, as their size
  often refers to variables initialized earlier in the block and their
  initialization involves an explicit stack allocation.  To handle this,
  we add an indirection and replace them with a pointer to stack space
! allocated by means of ‘alloca’.  In most cases, we also arrange for this
! space to be reclaimed when the enclosing ‘BIND_EXPR’ is exited, the
! exception to this being when there is an explicit call to ‘alloca’ in
  the source code, in which case the stack is left depressed on exit of
! the ‘BIND_EXPR’.
  
!  A C++ program will usually contain more ‘BIND_EXPR’s than there are
  syntactic blocks in the source code, since several C++ constructs have
  implicit scopes associated with them.  On the other hand, although the
  C++ front end uses pseudo-scopes to handle cleanups for objects with
  destructors, these don't translate into the GIMPLE form; multiple
! declarations at the same level use the same ‘BIND_EXPR’.
  
  
  File: gccint.info,  Node: Statement Sequences,  Next: Empty Statements,  Prev: Blocks,  Up: Statements
*************** File: gccint.info,  Node: Statement Sequ
*** 11983,11990 ****
  --------------------------
  
  Multiple statements at the same nesting level are collected into a
! 'STATEMENT_LIST'.  Statement lists are modified and traversed using the
! interface in 'tree-iterator.h'.
  
  
  File: gccint.info,  Node: Empty Statements,  Next: Jumps,  Prev: Statement Sequences,  Up: Statements
--- 11983,11990 ----
  --------------------------
  
  Multiple statements at the same nesting level are collected into a
! ‘STATEMENT_LIST’.  Statement lists are modified and traversed using the
! interface in ‘tree-iterator.h’.
  
  
  File: gccint.info,  Node: Empty Statements,  Next: Jumps,  Prev: Statement Sequences,  Up: Statements
*************** File: gccint.info,  Node: Empty Statemen
*** 11995,12005 ****
  Whenever possible, statements with no effect are discarded.  But if they
  are nested within another construct which cannot be discarded for some
  reason, they are instead replaced with an empty statement, generated by
! 'build_empty_stmt'.  Initially, all empty statements were shared, after
  the pattern of the Java front end, but this caused a lot of trouble in
  practice.
  
!  An empty statement is represented as '(void)0'.
  
  
  File: gccint.info,  Node: Jumps,  Next: Cleanups,  Prev: Empty Statements,  Up: Statements
--- 11995,12005 ----
  Whenever possible, statements with no effect are discarded.  But if they
  are nested within another construct which cannot be discarded for some
  reason, they are instead replaced with an empty statement, generated by
! ‘build_empty_stmt’.  Initially, all empty statements were shared, after
  the pattern of the Java front end, but this caused a lot of trouble in
  practice.
  
!  An empty statement is represented as ‘(void)0’.
  
  
  File: gccint.info,  Node: Jumps,  Next: Cleanups,  Prev: Empty Statements,  Up: Statements
*************** File: gccint.info,  Node: Jumps,  Next:
*** 12007,12023 ****
  11.7.5 Jumps
  ------------
  
! Other jumps are expressed by either 'GOTO_EXPR' or 'RETURN_EXPR'.
  
!  The operand of a 'GOTO_EXPR' must be either a label or a variable
  containing the address to jump to.
  
!  The operand of a 'RETURN_EXPR' is either 'NULL_TREE', 'RESULT_DECL', or
! a 'MODIFY_EXPR' which sets the return value.  It would be nice to move
! the 'MODIFY_EXPR' into a separate statement, but the special return
! semantics in 'expand_return' make that difficult.  It may still happen
  in the future, perhaps by moving most of that logic into
! 'expand_assignment'.
  
  
  File: gccint.info,  Node: Cleanups,  Next: OpenMP,  Prev: Jumps,  Up: Statements
--- 12007,12023 ----
  11.7.5 Jumps
  ------------
  
! Other jumps are expressed by either ‘GOTO_EXPR’ or ‘RETURN_EXPR’.
  
!  The operand of a ‘GOTO_EXPR’ must be either a label or a variable
  containing the address to jump to.
  
!  The operand of a ‘RETURN_EXPR’ is either ‘NULL_TREE’, ‘RESULT_DECL’, or
! a ‘MODIFY_EXPR’ which sets the return value.  It would be nice to move
! the ‘MODIFY_EXPR’ into a separate statement, but the special return
! semantics in ‘expand_return’ make that difficult.  It may still happen
  in the future, perhaps by moving most of that logic into
! ‘expand_assignment’.
  
  
  File: gccint.info,  Node: Cleanups,  Next: OpenMP,  Prev: Jumps,  Up: Statements
*************** File: gccint.info,  Node: Cleanups,  Nex
*** 12026,12032 ****
  ---------------
  
  Destructors for local C++ objects and similar dynamic cleanups are
! represented in GIMPLE by a 'TRY_FINALLY_EXPR'.  'TRY_FINALLY_EXPR' has
  two operands, both of which are a sequence of statements to execute.
  The first sequence is executed.  When it completes the second sequence
  is executed.
--- 12026,12032 ----
  ---------------
  
  Destructors for local C++ objects and similar dynamic cleanups are
! represented in GIMPLE by a ‘TRY_FINALLY_EXPR’.  ‘TRY_FINALLY_EXPR’ has
  two operands, both of which are a sequence of statements to execute.
  The first sequence is executed.  When it completes the second sequence
  is executed.
*************** is executed.
*** 12035,12050 ****
  
    1. Execute the last statement in the sequence and fall off the end.
  
!   2. Execute a goto statement ('GOTO_EXPR') to an ordinary label outside
       the sequence.
  
!   3. Execute a return statement ('RETURN_EXPR').
  
    4. Throw an exception.  This is currently not explicitly represented
       in GIMPLE.
  
   The second sequence is not executed if the first sequence completes by
! calling 'setjmp' or 'exit' or any other function that does not return.
  The second sequence is also not executed if the first sequence completes
  via a non-local goto or a computed goto (in general the compiler does
  not know whether such a goto statement exits the first sequence or not,
--- 12035,12050 ----
  
    1. Execute the last statement in the sequence and fall off the end.
  
!   2. Execute a goto statement (‘GOTO_EXPR’) to an ordinary label outside
       the sequence.
  
!   3. Execute a return statement (‘RETURN_EXPR’).
  
    4. Throw an exception.  This is currently not explicitly represented
       in GIMPLE.
  
   The second sequence is not executed if the first sequence completes by
! calling ‘setjmp’ or ‘exit’ or any other function that does not return.
  The second sequence is also not executed if the first sequence completes
  via a non-local goto or a computed goto (in general the compiler does
  not know whether such a goto statement exits the first sequence or not,
*************** so we assume that it doesn't).
*** 12054,12070 ****
  falling off the end, execution continues wherever the first sequence
  would have continued, by falling off the end, or doing a goto, etc.
  
!  If the second sequence is an 'EH_ELSE_EXPR' selector, then the sequence
  in its first operand is used when the first sequence completes normally,
  and that in its second operand is used for exceptional cleanups, i.e.,
  when an exception propagates out of the first sequence.
  
!  'TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs
  to appear on every edge out of the controlled block; this reduces the
  freedom to move code across these edges.  Therefore, the EH lowering
  pass which runs before most of the optimization passes eliminates these
  expressions by explicitly adding the cleanup to each edge.  Rethrowing
! the exception is represented using 'RESX_EXPR'.
  
  
  File: gccint.info,  Node: OpenMP,  Next: OpenACC,  Prev: Cleanups,  Up: Statements
--- 12054,12070 ----
  falling off the end, execution continues wherever the first sequence
  would have continued, by falling off the end, or doing a goto, etc.
  
!  If the second sequence is an ‘EH_ELSE_EXPR’ selector, then the sequence
  in its first operand is used when the first sequence completes normally,
  and that in its second operand is used for exceptional cleanups, i.e.,
  when an exception propagates out of the first sequence.
  
!  ‘TRY_FINALLY_EXPR’ complicates the flow graph, since the cleanup needs
  to appear on every edge out of the controlled block; this reduces the
  freedom to move code across these edges.  Therefore, the EH lowering
  pass which runs before most of the optimization passes eliminates these
  expressions by explicitly adding the cleanup to each edge.  Rethrowing
! the exception is represented using ‘RESX_EXPR’.
  
  
  File: gccint.info,  Node: OpenMP,  Next: OpenACC,  Prev: Cleanups,  Up: Statements
*************** File: gccint.info,  Node: OpenMP,  Next:
*** 12072,12112 ****
  11.7.7 OpenMP
  -------------
  
! All the statements starting with 'OMP_' represent directives and clauses
  used by the OpenMP API .
  
! 'OMP_PARALLEL'
  
!      Represents '#pragma omp parallel [clause1 ... clauseN]'.  It has
       four operands:
  
!      Operand 'OMP_PARALLEL_BODY' is valid while in GENERIC and High
       GIMPLE forms.  It contains the body of code to be executed by all
!      the threads.  During GIMPLE lowering, this operand becomes 'NULL'
!      and the body is emitted linearly after 'OMP_PARALLEL'.
  
!      Operand 'OMP_PARALLEL_CLAUSES' is the list of clauses associated
       with the directive.
  
!      Operand 'OMP_PARALLEL_FN' is created by 'pass_lower_omp', it
!      contains the 'FUNCTION_DECL' for the function that will contain the
       body of the parallel region.
  
!      Operand 'OMP_PARALLEL_DATA_ARG' is also created by
!      'pass_lower_omp'.  If there are shared variables to be communicated
!      to the children threads, this operand will contain the 'VAR_DECL'
       that contains all the shared values and variables.
  
! 'OMP_FOR'
! 'OMP_SIMD'
! 'OMP_DISTRIBUTE'
! 'OMP_TASKLOOP'
! 'OMP_LOOP'
  
!      Represents '#pragma omp for [clause1 ... clauseN]' and related loop
       constructs (respectively).
  
!      A single 'OMP_FOR' node represents an entire nest of collapsed
       loops; as noted below, some of its arguments are vectors of length
       equal to the collapse depth, and the corresponding elements holding
       data specific to a particular loop in the nest.  These vectors are
--- 12072,12112 ----
  11.7.7 OpenMP
  -------------
  
! All the statements starting with ‘OMP_’ represent directives and clauses
  used by the OpenMP API .
  
! ‘OMP_PARALLEL’
  
!      Represents ‘#pragma omp parallel [clause1 ... clauseN]’.  It has
       four operands:
  
!      Operand ‘OMP_PARALLEL_BODY’ is valid while in GENERIC and High
       GIMPLE forms.  It contains the body of code to be executed by all
!      the threads.  During GIMPLE lowering, this operand becomes ‘NULL’
!      and the body is emitted linearly after ‘OMP_PARALLEL’.
  
!      Operand ‘OMP_PARALLEL_CLAUSES’ is the list of clauses associated
       with the directive.
  
!      Operand ‘OMP_PARALLEL_FN’ is created by ‘pass_lower_omp’, it
!      contains the ‘FUNCTION_DECL’ for the function that will contain the
       body of the parallel region.
  
!      Operand ‘OMP_PARALLEL_DATA_ARG’ is also created by
!      ‘pass_lower_omp’.  If there are shared variables to be communicated
!      to the children threads, this operand will contain the ‘VAR_DECL’
       that contains all the shared values and variables.
  
! ‘OMP_FOR’
! ‘OMP_SIMD’
! ‘OMP_DISTRIBUTE’
! ‘OMP_TASKLOOP’
! ‘OMP_LOOP’
  
!      Represents ‘#pragma omp for [clause1 ... clauseN]’ and related loop
       constructs (respectively).
  
!      A single ‘OMP_FOR’ node represents an entire nest of collapsed
       loops; as noted below, some of its arguments are vectors of length
       equal to the collapse depth, and the corresponding elements holding
       data specific to a particular loop in the nest.  These vectors are
*************** used by the OpenMP API ,<=,>=} N2'.
  
!      Operand 'OMP_FOR_INCR' is a vector containing loop index increment
!      expressions of the form 'VAR {+=,-=} INCR'.
  
!      Operand 'OMP_FOR_PRE_BODY' contains side effect code from operands
!      'OMP_FOR_INIT', 'OMP_FOR_COND' and 'OMP_FOR_INCR'.  These side
!      effects are part of the 'OMP_FOR' block but must be evaluated
!      before the start of loop body.  'OMP_FOR_PRE_BODY' specifically
!      includes 'DECL_EXPR's for iteration variables that are declared in
!      the nested 'for' loops.  Note this field is not a vector; it may be
       null, but otherwise is usually a statement list collecting the side
       effect code from all the collapsed loops.
  
!      Operand 'OMP_FOR_ORIG_DECLS' holds 'VAR_DECLS' for the original
       user-specified iterator variables in the source code.  In some
!      cases, like C++ class iterators or range 'for' with decomposition,
!      the 'for' loop is rewritten by the front end to use a temporary
       iteration variable.  The purpose of this field is to make the
       original variables available to the gimplifier so it can adjust
       their data-sharing attributes and diagnose errors.
!      'OMP_FOR_ORIG_DECLS' is a vector field, with each element holding a
!      list of 'VAR_DECLS' for the corresponding collapse level.
  
!      The loop index variable 'VAR' must be a signed integer variable,
       which is implicitly private to each thread.  For rectangular loops,
!      the bounds 'N1' and 'N2' and the increment expression 'INCR' are
       required to be loop-invariant integer expressions that are
       evaluated without any synchronization.  The evaluation order,
       frequency of evaluation and side effects are otherwise unspecified
--- 12115,12156 ----
  
       These constructs have seven operands:
  
!      Operand ‘OMP_FOR_BODY’ contains the loop body.
  
!      Operand ‘OMP_FOR_CLAUSES’ is the list of clauses associated with
       the directive.
  
!      Operand ‘OMP_FOR_INIT’ is a vector containing iteration variable
!      initializations of the form ‘VAR = N1’.
  
!      Operand ‘OMP_FOR_COND’ is vector containing loop conditional
!      expressions of the form ‘VAR {<,>,<=,>=} N2’.
  
!      Operand ‘OMP_FOR_INCR’ is a vector containing loop index increment
!      expressions of the form ‘VAR {+=,-=} INCR’.
  
!      Operand ‘OMP_FOR_PRE_BODY’ contains side effect code from operands
!      ‘OMP_FOR_INIT’, ‘OMP_FOR_COND’ and ‘OMP_FOR_INCR’.  These side
!      effects are part of the ‘OMP_FOR’ block but must be evaluated
!      before the start of loop body.  ‘OMP_FOR_PRE_BODY’ specifically
!      includes ‘DECL_EXPR’s for iteration variables that are declared in
!      the nested ‘for’ loops.  Note this field is not a vector; it may be
       null, but otherwise is usually a statement list collecting the side
       effect code from all the collapsed loops.
  
!      Operand ‘OMP_FOR_ORIG_DECLS’ holds ‘VAR_DECLS’ for the original
       user-specified iterator variables in the source code.  In some
!      cases, like C++ class iterators or range ‘for’ with decomposition,
!      the ‘for’ loop is rewritten by the front end to use a temporary
       iteration variable.  The purpose of this field is to make the
       original variables available to the gimplifier so it can adjust
       their data-sharing attributes and diagnose errors.
!      ‘OMP_FOR_ORIG_DECLS’ is a vector field, with each element holding a
!      list of ‘VAR_DECLS’ for the corresponding collapse level.
  
!      The loop index variable ‘VAR’ must be a signed integer variable,
       which is implicitly private to each thread.  For rectangular loops,
!      the bounds ‘N1’ and ‘N2’ and the increment expression ‘INCR’ are
       required to be loop-invariant integer expressions that are
       evaluated without any synchronization.  The evaluation order,
       frequency of evaluation and side effects are otherwise unspecified
*************** used by the OpenMP API .
  
! 'OACC_CACHE'
  
!      Represents '#pragma acc cache (var ...)'.
  
! 'OACC_DATA'
  
!      Represents '#pragma acc data [clause1 ... clauseN]'.
  
! 'OACC_DECLARE'
  
!      Represents '#pragma acc declare [clause1 ... clauseN]'.
  
! 'OACC_ENTER_DATA'
  
!      Represents '#pragma acc enter data [clause1 ... clauseN]'.
  
! 'OACC_EXIT_DATA'
  
!      Represents '#pragma acc exit data [clause1 ... clauseN]'.
  
! 'OACC_HOST_DATA'
  
!      Represents '#pragma acc host_data [clause1 ... clauseN]'.
  
! 'OACC_KERNELS'
  
!      Represents '#pragma acc kernels [clause1 ... clauseN]'.
  
! 'OACC_LOOP'
  
!      Represents '#pragma acc loop [clause1 ... clauseN]'.
  
!      See the description of the 'OMP_FOR' code.
  
! 'OACC_PARALLEL'
  
!      Represents '#pragma acc parallel [clause1 ... clauseN]'.
  
! 'OACC_SERIAL'
  
!      Represents '#pragma acc serial [clause1 ... clauseN]'.
  
! 'OACC_UPDATE'
  
!      Represents '#pragma acc update [clause1 ... clauseN]'.
  
  
  File: gccint.info,  Node: Functions,  Next: Language-dependent trees,  Prev: Statements,  Up: GENERIC
--- 12270,12323 ----
  11.7.8 OpenACC
  --------------
  
! All the statements starting with ‘OACC_’ represent directives and
  clauses used by the OpenACC API .
  
! ‘OACC_CACHE’
  
!      Represents ‘#pragma acc cache (var ...)’.
  
! ‘OACC_DATA’
  
!      Represents ‘#pragma acc data [clause1 ... clauseN]’.
  
! ‘OACC_DECLARE’
  
!      Represents ‘#pragma acc declare [clause1 ... clauseN]’.
  
! ‘OACC_ENTER_DATA’
  
!      Represents ‘#pragma acc enter data [clause1 ... clauseN]’.
  
! ‘OACC_EXIT_DATA’
  
!      Represents ‘#pragma acc exit data [clause1 ... clauseN]’.
  
! ‘OACC_HOST_DATA’
  
!      Represents ‘#pragma acc host_data [clause1 ... clauseN]’.
  
! ‘OACC_KERNELS’
  
!      Represents ‘#pragma acc kernels [clause1 ... clauseN]’.
  
! ‘OACC_LOOP’
  
!      Represents ‘#pragma acc loop [clause1 ... clauseN]’.
  
!      See the description of the ‘OMP_FOR’ code.
  
! ‘OACC_PARALLEL’
  
!      Represents ‘#pragma acc parallel [clause1 ... clauseN]’.
  
! ‘OACC_SERIAL’
  
!      Represents ‘#pragma acc serial [clause1 ... clauseN]’.
  
! ‘OACC_UPDATE’
  
!      Represents ‘#pragma acc update [clause1 ... clauseN]’.
  
  
  File: gccint.info,  Node: Functions,  Next: Language-dependent trees,  Prev: Statements,  Up: GENERIC
*************** File: gccint.info,  Node: Functions,  Ne
*** 12325,12331 ****
  11.8 Functions
  ==============
  
! A function is represented by a 'FUNCTION_DECL' node.  It stores the
  basic pieces of the function such as body, parameters, and return type
  as well as information on the surrounding context, visibility, and
  linkage.
--- 12325,12331 ----
  11.8 Functions
  ==============
  
! A function is represented by a ‘FUNCTION_DECL’ node.  It stores the
  basic pieces of the function such as body, parameters, and return type
  as well as information on the surrounding context, visibility, and
  linkage.
*************** File: gccint.info,  Node: Function Basic
*** 12343,12402 ****
  
  A function has four core parts: the name, the parameters, the result,
  and the body.  The following macros and functions access these parts of
! a 'FUNCTION_DECL' as well as other basic features:
! 'DECL_NAME'
       This macro returns the unqualified name of the function, as an
!      'IDENTIFIER_NODE'.  For an instantiation of a function template,
!      the 'DECL_NAME' is the unqualified name of the template, not
!      something like 'f'.  The value of 'DECL_NAME' is undefined
       when used on a constructor, destructor, overloaded operator, or
       type-conversion operator, or any function that is implicitly
       generated by the compiler.  See below for macros that can be used
       to distinguish these cases.
  
! 'DECL_ASSEMBLER_NAME'
       This macro returns the mangled name of the function, also an
!      'IDENTIFIER_NODE'.  This name does not contain leading underscores
       on systems that prefix all identifiers with underscores.  The
       mangled name is computed in the same way on all platforms; if
       special processing is required to deal with the object file format
       used on a particular platform, it is the responsibility of the back
       end to perform those modifications.  (Of course, the back end
!      should not modify 'DECL_ASSEMBLER_NAME' itself.)
  
!      Using 'DECL_ASSEMBLER_NAME' will cause additional memory to be
       allocated (for the mangled name of the entity) so it should be used
       only when emitting assembly code.  It should not be used within the
       optimizers to determine whether or not two declarations are the
       same, even though some of the existing optimizers do use it in that
       way.  These uses will be removed over time.
  
! 'DECL_ARGUMENTS'
!      This macro returns the 'PARM_DECL' for the first argument to the
!      function.  Subsequent 'PARM_DECL' nodes can be obtained by
!      following the 'TREE_CHAIN' links.
  
! 'DECL_RESULT'
!      This macro returns the 'RESULT_DECL' for the function.
  
! 'DECL_SAVED_TREE'
       This macro returns the complete body of the function.
  
! 'TREE_TYPE'
!      This macro returns the 'FUNCTION_TYPE' or 'METHOD_TYPE' for the
       function.
  
! 'DECL_INITIAL'
       A function that has a definition in the current translation unit
!      will have a non-'NULL' 'DECL_INITIAL'.  However, back ends should
!      not make use of the particular value given by 'DECL_INITIAL'.
  
!      It should contain a tree of 'BLOCK' nodes that mirrors the scopes
       that variables are bound in the function.  Each block contains a
       list of decls declared in a basic block, a pointer to a chain of
       blocks at the next lower scope level, then a pointer to the next
!      block at the same level and a backpointer to the parent 'BLOCK' or
!      'FUNCTION_DECL'.  So given a function as follows:
  
            void foo()
            {
--- 12343,12402 ----
  
  A function has four core parts: the name, the parameters, the result,
  and the body.  The following macros and functions access these parts of
! a ‘FUNCTION_DECL’ as well as other basic features:
! ‘DECL_NAME’
       This macro returns the unqualified name of the function, as an
!      ‘IDENTIFIER_NODE’.  For an instantiation of a function template,
!      the ‘DECL_NAME’ is the unqualified name of the template, not
!      something like ‘f’.  The value of ‘DECL_NAME’ is undefined
       when used on a constructor, destructor, overloaded operator, or
       type-conversion operator, or any function that is implicitly
       generated by the compiler.  See below for macros that can be used
       to distinguish these cases.
  
! ‘DECL_ASSEMBLER_NAME’
       This macro returns the mangled name of the function, also an
!      ‘IDENTIFIER_NODE’.  This name does not contain leading underscores
       on systems that prefix all identifiers with underscores.  The
       mangled name is computed in the same way on all platforms; if
       special processing is required to deal with the object file format
       used on a particular platform, it is the responsibility of the back
       end to perform those modifications.  (Of course, the back end
!      should not modify ‘DECL_ASSEMBLER_NAME’ itself.)
  
!      Using ‘DECL_ASSEMBLER_NAME’ will cause additional memory to be
       allocated (for the mangled name of the entity) so it should be used
       only when emitting assembly code.  It should not be used within the
       optimizers to determine whether or not two declarations are the
       same, even though some of the existing optimizers do use it in that
       way.  These uses will be removed over time.
  
! ‘DECL_ARGUMENTS’
!      This macro returns the ‘PARM_DECL’ for the first argument to the
!      function.  Subsequent ‘PARM_DECL’ nodes can be obtained by
!      following the ‘TREE_CHAIN’ links.
  
! ‘DECL_RESULT’
!      This macro returns the ‘RESULT_DECL’ for the function.
  
! ‘DECL_SAVED_TREE’
       This macro returns the complete body of the function.
  
! ‘TREE_TYPE’
!      This macro returns the ‘FUNCTION_TYPE’ or ‘METHOD_TYPE’ for the
       function.
  
! ‘DECL_INITIAL’
       A function that has a definition in the current translation unit
!      will have a non-‘NULL’ ‘DECL_INITIAL’.  However, back ends should
!      not make use of the particular value given by ‘DECL_INITIAL’.
  
!      It should contain a tree of ‘BLOCK’ nodes that mirrors the scopes
       that variables are bound in the function.  Each block contains a
       list of decls declared in a basic block, a pointer to a chain of
       blocks at the next lower scope level, then a pointer to the next
!      block at the same level and a backpointer to the parent ‘BLOCK’ or
!      ‘FUNCTION_DECL’.  So given a function as follows:
  
            void foo()
            {
*************** File: gccint.info,  Node: Function Prope
*** 12432,12479 ****
  11.8.2 Function Properties
  --------------------------
  
! To determine the scope of a function, you can use the 'DECL_CONTEXT'
! macro.  This macro will return the class (either a 'RECORD_TYPE' or a
! 'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is
  a member.  For a virtual function, this macro returns the class in which
  the function was actually defined, not the base class in which the
  virtual declaration occurred.
  
!  In C, the 'DECL_CONTEXT' for a function maybe another function.  This
  representation indicates that the GNU nested function extension is in
  use.  For details on the semantics of nested functions, see the GCC
  Manual.  The nested function can refer to local variables in its
  containing function.  Such references are not explicitly marked in the
! tree structure; back ends must look at the 'DECL_CONTEXT' for the
! referenced 'VAR_DECL'.  If the 'DECL_CONTEXT' for the referenced
! 'VAR_DECL' is not the same as the function currently being processed,
! and neither 'DECL_EXTERNAL' nor 'TREE_STATIC' hold, then the reference
  is to a local variable in a containing function, and the back end must
  take appropriate action.
  
! 'DECL_EXTERNAL'
       This predicate holds if the function is undefined.
  
! 'TREE_PUBLIC'
       This predicate holds if the function has external linkage.
  
! 'TREE_STATIC'
       This predicate holds if the function has been defined.
  
! 'TREE_THIS_VOLATILE'
       This predicate holds if the function does not return normally.
  
! 'TREE_READONLY'
       This predicate holds if the function can only read its arguments.
  
! 'DECL_PURE_P'
       This predicate holds if the function can only read its arguments,
       but may also read global memory.
  
! 'DECL_VIRTUAL_P'
       This predicate holds if the function is virtual.
  
! 'DECL_ARTIFICIAL'
       This macro holds if the function was implicitly generated by the
       compiler, rather than explicitly declared.  In addition to
       implicitly generated class member functions, this macro holds for
--- 12432,12479 ----
  11.8.2 Function Properties
  --------------------------
  
! To determine the scope of a function, you can use the ‘DECL_CONTEXT’
! macro.  This macro will return the class (either a ‘RECORD_TYPE’ or a
! ‘UNION_TYPE’) or namespace (a ‘NAMESPACE_DECL’) of which the function is
  a member.  For a virtual function, this macro returns the class in which
  the function was actually defined, not the base class in which the
  virtual declaration occurred.
  
!  In C, the ‘DECL_CONTEXT’ for a function maybe another function.  This
  representation indicates that the GNU nested function extension is in
  use.  For details on the semantics of nested functions, see the GCC
  Manual.  The nested function can refer to local variables in its
  containing function.  Such references are not explicitly marked in the
! tree structure; back ends must look at the ‘DECL_CONTEXT’ for the
! referenced ‘VAR_DECL’.  If the ‘DECL_CONTEXT’ for the referenced
! ‘VAR_DECL’ is not the same as the function currently being processed,
! and neither ‘DECL_EXTERNAL’ nor ‘TREE_STATIC’ hold, then the reference
  is to a local variable in a containing function, and the back end must
  take appropriate action.
  
! ‘DECL_EXTERNAL’
       This predicate holds if the function is undefined.
  
! ‘TREE_PUBLIC’
       This predicate holds if the function has external linkage.
  
! ‘TREE_STATIC’
       This predicate holds if the function has been defined.
  
! ‘TREE_THIS_VOLATILE’
       This predicate holds if the function does not return normally.
  
! ‘TREE_READONLY’
       This predicate holds if the function can only read its arguments.
  
! ‘DECL_PURE_P’
       This predicate holds if the function can only read its arguments,
       but may also read global memory.
  
! ‘DECL_VIRTUAL_P’
       This predicate holds if the function is virtual.
  
! ‘DECL_ARTIFICIAL’
       This macro holds if the function was implicitly generated by the
       compiler, rather than explicitly declared.  In addition to
       implicitly generated class member functions, this macro holds for
*************** take appropriate action.
*** 12481,12496 ****
       and destruction, to compute run-time type information, and so
       forth.
  
! 'DECL_FUNCTION_SPECIFIC_TARGET'
       This macro returns a tree node that holds the target options that
!      are to be used to compile this particular function or 'NULL_TREE'
       if the function is to be compiled with the target options specified
       on the command line.
  
! 'DECL_FUNCTION_SPECIFIC_OPTIMIZATION'
       This macro returns a tree node that holds the optimization options
       that are to be used to compile this particular function or
!      'NULL_TREE' if the function is to be compiled with the optimization
       options specified on the command line.
  
  
--- 12481,12496 ----
       and destruction, to compute run-time type information, and so
       forth.
  
! ‘DECL_FUNCTION_SPECIFIC_TARGET’
       This macro returns a tree node that holds the target options that
!      are to be used to compile this particular function or ‘NULL_TREE’
       if the function is to be compiled with the target options specified
       on the command line.
  
! ‘DECL_FUNCTION_SPECIFIC_OPTIMIZATION’
       This macro returns a tree node that holds the optimization options
       that are to be used to compile this particular function or
!      ‘NULL_TREE’ if the function is to be compiled with the optimization
       options specified on the command line.
  
  
*************** File: gccint.info,  Node: Language-depen
*** 12502,12508 ****
  Front ends may wish to keep some state associated with various GENERIC
  trees while parsing.  To support this, trees provide a set of flags that
  may be used by the front end.  They are accessed using
! 'TREE_LANG_FLAG_n' where 'n' is currently 0 through 6.
  
   If necessary, a front end can use some language-dependent tree codes in
  its GENERIC representation, so long as it provides a hook for converting
--- 12502,12508 ----
  Front ends may wish to keep some state associated with various GENERIC
  trees while parsing.  To support this, trees provide a set of flags that
  may be used by the front end.  They are accessed using
! ‘TREE_LANG_FLAG_n’ where ‘n’ is currently 0 through 6.
  
   If necessary, a front end can use some language-dependent tree codes in
  its GENERIC representation, so long as it provides a hook for converting
*************** submit your patches for inclusion in GCC
*** 12566,12572 ****
  * Classes::                     Classes.
  * Functions for C++::           Overloading and accessors for C++.
  * Statements for C and C++::    Statements specific to C and C++.
! * C++ Expressions::    From 'typeid' to 'throw'.
  
  
  File: gccint.info,  Node: Types for C++,  Next: Namespaces,  Up: C and C++ Trees
--- 12566,12572 ----
  * Classes::                     Classes.
  * Functions for C++::           Overloading and accessors for C++.
  * Statements for C and C++::    Statements specific to C and C++.
! * C++ Expressions::    From ‘typeid’ to ‘throw’.
  
  
  File: gccint.info,  Node: Types for C++,  Next: Namespaces,  Up: C and C++ Trees
*************** representation.  The macros described he
*** 12580,12692 ****
  qualification of the underlying element type when applied to an array
  type.  (If the element type is itself an array, then the recursion
  continues until a non-array type is found, and the qualification of this
! type is examined.)  So, for example, 'CP_TYPE_CONST_P' will hold of the
! type 'const int ()[7]', denoting an array of seven 'int's.
  
   The following functions and macros deal with cv-qualification of types:
! 'cp_type_quals'
       This function returns the set of type qualifiers applied to this
!      type.  This value is 'TYPE_UNQUALIFIED' if no qualifiers have been
!      applied.  The 'TYPE_QUAL_CONST' bit is set if the type is
!      'const'-qualified.  The 'TYPE_QUAL_VOLATILE' bit is set if the type
!      is 'volatile'-qualified.  The 'TYPE_QUAL_RESTRICT' bit is set if
!      the type is 'restrict'-qualified.
  
! 'CP_TYPE_CONST_P'
!      This macro holds if the type is 'const'-qualified.
  
! 'CP_TYPE_VOLATILE_P'
!      This macro holds if the type is 'volatile'-qualified.
  
! 'CP_TYPE_RESTRICT_P'
!      This macro holds if the type is 'restrict'-qualified.
  
! 'CP_TYPE_CONST_NON_VOLATILE_P'
!      This predicate holds for a type that is 'const'-qualified, but
!      _not_ 'volatile'-qualified; other cv-qualifiers are ignored as
!      well: only the 'const'-ness is tested.
  
   A few other macros and functions are usable with all types:
! 'TYPE_SIZE'
       The number of bits required to represent the type, represented as
!      an 'INTEGER_CST'.  For an incomplete type, 'TYPE_SIZE' will be
!      'NULL_TREE'.
  
! 'TYPE_ALIGN'
!      The alignment of the type, in bits, represented as an 'int'.
  
! 'TYPE_NAME'
!      This macro returns a declaration (in the form of a 'TYPE_DECL') for
!      the type.  (Note this macro does _not_ return an 'IDENTIFIER_NODE',
       as you might expect, given its name!)  You can look at the
!      'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the
!      type.  The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a
       built-in type, the result of a typedef, or a named class type.
  
! 'CP_INTEGRAL_TYPE'
       This predicate holds if the type is an integral type.  Notice that
       in C++, enumerations are _not_ integral types.
  
! 'ARITHMETIC_TYPE_P'
       This predicate holds if the type is an integral type (in the C++
       sense) or a floating point type.
  
! 'CLASS_TYPE_P'
       This predicate holds for a class-type.
  
! 'TYPE_BUILT_IN'
       This predicate holds for a built-in type.
  
! 'TYPE_PTRDATAMEM_P'
       This predicate holds if the type is a pointer to data member.
  
! 'TYPE_PTR_P'
       This predicate holds if the type is a pointer type, and the pointee
       is not a data member.
  
! 'TYPE_PTRFN_P'
       This predicate holds for a pointer to function type.
  
! 'TYPE_PTROB_P'
       This predicate holds for a pointer to object type.  Note however
!      that it does not hold for the generic pointer to object type 'void
!      *'.  You may use 'TYPE_PTROBV_P' to test for a pointer to object
!      type as well as 'void *'.
  
   The table below describes types specific to C and C++ as well as
  language-dependent info about GENERIC types.
  
! 'POINTER_TYPE'
       Used to represent pointer types, and pointer to data member types.
!      If 'TREE_TYPE' is a pointer to data member type, then
!      'TYPE_PTRDATAMEM_P' will hold.  For a pointer to data member type
!      of the form 'T X::*', 'TYPE_PTRMEM_CLASS_TYPE' will be the type
!      'X', while 'TYPE_PTRMEM_POINTED_TO_TYPE' will be the type 'T'.
  
! 'RECORD_TYPE'
!      Used to represent 'struct' and 'class' types in C and C++.  If
!      'TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member
!      type.  In that case, the 'TYPE_PTRMEMFUNC_FN_TYPE' is a
!      'POINTER_TYPE' pointing to a 'METHOD_TYPE'.  The 'METHOD_TYPE' is
       the type of a function pointed to by the pointer-to-member
!      function.  If 'TYPE_PTRMEMFUNC_P' does not hold, this type is a
       class type.  For more information, *note Classes::.
  
! 'UNKNOWN_TYPE'
       This node is used to represent a type the knowledge of which is
       insufficient for a sound processing.
  
! 'TYPENAME_TYPE'
!      Used to represent a construct of the form 'typename T::A'.  The
!      'TYPE_CONTEXT' is 'T'; the 'TYPE_NAME' is an 'IDENTIFIER_NODE' for
!      'A'.  If the type is specified via a template-id, then
!      'TYPENAME_TYPE_FULLNAME' yields a 'TEMPLATE_ID_EXPR'.  The
!      'TREE_TYPE' is non-'NULL' if the node is implicitly generated in
       support for the implicit typename extension; in which case the
!      'TREE_TYPE' is a type node for the base-class.
  
! 'TYPEOF_TYPE'
!      Used to represent the '__typeof__' extension.  The 'TYPE_FIELDS' is
       the expression the type of which is being represented.
  
  
--- 12580,12692 ----
  qualification of the underlying element type when applied to an array
  type.  (If the element type is itself an array, then the recursion
  continues until a non-array type is found, and the qualification of this
! type is examined.)  So, for example, ‘CP_TYPE_CONST_P’ will hold of the
! type ‘const int ()[7]’, denoting an array of seven ‘int’s.
  
   The following functions and macros deal with cv-qualification of types:
! ‘cp_type_quals’
       This function returns the set of type qualifiers applied to this
!      type.  This value is ‘TYPE_UNQUALIFIED’ if no qualifiers have been
!      applied.  The ‘TYPE_QUAL_CONST’ bit is set if the type is
!      ‘const’-qualified.  The ‘TYPE_QUAL_VOLATILE’ bit is set if the type
!      is ‘volatile’-qualified.  The ‘TYPE_QUAL_RESTRICT’ bit is set if
!      the type is ‘restrict’-qualified.
  
! ‘CP_TYPE_CONST_P’
!      This macro holds if the type is ‘const’-qualified.
  
! ‘CP_TYPE_VOLATILE_P’
!      This macro holds if the type is ‘volatile’-qualified.
  
! ‘CP_TYPE_RESTRICT_P’
!      This macro holds if the type is ‘restrict’-qualified.
  
! ‘CP_TYPE_CONST_NON_VOLATILE_P’
!      This predicate holds for a type that is ‘const’-qualified, but
!      _not_ ‘volatile’-qualified; other cv-qualifiers are ignored as
!      well: only the ‘const’-ness is tested.
  
   A few other macros and functions are usable with all types:
! ‘TYPE_SIZE’
       The number of bits required to represent the type, represented as
!      an ‘INTEGER_CST’.  For an incomplete type, ‘TYPE_SIZE’ will be
!      ‘NULL_TREE’.
  
! ‘TYPE_ALIGN’
!      The alignment of the type, in bits, represented as an ‘int’.
  
! ‘TYPE_NAME’
!      This macro returns a declaration (in the form of a ‘TYPE_DECL’) for
!      the type.  (Note this macro does _not_ return an ‘IDENTIFIER_NODE’,
       as you might expect, given its name!)  You can look at the
!      ‘DECL_NAME’ of the ‘TYPE_DECL’ to obtain the actual name of the
!      type.  The ‘TYPE_NAME’ will be ‘NULL_TREE’ for a type that is not a
       built-in type, the result of a typedef, or a named class type.
  
! ‘CP_INTEGRAL_TYPE’
       This predicate holds if the type is an integral type.  Notice that
       in C++, enumerations are _not_ integral types.
  
! ‘ARITHMETIC_TYPE_P’
       This predicate holds if the type is an integral type (in the C++
       sense) or a floating point type.
  
! ‘CLASS_TYPE_P’
       This predicate holds for a class-type.
  
! ‘TYPE_BUILT_IN’
       This predicate holds for a built-in type.
  
! ‘TYPE_PTRDATAMEM_P’
       This predicate holds if the type is a pointer to data member.
  
! ‘TYPE_PTR_P’
       This predicate holds if the type is a pointer type, and the pointee
       is not a data member.
  
! ‘TYPE_PTRFN_P’
       This predicate holds for a pointer to function type.
  
! ‘TYPE_PTROB_P’
       This predicate holds for a pointer to object type.  Note however
!      that it does not hold for the generic pointer to object type ‘void
!      *’.  You may use ‘TYPE_PTROBV_P’ to test for a pointer to object
!      type as well as ‘void *’.
  
   The table below describes types specific to C and C++ as well as
  language-dependent info about GENERIC types.
  
! ‘POINTER_TYPE’
       Used to represent pointer types, and pointer to data member types.
!      If ‘TREE_TYPE’ is a pointer to data member type, then
!      ‘TYPE_PTRDATAMEM_P’ will hold.  For a pointer to data member type
!      of the form ‘T X::*’, ‘TYPE_PTRMEM_CLASS_TYPE’ will be the type
!      ‘X’, while ‘TYPE_PTRMEM_POINTED_TO_TYPE’ will be the type ‘T’.
  
! ‘RECORD_TYPE’
!      Used to represent ‘struct’ and ‘class’ types in C and C++.  If
!      ‘TYPE_PTRMEMFUNC_P’ holds, then this type is a pointer-to-member
!      type.  In that case, the ‘TYPE_PTRMEMFUNC_FN_TYPE’ is a
!      ‘POINTER_TYPE’ pointing to a ‘METHOD_TYPE’.  The ‘METHOD_TYPE’ is
       the type of a function pointed to by the pointer-to-member
!      function.  If ‘TYPE_PTRMEMFUNC_P’ does not hold, this type is a
       class type.  For more information, *note Classes::.
  
! ‘UNKNOWN_TYPE’
       This node is used to represent a type the knowledge of which is
       insufficient for a sound processing.
  
! ‘TYPENAME_TYPE’
!      Used to represent a construct of the form ‘typename T::A’.  The
!      ‘TYPE_CONTEXT’ is ‘T’; the ‘TYPE_NAME’ is an ‘IDENTIFIER_NODE’ for
!      ‘A’.  If the type is specified via a template-id, then
!      ‘TYPENAME_TYPE_FULLNAME’ yields a ‘TEMPLATE_ID_EXPR’.  The
!      ‘TREE_TYPE’ is non-‘NULL’ if the node is implicitly generated in
       support for the implicit typename extension; in which case the
!      ‘TREE_TYPE’ is a type node for the base-class.
  
! ‘TYPEOF_TYPE’
!      Used to represent the ‘__typeof__’ extension.  The ‘TYPE_FIELDS’ is
       the expression the type of which is being represented.
  
  
*************** File: gccint.info,  Node: Namespaces,  N
*** 12696,12702 ****
  ------------------
  
  The root of the entire intermediate representation is the variable
! 'global_namespace'.  This is the namespace specified with '::' in C++
  source code.  All other namespaces, types, variables, functions, and so
  forth can be found starting with this namespace.
  
--- 12696,12702 ----
  ------------------
  
  The root of the entire intermediate representation is the variable
! ‘global_namespace’.  This is the namespace specified with ‘::’ in C++
  source code.  All other namespaces, types, variables, functions, and so
  forth can be found starting with this namespace.
  
*************** the representation, the global namespace
*** 12705,12764 ****
  namespace.  Thus, in what follows, we describe namespaces generally,
  rather than the global namespace in particular.
  
!  A namespace is represented by a 'NAMESPACE_DECL' node.
  
!  The following macros and functions can be used on a 'NAMESPACE_DECL':
  
! 'DECL_NAME'
!      This macro is used to obtain the 'IDENTIFIER_NODE' corresponding to
       the unqualified name of the name of the namespace (*note
!      Identifiers::).  The name of the global namespace is '::', even
       though in C++ the global namespace is unnamed.  However, you should
!      use comparison with 'global_namespace', rather than 'DECL_NAME' to
       determine whether or not a namespace is the global one.  An unnamed
!      namespace will have a 'DECL_NAME' equal to
!      'anonymous_namespace_name'.  Within a single translation unit, all
       unnamed namespaces will have the same name.
  
! 'DECL_CONTEXT'
!      This macro returns the enclosing namespace.  The 'DECL_CONTEXT' for
!      the 'global_namespace' is 'NULL_TREE'.
  
! 'DECL_NAMESPACE_ALIAS'
       If this declaration is for a namespace alias, then
!      'DECL_NAMESPACE_ALIAS' is the namespace for which this one is an
       alias.
  
!      Do not attempt to use 'cp_namespace_decls' for a namespace which is
!      an alias.  Instead, follow 'DECL_NAMESPACE_ALIAS' links until you
       reach an ordinary, non-alias, namespace, and call
!      'cp_namespace_decls' there.
  
! 'DECL_NAMESPACE_STD_P'
!      This predicate holds if the namespace is the special '::std'
       namespace.
  
! 'cp_namespace_decls'
       This function will return the declarations contained in the
       namespace, including types, overloaded functions, other namespaces,
       and so forth.  If there are no declarations, this function will
!      return 'NULL_TREE'.  The declarations are connected through their
!      'TREE_CHAIN' fields.
  
       Although most entries on this list will be declarations,
!      'TREE_LIST' nodes may also appear.  In this case, the 'TREE_VALUE'
!      will be an 'OVERLOAD'.  The value of the 'TREE_PURPOSE' is
       unspecified; back ends should ignore this value.  As with the other
!      kinds of declarations returned by 'cp_namespace_decls', the
!      'TREE_CHAIN' will point to the next declaration in this list.
  
       For more information on the kinds of declarations that can occur on
       this list, *Note Declarations::.  Some declarations will not appear
!      on this list.  In particular, no 'FIELD_DECL', 'LABEL_DECL', or
!      'PARM_DECL' nodes will appear here.
  
       This function cannot be used with namespaces that have
!      'DECL_NAMESPACE_ALIAS' set.
  
  
  File: gccint.info,  Node: Classes,  Next: Functions for C++,  Prev: Namespaces,  Up: C and C++ Trees
--- 12705,12764 ----
  namespace.  Thus, in what follows, we describe namespaces generally,
  rather than the global namespace in particular.
  
!  A namespace is represented by a ‘NAMESPACE_DECL’ node.
  
!  The following macros and functions can be used on a ‘NAMESPACE_DECL’:
  
! ‘DECL_NAME’
!      This macro is used to obtain the ‘IDENTIFIER_NODE’ corresponding to
       the unqualified name of the name of the namespace (*note
!      Identifiers::).  The name of the global namespace is ‘::’, even
       though in C++ the global namespace is unnamed.  However, you should
!      use comparison with ‘global_namespace’, rather than ‘DECL_NAME’ to
       determine whether or not a namespace is the global one.  An unnamed
!      namespace will have a ‘DECL_NAME’ equal to
!      ‘anonymous_namespace_name’.  Within a single translation unit, all
       unnamed namespaces will have the same name.
  
! ‘DECL_CONTEXT’
!      This macro returns the enclosing namespace.  The ‘DECL_CONTEXT’ for
!      the ‘global_namespace’ is ‘NULL_TREE’.
  
! ‘DECL_NAMESPACE_ALIAS’
       If this declaration is for a namespace alias, then
!      ‘DECL_NAMESPACE_ALIAS’ is the namespace for which this one is an
       alias.
  
!      Do not attempt to use ‘cp_namespace_decls’ for a namespace which is
!      an alias.  Instead, follow ‘DECL_NAMESPACE_ALIAS’ links until you
       reach an ordinary, non-alias, namespace, and call
!      ‘cp_namespace_decls’ there.
  
! ‘DECL_NAMESPACE_STD_P’
!      This predicate holds if the namespace is the special ‘::std’
       namespace.
  
! ‘cp_namespace_decls’
       This function will return the declarations contained in the
       namespace, including types, overloaded functions, other namespaces,
       and so forth.  If there are no declarations, this function will
!      return ‘NULL_TREE’.  The declarations are connected through their
!      ‘TREE_CHAIN’ fields.
  
       Although most entries on this list will be declarations,
!      ‘TREE_LIST’ nodes may also appear.  In this case, the ‘TREE_VALUE’
!      will be an ‘OVERLOAD’.  The value of the ‘TREE_PURPOSE’ is
       unspecified; back ends should ignore this value.  As with the other
!      kinds of declarations returned by ‘cp_namespace_decls’, the
!      ‘TREE_CHAIN’ will point to the next declaration in this list.
  
       For more information on the kinds of declarations that can occur on
       this list, *Note Declarations::.  Some declarations will not appear
!      on this list.  In particular, no ‘FIELD_DECL’, ‘LABEL_DECL’, or
!      ‘PARM_DECL’ nodes will appear here.
  
       This function cannot be used with namespaces that have
!      ‘DECL_NAMESPACE_ALIAS’ set.
  
  
  File: gccint.info,  Node: Classes,  Next: Functions for C++,  Prev: Namespaces,  Up: C and C++ Trees
*************** File: gccint.info,  Node: Classes,  Next
*** 12767,12871 ****
  ---------------
  
  Besides namespaces, the other high-level scoping construct in C++ is the
! class.  (Throughout this manual the term "class" is used to mean the
  types referred to in the ANSI/ISO C++ Standard as classes; these include
! types defined with the 'class', 'struct', and 'union' keywords.)
  
!  A class type is represented by either a 'RECORD_TYPE' or a
! 'UNION_TYPE'.  A class declared with the 'union' tag is represented by a
! 'UNION_TYPE', while classes declared with either the 'struct' or the
! 'class' tag are represented by 'RECORD_TYPE's.  You can use the
! 'CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular
! type is a 'class' as opposed to a 'struct'.  This macro will be true
! only for classes declared with the 'class' tag.
  
!  Almost all members are available on the 'TYPE_FIELDS' list.  Given one
! member, the next can be found by following the 'TREE_CHAIN'.  You should
  not depend in any way on the order in which fields appear on this list.
! All nodes on this list will be 'DECL' nodes.  A 'FIELD_DECL' is used to
! represent a non-static data member, a 'VAR_DECL' is used to represent a
! static data member, and a 'TYPE_DECL' is used to represent a type.  Note
! that the 'CONST_DECL' for an enumeration constant will appear on this
  list, if the enumeration type was declared in the class.  (Of course,
! the 'TYPE_DECL' for the enumeration type will appear here as well.)
  There are no entries for base classes on this list.  In particular,
! there is no 'FIELD_DECL' for the "base-class portion" of an object.  If
  a function member is overloaded, each of the overloaded functions
! appears; no 'OVERLOAD' nodes appear on the 'TYPE_FIELDS' list.
  Implicitly declared functions (including default constructors, copy
  constructors, assignment operators, and destructors) will appear on this
  list as well.
  
!  The 'TYPE_VFIELD' is a compiler-generated field used to point to
! virtual function tables.  It may or may not appear on the 'TYPE_FIELDS'
! list.  However, back ends should handle the 'TYPE_VFIELD' just like all
! the entries on the 'TYPE_FIELDS' list.
  
!  Every class has an associated "binfo", which can be obtained with
! 'TYPE_BINFO'.  Binfos are used to represent base-classes.  The binfo
! given by 'TYPE_BINFO' is the degenerate case, whereby every class is
  considered to be its own base-class.  The base binfos for a particular
  binfo are held in a vector, whose length is obtained with
! 'BINFO_N_BASE_BINFOS'.  The base binfos themselves are obtained with
! 'BINFO_BASE_BINFO' and 'BINFO_BASE_ITERATE'.  To add a new binfo, use
! 'BINFO_BASE_APPEND'.  The vector of base binfos can be obtained with
! 'BINFO_BASE_BINFOS', but normally you do not need to use that.  The
! class type associated with a binfo is given by 'BINFO_TYPE'.  It is not
! always the case that 'BINFO_TYPE (TYPE_BINFO (x))', because of typedefs
! and qualified types.  Neither is it the case that 'TYPE_BINFO
! (BINFO_TYPE (y))' is the same binfo as 'y'.  The reason is that if 'y'
! is a binfo representing a base-class 'B' of a derived class 'D', then
! 'BINFO_TYPE (y)' will be 'B', and 'TYPE_BINFO (BINFO_TYPE (y))' will be
! 'B' as its own base-class, rather than as a base-class of 'D'.
  
!  The access to a base type can be found with 'BINFO_BASE_ACCESS'.  This
! will produce 'access_public_node', 'access_private_node' or
! 'access_protected_node'.  If bases are always public,
! 'BINFO_BASE_ACCESSES' may be 'NULL'.
  
!  'BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited
! virtually or not.  The other flags, 'BINFO_FLAG_0' to 'BINFO_FLAG_6',
  can be used for language specific use.
  
   The following macros can be used on a tree node representing a
  class-type.
  
! 'LOCAL_CLASS_P'
       This predicate holds if the class is local class _i.e._ declared
       inside a function body.
  
! 'TYPE_POLYMORPHIC_P'
       This predicate holds if the class has at least one virtual function
       (declared or inherited).
  
! 'TYPE_HAS_DEFAULT_CONSTRUCTOR'
       This predicate holds whenever its argument represents a class-type
       with default constructor.
  
! 'CLASSTYPE_HAS_MUTABLE'
! 'TYPE_HAS_MUTABLE_P'
       These predicates hold for a class-type having a mutable data
       member.
  
! 'CLASSTYPE_NON_POD_P'
       This predicate holds only for class-types that are not PODs.
  
! 'TYPE_HAS_NEW_OPERATOR'
!      This predicate holds for a class-type that defines 'operator new'.
  
! 'TYPE_HAS_ARRAY_NEW_OPERATOR'
!      This predicate holds for a class-type for which 'operator new[]' is
       defined.
  
! 'TYPE_OVERLOADS_CALL_EXPR'
       This predicate holds for class-type for which the function call
!      'operator()' is overloaded.
  
! 'TYPE_OVERLOADS_ARRAY_REF'
!      This predicate holds for a class-type that overloads 'operator[]'
  
! 'TYPE_OVERLOADS_ARROW'
!      This predicate holds for a class-type for which 'operator->' is
       overloaded.
  
  
--- 12767,12871 ----
  ---------------
  
  Besides namespaces, the other high-level scoping construct in C++ is the
! class.  (Throughout this manual the term “class” is used to mean the
  types referred to in the ANSI/ISO C++ Standard as classes; these include
! types defined with the ‘class’, ‘struct’, and ‘union’ keywords.)
  
!  A class type is represented by either a ‘RECORD_TYPE’ or a
! ‘UNION_TYPE’.  A class declared with the ‘union’ tag is represented by a
! ‘UNION_TYPE’, while classes declared with either the ‘struct’ or the
! ‘class’ tag are represented by ‘RECORD_TYPE’s.  You can use the
! ‘CLASSTYPE_DECLARED_CLASS’ macro to discern whether or not a particular
! type is a ‘class’ as opposed to a ‘struct’.  This macro will be true
! only for classes declared with the ‘class’ tag.
  
!  Almost all members are available on the ‘TYPE_FIELDS’ list.  Given one
! member, the next can be found by following the ‘TREE_CHAIN’.  You should
  not depend in any way on the order in which fields appear on this list.
! All nodes on this list will be ‘DECL’ nodes.  A ‘FIELD_DECL’ is used to
! represent a non-static data member, a ‘VAR_DECL’ is used to represent a
! static data member, and a ‘TYPE_DECL’ is used to represent a type.  Note
! that the ‘CONST_DECL’ for an enumeration constant will appear on this
  list, if the enumeration type was declared in the class.  (Of course,
! the ‘TYPE_DECL’ for the enumeration type will appear here as well.)
  There are no entries for base classes on this list.  In particular,
! there is no ‘FIELD_DECL’ for the "base-class portion" of an object.  If
  a function member is overloaded, each of the overloaded functions
! appears; no ‘OVERLOAD’ nodes appear on the ‘TYPE_FIELDS’ list.
  Implicitly declared functions (including default constructors, copy
  constructors, assignment operators, and destructors) will appear on this
  list as well.
  
!  The ‘TYPE_VFIELD’ is a compiler-generated field used to point to
! virtual function tables.  It may or may not appear on the ‘TYPE_FIELDS’
! list.  However, back ends should handle the ‘TYPE_VFIELD’ just like all
! the entries on the ‘TYPE_FIELDS’ list.
  
!  Every class has an associated “binfo”, which can be obtained with
! ‘TYPE_BINFO’.  Binfos are used to represent base-classes.  The binfo
! given by ‘TYPE_BINFO’ is the degenerate case, whereby every class is
  considered to be its own base-class.  The base binfos for a particular
  binfo are held in a vector, whose length is obtained with
! ‘BINFO_N_BASE_BINFOS’.  The base binfos themselves are obtained with
! ‘BINFO_BASE_BINFO’ and ‘BINFO_BASE_ITERATE’.  To add a new binfo, use
! ‘BINFO_BASE_APPEND’.  The vector of base binfos can be obtained with
! ‘BINFO_BASE_BINFOS’, but normally you do not need to use that.  The
! class type associated with a binfo is given by ‘BINFO_TYPE’.  It is not
! always the case that ‘BINFO_TYPE (TYPE_BINFO (x))’, because of typedefs
! and qualified types.  Neither is it the case that ‘TYPE_BINFO
! (BINFO_TYPE (y))’ is the same binfo as ‘y’.  The reason is that if ‘y’
! is a binfo representing a base-class ‘B’ of a derived class ‘D’, then
! ‘BINFO_TYPE (y)’ will be ‘B’, and ‘TYPE_BINFO (BINFO_TYPE (y))’ will be
! ‘B’ as its own base-class, rather than as a base-class of ‘D’.
  
!  The access to a base type can be found with ‘BINFO_BASE_ACCESS’.  This
! will produce ‘access_public_node’, ‘access_private_node’ or
! ‘access_protected_node’.  If bases are always public,
! ‘BINFO_BASE_ACCESSES’ may be ‘NULL’.
  
!  ‘BINFO_VIRTUAL_P’ is used to specify whether the binfo is inherited
! virtually or not.  The other flags, ‘BINFO_FLAG_0’ to ‘BINFO_FLAG_6’,
  can be used for language specific use.
  
   The following macros can be used on a tree node representing a
  class-type.
  
! ‘LOCAL_CLASS_P’
       This predicate holds if the class is local class _i.e._ declared
       inside a function body.
  
! ‘TYPE_POLYMORPHIC_P’
       This predicate holds if the class has at least one virtual function
       (declared or inherited).
  
! ‘TYPE_HAS_DEFAULT_CONSTRUCTOR’
       This predicate holds whenever its argument represents a class-type
       with default constructor.
  
! ‘CLASSTYPE_HAS_MUTABLE’
! ‘TYPE_HAS_MUTABLE_P’
       These predicates hold for a class-type having a mutable data
       member.
  
! ‘CLASSTYPE_NON_POD_P’
       This predicate holds only for class-types that are not PODs.
  
! ‘TYPE_HAS_NEW_OPERATOR’
!      This predicate holds for a class-type that defines ‘operator new’.
  
! ‘TYPE_HAS_ARRAY_NEW_OPERATOR’
!      This predicate holds for a class-type for which ‘operator new[]’ is
       defined.
  
! ‘TYPE_OVERLOADS_CALL_EXPR’
       This predicate holds for class-type for which the function call
!      ‘operator()’ is overloaded.
  
! ‘TYPE_OVERLOADS_ARRAY_REF’
!      This predicate holds for a class-type that overloads ‘operator[]’
  
! ‘TYPE_OVERLOADS_ARROW’
!      This predicate holds for a class-type for which ‘operator->’ is
       overloaded.
  
  
*************** File: gccint.info,  Node: Functions for
*** 12874,13001 ****
  11.10.4 Functions for C++
  -------------------------
  
! A function is represented by a 'FUNCTION_DECL' node.  A set of
! overloaded functions is sometimes represented by an 'OVERLOAD' node.
  
!  An 'OVERLOAD' node is not a declaration, so none of the 'DECL_' macros
! should be used on an 'OVERLOAD'.  An 'OVERLOAD' node is similar to a
! 'TREE_LIST'.  Use 'OVL_CURRENT' to get the function associated with an
! 'OVERLOAD' node; use 'OVL_NEXT' to get the next 'OVERLOAD' node in the
! list of overloaded functions.  The macros 'OVL_CURRENT' and 'OVL_NEXT'
! are actually polymorphic; you can use them to work with 'FUNCTION_DECL'
! nodes as well as with overloads.  In the case of a 'FUNCTION_DECL',
! 'OVL_CURRENT' will always return the function itself, and 'OVL_NEXT'
! will always be 'NULL_TREE'.
  
!  To determine the scope of a function, you can use the 'DECL_CONTEXT'
! macro.  This macro will return the class (either a 'RECORD_TYPE' or a
! 'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is
  a member.  For a virtual function, this macro returns the class in which
  the function was actually defined, not the base class in which the
  virtual declaration occurred.
  
   If a friend function is defined in a class scope, the
! 'DECL_FRIEND_CONTEXT' macro can be used to determine the class in which
  it was defined.  For example, in
       class C { friend void f() {} };
! the 'DECL_CONTEXT' for 'f' will be the 'global_namespace', but the
! 'DECL_FRIEND_CONTEXT' will be the 'RECORD_TYPE' for 'C'.
  
!  The following macros and functions can be used on a 'FUNCTION_DECL':
! 'DECL_MAIN_P'
       This predicate holds for a function that is the program entry point
!      '::code'.
  
! 'DECL_LOCAL_FUNCTION_P'
       This predicate holds if the function was declared at block scope,
       even though it has a global scope.
  
! 'DECL_ANTICIPATED'
       This predicate holds if the function is a built-in function but its
       prototype is not yet explicitly declared.
  
! 'DECL_EXTERN_C_FUNCTION_P'
!      This predicate holds if the function is declared as an ''extern
!      "C"'' function.
  
! 'DECL_LINKONCE_P'
       This macro holds if multiple copies of this function may be emitted
       in various translation units.  It is the responsibility of the
       linker to merge the various copies.  Template instantiations are
!      the most common example of functions for which 'DECL_LINKONCE_P'
       holds; G++ instantiates needed templates in all translation units
       which require them, and then relies on the linker to remove
       duplicate instantiations.
  
       FIXME: This macro is not yet implemented.
  
! 'DECL_FUNCTION_MEMBER_P'
       This macro holds if the function is a member of a class, rather
       than a member of a namespace.
  
! 'DECL_STATIC_FUNCTION_P'
       This predicate holds if the function a static member function.
  
! 'DECL_NONSTATIC_MEMBER_FUNCTION_P'
       This macro holds for a non-static member function.
  
! 'DECL_CONST_MEMFUNC_P'
!      This predicate holds for a 'const'-member function.
  
! 'DECL_VOLATILE_MEMFUNC_P'
!      This predicate holds for a 'volatile'-member function.
  
! 'DECL_CONSTRUCTOR_P'
       This macro holds if the function is a constructor.
  
! 'DECL_NONCONVERTING_P'
       This predicate holds if the constructor is a non-converting
       constructor.
  
! 'DECL_COMPLETE_CONSTRUCTOR_P'
       This predicate holds for a function which is a constructor for an
       object of a complete type.
  
! 'DECL_BASE_CONSTRUCTOR_P'
       This predicate holds for a function which is a constructor for a
       base class sub-object.
  
! 'DECL_COPY_CONSTRUCTOR_P'
       This predicate holds for a function which is a copy-constructor.
  
! 'DECL_DESTRUCTOR_P'
       This macro holds if the function is a destructor.
  
! 'DECL_COMPLETE_DESTRUCTOR_P'
       This predicate holds if the function is the destructor for an
       object a complete type.
  
! 'DECL_OVERLOADED_OPERATOR_P'
       This macro holds if the function is an overloaded operator.
  
! 'DECL_CONV_FN_P'
       This macro holds if the function is a type-conversion operator.
  
! 'DECL_GLOBAL_CTOR_P'
       This predicate holds if the function is a file-scope initialization
       function.
  
! 'DECL_GLOBAL_DTOR_P'
       This predicate holds if the function is a file-scope finalization
       function.
  
! 'DECL_THUNK_P'
       This predicate holds if the function is a thunk.
  
!      These functions represent stub code that adjusts the 'this' pointer
       and then jumps to another function.  When the jumped-to function
       returns, control is transferred directly to the caller, without
       returning to the thunk.  The first parameter to the thunk is always
!      the 'this' pointer; the thunk should add 'THUNK_DELTA' to this
!      value.  (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.)
  
!      Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the
!      adjusted 'this' pointer must be adjusted again.  The complete
       calculation is given by the following pseudo-code:
  
            this += THUNK_DELTA
--- 12874,13001 ----
  11.10.4 Functions for C++
  -------------------------
  
! A function is represented by a ‘FUNCTION_DECL’ node.  A set of
! overloaded functions is sometimes represented by an ‘OVERLOAD’ node.
  
!  An ‘OVERLOAD’ node is not a declaration, so none of the ‘DECL_’ macros
! should be used on an ‘OVERLOAD’.  An ‘OVERLOAD’ node is similar to a
! ‘TREE_LIST’.  Use ‘OVL_CURRENT’ to get the function associated with an
! ‘OVERLOAD’ node; use ‘OVL_NEXT’ to get the next ‘OVERLOAD’ node in the
! list of overloaded functions.  The macros ‘OVL_CURRENT’ and ‘OVL_NEXT’
! are actually polymorphic; you can use them to work with ‘FUNCTION_DECL’
! nodes as well as with overloads.  In the case of a ‘FUNCTION_DECL’,
! ‘OVL_CURRENT’ will always return the function itself, and ‘OVL_NEXT’
! will always be ‘NULL_TREE’.
  
!  To determine the scope of a function, you can use the ‘DECL_CONTEXT’
! macro.  This macro will return the class (either a ‘RECORD_TYPE’ or a
! ‘UNION_TYPE’) or namespace (a ‘NAMESPACE_DECL’) of which the function is
  a member.  For a virtual function, this macro returns the class in which
  the function was actually defined, not the base class in which the
  virtual declaration occurred.
  
   If a friend function is defined in a class scope, the
! ‘DECL_FRIEND_CONTEXT’ macro can be used to determine the class in which
  it was defined.  For example, in
       class C { friend void f() {} };
! the ‘DECL_CONTEXT’ for ‘f’ will be the ‘global_namespace’, but the
! ‘DECL_FRIEND_CONTEXT’ will be the ‘RECORD_TYPE’ for ‘C’.
  
!  The following macros and functions can be used on a ‘FUNCTION_DECL’:
! ‘DECL_MAIN_P’
       This predicate holds for a function that is the program entry point
!      ‘::code’.
  
! ‘DECL_LOCAL_FUNCTION_P’
       This predicate holds if the function was declared at block scope,
       even though it has a global scope.
  
! ‘DECL_ANTICIPATED’
       This predicate holds if the function is a built-in function but its
       prototype is not yet explicitly declared.
  
! ‘DECL_EXTERN_C_FUNCTION_P’
!      This predicate holds if the function is declared as an '‘extern
!      "C"’' function.
  
! ‘DECL_LINKONCE_P’
       This macro holds if multiple copies of this function may be emitted
       in various translation units.  It is the responsibility of the
       linker to merge the various copies.  Template instantiations are
!      the most common example of functions for which ‘DECL_LINKONCE_P’
       holds; G++ instantiates needed templates in all translation units
       which require them, and then relies on the linker to remove
       duplicate instantiations.
  
       FIXME: This macro is not yet implemented.
  
! ‘DECL_FUNCTION_MEMBER_P’
       This macro holds if the function is a member of a class, rather
       than a member of a namespace.
  
! ‘DECL_STATIC_FUNCTION_P’
       This predicate holds if the function a static member function.
  
! ‘DECL_NONSTATIC_MEMBER_FUNCTION_P’
       This macro holds for a non-static member function.
  
! ‘DECL_CONST_MEMFUNC_P’
!      This predicate holds for a ‘const’-member function.
  
! ‘DECL_VOLATILE_MEMFUNC_P’
!      This predicate holds for a ‘volatile’-member function.
  
! ‘DECL_CONSTRUCTOR_P’
       This macro holds if the function is a constructor.
  
! ‘DECL_NONCONVERTING_P’
       This predicate holds if the constructor is a non-converting
       constructor.
  
! ‘DECL_COMPLETE_CONSTRUCTOR_P’
       This predicate holds for a function which is a constructor for an
       object of a complete type.
  
! ‘DECL_BASE_CONSTRUCTOR_P’
       This predicate holds for a function which is a constructor for a
       base class sub-object.
  
! ‘DECL_COPY_CONSTRUCTOR_P’
       This predicate holds for a function which is a copy-constructor.
  
! ‘DECL_DESTRUCTOR_P’
       This macro holds if the function is a destructor.
  
! ‘DECL_COMPLETE_DESTRUCTOR_P’
       This predicate holds if the function is the destructor for an
       object a complete type.
  
! ‘DECL_OVERLOADED_OPERATOR_P’
       This macro holds if the function is an overloaded operator.
  
! ‘DECL_CONV_FN_P’
       This macro holds if the function is a type-conversion operator.
  
! ‘DECL_GLOBAL_CTOR_P’
       This predicate holds if the function is a file-scope initialization
       function.
  
! ‘DECL_GLOBAL_DTOR_P’
       This predicate holds if the function is a file-scope finalization
       function.
  
! ‘DECL_THUNK_P’
       This predicate holds if the function is a thunk.
  
!      These functions represent stub code that adjusts the ‘this’ pointer
       and then jumps to another function.  When the jumped-to function
       returns, control is transferred directly to the caller, without
       returning to the thunk.  The first parameter to the thunk is always
!      the ‘this’ pointer; the thunk should add ‘THUNK_DELTA’ to this
!      value.  (The ‘THUNK_DELTA’ is an ‘int’, not an ‘INTEGER_CST’.)
  
!      Then, if ‘THUNK_VCALL_OFFSET’ (an ‘INTEGER_CST’) is nonzero the
!      adjusted ‘this’ pointer must be adjusted again.  The complete
       calculation is given by the following pseudo-code:
  
            this += THUNK_DELTA
*************** the 'DECL_CONTEXT' for 'f' will be the '
*** 13003,13034 ****
              this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
  
       Finally, the thunk should jump to the location given by
!      'DECL_INITIAL'; this will always be an expression for the address
       of a function.
  
! 'DECL_NON_THUNK_FUNCTION_P'
       This predicate holds if the function is _not_ a thunk function.
  
! 'GLOBAL_INIT_PRIORITY'
!      If either 'DECL_GLOBAL_CTOR_P' or 'DECL_GLOBAL_DTOR_P' holds, then
       this gives the initialization priority for the function.  The
       linker will arrange that all functions for which
!      'DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority
!      before 'main' is called.  When the program exits, all functions for
!      which 'DECL_GLOBAL_DTOR_P' holds are run in the reverse order.
  
! 'TYPE_RAISES_EXCEPTIONS'
       This macro returns the list of exceptions that a (member-)function
!      can raise.  The returned list, if non 'NULL', is comprised of nodes
!      whose 'TREE_VALUE' represents a type.
  
! 'TYPE_NOTHROW_P'
       This predicate holds when the exception-specification of its
!      arguments is of the form ''()''.
  
! 'DECL_ARRAY_DELETE_OPERATOR_P'
!      This predicate holds if the function an overloaded 'operator
!      delete[]'.
  
  
  File: gccint.info,  Node: Statements for C and C++,  Next: C++ Expressions,  Prev: Functions for C++,  Up: C and C++ Trees
--- 13003,13034 ----
              this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
  
       Finally, the thunk should jump to the location given by
!      ‘DECL_INITIAL’; this will always be an expression for the address
       of a function.
  
! ‘DECL_NON_THUNK_FUNCTION_P’
       This predicate holds if the function is _not_ a thunk function.
  
! ‘GLOBAL_INIT_PRIORITY’
!      If either ‘DECL_GLOBAL_CTOR_P’ or ‘DECL_GLOBAL_DTOR_P’ holds, then
       this gives the initialization priority for the function.  The
       linker will arrange that all functions for which
!      ‘DECL_GLOBAL_CTOR_P’ holds are run in increasing order of priority
!      before ‘main’ is called.  When the program exits, all functions for
!      which ‘DECL_GLOBAL_DTOR_P’ holds are run in the reverse order.
  
! ‘TYPE_RAISES_EXCEPTIONS’
       This macro returns the list of exceptions that a (member-)function
!      can raise.  The returned list, if non ‘NULL’, is comprised of nodes
!      whose ‘TREE_VALUE’ represents a type.
  
! ‘TYPE_NOTHROW_P’
       This predicate holds when the exception-specification of its
!      arguments is of the form '‘()’'.
  
! ‘DECL_ARRAY_DELETE_OPERATOR_P’
!      This predicate holds if the function an overloaded ‘operator
!      delete[]’.
  
  
  File: gccint.info,  Node: Statements for C and C++,  Next: C++ Expressions,  Prev: Functions for C++,  Up: C and C++ Trees
*************** File: gccint.info,  Node: Statements for
*** 13037,13046 ****
  --------------------------------
  
  A function that has a definition in the current translation unit has a
! non-'NULL' 'DECL_INITIAL'.  However, back ends should not make use of
! the particular value given by 'DECL_INITIAL'.
  
!  The 'DECL_SAVED_TREE' gives the complete body of the function.
  
   There are tree nodes corresponding to all of the source-level statement
  constructs, used within the C and C++ frontends.  These are enumerated
--- 13037,13046 ----
  --------------------------------
  
  A function that has a definition in the current translation unit has a
! non-‘NULL’ ‘DECL_INITIAL’.  However, back ends should not make use of
! the particular value given by ‘DECL_INITIAL’.
  
!  The ‘DECL_SAVED_TREE’ gives the complete body of the function.
  
   There are tree nodes corresponding to all of the source-level statement
  constructs, used within the C and C++ frontends.  These are enumerated
*************** here, together with a list of the variou
*** 13048,13061 ****
  obtain information about them.  There are a few macros that can be used
  with all statements:
  
! 'STMT_IS_FULL_EXPR_P'
       In C++, statements normally constitute "full expressions";
       temporaries created during a statement are destroyed when the
       statement is complete.  However, G++ sometimes represents
       expressions by statements; these statements will not have
!      'STMT_IS_FULL_EXPR_P' set.  Temporaries created during such
       statements should be destroyed when the innermost enclosing
!      statement with 'STMT_IS_FULL_EXPR_P' set is exited.
  
   Here is the list of the various statement nodes, and the macros used to
  access them.  This documentation describes the use of these nodes in
--- 13048,13061 ----
  obtain information about them.  There are a few macros that can be used
  with all statements:
  
! ‘STMT_IS_FULL_EXPR_P’
       In C++, statements normally constitute "full expressions";
       temporaries created during a statement are destroyed when the
       statement is complete.  However, G++ sometimes represents
       expressions by statements; these statements will not have
!      ‘STMT_IS_FULL_EXPR_P’ set.  Temporaries created during such
       statements should be destroyed when the innermost enclosing
!      statement with ‘STMT_IS_FULL_EXPR_P’ set is exited.
  
   Here is the list of the various statement nodes, and the macros used to
  access them.  This documentation describes the use of these nodes in
*************** non-template functions (including instan
*** 13063,13074 ****
  In template functions, the same nodes are used, but sometimes in
  slightly different ways.
  
!  Many of the statements have substatements.  For example, a 'while' loop
  has a body, which is itself a statement.  If the substatement is
! 'NULL_TREE', it is considered equivalent to a statement consisting of a
! single ';', i.e., an expression statement in which the expression has
  been omitted.  A substatement may in fact be a list of statements,
! connected via their 'TREE_CHAIN's.  So, you should always process the
  statement tree by looping over substatements, like this:
       void process_stmt (stmt)
            tree stmt;
--- 13063,13074 ----
  In template functions, the same nodes are used, but sometimes in
  slightly different ways.
  
!  Many of the statements have substatements.  For example, a ‘while’ loop
  has a body, which is itself a statement.  If the substatement is
! ‘NULL_TREE’, it is considered equivalent to a statement consisting of a
! single ‘;’, i.e., an expression statement in which the expression has
  been omitted.  A substatement may in fact be a list of statements,
! connected via their ‘TREE_CHAIN’s.  So, you should always process the
  statement tree by looping over substatements, like this:
       void process_stmt (stmt)
            tree stmt;
*************** statement tree by looping over substatem
*** 13088,13173 ****
             stmt = TREE_CHAIN (stmt);
           }
       }
!  In other words, while the 'then' clause of an 'if' statement in C++ can
  be only one statement (although that one statement may be a compound
  statement), the intermediate representation sometimes uses several
  statements chained together.
  
! 'BREAK_STMT'
  
!      Used to represent a 'break' statement.  There are no additional
       fields.
  
! 'CLEANUP_STMT'
  
       Used to represent an action that should take place upon exit from
       the enclosing scope.  Typically, these actions are calls to
       destructors for local objects, but back ends cannot rely on this
       fact.  If these nodes are in fact representing such destructors,
!      'CLEANUP_DECL' will be the 'VAR_DECL' destroyed.  Otherwise,
!      'CLEANUP_DECL' will be 'NULL_TREE'.  In any case, the
!      'CLEANUP_EXPR' is the expression to execute.  The cleanups executed
       on exit from a scope should be run in the reverse order of the
!      order in which the associated 'CLEANUP_STMT's were encountered.
  
! 'CONTINUE_STMT'
  
!      Used to represent a 'continue' statement.  There are no additional
       fields.
  
! 'CTOR_STMT'
  
!      Used to mark the beginning (if 'CTOR_BEGIN_P' holds) or end (if
!      'CTOR_END_P' holds of the main body of a constructor.  See also
!      'SUBOBJECT' for more information on how to use these nodes.
  
! 'DO_STMT'
  
!      Used to represent a 'do' loop.  The body of the loop is given by
!      'DO_BODY' while the termination condition for the loop is given by
!      'DO_COND'.  The condition for a 'do'-statement is always an
       expression.
  
! 'EMPTY_CLASS_EXPR'
  
       Used to represent a temporary object of a class with no data whose
       address is never taken.  (All such objects are interchangeable.)
!      The 'TREE_TYPE' represents the type of the object.
  
! 'EXPR_STMT'
  
!      Used to represent an expression statement.  Use 'EXPR_STMT_EXPR' to
       obtain the expression.
  
! 'FOR_STMT'
  
!      Used to represent a 'for' statement.  The 'FOR_INIT_STMT' is the
!      initialization statement for the loop.  The 'FOR_COND' is the
!      termination condition.  The 'FOR_EXPR' is the expression executed
!      right before the 'FOR_COND' on each loop iteration; often, this
       expression increments a counter.  The body of the loop is given by
!      'FOR_BODY'.  'FOR_SCOPE' holds the scope of the 'for' statement
!      (used in the C++ front end only).  Note that 'FOR_INIT_STMT' and
!      'FOR_BODY' return statements, while 'FOR_COND' and 'FOR_EXPR'
       return expressions.
  
! 'HANDLER'
  
!      Used to represent a C++ 'catch' block.  The 'HANDLER_TYPE' is the
       type of exception that will be caught by this handler; it is equal
!      (by pointer equality) to 'NULL' if this handler is for all types.
!      'HANDLER_PARMS' is the 'DECL_STMT' for the catch parameter, and
!      'HANDLER_BODY' is the code for the block itself.
  
! 'IF_STMT'
  
!      Used to represent an 'if' statement.  The 'IF_COND' is the
       expression.
  
!      If the condition is a 'TREE_LIST', then the 'TREE_PURPOSE' is a
!      statement (usually a 'DECL_STMT').  Each time the condition is
       evaluated, the statement should be executed.  Then, the
!      'TREE_VALUE' should be used as the conditional expression itself.
       This representation is used to handle C++ code like this:
  
            if (int i = 7) ...
--- 13088,13173 ----
             stmt = TREE_CHAIN (stmt);
           }
       }
!  In other words, while the ‘then’ clause of an ‘if’ statement in C++ can
  be only one statement (although that one statement may be a compound
  statement), the intermediate representation sometimes uses several
  statements chained together.
  
! ‘BREAK_STMT’
  
!      Used to represent a ‘break’ statement.  There are no additional
       fields.
  
! ‘CLEANUP_STMT’
  
       Used to represent an action that should take place upon exit from
       the enclosing scope.  Typically, these actions are calls to
       destructors for local objects, but back ends cannot rely on this
       fact.  If these nodes are in fact representing such destructors,
!      ‘CLEANUP_DECL’ will be the ‘VAR_DECL’ destroyed.  Otherwise,
!      ‘CLEANUP_DECL’ will be ‘NULL_TREE’.  In any case, the
!      ‘CLEANUP_EXPR’ is the expression to execute.  The cleanups executed
       on exit from a scope should be run in the reverse order of the
!      order in which the associated ‘CLEANUP_STMT’s were encountered.
  
! ‘CONTINUE_STMT’
  
!      Used to represent a ‘continue’ statement.  There are no additional
       fields.
  
! ‘CTOR_STMT’
  
!      Used to mark the beginning (if ‘CTOR_BEGIN_P’ holds) or end (if
!      ‘CTOR_END_P’ holds of the main body of a constructor.  See also
!      ‘SUBOBJECT’ for more information on how to use these nodes.
  
! ‘DO_STMT’
  
!      Used to represent a ‘do’ loop.  The body of the loop is given by
!      ‘DO_BODY’ while the termination condition for the loop is given by
!      ‘DO_COND’.  The condition for a ‘do’-statement is always an
       expression.
  
! ‘EMPTY_CLASS_EXPR’
  
       Used to represent a temporary object of a class with no data whose
       address is never taken.  (All such objects are interchangeable.)
!      The ‘TREE_TYPE’ represents the type of the object.
  
! ‘EXPR_STMT’
  
!      Used to represent an expression statement.  Use ‘EXPR_STMT_EXPR’ to
       obtain the expression.
  
! ‘FOR_STMT’
  
!      Used to represent a ‘for’ statement.  The ‘FOR_INIT_STMT’ is the
!      initialization statement for the loop.  The ‘FOR_COND’ is the
!      termination condition.  The ‘FOR_EXPR’ is the expression executed
!      right before the ‘FOR_COND’ on each loop iteration; often, this
       expression increments a counter.  The body of the loop is given by
!      ‘FOR_BODY’.  ‘FOR_SCOPE’ holds the scope of the ‘for’ statement
!      (used in the C++ front end only).  Note that ‘FOR_INIT_STMT’ and
!      ‘FOR_BODY’ return statements, while ‘FOR_COND’ and ‘FOR_EXPR’
       return expressions.
  
! ‘HANDLER’
  
!      Used to represent a C++ ‘catch’ block.  The ‘HANDLER_TYPE’ is the
       type of exception that will be caught by this handler; it is equal
!      (by pointer equality) to ‘NULL’ if this handler is for all types.
!      ‘HANDLER_PARMS’ is the ‘DECL_STMT’ for the catch parameter, and
!      ‘HANDLER_BODY’ is the code for the block itself.
  
! ‘IF_STMT’
  
!      Used to represent an ‘if’ statement.  The ‘IF_COND’ is the
       expression.
  
!      If the condition is a ‘TREE_LIST’, then the ‘TREE_PURPOSE’ is a
!      statement (usually a ‘DECL_STMT’).  Each time the condition is
       evaluated, the statement should be executed.  Then, the
!      ‘TREE_VALUE’ should be used as the conditional expression itself.
       This representation is used to handle C++ code like this:
  
            if (int i = 7) ...
*************** statements chained together.
*** 13175,13242 ****
       where there is a new local variable (or variables) declared within
       the condition.
  
!      The 'THEN_CLAUSE' represents the statement given by the 'then'
!      condition, while the 'ELSE_CLAUSE' represents the statement given
!      by the 'else' condition.
  
!      C++ distinguishes between this and 'COND_EXPR' for handling
       templates.
  
! 'SUBOBJECT'
  
       In a constructor, these nodes are used to mark the point at which a
!      subobject of 'this' is fully constructed.  If, after this point, an
!      exception is thrown before a 'CTOR_STMT' with 'CTOR_END_P' set is
!      encountered, the 'SUBOBJECT_CLEANUP' must be executed.  The
       cleanups must be executed in the reverse order in which they
       appear.
  
! 'SWITCH_STMT'
  
!      Used to represent a 'switch' statement.  The 'SWITCH_STMT_COND' is
       the expression on which the switch is occurring.  See the
!      documentation for an 'IF_STMT' for more information on the
!      representation used for the condition.  The 'SWITCH_STMT_BODY' is
!      the body of the switch statement.  The 'SWITCH_STMT_TYPE' is the
       original type of switch expression as given in the source, before
!      any compiler conversions.  The 'SWITCH_STMT_SCOPE' is the statement
       scope (used in the C++ front end only).
  
!      There are also two boolean flags used with 'SWITCH_STMT'.
!      'SWITCH_STMT_ALL_CASES_P' is true if the switch includes a default
       label or the case label ranges cover all possible values of the
!      condition expression.  'SWITCH_STMT_NO_BREAK_P' is true if there
!      are no 'break' statements in the switch.
  
! 'TRY_BLOCK'
!      Used to represent a 'try' block.  The body of the try block is
!      given by 'TRY_STMTS'.  Each of the catch blocks is a 'HANDLER'
!      node.  The first handler is given by 'TRY_HANDLERS'.  Subsequent
!      handlers are obtained by following the 'TREE_CHAIN' link from one
       handler to the next.  The body of the handler is given by
!      'HANDLER_BODY'.
  
!      If 'CLEANUP_P' holds of the 'TRY_BLOCK', then the 'TRY_HANDLERS'
!      will not be a 'HANDLER' node.  Instead, it will be an expression
       that should be executed if an exception is thrown in the try block.
       It must rethrow the exception after executing that code.  And, if
       an exception is thrown while the expression is executing,
!      'terminate' must be called.
  
! 'USING_STMT'
!      Used to represent a 'using' directive.  The namespace is given by
!      'USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL.  This node
       is needed inside template functions, to implement using directives
       during instantiation.
  
! 'WHILE_STMT'
  
!      Used to represent a 'while' loop.  The 'WHILE_COND' is the
       termination condition for the loop.  See the documentation for an
!      'IF_STMT' for more information on the representation used for the
       condition.
  
!      The 'WHILE_BODY' is the body of the loop.
  
  
  File: gccint.info,  Node: C++ Expressions,  Prev: Statements for C and C++,  Up: C and C++ Trees
--- 13175,13242 ----
       where there is a new local variable (or variables) declared within
       the condition.
  
!      The ‘THEN_CLAUSE’ represents the statement given by the ‘then’
!      condition, while the ‘ELSE_CLAUSE’ represents the statement given
!      by the ‘else’ condition.
  
!      C++ distinguishes between this and ‘COND_EXPR’ for handling
       templates.
  
! ‘SUBOBJECT’
  
       In a constructor, these nodes are used to mark the point at which a
!      subobject of ‘this’ is fully constructed.  If, after this point, an
!      exception is thrown before a ‘CTOR_STMT’ with ‘CTOR_END_P’ set is
!      encountered, the ‘SUBOBJECT_CLEANUP’ must be executed.  The
       cleanups must be executed in the reverse order in which they
       appear.
  
! ‘SWITCH_STMT’
  
!      Used to represent a ‘switch’ statement.  The ‘SWITCH_STMT_COND’ is
       the expression on which the switch is occurring.  See the
!      documentation for an ‘IF_STMT’ for more information on the
!      representation used for the condition.  The ‘SWITCH_STMT_BODY’ is
!      the body of the switch statement.  The ‘SWITCH_STMT_TYPE’ is the
       original type of switch expression as given in the source, before
!      any compiler conversions.  The ‘SWITCH_STMT_SCOPE’ is the statement
       scope (used in the C++ front end only).
  
!      There are also two boolean flags used with ‘SWITCH_STMT’.
!      ‘SWITCH_STMT_ALL_CASES_P’ is true if the switch includes a default
       label or the case label ranges cover all possible values of the
!      condition expression.  ‘SWITCH_STMT_NO_BREAK_P’ is true if there
!      are no ‘break’ statements in the switch.
  
! ‘TRY_BLOCK’
!      Used to represent a ‘try’ block.  The body of the try block is
!      given by ‘TRY_STMTS’.  Each of the catch blocks is a ‘HANDLER’
!      node.  The first handler is given by ‘TRY_HANDLERS’.  Subsequent
!      handlers are obtained by following the ‘TREE_CHAIN’ link from one
       handler to the next.  The body of the handler is given by
!      ‘HANDLER_BODY’.
  
!      If ‘CLEANUP_P’ holds of the ‘TRY_BLOCK’, then the ‘TRY_HANDLERS’
!      will not be a ‘HANDLER’ node.  Instead, it will be an expression
       that should be executed if an exception is thrown in the try block.
       It must rethrow the exception after executing that code.  And, if
       an exception is thrown while the expression is executing,
!      ‘terminate’ must be called.
  
! ‘USING_STMT’
!      Used to represent a ‘using’ directive.  The namespace is given by
!      ‘USING_STMT_NAMESPACE’, which will be a NAMESPACE_DECL.  This node
       is needed inside template functions, to implement using directives
       during instantiation.
  
! ‘WHILE_STMT’
  
!      Used to represent a ‘while’ loop.  The ‘WHILE_COND’ is the
       termination condition for the loop.  See the documentation for an
!      ‘IF_STMT’ for more information on the representation used for the
       condition.
  
!      The ‘WHILE_BODY’ is the body of the loop.
  
  
  File: gccint.info,  Node: C++ Expressions,  Prev: Statements for C and C++,  Up: C and C++ Trees
*************** File: gccint.info,  Node: C++ Expression
*** 13246,13286 ****
  
  This section describes expressions specific to the C and C++ front ends.
  
! 'TYPEID_EXPR'
  
!      Used to represent a 'typeid' expression.
  
! 'NEW_EXPR'
! 'VEC_NEW_EXPR'
  
!      Used to represent a call to 'new' and 'new[]' respectively.
  
! 'DELETE_EXPR'
! 'VEC_DELETE_EXPR'
  
!      Used to represent a call to 'delete' and 'delete[]' respectively.
  
! 'MEMBER_REF'
  
       Represents a reference to a member of a class.
  
! 'THROW_EXPR'
  
!      Represents an instance of 'throw' in the program.  Operand 0, which
!      is the expression to throw, may be 'NULL_TREE'.
  
! 'AGGR_INIT_EXPR'
!      An 'AGGR_INIT_EXPR' represents the initialization as the return
       value of a function call, or as the result of a constructor.  An
!      'AGGR_INIT_EXPR' will only appear as a full-expression, or as the
!      second operand of a 'TARGET_EXPR'.  'AGGR_INIT_EXPR's have a
!      representation similar to that of 'CALL_EXPR's.  You can use the
!      'AGGR_INIT_EXPR_FN' and 'AGGR_INIT_EXPR_ARG' macros to access the
       function to call and the arguments to pass.
  
!      If 'AGGR_INIT_VIA_CTOR_P' holds of the 'AGGR_INIT_EXPR', then the
       initialization is via a constructor call.  The address of the
!      'AGGR_INIT_EXPR_SLOT' operand, which is always a 'VAR_DECL', is
       taken, and this value replaces the first argument in the argument
       list.
  
--- 13246,13286 ----
  
  This section describes expressions specific to the C and C++ front ends.
  
! ‘TYPEID_EXPR’
  
!      Used to represent a ‘typeid’ expression.
  
! ‘NEW_EXPR’
! ‘VEC_NEW_EXPR’
  
!      Used to represent a call to ‘new’ and ‘new[]’ respectively.
  
! ‘DELETE_EXPR’
! ‘VEC_DELETE_EXPR’
  
!      Used to represent a call to ‘delete’ and ‘delete[]’ respectively.
  
! ‘MEMBER_REF’
  
       Represents a reference to a member of a class.
  
! ‘THROW_EXPR’
  
!      Represents an instance of ‘throw’ in the program.  Operand 0, which
!      is the expression to throw, may be ‘NULL_TREE’.
  
! ‘AGGR_INIT_EXPR’
!      An ‘AGGR_INIT_EXPR’ represents the initialization as the return
       value of a function call, or as the result of a constructor.  An
!      ‘AGGR_INIT_EXPR’ will only appear as a full-expression, or as the
!      second operand of a ‘TARGET_EXPR’.  ‘AGGR_INIT_EXPR’s have a
!      representation similar to that of ‘CALL_EXPR’s.  You can use the
!      ‘AGGR_INIT_EXPR_FN’ and ‘AGGR_INIT_EXPR_ARG’ macros to access the
       function to call and the arguments to pass.
  
!      If ‘AGGR_INIT_VIA_CTOR_P’ holds of the ‘AGGR_INIT_EXPR’, then the
       initialization is via a constructor call.  The address of the
!      ‘AGGR_INIT_EXPR_SLOT’ operand, which is always a ‘VAR_DECL’, is
       taken, and this value replaces the first argument in the argument
       list.
  
*************** breaking down GENERIC expressions into t
*** 13297,13303 ****
  (with some exceptions like function calls).  GIMPLE was heavily
  influenced by the SIMPLE IL used by the McCAT compiler project at McGill
  University, though we have made some different choices.  For one thing,
! SIMPLE doesn't support 'goto'.
  
   Temporaries are introduced to hold intermediate values needed to
  compute complex expressions.  Additionally, all the control structures
--- 13297,13303 ----
  (with some exceptions like function calls).  GIMPLE was heavily
  influenced by the SIMPLE IL used by the McCAT compiler project at McGill
  University, though we have made some different choices.  For one thing,
! SIMPLE doesn't support ‘goto’.
  
   Temporaries are introduced to hold intermediate values needed to
  compute complex expressions.  Additionally, all the control structures
*************** removed and exception regions are conver
*** 13306,13312 ****
  exception region tree.
  
   The compiler pass which converts GENERIC into GIMPLE is referred to as
! the 'gimplifier'.  The gimplifier works recursively, generating GIMPLE
  tuples out of the original GENERIC expressions.
  
   One of the early implementation strategies used for the GIMPLE
--- 13306,13312 ----
  exception region tree.
  
   The compiler pass which converts GENERIC into GIMPLE is referred to as
! the ‘gimplifier’.  The gimplifier works recursively, generating GIMPLE
  tuples out of the original GENERIC expressions.
  
   One of the early implementation strategies used for the GIMPLE
*************** syntax trees (AST), therefore it does no
*** 13318,13346 ****
  complexity provided by the main tree data structure.
  
   The GENERIC representation of a function is stored in the
! 'DECL_SAVED_TREE' field of the associated 'FUNCTION_DECL' tree node.  It
! is converted to GIMPLE by a call to 'gimplify_function_tree'.
  
   If a front end wants to include language-specific tree codes in the
  tree representation which it provides to the back end, it must provide a
! definition of 'LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the
  front end trees to GIMPLE.  Usually such a hook will involve much of the
  same code for expanding front end trees to RTL.  This function can
  return fully lowered GIMPLE, or it can return GENERIC trees and let the
  main gimplifier lower them the rest of the way; this is often simpler.
  GIMPLE that is not fully lowered is known as "High GIMPLE" and consists
! of the IL before the pass 'pass_lower_cf'.  High GIMPLE contains some
! container statements like lexical scopes (represented by 'GIMPLE_BIND')
! and nested expressions (e.g., 'GIMPLE_TRY'), while "Low GIMPLE" exposes
  all of the implicit jumps for control and exception expressions directly
  in the IL and EH region trees.
  
   The C and C++ front ends currently convert directly from front end
  trees to GIMPLE, and hand that off to the back end rather than first
  converting to GENERIC.  Their gimplifier hooks know about all the
! '_STMT' nodes and how to convert them to GENERIC forms.  There was some
  work done on a genericization pass which would run first, but the
! existence of 'STMT_EXPR' meant that in order to convert all of the C
  statements into GENERIC equivalents would involve walking the entire
  tree anyway, so it was simpler to lower all the way.  This might change
  in the future if someone writes an optimization pass which would work
--- 13318,13346 ----
  complexity provided by the main tree data structure.
  
   The GENERIC representation of a function is stored in the
! ‘DECL_SAVED_TREE’ field of the associated ‘FUNCTION_DECL’ tree node.  It
! is converted to GIMPLE by a call to ‘gimplify_function_tree’.
  
   If a front end wants to include language-specific tree codes in the
  tree representation which it provides to the back end, it must provide a
! definition of ‘LANG_HOOKS_GIMPLIFY_EXPR’ which knows how to convert the
  front end trees to GIMPLE.  Usually such a hook will involve much of the
  same code for expanding front end trees to RTL.  This function can
  return fully lowered GIMPLE, or it can return GENERIC trees and let the
  main gimplifier lower them the rest of the way; this is often simpler.
  GIMPLE that is not fully lowered is known as "High GIMPLE" and consists
! of the IL before the pass ‘pass_lower_cf’.  High GIMPLE contains some
! container statements like lexical scopes (represented by ‘GIMPLE_BIND’)
! and nested expressions (e.g., ‘GIMPLE_TRY’), while "Low GIMPLE" exposes
  all of the implicit jumps for control and exception expressions directly
  in the IL and EH region trees.
  
   The C and C++ front ends currently convert directly from front end
  trees to GIMPLE, and hand that off to the back end rather than first
  converting to GENERIC.  Their gimplifier hooks know about all the
! ‘_STMT’ nodes and how to convert them to GENERIC forms.  There was some
  work done on a genericization pass which would run first, but the
! existence of ‘STMT_EXPR’ meant that in order to convert all of the C
  statements into GENERIC equivalents would involve walking the entire
  tree anyway, so it was simpler to lower all the way.  This might change
  in the future if someone writes an optimization pass which would work
*************** better with higher-level trees, but curr
*** 13348,13354 ****
  GIMPLE.
  
   You can request to dump a C-like representation of the GIMPLE form with
! the flag '-fdump-tree-gimple'.
  
  * Menu:
  
--- 13348,13354 ----
  GIMPLE.
  
   You can request to dump a C-like representation of the GIMPLE form with
! the flag ‘-fdump-tree-gimple’.
  
  * Menu:
  
*************** header describing the instruction and it
*** 13376,13382 ****
  length body with all the operands.  Tuples are organized into a
  hierarchy with 3 main classes of tuples.
  
! 12.1.1 'gimple' (gsbase)
  ------------------------
  
  This is the root of the hierarchy, it holds basic information needed by
--- 13376,13382 ----
  length body with all the operands.  Tuples are organized into a
  hierarchy with 3 main classes of tuples.
  
! 12.1.1 ‘gimple’ (gsbase)
  ------------------------
  
  This is the root of the hierarchy, it holds basic information needed by
*************** structure more compact).  The structure
*** 13387,13537 ****
  bit hosts:
  
  Field                   Size (bits)
! 'code'                  8
! 'subcode'               16
! 'no_warning'            1
! 'visited'               1
! 'nontemporal_move'      1
! 'plf'                   2
! 'modified'              1
! 'has_volatile_ops'      1
! 'references_memory_p'   1
! 'uid'                   32
! 'location'              32
! 'num_ops'               32
! 'bb'                    64
! 'block'                 63
  Total size              32 bytes
  
!    * 'code' Main identifier for a GIMPLE instruction.
  
!    * 'subcode' Used to distinguish different variants of the same basic
       instruction or provide flags applicable to a given code.  The
!      'subcode' flags field has different uses depending on the code of
       the instruction, but mostly it distinguishes instructions of the
       same family.  The most prominent use of this field is in
       assignments, where subcode indicates the operation done on the RHS
       of the assignment.  For example, a = b + c is encoded as
!      'GIMPLE_ASSIGN '.
  
!    * 'no_warning' Bitflag to indicate whether a warning has already been
       issued on this statement.
  
!    * 'visited' General purpose "visited" marker.  Set and cleared by
       each pass when needed.
  
!    * 'nontemporal_move' Bitflag used in assignments that represent
       non-temporal moves.  Although this bitflag is only used in
       assignments, it was moved into the base to take advantage of the
       bit holes left by the previous fields.
  
!    * 'plf' Pass Local Flags.  This 2-bit mask can be used as general
       purpose markers by any pass.  Passes are responsible for clearing
       and setting these two flags accordingly.
  
!    * 'modified' Bitflag to indicate whether the statement has been
       modified.  Used mainly by the operand scanner to determine when to
       re-scan a statement for operands.
  
!    * 'has_volatile_ops' Bitflag to indicate whether this statement
       contains operands that have been marked volatile.
  
!    * 'references_memory_p' Bitflag to indicate whether this statement
       contains memory references (i.e., its operands are either global
       variables, or pointer dereferences or anything that must reside in
       memory).
  
!    * 'uid' This is an unsigned integer used by passes that want to
       assign IDs to every statement.  These IDs must be assigned and used
       by each pass.
  
!    * 'location' This is a 'location_t' identifier to specify source code
       location for this statement.  It is inherited from the front end.
  
!    * 'num_ops' Number of operands that this statement has.  This
       specifies the size of the operand vector embedded in the tuple.
       Only used in some tuples, but it is declared in the base tuple to
       take advantage of the 32-bit hole left by the previous fields.
  
!    * 'bb' Basic block holding the instruction.
  
!    * 'block' Lexical block holding this statement.  Also used for debug
       information generation.
  
! 12.1.2 'gimple_statement_with_ops'
  ----------------------------------
  
! This tuple is actually split in two: 'gimple_statement_with_ops_base'
! and 'gimple_statement_with_ops'.  This is needed to accommodate the way
  the operand vector is allocated.  The operand vector is defined to be an
  array of 1 element.  So, to allocate a dynamic number of operands, the
! memory allocator ('gimple_alloc') simply allocates enough memory to hold
! the structure itself plus 'N - 1' operands which run "off the end" of
  the structure.  For example, to allocate space for a tuple with 3
! operands, 'gimple_alloc' reserves 'sizeof (struct
! gimple_statement_with_ops) + 2 * sizeof (tree)' bytes.
  
   On the other hand, several fields in this tuple need to be shared with
! the 'gimple_statement_with_memory_ops' tuple.  So, these common fields
! are placed in 'gimple_statement_with_ops_base' which is then inherited
  from the other two tuples.
  
! 'gsbase'    256
! 'def_ops'   64
! 'use_ops'   64
! 'op'        'num_ops' * 64
! Total       48 + 8 * 'num_ops' bytes
  size
  
!    * 'gsbase' Inherited from 'struct gimple'.
  
!    * 'def_ops' Array of pointers into the operand array indicating all
       the slots that contain a variable written-to by the statement.
       This array is also used for immediate use chaining.  Note that it
       would be possible to not rely on this array, but the changes
       required to implement this are pretty invasive.
  
!    * 'use_ops' Similar to 'def_ops' but for variables read by the
       statement.
  
!    * 'op' Array of trees with 'num_ops' slots.
  
! 12.1.3 'gimple_statement_with_memory_ops'
  -----------------------------------------
  
! This tuple is essentially identical to 'gimple_statement_with_ops',
  except that it contains 4 additional fields to hold vectors related
  memory stores and loads.  Similar to the previous case, the structure is
  split in two to accommodate for the operand vector
! ('gimple_statement_with_memory_ops_base' and
! 'gimple_statement_with_memory_ops').
  
  Field        Size (bits)
! 'gsbase'     256
! 'def_ops'    64
! 'use_ops'    64
! 'vdef_ops'   64
! 'vuse_ops'   64
! 'stores'     64
! 'loads'      64
! 'op'         'num_ops' * 64
! Total size   80 + 8 * 'num_ops' bytes
  
!    * 'vdef_ops' Similar to 'def_ops' but for 'VDEF' operators.  There is
       one entry per memory symbol written by this statement.  This is
       used to maintain the memory SSA use-def and def-def chains.
  
!    * 'vuse_ops' Similar to 'use_ops' but for 'VUSE' operators.  There is
       one entry per memory symbol loaded by this statement.  This is used
       to maintain the memory SSA use-def chains.
  
!    * 'stores' Bitset with all the UIDs for the symbols written-to by the
!      statement.  This is different than 'vdef_ops' in that all the
       affected symbols are mentioned in this set.  If memory partitioning
!      is enabled, the 'vdef_ops' vector will refer to memory partitions.
       Furthermore, no SSA information is stored in this set.
  
!    * 'loads' Similar to 'stores', but for memory loads.  (Note that
       there is some amount of redundancy here, it should be possible to
       reduce memory utilization further by removing these sets).
  
--- 13387,13537 ----
  bit hosts:
  
  Field                   Size (bits)
! ‘code’                  8
! ‘subcode’               16
! ‘no_warning’            1
! ‘visited’               1
! ‘nontemporal_move’      1
! ‘plf’                   2
! ‘modified’              1
! ‘has_volatile_ops’      1
! ‘references_memory_p’   1
! ‘uid’                   32
! ‘location’              32
! ‘num_ops’               32
! ‘bb’                    64
! ‘block’                 63
  Total size              32 bytes
  
!    • ‘code’ Main identifier for a GIMPLE instruction.
  
!    • ‘subcode’ Used to distinguish different variants of the same basic
       instruction or provide flags applicable to a given code.  The
!      ‘subcode’ flags field has different uses depending on the code of
       the instruction, but mostly it distinguishes instructions of the
       same family.  The most prominent use of this field is in
       assignments, where subcode indicates the operation done on the RHS
       of the assignment.  For example, a = b + c is encoded as
!      ‘GIMPLE_ASSIGN ’.
  
!    • ‘no_warning’ Bitflag to indicate whether a warning has already been
       issued on this statement.
  
!    • ‘visited’ General purpose "visited" marker.  Set and cleared by
       each pass when needed.
  
!    • ‘nontemporal_move’ Bitflag used in assignments that represent
       non-temporal moves.  Although this bitflag is only used in
       assignments, it was moved into the base to take advantage of the
       bit holes left by the previous fields.
  
!    • ‘plf’ Pass Local Flags.  This 2-bit mask can be used as general
       purpose markers by any pass.  Passes are responsible for clearing
       and setting these two flags accordingly.
  
!    • ‘modified’ Bitflag to indicate whether the statement has been
       modified.  Used mainly by the operand scanner to determine when to
       re-scan a statement for operands.
  
!    • ‘has_volatile_ops’ Bitflag to indicate whether this statement
       contains operands that have been marked volatile.
  
!    • ‘references_memory_p’ Bitflag to indicate whether this statement
       contains memory references (i.e., its operands are either global
       variables, or pointer dereferences or anything that must reside in
       memory).
  
!    • ‘uid’ This is an unsigned integer used by passes that want to
       assign IDs to every statement.  These IDs must be assigned and used
       by each pass.
  
!    • ‘location’ This is a ‘location_t’ identifier to specify source code
       location for this statement.  It is inherited from the front end.
  
!    • ‘num_ops’ Number of operands that this statement has.  This
       specifies the size of the operand vector embedded in the tuple.
       Only used in some tuples, but it is declared in the base tuple to
       take advantage of the 32-bit hole left by the previous fields.
  
!    • ‘bb’ Basic block holding the instruction.
  
!    • ‘block’ Lexical block holding this statement.  Also used for debug
       information generation.
  
! 12.1.2 ‘gimple_statement_with_ops’
  ----------------------------------
  
! This tuple is actually split in two: ‘gimple_statement_with_ops_base’
! and ‘gimple_statement_with_ops’.  This is needed to accommodate the way
  the operand vector is allocated.  The operand vector is defined to be an
  array of 1 element.  So, to allocate a dynamic number of operands, the
! memory allocator (‘gimple_alloc’) simply allocates enough memory to hold
! the structure itself plus ‘N - 1’ operands which run "off the end" of
  the structure.  For example, to allocate space for a tuple with 3
! operands, ‘gimple_alloc’ reserves ‘sizeof (struct
! gimple_statement_with_ops) + 2 * sizeof (tree)’ bytes.
  
   On the other hand, several fields in this tuple need to be shared with
! the ‘gimple_statement_with_memory_ops’ tuple.  So, these common fields
! are placed in ‘gimple_statement_with_ops_base’ which is then inherited
  from the other two tuples.
  
! ‘gsbase’    256
! ‘def_ops’   64
! ‘use_ops’   64
! ‘op’        ‘num_ops’ * 64
! Total       48 + 8 * ‘num_ops’ bytes
  size
  
!    • ‘gsbase’ Inherited from ‘struct gimple’.
  
!    • ‘def_ops’ Array of pointers into the operand array indicating all
       the slots that contain a variable written-to by the statement.
       This array is also used for immediate use chaining.  Note that it
       would be possible to not rely on this array, but the changes
       required to implement this are pretty invasive.
  
!    • ‘use_ops’ Similar to ‘def_ops’ but for variables read by the
       statement.
  
!    • ‘op’ Array of trees with ‘num_ops’ slots.
  
! 12.1.3 ‘gimple_statement_with_memory_ops’
  -----------------------------------------
  
! This tuple is essentially identical to ‘gimple_statement_with_ops’,
  except that it contains 4 additional fields to hold vectors related
  memory stores and loads.  Similar to the previous case, the structure is
  split in two to accommodate for the operand vector
! (‘gimple_statement_with_memory_ops_base’ and
! ‘gimple_statement_with_memory_ops’).
  
  Field        Size (bits)
! ‘gsbase’     256
! ‘def_ops’    64
! ‘use_ops’    64
! ‘vdef_ops’   64
! ‘vuse_ops’   64
! ‘stores’     64
! ‘loads’      64
! ‘op’         ‘num_ops’ * 64
! Total size   80 + 8 * ‘num_ops’ bytes
  
!    • ‘vdef_ops’ Similar to ‘def_ops’ but for ‘VDEF’ operators.  There is
       one entry per memory symbol written by this statement.  This is
       used to maintain the memory SSA use-def and def-def chains.
  
!    • ‘vuse_ops’ Similar to ‘use_ops’ but for ‘VUSE’ operators.  There is
       one entry per memory symbol loaded by this statement.  This is used
       to maintain the memory SSA use-def chains.
  
!    • ‘stores’ Bitset with all the UIDs for the symbols written-to by the
!      statement.  This is different than ‘vdef_ops’ in that all the
       affected symbols are mentioned in this set.  If memory partitioning
!      is enabled, the ‘vdef_ops’ vector will refer to memory partitions.
       Furthermore, no SSA information is stored in this set.
  
!    • ‘loads’ Similar to ‘stores’, but for memory loads.  (Note that
       there is some amount of redundancy here, it should be possible to
       reduce memory utilization further by removing these sets).
  
*************** File: gccint.info,  Node: Class hierarch
*** 13545,13552 ****
  =========================================
  
  The following diagram shows the C++ inheritance hierarchy of statement
! kinds, along with their relationships to 'GSS_' values (layouts) and
! 'GIMPLE_' values (codes):
  
          gimple
            |    layout: GSS_BASE
--- 13545,13552 ----
  =========================================
  
  The following diagram shows the C++ inheritance hierarchy of statement
! kinds, along with their relationships to ‘GSS_’ values (layouts) and
! ‘GIMPLE_’ values (codes):
  
          gimple
            |    layout: GSS_BASE
*************** File: gccint.info,  Node: GIMPLE instruc
*** 13690,13724 ****
  The following table briefly describes the GIMPLE instruction set.
  
  Instruction                    High GIMPLE   Low GIMPLE
! 'GIMPLE_ASM'                   x             x
! 'GIMPLE_ASSIGN'                x             x
! 'GIMPLE_BIND'                  x
! 'GIMPLE_CALL'                  x             x
! 'GIMPLE_CATCH'                 x
! 'GIMPLE_COND'                  x             x
! 'GIMPLE_DEBUG'                 x             x
! 'GIMPLE_EH_FILTER'             x
! 'GIMPLE_GOTO'                  x             x
! 'GIMPLE_LABEL'                 x             x
! 'GIMPLE_NOP'                   x             x
! 'GIMPLE_OMP_ATOMIC_LOAD'       x             x
! 'GIMPLE_OMP_ATOMIC_STORE'      x             x
! 'GIMPLE_OMP_CONTINUE'          x             x
! 'GIMPLE_OMP_CRITICAL'          x             x
! 'GIMPLE_OMP_FOR'               x             x
! 'GIMPLE_OMP_MASTER'            x             x
! 'GIMPLE_OMP_ORDERED'           x             x
! 'GIMPLE_OMP_PARALLEL'          x             x
! 'GIMPLE_OMP_RETURN'            x             x
! 'GIMPLE_OMP_SECTION'           x             x
! 'GIMPLE_OMP_SECTIONS'          x             x
! 'GIMPLE_OMP_SECTIONS_SWITCH'   x             x
! 'GIMPLE_OMP_SINGLE'            x             x
! 'GIMPLE_PHI'                                 x
! 'GIMPLE_RESX'                                x
! 'GIMPLE_RETURN'                x             x
! 'GIMPLE_SWITCH'                x             x
! 'GIMPLE_TRY'                   x
  
  
  File: gccint.info,  Node: GIMPLE Exception Handling,  Next: Temporaries,  Prev: GIMPLE instruction set,  Up: GIMPLE
--- 13690,13724 ----
  The following table briefly describes the GIMPLE instruction set.
  
  Instruction                    High GIMPLE   Low GIMPLE
! ‘GIMPLE_ASM’                   x             x
! ‘GIMPLE_ASSIGN’                x             x
! ‘GIMPLE_BIND’                  x
! ‘GIMPLE_CALL’                  x             x
! ‘GIMPLE_CATCH’                 x
! ‘GIMPLE_COND’                  x             x
! ‘GIMPLE_DEBUG’                 x             x
! ‘GIMPLE_EH_FILTER’             x
! ‘GIMPLE_GOTO’                  x             x
! ‘GIMPLE_LABEL’                 x             x
! ‘GIMPLE_NOP’                   x             x
! ‘GIMPLE_OMP_ATOMIC_LOAD’       x             x
! ‘GIMPLE_OMP_ATOMIC_STORE’      x             x
! ‘GIMPLE_OMP_CONTINUE’          x             x
! ‘GIMPLE_OMP_CRITICAL’          x             x
! ‘GIMPLE_OMP_FOR’               x             x
! ‘GIMPLE_OMP_MASTER’            x             x
! ‘GIMPLE_OMP_ORDERED’           x             x
! ‘GIMPLE_OMP_PARALLEL’          x             x
! ‘GIMPLE_OMP_RETURN’            x             x
! ‘GIMPLE_OMP_SECTION’           x             x
! ‘GIMPLE_OMP_SECTIONS’          x             x
! ‘GIMPLE_OMP_SECTIONS_SWITCH’   x             x
! ‘GIMPLE_OMP_SINGLE’            x             x
! ‘GIMPLE_PHI’                                 x
! ‘GIMPLE_RESX’                                x
! ‘GIMPLE_RETURN’                x             x
! ‘GIMPLE_SWITCH’                x             x
! ‘GIMPLE_TRY’                   x
  
  
  File: gccint.info,  Node: GIMPLE Exception Handling,  Next: Temporaries,  Prev: GIMPLE instruction set,  Up: GIMPLE
*************** File: gccint.info,  Node: GIMPLE Excepti
*** 13727,13749 ****
  =======================
  
  Other exception handling constructs are represented using
! 'GIMPLE_TRY_CATCH'.  'GIMPLE_TRY_CATCH' has two operands.  The first
  operand is a sequence of statements to execute.  If executing these
  statements does not throw an exception, then the second operand is
  ignored.  Otherwise, if an exception is thrown, then the second operand
! of the 'GIMPLE_TRY_CATCH' is checked.  The second operand may have the
  following forms:
  
    1. A sequence of statements to execute.  When an exception occurs,
       these statements are executed, and then the exception is rethrown.
  
!   2. A sequence of 'GIMPLE_CATCH' statements.  Each 'GIMPLE_CATCH' has a
       list of applicable exception types and handler code.  If the thrown
       exception matches one of the caught types, the associated handler
       code is executed.  If the handler code falls off the bottom,
!      execution continues after the original 'GIMPLE_TRY_CATCH'.
  
!   3. A 'GIMPLE_EH_FILTER' statement.  This has a list of permitted
       exception types, and code to handle a match failure.  If the thrown
       exception does not match one of the allowed types, the associated
       match failure code is executed.  If the thrown exception does
--- 13727,13749 ----
  =======================
  
  Other exception handling constructs are represented using
! ‘GIMPLE_TRY_CATCH’.  ‘GIMPLE_TRY_CATCH’ has two operands.  The first
  operand is a sequence of statements to execute.  If executing these
  statements does not throw an exception, then the second operand is
  ignored.  Otherwise, if an exception is thrown, then the second operand
! of the ‘GIMPLE_TRY_CATCH’ is checked.  The second operand may have the
  following forms:
  
    1. A sequence of statements to execute.  When an exception occurs,
       these statements are executed, and then the exception is rethrown.
  
!   2. A sequence of ‘GIMPLE_CATCH’ statements.  Each ‘GIMPLE_CATCH’ has a
       list of applicable exception types and handler code.  If the thrown
       exception matches one of the caught types, the associated handler
       code is executed.  If the handler code falls off the bottom,
!      execution continues after the original ‘GIMPLE_TRY_CATCH’.
  
!   3. A ‘GIMPLE_EH_FILTER’ statement.  This has a list of permitted
       exception types, and code to handle a match failure.  If the thrown
       exception does not match one of the allowed types, the associated
       match failure code is executed.  If the thrown exception does
*************** future we will want to add some way to e
*** 13756,13764 ****
  an exception of a known type.
  
   Just before running the optimizers, the compiler lowers the high-level
! EH constructs above into a set of 'goto's, magic labels, and EH regions.
  Continuing to unwind at the end of a cleanup is represented with a
! 'GIMPLE_RESX'.
  
  
  File: gccint.info,  Node: Temporaries,  Next: Operands,  Prev: GIMPLE Exception Handling,  Up: GIMPLE
--- 13756,13764 ----
  an exception of a known type.
  
   Just before running the optimizers, the compiler lowers the high-level
! EH constructs above into a set of ‘goto’s, magic labels, and EH regions.
  Continuing to unwind at the end of a cleanup is represented with a
! ‘GIMPLE_RESX’.
  
  
  File: gccint.info,  Node: Temporaries,  Next: Operands,  Prev: GIMPLE Exception Handling,  Up: GIMPLE
*************** File: gccint.info,  Node: Temporaries,
*** 13769,13785 ****
  When gimplification encounters a subexpression that is too complex, it
  creates a new temporary variable to hold the value of the subexpression,
  and adds a new statement to initialize it before the current statement.
! These special temporaries are known as 'expression temporaries', and are
! allocated using 'get_formal_tmp_var'.  The compiler tries to always
  evaluate identical expressions into the same temporary, to simplify
  elimination of redundant calculations.
  
   We can only use expression temporaries when we know that it will not be
  reevaluated before its value is used, and that it will not be otherwise
  modified(1).  Other temporaries can be allocated using
! 'get_initialized_tmp_var' or 'create_tmp_var'.
  
!  Currently, an expression like 'a = b + 5' is not reduced any further.
  We tried converting it to something like
       T1 = b + 5;
       a = T1;
--- 13769,13785 ----
  When gimplification encounters a subexpression that is too complex, it
  creates a new temporary variable to hold the value of the subexpression,
  and adds a new statement to initialize it before the current statement.
! These special temporaries are known as ‘expression temporaries’, and are
! allocated using ‘get_formal_tmp_var’.  The compiler tries to always
  evaluate identical expressions into the same temporary, to simplify
  elimination of redundant calculations.
  
   We can only use expression temporaries when we know that it will not be
  reevaluated before its value is used, and that it will not be otherwise
  modified(1).  Other temporaries can be allocated using
! ‘get_initialized_tmp_var’ or ‘create_tmp_var’.
  
!  Currently, an expression like ‘a = b + 5’ is not reduced any further.
  We tried converting it to something like
       T1 = b + 5;
       a = T1;
*************** File: gccint.info,  Node: Operands,  Nex
*** 13801,13817 ****
  
  In general, expressions in GIMPLE consist of an operation and the
  appropriate number of simple operands; these operands must either be a
! GIMPLE rvalue ('is_gimple_val'), i.e. a constant or a register variable.
  More complex operands are factored out into temporaries, so that
       a = b + c + d
   becomes
       T1 = b + c;
       a = T1 + d;
  
!  The same rule holds for arguments to a 'GIMPLE_CALL'.
  
   The target of an assignment is usually a variable, but can also be a
! 'MEM_REF' or a compound lvalue as described below.
  
  * Menu:
  
--- 13801,13817 ----
  
  In general, expressions in GIMPLE consist of an operation and the
  appropriate number of simple operands; these operands must either be a
! GIMPLE rvalue (‘is_gimple_val’), i.e. a constant or a register variable.
  More complex operands are factored out into temporaries, so that
       a = b + c + d
   becomes
       T1 = b + c;
       a = T1 + d;
  
!  The same rule holds for arguments to a ‘GIMPLE_CALL’.
  
   The target of an assignment is usually a variable, but can also be a
! ‘MEM_REF’ or a compound lvalue as described below.
  
  * Menu:
  
*************** File: gccint.info,  Node: Compound Lvalu
*** 13836,13842 ****
  -----------------------
  
  Currently compound lvalues involving array and structure field
! references are not broken down; an expression like 'a.b[2] = 42' is not
  reduced any further (though complex array subscripts are).  This
  restriction is a workaround for limitations in later optimizers; if we
  were to convert this to
--- 13836,13842 ----
  -----------------------
  
  Currently compound lvalues involving array and structure field
! references are not broken down; an expression like ‘a.b[2] = 42’ is not
  reduced any further (though complex array subscripts are).  This
  restriction is a workaround for limitations in later optimizers; if we
  were to convert this to
*************** were to convert this to
*** 13844,13852 ****
       T1 = &a.b;
       T1[2] = 42;
  
!  alias analysis would not remember that the reference to 'T1[2]' came by
! way of 'a.b', so it would think that the assignment could alias another
! member of 'a'; this broke 'struct-alias-1.c'.  Future optimizer
  improvements may make this limitation unnecessary.
  
  
--- 13844,13852 ----
       T1 = &a.b;
       T1[2] = 42;
  
!  alias analysis would not remember that the reference to ‘T1[2]’ came by
! way of ‘a.b’, so it would think that the assignment could alias another
! member of ‘a’; this broke ‘struct-alias-1.c’.  Future optimizer
  improvements may make this limitation unnecessary.
  
  
*************** File: gccint.info,  Node: Conditional Ex
*** 13855,13861 ****
  12.6.3 Conditional Expressions
  ------------------------------
  
! A C '?:' expression is converted into an 'if' statement with each branch
  assigning to the same temporary.  So,
  
       a = b ? c : d;
--- 13855,13861 ----
  12.6.3 Conditional Expressions
  ------------------------------
  
! A C ‘?:’ expression is converted into an ‘if’ statement with each branch
  assigning to the same temporary.  So,
  
       a = b ? c : d;
*************** assigning to the same temporary.  So,
*** 13866,13877 ****
         T1 = d;
       a = T1;
  
!  The GIMPLE level if-conversion pass re-introduces '?:' expression, if
  appropriate.  It is used to vectorize loops with conditions using vector
  conditional operations.
  
!  Note that in GIMPLE, 'if' statements are represented using
! 'GIMPLE_COND', as described below.
  
  
  File: gccint.info,  Node: Logical Operators,  Prev: Conditional Expressions,  Up: Operands
--- 13866,13877 ----
         T1 = d;
       a = T1;
  
!  The GIMPLE level if-conversion pass re-introduces ‘?:’ expression, if
  appropriate.  It is used to vectorize loops with conditions using vector
  conditional operations.
  
!  Note that in GIMPLE, ‘if’ statements are represented using
! ‘GIMPLE_COND’, as described below.
  
  
  File: gccint.info,  Node: Logical Operators,  Prev: Conditional Expressions,  Up: Operands
*************** File: gccint.info,  Node: Logical Operat
*** 13879,13886 ****
  12.6.4 Logical Operators
  ------------------------
  
! Except when they appear in the condition operand of a 'GIMPLE_COND',
! logical 'and' and 'or' operators are simplified as follows: 'a = b && c'
  becomes
  
       T1 = (bool)b;
--- 13879,13886 ----
  12.6.4 Logical Operators
  ------------------------
  
! Except when they appear in the condition operand of a ‘GIMPLE_COND’,
! logical 'and' and 'or' operators are simplified as follows: ‘a = b && c’
  becomes
  
       T1 = (bool)b;
*************** becomes
*** 13888,13928 ****
         T1 = (bool)c;
       a = T1;
  
!  Note that 'T1' in this example cannot be an expression temporary,
  because it has two different assignments.
  
  12.6.5 Manipulating operands
  ----------------------------
  
! All gimple operands are of type 'tree'.  But only certain types of trees
  are allowed to be used as operand tuples.  Basic validation is
! controlled by the function 'get_gimple_rhs_class', which given a tree
! code, returns an 'enum' with the following values of type 'enum
! gimple_rhs_class'
  
!    * 'GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand.
  
!    * 'GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation.
  
!    * 'GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation.
  
!    * 'GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation.
  
!    * 'GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be
!      split into simpler operands (for instance, 'SSA_NAME', 'VAR_DECL',
!      'COMPONENT_REF', etc).
  
       This operand class also acts as an escape hatch for tree nodes that
       may be flattened out into the operand vector, but would need more
!      than two slots on the RHS. For instance, a 'COND_EXPR' expression
!      of the form '(a op b) ? x : y' could be flattened out on the
       operand vector using 4 slots, but it would also require additional
!      processing to distinguish 'c = a op b' from 'c = a op b ? x : y'.
       In time, these special case tree expressions should be flattened
       into the operand vector.
  
!  For tree nodes in the categories 'GIMPLE_TERNARY_RHS',
! 'GIMPLE_BINARY_RHS' and 'GIMPLE_UNARY_RHS', they cannot be stored inside
  tuples directly.  They first need to be flattened and separated into
  individual components.  For instance, given the GENERIC expression
  
--- 13888,13928 ----
         T1 = (bool)c;
       a = T1;
  
!  Note that ‘T1’ in this example cannot be an expression temporary,
  because it has two different assignments.
  
  12.6.5 Manipulating operands
  ----------------------------
  
! All gimple operands are of type ‘tree’.  But only certain types of trees
  are allowed to be used as operand tuples.  Basic validation is
! controlled by the function ‘get_gimple_rhs_class’, which given a tree
! code, returns an ‘enum’ with the following values of type ‘enum
! gimple_rhs_class’
  
!    • ‘GIMPLE_INVALID_RHS’ The tree cannot be used as a GIMPLE operand.
  
!    • ‘GIMPLE_TERNARY_RHS’ The tree is a valid GIMPLE ternary operation.
  
!    • ‘GIMPLE_BINARY_RHS’ The tree is a valid GIMPLE binary operation.
  
!    • ‘GIMPLE_UNARY_RHS’ The tree is a valid GIMPLE unary operation.
  
!    • ‘GIMPLE_SINGLE_RHS’ The tree is a single object, that cannot be
!      split into simpler operands (for instance, ‘SSA_NAME’, ‘VAR_DECL’,
!      ‘COMPONENT_REF’, etc).
  
       This operand class also acts as an escape hatch for tree nodes that
       may be flattened out into the operand vector, but would need more
!      than two slots on the RHS. For instance, a ‘COND_EXPR’ expression
!      of the form ‘(a op b) ? x : y’ could be flattened out on the
       operand vector using 4 slots, but it would also require additional
!      processing to distinguish ‘c = a op b’ from ‘c = a op b ? x : y’.
       In time, these special case tree expressions should be flattened
       into the operand vector.
  
!  For tree nodes in the categories ‘GIMPLE_TERNARY_RHS’,
! ‘GIMPLE_BINARY_RHS’ and ‘GIMPLE_UNARY_RHS’, they cannot be stored inside
  tuples directly.  They first need to be flattened and separated into
  individual components.  For instance, given the GENERIC expression
  
*************** individual components.  For instance, gi
*** 13933,13941 ****
       MODIFY_EXPR , PLUS_EXPR , VAR_DECL >>
  
   In this case, the GIMPLE form for this statement is logically identical
! to its GENERIC form but in GIMPLE, the 'PLUS_EXPR' on the RHS of the
  assignment is not represented as a tree, instead the two operands are
! taken out of the 'PLUS_EXPR' sub-tree and flattened into the GIMPLE
  tuple as follows:
  
       GIMPLE_ASSIGN , VAR_DECL , VAR_DECL >
--- 13933,13941 ----
       MODIFY_EXPR , PLUS_EXPR , VAR_DECL >>
  
   In this case, the GIMPLE form for this statement is logically identical
! to its GENERIC form but in GIMPLE, the ‘PLUS_EXPR’ on the RHS of the
  assignment is not represented as a tree, instead the two operands are
! taken out of the ‘PLUS_EXPR’ sub-tree and flattened into the GIMPLE
  tuple as follows:
  
       GIMPLE_ASSIGN , VAR_DECL , VAR_DECL >
*************** of the structure.  To access tuple opera
*** 13952,13973 ****
       Returns the number of operands in statement G.
  
   -- GIMPLE function: tree gimple_op (gimple g, unsigned i)
!      Returns operand 'I' from statement 'G'.
  
   -- GIMPLE function: tree * gimple_ops (gimple g)
!      Returns a pointer into the operand vector for statement 'G'.  This
!      is computed using an internal table called 'gimple_ops_offset_'[].
!      This table is indexed by the gimple code of 'G'.
  
       When the compiler is built, this table is filled-in using the sizes
       of the structures used by each statement code defined in
       gimple.def.  Since the operand vector is at the bottom of the
!      structure, for a gimple code 'C' the offset is computed as sizeof
!      (struct-of 'C') - sizeof (tree).
  
       This mechanism adds one memory indirection to every access when
!      using 'gimple_op'(), if this becomes a bottleneck, a pass can
!      choose to memoize the result from 'gimple_ops'() and use that to
       access the operands.
  
  12.6.7 Operand validation
--- 13952,13973 ----
       Returns the number of operands in statement G.
  
   -- GIMPLE function: tree gimple_op (gimple g, unsigned i)
!      Returns operand ‘I’ from statement ‘G’.
  
   -- GIMPLE function: tree * gimple_ops (gimple g)
!      Returns a pointer into the operand vector for statement ‘G’.  This
!      is computed using an internal table called ‘gimple_ops_offset_’[].
!      This table is indexed by the gimple code of ‘G’.
  
       When the compiler is built, this table is filled-in using the sizes
       of the structures used by each statement code defined in
       gimple.def.  Since the operand vector is at the bottom of the
!      structure, for a gimple code ‘C’ the offset is computed as sizeof
!      (struct-of ‘C’) - sizeof (tree).
  
       This mechanism adds one memory indirection to every access when
!      using ‘gimple_op’(), if this becomes a bottleneck, a pass can
!      choose to memoize the result from ‘gimple_ops’() and use that to
       access the operands.
  
  12.6.7 Operand validation
*************** of the structure.  To access tuple opera
*** 13975,14004 ****
  
  When adding a new operand to a gimple statement, the operand will be
  validated according to what each tuple accepts in its operand vector.
! These predicates are called by the 'gimple_NAME_set_...()'.  Each tuple
  will use one of the following predicates (Note, this list is not
  exhaustive):
  
   -- GIMPLE function: bool is_gimple_val (tree t)
       Returns true if t is a "GIMPLE value", which are all the
       non-addressable stack variables (variables for which
!      'is_gimple_reg' returns true) and constants (expressions for which
!      'is_gimple_min_invariant' returns true).
  
   -- GIMPLE function: bool is_gimple_addressable (tree t)
       Returns true if t is a symbol or memory reference whose address can
       be taken.
  
   -- GIMPLE function: bool is_gimple_asm_val (tree t)
!      Similar to 'is_gimple_val' but it also accepts hard registers.
  
   -- GIMPLE function: bool is_gimple_call_addr (tree t)
       Return true if t is a valid expression to use as the function
!      called by a 'GIMPLE_CALL'.
  
   -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t)
       Return true if t is a valid expression to use as first operand of a
!      'MEM_REF' expression.
  
   -- GIMPLE function: bool is_gimple_constant (tree t)
       Return true if t is a valid gimple constant.
--- 13975,14004 ----
  
  When adding a new operand to a gimple statement, the operand will be
  validated according to what each tuple accepts in its operand vector.
! These predicates are called by the ‘gimple_NAME_set_...()’.  Each tuple
  will use one of the following predicates (Note, this list is not
  exhaustive):
  
   -- GIMPLE function: bool is_gimple_val (tree t)
       Returns true if t is a "GIMPLE value", which are all the
       non-addressable stack variables (variables for which
!      ‘is_gimple_reg’ returns true) and constants (expressions for which
!      ‘is_gimple_min_invariant’ returns true).
  
   -- GIMPLE function: bool is_gimple_addressable (tree t)
       Returns true if t is a symbol or memory reference whose address can
       be taken.
  
   -- GIMPLE function: bool is_gimple_asm_val (tree t)
!      Similar to ‘is_gimple_val’ but it also accepts hard registers.
  
   -- GIMPLE function: bool is_gimple_call_addr (tree t)
       Return true if t is a valid expression to use as the function
!      called by a ‘GIMPLE_CALL’.
  
   -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t)
       Return true if t is a valid expression to use as first operand of a
!      ‘MEM_REF’ expression.
  
   -- GIMPLE function: bool is_gimple_constant (tree t)
       Return true if t is a valid gimple constant.
*************** exhaustive):
*** 14015,14056 ****
       of a global variable but not of a local one).
  
   -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t)
!      Return true if t is an 'ADDR_EXPR' that does not change once the
       program is running (and which is valid in all functions).
  
  12.6.8 Statement validation
  ---------------------------
  
   -- GIMPLE function: bool is_gimple_assign (gimple g)
!      Return true if the code of g is 'GIMPLE_ASSIGN'.
  
   -- GIMPLE function: bool is_gimple_call (gimple g)
!      Return true if the code of g is 'GIMPLE_CALL'.
  
   -- GIMPLE function: bool is_gimple_debug (gimple g)
!      Return true if the code of g is 'GIMPLE_DEBUG'.
  
   -- GIMPLE function: bool gimple_assign_cast_p (const_gimple g)
!      Return true if g is a 'GIMPLE_ASSIGN' that performs a type cast
       operation.
  
   -- GIMPLE function: bool gimple_debug_bind_p (gimple g)
!      Return true if g is a 'GIMPLE_DEBUG' that binds the value of an
       expression to a variable.
  
   -- GIMPLE function: bool is_gimple_omp (gimple g)
       Return true if g is any of the OpenMP codes.
  
   -- GIMPLE function: bool gimple_debug_begin_stmt_p (gimple g)
!      Return true if g is a 'GIMPLE_DEBUG' that marks the beginning of a
       source statement.
  
   -- GIMPLE function: bool gimple_debug_inline_entry_p (gimple g)
!      Return true if g is a 'GIMPLE_DEBUG' that marks the entry point of
       an inlined function.
  
   -- GIMPLE function: bool gimple_debug_nonbind_marker_p (gimple g)
!      Return true if g is a 'GIMPLE_DEBUG' that marks a program location,
       without any variable binding.
  
  
--- 14015,14056 ----
       of a global variable but not of a local one).
  
   -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t)
!      Return true if t is an ‘ADDR_EXPR’ that does not change once the
       program is running (and which is valid in all functions).
  
  12.6.8 Statement validation
  ---------------------------
  
   -- GIMPLE function: bool is_gimple_assign (gimple g)
!      Return true if the code of g is ‘GIMPLE_ASSIGN’.
  
   -- GIMPLE function: bool is_gimple_call (gimple g)
!      Return true if the code of g is ‘GIMPLE_CALL’.
  
   -- GIMPLE function: bool is_gimple_debug (gimple g)
!      Return true if the code of g is ‘GIMPLE_DEBUG’.
  
   -- GIMPLE function: bool gimple_assign_cast_p (const_gimple g)
!      Return true if g is a ‘GIMPLE_ASSIGN’ that performs a type cast
       operation.
  
   -- GIMPLE function: bool gimple_debug_bind_p (gimple g)
!      Return true if g is a ‘GIMPLE_DEBUG’ that binds the value of an
       expression to a variable.
  
   -- GIMPLE function: bool is_gimple_omp (gimple g)
       Return true if g is any of the OpenMP codes.
  
   -- GIMPLE function: bool gimple_debug_begin_stmt_p (gimple g)
!      Return true if g is a ‘GIMPLE_DEBUG’ that marks the beginning of a
       source statement.
  
   -- GIMPLE function: bool gimple_debug_inline_entry_p (gimple g)
!      Return true if g is a ‘GIMPLE_DEBUG’ that marks the entry point of
       an inlined function.
  
   -- GIMPLE function: bool gimple_debug_nonbind_marker_p (gimple g)
!      Return true if g is a ‘GIMPLE_DEBUG’ that marks a program location,
       without any variable binding.
  
  
*************** GIMPLE instructions.
*** 14068,14199 ****
  The following are common accessors for gimple statements.
  
   -- GIMPLE function: enum gimple_code gimple_code (gimple g)
!      Return the code for statement 'G'.
  
   -- GIMPLE function: basic_block gimple_bb (gimple g)
!      Return the basic block to which statement 'G' belongs to.
  
   -- GIMPLE function: tree gimple_block (gimple g)
!      Return the lexical scope block holding statement 'G'.
  
   -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt)
!      Return the tree code for the expression computed by 'STMT'.  This
!      is only meaningful for 'GIMPLE_CALL', 'GIMPLE_ASSIGN' and
!      'GIMPLE_COND'.  If 'STMT' is 'GIMPLE_CALL', it will return
!      'CALL_EXPR'.  For 'GIMPLE_COND', it returns the code of the
!      comparison predicate.  For 'GIMPLE_ASSIGN' it returns the code of
!      the operation performed by the 'RHS' of the assignment.
  
   -- GIMPLE function: void gimple_set_block (gimple g, tree block)
!      Set the lexical scope block of 'G' to 'BLOCK'.
  
   -- GIMPLE function: location_t gimple_locus (gimple g)
!      Return locus information for statement 'G'.
  
   -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus)
!      Set locus information for statement 'G'.
  
   -- GIMPLE function: bool gimple_locus_empty_p (gimple g)
!      Return true if 'G' does not have locus information.
  
   -- GIMPLE function: bool gimple_no_warning_p (gimple stmt)
!      Return true if no warnings should be emitted for statement 'STMT'.
  
   -- GIMPLE function: void gimple_set_visited (gimple stmt, bool
            visited_p)
!      Set the visited status on statement 'STMT' to 'VISITED_P'.
  
   -- GIMPLE function: bool gimple_visited_p (gimple stmt)
!      Return the visited status on statement 'STMT'.
  
   -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask
            plf, bool val_p)
!      Set pass local flag 'PLF' on statement 'STMT' to 'VAL_P'.
  
   -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum plf_mask
            plf)
!      Return the value of pass local flag 'PLF' on statement 'STMT'.
  
   -- GIMPLE function: bool gimple_has_ops (gimple g)
!      Return true if statement 'G' has register or memory operands.
  
   -- GIMPLE function: bool gimple_has_mem_ops (gimple g)
!      Return true if statement 'G' has memory operands.
  
   -- GIMPLE function: unsigned gimple_num_ops (gimple g)
!      Return the number of operands for statement 'G'.
  
   -- GIMPLE function: tree * gimple_ops (gimple g)
!      Return the array of operands for statement 'G'.
  
   -- GIMPLE function: tree gimple_op (gimple g, unsigned i)
!      Return operand 'I' for statement 'G'.
  
   -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i)
!      Return a pointer to operand 'I' for statement 'G'.
  
   -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op)
!      Set operand 'I' of statement 'G' to 'OP'.
  
   -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt)
       Return the set of symbols that have had their address taken by
!      'STMT'.
  
   -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g)
!      Return the set of 'DEF' operands for statement 'G'.
  
   -- GIMPLE function: void gimple_set_def_ops (gimple g, struct
            def_optype_d *def)
!      Set 'DEF' to be the set of 'DEF' operands for statement 'G'.
  
   -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g)
!      Return the set of 'USE' operands for statement 'G'.
  
   -- GIMPLE function: void gimple_set_use_ops (gimple g, struct
            use_optype_d *use)
!      Set 'USE' to be the set of 'USE' operands for statement 'G'.
  
   -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g)
!      Return the set of 'VUSE' operands for statement 'G'.
  
   -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct
            voptype_d *ops)
!      Set 'OPS' to be the set of 'VUSE' operands for statement 'G'.
  
   -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g)
!      Return the set of 'VDEF' operands for statement 'G'.
  
   -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct
            voptype_d *ops)
!      Set 'OPS' to be the set of 'VDEF' operands for statement 'G'.
  
   -- GIMPLE function: bitmap gimple_loaded_syms (gimple g)
!      Return the set of symbols loaded by statement 'G'.  Each element of
!      the set is the 'DECL_UID' of the corresponding symbol.
  
   -- GIMPLE function: bitmap gimple_stored_syms (gimple g)
!      Return the set of symbols stored by statement 'G'.  Each element of
!      the set is the 'DECL_UID' of the corresponding symbol.
  
   -- GIMPLE function: bool gimple_modified_p (gimple g)
!      Return true if statement 'G' has operands and the modified field
       has been set.
  
   -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt)
!      Return true if statement 'STMT' contains volatile operands.
  
   -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, bool
            volatilep)
!      Return true if statement 'STMT' contains volatile operands.
  
   -- GIMPLE function: void update_stmt (gimple s)
!      Mark statement 'S' as modified, and update it.
  
   -- GIMPLE function: void update_stmt_if_modified (gimple s)
!      Update statement 'S' if it has been marked modified.
  
   -- GIMPLE function: gimple gimple_copy (gimple stmt)
!      Return a deep copy of statement 'STMT'.
  
  
  File: gccint.info,  Node: Tuple specific accessors,  Next: GIMPLE sequences,  Prev: Manipulating GIMPLE statements,  Up: GIMPLE
--- 14068,14199 ----
  The following are common accessors for gimple statements.
  
   -- GIMPLE function: enum gimple_code gimple_code (gimple g)
!      Return the code for statement ‘G’.
  
   -- GIMPLE function: basic_block gimple_bb (gimple g)
!      Return the basic block to which statement ‘G’ belongs to.
  
   -- GIMPLE function: tree gimple_block (gimple g)
!      Return the lexical scope block holding statement ‘G’.
  
   -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt)
!      Return the tree code for the expression computed by ‘STMT’.  This
!      is only meaningful for ‘GIMPLE_CALL’, ‘GIMPLE_ASSIGN’ and
!      ‘GIMPLE_COND’.  If ‘STMT’ is ‘GIMPLE_CALL’, it will return
!      ‘CALL_EXPR’.  For ‘GIMPLE_COND’, it returns the code of the
!      comparison predicate.  For ‘GIMPLE_ASSIGN’ it returns the code of
!      the operation performed by the ‘RHS’ of the assignment.
  
   -- GIMPLE function: void gimple_set_block (gimple g, tree block)
!      Set the lexical scope block of ‘G’ to ‘BLOCK’.
  
   -- GIMPLE function: location_t gimple_locus (gimple g)
!      Return locus information for statement ‘G’.
  
   -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus)
!      Set locus information for statement ‘G’.
  
   -- GIMPLE function: bool gimple_locus_empty_p (gimple g)
!      Return true if ‘G’ does not have locus information.
  
   -- GIMPLE function: bool gimple_no_warning_p (gimple stmt)
!      Return true if no warnings should be emitted for statement ‘STMT’.
  
   -- GIMPLE function: void gimple_set_visited (gimple stmt, bool
            visited_p)
!      Set the visited status on statement ‘STMT’ to ‘VISITED_P’.
  
   -- GIMPLE function: bool gimple_visited_p (gimple stmt)
!      Return the visited status on statement ‘STMT’.
  
   -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask
            plf, bool val_p)
!      Set pass local flag ‘PLF’ on statement ‘STMT’ to ‘VAL_P’.
  
   -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum plf_mask
            plf)
!      Return the value of pass local flag ‘PLF’ on statement ‘STMT’.
  
   -- GIMPLE function: bool gimple_has_ops (gimple g)
!      Return true if statement ‘G’ has register or memory operands.
  
   -- GIMPLE function: bool gimple_has_mem_ops (gimple g)
!      Return true if statement ‘G’ has memory operands.
  
   -- GIMPLE function: unsigned gimple_num_ops (gimple g)
!      Return the number of operands for statement ‘G’.
  
   -- GIMPLE function: tree * gimple_ops (gimple g)
!      Return the array of operands for statement ‘G’.
  
   -- GIMPLE function: tree gimple_op (gimple g, unsigned i)
!      Return operand ‘I’ for statement ‘G’.
  
   -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i)
!      Return a pointer to operand ‘I’ for statement ‘G’.
  
   -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op)
!      Set operand ‘I’ of statement ‘G’ to ‘OP’.
  
   -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt)
       Return the set of symbols that have had their address taken by
!      ‘STMT’.
  
   -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g)
!      Return the set of ‘DEF’ operands for statement ‘G’.
  
   -- GIMPLE function: void gimple_set_def_ops (gimple g, struct
            def_optype_d *def)
!      Set ‘DEF’ to be the set of ‘DEF’ operands for statement ‘G’.
  
   -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g)
!      Return the set of ‘USE’ operands for statement ‘G’.
  
   -- GIMPLE function: void gimple_set_use_ops (gimple g, struct
            use_optype_d *use)
!      Set ‘USE’ to be the set of ‘USE’ operands for statement ‘G’.
  
   -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g)
!      Return the set of ‘VUSE’ operands for statement ‘G’.
  
   -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct
            voptype_d *ops)
!      Set ‘OPS’ to be the set of ‘VUSE’ operands for statement ‘G’.
  
   -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g)
!      Return the set of ‘VDEF’ operands for statement ‘G’.
  
   -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct
            voptype_d *ops)
!      Set ‘OPS’ to be the set of ‘VDEF’ operands for statement ‘G’.
  
   -- GIMPLE function: bitmap gimple_loaded_syms (gimple g)
!      Return the set of symbols loaded by statement ‘G’.  Each element of
!      the set is the ‘DECL_UID’ of the corresponding symbol.
  
   -- GIMPLE function: bitmap gimple_stored_syms (gimple g)
!      Return the set of symbols stored by statement ‘G’.  Each element of
!      the set is the ‘DECL_UID’ of the corresponding symbol.
  
   -- GIMPLE function: bool gimple_modified_p (gimple g)
!      Return true if statement ‘G’ has operands and the modified field
       has been set.
  
   -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt)
!      Return true if statement ‘STMT’ contains volatile operands.
  
   -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, bool
            volatilep)
!      Return true if statement ‘STMT’ contains volatile operands.
  
   -- GIMPLE function: void update_stmt (gimple s)
!      Mark statement ‘S’ as modified, and update it.
  
   -- GIMPLE function: void update_stmt_if_modified (gimple s)
!      Update statement ‘S’ if it has been marked modified.
  
   -- GIMPLE function: gimple gimple_copy (gimple stmt)
!      Return a deep copy of statement ‘STMT’.
  
  
  File: gccint.info,  Node: Tuple specific accessors,  Next: GIMPLE sequences,  Prev: Manipulating GIMPLE statements,  Up: GIMPLE
*************** File: gccint.info,  Node: Tuple specific
*** 14236,14305 ****
  
  File: gccint.info,  Node: GIMPLE_ASM,  Next: GIMPLE_ASSIGN,  Up: Tuple specific accessors
  
! 12.8.1 'GIMPLE_ASM'
  -------------------
  
   -- GIMPLE function: gasm *gimple_build_asm_vec ( const char *string,
            vec *inputs, vec *outputs, vec *clobbers, vec *labels)
!      Build a 'GIMPLE_ASM' statement.  This statement is used for
!      building in-line assembly constructs.  'STRING' is the assembly
!      code.  'INPUTS', 'OUTPUTS', 'CLOBBERS' and 'LABELS' are the inputs,
       outputs, clobbered registers and labels.
  
   -- GIMPLE function: unsigned gimple_asm_ninputs (const gasm *g)
!      Return the number of input operands for 'GIMPLE_ASM' 'G'.
  
   -- GIMPLE function: unsigned gimple_asm_noutputs (const gasm *g)
!      Return the number of output operands for 'GIMPLE_ASM' 'G'.
  
   -- GIMPLE function: unsigned gimple_asm_nclobbers (const gasm *g)
!      Return the number of clobber operands for 'GIMPLE_ASM' 'G'.
  
   -- GIMPLE function: tree gimple_asm_input_op (const gasm *g, unsigned
            index)
!      Return input operand 'INDEX' of 'GIMPLE_ASM' 'G'.
  
   -- GIMPLE function: void gimple_asm_set_input_op (gasm *g, unsigned
            index, tree in_op)
!      Set 'IN_OP' to be input operand 'INDEX' in 'GIMPLE_ASM' 'G'.
  
   -- GIMPLE function: tree gimple_asm_output_op (const gasm *g, unsigned
            index)
!      Return output operand 'INDEX' of 'GIMPLE_ASM' 'G'.
  
   -- GIMPLE function: void gimple_asm_set_output_op (gasm *g, unsigned
            index, tree out_op)
!      Set 'OUT_OP' to be output operand 'INDEX' in 'GIMPLE_ASM' 'G'.
  
   -- GIMPLE function: tree gimple_asm_clobber_op (const gasm *g, unsigned
            index)
!      Return clobber operand 'INDEX' of 'GIMPLE_ASM' 'G'.
  
   -- GIMPLE function: void gimple_asm_set_clobber_op (gasm *g, unsigned
            index, tree clobber_op)
!      Set 'CLOBBER_OP' to be clobber operand 'INDEX' in 'GIMPLE_ASM' 'G'.
  
   -- GIMPLE function: const char * gimple_asm_string (const gasm *g)
       Return the string representing the assembly instruction in
!      'GIMPLE_ASM' 'G'.
  
   -- GIMPLE function: bool gimple_asm_volatile_p (const gasm *g)
!      Return true if 'G' is an asm statement marked volatile.
  
   -- GIMPLE function: void gimple_asm_set_volatile (gasm *g, bool
            volatile_p)
!      Mark asm statement 'G' as volatile or non-volatile based on
!      'VOLATILE_P'.
  
  
  File: gccint.info,  Node: GIMPLE_ASSIGN,  Next: GIMPLE_BIND,  Prev: GIMPLE_ASM,  Up: Tuple specific accessors
  
! 12.8.2 'GIMPLE_ASSIGN'
  ----------------------
  
   -- GIMPLE function: gassign *gimple_build_assign (tree lhs, tree rhs)
!      Build a 'GIMPLE_ASSIGN' statement.  The left-hand side is an lvalue
       passed in lhs.  The right-hand side can be either a unary or binary
       tree expression.  The expression tree rhs will be flattened and its
       operands assigned to the corresponding operand slots in the new
--- 14236,14305 ----
  
  File: gccint.info,  Node: GIMPLE_ASM,  Next: GIMPLE_ASSIGN,  Up: Tuple specific accessors
  
! 12.8.1 ‘GIMPLE_ASM’
  -------------------
  
   -- GIMPLE function: gasm *gimple_build_asm_vec ( const char *string,
            vec *inputs, vec *outputs, vec *clobbers, vec *labels)
!      Build a ‘GIMPLE_ASM’ statement.  This statement is used for
!      building in-line assembly constructs.  ‘STRING’ is the assembly
!      code.  ‘INPUTS’, ‘OUTPUTS’, ‘CLOBBERS’ and ‘LABELS’ are the inputs,
       outputs, clobbered registers and labels.
  
   -- GIMPLE function: unsigned gimple_asm_ninputs (const gasm *g)
!      Return the number of input operands for ‘GIMPLE_ASM’ ‘G’.
  
   -- GIMPLE function: unsigned gimple_asm_noutputs (const gasm *g)
!      Return the number of output operands for ‘GIMPLE_ASM’ ‘G’.
  
   -- GIMPLE function: unsigned gimple_asm_nclobbers (const gasm *g)
!      Return the number of clobber operands for ‘GIMPLE_ASM’ ‘G’.
  
   -- GIMPLE function: tree gimple_asm_input_op (const gasm *g, unsigned
            index)
!      Return input operand ‘INDEX’ of ‘GIMPLE_ASM’ ‘G’.
  
   -- GIMPLE function: void gimple_asm_set_input_op (gasm *g, unsigned
            index, tree in_op)
!      Set ‘IN_OP’ to be input operand ‘INDEX’ in ‘GIMPLE_ASM’ ‘G’.
  
   -- GIMPLE function: tree gimple_asm_output_op (const gasm *g, unsigned
            index)
!      Return output operand ‘INDEX’ of ‘GIMPLE_ASM’ ‘G’.
  
   -- GIMPLE function: void gimple_asm_set_output_op (gasm *g, unsigned
            index, tree out_op)
!      Set ‘OUT_OP’ to be output operand ‘INDEX’ in ‘GIMPLE_ASM’ ‘G’.
  
   -- GIMPLE function: tree gimple_asm_clobber_op (const gasm *g, unsigned
            index)
!      Return clobber operand ‘INDEX’ of ‘GIMPLE_ASM’ ‘G’.
  
   -- GIMPLE function: void gimple_asm_set_clobber_op (gasm *g, unsigned
            index, tree clobber_op)
!      Set ‘CLOBBER_OP’ to be clobber operand ‘INDEX’ in ‘GIMPLE_ASM’ ‘G’.
  
   -- GIMPLE function: const char * gimple_asm_string (const gasm *g)
       Return the string representing the assembly instruction in
!      ‘GIMPLE_ASM’ ‘G’.
  
   -- GIMPLE function: bool gimple_asm_volatile_p (const gasm *g)
!      Return true if ‘G’ is an asm statement marked volatile.
  
   -- GIMPLE function: void gimple_asm_set_volatile (gasm *g, bool
            volatile_p)
!      Mark asm statement ‘G’ as volatile or non-volatile based on
!      ‘VOLATILE_P’.
  
  
  File: gccint.info,  Node: GIMPLE_ASSIGN,  Next: GIMPLE_BIND,  Prev: GIMPLE_ASM,  Up: Tuple specific accessors
  
! 12.8.2 ‘GIMPLE_ASSIGN’
  ----------------------
  
   -- GIMPLE function: gassign *gimple_build_assign (tree lhs, tree rhs)
!      Build a ‘GIMPLE_ASSIGN’ statement.  The left-hand side is an lvalue
       passed in lhs.  The right-hand side can be either a unary or binary
       tree expression.  The expression tree rhs will be flattened and its
       operands assigned to the corresponding operand slots in the new
*************** File: gccint.info,  Node: GIMPLE_ASSIGN,
*** 14307,14736 ****
       expression that you want to convert into a tuple.  However, try to
       avoid building expression trees for the sole purpose of calling
       this function.  If you already have the operands in separate trees,
!      it is better to use 'gimple_build_assign' with 'enum tree_code'
       argument and separate arguments for each operand.
  
   -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum
            tree_code subcode, tree op1, tree op2, tree op3)
!      This function is similar to two operand 'gimple_build_assign', but
!      is used to build a 'GIMPLE_ASSIGN' statement when the operands of
       the right-hand side of the assignment are already split into
       different operands.
  
       The left-hand side is an lvalue passed in lhs.  Subcode is the
!      'tree_code' for the right-hand side of the assignment.  Op1, op2
       and op3 are the operands.
  
   -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum
            tree_code subcode, tree op1, tree op2)
!      Like the above 5 operand 'gimple_build_assign', but with the last
!      argument 'NULL' - this overload should not be used for
!      'GIMPLE_TERNARY_RHS' assignments.
  
   -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum
            tree_code subcode, tree op1)
!      Like the above 4 operand 'gimple_build_assign', but with the last
!      argument 'NULL' - this overload should be used only for
!      'GIMPLE_UNARY_RHS' and 'GIMPLE_SINGLE_RHS' assignments.
  
   -- GIMPLE function: gimple gimplify_assign (tree dst, tree src,
            gimple_seq *seq_p)
!      Build a new 'GIMPLE_ASSIGN' tuple and append it to the end of
!      '*SEQ_P'.
  
!  'DST'/'SRC' are the destination and source respectively.  You can pass
! ungimplified trees in 'DST' or 'SRC', in which case they will be
  converted to a gimple operand if necessary.
  
!  This function returns the newly created 'GIMPLE_ASSIGN' tuple.
  
   -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g)
!      Return the code of the expression computed on the 'RHS' of
!      assignment statement 'G'.
  
   -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class
            (gimple g)
       Return the gimple rhs class of the code for the expression computed
!      on the rhs of assignment statement 'G'.  This will never return
!      'GIMPLE_INVALID_RHS'.
  
   -- GIMPLE function: tree gimple_assign_lhs (gimple g)
!      Return the 'LHS' of assignment statement 'G'.
  
   -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g)
!      Return a pointer to the 'LHS' of assignment statement 'G'.
  
   -- GIMPLE function: tree gimple_assign_rhs1 (gimple g)
!      Return the first operand on the 'RHS' of assignment statement 'G'.
  
   -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g)
!      Return the address of the first operand on the 'RHS' of assignment
!      statement 'G'.
  
   -- GIMPLE function: tree gimple_assign_rhs2 (gimple g)
!      Return the second operand on the 'RHS' of assignment statement 'G'.
  
   -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g)
!      Return the address of the second operand on the 'RHS' of assignment
!      statement 'G'.
  
   -- GIMPLE function: tree gimple_assign_rhs3 (gimple g)
!      Return the third operand on the 'RHS' of assignment statement 'G'.
  
   -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g)
!      Return the address of the third operand on the 'RHS' of assignment
!      statement 'G'.
  
   -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs)
!      Set 'LHS' to be the 'LHS' operand of assignment statement 'G'.
  
   -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs)
!      Set 'RHS' to be the first operand on the 'RHS' of assignment
!      statement 'G'.
  
   -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs)
!      Set 'RHS' to be the second operand on the 'RHS' of assignment
!      statement 'G'.
  
   -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs)
!      Set 'RHS' to be the third operand on the 'RHS' of assignment
!      statement 'G'.
  
   -- GIMPLE function: bool gimple_assign_cast_p (const_gimple s)
!      Return true if 'S' is a type-cast assignment.
  
  
  File: gccint.info,  Node: GIMPLE_BIND,  Next: GIMPLE_CALL,  Prev: GIMPLE_ASSIGN,  Up: Tuple specific accessors
  
! 12.8.3 'GIMPLE_BIND'
  --------------------
  
   -- GIMPLE function: gbind *gimple_build_bind (tree vars, gimple_seq
            body)
!      Build a 'GIMPLE_BIND' statement with a list of variables in 'VARS'
!      and a body of statements in sequence 'BODY'.
  
   -- GIMPLE function: tree gimple_bind_vars (const gbind *g)
!      Return the variables declared in the 'GIMPLE_BIND' statement 'G'.
  
   -- GIMPLE function: void gimple_bind_set_vars (gbind *g, tree vars)
!      Set 'VARS' to be the set of variables declared in the 'GIMPLE_BIND'
!      statement 'G'.
  
   -- GIMPLE function: void gimple_bind_append_vars (gbind *g, tree vars)
!      Append 'VARS' to the set of variables declared in the 'GIMPLE_BIND'
!      statement 'G'.
  
   -- GIMPLE function: gimple_seq gimple_bind_body (gbind *g)
!      Return the GIMPLE sequence contained in the 'GIMPLE_BIND' statement
!      'G'.
  
   -- GIMPLE function: void gimple_bind_set_body (gbind *g, gimple_seq
            seq)
!      Set 'SEQ' to be sequence contained in the 'GIMPLE_BIND' statement
!      'G'.
  
   -- GIMPLE function: void gimple_bind_add_stmt (gbind *gs, gimple stmt)
!      Append a statement to the end of a 'GIMPLE_BIND''s body.
  
   -- GIMPLE function: void gimple_bind_add_seq (gbind *gs, gimple_seq
            seq)
!      Append a sequence of statements to the end of a 'GIMPLE_BIND''s
       body.
  
   -- GIMPLE function: tree gimple_bind_block (const gbind *g)
!      Return the 'TREE_BLOCK' node associated with 'GIMPLE_BIND'
!      statement 'G'.  This is analogous to the 'BIND_EXPR_BLOCK' field in
       trees.
  
   -- GIMPLE function: void gimple_bind_set_block (gbind *g, tree block)
!      Set 'BLOCK' to be the 'TREE_BLOCK' node associated with
!      'GIMPLE_BIND' statement 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_CALL,  Next: GIMPLE_CATCH,  Prev: GIMPLE_BIND,  Up: Tuple specific accessors
  
! 12.8.4 'GIMPLE_CALL'
  --------------------
  
   -- GIMPLE function: gcall *gimple_build_call (tree fn, unsigned nargs,
            ...)
!      Build a 'GIMPLE_CALL' statement to function 'FN'.  The argument
!      'FN' must be either a 'FUNCTION_DECL' or a gimple call address as
!      determined by 'is_gimple_call_addr'.  'NARGS' are the number of
!      arguments.  The rest of the arguments follow the argument 'NARGS',
       and must be trees that are valid as rvalues in gimple (i.e., each
!      operand is validated with 'is_gimple_operand').
  
   -- GIMPLE function: gcall *gimple_build_call_from_tree (tree call_expr,
            tree fnptrtype)
!      Build a 'GIMPLE_CALL' from a 'CALL_EXPR' node.  The arguments and
       the function are taken from the expression directly.  The type of
!      the 'GIMPLE_CALL' is set from the second parameter passed by a
!      caller.  This routine assumes that 'call_expr' is already in GIMPLE
       form.  That is, its operands are GIMPLE values and the function
       call needs no further simplification.  All the call flags in
!      'call_expr' are copied over to the new 'GIMPLE_CALL'.
  
   -- GIMPLE function: gcall *gimple_build_call_vec (tree fn, vec
            args)
!      Identical to 'gimple_build_call' but the arguments are stored in a
!      'vec'.
  
   -- GIMPLE function: tree gimple_call_lhs (gimple g)
!      Return the 'LHS' of call statement 'G'.
  
   -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g)
!      Return a pointer to the 'LHS' of call statement 'G'.
  
   -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs)
!      Set 'LHS' to be the 'LHS' operand of call statement 'G'.
  
   -- GIMPLE function: tree gimple_call_fn (gimple g)
       Return the tree node representing the function called by call
!      statement 'G'.
  
   -- GIMPLE function: void gimple_call_set_fn (gcall *g, tree fn)
!      Set 'FN' to be the function called by call statement 'G'.  This has
       to be a gimple value specifying the address of the called function.
  
   -- GIMPLE function: tree gimple_call_fndecl (gimple g)
!      If a given 'GIMPLE_CALL''s callee is a 'FUNCTION_DECL', return it.
!      Otherwise return 'NULL'.  This function is analogous to
!      'get_callee_fndecl' in 'GENERIC'.
  
   -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl)
!      Set the called function to 'FNDECL'.
  
   -- GIMPLE function: tree gimple_call_return_type (const gcall *g)
!      Return the type returned by call statement 'G'.
  
   -- GIMPLE function: tree gimple_call_chain (gimple g)
!      Return the static chain for call statement 'G'.
  
   -- GIMPLE function: void gimple_call_set_chain (gcall *g, tree chain)
!      Set 'CHAIN' to be the static chain for call statement 'G'.
  
   -- GIMPLE function: unsigned gimple_call_num_args (gimple g)
!      Return the number of arguments used by call statement 'G'.
  
   -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index)
!      Return the argument at position 'INDEX' for call statement 'G'.
       The first argument is 0.
  
   -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned
            index)
!      Return a pointer to the argument at position 'INDEX' for call
!      statement 'G'.
  
   -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned index,
            tree arg)
!      Set 'ARG' to be the argument at position 'INDEX' for call statement
!      'G'.
  
   -- GIMPLE function: void gimple_call_set_tail (gcall *s)
!      Mark call statement 'S' as being a tail call (i.e., a call just
       before the exit of a function).  These calls are candidate for tail
       call optimization.
  
   -- GIMPLE function: bool gimple_call_tail_p (gcall *s)
!      Return true if 'GIMPLE_CALL' 'S' is marked as a tail call.
  
   -- GIMPLE function: bool gimple_call_noreturn_p (gimple s)
!      Return true if 'S' is a noreturn call.
  
   -- GIMPLE function: gimple gimple_call_copy_skip_args (gcall *stmt,
            bitmap args_to_skip)
!      Build a 'GIMPLE_CALL' identical to 'STMT' but skipping the
!      arguments in the positions marked by the set 'ARGS_TO_SKIP'.
  
  
  File: gccint.info,  Node: GIMPLE_CATCH,  Next: GIMPLE_COND,  Prev: GIMPLE_CALL,  Up: Tuple specific accessors
  
! 12.8.5 'GIMPLE_CATCH'
  ---------------------
  
   -- GIMPLE function: gcatch *gimple_build_catch (tree types, gimple_seq
            handler)
!      Build a 'GIMPLE_CATCH' statement.  'TYPES' are the tree types this
!      catch handles.  'HANDLER' is a sequence of statements with the code
       for the handler.
  
   -- GIMPLE function: tree gimple_catch_types (const gcatch *g)
!      Return the types handled by 'GIMPLE_CATCH' statement 'G'.
  
   -- GIMPLE function: tree * gimple_catch_types_ptr (gcatch *g)
!      Return a pointer to the types handled by 'GIMPLE_CATCH' statement
!      'G'.
  
   -- GIMPLE function: gimple_seq gimple_catch_handler (gcatch *g)
       Return the GIMPLE sequence representing the body of the handler of
!      'GIMPLE_CATCH' statement 'G'.
  
   -- GIMPLE function: void gimple_catch_set_types (gcatch *g, tree t)
!      Set 'T' to be the set of types handled by 'GIMPLE_CATCH' 'G'.
  
   -- GIMPLE function: void gimple_catch_set_handler (gcatch *g,
            gimple_seq handler)
!      Set 'HANDLER' to be the body of 'GIMPLE_CATCH' 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_COND,  Next: GIMPLE_DEBUG,  Prev: GIMPLE_CATCH,  Up: Tuple specific accessors
  
! 12.8.6 'GIMPLE_COND'
  --------------------
  
   -- GIMPLE function: gcond *gimple_build_cond ( enum tree_code
            pred_code, tree lhs, tree rhs, tree t_label, tree f_label)
!      Build a 'GIMPLE_COND' statement.  'A' 'GIMPLE_COND' statement
!      compares 'LHS' and 'RHS' and if the condition in 'PRED_CODE' is
!      true, jump to the label in 't_label', otherwise jump to the label
!      in 'f_label'.  'PRED_CODE' are relational operator tree codes like
!      'EQ_EXPR', 'LT_EXPR', 'LE_EXPR', 'NE_EXPR', etc.
  
   -- GIMPLE function: gcond *gimple_build_cond_from_tree (tree cond, tree
            t_label, tree f_label)
!      Build a 'GIMPLE_COND' statement from the conditional expression
!      tree 'COND'.  'T_LABEL' and 'F_LABEL' are as in
!      'gimple_build_cond'.
  
   -- GIMPLE function: enum tree_code gimple_cond_code (gimple g)
       Return the code of the predicate computed by conditional statement
!      'G'.
  
   -- GIMPLE function: void gimple_cond_set_code (gcond *g, enum tree_code
            code)
!      Set 'CODE' to be the predicate code for the conditional statement
!      'G'.
  
   -- GIMPLE function: tree gimple_cond_lhs (gimple g)
!      Return the 'LHS' of the predicate computed by conditional statement
!      'G'.
  
   -- GIMPLE function: void gimple_cond_set_lhs (gcond *g, tree lhs)
!      Set 'LHS' to be the 'LHS' operand of the predicate computed by
!      conditional statement 'G'.
  
   -- GIMPLE function: tree gimple_cond_rhs (gimple g)
!      Return the 'RHS' operand of the predicate computed by conditional
!      'G'.
  
   -- GIMPLE function: void gimple_cond_set_rhs (gcond *g, tree rhs)
!      Set 'RHS' to be the 'RHS' operand of the predicate computed by
!      conditional statement 'G'.
  
   -- GIMPLE function: tree gimple_cond_true_label (const gcond *g)
!      Return the label used by conditional statement 'G' when its
       predicate evaluates to true.
  
   -- GIMPLE function: void gimple_cond_set_true_label (gcond *g, tree
            label)
!      Set 'LABEL' to be the label used by conditional statement 'G' when
       its predicate evaluates to true.
  
   -- GIMPLE function: void gimple_cond_set_false_label (gcond *g, tree
            label)
!      Set 'LABEL' to be the label used by conditional statement 'G' when
       its predicate evaluates to false.
  
   -- GIMPLE function: tree gimple_cond_false_label (const gcond *g)
!      Return the label used by conditional statement 'G' when its
       predicate evaluates to false.
  
   -- GIMPLE function: void gimple_cond_make_false (gcond *g)
!      Set the conditional 'COND_STMT' to be of the form 'if (1 == 0)'.
  
   -- GIMPLE function: void gimple_cond_make_true (gcond *g)
!      Set the conditional 'COND_STMT' to be of the form 'if (1 == 1)'.
  
  
  File: gccint.info,  Node: GIMPLE_DEBUG,  Next: GIMPLE_EH_FILTER,  Prev: GIMPLE_COND,  Up: Tuple specific accessors
  
! 12.8.7 'GIMPLE_DEBUG'
  ---------------------
  
   -- GIMPLE function: gdebug *gimple_build_debug_bind (tree var, tree
            value, gimple stmt)
!      Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BIND'
!      'subcode'.  The effect of this statement is to tell debug
       information generation machinery that the value of user variable
!      'var' is given by 'value' at that point, and to remain with that
!      value until 'var' runs out of scope, a dynamically-subsequent debug
       bind statement overrides the binding, or conflicting values reach a
!      control flow merge point.  Even if components of the 'value'
       expression change afterwards, the variable is supposed to retain
       the same value, though not necessarily the same location.
  
!      It is expected that 'var' be most often a tree for automatic user
!      variables ('VAR_DECL' or 'PARM_DECL') that satisfy the requirements
       for gimple registers, but it may also be a tree for a scalarized
!      component of a user variable ('ARRAY_REF', 'COMPONENT_REF'), or a
!      debug temporary ('DEBUG_EXPR_DECL').
  
!      As for 'value', it can be an arbitrary tree expression, but it is
       recommended that it be in a suitable form for a gimple assignment
!      'RHS'.  It is not expected that user variables that could appear as
!      'var' ever appear in 'value', because in the latter we'd have their
!      'SSA_NAME's instead, but even if they were not in SSA form, user
!      variables appearing in 'value' are to be regarded as part of the
!      executable code space, whereas those in 'var' are to be regarded as
       part of the source code space.  There is no way to refer to the
!      value bound to a user variable within a 'value' expression.
  
!      If 'value' is 'GIMPLE_DEBUG_BIND_NOVALUE', debug information
!      generation machinery is informed that the variable 'var' is
       unbound, i.e., that its value is indeterminate, which sometimes
       means it is really unavailable, and other times that the compiler
       could not keep track of it.
  
       Block and location information for the newly-created stmt are taken
!      from 'stmt', if given.
  
   -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt)
!      Return the user variable VAR that is bound at 'stmt'.
  
   -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt)
       Return the value expression that is bound to a user variable at
!      'stmt'.
  
   -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple
            stmt)
       Return a pointer to the value expression that is bound to a user
!      variable at 'stmt'.
  
   -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree
            var)
!      Modify the user variable bound at 'stmt' to VAR.
  
   -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, tree
            var)
!      Modify the value bound to the user variable bound at 'stmt' to
       VALUE.
  
   -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt)
!      Modify the value bound to the user variable bound at 'stmt' so that
       the variable becomes unbound.
  
   -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt)
!      Return 'TRUE' if 'stmt' binds a user variable to a value, and
!      'FALSE' if it unbinds the variable.
  
   -- GIMPLE function: gimple gimple_build_debug_begin_stmt (tree block,
            location_t location)
!      Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BEGIN_STMT'
!      'subcode'.  The effect of this statement is to tell debug
       information generation machinery that the user statement at the
!      given 'location' and 'block' starts at the point at which the
       statement is inserted.  The intent is that side effects (e.g.
       variable bindings) of all prior user statements are observable, and
       that none of the side effects of subsequent user statements are.
  
   -- GIMPLE function: gimple gimple_build_debug_inline_entry (tree block,
            location_t location)
!      Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_INLINE_ENTRY'
!      'subcode'.  The effect of this statement is to tell debug
!      information generation machinery that a function call at 'location'
!      underwent inline substitution, that 'block' is the enclosing
       lexical block created for the substitution, and that at the point
       of the program in which the stmt is inserted, all parameters for
       the inlined function are bound to the respective arguments, and
--- 14307,14736 ----
       expression that you want to convert into a tuple.  However, try to
       avoid building expression trees for the sole purpose of calling
       this function.  If you already have the operands in separate trees,
!      it is better to use ‘gimple_build_assign’ with ‘enum tree_code’
       argument and separate arguments for each operand.
  
   -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum
            tree_code subcode, tree op1, tree op2, tree op3)
!      This function is similar to two operand ‘gimple_build_assign’, but
!      is used to build a ‘GIMPLE_ASSIGN’ statement when the operands of
       the right-hand side of the assignment are already split into
       different operands.
  
       The left-hand side is an lvalue passed in lhs.  Subcode is the
!      ‘tree_code’ for the right-hand side of the assignment.  Op1, op2
       and op3 are the operands.
  
   -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum
            tree_code subcode, tree op1, tree op2)
!      Like the above 5 operand ‘gimple_build_assign’, but with the last
!      argument ‘NULL’ - this overload should not be used for
!      ‘GIMPLE_TERNARY_RHS’ assignments.
  
   -- GIMPLE function: gassign *gimple_build_assign (tree lhs, enum
            tree_code subcode, tree op1)
!      Like the above 4 operand ‘gimple_build_assign’, but with the last
!      argument ‘NULL’ - this overload should be used only for
!      ‘GIMPLE_UNARY_RHS’ and ‘GIMPLE_SINGLE_RHS’ assignments.
  
   -- GIMPLE function: gimple gimplify_assign (tree dst, tree src,
            gimple_seq *seq_p)
!      Build a new ‘GIMPLE_ASSIGN’ tuple and append it to the end of
!      ‘*SEQ_P’.
  
!  ‘DST’/‘SRC’ are the destination and source respectively.  You can pass
! ungimplified trees in ‘DST’ or ‘SRC’, in which case they will be
  converted to a gimple operand if necessary.
  
!  This function returns the newly created ‘GIMPLE_ASSIGN’ tuple.
  
   -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g)
!      Return the code of the expression computed on the ‘RHS’ of
!      assignment statement ‘G’.
  
   -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class
            (gimple g)
       Return the gimple rhs class of the code for the expression computed
!      on the rhs of assignment statement ‘G’.  This will never return
!      ‘GIMPLE_INVALID_RHS’.
  
   -- GIMPLE function: tree gimple_assign_lhs (gimple g)
!      Return the ‘LHS’ of assignment statement ‘G’.
  
   -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g)
!      Return a pointer to the ‘LHS’ of assignment statement ‘G’.
  
   -- GIMPLE function: tree gimple_assign_rhs1 (gimple g)
!      Return the first operand on the ‘RHS’ of assignment statement ‘G’.
  
   -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g)
!      Return the address of the first operand on the ‘RHS’ of assignment
!      statement ‘G’.
  
   -- GIMPLE function: tree gimple_assign_rhs2 (gimple g)
!      Return the second operand on the ‘RHS’ of assignment statement ‘G’.
  
   -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g)
!      Return the address of the second operand on the ‘RHS’ of assignment
!      statement ‘G’.
  
   -- GIMPLE function: tree gimple_assign_rhs3 (gimple g)
!      Return the third operand on the ‘RHS’ of assignment statement ‘G’.
  
   -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g)
!      Return the address of the third operand on the ‘RHS’ of assignment
!      statement ‘G’.
  
   -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs)
!      Set ‘LHS’ to be the ‘LHS’ operand of assignment statement ‘G’.
  
   -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs)
!      Set ‘RHS’ to be the first operand on the ‘RHS’ of assignment
!      statement ‘G’.
  
   -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs)
!      Set ‘RHS’ to be the second operand on the ‘RHS’ of assignment
!      statement ‘G’.
  
   -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs)
!      Set ‘RHS’ to be the third operand on the ‘RHS’ of assignment
!      statement ‘G’.
  
   -- GIMPLE function: bool gimple_assign_cast_p (const_gimple s)
!      Return true if ‘S’ is a type-cast assignment.
  
  
  File: gccint.info,  Node: GIMPLE_BIND,  Next: GIMPLE_CALL,  Prev: GIMPLE_ASSIGN,  Up: Tuple specific accessors
  
! 12.8.3 ‘GIMPLE_BIND’
  --------------------
  
   -- GIMPLE function: gbind *gimple_build_bind (tree vars, gimple_seq
            body)
!      Build a ‘GIMPLE_BIND’ statement with a list of variables in ‘VARS’
!      and a body of statements in sequence ‘BODY’.
  
   -- GIMPLE function: tree gimple_bind_vars (const gbind *g)
!      Return the variables declared in the ‘GIMPLE_BIND’ statement ‘G’.
  
   -- GIMPLE function: void gimple_bind_set_vars (gbind *g, tree vars)
!      Set ‘VARS’ to be the set of variables declared in the ‘GIMPLE_BIND’
!      statement ‘G’.
  
   -- GIMPLE function: void gimple_bind_append_vars (gbind *g, tree vars)
!      Append ‘VARS’ to the set of variables declared in the ‘GIMPLE_BIND’
!      statement ‘G’.
  
   -- GIMPLE function: gimple_seq gimple_bind_body (gbind *g)
!      Return the GIMPLE sequence contained in the ‘GIMPLE_BIND’ statement
!      ‘G’.
  
   -- GIMPLE function: void gimple_bind_set_body (gbind *g, gimple_seq
            seq)
!      Set ‘SEQ’ to be sequence contained in the ‘GIMPLE_BIND’ statement
!      ‘G’.
  
   -- GIMPLE function: void gimple_bind_add_stmt (gbind *gs, gimple stmt)
!      Append a statement to the end of a ‘GIMPLE_BIND’'s body.
  
   -- GIMPLE function: void gimple_bind_add_seq (gbind *gs, gimple_seq
            seq)
!      Append a sequence of statements to the end of a ‘GIMPLE_BIND’'s
       body.
  
   -- GIMPLE function: tree gimple_bind_block (const gbind *g)
!      Return the ‘TREE_BLOCK’ node associated with ‘GIMPLE_BIND’
!      statement ‘G’.  This is analogous to the ‘BIND_EXPR_BLOCK’ field in
       trees.
  
   -- GIMPLE function: void gimple_bind_set_block (gbind *g, tree block)
!      Set ‘BLOCK’ to be the ‘TREE_BLOCK’ node associated with
!      ‘GIMPLE_BIND’ statement ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_CALL,  Next: GIMPLE_CATCH,  Prev: GIMPLE_BIND,  Up: Tuple specific accessors
  
! 12.8.4 ‘GIMPLE_CALL’
  --------------------
  
   -- GIMPLE function: gcall *gimple_build_call (tree fn, unsigned nargs,
            ...)
!      Build a ‘GIMPLE_CALL’ statement to function ‘FN’.  The argument
!      ‘FN’ must be either a ‘FUNCTION_DECL’ or a gimple call address as
!      determined by ‘is_gimple_call_addr’.  ‘NARGS’ are the number of
!      arguments.  The rest of the arguments follow the argument ‘NARGS’,
       and must be trees that are valid as rvalues in gimple (i.e., each
!      operand is validated with ‘is_gimple_operand’).
  
   -- GIMPLE function: gcall *gimple_build_call_from_tree (tree call_expr,
            tree fnptrtype)
!      Build a ‘GIMPLE_CALL’ from a ‘CALL_EXPR’ node.  The arguments and
       the function are taken from the expression directly.  The type of
!      the ‘GIMPLE_CALL’ is set from the second parameter passed by a
!      caller.  This routine assumes that ‘call_expr’ is already in GIMPLE
       form.  That is, its operands are GIMPLE values and the function
       call needs no further simplification.  All the call flags in
!      ‘call_expr’ are copied over to the new ‘GIMPLE_CALL’.
  
   -- GIMPLE function: gcall *gimple_build_call_vec (tree fn, vec
            args)
!      Identical to ‘gimple_build_call’ but the arguments are stored in a
!      ‘vec’.
  
   -- GIMPLE function: tree gimple_call_lhs (gimple g)
!      Return the ‘LHS’ of call statement ‘G’.
  
   -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g)
!      Return a pointer to the ‘LHS’ of call statement ‘G’.
  
   -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs)
!      Set ‘LHS’ to be the ‘LHS’ operand of call statement ‘G’.
  
   -- GIMPLE function: tree gimple_call_fn (gimple g)
       Return the tree node representing the function called by call
!      statement ‘G’.
  
   -- GIMPLE function: void gimple_call_set_fn (gcall *g, tree fn)
!      Set ‘FN’ to be the function called by call statement ‘G’.  This has
       to be a gimple value specifying the address of the called function.
  
   -- GIMPLE function: tree gimple_call_fndecl (gimple g)
!      If a given ‘GIMPLE_CALL’'s callee is a ‘FUNCTION_DECL’, return it.
!      Otherwise return ‘NULL’.  This function is analogous to
!      ‘get_callee_fndecl’ in ‘GENERIC’.
  
   -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl)
!      Set the called function to ‘FNDECL’.
  
   -- GIMPLE function: tree gimple_call_return_type (const gcall *g)
!      Return the type returned by call statement ‘G’.
  
   -- GIMPLE function: tree gimple_call_chain (gimple g)
!      Return the static chain for call statement ‘G’.
  
   -- GIMPLE function: void gimple_call_set_chain (gcall *g, tree chain)
!      Set ‘CHAIN’ to be the static chain for call statement ‘G’.
  
   -- GIMPLE function: unsigned gimple_call_num_args (gimple g)
!      Return the number of arguments used by call statement ‘G’.
  
   -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index)
!      Return the argument at position ‘INDEX’ for call statement ‘G’.
       The first argument is 0.
  
   -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned
            index)
!      Return a pointer to the argument at position ‘INDEX’ for call
!      statement ‘G’.
  
   -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned index,
            tree arg)
!      Set ‘ARG’ to be the argument at position ‘INDEX’ for call statement
!      ‘G’.
  
   -- GIMPLE function: void gimple_call_set_tail (gcall *s)
!      Mark call statement ‘S’ as being a tail call (i.e., a call just
       before the exit of a function).  These calls are candidate for tail
       call optimization.
  
   -- GIMPLE function: bool gimple_call_tail_p (gcall *s)
!      Return true if ‘GIMPLE_CALL’ ‘S’ is marked as a tail call.
  
   -- GIMPLE function: bool gimple_call_noreturn_p (gimple s)
!      Return true if ‘S’ is a noreturn call.
  
   -- GIMPLE function: gimple gimple_call_copy_skip_args (gcall *stmt,
            bitmap args_to_skip)
!      Build a ‘GIMPLE_CALL’ identical to ‘STMT’ but skipping the
!      arguments in the positions marked by the set ‘ARGS_TO_SKIP’.
  
  
  File: gccint.info,  Node: GIMPLE_CATCH,  Next: GIMPLE_COND,  Prev: GIMPLE_CALL,  Up: Tuple specific accessors
  
! 12.8.5 ‘GIMPLE_CATCH’
  ---------------------
  
   -- GIMPLE function: gcatch *gimple_build_catch (tree types, gimple_seq
            handler)
!      Build a ‘GIMPLE_CATCH’ statement.  ‘TYPES’ are the tree types this
!      catch handles.  ‘HANDLER’ is a sequence of statements with the code
       for the handler.
  
   -- GIMPLE function: tree gimple_catch_types (const gcatch *g)
!      Return the types handled by ‘GIMPLE_CATCH’ statement ‘G’.
  
   -- GIMPLE function: tree * gimple_catch_types_ptr (gcatch *g)
!      Return a pointer to the types handled by ‘GIMPLE_CATCH’ statement
!      ‘G’.
  
   -- GIMPLE function: gimple_seq gimple_catch_handler (gcatch *g)
       Return the GIMPLE sequence representing the body of the handler of
!      ‘GIMPLE_CATCH’ statement ‘G’.
  
   -- GIMPLE function: void gimple_catch_set_types (gcatch *g, tree t)
!      Set ‘T’ to be the set of types handled by ‘GIMPLE_CATCH’ ‘G’.
  
   -- GIMPLE function: void gimple_catch_set_handler (gcatch *g,
            gimple_seq handler)
!      Set ‘HANDLER’ to be the body of ‘GIMPLE_CATCH’ ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_COND,  Next: GIMPLE_DEBUG,  Prev: GIMPLE_CATCH,  Up: Tuple specific accessors
  
! 12.8.6 ‘GIMPLE_COND’
  --------------------
  
   -- GIMPLE function: gcond *gimple_build_cond ( enum tree_code
            pred_code, tree lhs, tree rhs, tree t_label, tree f_label)
!      Build a ‘GIMPLE_COND’ statement.  ‘A’ ‘GIMPLE_COND’ statement
!      compares ‘LHS’ and ‘RHS’ and if the condition in ‘PRED_CODE’ is
!      true, jump to the label in ‘t_label’, otherwise jump to the label
!      in ‘f_label’.  ‘PRED_CODE’ are relational operator tree codes like
!      ‘EQ_EXPR’, ‘LT_EXPR’, ‘LE_EXPR’, ‘NE_EXPR’, etc.
  
   -- GIMPLE function: gcond *gimple_build_cond_from_tree (tree cond, tree
            t_label, tree f_label)
!      Build a ‘GIMPLE_COND’ statement from the conditional expression
!      tree ‘COND’.  ‘T_LABEL’ and ‘F_LABEL’ are as in
!      ‘gimple_build_cond’.
  
   -- GIMPLE function: enum tree_code gimple_cond_code (gimple g)
       Return the code of the predicate computed by conditional statement
!      ‘G’.
  
   -- GIMPLE function: void gimple_cond_set_code (gcond *g, enum tree_code
            code)
!      Set ‘CODE’ to be the predicate code for the conditional statement
!      ‘G’.
  
   -- GIMPLE function: tree gimple_cond_lhs (gimple g)
!      Return the ‘LHS’ of the predicate computed by conditional statement
!      ‘G’.
  
   -- GIMPLE function: void gimple_cond_set_lhs (gcond *g, tree lhs)
!      Set ‘LHS’ to be the ‘LHS’ operand of the predicate computed by
!      conditional statement ‘G’.
  
   -- GIMPLE function: tree gimple_cond_rhs (gimple g)
!      Return the ‘RHS’ operand of the predicate computed by conditional
!      ‘G’.
  
   -- GIMPLE function: void gimple_cond_set_rhs (gcond *g, tree rhs)
!      Set ‘RHS’ to be the ‘RHS’ operand of the predicate computed by
!      conditional statement ‘G’.
  
   -- GIMPLE function: tree gimple_cond_true_label (const gcond *g)
!      Return the label used by conditional statement ‘G’ when its
       predicate evaluates to true.
  
   -- GIMPLE function: void gimple_cond_set_true_label (gcond *g, tree
            label)
!      Set ‘LABEL’ to be the label used by conditional statement ‘G’ when
       its predicate evaluates to true.
  
   -- GIMPLE function: void gimple_cond_set_false_label (gcond *g, tree
            label)
!      Set ‘LABEL’ to be the label used by conditional statement ‘G’ when
       its predicate evaluates to false.
  
   -- GIMPLE function: tree gimple_cond_false_label (const gcond *g)
!      Return the label used by conditional statement ‘G’ when its
       predicate evaluates to false.
  
   -- GIMPLE function: void gimple_cond_make_false (gcond *g)
!      Set the conditional ‘COND_STMT’ to be of the form 'if (1 == 0)'.
  
   -- GIMPLE function: void gimple_cond_make_true (gcond *g)
!      Set the conditional ‘COND_STMT’ to be of the form 'if (1 == 1)'.
  
  
  File: gccint.info,  Node: GIMPLE_DEBUG,  Next: GIMPLE_EH_FILTER,  Prev: GIMPLE_COND,  Up: Tuple specific accessors
  
! 12.8.7 ‘GIMPLE_DEBUG’
  ---------------------
  
   -- GIMPLE function: gdebug *gimple_build_debug_bind (tree var, tree
            value, gimple stmt)
!      Build a ‘GIMPLE_DEBUG’ statement with ‘GIMPLE_DEBUG_BIND’
!      ‘subcode’.  The effect of this statement is to tell debug
       information generation machinery that the value of user variable
!      ‘var’ is given by ‘value’ at that point, and to remain with that
!      value until ‘var’ runs out of scope, a dynamically-subsequent debug
       bind statement overrides the binding, or conflicting values reach a
!      control flow merge point.  Even if components of the ‘value’
       expression change afterwards, the variable is supposed to retain
       the same value, though not necessarily the same location.
  
!      It is expected that ‘var’ be most often a tree for automatic user
!      variables (‘VAR_DECL’ or ‘PARM_DECL’) that satisfy the requirements
       for gimple registers, but it may also be a tree for a scalarized
!      component of a user variable (‘ARRAY_REF’, ‘COMPONENT_REF’), or a
!      debug temporary (‘DEBUG_EXPR_DECL’).
  
!      As for ‘value’, it can be an arbitrary tree expression, but it is
       recommended that it be in a suitable form for a gimple assignment
!      ‘RHS’.  It is not expected that user variables that could appear as
!      ‘var’ ever appear in ‘value’, because in the latter we'd have their
!      ‘SSA_NAME’s instead, but even if they were not in SSA form, user
!      variables appearing in ‘value’ are to be regarded as part of the
!      executable code space, whereas those in ‘var’ are to be regarded as
       part of the source code space.  There is no way to refer to the
!      value bound to a user variable within a ‘value’ expression.
  
!      If ‘value’ is ‘GIMPLE_DEBUG_BIND_NOVALUE’, debug information
!      generation machinery is informed that the variable ‘var’ is
       unbound, i.e., that its value is indeterminate, which sometimes
       means it is really unavailable, and other times that the compiler
       could not keep track of it.
  
       Block and location information for the newly-created stmt are taken
!      from ‘stmt’, if given.
  
   -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt)
!      Return the user variable VAR that is bound at ‘stmt’.
  
   -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt)
       Return the value expression that is bound to a user variable at
!      ‘stmt’.
  
   -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple
            stmt)
       Return a pointer to the value expression that is bound to a user
!      variable at ‘stmt’.
  
   -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree
            var)
!      Modify the user variable bound at ‘stmt’ to VAR.
  
   -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, tree
            var)
!      Modify the value bound to the user variable bound at ‘stmt’ to
       VALUE.
  
   -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt)
!      Modify the value bound to the user variable bound at ‘stmt’ so that
       the variable becomes unbound.
  
   -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt)
!      Return ‘TRUE’ if ‘stmt’ binds a user variable to a value, and
!      ‘FALSE’ if it unbinds the variable.
  
   -- GIMPLE function: gimple gimple_build_debug_begin_stmt (tree block,
            location_t location)
!      Build a ‘GIMPLE_DEBUG’ statement with ‘GIMPLE_DEBUG_BEGIN_STMT’
!      ‘subcode’.  The effect of this statement is to tell debug
       information generation machinery that the user statement at the
!      given ‘location’ and ‘block’ starts at the point at which the
       statement is inserted.  The intent is that side effects (e.g.
       variable bindings) of all prior user statements are observable, and
       that none of the side effects of subsequent user statements are.
  
   -- GIMPLE function: gimple gimple_build_debug_inline_entry (tree block,
            location_t location)
!      Build a ‘GIMPLE_DEBUG’ statement with ‘GIMPLE_DEBUG_INLINE_ENTRY’
!      ‘subcode’.  The effect of this statement is to tell debug
!      information generation machinery that a function call at ‘location’
!      underwent inline substitution, that ‘block’ is the enclosing
       lexical block created for the substitution, and that at the point
       of the program in which the stmt is inserted, all parameters for
       the inlined function are bound to the respective arguments, and
*************** File: gccint.info,  Node: GIMPLE_DEBUG,
*** 14739,14772 ****
  
  File: gccint.info,  Node: GIMPLE_EH_FILTER,  Next: GIMPLE_LABEL,  Prev: GIMPLE_DEBUG,  Up: Tuple specific accessors
  
! 12.8.8 'GIMPLE_EH_FILTER'
  -------------------------
  
   -- GIMPLE function: geh_filter *gimple_build_eh_filter (tree types,
            gimple_seq failure)
!      Build a 'GIMPLE_EH_FILTER' statement.  'TYPES' are the filter's
!      types.  'FAILURE' is a sequence with the filter's failure action.
  
   -- GIMPLE function: tree gimple_eh_filter_types (gimple g)
!      Return the types handled by 'GIMPLE_EH_FILTER' statement 'G'.
  
   -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g)
!      Return a pointer to the types handled by 'GIMPLE_EH_FILTER'
!      statement 'G'.
  
   -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g)
!      Return the sequence of statement to execute when 'GIMPLE_EH_FILTER'
       statement fails.
  
   -- GIMPLE function: void gimple_eh_filter_set_types (geh_filter *g,
            tree types)
!      Set 'TYPES' to be the set of types handled by 'GIMPLE_EH_FILTER'
!      'G'.
  
   -- GIMPLE function: void gimple_eh_filter_set_failure (geh_filter *g,
            gimple_seq failure)
!      Set 'FAILURE' to be the sequence of statements to execute on
!      failure for 'GIMPLE_EH_FILTER' 'G'.
  
   -- GIMPLE function: tree gimple_eh_must_not_throw_fndecl ( geh_mnt
            *eh_mnt_stmt)
--- 14739,14772 ----
  
  File: gccint.info,  Node: GIMPLE_EH_FILTER,  Next: GIMPLE_LABEL,  Prev: GIMPLE_DEBUG,  Up: Tuple specific accessors
  
! 12.8.8 ‘GIMPLE_EH_FILTER’
  -------------------------
  
   -- GIMPLE function: geh_filter *gimple_build_eh_filter (tree types,
            gimple_seq failure)
!      Build a ‘GIMPLE_EH_FILTER’ statement.  ‘TYPES’ are the filter's
!      types.  ‘FAILURE’ is a sequence with the filter's failure action.
  
   -- GIMPLE function: tree gimple_eh_filter_types (gimple g)
!      Return the types handled by ‘GIMPLE_EH_FILTER’ statement ‘G’.
  
   -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g)
!      Return a pointer to the types handled by ‘GIMPLE_EH_FILTER’
!      statement ‘G’.
  
   -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g)
!      Return the sequence of statement to execute when ‘GIMPLE_EH_FILTER’
       statement fails.
  
   -- GIMPLE function: void gimple_eh_filter_set_types (geh_filter *g,
            tree types)
!      Set ‘TYPES’ to be the set of types handled by ‘GIMPLE_EH_FILTER’
!      ‘G’.
  
   -- GIMPLE function: void gimple_eh_filter_set_failure (geh_filter *g,
            gimple_seq failure)
!      Set ‘FAILURE’ to be the sequence of statements to execute on
!      failure for ‘GIMPLE_EH_FILTER’ ‘G’.
  
   -- GIMPLE function: tree gimple_eh_must_not_throw_fndecl ( geh_mnt
            *eh_mnt_stmt)
*************** File: gccint.info,  Node: GIMPLE_EH_FILT
*** 14779,14862 ****
  
  File: gccint.info,  Node: GIMPLE_LABEL,  Next: GIMPLE_GOTO,  Prev: GIMPLE_EH_FILTER,  Up: Tuple specific accessors
  
! 12.8.9 'GIMPLE_LABEL'
  ---------------------
  
   -- GIMPLE function: glabel *gimple_build_label (tree label)
!      Build a 'GIMPLE_LABEL' statement with corresponding to the tree
!      label, 'LABEL'.
  
   -- GIMPLE function: tree gimple_label_label (const glabel *g)
!      Return the 'LABEL_DECL' node used by 'GIMPLE_LABEL' statement 'G'.
  
   -- GIMPLE function: void gimple_label_set_label (glabel *g, tree label)
!      Set 'LABEL' to be the 'LABEL_DECL' node used by 'GIMPLE_LABEL'
!      statement 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_GOTO,  Next: GIMPLE_NOP,  Prev: GIMPLE_LABEL,  Up: Tuple specific accessors
  
! 12.8.10 'GIMPLE_GOTO'
  ---------------------
  
   -- GIMPLE function: ggoto *gimple_build_goto (tree dest)
!      Build a 'GIMPLE_GOTO' statement to label 'DEST'.
  
   -- GIMPLE function: tree gimple_goto_dest (gimple g)
!      Return the destination of the unconditional jump 'G'.
  
   -- GIMPLE function: void gimple_goto_set_dest (ggoto *g, tree dest)
!      Set 'DEST' to be the destination of the unconditional jump 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_NOP,  Next: GIMPLE_OMP_ATOMIC_LOAD,  Prev: GIMPLE_GOTO,  Up: Tuple specific accessors
  
! 12.8.11 'GIMPLE_NOP'
  --------------------
  
   -- GIMPLE function: gimple gimple_build_nop (void)
!      Build a 'GIMPLE_NOP' statement.
  
   -- GIMPLE function: bool gimple_nop_p (gimple g)
!      Returns 'TRUE' if statement 'G' is a 'GIMPLE_NOP'.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_ATOMIC_LOAD,  Next: GIMPLE_OMP_ATOMIC_STORE,  Prev: GIMPLE_NOP,  Up: Tuple specific accessors
  
! 12.8.12 'GIMPLE_OMP_ATOMIC_LOAD'
  --------------------------------
  
   -- GIMPLE function: gomp_atomic_load *gimple_build_omp_atomic_load (
            tree lhs, tree rhs)
!      Build a 'GIMPLE_OMP_ATOMIC_LOAD' statement.  'LHS' is the left-hand
!      side of the assignment.  'RHS' is the right-hand side of the
       assignment.
  
   -- GIMPLE function: void gimple_omp_atomic_load_set_lhs (
            gomp_atomic_load *g, tree lhs)
!      Set the 'LHS' of an atomic load.
  
   -- GIMPLE function: tree gimple_omp_atomic_load_lhs ( const
            gomp_atomic_load *g)
!      Get the 'LHS' of an atomic load.
  
   -- GIMPLE function: void gimple_omp_atomic_load_set_rhs (
            gomp_atomic_load *g, tree rhs)
!      Set the 'RHS' of an atomic set.
  
   -- GIMPLE function: tree gimple_omp_atomic_load_rhs ( const
            gomp_atomic_load *g)
!      Get the 'RHS' of an atomic set.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_ATOMIC_STORE,  Next: GIMPLE_OMP_CONTINUE,  Prev: GIMPLE_OMP_ATOMIC_LOAD,  Up: Tuple specific accessors
  
! 12.8.13 'GIMPLE_OMP_ATOMIC_STORE'
  ---------------------------------
  
   -- GIMPLE function: gomp_atomic_store *gimple_build_omp_atomic_store (
            tree val)
!      Build a 'GIMPLE_OMP_ATOMIC_STORE' statement.  'VAL' is the value to
       be stored.
  
   -- GIMPLE function: void gimple_omp_atomic_store_set_val (
--- 14779,14862 ----
  
  File: gccint.info,  Node: GIMPLE_LABEL,  Next: GIMPLE_GOTO,  Prev: GIMPLE_EH_FILTER,  Up: Tuple specific accessors
  
! 12.8.9 ‘GIMPLE_LABEL’
  ---------------------
  
   -- GIMPLE function: glabel *gimple_build_label (tree label)
!      Build a ‘GIMPLE_LABEL’ statement with corresponding to the tree
!      label, ‘LABEL’.
  
   -- GIMPLE function: tree gimple_label_label (const glabel *g)
!      Return the ‘LABEL_DECL’ node used by ‘GIMPLE_LABEL’ statement ‘G’.
  
   -- GIMPLE function: void gimple_label_set_label (glabel *g, tree label)
!      Set ‘LABEL’ to be the ‘LABEL_DECL’ node used by ‘GIMPLE_LABEL’
!      statement ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_GOTO,  Next: GIMPLE_NOP,  Prev: GIMPLE_LABEL,  Up: Tuple specific accessors
  
! 12.8.10 ‘GIMPLE_GOTO’
  ---------------------
  
   -- GIMPLE function: ggoto *gimple_build_goto (tree dest)
!      Build a ‘GIMPLE_GOTO’ statement to label ‘DEST’.
  
   -- GIMPLE function: tree gimple_goto_dest (gimple g)
!      Return the destination of the unconditional jump ‘G’.
  
   -- GIMPLE function: void gimple_goto_set_dest (ggoto *g, tree dest)
!      Set ‘DEST’ to be the destination of the unconditional jump ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_NOP,  Next: GIMPLE_OMP_ATOMIC_LOAD,  Prev: GIMPLE_GOTO,  Up: Tuple specific accessors
  
! 12.8.11 ‘GIMPLE_NOP’
  --------------------
  
   -- GIMPLE function: gimple gimple_build_nop (void)
!      Build a ‘GIMPLE_NOP’ statement.
  
   -- GIMPLE function: bool gimple_nop_p (gimple g)
!      Returns ‘TRUE’ if statement ‘G’ is a ‘GIMPLE_NOP’.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_ATOMIC_LOAD,  Next: GIMPLE_OMP_ATOMIC_STORE,  Prev: GIMPLE_NOP,  Up: Tuple specific accessors
  
! 12.8.12 ‘GIMPLE_OMP_ATOMIC_LOAD’
  --------------------------------
  
   -- GIMPLE function: gomp_atomic_load *gimple_build_omp_atomic_load (
            tree lhs, tree rhs)
!      Build a ‘GIMPLE_OMP_ATOMIC_LOAD’ statement.  ‘LHS’ is the left-hand
!      side of the assignment.  ‘RHS’ is the right-hand side of the
       assignment.
  
   -- GIMPLE function: void gimple_omp_atomic_load_set_lhs (
            gomp_atomic_load *g, tree lhs)
!      Set the ‘LHS’ of an atomic load.
  
   -- GIMPLE function: tree gimple_omp_atomic_load_lhs ( const
            gomp_atomic_load *g)
!      Get the ‘LHS’ of an atomic load.
  
   -- GIMPLE function: void gimple_omp_atomic_load_set_rhs (
            gomp_atomic_load *g, tree rhs)
!      Set the ‘RHS’ of an atomic set.
  
   -- GIMPLE function: tree gimple_omp_atomic_load_rhs ( const
            gomp_atomic_load *g)
!      Get the ‘RHS’ of an atomic set.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_ATOMIC_STORE,  Next: GIMPLE_OMP_CONTINUE,  Prev: GIMPLE_OMP_ATOMIC_LOAD,  Up: Tuple specific accessors
  
! 12.8.13 ‘GIMPLE_OMP_ATOMIC_STORE’
  ---------------------------------
  
   -- GIMPLE function: gomp_atomic_store *gimple_build_omp_atomic_store (
            tree val)
!      Build a ‘GIMPLE_OMP_ATOMIC_STORE’ statement.  ‘VAL’ is the value to
       be stored.
  
   -- GIMPLE function: void gimple_omp_atomic_store_set_val (
*************** File: gccint.info,  Node: GIMPLE_OMP_ATO
*** 14870,14888 ****
  
  File: gccint.info,  Node: GIMPLE_OMP_CONTINUE,  Next: GIMPLE_OMP_CRITICAL,  Prev: GIMPLE_OMP_ATOMIC_STORE,  Up: Tuple specific accessors
  
! 12.8.14 'GIMPLE_OMP_CONTINUE'
  -----------------------------
  
   -- GIMPLE function: gomp_continue *gimple_build_omp_continue ( tree
            control_def, tree control_use)
!      Build a 'GIMPLE_OMP_CONTINUE' statement.  'CONTROL_DEF' is the
!      definition of the control variable.  'CONTROL_USE' is the use of
       the control variable.
  
   -- GIMPLE function: tree gimple_omp_continue_control_def ( const
            gomp_continue *s)
       Return the definition of the control variable on a
!      'GIMPLE_OMP_CONTINUE' in 'S'.
  
   -- GIMPLE function: tree gimple_omp_continue_control_def_ptr (
            gomp_continue *s)
--- 14870,14888 ----
  
  File: gccint.info,  Node: GIMPLE_OMP_CONTINUE,  Next: GIMPLE_OMP_CRITICAL,  Prev: GIMPLE_OMP_ATOMIC_STORE,  Up: Tuple specific accessors
  
! 12.8.14 ‘GIMPLE_OMP_CONTINUE’
  -----------------------------
  
   -- GIMPLE function: gomp_continue *gimple_build_omp_continue ( tree
            control_def, tree control_use)
!      Build a ‘GIMPLE_OMP_CONTINUE’ statement.  ‘CONTROL_DEF’ is the
!      definition of the control variable.  ‘CONTROL_USE’ is the use of
       the control variable.
  
   -- GIMPLE function: tree gimple_omp_continue_control_def ( const
            gomp_continue *s)
       Return the definition of the control variable on a
!      ‘GIMPLE_OMP_CONTINUE’ in ‘S’.
  
   -- GIMPLE function: tree gimple_omp_continue_control_def_ptr (
            gomp_continue *s)
*************** File: gccint.info,  Node: GIMPLE_OMP_CON
*** 14890,14902 ****
  
   -- GIMPLE function: tree gimple_omp_continue_set_control_def (
            gomp_continue *s)
!      Set the control variable definition for a 'GIMPLE_OMP_CONTINUE'
!      statement in 'S'.
  
   -- GIMPLE function: tree gimple_omp_continue_control_use ( const
            gomp_continue *s)
!      Return the use of the control variable on a 'GIMPLE_OMP_CONTINUE'
!      in 'S'.
  
   -- GIMPLE function: tree gimple_omp_continue_control_use_ptr (
            gomp_continue *s)
--- 14890,14902 ----
  
   -- GIMPLE function: tree gimple_omp_continue_set_control_def (
            gomp_continue *s)
!      Set the control variable definition for a ‘GIMPLE_OMP_CONTINUE’
!      statement in ‘S’.
  
   -- GIMPLE function: tree gimple_omp_continue_control_use ( const
            gomp_continue *s)
!      Return the use of the control variable on a ‘GIMPLE_OMP_CONTINUE’
!      in ‘S’.
  
   -- GIMPLE function: tree gimple_omp_continue_control_use_ptr (
            gomp_continue *s)
*************** File: gccint.info,  Node: GIMPLE_OMP_CON
*** 14904,15316 ****
  
   -- GIMPLE function: tree gimple_omp_continue_set_control_use (
            gomp_continue *s)
!      Set the control variable use for a 'GIMPLE_OMP_CONTINUE' statement
!      in 'S'.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_CRITICAL,  Next: GIMPLE_OMP_FOR,  Prev: GIMPLE_OMP_CONTINUE,  Up: Tuple specific accessors
  
! 12.8.15 'GIMPLE_OMP_CRITICAL'
  -----------------------------
  
   -- GIMPLE function: gomp_critical *gimple_build_omp_critical (
            gimple_seq body, tree name)
!      Build a 'GIMPLE_OMP_CRITICAL' statement.  'BODY' is the sequence of
!      statements for which only one thread can execute.  'NAME' is an
       optional identifier for this critical block.
  
   -- GIMPLE function: tree gimple_omp_critical_name ( const gomp_critical
            *g)
!      Return the name associated with 'OMP_CRITICAL' statement 'G'.
  
   -- GIMPLE function: tree * gimple_omp_critical_name_ptr ( gomp_critical
            *g)
!      Return a pointer to the name associated with 'OMP' critical
!      statement 'G'.
  
   -- GIMPLE function: void gimple_omp_critical_set_name ( gomp_critical
            *g, tree name)
!      Set 'NAME' to be the name associated with 'OMP' critical statement
!      'G'.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_FOR,  Next: GIMPLE_OMP_MASTER,  Prev: GIMPLE_OMP_CRITICAL,  Up: Tuple specific accessors
  
! 12.8.16 'GIMPLE_OMP_FOR'
  ------------------------
  
   -- GIMPLE function: gomp_for *gimple_build_omp_for (gimple_seq body,
            tree clauses, tree index, tree initial, tree final, tree incr,
            gimple_seq pre_body, enum tree_code omp_for_cond)
!      Build a 'GIMPLE_OMP_FOR' statement.  'BODY' is sequence of
!      statements inside the for loop.  'CLAUSES', are any of the loop
!      construct's clauses.  'PRE_BODY' is the sequence of statements that
!      are loop invariant.  'INDEX' is the index variable.  'INITIAL' is
!      the initial value of 'INDEX'.  'FINAL' is final value of 'INDEX'.
!      OMP_FOR_COND is the predicate used to compare 'INDEX' and 'FINAL'.
!      'INCR' is the increment expression.
  
   -- GIMPLE function: tree gimple_omp_for_clauses (gimple g)
!      Return the clauses associated with 'OMP_FOR' 'G'.
  
   -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g)
!      Return a pointer to the 'OMP_FOR' 'G'.
  
   -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree
            clauses)
!      Set 'CLAUSES' to be the list of clauses associated with 'OMP_FOR'
!      'G'.
  
   -- GIMPLE function: tree gimple_omp_for_index (gimple g)
!      Return the index variable for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g)
!      Return a pointer to the index variable for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree
            index)
!      Set 'INDEX' to be the index variable for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: tree gimple_omp_for_initial (gimple g)
!      Return the initial value for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g)
!      Return a pointer to the initial value for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree
            initial)
!      Set 'INITIAL' to be the initial value for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: tree gimple_omp_for_final (gimple g)
!      Return the final value for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g)
!      turn a pointer to the final value for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree
            final)
!      Set 'FINAL' to be the final value for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: tree gimple_omp_for_incr (gimple g)
!      Return the increment value for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g)
!      Return a pointer to the increment value for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr)
!      Set 'INCR' to be the increment value for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g)
!      Return the sequence of statements to execute before the 'OMP_FOR'
!      statement 'G' starts.
  
   -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g,
            gimple_seq pre_body)
!      Set 'PRE_BODY' to be the sequence of statements to execute before
!      the 'OMP_FOR' statement 'G' starts.
  
   -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum
            tree_code cond)
!      Set 'COND' to be the condition code for 'OMP_FOR' 'G'.
  
   -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g)
!      Return the condition code associated with 'OMP_FOR' 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_MASTER,  Next: GIMPLE_OMP_ORDERED,  Prev: GIMPLE_OMP_FOR,  Up: Tuple specific accessors
  
! 12.8.17 'GIMPLE_OMP_MASTER'
  ---------------------------
  
   -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body)
!      Build a 'GIMPLE_OMP_MASTER' statement.  'BODY' is the sequence of
       statements to be executed by just the master.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_ORDERED,  Next: GIMPLE_OMP_PARALLEL,  Prev: GIMPLE_OMP_MASTER,  Up: Tuple specific accessors
  
! 12.8.18 'GIMPLE_OMP_ORDERED'
  ----------------------------
  
   -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body)
!      Build a 'GIMPLE_OMP_ORDERED' statement.
  
!      'BODY' is the sequence of statements inside a loop that will
       executed in sequence.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_PARALLEL,  Next: GIMPLE_OMP_RETURN,  Prev: GIMPLE_OMP_ORDERED,  Up: Tuple specific accessors
  
! 12.8.19 'GIMPLE_OMP_PARALLEL'
  -----------------------------
  
   -- GIMPLE function: gomp_parallel *gimple_build_omp_parallel
            (gimple_seq body, tree clauses, tree child_fn, tree data_arg)
!      Build a 'GIMPLE_OMP_PARALLEL' statement.
  
!      'BODY' is sequence of statements which are executed in parallel.
!      'CLAUSES', are the 'OMP' parallel construct's clauses.  'CHILD_FN'
       is the function created for the parallel threads to execute.
!      'DATA_ARG' are the shared data argument(s).
  
   -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g)
!      Return true if 'OMP' parallel statement 'G' has the
!      'GF_OMP_PARALLEL_COMBINED' flag set.
  
   -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g)
!      Set the 'GF_OMP_PARALLEL_COMBINED' field in 'OMP' parallel
!      statement 'G'.
  
   -- GIMPLE function: gimple_seq gimple_omp_body (gimple g)
!      Return the body for the 'OMP' statement 'G'.
  
   -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq
            body)
!      Set 'BODY' to be the body for the 'OMP' statement 'G'.
  
   -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g)
!      Return the clauses associated with 'OMP_PARALLEL' 'G'.
  
   -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr (
            gomp_parallel *g)
!      Return a pointer to the clauses associated with 'OMP_PARALLEL' 'G'.
  
   -- GIMPLE function: void gimple_omp_parallel_set_clauses (
            gomp_parallel *g, tree clauses)
!      Set 'CLAUSES' to be the list of clauses associated with
!      'OMP_PARALLEL' 'G'.
  
   -- GIMPLE function: tree gimple_omp_parallel_child_fn ( const
            gomp_parallel *g)
!      Return the child function used to hold the body of 'OMP_PARALLEL'
!      'G'.
  
   -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr (
            gomp_parallel *g)
       Return a pointer to the child function used to hold the body of
!      'OMP_PARALLEL' 'G'.
  
   -- GIMPLE function: void gimple_omp_parallel_set_child_fn (
            gomp_parallel *g, tree child_fn)
!      Set 'CHILD_FN' to be the child function for 'OMP_PARALLEL' 'G'.
  
   -- GIMPLE function: tree gimple_omp_parallel_data_arg ( const
            gomp_parallel *g)
       Return the artificial argument used to send variables and values
!      from the parent to the children threads in 'OMP_PARALLEL' 'G'.
  
   -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr (
            gomp_parallel *g)
!      Return a pointer to the data argument for 'OMP_PARALLEL' 'G'.
  
   -- GIMPLE function: void gimple_omp_parallel_set_data_arg (
            gomp_parallel *g, tree data_arg)
!      Set 'DATA_ARG' to be the data argument for 'OMP_PARALLEL' 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_RETURN,  Next: GIMPLE_OMP_SECTION,  Prev: GIMPLE_OMP_PARALLEL,  Up: Tuple specific accessors
  
! 12.8.20 'GIMPLE_OMP_RETURN'
  ---------------------------
  
   -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p)
!      Build a 'GIMPLE_OMP_RETURN' statement.  'WAIT_P' is true if this is
       a non-waiting return.
  
   -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s)
!      Set the nowait flag on 'GIMPLE_OMP_RETURN' statement 'S'.
  
   -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g)
!      Return true if 'OMP' return statement 'G' has the
!      'GF_OMP_RETURN_NOWAIT' flag set.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_SECTION,  Next: GIMPLE_OMP_SECTIONS,  Prev: GIMPLE_OMP_RETURN,  Up: Tuple specific accessors
  
! 12.8.21 'GIMPLE_OMP_SECTION'
  ----------------------------
  
   -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body)
!      Build a 'GIMPLE_OMP_SECTION' statement for a sections statement.
  
!      'BODY' is the sequence of statements in the section.
  
   -- GIMPLE function: bool gimple_omp_section_last_p (gimple g)
!      Return true if 'OMP' section statement 'G' has the
!      'GF_OMP_SECTION_LAST' flag set.
  
   -- GIMPLE function: void gimple_omp_section_set_last (gimple g)
!      Set the 'GF_OMP_SECTION_LAST' flag on 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_SECTIONS,  Next: GIMPLE_OMP_SINGLE,  Prev: GIMPLE_OMP_SECTION,  Up: Tuple specific accessors
  
! 12.8.22 'GIMPLE_OMP_SECTIONS'
  -----------------------------
  
   -- GIMPLE function: gomp_sections *gimple_build_omp_sections (
            gimple_seq body, tree clauses)
!      Build a 'GIMPLE_OMP_SECTIONS' statement.  'BODY' is a sequence of
!      section statements.  'CLAUSES' are any of the 'OMP' sections
       construct's clauses: private, firstprivate, lastprivate, reduction,
       and nowait.
  
   -- GIMPLE function: gimple gimple_build_omp_sections_switch (void)
!      Build a 'GIMPLE_OMP_SECTIONS_SWITCH' statement.
  
   -- GIMPLE function: tree gimple_omp_sections_control (gimple g)
       Return the control variable associated with the
!      'GIMPLE_OMP_SECTIONS' in 'G'.
  
   -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g)
       Return a pointer to the clauses associated with the
!      'GIMPLE_OMP_SECTIONS' in 'G'.
  
   -- GIMPLE function: void gimple_omp_sections_set_control (gimple g,
            tree control)
!      Set 'CONTROL' to be the set of clauses associated with the
!      'GIMPLE_OMP_SECTIONS' in 'G'.
  
   -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g)
!      Return the clauses associated with 'OMP_SECTIONS' 'G'.
  
   -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g)
!      Return a pointer to the clauses associated with 'OMP_SECTIONS' 'G'.
  
   -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g,
            tree clauses)
!      Set 'CLAUSES' to be the set of clauses associated with
!      'OMP_SECTIONS' 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_SINGLE,  Next: GIMPLE_PHI,  Prev: GIMPLE_OMP_SECTIONS,  Up: Tuple specific accessors
  
! 12.8.23 'GIMPLE_OMP_SINGLE'
  ---------------------------
  
   -- GIMPLE function: gomp_single *gimple_build_omp_single ( gimple_seq
            body, tree clauses)
!      Build a 'GIMPLE_OMP_SINGLE' statement.  'BODY' is the sequence of
!      statements that will be executed once.  'CLAUSES' are any of the
!      'OMP' single construct's clauses: private, firstprivate,
       copyprivate, nowait.
  
   -- GIMPLE function: tree gimple_omp_single_clauses (gimple g)
!      Return the clauses associated with 'OMP_SINGLE' 'G'.
  
   -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g)
!      Return a pointer to the clauses associated with 'OMP_SINGLE' 'G'.
  
   -- GIMPLE function: void gimple_omp_single_set_clauses ( gomp_single
            *g, tree clauses)
!      Set 'CLAUSES' to be the clauses associated with 'OMP_SINGLE' 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_PHI,  Next: GIMPLE_RESX,  Prev: GIMPLE_OMP_SINGLE,  Up: Tuple specific accessors
  
! 12.8.24 'GIMPLE_PHI'
  --------------------
  
   -- GIMPLE function: unsigned gimple_phi_capacity (gimple g)
!      Return the maximum number of arguments supported by 'GIMPLE_PHI'
!      'G'.
  
   -- GIMPLE function: unsigned gimple_phi_num_args (gimple g)
!      Return the number of arguments in 'GIMPLE_PHI' 'G'.  This must
       always be exactly the number of incoming edges for the basic block
!      holding 'G'.
  
   -- GIMPLE function: tree gimple_phi_result (gimple g)
!      Return the 'SSA' name created by 'GIMPLE_PHI' 'G'.
  
   -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g)
!      Return a pointer to the 'SSA' name created by 'GIMPLE_PHI' 'G'.
  
   -- GIMPLE function: void gimple_phi_set_result (gphi *g, tree result)
!      Set 'RESULT' to be the 'SSA' name created by 'GIMPLE_PHI' 'G'.
  
   -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index)
!      Return the 'PHI' argument corresponding to incoming edge 'INDEX'
!      for 'GIMPLE_PHI' 'G'.
  
   -- GIMPLE function: void gimple_phi_set_arg (gphi *g, index, struct
            phi_arg_d * phiarg)
!      Set 'PHIARG' to be the argument corresponding to incoming edge
!      'INDEX' for 'GIMPLE_PHI' 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_RESX,  Next: GIMPLE_RETURN,  Prev: GIMPLE_PHI,  Up: Tuple specific accessors
  
! 12.8.25 'GIMPLE_RESX'
  ---------------------
  
   -- GIMPLE function: gresx *gimple_build_resx (int region)
!      Build a 'GIMPLE_RESX' statement which is a statement.  This
       statement is a placeholder for _Unwind_Resume before we know if a
!      function call or a branch is needed.  'REGION' is the exception
       region from which control is flowing.
  
   -- GIMPLE function: int gimple_resx_region (const gresx *g)
!      Return the region number for 'GIMPLE_RESX' 'G'.
  
   -- GIMPLE function: void gimple_resx_set_region (gresx *g, int region)
!      Set 'REGION' to be the region number for 'GIMPLE_RESX' 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_RETURN,  Next: GIMPLE_SWITCH,  Prev: GIMPLE_RESX,  Up: Tuple specific accessors
  
! 12.8.26 'GIMPLE_RETURN'
  -----------------------
  
   -- GIMPLE function: greturn *gimple_build_return (tree retval)
!      Build a 'GIMPLE_RETURN' statement whose return value is retval.
  
   -- GIMPLE function: tree gimple_return_retval (const greturn *g)
!      Return the return value for 'GIMPLE_RETURN' 'G'.
  
   -- GIMPLE function: void gimple_return_set_retval (greturn *g, tree
            retval)
!      Set 'RETVAL' to be the return value for 'GIMPLE_RETURN' 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_SWITCH,  Next: GIMPLE_TRY,  Prev: GIMPLE_RETURN,  Up: Tuple specific accessors
  
! 12.8.27 'GIMPLE_SWITCH'
  -----------------------
  
   -- GIMPLE function: gswitch *gimple_build_switch (tree index, tree
            default_label, vec *args)
!      Build a 'GIMPLE_SWITCH' statement.  'INDEX' is the index variable
!      to switch on, and 'DEFAULT_LABEL' represents the default label.
!      'ARGS' is a vector of 'CASE_LABEL_EXPR' trees that contain the
       non-default case labels.  Each label is a tree of code
!      'CASE_LABEL_EXPR'.
  
   -- GIMPLE function: unsigned gimple_switch_num_labels ( const gswitch
            *g)
       Return the number of labels associated with the switch statement
!      'G'.
  
   -- GIMPLE function: void gimple_switch_set_num_labels (gswitch *g,
            unsigned nlabels)
!      Set 'NLABELS' to be the number of labels for the switch statement
!      'G'.
  
   -- GIMPLE function: tree gimple_switch_index (const gswitch *g)
!      Return the index variable used by the switch statement 'G'.
  
   -- GIMPLE function: void gimple_switch_set_index (gswitch *g, tree
            index)
!      Set 'INDEX' to be the index variable for switch statement 'G'.
  
   -- GIMPLE function: tree gimple_switch_label (const gswitch *g,
            unsigned index)
!      Return the label numbered 'INDEX'.  The default label is 0,
       followed by any labels in a switch statement.
  
   -- GIMPLE function: void gimple_switch_set_label (gswitch *g, unsigned
            index, tree label)
!      Set the label number 'INDEX' to 'LABEL'.  0 is always the default
       label.
  
   -- GIMPLE function: tree gimple_switch_default_label ( const gswitch
--- 14904,15316 ----
  
   -- GIMPLE function: tree gimple_omp_continue_set_control_use (
            gomp_continue *s)
!      Set the control variable use for a ‘GIMPLE_OMP_CONTINUE’ statement
!      in ‘S’.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_CRITICAL,  Next: GIMPLE_OMP_FOR,  Prev: GIMPLE_OMP_CONTINUE,  Up: Tuple specific accessors
  
! 12.8.15 ‘GIMPLE_OMP_CRITICAL’
  -----------------------------
  
   -- GIMPLE function: gomp_critical *gimple_build_omp_critical (
            gimple_seq body, tree name)
!      Build a ‘GIMPLE_OMP_CRITICAL’ statement.  ‘BODY’ is the sequence of
!      statements for which only one thread can execute.  ‘NAME’ is an
       optional identifier for this critical block.
  
   -- GIMPLE function: tree gimple_omp_critical_name ( const gomp_critical
            *g)
!      Return the name associated with ‘OMP_CRITICAL’ statement ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_critical_name_ptr ( gomp_critical
            *g)
!      Return a pointer to the name associated with ‘OMP’ critical
!      statement ‘G’.
  
   -- GIMPLE function: void gimple_omp_critical_set_name ( gomp_critical
            *g, tree name)
!      Set ‘NAME’ to be the name associated with ‘OMP’ critical statement
!      ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_FOR,  Next: GIMPLE_OMP_MASTER,  Prev: GIMPLE_OMP_CRITICAL,  Up: Tuple specific accessors
  
! 12.8.16 ‘GIMPLE_OMP_FOR’
  ------------------------
  
   -- GIMPLE function: gomp_for *gimple_build_omp_for (gimple_seq body,
            tree clauses, tree index, tree initial, tree final, tree incr,
            gimple_seq pre_body, enum tree_code omp_for_cond)
!      Build a ‘GIMPLE_OMP_FOR’ statement.  ‘BODY’ is sequence of
!      statements inside the for loop.  ‘CLAUSES’, are any of the loop
!      construct's clauses.  ‘PRE_BODY’ is the sequence of statements that
!      are loop invariant.  ‘INDEX’ is the index variable.  ‘INITIAL’ is
!      the initial value of ‘INDEX’.  ‘FINAL’ is final value of ‘INDEX’.
!      OMP_FOR_COND is the predicate used to compare ‘INDEX’ and ‘FINAL’.
!      ‘INCR’ is the increment expression.
  
   -- GIMPLE function: tree gimple_omp_for_clauses (gimple g)
!      Return the clauses associated with ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g)
!      Return a pointer to the ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree
            clauses)
!      Set ‘CLAUSES’ to be the list of clauses associated with ‘OMP_FOR’
!      ‘G’.
  
   -- GIMPLE function: tree gimple_omp_for_index (gimple g)
!      Return the index variable for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g)
!      Return a pointer to the index variable for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree
            index)
!      Set ‘INDEX’ to be the index variable for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: tree gimple_omp_for_initial (gimple g)
!      Return the initial value for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g)
!      Return a pointer to the initial value for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree
            initial)
!      Set ‘INITIAL’ to be the initial value for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: tree gimple_omp_for_final (gimple g)
!      Return the final value for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g)
!      turn a pointer to the final value for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree
            final)
!      Set ‘FINAL’ to be the final value for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: tree gimple_omp_for_incr (gimple g)
!      Return the increment value for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g)
!      Return a pointer to the increment value for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr)
!      Set ‘INCR’ to be the increment value for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g)
!      Return the sequence of statements to execute before the ‘OMP_FOR’
!      statement ‘G’ starts.
  
   -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g,
            gimple_seq pre_body)
!      Set ‘PRE_BODY’ to be the sequence of statements to execute before
!      the ‘OMP_FOR’ statement ‘G’ starts.
  
   -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum
            tree_code cond)
!      Set ‘COND’ to be the condition code for ‘OMP_FOR’ ‘G’.
  
   -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g)
!      Return the condition code associated with ‘OMP_FOR’ ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_MASTER,  Next: GIMPLE_OMP_ORDERED,  Prev: GIMPLE_OMP_FOR,  Up: Tuple specific accessors
  
! 12.8.17 ‘GIMPLE_OMP_MASTER’
  ---------------------------
  
   -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body)
!      Build a ‘GIMPLE_OMP_MASTER’ statement.  ‘BODY’ is the sequence of
       statements to be executed by just the master.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_ORDERED,  Next: GIMPLE_OMP_PARALLEL,  Prev: GIMPLE_OMP_MASTER,  Up: Tuple specific accessors
  
! 12.8.18 ‘GIMPLE_OMP_ORDERED’
  ----------------------------
  
   -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body)
!      Build a ‘GIMPLE_OMP_ORDERED’ statement.
  
!      ‘BODY’ is the sequence of statements inside a loop that will
       executed in sequence.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_PARALLEL,  Next: GIMPLE_OMP_RETURN,  Prev: GIMPLE_OMP_ORDERED,  Up: Tuple specific accessors
  
! 12.8.19 ‘GIMPLE_OMP_PARALLEL’
  -----------------------------
  
   -- GIMPLE function: gomp_parallel *gimple_build_omp_parallel
            (gimple_seq body, tree clauses, tree child_fn, tree data_arg)
!      Build a ‘GIMPLE_OMP_PARALLEL’ statement.
  
!      ‘BODY’ is sequence of statements which are executed in parallel.
!      ‘CLAUSES’, are the ‘OMP’ parallel construct's clauses.  ‘CHILD_FN’
       is the function created for the parallel threads to execute.
!      ‘DATA_ARG’ are the shared data argument(s).
  
   -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g)
!      Return true if ‘OMP’ parallel statement ‘G’ has the
!      ‘GF_OMP_PARALLEL_COMBINED’ flag set.
  
   -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g)
!      Set the ‘GF_OMP_PARALLEL_COMBINED’ field in ‘OMP’ parallel
!      statement ‘G’.
  
   -- GIMPLE function: gimple_seq gimple_omp_body (gimple g)
!      Return the body for the ‘OMP’ statement ‘G’.
  
   -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq
            body)
!      Set ‘BODY’ to be the body for the ‘OMP’ statement ‘G’.
  
   -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g)
!      Return the clauses associated with ‘OMP_PARALLEL’ ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr (
            gomp_parallel *g)
!      Return a pointer to the clauses associated with ‘OMP_PARALLEL’ ‘G’.
  
   -- GIMPLE function: void gimple_omp_parallel_set_clauses (
            gomp_parallel *g, tree clauses)
!      Set ‘CLAUSES’ to be the list of clauses associated with
!      ‘OMP_PARALLEL’ ‘G’.
  
   -- GIMPLE function: tree gimple_omp_parallel_child_fn ( const
            gomp_parallel *g)
!      Return the child function used to hold the body of ‘OMP_PARALLEL’
!      ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr (
            gomp_parallel *g)
       Return a pointer to the child function used to hold the body of
!      ‘OMP_PARALLEL’ ‘G’.
  
   -- GIMPLE function: void gimple_omp_parallel_set_child_fn (
            gomp_parallel *g, tree child_fn)
!      Set ‘CHILD_FN’ to be the child function for ‘OMP_PARALLEL’ ‘G’.
  
   -- GIMPLE function: tree gimple_omp_parallel_data_arg ( const
            gomp_parallel *g)
       Return the artificial argument used to send variables and values
!      from the parent to the children threads in ‘OMP_PARALLEL’ ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr (
            gomp_parallel *g)
!      Return a pointer to the data argument for ‘OMP_PARALLEL’ ‘G’.
  
   -- GIMPLE function: void gimple_omp_parallel_set_data_arg (
            gomp_parallel *g, tree data_arg)
!      Set ‘DATA_ARG’ to be the data argument for ‘OMP_PARALLEL’ ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_RETURN,  Next: GIMPLE_OMP_SECTION,  Prev: GIMPLE_OMP_PARALLEL,  Up: Tuple specific accessors
  
! 12.8.20 ‘GIMPLE_OMP_RETURN’
  ---------------------------
  
   -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p)
!      Build a ‘GIMPLE_OMP_RETURN’ statement.  ‘WAIT_P’ is true if this is
       a non-waiting return.
  
   -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s)
!      Set the nowait flag on ‘GIMPLE_OMP_RETURN’ statement ‘S’.
  
   -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g)
!      Return true if ‘OMP’ return statement ‘G’ has the
!      ‘GF_OMP_RETURN_NOWAIT’ flag set.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_SECTION,  Next: GIMPLE_OMP_SECTIONS,  Prev: GIMPLE_OMP_RETURN,  Up: Tuple specific accessors
  
! 12.8.21 ‘GIMPLE_OMP_SECTION’
  ----------------------------
  
   -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body)
!      Build a ‘GIMPLE_OMP_SECTION’ statement for a sections statement.
  
!      ‘BODY’ is the sequence of statements in the section.
  
   -- GIMPLE function: bool gimple_omp_section_last_p (gimple g)
!      Return true if ‘OMP’ section statement ‘G’ has the
!      ‘GF_OMP_SECTION_LAST’ flag set.
  
   -- GIMPLE function: void gimple_omp_section_set_last (gimple g)
!      Set the ‘GF_OMP_SECTION_LAST’ flag on ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_SECTIONS,  Next: GIMPLE_OMP_SINGLE,  Prev: GIMPLE_OMP_SECTION,  Up: Tuple specific accessors
  
! 12.8.22 ‘GIMPLE_OMP_SECTIONS’
  -----------------------------
  
   -- GIMPLE function: gomp_sections *gimple_build_omp_sections (
            gimple_seq body, tree clauses)
!      Build a ‘GIMPLE_OMP_SECTIONS’ statement.  ‘BODY’ is a sequence of
!      section statements.  ‘CLAUSES’ are any of the ‘OMP’ sections
       construct's clauses: private, firstprivate, lastprivate, reduction,
       and nowait.
  
   -- GIMPLE function: gimple gimple_build_omp_sections_switch (void)
!      Build a ‘GIMPLE_OMP_SECTIONS_SWITCH’ statement.
  
   -- GIMPLE function: tree gimple_omp_sections_control (gimple g)
       Return the control variable associated with the
!      ‘GIMPLE_OMP_SECTIONS’ in ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g)
       Return a pointer to the clauses associated with the
!      ‘GIMPLE_OMP_SECTIONS’ in ‘G’.
  
   -- GIMPLE function: void gimple_omp_sections_set_control (gimple g,
            tree control)
!      Set ‘CONTROL’ to be the set of clauses associated with the
!      ‘GIMPLE_OMP_SECTIONS’ in ‘G’.
  
   -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g)
!      Return the clauses associated with ‘OMP_SECTIONS’ ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g)
!      Return a pointer to the clauses associated with ‘OMP_SECTIONS’ ‘G’.
  
   -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g,
            tree clauses)
!      Set ‘CLAUSES’ to be the set of clauses associated with
!      ‘OMP_SECTIONS’ ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_OMP_SINGLE,  Next: GIMPLE_PHI,  Prev: GIMPLE_OMP_SECTIONS,  Up: Tuple specific accessors
  
! 12.8.23 ‘GIMPLE_OMP_SINGLE’
  ---------------------------
  
   -- GIMPLE function: gomp_single *gimple_build_omp_single ( gimple_seq
            body, tree clauses)
!      Build a ‘GIMPLE_OMP_SINGLE’ statement.  ‘BODY’ is the sequence of
!      statements that will be executed once.  ‘CLAUSES’ are any of the
!      ‘OMP’ single construct's clauses: private, firstprivate,
       copyprivate, nowait.
  
   -- GIMPLE function: tree gimple_omp_single_clauses (gimple g)
!      Return the clauses associated with ‘OMP_SINGLE’ ‘G’.
  
   -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g)
!      Return a pointer to the clauses associated with ‘OMP_SINGLE’ ‘G’.
  
   -- GIMPLE function: void gimple_omp_single_set_clauses ( gomp_single
            *g, tree clauses)
!      Set ‘CLAUSES’ to be the clauses associated with ‘OMP_SINGLE’ ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_PHI,  Next: GIMPLE_RESX,  Prev: GIMPLE_OMP_SINGLE,  Up: Tuple specific accessors
  
! 12.8.24 ‘GIMPLE_PHI’
  --------------------
  
   -- GIMPLE function: unsigned gimple_phi_capacity (gimple g)
!      Return the maximum number of arguments supported by ‘GIMPLE_PHI’
!      ‘G’.
  
   -- GIMPLE function: unsigned gimple_phi_num_args (gimple g)
!      Return the number of arguments in ‘GIMPLE_PHI’ ‘G’.  This must
       always be exactly the number of incoming edges for the basic block
!      holding ‘G’.
  
   -- GIMPLE function: tree gimple_phi_result (gimple g)
!      Return the ‘SSA’ name created by ‘GIMPLE_PHI’ ‘G’.
  
   -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g)
!      Return a pointer to the ‘SSA’ name created by ‘GIMPLE_PHI’ ‘G’.
  
   -- GIMPLE function: void gimple_phi_set_result (gphi *g, tree result)
!      Set ‘RESULT’ to be the ‘SSA’ name created by ‘GIMPLE_PHI’ ‘G’.
  
   -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index)
!      Return the ‘PHI’ argument corresponding to incoming edge ‘INDEX’
!      for ‘GIMPLE_PHI’ ‘G’.
  
   -- GIMPLE function: void gimple_phi_set_arg (gphi *g, index, struct
            phi_arg_d * phiarg)
!      Set ‘PHIARG’ to be the argument corresponding to incoming edge
!      ‘INDEX’ for ‘GIMPLE_PHI’ ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_RESX,  Next: GIMPLE_RETURN,  Prev: GIMPLE_PHI,  Up: Tuple specific accessors
  
! 12.8.25 ‘GIMPLE_RESX’
  ---------------------
  
   -- GIMPLE function: gresx *gimple_build_resx (int region)
!      Build a ‘GIMPLE_RESX’ statement which is a statement.  This
       statement is a placeholder for _Unwind_Resume before we know if a
!      function call or a branch is needed.  ‘REGION’ is the exception
       region from which control is flowing.
  
   -- GIMPLE function: int gimple_resx_region (const gresx *g)
!      Return the region number for ‘GIMPLE_RESX’ ‘G’.
  
   -- GIMPLE function: void gimple_resx_set_region (gresx *g, int region)
!      Set ‘REGION’ to be the region number for ‘GIMPLE_RESX’ ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_RETURN,  Next: GIMPLE_SWITCH,  Prev: GIMPLE_RESX,  Up: Tuple specific accessors
  
! 12.8.26 ‘GIMPLE_RETURN’
  -----------------------
  
   -- GIMPLE function: greturn *gimple_build_return (tree retval)
!      Build a ‘GIMPLE_RETURN’ statement whose return value is retval.
  
   -- GIMPLE function: tree gimple_return_retval (const greturn *g)
!      Return the return value for ‘GIMPLE_RETURN’ ‘G’.
  
   -- GIMPLE function: void gimple_return_set_retval (greturn *g, tree
            retval)
!      Set ‘RETVAL’ to be the return value for ‘GIMPLE_RETURN’ ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_SWITCH,  Next: GIMPLE_TRY,  Prev: GIMPLE_RETURN,  Up: Tuple specific accessors
  
! 12.8.27 ‘GIMPLE_SWITCH’
  -----------------------
  
   -- GIMPLE function: gswitch *gimple_build_switch (tree index, tree
            default_label, vec *args)
!      Build a ‘GIMPLE_SWITCH’ statement.  ‘INDEX’ is the index variable
!      to switch on, and ‘DEFAULT_LABEL’ represents the default label.
!      ‘ARGS’ is a vector of ‘CASE_LABEL_EXPR’ trees that contain the
       non-default case labels.  Each label is a tree of code
!      ‘CASE_LABEL_EXPR’.
  
   -- GIMPLE function: unsigned gimple_switch_num_labels ( const gswitch
            *g)
       Return the number of labels associated with the switch statement
!      ‘G’.
  
   -- GIMPLE function: void gimple_switch_set_num_labels (gswitch *g,
            unsigned nlabels)
!      Set ‘NLABELS’ to be the number of labels for the switch statement
!      ‘G’.
  
   -- GIMPLE function: tree gimple_switch_index (const gswitch *g)
!      Return the index variable used by the switch statement ‘G’.
  
   -- GIMPLE function: void gimple_switch_set_index (gswitch *g, tree
            index)
!      Set ‘INDEX’ to be the index variable for switch statement ‘G’.
  
   -- GIMPLE function: tree gimple_switch_label (const gswitch *g,
            unsigned index)
!      Return the label numbered ‘INDEX’.  The default label is 0,
       followed by any labels in a switch statement.
  
   -- GIMPLE function: void gimple_switch_set_label (gswitch *g, unsigned
            index, tree label)
!      Set the label number ‘INDEX’ to ‘LABEL’.  0 is always the default
       label.
  
   -- GIMPLE function: tree gimple_switch_default_label ( const gswitch
*************** File: gccint.info,  Node: GIMPLE_SWITCH,
*** 15324,15392 ****
  
  File: gccint.info,  Node: GIMPLE_TRY,  Next: GIMPLE_WITH_CLEANUP_EXPR,  Prev: GIMPLE_SWITCH,  Up: Tuple specific accessors
  
! 12.8.28 'GIMPLE_TRY'
  --------------------
  
   -- GIMPLE function: gtry *gimple_build_try (gimple_seq eval, gimple_seq
            cleanup, unsigned int kind)
!      Build a 'GIMPLE_TRY' statement.  'EVAL' is a sequence with the
!      expression to evaluate.  'CLEANUP' is a sequence of statements to
!      run at clean-up time.  'KIND' is the enumeration value
!      'GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct
!      or 'GIMPLE_TRY_FINALLY' if this statement denotes a try/finally
       construct.
  
   -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g)
!      Return the kind of try block represented by 'GIMPLE_TRY' 'G'.  This
!      is either 'GIMPLE_TRY_CATCH' or 'GIMPLE_TRY_FINALLY'.
  
   -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g)
!      Return the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag.
  
   -- GIMPLE function: gimple_seq gimple_try_eval (gimple g)
!      Return the sequence of statements used as the body for 'GIMPLE_TRY'
!      'G'.
  
   -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g)
       Return the sequence of statements used as the cleanup body for
!      'GIMPLE_TRY' 'G'.
  
   -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g,
            bool catch_is_cleanup)
!      Set the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag.
  
   -- GIMPLE function: void gimple_try_set_eval (gtry *g, gimple_seq eval)
!      Set 'EVAL' to be the sequence of statements to use as the body for
!      'GIMPLE_TRY' 'G'.
  
   -- GIMPLE function: void gimple_try_set_cleanup (gtry *g, gimple_seq
            cleanup)
!      Set 'CLEANUP' to be the sequence of statements to use as the
!      cleanup body for 'GIMPLE_TRY' 'G'.
  
  
  File: gccint.info,  Node: GIMPLE_WITH_CLEANUP_EXPR,  Prev: GIMPLE_TRY,  Up: Tuple specific accessors
  
! 12.8.29 'GIMPLE_WITH_CLEANUP_EXPR'
  ----------------------------------
  
   -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup)
!      Build a 'GIMPLE_WITH_CLEANUP_EXPR' statement.  'CLEANUP' is the
       clean-up expression.
  
   -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g)
!      Return the cleanup sequence for cleanup statement 'G'.
  
   -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq
            cleanup)
!      Set 'CLEANUP' to be the cleanup sequence for 'G'.
  
   -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g)
!      Return the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple.
  
   -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, bool
            eh_only_p)
!      Set the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple.
  
  
  File: gccint.info,  Node: GIMPLE sequences,  Next: Sequence iterators,  Prev: Tuple specific accessors,  Up: GIMPLE
--- 15324,15392 ----
  
  File: gccint.info,  Node: GIMPLE_TRY,  Next: GIMPLE_WITH_CLEANUP_EXPR,  Prev: GIMPLE_SWITCH,  Up: Tuple specific accessors
  
! 12.8.28 ‘GIMPLE_TRY’
  --------------------
  
   -- GIMPLE function: gtry *gimple_build_try (gimple_seq eval, gimple_seq
            cleanup, unsigned int kind)
!      Build a ‘GIMPLE_TRY’ statement.  ‘EVAL’ is a sequence with the
!      expression to evaluate.  ‘CLEANUP’ is a sequence of statements to
!      run at clean-up time.  ‘KIND’ is the enumeration value
!      ‘GIMPLE_TRY_CATCH’ if this statement denotes a try/catch construct
!      or ‘GIMPLE_TRY_FINALLY’ if this statement denotes a try/finally
       construct.
  
   -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g)
!      Return the kind of try block represented by ‘GIMPLE_TRY’ ‘G’.  This
!      is either ‘GIMPLE_TRY_CATCH’ or ‘GIMPLE_TRY_FINALLY’.
  
   -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g)
!      Return the ‘GIMPLE_TRY_CATCH_IS_CLEANUP’ flag.
  
   -- GIMPLE function: gimple_seq gimple_try_eval (gimple g)
!      Return the sequence of statements used as the body for ‘GIMPLE_TRY’
!      ‘G’.
  
   -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g)
       Return the sequence of statements used as the cleanup body for
!      ‘GIMPLE_TRY’ ‘G’.
  
   -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g,
            bool catch_is_cleanup)
!      Set the ‘GIMPLE_TRY_CATCH_IS_CLEANUP’ flag.
  
   -- GIMPLE function: void gimple_try_set_eval (gtry *g, gimple_seq eval)
!      Set ‘EVAL’ to be the sequence of statements to use as the body for
!      ‘GIMPLE_TRY’ ‘G’.
  
   -- GIMPLE function: void gimple_try_set_cleanup (gtry *g, gimple_seq
            cleanup)
!      Set ‘CLEANUP’ to be the sequence of statements to use as the
!      cleanup body for ‘GIMPLE_TRY’ ‘G’.
  
  
  File: gccint.info,  Node: GIMPLE_WITH_CLEANUP_EXPR,  Prev: GIMPLE_TRY,  Up: Tuple specific accessors
  
! 12.8.29 ‘GIMPLE_WITH_CLEANUP_EXPR’
  ----------------------------------
  
   -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup)
!      Build a ‘GIMPLE_WITH_CLEANUP_EXPR’ statement.  ‘CLEANUP’ is the
       clean-up expression.
  
   -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g)
!      Return the cleanup sequence for cleanup statement ‘G’.
  
   -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq
            cleanup)
!      Set ‘CLEANUP’ to be the cleanup sequence for ‘G’.
  
   -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g)
!      Return the ‘CLEANUP_EH_ONLY’ flag for a ‘WCE’ tuple.
  
   -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, bool
            eh_only_p)
!      Set the ‘CLEANUP_EH_ONLY’ flag for a ‘WCE’ tuple.
  
  
  File: gccint.info,  Node: GIMPLE sequences,  Next: Sequence iterators,  Prev: Tuple specific accessors,  Up: GIMPLE
*************** File: gccint.info,  Node: GIMPLE sequenc
*** 15394,15411 ****
  12.9 GIMPLE sequences
  =====================
  
! GIMPLE sequences are the tuple equivalent of 'STATEMENT_LIST''s used in
! 'GENERIC'.  They are used to chain statements together, and when used in
  conjunction with sequence iterators, provide a framework for iterating
  through statements.
  
!  GIMPLE sequences are of type struct 'gimple_sequence', but are more
  commonly passed by reference to functions dealing with sequences.  The
! type for a sequence pointer is 'gimple_seq' which is the same as struct
! 'gimple_sequence' *.  When declaring a local sequence, you can define a
! local variable of type struct 'gimple_sequence'.  When declaring a
  sequence allocated on the garbage collected heap, use the function
! 'gimple_seq_alloc' documented below.
  
   There are convenience functions for iterating through sequences in the
  section entitled Sequence Iterators.
--- 15394,15411 ----
  12.9 GIMPLE sequences
  =====================
  
! GIMPLE sequences are the tuple equivalent of ‘STATEMENT_LIST’'s used in
! ‘GENERIC’.  They are used to chain statements together, and when used in
  conjunction with sequence iterators, provide a framework for iterating
  through statements.
  
!  GIMPLE sequences are of type struct ‘gimple_sequence’, but are more
  commonly passed by reference to functions dealing with sequences.  The
! type for a sequence pointer is ‘gimple_seq’ which is the same as struct
! ‘gimple_sequence’ *.  When declaring a local sequence, you can define a
! local variable of type struct ‘gimple_sequence’.  When declaring a
  sequence allocated on the garbage collected heap, use the function
! ‘gimple_seq_alloc’ documented below.
  
   There are convenience functions for iterating through sequences in the
  section entitled Sequence Iterators.
*************** section entitled Sequence Iterators.
*** 15414,15453 ****
  
   -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple
            g)
!      Link a gimple statement to the end of the sequence *'SEQ' if 'G' is
!      not 'NULL'.  If *'SEQ' is 'NULL', allocate a sequence before
       linking.
  
   -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest,
            gimple_seq src)
!      Append sequence 'SRC' to the end of sequence *'DEST' if 'SRC' is
!      not 'NULL'.  If *'DEST' is 'NULL', allocate a new sequence before
       appending.
  
   -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src)
!      Perform a deep copy of sequence 'SRC' and return the result.
  
   -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq)
!      Reverse the order of the statements in the sequence 'SEQ'.  Return
!      'SEQ'.
  
   -- GIMPLE function: gimple gimple_seq_first (gimple_seq s)
!      Return the first statement in sequence 'S'.
  
   -- GIMPLE function: gimple gimple_seq_last (gimple_seq s)
!      Return the last statement in sequence 'S'.
  
   -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple
            last)
!      Set the last statement in sequence 'S' to the statement in 'LAST'.
  
   -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple
            first)
!      Set the first statement in sequence 'S' to the statement in
!      'FIRST'.
  
   -- GIMPLE function: void gimple_seq_init (gimple_seq s)
!      Initialize sequence 'S' to an empty sequence.
  
   -- GIMPLE function: gimple_seq gimple_seq_alloc (void)
       Allocate a new sequence in the garbage collected store and return
--- 15414,15453 ----
  
   -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple
            g)
!      Link a gimple statement to the end of the sequence *‘SEQ’ if ‘G’ is
!      not ‘NULL’.  If *‘SEQ’ is ‘NULL’, allocate a sequence before
       linking.
  
   -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest,
            gimple_seq src)
!      Append sequence ‘SRC’ to the end of sequence *‘DEST’ if ‘SRC’ is
!      not ‘NULL’.  If *‘DEST’ is ‘NULL’, allocate a new sequence before
       appending.
  
   -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src)
!      Perform a deep copy of sequence ‘SRC’ and return the result.
  
   -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq)
!      Reverse the order of the statements in the sequence ‘SEQ’.  Return
!      ‘SEQ’.
  
   -- GIMPLE function: gimple gimple_seq_first (gimple_seq s)
!      Return the first statement in sequence ‘S’.
  
   -- GIMPLE function: gimple gimple_seq_last (gimple_seq s)
!      Return the last statement in sequence ‘S’.
  
   -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple
            last)
!      Set the last statement in sequence ‘S’ to the statement in ‘LAST’.
  
   -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple
            first)
!      Set the first statement in sequence ‘S’ to the statement in
!      ‘FIRST’.
  
   -- GIMPLE function: void gimple_seq_init (gimple_seq s)
!      Initialize sequence ‘S’ to an empty sequence.
  
   -- GIMPLE function: gimple_seq gimple_seq_alloc (void)
       Allocate a new sequence in the garbage collected store and return
*************** section entitled Sequence Iterators.
*** 15455,15473 ****
  
   -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq
            src)
!      Copy the sequence 'SRC' into the sequence 'DEST'.
  
   -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s)
!      Return true if the sequence 'S' is empty.
  
   -- GIMPLE function: gimple_seq bb_seq (basic_block bb)
!      Returns the sequence of statements in 'BB'.
  
   -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq)
!      Sets the sequence of statements in 'BB' to 'SEQ'.
  
   -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq)
!      Determine whether 'SEQ' contains exactly one statement.
  
  
  File: gccint.info,  Node: Sequence iterators,  Next: Adding a new GIMPLE statement code,  Prev: GIMPLE sequences,  Up: GIMPLE
--- 15455,15473 ----
  
   -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq
            src)
!      Copy the sequence ‘SRC’ into the sequence ‘DEST’.
  
   -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s)
!      Return true if the sequence ‘S’ is empty.
  
   -- GIMPLE function: gimple_seq bb_seq (basic_block bb)
!      Returns the sequence of statements in ‘BB’.
  
   -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq)
!      Sets the sequence of statements in ‘BB’ to ‘SEQ’.
  
   -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq)
!      Determine whether ‘SEQ’ contains exactly one statement.
  
  
  File: gccint.info,  Node: Sequence iterators,  Next: Adding a new GIMPLE statement code,  Prev: GIMPLE sequences,  Up: GIMPLE
*************** File: gccint.info,  Node: Sequence itera
*** 15476,15482 ****
  ========================
  
  Sequence iterators are convenience constructs for iterating through
! statements in a sequence.  Given a sequence 'SEQ', here is a typical use
  of gimple sequence iterators:
  
       gimple_stmt_iterator gsi;
--- 15476,15482 ----
  ========================
  
  Sequence iterators are convenience constructs for iterating through
! statements in a sequence.  Given a sequence ‘SEQ’, here is a typical use
  of gimple sequence iterators:
  
       gimple_stmt_iterator gsi;
*************** of gimple sequence iterators:
*** 15492,15538 ****
               for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi))
  
   Forward and backward iterations on basic blocks are possible with
! 'gsi_start_bb' and 'gsi_last_bb'.
  
   In the documentation below we sometimes refer to enum
! 'gsi_iterator_update'.  The valid options for this enumeration are:
  
!    * 'GSI_NEW_STMT' Only valid when a single statement is added.  Move
       the iterator to it.
  
!    * 'GSI_SAME_STMT' Leave the iterator at the same statement.
  
!    * 'GSI_CONTINUE_LINKING' Move iterator to whatever position is
       suitable for linking other statements in the same direction.
  
   Below is a list of the functions used to manipulate and use statement
  iterators.
  
   -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq)
!      Return a new iterator pointing to the sequence 'SEQ''s first
!      statement.  If 'SEQ' is empty, the iterator's basic block is
!      'NULL'.  Use 'gsi_start_bb' instead when the iterator needs to
       always have the correct basic block set.
  
   -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb)
       Return a new iterator pointing to the first statement in basic
!      block 'BB'.
  
   -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq)
       Return a new iterator initially pointing to the last statement of
!      sequence 'SEQ'.  If 'SEQ' is empty, the iterator's basic block is
!      'NULL'.  Use 'gsi_last_bb' instead when the iterator needs to
       always have the correct basic block set.
  
   -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb)
       Return a new iterator pointing to the last statement in basic block
!      'BB'.
  
   -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i)
!      Return 'TRUE' if at the end of 'I'.
  
   -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i)
!      Return 'TRUE' if we're one statement before the end of 'I'.
  
   -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i)
       Advance the iterator to the next gimple statement.
--- 15492,15538 ----
               for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi))
  
   Forward and backward iterations on basic blocks are possible with
! ‘gsi_start_bb’ and ‘gsi_last_bb’.
  
   In the documentation below we sometimes refer to enum
! ‘gsi_iterator_update’.  The valid options for this enumeration are:
  
!    • ‘GSI_NEW_STMT’ Only valid when a single statement is added.  Move
       the iterator to it.
  
!    • ‘GSI_SAME_STMT’ Leave the iterator at the same statement.
  
!    • ‘GSI_CONTINUE_LINKING’ Move iterator to whatever position is
       suitable for linking other statements in the same direction.
  
   Below is a list of the functions used to manipulate and use statement
  iterators.
  
   -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq)
!      Return a new iterator pointing to the sequence ‘SEQ’'s first
!      statement.  If ‘SEQ’ is empty, the iterator's basic block is
!      ‘NULL’.  Use ‘gsi_start_bb’ instead when the iterator needs to
       always have the correct basic block set.
  
   -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb)
       Return a new iterator pointing to the first statement in basic
!      block ‘BB’.
  
   -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq)
       Return a new iterator initially pointing to the last statement of
!      sequence ‘SEQ’.  If ‘SEQ’ is empty, the iterator's basic block is
!      ‘NULL’.  Use ‘gsi_last_bb’ instead when the iterator needs to
       always have the correct basic block set.
  
   -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb)
       Return a new iterator pointing to the last statement in basic block
!      ‘BB’.
  
   -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i)
!      Return ‘TRUE’ if at the end of ‘I’.
  
   -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i)
!      Return ‘TRUE’ if we're one statement before the end of ‘I’.
  
   -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i)
       Advance the iterator to the next gimple statement.
*************** iterators.
*** 15546,15552 ****
   -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block
            bb)
       Return a block statement iterator that points to the first
!      non-label statement in block 'BB'.
  
   -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i)
       Return a pointer to the current stmt.
--- 15546,15552 ----
   -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block
            bb)
       Return a block statement iterator that points to the first
!      non-label statement in block ‘BB’.
  
   -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i)
       Return a pointer to the current stmt.
*************** iterators.
*** 15560,15666 ****
   -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool
            remove_eh_info)
       Remove the current stmt from the sequence.  The iterator is updated
!      to point to the next statement.  When 'REMOVE_EH_INFO' is true we
!      remove the statement pointed to by iterator 'I' from the 'EH'
!      tables.  Otherwise we do not modify the 'EH' tables.  Generally,
!      'REMOVE_EH_INFO' should be true when the statement is going to be
!      removed from the 'IL' and not reinserted elsewhere.
  
   -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i,
            gimple_seq seq, enum gsi_iterator_update mode)
!      Links the sequence of statements 'SEQ' before the statement pointed
!      by iterator 'I'.  'MODE' indicates what to do with the iterator
!      after insertion (see 'enum gsi_iterator_update' above).
  
   -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i,
            gimple g, enum gsi_iterator_update mode)
!      Links statement 'G' before the statement pointed-to by iterator
!      'I'.  Updates iterator 'I' according to 'MODE'.
  
   -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i,
            gimple_seq seq, enum gsi_iterator_update mode)
!      Links sequence 'SEQ' after the statement pointed-to by iterator
!      'I'.  'MODE' is as in 'gsi_insert_after'.
  
   -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i,
            gimple g, enum gsi_iterator_update mode)
!      Links statement 'G' after the statement pointed-to by iterator 'I'.
!      'MODE' is as in 'gsi_insert_after'.
  
   -- GIMPLE function: gimple_seq gsi_split_seq_after
            (gimple_stmt_iterator i)
!      Move all statements in the sequence after 'I' to a new sequence.
       Return this new sequence.
  
   -- GIMPLE function: gimple_seq gsi_split_seq_before
            (gimple_stmt_iterator *i)
!      Move all statements in the sequence before 'I' to a new sequence.
       Return this new sequence.
  
   -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple
            stmt, bool update_eh_info)
!      Replace the statement pointed-to by 'I' to 'STMT'.  If
!      'UPDATE_EH_INFO' is true, the exception handling information of the
       original statement is moved to the new statement.
  
   -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i,
            gimple stmt, enum gsi_iterator_update mode)
!      Insert statement 'STMT' before the statement pointed-to by iterator
!      'I', update 'STMT''s basic block and scan it for new operands.
!      'MODE' specifies how to update iterator 'I' after insertion (see
!      enum 'gsi_iterator_update').
  
   -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator
            *i, gimple_seq seq, enum gsi_iterator_update mode)
!      Like 'gsi_insert_before', but for all the statements in 'SEQ'.
  
   -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i,
            gimple stmt, enum gsi_iterator_update mode)
!      Insert statement 'STMT' after the statement pointed-to by iterator
!      'I', update 'STMT''s basic block and scan it for new operands.
!      'MODE' specifies how to update iterator 'I' after insertion (see
!      enum 'gsi_iterator_update').
  
   -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator *i,
            gimple_seq seq, enum gsi_iterator_update mode)
!      Like 'gsi_insert_after', but for all the statements in 'SEQ'.
  
   -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt)
!      Finds iterator for 'STMT'.
  
   -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from,
            gimple_stmt_iterator *to)
!      Move the statement at 'FROM' so it comes right after the statement
!      at 'TO'.
  
   -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from,
            gimple_stmt_iterator *to)
!      Move the statement at 'FROM' so it comes right before the statement
!      at 'TO'.
  
   -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator
            *from, basic_block bb)
!      Move the statement at 'FROM' to the end of basic block 'BB'.
  
   -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt)
!      Add 'STMT' to the pending list of edge 'E'.  No actual insertion is
!      made until a call to 'gsi_commit_edge_inserts'() is made.
  
   -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq
            seq)
!      Add the sequence of statements in 'SEQ' to the pending list of edge
!      'E'.  No actual insertion is made until a call to
!      'gsi_commit_edge_inserts'() is made.
  
   -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e,
            gimple stmt)
!      Similar to 'gsi_insert_on_edge'+'gsi_commit_edge_inserts'.  If a
       new block has to be created, it is returned.
  
   -- GIMPLE function: void gsi_commit_one_edge_insert (edge e,
            basic_block *new_bb)
!      Commit insertions pending at edge 'E'.  If a new block is created,
!      set 'NEW_BB' to this block, otherwise set it to 'NULL'.
  
   -- GIMPLE function: void gsi_commit_edge_inserts (void)
       This routine will commit all pending edge insertions, creating any
--- 15560,15666 ----
   -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool
            remove_eh_info)
       Remove the current stmt from the sequence.  The iterator is updated
!      to point to the next statement.  When ‘REMOVE_EH_INFO’ is true we
!      remove the statement pointed to by iterator ‘I’ from the ‘EH’
!      tables.  Otherwise we do not modify the ‘EH’ tables.  Generally,
!      ‘REMOVE_EH_INFO’ should be true when the statement is going to be
!      removed from the ‘IL’ and not reinserted elsewhere.
  
   -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i,
            gimple_seq seq, enum gsi_iterator_update mode)
!      Links the sequence of statements ‘SEQ’ before the statement pointed
!      by iterator ‘I’.  ‘MODE’ indicates what to do with the iterator
!      after insertion (see ‘enum gsi_iterator_update’ above).
  
   -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i,
            gimple g, enum gsi_iterator_update mode)
!      Links statement ‘G’ before the statement pointed-to by iterator
!      ‘I’.  Updates iterator ‘I’ according to ‘MODE’.
  
   -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i,
            gimple_seq seq, enum gsi_iterator_update mode)
!      Links sequence ‘SEQ’ after the statement pointed-to by iterator
!      ‘I’.  ‘MODE’ is as in ‘gsi_insert_after’.
  
   -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i,
            gimple g, enum gsi_iterator_update mode)
!      Links statement ‘G’ after the statement pointed-to by iterator ‘I’.
!      ‘MODE’ is as in ‘gsi_insert_after’.
  
   -- GIMPLE function: gimple_seq gsi_split_seq_after
            (gimple_stmt_iterator i)
!      Move all statements in the sequence after ‘I’ to a new sequence.
       Return this new sequence.
  
   -- GIMPLE function: gimple_seq gsi_split_seq_before
            (gimple_stmt_iterator *i)
!      Move all statements in the sequence before ‘I’ to a new sequence.
       Return this new sequence.
  
   -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple
            stmt, bool update_eh_info)
!      Replace the statement pointed-to by ‘I’ to ‘STMT’.  If
!      ‘UPDATE_EH_INFO’ is true, the exception handling information of the
       original statement is moved to the new statement.
  
   -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i,
            gimple stmt, enum gsi_iterator_update mode)
!      Insert statement ‘STMT’ before the statement pointed-to by iterator
!      ‘I’, update ‘STMT’'s basic block and scan it for new operands.
!      ‘MODE’ specifies how to update iterator ‘I’ after insertion (see
!      enum ‘gsi_iterator_update’).
  
   -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator
            *i, gimple_seq seq, enum gsi_iterator_update mode)
!      Like ‘gsi_insert_before’, but for all the statements in ‘SEQ’.
  
   -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i,
            gimple stmt, enum gsi_iterator_update mode)
!      Insert statement ‘STMT’ after the statement pointed-to by iterator
!      ‘I’, update ‘STMT’'s basic block and scan it for new operands.
!      ‘MODE’ specifies how to update iterator ‘I’ after insertion (see
!      enum ‘gsi_iterator_update’).
  
   -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator *i,
            gimple_seq seq, enum gsi_iterator_update mode)
!      Like ‘gsi_insert_after’, but for all the statements in ‘SEQ’.
  
   -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt)
!      Finds iterator for ‘STMT’.
  
   -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from,
            gimple_stmt_iterator *to)
!      Move the statement at ‘FROM’ so it comes right after the statement
!      at ‘TO’.
  
   -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from,
            gimple_stmt_iterator *to)
!      Move the statement at ‘FROM’ so it comes right before the statement
!      at ‘TO’.
  
   -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator
            *from, basic_block bb)
!      Move the statement at ‘FROM’ to the end of basic block ‘BB’.
  
   -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt)
!      Add ‘STMT’ to the pending list of edge ‘E’.  No actual insertion is
!      made until a call to ‘gsi_commit_edge_inserts’() is made.
  
   -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq
            seq)
!      Add the sequence of statements in ‘SEQ’ to the pending list of edge
!      ‘E’.  No actual insertion is made until a call to
!      ‘gsi_commit_edge_inserts’() is made.
  
   -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e,
            gimple stmt)
!      Similar to ‘gsi_insert_on_edge’+‘gsi_commit_edge_inserts’.  If a
       new block has to be created, it is returned.
  
   -- GIMPLE function: void gsi_commit_one_edge_insert (edge e,
            basic_block *new_bb)
!      Commit insertions pending at edge ‘E’.  If a new block is created,
!      set ‘NEW_BB’ to this block, otherwise set it to ‘NULL’.
  
   -- GIMPLE function: void gsi_commit_edge_inserts (void)
       This routine will commit all pending edge insertions, creating any
*************** File: gccint.info,  Node: Adding a new G
*** 15673,15699 ****
  ========================================
  
  The first step in adding a new GIMPLE statement code, is modifying the
! file 'gimple.def', which contains all the GIMPLE codes.  Then you must
! add a corresponding gimple subclass located in 'gimple.h'.  This in
! turn, will require you to add a corresponding 'GTY' tag in
! 'gsstruct.def', and code to handle this tag in 'gss_for_code' which is
! located in 'gimple.cc'.
  
   In order for the garbage collector to know the size of the structure
! you created in 'gimple.h', you need to add a case to handle your new
! GIMPLE statement in 'gimple_size' which is located in 'gimple.cc'.
  
   You will probably want to create a function to build the new gimple
! statement in 'gimple.cc'.  The function should be called
! 'gimple_build_NEW-TUPLE-NAME', and should return the new tuple as a
  pointer to the appropriate gimple subclass.
  
   If your new statement requires accessors for any members or operands it
! may have, put simple inline accessors in 'gimple.h' and any non-trivial
! accessors in 'gimple.cc' with a corresponding prototype in 'gimple.h'.
  
   You should add the new statement subclass to the class hierarchy
! diagram in 'gimple.texi'.
  
  
  File: gccint.info,  Node: Statement and operand traversals,  Prev: Adding a new GIMPLE statement code,  Up: GIMPLE
--- 15673,15699 ----
  ========================================
  
  The first step in adding a new GIMPLE statement code, is modifying the
! file ‘gimple.def’, which contains all the GIMPLE codes.  Then you must
! add a corresponding gimple subclass located in ‘gimple.h’.  This in
! turn, will require you to add a corresponding ‘GTY’ tag in
! ‘gsstruct.def’, and code to handle this tag in ‘gss_for_code’ which is
! located in ‘gimple.cc’.
  
   In order for the garbage collector to know the size of the structure
! you created in ‘gimple.h’, you need to add a case to handle your new
! GIMPLE statement in ‘gimple_size’ which is located in ‘gimple.cc’.
  
   You will probably want to create a function to build the new gimple
! statement in ‘gimple.cc’.  The function should be called
! ‘gimple_build_NEW-TUPLE-NAME’, and should return the new tuple as a
  pointer to the appropriate gimple subclass.
  
   If your new statement requires accessors for any members or operands it
! may have, put simple inline accessors in ‘gimple.h’ and any non-trivial
! accessors in ‘gimple.cc’ with a corresponding prototype in ‘gimple.h’.
  
   You should add the new statement subclass to the class hierarchy
! diagram in ‘gimple.texi’.
  
  
  File: gccint.info,  Node: Statement and operand traversals,  Prev: Adding a new GIMPLE statement code,  Up: GIMPLE
*************** File: gccint.info,  Node: Statement and
*** 15702,15755 ****
  ======================================
  
  There are two functions available for walking statements and sequences:
! 'walk_gimple_stmt' and 'walk_gimple_seq', accordingly, and a third
! function for walking the operands in a statement: 'walk_gimple_op'.
  
   -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi,
            walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct
            walk_stmt_info *wi)
!      This function is used to walk the current statement in 'GSI',
!      optionally using traversal state stored in 'WI'.  If 'WI' is
!      'NULL', no state is kept during the traversal.
  
!      The callback 'CALLBACK_STMT' is called.  If 'CALLBACK_STMT' returns
       true, it means that the callback function has handled all the
       operands of the statement and it is not necessary to walk its
       operands.
  
!      If 'CALLBACK_STMT' is 'NULL' or it returns false, 'CALLBACK_OP' is
!      called on each operand of the statement via 'walk_gimple_op'.  If
!      'walk_gimple_op' returns non-'NULL' for any operand, the remaining
       operands are not scanned.
  
       The return value is that returned by the last call to
!      'walk_gimple_op', or 'NULL_TREE' if no 'CALLBACK_OP' is specified.
  
   -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn
            callback_op, struct walk_stmt_info *wi)
!      Use this function to walk the operands of statement 'STMT'.  Every
!      operand is walked via 'walk_tree' with optional state information
!      in 'WI'.
  
!      'CALLBACK_OP' is called on each operand of 'STMT' via 'walk_tree'.
!      Additional parameters to 'walk_tree' must be stored in 'WI'.  For
!      each operand 'OP', 'walk_tree' is called as:
  
            walk_tree (&OP, CALLBACK_OP, WI, PSET)
  
!      If 'CALLBACK_OP' returns non-'NULL' for an operand, the remaining
       operands are not scanned.  The return value is that returned by the
!      last call to 'walk_tree', or 'NULL_TREE' if no 'CALLBACK_OP' is
       specified.
  
   -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn
            callback_stmt, walk_tree_fn callback_op, struct walk_stmt_info
            *wi)
!      This function walks all the statements in the sequence 'SEQ'
!      calling 'walk_gimple_stmt' on each one.  'WI' is as in
!      'walk_gimple_stmt'.  If 'walk_gimple_stmt' returns non-'NULL', the
       walk is stopped and the value returned.  Otherwise, all the
!      statements are walked and 'NULL_TREE' returned.
  
  
  File: gccint.info,  Node: Tree SSA,  Next: RTL,  Prev: GIMPLE,  Up: Top
--- 15702,15755 ----
  ======================================
  
  There are two functions available for walking statements and sequences:
! ‘walk_gimple_stmt’ and ‘walk_gimple_seq’, accordingly, and a third
! function for walking the operands in a statement: ‘walk_gimple_op’.
  
   -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi,
            walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct
            walk_stmt_info *wi)
!      This function is used to walk the current statement in ‘GSI’,
!      optionally using traversal state stored in ‘WI’.  If ‘WI’ is
!      ‘NULL’, no state is kept during the traversal.
  
!      The callback ‘CALLBACK_STMT’ is called.  If ‘CALLBACK_STMT’ returns
       true, it means that the callback function has handled all the
       operands of the statement and it is not necessary to walk its
       operands.
  
!      If ‘CALLBACK_STMT’ is ‘NULL’ or it returns false, ‘CALLBACK_OP’ is
!      called on each operand of the statement via ‘walk_gimple_op’.  If
!      ‘walk_gimple_op’ returns non-‘NULL’ for any operand, the remaining
       operands are not scanned.
  
       The return value is that returned by the last call to
!      ‘walk_gimple_op’, or ‘NULL_TREE’ if no ‘CALLBACK_OP’ is specified.
  
   -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn
            callback_op, struct walk_stmt_info *wi)
!      Use this function to walk the operands of statement ‘STMT’.  Every
!      operand is walked via ‘walk_tree’ with optional state information
!      in ‘WI’.
  
!      ‘CALLBACK_OP’ is called on each operand of ‘STMT’ via ‘walk_tree’.
!      Additional parameters to ‘walk_tree’ must be stored in ‘WI’.  For
!      each operand ‘OP’, ‘walk_tree’ is called as:
  
            walk_tree (&OP, CALLBACK_OP, WI, PSET)
  
!      If ‘CALLBACK_OP’ returns non-‘NULL’ for an operand, the remaining
       operands are not scanned.  The return value is that returned by the
!      last call to ‘walk_tree’, or ‘NULL_TREE’ if no ‘CALLBACK_OP’ is
       specified.
  
   -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn
            callback_stmt, walk_tree_fn callback_op, struct walk_stmt_info
            *wi)
!      This function walks all the statements in the sequence ‘SEQ’
!      calling ‘walk_gimple_stmt’ on each one.  ‘WI’ is as in
!      ‘walk_gimple_stmt’.  If ‘walk_gimple_stmt’ returns non-‘NULL’, the
       walk is stopped and the value returned.  Otherwise, all the
!      statements are walked and ‘NULL_TREE’ returned.
  
  
  File: gccint.info,  Node: Tree SSA,  Next: RTL,  Prev: GIMPLE,  Up: Top
*************** File: gccint.info,  Node: Annotations,
*** 15798,15805 ****
  The optimizers need to associate attributes with variables during the
  optimization process.  For instance, we need to know whether a variable
  has aliases.  All these attributes are stored in data structures called
! annotations which are then linked to the field 'ann' in 'struct
! tree_common'.
  
  
  File: gccint.info,  Node: SSA Operands,  Next: SSA,  Prev: Annotations,  Up: Tree SSA
--- 15798,15805 ----
  The optimizers need to associate attributes with variables during the
  optimization process.  For instance, we need to know whether a variable
  has aliases.  All these attributes are stored in data structures called
! annotations which are then linked to the field ‘ann’ in ‘struct
! tree_common’.
  
  
  File: gccint.info,  Node: SSA Operands,  Next: SSA,  Prev: Annotations,  Up: Tree SSA
*************** their operands are going to be located a
*** 15813,15825 ****
  statement's tree.  To facilitate access to the statement's operands,
  they are organized into lists associated inside each statement's
  annotation.  Each element in an operand list is a pointer to a
! 'VAR_DECL', 'PARM_DECL' or 'SSA_NAME' tree node.  This provides a very
  convenient way of examining and replacing operands.
  
   Data flow analysis and optimization is done on all tree nodes
! representing variables.  Any node for which 'SSA_VAR_P' returns nonzero
  is considered when scanning statement operands.  However, not all
! 'SSA_VAR_P' variables are processed in the same way.  For the purposes
  of optimization, we need to distinguish between references to local
  scalar variables and references to globals, statics, structures, arrays,
  aliased variables, etc.  The reason is simple, the compiler can gather
--- 15813,15825 ----
  statement's tree.  To facilitate access to the statement's operands,
  they are organized into lists associated inside each statement's
  annotation.  Each element in an operand list is a pointer to a
! ‘VAR_DECL’, ‘PARM_DECL’ or ‘SSA_NAME’ tree node.  This provides a very
  convenient way of examining and replacing operands.
  
   Data flow analysis and optimization is done on all tree nodes
! representing variables.  Any node for which ‘SSA_VAR_P’ returns nonzero
  is considered when scanning statement operands.  However, not all
! ‘SSA_VAR_P’ variables are processed in the same way.  For the purposes
  of optimization, we need to distinguish between references to local
  scalar variables and references to globals, statics, structures, arrays,
  aliased variables, etc.  The reason is simple, the compiler can gather
*************** global variable may be modified by a fun
*** 15828,15835 ****
  possible to keep track of all the elements of an array or the fields of
  a structure, etc.
  
!  The operand scanner gathers two kinds of operands: "real" and
! "virtual".  An operand for which 'is_gimple_reg' returns true is
  considered real, otherwise it is a virtual operand.  We also distinguish
  between uses and definitions.  An operand is used if its value is loaded
  by the statement (e.g., the operand at the RHS of an assignment).  If
--- 15828,15835 ----
  possible to keep track of all the elements of an array or the fields of
  a structure, etc.
  
!  The operand scanner gathers two kinds of operands: “real” and
! “virtual”.  An operand for which ‘is_gimple_reg’ returns true is
  considered real, otherwise it is a virtual operand.  We also distinguish
  between uses and definitions.  An operand is used if its value is loaded
  by the statement (e.g., the operand at the RHS of an assignment).  If
*************** that they represent.  For instance, give
*** 15845,15854 ****
         a = b
       }
  
!  Since 'a' and 'b' are non-aliased locals, the statement 'a = b' will
! have one real definition and one real use because variable 'a' is
! completely modified with the contents of variable 'b'.  Real definition
! are also known as "killing definitions".  Similarly, the use of 'b'
  reads all its bits.
  
   In contrast, virtual operands are used with variables that can have a
--- 15845,15854 ----
         a = b
       }
  
!  Since ‘a’ and ‘b’ are non-aliased locals, the statement ‘a = b’ will
! have one real definition and one real use because variable ‘a’ is
! completely modified with the contents of variable ‘b’.  Real definition
! are also known as “killing definitions”.  Similarly, the use of ‘b’
  reads all its bits.
  
   In contrast, virtual operands are used with variables that can have a
*************** partial or ambiguous reference.  This in
*** 15856,15866 ****
  globals, and aliased variables.  In these cases, we have two types of
  definitions.  For globals, structures, and arrays, we can determine from
  a statement whether a variable of these types has a killing definition.
! If the variable does, then the statement is marked as having a "must
! definition" of that variable.  However, if a statement is only defining
  a part of the variable (i.e. a field in a structure), or if we know that
  a statement might define the variable but we cannot say for sure, then
! we mark that statement as having a "may definition".  For instance,
  given
  
       {
--- 15856,15866 ----
  globals, and aliased variables.  In these cases, we have two types of
  definitions.  For globals, structures, and arrays, we can determine from
  a statement whether a variable of these types has a killing definition.
! If the variable does, then the statement is marked as having a “must
! definition” of that variable.  However, if a statement is only defining
  a part of the variable (i.e. a field in a structure), or if we know that
  a statement might define the variable but we cannot say for sure, then
! we mark that statement as having a “may definition”.  For instance,
  given
  
       {
*************** given
*** 15874,15886 ****
         return *p;
       }
  
!  The assignment '*p = 5' may be a definition of 'a' or 'b'.  If we
! cannot determine statically where 'p' is pointing to at the time of the
  store operation, we create virtual definitions to mark that statement as
! a potential definition site for 'a' and 'b'.  Memory loads are similarly
  marked with virtual use operands.  Virtual operands are shown in tree
  dumps right before the statement that contains them.  To request a tree
! dump with virtual operands, use the '-vops' option to '-fdump-tree':
  
       {
         int a, b, *p;
--- 15874,15886 ----
         return *p;
       }
  
!  The assignment ‘*p = 5’ may be a definition of ‘a’ or ‘b’.  If we
! cannot determine statically where ‘p’ is pointing to at the time of the
  store operation, we create virtual definitions to mark that statement as
! a potential definition site for ‘a’ and ‘b’.  Memory loads are similarly
  marked with virtual use operands.  Virtual operands are shown in tree
  dumps right before the statement that contains them.  To request a tree
! dump with virtual operands, use the ‘-vops’ option to ‘-fdump-tree’:
  
       {
         int a, b, *p;
*************** dump with virtual operands, use the '-vo
*** 15898,15951 ****
         return *p;
       }
  
!  Notice that 'VDEF' operands have two copies of the referenced variable.
  This indicates that this is not a killing definition of that variable.
! In this case we refer to it as a "may definition" or "aliased store".
! The presence of the second copy of the variable in the 'VDEF' operand
  will become important when the function is converted into SSA form.
  This will be used to link all the non-killing definitions to prevent
  optimizations from making incorrect assumptions about them.
  
   Operands are updated as soon as the statement is finished via a call to
! 'update_stmt'.  If statement elements are changed via 'SET_USE' or
! 'SET_DEF', then no further action is required (i.e., those macros take
  care of updating the statement).  If changes are made by manipulating
! the statement's tree directly, then a call must be made to 'update_stmt'
! when complete.  Calling one of the 'bsi_insert' routines or
! 'bsi_replace' performs an implicit call to 'update_stmt'.
  
  13.2.1 Operand Iterators And Access Routines
  --------------------------------------------
  
! Operands are collected by 'tree-ssa-operands.cc'.  They are stored
  inside each statement's annotation and can be accessed through either
  the operand iterators or an access routine.
  
   The following access routines are available for examining operands:
  
!   1. 'SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return
       NULL unless there is exactly one operand matching the specified
       flags.  If there is exactly one operand, the operand is returned as
!      either a 'tree', 'def_operand_p', or 'use_operand_p'.
  
            tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags);
            use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES);
            def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS);
  
!   2. 'ZERO_SSA_OPERANDS': This macro returns true if there are no
       operands matching the specified flags.
  
            if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS))
              return;
  
!   3. 'NUM_SSA_OPERANDS': This macro Returns the number of operands
       matching 'flags'.  This actually executes a loop to perform the
       count, so only use this if it is really needed.
  
            int count = NUM_SSA_OPERANDS (stmt, flags)
  
   If you wish to iterate over some or all operands, use the
! 'FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator.  For example, to print
  all the operands for a statement:
  
       void
--- 15898,15951 ----
         return *p;
       }
  
!  Notice that ‘VDEF’ operands have two copies of the referenced variable.
  This indicates that this is not a killing definition of that variable.
! In this case we refer to it as a “may definition” or “aliased store”.
! The presence of the second copy of the variable in the ‘VDEF’ operand
  will become important when the function is converted into SSA form.
  This will be used to link all the non-killing definitions to prevent
  optimizations from making incorrect assumptions about them.
  
   Operands are updated as soon as the statement is finished via a call to
! ‘update_stmt’.  If statement elements are changed via ‘SET_USE’ or
! ‘SET_DEF’, then no further action is required (i.e., those macros take
  care of updating the statement).  If changes are made by manipulating
! the statement's tree directly, then a call must be made to ‘update_stmt’
! when complete.  Calling one of the ‘bsi_insert’ routines or
! ‘bsi_replace’ performs an implicit call to ‘update_stmt’.
  
  13.2.1 Operand Iterators And Access Routines
  --------------------------------------------
  
! Operands are collected by ‘tree-ssa-operands.cc’.  They are stored
  inside each statement's annotation and can be accessed through either
  the operand iterators or an access routine.
  
   The following access routines are available for examining operands:
  
!   1. ‘SINGLE_SSA_{USE,DEF,TREE}_OPERAND’: These accessors will return
       NULL unless there is exactly one operand matching the specified
       flags.  If there is exactly one operand, the operand is returned as
!      either a ‘tree’, ‘def_operand_p’, or ‘use_operand_p’.
  
            tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags);
            use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES);
            def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS);
  
!   2. ‘ZERO_SSA_OPERANDS’: This macro returns true if there are no
       operands matching the specified flags.
  
            if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS))
              return;
  
!   3. ‘NUM_SSA_OPERANDS’: This macro Returns the number of operands
       matching 'flags'.  This actually executes a loop to perform the
       count, so only use this if it is really needed.
  
            int count = NUM_SSA_OPERANDS (stmt, flags)
  
   If you wish to iterate over some or all operands, use the
! ‘FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND’ iterator.  For example, to print
  all the operands for a statement:
  
       void
*************** all the operands for a statement:
*** 15975,15981 ****
  
    3. Determine which operands you wish to use, and specify the flags of
       those you are interested in.  They are documented in
!      'tree-ssa-operands.h':
  
            #define SSA_OP_USE              0x01    /* Real USE operands.  */
            #define SSA_OP_DEF              0x02    /* Real DEF operands.  */
--- 15975,15981 ----
  
    3. Determine which operands you wish to use, and specify the flags of
       those you are interested in.  They are documented in
!      ‘tree-ssa-operands.h’:
  
            #define SSA_OP_USE              0x01    /* Real USE operands.  */
            #define SSA_OP_DEF              0x02    /* Real DEF operands.  */
*************** all the operands for a statement:
*** 15990,15996 ****
            #define SSA_OP_ALL_DEFS		(SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF)
            #define SSA_OP_ALL_OPERANDS	(SSA_OP_ALL_USES | SSA_OP_ALL_DEFS)
  
!  So if you want to look at the use pointers for all the 'USE' and 'VUSE'
  operands, you would do something like:
  
         use_operand_p use_p;
--- 15990,15996 ----
            #define SSA_OP_ALL_DEFS		(SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF)
            #define SSA_OP_ALL_OPERANDS	(SSA_OP_ALL_USES | SSA_OP_ALL_DEFS)
  
!  So if you want to look at the use pointers for all the ‘USE’ and ‘VUSE’
  operands, you would do something like:
  
         use_operand_p use_p;
*************** operands, you would do something like:
*** 16001,16009 ****
             process_use_ptr (use_p);
           }
  
!  The 'TREE' macro is basically the same as the 'USE' and 'DEF' macros,
! only with the use or def dereferenced via 'USE_FROM_PTR (use_p)' and
! 'DEF_FROM_PTR (def_p)'.  Since we aren't using operand pointers, use and
  defs flags can be mixed.
  
         tree var;
--- 16001,16009 ----
             process_use_ptr (use_p);
           }
  
!  The ‘TREE’ macro is basically the same as the ‘USE’ and ‘DEF’ macros,
! only with the use or def dereferenced via ‘USE_FROM_PTR (use_p)’ and
! ‘DEF_FROM_PTR (def_p)’.  Since we aren't using operand pointers, use and
  defs flags can be mixed.
  
         tree var;
*************** defs flags can be mixed.
*** 16014,16030 ****
              print_generic_expr (stderr, var, TDF_SLIM);
           }
  
!  'VDEF's are broken into two flags, one for the 'DEF' portion
! ('SSA_OP_VDEF') and one for the USE portion ('SSA_OP_VUSE').
  
   There are many examples in the code, in addition to the documentation
! in 'tree-ssa-operands.h' and 'ssa-iterators.h'.
  
   There are also a couple of variants on the stmt iterators regarding PHI
  nodes.
  
!  'FOR_EACH_PHI_ARG' Works exactly like 'FOR_EACH_SSA_USE_OPERAND',
! except it works over 'PHI' arguments instead of statement operands.
  
       /* Look at every virtual PHI use.  */
       FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES)
--- 16014,16030 ----
              print_generic_expr (stderr, var, TDF_SLIM);
           }
  
!  ‘VDEF’s are broken into two flags, one for the ‘DEF’ portion
! (‘SSA_OP_VDEF’) and one for the USE portion (‘SSA_OP_VUSE’).
  
   There are many examples in the code, in addition to the documentation
! in ‘tree-ssa-operands.h’ and ‘ssa-iterators.h’.
  
   There are also a couple of variants on the stmt iterators regarding PHI
  nodes.
  
!  ‘FOR_EACH_PHI_ARG’ Works exactly like ‘FOR_EACH_SSA_USE_OPERAND’,
! except it works over ‘PHI’ arguments instead of statement operands.
  
       /* Look at every virtual PHI use.  */
       FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES)
*************** except it works over 'PHI' arguments ins
*** 16040,16050 ****
       FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES)
         my_code;
  
!  'FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like
! 'FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a
! statement or a 'PHI' node.  These should be used when it is appropriate
! but they are not quite as efficient as the individual 'FOR_EACH_PHI' and
! 'FOR_EACH_SSA' routines.
  
       FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags)
         {
--- 16040,16050 ----
       FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES)
         my_code;
  
!  ‘FOR_EACH_PHI_OR_STMT_{USE,DEF}’ works exactly like
! ‘FOR_EACH_SSA_{USE,DEF}_OPERAND’, except it will function on either a
! statement or a ‘PHI’ node.  These should be used when it is appropriate
! but they are not quite as efficient as the individual ‘FOR_EACH_PHI’ and
! ‘FOR_EACH_SSA’ routines.
  
       FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags)
         {
*************** but they are not quite as efficient as t
*** 16060,16067 ****
  ---------------------
  
  Immediate use information is now always available.  Using the immediate
! use iterators, you may examine every use of any 'SSA_NAME'.  For
! instance, to change each use of 'ssa_var' to 'ssa_var2' and call
  fold_stmt on each stmt after that is done:
  
         use_operand_p imm_use_p;
--- 16060,16067 ----
  ---------------------
  
  Immediate use information is now always available.  Using the immediate
! use iterators, you may examine every use of any ‘SSA_NAME’.  For
! instance, to change each use of ‘ssa_var’ to ‘ssa_var2’ and call
  fold_stmt on each stmt after that is done:
  
         use_operand_p imm_use_p;
*************** fold_stmt on each stmt after that is don
*** 16076,16088 ****
             fold_stmt (stmt);
           }
  
!  There are 2 iterators which can be used.  'FOR_EACH_IMM_USE_FAST' is
  used when the immediate uses are not changed, i.e., you are looking at
  the uses, but not setting them.
  
   If they do get changed, then care must be taken that things are not
! changed under the iterators, so use the 'FOR_EACH_IMM_USE_STMT' and
! 'FOR_EACH_IMM_USE_ON_STMT' iterators.  They attempt to preserve the
  sanity of the use list by moving all the uses for a statement into a
  controlled position, and then iterating over those uses.  Then the
  optimization can manipulate the stmt when all the uses have been
--- 16076,16088 ----
             fold_stmt (stmt);
           }
  
!  There are 2 iterators which can be used.  ‘FOR_EACH_IMM_USE_FAST’ is
  used when the immediate uses are not changed, i.e., you are looking at
  the uses, but not setting them.
  
   If they do get changed, then care must be taken that things are not
! changed under the iterators, so use the ‘FOR_EACH_IMM_USE_STMT’ and
! ‘FOR_EACH_IMM_USE_ON_STMT’ iterators.  They attempt to preserve the
  sanity of the use list by moving all the uses for a statement into a
  controlled position, and then iterating over those uses.  Then the
  optimization can manipulate the stmt when all the uses have been
*************** processed.  This is a little slower than
*** 16090,16121 ****
  a placeholder element and must sort through the list a bit for each
  statement.  This placeholder element must be also be removed if the loop
  is terminated early; a destructor takes care of that when leaving the
! 'FOR_EACH_IMM_USE_STMT' scope.
  
!  There are checks in 'verify_ssa' which verify that the immediate use
  list is up to date, as well as checking that an optimization didn't
  break from the loop without using this macro.  It is safe to simply
! 'break'; from a 'FOR_EACH_IMM_USE_FAST' traverse.
  
   Some useful functions and macros:
!   1. 'has_zero_uses (ssa_var)' : Returns true if there are no uses of
!      'ssa_var'.
!   2. 'has_single_use (ssa_var)' : Returns true if there is only a single
!      use of 'ssa_var'.
!   3. 'single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' :
!      Returns true if there is only a single use of 'ssa_var', and also
       returns the use pointer and statement it occurs in, in the second
       and third parameters.
!   4. 'num_imm_uses (ssa_var)' : Returns the number of immediate uses of
!      'ssa_var'.  It is better not to use this if possible since it
       simply utilizes a loop to count the uses.
!   5. 'PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a 'PHI' node,
       return the index number for the use.  An assert is triggered if the
!      use isn't located in a 'PHI' node.
!   6. 'USE_STMT (use_p)' : Return the statement a use occurs in.
  
   Note that uses are not put into an immediate use list until their
! statement is actually inserted into the instruction stream via a 'bsi_*'
  routine.
  
   It is also still possible to utilize lazy updating of statements, but
--- 16090,16121 ----
  a placeholder element and must sort through the list a bit for each
  statement.  This placeholder element must be also be removed if the loop
  is terminated early; a destructor takes care of that when leaving the
! ‘FOR_EACH_IMM_USE_STMT’ scope.
  
!  There are checks in ‘verify_ssa’ which verify that the immediate use
  list is up to date, as well as checking that an optimization didn't
  break from the loop without using this macro.  It is safe to simply
! 'break'; from a ‘FOR_EACH_IMM_USE_FAST’ traverse.
  
   Some useful functions and macros:
!   1. ‘has_zero_uses (ssa_var)’ : Returns true if there are no uses of
!      ‘ssa_var’.
!   2. ‘has_single_use (ssa_var)’ : Returns true if there is only a single
!      use of ‘ssa_var’.
!   3. ‘single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)’ :
!      Returns true if there is only a single use of ‘ssa_var’, and also
       returns the use pointer and statement it occurs in, in the second
       and third parameters.
!   4. ‘num_imm_uses (ssa_var)’ : Returns the number of immediate uses of
!      ‘ssa_var’.  It is better not to use this if possible since it
       simply utilizes a loop to count the uses.
!   5. ‘PHI_ARG_INDEX_FROM_USE (use_p)’ : Given a use within a ‘PHI’ node,
       return the index number for the use.  An assert is triggered if the
!      use isn't located in a ‘PHI’ node.
!   6. ‘USE_STMT (use_p)’ : Return the statement a use occurs in.
  
   Note that uses are not put into an immediate use list until their
! statement is actually inserted into the instruction stream via a ‘bsi_*’
  routine.
  
   It is also still possible to utilize lazy updating of statements, but
*************** and the dominator optimizations currentl
*** 16124,16134 ****
  
   When lazy updating is being used, the immediate use information is out
  of date and cannot be used reliably.  Lazy updating is achieved by
! simply marking statements modified via calls to 'gimple_set_modified'
! instead of 'update_stmt'.  When lazy updating is no longer required, all
! the modified statements must have 'update_stmt' called in order to bring
  them up to date.  This must be done before the optimization is finished,
! or 'verify_ssa' will trigger an abort.
  
   This is done with a simple loop over the instruction stream:
         block_stmt_iterator bsi;
--- 16124,16134 ----
  
   When lazy updating is being used, the immediate use information is out
  of date and cannot be used reliably.  Lazy updating is achieved by
! simply marking statements modified via calls to ‘gimple_set_modified’
! instead of ‘update_stmt’.  When lazy updating is no longer required, all
! the modified statements must have ‘update_stmt’ called in order to bring
  them up to date.  This must be done before the optimization is finished,
! or ‘verify_ssa’ will trigger an abort.
  
   This is done with a simple loop over the instruction stream:
         block_stmt_iterator bsi;
*************** File: gccint.info,  Node: SSA,  Next: Al
*** 16147,16156 ****
  
  Most of the tree optimizers rely on the data flow information provided
  by the Static Single Assignment (SSA) form.  We implement the SSA form
! as described in 'R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K.
  Zadeck. Efficiently Computing Static Single Assignment Form and the
  Control Dependence Graph. ACM Transactions on Programming Languages and
! Systems, 13(4):451-490, October 1991'.
  
   The SSA form is based on the premise that program variables are
  assigned in exactly one location in the program.  Multiple assignments
--- 16147,16156 ----
  
  Most of the tree optimizers rely on the data flow information provided
  by the Static Single Assignment (SSA) form.  We implement the SSA form
! as described in ‘R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K.
  Zadeck. Efficiently Computing Static Single Assignment Form and the
  Control Dependence Graph. ACM Transactions on Programming Languages and
! Systems, 13(4):451-490, October 1991’.
  
   The SSA form is based on the premise that program variables are
  assigned in exactly one location in the program.  Multiple assignments
*************** version number.  Variables used in the r
*** 16164,16179 ****
  are renamed so that their version number matches that of the most recent
  assignment.
  
!  We represent variable versions using 'SSA_NAME' nodes.  The renaming
! process in 'tree-ssa.cc' wraps every real and virtual operand with an
! 'SSA_NAME' node which contains the version number and the statement that
! created the 'SSA_NAME'.  Only definitions and virtual definitions may
! create new 'SSA_NAME' nodes.
  
   Sometimes, flow of control makes it impossible to determine the most
  recent version of a variable.  In these cases, the compiler inserts an
! artificial definition for that variable called "PHI function" or "PHI
! node".  This new definition merges all the incoming versions of the
  variable to create a new name for it.  For instance,
  
       if (...)
--- 16164,16179 ----
  are renamed so that their version number matches that of the most recent
  assignment.
  
!  We represent variable versions using ‘SSA_NAME’ nodes.  The renaming
! process in ‘tree-ssa.cc’ wraps every real and virtual operand with an
! ‘SSA_NAME’ node which contains the version number and the statement that
! created the ‘SSA_NAME’.  Only definitions and virtual definitions may
! create new ‘SSA_NAME’ nodes.
  
   Sometimes, flow of control makes it impossible to determine the most
  recent version of a variable.  In these cases, the compiler inserts an
! artificial definition for that variable called “PHI function” or “PHI
! node”.  This new definition merges all the incoming versions of the
  variable to create a new name for it.  For instance,
  
       if (...)
*************** variable to create a new name for it.  F
*** 16187,16201 ****
       return a_4;
  
   Since it is not possible to determine which of the three branches will
! be taken at runtime, we don't know which of 'a_1', 'a_2' or 'a_3' to use
  at the return statement.  So, the SSA renamer creates a new version
! 'a_4' which is assigned the result of "merging" 'a_1', 'a_2' and 'a_3'.
  Hence, PHI nodes mean "one of these operands.  I don't know which".
  
   The following functions can be used to examine PHI nodes
  
   -- Function: gimple_phi_result (PHI)
!      Returns the 'SSA_NAME' created by PHI node PHI (i.e., PHI's LHS).
  
   -- Function: gimple_phi_num_args (PHI)
       Returns the number of arguments in PHI.  This number is exactly the
--- 16187,16201 ----
       return a_4;
  
   Since it is not possible to determine which of the three branches will
! be taken at runtime, we don't know which of ‘a_1’, ‘a_2’ or ‘a_3’ to use
  at the return statement.  So, the SSA renamer creates a new version
! ‘a_4’ which is assigned the result of "merging" ‘a_1’, ‘a_2’ and ‘a_3’.
  Hence, PHI nodes mean "one of these operands.  I don't know which".
  
   The following functions can be used to examine PHI nodes
  
   -- Function: gimple_phi_result (PHI)
!      Returns the ‘SSA_NAME’ created by PHI node PHI (i.e., PHI's LHS).
  
   -- Function: gimple_phi_num_args (PHI)
       Returns the number of arguments in PHI.  This number is exactly the
*************** Hence, PHI nodes mean "one of these oper
*** 16208,16214 ****
       Returns the incoming edge for the Ith argument of PHI.
  
   -- Function: gimple_phi_arg_def (PHI, I)
!      Returns the 'SSA_NAME' for the Ith argument of PHI.
  
  13.3.1 Preserving the SSA form
  ------------------------------
--- 16208,16214 ----
       Returns the incoming edge for the Ith argument of PHI.
  
   -- Function: gimple_phi_arg_def (PHI, I)
!      Returns the ‘SSA_NAME’ for the Ith argument of PHI.
  
  13.3.1 Preserving the SSA form
  ------------------------------
*************** program.
*** 16242,16248 ****
            10   goto L0;
            11 endif
  
!  Suppose that we insert new names 'x_10' and 'x_11' (lines '4' and '8').
  
            1  L0:
            2  x_1 = PHI (0, x_5)
--- 16242,16248 ----
            10   goto L0;
            11 endif
  
!  Suppose that we insert new names ‘x_10’ and ‘x_11’ (lines ‘4’ and ‘8’).
  
            1  L0:
            2  x_1 = PHI (0, x_5)
*************** program.
*** 16258,16272 ****
            12   goto L0;
            13 endif
  
!  We want to replace all the uses of 'x_1' with the new definitions of
! 'x_10' and 'x_11'.  Note that the only uses that should be replaced are
! those at lines '5', '9' and '11'.  Also, the use of 'x_7' at line '9'
! should _not_ be replaced (this is why we cannot just mark symbol 'x' for
  renaming).
  
!  Additionally, we may need to insert a PHI node at line '11' because
! that is a merge point for 'x_10' and 'x_11'.  So the use of 'x_1' at
! line '11' will be replaced with the new PHI node.  The insertion of PHI
  nodes is optional.  They are not strictly necessary to preserve the SSA
  form, and depending on what the caller inserted, they may not even be
  useful for the optimizers.
--- 16258,16272 ----
            12   goto L0;
            13 endif
  
!  We want to replace all the uses of ‘x_1’ with the new definitions of
! ‘x_10’ and ‘x_11’.  Note that the only uses that should be replaced are
! those at lines ‘5’, ‘9’ and ‘11’.  Also, the use of ‘x_7’ at line ‘9’
! should _not_ be replaced (this is why we cannot just mark symbol ‘x’ for
  renaming).
  
!  Additionally, we may need to insert a PHI node at line ‘11’ because
! that is a merge point for ‘x_10’ and ‘x_11’.  So the use of ‘x_1’ at
! line ‘11’ will be replaced with the new PHI node.  The insertion of PHI
  nodes is optional.  They are not strictly necessary to preserve the SSA
  form, and depending on what the caller inserted, they may not even be
  useful for the optimizers.
*************** useful for the optimizers.
*** 16275,16335 ****
  identify which names need to be updated and/or which symbols need to be
  renamed into SSA form for the first time.  When new names are introduced
  to replace existing names in the program, the mapping between the old
! and the new names are registered by calling 'register_new_name_mapping'
  (note that if your pass creates new code by duplicating basic blocks,
! the call to 'tree_duplicate_bb' will set up the necessary mappings
  automatically).
  
   After the replacement mappings have been registered and new symbols
! marked for renaming, a call to 'update_ssa' makes the registered
! changes.  This can be done with an explicit call or by creating 'TODO'
! flags in the 'tree_opt_pass' structure for your pass.  There are several
! 'TODO' flags that control the behavior of 'update_ssa':
  
!    * 'TODO_update_ssa'.  Update the SSA form inserting PHI nodes for
       newly exposed symbols and virtual names marked for updating.  When
!      updating real names, only insert PHI nodes for a real name 'O_j' in
!      blocks reached by all the new and old definitions for 'O_j'.  If
!      the iterated dominance frontier for 'O_j' is not pruned, we may end
       up inserting PHI nodes in blocks that have one or more edges with
!      no incoming definition for 'O_j'.  This would lead to uninitialized
!      warnings for 'O_j''s symbol.
  
!    * 'TODO_update_ssa_no_phi'.  Update the SSA form without inserting
       any new PHI nodes at all.  This is used by passes that have either
       inserted all the PHI nodes themselves or passes that need only to
       patch use-def and def-def chains for virtuals (e.g., DCE).
  
!    * 'TODO_update_ssa_full_phi'.  Insert PHI nodes everywhere they are
       needed.  No pruning of the IDF is done.  This is used by passes
!      that need the PHI nodes for 'O_j' even if it means that some
!      arguments will come from the default definition of 'O_j''s symbol
!      (e.g., 'pass_linear_transform').
  
       WARNING: If you need to use this flag, chances are that your pass
       may be doing something wrong.  Inserting PHI nodes for an old name
       where not all edges carry a new replacement may lead to silent
       codegen errors or spurious uninitialized warnings.
  
!    * 'TODO_update_ssa_only_virtuals'.  Passes that update the SSA form
       on their own may want to delegate the updating of virtual names to
       the generic updater.  Since FUD chains are easier to maintain, this
       simplifies the work they need to do.  NOTE: If this flag is used,
       any OLD->NEW mappings for real names are explicitly destroyed and
       only the symbols marked for renaming are processed.
  
! 13.3.2 Examining 'SSA_NAME' nodes
  ---------------------------------
  
! The following macros can be used to examine 'SSA_NAME' nodes
  
   -- Macro: SSA_NAME_DEF_STMT (VAR)
!      Returns the statement S that creates the 'SSA_NAME' VAR.  If S is
!      an empty statement (i.e., 'IS_EMPTY_STMT (S)' returns 'true'), it
       means that the first reference to this variable is a USE or a VUSE.
  
   -- Macro: SSA_NAME_VERSION (VAR)
!      Returns the version number of the 'SSA_NAME' object VAR.
  
  13.3.3 Walking the dominator tree
  ---------------------------------
--- 16275,16335 ----
  identify which names need to be updated and/or which symbols need to be
  renamed into SSA form for the first time.  When new names are introduced
  to replace existing names in the program, the mapping between the old
! and the new names are registered by calling ‘register_new_name_mapping’
  (note that if your pass creates new code by duplicating basic blocks,
! the call to ‘tree_duplicate_bb’ will set up the necessary mappings
  automatically).
  
   After the replacement mappings have been registered and new symbols
! marked for renaming, a call to ‘update_ssa’ makes the registered
! changes.  This can be done with an explicit call or by creating ‘TODO’
! flags in the ‘tree_opt_pass’ structure for your pass.  There are several
! ‘TODO’ flags that control the behavior of ‘update_ssa’:
  
!    • ‘TODO_update_ssa’.  Update the SSA form inserting PHI nodes for
       newly exposed symbols and virtual names marked for updating.  When
!      updating real names, only insert PHI nodes for a real name ‘O_j’ in
!      blocks reached by all the new and old definitions for ‘O_j’.  If
!      the iterated dominance frontier for ‘O_j’ is not pruned, we may end
       up inserting PHI nodes in blocks that have one or more edges with
!      no incoming definition for ‘O_j’.  This would lead to uninitialized
!      warnings for ‘O_j’'s symbol.
  
!    • ‘TODO_update_ssa_no_phi’.  Update the SSA form without inserting
       any new PHI nodes at all.  This is used by passes that have either
       inserted all the PHI nodes themselves or passes that need only to
       patch use-def and def-def chains for virtuals (e.g., DCE).
  
!    • ‘TODO_update_ssa_full_phi’.  Insert PHI nodes everywhere they are
       needed.  No pruning of the IDF is done.  This is used by passes
!      that need the PHI nodes for ‘O_j’ even if it means that some
!      arguments will come from the default definition of ‘O_j’'s symbol
!      (e.g., ‘pass_linear_transform’).
  
       WARNING: If you need to use this flag, chances are that your pass
       may be doing something wrong.  Inserting PHI nodes for an old name
       where not all edges carry a new replacement may lead to silent
       codegen errors or spurious uninitialized warnings.
  
!    • ‘TODO_update_ssa_only_virtuals’.  Passes that update the SSA form
       on their own may want to delegate the updating of virtual names to
       the generic updater.  Since FUD chains are easier to maintain, this
       simplifies the work they need to do.  NOTE: If this flag is used,
       any OLD->NEW mappings for real names are explicitly destroyed and
       only the symbols marked for renaming are processed.
  
! 13.3.2 Examining ‘SSA_NAME’ nodes
  ---------------------------------
  
! The following macros can be used to examine ‘SSA_NAME’ nodes
  
   -- Macro: SSA_NAME_DEF_STMT (VAR)
!      Returns the statement S that creates the ‘SSA_NAME’ VAR.  If S is
!      an empty statement (i.e., ‘IS_EMPTY_STMT (S)’ returns ‘true’), it
       means that the first reference to this variable is a USE or a VUSE.
  
   -- Macro: SSA_NAME_VERSION (VAR)
!      Returns the version number of the ‘SSA_NAME’ object VAR.
  
  13.3.3 Walking the dominator tree
  ---------------------------------
*************** The following macros can be used to exam
*** 16338,16344 ****
  
       This function walks the dominator tree for the current CFG calling
       a set of callback functions defined in STRUCT DOM_WALK_DATA in
!      'domwalk.h'.  The call back functions you need to define give you
       hooks to execute custom code at various points during traversal:
  
         1. Once to initialize any local data needed while processing BB
--- 16338,16344 ----
  
       This function walks the dominator tree for the current CFG calling
       a set of callback functions defined in STRUCT DOM_WALK_DATA in
!      ‘domwalk.h’.  The call back functions you need to define give you
       hooks to execute custom code at various points during traversal:
  
         1. Once to initialize any local data needed while processing BB
*************** disambiguate explicit and implicit memor
*** 16395,16403 ****
              return i;
            }
  
!      The virtual SSA names in this case are '.MEM_2(D)' and '.MEM_3'.
!      The store to the global variable 'i' defines '.MEM_3' invalidating
!      '.MEM_2(D)'.  The load from 'i' uses that new state '.MEM_3'.
  
       The virtual SSA web serves as constraints to SSA optimizers
       preventing illegitimate code-motion and optimization.  It also
--- 16395,16403 ----
              return i;
            }
  
!      The virtual SSA names in this case are ‘.MEM_2(D)’ and ‘.MEM_3’.
!      The store to the global variable ‘i’ defines ‘.MEM_3’ invalidating
!      ‘.MEM_2(D)’.  The load from ‘i’ uses that new state ‘.MEM_3’.
  
       The virtual SSA web serves as constraints to SSA optimizers
       preventing illegitimate code-motion and optimization.  It also
*************** disambiguate explicit and implicit memor
*** 16413,16440 ****
       what it may possibly point to.
  
       This points-to solution for a given SSA name pointer is stored in
!      the 'pt_solution' sub-structure of the 'SSA_NAME_PTR_INFO' record.
       The following accessor functions are available:
  
!         * 'pt_solution_includes'
!         * 'pt_solutions_intersect'
  
       Points-to analysis also computes the solution for two special set
!      of pointers, 'ESCAPED' and 'CALLUSED'.  Those represent all memory
       that has escaped the scope of analysis or that is used by pure or
       nested const calls.
  
    3. Type-based alias analysis
  
       Type-based alias analysis is frontend dependent though generic
!      support is provided by the middle-end in 'alias.cc'.  TBAA code is
       used by both tree optimizers and RTL optimizers.
  
       Every language that wishes to perform language-specific alias
!      analysis should define a function that computes, given a 'tree'
       node, an alias set for the node.  Nodes in different alias sets are
       not allowed to alias.  For an example, see the C front-end function
!      'c_get_alias_set'.
  
    4. Tree alias-oracle
  
--- 16413,16440 ----
       what it may possibly point to.
  
       This points-to solution for a given SSA name pointer is stored in
!      the ‘pt_solution’ sub-structure of the ‘SSA_NAME_PTR_INFO’ record.
       The following accessor functions are available:
  
!         • ‘pt_solution_includes’
!         • ‘pt_solutions_intersect’
  
       Points-to analysis also computes the solution for two special set
!      of pointers, ‘ESCAPED’ and ‘CALLUSED’.  Those represent all memory
       that has escaped the scope of analysis or that is used by pure or
       nested const calls.
  
    3. Type-based alias analysis
  
       Type-based alias analysis is frontend dependent though generic
!      support is provided by the middle-end in ‘alias.cc’.  TBAA code is
       used by both tree optimizers and RTL optimizers.
  
       Every language that wishes to perform language-specific alias
!      analysis should define a function that computes, given a ‘tree’
       node, an alias set for the node.  Nodes in different alias sets are
       not allowed to alias.  For an example, see the C front-end function
!      ‘c_get_alias_set’.
  
    4. Tree alias-oracle
  
*************** disambiguate explicit and implicit memor
*** 16442,16457 ****
       references and memory references against statements.  The following
       queries are available:
  
!         * 'refs_may_alias_p'
!         * 'ref_maybe_used_by_stmt_p'
!         * 'stmt_may_clobber_ref_p'
  
       In addition to those two kind of statement walkers are available
       walking statements related to a reference ref.
!      'walk_non_aliased_vuses' walks over dominating memory defining
       statements and calls back if the statement does not clobber ref
       providing the non-aliased VUSE. The walk stops at the first
!      clobbering statement or if asked to.  'walk_aliased_vdefs' walks
       over dominating memory defining statements and calls back on each
       statement clobbering ref providing its aliasing VDEF. The walk
       stops if asked to.
--- 16442,16457 ----
       references and memory references against statements.  The following
       queries are available:
  
!         • ‘refs_may_alias_p’
!         • ‘ref_maybe_used_by_stmt_p’
!         • ‘stmt_may_clobber_ref_p’
  
       In addition to those two kind of statement walkers are available
       walking statements related to a reference ref.
!      ‘walk_non_aliased_vuses’ walks over dominating memory defining
       statements and calls back if the statement does not clobber ref
       providing the non-aliased VUSE. The walk stops at the first
!      clobbering statement or if asked to.  ‘walk_aliased_vdefs’ walks
       over dominating memory defining statements and calls back on each
       statement clobbering ref providing its aliasing VDEF. The walk
       stops if asked to.
*************** internal form.
*** 16518,16524 ****
  * RTL Declarations::  Declaring volatility, constancy, etc.
  * Side Effects::      Expressions for storing in registers, etc.
  * Incdec::            Embedded side-effects for autoincrement addressing.
! * Assembler::         Representing 'asm' with operands.
  * Debug Information:: Expressions representing debugging information.
  * Insns::             Expression types for entire insns.
  * Calls::             RTL representation of function call insns.
--- 16518,16524 ----
  * RTL Declarations::  Declaring volatility, constancy, etc.
  * Side Effects::      Expressions for storing in registers, etc.
  * Incdec::            Embedded side-effects for autoincrement addressing.
! * Assembler::         Representing ‘asm’ with operands.
  * Debug Information:: Expressions representing debugging information.
  * Insns::             Expression types for entire insns.
  * Calls::             RTL representation of function call insns.
*************** File: gccint.info,  Node: RTL Objects,
*** 16535,16553 ****
  RTL uses five kinds of objects: expressions, integers, wide integers,
  strings and vectors.  Expressions are the most important ones.  An RTL
  expression ("RTX", for short) is a C structure, but it is usually
! referred to with a pointer; a type that is given the typedef name 'rtx'.
  
!  An integer is simply an 'int'; their written form uses decimal digits.
! A wide integer is an integral object whose type is 'HOST_WIDE_INT';
  their written form uses decimal digits.
  
   A string is a sequence of characters.  In core it is represented as a
! 'char *' in usual C fashion, and it is written in C syntax as well.
  However, strings in RTL may never be null.  If you write an empty string
  in a machine description, it is represented in core as a null pointer
  rather than as a pointer to a null character.  In certain contexts,
  these null pointers instead of strings are valid.  Within RTL code,
! strings are most commonly found inside 'symbol_ref' expressions, but
  they appear in other contexts in the RTL expressions that make up
  machine descriptions.
  
--- 16535,16553 ----
  RTL uses five kinds of objects: expressions, integers, wide integers,
  strings and vectors.  Expressions are the most important ones.  An RTL
  expression ("RTX", for short) is a C structure, but it is usually
! referred to with a pointer; a type that is given the typedef name ‘rtx’.
  
!  An integer is simply an ‘int’; their written form uses decimal digits.
! A wide integer is an integral object whose type is ‘HOST_WIDE_INT’;
  their written form uses decimal digits.
  
   A string is a sequence of characters.  In core it is represented as a
! ‘char *’ in usual C fashion, and it is written in C syntax as well.
  However, strings in RTL may never be null.  If you write an empty string
  in a machine description, it is represented in core as a null pointer
  rather than as a pointer to a null character.  In certain contexts,
  these null pointers instead of strings are valid.  Within RTL code,
! strings are most commonly found inside ‘symbol_ref’ expressions, but
  they appear in other contexts in the RTL expressions that make up
  machine descriptions.
  
*************** need not escape each quote character wit
*** 16568,16606 ****
  
   A vector contains an arbitrary number of pointers to expressions.  The
  number of elements in the vector is explicitly present in the vector.
! The written form of a vector consists of square brackets ('[...]')
  surrounding the elements, in sequence and with whitespace separating
  them.  Vectors of length zero are not created; null pointers are used
  instead.
  
!  Expressions are classified by "expression codes" (also called RTX
! codes).  The expression code is a name defined in 'rtl.def', which is
  also (in uppercase) a C enumeration constant.  The possible expression
  codes and their meanings are machine-independent.  The code of an RTX
! can be extracted with the macro 'GET_CODE (X)' and altered with
! 'PUT_CODE (X, NEWCODE)'.
  
   The expression code determines how many operands the expression
  contains, and what kinds of objects they are.  In RTL, unlike Lisp, you
  cannot tell by looking at an operand what kind of object it is.
  Instead, you must know from its context--from the expression code of the
! containing expression.  For example, in an expression of code 'subreg',
  the first operand is to be regarded as an expression and the second
! operand as a polynomial integer.  In an expression of code 'plus', there
  are two operands, both of which are to be regarded as expressions.  In a
! 'symbol_ref' expression, there is one operand, which is to be regarded
  as a string.
  
   Expressions are written as parentheses containing the name of the
  expression type, its flags and machine mode if any, and then the
  operands of the expression (separated by spaces).
  
!  Expression code names in the 'md' file are written in lowercase, but
  when they appear in C code they are written in uppercase.  In this
! manual, they are shown as follows: 'const_int'.
  
   In a few contexts a null pointer is valid where an expression is
! normally wanted.  The written form of this is '(nil)'.
  
  
  File: gccint.info,  Node: RTL Classes,  Next: Accessors,  Prev: RTL Objects,  Up: RTL
--- 16568,16606 ----
  
   A vector contains an arbitrary number of pointers to expressions.  The
  number of elements in the vector is explicitly present in the vector.
! The written form of a vector consists of square brackets (‘[...]’)
  surrounding the elements, in sequence and with whitespace separating
  them.  Vectors of length zero are not created; null pointers are used
  instead.
  
!  Expressions are classified by “expression codes” (also called RTX
! codes).  The expression code is a name defined in ‘rtl.def’, which is
  also (in uppercase) a C enumeration constant.  The possible expression
  codes and their meanings are machine-independent.  The code of an RTX
! can be extracted with the macro ‘GET_CODE (X)’ and altered with
! ‘PUT_CODE (X, NEWCODE)’.
  
   The expression code determines how many operands the expression
  contains, and what kinds of objects they are.  In RTL, unlike Lisp, you
  cannot tell by looking at an operand what kind of object it is.
  Instead, you must know from its context--from the expression code of the
! containing expression.  For example, in an expression of code ‘subreg’,
  the first operand is to be regarded as an expression and the second
! operand as a polynomial integer.  In an expression of code ‘plus’, there
  are two operands, both of which are to be regarded as expressions.  In a
! ‘symbol_ref’ expression, there is one operand, which is to be regarded
  as a string.
  
   Expressions are written as parentheses containing the name of the
  expression type, its flags and machine mode if any, and then the
  operands of the expression (separated by spaces).
  
!  Expression code names in the ‘md’ file are written in lowercase, but
  when they appear in C code they are written in uppercase.  In this
! manual, they are shown as follows: ‘const_int’.
  
   In a few contexts a null pointer is valid where an expression is
! normally wanted.  The written form of this is ‘(nil)’.
  
  
  File: gccint.info,  Node: RTL Classes,  Next: Accessors,  Prev: RTL Objects,  Up: RTL
*************** File: gccint.info,  Node: RTL Classes,
*** 16608,16771 ****
  14.2 RTL Classes and Formats
  ============================
  
! The various expression codes are divided into several "classes", which
  are represented by single characters.  You can determine the class of an
! RTX code with the macro 'GET_RTX_CLASS (CODE)'.  Currently, 'rtl.def'
  defines these classes:
  
! 'RTX_OBJ'
       An RTX code that represents an actual object, such as a register
!      ('REG') or a memory location ('MEM', 'SYMBOL_REF').  'LO_SUM' is
!      also included; instead, 'SUBREG' and 'STRICT_LOW_PART' are not in
!      this class, but in class 'RTX_EXTRA'.
  
! 'RTX_CONST_OBJ'
!      An RTX code that represents a constant object.  'HIGH' is also
       included in this class.
  
! 'RTX_COMPARE'
!      An RTX code for a non-symmetric comparison, such as 'GEU' or 'LT'.
  
! 'RTX_COMM_COMPARE'
!      An RTX code for a symmetric (commutative) comparison, such as 'EQ'
!      or 'ORDERED'.
  
! 'RTX_UNARY'
!      An RTX code for a unary arithmetic operation, such as 'NEG', 'NOT',
!      or 'ABS'.  This category also includes value extension (sign or
       zero) and conversions between integer and floating point.
  
! 'RTX_COMM_ARITH'
!      An RTX code for a commutative binary operation, such as 'PLUS' or
!      'AND'.  'NE' and 'EQ' are comparisons, so they have class
!      'RTX_COMM_COMPARE'.
  
! 'RTX_BIN_ARITH'
       An RTX code for a non-commutative binary operation, such as
!      'MINUS', 'DIV', or 'ASHIFTRT'.
  
! 'RTX_BITFIELD_OPS'
       An RTX code for a bit-field operation.  Currently only
!      'ZERO_EXTRACT' and 'SIGN_EXTRACT'.  These have three inputs and are
       lvalues (so they can be used for insertion as well).  *Note
       Bit-Fields::.
  
! 'RTX_TERNARY'
       An RTX code for other three input operations.  Currently only
!      'IF_THEN_ELSE', 'VEC_MERGE', 'SIGN_EXTRACT', 'ZERO_EXTRACT', and
!      'FMA'.
  
! 'RTX_INSN'
!      An RTX code for an entire instruction: 'INSN', 'JUMP_INSN', and
!      'CALL_INSN'.  *Note Insns::.
  
! 'RTX_MATCH'
       An RTX code for something that matches in insns, such as
!      'MATCH_DUP'.  These only occur in machine descriptions.
  
! 'RTX_AUTOINC'
       An RTX code for an auto-increment addressing mode, such as
!      'POST_INC'.  'XEXP (X, 0)' gives the auto-modified register.
  
! 'RTX_EXTRA'
       All other RTX codes.  This category includes the remaining codes
!      used only in machine descriptions ('DEFINE_*', etc.).  It also
!      includes all the codes describing side effects ('SET', 'USE',
!      'CLOBBER', etc.)  and the non-insns that may appear on an insn
!      chain, such as 'NOTE', 'BARRIER', and 'CODE_LABEL'.  'SUBREG' is
       also part of this class.
  
!  For each expression code, 'rtl.def' specifies the number of contained
  objects and their kinds using a sequence of characters called the
! "format" of the expression code.  For example, the format of 'subreg' is
! 'ep'.
  
   These are the most commonly used format characters:
  
! 'e'
       An expression (actually a pointer to an expression).
  
! 'i'
       An integer.
  
! 'w'
       A wide integer.
  
! 's'
       A string.
  
! 'E'
       A vector of expressions.
  
   A few other format characters are used occasionally:
  
! 'u'
!      'u' is equivalent to 'e' except that it is printed differently in
       debugging dumps.  It is used for pointers to insns.
  
! 'n'
!      'n' is equivalent to 'i' except that it is printed differently in
       debugging dumps.  It is used for the line number or code number of
!      a 'note' insn.
  
! 'S'
!      'S' indicates a string which is optional.  In the RTL objects in
!      core, 'S' is equivalent to 's', but when the object is read, from
!      an 'md' file, the string value of this operand may be omitted.  An
       omitted string is taken to be the null string.
  
! 'V'
!      'V' indicates a vector which is optional.  In the RTL objects in
!      core, 'V' is equivalent to 'E', but when the object is read from an
!      'md' file, the vector value of this operand may be omitted.  An
       omitted vector is effectively the same as a vector of no elements.
  
! 'B'
!      'B' indicates a pointer to basic block structure.
  
! 'p'
       A polynomial integer.  At present this is used only for
!      'SUBREG_BYTE'.
  
! '0'
!      '0' means a slot whose contents do not fit any normal category.
!      '0' slots are not printed at all in dumps, and are often used in
       special ways by small parts of the compiler.
  
   There are macros to get the number of operands and the format of an
  expression code:
  
! 'GET_RTX_LENGTH (CODE)'
       Number of operands of an RTX of code CODE.
  
! 'GET_RTX_FORMAT (CODE)'
       The format of an RTX of code CODE, as a C string.
  
   Some classes of RTX codes always have the same format.  For example, it
! is safe to assume that all comparison operations have format 'ee'.
  
! 'RTX_UNARY'
!      All codes of this class have format 'e'.
  
! 'RTX_BIN_ARITH'
! 'RTX_COMM_ARITH'
! 'RTX_COMM_COMPARE'
! 'RTX_COMPARE'
!      All codes of these classes have format 'ee'.
  
! 'RTX_BITFIELD_OPS'
! 'RTX_TERNARY'
!      All codes of these classes have format 'eee'.
  
! 'RTX_INSN'
!      All codes of this class have formats that begin with 'iuueiee'.
       *Note Insns::.  Note that not all RTL objects linked onto an insn
!      chain are of class 'RTX_INSN'.
  
! 'RTX_CONST_OBJ'
! 'RTX_OBJ'
! 'RTX_MATCH'
! 'RTX_EXTRA'
       You can make no assumptions about the format of these codes.
  
  
--- 16608,16771 ----
  14.2 RTL Classes and Formats
  ============================
  
! The various expression codes are divided into several “classes”, which
  are represented by single characters.  You can determine the class of an
! RTX code with the macro ‘GET_RTX_CLASS (CODE)’.  Currently, ‘rtl.def’
  defines these classes:
  
! ‘RTX_OBJ’
       An RTX code that represents an actual object, such as a register
!      (‘REG’) or a memory location (‘MEM’, ‘SYMBOL_REF’).  ‘LO_SUM’ is
!      also included; instead, ‘SUBREG’ and ‘STRICT_LOW_PART’ are not in
!      this class, but in class ‘RTX_EXTRA’.
  
! ‘RTX_CONST_OBJ’
!      An RTX code that represents a constant object.  ‘HIGH’ is also
       included in this class.
  
! ‘RTX_COMPARE’
!      An RTX code for a non-symmetric comparison, such as ‘GEU’ or ‘LT’.
  
! ‘RTX_COMM_COMPARE’
!      An RTX code for a symmetric (commutative) comparison, such as ‘EQ’
!      or ‘ORDERED’.
  
! ‘RTX_UNARY’
!      An RTX code for a unary arithmetic operation, such as ‘NEG’, ‘NOT’,
!      or ‘ABS’.  This category also includes value extension (sign or
       zero) and conversions between integer and floating point.
  
! ‘RTX_COMM_ARITH’
!      An RTX code for a commutative binary operation, such as ‘PLUS’ or
!      ‘AND’.  ‘NE’ and ‘EQ’ are comparisons, so they have class
!      ‘RTX_COMM_COMPARE’.
  
! ‘RTX_BIN_ARITH’
       An RTX code for a non-commutative binary operation, such as
!      ‘MINUS’, ‘DIV’, or ‘ASHIFTRT’.
  
! ‘RTX_BITFIELD_OPS’
       An RTX code for a bit-field operation.  Currently only
!      ‘ZERO_EXTRACT’ and ‘SIGN_EXTRACT’.  These have three inputs and are
       lvalues (so they can be used for insertion as well).  *Note
       Bit-Fields::.
  
! ‘RTX_TERNARY’
       An RTX code for other three input operations.  Currently only
!      ‘IF_THEN_ELSE’, ‘VEC_MERGE’, ‘SIGN_EXTRACT’, ‘ZERO_EXTRACT’, and
!      ‘FMA’.
  
! ‘RTX_INSN’
!      An RTX code for an entire instruction: ‘INSN’, ‘JUMP_INSN’, and
!      ‘CALL_INSN’.  *Note Insns::.
  
! ‘RTX_MATCH’
       An RTX code for something that matches in insns, such as
!      ‘MATCH_DUP’.  These only occur in machine descriptions.
  
! ‘RTX_AUTOINC’
       An RTX code for an auto-increment addressing mode, such as
!      ‘POST_INC’.  ‘XEXP (X, 0)’ gives the auto-modified register.
  
! ‘RTX_EXTRA’
       All other RTX codes.  This category includes the remaining codes
!      used only in machine descriptions (‘DEFINE_*’, etc.).  It also
!      includes all the codes describing side effects (‘SET’, ‘USE’,
!      ‘CLOBBER’, etc.)  and the non-insns that may appear on an insn
!      chain, such as ‘NOTE’, ‘BARRIER’, and ‘CODE_LABEL’.  ‘SUBREG’ is
       also part of this class.
  
!  For each expression code, ‘rtl.def’ specifies the number of contained
  objects and their kinds using a sequence of characters called the
! “format” of the expression code.  For example, the format of ‘subreg’ is
! ‘ep’.
  
   These are the most commonly used format characters:
  
! ‘e’
       An expression (actually a pointer to an expression).
  
! ‘i’
       An integer.
  
! ‘w’
       A wide integer.
  
! ‘s’
       A string.
  
! ‘E’
       A vector of expressions.
  
   A few other format characters are used occasionally:
  
! ‘u’
!      ‘u’ is equivalent to ‘e’ except that it is printed differently in
       debugging dumps.  It is used for pointers to insns.
  
! ‘n’
!      ‘n’ is equivalent to ‘i’ except that it is printed differently in
       debugging dumps.  It is used for the line number or code number of
!      a ‘note’ insn.
  
! ‘S’
!      ‘S’ indicates a string which is optional.  In the RTL objects in
!      core, ‘S’ is equivalent to ‘s’, but when the object is read, from
!      an ‘md’ file, the string value of this operand may be omitted.  An
       omitted string is taken to be the null string.
  
! ‘V’
!      ‘V’ indicates a vector which is optional.  In the RTL objects in
!      core, ‘V’ is equivalent to ‘E’, but when the object is read from an
!      ‘md’ file, the vector value of this operand may be omitted.  An
       omitted vector is effectively the same as a vector of no elements.
  
! ‘B’
!      ‘B’ indicates a pointer to basic block structure.
  
! ‘p’
       A polynomial integer.  At present this is used only for
!      ‘SUBREG_BYTE’.
  
! ‘0’
!      ‘0’ means a slot whose contents do not fit any normal category.
!      ‘0’ slots are not printed at all in dumps, and are often used in
       special ways by small parts of the compiler.
  
   There are macros to get the number of operands and the format of an
  expression code:
  
! ‘GET_RTX_LENGTH (CODE)’
       Number of operands of an RTX of code CODE.
  
! ‘GET_RTX_FORMAT (CODE)’
       The format of an RTX of code CODE, as a C string.
  
   Some classes of RTX codes always have the same format.  For example, it
! is safe to assume that all comparison operations have format ‘ee’.
  
! ‘RTX_UNARY’
!      All codes of this class have format ‘e’.
  
! ‘RTX_BIN_ARITH’
! ‘RTX_COMM_ARITH’
! ‘RTX_COMM_COMPARE’
! ‘RTX_COMPARE’
!      All codes of these classes have format ‘ee’.
  
! ‘RTX_BITFIELD_OPS’
! ‘RTX_TERNARY’
!      All codes of these classes have format ‘eee’.
  
! ‘RTX_INSN’
!      All codes of this class have formats that begin with ‘iuueiee’.
       *Note Insns::.  Note that not all RTL objects linked onto an insn
!      chain are of class ‘RTX_INSN’.
  
! ‘RTX_CONST_OBJ’
! ‘RTX_OBJ’
! ‘RTX_MATCH’
! ‘RTX_EXTRA’
       You can make no assumptions about the format of these codes.
  
  
*************** File: gccint.info,  Node: Accessors,  Ne
*** 16774,16781 ****
  14.3 Access to Operands
  =======================
  
! Operands of expressions are accessed using the macros 'XEXP', 'XINT',
! 'XWINT' and 'XSTR'.  Each of these macros takes two arguments: an
  expression-pointer (RTX) and an operand number (counting from zero).
  Thus,
  
--- 16774,16781 ----
  14.3 Access to Operands
  =======================
  
! Operands of expressions are accessed using the macros ‘XEXP’, ‘XINT’,
! ‘XWINT’ and ‘XSTR’.  Each of these macros takes two arguments: an
  expression-pointer (RTX) and an operand number (counting from zero).
  Thus,
  
*************** accesses operand 2 of expression X, as a
*** 16785,16791 ****
  
       XINT (X, 2)
  
! accesses the same operand as an integer.  'XSTR', used in the same
  fashion, would access it as a string.
  
   Any operand can be accessed as an integer, as an expression or as a
--- 16785,16791 ----
  
       XINT (X, 2)
  
! accesses the same operand as an integer.  ‘XSTR’, used in the same
  fashion, would access it as a string.
  
   Any operand can be accessed as an integer, as an expression or as a
*************** value actually stored in the operand.  Y
*** 16794,16824 ****
  expression code of the containing expression.  That is also how you
  would know how many operands there are.
  
!  For example, if X is an 'int_list' expression, you know that it has two
! operands which can be correctly accessed as 'XINT (X, 0)' and 'XEXP (X,
! 1)'.  Incorrect accesses like 'XEXP (X, 0)' and 'XINT (X, 1)' would
  compile, but would trigger an internal compiler error when rtl checking
! is enabled.  Nothing stops you from writing 'XEXP (X, 28)' either, but
  this will access memory past the end of the expression with
  unpredictable results.
  
   Access to operands which are vectors is more complicated.  You can use
! the macro 'XVEC' to get the vector-pointer itself, or the macros
! 'XVECEXP' and 'XVECLEN' to access the elements and length of a vector.
  
! 'XVEC (EXP, IDX)'
       Access the vector-pointer which is operand number IDX in EXP.
  
! 'XVECLEN (EXP, IDX)'
       Access the length (number of elements) in the vector which is in
!      operand number IDX in EXP.  This value is an 'int'.
  
! 'XVECEXP (EXP, IDX, ELTNUM)'
       Access element number ELTNUM in the vector which is in operand
       number IDX in EXP.  This value is an RTX.
  
       It is up to you to make sure that ELTNUM is not negative and is
!      less than 'XVECLEN (EXP, IDX)'.
  
   All the macros defined in this section expand into lvalues and
  therefore can be used to assign the operands, lengths and vector
--- 16794,16824 ----
  expression code of the containing expression.  That is also how you
  would know how many operands there are.
  
!  For example, if X is an ‘int_list’ expression, you know that it has two
! operands which can be correctly accessed as ‘XINT (X, 0)’ and ‘XEXP (X,
! 1)’.  Incorrect accesses like ‘XEXP (X, 0)’ and ‘XINT (X, 1)’ would
  compile, but would trigger an internal compiler error when rtl checking
! is enabled.  Nothing stops you from writing ‘XEXP (X, 28)’ either, but
  this will access memory past the end of the expression with
  unpredictable results.
  
   Access to operands which are vectors is more complicated.  You can use
! the macro ‘XVEC’ to get the vector-pointer itself, or the macros
! ‘XVECEXP’ and ‘XVECLEN’ to access the elements and length of a vector.
  
! ‘XVEC (EXP, IDX)’
       Access the vector-pointer which is operand number IDX in EXP.
  
! ‘XVECLEN (EXP, IDX)’
       Access the length (number of elements) in the vector which is in
!      operand number IDX in EXP.  This value is an ‘int’.
  
! ‘XVECEXP (EXP, IDX, ELTNUM)’
       Access element number ELTNUM in the vector which is in operand
       number IDX in EXP.  This value is an RTX.
  
       It is up to you to make sure that ELTNUM is not negative and is
!      less than ‘XVECLEN (EXP, IDX)’.
  
   All the macros defined in this section expand into lvalues and
  therefore can be used to assign the operands, lengths and vector
*************** File: gccint.info,  Node: Special Access
*** 16832,16967 ****
  
  Some RTL nodes have special annotations associated with them.
  
! 'MEM'
!      'MEM_ALIAS_SET (X)'
            If 0, X is not in any alias set, and may alias anything.
!           Otherwise, X can only alias 'MEM's in a conflicting alias set.
            This value is set in a language-dependent manner in the
            front-end, and should not be altered in the back-end.  In some
            front-ends, these numbers may correspond in some way to types,
            or other language-level entities, but they need not, and the
            back-end makes no such assumptions.  These set numbers are
!           tested with 'alias_sets_conflict_p'.
  
!      'MEM_EXPR (X)'
            If this register is known to hold the value of some user-level
            declaration, this is that tree node.  It may also be a
!           'COMPONENT_REF', in which case this is some field reference,
!           and 'TREE_OPERAND (X, 0)' contains the declaration, or another
!           'COMPONENT_REF', or null if there is no compile-time object
            associated with the reference.
  
!      'MEM_OFFSET_KNOWN_P (X)'
!           True if the offset of the memory reference from 'MEM_EXPR' is
!           known.  'MEM_OFFSET (X)' provides the offset if so.
  
!      'MEM_OFFSET (X)'
!           The offset from the start of 'MEM_EXPR'.  The value is only
!           valid if 'MEM_OFFSET_KNOWN_P (X)' is true.
  
!      'MEM_SIZE_KNOWN_P (X)'
!           True if the size of the memory reference is known.  'MEM_SIZE
!           (X)' provides its size if so.
  
!      'MEM_SIZE (X)'
            The size in bytes of the memory reference.  This is mostly
!           relevant for 'BLKmode' references as otherwise the size is
            implied by the mode.  The value is only valid if
!           'MEM_SIZE_KNOWN_P (X)' is true.
  
!      'MEM_ALIGN (X)'
            The known alignment in bits of the memory reference.
  
!      'MEM_ADDR_SPACE (X)'
            The address space of the memory reference.  This will commonly
            be zero for the generic address space.
  
! 'REG'
!      'ORIGINAL_REGNO (X)'
            This field holds the number the register "originally" had; for
            a pseudo register turned into a hard reg this will hold the
            old pseudo register number.
  
!      'REG_EXPR (X)'
            If this register is known to hold the value of some user-level
            declaration, this is that tree node.
  
!      'REG_OFFSET (X)'
            If this register is known to hold the value of some user-level
            declaration, this is the offset into that logical storage.
  
! 'SYMBOL_REF'
!      'SYMBOL_REF_DECL (X)'
!           If the 'symbol_ref' X was created for a 'VAR_DECL' or a
!           'FUNCTION_DECL', that tree is recorded here.  If this value is
            null, then X was created by back end code generation routines,
            and there is no associated front end symbol table entry.
  
!           'SYMBOL_REF_DECL' may also point to a tree of class ''c'',
            that is, some sort of constant.  In this case, the
!           'symbol_ref' is an entry in the per-file constant pool; again,
            there is no associated front end symbol table entry.
  
!      'SYMBOL_REF_CONSTANT (X)'
!           If 'CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant
            pool entry for X.  It is null otherwise.
  
!      'SYMBOL_REF_DATA (X)'
!           A field of opaque type used to store 'SYMBOL_REF_DECL' or
!           'SYMBOL_REF_CONSTANT'.
  
!      'SYMBOL_REF_FLAGS (X)'
!           In a 'symbol_ref', this is used to communicate various
            predicates about the symbol.  Some of these are common enough
            to be computed by common code, some are specific to the
            target.  The common bits are:
  
!           'SYMBOL_FLAG_FUNCTION'
                 Set if the symbol refers to a function.
  
!           'SYMBOL_FLAG_LOCAL'
                 Set if the symbol is local to this "module".  See
!                'TARGET_BINDS_LOCAL_P'.
  
!           'SYMBOL_FLAG_EXTERNAL'
                 Set if this symbol is not defined in this translation
                 unit.  Note that this is not the inverse of
!                'SYMBOL_FLAG_LOCAL'.
  
!           'SYMBOL_FLAG_SMALL'
                 Set if the symbol is located in the small data section.
!                See 'TARGET_IN_SMALL_DATA_P'.
  
!           'SYMBOL_REF_TLS_MODEL (X)'
                 This is a multi-bit field accessor that returns the
!                'tls_model' to be used for a thread-local storage symbol.
                 It returns zero for non-thread-local symbols.
  
!           'SYMBOL_FLAG_HAS_BLOCK_INFO'
!                Set if the symbol has 'SYMBOL_REF_BLOCK' and
!                'SYMBOL_REF_BLOCK_OFFSET' fields.
  
!           'SYMBOL_FLAG_ANCHOR'
                 Set if the symbol is used as a section anchor.  "Section
                 anchors" are symbols that have a known position within an
!                'object_block' and that can be used to access nearby
                 members of that block.  They are used to implement
!                '-fsection-anchors'.
  
!                If this flag is set, then 'SYMBOL_FLAG_HAS_BLOCK_INFO'
                 will be too.
  
!           Bits beginning with 'SYMBOL_FLAG_MACH_DEP' are available for
            the target's use.
  
! 'SYMBOL_REF_BLOCK (X)'
!      If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the 'object_block'
!      structure to which the symbol belongs, or 'NULL' if it has not been
       assigned a block.
  
! 'SYMBOL_REF_BLOCK_OFFSET (X)'
!      If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from
!      the first object in 'SYMBOL_REF_BLOCK (X)'.  The value is negative
       if X has not yet been assigned to a block, or it has not been given
       an offset within that block.
  
--- 16832,16967 ----
  
  Some RTL nodes have special annotations associated with them.
  
! ‘MEM’
!      ‘MEM_ALIAS_SET (X)’
            If 0, X is not in any alias set, and may alias anything.
!           Otherwise, X can only alias ‘MEM’s in a conflicting alias set.
            This value is set in a language-dependent manner in the
            front-end, and should not be altered in the back-end.  In some
            front-ends, these numbers may correspond in some way to types,
            or other language-level entities, but they need not, and the
            back-end makes no such assumptions.  These set numbers are
!           tested with ‘alias_sets_conflict_p’.
  
!      ‘MEM_EXPR (X)’
            If this register is known to hold the value of some user-level
            declaration, this is that tree node.  It may also be a
!           ‘COMPONENT_REF’, in which case this is some field reference,
!           and ‘TREE_OPERAND (X, 0)’ contains the declaration, or another
!           ‘COMPONENT_REF’, or null if there is no compile-time object
            associated with the reference.
  
!      ‘MEM_OFFSET_KNOWN_P (X)’
!           True if the offset of the memory reference from ‘MEM_EXPR’ is
!           known.  ‘MEM_OFFSET (X)’ provides the offset if so.
  
!      ‘MEM_OFFSET (X)’
!           The offset from the start of ‘MEM_EXPR’.  The value is only
!           valid if ‘MEM_OFFSET_KNOWN_P (X)’ is true.
  
!      ‘MEM_SIZE_KNOWN_P (X)’
!           True if the size of the memory reference is known.  ‘MEM_SIZE
!           (X)’ provides its size if so.
  
!      ‘MEM_SIZE (X)’
            The size in bytes of the memory reference.  This is mostly
!           relevant for ‘BLKmode’ references as otherwise the size is
            implied by the mode.  The value is only valid if
!           ‘MEM_SIZE_KNOWN_P (X)’ is true.
  
!      ‘MEM_ALIGN (X)’
            The known alignment in bits of the memory reference.
  
!      ‘MEM_ADDR_SPACE (X)’
            The address space of the memory reference.  This will commonly
            be zero for the generic address space.
  
! ‘REG’
!      ‘ORIGINAL_REGNO (X)’
            This field holds the number the register "originally" had; for
            a pseudo register turned into a hard reg this will hold the
            old pseudo register number.
  
!      ‘REG_EXPR (X)’
            If this register is known to hold the value of some user-level
            declaration, this is that tree node.
  
!      ‘REG_OFFSET (X)’
            If this register is known to hold the value of some user-level
            declaration, this is the offset into that logical storage.
  
! ‘SYMBOL_REF’
!      ‘SYMBOL_REF_DECL (X)’
!           If the ‘symbol_ref’ X was created for a ‘VAR_DECL’ or a
!           ‘FUNCTION_DECL’, that tree is recorded here.  If this value is
            null, then X was created by back end code generation routines,
            and there is no associated front end symbol table entry.
  
!           ‘SYMBOL_REF_DECL’ may also point to a tree of class ‘'c'’,
            that is, some sort of constant.  In this case, the
!           ‘symbol_ref’ is an entry in the per-file constant pool; again,
            there is no associated front end symbol table entry.
  
!      ‘SYMBOL_REF_CONSTANT (X)’
!           If ‘CONSTANT_POOL_ADDRESS_P (X)’ is true, this is the constant
            pool entry for X.  It is null otherwise.
  
!      ‘SYMBOL_REF_DATA (X)’
!           A field of opaque type used to store ‘SYMBOL_REF_DECL’ or
!           ‘SYMBOL_REF_CONSTANT’.
  
!      ‘SYMBOL_REF_FLAGS (X)’
!           In a ‘symbol_ref’, this is used to communicate various
            predicates about the symbol.  Some of these are common enough
            to be computed by common code, some are specific to the
            target.  The common bits are:
  
!           ‘SYMBOL_FLAG_FUNCTION’
                 Set if the symbol refers to a function.
  
!           ‘SYMBOL_FLAG_LOCAL’
                 Set if the symbol is local to this "module".  See
!                ‘TARGET_BINDS_LOCAL_P’.
  
!           ‘SYMBOL_FLAG_EXTERNAL’
                 Set if this symbol is not defined in this translation
                 unit.  Note that this is not the inverse of
!                ‘SYMBOL_FLAG_LOCAL’.
  
!           ‘SYMBOL_FLAG_SMALL’
                 Set if the symbol is located in the small data section.
!                See ‘TARGET_IN_SMALL_DATA_P’.
  
!           ‘SYMBOL_REF_TLS_MODEL (X)’
                 This is a multi-bit field accessor that returns the
!                ‘tls_model’ to be used for a thread-local storage symbol.
                 It returns zero for non-thread-local symbols.
  
!           ‘SYMBOL_FLAG_HAS_BLOCK_INFO’
!                Set if the symbol has ‘SYMBOL_REF_BLOCK’ and
!                ‘SYMBOL_REF_BLOCK_OFFSET’ fields.
  
!           ‘SYMBOL_FLAG_ANCHOR’
                 Set if the symbol is used as a section anchor.  "Section
                 anchors" are symbols that have a known position within an
!                ‘object_block’ and that can be used to access nearby
                 members of that block.  They are used to implement
!                ‘-fsection-anchors’.
  
!                If this flag is set, then ‘SYMBOL_FLAG_HAS_BLOCK_INFO’
                 will be too.
  
!           Bits beginning with ‘SYMBOL_FLAG_MACH_DEP’ are available for
            the target's use.
  
! ‘SYMBOL_REF_BLOCK (X)’
!      If ‘SYMBOL_REF_HAS_BLOCK_INFO_P (X)’, this is the ‘object_block’
!      structure to which the symbol belongs, or ‘NULL’ if it has not been
       assigned a block.
  
! ‘SYMBOL_REF_BLOCK_OFFSET (X)’
!      If ‘SYMBOL_REF_HAS_BLOCK_INFO_P (X)’, this is the offset of X from
!      the first object in ‘SYMBOL_REF_BLOCK (X)’.  The value is negative
       if X has not yet been assigned to a block, or it has not been given
       an offset within that block.
  
*************** RTL expressions contain several flags (o
*** 16975,16982 ****
  in certain types of expression.  Most often they are accessed with the
  following macros, which expand into lvalues.
  
! 'CROSSING_JUMP_P (X)'
!      Nonzero in a 'jump_insn' if it crosses between hot and cold
       sections, which could potentially be very far apart in the
       executable.  The presence of this flag indicates to other
       optimizations that this branching instruction should not be
--- 16975,16982 ----
  in certain types of expression.  Most often they are accessed with the
  following macros, which expand into lvalues.
  
! ‘CROSSING_JUMP_P (X)’
!      Nonzero in a ‘jump_insn’ if it crosses between hot and cold
       sections, which could potentially be very far apart in the
       executable.  The presence of this flag indicates to other
       optimizations that this branching instruction should not be
*************** following macros, which expand into lval
*** 16984,17050 ****
       the optimization to partition basic blocks into hot and cold
       sections is turned on.
  
! 'CONSTANT_POOL_ADDRESS_P (X)'
!      Nonzero in a 'symbol_ref' if it refers to part of the current
       function's constant pool.  For most targets these addresses are in
!      a '.rodata' section entirely separate from the function, but for
       some targets the addresses are close to the beginning of the
       function.  In either case GCC assumes these addresses can be
       addressed directly, perhaps with the help of base registers.
!      Stored in the 'unchanging' field and printed as '/u'.
  
! 'INSN_ANNULLED_BRANCH_P (X)'
!      In a 'jump_insn', 'call_insn', or 'insn' indicates that the branch
!      is an annulling one.  See the discussion under 'sequence' below.
!      Stored in the 'unchanging' field and printed as '/u'.
  
! 'INSN_DELETED_P (X)'
!      In an 'insn', 'call_insn', 'jump_insn', 'code_label',
!      'jump_table_data', 'barrier', or 'note', nonzero if the insn has
!      been deleted.  Stored in the 'volatil' field and printed as '/v'.
  
! 'INSN_FROM_TARGET_P (X)'
!      In an 'insn' or 'jump_insn' or 'call_insn' in a delay slot of a
       branch, indicates that the insn is from the target of the branch.
!      If the branch insn has 'INSN_ANNULLED_BRANCH_P' set, this insn will
       only be executed if the branch is taken.  For annulled branches
!      with 'INSN_FROM_TARGET_P' clear, the insn will be executed only if
!      the branch is not taken.  When 'INSN_ANNULLED_BRANCH_P' is not set,
!      this insn will always be executed.  Stored in the 'in_struct' field
!      and printed as '/s'.
  
! 'LABEL_PRESERVE_P (X)'
!      In a 'code_label' or 'note', indicates that the label is referenced
       by code or data not visible to the RTL of a given function.  Labels
       referenced by a non-local goto will have this bit set.  Stored in
!      the 'in_struct' field and printed as '/s'.
  
! 'LABEL_REF_NONLOCAL_P (X)'
!      In 'label_ref' and 'reg_label' expressions, nonzero if this is a
!      reference to a non-local label.  Stored in the 'volatil' field and
!      printed as '/v'.
  
! 'MEM_KEEP_ALIAS_SET_P (X)'
!      In 'mem' expressions, 1 if we should keep the alias set for this
       mem unchanged when we access a component.  Set to 1, for example,
       when we are already in a non-addressable component of an aggregate.
!      Stored in the 'jump' field and printed as '/j'.
  
! 'MEM_VOLATILE_P (X)'
!      In 'mem', 'asm_operands', and 'asm_input' expressions, nonzero for
!      volatile memory references.  Stored in the 'volatil' field and
!      printed as '/v'.
  
! 'MEM_NOTRAP_P (X)'
!      In 'mem', nonzero for memory references that will not trap.  Stored
!      in the 'call' field and printed as '/c'.
  
! 'MEM_POINTER (X)'
!      Nonzero in a 'mem' if the memory reference holds a pointer.  Stored
!      in the 'frame_related' field and printed as '/f'.
  
! 'MEM_READONLY_P (X)'
!      Nonzero in a 'mem', if the memory is statically allocated and
       read-only.
  
       Read-only in this context means never modified during the lifetime
--- 16984,17050 ----
       the optimization to partition basic blocks into hot and cold
       sections is turned on.
  
! ‘CONSTANT_POOL_ADDRESS_P (X)’
!      Nonzero in a ‘symbol_ref’ if it refers to part of the current
       function's constant pool.  For most targets these addresses are in
!      a ‘.rodata’ section entirely separate from the function, but for
       some targets the addresses are close to the beginning of the
       function.  In either case GCC assumes these addresses can be
       addressed directly, perhaps with the help of base registers.
!      Stored in the ‘unchanging’ field and printed as ‘/u’.
  
! ‘INSN_ANNULLED_BRANCH_P (X)’
!      In a ‘jump_insn’, ‘call_insn’, or ‘insn’ indicates that the branch
!      is an annulling one.  See the discussion under ‘sequence’ below.
!      Stored in the ‘unchanging’ field and printed as ‘/u’.
  
! ‘INSN_DELETED_P (X)’
!      In an ‘insn’, ‘call_insn’, ‘jump_insn’, ‘code_label’,
!      ‘jump_table_data’, ‘barrier’, or ‘note’, nonzero if the insn has
!      been deleted.  Stored in the ‘volatil’ field and printed as ‘/v’.
  
! ‘INSN_FROM_TARGET_P (X)’
!      In an ‘insn’ or ‘jump_insn’ or ‘call_insn’ in a delay slot of a
       branch, indicates that the insn is from the target of the branch.
!      If the branch insn has ‘INSN_ANNULLED_BRANCH_P’ set, this insn will
       only be executed if the branch is taken.  For annulled branches
!      with ‘INSN_FROM_TARGET_P’ clear, the insn will be executed only if
!      the branch is not taken.  When ‘INSN_ANNULLED_BRANCH_P’ is not set,
!      this insn will always be executed.  Stored in the ‘in_struct’ field
!      and printed as ‘/s’.
  
! ‘LABEL_PRESERVE_P (X)’
!      In a ‘code_label’ or ‘note’, indicates that the label is referenced
       by code or data not visible to the RTL of a given function.  Labels
       referenced by a non-local goto will have this bit set.  Stored in
!      the ‘in_struct’ field and printed as ‘/s’.
  
! ‘LABEL_REF_NONLOCAL_P (X)’
!      In ‘label_ref’ and ‘reg_label’ expressions, nonzero if this is a
!      reference to a non-local label.  Stored in the ‘volatil’ field and
!      printed as ‘/v’.
  
! ‘MEM_KEEP_ALIAS_SET_P (X)’
!      In ‘mem’ expressions, 1 if we should keep the alias set for this
       mem unchanged when we access a component.  Set to 1, for example,
       when we are already in a non-addressable component of an aggregate.
!      Stored in the ‘jump’ field and printed as ‘/j’.
  
! ‘MEM_VOLATILE_P (X)’
!      In ‘mem’, ‘asm_operands’, and ‘asm_input’ expressions, nonzero for
!      volatile memory references.  Stored in the ‘volatil’ field and
!      printed as ‘/v’.
  
! ‘MEM_NOTRAP_P (X)’
!      In ‘mem’, nonzero for memory references that will not trap.  Stored
!      in the ‘call’ field and printed as ‘/c’.
  
! ‘MEM_POINTER (X)’
!      Nonzero in a ‘mem’ if the memory reference holds a pointer.  Stored
!      in the ‘frame_related’ field and printed as ‘/f’.
  
! ‘MEM_READONLY_P (X)’
!      Nonzero in a ‘mem’, if the memory is statically allocated and
       read-only.
  
       Read-only in this context means never modified during the lifetime
*************** following macros, which expand into lval
*** 17055,17112 ****
       from the runtime loader to the application, this memory will never
       be subsequently modified.
  
!      Stored in the 'unchanging' field and printed as '/u'.
  
! 'PREFETCH_SCHEDULE_BARRIER_P (X)'
!      In a 'prefetch', indicates that the prefetch is a scheduling
       barrier.  No other INSNs will be moved over it.  Stored in the
!      'volatil' field and printed as '/v'.
  
! 'REG_FUNCTION_VALUE_P (X)'
!      Nonzero in a 'reg' if it is the place in which this function's
       value is going to be returned.  (This happens only in a hard
!      register.)  Stored in the 'return_val' field and printed as '/i'.
  
! 'REG_POINTER (X)'
!      Nonzero in a 'reg' if the register holds a pointer.  Stored in the
!      'frame_related' field and printed as '/f'.
  
! 'REG_USERVAR_P (X)'
!      In a 'reg', nonzero if it corresponds to a variable present in the
       user's source code.  Zero for temporaries generated internally by
!      the compiler.  Stored in the 'volatil' field and printed as '/v'.
  
       The same hard register may be used also for collecting the values
!      of functions called by this one, but 'REG_FUNCTION_VALUE_P' is zero
       in this kind of use.
  
! 'RTL_CONST_CALL_P (X)'
!      In a 'call_insn' indicates that the insn represents a call to a
!      const function.  Stored in the 'unchanging' field and printed as
!      '/u'.
  
! 'RTL_PURE_CALL_P (X)'
!      In a 'call_insn' indicates that the insn represents a call to a
!      pure function.  Stored in the 'return_val' field and printed as
!      '/i'.
  
! 'RTL_CONST_OR_PURE_CALL_P (X)'
!      In a 'call_insn', true if 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P'
       is true.
  
! 'RTL_LOOPING_CONST_OR_PURE_CALL_P (X)'
!      In a 'call_insn' indicates that the insn represents a possibly
       infinite looping call to a const or pure function.  Stored in the
!      'call' field and printed as '/c'.  Only true if one of
!      'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' is true.
  
! 'RTX_FRAME_RELATED_P (X)'
!      Nonzero in an 'insn', 'call_insn', 'jump_insn', 'barrier', or 'set'
       which is part of a function prologue and sets the stack pointer,
       sets the frame pointer, or saves a register.  This flag should also
       be set on an instruction that sets up a temporary register to use
!      in place of the frame pointer.  Stored in the 'frame_related' field
!      and printed as '/f'.
  
       In particular, on RISC targets where there are limits on the sizes
       of immediate constants, it is sometimes impossible to reach the
--- 17055,17112 ----
       from the runtime loader to the application, this memory will never
       be subsequently modified.
  
!      Stored in the ‘unchanging’ field and printed as ‘/u’.
  
! ‘PREFETCH_SCHEDULE_BARRIER_P (X)’
!      In a ‘prefetch’, indicates that the prefetch is a scheduling
       barrier.  No other INSNs will be moved over it.  Stored in the
!      ‘volatil’ field and printed as ‘/v’.
  
! ‘REG_FUNCTION_VALUE_P (X)’
!      Nonzero in a ‘reg’ if it is the place in which this function's
       value is going to be returned.  (This happens only in a hard
!      register.)  Stored in the ‘return_val’ field and printed as ‘/i’.
  
! ‘REG_POINTER (X)’
!      Nonzero in a ‘reg’ if the register holds a pointer.  Stored in the
!      ‘frame_related’ field and printed as ‘/f’.
  
! ‘REG_USERVAR_P (X)’
!      In a ‘reg’, nonzero if it corresponds to a variable present in the
       user's source code.  Zero for temporaries generated internally by
!      the compiler.  Stored in the ‘volatil’ field and printed as ‘/v’.
  
       The same hard register may be used also for collecting the values
!      of functions called by this one, but ‘REG_FUNCTION_VALUE_P’ is zero
       in this kind of use.
  
! ‘RTL_CONST_CALL_P (X)’
!      In a ‘call_insn’ indicates that the insn represents a call to a
!      const function.  Stored in the ‘unchanging’ field and printed as
!      ‘/u’.
  
! ‘RTL_PURE_CALL_P (X)’
!      In a ‘call_insn’ indicates that the insn represents a call to a
!      pure function.  Stored in the ‘return_val’ field and printed as
!      ‘/i’.
  
! ‘RTL_CONST_OR_PURE_CALL_P (X)’
!      In a ‘call_insn’, true if ‘RTL_CONST_CALL_P’ or ‘RTL_PURE_CALL_P’
       is true.
  
! ‘RTL_LOOPING_CONST_OR_PURE_CALL_P (X)’
!      In a ‘call_insn’ indicates that the insn represents a possibly
       infinite looping call to a const or pure function.  Stored in the
!      ‘call’ field and printed as ‘/c’.  Only true if one of
!      ‘RTL_CONST_CALL_P’ or ‘RTL_PURE_CALL_P’ is true.
  
! ‘RTX_FRAME_RELATED_P (X)’
!      Nonzero in an ‘insn’, ‘call_insn’, ‘jump_insn’, ‘barrier’, or ‘set’
       which is part of a function prologue and sets the stack pointer,
       sets the frame pointer, or saves a register.  This flag should also
       be set on an instruction that sets up a temporary register to use
!      in place of the frame pointer.  Stored in the ‘frame_related’ field
!      and printed as ‘/f’.
  
       In particular, on RISC targets where there are limits on the sizes
       of immediate constants, it is sometimes impossible to reach the
*************** following macros, which expand into lval
*** 17115,17329 ****
       save area, and the Canonical Frame Address, i.e., DWARF2's logical
       frame pointer, register must (temporarily) be changed to be this
       temporary register.  So, the instruction that sets this temporary
!      register must be marked as 'RTX_FRAME_RELATED_P'.
  
       If the marked instruction is overly complex (defined in terms of
!      what 'dwarf2out_frame_debug_expr' can handle), you will also have
!      to create a 'REG_FRAME_RELATED_EXPR' note and attach it to the
       instruction.  This note should contain a simple expression of the
       computation performed by this instruction, i.e., one that
!      'dwarf2out_frame_debug_expr' can handle.
  
       This flag is required for exception handling support on targets
       with RTL prologues.
  
! 'SCHED_GROUP_P (X)'
!      During instruction scheduling, in an 'insn', 'call_insn',
!      'jump_insn' or 'jump_table_data', indicates that the previous insn
       must be scheduled together with this insn.  This is used to ensure
       that certain groups of instructions will not be split up by the
!      instruction scheduling pass, for example, 'use' insns before a
!      'call_insn' may not be separated from the 'call_insn'.  Stored in
!      the 'in_struct' field and printed as '/s'.
  
! 'SET_IS_RETURN_P (X)'
!      For a 'set', nonzero if it is for a return.  Stored in the 'jump'
!      field and printed as '/j'.
  
! 'SIBLING_CALL_P (X)'
!      For a 'call_insn', nonzero if the insn is a sibling call.  Stored
!      in the 'jump' field and printed as '/j'.
  
! 'STRING_POOL_ADDRESS_P (X)'
!      For a 'symbol_ref' expression, nonzero if it addresses this
!      function's string constant pool.  Stored in the 'frame_related'
!      field and printed as '/f'.
  
! 'SUBREG_PROMOTED_UNSIGNED_P (X)'
!      Returns a value greater then zero for a 'subreg' that has
!      'SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is
       kept zero-extended, zero if it is kept sign-extended, and less then
!      zero if it is extended some other way via the 'ptr_extend'
!      instruction.  Stored in the 'unchanging' field and 'volatil' field,
!      printed as '/u' and '/v'.  This macro may only be used to get the
       value it may not be used to change the value.  Use
!      'SUBREG_PROMOTED_UNSIGNED_SET' to change the value.
  
! 'SUBREG_PROMOTED_UNSIGNED_SET (X)'
!      Set the 'unchanging' and 'volatil' fields in a 'subreg' to reflect
!      zero, sign, or other extension.  If 'volatil' is zero, then
!      'unchanging' as nonzero means zero extension and as zero means sign
!      extension.  If 'volatil' is nonzero then some other type of
!      extension was done via the 'ptr_extend' instruction.
  
! 'SUBREG_PROMOTED_VAR_P (X)'
!      Nonzero in a 'subreg' if it was made when accessing an object that
!      was promoted to a wider mode in accord with the 'PROMOTED_MODE'
       machine description macro (*note Storage Layout::).  In this case,
!      the mode of the 'subreg' is the declared mode of the object and the
!      mode of 'SUBREG_REG' is the mode of the register that holds the
       object.  Promoted variables are always either sign- or
       zero-extended to the wider mode on every assignment.  Stored in the
!      'in_struct' field and printed as '/s'.
  
! 'SYMBOL_REF_USED (X)'
!      In a 'symbol_ref', indicates that X has been used.  This is
       normally only used to ensure that X is only declared external once.
!      Stored in the 'used' field.
  
! 'SYMBOL_REF_WEAK (X)'
!      In a 'symbol_ref', indicates that X has been declared weak.  Stored
!      in the 'return_val' field and printed as '/i'.
  
! 'SYMBOL_REF_FLAG (X)'
!      In a 'symbol_ref', this is used as a flag for machine-specific
!      purposes.  Stored in the 'volatil' field and printed as '/v'.
  
!      Most uses of 'SYMBOL_REF_FLAG' are historic and may be subsumed by
!      'SYMBOL_REF_FLAGS'.  Certainly use of 'SYMBOL_REF_FLAGS' is
       mandatory if the target requires more than one bit of storage.
  
   These are the fields to which the above macros refer:
  
! 'call'
!      In a 'mem', 1 means that the memory reference will not trap.
  
!      In a 'call', 1 means that this pure or const call may possibly
       infinite loop.
  
!      In an RTL dump, this flag is represented as '/c'.
  
! 'frame_related'
!      In an 'insn' or 'set' expression, 1 means that it is part of a
       function prologue and sets the stack pointer, sets the frame
       pointer, saves a register, or sets up a temporary register to use
       in place of the frame pointer.
  
!      In 'reg' expressions, 1 means that the register holds a pointer.
  
!      In 'mem' expressions, 1 means that the memory reference holds a
       pointer.
  
!      In 'symbol_ref' expressions, 1 means that the reference addresses
       this function's string constant pool.
  
!      In an RTL dump, this flag is represented as '/f'.
  
! 'in_struct'
!      In 'reg' expressions, it is 1 if the register has its entire life
       contained within the test expression of some loop.
  
!      In 'subreg' expressions, 1 means that the 'subreg' is accessing an
       object that has had its mode promoted from a wider mode.
  
!      In 'label_ref' expressions, 1 means that the referenced label is
       outside the innermost loop containing the insn in which the
!      'label_ref' was found.
  
!      In 'code_label' expressions, it is 1 if the label may never be
       deleted.  This is used for labels which are the target of non-local
       gotos.  Such a label that would have been deleted is replaced with
!      a 'note' of type 'NOTE_INSN_DELETED_LABEL'.
  
!      In an 'insn' during dead-code elimination, 1 means that the insn is
       dead code.
  
!      In an 'insn' or 'jump_insn' during reorg for an insn in the delay
       slot of a branch, 1 means that this insn is from the target of the
       branch.
  
!      In an 'insn' during instruction scheduling, 1 means that this insn
       must be scheduled as part of a group together with the previous
       insn.
  
!      In an RTL dump, this flag is represented as '/s'.
  
! 'return_val'
!      In 'reg' expressions, 1 means the register contains the value to be
       returned by the current function.  On machines that pass parameters
       in registers, the same register number may be used for parameters
       as well, but this flag is not set on such uses.
  
!      In 'symbol_ref' expressions, 1 means the referenced symbol is weak.
  
!      In 'call' expressions, 1 means the call is pure.
  
!      In an RTL dump, this flag is represented as '/i'.
  
! 'jump'
!      In a 'mem' expression, 1 means we should keep the alias set for
       this mem unchanged when we access a component.
  
!      In a 'set', 1 means it is for a return.
  
!      In a 'call_insn', 1 means it is a sibling call.
  
!      In a 'jump_insn', 1 means it is a crossing jump.
  
!      In an RTL dump, this flag is represented as '/j'.
  
! 'unchanging'
!      In 'reg' and 'mem' expressions, 1 means that the value of the
       expression never changes.
  
!      In 'subreg' expressions, it is 1 if the 'subreg' references an
       unsigned object whose mode has been promoted to a wider mode.
  
!      In an 'insn' or 'jump_insn' in the delay slot of a branch
       instruction, 1 means an annulling branch should be used.
  
!      In a 'symbol_ref' expression, 1 means that this symbol addresses
       something in the per-function constant pool.
  
!      In a 'call_insn' 1 means that this instruction is a call to a const
       function.
  
!      In an RTL dump, this flag is represented as '/u'.
  
! 'used'
       This flag is used directly (without an access macro) at the end of
       RTL generation for a function, to count the number of times an
       expression appears in insns.  Expressions that appear more than
       once are copied, according to the rules for shared structure (*note
       Sharing::).
  
!      For a 'reg', it is used directly (without an access macro) by the
       leaf register renumbering code to ensure that each register is only
       renumbered once.
  
!      In a 'symbol_ref', it indicates that an external declaration for
       the symbol has already been written.
  
! 'volatil'
!      In a 'mem', 'asm_operands', or 'asm_input' expression, it is 1 if
       the memory reference is volatile.  Volatile memory references may
       not be deleted, reordered or combined.
  
!      In a 'symbol_ref' expression, it is used for machine-specific
       purposes.
  
!      In a 'reg' expression, it is 1 if the value is a user-level
       variable.  0 indicates an internal compiler temporary.
  
!      In an 'insn', 1 means the insn has been deleted.
  
!      In 'label_ref' and 'reg_label' expressions, 1 means a reference to
       a non-local label.
  
!      In 'prefetch' expressions, 1 means that the containing insn is a
       scheduling barrier.
  
!      In an RTL dump, this flag is represented as '/v'.
  
  
  File: gccint.info,  Node: Machine Modes,  Next: Constants,  Prev: Flags,  Up: RTL
--- 17115,17329 ----
       save area, and the Canonical Frame Address, i.e., DWARF2's logical
       frame pointer, register must (temporarily) be changed to be this
       temporary register.  So, the instruction that sets this temporary
!      register must be marked as ‘RTX_FRAME_RELATED_P’.
  
       If the marked instruction is overly complex (defined in terms of
!      what ‘dwarf2out_frame_debug_expr’ can handle), you will also have
!      to create a ‘REG_FRAME_RELATED_EXPR’ note and attach it to the
       instruction.  This note should contain a simple expression of the
       computation performed by this instruction, i.e., one that
!      ‘dwarf2out_frame_debug_expr’ can handle.
  
       This flag is required for exception handling support on targets
       with RTL prologues.
  
! ‘SCHED_GROUP_P (X)’
!      During instruction scheduling, in an ‘insn’, ‘call_insn’,
!      ‘jump_insn’ or ‘jump_table_data’, indicates that the previous insn
       must be scheduled together with this insn.  This is used to ensure
       that certain groups of instructions will not be split up by the
!      instruction scheduling pass, for example, ‘use’ insns before a
!      ‘call_insn’ may not be separated from the ‘call_insn’.  Stored in
!      the ‘in_struct’ field and printed as ‘/s’.
  
! ‘SET_IS_RETURN_P (X)’
!      For a ‘set’, nonzero if it is for a return.  Stored in the ‘jump’
!      field and printed as ‘/j’.
  
! ‘SIBLING_CALL_P (X)’
!      For a ‘call_insn’, nonzero if the insn is a sibling call.  Stored
!      in the ‘jump’ field and printed as ‘/j’.
  
! ‘STRING_POOL_ADDRESS_P (X)’
!      For a ‘symbol_ref’ expression, nonzero if it addresses this
!      function's string constant pool.  Stored in the ‘frame_related’
!      field and printed as ‘/f’.
  
! ‘SUBREG_PROMOTED_UNSIGNED_P (X)’
!      Returns a value greater then zero for a ‘subreg’ that has
!      ‘SUBREG_PROMOTED_VAR_P’ nonzero if the object being referenced is
       kept zero-extended, zero if it is kept sign-extended, and less then
!      zero if it is extended some other way via the ‘ptr_extend’
!      instruction.  Stored in the ‘unchanging’ field and ‘volatil’ field,
!      printed as ‘/u’ and ‘/v’.  This macro may only be used to get the
       value it may not be used to change the value.  Use
!      ‘SUBREG_PROMOTED_UNSIGNED_SET’ to change the value.
  
! ‘SUBREG_PROMOTED_UNSIGNED_SET (X)’
!      Set the ‘unchanging’ and ‘volatil’ fields in a ‘subreg’ to reflect
!      zero, sign, or other extension.  If ‘volatil’ is zero, then
!      ‘unchanging’ as nonzero means zero extension and as zero means sign
!      extension.  If ‘volatil’ is nonzero then some other type of
!      extension was done via the ‘ptr_extend’ instruction.
  
! ‘SUBREG_PROMOTED_VAR_P (X)’
!      Nonzero in a ‘subreg’ if it was made when accessing an object that
!      was promoted to a wider mode in accord with the ‘PROMOTED_MODE’
       machine description macro (*note Storage Layout::).  In this case,
!      the mode of the ‘subreg’ is the declared mode of the object and the
!      mode of ‘SUBREG_REG’ is the mode of the register that holds the
       object.  Promoted variables are always either sign- or
       zero-extended to the wider mode on every assignment.  Stored in the
!      ‘in_struct’ field and printed as ‘/s’.
  
! ‘SYMBOL_REF_USED (X)’
!      In a ‘symbol_ref’, indicates that X has been used.  This is
       normally only used to ensure that X is only declared external once.
!      Stored in the ‘used’ field.
  
! ‘SYMBOL_REF_WEAK (X)’
!      In a ‘symbol_ref’, indicates that X has been declared weak.  Stored
!      in the ‘return_val’ field and printed as ‘/i’.
  
! ‘SYMBOL_REF_FLAG (X)’
!      In a ‘symbol_ref’, this is used as a flag for machine-specific
!      purposes.  Stored in the ‘volatil’ field and printed as ‘/v’.
  
!      Most uses of ‘SYMBOL_REF_FLAG’ are historic and may be subsumed by
!      ‘SYMBOL_REF_FLAGS’.  Certainly use of ‘SYMBOL_REF_FLAGS’ is
       mandatory if the target requires more than one bit of storage.
  
   These are the fields to which the above macros refer:
  
! ‘call’
!      In a ‘mem’, 1 means that the memory reference will not trap.
  
!      In a ‘call’, 1 means that this pure or const call may possibly
       infinite loop.
  
!      In an RTL dump, this flag is represented as ‘/c’.
  
! ‘frame_related’
!      In an ‘insn’ or ‘set’ expression, 1 means that it is part of a
       function prologue and sets the stack pointer, sets the frame
       pointer, saves a register, or sets up a temporary register to use
       in place of the frame pointer.
  
!      In ‘reg’ expressions, 1 means that the register holds a pointer.
  
!      In ‘mem’ expressions, 1 means that the memory reference holds a
       pointer.
  
!      In ‘symbol_ref’ expressions, 1 means that the reference addresses
       this function's string constant pool.
  
!      In an RTL dump, this flag is represented as ‘/f’.
  
! ‘in_struct’
!      In ‘reg’ expressions, it is 1 if the register has its entire life
       contained within the test expression of some loop.
  
!      In ‘subreg’ expressions, 1 means that the ‘subreg’ is accessing an
       object that has had its mode promoted from a wider mode.
  
!      In ‘label_ref’ expressions, 1 means that the referenced label is
       outside the innermost loop containing the insn in which the
!      ‘label_ref’ was found.
  
!      In ‘code_label’ expressions, it is 1 if the label may never be
       deleted.  This is used for labels which are the target of non-local
       gotos.  Such a label that would have been deleted is replaced with
!      a ‘note’ of type ‘NOTE_INSN_DELETED_LABEL’.
  
!      In an ‘insn’ during dead-code elimination, 1 means that the insn is
       dead code.
  
!      In an ‘insn’ or ‘jump_insn’ during reorg for an insn in the delay
       slot of a branch, 1 means that this insn is from the target of the
       branch.
  
!      In an ‘insn’ during instruction scheduling, 1 means that this insn
       must be scheduled as part of a group together with the previous
       insn.
  
!      In an RTL dump, this flag is represented as ‘/s’.
  
! ‘return_val’
!      In ‘reg’ expressions, 1 means the register contains the value to be
       returned by the current function.  On machines that pass parameters
       in registers, the same register number may be used for parameters
       as well, but this flag is not set on such uses.
  
!      In ‘symbol_ref’ expressions, 1 means the referenced symbol is weak.
  
!      In ‘call’ expressions, 1 means the call is pure.
  
!      In an RTL dump, this flag is represented as ‘/i’.
  
! ‘jump’
!      In a ‘mem’ expression, 1 means we should keep the alias set for
       this mem unchanged when we access a component.
  
!      In a ‘set’, 1 means it is for a return.
  
!      In a ‘call_insn’, 1 means it is a sibling call.
  
!      In a ‘jump_insn’, 1 means it is a crossing jump.
  
!      In an RTL dump, this flag is represented as ‘/j’.
  
! ‘unchanging’
!      In ‘reg’ and ‘mem’ expressions, 1 means that the value of the
       expression never changes.
  
!      In ‘subreg’ expressions, it is 1 if the ‘subreg’ references an
       unsigned object whose mode has been promoted to a wider mode.
  
!      In an ‘insn’ or ‘jump_insn’ in the delay slot of a branch
       instruction, 1 means an annulling branch should be used.
  
!      In a ‘symbol_ref’ expression, 1 means that this symbol addresses
       something in the per-function constant pool.
  
!      In a ‘call_insn’ 1 means that this instruction is a call to a const
       function.
  
!      In an RTL dump, this flag is represented as ‘/u’.
  
! ‘used’
       This flag is used directly (without an access macro) at the end of
       RTL generation for a function, to count the number of times an
       expression appears in insns.  Expressions that appear more than
       once are copied, according to the rules for shared structure (*note
       Sharing::).
  
!      For a ‘reg’, it is used directly (without an access macro) by the
       leaf register renumbering code to ensure that each register is only
       renumbered once.
  
!      In a ‘symbol_ref’, it indicates that an external declaration for
       the symbol has already been written.
  
! ‘volatil’
!      In a ‘mem’, ‘asm_operands’, or ‘asm_input’ expression, it is 1 if
       the memory reference is volatile.  Volatile memory references may
       not be deleted, reordered or combined.
  
!      In a ‘symbol_ref’ expression, it is used for machine-specific
       purposes.
  
!      In a ‘reg’ expression, it is 1 if the value is a user-level
       variable.  0 indicates an internal compiler temporary.
  
!      In an ‘insn’, 1 means the insn has been deleted.
  
!      In ‘label_ref’ and ‘reg_label’ expressions, 1 means a reference to
       a non-local label.
  
!      In ‘prefetch’ expressions, 1 means that the containing insn is a
       scheduling barrier.
  
!      In an RTL dump, this flag is represented as ‘/v’.
  
  
  File: gccint.info,  Node: Machine Modes,  Next: Constants,  Prev: Flags,  Up: RTL
*************** File: gccint.info,  Node: Machine Modes,
*** 17333,17765 ****
  
  A machine mode describes a size of data object and the representation
  used for it.  In the C code, machine modes are represented by an
! enumeration type, 'machine_mode', defined in 'machmode.def'.  Each RTL
  expression has room for a machine mode and so do certain kinds of tree
  expressions (declarations and types, to be precise).
  
   In debugging dumps and machine descriptions, the machine mode of an RTL
  expression is written after the expression code with a colon to separate
! them.  The letters 'mode' which appear at the end of each machine mode
! name are omitted.  For example, '(reg:SI 38)' is a 'reg' expression with
! machine mode 'SImode'.  If the mode is 'VOIDmode', it is not written at
  all.
  
   Here is a table of machine modes.  The term "byte" below refers to an
! object of 'BITS_PER_UNIT' bits (*note Storage Layout::).
  
! 'BImode'
       "Bit" mode represents a single bit, for predicate registers.
  
! 'QImode'
       "Quarter-Integer" mode represents a single byte treated as an
       integer.
  
! 'HImode'
       "Half-Integer" mode represents a two-byte integer.
  
! 'PSImode'
       "Partial Single Integer" mode represents an integer which occupies
       four bytes but which doesn't really use all four.  On some
       machines, this is the right mode to use for pointers.
  
! 'SImode'
       "Single Integer" mode represents a four-byte integer.
  
! 'PDImode'
       "Partial Double Integer" mode represents an integer which occupies
       eight bytes but which doesn't really use all eight.  On some
       machines, this is the right mode to use for certain pointers.
  
! 'DImode'
       "Double Integer" mode represents an eight-byte integer.
  
! 'TImode'
       "Tetra Integer" (?)  mode represents a sixteen-byte integer.
  
! 'OImode'
       "Octa Integer" (?)  mode represents a thirty-two-byte integer.
  
! 'XImode'
       "Hexadeca Integer" (?)  mode represents a sixty-four-byte integer.
  
! 'QFmode'
       "Quarter-Floating" mode represents a quarter-precision (single
       byte) floating point number.
  
! 'HFmode'
       "Half-Floating" mode represents a half-precision (two byte)
       floating point number.
  
! 'TQFmode'
       "Three-Quarter-Floating" (?)  mode represents a
       three-quarter-precision (three byte) floating point number.
  
! 'SFmode'
       "Single Floating" mode represents a four byte floating point
       number.  In the common case, of a processor with IEEE arithmetic
       and 8-bit bytes, this is a single-precision IEEE floating point
       number; it can also be used for double-precision (on processors
       with 16-bit bytes) and single-precision VAX and IBM types.
  
! 'DFmode'
       "Double Floating" mode represents an eight byte floating point
       number.  In the common case, of a processor with IEEE arithmetic
       and 8-bit bytes, this is a double-precision IEEE floating point
       number.
  
! 'XFmode'
       "Extended Floating" mode represents an IEEE extended floating point
       number.  This mode only has 80 meaningful bits (ten bytes).  Some
       processors require such numbers to be padded to twelve bytes,
       others to sixteen; this mode is used for either.
  
! 'SDmode'
       "Single Decimal Floating" mode represents a four byte decimal
       floating point number (as distinct from conventional binary
       floating point).
  
! 'DDmode'
       "Double Decimal Floating" mode represents an eight byte decimal
       floating point number.
  
! 'TDmode'
       "Tetra Decimal Floating" mode represents a sixteen byte decimal
       floating point number all 128 of whose bits are meaningful.
  
! 'TFmode'
       "Tetra Floating" mode represents a sixteen byte floating point
       number all 128 of whose bits are meaningful.  One common use is the
       IEEE quad-precision format.
  
! 'QQmode'
       "Quarter-Fractional" mode represents a single byte treated as a
       signed fractional number.  The default format is "s.7".
  
! 'HQmode'
       "Half-Fractional" mode represents a two-byte signed fractional
       number.  The default format is "s.15".
  
! 'SQmode'
       "Single Fractional" mode represents a four-byte signed fractional
       number.  The default format is "s.31".
  
! 'DQmode'
       "Double Fractional" mode represents an eight-byte signed fractional
       number.  The default format is "s.63".
  
! 'TQmode'
       "Tetra Fractional" mode represents a sixteen-byte signed fractional
       number.  The default format is "s.127".
  
! 'UQQmode'
       "Unsigned Quarter-Fractional" mode represents a single byte treated
       as an unsigned fractional number.  The default format is ".8".
  
! 'UHQmode'
       "Unsigned Half-Fractional" mode represents a two-byte unsigned
       fractional number.  The default format is ".16".
  
! 'USQmode'
       "Unsigned Single Fractional" mode represents a four-byte unsigned
       fractional number.  The default format is ".32".
  
! 'UDQmode'
       "Unsigned Double Fractional" mode represents an eight-byte unsigned
       fractional number.  The default format is ".64".
  
! 'UTQmode'
       "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned
       fractional number.  The default format is ".128".
  
! 'HAmode'
       "Half-Accumulator" mode represents a two-byte signed accumulator.
       The default format is "s8.7".
  
! 'SAmode'
       "Single Accumulator" mode represents a four-byte signed
       accumulator.  The default format is "s16.15".
  
! 'DAmode'
       "Double Accumulator" mode represents an eight-byte signed
       accumulator.  The default format is "s32.31".
  
! 'TAmode'
       "Tetra Accumulator" mode represents a sixteen-byte signed
       accumulator.  The default format is "s64.63".
  
! 'UHAmode'
       "Unsigned Half-Accumulator" mode represents a two-byte unsigned
       accumulator.  The default format is "8.8".
  
! 'USAmode'
       "Unsigned Single Accumulator" mode represents a four-byte unsigned
       accumulator.  The default format is "16.16".
  
! 'UDAmode'
       "Unsigned Double Accumulator" mode represents an eight-byte
       unsigned accumulator.  The default format is "32.32".
  
! 'UTAmode'
       "Unsigned Tetra Accumulator" mode represents a sixteen-byte
       unsigned accumulator.  The default format is "64.64".
  
! 'CCmode'
       "Condition Code" mode represents the value of a condition code,
       which is a machine-specific set of bits used to represent the
       result of a comparison operation.  Other machine-specific modes may
       also be used for the condition code.  (*note Condition Code::).
  
! 'BLKmode'
       "Block" mode represents values that are aggregates to which none of
       the other modes apply.  In RTL, only memory references can have
       this mode, and only if they appear in string-move or vector
       instructions.  On machines which have no such instructions,
!      'BLKmode' will not appear in RTL.
  
! 'VOIDmode'
       Void mode means the absence of a mode or an unspecified mode.  For
!      example, RTL expressions of code 'const_int' have mode 'VOIDmode'
       because they can be taken to have whatever mode the context
!      requires.  In debugging dumps of RTL, 'VOIDmode' is expressed by
       the absence of any mode.
  
! 'QCmode, HCmode, SCmode, DCmode, XCmode, TCmode'
       These modes stand for a complex number represented as a pair of
!      floating point values.  The floating point values are in 'QFmode',
!      'HFmode', 'SFmode', 'DFmode', 'XFmode', and 'TFmode', respectively.
  
! 'CQImode, CHImode, CSImode, CDImode, CTImode, COImode, CPSImode'
       These modes stand for a complex number represented as a pair of
!      integer values.  The integer values are in 'QImode', 'HImode',
!      'SImode', 'DImode', 'TImode', 'OImode', and 'PSImode',
       respectively.
  
! 'BND32mode BND64mode'
       These modes stand for bounds for pointer of 32 and 64 bit size
       respectively.  Mode size is double pointer mode size.
  
!  The machine description defines 'Pmode' as a C macro which expands into
  the machine mode used for addresses.  Normally this is the mode whose
! size is 'BITS_PER_WORD', 'SImode' on 32-bit machines.
  
!  The only modes which a machine description must support are 'QImode',
! and the modes corresponding to 'BITS_PER_WORD', 'FLOAT_TYPE_SIZE' and
! 'DOUBLE_TYPE_SIZE'.  The compiler will attempt to use 'DImode' for
  8-byte structures and unions, but this can be prevented by overriding
! the definition of 'MAX_FIXED_MODE_SIZE'.  Alternatively, you can have
! the compiler use 'TImode' for 16-byte structures and unions.  Likewise,
! you can arrange for the C type 'short int' to avoid using 'HImode'.
  
   Very few explicit references to machine modes remain in the compiler
  and these few references will soon be removed.  Instead, the machine
  modes are divided into mode classes.  These are represented by the
! enumeration type 'enum mode_class' defined in 'machmode.h'.  The
  possible mode classes are:
  
! 'MODE_INT'
!      Integer modes.  By default these are 'BImode', 'QImode', 'HImode',
!      'SImode', 'DImode', 'TImode', and 'OImode'.
  
! 'MODE_PARTIAL_INT'
!      The "partial integer" modes, 'PQImode', 'PHImode', 'PSImode' and
!      'PDImode'.
  
! 'MODE_FLOAT'
!      Floating point modes.  By default these are 'QFmode', 'HFmode',
!      'TQFmode', 'SFmode', 'DFmode', 'XFmode' and 'TFmode'.
  
! 'MODE_DECIMAL_FLOAT'
!      Decimal floating point modes.  By default these are 'SDmode',
!      'DDmode' and 'TDmode'.
  
! 'MODE_FRACT'
!      Signed fractional modes.  By default these are 'QQmode', 'HQmode',
!      'SQmode', 'DQmode' and 'TQmode'.
  
! 'MODE_UFRACT'
!      Unsigned fractional modes.  By default these are 'UQQmode',
!      'UHQmode', 'USQmode', 'UDQmode' and 'UTQmode'.
  
! 'MODE_ACCUM'
!      Signed accumulator modes.  By default these are 'HAmode', 'SAmode',
!      'DAmode' and 'TAmode'.
  
! 'MODE_UACCUM'
!      Unsigned accumulator modes.  By default these are 'UHAmode',
!      'USAmode', 'UDAmode' and 'UTAmode'.
  
! 'MODE_COMPLEX_INT'
       Complex integer modes.  (These are not currently implemented).
  
! 'MODE_COMPLEX_FLOAT'
!      Complex floating point modes.  By default these are 'QCmode',
!      'HCmode', 'SCmode', 'DCmode', 'XCmode', and 'TCmode'.
  
! 'MODE_CC'
!      Modes representing condition code values.  These are 'CCmode' plus
!      any 'CC_MODE' modes listed in the 'MACHINE-modes.def'.  *Note Jump
       Patterns::, also see *note Condition Code::.
  
! 'MODE_POINTER_BOUNDS'
       Pointer bounds modes.  Used to represent values of pointer bounds
       type.  Operations in these modes may be executed as NOPs depending
       on hardware features and environment setup.
  
! 'MODE_OPAQUE'
       This is a mode class for modes that don't want to provide
       operations other than register moves, memory moves, loads, stores,
!      and 'unspec's.  They have a size and precision and that's all.
  
! 'MODE_RANDOM'
       This is a catchall mode class for modes which don't fit into the
!      above classes.  Currently 'VOIDmode' and 'BLKmode' are in
!      'MODE_RANDOM'.
  
!  'machmode.h' also defines various wrapper classes that combine a
! 'machine_mode' with a static assertion that a particular condition
  holds.  The classes are:
  
! 'scalar_int_mode'
!      A mode that has class 'MODE_INT' or 'MODE_PARTIAL_INT'.
  
! 'scalar_float_mode'
!      A mode that has class 'MODE_FLOAT' or 'MODE_DECIMAL_FLOAT'.
  
! 'scalar_mode'
       A mode that holds a single numerical value.  In practice this means
!      that the mode is a 'scalar_int_mode', is a 'scalar_float_mode', or
!      has class 'MODE_FRACT', 'MODE_UFRACT', 'MODE_ACCUM', 'MODE_UACCUM'
!      or 'MODE_POINTER_BOUNDS'.
  
! 'complex_mode'
!      A mode that has class 'MODE_COMPLEX_INT' or 'MODE_COMPLEX_FLOAT'.
  
! 'fixed_size_mode'
       A mode whose size is known at compile time.
  
   Named modes use the most constrained of the available wrapper classes,
! if one exists, otherwise they use 'machine_mode'.  For example, 'QImode'
! is a 'scalar_int_mode', 'SFmode' is a 'scalar_float_mode' and 'BLKmode'
! is a plain 'machine_mode'.  It is possible to refer to any mode as a raw
! 'machine_mode' by adding the 'E_' prefix, where 'E' stands for
! "enumeration".  For example, the raw 'machine_mode' names of the modes
! just mentioned are 'E_QImode', 'E_SFmode' and 'E_BLKmode' respectively.
  
!  The wrapper classes implicitly convert to 'machine_mode' and to any
  wrapper class that represents a more general condition; for example
! 'scalar_int_mode' and 'scalar_float_mode' both convert to 'scalar_mode'
! and all three convert to 'fixed_size_mode'.  The classes act like
! 'machine_mode's that accept only certain named modes.
  
!  'machmode.h' also defines a template class 'opt_mode' that holds a
! 'T' or nothing, where 'T' can be either 'machine_mode' or one of the
! wrapper classes above.  The main operations on an 'opt_mode' X are as
  follows:
  
! 'X.exists ()'
       Return true if X holds a mode rather than nothing.
  
! 'X.exists (&Y)'
       Return true if X holds a mode rather than nothing, storing the mode
       in Y if so.  Y must be assignment-compatible with T.
  
! 'X.require ()'
       Assert that X holds a mode rather than nothing and return that
       mode.
  
! 'X = Y'
       Set X to Y, where Y is a T or implicitly converts to a T.
  
!  The default constructor sets an 'opt_mode' to nothing.  There is
  also a constructor that takes an initial value of type T.
  
!  It is possible to use the 'is-a.h' accessors on a 'machine_mode' or
  machine mode wrapper X:
  
! 'is_a  (X)'
       Return true if X meets the conditions for wrapper class T.
  
! 'is_a  (X, &Y)'
       Return true if X meets the conditions for wrapper class T, storing
       it in Y if so.  Y must be assignment-compatible with T.
  
! 'as_a  (X)'
       Assert that X meets the conditions for wrapper class T and return
       it as a T.
  
! 'dyn_cast  (X)'
!      Return an 'opt_mode' that holds X if X meets the conditions for
       wrapper class T and that holds nothing otherwise.
  
   The purpose of these wrapper classes is to give stronger static type
! checking.  For example, if a function takes a 'scalar_int_mode', a
! caller that has a general 'machine_mode' must either check or assert
  that the code is indeed a scalar integer first, using one of the
  functions above.
  
   The wrapper classes are normal C++ classes, with user-defined
  constructors.  Sometimes it is useful to have a POD version of the same
! type, particularly if the type appears in a 'union'.  The template class
! 'pod_mode' provides a POD version of wrapper class T.  It is
  assignment-compatible with T and implicitly converts to both
! 'machine_mode' and T.
  
   Here are some C macros that relate to machine modes:
  
! 'GET_MODE (X)'
       Returns the machine mode of the RTX X.
  
! 'PUT_MODE (X, NEWMODE)'
       Alters the machine mode of the RTX X to be NEWMODE.
  
! 'NUM_MACHINE_MODES'
       Stands for the number of machine modes available on the target
       machine.  This is one greater than the largest numeric value of any
       machine mode.
  
! 'GET_MODE_NAME (M)'
       Returns the name of mode M as a string.
  
! 'GET_MODE_CLASS (M)'
       Returns the mode class of mode M.
  
! 'GET_MODE_WIDER_MODE (M)'
       Returns the next wider natural mode.  For example, the expression
!      'GET_MODE_WIDER_MODE (QImode)' returns 'HImode'.
  
! 'GET_MODE_SIZE (M)'
       Returns the size in bytes of a datum of mode M.
  
! 'GET_MODE_BITSIZE (M)'
       Returns the size in bits of a datum of mode M.
  
! 'GET_MODE_IBIT (M)'
       Returns the number of integral bits of a datum of fixed-point mode
       M.
  
! 'GET_MODE_FBIT (M)'
       Returns the number of fractional bits of a datum of fixed-point
       mode M.
  
! 'GET_MODE_MASK (M)'
       Returns a bitmask containing 1 for all bits in a word that fit
       within mode M.  This macro can only be used for modes whose bitsize
!      is less than or equal to 'HOST_BITS_PER_INT'.
  
! 'GET_MODE_ALIGNMENT (M)'
       Return the required alignment, in bits, for an object of mode M.
  
! 'GET_MODE_UNIT_SIZE (M)'
       Returns the size in bytes of the subunits of a datum of mode M.
!      This is the same as 'GET_MODE_SIZE' except in the case of complex
       modes.  For them, the unit size is the size of the real or
       imaginary part.
  
! 'GET_MODE_NUNITS (M)'
       Returns the number of units contained in a mode, i.e.,
!      'GET_MODE_SIZE' divided by 'GET_MODE_UNIT_SIZE'.
  
! 'GET_CLASS_NARROWEST_MODE (C)'
       Returns the narrowest mode in mode class C.
  
   The following 3 variables are defined on every target.  They can be
--- 17333,17765 ----
  
  A machine mode describes a size of data object and the representation
  used for it.  In the C code, machine modes are represented by an
! enumeration type, ‘machine_mode’, defined in ‘machmode.def’.  Each RTL
  expression has room for a machine mode and so do certain kinds of tree
  expressions (declarations and types, to be precise).
  
   In debugging dumps and machine descriptions, the machine mode of an RTL
  expression is written after the expression code with a colon to separate
! them.  The letters ‘mode’ which appear at the end of each machine mode
! name are omitted.  For example, ‘(reg:SI 38)’ is a ‘reg’ expression with
! machine mode ‘SImode’.  If the mode is ‘VOIDmode’, it is not written at
  all.
  
   Here is a table of machine modes.  The term "byte" below refers to an
! object of ‘BITS_PER_UNIT’ bits (*note Storage Layout::).
  
! ‘BImode’
       "Bit" mode represents a single bit, for predicate registers.
  
! ‘QImode’
       "Quarter-Integer" mode represents a single byte treated as an
       integer.
  
! ‘HImode’
       "Half-Integer" mode represents a two-byte integer.
  
! ‘PSImode’
       "Partial Single Integer" mode represents an integer which occupies
       four bytes but which doesn't really use all four.  On some
       machines, this is the right mode to use for pointers.
  
! ‘SImode’
       "Single Integer" mode represents a four-byte integer.
  
! ‘PDImode’
       "Partial Double Integer" mode represents an integer which occupies
       eight bytes but which doesn't really use all eight.  On some
       machines, this is the right mode to use for certain pointers.
  
! ‘DImode’
       "Double Integer" mode represents an eight-byte integer.
  
! ‘TImode’
       "Tetra Integer" (?)  mode represents a sixteen-byte integer.
  
! ‘OImode’
       "Octa Integer" (?)  mode represents a thirty-two-byte integer.
  
! ‘XImode’
       "Hexadeca Integer" (?)  mode represents a sixty-four-byte integer.
  
! ‘QFmode’
       "Quarter-Floating" mode represents a quarter-precision (single
       byte) floating point number.
  
! ‘HFmode’
       "Half-Floating" mode represents a half-precision (two byte)
       floating point number.
  
! ‘TQFmode’
       "Three-Quarter-Floating" (?)  mode represents a
       three-quarter-precision (three byte) floating point number.
  
! ‘SFmode’
       "Single Floating" mode represents a four byte floating point
       number.  In the common case, of a processor with IEEE arithmetic
       and 8-bit bytes, this is a single-precision IEEE floating point
       number; it can also be used for double-precision (on processors
       with 16-bit bytes) and single-precision VAX and IBM types.
  
! ‘DFmode’
       "Double Floating" mode represents an eight byte floating point
       number.  In the common case, of a processor with IEEE arithmetic
       and 8-bit bytes, this is a double-precision IEEE floating point
       number.
  
! ‘XFmode’
       "Extended Floating" mode represents an IEEE extended floating point
       number.  This mode only has 80 meaningful bits (ten bytes).  Some
       processors require such numbers to be padded to twelve bytes,
       others to sixteen; this mode is used for either.
  
! ‘SDmode’
       "Single Decimal Floating" mode represents a four byte decimal
       floating point number (as distinct from conventional binary
       floating point).
  
! ‘DDmode’
       "Double Decimal Floating" mode represents an eight byte decimal
       floating point number.
  
! ‘TDmode’
       "Tetra Decimal Floating" mode represents a sixteen byte decimal
       floating point number all 128 of whose bits are meaningful.
  
! ‘TFmode’
       "Tetra Floating" mode represents a sixteen byte floating point
       number all 128 of whose bits are meaningful.  One common use is the
       IEEE quad-precision format.
  
! ‘QQmode’
       "Quarter-Fractional" mode represents a single byte treated as a
       signed fractional number.  The default format is "s.7".
  
! ‘HQmode’
       "Half-Fractional" mode represents a two-byte signed fractional
       number.  The default format is "s.15".
  
! ‘SQmode’
       "Single Fractional" mode represents a four-byte signed fractional
       number.  The default format is "s.31".
  
! ‘DQmode’
       "Double Fractional" mode represents an eight-byte signed fractional
       number.  The default format is "s.63".
  
! ‘TQmode’
       "Tetra Fractional" mode represents a sixteen-byte signed fractional
       number.  The default format is "s.127".
  
! ‘UQQmode’
       "Unsigned Quarter-Fractional" mode represents a single byte treated
       as an unsigned fractional number.  The default format is ".8".
  
! ‘UHQmode’
       "Unsigned Half-Fractional" mode represents a two-byte unsigned
       fractional number.  The default format is ".16".
  
! ‘USQmode’
       "Unsigned Single Fractional" mode represents a four-byte unsigned
       fractional number.  The default format is ".32".
  
! ‘UDQmode’
       "Unsigned Double Fractional" mode represents an eight-byte unsigned
       fractional number.  The default format is ".64".
  
! ‘UTQmode’
       "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned
       fractional number.  The default format is ".128".
  
! ‘HAmode’
       "Half-Accumulator" mode represents a two-byte signed accumulator.
       The default format is "s8.7".
  
! ‘SAmode’
       "Single Accumulator" mode represents a four-byte signed
       accumulator.  The default format is "s16.15".
  
! ‘DAmode’
       "Double Accumulator" mode represents an eight-byte signed
       accumulator.  The default format is "s32.31".
  
! ‘TAmode’
       "Tetra Accumulator" mode represents a sixteen-byte signed
       accumulator.  The default format is "s64.63".
  
! ‘UHAmode’
       "Unsigned Half-Accumulator" mode represents a two-byte unsigned
       accumulator.  The default format is "8.8".
  
! ‘USAmode’
       "Unsigned Single Accumulator" mode represents a four-byte unsigned
       accumulator.  The default format is "16.16".
  
! ‘UDAmode’
       "Unsigned Double Accumulator" mode represents an eight-byte
       unsigned accumulator.  The default format is "32.32".
  
! ‘UTAmode’
       "Unsigned Tetra Accumulator" mode represents a sixteen-byte
       unsigned accumulator.  The default format is "64.64".
  
! ‘CCmode’
       "Condition Code" mode represents the value of a condition code,
       which is a machine-specific set of bits used to represent the
       result of a comparison operation.  Other machine-specific modes may
       also be used for the condition code.  (*note Condition Code::).
  
! ‘BLKmode’
       "Block" mode represents values that are aggregates to which none of
       the other modes apply.  In RTL, only memory references can have
       this mode, and only if they appear in string-move or vector
       instructions.  On machines which have no such instructions,
!      ‘BLKmode’ will not appear in RTL.
  
! ‘VOIDmode’
       Void mode means the absence of a mode or an unspecified mode.  For
!      example, RTL expressions of code ‘const_int’ have mode ‘VOIDmode’
       because they can be taken to have whatever mode the context
!      requires.  In debugging dumps of RTL, ‘VOIDmode’ is expressed by
       the absence of any mode.
  
! ‘QCmode, HCmode, SCmode, DCmode, XCmode, TCmode’
       These modes stand for a complex number represented as a pair of
!      floating point values.  The floating point values are in ‘QFmode’,
!      ‘HFmode’, ‘SFmode’, ‘DFmode’, ‘XFmode’, and ‘TFmode’, respectively.
  
! ‘CQImode, CHImode, CSImode, CDImode, CTImode, COImode, CPSImode’
       These modes stand for a complex number represented as a pair of
!      integer values.  The integer values are in ‘QImode’, ‘HImode’,
!      ‘SImode’, ‘DImode’, ‘TImode’, ‘OImode’, and ‘PSImode’,
       respectively.
  
! ‘BND32mode BND64mode’
       These modes stand for bounds for pointer of 32 and 64 bit size
       respectively.  Mode size is double pointer mode size.
  
!  The machine description defines ‘Pmode’ as a C macro which expands into
  the machine mode used for addresses.  Normally this is the mode whose
! size is ‘BITS_PER_WORD’, ‘SImode’ on 32-bit machines.
  
!  The only modes which a machine description must support are ‘QImode’,
! and the modes corresponding to ‘BITS_PER_WORD’, ‘FLOAT_TYPE_SIZE’ and
! ‘DOUBLE_TYPE_SIZE’.  The compiler will attempt to use ‘DImode’ for
  8-byte structures and unions, but this can be prevented by overriding
! the definition of ‘MAX_FIXED_MODE_SIZE’.  Alternatively, you can have
! the compiler use ‘TImode’ for 16-byte structures and unions.  Likewise,
! you can arrange for the C type ‘short int’ to avoid using ‘HImode’.
  
   Very few explicit references to machine modes remain in the compiler
  and these few references will soon be removed.  Instead, the machine
  modes are divided into mode classes.  These are represented by the
! enumeration type ‘enum mode_class’ defined in ‘machmode.h’.  The
  possible mode classes are:
  
! ‘MODE_INT’
!      Integer modes.  By default these are ‘BImode’, ‘QImode’, ‘HImode’,
!      ‘SImode’, ‘DImode’, ‘TImode’, and ‘OImode’.
  
! ‘MODE_PARTIAL_INT’
!      The "partial integer" modes, ‘PQImode’, ‘PHImode’, ‘PSImode’ and
!      ‘PDImode’.
  
! ‘MODE_FLOAT’
!      Floating point modes.  By default these are ‘QFmode’, ‘HFmode’,
!      ‘TQFmode’, ‘SFmode’, ‘DFmode’, ‘XFmode’ and ‘TFmode’.
  
! ‘MODE_DECIMAL_FLOAT’
!      Decimal floating point modes.  By default these are ‘SDmode’,
!      ‘DDmode’ and ‘TDmode’.
  
! ‘MODE_FRACT’
!      Signed fractional modes.  By default these are ‘QQmode’, ‘HQmode’,
!      ‘SQmode’, ‘DQmode’ and ‘TQmode’.
  
! ‘MODE_UFRACT’
!      Unsigned fractional modes.  By default these are ‘UQQmode’,
!      ‘UHQmode’, ‘USQmode’, ‘UDQmode’ and ‘UTQmode’.
  
! ‘MODE_ACCUM’
!      Signed accumulator modes.  By default these are ‘HAmode’, ‘SAmode’,
!      ‘DAmode’ and ‘TAmode’.
  
! ‘MODE_UACCUM’
!      Unsigned accumulator modes.  By default these are ‘UHAmode’,
!      ‘USAmode’, ‘UDAmode’ and ‘UTAmode’.
  
! ‘MODE_COMPLEX_INT’
       Complex integer modes.  (These are not currently implemented).
  
! ‘MODE_COMPLEX_FLOAT’
!      Complex floating point modes.  By default these are ‘QCmode’,
!      ‘HCmode’, ‘SCmode’, ‘DCmode’, ‘XCmode’, and ‘TCmode’.
  
! ‘MODE_CC’
!      Modes representing condition code values.  These are ‘CCmode’ plus
!      any ‘CC_MODE’ modes listed in the ‘MACHINE-modes.def’.  *Note Jump
       Patterns::, also see *note Condition Code::.
  
! ‘MODE_POINTER_BOUNDS’
       Pointer bounds modes.  Used to represent values of pointer bounds
       type.  Operations in these modes may be executed as NOPs depending
       on hardware features and environment setup.
  
! ‘MODE_OPAQUE’
       This is a mode class for modes that don't want to provide
       operations other than register moves, memory moves, loads, stores,
!      and ‘unspec’s.  They have a size and precision and that's all.
  
! ‘MODE_RANDOM’
       This is a catchall mode class for modes which don't fit into the
!      above classes.  Currently ‘VOIDmode’ and ‘BLKmode’ are in
!      ‘MODE_RANDOM’.
  
!  ‘machmode.h’ also defines various wrapper classes that combine a
! ‘machine_mode’ with a static assertion that a particular condition
  holds.  The classes are:
  
! ‘scalar_int_mode’
!      A mode that has class ‘MODE_INT’ or ‘MODE_PARTIAL_INT’.
  
! ‘scalar_float_mode’
!      A mode that has class ‘MODE_FLOAT’ or ‘MODE_DECIMAL_FLOAT’.
  
! ‘scalar_mode’
       A mode that holds a single numerical value.  In practice this means
!      that the mode is a ‘scalar_int_mode’, is a ‘scalar_float_mode’, or
!      has class ‘MODE_FRACT’, ‘MODE_UFRACT’, ‘MODE_ACCUM’, ‘MODE_UACCUM’
!      or ‘MODE_POINTER_BOUNDS’.
  
! ‘complex_mode’
!      A mode that has class ‘MODE_COMPLEX_INT’ or ‘MODE_COMPLEX_FLOAT’.
  
! ‘fixed_size_mode’
       A mode whose size is known at compile time.
  
   Named modes use the most constrained of the available wrapper classes,
! if one exists, otherwise they use ‘machine_mode’.  For example, ‘QImode’
! is a ‘scalar_int_mode’, ‘SFmode’ is a ‘scalar_float_mode’ and ‘BLKmode’
! is a plain ‘machine_mode’.  It is possible to refer to any mode as a raw
! ‘machine_mode’ by adding the ‘E_’ prefix, where ‘E’ stands for
! "enumeration".  For example, the raw ‘machine_mode’ names of the modes
! just mentioned are ‘E_QImode’, ‘E_SFmode’ and ‘E_BLKmode’ respectively.
  
!  The wrapper classes implicitly convert to ‘machine_mode’ and to any
  wrapper class that represents a more general condition; for example
! ‘scalar_int_mode’ and ‘scalar_float_mode’ both convert to ‘scalar_mode’
! and all three convert to ‘fixed_size_mode’.  The classes act like
! ‘machine_mode’s that accept only certain named modes.
  
!  ‘machmode.h’ also defines a template class ‘opt_mode’ that holds a
! ‘T’ or nothing, where ‘T’ can be either ‘machine_mode’ or one of the
! wrapper classes above.  The main operations on an ‘opt_mode’ X are as
  follows:
  
! ‘X.exists ()’
       Return true if X holds a mode rather than nothing.
  
! ‘X.exists (&Y)’
       Return true if X holds a mode rather than nothing, storing the mode
       in Y if so.  Y must be assignment-compatible with T.
  
! ‘X.require ()’
       Assert that X holds a mode rather than nothing and return that
       mode.
  
! ‘X = Y’
       Set X to Y, where Y is a T or implicitly converts to a T.
  
!  The default constructor sets an ‘opt_mode’ to nothing.  There is
  also a constructor that takes an initial value of type T.
  
!  It is possible to use the ‘is-a.h’ accessors on a ‘machine_mode’ or
  machine mode wrapper X:
  
! ‘is_a  (X)’
       Return true if X meets the conditions for wrapper class T.
  
! ‘is_a  (X, &Y)’
       Return true if X meets the conditions for wrapper class T, storing
       it in Y if so.  Y must be assignment-compatible with T.
  
! ‘as_a  (X)’
       Assert that X meets the conditions for wrapper class T and return
       it as a T.
  
! ‘dyn_cast  (X)’
!      Return an ‘opt_mode’ that holds X if X meets the conditions for
       wrapper class T and that holds nothing otherwise.
  
   The purpose of these wrapper classes is to give stronger static type
! checking.  For example, if a function takes a ‘scalar_int_mode’, a
! caller that has a general ‘machine_mode’ must either check or assert
  that the code is indeed a scalar integer first, using one of the
  functions above.
  
   The wrapper classes are normal C++ classes, with user-defined
  constructors.  Sometimes it is useful to have a POD version of the same
! type, particularly if the type appears in a ‘union’.  The template class
! ‘pod_mode’ provides a POD version of wrapper class T.  It is
  assignment-compatible with T and implicitly converts to both
! ‘machine_mode’ and T.
  
   Here are some C macros that relate to machine modes:
  
! ‘GET_MODE (X)’
       Returns the machine mode of the RTX X.
  
! ‘PUT_MODE (X, NEWMODE)’
       Alters the machine mode of the RTX X to be NEWMODE.
  
! ‘NUM_MACHINE_MODES’
       Stands for the number of machine modes available on the target
       machine.  This is one greater than the largest numeric value of any
       machine mode.
  
! ‘GET_MODE_NAME (M)’
       Returns the name of mode M as a string.
  
! ‘GET_MODE_CLASS (M)’
       Returns the mode class of mode M.
  
! ‘GET_MODE_WIDER_MODE (M)’
       Returns the next wider natural mode.  For example, the expression
!      ‘GET_MODE_WIDER_MODE (QImode)’ returns ‘HImode’.
  
! ‘GET_MODE_SIZE (M)’
       Returns the size in bytes of a datum of mode M.
  
! ‘GET_MODE_BITSIZE (M)’
       Returns the size in bits of a datum of mode M.
  
! ‘GET_MODE_IBIT (M)’
       Returns the number of integral bits of a datum of fixed-point mode
       M.
  
! ‘GET_MODE_FBIT (M)’
       Returns the number of fractional bits of a datum of fixed-point
       mode M.
  
! ‘GET_MODE_MASK (M)’
       Returns a bitmask containing 1 for all bits in a word that fit
       within mode M.  This macro can only be used for modes whose bitsize
!      is less than or equal to ‘HOST_BITS_PER_INT’.
  
! ‘GET_MODE_ALIGNMENT (M)’
       Return the required alignment, in bits, for an object of mode M.
  
! ‘GET_MODE_UNIT_SIZE (M)’
       Returns the size in bytes of the subunits of a datum of mode M.
!      This is the same as ‘GET_MODE_SIZE’ except in the case of complex
       modes.  For them, the unit size is the size of the real or
       imaginary part.
  
! ‘GET_MODE_NUNITS (M)’
       Returns the number of units contained in a mode, i.e.,
!      ‘GET_MODE_SIZE’ divided by ‘GET_MODE_UNIT_SIZE’.
  
! ‘GET_CLASS_NARROWEST_MODE (C)’
       Returns the narrowest mode in mode class C.
  
   The following 3 variables are defined on every target.  They can be
*************** overridden by defining them in the targe
*** 17769,17796 ****
  value must be a constant that can determined very early in the
  compilation process.  The third symbol cannot be overridden.
  
! 'BITS_PER_UNIT'
       The number of bits in an addressable storage unit (byte).  If you
       do not define this, the default is 8.
  
! 'MAX_BITSIZE_MODE_ANY_INT'
       The maximum bitsize of any mode that is used in integer math.  This
       should be overridden by the target if it uses large integers as
       containers for larger vectors but otherwise never uses the contents
       to compute integer values.
  
! 'MAX_BITSIZE_MODE_ANY_MODE'
       The bitsize of the largest mode on the target.  The default value
       is the largest mode size given in the mode definition file, which
       is always correct for targets whose modes have a fixed size.
       Targets that might increase the size of a mode beyond this default
!      should define 'MAX_BITSIZE_MODE_ANY_MODE' to the actual upper limit
!      in 'MACHINE-modes.def'.
  
!  The global variables 'byte_mode' and 'word_mode' contain modes whose
! classes are 'MODE_INT' and whose bitsizes are either 'BITS_PER_UNIT' or
! 'BITS_PER_WORD', respectively.  On 32-bit machines, these are 'QImode'
! and 'SImode', respectively.
  
  
  File: gccint.info,  Node: Constants,  Next: Regs and Memory,  Prev: Machine Modes,  Up: RTL
--- 17769,17796 ----
  value must be a constant that can determined very early in the
  compilation process.  The third symbol cannot be overridden.
  
! ‘BITS_PER_UNIT’
       The number of bits in an addressable storage unit (byte).  If you
       do not define this, the default is 8.
  
! ‘MAX_BITSIZE_MODE_ANY_INT’
       The maximum bitsize of any mode that is used in integer math.  This
       should be overridden by the target if it uses large integers as
       containers for larger vectors but otherwise never uses the contents
       to compute integer values.
  
! ‘MAX_BITSIZE_MODE_ANY_MODE’
       The bitsize of the largest mode on the target.  The default value
       is the largest mode size given in the mode definition file, which
       is always correct for targets whose modes have a fixed size.
       Targets that might increase the size of a mode beyond this default
!      should define ‘MAX_BITSIZE_MODE_ANY_MODE’ to the actual upper limit
!      in ‘MACHINE-modes.def’.
  
!  The global variables ‘byte_mode’ and ‘word_mode’ contain modes whose
! classes are ‘MODE_INT’ and whose bitsizes are either ‘BITS_PER_UNIT’ or
! ‘BITS_PER_WORD’, respectively.  On 32-bit machines, these are ‘QImode’
! and ‘SImode’, respectively.
  
  
  File: gccint.info,  Node: Constants,  Next: Regs and Memory,  Prev: Machine Modes,  Up: RTL
*************** File: gccint.info,  Node: Constants,  Ne
*** 17800,17867 ****
  
  The simplest RTL expressions are those that represent constant values.
  
! '(const_int I)'
       This type of expression represents the integer value I.  I is
!      customarily accessed with the macro 'INTVAL' as in 'INTVAL (EXP)',
!      which is equivalent to 'XWINT (EXP, 0)'.
  
       Constants generated for modes with fewer bits than in
!      'HOST_WIDE_INT' must be sign extended to full width (e.g., with
!      'gen_int_mode').  For constants for modes with more bits than in
!      'HOST_WIDE_INT' the implied high order bits of that constant are
       copies of the top bit.  Note however that values are neither
       inherently signed nor inherently unsigned; where necessary,
       signedness is determined by the rtl operation instead.
  
       There is only one expression object for the integer value zero; it
!      is the value of the variable 'const0_rtx'.  Likewise, the only
!      expression for integer value one is found in 'const1_rtx', the only
!      expression for integer value two is found in 'const2_rtx', and the
       only expression for integer value negative one is found in
!      'constm1_rtx'.  Any attempt to create an expression of code
!      'const_int' and value zero, one, two or negative one will return
!      'const0_rtx', 'const1_rtx', 'const2_rtx' or 'constm1_rtx' as
       appropriate.
  
       Similarly, there is only one object for the integer whose value is
!      'STORE_FLAG_VALUE'.  It is found in 'const_true_rtx'.  If
!      'STORE_FLAG_VALUE' is one, 'const_true_rtx' and 'const1_rtx' will
!      point to the same object.  If 'STORE_FLAG_VALUE' is -1,
!      'const_true_rtx' and 'constm1_rtx' will point to the same object.
  
! '(const_double:M I0 I1 ...)'
       This represents either a floating-point constant of mode M or (on
!      older ports that do not define 'TARGET_SUPPORTS_WIDE_INT') an
!      integer constant too large to fit into 'HOST_BITS_PER_WIDE_INT'
       bits but small enough to fit within twice that number of bits.  In
!      the latter case, M will be 'VOIDmode'.  For integral values
       constants for modes with more bits than twice the number in
!      'HOST_WIDE_INT' the implied high order bits of that constant are
!      copies of the top bit of 'CONST_DOUBLE_HIGH'.  Note however that
       integral values are neither inherently signed nor inherently
       unsigned; where necessary, signedness is determined by the rtl
       operation instead.
  
!      On more modern ports, 'CONST_DOUBLE' only represents floating point
!      values.  New ports define 'TARGET_SUPPORTS_WIDE_INT' to make this
       designation.
  
!      If M is 'VOIDmode', the bits of the value are stored in I0 and I1.
!      I0 is customarily accessed with the macro 'CONST_DOUBLE_LOW' and I1
!      with 'CONST_DOUBLE_HIGH'.
  
       If the constant is floating point (regardless of its precision),
       then the number of integers used to store the value depends on the
!      size of 'REAL_VALUE_TYPE' (*note Floating Point::).  The integers
       represent a floating point number, but not precisely in the target
       machine's or host machine's floating point format.  To convert them
       to the precise bit pattern used by the target machine, use the
!      macro 'REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data
       Output::).
  
       The host dependency for the number of integers used to store a
       double value makes it problematic for machine descriptions to use
!      expressions of code 'const_double' and therefore a syntactic alias
       has been provided:
  
            (const_double_zero:M)
--- 17800,17867 ----
  
  The simplest RTL expressions are those that represent constant values.
  
! ‘(const_int I)’
       This type of expression represents the integer value I.  I is
!      customarily accessed with the macro ‘INTVAL’ as in ‘INTVAL (EXP)’,
!      which is equivalent to ‘XWINT (EXP, 0)’.
  
       Constants generated for modes with fewer bits than in
!      ‘HOST_WIDE_INT’ must be sign extended to full width (e.g., with
!      ‘gen_int_mode’).  For constants for modes with more bits than in
!      ‘HOST_WIDE_INT’ the implied high order bits of that constant are
       copies of the top bit.  Note however that values are neither
       inherently signed nor inherently unsigned; where necessary,
       signedness is determined by the rtl operation instead.
  
       There is only one expression object for the integer value zero; it
!      is the value of the variable ‘const0_rtx’.  Likewise, the only
!      expression for integer value one is found in ‘const1_rtx’, the only
!      expression for integer value two is found in ‘const2_rtx’, and the
       only expression for integer value negative one is found in
!      ‘constm1_rtx’.  Any attempt to create an expression of code
!      ‘const_int’ and value zero, one, two or negative one will return
!      ‘const0_rtx’, ‘const1_rtx’, ‘const2_rtx’ or ‘constm1_rtx’ as
       appropriate.
  
       Similarly, there is only one object for the integer whose value is
!      ‘STORE_FLAG_VALUE’.  It is found in ‘const_true_rtx’.  If
!      ‘STORE_FLAG_VALUE’ is one, ‘const_true_rtx’ and ‘const1_rtx’ will
!      point to the same object.  If ‘STORE_FLAG_VALUE’ is −1,
!      ‘const_true_rtx’ and ‘constm1_rtx’ will point to the same object.
  
! ‘(const_double:M I0 I1 ...)’
       This represents either a floating-point constant of mode M or (on
!      older ports that do not define ‘TARGET_SUPPORTS_WIDE_INT’) an
!      integer constant too large to fit into ‘HOST_BITS_PER_WIDE_INT’
       bits but small enough to fit within twice that number of bits.  In
!      the latter case, M will be ‘VOIDmode’.  For integral values
       constants for modes with more bits than twice the number in
!      ‘HOST_WIDE_INT’ the implied high order bits of that constant are
!      copies of the top bit of ‘CONST_DOUBLE_HIGH’.  Note however that
       integral values are neither inherently signed nor inherently
       unsigned; where necessary, signedness is determined by the rtl
       operation instead.
  
!      On more modern ports, ‘CONST_DOUBLE’ only represents floating point
!      values.  New ports define ‘TARGET_SUPPORTS_WIDE_INT’ to make this
       designation.
  
!      If M is ‘VOIDmode’, the bits of the value are stored in I0 and I1.
!      I0 is customarily accessed with the macro ‘CONST_DOUBLE_LOW’ and I1
!      with ‘CONST_DOUBLE_HIGH’.
  
       If the constant is floating point (regardless of its precision),
       then the number of integers used to store the value depends on the
!      size of ‘REAL_VALUE_TYPE’ (*note Floating Point::).  The integers
       represent a floating point number, but not precisely in the target
       machine's or host machine's floating point format.  To convert them
       to the precise bit pattern used by the target machine, use the
!      macro ‘REAL_VALUE_TO_TARGET_DOUBLE’ and friends (*note Data
       Output::).
  
       The host dependency for the number of integers used to store a
       double value makes it problematic for machine descriptions to use
!      expressions of code ‘const_double’ and therefore a syntactic alias
       has been provided:
  
            (const_double_zero:M)
*************** The simplest RTL expressions are those t
*** 17873,17926 ****
       for matching the floating-point value zero, possibly the only
       useful one.
  
! '(const_wide_int:M NUNITS ELT0 ...)'
!      This contains an array of 'HOST_WIDE_INT's that is large enough to
       hold any constant that can be represented on the target.  This form
       of rtl is only used on targets that define
!      'TARGET_SUPPORTS_WIDE_INT' to be nonzero and then 'CONST_DOUBLE's
       are only used to hold floating-point values.  If the target leaves
!      'TARGET_SUPPORTS_WIDE_INT' defined as 0, 'CONST_WIDE_INT's are not
!      used and 'CONST_DOUBLE's are as they were before.
  
       The values are stored in a compressed format.  The higher-order 0s
       or -1s are not represented if they are just the logical sign
       extension of the number that is represented.
  
! 'CONST_WIDE_INT_VEC (CODE)'
!      Returns the entire array of 'HOST_WIDE_INT's that are used to store
       the value.  This macro should be rarely used.
  
! 'CONST_WIDE_INT_NUNITS (CODE)'
!      The number of 'HOST_WIDE_INT's used to represent the number.  Note
!      that this generally is smaller than the number of 'HOST_WIDE_INT's
       implied by the mode size.
  
! 'CONST_WIDE_INT_ELT (CODE,I)'
!      Returns the 'i'th element of the array.  Element 0 is contains the
       low order bits of the constant.
  
! '(const_fixed:M ...)'
       Represents a fixed-point constant of mode M.  The operand is a data
!      structure of type 'struct fixed_value' and is accessed with the
!      macro 'CONST_FIXED_VALUE'.  The high part of data is accessed with
!      'CONST_FIXED_VALUE_HIGH'; the low part is accessed with
!      'CONST_FIXED_VALUE_LOW'.
  
! '(const_poly_int:M [C0 C1 ...])'
!      Represents a 'poly_int'-style polynomial integer with coefficients
!      C0, C1, ....  The coefficients are 'wide_int'-based integers rather
!      than rtxes.  'CONST_POLY_INT_COEFFS' gives the values of individual
       coefficients (which is mostly only useful in low-level routines)
!      and 'const_poly_int_value' gives the full 'poly_int' value.
  
! '(const_vector:M [X0 X1 ...])'
       Represents a vector constant.  The values in square brackets are
!      elements of the vector, which are always 'const_int',
!      'const_wide_int', 'const_double' or 'const_fixed' expressions.
  
       Each vector constant V is treated as a specific instance of an
       arbitrary-length sequence that itself contains
!      'CONST_VECTOR_NPATTERNS (V)' interleaved patterns.  Each pattern
       has the form:
  
            { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... }
--- 17873,17926 ----
       for matching the floating-point value zero, possibly the only
       useful one.
  
! ‘(const_wide_int:M NUNITS ELT0 ...)’
!      This contains an array of ‘HOST_WIDE_INT’s that is large enough to
       hold any constant that can be represented on the target.  This form
       of rtl is only used on targets that define
!      ‘TARGET_SUPPORTS_WIDE_INT’ to be nonzero and then ‘CONST_DOUBLE’s
       are only used to hold floating-point values.  If the target leaves
!      ‘TARGET_SUPPORTS_WIDE_INT’ defined as 0, ‘CONST_WIDE_INT’s are not
!      used and ‘CONST_DOUBLE’s are as they were before.
  
       The values are stored in a compressed format.  The higher-order 0s
       or -1s are not represented if they are just the logical sign
       extension of the number that is represented.
  
! ‘CONST_WIDE_INT_VEC (CODE)’
!      Returns the entire array of ‘HOST_WIDE_INT’s that are used to store
       the value.  This macro should be rarely used.
  
! ‘CONST_WIDE_INT_NUNITS (CODE)’
!      The number of ‘HOST_WIDE_INT’s used to represent the number.  Note
!      that this generally is smaller than the number of ‘HOST_WIDE_INT’s
       implied by the mode size.
  
! ‘CONST_WIDE_INT_ELT (CODE,I)’
!      Returns the ‘i’th element of the array.  Element 0 is contains the
       low order bits of the constant.
  
! ‘(const_fixed:M ...)’
       Represents a fixed-point constant of mode M.  The operand is a data
!      structure of type ‘struct fixed_value’ and is accessed with the
!      macro ‘CONST_FIXED_VALUE’.  The high part of data is accessed with
!      ‘CONST_FIXED_VALUE_HIGH’; the low part is accessed with
!      ‘CONST_FIXED_VALUE_LOW’.
  
! ‘(const_poly_int:M [C0 C1 ...])’
!      Represents a ‘poly_int’-style polynomial integer with coefficients
!      C0, C1, ....  The coefficients are ‘wide_int’-based integers rather
!      than rtxes.  ‘CONST_POLY_INT_COEFFS’ gives the values of individual
       coefficients (which is mostly only useful in low-level routines)
!      and ‘const_poly_int_value’ gives the full ‘poly_int’ value.
  
! ‘(const_vector:M [X0 X1 ...])’
       Represents a vector constant.  The values in square brackets are
!      elements of the vector, which are always ‘const_int’,
!      ‘const_wide_int’, ‘const_double’ or ‘const_fixed’ expressions.
  
       Each vector constant V is treated as a specific instance of an
       arbitrary-length sequence that itself contains
!      ‘CONST_VECTOR_NPATTERNS (V)’ interleaved patterns.  Each pattern
       has the form:
  
            { BASE0, BASE1, BASE1 + STEP, BASE1 + STEP * 2, ... }
*************** The simplest RTL expressions are those t
*** 17930,17936 ****
       only the first two elements are needed.  If in addition each BASE1
       is equal to the corresponding BASE0, only the first element in each
       pattern is needed.  The number of determining elements per pattern
!      is given by 'CONST_VECTOR_NELTS_PER_PATTERN (V)'.
  
       For example, the constant:
  
--- 17930,17936 ----
       only the first two elements are needed.  If in addition each BASE1
       is equal to the corresponding BASE0, only the first element in each
       pattern is needed.  The number of determining elements per pattern
!      is given by ‘CONST_VECTOR_NELTS_PER_PATTERN (V)’.
  
       For example, the constant:
  
*************** The simplest RTL expressions are those t
*** 17951,17964 ****
            CONST_VECTOR_NPATTERNS (V) == 2
            CONST_VECTOR_NELTS_PER_PATTERN (V) == 3
  
!      Thus the first 6 elements ('{ 0, 1, 2, 6, 3, 8 }') are enough to
       determine the whole sequence; we refer to them as the "encoded"
       elements.  They are the only elements present in the square
!      brackets for variable-length 'const_vector's (i.e. for
!      'const_vector's whose mode M has a variable number of elements).
       However, as a convenience to code that needs to handle both
!      'const_vector's and 'parallel's, all elements are present in the
!      square brackets for fixed-length 'const_vector's; the encoding
       scheme simply reduces the amount of work involved in processing
       constants that follow a regular pattern.
  
--- 17951,17964 ----
            CONST_VECTOR_NPATTERNS (V) == 2
            CONST_VECTOR_NELTS_PER_PATTERN (V) == 3
  
!      Thus the first 6 elements (‘{ 0, 1, 2, 6, 3, 8 }’) are enough to
       determine the whole sequence; we refer to them as the "encoded"
       elements.  They are the only elements present in the square
!      brackets for variable-length ‘const_vector’s (i.e. for
!      ‘const_vector’s whose mode M has a variable number of elements).
       However, as a convenience to code that needs to handle both
!      ‘const_vector’s and ‘parallel’s, all elements are present in the
!      square brackets for fixed-length ‘const_vector’s; the encoding
       scheme simply reduces the amount of work involved in processing
       constants that follow a regular pattern.
  
*************** The simplest RTL expressions are those t
*** 17969,18048 ****
       patterns or (if both encodings have the same number of patterns)
       the one with the fewest encoded elements.
  
!      'const_vector_encoding_nelts (V)' gives the total number of encoded
       elements in V, which is 6 in the example above.
!      'CONST_VECTOR_ENCODED_ELT (V, I)' accesses the value of encoded
       element I.
  
!      'CONST_VECTOR_DUPLICATE_P (V)' is true if V simply contains
!      repeated instances of 'CONST_VECTOR_NPATTERNS (V)' values.  This is
!      a shorthand for testing 'CONST_VECTOR_NELTS_PER_PATTERN (V) == 1'.
  
!      'CONST_VECTOR_STEPPED_P (V)' is true if at least one pattern in V
       has a nonzero step.  This is a shorthand for testing
!      'CONST_VECTOR_NELTS_PER_PATTERN (V) == 3'.
  
!      'CONST_VECTOR_NUNITS (V)' gives the total number of elements in V;
!      it is a shorthand for getting the number of units in 'GET_MODE
!      (V)'.
  
!      The utility function 'const_vector_elt' gives the value of an
!      arbitrary element as an 'rtx'.  'const_vector_int_elt' gives the
!      same value as a 'wide_int'.
  
! '(const_string STR)'
       Represents a constant string with value STR.  Currently this is
       used only for insn attributes (*note Insn Attributes::) since
       constant strings in C are placed in memory.
  
! '(symbol_ref:MODE SYMBOL)'
       Represents the value of an assembler label for data.  SYMBOL is a
       string that describes the name of the assembler label.  If it
!      starts with a '*', the label is the rest of SYMBOL not including
!      the '*'.  Otherwise, the label is SYMBOL, usually prefixed with
!      '_'.
  
!      The 'symbol_ref' contains a mode, which is usually 'Pmode'.
       Usually that is the only mode for which a symbol is directly valid.
  
! '(label_ref:MODE LABEL)'
       Represents the value of an assembler label for code.  It contains
!      one operand, an expression, which must be a 'code_label' or a
!      'note' of type 'NOTE_INSN_DELETED_LABEL' that appears in the
       instruction sequence to identify the place where the label should
       go.
  
       The reason for using a distinct expression type for code label
       references is so that jump optimization can distinguish them.
  
!      The 'label_ref' contains a mode, which is usually 'Pmode'.  Usually
       that is the only mode for which a label is directly valid.
  
! '(const:M EXP)'
       Represents a constant that is the result of an assembly-time
       arithmetic computation.  The operand, EXP, contains only
!      'const_int', 'symbol_ref', 'label_ref' or 'unspec' expressions,
!      combined with 'plus' and 'minus'.  Any such 'unspec's are
       target-specific and typically represent some form of relocation
       operator.  M should be a valid address mode.
  
! '(high:M EXP)'
       Represents the high-order bits of EXP.  The number of bits is
       machine-dependent and is normally the number of bits specified in
       an instruction that initializes the high order bits of a register.
!      It is used with 'lo_sum' to represent the typical two-instruction
       sequence used in RISC machines to reference large immediate values
       and/or link-time constants such as global memory addresses.  In the
!      latter case, M is 'Pmode' and EXP is usually a constant expression
!      involving 'symbol_ref'.
  
!  The macro 'CONST0_RTX (MODE)' refers to an expression with value 0 in
! mode MODE.  If mode MODE is of mode class 'MODE_INT', it returns
! 'const0_rtx'.  If mode MODE is of mode class 'MODE_FLOAT', it returns a
! 'CONST_DOUBLE' expression in mode MODE.  Otherwise, it returns a
! 'CONST_VECTOR' expression in mode MODE.  Similarly, the macro
! 'CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE
! and similarly for 'CONST2_RTX'.  The 'CONST1_RTX' and 'CONST2_RTX'
  macros are undefined for vector modes.
  
  
--- 17969,18048 ----
       patterns or (if both encodings have the same number of patterns)
       the one with the fewest encoded elements.
  
!      ‘const_vector_encoding_nelts (V)’ gives the total number of encoded
       elements in V, which is 6 in the example above.
!      ‘CONST_VECTOR_ENCODED_ELT (V, I)’ accesses the value of encoded
       element I.
  
!      ‘CONST_VECTOR_DUPLICATE_P (V)’ is true if V simply contains
!      repeated instances of ‘CONST_VECTOR_NPATTERNS (V)’ values.  This is
!      a shorthand for testing ‘CONST_VECTOR_NELTS_PER_PATTERN (V) == 1’.
  
!      ‘CONST_VECTOR_STEPPED_P (V)’ is true if at least one pattern in V
       has a nonzero step.  This is a shorthand for testing
!      ‘CONST_VECTOR_NELTS_PER_PATTERN (V) == 3’.
  
!      ‘CONST_VECTOR_NUNITS (V)’ gives the total number of elements in V;
!      it is a shorthand for getting the number of units in ‘GET_MODE
!      (V)’.
  
!      The utility function ‘const_vector_elt’ gives the value of an
!      arbitrary element as an ‘rtx’.  ‘const_vector_int_elt’ gives the
!      same value as a ‘wide_int’.
  
! ‘(const_string STR)’
       Represents a constant string with value STR.  Currently this is
       used only for insn attributes (*note Insn Attributes::) since
       constant strings in C are placed in memory.
  
! ‘(symbol_ref:MODE SYMBOL)’
       Represents the value of an assembler label for data.  SYMBOL is a
       string that describes the name of the assembler label.  If it
!      starts with a ‘*’, the label is the rest of SYMBOL not including
!      the ‘*’.  Otherwise, the label is SYMBOL, usually prefixed with
!      ‘_’.
  
!      The ‘symbol_ref’ contains a mode, which is usually ‘Pmode’.
       Usually that is the only mode for which a symbol is directly valid.
  
! ‘(label_ref:MODE LABEL)’
       Represents the value of an assembler label for code.  It contains
!      one operand, an expression, which must be a ‘code_label’ or a
!      ‘note’ of type ‘NOTE_INSN_DELETED_LABEL’ that appears in the
       instruction sequence to identify the place where the label should
       go.
  
       The reason for using a distinct expression type for code label
       references is so that jump optimization can distinguish them.
  
!      The ‘label_ref’ contains a mode, which is usually ‘Pmode’.  Usually
       that is the only mode for which a label is directly valid.
  
! ‘(const:M EXP)’
       Represents a constant that is the result of an assembly-time
       arithmetic computation.  The operand, EXP, contains only
!      ‘const_int’, ‘symbol_ref’, ‘label_ref’ or ‘unspec’ expressions,
!      combined with ‘plus’ and ‘minus’.  Any such ‘unspec’s are
       target-specific and typically represent some form of relocation
       operator.  M should be a valid address mode.
  
! ‘(high:M EXP)’
       Represents the high-order bits of EXP.  The number of bits is
       machine-dependent and is normally the number of bits specified in
       an instruction that initializes the high order bits of a register.
!      It is used with ‘lo_sum’ to represent the typical two-instruction
       sequence used in RISC machines to reference large immediate values
       and/or link-time constants such as global memory addresses.  In the
!      latter case, M is ‘Pmode’ and EXP is usually a constant expression
!      involving ‘symbol_ref’.
  
!  The macro ‘CONST0_RTX (MODE)’ refers to an expression with value 0 in
! mode MODE.  If mode MODE is of mode class ‘MODE_INT’, it returns
! ‘const0_rtx’.  If mode MODE is of mode class ‘MODE_FLOAT’, it returns a
! ‘CONST_DOUBLE’ expression in mode MODE.  Otherwise, it returns a
! ‘CONST_VECTOR’ expression in mode MODE.  Similarly, the macro
! ‘CONST1_RTX (MODE)’ refers to an expression with value 1 in mode MODE
! and similarly for ‘CONST2_RTX’.  The ‘CONST1_RTX’ and ‘CONST2_RTX’
  macros are undefined for vector modes.
  
  
*************** File: gccint.info,  Node: Regs and Memor
*** 18054,18064 ****
  Here are the RTL expression types for describing access to machine
  registers and to main memory.
  
! '(reg:M N)'
       For small values of the integer N (those that are less than
!      'FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
!      register number N: a "hard register".  For larger values of N, it
!      stands for a temporary value or "pseudo register".  The compiler's
       strategy is to generate code assuming an unlimited number of such
       pseudo registers, and later convert them into hard registers or
       into memory references.
--- 18054,18064 ----
  Here are the RTL expression types for describing access to machine
  registers and to main memory.
  
! ‘(reg:M N)’
       For small values of the integer N (those that are less than
!      ‘FIRST_PSEUDO_REGISTER’), this stands for a reference to machine
!      register number N: a “hard register”.  For larger values of N, it
!      stands for a temporary value or “pseudo register”.  The compiler's
       strategy is to generate code assuming an unlimited number of such
       pseudo registers, and later convert them into hard registers or
       into memory references.
*************** registers and to main memory.
*** 18073,18079 ****
       Even for a register that the machine can access in only one mode,
       the mode must always be specified.
  
!      The symbol 'FIRST_PSEUDO_REGISTER' is defined by the machine
       description, since the number of hard registers on the machine is
       an invariant characteristic of the machine.  Note, however, that
       not all of the machine registers must be general registers.  All
--- 18073,18079 ----
       Even for a register that the machine can access in only one mode,
       the mode must always be specified.
  
!      The symbol ‘FIRST_PSEUDO_REGISTER’ is defined by the machine
       description, since the number of hard registers on the machine is
       an invariant characteristic of the machine.  Note, however, that
       not all of the machine registers must be general registers.  All
*************** registers and to main memory.
*** 18084,18110 ****
       A hard register may be accessed in various modes throughout one
       function, but each pseudo register is given a natural mode and is
       accessed only in that mode.  When it is necessary to describe an
!      access to a pseudo register using a nonnatural mode, a 'subreg'
       expression is used.
  
!      A 'reg' expression with a machine mode that specifies more than one
       word of data may actually stand for several consecutive registers.
       If in addition the register number specifies a hardware register,
       then it actually represents several consecutive hardware registers
       starting with the specified one.
  
       Each pseudo register number used in a function's RTL code is
!      represented by a unique 'reg' expression.
  
       Some pseudo register numbers, those within the range of
!      'FIRST_VIRTUAL_REGISTER' to 'LAST_VIRTUAL_REGISTER' only appear
       during the RTL generation phase and are eliminated before the
       optimization phases.  These represent locations in the stack frame
       that cannot be determined until RTL generation for the function has
       been completed.  The following virtual register numbers are
       defined:
  
!      'VIRTUAL_INCOMING_ARGS_REGNUM'
            This points to the first word of the incoming arguments passed
            on the stack.  Normally these arguments are placed there by
            the caller, but the callee may have pushed some arguments that
--- 18084,18110 ----
       A hard register may be accessed in various modes throughout one
       function, but each pseudo register is given a natural mode and is
       accessed only in that mode.  When it is necessary to describe an
!      access to a pseudo register using a nonnatural mode, a ‘subreg’
       expression is used.
  
!      A ‘reg’ expression with a machine mode that specifies more than one
       word of data may actually stand for several consecutive registers.
       If in addition the register number specifies a hardware register,
       then it actually represents several consecutive hardware registers
       starting with the specified one.
  
       Each pseudo register number used in a function's RTL code is
!      represented by a unique ‘reg’ expression.
  
       Some pseudo register numbers, those within the range of
!      ‘FIRST_VIRTUAL_REGISTER’ to ‘LAST_VIRTUAL_REGISTER’ only appear
       during the RTL generation phase and are eliminated before the
       optimization phases.  These represent locations in the stack frame
       that cannot be determined until RTL generation for the function has
       been completed.  The following virtual register numbers are
       defined:
  
!      ‘VIRTUAL_INCOMING_ARGS_REGNUM’
            This points to the first word of the incoming arguments passed
            on the stack.  Normally these arguments are placed there by
            the caller, but the callee may have pushed some arguments that
*************** registers and to main memory.
*** 18112,18225 ****
  
            When RTL generation is complete, this virtual register is
            replaced by the sum of the register given by
!           'ARG_POINTER_REGNUM' and the value of 'FIRST_PARM_OFFSET'.
  
!      'VIRTUAL_STACK_VARS_REGNUM'
!           If 'FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this
            points to immediately above the first variable on the stack.
            Otherwise, it points to the first variable on the stack.
  
!           'VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the
!           register given by 'FRAME_POINTER_REGNUM' and the value
!           'TARGET_STARTING_FRAME_OFFSET'.
  
!      'VIRTUAL_STACK_DYNAMIC_REGNUM'
            This points to the location of dynamically allocated memory on
            the stack immediately after the stack pointer has been
            adjusted by the amount of memory desired.
  
            This virtual register is replaced by the sum of the register
!           given by 'STACK_POINTER_REGNUM' and the value
!           'STACK_DYNAMIC_OFFSET'.
  
!      'VIRTUAL_OUTGOING_ARGS_REGNUM'
            This points to the location in the stack at which outgoing
            arguments should be written when the stack is pre-pushed
            (arguments pushed using push insns should always use
!           'STACK_POINTER_REGNUM').
  
            This virtual register is replaced by the sum of the register
!           given by 'STACK_POINTER_REGNUM' and the value
!           'STACK_POINTER_OFFSET'.
  
! '(subreg:M1 REG:M2 BYTENUM)'
  
!      'subreg' expressions are used to refer to a register in a machine
       mode other than its natural one, or to refer to one register of a
!      multi-part 'reg' that actually refers to several registers.
  
       Each pseudo register has a natural mode.  If it is necessary to
       operate on it in a different mode, the register must be enclosed in
!      a 'subreg'.
  
       There are currently three supported types for the first operand of
!      a 'subreg':
!         * pseudo registers This is the most common case.  Most 'subreg's
!           have pseudo 'reg's as their first operand.
  
!         * mem 'subreg's of 'mem' were common in earlier versions of GCC
            and are still supported.  During the reload pass these are
!           replaced by plain 'mem's.  On machines that do not do
!           instruction scheduling, use of 'subreg's of 'mem' are still
!           used, but this is no longer recommended.  Such 'subreg's are
!           considered to be 'register_operand's rather than
!           'memory_operand's before and during reload.  Because of this,
            the scheduling passes cannot properly schedule instructions
!           with 'subreg's of 'mem', so for machines that do scheduling,
!           'subreg's of 'mem' should never be used.  To support this, the
            combine and recog passes have explicit code to inhibit the
!           creation of 'subreg's of 'mem' when 'INSN_SCHEDULING' is
            defined.
  
!           The use of 'subreg's of 'mem' after the reload pass is an area
            that is not well understood and should be avoided.  There is
            still some code in the compiler to support this, but this code
!           has possibly rotted.  This use of 'subreg's is discouraged and
            will most likely not be supported in the future.
  
!         * hard registers It is seldom necessary to wrap hard registers
!           in 'subreg's; such registers would normally reduce to a single
!           'reg' rtx.  This use of 'subreg's is discouraged and may not
            be supported in the future.
  
!      'subreg's of 'subreg's are not supported.  Using
!      'simplify_gen_subreg' is the recommended way to avoid this problem.
  
!      'subreg's come in two distinct flavors, each having its own usage
       and rules:
  
       Paradoxical subregs
!           When M1 is strictly wider than M2, the 'subreg' expression is
!           called "paradoxical".  The canonical test for this class of
!           'subreg' is:
  
                 paradoxical_subreg_p (M1, M2)
  
!           Paradoxical 'subreg's can be used as both lvalues and rvalues.
            When used as an lvalue, the low-order bits of the source value
            are stored in REG and the high-order bits are discarded.  When
!           used as an rvalue, the low-order bits of the 'subreg' are
            taken from REG while the high-order bits may or may not be
            defined.
  
            The high-order bits of rvalues are defined in the following
            circumstances:
  
!              * 'subreg's of 'mem' When M2 is smaller than a word, the
!                macro 'LOAD_EXTEND_OP', can control how the high-order
                 bits are defined.
  
!              * 'subreg' of 'reg's The upper bits are defined when
!                'SUBREG_PROMOTED_VAR_P' is true.
!                'SUBREG_PROMOTED_UNSIGNED_P' describes what the upper
                 bits hold.  Such subregs usually represent local
                 variables, register variables and parameter pseudo
                 variables that have been promoted to a wider mode.
  
!           BYTENUM is always zero for a paradoxical 'subreg', even on
            big-endian targets.
  
!           For example, the paradoxical 'subreg':
  
                 (set (subreg:SI (reg:HI X) 0) Y)
  
--- 18112,18225 ----
  
            When RTL generation is complete, this virtual register is
            replaced by the sum of the register given by
!           ‘ARG_POINTER_REGNUM’ and the value of ‘FIRST_PARM_OFFSET’.
  
!      ‘VIRTUAL_STACK_VARS_REGNUM’
!           If ‘FRAME_GROWS_DOWNWARD’ is defined to a nonzero value, this
            points to immediately above the first variable on the stack.
            Otherwise, it points to the first variable on the stack.
  
!           ‘VIRTUAL_STACK_VARS_REGNUM’ is replaced with the sum of the
!           register given by ‘FRAME_POINTER_REGNUM’ and the value
!           ‘TARGET_STARTING_FRAME_OFFSET’.
  
!      ‘VIRTUAL_STACK_DYNAMIC_REGNUM’
            This points to the location of dynamically allocated memory on
            the stack immediately after the stack pointer has been
            adjusted by the amount of memory desired.
  
            This virtual register is replaced by the sum of the register
!           given by ‘STACK_POINTER_REGNUM’ and the value
!           ‘STACK_DYNAMIC_OFFSET’.
  
!      ‘VIRTUAL_OUTGOING_ARGS_REGNUM’
            This points to the location in the stack at which outgoing
            arguments should be written when the stack is pre-pushed
            (arguments pushed using push insns should always use
!           ‘STACK_POINTER_REGNUM’).
  
            This virtual register is replaced by the sum of the register
!           given by ‘STACK_POINTER_REGNUM’ and the value
!           ‘STACK_POINTER_OFFSET’.
  
! ‘(subreg:M1 REG:M2 BYTENUM)’
  
!      ‘subreg’ expressions are used to refer to a register in a machine
       mode other than its natural one, or to refer to one register of a
!      multi-part ‘reg’ that actually refers to several registers.
  
       Each pseudo register has a natural mode.  If it is necessary to
       operate on it in a different mode, the register must be enclosed in
!      a ‘subreg’.
  
       There are currently three supported types for the first operand of
!      a ‘subreg’:
!         • pseudo registers This is the most common case.  Most ‘subreg’s
!           have pseudo ‘reg’s as their first operand.
  
!         • mem ‘subreg’s of ‘mem’ were common in earlier versions of GCC
            and are still supported.  During the reload pass these are
!           replaced by plain ‘mem’s.  On machines that do not do
!           instruction scheduling, use of ‘subreg’s of ‘mem’ are still
!           used, but this is no longer recommended.  Such ‘subreg’s are
!           considered to be ‘register_operand’s rather than
!           ‘memory_operand’s before and during reload.  Because of this,
            the scheduling passes cannot properly schedule instructions
!           with ‘subreg’s of ‘mem’, so for machines that do scheduling,
!           ‘subreg’s of ‘mem’ should never be used.  To support this, the
            combine and recog passes have explicit code to inhibit the
!           creation of ‘subreg’s of ‘mem’ when ‘INSN_SCHEDULING’ is
            defined.
  
!           The use of ‘subreg’s of ‘mem’ after the reload pass is an area
            that is not well understood and should be avoided.  There is
            still some code in the compiler to support this, but this code
!           has possibly rotted.  This use of ‘subreg’s is discouraged and
            will most likely not be supported in the future.
  
!         • hard registers It is seldom necessary to wrap hard registers
!           in ‘subreg’s; such registers would normally reduce to a single
!           ‘reg’ rtx.  This use of ‘subreg’s is discouraged and may not
            be supported in the future.
  
!      ‘subreg’s of ‘subreg’s are not supported.  Using
!      ‘simplify_gen_subreg’ is the recommended way to avoid this problem.
  
!      ‘subreg’s come in two distinct flavors, each having its own usage
       and rules:
  
       Paradoxical subregs
!           When M1 is strictly wider than M2, the ‘subreg’ expression is
!           called “paradoxical”.  The canonical test for this class of
!           ‘subreg’ is:
  
                 paradoxical_subreg_p (M1, M2)
  
!           Paradoxical ‘subreg’s can be used as both lvalues and rvalues.
            When used as an lvalue, the low-order bits of the source value
            are stored in REG and the high-order bits are discarded.  When
!           used as an rvalue, the low-order bits of the ‘subreg’ are
            taken from REG while the high-order bits may or may not be
            defined.
  
            The high-order bits of rvalues are defined in the following
            circumstances:
  
!              • ‘subreg’s of ‘mem’ When M2 is smaller than a word, the
!                macro ‘LOAD_EXTEND_OP’, can control how the high-order
                 bits are defined.
  
!              • ‘subreg’ of ‘reg’s The upper bits are defined when
!                ‘SUBREG_PROMOTED_VAR_P’ is true.
!                ‘SUBREG_PROMOTED_UNSIGNED_P’ describes what the upper
                 bits hold.  Such subregs usually represent local
                 variables, register variables and parameter pseudo
                 variables that have been promoted to a wider mode.
  
!           BYTENUM is always zero for a paradoxical ‘subreg’, even on
            big-endian targets.
  
!           For example, the paradoxical ‘subreg’:
  
                 (set (subreg:SI (reg:HI X) 0) Y)
  
*************** registers and to main memory.
*** 18229,18303 ****
                 (set Z (subreg:SI (reg:HI X) 0))
  
            would set the lower two bytes of Z to Y and set the upper two
!           bytes to an unknown value assuming 'SUBREG_PROMOTED_VAR_P' is
            false.
  
       Normal subregs
!           When M1 is at least as narrow as M2 the 'subreg' expression is
!           called "normal".
  
!           Normal 'subreg's restrict consideration to certain bits of
            REG.  For this purpose, REG is divided into
            individually-addressable blocks in which each block has:
  
                 REGMODE_NATURAL_SIZE (M2)
  
!           bytes.  Usually the value is 'UNITS_PER_WORD'; that is, most
            targets usually treat each word of a register as being
            independently addressable.
  
!           There are two types of normal 'subreg'.  If M1 is known to be
!           no bigger than a block, the 'subreg' refers to the
!           least-significant part (or "lowpart") of one block of REG.  If
!           M1 is known to be larger than a block, the 'subreg' refers to
            two or more complete blocks.
  
!           When used as an lvalue, 'subreg' is a block-based accessor.
!           Storing to a 'subreg' modifies all the blocks of REG that
!           overlap the 'subreg', but it leaves the other blocks of REG
            alone.
  
!           When storing to a normal 'subreg' that is smaller than a
            block, the other bits of the referenced block are usually left
            in an undefined state.  This laxity makes it easier to
            generate efficient code for such instructions.  To represent
            an instruction that preserves all the bits outside of those in
!           the 'subreg', use 'strict_low_part' or 'zero_extract' around
!           the 'subreg'.
  
            BYTENUM must identify the offset of the first byte of the
!           'subreg' from the start of REG, assuming that REG is laid out
            in memory order.  The memory order of bytes is defined by two
!           target macros, 'WORDS_BIG_ENDIAN' and 'BYTES_BIG_ENDIAN':
  
!              * 'WORDS_BIG_ENDIAN', if set to 1, says that byte number
                 zero is part of the most significant word; otherwise, it
                 is part of the least significant word.
  
!              * 'BYTES_BIG_ENDIAN', if set to 1, says that byte number
                 zero is the most significant byte within a word;
                 otherwise, it is the least significant byte within a
                 word.
  
!           On a few targets, 'FLOAT_WORDS_BIG_ENDIAN' disagrees with
!           'WORDS_BIG_ENDIAN'.  However, most parts of the compiler treat
            floating point values as if they had the same endianness as
            integer values.  This works because they handle them solely as
            a collection of integer values, with no particular numerical
            value.  Only real.cc and the runtime libraries care about
!           'FLOAT_WORDS_BIG_ENDIAN'.
  
            Thus,
  
                 (subreg:HI (reg:SI X) 2)
  
!           on a 'BYTES_BIG_ENDIAN', 'UNITS_PER_WORD == 4' target is the
            same as
  
                 (subreg:HI (reg:SI X) 0)
  
!           on a little-endian, 'UNITS_PER_WORD == 4' target.  Both
!           'subreg's access the lower two bytes of register X.
  
            Note that the byte offset is a polynomial integer; it may not
            be a compile-time constant on targets with variable-sized
--- 18229,18303 ----
                 (set Z (subreg:SI (reg:HI X) 0))
  
            would set the lower two bytes of Z to Y and set the upper two
!           bytes to an unknown value assuming ‘SUBREG_PROMOTED_VAR_P’ is
            false.
  
       Normal subregs
!           When M1 is at least as narrow as M2 the ‘subreg’ expression is
!           called “normal”.
  
!           Normal ‘subreg’s restrict consideration to certain bits of
            REG.  For this purpose, REG is divided into
            individually-addressable blocks in which each block has:
  
                 REGMODE_NATURAL_SIZE (M2)
  
!           bytes.  Usually the value is ‘UNITS_PER_WORD’; that is, most
            targets usually treat each word of a register as being
            independently addressable.
  
!           There are two types of normal ‘subreg’.  If M1 is known to be
!           no bigger than a block, the ‘subreg’ refers to the
!           least-significant part (or “lowpart”) of one block of REG.  If
!           M1 is known to be larger than a block, the ‘subreg’ refers to
            two or more complete blocks.
  
!           When used as an lvalue, ‘subreg’ is a block-based accessor.
!           Storing to a ‘subreg’ modifies all the blocks of REG that
!           overlap the ‘subreg’, but it leaves the other blocks of REG
            alone.
  
!           When storing to a normal ‘subreg’ that is smaller than a
            block, the other bits of the referenced block are usually left
            in an undefined state.  This laxity makes it easier to
            generate efficient code for such instructions.  To represent
            an instruction that preserves all the bits outside of those in
!           the ‘subreg’, use ‘strict_low_part’ or ‘zero_extract’ around
!           the ‘subreg’.
  
            BYTENUM must identify the offset of the first byte of the
!           ‘subreg’ from the start of REG, assuming that REG is laid out
            in memory order.  The memory order of bytes is defined by two
!           target macros, ‘WORDS_BIG_ENDIAN’ and ‘BYTES_BIG_ENDIAN’:
  
!              • ‘WORDS_BIG_ENDIAN’, if set to 1, says that byte number
                 zero is part of the most significant word; otherwise, it
                 is part of the least significant word.
  
!              • ‘BYTES_BIG_ENDIAN’, if set to 1, says that byte number
                 zero is the most significant byte within a word;
                 otherwise, it is the least significant byte within a
                 word.
  
!           On a few targets, ‘FLOAT_WORDS_BIG_ENDIAN’ disagrees with
!           ‘WORDS_BIG_ENDIAN’.  However, most parts of the compiler treat
            floating point values as if they had the same endianness as
            integer values.  This works because they handle them solely as
            a collection of integer values, with no particular numerical
            value.  Only real.cc and the runtime libraries care about
!           ‘FLOAT_WORDS_BIG_ENDIAN’.
  
            Thus,
  
                 (subreg:HI (reg:SI X) 2)
  
!           on a ‘BYTES_BIG_ENDIAN’, ‘UNITS_PER_WORD == 4’ target is the
            same as
  
                 (subreg:HI (reg:SI X) 0)
  
!           on a little-endian, ‘UNITS_PER_WORD == 4’ target.  Both
!           ‘subreg’s access the lower two bytes of register X.
  
            Note that the byte offset is a polynomial integer; it may not
            be a compile-time constant on targets with variable-sized
*************** registers and to main memory.
*** 18307,18348 ****
            blocks a valid subreg occupies, and whether the subreg is a
            lowpart of a block.
  
!      A 'MODE_PARTIAL_INT' mode behaves as if it were as wide as the
!      corresponding 'MODE_INT' mode, except that it has a number of
       undefined bits, which are determined by the precision of the mode.
  
!      For example, on a little-endian target which defines 'PSImode' to
       have a precision of 20 bits:
  
            (subreg:PSI (reg:SI 0) 0)
  
!      accesses the low 20 bits of '(reg:SI 0)'.
  
!      Continuing with a 'PSImode' precision of 20 bits, if we assume
!      'REGMODE_NATURAL_SIZE (DImode) <= 4', then the following two
!      'subreg's:
  
            (subreg:PSI (reg:DI 0) 0)
            (subreg:PSI (reg:DI 0) 4)
  
!      represent accesses to the low 20 bits of the two halves of '(reg:DI
!      0)'.
  
!      If 'REGMODE_NATURAL_SIZE (PSImode) <= 2' then these two 'subreg's:
  
            (subreg:HI (reg:PSI 0) 0)
            (subreg:HI (reg:PSI 0) 2)
  
       represent independent 2-byte accesses that together span the whole
!      of '(reg:PSI 0)'.  Storing to the first 'subreg' does not affect
       the value of the second, and vice versa, so the assignment:
  
            (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4))
  
!      sets the low 16 bits of '(reg:PSI 0)' to '(reg:HI 4)', and the high
!      4 defined bits of '(reg:PSI 0)' retain their original value.  The
!      behavior here is the same as for normal 'subreg's, when there are
!      no 'MODE_PARTIAL_INT' modes involved.
  
       The rules above apply to both pseudo REGs and hard REGs.  If the
       semantics are not correct for particular combinations of M1, M2 and
--- 18307,18348 ----
            blocks a valid subreg occupies, and whether the subreg is a
            lowpart of a block.
  
!      A ‘MODE_PARTIAL_INT’ mode behaves as if it were as wide as the
!      corresponding ‘MODE_INT’ mode, except that it has a number of
       undefined bits, which are determined by the precision of the mode.
  
!      For example, on a little-endian target which defines ‘PSImode’ to
       have a precision of 20 bits:
  
            (subreg:PSI (reg:SI 0) 0)
  
!      accesses the low 20 bits of ‘(reg:SI 0)’.
  
!      Continuing with a ‘PSImode’ precision of 20 bits, if we assume
!      ‘REGMODE_NATURAL_SIZE (DImode) <= 4’, then the following two
!      ‘subreg’s:
  
            (subreg:PSI (reg:DI 0) 0)
            (subreg:PSI (reg:DI 0) 4)
  
!      represent accesses to the low 20 bits of the two halves of ‘(reg:DI
!      0)’.
  
!      If ‘REGMODE_NATURAL_SIZE (PSImode) <= 2’ then these two ‘subreg’s:
  
            (subreg:HI (reg:PSI 0) 0)
            (subreg:HI (reg:PSI 0) 2)
  
       represent independent 2-byte accesses that together span the whole
!      of ‘(reg:PSI 0)’.  Storing to the first ‘subreg’ does not affect
       the value of the second, and vice versa, so the assignment:
  
            (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4))
  
!      sets the low 16 bits of ‘(reg:PSI 0)’ to ‘(reg:HI 4)’, and the high
!      4 defined bits of ‘(reg:PSI 0)’ retain their original value.  The
!      behavior here is the same as for normal ‘subreg’s, when there are
!      no ‘MODE_PARTIAL_INT’ modes involved.
  
       The rules above apply to both pseudo REGs and hard REGs.  If the
       semantics are not correct for particular combinations of M1, M2 and
*************** registers and to main memory.
*** 18357,18386 ****
       paradoxical, whether it occupies a whole number of blocks, or
       whether it is a lowpart of a block.  This means that certain
       combinations of variable-sized mode are not permitted.  For
!      example, if M2 holds N 'SI' values, where N is greater than zero,
!      it is not possible to form a 'DI' 'subreg' of it; such a 'subreg'
       would be paradoxical when N is 1 but not when N is greater than 1.
  
!      The first operand of a 'subreg' expression is customarily accessed
!      with the 'SUBREG_REG' macro and the second operand is customarily
!      accessed with the 'SUBREG_BYTE' macro.
  
       It has been several years since a platform in which
!      'BYTES_BIG_ENDIAN' not equal to 'WORDS_BIG_ENDIAN' has been tested.
       Anyone wishing to support such a platform in the future may be
       confronted with code rot.
  
! '(scratch:M)'
       This represents a scratch register that will be required for the
       execution of a single instruction and not used subsequently.  It is
!      converted into a 'reg' by either the local register allocator or
       the reload pass.
  
!      'scratch' is usually present inside a 'clobber' operation (*note
       Side Effects::).
  
       On some machines, the condition code register is given a register
!      number and a 'reg' is used.  Other machines store condition codes
       in general registers; in such cases a pseudo register should be
       used.
  
--- 18357,18386 ----
       paradoxical, whether it occupies a whole number of blocks, or
       whether it is a lowpart of a block.  This means that certain
       combinations of variable-sized mode are not permitted.  For
!      example, if M2 holds N ‘SI’ values, where N is greater than zero,
!      it is not possible to form a ‘DI’ ‘subreg’ of it; such a ‘subreg’
       would be paradoxical when N is 1 but not when N is greater than 1.
  
!      The first operand of a ‘subreg’ expression is customarily accessed
!      with the ‘SUBREG_REG’ macro and the second operand is customarily
!      accessed with the ‘SUBREG_BYTE’ macro.
  
       It has been several years since a platform in which
!      ‘BYTES_BIG_ENDIAN’ not equal to ‘WORDS_BIG_ENDIAN’ has been tested.
       Anyone wishing to support such a platform in the future may be
       confronted with code rot.
  
! ‘(scratch:M)’
       This represents a scratch register that will be required for the
       execution of a single instruction and not used subsequently.  It is
!      converted into a ‘reg’ by either the local register allocator or
       the reload pass.
  
!      ‘scratch’ is usually present inside a ‘clobber’ operation (*note
       Side Effects::).
  
       On some machines, the condition code register is given a register
!      number and a ‘reg’ is used.  Other machines store condition codes
       in general registers; in such cases a pseudo register should be
       used.
  
*************** registers and to main memory.
*** 18389,18430 ****
       the condition code.  This is best handled by normally generating
       the instruction that does not set the condition code, and making a
       pattern that both performs the arithmetic and sets the condition
!      code register.  For examples, search for 'addcc' and 'andcc' in
!      'sparc.md'.
  
! '(pc)'
       This represents the machine's program counter.  It has no operands
!      and may not have a machine mode.  '(pc)' may be validly used only
       in certain specific contexts in jump instructions.
  
!      There is only one expression object of code 'pc'; it is the value
!      of the variable 'pc_rtx'.  Any attempt to create an expression of
!      code 'pc' will return 'pc_rtx'.
  
       All instructions that do not jump alter the program counter
       implicitly by incrementing it, but there is no need to mention this
       in the RTL.
  
! '(mem:M ADDR ALIAS)'
       This RTX represents a reference to main memory at an address
       represented by the expression ADDR.  M specifies how large a unit
       of memory is accessed.  ALIAS specifies an alias set for the
       reference.  In general two items are in different alias sets if
       they cannot reference the same memory address.
  
!      The construct '(mem:BLK (scratch))' is considered to alias all
       other memories.  Thus it may be used as a memory barrier in
       epilogue stack deallocation patterns.
  
! '(concatM RTX RTX)'
       This RTX represents the concatenation of two other RTXs.  This is
       used for complex values.  It should only appear in the RTL attached
       to declarations and during RTL generation.  It should not appear in
       the ordinary insn chain.
  
! '(concatnM [RTX ...])'
       This RTX represents the concatenation of all the RTX to make a
!      single value.  Like 'concat', this should only appear in
       declarations, and not in the insn chain.
  
  
--- 18389,18430 ----
       the condition code.  This is best handled by normally generating
       the instruction that does not set the condition code, and making a
       pattern that both performs the arithmetic and sets the condition
!      code register.  For examples, search for ‘addcc’ and ‘andcc’ in
!      ‘sparc.md’.
  
! ‘(pc)’
       This represents the machine's program counter.  It has no operands
!      and may not have a machine mode.  ‘(pc)’ may be validly used only
       in certain specific contexts in jump instructions.
  
!      There is only one expression object of code ‘pc’; it is the value
!      of the variable ‘pc_rtx’.  Any attempt to create an expression of
!      code ‘pc’ will return ‘pc_rtx’.
  
       All instructions that do not jump alter the program counter
       implicitly by incrementing it, but there is no need to mention this
       in the RTL.
  
! ‘(mem:M ADDR ALIAS)’
       This RTX represents a reference to main memory at an address
       represented by the expression ADDR.  M specifies how large a unit
       of memory is accessed.  ALIAS specifies an alias set for the
       reference.  In general two items are in different alias sets if
       they cannot reference the same memory address.
  
!      The construct ‘(mem:BLK (scratch))’ is considered to alias all
       other memories.  Thus it may be used as a memory barrier in
       epilogue stack deallocation patterns.
  
! ‘(concatM RTX RTX)’
       This RTX represents the concatenation of two other RTXs.  This is
       used for complex values.  It should only appear in the RTL attached
       to declarations and during RTL generation.  It should not appear in
       the ordinary insn chain.
  
! ‘(concatnM [RTX ...])’
       This RTX represents the concatenation of all the RTX to make a
!      single value.  Like ‘concat’, this should only appear in
       declarations, and not in the insn chain.
  
  
*************** File: gccint.info,  Node: Arithmetic,  N
*** 18435,18479 ****
  
  Unless otherwise specified, all the operands of arithmetic expressions
  must be valid for mode M.  An operand is valid for mode M if it has mode
! M, or if it is a 'const_int' or 'const_double' and M is a mode of class
! 'MODE_INT'.
  
   For commutative binary operations, constants should be placed in the
  second operand.
  
! '(plus:M X Y)'
! '(ss_plus:M X Y)'
! '(us_plus:M X Y)'
  
       These three expressions all represent the sum of the values
       represented by X and Y carried out in machine mode M.  They differ
!      in their behavior on overflow of integer modes.  'plus' wraps round
!      modulo the width of M; 'ss_plus' saturates at the maximum signed
!      value representable in M; 'us_plus' saturates at the maximum
       unsigned value.
  
! '(lo_sum:M X Y)'
  
       This expression represents the sum of X and the low-order bits of
!      Y.  It is used with 'high' (*note Constants::) to represent the
       typical two-instruction sequence used in RISC machines to reference
       large immediate values and/or link-time constants such as global
!      memory addresses.  In the latter case, M is 'Pmode' and Y is
!      usually a constant expression involving 'symbol_ref'.
  
       The number of low order bits is machine-dependent but is normally
       the number of bits in mode M minus the number of bits set by
!      'high'.
  
! '(minus:M X Y)'
! '(ss_minus:M X Y)'
! '(us_minus:M X Y)'
  
       These three expressions represent the result of subtracting Y from
       X, carried out in mode M.  Behavior on overflow is the same as for
!      the three variants of 'plus' (see above).
  
! '(compare:M X Y)'
       Represents the result of subtracting Y from X for purposes of
       comparison.  The result is computed without overflow, as if with
       infinite precision.
--- 18435,18479 ----
  
  Unless otherwise specified, all the operands of arithmetic expressions
  must be valid for mode M.  An operand is valid for mode M if it has mode
! M, or if it is a ‘const_int’ or ‘const_double’ and M is a mode of class
! ‘MODE_INT’.
  
   For commutative binary operations, constants should be placed in the
  second operand.
  
! ‘(plus:M X Y)’
! ‘(ss_plus:M X Y)’
! ‘(us_plus:M X Y)’
  
       These three expressions all represent the sum of the values
       represented by X and Y carried out in machine mode M.  They differ
!      in their behavior on overflow of integer modes.  ‘plus’ wraps round
!      modulo the width of M; ‘ss_plus’ saturates at the maximum signed
!      value representable in M; ‘us_plus’ saturates at the maximum
       unsigned value.
  
! ‘(lo_sum:M X Y)’
  
       This expression represents the sum of X and the low-order bits of
!      Y.  It is used with ‘high’ (*note Constants::) to represent the
       typical two-instruction sequence used in RISC machines to reference
       large immediate values and/or link-time constants such as global
!      memory addresses.  In the latter case, M is ‘Pmode’ and Y is
!      usually a constant expression involving ‘symbol_ref’.
  
       The number of low order bits is machine-dependent but is normally
       the number of bits in mode M minus the number of bits set by
!      ‘high’.
  
! ‘(minus:M X Y)’
! ‘(ss_minus:M X Y)’
! ‘(us_minus:M X Y)’
  
       These three expressions represent the result of subtracting Y from
       X, carried out in mode M.  Behavior on overflow is the same as for
!      the three variants of ‘plus’ (see above).
  
! ‘(compare:M X Y)’
       Represents the result of subtracting Y from X for purposes of
       comparison.  The result is computed without overflow, as if with
       infinite precision.
*************** second operand.
*** 18487,18529 ****
  
       The mode M is not related to the modes of X and Y, but instead is
       the mode of the condition code value.  It is some mode in class
!      'MODE_CC', often 'CCmode'.  *Note Condition Code::.  If M is
!      'CCmode', the operation returns sufficient information (in an
       unspecified format) so that any comparison operator can be applied
!      to the result of the 'COMPARE' operation.  For other modes in class
!      'MODE_CC', the operation only returns a subset of this information.
  
!      Normally, X and Y must have the same mode.  Otherwise, 'compare' is
!      valid only if the mode of X is in class 'MODE_INT' and Y is a
!      'const_int' or 'const_double' with mode 'VOIDmode'.  The mode of X
       determines what mode the comparison is to be done in; thus it must
!      not be 'VOIDmode'.
  
       If one of the operands is a constant, it should be placed in the
       second operand and the comparison code adjusted as appropriate.
  
!      A 'compare' specifying two 'VOIDmode' constants is not valid since
       there is no way to know in what mode the comparison is to be
       performed; the comparison must either be folded during the
       compilation or the first operand must be loaded into a register
       while its mode is still known.
  
! '(neg:M X)'
! '(ss_neg:M X)'
! '(us_neg:M X)'
       These two expressions represent the negation (subtraction from
       zero) of the value represented by X, carried out in mode M.  They
       differ in the behavior on overflow of integer modes.  In the case
!      of 'neg', the negation of the operand may be a number not
       representable in mode M, in which case it is truncated to M.
!      'ss_neg' and 'us_neg' ensure that an out-of-bounds result saturates
       to the maximum or minimum signed or unsigned value.
  
! '(mult:M X Y)'
! '(ss_mult:M X Y)'
! '(us_mult:M X Y)'
       Represents the signed product of the values represented by X and Y
!      carried out in machine mode M.  'ss_mult' and 'us_mult' ensure that
       an out-of-bounds result saturates to the maximum or minimum signed
       or unsigned value.
  
--- 18487,18529 ----
  
       The mode M is not related to the modes of X and Y, but instead is
       the mode of the condition code value.  It is some mode in class
!      ‘MODE_CC’, often ‘CCmode’.  *Note Condition Code::.  If M is
!      ‘CCmode’, the operation returns sufficient information (in an
       unspecified format) so that any comparison operator can be applied
!      to the result of the ‘COMPARE’ operation.  For other modes in class
!      ‘MODE_CC’, the operation only returns a subset of this information.
  
!      Normally, X and Y must have the same mode.  Otherwise, ‘compare’ is
!      valid only if the mode of X is in class ‘MODE_INT’ and Y is a
!      ‘const_int’ or ‘const_double’ with mode ‘VOIDmode’.  The mode of X
       determines what mode the comparison is to be done in; thus it must
!      not be ‘VOIDmode’.
  
       If one of the operands is a constant, it should be placed in the
       second operand and the comparison code adjusted as appropriate.
  
!      A ‘compare’ specifying two ‘VOIDmode’ constants is not valid since
       there is no way to know in what mode the comparison is to be
       performed; the comparison must either be folded during the
       compilation or the first operand must be loaded into a register
       while its mode is still known.
  
! ‘(neg:M X)’
! ‘(ss_neg:M X)’
! ‘(us_neg:M X)’
       These two expressions represent the negation (subtraction from
       zero) of the value represented by X, carried out in mode M.  They
       differ in the behavior on overflow of integer modes.  In the case
!      of ‘neg’, the negation of the operand may be a number not
       representable in mode M, in which case it is truncated to M.
!      ‘ss_neg’ and ‘us_neg’ ensure that an out-of-bounds result saturates
       to the maximum or minimum signed or unsigned value.
  
! ‘(mult:M X Y)’
! ‘(ss_mult:M X Y)’
! ‘(us_mult:M X Y)’
       Represents the signed product of the values represented by X and Y
!      carried out in machine mode M.  ‘ss_mult’ and ‘us_mult’ ensure that
       an out-of-bounds result saturates to the maximum or minimum signed
       or unsigned value.
  
*************** second operand.
*** 18536,18688 ****
       same.
  
       For unsigned widening multiplication, use the same idiom, but with
!      'zero_extend' instead of 'sign_extend'.
  
! '(smul_highpart:M X Y)'
! '(umul_highpart:M X Y)'
       Represents the high-part multiplication of X and Y carried out in
!      machine mode M.  'smul_highpart' returns the high part of a signed
!      multiplication, 'umul_highpart' returns the high part of an
       unsigned multiplication.
  
! '(fma:M X Y Z)'
!      Represents the 'fma', 'fmaf', and 'fmal' builtin functions, which
!      compute 'X * Y + Z' without doing an intermediate rounding step.
  
! '(div:M X Y)'
! '(ss_div:M X Y)'
       Represents the quotient in signed division of X by Y, carried out
       in machine mode M.  If M is a floating point mode, it represents
!      the exact quotient; otherwise, the integerized quotient.  'ss_div'
       ensures that an out-of-bounds result saturates to the maximum or
       minimum signed value.
  
       Some machines have division instructions in which the operands and
       quotient widths are not all the same; you should represent such
!      instructions using 'truncate' and 'sign_extend' as in,
  
            (truncate:M1 (div:M2 X (sign_extend:M2 Y)))
  
! '(udiv:M X Y)'
! '(us_div:M X Y)'
!      Like 'div' but represents unsigned division.  'us_div' ensures that
       an out-of-bounds result saturates to the maximum or minimum
       unsigned value.
  
! '(mod:M X Y)'
! '(umod:M X Y)'
!      Like 'div' and 'udiv' but represent the remainder instead of the
       quotient.
  
! '(smin:M X Y)'
! '(smax:M X Y)'
!      Represents the smaller (for 'smin') or larger (for 'smax') of X and
       Y, interpreted as signed values in mode M.  When used with floating
!      point, if both operands are zeros, or if either operand is 'NaN',
       then it is unspecified which of the two operands is returned as the
       result.
  
! '(umin:M X Y)'
! '(umax:M X Y)'
!      Like 'smin' and 'smax', but the values are interpreted as unsigned
       integers.
  
! '(not:M X)'
       Represents the bitwise complement of the value represented by X,
       carried out in mode M, which must be a fixed-point machine mode.
  
! '(and:M X Y)'
       Represents the bitwise logical-and of the values represented by X
       and Y, carried out in machine mode M, which must be a fixed-point
       machine mode.
  
! '(ior:M X Y)'
       Represents the bitwise inclusive-or of the values represented by X
       and Y, carried out in machine mode M, which must be a fixed-point
       mode.
  
! '(xor:M X Y)'
       Represents the bitwise exclusive-or of the values represented by X
       and Y, carried out in machine mode M, which must be a fixed-point
       mode.
  
! '(ashift:M X C)'
! '(ss_ashift:M X C)'
! '(us_ashift:M X C)'
       These three expressions represent the result of arithmetically
       shifting X left by C places.  They differ in their behavior on
!      overflow of integer modes.  An 'ashift' operation is a plain shift
       with no special behavior in case of a change in the sign bit;
!      'ss_ashift' and 'us_ashift' saturates to the minimum or maximum
       representable value if any of the bits shifted out differs from the
       final sign bit.
  
       X have mode M, a fixed-point machine mode.  C be a fixed-point mode
!      or be a constant with mode 'VOIDmode'; which mode is determined by
       the mode called for in the machine description entry for the
       left-shift instruction.  For example, on the VAX, the mode of C is
!      'QImode' regardless of M.
  
! '(lshiftrt:M X C)'
! '(ashiftrt:M X C)'
!      Like 'ashift' but for right shift.  Unlike the case for left shift,
       these two operations are distinct.
  
! '(rotate:M X C)'
! '(rotatert:M X C)'
       Similar but represent left and right rotate.  If C is a constant,
!      use 'rotate'.
  
! '(abs:M X)'
! '(ss_abs:M X)'
!      Represents the absolute value of X, computed in mode M.  'ss_abs'
       ensures that an out-of-bounds result saturates to the maximum
       signed value.
  
! '(sqrt:M X)'
       Represents the square root of X, computed in mode M.  Most often M
       will be a floating point mode.
  
! '(ffs:M X)'
       Represents one plus the index of the least significant 1-bit in X,
       represented as an integer of mode M.  (The value is zero if X is
!      zero.)  The mode of X must be M or 'VOIDmode'.
  
! '(clrsb:M X)'
       Represents the number of redundant leading sign bits in X,
       represented as an integer of mode M, starting at the most
       significant bit position.  This is one less than the number of
       leading sign bits (either 0 or 1), with no special cases.  The mode
!      of X must be M or 'VOIDmode'.
  
! '(clz:M X)'
       Represents the number of leading 0-bits in X, represented as an
       integer of mode M, starting at the most significant bit position.
       If X is zero, the value is determined by
!      'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::).  Note that this is one
       of the few expressions that is not invariant under widening.  The
!      mode of X must be M or 'VOIDmode'.
  
! '(ctz:M X)'
       Represents the number of trailing 0-bits in X, represented as an
       integer of mode M, starting at the least significant bit position.
       If X is zero, the value is determined by
!      'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::).  Except for this case,
!      'ctz(x)' is equivalent to 'ffs(X) - 1'.  The mode of X must be M or
!      'VOIDmode'.
  
! '(popcount:M X)'
       Represents the number of 1-bits in X, represented as an integer of
!      mode M.  The mode of X must be M or 'VOIDmode'.
  
! '(parity:M X)'
       Represents the number of 1-bits modulo 2 in X, represented as an
!      integer of mode M.  The mode of X must be M or 'VOIDmode'.
  
! '(bswap:M X)'
       Represents the value X with the order of bytes reversed, carried
       out in mode M, which must be a fixed-point machine mode.  The mode
!      of X must be M or 'VOIDmode'.
  
  
  File: gccint.info,  Node: Comparisons,  Next: Bit-Fields,  Prev: Arithmetic,  Up: RTL
--- 18536,18688 ----
       same.
  
       For unsigned widening multiplication, use the same idiom, but with
!      ‘zero_extend’ instead of ‘sign_extend’.
  
! ‘(smul_highpart:M X Y)’
! ‘(umul_highpart:M X Y)’
       Represents the high-part multiplication of X and Y carried out in
!      machine mode M.  ‘smul_highpart’ returns the high part of a signed
!      multiplication, ‘umul_highpart’ returns the high part of an
       unsigned multiplication.
  
! ‘(fma:M X Y Z)’
!      Represents the ‘fma’, ‘fmaf’, and ‘fmal’ builtin functions, which
!      compute ‘X * Y + Z’ without doing an intermediate rounding step.
  
! ‘(div:M X Y)’
! ‘(ss_div:M X Y)’
       Represents the quotient in signed division of X by Y, carried out
       in machine mode M.  If M is a floating point mode, it represents
!      the exact quotient; otherwise, the integerized quotient.  ‘ss_div’
       ensures that an out-of-bounds result saturates to the maximum or
       minimum signed value.
  
       Some machines have division instructions in which the operands and
       quotient widths are not all the same; you should represent such
!      instructions using ‘truncate’ and ‘sign_extend’ as in,
  
            (truncate:M1 (div:M2 X (sign_extend:M2 Y)))
  
! ‘(udiv:M X Y)’
! ‘(us_div:M X Y)’
!      Like ‘div’ but represents unsigned division.  ‘us_div’ ensures that
       an out-of-bounds result saturates to the maximum or minimum
       unsigned value.
  
! ‘(mod:M X Y)’
! ‘(umod:M X Y)’
!      Like ‘div’ and ‘udiv’ but represent the remainder instead of the
       quotient.
  
! ‘(smin:M X Y)’
! ‘(smax:M X Y)’
!      Represents the smaller (for ‘smin’) or larger (for ‘smax’) of X and
       Y, interpreted as signed values in mode M.  When used with floating
!      point, if both operands are zeros, or if either operand is ‘NaN’,
       then it is unspecified which of the two operands is returned as the
       result.
  
! ‘(umin:M X Y)’
! ‘(umax:M X Y)’
!      Like ‘smin’ and ‘smax’, but the values are interpreted as unsigned
       integers.
  
! ‘(not:M X)’
       Represents the bitwise complement of the value represented by X,
       carried out in mode M, which must be a fixed-point machine mode.
  
! ‘(and:M X Y)’
       Represents the bitwise logical-and of the values represented by X
       and Y, carried out in machine mode M, which must be a fixed-point
       machine mode.
  
! ‘(ior:M X Y)’
       Represents the bitwise inclusive-or of the values represented by X
       and Y, carried out in machine mode M, which must be a fixed-point
       mode.
  
! ‘(xor:M X Y)’
       Represents the bitwise exclusive-or of the values represented by X
       and Y, carried out in machine mode M, which must be a fixed-point
       mode.
  
! ‘(ashift:M X C)’
! ‘(ss_ashift:M X C)’
! ‘(us_ashift:M X C)’
       These three expressions represent the result of arithmetically
       shifting X left by C places.  They differ in their behavior on
!      overflow of integer modes.  An ‘ashift’ operation is a plain shift
       with no special behavior in case of a change in the sign bit;
!      ‘ss_ashift’ and ‘us_ashift’ saturates to the minimum or maximum
       representable value if any of the bits shifted out differs from the
       final sign bit.
  
       X have mode M, a fixed-point machine mode.  C be a fixed-point mode
!      or be a constant with mode ‘VOIDmode’; which mode is determined by
       the mode called for in the machine description entry for the
       left-shift instruction.  For example, on the VAX, the mode of C is
!      ‘QImode’ regardless of M.
  
! ‘(lshiftrt:M X C)’
! ‘(ashiftrt:M X C)’
!      Like ‘ashift’ but for right shift.  Unlike the case for left shift,
       these two operations are distinct.
  
! ‘(rotate:M X C)’
! ‘(rotatert:M X C)’
       Similar but represent left and right rotate.  If C is a constant,
!      use ‘rotate’.
  
! ‘(abs:M X)’
! ‘(ss_abs:M X)’
!      Represents the absolute value of X, computed in mode M.  ‘ss_abs’
       ensures that an out-of-bounds result saturates to the maximum
       signed value.
  
! ‘(sqrt:M X)’
       Represents the square root of X, computed in mode M.  Most often M
       will be a floating point mode.
  
! ‘(ffs:M X)’
       Represents one plus the index of the least significant 1-bit in X,
       represented as an integer of mode M.  (The value is zero if X is
!      zero.)  The mode of X must be M or ‘VOIDmode’.
  
! ‘(clrsb:M X)’
       Represents the number of redundant leading sign bits in X,
       represented as an integer of mode M, starting at the most
       significant bit position.  This is one less than the number of
       leading sign bits (either 0 or 1), with no special cases.  The mode
!      of X must be M or ‘VOIDmode’.
  
! ‘(clz:M X)’
       Represents the number of leading 0-bits in X, represented as an
       integer of mode M, starting at the most significant bit position.
       If X is zero, the value is determined by
!      ‘CLZ_DEFINED_VALUE_AT_ZERO’ (*note Misc::).  Note that this is one
       of the few expressions that is not invariant under widening.  The
!      mode of X must be M or ‘VOIDmode’.
  
! ‘(ctz:M X)’
       Represents the number of trailing 0-bits in X, represented as an
       integer of mode M, starting at the least significant bit position.
       If X is zero, the value is determined by
!      ‘CTZ_DEFINED_VALUE_AT_ZERO’ (*note Misc::).  Except for this case,
!      ‘ctz(x)’ is equivalent to ‘ffs(X) - 1’.  The mode of X must be M or
!      ‘VOIDmode’.
  
! ‘(popcount:M X)’
       Represents the number of 1-bits in X, represented as an integer of
!      mode M.  The mode of X must be M or ‘VOIDmode’.
  
! ‘(parity:M X)’
       Represents the number of 1-bits modulo 2 in X, represented as an
!      integer of mode M.  The mode of X must be M or ‘VOIDmode’.
  
! ‘(bswap:M X)’
       Represents the value X with the order of bytes reversed, carried
       out in mode M, which must be a fixed-point machine mode.  The mode
!      of X must be M or ‘VOIDmode’.
  
  
  File: gccint.info,  Node: Comparisons,  Next: Bit-Fields,  Prev: Arithmetic,  Up: RTL
*************** File: gccint.info,  Node: Comparisons,
*** 18692,18708 ****
  
  Comparison operators test a relation on two operands and are considered
  to represent a machine-dependent nonzero value described by, but not
! necessarily equal to, 'STORE_FLAG_VALUE' (*note Misc::) if the relation
  holds, or zero if it does not, for comparison operators whose results
! have a 'MODE_INT' mode, 'FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the
  relation holds, or zero if it does not, for comparison operators that
  return floating-point values, and a vector of either
! 'VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of
  zeros if it does not, for comparison operators that return vector
  results.  The mode of the comparison operation is independent of the
  mode of the data being compared.  If the comparison operation is being
! tested (e.g., the first operand of an 'if_then_else'), the mode must be
! 'VOIDmode'.
  
   A comparison operation compares two data objects.  The mode of the
  comparison is determined by the operands; they must both be valid for a
--- 18692,18708 ----
  
  Comparison operators test a relation on two operands and are considered
  to represent a machine-dependent nonzero value described by, but not
! necessarily equal to, ‘STORE_FLAG_VALUE’ (*note Misc::) if the relation
  holds, or zero if it does not, for comparison operators whose results
! have a 'MODE_INT' mode, ‘FLOAT_STORE_FLAG_VALUE’ (*note Misc::) if the
  relation holds, or zero if it does not, for comparison operators that
  return floating-point values, and a vector of either
! ‘VECTOR_STORE_FLAG_VALUE’ (*note Misc::) if the relation holds, or of
  zeros if it does not, for comparison operators that return vector
  results.  The mode of the comparison operation is independent of the
  mode of the data being compared.  If the comparison operation is being
! tested (e.g., the first operand of an ‘if_then_else’), the mode must be
! ‘VOIDmode’.
  
   A comparison operation compares two data objects.  The mode of the
  comparison is determined by the operands; they must both be valid for a
*************** comparison should never exist in RTL due
*** 18712,18771 ****
  
   Usually only one style of comparisons is supported on a particular
  machine, but the combine pass will try to merge operations to produce
! code like '(eq X Y)', in case it exists in the context of the particular
  insn involved.
  
   Inequality comparisons come in two flavors, signed and unsigned.  Thus,
! there are distinct expression codes 'gt' and 'gtu' for signed and
  unsigned greater-than.  These can produce different results for the same
! pair of integer values: for example, 1 is signed greater-than -1 but not
! unsigned greater-than, because -1 when regarded as unsigned is actually
! '0xffffffff' which is greater than 1.
  
   The signed comparisons are also used for floating point values.
  Floating point comparisons are distinguished by the machine modes of the
  operands.
  
! '(eq:M X Y)'
!      'STORE_FLAG_VALUE' if the values represented by X and Y are equal,
       otherwise 0.
  
! '(ne:M X Y)'
!      'STORE_FLAG_VALUE' if the values represented by X and Y are not
       equal, otherwise 0.
  
! '(gt:M X Y)'
!      'STORE_FLAG_VALUE' if the X is greater than Y.  If they are
       fixed-point, the comparison is done in a signed sense.
  
! '(gtu:M X Y)'
!      Like 'gt' but does unsigned comparison, on fixed-point numbers
       only.
  
! '(lt:M X Y)'
! '(ltu:M X Y)'
!      Like 'gt' and 'gtu' but test for "less than".
  
! '(ge:M X Y)'
! '(geu:M X Y)'
!      Like 'gt' and 'gtu' but test for "greater than or equal".
  
! '(le:M X Y)'
! '(leu:M X Y)'
!      Like 'gt' and 'gtu' but test for "less than or equal".
  
! '(if_then_else COND THEN ELSE)'
       This is not a comparison operation but is listed here because it is
       always used in conjunction with a comparison operation.  To be
       precise, COND is a comparison expression.  This expression
       represents a choice, according to COND, between the value
       represented by THEN and the one represented by ELSE.
  
!      On most machines, 'if_then_else' expressions are valid only to
       express conditional jumps.
  
! '(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)'
!      Similar to 'if_then_else', but more general.  Each of TEST1, TEST2,
       ... is performed in turn.  The result of this expression is the
       VALUE corresponding to the first nonzero test, or DEFAULT if none
       of the tests are nonzero expressions.
--- 18712,18771 ----
  
   Usually only one style of comparisons is supported on a particular
  machine, but the combine pass will try to merge operations to produce
! code like ‘(eq X Y)’, in case it exists in the context of the particular
  insn involved.
  
   Inequality comparisons come in two flavors, signed and unsigned.  Thus,
! there are distinct expression codes ‘gt’ and ‘gtu’ for signed and
  unsigned greater-than.  These can produce different results for the same
! pair of integer values: for example, 1 is signed greater-than −1 but not
! unsigned greater-than, because −1 when regarded as unsigned is actually
! ‘0xffffffff’ which is greater than 1.
  
   The signed comparisons are also used for floating point values.
  Floating point comparisons are distinguished by the machine modes of the
  operands.
  
! ‘(eq:M X Y)’
!      ‘STORE_FLAG_VALUE’ if the values represented by X and Y are equal,
       otherwise 0.
  
! ‘(ne:M X Y)’
!      ‘STORE_FLAG_VALUE’ if the values represented by X and Y are not
       equal, otherwise 0.
  
! ‘(gt:M X Y)’
!      ‘STORE_FLAG_VALUE’ if the X is greater than Y.  If they are
       fixed-point, the comparison is done in a signed sense.
  
! ‘(gtu:M X Y)’
!      Like ‘gt’ but does unsigned comparison, on fixed-point numbers
       only.
  
! ‘(lt:M X Y)’
! ‘(ltu:M X Y)’
!      Like ‘gt’ and ‘gtu’ but test for "less than".
  
! ‘(ge:M X Y)’
! ‘(geu:M X Y)’
!      Like ‘gt’ and ‘gtu’ but test for "greater than or equal".
  
! ‘(le:M X Y)’
! ‘(leu:M X Y)’
!      Like ‘gt’ and ‘gtu’ but test for "less than or equal".
  
! ‘(if_then_else COND THEN ELSE)’
       This is not a comparison operation but is listed here because it is
       always used in conjunction with a comparison operation.  To be
       precise, COND is a comparison expression.  This expression
       represents a choice, according to COND, between the value
       represented by THEN and the one represented by ELSE.
  
!      On most machines, ‘if_then_else’ expressions are valid only to
       express conditional jumps.
  
! ‘(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)’
!      Similar to ‘if_then_else’, but more general.  Each of TEST1, TEST2,
       ... is performed in turn.  The result of this expression is the
       VALUE corresponding to the first nonzero test, or DEFAULT if none
       of the tests are nonzero expressions.
*************** File: gccint.info,  Node: Bit-Fields,  N
*** 18781,18814 ****
  
  Special expression codes exist to represent bit-field instructions.
  
! '(sign_extract:M LOC SIZE POS)'
       This represents a reference to a sign-extended bit-field contained
       or starting in LOC (a memory or register reference).  The bit-field
       is SIZE bits wide and starts at bit POS.  The compilation option
!      'BITS_BIG_ENDIAN' says which end of the memory unit POS counts
       from.
  
       If LOC is in memory, its mode must be a single-byte integer mode.
       If LOC is in a register, the mode to use is specified by the
!      operand of the 'insv' or 'extv' pattern (*note Standard Names::)
       and is usually a full-word integer mode, which is the default if
       none is specified.
  
       The mode of POS is machine-specific and is also specified in the
!      'insv' or 'extv' pattern.
  
       The mode M is the same as the mode that would be used for LOC if it
       were a register.
  
!      A 'sign_extract' cannot appear as an lvalue, or part thereof, in
       RTL.
  
! '(zero_extract:M LOC SIZE POS)'
!      Like 'sign_extract' but refers to an unsigned or zero-extended
       bit-field.  The same sequence of bits are extracted, but they are
       filled to an entire word with zeros instead of by sign-extension.
  
!      Unlike 'sign_extract', this type of expressions can be lvalues in
       RTL; they may appear on the left side of an assignment, indicating
       insertion of a value into the specified bit-field.
  
--- 18781,18814 ----
  
  Special expression codes exist to represent bit-field instructions.
  
! ‘(sign_extract:M LOC SIZE POS)’
       This represents a reference to a sign-extended bit-field contained
       or starting in LOC (a memory or register reference).  The bit-field
       is SIZE bits wide and starts at bit POS.  The compilation option
!      ‘BITS_BIG_ENDIAN’ says which end of the memory unit POS counts
       from.
  
       If LOC is in memory, its mode must be a single-byte integer mode.
       If LOC is in a register, the mode to use is specified by the
!      operand of the ‘insv’ or ‘extv’ pattern (*note Standard Names::)
       and is usually a full-word integer mode, which is the default if
       none is specified.
  
       The mode of POS is machine-specific and is also specified in the
!      ‘insv’ or ‘extv’ pattern.
  
       The mode M is the same as the mode that would be used for LOC if it
       were a register.
  
!      A ‘sign_extract’ cannot appear as an lvalue, or part thereof, in
       RTL.
  
! ‘(zero_extract:M LOC SIZE POS)’
!      Like ‘sign_extract’ but refers to an unsigned or zero-extended
       bit-field.  The same sequence of bits are extracted, but they are
       filled to an entire word with zeros instead of by sign-extension.
  
!      Unlike ‘sign_extract’, this type of expressions can be lvalues in
       RTL; they may appear on the left side of an assignment, indicating
       insertion of a value into the specified bit-field.
  
*************** interpreted as operating on each part of
*** 18823,18861 ****
  Additionally, there are a few new expressions to describe specific
  vector operations.
  
! '(vec_merge:M VEC1 VEC2 ITEMS)'
       This describes a merge operation between two vectors.  The result
       is a vector of mode M; its elements are selected from either VEC1
       or VEC2.  Which elements are selected is described by ITEMS, which
!      is a bit mask represented by a 'const_int'; a zero bit indicates
       the corresponding element in the result vector is taken from VEC2
       while a set bit indicates it is taken from VEC1.
  
! '(vec_select:M VEC1 SELECTION)'
       This describes an operation that selects parts of a vector.  VEC1
!      is the source vector, and SELECTION is a 'parallel' that contains a
!      'const_int' (or another expression, if the selection can be made at
       runtime) for each of the subparts of the result vector, giving the
       number of the source subpart that should be stored into it.  The
       result mode M is either the submode for a single element of VEC1
       (if only one subpart is selected), or another vector mode with that
       element submode (if multiple subparts are selected).
  
! '(vec_concat:M X1 X2)'
       Describes a vector concat operation.  The result is a concatenation
       of the vectors or scalars X1 and X2; its length is the sum of the
       lengths of the two inputs.
  
! '(vec_duplicate:M X)'
       This operation converts a scalar into a vector or a small vector
       into a larger one by duplicating the input values.  The output
       vector mode must have the same submodes as the input vector mode or
       the scalar modes, and the number of output parts must be an integer
       multiple of the number of input parts.
  
! '(vec_series:M BASE STEP)'
       This operation creates a vector in which element I is equal to
!      'BASE + I*STEP'.  M must be a vector integer mode.
  
  
  File: gccint.info,  Node: Conversions,  Next: RTL Declarations,  Prev: Vector Operations,  Up: RTL
--- 18823,18861 ----
  Additionally, there are a few new expressions to describe specific
  vector operations.
  
! ‘(vec_merge:M VEC1 VEC2 ITEMS)’
       This describes a merge operation between two vectors.  The result
       is a vector of mode M; its elements are selected from either VEC1
       or VEC2.  Which elements are selected is described by ITEMS, which
!      is a bit mask represented by a ‘const_int’; a zero bit indicates
       the corresponding element in the result vector is taken from VEC2
       while a set bit indicates it is taken from VEC1.
  
! ‘(vec_select:M VEC1 SELECTION)’
       This describes an operation that selects parts of a vector.  VEC1
!      is the source vector, and SELECTION is a ‘parallel’ that contains a
!      ‘const_int’ (or another expression, if the selection can be made at
       runtime) for each of the subparts of the result vector, giving the
       number of the source subpart that should be stored into it.  The
       result mode M is either the submode for a single element of VEC1
       (if only one subpart is selected), or another vector mode with that
       element submode (if multiple subparts are selected).
  
! ‘(vec_concat:M X1 X2)’
       Describes a vector concat operation.  The result is a concatenation
       of the vectors or scalars X1 and X2; its length is the sum of the
       lengths of the two inputs.
  
! ‘(vec_duplicate:M X)’
       This operation converts a scalar into a vector or a small vector
       into a larger one by duplicating the input values.  The output
       vector mode must have the same submodes as the input vector mode or
       the scalar modes, and the number of output parts must be an integer
       multiple of the number of input parts.
  
! ‘(vec_series:M BASE STEP)’
       This operation creates a vector in which element I is equal to
!      ‘BASE + I*STEP’.  M must be a vector integer mode.
  
  
  File: gccint.info,  Node: Conversions,  Next: RTL Declarations,  Prev: Vector Operations,  Up: RTL
*************** File: gccint.info,  Node: Conversions,
*** 18865,18872 ****
  
  All conversions between machine modes must be represented by explicit
  conversion operations.  For example, an expression which is the sum of a
! byte and a full word cannot be written as '(plus:SI (reg:QI 34) (reg:SI
! 80))' because the 'plus' operation requires two operands of the same
  machine mode.  Therefore, the byte-sized operand is enclosed in a
  conversion operation, as in
  
--- 18865,18872 ----
  
  All conversions between machine modes must be represented by explicit
  conversion operations.  For example, an expression which is the sum of a
! byte and a full word cannot be written as ‘(plus:SI (reg:QI 34) (reg:SI
! 80))’ because the ‘plus’ operation requires two operands of the same
  machine mode.  Therefore, the byte-sized operand is enclosed in a
  conversion operation, as in
  
*************** conversion operation, as in
*** 18876,18929 ****
  be more than one way of converting from a given starting mode to the
  desired final mode.  The conversion operation code says how to do it.
  
!  For all conversion operations, X must not be 'VOIDmode' because the
  mode in which to do the conversion would not be known.  The conversion
  must either be done at compile-time or X must be placed into a register.
  
! '(sign_extend:M X)'
       Represents the result of sign-extending the value X to machine mode
       M.  M must be a fixed-point mode and X a fixed-point value of a
       mode narrower than M.
  
! '(zero_extend:M X)'
       Represents the result of zero-extending the value X to machine mode
       M.  M must be a fixed-point mode and X a fixed-point value of a
       mode narrower than M.
  
! '(float_extend:M X)'
       Represents the result of extending the value X to machine mode M.
       M must be a floating point mode and X a floating point value of a
       mode narrower than M.
  
! '(truncate:M X)'
       Represents the result of truncating the value X to machine mode M.
       M must be a fixed-point mode and X a fixed-point value of a mode
       wider than M.
  
! '(ss_truncate:M X)'
       Represents the result of truncating the value X to machine mode M,
       using signed saturation in the case of overflow.  Both M and the
       mode of X must be fixed-point modes.
  
! '(us_truncate:M X)'
       Represents the result of truncating the value X to machine mode M,
       using unsigned saturation in the case of overflow.  Both M and the
       mode of X must be fixed-point modes.
  
! '(float_truncate:M X)'
       Represents the result of truncating the value X to machine mode M.
       M must be a floating point mode and X a floating point value of a
       mode wider than M.
  
! '(float:M X)'
       Represents the result of converting fixed point value X, regarded
       as signed, to floating point mode M.
  
! '(unsigned_float:M X)'
       Represents the result of converting fixed point value X, regarded
       as unsigned, to floating point mode M.
  
! '(fix:M X)'
       When M is a floating-point mode, represents the result of
       converting floating point value X (valid for mode M) to an integer,
       still represented in floating point mode M, by rounding towards
--- 18876,18929 ----
  be more than one way of converting from a given starting mode to the
  desired final mode.  The conversion operation code says how to do it.
  
!  For all conversion operations, X must not be ‘VOIDmode’ because the
  mode in which to do the conversion would not be known.  The conversion
  must either be done at compile-time or X must be placed into a register.
  
! ‘(sign_extend:M X)’
       Represents the result of sign-extending the value X to machine mode
       M.  M must be a fixed-point mode and X a fixed-point value of a
       mode narrower than M.
  
! ‘(zero_extend:M X)’
       Represents the result of zero-extending the value X to machine mode
       M.  M must be a fixed-point mode and X a fixed-point value of a
       mode narrower than M.
  
! ‘(float_extend:M X)’
       Represents the result of extending the value X to machine mode M.
       M must be a floating point mode and X a floating point value of a
       mode narrower than M.
  
! ‘(truncate:M X)’
       Represents the result of truncating the value X to machine mode M.
       M must be a fixed-point mode and X a fixed-point value of a mode
       wider than M.
  
! ‘(ss_truncate:M X)’
       Represents the result of truncating the value X to machine mode M,
       using signed saturation in the case of overflow.  Both M and the
       mode of X must be fixed-point modes.
  
! ‘(us_truncate:M X)’
       Represents the result of truncating the value X to machine mode M,
       using unsigned saturation in the case of overflow.  Both M and the
       mode of X must be fixed-point modes.
  
! ‘(float_truncate:M X)’
       Represents the result of truncating the value X to machine mode M.
       M must be a floating point mode and X a floating point value of a
       mode wider than M.
  
! ‘(float:M X)’
       Represents the result of converting fixed point value X, regarded
       as signed, to floating point mode M.
  
! ‘(unsigned_float:M X)’
       Represents the result of converting fixed point value X, regarded
       as unsigned, to floating point mode M.
  
! ‘(fix:M X)’
       When M is a floating-point mode, represents the result of
       converting floating point value X (valid for mode M) to an integer,
       still represented in floating point mode M, by rounding towards
*************** must either be done at compile-time or X
*** 18934,18945 ****
       is done is not specified, so this operation may be used validly in
       compiling C code only for integer-valued operands.
  
! '(unsigned_fix:M X)'
       Represents the result of converting floating point value X to fixed
       point mode M, regarded as unsigned.  How rounding is done is not
       specified.
  
! '(fract_convert:M X)'
       Represents the result of converting fixed-point value X to
       fixed-point mode M, signed integer value X to fixed-point mode M,
       floating-point value X to fixed-point mode M, fixed-point value X
--- 18934,18945 ----
       is done is not specified, so this operation may be used validly in
       compiling C code only for integer-valued operands.
  
! ‘(unsigned_fix:M X)’
       Represents the result of converting floating point value X to fixed
       point mode M, regarded as unsigned.  How rounding is done is not
       specified.
  
! ‘(fract_convert:M X)’
       Represents the result of converting fixed-point value X to
       fixed-point mode M, signed integer value X to fixed-point mode M,
       floating-point value X to fixed-point mode M, fixed-point value X
*************** must either be done at compile-time or X
*** 18947,18966 ****
       floating-point mode M.  When overflows or underflows happen, the
       results are undefined.
  
! '(sat_fract:M X)'
       Represents the result of converting fixed-point value X to
       fixed-point mode M, signed integer value X to fixed-point mode M,
       or floating-point value X to fixed-point mode M.  When overflows or
       underflows happen, the results are saturated to the maximum or the
       minimum.
  
! '(unsigned_fract_convert:M X)'
       Represents the result of converting fixed-point value X to integer
       mode M regarded as unsigned, or unsigned integer value X to
       fixed-point mode M.  When overflows or underflows happen, the
       results are undefined.
  
! '(unsigned_sat_fract:M X)'
       Represents the result of converting unsigned integer value X to
       fixed-point mode M.  When overflows or underflows happen, the
       results are saturated to the maximum or the minimum.
--- 18947,18966 ----
       floating-point mode M.  When overflows or underflows happen, the
       results are undefined.
  
! ‘(sat_fract:M X)’
       Represents the result of converting fixed-point value X to
       fixed-point mode M, signed integer value X to fixed-point mode M,
       or floating-point value X to fixed-point mode M.  When overflows or
       underflows happen, the results are saturated to the maximum or the
       minimum.
  
! ‘(unsigned_fract_convert:M X)’
       Represents the result of converting fixed-point value X to integer
       mode M regarded as unsigned, or unsigned integer value X to
       fixed-point mode M.  When overflows or underflows happen, the
       results are undefined.
  
! ‘(unsigned_sat_fract:M X)’
       Represents the result of converting unsigned integer value X to
       fixed-point mode M.  When overflows or underflows happen, the
       results are saturated to the maximum or the minimum.
*************** File: gccint.info,  Node: RTL Declaratio
*** 18974,18990 ****
  Declaration expression codes do not represent arithmetic operations but
  rather state assertions about their operands.
  
! '(strict_low_part (subreg:M (reg:N R) 0))'
       This expression code is used in only one context: as the
!      destination operand of a 'set' expression.  In addition, the
!      operand of this expression must be a non-paradoxical 'subreg'
       expression.
  
!      The presence of 'strict_low_part' says that the part of the
       register which is meaningful in mode N, but is not part of mode M,
       is not to be altered.  Normally, an assignment to such a subreg is
       allowed to have undefined effects on the rest of the register when
!      M is smaller than 'REGMODE_NATURAL_SIZE (N)'.
  
  
  File: gccint.info,  Node: Side Effects,  Next: Incdec,  Prev: RTL Declarations,  Up: RTL
--- 18974,18990 ----
  Declaration expression codes do not represent arithmetic operations but
  rather state assertions about their operands.
  
! ‘(strict_low_part (subreg:M (reg:N R) 0))’
       This expression code is used in only one context: as the
!      destination operand of a ‘set’ expression.  In addition, the
!      operand of this expression must be a non-paradoxical ‘subreg’
       expression.
  
!      The presence of ‘strict_low_part’ says that the part of the
       register which is meaningful in mode N, but is not part of mode M,
       is not to be altered.  Normally, an assignment to such a subreg is
       allowed to have undefined effects on the rest of the register when
!      M is smaller than ‘REGMODE_NATURAL_SIZE (N)’.
  
  
  File: gccint.info,  Node: Side Effects,  Next: Incdec,  Prev: RTL Declarations,  Up: RTL
*************** codes are used to represent side effects
*** 19001,19094 ****
  the codes described above, which represent values, appear only as the
  operands of these.
  
! '(set LVAL X)'
       Represents the action of storing the value of X into the place
       represented by LVAL.  LVAL must be an expression representing a
!      place that can be stored in: 'reg' (or 'subreg', 'strict_low_part'
!      or 'zero_extract'), 'mem', 'pc', or 'parallel'.
  
!      If LVAL is a 'reg', 'subreg' or 'mem', it has a machine mode; then
       X must be valid for that mode.
  
!      If LVAL is a 'reg' whose machine mode is less than the full width
       of the register, then it means that the part of the register
       specified by the machine mode is given the specified value and the
       rest of the register receives an undefined value.  Likewise, if
!      LVAL is a 'subreg' whose machine mode is narrower than the mode of
       the register, the rest of the register can be changed in an
       undefined way.
  
!      If LVAL is a 'strict_low_part' of a subreg, then the part of the
!      register specified by the machine mode of the 'subreg' is given the
       value X and the rest of the register is not changed.
  
!      If LVAL is a 'zero_extract', then the referenced part of the
       bit-field (a memory or register reference) specified by the
!      'zero_extract' is given the value X and the rest of the bit-field
!      is not changed.  Note that 'sign_extract' cannot appear in LVAL.
  
!      If LVAL is a 'parallel', it is used to represent the case of a
       function returning a structure in multiple registers.  Each element
!      of the 'parallel' is an 'expr_list' whose first operand is a 'reg'
!      and whose second operand is a 'const_int' representing the offset
       (in bytes) into the structure at which the data in that register
       corresponds.  The first element may be null to indicate that the
       structure is also passed partly in memory.
  
!      If LVAL is '(pc)', we have a jump instruction, and the
!      possibilities for X are very limited.  It may be a 'label_ref'
!      expression (unconditional jump).  It may be an 'if_then_else'
       (conditional jump), in which case either the second or the third
!      operand must be '(pc)' (for the case which does not jump) and the
!      other of the two must be a 'label_ref' (for the case which does
!      jump).  X may also be a 'mem' or '(plus:SI (pc) Y)', where Y may be
!      a 'reg' or a 'mem'; these unusual patterns are used to represent
       jumps through branch tables.
  
!      If LVAL is not '(pc)', the mode of LVAL must not be 'VOIDmode' and
       the mode of X must be valid for the mode of LVAL.
  
!      LVAL is customarily accessed with the 'SET_DEST' macro and X with
!      the 'SET_SRC' macro.
  
! '(return)'
       As the sole expression in a pattern, represents a return from the
       current function, on machines where this can be done with one
       instruction, such as VAXen.  On machines where a multi-instruction
       "epilogue" must be executed in order to return from the function,
       returning is done by jumping to a label which precedes the
!      epilogue, and the 'return' expression code is never used.
  
!      Inside an 'if_then_else' expression, represents the value to be
!      placed in 'pc' to return to the caller.
  
!      Note that an insn pattern of '(return)' is logically equivalent to
!      '(set (pc) (return))', but the latter form is never used.
  
! '(simple_return)'
!      Like '(return)', but truly represents only a function return, while
!      '(return)' may represent an insn that also performs other functions
!      of the function epilogue.  Like '(return)', this may also occur in
       conditional jumps.
  
! '(call FUNCTION NARGS)'
!      Represents a function call.  FUNCTION is a 'mem' expression whose
       address is the address of the function to be called.  NARGS is an
       expression which can be used for two purposes: on some machines it
       represents the number of bytes of stack argument; on others, it
       represents the number of argument registers.
  
       Each machine has a standard machine mode which FUNCTION must have.
!      The machine description defines macro 'FUNCTION_MODE' to expand
       into the requisite mode name.  The purpose of this mode is to
       specify what kind of addressing is allowed, on machines where the
       allowed kinds of addressing depend on the machine mode being
       addressed.
  
! '(clobber X)'
       Represents the storing or possible storing of an unpredictable,
!      undescribed value into X, which must be a 'reg', 'scratch',
!      'parallel' or 'mem' expression.
  
       One place this is used is in string instructions that store
       standard values into particular hard registers.  It may not be
--- 19001,19094 ----
  the codes described above, which represent values, appear only as the
  operands of these.
  
! ‘(set LVAL X)’
       Represents the action of storing the value of X into the place
       represented by LVAL.  LVAL must be an expression representing a
!      place that can be stored in: ‘reg’ (or ‘subreg’, ‘strict_low_part’
!      or ‘zero_extract’), ‘mem’, ‘pc’, or ‘parallel’.
  
!      If LVAL is a ‘reg’, ‘subreg’ or ‘mem’, it has a machine mode; then
       X must be valid for that mode.
  
!      If LVAL is a ‘reg’ whose machine mode is less than the full width
       of the register, then it means that the part of the register
       specified by the machine mode is given the specified value and the
       rest of the register receives an undefined value.  Likewise, if
!      LVAL is a ‘subreg’ whose machine mode is narrower than the mode of
       the register, the rest of the register can be changed in an
       undefined way.
  
!      If LVAL is a ‘strict_low_part’ of a subreg, then the part of the
!      register specified by the machine mode of the ‘subreg’ is given the
       value X and the rest of the register is not changed.
  
!      If LVAL is a ‘zero_extract’, then the referenced part of the
       bit-field (a memory or register reference) specified by the
!      ‘zero_extract’ is given the value X and the rest of the bit-field
!      is not changed.  Note that ‘sign_extract’ cannot appear in LVAL.
  
!      If LVAL is a ‘parallel’, it is used to represent the case of a
       function returning a structure in multiple registers.  Each element
!      of the ‘parallel’ is an ‘expr_list’ whose first operand is a ‘reg’
!      and whose second operand is a ‘const_int’ representing the offset
       (in bytes) into the structure at which the data in that register
       corresponds.  The first element may be null to indicate that the
       structure is also passed partly in memory.
  
!      If LVAL is ‘(pc)’, we have a jump instruction, and the
!      possibilities for X are very limited.  It may be a ‘label_ref’
!      expression (unconditional jump).  It may be an ‘if_then_else’
       (conditional jump), in which case either the second or the third
!      operand must be ‘(pc)’ (for the case which does not jump) and the
!      other of the two must be a ‘label_ref’ (for the case which does
!      jump).  X may also be a ‘mem’ or ‘(plus:SI (pc) Y)’, where Y may be
!      a ‘reg’ or a ‘mem’; these unusual patterns are used to represent
       jumps through branch tables.
  
!      If LVAL is not ‘(pc)’, the mode of LVAL must not be ‘VOIDmode’ and
       the mode of X must be valid for the mode of LVAL.
  
!      LVAL is customarily accessed with the ‘SET_DEST’ macro and X with
!      the ‘SET_SRC’ macro.
  
! ‘(return)’
       As the sole expression in a pattern, represents a return from the
       current function, on machines where this can be done with one
       instruction, such as VAXen.  On machines where a multi-instruction
       "epilogue" must be executed in order to return from the function,
       returning is done by jumping to a label which precedes the
!      epilogue, and the ‘return’ expression code is never used.
  
!      Inside an ‘if_then_else’ expression, represents the value to be
!      placed in ‘pc’ to return to the caller.
  
!      Note that an insn pattern of ‘(return)’ is logically equivalent to
!      ‘(set (pc) (return))’, but the latter form is never used.
  
! ‘(simple_return)’
!      Like ‘(return)’, but truly represents only a function return, while
!      ‘(return)’ may represent an insn that also performs other functions
!      of the function epilogue.  Like ‘(return)’, this may also occur in
       conditional jumps.
  
! ‘(call FUNCTION NARGS)’
!      Represents a function call.  FUNCTION is a ‘mem’ expression whose
       address is the address of the function to be called.  NARGS is an
       expression which can be used for two purposes: on some machines it
       represents the number of bytes of stack argument; on others, it
       represents the number of argument registers.
  
       Each machine has a standard machine mode which FUNCTION must have.
!      The machine description defines macro ‘FUNCTION_MODE’ to expand
       into the requisite mode name.  The purpose of this mode is to
       specify what kind of addressing is allowed, on machines where the
       allowed kinds of addressing depend on the machine mode being
       addressed.
  
! ‘(clobber X)’
       Represents the storing or possible storing of an unpredictable,
!      undescribed value into X, which must be a ‘reg’, ‘scratch’,
!      ‘parallel’ or ‘mem’ expression.
  
       One place this is used is in string instructions that store
       standard values into particular hard registers.  It may not be
*************** operands of these.
*** 19097,19118 ****
       altered, lest it attempt to keep data in them across the string
       instruction.
  
!      If X is '(mem:BLK (const_int 0))' or '(mem:BLK (scratch))', it
       means that all memory locations must be presumed clobbered.  If X
!      is a 'parallel', it has the same meaning as a 'parallel' in a 'set'
       expression.
  
       Note that the machine description classifies certain hard registers
       as "call-clobbered".  All function call instructions are assumed by
       default to clobber these registers, so there is no need to use
!      'clobber' expressions to indicate this fact.  Also, each function
       call is assumed to have the potential to alter any memory location,
!      unless the function is declared 'const'.
  
!      If the last group of expressions in a 'parallel' are each a
!      'clobber' expression whose arguments are 'reg' or 'match_scratch'
       (*note RTL Template::) expressions, the combiner phase can add the
!      appropriate 'clobber' expressions to an insn it has constructed
       when doing so will cause a pattern to be matched.
  
       This feature can be used, for example, on a machine that whose
--- 19097,19118 ----
       altered, lest it attempt to keep data in them across the string
       instruction.
  
!      If X is ‘(mem:BLK (const_int 0))’ or ‘(mem:BLK (scratch))’, it
       means that all memory locations must be presumed clobbered.  If X
!      is a ‘parallel’, it has the same meaning as a ‘parallel’ in a ‘set’
       expression.
  
       Note that the machine description classifies certain hard registers
       as "call-clobbered".  All function call instructions are assumed by
       default to clobber these registers, so there is no need to use
!      ‘clobber’ expressions to indicate this fact.  Also, each function
       call is assumed to have the potential to alter any memory location,
!      unless the function is declared ‘const’.
  
!      If the last group of expressions in a ‘parallel’ are each a
!      ‘clobber’ expression whose arguments are ‘reg’ or ‘match_scratch’
       (*note RTL Template::) expressions, the combiner phase can add the
!      appropriate ‘clobber’ expressions to an insn it has constructed
       when doing so will cause a pattern to be matched.
  
       This feature can be used, for example, on a machine that whose
*************** operands of these.
*** 19121,19161 ****
       register.  Similarly, a combined instruction might require a
       temporary register while the constituent instructions might not.
  
!      When a 'clobber' expression for a register appears inside a
!      'parallel' with other side effects, the register allocator
       guarantees that the register is unoccupied both before and after
       that insn if it is a hard register clobber.  For pseudo-register
       clobber, the register allocator and the reload pass do not assign
       the same hard register to the clobber and the input operands if
!      there is an insn alternative containing the '&' constraint (*note
       Modifiers::) for the clobber and the hard register is in register
       classes of the clobber in the alternative.  You can clobber either
!      a specific hard register, a pseudo register, or a 'scratch'
       expression; in the latter two cases, GCC will allocate a hard
       register that is available there for use as a temporary.
  
       For instructions that require a temporary register, you should use
!      'scratch' instead of a pseudo-register because this will allow the
!      combiner phase to add the 'clobber' when required.  You do this by
!      coding ('clobber' ('match_scratch' ...)).  If you do clobber a
       pseudo register, use one which appears nowhere else--generate a new
       one each time.  Otherwise, you may confuse CSE.
  
       There is one other known use for clobbering a pseudo register in a
!      'parallel': when one of the input operands of the insn is also
       clobbered by the insn.  In this case, using the same pseudo
       register in the clobber and elsewhere in the insn produces the
       expected results.
  
! '(use X)'
       Represents the use of the value of X.  It indicates that the value
       in X at this point in the program is needed, even though it may not
       be apparent why this is so.  Therefore, the compiler will not
       attempt to delete previous instructions whose only effect is to
!      store a value in X.  X must be a 'reg' expression.
  
!      In some situations, it may be tempting to add a 'use' of a register
!      in a 'parallel' to describe a situation where the value of a
       special register will modify the behavior of the instruction.  A
       hypothetical example might be a pattern for an addition that can
       either wrap around or use saturating addition depending on the
--- 19121,19161 ----
       register.  Similarly, a combined instruction might require a
       temporary register while the constituent instructions might not.
  
!      When a ‘clobber’ expression for a register appears inside a
!      ‘parallel’ with other side effects, the register allocator
       guarantees that the register is unoccupied both before and after
       that insn if it is a hard register clobber.  For pseudo-register
       clobber, the register allocator and the reload pass do not assign
       the same hard register to the clobber and the input operands if
!      there is an insn alternative containing the ‘&’ constraint (*note
       Modifiers::) for the clobber and the hard register is in register
       classes of the clobber in the alternative.  You can clobber either
!      a specific hard register, a pseudo register, or a ‘scratch’
       expression; in the latter two cases, GCC will allocate a hard
       register that is available there for use as a temporary.
  
       For instructions that require a temporary register, you should use
!      ‘scratch’ instead of a pseudo-register because this will allow the
!      combiner phase to add the ‘clobber’ when required.  You do this by
!      coding (‘clobber’ (‘match_scratch’ ...)).  If you do clobber a
       pseudo register, use one which appears nowhere else--generate a new
       one each time.  Otherwise, you may confuse CSE.
  
       There is one other known use for clobbering a pseudo register in a
!      ‘parallel’: when one of the input operands of the insn is also
       clobbered by the insn.  In this case, using the same pseudo
       register in the clobber and elsewhere in the insn produces the
       expected results.
  
! ‘(use X)’
       Represents the use of the value of X.  It indicates that the value
       in X at this point in the program is needed, even though it may not
       be apparent why this is so.  Therefore, the compiler will not
       attempt to delete previous instructions whose only effect is to
!      store a value in X.  X must be a ‘reg’ expression.
  
!      In some situations, it may be tempting to add a ‘use’ of a register
!      in a ‘parallel’ to describe a situation where the value of a
       special register will modify the behavior of the instruction.  A
       hypothetical example might be a pattern for an addition that can
       either wrap around or use saturating addition depending on the
*************** operands of these.
*** 19165,19200 ****
                                                   (reg:SI 4)] 0))
                       (use (reg:SI 1))])
  
- 
       This will not work, several of the optimizers only look at
       expressions locally; it is very likely that if you have multiple
!      insns with identical inputs to the 'unspec', they will be optimized
       away even if register 1 changes in between.
  
!      This means that 'use' can _only_ be used to describe that the
!      register is live.  You should think twice before adding 'use'
!      statements, more often you will want to use 'unspec' instead.  The
!      'use' RTX is most commonly useful to describe that a fixed register
       is implicitly used in an insn.  It is also safe to use in patterns
       where the compiler knows for other reasons that the result of the
!      whole pattern is variable, such as 'cpymemM' or 'call' patterns.
  
!      During the reload phase, an insn that has a 'use' as pattern can
!      carry a reg_equal note.  These 'use' insns will be deleted before
       the reload phase exits.
  
       During the delayed branch scheduling phase, X may be an insn.  This
       indicates that X previously was located at this place in the code
       and its data dependencies need to be taken into account.  These
!      'use' insns will be deleted before the delayed branch scheduling
       phase exits.
  
! '(parallel [X0 X1 ...])'
       Represents several side effects performed in parallel.  The square
!      brackets stand for a vector; the operand of 'parallel' is a vector
       of expressions.  X0, X1 and so on are individual side effect
!      expressions--expressions of code 'set', 'call', 'return',
!      'simple_return', 'clobber' or 'use'.
  
       "In parallel" means that first all the values used in the
       individual side-effects are computed, and second all the actual
--- 19165,19199 ----
                                                   (reg:SI 4)] 0))
                       (use (reg:SI 1))])
  
       This will not work, several of the optimizers only look at
       expressions locally; it is very likely that if you have multiple
!      insns with identical inputs to the ‘unspec’, they will be optimized
       away even if register 1 changes in between.
  
!      This means that ‘use’ can _only_ be used to describe that the
!      register is live.  You should think twice before adding ‘use’
!      statements, more often you will want to use ‘unspec’ instead.  The
!      ‘use’ RTX is most commonly useful to describe that a fixed register
       is implicitly used in an insn.  It is also safe to use in patterns
       where the compiler knows for other reasons that the result of the
!      whole pattern is variable, such as ‘cpymemM’ or ‘call’ patterns.
  
!      During the reload phase, an insn that has a ‘use’ as pattern can
!      carry a reg_equal note.  These ‘use’ insns will be deleted before
       the reload phase exits.
  
       During the delayed branch scheduling phase, X may be an insn.  This
       indicates that X previously was located at this place in the code
       and its data dependencies need to be taken into account.  These
!      ‘use’ insns will be deleted before the delayed branch scheduling
       phase exits.
  
! ‘(parallel [X0 X1 ...])’
       Represents several side effects performed in parallel.  The square
!      brackets stand for a vector; the operand of ‘parallel’ is a vector
       of expressions.  X0, X1 and so on are individual side effect
!      expressions--expressions of code ‘set’, ‘call’, ‘return’,
!      ‘simple_return’, ‘clobber’ or ‘use’.
  
       "In parallel" means that first all the values used in the
       individual side-effects are computed, and second all the actual
*************** operands of these.
*** 19205,19215 ****
  
       says unambiguously that the values of hard register 1 and the
       memory location addressed by it are interchanged.  In both places
!      where '(reg:SI 1)' appears as a memory address it refers to the
       value in register 1 _before_ the execution of the insn.
  
!      It follows that it is _incorrect_ to use 'parallel' and expect the
!      result of one 'set' to be available for the next one.  For example,
       people sometimes attempt to represent a jump-if-zero instruction
       this way:
  
--- 19204,19214 ----
  
       says unambiguously that the values of hard register 1 and the
       memory location addressed by it are interchanged.  In both places
!      where ‘(reg:SI 1)’ appears as a memory address it refers to the
       value in register 1 _before_ the execution of the insn.
  
!      It follows that it is _incorrect_ to use ‘parallel’ and expect the
!      result of one ‘set’ to be available for the next one.  For example,
       people sometimes attempt to represent a jump-if-zero instruction
       this way:
  
*************** operands of these.
*** 19225,19299 ****
  
       Peephole optimization, which takes place together with final
       assembly code output, can produce insns whose patterns consist of a
!      'parallel' whose elements are the operands needed to output the
!      resulting assembler code--often 'reg', 'mem' or constant
       expressions.  This would not be well-formed RTL at any other stage
       in compilation, but it is OK then because no further optimization
       remains to be done.
  
! '(cond_exec [COND EXPR])'
       Represents a conditionally executed expression.  The EXPR is
       executed only if the COND is nonzero.  The COND expression must not
       have side-effects, but the EXPR may very well have side-effects.
  
! '(sequence [INSNS ...])'
!      Represents a sequence of insns.  If a 'sequence' appears in the
       chain of insns, then each of the INSNS that appears in the sequence
       must be suitable for appearing in the chain of insns, i.e. must
!      satisfy the 'INSN_P' predicate.
  
       After delay-slot scheduling is completed, an insn and all the insns
       that reside in its delay slots are grouped together into a
!      'sequence'.  The insn requiring the delay slot is the first insn in
       the vector; subsequent insns are to be placed in the delay slot.
  
!      'INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to
       indicate that a branch insn should be used that will conditionally
       annul the effect of the insns in the delay slots.  In such a case,
!      'INSN_FROM_TARGET_P' indicates that the insn is from the target of
       the branch and should be executed only if the branch is taken;
       otherwise the insn should be executed only if the branch is not
       taken.  *Note Delay Slots::.
  
!      Some back ends also use 'sequence' objects for purposes other than
       delay-slot groups.  This is not supported in the common parts of
       the compiler, which treat such sequences as delay-slot groups.
  
       DWARF2 Call Frame Address (CFA) adjustments are sometimes also
!      expressed using 'sequence' objects as the value of a
!      'RTX_FRAME_RELATED_P' note.  This only happens if the CFA
       adjustments cannot be easily derived from the pattern of the
       instruction to which the note is attached.  In such cases, the
       value of the note is used instead of best-guesing the semantics of
       the instruction.  The back end can attach notes containing a
!      'sequence' of 'set' patterns that express the effect of the parent
       instruction.
  
   These expression codes appear in place of a side effect, as the body of
  an insn, though strictly speaking they do not always describe side
  effects as such:
  
! '(asm_input S)'
       Represents literal assembler code as described by the string S.
  
! '(unspec [OPERANDS ...] INDEX)'
! '(unspec_volatile [OPERANDS ...] INDEX)'
       Represents a machine-specific operation on OPERANDS.  INDEX selects
!      between multiple machine-specific operations.  'unspec_volatile' is
!      used for volatile operations and operations that may trap; 'unspec'
       is used for other operations.
  
!      These codes may appear inside a 'pattern' of an insn, inside a
!      'parallel', or inside an expression.
  
! '(addr_vec:M [LR0 LR1 ...])'
       Represents a table of jump addresses.  The vector elements LR0,
!      etc., are 'label_ref' expressions.  The mode M specifies how much
!      space is given to each address; normally M would be 'Pmode'.
  
! '(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)'
       Represents a table of jump addresses expressed as offsets from
!      BASE.  The vector elements LR0, etc., are 'label_ref' expressions
       and so is BASE.  The mode M specifies how much space is given to
       each address-difference.  MIN and MAX are set up by branch
       shortening and hold a label with a minimum and a maximum address,
--- 19224,19298 ----
  
       Peephole optimization, which takes place together with final
       assembly code output, can produce insns whose patterns consist of a
!      ‘parallel’ whose elements are the operands needed to output the
!      resulting assembler code--often ‘reg’, ‘mem’ or constant
       expressions.  This would not be well-formed RTL at any other stage
       in compilation, but it is OK then because no further optimization
       remains to be done.
  
! ‘(cond_exec [COND EXPR])’
       Represents a conditionally executed expression.  The EXPR is
       executed only if the COND is nonzero.  The COND expression must not
       have side-effects, but the EXPR may very well have side-effects.
  
! ‘(sequence [INSNS ...])’
!      Represents a sequence of insns.  If a ‘sequence’ appears in the
       chain of insns, then each of the INSNS that appears in the sequence
       must be suitable for appearing in the chain of insns, i.e. must
!      satisfy the ‘INSN_P’ predicate.
  
       After delay-slot scheduling is completed, an insn and all the insns
       that reside in its delay slots are grouped together into a
!      ‘sequence’.  The insn requiring the delay slot is the first insn in
       the vector; subsequent insns are to be placed in the delay slot.
  
!      ‘INSN_ANNULLED_BRANCH_P’ is set on an insn in a delay slot to
       indicate that a branch insn should be used that will conditionally
       annul the effect of the insns in the delay slots.  In such a case,
!      ‘INSN_FROM_TARGET_P’ indicates that the insn is from the target of
       the branch and should be executed only if the branch is taken;
       otherwise the insn should be executed only if the branch is not
       taken.  *Note Delay Slots::.
  
!      Some back ends also use ‘sequence’ objects for purposes other than
       delay-slot groups.  This is not supported in the common parts of
       the compiler, which treat such sequences as delay-slot groups.
  
       DWARF2 Call Frame Address (CFA) adjustments are sometimes also
!      expressed using ‘sequence’ objects as the value of a
!      ‘RTX_FRAME_RELATED_P’ note.  This only happens if the CFA
       adjustments cannot be easily derived from the pattern of the
       instruction to which the note is attached.  In such cases, the
       value of the note is used instead of best-guesing the semantics of
       the instruction.  The back end can attach notes containing a
!      ‘sequence’ of ‘set’ patterns that express the effect of the parent
       instruction.
  
   These expression codes appear in place of a side effect, as the body of
  an insn, though strictly speaking they do not always describe side
  effects as such:
  
! ‘(asm_input S)’
       Represents literal assembler code as described by the string S.
  
! ‘(unspec [OPERANDS ...] INDEX)’
! ‘(unspec_volatile [OPERANDS ...] INDEX)’
       Represents a machine-specific operation on OPERANDS.  INDEX selects
!      between multiple machine-specific operations.  ‘unspec_volatile’ is
!      used for volatile operations and operations that may trap; ‘unspec’
       is used for other operations.
  
!      These codes may appear inside a ‘pattern’ of an insn, inside a
!      ‘parallel’, or inside an expression.
  
! ‘(addr_vec:M [LR0 LR1 ...])’
       Represents a table of jump addresses.  The vector elements LR0,
!      etc., are ‘label_ref’ expressions.  The mode M specifies how much
!      space is given to each address; normally M would be ‘Pmode’.
  
! ‘(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)’
       Represents a table of jump addresses expressed as offsets from
!      BASE.  The vector elements LR0, etc., are ‘label_ref’ expressions
       and so is BASE.  The mode M specifies how much space is given to
       each address-difference.  MIN and MAX are set up by branch
       shortening and hold a label with a minimum and a maximum address,
*************** effects as such:
*** 19301,19307 ****
       and MAX to the containing insn and of MIN and MAX to BASE.  See
       rtl.def for details.
  
! '(prefetch:M ADDR RW LOCALITY)'
       Represents prefetch of memory at address ADDR.  Operand RW is 1 if
       the prefetch is for data to be written, 0 otherwise; targets that
       do not support write prefetches should treat this as a normal
--- 19300,19306 ----
       and MAX to the containing insn and of MIN and MAX to BASE.  See
       rtl.def for details.
  
! ‘(prefetch:M ADDR RW LOCALITY)’
       Represents prefetch of memory at address ADDR.  Operand RW is 1 if
       the prefetch is for data to be written, 0 otherwise; targets that
       do not support write prefetches should treat this as a normal
*************** File: gccint.info,  Node: Incdec,  Next:
*** 19322,19331 ****
  
  Six special side-effect expression codes appear as memory addresses.
  
! '(pre_dec:M X)'
       Represents the side effect of decrementing X by a standard amount
       and represents also the value that X has after being decremented.
!      X must be a 'reg' or 'mem', but most machines allow only a 'reg'.
       M must be the machine mode for pointers on the machine in use.  The
       amount X is decremented by is the length in bytes of the machine
       mode of the containing memory reference of which this expression
--- 19321,19330 ----
  
  Six special side-effect expression codes appear as memory addresses.
  
! ‘(pre_dec:M X)’
       Represents the side effect of decrementing X by a standard amount
       and represents also the value that X has after being decremented.
!      X must be a ‘reg’ or ‘mem’, but most machines allow only a ‘reg’.
       M must be the machine mode for pointers on the machine in use.  The
       amount X is decremented by is the length in bytes of the machine
       mode of the containing memory reference of which this expression
*************** Six special side-effect expression codes
*** 19334,19361 ****
            (mem:DF (pre_dec:SI (reg:SI 39)))
  
       This says to decrement pseudo register 39 by the length of a
!      'DFmode' value and use the result to address a 'DFmode' value.
  
! '(pre_inc:M X)'
       Similar, but specifies incrementing X instead of decrementing it.
  
! '(post_dec:M X)'
!      Represents the same side effect as 'pre_dec' but a different value.
       The value represented here is the value X has before being
       decremented.
  
! '(post_inc:M X)'
       Similar, but specifies incrementing X instead of decrementing it.
  
! '(post_modify:M X Y)'
  
       Represents the side effect of setting X to Y and represents X
!      before X is modified.  X must be a 'reg' or 'mem', but most
!      machines allow only a 'reg'.  M must be the machine mode for
       pointers on the machine in use.
  
!      The expression Y must be one of three forms: '(plus:M X Z)',
!      '(minus:M X Z)', or '(plus:M X I)', where Z is an index register
       and I is a constant.
  
       Here is an example of its use:
--- 19333,19360 ----
            (mem:DF (pre_dec:SI (reg:SI 39)))
  
       This says to decrement pseudo register 39 by the length of a
!      ‘DFmode’ value and use the result to address a ‘DFmode’ value.
  
! ‘(pre_inc:M X)’
       Similar, but specifies incrementing X instead of decrementing it.
  
! ‘(post_dec:M X)’
!      Represents the same side effect as ‘pre_dec’ but a different value.
       The value represented here is the value X has before being
       decremented.
  
! ‘(post_inc:M X)’
       Similar, but specifies incrementing X instead of decrementing it.
  
! ‘(post_modify:M X Y)’
  
       Represents the side effect of setting X to Y and represents X
!      before X is modified.  X must be a ‘reg’ or ‘mem’, but most
!      machines allow only a ‘reg’.  M must be the machine mode for
       pointers on the machine in use.
  
!      The expression Y must be one of three forms: ‘(plus:M X Z)’,
!      ‘(minus:M X Z)’, or ‘(plus:M X I)’, where Z is an index register
       and I is a constant.
  
       Here is an example of its use:
*************** Six special side-effect expression codes
*** 19366,19378 ****
       This says to modify pseudo register 42 by adding the contents of
       pseudo register 48 to it, after the use of what ever 42 points to.
  
! '(pre_modify:M X EXPR)'
       Similar except side effects happen before the use.
  
   These embedded side effect expressions must be used with care.
! Instruction patterns may not use them.  Until the 'flow' pass of the
  compiler, they may occur only to represent pushes onto the stack.  The
! 'flow' pass finds cases where registers are incremented or decremented
  in one instruction and used as an address shortly before or after; these
  cases are then transformed to use pre- or post-increment or -decrement.
  
--- 19365,19377 ----
       This says to modify pseudo register 42 by adding the contents of
       pseudo register 48 to it, after the use of what ever 42 points to.
  
! ‘(pre_modify:M X EXPR)’
       Similar except side effects happen before the use.
  
   These embedded side effect expressions must be used with care.
! Instruction patterns may not use them.  Until the ‘flow’ pass of the
  compiler, they may occur only to represent pushes onto the stack.  The
! ‘flow’ pass finds cases where registers are incremented or decremented
  in one instruction and used as an address shortly before or after; these
  cases are then transformed to use pre- or post-increment or -decrement.
  
*************** insns behave differently on different ma
*** 19384,19391 ****
  as ambiguous and disallowed.
  
   An instruction that can be represented with an embedded side effect
! could also be represented using 'parallel' containing an additional
! 'set' to describe how the address register is altered.  This is not done
  because machines that allow these operations at all typically allow them
  wherever a memory address is called for.  Describing them as additional
  parallel stores would require doubling the number of entries in the
--- 19383,19390 ----
  as ambiguous and disallowed.
  
   An instruction that can be represented with an embedded side effect
! could also be represented using ‘parallel’ containing an additional
! ‘set’ to describe how the address register is altered.  This is not done
  because machines that allow these operations at all typically allow them
  wherever a memory address is called for.  Describing them as additional
  parallel stores would require doubling the number of entries in the
*************** File: gccint.info,  Node: Assembler,  Ne
*** 19397,19411 ****
  14.17 Assembler Instructions as Expressions
  ===========================================
  
! The RTX code 'asm_operands' represents a value produced by a
! user-specified assembler instruction.  It is used to represent an 'asm'
! statement with arguments.  An 'asm' statement with a single output
  operand, like this:
  
       asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
  
! is represented using a single 'asm_operands' RTX which represents the
! value that is stored in 'outputvar':
  
       (set RTX-FOR-OUTPUTVAR
            (asm_operands "foo %1,%2,%0" "a" 0
--- 19396,19410 ----
  14.17 Assembler Instructions as Expressions
  ===========================================
  
! The RTX code ‘asm_operands’ represents a value produced by a
! user-specified assembler instruction.  It is used to represent an ‘asm’
! statement with arguments.  An ‘asm’ statement with a single output
  operand, like this:
  
       asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
  
! is represented using a single ‘asm_operands’ RTX which represents the
! value that is stored in ‘outputvar’:
  
       (set RTX-FOR-OUTPUTVAR
            (asm_operands "foo %1,%2,%0" "a" 0
*************** value that is stored in 'outputvar':
*** 19413,19427 ****
                          [(asm_input:M1 "g")
                           (asm_input:M2 "di")]))
  
! Here the operands of the 'asm_operands' RTX are the assembler template
  string, the output-operand's constraint, the index-number of the output
  operand among the output operands specified, a vector of input operand
  RTX's, and a vector of input-operand modes and constraints.  The mode M1
! is the mode of the sum 'x+y'; M2 is that of '*z'.
  
!  When an 'asm' statement has multiple output values, its insn has
! several such 'set' RTX's inside of a 'parallel'.  Each 'set' contains an
! 'asm_operands'; all of these share the same assembler template and
  vectors, but each contains the constraint for the respective output
  operand.  They are also distinguished by the output-operand index
  number, which is 0, 1, ... for successive output operands.
--- 19412,19426 ----
                          [(asm_input:M1 "g")
                           (asm_input:M2 "di")]))
  
! Here the operands of the ‘asm_operands’ RTX are the assembler template
  string, the output-operand's constraint, the index-number of the output
  operand among the output operands specified, a vector of input operand
  RTX's, and a vector of input-operand modes and constraints.  The mode M1
! is the mode of the sum ‘x+y’; M2 is that of ‘*z’.
  
!  When an ‘asm’ statement has multiple output values, its insn has
! several such ‘set’ RTX's inside of a ‘parallel’.  Each ‘set’ contains an
! ‘asm_operands’; all of these share the same assembler template and
  vectors, but each contains the constraint for the respective output
  operand.  They are also distinguished by the output-operand index
  number, which is 0, 1, ... for successive output operands.
*************** File: gccint.info,  Node: Debug Informat
*** 19432,19438 ****
  14.18 Variable Location Debug Information in RTL
  ================================================
  
! Variable tracking relies on 'MEM_EXPR' and 'REG_EXPR' annotations to
  determine what user variables memory and register references refer to.
  
   Variable tracking at assignments uses these notes only when they refer
--- 19431,19437 ----
  14.18 Variable Location Debug Information in RTL
  ================================================
  
! Variable tracking relies on ‘MEM_EXPR’ and ‘REG_EXPR’ annotations to
  determine what user variables memory and register references refer to.
  
   Variable tracking at assignments uses these notes only when they refer
*************** to variables that live at fixed location
*** 19440,19474 ****
  global non-automatic variables).  For variables whose location may vary,
  it relies on the following types of notes.
  
! '(var_location:MODE VAR EXP STAT)'
!      Binds variable 'var', a tree, to value EXP, an RTL expression.  It
!      appears only in 'NOTE_INSN_VAR_LOCATION' and 'DEBUG_INSN's, with
       slightly different meanings.  MODE, if present, represents the mode
       of EXP, which is useful if it is a modeless expression.  STAT is
       only meaningful in notes, indicating whether the variable is known
       to be initialized or uninitialized.
  
! '(debug_expr:MODE DECL)'
!      Stands for the value bound to the 'DEBUG_EXPR_DECL' DECL, that
!      points back to it, within value expressions in 'VAR_LOCATION'
       nodes.
  
! '(debug_implicit_ptr:MODE DECL)'
       Stands for the location of a DECL that is no longer addressable.
  
! '(entry_value:MODE DECL)'
       Stands for the value a DECL had at the entry point of the
       containing function.
  
! '(debug_parameter_ref:MODE DECL)'
       Refers to a parameter that was completely optimized out.
  
! '(debug_marker:MODE)'
!      Marks a program location.  With 'VOIDmode', it stands for the
       beginning of a statement, a recommended inspection point logically
       after all prior side effects, and before any subsequent side
!      effects.  With 'BLKmode', it indicates an inline entry point: the
!      lexical block encoded in the 'INSN_LOCATION' is the enclosing block
       that encloses the inlined function.
  
  
--- 19439,19473 ----
  global non-automatic variables).  For variables whose location may vary,
  it relies on the following types of notes.
  
! ‘(var_location:MODE VAR EXP STAT)’
!      Binds variable ‘var’, a tree, to value EXP, an RTL expression.  It
!      appears only in ‘NOTE_INSN_VAR_LOCATION’ and ‘DEBUG_INSN’s, with
       slightly different meanings.  MODE, if present, represents the mode
       of EXP, which is useful if it is a modeless expression.  STAT is
       only meaningful in notes, indicating whether the variable is known
       to be initialized or uninitialized.
  
! ‘(debug_expr:MODE DECL)’
!      Stands for the value bound to the ‘DEBUG_EXPR_DECL’ DECL, that
!      points back to it, within value expressions in ‘VAR_LOCATION’
       nodes.
  
! ‘(debug_implicit_ptr:MODE DECL)’
       Stands for the location of a DECL that is no longer addressable.
  
! ‘(entry_value:MODE DECL)’
       Stands for the value a DECL had at the entry point of the
       containing function.
  
! ‘(debug_parameter_ref:MODE DECL)’
       Refers to a parameter that was completely optimized out.
  
! ‘(debug_marker:MODE)’
!      Marks a program location.  With ‘VOIDmode’, it stands for the
       beginning of a statement, a recommended inspection point logically
       after all prior side effects, and before any subsequent side
!      effects.  With ‘BLKmode’, it indicates an inline entry point: the
!      lexical block encoded in the ‘INSN_LOCATION’ is the enclosing block
       that encloses the inlined function.
  
  
*************** File: gccint.info,  Node: Insns,  Next:
*** 19478,19486 ****
  ===========
  
  The RTL representation of the code for a function is a doubly-linked
! chain of objects called "insns".  Insns are expressions with special
  codes that are used for no other purpose.  Some insns are actual
! instructions; others represent dispatch tables for 'switch' statements;
  others represent labels to jump to or various sorts of declarative
  information.
  
--- 19477,19485 ----
  ===========
  
  The RTL representation of the code for a function is a doubly-linked
! chain of objects called “insns”.  Insns are expressions with special
  codes that are used for no other purpose.  Some insns are actual
! instructions; others represent dispatch tables for ‘switch’ statements;
  others represent labels to jump to or various sorts of declarative
  information.
  
*************** id-number that distinguishes it from all
*** 19489,19513 ****
  function (after delayed branch scheduling, copies of an insn with the
  same id-number may be present in multiple places in a function, but
  these copies will always be identical and will only appear inside a
! 'sequence'), and chain pointers to the preceding and following insns.
  These three fields occupy the same position in every insn, independent
! of the expression code of the insn.  They could be accessed with 'XEXP'
! and 'XINT', but instead three special macros are always used:
  
! 'INSN_UID (I)'
       Accesses the unique id of insn I.
  
! 'PREV_INSN (I)'
       Accesses the chain pointer to the insn preceding I.  If I is the
       first insn, this is a null pointer.
  
! 'NEXT_INSN (I)'
       Accesses the chain pointer to the insn following I.  If I is the
       last insn, this is a null pointer.
  
!  The first insn in the chain is obtained by calling 'get_insns'; the
! last insn is the result of calling 'get_last_insn'.  Within the chain
! delimited by these insns, the 'NEXT_INSN' and 'PREV_INSN' pointers must
  always correspond: if INSN is not the first insn,
  
       NEXT_INSN (PREV_INSN (INSN)) == INSN
--- 19488,19512 ----
  function (after delayed branch scheduling, copies of an insn with the
  same id-number may be present in multiple places in a function, but
  these copies will always be identical and will only appear inside a
! ‘sequence’), and chain pointers to the preceding and following insns.
  These three fields occupy the same position in every insn, independent
! of the expression code of the insn.  They could be accessed with ‘XEXP’
! and ‘XINT’, but instead three special macros are always used:
  
! ‘INSN_UID (I)’
       Accesses the unique id of insn I.
  
! ‘PREV_INSN (I)’
       Accesses the chain pointer to the insn preceding I.  If I is the
       first insn, this is a null pointer.
  
! ‘NEXT_INSN (I)’
       Accesses the chain pointer to the insn following I.  If I is the
       last insn, this is a null pointer.
  
!  The first insn in the chain is obtained by calling ‘get_insns’; the
! last insn is the result of calling ‘get_last_insn’.  Within the chain
! delimited by these insns, the ‘NEXT_INSN’ and ‘PREV_INSN’ pointers must
  always correspond: if INSN is not the first insn,
  
       NEXT_INSN (PREV_INSN (INSN)) == INSN
*************** is always true and if INSN is not the la
*** 19519,19626 ****
  is always true.
  
   After delay slot scheduling, some of the insns in the chain might be
! 'sequence' expressions, which contain a vector of insns.  The value of
! 'NEXT_INSN' in all but the last of these insns is the next insn in the
! vector; the value of 'NEXT_INSN' of the last insn in the vector is the
! same as the value of 'NEXT_INSN' for the 'sequence' in which it is
! contained.  Similar rules apply for 'PREV_INSN'.
  
   This means that the above invariants are not necessarily true for insns
! inside 'sequence' expressions.  Specifically, if INSN is the first insn
! in a 'sequence', 'NEXT_INSN (PREV_INSN (INSN))' is the insn containing
! the 'sequence' expression, as is the value of 'PREV_INSN (NEXT_INSN
! (INSN))' if INSN is the last insn in the 'sequence' expression.  You can
! use these expressions to find the containing 'sequence' expression.
  
   Every insn has one of the following expression codes:
  
! 'insn'
!      The expression code 'insn' is used for instructions that do not
!      jump and do not do function calls.  'sequence' expressions are
!      always contained in insns with code 'insn' even if one of those
       insns should jump or do function calls.
  
!      Insns with code 'insn' have four additional fields beyond the three
       mandatory ones listed above.  These four are described in a table
       below.
  
! 'jump_insn'
!      The expression code 'jump_insn' is used for instructions that may
!      jump (or, more generally, may contain 'label_ref' expressions to
!      which 'pc' can be set in that instruction).  If there is an
       instruction to return from the current function, it is recorded as
!      a 'jump_insn'.
  
!      'jump_insn' insns have the same extra fields as 'insn' insns,
       accessed in the same way and in addition contain a field
!      'JUMP_LABEL' which is defined once jump optimization has completed.
  
       For simple conditional and unconditional jumps, this field contains
!      the 'code_label' to which this insn will (possibly conditionally)
!      branch.  In a more complex jump, 'JUMP_LABEL' records one of the
       labels that the insn refers to; other jump target labels are
!      recorded as 'REG_LABEL_TARGET' notes.  The exception is 'addr_vec'
!      and 'addr_diff_vec', where 'JUMP_LABEL' is 'NULL_RTX' and the only
       way to find the labels is to scan the entire body of the insn.
  
!      Return insns count as jumps, but their 'JUMP_LABEL' is 'RETURN' or
!      'SIMPLE_RETURN'.
  
! 'call_insn'
!      The expression code 'call_insn' is used for instructions that may
       do function calls.  It is important to distinguish these
       instructions because they imply that certain registers and memory
       locations may be altered unpredictably.
  
!      'call_insn' insns have the same extra fields as 'insn' insns,
       accessed in the same way and in addition contain a field
!      'CALL_INSN_FUNCTION_USAGE', which contains a list (chain of
!      'expr_list' expressions) containing 'use', 'clobber' and sometimes
!      'set' expressions that denote hard registers and 'mem's used or
       clobbered by the called function.
  
!      A 'mem' generally points to a stack slot in which arguments passed
       to the libcall by reference (*note TARGET_PASS_BY_REFERENCE:
       Register Arguments.) are stored.  If the argument is caller-copied
       (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot
!      will be mentioned in 'clobber' and 'use' entries; if it's
!      callee-copied, only a 'use' will appear, and the 'mem' may point to
       addresses that are not stack slots.
  
!      Registers occurring inside a 'clobber' in this list augment
!      registers specified in 'CALL_USED_REGISTERS' (*note Register
       Basics::).
  
!      If the list contains a 'set' involving two registers, it indicates
!      that the function returns one of its arguments.  Such a 'set' may
       look like a no-op if the same register holds the argument and the
       return value.
  
! 'code_label'
!      A 'code_label' insn represents a label that a jump insn can jump
       to.  It contains two special fields of data in addition to the
!      three standard ones.  'CODE_LABEL_NUMBER' is used to hold the
!      "label number", a number that identifies this label uniquely among
       all the labels in the compilation (not just in the current
       function).  Ultimately, the label is represented in the assembler
!      output as an assembler label, usually of the form 'LN' where N is
       the label number.
  
!      When a 'code_label' appears in an RTL expression, it normally
!      appears within a 'label_ref' which represents the address of the
       label, as a number.
  
!      Besides as a 'code_label', a label can also be represented as a
!      'note' of type 'NOTE_INSN_DELETED_LABEL'.
  
!      The field 'LABEL_NUSES' is only defined once the jump optimization
       phase is completed.  It contains the number of times this label is
       referenced in the current function.
  
!      The field 'LABEL_KIND' differentiates four different types of
!      labels: 'LABEL_NORMAL', 'LABEL_STATIC_ENTRY', 'LABEL_GLOBAL_ENTRY',
!      and 'LABEL_WEAK_ENTRY'.  The only labels that do not have type
!      'LABEL_NORMAL' are "alternate entry points" to the current
       function.  These may be static (visible only in the containing
       translation unit), global (exposed to all translation units), or
       weak (global, but can be overridden by another symbol with the same
--- 19518,19625 ----
  is always true.
  
   After delay slot scheduling, some of the insns in the chain might be
! ‘sequence’ expressions, which contain a vector of insns.  The value of
! ‘NEXT_INSN’ in all but the last of these insns is the next insn in the
! vector; the value of ‘NEXT_INSN’ of the last insn in the vector is the
! same as the value of ‘NEXT_INSN’ for the ‘sequence’ in which it is
! contained.  Similar rules apply for ‘PREV_INSN’.
  
   This means that the above invariants are not necessarily true for insns
! inside ‘sequence’ expressions.  Specifically, if INSN is the first insn
! in a ‘sequence’, ‘NEXT_INSN (PREV_INSN (INSN))’ is the insn containing
! the ‘sequence’ expression, as is the value of ‘PREV_INSN (NEXT_INSN
! (INSN))’ if INSN is the last insn in the ‘sequence’ expression.  You can
! use these expressions to find the containing ‘sequence’ expression.
  
   Every insn has one of the following expression codes:
  
! ‘insn’
!      The expression code ‘insn’ is used for instructions that do not
!      jump and do not do function calls.  ‘sequence’ expressions are
!      always contained in insns with code ‘insn’ even if one of those
       insns should jump or do function calls.
  
!      Insns with code ‘insn’ have four additional fields beyond the three
       mandatory ones listed above.  These four are described in a table
       below.
  
! ‘jump_insn’
!      The expression code ‘jump_insn’ is used for instructions that may
!      jump (or, more generally, may contain ‘label_ref’ expressions to
!      which ‘pc’ can be set in that instruction).  If there is an
       instruction to return from the current function, it is recorded as
!      a ‘jump_insn’.
  
!      ‘jump_insn’ insns have the same extra fields as ‘insn’ insns,
       accessed in the same way and in addition contain a field
!      ‘JUMP_LABEL’ which is defined once jump optimization has completed.
  
       For simple conditional and unconditional jumps, this field contains
!      the ‘code_label’ to which this insn will (possibly conditionally)
!      branch.  In a more complex jump, ‘JUMP_LABEL’ records one of the
       labels that the insn refers to; other jump target labels are
!      recorded as ‘REG_LABEL_TARGET’ notes.  The exception is ‘addr_vec’
!      and ‘addr_diff_vec’, where ‘JUMP_LABEL’ is ‘NULL_RTX’ and the only
       way to find the labels is to scan the entire body of the insn.
  
!      Return insns count as jumps, but their ‘JUMP_LABEL’ is ‘RETURN’ or
!      ‘SIMPLE_RETURN’.
  
! ‘call_insn’
!      The expression code ‘call_insn’ is used for instructions that may
       do function calls.  It is important to distinguish these
       instructions because they imply that certain registers and memory
       locations may be altered unpredictably.
  
!      ‘call_insn’ insns have the same extra fields as ‘insn’ insns,
       accessed in the same way and in addition contain a field
!      ‘CALL_INSN_FUNCTION_USAGE’, which contains a list (chain of
!      ‘expr_list’ expressions) containing ‘use’, ‘clobber’ and sometimes
!      ‘set’ expressions that denote hard registers and ‘mem’s used or
       clobbered by the called function.
  
!      A ‘mem’ generally points to a stack slot in which arguments passed
       to the libcall by reference (*note TARGET_PASS_BY_REFERENCE:
       Register Arguments.) are stored.  If the argument is caller-copied
       (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot
!      will be mentioned in ‘clobber’ and ‘use’ entries; if it's
!      callee-copied, only a ‘use’ will appear, and the ‘mem’ may point to
       addresses that are not stack slots.
  
!      Registers occurring inside a ‘clobber’ in this list augment
!      registers specified in ‘CALL_USED_REGISTERS’ (*note Register
       Basics::).
  
!      If the list contains a ‘set’ involving two registers, it indicates
!      that the function returns one of its arguments.  Such a ‘set’ may
       look like a no-op if the same register holds the argument and the
       return value.
  
! ‘code_label’
!      A ‘code_label’ insn represents a label that a jump insn can jump
       to.  It contains two special fields of data in addition to the
!      three standard ones.  ‘CODE_LABEL_NUMBER’ is used to hold the
!      “label number”, a number that identifies this label uniquely among
       all the labels in the compilation (not just in the current
       function).  Ultimately, the label is represented in the assembler
!      output as an assembler label, usually of the form ‘LN’ where N is
       the label number.
  
!      When a ‘code_label’ appears in an RTL expression, it normally
!      appears within a ‘label_ref’ which represents the address of the
       label, as a number.
  
!      Besides as a ‘code_label’, a label can also be represented as a
!      ‘note’ of type ‘NOTE_INSN_DELETED_LABEL’.
  
!      The field ‘LABEL_NUSES’ is only defined once the jump optimization
       phase is completed.  It contains the number of times this label is
       referenced in the current function.
  
!      The field ‘LABEL_KIND’ differentiates four different types of
!      labels: ‘LABEL_NORMAL’, ‘LABEL_STATIC_ENTRY’, ‘LABEL_GLOBAL_ENTRY’,
!      and ‘LABEL_WEAK_ENTRY’.  The only labels that do not have type
!      ‘LABEL_NORMAL’ are “alternate entry points” to the current
       function.  These may be static (visible only in the containing
       translation unit), global (exposed to all translation units), or
       weak (global, but can be overridden by another symbol with the same
*************** use these expressions to find the contai
*** 19628,19716 ****
  
       Much of the compiler treats all four kinds of label identically.
       Some of it needs to know whether or not a label is an alternate
!      entry point; for this purpose, the macro 'LABEL_ALT_ENTRY_P' is
!      provided.  It is equivalent to testing whether 'LABEL_KIND (label)
!      == LABEL_NORMAL'.  The only place that cares about the distinction
       between static, global, and weak alternate entry points, besides
       the front-end code that creates them, is the function
!      'output_alternate_entry_point', in 'final.cc'.
  
!      To set the kind of a label, use the 'SET_LABEL_KIND' macro.
  
! 'jump_table_data'
!      A 'jump_table_data' insn is a placeholder for the jump-table data
!      of a 'casesi' or 'tablejump' insn.  They are placed after a
!      'tablejump_p' insn.  A 'jump_table_data' insn is not part o a basic
       blockm but it is associated with the basic block that ends with the
!      'tablejump_p' insn.  The 'PATTERN' of a 'jump_table_data' is always
!      either an 'addr_vec' or an 'addr_diff_vec', and a 'jump_table_data'
!      insn is always preceded by a 'code_label'.  The 'tablejump_p' insn
!      refers to that 'code_label' via its 'JUMP_LABEL'.
  
! 'barrier'
       Barriers are placed in the instruction stream when control cannot
       flow past them.  They are placed after unconditional jump
       instructions to indicate that the jumps are unconditional and after
!      calls to 'volatile' functions, which do not return (e.g., 'exit').
       They contain no information beyond the three standard fields.
  
! 'note'
!      'note' insns are used to represent additional debugging and
       declarative information.  They contain two nonstandard fields, an
!      integer which is accessed with the macro 'NOTE_LINE_NUMBER' and a
!      string accessed with 'NOTE_SOURCE_FILE'.
  
!      If 'NOTE_LINE_NUMBER' is positive, the note represents the position
!      of a source line and 'NOTE_SOURCE_FILE' is the source file name
       that the line came from.  These notes control generation of line
       number data in the assembler output.
  
!      Otherwise, 'NOTE_LINE_NUMBER' is not really a line number but a
!      code with one of the following values (and 'NOTE_SOURCE_FILE' must
       contain a null pointer):
  
!      'NOTE_INSN_DELETED'
            Such a note is completely ignorable.  Some passes of the
            compiler delete insns by altering them into notes of this
            kind.
  
!      'NOTE_INSN_DELETED_LABEL'
!           This marks what used to be a 'code_label', but was not used
            for other purposes than taking its address and was transformed
            to mark that no code jumps to it.
  
!      'NOTE_INSN_BLOCK_BEG'
!      'NOTE_INSN_BLOCK_END'
            These types of notes indicate the position of the beginning
            and end of a level of scoping of variable names.  They control
            the output of debugging information.
  
!      'NOTE_INSN_EH_REGION_BEG'
!      'NOTE_INSN_EH_REGION_END'
            These types of notes indicate the position of the beginning
            and end of a level of scoping for exception handling.
!           'NOTE_EH_HANDLER' identifies which region is associated with
            these notes.
  
!      'NOTE_INSN_FUNCTION_BEG'
            Appears at the start of the function body, after the function
            prologue.
  
!      'NOTE_INSN_VAR_LOCATION'
            This note is used to generate variable location debugging
            information.  It indicates that the user variable in its
!           'VAR_LOCATION' operand is at the location given in the RTL
            expression, or holds a value that can be computed by
            evaluating the RTL expression from that static point in the
            program up to the next such note for the same user variable.
  
!      'NOTE_INSN_BEGIN_STMT'
!           This note is used to generate 'is_stmt' markers in line number
            debugging information.  It indicates the beginning of a user
            statement.
  
!      'NOTE_INSN_INLINE_ENTRY'
!           This note is used to generate 'entry_pc' for inlined
            subroutines in debugging information.  It indicates an
            inspection point at which all arguments for the inlined
            function have been bound, and before its first statement.
--- 19627,19715 ----
  
       Much of the compiler treats all four kinds of label identically.
       Some of it needs to know whether or not a label is an alternate
!      entry point; for this purpose, the macro ‘LABEL_ALT_ENTRY_P’ is
!      provided.  It is equivalent to testing whether ‘LABEL_KIND (label)
!      == LABEL_NORMAL’.  The only place that cares about the distinction
       between static, global, and weak alternate entry points, besides
       the front-end code that creates them, is the function
!      ‘output_alternate_entry_point’, in ‘final.cc’.
  
!      To set the kind of a label, use the ‘SET_LABEL_KIND’ macro.
  
! ‘jump_table_data’
!      A ‘jump_table_data’ insn is a placeholder for the jump-table data
!      of a ‘casesi’ or ‘tablejump’ insn.  They are placed after a
!      ‘tablejump_p’ insn.  A ‘jump_table_data’ insn is not part o a basic
       blockm but it is associated with the basic block that ends with the
!      ‘tablejump_p’ insn.  The ‘PATTERN’ of a ‘jump_table_data’ is always
!      either an ‘addr_vec’ or an ‘addr_diff_vec’, and a ‘jump_table_data’
!      insn is always preceded by a ‘code_label’.  The ‘tablejump_p’ insn
!      refers to that ‘code_label’ via its ‘JUMP_LABEL’.
  
! ‘barrier’
       Barriers are placed in the instruction stream when control cannot
       flow past them.  They are placed after unconditional jump
       instructions to indicate that the jumps are unconditional and after
!      calls to ‘volatile’ functions, which do not return (e.g., ‘exit’).
       They contain no information beyond the three standard fields.
  
! ‘note’
!      ‘note’ insns are used to represent additional debugging and
       declarative information.  They contain two nonstandard fields, an
!      integer which is accessed with the macro ‘NOTE_LINE_NUMBER’ and a
!      string accessed with ‘NOTE_SOURCE_FILE’.
  
!      If ‘NOTE_LINE_NUMBER’ is positive, the note represents the position
!      of a source line and ‘NOTE_SOURCE_FILE’ is the source file name
       that the line came from.  These notes control generation of line
       number data in the assembler output.
  
!      Otherwise, ‘NOTE_LINE_NUMBER’ is not really a line number but a
!      code with one of the following values (and ‘NOTE_SOURCE_FILE’ must
       contain a null pointer):
  
!      ‘NOTE_INSN_DELETED’
            Such a note is completely ignorable.  Some passes of the
            compiler delete insns by altering them into notes of this
            kind.
  
!      ‘NOTE_INSN_DELETED_LABEL’
!           This marks what used to be a ‘code_label’, but was not used
            for other purposes than taking its address and was transformed
            to mark that no code jumps to it.
  
!      ‘NOTE_INSN_BLOCK_BEG’
!      ‘NOTE_INSN_BLOCK_END’
            These types of notes indicate the position of the beginning
            and end of a level of scoping of variable names.  They control
            the output of debugging information.
  
!      ‘NOTE_INSN_EH_REGION_BEG’
!      ‘NOTE_INSN_EH_REGION_END’
            These types of notes indicate the position of the beginning
            and end of a level of scoping for exception handling.
!           ‘NOTE_EH_HANDLER’ identifies which region is associated with
            these notes.
  
!      ‘NOTE_INSN_FUNCTION_BEG’
            Appears at the start of the function body, after the function
            prologue.
  
!      ‘NOTE_INSN_VAR_LOCATION’
            This note is used to generate variable location debugging
            information.  It indicates that the user variable in its
!           ‘VAR_LOCATION’ operand is at the location given in the RTL
            expression, or holds a value that can be computed by
            evaluating the RTL expression from that static point in the
            program up to the next such note for the same user variable.
  
!      ‘NOTE_INSN_BEGIN_STMT’
!           This note is used to generate ‘is_stmt’ markers in line number
            debugging information.  It indicates the beginning of a user
            statement.
  
!      ‘NOTE_INSN_INLINE_ENTRY’
!           This note is used to generate ‘entry_pc’ for inlined
            subroutines in debugging information.  It indicates an
            inspection point at which all arguments for the inlined
            function have been bound, and before its first statement.
*************** use these expressions to find the contai
*** 19718,19827 ****
       These codes are printed symbolically when they appear in debugging
       dumps.
  
! 'debug_insn'
!      The expression code 'debug_insn' is used for pseudo-instructions
       that hold debugging information for variable tracking at
!      assignments (see '-fvar-tracking-assignments' option).  They are
!      the RTL representation of 'GIMPLE_DEBUG' statements (*note
!      GIMPLE_DEBUG::), with a 'VAR_LOCATION' operand that binds a user
!      variable tree to an RTL representation of the 'value' in the
!      corresponding statement.  A 'DEBUG_EXPR' in it stands for the value
!      bound to the corresponding 'DEBUG_EXPR_DECL'.
  
!      'GIMPLE_DEBUG_BEGIN_STMT' and 'GIMPLE_DEBUG_INLINE_ENTRY' are
!      expanded to RTL as a 'DEBUG_INSN' with a 'DEBUG_MARKER' 'PATTERN';
!      the difference is the RTL mode: the former's 'DEBUG_MARKER' is
!      'VOIDmode', whereas the latter is 'BLKmode'; information about the
       inlined function can be taken from the lexical block encoded in the
!      'INSN_LOCATION'.  These 'DEBUG_INSN's, that do not carry
!      'VAR_LOCATION' information, just 'DEBUG_MARKER's, can be detected
!      by testing 'DEBUG_MARKER_INSN_P', whereas those that do can be
!      recognized as 'DEBUG_BIND_INSN_P'.
  
!      Throughout optimization passes, 'DEBUG_INSN's are not reordered
       with respect to each other, particularly during scheduling.
       Binding information is kept in pseudo-instruction form, so that,
       unlike notes, it gets the same treatment and adjustments that
       regular instructions would.  It is the variable tracking pass that
!      turns these pseudo-instructions into 'NOTE_INSN_VAR_LOCATION',
!      'NOTE_INSN_BEGIN_STMT' and 'NOTE_INSN_INLINE_ENTRY' notes,
       analyzing control flow, value equivalences and changes to registers
       and memory referenced in value expressions, propagating the values
       of debug temporaries and determining expressions that can be used
       to compute the value of each user variable at as many points
       (ranges, actually) in the program as possible.
  
!      Unlike 'NOTE_INSN_VAR_LOCATION', the value expression in an
!      'INSN_VAR_LOCATION' denotes a value at that specific point in the
       program, rather than an expression that can be evaluated at any
!      later point before an overriding 'VAR_LOCATION' is encountered.
!      E.g., if a user variable is bound to a 'REG' and then a subsequent
!      insn modifies the 'REG', the note location would keep mapping the
       user variable to the register across the insn, whereas the insn
       location would keep the variable bound to the value, so that the
       variable tracking pass would emit another location note for the
       variable at the point in which the register is modified.
  
!  The machine mode of an insn is normally 'VOIDmode', but some phases use
  the mode for various purposes.
  
   The common subexpression elimination pass sets the mode of an insn to
! 'QImode' when it is the first insn in a block that has already been
  processed.
  
   The second Haifa scheduling pass, for targets that can multiple issue,
! sets the mode of an insn to 'TImode' when it is believed that the
  instruction begins an issue group.  That is, when the instruction cannot
  issue simultaneously with the previous.  This may be relied on by later
  passes, in particular machine-dependent reorg.
  
!  Here is a table of the extra fields of 'insn', 'jump_insn' and
! 'call_insn' insns:
  
! 'PATTERN (I)'
       An expression for the side effect performed by this insn.  This
!      must be one of the following codes: 'set', 'call', 'use',
!      'clobber', 'return', 'simple_return', 'asm_input', 'asm_output',
!      'addr_vec', 'addr_diff_vec', 'trap_if', 'unspec',
!      'unspec_volatile', 'parallel', 'cond_exec', or 'sequence'.  If it
!      is a 'parallel', each element of the 'parallel' must be one these
!      codes, except that 'parallel' expressions cannot be nested and
!      'addr_vec' and 'addr_diff_vec' are not permitted inside a
!      'parallel' expression.
  
! 'INSN_CODE (I)'
       An integer that says which pattern in the machine description
!      matches this insn, or -1 if the matching has not yet been
       attempted.
  
!      Such matching is never attempted and this field remains -1 on an
!      insn whose pattern consists of a single 'use', 'clobber',
!      'asm_input', 'addr_vec' or 'addr_diff_vec' expression.
  
!      Matching is also never attempted on insns that result from an 'asm'
!      statement.  These contain at least one 'asm_operands' expression.
!      The function 'asm_noperands' returns a non-negative value for such
       insns.
  
       In the debugging output, this field is printed as a number followed
!      by a symbolic representation that locates the pattern in the 'md'
       file as some small positive or negative offset from a named
       pattern.
  
! 'REG_NOTES (I)'
!      A list (chain of 'expr_list', 'insn_list' and 'int_list'
       expressions) giving miscellaneous information about the insn.  It
       is often information pertaining to the registers used in this insn.
  
!  The 'REG_NOTES' field of an insn is a chain that includes 'expr_list'
! and 'int_list' expressions as well as 'insn_list' expressions.  There
  are several kinds of register notes, which are distinguished by the
  machine mode, which in a register note is really understood as being an
! 'enum reg_note'.  The first operand OP of the note is data whose meaning
  depends on the kind of note.
  
!  The macro 'REG_NOTE_KIND (X)' returns the kind of register note.  Its
! counterpart, the macro 'PUT_REG_NOTE_KIND (X, NEWKIND)' sets the
  register note type of X to be NEWKIND.
  
   Register notes are of three classes: They may say something about an
--- 19717,19826 ----
       These codes are printed symbolically when they appear in debugging
       dumps.
  
! ‘debug_insn’
!      The expression code ‘debug_insn’ is used for pseudo-instructions
       that hold debugging information for variable tracking at
!      assignments (see ‘-fvar-tracking-assignments’ option).  They are
!      the RTL representation of ‘GIMPLE_DEBUG’ statements (*note
!      GIMPLE_DEBUG::), with a ‘VAR_LOCATION’ operand that binds a user
!      variable tree to an RTL representation of the ‘value’ in the
!      corresponding statement.  A ‘DEBUG_EXPR’ in it stands for the value
!      bound to the corresponding ‘DEBUG_EXPR_DECL’.
  
!      ‘GIMPLE_DEBUG_BEGIN_STMT’ and ‘GIMPLE_DEBUG_INLINE_ENTRY’ are
!      expanded to RTL as a ‘DEBUG_INSN’ with a ‘DEBUG_MARKER’ ‘PATTERN’;
!      the difference is the RTL mode: the former's ‘DEBUG_MARKER’ is
!      ‘VOIDmode’, whereas the latter is ‘BLKmode’; information about the
       inlined function can be taken from the lexical block encoded in the
!      ‘INSN_LOCATION’.  These ‘DEBUG_INSN’s, that do not carry
!      ‘VAR_LOCATION’ information, just ‘DEBUG_MARKER’s, can be detected
!      by testing ‘DEBUG_MARKER_INSN_P’, whereas those that do can be
!      recognized as ‘DEBUG_BIND_INSN_P’.
  
!      Throughout optimization passes, ‘DEBUG_INSN’s are not reordered
       with respect to each other, particularly during scheduling.
       Binding information is kept in pseudo-instruction form, so that,
       unlike notes, it gets the same treatment and adjustments that
       regular instructions would.  It is the variable tracking pass that
!      turns these pseudo-instructions into ‘NOTE_INSN_VAR_LOCATION’,
!      ‘NOTE_INSN_BEGIN_STMT’ and ‘NOTE_INSN_INLINE_ENTRY’ notes,
       analyzing control flow, value equivalences and changes to registers
       and memory referenced in value expressions, propagating the values
       of debug temporaries and determining expressions that can be used
       to compute the value of each user variable at as many points
       (ranges, actually) in the program as possible.
  
!      Unlike ‘NOTE_INSN_VAR_LOCATION’, the value expression in an
!      ‘INSN_VAR_LOCATION’ denotes a value at that specific point in the
       program, rather than an expression that can be evaluated at any
!      later point before an overriding ‘VAR_LOCATION’ is encountered.
!      E.g., if a user variable is bound to a ‘REG’ and then a subsequent
!      insn modifies the ‘REG’, the note location would keep mapping the
       user variable to the register across the insn, whereas the insn
       location would keep the variable bound to the value, so that the
       variable tracking pass would emit another location note for the
       variable at the point in which the register is modified.
  
!  The machine mode of an insn is normally ‘VOIDmode’, but some phases use
  the mode for various purposes.
  
   The common subexpression elimination pass sets the mode of an insn to
! ‘QImode’ when it is the first insn in a block that has already been
  processed.
  
   The second Haifa scheduling pass, for targets that can multiple issue,
! sets the mode of an insn to ‘TImode’ when it is believed that the
  instruction begins an issue group.  That is, when the instruction cannot
  issue simultaneously with the previous.  This may be relied on by later
  passes, in particular machine-dependent reorg.
  
!  Here is a table of the extra fields of ‘insn’, ‘jump_insn’ and
! ‘call_insn’ insns:
  
! ‘PATTERN (I)’
       An expression for the side effect performed by this insn.  This
!      must be one of the following codes: ‘set’, ‘call’, ‘use’,
!      ‘clobber’, ‘return’, ‘simple_return’, ‘asm_input’, ‘asm_output’,
!      ‘addr_vec’, ‘addr_diff_vec’, ‘trap_if’, ‘unspec’,
!      ‘unspec_volatile’, ‘parallel’, ‘cond_exec’, or ‘sequence’.  If it
!      is a ‘parallel’, each element of the ‘parallel’ must be one these
!      codes, except that ‘parallel’ expressions cannot be nested and
!      ‘addr_vec’ and ‘addr_diff_vec’ are not permitted inside a
!      ‘parallel’ expression.
  
! ‘INSN_CODE (I)’
       An integer that says which pattern in the machine description
!      matches this insn, or −1 if the matching has not yet been
       attempted.
  
!      Such matching is never attempted and this field remains −1 on an
!      insn whose pattern consists of a single ‘use’, ‘clobber’,
!      ‘asm_input’, ‘addr_vec’ or ‘addr_diff_vec’ expression.
  
!      Matching is also never attempted on insns that result from an ‘asm’
!      statement.  These contain at least one ‘asm_operands’ expression.
!      The function ‘asm_noperands’ returns a non-negative value for such
       insns.
  
       In the debugging output, this field is printed as a number followed
!      by a symbolic representation that locates the pattern in the ‘md’
       file as some small positive or negative offset from a named
       pattern.
  
! ‘REG_NOTES (I)’
!      A list (chain of ‘expr_list’, ‘insn_list’ and ‘int_list’
       expressions) giving miscellaneous information about the insn.  It
       is often information pertaining to the registers used in this insn.
  
!  The ‘REG_NOTES’ field of an insn is a chain that includes ‘expr_list’
! and ‘int_list’ expressions as well as ‘insn_list’ expressions.  There
  are several kinds of register notes, which are distinguished by the
  machine mode, which in a register note is really understood as being an
! ‘enum reg_note’.  The first operand OP of the note is data whose meaning
  depends on the kind of note.
  
!  The macro ‘REG_NOTE_KIND (X)’ returns the kind of register note.  Its
! counterpart, the macro ‘PUT_REG_NOTE_KIND (X, NEWKIND)’ sets the
  register note type of X to be NEWKIND.
  
   Register notes are of three classes: They may say something about an
*************** they may create a linkage between two in
*** 19830,19836 ****
  
   These register notes annotate inputs to an insn:
  
! 'REG_DEAD'
       The value in OP dies in this insn; that is to say, altering the
       value immediately after this insn would not affect the future
       behavior of the program.
--- 19829,19835 ----
  
   These register notes annotate inputs to an insn:
  
! ‘REG_DEAD’
       The value in OP dies in this insn; that is to say, altering the
       value immediately after this insn would not affect the future
       behavior of the program.
*************** they may create a linkage between two in
*** 19839,19901 ****
       this insn since OP is not necessarily modified by this insn.
       Rather, no subsequent instruction uses the contents of OP.
  
! 'REG_UNUSED'
       The register OP being set by this insn will not be used in a
!      subsequent insn.  This differs from a 'REG_DEAD' note, which
       indicates that the value in an input will not be used subsequently.
       These two notes are independent; both may be present for the same
       register.
  
! 'REG_INC'
       The register OP is incremented (or decremented; at this level there
       is no distinction) by an embedded side effect inside this insn.
!      This means it appears in a 'post_inc', 'pre_inc', 'post_dec' or
!      'pre_dec' expression.
  
! 'REG_NONNEG'
       The register OP is known to have a nonnegative value when this insn
       is reached.  This is used by special looping instructions that
       terminate when the register goes negative.
  
!      The 'REG_NONNEG' note is added only to 'doloop_end' insns, if its
!      pattern uses a 'ge' condition.
  
! 'REG_LABEL_OPERAND'
!      This insn uses OP, a 'code_label' or a 'note' of type
!      'NOTE_INSN_DELETED_LABEL', but is not a 'jump_insn', or it is a
!      'jump_insn' that refers to the operand as an ordinary operand.  The
       label may still eventually be a jump target, but if so in an
       indirect jump in a subsequent insn.  The presence of this note
       allows jump optimization to be aware that OP is, in fact, being
       used, and flow optimization to build an accurate flow graph.
  
! 'REG_LABEL_TARGET'
!      This insn is a 'jump_insn' but not an 'addr_vec' or
!      'addr_diff_vec'.  It uses OP, a 'code_label' as a direct or
       indirect jump target.  Its purpose is similar to that of
!      'REG_LABEL_OPERAND'.  This note is only present if the insn has
       multiple targets; the last label in the insn (in the highest
!      numbered insn-field) goes into the 'JUMP_LABEL' field and does not
!      have a 'REG_LABEL_TARGET' note.  *Note JUMP_LABEL: Insns.
  
! 'REG_SETJMP'
!      Appears attached to each 'CALL_INSN' to 'setjmp' or a related
       function.
  
   The following notes describe attributes of outputs of an insn:
  
! 'REG_EQUIV'
! 'REG_EQUAL'
       This note is only valid on an insn that sets only one register and
       indicates that that register will be equal to OP at run time; the
       scope of this equivalence differs between the two types of notes.
       The value which the insn explicitly copies into the register may
       look different from OP, but they will be equal at run time.  If the
!      output of the single 'set' is a 'strict_low_part' or 'zero_extract'
       expression, the note refers to the register that is contained in
       its first operand.
  
!      For 'REG_EQUIV', the register is equivalent to OP throughout the
       entire function, and could validly be replaced in all its
       occurrences by OP.  ("Validly" here refers to the data flow of the
       program; simple replacement may make some insns invalid.)  For
--- 19838,19900 ----
       this insn since OP is not necessarily modified by this insn.
       Rather, no subsequent instruction uses the contents of OP.
  
! ‘REG_UNUSED’
       The register OP being set by this insn will not be used in a
!      subsequent insn.  This differs from a ‘REG_DEAD’ note, which
       indicates that the value in an input will not be used subsequently.
       These two notes are independent; both may be present for the same
       register.
  
! ‘REG_INC’
       The register OP is incremented (or decremented; at this level there
       is no distinction) by an embedded side effect inside this insn.
!      This means it appears in a ‘post_inc’, ‘pre_inc’, ‘post_dec’ or
!      ‘pre_dec’ expression.
  
! ‘REG_NONNEG’
       The register OP is known to have a nonnegative value when this insn
       is reached.  This is used by special looping instructions that
       terminate when the register goes negative.
  
!      The ‘REG_NONNEG’ note is added only to ‘doloop_end’ insns, if its
!      pattern uses a ‘ge’ condition.
  
! ‘REG_LABEL_OPERAND’
!      This insn uses OP, a ‘code_label’ or a ‘note’ of type
!      ‘NOTE_INSN_DELETED_LABEL’, but is not a ‘jump_insn’, or it is a
!      ‘jump_insn’ that refers to the operand as an ordinary operand.  The
       label may still eventually be a jump target, but if so in an
       indirect jump in a subsequent insn.  The presence of this note
       allows jump optimization to be aware that OP is, in fact, being
       used, and flow optimization to build an accurate flow graph.
  
! ‘REG_LABEL_TARGET’
!      This insn is a ‘jump_insn’ but not an ‘addr_vec’ or
!      ‘addr_diff_vec’.  It uses OP, a ‘code_label’ as a direct or
       indirect jump target.  Its purpose is similar to that of
!      ‘REG_LABEL_OPERAND’.  This note is only present if the insn has
       multiple targets; the last label in the insn (in the highest
!      numbered insn-field) goes into the ‘JUMP_LABEL’ field and does not
!      have a ‘REG_LABEL_TARGET’ note.  *Note JUMP_LABEL: Insns.
  
! ‘REG_SETJMP’
!      Appears attached to each ‘CALL_INSN’ to ‘setjmp’ or a related
       function.
  
   The following notes describe attributes of outputs of an insn:
  
! ‘REG_EQUIV’
! ‘REG_EQUAL’
       This note is only valid on an insn that sets only one register and
       indicates that that register will be equal to OP at run time; the
       scope of this equivalence differs between the two types of notes.
       The value which the insn explicitly copies into the register may
       look different from OP, but they will be equal at run time.  If the
!      output of the single ‘set’ is a ‘strict_low_part’ or ‘zero_extract’
       expression, the note refers to the register that is contained in
       its first operand.
  
!      For ‘REG_EQUIV’, the register is equivalent to OP throughout the
       entire function, and could validly be replaced in all its
       occurrences by OP.  ("Validly" here refers to the data flow of the
       program; simple replacement may make some insns invalid.)  For
*************** they may create a linkage between two in
*** 19909,19915 ****
       still valid to replace the register by the stack slot throughout
       the function.
  
!      A 'REG_EQUIV' note is also used on an instruction which copies a
       register parameter into a pseudo-register at entry to a function,
       if there is a stack slot where that parameter could be stored.
       Although other insns may set the pseudo-register, it is valid for
--- 19908,19914 ----
       still valid to replace the register by the stack slot throughout
       the function.
  
!      A ‘REG_EQUIV’ note is also used on an instruction which copies a
       register parameter into a pseudo-register at entry to a function,
       if there is a stack slot where that parameter could be stored.
       Although other insns may set the pseudo-register, it is valid for
*************** they may create a linkage between two in
*** 19918,19926 ****
       stack slot is properly initialized by making the replacement in the
       initial copy instruction as well.  This is used on machines for
       which the calling convention allocates stack space for register
!      parameters.  See 'REG_PARM_STACK_SPACE' in *note Stack Arguments::.
  
!      In the case of 'REG_EQUAL', the register that is set by this insn
       will be equal to OP at run time at the end of this insn but not
       necessarily elsewhere in the function.  In this case, OP is
       typically an arithmetic expression.  For example, when a sequence
--- 19917,19925 ----
       stack slot is properly initialized by making the replacement in the
       initial copy instruction as well.  This is used on machines for
       which the calling convention allocates stack space for register
!      parameters.  See ‘REG_PARM_STACK_SPACE’ in *note Stack Arguments::.
  
!      In the case of ‘REG_EQUAL’, the register that is set by this insn
       will be equal to OP at run time at the end of this insn but not
       necessarily elsewhere in the function.  In this case, OP is
       typically an arithmetic expression.  For example, when a sequence
*************** they may create a linkage between two in
*** 19929,20012 ****
       or copies the final value.
  
       These two notes are used in different ways by the compiler passes.
!      'REG_EQUAL' is used by passes prior to register allocation (such as
       common subexpression elimination and loop optimization) to tell
!      them how to think of that value.  'REG_EQUIV' notes are used by
       register allocation to indicate that there is an available
!      substitute expression (either a constant or a 'mem' expression for
       the location of a parameter on the stack) that may be used in place
       of a register if insufficient registers are available.
  
       Except for stack homes for parameters, which are indicated by a
!      'REG_EQUIV' note and are not useful to the early optimization
       passes and pseudo registers that are equivalent to a memory
       location throughout their entire life, which is not detected until
       later in the compilation, all equivalences are initially indicated
!      by an attached 'REG_EQUAL' note.  In the early stages of register
!      allocation, a 'REG_EQUAL' note is changed into a 'REG_EQUIV' note
       if OP is a constant and the insn represents the only set of its
       destination register.
  
       Thus, compiler passes prior to register allocation need only check
!      for 'REG_EQUAL' notes and passes subsequent to register allocation
!      need only check for 'REG_EQUIV' notes.
  
   These notes describe linkages between insns.  They occur in pairs: one
  insn has one of a pair of notes that points to a second insn, which has
  the inverse note pointing back to the first insn.
  
! 'REG_DEP_TRUE'
       This indicates a true dependence (a read after write dependence).
  
! 'REG_DEP_OUTPUT'
       This indicates an output dependence (a write after write
       dependence).
  
! 'REG_DEP_ANTI'
       This indicates an anti dependence (a write after read dependence).
  
   These notes describe information gathered from gcov profile data.  They
! are stored in the 'REG_NOTES' field of an insn.
  
! 'REG_BR_PROB'
       This is used to specify the ratio of branches to non-branches of a
       branch insn according to the profile data.  The note is represented
!      as an 'int_list' expression whose integer value is an encoding of
!      'profile_probability' type.  'profile_probability' provide member
!      function 'from_reg_br_prob_note' and 'to_reg_br_prob_note' to
       extract and store the probability into the RTL encoding.
  
! 'REG_BR_PRED'
       These notes are found in JUMP insns after delayed branch scheduling
       has taken place.  They indicate both the direction and the
       likelihood of the JUMP.  The format is a bitmask of ATTR_FLAG_*
       values.
  
! 'REG_FRAME_RELATED_EXPR'
       This is used on an RTX_FRAME_RELATED_P insn wherein the attached
       expression is used in place of the actual insn pattern.  This is
       done in cases where the pattern is either complex or misleading.
  
!  The note 'REG_CALL_NOCF_CHECK' is used in conjunction with the
! '-fcf-protection=branch' option.  The note is set if a 'nocf_check'
  attribute is specified for a function type or a pointer to function
! type.  The note is stored in the 'REG_NOTES' field of an insn.
  
! 'REG_CALL_NOCF_CHECK'
!      Users have control through the 'nocf_check' attribute to identify
       which calls to a function should be skipped from control-flow
!      instrumentation when the option '-fcf-protection=branch' is
!      specified.  The compiler puts a 'REG_CALL_NOCF_CHECK' note on each
!      'CALL_INSN' instruction that has a function type marked with a
!      'nocf_check' attribute.
  
!  For convenience, the machine mode in an 'insn_list' or 'expr_list' is
  printed using these symbolic codes in debugging dumps.
  
!  The only difference between the expression codes 'insn_list' and
! 'expr_list' is that the first operand of an 'insn_list' is assumed to be
  an insn and is printed in debugging dumps as the insn's unique id; the
! first operand of an 'expr_list' is printed in the ordinary way as an
  expression.
  
  
--- 19928,20011 ----
       or copies the final value.
  
       These two notes are used in different ways by the compiler passes.
!      ‘REG_EQUAL’ is used by passes prior to register allocation (such as
       common subexpression elimination and loop optimization) to tell
!      them how to think of that value.  ‘REG_EQUIV’ notes are used by
       register allocation to indicate that there is an available
!      substitute expression (either a constant or a ‘mem’ expression for
       the location of a parameter on the stack) that may be used in place
       of a register if insufficient registers are available.
  
       Except for stack homes for parameters, which are indicated by a
!      ‘REG_EQUIV’ note and are not useful to the early optimization
       passes and pseudo registers that are equivalent to a memory
       location throughout their entire life, which is not detected until
       later in the compilation, all equivalences are initially indicated
!      by an attached ‘REG_EQUAL’ note.  In the early stages of register
!      allocation, a ‘REG_EQUAL’ note is changed into a ‘REG_EQUIV’ note
       if OP is a constant and the insn represents the only set of its
       destination register.
  
       Thus, compiler passes prior to register allocation need only check
!      for ‘REG_EQUAL’ notes and passes subsequent to register allocation
!      need only check for ‘REG_EQUIV’ notes.
  
   These notes describe linkages between insns.  They occur in pairs: one
  insn has one of a pair of notes that points to a second insn, which has
  the inverse note pointing back to the first insn.
  
! ‘REG_DEP_TRUE’
       This indicates a true dependence (a read after write dependence).
  
! ‘REG_DEP_OUTPUT’
       This indicates an output dependence (a write after write
       dependence).
  
! ‘REG_DEP_ANTI’
       This indicates an anti dependence (a write after read dependence).
  
   These notes describe information gathered from gcov profile data.  They
! are stored in the ‘REG_NOTES’ field of an insn.
  
! ‘REG_BR_PROB’
       This is used to specify the ratio of branches to non-branches of a
       branch insn according to the profile data.  The note is represented
!      as an ‘int_list’ expression whose integer value is an encoding of
!      ‘profile_probability’ type.  ‘profile_probability’ provide member
!      function ‘from_reg_br_prob_note’ and ‘to_reg_br_prob_note’ to
       extract and store the probability into the RTL encoding.
  
! ‘REG_BR_PRED’
       These notes are found in JUMP insns after delayed branch scheduling
       has taken place.  They indicate both the direction and the
       likelihood of the JUMP.  The format is a bitmask of ATTR_FLAG_*
       values.
  
! ‘REG_FRAME_RELATED_EXPR’
       This is used on an RTX_FRAME_RELATED_P insn wherein the attached
       expression is used in place of the actual insn pattern.  This is
       done in cases where the pattern is either complex or misleading.
  
!  The note ‘REG_CALL_NOCF_CHECK’ is used in conjunction with the
! ‘-fcf-protection=branch’ option.  The note is set if a ‘nocf_check’
  attribute is specified for a function type or a pointer to function
! type.  The note is stored in the ‘REG_NOTES’ field of an insn.
  
! ‘REG_CALL_NOCF_CHECK’
!      Users have control through the ‘nocf_check’ attribute to identify
       which calls to a function should be skipped from control-flow
!      instrumentation when the option ‘-fcf-protection=branch’ is
!      specified.  The compiler puts a ‘REG_CALL_NOCF_CHECK’ note on each
!      ‘CALL_INSN’ instruction that has a function type marked with a
!      ‘nocf_check’ attribute.
  
!  For convenience, the machine mode in an ‘insn_list’ or ‘expr_list’ is
  printed using these symbolic codes in debugging dumps.
  
!  The only difference between the expression codes ‘insn_list’ and
! ‘expr_list’ is that the first operand of an ‘insn_list’ is assumed to be
  an insn and is printed in debugging dumps as the insn's unique id; the
! first operand of an ‘expr_list’ is printed in the ordinary way as an
  expression.
  
  
*************** File: gccint.info,  Node: Calls,  Next:
*** 20015,20038 ****
  14.20 RTL Representation of Function-Call Insns
  ===============================================
  
! Insns that call subroutines have the RTL expression code 'call_insn'.
  These insns must satisfy special rules, and their bodies must use a
! special RTL expression code, 'call'.
  
!  A 'call' expression has two operands, as follows:
  
       (call (mem:FM ADDR) NBYTES)
  
  Here NBYTES is an operand that represents the number of bytes of
  argument data being passed to the subroutine, FM is a machine mode
! (which must equal as the definition of the 'FUNCTION_MODE' macro in the
  machine description) and ADDR represents the address of the subroutine.
  
!  For a subroutine that returns no value, the 'call' expression as shown
  above is the entire body of the insn, except that the insn might also
! contain 'use' or 'clobber' expressions.
  
!  For a subroutine that returns a value whose mode is not 'BLKmode', the
  value is returned in a hard register.  If this register's number is R,
  then the body of the call insn looks like this:
  
--- 20014,20037 ----
  14.20 RTL Representation of Function-Call Insns
  ===============================================
  
! Insns that call subroutines have the RTL expression code ‘call_insn’.
  These insns must satisfy special rules, and their bodies must use a
! special RTL expression code, ‘call’.
  
!  A ‘call’ expression has two operands, as follows:
  
       (call (mem:FM ADDR) NBYTES)
  
  Here NBYTES is an operand that represents the number of bytes of
  argument data being passed to the subroutine, FM is a machine mode
! (which must equal as the definition of the ‘FUNCTION_MODE’ macro in the
  machine description) and ADDR represents the address of the subroutine.
  
!  For a subroutine that returns no value, the ‘call’ expression as shown
  above is the entire body of the insn, except that the insn might also
! contain ‘use’ or ‘clobber’ expressions.
  
!  For a subroutine that returns a value whose mode is not ‘BLKmode’, the
  value is returned in a hard register.  If this register's number is R,
  then the body of the call insn looks like this:
  
*************** then the body of the call insn looks lik
*** 20042,20071 ****
  This RTL expression makes it clear (to the optimizer passes) that the
  appropriate register receives a useful value in this insn.
  
!  When a subroutine returns a 'BLKmode' value, it is handled by passing
  to the subroutine the address of a place to store the value.  So the
  call insn itself does not "return" any value, and it has the same RTL
  form as a call that returns nothing.
  
   On some machines, the call instruction itself clobbers some register,
! for example to contain the return address.  'call_insn' insns on these
! machines should have a body which is a 'parallel' that contains both the
! 'call' expression and 'clobber' expressions that indicate which
  registers are destroyed.  Similarly, if the call instruction requires
  some register other than the stack pointer that is not explicitly
! mentioned in its RTL, a 'use' subexpression should mention that
  register.
  
   Functions that are called are assumed to modify all registers listed in
! the configuration macro 'CALL_USED_REGISTERS' (*note Register Basics::)
! and, with the exception of 'const' functions and library calls, to
  modify all of memory.
  
!  Insns containing just 'use' expressions directly precede the
! 'call_insn' insn to indicate which registers contain inputs to the
  function.  Similarly, if registers other than those in
! 'CALL_USED_REGISTERS' are clobbered by the called function, insns
! containing a single 'clobber' follow immediately after the call to
  indicate which registers.
  
  
--- 20041,20070 ----
  This RTL expression makes it clear (to the optimizer passes) that the
  appropriate register receives a useful value in this insn.
  
!  When a subroutine returns a ‘BLKmode’ value, it is handled by passing
  to the subroutine the address of a place to store the value.  So the
  call insn itself does not "return" any value, and it has the same RTL
  form as a call that returns nothing.
  
   On some machines, the call instruction itself clobbers some register,
! for example to contain the return address.  ‘call_insn’ insns on these
! machines should have a body which is a ‘parallel’ that contains both the
! ‘call’ expression and ‘clobber’ expressions that indicate which
  registers are destroyed.  Similarly, if the call instruction requires
  some register other than the stack pointer that is not explicitly
! mentioned in its RTL, a ‘use’ subexpression should mention that
  register.
  
   Functions that are called are assumed to modify all registers listed in
! the configuration macro ‘CALL_USED_REGISTERS’ (*note Register Basics::)
! and, with the exception of ‘const’ functions and library calls, to
  modify all of memory.
  
!  Insns containing just ‘use’ expressions directly precede the
! ‘call_insn’ insn to indicate which registers contain inputs to the
  function.  Similarly, if registers other than those in
! ‘CALL_USED_REGISTERS’ are clobbered by the called function, insns
! containing a single ‘clobber’ follow immediately after the call to
  indicate which registers.
  
  
*************** is used.  One way of obtaining this info
*** 20082,20088 ****
  form, which provides a Static Single Assignment representation of the
  RTL instructions.
  
!  The RTL SSA code is located in the 'rtl-ssa' subdirectory of the GCC
  source tree.  This section only gives a brief overview of it; please see
  the comments in the source code for more details.
  
--- 20081,20087 ----
  form, which provides a Static Single Assignment representation of the
  RTL instructions.
  
!  The RTL SSA code is located in the ‘rtl-ssa’ subdirectory of the GCC
  source tree.  This section only gives a brief overview of it; please see
  the comments in the source code for more details.
  
*************** following:
*** 20116,20122 ****
       #include "df.h"
       #include "rtl-ssa.h"
  
!  All the RTL SSA code is contained in the 'rtl_ssa' namespace, so most
  passes will then want to do:
  
       using namespace rtl_ssa;
--- 20115,20121 ----
       #include "df.h"
       #include "rtl-ssa.h"
  
!  All the RTL SSA code is contained in the ‘rtl_ssa’ namespace, so most
  passes will then want to do:
  
       using namespace rtl_ssa;
*************** applies on top of the normal RTL instruc
*** 20129,20142 ****
  individual RTL passes and is not maintained across passes.
  
   However, in order to allow the RTL SSA information to be preserved
! across passes in future, 'crtl->ssa' points to the current function's
  SSA form (if any).  Passes that want to use the RTL SSA form should
  first do:
  
       crtl->ssa = new rtl_ssa::function_info (FN);
  
   where FN is the function that the pass is processing.  (Passes that are
! 'using namespace rtl_ssa' do not need the 'rtl_ssa::'.)
  
   Once the pass has finished with the SSA form, it should do the
  following:
--- 20128,20141 ----
  individual RTL passes and is not maintained across passes.
  
   However, in order to allow the RTL SSA information to be preserved
! across passes in future, ‘crtl->ssa’ points to the current function's
  SSA form (if any).  Passes that want to use the RTL SSA form should
  first do:
  
       crtl->ssa = new rtl_ssa::function_info (FN);
  
   where FN is the function that the pass is processing.  (Passes that are
! ‘using namespace rtl_ssa’ do not need the ‘rtl_ssa::’.)
  
   Once the pass has finished with the SSA form, it should do the
  following:
*************** following:
*** 20148,20158 ****
       delete crtl->ssa;
       crtl->ssa = nullptr;
  
!  The 'free_dominance_info' call is necessary because dominance
  information is not currently maintained between RTL passes.  The next
  two lines commit any changes to the RTL instructions that were queued
  for later; see the comment above the declaration of
! 'perform_pending_updates' for details.  The final two lines discard the
  RTL SSA form and free the associated memory.
  
  
--- 20147,20157 ----
       delete crtl->ssa;
       crtl->ssa = nullptr;
  
!  The ‘free_dominance_info’ call is necessary because dominance
  information is not currently maintained between RTL passes.  The next
  two lines commit any changes to the RTL instructions that were queued
  for later; see the comment above the declaration of
! ‘perform_pending_updates’ for details.  The final two lines discard the
  RTL SSA form and free the associated memory.
  
  
*************** File: gccint.info,  Node: RTL SSA Instru
*** 20161,20167 ****
  14.21.2 RTL SSA Instructions
  ----------------------------
  
! RTL SSA instructions are represented by an 'rtl_ssa::insn_info'.  These
  instructions are chained together in a single list that follows a
  reverse postorder (RPO) traversal of the function.  This means that if
  any path through the function can execute an instruction I1 and then
--- 20160,20166 ----
  14.21.2 RTL SSA Instructions
  ----------------------------
  
! RTL SSA instructions are represented by an ‘rtl_ssa::insn_info’.  These
  instructions are chained together in a single list that follows a
  reverse postorder (RPO) traversal of the function.  This means that if
  any path through the function can execute an instruction I1 and then
*************** the C++ comparison operators, such as:
*** 20174,20180 ****
  
       *INSN1 < *INSN2
  
!  Another way is to use the 'compare_with' function:
  
       INSN1->compare_with (INSN2)
  
--- 20173,20179 ----
  
       *INSN1 < *INSN2
  
!  Another way is to use the ‘compare_with’ function:
  
       INSN1->compare_with (INSN2)
  
*************** RPO, less than zero if INSN1 comes befor
*** 20183,20189 ****
  INSN1 and INSN2 are the same.  This order is maintained even if
  instructions are added to the function or moved around.
  
!  The main purpose of 'rtl_ssa::insn_info' is to hold SSA information
  about an instruction.  However, it also caches certain properties of the
  instruction, such as whether it is an inline assembly instruction,
  whether it has volatile accesses, and so on.
--- 20182,20188 ----
  INSN1 and INSN2 are the same.  This order is maintained even if
  instructions are added to the function or moved around.
  
!  The main purpose of ‘rtl_ssa::insn_info’ is to hold SSA information
  about an instruction.  However, it also caches certain properties of the
  instruction, such as whether it is an inline assembly instruction,
  whether it has volatile accesses, and so on.
*************** File: gccint.info,  Node: RTL SSA Basic
*** 20200,20208 ****
  ----------------------------
  
  RTL SSA instructions (*note RTL SSA Instructions::) are organized into
! basic blocks, with each block being represented by an 'rtl_ssa:bb_info'.
! There is a one-to-one mapping between these 'rtl_ssa:bb_info' structures
! and the underlying CFG 'basic_block' structures (*note Basic Blocks::).
  
   If a CFG basic block BB contains an RTL instruction INSN, the RTL SSA
  represenation of BB also contains an RTL SSA representation of INSN(1).
--- 20199,20207 ----
  ----------------------------
  
  RTL SSA instructions (*note RTL SSA Instructions::) are organized into
! basic blocks, with each block being represented by an ‘rtl_ssa:bb_info’.
! There is a one-to-one mapping between these ‘rtl_ssa:bb_info’ structures
! and the underlying CFG ‘basic_block’ structures (*note Basic Blocks::).
  
   If a CFG basic block BB contains an RTL instruction INSN, the RTL SSA
  represenation of BB also contains an RTL SSA representation of INSN(1).
*************** postorder.  This list includes the entry
*** 20223,20229 ****
  first) and the exit block (which always comes last).
  
   RTL SSA basic blocks are chained together into "extended basic blocks"
! (EBBs), represented by an 'rtl_ssa::ebb_info'.  Extended basic blocks
  contain one or more basic blocks.  They have the property that if a
  block BBY comes immediately after a block BBX in an EBB, then BBY can
  only be reached by BBX; in other words, BBX is the sole predecessor of
--- 20222,20228 ----
  first) and the exit block (which always comes last).
  
   RTL SSA basic blocks are chained together into "extended basic blocks"
! (EBBs), represented by an ‘rtl_ssa::ebb_info’.  Extended basic blocks
  contain one or more basic blocks.  They have the property that if a
  block BBY comes immediately after a block BBX in an EBB, then BBY can
  only be reached by BBX; in other words, BBX is the sole predecessor of
*************** nodes because their live values can only
*** 20237,20259 ****
   The contents of a function are therefore represented using a four-level
  hierarchy:
  
!    * functions ('rtl_ssa::function_info'), which contain ...
  
!    * extended basic blocks ('rtl_ssa::ebb_info'), which contain ...
  
!    * basic blocks ('rtl_ssa::bb_info'), which contain ...
  
!    * instructions ('rtl_ssa::insn_info')
  
!  In dumps, a basic block is identified as 'bbN', where N is the index of
! the associated CFG 'basic_block' structure.  An EBB is in turn
  identified by the index of its first block.  For example, an EBB that
! contains 'bb10', 'bb5', 'bb6' and 'bb9' is identified as EBB10.
  
     ---------- Footnotes ----------
  
!    (1) Note that this excludes non-instruction things like 'note's and
! 'barrier's that also appear in the chain of RTL instructions.
  
  
  File: gccint.info,  Node: RTL SSA Resources,  Next: RTL SSA Accesses,  Prev: RTL SSA Basic Blocks,  Up: RTL SSA
--- 20236,20258 ----
   The contents of a function are therefore represented using a four-level
  hierarchy:
  
!    • functions (‘rtl_ssa::function_info’), which contain ...
  
!    • extended basic blocks (‘rtl_ssa::ebb_info’), which contain ...
  
!    • basic blocks (‘rtl_ssa::bb_info’), which contain ...
  
!    • instructions (‘rtl_ssa::insn_info’)
  
!  In dumps, a basic block is identified as ‘bbN’, where N is the index of
! the associated CFG ‘basic_block’ structure.  An EBB is in turn
  identified by the index of its first block.  For example, an EBB that
! contains ‘bb10’, ‘bb5’, ‘bb6’ and ‘bb9’ is identified as EBB10.
  
     ---------- Footnotes ----------
  
!    (1) Note that this excludes non-instruction things like ‘note’s and
! ‘barrier’s that also appear in the chain of RTL instructions.
  
  
  File: gccint.info,  Node: RTL SSA Resources,  Next: RTL SSA Accesses,  Prev: RTL SSA Basic Blocks,  Up: RTL SSA
*************** single unified resource, like it is in G
*** 20267,20280 ****
  
   Each resource has a unique identifier.  The unique identifier for a
  register is simply its register number.  The unique identifier for
! memory is a special register number called 'MEM_REGNO'.
  
   Since resource numbers so closely match register numbers, it is
  sometimes convenient to refer to them simply as register numbers, or
  "regnos" for short.  However, the RTL SSA form also provides an
! abstraction of resources in the form of 'rtl_ssa::resource_info'.  This
  is a lightweight class that records both the regno of a resource and the
! 'machine_mode' that the resource has (*note Machine Modes::).  It has
  functions for testing whether a resource is a register or memory.  In
  principle it could be extended to other kinds of resource in future.
  
--- 20266,20279 ----
  
   Each resource has a unique identifier.  The unique identifier for a
  register is simply its register number.  The unique identifier for
! memory is a special register number called ‘MEM_REGNO’.
  
   Since resource numbers so closely match register numbers, it is
  sometimes convenient to refer to them simply as register numbers, or
  "regnos" for short.  However, the RTL SSA form also provides an
! abstraction of resources in the form of ‘rtl_ssa::resource_info’.  This
  is a lightweight class that records both the regno of a resource and the
! ‘machine_mode’ that the resource has (*note Machine Modes::).  It has
  functions for testing whether a resource is a register or memory.  In
  principle it could be extended to other kinds of resource in future.
  
*************** File: gccint.info,  Node: RTL SSA Access
*** 20285,20291 ****
  --------------------------------------------
  
  In the RTL SSA form, most reads or writes of a resource are represented
! as a 'rtl_ssa::access_info'(1).  These 'rtl_ssa::access_info's are
  organized into the following class hierarchy:
  
       rtl_ssa::access_info
--- 20284,20290 ----
  --------------------------------------------
  
  In the RTL SSA form, most reads or writes of a resource are represented
! as a ‘rtl_ssa::access_info’(1).  These ‘rtl_ssa::access_info’s are
  organized into the following class hierarchy:
  
       rtl_ssa::access_info
*************** organized into the following class hiera
*** 20300,20328 ****
                     |
                     +-- rtl_ssa::phi_info
  
!  A 'rtl_ssa::use_info' represents a read or use of a resource and a
! 'rtl_ssa::def_info' represents a write or definition of a resource.  As
  in the main RTL representation, there are two basic types of definition:
  clobbers and sets.  The difference is that a clobber leaves the register
  with an unspecified value that cannot be used or relied on by later
  instructions, while a set leaves the register with a known value that
  later instructions could use if they wanted to.  A
! 'rtl_ssa::clobber_info' represents a clobber and a 'rtl_ssa::set_info'
  represent a set.
  
!  Each 'rtl_ssa::use_info' records which single 'rtl_ssa::set_info'
  provides the value of the resource; this is null if the resource is
! completely undefined at the point of use.  Each 'rtl_ssa::set_info' in
! turn records all the 'rtl_ssa::use_info's that use its value.
  
   If a value of a resource can come from multiple sources, a
! 'rtl_ssa::phi_info' brings those multiple sources together into a single
  definition (*note RTL SSA Phi Nodes::).
  
     ---------- Footnotes ----------
  
     (1) The exceptions are call clobbers, which are generally represented
! separately.  See the comment above 'rtl_ssa::insn_info' for details.
  
  
  File: gccint.info,  Node: RTL SSA Phi Nodes,  Next: RTL SSA Access Lists,  Prev: RTL SSA Accesses,  Up: RTL SSA
--- 20299,20327 ----
                     |
                     +-- rtl_ssa::phi_info
  
!  A ‘rtl_ssa::use_info’ represents a read or use of a resource and a
! ‘rtl_ssa::def_info’ represents a write or definition of a resource.  As
  in the main RTL representation, there are two basic types of definition:
  clobbers and sets.  The difference is that a clobber leaves the register
  with an unspecified value that cannot be used or relied on by later
  instructions, while a set leaves the register with a known value that
  later instructions could use if they wanted to.  A
! ‘rtl_ssa::clobber_info’ represents a clobber and a ‘rtl_ssa::set_info’
  represent a set.
  
!  Each ‘rtl_ssa::use_info’ records which single ‘rtl_ssa::set_info’
  provides the value of the resource; this is null if the resource is
! completely undefined at the point of use.  Each ‘rtl_ssa::set_info’ in
! turn records all the ‘rtl_ssa::use_info’s that use its value.
  
   If a value of a resource can come from multiple sources, a
! ‘rtl_ssa::phi_info’ brings those multiple sources together into a single
  definition (*note RTL SSA Phi Nodes::).
  
     ---------- Footnotes ----------
  
     (1) The exceptions are call clobbers, which are generally represented
! separately.  See the comment above ‘rtl_ssa::insn_info’ for details.
  
  
  File: gccint.info,  Node: RTL SSA Phi Nodes,  Next: RTL SSA Access Lists,  Prev: RTL SSA Accesses,  Up: RTL SSA
*************** This is in contrast to a native SSA repr
*** 20371,20378 ****
  the phi inputs can be arbitrary expressions.  As a result, RTL SSA phi
  nodes never involve "hidden" moves: all moves are instead explicit.
  
!  Phi nodes are represented as a 'rtl_ssa::phi_node'.  Each input to a
! phi node is represented as an 'rtl_ssa::use_info'.
  
  
  File: gccint.info,  Node: RTL SSA Access Lists,  Next: Changing RTL Instructions,  Prev: RTL SSA Phi Nodes,  Up: RTL SSA
--- 20370,20377 ----
  the phi inputs can be arbitrary expressions.  As a result, RTL SSA phi
  nodes never involve "hidden" moves: all moves are instead explicit.
  
!  Phi nodes are represented as a ‘rtl_ssa::phi_node’.  Each input to a
! phi node is represented as an ‘rtl_ssa::use_info’.
  
  
  File: gccint.info,  Node: RTL SSA Access Lists,  Next: Changing RTL Instructions,  Prev: RTL SSA Phi Nodes,  Up: RTL SSA
*************** File: gccint.info,  Node: RTL SSA Access
*** 20382,20393 ****
  
  All the definitions of a resource are chained together in reverse
  postorder.  In general, this list can contain an arbitrary mix of both
! sets ('rtl_ssa::set_info') and clobbers ('rtl_ssa::clobber_info').
  However, it is often useful to skip over all intervening clobbers of a
  resource in order to find the next set.  The list is constructed in such
  a way that this can be done in amortized constant time.
  
!  All uses ('rtl_ssa::use_info') of a given set are also chained together
  into a list.  This list of uses is divided into three parts:
  
    1. uses by "real" nondebug instructions (*note real RTL SSA insns::)
--- 20381,20392 ----
  
  All the definitions of a resource are chained together in reverse
  postorder.  In general, this list can contain an arbitrary mix of both
! sets (‘rtl_ssa::set_info’) and clobbers (‘rtl_ssa::clobber_info’).
  However, it is often useful to skip over all intervening clobbers of a
  resource in order to find the next set.  The list is constructed in such
  a way that this can be done in amortized constant time.
  
!  All uses (‘rtl_ssa::use_info’) of a given set are also chained together
  into a list.  This list of uses is divided into three parts:
  
    1. uses by "real" nondebug instructions (*note real RTL SSA insns::)
*************** third part has no particular order.
*** 20403,20438 ****
  reverse postorder than the next definition of the resource (if any).
  This means that the accesses follow a linear sequence of the form:
  
!    * first definition of resource R
  
!         * first use by a real nondebug instruction of the first
            definition of resource R
  
!         * ...
  
!         * last use by a real nondebug instruction of the first
            definition of resource R
  
!    * second definition of resource R
  
!         * first use by a real nondebug instruction of the second
            definition of resource R
  
!         * ...
  
!         * last use by a real nondebug instruction of the second
            definition of resource R
  
!    * ...
  
!    * last definition of resource R
  
!         * first use by a real nondebug instruction of the last
            definition of resource R
  
!         * ...
  
!         * last use by a real nondebug instruction of the last definition
            of resource R
  
   (Note that clobbers never have uses; only sets do.)
--- 20402,20437 ----
  reverse postorder than the next definition of the resource (if any).
  This means that the accesses follow a linear sequence of the form:
  
!    • first definition of resource R
  
!         • first use by a real nondebug instruction of the first
            definition of resource R
  
!         • ...
  
!         • last use by a real nondebug instruction of the first
            definition of resource R
  
!    • second definition of resource R
  
!         • first use by a real nondebug instruction of the second
            definition of resource R
  
!         • ...
  
!         • last use by a real nondebug instruction of the second
            definition of resource R
  
!    • ...
  
!    • last definition of resource R
  
!         • first use by a real nondebug instruction of the last
            definition of resource R
  
!         • ...
  
!         • last use by a real nondebug instruction of the last definition
            of resource R
  
   (Note that clobbers never have uses; only sets do.)
*************** following:
*** 20459,20474 ****
  
   The list of accesses would begin as follows:
  
!    * definition of R by A
  
!         * use of A's definition of R by B
  
!    * definition of R by C
  
   The next access to R is in D, but the value of R that D uses comes from
  A rather than C.
  
!  This is resolved by adding a phi node for 'ebb4'.  All inputs to this
  phi node have the same value, which in the example above is A's
  definition of R.  In other circumstances, it would not be necessary to
  create a phi node when all inputs are equal, so these phi nodes are
--- 20458,20473 ----
  
   The list of accesses would begin as follows:
  
!    • definition of R by A
  
!         • use of A's definition of R by B
  
!    • definition of R by C
  
   The next access to R is in D, but the value of R that D uses comes from
  A rather than C.
  
!  This is resolved by adding a phi node for ‘ebb4’.  All inputs to this
  phi node have the same value, which in the example above is A's
  definition of R.  In other circumstances, it would not be necessary to
  create a phi node when all inputs are equal, so these phi nodes are
*************** referred to as "degenerate" phi nodes.
*** 20476,20498 ****
  
   The full list of accesses to R is therefore:
  
!    * definition of R by A
  
!         * use of A's definition of R by B
  
!    * definition of R by C
  
!    * definition of R by ebb4's phi instruction, with the input coming
       from A
  
!         * use of the ebb4's R phi definition of R by B
  
   Note that A's definition is also used by ebb4's phi node, but this use
  belongs to the third part of the use list described above and so does
  not form part of the linear sequence.
  
   It is possible to "look through" any degenerate phi to the ultimate
! definition using the function 'look_through_degenerate_phi'.  Note that
  the input to a degenerate phi is never itself provided by a degenerate
  phi.
  
--- 20475,20497 ----
  
   The full list of accesses to R is therefore:
  
!    • definition of R by A
  
!         • use of A's definition of R by B
  
!    • definition of R by C
  
!    • definition of R by ebb4's phi instruction, with the input coming
       from A
  
!         • use of the ebb4's R phi definition of R by B
  
   Note that A's definition is also used by ebb4's phi node, but this use
  belongs to the third part of the use list described above and so does
  not form part of the linear sequence.
  
   It is possible to "look through" any degenerate phi to the ultimate
! definition using the function ‘look_through_degenerate_phi’.  Note that
  the input to a degenerate phi is never itself provided by a degenerate
  phi.
  
*************** phi.
*** 20500,20510 ****
  guarantees that, for any given resource RES, one of the following is
  true:
  
!    * The resource has a single definition DEF, which is not a phi node.
       Excluding uses of undefined registers, all uses of RES by real
       nondebug instructions use the value provided by DEF.
  
!    * Excluding uses of undefined registers, all uses of RES use values
       provided by definitions that occur earlier in the same extended
       basic block.  These definitions might come from phi nodes or from
       real instructions.
--- 20499,20509 ----
  guarantees that, for any given resource RES, one of the following is
  true:
  
!    • The resource has a single definition DEF, which is not a phi node.
       Excluding uses of undefined registers, all uses of RES by real
       nondebug instructions use the value provided by DEF.
  
!    • Excluding uses of undefined registers, all uses of RES use values
       provided by definitions that occur earlier in the same extended
       basic block.  These definitions might come from phi nodes or from
       real instructions.
*************** following:
*** 20537,20574 ****
  
       auto attempt = crtl->ssa->new_change_attempt ();
  
!  Here, 'attempt' is an RAII object that should remain in scope for the
  entire change attempt.  It automatically frees temporary memory related
  to the changes when it goes out of scope.
  
!  Next, the pass should create an 'rtl_ssa::insn_change' object for the
  instruction that it wants to change.  This object specifies several
  things:
  
!    * what the instruction's new list of uses should be ('new_uses').  By
       default this is the same as the instruction's current list of uses.
  
!    * what the instruction's new list of definitions should be
!      ('new_defs').  By default this is the same as the instruction's
       current list of definitions.
  
!    * where the instruction should be located ('move_range').  This is a
       range of instructions after which the instruction could be placed,
!      represented as an 'rtl_ssa::insn_range'.  By default the
       instruction must remain at its current position.
  
   If a pass was attempting to change all these properties of an
! instruction 'insn', it might do something like this:
  
       rtl_ssa::insn_change change (insn);
       change.new_defs = ...;
       change.new_uses = ...;
       change.move_range = ...;
  
!  This 'rtl_ssa::insn_change' only describes something that the pass
  _might_ do; at this stage, nothing has actually changed.
  
!  As noted above, the default 'move_range' requires the instruction to
  remain where it is.  At the other extreme, it is possible to allow the
  instruction to move anywhere within its extended basic block, provided
  that all the new uses and definitions can be performed at the new
--- 20536,20573 ----
  
       auto attempt = crtl->ssa->new_change_attempt ();
  
!  Here, ‘attempt’ is an RAII object that should remain in scope for the
  entire change attempt.  It automatically frees temporary memory related
  to the changes when it goes out of scope.
  
!  Next, the pass should create an ‘rtl_ssa::insn_change’ object for the
  instruction that it wants to change.  This object specifies several
  things:
  
!    • what the instruction's new list of uses should be (‘new_uses’).  By
       default this is the same as the instruction's current list of uses.
  
!    • what the instruction's new list of definitions should be
!      (‘new_defs’).  By default this is the same as the instruction's
       current list of definitions.
  
!    • where the instruction should be located (‘move_range’).  This is a
       range of instructions after which the instruction could be placed,
!      represented as an ‘rtl_ssa::insn_range’.  By default the
       instruction must remain at its current position.
  
   If a pass was attempting to change all these properties of an
! instruction ‘insn’, it might do something like this:
  
       rtl_ssa::insn_change change (insn);
       change.new_defs = ...;
       change.new_uses = ...;
       change.move_range = ...;
  
!  This ‘rtl_ssa::insn_change’ only describes something that the pass
  _might_ do; at this stage, nothing has actually changed.
  
!  As noted above, the default ‘move_range’ requires the instruction to
  remain where it is.  At the other extreme, it is possible to allow the
  instruction to move anywhere within its extended basic block, provided
  that all the new uses and definitions can be performed at the new
*************** consistent with the new uses and definit
*** 20582,20602 ****
       if (!rtl_ssa::restrict_movement (change))
         return false;
  
!  This function tries to limit 'move_range' to a range of instructions at
! which 'new_uses' and 'new_defs' can be correctly performed.  It returns
  true on success or false if no suitable location exists.
  
   The pass should also tentatively change the pattern of the instruction
  to whatever form the pass wants the instruction to have.  This should
! use the facilities provided by 'recog.cc'.  For example:
  
       rtl_insn *rtl = insn->rtl ();
       insn_change_watermark watermark;
       validate_change (rtl, &PATTERN (rtl), new_pat, 1);
  
!  will tentatively replace 'insn''s pattern with 'new_pat'.
  
!  These changes and the construction of the 'rtl_ssa::insn_change' can
  happen in either order or be interleaved.
  
   After the tentative changes to the instruction are complete, the pass
--- 20581,20601 ----
       if (!rtl_ssa::restrict_movement (change))
         return false;
  
!  This function tries to limit ‘move_range’ to a range of instructions at
! which ‘new_uses’ and ‘new_defs’ can be correctly performed.  It returns
  true on success or false if no suitable location exists.
  
   The pass should also tentatively change the pattern of the instruction
  to whatever form the pass wants the instruction to have.  This should
! use the facilities provided by ‘recog.cc’.  For example:
  
       rtl_insn *rtl = insn->rtl ();
       insn_change_watermark watermark;
       validate_change (rtl, &PATTERN (rtl), new_pat, 1);
  
!  will tentatively replace ‘insn’'s pattern with ‘new_pat’.
  
!  These changes and the construction of the ‘rtl_ssa::insn_change’ can
  happen in either order or be interleaved.
  
   After the tentative changes to the instruction are complete, the pass
*************** satisfies the requirements of an inline
*** 20610,20627 ****
  it match.  It might also add new definitions or restrict the range of
  the move.  For example, if the new pattern did not match in its original
  form, but could be made to match by adding a clobber of the flags
! register, 'rtl_ssa::recog' will check whether the flags register is free
  at an appropriate point.  If so, it will add a clobber of the flags
! register to 'new_defs' and restrict 'move_range' to the locations at
  which the flags register can be safely clobbered.
  
   Even if the proposed new instruction is valid according to
! 'rtl_ssa::recog', the change might not be worthwhile.  For example, when
  optimizing for speed, the new instruction might turn out to be slower
  than the original one.  When optimizing for size, the new instruction
  might turn out to be bigger than the original one.
  
!  Passes should check for this case using 'change_is_worthwhile'.  For
  example:
  
       if (!rtl_ssa::change_is_worthwhile (change))
--- 20609,20626 ----
  it match.  It might also add new definitions or restrict the range of
  the move.  For example, if the new pattern did not match in its original
  form, but could be made to match by adding a clobber of the flags
! register, ‘rtl_ssa::recog’ will check whether the flags register is free
  at an appropriate point.  If so, it will add a clobber of the flags
! register to ‘new_defs’ and restrict ‘move_range’ to the locations at
  which the flags register can be safely clobbered.
  
   Even if the proposed new instruction is valid according to
! ‘rtl_ssa::recog’, the change might not be worthwhile.  For example, when
  optimizing for speed, the new instruction might turn out to be slower
  than the original one.  When optimizing for size, the new instruction
  might turn out to be bigger than the original one.
  
!  Passes should check for this case using ‘change_is_worthwhile’.  For
  example:
  
       if (!rtl_ssa::change_is_worthwhile (change))
*************** Instruction::).  The pass should again s
*** 20667,20678 ****
  
       auto attempt = crtl->ssa->new_change_attempt ();
  
!  and keep 'attempt' in scope for the duration of the change attempt.  It
! should then construct an 'rtl_ssa::insn_change' for each change that it
  wants to make.
  
   After this, it should combine the changes into a sequence of
! 'rtl_ssa::insn_change' pointers.  This sequence must be in reverse
  postorder; the instructions will remain strictly in the order that the
  sequence specifies.
  
--- 20666,20677 ----
  
       auto attempt = crtl->ssa->new_change_attempt ();
  
!  and keep ‘attempt’ in scope for the duration of the change attempt.  It
! should then construct an ‘rtl_ssa::insn_change’ for each change that it
  wants to make.
  
   After this, it should combine the changes into a sequence of
! ‘rtl_ssa::insn_change’ pointers.  This sequence must be in reverse
  postorder; the instructions will remain strictly in the order that the
  sequence specifies.
  
*************** do:
*** 20681,20692 ****
  
       rtl_ssa::insn_change *changes[] = { &change1, change2 };
  
!  where 'change1''s instruction must come before 'change2''s.
  Alternatively, if the pass is changing a variable number of
  instructions, it might build up the sequence in a
! 'vec'.
  
!  By default, 'rtl_ssa::restrict_movement' assumes that all instructions
  other than the one passed to it will remain in their current positions
  and will retain their current uses and definitions.  When changing
  multiple instructions, it is usually more effective to ignore the other
--- 20680,20691 ----
  
       rtl_ssa::insn_change *changes[] = { &change1, change2 };
  
!  where ‘change1’'s instruction must come before ‘change2’'s.
  Alternatively, if the pass is changing a variable number of
  instructions, it might build up the sequence in a
! ‘vec’.
  
!  By default, ‘rtl_ssa::restrict_movement’ assumes that all instructions
  other than the one passed to it will remain in their current positions
  and will retain their current uses and definitions.  When changing
  multiple instructions, it is usually more effective to ignore the other
*************** to each other.  The way to do this is:
*** 20697,20703 ****
       if (!rtl_ssa::restrict_movement (change, insn_is_changing (changes)))
         return false;
  
!  Similarly, when 'rtl_ssa::restrict_movement' is detecting whether a
  register can be clobbered, it by default assumes that all other
  instructions will remain in their current positions and retain their
  current form.  It is again more effective to ignore changing
--- 20696,20702 ----
       if (!rtl_ssa::restrict_movement (change, insn_is_changing (changes)))
         return false;
  
!  Similarly, when ‘rtl_ssa::restrict_movement’ is detecting whether a
  register can be clobbered, it by default assumes that all other
  instructions will remain in their current positions and retain their
  current form.  It is again more effective to ignore changing
*************** changes as a whole are worthwhile.  The
*** 20715,20724 ****
         return false;
  
   The process for changing single instructions makes sure that one
! 'rtl_ssa::insn_change' in isolation is valid.  But when changing
  multiple instructions, it is also necessary to test whether the sequence
  as a whole is valid.  For example, it might be impossible to satisfy all
! of the 'move_range's at once.
  
   Therefore, once the pass has a sequence of changes that are
  individually correct, it should use:
--- 20714,20723 ----
         return false;
  
   The process for changing single instructions makes sure that one
! ‘rtl_ssa::insn_change’ in isolation is valid.  But when changing
  multiple instructions, it is also necessary to test whether the sequence
  as a whole is valid.  For example, it might be impossible to satisfy all
! of the ‘move_range’s at once.
  
   Therefore, once the pass has a sequence of changes that are
  individually correct, it should use:
*************** objects that describe global variables a
*** 20782,20839 ****
  standard objects such as small integer constants, no RTL objects are
  common to two functions.
  
!    * Each pseudo-register has only a single 'reg' object to represent
       it, and therefore only a single machine mode.
  
!    * For any symbolic label, there is only one 'symbol_ref' object
       referring to it.
  
!    * All 'const_int' expressions with equal values are shared.
  
!    * All 'const_poly_int' expressions with equal modes and values are
       shared.
  
!    * There is only one 'pc' expression.
  
!    * There is only one 'const_double' expression with value 0 for each
       floating point mode.  Likewise for values 1 and 2.
  
!    * There is only one 'const_vector' expression with value 0 for each
       vector mode, be it an integer or a double constant vector.
  
!    * No 'label_ref' or 'scratch' appears in more than one place in the
       RTL structure; in other words, it is safe to do a tree-walk of all
!      the insns in the function and assume that each time a 'label_ref'
!      or 'scratch' is seen it is distinct from all others that are seen.
  
!    * Only one 'mem' object is normally created for each static variable
       or stack slot, so these objects are frequently shared in all the
       places they appear.  However, separate but equal objects for these
       variables are occasionally made.
  
!    * When a single 'asm' statement has multiple output operands, a
!      distinct 'asm_operands' expression is made for each output operand.
       However, these all share the vector which contains the sequence of
       input operands.  This sharing is used later on to test whether two
!      'asm_operands' expressions come from the same statement, so all
       optimizations must carefully preserve the sharing if they copy the
       vector at all.
  
!    * No RTL object appears in more than one place in the RTL structure
       except as described above.  Many passes of the compiler rely on
       this by assuming that they can modify RTL objects in place without
       unwanted side-effects on other insns.
  
!    * During initial RTL generation, shared structure is freely
       introduced.  After all the RTL for a function has been generated,
!      all shared structure is copied by 'unshare_all_rtl' in
!      'emit-rtl.cc', after which the above rules are guaranteed to be
       followed.
  
!    * During the combiner pass, shared structure within an insn can exist
       temporarily.  However, the shared structure is copied before the
       combiner is finished with the insn.  This is done by calling
!      'copy_rtx_if_shared', which is a subroutine of 'unshare_all_rtl'.
  
  
  File: gccint.info,  Node: Reading RTL,  Prev: Sharing,  Up: RTL
--- 20781,20838 ----
  standard objects such as small integer constants, no RTL objects are
  common to two functions.
  
!    • Each pseudo-register has only a single ‘reg’ object to represent
       it, and therefore only a single machine mode.
  
!    • For any symbolic label, there is only one ‘symbol_ref’ object
       referring to it.
  
!    • All ‘const_int’ expressions with equal values are shared.
  
!    • All ‘const_poly_int’ expressions with equal modes and values are
       shared.
  
!    • There is only one ‘pc’ expression.
  
!    • There is only one ‘const_double’ expression with value 0 for each
       floating point mode.  Likewise for values 1 and 2.
  
!    • There is only one ‘const_vector’ expression with value 0 for each
       vector mode, be it an integer or a double constant vector.
  
!    • No ‘label_ref’ or ‘scratch’ appears in more than one place in the
       RTL structure; in other words, it is safe to do a tree-walk of all
!      the insns in the function and assume that each time a ‘label_ref’
!      or ‘scratch’ is seen it is distinct from all others that are seen.
  
!    • Only one ‘mem’ object is normally created for each static variable
       or stack slot, so these objects are frequently shared in all the
       places they appear.  However, separate but equal objects for these
       variables are occasionally made.
  
!    • When a single ‘asm’ statement has multiple output operands, a
!      distinct ‘asm_operands’ expression is made for each output operand.
       However, these all share the vector which contains the sequence of
       input operands.  This sharing is used later on to test whether two
!      ‘asm_operands’ expressions come from the same statement, so all
       optimizations must carefully preserve the sharing if they copy the
       vector at all.
  
!    • No RTL object appears in more than one place in the RTL structure
       except as described above.  Many passes of the compiler rely on
       this by assuming that they can modify RTL objects in place without
       unwanted side-effects on other insns.
  
!    • During initial RTL generation, shared structure is freely
       introduced.  After all the RTL for a function has been generated,
!      all shared structure is copied by ‘unshare_all_rtl’ in
!      ‘emit-rtl.cc’, after which the above rules are guaranteed to be
       followed.
  
!    • During the combiner pass, shared structure within an insn can exist
       temporarily.  However, the shared structure is copied before the
       combiner is finished with the insn.  This is done by calling
!      ‘copy_rtx_if_shared’, which is a subroutine of ‘unshare_all_rtl’.
  
  
  File: gccint.info,  Node: Reading RTL,  Prev: Sharing,  Up: RTL
*************** File: gccint.info,  Node: Reading RTL,
*** 20841,20849 ****
  14.23 Reading RTL
  =================
  
! To read an RTL object from a file, call 'read_rtx'.  It takes one
  argument, a stdio stream, and returns a single RTL object.  This routine
! is defined in 'read-rtl.cc'.  It is not available in the compiler
  itself, only the various programs that generate the compiler back end
  from the machine description.
  
--- 20840,20848 ----
  14.23 Reading RTL
  =================
  
! To read an RTL object from a file, call ‘read_rtx’.  It takes one
  argument, a stdio stream, and returns a single RTL object.  This routine
! is defined in ‘read-rtl.cc’.  It is not available in the compiler
  itself, only the various programs that generate the compiler back end
  from the machine description.
  
*************** program is very dependent on the particu
*** 20856,20862 ****
  does not contain all the information about the program.
  
   The proper way to interface GCC to a new language front end is with the
! "tree" data structure, described in the files 'tree.h' and 'tree.def'.
  The documentation for this structure (*note GENERIC::) is incomplete.
  
  
--- 20855,20861 ----
  does not contain all the information about the program.
  
   The proper way to interface GCC to a new language front end is with the
! "tree" data structure, described in the files ‘tree.h’ and ‘tree.def’.
  The documentation for this structure (*note GENERIC::) is incomplete.
  
  
*************** File: gccint.info,  Node: Control Flow,
*** 20866,20886 ****
  *********************
  
  A control flow graph (CFG) is a data structure built on top of the
! intermediate code representation (the RTL or 'GIMPLE' instruction
  stream) abstracting the control flow behavior of a function that is
  being compiled.  The CFG is a directed graph where the vertices
  represent basic blocks and edges represent possible transfer of control
  flow from one basic block to another.  The data structures used to
! represent the control flow graph are defined in 'basic-block.h'.
  
   In GCC, the representation of control flow is maintained throughout the
! compilation process, from constructing the CFG early in 'pass_build_cfg'
! to 'pass_free_cfg' (see 'passes.def').  The CFG takes various different
  modes and may undergo extensive manipulations, but the graph is always
  valid between its construction and its release.  This way, transfer of
  information such as data flow, a measured profile, or the loop tree, can
! be propagated through the passes pipeline, and even from 'GIMPLE' to
! 'RTL'.
  
   Often the CFG may be better viewed as integral part of instruction
  chain, than structure built on the top of it.  Updating the compiler's
--- 20865,20885 ----
  *********************
  
  A control flow graph (CFG) is a data structure built on top of the
! intermediate code representation (the RTL or ‘GIMPLE’ instruction
  stream) abstracting the control flow behavior of a function that is
  being compiled.  The CFG is a directed graph where the vertices
  represent basic blocks and edges represent possible transfer of control
  flow from one basic block to another.  The data structures used to
! represent the control flow graph are defined in ‘basic-block.h’.
  
   In GCC, the representation of control flow is maintained throughout the
! compilation process, from constructing the CFG early in ‘pass_build_cfg’
! to ‘pass_free_cfg’ (see ‘passes.def’).  The CFG takes various different
  modes and may undergo extensive manipulations, but the graph is always
  valid between its construction and its release.  This way, transfer of
  information such as data flow, a measured profile, or the loop tree, can
! be propagated through the passes pipeline, and even from ‘GIMPLE’ to
! ‘RTL’.
  
   Often the CFG may be better viewed as integral part of instruction
  chain, than structure built on the top of it.  Updating the compiler's
*************** File: gccint.info,  Node: Basic Blocks,
*** 20903,20965 ****
  
  A basic block is a straight-line sequence of code with only one entry
  point and only one exit.  In GCC, basic blocks are represented using the
! 'basic_block' data type.
  
   Special basic blocks represent possible entry and exit points of a
! function.  These blocks are called 'ENTRY_BLOCK_PTR' and
! 'EXIT_BLOCK_PTR'.  These blocks do not contain any code.
  
!  The 'BASIC_BLOCK' array contains all basic blocks in an unspecified
! order.  Each 'basic_block' structure has a field that holds a unique
! integer identifier 'index' that is the index of the block in the
! 'BASIC_BLOCK' array.  The total number of basic blocks in the function
! is 'n_basic_blocks'.  Both the basic block indices and the total number
  of basic blocks may vary during the compilation process, as passes
  reorder, create, duplicate, and destroy basic blocks.  The index for any
! block should never be greater than 'last_basic_block'.  The indices 0
! and 1 are special codes reserved for 'ENTRY_BLOCK' and 'EXIT_BLOCK', the
! indices of 'ENTRY_BLOCK_PTR' and 'EXIT_BLOCK_PTR'.
  
!  Two pointer members of the 'basic_block' structure are the pointers
! 'next_bb' and 'prev_bb'.  These are used to keep doubly linked chain of
  basic blocks in the same order as the underlying instruction stream.
  The chain of basic blocks is updated transparently by the provided API
! for manipulating the CFG.  The macro 'FOR_EACH_BB' can be used to visit
! all the basic blocks in lexicographical order, except 'ENTRY_BLOCK' and
! 'EXIT_BLOCK'.  The macro 'FOR_ALL_BB' also visits all basic blocks in
! lexicographical order, including 'ENTRY_BLOCK' and 'EXIT_BLOCK'.
  
!  The functions 'post_order_compute' and 'inverted_post_order_compute'
  can be used to compute topological orders of the CFG. The orders are
! stored as vectors of basic block indices.  The 'BASIC_BLOCK' array can
  be used to iterate each basic block by index.  Dominator traversals are
! also possible using 'walk_dominator_tree'.  Given two basic blocks A and
  B, block A dominates block B if A is _always_ executed before B.
  
!  Each 'basic_block' also contains pointers to the first instruction (the
! "head") and the last instruction (the "tail") or "end" of the
  instruction stream contained in a basic block.  In fact, since the
! 'basic_block' data type is used to represent blocks in both major
! intermediate representations of GCC ('GIMPLE' and RTL), there are
  pointers to the head and end of a basic block for both representations,
! stored in intermediate representation specific data in the 'il' field of
! 'struct basic_block_def'.
  
!  For RTL, these pointers are 'BB_HEAD' and 'BB_END'.
  
   In the RTL representation of a function, the instruction stream
! contains not only the "real" instructions, but also "notes" or "insn
! notes" (to distinguish them from "reg notes").  Any function that moves
  or duplicates the basic blocks needs to take care of updating of these
  notes.  Many of these notes expect that the instruction stream consists
  of linear regions, so updating can sometimes be tedious.  All types of
! insn notes are defined in 'insn-notes.def'.
  
   In the RTL function representation, the instructions contained in a
! basic block always follow a 'NOTE_INSN_BASIC_BLOCK', but zero or more
! 'CODE_LABEL' nodes can precede the block note.  A basic block ends with
  a control flow instruction or with the last instruction before the next
! 'CODE_LABEL' or 'NOTE_INSN_BASIC_BLOCK'.  By definition, a 'CODE_LABEL'
  cannot appear in the middle of the instruction stream of a basic block.
  
   In addition to notes, the jump table vectors are also represented as
--- 20902,20964 ----
  
  A basic block is a straight-line sequence of code with only one entry
  point and only one exit.  In GCC, basic blocks are represented using the
! ‘basic_block’ data type.
  
   Special basic blocks represent possible entry and exit points of a
! function.  These blocks are called ‘ENTRY_BLOCK_PTR’ and
! ‘EXIT_BLOCK_PTR’.  These blocks do not contain any code.
  
!  The ‘BASIC_BLOCK’ array contains all basic blocks in an unspecified
! order.  Each ‘basic_block’ structure has a field that holds a unique
! integer identifier ‘index’ that is the index of the block in the
! ‘BASIC_BLOCK’ array.  The total number of basic blocks in the function
! is ‘n_basic_blocks’.  Both the basic block indices and the total number
  of basic blocks may vary during the compilation process, as passes
  reorder, create, duplicate, and destroy basic blocks.  The index for any
! block should never be greater than ‘last_basic_block’.  The indices 0
! and 1 are special codes reserved for ‘ENTRY_BLOCK’ and ‘EXIT_BLOCK’, the
! indices of ‘ENTRY_BLOCK_PTR’ and ‘EXIT_BLOCK_PTR’.
  
!  Two pointer members of the ‘basic_block’ structure are the pointers
! ‘next_bb’ and ‘prev_bb’.  These are used to keep doubly linked chain of
  basic blocks in the same order as the underlying instruction stream.
  The chain of basic blocks is updated transparently by the provided API
! for manipulating the CFG.  The macro ‘FOR_EACH_BB’ can be used to visit
! all the basic blocks in lexicographical order, except ‘ENTRY_BLOCK’ and
! ‘EXIT_BLOCK’.  The macro ‘FOR_ALL_BB’ also visits all basic blocks in
! lexicographical order, including ‘ENTRY_BLOCK’ and ‘EXIT_BLOCK’.
  
!  The functions ‘post_order_compute’ and ‘inverted_post_order_compute’
  can be used to compute topological orders of the CFG. The orders are
! stored as vectors of basic block indices.  The ‘BASIC_BLOCK’ array can
  be used to iterate each basic block by index.  Dominator traversals are
! also possible using ‘walk_dominator_tree’.  Given two basic blocks A and
  B, block A dominates block B if A is _always_ executed before B.
  
!  Each ‘basic_block’ also contains pointers to the first instruction (the
! “head”) and the last instruction (the “tail”) or “end” of the
  instruction stream contained in a basic block.  In fact, since the
! ‘basic_block’ data type is used to represent blocks in both major
! intermediate representations of GCC (‘GIMPLE’ and RTL), there are
  pointers to the head and end of a basic block for both representations,
! stored in intermediate representation specific data in the ‘il’ field of
! ‘struct basic_block_def’.
  
!  For RTL, these pointers are ‘BB_HEAD’ and ‘BB_END’.
  
   In the RTL representation of a function, the instruction stream
! contains not only the "real" instructions, but also “notes” or “insn
! notes” (to distinguish them from “reg notes”).  Any function that moves
  or duplicates the basic blocks needs to take care of updating of these
  notes.  Many of these notes expect that the instruction stream consists
  of linear regions, so updating can sometimes be tedious.  All types of
! insn notes are defined in ‘insn-notes.def’.
  
   In the RTL function representation, the instructions contained in a
! basic block always follow a ‘NOTE_INSN_BASIC_BLOCK’, but zero or more
! ‘CODE_LABEL’ nodes can precede the block note.  A basic block ends with
  a control flow instruction or with the last instruction before the next
! ‘CODE_LABEL’ or ‘NOTE_INSN_BASIC_BLOCK’.  By definition, a ‘CODE_LABEL’
  cannot appear in the middle of the instruction stream of a basic block.
  
   In addition to notes, the jump table vectors are also represented as
*************** it is often difficult to eliminate the c
*** 20970,20986 ****
  referencing the vector, so cleaning up these vectors is postponed until
  after liveness analysis.  Thus the jump table vectors may appear in the
  insn stream unreferenced and without any purpose.  Before any edge is
! made "fall-thru", the existence of such construct in the way needs to be
! checked by calling 'can_fallthru' function.
  
!  For the 'GIMPLE' representation, the PHI nodes and statements contained
! in a basic block are in a 'gimple_seq' pointed to by the basic block
  intermediate language specific pointers.  Abstract containers and
  iterators are used to access the PHI nodes and statements in a basic
! blocks.  These iterators are called "GIMPLE statement iterators" (GSIs).
! Grep for '^gsi' in the various 'gimple-*' and 'tree-*' files.  There is
! a 'gimple_stmt_iterator' type for iterating over all kinds of statement,
! and a 'gphi_iterator' subclass for iterating over PHI nodes.  The
  following snippet will pretty-print all PHI nodes the statements of the
  current function in the GIMPLE representation.
  
--- 20969,20985 ----
  referencing the vector, so cleaning up these vectors is postponed until
  after liveness analysis.  Thus the jump table vectors may appear in the
  insn stream unreferenced and without any purpose.  Before any edge is
! made “fall-thru”, the existence of such construct in the way needs to be
! checked by calling ‘can_fallthru’ function.
  
!  For the ‘GIMPLE’ representation, the PHI nodes and statements contained
! in a basic block are in a ‘gimple_seq’ pointed to by the basic block
  intermediate language specific pointers.  Abstract containers and
  iterators are used to access the PHI nodes and statements in a basic
! blocks.  These iterators are called “GIMPLE statement iterators” (GSIs).
! Grep for ‘^gsi’ in the various ‘gimple-*’ and ‘tree-*’ files.  There is
! a ‘gimple_stmt_iterator’ type for iterating over all kinds of statement,
! and a ‘gphi_iterator’ subclass for iterating over PHI nodes.  The
  following snippet will pretty-print all PHI nodes the statements of the
  current function in the GIMPLE representation.
  
*************** File: gccint.info,  Node: Edges,  Next:
*** 21012,21063 ****
  Edges represent possible control flow transfers from the end of some
  basic block A to the head of another basic block B.  We say that A is a
  predecessor of B, and B is a successor of A.  Edges are represented in
! GCC with the 'edge' data type.  Each 'edge' acts as a link between two
! basic blocks: The 'src' member of an edge points to the predecessor
! basic block of the 'dest' basic block.  The members 'preds' and 'succs'
! of the 'basic_block' data type point to type-safe vectors of edges to
  the predecessors and successors of the block.
  
!  When walking the edges in an edge vector, "edge iterators" should be
! used.  Edge iterators are constructed using the 'edge_iterator' data
  structure and several methods are available to operate on them:
  
! 'ei_start'
!      This function initializes an 'edge_iterator' that points to the
       first edge in a vector of edges.
  
! 'ei_last'
!      This function initializes an 'edge_iterator' that points to the
       last edge in a vector of edges.
  
! 'ei_end_p'
!      This predicate is 'true' if an 'edge_iterator' represents the last
       edge in an edge vector.
  
! 'ei_one_before_end_p'
!      This predicate is 'true' if an 'edge_iterator' represents the
       second last edge in an edge vector.
  
! 'ei_next'
!      This function takes a pointer to an 'edge_iterator' and makes it
       point to the next edge in the sequence.
  
! 'ei_prev'
!      This function takes a pointer to an 'edge_iterator' and makes it
       point to the previous edge in the sequence.
  
! 'ei_edge'
!      This function returns the 'edge' currently pointed to by an
!      'edge_iterator'.
  
! 'ei_safe_edge'
!      This function returns the 'edge' currently pointed to by an
!      'edge_iterator', but returns 'NULL' if the iterator is pointing at
       the end of the sequence.  This function has been provided for
!      existing code makes the assumption that a 'NULL' edge indicates the
       end of the sequence.
  
!  The convenience macro 'FOR_EACH_EDGE' can be used to visit all of the
  edges in a sequence of predecessor or successor edges.  It must not be
  used when an element might be removed during the traversal, otherwise
  elements will be missed.  Here is an example of how to use the macro:
--- 21011,21062 ----
  Edges represent possible control flow transfers from the end of some
  basic block A to the head of another basic block B.  We say that A is a
  predecessor of B, and B is a successor of A.  Edges are represented in
! GCC with the ‘edge’ data type.  Each ‘edge’ acts as a link between two
! basic blocks: The ‘src’ member of an edge points to the predecessor
! basic block of the ‘dest’ basic block.  The members ‘preds’ and ‘succs’
! of the ‘basic_block’ data type point to type-safe vectors of edges to
  the predecessors and successors of the block.
  
!  When walking the edges in an edge vector, “edge iterators” should be
! used.  Edge iterators are constructed using the ‘edge_iterator’ data
  structure and several methods are available to operate on them:
  
! ‘ei_start’
!      This function initializes an ‘edge_iterator’ that points to the
       first edge in a vector of edges.
  
! ‘ei_last’
!      This function initializes an ‘edge_iterator’ that points to the
       last edge in a vector of edges.
  
! ‘ei_end_p’
!      This predicate is ‘true’ if an ‘edge_iterator’ represents the last
       edge in an edge vector.
  
! ‘ei_one_before_end_p’
!      This predicate is ‘true’ if an ‘edge_iterator’ represents the
       second last edge in an edge vector.
  
! ‘ei_next’
!      This function takes a pointer to an ‘edge_iterator’ and makes it
       point to the next edge in the sequence.
  
! ‘ei_prev’
!      This function takes a pointer to an ‘edge_iterator’ and makes it
       point to the previous edge in the sequence.
  
! ‘ei_edge’
!      This function returns the ‘edge’ currently pointed to by an
!      ‘edge_iterator’.
  
! ‘ei_safe_edge’
!      This function returns the ‘edge’ currently pointed to by an
!      ‘edge_iterator’, but returns ‘NULL’ if the iterator is pointing at
       the end of the sequence.  This function has been provided for
!      existing code makes the assumption that a ‘NULL’ edge indicates the
       end of the sequence.
  
!  The convenience macro ‘FOR_EACH_EDGE’ can be used to visit all of the
  edges in a sequence of predecessor or successor edges.  It must not be
  used when an element might be removed during the traversal, otherwise
  elements will be missed.  Here is an example of how to use the macro:
*************** elements will be missed.  Here is an exa
*** 21073,21082 ****
  
   There are various reasons why control flow may transfer from one block
  to another.  One possibility is that some instruction, for example a
! 'CODE_LABEL', in a linearized instruction stream just always starts a
! new basic block.  In this case a "fall-thru" edge links the basic block
  to the first following basic block.  But there are several other reasons
! why edges may be created.  The 'flags' field of the 'edge' data type is
  used to store information about the type of edge we are dealing with.
  Each edge is of one of the following types:
  
--- 21072,21081 ----
  
   There are various reasons why control flow may transfer from one block
  to another.  One possibility is that some instruction, for example a
! ‘CODE_LABEL’, in a linearized instruction stream just always starts a
! new basic block.  In this case a “fall-thru” edge links the basic block
  to the first following basic block.  But there are several other reasons
! why edges may be created.  The ‘flags’ field of the ‘edge’ data type is
  used to store information about the type of edge we are dealing with.
  Each edge is of one of the following types:
  
*************** _jump_
*** 21090,21099 ****
  _fall-thru_
       Fall-thru edges are present in case where the basic block may
       continue execution to the following one without branching.  These
!      edges have the 'EDGE_FALLTHRU' flag set.  Unlike other types of
       edges, these edges must come into the basic block immediately
       following in the instruction stream.  The function
!      'force_nonfallthru' is available to insert an unconditional jump in
       the case that redirection is needed.  Note that this may require
       creation of a new basic block.
  
--- 21089,21098 ----
  _fall-thru_
       Fall-thru edges are present in case where the basic block may
       continue execution to the following one without branching.  These
!      edges have the ‘EDGE_FALLTHRU’ flag set.  Unlike other types of
       edges, these edges must come into the basic block immediately
       following in the instruction stream.  The function
!      ‘force_nonfallthru’ is available to insert an unconditional jump in
       the case that redirection is needed.  Note that this may require
       creation of a new basic block.
  
*************** _exception handling_
*** 21104,21137 ****
       Ada exceptions like division by zero or segmentation fault are
       defined and thus each instruction possibly throwing this kind of
       exception needs to be handled as control flow instruction.
!      Exception edges have the 'EDGE_ABNORMAL' and 'EDGE_EH' flags set.
  
       When updating the instruction stream it is easy to change possibly
       trapping instruction to non-trapping, by simply removing the
       exception edge.  The opposite conversion is difficult, but should
       not happen anyway.  The edges can be eliminated via
!      'purge_dead_edges' call.
  
       In the RTL representation, the destination of an exception edge is
!      specified by 'REG_EH_REGION' note attached to the insn.  In case of
!      a trapping call the 'EDGE_ABNORMAL_CALL' flag is set too.  In the
!      'GIMPLE' representation, this extra flag is not set.
  
!      In the RTL representation, the predicate 'may_trap_p' may be used
       to check whether instruction still may trap or not.  For the tree
!      representation, the 'tree_could_trap_p' predicate is available, but
       this predicate only checks for possible memory traps, as in
       dereferencing an invalid pointer location.
  
  _sibling calls_
       Sibling calls or tail calls terminate the function in a
       non-standard way and thus an edge to the exit must be present.
!      'EDGE_SIBCALL' and 'EDGE_ABNORMAL' are set in such case.  These
       edges only exist in the RTL representation.
  
  _computed jumps_
       Computed jumps contain edges to all labels in the function
!      referenced from the code.  All those edges have 'EDGE_ABNORMAL'
       flag set.  The edges used to represent computed jumps often cause
       compile time performance problems, since functions consisting of
       many taken labels and many computed jumps may have _very_ dense
--- 21103,21136 ----
       Ada exceptions like division by zero or segmentation fault are
       defined and thus each instruction possibly throwing this kind of
       exception needs to be handled as control flow instruction.
!      Exception edges have the ‘EDGE_ABNORMAL’ and ‘EDGE_EH’ flags set.
  
       When updating the instruction stream it is easy to change possibly
       trapping instruction to non-trapping, by simply removing the
       exception edge.  The opposite conversion is difficult, but should
       not happen anyway.  The edges can be eliminated via
!      ‘purge_dead_edges’ call.
  
       In the RTL representation, the destination of an exception edge is
!      specified by ‘REG_EH_REGION’ note attached to the insn.  In case of
!      a trapping call the ‘EDGE_ABNORMAL_CALL’ flag is set too.  In the
!      ‘GIMPLE’ representation, this extra flag is not set.
  
!      In the RTL representation, the predicate ‘may_trap_p’ may be used
       to check whether instruction still may trap or not.  For the tree
!      representation, the ‘tree_could_trap_p’ predicate is available, but
       this predicate only checks for possible memory traps, as in
       dereferencing an invalid pointer location.
  
  _sibling calls_
       Sibling calls or tail calls terminate the function in a
       non-standard way and thus an edge to the exit must be present.
!      ‘EDGE_SIBCALL’ and ‘EDGE_ABNORMAL’ are set in such case.  These
       edges only exist in the RTL representation.
  
  _computed jumps_
       Computed jumps contain edges to all labels in the function
!      referenced from the code.  All those edges have ‘EDGE_ABNORMAL’
       flag set.  The edges used to represent computed jumps often cause
       compile time performance problems, since functions consisting of
       many taken labels and many computed jumps may have _very_ dense
*************** _computed jumps_
*** 21168,21193 ****
       has a runtime cost in there resulting code: An extra jump.
       Therefore, the computed jumps are un-factored in the later passes
       of the compiler (in the pass called
!      'pass_duplicate_computed_gotos').  Be aware of that when you work
       on passes in that area.  There have been numerous examples already
       where the compile time for code with unfactored computed jumps
       caused some serious headaches.
  
  _nonlocal goto handlers_
!      GCC allows nested functions to return into caller using a 'goto' to
       a label passed to as an argument to the callee.  The labels passed
       to nested functions contain special code to cleanup after function
       call.  Such sections of code are referred to as "nonlocal goto
       receivers".  If a function contains such nonlocal goto receivers,
       an edge from the call to the label is created with the
!      'EDGE_ABNORMAL' and 'EDGE_ABNORMAL_CALL' flags set.
  
  _function entry points_
       By definition, execution of function starts at basic block 0, so
!      there is always an edge from the 'ENTRY_BLOCK_PTR' to basic block
!      0.  There is no 'GIMPLE' representation for alternate entry points
       at this moment.  In RTL, alternate entry points are specified by
!      'CODE_LABEL' with 'LABEL_ALTERNATE_NAME' defined.  This feature is
       currently used for multiple entry point prologues and is limited to
       post-reload passes only.  This can be used by back-ends to emit
       alternate prologues for functions called from different contexts.
--- 21167,21192 ----
       has a runtime cost in there resulting code: An extra jump.
       Therefore, the computed jumps are un-factored in the later passes
       of the compiler (in the pass called
!      ‘pass_duplicate_computed_gotos’).  Be aware of that when you work
       on passes in that area.  There have been numerous examples already
       where the compile time for code with unfactored computed jumps
       caused some serious headaches.
  
  _nonlocal goto handlers_
!      GCC allows nested functions to return into caller using a ‘goto’ to
       a label passed to as an argument to the callee.  The labels passed
       to nested functions contain special code to cleanup after function
       call.  Such sections of code are referred to as "nonlocal goto
       receivers".  If a function contains such nonlocal goto receivers,
       an edge from the call to the label is created with the
!      ‘EDGE_ABNORMAL’ and ‘EDGE_ABNORMAL_CALL’ flags set.
  
  _function entry points_
       By definition, execution of function starts at basic block 0, so
!      there is always an edge from the ‘ENTRY_BLOCK_PTR’ to basic block
!      0.  There is no ‘GIMPLE’ representation for alternate entry points
       at this moment.  In RTL, alternate entry points are specified by
!      ‘CODE_LABEL’ with ‘LABEL_ALTERNATE_NAME’ defined.  This feature is
       currently used for multiple entry point prologues and is limited to
       post-reload passes only.  This can be used by back-ends to emit
       alternate prologues for functions called from different contexts.
*************** one part of code for speed in another, o
*** 21213,21219 ****
  speed.  In such cases it is useful to know information about how often
  some given block will be executed.  That is the purpose for maintaining
  profile within the flow graph.  GCC can handle profile information
! obtained through "profile feedback", but it can also estimate branch
  probabilities based on statics and heuristics.
  
   The feedback based profile is produced by compiling the program with
--- 21212,21218 ----
  speed.  In such cases it is useful to know information about how often
  some given block will be executed.  That is the purpose for maintaining
  profile within the flow graph.  GCC can handle profile information
! obtained through “profile feedback”, but it can also estimate branch
  probabilities based on statics and heuristics.
  
   The feedback based profile is produced by compiling the program with
*************** different data sets.
*** 21228,21252 ****
  
   When profile feedback is not available, the compiler may be asked to
  attempt to predict the behavior of each branch in the program using a
! set of heuristics (see 'predict.def' for details) and compute estimated
  frequencies of each basic block by propagating the probabilities over
  the graph.
  
!  Each 'basic_block' contains two integer fields to represent profile
! information: 'frequency' and 'count'.  The 'frequency' is an estimation
  how often is basic block executed within a function.  It is represented
! as an integer scaled in the range from 0 to 'BB_FREQ_BASE'.  The most
  frequently executed basic block in function is initially set to
! 'BB_FREQ_BASE' and the rest of frequencies are scaled accordingly.
  During optimization, the frequency of the most frequent basic block can
  both decrease (for instance by loop unrolling) or grow (for instance by
  cross-jumping optimization), so scaling sometimes has to be performed
  multiple times.
  
!  The 'count' contains hard-counted numbers of execution measured during
  training runs and is nonzero only when profile feedback is available.
  This value is represented as the host's widest integer (typically a 64
! bit integer) of the special type 'gcov_type'.
  
   Most optimization passes can use only the frequency information of a
  basic block, but a few passes may want to know hard execution counts.
--- 21227,21251 ----
  
   When profile feedback is not available, the compiler may be asked to
  attempt to predict the behavior of each branch in the program using a
! set of heuristics (see ‘predict.def’ for details) and compute estimated
  frequencies of each basic block by propagating the probabilities over
  the graph.
  
!  Each ‘basic_block’ contains two integer fields to represent profile
! information: ‘frequency’ and ‘count’.  The ‘frequency’ is an estimation
  how often is basic block executed within a function.  It is represented
! as an integer scaled in the range from 0 to ‘BB_FREQ_BASE’.  The most
  frequently executed basic block in function is initially set to
! ‘BB_FREQ_BASE’ and the rest of frequencies are scaled accordingly.
  During optimization, the frequency of the most frequent basic block can
  both decrease (for instance by loop unrolling) or grow (for instance by
  cross-jumping optimization), so scaling sometimes has to be performed
  multiple times.
  
!  The ‘count’ contains hard-counted numbers of execution measured during
  training runs and is nonzero only when profile feedback is available.
  This value is represented as the host's widest integer (typically a 64
! bit integer) of the special type ‘gcov_type’.
  
   Most optimization passes can use only the frequency information of a
  basic block, but a few passes may want to know hard execution counts.
*************** during updating of the profile informati
*** 21255,21282 ****
  accumulate into quite large errors.
  
   Each edge also contains a branch probability field: an integer in the
! range from 0 to 'REG_BR_PROB_BASE'.  It represents probability of
! passing control from the end of the 'src' basic block to the 'dest'
  basic block, i.e. the probability that control will flow along this
! edge.  The 'EDGE_FREQUENCY' macro is available to compute how frequently
! a given edge is taken.  There is a 'count' field for each edge as well,
  representing same information as for a basic block.
  
   The basic block frequencies are not represented in the instruction
  stream, but in the RTL representation the edge frequencies are
! represented for conditional jumps (via the 'REG_BR_PROB' macro) since
  they are used when instructions are output to the assembly file and the
  flow graph is no longer maintained.
  
   The probability that control flow arrives via a given edge to its
! destination basic block is called "reverse probability" and is not
  directly represented, but it may be easily computed from frequencies of
  basic blocks.
  
   Updating profile information is a delicate task that can unfortunately
  not be easily integrated with the CFG manipulation API.  Many of the
  functions and hooks to modify the CFG, such as
! 'redirect_edge_and_branch', do not have enough information to easily
  update the profile, so updating it is in the majority of cases left up
  to the caller.  It is difficult to uncover bugs in the profile updating
  code, because they manifest themselves only by producing worse code, and
--- 21254,21281 ----
  accumulate into quite large errors.
  
   Each edge also contains a branch probability field: an integer in the
! range from 0 to ‘REG_BR_PROB_BASE’.  It represents probability of
! passing control from the end of the ‘src’ basic block to the ‘dest’
  basic block, i.e. the probability that control will flow along this
! edge.  The ‘EDGE_FREQUENCY’ macro is available to compute how frequently
! a given edge is taken.  There is a ‘count’ field for each edge as well,
  representing same information as for a basic block.
  
   The basic block frequencies are not represented in the instruction
  stream, but in the RTL representation the edge frequencies are
! represented for conditional jumps (via the ‘REG_BR_PROB’ macro) since
  they are used when instructions are output to the assembly file and the
  flow graph is no longer maintained.
  
   The probability that control flow arrives via a given edge to its
! destination basic block is called “reverse probability” and is not
  directly represented, but it may be easily computed from frequencies of
  basic blocks.
  
   Updating profile information is a delicate task that can unfortunately
  not be easily integrated with the CFG manipulation API.  Many of the
  functions and hooks to modify the CFG, such as
! ‘redirect_edge_and_branch’, do not have enough information to easily
  update the profile, so updating it is in the majority of cases left up
  to the caller.  It is difficult to uncover bugs in the profile updating
  code, because they manifest themselves only by producing worse code, and
*************** checking profile consistency is not poss
*** 21284,21293 ****
  accumulation.  Hence special attention needs to be given to this issue
  in each pass that modifies the CFG.
  
!  It is important to point out that 'REG_BR_PROB_BASE' and 'BB_FREQ_BASE'
  are both set low enough to be possible to compute second power of any
  frequency or probability in the flow graph, it is not possible to even
! square the 'count' field, as modern CPUs are fast enough to execute
  $2^32$ operations quickly.
  
  
--- 21283,21292 ----
  accumulation.  Hence special attention needs to be given to this issue
  in each pass that modifies the CFG.
  
!  It is important to point out that ‘REG_BR_PROB_BASE’ and ‘BB_FREQ_BASE’
  are both set low enough to be possible to compute second power of any
  frequency or probability in the flow graph, it is not possible to even
! square the ‘count’ field, as modern CPUs are fast enough to execute
  $2^32$ operations quickly.
  
  
*************** very expensive and lost profile informat
*** 21303,21412 ****
  all.
  
   GCC has two major intermediate representations, and both use the
! 'basic_block' and 'edge' data types to represent control flow.  Both
  representations share as much of the CFG maintenance code as possible.
! For each representation, a set of "hooks" is defined so that each
  representation can provide its own implementation of CFG manipulation
! routines when necessary.  These hooks are defined in 'cfghooks.h'.
  There are hooks for almost all common CFG manipulations, including block
  splitting and merging, edge redirection and creating and deleting basic
  blocks.  These hooks should provide everything you need to maintain and
! manipulate the CFG in both the RTL and 'GIMPLE' representation.
  
   At the moment, the basic block boundaries are maintained transparently
  when modifying instructions, so there rarely is a need to move them
  manually (such as in case someone wants to output instruction outside
  basic block explicitly).
  
!  In the RTL representation, each instruction has a 'BLOCK_FOR_INSN'
  value that represents pointer to the basic block that contains the
! instruction.  In the 'GIMPLE' representation, the function 'gimple_bb'
  returns a pointer to the basic block containing the queried statement.
  
!  When changes need to be applied to a function in its 'GIMPLE'
! representation, "GIMPLE statement iterators" should be used.  These
  iterators provide an integrated abstraction of the flow graph and the
  instruction stream.  Block statement iterators are constructed using the
! 'gimple_stmt_iterator' data structure and several modifiers are
  available, including the following:
  
! 'gsi_start'
!      This function initializes a 'gimple_stmt_iterator' that points to
       the first non-empty statement in a basic block.
  
! 'gsi_last'
!      This function initializes a 'gimple_stmt_iterator' that points to
       the last statement in a basic block.
  
! 'gsi_end_p'
!      This predicate is 'true' if a 'gimple_stmt_iterator' represents the
       end of a basic block.
  
! 'gsi_next'
!      This function takes a 'gimple_stmt_iterator' and makes it point to
       its successor.
  
! 'gsi_prev'
!      This function takes a 'gimple_stmt_iterator' and makes it point to
       its predecessor.
  
! 'gsi_insert_after'
!      This function inserts a statement after the 'gimple_stmt_iterator'
       passed in.  The final parameter determines whether the statement
       iterator is updated to point to the newly inserted statement, or
       left pointing to the original statement.
  
! 'gsi_insert_before'
!      This function inserts a statement before the 'gimple_stmt_iterator'
       passed in.  The final parameter determines whether the statement
       iterator is updated to point to the newly inserted statement, or
       left pointing to the original statement.
  
! 'gsi_remove'
!      This function removes the 'gimple_stmt_iterator' passed in and
       rechains the remaining statements in a basic block, if any.
  
!  In the RTL representation, the macros 'BB_HEAD' and 'BB_END' may be
! used to get the head and end 'rtx' of a basic block.  No abstract
  iterators are defined for traversing the insn chain, but you can just
! use 'NEXT_INSN' and 'PREV_INSN' instead.  *Note Insns::.
  
   Usually a code manipulating pass simplifies the instruction stream and
  the flow of control, possibly eliminating some edges.  This may for
  example happen when a conditional jump is replaced with an unconditional
  jump.  Updating of edges is not transparent and each optimization pass
  is required to do so manually.  However only few cases occur in
! practice.  The pass may call 'purge_dead_edges' on a given basic block
  to remove superfluous edges, if any.
  
   Another common scenario is redirection of branch instructions, but this
  is best modeled as redirection of edges in the control flow graph and
! thus use of 'redirect_edge_and_branch' is preferred over more low level
! functions, such as 'redirect_jump' that operate on RTL chain only.  The
! CFG hooks defined in 'cfghooks.h' should provide the complete API
  required for manipulating and maintaining the CFG.
  
   It is also possible that a pass has to insert control flow instruction
  into the middle of a basic block, thus creating an entry point in the
  middle of the basic block, which is impossible by definition: The block
  must be split to make sure it only has one entry point, i.e. the head of
! the basic block.  The CFG hook 'split_block' may be used when an
  instruction in the middle of a basic block has to become the target of a
  jump or branch instruction.
  
   For a global optimizer, a common operation is to split edges in the
  flow graph and insert instructions on them.  In the RTL representation,
! this can be easily done using the 'insert_insn_on_edge' function that
  emits an instruction "on the edge", caching it for a later
! 'commit_edge_insertions' call that will take care of moving the inserted
  instructions off the edge into the instruction stream contained in a
  basic block.  This includes the creation of new basic blocks where
! needed.  In the 'GIMPLE' representation, the equivalent functions are
! 'gsi_insert_on_edge' which inserts a block statement iterator on an
! edge, and 'gsi_commit_edge_inserts' which flushes the instruction to
  actual instruction stream.
  
!  While debugging the optimization pass, the 'verify_flow_info' function
  may be useful to find bugs in the control flow graph updating code.
  
  
--- 21302,21411 ----
  all.
  
   GCC has two major intermediate representations, and both use the
! ‘basic_block’ and ‘edge’ data types to represent control flow.  Both
  representations share as much of the CFG maintenance code as possible.
! For each representation, a set of “hooks” is defined so that each
  representation can provide its own implementation of CFG manipulation
! routines when necessary.  These hooks are defined in ‘cfghooks.h’.
  There are hooks for almost all common CFG manipulations, including block
  splitting and merging, edge redirection and creating and deleting basic
  blocks.  These hooks should provide everything you need to maintain and
! manipulate the CFG in both the RTL and ‘GIMPLE’ representation.
  
   At the moment, the basic block boundaries are maintained transparently
  when modifying instructions, so there rarely is a need to move them
  manually (such as in case someone wants to output instruction outside
  basic block explicitly).
  
!  In the RTL representation, each instruction has a ‘BLOCK_FOR_INSN’
  value that represents pointer to the basic block that contains the
! instruction.  In the ‘GIMPLE’ representation, the function ‘gimple_bb’
  returns a pointer to the basic block containing the queried statement.
  
!  When changes need to be applied to a function in its ‘GIMPLE’
! representation, “GIMPLE statement iterators” should be used.  These
  iterators provide an integrated abstraction of the flow graph and the
  instruction stream.  Block statement iterators are constructed using the
! ‘gimple_stmt_iterator’ data structure and several modifiers are
  available, including the following:
  
! ‘gsi_start’
!      This function initializes a ‘gimple_stmt_iterator’ that points to
       the first non-empty statement in a basic block.
  
! ‘gsi_last’
!      This function initializes a ‘gimple_stmt_iterator’ that points to
       the last statement in a basic block.
  
! ‘gsi_end_p’
!      This predicate is ‘true’ if a ‘gimple_stmt_iterator’ represents the
       end of a basic block.
  
! ‘gsi_next’
!      This function takes a ‘gimple_stmt_iterator’ and makes it point to
       its successor.
  
! ‘gsi_prev’
!      This function takes a ‘gimple_stmt_iterator’ and makes it point to
       its predecessor.
  
! ‘gsi_insert_after’
!      This function inserts a statement after the ‘gimple_stmt_iterator’
       passed in.  The final parameter determines whether the statement
       iterator is updated to point to the newly inserted statement, or
       left pointing to the original statement.
  
! ‘gsi_insert_before’
!      This function inserts a statement before the ‘gimple_stmt_iterator’
       passed in.  The final parameter determines whether the statement
       iterator is updated to point to the newly inserted statement, or
       left pointing to the original statement.
  
! ‘gsi_remove’
!      This function removes the ‘gimple_stmt_iterator’ passed in and
       rechains the remaining statements in a basic block, if any.
  
!  In the RTL representation, the macros ‘BB_HEAD’ and ‘BB_END’ may be
! used to get the head and end ‘rtx’ of a basic block.  No abstract
  iterators are defined for traversing the insn chain, but you can just
! use ‘NEXT_INSN’ and ‘PREV_INSN’ instead.  *Note Insns::.
  
   Usually a code manipulating pass simplifies the instruction stream and
  the flow of control, possibly eliminating some edges.  This may for
  example happen when a conditional jump is replaced with an unconditional
  jump.  Updating of edges is not transparent and each optimization pass
  is required to do so manually.  However only few cases occur in
! practice.  The pass may call ‘purge_dead_edges’ on a given basic block
  to remove superfluous edges, if any.
  
   Another common scenario is redirection of branch instructions, but this
  is best modeled as redirection of edges in the control flow graph and
! thus use of ‘redirect_edge_and_branch’ is preferred over more low level
! functions, such as ‘redirect_jump’ that operate on RTL chain only.  The
! CFG hooks defined in ‘cfghooks.h’ should provide the complete API
  required for manipulating and maintaining the CFG.
  
   It is also possible that a pass has to insert control flow instruction
  into the middle of a basic block, thus creating an entry point in the
  middle of the basic block, which is impossible by definition: The block
  must be split to make sure it only has one entry point, i.e. the head of
! the basic block.  The CFG hook ‘split_block’ may be used when an
  instruction in the middle of a basic block has to become the target of a
  jump or branch instruction.
  
   For a global optimizer, a common operation is to split edges in the
  flow graph and insert instructions on them.  In the RTL representation,
! this can be easily done using the ‘insert_insn_on_edge’ function that
  emits an instruction "on the edge", caching it for a later
! ‘commit_edge_insertions’ call that will take care of moving the inserted
  instructions off the edge into the instruction stream contained in a
  basic block.  This includes the creation of new basic blocks where
! needed.  In the ‘GIMPLE’ representation, the equivalent functions are
! ‘gsi_insert_on_edge’ which inserts a block statement iterator on an
! edge, and ‘gsi_commit_edge_inserts’ which flushes the instruction to
  actual instruction stream.
  
!  While debugging the optimization pass, the ‘verify_flow_info’ function
  may be useful to find bugs in the control flow graph updating code.
  
  
*************** live.  The hard registers and stack slot
*** 21424,21451 ****
  values when a register is dead.
  
   Liveness information is available in the back end starting with
! 'pass_df_initialize' and ending with 'pass_df_finish'.  Three flavors of
! live analysis are available: With 'LR', it is possible to determine at
! any point 'P' in the function if the register may be used on some path
! from 'P' to the end of the function.  With 'UR', it is possible to
! determine if there is a path from the beginning of the function to 'P'
! that defines the variable.  'LIVE' is the intersection of the 'LR' and
! 'UR' and a variable is live at 'P' if there is both an assignment that
  reaches it from the beginning of the function and a use that can be
! reached on some path from 'P' to the end of the function.
  
!  In general 'LIVE' is the most useful of the three.  The macros
! 'DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information.  The
  macros take a basic block number and return a bitmap that is indexed by
  the register number.  This information is only guaranteed to be up to
! date after calls are made to 'df_analyze'.  See the file 'df-core.cc'
  for details on using the dataflow.
  
   The liveness information is stored partly in the RTL instruction stream
  and partly in the flow graph.  Local information is stored in the
! instruction stream: Each instruction may contain 'REG_DEAD' notes
  representing that the value of a given register is no longer needed, or
! 'REG_UNUSED' notes representing that the value computed by the
  instruction is never used.  The second is useful for instructions
  computing multiple values at once.
  
--- 21423,21450 ----
  values when a register is dead.
  
   Liveness information is available in the back end starting with
! ‘pass_df_initialize’ and ending with ‘pass_df_finish’.  Three flavors of
! live analysis are available: With ‘LR’, it is possible to determine at
! any point ‘P’ in the function if the register may be used on some path
! from ‘P’ to the end of the function.  With ‘UR’, it is possible to
! determine if there is a path from the beginning of the function to ‘P’
! that defines the variable.  ‘LIVE’ is the intersection of the ‘LR’ and
! ‘UR’ and a variable is live at ‘P’ if there is both an assignment that
  reaches it from the beginning of the function and a use that can be
! reached on some path from ‘P’ to the end of the function.
  
!  In general ‘LIVE’ is the most useful of the three.  The macros
! ‘DF_[LR,UR,LIVE]_[IN,OUT]’ can be used to access this information.  The
  macros take a basic block number and return a bitmap that is indexed by
  the register number.  This information is only guaranteed to be up to
! date after calls are made to ‘df_analyze’.  See the file ‘df-core.cc’
  for details on using the dataflow.
  
   The liveness information is stored partly in the RTL instruction stream
  and partly in the flow graph.  Local information is stored in the
! instruction stream: Each instruction may contain ‘REG_DEAD’ notes
  representing that the value of a given register is no longer needed, or
! ‘REG_UNUSED’ notes representing that the value computed by the
  instruction is never used.  The second is useful for instructions
  computing multiple values at once.
  
*************** File: gccint.info,  Node: Loop represent
*** 21480,21486 ****
  
  This chapter describes the representation of loops in GCC, and functions
  that can be used to build, modify and analyze this representation.  Most
! of the interfaces and data structures are declared in 'cfgloop.h'.  Loop
  structures are analyzed and this information disposed or updated at the
  discretion of individual passes.  Still most of the generic CFG
  manipulation routines are aware of loop structures and try to keep them
--- 21479,21485 ----
  
  This chapter describes the representation of loops in GCC, and functions
  that can be used to build, modify and analyze this representation.  Most
! of the interfaces and data structures are declared in ‘cfgloop.h’.  Loop
  structures are analyzed and this information disposed or updated at the
  discretion of individual passes.  Still most of the generic CFG
  manipulation routines are aware of loop structures and try to keep them
*************** correspond to sub-loops or to control fl
*** 21502,21508 ****
  that the analysis sometimes changes the CFG, and if you run it in the
  middle of an optimization pass, you must be able to deal with the new
  blocks.  You may avoid CFG changes by passing
! 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note
  however that most other loop manipulation functions will not work
  correctly for loops with multiple latch edges (the functions that only
  query membership of blocks to loops and subloop relationships, or
--- 21501,21507 ----
  that the analysis sometimes changes the CFG, and if you run it in the
  middle of an optimization pass, you must be able to deal with the new
  blocks.  You may avoid CFG changes by passing
! ‘LOOPS_MAY_HAVE_MULTIPLE_LATCHES’ flag to the loop discovery, note
  however that most other loop manipulation functions will not work
  correctly for loops with multiple latch edges (the functions that only
  query membership of blocks to loops and subloop relationships, or
*************** enumerate and test loop exits, can be ex
*** 21512,21534 ****
  and reachable from its latch against the direction of edges in CFG.  The
  loops are organized in a containment hierarchy (tree) such that all the
  loops immediately contained inside loop L are the children of L in the
! tree.  This tree is represented by the 'struct loops' structure.  The
  root of this tree is a fake loop that contains all blocks in the
! function.  Each of the loops is represented in a 'struct loop'
! structure.  Each loop is assigned an index ('num' field of the 'struct
! loop' structure), and the pointer to the loop is stored in the
! corresponding field of the 'larray' vector in the loops structure.  The
! indices do not have to be continuous, there may be empty ('NULL')
! entries in the 'larray' created by deleting loops.  Also, there is no
  guarantee on the relative order of a loop and its subloops in the
  numbering.  The index of a loop never changes.
  
!  The entries of the 'larray' field should not be accessed directly.  The
! function 'get_loop' returns the loop description for a loop with the
! given index.  'number_of_loops' function returns number of loops in the
  function.  To traverse all loops, use a range-based for loop with class
! 'loops_list' instance.  The 'flags' argument passed to the constructor
! function of class 'loops_list' is used to determine the direction of
  traversal and the set of loops visited.  Each loop is guaranteed to be
  visited exactly once, regardless of the changes to the loop tree, and
  the loops may be removed during the traversal.  The newly created loops
--- 21511,21533 ----
  and reachable from its latch against the direction of edges in CFG.  The
  loops are organized in a containment hierarchy (tree) such that all the
  loops immediately contained inside loop L are the children of L in the
! tree.  This tree is represented by the ‘struct loops’ structure.  The
  root of this tree is a fake loop that contains all blocks in the
! function.  Each of the loops is represented in a ‘struct loop’
! structure.  Each loop is assigned an index (‘num’ field of the ‘struct
! loop’ structure), and the pointer to the loop is stored in the
! corresponding field of the ‘larray’ vector in the loops structure.  The
! indices do not have to be continuous, there may be empty (‘NULL’)
! entries in the ‘larray’ created by deleting loops.  Also, there is no
  guarantee on the relative order of a loop and its subloops in the
  numbering.  The index of a loop never changes.
  
!  The entries of the ‘larray’ field should not be accessed directly.  The
! function ‘get_loop’ returns the loop description for a loop with the
! given index.  ‘number_of_loops’ function returns number of loops in the
  function.  To traverse all loops, use a range-based for loop with class
! ‘loops_list’ instance.  The ‘flags’ argument passed to the constructor
! function of class ‘loops_list’ is used to determine the direction of
  traversal and the set of loops visited.  Each loop is guaranteed to be
  visited exactly once, regardless of the changes to the loop tree, and
  the loops may be removed during the traversal.  The newly created loops
*************** are never traversed, if they need to be
*** 21536,21566 ****
  separately after their creation.
  
   Each basic block contains the reference to the innermost loop it
! belongs to ('loop_father').  For this reason, it is only possible to
! have one 'struct loops' structure initialized at the same time for each
! CFG.  The global variable 'current_loops' contains the 'struct loops'
  structure.  Many of the loop manipulation functions assume that
  dominance information is up-to-date.
  
!  The loops are analyzed through 'loop_optimizer_init' function.  The
  argument of this function is a set of flags represented in an integer
  bitmask.  These flags specify what other properties of the loop
  structures should be calculated/enforced and preserved later:
  
!    * 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes
       to CFG will be performed in the loop analysis, in particular, loops
       with multiple latch edges will not be disambiguated.  If a loop has
       multiple latches, its latch block is set to NULL.  Most of the loop
       manipulation functions will not work for loops in this shape.  No
       other flags that require CFG changes can be passed to
       loop_optimizer_init.
!    * 'LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a way
       that each loop has only one entry edge, and additionally, the
       source block of this entry edge has only one successor.  This
       creates a natural place where the code can be moved out of the
       loop, and ensures that the entry edge of the loop leads from its
       immediate super-loop.
!    * 'LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force
       the latch block of each loop to have only one successor.  This
       ensures that the latch of the loop does not belong to any of its
       sub-loops, and makes manipulation with the loops significantly
--- 21535,21565 ----
  separately after their creation.
  
   Each basic block contains the reference to the innermost loop it
! belongs to (‘loop_father’).  For this reason, it is only possible to
! have one ‘struct loops’ structure initialized at the same time for each
! CFG.  The global variable ‘current_loops’ contains the ‘struct loops’
  structure.  Many of the loop manipulation functions assume that
  dominance information is up-to-date.
  
!  The loops are analyzed through ‘loop_optimizer_init’ function.  The
  argument of this function is a set of flags represented in an integer
  bitmask.  These flags specify what other properties of the loop
  structures should be calculated/enforced and preserved later:
  
!    • ‘LOOPS_MAY_HAVE_MULTIPLE_LATCHES’: If this flag is set, no changes
       to CFG will be performed in the loop analysis, in particular, loops
       with multiple latch edges will not be disambiguated.  If a loop has
       multiple latches, its latch block is set to NULL.  Most of the loop
       manipulation functions will not work for loops in this shape.  No
       other flags that require CFG changes can be passed to
       loop_optimizer_init.
!    • ‘LOOPS_HAVE_PREHEADERS’: Forwarder blocks are created in such a way
       that each loop has only one entry edge, and additionally, the
       source block of this entry edge has only one successor.  This
       creates a natural place where the code can be moved out of the
       loop, and ensures that the entry edge of the loop leads from its
       immediate super-loop.
!    • ‘LOOPS_HAVE_SIMPLE_LATCHES’: Forwarder blocks are created to force
       the latch block of each loop to have only one successor.  This
       ensures that the latch of the loop does not belong to any of its
       sub-loops, and makes manipulation with the loops significantly
*************** structures should be calculated/enforced
*** 21568,21605 ****
       loops are in this shape.  Note that with this flag, the "normal"
       loop without any control flow inside and with one exit consists of
       two basic blocks.
!    * 'LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in
       the strongly connected components that are not natural loops (have
!      more than one entry block) are marked with 'BB_IRREDUCIBLE_LOOP'
!      and 'EDGE_IRREDUCIBLE_LOOP' flags.  The flag is not set for blocks
       and edges that belong to natural loops that are in such an
       irreducible region (but it is set for the entry and exit edges of
       such a loop, if they lead to/from this region).
!    * 'LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and
       updated for each loop.  This makes some functions (e.g.,
!      'get_loop_exit_edges') more efficient.  Some functions (e.g.,
!      'single_exit') can be used only if the lists of exits are recorded.
  
   These properties may also be computed/enforced later, using functions
! 'create_preheaders', 'force_single_succ_latches',
! 'mark_irreducible_loops' and 'record_loop_exits'.  The properties can be
! queried using 'loops_state_satisfies_p'.
  
   The memory occupied by the loops structures should be freed with
! 'loop_optimizer_finalize' function.  When loop structures are setup to
  be preserved across passes this function reduces the information to be
! kept up-to-date to a minimum (only 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES'
  set).
  
   The CFG manipulation functions in general do not update loop
  structures.  Specialized versions that additionally do so are provided
! for the most common tasks.  On GIMPLE, 'cleanup_tree_cfg_loop' function
  can be used to cleanup CFG while updating the loops structures if
! 'current_loops' is set.
  
   At the moment loop structure is preserved from the start of GIMPLE loop
  optimizations until the end of RTL loop optimizations.  During this time
! a loop can be tracked by its 'struct loop' and number.
  
  
  File: gccint.info,  Node: Loop querying,  Next: Loop manipulation,  Prev: Loop representation,  Up: Loop Analysis and Representation
--- 21567,21604 ----
       loops are in this shape.  Note that with this flag, the "normal"
       loop without any control flow inside and with one exit consists of
       two basic blocks.
!    • ‘LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS’: Basic blocks and edges in
       the strongly connected components that are not natural loops (have
!      more than one entry block) are marked with ‘BB_IRREDUCIBLE_LOOP’
!      and ‘EDGE_IRREDUCIBLE_LOOP’ flags.  The flag is not set for blocks
       and edges that belong to natural loops that are in such an
       irreducible region (but it is set for the entry and exit edges of
       such a loop, if they lead to/from this region).
!    • ‘LOOPS_HAVE_RECORDED_EXITS’: The lists of exits are recorded and
       updated for each loop.  This makes some functions (e.g.,
!      ‘get_loop_exit_edges’) more efficient.  Some functions (e.g.,
!      ‘single_exit’) can be used only if the lists of exits are recorded.
  
   These properties may also be computed/enforced later, using functions
! ‘create_preheaders’, ‘force_single_succ_latches’,
! ‘mark_irreducible_loops’ and ‘record_loop_exits’.  The properties can be
! queried using ‘loops_state_satisfies_p’.
  
   The memory occupied by the loops structures should be freed with
! ‘loop_optimizer_finalize’ function.  When loop structures are setup to
  be preserved across passes this function reduces the information to be
! kept up-to-date to a minimum (only ‘LOOPS_MAY_HAVE_MULTIPLE_LATCHES’
  set).
  
   The CFG manipulation functions in general do not update loop
  structures.  Specialized versions that additionally do so are provided
! for the most common tasks.  On GIMPLE, ‘cleanup_tree_cfg_loop’ function
  can be used to cleanup CFG while updating the loops structures if
! ‘current_loops’ is set.
  
   At the moment loop structure is preserved from the start of GIMPLE loop
  optimizations until the end of RTL loop optimizations.  During this time
! a loop can be tracked by its ‘struct loop’ and number.
  
  
  File: gccint.info,  Node: Loop querying,  Next: Loop manipulation,  Prev: Loop representation,  Up: Loop Analysis and Representation
*************** File: gccint.info,  Node: Loop querying,
*** 21608,21622 ****
  ==================
  
  The functions to query the information about loops are declared in
! 'cfgloop.h'.  Some of the information can be taken directly from the
! structures.  'loop_father' field of each basic block contains the
  innermost loop to that the block belongs.  The most useful fields of
  loop structure (that are kept up-to-date at all times) are:
  
!    * 'header', 'latch': Header and latch basic blocks of the loop.
!    * 'num_nodes': Number of basic blocks in the loop (including the
       basic blocks of the sub-loops).
!    * 'outer', 'inner', 'next': The super-loop, the first sub-loop, and
       the sibling of the loop in the loops tree.
  
   There are other fields in the loop structures, many of them used only
--- 21607,21621 ----
  ==================
  
  The functions to query the information about loops are declared in
! ‘cfgloop.h’.  Some of the information can be taken directly from the
! structures.  ‘loop_father’ field of each basic block contains the
  innermost loop to that the block belongs.  The most useful fields of
  loop structure (that are kept up-to-date at all times) are:
  
!    • ‘header’, ‘latch’: Header and latch basic blocks of the loop.
!    • ‘num_nodes’: Number of basic blocks in the loop (including the
       basic blocks of the sub-loops).
!    • ‘outer’, ‘inner’, ‘next’: The super-loop, the first sub-loop, and
       the sibling of the loop in the loops tree.
  
   There are other fields in the loop structures, many of them used only
*************** they should not be accessed directly.
*** 21625,21658 ****
  
   The most important functions to query loop structures are:
  
!    * 'loop_depth': The depth of the loop in the loops tree, i.e., the
       number of super-loops of the loop.
!    * 'flow_loops_dump': Dumps the information about loops to a file.
!    * 'verify_loop_structure': Checks consistency of the loop structures.
!    * 'loop_latch_edge': Returns the latch edge of a loop.
!    * 'loop_preheader_edge': If loops have preheaders, returns the
       preheader edge of a loop.
!    * 'flow_loop_nested_p': Tests whether loop is a sub-loop of another
       loop.
!    * 'flow_bb_inside_loop_p': Tests whether a basic block belongs to a
       loop (including its sub-loops).
!    * 'find_common_loop': Finds the common super-loop of two loops.
!    * 'superloop_at_depth': Returns the super-loop of a loop with the
       given depth.
!    * 'tree_num_loop_insns', 'num_loop_insns': Estimates the number of
       insns in the loop, on GIMPLE and on RTL.
!    * 'loop_exit_edge_p': Tests whether edge is an exit from a loop.
!    * 'mark_loop_exit_edges': Marks all exit edges of all loops with
!      'EDGE_LOOP_EXIT' flag.
!    * 'get_loop_body', 'get_loop_body_in_dom_order',
!      'get_loop_body_in_bfs_order': Enumerates the basic blocks in the
       loop in depth-first search order in reversed CFG, ordered by
       dominance relation, and breath-first search order, respectively.
!    * 'single_exit': Returns the single exit edge of the loop, or 'NULL'
       if the loop has more than one exit.  You can only use this function
!      if 'LOOPS_HAVE_RECORDED_EXITS' is used.
!    * 'get_loop_exit_edges': Enumerates the exit edges of a loop.
!    * 'just_once_each_iteration_p': Returns true if the basic block is
       executed exactly once during each iteration of a loop (that is, it
       does not belong to a sub-loop, and it dominates the latch of the
       loop).
--- 21624,21657 ----
  
   The most important functions to query loop structures are:
  
!    • ‘loop_depth’: The depth of the loop in the loops tree, i.e., the
       number of super-loops of the loop.
!    • ‘flow_loops_dump’: Dumps the information about loops to a file.
!    • ‘verify_loop_structure’: Checks consistency of the loop structures.
!    • ‘loop_latch_edge’: Returns the latch edge of a loop.
!    • ‘loop_preheader_edge’: If loops have preheaders, returns the
       preheader edge of a loop.
!    • ‘flow_loop_nested_p’: Tests whether loop is a sub-loop of another
       loop.
!    • ‘flow_bb_inside_loop_p’: Tests whether a basic block belongs to a
       loop (including its sub-loops).
!    • ‘find_common_loop’: Finds the common super-loop of two loops.
!    • ‘superloop_at_depth’: Returns the super-loop of a loop with the
       given depth.
!    • ‘tree_num_loop_insns’, ‘num_loop_insns’: Estimates the number of
       insns in the loop, on GIMPLE and on RTL.
!    • ‘loop_exit_edge_p’: Tests whether edge is an exit from a loop.
!    • ‘mark_loop_exit_edges’: Marks all exit edges of all loops with
!      ‘EDGE_LOOP_EXIT’ flag.
!    • ‘get_loop_body’, ‘get_loop_body_in_dom_order’,
!      ‘get_loop_body_in_bfs_order’: Enumerates the basic blocks in the
       loop in depth-first search order in reversed CFG, ordered by
       dominance relation, and breath-first search order, respectively.
!    • ‘single_exit’: Returns the single exit edge of the loop, or ‘NULL’
       if the loop has more than one exit.  You can only use this function
!      if ‘LOOPS_HAVE_RECORDED_EXITS’ is used.
!    • ‘get_loop_exit_edges’: Enumerates the exit edges of a loop.
!    • ‘just_once_each_iteration_p’: Returns true if the basic block is
       executed exactly once during each iteration of a loop (that is, it
       does not belong to a sub-loop, and it dominates the latch of the
       loop).
*************** File: gccint.info,  Node: Loop manipulat
*** 21665,21680 ****
  
  The loops tree can be manipulated using the following functions:
  
!    * 'flow_loop_tree_node_add': Adds a node to the tree.
!    * 'flow_loop_tree_node_remove': Removes a node from the tree.
!    * 'add_bb_to_loop': Adds a basic block to a loop.
!    * 'remove_bb_from_loops': Removes a basic block from loops.
  
   Most low-level CFG functions update loops automatically.  The following
  functions handle some more complicated cases of CFG manipulations:
  
!    * 'remove_path': Removes an edge and all blocks it dominates.
!    * 'split_loop_exit_edge': Splits exit edge of the loop, ensuring that
       PHI node arguments remain in the loop (this ensures that
       loop-closed SSA form is preserved).  Only useful on GIMPLE.
  
--- 21664,21679 ----
  
  The loops tree can be manipulated using the following functions:
  
!    • ‘flow_loop_tree_node_add’: Adds a node to the tree.
!    • ‘flow_loop_tree_node_remove’: Removes a node from the tree.
!    • ‘add_bb_to_loop’: Adds a basic block to a loop.
!    • ‘remove_bb_from_loops’: Removes a basic block from loops.
  
   Most low-level CFG functions update loops automatically.  The following
  functions handle some more complicated cases of CFG manipulations:
  
!    • ‘remove_path’: Removes an edge and all blocks it dominates.
!    • ‘split_loop_exit_edge’: Splits exit edge of the loop, ensuring that
       PHI node arguments remain in the loop (this ensures that
       loop-closed SSA form is preserved).  Only useful on GIMPLE.
  
*************** While some of them are written so that t
*** 21683,21705 ****
  loops, they are mostly untested in that case, and at the moment, they
  are only reliable for the innermost loops:
  
!    * 'create_iv': Creates a new induction variable.  Only works on
!      GIMPLE.  'standard_iv_increment_position' can be used to find a
       suitable place for the iv increment.
!    * 'duplicate_loop_body_to_header_edge',
!      'tree_duplicate_loop_body_to_header_edge': These functions (on RTL
       and on GIMPLE) duplicate the body of the loop prescribed number of
       times on one of the edges entering loop header, thus performing
!      either loop unrolling or loop peeling.  'can_duplicate_loop_p'
!      ('can_unroll_loop_p' on GIMPLE) must be true for the duplicated
       loop.
!    * 'loop_version': This function creates a copy of a loop, and a
       branch before them that selects one of them depending on the
       prescribed condition.  This is useful for optimizations that need
       to verify some assumptions in runtime (one of the copies of the
       loop is usually left unchanged, while the other one is transformed
       in some way).
!    * 'tree_unroll_loop': Unrolls the loop, including peeling the extra
       iterations to make the number of iterations divisible by unroll
       factor, updating the exit condition, and removing the exits that
       now cannot be taken.  Works only on GIMPLE.
--- 21682,21704 ----
  loops, they are mostly untested in that case, and at the moment, they
  are only reliable for the innermost loops:
  
!    • ‘create_iv’: Creates a new induction variable.  Only works on
!      GIMPLE.  ‘standard_iv_increment_position’ can be used to find a
       suitable place for the iv increment.
!    • ‘duplicate_loop_body_to_header_edge’,
!      ‘tree_duplicate_loop_body_to_header_edge’: These functions (on RTL
       and on GIMPLE) duplicate the body of the loop prescribed number of
       times on one of the edges entering loop header, thus performing
!      either loop unrolling or loop peeling.  ‘can_duplicate_loop_p’
!      (‘can_unroll_loop_p’ on GIMPLE) must be true for the duplicated
       loop.
!    • ‘loop_version’: This function creates a copy of a loop, and a
       branch before them that selects one of them depending on the
       prescribed condition.  This is useful for optimizations that need
       to verify some assumptions in runtime (one of the copies of the
       loop is usually left unchanged, while the other one is transformed
       in some way).
!    • ‘tree_unroll_loop’: Unrolls the loop, including peeling the extra
       iterations to make the number of iterations divisible by unroll
       factor, updating the exit condition, and removing the exits that
       now cannot be taken.  Works only on GIMPLE.
*************** held in LCSSA, in order to save memory.
*** 21720,21734 ****
  
   There are various benefits of LCSSA:
  
!    * Many optimizations (value range analysis, final value replacement)
       are interested in the values that are defined in the loop and used
       outside of it, i.e., exactly those for that we create new PHI
       nodes.
!    * In induction variable analysis, it is not necessary to specify the
       loop in that the analysis should be performed - the scalar
       evolution analysis always returns the results with respect to the
       loop in that the SSA name is defined.
!    * It makes updating of SSA form during loop transformations simpler.
       Without LCSSA, operations like loop unrolling may force creation of
       PHI nodes arbitrarily far from the loop, while in LCSSA, the SSA
       form can be updated locally.  However, since we only keep real
--- 21719,21733 ----
  
   There are various benefits of LCSSA:
  
!    • Many optimizations (value range analysis, final value replacement)
       are interested in the values that are defined in the loop and used
       outside of it, i.e., exactly those for that we create new PHI
       nodes.
!    • In induction variable analysis, it is not necessary to specify the
       loop in that the analysis should be performed - the scalar
       evolution analysis always returns the results with respect to the
       loop in that the SSA name is defined.
!    • It makes updating of SSA form during loop transformations simpler.
       Without LCSSA, operations like loop unrolling may force creation of
       PHI nodes arbitrarily far from the loop, while in LCSSA, the SSA
       form can be updated locally.  However, since we only keep real
*************** held in LCSSA, in order to save memory.
*** 21741,21748 ****
  straightforward, unless you create a new value in loop and use it
  outside, or unless you manipulate loop exit edges (functions are
  provided to make these manipulations simple).
! 'rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, and
! 'verify_loop_closed_ssa' to check that the invariant of LCSSA is
  preserved.
  
  
--- 21740,21747 ----
  straightforward, unless you create a new value in loop and use it
  outside, or unless you manipulate loop exit edges (functions are
  provided to make these manipulations simple).
! ‘rewrite_into_loop_closed_ssa’ is used to rewrite SSA form to LCSSA, and
! ‘verify_loop_closed_ssa’ to check that the invariant of LCSSA is
  preserved.
  
  
*************** variable analysis on GIMPLE.  They enabl
*** 21756,21792 ****
  complicated behavior in a simple and consistent way (we only use it to
  express values of polynomial induction variables, but it is possible to
  extend it).  The interfaces to SCEV analysis are declared in
! 'tree-scalar-evolution.h'.  To use scalar evolutions analysis,
! 'scev_initialize' must be used.  To stop using SCEV, 'scev_finalize'
  should be used.  SCEV analysis caches results in order to save time and
  memory.  This cache however is made invalid by most of the loop
  transformations, including removal of code.  If such a transformation is
! performed, 'scev_reset' must be called to clean the caches.
  
   Given an SSA name, its behavior in loops can be analyzed using the
! 'analyze_scalar_evolution' function.  The returned SCEV however does not
  have to be fully analyzed and it may contain references to other SSA
  names defined in the loop.  To resolve these (potentially recursive)
! references, 'instantiate_parameters' or 'resolve_mixers' functions must
! be used.  'instantiate_parameters' is useful when you use the results of
  SCEV only for some analysis, and when you work with whole nest of loops
  at once.  It will try replacing all SSA names by their SCEV in all
  loops, including the super-loops of the current loop, thus providing a
  complete information about the behavior of the variable in the loop
! nest.  'resolve_mixers' is useful if you work with only one loop at a
  time, and if you possibly need to create code based on the value of the
  induction variable.  It will only resolve the SSA names defined in the
  current loop, leaving the SSA names defined outside unchanged, even if
  their evolution in the outer loops is known.
  
   The SCEV is a normal tree expression, except for the fact that it may
! contain several special tree nodes.  One of them is 'SCEV_NOT_KNOWN',
  used for SSA names whose value cannot be expressed.  The other one is
! 'POLYNOMIAL_CHREC'.  Polynomial chrec has three arguments - base, step
  and loop (both base and step may contain further polynomial chrecs).
  Type of the expression and of base and step must be the same.  A
! variable has evolution 'POLYNOMIAL_CHREC(base, step, loop)' if it is (in
! the specified loop) equivalent to 'x_1' in the following example
  
       while (...)
         {
--- 21755,21791 ----
  complicated behavior in a simple and consistent way (we only use it to
  express values of polynomial induction variables, but it is possible to
  extend it).  The interfaces to SCEV analysis are declared in
! ‘tree-scalar-evolution.h’.  To use scalar evolutions analysis,
! ‘scev_initialize’ must be used.  To stop using SCEV, ‘scev_finalize’
  should be used.  SCEV analysis caches results in order to save time and
  memory.  This cache however is made invalid by most of the loop
  transformations, including removal of code.  If such a transformation is
! performed, ‘scev_reset’ must be called to clean the caches.
  
   Given an SSA name, its behavior in loops can be analyzed using the
! ‘analyze_scalar_evolution’ function.  The returned SCEV however does not
  have to be fully analyzed and it may contain references to other SSA
  names defined in the loop.  To resolve these (potentially recursive)
! references, ‘instantiate_parameters’ or ‘resolve_mixers’ functions must
! be used.  ‘instantiate_parameters’ is useful when you use the results of
  SCEV only for some analysis, and when you work with whole nest of loops
  at once.  It will try replacing all SSA names by their SCEV in all
  loops, including the super-loops of the current loop, thus providing a
  complete information about the behavior of the variable in the loop
! nest.  ‘resolve_mixers’ is useful if you work with only one loop at a
  time, and if you possibly need to create code based on the value of the
  induction variable.  It will only resolve the SSA names defined in the
  current loop, leaving the SSA names defined outside unchanged, even if
  their evolution in the outer loops is known.
  
   The SCEV is a normal tree expression, except for the fact that it may
! contain several special tree nodes.  One of them is ‘SCEV_NOT_KNOWN’,
  used for SSA names whose value cannot be expressed.  The other one is
! ‘POLYNOMIAL_CHREC’.  Polynomial chrec has three arguments - base, step
  and loop (both base and step may contain further polynomial chrecs).
  Type of the expression and of base and step must be the same.  A
! variable has evolution ‘POLYNOMIAL_CHREC(base, step, loop)’ if it is (in
! the specified loop) equivalent to ‘x_1’ in the following example
  
       while (...)
         {
*************** the specified loop) equivalent to 'x_1'
*** 21795,21801 ****
         }
  
   Note that this includes the language restrictions on the operations.
! For example, if we compile C code and 'x' has signed type, then the
  overflow in addition would cause undefined behavior, and we may assume
  that this does not happen.  Hence, the value with this SCEV cannot
  overflow (which restricts the number of iterations of such a loop).
--- 21794,21800 ----
         }
  
   Note that this includes the language restrictions on the operations.
! For example, if we compile C code and ‘x’ has signed type, then the
  overflow in addition would cause undefined behavior, and we may assume
  that this does not happen.  Hence, the value with this SCEV cannot
  overflow (which restricts the number of iterations of such a loop).
*************** overflow (which restricts the number of
*** 21803,21809 ****
   In many cases, one wants to restrict the attention just to affine
  induction variables.  In this case, the extra expressive power of SCEV
  is not useful, and may complicate the optimizations.  In this case,
! 'simple_iv' function may be used to analyze a value - the result is a
  loop-invariant base and step.
  
  
--- 21802,21808 ----
   In many cases, one wants to restrict the attention just to affine
  induction variables.  In this case, the extra expressive power of SCEV
  is not useful, and may complicate the optimizations.  In this case,
! ‘simple_iv’ function may be used to analyze a value - the result is a
  loop-invariant base and step.
  
  
*************** File: gccint.info,  Node: loop-iv,  Next
*** 21814,21851 ****
  
  The induction variable on RTL is simple and only allows analysis of
  affine induction variables, and only in one loop at once.  The interface
! is declared in 'cfgloop.h'.  Before analyzing induction variables in a
! loop L, 'iv_analysis_loop_init' function must be called on L. After the
! analysis (possibly calling 'iv_analysis_loop_init' for several loops) is
! finished, 'iv_analysis_done' should be called.  The following functions
  can be used to access the results of the analysis:
  
!    * 'iv_analyze': Analyzes a single register used in the given insn.
       If no use of the register in this insn is found, the following
       insns are scanned, so that this function can be called on the insn
       returned by get_condition.
!    * 'iv_analyze_result': Analyzes result of the assignment in the given
       insn.
!    * 'iv_analyze_expr': Analyzes a more complicated expression.  All its
!      operands are analyzed by 'iv_analyze', and hence they must be used
       in the specified insn or one of the following insns.
  
!  The description of the induction variable is provided in 'struct
! rtx_iv'.  In order to handle subregs, the representation is a bit
! complicated; if the value of the 'extend' field is not 'UNKNOWN', the
  value of the induction variable in the i-th iteration is
  
       delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)),
  
!  with the following exception: if 'first_special' is true, then the
! value in the first iteration (when 'i' is zero) is 'delta + mult *
! base'.  However, if 'extend' is equal to 'UNKNOWN', then 'first_special'
! must be false, 'delta' 0, 'mult' 1 and the value in the i-th iteration
  is
  
       subreg_{mode} (base + i * step)
  
!  The function 'get_iv_value' can be used to perform these calculations.
  
  
  File: gccint.info,  Node: Number of iterations,  Next: Dependency analysis,  Prev: loop-iv,  Up: Loop Analysis and Representation
--- 21813,21850 ----
  
  The induction variable on RTL is simple and only allows analysis of
  affine induction variables, and only in one loop at once.  The interface
! is declared in ‘cfgloop.h’.  Before analyzing induction variables in a
! loop L, ‘iv_analysis_loop_init’ function must be called on L. After the
! analysis (possibly calling ‘iv_analysis_loop_init’ for several loops) is
! finished, ‘iv_analysis_done’ should be called.  The following functions
  can be used to access the results of the analysis:
  
!    • ‘iv_analyze’: Analyzes a single register used in the given insn.
       If no use of the register in this insn is found, the following
       insns are scanned, so that this function can be called on the insn
       returned by get_condition.
!    • ‘iv_analyze_result’: Analyzes result of the assignment in the given
       insn.
!    • ‘iv_analyze_expr’: Analyzes a more complicated expression.  All its
!      operands are analyzed by ‘iv_analyze’, and hence they must be used
       in the specified insn or one of the following insns.
  
!  The description of the induction variable is provided in ‘struct
! rtx_iv’.  In order to handle subregs, the representation is a bit
! complicated; if the value of the ‘extend’ field is not ‘UNKNOWN’, the
  value of the induction variable in the i-th iteration is
  
       delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)),
  
!  with the following exception: if ‘first_special’ is true, then the
! value in the first iteration (when ‘i’ is zero) is ‘delta + mult *
! base’.  However, if ‘extend’ is equal to ‘UNKNOWN’, then ‘first_special’
! must be false, ‘delta’ 0, ‘mult’ 1 and the value in the i-th iteration
  is
  
       subreg_{mode} (base + i * step)
  
!  The function ‘get_iv_value’ can be used to perform these calculations.
  
  
  File: gccint.info,  Node: Number of iterations,  Next: Dependency analysis,  Prev: loop-iv,  Up: Loop Analysis and Representation
*************** program; if it fails, the conditions are
*** 21864,21925 ****
  result.  The following information and conditions are provided by the
  analysis:
  
!    * 'assumptions': If this condition is false, the rest of the
       information is invalid.
!    * 'noloop_assumptions' on RTL, 'may_be_zero' on GIMPLE: If this
       condition is true, the loop exits in the first iteration.
!    * 'infinite': If this condition is true, the loop is infinite.  This
       condition is only available on RTL.  On GIMPLE, conditions for
!      finiteness of the loop are included in 'assumptions'.
!    * 'niter_expr' on RTL, 'niter' on GIMPLE: The expression that gives
       number of iterations.  The number of iterations is defined as the
       number of executions of the loop latch.
  
   Both on GIMPLE and on RTL, it necessary for the induction variable
  analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL).
! On GIMPLE, the results are stored to 'struct tree_niter_desc' structure.
  Number of iterations before the loop is exited through a given exit can
! be determined using 'number_of_iterations_exit' function.  On RTL, the
! results are returned in 'struct niter_desc' structure.  The
! corresponding function is named 'check_simple_exit'.  There are also
  functions that pass through all the exits of a loop and try to find one
! with easy to determine number of iterations - 'find_loop_niter' on
! GIMPLE and 'find_simple_exit' on RTL.  Finally, there are functions that
  provide the same information, but additionally cache it, so that
  repeated calls to number of iterations are not so costly -
! 'number_of_latch_executions' on GIMPLE and 'get_simple_loop_desc' on
  RTL.
  
   Note that some of these functions may behave slightly differently than
  others - some of them return only the expression for the number of
  iterations, and fail if there are some assumptions.  The function
! 'number_of_latch_executions' works only for single-exit loops.  The
! function 'number_of_cond_exit_executions' can be used to determine
  number of executions of the exit condition of a single-exit loop (i.e.,
! the 'number_of_latch_executions' increased by one).
  
   On GIMPLE, below constraint flags affect semantics of some APIs of
  number of iterations analyzer:
  
!    * 'LOOP_C_INFINITE': If this constraint flag is set, the loop is
!      known to be infinite.  APIs like 'number_of_iterations_exit' can
       return false directly without doing any analysis.
!    * 'LOOP_C_FINITE': If this constraint flag is set, the loop is known
       to be finite, in other words, loop's number of iterations can be
!      computed with 'assumptions' be true.
  
   Generally, the constraint flags are set/cleared by consumers which are
  loop optimizers.  It's also the consumers' responsibility to set/clear
  constraints correctly.  Failing to do that might result in hard to track
  down bugs in scev/niter consumers.  One typical use case is vectorizer:
! it drives number of iterations analyzer by setting 'LOOP_C_FINITE' and
  vectorizes possibly infinite loop by versioning loop with analysis
  result.  In return, constraints set by consumers can also help number of
! iterations analyzer in following optimizers.  For example, 'niter' of a
! loop versioned under 'assumptions' is valid unconditionally.
  
   Other constraints may be added in the future, for example, a constraint
! indicating that loops' latch must roll thus 'may_be_zero' would be false
  unconditionally.
  
  
--- 21863,21924 ----
  result.  The following information and conditions are provided by the
  analysis:
  
!    • ‘assumptions’: If this condition is false, the rest of the
       information is invalid.
!    • ‘noloop_assumptions’ on RTL, ‘may_be_zero’ on GIMPLE: If this
       condition is true, the loop exits in the first iteration.
!    • ‘infinite’: If this condition is true, the loop is infinite.  This
       condition is only available on RTL.  On GIMPLE, conditions for
!      finiteness of the loop are included in ‘assumptions’.
!    • ‘niter_expr’ on RTL, ‘niter’ on GIMPLE: The expression that gives
       number of iterations.  The number of iterations is defined as the
       number of executions of the loop latch.
  
   Both on GIMPLE and on RTL, it necessary for the induction variable
  analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL).
! On GIMPLE, the results are stored to ‘struct tree_niter_desc’ structure.
  Number of iterations before the loop is exited through a given exit can
! be determined using ‘number_of_iterations_exit’ function.  On RTL, the
! results are returned in ‘struct niter_desc’ structure.  The
! corresponding function is named ‘check_simple_exit’.  There are also
  functions that pass through all the exits of a loop and try to find one
! with easy to determine number of iterations - ‘find_loop_niter’ on
! GIMPLE and ‘find_simple_exit’ on RTL.  Finally, there are functions that
  provide the same information, but additionally cache it, so that
  repeated calls to number of iterations are not so costly -
! ‘number_of_latch_executions’ on GIMPLE and ‘get_simple_loop_desc’ on
  RTL.
  
   Note that some of these functions may behave slightly differently than
  others - some of them return only the expression for the number of
  iterations, and fail if there are some assumptions.  The function
! ‘number_of_latch_executions’ works only for single-exit loops.  The
! function ‘number_of_cond_exit_executions’ can be used to determine
  number of executions of the exit condition of a single-exit loop (i.e.,
! the ‘number_of_latch_executions’ increased by one).
  
   On GIMPLE, below constraint flags affect semantics of some APIs of
  number of iterations analyzer:
  
!    • ‘LOOP_C_INFINITE’: If this constraint flag is set, the loop is
!      known to be infinite.  APIs like ‘number_of_iterations_exit’ can
       return false directly without doing any analysis.
!    • ‘LOOP_C_FINITE’: If this constraint flag is set, the loop is known
       to be finite, in other words, loop's number of iterations can be
!      computed with ‘assumptions’ be true.
  
   Generally, the constraint flags are set/cleared by consumers which are
  loop optimizers.  It's also the consumers' responsibility to set/clear
  constraints correctly.  Failing to do that might result in hard to track
  down bugs in scev/niter consumers.  One typical use case is vectorizer:
! it drives number of iterations analyzer by setting ‘LOOP_C_FINITE’ and
  vectorizes possibly infinite loop by versioning loop with analysis
  result.  In return, constraints set by consumers can also help number of
! iterations analyzer in following optimizers.  For example, ‘niter’ of a
! loop versioned under ‘assumptions’ is valid unconditionally.
  
   Other constraints may be added in the future, for example, a constraint
! indicating that loops' latch must roll thus ‘may_be_zero’ would be false
  unconditionally.
  
  
*************** File: gccint.info,  Node: Dependency ana
*** 21929,21948 ****
  =============================
  
  The code for the data dependence analysis can be found in
! 'tree-data-ref.cc' and its interface and data structures are described
! in 'tree-data-ref.h'.  The function that computes the data dependences
  for all the array and pointer references for a given loop is
! 'compute_data_dependences_for_loop'.  This function is currently used by
  the linear loop transform and the vectorization passes.  Before calling
  this function, one has to allocate two vectors: a first vector will
  contain the set of data references that are contained in the analyzed
  loop body, and the second vector will contain the dependence relations
  between the data references.  Thus if the vector of data references is
! of size 'n', the vector containing the dependence relations will contain
! 'n*n' elements.  However if the analyzed loop contains side effects,
  such as calls that potentially can interfere with the data references in
  the current analyzed loop, the analysis stops while scanning the loop
! body for data references, and inserts a single 'chrec_dont_know' in the
  dependence relation array.
  
   The data references are discovered in a particular order during the
--- 21928,21947 ----
  =============================
  
  The code for the data dependence analysis can be found in
! ‘tree-data-ref.cc’ and its interface and data structures are described
! in ‘tree-data-ref.h’.  The function that computes the data dependences
  for all the array and pointer references for a given loop is
! ‘compute_data_dependences_for_loop’.  This function is currently used by
  the linear loop transform and the vectorization passes.  Before calling
  this function, one has to allocate two vectors: a first vector will
  contain the set of data references that are contained in the analyzed
  loop body, and the second vector will contain the dependence relations
  between the data references.  Thus if the vector of data references is
! of size ‘n’, the vector containing the dependence relations will contain
! ‘n*n’ elements.  However if the analyzed loop contains side effects,
  such as calls that potentially can interfere with the data references in
  the current analyzed loop, the analysis stops while scanning the loop
! body for data references, and inserts a single ‘chrec_dont_know’ in the
  dependence relation array.
  
   The data references are discovered in a particular order during the
*************** queries to the loop body representation.
*** 21956,21975 ****
  
   Three types of data references are currently handled: ARRAY_REF,
  INDIRECT_REF and COMPONENT_REF.  The data structure for the data
! reference is 'data_reference', where 'data_reference_p' is a name of a
  pointer to the data reference structure.  The structure contains the
  following elements:
  
!    * 'base_object_info': Provides information about the base object of
       the data reference and its access functions.  These access
       functions represent the evolution of the data reference in the loop
       relative to its base, in keeping with the classical meaning of the
       data reference access function for the support of arrays.  For
!      example, for a reference 'a.b[i][j]', the base object is 'a.b' and
!      the access functions, one for each array subscript, are: '{i_init,
!      + i_step}_1, {j_init, +, j_step}_2'.
  
!    * 'first_location_in_loop': Provides information about the first
       location accessed by the data reference in the loop and about the
       access function used to represent evolution relative to this
       location.  This data is used to support pointers, and is not used
--- 21955,21974 ----
  
   Three types of data references are currently handled: ARRAY_REF,
  INDIRECT_REF and COMPONENT_REF.  The data structure for the data
! reference is ‘data_reference’, where ‘data_reference_p’ is a name of a
  pointer to the data reference structure.  The structure contains the
  following elements:
  
!    • ‘base_object_info’: Provides information about the base object of
       the data reference and its access functions.  These access
       functions represent the evolution of the data reference in the loop
       relative to its base, in keeping with the classical meaning of the
       data reference access function for the support of arrays.  For
!      example, for a reference ‘a.b[i][j]’, the base object is ‘a.b’ and
!      the access functions, one for each array subscript, are: ‘{i_init,
!      + i_step}_1, {j_init, +, j_step}_2’.
  
!    • ‘first_location_in_loop’: Provides information about the first
       location accessed by the data reference in the loop and about the
       access function used to represent evolution relative to this
       location.  This data is used to support pointers, and is not used
*************** following elements:
*** 21981,21990 ****
                     for2 j
                      *((int *)p + i + j) = a[i][j];
  
!      The access function of the pointer access is '{0, + 4B}_for2'
!      relative to 'p + i'.  The access functions of the array are
!      '{i_init, + i_step}_for1' and '{j_init, +, j_step}_for2' relative
!      to 'a'.
  
       Usually, the object the pointer refers to is either unknown, or we
       cannot prove that the access is confined to the boundaries of a
--- 21980,21989 ----
                     for2 j
                      *((int *)p + i + j) = a[i][j];
  
!      The access function of the pointer access is ‘{0, + 4B}_for2’
!      relative to ‘p + i’.  The access functions of the array are
!      ‘{i_init, + i_step}_for1’ and ‘{j_init, +, j_step}_for2’ relative
!      to ‘a’.
  
       Usually, the object the pointer refers to is either unknown, or we
       cannot prove that the access is confined to the boundaries of a
*************** following elements:
*** 21995,22044 ****
       references.
  
       The current strategy for data dependence tests is as follows: If
!      both 'a' and 'b' are represented as arrays, compare 'a.base_object'
!      and 'b.base_object'; if they are equal, apply dependence tests (use
!      access functions based on base_objects).  Else if both 'a' and 'b'
!      are represented as pointers, compare 'a.first_location' and
!      'b.first_location'; if they are equal, apply dependence tests (use
!      access functions based on first location).  However, if 'a' and 'b'
       are represented differently, only try to prove that the bases are
       definitely different.
  
!    * Aliasing information.
!    * Alignment information.
  
   The structure describing the relation between two data references is
! 'data_dependence_relation' and the shorter name for a pointer to such a
! structure is 'ddr_p'.  This structure contains:
  
!    * a pointer to each data reference,
!    * a tree node 'are_dependent' that is set to 'chrec_known' if the
       analysis has proved that there is no dependence between these two
!      data references, 'chrec_dont_know' if the analysis was not able to
       determine any useful result and potentially there could exist a
!      dependence between these data references, and 'are_dependent' is
!      set to 'NULL_TREE' if there exist a dependence relation between the
       data references, and the description of this dependence relation is
!      given in the 'subscripts', 'dir_vects', and 'dist_vects' arrays,
!    * a boolean that determines whether the dependence relation can be
       represented by a classical distance vector,
!    * an array 'subscripts' that contains a description of each subscript
       of the data references.  Given two array accesses a subscript is
       the tuple composed of the access functions for a given dimension.
!      For example, given 'A[f1][f2][f3]' and 'B[g1][g2][g3]', there are
!      three subscripts: '(f1, g1), (f2, g2), (f3, g3)'.
!    * two arrays 'dir_vects' and 'dist_vects' that contain classical
       representations of the data dependences under the form of direction
       and distance dependence vectors,
!    * an array of loops 'loop_nest' that contains the loops to which the
       distance and direction vectors refer to.
  
   Several functions for pretty printing the information extracted by the
! data dependence analysis are available: 'dump_ddrs' prints with a
  maximum verbosity the details of a data dependence relations array,
! 'dump_dist_dir_vectors' prints only the classical distance and direction
  vectors for a data dependence relations array, and
! 'dump_data_references' prints the details of the data references
  contained in a data reference array.
  
  
--- 21994,22043 ----
       references.
  
       The current strategy for data dependence tests is as follows: If
!      both ‘a’ and ‘b’ are represented as arrays, compare ‘a.base_object’
!      and ‘b.base_object’; if they are equal, apply dependence tests (use
!      access functions based on base_objects).  Else if both ‘a’ and ‘b’
!      are represented as pointers, compare ‘a.first_location’ and
!      ‘b.first_location’; if they are equal, apply dependence tests (use
!      access functions based on first location).  However, if ‘a’ and ‘b’
       are represented differently, only try to prove that the bases are
       definitely different.
  
!    • Aliasing information.
!    • Alignment information.
  
   The structure describing the relation between two data references is
! ‘data_dependence_relation’ and the shorter name for a pointer to such a
! structure is ‘ddr_p’.  This structure contains:
  
!    • a pointer to each data reference,
!    • a tree node ‘are_dependent’ that is set to ‘chrec_known’ if the
       analysis has proved that there is no dependence between these two
!      data references, ‘chrec_dont_know’ if the analysis was not able to
       determine any useful result and potentially there could exist a
!      dependence between these data references, and ‘are_dependent’ is
!      set to ‘NULL_TREE’ if there exist a dependence relation between the
       data references, and the description of this dependence relation is
!      given in the ‘subscripts’, ‘dir_vects’, and ‘dist_vects’ arrays,
!    • a boolean that determines whether the dependence relation can be
       represented by a classical distance vector,
!    • an array ‘subscripts’ that contains a description of each subscript
       of the data references.  Given two array accesses a subscript is
       the tuple composed of the access functions for a given dimension.
!      For example, given ‘A[f1][f2][f3]’ and ‘B[g1][g2][g3]’, there are
!      three subscripts: ‘(f1, g1), (f2, g2), (f3, g3)’.
!    • two arrays ‘dir_vects’ and ‘dist_vects’ that contain classical
       representations of the data dependences under the form of direction
       and distance dependence vectors,
!    • an array of loops ‘loop_nest’ that contains the loops to which the
       distance and direction vectors refer to.
  
   Several functions for pretty printing the information extracted by the
! data dependence analysis are available: ‘dump_ddrs’ prints with a
  maximum verbosity the details of a data dependence relations array,
! ‘dump_dist_dir_vectors’ prints only the classical distance and direction
  vectors for a data dependence relations array, and
! ‘dump_data_references’ prints the details of the data references
  contained in a data reference array.
  
  
*************** File: gccint.info,  Node: Machine Desc,
*** 22048,22056 ****
  ***********************
  
  A machine description has two parts: a file of instruction patterns
! ('.md' file) and a C header file of macro definitions.
  
!  The '.md' file for a target machine contains a pattern for each
  instruction that the target machine supports (or at least each
  instruction that is worth telling the compiler about).  It may also
  contain comments.  A semicolon causes the rest of the line to be a
--- 22047,22055 ----
  ***********************
  
  A machine description has two parts: a file of instruction patterns
! (‘.md’ file) and a C header file of macro definitions.
  
!  The ‘.md’ file for a target machine contains a pattern for each
  instruction that the target machine supports (or at least each
  instruction that is worth telling the compiler about).  It may also
  contain comments.  A semicolon causes the rest of the line to be a
*************** comment, unless the semicolon is inside
*** 22062,22068 ****
  
  * Overview::            How the machine description is used.
  * Patterns::            How to write instruction patterns.
! * Example::             An explained example of a 'define_insn' pattern.
  * RTL Template::        The RTL template defines what insns match a pattern.
  * Output Template::     The output template says how to make assembler code
                          from such an insn.
--- 22061,22067 ----
  
  * Overview::            How the machine description is used.
  * Patterns::            How to write instruction patterns.
! * Example::             An explained example of a ‘define_insn’ pattern.
  * RTL Template::        The RTL template defines what insns match a pattern.
  * Output Template::     The output template says how to make assembler code
                          from such an insn.
*************** comment, unless the semicolon is inside
*** 22083,22091 ****
  * Including Patterns::  Including Patterns in Machine Descriptions.
  * Peephole Definitions::Defining machine-specific peephole optimizations.
  * Insn Attributes::     Specifying the value of attributes for generated insns.
! * Conditional Execution::Generating 'define_insn' patterns for
                           predication.
! * Define Subst::	Generating 'define_insn' and 'define_expand'
  			patterns from other patterns.
  * Constant Definitions::Defining symbolic constants that can be used in the
                          md file.
--- 22082,22090 ----
  * Including Patterns::  Including Patterns in Machine Descriptions.
  * Peephole Definitions::Defining machine-specific peephole optimizations.
  * Insn Attributes::     Specifying the value of attributes for generated insns.
! * Conditional Execution::Generating ‘define_insn’ patterns for
                           predication.
! * Define Subst::	Generating ‘define_insn’ and ‘define_expand’
  			patterns from other patterns.
  * Constant Definitions::Defining symbolic constants that can be used in the
                          md file.
*************** There are three main conversions that ha
*** 22108,22114 ****
       assembler code.
  
   For the generate pass, only the names of the insns matter, from either
! a named 'define_insn' or a 'define_expand'.  The compiler will choose
  the pattern with the right name and apply the operands according to the
  documentation later in this chapter, without regard for the RTL template
  or operand constraints.  Note that the names the compiler looks for are
--- 22107,22113 ----
       assembler code.
  
   For the generate pass, only the names of the insns matter, from either
! a named ‘define_insn’ or a ‘define_expand’.  The compiler will choose
  the pattern with the right name and apply the operands according to the
  documentation later in this chapter, without regard for the RTL template
  or operand constraints.  Note that the names the compiler looks for are
*************** hard-coded in the compiler--it will igno
*** 22116,22137 ****
  with names it doesn't know about, but if you don't provide a named
  pattern it needs, it will abort.
  
!  If a 'define_insn' is used, the template given is inserted into the
! insn list.  If a 'define_expand' is used, one of three things happens,
  based on the condition logic.  The condition logic may manually create
! new insns for the insn list, say via 'emit_insn()', and invoke 'DONE'.
! For certain named patterns, it may invoke 'FAIL' to tell the compiler to
  use an alternate way of performing that task.  If it invokes neither
! 'DONE' nor 'FAIL', the template given in the pattern is inserted, as if
! the 'define_expand' were a 'define_insn'.
  
   Once the insn list is generated, various optimization passes convert,
  replace, and rearrange the insns in the insn list.  This is where the
! 'define_split' and 'define_peephole' patterns get used, for example.
  
   Finally, the insn list's RTL is matched up with the RTL templates in
! the 'define_insn' patterns, and those patterns are used to emit the
! final assembly code.  For this purpose, each named 'define_insn' acts
  like it's unnamed, since the names are ignored.
  
  
--- 22115,22136 ----
  with names it doesn't know about, but if you don't provide a named
  pattern it needs, it will abort.
  
!  If a ‘define_insn’ is used, the template given is inserted into the
! insn list.  If a ‘define_expand’ is used, one of three things happens,
  based on the condition logic.  The condition logic may manually create
! new insns for the insn list, say via ‘emit_insn()’, and invoke ‘DONE’.
! For certain named patterns, it may invoke ‘FAIL’ to tell the compiler to
  use an alternate way of performing that task.  If it invokes neither
! ‘DONE’ nor ‘FAIL’, the template given in the pattern is inserted, as if
! the ‘define_expand’ were a ‘define_insn’.
  
   Once the insn list is generated, various optimization passes convert,
  replace, and rearrange the insns in the insn list.  This is where the
! ‘define_split’ and ‘define_peephole’ patterns get used, for example.
  
   Finally, the insn list's RTL is matched up with the RTL templates in
! the ‘define_insn’ patterns, and those patterns are used to emit the
! final assembly code.  For this purpose, each named ‘define_insn’ acts
  like it's unnamed, since the names are ignored.
  
  
*************** File: gccint.info,  Node: Patterns,  Nex
*** 22140,22159 ****
  17.2 Everything about Instruction Patterns
  ==========================================
  
! A 'define_insn' expression is used to define instruction patterns to
! which insns may be matched.  A 'define_insn' expression contains an
  incomplete RTL expression, with pieces to be filled in later, operand
  constraints that restrict how the pieces can be filled in, and an output
  template or C code to generate the assembler output.
  
!  A 'define_insn' is an RTL expression containing four or five operands:
  
    1. An optional name N.  When a name is present, the compiler
!      automically generates a C++ function 'gen_N' that takes the
       operands of the instruction as arguments and returns the
       instruction's rtx pattern.  The compiler also assigns the
!      instruction a unique code 'CODE_FOR_N', with all such codes
!      belonging to an enum called 'insn_code'.
  
       These names serve one of two purposes.  The first is to indicate
       that the instruction performs a certain standard job for the
--- 22139,22158 ----
  17.2 Everything about Instruction Patterns
  ==========================================
  
! A ‘define_insn’ expression is used to define instruction patterns to
! which insns may be matched.  A ‘define_insn’ expression contains an
  incomplete RTL expression, with pieces to be filled in later, operand
  constraints that restrict how the pieces can be filled in, and an output
  template or C code to generate the assembler output.
  
!  A ‘define_insn’ is an RTL expression containing four or five operands:
  
    1. An optional name N.  When a name is present, the compiler
!      automically generates a C++ function ‘gen_N’ that takes the
       operands of the instruction as arguments and returns the
       instruction's rtx pattern.  The compiler also assigns the
!      instruction a unique code ‘CODE_FOR_N’, with all such codes
!      belonging to an enum called ‘insn_code’.
  
       These names serve one of two purposes.  The first is to indicate
       that the instruction performs a certain standard job for the
*************** template or C code to generate the assem
*** 22171,22199 ****
       to be combined later on.
  
       For the purpose of debugging the compiler, you may also specify a
!      name beginning with the '*' character.  Such a name is used only
       for identifying the instruction in RTL dumps; it is equivalent to
       having a nameless pattern for all other purposes.  Names beginning
!      with the '*' character are not required to be unique.
  
!      The name may also have the form '@N'.  This has the same effect as
!      a name 'N', but in addition tells the compiler to generate further
       helper functions; see *note Parameterized Names:: for details.
  
!   2. The "RTL template": This is a vector of incomplete RTL expressions
       which describe the semantics of the instruction (*note RTL
       Template::).  It is incomplete because it may contain
!      'match_operand', 'match_operator', and 'match_dup' expressions that
       stand for operands of the instruction.
  
       If the vector has multiple elements, the RTL template is treated as
!      a 'parallel' expression.
  
    3. The condition: This is a string which contains a C expression.
       When the compiler attempts to match RTL against a pattern, the
!      condition is evaluated.  If the condition evaluates to 'true', the
       match is permitted.  The condition may be an empty string, which is
!      treated as always 'true'.
  
       For a named pattern, the condition may not depend on the data in
       the insn being matched, but only the target-machine-type flags.
--- 22170,22198 ----
       to be combined later on.
  
       For the purpose of debugging the compiler, you may also specify a
!      name beginning with the ‘*’ character.  Such a name is used only
       for identifying the instruction in RTL dumps; it is equivalent to
       having a nameless pattern for all other purposes.  Names beginning
!      with the ‘*’ character are not required to be unique.
  
!      The name may also have the form ‘@N’.  This has the same effect as
!      a name ‘N’, but in addition tells the compiler to generate further
       helper functions; see *note Parameterized Names:: for details.
  
!   2. The “RTL template”: This is a vector of incomplete RTL expressions
       which describe the semantics of the instruction (*note RTL
       Template::).  It is incomplete because it may contain
!      ‘match_operand’, ‘match_operator’, and ‘match_dup’ expressions that
       stand for operands of the instruction.
  
       If the vector has multiple elements, the RTL template is treated as
!      a ‘parallel’ expression.
  
    3. The condition: This is a string which contains a C expression.
       When the compiler attempts to match RTL against a pattern, the
!      condition is evaluated.  If the condition evaluates to ‘true’, the
       match is permitted.  The condition may be an empty string, which is
!      treated as always ‘true’.
  
       For a named pattern, the condition may not depend on the data in
       the insn being matched, but only the target-machine-type flags.
*************** template or C code to generate the assem
*** 22204,22216 ****
       For nameless patterns, the condition is applied only when matching
       an individual insn, and only after the insn has matched the
       pattern's recognition template.  The insn's operands may be found
!      in the vector 'operands'.
  
       An instruction condition cannot become more restrictive as
       compilation progresses.  If the condition accepts a particular RTL
       instruction at one stage of compilation, it must continue to accept
       that instruction until the final pass.  For example,
!      '!reload_completed' and 'can_create_pseudo_p ()' are both invalid
       instruction conditions, because they are true during the earlier
       RTL passes and false during the later ones.  For the same reason,
       if a condition accepts an instruction before register allocation,
--- 22203,22215 ----
       For nameless patterns, the condition is applied only when matching
       an individual insn, and only after the insn has matched the
       pattern's recognition template.  The insn's operands may be found
!      in the vector ‘operands’.
  
       An instruction condition cannot become more restrictive as
       compilation progresses.  If the condition accepts a particular RTL
       instruction at one stage of compilation, it must continue to accept
       that instruction until the final pass.  For example,
!      ‘!reload_completed’ and ‘can_create_pseudo_p ()’ are both invalid
       instruction conditions, because they are true during the earlier
       RTL passes and false during the later ones.  For the same reason,
       if a condition accepts an instruction before register allocation,
*************** template or C code to generate the assem
*** 22220,22242 ****
       Although a condition cannot become more restrictive as compilation
       progresses, the condition for a nameless pattern _can_ become more
       permissive.  For example, a nameless instruction can require
!      'reload_completed' to be true, in which case it only matches after
       register allocation.
  
!   4. The "output template" or "output statement": This is either a
       string, or a fragment of C code which returns a string.
  
       When simple substitution isn't general enough, you can specify a
       piece of C code to compute the output.  *Note Output Statement::.
  
!   5. The "insn attributes": This is an optional vector containing the
       values of attributes for insns matching this pattern (*note Insn
       Attributes::).
  
  
  File: gccint.info,  Node: Example,  Next: RTL Template,  Prev: Patterns,  Up: Machine Desc
  
! 17.3 Example of 'define_insn'
  =============================
  
  Here is an example of an instruction pattern, taken from the machine
--- 22219,22241 ----
       Although a condition cannot become more restrictive as compilation
       progresses, the condition for a nameless pattern _can_ become more
       permissive.  For example, a nameless instruction can require
!      ‘reload_completed’ to be true, in which case it only matches after
       register allocation.
  
!   4. The “output template” or “output statement”: This is either a
       string, or a fragment of C code which returns a string.
  
       When simple substitution isn't general enough, you can specify a
       piece of C code to compute the output.  *Note Output Statement::.
  
!   5. The “insn attributes”: This is an optional vector containing the
       values of attributes for insns matching this pattern (*note Insn
       Attributes::).
  
  
  File: gccint.info,  Node: Example,  Next: RTL Template,  Prev: Patterns,  Up: Machine Desc
  
! 17.3 Example of ‘define_insn’
  =============================
  
  Here is an example of an instruction pattern, taken from the machine
*************** This can also be written using braced st
*** 22268,22274 ****
   This describes an instruction which sets the condition codes based on
  the value of a general operand.  It has no condition, so any insn with
  an RTL description of the form shown may be matched to this pattern.
! The name 'tstsi' means "test a 'SImode' value" and tells the RTL
  generation pass that, when it is necessary to test such a value, an insn
  to do so can be constructed using this pattern.
  
--- 22267,22273 ----
   This describes an instruction which sets the condition codes based on
  the value of a general operand.  It has no condition, so any insn with
  an RTL description of the form shown may be matched to this pattern.
! The name ‘tstsi’ means "test a ‘SImode’ value" and tells the RTL
  generation pass that, when it is necessary to test such a value, an insn
  to do so can be constructed using this pattern.
  
*************** to do so can be constructed using this p
*** 22276,22282 ****
  output template to return based on the kind of operand and the specific
  type of CPU for which code is being generated.
  
!  '"rm"' is an operand constraint.  Its meaning is explained below.
  
  
  File: gccint.info,  Node: RTL Template,  Next: Output Template,  Prev: Example,  Up: Machine Desc
--- 22275,22281 ----
  output template to return based on the kind of operand and the specific
  type of CPU for which code is being generated.
  
!  ‘"rm"’ is an operand constraint.  Its meaning is explained below.
  
  
  File: gccint.info,  Node: RTL Template,  Next: Output Template,  Prev: Example,  Up: Machine Desc
*************** the operands in the insn being matched.
*** 22294,22300 ****
  controlled by special expression types that direct matching and
  substitution of the operands.
  
! '(match_operand:M N PREDICATE CONSTRAINT)'
       This expression is a placeholder for operand number N of the insn.
       When constructing an insn, operand number N will be substituted at
       this point.  When matching an insn, whatever appears at this
--- 22293,22299 ----
  controlled by special expression types that direct matching and
  substitution of the operands.
  
! ‘(match_operand:M N PREDICATE CONSTRAINT)’
       This expression is a placeholder for operand number N of the insn.
       When constructing an insn, operand number N will be substituted at
       this point.  When matching an insn, whatever appears at this
*************** substitution of the operands.
*** 22303,22330 ****
       all.
  
       Operand numbers must be chosen consecutively counting from zero in
!      each instruction pattern.  There may be only one 'match_operand'
       expression in the pattern for each operand number.  Usually
!      operands are numbered in the order of appearance in 'match_operand'
!      expressions.  In the case of a 'define_expand', any operand numbers
!      used only in 'match_dup' expressions have higher values than all
       other operand numbers.
  
       PREDICATE is a string that is the name of a function that accepts
       two arguments, an expression and a machine mode.  *Note
       Predicates::.  During matching, the function will be called with
       the putative operand as the expression and M as the mode argument
!      (if M is not specified, 'VOIDmode' will be used, which normally
       causes PREDICATE to accept any mode).  If it returns zero, this
       instruction pattern fails to match.  PREDICATE may be an empty
       string; then it means no test is to be done on the operand, so
       anything which occurs in this position is valid.
  
       Most of the time, PREDICATE will reject modes other than M--but not
!      always.  For example, the predicate 'address_operand' uses M as the
       mode of memory ref that the address should be valid for.  Many
!      predicates accept 'const_int' nodes even though their mode is
!      'VOIDmode'.
  
       CONSTRAINT controls reloading and the choice of the best register
       class to use for a value, as explained later (*note Constraints::).
--- 22302,22329 ----
       all.
  
       Operand numbers must be chosen consecutively counting from zero in
!      each instruction pattern.  There may be only one ‘match_operand’
       expression in the pattern for each operand number.  Usually
!      operands are numbered in the order of appearance in ‘match_operand’
!      expressions.  In the case of a ‘define_expand’, any operand numbers
!      used only in ‘match_dup’ expressions have higher values than all
       other operand numbers.
  
       PREDICATE is a string that is the name of a function that accepts
       two arguments, an expression and a machine mode.  *Note
       Predicates::.  During matching, the function will be called with
       the putative operand as the expression and M as the mode argument
!      (if M is not specified, ‘VOIDmode’ will be used, which normally
       causes PREDICATE to accept any mode).  If it returns zero, this
       instruction pattern fails to match.  PREDICATE may be an empty
       string; then it means no test is to be done on the operand, so
       anything which occurs in this position is valid.
  
       Most of the time, PREDICATE will reject modes other than M--but not
!      always.  For example, the predicate ‘address_operand’ uses M as the
       mode of memory ref that the address should be valid for.  Many
!      predicates accept ‘const_int’ nodes even though their mode is
!      ‘VOIDmode’.
  
       CONSTRAINT controls reloading and the choice of the best register
       class to use for a value, as explained later (*note Constraints::).
*************** substitution of the operands.
*** 22336,22379 ****
       decision; instead, it controls various decisions in the case of an
       insn which does match.
  
! '(match_scratch:M N CONSTRAINT)'
       This expression is also a placeholder for operand number N and
!      indicates that operand must be a 'scratch' or 'reg' expression.
  
       When matching patterns, this is equivalent to
  
            (match_operand:M N "scratch_operand" CONSTRAINT)
  
!      but, when generating RTL, it produces a ('scratch':M) expression.
  
!      If the last few expressions in a 'parallel' are 'clobber'
       expressions whose operands are either a hard register or
!      'match_scratch', the combiner can add or delete them when
       necessary.  *Note Side Effects::.
  
! '(match_dup N)'
       This expression is also a placeholder for operand number N.  It is
       used when the operand needs to appear more than once in the insn.
  
!      In construction, 'match_dup' acts just like 'match_operand': the
       operand is substituted into the insn being constructed.  But in
!      matching, 'match_dup' behaves differently.  It assumes that operand
!      number N has already been determined by a 'match_operand' appearing
       earlier in the recognition template, and it matches only an
       identical-looking expression.
  
!      Note that 'match_dup' should not be used to tell the compiler that
       a particular register is being used for two operands (example:
!      'add' that adds one register to another; the second register is
       both an input operand and the output operand).  Use a matching
!      constraint (*note Simple Constraints::) for those.  'match_dup' is
       for the cases where one operand is used in two places in the
       template, such as an instruction that computes both a quotient and
       a remainder, where the opcode takes two input operands but the RTL
       template has to refer to each of those twice; once for the quotient
       pattern and once for the remainder pattern.
  
! '(match_operator:M N PREDICATE [OPERANDS...])'
       This pattern is a kind of placeholder for a variable RTL expression
       code.
  
--- 22335,22378 ----
       decision; instead, it controls various decisions in the case of an
       insn which does match.
  
! ‘(match_scratch:M N CONSTRAINT)’
       This expression is also a placeholder for operand number N and
!      indicates that operand must be a ‘scratch’ or ‘reg’ expression.
  
       When matching patterns, this is equivalent to
  
            (match_operand:M N "scratch_operand" CONSTRAINT)
  
!      but, when generating RTL, it produces a (‘scratch’:M) expression.
  
!      If the last few expressions in a ‘parallel’ are ‘clobber’
       expressions whose operands are either a hard register or
!      ‘match_scratch’, the combiner can add or delete them when
       necessary.  *Note Side Effects::.
  
! ‘(match_dup N)’
       This expression is also a placeholder for operand number N.  It is
       used when the operand needs to appear more than once in the insn.
  
!      In construction, ‘match_dup’ acts just like ‘match_operand’: the
       operand is substituted into the insn being constructed.  But in
!      matching, ‘match_dup’ behaves differently.  It assumes that operand
!      number N has already been determined by a ‘match_operand’ appearing
       earlier in the recognition template, and it matches only an
       identical-looking expression.
  
!      Note that ‘match_dup’ should not be used to tell the compiler that
       a particular register is being used for two operands (example:
!      ‘add’ that adds one register to another; the second register is
       both an input operand and the output operand).  Use a matching
!      constraint (*note Simple Constraints::) for those.  ‘match_dup’ is
       for the cases where one operand is used in two places in the
       template, such as an instruction that computes both a quotient and
       a remainder, where the opcode takes two input operands but the RTL
       template has to refer to each of those twice; once for the quotient
       pattern and once for the remainder pattern.
  
! ‘(match_operator:M N PREDICATE [OPERANDS...])’
       This pattern is a kind of placeholder for a variable RTL expression
       code.
  
*************** substitution of the operands.
*** 22385,22391 ****
       function PREDICATE returns nonzero on that expression _and_ the
       patterns OPERANDS match the operands of the expression.
  
!      Suppose that the function 'commutative_operator' is defined as
       follows, to match any expression whose operator is one of the
       commutative arithmetic operators of RTL and whose mode is MODE:
  
--- 22384,22390 ----
       function PREDICATE returns nonzero on that expression _and_ the
       patterns OPERANDS match the operands of the expression.
  
!      Suppose that the function ‘commutative_operator’ is defined as
       follows, to match any expression whose operator is one of the
       commutative arithmetic operators of RTL and whose mode is MODE:
  
*************** substitution of the operands.
*** 22408,22424 ****
              [(match_operand:SI 1 "general_operand" "g")
               (match_operand:SI 2 "general_operand" "g")])
  
!      Here the vector '[OPERANDS...]' contains two patterns because the
       expressions to be matched all contain two operands.
  
       When this pattern does match, the two operands of the commutative
       operator are recorded as operands 1 and 2 of the insn.  (This is
!      done by the two instances of 'match_operand'.)  Operand 3 of the
!      insn will be the entire commutative expression: use 'GET_CODE
!      (operands[3])' to see which commutative operator was used.
  
!      The machine mode M of 'match_operator' works like that of
!      'match_operand': it is passed as the second argument to the
       predicate function, and that function is solely responsible for
       deciding whether the expression to be matched "has" that mode.
  
--- 22407,22423 ----
              [(match_operand:SI 1 "general_operand" "g")
               (match_operand:SI 2 "general_operand" "g")])
  
!      Here the vector ‘[OPERANDS...]’ contains two patterns because the
       expressions to be matched all contain two operands.
  
       When this pattern does match, the two operands of the commutative
       operator are recorded as operands 1 and 2 of the insn.  (This is
!      done by the two instances of ‘match_operand’.)  Operand 3 of the
!      insn will be the entire commutative expression: use ‘GET_CODE
!      (operands[3])’ to see which commutative operator was used.
  
!      The machine mode M of ‘match_operator’ works like that of
!      ‘match_operand’: it is passed as the second argument to the
       predicate function, and that function is solely responsible for
       deciding whether the expression to be matched "has" that mode.
  
*************** substitution of the operands.
*** 22429,22473 ****
       2 of the gen-function.  The subexpressions of argument 3 are not
       used; only its expression code matters.
  
!      When 'match_operator' is used in a pattern for matching an insn, it
!      usually best if the operand number of the 'match_operator' is
       higher than that of the actual operands of the insn.  This improves
       register allocation because the register allocator often looks at
       operands 1 and 2 of insns to see if it can do register tying.
  
!      There is no way to specify constraints in 'match_operator'.  The
!      operand of the insn which corresponds to the 'match_operator' never
       has any constraints because it is never reloaded as a whole.
!      However, if parts of its OPERANDS are matched by 'match_operand'
       patterns, those parts may have constraints of their own.
  
! '(match_op_dup:M N[OPERANDS...])'
!      Like 'match_dup', except that it applies to operators instead of
       operands.  When constructing an insn, operand number N will be
!      substituted at this point.  But in matching, 'match_op_dup' behaves
       differently.  It assumes that operand number N has already been
!      determined by a 'match_operator' appearing earlier in the
       recognition template, and it matches only an identical-looking
       expression.
  
! '(match_parallel N PREDICATE [SUBPAT...])'
       This pattern is a placeholder for an insn that consists of a
!      'parallel' expression with a variable number of elements.  This
       expression should only appear at the top level of an insn pattern.
  
       When constructing an insn, operand number N will be substituted at
       this point.  When matching an insn, it matches if the body of the
!      insn is a 'parallel' expression with at least as many elements as
!      the vector of SUBPAT expressions in the 'match_parallel', if each
!      SUBPAT matches the corresponding element of the 'parallel', _and_
!      the function PREDICATE returns nonzero on the 'parallel' that is
       the body of the insn.  It is the responsibility of the predicate to
!      validate elements of the 'parallel' beyond those listed in the
!      'match_parallel'.
  
!      A typical use of 'match_parallel' is to match load and store
       multiple expressions, which can contain a variable number of
!      elements in a 'parallel'.  For example,
  
            (define_insn ""
              [(match_parallel 0 "load_multiple_operation"
--- 22428,22472 ----
       2 of the gen-function.  The subexpressions of argument 3 are not
       used; only its expression code matters.
  
!      When ‘match_operator’ is used in a pattern for matching an insn, it
!      usually best if the operand number of the ‘match_operator’ is
       higher than that of the actual operands of the insn.  This improves
       register allocation because the register allocator often looks at
       operands 1 and 2 of insns to see if it can do register tying.
  
!      There is no way to specify constraints in ‘match_operator’.  The
!      operand of the insn which corresponds to the ‘match_operator’ never
       has any constraints because it is never reloaded as a whole.
!      However, if parts of its OPERANDS are matched by ‘match_operand’
       patterns, those parts may have constraints of their own.
  
! ‘(match_op_dup:M N[OPERANDS...])’
!      Like ‘match_dup’, except that it applies to operators instead of
       operands.  When constructing an insn, operand number N will be
!      substituted at this point.  But in matching, ‘match_op_dup’ behaves
       differently.  It assumes that operand number N has already been
!      determined by a ‘match_operator’ appearing earlier in the
       recognition template, and it matches only an identical-looking
       expression.
  
! ‘(match_parallel N PREDICATE [SUBPAT...])’
       This pattern is a placeholder for an insn that consists of a
!      ‘parallel’ expression with a variable number of elements.  This
       expression should only appear at the top level of an insn pattern.
  
       When constructing an insn, operand number N will be substituted at
       this point.  When matching an insn, it matches if the body of the
!      insn is a ‘parallel’ expression with at least as many elements as
!      the vector of SUBPAT expressions in the ‘match_parallel’, if each
!      SUBPAT matches the corresponding element of the ‘parallel’, _and_
!      the function PREDICATE returns nonzero on the ‘parallel’ that is
       the body of the insn.  It is the responsibility of the predicate to
!      validate elements of the ‘parallel’ beyond those listed in the
!      ‘match_parallel’.
  
!      A typical use of ‘match_parallel’ is to match load and store
       multiple expressions, which can contain a variable number of
!      elements in a ‘parallel’.  For example,
  
            (define_insn ""
              [(match_parallel 0 "load_multiple_operation"
*************** substitution of the operands.
*** 22478,22486 ****
              ""
              "loadm 0,0,%1,%2")
  
!      This example comes from 'a29k.md'.  The function
!      'load_multiple_operation' is defined in 'a29k.c' and checks that
!      subsequent elements in the 'parallel' are the same as the 'set' in
       the pattern, except that they are referencing subsequent registers
       and memory locations.
  
--- 22477,22485 ----
              ""
              "loadm 0,0,%1,%2")
  
!      This example comes from ‘a29k.md’.  The function
!      ‘load_multiple_operation’ is defined in ‘a29k.c’ and checks that
!      subsequent elements in the ‘parallel’ are the same as the ‘set’ in
       the pattern, except that they are referencing subsequent registers
       and memory locations.
  
*************** substitution of the operands.
*** 22497,22505 ****
                   (mem:SI (plus:SI (reg:SI 100)
                                    (const_int 8))))])
  
! '(match_par_dup N [SUBPAT...])'
!      Like 'match_op_dup', but for 'match_parallel' instead of
!      'match_operator'.
  
  
  File: gccint.info,  Node: Output Template,  Next: Output Statement,  Prev: RTL Template,  Up: Machine Desc
--- 22496,22504 ----
                   (mem:SI (plus:SI (reg:SI 100)
                                    (const_int 8))))])
  
! ‘(match_par_dup N [SUBPAT...])’
!      Like ‘match_op_dup’, but for ‘match_parallel’ instead of
!      ‘match_operator’.
  
  
  File: gccint.info,  Node: Output Template,  Next: Output Statement,  Prev: RTL Template,  Up: Machine Desc
*************** File: gccint.info,  Node: Output Templat
*** 22507,22554 ****
  17.5 Output Templates and Operand Substitution
  ==============================================
  
! The "output template" is a string which specifies how to output the
  assembler code for an instruction pattern.  Most of the template is a
! fixed string which is output literally.  The character '%' is used to
  specify where to substitute an operand; it can also be used to identify
  places where different variants of the assembler require different
  syntax.
  
!  In the simplest case, a '%' followed by a digit N says to output
  operand N at that point in the string.
  
!  '%' followed by a letter and a digit says to output an operand in an
  alternate fashion.  Four letters have standard, built-in meanings
! described below.  The machine description macro 'PRINT_OPERAND' can
  define additional letters with nonstandard meanings.
  
!  '%cDIGIT' can be used to substitute an operand that is a constant value
  without the syntax that normally indicates an immediate operand.
  
!  '%nDIGIT' is like '%cDIGIT' except that the value of the constant is
  negated before printing.
  
!  '%aDIGIT' can be used to substitute an operand as if it were a memory
  reference, with the actual operand treated as the address.  This may be
  useful when outputting a "load address" instruction, because often the
  assembler syntax for such an instruction requires you to write the
  operand as if it were a memory reference.
  
!  '%lDIGIT' is used to substitute a 'label_ref' into a jump instruction.
  
!  '%=' outputs a number which is unique to each instruction in the entire
  compilation.  This is useful for making local labels to be referred to
  more than once in a single template that generates multiple assembler
  instructions.
  
!  '%' followed by a punctuation character specifies a substitution that
! does not use an operand.  Only one case is standard: '%%' outputs a '%'
  into the assembler code.  Other nonstandard cases can be defined in the
! 'PRINT_OPERAND' macro.  You must also define which punctuation
! characters are valid with the 'PRINT_OPERAND_PUNCT_VALID_P' macro.
  
   The template may generate multiple assembler instructions.  Write the
! text for the instructions, with '\;' between them.
  
   When the RTL contains two operands which are required by constraint to
  match each other, the output template must refer only to the
--- 22506,22553 ----
  17.5 Output Templates and Operand Substitution
  ==============================================
  
! The “output template” is a string which specifies how to output the
  assembler code for an instruction pattern.  Most of the template is a
! fixed string which is output literally.  The character ‘%’ is used to
  specify where to substitute an operand; it can also be used to identify
  places where different variants of the assembler require different
  syntax.
  
!  In the simplest case, a ‘%’ followed by a digit N says to output
  operand N at that point in the string.
  
!  ‘%’ followed by a letter and a digit says to output an operand in an
  alternate fashion.  Four letters have standard, built-in meanings
! described below.  The machine description macro ‘PRINT_OPERAND’ can
  define additional letters with nonstandard meanings.
  
!  ‘%cDIGIT’ can be used to substitute an operand that is a constant value
  without the syntax that normally indicates an immediate operand.
  
!  ‘%nDIGIT’ is like ‘%cDIGIT’ except that the value of the constant is
  negated before printing.
  
!  ‘%aDIGIT’ can be used to substitute an operand as if it were a memory
  reference, with the actual operand treated as the address.  This may be
  useful when outputting a "load address" instruction, because often the
  assembler syntax for such an instruction requires you to write the
  operand as if it were a memory reference.
  
!  ‘%lDIGIT’ is used to substitute a ‘label_ref’ into a jump instruction.
  
!  ‘%=’ outputs a number which is unique to each instruction in the entire
  compilation.  This is useful for making local labels to be referred to
  more than once in a single template that generates multiple assembler
  instructions.
  
!  ‘%’ followed by a punctuation character specifies a substitution that
! does not use an operand.  Only one case is standard: ‘%%’ outputs a ‘%’
  into the assembler code.  Other nonstandard cases can be defined in the
! ‘PRINT_OPERAND’ macro.  You must also define which punctuation
! characters are valid with the ‘PRINT_OPERAND_PUNCT_VALID_P’ macro.
  
   The template may generate multiple assembler instructions.  Write the
! text for the instructions, with ‘\;’ between them.
  
   When the RTL contains two operands which are required by constraint to
  match each other, the output template must refer only to the
*************** lower-numbered operand.  Matching operan
*** 22556,22588 ****
  the rest of the compiler arranges to put the proper RTL expression for
  printing into the lower-numbered operand.
  
!  One use of nonstandard letters or punctuation following '%' is to
  distinguish between different assembler languages for the same machine;
  for example, Motorola syntax versus MIT syntax for the 68000.  Motorola
  syntax requires periods in most opcode names, while MIT syntax does not.
! For example, the opcode 'movel' in MIT syntax is 'move.l' in Motorola
  syntax.  The same file of patterns is used for both kinds of output
! syntax, but the character sequence '%.' is used in each place where
! Motorola syntax wants a period.  The 'PRINT_OPERAND' macro for Motorola
  syntax defines the sequence to output a period; the macro for MIT syntax
  defines it to do nothing.
  
!  As a special case, a template consisting of the single character '#'
  instructs the compiler to first split the insn, and then output the
  resulting instructions separately.  This helps eliminate redundancy in
! the output templates.  If you have a 'define_insn' that needs to emit
! multiple assembler instructions, and there is a matching 'define_split'
! already defined, then you can simply use '#' as the output template
  instead of writing an output template that emits the multiple assembler
  instructions.
  
!  Note that '#' only has an effect while generating assembly code; it
  does not affect whether a split occurs earlier.  An associated
! 'define_split' must exist and it must be suitable for use after register
  allocation.
  
!  If the macro 'ASSEMBLER_DIALECT' is defined, you can use construct of
! the form '{option0|option1|option2}' in the templates.  These describe
  multiple variants of assembler language syntax.  *Note Instruction
  Output::.
  
--- 22555,22587 ----
  the rest of the compiler arranges to put the proper RTL expression for
  printing into the lower-numbered operand.
  
!  One use of nonstandard letters or punctuation following ‘%’ is to
  distinguish between different assembler languages for the same machine;
  for example, Motorola syntax versus MIT syntax for the 68000.  Motorola
  syntax requires periods in most opcode names, while MIT syntax does not.
! For example, the opcode ‘movel’ in MIT syntax is ‘move.l’ in Motorola
  syntax.  The same file of patterns is used for both kinds of output
! syntax, but the character sequence ‘%.’ is used in each place where
! Motorola syntax wants a period.  The ‘PRINT_OPERAND’ macro for Motorola
  syntax defines the sequence to output a period; the macro for MIT syntax
  defines it to do nothing.
  
!  As a special case, a template consisting of the single character ‘#’
  instructs the compiler to first split the insn, and then output the
  resulting instructions separately.  This helps eliminate redundancy in
! the output templates.  If you have a ‘define_insn’ that needs to emit
! multiple assembler instructions, and there is a matching ‘define_split’
! already defined, then you can simply use ‘#’ as the output template
  instead of writing an output template that emits the multiple assembler
  instructions.
  
!  Note that ‘#’ only has an effect while generating assembly code; it
  does not affect whether a split occurs earlier.  An associated
! ‘define_split’ must exist and it must be suitable for use after register
  allocation.
  
!  If the macro ‘ASSEMBLER_DIALECT’ is defined, you can use construct of
! the form ‘{option0|option1|option2}’ in the templates.  These describe
  multiple variants of assembler language syntax.  *Note Instruction
  Output::.
  
*************** single instruction pattern.  For example
*** 22598,22609 ****
  kinds of operands; or some unfortunate combinations of operands may
  require extra machine instructions.
  
!  If the output control string starts with a '@', then it is actually a
  series of templates, each on a separate line.  (Blank lines and leading
  spaces and tabs are ignored.)  The templates correspond to the pattern's
  constraint alternatives (*note Multi-Alternative::).  For example, if a
! target machine has a two-address add instruction 'addr' to add into a
! register and another 'addm' to add a register to memory, you might write
  this pattern:
  
       (define_insn "addsi3"
--- 22597,22608 ----
  kinds of operands; or some unfortunate combinations of operands may
  require extra machine instructions.
  
!  If the output control string starts with a ‘@’, then it is actually a
  series of templates, each on a separate line.  (Blank lines and leading
  spaces and tabs are ignored.)  The templates correspond to the pattern's
  constraint alternatives (*note Multi-Alternative::).  For example, if a
! target machine has a two-address add instruction ‘addr’ to add into a
! register and another ‘addm’ to add a register to memory, you might write
  this pattern:
  
       (define_insn "addsi3"
*************** this pattern:
*** 22615,22659 ****
          addr %2,%0
          addm %2,%0")
  
!  If the output control string starts with a '*', then it is not an
  output template but rather a piece of C program that should compute a
! template.  It should execute a 'return' statement to return the
  template-string you want.  Most such templates use C string literals,
  which require doublequote characters to delimit them.  To include these
! doublequote characters in the string, prefix each one with '\'.
  
   If the output control string is written as a brace block instead of a
  double-quoted string, it is automatically assumed to be C code.  In that
  case, it is not necessary to put in a leading asterisk, or to escape the
  doublequotes surrounding C string literals.
  
!  The operands may be found in the array 'operands', whose C data type is
! 'rtx []'.
  
   It is very common to select different ways of generating assembler code
  based on whether an immediate operand is within a certain range.  Be
! careful when doing this, because the result of 'INTVAL' is an integer on
! the host machine.  If the host machine has more bits in an 'int' than
  the target machine has in the mode in which the constant will be used,
! then some of the bits you get from 'INTVAL' will be superfluous.  For
  proper results, you must carefully disregard the values of those bits.
  
   It is possible to output an assembler instruction and then go on to
! output or compute more of them, using the subroutine 'output_asm_insn'.
  This receives two arguments: a template-string and a vector of operands.
! The vector may be 'operands', or it may be another array of 'rtx' that
  you declare locally and initialize yourself.
  
   When an insn pattern has multiple alternatives in its constraints,
  often the appearance of the assembler code is determined mostly by which
  alternative was matched.  When this is so, the C code can test the
! variable 'which_alternative', which is the ordinal number of the
  alternative that was actually satisfied (0 for the first, 1 for the
  second alternative, etc.).
  
!  For example, suppose there are two opcodes for storing zero, 'clrreg'
! for registers and 'clrmem' for memory locations.  Here is how a pattern
! could use 'which_alternative' to choose between them:
  
       (define_insn ""
         [(set (match_operand:SI 0 "general_operand" "=r,m")
--- 22614,22658 ----
          addr %2,%0
          addm %2,%0")
  
!  If the output control string starts with a ‘*’, then it is not an
  output template but rather a piece of C program that should compute a
! template.  It should execute a ‘return’ statement to return the
  template-string you want.  Most such templates use C string literals,
  which require doublequote characters to delimit them.  To include these
! doublequote characters in the string, prefix each one with ‘\’.
  
   If the output control string is written as a brace block instead of a
  double-quoted string, it is automatically assumed to be C code.  In that
  case, it is not necessary to put in a leading asterisk, or to escape the
  doublequotes surrounding C string literals.
  
!  The operands may be found in the array ‘operands’, whose C data type is
! ‘rtx []’.
  
   It is very common to select different ways of generating assembler code
  based on whether an immediate operand is within a certain range.  Be
! careful when doing this, because the result of ‘INTVAL’ is an integer on
! the host machine.  If the host machine has more bits in an ‘int’ than
  the target machine has in the mode in which the constant will be used,
! then some of the bits you get from ‘INTVAL’ will be superfluous.  For
  proper results, you must carefully disregard the values of those bits.
  
   It is possible to output an assembler instruction and then go on to
! output or compute more of them, using the subroutine ‘output_asm_insn’.
  This receives two arguments: a template-string and a vector of operands.
! The vector may be ‘operands’, or it may be another array of ‘rtx’ that
  you declare locally and initialize yourself.
  
   When an insn pattern has multiple alternatives in its constraints,
  often the appearance of the assembler code is determined mostly by which
  alternative was matched.  When this is so, the C code can test the
! variable ‘which_alternative’, which is the ordinal number of the
  alternative that was actually satisfied (0 for the first, 1 for the
  second alternative, etc.).
  
!  For example, suppose there are two opcodes for storing zero, ‘clrreg’
! for registers and ‘clrmem’ for memory locations.  Here is how a pattern
! could use ‘which_alternative’ to choose between them:
  
       (define_insn ""
         [(set (match_operand:SI 0 "general_operand" "=r,m")
*************** could use 'which_alternative' to choose
*** 22666,22672 ****
  
   The example above, where the assembler code to generate was _solely_
  determined by the alternative, could also have been specified as
! follows, having the output control string start with a '@':
  
       (define_insn ""
         [(set (match_operand:SI 0 "general_operand" "=r,m")
--- 22665,22671 ----
  
   The example above, where the assembler code to generate was _solely_
  determined by the alternative, could also have been specified as
! follows, having the output control string start with a ‘@’:
  
       (define_insn ""
         [(set (match_operand:SI 0 "general_operand" "=r,m")
*************** follows, having the output control strin
*** 22677,22683 ****
          clrmem %0")
  
   If you just need a little bit of C code in one (or a few) alternatives,
! you can use '*' inside of a '@' multi-alternative template:
  
       (define_insn ""
         [(set (match_operand:SI 0 "general_operand" "=r,<,m")
--- 22676,22682 ----
          clrmem %0")
  
   If you just need a little bit of C code in one (or a few) alternatives,
! you can use ‘*’ inside of a ‘@’ multi-alternative template:
  
       (define_insn ""
         [(set (match_operand:SI 0 "general_operand" "=r,<,m")
*************** File: gccint.info,  Node: Predicates,  N
*** 22694,22711 ****
  17.7 Predicates
  ===============
  
! A predicate determines whether a 'match_operand' or 'match_operator'
  expression matches, and therefore whether the surrounding instruction
  pattern will be used for that combination of operands.  GCC has a number
  of machine-independent predicates, and you can define machine-specific
  predicates as needed.  By convention, predicates used with
! 'match_operand' have names that end in '_operand', and those used with
! 'match_operator' have names that end in '_operator'.
  
   All predicates are boolean functions (in the mathematical sense) of two
  arguments: the RTL expression that is being considered at that position
  in the instruction pattern, and the machine mode that the
! 'match_operand' or 'match_operator' specifies.  In this section, the
  first argument is called OP and the second argument MODE.  Predicates
  can be called from C as ordinary two-argument functions; this can be
  useful in output templates or other machine-specific code.
--- 22693,22710 ----
  17.7 Predicates
  ===============
  
! A predicate determines whether a ‘match_operand’ or ‘match_operator’
  expression matches, and therefore whether the surrounding instruction
  pattern will be used for that combination of operands.  GCC has a number
  of machine-independent predicates, and you can define machine-specific
  predicates as needed.  By convention, predicates used with
! ‘match_operand’ have names that end in ‘_operand’, and those used with
! ‘match_operator’ have names that end in ‘_operator’.
  
   All predicates are boolean functions (in the mathematical sense) of two
  arguments: the RTL expression that is being considered at that position
  in the instruction pattern, and the machine mode that the
! ‘match_operand’ or ‘match_operator’ specifies.  In this section, the
  first argument is called OP and the second argument MODE.  Predicates
  can be called from C as ordinary two-argument functions; this can be
  useful in output templates or other machine-specific code.
*************** allows only constants, or else enforce t
*** 22720,22742 ****
  condition.
  
   Most predicates handle their MODE argument in a uniform manner.  If
! MODE is 'VOIDmode' (unspecified), then OP can have any mode.  If MODE is
  anything else, then OP must have the same mode, unless OP is a
! 'CONST_INT' or integer 'CONST_DOUBLE'.  These RTL expressions always
! have 'VOIDmode', so it would be counterproductive to check that their
! mode matches.  Instead, predicates that accept 'CONST_INT' and/or
! integer 'CONST_DOUBLE' check that the value stored in the constant will
  fit in the requested mode.
  
!  Predicates with this behavior are called "normal".  'genrecog' can
  optimize the instruction recognizer based on knowledge of how normal
  predicates treat modes.  It can also diagnose certain kinds of common
  errors in the use of normal predicates; for instance, it is almost
  always an error to use a normal predicate without specifying a mode.
  
   Predicates that do something different with their MODE argument are
! called "special".  The generic predicates 'address_operand' and
! 'pmode_register_operand' are special predicates.  'genrecog' does not do
  any optimizations or diagnosis when special predicates are used.
  
  * Menu:
--- 22719,22741 ----
  condition.
  
   Most predicates handle their MODE argument in a uniform manner.  If
! MODE is ‘VOIDmode’ (unspecified), then OP can have any mode.  If MODE is
  anything else, then OP must have the same mode, unless OP is a
! ‘CONST_INT’ or integer ‘CONST_DOUBLE’.  These RTL expressions always
! have ‘VOIDmode’, so it would be counterproductive to check that their
! mode matches.  Instead, predicates that accept ‘CONST_INT’ and/or
! integer ‘CONST_DOUBLE’ check that the value stored in the constant will
  fit in the requested mode.
  
!  Predicates with this behavior are called “normal”.  ‘genrecog’ can
  optimize the instruction recognizer based on knowledge of how normal
  predicates treat modes.  It can also diagnose certain kinds of common
  errors in the use of normal predicates; for instance, it is almost
  always an error to use a normal predicate without specifying a mode.
  
   Predicates that do something different with their MODE argument are
! called “special”.  The generic predicates ‘address_operand’ and
! ‘pmode_register_operand’ are special predicates.  ‘genrecog’ does not do
  any optimizations or diagnosis when special predicates are used.
  
  * Menu:
*************** File: gccint.info,  Node: Machine-Indepe
*** 22752,22759 ****
  -------------------------------------
  
  These are the generic predicates available to all back ends.  They are
! defined in 'recog.cc'.  The first category of predicates allow only
! constant, or "immediate", operands.
  
   -- Function: immediate_operand
       This predicate allows any sort of constant that fits in MODE.  It
--- 22751,22758 ----
  -------------------------------------
  
  These are the generic predicates available to all back ends.  They are
! defined in ‘recog.cc’.  The first category of predicates allow only
! constant, or “immediate”, operands.
  
   -- Function: immediate_operand
       This predicate allows any sort of constant that fits in MODE.  It
*************** constant, or "immediate", operands.
*** 22761,22786 ****
       must be constant.
  
   -- Function: const_int_operand
!      This predicate allows any 'CONST_INT' expression that fits in MODE.
       It is an appropriate choice for an immediate operand that does not
       allow a symbol or label.
  
   -- Function: const_double_operand
!      This predicate accepts any 'CONST_DOUBLE' expression that has
!      exactly MODE.  If MODE is 'VOIDmode', it will also accept
!      'CONST_INT'.  It is intended for immediate floating point
       constants.
  
  The second category of predicates allow only some kind of machine
  register.
  
   -- Function: register_operand
!      This predicate allows any 'REG' or 'SUBREG' expression that is
       valid for MODE.  It is often suitable for arithmetic instruction
       operands on a RISC machine.
  
   -- Function: pmode_register_operand
!      This is a slight variant on 'register_operand' which works around a
       limitation in the machine-description reader.
  
            (match_operand N "pmode_register_operand" CONSTRAINT)
--- 22760,22785 ----
       must be constant.
  
   -- Function: const_int_operand
!      This predicate allows any ‘CONST_INT’ expression that fits in MODE.
       It is an appropriate choice for an immediate operand that does not
       allow a symbol or label.
  
   -- Function: const_double_operand
!      This predicate accepts any ‘CONST_DOUBLE’ expression that has
!      exactly MODE.  If MODE is ‘VOIDmode’, it will also accept
!      ‘CONST_INT’.  It is intended for immediate floating point
       constants.
  
  The second category of predicates allow only some kind of machine
  register.
  
   -- Function: register_operand
!      This predicate allows any ‘REG’ or ‘SUBREG’ expression that is
       valid for MODE.  It is often suitable for arithmetic instruction
       operands on a RISC machine.
  
   -- Function: pmode_register_operand
!      This is a slight variant on ‘register_operand’ which works around a
       limitation in the machine-description reader.
  
            (match_operand N "pmode_register_operand" CONSTRAINT)
*************** register.
*** 22789,22802 ****
  
            (match_operand:P N "register_operand" CONSTRAINT)
  
!      would mean, if the machine-description reader accepted ':P' mode
!      suffixes.  Unfortunately, it cannot, because 'Pmode' is an alias
       for some other mode, and might vary with machine-specific options.
       *Note Misc::.
  
   -- Function: scratch_operand
!      This predicate allows hard registers and 'SCRATCH' expressions, but
!      not pseudo-registers.  It is used internally by 'match_scratch'; it
       should not be used directly.
  
  The third category of predicates allow only some kind of memory
--- 22788,22801 ----
  
            (match_operand:P N "register_operand" CONSTRAINT)
  
!      would mean, if the machine-description reader accepted ‘:P’ mode
!      suffixes.  Unfortunately, it cannot, because ‘Pmode’ is an alias
       for some other mode, and might vary with machine-specific options.
       *Note Misc::.
  
   -- Function: scratch_operand
!      This predicate allows hard registers and ‘SCRATCH’ expressions, but
!      not pseudo-registers.  It is used internally by ‘match_scratch’; it
       should not be used directly.
  
  The third category of predicates allow only some kind of memory
*************** reference.
*** 22805,22842 ****
   -- Function: memory_operand
       This predicate allows any valid reference to a quantity of mode
       MODE in memory, as determined by the weak form of
!      'GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::).
  
   -- Function: address_operand
       This predicate is a little unusual; it allows any operand that is a
       valid expression for the _address_ of a quantity of mode MODE,
!      again determined by the weak form of 'GO_IF_LEGITIMATE_ADDRESS'.
!      To first order, if '(mem:MODE (EXP))' is acceptable to
!      'memory_operand', then EXP is acceptable to 'address_operand'.
       Note that EXP does not necessarily have the mode MODE.
  
   -- Function: indirect_operand
!      This is a stricter form of 'memory_operand' which allows only
!      memory references with a 'general_operand' as the address
       expression.  New uses of this predicate are discouraged, because
!      'general_operand' is very permissive, so it's hard to tell what an
!      'indirect_operand' does or does not allow.  If a target has
       different requirements for memory operands for different
       instructions, it is better to define target-specific predicates
       which enforce the hardware's requirements explicitly.
  
   -- Function: push_operand
       This predicate allows a memory reference suitable for pushing a
!      value onto the stack.  This will be a 'MEM' which refers to
!      'stack_pointer_rtx', with a side effect in its address expression
!      (*note Incdec::); which one is determined by the 'STACK_PUSH_CODE'
       macro (*note Frame Layout::).
  
   -- Function: pop_operand
       This predicate allows a memory reference suitable for popping a
!      value off the stack.  Again, this will be a 'MEM' referring to
!      'stack_pointer_rtx', with a side effect in its address expression.
!      However, this time 'STACK_POP_CODE' is expected.
  
  The fourth category of predicates allow some combination of the above
  operands.
--- 22804,22841 ----
   -- Function: memory_operand
       This predicate allows any valid reference to a quantity of mode
       MODE in memory, as determined by the weak form of
!      ‘GO_IF_LEGITIMATE_ADDRESS’ (*note Addressing Modes::).
  
   -- Function: address_operand
       This predicate is a little unusual; it allows any operand that is a
       valid expression for the _address_ of a quantity of mode MODE,
!      again determined by the weak form of ‘GO_IF_LEGITIMATE_ADDRESS’.
!      To first order, if ‘(mem:MODE (EXP))’ is acceptable to
!      ‘memory_operand’, then EXP is acceptable to ‘address_operand’.
       Note that EXP does not necessarily have the mode MODE.
  
   -- Function: indirect_operand
!      This is a stricter form of ‘memory_operand’ which allows only
!      memory references with a ‘general_operand’ as the address
       expression.  New uses of this predicate are discouraged, because
!      ‘general_operand’ is very permissive, so it's hard to tell what an
!      ‘indirect_operand’ does or does not allow.  If a target has
       different requirements for memory operands for different
       instructions, it is better to define target-specific predicates
       which enforce the hardware's requirements explicitly.
  
   -- Function: push_operand
       This predicate allows a memory reference suitable for pushing a
!      value onto the stack.  This will be a ‘MEM’ which refers to
!      ‘stack_pointer_rtx’, with a side effect in its address expression
!      (*note Incdec::); which one is determined by the ‘STACK_PUSH_CODE’
       macro (*note Frame Layout::).
  
   -- Function: pop_operand
       This predicate allows a memory reference suitable for popping a
!      value off the stack.  Again, this will be a ‘MEM’ referring to
!      ‘stack_pointer_rtx’, with a side effect in its address expression.
!      However, this time ‘STACK_POP_CODE’ is expected.
  
  The fourth category of predicates allow some combination of the above
  operands.
*************** Finally, there are two generic operator
*** 22857,22870 ****
  
   -- Function: comparison_operator
       This predicate matches any expression which performs an arithmetic
!      comparison in MODE; that is, 'COMPARISON_P' is true for the
       expression code.
  
   -- Function: ordered_comparison_operator
       This predicate matches any expression which performs an arithmetic
       comparison in MODE and whose expression code is valid for integer
!      modes; that is, the expression code will be one of 'eq', 'ne',
!      'lt', 'ltu', 'le', 'leu', 'gt', 'gtu', 'ge', 'geu'.
  
  
  File: gccint.info,  Node: Defining Predicates,  Prev: Machine-Independent Predicates,  Up: Predicates
--- 22856,22869 ----
  
   -- Function: comparison_operator
       This predicate matches any expression which performs an arithmetic
!      comparison in MODE; that is, ‘COMPARISON_P’ is true for the
       expression code.
  
   -- Function: ordered_comparison_operator
       This predicate matches any expression which performs an arithmetic
       comparison in MODE and whose expression code is valid for integer
!      modes; that is, the expression code will be one of ‘eq’, ‘ne’,
!      ‘lt’, ‘ltu’, ‘le’, ‘leu’, ‘gt’, ‘gtu’, ‘ge’, ‘geu’.
  
  
  File: gccint.info,  Node: Defining Predicates,  Prev: Machine-Independent Predicates,  Up: Predicates
*************** File: gccint.info,  Node: Defining Predi
*** 22874,22904 ****
  
  Many machines have requirements for their operands that cannot be
  expressed precisely using the generic predicates.  You can define
! additional predicates using 'define_predicate' and
! 'define_special_predicate' expressions.  These expressions have three
  operands:
  
!    * The name of the predicate, as it will be referred to in
!      'match_operand' or 'match_operator' expressions.
  
!    * An RTL expression which evaluates to true if the predicate allows
       the operand OP, false if it does not.  This expression can only use
       the following RTL codes:
  
!      'MATCH_OPERAND'
!           When written inside a predicate expression, a 'MATCH_OPERAND'
            expression evaluates to true if the predicate it names would
            allow OP.  The operand number and constraint are ignored.  Due
!           to limitations in 'genrecog', you can only refer to generic
            predicates and predicates that have already been defined.
  
!      'MATCH_CODE'
            This expression evaluates to true if OP or a specified
            subexpression of OP has one of a given list of RTX codes.
  
            The first operand of this expression is a string constant
            containing a comma-separated list of RTX code names (in lower
!           case).  These are the codes for which the 'MATCH_CODE' will be
            true.
  
            The second operand is a string constant which indicates what
--- 22873,22903 ----
  
  Many machines have requirements for their operands that cannot be
  expressed precisely using the generic predicates.  You can define
! additional predicates using ‘define_predicate’ and
! ‘define_special_predicate’ expressions.  These expressions have three
  operands:
  
!    • The name of the predicate, as it will be referred to in
!      ‘match_operand’ or ‘match_operator’ expressions.
  
!    • An RTL expression which evaluates to true if the predicate allows
       the operand OP, false if it does not.  This expression can only use
       the following RTL codes:
  
!      ‘MATCH_OPERAND’
!           When written inside a predicate expression, a ‘MATCH_OPERAND’
            expression evaluates to true if the predicate it names would
            allow OP.  The operand number and constraint are ignored.  Due
!           to limitations in ‘genrecog’, you can only refer to generic
            predicates and predicates that have already been defined.
  
!      ‘MATCH_CODE’
            This expression evaluates to true if OP or a specified
            subexpression of OP has one of a given list of RTX codes.
  
            The first operand of this expression is a string constant
            containing a comma-separated list of RTX code names (in lower
!           case).  These are the codes for which the ‘MATCH_CODE’ will be
            true.
  
            The second operand is a string constant which indicates what
*************** operands:
*** 22908,22960 ****
            character indicates a subexpression to extract from the
            current expression; for the first character this is OP, for
            the second and subsequent characters it is the result of the
!           previous character.  A digit N extracts 'XEXP (E, N)'; a
!           letter L extracts 'XVECEXP (E, 0, N)' where N is the
            alphabetic ordinal of L (0 for 'a', 1 for 'b', and so on).
!           The 'MATCH_CODE' then examines the RTX code of the
            subexpression extracted by the complete string.  It is not
!           possible to extract components of an 'rtvec' that is not at
            position 0 within its RTX object.
  
!      'MATCH_TEST'
            This expression has one operand, a string constant containing
            a C expression.  The predicate's arguments, OP and MODE, are
            available with those names in the C expression.  The
!           'MATCH_TEST' evaluates to true if the C expression evaluates
!           to a nonzero value.  'MATCH_TEST' expressions must not have
            side effects.
  
!      'AND'
!      'IOR'
!      'NOT'
!      'IF_THEN_ELSE'
!           The basic 'MATCH_' expressions can be combined using these
            logical operators, which have the semantics of the C operators
!           '&&', '||', '!', and '? :' respectively.  As in Common Lisp,
!           you may give an 'AND' or 'IOR' expression an arbitrary number
            of arguments; this has exactly the same effect as writing a
!           chain of two-argument 'AND' or 'IOR' expressions.
  
!    * An optional block of C code, which should execute 'return true' if
!      the predicate is found to match and 'return false' if it does not.
       It must not have any side effects.  The predicate arguments, OP and
       MODE, are available with those names.
  
       If a code block is present in a predicate definition, then the RTL
       expression must evaluate to true _and_ the code block must execute
!      'return true' for the predicate to allow the operand.  The RTL
       expression is evaluated first; do not re-check anything in the code
       block that was checked in the RTL expression.
  
!  The program 'genrecog' scans 'define_predicate' and
! 'define_special_predicate' expressions to determine which RTX codes are
  possibly allowed.  You should always make this explicit in the RTL
! predicate expression, using 'MATCH_OPERAND' and 'MATCH_CODE'.
  
   Here is an example of a simple predicate definition, from the IA64
  machine description:
  
!      ;; True if OP is a 'SYMBOL_REF' which refers to the sdata section.
       (define_predicate "small_addr_symbolic_operand"
         (and (match_code "symbol_ref")
              (match_test "SYMBOL_REF_SMALL_ADDR_P (op)")))
--- 22907,22959 ----
            character indicates a subexpression to extract from the
            current expression; for the first character this is OP, for
            the second and subsequent characters it is the result of the
!           previous character.  A digit N extracts ‘XEXP (E, N)’; a
!           letter L extracts ‘XVECEXP (E, 0, N)’ where N is the
            alphabetic ordinal of L (0 for 'a', 1 for 'b', and so on).
!           The ‘MATCH_CODE’ then examines the RTX code of the
            subexpression extracted by the complete string.  It is not
!           possible to extract components of an ‘rtvec’ that is not at
            position 0 within its RTX object.
  
!      ‘MATCH_TEST’
            This expression has one operand, a string constant containing
            a C expression.  The predicate's arguments, OP and MODE, are
            available with those names in the C expression.  The
!           ‘MATCH_TEST’ evaluates to true if the C expression evaluates
!           to a nonzero value.  ‘MATCH_TEST’ expressions must not have
            side effects.
  
!      ‘AND’
!      ‘IOR’
!      ‘NOT’
!      ‘IF_THEN_ELSE’
!           The basic ‘MATCH_’ expressions can be combined using these
            logical operators, which have the semantics of the C operators
!           ‘&&’, ‘||’, ‘!’, and ‘? :’ respectively.  As in Common Lisp,
!           you may give an ‘AND’ or ‘IOR’ expression an arbitrary number
            of arguments; this has exactly the same effect as writing a
!           chain of two-argument ‘AND’ or ‘IOR’ expressions.
  
!    • An optional block of C code, which should execute ‘return true’ if
!      the predicate is found to match and ‘return false’ if it does not.
       It must not have any side effects.  The predicate arguments, OP and
       MODE, are available with those names.
  
       If a code block is present in a predicate definition, then the RTL
       expression must evaluate to true _and_ the code block must execute
!      ‘return true’ for the predicate to allow the operand.  The RTL
       expression is evaluated first; do not re-check anything in the code
       block that was checked in the RTL expression.
  
!  The program ‘genrecog’ scans ‘define_predicate’ and
! ‘define_special_predicate’ expressions to determine which RTX codes are
  possibly allowed.  You should always make this explicit in the RTL
! predicate expression, using ‘MATCH_OPERAND’ and ‘MATCH_CODE’.
  
   Here is an example of a simple predicate definition, from the IA64
  machine description:
  
!      ;; True if OP is a ‘SYMBOL_REF’ which refers to the sdata section.
       (define_predicate "small_addr_symbolic_operand"
         (and (match_code "symbol_ref")
              (match_test "SYMBOL_REF_SMALL_ADDR_P (op)")))
*************** And here is another, showing the use of
*** 22973,22997 ****
         return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno));
       })
  
!  Predicates written with 'define_predicate' automatically include a test
! that MODE is 'VOIDmode', or OP has the same mode as MODE, or OP is a
! 'CONST_INT' or 'CONST_DOUBLE'.  They do _not_ check specifically for
! integer 'CONST_DOUBLE', nor do they test that the value of either kind
  of constant fits in the requested mode.  This is because target-specific
  predicates that take constants usually have to do more stringent value
! checks anyway.  If you need the exact same treatment of 'CONST_INT' or
! 'CONST_DOUBLE' that the generic predicates provide, use a
! 'MATCH_OPERAND' subexpression to call 'const_int_operand',
! 'const_double_operand', or 'immediate_operand'.
  
!  Predicates written with 'define_special_predicate' do not get any
  automatic mode checks, and are treated as having special mode handling
! by 'genrecog'.
  
!  The program 'genpreds' is responsible for generating code to test
  predicates.  It also writes a header file containing function
  declarations for all machine-specific predicates.  It is not necessary
! to declare these predicates in 'CPU-protos.h'.
  
  
  File: gccint.info,  Node: Constraints,  Next: Standard Names,  Prev: Predicates,  Up: Machine Desc
--- 22972,22996 ----
         return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno));
       })
  
!  Predicates written with ‘define_predicate’ automatically include a test
! that MODE is ‘VOIDmode’, or OP has the same mode as MODE, or OP is a
! ‘CONST_INT’ or ‘CONST_DOUBLE’.  They do _not_ check specifically for
! integer ‘CONST_DOUBLE’, nor do they test that the value of either kind
  of constant fits in the requested mode.  This is because target-specific
  predicates that take constants usually have to do more stringent value
! checks anyway.  If you need the exact same treatment of ‘CONST_INT’ or
! ‘CONST_DOUBLE’ that the generic predicates provide, use a
! ‘MATCH_OPERAND’ subexpression to call ‘const_int_operand’,
! ‘const_double_operand’, or ‘immediate_operand’.
  
!  Predicates written with ‘define_special_predicate’ do not get any
  automatic mode checks, and are treated as having special mode handling
! by ‘genrecog’.
  
!  The program ‘genpreds’ is responsible for generating code to test
  predicates.  It also writes a header file containing function
  declarations for all machine-specific predicates.  It is not necessary
! to declare these predicates in ‘CPU-protos.h’.
  
  
  File: gccint.info,  Node: Constraints,  Next: Standard Names,  Prev: Predicates,  Up: Machine Desc
*************** File: gccint.info,  Node: Constraints,
*** 22999,23005 ****
  17.8 Operand Constraints
  ========================
  
! Each 'match_operand' in an instruction pattern can specify constraints
  for the operands allowed.  The constraints allow you to fine-tune
  matching within the set of operands allowed by the predicate.
  
--- 22998,23004 ----
  17.8 Operand Constraints
  ========================
  
! Each ‘match_operand’ in an instruction pattern can specify constraints
  for the operands allowed.  The constraints allow you to fine-tune
  matching within the set of operands allowed by the predicate.
  
*************** kinds of register; whether the operand c
*** 23008,23014 ****
  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.
  
--- 23007,23013 ----
  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.
  
*************** whitespace
*** 23040,23054 ****
       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.
--- 23039,23053 ----
       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.
*************** whitespace
*** 23062,23157 ****
       on the other addressing modes that the machine supports.
  
       Note that in an output operand which can be matched by another
!      operand, the constraint letter 'o' is valid only when accompanied
!      by both '<' (if the target machine has predecrement addressing) and
!      '>' (if the target machine has preincrement addressing).
  
! 'V'
       A memory operand that is not offsettable.  In other words, anything
!      that would fit the 'm' constraint but not the 'o' constraint.
  
! '<'
       A memory operand with autodecrement addressing (either predecrement
!      or postdecrement) is allowed.  In inline 'asm' this constraint is
       only allowed if the operand is used exactly once in an instruction
!      that can handle the side effects.  Not using an operand with '<' in
!      constraint string in the inline 'asm' pattern at all or using it in
       multiple instructions isn't valid, because the side effects
       wouldn't be performed or would be performed more than once.
!      Furthermore, on some targets the operand with '<' in constraint
       string must be accompanied by special instruction suffixes like
!      '%U0' instruction suffix on PowerPC or '%P0' on IA-64.
  
! '>'
       A memory operand with autoincrement addressing (either preincrement
!      or postincrement) is allowed.  In inline 'asm' the same
!      restrictions as for '<' apply.
  
! 'r'
       A register operand is allowed provided that it is in a general
       register.
  
! 'i'
       An immediate integer operand (one with constant value) is allowed.
       This includes symbolic constants whose values will be known only at
       assembly time or later.
  
! 'n'
       An immediate integer operand with a known numeric value is allowed.
       Many systems cannot support assembly-time constants for operands
       less than a word wide.  Constraints for these operands should use
!      'n' rather than 'i'.
  
! 'I', 'J', 'K', ... 'P'
!      Other letters in the range 'I' through 'P' may be defined in a
       machine-dependent fashion to permit immediate integer operands with
       explicit integer values in specified ranges.  For example, on the
!      68000, 'I' is defined to stand for the range of values 1 to 8.
       This is the range permitted as a shift count in the shift
       instructions.
  
! 'E'
!      An immediate floating operand (expression code 'const_double') is
       allowed, but only if the target floating point format is the same
       as that of the host machine (on which the compiler is running).
  
! 'F'
!      An immediate floating operand (expression code 'const_double' or
!      'const_vector') is allowed.
  
! 'G', 'H'
!      'G' and 'H' may be defined in a machine-dependent fashion to permit
       immediate floating operands in particular ranges of values.
  
! 's'
       An immediate integer operand whose value is not an explicit integer
       is allowed.
  
       This might appear strange; if an insn allows a constant operand
       with a value not known at compile time, it certainly must allow any
!      known value.  So why use 's' instead of 'i'?  Sometimes it allows
       better code to be generated.
  
       For example, on the 68000 in a fullword instruction it is possible
       to use an immediate operand; but if the immediate value is between
!      -128 and 127, better code results from loading the value into a
       register and using the register.  This is because the load into the
!      register can be done with a 'moveq' instruction.  We arrange for
!      this to happen by defining the letter 'K' to mean "any integer
!      outside the range -128 to 127", and then specifying 'Ks' in the
       operand constraints.
  
! 'g'
       Any register, memory or immediate integer operand is allowed,
       except for registers that are not general registers.
  
! 'X'
       Any operand whatsoever is allowed, even if it does not satisfy
!      'general_operand'.  This is normally used in the constraint of a
!      'match_scratch' when certain alternatives will not actually require
       a scratch register.
  
! '0', '1', '2', ... '9'
       An operand that matches the specified operand number is allowed.
       If a digit is used together with letters within the same
       alternative, the digit should come last.
--- 23061,23156 ----
       on the other addressing modes that the machine supports.
  
       Note that in an output operand which can be matched by another
!      operand, the constraint letter ‘o’ is valid only when accompanied
!      by both ‘<’ (if the target machine has predecrement addressing) and
!      ‘>’ (if the target machine has preincrement addressing).
  
! ‘V’
       A memory operand that is not offsettable.  In other words, anything
!      that would fit the ‘m’ constraint but not the ‘o’ constraint.
  
! ‘<’
       A memory operand with autodecrement addressing (either predecrement
!      or postdecrement) is allowed.  In inline ‘asm’ this constraint is
       only allowed if the operand is used exactly once in an instruction
!      that can handle the side effects.  Not using an operand with ‘<’ in
!      constraint string in the inline ‘asm’ pattern at all or using it in
       multiple instructions isn't valid, because the side effects
       wouldn't be performed or would be performed more than once.
!      Furthermore, on some targets the operand with ‘<’ in constraint
       string must be accompanied by special instruction suffixes like
!      ‘%U0’ instruction suffix on PowerPC or ‘%P0’ on IA-64.
  
! ‘>’
       A memory operand with autoincrement addressing (either preincrement
!      or postincrement) is allowed.  In inline ‘asm’ the same
!      restrictions as for ‘<’ apply.
  
! ‘r’
       A register operand is allowed provided that it is in a general
       register.
  
! ‘i’
       An immediate integer operand (one with constant value) is allowed.
       This includes symbolic constants whose values will be known only at
       assembly time or later.
  
! ‘n’
       An immediate integer operand with a known numeric value is allowed.
       Many systems cannot support assembly-time constants for operands
       less than a word wide.  Constraints for these operands should use
!      ‘n’ rather than ‘i’.
  
! ‘I’, ‘J’, ‘K’, ... ‘P’
!      Other letters in the range ‘I’ through ‘P’ may be defined in a
       machine-dependent fashion to permit immediate integer operands with
       explicit integer values in specified ranges.  For example, on the
!      68000, ‘I’ is defined to stand for the range of values 1 to 8.
       This is the range permitted as a shift count in the shift
       instructions.
  
! ‘E’
!      An immediate floating operand (expression code ‘const_double’) is
       allowed, but only if the target floating point format is the same
       as that of the host machine (on which the compiler is running).
  
! ‘F’
!      An immediate floating operand (expression code ‘const_double’ or
!      ‘const_vector’) is allowed.
  
! ‘G’, ‘H’
!      ‘G’ and ‘H’ may be defined in a machine-dependent fashion to permit
       immediate floating operands in particular ranges of values.
  
! ‘s’
       An immediate integer operand whose value is not an explicit integer
       is allowed.
  
       This might appear strange; if an insn allows a constant operand
       with a value not known at compile time, it certainly must allow any
!      known value.  So why use ‘s’ instead of ‘i’?  Sometimes it allows
       better code to be generated.
  
       For example, on the 68000 in a fullword instruction it is possible
       to use an immediate operand; but if the immediate value is between
!      −128 and 127, better code results from loading the value into a
       register and using the register.  This is because the load into the
!      register can be done with a ‘moveq’ instruction.  We arrange for
!      this to happen by defining the letter ‘K’ to mean "any integer
!      outside the range −128 to 127", and then specifying ‘Ks’ in the
       operand constraints.
  
! ‘g’
       Any register, memory or immediate integer operand is allowed,
       except for registers that are not general registers.
  
! ‘X’
       Any operand whatsoever is allowed, even if it does not satisfy
!      ‘general_operand’.  This is normally used in the constraint of a
!      ‘match_scratch’ when certain alternatives will not actually require
       a scratch register.
  
! ‘0’, ‘1’, ‘2’, ... ‘9’
       An operand that matches the specified operand number is allowed.
       If a digit is used together with letters within the same
       alternative, the digit should come last.
*************** whitespace
*** 23159,23169 ****
       This number is allowed to be more than a single digit.  If multiple
       digits are encountered consecutively, they are interpreted as a
       single decimal integer.  There is scant chance for ambiguity, since
!      to-date it has never been desirable that '10' be interpreted as
       matching either operand 1 _or_ operand 0.  Should this be desired,
       one can use multiple alternatives instead.
  
!      This is called a "matching constraint" and what it really means is
       that the assembler has only a single operand that fills two roles
       considered separate in the RTL insn.  For example, an add insn has
       two input operands and one output operand in the RTL, but on most
--- 23158,23168 ----
       This number is allowed to be more than a single digit.  If multiple
       digits are encountered consecutively, they are interpreted as a
       single decimal integer.  There is scant chance for ambiguity, since
!      to-date it has never been desirable that ‘10’ be interpreted as
       matching either operand 1 _or_ operand 0.  Should this be desired,
       one can use multiple alternatives instead.
  
!      This is called a “matching constraint” and what it really means is
       that the assembler has only a single operand that fills two roles
       considered separate in the RTL insn.  For example, an add insn has
       two input operands and one output operand in the RTL, but on most
*************** whitespace
*** 23180,23203 ****
  
       For operands to match in a particular case usually means that they
       are identical-looking RTL expressions.  But in a few special cases
!      specific kinds of dissimilarity are allowed.  For example, '*x' as
!      an input operand will match '*x++' as an output operand.  For
       proper results in such cases, the output template should always use
       the output-operand's number when printing the operand.
  
! 'p'
       An operand that is a valid memory address is allowed.  This is for
       "load address" and "push address" instructions.
  
!      'p' in the constraint must be accompanied by 'address_operand' as
!      the predicate in the 'match_operand'.  This predicate interprets
!      the mode specified in the 'match_operand' as the mode of the memory
       reference for which the address would be valid.
  
  OTHER-LETTERS
       Other letters can be defined in machine-dependent fashion to stand
       for particular classes of registers or other arbitrary operand
!      types.  'd', 'a' and 'f' are defined on the 68000/68020 to stand
       for data, address and floating point registers.
  
   In order to have valid assembler code, each operand must satisfy its
--- 23179,23202 ----
  
       For operands to match in a particular case usually means that they
       are identical-looking RTL expressions.  But in a few special cases
!      specific kinds of dissimilarity are allowed.  For example, ‘*x’ as
!      an input operand will match ‘*x++’ as an output operand.  For
       proper results in such cases, the output template should always use
       the output-operand's number when printing the operand.
  
! ‘p’
       An operand that is a valid memory address is allowed.  This is for
       "load address" and "push address" instructions.
  
!      ‘p’ in the constraint must be accompanied by ‘address_operand’ as
!      the predicate in the ‘match_operand’.  This predicate interprets
!      the mode specified in the ‘match_operand’ as the mode of the memory
       reference for which the address would be valid.
  
  OTHER-LETTERS
       Other letters can be defined in machine-dependent fashion to stand
       for particular classes of registers or other arbitrary operand
!      types.  ‘d’, ‘a’ and ‘f’ are defined on the 68000/68020 to stand
       for data, address and floating point registers.
  
   In order to have valid assembler code, each operand must satisfy its
*************** The constraints don't need to _allow_ an
*** 23258,23292 ****
  the case, they do not constrain--but they must at least point the way to
  reloading any possible operand so that it will fit.
  
!    * If the constraint accepts whatever operands the predicate permits,
       there is no problem: reloading is never necessary for this operand.
  
       For example, an operand whose constraints permit everything except
       registers is safe provided its predicate rejects registers.
  
       An operand whose predicate accepts only constant values is safe
!      provided its constraints include the letter 'i'.  If any possible
!      constant value is accepted, then nothing less than 'i' will do; if
       the predicate is more selective, then the constraints may also be
       more selective.
  
!    * Any operand expression can be reloaded by copying it into a
       register.  So if an operand's constraints allow some kind of
       register, it is certain to be safe.  It need not permit all classes
       of registers; the compiler knows how to copy a register into
       another register of the proper class in order to make an
       instruction valid.
  
!    * A nonoffsettable memory reference can be reloaded by copying the
!      address into a register.  So if the constraint uses the letter 'o',
       all memory references are taken care of.
  
!    * A constant operand can be reloaded by allocating space in memory to
       hold it as preinitialized data.  Then the memory reference can be
       used in place of the constant.  So if the constraint uses the
!      letters 'o' or 'm', constant operands are not a problem.
  
!    * If the constraint permits a constant and a pseudo register used in
       an insn was not allocated to a hard register and is equivalent to a
       constant, the register will be replaced with the constant.  If the
       predicate does not permit a constant and the insn is re-recognized
--- 23257,23291 ----
  the case, they do not constrain--but they must at least point the way to
  reloading any possible operand so that it will fit.
  
!    • If the constraint accepts whatever operands the predicate permits,
       there is no problem: reloading is never necessary for this operand.
  
       For example, an operand whose constraints permit everything except
       registers is safe provided its predicate rejects registers.
  
       An operand whose predicate accepts only constant values is safe
!      provided its constraints include the letter ‘i’.  If any possible
!      constant value is accepted, then nothing less than ‘i’ will do; if
       the predicate is more selective, then the constraints may also be
       more selective.
  
!    • Any operand expression can be reloaded by copying it into a
       register.  So if an operand's constraints allow some kind of
       register, it is certain to be safe.  It need not permit all classes
       of registers; the compiler knows how to copy a register into
       another register of the proper class in order to make an
       instruction valid.
  
!    • A nonoffsettable memory reference can be reloaded by copying the
!      address into a register.  So if the constraint uses the letter ‘o’,
       all memory references are taken care of.
  
!    • A constant operand can be reloaded by allocating space in memory to
       hold it as preinitialized data.  Then the memory reference can be
       used in place of the constant.  So if the constraint uses the
!      letters ‘o’ or ‘m’, constant operands are not a problem.
  
!    • If the constraint permits a constant and a pseudo register used in
       an insn was not allocated to a hard register and is equivalent to a
       constant, the register will be replaced with the constant.  If the
       predicate does not permit a constant and the insn is re-recognized
*************** does not know how to copy a register tem
*** 23300,23310 ****
  
   If the predicate accepts a unary operator, the constraint applies to
  the operand.  For example, the MIPS processor at ISA level 3 supports an
! instruction which adds two registers in 'SImode' to produce a 'DImode'
  result, but only if the registers are correctly sign extended.  This
! predicate for the input operands accepts a 'sign_extend' of an 'SImode'
  register.  Write the constraint to indicate the type of register that is
! required for the operand of the 'sign_extend'.
  
  
  File: gccint.info,  Node: Multi-Alternative,  Next: Class Preferences,  Prev: Simple Constraints,  Up: Constraints
--- 23299,23309 ----
  
   If the predicate accepts a unary operator, the constraint applies to
  the operand.  For example, the MIPS processor at ISA level 3 supports an
! instruction which adds two registers in ‘SImode’ to produce a ‘DImode’
  result, but only if the registers are correctly sign extended.  This
! predicate for the input operands accepts a ‘sign_extend’ of an ‘SImode’
  register.  Write the constraint to indicate the type of register that is
! required for the operand of the ‘sign_extend’.
  
  
  File: gccint.info,  Node: Multi-Alternative,  Next: Class Preferences,  Prev: Simple Constraints,  Up: Constraints
*************** on the 68000:
*** 23333,23342 ****
                       (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
         ...)
  
!  The first alternative has 'm' (memory) for operand 0, '0' for operand 1
! (meaning it must match operand 0), and 'dKs' for operand 2.  The second
! alternative has 'd' (data register) for operand 0, '0' for operand 1,
! and 'dmKs' for operand 2.  The '=' and '%' in the constraints apply to
  all the alternatives; their meaning is explained in a later section
  (*note Modifiers::).
  
--- 23332,23341 ----
                       (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
         ...)
  
!  The first alternative has ‘m’ (memory) for operand 0, ‘0’ for operand 1
! (meaning it must match operand 0), and ‘dKs’ for operand 2.  The second
! alternative has ‘d’ (data register) for operand 0, ‘0’ for operand 1,
! and ‘dmKs’ for operand 2.  The ‘=’ and ‘%’ in the constraints apply to
  all the alternatives; their meaning is explained in a later section
  (*note Modifiers::).
  
*************** Otherwise, for each alternative, the com
*** 23345,23376 ****
  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.
  
! '^'
!      This constraint is analogous to '?' but it disparages slightly the
!      alternative only if the operand with the '^' needs a reload.
  
! '$'
!      This constraint is analogous to '!' but it disparages severely the
!      alternative only if the operand with the '$' needs a reload.
  
   When an insn pattern has multiple alternatives in its constraints,
  often the appearance of the assembler code is determined mostly by which
  alternative was matched.  When this is so, the C code for writing the
! assembler code can use the variable 'which_alternative', which is the
  ordinal number of the alternative that was actually satisfied (0 for the
  first, 1 for the second alternative, etc.).  *Note Output Statement::.
  
--- 23344,23375 ----
  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.
  
! ‘^’
!      This constraint is analogous to ‘?’ but it disparages slightly the
!      alternative only if the operand with the ‘^’ needs a reload.
  
! ‘$’
!      This constraint is analogous to ‘!’ but it disparages severely the
!      alternative only if the operand with the ‘$’ needs a reload.
  
   When an insn pattern has multiple alternatives in its constraints,
  often the appearance of the assembler code is determined mostly by which
  alternative was matched.  When this is so, the C code for writing the
! assembler code can use the variable ‘which_alternative’, which is the
  ordinal number of the alternative that was actually satisfied (0 for the
  first, 1 for the second alternative, etc.).  *Note Output Statement::.
  
*************** The operand constraints have another fun
*** 23384,23392 ****
  to decide which kind of hardware register a pseudo register is best
  allocated to.  The compiler examines the constraints that apply to the
  insns that use the pseudo register, looking for the machine-dependent
! letters such as 'd' and 'a' that specify classes of registers.  The
  pseudo register is put in whichever class gets the most "votes".  The
! constraint letters 'g' and 'r' also vote: they vote in favor of a
  general register.  The machine description says which registers are
  considered general.
  
--- 23383,23391 ----
  to decide which kind of hardware register a pseudo register is best
  allocated to.  The compiler examines the constraints that apply to the
  insns that use the pseudo register, looking for the machine-dependent
! letters such as ‘d’ and ‘a’ that specify classes of registers.  The
  pseudo register is put in whichever class gets the most "votes".  The
! constraint letters ‘g’ and ‘r’ also vote: they vote in favor of a
  general register.  The machine description says which registers are
  considered general.
  
*************** File: gccint.info,  Node: Modifiers,  Ne
*** 23401,23433 ****
  
  Here are constraint modifier characters.
  
! '='
       Means that this operand is written to by this instruction: the
       previous value is discarded and replaced by new 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 read by the instruction and
!      which are written by it.  '=' identifies an operand which is only
!      written; '+' identifies an operand that is both read and written;
       all other operands are assumed to only be read.
  
!      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 written before the instruction is
       finished using the input operands.  Therefore, this operand may not
       lie in a register that is read by the instruction 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 operand which is read by the instruction can be tied to an
--- 23400,23432 ----
  
  Here are constraint modifier characters.
  
! ‘=’
       Means that this operand is written to by this instruction: the
       previous value is discarded and replaced by new 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 read by the instruction and
!      which are written by it.  ‘=’ identifies an operand which is only
!      written; ‘+’ identifies an operand that is both read and written;
       all other operands are assumed to only be read.
  
!      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 written before the instruction is
       finished using the input operands.  Therefore, this operand may not
       lie in a register that is read by the instruction 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 operand which is read by the instruction can be tied to an
*************** Here are constraint modifier characters.
*** 23435,23457 ****
       early result is written.  Adding alternatives of this form often
       allows GCC to produce better code when only some of the read
       operands can be affected by the earlyclobber.  See, for example,
!      the 'mulsi3' insn of the ARM.
  
!      Furthermore, if the "earlyclobber" operand is also a read/write
       operand, then that operand is written only after it's used.
  
!      '&' does not obviate the need to write '=' or '+'.  As
!      "earlyclobber" operands are always written, a read-only
!      "earlyclobber" operand is ill-formed and will be rejected by the
       compiler.
  
! '%'
       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.  '%' applies to all alternatives and must
       appear as the first character in the constraint.  Only read-only
!      operands can use '%'.
  
       This is often used in patterns for addition instructions that
       really have only two operands: the result must go in one of the
--- 23434,23456 ----
       early result is written.  Adding alternatives of this form often
       allows GCC to produce better code when only some of the read
       operands can be affected by the earlyclobber.  See, for example,
!      the ‘mulsi3’ insn of the ARM.
  
!      Furthermore, if the “earlyclobber” operand is also a read/write
       operand, then that operand is written only after it's used.
  
!      ‘&’ does not obviate the need to write ‘=’ or ‘+’.  As
!      “earlyclobber” operands are always written, a read-only
!      “earlyclobber” operand is ill-formed and will be rejected by the
       compiler.
  
! ‘%’
       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.  ‘%’ applies to all alternatives and must
       appear as the first character in the constraint.  Only read-only
!      operands can use ‘%’.
  
       This is often used in patterns for addition instructions that
       really have only two operands: the result must go in one of the
*************** Here are constraint modifier characters.
*** 23468,23486 ****
       modifier if the two alternatives are strictly identical; this would
       only waste time in the reload pass.  The modifier is not
       operational after register allocation, so the result of
!      'define_peephole2' and 'define_split's performed after reload
!      cannot rely on '%' to make the intended insn match.
  
! '#'
       Says that all following characters, up to the next comma, are to be
       ignored as a constraint.  They are significant only for choosing
       register preferences.
  
! '*'
       Says that the following character should be ignored when choosing
!      register preferences.  '*' has no effect on the meaning of the
       constraint as a constraint, and no effect on reloading.  For LRA
!      '*' additionally disparages slightly the alternative if the
       following character matches the operand.
  
       Here is an example: the 68000 has an instruction to sign-extend a
--- 23467,23485 ----
       modifier if the two alternatives are strictly identical; this would
       only waste time in the reload pass.  The modifier is not
       operational after register allocation, so the result of
!      ‘define_peephole2’ and ‘define_split’s performed after reload
!      cannot rely on ‘%’ to make the intended insn match.
  
! ‘#’
       Says that all following characters, up to the next comma, are to be
       ignored as a constraint.  They are significant only for choosing
       register preferences.
  
! ‘*’
       Says that the following character should be ignored when choosing
!      register preferences.  ‘*’ has no effect on the meaning of the
       constraint as a constraint, and no effect on reloading.  For LRA
!      ‘*’ additionally disparages slightly the alternative if the
       following character matches the operand.
  
       Here is an example: the 68000 has an instruction to sign-extend a
*************** Here are constraint modifier characters.
*** 23488,23494 ****
       copying it into an address register.  While either kind of register
       is acceptable, the constraints on an address-register destination
       are less strict, so it is best if register allocation makes an
!      address register its goal.  Therefore, '*' is used so that the 'd'
       constraint letter (for data register) is ignored when computing
       register preferences.
  
--- 23487,23493 ----
       copying it into an address register.  While either kind of register
       is acceptable, the constraints on an address-register destination
       are less strict, so it is best if register allocation makes an
!      address register its goal.  Therefore, ‘*’ is used so that the ‘d’
       constraint letter (for data register) is ignored when computing
       register preferences.
  
*************** File: gccint.info,  Node: Machine Constr
*** 23505,24026 ****
  ------------------------------------------
  
  Whenever possible, you should use the general-purpose constraint letters
! in 'asm' arguments, since they will convey meaning more readily to
  people reading your code.  Failing that, use the constraint letters that
  usually have very similar meanings across architectures.  The most
! commonly used constraints are 'm' and 'r' (for memory and
  general-purpose registers respectively; *note Simple Constraints::), and
! 'I', usually the letter indicating the most common immediate-constant
  format.
  
   Each architecture defines additional constraints.  These constraints
  are used by the compiler itself for instruction generation, as well as
! for 'asm' statements; therefore, some of the constraints are not
! particularly useful for 'asm'.  Here is a summary of some of the
  machine-dependent constraints available on some particular machines; it
! includes both constraints that are useful for 'asm' and constraints that
  aren't.  The compiler source file mentioned in the table heading for
  each architecture is the definitive reference for the meanings of that
  architecture's constraints.
  
! _AArch64 family--'config/aarch64/constraints.md'_
!      'k'
!           The stack pointer register ('SP')
  
!      'w'
            Floating point register, Advanced SIMD vector register or SVE
            vector register
  
!      'x'
!           Like 'w', but restricted to registers 0 to 15 inclusive.
  
!      'y'
!           Like 'w', but restricted to registers 0 to 7 inclusive.
  
!      'Upl'
!           One of the low eight SVE predicate registers ('P0' to 'P7')
  
!      'Upa'
!           Any of the SVE predicate registers ('P0' to 'P15')
  
!      'I'
            Integer constant that is valid as an immediate operand in an
!           'ADD' instruction
  
!      'J'
            Integer constant that is valid as an immediate operand in a
!           'SUB' instruction (once negated)
  
!      'K'
            Integer constant that can be used with a 32-bit logical
            instruction
  
!      'L'
            Integer constant that can be used with a 64-bit logical
            instruction
  
!      'M'
            Integer constant that is valid as an immediate operand in a
!           32-bit 'MOV' pseudo instruction.  The 'MOV' may be assembled
            to one of several different machine instructions depending on
            the value
  
!      'N'
            Integer constant that is valid as an immediate operand in a
!           64-bit 'MOV' pseudo instruction
  
!      'S'
            An absolute symbolic address or a label reference
  
!      'Y'
            Floating point constant zero
  
!      'Z'
            Integer constant zero
  
!      'Ush'
            The high part (bits 12 and upwards) of the pc-relative address
            of a symbol within 4GB of the instruction
  
!      'Q'
            A memory address which uses a single base register with no
            offset
  
!      'Ump'
            A memory address suitable for a load/store pair instruction in
            SI, DI, SF and DF modes
  
! _AMD GCN --'config/gcn/constraints.md'_
!      'I'
!           Immediate integer in the range -16 to 64
  
!      'J'
            Immediate 16-bit signed integer
  
!      'Kf'
!           Immediate constant -1
  
!      'L'
            Immediate 15-bit unsigned integer
  
!      'A'
            Immediate constant that can be inlined in an instruction
!           encoding: integer -16..64, or float 0.0, +/-0.5, +/-1.0,
!           +/-2.0, +/-4.0, 1.0/(2.0*PI)
  
!      'B'
            Immediate 32-bit signed integer that can be attached to an
            instruction encoding
  
!      'C'
!           Immediate 32-bit integer in range -16..4294967295 (i.e.
!           32-bit unsigned integer or 'A' constraint)
  
!      'DA'
!           Immediate 64-bit constant that can be split into two 'A'
            constants
  
!      'DB'
!           Immediate 64-bit constant that can be split into two 'B'
            constants
  
!      'U'
!           Any 'unspec'
  
!      'Y'
!           Any 'symbol_ref' or 'label_ref'
  
!      'v'
            VGPR register
  
!      'Sg'
            SGPR register
  
!      'SD'
            SGPR registers valid for instruction destinations, including
            VCC, M0 and EXEC
  
!      'SS'
            SGPR registers valid for instruction sources, including VCC,
            M0, EXEC and SCC
  
!      'Sm'
            SGPR registers valid as a source for scalar memory
            instructions (excludes M0 and EXEC)
  
!      'Sv'
            SGPR registers valid as a source or destination for vector
            instructions (excludes EXEC)
  
!      'ca'
            All condition registers: SCC, VCCZ, EXECZ
  
!      'cs'
            Scalar condition register: SCC
  
!      'cV'
            Vector condition register: VCC, VCC_LO, VCC_HI
  
!      'e'
            EXEC register (EXEC_LO and EXEC_HI)
  
!      'RB'
!           Memory operand with address space suitable for 'buffer_*'
            instructions
  
!      'RF'
!           Memory operand with address space suitable for 'flat_*'
            instructions
  
!      'RS'
!           Memory operand with address space suitable for 's_*'
            instructions
  
!      'RL'
!           Memory operand with address space suitable for 'ds_*' LDS
            instructions
  
!      'RG'
!           Memory operand with address space suitable for 'ds_*' GDS
            instructions
  
!      'RD'
!           Memory operand with address space suitable for any 'ds_*'
            instructions
  
!      'RM'
!           Memory operand with address space suitable for 'global_*'
            instructions
  
! _ARC --'config/arc/constraints.md'_
!      'q'
!           Registers usable in ARCompact 16-bit instructions: 'r0'-'r3',
!           'r12'-'r15'.  This constraint can only match when the '-mq'
            option is in effect.
  
!      'e'
            Registers usable as base-regs of memory addresses in ARCompact
!           16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'.
!           This constraint can only match when the '-mq' option is in
            effect.
!      'D'
!           ARC FPX (dpfp) 64-bit registers.  'D0', 'D1'.
  
!      'I'
            A signed 12-bit integer constant.
  
!      'Cal'
            constant for arithmetic/logical operations.  This might be any
            constant that can be put into a long immediate by the assmbler
            or linker without involving a PIC relocation.
  
!      'K'
            A 3-bit unsigned integer constant.
  
!      'L'
            A 6-bit unsigned integer constant.
  
!      'CnL'
            One's complement of a 6-bit unsigned integer constant.
  
!      'CmL'
            Two's complement of a 6-bit unsigned integer constant.
  
!      'M'
            A 5-bit unsigned integer constant.
  
!      'O'
            A 7-bit unsigned integer constant.
  
!      'P'
            A 8-bit unsigned integer constant.
  
!      'H'
            Any const_double value.
  
! _ARM family--'config/arm/constraints.md'_
  
!      'h'
!           In Thumb state, the core registers 'r8'-'r15'.
  
!      'k'
            The stack pointer register.
  
!      'l'
!           In Thumb State the core registers 'r0'-'r7'.  In ARM state
!           this is an alias for the 'r' constraint.
  
!      't'
!           VFP floating-point registers 's0'-'s31'.  Used for 32 bit
            values.
  
!      'w'
!           VFP floating-point registers 'd0'-'d31' and the appropriate
!           subset 'd0'-'d15' based on command line options.  Used for 64
            bit values only.  Not valid for Thumb1.
  
!      'y'
            The iWMMX co-processor registers.
  
!      'z'
            The iWMMX GR registers.
  
!      'G'
            The floating-point constant 0.0
  
!      'I'
            Integer that is valid as an immediate operand in a data
            processing instruction.  That is, an integer in the range 0 to
            255 rotated by a multiple of 2
  
!      'J'
!           Integer in the range -4095 to 4095
  
!      'K'
!           Integer that satisfies constraint 'I' when inverted (ones
            complement)
  
!      'L'
!           Integer that satisfies constraint 'I' when negated (twos
            complement)
  
!      'M'
            Integer in the range 0 to 32
  
!      'Q'
            A memory reference where the exact address is in a single
!           register (''m'' is preferable for 'asm' statements)
  
!      'R'
            An item in the constant pool
  
!      'S'
            A symbol in the text segment of the current file
  
!      'Uv'
            A memory reference suitable for VFP load/store insns
            (reg+constant offset)
  
!      'Uy'
            A memory reference suitable for iWMMXt load/store
            instructions.
  
!      'Uq'
            A memory reference suitable for the ARMv4 ldrsb instruction.
  
! _AVR family--'config/avr/constraints.md'_
!      'l'
            Registers from r0 to r15
  
!      'a'
            Registers from r16 to r23
  
!      'd'
            Registers from r16 to r31
  
!      'w'
            Registers from r24 to r31.  These registers can be used in
!           'adiw' command
  
!      'e'
            Pointer register (r26-r31)
  
!      'b'
            Base pointer register (r28-r31)
  
!      'q'
            Stack pointer register (SPH:SPL)
  
!      't'
            Temporary register r0
  
!      'x'
            Register pair X (r27:r26)
  
!      'y'
            Register pair Y (r29:r28)
  
!      'z'
            Register pair Z (r31:r30)
  
!      'I'
!           Constant greater than -1, less than 64
  
!      'J'
!           Constant greater than -64, less than 1
  
!      'K'
            Constant integer 2
  
!      'L'
            Constant integer 0
  
!      'M'
            Constant that fits in 8 bits
  
!      'N'
!           Constant integer -1
  
!      'O'
            Constant integer 8, 16, or 24
  
!      'P'
            Constant integer 1
  
!      'G'
            A floating point constant 0.0
  
!      'Q'
            A memory address based on Y or Z pointer with displacement.
  
! _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.
  
! _C-SKY--'config/csky/constraints.md'_
  
!      'a'
            The mini registers r0 - r7.
  
!      'b'
            The low registers r0 - r15.
  
!      'c'
            C register.
  
!      'y'
            HI and LO registers.
  
!      'l'
            LO register.
  
!      'h'
            HI register.
  
!      'v'
            Vector registers.
  
!      'z'
            Stack pointer register (SP).
  
!      'Q'
            A memory address which uses a base register with a short
            offset or with a index register with its scale.
  
!      'W'
            A memory address which uses a base register with a index
            register with its scale.
  
--- 23504,24025 ----
  ------------------------------------------
  
  Whenever possible, you should use the general-purpose constraint letters
! in ‘asm’ arguments, since they will convey meaning more readily to
  people reading your code.  Failing that, use the constraint letters that
  usually have very similar meanings across architectures.  The most
! commonly used constraints are ‘m’ and ‘r’ (for memory and
  general-purpose registers respectively; *note Simple Constraints::), and
! ‘I’, usually the letter indicating the most common immediate-constant
  format.
  
   Each architecture defines additional constraints.  These constraints
  are used by the compiler itself for instruction generation, as well as
! for ‘asm’ statements; therefore, some of the constraints are not
! particularly useful for ‘asm’.  Here is a summary of some of the
  machine-dependent constraints available on some particular machines; it
! includes both constraints that are useful for ‘asm’ and constraints that
  aren't.  The compiler source file mentioned in the table heading for
  each architecture is the definitive reference for the meanings of that
  architecture's constraints.
  
! _AArch64 family--‘config/aarch64/constraints.md’_
!      ‘k’
!           The stack pointer register (‘SP’)
  
!      ‘w’
            Floating point register, Advanced SIMD vector register or SVE
            vector register
  
!      ‘x’
!           Like ‘w’, but restricted to registers 0 to 15 inclusive.
  
!      ‘y’
!           Like ‘w’, but restricted to registers 0 to 7 inclusive.
  
!      ‘Upl’
!           One of the low eight SVE predicate registers (‘P0’ to ‘P7’)
  
!      ‘Upa’
!           Any of the SVE predicate registers (‘P0’ to ‘P15’)
  
!      ‘I’
            Integer constant that is valid as an immediate operand in an
!           ‘ADD’ instruction
  
!      ‘J’
            Integer constant that is valid as an immediate operand in a
!           ‘SUB’ instruction (once negated)
  
!      ‘K’
            Integer constant that can be used with a 32-bit logical
            instruction
  
!      ‘L’
            Integer constant that can be used with a 64-bit logical
            instruction
  
!      ‘M’
            Integer constant that is valid as an immediate operand in a
!           32-bit ‘MOV’ pseudo instruction.  The ‘MOV’ may be assembled
            to one of several different machine instructions depending on
            the value
  
!      ‘N’
            Integer constant that is valid as an immediate operand in a
!           64-bit ‘MOV’ pseudo instruction
  
!      ‘S’
            An absolute symbolic address or a label reference
  
!      ‘Y’
            Floating point constant zero
  
!      ‘Z’
            Integer constant zero
  
!      ‘Ush’
            The high part (bits 12 and upwards) of the pc-relative address
            of a symbol within 4GB of the instruction
  
!      ‘Q’
            A memory address which uses a single base register with no
            offset
  
!      ‘Ump’
            A memory address suitable for a load/store pair instruction in
            SI, DI, SF and DF modes
  
! _AMD GCN --‘config/gcn/constraints.md’_
!      ‘I’
!           Immediate integer in the range −16 to 64
  
!      ‘J’
            Immediate 16-bit signed integer
  
!      ‘Kf’
!           Immediate constant −1
  
!      ‘L’
            Immediate 15-bit unsigned integer
  
!      ‘A’
            Immediate constant that can be inlined in an instruction
!           encoding: integer −16..64, or float 0.0, +/−0.5, +/−1.0,
!           +/−2.0, +/−4.0, 1.0/(2.0*PI)
  
!      ‘B’
            Immediate 32-bit signed integer that can be attached to an
            instruction encoding
  
!      ‘C’
!           Immediate 32-bit integer in range −16..4294967295 (i.e.
!           32-bit unsigned integer or ‘A’ constraint)
  
!      ‘DA’
!           Immediate 64-bit constant that can be split into two ‘A’
            constants
  
!      ‘DB’
!           Immediate 64-bit constant that can be split into two ‘B’
            constants
  
!      ‘U’
!           Any ‘unspec’
  
!      ‘Y’
!           Any ‘symbol_ref’ or ‘label_ref’
  
!      ‘v’
            VGPR register
  
!      ‘Sg’
            SGPR register
  
!      ‘SD’
            SGPR registers valid for instruction destinations, including
            VCC, M0 and EXEC
  
!      ‘SS’
            SGPR registers valid for instruction sources, including VCC,
            M0, EXEC and SCC
  
!      ‘Sm’
            SGPR registers valid as a source for scalar memory
            instructions (excludes M0 and EXEC)
  
!      ‘Sv’
            SGPR registers valid as a source or destination for vector
            instructions (excludes EXEC)
  
!      ‘ca’
            All condition registers: SCC, VCCZ, EXECZ
  
!      ‘cs’
            Scalar condition register: SCC
  
!      ‘cV’
            Vector condition register: VCC, VCC_LO, VCC_HI
  
!      ‘e’
            EXEC register (EXEC_LO and EXEC_HI)
  
!      ‘RB’
!           Memory operand with address space suitable for ‘buffer_*’
            instructions
  
!      ‘RF’
!           Memory operand with address space suitable for ‘flat_*’
            instructions
  
!      ‘RS’
!           Memory operand with address space suitable for ‘s_*’
            instructions
  
!      ‘RL’
!           Memory operand with address space suitable for ‘ds_*’ LDS
            instructions
  
!      ‘RG’
!           Memory operand with address space suitable for ‘ds_*’ GDS
            instructions
  
!      ‘RD’
!           Memory operand with address space suitable for any ‘ds_*’
            instructions
  
!      ‘RM’
!           Memory operand with address space suitable for ‘global_*’
            instructions
  
! _ARC --‘config/arc/constraints.md’_
!      ‘q’
!           Registers usable in ARCompact 16-bit instructions: ‘r0’-‘r3’,
!           ‘r12’-‘r15’.  This constraint can only match when the ‘-mq’
            option is in effect.
  
!      ‘e’
            Registers usable as base-regs of memory addresses in ARCompact
!           16-bit memory instructions: ‘r0’-‘r3’, ‘r12’-‘r15’, ‘sp’.
!           This constraint can only match when the ‘-mq’ option is in
            effect.
!      ‘D’
!           ARC FPX (dpfp) 64-bit registers.  ‘D0’, ‘D1’.
  
!      ‘I’
            A signed 12-bit integer constant.
  
!      ‘Cal’
            constant for arithmetic/logical operations.  This might be any
            constant that can be put into a long immediate by the assmbler
            or linker without involving a PIC relocation.
  
!      ‘K’
            A 3-bit unsigned integer constant.
  
!      ‘L’
            A 6-bit unsigned integer constant.
  
!      ‘CnL’
            One's complement of a 6-bit unsigned integer constant.
  
!      ‘CmL’
            Two's complement of a 6-bit unsigned integer constant.
  
!      ‘M’
            A 5-bit unsigned integer constant.
  
!      ‘O’
            A 7-bit unsigned integer constant.
  
!      ‘P’
            A 8-bit unsigned integer constant.
  
!      ‘H’
            Any const_double value.
  
! _ARM family--‘config/arm/constraints.md’_
  
!      ‘h’
!           In Thumb state, the core registers ‘r8’-‘r15’.
  
!      ‘k’
            The stack pointer register.
  
!      ‘l’
!           In Thumb State the core registers ‘r0’-‘r7’.  In ARM state
!           this is an alias for the ‘r’ constraint.
  
!      ‘t’
!           VFP floating-point registers ‘s0’-‘s31’.  Used for 32 bit
            values.
  
!      ‘w’
!           VFP floating-point registers ‘d0’-‘d31’ and the appropriate
!           subset ‘d0’-‘d15’ based on command line options.  Used for 64
            bit values only.  Not valid for Thumb1.
  
!      ‘y’
            The iWMMX co-processor registers.
  
!      ‘z’
            The iWMMX GR registers.
  
!      ‘G’
            The floating-point constant 0.0
  
!      ‘I’
            Integer that is valid as an immediate operand in a data
            processing instruction.  That is, an integer in the range 0 to
            255 rotated by a multiple of 2
  
!      ‘J’
!           Integer in the range −4095 to 4095
  
!      ‘K’
!           Integer that satisfies constraint ‘I’ when inverted (ones
            complement)
  
!      ‘L’
!           Integer that satisfies constraint ‘I’ when negated (twos
            complement)
  
!      ‘M’
            Integer in the range 0 to 32
  
!      ‘Q’
            A memory reference where the exact address is in a single
!           register ('‘m’' is preferable for ‘asm’ statements)
  
!      ‘R’
            An item in the constant pool
  
!      ‘S’
            A symbol in the text segment of the current file
  
!      ‘Uv’
            A memory reference suitable for VFP load/store insns
            (reg+constant offset)
  
!      ‘Uy’
            A memory reference suitable for iWMMXt load/store
            instructions.
  
!      ‘Uq’
            A memory reference suitable for the ARMv4 ldrsb instruction.
  
! _AVR family--‘config/avr/constraints.md’_
!      ‘l’
            Registers from r0 to r15
  
!      ‘a’
            Registers from r16 to r23
  
!      ‘d’
            Registers from r16 to r31
  
!      ‘w’
            Registers from r24 to r31.  These registers can be used in
!           ‘adiw’ command
  
!      ‘e’
            Pointer register (r26-r31)
  
!      ‘b’
            Base pointer register (r28-r31)
  
!      ‘q’
            Stack pointer register (SPH:SPL)
  
!      ‘t’
            Temporary register r0
  
!      ‘x’
            Register pair X (r27:r26)
  
!      ‘y’
            Register pair Y (r29:r28)
  
!      ‘z’
            Register pair Z (r31:r30)
  
!      ‘I’
!           Constant greater than −1, less than 64
  
!      ‘J’
!           Constant greater than −64, less than 1
  
!      ‘K’
            Constant integer 2
  
!      ‘L’
            Constant integer 0
  
!      ‘M’
            Constant that fits in 8 bits
  
!      ‘N’
!           Constant integer −1
  
!      ‘O’
            Constant integer 8, 16, or 24
  
!      ‘P’
            Constant integer 1
  
!      ‘G’
            A floating point constant 0.0
  
!      ‘Q’
            A memory address based on Y or Z pointer with displacement.
  
! _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.
  
! _C-SKY--‘config/csky/constraints.md’_
  
!      ‘a’
            The mini registers r0 - r7.
  
!      ‘b’
            The low registers r0 - r15.
  
!      ‘c’
            C register.
  
!      ‘y’
            HI and LO registers.
  
!      ‘l’
            LO register.
  
!      ‘h’
            HI register.
  
!      ‘v’
            Vector registers.
  
!      ‘z’
            Stack pointer register (SP).
  
!      ‘Q’
            A memory address which uses a base register with a short
            offset or with a index register with its scale.
  
!      ‘W’
            A memory address which uses a base register with a index
            register with its scale.
  
*************** _C-SKY--'config/csky/constraints.md'_
*** 24030,25105 ****
       ranges accepted by particular instruction encodings.  Refer to the
       source code for details.
  
! _Epiphany--'config/epiphany/constraints.md'_
!      'U16'
            An unsigned 16-bit constant.
  
!      'K'
            An unsigned 5-bit constant.
  
!      'L'
            A signed 11-bit constant.
  
!      'Cm1'
!           A signed 11-bit constant added to -1.  Can only match when the
!           '-m1reg-REG' option is active.
  
!      'Cl1'
!           Left-shift of -1, i.e., a bit mask with a block of leading
            ones, the rest being a block of trailing zeroes.  Can only
!           match when the '-m1reg-REG' option is active.
  
!      'Cr1'
!           Right-shift of -1, i.e., a bit mask with a trailing block of
            ones, the rest being zeroes.  Or to put it another way, one
            less than a power of two.  Can only match when the
!           '-m1reg-REG' option is active.
  
!      'Cal'
!           Constant for arithmetic/logical operations.  This is like 'i',
            except that for position independent code, no symbols /
            expressions needing relocations are allowed.
  
!      'Csy'
            Symbolic constant for call/jump instruction.
  
!      'Rcs'
            The register class usable in short insns.  This is a register
            class constraint, and can thus drive register allocation.
!           This constraint won't match unless '-mprefer-short-insn-regs'
            is in effect.
  
!      'Rsc'
            The register class of registers that can be used to hold a
            sibcall call address.  I.e., a caller-saved register.
  
!      'Rct'
            Core control register class.
  
!      'Rgs'
            The register group usable in short insns.  This constraint
            does not use a register class, so that it only passively
            matches suitable registers, and doesn't drive register
            allocation.
  
!      'Car'
            Constant suitable for the addsi3_r pattern.  This is a valid
            offset For byte, halfword, or word addressing.
  
!      'Rra'
            Matches the return address if it can be replaced with the link
            register.
  
!      'Rcc'
            Matches the integer condition code register.
  
!      'Sra'
            Matches the return address if it is in a stack slot.
  
!      'Cfm'
            Matches control register values to switch fp mode, which are
!           encapsulated in 'UNSPEC_FP_MODE'.
  
! _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.
  
! _FT32--'config/ft32/constraints.md'_
!      'A'
            An absolute address
  
!      'B'
            An offset address
  
!      'W'
            A register indirect memory operand
  
!      'e'
            An offset address.
  
!      'f'
            An offset address.
  
!      'O'
            The constant zero or one
  
!      'I'
!           A 16-bit signed constant (-32768 ... 32767)
  
!      'w'
            A bitfield mask suitable for bext or bins
  
!      'x'
            An inverted bitfield mask suitable for bext or bins
  
!      'L'
            A 16-bit unsigned constant, multiple of 4 (0 ... 65532)
  
!      'S'
!           A 20-bit signed constant (-524288 ... 524287)
  
!      'b'
            A constant for a bitfield width (1 ... 16)
  
!      'KA'
!           A 10-bit signed constant (-512 ... 511)
  
! _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
  
! _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 '>'.
  
! _M32C--'config/m32c/m32c.cc'_
!      '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
  
! _LoongArch--'config/loongarch/constraints.md'_
!      'f'
            A floating-point register (if available).
!      'k'
            A memory operand whose address is formed by a base register
            and (optionally scaled) index register.
!      'l'
            A signed 16-bit constant.
!      'm'
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as 'st.w' and 'ld.w'.
!      'I'
            A signed 12-bit constant (for arithmetic instructions).
!      'K'
            An unsigned 12-bit constant (for logic instructions).
!      'ZB'
            An address that is held in a general-purpose register.  The
            offset is zero.
!      'ZC'
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as 'll.w' and 'sc.w'.
  
! _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'
!           A general-purpose register.  This is equivalent to 'r' unless
            generating MIPS16 code, in which case the MIPS16 register set
            is used.
  
!      'f'
            A floating-point register (if available).
  
!      'h'
!           Formerly the 'hi' register.  This constraint is no longer
            supported.
  
!      'l'
!           The 'lo' register.  Use this register to store values that are
            no bigger than a word.
  
!      'x'
!           The concatenated 'hi' and 'lo' registers.  Use this register
            to store doubleword values.
  
!      'c'
            A register suitable for use in an indirect jump.  This will
!           always be '$25' for '-mabicalls'.
  
!      'v'
!           Register '$3'.  Do not use this constraint in new code; it is
            retained only for compatibility with glibc.
  
!      'y'
!           Equivalent to 'r'; retained for backwards compatibility.
  
!      'z'
            A floating-point condition code register.
  
!      'I'
            A signed 16-bit constant (for arithmetic instructions).
  
!      'J'
            Integer zero.
  
!      'K'
            An unsigned 16-bit constant (for logic instructions).
  
!      'L'
            A signed 32-bit constant in which the lower 16 bits are zero.
!           Such constants can be loaded using 'lui'.
  
!      'M'
!           A constant that cannot be loaded using 'lui', 'addiu' or
!           'ori'.
  
!      'N'
!           A constant in the range -65535 to -1 (inclusive).
  
!      'O'
            A signed 15-bit constant.
  
!      'P'
            A constant in the range 1 to 65535 (inclusive).
  
!      'G'
            Floating-point zero.
  
!      'R'
            An address that can be used in a non-macro load or store.
  
!      'ZC'
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as 'll' and 'sc'.
  
!      'ZD'
!           An address suitable for a 'prefetch' instruction, or for any
!           other instruction with the same addressing mode as 'prefetch'.
  
! _Motorola 680x0--'config/m68k/constraints.md'_
!      'a'
            Address register
  
!      'd'
            Data register
  
!      'f'
            68881 floating-point register, if available
  
!      'I'
            Integer in the range 1 to 8
  
!      'J'
            16-bit signed number
  
!      'K'
            Signed number whose magnitude is greater than 0x80
  
!      'L'
!           Integer in the range -8 to -1
  
!      'M'
            Signed number whose magnitude is greater than 0x100
  
!      'N'
            Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate
  
!      'O'
            16 (for rotate using swap)
  
!      'P'
            Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate
  
!      'R'
            Numbers that mov3q can handle
  
!      'G'
            Floating point constant that is not a 68881 constant
  
!      'S'
            Operands that satisfy 'm' when -mpcrel is in effect
  
!      'T'
            Operands that satisfy 's' when -mpcrel is not in effect
  
!      'Q'
            Address register indirect addressing mode
  
!      'U'
            Register offset addressing
  
!      'W'
            const_call_operand
  
!      'Cs'
            symbol_ref or const
  
!      'Ci'
            const_int
  
!      'C0'
            const_int 0
  
!      'Cj'
            Range of signed numbers that don't fit in 16 bits
  
!      'Cmvq'
            Integers valid for mvq
  
!      'Capsw'
            Integers valid for a moveq followed by a swap
  
!      'Cmvz'
            Integers valid for mvz
  
!      'Cmvs'
            Integers valid for mvs
  
!      'Ap'
            push_operand
  
!      'Ac'
            Non-register operands allowed in clr
  
! _Moxie--'config/moxie/constraints.md'_
!      'A'
            An absolute address
  
!      'B'
            An offset address
  
!      'W'
            A register indirect memory operand
  
!      'I'
            A constant in the range of 0 to 255.
  
!      'N'
!           A constant in the range of 0 to -255.
  
! _MSP430-'config/msp430/constraints.md'_
  
!      'R12'
            Register R12.
  
!      'R13'
            Register R13.
  
!      'K'
            Integer constant 1.
  
!      'L'
            Integer constant -1^20..1^19.
  
!      'M'
            Integer constant 1-4.
  
!      'Ya'
            Memory references which do not require an extended MOVX
            instruction.
  
!      'Yl'
            Memory reference, labels only.
  
!      'Ys'
            Memory reference, stack only.
  
! _NDS32--'config/nds32/constraints.md'_
!      'w'
            LOW register class $r0 to $r7 constraint for V3/V3M ISA.
!      'l'
            LOW register class $r0 to $r7.
!      'd'
            MIDDLE register class $r0 to $r11, $r16 to $r19.
!      'h'
            HIGH register class $r12 to $r14, $r20 to $r31.
!      't'
            Temporary assist register $ta (i.e. $r15).
!      'k'
            Stack register $sp.
!      'Iu03'
            Unsigned immediate 3-bit value.
!      'In03'
!           Negative immediate 3-bit value in the range of -7-0.
!      'Iu04'
            Unsigned immediate 4-bit value.
!      'Is05'
            Signed immediate 5-bit value.
!      'Iu05'
            Unsigned immediate 5-bit value.
!      'In05'
!           Negative immediate 5-bit value in the range of -31-0.
!      'Ip05'
            Unsigned immediate 5-bit value for movpi45 instruction with
            range 16-47.
!      'Iu06'
            Unsigned immediate 6-bit value constraint for addri36.sp
            instruction.
!      'Iu08'
            Unsigned immediate 8-bit value.
!      'Iu09'
            Unsigned immediate 9-bit value.
!      'Is10'
            Signed immediate 10-bit value.
!      'Is11'
            Signed immediate 11-bit value.
!      'Is15'
            Signed immediate 15-bit value.
!      'Iu15'
            Unsigned immediate 15-bit value.
!      'Ic15'
            A constant which is not in the range of imm15u but ok for bclr
            instruction.
!      'Ie15'
            A constant which is not in the range of imm15u but ok for bset
            instruction.
!      'It15'
            A constant which is not in the range of imm15u but ok for btgl
            instruction.
!      'Ii15'
            A constant whose compliment value is in the range of imm15u
            and ok for bitci instruction.
!      'Is16'
            Signed immediate 16-bit value.
!      'Is17'
            Signed immediate 17-bit value.
!      'Is19'
            Signed immediate 19-bit value.
!      'Is20'
            Signed immediate 20-bit value.
!      'Ihig'
            The immediate value that can be simply set high 20-bit.
!      'Izeb'
            The immediate value 0xff.
!      'Izeh'
            The immediate value 0xffff.
!      'Ixls'
            The immediate value 0x01.
!      'Ix11'
            The immediate value 0x7ff.
!      'Ibms'
            The immediate value with power of 2.
!      'Ifex'
            The immediate value with power of 2 minus 1.
!      'U33'
            Memory constraint for 333 format.
!      'U45'
            Memory constraint for 45 format.
!      'U37'
            Memory constraint for 37 format.
  
! _Nios II family--'config/nios2/constraints.md'_
  
!      'I'
            Integer that is valid as an immediate operand in an
!           instruction taking a signed 16-bit number.  Range -32768 to
            32767.
  
!      'J'
            Integer that is valid as an immediate operand in an
            instruction taking an unsigned 16-bit number.  Range 0 to
            65535.
  
!      'K'
            Integer that is valid as an immediate operand in an
            instruction taking only the upper 16-bits of a 32-bit number.
            Range 32-bit numbers with the lower 16-bits being 0.
  
!      'L'
            Integer that is valid as an immediate operand for a shift
            instruction.  Range 0 to 31.
  
!      'M'
            Integer that is valid as an immediate operand for only the
            value 0.  Can be used in conjunction with the format modifier
!           'z' to use 'r0' instead of '0' in the assembly output.
  
!      'N'
            Integer that is valid as an immediate operand for a custom
            instruction opcode.  Range 0 to 255.
  
!      'P'
            An immediate operand for R2 andchi/andci instructions.
  
!      'S'
            Matches immediates which are addresses in the small data
!           section and therefore can be added to 'gp' as a 16-bit
            immediate to re-create their 32-bit value.
  
!      'U'
            Matches constants suitable as an operand for the rdprs and
            cache instructions.
  
!      'v'
            A memory operand suitable for Nios II R2 load/store exclusive
            instructions.
  
!      'w'
            A memory operand suitable for load/store IO and cache
            instructions.
  
!      'T'
!           A 'const' wrapped 'UNSPEC' expression, representing a
            supported PIC or TLS relocation.
  
! _OpenRISC--'config/or1k/constraints.md'_
!      'I'
            Integer that is valid as an immediate operand in an
!           instruction taking a signed 16-bit number.  Range -32768 to
            32767.
  
!      'K'
            Integer that is valid as an immediate operand in an
            instruction taking an unsigned 16-bit number.  Range 0 to
            65535.
  
!      'M'
            Signed 16-bit constant shifted left 16 bits.  (Used with
!           'l.movhi')
  
!      'O'
            Zero
  
!      'c'
            Register usable for sibcalls.
  
! _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.
  
!      'D'
            A memory reference that is encoded within the opcode, but not
            auto-increment or auto-decrement.
  
!      'f'
            Any of the floating point registers (AC0 through AC5).
  
!      'G'
            Floating point constant 0.
  
!      'h'
            Floating point registers AC4 and AC5.  These cannot be loaded
            from/to memory with a single instruction.
  
!      '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 0 through 3; 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.
  
! _PowerPC and IBM RS6000--'config/rs6000/constraints.md'_
!      'r'
!           A general purpose register (GPR), 'r0'...'r31'.
  
!      'b'
!           A base register.  Like 'r', but 'r0' is not allowed, so
!           'r1'...'r31'.
  
!      'f'
!           A floating point register (FPR), 'f0'...'f31'.
  
!      'd'
!           A floating point register.  This is the same as 'f' nowadays;
!           historically 'f' was for single-precision and 'd' was for
            double-precision floating point.
  
!      'v'
!           An Altivec vector register (VR), 'v0'...'v31'.
  
!      'wa'
!           A VSX register (VSR), 'vs0'...'vs63'.  This is either an FPR
!           ('vs0'...'vs31' are 'f0'...'f31') or a VR ('vs32'...'vs63' are
!           'v0'...'v31').
  
!           When using 'wa', you should use the '%x' output modifier, so
            that the correct register number is printed.  For example:
  
                 asm ("xvadddp %x0,%x1,%x2"
                      : "=wa" (v1)
                      : "wa" (v2), "wa" (v3));
  
!           You should not use '%x' for 'v' operands:
  
                 asm ("xsaddqp %0,%1,%2"
                      : "=v" (v1)
                      : "v" (v2), "v" (v3));
  
!      'h'
!           A special register ('vrsave', 'ctr', or 'lr').
  
!      'c'
!           The count register, 'ctr'.
  
!      'l'
!           The link register, 'lr'.
  
!      'x'
!           Condition register field 0, 'cr0'.
  
!      'y'
!           Any condition register field, 'cr0'...'cr7'.
  
!      'z'
!           The carry bit, 'XER[CA]'.
  
!      'we'
!           Like 'wa', if '-mpower9-vector' and '-m64' are used;
!           otherwise, 'NO_REGS'.
  
!      'wn'
!           No register ('NO_REGS').
  
!      'wr'
!           Like 'r', if '-mpowerpc64' is used; otherwise, 'NO_REGS'.
  
!      'wx'
!           Like 'd', if '-mpowerpc-gfxopt' is used; otherwise, 'NO_REGS'.
  
!      'wA'
!           Like 'b', if '-mpowerpc64' is used; otherwise, 'NO_REGS'.
  
!      'wB'
            Signed 5-bit constant integer that can be loaded into an
            Altivec register.
  
!      'wE'
            Vector constant that can be loaded with the XXSPLTIB
            instruction.
  
!      'wF'
            Memory operand suitable for power8 GPR load fusion.
  
!      'wL'
            Int constant that is the element number mfvsrld accesses in a
            vector.
  
!      'wM'
            Match vector constant with all 1's if the XXLORC instruction
            is available.
  
!      'wO'
            Memory operand suitable for the ISA 3.0 vector d-form
            instructions.
  
!      'wQ'
            Memory operand suitable for the load/store quad instructions.
  
!      'wS'
            Vector constant that can be loaded with XXSPLTIB & sign
            extension.
  
!      'wY'
            A memory operand for a DS-form instruction.
  
!      'wZ'
            An indexed or indirect memory operand, ignoring the bottom 4
            bits.
  
!      'I'
            A signed 16-bit constant.
  
!      'J'
!           An unsigned 16-bit constant shifted left 16 bits (use 'L'
!           instead for 'SImode' constants).
  
!      'K'
            An unsigned 16-bit constant.
  
!      'L'
            A signed 16-bit constant shifted left 16 bits.
  
!      'M'
            An integer constant greater than 31.
  
!      'N'
            An exact power of 2.
  
!      'O'
            The integer constant zero.
  
!      'P'
            A constant whose negation is a signed 16-bit constant.
  
!      'eI'
            A signed 34-bit integer constant if prefixed instructions are
            supported.
  
!      'eP'
            A scalar floating point constant or a vector constant that can
            be loaded to a VSX register with one prefixed instruction.
  
!      'eQ'
            An IEEE 128-bit constant that can be loaded into a VSX
!           register with the 'lxvkq' instruction.
  
!      'G'
            A floating point constant that can be loaded into a register
            with one instruction per word.
  
!      'H'
            A floating point constant that can be loaded into a register
            using three instructions.
  
!      'm'
!           A memory operand.  Normally, 'm' does not allow addresses that
!           update the base register.  If the '<' 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' as a
            placeholder for the "update" flag in the corresponding load or
            store instruction.  For example:
  
--- 24029,25104 ----
       ranges accepted by particular instruction encodings.  Refer to the
       source code for details.
  
! _Epiphany--‘config/epiphany/constraints.md’_
!      ‘U16’
            An unsigned 16-bit constant.
  
!      ‘K’
            An unsigned 5-bit constant.
  
!      ‘L’
            A signed 11-bit constant.
  
!      ‘Cm1’
!           A signed 11-bit constant added to −1.  Can only match when the
!           ‘-m1reg-REG’ option is active.
  
!      ‘Cl1’
!           Left-shift of −1, i.e., a bit mask with a block of leading
            ones, the rest being a block of trailing zeroes.  Can only
!           match when the ‘-m1reg-REG’ option is active.
  
!      ‘Cr1’
!           Right-shift of −1, i.e., a bit mask with a trailing block of
            ones, the rest being zeroes.  Or to put it another way, one
            less than a power of two.  Can only match when the
!           ‘-m1reg-REG’ option is active.
  
!      ‘Cal’
!           Constant for arithmetic/logical operations.  This is like ‘i’,
            except that for position independent code, no symbols /
            expressions needing relocations are allowed.
  
!      ‘Csy’
            Symbolic constant for call/jump instruction.
  
!      ‘Rcs’
            The register class usable in short insns.  This is a register
            class constraint, and can thus drive register allocation.
!           This constraint won't match unless ‘-mprefer-short-insn-regs’
            is in effect.
  
!      ‘Rsc’
            The register class of registers that can be used to hold a
            sibcall call address.  I.e., a caller-saved register.
  
!      ‘Rct’
            Core control register class.
  
!      ‘Rgs’
            The register group usable in short insns.  This constraint
            does not use a register class, so that it only passively
            matches suitable registers, and doesn't drive register
            allocation.
  
!      ‘Car’
            Constant suitable for the addsi3_r pattern.  This is a valid
            offset For byte, halfword, or word addressing.
  
!      ‘Rra’
            Matches the return address if it can be replaced with the link
            register.
  
!      ‘Rcc’
            Matches the integer condition code register.
  
!      ‘Sra’
            Matches the return address if it is in a stack slot.
  
!      ‘Cfm’
            Matches control register values to switch fp mode, which are
!           encapsulated in ‘UNSPEC_FP_MODE’.
  
! _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.
  
! _FT32--‘config/ft32/constraints.md’_
!      ‘A’
            An absolute address
  
!      ‘B’
            An offset address
  
!      ‘W’
            A register indirect memory operand
  
!      ‘e’
            An offset address.
  
!      ‘f’
            An offset address.
  
!      ‘O’
            The constant zero or one
  
!      ‘I’
!           A 16-bit signed constant (−32768 ... 32767)
  
!      ‘w’
            A bitfield mask suitable for bext or bins
  
!      ‘x’
            An inverted bitfield mask suitable for bext or bins
  
!      ‘L’
            A 16-bit unsigned constant, multiple of 4 (0 ... 65532)
  
!      ‘S’
!           A 20-bit signed constant (−524288 ... 524287)
  
!      ‘b’
            A constant for a bitfield width (1 ... 16)
  
!      ‘KA’
!           A 10-bit signed constant (−512 ... 511)
  
! _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
  
! _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 ‘>’.
  
! _M32C--‘config/m32c/m32c.cc’_
!      ‘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
  
! _LoongArch--‘config/loongarch/constraints.md’_
!      ‘f’
            A floating-point register (if available).
!      ‘k’
            A memory operand whose address is formed by a base register
            and (optionally scaled) index register.
!      ‘l’
            A signed 16-bit constant.
!      ‘m’
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as ‘st.w’ and ‘ld.w’.
!      ‘I’
            A signed 12-bit constant (for arithmetic instructions).
!      ‘K’
            An unsigned 12-bit constant (for logic instructions).
!      ‘ZB’
            An address that is held in a general-purpose register.  The
            offset is zero.
!      ‘ZC’
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as ‘ll.w’ and ‘sc.w’.
  
! _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’
!           A general-purpose register.  This is equivalent to ‘r’ unless
            generating MIPS16 code, in which case the MIPS16 register set
            is used.
  
!      ‘f’
            A floating-point register (if available).
  
!      ‘h’
!           Formerly the ‘hi’ register.  This constraint is no longer
            supported.
  
!      ‘l’
!           The ‘lo’ register.  Use this register to store values that are
            no bigger than a word.
  
!      ‘x’
!           The concatenated ‘hi’ and ‘lo’ registers.  Use this register
            to store doubleword values.
  
!      ‘c’
            A register suitable for use in an indirect jump.  This will
!           always be ‘$25’ for ‘-mabicalls’.
  
!      ‘v’
!           Register ‘$3’.  Do not use this constraint in new code; it is
            retained only for compatibility with glibc.
  
!      ‘y’
!           Equivalent to ‘r’; retained for backwards compatibility.
  
!      ‘z’
            A floating-point condition code register.
  
!      ‘I’
            A signed 16-bit constant (for arithmetic instructions).
  
!      ‘J’
            Integer zero.
  
!      ‘K’
            An unsigned 16-bit constant (for logic instructions).
  
!      ‘L’
            A signed 32-bit constant in which the lower 16 bits are zero.
!           Such constants can be loaded using ‘lui’.
  
!      ‘M’
!           A constant that cannot be loaded using ‘lui’, ‘addiu’ or
!           ‘ori’.
  
!      ‘N’
!           A constant in the range −65535 to −1 (inclusive).
  
!      ‘O’
            A signed 15-bit constant.
  
!      ‘P’
            A constant in the range 1 to 65535 (inclusive).
  
!      ‘G’
            Floating-point zero.
  
!      ‘R’
            An address that can be used in a non-macro load or store.
  
!      ‘ZC’
            A memory operand whose address is formed by a base register
            and offset that is suitable for use in instructions with the
!           same addressing mode as ‘ll’ and ‘sc’.
  
!      ‘ZD’
!           An address suitable for a ‘prefetch’ instruction, or for any
!           other instruction with the same addressing mode as ‘prefetch’.
  
! _Motorola 680x0--‘config/m68k/constraints.md’_
!      ‘a’
            Address register
  
!      ‘d’
            Data register
  
!      ‘f’
            68881 floating-point register, if available
  
!      ‘I’
            Integer in the range 1 to 8
  
!      ‘J’
            16-bit signed number
  
!      ‘K’
            Signed number whose magnitude is greater than 0x80
  
!      ‘L’
!           Integer in the range −8 to −1
  
!      ‘M’
            Signed number whose magnitude is greater than 0x100
  
!      ‘N’
            Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate
  
!      ‘O’
            16 (for rotate using swap)
  
!      ‘P’
            Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate
  
!      ‘R’
            Numbers that mov3q can handle
  
!      ‘G’
            Floating point constant that is not a 68881 constant
  
!      ‘S’
            Operands that satisfy 'm' when -mpcrel is in effect
  
!      ‘T’
            Operands that satisfy 's' when -mpcrel is not in effect
  
!      ‘Q’
            Address register indirect addressing mode
  
!      ‘U’
            Register offset addressing
  
!      ‘W’
            const_call_operand
  
!      ‘Cs’
            symbol_ref or const
  
!      ‘Ci’
            const_int
  
!      ‘C0’
            const_int 0
  
!      ‘Cj’
            Range of signed numbers that don't fit in 16 bits
  
!      ‘Cmvq’
            Integers valid for mvq
  
!      ‘Capsw’
            Integers valid for a moveq followed by a swap
  
!      ‘Cmvz’
            Integers valid for mvz
  
!      ‘Cmvs’
            Integers valid for mvs
  
!      ‘Ap’
            push_operand
  
!      ‘Ac’
            Non-register operands allowed in clr
  
! _Moxie--‘config/moxie/constraints.md’_
!      ‘A’
            An absolute address
  
!      ‘B’
            An offset address
  
!      ‘W’
            A register indirect memory operand
  
!      ‘I’
            A constant in the range of 0 to 255.
  
!      ‘N’
!           A constant in the range of 0 to −255.
  
! _MSP430-‘config/msp430/constraints.md’_
  
!      ‘R12’
            Register R12.
  
!      ‘R13’
            Register R13.
  
!      ‘K’
            Integer constant 1.
  
!      ‘L’
            Integer constant -1^20..1^19.
  
!      ‘M’
            Integer constant 1-4.
  
!      ‘Ya’
            Memory references which do not require an extended MOVX
            instruction.
  
!      ‘Yl’
            Memory reference, labels only.
  
!      ‘Ys’
            Memory reference, stack only.
  
! _NDS32--‘config/nds32/constraints.md’_
!      ‘w’
            LOW register class $r0 to $r7 constraint for V3/V3M ISA.
!      ‘l’
            LOW register class $r0 to $r7.
!      ‘d’
            MIDDLE register class $r0 to $r11, $r16 to $r19.
!      ‘h’
            HIGH register class $r12 to $r14, $r20 to $r31.
!      ‘t’
            Temporary assist register $ta (i.e. $r15).
!      ‘k’
            Stack register $sp.
!      ‘Iu03’
            Unsigned immediate 3-bit value.
!      ‘In03’
!           Negative immediate 3-bit value in the range of −7-0.
!      ‘Iu04’
            Unsigned immediate 4-bit value.
!      ‘Is05’
            Signed immediate 5-bit value.
!      ‘Iu05’
            Unsigned immediate 5-bit value.
!      ‘In05’
!           Negative immediate 5-bit value in the range of −31-0.
!      ‘Ip05’
            Unsigned immediate 5-bit value for movpi45 instruction with
            range 16-47.
!      ‘Iu06’
            Unsigned immediate 6-bit value constraint for addri36.sp
            instruction.
!      ‘Iu08’
            Unsigned immediate 8-bit value.
!      ‘Iu09’
            Unsigned immediate 9-bit value.
!      ‘Is10’
            Signed immediate 10-bit value.
!      ‘Is11’
            Signed immediate 11-bit value.
!      ‘Is15’
            Signed immediate 15-bit value.
!      ‘Iu15’
            Unsigned immediate 15-bit value.
!      ‘Ic15’
            A constant which is not in the range of imm15u but ok for bclr
            instruction.
!      ‘Ie15’
            A constant which is not in the range of imm15u but ok for bset
            instruction.
!      ‘It15’
            A constant which is not in the range of imm15u but ok for btgl
            instruction.
!      ‘Ii15’
            A constant whose compliment value is in the range of imm15u
            and ok for bitci instruction.
!      ‘Is16’
            Signed immediate 16-bit value.
!      ‘Is17’
            Signed immediate 17-bit value.
!      ‘Is19’
            Signed immediate 19-bit value.
!      ‘Is20’
            Signed immediate 20-bit value.
!      ‘Ihig’
            The immediate value that can be simply set high 20-bit.
!      ‘Izeb’
            The immediate value 0xff.
!      ‘Izeh’
            The immediate value 0xffff.
!      ‘Ixls’
            The immediate value 0x01.
!      ‘Ix11’
            The immediate value 0x7ff.
!      ‘Ibms’
            The immediate value with power of 2.
!      ‘Ifex’
            The immediate value with power of 2 minus 1.
!      ‘U33’
            Memory constraint for 333 format.
!      ‘U45’
            Memory constraint for 45 format.
!      ‘U37’
            Memory constraint for 37 format.
  
! _Nios II family--‘config/nios2/constraints.md’_
  
!      ‘I’
            Integer that is valid as an immediate operand in an
!           instruction taking a signed 16-bit number.  Range −32768 to
            32767.
  
!      ‘J’
            Integer that is valid as an immediate operand in an
            instruction taking an unsigned 16-bit number.  Range 0 to
            65535.
  
!      ‘K’
            Integer that is valid as an immediate operand in an
            instruction taking only the upper 16-bits of a 32-bit number.
            Range 32-bit numbers with the lower 16-bits being 0.
  
!      ‘L’
            Integer that is valid as an immediate operand for a shift
            instruction.  Range 0 to 31.
  
!      ‘M’
            Integer that is valid as an immediate operand for only the
            value 0.  Can be used in conjunction with the format modifier
!           ‘z’ to use ‘r0’ instead of ‘0’ in the assembly output.
  
!      ‘N’
            Integer that is valid as an immediate operand for a custom
            instruction opcode.  Range 0 to 255.
  
!      ‘P’
            An immediate operand for R2 andchi/andci instructions.
  
!      ‘S’
            Matches immediates which are addresses in the small data
!           section and therefore can be added to ‘gp’ as a 16-bit
            immediate to re-create their 32-bit value.
  
!      ‘U’
            Matches constants suitable as an operand for the rdprs and
            cache instructions.
  
!      ‘v’
            A memory operand suitable for Nios II R2 load/store exclusive
            instructions.
  
!      ‘w’
            A memory operand suitable for load/store IO and cache
            instructions.
  
!      ‘T’
!           A ‘const’ wrapped ‘UNSPEC’ expression, representing a
            supported PIC or TLS relocation.
  
! _OpenRISC--‘config/or1k/constraints.md’_
!      ‘I’
            Integer that is valid as an immediate operand in an
!           instruction taking a signed 16-bit number.  Range −32768 to
            32767.
  
!      ‘K’
            Integer that is valid as an immediate operand in an
            instruction taking an unsigned 16-bit number.  Range 0 to
            65535.
  
!      ‘M’
            Signed 16-bit constant shifted left 16 bits.  (Used with
!           ‘l.movhi’)
  
!      ‘O’
            Zero
  
!      ‘c’
            Register usable for sibcalls.
  
! _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.
  
!      ‘D’
            A memory reference that is encoded within the opcode, but not
            auto-increment or auto-decrement.
  
!      ‘f’
            Any of the floating point registers (AC0 through AC5).
  
!      ‘G’
            Floating point constant 0.
  
!      ‘h’
            Floating point registers AC4 and AC5.  These cannot be loaded
            from/to memory with a single instruction.
  
!      ‘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 0 through 3; 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.
  
! _PowerPC and IBM RS6000--‘config/rs6000/constraints.md’_
!      ‘r’
!           A general purpose register (GPR), ‘r0’...‘r31’.
  
!      ‘b’
!           A base register.  Like ‘r’, but ‘r0’ is not allowed, so
!           ‘r1’...‘r31’.
  
!      ‘f’
!           A floating point register (FPR), ‘f0’...‘f31’.
  
!      ‘d’
!           A floating point register.  This is the same as ‘f’ nowadays;
!           historically ‘f’ was for single-precision and ‘d’ was for
            double-precision floating point.
  
!      ‘v’
!           An Altivec vector register (VR), ‘v0’...‘v31’.
  
!      ‘wa’
!           A VSX register (VSR), ‘vs0’...‘vs63’.  This is either an FPR
!           (‘vs0’...‘vs31’ are ‘f0’...‘f31’) or a VR (‘vs32’...‘vs63’ are
!           ‘v0’...‘v31’).
  
!           When using ‘wa’, you should use the ‘%x’ output modifier, so
            that the correct register number is printed.  For example:
  
                 asm ("xvadddp %x0,%x1,%x2"
                      : "=wa" (v1)
                      : "wa" (v2), "wa" (v3));
  
!           You should not use ‘%x’ for ‘v’ operands:
  
                 asm ("xsaddqp %0,%1,%2"
                      : "=v" (v1)
                      : "v" (v2), "v" (v3));
  
!      ‘h’
!           A special register (‘vrsave’, ‘ctr’, or ‘lr’).
  
!      ‘c’
!           The count register, ‘ctr’.
  
!      ‘l’
!           The link register, ‘lr’.
  
!      ‘x’
!           Condition register field 0, ‘cr0’.
  
!      ‘y’
!           Any condition register field, ‘cr0’...‘cr7’.
  
!      ‘z’
!           The carry bit, ‘XER[CA]’.
  
!      ‘we’
!           Like ‘wa’, if ‘-mpower9-vector’ and ‘-m64’ are used;
!           otherwise, ‘NO_REGS’.
  
!      ‘wn’
!           No register (‘NO_REGS’).
  
!      ‘wr’
!           Like ‘r’, if ‘-mpowerpc64’ is used; otherwise, ‘NO_REGS’.
  
!      ‘wx’
!           Like ‘d’, if ‘-mpowerpc-gfxopt’ is used; otherwise, ‘NO_REGS’.
  
!      ‘wA’
!           Like ‘b’, if ‘-mpowerpc64’ is used; otherwise, ‘NO_REGS’.
  
!      ‘wB’
            Signed 5-bit constant integer that can be loaded into an
            Altivec register.
  
!      ‘wE’
            Vector constant that can be loaded with the XXSPLTIB
            instruction.
  
!      ‘wF’
            Memory operand suitable for power8 GPR load fusion.
  
!      ‘wL’
            Int constant that is the element number mfvsrld accesses in a
            vector.
  
!      ‘wM’
            Match vector constant with all 1's if the XXLORC instruction
            is available.
  
!      ‘wO’
            Memory operand suitable for the ISA 3.0 vector d-form
            instructions.
  
!      ‘wQ’
            Memory operand suitable for the load/store quad instructions.
  
!      ‘wS’
            Vector constant that can be loaded with XXSPLTIB & sign
            extension.
  
!      ‘wY’
            A memory operand for a DS-form instruction.
  
!      ‘wZ’
            An indexed or indirect memory operand, ignoring the bottom 4
            bits.
  
!      ‘I’
            A signed 16-bit constant.
  
!      ‘J’
!           An unsigned 16-bit constant shifted left 16 bits (use ‘L’
!           instead for ‘SImode’ constants).
  
!      ‘K’
            An unsigned 16-bit constant.
  
!      ‘L’
            A signed 16-bit constant shifted left 16 bits.
  
!      ‘M’
            An integer constant greater than 31.
  
!      ‘N’
            An exact power of 2.
  
!      ‘O’
            The integer constant zero.
  
!      ‘P’
            A constant whose negation is a signed 16-bit constant.
  
!      ‘eI’
            A signed 34-bit integer constant if prefixed instructions are
            supported.
  
!      ‘eP’
            A scalar floating point constant or a vector constant that can
            be loaded to a VSX register with one prefixed instruction.
  
!      ‘eQ’
            An IEEE 128-bit constant that can be loaded into a VSX
!           register with the ‘lxvkq’ instruction.
  
!      ‘G’
            A floating point constant that can be loaded into a register
            with one instruction per word.
  
!      ‘H’
            A floating point constant that can be loaded into a register
            using three instructions.
  
!      ‘m’
!           A memory operand.  Normally, ‘m’ does not allow addresses that
!           update the base register.  If the ‘<’ 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’ as a
            placeholder for the "update" flag in the corresponding load or
            store instruction.  For example:
  
*************** _PowerPC and IBM RS6000--'config/rs6000/
*** 25111,25648 ****
  
            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'
            A memory operand addressed by just a base register.
  
!      'Y'
            A memory operand for a DQ-form instruction.
  
!      'Z'
            A memory operand accessed with indexed or indirect addressing.
  
!      'R'
            An AIX TOC entry.
  
!      'a'
            An indexed or indirect address.
  
!      'U'
            A V.4 small data reference.
  
!      'W'
            A vector constant that does not require memory.
  
!      'j'
            The zero vector constant.
  
! _PRU--'config/pru/constraints.md'_
!      'I'
            An unsigned 8-bit integer constant.
  
!      'J'
            An unsigned 16-bit integer constant.
  
!      'L'
            An unsigned 5-bit integer constant (for shift counts).
  
!      'T'
            A text segment (program memory) constant label.
  
!      'Z'
            Integer constant zero.
  
! _RL78--'config/rl78/constraints.md'_
  
!      'Int3'
            An integer constant in the range 1 ... 7.
!      'Int8'
            An integer constant in the range 0 ... 255.
!      'J'
!           An integer constant in the range -255 ... 0
!      'K'
            The integer constant 1.
!      'L'
            The integer constant -1.
!      'M'
            The integer constant 0.
!      'N'
            The integer constant 2.
!      'O'
            The integer constant -2.
!      'P'
            An integer constant in the range 1 ... 15.
!      'Qbi'
            The built-in compare types-eq, ne, gtu, ltu, geu, and leu.
!      'Qsc'
            The synthetic compare types-gt, lt, ge, and le.
!      'Wab'
            A memory reference with an absolute address.
!      'Wbc'
!           A memory reference using 'BC' as a base register, with an
            optional offset.
!      'Wca'
!           A memory reference using 'AX', 'BC', 'DE', or 'HL' for the
            address, for calls.
!      'Wcv'
            A memory reference using any 16-bit register pair for the
            address, for calls.
!      'Wd2'
!           A memory reference using 'DE' as a base register, with an
            optional offset.
!      'Wde'
!           A memory reference using 'DE' as a base register, without any
            offset.
!      'Wfr'
            Any memory reference to an address in the far address space.
!      'Wh1'
!           A memory reference using 'HL' as a base register, with an
            optional one-byte offset.
!      'Whb'
!           A memory reference using 'HL' as a base register, with 'B' or
!           'C' as the index register.
!      'Whl'
!           A memory reference using 'HL' as a base register, without any
            offset.
!      'Ws1'
!           A memory reference using 'SP' as a base register, with an
            optional one-byte offset.
!      'Y'
            Any memory reference to an address in the near address space.
!      'A'
!           The 'AX' register.
!      'B'
!           The 'BC' register.
!      'D'
!           The 'DE' register.
!      'R'
!           'A' through 'L' registers.
!      'S'
!           The 'SP' register.
!      'T'
!           The 'HL' register.
!      'Z08W'
!           The 16-bit 'R8' register.
!      'Z10W'
!           The 16-bit 'R10' register.
!      'Zint'
!           The registers reserved for interrupts ('R24' to 'R31').
!      'a'
!           The 'A' register.
!      'b'
!           The 'B' register.
!      'c'
!           The 'C' register.
!      'd'
!           The 'D' register.
!      'e'
!           The 'E' register.
!      'h'
!           The 'H' register.
!      'l'
!           The 'L' register.
!      'v'
            The virtual registers.
!      'w'
!           The 'PSW' register.
!      'x'
!           The 'X' register.
  
! _RISC-V--'config/riscv/constraints.md'_
  
!      'f'
            A floating-point register (if available).
  
!      'I'
            An I-type 12-bit signed immediate.
  
!      'J'
            Integer zero.
  
!      'K'
            A 5-bit unsigned immediate for CSR access instructions.
  
!      'A'
            An address that is held in a general-purpose register.
  
!      'S'
            A constraint that matches an absolute symbolic address.
  
!      'vr'
            A vector register (if available)..
  
!      'vd'
            A vector register, excluding v0 (if available).
  
!      'vm'
            A vector register, only v0 (if available).
  
! _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.
  
! _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.
  
! _SPARC--'config/sparc/sparc.h'_
!      'f'
            Floating-point register on the SPARC-V8 architecture and lower
            floating-point register on the SPARC-V9 architecture.
  
!      'e'
!           Floating-point register.  It is equivalent to 'f' on the
            SPARC-V8 architecture and contains both lower and upper
            floating-point registers on the SPARC-V9 architecture.
  
!      'c'
            Floating-point condition code register.
  
!      'd'
            Lower floating-point register.  It is only valid on the
            SPARC-V9 architecture when the Visual Instruction Set is
            available.
  
!      'b'
            Floating-point register.  It is only valid on the SPARC-V9
            architecture when the Visual Instruction Set is available.
  
!      'h'
            64-bit global or out register for the SPARC-V8+ architecture.
  
!      'C'
            The constant all-ones, for floating-point.
  
!      'A'
            Signed 5-bit constant
  
!      'D'
            A vector constant
  
!      'I'
            Signed 13-bit constant
  
!      'J'
            Zero
  
!      'K'
            32-bit constant with the low 12 bits clear (a constant that
!           can be loaded with the 'sethi' instruction)
  
!      'L'
!           A constant in the range supported by 'movcc' instructions
            (11-bit signed immediate)
  
!      'M'
!           A constant in the range supported by 'movrcc' instructions
            (10-bit signed immediate)
  
!      'N'
!           Same as 'K', except that it verifies that bits that are not in
            the lower 32-bit range are all zero.  Must be used instead of
!           'K' for modes wider than 'SImode'
  
!      'O'
            The constant 4096
  
!      'G'
            Floating-point zero
  
!      'H'
            Signed 13-bit constant, sign-extended to 32 or 64 bits
  
!      'P'
            The constant -1
  
!      'Q'
            Floating-point constant whose integral representation can be
            moved into an integer register using a single sethi
            instruction
  
!      'R'
            Floating-point constant whose integral representation can be
            moved into an integer register using a single mov instruction
  
!      'S'
            Floating-point constant whose integral representation can be
            moved into an integer register using a high/lo_sum instruction
            sequence
  
!      'T'
            Memory address aligned to an 8-byte boundary
  
!      'U'
            Even register
  
!      'W'
!           Memory address for 'e' constraint registers
  
!      'w'
            Memory address with only a base register
  
!      'Y'
            Vector zero
  
! _TI C6X family--'config/c6x/constraints.md'_
!      'a'
            Register file A (A0-A31).
  
!      'b'
            Register file B (B0-B31).
  
!      'A'
            Predicate registers in register file A (A0-A2 on C64X and
            higher, A1 and A2 otherwise).
  
!      'B'
            Predicate registers in register file B (B0-B2).
  
!      'C'
            A call-used register in register file B (B0-B9, B16-B31).
  
!      'Da'
            Register file A, excluding predicate registers (A3-A31, plus
            A0 if not C64X or higher).
  
!      'Db'
            Register file B, excluding predicate registers (B3-B31).
  
!      'Iu4'
            Integer constant in the range 0 ... 15.
  
!      'Iu5'
            Integer constant in the range 0 ... 31.
  
!      'In5'
!           Integer constant in the range -31 ... 0.
  
!      'Is5'
!           Integer constant in the range -16 ... 15.
  
!      'I5x'
            Integer constant that can be the operand of an ADDA or a SUBA
            insn.
  
!      'IuB'
            Integer constant in the range 0 ... 65535.
  
!      'IsB'
!           Integer constant in the range -32768 ... 32767.
  
!      'IsC'
            Integer constant in the range -2^{20} ... 2^{20} - 1.
  
!      'Jc'
            Integer constant that is a valid mask for the clr instruction.
  
!      'Js'
            Integer constant that is a valid mask for the set instruction.
  
!      'Q'
            Memory location with A base register.
  
!      'R'
            Memory location with B base register.
  
!      'S0'
            On C64x+ targets, a GP-relative small data reference.
  
!      'S1'
!           Any kind of 'SYMBOL_REF', for use in a call address.
  
!      'Si'
            Any kind of immediate operand, unless it matches the S0
            constraint.
  
!      'T'
            Memory location with B base register, but not using a long
            offset.
  
!      'W'
            A memory operand with an address that cannot be used in an
            unaligned access.
  
!      'Z'
            Register B14 (aka DP).
  
! _Visium--'config/visium/constraints.md'_
!      'b'
!           EAM register 'mdb'
  
!      'c'
!           EAM register 'mdc'
  
!      'f'
            Floating point register
  
!      'k'
            Register for sibcall optimization
  
!      'l'
!           General register, but not 'r29', 'r30' and 'r31'
  
!      't'
!           Register 'r1'
  
!      'u'
!           Register 'r2'
  
!      'v'
!           Register 'r3'
  
!      'G'
            Floating-point constant 0.0
  
!      'J'
            Integer constant in the range 0 ..  65535 (16-bit immediate)
  
!      'K'
            Integer constant in the range 1 ..  31 (5-bit immediate)
  
!      'L'
!           Integer constant in the range -65535 ..  -1 (16-bit negative
            immediate)
  
!      'M'
!           Integer constant -1
  
!      'O'
            Integer constant 0
  
!      'P'
            Integer constant 32
  
! _x86 family--'config/i386/constraints.md'_
!      'R'
            Legacy register--the eight integer registers available on all
!           i386 processors ('a', 'b', 'c', 'd', 'si', 'di', 'bp', 'sp').
  
!      'q'
!           Any register accessible as 'Rl'.  In 32-bit mode, 'a', 'b',
!           'c', and 'd'; in 64-bit mode, any integer register.
  
!      'Q'
!           Any register accessible as 'Rh': 'a', 'b', 'c', and 'd'.
  
!      'l'
            Any register that can be used as the index in a base+index
            memory access: that is, any general register except the stack
            pointer.
  
!      'a'
!           The 'a' register.
  
!      'b'
!           The 'b' register.
  
!      'c'
!           The 'c' register.
  
!      'd'
!           The 'd' register.
  
!      'S'
!           The 'si' register.
  
!      'D'
!           The 'di' register.
  
!      'A'
!           The 'a' and 'd' registers.  This class is used for
!           instructions that return double word results in the 'ax:dx'
            register pair.  Single word values will be allocated either in
!           'ax' or 'dx'.  For example on i386 the following implements
!           'rdtsc':
  
                 unsigned long long rdtsc (void)
                 {
--- 25110,25647 ----
  
            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’
            A memory operand addressed by just a base register.
  
!      ‘Y’
            A memory operand for a DQ-form instruction.
  
!      ‘Z’
            A memory operand accessed with indexed or indirect addressing.
  
!      ‘R’
            An AIX TOC entry.
  
!      ‘a’
            An indexed or indirect address.
  
!      ‘U’
            A V.4 small data reference.
  
!      ‘W’
            A vector constant that does not require memory.
  
!      ‘j’
            The zero vector constant.
  
! _PRU--‘config/pru/constraints.md’_
!      ‘I’
            An unsigned 8-bit integer constant.
  
!      ‘J’
            An unsigned 16-bit integer constant.
  
!      ‘L’
            An unsigned 5-bit integer constant (for shift counts).
  
!      ‘T’
            A text segment (program memory) constant label.
  
!      ‘Z’
            Integer constant zero.
  
! _RL78--‘config/rl78/constraints.md’_
  
!      ‘Int3’
            An integer constant in the range 1 ... 7.
!      ‘Int8’
            An integer constant in the range 0 ... 255.
!      ‘J’
!           An integer constant in the range −255 ... 0
!      ‘K’
            The integer constant 1.
!      ‘L’
            The integer constant -1.
!      ‘M’
            The integer constant 0.
!      ‘N’
            The integer constant 2.
!      ‘O’
            The integer constant -2.
!      ‘P’
            An integer constant in the range 1 ... 15.
!      ‘Qbi’
            The built-in compare types-eq, ne, gtu, ltu, geu, and leu.
!      ‘Qsc’
            The synthetic compare types-gt, lt, ge, and le.
!      ‘Wab’
            A memory reference with an absolute address.
!      ‘Wbc’
!           A memory reference using ‘BC’ as a base register, with an
            optional offset.
!      ‘Wca’
!           A memory reference using ‘AX’, ‘BC’, ‘DE’, or ‘HL’ for the
            address, for calls.
!      ‘Wcv’
            A memory reference using any 16-bit register pair for the
            address, for calls.
!      ‘Wd2’
!           A memory reference using ‘DE’ as a base register, with an
            optional offset.
!      ‘Wde’
!           A memory reference using ‘DE’ as a base register, without any
            offset.
!      ‘Wfr’
            Any memory reference to an address in the far address space.
!      ‘Wh1’
!           A memory reference using ‘HL’ as a base register, with an
            optional one-byte offset.
!      ‘Whb’
!           A memory reference using ‘HL’ as a base register, with ‘B’ or
!           ‘C’ as the index register.
!      ‘Whl’
!           A memory reference using ‘HL’ as a base register, without any
            offset.
!      ‘Ws1’
!           A memory reference using ‘SP’ as a base register, with an
            optional one-byte offset.
!      ‘Y’
            Any memory reference to an address in the near address space.
!      ‘A’
!           The ‘AX’ register.
!      ‘B’
!           The ‘BC’ register.
!      ‘D’
!           The ‘DE’ register.
!      ‘R’
!           ‘A’ through ‘L’ registers.
!      ‘S’
!           The ‘SP’ register.
!      ‘T’
!           The ‘HL’ register.
!      ‘Z08W’
!           The 16-bit ‘R8’ register.
!      ‘Z10W’
!           The 16-bit ‘R10’ register.
!      ‘Zint’
!           The registers reserved for interrupts (‘R24’ to ‘R31’).
!      ‘a’
!           The ‘A’ register.
!      ‘b’
!           The ‘B’ register.
!      ‘c’
!           The ‘C’ register.
!      ‘d’
!           The ‘D’ register.
!      ‘e’
!           The ‘E’ register.
!      ‘h’
!           The ‘H’ register.
!      ‘l’
!           The ‘L’ register.
!      ‘v’
            The virtual registers.
!      ‘w’
!           The ‘PSW’ register.
!      ‘x’
!           The ‘X’ register.
  
! _RISC-V--‘config/riscv/constraints.md’_
  
!      ‘f’
            A floating-point register (if available).
  
!      ‘I’
            An I-type 12-bit signed immediate.
  
!      ‘J’
            Integer zero.
  
!      ‘K’
            A 5-bit unsigned immediate for CSR access instructions.
  
!      ‘A’
            An address that is held in a general-purpose register.
  
!      ‘S’
            A constraint that matches an absolute symbolic address.
  
!      ‘vr’
            A vector register (if available)..
  
!      ‘vd’
            A vector register, excluding v0 (if available).
  
!      ‘vm’
            A vector register, only v0 (if available).
  
! _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.
  
! _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.
  
! _SPARC--‘config/sparc/sparc.h’_
!      ‘f’
            Floating-point register on the SPARC-V8 architecture and lower
            floating-point register on the SPARC-V9 architecture.
  
!      ‘e’
!           Floating-point register.  It is equivalent to ‘f’ on the
            SPARC-V8 architecture and contains both lower and upper
            floating-point registers on the SPARC-V9 architecture.
  
!      ‘c’
            Floating-point condition code register.
  
!      ‘d’
            Lower floating-point register.  It is only valid on the
            SPARC-V9 architecture when the Visual Instruction Set is
            available.
  
!      ‘b’
            Floating-point register.  It is only valid on the SPARC-V9
            architecture when the Visual Instruction Set is available.
  
!      ‘h’
            64-bit global or out register for the SPARC-V8+ architecture.
  
!      ‘C’
            The constant all-ones, for floating-point.
  
!      ‘A’
            Signed 5-bit constant
  
!      ‘D’
            A vector constant
  
!      ‘I’
            Signed 13-bit constant
  
!      ‘J’
            Zero
  
!      ‘K’
            32-bit constant with the low 12 bits clear (a constant that
!           can be loaded with the ‘sethi’ instruction)
  
!      ‘L’
!           A constant in the range supported by ‘movcc’ instructions
            (11-bit signed immediate)
  
!      ‘M’
!           A constant in the range supported by ‘movrcc’ instructions
            (10-bit signed immediate)
  
!      ‘N’
!           Same as ‘K’, except that it verifies that bits that are not in
            the lower 32-bit range are all zero.  Must be used instead of
!           ‘K’ for modes wider than ‘SImode’
  
!      ‘O’
            The constant 4096
  
!      ‘G’
            Floating-point zero
  
!      ‘H’
            Signed 13-bit constant, sign-extended to 32 or 64 bits
  
!      ‘P’
            The constant -1
  
!      ‘Q’
            Floating-point constant whose integral representation can be
            moved into an integer register using a single sethi
            instruction
  
!      ‘R’
            Floating-point constant whose integral representation can be
            moved into an integer register using a single mov instruction
  
!      ‘S’
            Floating-point constant whose integral representation can be
            moved into an integer register using a high/lo_sum instruction
            sequence
  
!      ‘T’
            Memory address aligned to an 8-byte boundary
  
!      ‘U’
            Even register
  
!      ‘W’
!           Memory address for ‘e’ constraint registers
  
!      ‘w’
            Memory address with only a base register
  
!      ‘Y’
            Vector zero
  
! _TI C6X family--‘config/c6x/constraints.md’_
!      ‘a’
            Register file A (A0-A31).
  
!      ‘b’
            Register file B (B0-B31).
  
!      ‘A’
            Predicate registers in register file A (A0-A2 on C64X and
            higher, A1 and A2 otherwise).
  
!      ‘B’
            Predicate registers in register file B (B0-B2).
  
!      ‘C’
            A call-used register in register file B (B0-B9, B16-B31).
  
!      ‘Da’
            Register file A, excluding predicate registers (A3-A31, plus
            A0 if not C64X or higher).
  
!      ‘Db’
            Register file B, excluding predicate registers (B3-B31).
  
!      ‘Iu4’
            Integer constant in the range 0 ... 15.
  
!      ‘Iu5’
            Integer constant in the range 0 ... 31.
  
!      ‘In5’
!           Integer constant in the range −31 ... 0.
  
!      ‘Is5’
!           Integer constant in the range −16 ... 15.
  
!      ‘I5x’
            Integer constant that can be the operand of an ADDA or a SUBA
            insn.
  
!      ‘IuB’
            Integer constant in the range 0 ... 65535.
  
!      ‘IsB’
!           Integer constant in the range −32768 ... 32767.
  
!      ‘IsC’
            Integer constant in the range -2^{20} ... 2^{20} - 1.
  
!      ‘Jc’
            Integer constant that is a valid mask for the clr instruction.
  
!      ‘Js’
            Integer constant that is a valid mask for the set instruction.
  
!      ‘Q’
            Memory location with A base register.
  
!      ‘R’
            Memory location with B base register.
  
!      ‘S0’
            On C64x+ targets, a GP-relative small data reference.
  
!      ‘S1’
!           Any kind of ‘SYMBOL_REF’, for use in a call address.
  
!      ‘Si’
            Any kind of immediate operand, unless it matches the S0
            constraint.
  
!      ‘T’
            Memory location with B base register, but not using a long
            offset.
  
!      ‘W’
            A memory operand with an address that cannot be used in an
            unaligned access.
  
!      ‘Z’
            Register B14 (aka DP).
  
! _Visium--‘config/visium/constraints.md’_
!      ‘b’
!           EAM register ‘mdb’
  
!      ‘c’
!           EAM register ‘mdc’
  
!      ‘f’
            Floating point register
  
!      ‘k’
            Register for sibcall optimization
  
!      ‘l’
!           General register, but not ‘r29’, ‘r30’ and ‘r31’
  
!      ‘t’
!           Register ‘r1’
  
!      ‘u’
!           Register ‘r2’
  
!      ‘v’
!           Register ‘r3’
  
!      ‘G’
            Floating-point constant 0.0
  
!      ‘J’
            Integer constant in the range 0 ..  65535 (16-bit immediate)
  
!      ‘K’
            Integer constant in the range 1 ..  31 (5-bit immediate)
  
!      ‘L’
!           Integer constant in the range −65535 ..  −1 (16-bit negative
            immediate)
  
!      ‘M’
!           Integer constant −1
  
!      ‘O’
            Integer constant 0
  
!      ‘P’
            Integer constant 32
  
! _x86 family--‘config/i386/constraints.md’_
!      ‘R’
            Legacy register--the eight integer registers available on all
!           i386 processors (‘a’, ‘b’, ‘c’, ‘d’, ‘si’, ‘di’, ‘bp’, ‘sp’).
  
!      ‘q’
!           Any register accessible as ‘Rl’.  In 32-bit mode, ‘a’, ‘b’,
!           ‘c’, and ‘d’; in 64-bit mode, any integer register.
  
!      ‘Q’
!           Any register accessible as ‘Rh’: ‘a’, ‘b’, ‘c’, and ‘d’.
  
!      ‘l’
            Any register that can be used as the index in a base+index
            memory access: that is, any general register except the stack
            pointer.
  
!      ‘a’
!           The ‘a’ register.
  
!      ‘b’
!           The ‘b’ register.
  
!      ‘c’
!           The ‘c’ register.
  
!      ‘d’
!           The ‘d’ register.
  
!      ‘S’
!           The ‘si’ register.
  
!      ‘D’
!           The ‘di’ register.
  
!      ‘A’
!           The ‘a’ and ‘d’ registers.  This class is used for
!           instructions that return double word results in the ‘ax:dx’
            register pair.  Single word values will be allocated either in
!           ‘ax’ or ‘dx’.  For example on i386 the following implements
!           ‘rdtsc’:
  
                 unsigned long long rdtsc (void)
                 {
*************** _x86 family--'config/i386/constraints.md
*** 25652,25658 ****
                 }
  
            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)
--- 25651,25657 ----
                 }
  
            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)
*************** _x86 family--'config/i386/constraints.md
*** 25662,25971 ****
                   return ((unsigned long long)tickh << 32)|tickl;
                 }
  
!      'U'
            The call-clobbered integer registers.
  
!      '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)').
  
!      'Yk'
            Any mask register that can be used as a predicate, i.e.
!           'k1-k7'.
  
!      'k'
            Any mask register.
  
!      'y'
            Any MMX register.
  
!      'x'
            Any SSE register.
  
!      'v'
!           Any EVEX encodable SSE register ('%xmm0-%xmm31').
  
!      'w'
            Any bound register.
  
!      'Yz'
!           First SSE register ('%xmm0').
  
!      'Yi'
            Any SSE register, when SSE2 and inter-unit moves are enabled.
  
!      'Yj'
            Any SSE register, when SSE2 and inter-unit moves from vector
            registers are enabled.
  
!      'Ym'
            Any MMX register, when inter-unit moves are enabled.
  
!      'Yn'
            Any MMX register, when inter-unit moves from vector registers
            are enabled.
  
!      'Yp'
!           Any integer register when 'TARGET_PARTIAL_REG_STALL' is
            disabled.
  
!      'Ya'
!           Any integer register when zero extensions with 'AND' are
            disabled.
  
!      'Yb'
            Any register that can be used as the GOT base when calling
!           '___tls_get_addr': that is, any general register except 'a'
!           and 'sp' registers, for '-fno-plt' if linker supports it.
!           Otherwise, 'b' register.
  
!      'Yf'
            Any x87 register when 80387 floating-point arithmetic is
            enabled.
  
!      'Yr'
            Lower SSE register when avoiding REX prefix and all SSE
            registers otherwise.
  
!      'Yv'
            For AVX512VL, any EVEX-encodable SSE register
!           ('%xmm0-%xmm31'), otherwise any SSE register.
  
!      'Yh'
            Any EVEX-encodable SSE register, that has number factor of
            four.
  
!      'Bf'
            Flags register operand.
  
!      'Bg'
            GOT memory operand.
  
!      'Bm'
            Vector memory operand.
  
!      'Bc'
            Constant memory operand.
  
!      'Bn'
            Memory operand without REX prefix.
  
!      'Bs'
            Sibcall memory operand.
  
!      'Bw'
            Call memory operand.
  
!      'Bz'
            Constant call address operand.
  
!      'BC'
            SSE constant -1 operand.
  
!      'I'
            Integer constant in the range 0 ... 31, for 32-bit shifts.
  
!      'J'
            Integer constant in the range 0 ... 63, for 64-bit shifts.
  
!      'K'
            Signed 8-bit integer constant.
  
!      'L'
!           '0xFF' or '0xFFFF', for andsi as a zero-extending move.
  
!      'M'
!           0, 1, 2, or 3 (shifts for the 'lea' instruction).
  
!      'N'
!           Unsigned 8-bit integer constant (for 'in' and 'out'
            instructions).
  
!      'O'
            Integer constant in the range 0 ... 127, for 128-bit shifts.
  
!      'G'
            Standard 80387 floating point constant.
  
!      'C'
            SSE constant zero operand.
  
!      'e'
            32-bit signed integer constant, or a symbolic reference known
            to fit that range (for immediate operands in sign-extending
            x86-64 instructions).
  
!      'We'
            32-bit signed integer constant, or a symbolic reference known
            to fit that range (for sign-extending conversion operations
!           that require non-'VOIDmode' immediate operands).
  
!      'Wz'
            32-bit unsigned integer constant, or a symbolic reference
            known to fit that range (for zero-extending conversion
!           operations that require non-'VOIDmode' immediate operands).
  
!      'Wd'
            128-bit integer constant where both the high and low 64-bit
!           word satisfy the 'e' constraint.
  
!      'Z'
            32-bit unsigned integer constant, or a symbolic reference
            known to fit that range (for immediate operands in
            zero-extending x86-64 instructions).
  
!      'Tv'
            VSIB address operand.
  
!      'Ts'
            Address operand without segment register.
  
! _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: gccint.info,  Node: Disable Insn Alternatives,  Next: Define Constraints,  Prev: Machine Constraints,  Up: Constraints
  
! 17.8.6 Disable insn alternatives using the 'enabled' attribute
  --------------------------------------------------------------
  
  There are three insn attributes that may be used to selectively disable
  instruction alternatives:
  
! 'enabled'
       Says whether an alternative is available on the current subtarget.
  
! 'preferred_for_size'
       Says whether an enabled alternative should be used in code that is
       optimized for size.
  
! 'preferred_for_speed'
       Says whether an enabled alternative should be used in code that is
       optimized for speed.
  
!  All these attributes should use '(const_int 1)' to allow an alternative
! or '(const_int 0)' to disallow it.  The attributes must be a static
  property of the subtarget; they cannot for example depend on the current
  operands, on the current optimization level, on the location of the insn
  within the body of a loop, on whether register allocation has finished,
  or on the current compiler pass.
  
!  The 'enabled' attribute is a correctness property.  It tells GCC to act
  as though the disabled alternatives were never defined in the first
  place.  This is useful when adding new instructions to an existing
  pattern in cases where the new instructions are only available for
! certain cpu architecture levels (typically mapped to the '-march='
  command-line option).
  
!  In contrast, the 'preferred_for_size' and 'preferred_for_speed'
  attributes are strong optimization hints rather than correctness
! properties.  'preferred_for_size' tells GCC which alternatives to
  consider when adding or modifying an instruction that GCC wants to
! optimize for size.  'preferred_for_speed' does the same thing for speed.
  Note that things like code motion can lead to cases where code optimized
  for size uses alternatives that are not preferred for size, and
  similarly for speed.
  
!  Although 'define_insn's can in principle specify the 'enabled'
  attribute directly, it is often clearer to have subsiduary attributes
! for each architectural feature of interest.  The 'define_insn's can then
  use these subsiduary attributes to say which alternatives require which
! features.  The example below does this for 'cpu_facility'.
  
   E.g.  the following two patterns could easily be merged using the
! 'enabled' attribute:
  
  
       (define_insn "*movdi_old"
--- 25661,25970 ----
                   return ((unsigned long long)tickh << 32)|tickl;
                 }
  
!      ‘U’
            The call-clobbered integer registers.
  
!      ‘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)’).
  
!      ‘Yk’
            Any mask register that can be used as a predicate, i.e.
!           ‘k1-k7’.
  
!      ‘k’
            Any mask register.
  
!      ‘y’
            Any MMX register.
  
!      ‘x’
            Any SSE register.
  
!      ‘v’
!           Any EVEX encodable SSE register (‘%xmm0-%xmm31’).
  
!      ‘w’
            Any bound register.
  
!      ‘Yz’
!           First SSE register (‘%xmm0’).
  
!      ‘Yi’
            Any SSE register, when SSE2 and inter-unit moves are enabled.
  
!      ‘Yj’
            Any SSE register, when SSE2 and inter-unit moves from vector
            registers are enabled.
  
!      ‘Ym’
            Any MMX register, when inter-unit moves are enabled.
  
!      ‘Yn’
            Any MMX register, when inter-unit moves from vector registers
            are enabled.
  
!      ‘Yp’
!           Any integer register when ‘TARGET_PARTIAL_REG_STALL’ is
            disabled.
  
!      ‘Ya’
!           Any integer register when zero extensions with ‘AND’ are
            disabled.
  
!      ‘Yb’
            Any register that can be used as the GOT base when calling
!           ‘___tls_get_addr’: that is, any general register except ‘a’
!           and ‘sp’ registers, for ‘-fno-plt’ if linker supports it.
!           Otherwise, ‘b’ register.
  
!      ‘Yf’
            Any x87 register when 80387 floating-point arithmetic is
            enabled.
  
!      ‘Yr’
            Lower SSE register when avoiding REX prefix and all SSE
            registers otherwise.
  
!      ‘Yv’
            For AVX512VL, any EVEX-encodable SSE register
!           (‘%xmm0-%xmm31’), otherwise any SSE register.
  
!      ‘Yh’
            Any EVEX-encodable SSE register, that has number factor of
            four.
  
!      ‘Bf’
            Flags register operand.
  
!      ‘Bg’
            GOT memory operand.
  
!      ‘Bm’
            Vector memory operand.
  
!      ‘Bc’
            Constant memory operand.
  
!      ‘Bn’
            Memory operand without REX prefix.
  
!      ‘Bs’
            Sibcall memory operand.
  
!      ‘Bw’
            Call memory operand.
  
!      ‘Bz’
            Constant call address operand.
  
!      ‘BC’
            SSE constant -1 operand.
  
!      ‘I’
            Integer constant in the range 0 ... 31, for 32-bit shifts.
  
!      ‘J’
            Integer constant in the range 0 ... 63, for 64-bit shifts.
  
!      ‘K’
            Signed 8-bit integer constant.
  
!      ‘L’
!           ‘0xFF’ or ‘0xFFFF’, for andsi as a zero-extending move.
  
!      ‘M’
!           0, 1, 2, or 3 (shifts for the ‘lea’ instruction).
  
!      ‘N’
!           Unsigned 8-bit integer constant (for ‘in’ and ‘out’
            instructions).
  
!      ‘O’
            Integer constant in the range 0 ... 127, for 128-bit shifts.
  
!      ‘G’
            Standard 80387 floating point constant.
  
!      ‘C’
            SSE constant zero operand.
  
!      ‘e’
            32-bit signed integer constant, or a symbolic reference known
            to fit that range (for immediate operands in sign-extending
            x86-64 instructions).
  
!      ‘We’
            32-bit signed integer constant, or a symbolic reference known
            to fit that range (for sign-extending conversion operations
!           that require non-‘VOIDmode’ immediate operands).
  
!      ‘Wz’
            32-bit unsigned integer constant, or a symbolic reference
            known to fit that range (for zero-extending conversion
!           operations that require non-‘VOIDmode’ immediate operands).
  
!      ‘Wd’
            128-bit integer constant where both the high and low 64-bit
!           word satisfy the ‘e’ constraint.
  
!      ‘Z’
            32-bit unsigned integer constant, or a symbolic reference
            known to fit that range (for immediate operands in
            zero-extending x86-64 instructions).
  
!      ‘Tv’
            VSIB address operand.
  
!      ‘Ts’
            Address operand without segment register.
  
! _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: gccint.info,  Node: Disable Insn Alternatives,  Next: Define Constraints,  Prev: Machine Constraints,  Up: Constraints
  
! 17.8.6 Disable insn alternatives using the ‘enabled’ attribute
  --------------------------------------------------------------
  
  There are three insn attributes that may be used to selectively disable
  instruction alternatives:
  
! ‘enabled’
       Says whether an alternative is available on the current subtarget.
  
! ‘preferred_for_size’
       Says whether an enabled alternative should be used in code that is
       optimized for size.
  
! ‘preferred_for_speed’
       Says whether an enabled alternative should be used in code that is
       optimized for speed.
  
!  All these attributes should use ‘(const_int 1)’ to allow an alternative
! or ‘(const_int 0)’ to disallow it.  The attributes must be a static
  property of the subtarget; they cannot for example depend on the current
  operands, on the current optimization level, on the location of the insn
  within the body of a loop, on whether register allocation has finished,
  or on the current compiler pass.
  
!  The ‘enabled’ attribute is a correctness property.  It tells GCC to act
  as though the disabled alternatives were never defined in the first
  place.  This is useful when adding new instructions to an existing
  pattern in cases where the new instructions are only available for
! certain cpu architecture levels (typically mapped to the ‘-march=’
  command-line option).
  
!  In contrast, the ‘preferred_for_size’ and ‘preferred_for_speed’
  attributes are strong optimization hints rather than correctness
! properties.  ‘preferred_for_size’ tells GCC which alternatives to
  consider when adding or modifying an instruction that GCC wants to
! optimize for size.  ‘preferred_for_speed’ does the same thing for speed.
  Note that things like code motion can lead to cases where code optimized
  for size uses alternatives that are not preferred for size, and
  similarly for speed.
  
!  Although ‘define_insn’s can in principle specify the ‘enabled’
  attribute directly, it is often clearer to have subsiduary attributes
! for each architectural feature of interest.  The ‘define_insn’s can then
  use these subsiduary attributes to say which alternatives require which
! features.  The example below does this for ‘cpu_facility’.
  
   E.g.  the following two patterns could easily be merged using the
! ‘enabled’ attribute:
  
  
       (define_insn "*movdi_old"
*************** features.  The example below does this f
*** 25998,26004 ****
         [(set_attr "cpu_facility" "*,new,new")])
  
  
!  with the 'enabled' attribute defined like this:
  
  
       (define_attr "cpu_facility" "standard,new" (const_string "standard"))
--- 25997,26003 ----
         [(set_attr "cpu_facility" "*,new,new")])
  
  
!  with the ‘enabled’ attribute defined like this:
  
  
       (define_attr "cpu_facility" "standard,new" (const_string "standard"))
*************** File: gccint.info,  Node: Define Constra
*** 26020,26037 ****
  Machine-specific constraints fall into two categories: register and
  non-register constraints.  Within the latter category, constraints which
  allow subsets of all possible memory or address operands should be
! specially marked, to give 'reload' more information.
  
   Machine-specific constraints can be given names of arbitrary length,
  but they must be entirely composed of letters, digits, underscores
! ('_'), and angle brackets ('< >').  Like C identifiers, they must begin
  with a letter or underscore.
  
   In order to avoid ambiguity in operand constraint strings, no
  constraint can have a name that begins with any other constraint's name.
! For example, if 'x' is defined as a constraint name, 'xy' may not be,
  and vice versa.  As a consequence of this rule, no constraint may begin
! with one of the generic constraint letters: 'E F V X g i m n o p r s'.
  
   Register constraints correspond directly to register classes.  *Note
  Register Classes::.  There is thus not much flexibility in their
--- 26019,26036 ----
  Machine-specific constraints fall into two categories: register and
  non-register constraints.  Within the latter category, constraints which
  allow subsets of all possible memory or address operands should be
! specially marked, to give ‘reload’ more information.
  
   Machine-specific constraints can be given names of arbitrary length,
  but they must be entirely composed of letters, digits, underscores
! (‘_’), and angle brackets (‘< >’).  Like C identifiers, they must begin
  with a letter or underscore.
  
   In order to avoid ambiguity in operand constraint strings, no
  constraint can have a name that begins with any other constraint's name.
! For example, if ‘x’ is defined as a constraint name, ‘xy’ may not be,
  and vice versa.  As a consequence of this rule, no constraint may begin
! with one of the generic constraint letters: ‘E F V X g i m n o p r s’.
  
   Register constraints correspond directly to register classes.  *Note
  Register Classes::.  There is thus not much flexibility in their
*************** definitions.
*** 26039,26052 ****
  
   -- MD Expression: define_register_constraint name regclass docstring
       All three arguments are string constants.  NAME is the name of the
!      constraint, as it will appear in 'match_operand' expressions.  If
       NAME is a multi-letter constraint its length shall be the same for
       all constraints starting with the same letter.  REGCLASS can be
       either the name of the corresponding register class (*note Register
       Classes::), or a C expression which evaluates to the appropriate
       register class.  If it is an expression, it must have no side
       effects, and it cannot look at the operand.  The usual use of
!      expressions is to map some register constraints to 'NO_REGS' when
       the register class is not available on a given subarchitecture.
  
       DOCSTRING is a sentence documenting the meaning of the constraint.
--- 26038,26051 ----
  
   -- MD Expression: define_register_constraint name regclass docstring
       All three arguments are string constants.  NAME is the name of the
!      constraint, as it will appear in ‘match_operand’ expressions.  If
       NAME is a multi-letter constraint its length shall be the same for
       all constraints starting with the same letter.  REGCLASS can be
       either the name of the corresponding register class (*note Register
       Classes::), or a C expression which evaluates to the appropriate
       register class.  If it is an expression, it must have no side
       effects, and it cannot look at the operand.  The usual use of
!      expressions is to map some register constraints to ‘NO_REGS’ when
       the register class is not available on a given subarchitecture.
  
       DOCSTRING is a sentence documenting the meaning of the constraint.
*************** constraint matches.
*** 26058,26064 ****
  
   -- MD Expression: define_constraint name docstring exp
       The NAME and DOCSTRING arguments are the same as for
!      'define_register_constraint', but note that the docstring comes
       immediately after the name for these expressions.  EXP is an RTL
       expression, obeying the same rules as the RTL expressions in
       predicate definitions.  *Note Defining Predicates::, for details.
--- 26057,26063 ----
  
   -- MD Expression: define_constraint name docstring exp
       The NAME and DOCSTRING arguments are the same as for
!      ‘define_register_constraint’, but note that the docstring comes
       immediately after the name for these expressions.  EXP is an RTL
       expression, obeying the same rules as the RTL expressions in
       predicate definitions.  *Note Defining Predicates::, for details.
*************** constraint matches.
*** 26066,26195 ****
       false, it doesn't.  Constraint expressions should indicate which
       RTL codes they might match, just like predicate expressions.
  
!      'match_test' C expressions have access to the following variables:
  
       OP
            The RTL object defining the operand.
       MODE
            The machine mode of OP.
       IVAL
!           'INTVAL (OP)', if OP is a 'const_int'.
       HVAL
!           'CONST_DOUBLE_HIGH (OP)', if OP is an integer 'const_double'.
       LVAL
!           'CONST_DOUBLE_LOW (OP)', if OP is an integer 'const_double'.
       RVAL
!           'CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point
!           'const_double'.
  
       The *VAL variables should only be used once another piece of the
       expression has verified that OP is the appropriate kind of RTL
       object.
  
   Most non-register constraints should be defined with
! 'define_constraint'.  The remaining two definition expressions are only
! appropriate for constraints that should be handled specially by 'reload'
  if they fail to match.
  
   -- MD Expression: define_memory_constraint name docstring exp
       Use this expression for constraints that match a subset of all
!      memory operands: that is, 'reload' can make them match by
!      converting the operand to the form '(mem (reg X))', where X is a
       base register (from the register class specified by
!      'BASE_REG_CLASS', *note Register Classes::).
  
       For example, on the S/390, some instructions do not accept
       arbitrary memory references, but only those that do not make use of
!      an index register.  The constraint letter 'Q' is defined to
!      represent a memory address of this type.  If 'Q' is defined with
!      'define_memory_constraint', a 'Q' constraint can handle any memory
!      operand, because 'reload' knows it can simply copy the memory
       address into a base register if required.  This is analogous to the
!      way an 'o' constraint can handle any memory operand.
  
       The syntax and semantics are otherwise identical to
!      'define_constraint'.
  
   -- MD Expression: define_special_memory_constraint name docstring exp
       Use this expression for constraints that match a subset of all
!      memory operands: that is, 'reload' cannot make them match by
       reloading the address as it is described for
!      'define_memory_constraint' or such address reload is undesirable
       with the performance point of view.
  
!      For example, 'define_special_memory_constraint' can be useful if
       specifically aligned memory is necessary or desirable for some insn
       operand.
  
       The syntax and semantics are otherwise identical to
!      'define_memory_constraint'.
  
   -- MD Expression: define_relaxed_memory_constraint name docstring exp
!      The test expression in a 'define_memory_constraint' can assume that
!      'TARGET_LEGITIMATE_ADDRESS_P' holds for the address inside a 'mem'
       rtx and so it does not need to test this condition itself.  In
!      other words, a 'define_memory_constraint' test of the form:
  
            (match_test "mem")
  
!      is enough to test whether an rtx is a 'mem' _and_ whether its
!      address satisfies 'TARGET_MEM_CONSTRAINT' (which is usually ''m'').
!      Thus the conditions imposed by a 'define_memory_constraint' always
!      apply on top of the conditions imposed by 'TARGET_MEM_CONSTRAINT'.
  
       However, it is sometimes useful to define memory constraints that
       allow addresses beyond those accepted by
!      'TARGET_LEGITIMATE_ADDRESS_P'.  'define_relaxed_memory_constraint'
       exists for this case.  The test expression in a
!      'define_relaxed_memory_constraint' is applied with no
       preconditions, so that the expression can determine "from scratch"
       exactly which addresses are valid and which are not.
  
       The syntax and semantics are otherwise identical to
!      'define_memory_constraint'.
  
   -- MD Expression: define_address_constraint name docstring exp
       Use this expression for constraints that match a subset of all
!      address operands: that is, 'reload' can make the constraint match
!      by converting the operand to the form '(reg X)', again with X a
       base register.
  
!      Constraints defined with 'define_address_constraint' can only be
!      used with the 'address_operand' predicate, or machine-specific
       predicates that work the same way.  They are treated analogously to
!      the generic 'p' constraint.
  
       The syntax and semantics are otherwise identical to
!      'define_constraint'.
  
!  For historical reasons, names beginning with the letters 'G H' are
! reserved for constraints that match only 'const_double's, and names
! beginning with the letters 'I J K L M N O P' are reserved for
! constraints that match only 'const_int's.  This may change in the
  future.  For the time being, constraints with these names must be
! written in a stylized form, so that 'genpreds' can tell you did it
  correctly:
  
       (define_constraint "[GHIJKLMNOP]..."
         "DOC..."
!        (and (match_code "const_int")  ; 'const_double' for G/H
!             CONDITION...))            ; usually a 'match_test'
  
   It is fine to use names beginning with other letters for constraints
! that match 'const_double's or 'const_int's.
  
   Each docstring in a constraint definition should be one or more
  complete sentences, marked up in Texinfo format.  _They are currently
  unused._  In the future they will be copied into the GCC manual, in
  *note Machine Constraints::, replacing the hand-maintained tables
  currently found in that section.  Also, in the future the compiler may
! use this to give more helpful diagnostics when poor choice of 'asm'
  constraints causes a reload failure.
  
!  If you put the pseudo-Texinfo directive '@internal' at the beginning of
  a docstring, then (in the future) it will appear only in the internals
  manual's version of the machine-specific constraint tables.  Use this
! for constraints that should not appear in 'asm' statements.
  
  
  File: gccint.info,  Node: C Constraint Interface,  Prev: Define Constraints,  Up: Constraints
--- 26065,26194 ----
       false, it doesn't.  Constraint expressions should indicate which
       RTL codes they might match, just like predicate expressions.
  
!      ‘match_test’ C expressions have access to the following variables:
  
       OP
            The RTL object defining the operand.
       MODE
            The machine mode of OP.
       IVAL
!           ‘INTVAL (OP)’, if OP is a ‘const_int’.
       HVAL
!           ‘CONST_DOUBLE_HIGH (OP)’, if OP is an integer ‘const_double’.
       LVAL
!           ‘CONST_DOUBLE_LOW (OP)’, if OP is an integer ‘const_double’.
       RVAL
!           ‘CONST_DOUBLE_REAL_VALUE (OP)’, if OP is a floating-point
!           ‘const_double’.
  
       The *VAL variables should only be used once another piece of the
       expression has verified that OP is the appropriate kind of RTL
       object.
  
   Most non-register constraints should be defined with
! ‘define_constraint’.  The remaining two definition expressions are only
! appropriate for constraints that should be handled specially by ‘reload’
  if they fail to match.
  
   -- MD Expression: define_memory_constraint name docstring exp
       Use this expression for constraints that match a subset of all
!      memory operands: that is, ‘reload’ can make them match by
!      converting the operand to the form ‘(mem (reg X))’, where X is a
       base register (from the register class specified by
!      ‘BASE_REG_CLASS’, *note Register Classes::).
  
       For example, on the S/390, some instructions do not accept
       arbitrary memory references, but only those that do not make use of
!      an index register.  The constraint letter ‘Q’ is defined to
!      represent a memory address of this type.  If ‘Q’ is defined with
!      ‘define_memory_constraint’, a ‘Q’ constraint can handle any memory
!      operand, because ‘reload’ knows it can simply copy the memory
       address into a base register if required.  This is analogous to the
!      way an ‘o’ constraint can handle any memory operand.
  
       The syntax and semantics are otherwise identical to
!      ‘define_constraint’.
  
   -- MD Expression: define_special_memory_constraint name docstring exp
       Use this expression for constraints that match a subset of all
!      memory operands: that is, ‘reload’ cannot make them match by
       reloading the address as it is described for
!      ‘define_memory_constraint’ or such address reload is undesirable
       with the performance point of view.
  
!      For example, ‘define_special_memory_constraint’ can be useful if
       specifically aligned memory is necessary or desirable for some insn
       operand.
  
       The syntax and semantics are otherwise identical to
!      ‘define_memory_constraint’.
  
   -- MD Expression: define_relaxed_memory_constraint name docstring exp
!      The test expression in a ‘define_memory_constraint’ can assume that
!      ‘TARGET_LEGITIMATE_ADDRESS_P’ holds for the address inside a ‘mem’
       rtx and so it does not need to test this condition itself.  In
!      other words, a ‘define_memory_constraint’ test of the form:
  
            (match_test "mem")
  
!      is enough to test whether an rtx is a ‘mem’ _and_ whether its
!      address satisfies ‘TARGET_MEM_CONSTRAINT’ (which is usually ‘'m'’).
!      Thus the conditions imposed by a ‘define_memory_constraint’ always
!      apply on top of the conditions imposed by ‘TARGET_MEM_CONSTRAINT’.
  
       However, it is sometimes useful to define memory constraints that
       allow addresses beyond those accepted by
!      ‘TARGET_LEGITIMATE_ADDRESS_P’.  ‘define_relaxed_memory_constraint’
       exists for this case.  The test expression in a
!      ‘define_relaxed_memory_constraint’ is applied with no
       preconditions, so that the expression can determine "from scratch"
       exactly which addresses are valid and which are not.
  
       The syntax and semantics are otherwise identical to
!      ‘define_memory_constraint’.
  
   -- MD Expression: define_address_constraint name docstring exp
       Use this expression for constraints that match a subset of all
!      address operands: that is, ‘reload’ can make the constraint match
!      by converting the operand to the form ‘(reg X)’, again with X a
       base register.
  
!      Constraints defined with ‘define_address_constraint’ can only be
!      used with the ‘address_operand’ predicate, or machine-specific
       predicates that work the same way.  They are treated analogously to
!      the generic ‘p’ constraint.
  
       The syntax and semantics are otherwise identical to
!      ‘define_constraint’.
  
!  For historical reasons, names beginning with the letters ‘G H’ are
! reserved for constraints that match only ‘const_double’s, and names
! beginning with the letters ‘I J K L M N O P’ are reserved for
! constraints that match only ‘const_int’s.  This may change in the
  future.  For the time being, constraints with these names must be
! written in a stylized form, so that ‘genpreds’ can tell you did it
  correctly:
  
       (define_constraint "[GHIJKLMNOP]..."
         "DOC..."
!        (and (match_code "const_int")  ; ‘const_double’ for G/H
!             CONDITION...))            ; usually a ‘match_test’
  
   It is fine to use names beginning with other letters for constraints
! that match ‘const_double’s or ‘const_int’s.
  
   Each docstring in a constraint definition should be one or more
  complete sentences, marked up in Texinfo format.  _They are currently
  unused._  In the future they will be copied into the GCC manual, in
  *note Machine Constraints::, replacing the hand-maintained tables
  currently found in that section.  Also, in the future the compiler may
! use this to give more helpful diagnostics when poor choice of ‘asm’
  constraints causes a reload failure.
  
!  If you put the pseudo-Texinfo directive ‘@internal’ at the beginning of
  a docstring, then (in the future) it will appear only in the internals
  manual's version of the machine-specific constraint tables.  Use this
! for constraints that should not appear in ‘asm’ statements.
  
  
  File: gccint.info,  Node: C Constraint Interface,  Prev: Define Constraints,  Up: Constraints
*************** File: gccint.info,  Node: C Constraint I
*** 26198,26213 ****
  ---------------------------------
  
  It is occasionally useful to test a constraint from C code rather than
! implicitly via the constraint string in a 'match_operand'.  The
! generated file 'tm_p.h' declares a few interfaces for working with
  constraints.  At present these are defined for all constraints except
! 'g' (which is equivalent to 'general_operand').
  
   Some valid constraint names are not valid C identifiers, so there is a
  mangling scheme for referring to them from C.  Constraint names that do
  not contain angle brackets or underscores are left unchanged.
! Underscores are doubled, each '<' is replaced with '_l', and each '>'
! with '_g'.  Here are some examples:
  
       *Original* *Mangled*
       x          x
--- 26197,26212 ----
  ---------------------------------
  
  It is occasionally useful to test a constraint from C code rather than
! implicitly via the constraint string in a ‘match_operand’.  The
! generated file ‘tm_p.h’ declares a few interfaces for working with
  constraints.  At present these are defined for all constraints except
! ‘g’ (which is equivalent to ‘general_operand’).
  
   Some valid constraint names are not valid C identifiers, so there is a
  mangling scheme for referring to them from C.  Constraint names that do
  not contain angle brackets or underscores are left unchanged.
! Underscores are doubled, each ‘<’ is replaced with ‘_l’, and each ‘>’
! with ‘_g’.  Here are some examples:
  
       *Original* *Mangled*
       x          x
*************** with '_g'.  Here are some examples:
*** 26218,26255 ****
       P4_g>      P4__g_g
  
   Throughout this section, the variable C is either a constraint in the
! abstract sense, or a constant from 'enum constraint_num'; the variable M
  is a mangled constraint name (usually as part of a larger identifier).
  
   -- Enum: constraint_num
!      For each constraint except 'g', there is a corresponding
!      enumeration constant: 'CONSTRAINT_' plus the mangled name of the
!      constraint.  Functions that take an 'enum constraint_num' as an
       argument expect one of these constants.
  
   -- Function: inline bool satisfies_constraint_M (rtx EXP)
!      For each non-register constraint M except 'g', there is one of
!      these functions; it returns 'true' if EXP satisfies the constraint.
!      These functions are only visible if 'rtl.h' was included before
!      'tm_p.h'.
  
   -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num
            C)
!      Like the 'satisfies_constraint_M' functions, but the constraint to
       test is given as an argument, C.  If C specifies a register
!      constraint, this function will always return 'false'.
  
   -- Function: enum reg_class reg_class_for_constraint (enum
            constraint_num C)
       Returns the register class associated with C.  If C is not a
       register constraint, or those registers are not available for the
!      currently selected subtarget, returns 'NO_REGS'.
  
!  Here is an example use of 'satisfies_constraint_M'.  In peephole
  optimizations (*note Peephole Definitions::), operand constraint strings
  are ignored, so if there are relevant constraints, they must be tested
  in the C condition.  In the example, the optimization is applied if
! operand 2 does _not_ satisfy the 'K' constraint.  (This is a simplified
  version of a peephole definition from the i386 machine description.)
  
       (define_peephole2
--- 26217,26254 ----
       P4_g>      P4__g_g
  
   Throughout this section, the variable C is either a constraint in the
! abstract sense, or a constant from ‘enum constraint_num’; the variable M
  is a mangled constraint name (usually as part of a larger identifier).
  
   -- Enum: constraint_num
!      For each constraint except ‘g’, there is a corresponding
!      enumeration constant: ‘CONSTRAINT_’ plus the mangled name of the
!      constraint.  Functions that take an ‘enum constraint_num’ as an
       argument expect one of these constants.
  
   -- Function: inline bool satisfies_constraint_M (rtx EXP)
!      For each non-register constraint M except ‘g’, there is one of
!      these functions; it returns ‘true’ if EXP satisfies the constraint.
!      These functions are only visible if ‘rtl.h’ was included before
!      ‘tm_p.h’.
  
   -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num
            C)
!      Like the ‘satisfies_constraint_M’ functions, but the constraint to
       test is given as an argument, C.  If C specifies a register
!      constraint, this function will always return ‘false’.
  
   -- Function: enum reg_class reg_class_for_constraint (enum
            constraint_num C)
       Returns the register class associated with C.  If C is not a
       register constraint, or those registers are not available for the
!      currently selected subtarget, returns ‘NO_REGS’.
  
!  Here is an example use of ‘satisfies_constraint_M’.  In peephole
  optimizations (*note Peephole Definitions::), operand constraint strings
  are ignored, so if there are relevant constraints, they must be tested
  in the C condition.  In the example, the optimization is applied if
! operand 2 does _not_ satisfy the ‘K’ constraint.  (This is a simplified
  version of a peephole definition from the i386 machine description.)
  
       (define_peephole2
*************** generation pass of the compiler.  Giving
*** 26276,26298 ****
  instruction pattern tells the RTL generation pass that it can use the
  pattern to accomplish a certain task.
  
! 'movM'
       Here M stands for a two-letter machine mode name, in lowercase.
       This instruction pattern moves data with that machine mode from
!      operand 1 to operand 0.  For example, 'movsi' moves full-word data.
  
!      If operand 0 is a 'subreg' with mode M of a register whose own mode
       is wider than M, the effect of this instruction is to store the
       specified value in the part of the register that corresponds to
       mode M.  Bits outside of M, but which are within the same target
!      word as the 'subreg' are undefined.  Bits which are outside the
       target word are left unchanged.
  
       This class of patterns is special in several ways.  First of all,
       each of these names up to and including full word size _must_ be
       defined, because there is no other way to copy a datum from one
       place to another.  If there are patterns accepting operands in
!      larger modes, 'movM' must be defined for integer modes of those
       sizes.
  
       Second, these patterns are not used solely in the RTL generation
--- 26275,26297 ----
  instruction pattern tells the RTL generation pass that it can use the
  pattern to accomplish a certain task.
  
! ‘movM’
       Here M stands for a two-letter machine mode name, in lowercase.
       This instruction pattern moves data with that machine mode from
!      operand 1 to operand 0.  For example, ‘movsi’ moves full-word data.
  
!      If operand 0 is a ‘subreg’ with mode M of a register whose own mode
       is wider than M, the effect of this instruction is to store the
       specified value in the part of the register that corresponds to
       mode M.  Bits outside of M, but which are within the same target
!      word as the ‘subreg’ are undefined.  Bits which are outside the
       target word are left unchanged.
  
       This class of patterns is special in several ways.  First of all,
       each of these names up to and including full word size _must_ be
       defined, because there is no other way to copy a datum from one
       place to another.  If there are patterns accepting operands in
!      larger modes, ‘movM’ must be defined for integer modes of those
       sizes.
  
       Second, these patterns are not used solely in the RTL generation
*************** pattern to accomplish a certain task.
*** 26304,26311 ****
       Therefore, when given such a pair of operands, the pattern must
       generate RTL which needs no reloading and needs no temporary
       registers--no registers other than the operands.  For example, if
!      you support the pattern with a 'define_expand', then in such a case
!      the 'define_expand' mustn't call 'force_reg' or any other such
       function which might generate new pseudo registers.
  
       This requirement exists even for subword modes on a RISC machine
--- 26303,26310 ----
       Therefore, when given such a pair of operands, the pattern must
       generate RTL which needs no reloading and needs no temporary
       registers--no registers other than the operands.  For example, if
!      you support the pattern with a ‘define_expand’, then in such a case
!      the ‘define_expand’ mustn't call ‘force_reg’ or any other such
       function which might generate new pseudo registers.
  
       This requirement exists even for subword modes on a RISC machine
*************** pattern to accomplish a certain task.
*** 26318,26328 ****
       be done with the address except to use it as it stands.  If it is
       copied, it will not be replaced with a valid address.  No attempt
       should be made to make such an address into a valid address and no
!      routine (such as 'change_address') that will do so may be called.
!      Note that 'general_operand' will fail when applied to such an
       address.
  
!      The global variable 'reload_in_progress' (which must be explicitly
       declared if required) can be used to determine whether such special
       handling is required.
  
--- 26317,26327 ----
       be done with the address except to use it as it stands.  If it is
       copied, it will not be replaced with a valid address.  No attempt
       should be made to make such an address into a valid address and no
!      routine (such as ‘change_address’) that will do so may be called.
!      Note that ‘general_operand’ will fail when applied to such an
       address.
  
!      The global variable ‘reload_in_progress’ (which must be explicitly
       declared if required) can be used to determine whether such special
       handling is required.
  
*************** pattern to accomplish a certain task.
*** 26333,26396 ****
       reloads.
  
       If a scratch register is required to move an object to or from
!      memory, it can be allocated using 'gen_reg_rtx' prior to life
       analysis.
  
       If there are cases which need scratch registers during or after
       reload, you must provide an appropriate secondary_reload target
       hook.
  
!      The macro 'can_create_pseudo_p' can be used to determine if it is
       unsafe to create new pseudo registers.  If this variable is
!      nonzero, then it is unsafe to call 'gen_reg_rtx' to allocate a new
       pseudo.
  
!      The constraints on a 'movM' must permit moving any hard register to
!      any other hard register provided that 'TARGET_HARD_REGNO_MODE_OK'
!      permits mode M in both registers and 'TARGET_REGISTER_MOVE_COST'
       applied to their classes returns a value of 2.
  
!      It is obligatory to support floating point 'movM' instructions into
       and out of any registers that can hold fixed point values, because
!      unions and structures (which have modes 'SImode' or 'DImode') can
       be in those registers and they may have floating point members.
  
!      There may also be a need to support fixed point 'movM' instructions
       in and out of floating point registers.  Unfortunately, I have
       forgotten why this was so, and I don't know whether it is still
!      true.  If 'TARGET_HARD_REGNO_MODE_OK' rejects fixed point values in
       floating point registers, then the constraints of the fixed point
!      'movM' instructions must be designed to avoid ever trying to reload
       into a floating point register.
  
! 'reload_inM'
! 'reload_outM'
       These named patterns have been obsoleted by the target hook
!      'secondary_reload'.
  
!      Like 'movM', but used when a scratch register is required to move
       between operand 0 and operand 1.  Operand 2 describes the scratch
!      register.  See the discussion of the 'SECONDARY_RELOAD_CLASS' macro
       in *note Register Classes::.
  
!      There are special restrictions on the form of the 'match_operand's
       used in these patterns.  First, only the predicate for the reload
!      operand is examined, i.e., 'reload_in' examines operand 1, but not
       the predicates for operand 0 or 2.  Second, there may be only one
       alternative in the constraints.  Third, only a single register
       class letter may be used for the constraint; subsequent constraint
       letters are ignored.  As a special exception, an empty constraint
!      string matches the 'ALL_REGS' register class.  This may relieve
!      ports of the burden of defining an 'ALL_REGS' constraint letter
       just for these patterns.
  
! 'movstrictM'
!      Like 'movM' except that if operand 0 is a 'subreg' with mode M of a
!      register whose natural mode is wider, the 'movstrictM' instruction
       is guaranteed not to alter any of the register except the part
       which belongs to mode M.
  
! 'movmisalignM'
       This variant of a move pattern is designed to load or store a value
       from a memory address that is not naturally aligned for its mode.
       For a store, the memory will be in operand 0; for a load, the
--- 26332,26395 ----
       reloads.
  
       If a scratch register is required to move an object to or from
!      memory, it can be allocated using ‘gen_reg_rtx’ prior to life
       analysis.
  
       If there are cases which need scratch registers during or after
       reload, you must provide an appropriate secondary_reload target
       hook.
  
!      The macro ‘can_create_pseudo_p’ can be used to determine if it is
       unsafe to create new pseudo registers.  If this variable is
!      nonzero, then it is unsafe to call ‘gen_reg_rtx’ to allocate a new
       pseudo.
  
!      The constraints on a ‘movM’ must permit moving any hard register to
!      any other hard register provided that ‘TARGET_HARD_REGNO_MODE_OK’
!      permits mode M in both registers and ‘TARGET_REGISTER_MOVE_COST’
       applied to their classes returns a value of 2.
  
!      It is obligatory to support floating point ‘movM’ instructions into
       and out of any registers that can hold fixed point values, because
!      unions and structures (which have modes ‘SImode’ or ‘DImode’) can
       be in those registers and they may have floating point members.
  
!      There may also be a need to support fixed point ‘movM’ instructions
       in and out of floating point registers.  Unfortunately, I have
       forgotten why this was so, and I don't know whether it is still
!      true.  If ‘TARGET_HARD_REGNO_MODE_OK’ rejects fixed point values in
       floating point registers, then the constraints of the fixed point
!      ‘movM’ instructions must be designed to avoid ever trying to reload
       into a floating point register.
  
! ‘reload_inM’
! ‘reload_outM’
       These named patterns have been obsoleted by the target hook
!      ‘secondary_reload’.
  
!      Like ‘movM’, but used when a scratch register is required to move
       between operand 0 and operand 1.  Operand 2 describes the scratch
!      register.  See the discussion of the ‘SECONDARY_RELOAD_CLASS’ macro
       in *note Register Classes::.
  
!      There are special restrictions on the form of the ‘match_operand’s
       used in these patterns.  First, only the predicate for the reload
!      operand is examined, i.e., ‘reload_in’ examines operand 1, but not
       the predicates for operand 0 or 2.  Second, there may be only one
       alternative in the constraints.  Third, only a single register
       class letter may be used for the constraint; subsequent constraint
       letters are ignored.  As a special exception, an empty constraint
!      string matches the ‘ALL_REGS’ register class.  This may relieve
!      ports of the burden of defining an ‘ALL_REGS’ constraint letter
       just for these patterns.
  
! ‘movstrictM’
!      Like ‘movM’ except that if operand 0 is a ‘subreg’ with mode M of a
!      register whose natural mode is wider, the ‘movstrictM’ instruction
       is guaranteed not to alter any of the register except the part
       which belongs to mode M.
  
! ‘movmisalignM’
       This variant of a move pattern is designed to load or store a value
       from a memory address that is not naturally aligned for its mode.
       For a store, the memory will be in operand 0; for a load, the
*************** pattern to accomplish a certain task.
*** 26399,26407 ****
       store.
  
       This pattern is used by the autovectorizer, and when expanding a
!      'MISALIGNED_INDIRECT_REF' expression.
  
! 'load_multiple'
       Load several consecutive memory locations into consecutive
       registers.  Operand 0 is the first of the consecutive registers,
       operand 1 is the first memory location, and operand 2 is a
--- 26398,26406 ----
       store.
  
       This pattern is used by the autovectorizer, and when expanding a
!      ‘MISALIGNED_INDIRECT_REF’ expression.
  
! ‘load_multiple’
       Load several consecutive memory locations into consecutive
       registers.  Operand 0 is the first of the consecutive registers,
       operand 1 is the first memory location, and operand 2 is a
*************** pattern to accomplish a certain task.
*** 26415,26436 ****
       On some machines, there are restrictions as to which consecutive
       registers can be stored into memory, such as particular starting or
       ending register numbers or only a range of valid counts.  For those
!      machines, use a 'define_expand' (*note Expander Definitions::) and
       make the pattern fail if the restrictions are not met.
  
!      Write the generated insn as a 'parallel' with elements being a
!      'set' of one register from the appropriate memory location (you may
!      also need 'use' or 'clobber' elements).  Use a 'match_parallel'
!      (*note RTL Template::) to recognize the insn.  See 'rs6000.md' for
       examples of the use of this insn pattern.
  
! 'store_multiple'
!      Similar to 'load_multiple', but store several consecutive registers
       into consecutive memory locations.  Operand 0 is the first of the
       consecutive memory locations, operand 1 is the first register, and
       operand 2 is a constant: the number of consecutive registers.
  
! 'vec_load_lanesMN'
       Perform an interleaved load of several vectors from memory operand
       1 into register operand 0.  Both operands have mode M.  The
       register operand is viewed as holding consecutive vectors of mode
--- 26414,26435 ----
       On some machines, there are restrictions as to which consecutive
       registers can be stored into memory, such as particular starting or
       ending register numbers or only a range of valid counts.  For those
!      machines, use a ‘define_expand’ (*note Expander Definitions::) and
       make the pattern fail if the restrictions are not met.
  
!      Write the generated insn as a ‘parallel’ with elements being a
!      ‘set’ of one register from the appropriate memory location (you may
!      also need ‘use’ or ‘clobber’ elements).  Use a ‘match_parallel’
!      (*note RTL Template::) to recognize the insn.  See ‘rs6000.md’ for
       examples of the use of this insn pattern.
  
! ‘store_multiple’
!      Similar to ‘load_multiple’, but store several consecutive registers
       into consecutive memory locations.  Operand 0 is the first of the
       consecutive memory locations, operand 1 is the first register, and
       operand 2 is a constant: the number of consecutive registers.
  
! ‘vec_load_lanesMN’
       Perform an interleaved load of several vectors from memory operand
       1 into register operand 0.  Both operands have mode M.  The
       register operand is viewed as holding consecutive vectors of mode
*************** pattern to accomplish a certain task.
*** 26442,26450 ****
              for (i = 0; i < c; i++)
                operand0[i][j] = operand1[j * c + i];
  
!      For example, 'vec_load_lanestiv4hi' loads 8 16-bit values from
!      memory into a register of mode 'TI'.  The register contains two
!      consecutive vectors of mode 'V4HI'.
  
       This pattern can only be used if:
            TARGET_ARRAY_MODE_SUPPORTED_P (N, C)
--- 26441,26449 ----
              for (i = 0; i < c; i++)
                operand0[i][j] = operand1[j * c + i];
  
!      For example, ‘vec_load_lanestiv4hi’ loads 8 16-bit values from
!      memory into a register of mode ‘TI’.  The register contains two
!      consecutive vectors of mode ‘V4HI’.
  
       This pattern can only be used if:
            TARGET_ARRAY_MODE_SUPPORTED_P (N, C)
*************** pattern to accomplish a certain task.
*** 26452,26461 ****
       instruction for some mode N, it also supports unaligned loads for
       vectors of mode N.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'vec_mask_load_lanesMN'
!      Like 'vec_load_lanesMN', but takes an additional mask operand
       (operand 2) that specifies which elements of the destination
       vectors should be loaded.  Other elements of the destination
       vectors are set to zero.  The operation is equivalent to:
--- 26451,26460 ----
       instruction for some mode N, it also supports unaligned loads for
       vectors of mode N.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘vec_mask_load_lanesMN’
!      Like ‘vec_load_lanesMN’, but takes an additional mask operand
       (operand 2) that specifies which elements of the destination
       vectors should be loaded.  Other elements of the destination
       vectors are set to zero.  The operation is equivalent to:
*************** pattern to accomplish a certain task.
*** 26469,26478 ****
                for (i = 0; i < c; i++)
                  operand0[i][j] = 0;
  
!      This pattern is not allowed to 'FAIL'.
  
! 'vec_store_lanesMN'
!      Equivalent to 'vec_load_lanesMN', with the memory and register
       operands reversed.  That is, the instruction is equivalent to:
  
            int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N);
--- 26468,26477 ----
                for (i = 0; i < c; i++)
                  operand0[i][j] = 0;
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘vec_store_lanesMN’
!      Equivalent to ‘vec_load_lanesMN’, with the memory and register
       operands reversed.  That is, the instruction is equivalent to:
  
            int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N);
*************** pattern to accomplish a certain task.
*** 26482,26491 ****
  
       for a memory operand 0 and register operand 1.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'vec_mask_store_lanesMN'
!      Like 'vec_store_lanesMN', but takes an additional mask operand
       (operand 2) that specifies which elements of the source vectors
       should be stored.  The operation is equivalent to:
  
--- 26481,26490 ----
  
       for a memory operand 0 and register operand 1.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘vec_mask_store_lanesMN’
!      Like ‘vec_store_lanesMN’, but takes an additional mask operand
       (operand 2) that specifies which elements of the source vectors
       should be stored.  The operation is equivalent to:
  
*************** pattern to accomplish a certain task.
*** 26495,26553 ****
                for (i = 0; i < c; i++)
                  operand0[j * c + i] = operand1[i][j];
  
!      This pattern is not allowed to 'FAIL'.
  
! 'gather_loadMN'
       Load several separate memory locations into a vector of mode M.
       Operand 1 is a scalar base address and operand 2 is a vector of
       mode N containing offsets from that base.  Operand 0 is a
       destination vector with the same number of elements as N.  For each
       element index I:
  
!         * extend the offset element I to address width, using zero
            extension if operand 3 is 1 and sign extension if operand 3 is
            zero;
!         * multiply the extended offset by operand 4;
!         * add the result to the base; and
!         * load the value at that address into element I of operand 0.
  
       The value of operand 3 does not matter if the offsets are already
       address width.
  
! 'mask_gather_loadMN'
!      Like 'gather_loadMN', but takes an extra mask operand as operand 5.
       Bit I of the mask is set if element I of the result should be
       loaded from memory and clear if element I of the result should be
       set to zero.
  
! 'scatter_storeMN'
       Store a vector of mode M into several distinct memory locations.
       Operand 0 is a scalar base address and operand 1 is a vector of
       mode N containing offsets from that base.  Operand 4 is the vector
       of values that should be stored, which has the same number of
       elements as N.  For each element index I:
  
!         * extend the offset element I to address width, using zero
            extension if operand 2 is 1 and sign extension if operand 2 is
            zero;
!         * multiply the extended offset by operand 3;
!         * add the result to the base; and
!         * store element I of operand 4 to that address.
  
       The value of operand 2 does not matter if the offsets are already
       address width.
  
! 'mask_scatter_storeMN'
!      Like 'scatter_storeMN', but takes an extra mask operand as operand
       5.  Bit I of the mask is set if element I of the result should be
       stored to memory.
  
! 'vec_setM'
       Set given field in the vector value.  Operand 0 is the vector to
       modify, operand 1 is new value of field and operand 2 specify the
       field index.
  
! 'vec_extractMN'
       Extract given field from the vector value.  Operand 1 is the
       vector, operand 2 specify field index and operand 0 place to store
       value into.  The N mode is the mode of the field or vector of
--- 26494,26552 ----
                for (i = 0; i < c; i++)
                  operand0[j * c + i] = operand1[i][j];
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘gather_loadMN’
       Load several separate memory locations into a vector of mode M.
       Operand 1 is a scalar base address and operand 2 is a vector of
       mode N containing offsets from that base.  Operand 0 is a
       destination vector with the same number of elements as N.  For each
       element index I:
  
!         • extend the offset element I to address width, using zero
            extension if operand 3 is 1 and sign extension if operand 3 is
            zero;
!         • multiply the extended offset by operand 4;
!         • add the result to the base; and
!         • load the value at that address into element I of operand 0.
  
       The value of operand 3 does not matter if the offsets are already
       address width.
  
! ‘mask_gather_loadMN’
!      Like ‘gather_loadMN’, but takes an extra mask operand as operand 5.
       Bit I of the mask is set if element I of the result should be
       loaded from memory and clear if element I of the result should be
       set to zero.
  
! ‘scatter_storeMN’
       Store a vector of mode M into several distinct memory locations.
       Operand 0 is a scalar base address and operand 1 is a vector of
       mode N containing offsets from that base.  Operand 4 is the vector
       of values that should be stored, which has the same number of
       elements as N.  For each element index I:
  
!         • extend the offset element I to address width, using zero
            extension if operand 2 is 1 and sign extension if operand 2 is
            zero;
!         • multiply the extended offset by operand 3;
!         • add the result to the base; and
!         • store element I of operand 4 to that address.
  
       The value of operand 2 does not matter if the offsets are already
       address width.
  
! ‘mask_scatter_storeMN’
!      Like ‘scatter_storeMN’, but takes an extra mask operand as operand
       5.  Bit I of the mask is set if element I of the result should be
       stored to memory.
  
! ‘vec_setM’
       Set given field in the vector value.  Operand 0 is the vector to
       modify, operand 1 is new value of field and operand 2 specify the
       field index.
  
! ‘vec_extractMN’
       Extract given field from the vector value.  Operand 1 is the
       vector, operand 2 specify field index and operand 0 place to store
       value into.  The N mode is the mode of the field or vector of
*************** pattern to accomplish a certain task.
*** 26556,26579 ****
       smaller number of elements.  If N is a vector mode, the index is
       counted in units of that mode.
  
! 'vec_initMN'
       Initialize the vector to given values.  Operand 0 is the vector to
       initialize and operand 1 is parallel containing values for
       individual fields.  The N mode is the mode of the elements, should
       be either element mode of the vector mode M, or a vector mode with
       the same element mode and smaller number of elements.
  
! 'vec_duplicateM'
       Initialize vector output operand 0 so that each element has the
       value given by scalar input operand 1.  The vector has mode M and
       the scalar has the mode appropriate for one element of M.
  
       This pattern only handles duplicates of non-constant inputs.
!      Constant vectors go through the 'movM' pattern instead.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'vec_seriesM'
       Initialize vector output operand 0 so that element I is equal to
       operand 1 plus I times operand 2.  In other words, create a linear
       series whose base value is operand 1 and whose step is operand 2.
--- 26555,26578 ----
       smaller number of elements.  If N is a vector mode, the index is
       counted in units of that mode.
  
! ‘vec_initMN’
       Initialize the vector to given values.  Operand 0 is the vector to
       initialize and operand 1 is parallel containing values for
       individual fields.  The N mode is the mode of the elements, should
       be either element mode of the vector mode M, or a vector mode with
       the same element mode and smaller number of elements.
  
! ‘vec_duplicateM’
       Initialize vector output operand 0 so that each element has the
       value given by scalar input operand 1.  The vector has mode M and
       the scalar has the mode appropriate for one element of M.
  
       This pattern only handles duplicates of non-constant inputs.
!      Constant vectors go through the ‘movM’ pattern instead.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘vec_seriesM’
       Initialize vector output operand 0 so that element I is equal to
       operand 1 plus I times operand 2.  In other words, create a linear
       series whose base value is operand 1 and whose step is operand 2.
*************** pattern to accomplish a certain task.
*** 26583,26596 ****
       floating-point vectors, in order to avoid having to specify the
       rounding behavior for I > 1.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'while_ultMN'
       Set operand 0 to a mask that is true while incrementing operand 1
       gives a value that is less than operand 2, for a vector length up
       to operand 3.  Operand 0 has mode N and operands 1 and 2 are scalar
       integers of mode M.  Operand 3 should be omitted when N is a vector
!      mode, and a 'CONST_INT' otherwise.  The operation for vector modes
       is equivalent to:
  
            operand0[0] = operand1 < operand2;
--- 26582,26595 ----
       floating-point vectors, in order to avoid having to specify the
       rounding behavior for I > 1.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘while_ultMN’
       Set operand 0 to a mask that is true while incrementing operand 1
       gives a value that is less than operand 2, for a vector length up
       to operand 3.  Operand 0 has mode N and operands 1 and 2 are scalar
       integers of mode M.  Operand 3 should be omitted when N is a vector
!      mode, and a ‘CONST_INT’ otherwise.  The operation for vector modes
       is equivalent to:
  
            operand0[0] = operand1 < operand2;
*************** pattern to accomplish a certain task.
*** 26603,26612 ****
            for (i = 1; i < operand3; i++)
              operand0[i] = operand0[i - 1] && (operand1 + i < operand2);
  
! 'check_raw_ptrsM'
       Check whether, given two pointers A and B and a length LEN, a write
       of LEN bytes at A followed by a read of LEN bytes at B can be split
!      into interleaved byte accesses 'A[0], B[0], A[1], B[1], ...'
       without affecting the dependencies between the bytes.  Set operand
       0 to true if the split is possible and false otherwise.
  
--- 26602,26611 ----
            for (i = 1; i < operand3; i++)
              operand0[i] = operand0[i - 1] && (operand1 + i < operand2);
  
! ‘check_raw_ptrsM’
       Check whether, given two pointers A and B and a length LEN, a write
       of LEN bytes at A followed by a read of LEN bytes at B can be split
!      into interleaved byte accesses ‘A[0], B[0], A[1], B[1], ...’
       without affecting the dependencies between the bytes.  Set operand
       0 to true if the split is possible and false otherwise.
  
*************** pattern to accomplish a certain task.
*** 26622,26651 ****
       accelerating the test without having to do the individual
       comparisons.
  
! 'check_war_ptrsM'
!      Like 'check_raw_ptrsM', but with the read and write swapped round.
       The split is possible in this case if:
  
            B <= A || A + LEN <= B
  
! 'vec_cmpMN'
       Output a vector comparison.  Operand 0 of mode N is the destination
       for predicate in operand 1 which is a signed vector comparison with
       operands of mode M in operands 2 and 3.  Predicate is computed by
       element-wise evaluation of the vector comparison with a truth value
       of all-ones and a false value of all-zeros.
  
! 'vec_cmpuMN'
!      Similar to 'vec_cmpMN' but perform unsigned vector comparison.
  
! 'vec_cmpeqMN'
!      Similar to 'vec_cmpMN' but perform equality or non-equality vector
!      comparison only.  If 'vec_cmpMN' or 'vec_cmpuMN' instruction
!      pattern is supported, it will be preferred over 'vec_cmpeqMN', so
       there is no need to define this instruction pattern if the others
       are supported.
  
! 'vcondMN'
       Output a conditional vector move.  Operand 0 is the destination to
       receive a combination of operand 1 and operand 2, which are of mode
       M, dependent on the outcome of the predicate in operand 3 which is
--- 26621,26650 ----
       accelerating the test without having to do the individual
       comparisons.
  
! ‘check_war_ptrsM’
!      Like ‘check_raw_ptrsM’, but with the read and write swapped round.
       The split is possible in this case if:
  
            B <= A || A + LEN <= B
  
! ‘vec_cmpMN’
       Output a vector comparison.  Operand 0 of mode N is the destination
       for predicate in operand 1 which is a signed vector comparison with
       operands of mode M in operands 2 and 3.  Predicate is computed by
       element-wise evaluation of the vector comparison with a truth value
       of all-ones and a false value of all-zeros.
  
! ‘vec_cmpuMN’
!      Similar to ‘vec_cmpMN’ but perform unsigned vector comparison.
  
! ‘vec_cmpeqMN’
!      Similar to ‘vec_cmpMN’ but perform equality or non-equality vector
!      comparison only.  If ‘vec_cmpMN’ or ‘vec_cmpuMN’ instruction
!      pattern is supported, it will be preferred over ‘vec_cmpeqMN’, so
       there is no need to define this instruction pattern if the others
       are supported.
  
! ‘vcondMN’
       Output a conditional vector move.  Operand 0 is the destination to
       receive a combination of operand 1 and operand 2, which are of mode
       M, dependent on the outcome of the predicate in operand 3 which is
*************** pattern to accomplish a certain task.
*** 26655,26694 ****
       computed by element-wise evaluation of the vector comparison with a
       truth value of all-ones and a false value of all-zeros.
  
! 'vconduMN'
!      Similar to 'vcondMN' but performs unsigned vector comparison.
  
! 'vcondeqMN'
!      Similar to 'vcondMN' but performs equality or non-equality vector
!      comparison only.  If 'vcondMN' or 'vconduMN' instruction pattern is
!      supported, it will be preferred over 'vcondeqMN', so there is no
       need to define this instruction pattern if the others are
       supported.
  
! 'vcond_mask_MN'
!      Similar to 'vcondMN' but operand 3 holds a pre-computed result of
       vector comparison.
  
! 'maskloadMN'
       Perform a masked load of vector from memory operand 1 of mode M
       into register operand 0.  Mask is provided in register operand 2 of
       mode N.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'maskstoreMN'
       Perform a masked store of vector from register operand 1 of mode M
       into memory operand 0.  Mask is provided in register operand 2 of
       mode N.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'len_load_M'
       Load (operand 2 - operand 3) elements from vector memory operand 1
       into vector register operand 0, setting the other elements of
       operand 0 to undefined values.  Operands 0 and 1 have mode M, which
       must be a vector mode.  Operand 2 has whichever integer mode the
!      target prefers.  Operand 3 conceptually has mode 'QI'.
  
       Operand 2 can be a variable or a constant amount.  Operand 3
       specifies a constant bias: it is either a constant 0 or a constant
--- 26654,26693 ----
       computed by element-wise evaluation of the vector comparison with a
       truth value of all-ones and a false value of all-zeros.
  
! ‘vconduMN’
!      Similar to ‘vcondMN’ but performs unsigned vector comparison.
  
! ‘vcondeqMN’
!      Similar to ‘vcondMN’ but performs equality or non-equality vector
!      comparison only.  If ‘vcondMN’ or ‘vconduMN’ instruction pattern is
!      supported, it will be preferred over ‘vcondeqMN’, so there is no
       need to define this instruction pattern if the others are
       supported.
  
! ‘vcond_mask_MN’
!      Similar to ‘vcondMN’ but operand 3 holds a pre-computed result of
       vector comparison.
  
! ‘maskloadMN’
       Perform a masked load of vector from memory operand 1 of mode M
       into register operand 0.  Mask is provided in register operand 2 of
       mode N.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘maskstoreMN’
       Perform a masked store of vector from register operand 1 of mode M
       into memory operand 0.  Mask is provided in register operand 2 of
       mode N.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘len_load_M’
       Load (operand 2 - operand 3) elements from vector memory operand 1
       into vector register operand 0, setting the other elements of
       operand 0 to undefined values.  Operands 0 and 1 have mode M, which
       must be a vector mode.  Operand 2 has whichever integer mode the
!      target prefers.  Operand 3 conceptually has mode ‘QI’.
  
       Operand 2 can be a variable or a constant amount.  Operand 3
       specifies a constant bias: it is either a constant 0 or a constant
*************** pattern to accomplish a certain task.
*** 26701,26716 ****
  
       If the target prefers the length to be measured in bytes rather
       than elements, it should only implement this pattern for vectors of
!      'QI' elements.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'len_store_M'
       Store (operand 2 - operand 3) vector elements from vector register
       operand 1 into memory operand 0, leaving the other elements of
       operand 0 unchanged.  Operands 0 and 1 have mode M, which must be a
       vector mode.  Operand 2 has whichever integer mode the target
!      prefers.  Operand 3 conceptually has mode 'QI'.
  
       Operand 2 can be a variable or a constant amount.  Operand 3
       specifies a constant bias: it is either a constant 0 or a constant
--- 26700,26715 ----
  
       If the target prefers the length to be measured in bytes rather
       than elements, it should only implement this pattern for vectors of
!      ‘QI’ elements.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘len_store_M’
       Store (operand 2 - operand 3) vector elements from vector register
       operand 1 into memory operand 0, leaving the other elements of
       operand 0 unchanged.  Operands 0 and 1 have mode M, which must be a
       vector mode.  Operand 2 has whichever integer mode the target
!      prefers.  Operand 3 conceptually has mode ‘QI’.
  
       Operand 2 can be a variable or a constant amount.  Operand 3
       specifies a constant bias: it is either a constant 0 or a constant
*************** pattern to accomplish a certain task.
*** 26723,26898 ****
  
       If the target prefers the length to be measured in bytes rather
       than elements, it should only implement this pattern for vectors of
!      'QI' elements.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'vec_permM'
       Output a (variable) vector permutation.  Operand 0 is the
       destination to receive elements from operand 1 and operand 2, which
!      are of mode M.  Operand 3 is the "selector".  It is an integral
       mode vector of the same width and number of elements as mode M.
  
       The input elements are numbered from 0 in operand 1 through 2*N-1
       in operand 2.  The elements of the selector must be computed modulo
!      2*N.  Note that if 'rtx_equal_p(operand1, operand2)', this can be
       implemented with just operand 1 and selector elements modulo N.
  
       In order to make things easy for a number of targets, if there is
!      no 'vec_perm' pattern for mode M, but there is for mode Q where Q
!      is a vector of 'QImode' of the same width as M, the middle-end will
!      lower the mode M 'VEC_PERM_EXPR' to mode Q.
  
!      See also 'TARGET_VECTORIZER_VEC_PERM_CONST', which performs the
       analogous operation for constant selectors.
  
! 'pushM1'
       Output a push instruction.  Operand 0 is value to push.  Used only
!      when 'PUSH_ROUNDING' is defined.  For historical reason, this
!      pattern may be missing and in such case an 'mov' expander is used
!      instead, with a 'MEM' expression forming the push operation.  The
!      'mov' expander method is deprecated.
  
! 'addM3'
       Add operand 2 and operand 1, storing the result in operand 0.  All
       operands must have mode M.  This can be used even on two-address
       machines, by means of constraints requiring operands 1 and 0 to be
       the same location.
  
! 'ssaddM3', 'usaddM3'
! 'subM3', 'sssubM3', 'ussubM3'
! 'mulM3', 'ssmulM3', 'usmulM3'
! 'divM3', 'ssdivM3'
! 'udivM3', 'usdivM3'
! 'modM3', 'umodM3'
! 'uminM3', 'umaxM3'
! 'andM3', 'iorM3', 'xorM3'
       Similar, for other arithmetic operations.
  
! 'addvM4'
!      Like 'addM3' but takes a 'code_label' as operand 3 and emits code
       to jump to it if signed overflow occurs during the addition.  This
       pattern is used to implement the built-in functions performing
       signed integer addition with overflow checking.
  
! 'subvM4', 'mulvM4'
       Similar, for other signed arithmetic operations.
  
! 'uaddvM4'
!      Like 'addvM4' but for unsigned addition.  That is to say, the
       operation is the same as signed addition but the jump is taken only
       on unsigned overflow.
  
! 'usubvM4', 'umulvM4'
       Similar, for other unsigned arithmetic operations.
  
! 'addptrM3'
!      Like 'addM3' but is guaranteed to only be used for address
       calculations.  The expanded code is not allowed to clobber the
!      condition code.  It only needs to be defined if 'addM3' sets the
       condition code.  If adds used for address calculations and normal
       adds are not compatible it is required to expand a distinct pattern
       (e.g. using an unspec).  The pattern is used by LRA to emit address
!      calculations.  'addM3' is used if 'addptrM3' is not defined.
  
! 'fmaM4'
       Multiply operand 2 and operand 1, then add operand 3, storing the
       result in operand 0 without doing an intermediate rounding step.
       All operands must have mode M.  This pattern is used to implement
!      the 'fma', 'fmaf', and 'fmal' builtin functions from the ISO C99
       standard.
  
! 'fmsM4'
!      Like 'fmaM4', except operand 3 subtracted from the product instead
       of added to the product.  This is represented in the rtl as
  
            (fma:M OP1 OP2 (neg:M OP3))
  
! 'fnmaM4'
!      Like 'fmaM4' except that the intermediate product is negated before
       being added to operand 3.  This is represented in the rtl as
  
            (fma:M (neg:M OP1) OP2 OP3)
  
! 'fnmsM4'
!      Like 'fmsM4' except that the intermediate product is negated before
       subtracting operand 3.  This is represented in the rtl as
  
            (fma:M (neg:M OP1) OP2 (neg:M OP3))
  
! 'sminM3', 'smaxM3'
       Signed minimum and maximum operations.  When used with floating
!      point, if both operands are zeros, or if either operand is 'NaN',
       then it is unspecified which of the two operands is returned as the
       result.
  
! 'fminM3', 'fmaxM3'
       IEEE-conformant minimum and maximum operations.  If one operand is
!      a quiet 'NaN', then the other operand is returned.  If both
!      operands are quiet 'NaN', then a quiet 'NaN' is returned.  In the
!      case when gcc supports signaling 'NaN' (-fsignaling-nans) an
!      invalid floating point exception is raised and a quiet 'NaN' is
       returned.
  
       All operands have mode M, which is a scalar or vector
!      floating-point mode.  These patterns are not allowed to 'FAIL'.
  
! 'reduc_smin_scal_M', 'reduc_smax_scal_M'
       Find the signed minimum/maximum of the elements of a vector.  The
       vector is operand 1, and operand 0 is the scalar result, with mode
       equal to the mode of the elements of the input vector.
  
! 'reduc_umin_scal_M', 'reduc_umax_scal_M'
       Find the unsigned minimum/maximum of the elements of a vector.  The
       vector is operand 1, and operand 0 is the scalar result, with mode
       equal to the mode of the elements of the input vector.
  
! 'reduc_fmin_scal_M', 'reduc_fmax_scal_M'
       Find the floating-point minimum/maximum of the elements of a
!      vector, using the same rules as 'fminM3' and 'fmaxM3'.  Operand 1
       is a vector of mode M and operand 0 is the scalar result, which has
!      mode 'GET_MODE_INNER (M)'.
  
! 'reduc_plus_scal_M'
       Compute the sum of the elements of a vector.  The vector is operand
       1, and operand 0 is the scalar result, with mode equal to the mode
       of the elements of the input vector.
  
! 'reduc_and_scal_M'
! 'reduc_ior_scal_M'
! 'reduc_xor_scal_M'
!      Compute the bitwise 'AND'/'IOR'/'XOR' reduction of the elements of
       a vector of mode M.  Operand 1 is the vector input and operand 0 is
       the scalar result.  The mode of the scalar result is the same as
       one element of M.
  
! 'extract_last_M'
       Find the last set bit in mask operand 1 and extract the associated
       element of vector operand 2.  Store the result in scalar operand 0.
       Operand 2 has vector mode M while operand 0 has the mode
       appropriate for one element of M.  Operand 1 has the usual mask
!      mode for vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'.
  
! 'fold_extract_last_M'
       If any bits of mask operand 2 are set, find the last set bit,
       extract the associated element from vector operand 3, and store the
       result in operand 0.  Store operand 1 in operand 0 otherwise.
       Operand 3 has mode M and operands 0 and 1 have the mode appropriate
       for one element of M.  Operand 2 has the usual mask mode for
!      vectors of mode M; see 'TARGET_VECTORIZE_GET_MASK_MODE'.
  
! 'fold_left_plus_M'
       Take scalar operand 1 and successively add each element from vector
       operand 2.  Store the result in scalar operand 0.  The vector has
       mode M and the scalars have the mode appropriate for one element of
       M.  The operation is strictly in-order: there is no reassociation.
  
! 'mask_fold_left_plus_M'
!      Like 'fold_left_plus_M', but takes an additional mask operand
       (operand 3) that specifies which elements of the source vector
       should be added.
  
! 'sdot_prodM'
  
       Compute the sum of the products of two signed elements.  Operand 1
       and operand 2 are of the same mode.  Their product, which is of a
--- 26722,26897 ----
  
       If the target prefers the length to be measured in bytes rather
       than elements, it should only implement this pattern for vectors of
!      ‘QI’ elements.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘vec_permM’
       Output a (variable) vector permutation.  Operand 0 is the
       destination to receive elements from operand 1 and operand 2, which
!      are of mode M.  Operand 3 is the “selector”.  It is an integral
       mode vector of the same width and number of elements as mode M.
  
       The input elements are numbered from 0 in operand 1 through 2*N-1
       in operand 2.  The elements of the selector must be computed modulo
!      2*N.  Note that if ‘rtx_equal_p(operand1, operand2)’, this can be
       implemented with just operand 1 and selector elements modulo N.
  
       In order to make things easy for a number of targets, if there is
!      no ‘vec_perm’ pattern for mode M, but there is for mode Q where Q
!      is a vector of ‘QImode’ of the same width as M, the middle-end will
!      lower the mode M ‘VEC_PERM_EXPR’ to mode Q.
  
!      See also ‘TARGET_VECTORIZER_VEC_PERM_CONST’, which performs the
       analogous operation for constant selectors.
  
! ‘pushM1’
       Output a push instruction.  Operand 0 is value to push.  Used only
!      when ‘PUSH_ROUNDING’ is defined.  For historical reason, this
!      pattern may be missing and in such case an ‘mov’ expander is used
!      instead, with a ‘MEM’ expression forming the push operation.  The
!      ‘mov’ expander method is deprecated.
  
! ‘addM3’
       Add operand 2 and operand 1, storing the result in operand 0.  All
       operands must have mode M.  This can be used even on two-address
       machines, by means of constraints requiring operands 1 and 0 to be
       the same location.
  
! ‘ssaddM3’, ‘usaddM3’
! ‘subM3’, ‘sssubM3’, ‘ussubM3’
! ‘mulM3’, ‘ssmulM3’, ‘usmulM3’
! ‘divM3’, ‘ssdivM3’
! ‘udivM3’, ‘usdivM3’
! ‘modM3’, ‘umodM3’
! ‘uminM3’, ‘umaxM3’
! ‘andM3’, ‘iorM3’, ‘xorM3’
       Similar, for other arithmetic operations.
  
! ‘addvM4’
!      Like ‘addM3’ but takes a ‘code_label’ as operand 3 and emits code
       to jump to it if signed overflow occurs during the addition.  This
       pattern is used to implement the built-in functions performing
       signed integer addition with overflow checking.
  
! ‘subvM4’, ‘mulvM4’
       Similar, for other signed arithmetic operations.
  
! ‘uaddvM4’
!      Like ‘addvM4’ but for unsigned addition.  That is to say, the
       operation is the same as signed addition but the jump is taken only
       on unsigned overflow.
  
! ‘usubvM4’, ‘umulvM4’
       Similar, for other unsigned arithmetic operations.
  
! ‘addptrM3’
!      Like ‘addM3’ but is guaranteed to only be used for address
       calculations.  The expanded code is not allowed to clobber the
!      condition code.  It only needs to be defined if ‘addM3’ sets the
       condition code.  If adds used for address calculations and normal
       adds are not compatible it is required to expand a distinct pattern
       (e.g. using an unspec).  The pattern is used by LRA to emit address
!      calculations.  ‘addM3’ is used if ‘addptrM3’ is not defined.
  
! ‘fmaM4’
       Multiply operand 2 and operand 1, then add operand 3, storing the
       result in operand 0 without doing an intermediate rounding step.
       All operands must have mode M.  This pattern is used to implement
!      the ‘fma’, ‘fmaf’, and ‘fmal’ builtin functions from the ISO C99
       standard.
  
! ‘fmsM4’
!      Like ‘fmaM4’, except operand 3 subtracted from the product instead
       of added to the product.  This is represented in the rtl as
  
            (fma:M OP1 OP2 (neg:M OP3))
  
! ‘fnmaM4’
!      Like ‘fmaM4’ except that the intermediate product is negated before
       being added to operand 3.  This is represented in the rtl as
  
            (fma:M (neg:M OP1) OP2 OP3)
  
! ‘fnmsM4’
!      Like ‘fmsM4’ except that the intermediate product is negated before
       subtracting operand 3.  This is represented in the rtl as
  
            (fma:M (neg:M OP1) OP2 (neg:M OP3))
  
! ‘sminM3’, ‘smaxM3’
       Signed minimum and maximum operations.  When used with floating
!      point, if both operands are zeros, or if either operand is ‘NaN’,
       then it is unspecified which of the two operands is returned as the
       result.
  
! ‘fminM3’, ‘fmaxM3’
       IEEE-conformant minimum and maximum operations.  If one operand is
!      a quiet ‘NaN’, then the other operand is returned.  If both
!      operands are quiet ‘NaN’, then a quiet ‘NaN’ is returned.  In the
!      case when gcc supports signaling ‘NaN’ (-fsignaling-nans) an
!      invalid floating point exception is raised and a quiet ‘NaN’ is
       returned.
  
       All operands have mode M, which is a scalar or vector
!      floating-point mode.  These patterns are not allowed to ‘FAIL’.
  
! ‘reduc_smin_scal_M’, ‘reduc_smax_scal_M’
       Find the signed minimum/maximum of the elements of a vector.  The
       vector is operand 1, and operand 0 is the scalar result, with mode
       equal to the mode of the elements of the input vector.
  
! ‘reduc_umin_scal_M’, ‘reduc_umax_scal_M’
       Find the unsigned minimum/maximum of the elements of a vector.  The
       vector is operand 1, and operand 0 is the scalar result, with mode
       equal to the mode of the elements of the input vector.
  
! ‘reduc_fmin_scal_M’, ‘reduc_fmax_scal_M’
       Find the floating-point minimum/maximum of the elements of a
!      vector, using the same rules as ‘fminM3’ and ‘fmaxM3’.  Operand 1
       is a vector of mode M and operand 0 is the scalar result, which has
!      mode ‘GET_MODE_INNER (M)’.
  
! ‘reduc_plus_scal_M’
       Compute the sum of the elements of a vector.  The vector is operand
       1, and operand 0 is the scalar result, with mode equal to the mode
       of the elements of the input vector.
  
! ‘reduc_and_scal_M’
! ‘reduc_ior_scal_M’
! ‘reduc_xor_scal_M’
!      Compute the bitwise ‘AND’/‘IOR’/‘XOR’ reduction of the elements of
       a vector of mode M.  Operand 1 is the vector input and operand 0 is
       the scalar result.  The mode of the scalar result is the same as
       one element of M.
  
! ‘extract_last_M’
       Find the last set bit in mask operand 1 and extract the associated
       element of vector operand 2.  Store the result in scalar operand 0.
       Operand 2 has vector mode M while operand 0 has the mode
       appropriate for one element of M.  Operand 1 has the usual mask
!      mode for vectors of mode M; see ‘TARGET_VECTORIZE_GET_MASK_MODE’.
  
! ‘fold_extract_last_M’
       If any bits of mask operand 2 are set, find the last set bit,
       extract the associated element from vector operand 3, and store the
       result in operand 0.  Store operand 1 in operand 0 otherwise.
       Operand 3 has mode M and operands 0 and 1 have the mode appropriate
       for one element of M.  Operand 2 has the usual mask mode for
!      vectors of mode M; see ‘TARGET_VECTORIZE_GET_MASK_MODE’.
  
! ‘fold_left_plus_M’
       Take scalar operand 1 and successively add each element from vector
       operand 2.  Store the result in scalar operand 0.  The vector has
       mode M and the scalars have the mode appropriate for one element of
       M.  The operation is strictly in-order: there is no reassociation.
  
! ‘mask_fold_left_plus_M’
!      Like ‘fold_left_plus_M’, but takes an additional mask operand
       (operand 3) that specifies which elements of the source vector
       should be added.
  
! ‘sdot_prodM’
  
       Compute the sum of the products of two signed elements.  Operand 1
       and operand 2 are of the same mode.  Their product, which is of a
*************** pattern to accomplish a certain task.
*** 26907,26913 ****
               op0 = sign-ext (op1) * sign-ext (op2) + op3
            ...
  
! 'udot_prodM'
  
       Compute the sum of the products of two unsigned elements.  Operand
       1 and operand 2 are of the same mode.  Their product, which is of a
--- 26906,26912 ----
               op0 = sign-ext (op1) * sign-ext (op2) + op3
            ...
  
! ‘udot_prodM’
  
       Compute the sum of the products of two unsigned elements.  Operand
       1 and operand 2 are of the same mode.  Their product, which is of a
*************** pattern to accomplish a certain task.
*** 26922,26928 ****
               op0 = zero-ext (op1) * zero-ext (op2) + op3
            ...
  
! 'usdot_prodM'
       Compute the sum of the products of elements of different signs.
       Operand 1 must be unsigned and operand 2 signed.  Their product,
       which is of a wider mode, is computed and added to operand 3.
--- 26921,26927 ----
               op0 = zero-ext (op1) * zero-ext (op2) + op3
            ...
  
! ‘usdot_prodM’
       Compute the sum of the products of elements of different signs.
       Operand 1 must be unsigned and operand 2 signed.  Their product,
       which is of a wider mode, is computed and added to operand 3.
*************** pattern to accomplish a certain task.
*** 26937,26944 ****
               op0 = ((signed-conv) zero-ext (op1)) * sign-ext (op2) + op3
            ...
  
! 'ssadM'
! 'usadM'
       Compute the sum of absolute differences of two signed/unsigned
       elements.  Operand 1 and operand 2 are of the same mode.  Their
       absolute difference, which is of a wider mode, is computed and
--- 26936,26943 ----
               op0 = ((signed-conv) zero-ext (op1)) * sign-ext (op2) + op3
            ...
  
! ‘ssadM’
! ‘usadM’
       Compute the sum of absolute differences of two signed/unsigned
       elements.  Operand 1 and operand 2 are of the same mode.  Their
       absolute difference, which is of a wider mode, is computed and
*************** pattern to accomplish a certain task.
*** 26946,27066 ****
       mode of the absolute difference.  The result is placed in operand
       0, which is of the same mode as operand 3.
  
! 'widen_ssumM3'
! 'widen_usumM3'
       Operands 0 and 2 are of the same mode, which is wider than the mode
       of operand 1.  Add operand 1 to operand 2 and place the widened
       result in operand 0.  (This is used express accumulation of
       elements into an accumulator of a wider mode.)
  
! 'smulhsM3'
! 'umulhsM3'
       Signed/unsigned multiply high with scale.  This is equivalent to
       the C code:
            narrow op0, op1, op2;
            ...
            op0 = (narrow) (((wide) op1 * (wide) op2) >> (N / 2 - 1));
!      where the sign of 'narrow' determines whether this is a signed or
!      unsigned operation, and N is the size of 'wide' in bits.
  
! 'smulhrsM3'
! 'umulhrsM3'
       Signed/unsigned multiply high with round and scale.  This is
       equivalent to the C code:
            narrow op0, op1, op2;
            ...
            op0 = (narrow) (((((wide) op1 * (wide) op2) >> (N / 2 - 2)) + 1) >> 1);
!      where the sign of 'narrow' determines whether this is a signed or
!      unsigned operation, and N is the size of 'wide' in bits.
  
! 'sdiv_pow2M3'
! 'sdiv_pow2M3'
       Signed division by power-of-2 immediate.  Equivalent to:
            signed op0, op1;
            ...
            op0 = op1 / (1 << imm);
  
! 'vec_shl_insert_M'
       Shift the elements in vector input operand 1 left one element (i.e.
       away from element 0) and fill the vacated element 0 with the scalar
       in operand 2.  Store the result in vector output operand 0.
       Operands 0 and 1 have mode M and operand 2 has the mode appropriate
       for one element of M.
  
! 'vec_shl_M'
       Whole vector left shift in bits, i.e. away from element 0.  Operand
       1 is a vector to be shifted.  Operand 2 is an integer shift amount
       in bits.  Operand 0 is where the resulting shifted vector is
       stored.  The output and input vectors should have the same modes.
  
! 'vec_shr_M'
       Whole vector right shift in bits, i.e. towards element 0.  Operand
       1 is a vector to be shifted.  Operand 2 is an integer shift amount
       in bits.  Operand 0 is where the resulting shifted vector is
       stored.  The output and input vectors should have the same modes.
  
! 'vec_pack_trunc_M'
       Narrow (demote) and merge the elements of two vectors.  Operands 1
       and 2 are vectors of the same mode having N integral or floating
       point elements of size S.  Operand 0 is the resulting vector in
       which 2*N elements of size S/2 are concatenated after narrowing
       them down using truncation.
  
! 'vec_pack_sbool_trunc_M'
       Narrow and merge the elements of two vectors.  Operands 1 and 2 are
       vectors of the same type having N boolean elements.  Operand 0 is
       the resulting vector in which 2*N elements are concatenated.  The
       last operand (operand 3) is the number of elements in the output
!      vector 2*N as a 'CONST_INT'.  This instruction pattern is used when
       all the vector input and output operands have the same scalar mode
!      M and thus using 'vec_pack_trunc_M' would be ambiguous.
  
! 'vec_pack_ssat_M', 'vec_pack_usat_M'
       Narrow (demote) and merge the elements of two vectors.  Operands 1
       and 2 are vectors of the same mode having N integral elements of
       size S. Operand 0 is the resulting vector in which the elements of
       the two input vectors are concatenated after narrowing them down
       using signed/unsigned saturating arithmetic.
  
! 'vec_pack_sfix_trunc_M', 'vec_pack_ufix_trunc_M'
       Narrow, convert to signed/unsigned integral type and merge the
       elements of two vectors.  Operands 1 and 2 are vectors of the same
       mode having N floating point elements of size S.  Operand 0 is the
       resulting vector in which 2*N elements of size S/2 are
       concatenated.
  
! 'vec_packs_float_M', 'vec_packu_float_M'
       Narrow, convert to floating point type and merge the elements of
       two vectors.  Operands 1 and 2 are vectors of the same mode having
       N signed/unsigned integral elements of size S.  Operand 0 is the
       resulting vector in which 2*N elements of size S/2 are
       concatenated.
  
! 'vec_unpacks_hi_M', 'vec_unpacks_lo_M'
       Extract and widen (promote) the high/low part of a vector of signed
       integral or floating point elements.  The input vector (operand 1)
       has N elements of size S.  Widen (promote) the high/low elements of
       the vector using signed or floating point extension and place the
       resulting N/2 values of size 2*S in the output vector (operand 0).
  
! 'vec_unpacku_hi_M', 'vec_unpacku_lo_M'
       Extract and widen (promote) the high/low part of a vector of
       unsigned integral elements.  The input vector (operand 1) has N
       elements of size S. Widen (promote) the high/low elements of the
       vector using zero extension and place the resulting N/2 values of
       size 2*S in the output vector (operand 0).
  
! 'vec_unpacks_sbool_hi_M', 'vec_unpacks_sbool_lo_M'
       Extract the high/low part of a vector of boolean elements that have
       scalar mode M.  The input vector (operand 1) has N elements, the
       output vector (operand 0) has N/2 elements.  The last operand
       (operand 2) is the number of elements of the input vector N as a
!      'CONST_INT'.  These patterns are used if both the input and output
       vectors have the same scalar mode M and thus using
!      'vec_unpacks_hi_M' or 'vec_unpacks_lo_M' would be ambiguous.
  
! 'vec_unpacks_float_hi_M', 'vec_unpacks_float_lo_M'
! 'vec_unpacku_float_hi_M', 'vec_unpacku_float_lo_M'
       Extract, convert to floating point type and widen the high/low part
       of a vector of signed/unsigned integral elements.  The input vector
       (operand 1) has N elements of size S.  Convert the high/low
--- 26945,27065 ----
       mode of the absolute difference.  The result is placed in operand
       0, which is of the same mode as operand 3.
  
! ‘widen_ssumM3’
! ‘widen_usumM3’
       Operands 0 and 2 are of the same mode, which is wider than the mode
       of operand 1.  Add operand 1 to operand 2 and place the widened
       result in operand 0.  (This is used express accumulation of
       elements into an accumulator of a wider mode.)
  
! ‘smulhsM3’
! ‘umulhsM3’
       Signed/unsigned multiply high with scale.  This is equivalent to
       the C code:
            narrow op0, op1, op2;
            ...
            op0 = (narrow) (((wide) op1 * (wide) op2) >> (N / 2 - 1));
!      where the sign of ‘narrow’ determines whether this is a signed or
!      unsigned operation, and N is the size of ‘wide’ in bits.
  
! ‘smulhrsM3’
! ‘umulhrsM3’
       Signed/unsigned multiply high with round and scale.  This is
       equivalent to the C code:
            narrow op0, op1, op2;
            ...
            op0 = (narrow) (((((wide) op1 * (wide) op2) >> (N / 2 - 2)) + 1) >> 1);
!      where the sign of ‘narrow’ determines whether this is a signed or
!      unsigned operation, and N is the size of ‘wide’ in bits.
  
! ‘sdiv_pow2M3’
! ‘sdiv_pow2M3’
       Signed division by power-of-2 immediate.  Equivalent to:
            signed op0, op1;
            ...
            op0 = op1 / (1 << imm);
  
! ‘vec_shl_insert_M’
       Shift the elements in vector input operand 1 left one element (i.e.
       away from element 0) and fill the vacated element 0 with the scalar
       in operand 2.  Store the result in vector output operand 0.
       Operands 0 and 1 have mode M and operand 2 has the mode appropriate
       for one element of M.
  
! ‘vec_shl_M’
       Whole vector left shift in bits, i.e. away from element 0.  Operand
       1 is a vector to be shifted.  Operand 2 is an integer shift amount
       in bits.  Operand 0 is where the resulting shifted vector is
       stored.  The output and input vectors should have the same modes.
  
! ‘vec_shr_M’
       Whole vector right shift in bits, i.e. towards element 0.  Operand
       1 is a vector to be shifted.  Operand 2 is an integer shift amount
       in bits.  Operand 0 is where the resulting shifted vector is
       stored.  The output and input vectors should have the same modes.
  
! ‘vec_pack_trunc_M’
       Narrow (demote) and merge the elements of two vectors.  Operands 1
       and 2 are vectors of the same mode having N integral or floating
       point elements of size S.  Operand 0 is the resulting vector in
       which 2*N elements of size S/2 are concatenated after narrowing
       them down using truncation.
  
! ‘vec_pack_sbool_trunc_M’
       Narrow and merge the elements of two vectors.  Operands 1 and 2 are
       vectors of the same type having N boolean elements.  Operand 0 is
       the resulting vector in which 2*N elements are concatenated.  The
       last operand (operand 3) is the number of elements in the output
!      vector 2*N as a ‘CONST_INT’.  This instruction pattern is used when
       all the vector input and output operands have the same scalar mode
!      M and thus using ‘vec_pack_trunc_M’ would be ambiguous.
  
! ‘vec_pack_ssat_M’, ‘vec_pack_usat_M’
       Narrow (demote) and merge the elements of two vectors.  Operands 1
       and 2 are vectors of the same mode having N integral elements of
       size S. Operand 0 is the resulting vector in which the elements of
       the two input vectors are concatenated after narrowing them down
       using signed/unsigned saturating arithmetic.
  
! ‘vec_pack_sfix_trunc_M’, ‘vec_pack_ufix_trunc_M’
       Narrow, convert to signed/unsigned integral type and merge the
       elements of two vectors.  Operands 1 and 2 are vectors of the same
       mode having N floating point elements of size S.  Operand 0 is the
       resulting vector in which 2*N elements of size S/2 are
       concatenated.
  
! ‘vec_packs_float_M’, ‘vec_packu_float_M’
       Narrow, convert to floating point type and merge the elements of
       two vectors.  Operands 1 and 2 are vectors of the same mode having
       N signed/unsigned integral elements of size S.  Operand 0 is the
       resulting vector in which 2*N elements of size S/2 are
       concatenated.
  
! ‘vec_unpacks_hi_M’, ‘vec_unpacks_lo_M’
       Extract and widen (promote) the high/low part of a vector of signed
       integral or floating point elements.  The input vector (operand 1)
       has N elements of size S.  Widen (promote) the high/low elements of
       the vector using signed or floating point extension and place the
       resulting N/2 values of size 2*S in the output vector (operand 0).
  
! ‘vec_unpacku_hi_M’, ‘vec_unpacku_lo_M’
       Extract and widen (promote) the high/low part of a vector of
       unsigned integral elements.  The input vector (operand 1) has N
       elements of size S. Widen (promote) the high/low elements of the
       vector using zero extension and place the resulting N/2 values of
       size 2*S in the output vector (operand 0).
  
! ‘vec_unpacks_sbool_hi_M’, ‘vec_unpacks_sbool_lo_M’
       Extract the high/low part of a vector of boolean elements that have
       scalar mode M.  The input vector (operand 1) has N elements, the
       output vector (operand 0) has N/2 elements.  The last operand
       (operand 2) is the number of elements of the input vector N as a
!      ‘CONST_INT’.  These patterns are used if both the input and output
       vectors have the same scalar mode M and thus using
!      ‘vec_unpacks_hi_M’ or ‘vec_unpacks_lo_M’ would be ambiguous.
  
! ‘vec_unpacks_float_hi_M’, ‘vec_unpacks_float_lo_M’
! ‘vec_unpacku_float_hi_M’, ‘vec_unpacku_float_lo_M’
       Extract, convert to floating point type and widen the high/low part
       of a vector of signed/unsigned integral elements.  The input vector
       (operand 1) has N elements of size S.  Convert the high/low
*************** pattern to accomplish a certain task.
*** 27068,27087 ****
       the resulting N/2 values of size 2*S in the output vector (operand
       0).
  
! 'vec_unpack_sfix_trunc_hi_M',
! 'vec_unpack_sfix_trunc_lo_M'
! 'vec_unpack_ufix_trunc_hi_M'
! 'vec_unpack_ufix_trunc_lo_M'
       Extract, convert to signed/unsigned integer type and widen the
       high/low part of a vector of floating point elements.  The input
       vector (operand 1) has N elements of size S.  Convert the high/low
       elements of the vector to integers and place the resulting N/2
       values of size 2*S in the output vector (operand 0).
  
! 'vec_widen_umult_hi_M', 'vec_widen_umult_lo_M'
! 'vec_widen_smult_hi_M', 'vec_widen_smult_lo_M'
! 'vec_widen_umult_even_M', 'vec_widen_umult_odd_M'
! 'vec_widen_smult_even_M', 'vec_widen_smult_odd_M'
       Signed/Unsigned widening multiplication.  The two inputs (operands
       1 and 2) are vectors with N signed/unsigned elements of size S.
       Multiply the high/low or even/odd elements of the two vectors, and
--- 27067,27086 ----
       the resulting N/2 values of size 2*S in the output vector (operand
       0).
  
! ‘vec_unpack_sfix_trunc_hi_M’,
! ‘vec_unpack_sfix_trunc_lo_M’
! ‘vec_unpack_ufix_trunc_hi_M’
! ‘vec_unpack_ufix_trunc_lo_M’
       Extract, convert to signed/unsigned integer type and widen the
       high/low part of a vector of floating point elements.  The input
       vector (operand 1) has N elements of size S.  Convert the high/low
       elements of the vector to integers and place the resulting N/2
       values of size 2*S in the output vector (operand 0).
  
! ‘vec_widen_umult_hi_M’, ‘vec_widen_umult_lo_M’
! ‘vec_widen_smult_hi_M’, ‘vec_widen_smult_lo_M’
! ‘vec_widen_umult_even_M’, ‘vec_widen_umult_odd_M’
! ‘vec_widen_smult_even_M’, ‘vec_widen_smult_odd_M’
       Signed/Unsigned widening multiplication.  The two inputs (operands
       1 and 2) are vectors with N signed/unsigned elements of size S.
       Multiply the high/low or even/odd elements of the two vectors, and
*************** pattern to accomplish a certain task.
*** 27089,27250 ****
       A target shouldn't implement even/odd pattern pair if it is less
       efficient than lo/hi one.
  
! 'vec_widen_ushiftl_hi_M', 'vec_widen_ushiftl_lo_M'
! 'vec_widen_sshiftl_hi_M', 'vec_widen_sshiftl_lo_M'
       Signed/Unsigned widening shift left.  The first input (operand 1)
       is a vector with N signed/unsigned elements of size S.  Operand 2
       is a constant.  Shift the high/low elements of operand 1, and put
       the N/2 results of size 2*S in the output vector (operand 0).
  
! 'vec_widen_uaddl_hi_M', 'vec_widen_uaddl_lo_M'
! 'vec_widen_saddl_hi_M', 'vec_widen_saddl_lo_M'
       Signed/Unsigned widening add long.  Operands 1 and 2 are vectors
       with N signed/unsigned elements of size S.  Add the high/low
       elements of 1 and 2 together, widen the resulting elements and put
       the N/2 results of size 2*S in the output vector (operand 0).
  
! 'vec_widen_usubl_hi_M', 'vec_widen_usubl_lo_M'
! 'vec_widen_ssubl_hi_M', 'vec_widen_ssubl_lo_M'
       Signed/Unsigned widening subtract long.  Operands 1 and 2 are
       vectors with N signed/unsigned elements of size S.  Subtract the
       high/low elements of 2 from 1 and widen the resulting elements.
       Put the N/2 results of size 2*S in the output vector (operand 0).
  
! 'vec_addsubM3'
       Alternating subtract, add with even lanes doing subtract and odd
       lanes doing addition.  Operands 1 and 2 and the outout operand are
       vectors with mode M.
  
! 'vec_fmaddsubM4'
       Alternating multiply subtract, add with even lanes doing subtract
       and odd lanes doing addition of the third operand to the
       multiplication result of the first two operands.  Operands 1, 2 and
       3 and the outout operand are vectors with mode M.
  
! 'vec_fmsubaddM4'
       Alternating multiply add, subtract with even lanes doing addition
       and odd lanes doing subtraction of the third operand to the
       multiplication result of the first two operands.  Operands 1, 2 and
       3 and the outout operand are vectors with mode M.
  
!      These instructions are not allowed to 'FAIL'.
  
! 'mulhisi3'
!      Multiply operands 1 and 2, which have mode 'HImode', and store a
!      'SImode' product in operand 0.
  
! 'mulqihi3', 'mulsidi3'
       Similar widening-multiplication instructions of other widths.
  
! 'umulqihi3', 'umulhisi3', 'umulsidi3'
       Similar widening-multiplication instructions that do unsigned
       multiplication.
  
! 'usmulqihi3', 'usmulhisi3', 'usmulsidi3'
       Similar widening-multiplication instructions that interpret the
       first operand as unsigned and the second operand as signed, then do
       a signed multiplication.
  
! 'smulM3_highpart'
       Perform a signed multiplication of operands 1 and 2, which have
       mode M, and store the most significant half of the product in
       operand 0.  The least significant half of the product is discarded.
!      This may be represented in RTL using a 'smul_highpart' RTX
       expression.
  
! 'umulM3_highpart'
       Similar, but the multiplication is unsigned.  This may be
!      represented in RTL using an 'umul_highpart' RTX expression.
  
! 'maddMN4'
       Multiply operands 1 and 2, sign-extend them to mode N, add operand
       3, and store the result in operand 0.  Operands 1 and 2 have mode M
       and operands 0 and 3 have mode N.  Both modes must be integer or
       fixed-point modes and N must be twice the size of M.
  
!      In other words, 'maddMN4' is like 'mulMN3' except that it also adds
       operand 3.
  
!      These instructions are not allowed to 'FAIL'.
  
! 'umaddMN4'
!      Like 'maddMN4', but zero-extend the multiplication operands instead
       of sign-extending them.
  
! 'ssmaddMN4'
!      Like 'maddMN4', but all involved operations must be
       signed-saturating.
  
! 'usmaddMN4'
!      Like 'umaddMN4', but all involved operations must be
       unsigned-saturating.
  
! 'msubMN4'
       Multiply operands 1 and 2, sign-extend them to mode N, subtract the
       result from operand 3, and store the result in operand 0.  Operands
       1 and 2 have mode M and operands 0 and 3 have mode N.  Both modes
       must be integer or fixed-point modes and N must be twice the size
       of M.
  
!      In other words, 'msubMN4' is like 'mulMN3' except that it also
       subtracts the result from operand 3.
  
!      These instructions are not allowed to 'FAIL'.
  
! 'umsubMN4'
!      Like 'msubMN4', but zero-extend the multiplication operands instead
       of sign-extending them.
  
! 'ssmsubMN4'
!      Like 'msubMN4', but all involved operations must be
       signed-saturating.
  
! 'usmsubMN4'
!      Like 'umsubMN4', but all involved operations must be
       unsigned-saturating.
  
! 'divmodM4'
       Signed division that produces both a quotient and a remainder.
       Operand 1 is divided by operand 2 to produce a quotient stored in
       operand 0 and a remainder stored in operand 3.
  
       For machines with an instruction that produces both a quotient and
!      a remainder, provide a pattern for 'divmodM4' but do not provide
!      patterns for 'divM3' and 'modM3'.  This allows optimization in the
       relatively common case when both the quotient and remainder are
       computed.
  
       If an instruction that just produces a quotient or just a remainder
       exists and is more efficient than the instruction that produces
!      both, write the output routine of 'divmodM4' to call
!      'find_reg_note' and look for a 'REG_UNUSED' note on the quotient or
       remainder and generate the appropriate instruction.
  
! 'udivmodM4'
       Similar, but does unsigned division.
  
! 'ashlM3', 'ssashlM3', 'usashlM3'
       Arithmetic-shift operand 1 left by a number of bits specified by
       operand 2, and store the result in operand 0.  Here M is the mode
       of operand 0 and operand 1; operand 2's mode is specified by the
       instruction pattern, and the compiler will convert the operand to
       that mode before generating the instruction.  The shift or rotate
       expander or instruction pattern should explicitly specify the mode
!      of the operand 2, it should never be 'VOIDmode'.  The meaning of
       out-of-range shift counts can optionally be specified by
!      'TARGET_SHIFT_TRUNCATION_MASK'.  *Note
       TARGET_SHIFT_TRUNCATION_MASK::.  Operand 2 is always a scalar type.
  
! 'ashrM3', 'lshrM3', 'rotlM3', 'rotrM3'
!      Other shift and rotate instructions, analogous to the 'ashlM3'
       instructions.  Operand 2 is always a scalar type.
  
! 'vashlM3', 'vashrM3', 'vlshrM3', 'vrotlM3', 'vrotrM3'
       Vector shift and rotate instructions that take vectors as operand 2
       instead of a scalar type.
  
! 'avgM3_floor'
! 'uavgM3_floor'
       Signed and unsigned average instructions.  These instructions add
       operands 1 and 2 without truncation, divide the result by 2, round
       towards -Inf, and store the result in operand 0.  This is
--- 27088,27249 ----
       A target shouldn't implement even/odd pattern pair if it is less
       efficient than lo/hi one.
  
! ‘vec_widen_ushiftl_hi_M’, ‘vec_widen_ushiftl_lo_M’
! ‘vec_widen_sshiftl_hi_M’, ‘vec_widen_sshiftl_lo_M’
       Signed/Unsigned widening shift left.  The first input (operand 1)
       is a vector with N signed/unsigned elements of size S.  Operand 2
       is a constant.  Shift the high/low elements of operand 1, and put
       the N/2 results of size 2*S in the output vector (operand 0).
  
! ‘vec_widen_uaddl_hi_M’, ‘vec_widen_uaddl_lo_M’
! ‘vec_widen_saddl_hi_M’, ‘vec_widen_saddl_lo_M’
       Signed/Unsigned widening add long.  Operands 1 and 2 are vectors
       with N signed/unsigned elements of size S.  Add the high/low
       elements of 1 and 2 together, widen the resulting elements and put
       the N/2 results of size 2*S in the output vector (operand 0).
  
! ‘vec_widen_usubl_hi_M’, ‘vec_widen_usubl_lo_M’
! ‘vec_widen_ssubl_hi_M’, ‘vec_widen_ssubl_lo_M’
       Signed/Unsigned widening subtract long.  Operands 1 and 2 are
       vectors with N signed/unsigned elements of size S.  Subtract the
       high/low elements of 2 from 1 and widen the resulting elements.
       Put the N/2 results of size 2*S in the output vector (operand 0).
  
! ‘vec_addsubM3’
       Alternating subtract, add with even lanes doing subtract and odd
       lanes doing addition.  Operands 1 and 2 and the outout operand are
       vectors with mode M.
  
! ‘vec_fmaddsubM4’
       Alternating multiply subtract, add with even lanes doing subtract
       and odd lanes doing addition of the third operand to the
       multiplication result of the first two operands.  Operands 1, 2 and
       3 and the outout operand are vectors with mode M.
  
! ‘vec_fmsubaddM4’
       Alternating multiply add, subtract with even lanes doing addition
       and odd lanes doing subtraction of the third operand to the
       multiplication result of the first two operands.  Operands 1, 2 and
       3 and the outout operand are vectors with mode M.
  
!      These instructions are not allowed to ‘FAIL’.
  
! ‘mulhisi3’
!      Multiply operands 1 and 2, which have mode ‘HImode’, and store a
!      ‘SImode’ product in operand 0.
  
! ‘mulqihi3’, ‘mulsidi3’
       Similar widening-multiplication instructions of other widths.
  
! ‘umulqihi3’, ‘umulhisi3’, ‘umulsidi3’
       Similar widening-multiplication instructions that do unsigned
       multiplication.
  
! ‘usmulqihi3’, ‘usmulhisi3’, ‘usmulsidi3’
       Similar widening-multiplication instructions that interpret the
       first operand as unsigned and the second operand as signed, then do
       a signed multiplication.
  
! ‘smulM3_highpart’
       Perform a signed multiplication of operands 1 and 2, which have
       mode M, and store the most significant half of the product in
       operand 0.  The least significant half of the product is discarded.
!      This may be represented in RTL using a ‘smul_highpart’ RTX
       expression.
  
! ‘umulM3_highpart’
       Similar, but the multiplication is unsigned.  This may be
!      represented in RTL using an ‘umul_highpart’ RTX expression.
  
! ‘maddMN4’
       Multiply operands 1 and 2, sign-extend them to mode N, add operand
       3, and store the result in operand 0.  Operands 1 and 2 have mode M
       and operands 0 and 3 have mode N.  Both modes must be integer or
       fixed-point modes and N must be twice the size of M.
  
!      In other words, ‘maddMN4’ is like ‘mulMN3’ except that it also adds
       operand 3.
  
!      These instructions are not allowed to ‘FAIL’.
  
! ‘umaddMN4’
!      Like ‘maddMN4’, but zero-extend the multiplication operands instead
       of sign-extending them.
  
! ‘ssmaddMN4’
!      Like ‘maddMN4’, but all involved operations must be
       signed-saturating.
  
! ‘usmaddMN4’
!      Like ‘umaddMN4’, but all involved operations must be
       unsigned-saturating.
  
! ‘msubMN4’
       Multiply operands 1 and 2, sign-extend them to mode N, subtract the
       result from operand 3, and store the result in operand 0.  Operands
       1 and 2 have mode M and operands 0 and 3 have mode N.  Both modes
       must be integer or fixed-point modes and N must be twice the size
       of M.
  
!      In other words, ‘msubMN4’ is like ‘mulMN3’ except that it also
       subtracts the result from operand 3.
  
!      These instructions are not allowed to ‘FAIL’.
  
! ‘umsubMN4’
!      Like ‘msubMN4’, but zero-extend the multiplication operands instead
       of sign-extending them.
  
! ‘ssmsubMN4’
!      Like ‘msubMN4’, but all involved operations must be
       signed-saturating.
  
! ‘usmsubMN4’
!      Like ‘umsubMN4’, but all involved operations must be
       unsigned-saturating.
  
! ‘divmodM4’
       Signed division that produces both a quotient and a remainder.
       Operand 1 is divided by operand 2 to produce a quotient stored in
       operand 0 and a remainder stored in operand 3.
  
       For machines with an instruction that produces both a quotient and
!      a remainder, provide a pattern for ‘divmodM4’ but do not provide
!      patterns for ‘divM3’ and ‘modM3’.  This allows optimization in the
       relatively common case when both the quotient and remainder are
       computed.
  
       If an instruction that just produces a quotient or just a remainder
       exists and is more efficient than the instruction that produces
!      both, write the output routine of ‘divmodM4’ to call
!      ‘find_reg_note’ and look for a ‘REG_UNUSED’ note on the quotient or
       remainder and generate the appropriate instruction.
  
! ‘udivmodM4’
       Similar, but does unsigned division.
  
! ‘ashlM3’, ‘ssashlM3’, ‘usashlM3’
       Arithmetic-shift operand 1 left by a number of bits specified by
       operand 2, and store the result in operand 0.  Here M is the mode
       of operand 0 and operand 1; operand 2's mode is specified by the
       instruction pattern, and the compiler will convert the operand to
       that mode before generating the instruction.  The shift or rotate
       expander or instruction pattern should explicitly specify the mode
!      of the operand 2, it should never be ‘VOIDmode’.  The meaning of
       out-of-range shift counts can optionally be specified by
!      ‘TARGET_SHIFT_TRUNCATION_MASK’.  *Note
       TARGET_SHIFT_TRUNCATION_MASK::.  Operand 2 is always a scalar type.
  
! ‘ashrM3’, ‘lshrM3’, ‘rotlM3’, ‘rotrM3’
!      Other shift and rotate instructions, analogous to the ‘ashlM3’
       instructions.  Operand 2 is always a scalar type.
  
! ‘vashlM3’, ‘vashrM3’, ‘vlshrM3’, ‘vrotlM3’, ‘vrotrM3’
       Vector shift and rotate instructions that take vectors as operand 2
       instead of a scalar type.
  
! ‘avgM3_floor’
! ‘uavgM3_floor’
       Signed and unsigned average instructions.  These instructions add
       operands 1 and 2 without truncation, divide the result by 2, round
       towards -Inf, and store the result in operand 0.  This is
*************** pattern to accomplish a certain task.
*** 27252,27585 ****
            narrow op0, op1, op2;
            ...
            op0 = (narrow) (((wide) op1 + (wide) op2) >> 1);
!      where the sign of 'narrow' determines whether this is a signed or
       unsigned operation.
  
! 'avgM3_ceil'
! 'uavgM3_ceil'
!      Like 'avgM3_floor' and 'uavgM3_floor', but round towards +Inf.
       This is equivalent to the C code:
            narrow op0, op1, op2;
            ...
            op0 = (narrow) (((wide) op1 + (wide) op2 + 1) >> 1);
  
! 'bswapM2'
       Reverse the order of bytes of operand 1 and store the result in
       operand 0.
  
! 'negM2', 'ssnegM2', 'usnegM2'
       Negate operand 1 and store the result in operand 0.
  
! 'negvM3'
!      Like 'negM2' but takes a 'code_label' as operand 2 and emits code
       to jump to it if signed overflow occurs during the negation.
  
! 'absM2'
       Store the absolute value of operand 1 into operand 0.
  
! 'sqrtM2'
       Store the square root of operand 1 into operand 0.  Both operands
       have mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'rsqrtM2'
       Store the reciprocal of the square root of operand 1 into operand
       0.  Both operands have mode M, which is a scalar or vector
       floating-point mode.
  
       On most architectures this pattern is only approximate, so either
!      its C condition or the 'TARGET_OPTAB_SUPPORTED_P' hook should check
       for the appropriate math flags.  (Using the C condition is more
!      direct, but using 'TARGET_OPTAB_SUPPORTED_P' can be useful if a
!      target-specific built-in also uses the 'rsqrtM2' pattern.)
  
!      This pattern is not allowed to 'FAIL'.
  
! 'fmodM3'
       Store the remainder of dividing operand 1 by operand 2 into operand
       0, rounded towards zero to an integer.  All operands have mode M,
       which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'remainderM3'
       Store the remainder of dividing operand 1 by operand 2 into operand
       0, rounded to the nearest integer.  All operands have mode M, which
       is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'scalbM3'
!      Raise 'FLT_RADIX' to the power of operand 2, multiply it by operand
       1, and store the result in operand 0.  All operands have mode M,
       which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'ldexpM3'
       Raise 2 to the power of operand 2, multiply it by operand 1, and
       store the result in operand 0.  Operands 0 and 1 have mode M, which
       is a scalar or vector floating-point mode.  Operand 2's mode has
       the same number of elements as M and each element is wide enough to
!      store an 'int'.  The integers are signed.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'cosM2'
       Store the cosine of operand 1 into operand 0.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'sinM2'
       Store the sine of operand 1 into operand 0.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'sincosM3'
       Store the cosine of operand 2 into operand 0 and the sine of
       operand 2 into operand 1.  All operands have mode M, which is a
       scalar or vector floating-point mode.
  
       Targets that can calculate the sine and cosine simultaneously can
       implement this pattern as opposed to implementing individual
!      'sinM2' and 'cosM2' patterns.  The 'sin' and 'cos' built-in
!      functions will then be expanded to the 'sincosM3' pattern, with one
       of the output values left unused.
  
! 'tanM2'
       Store the tangent of operand 1 into operand 0.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'asinM2'
       Store the arc sine of operand 1 into operand 0.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'acosM2'
       Store the arc cosine of operand 1 into operand 0.  Both operands
       have mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'atanM2'
       Store the arc tangent of operand 1 into operand 0.  Both operands
       have mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'fegetroundM'
       Store the current machine floating-point rounding mode into operand
       0.  Operand 0 has mode M, which is scalar.  This pattern is used to
!      implement the 'fegetround' function from the ISO C99 standard.
  
! 'feclearexceptM'
! 'feraiseexceptM'
       Clears or raises the supported machine floating-point exceptions
       represented by the bits in operand 1.  Error status is stored as
       nonzero value in operand 0.  Both operands have mode M, which is a
!      scalar.  These patterns are used to implement the 'feclearexcept'
!      and 'feraiseexcept' functions from the ISO C99 standard.
  
! 'expM2'
       Raise e (the base of natural logarithms) to the power of operand 1
       and store the result in operand 0.  Both operands have mode M,
       which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'expm1M2'
       Raise e (the base of natural logarithms) to the power of operand 1,
       subtract 1, and store the result in operand 0.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
       For inputs close to zero, the pattern is expected to be more
!      accurate than a separate 'expM2' and 'subM3' would be.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'exp10M2'
       Raise 10 to the power of operand 1 and store the result in operand
       0.  Both operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'exp2M2'
       Raise 2 to the power of operand 1 and store the result in operand
       0.  Both operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'logM2'
       Store the natural logarithm of operand 1 into operand 0.  Both
       operands have mode M, which is a scalar or vector floating-point
       mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'log1pM2'
       Add 1 to operand 1, compute the natural logarithm, and store the
       result in operand 0.  Both operands have mode M, which is a scalar
       or vector floating-point mode.
  
       For inputs close to zero, the pattern is expected to be more
!      accurate than a separate 'addM3' and 'logM2' would be.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'log10M2'
       Store the base-10 logarithm of operand 1 into operand 0.  Both
       operands have mode M, which is a scalar or vector floating-point
       mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'log2M2'
       Store the base-2 logarithm of operand 1 into operand 0.  Both
       operands have mode M, which is a scalar or vector floating-point
       mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'logbM2'
!      Store the base-'FLT_RADIX' logarithm of operand 1 into operand 0.
       Both operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'signbitM2'
       Store the sign bit of floating-point operand 1 in operand 0.  M is
       either a scalar or vector mode.  When it is a scalar, operand 1 has
!      mode M but operand 0 must have mode 'SImode'.  When M is a vector,
       operand 1 has the mode M.  operand 0's mode should be an vector
       integer mode which has the same number of elements and the same
       size as mode M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'significandM2'
       Store the significand of floating-point operand 1 in operand 0.
       Both operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'powM3'
       Store the value of operand 1 raised to the exponent operand 2 into
       operand 0.  All operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'atan2M3'
       Store the arc tangent (inverse tangent) of operand 1 divided by
       operand 2 into operand 0, using the signs of both arguments to
       determine the quadrant of the result.  All operands have mode M,
       which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'floorM2'
       Store the largest integral value not greater than operand 1 in
       operand 0.  Both operands have mode M, which is a scalar or vector
!      floating-point mode.  If '-ffp-int-builtin-inexact' is in effect,
       the "inexact" exception may be raised for noninteger operands;
       otherwise, it may not.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'btruncM2'
       Round operand 1 to an integer, towards zero, and store the result
       in operand 0.  Both operands have mode M, which is a scalar or
!      vector floating-point mode.  If '-ffp-int-builtin-inexact' is in
       effect, the "inexact" exception may be raised for noninteger
       operands; otherwise, it may not.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'roundM2'
       Round operand 1 to the nearest integer, rounding away from zero in
       the event of a tie, and store the result in operand 0.  Both
       operands have mode M, which is a scalar or vector floating-point
!      mode.  If '-ffp-int-builtin-inexact' is in effect, the "inexact"
       exception may be raised for noninteger operands; otherwise, it may
       not.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'ceilM2'
       Store the smallest integral value not less than operand 1 in
       operand 0.  Both operands have mode M, which is a scalar or vector
!      floating-point mode.  If '-ffp-int-builtin-inexact' is in effect,
       the "inexact" exception may be raised for noninteger operands;
       otherwise, it may not.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'nearbyintM2'
       Round operand 1 to an integer, using the current rounding mode, and
       store the result in operand 0.  Do not raise an inexact condition
       when the result is different from the argument.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'rintM2'
       Round operand 1 to an integer, using the current rounding mode, and
       store the result in operand 0.  Raise an inexact condition when the
       result is different from the argument.  Both operands have mode M,
       which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'lrintMN2'
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as a signed number according to the current rounding mode
       and store in operand 0 (which has mode N).
  
! 'lroundMN2'
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as a signed number rounding to nearest and away from zero
       and store in operand 0 (which has mode N).
  
! 'lfloorMN2'
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as a signed number rounding down and store in operand 0
       (which has mode N).
  
! 'lceilMN2'
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as a signed number rounding up and store in operand 0 (which
       has mode N).
  
! 'copysignM3'
       Store a value with the magnitude of operand 1 and the sign of
       operand 2 into operand 0.  All operands have mode M, which is a
       scalar or vector floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'xorsignM3'
!      Equivalent to 'op0 = op1 * copysign (1.0, op2)': store a value with
       the magnitude of operand 1 and the sign of operand 2 into operand
       0.  All operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'issignalingM2'
       Set operand 0 to 1 if operand 1 is a signaling NaN and to 0
       otherwise.
  
! 'cadd90M3'
       Perform vector add and subtract on even/odd number pairs.  The
       operation being matched is semantically described as
  
--- 27251,27584 ----
            narrow op0, op1, op2;
            ...
            op0 = (narrow) (((wide) op1 + (wide) op2) >> 1);
!      where the sign of ‘narrow’ determines whether this is a signed or
       unsigned operation.
  
! ‘avgM3_ceil’
! ‘uavgM3_ceil’
!      Like ‘avgM3_floor’ and ‘uavgM3_floor’, but round towards +Inf.
       This is equivalent to the C code:
            narrow op0, op1, op2;
            ...
            op0 = (narrow) (((wide) op1 + (wide) op2 + 1) >> 1);
  
! ‘bswapM2’
       Reverse the order of bytes of operand 1 and store the result in
       operand 0.
  
! ‘negM2’, ‘ssnegM2’, ‘usnegM2’
       Negate operand 1 and store the result in operand 0.
  
! ‘negvM3’
!      Like ‘negM2’ but takes a ‘code_label’ as operand 2 and emits code
       to jump to it if signed overflow occurs during the negation.
  
! ‘absM2’
       Store the absolute value of operand 1 into operand 0.
  
! ‘sqrtM2’
       Store the square root of operand 1 into operand 0.  Both operands
       have mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘rsqrtM2’
       Store the reciprocal of the square root of operand 1 into operand
       0.  Both operands have mode M, which is a scalar or vector
       floating-point mode.
  
       On most architectures this pattern is only approximate, so either
!      its C condition or the ‘TARGET_OPTAB_SUPPORTED_P’ hook should check
       for the appropriate math flags.  (Using the C condition is more
!      direct, but using ‘TARGET_OPTAB_SUPPORTED_P’ can be useful if a
!      target-specific built-in also uses the ‘rsqrtM2’ pattern.)
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘fmodM3’
       Store the remainder of dividing operand 1 by operand 2 into operand
       0, rounded towards zero to an integer.  All operands have mode M,
       which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘remainderM3’
       Store the remainder of dividing operand 1 by operand 2 into operand
       0, rounded to the nearest integer.  All operands have mode M, which
       is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘scalbM3’
!      Raise ‘FLT_RADIX’ to the power of operand 2, multiply it by operand
       1, and store the result in operand 0.  All operands have mode M,
       which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘ldexpM3’
       Raise 2 to the power of operand 2, multiply it by operand 1, and
       store the result in operand 0.  Operands 0 and 1 have mode M, which
       is a scalar or vector floating-point mode.  Operand 2's mode has
       the same number of elements as M and each element is wide enough to
!      store an ‘int’.  The integers are signed.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘cosM2’
       Store the cosine of operand 1 into operand 0.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘sinM2’
       Store the sine of operand 1 into operand 0.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘sincosM3’
       Store the cosine of operand 2 into operand 0 and the sine of
       operand 2 into operand 1.  All operands have mode M, which is a
       scalar or vector floating-point mode.
  
       Targets that can calculate the sine and cosine simultaneously can
       implement this pattern as opposed to implementing individual
!      ‘sinM2’ and ‘cosM2’ patterns.  The ‘sin’ and ‘cos’ built-in
!      functions will then be expanded to the ‘sincosM3’ pattern, with one
       of the output values left unused.
  
! ‘tanM2’
       Store the tangent of operand 1 into operand 0.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘asinM2’
       Store the arc sine of operand 1 into operand 0.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘acosM2’
       Store the arc cosine of operand 1 into operand 0.  Both operands
       have mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘atanM2’
       Store the arc tangent of operand 1 into operand 0.  Both operands
       have mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘fegetroundM’
       Store the current machine floating-point rounding mode into operand
       0.  Operand 0 has mode M, which is scalar.  This pattern is used to
!      implement the ‘fegetround’ function from the ISO C99 standard.
  
! ‘feclearexceptM’
! ‘feraiseexceptM’
       Clears or raises the supported machine floating-point exceptions
       represented by the bits in operand 1.  Error status is stored as
       nonzero value in operand 0.  Both operands have mode M, which is a
!      scalar.  These patterns are used to implement the ‘feclearexcept’
!      and ‘feraiseexcept’ functions from the ISO C99 standard.
  
! ‘expM2’
       Raise e (the base of natural logarithms) to the power of operand 1
       and store the result in operand 0.  Both operands have mode M,
       which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘expm1M2’
       Raise e (the base of natural logarithms) to the power of operand 1,
       subtract 1, and store the result in operand 0.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
       For inputs close to zero, the pattern is expected to be more
!      accurate than a separate ‘expM2’ and ‘subM3’ would be.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘exp10M2’
       Raise 10 to the power of operand 1 and store the result in operand
       0.  Both operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘exp2M2’
       Raise 2 to the power of operand 1 and store the result in operand
       0.  Both operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘logM2’
       Store the natural logarithm of operand 1 into operand 0.  Both
       operands have mode M, which is a scalar or vector floating-point
       mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘log1pM2’
       Add 1 to operand 1, compute the natural logarithm, and store the
       result in operand 0.  Both operands have mode M, which is a scalar
       or vector floating-point mode.
  
       For inputs close to zero, the pattern is expected to be more
!      accurate than a separate ‘addM3’ and ‘logM2’ would be.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘log10M2’
       Store the base-10 logarithm of operand 1 into operand 0.  Both
       operands have mode M, which is a scalar or vector floating-point
       mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘log2M2’
       Store the base-2 logarithm of operand 1 into operand 0.  Both
       operands have mode M, which is a scalar or vector floating-point
       mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘logbM2’
!      Store the base-‘FLT_RADIX’ logarithm of operand 1 into operand 0.
       Both operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘signbitM2’
       Store the sign bit of floating-point operand 1 in operand 0.  M is
       either a scalar or vector mode.  When it is a scalar, operand 1 has
!      mode M but operand 0 must have mode ‘SImode’.  When M is a vector,
       operand 1 has the mode M.  operand 0's mode should be an vector
       integer mode which has the same number of elements and the same
       size as mode M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘significandM2’
       Store the significand of floating-point operand 1 in operand 0.
       Both operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘powM3’
       Store the value of operand 1 raised to the exponent operand 2 into
       operand 0.  All operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘atan2M3’
       Store the arc tangent (inverse tangent) of operand 1 divided by
       operand 2 into operand 0, using the signs of both arguments to
       determine the quadrant of the result.  All operands have mode M,
       which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘floorM2’
       Store the largest integral value not greater than operand 1 in
       operand 0.  Both operands have mode M, which is a scalar or vector
!      floating-point mode.  If ‘-ffp-int-builtin-inexact’ is in effect,
       the "inexact" exception may be raised for noninteger operands;
       otherwise, it may not.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘btruncM2’
       Round operand 1 to an integer, towards zero, and store the result
       in operand 0.  Both operands have mode M, which is a scalar or
!      vector floating-point mode.  If ‘-ffp-int-builtin-inexact’ is in
       effect, the "inexact" exception may be raised for noninteger
       operands; otherwise, it may not.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘roundM2’
       Round operand 1 to the nearest integer, rounding away from zero in
       the event of a tie, and store the result in operand 0.  Both
       operands have mode M, which is a scalar or vector floating-point
!      mode.  If ‘-ffp-int-builtin-inexact’ is in effect, the "inexact"
       exception may be raised for noninteger operands; otherwise, it may
       not.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘ceilM2’
       Store the smallest integral value not less than operand 1 in
       operand 0.  Both operands have mode M, which is a scalar or vector
!      floating-point mode.  If ‘-ffp-int-builtin-inexact’ is in effect,
       the "inexact" exception may be raised for noninteger operands;
       otherwise, it may not.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘nearbyintM2’
       Round operand 1 to an integer, using the current rounding mode, and
       store the result in operand 0.  Do not raise an inexact condition
       when the result is different from the argument.  Both operands have
       mode M, which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘rintM2’
       Round operand 1 to an integer, using the current rounding mode, and
       store the result in operand 0.  Raise an inexact condition when the
       result is different from the argument.  Both operands have mode M,
       which is a scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘lrintMN2’
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as a signed number according to the current rounding mode
       and store in operand 0 (which has mode N).
  
! ‘lroundMN2’
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as a signed number rounding to nearest and away from zero
       and store in operand 0 (which has mode N).
  
! ‘lfloorMN2’
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as a signed number rounding down and store in operand 0
       (which has mode N).
  
! ‘lceilMN2’
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as a signed number rounding up and store in operand 0 (which
       has mode N).
  
! ‘copysignM3’
       Store a value with the magnitude of operand 1 and the sign of
       operand 2 into operand 0.  All operands have mode M, which is a
       scalar or vector floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘xorsignM3’
!      Equivalent to ‘op0 = op1 * copysign (1.0, op2)’: store a value with
       the magnitude of operand 1 and the sign of operand 2 into operand
       0.  All operands have mode M, which is a scalar or vector
       floating-point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘issignalingM2’
       Set operand 0 to 1 if operand 1 is a signaling NaN and to 0
       otherwise.
  
! ‘cadd90M3’
       Perform vector add and subtract on even/odd number pairs.  The
       operation being matched is semantically described as
  
*************** pattern to accomplish a certain task.
*** 27599,27607 ****
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'cadd270M3'
       Perform vector add and subtract on even/odd number pairs.  The
       operation being matched is semantically described as
  
--- 27598,27606 ----
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘cadd270M3’
       Perform vector add and subtract on even/odd number pairs.  The
       operation being matched is semantically described as
  
*************** pattern to accomplish a certain task.
*** 27621,27629 ****
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'cmlaM4'
       Perform a vector multiply and accumulate that is semantically the
       same as a multiply and accumulate of complex numbers.
  
--- 27620,27628 ----
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘cmlaM4’
       Perform a vector multiply and accumulate that is semantically the
       same as a multiply and accumulate of complex numbers.
  
*************** pattern to accomplish a certain task.
*** 27641,27649 ****
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'cmla_conjM4'
       Perform a vector multiply by conjugate and accumulate that is
       semantically the same as a multiply and accumulate of complex
       numbers where the second multiply arguments is conjugated.
--- 27640,27648 ----
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘cmla_conjM4’
       Perform a vector multiply by conjugate and accumulate that is
       semantically the same as a multiply and accumulate of complex
       numbers where the second multiply arguments is conjugated.
*************** pattern to accomplish a certain task.
*** 27662,27670 ****
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'cmlsM4'
       Perform a vector multiply and subtract that is semantically the
       same as a multiply and subtract of complex numbers.
  
--- 27661,27669 ----
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘cmlsM4’
       Perform a vector multiply and subtract that is semantically the
       same as a multiply and subtract of complex numbers.
  
*************** pattern to accomplish a certain task.
*** 27682,27690 ****
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'cmls_conjM4'
       Perform a vector multiply by conjugate and subtract that is
       semantically the same as a multiply and subtract of complex numbers
       where the second multiply arguments is conjugated.
--- 27681,27689 ----
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘cmls_conjM4’
       Perform a vector multiply by conjugate and subtract that is
       semantically the same as a multiply and subtract of complex numbers
       where the second multiply arguments is conjugated.
*************** pattern to accomplish a certain task.
*** 27703,27711 ****
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'cmulM4'
       Perform a vector multiply that is semantically the same as multiply
       of complex numbers.
  
--- 27702,27710 ----
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘cmulM4’
       Perform a vector multiply that is semantically the same as multiply
       of complex numbers.
  
*************** pattern to accomplish a certain task.
*** 27722,27730 ****
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'cmul_conjM4'
       Perform a vector multiply by conjugate that is semantically the
       same as a multiply of complex numbers where the second multiply
       arguments is conjugated.
--- 27721,27729 ----
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘cmul_conjM4’
       Perform a vector multiply by conjugate that is semantically the
       same as a multiply of complex numbers where the second multiply
       arguments is conjugated.
*************** pattern to accomplish a certain task.
*** 27742,27750 ****
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'ffsM2'
       Store into operand 0 one plus the index of the least significant
       1-bit of operand 1.  If operand 1 is zero, store zero.
  
--- 27741,27749 ----
  
       The operation is only supported for vector modes M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘ffsM2’
       Store into operand 0 one plus the index of the least significant
       1-bit of operand 1.  If operand 1 is zero, store zero.
  
*************** pattern to accomplish a certain task.
*** 27752,27763 ****
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as 'int').  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'clrsbM2'
       Count leading redundant sign bits.  Store into operand 0 the number
       of redundant sign bits in operand 1, starting at the most
       significant bit position.  A redundant sign bit is defined as any
--- 27751,27762 ----
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as ‘int’).  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘clrsbM2’
       Count leading redundant sign bits.  Store into operand 0 the number
       of redundant sign bits in operand 1, starting at the most
       significant bit position.  A redundant sign bit is defined as any
*************** pattern to accomplish a certain task.
*** 27768,27821 ****
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as 'int').  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'clzM2'
       Store into operand 0 the number of leading 0-bits in operand 1,
       starting at the most significant bit position.  If operand 1 is 0,
!      the 'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the
       result is undefined or has a useful value.
  
       M is either a scalar or vector integer mode.  When it is a scalar,
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as 'int').  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'ctzM2'
       Store into operand 0 the number of trailing 0-bits in operand 1,
       starting at the least significant bit position.  If operand 1 is 0,
!      the 'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the
       result is undefined or has a useful value.
  
       M is either a scalar or vector integer mode.  When it is a scalar,
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as 'int').  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'popcountM2'
       Store into operand 0 the number of 1-bits in operand 1.
  
       M is either a scalar or vector integer mode.  When it is a scalar,
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as 'int').  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'parityM2'
       Store into operand 0 the parity of operand 1, i.e. the number of
       1-bits in operand 1 modulo 2.
  
--- 27767,27820 ----
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as ‘int’).  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘clzM2’
       Store into operand 0 the number of leading 0-bits in operand 1,
       starting at the most significant bit position.  If operand 1 is 0,
!      the ‘CLZ_DEFINED_VALUE_AT_ZERO’ (*note Misc::) macro defines if the
       result is undefined or has a useful value.
  
       M is either a scalar or vector integer mode.  When it is a scalar,
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as ‘int’).  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘ctzM2’
       Store into operand 0 the number of trailing 0-bits in operand 1,
       starting at the least significant bit position.  If operand 1 is 0,
!      the ‘CTZ_DEFINED_VALUE_AT_ZERO’ (*note Misc::) macro defines if the
       result is undefined or has a useful value.
  
       M is either a scalar or vector integer mode.  When it is a scalar,
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as ‘int’).  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘popcountM2’
       Store into operand 0 the number of 1-bits in operand 1.
  
       M is either a scalar or vector integer mode.  When it is a scalar,
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as ‘int’).  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘parityM2’
       Store into operand 0 the parity of operand 1, i.e. the number of
       1-bits in operand 1 modulo 2.
  
*************** pattern to accomplish a certain task.
*** 27823,27852 ****
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as 'int').  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to 'FAIL'.
  
! 'one_cmplM2'
       Store the bitwise-complement of operand 1 into operand 0.
  
! 'cpymemM'
       Block copy instruction.  The destination and source blocks of
!      memory are the first two operands, and both are 'mem:BLK's with an
!      address in mode 'Pmode'.
  
       The number of bytes to copy is the third operand, in mode M.
!      Usually, you specify 'Pmode' for M.  However, if you can generate
       better code knowing the range of valid lengths is smaller than
       those representable in a full Pmode pointer, you should provide a
       pattern with a mode corresponding to the range of values you can
!      handle efficiently (e.g., 'QImode' for values in the range 0-127;
       note we avoid numbers that appear negative) and also a pattern with
!      'Pmode'.
  
       The fourth operand is the known shared alignment of the source and
!      destination, in the form of a 'const_int' rtx.  Thus, if the
       compiler knows that both source and destination are word-aligned,
       it may provide the value 4 for this operand.
  
--- 27822,27851 ----
       operand 1 has mode M but operand 0 can have whatever scalar integer
       mode is suitable for the target.  The compiler will insert
       conversion instructions as necessary (typically to convert the
!      result to the same width as ‘int’).  When M is a vector, both
       operands must have mode M.
  
!      This pattern is not allowed to ‘FAIL’.
  
! ‘one_cmplM2’
       Store the bitwise-complement of operand 1 into operand 0.
  
! ‘cpymemM’
       Block copy instruction.  The destination and source blocks of
!      memory are the first two operands, and both are ‘mem:BLK’s with an
!      address in mode ‘Pmode’.
  
       The number of bytes to copy is the third operand, in mode M.
!      Usually, you specify ‘Pmode’ for M.  However, if you can generate
       better code knowing the range of valid lengths is smaller than
       those representable in a full Pmode pointer, you should provide a
       pattern with a mode corresponding to the range of values you can
!      handle efficiently (e.g., ‘QImode’ for values in the range 0-127;
       note we avoid numbers that appear negative) and also a pattern with
!      ‘Pmode’.
  
       The fourth operand is the known shared alignment of the source and
!      destination, in the form of a ‘const_int’ rtx.  Thus, if the
       compiler knows that both source and destination are word-aligned,
       it may provide the value 4 for this operand.
  
*************** pattern to accomplish a certain task.
*** 27855,27889 ****
       in operand 4 in a way that the blocks are not required to be
       aligned according to it in all cases.  This expected alignment is
       also in bytes, just like operand 4.  Expected size, when unknown,
!      is set to '(const_int -1)'.
  
!      Descriptions of multiple 'cpymemM' patterns can only be beneficial
       if the patterns for smaller modes have fewer restrictions on their
       first, second and fourth operands.  Note that the mode M in
!      'cpymemM' does not impose any restriction on the mode of
       individually copied data units in the block.
  
!      The 'cpymemM' patterns need not give special consideration to the
       possibility that the source and destination strings might overlap.
       These patterns are used to do inline expansion of
!      '__builtin_memcpy'.
  
! 'movmemM'
       Block move instruction.  The destination and source blocks of
!      memory are the first two operands, and both are 'mem:BLK's with an
!      address in mode 'Pmode'.
  
       The number of bytes to copy is the third operand, in mode M.
!      Usually, you specify 'Pmode' for M.  However, if you can generate
       better code knowing the range of valid lengths is smaller than
       those representable in a full Pmode pointer, you should provide a
       pattern with a mode corresponding to the range of values you can
!      handle efficiently (e.g., 'QImode' for values in the range 0-127;
       note we avoid numbers that appear negative) and also a pattern with
!      'Pmode'.
  
       The fourth operand is the known shared alignment of the source and
!      destination, in the form of a 'const_int' rtx.  Thus, if the
       compiler knows that both source and destination are word-aligned,
       it may provide the value 4 for this operand.
  
--- 27854,27888 ----
       in operand 4 in a way that the blocks are not required to be
       aligned according to it in all cases.  This expected alignment is
       also in bytes, just like operand 4.  Expected size, when unknown,
!      is set to ‘(const_int -1)’.
  
!      Descriptions of multiple ‘cpymemM’ patterns can only be beneficial
       if the patterns for smaller modes have fewer restrictions on their
       first, second and fourth operands.  Note that the mode M in
!      ‘cpymemM’ does not impose any restriction on the mode of
       individually copied data units in the block.
  
!      The ‘cpymemM’ patterns need not give special consideration to the
       possibility that the source and destination strings might overlap.
       These patterns are used to do inline expansion of
!      ‘__builtin_memcpy’.
  
! ‘movmemM’
       Block move instruction.  The destination and source blocks of
!      memory are the first two operands, and both are ‘mem:BLK’s with an
!      address in mode ‘Pmode’.
  
       The number of bytes to copy is the third operand, in mode M.
!      Usually, you specify ‘Pmode’ for M.  However, if you can generate
       better code knowing the range of valid lengths is smaller than
       those representable in a full Pmode pointer, you should provide a
       pattern with a mode corresponding to the range of values you can
!      handle efficiently (e.g., ‘QImode’ for values in the range 0-127;
       note we avoid numbers that appear negative) and also a pattern with
!      ‘Pmode’.
  
       The fourth operand is the known shared alignment of the source and
!      destination, in the form of a ‘const_int’ rtx.  Thus, if the
       compiler knows that both source and destination are word-aligned,
       it may provide the value 4 for this operand.
  
*************** pattern to accomplish a certain task.
*** 27892,27931 ****
       in operand 4 in a way that the blocks are not required to be
       aligned according to it in all cases.  This expected alignment is
       also in bytes, just like operand 4.  Expected size, when unknown,
!      is set to '(const_int -1)'.
  
!      Descriptions of multiple 'movmemM' patterns can only be beneficial
       if the patterns for smaller modes have fewer restrictions on their
       first, second and fourth operands.  Note that the mode M in
!      'movmemM' does not impose any restriction on the mode of
       individually copied data units in the block.
  
!      The 'movmemM' patterns must correctly handle the case where the
       source and destination strings overlap.  These patterns are used to
!      do inline expansion of '__builtin_memmove'.
  
! 'movstr'
!      String copy instruction, with 'stpcpy' semantics.  Operand 0 is an
!      output operand in mode 'Pmode'.  The addresses of the destination
!      and source strings are operands 1 and 2, and both are 'mem:BLK's
!      with addresses in mode 'Pmode'.  The execution of the expansion of
       this pattern should store in operand 0 the address in which the
!      'NUL' terminator was stored in the destination string.
  
       This pattern has also several optional operands that are same as in
!      'setmem'.
  
! 'setmemM'
       Block set instruction.  The destination string is the first
!      operand, given as a 'mem:BLK' whose address is in mode 'Pmode'.
       The number of bytes to set is the second operand, in mode M.  The
       value to initialize the memory with is the third operand.  Targets
       that only support the clearing of memory should reject any value
!      that is not the constant 0.  See 'cpymemM' for a discussion of the
       choice of mode.
  
       The fourth operand is the known alignment of the destination, in
!      the form of a 'const_int' rtx.  Thus, if the compiler knows that
       the destination is word-aligned, it may provide the value 4 for
       this operand.
  
--- 27891,27930 ----
       in operand 4 in a way that the blocks are not required to be
       aligned according to it in all cases.  This expected alignment is
       also in bytes, just like operand 4.  Expected size, when unknown,
!      is set to ‘(const_int -1)’.
  
!      Descriptions of multiple ‘movmemM’ patterns can only be beneficial
       if the patterns for smaller modes have fewer restrictions on their
       first, second and fourth operands.  Note that the mode M in
!      ‘movmemM’ does not impose any restriction on the mode of
       individually copied data units in the block.
  
!      The ‘movmemM’ patterns must correctly handle the case where the
       source and destination strings overlap.  These patterns are used to
!      do inline expansion of ‘__builtin_memmove’.
  
! ‘movstr’
!      String copy instruction, with ‘stpcpy’ semantics.  Operand 0 is an
!      output operand in mode ‘Pmode’.  The addresses of the destination
!      and source strings are operands 1 and 2, and both are ‘mem:BLK’s
!      with addresses in mode ‘Pmode’.  The execution of the expansion of
       this pattern should store in operand 0 the address in which the
!      ‘NUL’ terminator was stored in the destination string.
  
       This pattern has also several optional operands that are same as in
!      ‘setmem’.
  
! ‘setmemM’
       Block set instruction.  The destination string is the first
!      operand, given as a ‘mem:BLK’ whose address is in mode ‘Pmode’.
       The number of bytes to set is the second operand, in mode M.  The
       value to initialize the memory with is the third operand.  Targets
       that only support the clearing of memory should reject any value
!      that is not the constant 0.  See ‘cpymemM’ for a discussion of the
       choice of mode.
  
       The fourth operand is the known alignment of the destination, in
!      the form of a ‘const_int’ rtx.  Thus, if the compiler knows that
       the destination is word-aligned, it may provide the value 4 for
       this operand.
  
*************** pattern to accomplish a certain task.
*** 27934,27951 ****
       in operand 4 in a way that the blocks are not required to be
       aligned according to it in all cases.  This expected alignment is
       also in bytes, just like operand 4.  Expected size, when unknown,
!      is set to '(const_int -1)'.  Operand 7 is the minimal size of the
       block and operand 8 is the maximal size of the block (NULL if it
       cannot be represented as CONST_INT). Operand 9 is the probable
       maximal size (i.e. we cannot rely on it for correctness, but it can
       be used for choosing proper code sequence for a given size).
  
!      The use for multiple 'setmemM' is as for 'cpymemM'.
  
! 'cmpstrnM'
       String compare instruction, with five operands.  Operand 0 is the
       output; it has mode M.  The remaining four operands are like the
!      operands of 'cpymemM'.  The two memory blocks specified are
       compared byte by byte in lexicographic order starting at the
       beginning of each string.  The instruction is not allowed to
       prefetch more than one byte at a time since either string may end
--- 27933,27950 ----
       in operand 4 in a way that the blocks are not required to be
       aligned according to it in all cases.  This expected alignment is
       also in bytes, just like operand 4.  Expected size, when unknown,
!      is set to ‘(const_int -1)’.  Operand 7 is the minimal size of the
       block and operand 8 is the maximal size of the block (NULL if it
       cannot be represented as CONST_INT). Operand 9 is the probable
       maximal size (i.e. we cannot rely on it for correctness, but it can
       be used for choosing proper code sequence for a given size).
  
!      The use for multiple ‘setmemM’ is as for ‘cpymemM’.
  
! ‘cmpstrnM’
       String compare instruction, with five operands.  Operand 0 is the
       output; it has mode M.  The remaining four operands are like the
!      operands of ‘cpymemM’.  The two memory blocks specified are
       compared byte by byte in lexicographic order starting at the
       beginning of each string.  The instruction is not allowed to
       prefetch more than one byte at a time since either string may end
*************** pattern to accomplish a certain task.
*** 27955,27968 ****
       effect of the instruction is to store a value in operand 0 whose
       sign indicates the result of the comparison.
  
! 'cmpstrM'
       String compare instruction, without known maximum length.  Operand
       0 is the output; it has mode M.  The second and third operand are
!      the blocks of memory to be compared; both are 'mem:BLK' with an
!      address in mode 'Pmode'.
  
       The fourth operand is the known shared alignment of the source and
!      destination, in the form of a 'const_int' rtx.  Thus, if the
       compiler knows that both source and destination are word-aligned,
       it may provide the value 4 for this operand.
  
--- 27954,27967 ----
       effect of the instruction is to store a value in operand 0 whose
       sign indicates the result of the comparison.
  
! ‘cmpstrM’
       String compare instruction, without known maximum length.  Operand
       0 is the output; it has mode M.  The second and third operand are
!      the blocks of memory to be compared; both are ‘mem:BLK’ with an
!      address in mode ‘Pmode’.
  
       The fourth operand is the known shared alignment of the source and
!      destination, in the form of a ‘const_int’ rtx.  Thus, if the
       compiler knows that both source and destination are word-aligned,
       it may provide the value 4 for this operand.
  
*************** pattern to accomplish a certain task.
*** 27976,28055 ****
       store a value in operand 0 whose sign indicates the result of the
       comparison.
  
! 'cmpmemM'
       Block compare instruction, with five operands like the operands of
!      'cmpstrM'.  The two memory blocks specified are compared byte by
       byte in lexicographic order starting at the beginning of each
!      block.  Unlike 'cmpstrM' the instruction can prefetch any bytes in
!      the two memory blocks.  Also unlike 'cmpstrM' the comparison will
       not stop if both bytes are zero.  The effect of the instruction is
       to store a value in operand 0 whose sign indicates the result of
       the comparison.
  
! 'strlenM'
       Compute the length of a string, with three operands.  Operand 0 is
!      the result (of mode M), operand 1 is a 'mem' referring to the first
       character of the string, operand 2 is the character to search for
       (normally zero), and operand 3 is a constant describing the known
       alignment of the beginning of the string.
  
! 'rawmemchrM'
       Scan memory referred to by operand 1 for the first occurrence of
!      operand 2.  Operand 1 is a 'mem' and operand 2 a 'const_int' of
       mode M.  Operand 0 is the result, i.e., a pointer to the first
       occurrence of operand 2 in the memory block given by operand 1.
  
! 'floatMN2'
       Convert signed integer operand 1 (valid for fixed point mode M) to
       floating point mode N and store in operand 0 (which has mode N).
  
! 'floatunsMN2'
       Convert unsigned integer operand 1 (valid for fixed point mode M)
       to floating point mode N and store in operand 0 (which has mode N).
  
! 'fixMN2'
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as a signed number and store in operand 0 (which has mode
       N).  This instruction's result is defined only when the value of
       operand 1 is an integer.
  
       If the machine description defines this pattern, it also needs to
!      define the 'ftrunc' pattern.
  
! 'fixunsMN2'
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as an unsigned number and store in operand 0 (which has mode
       N).  This instruction's result is defined only when the value of
       operand 1 is an integer.
  
! 'ftruncM2'
       Convert operand 1 (valid for floating point mode M) to an integer
       value, still represented in floating point mode M, and store it in
       operand 0 (valid for floating point mode M).
  
! 'fix_truncMN2'
!      Like 'fixMN2' but works for any floating point value of mode M by
       converting the value to an integer.
  
! 'fixuns_truncMN2'
!      Like 'fixunsMN2' but works for any floating point value of mode M
       by converting the value to an integer.
  
! 'truncMN2'
       Truncate operand 1 (valid for mode M) to mode N and store in
       operand 0 (which has mode N).  Both modes must be fixed point or
       both floating point.
  
! 'extendMN2'
       Sign-extend operand 1 (valid for mode M) to mode N and store in
       operand 0 (which has mode N).  Both modes must be fixed point or
       both floating point.
  
! 'zero_extendMN2'
       Zero-extend operand 1 (valid for mode M) to mode N and store in
       operand 0 (which has mode N).  Both modes must be fixed point.
  
! 'fractMN2'
       Convert operand 1 of mode M to mode N and store in operand 0 (which
       has mode N).  Mode M and mode N could be fixed-point to
       fixed-point, signed integer to fixed-point, fixed-point to signed
--- 27975,28054 ----
       store a value in operand 0 whose sign indicates the result of the
       comparison.
  
! ‘cmpmemM’
       Block compare instruction, with five operands like the operands of
!      ‘cmpstrM’.  The two memory blocks specified are compared byte by
       byte in lexicographic order starting at the beginning of each
!      block.  Unlike ‘cmpstrM’ the instruction can prefetch any bytes in
!      the two memory blocks.  Also unlike ‘cmpstrM’ the comparison will
       not stop if both bytes are zero.  The effect of the instruction is
       to store a value in operand 0 whose sign indicates the result of
       the comparison.
  
! ‘strlenM’
       Compute the length of a string, with three operands.  Operand 0 is
!      the result (of mode M), operand 1 is a ‘mem’ referring to the first
       character of the string, operand 2 is the character to search for
       (normally zero), and operand 3 is a constant describing the known
       alignment of the beginning of the string.
  
! ‘rawmemchrM’
       Scan memory referred to by operand 1 for the first occurrence of
!      operand 2.  Operand 1 is a ‘mem’ and operand 2 a ‘const_int’ of
       mode M.  Operand 0 is the result, i.e., a pointer to the first
       occurrence of operand 2 in the memory block given by operand 1.
  
! ‘floatMN2’
       Convert signed integer operand 1 (valid for fixed point mode M) to
       floating point mode N and store in operand 0 (which has mode N).
  
! ‘floatunsMN2’
       Convert unsigned integer operand 1 (valid for fixed point mode M)
       to floating point mode N and store in operand 0 (which has mode N).
  
! ‘fixMN2’
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as a signed number and store in operand 0 (which has mode
       N).  This instruction's result is defined only when the value of
       operand 1 is an integer.
  
       If the machine description defines this pattern, it also needs to
!      define the ‘ftrunc’ pattern.
  
! ‘fixunsMN2’
       Convert operand 1 (valid for floating point mode M) to fixed point
       mode N as an unsigned number and store in operand 0 (which has mode
       N).  This instruction's result is defined only when the value of
       operand 1 is an integer.
  
! ‘ftruncM2’
       Convert operand 1 (valid for floating point mode M) to an integer
       value, still represented in floating point mode M, and store it in
       operand 0 (valid for floating point mode M).
  
! ‘fix_truncMN2’
!      Like ‘fixMN2’ but works for any floating point value of mode M by
       converting the value to an integer.
  
! ‘fixuns_truncMN2’
!      Like ‘fixunsMN2’ but works for any floating point value of mode M
       by converting the value to an integer.
  
! ‘truncMN2’
       Truncate operand 1 (valid for mode M) to mode N and store in
       operand 0 (which has mode N).  Both modes must be fixed point or
       both floating point.
  
! ‘extendMN2’
       Sign-extend operand 1 (valid for mode M) to mode N and store in
       operand 0 (which has mode N).  Both modes must be fixed point or
       both floating point.
  
! ‘zero_extendMN2’
       Zero-extend operand 1 (valid for mode M) to mode N and store in
       operand 0 (which has mode N).  Both modes must be fixed point.
  
! ‘fractMN2’
       Convert operand 1 of mode M to mode N and store in operand 0 (which
       has mode N).  Mode M and mode N could be fixed-point to
       fixed-point, signed integer to fixed-point, fixed-point to signed
*************** pattern to accomplish a certain task.
*** 28057,28143 ****
       floating-point.  When overflows or underflows happen, the results
       are undefined.
  
! 'satfractMN2'
       Convert operand 1 of mode M to mode N and store in operand 0 (which
       has mode N).  Mode M and mode N could be fixed-point to
       fixed-point, signed integer to fixed-point, or floating-point to
       fixed-point.  When overflows or underflows happen, the instruction
       saturates the results to the maximum or the minimum.
  
! 'fractunsMN2'
       Convert operand 1 of mode M to mode N and store in operand 0 (which
       has mode N).  Mode M and mode N could be unsigned integer to
       fixed-point, or fixed-point to unsigned integer.  When overflows or
       underflows happen, the results are undefined.
  
! 'satfractunsMN2'
       Convert unsigned integer operand 1 of mode M to fixed-point mode N
       and store in operand 0 (which has mode N).  When overflows or
       underflows happen, the instruction saturates the results to the
       maximum or the minimum.
  
! 'extvM'
       Extract a bit-field from register operand 1, sign-extend it, and
       store it in operand 0.  Operand 2 specifies the width of the field
       in bits and operand 3 the starting bit, which counts from the most
!      significant bit if 'BITS_BIG_ENDIAN' is true and from the least
       significant bit otherwise.
  
       Operands 0 and 1 both have mode M.  Operands 2 and 3 have a
       target-specific mode.
  
! 'extvmisalignM'
       Extract a bit-field from memory operand 1, sign extend it, and
       store it in operand 0.  Operand 2 specifies the width in bits and
       operand 3 the starting bit.  The starting bit is always somewhere
       in the first byte of operand 1; it counts from the most significant
!      bit if 'BITS_BIG_ENDIAN' is true and from the least significant bit
       otherwise.
  
!      Operand 0 has mode M while operand 1 has 'BLK' mode.  Operands 2
       and 3 have a target-specific mode.
  
       The instruction must not read beyond the last byte of the
       bit-field.
  
! 'extzvM'
!      Like 'extvM' except that the bit-field value is zero-extended.
  
! 'extzvmisalignM'
!      Like 'extvmisalignM' except that the bit-field value is
       zero-extended.
  
! 'insvM'
       Insert operand 3 into a bit-field of register operand 0.  Operand 1
       specifies the width of the field in bits and operand 2 the starting
       bit, which counts from the most significant bit if
!      'BITS_BIG_ENDIAN' is true and from the least significant bit
       otherwise.
  
       Operands 0 and 3 both have mode M.  Operands 1 and 2 have a
       target-specific mode.
  
! 'insvmisalignM'
       Insert operand 3 into a bit-field of memory operand 0.  Operand 1
       specifies the width of the field in bits and operand 2 the starting
       bit.  The starting bit is always somewhere in the first byte of
       operand 0; it counts from the most significant bit if
!      'BITS_BIG_ENDIAN' is true and from the least significant bit
       otherwise.
  
!      Operand 3 has mode M while operand 0 has 'BLK' mode.  Operands 1
       and 2 have a target-specific mode.
  
       The instruction must not read or write beyond the last byte of the
       bit-field.
  
! 'extv'
       Extract a bit-field from operand 1 (a register or memory operand),
       where operand 2 specifies the width in bits and operand 3 the
       starting bit, and store it in operand 0.  Operand 0 must have mode
!      'word_mode'.  Operand 1 may have mode 'byte_mode' or 'word_mode';
!      often 'word_mode' is allowed only for registers.  Operands 2 and 3
!      must be valid for 'word_mode'.
  
       The RTL generation pass generates this instruction only with
       constants for operands 2 and 3 and the constant is never zero for
--- 28056,28142 ----
       floating-point.  When overflows or underflows happen, the results
       are undefined.
  
! ‘satfractMN2’
       Convert operand 1 of mode M to mode N and store in operand 0 (which
       has mode N).  Mode M and mode N could be fixed-point to
       fixed-point, signed integer to fixed-point, or floating-point to
       fixed-point.  When overflows or underflows happen, the instruction
       saturates the results to the maximum or the minimum.
  
! ‘fractunsMN2’
       Convert operand 1 of mode M to mode N and store in operand 0 (which
       has mode N).  Mode M and mode N could be unsigned integer to
       fixed-point, or fixed-point to unsigned integer.  When overflows or
       underflows happen, the results are undefined.
  
! ‘satfractunsMN2’
       Convert unsigned integer operand 1 of mode M to fixed-point mode N
       and store in operand 0 (which has mode N).  When overflows or
       underflows happen, the instruction saturates the results to the
       maximum or the minimum.
  
! ‘extvM’
       Extract a bit-field from register operand 1, sign-extend it, and
       store it in operand 0.  Operand 2 specifies the width of the field
       in bits and operand 3 the starting bit, which counts from the most
!      significant bit if ‘BITS_BIG_ENDIAN’ is true and from the least
       significant bit otherwise.
  
       Operands 0 and 1 both have mode M.  Operands 2 and 3 have a
       target-specific mode.
  
! ‘extvmisalignM’
       Extract a bit-field from memory operand 1, sign extend it, and
       store it in operand 0.  Operand 2 specifies the width in bits and
       operand 3 the starting bit.  The starting bit is always somewhere
       in the first byte of operand 1; it counts from the most significant
!      bit if ‘BITS_BIG_ENDIAN’ is true and from the least significant bit
       otherwise.
  
!      Operand 0 has mode M while operand 1 has ‘BLK’ mode.  Operands 2
       and 3 have a target-specific mode.
  
       The instruction must not read beyond the last byte of the
       bit-field.
  
! ‘extzvM’
!      Like ‘extvM’ except that the bit-field value is zero-extended.
  
! ‘extzvmisalignM’
!      Like ‘extvmisalignM’ except that the bit-field value is
       zero-extended.
  
! ‘insvM’
       Insert operand 3 into a bit-field of register operand 0.  Operand 1
       specifies the width of the field in bits and operand 2 the starting
       bit, which counts from the most significant bit if
!      ‘BITS_BIG_ENDIAN’ is true and from the least significant bit
       otherwise.
  
       Operands 0 and 3 both have mode M.  Operands 1 and 2 have a
       target-specific mode.
  
! ‘insvmisalignM’
       Insert operand 3 into a bit-field of memory operand 0.  Operand 1
       specifies the width of the field in bits and operand 2 the starting
       bit.  The starting bit is always somewhere in the first byte of
       operand 0; it counts from the most significant bit if
!      ‘BITS_BIG_ENDIAN’ is true and from the least significant bit
       otherwise.
  
!      Operand 3 has mode M while operand 0 has ‘BLK’ mode.  Operands 1
       and 2 have a target-specific mode.
  
       The instruction must not read or write beyond the last byte of the
       bit-field.
  
! ‘extv’
       Extract a bit-field from operand 1 (a register or memory operand),
       where operand 2 specifies the width in bits and operand 3 the
       starting bit, and store it in operand 0.  Operand 0 must have mode
!      ‘word_mode’.  Operand 1 may have mode ‘byte_mode’ or ‘word_mode’;
!      often ‘word_mode’ is allowed only for registers.  Operands 2 and 3
!      must be valid for ‘word_mode’.
  
       The RTL generation pass generates this instruction only with
       constants for operands 2 and 3 and the constant is never zero for
*************** pattern to accomplish a certain task.
*** 28146,28175 ****
       The bit-field value is sign-extended to a full word integer before
       it is stored in operand 0.
  
!      This pattern is deprecated; please use 'extvM' and 'extvmisalignM'
       instead.
  
! 'extzv'
!      Like 'extv' except that the bit-field value is zero-extended.
  
!      This pattern is deprecated; please use 'extzvM' and
!      'extzvmisalignM' instead.
  
! 'insv'
!      Store operand 3 (which must be valid for 'word_mode') into a
       bit-field in operand 0, where operand 1 specifies the width in bits
       and operand 2 the starting bit.  Operand 0 may have mode
!      'byte_mode' or 'word_mode'; often 'word_mode' is allowed only for
!      registers.  Operands 1 and 2 must be valid for 'word_mode'.
  
       The RTL generation pass generates this instruction only with
       constants for operands 1 and 2 and the constant is never zero for
       operand 1.
  
!      This pattern is deprecated; please use 'insvM' and 'insvmisalignM'
       instead.
  
! 'movMODEcc'
       Conditionally move operand 2 or operand 3 into operand 0 according
       to the comparison in operand 1.  If the comparison is true, operand
       2 is moved into operand 0, otherwise operand 3 is moved.
--- 28145,28174 ----
       The bit-field value is sign-extended to a full word integer before
       it is stored in operand 0.
  
!      This pattern is deprecated; please use ‘extvM’ and ‘extvmisalignM’
       instead.
  
! ‘extzv’
!      Like ‘extv’ except that the bit-field value is zero-extended.
  
!      This pattern is deprecated; please use ‘extzvM’ and
!      ‘extzvmisalignM’ instead.
  
! ‘insv’
!      Store operand 3 (which must be valid for ‘word_mode’) into a
       bit-field in operand 0, where operand 1 specifies the width in bits
       and operand 2 the starting bit.  Operand 0 may have mode
!      ‘byte_mode’ or ‘word_mode’; often ‘word_mode’ is allowed only for
!      registers.  Operands 1 and 2 must be valid for ‘word_mode’.
  
       The RTL generation pass generates this instruction only with
       constants for operands 1 and 2 and the constant is never zero for
       operand 1.
  
!      This pattern is deprecated; please use ‘insvM’ and ‘insvmisalignM’
       instead.
  
! ‘movMODEcc’
       Conditionally move operand 2 or operand 3 into operand 0 according
       to the comparison in operand 1.  If the comparison is true, operand
       2 is moved into operand 0, otherwise operand 3 is moved.
*************** pattern to accomplish a certain task.
*** 28182,28213 ****
       If the machine does not have conditional move instructions, do not
       define these patterns.
  
! 'addMODEcc'
!      Similar to 'movMODEcc' but for conditional addition.  Conditionally
       move operand 2 or (operands 2 + operand 3) into operand 0 according
       to the comparison in operand 1.  If the comparison is false,
       operand 2 is moved into operand 0, otherwise (operand 2 + operand
       3) is moved.
  
! 'cond_addMODE'
! 'cond_subMODE'
! 'cond_mulMODE'
! 'cond_divMODE'
! 'cond_udivMODE'
! 'cond_modMODE'
! 'cond_umodMODE'
! 'cond_andMODE'
! 'cond_iorMODE'
! 'cond_xorMODE'
! 'cond_sminMODE'
! 'cond_smaxMODE'
! 'cond_uminMODE'
! 'cond_umaxMODE'
! 'cond_fminMODE'
! 'cond_fmaxMODE'
! 'cond_ashlMODE'
! 'cond_ashrMODE'
! 'cond_lshrMODE'
       When operand 1 is true, perform an operation on operands 2 and 3
       and store the result in operand 0, otherwise store operand 4 in
       operand 0.  The operation works elementwise if the operands are
--- 28181,28212 ----
       If the machine does not have conditional move instructions, do not
       define these patterns.
  
! ‘addMODEcc’
!      Similar to ‘movMODEcc’ but for conditional addition.  Conditionally
       move operand 2 or (operands 2 + operand 3) into operand 0 according
       to the comparison in operand 1.  If the comparison is false,
       operand 2 is moved into operand 0, otherwise (operand 2 + operand
       3) is moved.
  
! ‘cond_addMODE’
! ‘cond_subMODE’
! ‘cond_mulMODE’
! ‘cond_divMODE’
! ‘cond_udivMODE’
! ‘cond_modMODE’
! ‘cond_umodMODE’
! ‘cond_andMODE’
! ‘cond_iorMODE’
! ‘cond_xorMODE’
! ‘cond_sminMODE’
! ‘cond_smaxMODE’
! ‘cond_uminMODE’
! ‘cond_umaxMODE’
! ‘cond_fminMODE’
! ‘cond_fmaxMODE’
! ‘cond_ashlMODE’
! ‘cond_ashrMODE’
! ‘cond_lshrMODE’
       When operand 1 is true, perform an operation on operands 2 and 3
       and store the result in operand 0, otherwise store operand 4 in
       operand 0.  The operation works elementwise if the operands are
*************** pattern to accomplish a certain task.
*** 28222,28273 ****
            for (i = 0; i < GET_MODE_NUNITS (M); i++)
              op0[i] = op1[i] ? op2[i] OP op3[i] : op4[i];
  
!      where, for example, OP is '+' for 'cond_addMODE'.
  
!      When defined for floating-point modes, the contents of 'op3[i]' are
!      not interpreted if 'op1[i]' is false, just like they would not be
!      in a normal C '?:' condition.
  
       Operands 0, 2, 3 and 4 all have mode M.  Operand 1 is a scalar
       integer if M is scalar, otherwise it has the mode returned by
!      'TARGET_VECTORIZE_GET_MASK_MODE'.
  
!      'cond_OPMODE' generally corresponds to a conditional form of
!      'OPMODE3'.  As an exception, the vector forms of shifts correspond
!      to patterns like 'vashlMODE3' rather than patterns like
!      'ashlMODE3'.
  
! 'cond_fmaMODE'
! 'cond_fmsMODE'
! 'cond_fnmaMODE'
! 'cond_fnmsMODE'
!      Like 'cond_addM', except that the conditional operation takes 3
       operands rather than two.  For example, the vector form of
!      'cond_fmaMODE' is equivalent to:
  
            for (i = 0; i < GET_MODE_NUNITS (M); i++)
              op0[i] = op1[i] ? fma (op2[i], op3[i], op4[i]) : op5[i];
  
! 'negMODEcc'
!      Similar to 'movMODEcc' but for conditional negation.  Conditionally
       move the negation of operand 2 or the unchanged operand 3 into
       operand 0 according to the comparison in operand 1.  If the
       comparison is true, the negation of operand 2 is moved into operand
       0, otherwise operand 3 is moved.
  
! 'notMODEcc'
!      Similar to 'negMODEcc' but for conditional complement.
       Conditionally move the bitwise complement of operand 2 or the
       unchanged operand 3 into operand 0 according to the comparison in
       operand 1.  If the comparison is true, the complement of operand 2
       is moved into operand 0, otherwise operand 3 is moved.
  
! 'cstoreMODE4'
       Store zero or nonzero in operand 0 according to whether a
       comparison is true.  Operand 1 is a comparison operator.  Operand 2
       and operand 3 are the first and second operand of the comparison,
       respectively.  You specify the mode that operand 0 must have when
!      you write the 'match_operand' expression.  The compiler
       automatically sees which mode you have used and supplies an operand
       of that mode.
  
--- 28221,28272 ----
            for (i = 0; i < GET_MODE_NUNITS (M); i++)
              op0[i] = op1[i] ? op2[i] OP op3[i] : op4[i];
  
!      where, for example, OP is ‘+’ for ‘cond_addMODE’.
  
!      When defined for floating-point modes, the contents of ‘op3[i]’ are
!      not interpreted if ‘op1[i]’ is false, just like they would not be
!      in a normal C ‘?:’ condition.
  
       Operands 0, 2, 3 and 4 all have mode M.  Operand 1 is a scalar
       integer if M is scalar, otherwise it has the mode returned by
!      ‘TARGET_VECTORIZE_GET_MASK_MODE’.
  
!      ‘cond_OPMODE’ generally corresponds to a conditional form of
!      ‘OPMODE3’.  As an exception, the vector forms of shifts correspond
!      to patterns like ‘vashlMODE3’ rather than patterns like
!      ‘ashlMODE3’.
  
! ‘cond_fmaMODE’
! ‘cond_fmsMODE’
! ‘cond_fnmaMODE’
! ‘cond_fnmsMODE’
!      Like ‘cond_addM’, except that the conditional operation takes 3
       operands rather than two.  For example, the vector form of
!      ‘cond_fmaMODE’ is equivalent to:
  
            for (i = 0; i < GET_MODE_NUNITS (M); i++)
              op0[i] = op1[i] ? fma (op2[i], op3[i], op4[i]) : op5[i];
  
! ‘negMODEcc’
!      Similar to ‘movMODEcc’ but for conditional negation.  Conditionally
       move the negation of operand 2 or the unchanged operand 3 into
       operand 0 according to the comparison in operand 1.  If the
       comparison is true, the negation of operand 2 is moved into operand
       0, otherwise operand 3 is moved.
  
! ‘notMODEcc’
!      Similar to ‘negMODEcc’ but for conditional complement.
       Conditionally move the bitwise complement of operand 2 or the
       unchanged operand 3 into operand 0 according to the comparison in
       operand 1.  If the comparison is true, the complement of operand 2
       is moved into operand 0, otherwise operand 3 is moved.
  
! ‘cstoreMODE4’
       Store zero or nonzero in operand 0 according to whether a
       comparison is true.  Operand 1 is a comparison operator.  Operand 2
       and operand 3 are the first and second operand of the comparison,
       respectively.  You specify the mode that operand 0 must have when
!      you write the ‘match_operand’ expression.  The compiler
       automatically sees which mode you have used and supplies an operand
       of that mode.
  
*************** pattern to accomplish a certain task.
*** 28275,28291 ****
       or else must be negative.  Otherwise the instruction is not
       suitable and you should omit it from the machine description.  You
       describe to the compiler exactly which value is stored by defining
!      the macro 'STORE_FLAG_VALUE' (*note Misc::).  If a description
       cannot be found that can be used for all the possible comparison
!      operators, you should pick one and use a 'define_expand' to map all
       results onto the one you chose.
  
!      These operations may 'FAIL', but should do so only in relatively
!      uncommon cases; if they would 'FAIL' for common cases involving
       integer comparisons, it is best to restrict the predicates to not
       allow these operands.  Likewise if a given comparison operator will
       always fail, independent of the operands (for floating-point modes,
!      the 'ordered_comparison_operator' predicate is often useful in this
       case).
  
       If this pattern is omitted, the compiler will generate a
--- 28274,28290 ----
       or else must be negative.  Otherwise the instruction is not
       suitable and you should omit it from the machine description.  You
       describe to the compiler exactly which value is stored by defining
!      the macro ‘STORE_FLAG_VALUE’ (*note Misc::).  If a description
       cannot be found that can be used for all the possible comparison
!      operators, you should pick one and use a ‘define_expand’ to map all
       results onto the one you chose.
  
!      These operations may ‘FAIL’, but should do so only in relatively
!      uncommon cases; if they would ‘FAIL’ for common cases involving
       integer comparisons, it is best to restrict the predicates to not
       allow these operands.  Likewise if a given comparison operator will
       always fail, independent of the operands (for floating-point modes,
!      the ‘ordered_comparison_operator’ predicate is often useful in this
       case).
  
       If this pattern is omitted, the compiler will generate a
*************** pattern to accomplish a certain task.
*** 28295,28386 ****
       operators, it will also try reordering the operands and/or
       inverting the result value (e.g. by an exclusive OR). These
       possibilities could be cheaper or equivalent to the instructions
!      used for the 'cstoreMODE4' pattern followed by those required to
!      convert a positive result from 'STORE_FLAG_VALUE' to 1; in this
       case, you can and should make operand 1's predicate reject some
!      operators in the 'cstoreMODE4' pattern, or remove the pattern
       altogether from the machine description.
  
! 'tbranch_OPMODE3'
       Conditional branch instruction combined with a bit test-and-compare
       instruction.  Operand 0 is the operand of the comparison.  Operand
       1 is the bit position of Operand 1 to test.  Operand 3 is the
!      'code_label' to jump to.  OP is one of EQ or NE.
  
! 'cbranchMODE4'
       Conditional branch instruction combined with a compare instruction.
       Operand 0 is a comparison operator.  Operand 1 and operand 2 are
       the first and second operands of the comparison, respectively.
!      Operand 3 is the 'code_label' to jump to.
  
! 'jump'
       A jump inside a function; an unconditional branch.  Operand 0 is
!      the 'code_label' to jump to.  This pattern name is mandatory on all
       machines.
  
! 'call'
       Subroutine call instruction returning no value.  Operand 0 is the
       function to call; operand 1 is the number of bytes of arguments
!      pushed as a 'const_int'.  Operand 2 is the result of calling the
!      target hook 'TARGET_FUNCTION_ARG' with the second argument 'arg'
!      yielding true for 'arg.end_marker_p ()', in a call after all
       parameters have been passed to that hook.  By default this is the
       first register beyond those used for arguments in the call, or
!      'NULL' if all the argument-registers are used in the call.
  
       On most machines, operand 2 is not actually stored into the RTL
       pattern.  It is supplied for the sake of some RISC machines which
       need to put this information into the assembler code; they can put
       it in the RTL instead of operand 1.
  
!      Operand 0 should be a 'mem' RTX whose address is the address of the
!      function.  Note, however, that this address can be a 'symbol_ref'
       expression even if it would not be a legitimate memory address on
       the target machine.  If it is also not a valid argument for a call
       instruction, the pattern for this operation should be a
!      'define_expand' (*note Expander Definitions::) that places the
       address into a register and uses that register in the call
       instruction.
  
! 'call_value'
       Subroutine call instruction returning a value.  Operand 0 is the
       hard register in which the value is returned.  There are three more
!      operands, the same as the three operands of the 'call' instruction
       (but with numbers increased by one).
  
!      Subroutines that return 'BLKmode' objects use the 'call' insn.
  
! 'call_pop', 'call_value_pop'
!      Similar to 'call' and 'call_value', except used if defined and if
!      'RETURN_POPS_ARGS' is nonzero.  They should emit a 'parallel' that
!      contains both the function call and a 'set' to indicate the
       adjustment made to the frame pointer.
  
!      For machines where 'RETURN_POPS_ARGS' can be nonzero, the use of
       these patterns increases the number of functions for which the
       frame pointer can be eliminated, if desired.
  
! 'untyped_call'
       Subroutine call instruction returning a value of any type.  Operand
       0 is the function to call; operand 1 is a memory location where the
       result of calling the function is to be stored; operand 2 is a
!      'parallel' expression where each element is a 'set' expression that
       indicates the saving of a function return value into the result
       block.
  
       This instruction pattern should be defined to support
!      '__builtin_apply' on machines where special instructions are needed
       to call a subroutine with arbitrary arguments or to save the value
       returned.  This instruction pattern is required on machines that
       have multiple registers that can hold a return value (i.e.
!      'FUNCTION_VALUE_REGNO_P' is true for more than one register).
  
! 'return'
       Subroutine return instruction.  This instruction pattern name
       should be defined only if a single instruction can do all the work
       of returning from a function.
  
!      Like the 'movM' patterns, this pattern is also used after the RTL
       generation phase.  In this case it is to support machines where
       multiple instructions are usually needed to return from a function,
       but some class of functions only requires one instruction to
--- 28294,28385 ----
       operators, it will also try reordering the operands and/or
       inverting the result value (e.g. by an exclusive OR). These
       possibilities could be cheaper or equivalent to the instructions
!      used for the ‘cstoreMODE4’ pattern followed by those required to
!      convert a positive result from ‘STORE_FLAG_VALUE’ to 1; in this
       case, you can and should make operand 1's predicate reject some
!      operators in the ‘cstoreMODE4’ pattern, or remove the pattern
       altogether from the machine description.
  
! ‘tbranch_OPMODE3’
       Conditional branch instruction combined with a bit test-and-compare
       instruction.  Operand 0 is the operand of the comparison.  Operand
       1 is the bit position of Operand 1 to test.  Operand 3 is the
!      ‘code_label’ to jump to.  OP is one of EQ or NE.
  
! ‘cbranchMODE4’
       Conditional branch instruction combined with a compare instruction.
       Operand 0 is a comparison operator.  Operand 1 and operand 2 are
       the first and second operands of the comparison, respectively.
!      Operand 3 is the ‘code_label’ to jump to.
  
! ‘jump’
       A jump inside a function; an unconditional branch.  Operand 0 is
!      the ‘code_label’ to jump to.  This pattern name is mandatory on all
       machines.
  
! ‘call’
       Subroutine call instruction returning no value.  Operand 0 is the
       function to call; operand 1 is the number of bytes of arguments
!      pushed as a ‘const_int’.  Operand 2 is the result of calling the
!      target hook ‘TARGET_FUNCTION_ARG’ with the second argument ‘arg’
!      yielding true for ‘arg.end_marker_p ()’, in a call after all
       parameters have been passed to that hook.  By default this is the
       first register beyond those used for arguments in the call, or
!      ‘NULL’ if all the argument-registers are used in the call.
  
       On most machines, operand 2 is not actually stored into the RTL
       pattern.  It is supplied for the sake of some RISC machines which
       need to put this information into the assembler code; they can put
       it in the RTL instead of operand 1.
  
!      Operand 0 should be a ‘mem’ RTX whose address is the address of the
!      function.  Note, however, that this address can be a ‘symbol_ref’
       expression even if it would not be a legitimate memory address on
       the target machine.  If it is also not a valid argument for a call
       instruction, the pattern for this operation should be a
!      ‘define_expand’ (*note Expander Definitions::) that places the
       address into a register and uses that register in the call
       instruction.
  
! ‘call_value’
       Subroutine call instruction returning a value.  Operand 0 is the
       hard register in which the value is returned.  There are three more
!      operands, the same as the three operands of the ‘call’ instruction
       (but with numbers increased by one).
  
!      Subroutines that return ‘BLKmode’ objects use the ‘call’ insn.
  
! ‘call_pop’, ‘call_value_pop’
!      Similar to ‘call’ and ‘call_value’, except used if defined and if
!      ‘RETURN_POPS_ARGS’ is nonzero.  They should emit a ‘parallel’ that
!      contains both the function call and a ‘set’ to indicate the
       adjustment made to the frame pointer.
  
!      For machines where ‘RETURN_POPS_ARGS’ can be nonzero, the use of
       these patterns increases the number of functions for which the
       frame pointer can be eliminated, if desired.
  
! ‘untyped_call’
       Subroutine call instruction returning a value of any type.  Operand
       0 is the function to call; operand 1 is a memory location where the
       result of calling the function is to be stored; operand 2 is a
!      ‘parallel’ expression where each element is a ‘set’ expression that
       indicates the saving of a function return value into the result
       block.
  
       This instruction pattern should be defined to support
!      ‘__builtin_apply’ on machines where special instructions are needed
       to call a subroutine with arbitrary arguments or to save the value
       returned.  This instruction pattern is required on machines that
       have multiple registers that can hold a return value (i.e.
!      ‘FUNCTION_VALUE_REGNO_P’ is true for more than one register).
  
! ‘return’
       Subroutine return instruction.  This instruction pattern name
       should be defined only if a single instruction can do all the work
       of returning from a function.
  
!      Like the ‘movM’ patterns, this pattern is also used after the RTL
       generation phase.  In this case it is to support machines where
       multiple instructions are usually needed to return from a function,
       but some class of functions only requires one instruction to
*************** pattern to accomplish a certain task.
*** 28388,28400 ****
       which do not need to save any registers or allocate stack space.
  
       It is valid for this pattern to expand to an instruction using
!      'simple_return' if no epilogue is required.
  
! 'simple_return'
       Subroutine return instruction.  This instruction pattern name
       should be defined only if a single instruction can do all the work
       of returning from a function on a path where no epilogue is
!      required.  This pattern is very similar to the 'return' instruction
       pattern, but it is emitted only by the shrink-wrapping optimization
       on paths where the function prologue has not been executed, and a
       function return should occur without any of the effects of the
--- 28387,28399 ----
       which do not need to save any registers or allocate stack space.
  
       It is valid for this pattern to expand to an instruction using
!      ‘simple_return’ if no epilogue is required.
  
! ‘simple_return’
       Subroutine return instruction.  This instruction pattern name
       should be defined only if a single instruction can do all the work
       of returning from a function on a path where no epilogue is
!      required.  This pattern is very similar to the ‘return’ instruction
       pattern, but it is emitted only by the shrink-wrapping optimization
       on paths where the function prologue has not been executed, and a
       function return should occur without any of the effects of the
*************** pattern to accomplish a certain task.
*** 28402,28410 ****
       the prologue and the epilogue have executed.
  
       For such machines, the condition specified in this pattern should
!      only be true when 'reload_completed' is nonzero and the function's
       epilogue would only be a single instruction.  For machines with
!      register windows, the routine 'leaf_function_p' may be used to
       determine if a register window push is required.
  
       Machines that have conditional return instructions should define
--- 28401,28409 ----
       the prologue and the epilogue have executed.
  
       For such machines, the condition specified in this pattern should
!      only be true when ‘reload_completed’ is nonzero and the function's
       epilogue would only be a single instruction.  For machines with
!      register windows, the routine ‘leaf_function_p’ may be used to
       determine if a register window push is required.
  
       Machines that have conditional return instructions should define
*************** pattern to accomplish a certain task.
*** 28421,28453 ****
              "...")
  
       where CONDITION would normally be the same condition specified on
!      the named 'return' pattern.
  
! 'untyped_return'
       Untyped subroutine return instruction.  This instruction pattern
!      should be defined to support '__builtin_return' on machines where
       special instructions are needed to return a value of any type.
  
       Operand 0 is a memory location where the result of calling a
!      function with '__builtin_apply' is stored; operand 1 is a
!      'parallel' expression where each element is a 'set' expression that
       indicates the restoring of a function return value from the result
       block.
  
! 'nop'
       No-op instruction.  This instruction pattern name should always be
!      defined to output a no-op in assembler code.  '(const_int 0)' will
       do as an RTL pattern.
  
! 'indirect_jump'
       An instruction to jump to an address which is operand zero.  This
       pattern name is mandatory on all machines.
  
! 'casesi'
       Instruction to jump through a dispatch table, including bounds
       checking.  This instruction takes five operands:
  
!        1. The index to dispatch on, which has mode 'SImode'.
  
         2. The lower bound for indices in the table, an integer constant.
  
--- 28420,28452 ----
              "...")
  
       where CONDITION would normally be the same condition specified on
!      the named ‘return’ pattern.
  
! ‘untyped_return’
       Untyped subroutine return instruction.  This instruction pattern
!      should be defined to support ‘__builtin_return’ on machines where
       special instructions are needed to return a value of any type.
  
       Operand 0 is a memory location where the result of calling a
!      function with ‘__builtin_apply’ is stored; operand 1 is a
!      ‘parallel’ expression where each element is a ‘set’ expression that
       indicates the restoring of a function return value from the result
       block.
  
! ‘nop’
       No-op instruction.  This instruction pattern name should always be
!      defined to output a no-op in assembler code.  ‘(const_int 0)’ will
       do as an RTL pattern.
  
! ‘indirect_jump’
       An instruction to jump to an address which is operand zero.  This
       pattern name is mandatory on all machines.
  
! ‘casesi’
       Instruction to jump through a dispatch table, including bounds
       checking.  This instruction takes five operands:
  
!        1. The index to dispatch on, which has mode ‘SImode’.
  
         2. The lower bound for indices in the table, an integer constant.
  
*************** pattern to accomplish a certain task.
*** 28459,28486 ****
         5. A label to jump to if the index has a value outside the
            bounds.
  
!      The table is an 'addr_vec' or 'addr_diff_vec' inside of a
!      'jump_table_data'.  The number of elements in the table is one plus
       the difference between the upper bound and the lower bound.
  
! 'tablejump'
       Instruction to jump to a variable address.  This is a low-level
       capability which can be used to implement a dispatch table when
!      there is no 'casesi' pattern.
  
       This pattern requires two operands: the address or offset, and a
       label which should immediately precede the jump table.  If the
!      macro 'CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then
       the first operand is an offset which counts from the address of the
       table; otherwise, it is an absolute address to jump to.  In either
!      case, the first operand has mode 'Pmode'.
  
!      The 'tablejump' insn is always the last insn before the jump table
       it uses.  Its assembler code normally has no need to use the second
       operand, but you should incorporate it in the RTL pattern so that
       the jump optimizer will not delete the table as unreachable code.
  
! 'doloop_end'
       Conditional branch instruction that decrements a register and jumps
       if the register is nonzero.  Operand 0 is the register to decrement
       and test; operand 1 is the label to jump to if the register is
--- 28458,28485 ----
         5. A label to jump to if the index has a value outside the
            bounds.
  
!      The table is an ‘addr_vec’ or ‘addr_diff_vec’ inside of a
!      ‘jump_table_data’.  The number of elements in the table is one plus
       the difference between the upper bound and the lower bound.
  
! ‘tablejump’
       Instruction to jump to a variable address.  This is a low-level
       capability which can be used to implement a dispatch table when
!      there is no ‘casesi’ pattern.
  
       This pattern requires two operands: the address or offset, and a
       label which should immediately precede the jump table.  If the
!      macro ‘CASE_VECTOR_PC_RELATIVE’ evaluates to a nonzero value then
       the first operand is an offset which counts from the address of the
       table; otherwise, it is an absolute address to jump to.  In either
!      case, the first operand has mode ‘Pmode’.
  
!      The ‘tablejump’ insn is always the last insn before the jump table
       it uses.  Its assembler code normally has no need to use the second
       operand, but you should incorporate it in the RTL pattern so that
       the jump optimizer will not delete the table as unreachable code.
  
! ‘doloop_end’
       Conditional branch instruction that decrements a register and jumps
       if the register is nonzero.  Operand 0 is the register to decrement
       and test; operand 1 is the label to jump to if the register is
*************** pattern to accomplish a certain task.
*** 28489,28513 ****
       This optional instruction pattern should be defined for machines
       with low-overhead looping instructions as the loop optimizer will
       try to modify suitable loops to utilize it.  The target hook
!      'TARGET_CAN_USE_DOLOOP_P' controls the conditions under which
       low-overhead loops can be used.
  
! 'doloop_begin'
!      Companion instruction to 'doloop_end' required for machines that
       need to perform some initialization, such as loading a special
!      counter register.  Operand 1 is the associated 'doloop_end' pattern
       and operand 0 is the register that it decrements.
  
       If initialization insns do not always need to be emitted, use a
!      'define_expand' (*note Expander Definitions::) and make it fail.
  
! 'canonicalize_funcptr_for_compare'
       Canonicalize the function pointer in operand 1 and store the result
       into operand 0.
  
!      Operand 0 is always a 'reg' and has mode 'Pmode'; operand 1 may be
!      a 'reg', 'mem', 'symbol_ref', 'const_int', etc and also has mode
!      'Pmode'.
  
       Canonicalization of a function pointer usually involves computing
       the address of the function which would be called if the function
--- 28488,28512 ----
       This optional instruction pattern should be defined for machines
       with low-overhead looping instructions as the loop optimizer will
       try to modify suitable loops to utilize it.  The target hook
!      ‘TARGET_CAN_USE_DOLOOP_P’ controls the conditions under which
       low-overhead loops can be used.
  
! ‘doloop_begin’
!      Companion instruction to ‘doloop_end’ required for machines that
       need to perform some initialization, such as loading a special
!      counter register.  Operand 1 is the associated ‘doloop_end’ pattern
       and operand 0 is the register that it decrements.
  
       If initialization insns do not always need to be emitted, use a
!      ‘define_expand’ (*note Expander Definitions::) and make it fail.
  
! ‘canonicalize_funcptr_for_compare’
       Canonicalize the function pointer in operand 1 and store the result
       into operand 0.
  
!      Operand 0 is always a ‘reg’ and has mode ‘Pmode’; operand 1 may be
!      a ‘reg’, ‘mem’, ‘symbol_ref’, ‘const_int’, etc and also has mode
!      ‘Pmode’.
  
       Canonicalization of a function pointer usually involves computing
       the address of the function which would be called if the function
*************** pattern to accomplish a certain task.
*** 28517,28553 ****
       can have different values but still call the same function when
       used in an indirect call.
  
! 'save_stack_block'
! 'save_stack_function'
! 'save_stack_nonlocal'
! 'restore_stack_block'
! 'restore_stack_function'
! 'restore_stack_nonlocal'
       Most machines save and restore the stack pointer by copying it to
!      or from an object of mode 'Pmode'.  Do not define these patterns on
       such machines.
  
       Some machines require special handling for stack pointer saves and
       restores.  On those machines, define the patterns corresponding to
!      the non-standard cases by using a 'define_expand' (*note Expander
       Definitions::) that produces the required insns.  The three types
       of saves and restores are:
  
!        1. 'save_stack_block' saves the stack pointer at the start of a
            block that allocates a variable-sized object, and
!           'restore_stack_block' restores the stack pointer when the
            block is exited.
  
!        2. 'save_stack_function' and 'restore_stack_function' do a
            similar job for the outermost block of a function and are used
            when the function allocates variable-sized objects or calls
!           'alloca'.  Only the epilogue uses the restored stack pointer,
            allowing a simpler save or restore sequence on some machines.
  
!        3. 'save_stack_nonlocal' is used in functions that contain labels
            branched to by nested functions.  It saves the stack pointer
            in such a way that the inner function can use
!           'restore_stack_nonlocal' to restore the stack pointer.  The
            compiler generates code to restore the frame and argument
            pointer registers, but some machines require saving and
            restoring additional data such as register window information
--- 28516,28552 ----
       can have different values but still call the same function when
       used in an indirect call.
  
! ‘save_stack_block’
! ‘save_stack_function’
! ‘save_stack_nonlocal’
! ‘restore_stack_block’
! ‘restore_stack_function’
! ‘restore_stack_nonlocal’
       Most machines save and restore the stack pointer by copying it to
!      or from an object of mode ‘Pmode’.  Do not define these patterns on
       such machines.
  
       Some machines require special handling for stack pointer saves and
       restores.  On those machines, define the patterns corresponding to
!      the non-standard cases by using a ‘define_expand’ (*note Expander
       Definitions::) that produces the required insns.  The three types
       of saves and restores are:
  
!        1. ‘save_stack_block’ saves the stack pointer at the start of a
            block that allocates a variable-sized object, and
!           ‘restore_stack_block’ restores the stack pointer when the
            block is exited.
  
!        2. ‘save_stack_function’ and ‘restore_stack_function’ do a
            similar job for the outermost block of a function and are used
            when the function allocates variable-sized objects or calls
!           ‘alloca’.  Only the epilogue uses the restored stack pointer,
            allowing a simpler save or restore sequence on some machines.
  
!        3. ‘save_stack_nonlocal’ is used in functions that contain labels
            branched to by nested functions.  It saves the stack pointer
            in such a way that the inner function can use
!           ‘restore_stack_nonlocal’ to restore the stack pointer.  The
            compiler generates code to restore the frame and argument
            pointer registers, but some machines require saving and
            restoring additional data such as register window information
*************** pattern to accomplish a certain task.
*** 28556,28582 ****
  
       When saving the stack pointer, operand 0 is the save area and
       operand 1 is the stack pointer.  The mode used to allocate the save
!      area defaults to 'Pmode' but you can override that choice by
!      defining the 'STACK_SAVEAREA_MODE' macro (*note Storage Layout::).
!      You must specify an integral mode, or 'VOIDmode' if no save area is
       needed for a particular type of save (either because no save is
       needed or because a machine-specific save area can be used).
       Operand 0 is the stack pointer and operand 1 is the save area for
!      restore operations.  If 'save_stack_block' is defined, operand 0
!      must not be 'VOIDmode' since these saves can be arbitrarily nested.
  
!      A save area is a 'mem' that is at a constant offset from
!      'virtual_stack_vars_rtx' when the stack pointer is saved for use by
!      nonlocal gotos and a 'reg' in the other two cases.
  
! 'allocate_stack'
!      Subtract (or add if 'STACK_GROWS_DOWNWARD' is undefined) operand 1
       from the stack pointer to create space for dynamically allocated
       data.
  
       Store the resultant pointer to this space into operand 0.  If you
       are allocating space from the main stack, do this by emitting a
!      move insn to copy 'virtual_stack_dynamic_rtx' to operand 0.  If you
       are allocating the space elsewhere, generate code to copy the
       location of the space to operand 0.  In the latter case, you must
       ensure this space gets freed when the corresponding space on the
--- 28555,28581 ----
  
       When saving the stack pointer, operand 0 is the save area and
       operand 1 is the stack pointer.  The mode used to allocate the save
!      area defaults to ‘Pmode’ but you can override that choice by
!      defining the ‘STACK_SAVEAREA_MODE’ macro (*note Storage Layout::).
!      You must specify an integral mode, or ‘VOIDmode’ if no save area is
       needed for a particular type of save (either because no save is
       needed or because a machine-specific save area can be used).
       Operand 0 is the stack pointer and operand 1 is the save area for
!      restore operations.  If ‘save_stack_block’ is defined, operand 0
!      must not be ‘VOIDmode’ since these saves can be arbitrarily nested.
  
!      A save area is a ‘mem’ that is at a constant offset from
!      ‘virtual_stack_vars_rtx’ when the stack pointer is saved for use by
!      nonlocal gotos and a ‘reg’ in the other two cases.
  
! ‘allocate_stack’
!      Subtract (or add if ‘STACK_GROWS_DOWNWARD’ is undefined) operand 1
       from the stack pointer to create space for dynamically allocated
       data.
  
       Store the resultant pointer to this space into operand 0.  If you
       are allocating space from the main stack, do this by emitting a
!      move insn to copy ‘virtual_stack_dynamic_rtx’ to operand 0.  If you
       are allocating the space elsewhere, generate code to copy the
       location of the space to operand 0.  In the latter case, you must
       ensure this space gets freed when the corresponding space on the
*************** pattern to accomplish a certain task.
*** 28587,28593 ****
       probes or maintaining the back chain.  Define this pattern to emit
       those operations in addition to updating the stack pointer.
  
! 'check_stack'
       If stack checking (*note Stack Checking::) cannot be done on your
       system by probing the stack, define this pattern to perform the
       needed check and signal an error if the stack has overflowed.  The
--- 28586,28592 ----
       probes or maintaining the back chain.  Define this pattern to emit
       those operations in addition to updating the stack pointer.
  
! ‘check_stack’
       If stack checking (*note Stack Checking::) cannot be done on your
       system by probing the stack, define this pattern to perform the
       needed check and signal an error if the stack has overflowed.  The
*************** pattern to accomplish a certain task.
*** 28596,28609 ****
       platforms where this pattern is needed, you would obtain the stack
       limit from a global or thread-specific variable or register.
  
! 'probe_stack_address'
       If stack checking (*note Stack Checking::) can be done on your
       system by probing the stack but without the need to actually access
       it, define this pattern and signal an error if the stack has
       overflowed.  The single operand is the memory address in the stack
       that needs to be probed.
  
! 'probe_stack'
       If stack checking (*note Stack Checking::) can be done on your
       system by probing the stack but doing it with a "store zero"
       instruction is not valid or optimal, define this pattern to do the
--- 28595,28608 ----
       platforms where this pattern is needed, you would obtain the stack
       limit from a global or thread-specific variable or register.
  
! ‘probe_stack_address’
       If stack checking (*note Stack Checking::) can be done on your
       system by probing the stack but without the need to actually access
       it, define this pattern and signal an error if the stack has
       overflowed.  The single operand is the memory address in the stack
       that needs to be probed.
  
! ‘probe_stack’
       If stack checking (*note Stack Checking::) can be done on your
       system by probing the stack but doing it with a "store zero"
       instruction is not valid or optimal, define this pattern to do the
*************** pattern to accomplish a certain task.
*** 28611,28617 ****
       overflowed.  The single operand is the memory reference in the
       stack that needs to be probed.
  
! 'nonlocal_goto'
       Emit code to generate a non-local goto, e.g., a jump from one
       function to a label in an outer function.  This pattern has four
       arguments, each representing a value to be used in the jump.  The
--- 28610,28616 ----
       overflowed.  The single operand is the memory reference in the
       stack that needs to be probed.
  
! ‘nonlocal_goto’
       Emit code to generate a non-local goto, e.g., a jump from one
       function to a label in an outer function.  This pattern has four
       arguments, each representing a value to be used in the jump.  The
*************** pattern to accomplish a certain task.
*** 28624,28634 ****
       On most machines you need not define this pattern, since GCC will
       already generate the correct code, which is to load the frame
       pointer and static chain, restore the stack (using the
!      'restore_stack_nonlocal' pattern, if defined), and jump indirectly
       to the dispatcher.  You need only define this pattern if this code
       will not work on your machine.
  
! 'nonlocal_goto_receiver'
       This pattern, if defined, contains code needed at the target of a
       nonlocal goto after the code already generated by GCC.  You will
       not normally need to define this pattern.  A typical reason why you
--- 28623,28633 ----
       On most machines you need not define this pattern, since GCC will
       already generate the correct code, which is to load the frame
       pointer and static chain, restore the stack (using the
!      ‘restore_stack_nonlocal’ pattern, if defined), and jump indirectly
       to the dispatcher.  You need only define this pattern if this code
       will not work on your machine.
  
! ‘nonlocal_goto_receiver’
       This pattern, if defined, contains code needed at the target of a
       nonlocal goto after the code already generated by GCC.  You will
       not normally need to define this pattern.  A typical reason why you
*************** pattern to accomplish a certain task.
*** 28638,28644 ****
       so a global table pointer that is shared by all functions of a
       given module need not be restored.  There are no arguments.
  
! 'exception_receiver'
       This pattern, if defined, contains code needed at the site of an
       exception handler that isn't needed at the site of a nonlocal goto.
       You will not normally need to define this pattern.  A typical
--- 28637,28643 ----
       so a global table pointer that is shared by all functions of a
       given module need not be restored.  There are no arguments.
  
! ‘exception_receiver’
       This pattern, if defined, contains code needed at the site of an
       exception handler that isn't needed at the site of a nonlocal goto.
       You will not normally need to define this pattern.  A typical
*************** pattern to accomplish a certain task.
*** 28646,28663 ****
       pointer to a global table, must be restored after control flow is
       branched to the handler of an exception.  There are no arguments.
  
! 'builtin_setjmp_setup'
       This pattern, if defined, contains additional code needed to
!      initialize the 'jmp_buf'.  You will not normally need to define
       this pattern.  A typical reason why you might need this pattern is
       if some value, such as a pointer to a global table, must be
       restored.  Though it is preferred that the pointer value be
       recalculated if possible (given the address of a label for
!      instance).  The single argument is a pointer to the 'jmp_buf'.
       Note that the buffer is five words long and that the first three
       are normally used by the generic mechanism.
  
! 'builtin_setjmp_receiver'
       This pattern, if defined, contains code needed at the site of a
       built-in setjmp that isn't needed at the site of a nonlocal goto.
       You will not normally need to define this pattern.  A typical
--- 28645,28662 ----
       pointer to a global table, must be restored after control flow is
       branched to the handler of an exception.  There are no arguments.
  
! ‘builtin_setjmp_setup’
       This pattern, if defined, contains additional code needed to
!      initialize the ‘jmp_buf’.  You will not normally need to define
       this pattern.  A typical reason why you might need this pattern is
       if some value, such as a pointer to a global table, must be
       restored.  Though it is preferred that the pointer value be
       recalculated if possible (given the address of a label for
!      instance).  The single argument is a pointer to the ‘jmp_buf’.
       Note that the buffer is five words long and that the first three
       are normally used by the generic mechanism.
  
! ‘builtin_setjmp_receiver’
       This pattern, if defined, contains code needed at the site of a
       built-in setjmp that isn't needed at the site of a nonlocal goto.
       You will not normally need to define this pattern.  A typical
*************** pattern to accomplish a certain task.
*** 28667,28680 ****
       control; this pattern may be emitted at a small offset from that
       label.
  
! 'builtin_longjmp'
       This pattern, if defined, performs the entire action of the
       longjmp.  You will not normally need to define this pattern unless
!      you also define 'builtin_setjmp_setup'.  The single argument is a
!      pointer to the 'jmp_buf'.
  
! 'eh_return'
!      This pattern, if defined, affects the way '__builtin_eh_return',
       and thence the call frame exception handling library routines, are
       built.  It is intended to handle non-trivial actions needed along
       the abnormal return path.
--- 28666,28679 ----
       control; this pattern may be emitted at a small offset from that
       label.
  
! ‘builtin_longjmp’
       This pattern, if defined, performs the entire action of the
       longjmp.  You will not normally need to define this pattern unless
!      you also define ‘builtin_setjmp_setup’.  The single argument is a
!      pointer to the ‘jmp_buf’.
  
! ‘eh_return’
!      This pattern, if defined, affects the way ‘__builtin_eh_return’,
       and thence the call frame exception handling library routines, are
       built.  It is intended to handle non-trivial actions needed along
       the abnormal return path.
*************** pattern to accomplish a certain task.
*** 28684,28749 ****
       to copied by the pattern to some special register or memory
       location.  If the pattern needs to determine the location of the
       target call frame in order to do so, it may use
!      'EH_RETURN_STACKADJ_RTX', if defined; it will have already been
       assigned.
  
       If this pattern is not defined, the default action will be to
!      simply copy the return address to 'EH_RETURN_HANDLER_RTX'.  Either
       that macro or this pattern needs to be defined if call frame
       exception handling is to be used.
  
! 'prologue'
       This pattern, if defined, emits RTL for entry to a function.  The
       function entry is responsible for setting up the stack frame,
       initializing the frame pointer register, saving callee saved
       registers, etc.
  
       Using a prologue pattern is generally preferred over defining
!      'TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the
       prologue.
  
!      The 'prologue' pattern is particularly useful for targets which
       perform instruction scheduling.
  
! 'window_save'
       This pattern, if defined, emits RTL for a register window save.  It
       should be defined if the target machine has register windows but
       the window events are decoupled from calls to subroutines.  The
       canonical example is the SPARC architecture.
  
! 'epilogue'
       This pattern emits RTL for exit from a function.  The function exit
       is responsible for deallocating the stack frame, restoring callee
       saved registers and emitting the return instruction.
  
       Using an epilogue pattern is generally preferred over defining
!      'TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the
       epilogue.
  
!      The 'epilogue' pattern is particularly useful for targets which
       perform instruction scheduling or which have delay slots for their
       return instruction.
  
! 'sibcall_epilogue'
       This pattern, if defined, emits RTL for exit from a function
       without the final branch back to the calling function.  This
       pattern will be emitted before any sibling call (aka tail call)
       sites.
  
!      The 'sibcall_epilogue' pattern must not clobber any arguments used
       for parameter passing or any stack slots for arguments passed to
       the current function.
  
! 'trap'
       This pattern, if defined, signals an error, typically by causing
       some kind of signal to be raised.
  
! 'ctrapMM4'
       Conditional trap instruction.  Operand 0 is a piece of RTL which
       performs a comparison, and operands 1 and 2 are the arms of the
       comparison.  Operand 3 is the trap code, an integer.
  
!      A typical 'ctrap' pattern looks like
  
            (define_insn "ctrapsi4"
              [(trap_if (match_operator 0 "trap_operator"
--- 28683,28748 ----
       to copied by the pattern to some special register or memory
       location.  If the pattern needs to determine the location of the
       target call frame in order to do so, it may use
!      ‘EH_RETURN_STACKADJ_RTX’, if defined; it will have already been
       assigned.
  
       If this pattern is not defined, the default action will be to
!      simply copy the return address to ‘EH_RETURN_HANDLER_RTX’.  Either
       that macro or this pattern needs to be defined if call frame
       exception handling is to be used.
  
! ‘prologue’
       This pattern, if defined, emits RTL for entry to a function.  The
       function entry is responsible for setting up the stack frame,
       initializing the frame pointer register, saving callee saved
       registers, etc.
  
       Using a prologue pattern is generally preferred over defining
!      ‘TARGET_ASM_FUNCTION_PROLOGUE’ to emit assembly code for the
       prologue.
  
!      The ‘prologue’ pattern is particularly useful for targets which
       perform instruction scheduling.
  
! ‘window_save’
       This pattern, if defined, emits RTL for a register window save.  It
       should be defined if the target machine has register windows but
       the window events are decoupled from calls to subroutines.  The
       canonical example is the SPARC architecture.
  
! ‘epilogue’
       This pattern emits RTL for exit from a function.  The function exit
       is responsible for deallocating the stack frame, restoring callee
       saved registers and emitting the return instruction.
  
       Using an epilogue pattern is generally preferred over defining
!      ‘TARGET_ASM_FUNCTION_EPILOGUE’ to emit assembly code for the
       epilogue.
  
!      The ‘epilogue’ pattern is particularly useful for targets which
       perform instruction scheduling or which have delay slots for their
       return instruction.
  
! ‘sibcall_epilogue’
       This pattern, if defined, emits RTL for exit from a function
       without the final branch back to the calling function.  This
       pattern will be emitted before any sibling call (aka tail call)
       sites.
  
!      The ‘sibcall_epilogue’ pattern must not clobber any arguments used
       for parameter passing or any stack slots for arguments passed to
       the current function.
  
! ‘trap’
       This pattern, if defined, signals an error, typically by causing
       some kind of signal to be raised.
  
! ‘ctrapMM4’
       Conditional trap instruction.  Operand 0 is a piece of RTL which
       performs a comparison, and operands 1 and 2 are the arms of the
       comparison.  Operand 3 is the trap code, an integer.
  
!      A typical ‘ctrap’ pattern looks like
  
            (define_insn "ctrapsi4"
              [(trap_if (match_operator 0 "trap_operator"
*************** pattern to accomplish a certain task.
*** 28753,28759 ****
              ""
              "...")
  
! 'prefetch'
       This pattern, if defined, emits code for a non-faulting data
       prefetch instruction.  Operand 0 is the address of the memory to
       prefetch.  Operand 1 is a constant 1 if the prefetch is preparing
--- 28752,28758 ----
              ""
              "...")
  
! ‘prefetch’
       This pattern, if defined, emits code for a non-faulting data
       prefetch instruction.  Operand 0 is the address of the memory to
       prefetch.  Operand 1 is a constant 1 if the prefetch is preparing
*************** pattern to accomplish a certain task.
*** 28769,28797 ****
       Targets that do not support write prefetches or locality hints can
       ignore the values of operands 1 and 2.
  
! 'blockage'
       This pattern defines a pseudo insn that prevents the instruction
       scheduler and other passes from moving instructions and using
       register equivalences across the boundary defined by the blockage
       insn.  This needs to be an UNSPEC_VOLATILE pattern or a volatile
       ASM.
  
! 'memory_blockage'
       This pattern, if defined, represents a compiler memory barrier, and
       will be placed at points across which RTL passes may not propagate
       memory accesses.  This instruction needs to read and write volatile
       BLKmode memory.  It does not need to generate any machine
       instruction.  If this pattern is not defined, the compiler falls
!      back to emitting an instruction corresponding to 'asm volatile (""
!      ::: "memory")'.
  
! 'memory_barrier'
       If the target memory model is not fully synchronous, then this
       pattern should be defined to an instruction that orders both loads
       and stores before the instruction with respect to loads and stores
       after the instruction.  This pattern has no operands.
  
! 'speculation_barrier'
       If the target can support speculative execution, then this pattern
       should be defined to an instruction that will block subsequent
       execution until any prior speculation conditions has been resolved.
--- 28768,28796 ----
       Targets that do not support write prefetches or locality hints can
       ignore the values of operands 1 and 2.
  
! ‘blockage’
       This pattern defines a pseudo insn that prevents the instruction
       scheduler and other passes from moving instructions and using
       register equivalences across the boundary defined by the blockage
       insn.  This needs to be an UNSPEC_VOLATILE pattern or a volatile
       ASM.
  
! ‘memory_blockage’
       This pattern, if defined, represents a compiler memory barrier, and
       will be placed at points across which RTL passes may not propagate
       memory accesses.  This instruction needs to read and write volatile
       BLKmode memory.  It does not need to generate any machine
       instruction.  If this pattern is not defined, the compiler falls
!      back to emitting an instruction corresponding to ‘asm volatile (""
!      ::: "memory")’.
  
! ‘memory_barrier’
       If the target memory model is not fully synchronous, then this
       pattern should be defined to an instruction that orders both loads
       and stores before the instruction with respect to loads and stores
       after the instruction.  This pattern has no operands.
  
! ‘speculation_barrier’
       If the target can support speculative execution, then this pattern
       should be defined to an instruction that will block subsequent
       execution until any prior speculation conditions has been resolved.
*************** pattern to accomplish a certain task.
*** 28800,28811 ****
       pattern.  The pattern has no operands.
  
       If this pattern is not defined then the default expansion of
!      '__builtin_speculation_safe_value' will emit a warning.  You can
       suppress this warning by defining this pattern with a final
!      condition of '0' (zero), which tells the compiler that a
       speculation barrier is not needed for this target.
  
! 'sync_compare_and_swapMODE'
       This pattern, if defined, emits code for an atomic compare-and-swap
       operation.  Operand 1 is the memory on which the atomic operation
       is performed.  Operand 2 is the "old" value to be compared against
--- 28799,28810 ----
       pattern.  The pattern has no operands.
  
       If this pattern is not defined then the default expansion of
!      ‘__builtin_speculation_safe_value’ will emit a warning.  You can
       suppress this warning by defining this pattern with a final
!      condition of ‘0’ (zero), which tells the compiler that a
       speculation barrier is not needed for this target.
  
! ‘sync_compare_and_swapMODE’
       This pattern, if defined, emits code for an atomic compare-and-swap
       operation.  Operand 1 is the memory on which the atomic operation
       is performed.  Operand 2 is the "old" value to be compared against
*************** pattern to accomplish a certain task.
*** 28827,28853 ****
       operation is available via the status flags, it is possible to
       avoid a separate compare operation and issue the subsequent branch
       or store-flag operation immediately after the compare-and-swap.  To
!      this end, GCC will look for a 'MODE_CC' set in the output of
!      'sync_compare_and_swapMODE'; if the machine description includes
!      such a set, the target should also define special 'cbranchcc4'
!      and/or 'cstorecc4' instructions.  GCC will then be able to take the
!      destination of the 'MODE_CC' set and pass it to the 'cbranchcc4' or
!      'cstorecc4' pattern as the first operand of the comparison (the
!      second will be '(const_int 0)').
  
       For targets where the operating system may provide support for this
!      operation via library calls, the 'sync_compare_and_swap_optab' may
       be initialized to a function with the same interface as the
!      '__sync_val_compare_and_swap_N' built-in.  If the entire set of
       __SYNC builtins are supported via library calls, the target can
!      initialize all of the optabs at once with 'init_sync_libfuncs'.
!      For the purposes of C++11 'std::atomic::is_lock_free', it is
       assumed that these library calls do _not_ use any kind of
       interruptable locking.
  
! 'sync_addMODE', 'sync_subMODE'
! 'sync_iorMODE', 'sync_andMODE'
! 'sync_xorMODE', 'sync_nandMODE'
       These patterns emit code for an atomic operation on memory.
       Operand 0 is the memory on which the atomic operation is performed.
       Operand 1 is the second operand to the binary operator.
--- 28826,28852 ----
       operation is available via the status flags, it is possible to
       avoid a separate compare operation and issue the subsequent branch
       or store-flag operation immediately after the compare-and-swap.  To
!      this end, GCC will look for a ‘MODE_CC’ set in the output of
!      ‘sync_compare_and_swapMODE’; if the machine description includes
!      such a set, the target should also define special ‘cbranchcc4’
!      and/or ‘cstorecc4’ instructions.  GCC will then be able to take the
!      destination of the ‘MODE_CC’ set and pass it to the ‘cbranchcc4’ or
!      ‘cstorecc4’ pattern as the first operand of the comparison (the
!      second will be ‘(const_int 0)’).
  
       For targets where the operating system may provide support for this
!      operation via library calls, the ‘sync_compare_and_swap_optab’ may
       be initialized to a function with the same interface as the
!      ‘__sync_val_compare_and_swap_N’ built-in.  If the entire set of
       __SYNC builtins are supported via library calls, the target can
!      initialize all of the optabs at once with ‘init_sync_libfuncs’.
!      For the purposes of C++11 ‘std::atomic::is_lock_free’, it is
       assumed that these library calls do _not_ use any kind of
       interruptable locking.
  
! ‘sync_addMODE’, ‘sync_subMODE’
! ‘sync_iorMODE’, ‘sync_andMODE’
! ‘sync_xorMODE’, ‘sync_nandMODE’
       These patterns emit code for an atomic operation on memory.
       Operand 0 is the memory on which the atomic operation is performed.
       Operand 1 is the second operand to the binary operator.
*************** pattern to accomplish a certain task.
*** 28860,28868 ****
       If these patterns are not defined, the operation will be
       constructed from a compare-and-swap operation, if defined.
  
! 'sync_old_addMODE', 'sync_old_subMODE'
! 'sync_old_iorMODE', 'sync_old_andMODE'
! 'sync_old_xorMODE', 'sync_old_nandMODE'
       These patterns emit code for an atomic operation on memory, and
       return the value that the memory contained before the operation.
       Operand 0 is the result value, operand 1 is the memory on which the
--- 28859,28867 ----
       If these patterns are not defined, the operation will be
       constructed from a compare-and-swap operation, if defined.
  
! ‘sync_old_addMODE’, ‘sync_old_subMODE’
! ‘sync_old_iorMODE’, ‘sync_old_andMODE’
! ‘sync_old_xorMODE’, ‘sync_old_nandMODE’
       These patterns emit code for an atomic operation on memory, and
       return the value that the memory contained before the operation.
       Operand 0 is the result value, operand 1 is the memory on which the
*************** pattern to accomplish a certain task.
*** 28877,28890 ****
       If these patterns are not defined, the operation will be
       constructed from a compare-and-swap operation, if defined.
  
! 'sync_new_addMODE', 'sync_new_subMODE'
! 'sync_new_iorMODE', 'sync_new_andMODE'
! 'sync_new_xorMODE', 'sync_new_nandMODE'
!      These patterns are like their 'sync_old_OP' counterparts, except
       that they return the value that exists in the memory location after
       the operation, rather than before the operation.
  
! 'sync_lock_test_and_setMODE'
       This pattern takes two forms, based on the capabilities of the
       target.  In either case, operand 0 is the result of the operand,
       operand 1 is the memory on which the atomic operation is performed,
--- 28876,28889 ----
       If these patterns are not defined, the operation will be
       constructed from a compare-and-swap operation, if defined.
  
! ‘sync_new_addMODE’, ‘sync_new_subMODE’
! ‘sync_new_iorMODE’, ‘sync_new_andMODE’
! ‘sync_new_xorMODE’, ‘sync_new_nandMODE’
!      These patterns are like their ‘sync_old_OP’ counterparts, except
       that they return the value that exists in the memory location after
       the operation, rather than before the operation.
  
! ‘sync_lock_test_and_setMODE’
       This pattern takes two forms, based on the capabilities of the
       target.  In either case, operand 0 is the result of the operand,
       operand 1 is the memory on which the atomic operation is performed,
*************** pattern to accomplish a certain task.
*** 28896,28902 ****
       operand.
  
       For less capable targets, any value operand that is not the
!      constant 1 should be rejected with 'FAIL'.  In this case the target
       may use an atomic test-and-set bit operation.  The result operand
       should contain 1 if the bit was previously set and 0 if the bit was
       previously clear.  The true contents of the memory operand are
--- 28895,28901 ----
       operand.
  
       For less capable targets, any value operand that is not the
!      constant 1 should be rejected with ‘FAIL’.  In this case the target
       may use an atomic test-and-set bit operation.  The result operand
       should contain 1 if the bit was previously set and 0 if the bit was
       previously clear.  The true contents of the memory operand are
*************** pattern to accomplish a certain task.
*** 28910,28923 ****
       If this pattern is not defined, the operation will be constructed
       from a compare-and-swap operation, if defined.
  
! 'sync_lock_releaseMODE'
       This pattern, if defined, releases a lock set by
!      'sync_lock_test_and_setMODE'.  Operand 0 is the memory that
       contains the lock; operand 1 is the value to store in the lock.
  
       If the target doesn't implement full semantics for
!      'sync_lock_test_and_setMODE', any value operand which is not the
!      constant 0 should be rejected with 'FAIL', and the true contents of
       the memory operand are implementation defined.
  
       This pattern must issue any memory barrier instructions such that
--- 28909,28922 ----
       If this pattern is not defined, the operation will be constructed
       from a compare-and-swap operation, if defined.
  
! ‘sync_lock_releaseMODE’
       This pattern, if defined, releases a lock set by
!      ‘sync_lock_test_and_setMODE’.  Operand 0 is the memory that
       contains the lock; operand 1 is the value to store in the lock.
  
       If the target doesn't implement full semantics for
!      ‘sync_lock_test_and_setMODE’, any value operand which is not the
!      constant 0 should be rejected with ‘FAIL’, and the true contents of
       the memory operand are implementation defined.
  
       This pattern must issue any memory barrier instructions such that
*************** pattern to accomplish a certain task.
*** 28925,28935 ****
       is released only after all previous memory operations have
       completed.
  
!      If this pattern is not defined, then a 'memory_barrier' pattern
       will be emitted, followed by a store of the value to the memory
       operand.
  
! 'atomic_compare_and_swapMODE'
       This pattern, if defined, emits code for an atomic compare-and-swap
       operation with memory model semantics.  Operand 2 is the memory on
       which the atomic operation is performed.  Operand 0 is an output
--- 28924,28934 ----
       is released only after all previous memory operations have
       completed.
  
!      If this pattern is not defined, then a ‘memory_barrier’ pattern
       will be emitted, followed by a store of the value to the memory
       operand.
  
! ‘atomic_compare_and_swapMODE’
       This pattern, if defined, emits code for an atomic compare-and-swap
       operation with memory model semantics.  Operand 2 is the memory on
       which the atomic operation is performed.  Operand 0 is an output
*************** pattern to accomplish a certain task.
*** 28956,28987 ****
       operand 5 can be ignored.  Note a strong implementation must be
       provided.
  
!      If this pattern is not provided, the '__atomic_compare_exchange'
!      built-in functions will utilize the legacy 'sync_compare_and_swap'
!      pattern with an '__ATOMIC_SEQ_CST' memory model.
  
! 'atomic_loadMODE'
       This pattern implements an atomic load operation with memory model
       semantics.  Operand 1 is the memory address being loaded from.
       Operand 0 is the result of the load.  Operand 2 is the memory model
       to be used for the load operation.
  
!      If not present, the '__atomic_load' built-in function will either
       resort to a normal load with memory barriers, or a compare-and-swap
       operation if a normal load would not be atomic.
  
! 'atomic_storeMODE'
       This pattern implements an atomic store operation with memory model
       semantics.  Operand 0 is the memory address being stored to.
       Operand 1 is the value to be written.  Operand 2 is the memory
       model to be used for the operation.
  
!      If not present, the '__atomic_store' built-in function will attempt
       to perform a normal store and surround it with any required memory
       fences.  If the store would not be atomic, then an
!      '__atomic_exchange' is attempted with the result being ignored.
  
! 'atomic_exchangeMODE'
       This pattern implements an atomic exchange operation with memory
       model semantics.  Operand 1 is the memory location the operation is
       performed on.  Operand 0 is an output operand which is set to the
--- 28955,28986 ----
       operand 5 can be ignored.  Note a strong implementation must be
       provided.
  
!      If this pattern is not provided, the ‘__atomic_compare_exchange’
!      built-in functions will utilize the legacy ‘sync_compare_and_swap’
!      pattern with an ‘__ATOMIC_SEQ_CST’ memory model.
  
! ‘atomic_loadMODE’
       This pattern implements an atomic load operation with memory model
       semantics.  Operand 1 is the memory address being loaded from.
       Operand 0 is the result of the load.  Operand 2 is the memory model
       to be used for the load operation.
  
!      If not present, the ‘__atomic_load’ built-in function will either
       resort to a normal load with memory barriers, or a compare-and-swap
       operation if a normal load would not be atomic.
  
! ‘atomic_storeMODE’
       This pattern implements an atomic store operation with memory model
       semantics.  Operand 0 is the memory address being stored to.
       Operand 1 is the value to be written.  Operand 2 is the memory
       model to be used for the operation.
  
!      If not present, the ‘__atomic_store’ built-in function will attempt
       to perform a normal store and surround it with any required memory
       fences.  If the store would not be atomic, then an
!      ‘__atomic_exchange’ is attempted with the result being ignored.
  
! ‘atomic_exchangeMODE’
       This pattern implements an atomic exchange operation with memory
       model semantics.  Operand 1 is the memory location the operation is
       performed on.  Operand 0 is an output operand which is set to the
*************** pattern to accomplish a certain task.
*** 28990,29001 ****
       to be used.
  
       If this pattern is not present, the built-in function
!      '__atomic_exchange' will attempt to preform the operation with a
       compare and swap loop.
  
! 'atomic_addMODE', 'atomic_subMODE'
! 'atomic_orMODE', 'atomic_andMODE'
! 'atomic_xorMODE', 'atomic_nandMODE'
       These patterns emit code for an atomic operation on memory with
       memory model semantics.  Operand 0 is the memory on which the
       atomic operation is performed.  Operand 1 is the second operand to
--- 28989,29000 ----
       to be used.
  
       If this pattern is not present, the built-in function
!      ‘__atomic_exchange’ will attempt to preform the operation with a
       compare and swap loop.
  
! ‘atomic_addMODE’, ‘atomic_subMODE’
! ‘atomic_orMODE’, ‘atomic_andMODE’
! ‘atomic_xorMODE’, ‘atomic_nandMODE’
       These patterns emit code for an atomic operation on memory with
       memory model semantics.  Operand 0 is the memory on which the
       atomic operation is performed.  Operand 1 is the second operand to
*************** pattern to accomplish a certain task.
*** 29003,29015 ****
       the operation.
  
       If these patterns are not defined, attempts will be made to use
!      legacy 'sync' patterns, or equivalent patterns which return a
       result.  If none of these are available a compare-and-swap loop
       will be used.
  
! 'atomic_fetch_addMODE', 'atomic_fetch_subMODE'
! 'atomic_fetch_orMODE', 'atomic_fetch_andMODE'
! 'atomic_fetch_xorMODE', 'atomic_fetch_nandMODE'
       These patterns emit code for an atomic operation on memory with
       memory model semantics, and return the original value.  Operand 0
       is an output operand which contains the value of the memory
--- 29002,29014 ----
       the operation.
  
       If these patterns are not defined, attempts will be made to use
!      legacy ‘sync’ patterns, or equivalent patterns which return a
       result.  If none of these are available a compare-and-swap loop
       will be used.
  
! ‘atomic_fetch_addMODE’, ‘atomic_fetch_subMODE’
! ‘atomic_fetch_orMODE’, ‘atomic_fetch_andMODE’
! ‘atomic_fetch_xorMODE’, ‘atomic_fetch_nandMODE’
       These patterns emit code for an atomic operation on memory with
       memory model semantics, and return the original value.  Operand 0
       is an output operand which contains the value of the memory
*************** pattern to accomplish a certain task.
*** 29019,29030 ****
       model to be used by the operation.
  
       If these patterns are not defined, attempts will be made to use
!      legacy 'sync' patterns.  If none of these are available a
       compare-and-swap loop will be used.
  
! 'atomic_add_fetchMODE', 'atomic_sub_fetchMODE'
! 'atomic_or_fetchMODE', 'atomic_and_fetchMODE'
! 'atomic_xor_fetchMODE', 'atomic_nand_fetchMODE'
       These patterns emit code for an atomic operation on memory with
       memory model semantics and return the result after the operation is
       performed.  Operand 0 is an output operand which contains the value
--- 29018,29029 ----
       model to be used by the operation.
  
       If these patterns are not defined, attempts will be made to use
!      legacy ‘sync’ patterns.  If none of these are available a
       compare-and-swap loop will be used.
  
! ‘atomic_add_fetchMODE’, ‘atomic_sub_fetchMODE’
! ‘atomic_or_fetchMODE’, ‘atomic_and_fetchMODE’
! ‘atomic_xor_fetchMODE’, ‘atomic_nand_fetchMODE’
       These patterns emit code for an atomic operation on memory with
       memory model semantics and return the result after the operation is
       performed.  Operand 0 is an output operand which contains the value
*************** pattern to accomplish a certain task.
*** 29034,29058 ****
       operation.
  
       If these patterns are not defined, attempts will be made to use
!      legacy 'sync' patterns, or equivalent patterns which return the
       result before the operation followed by the arithmetic operation
       required to produce the result.  If none of these are available a
       compare-and-swap loop will be used.
  
! 'atomic_test_and_set'
!      This pattern emits code for '__builtin_atomic_test_and_set'.
       Operand 0 is an output operand which is set to true if the previous
       previous contents of the byte was "set", and false otherwise.
!      Operand 1 is the 'QImode' memory to be modified.  Operand 2 is the
       memory model to be used.
  
       The specific value that defines "set" is implementation defined,
       and is normally based on what is performed by the native atomic
       test and set instruction.
  
! 'atomic_bit_test_and_setMODE'
! 'atomic_bit_test_and_complementMODE'
! 'atomic_bit_test_and_resetMODE'
       These patterns emit code for an atomic bitwise operation on memory
       with memory model semantics, and return the original value of the
       specified bit.  Operand 0 is an output operand which contains the
--- 29033,29057 ----
       operation.
  
       If these patterns are not defined, attempts will be made to use
!      legacy ‘sync’ patterns, or equivalent patterns which return the
       result before the operation followed by the arithmetic operation
       required to produce the result.  If none of these are available a
       compare-and-swap loop will be used.
  
! ‘atomic_test_and_set’
!      This pattern emits code for ‘__builtin_atomic_test_and_set’.
       Operand 0 is an output operand which is set to true if the previous
       previous contents of the byte was "set", and false otherwise.
!      Operand 1 is the ‘QImode’ memory to be modified.  Operand 2 is the
       memory model to be used.
  
       The specific value that defines "set" is implementation defined,
       and is normally based on what is performed by the native atomic
       test and set instruction.
  
! ‘atomic_bit_test_and_setMODE’
! ‘atomic_bit_test_and_complementMODE’
! ‘atomic_bit_test_and_resetMODE’
       These patterns emit code for an atomic bitwise operation on memory
       with memory model semantics, and return the original value of the
       specified bit.  Operand 0 is an output operand which contains the
*************** pattern to accomplish a certain task.
*** 29061,29085 ****
       atomic operation is performed.  Operand 2 is the bit within the
       operand, starting with least significant bit.  Operand 3 is the
       memory model to be used by the operation.  Operand 4 is a flag - it
!      is 'const1_rtx' if operand 0 should contain the original value of
       the specified bit in the least significant bit of the operand, and
!      'const0_rtx' if the bit should be in its original position in the
!      operand.  'atomic_bit_test_and_setMODE' atomically sets the
       specified bit after remembering its original value,
!      'atomic_bit_test_and_complementMODE' inverts the specified bit and
!      'atomic_bit_test_and_resetMODE' clears the specified bit.
  
       If these patterns are not defined, attempts will be made to use
!      'atomic_fetch_orMODE', 'atomic_fetch_xorMODE' or
!      'atomic_fetch_andMODE' instruction patterns, or their 'sync'
       counterparts.  If none of these are available a compare-and-swap
       loop will be used.
  
! 'atomic_add_fetch_cmp_0MODE'
! 'atomic_sub_fetch_cmp_0MODE'
! 'atomic_and_fetch_cmp_0MODE'
! 'atomic_or_fetch_cmp_0MODE'
! 'atomic_xor_fetch_cmp_0MODE'
       These patterns emit code for an atomic operation on memory with
       memory model semantics if the fetch result is used only in a
       comparison against zero.  Operand 0 is an output operand which
--- 29060,29084 ----
       atomic operation is performed.  Operand 2 is the bit within the
       operand, starting with least significant bit.  Operand 3 is the
       memory model to be used by the operation.  Operand 4 is a flag - it
!      is ‘const1_rtx’ if operand 0 should contain the original value of
       the specified bit in the least significant bit of the operand, and
!      ‘const0_rtx’ if the bit should be in its original position in the
!      operand.  ‘atomic_bit_test_and_setMODE’ atomically sets the
       specified bit after remembering its original value,
!      ‘atomic_bit_test_and_complementMODE’ inverts the specified bit and
!      ‘atomic_bit_test_and_resetMODE’ clears the specified bit.
  
       If these patterns are not defined, attempts will be made to use
!      ‘atomic_fetch_orMODE’, ‘atomic_fetch_xorMODE’ or
!      ‘atomic_fetch_andMODE’ instruction patterns, or their ‘sync’
       counterparts.  If none of these are available a compare-and-swap
       loop will be used.
  
! ‘atomic_add_fetch_cmp_0MODE’
! ‘atomic_sub_fetch_cmp_0MODE’
! ‘atomic_and_fetch_cmp_0MODE’
! ‘atomic_or_fetch_cmp_0MODE’
! ‘atomic_xor_fetch_cmp_0MODE’
       These patterns emit code for an atomic operation on memory with
       memory model semantics if the fetch result is used only in a
       comparison against zero.  Operand 0 is an output operand which
*************** pattern to accomplish a certain task.
*** 29088,29142 ****
       atomic operation is performed.  Operand 2 is the second operand to
       the binary operator.  Operand 3 is the memory model to be used by
       the operation.  Operand 4 is an integer holding the comparison
!      code, one of 'EQ', 'NE', 'LT', 'GT', 'LE' or 'GE'.
  
       If these patterns are not defined, attempts will be made to use
       separate atomic operation and fetch pattern followed by comparison
       of the result against zero.
  
! 'mem_thread_fence'
       This pattern emits code required to implement a thread fence with
       memory model semantics.  Operand 0 is the memory model to be used.
  
!      For the '__ATOMIC_RELAXED' model no instructions need to be issued
       and this expansion is not invoked.
  
       The compiler always emits a compiler memory barrier regardless of
       what expanding this pattern produced.
  
       If this pattern is not defined, the compiler falls back to
!      expanding the 'memory_barrier' pattern, then to emitting
!      '__sync_synchronize' library call, and finally to just placing a
       compiler memory barrier.
  
! 'get_thread_pointerMODE'
! 'set_thread_pointerMODE'
       These patterns emit code that reads/sets the TLS thread pointer.
       Currently, these are only needed if the target needs to support the
!      '__builtin_thread_pointer' and '__builtin_set_thread_pointer'
       builtins.
  
       The get/set patterns have a single output/input operand
!      respectively, with MODE intended to be 'Pmode'.
  
! 'stack_protect_combined_set'
!      This pattern, if defined, moves a 'ptr_mode' value from an address
       whose declaration RTX is given in operand 1 to the memory in
       operand 0 without leaving the value in a register afterward.  If
       several instructions are needed by the target to perform the
       operation (eg.  to load the address from a GOT entry then load the
!      'ptr_mode' value and finally store it), it is the backend's
       responsibility to ensure no intermediate result gets spilled.  This
       is to avoid leaking the value some place that an attacker might use
       to rewrite the stack guard slot after having clobbered it.
  
       If this pattern is not defined, then the address declaration is
!      expanded first in the standard way and a 'stack_protect_set'
       pattern is then generated to move the value from that address to
       the address in operand 0.
  
! 'stack_protect_set'
!      This pattern, if defined, moves a 'ptr_mode' value from the valid
       memory location in operand 1 to the memory in operand 0 without
       leaving the value in a register afterward.  This is to avoid
       leaking the value some place that an attacker might use to rewrite
--- 29087,29141 ----
       atomic operation is performed.  Operand 2 is the second operand to
       the binary operator.  Operand 3 is the memory model to be used by
       the operation.  Operand 4 is an integer holding the comparison
!      code, one of ‘EQ’, ‘NE’, ‘LT’, ‘GT’, ‘LE’ or ‘GE’.
  
       If these patterns are not defined, attempts will be made to use
       separate atomic operation and fetch pattern followed by comparison
       of the result against zero.
  
! ‘mem_thread_fence’
       This pattern emits code required to implement a thread fence with
       memory model semantics.  Operand 0 is the memory model to be used.
  
!      For the ‘__ATOMIC_RELAXED’ model no instructions need to be issued
       and this expansion is not invoked.
  
       The compiler always emits a compiler memory barrier regardless of
       what expanding this pattern produced.
  
       If this pattern is not defined, the compiler falls back to
!      expanding the ‘memory_barrier’ pattern, then to emitting
!      ‘__sync_synchronize’ library call, and finally to just placing a
       compiler memory barrier.
  
! ‘get_thread_pointerMODE’
! ‘set_thread_pointerMODE’
       These patterns emit code that reads/sets the TLS thread pointer.
       Currently, these are only needed if the target needs to support the
!      ‘__builtin_thread_pointer’ and ‘__builtin_set_thread_pointer’
       builtins.
  
       The get/set patterns have a single output/input operand
!      respectively, with MODE intended to be ‘Pmode’.
  
! ‘stack_protect_combined_set’
!      This pattern, if defined, moves a ‘ptr_mode’ value from an address
       whose declaration RTX is given in operand 1 to the memory in
       operand 0 without leaving the value in a register afterward.  If
       several instructions are needed by the target to perform the
       operation (eg.  to load the address from a GOT entry then load the
!      ‘ptr_mode’ value and finally store it), it is the backend's
       responsibility to ensure no intermediate result gets spilled.  This
       is to avoid leaking the value some place that an attacker might use
       to rewrite the stack guard slot after having clobbered it.
  
       If this pattern is not defined, then the address declaration is
!      expanded first in the standard way and a ‘stack_protect_set’
       pattern is then generated to move the value from that address to
       the address in operand 0.
  
! ‘stack_protect_set’
!      This pattern, if defined, moves a ‘ptr_mode’ value from the valid
       memory location in operand 1 to the memory in operand 0 without
       leaving the value in a register afterward.  This is to avoid
       leaking the value some place that an attacker might use to rewrite
*************** pattern to accomplish a certain task.
*** 29149,29173 ****
       If this pattern is not defined, then a plain move pattern is
       generated.
  
! 'stack_protect_combined_test'
!      This pattern, if defined, compares a 'ptr_mode' value from an
       address whose declaration RTX is given in operand 1 with the memory
       in operand 0 without leaving the value in a register afterward and
       branches to operand 2 if the values were equal.  If several
       instructions are needed by the target to perform the operation (eg.
!      to load the address from a GOT entry then load the 'ptr_mode' value
       and finally store it), it is the backend's responsibility to ensure
       no intermediate result gets spilled.  This is to avoid leaking the
       value some place that an attacker might use to rewrite the stack
       guard slot after having clobbered it.
  
       If this pattern is not defined, then the address declaration is
!      expanded first in the standard way and a 'stack_protect_test'
       pattern is then generated to compare the value from that address to
       the value at the memory in operand 0.
  
! 'stack_protect_test'
!      This pattern, if defined, compares a 'ptr_mode' value from the
       valid memory location in operand 1 with the memory in operand 0
       without leaving the value in a register afterward and branches to
       operand 2 if the values were equal.
--- 29148,29172 ----
       If this pattern is not defined, then a plain move pattern is
       generated.
  
! ‘stack_protect_combined_test’
!      This pattern, if defined, compares a ‘ptr_mode’ value from an
       address whose declaration RTX is given in operand 1 with the memory
       in operand 0 without leaving the value in a register afterward and
       branches to operand 2 if the values were equal.  If several
       instructions are needed by the target to perform the operation (eg.
!      to load the address from a GOT entry then load the ‘ptr_mode’ value
       and finally store it), it is the backend's responsibility to ensure
       no intermediate result gets spilled.  This is to avoid leaking the
       value some place that an attacker might use to rewrite the stack
       guard slot after having clobbered it.
  
       If this pattern is not defined, then the address declaration is
!      expanded first in the standard way and a ‘stack_protect_test’
       pattern is then generated to compare the value from that address to
       the value at the memory in operand 0.
  
! ‘stack_protect_test’
!      This pattern, if defined, compares a ‘ptr_mode’ value from the
       valid memory location in operand 1 with the memory in operand 0
       without leaving the value in a register afterward and branches to
       operand 2 if the values were equal.
*************** pattern to accomplish a certain task.
*** 29175,29195 ****
       If this pattern is not defined, then a plain compare pattern and
       conditional branch pattern is used.
  
! 'clear_cache'
       This pattern, if defined, flushes the instruction cache for a
       region of memory.  The region is bounded to by the Pmode pointers
       in operand 0 inclusive and operand 1 exclusive.
  
       If this pattern is not defined, a call to the library function
!      '__clear_cache' is used.
  
! 'spaceshipM3'
       Initialize output operand 0 with mode of integer type to -1, 0, 1
       or 2 if operand 1 with mode M compares less than operand 2, equal
       to operand 2, greater than operand 2 or is unordered with operand
       2.  M should be a scalar floating point mode.
  
!      This pattern is not allowed to 'FAIL'.
  
  
  File: gccint.info,  Node: Pattern Ordering,  Next: Dependent Patterns,  Prev: Standard Names,  Up: Machine Desc
--- 29174,29194 ----
       If this pattern is not defined, then a plain compare pattern and
       conditional branch pattern is used.
  
! ‘clear_cache’
       This pattern, if defined, flushes the instruction cache for a
       region of memory.  The region is bounded to by the Pmode pointers
       in operand 0 inclusive and operand 1 exclusive.
  
       If this pattern is not defined, a call to the library function
!      ‘__clear_cache’ is used.
  
! ‘spaceshipM3’
       Initialize output operand 0 with mode of integer type to -1, 0, 1
       or 2 if operand 1 with mode M compares less than operand 2, equal
       to operand 2, greater than operand 2 or is unordered with operand
       2.  M should be a scalar floating point mode.
  
!      This pattern is not allowed to ‘FAIL’.
  
  
  File: gccint.info,  Node: Pattern Ordering,  Next: Dependent Patterns,  Prev: Standard Names,  Up: Machine Desc
*************** Constant integers do not specify a machi
*** 29235,29241 ****
  extend a constant value could match either pattern.  The pattern it
  actually will match is the one that appears first in the file.  For
  correct results, this must be the one for the widest possible mode
! ('HImode', here).  If the pattern matches the 'QImode' instruction, the
  results will be incorrect if the constant value does not actually fit
  that mode.
  
--- 29234,29240 ----
  extend a constant value could match either pattern.  The pattern it
  actually will match is the one that appears first in the file.  For
  correct results, this must be the one for the widest possible mode
! (‘HImode’, here).  If the pattern matches the ‘QImode’ instruction, the
  results will be incorrect if the constant value does not actually fit
  that mode.
  
*************** File: gccint.info,  Node: Jump Patterns,
*** 29259,29271 ****
  
  GCC does not assume anything about how the machine realizes jumps.  The
  machine description should define a single pattern, usually a
! 'define_expand', which expands to all the required insns.
  
   Usually, this would be a comparison insn to set the condition code and
  a separate branch insn testing the condition code and branching or not
  according to its value.  For many machines, however, separating compares
  and branches is limiting, which is why the more flexible approach with
! one 'define_expand' is used in GCC. The machine description becomes
  clearer for architectures that have compare-and-branch instructions but
  no condition code.  It also works better when different sets of
  comparison operators are supported by different kinds of conditional
--- 29258,29270 ----
  
  GCC does not assume anything about how the machine realizes jumps.  The
  machine description should define a single pattern, usually a
! ‘define_expand’, which expands to all the required insns.
  
   Usually, this would be a comparison insn to set the condition code and
  a separate branch insn testing the condition code and branching or not
  according to its value.  For many machines, however, separating compares
  and branches is limiting, which is why the more flexible approach with
! one ‘define_expand’ is used in GCC. The machine description becomes
  clearer for architectures that have compare-and-branch instructions but
  no condition code.  It also works better when different sets of
  comparison operators are supported by different kinds of conditional
*************** File: gccint.info,  Node: Looping Patter
*** 29290,29296 ****
  ===========================================
  
  Some machines have special jump instructions that can be utilized to
! make loops more efficient.  A common example is the 68000 'dbra'
  instruction which performs a decrement of a register and a branch if the
  result was greater than zero.  Other machines, in particular digital
  signal processors (DSPs), have special block repeat instructions to
--- 29289,29295 ----
  ===========================================
  
  Some machines have special jump instructions that can be utilized to
! make loops more efficient.  A common example is the 68000 ‘dbra’
  instruction which performs a decrement of a register and a branch if the
  result was greater than zero.  Other machines, in particular digital
  signal processors (DSPs), have special block repeat instructions to
*************** provide low-overhead loop support.  For
*** 29298,29322 ****
  DSPs have a block repeat instruction that loads special registers to
  mark the top and end of a loop and to count the number of loop
  iterations.  This avoids the need for fetching and executing a
! 'dbra'-like instruction and avoids pipeline stalls associated with the
  jump.
  
   GCC has two special named patterns to support low overhead looping.
! They are 'doloop_begin' and 'doloop_end'.  These are emitted by the loop
  optimizer for certain well-behaved loops with a finite number of loop
  iterations using information collected during strength reduction.
  
!  The 'doloop_end' pattern describes the actual looping instruction (or
! the implicit looping operation) and the 'doloop_begin' pattern is an
  optional companion pattern that can be used for initialization needed
  for some low-overhead looping instructions.
  
   Note that some machines require the actual looping instruction to be
  emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs).  Emitting
  the true RTL for a looping instruction at the top of the loop can cause
! problems with flow analysis.  So instead, a dummy 'doloop' insn is
  emitted at the end of the loop.  The machine dependent reorg pass checks
! for the presence of this 'doloop' insn and then searches back to the top
  of the loop, where it inserts the true looping insn (provided there are
  no instructions in the loop which would cause problems).  Any additional
  labels can be emitted at this point.  In addition, if the desired
--- 29297,29321 ----
  DSPs have a block repeat instruction that loads special registers to
  mark the top and end of a loop and to count the number of loop
  iterations.  This avoids the need for fetching and executing a
! ‘dbra’-like instruction and avoids pipeline stalls associated with the
  jump.
  
   GCC has two special named patterns to support low overhead looping.
! They are ‘doloop_begin’ and ‘doloop_end’.  These are emitted by the loop
  optimizer for certain well-behaved loops with a finite number of loop
  iterations using information collected during strength reduction.
  
!  The ‘doloop_end’ pattern describes the actual looping instruction (or
! the implicit looping operation) and the ‘doloop_begin’ pattern is an
  optional companion pattern that can be used for initialization needed
  for some low-overhead looping instructions.
  
   Note that some machines require the actual looping instruction to be
  emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs).  Emitting
  the true RTL for a looping instruction at the top of the loop can cause
! problems with flow analysis.  So instead, a dummy ‘doloop’ insn is
  emitted at the end of the loop.  The machine dependent reorg pass checks
! for the presence of this ‘doloop’ insn and then searches back to the top
  of the loop, where it inserts the true looping insn (provided there are
  no instructions in the loop which would cause problems).  Any additional
  labels can be emitted at this point.  In addition, if the desired
*************** special iteration counter register was n
*** 29324,29336 ****
  dependent reorg pass could emit a traditional compare and jump
  instruction pair.
  
!  For the 'doloop_end' pattern, the loop optimizer allocates an
  additional pseudo register as an iteration counter.  This pseudo
  register cannot be used within the loop (i.e., general induction
  variables cannot be derived from it), however, in many cases the loop
  induction variable may become redundant and removed by the flow pass.
  
!  The 'doloop_end' pattern must have a specific structure to be handled
  correctly by GCC. The example below is taken (slightly simplified) from
  the PDP-11 target:
  
--- 29323,29335 ----
  dependent reorg pass could emit a traditional compare and jump
  instruction pair.
  
!  For the ‘doloop_end’ pattern, the loop optimizer allocates an
  additional pseudo register as an iteration counter.  This pseudo
  register cannot be used within the loop (i.e., general induction
  variables cannot be derived from it), however, in many cases the loop
  induction variable may become redundant and removed by the flow pass.
  
!  The ‘doloop_end’ pattern must have a specific structure to be handled
  correctly by GCC. The example below is taken (slightly simplified) from
  the PDP-11 target:
  
*************** the PDP-11 target:
*** 29374,29407 ****
   The first part of the pattern describes the branch condition.  GCC
  supports three cases for the way the target machine handles the loop
  counter:
!    * Loop terminates when the loop register decrements to zero.  This is
!      represented by a 'ne' comparison of the register (its old value)
       with constant 1 (as in the example above).
!    * Loop terminates when the loop register decrements to -1.  This is
!      represented by a 'ne' comparison of the register with constant
       zero.
!    * Loop terminates when the loop register decrements to a negative
!      value.  This is represented by a 'ge' comparison of the register
!      with constant zero.  For this case, GCC will attach a 'REG_NONNEG'
!      note to the 'doloop_end' insn if it can determine that the register
       will be non-negative.
  
!  Since the 'doloop_end' insn is a jump insn that also has an output, the
  reload pass does not handle the output operand.  Therefore, the
  constraint must allow for that operand to be in memory rather than a
  register.  In the example shown above, that is handled (in the
! 'doloop_end_insn' pattern) by using a loop instruction sequence that can
  handle memory operands when the memory alternative appears.
  
   GCC does not check the mode of the loop register operand when
! generating the 'doloop_end' pattern.  If the pattern is only valid for
! some modes but not others, the pattern should be a 'define_expand'
  pattern that checks the operand mode in the preparation code, and issues
! 'FAIL' if an unsupported mode is found.  The example above does this,
! since the machine instruction to be used only exists for 'HImode'.
  
!  If the 'doloop_end' pattern is a 'define_expand', there must also be a
! 'define_insn' or 'define_insn_and_split' matching the generated pattern.
  Otherwise, the compiler will fail during loop optimization.
  
  
--- 29373,29406 ----
   The first part of the pattern describes the branch condition.  GCC
  supports three cases for the way the target machine handles the loop
  counter:
!    • Loop terminates when the loop register decrements to zero.  This is
!      represented by a ‘ne’ comparison of the register (its old value)
       with constant 1 (as in the example above).
!    • Loop terminates when the loop register decrements to −1.  This is
!      represented by a ‘ne’ comparison of the register with constant
       zero.
!    • Loop terminates when the loop register decrements to a negative
!      value.  This is represented by a ‘ge’ comparison of the register
!      with constant zero.  For this case, GCC will attach a ‘REG_NONNEG’
!      note to the ‘doloop_end’ insn if it can determine that the register
       will be non-negative.
  
!  Since the ‘doloop_end’ insn is a jump insn that also has an output, the
  reload pass does not handle the output operand.  Therefore, the
  constraint must allow for that operand to be in memory rather than a
  register.  In the example shown above, that is handled (in the
! ‘doloop_end_insn’ pattern) by using a loop instruction sequence that can
  handle memory operands when the memory alternative appears.
  
   GCC does not check the mode of the loop register operand when
! generating the ‘doloop_end’ pattern.  If the pattern is only valid for
! some modes but not others, the pattern should be a ‘define_expand’
  pattern that checks the operand mode in the preparation code, and issues
! ‘FAIL’ if an unsupported mode is found.  The example above does this,
! since the machine instruction to be used only exists for ‘HImode’.
  
!  If the ‘doloop_end’ pattern is a ‘define_expand’, there must also be a
! ‘define_insn’ or ‘define_insn_and_split’ matching the generated pattern.
  Otherwise, the compiler will fail during loop optimization.
  
  
*************** number of insn patterns required.
*** 29420,29451 ****
   In addition to algebraic simplifications, following canonicalizations
  are performed:
  
!    * For commutative and comparison operators, a constant is always made
       the second operand.  If a machine only supports a constant as the
       second operand, only patterns that match a constant in the second
       operand need be supplied.
  
!    * For associative operators, a sequence of operators will always
       chain to the left; for instance, only the left operand of an
!      integer 'plus' can itself be a 'plus'.  'and', 'ior', 'xor',
!      'plus', 'mult', 'smin', 'smax', 'umin', and 'umax' are associative
       when applied to integers, and sometimes to floating-point.
  
!    * For these operators, if only one operand is a 'neg', 'not', 'mult',
!      'plus', or 'minus' expression, it will be the first operand.
  
!    * In combinations of 'neg', 'mult', 'plus', and 'minus', the 'neg'
       operations (if any) will be moved inside the operations as far as
!      possible.  For instance, '(neg (mult A B))' is canonicalized as
!      '(mult (neg A) B)', but '(plus (mult (neg B) C) A)' is
!      canonicalized as '(minus A (mult B C))'.
  
!    * For the 'compare' operator, a constant is always the second operand
       if the first argument is a condition code register.
  
!    * For instructions that inherently set a condition code register, the
!      'compare' operator is always written as the first RTL expression of
!      the 'parallel' instruction pattern.  For example,
  
            (define_insn ""
              [(set (reg:CCZ FLAGS_REG)
--- 29419,29450 ----
   In addition to algebraic simplifications, following canonicalizations
  are performed:
  
!    • For commutative and comparison operators, a constant is always made
       the second operand.  If a machine only supports a constant as the
       second operand, only patterns that match a constant in the second
       operand need be supplied.
  
!    • For associative operators, a sequence of operators will always
       chain to the left; for instance, only the left operand of an
!      integer ‘plus’ can itself be a ‘plus’.  ‘and’, ‘ior’, ‘xor’,
!      ‘plus’, ‘mult’, ‘smin’, ‘smax’, ‘umin’, and ‘umax’ are associative
       when applied to integers, and sometimes to floating-point.
  
!    • For these operators, if only one operand is a ‘neg’, ‘not’, ‘mult’,
!      ‘plus’, or ‘minus’ expression, it will be the first operand.
  
!    • In combinations of ‘neg’, ‘mult’, ‘plus’, and ‘minus’, the ‘neg’
       operations (if any) will be moved inside the operations as far as
!      possible.  For instance, ‘(neg (mult A B))’ is canonicalized as
!      ‘(mult (neg A) B)’, but ‘(plus (mult (neg B) C) A)’ is
!      canonicalized as ‘(minus A (mult B C))’.
  
!    • For the ‘compare’ operator, a constant is always the second operand
       if the first argument is a condition code register.
  
!    • For instructions that inherently set a condition code register, the
!      ‘compare’ operator is always written as the first RTL expression of
!      the ‘parallel’ instruction pattern.  For example,
  
            (define_insn ""
              [(set (reg:CCZ FLAGS_REG)
*************** are performed:
*** 29459,29479 ****
              ""
              "addl %0, %1, %2")
  
!    * An operand of 'neg', 'not', 'mult', 'plus', or 'minus' is made the
       first operand under the same conditions as above.
  
!    * '(ltu (plus A B) B)' is converted to '(ltu (plus A B) A)'.
!      Likewise with 'geu' instead of 'ltu'.
  
!    * '(minus X (const_int N))' is converted to '(plus X (const_int
!      -N))'.
  
!    * Within address computations (i.e., inside 'mem'), a left shift is
       converted into the appropriate multiplication by a power of two.
  
!    * De Morgan's Law is used to move bitwise negation inside a bitwise
       logical-and or logical-or operation.  If this results in only one
!      operand being a 'not' expression, it will be the first one.
  
       A machine that has an instruction that performs a bitwise
       logical-and of one operand with the bitwise negation of the other
--- 29458,29478 ----
              ""
              "addl %0, %1, %2")
  
!    • An operand of ‘neg’, ‘not’, ‘mult’, ‘plus’, or ‘minus’ is made the
       first operand under the same conditions as above.
  
!    • ‘(ltu (plus A B) B)’ is converted to ‘(ltu (plus A B) A)’.
!      Likewise with ‘geu’ instead of ‘ltu’.
  
!    • ‘(minus X (const_int N))’ is converted to ‘(plus X (const_int
!      -N))’.
  
!    • Within address computations (i.e., inside ‘mem’), a left shift is
       converted into the appropriate multiplication by a power of two.
  
!    • De Morgan's Law is used to move bitwise negation inside a bitwise
       logical-and or logical-or operation.  If this results in only one
!      operand being a ‘not’ expression, it will be the first one.
  
       A machine that has an instruction that performs a bitwise
       logical-and of one operand with the bitwise negation of the other
*************** are performed:
*** 29498,29530 ****
       In both cases, it is not necessary to include patterns for the many
       logically equivalent RTL expressions.
  
!    * The only possible RTL expressions involving both bitwise
!      exclusive-or and bitwise negation are '(xor:M X Y)' and '(not:M
!      (xor:M X Y))'.
  
!    * The sum of three items, one of which is a constant, will only
       appear in the form
  
            (plus:M (plus:M X Y) CONSTANT)
  
!    * Equality comparisons of a group of bits (usually a single bit) with
!      zero will be written using 'zero_extract' rather than the
!      equivalent 'and' or 'sign_extract' operations.
  
!    * '(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))'
!      is converted to '(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))',
!      and likewise for 'zero_extend'.
  
!    * '(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))'
!      is converted to '(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S))
!      (sign_extend:M1 Y))', and likewise for patterns using 'zero_extend'
!      and 'lshiftrt'.  If the second operand of 'mult' is also a shift,
       then that is extended also.  This transformation is only applied
       when it can be proven that the original operation had sufficient
       precision to prevent overflow.
  
   Further canonicalization rules are defined in the function
! 'commutative_operand_precedence' in 'gcc/rtlanal.cc'.
  
  
  File: gccint.info,  Node: Expander Definitions,  Next: Insn Splitting,  Prev: Insn Canonicalizations,  Up: Machine Desc
--- 29497,29529 ----
       In both cases, it is not necessary to include patterns for the many
       logically equivalent RTL expressions.
  
!    • The only possible RTL expressions involving both bitwise
!      exclusive-or and bitwise negation are ‘(xor:M X Y)’ and ‘(not:M
!      (xor:M X Y))’.
  
!    • The sum of three items, one of which is a constant, will only
       appear in the form
  
            (plus:M (plus:M X Y) CONSTANT)
  
!    • Equality comparisons of a group of bits (usually a single bit) with
!      zero will be written using ‘zero_extract’ rather than the
!      equivalent ‘and’ or ‘sign_extract’ operations.
  
!    • ‘(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))’
!      is converted to ‘(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))’,
!      and likewise for ‘zero_extend’.
  
!    • ‘(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))’
!      is converted to ‘(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S))
!      (sign_extend:M1 Y))’, and likewise for patterns using ‘zero_extend’
!      and ‘lshiftrt’.  If the second operand of ‘mult’ is also a shift,
       then that is extended also.  This transformation is only applied
       when it can be proven that the original operation had sufficient
       precision to prevent overflow.
  
   Further canonicalization rules are defined in the function
! ‘commutative_operand_precedence’ in ‘gcc/rtlanal.cc’.
  
  
  File: gccint.info,  Node: Expander Definitions,  Next: Insn Splitting,  Prev: Insn Canonicalizations,  Up: Machine Desc
*************** File: gccint.info,  Node: Expander Defin
*** 29535,29579 ****
  On some target machines, some standard pattern names for RTL generation
  cannot be handled with single insn, but a sequence of RTL insns can
  represent them.  For these target machines, you can write a
! 'define_expand' to specify how to generate the sequence of RTL.
  
!  A 'define_expand' is an RTL expression that looks almost like a
! 'define_insn'; but, unlike the latter, a 'define_expand' is used only
  for RTL generation and it can produce more than one RTL insn.
  
!  A 'define_expand' RTX has four operands:
  
!    * The name.  Each 'define_expand' must have a name, since the only
       use for it is to refer to it by name.
  
!    * The RTL template.  This is a vector of RTL expressions representing
!      a sequence of separate instructions.  Unlike 'define_insn', there
!      is no implicit surrounding 'PARALLEL'.
  
!    * The condition, a string containing a C expression.  This expression
       is used to express how the availability of this pattern depends on
       subclasses of target machine, selected by command-line options when
!      GCC is run.  This is just like the condition of a 'define_insn'
       that has a standard name.  Therefore, the condition (if present)
       may not depend on the data in the insn being matched, but only the
       target-machine-type flags.  The compiler needs to test these
       conditions during initialization in order to learn exactly which
       named instructions are available in a particular run.
  
!    * The preparation statements, a string containing zero or more C
       statements which are to be executed before RTL code is generated
       from the RTL template.
  
       Usually these statements prepare temporary registers for use as
       internal operands in the RTL template, but they can also generate
!      RTL insns directly by calling routines such as 'emit_insn', etc.
       Any such insns precede the ones that come from the RTL template.
  
!    * Optionally, a vector containing the values of attributes.  *Note
       Insn Attributes::.
  
!  Every RTL insn emitted by a 'define_expand' must match some
! 'define_insn' in the machine description.  Otherwise, the compiler will
  crash when trying to generate code for the insn or trying to optimize
  it.
  
--- 29534,29578 ----
  On some target machines, some standard pattern names for RTL generation
  cannot be handled with single insn, but a sequence of RTL insns can
  represent them.  For these target machines, you can write a
! ‘define_expand’ to specify how to generate the sequence of RTL.
  
!  A ‘define_expand’ is an RTL expression that looks almost like a
! ‘define_insn’; but, unlike the latter, a ‘define_expand’ is used only
  for RTL generation and it can produce more than one RTL insn.
  
!  A ‘define_expand’ RTX has four operands:
  
!    • The name.  Each ‘define_expand’ must have a name, since the only
       use for it is to refer to it by name.
  
!    • The RTL template.  This is a vector of RTL expressions representing
!      a sequence of separate instructions.  Unlike ‘define_insn’, there
!      is no implicit surrounding ‘PARALLEL’.
  
!    • The condition, a string containing a C expression.  This expression
       is used to express how the availability of this pattern depends on
       subclasses of target machine, selected by command-line options when
!      GCC is run.  This is just like the condition of a ‘define_insn’
       that has a standard name.  Therefore, the condition (if present)
       may not depend on the data in the insn being matched, but only the
       target-machine-type flags.  The compiler needs to test these
       conditions during initialization in order to learn exactly which
       named instructions are available in a particular run.
  
!    • The preparation statements, a string containing zero or more C
       statements which are to be executed before RTL code is generated
       from the RTL template.
  
       Usually these statements prepare temporary registers for use as
       internal operands in the RTL template, but they can also generate
!      RTL insns directly by calling routines such as ‘emit_insn’, etc.
       Any such insns precede the ones that come from the RTL template.
  
!    • Optionally, a vector containing the values of attributes.  *Note
       Insn Attributes::.
  
!  Every RTL insn emitted by a ‘define_expand’ must match some
! ‘define_insn’ in the machine description.  Otherwise, the compiler will
  crash when trying to generate code for the insn or trying to optimize
  it.
  
*************** also describes the operands that need to
*** 29582,29631 ****
  is used.  In particular, it gives a predicate for each operand.
  
   A true operand, which needs to be specified in order to generate RTL
! from the pattern, should be described with a 'match_operand' in its
  first occurrence in the RTL template.  This enters information on the
  operand's predicate into the tables that record such things.  GCC uses
  the information to preload the operand into a register if that is
  required for valid RTL code.  If the operand is referred to more than
! once, subsequent references should use 'match_dup'.
  
   The RTL template may also refer to internal "operands" which are
  temporary registers or labels used only within the sequence made by the
! 'define_expand'.  Internal operands are substituted into the RTL
! template with 'match_dup', never with 'match_operand'.  The values of
  the internal operands are not passed in as arguments by the compiler
  when it requests use of this pattern.  Instead, they are computed within
  the pattern, in the preparation statements.  These statements compute
! the values and store them into the appropriate elements of 'operands' so
! that 'match_dup' can find them.
  
   There are two special macros defined for use in the preparation
! statements: 'DONE' and 'FAIL'.  Use them with a following semicolon, as
  a statement.
  
! 'DONE'
!      Use the 'DONE' macro to end RTL generation for the pattern.  The
       only RTL insns resulting from the pattern on this occasion will be
!      those already emitted by explicit calls to 'emit_insn' within the
       preparation statements; the RTL template will not be generated.
  
! 'FAIL'
       Make the pattern fail on this occasion.  When a pattern fails, it
       means that the pattern was not truly available.  The calling
       routines in the compiler will try other strategies for code
       generation using other patterns.
  
       Failure is currently supported only for binary (addition,
!      multiplication, shifting, etc.)  and bit-field ('extv', 'extzv',
!      and 'insv') operations.
  
!  If the preparation falls through (invokes neither 'DONE' nor 'FAIL'),
! then the 'define_expand' acts like a 'define_insn' in that the RTL
  template is used to generate the insn.
  
   The RTL template is not used for matching, only for generating the
! initial insn list.  If the preparation statement always invokes 'DONE'
! or 'FAIL', the RTL template may be reduced to a simple list of operands,
  such as this example:
  
       (define_expand "addsi3"
--- 29581,29630 ----
  is used.  In particular, it gives a predicate for each operand.
  
   A true operand, which needs to be specified in order to generate RTL
! from the pattern, should be described with a ‘match_operand’ in its
  first occurrence in the RTL template.  This enters information on the
  operand's predicate into the tables that record such things.  GCC uses
  the information to preload the operand into a register if that is
  required for valid RTL code.  If the operand is referred to more than
! once, subsequent references should use ‘match_dup’.
  
   The RTL template may also refer to internal "operands" which are
  temporary registers or labels used only within the sequence made by the
! ‘define_expand’.  Internal operands are substituted into the RTL
! template with ‘match_dup’, never with ‘match_operand’.  The values of
  the internal operands are not passed in as arguments by the compiler
  when it requests use of this pattern.  Instead, they are computed within
  the pattern, in the preparation statements.  These statements compute
! the values and store them into the appropriate elements of ‘operands’ so
! that ‘match_dup’ can find them.
  
   There are two special macros defined for use in the preparation
! statements: ‘DONE’ and ‘FAIL’.  Use them with a following semicolon, as
  a statement.
  
! ‘DONE’
!      Use the ‘DONE’ macro to end RTL generation for the pattern.  The
       only RTL insns resulting from the pattern on this occasion will be
!      those already emitted by explicit calls to ‘emit_insn’ within the
       preparation statements; the RTL template will not be generated.
  
! ‘FAIL’
       Make the pattern fail on this occasion.  When a pattern fails, it
       means that the pattern was not truly available.  The calling
       routines in the compiler will try other strategies for code
       generation using other patterns.
  
       Failure is currently supported only for binary (addition,
!      multiplication, shifting, etc.)  and bit-field (‘extv’, ‘extzv’,
!      and ‘insv’) operations.
  
!  If the preparation falls through (invokes neither ‘DONE’ nor ‘FAIL’),
! then the ‘define_expand’ acts like a ‘define_insn’ in that the RTL
  template is used to generate the insn.
  
   The RTL template is not used for matching, only for generating the
! initial insn list.  If the preparation statement always invokes ‘DONE’
! or ‘FAIL’, the RTL template may be reduced to a simple list of operands,
  such as this example:
  
       (define_expand "addsi3"
*************** such as this example:
*** 29654,29669 ****
           FAIL;
       }")
  
! This example uses 'define_expand' so that it can generate an RTL insn
  for shifting when the shift-count is in the supported range of 0 to 3
  but fail in other cases where machine insns aren't available.  When it
  fails, the compiler tries another strategy using different patterns
  (such as, a library call).
  
   If the compiler were able to handle nontrivial condition-strings in
! patterns with names, then it would be possible to use a 'define_insn' in
  that case.  Here is another case (zero-extension on the 68000) which
! makes more use of the power of 'define_expand':
  
       (define_expand "zero_extendhisi2"
         [(set (match_operand:SI 0 "general_operand" "")
--- 29653,29668 ----
           FAIL;
       }")
  
! This example uses ‘define_expand’ so that it can generate an RTL insn
  for shifting when the shift-count is in the supported range of 0 to 3
  but fail in other cases where machine insns aren't available.  When it
  fails, the compiler tries another strategy using different patterns
  (such as, a library call).
  
   If the compiler were able to handle nontrivial condition-strings in
! patterns with names, then it would be possible to use a ‘define_insn’ in
  that case.  Here is another case (zero-extension on the 68000) which
! makes more use of the power of ‘define_expand’:
  
       (define_expand "zero_extendhisi2"
         [(set (match_operand:SI 0 "general_operand" "")
*************** Here two RTL insns are generated, one to
*** 29680,29695 ****
  and the other to copy the input operand into its low half.  This
  sequence is incorrect if the input operand refers to [the old value of]
  the output operand, so the preparation statement makes sure this isn't
! so.  The function 'make_safe_from' copies the 'operands[1]' into a
! temporary register if it refers to 'operands[0]'.  It does this by
  emitting another RTL insn.
  
   Finally, a third example shows the use of an internal operand.
! Zero-extension on the SPUR chip is done by 'and'-ing the result against
! a halfword mask.  But this mask cannot be represented by a 'const_int'
  because the constant value is too large to be legitimate on this
! machine.  So it must be copied into a register with 'force_reg' and then
! the register used in the 'and'.
  
       (define_expand "zero_extendhisi2"
         [(set (match_operand:SI 0 "register_operand" "")
--- 29679,29694 ----
  and the other to copy the input operand into its low half.  This
  sequence is incorrect if the input operand refers to [the old value of]
  the output operand, so the preparation statement makes sure this isn't
! so.  The function ‘make_safe_from’ copies the ‘operands[1]’ into a
! temporary register if it refers to ‘operands[0]’.  It does this by
  emitting another RTL insn.
  
   Finally, a third example shows the use of an internal operand.
! Zero-extension on the SPUR chip is done by ‘and’-ing the result against
! a halfword mask.  But this mask cannot be represented by a ‘const_int’
  because the constant value is too large to be legitimate on this
! machine.  So it must be copied into a register with ‘force_reg’ and then
! the register used in the ‘and’.
  
       (define_expand "zero_extendhisi2"
         [(set (match_operand:SI 0 "register_operand" "")
*************** the register used in the 'and'.
*** 29701,29710 ****
         "operands[2]
            = force_reg (SImode, GEN_INT (65535)); ")
  
!  _Note:_ If the 'define_expand' is used to serve a standard binary or
  unary arithmetic operation or a bit-field operation, then the last insn
! it generates must not be a 'code_label', 'barrier' or 'note'.  It must
! be an 'insn', 'jump_insn' or 'call_insn'.  If you don't need a real insn
  at the end, emit an insn to copy the result of the operation into
  itself.  Such an insn will generate no code, but it can avoid problems
  in the compiler.
--- 29700,29709 ----
         "operands[2]
            = force_reg (SImode, GEN_INT (65535)); ")
  
!  _Note:_ If the ‘define_expand’ is used to serve a standard binary or
  unary arithmetic operation or a bit-field operation, then the last insn
! it generates must not be a ‘code_label’, ‘barrier’ or ‘note’.  It must
! be an ‘insn’, ‘jump_insn’ or ‘call_insn’.  If you don't need a real insn
  at the end, emit an insn to copy the result of the operation into
  itself.  Such an insn will generate no code, but it can avoid problems
  in the compiler.
*************** scheduling.
*** 29734,29747 ****
  
   The insn combiner phase also splits putative insns.  If three insns are
  merged into one insn with a complex expression that cannot be matched by
! some 'define_insn' pattern, the combiner phase attempts to split the
  complex pattern into two insns that are recognized.  Usually it can
  break the complex pattern into two patterns by splitting out some
  subexpression.  However, in some other cases, such as performing an
  addition of a large constant in two insns on a RISC machine, the way to
  split the addition into two insns is machine-dependent.
  
!  The 'define_split' definition tells the compiler how to split a complex
  insn into several simpler insns.  It looks like this:
  
       (define_split
--- 29733,29746 ----
  
   The insn combiner phase also splits putative insns.  If three insns are
  merged into one insn with a complex expression that cannot be matched by
! some ‘define_insn’ pattern, the combiner phase attempts to split the
  complex pattern into two insns that are recognized.  Usually it can
  break the complex pattern into two patterns by splitting out some
  subexpression.  However, in some other cases, such as performing an
  addition of a large constant in two insns on a RISC machine, the way to
  split the addition into two insns is machine-dependent.
  
!  The ‘define_split’ definition tells the compiler how to split a complex
  insn into several simpler insns.  It looks like this:
  
       (define_split
*************** insn into several simpler insns.  It loo
*** 29753,29803 ****
         "PREPARATION-STATEMENTS")
  
   INSN-PATTERN is a pattern that needs to be split and CONDITION is the
! final condition to be tested, as in a 'define_insn'.  When an insn
  matching INSN-PATTERN and satisfying CONDITION is found, it is replaced
  in the insn list with the insns given by NEW-INSN-PATTERN-1,
  NEW-INSN-PATTERN-2, etc.
  
   The PREPARATION-STATEMENTS are similar to those statements that are
! specified for 'define_expand' (*note Expander Definitions::) and are
  executed before the new RTL is generated to prepare for the generated
  code or emit some insns whose pattern is not fixed.  Unlike those in
! 'define_expand', however, these statements must not generate any new
  pseudo-registers.  Once reload has completed, they also must not
  allocate any space in the stack frame.
  
   There are two special macros defined for use in the preparation
! statements: 'DONE' and 'FAIL'.  Use them with a following semicolon, as
  a statement.
  
! 'DONE'
!      Use the 'DONE' macro to end RTL generation for the splitter.  The
       only RTL insns generated as replacement for the matched input insn
!      will be those already emitted by explicit calls to 'emit_insn'
       within the preparation statements; the replacement pattern is not
       used.
  
! 'FAIL'
!      Make the 'define_split' fail on this occasion.  When a
!      'define_split' fails, it means that the splitter was not truly
       available for the inputs it was given, and the input insn will not
       be split.
  
!  If the preparation falls through (invokes neither 'DONE' nor 'FAIL'),
! then the 'define_split' uses the replacement template.
  
   Patterns are matched against INSN-PATTERN in two different
  circumstances.  If an insn needs to be split for delay slot scheduling
  or insn scheduling, the insn is already known to be valid, which means
! that it must have been matched by some 'define_insn' and, if
! 'reload_completed' is nonzero, is known to satisfy the constraints of
! that 'define_insn'.  In that case, the new insn patterns must also be
! insns that are matched by some 'define_insn' and, if 'reload_completed'
  is nonzero, must also satisfy the constraints of those definitions.
  
!  As an example of this usage of 'define_split', consider the following
! example from 'a29k.md', which splits a 'sign_extend' from 'HImode' to
! 'SImode' into a pair of shift insns:
  
       (define_split
         [(set (match_operand:SI 0 "gen_reg_operand" "")
--- 29752,29802 ----
         "PREPARATION-STATEMENTS")
  
   INSN-PATTERN is a pattern that needs to be split and CONDITION is the
! final condition to be tested, as in a ‘define_insn’.  When an insn
  matching INSN-PATTERN and satisfying CONDITION is found, it is replaced
  in the insn list with the insns given by NEW-INSN-PATTERN-1,
  NEW-INSN-PATTERN-2, etc.
  
   The PREPARATION-STATEMENTS are similar to those statements that are
! specified for ‘define_expand’ (*note Expander Definitions::) and are
  executed before the new RTL is generated to prepare for the generated
  code or emit some insns whose pattern is not fixed.  Unlike those in
! ‘define_expand’, however, these statements must not generate any new
  pseudo-registers.  Once reload has completed, they also must not
  allocate any space in the stack frame.
  
   There are two special macros defined for use in the preparation
! statements: ‘DONE’ and ‘FAIL’.  Use them with a following semicolon, as
  a statement.
  
! ‘DONE’
!      Use the ‘DONE’ macro to end RTL generation for the splitter.  The
       only RTL insns generated as replacement for the matched input insn
!      will be those already emitted by explicit calls to ‘emit_insn’
       within the preparation statements; the replacement pattern is not
       used.
  
! ‘FAIL’
!      Make the ‘define_split’ fail on this occasion.  When a
!      ‘define_split’ fails, it means that the splitter was not truly
       available for the inputs it was given, and the input insn will not
       be split.
  
!  If the preparation falls through (invokes neither ‘DONE’ nor ‘FAIL’),
! then the ‘define_split’ uses the replacement template.
  
   Patterns are matched against INSN-PATTERN in two different
  circumstances.  If an insn needs to be split for delay slot scheduling
  or insn scheduling, the insn is already known to be valid, which means
! that it must have been matched by some ‘define_insn’ and, if
! ‘reload_completed’ is nonzero, is known to satisfy the constraints of
! that ‘define_insn’.  In that case, the new insn patterns must also be
! insns that are matched by some ‘define_insn’ and, if ‘reload_completed’
  is nonzero, must also satisfy the constraints of those definitions.
  
!  As an example of this usage of ‘define_split’, consider the following
! example from ‘a29k.md’, which splits a ‘sign_extend’ from ‘HImode’ to
! ‘SImode’ into a pair of shift insns:
  
       (define_split
         [(set (match_operand:SI 0 "gen_reg_operand" "")
*************** example from 'a29k.md', which splits a '
*** 29813,29830 ****
       { operands[1] = gen_lowpart (SImode, operands[1]); }")
  
   When the combiner phase tries to split an insn pattern, it is always
! the case that the pattern is _not_ matched by any 'define_insn'.  The
! combiner pass first tries to split a single 'set' expression and then
! the same 'set' expression inside a 'parallel', but followed by a
! 'clobber' of a pseudo-reg to use as a scratch register.  In these cases,
  the combiner expects exactly one or two new insn patterns to be
! generated.  It will verify that these patterns match some 'define_insn'
! definitions, so you need not do this test in the 'define_split' (of
! course, there is no point in writing a 'define_split' that will never
  produce insns that match).
  
!  Here is an example of this use of 'define_split', taken from
! 'rs6000.md':
  
       (define_split
         [(set (match_operand:SI 0 "gen_reg_operand" "")
--- 29812,29829 ----
       { operands[1] = gen_lowpart (SImode, operands[1]); }")
  
   When the combiner phase tries to split an insn pattern, it is always
! the case that the pattern is _not_ matched by any ‘define_insn’.  The
! combiner pass first tries to split a single ‘set’ expression and then
! the same ‘set’ expression inside a ‘parallel’, but followed by a
! ‘clobber’ of a pseudo-reg to use as a scratch register.  In these cases,
  the combiner expects exactly one or two new insn patterns to be
! generated.  It will verify that these patterns match some ‘define_insn’
! definitions, so you need not do this test in the ‘define_split’ (of
! course, there is no point in writing a ‘define_split’ that will never
  produce insns that match).
  
!  Here is an example of this use of ‘define_split’, taken from
! ‘rs6000.md’:
  
       (define_split
         [(set (match_operand:SI 0 "gen_reg_operand" "")
*************** produce insns that match).
*** 29845,29851 ****
         operands[4] = GEN_INT (low);
       }")
  
!  Here the predicate 'non_add_cint_operand' matches any 'const_int' that
  is _not_ a valid operand of a single add insn.  The add with the smaller
  displacement is written so that it can be substituted into the address
  of a subsequent operation.
--- 29844,29850 ----
         operands[4] = GEN_INT (low);
       }")
  
!  Here the predicate ‘non_add_cint_operand’ matches any ‘const_int’ that
  is _not_ a valid operand of a single add insn.  The add with the smaller
  displacement is written so that it can be substituted into the address
  of a subsequent operation.
*************** an equality comparison of a register and
*** 29877,29885 ****
         operands[5] = GEN_INT (sextc);
       }")
  
!  To avoid confusion, don't write a single 'define_split' that accepts
! some insns that match some 'define_insn' as well as some insns that
! don't.  Instead, write two separate 'define_split' definitions, one for
  the insns that are valid and one for the insns that are not valid.
  
   The splitter is allowed to split jump instructions into a sequence of
--- 29876,29884 ----
         operands[5] = GEN_INT (sextc);
       }")
  
!  To avoid confusion, don't write a single ‘define_split’ that accepts
! some insns that match some ‘define_insn’ as well as some insns that
! don't.  Instead, write two separate ‘define_split’ definitions, one for
  the insns that are valid and one for the insns that are not valid.
  
   The splitter is allowed to split jump instructions into a sequence of
*************** identical behavior of the new jump.  Whe
*** 29893,29906 ****
  multiple jump instructions or new labels, more assistance is needed.
  The splitter is permitted to create only unconditional jumps, or simple
  conditional jump instructions.  Additionally it must attach a
! 'REG_BR_PROB' note to each conditional jump.  A global variable
! 'split_branch_probability' holds the probability of the original branch
! in case it was a simple conditional jump, -1 otherwise.  To simplify
  recomputing of edge frequencies, the new sequence is permitted to have
  only forward jumps to the newly-created labels.
  
   For the common case where the pattern of a define_split exactly matches
! the pattern of a define_insn, use 'define_insn_and_split'.  It looks
  like this:
  
       (define_insn_and_split
--- 29892,29905 ----
  multiple jump instructions or new labels, more assistance is needed.
  The splitter is permitted to create only unconditional jumps, or simple
  conditional jump instructions.  Additionally it must attach a
! ‘REG_BR_PROB’ note to each conditional jump.  A global variable
! ‘split_branch_probability’ holds the probability of the original branch
! in case it was a simple conditional jump, −1 otherwise.  To simplify
  recomputing of edge frequencies, the new sequence is permitted to have
  only forward jumps to the newly-created labels.
  
   For the common case where the pattern of a define_split exactly matches
! the pattern of a define_insn, use ‘define_insn_and_split’.  It looks
  like this:
  
       (define_insn_and_split
*************** like this:
*** 29916,29925 ****
  
  
   INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used
! as in 'define_insn'.  The NEW-INSN-PATTERN vector and the
! PREPARATION-STATEMENTS are used as in a 'define_split'.  The
! SPLIT-CONDITION is also used as in 'define_split', with the additional
! behavior that if the condition starts with '&&', the condition used for
  the split will be the constructed as a logical "and" of the split
  condition with the insn condition.  For example, from i386.md:
  
--- 29915,29924 ----
  
  
   INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used
! as in ‘define_insn’.  The NEW-INSN-PATTERN vector and the
! PREPARATION-STATEMENTS are used as in a ‘define_split’.  The
! SPLIT-CONDITION is also used as in ‘define_split’, with the additional
! behavior that if the condition starts with ‘&&’, the condition used for
  the split will be the constructed as a logical "and" of the split
  condition with the insn condition.  For example, from i386.md:
  
*************** condition with the insn condition.  For
*** 29938,29963 ****
  
  
   In this case, the actual split condition will be
! 'TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'.
  
!  The 'define_insn_and_split' construction provides exactly the same
! functionality as two separate 'define_insn' and 'define_split' patterns.
  It exists for compactness, and as a maintenance tool to prevent having
  to ensure the two patterns' templates match.
  
!  It is sometimes useful to have a 'define_insn_and_split' that replaces
  specific operands of an instruction but leaves the rest of the
  instruction pattern unchanged.  You can do this directly with a
! 'define_insn_and_split', but it requires a NEW-INSN-PATTERN-1 that
  repeats most of the original INSN-PATTERN.  There is also the
! complication that an implicit 'parallel' in INSN-PATTERN must become an
! explicit 'parallel' in NEW-INSN-PATTERN-1, which is easy to overlook.  A
! simpler alternative is to use 'define_insn_and_rewrite', which is a form
! of 'define_insn_and_split' that automatically generates
! NEW-INSN-PATTERN-1 by replacing each 'match_operand' in INSN-PATTERN
! with a corresponding 'match_dup', and each 'match_operator' in the
! pattern with a corresponding 'match_op_dup'.  The arguments are
! otherwise identical to 'define_insn_and_split':
  
       (define_insn_and_rewrite
         [INSN-PATTERN]
--- 29937,29962 ----
  
  
   In this case, the actual split condition will be
! ‘TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed’.
  
!  The ‘define_insn_and_split’ construction provides exactly the same
! functionality as two separate ‘define_insn’ and ‘define_split’ patterns.
  It exists for compactness, and as a maintenance tool to prevent having
  to ensure the two patterns' templates match.
  
!  It is sometimes useful to have a ‘define_insn_and_split’ that replaces
  specific operands of an instruction but leaves the rest of the
  instruction pattern unchanged.  You can do this directly with a
! ‘define_insn_and_split’, but it requires a NEW-INSN-PATTERN-1 that
  repeats most of the original INSN-PATTERN.  There is also the
! complication that an implicit ‘parallel’ in INSN-PATTERN must become an
! explicit ‘parallel’ in NEW-INSN-PATTERN-1, which is easy to overlook.  A
! simpler alternative is to use ‘define_insn_and_rewrite’, which is a form
! of ‘define_insn_and_split’ that automatically generates
! NEW-INSN-PATTERN-1 by replacing each ‘match_operand’ in INSN-PATTERN
! with a corresponding ‘match_dup’, and each ‘match_operator’ in the
! pattern with a corresponding ‘match_op_dup’.  The arguments are
! otherwise identical to ‘define_insn_and_split’:
  
       (define_insn_and_rewrite
         [INSN-PATTERN]
*************** otherwise identical to 'define_insn_and_
*** 29967,29983 ****
         "PREPARATION-STATEMENTS"
         [INSN-ATTRIBUTES])
  
!  The 'match_dup's and 'match_op_dup's in the new instruction pattern use
  any new operand values that the PREPARATION-STATEMENTS store in the
! 'operands' array, as for a normal 'define_insn_and_split'.
  PREPARATION-STATEMENTS can also emit additional instructions before the
  new instruction.  They can even emit an entirely different sequence of
! instructions and use 'DONE' to avoid emitting a new form of the original
  instruction.
  
!  The split in a 'define_insn_and_rewrite' is only intended to apply to
  existing instructions that match INSN-PATTERN.  SPLIT-CONDITION must
! therefore start with '&&', so that the split condition applies on top of
  CONDITION.
  
   Here is an example from the AArch64 SVE port, in which operand 1 is
--- 29966,29982 ----
         "PREPARATION-STATEMENTS"
         [INSN-ATTRIBUTES])
  
!  The ‘match_dup’s and ‘match_op_dup’s in the new instruction pattern use
  any new operand values that the PREPARATION-STATEMENTS store in the
! ‘operands’ array, as for a normal ‘define_insn_and_split’.
  PREPARATION-STATEMENTS can also emit additional instructions before the
  new instruction.  They can even emit an entirely different sequence of
! instructions and use ‘DONE’ to avoid emitting a new form of the original
  instruction.
  
!  The split in a ‘define_insn_and_rewrite’ is only intended to apply to
  existing instructions that match INSN-PATTERN.  SPLIT-CONDITION must
! therefore start with ‘&&’, so that the split condition applies on top of
  CONDITION.
  
   Here is an example from the AArch64 SVE port, in which operand 1 is
*************** output template:
*** 30009,30015 ****
       )
  
   The splitter in this case simply replaces operand 1 with the constant
! value that it is known to have.  The equivalent 'define_insn_and_split'
  would be:
  
       (define_insn_and_split "*while_ult_cc"
--- 30008,30014 ----
       )
  
   The splitter in this case simply replaces operand 1 with the constant
! value that it is known to have.  The equivalent ‘define_insn_and_split’
  would be:
  
       (define_insn_and_split "*while_ult_cc"
*************** File: gccint.info,  Node: Including Patt
*** 30055,30062 ****
  17.17 Including Patterns in Machine Descriptions.
  =================================================
  
! The 'include' pattern tells the compiler tools where to look for
! patterns that are in files other than in the file '.md'.  This is used
  only at build time and there is no preprocessing allowed.
  
   It looks like:
--- 30054,30061 ----
  17.17 Including Patterns in Machine Descriptions.
  =================================================
  
! The ‘include’ pattern tells the compiler tools where to look for
! patterns that are in files other than in the file ‘.md’.  This is used
  only at build time and there is no preprocessing allowed.
  
   It looks like:
*************** only at build time and there is no prepr
*** 30071,30078 ****
  
  
   Where PATHNAME is a string that specifies the location of the file,
! specifies the include file to be in 'gcc/config/target/filestuff'.  The
! directory 'gcc/config/target' is regarded as the default directory.
  
   Machine descriptions may be split up into smaller more manageable
  subsections and placed into subdirectories.
--- 30070,30077 ----
  
  
   Where PATHNAME is a string that specifies the location of the file,
! specifies the include file to be in ‘gcc/config/target/filestuff’.  The
! directory ‘gcc/config/target’ is regarded as the default directory.
  
   Machine descriptions may be split up into smaller more manageable
  subsections and placed into subdirectories.
*************** subsections and placed into subdirectori
*** 30084,30090 ****
  
  
   the include file is specified to be in
! 'gcc/config/TARGET/BOGUS/filestuff'.
  
   Specifying an absolute path for the include file such as;
  
--- 30083,30089 ----
  
  
   the include file is specified to be in
! ‘gcc/config/TARGET/BOGUS/filestuff’.
  
   Specifying an absolute path for the include file such as;
  
*************** subsections and placed into subdirectori
*** 30095,30101 ****
  17.17.1 RTL Generation Tool Options for Directory Search
  --------------------------------------------------------
  
! The '-IDIR' option specifies directories to search for machine
  descriptions.  For example:
  
  
--- 30094,30100 ----
  17.17.1 RTL Generation Tool Options for Directory Search
  --------------------------------------------------------
  
! The ‘-IDIR’ option specifies directories to search for machine
  descriptions.  For example:
  
  
*************** descriptions.  For example:
*** 30106,30112 ****
  searched for header files.  This can be used to override a system
  machine definition file, substituting your own version, since these
  directories are searched before the default machine description file
! directories.  If you use more than one '-I' option, the directories are
  scanned in left-to-right order; the standard default directory come
  after.
  
--- 30105,30111 ----
  searched for header files.  This can be used to override a system
  machine definition file, substituting your own version, since these
  directories are searched before the default machine description file
! directories.  If you use more than one ‘-I’ option, the directories are
  scanned in left-to-right order; the standard default directory come
  after.
  
*************** File: gccint.info,  Node: Peephole Defin
*** 30116,30122 ****
  17.18 Machine-Specific Peephole Optimizers
  ==========================================
  
! In addition to instruction patterns the 'md' file may contain
  definitions of machine-specific peephole optimizations.
  
   The combiner does not notice certain peephole optimizations when the
--- 30115,30121 ----
  17.18 Machine-Specific Peephole Optimizers
  ==========================================
  
! In addition to instruction patterns the ‘md’ file may contain
  definitions of machine-specific peephole optimizations.
  
   The combiner does not notice certain peephole optimizations when the
*************** computed in the first one.  A machine-sp
*** 30127,30137 ****
  detect such opportunities.
  
   There are two forms of peephole definitions that may be used.  The
! original 'define_peephole' is run at assembly output time to match insns
! and substitute assembly text.  Use of 'define_peephole' is deprecated.
  
!  A newer 'define_peephole2' matches insns and substitutes new insns.
! The 'peephole2' pass is run after register allocation but before
  scheduling, which may result in much better code for targets that do
  scheduling.
  
--- 30126,30136 ----
  detect such opportunities.
  
   There are two forms of peephole definitions that may be used.  The
! original ‘define_peephole’ is run at assembly output time to match insns
! and substitute assembly text.  Use of ‘define_peephole’ is deprecated.
  
!  A newer ‘define_peephole2’ matches insns and substitutes new insns.
! The ‘peephole2’ pass is run after register allocation but before
  scheduling, which may result in much better code for targets that do
  scheduling.
  
*************** A definition looks like this:
*** 30158,30164 ****
  
  The last string operand may be omitted if you are not using any
  machine-specific information in this machine description.  If present,
! it must obey the same rules as in a 'define_insn'.
  
   In this skeleton, INSN-PATTERN-1 and so on are patterns to match
  consecutive insns.  The optimization applies to a sequence of insns when
--- 30157,30163 ----
  
  The last string operand may be omitted if you are not using any
  machine-specific information in this machine description.  If present,
! it must obey the same rules as in a ‘define_insn’.
  
   In this skeleton, INSN-PATTERN-1 and so on are patterns to match
  consecutive insns.  The optimization applies to a sequence of insns when
*************** INSN-PATTERN-1 matches the first one, IN
*** 30166,30184 ****
  and so on.
  
   Each of the insns matched by a peephole must also match a
! 'define_insn'.  Peepholes are checked only at the last stage just before
  code generation, and only optionally.  Therefore, any insn which would
! match a peephole but no 'define_insn' will cause a crash in code
  generation in an unoptimized compilation, or at various optimization
  stages.
  
!  The operands of the insns are matched with 'match_operands',
! 'match_operator', and 'match_dup', as usual.  What is not usual is that
  the operand numbers apply to all the insn patterns in the definition.
  So, you can check for identical operands in two insns by using
! 'match_operand' in one insn and 'match_dup' in the other.
  
!  The operand constraints used in 'match_operand' patterns do not have
  any direct effect on the applicability of the peephole, but they will be
  validated afterward, so make sure your constraints are general enough to
  apply whenever the peephole matches.  If the peephole matches but the
--- 30165,30183 ----
  and so on.
  
   Each of the insns matched by a peephole must also match a
! ‘define_insn’.  Peepholes are checked only at the last stage just before
  code generation, and only optionally.  Therefore, any insn which would
! match a peephole but no ‘define_insn’ will cause a crash in code
  generation in an unoptimized compilation, or at various optimization
  stages.
  
!  The operands of the insns are matched with ‘match_operands’,
! ‘match_operator’, and ‘match_dup’, as usual.  What is not usual is that
  the operand numbers apply to all the insn patterns in the definition.
  So, you can check for identical operands in two insns by using
! ‘match_operand’ in one insn and ‘match_dup’ in the other.
  
!  The operand constraints used in ‘match_operand’ patterns do not have
  any direct effect on the applicability of the peephole, but they will be
  validated afterward, so make sure your constraints are general enough to
  apply whenever the peephole matches.  If the peephole matches but the
*************** allocation is complete.  Therefore, the
*** 30200,30221 ****
  which operands have ended up in which kinds of registers, just by
  looking at the operands.
  
!  The way to refer to the operands in CONDITION is to write 'operands[I]'
! for operand number I (as matched by '(match_operand I ...)').  Use the
! variable 'insn' to refer to the last of the insns being matched; use
! 'prev_active_insn' to find the preceding insns.
  
   When optimizing computations with intermediate results, you can use
  CONDITION to match only when the intermediate results are not used
! elsewhere.  Use the C expression 'dead_or_set_p (INSN, OP)', where INSN
  is the insn in which you expect the value to be used for the last time
! (from the value of 'insn', together with use of 'prev_nonnote_insn'),
! and OP is the intermediate value (from 'operands[I]').
  
   Applying the optimization means replacing the sequence of insns with
  one new insn.  The TEMPLATE controls ultimate output of assembler code
  for this combined insn.  It works exactly like the template of a
! 'define_insn'.  Operand numbers in this template are the same ones used
  in matching the original sequence of insns.
  
   The result of a defined peephole optimizer does not need to match any
--- 30199,30220 ----
  which operands have ended up in which kinds of registers, just by
  looking at the operands.
  
!  The way to refer to the operands in CONDITION is to write ‘operands[I]’
! for operand number I (as matched by ‘(match_operand I ...)’).  Use the
! variable ‘insn’ to refer to the last of the insns being matched; use
! ‘prev_active_insn’ to find the preceding insns.
  
   When optimizing computations with intermediate results, you can use
  CONDITION to match only when the intermediate results are not used
! elsewhere.  Use the C expression ‘dead_or_set_p (INSN, OP)’, where INSN
  is the insn in which you expect the value to be used for the last time
! (from the value of ‘insn’, together with use of ‘prev_nonnote_insn’),
! and OP is the intermediate value (from ‘operands[I]’).
  
   Applying the optimization means replacing the sequence of insns with
  one new insn.  The TEMPLATE controls ultimate output of assembler code
  for this combined insn.  It works exactly like the template of a
! ‘define_insn’.  Operand numbers in this template are the same ones used
  in matching the original sequence of insns.
  
   The result of a defined peephole optimizer does not need to match any
*************** into
*** 30263,30275 ****
       fmoved sp@+,fp0
  
   INSN-PATTERN-1 and so on look _almost_ like the second operand of
! 'define_insn'.  There is one important difference: the second operand of
! 'define_insn' consists of one or more RTX's enclosed in square brackets.
  Usually, there is only one: then the same action can be written as an
! element of a 'define_peephole'.  But when there are multiple actions in
! a 'define_insn', they are implicitly enclosed in a 'parallel'.  Then you
! must explicitly write the 'parallel', and the square brackets within it,
! in the 'define_peephole'.  Thus, if an insn pattern looks like this,
  
       (define_insn "divmodsi4"
         [(set (match_operand:SI 0 "general_operand" "=d")
--- 30262,30274 ----
       fmoved sp@+,fp0
  
   INSN-PATTERN-1 and so on look _almost_ like the second operand of
! ‘define_insn’.  There is one important difference: the second operand of
! ‘define_insn’ consists of one or more RTX's enclosed in square brackets.
  Usually, there is only one: then the same action can be written as an
! element of a ‘define_peephole’.  But when there are multiple actions in
! a ‘define_insn’, they are implicitly enclosed in a ‘parallel’.  Then you
! must explicitly write the ‘parallel’, and the square brackets within it,
! in the ‘define_peephole’.  Thus, if an insn pattern looks like this,
  
       (define_insn "divmodsi4"
         [(set (match_operand:SI 0 "general_operand" "=d")
*************** File: gccint.info,  Node: define_peephol
*** 30299,30305 ****
  17.18.2 RTL to RTL Peephole Optimizers
  --------------------------------------
  
! The 'define_peephole2' definition tells the compiler how to substitute
  one sequence of instructions for another sequence, what additional
  scratch registers may be needed and what their lifetimes must be.
  
--- 30298,30304 ----
  17.18.2 RTL to RTL Peephole Optimizers
  --------------------------------------
  
! The ‘define_peephole2’ definition tells the compiler how to substitute
  one sequence of instructions for another sequence, what additional
  scratch registers may be needed and what their lifetimes must be.
  
*************** scratch registers may be needed and what
*** 30313,30319 ****
          ...]
         "PREPARATION-STATEMENTS")
  
!  The definition is almost identical to 'define_split' (*note Insn
  Splitting::) except that the pattern to match is not a single
  instruction, but a sequence of instructions.
  
--- 30312,30318 ----
          ...]
         "PREPARATION-STATEMENTS")
  
!  The definition is almost identical to ‘define_split’ (*note Insn
  Splitting::) except that the pattern to match is not a single
  instruction, but a sequence of instructions.
  
*************** instruction, but a sequence of instructi
*** 30321,30330 ****
  output template.  If appropriate registers are not free, the pattern
  will simply not match.
  
!  Scratch registers are requested with a 'match_scratch' pattern at the
  top level of the input pattern.  The allocated register (initially) will
  be dead at the point requested within the original sequence.  If the
! scratch is used at more than a single point, a 'match_dup' pattern at
  the top level of the input pattern marks the last position in the input
  sequence at which the register must be available.
  
--- 30320,30329 ----
  output template.  If appropriate registers are not free, the pattern
  will simply not match.
  
!  Scratch registers are requested with a ‘match_scratch’ pattern at the
  top level of the input pattern.  The allocated register (initially) will
  be dead at the point requested within the original sequence.  If the
! scratch is used at more than a single point, a ‘match_dup’ pattern at
  the top level of the input pattern marks the last position in the input
  sequence at which the register must be available.
  
*************** sequence at which the register must be a
*** 30346,30352 ****
  
  This pattern tries to split a load from its use in the hopes that we'll
  be able to schedule around the memory load latency.  It allocates a
! single 'SImode' register of class 'GENERAL_REGS' ('"r"') that needs to
  be live only at the point just before the arithmetic.
  
   A real example requiring extended scratch lifetimes is harder to come
--- 30345,30351 ----
  
  This pattern tries to split a load from its use in the hopes that we'll
  be able to schedule around the memory load latency.  It allocates a
! single ‘SImode’ register of class ‘GENERAL_REGS’ (‘"r"’) that needs to
  be live only at the point just before the arithmetic.
  
   A real example requiring extended scratch lifetimes is harder to come
*************** by, so here's a silly made-up example:
*** 30365,30396 ****
          (set (match_dup 3) (match_dup 4))]
         "")
  
! If we had not added the '(match_dup 4)' in the middle of the input
  sequence, it might have been the case that the register we chose at the
! beginning of the sequence is killed by the first or second 'set'.
  
   There are two special macros defined for use in the preparation
! statements: 'DONE' and 'FAIL'.  Use them with a following semicolon, as
  a statement.
  
! 'DONE'
!      Use the 'DONE' macro to end RTL generation for the peephole.  The
       only RTL insns generated as replacement for the matched input insn
!      will be those already emitted by explicit calls to 'emit_insn'
       within the preparation statements; the replacement pattern is not
       used.
  
! 'FAIL'
!      Make the 'define_peephole2' fail on this occasion.  When a
!      'define_peephole2' fails, it means that the replacement was not
       truly available for the particular inputs it was given.  In that
!      case, GCC may still apply a later 'define_peephole2' that also
       matches the given insn pattern.  (Note that this is different from
!      'define_split', where 'FAIL' prevents the input insn from being
       split at all.)
  
!  If the preparation falls through (invokes neither 'DONE' nor 'FAIL'),
! then the 'define_peephole2' uses the replacement template.
  
  
  File: gccint.info,  Node: Insn Attributes,  Next: Conditional Execution,  Prev: Peephole Definitions,  Up: Machine Desc
--- 30364,30395 ----
          (set (match_dup 3) (match_dup 4))]
         "")
  
! If we had not added the ‘(match_dup 4)’ in the middle of the input
  sequence, it might have been the case that the register we chose at the
! beginning of the sequence is killed by the first or second ‘set’.
  
   There are two special macros defined for use in the preparation
! statements: ‘DONE’ and ‘FAIL’.  Use them with a following semicolon, as
  a statement.
  
! ‘DONE’
!      Use the ‘DONE’ macro to end RTL generation for the peephole.  The
       only RTL insns generated as replacement for the matched input insn
!      will be those already emitted by explicit calls to ‘emit_insn’
       within the preparation statements; the replacement pattern is not
       used.
  
! ‘FAIL’
!      Make the ‘define_peephole2’ fail on this occasion.  When a
!      ‘define_peephole2’ fails, it means that the replacement was not
       truly available for the particular inputs it was given.  In that
!      case, GCC may still apply a later ‘define_peephole2’ that also
       matches the given insn pattern.  (Note that this is different from
!      ‘define_split’, where ‘FAIL’ prevents the input insn from being
       split at all.)
  
!  If the preparation falls through (invokes neither ‘DONE’ nor ‘FAIL’),
! then the ‘define_peephole2’ uses the replacement template.
  
  
  File: gccint.info,  Node: Insn Attributes,  Next: Conditional Execution,  Prev: Peephole Definitions,  Up: Machine Desc
*************** File: gccint.info,  Node: Insn Attribute
*** 30399,30405 ****
  ============================
  
  In addition to describing the instruction supported by the target
! machine, the 'md' file also defines a group of "attributes" and a set of
  values for each.  Every generated insn is assigned a value for each
  attribute.  One possible attribute would be the effect that the insn has
  on the machine's condition code.
--- 30398,30404 ----
  ============================
  
  In addition to describing the instruction supported by the target
! machine, the ‘md’ file also defines a group of “attributes” and a set of
  values for each.  Every generated insn is assigned a value for each
  attribute.  One possible attribute would be the effect that the insn has
  on the machine's condition code.
*************** File: gccint.info,  Node: Defining Attri
*** 30422,30442 ****
  17.19.1 Defining Attributes and their Values
  --------------------------------------------
  
! The 'define_attr' expression is used to define each attribute required
  by the target machine.  It looks like:
  
       (define_attr NAME LIST-OF-VALUES DEFAULT)
  
   NAME is a string specifying the name of the attribute being defined.
  Some attributes are used in a special way by the rest of the compiler.
! The 'enabled' attribute can be used to conditionally enable or disable
! insn alternatives (*note Disable Insn Alternatives::).  The 'predicable'
! attribute, together with a suitable 'define_cond_exec' (*note
  Conditional Execution::), can be used to automatically generate
! conditional variants of instruction patterns.  The 'mnemonic' attribute
  can be used to check for the instruction mnemonic (*note Mnemonic
! Attribute::).  The compiler internally uses the names 'ce_enabled' and
! 'nonce_enabled', so they should not be used elsewhere as alternative
  names.
  
   LIST-OF-VALUES is either a string that specifies a comma-separated list
--- 30421,30441 ----
  17.19.1 Defining Attributes and their Values
  --------------------------------------------
  
! The ‘define_attr’ expression is used to define each attribute required
  by the target machine.  It looks like:
  
       (define_attr NAME LIST-OF-VALUES DEFAULT)
  
   NAME is a string specifying the name of the attribute being defined.
  Some attributes are used in a special way by the rest of the compiler.
! The ‘enabled’ attribute can be used to conditionally enable or disable
! insn alternatives (*note Disable Insn Alternatives::).  The ‘predicable’
! attribute, together with a suitable ‘define_cond_exec’ (*note
  Conditional Execution::), can be used to automatically generate
! conditional variants of instruction patterns.  The ‘mnemonic’ attribute
  can be used to check for the instruction mnemonic (*note Mnemonic
! Attribute::).  The compiler internally uses the names ‘ce_enabled’ and
! ‘nonce_enabled’, so they should not be used elsewhere as alternative
  names.
  
   LIST-OF-VALUES is either a string that specifies a comma-separated list
*************** Attributes::, for information on attribu
*** 30451,30509 ****
  particular insn.
  
   For each defined attribute, a number of definitions are written to the
! 'insn-attr.h' file.  For cases where an explicit set of values is
  specified for an attribute, the following are defined:
  
!    * A '#define' is written for the symbol 'HAVE_ATTR_NAME'.
  
!    * An enumerated class is defined for 'attr_NAME' with elements of the
!      form 'UPPER-NAME_UPPER-VALUE' where the attribute name and value
       are first converted to uppercase.
  
!    * A function 'get_attr_NAME' is defined that is passed an insn and
       returns the attribute value for that insn.
  
!  For example, if the following is present in the 'md' file:
  
       (define_attr "type" "branch,fp,load,store,arith" ...)
  
! the following lines will be written to the file 'insn-attr.h'.
  
       #define HAVE_ATTR_type 1
       enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
                        TYPE_STORE, TYPE_ARITH};
       extern enum attr_type get_attr_type ();
  
!  If the attribute takes numeric values, no 'enum' type will be defined
! and the function to obtain the attribute's value will return 'int'.
  
   There are attributes which are tied to a specific meaning.  These
  attributes are not free to use for other purposes:
  
! 'length'
!      The 'length' attribute is used to calculate the length of emitted
       code chunks.  This is especially important when verifying branch
       distances.  *Note Insn Lengths::.
  
! 'enabled'
!      The 'enabled' attribute can be defined to prevent certain
       alternatives of an insn definition from being used during code
       generation.  *Note Disable Insn Alternatives::.
  
! 'mnemonic'
!      The 'mnemonic' attribute can be defined to implement instruction
       specific checks in e.g. the pipeline description.  *Note Mnemonic
       Attribute::.
  
   For each of these special attributes, the corresponding
! 'HAVE_ATTR_NAME' '#define' is also written when the attribute is not
! defined; in that case, it is defined as '0'.
  
   Another way of defining an attribute is to use:
  
       (define_enum_attr "ATTR" "ENUM" DEFAULT)
  
!  This works in just the same way as 'define_attr', except that the list
  of values is taken from a separate enumeration called ENUM (*note
  define_enum::).  This form allows you to use the same list of values for
  several attributes without having to repeat the list each time.  For
--- 30450,30508 ----
  particular insn.
  
   For each defined attribute, a number of definitions are written to the
! ‘insn-attr.h’ file.  For cases where an explicit set of values is
  specified for an attribute, the following are defined:
  
!    • A ‘#define’ is written for the symbol ‘HAVE_ATTR_NAME’.
  
!    • An enumerated class is defined for ‘attr_NAME’ with elements of the
!      form ‘UPPER-NAME_UPPER-VALUE’ where the attribute name and value
       are first converted to uppercase.
  
!    • A function ‘get_attr_NAME’ is defined that is passed an insn and
       returns the attribute value for that insn.
  
!  For example, if the following is present in the ‘md’ file:
  
       (define_attr "type" "branch,fp,load,store,arith" ...)
  
! the following lines will be written to the file ‘insn-attr.h’.
  
       #define HAVE_ATTR_type 1
       enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
                        TYPE_STORE, TYPE_ARITH};
       extern enum attr_type get_attr_type ();
  
!  If the attribute takes numeric values, no ‘enum’ type will be defined
! and the function to obtain the attribute's value will return ‘int’.
  
   There are attributes which are tied to a specific meaning.  These
  attributes are not free to use for other purposes:
  
! ‘length’
!      The ‘length’ attribute is used to calculate the length of emitted
       code chunks.  This is especially important when verifying branch
       distances.  *Note Insn Lengths::.
  
! ‘enabled’
!      The ‘enabled’ attribute can be defined to prevent certain
       alternatives of an insn definition from being used during code
       generation.  *Note Disable Insn Alternatives::.
  
! ‘mnemonic’
!      The ‘mnemonic’ attribute can be defined to implement instruction
       specific checks in e.g. the pipeline description.  *Note Mnemonic
       Attribute::.
  
   For each of these special attributes, the corresponding
! ‘HAVE_ATTR_NAME’ ‘#define’ is also written when the attribute is not
! defined; in that case, it is defined as ‘0’.
  
   Another way of defining an attribute is to use:
  
       (define_enum_attr "ATTR" "ENUM" DEFAULT)
  
!  This works in just the same way as ‘define_attr’, except that the list
  of values is taken from a separate enumeration called ENUM (*note
  define_enum::).  This form allows you to use the same list of values for
  several attributes without having to repeat the list each time.  For
*************** example:
*** 30527,30534 ****
         (const (symbol_ref "target_tune")))
  
   but without duplicating the processor list.  The second example defines
! two separate C enums ('attr_arch' and 'attr_tune') whereas the first
! defines a single C enum ('processor').
  
  
  File: gccint.info,  Node: Expressions,  Next: Tagging Insns,  Prev: Defining Attributes,  Up: Insn Attributes
--- 30526,30533 ----
         (const (symbol_ref "target_tune")))
  
   but without duplicating the processor list.  The second example defines
! two separate C enums (‘attr_arch’ and ‘attr_tune’) whereas the first
! defines a single C enum (‘processor’).
  
  
  File: gccint.info,  Node: Expressions,  Next: Tagging Insns,  Prev: Defining Attributes,  Up: Insn Attributes
*************** RTL expressions used to define attribute
*** 30540,30647 ****
  plus a few specific to attribute definitions, to be discussed below.
  Attribute value expressions must have one of the following forms:
  
! '(const_int I)'
       The integer I specifies the value of a numeric attribute.  I must
       be non-negative.
  
       The value of a numeric attribute can be specified either with a
!      'const_int', or as an integer represented as a string in
!      'const_string', 'eq_attr' (see below), 'attr', 'symbol_ref', simple
!      arithmetic expressions, and 'set_attr' overrides on specific
       instructions (*note Tagging Insns::).
  
! '(const_string VALUE)'
       The string VALUE specifies a constant attribute value.  If VALUE is
!      specified as '"*"', it means that the default value of the
       attribute is to be used for the insn containing this expression.
!      '"*"' obviously cannot be used in the DEFAULT expression of a
!      'define_attr'.
  
       If the attribute whose value is being specified is numeric, VALUE
       must be a string containing a non-negative integer (normally
!      'const_int' would be used in this case).  Otherwise, it must
       contain one of the valid values for the attribute.
  
! '(if_then_else TEST TRUE-VALUE FALSE-VALUE)'
       TEST specifies an attribute test, whose format is defined below.
       The value of this expression is TRUE-VALUE if TEST is true,
       otherwise it is FALSE-VALUE.
  
! '(cond [TEST1 VALUE1 ...] DEFAULT)'
       The first operand of this expression is a vector containing an even
       number of expressions and consisting of pairs of TEST and VALUE
!      expressions.  The value of the 'cond' expression is that of the
       VALUE corresponding to the first true TEST expression.  If none of
!      the TEST expressions are true, the value of the 'cond' expression
       is that of the DEFAULT expression.
  
   TEST expressions can have one of the following forms:
  
! '(const_int I)'
       This test is true if I is nonzero and false otherwise.
  
! '(not TEST)'
! '(ior TEST1 TEST2)'
! '(and TEST1 TEST2)'
       These tests are true if the indicated logical function is true.
  
! '(match_operand:M N PRED CONSTRAINTS)'
       This test is true if operand N of the insn whose attribute value is
       being determined has mode M (this part of the test is ignored if M
!      is 'VOIDmode') and the function specified by the string PRED
       returns a nonzero value when passed operand N and mode M (this part
       of the test is ignored if PRED is the null string).
  
       The CONSTRAINTS operand is ignored and should be the null string.
  
! '(match_test C-EXPR)'
       The test is true if C expression C-EXPR is true.  In non-constant
       attributes, C-EXPR has access to the following variables:
  
       INSN
            The rtl instruction under test.
       WHICH_ALTERNATIVE
!           The 'define_insn' alternative that INSN matches.  *Note Output
            Statement::.
       OPERANDS
            An array of INSN's rtl operands.
  
!      C-EXPR behaves like the condition in a C 'if' statement, so there
       is no need to explicitly convert the expression into a boolean 0 or
       1 value.  For example, the following two tests are equivalent:
  
            (match_test "x & 2")
            (match_test "(x & 2) != 0")
  
! '(le ARITH1 ARITH2)'
! '(leu ARITH1 ARITH2)'
! '(lt ARITH1 ARITH2)'
! '(ltu ARITH1 ARITH2)'
! '(gt ARITH1 ARITH2)'
! '(gtu ARITH1 ARITH2)'
! '(ge ARITH1 ARITH2)'
! '(geu ARITH1 ARITH2)'
! '(ne ARITH1 ARITH2)'
! '(eq ARITH1 ARITH2)'
       These tests are true if the indicated comparison of the two
       arithmetic expressions is true.  Arithmetic expressions are formed
!      with 'plus', 'minus', 'mult', 'div', 'mod', 'abs', 'neg', 'and',
!      'ior', 'xor', 'not', 'ashift', 'lshiftrt', and 'ashiftrt'
       expressions.
  
!      'const_int' and 'symbol_ref' are always valid terms (*note Insn
!      Lengths::,for additional forms).  'symbol_ref' is a string denoting
!      a C expression that yields an 'int' when evaluated by the
!      'get_attr_...' routine.  It should normally be a global variable.
  
! '(eq_attr NAME VALUE)'
       NAME is a string specifying the name of an attribute.
  
       VALUE is a string that is either a valid value for attribute NAME,
!      a comma-separated list of values, or '!' followed by a value or
!      list.  If VALUE does not begin with a '!', this test is true if the
       value of the NAME attribute of the current insn is in the list
!      specified by VALUE.  If VALUE begins with a '!', this test is true
       if the attribute's value is _not_ in the specified list.
  
       For example,
--- 30539,30646 ----
  plus a few specific to attribute definitions, to be discussed below.
  Attribute value expressions must have one of the following forms:
  
! ‘(const_int I)’
       The integer I specifies the value of a numeric attribute.  I must
       be non-negative.
  
       The value of a numeric attribute can be specified either with a
!      ‘const_int’, or as an integer represented as a string in
!      ‘const_string’, ‘eq_attr’ (see below), ‘attr’, ‘symbol_ref’, simple
!      arithmetic expressions, and ‘set_attr’ overrides on specific
       instructions (*note Tagging Insns::).
  
! ‘(const_string VALUE)’
       The string VALUE specifies a constant attribute value.  If VALUE is
!      specified as ‘"*"’, it means that the default value of the
       attribute is to be used for the insn containing this expression.
!      ‘"*"’ obviously cannot be used in the DEFAULT expression of a
!      ‘define_attr’.
  
       If the attribute whose value is being specified is numeric, VALUE
       must be a string containing a non-negative integer (normally
!      ‘const_int’ would be used in this case).  Otherwise, it must
       contain one of the valid values for the attribute.
  
! ‘(if_then_else TEST TRUE-VALUE FALSE-VALUE)’
       TEST specifies an attribute test, whose format is defined below.
       The value of this expression is TRUE-VALUE if TEST is true,
       otherwise it is FALSE-VALUE.
  
! ‘(cond [TEST1 VALUE1 ...] DEFAULT)’
       The first operand of this expression is a vector containing an even
       number of expressions and consisting of pairs of TEST and VALUE
!      expressions.  The value of the ‘cond’ expression is that of the
       VALUE corresponding to the first true TEST expression.  If none of
!      the TEST expressions are true, the value of the ‘cond’ expression
       is that of the DEFAULT expression.
  
   TEST expressions can have one of the following forms:
  
! ‘(const_int I)’
       This test is true if I is nonzero and false otherwise.
  
! ‘(not TEST)’
! ‘(ior TEST1 TEST2)’
! ‘(and TEST1 TEST2)’
       These tests are true if the indicated logical function is true.
  
! ‘(match_operand:M N PRED CONSTRAINTS)’
       This test is true if operand N of the insn whose attribute value is
       being determined has mode M (this part of the test is ignored if M
!      is ‘VOIDmode’) and the function specified by the string PRED
       returns a nonzero value when passed operand N and mode M (this part
       of the test is ignored if PRED is the null string).
  
       The CONSTRAINTS operand is ignored and should be the null string.
  
! ‘(match_test C-EXPR)’
       The test is true if C expression C-EXPR is true.  In non-constant
       attributes, C-EXPR has access to the following variables:
  
       INSN
            The rtl instruction under test.
       WHICH_ALTERNATIVE
!           The ‘define_insn’ alternative that INSN matches.  *Note Output
            Statement::.
       OPERANDS
            An array of INSN's rtl operands.
  
!      C-EXPR behaves like the condition in a C ‘if’ statement, so there
       is no need to explicitly convert the expression into a boolean 0 or
       1 value.  For example, the following two tests are equivalent:
  
            (match_test "x & 2")
            (match_test "(x & 2) != 0")
  
! ‘(le ARITH1 ARITH2)’
! ‘(leu ARITH1 ARITH2)’
! ‘(lt ARITH1 ARITH2)’
! ‘(ltu ARITH1 ARITH2)’
! ‘(gt ARITH1 ARITH2)’
! ‘(gtu ARITH1 ARITH2)’
! ‘(ge ARITH1 ARITH2)’
! ‘(geu ARITH1 ARITH2)’
! ‘(ne ARITH1 ARITH2)’
! ‘(eq ARITH1 ARITH2)’
       These tests are true if the indicated comparison of the two
       arithmetic expressions is true.  Arithmetic expressions are formed
!      with ‘plus’, ‘minus’, ‘mult’, ‘div’, ‘mod’, ‘abs’, ‘neg’, ‘and’,
!      ‘ior’, ‘xor’, ‘not’, ‘ashift’, ‘lshiftrt’, and ‘ashiftrt’
       expressions.
  
!      ‘const_int’ and ‘symbol_ref’ are always valid terms (*note Insn
!      Lengths::,for additional forms).  ‘symbol_ref’ is a string denoting
!      a C expression that yields an ‘int’ when evaluated by the
!      ‘get_attr_...’ routine.  It should normally be a global variable.
  
! ‘(eq_attr NAME VALUE)’
       NAME is a string specifying the name of an attribute.
  
       VALUE is a string that is either a valid value for attribute NAME,
!      a comma-separated list of values, or ‘!’ followed by a value or
!      list.  If VALUE does not begin with a ‘!’, this test is true if the
       value of the NAME attribute of the current insn is in the list
!      specified by VALUE.  If VALUE begins with a ‘!’, this test is true
       if the attribute's value is _not_ in the specified list.
  
       For example,
*************** Attribute value expressions must have on
*** 30652,30659 ****
  
            (ior (eq_attr "type" "load") (eq_attr "type" "store"))
  
!      If NAME specifies an attribute of 'alternative', it refers to the
!      value of the compiler variable 'which_alternative' (*note Output
       Statement::) and the values must be small integers.  For example,
  
            (eq_attr "alternative" "2,3")
--- 30651,30658 ----
  
            (ior (eq_attr "type" "load") (eq_attr "type" "store"))
  
!      If NAME specifies an attribute of ‘alternative’, it refers to the
!      value of the compiler variable ‘which_alternative’ (*note Output
       Statement::) and the values must be small integers.  For example,
  
            (eq_attr "alternative" "2,3")
*************** Attribute value expressions must have on
*** 30663,30679 ****
            (ior (eq (symbol_ref "which_alternative") (const_int 2))
                 (eq (symbol_ref "which_alternative") (const_int 3)))
  
!      Note that, for most attributes, an 'eq_attr' test is simplified in
       cases where the value of the attribute being tested is known for
       all insns matching a particular pattern.  This is by far the most
       common case.
  
! '(attr_flag NAME)'
!      The value of an 'attr_flag' expression is true if the flag
!      specified by NAME is true for the 'insn' currently being scheduled.
  
       NAME is a string specifying one of a fixed set of flags to test.
!      Test the flags 'forward' and 'backward' to determine the direction
       of a conditional branch.
  
       This example describes a conditional branch delay slot which can be
--- 30662,30678 ----
            (ior (eq (symbol_ref "which_alternative") (const_int 2))
                 (eq (symbol_ref "which_alternative") (const_int 3)))
  
!      Note that, for most attributes, an ‘eq_attr’ test is simplified in
       cases where the value of the attribute being tested is known for
       all insns matching a particular pattern.  This is by far the most
       common case.
  
! ‘(attr_flag NAME)’
!      The value of an ‘attr_flag’ expression is true if the flag
!      specified by NAME is true for the ‘insn’ currently being scheduled.
  
       NAME is a string specifying one of a fixed set of flags to test.
!      Test the flags ‘forward’ and ‘backward’ to determine the direction
       of a conditional branch.
  
       This example describes a conditional branch delay slot which can be
*************** Attribute value expressions must have on
*** 30687,30701 ****
               (and (eq_attr "in_branch_delay" "true")
                    (attr_flag "backward"))])
  
!      The 'forward' and 'backward' flags are false if the current 'insn'
       being scheduled is not a conditional branch.
  
!      'attr_flag' is only used during delay slot scheduling and has no
       meaning to other passes of the compiler.
  
! '(attr NAME)'
       The value of another attribute is returned.  This is most useful
!      for numeric attributes, as 'eq_attr' and 'attr_flag' produce more
       efficient code for non-numeric attributes.
  
  
--- 30686,30700 ----
               (and (eq_attr "in_branch_delay" "true")
                    (attr_flag "backward"))])
  
!      The ‘forward’ and ‘backward’ flags are false if the current ‘insn’
       being scheduled is not a conditional branch.
  
!      ‘attr_flag’ is only used during delay slot scheduling and has no
       meaning to other passes of the compiler.
  
! ‘(attr NAME)’
       The value of another attribute is returned.  This is most useful
!      for numeric attributes, as ‘eq_attr’ and ‘attr_flag’ produce more
       efficient code for non-numeric attributes.
  
  
*************** File: gccint.info,  Node: Tagging Insns,
*** 30705,30760 ****
  -------------------------------------------
  
  The value assigned to an attribute of an insn is primarily determined by
! which pattern is matched by that insn (or which 'define_peephole'
! generated it).  Every 'define_insn' and 'define_peephole' can have an
  optional last argument to specify the values of attributes for matching
  insns.  The value of any attribute not specified in a particular insn is
  set to the default value for that attribute, as specified in its
! 'define_attr'.  Extensive use of default values for attributes permits
  the specification of the values for only one or two attributes in the
  definition of most insn patterns, as seen in the example in the next
  section.
  
!  The optional last argument of 'define_insn' and 'define_peephole' is a
  vector of expressions, each of which defines the value for a single
  attribute.  The most general way of assigning an attribute's value is to
! use a 'set' expression whose first operand is an 'attr' expression
  giving the name of the attribute being set.  The second operand of the
! 'set' is an attribute expression (*note Expressions::) giving the value
  of the attribute.
  
!  When the attribute value depends on the 'alternative' attribute (i.e.,
  which is the applicable alternative in the constraint of the insn), the
! 'set_attr_alternative' expression can be used.  It allows the
  specification of a vector of attribute expressions, one for each
  alternative.
  
   When the generality of arbitrary attribute expressions is not required,
! the simpler 'set_attr' expression can be used, which allows specifying a
  string giving either a single attribute value or a list of attribute
  values, one for each alternative.
  
   The form of each of the above specifications is shown below.  In each
  case, NAME is a string specifying the attribute to be set.
  
! '(set_attr NAME VALUE-STRING)'
       VALUE-STRING is either a string giving the desired attribute value,
       or a string containing a comma-separated list giving the values for
       succeeding alternatives.  The number of elements must match the
       number of alternatives in the constraint of the insn pattern.
  
!      Note that it may be useful to specify '*' for some alternative, in
       which case the attribute will assume its default value for insns
       matching that alternative.
  
! '(set_attr_alternative NAME [VALUE1 VALUE2 ...])'
       Depending on the alternative of the insn, the value will be one of
!      the specified values.  This is a shorthand for using a 'cond' with
!      tests on the 'alternative' attribute.
  
! '(set (attr NAME) VALUE)'
!      The first operand of this 'set' must be the special RTL expression
!      'attr', whose sole operand is a string giving the name of the
       attribute being set.  VALUE is the value of the attribute.
  
   The following shows three different ways of representing the same
--- 30704,30759 ----
  -------------------------------------------
  
  The value assigned to an attribute of an insn is primarily determined by
! which pattern is matched by that insn (or which ‘define_peephole’
! generated it).  Every ‘define_insn’ and ‘define_peephole’ can have an
  optional last argument to specify the values of attributes for matching
  insns.  The value of any attribute not specified in a particular insn is
  set to the default value for that attribute, as specified in its
! ‘define_attr’.  Extensive use of default values for attributes permits
  the specification of the values for only one or two attributes in the
  definition of most insn patterns, as seen in the example in the next
  section.
  
!  The optional last argument of ‘define_insn’ and ‘define_peephole’ is a
  vector of expressions, each of which defines the value for a single
  attribute.  The most general way of assigning an attribute's value is to
! use a ‘set’ expression whose first operand is an ‘attr’ expression
  giving the name of the attribute being set.  The second operand of the
! ‘set’ is an attribute expression (*note Expressions::) giving the value
  of the attribute.
  
!  When the attribute value depends on the ‘alternative’ attribute (i.e.,
  which is the applicable alternative in the constraint of the insn), the
! ‘set_attr_alternative’ expression can be used.  It allows the
  specification of a vector of attribute expressions, one for each
  alternative.
  
   When the generality of arbitrary attribute expressions is not required,
! the simpler ‘set_attr’ expression can be used, which allows specifying a
  string giving either a single attribute value or a list of attribute
  values, one for each alternative.
  
   The form of each of the above specifications is shown below.  In each
  case, NAME is a string specifying the attribute to be set.
  
! ‘(set_attr NAME VALUE-STRING)’
       VALUE-STRING is either a string giving the desired attribute value,
       or a string containing a comma-separated list giving the values for
       succeeding alternatives.  The number of elements must match the
       number of alternatives in the constraint of the insn pattern.
  
!      Note that it may be useful to specify ‘*’ for some alternative, in
       which case the attribute will assume its default value for insns
       matching that alternative.
  
! ‘(set_attr_alternative NAME [VALUE1 VALUE2 ...])’
       Depending on the alternative of the insn, the value will be one of
!      the specified values.  This is a shorthand for using a ‘cond’ with
!      tests on the ‘alternative’ attribute.
  
! ‘(set (attr NAME) VALUE)’
!      The first operand of this ‘set’ must be the special RTL expression
!      ‘attr’, whose sole operand is a string giving the name of the
       attribute being set.  VALUE is the value of the attribute.
  
   The following shows three different ways of representing the same
*************** attribute value specification:
*** 30771,30795 ****
                   (eq_attr "alternative" "2") (const_string "store")]
                  (const_string "arith")))
  
!  The 'define_asm_attributes' expression provides a mechanism to specify
! the attributes assigned to insns produced from an 'asm' statement.  It
  has the form:
  
       (define_asm_attributes [ATTR-SETS])
  
! where ATTR-SETS is specified the same as for both the 'define_insn' and
! the 'define_peephole' expressions.
  
   These values will typically be the "worst case" attribute values.  For
  example, they might indicate that the condition code will be clobbered.
  
!  A specification for a 'length' attribute is handled specially.  The way
! to compute the length of an 'asm' insn is to multiply the length
! specified in the expression 'define_asm_attributes' by the number of
! machine instructions specified in the 'asm' statement, determined by
  counting the number of semicolons and newlines in the string.
! Therefore, the value of the 'length' attribute specified in a
! 'define_asm_attributes' should be the maximum possible length of a
  single machine instruction.
  
  
--- 30770,30794 ----
                   (eq_attr "alternative" "2") (const_string "store")]
                  (const_string "arith")))
  
!  The ‘define_asm_attributes’ expression provides a mechanism to specify
! the attributes assigned to insns produced from an ‘asm’ statement.  It
  has the form:
  
       (define_asm_attributes [ATTR-SETS])
  
! where ATTR-SETS is specified the same as for both the ‘define_insn’ and
! the ‘define_peephole’ expressions.
  
   These values will typically be the "worst case" attribute values.  For
  example, they might indicate that the condition code will be clobbered.
  
!  A specification for a ‘length’ attribute is handled specially.  The way
! to compute the length of an ‘asm’ insn is to multiply the length
! specified in the expression ‘define_asm_attributes’ by the number of
! machine instructions specified in the ‘asm’ statement, determined by
  counting the number of semicolons and newlines in the string.
! Therefore, the value of the ‘length’ attribute specified in a
! ‘define_asm_attributes’ should be the maximum possible length of a
  single machine instruction.
  
  
*************** File: gccint.info,  Node: Attr Example,
*** 30799,30806 ****
  -------------------------------------------
  
  The judicious use of defaulting is important in the efficient use of
! insn attributes.  Typically, insns are divided into "types" and an
! attribute, customarily called 'type', is used to represent this value.
  This attribute is normally used only to define the default value for
  other attributes.  An example will clarify this usage.
  
--- 30798,30805 ----
  -------------------------------------------
  
  The judicious use of defaulting is important in the efficient use of
! insn attributes.  Typically, insns are divided into “types” and an
! attribute, customarily called ‘type’, is used to represent this value.
  This attribute is normally used only to define the default value for
  other attributes.  An example will clarify this usage.
  
*************** changed, be set to agree with the result
*** 30816,30822 ****
  changed if the item previously set into the condition code has been
  modified.
  
!  Here is part of a sample 'md' file for such a machine:
  
       (define_attr "type" "load,store,arith,fp,branch" (const_string "arith"))
  
--- 30815,30821 ----
  changed if the item previously set into the condition code has been
  modified.
  
!  Here is part of a sample ‘md’ file for such a machine:
  
       (define_attr "type" "load,store,arith,fp,branch" (const_string "arith"))
  
*************** File: gccint.info,  Node: Insn Lengths,
*** 30855,30904 ****
  For many machines, multiple types of branch instructions are provided,
  each for different length branch displacements.  In most cases, the
  assembler will choose the correct instruction to use.  However, when the
! assembler cannot do so, GCC can when a special attribute, the 'length'
  attribute, is defined.  This attribute must be defined to have numeric
! values by specifying a null string in its 'define_attr'.
  
!  In the case of the 'length' attribute, two additional forms of
  arithmetic terms are allowed in test expressions:
  
! '(match_dup N)'
       This refers to the address of operand N of the current insn, which
!      must be a 'label_ref'.
  
! '(pc)'
       For non-branch instructions and backward branch instructions, this
       refers to the address of the current insn.  But for forward branch
       instructions, this refers to the address of the next insn, because
       the length of the current insn is to be computed.
  
   For normal insns, the length will be determined by value of the
! 'length' attribute.  In the case of 'addr_vec' and 'addr_diff_vec' insn
  patterns, the length is computed as the number of vectors multiplied by
  the size of each vector.
  
   Lengths are measured in addressable storage units (bytes).
  
!  Note that it is possible to call functions via the 'symbol_ref'
  mechanism to compute the length of an insn.  However, if you use this
  mechanism you must provide dummy clauses to express the maximum length
  without using the function call.  You can see an example of this in the
! 'pa' machine description for the 'call_symref' pattern.
  
   The following macros can be used to refine the length computation:
  
! 'ADJUST_INSN_LENGTH (INSN, LENGTH)'
       If defined, modifies the length assigned to instruction INSN as a
       function of the context in which it is used.  LENGTH is an lvalue
       that contains the initially computed length of the insn and should
       be updated with the correct length of the insn.
  
       This macro will normally not be required.  A case in which it is
!      required is the ROMP.  On this machine, the size of an 'addr_vec'
       insn must be increased by two to compensate for the fact that
       alignment may be required.
  
!  The routine that returns 'get_attr_length' (the value of the 'length'
  attribute) can be used by the output routine to determine the form of
  the branch instruction to be written, as the example below illustrates.
  
--- 30854,30903 ----
  For many machines, multiple types of branch instructions are provided,
  each for different length branch displacements.  In most cases, the
  assembler will choose the correct instruction to use.  However, when the
! assembler cannot do so, GCC can when a special attribute, the ‘length’
  attribute, is defined.  This attribute must be defined to have numeric
! values by specifying a null string in its ‘define_attr’.
  
!  In the case of the ‘length’ attribute, two additional forms of
  arithmetic terms are allowed in test expressions:
  
! ‘(match_dup N)’
       This refers to the address of operand N of the current insn, which
!      must be a ‘label_ref’.
  
! ‘(pc)’
       For non-branch instructions and backward branch instructions, this
       refers to the address of the current insn.  But for forward branch
       instructions, this refers to the address of the next insn, because
       the length of the current insn is to be computed.
  
   For normal insns, the length will be determined by value of the
! ‘length’ attribute.  In the case of ‘addr_vec’ and ‘addr_diff_vec’ insn
  patterns, the length is computed as the number of vectors multiplied by
  the size of each vector.
  
   Lengths are measured in addressable storage units (bytes).
  
!  Note that it is possible to call functions via the ‘symbol_ref’
  mechanism to compute the length of an insn.  However, if you use this
  mechanism you must provide dummy clauses to express the maximum length
  without using the function call.  You can see an example of this in the
! ‘pa’ machine description for the ‘call_symref’ pattern.
  
   The following macros can be used to refine the length computation:
  
! ‘ADJUST_INSN_LENGTH (INSN, LENGTH)’
       If defined, modifies the length assigned to instruction INSN as a
       function of the context in which it is used.  LENGTH is an lvalue
       that contains the initially computed length of the insn and should
       be updated with the correct length of the insn.
  
       This macro will normally not be required.  A case in which it is
!      required is the ROMP.  On this machine, the size of an ‘addr_vec’
       insn must be increased by two to compensate for the fact that
       alignment may be required.
  
!  The routine that returns ‘get_attr_length’ (the value of the ‘length’
  attribute) can be used by the output routine to determine the form of
  the branch instruction to be written, as the example below illustrates.
  
*************** File: gccint.info,  Node: Constant Attri
*** 30931,30938 ****
  17.19.6 Constant Attributes
  ---------------------------
  
! A special form of 'define_attr', where the expression for the default
! value is a 'const' expression, indicates an attribute that is constant
  for a given run of the compiler.  Constant attributes may be used to
  specify which variety of processor is used.  For example,
  
--- 30930,30937 ----
  17.19.6 Constant Attributes
  ---------------------------
  
! A special form of ‘define_attr’, where the expression for the default
! value is a ‘const’ expression, indicates an attribute that is constant
  for a given run of the compiler.  Constant attributes may be used to
  specify which variety of processor is used.  For example,
  
*************** specify which variety of processor is us
*** 30950,30957 ****
  
   The routine generated for constant attributes has no parameters as it
  does not depend on any particular insn.  RTL expressions used to define
! the value of a constant attribute may use the 'symbol_ref' form, but may
! not use either the 'match_operand' form or 'eq_attr' forms involving
  insn attributes.
  
  
--- 30949,30956 ----
  
   The routine generated for constant attributes has no parameters as it
  does not depend on any particular insn.  RTL expressions used to define
! the value of a constant attribute may use the ‘symbol_ref’ form, but may
! not use either the ‘match_operand’ form or ‘eq_attr’ forms involving
  insn attributes.
  
  
*************** File: gccint.info,  Node: Mnemonic Attri
*** 30960,30966 ****
  17.19.7 Mnemonic Attribute
  --------------------------
  
! The 'mnemonic' attribute is a string type attribute holding the
  instruction mnemonic for an insn alternative.  The attribute values will
  automatically be generated by the machine description parser if there is
  an attribute definition in the md file:
--- 30959,30965 ----
  17.19.7 Mnemonic Attribute
  --------------------------
  
! The ‘mnemonic’ attribute is a string type attribute holding the
  instruction mnemonic for an insn alternative.  The attribute values will
  automatically be generated by the machine description parser if there is
  an attribute definition in the md file:
*************** an attribute definition in the md file:
*** 30971,30987 ****
  with any of the instruction mnemonics.  This value will be used whenever
  the machine description parser is not able to determine the mnemonic
  string.  This might be the case for output templates containing more
! than a single instruction as in '"mvcle\t%0,%1,0\;jo\t.-4"'.
  
!  The 'mnemonic' attribute set is not generated automatically if the
  instruction string is generated via C code.
  
!  An existing 'mnemonic' attribute set in an insn definition will not be
  overriden by the md file parser.  That way it is possible to manually
  set the instruction mnemonics for the cases where the md file parser
  fails to determine it automatically.
  
!  The 'mnemonic' attribute is useful for dealing with instruction
  specific properties in the pipeline description without defining
  additional insn attributes.
  
--- 30970,30986 ----
  with any of the instruction mnemonics.  This value will be used whenever
  the machine description parser is not able to determine the mnemonic
  string.  This might be the case for output templates containing more
! than a single instruction as in ‘"mvcle\t%0,%1,0\;jo\t.-4"’.
  
!  The ‘mnemonic’ attribute set is not generated automatically if the
  instruction string is generated via C code.
  
!  An existing ‘mnemonic’ attribute set in an insn definition will not be
  overriden by the md file parser.  That way it is possible to manually
  set the instruction mnemonics for the cases where the md file parser
  fails to determine it automatically.
  
!  The ‘mnemonic’ attribute is useful for dealing with instruction
  specific properties in the pipeline description without defining
  additional insn attributes.
  
*************** File: gccint.info,  Node: Delay Slots,
*** 30998,31010 ****
  
  The insn attribute mechanism can be used to specify the requirements for
  delay slots, if any, on a target machine.  An instruction is said to
! require a "delay slot" if some instructions that are physically after
  the instruction are executed as if they were located before it.  Classic
  examples are branch and call instructions, which often execute the
  following instruction before the branch or call is performed.
  
   On some machines, conditional branch instructions can optionally
! "annul" instructions in the delay slot.  This means that the instruction
  will not be executed for certain branch outcomes.  Both instructions
  that annul if the branch is true and instructions that annul if the
  branch is false are supported.
--- 30997,31009 ----
  
  The insn attribute mechanism can be used to specify the requirements for
  delay slots, if any, on a target machine.  An instruction is said to
! require a “delay slot” if some instructions that are physically after
  the instruction are executed as if they were located before it.  Classic
  examples are branch and call instructions, which often execute the
  following instruction before the branch or call is performed.
  
   On some machines, conditional branch instructions can optionally
! “annul” instructions in the delay slot.  This means that the instruction
  will not be executed for certain branch outcomes.  Both instructions
  that annul if the branch is true and instructions that annul if the
  branch is false are supported.
*************** instructions.  See the next section for
*** 31016,31048 ****
  instruction scheduling.
  
   The requirement of an insn needing one or more delay slots is indicated
! via the 'define_delay' expression.  It has the following form:
  
       (define_delay TEST
                     [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
                      DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
                      ...])
  
!  TEST is an attribute test that indicates whether this 'define_delay'
  applies to a particular insn.  If so, the number of required delay slots
  is determined by the length of the vector specified as the second
  argument.  An insn placed in delay slot N must satisfy attribute test
  DELAY-N.  ANNUL-TRUE-N is an attribute test that specifies which insns
  may be annulled if the branch is true.  Similarly, ANNUL-FALSE-N
  specifies which insns in the delay slot may be annulled if the branch is
! false.  If annulling is not supported for that delay slot, '(nil)'
  should be coded.
  
   For example, in the common case where branch and call insns require a
  single delay slot, which may contain any insn other than a branch or
! call, the following would be placed in the 'md' file:
  
       (define_delay (eq_attr "type" "branch,call")
                     [(eq_attr "type" "!branch,call") (nil) (nil)])
  
!  Multiple 'define_delay' expressions may be specified.  In this case,
  each such expression specifies different delay slot requirements and
! there must be no insn for which tests in two 'define_delay' expressions
  are both true.
  
   For example, if we have a machine that requires one delay slot for
--- 31015,31047 ----
  instruction scheduling.
  
   The requirement of an insn needing one or more delay slots is indicated
! via the ‘define_delay’ expression.  It has the following form:
  
       (define_delay TEST
                     [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
                      DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
                      ...])
  
!  TEST is an attribute test that indicates whether this ‘define_delay’
  applies to a particular insn.  If so, the number of required delay slots
  is determined by the length of the vector specified as the second
  argument.  An insn placed in delay slot N must satisfy attribute test
  DELAY-N.  ANNUL-TRUE-N is an attribute test that specifies which insns
  may be annulled if the branch is true.  Similarly, ANNUL-FALSE-N
  specifies which insns in the delay slot may be annulled if the branch is
! false.  If annulling is not supported for that delay slot, ‘(nil)’
  should be coded.
  
   For example, in the common case where branch and call insns require a
  single delay slot, which may contain any insn other than a branch or
! call, the following would be placed in the ‘md’ file:
  
       (define_delay (eq_attr "type" "branch,call")
                     [(eq_attr "type" "!branch,call") (nil) (nil)])
  
!  Multiple ‘define_delay’ expressions may be specified.  In this case,
  each such expression specifies different delay slot requirements and
! there must be no insn for which tests in two ‘define_delay’ expressions
  are both true.
  
   For example, if we have a machine that requires one delay slot for
*************** File: gccint.info,  Node: Processor pipe
*** 31066,31082 ****
  -------------------------------------------------
  
  To achieve better performance, most modern processors (super-pipelined,
! superscalar RISC, and VLIW processors) have many "functional units" on
  which several instructions can be executed simultaneously.  An
  instruction starts execution if its issue conditions are satisfied.  If
  not, the instruction is stalled until its conditions are satisfied.
! Such "interlock (pipeline) delay" causes interruption of the fetching of
  successor instructions (or demands nop instructions, e.g. for some MIPS
  processors).
  
   There are two major kinds of interlock delays in modern processors.
! The first one is a data dependence delay determining "instruction
! latency time".  The instruction execution is not started until all
  source data have been evaluated by prior instructions (there are more
  complex cases when the instruction execution starts even when the data
  are not available but will be ready in given time after the instruction
--- 31065,31081 ----
  -------------------------------------------------
  
  To achieve better performance, most modern processors (super-pipelined,
! superscalar RISC, and VLIW processors) have many “functional units” on
  which several instructions can be executed simultaneously.  An
  instruction starts execution if its issue conditions are satisfied.  If
  not, the instruction is stalled until its conditions are satisfied.
! Such “interlock (pipeline) delay” causes interruption of the fetching of
  successor instructions (or demands nop instructions, e.g. for some MIPS
  processors).
  
   There are two major kinds of interlock delays in modern processors.
! The first one is a data dependence delay determining “instruction
! latency time”.  The instruction execution is not started until all
  source data have been evaluated by prior instructions (there are more
  complex cases when the instruction execution starts even when the data
  are not available but will be ready in given time after the instruction
*************** especially for modern RISC processors.
*** 31093,31104 ****
   The task of exploiting more processor parallelism is solved by an
  instruction scheduler.  For a better solution to this problem, the
  instruction scheduler has to have an adequate description of the
! processor parallelism (or "pipeline description").  GCC machine
  descriptions describe processor parallelism and functional unit
! reservations for groups of instructions with the aid of "regular
! expressions".
  
!  The GCC instruction scheduler uses a "pipeline hazard recognizer" to
  figure out the possibility of the instruction issue by the processor on
  a given simulated processor cycle.  The pipeline hazard recognizer is
  automatically generated from the processor pipeline description.  The
--- 31092,31103 ----
   The task of exploiting more processor parallelism is solved by an
  instruction scheduler.  For a better solution to this problem, the
  instruction scheduler has to have an adequate description of the
! processor parallelism (or “pipeline description”).  GCC machine
  descriptions describe processor parallelism and functional unit
! reservations for groups of instructions with the aid of “regular
! expressions”.
  
!  The GCC instruction scheduler uses a “pipeline hazard recognizer” to
  figure out the possibility of the instruction issue by the processor on
  a given simulated processor cycle.  The pipeline hazard recognizer is
  automatically generated from the processor pipeline description.  The
*************** only one finite state automaton is gener
*** 31124,31131 ****
  
   AUTOMATA-NAMES is a string giving names of the automata.  The names are
  separated by commas.  All the automata should have unique names.  The
! automaton name is used in the constructions 'define_cpu_unit' and
! 'define_query_cpu_unit'.
  
   Each processor functional unit used in the description of instruction
  reservations should be described by the following construction.
--- 31123,31130 ----
  
   AUTOMATA-NAMES is a string giving names of the automata.  The names are
  separated by commas.  All the automata should have unique names.  The
! automaton name is used in the constructions ‘define_cpu_unit’ and
! ‘define_query_cpu_unit’.
  
   Each processor functional unit used in the description of instruction
  reservations should be described by the following construction.
*************** reservations should be described by the
*** 31133,31144 ****
       (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
  
   UNIT-NAMES is a string giving the names of the functional units
! separated by commas.  Don't use name 'nothing', it is reserved for other
  goals.
  
   AUTOMATON-NAME is a string giving the name of the automaton with which
  the unit is bound.  The automaton should be described in construction
! 'define_automaton'.  You should give "automaton-name", if there is a
  defined automaton.
  
   The assignment of units to automata are constrained by the uses of the
--- 31132,31143 ----
       (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
  
   UNIT-NAMES is a string giving the names of the functional units
! separated by commas.  Don't use name ‘nothing’, it is reserved for other
  goals.
  
   AUTOMATON-NAME is a string giving the name of the automaton with which
  the unit is bound.  The automaton should be described in construction
! ‘define_automaton’.  You should give “automaton-name”, if there is a
  defined automaton.
  
   The assignment of units to automata are constrained by the uses of the
*************** The rest of the constraints are mentione
*** 31150,31156 ****
  subsequent constructions.
  
   The following construction describes CPU functional units analogously
! to 'define_cpu_unit'.  The reservation of such units can be queried for
  an automaton state.  The instruction scheduler never queries reservation
  of functional units for given automaton state.  So as a rule, you don't
  need this construction.  This construction could be used for future code
--- 31149,31155 ----
  subsequent constructions.
  
   The following construction describes CPU functional units analogously
! to ‘define_cpu_unit’.  The reservation of such units can be queried for
  an automaton state.  The instruction scheduler never queries reservation
  of functional units for given automaton state.  So as a rule, you don't
  need this construction.  This construction could be used for future code
*************** dependencies.  The cost of anti-dependen
*** 31179,31201 ****
  of output dependencies is the difference between latency times of the
  producing and consuming insns (if the difference is negative, the cost
  is considered to be zero).  You can always change the default costs for
! any description by using the target hook 'TARGET_SCHED_ADJUST_COST'
  (*note Scheduling::).
  
   INSN-NAME is a string giving the internal name of the insn.  The
! internal names are used in constructions 'define_bypass' and in the
  automaton description file generated for debugging.  The internal name
! has nothing in common with the names in 'define_insn'.  It is a good
  practice to use insn classes described in the processor manual.
  
   CONDITION defines what RTL insns are described by this construction.
  You should remember that you will be in trouble if CONDITION for two or
! more different 'define_insn_reservation' constructions is TRUE for an
  insn.  In this case what reservation will be used for the insn is not
  defined.  Such cases are not checked during generation of the pipeline
  hazards recognizer because in general recognizing that two conditions
  may have the same value is quite difficult (especially if the conditions
! contain 'symbol_ref').  It is also not checked during the pipeline
  hazard recognizer work because it would slow down the recognizer
  considerably.
  
--- 31178,31200 ----
  of output dependencies is the difference between latency times of the
  producing and consuming insns (if the difference is negative, the cost
  is considered to be zero).  You can always change the default costs for
! any description by using the target hook ‘TARGET_SCHED_ADJUST_COST’
  (*note Scheduling::).
  
   INSN-NAME is a string giving the internal name of the insn.  The
! internal names are used in constructions ‘define_bypass’ and in the
  automaton description file generated for debugging.  The internal name
! has nothing in common with the names in ‘define_insn’.  It is a good
  practice to use insn classes described in the processor manual.
  
   CONDITION defines what RTL insns are described by this construction.
  You should remember that you will be in trouble if CONDITION for two or
! more different ‘define_insn_reservation’ constructions is TRUE for an
  insn.  In this case what reservation will be used for the insn is not
  defined.  Such cases are not checked during generation of the pipeline
  hazards recognizer because in general recognizing that two conditions
  may have the same value is quite difficult (especially if the conditions
! contain ‘symbol_ref’).  It is also not checked during the pipeline
  hazard recognizer work because it would slow down the recognizer
  considerably.
  
*************** expression according to the following sy
*** 31221,31248 ****
                      | "nothing"
                      | "(" regexp ")"
  
!    * ',' is used for describing the start of the next cycle in the
       reservation.
  
!    * '|' is used for describing a reservation described by the first
       regular expression *or* a reservation described by the second
       regular expression *or* etc.
  
!    * '+' is used for describing a reservation described by the first
       regular expression *and* a reservation described by the second
       regular expression *and* etc.
  
!    * '*' is used for convenience and simply means a sequence in which
       the regular expression are repeated NUMBER times with cycle
!      advancing (see ',').
  
!    * 'cpu_function_unit_name' denotes reservation of the named
       functional unit.
  
!    * 'reservation_name' -- see description of construction
!      'define_reservation'.
  
!    * 'nothing' denotes no unit reservations.
  
   Sometimes unit reservations for different insns contain common parts.
  In such case, you can simplify the pipeline description by describing
--- 31220,31247 ----
                      | "nothing"
                      | "(" regexp ")"
  
!    • ‘,’ is used for describing the start of the next cycle in the
       reservation.
  
!    • ‘|’ is used for describing a reservation described by the first
       regular expression *or* a reservation described by the second
       regular expression *or* etc.
  
!    • ‘+’ is used for describing a reservation described by the first
       regular expression *and* a reservation described by the second
       regular expression *and* etc.
  
!    • ‘*’ is used for convenience and simply means a sequence in which
       the regular expression are repeated NUMBER times with cycle
!      advancing (see ‘,’).
  
!    • ‘cpu_function_unit_name’ denotes reservation of the named
       functional unit.
  
!    • ‘reservation_name’ -- see description of construction
!      ‘define_reservation’.
  
!    • ‘nothing’ denotes no unit reservations.
  
   Sometimes unit reservations for different insns contain common parts.
  In such case, you can simplify the pipeline description by describing
*************** the common part by the following constru
*** 31253,31259 ****
   RESERVATION-NAME is a string giving name of REGEXP.  Functional unit
  names and reservation names are in the same name space.  So the
  reservation names should be different from the functional unit names and
! cannot be the reserved name 'nothing'.
  
   The following construction is used to describe exceptions in the
  latency time for given instruction pair.  This is so called bypasses.
--- 31252,31258 ----
   RESERVATION-NAME is a string giving name of REGEXP.  Functional unit
  names and reservation names are in the same name space.  So the
  reservation names should be different from the functional unit names and
! cannot be the reserved name ‘nothing’.
  
   The following construction is used to describe exceptions in the
  latency time for given instruction pair.  This is so called bypasses.
*************** latency time for given instruction pair.
*** 31265,31281 ****
  string OUT_INSN_NAMES will be ready for the instructions given in string
  IN_INSN_NAMES.  Each of these strings is a comma-separated list of
  filename-style globs and they refer to the names of
! 'define_insn_reservation's.  For example:
       (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*")
!  defines a bypass between instructions that start with 'cpu1_load_' or
! 'cpu1_store_' and those that start with 'cpu1_load_'.
  
   GUARD is an optional string giving the name of a C function which
  defines an additional guard for the bypass.  The function will get the
  two insns as parameters.  If the function returns zero the bypass will
  be ignored for this case.  The additional guard is necessary to
  recognize complicated bypasses, e.g. when the consumer is only an
! address of insn 'store' (not a stored value).
  
   If there are more one bypass with the same output and input insns, the
  chosen bypass is the first bypass with a guard in description whose
--- 31264,31280 ----
  string OUT_INSN_NAMES will be ready for the instructions given in string
  IN_INSN_NAMES.  Each of these strings is a comma-separated list of
  filename-style globs and they refer to the names of
! ‘define_insn_reservation’s.  For example:
       (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*")
!  defines a bypass between instructions that start with ‘cpu1_load_’ or
! ‘cpu1_store_’ and those that start with ‘cpu1_load_’.
  
   GUARD is an optional string giving the name of a C function which
  defines an additional guard for the bypass.  The function will get the
  two insns as parameters.  If the function returns zero the bypass will
  be ignored for this case.  The additional guard is necessary to
  recognize complicated bypasses, e.g. when the consumer is only an
! address of insn ‘store’ (not a stored value).
  
   If there are more one bypass with the same output and input insns, the
  chosen bypass is the first bypass with a guard in description whose
*************** commas.
*** 31300,31306 ****
  comma.  Currently pattern is one unit or units separated by
  white-spaces.
  
!  The first construction ('exclusion_set') means that each functional
  unit in the first string cannot be reserved simultaneously with a unit
  whose name is in the second string and vice versa.  For example, the
  construction is useful for describing processors (e.g. some SPARC
--- 31299,31305 ----
  comma.  Currently pattern is one unit or units separated by
  white-spaces.
  
!  The first construction (‘exclusion_set’) means that each functional
  unit in the first string cannot be reserved simultaneously with a unit
  whose name is in the second string and vice versa.  For example, the
  construction is useful for describing processors (e.g. some SPARC
*************** processors) with a fully pipelined float
*** 31308,31367 ****
  can execute simultaneously only single floating point insns or only
  double floating point insns.
  
!  The second construction ('presence_set') means that each functional
  unit in the first string cannot be reserved unless at least one of
  pattern of units whose names are in the second string is reserved.  This
  is an asymmetric relation.  For example, it is useful for description
! that VLIW 'slot1' is reserved after 'slot0' reservation.  We could
  describe it by the following construction
  
       (presence_set "slot1" "slot0")
  
!  Or 'slot1' is reserved only after 'slot0' and unit 'b0' reservation.
  In this case we could write
  
       (presence_set "slot1" "slot0 b0")
  
!  The third construction ('final_presence_set') is analogous to
! 'presence_set'.  The difference between them is when checking is done.
  When an instruction is issued in given automaton state reflecting all
  current and planned unit reservations, the automaton state is changed.
  The first state is a source state, the second one is a result state.
! Checking for 'presence_set' is done on the source state reservation,
! checking for 'final_presence_set' is done on the result reservation.
  This construction is useful to describe a reservation which is actually
  two subsequent reservations.  For example, if we use
  
       (presence_set "slot1" "slot0")
  
!  the following insn will be never issued (because 'slot1' requires
! 'slot0' which is absent in the source state).
  
       (define_reservation "insn_and_nop" "slot0 + slot1")
  
!  but it can be issued if we use analogous 'final_presence_set'.
  
!  The forth construction ('absence_set') means that each functional unit
  in the first string can be reserved only if each pattern of units whose
  names are in the second string is not reserved.  This is an asymmetric
! relation (actually 'exclusion_set' is analogous to this one but it is
  symmetric).  For example it might be useful in a VLIW description to say
! that 'slot0' cannot be reserved after either 'slot1' or 'slot2' have
  been reserved.  This can be described as:
  
       (absence_set "slot0" "slot1, slot2")
  
!  Or 'slot2' cannot be reserved if 'slot0' and unit 'b0' are reserved or
! 'slot1' and unit 'b1' are reserved.  In this case we could write
  
       (absence_set "slot2" "slot0 b0, slot1 b1")
  
   All functional units mentioned in a set should belong to the same
  automaton.
  
!  The last construction ('final_absence_set') is analogous to
! 'absence_set' but checking is done on the result (state) reservation.
! See comments for 'final_presence_set'.
  
   You can control the generator of the pipeline hazard recognizer with
  the following construction.
--- 31307,31366 ----
  can execute simultaneously only single floating point insns or only
  double floating point insns.
  
!  The second construction (‘presence_set’) means that each functional
  unit in the first string cannot be reserved unless at least one of
  pattern of units whose names are in the second string is reserved.  This
  is an asymmetric relation.  For example, it is useful for description
! that VLIW ‘slot1’ is reserved after ‘slot0’ reservation.  We could
  describe it by the following construction
  
       (presence_set "slot1" "slot0")
  
!  Or ‘slot1’ is reserved only after ‘slot0’ and unit ‘b0’ reservation.
  In this case we could write
  
       (presence_set "slot1" "slot0 b0")
  
!  The third construction (‘final_presence_set’) is analogous to
! ‘presence_set’.  The difference between them is when checking is done.
  When an instruction is issued in given automaton state reflecting all
  current and planned unit reservations, the automaton state is changed.
  The first state is a source state, the second one is a result state.
! Checking for ‘presence_set’ is done on the source state reservation,
! checking for ‘final_presence_set’ is done on the result reservation.
  This construction is useful to describe a reservation which is actually
  two subsequent reservations.  For example, if we use
  
       (presence_set "slot1" "slot0")
  
!  the following insn will be never issued (because ‘slot1’ requires
! ‘slot0’ which is absent in the source state).
  
       (define_reservation "insn_and_nop" "slot0 + slot1")
  
!  but it can be issued if we use analogous ‘final_presence_set’.
  
!  The forth construction (‘absence_set’) means that each functional unit
  in the first string can be reserved only if each pattern of units whose
  names are in the second string is not reserved.  This is an asymmetric
! relation (actually ‘exclusion_set’ is analogous to this one but it is
  symmetric).  For example it might be useful in a VLIW description to say
! that ‘slot0’ cannot be reserved after either ‘slot1’ or ‘slot2’ have
  been reserved.  This can be described as:
  
       (absence_set "slot0" "slot1, slot2")
  
!  Or ‘slot2’ cannot be reserved if ‘slot0’ and unit ‘b0’ are reserved or
! ‘slot1’ and unit ‘b1’ are reserved.  In this case we could write
  
       (absence_set "slot2" "slot0 b0, slot1 b1")
  
   All functional units mentioned in a set should belong to the same
  automaton.
  
!  The last construction (‘final_absence_set’) is analogous to
! ‘absence_set’ but checking is done on the result (state) reservation.
! See comments for ‘final_presence_set’.
  
   You can control the generator of the pipeline hazard recognizer with
  the following construction.
*************** the following construction.
*** 31371,31417 ****
   OPTIONS is a string giving options which affect the generated code.
  Currently there are the following options:
  
!    * "no-minimization" makes no minimization of the automaton.  This is
       only worth to do when we are debugging the description and need to
       look more accurately at reservations of states.
  
!    * "time" means printing time statistics about the generation of
       automata.
  
!    * "stats" means printing statistics about the generated automata such
       as the number of DFA states, NDFA states and arcs.
  
!    * "v" means a generation of the file describing the result automata.
!      The file has suffix '.dfa' and can be used for the description
       verification and debugging.
  
!    * "w" means a generation of warning instead of error for non-critical
       errors.
  
!    * "no-comb-vect" prevents the automaton generator from generating two
       data structures and comparing them for space efficiency.  Using a
       comb vector to represent transitions may be better, but it can be
       very expensive to construct.  This option is useful if the build
       process spends an unacceptably long time in genautomata.
  
!    * "ndfa" makes nondeterministic finite state automata.  This affects
!      the treatment of operator '|' in the regular expressions.  The
       usual treatment of the operator is to try the first alternative
       and, if the reservation is not possible, the second alternative.
       The nondeterministic treatment means trying all alternatives, some
       of them may be rejected by reservations in the subsequent insns.
  
!    * "collapse-ndfa" modifies the behavior of the generator when
       producing an automaton.  An additional state transition to collapse
       a nondeterministic NDFA state to a deterministic DFA state is
!      generated.  It can be triggered by passing 'const0_rtx' to
       state_transition.  In such an automaton, cycle advance transitions
       are available only for these collapsed states.  This option is
!      useful for ports that want to use the 'ndfa' option, but also want
!      to use 'define_query_cpu_unit' to assign units to insns issued in a
       cycle.
  
!    * "progress" means output of a progress bar showing how many states
       were generated so far for automaton being processed.  This is
       useful during debugging a DFA description.  If you see too many
       generated states, you could interrupt the generator of the pipeline
--- 31370,31416 ----
   OPTIONS is a string giving options which affect the generated code.
  Currently there are the following options:
  
!    • “no-minimization” makes no minimization of the automaton.  This is
       only worth to do when we are debugging the description and need to
       look more accurately at reservations of states.
  
!    • “time” means printing time statistics about the generation of
       automata.
  
!    • “stats” means printing statistics about the generated automata such
       as the number of DFA states, NDFA states and arcs.
  
!    • “v” means a generation of the file describing the result automata.
!      The file has suffix ‘.dfa’ and can be used for the description
       verification and debugging.
  
!    • “w” means a generation of warning instead of error for non-critical
       errors.
  
!    • “no-comb-vect” prevents the automaton generator from generating two
       data structures and comparing them for space efficiency.  Using a
       comb vector to represent transitions may be better, but it can be
       very expensive to construct.  This option is useful if the build
       process spends an unacceptably long time in genautomata.
  
!    • “ndfa” makes nondeterministic finite state automata.  This affects
!      the treatment of operator ‘|’ in the regular expressions.  The
       usual treatment of the operator is to try the first alternative
       and, if the reservation is not possible, the second alternative.
       The nondeterministic treatment means trying all alternatives, some
       of them may be rejected by reservations in the subsequent insns.
  
!    • “collapse-ndfa” modifies the behavior of the generator when
       producing an automaton.  An additional state transition to collapse
       a nondeterministic NDFA state to a deterministic DFA state is
!      generated.  It can be triggered by passing ‘const0_rtx’ to
       state_transition.  In such an automaton, cycle advance transitions
       are available only for these collapsed states.  This option is
!      useful for ports that want to use the ‘ndfa’ option, but also want
!      to use ‘define_query_cpu_unit’ to assign units to insns issued in a
       cycle.
  
!    • “progress” means output of a progress bar showing how many states
       were generated so far for automaton being processed.  This is
       useful during debugging a DFA description.  If you see too many
       generated states, you could interrupt the generator of the pipeline
*************** could specify
*** 31459,31465 ****
  
       (define_reservation "finish" "port0|port1")
  
!  and use it in all 'define_insn_reservation' as in the following
  construction
  
       (define_insn_reservation "simple" 2 (eq_attr "type" "int")
--- 31458,31464 ----
  
       (define_reservation "finish" "port0|port1")
  
!  and use it in all ‘define_insn_reservation’ as in the following
  construction
  
       (define_insn_reservation "simple" 2 (eq_attr "type" "int")
*************** A number of architectures provide for so
*** 31483,31490 ****
  execution, or predication.  The hallmark of this feature is the ability
  to nullify most of the instructions in the instruction set.  When the
  instruction set is large and not entirely symmetric, it can be quite
! tedious to describe these forms directly in the '.md' file.  An
! alternative is the 'define_cond_exec' template.
  
       (define_cond_exec
         [PREDICATE-PATTERN]
--- 31482,31489 ----
  execution, or predication.  The hallmark of this feature is the ability
  to nullify most of the instructions in the instruction set.  When the
  instruction set is large and not entirely symmetric, it can be quite
! tedious to describe these forms directly in the ‘.md’ file.  An
! alternative is the ‘define_cond_exec’ template.
  
       (define_cond_exec
         [PREDICATE-PATTERN]
*************** alternative is the 'define_cond_exec' te
*** 31494,31512 ****
  
   PREDICATE-PATTERN is the condition that must be true for the insn to be
  executed at runtime and should match a relational operator.  One can use
! 'match_operator' to match several relational operators at once.  Any
! 'match_operand' operands must have no more than one alternative.
  
   CONDITION is a C expression that must be true for the generated pattern
  to match.
  
!  OUTPUT-TEMPLATE is a string similar to the 'define_insn' output
! template (*note Output Template::), except that the '*' and '@' special
  cases do not apply.  This is only useful if the assembly text for the
  predicate is a simple prefix to the main insn.  In order to handle the
! general case, there is a global variable 'current_insn_predicate' that
  will contain the entire predicate if the current insn is predicated, and
! will otherwise be 'NULL'.
  
   OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets
  appended to the insn attributes of the produced cond_exec rtx.  It can
--- 31493,31511 ----
  
   PREDICATE-PATTERN is the condition that must be true for the insn to be
  executed at runtime and should match a relational operator.  One can use
! ‘match_operator’ to match several relational operators at once.  Any
! ‘match_operand’ operands must have no more than one alternative.
  
   CONDITION is a C expression that must be true for the generated pattern
  to match.
  
!  OUTPUT-TEMPLATE is a string similar to the ‘define_insn’ output
! template (*note Output Template::), except that the ‘*’ and ‘@’ special
  cases do not apply.  This is only useful if the assembly text for the
  predicate is a simple prefix to the main insn.  In order to handle the
! general case, there is a global variable ‘current_insn_predicate’ that
  will contain the entire predicate if the current insn is predicated, and
! will otherwise be ‘NULL’.
  
   OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets
  appended to the insn attributes of the produced cond_exec rtx.  It can
*************** that way.  An example usage would be to
*** 31515,31533 ****
  conjunction with attributes on the main pattern to disable particular
  alternatives under certain conditions.
  
!  When 'define_cond_exec' is used, an implicit reference to the
! 'predicable' instruction attribute is made.  *Note Insn Attributes::.
  This attribute must be a boolean (i.e. have exactly two elements in its
! LIST-OF-VALUES), with the possible values being 'no' and 'yes'.  The
  default and all uses in the insns must be a simple constant, not a
  complex expressions.  It may, however, depend on the alternative, by
  using a comma-separated list of values.  If that is the case, the port
! should also define an 'enabled' attribute (*note Disable Insn
! Alternatives::), which should also allow only 'no' and 'yes' as its
  values.
  
!  For each 'define_insn' for which the 'predicable' attribute is true, a
! new 'define_insn' pattern will be generated that matches a predicated
  version of the instruction.  For example,
  
       (define_insn "addsi"
--- 31514,31532 ----
  conjunction with attributes on the main pattern to disable particular
  alternatives under certain conditions.
  
!  When ‘define_cond_exec’ is used, an implicit reference to the
! ‘predicable’ instruction attribute is made.  *Note Insn Attributes::.
  This attribute must be a boolean (i.e. have exactly two elements in its
! LIST-OF-VALUES), with the possible values being ‘no’ and ‘yes’.  The
  default and all uses in the insns must be a simple constant, not a
  complex expressions.  It may, however, depend on the alternative, by
  using a comma-separated list of values.  If that is the case, the port
! should also define an ‘enabled’ attribute (*note Disable Insn
! Alternatives::), which should also allow only ‘no’ and ‘yes’ as its
  values.
  
!  For each ‘define_insn’ for which the ‘predicable’ attribute is true, a
! new ‘define_insn’ pattern will be generated that matches a predicated
  version of the instruction.  For example,
  
       (define_insn "addsi"
*************** File: gccint.info,  Node: Define Subst,
*** 31562,31570 ****
  
  For some hardware architectures there are common cases when the RTL
  templates for the instructions can be derived from the other RTL
! templates using simple transformations.  E.g., 'i386.md' contains an RTL
! template for the ordinary 'sub' instruction-- '*subsi_1', and for the
! 'sub' instruction with subsequent zero-extension--'*subsi_1_zext'.  Such
  cases can be easily implemented by a single meta-template capable of
  generating a modified case based on the initial one:
  
--- 31561,31569 ----
  
  For some hardware architectures there are common cases when the RTL
  templates for the instructions can be derived from the other RTL
! templates using simple transformations.  E.g., ‘i386.md’ contains an RTL
! template for the ordinary ‘sub’ instruction-- ‘*subsi_1’, and for the
! ‘sub’ instruction with subsequent zero-extension--‘*subsi_1_zext’.  Such
  cases can be easily implemented by a single meta-template capable of
  generating a modified case based on the initial one:
  
*************** output-template.
*** 31582,31619 ****
   OUTPUT-TEMPLATE is a pattern that will be used in the resulting
  template.
  
!  'define_subst' mechanism is tightly coupled with the notion of the
! subst attribute (*note Subst Iterators::).  The use of 'define_subst' is
  triggered by a reference to a subst attribute in the transforming RTL
  template.  This reference initiates duplication of the source RTL
  template and substitution of the attributes with their values.  The
  source RTL template is left unchanged, while the copy is transformed by
! 'define_subst'.  This transformation can fail in the case when the
  source RTL template is not matched against the input-template of the
! 'define_subst'.  In such case the copy is deleted.
  
!  'define_subst' can be used only in 'define_insn' and 'define_expand',
  it cannot be used in other expressions (e.g. in
! 'define_insn_and_split').
  
  * Menu:
  
! * Define Subst Example::	    Example of 'define_subst' work.
  * Define Subst Pattern Matching::   Process of template comparison.
  * Define Subst Output Template::    Generation of output template.
  
  
  File: gccint.info,  Node: Define Subst Example,  Next: Define Subst Pattern Matching,  Up: Define Subst
  
! 17.21.1 'define_subst' Example
  ------------------------------
  
! To illustrate how 'define_subst' works, let us examine a simple template
  transformation.
  
   Suppose there are two kinds of instructions: one that touches flags and
  the other that does not.  The instructions of the second type could be
! generated with the following 'define_subst':
  
       (define_subst "add_clobber_subst"
         [(set (match_operand:SI 0 "" "")
--- 31581,31618 ----
   OUTPUT-TEMPLATE is a pattern that will be used in the resulting
  template.
  
!  ‘define_subst’ mechanism is tightly coupled with the notion of the
! subst attribute (*note Subst Iterators::).  The use of ‘define_subst’ is
  triggered by a reference to a subst attribute in the transforming RTL
  template.  This reference initiates duplication of the source RTL
  template and substitution of the attributes with their values.  The
  source RTL template is left unchanged, while the copy is transformed by
! ‘define_subst’.  This transformation can fail in the case when the
  source RTL template is not matched against the input-template of the
! ‘define_subst’.  In such case the copy is deleted.
  
!  ‘define_subst’ can be used only in ‘define_insn’ and ‘define_expand’,
  it cannot be used in other expressions (e.g. in
! ‘define_insn_and_split’).
  
  * Menu:
  
! * Define Subst Example::	    Example of ‘define_subst’ work.
  * Define Subst Pattern Matching::   Process of template comparison.
  * Define Subst Output Template::    Generation of output template.
  
  
  File: gccint.info,  Node: Define Subst Example,  Next: Define Subst Pattern Matching,  Up: Define Subst
  
! 17.21.1 ‘define_subst’ Example
  ------------------------------
  
! To illustrate how ‘define_subst’ works, let us examine a simple template
  transformation.
  
   Suppose there are two kinds of instructions: one that touches flags and
  the other that does not.  The instructions of the second type could be
! generated with the following ‘define_subst’:
  
       (define_subst "add_clobber_subst"
         [(set (match_operand:SI 0 "" "")
*************** generated with the following 'define_sub
*** 31623,31633 ****
               (match_dup 1))
          (clobber (reg:CC FLAGS_REG))])
  
!  This 'define_subst' can be applied to any RTL pattern containing 'set'
  of mode SI and generates a copy with clobber when it is applied.
  
!  Assume there is an RTL template for a 'max' instruction to be used in
! 'define_subst' mentioned above:
  
       (define_insn "maxsi"
         [(set (match_operand:SI 0 "register_operand" "=r")
--- 31622,31632 ----
               (match_dup 1))
          (clobber (reg:CC FLAGS_REG))])
  
!  This ‘define_subst’ can be applied to any RTL pattern containing ‘set’
  of mode SI and generates a copy with clobber when it is applied.
  
!  Assume there is an RTL template for a ‘max’ instruction to be used in
! ‘define_subst’ mentioned above:
  
       (define_insn "maxsi"
         [(set (match_operand:SI 0 "register_operand" "=r")
*************** of mode SI and generates a copy with clo
*** 31638,31657 ****
         "max\t{%2, %1, %0|%0, %1, %2}"
        [...])
  
!  To mark the RTL template for 'define_subst' application,
  subst-attributes are used.  They should be declared in advance:
  
       (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber")
  
!  Here 'add_clobber_name' is the attribute name, 'add_clobber_subst' is
! the name of the corresponding 'define_subst', the third argument
! ('_noclobber') is the attribute value that would be substituted into the
  unchanged version of the source RTL template, and the last argument
! ('_clobber') is the value that would be substituted into the second,
  transformed, version of the RTL template.
  
   Once the subst-attribute has been defined, it should be used in RTL
! templates which need to be processed by the 'define_subst'.  So, the
  original RTL template should be changed:
  
       (define_insn "maxsi"
--- 31637,31656 ----
         "max\t{%2, %1, %0|%0, %1, %2}"
        [...])
  
!  To mark the RTL template for ‘define_subst’ application,
  subst-attributes are used.  They should be declared in advance:
  
       (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber")
  
!  Here ‘add_clobber_name’ is the attribute name, ‘add_clobber_subst’ is
! the name of the corresponding ‘define_subst’, the third argument
! (‘_noclobber’) is the attribute value that would be substituted into the
  unchanged version of the source RTL template, and the last argument
! (‘_clobber’) is the value that would be substituted into the second,
  transformed, version of the RTL template.
  
   Once the subst-attribute has been defined, it should be used in RTL
! templates which need to be processed by the ‘define_subst’.  So, the
  original RTL template should be changed:
  
       (define_insn "maxsi"
*************** original RTL template should be changed:
*** 31663,31669 ****
         "max\t{%2, %1, %0|%0, %1, %2}"
        [...])
  
!  The result of the 'define_subst' usage would look like the following:
  
       (define_insn "maxsi_noclobber"
         [(set (match_operand:SI 0 "register_operand" "=r")
--- 31662,31668 ----
         "max\t{%2, %1, %0|%0, %1, %2}"
        [...])
  
!  The result of the ‘define_subst’ usage would look like the following:
  
       (define_insn "maxsi_noclobber"
         [(set (match_operand:SI 0 "register_operand" "=r")
*************** original RTL template should be changed:
*** 31686,31755 ****
  
  File: gccint.info,  Node: Define Subst Pattern Matching,  Next: Define Subst Output Template,  Prev: Define Subst Example,  Up: Define Subst
  
! 17.21.2 Pattern Matching in 'define_subst'
  ------------------------------------------
  
! All expressions, allowed in 'define_insn' or 'define_expand', are
! allowed in the input-template of 'define_subst', except 'match_par_dup',
! 'match_scratch', 'match_parallel'.  The meanings of expressions in the
  input-template were changed:
  
!  'match_operand' matches any expression (possibly, a subtree in
! RTL-template), if modes of the 'match_operand' and this expression are
! the same, or mode of the 'match_operand' is 'VOIDmode', or this
! expression is 'match_dup', 'match_op_dup'.  If the expression is
! 'match_operand' too, and predicate of 'match_operand' from the input
  pattern is not empty, then the predicates are compared.  That can be
  used for more accurate filtering of accepted RTL-templates.
  
!  'match_operator' matches common operators (like 'plus', 'minus'),
! 'unspec', 'unspec_volatile' operators and 'match_operator's from the
! original pattern if the modes match and 'match_operator' from the input
  pattern has the same number of operands as the operator from the
  original pattern.
  
  
  File: gccint.info,  Node: Define Subst Output Template,  Prev: Define Subst Pattern Matching,  Up: Define Subst
  
! 17.21.3 Generation of output template in 'define_subst'
  -------------------------------------------------------
  
! If all necessary checks for 'define_subst' application pass, a new
  RTL-pattern, based on the output-template, is created to replace the old
  template.  Like in input-patterns, meanings of some RTL expressions are
! changed when they are used in output-patterns of a 'define_subst'.
! Thus, 'match_dup' is used for copying the whole expression from the
! original pattern, which matched corresponding 'match_operand' from the
  input pattern.
  
!  'match_dup N' is used in the output template to be replaced with the
! expression from the original pattern, which matched 'match_operand N'
! from the input pattern.  As a consequence, 'match_dup' cannot be used to
! point to 'match_operand's from the output pattern, it should always
! refer to a 'match_operand' from the input pattern.  If a 'match_dup N'
  occurs more than once in the output template, its first occurrence is
  replaced with the expression from the original pattern, and the
! subsequent expressions are replaced with 'match_dup N', i.e., a
  reference to the first expression.
  
   In the output template one can refer to the expressions from the
  original pattern and create new ones.  For instance, some operands could
! be added by means of standard 'match_operand'.
  
!  After replacing 'match_dup' with some RTL-subtree from the original
! pattern, it could happen that several 'match_operand's in the output
  pattern have the same indexes.  It is unknown, how many and what indexes
! would be used in the expression which would replace 'match_dup', so such
  conflicts in indexes are inevitable.  To overcome this issue,
! 'match_operands' and 'match_operators', which were introduced into the
! output pattern, are renumerated when all 'match_dup's are replaced.
  
!  Number of alternatives in 'match_operand's introduced into the output
! template 'M' could differ from the number of alternatives in the
! original pattern 'N', so in the resultant pattern there would be 'N*M'
  alternatives.  Thus, constraints from the original pattern would be
! duplicated 'N' times, constraints from the output pattern would be
! duplicated 'M' times, producing all possible combinations.
  
  
  File: gccint.info,  Node: Constant Definitions,  Next: Iterators,  Prev: Define Subst,  Up: Machine Desc
--- 31685,31754 ----
  
  File: gccint.info,  Node: Define Subst Pattern Matching,  Next: Define Subst Output Template,  Prev: Define Subst Example,  Up: Define Subst
  
! 17.21.2 Pattern Matching in ‘define_subst’
  ------------------------------------------
  
! All expressions, allowed in ‘define_insn’ or ‘define_expand’, are
! allowed in the input-template of ‘define_subst’, except ‘match_par_dup’,
! ‘match_scratch’, ‘match_parallel’.  The meanings of expressions in the
  input-template were changed:
  
!  ‘match_operand’ matches any expression (possibly, a subtree in
! RTL-template), if modes of the ‘match_operand’ and this expression are
! the same, or mode of the ‘match_operand’ is ‘VOIDmode’, or this
! expression is ‘match_dup’, ‘match_op_dup’.  If the expression is
! ‘match_operand’ too, and predicate of ‘match_operand’ from the input
  pattern is not empty, then the predicates are compared.  That can be
  used for more accurate filtering of accepted RTL-templates.
  
!  ‘match_operator’ matches common operators (like ‘plus’, ‘minus’),
! ‘unspec’, ‘unspec_volatile’ operators and ‘match_operator’s from the
! original pattern if the modes match and ‘match_operator’ from the input
  pattern has the same number of operands as the operator from the
  original pattern.
  
  
  File: gccint.info,  Node: Define Subst Output Template,  Prev: Define Subst Pattern Matching,  Up: Define Subst
  
! 17.21.3 Generation of output template in ‘define_subst’
  -------------------------------------------------------
  
! If all necessary checks for ‘define_subst’ application pass, a new
  RTL-pattern, based on the output-template, is created to replace the old
  template.  Like in input-patterns, meanings of some RTL expressions are
! changed when they are used in output-patterns of a ‘define_subst’.
! Thus, ‘match_dup’ is used for copying the whole expression from the
! original pattern, which matched corresponding ‘match_operand’ from the
  input pattern.
  
!  ‘match_dup N’ is used in the output template to be replaced with the
! expression from the original pattern, which matched ‘match_operand N’
! from the input pattern.  As a consequence, ‘match_dup’ cannot be used to
! point to ‘match_operand’s from the output pattern, it should always
! refer to a ‘match_operand’ from the input pattern.  If a ‘match_dup N’
  occurs more than once in the output template, its first occurrence is
  replaced with the expression from the original pattern, and the
! subsequent expressions are replaced with ‘match_dup N’, i.e., a
  reference to the first expression.
  
   In the output template one can refer to the expressions from the
  original pattern and create new ones.  For instance, some operands could
! be added by means of standard ‘match_operand’.
  
!  After replacing ‘match_dup’ with some RTL-subtree from the original
! pattern, it could happen that several ‘match_operand’s in the output
  pattern have the same indexes.  It is unknown, how many and what indexes
! would be used in the expression which would replace ‘match_dup’, so such
  conflicts in indexes are inevitable.  To overcome this issue,
! ‘match_operands’ and ‘match_operators’, which were introduced into the
! output pattern, are renumerated when all ‘match_dup’s are replaced.
  
!  Number of alternatives in ‘match_operand’s introduced into the output
! template ‘M’ could differ from the number of alternatives in the
! original pattern ‘N’, so in the resultant pattern there would be ‘N*M’
  alternatives.  Thus, constraints from the original pattern would be
! duplicated ‘N’ times, constraints from the output pattern would be
! duplicated ‘M’ times, producing all possible combinations.
  
  
  File: gccint.info,  Node: Constant Definitions,  Next: Iterators,  Prev: Define Subst,  Up: Machine Desc
*************** File: gccint.info,  Node: Constant Defin
*** 31760,31770 ****
  Using literal constants inside instruction patterns reduces legibility
  and can be a maintenance problem.
  
!  To overcome this problem, you may use the 'define_constants'
  expression.  It contains a vector of name-value pairs.  From that point
  on, wherever any of the names appears in the MD file, it is as if the
  corresponding value had been written instead.  You may use
! 'define_constants' multiple times; each appearance adds more constants
  to the table.  It is an error to redefine a constant with a different
  value.
  
--- 31759,31769 ----
  Using literal constants inside instruction patterns reduces legibility
  and can be a maintenance problem.
  
!  To overcome this problem, you may use the ‘define_constants’
  expression.  It contains a vector of name-value pairs.  From that point
  on, wherever any of the names appears in the MD file, it is as if the
  corresponding value had been written instead.  You may use
! ‘define_constants’ multiple times; each appearance adds more constants
  to the table.  It is an error to redefine a constant with a different
  value.
  
*************** value.
*** 31801,31807 ****
  in the insn-codes.h header file as #defines.
  
   You can also use the machine description file to define enumerations.
! Like the constants defined by 'define_constant', these enumerations are
  visible to both the machine description file and the main C code.
  
   The syntax is as follows:
--- 31800,31806 ----
  in the insn-codes.h header file as #defines.
  
   You can also use the machine description file to define enumerations.
! Like the constants defined by ‘define_constant’, these enumerations are
  visible to both the machine description file and the main C code.
  
   The syntax is as follows:
*************** visible to both the machine description
*** 31816,31822 ****
       ])
  
   This definition causes the equivalent of the following C code to appear
! in 'insn-constants.h':
  
       enum NAME {
         VALUE0 = 0,
--- 31815,31821 ----
       ])
  
   This definition causes the equivalent of the following C code to appear
! in ‘insn-constants.h’:
  
       enum NAME {
         VALUE0 = 0,
*************** like.  The above example is directly equ
*** 31846,31879 ****
       (define_c_enum "NAME" [VALUEN])
  
   Splitting the enumeration helps to improve the modularity of each
! individual '.md' file.  For example, if a port defines its
! synchronization instructions in a separate 'sync.md' file, it is
  convenient to define all synchronization-specific enumeration values in
! 'sync.md' rather than in the main '.md' file.
  
   Some enumeration names have special significance to GCC:
  
! 'unspecv'
!      If an enumeration called 'unspecv' is defined, GCC will use it when
!      printing out 'unspec_volatile' expressions.  For example:
  
            (define_c_enum "unspecv" [
              UNSPECV_BLOCKAGE
            ])
  
!      causes GCC to print '(unspec_volatile ... 0)' as:
  
            (unspec_volatile ... UNSPECV_BLOCKAGE)
  
! 'unspec'
!      If an enumeration called 'unspec' is defined, GCC will use it when
!      printing out 'unspec' expressions.  GCC will also use it when
!      printing out 'unspec_volatile' expressions unless an 'unspecv'
       enumeration is also defined.  You can therefore decide whether to
       keep separate enumerations for volatile and non-volatile
       expressions or whether to use the same enumeration for both.
  
!  Another way of defining an enumeration is to use 'define_enum':
  
       (define_enum "NAME" [
         VALUE0
--- 31845,31878 ----
       (define_c_enum "NAME" [VALUEN])
  
   Splitting the enumeration helps to improve the modularity of each
! individual ‘.md’ file.  For example, if a port defines its
! synchronization instructions in a separate ‘sync.md’ file, it is
  convenient to define all synchronization-specific enumeration values in
! ‘sync.md’ rather than in the main ‘.md’ file.
  
   Some enumeration names have special significance to GCC:
  
! ‘unspecv’
!      If an enumeration called ‘unspecv’ is defined, GCC will use it when
!      printing out ‘unspec_volatile’ expressions.  For example:
  
            (define_c_enum "unspecv" [
              UNSPECV_BLOCKAGE
            ])
  
!      causes GCC to print ‘(unspec_volatile ... 0)’ as:
  
            (unspec_volatile ... UNSPECV_BLOCKAGE)
  
! ‘unspec’
!      If an enumeration called ‘unspec’ is defined, GCC will use it when
!      printing out ‘unspec’ expressions.  GCC will also use it when
!      printing out ‘unspec_volatile’ expressions unless an ‘unspecv’
       enumeration is also defined.  You can therefore decide whether to
       keep separate enumerations for volatile and non-volatile
       expressions or whether to use the same enumeration for both.
  
!  Another way of defining an enumeration is to use ‘define_enum’:
  
       (define_enum "NAME" [
         VALUE0
*************** convenient to define all synchronization
*** 31892,31898 ****
       ])
  
   where CVALUEI is the capitalized form of VALUEI.  However, unlike
! 'define_c_enum', the enumerations defined by 'define_enum' can be used
  in attribute specifications (*note define_enum_attr::).
  
  
--- 31891,31897 ----
       ])
  
   where CVALUEI is the capitalized form of VALUEI.  However, unlike
! ‘define_c_enum’, the enumerations defined by ‘define_enum’ can be used
  in attribute specifications (*note define_enum_attr::).
  
  
*************** File: gccint.info,  Node: Mode Iterators
*** 31922,31938 ****
  Ports often need to define similar patterns for two or more different
  modes.  For example:
  
!    * If a processor has hardware support for both single and double
!      floating-point arithmetic, the 'SFmode' patterns tend to be very
!      similar to the 'DFmode' ones.
  
!    * If a port uses 'SImode' pointers in one configuration and 'DImode'
!      pointers in another, it will usually have very similar 'SImode' and
!      'DImode' patterns for manipulating pointers.
  
!  Mode iterators allow several patterns to be instantiated from one '.md'
  file template.  They can be used with any type of rtx-based construct,
! such as a 'define_insn', 'define_split', or 'define_peephole2'.
  
  * Menu:
  
--- 31921,31937 ----
  Ports often need to define similar patterns for two or more different
  modes.  For example:
  
!    • If a processor has hardware support for both single and double
!      floating-point arithmetic, the ‘SFmode’ patterns tend to be very
!      similar to the ‘DFmode’ ones.
  
!    • If a port uses ‘SImode’ pointers in one configuration and ‘DImode’
!      pointers in another, it will usually have very similar ‘SImode’ and
!      ‘DImode’ patterns for manipulating pointers.
  
!  Mode iterators allow several patterns to be instantiated from one ‘.md’
  file template.  They can be used with any type of rtx-based construct,
! such as a ‘define_insn’, ‘define_split’, or ‘define_peephole2’.
  
  * Menu:
  
*************** The syntax for defining a mode iterator
*** 31950,31978 ****
  
       (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")])
  
!  This allows subsequent '.md' file constructs to use the mode suffix
! ':NAME'.  Every construct that does so will be expanded N times, once
! with every use of ':NAME' replaced by ':MODE1', once with every use
! replaced by ':MODE2', and so on.  In the expansion for a particular
  MODEI, every C condition will also require that CONDI be true.
  
   For example:
  
       (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
  
!  defines a new mode suffix ':P'.  Every construct that uses ':P' will be
! expanded twice, once with every ':P' replaced by ':SI' and once with
! every ':P' replaced by ':DI'.  The ':SI' version will only apply if
! 'Pmode == SImode' and the ':DI' version will only apply if 'Pmode ==
! DImode'.
  
!  As with other '.md' conditions, an empty string is treated as "always
! true".  '(MODE "")' can also be abbreviated to 'MODE'.  For example:
  
       (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
  
!  means that the ':DI' expansion only applies if 'TARGET_64BIT' but that
! the ':SI' expansion has no such constraint.
  
   Iterators are applied in the order they are defined.  This can be
  significant if two iterators are used in a construct that requires
--- 31949,31977 ----
  
       (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")])
  
!  This allows subsequent ‘.md’ file constructs to use the mode suffix
! ‘:NAME’.  Every construct that does so will be expanded N times, once
! with every use of ‘:NAME’ replaced by ‘:MODE1’, once with every use
! replaced by ‘:MODE2’, and so on.  In the expansion for a particular
  MODEI, every C condition will also require that CONDI be true.
  
   For example:
  
       (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
  
!  defines a new mode suffix ‘:P’.  Every construct that uses ‘:P’ will be
! expanded twice, once with every ‘:P’ replaced by ‘:SI’ and once with
! every ‘:P’ replaced by ‘:DI’.  The ‘:SI’ version will only apply if
! ‘Pmode == SImode’ and the ‘:DI’ version will only apply if ‘Pmode ==
! DImode’.
  
!  As with other ‘.md’ conditions, an empty string is treated as "always
! true".  ‘(MODE "")’ can also be abbreviated to ‘MODE’.  For example:
  
       (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
  
!  means that the ‘:DI’ expansion only applies if ‘TARGET_64BIT’ but that
! the ‘:SI’ expansion has no such constraint.
  
   Iterators are applied in the order they are defined.  This can be
  significant if two iterators are used in a construct that requires
*************** File: gccint.info,  Node: Substitutions,
*** 31984,32007 ****
  17.23.1.2 Substitution in Mode Iterators
  ........................................
  
! If an '.md' file construct uses mode iterators, each version of the
  construct will often need slightly different strings or modes.  For
  example:
  
!    * When a 'define_expand' defines several 'addM3' patterns (*note
       Standard Names::), each expander will need to use the appropriate
       mode name for M.
  
!    * When a 'define_insn' defines several instruction patterns, each
       instruction will often use a different assembler mnemonic.
  
!    * When a 'define_insn' requires operands with different modes, using
       an iterator for one of the operand modes usually requires a
       specific mode for the other operand(s).
  
   GCC supports such variations through a system of "mode attributes".
! There are two standard attributes: 'mode', which is the name of the mode
! in lower case, and 'MODE', which is the same thing in upper case.  You
  can define other attributes using:
  
       (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")])
--- 31983,32006 ----
  17.23.1.2 Substitution in Mode Iterators
  ........................................
  
! If an ‘.md’ file construct uses mode iterators, each version of the
  construct will often need slightly different strings or modes.  For
  example:
  
!    • When a ‘define_expand’ defines several ‘addM3’ patterns (*note
       Standard Names::), each expander will need to use the appropriate
       mode name for M.
  
!    • When a ‘define_insn’ defines several instruction patterns, each
       instruction will often use a different assembler mnemonic.
  
!    • When a ‘define_insn’ requires operands with different modes, using
       an iterator for one of the operand modes usually requires a
       specific mode for the other operand(s).
  
   GCC supports such variations through a system of "mode attributes".
! There are two standard attributes: ‘mode’, which is the name of the mode
! in lower case, and ‘MODE’, which is the same thing in upper case.  You
  can define other attributes using:
  
       (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")])
*************** can define other attributes using:
*** 32010,32028 ****
  associated with MODEI.
  
   When GCC replaces some :ITERATOR with :MODE, it will scan each string
! and mode in the pattern for sequences of the form '',
  where ATTR is the name of a mode attribute.  If the attribute is defined
! for MODE, the whole '<...>' sequence will be replaced by the appropriate
  attribute value.
  
!  For example, suppose an '.md' file has:
  
       (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
       (define_mode_attr load [(SI "lw") (DI "ld")])
  
!  If one of the patterns that uses ':P' contains the string
! '"\t%0,%1"', the 'SI' version of that pattern will use
! '"lw\t%0,%1"' and the 'DI' version will use '"ld\t%0,%1"'.
  
   Here is an example of using an attribute for a mode:
  
--- 32009,32027 ----
  associated with MODEI.
  
   When GCC replaces some :ITERATOR with :MODE, it will scan each string
! and mode in the pattern for sequences of the form ‘’,
  where ATTR is the name of a mode attribute.  If the attribute is defined
! for MODE, the whole ‘<...>’ sequence will be replaced by the appropriate
  attribute value.
  
!  For example, suppose an ‘.md’ file has:
  
       (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
       (define_mode_attr load [(SI "lw") (DI "ld")])
  
!  If one of the patterns that uses ‘:P’ contains the string
! ‘"\t%0,%1"’, the ‘SI’ version of that pattern will use
! ‘"lw\t%0,%1"’ and the ‘DI’ version will use ‘"ld\t%0,%1"’.
  
   Here is an example of using an attribute for a mode:
  
*************** attribute value.
*** 32031,32037 ****
       (define_insn ...
         (sign_extend:LONG (match_operand: ...)) ...)
  
!  The 'ITERATOR:' prefix may be omitted, in which case the substitution
  will be attempted for every iterator expansion.
  
  
--- 32030,32036 ----
       (define_insn ...
         (sign_extend:LONG (match_operand: ...)) ...)
  
!  The ‘ITERATOR:’ prefix may be omitted, in which case the substitution
  will be attempted for every iterator expansion.
  
  
*************** and attributes (among others):
*** 32046,32052 ****
       (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
       (define_mode_attr d [(SI "") (DI "d")])
  
!  and uses the following template to define both 'subsi3' and 'subdi3':
  
       (define_insn "sub3"
         [(set (match_operand:GPR 0 "register_operand" "=d")
--- 32045,32051 ----
       (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
       (define_mode_attr d [(SI "") (DI "d")])
  
!  and uses the following template to define both ‘subsi3’ and ‘subdi3’:
  
       (define_insn "sub3"
         [(set (match_operand:GPR 0 "register_operand" "=d")
*************** times, once with all uses of NAME replac
*** 32099,32113 ****
  replaced by CODE2, and so on.  *Note Defining Mode Iterators::.
  
   It is possible to define attributes for codes as well as for modes.
! There are two standard code attributes: 'code', the name of the code in
! lower case, and 'CODE', the name of the code in upper case.  Other
  attributes are defined using:
  
       (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")])
  
   Instruction patterns can use code attributes as rtx codes, which can be
  useful if two sets of codes act in tandem.  For example, the following
! 'define_insn' defines two patterns, one calculating a signed absolute
  difference and another calculating an unsigned absolute difference:
  
       (define_code_iterator any_max [smax umax])
--- 32098,32112 ----
  replaced by CODE2, and so on.  *Note Defining Mode Iterators::.
  
   It is possible to define attributes for codes as well as for modes.
! There are two standard code attributes: ‘code’, the name of the code in
! lower case, and ‘CODE’, the name of the code in upper case.  Other
  attributes are defined using:
  
       (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")])
  
   Instruction patterns can use code attributes as rtx codes, which can be
  useful if two sets of codes act in tandem.  For example, the following
! ‘define_insn’ defines two patterns, one calculating a signed absolute
  difference and another calculating an unsigned absolute difference:
  
       (define_code_iterator any_max [smax umax])
*************** difference and another calculating an un
*** 32119,32127 ****
                         (:SI (match_dup 1) (match_dup 2))))]
         ...)
  
!  The signed version of the instruction uses 'smax' and 'smin' while the
! unsigned version uses 'umax' and 'umin'.  There are no versions that
! pair 'smax' with 'umin' or 'umax' with 'smin'.
  
   Here's an example of code iterators in action, taken from the MIPS
  port:
--- 32118,32126 ----
                         (:SI (match_dup 1) (match_dup 2))))]
         ...)
  
!  The signed version of the instruction uses ‘smax’ and ‘smin’ while the
! unsigned version uses ‘umax’ and ‘umin’.  There are no versions that
! pair ‘smax’ with ‘umin’ or ‘umax’ with ‘smin’.
  
   Here's an example of code iterators in action, taken from the MIPS
  port:
*************** used in RTL-pattern.
*** 32252,32265 ****
   Subst iterators transform templates in the following way: the templates
  are duplicated, the subst-attributes in these templates are replaced
  with the corresponding values, and a new attribute is implicitly added
! to the given 'define_insn'/'define_expand'.  The name of the added
! attribute matches the name of 'define_subst'.  Such attributes are
! declared implicitly, and it is not allowed to have a 'define_attr' named
! as a 'define_subst'.
  
!  Each subst iterator is linked to a 'define_subst'.  It is declared
  implicitly by the first appearance of the corresponding
! 'define_subst_attr', and it is not allowed to define it explicitly.
  
   Declarations of subst-attributes have the following syntax:
  
--- 32251,32264 ----
   Subst iterators transform templates in the following way: the templates
  are duplicated, the subst-attributes in these templates are replaced
  with the corresponding values, and a new attribute is implicitly added
! to the given ‘define_insn’/‘define_expand’.  The name of the added
! attribute matches the name of ‘define_subst’.  Such attributes are
! declared implicitly, and it is not allowed to have a ‘define_attr’ named
! as a ‘define_subst’.
  
!  Each subst iterator is linked to a ‘define_subst’.  It is declared
  implicitly by the first appearance of the corresponding
! ‘define_subst_attr’, and it is not allowed to define it explicitly.
  
   Declarations of subst-attributes have the following syntax:
  
*************** implicitly by the first appearance of th
*** 32271,32277 ****
   NAME is a string with which the given subst-attribute could be referred
  to.
  
!  SUBST-NAME shows which 'define_subst' should be applied to an
  RTL-template if the given subst-attribute is present in the
  RTL-template.
  
--- 32270,32276 ----
   NAME is a string with which the given subst-attribute could be referred
  to.
  
!  SUBST-NAME shows which ‘define_subst’ should be applied to an
  RTL-template if the given subst-attribute is present in the
  RTL-template.
  
*************** File: gccint.info,  Node: Parameterized
*** 32289,32295 ****
  
  Ports sometimes need to apply iterators using C++ code, in order to get
  the code or RTL pattern for a specific instruction.  For example,
! suppose we have the 'neon_vq' pattern given above:
  
       (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG])
  
--- 32288,32294 ----
  
  Ports sometimes need to apply iterators using C++ code, in order to get
  the code or RTL pattern for a specific instruction.  For example,
! suppose we have the ‘neon_vq’ pattern given above:
  
       (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG])
  
*************** suppose we have the 'neon_vq' placeholders, and
! with any underscore before a '<...>' placeholder removed if keeping it
  would lead to a double or trailing underscore.
  
! 'insn_code maybe_code_for_NAME (I1, I2, ...)'
!      See whether replacing the first '<...>' placeholder with iterator
       value I1, the second with iterator value I2, and so on, gives a
       valid instruction.  Return its code if so, otherwise return
!      'CODE_FOR_nothing'.
  
! 'insn_code code_for_NAME (I1, I2, ...)'
       Same, but abort the compiler if the requested instruction does not
       exist.
  
! 'rtx maybe_gen_NAME (I1, I2, ..., OP0, OP1, ...)'
       Check for a valid instruction in the same way as
!      'maybe_code_for_NAME'.  If the instruction exists, generate an
       instance of it using the operand values given by OP0, OP1, and so
       on, otherwise return null.
  
! 'rtx gen_NAME (I1, I2, ..., OP0, OP1, ...)'
       Same, but abort the compiler if the requested instruction does not
!      exist, or if the instruction generator invoked the 'FAIL' macro.
  
   For example, changing the pattern above to:
  
--- 32302,32337 ----
         ...
       )
  
!  A port might need to generate this pattern for a variable ‘QABSNEG’
! value and a variable ‘VDQIW’ mode.  There are two ways of doing this.
  The first is to build the rtx for the pattern directly from C++ code;
  this is a valid technique and avoids any risk of combinatorial
  explosion.  The second is to prefix the instruction name with the
! special character ‘@’, which tells GCC to generate the four additional
  functions below.  In each case, NAME is the name of the instruction
! without the leading ‘@’ character, without the ‘<...>’ placeholders, and
! with any underscore before a ‘<...>’ placeholder removed if keeping it
  would lead to a double or trailing underscore.
  
! ‘insn_code maybe_code_for_NAME (I1, I2, ...)’
!      See whether replacing the first ‘<...>’ placeholder with iterator
       value I1, the second with iterator value I2, and so on, gives a
       valid instruction.  Return its code if so, otherwise return
!      ‘CODE_FOR_nothing’.
  
! ‘insn_code code_for_NAME (I1, I2, ...)’
       Same, but abort the compiler if the requested instruction does not
       exist.
  
! ‘rtx maybe_gen_NAME (I1, I2, ..., OP0, OP1, ...)’
       Check for a valid instruction in the same way as
!      ‘maybe_code_for_NAME’.  If the instruction exists, generate an
       instance of it using the operand values given by OP0, OP1, and so
       on, otherwise return null.
  
! ‘rtx gen_NAME (I1, I2, ..., OP0, OP1, ...)’
       Same, but abort the compiler if the requested instruction does not
!      exist, or if the instruction generator invoked the ‘FAIL’ macro.
  
   For example, changing the pattern above to:
  
*************** generate the four functions below:
*** 32352,32361 ****
       rtx maybe_gen_neon_vq (int, machine_mode, rtx, rtx, rtx);
       rtx gen_neon_vq (int, machine_mode, rtx, rtx, rtx);
  
!  Calling 'code_for_neon_vq (UNSPEC_VQABS, V8QImode)' would then give
! 'CODE_FOR_neon_vqabsv8qi'.
  
!  It is possible to have multiple '@' patterns with the same name and
  same types of iterator.  For example:
  
       (define_insn "@some_arithmetic_op"
--- 32351,32360 ----
       rtx maybe_gen_neon_vq (int, machine_mode, rtx, rtx, rtx);
       rtx gen_neon_vq (int, machine_mode, rtx, rtx, rtx);
  
!  Calling ‘code_for_neon_vq (UNSPEC_VQABS, V8QImode)’ would then give
! ‘CODE_FOR_neon_vqabsv8qi’.
  
!  It is possible to have multiple ‘@’ patterns with the same name and
  same types of iterator.  For example:
  
       (define_insn "@some_arithmetic_op"
*************** same types of iterator.  For example:
*** 32369,32383 ****
       )
  
   would produce a single set of functions that handles both
! 'INTEGER_MODES' and 'FLOAT_MODES'.
  
!  It is also possible for these '@' patterns to have different numbers of
  operands from each other.  For example, patterns with a binary rtl code
  might take three operands (one output and two inputs) while patterns
  with a ternary rtl code might take four operands (one output and three
! inputs).  This combination would produce separate 'maybe_gen_NAME' and
! 'gen_NAME' functions for each operand count, but it would still produce
! a single 'maybe_code_for_NAME' and a single 'code_for_NAME'.
  
  
  File: gccint.info,  Node: Target Macros,  Next: Host Config,  Prev: Machine Desc,  Up: Top
--- 32368,32382 ----
       )
  
   would produce a single set of functions that handles both
! ‘INTEGER_MODES’ and ‘FLOAT_MODES’.
  
!  It is also possible for these ‘@’ patterns to have different numbers of
  operands from each other.  For example, patterns with a binary rtl code
  might take three operands (one output and two inputs) while patterns
  with a ternary rtl code might take four operands (one output and three
! inputs).  This combination would produce separate ‘maybe_gen_NAME’ and
! ‘gen_NAME’ functions for each operand count, but it would still produce
! a single ‘maybe_code_for_NAME’ and a single ‘code_for_NAME’.
  
  
  File: gccint.info,  Node: Target Macros,  Next: Host Config,  Prev: Machine Desc,  Up: Top
*************** File: gccint.info,  Node: Target Macros,
*** 32385,32408 ****
  18 Target Description Macros and Functions
  ******************************************
  
! In addition to the file 'MACHINE.md', a machine description includes a C
! header file conventionally given the name 'MACHINE.h' and a C source
! file named 'MACHINE.c'.  The header file defines numerous macros that
  convey the information about the target machine that does not fit into
! the scheme of the '.md' file.  The file 'tm.h' should be a link to
! 'MACHINE.h'.  The header file 'config.h' includes 'tm.h' and most
! compiler source files include 'config.h'.  The source file defines a
! variable 'targetm', which is a structure containing pointers to
! functions and data relating to the target machine.  'MACHINE.c' should
  also contain their definitions, if they are not defined elsewhere in
! GCC, and other functions called through the macros defined in the '.h'
  file.
  
  * Menu:
  
! * Target Structure::    The 'targetm' variable.
  * Driver::              Controlling how the driver runs the compilation passes.
! * Run-time Target::     Defining '-m' options like '-m68000' and '-m68020'.
  * Per-Function Data::   Defining data structures for per-function information.
  * Storage Layout::      Defining sizes and alignments of data.
  * Type Layout::         Defining sizes and properties of basic user data types.
--- 32384,32407 ----
  18 Target Description Macros and Functions
  ******************************************
  
! In addition to the file ‘MACHINE.md’, a machine description includes a C
! header file conventionally given the name ‘MACHINE.h’ and a C source
! file named ‘MACHINE.c’.  The header file defines numerous macros that
  convey the information about the target machine that does not fit into
! the scheme of the ‘.md’ file.  The file ‘tm.h’ should be a link to
! ‘MACHINE.h’.  The header file ‘config.h’ includes ‘tm.h’ and most
! compiler source files include ‘config.h’.  The source file defines a
! variable ‘targetm’, which is a structure containing pointers to
! functions and data relating to the target machine.  ‘MACHINE.c’ should
  also contain their definitions, if they are not defined elsewhere in
! GCC, and other functions called through the macros defined in the ‘.h’
  file.
  
  * Menu:
  
! * Target Structure::    The ‘targetm’ variable.
  * Driver::              Controlling how the driver runs the compilation passes.
! * Run-time Target::     Defining ‘-m’ options like ‘-m68000’ and ‘-m68020’.
  * Per-Function Data::   Defining data structures for per-function information.
  * Storage Layout::      Defining sizes and alignments of data.
  * Type Layout::         Defining sizes and properties of basic user data types.
*************** file.
*** 32413,32419 ****
  * Trampolines::         Code set up at run time to enter a nested function.
  * Library Calls::       Controlling how library routines are implicitly called.
  * Addressing Modes::    Defining addressing modes valid for memory operands.
! * Anchored Addresses::  Defining how '-fsection-anchors' should work.
  * Condition Code::      Defining how insns update the condition code.
  * Costs::               Defining relative costs of different operations.
  * Scheduling::          Adjusting the behavior of the instruction scheduler.
--- 32412,32418 ----
  * Trampolines::         Code set up at run time to enter a nested function.
  * Library Calls::       Controlling how library routines are implicitly called.
  * Addressing Modes::    Defining addressing modes valid for memory operands.
! * Anchored Addresses::  Defining how ‘-fsection-anchors’ should work.
  * Condition Code::      Defining how insns update the condition code.
  * Costs::               Defining relative costs of different operations.
  * Scheduling::          Adjusting the behavior of the instruction scheduler.
*************** file.
*** 32423,32429 ****
  * Debugging Info::      Defining the format of debugging output.
  * Floating Point::      Handling floating point for cross-compilers.
  * Mode Switching::      Insertion of mode-switching instructions.
! * Target Attributes::   Defining target-specific uses of '__attribute__'.
  * Emulated TLS::        Emulated TLS support.
  * MIPS Coprocessors::   MIPS coprocessor support and how to customize it.
  * PCH Target::          Validity checking for precompiled headers.
--- 32422,32428 ----
  * Debugging Info::      Defining the format of debugging output.
  * Floating Point::      Handling floating point for cross-compilers.
  * Mode Switching::      Insertion of mode-switching instructions.
! * Target Attributes::   Defining target-specific uses of ‘__attribute__’.
  * Emulated TLS::        Emulated TLS support.
  * MIPS Coprocessors::   MIPS coprocessor support and how to customize it.
  * PCH Target::          Validity checking for precompiled headers.
*************** file.
*** 32435,32450 ****
  
  File: gccint.info,  Node: Target Structure,  Next: Driver,  Up: Target Macros
  
! 18.1 The Global 'targetm' Variable
  ==================================
  
   -- Variable: struct gcc_target targetm
!      The target '.c' file must define the global 'targetm' variable
       which contains pointers to functions and data relating to the
!      target machine.  The variable is declared in 'target.h';
!      'target-def.h' defines the macro 'TARGET_INITIALIZER' which is used
       to initialize the variable, and macros for the default initializers
!      for elements of the structure.  The '.c' file should override those
       macros for which the default definition is inappropriate.  For
       example:
            #include "target.h"
--- 32434,32449 ----
  
  File: gccint.info,  Node: Target Structure,  Next: Driver,  Up: Target Macros
  
! 18.1 The Global ‘targetm’ Variable
  ==================================
  
   -- Variable: struct gcc_target targetm
!      The target ‘.c’ file must define the global ‘targetm’ variable
       which contains pointers to functions and data relating to the
!      target machine.  The variable is declared in ‘target.h’;
!      ‘target-def.h’ defines the macro ‘TARGET_INITIALIZER’ which is used
       to initialize the variable, and macros for the default initializers
!      for elements of the structure.  The ‘.c’ file should override those
       macros for which the default definition is inappropriate.  For
       example:
            #include "target.h"
*************** File: gccint.info,  Node: Target Structu
*** 32457,32494 ****
  
            struct gcc_target targetm = TARGET_INITIALIZER;
  
!  Where a macro should be defined in the '.c' file in this manner to form
! part of the 'targetm' structure, it is documented below as a "Target
  Hook" with a prototype.  Many macros will change in future from being
! defined in the '.h' file to being part of the 'targetm' structure.
  
!  Similarly, there is a 'targetcm' variable for hooks that are specific
  to front ends for C-family languages, documented as "C Target Hook".
! This is declared in 'c-family/c-target.h', the initializer
! 'TARGETCM_INITIALIZER' in 'c-family/c-target-def.h'.  If targets
! initialize 'targetcm' themselves, they should set
! 'target_has_targetcm=yes' in 'config.gcc'; otherwise a default
  definition is used.
  
!  Similarly, there is a 'targetm_common' variable for hooks that are
  shared between the compiler driver and the compilers proper, documented
! as "Common Target Hook".  This is declared in 'common/common-target.h',
! the initializer 'TARGETM_COMMON_INITIALIZER' in
! 'common/common-target-def.h'.  If targets initialize 'targetm_common'
! themselves, they should set 'target_has_targetm_common=yes' in
! 'config.gcc'; otherwise a default definition is used.
  
!  Similarly, there is a 'targetdm' variable for hooks that are specific
  to the D language front end, documented as "D Target Hook".  This is
! declared in 'd/d-target.h', the initializer 'TARGETDM_INITIALIZER' in
! 'd/d-target-def.h'.  If targets initialize 'targetdm' themselves, they
! should set 'target_has_targetdm=yes' in 'config.gcc'; otherwise a
  default definition is used.
  
  
  File: gccint.info,  Node: Driver,  Next: Run-time Target,  Prev: Target Structure,  Up: Target Macros
  
! 18.2 Controlling the Compilation Driver, 'gcc'
  ==============================================
  
  You can control the compilation driver.
--- 32456,32493 ----
  
            struct gcc_target targetm = TARGET_INITIALIZER;
  
!  Where a macro should be defined in the ‘.c’ file in this manner to form
! part of the ‘targetm’ structure, it is documented below as a "Target
  Hook" with a prototype.  Many macros will change in future from being
! defined in the ‘.h’ file to being part of the ‘targetm’ structure.
  
!  Similarly, there is a ‘targetcm’ variable for hooks that are specific
  to front ends for C-family languages, documented as "C Target Hook".
! This is declared in ‘c-family/c-target.h’, the initializer
! ‘TARGETCM_INITIALIZER’ in ‘c-family/c-target-def.h’.  If targets
! initialize ‘targetcm’ themselves, they should set
! ‘target_has_targetcm=yes’ in ‘config.gcc’; otherwise a default
  definition is used.
  
!  Similarly, there is a ‘targetm_common’ variable for hooks that are
  shared between the compiler driver and the compilers proper, documented
! as "Common Target Hook".  This is declared in ‘common/common-target.h’,
! the initializer ‘TARGETM_COMMON_INITIALIZER’ in
! ‘common/common-target-def.h’.  If targets initialize ‘targetm_common’
! themselves, they should set ‘target_has_targetm_common=yes’ in
! ‘config.gcc’; otherwise a default definition is used.
  
!  Similarly, there is a ‘targetdm’ variable for hooks that are specific
  to the D language front end, documented as "D Target Hook".  This is
! declared in ‘d/d-target.h’, the initializer ‘TARGETDM_INITIALIZER’ in
! ‘d/d-target-def.h’.  If targets initialize ‘targetdm’ themselves, they
! should set ‘target_has_targetdm=yes’ in ‘config.gcc’; otherwise a
  default definition is used.
  
  
  File: gccint.info,  Node: Driver,  Next: Run-time Target,  Prev: Target Structure,  Up: Target Macros
  
! 18.2 Controlling the Compilation Driver, ‘gcc’
  ==============================================
  
  You can control the compilation driver.
*************** You can control the compilation driver.
*** 32498,32508 ****
       initializer for an array of strings, with no surrounding braces.
  
       The driver applies these specs to its own command line between
!      loading default 'specs' files (but not command-line specified ones)
       and choosing the multilib directory or running any subcommands.  It
       applies them in the order given, so each spec can depend on the
       options added by earlier ones.  It is also possible to remove
!      options using '%' in such a case, the header provided may not
       conform to C99, depending on the type in question.  The defaults
       for all of these macros are null pointers.
  
--- 34011,34028 ----
   -- Macro: UINT_FAST64_TYPE
   -- Macro: INTPTR_TYPE
   -- Macro: UINTPTR_TYPE
!      C expressions for the standard types ‘sig_atomic_t’, ‘int8_t’,
!      ‘int16_t’, ‘int32_t’, ‘int64_t’, ‘uint8_t’, ‘uint16_t’, ‘uint32_t’,
!      ‘uint64_t’, ‘int_least8_t’, ‘int_least16_t’, ‘int_least32_t’,
!      ‘int_least64_t’, ‘uint_least8_t’, ‘uint_least16_t’,
!      ‘uint_least32_t’, ‘uint_least64_t’, ‘int_fast8_t’, ‘int_fast16_t’,
!      ‘int_fast32_t’, ‘int_fast64_t’, ‘uint_fast8_t’, ‘uint_fast16_t’,
!      ‘uint_fast32_t’, ‘uint_fast64_t’, ‘intptr_t’, and ‘uintptr_t’.  See
!      ‘SIZE_TYPE’ above for more information.
  
       If any of these macros evaluates to a null pointer, the
       corresponding type is not supported; if GCC is configured to
!      provide ‘’ in such a case, the header provided may not
       conform to C99, depending on the type in question.  The defaults
       for all of these macros are null pointers.
  
*************** languages, rather than to fundamental as
*** 34046,34067 ****
       vtable_index is odd, we can distinguish which variant of the union
       is in use.  But, on some platforms function pointers can be odd,
       and so this doesn't work.  In that case, we use the low-order bit
!      of the 'delta' field, and shift the remainder of the 'delta' field
       to the left.
  
       GCC will automatically make the right selection about where to
!      store this bit using the 'FUNCTION_BOUNDARY' setting for your
       platform.  However, some platforms such as ARM/Thumb have
!      'FUNCTION_BOUNDARY' set such that functions always start at even
       addresses, but the lowest bit of pointers to functions indicate
       whether the function at that address is in ARM or Thumb mode.  If
       this is the case of your architecture, you should define this macro
!      to 'ptrmemfunc_vbit_in_delta'.
  
       In general, you should not have to define this macro.  On
       architectures in which function addresses are always even,
!      according to 'FUNCTION_BOUNDARY', GCC will automatically define
!      this macro to 'ptrmemfunc_vbit_in_pfn'.
  
   -- Macro: TARGET_VTABLE_USES_DESCRIPTORS
       Normally, the C++ compiler uses function pointers in vtables.  This
--- 34045,34066 ----
       vtable_index is odd, we can distinguish which variant of the union
       is in use.  But, on some platforms function pointers can be odd,
       and so this doesn't work.  In that case, we use the low-order bit
!      of the ‘delta’ field, and shift the remainder of the ‘delta’ field
       to the left.
  
       GCC will automatically make the right selection about where to
!      store this bit using the ‘FUNCTION_BOUNDARY’ setting for your
       platform.  However, some platforms such as ARM/Thumb have
!      ‘FUNCTION_BOUNDARY’ set such that functions always start at even
       addresses, but the lowest bit of pointers to functions indicate
       whether the function at that address is in ARM or Thumb mode.  If
       this is the case of your architecture, you should define this macro
!      to ‘ptrmemfunc_vbit_in_delta’.
  
       In general, you should not have to define this macro.  On
       architectures in which function addresses are always even,
!      according to ‘FUNCTION_BOUNDARY’, GCC will automatically define
!      this macro to ‘ptrmemfunc_vbit_in_pfn’.
  
   -- Macro: TARGET_VTABLE_USES_DESCRIPTORS
       Normally, the C++ compiler uses function pointers in vtables.  This
*************** languages, rather than to fundamental as
*** 34083,34089 ****
   -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE
       There are a few non-descriptor entries in the vtable at offsets
       below zero.  If these entries must be padded (say, to preserve the
!      alignment specified by 'TARGET_VTABLE_ENTRY_ALIGN'), set this to
       the number of words in each data entry.
  
  
--- 34082,34088 ----
   -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE
       There are a few non-descriptor entries in the vtable at offsets
       below zero.  If these entries must be padded (say, to preserve the
!      alignment specified by ‘TARGET_VTABLE_ENTRY_ALIGN’), set this to
       the number of words in each data entry.
  
  
*************** Registers have various characteristics.
*** 34120,34128 ****
  
   -- Macro: FIRST_PSEUDO_REGISTER
       Number of hardware registers known to the compiler.  They receive
!      numbers 0 through 'FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo
       register's number really is assigned the number
!      'FIRST_PSEUDO_REGISTER'.
  
   -- Macro: FIXED_REGISTERS
       An initializer that says which registers are used for fixed
--- 34119,34127 ----
  
   -- Macro: FIRST_PSEUDO_REGISTER
       Number of hardware registers known to the compiler.  They receive
!      numbers 0 through ‘FIRST_PSEUDO_REGISTER-1’; thus, the first pseudo
       register's number really is assigned the number
!      ‘FIRST_PSEUDO_REGISTER’.
  
   -- Macro: FIXED_REGISTERS
       An initializer that says which registers are used for fixed
*************** Registers have various characteristics.
*** 34141,34177 ****
       The table initialized from this macro, and the table initialized by
       the following one, may be overridden at run time either
       automatically, by the actions of the macro
!      'CONDITIONAL_REGISTER_USAGE', or by the user with the command
!      options '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'.
  
   -- Macro: CALL_USED_REGISTERS
!      Like 'FIXED_REGISTERS' but has 1 for each register that is
       clobbered (in general) by function calls as well as for fixed
       registers.  This macro therefore identifies the registers that are
       not available for general allocation of values that must live
       across function calls.
  
!      If a register has 0 in 'CALL_USED_REGISTERS', the compiler
       automatically saves it on function entry and restores it on
       function exit, if the register is used within the function.
  
!      Exactly one of 'CALL_USED_REGISTERS' and
!      'CALL_REALLY_USED_REGISTERS' must be defined.  Modern ports should
!      define 'CALL_REALLY_USED_REGISTERS'.
  
   -- Macro: CALL_REALLY_USED_REGISTERS
!      Like 'CALL_USED_REGISTERS' except this macro doesn't require that
!      the entire set of 'FIXED_REGISTERS' be included.
!      ('CALL_USED_REGISTERS' must be a superset of 'FIXED_REGISTERS').
  
!      Exactly one of 'CALL_USED_REGISTERS' and
!      'CALL_REALLY_USED_REGISTERS' must be defined.  Modern ports should
!      define 'CALL_REALLY_USED_REGISTERS'.
  
   -- Target Hook: const predefined_function_abi & TARGET_FNTYPE_ABI
            (const_tree TYPE)
       Return the ABI used by a function with type TYPE; see the
!      definition of 'predefined_function_abi' for details of the ABI
       descriptor.  Targets only need to define this hook if they support
       interoperability between several ABIs in the same translation unit.
  
--- 34140,34176 ----
       The table initialized from this macro, and the table initialized by
       the following one, may be overridden at run time either
       automatically, by the actions of the macro
!      ‘CONDITIONAL_REGISTER_USAGE’, or by the user with the command
!      options ‘-ffixed-REG’, ‘-fcall-used-REG’ and ‘-fcall-saved-REG’.
  
   -- Macro: CALL_USED_REGISTERS
!      Like ‘FIXED_REGISTERS’ but has 1 for each register that is
       clobbered (in general) by function calls as well as for fixed
       registers.  This macro therefore identifies the registers that are
       not available for general allocation of values that must live
       across function calls.
  
!      If a register has 0 in ‘CALL_USED_REGISTERS’, the compiler
       automatically saves it on function entry and restores it on
       function exit, if the register is used within the function.
  
!      Exactly one of ‘CALL_USED_REGISTERS’ and
!      ‘CALL_REALLY_USED_REGISTERS’ must be defined.  Modern ports should
!      define ‘CALL_REALLY_USED_REGISTERS’.
  
   -- Macro: CALL_REALLY_USED_REGISTERS
!      Like ‘CALL_USED_REGISTERS’ except this macro doesn't require that
!      the entire set of ‘FIXED_REGISTERS’ be included.
!      (‘CALL_USED_REGISTERS’ must be a superset of ‘FIXED_REGISTERS’).
  
!      Exactly one of ‘CALL_USED_REGISTERS’ and
!      ‘CALL_REALLY_USED_REGISTERS’ must be defined.  Modern ports should
!      define ‘CALL_REALLY_USED_REGISTERS’.
  
   -- Target Hook: const predefined_function_abi & TARGET_FNTYPE_ABI
            (const_tree TYPE)
       Return the ABI used by a function with type TYPE; see the
!      definition of ‘predefined_function_abi’ for details of the ABI
       descriptor.  Targets only need to define this hook if they support
       interoperability between several ABIs in the same translation unit.
  
*************** Registers have various characteristics.
*** 34179,34186 ****
            (const rtx_insn *INSN)
       This hook returns a description of the ABI used by the target of
       call instruction INSN; see the definition of
!      'predefined_function_abi' for details of the ABI descriptor.  Only
!      the global function 'insn_callee_abi' should call this hook
       directly.
  
       Targets only need to define this hook if they support
--- 34178,34185 ----
            (const rtx_insn *INSN)
       This hook returns a description of the ABI used by the target of
       call instruction INSN; see the definition of
!      ‘predefined_function_abi’ for details of the ABI descriptor.  Only
!      the global function ‘insn_callee_abi’ should call this hook
       directly.
  
       Targets only need to define this hook if they support
*************** Registers have various characteristics.
*** 34191,34206 ****
       ABIs usually specify that calls must preserve the full contents of
       a particular register, or that calls can alter any part of a
       particular register.  This information is captured by the target
!      macro 'CALL_REALLY_USED_REGISTERS'.  However, some ABIs specify
       that calls must preserve certain bits of a particular register but
       can alter others.  This hook should return true if this applies to
!      at least one of the registers in '(reg:MODE REGNO)', and if as a
       result the call would alter part of the MODE value.  For example,
       if a call preserves the low 32 bits of a 64-bit hard register REGNO
       but can clobber the upper 32 bits, this hook should return true for
       a 64-bit mode but false for a 32-bit mode.
  
!      The value of ABI_ID comes from the 'predefined_function_abi'
       structure that describes the ABI of the call; see the definition of
       the structure for more details.  If (as is usual) the target uses
       the same ABI for all functions in a translation unit, ABI_ID is
--- 34190,34205 ----
       ABIs usually specify that calls must preserve the full contents of
       a particular register, or that calls can alter any part of a
       particular register.  This information is captured by the target
!      macro ‘CALL_REALLY_USED_REGISTERS’.  However, some ABIs specify
       that calls must preserve certain bits of a particular register but
       can alter others.  This hook should return true if this applies to
!      at least one of the registers in ‘(reg:MODE REGNO)’, and if as a
       result the call would alter part of the MODE value.  For example,
       if a call preserves the low 32 bits of a 64-bit hard register REGNO
       but can clobber the upper 32 bits, this hook should return true for
       a 64-bit mode but false for a 32-bit mode.
  
!      The value of ABI_ID comes from the ‘predefined_function_abi’
       structure that describes the ABI of the call; see the definition of
       the structure for more details.  If (as is usual) the target uses
       the same ABI for all functions in a translation unit, ABI_ID is
*************** Registers have various characteristics.
*** 34213,34239 ****
       This hook returns name of multilib ABI name.
  
   -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void)
!      This hook may conditionally modify five variables 'fixed_regs',
!      'call_used_regs', 'global_regs', 'reg_names', and
!      'reg_class_contents', to take into account any dependence of these
       register sets on target flags.  The first three of these are of
!      type 'char []' (interpreted as boolean vectors).  'global_regs' is
!      a 'const char *[]', and 'reg_class_contents' is a 'HARD_REG_SET'.
!      Before the macro is called, 'fixed_regs', 'call_used_regs',
!      'reg_class_contents', and 'reg_names' have been initialized from
!      'FIXED_REGISTERS', 'CALL_USED_REGISTERS', 'REG_CLASS_CONTENTS', and
!      'REGISTER_NAMES', respectively.  'global_regs' has been cleared,
!      and any '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'
       command options have been applied.
  
       If the usage of an entire class of registers depends on the target
       flags, you may indicate this to GCC by using this macro to modify
!      'fixed_regs' and 'call_used_regs' to 1 for each of the registers in
       the classes which should not be used by GCC.  Also make
!      'define_register_constraint's return 'NO_REGS' for constraints that
       shouldn't be used.
  
!      (However, if this class is not included in 'GENERAL_REGS' and all
       of the insn patterns whose constraints permit this class are
       controlled by target switches, then GCC will automatically avoid
       using these registers when the target switches are opposed to
--- 34212,34238 ----
       This hook returns name of multilib ABI name.
  
   -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void)
!      This hook may conditionally modify five variables ‘fixed_regs’,
!      ‘call_used_regs’, ‘global_regs’, ‘reg_names’, and
!      ‘reg_class_contents’, to take into account any dependence of these
       register sets on target flags.  The first three of these are of
!      type ‘char []’ (interpreted as boolean vectors).  ‘global_regs’ is
!      a ‘const char *[]’, and ‘reg_class_contents’ is a ‘HARD_REG_SET’.
!      Before the macro is called, ‘fixed_regs’, ‘call_used_regs’,
!      ‘reg_class_contents’, and ‘reg_names’ have been initialized from
!      ‘FIXED_REGISTERS’, ‘CALL_USED_REGISTERS’, ‘REG_CLASS_CONTENTS’, and
!      ‘REGISTER_NAMES’, respectively.  ‘global_regs’ has been cleared,
!      and any ‘-ffixed-REG’, ‘-fcall-used-REG’ and ‘-fcall-saved-REG’
       command options have been applied.
  
       If the usage of an entire class of registers depends on the target
       flags, you may indicate this to GCC by using this macro to modify
!      ‘fixed_regs’ and ‘call_used_regs’ to 1 for each of the registers in
       the classes which should not be used by GCC.  Also make
!      ‘define_register_constraint’s return ‘NO_REGS’ for constraints that
       shouldn't be used.
  
!      (However, if this class is not included in ‘GENERAL_REGS’ and all
       of the insn patterns whose constraints permit this class are
       controlled by target switches, then GCC will automatically avoid
       using these registers when the target switches are opposed to
*************** Registers are allocated in order.
*** 34283,34289 ****
       One use of this macro is on machines where the highest numbered
       registers must always be saved and the save-multiple-registers
       instruction supports only sequences of consecutive registers.  On
!      such machines, define 'REG_ALLOC_ORDER' to be an initializer that
       lists the highest numbered allocable register first.
  
   -- Macro: ADJUST_REG_ALLOC_ORDER
--- 34282,34288 ----
       One use of this macro is on machines where the highest numbered
       registers must always be saved and the save-multiple-registers
       instruction supports only sequences of consecutive registers.  On
!      such machines, define ‘REG_ALLOC_ORDER’ to be an initializer that
       lists the highest numbered allocable register first.
  
   -- Macro: ADJUST_REG_ALLOC_ORDER
*************** Registers are allocated in order.
*** 34291,34302 ****
       allocate hard registers for pseudo-registers local to a basic
       block.
  
!      Store the desired register order in the array 'reg_alloc_order'.
       Element 0 should be the register to allocate first; element 1, the
       next register; and so on.
  
       The macro body should not assume anything about the contents of
!      'reg_alloc_order' before execution of the macro.
  
       On most machines, it is not necessary to define this macro.
  
--- 34290,34301 ----
       allocate hard registers for pseudo-registers local to a basic
       block.
  
!      Store the desired register order in the array ‘reg_alloc_order’.
       Element 0 should be the register to allocate first; element 1, the
       next register; and so on.
  
       The macro body should not assume anything about the contents of
!      ‘reg_alloc_order’ before execution of the macro.
  
       On most machines, it is not necessary to define this macro.
  
*************** Registers are allocated in order.
*** 34315,34321 ****
       based on REGNO.  The cost of using REGNO for a pseudo will be
       increased by approximately the pseudo's usage frequency times the
       value returned by this macro.  Not defining this macro is
!      equivalent to having it always return '0.0'.
  
       On most machines, it is not necessary to define this macro.
  
--- 34314,34320 ----
       based on REGNO.  The cost of using REGNO for a pseudo will be
       increased by approximately the pseudo's usage frequency times the
       value returned by this macro.  Not defining this macro is
!      equivalent to having it always return ‘0.0’.
  
       On most machines, it is not necessary to define this macro.
  
*************** consecutive registers are needed for a g
*** 34335,34341 ****
       starting at register number REGNO, required to hold a value of mode
       MODE.  This hook must never return zero, even if a register cannot
       hold the requested mode - indicate that with
!      'TARGET_HARD_REGNO_MODE_OK' and/or 'TARGET_CAN_CHANGE_MODE_CLASS'
       instead.
  
       The default definition returns the number of words in MODE.
--- 34334,34340 ----
       starting at register number REGNO, required to hold a value of mode
       MODE.  This hook must never return zero, even if a register cannot
       hold the requested mode - indicate that with
!      ‘TARGET_HARD_REGNO_MODE_OK’ and/or ‘TARGET_CAN_CHANGE_MODE_CLASS’
       instead.
  
       The default definition returns the number of words in MODE.
*************** consecutive registers are needed for a g
*** 34346,34366 ****
       in registers starting at register number REGNO (as determined by
       multiplying GCC's notion of the size of the register when
       containing this mode by the number of registers returned by
!      'TARGET_HARD_REGNO_NREGS').  By default this is zero.
  
       For example, if a floating-point value is stored in three 32-bit
       registers but takes up 128 bits in memory, then this would be
       nonzero.
  
       This macros only needs to be defined if there are cases where
!      'subreg_get_info' would otherwise wrongly determine that a 'subreg'
       can be represented by an offset to the register number, when in
!      fact such a 'subreg' would contain some of the padding not stored
       in registers and so not be representable.
  
   -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE)
       For values of REGNO and MODE for which
!      'HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression
       returning the greater number of registers required to hold the
       value including any padding.  In the example above, the value would
       be four.
--- 34345,34365 ----
       in registers starting at register number REGNO (as determined by
       multiplying GCC's notion of the size of the register when
       containing this mode by the number of registers returned by
!      ‘TARGET_HARD_REGNO_NREGS’).  By default this is zero.
  
       For example, if a floating-point value is stored in three 32-bit
       registers but takes up 128 bits in memory, then this would be
       nonzero.
  
       This macros only needs to be defined if there are cases where
!      ‘subreg_get_info’ would otherwise wrongly determine that a ‘subreg’
       can be represented by an offset to the register number, when in
!      fact such a ‘subreg’ would contain some of the padding not stored
       in registers and so not be representable.
  
   -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE)
       For values of REGNO and MODE for which
!      ‘HARD_REGNO_NREGS_HAS_PADDING’ returns nonzero, a C expression
       returning the greater number of registers required to hold the
       value including any padding.  In the example above, the value would
       be four.
*************** consecutive registers are needed for a g
*** 34389,34404 ****
       reject odd register numbers for such modes.
  
       The minimum requirement for a mode to be OK in a register is that
!      the 'movMODE' instruction pattern support moves between the
       register and other hard register in the same class and that moving
       a value into the register and back out not alter it.
  
!      Since the same instruction used to move 'word_mode' will work for
       all narrower integer modes, it is not necessary on any machine for
       this hook to distinguish between these modes, provided you define
!      patterns 'movhi', etc., to take advantage of this.  This is useful
!      because of the interaction between 'TARGET_HARD_REGNO_MODE_OK' and
!      'TARGET_MODES_TIEABLE_P'; it is very desirable for all integer
       modes to be tieable.
  
       Many machines have special registers for floating point arithmetic.
--- 34388,34403 ----
       reject odd register numbers for such modes.
  
       The minimum requirement for a mode to be OK in a register is that
!      the ‘movMODE’ instruction pattern support moves between the
       register and other hard register in the same class and that moving
       a value into the register and back out not alter it.
  
!      Since the same instruction used to move ‘word_mode’ will work for
       all narrower integer modes, it is not necessary on any machine for
       this hook to distinguish between these modes, provided you define
!      patterns ‘movhi’, etc., to take advantage of this.  This is useful
!      because of the interaction between ‘TARGET_HARD_REGNO_MODE_OK’ and
!      ‘TARGET_MODES_TIEABLE_P’; it is very desirable for all integer
       modes to be tieable.
  
       Many machines have special registers for floating point arithmetic.
*************** consecutive registers are needed for a g
*** 34413,34419 ****
       modes may not go in floating registers.  This is true if the
       floating registers normalize any value stored in them, because
       storing a non-floating value there would garble it.  In this case,
!      'TARGET_HARD_REGNO_MODE_OK' should reject fixed-point machine modes
       in floating registers.  But if the floating registers do not
       automatically normalize, if you can store any bit pattern in one
       and retrieve it unchanged without a trap, then any machine mode may
--- 34412,34418 ----
       modes may not go in floating registers.  This is true if the
       floating registers normalize any value stored in them, because
       storing a non-floating value there would garble it.  In this case,
!      ‘TARGET_HARD_REGNO_MODE_OK’ should reject fixed-point machine modes
       in floating registers.  But if the floating registers do not
       automatically normalize, if you can store any bit pattern in one
       and retrieve it unchanged without a trap, then any machine mode may
*************** consecutive registers are needed for a g
*** 34422,34434 ****
       The primary significance of special floating registers is rather
       that they are the registers acceptable in floating point arithmetic
       instructions.  However, this is of no concern to
!      'TARGET_HARD_REGNO_MODE_OK'.  You handle it by writing the proper
       constraints for those instructions.
  
       On some machines, the floating registers are especially slow to
       access, so that it is better to store a value in a stack frame than
       in such a register if floating point arithmetic is not being done.
!      As long as the floating registers are not in class 'GENERAL_REGS',
       they will not be used unless some pattern's constraint asks for
       one.
  
--- 34421,34433 ----
       The primary significance of special floating registers is rather
       that they are the registers acceptable in floating point arithmetic
       instructions.  However, this is of no concern to
!      ‘TARGET_HARD_REGNO_MODE_OK’.  You handle it by writing the proper
       constraints for those instructions.
  
       On some machines, the floating registers are especially slow to
       access, so that it is better to store a value in a stack frame than
       in such a register if floating point arithmetic is not being done.
!      As long as the floating registers are not in class ‘GENERAL_REGS’,
       they will not be used unless some pattern's constraint asks for
       one.
  
*************** consecutive registers are needed for a g
*** 34447,34455 ****
       This hook returns true if a value of mode MODE1 is accessible in
       mode MODE2 without copying.
  
!      If 'TARGET_HARD_REGNO_MODE_OK (R, MODE1)' and
!      'TARGET_HARD_REGNO_MODE_OK (R, MODE2)' are always the same for any
!      R, then 'TARGET_MODES_TIEABLE_P (MODE1, MODE2)' should be true.  If
       they differ for any R, you should define this hook to return false
       unless some other mechanism ensures the accessibility of the value
       in a narrower mode.
--- 34446,34454 ----
       This hook returns true if a value of mode MODE1 is accessible in
       mode MODE2 without copying.
  
!      If ‘TARGET_HARD_REGNO_MODE_OK (R, MODE1)’ and
!      ‘TARGET_HARD_REGNO_MODE_OK (R, MODE2)’ are always the same for any
!      R, then ‘TARGET_MODES_TIEABLE_P (MODE1, MODE2)’ should be true.  If
       they differ for any R, you should define this hook to return false
       unless some other mechanism ensures the accessibility of the value
       in a narrower mode.
*************** consecutive registers are needed for a g
*** 34459,34476 ****
       allocation.  The default definition returns true unconditionally.
  
   -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO)
!      This target hook should return 'true' if it is OK to use a hard
       register REGNO as scratch reg in peephole2.
  
       One common use of this macro is to prevent using of a register that
       is not saved by a prologue in an interrupt handler.
  
!      The default version of this hook always returns 'true'.
  
   -- Macro: AVOID_CCMODE_COPIES
       Define this macro if the compiler should avoid copies to/from
!      'CCmode' registers.  You should only define this macro if support
!      for copying to/from 'CCmode' is incomplete.
  
  
  File: gccint.info,  Node: Leaf Functions,  Next: Stack Registers,  Prev: Values in Registers,  Up: Registers
--- 34458,34475 ----
       allocation.  The default definition returns true unconditionally.
  
   -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO)
!      This target hook should return ‘true’ if it is OK to use a hard
       register REGNO as scratch reg in peephole2.
  
       One common use of this macro is to prevent using of a register that
       is not saved by a prologue in an interrupt handler.
  
!      The default version of this hook always returns ‘true’.
  
   -- Macro: AVOID_CCMODE_COPIES
       Define this macro if the compiler should avoid copies to/from
!      ‘CCmode’ registers.  You should only define this macro if support
!      for copying to/from ‘CCmode’ is incomplete.
  
  
  File: gccint.info,  Node: Leaf Functions,  Next: Stack Registers,  Prev: Values in Registers,  Up: Registers
*************** accomplish this.
*** 34515,34537 ****
       function.
  
       If REGNO is a register number which should not appear in a leaf
!      function before renumbering, then the expression should yield -1,
       which will cause the compiler to abort.
  
       Define this macro only if the target machine offers a way to
       optimize the treatment of leaf functions, and registers need to be
       renumbered to do this.
  
!  'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' must
  usually treat leaf functions specially.  They can test the C variable
! 'current_function_is_leaf' which is nonzero for leaf functions.
! 'current_function_is_leaf' is set prior to local register allocation and
  is valid for the remaining compiler passes.  They can also test the C
! variable 'current_function_uses_only_leaf_regs' which is nonzero for
  leaf functions which only use leaf registers.
! 'current_function_uses_only_leaf_regs' is valid after all passes that
  modify the instructions have been run and is only useful if
! 'LEAF_REGISTERS' is defined.
  
  
  File: gccint.info,  Node: Stack Registers,  Prev: Leaf Functions,  Up: Registers
--- 34514,34536 ----
       function.
  
       If REGNO is a register number which should not appear in a leaf
!      function before renumbering, then the expression should yield −1,
       which will cause the compiler to abort.
  
       Define this macro only if the target machine offers a way to
       optimize the treatment of leaf functions, and registers need to be
       renumbered to do this.
  
!  ‘TARGET_ASM_FUNCTION_PROLOGUE’ and ‘TARGET_ASM_FUNCTION_EPILOGUE’ must
  usually treat leaf functions specially.  They can test the C variable
! ‘current_function_is_leaf’ which is nonzero for leaf functions.
! ‘current_function_is_leaf’ is set prior to local register allocation and
  is valid for the remaining compiler passes.  They can also test the C
! variable ‘current_function_uses_only_leaf_regs’ which is nonzero for
  leaf functions which only use leaf registers.
! ‘current_function_uses_only_leaf_regs’ is valid after all passes that
  modify the instructions have been run and is only useful if
! ‘LEAF_REGISTERS’ is defined.
  
  
  File: gccint.info,  Node: Stack Registers,  Prev: Leaf Functions,  Up: Registers
*************** stack.
*** 34548,34554 ****
  they must be consecutively numbered.  Furthermore, the existing support
  for stack-like registers is specific to the 80387 floating point
  coprocessor.  If you have a new architecture that uses stack-like
! registers, you will need to do substantial work on 'reg-stack.cc' and
  write your machine description to cooperate with it, as well as defining
  these macros.
  
--- 34547,34553 ----
  they must be consecutively numbered.  Furthermore, the existing support
  for stack-like registers is specific to the 80387 floating point
  coprocessor.  If you have a new architecture that uses stack-like
! registers, you will need to do substantial work on ‘reg-stack.cc’ and
  write your machine description to cooperate with it, as well as defining
  these macros.
  
*************** File: gccint.info,  Node: Register Class
*** 34576,34583 ****
  On many machines, the numbered registers are not all equivalent.  For
  example, certain registers may not be allowed for indexed addressing;
  certain registers may not be allowed in some instructions.  These
! machine restrictions are described to the compiler using "register
! classes".
  
   You define a number of register classes, giving each one a name and
  saying which of the registers belong to it.  Then you can specify
--- 34575,34582 ----
  On many machines, the numbered registers are not all equivalent.  For
  example, certain registers may not be allowed for indexed addressing;
  certain registers may not be allowed in some instructions.  These
! machine restrictions are described to the compiler using “register
! classes”.
  
   You define a number of register classes, giving each one a name and
  saying which of the registers belong to it.  Then you can specify
*************** register classes that are allowed as ope
*** 34585,34603 ****
  patterns.
  
   In general, each register will belong to several classes.  In fact, one
! class must be named 'ALL_REGS' and contain all the registers.  Another
! class must be named 'NO_REGS' and contain no registers.  Often the union
  of two classes will be another class; however, this is not required.
  
!  One of the classes must be named 'GENERAL_REGS'.  There is nothing
! terribly special about the name, but the operand constraint letters 'r'
! and 'g' specify this class.  If 'GENERAL_REGS' is the same as
! 'ALL_REGS', just define it as a macro which expands to 'ALL_REGS'.
  
   Order the classes so that if class X is contained in class Y then X has
  a lower class number than Y.
  
!  The way classes other than 'GENERAL_REGS' are specified in operand
  constraints is through machine-dependent operand constraint letters.
  You can define such letters to correspond to various classes, then use
  them in operand constraints.
--- 34584,34602 ----
  patterns.
  
   In general, each register will belong to several classes.  In fact, one
! class must be named ‘ALL_REGS’ and contain all the registers.  Another
! class must be named ‘NO_REGS’ and contain no registers.  Often the union
  of two classes will be another class; however, this is not required.
  
!  One of the classes must be named ‘GENERAL_REGS’.  There is nothing
! terribly special about the name, but the operand constraint letters ‘r’
! and ‘g’ specify this class.  If ‘GENERAL_REGS’ is the same as
! ‘ALL_REGS’, just define it as a macro which expands to ‘ALL_REGS’.
  
   Order the classes so that if class X is contained in class Y then X has
  a lower class number than Y.
  
!  The way classes other than ‘GENERAL_REGS’ are specified in operand
  constraints is through machine-dependent operand constraint letters.
  You can define such letters to correspond to various classes, then use
  them in operand constraints.
*************** moving a register in the class to or fro
*** 34610,34619 ****
   You should define a class for the union of two classes whenever some
  instruction allows both classes.  For example, if an instruction allows
  either a floating point (coprocessor) register or a general register for
! a certain operand, you should define a class 'FLOAT_OR_GENERAL_REGS'
  which includes both of them.  Otherwise you will get suboptimal code, or
  even internal compiler errors when reload cannot find a register in the
! class computed via 'reg_class_subunion'.
  
   You must also specify certain redundant information about the register
  classes: for each class, which classes contain it and which ones are
--- 34609,34618 ----
   You should define a class for the union of two classes whenever some
  instruction allows both classes.  For example, if an instruction allows
  either a floating point (coprocessor) register or a general register for
! a certain operand, you should define a class ‘FLOAT_OR_GENERAL_REGS’
  which includes both of them.  Otherwise you will get suboptimal code, or
  even internal compiler errors when reload cannot find a register in the
! class computed via ‘reg_class_subunion’.
  
   You must also specify certain redundant information about the register
  classes: for each class, which classes contain it and which ones are
*************** in their union.
*** 34624,34651 ****
  certain class, all the registers used must belong to that class.
  Therefore, register classes cannot be used to enforce a requirement for
  a register pair to start with an even-numbered register.  The way to
! specify this requirement is with 'TARGET_HARD_REGNO_MODE_OK'.
  
   Register classes used for input-operands of bitwise-and or shift
  instructions have a special requirement: each such class must have, for
  each fixed-point machine mode, a subclass whose registers can transfer
  that mode to or from memory.  For example, on some machines, the
! operations for single-byte values ('QImode') are limited to certain
  registers.  When this is so, each register class that is used in a
  bitwise-and or shift instruction must have a subclass consisting of
  registers from which single-byte values can be loaded or stored.  This
! is so that 'PREFERRED_RELOAD_CLASS' can always have a possible value to
  return.
  
   -- Data type: enum reg_class
       An enumerated type that must be defined with all the register class
!      names as enumerated values.  'NO_REGS' must be first.  'ALL_REGS'
       must be the last register class, followed by one more enumerated
!      value, 'LIM_REG_CLASSES', which is not a register class but rather
       tells how many classes there are.
  
       Each register class has a number, which is the value of casting the
!      class name to type 'int'.  The number serves as an index in many of
       the tables described below.
  
   -- Macro: N_REG_CLASSES
--- 34623,34650 ----
  certain class, all the registers used must belong to that class.
  Therefore, register classes cannot be used to enforce a requirement for
  a register pair to start with an even-numbered register.  The way to
! specify this requirement is with ‘TARGET_HARD_REGNO_MODE_OK’.
  
   Register classes used for input-operands of bitwise-and or shift
  instructions have a special requirement: each such class must have, for
  each fixed-point machine mode, a subclass whose registers can transfer
  that mode to or from memory.  For example, on some machines, the
! operations for single-byte values (‘QImode’) are limited to certain
  registers.  When this is so, each register class that is used in a
  bitwise-and or shift instruction must have a subclass consisting of
  registers from which single-byte values can be loaded or stored.  This
! is so that ‘PREFERRED_RELOAD_CLASS’ can always have a possible value to
  return.
  
   -- Data type: enum reg_class
       An enumerated type that must be defined with all the register class
!      names as enumerated values.  ‘NO_REGS’ must be first.  ‘ALL_REGS’
       must be the last register class, followed by one more enumerated
!      value, ‘LIM_REG_CLASSES’, which is not a register class but rather
       tells how many classes there are.
  
       Each register class has a number, which is the value of casting the
!      class name to type ‘int’.  The number serves as an index in many of
       the tables described below.
  
   -- Macro: N_REG_CLASSES
*************** return.
*** 34662,34681 ****
       An initializer containing the contents of the register classes, as
       integers which are bit masks.  The Nth integer specifies the
       contents of class N.  The way the integer MASK is interpreted is
!      that register R is in the class if 'MASK & (1 << R)' is 1.
  
       When the machine has more than 32 registers, an integer does not
       suffice.  Then the integers are replaced by sub-initializers,
       braced groupings containing several integers.  Each sub-initializer
!      must be suitable as an initializer for the type 'HARD_REG_SET'
!      which is defined in 'hard-reg-set.h'.  In this situation, the first
       integer in each sub-initializer corresponds to registers 0 through
       31, the second integer to registers 32 through 63, and so on.
  
   -- Macro: REGNO_REG_CLASS (REGNO)
       A C expression whose value is a register class containing hard
       register REGNO.  In general there is more than one such class;
!      choose a class which is "minimal", meaning that no smaller class
       also contains the register.
  
   -- Macro: BASE_REG_CLASS
--- 34661,34680 ----
       An initializer containing the contents of the register classes, as
       integers which are bit masks.  The Nth integer specifies the
       contents of class N.  The way the integer MASK is interpreted is
!      that register R is in the class if ‘MASK & (1 << R)’ is 1.
  
       When the machine has more than 32 registers, an integer does not
       suffice.  Then the integers are replaced by sub-initializers,
       braced groupings containing several integers.  Each sub-initializer
!      must be suitable as an initializer for the type ‘HARD_REG_SET’
!      which is defined in ‘hard-reg-set.h’.  In this situation, the first
       integer in each sub-initializer corresponds to registers 0 through
       31, the second integer to registers 32 through 63, and so on.
  
   -- Macro: REGNO_REG_CLASS (REGNO)
       A C expression whose value is a register class containing hard
       register REGNO.  In general there is more than one such class;
!      choose a class which is “minimal”, meaning that no smaller class
       also contains the register.
  
   -- Macro: BASE_REG_CLASS
*************** return.
*** 34684,34693 ****
       address which is the register value plus a displacement.
  
   -- Macro: MODE_BASE_REG_CLASS (MODE)
!      This is a variation of the 'BASE_REG_CLASS' macro which allows the
       selection of a base register in a mode dependent manner.  If MODE
       is VOIDmode then it should return the same value as
!      'BASE_REG_CLASS'.
  
   -- Macro: MODE_BASE_REG_REG_CLASS (MODE)
       A C expression whose value is the register class to which a valid
--- 34683,34692 ----
       address which is the register value plus a displacement.
  
   -- Macro: MODE_BASE_REG_CLASS (MODE)
!      This is a variation of the ‘BASE_REG_CLASS’ macro which allows the
       selection of a base register in a mode dependent manner.  If MODE
       is VOIDmode then it should return the same value as
!      ‘BASE_REG_CLASS’.
  
   -- Macro: MODE_BASE_REG_REG_CLASS (MODE)
       A C expression whose value is the register class to which a valid
*************** return.
*** 34702,34711 ****
       base register for a memory reference in mode MODE to address space
       ADDRESS_SPACE must belong.  OUTER_CODE and INDEX_CODE define the
       context in which the base register occurs.  OUTER_CODE is the code
!      of the immediately enclosing expression ('MEM' for the top level of
!      an address, 'ADDRESS' for something that occurs in an
!      'address_operand').  INDEX_CODE is the code of the corresponding
!      index expression if OUTER_CODE is 'PLUS'; 'SCRATCH' otherwise.
  
   -- Macro: INDEX_REG_CLASS
       A macro whose definition is the name of the class to which a valid
--- 34701,34710 ----
       base register for a memory reference in mode MODE to address space
       ADDRESS_SPACE must belong.  OUTER_CODE and INDEX_CODE define the
       context in which the base register occurs.  OUTER_CODE is the code
!      of the immediately enclosing expression (‘MEM’ for the top level of
!      an address, ‘ADDRESS’ for something that occurs in an
!      ‘address_operand’).  INDEX_CODE is the code of the corresponding
!      index expression if OUTER_CODE is ‘PLUS’; ‘SCRATCH’ otherwise.
  
   -- Macro: INDEX_REG_CLASS
       A macro whose definition is the name of the class to which a valid
*************** return.
*** 34718,34731 ****
       for use as a base register in operand addresses.
  
   -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)
!      A C expression that is just like 'REGNO_OK_FOR_BASE_P', except that
       that expression may examine the mode of the memory reference in
       MODE.  You should define this macro if the mode of the memory
       reference affects whether a register may be used as a base
       register.  If you define this macro, the compiler will use it
!      instead of 'REGNO_OK_FOR_BASE_P'.  The mode may be 'VOIDmode' for
!      addresses that appear outside a 'MEM', i.e., as an
!      'address_operand'.
  
   -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE)
       A C expression which is nonzero if register number NUM is suitable
--- 34717,34730 ----
       for use as a base register in operand addresses.
  
   -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)
!      A C expression that is just like ‘REGNO_OK_FOR_BASE_P’, except that
       that expression may examine the mode of the memory reference in
       MODE.  You should define this macro if the mode of the memory
       reference affects whether a register may be used as a base
       register.  If you define this macro, the compiler will use it
!      instead of ‘REGNO_OK_FOR_BASE_P’.  The mode may be ‘VOIDmode’ for
!      addresses that appear outside a ‘MEM’, i.e., as an
!      ‘address_operand’.
  
   -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE)
       A C expression which is nonzero if register number NUM is suitable
*************** return.
*** 34737,34757 ****
       uses.
  
       Use of this macro is deprecated; please use the more general
!      'REGNO_MODE_CODE_OK_FOR_BASE_P'.
  
   -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE,
            OUTER_CODE, INDEX_CODE)
       A C expression which is nonzero if register number NUM is suitable
       for use as a base register in operand addresses, accessing memory
       in mode MODE in address space ADDRESS_SPACE.  This is similar to
!      'REGNO_MODE_OK_FOR_BASE_P', except that that expression may examine
       the context in which the register appears in the memory reference.
       OUTER_CODE is the code of the immediately enclosing expression
!      ('MEM' if at the top level of the address, 'ADDRESS' for something
!      that occurs in an 'address_operand').  INDEX_CODE is the code of
!      the corresponding index expression if OUTER_CODE is 'PLUS';
!      'SCRATCH' otherwise.  The mode may be 'VOIDmode' for addresses that
!      appear outside a 'MEM', i.e., as an 'address_operand'.
  
   -- Macro: REGNO_OK_FOR_INDEX_P (NUM)
       A C expression which is nonzero if register number NUM is suitable
--- 34736,34756 ----
       uses.
  
       Use of this macro is deprecated; please use the more general
!      ‘REGNO_MODE_CODE_OK_FOR_BASE_P’.
  
   -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE,
            OUTER_CODE, INDEX_CODE)
       A C expression which is nonzero if register number NUM is suitable
       for use as a base register in operand addresses, accessing memory
       in mode MODE in address space ADDRESS_SPACE.  This is similar to
!      ‘REGNO_MODE_OK_FOR_BASE_P’, except that that expression may examine
       the context in which the register appears in the memory reference.
       OUTER_CODE is the code of the immediately enclosing expression
!      (‘MEM’ if at the top level of the address, ‘ADDRESS’ for something
!      that occurs in an ‘address_operand’).  INDEX_CODE is the code of
!      the corresponding index expression if OUTER_CODE is ‘PLUS’;
!      ‘SCRATCH’ otherwise.  The mode may be ‘VOIDmode’ for addresses that
!      appear outside a ‘MEM’, i.e., as an ‘address_operand’.
  
   -- Macro: REGNO_OK_FOR_INDEX_P (NUM)
       A C expression which is nonzero if register number NUM is suitable
*************** return.
*** 34773,34783 ****
       A target hook that places additional preference on the register
       class to use when it is necessary to rename a register in class
       RCLASS to another class, or perhaps NO_REGS, if no preferred
!      register class is found or hook 'preferred_rename_class' is not
       implemented.  Sometimes returning a more restrictive class makes
       better code.  For example, on ARM, thumb-2 instructions using
!      'LO_REGS' may be smaller than instructions using 'GENERIC_REGS'.
!      By returning 'LO_REGS' from 'preferred_rename_class', code size can
       be reduced.
  
   -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X,
--- 34772,34782 ----
       A target hook that places additional preference on the register
       class to use when it is necessary to rename a register in class
       RCLASS to another class, or perhaps NO_REGS, if no preferred
!      register class is found or hook ‘preferred_rename_class’ is not
       implemented.  Sometimes returning a more restrictive class makes
       better code.  For example, on ARM, thumb-2 instructions using
!      ‘LO_REGS’ may be smaller than instructions using ‘GENERIC_REGS’.
!      By returning ‘LO_REGS’ from ‘preferred_rename_class’, code size can
       be reduced.
  
   -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X,
*************** return.
*** 34787,34817 ****
       in class RCLASS.  The value is a register class; perhaps RCLASS, or
       perhaps another, smaller class.
  
!      The default version of this hook always returns value of 'rclass'
       argument.
  
       Sometimes returning a more restrictive class makes better code.
       For example, on the 68000, when X is an integer constant that is in
!      range for a 'moveq' instruction, the value of this macro is always
!      'DATA_REGS' as long as RCLASS includes the data registers.
!      Requiring a data register guarantees that a 'moveq' will be used.
  
!      One case where 'TARGET_PREFERRED_RELOAD_CLASS' must not return
       RCLASS is if X is a legitimate constant which cannot be loaded into
!      some register class.  By returning 'NO_REGS' you can force X into a
       memory location.  For example, rs6000 can load immediate values
       into general-purpose registers, but does not have an instruction
       for loading an immediate value into a floating-point register, so
!      'TARGET_PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a
       floating-point constant.  If the constant can't be loaded into any
       kind of register, code generation will be better if
!      'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate
!      instead of using 'TARGET_PREFERRED_RELOAD_CLASS'.
  
       If an insn has pseudos in it after register allocation, reload will
       go through the alternatives and call repeatedly
!      'TARGET_PREFERRED_RELOAD_CLASS' to find the best one.  Returning
!      'NO_REGS', in this case, makes reload add a '!' in front of the
       constraint: the x86 back-end uses this feature to discourage usage
       of 387 registers when math is done in the SSE registers (and vice
       versa).
--- 34786,34816 ----
       in class RCLASS.  The value is a register class; perhaps RCLASS, or
       perhaps another, smaller class.
  
!      The default version of this hook always returns value of ‘rclass’
       argument.
  
       Sometimes returning a more restrictive class makes better code.
       For example, on the 68000, when X is an integer constant that is in
!      range for a ‘moveq’ instruction, the value of this macro is always
!      ‘DATA_REGS’ as long as RCLASS includes the data registers.
!      Requiring a data register guarantees that a ‘moveq’ will be used.
  
!      One case where ‘TARGET_PREFERRED_RELOAD_CLASS’ must not return
       RCLASS is if X is a legitimate constant which cannot be loaded into
!      some register class.  By returning ‘NO_REGS’ you can force X into a
       memory location.  For example, rs6000 can load immediate values
       into general-purpose registers, but does not have an instruction
       for loading an immediate value into a floating-point register, so
!      ‘TARGET_PREFERRED_RELOAD_CLASS’ returns ‘NO_REGS’ when X is a
       floating-point constant.  If the constant can't be loaded into any
       kind of register, code generation will be better if
!      ‘TARGET_LEGITIMATE_CONSTANT_P’ makes the constant illegitimate
!      instead of using ‘TARGET_PREFERRED_RELOAD_CLASS’.
  
       If an insn has pseudos in it after register allocation, reload will
       go through the alternatives and call repeatedly
!      ‘TARGET_PREFERRED_RELOAD_CLASS’ to find the best one.  Returning
!      ‘NO_REGS’, in this case, makes reload add a ‘!’ in front of the
       constraint: the x86 back-end uses this feature to discourage usage
       of 387 registers when math is done in the SSE registers (and vice
       versa).
*************** return.
*** 34827,34867 ****
  
       Sometimes returning a more restrictive class makes better code.
       For example, on the 68000, when X is an integer constant that is in
!      range for a 'moveq' instruction, the value of this macro is always
!      'DATA_REGS' as long as CLASS includes the data registers.
!      Requiring a data register guarantees that a 'moveq' will be used.
  
!      One case where 'PREFERRED_RELOAD_CLASS' must not return CLASS is if
       X is a legitimate constant which cannot be loaded into some
!      register class.  By returning 'NO_REGS' you can force X into a
       memory location.  For example, rs6000 can load immediate values
       into general-purpose registers, but does not have an instruction
       for loading an immediate value into a floating-point register, so
!      'PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a
       floating-point constant.  If the constant cannot be loaded into any
       kind of register, code generation will be better if
!      'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate
!      instead of using 'TARGET_PREFERRED_RELOAD_CLASS'.
  
       If an insn has pseudos in it after register allocation, reload will
       go through the alternatives and call repeatedly
!      'PREFERRED_RELOAD_CLASS' to find the best one.  Returning
!      'NO_REGS', in this case, makes reload add a '!' in front of the
       constraint: the x86 back-end uses this feature to discourage usage
       of 387 registers when math is done in the SSE registers (and vice
       versa).
  
   -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx
            X, reg_class_t RCLASS)
!      Like 'TARGET_PREFERRED_RELOAD_CLASS', but for output reloads
       instead of input reloads.
  
!      The default version of this hook always returns value of 'rclass'
       argument.
  
!      You can also use 'TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to
       discourage reload from using some alternatives, like
!      'TARGET_PREFERRED_RELOAD_CLASS'.
  
   -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS)
       A C expression that places additional restrictions on the register
--- 34826,34866 ----
  
       Sometimes returning a more restrictive class makes better code.
       For example, on the 68000, when X is an integer constant that is in
!      range for a ‘moveq’ instruction, the value of this macro is always
!      ‘DATA_REGS’ as long as CLASS includes the data registers.
!      Requiring a data register guarantees that a ‘moveq’ will be used.
  
!      One case where ‘PREFERRED_RELOAD_CLASS’ must not return CLASS is if
       X is a legitimate constant which cannot be loaded into some
!      register class.  By returning ‘NO_REGS’ you can force X into a
       memory location.  For example, rs6000 can load immediate values
       into general-purpose registers, but does not have an instruction
       for loading an immediate value into a floating-point register, so
!      ‘PREFERRED_RELOAD_CLASS’ returns ‘NO_REGS’ when X is a
       floating-point constant.  If the constant cannot be loaded into any
       kind of register, code generation will be better if
!      ‘TARGET_LEGITIMATE_CONSTANT_P’ makes the constant illegitimate
!      instead of using ‘TARGET_PREFERRED_RELOAD_CLASS’.
  
       If an insn has pseudos in it after register allocation, reload will
       go through the alternatives and call repeatedly
!      ‘PREFERRED_RELOAD_CLASS’ to find the best one.  Returning
!      ‘NO_REGS’, in this case, makes reload add a ‘!’ in front of the
       constraint: the x86 back-end uses this feature to discourage usage
       of 387 registers when math is done in the SSE registers (and vice
       versa).
  
   -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx
            X, reg_class_t RCLASS)
!      Like ‘TARGET_PREFERRED_RELOAD_CLASS’, but for output reloads
       instead of input reloads.
  
!      The default version of this hook always returns value of ‘rclass’
       argument.
  
!      You can also use ‘TARGET_PREFERRED_OUTPUT_RELOAD_CLASS’ to
       discourage reload from using some alternatives, like
!      ‘TARGET_PREFERRED_RELOAD_CLASS’.
  
   -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS)
       A C expression that places additional restrictions on the register
*************** return.
*** 34869,34875 ****
       mode MODE in a reload register for which class CLASS would
       ordinarily be used.
  
!      Unlike 'PREFERRED_RELOAD_CLASS', this macro should be used when
       there are certain modes that simply cannot go in certain reload
       classes.
  
--- 34868,34874 ----
       mode MODE in a reload register for which class CLASS would
       ordinarily be used.
  
!      Unlike ‘PREFERRED_RELOAD_CLASS’, this macro should be used when
       there are certain modes that simply cannot go in certain reload
       classes.
  
*************** return.
*** 34884,34890 ****
            secondary_reload_info *SRI)
       Many machines have some registers that cannot be copied directly to
       or from memory or even from other types of registers.  An example
!      is the 'MQ' register, which on most machines, can only be copied to
       or from general registers, but not memory.  Below, we shall be
       using the term 'intermediate register' when a move operation cannot
       be performed directly, but has to be done by copying the source
--- 34883,34889 ----
            secondary_reload_info *SRI)
       Many machines have some registers that cannot be copied directly to
       or from memory or even from other types of registers.  An example
!      is the ‘MQ’ register, which on most machines, can only be copied to
       or from general registers, but not memory.  Below, we shall be
       using the term 'intermediate register' when a move operation cannot
       be performed directly, but has to be done by copying the source
*************** return.
*** 34917,34923 ****
       needs to be copied to rtx X in RELOAD_MODE.
  
       If copying a register of RELOAD_CLASS from/to X requires an
!      intermediate register, the hook 'secondary_reload' should return
       the register class required for this intermediate register.  If no
       intermediate register is required, it should return NO_REGS. If
       more than one intermediate register is required, describe the one
--- 34916,34922 ----
       needs to be copied to rtx X in RELOAD_MODE.
  
       If copying a register of RELOAD_CLASS from/to X requires an
!      intermediate register, the hook ‘secondary_reload’ should return
       the register class required for this intermediate register.  If no
       intermediate register is required, it should return NO_REGS. If
       more than one intermediate register is required, describe the one
*************** return.
*** 34929,34996 ****
       but still a scratch register is needed, describe the copy from/to
       the reload register to/from the reload operand X.
  
!      You do this by setting 'sri->icode' to the instruction code of a
       pattern in the md file which performs the move.  Operands 0 and 1
       are the output and input of this copy, respectively.  Operands from
       operand 2 onward are for scratch operands.  These scratch operands
       must have a mode, and a single-register-class output constraint.
  
!      When an intermediate register is used, the 'secondary_reload' hook
       will be called again to determine how to copy the intermediate
       register to/from the reload operand X, so your hook must also have
       code to handle the register class of the intermediate operand.
  
!      X might be a pseudo-register or a 'subreg' of a pseudo-register,
       which could either be in a hard register or in memory.  Use
!      'true_regnum' to find out; it will return -1 if the pseudo is in
       memory and the hard register number if it is in a register.
  
!      Scratch operands in memory (constraint '"=m"' / '"=&m"') are
       currently not supported.  For the time being, you will have to
!      continue to use 'TARGET_SECONDARY_MEMORY_NEEDED' for that purpose.
  
!      'copy_cost' also uses this target hook to find out how values are
       copied.  If you want it to include some extra cost for the need to
!      allocate (a) scratch register(s), set 'sri->extra_cost' to the
       additional cost.  Or if two dependent moves are supposed to have a
       lower cost than the sum of the individual moves due to expected
       fortuitous scheduling and/or special forwarding logic, you can set
!      'sri->extra_cost' to a negative amount.
  
   -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X)
   -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)
   -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)
       These macros are obsolete, new ports should use the target hook
!      'TARGET_SECONDARY_RELOAD' instead.
  
       These are obsolete macros, replaced by the
!      'TARGET_SECONDARY_RELOAD' target hook.  Older ports still define
       these macros to indicate to the reload phase that it may need to
       allocate at least one register for a reload in addition to the
       register to contain the data.  Specifically, if copying X to a
       register CLASS in MODE requires an intermediate register, you were
!      supposed to define 'SECONDARY_INPUT_RELOAD_CLASS' to return the
       largest register class all of whose registers can be used as
       intermediate registers or scratch registers.
  
       If copying a register CLASS in MODE to X requires an intermediate
!      or scratch register, 'SECONDARY_OUTPUT_RELOAD_CLASS' was supposed
       to be defined to return the largest register class required.  If
       the requirements for input and output reloads were the same, the
!      macro 'SECONDARY_RELOAD_CLASS' should have been used instead of
       defining both macros identically.
  
!      The values returned by these macros are often 'GENERAL_REGS'.
!      Return 'NO_REGS' if no spare register is needed; i.e., if X can be
       directly copied to or from a register of CLASS in MODE without
       requiring a scratch register.  Do not define this macro if it would
!      always return 'NO_REGS'.
  
       If a scratch register is required (either with or without an
       intermediate register), you were supposed to define patterns for
!      'reload_inM' or 'reload_outM', as required (*note Standard Names::.
       These patterns, which were normally implemented with a
!      'define_expand', should be similar to the 'movM' patterns, except
       that operand 2 is the scratch register.
  
       These patterns need constraints for the reload register and scratch
--- 34928,34995 ----
       but still a scratch register is needed, describe the copy from/to
       the reload register to/from the reload operand X.
  
!      You do this by setting ‘sri->icode’ to the instruction code of a
       pattern in the md file which performs the move.  Operands 0 and 1
       are the output and input of this copy, respectively.  Operands from
       operand 2 onward are for scratch operands.  These scratch operands
       must have a mode, and a single-register-class output constraint.
  
!      When an intermediate register is used, the ‘secondary_reload’ hook
       will be called again to determine how to copy the intermediate
       register to/from the reload operand X, so your hook must also have
       code to handle the register class of the intermediate operand.
  
!      X might be a pseudo-register or a ‘subreg’ of a pseudo-register,
       which could either be in a hard register or in memory.  Use
!      ‘true_regnum’ to find out; it will return −1 if the pseudo is in
       memory and the hard register number if it is in a register.
  
!      Scratch operands in memory (constraint ‘"=m"’ / ‘"=&m"’) are
       currently not supported.  For the time being, you will have to
!      continue to use ‘TARGET_SECONDARY_MEMORY_NEEDED’ for that purpose.
  
!      ‘copy_cost’ also uses this target hook to find out how values are
       copied.  If you want it to include some extra cost for the need to
!      allocate (a) scratch register(s), set ‘sri->extra_cost’ to the
       additional cost.  Or if two dependent moves are supposed to have a
       lower cost than the sum of the individual moves due to expected
       fortuitous scheduling and/or special forwarding logic, you can set
!      ‘sri->extra_cost’ to a negative amount.
  
   -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X)
   -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)
   -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)
       These macros are obsolete, new ports should use the target hook
!      ‘TARGET_SECONDARY_RELOAD’ instead.
  
       These are obsolete macros, replaced by the
!      ‘TARGET_SECONDARY_RELOAD’ target hook.  Older ports still define
       these macros to indicate to the reload phase that it may need to
       allocate at least one register for a reload in addition to the
       register to contain the data.  Specifically, if copying X to a
       register CLASS in MODE requires an intermediate register, you were
!      supposed to define ‘SECONDARY_INPUT_RELOAD_CLASS’ to return the
       largest register class all of whose registers can be used as
       intermediate registers or scratch registers.
  
       If copying a register CLASS in MODE to X requires an intermediate
!      or scratch register, ‘SECONDARY_OUTPUT_RELOAD_CLASS’ was supposed
       to be defined to return the largest register class required.  If
       the requirements for input and output reloads were the same, the
!      macro ‘SECONDARY_RELOAD_CLASS’ should have been used instead of
       defining both macros identically.
  
!      The values returned by these macros are often ‘GENERAL_REGS’.
!      Return ‘NO_REGS’ if no spare register is needed; i.e., if X can be
       directly copied to or from a register of CLASS in MODE without
       requiring a scratch register.  Do not define this macro if it would
!      always return ‘NO_REGS’.
  
       If a scratch register is required (either with or without an
       intermediate register), you were supposed to define patterns for
!      ‘reload_inM’ or ‘reload_outM’, as required (*note Standard Names::.
       These patterns, which were normally implemented with a
!      ‘define_expand’, should be similar to the ‘movM’ patterns, except
       that operand 2 is the scratch register.
  
       These patterns need constraints for the reload register and scratch
*************** return.
*** 35001,35016 ****
       reload registers are required.  Their classes are obtained from the
       constraints in the insn pattern.
  
!      X might be a pseudo-register or a 'subreg' of a pseudo-register,
       which could either be in a hard register or in memory.  Use
!      'true_regnum' to find out; it will return -1 if the pseudo is in
       memory and the hard register number if it is in a register.
  
       These macros should not be used in the case where a particular
       class of registers can only be copied to memory and not to another
       class of registers.  In that case, secondary reload registers are
       not needed and would not be helpful.  Instead, a stack location
!      must be used to perform the copy and the 'movM' pattern should use
       memory as an intermediate storage.  This case often occurs between
       floating-point and general registers.
  
--- 35000,35015 ----
       reload registers are required.  Their classes are obtained from the
       constraints in the insn pattern.
  
!      X might be a pseudo-register or a ‘subreg’ of a pseudo-register,
       which could either be in a hard register or in memory.  Use
!      ‘true_regnum’ to find out; it will return −1 if the pseudo is in
       memory and the hard register number if it is in a register.
  
       These macros should not be used in the case where a particular
       class of registers can only be copied to memory and not to another
       class of registers.  In that case, secondary reload registers are
       not needed and would not be helpful.  Instead, a stack location
!      must be used to perform the copy and the ‘movM’ pattern should use
       memory as an intermediate storage.  This case often occurs between
       floating-point and general registers.
  
*************** return.
*** 35025,35045 ****
       false for all inputs.
  
   -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE)
!      Normally when 'TARGET_SECONDARY_MEMORY_NEEDED' is defined, the
       compiler allocates a stack slot for a memory location needed for
       register copies.  If this macro is defined, the compiler instead
       uses the memory location defined by this macro.
  
       Do not define this macro if you do not define
!      'TARGET_SECONDARY_MEMORY_NEEDED'.
  
   -- Target Hook: machine_mode TARGET_SECONDARY_MEMORY_NEEDED_MODE
            (machine_mode MODE)
!      If 'TARGET_SECONDARY_MEMORY_NEEDED' tells the compiler to use
       memory when moving between two particular registers of mode MODE,
       this hook specifies the mode that the memory should have.
  
!      The default depends on 'TARGET_LRA_P'.  Without LRA, the default is
       to use a word-sized mode for integral modes that are smaller than a
       a word.  This is right thing to do on most machines because it
       ensures that all bits of the register are copied and prevents
--- 35024,35044 ----
       false for all inputs.
  
   -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE)
!      Normally when ‘TARGET_SECONDARY_MEMORY_NEEDED’ is defined, the
       compiler allocates a stack slot for a memory location needed for
       register copies.  If this macro is defined, the compiler instead
       uses the memory location defined by this macro.
  
       Do not define this macro if you do not define
!      ‘TARGET_SECONDARY_MEMORY_NEEDED’.
  
   -- Target Hook: machine_mode TARGET_SECONDARY_MEMORY_NEEDED_MODE
            (machine_mode MODE)
!      If ‘TARGET_SECONDARY_MEMORY_NEEDED’ tells the compiler to use
       memory when moving between two particular registers of mode MODE,
       this hook specifies the mode that the memory should have.
  
!      The default depends on ‘TARGET_LRA_P’.  Without LRA, the default is
       to use a word-sized mode for integral modes that are smaller than a
       a word.  This is right thing to do on most machines because it
       ensures that all bits of the register are copied and prevents
*************** return.
*** 35051,35057 ****
       registers differently than in integer registers.  On those
       machines, the default widening will not work correctly and you must
       define this hook to suppress that widening in some cases.  See the
!      file 'alpha.cc' for details.
  
       With LRA, the default is to use MODE unmodified.
  
--- 35050,35056 ----
       registers differently than in integer registers.  On those
       machines, the default widening will not work correctly and you must
       define this hook to suppress that widening in some cases.  See the
!      file ‘alpha.cc’ for details.
  
       With LRA, the default is to use MODE unmodified.
  
*************** return.
*** 35067,35078 ****
       has the effect of disabling the early rematerialization pass.
  
   -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS)
!      A target hook which returns 'true' if pseudos that have been
       assigned to registers of class RCLASS would likely be spilled
       because registers of RCLASS are needed for spill registers.
  
!      The default version of this target hook returns 'true' if RCLASS
!      has exactly one register and 'false' otherwise.  On most machines,
       this default should be used.  For generally register-starved
       machines, such as i386, or machines with right register
       constraints, such as SH, this hook can be used to avoid excessive
--- 35066,35077 ----
       has the effect of disabling the early rematerialization pass.
  
   -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS)
!      A target hook which returns ‘true’ if pseudos that have been
       assigned to registers of class RCLASS would likely be spilled
       because registers of RCLASS are needed for spill registers.
  
!      The default version of this target hook returns ‘true’ if RCLASS
!      has exactly one register and ‘false’ otherwise.  On most machines,
       this default should be used.  For generally register-starved
       machines, such as i386, or machines with right register
       constraints, such as SH, this hook can be used to avoid excessive
*************** return.
*** 35087,35096 ****
       A target hook returns the maximum number of consecutive registers
       of class RCLASS needed to hold a value of mode MODE.
  
!      This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'.  In
!      fact, the value returned by 'TARGET_CLASS_MAX_NREGS (RCLASS, MODE)'
!      target hook should be the maximum value of 'TARGET_HARD_REGNO_NREGS
!      (REGNO, MODE)' for all REGNO values in the class RCLASS.
  
       This target hook helps control the handling of multiple-word values
       in the reload pass.
--- 35086,35095 ----
       A target hook returns the maximum number of consecutive registers
       of class RCLASS needed to hold a value of mode MODE.
  
!      This is closely related to the macro ‘TARGET_HARD_REGNO_NREGS’.  In
!      fact, the value returned by ‘TARGET_CLASS_MAX_NREGS (RCLASS, MODE)’
!      target hook should be the maximum value of ‘TARGET_HARD_REGNO_NREGS
!      (REGNO, MODE)’ for all REGNO values in the class RCLASS.
  
       This target hook helps control the handling of multiple-word values
       in the reload pass.
*************** return.
*** 35102,35110 ****
       A C expression for the maximum number of consecutive registers of
       class CLASS needed to hold a value of mode MODE.
  
!      This is closely related to the macro 'TARGET_HARD_REGNO_NREGS'.  In
!      fact, the value of the macro 'CLASS_MAX_NREGS (CLASS, MODE)' should
!      be the maximum value of 'TARGET_HARD_REGNO_NREGS (REGNO, MODE)' for
       all REGNO values in the class CLASS.
  
       This macro helps control the handling of multiple-word values in
--- 35101,35109 ----
       A C expression for the maximum number of consecutive registers of
       class CLASS needed to hold a value of mode MODE.
  
!      This is closely related to the macro ‘TARGET_HARD_REGNO_NREGS’.  In
!      fact, the value of the macro ‘CLASS_MAX_NREGS (CLASS, MODE)’ should
!      be the maximum value of ‘TARGET_HARD_REGNO_NREGS (REGNO, MODE)’ for
       all REGNO values in the class CLASS.
  
       This macro helps control the handling of multiple-word values in
*************** return.
*** 35116,35140 ****
       registers of class RCLASS from mode FROM to mode TO and if doing so
       preserves the low-order bits that are common to both modes.  The
       result is only meaningful if RCLASS has registers that can hold
!      both 'from' and 'to'.  The default implementation returns true.
  
       As an example of when such bitcasting is invalid, loading 32-bit
       integer or floating-point objects into floating-point registers on
       Alpha extends them to 64 bits.  Therefore loading a 64-bit object
       and then storing it as a 32-bit object does not store the low-order
       32 bits, as would be the case for a normal register.  Therefore,
!      'alpha.h' defines 'TARGET_CAN_CHANGE_MODE_CLASS' to return:
  
            (GET_MODE_SIZE (from) == GET_MODE_SIZE (to)
             || !reg_classes_intersect_p (FLOAT_REGS, rclass))
  
       Even if storing from a register in mode TO would be valid, if both
!      FROM and 'raw_reg_mode' for RCLASS are wider than 'word_mode', then
       we must prevent TO narrowing the mode.  This happens when the
       middle-end assumes that it can load or store pieces of an N-word
       pseudo, and that the pseudo will eventually be allocated to N
!      'word_mode' hard registers.  Failure to prevent this kind of mode
!      change will result in the entire 'raw_reg_mode' being modified
       instead of the partial value that the middle-end intended.
  
   -- Target Hook: reg_class_t TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS
--- 35115,35139 ----
       registers of class RCLASS from mode FROM to mode TO and if doing so
       preserves the low-order bits that are common to both modes.  The
       result is only meaningful if RCLASS has registers that can hold
!      both ‘from’ and ‘to’.  The default implementation returns true.
  
       As an example of when such bitcasting is invalid, loading 32-bit
       integer or floating-point objects into floating-point registers on
       Alpha extends them to 64 bits.  Therefore loading a 64-bit object
       and then storing it as a 32-bit object does not store the low-order
       32 bits, as would be the case for a normal register.  Therefore,
!      ‘alpha.h’ defines ‘TARGET_CAN_CHANGE_MODE_CLASS’ to return:
  
            (GET_MODE_SIZE (from) == GET_MODE_SIZE (to)
             || !reg_classes_intersect_p (FLOAT_REGS, rclass))
  
       Even if storing from a register in mode TO would be valid, if both
!      FROM and ‘raw_reg_mode’ for RCLASS are wider than ‘word_mode’, then
       we must prevent TO narrowing the mode.  This happens when the
       middle-end assumes that it can load or store pieces of an N-word
       pseudo, and that the pseudo will eventually be allocated to N
!      ‘word_mode’ hard registers.  Failure to prevent this kind of mode
!      change will result in the entire ‘raw_reg_mode’ being modified
       instead of the partial value that the middle-end intended.
  
   -- Target Hook: reg_class_t TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS
*************** return.
*** 35183,35191 ****
       The default version of this target hook returns always false.
  
   -- Target Hook: bool TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P (rtx SUBST)
!      A target hook which returns 'true' if SUBST can't substitute safely
       pseudos with equivalent memory values during register allocation.
!      The default version of this target hook returns 'false'.  On most
       machines, this default should be used.  For generally machines with
       non orthogonal register usage for addressing, such as SH, this hook
       can be used to avoid excessive spilling.
--- 35182,35190 ----
       The default version of this target hook returns always false.
  
   -- Target Hook: bool TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P (rtx SUBST)
!      A target hook which returns ‘true’ if SUBST can't substitute safely
       pseudos with equivalent memory values during register allocation.
!      The default version of this target hook returns ‘false’.  On most
       machines, this default should be used.  For generally machines with
       non orthogonal register usage for addressing, such as SH, this hook
       can be used to avoid excessive spilling.
*************** return.
*** 35207,35223 ****
   -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t,
            MACHINE_MODE)
       This hook defines a class of registers which could be used for
!      spilling pseudos of the given mode and class, or 'NO_REGS' if only
       memory should be used.  Not defining this hook is equivalent to
!      returning 'NO_REGS' for all inputs.
  
   -- Target Hook: bool TARGET_ADDITIONAL_ALLOCNO_CLASS_P (reg_class_t)
!      This hook should return 'true' if given class of registers should
       be an allocno class in any way.  Usually RA uses only one register
       class from all classes containing the same register set.  In some
       complicated cases, you need to have two or more such classes as
       allocno ones for RA correct work.  Not defining this hook is
!      equivalent to returning 'false' for all inputs.
  
   -- Target Hook: scalar_int_mode TARGET_CSTORE_MODE (enum insn_code
            ICODE)
--- 35206,35222 ----
   -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t,
            MACHINE_MODE)
       This hook defines a class of registers which could be used for
!      spilling pseudos of the given mode and class, or ‘NO_REGS’ if only
       memory should be used.  Not defining this hook is equivalent to
!      returning ‘NO_REGS’ for all inputs.
  
   -- Target Hook: bool TARGET_ADDITIONAL_ALLOCNO_CLASS_P (reg_class_t)
!      This hook should return ‘true’ if given class of registers should
       be an allocno class in any way.  Usually RA uses only one register
       class from all classes containing the same register set.  In some
       complicated cases, you need to have two or more such classes as
       allocno ones for RA correct work.  Not defining this hook is
!      equivalent to returning ‘false’ for all inputs.
  
   -- Target Hook: scalar_int_mode TARGET_CSTORE_MODE (enum insn_code
            ICODE)
*************** Here is the basic stack layout.
*** 35276,35291 ****
  
   -- Macro: STACK_PUSH_CODE
       This macro defines the operation used when something is pushed on
!      the stack.  In RTL, a push operation will be '(set (mem
!      (STACK_PUSH_CODE (reg sp))) ...)'
  
!      The choices are 'PRE_DEC', 'POST_DEC', 'PRE_INC', and 'POST_INC'.
       Which of these is correct depends on the stack direction and on
       whether the stack pointer points to the last item on the stack or
       whether it points to the space for the next item on the stack.
  
!      The default is 'PRE_DEC' when 'STACK_GROWS_DOWNWARD' is true, which
!      is almost always right, and 'PRE_INC' otherwise, which is often
       wrong.
  
   -- Macro: FRAME_GROWS_DOWNWARD
--- 35275,35290 ----
  
   -- Macro: STACK_PUSH_CODE
       This macro defines the operation used when something is pushed on
!      the stack.  In RTL, a push operation will be ‘(set (mem
!      (STACK_PUSH_CODE (reg sp))) ...)’
  
!      The choices are ‘PRE_DEC’, ‘POST_DEC’, ‘PRE_INC’, and ‘POST_INC’.
       Which of these is correct depends on the stack direction and on
       whether the stack pointer points to the last item on the stack or
       whether it points to the space for the next item on the stack.
  
!      The default is ‘PRE_DEC’ when ‘STACK_GROWS_DOWNWARD’ is true, which
!      is almost always right, and ‘PRE_INC’ otherwise, which is often
       wrong.
  
   -- Macro: FRAME_GROWS_DOWNWARD
*************** Here is the basic stack layout.
*** 35298,35304 ****
  
   -- Target Hook: HOST_WIDE_INT TARGET_STARTING_FRAME_OFFSET (void)
       This hook returns the offset from the frame pointer to the first
!      local variable slot to be allocated.  If 'FRAME_GROWS_DOWNWARD', it
       is the offset to _end_ of the first slot allocated, otherwise it is
       the offset to _beginning_ of the first slot allocated.  The default
       implementation returns 0.
--- 35297,35303 ----
  
   -- Target Hook: HOST_WIDE_INT TARGET_STARTING_FRAME_OFFSET (void)
       This hook returns the offset from the frame pointer to the first
!      local variable slot to be allocated.  If ‘FRAME_GROWS_DOWNWARD’, it
       is the offset to _end_ of the first slot allocated, otherwise it is
       the offset to _beginning_ of the first slot allocated.  The default
       implementation returns 0.
*************** Here is the basic stack layout.
*** 35308,35316 ****
       reload.  The nonzero default for this macro is suitable for most
       ports.
  
!      On ports where 'TARGET_STARTING_FRAME_OFFSET' is nonzero or where
       there is a register save block following the local block that
!      doesn't require alignment to 'STACK_BOUNDARY', it may be beneficial
       to disable stack alignment and do it in the backend.
  
   -- Macro: STACK_POINTER_OFFSET
--- 35307,35315 ----
       reload.  The nonzero default for this macro is suitable for most
       ports.
  
!      On ports where ‘TARGET_STARTING_FRAME_OFFSET’ is nonzero or where
       there is a register save block following the local block that
!      doesn't require alignment to ‘STACK_BOUNDARY’, it may be beneficial
       to disable stack alignment and do it in the backend.
  
   -- Macro: STACK_POINTER_OFFSET
*************** Here is the basic stack layout.
*** 35318,35324 ****
       which outgoing arguments are placed.  If not specified, the default
       value of zero is used.  This is the proper value for most machines.
  
!      If 'ARGS_GROW_DOWNWARD', this is the offset to the location above
       the first location at which outgoing arguments are placed.
  
   -- Macro: FIRST_PARM_OFFSET (FUNDECL)
--- 35317,35323 ----
       which outgoing arguments are placed.  If not specified, the default
       value of zero is used.  This is the proper value for most machines.
  
!      If ‘ARGS_GROW_DOWNWARD’, this is the offset to the location above
       the first location at which outgoing arguments are placed.
  
   -- Macro: FIRST_PARM_OFFSET (FUNDECL)
*************** Here is the basic stack layout.
*** 35326,35350 ****
       address.  On some machines it may depend on the data type of the
       function.
  
!      If 'ARGS_GROW_DOWNWARD', this is the offset to the location above
       the first argument's address.
  
   -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL)
       Offset from the stack pointer register to an item dynamically
!      allocated on the stack, e.g., by 'alloca'.
  
!      The default value for this macro is 'STACK_POINTER_OFFSET' plus the
       length of the outgoing arguments.  The default is correct for most
!      machines.  See 'function.cc' for details.
  
   -- Macro: INITIAL_FRAME_ADDRESS_RTX
       A C expression whose value is RTL representing the address of the
!      initial stack frame.  This address is passed to 'RETURN_ADDR_RTX'
!      and 'DYNAMIC_CHAIN_ADDRESS'.  If you don't define this macro, a
       reasonable default value will be used.  Define this macro in order
       to make frame pointer elimination work in the presence of
!      '__builtin_frame_address (count)' and '__builtin_return_address
!      (count)' for 'count' not equal to zero.
  
   -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)
       A C expression whose value is RTL representing the address in a
--- 35325,35349 ----
       address.  On some machines it may depend on the data type of the
       function.
  
!      If ‘ARGS_GROW_DOWNWARD’, this is the offset to the location above
       the first argument's address.
  
   -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL)
       Offset from the stack pointer register to an item dynamically
!      allocated on the stack, e.g., by ‘alloca’.
  
!      The default value for this macro is ‘STACK_POINTER_OFFSET’ plus the
       length of the outgoing arguments.  The default is correct for most
!      machines.  See ‘function.cc’ for details.
  
   -- Macro: INITIAL_FRAME_ADDRESS_RTX
       A C expression whose value is RTL representing the address of the
!      initial stack frame.  This address is passed to ‘RETURN_ADDR_RTX’
!      and ‘DYNAMIC_CHAIN_ADDRESS’.  If you don't define this macro, a
       reasonable default value will be used.  Define this macro in order
       to make frame pointer elimination work in the presence of
!      ‘__builtin_frame_address (count)’ and ‘__builtin_return_address
!      (count)’ for ‘count’ not equal to zero.
  
   -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)
       A C expression whose value is RTL representing the address in a
*************** Here is the basic stack layout.
*** 35365,35374 ****
  
   -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void)
       This target hook should return an rtx that is used to store the
!      address of the current frame into the built in 'setjmp' buffer.
!      The default value, 'virtual_stack_vars_rtx', is correct for most
       machines.  One reason you may need to define this target hook is if
!      'hard_frame_pointer_rtx' is the appropriate value on your machine.
  
   -- Macro: FRAME_ADDR_RTX (FRAMEADDR)
       A C expression whose value is RTL representing the value of the
--- 35364,35373 ----
  
   -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void)
       This target hook should return an rtx that is used to store the
!      address of the current frame into the built in ‘setjmp’ buffer.
!      The default value, ‘virtual_stack_vars_rtx’, is correct for most
       machines.  One reason you may need to define this target hook is if
!      ‘hard_frame_pointer_rtx’ is the appropriate value on your machine.
  
   -- Macro: FRAME_ADDR_RTX (FRAMEADDR)
       A C expression whose value is RTL representing the value of the
*************** Here is the basic stack layout.
*** 35382,35392 ****
       A C expression whose value is RTL representing the value of the
       return address for the frame COUNT steps up from the current frame,
       after the prologue.  FRAMEADDR is the frame pointer of the COUNT
!      frame, or the frame pointer of the COUNT - 1 frame if
!      'RETURN_ADDR_IN_PREVIOUS_FRAME' is nonzero.
  
       The value of the expression must always be the correct address when
!      COUNT is zero, but may be 'NULL_RTX' if there is no way to
       determine the return address of other frames.
  
   -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME
--- 35381,35391 ----
       A C expression whose value is RTL representing the value of the
       return address for the frame COUNT steps up from the current frame,
       after the prologue.  FRAMEADDR is the frame pointer of the COUNT
!      frame, or the frame pointer of the COUNT − 1 frame if
!      ‘RETURN_ADDR_IN_PREVIOUS_FRAME’ is nonzero.
  
       The value of the expression must always be the correct address when
!      COUNT is zero, but may be ‘NULL_RTX’ if there is no way to
       determine the return address of other frames.
  
   -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME
*************** Here is the basic stack layout.
*** 35398,35420 ****
   -- Macro: INCOMING_RETURN_ADDR_RTX
       A C expression whose value is RTL representing the location of the
       incoming return address at the beginning of any function, before
!      the prologue.  This RTL is either a 'REG', indicating that the
!      return value is saved in 'REG', or a 'MEM' representing a location
       in the stack.
  
       You only need to define this macro if you want to support call
       frame debugging information like that provided by DWARF 2.
  
!      If this RTL is a 'REG', you should also define
!      'DWARF_FRAME_RETURN_COLUMN' to 'DWARF_FRAME_REGNUM (REGNO)'.
  
   -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN
       A C expression whose value is an integer giving a DWARF 2 column
       number that may be used as an alternative return column.  The
       column must not correspond to any gcc hard register (that is, it
!      must not be in the range of 'DWARF_FRAME_REGNUM').
  
!      This macro can be useful if 'DWARF_FRAME_RETURN_COLUMN' is set to a
       general register, but an alternative column needs to be used for
       signal frames.  Some targets have also used different frame return
       columns over time.
--- 35397,35419 ----
   -- Macro: INCOMING_RETURN_ADDR_RTX
       A C expression whose value is RTL representing the location of the
       incoming return address at the beginning of any function, before
!      the prologue.  This RTL is either a ‘REG’, indicating that the
!      return value is saved in ‘REG’, or a ‘MEM’ representing a location
       in the stack.
  
       You only need to define this macro if you want to support call
       frame debugging information like that provided by DWARF 2.
  
!      If this RTL is a ‘REG’, you should also define
!      ‘DWARF_FRAME_RETURN_COLUMN’ to ‘DWARF_FRAME_REGNUM (REGNO)’.
  
   -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN
       A C expression whose value is an integer giving a DWARF 2 column
       number that may be used as an alternative return column.  The
       column must not correspond to any gcc hard register (that is, it
!      must not be in the range of ‘DWARF_FRAME_REGNUM’).
  
!      This macro can be useful if ‘DWARF_FRAME_RETURN_COLUMN’ is set to a
       general register, but an alternative column needs to be used for
       signal frames.  Some targets have also used different frame return
       columns over time.
*************** Here is the basic stack layout.
*** 35430,35436 ****
   -- Macro: DWARF_VERSION_DEFAULT
       A C expression whose value is the default dwarf standard version
       we'll honor and advertise when generating dwarf debug information,
!      in absence of an explicit '-gdwarf-VERSION' option on the command
       line.
  
   -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char
--- 35429,35435 ----
   -- Macro: DWARF_VERSION_DEFAULT
       A C expression whose value is the default dwarf standard version
       we'll honor and advertise when generating dwarf debug information,
!      in absence of an explicit ‘-gdwarf-VERSION’ option on the command
       line.
  
   -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char
*************** Here is the basic stack layout.
*** 35443,35460 ****
            (set (reg) (unspec_volatile [...] UNSPECV_INDEX)).
       to let the backend emit the call frame instructions.  LABEL is the
       CFI label attached to the insn, PATTERN is the pattern of the insn
!      and INDEX is 'UNSPEC_INDEX' or 'UNSPECV_INDEX'.
  
   -- Target Hook: unsigned int TARGET_DWARF_POLY_INDETERMINATE_VALUE
            (unsigned int I, unsigned int *FACTOR, int *OFFSET)
!      Express the value of 'poly_int' indeterminate I as a DWARF
       expression, with I counting from 1.  Return the number of a DWARF
!      register R and set '*FACTOR' and '*OFFSET' such that the value of
       the indeterminate is:
            value_of(R) / FACTOR - OFFSET
  
       A target only needs to define this hook if it sets
!      'NUM_POLY_INT_COEFFS' to a value greater than 1.
  
   -- Macro: INCOMING_FRAME_SP_OFFSET
       A C expression whose value is an integer giving the offset, in
--- 35442,35459 ----
            (set (reg) (unspec_volatile [...] UNSPECV_INDEX)).
       to let the backend emit the call frame instructions.  LABEL is the
       CFI label attached to the insn, PATTERN is the pattern of the insn
!      and INDEX is ‘UNSPEC_INDEX’ or ‘UNSPECV_INDEX’.
  
   -- Target Hook: unsigned int TARGET_DWARF_POLY_INDETERMINATE_VALUE
            (unsigned int I, unsigned int *FACTOR, int *OFFSET)
!      Express the value of ‘poly_int’ indeterminate I as a DWARF
       expression, with I counting from 1.  Return the number of a DWARF
!      register R and set ‘*FACTOR’ and ‘*OFFSET’ such that the value of
       the indeterminate is:
            value_of(R) / FACTOR - OFFSET
  
       A target only needs to define this hook if it sets
!      ‘NUM_POLY_INT_COEFFS’ to a value greater than 1.
  
   -- Macro: INCOMING_FRAME_SP_OFFSET
       A C expression whose value is an integer giving the offset, in
*************** Here is the basic stack layout.
*** 35468,35489 ****
       frame debugging information like that provided by DWARF 2.
  
   -- Macro: DEFAULT_INCOMING_FRAME_SP_OFFSET
!      Like 'INCOMING_FRAME_SP_OFFSET', but must be the same for all
!      functions of the same ABI, and when using GAS '.cfi_*' directives
       must also agree with the default CFI GAS emits.  Define this macro
!      only if 'INCOMING_FRAME_SP_OFFSET' can have different values
       between different functions of the same ABI or when
!      'INCOMING_FRAME_SP_OFFSET' does not agree with GAS default CFI.
  
   -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL)
       A C expression whose value is an integer giving the offset, in
       bytes, from the argument pointer to the canonical frame address
       (cfa).  The final value should coincide with that calculated by
!      'INCOMING_FRAME_SP_OFFSET'.  Which is unfortunately not usable
       during virtual register instantiation.
  
!      The default value for this macro is 'FIRST_PARM_OFFSET (fundecl) +
!      crtl->args.pretend_args_size', which is correct for most machines;
       in general, the arguments are found immediately before the stack
       frame.  Note that this is not the case on some targets that save
       registers into the caller's frame, such as SPARC and rs6000, and so
--- 35467,35488 ----
       frame debugging information like that provided by DWARF 2.
  
   -- Macro: DEFAULT_INCOMING_FRAME_SP_OFFSET
!      Like ‘INCOMING_FRAME_SP_OFFSET’, but must be the same for all
!      functions of the same ABI, and when using GAS ‘.cfi_*’ directives
       must also agree with the default CFI GAS emits.  Define this macro
!      only if ‘INCOMING_FRAME_SP_OFFSET’ can have different values
       between different functions of the same ABI or when
!      ‘INCOMING_FRAME_SP_OFFSET’ does not agree with GAS default CFI.
  
   -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL)
       A C expression whose value is an integer giving the offset, in
       bytes, from the argument pointer to the canonical frame address
       (cfa).  The final value should coincide with that calculated by
!      ‘INCOMING_FRAME_SP_OFFSET’.  Which is unfortunately not usable
       during virtual register instantiation.
  
!      The default value for this macro is ‘FIRST_PARM_OFFSET (fundecl) +
!      crtl->args.pretend_args_size’, which is correct for most machines;
       in general, the arguments are found immediately before the stack
       frame.  Note that this is not the case on some targets that save
       registers into the caller's frame, such as SPARC and rs6000, and so
*************** Here is the basic stack layout.
*** 35497,35511 ****
       If defined, a C expression whose value is an integer giving the
       offset in bytes from the frame pointer to the canonical frame
       address (cfa).  The final value should coincide with that
!      calculated by 'INCOMING_FRAME_SP_OFFSET'.
  
       Normally the CFA is calculated as an offset from the argument
!      pointer, via 'ARG_POINTER_CFA_OFFSET', but if the argument pointer
       is variable due to the ABI, this may not be possible.  If this
       macro is defined, it implies that the virtual register
       instantiation should be based on the frame pointer instead of the
!      argument pointer.  Only one of 'FRAME_POINTER_CFA_OFFSET' and
!      'ARG_POINTER_CFA_OFFSET' should be defined.
  
   -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL)
       If defined, a C expression whose value is an integer giving the
--- 35496,35510 ----
       If defined, a C expression whose value is an integer giving the
       offset in bytes from the frame pointer to the canonical frame
       address (cfa).  The final value should coincide with that
!      calculated by ‘INCOMING_FRAME_SP_OFFSET’.
  
       Normally the CFA is calculated as an offset from the argument
!      pointer, via ‘ARG_POINTER_CFA_OFFSET’, but if the argument pointer
       is variable due to the ABI, this may not be possible.  If this
       macro is defined, it implies that the virtual register
       instantiation should be based on the frame pointer instead of the
!      argument pointer.  Only one of ‘FRAME_POINTER_CFA_OFFSET’ and
!      ‘ARG_POINTER_CFA_OFFSET’ should be defined.
  
   -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL)
       If defined, a C expression whose value is an integer giving the
*************** File: gccint.info,  Node: Exception Hand
*** 35522,35528 ****
  
   -- Macro: EH_RETURN_DATA_REGNO (N)
       A C expression whose value is the Nth register number used for data
!      by exception handlers, or 'INVALID_REGNUM' if fewer than N
       registers are usable.
  
       The exception handling library routines communicate with the
--- 35521,35527 ----
  
   -- Macro: EH_RETURN_DATA_REGNO (N)
       A C expression whose value is the Nth register number used for data
!      by exception handlers, or ‘INVALID_REGNUM’ if fewer than N
       registers are usable.
  
       The exception handling library routines communicate with the
*************** File: gccint.info,  Node: Exception Hand
*** 35562,35577 ****
       normal return address is stored.  For targets that return by
       popping an address off the stack, this might be a memory address
       just below the _target_ call frame rather than inside the current
!      call frame.  If defined, 'EH_RETURN_STACKADJ_RTX' will have already
       been assigned, so it may be used to calculate the location of the
       target call frame.
  
       Some targets have more complex requirements than storing to an
       address calculable during initial code generation.  In that case
!      the 'eh_return' instruction pattern should be used instead.
  
       If you want to support call frame exception handling, you must
!      define either this macro or the 'eh_return' instruction pattern.
  
   -- Macro: RETURN_ADDR_OFFSET
       If defined, an integer-valued C expression for which rtl will be
--- 35561,35576 ----
       normal return address is stored.  For targets that return by
       popping an address off the stack, this might be a memory address
       just below the _target_ call frame rather than inside the current
!      call frame.  If defined, ‘EH_RETURN_STACKADJ_RTX’ will have already
       been assigned, so it may be used to calculate the location of the
       target call frame.
  
       Some targets have more complex requirements than storing to an
       address calculable during initial code generation.  In that case
!      the ‘eh_return’ instruction pattern should be used instead.
  
       If you want to support call frame exception handling, you must
!      define either this macro or the ‘eh_return’ instruction pattern.
  
   -- Macro: RETURN_ADDR_OFFSET
       If defined, an integer-valued C expression for which rtl will be
*************** File: gccint.info,  Node: Exception Hand
*** 35589,35595 ****
       CODE is 0 for data, 1 for code labels, 2 for function pointers.
       GLOBAL is true if the symbol may be affected by dynamic
       relocations.  The macro should return a combination of the
!      'DW_EH_PE_*' defines as found in 'dwarf2.h'.
  
       If this macro is not defined, pointers will not be encoded but
       represented directly.
--- 35588,35594 ----
       CODE is 0 for data, 1 for code labels, 2 for function pointers.
       GLOBAL is true if the symbol may be affected by dynamic
       relocations.  The macro should return a combination of the
!      ‘DW_EH_PE_*’ defines as found in ‘dwarf2.h’.
  
       If this macro is not defined, pointers will not be encoded but
       represented directly.
*************** File: gccint.info,  Node: Exception Hand
*** 35598,35610 ****
            ADDR, DONE)
       This macro allows the target to emit whatever special magic is
       required to represent the encoding chosen by
!      'ASM_PREFERRED_EH_DATA_FORMAT'.  Generic code takes care of
       pc-relative and indirect encodings; this must be defined if the
       target uses text-relative or data-relative encodings.
  
       This is a C statement that branches to DONE if the format was
       handled.  ENCODING is the format chosen, SIZE is the number of
!      bytes that the format occupies, ADDR is the 'SYMBOL_REF' to be
       emitted.
  
   -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS)
--- 35597,35609 ----
            ADDR, DONE)
       This macro allows the target to emit whatever special magic is
       required to represent the encoding chosen by
!      ‘ASM_PREFERRED_EH_DATA_FORMAT’.  Generic code takes care of
       pc-relative and indirect encodings; this must be defined if the
       target uses text-relative or data-relative encodings.
  
       This is a C statement that branches to DONE if the format was
       handled.  ENCODING is the format chosen, SIZE is the number of
!      bytes that the format occupies, ADDR is the ‘SYMBOL_REF’ to be
       emitted.
  
   -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS)
*************** File: gccint.info,  Node: Exception Hand
*** 35613,35646 ****
       unwind data available.  The most common reason to implement this
       macro is to unwind through signal frames.
  
!      This macro is called from 'uw_frame_state_for' in 'unwind-dw2.c',
!      'unwind-dw2-xtensa.c' and 'unwind-ia64.c'.  CONTEXT is an
!      '_Unwind_Context'; FS is an '_Unwind_FrameState'.  Examine
!      'context->ra' for the address of the code being executed and
!      'context->cfa' for the stack pointer value.  If the frame can be
       decoded, the register save addresses should be updated in FS and
!      the macro should evaluate to '_URC_NO_REASON'.  If the frame cannot
!      be decoded, the macro should evaluate to '_URC_END_OF_STACK'.
  
       For proper signal handling in Java this macro is accompanied by
!      'MAKE_THROW_FRAME', defined in 'libjava/include/*-signal.h'
       headers.
  
   -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS)
       This macro allows the target to add operating system specific code
!      to the call-frame unwinder to handle the IA-64 '.unwabi' unwinding
       directive, usually used for signal or interrupt frames.
  
!      This macro is called from 'uw_update_context' in libgcc's
!      'unwind-ia64.c'.  CONTEXT is an '_Unwind_Context'; FS is an
!      '_Unwind_FrameState'.  Examine 'fs->unwabi' for the abi and context
!      in the '.unwabi' directive.  If the '.unwabi' directive can be
       handled, the register save addresses should be updated in FS.
  
   -- Macro: TARGET_USES_WEAK_UNWIND_INFO
       A C expression that evaluates to true if the target requires unwind
!      info to be given comdat linkage.  Define it to be '1' if comdat
!      linkage is necessary.  The default is '0'.
  
  
  File: gccint.info,  Node: Stack Checking,  Next: Frame Registers,  Prev: Exception Handling,  Up: Stack and Calling
--- 35612,35645 ----
       unwind data available.  The most common reason to implement this
       macro is to unwind through signal frames.
  
!      This macro is called from ‘uw_frame_state_for’ in ‘unwind-dw2.c’,
!      ‘unwind-dw2-xtensa.c’ and ‘unwind-ia64.c’.  CONTEXT is an
!      ‘_Unwind_Context’; FS is an ‘_Unwind_FrameState’.  Examine
!      ‘context->ra’ for the address of the code being executed and
!      ‘context->cfa’ for the stack pointer value.  If the frame can be
       decoded, the register save addresses should be updated in FS and
!      the macro should evaluate to ‘_URC_NO_REASON’.  If the frame cannot
!      be decoded, the macro should evaluate to ‘_URC_END_OF_STACK’.
  
       For proper signal handling in Java this macro is accompanied by
!      ‘MAKE_THROW_FRAME’, defined in ‘libjava/include/*-signal.h’
       headers.
  
   -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS)
       This macro allows the target to add operating system specific code
!      to the call-frame unwinder to handle the IA-64 ‘.unwabi’ unwinding
       directive, usually used for signal or interrupt frames.
  
!      This macro is called from ‘uw_update_context’ in libgcc's
!      ‘unwind-ia64.c’.  CONTEXT is an ‘_Unwind_Context’; FS is an
!      ‘_Unwind_FrameState’.  Examine ‘fs->unwabi’ for the abi and context
!      in the ‘.unwabi’ directive.  If the ‘.unwabi’ directive can be
       handled, the register save addresses should be updated in FS.
  
   -- Macro: TARGET_USES_WEAK_UNWIND_INFO
       A C expression that evaluates to true if the target requires unwind
!      info to be given comdat linkage.  Define it to be ‘1’ if comdat
!      linkage is necessary.  The default is ‘0’.
  
  
  File: gccint.info,  Node: Stack Checking,  Next: Frame Registers,  Prev: Exception Handling,  Up: Stack and Calling
*************** File: gccint.info,  Node: Stack Checking
*** 35649,35663 ****
  --------------------------------------------
  
  GCC will check that stack references are within the boundaries of the
! stack, if the option '-fstack-check' is specified, in one of three ways:
  
!   1. If the value of the 'STACK_CHECK_BUILTIN' macro is nonzero, GCC
       will assume that you have arranged for full stack checking to be
       done at appropriate places in the configuration files.  GCC will
       not do other special processing.
  
!   2. If 'STACK_CHECK_BUILTIN' is zero and the value of the
!      'STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume that
       you have arranged for static stack checking (checking of the static
       stack frame of functions) to be done at appropriate places in the
       configuration files.  GCC will only emit code to do dynamic stack
--- 35648,35662 ----
  --------------------------------------------
  
  GCC will check that stack references are within the boundaries of the
! stack, if the option ‘-fstack-check’ is specified, in one of three ways:
  
!   1. If the value of the ‘STACK_CHECK_BUILTIN’ macro is nonzero, GCC
       will assume that you have arranged for full stack checking to be
       done at appropriate places in the configuration files.  GCC will
       not do other special processing.
  
!   2. If ‘STACK_CHECK_BUILTIN’ is zero and the value of the
!      ‘STACK_CHECK_STATIC_BUILTIN’ macro is nonzero, GCC will assume that
       you have arranged for static stack checking (checking of the static
       stack frame of functions) to be done at appropriate places in the
       configuration files.  GCC will only emit code to do dynamic stack
*************** stack, if the option '-fstack-check' is
*** 35670,35677 ****
  
   If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is
  defined, GCC will change its allocation strategy for large objects if
! the option '-fstack-check' is specified: they will always be allocated
! dynamically if their size exceeds 'STACK_CHECK_MAX_VAR_SIZE' bytes.
  
   -- Macro: STACK_CHECK_BUILTIN
       A nonzero value if stack checking is done by the configuration
--- 35669,35676 ----
  
   If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is
  defined, GCC will change its allocation strategy for large objects if
! the option ‘-fstack-check’ is specified: they will always be allocated
! dynamically if their size exceeds ‘STACK_CHECK_MAX_VAR_SIZE’ bytes.
  
   -- Macro: STACK_CHECK_BUILTIN
       A nonzero value if stack checking is done by the configuration
*************** dynamically if their size exceeds 'STACK
*** 35707,35713 ****
   -- Macro: STACK_CHECK_PROTECT
       The number of bytes of stack needed to recover from a stack
       overflow, for languages where such a recovery is supported.  The
!      default value of 4KB/8KB with the 'setjmp'/'longjmp'-based
       exception handling mechanism and 8KB/12KB with other exception
       handling mechanisms should be adequate for most architectures and
       operating systems.
--- 35706,35712 ----
   -- Macro: STACK_CHECK_PROTECT
       The number of bytes of stack needed to recover from a stack
       overflow, for languages where such a recovery is supported.  The
!      default value of 4KB/8KB with the ‘setjmp’/‘longjmp’-based
       exception handling mechanism and 8KB/12KB with other exception
       handling mechanisms should be adequate for most architectures and
       operating systems.
*************** in the opposite case.
*** 35735,35741 ****
   -- Macro: STACK_CHECK_MAX_VAR_SIZE
       The maximum size, in bytes, of an object that GCC will place in the
       fixed area of the stack frame when the user specifies
!      '-fstack-check'.  GCC computed the default from the values of the
       above macros and you will normally not need to override that
       default.
  
--- 35734,35740 ----
   -- Macro: STACK_CHECK_MAX_VAR_SIZE
       The maximum size, in bytes, of an object that GCC will place in the
       fixed area of the stack frame when the user specifies
!      ‘-fstack-check’.  GCC computed the default from the values of the
       above macros and you will normally not need to override that
       default.
  
*************** This discusses registers that address th
*** 35762,35768 ****
  
   -- Macro: STACK_POINTER_REGNUM
       The register number of the stack pointer register, which must also
!      be a fixed register according to 'FIXED_REGISTERS'.  On most
       machines, the hardware determines which register this is.
  
   -- Macro: FRAME_POINTER_REGNUM
--- 35761,35767 ----
  
   -- Macro: STACK_POINTER_REGNUM
       The register number of the stack pointer register, which must also
!      be a fixed register according to ‘FIXED_REGISTERS’.  On most
       machines, the hardware determines which register this is.
  
   -- Macro: FRAME_POINTER_REGNUM
*************** This discusses registers that address th
*** 35776,35796 ****
       offset of the automatic variables is not known until after register
       allocation has been done (for example, because the saved registers
       are between these two locations).  On those machines, define
!      'FRAME_POINTER_REGNUM' the number of a special, fixed register to
       be used internally until the offset is known, and define
!      'HARD_FRAME_POINTER_REGNUM' to be the actual hard register number
       used for the frame pointer.
  
       You should define this macro only in the very rare circumstances
       when it is not possible to calculate the offset between the frame
       pointer and the automatic variables until after register allocation
       has been completed.  When this macro is defined, you must also
!      indicate in your definition of 'ELIMINABLE_REGS' how to eliminate
!      'FRAME_POINTER_REGNUM' into either 'HARD_FRAME_POINTER_REGNUM' or
!      'STACK_POINTER_REGNUM'.
  
       Do not define this macro if it would be the same as
!      'FRAME_POINTER_REGNUM'.
  
   -- Macro: ARG_POINTER_REGNUM
       The register number of the arg pointer register, which is used to
--- 35775,35795 ----
       offset of the automatic variables is not known until after register
       allocation has been done (for example, because the saved registers
       are between these two locations).  On those machines, define
!      ‘FRAME_POINTER_REGNUM’ the number of a special, fixed register to
       be used internally until the offset is known, and define
!      ‘HARD_FRAME_POINTER_REGNUM’ to be the actual hard register number
       used for the frame pointer.
  
       You should define this macro only in the very rare circumstances
       when it is not possible to calculate the offset between the frame
       pointer and the automatic variables until after register allocation
       has been completed.  When this macro is defined, you must also
!      indicate in your definition of ‘ELIMINABLE_REGS’ how to eliminate
!      ‘FRAME_POINTER_REGNUM’ into either ‘HARD_FRAME_POINTER_REGNUM’ or
!      ‘STACK_POINTER_REGNUM’.
  
       Do not define this macro if it would be the same as
!      ‘FRAME_POINTER_REGNUM’.
  
   -- Macro: ARG_POINTER_REGNUM
       The register number of the arg pointer register, which is used to
*************** This discusses registers that address th
*** 35799,35819 ****
       determines which register this is.  On other machines, you can
       choose any register you wish for this purpose.  If this is not the
       same register as the frame pointer register, then you must mark it
!      as a fixed register according to 'FIXED_REGISTERS', or arrange to
       be able to eliminate it (*note Elimination::).
  
   -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER
       Define this to a preprocessor constant that is nonzero if
!      'hard_frame_pointer_rtx' and 'frame_pointer_rtx' should be the
!      same.  The default definition is '(HARD_FRAME_POINTER_REGNUM ==
!      FRAME_POINTER_REGNUM)'; you only need to define this macro if that
       definition is not suitable for use in preprocessor conditionals.
  
   -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER
       Define this to a preprocessor constant that is nonzero if
!      'hard_frame_pointer_rtx' and 'arg_pointer_rtx' should be the same.
!      The default definition is '(HARD_FRAME_POINTER_REGNUM ==
!      ARG_POINTER_REGNUM)'; you only need to define this macro if that
       definition is not suitable for use in preprocessor conditionals.
  
   -- Macro: RETURN_ADDRESS_POINTER_REGNUM
--- 35798,35818 ----
       determines which register this is.  On other machines, you can
       choose any register you wish for this purpose.  If this is not the
       same register as the frame pointer register, then you must mark it
!      as a fixed register according to ‘FIXED_REGISTERS’, or arrange to
       be able to eliminate it (*note Elimination::).
  
   -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER
       Define this to a preprocessor constant that is nonzero if
!      ‘hard_frame_pointer_rtx’ and ‘frame_pointer_rtx’ should be the
!      same.  The default definition is ‘(HARD_FRAME_POINTER_REGNUM ==
!      FRAME_POINTER_REGNUM)’; you only need to define this macro if that
       definition is not suitable for use in preprocessor conditionals.
  
   -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER
       Define this to a preprocessor constant that is nonzero if
!      ‘hard_frame_pointer_rtx’ and ‘arg_pointer_rtx’ should be the same.
!      The default definition is ‘(HARD_FRAME_POINTER_REGNUM ==
!      ARG_POINTER_REGNUM)’; you only need to define this macro if that
       definition is not suitable for use in preprocessor conditionals.
  
   -- Macro: RETURN_ADDRESS_POINTER_REGNUM
*************** This discusses registers that address th
*** 35822,35828 ****
       stack.  On some machines, the return address is not at a fixed
       offset from the frame pointer or stack pointer or argument pointer.
       This register can be defined to point to the return address on the
!      stack, and then be converted by 'ELIMINABLE_REGS' into either the
       frame pointer or stack pointer.
  
       Do not define this macro unless there is no other way to get the
--- 35821,35827 ----
       stack.  On some machines, the return address is not at a fixed
       offset from the frame pointer or stack pointer or argument pointer.
       This register can be defined to point to the return address on the
!      stack, and then be converted by ‘ELIMINABLE_REGS’ into either the
       frame pointer or stack pointer.
  
       Do not define this macro unless there is no other way to get the
*************** This discusses registers that address th
*** 35832,35864 ****
   -- Macro: STATIC_CHAIN_INCOMING_REGNUM
       Register numbers used for passing a function's static chain
       pointer.  If register windows are used, the register number as seen
!      by the called function is 'STATIC_CHAIN_INCOMING_REGNUM', while the
       register number as seen by the calling function is
!      'STATIC_CHAIN_REGNUM'.  If these registers are the same,
!      'STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
  
       The static chain register need not be a fixed register.
  
       If the static chain is passed in memory, these macros should not be
!      defined; instead, the 'TARGET_STATIC_CHAIN' hook should be used.
  
   -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL_OR_TYPE,
            bool INCOMING_P)
!      This hook replaces the use of 'STATIC_CHAIN_REGNUM' et al for
       targets that may use different static chain locations for different
       nested functions.  This may be required if the target has function
       attributes that affect the calling conventions of the function and
       those calling conventions use different static chain locations.
  
!      The default version of this hook uses 'STATIC_CHAIN_REGNUM' et al.
  
       If the static chain is passed in memory, this hook should be used
!      to provide rtx giving 'mem' expressions that denote where they are
!      stored.  Often the 'mem' expression as seen by the caller will be
!      at an offset from the stack pointer and the 'mem' expression as
       seen by the callee will be at an offset from the frame pointer.
!      The variables 'stack_pointer_rtx', 'frame_pointer_rtx', and
!      'arg_pointer_rtx' will have been initialized and should be used to
       refer to those items.
  
   -- Macro: DWARF_FRAME_REGISTERS
--- 35831,35863 ----
   -- Macro: STATIC_CHAIN_INCOMING_REGNUM
       Register numbers used for passing a function's static chain
       pointer.  If register windows are used, the register number as seen
!      by the called function is ‘STATIC_CHAIN_INCOMING_REGNUM’, while the
       register number as seen by the calling function is
!      ‘STATIC_CHAIN_REGNUM’.  If these registers are the same,
!      ‘STATIC_CHAIN_INCOMING_REGNUM’ need not be defined.
  
       The static chain register need not be a fixed register.
  
       If the static chain is passed in memory, these macros should not be
!      defined; instead, the ‘TARGET_STATIC_CHAIN’ hook should be used.
  
   -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL_OR_TYPE,
            bool INCOMING_P)
!      This hook replaces the use of ‘STATIC_CHAIN_REGNUM’ et al for
       targets that may use different static chain locations for different
       nested functions.  This may be required if the target has function
       attributes that affect the calling conventions of the function and
       those calling conventions use different static chain locations.
  
!      The default version of this hook uses ‘STATIC_CHAIN_REGNUM’ et al.
  
       If the static chain is passed in memory, this hook should be used
!      to provide rtx giving ‘mem’ expressions that denote where they are
!      stored.  Often the ‘mem’ expression as seen by the caller will be
!      at an offset from the stack pointer and the ‘mem’ expression as
       seen by the callee will be at an offset from the frame pointer.
!      The variables ‘stack_pointer_rtx’, ‘frame_pointer_rtx’, and
!      ‘arg_pointer_rtx’ will have been initialized and should be used to
       refer to those items.
  
   -- Macro: DWARF_FRAME_REGISTERS
*************** This discusses registers that address th
*** 35876,35890 ****
       call-saved.
  
       If this macro is not defined, it defaults to
!      'FIRST_PSEUDO_REGISTER'.
  
   -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS
  
!      This macro is similar to 'DWARF_FRAME_REGISTERS', but is provided
       for backward compatibility in pre GCC 3.0 compiled code.
  
       If this macro is not defined, it defaults to
!      'DWARF_FRAME_REGISTERS'.
  
   -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO)
  
--- 35875,35889 ----
       call-saved.
  
       If this macro is not defined, it defaults to
!      ‘FIRST_PSEUDO_REGISTER’.
  
   -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS
  
!      This macro is similar to ‘DWARF_FRAME_REGISTERS’, but is provided
       for backward compatibility in pre GCC 3.0 compiled code.
  
       If this macro is not defined, it defaults to
!      ‘DWARF_FRAME_REGISTERS’.
  
   -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO)
  
*************** This discusses registers that address th
*** 35899,35932 ****
       registers used in .eh_frame or .debug_frame is different from that
       used in other debug info sections.  Given a GCC hard register
       number, this macro should return the .eh_frame register number.
!      The default is 'DEBUGGER_REGNO (REGNO)'.
  
   -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH)
  
       Define this macro to map register numbers held in the call frame
!      info that GCC has collected using 'DWARF_FRAME_REGNUM' to those
!      that should be output in .debug_frame ('FOR_EH' is zero) and
!      .eh_frame ('FOR_EH' is nonzero).  The default is to return 'REGNO'.
  
   -- Macro: REG_VALUE_IN_UNWIND_CONTEXT
  
       Define this macro if the target stores register values as
!      '_Unwind_Word' type in unwind context.  It should be defined if
!      target register size is larger than the size of 'void *'.  The
!      default is to store register values as 'void *' type.
  
   -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT
  
       Define this macro to be 1 if the target always uses extended unwind
       context with version, args_size and by_value fields.  If it is
       undefined, it will be defined to 1 when
!      'REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise.
  
   -- Macro: DWARF_LAZY_REGISTER_VALUE (REGNO, VALUE)
       Define this macro if the target has pseudo DWARF registers whose
       values need to be computed lazily on demand by the unwinder (such
       as when referenced in a CFA expression).  The macro returns true if
!      REGNO is such a register and stores its value in '*VALUE' if so.
  
  
  File: gccint.info,  Node: Elimination,  Next: Stack Arguments,  Prev: Frame Registers,  Up: Stack and Calling
--- 35898,35931 ----
       registers used in .eh_frame or .debug_frame is different from that
       used in other debug info sections.  Given a GCC hard register
       number, this macro should return the .eh_frame register number.
!      The default is ‘DEBUGGER_REGNO (REGNO)’.
  
   -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH)
  
       Define this macro to map register numbers held in the call frame
!      info that GCC has collected using ‘DWARF_FRAME_REGNUM’ to those
!      that should be output in .debug_frame (‘FOR_EH’ is zero) and
!      .eh_frame (‘FOR_EH’ is nonzero).  The default is to return ‘REGNO’.
  
   -- Macro: REG_VALUE_IN_UNWIND_CONTEXT
  
       Define this macro if the target stores register values as
!      ‘_Unwind_Word’ type in unwind context.  It should be defined if
!      target register size is larger than the size of ‘void *’.  The
!      default is to store register values as ‘void *’ type.
  
   -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT
  
       Define this macro to be 1 if the target always uses extended unwind
       context with version, args_size and by_value fields.  If it is
       undefined, it will be defined to 1 when
!      ‘REG_VALUE_IN_UNWIND_CONTEXT’ is defined and 0 otherwise.
  
   -- Macro: DWARF_LAZY_REGISTER_VALUE (REGNO, VALUE)
       Define this macro if the target has pseudo DWARF registers whose
       values need to be computed lazily on demand by the unwinder (such
       as when referenced in a CFA expression).  The macro returns true if
!      REGNO is such a register and stores its value in ‘*VALUE’ if so.
  
  
  File: gccint.info,  Node: Elimination,  Next: Stack Arguments,  Prev: Frame Registers,  Up: Stack and Calling
*************** File: gccint.info,  Node: Elimination,
*** 35937,35966 ****
  This is about eliminating the frame pointer and arg pointer.
  
   -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void)
!      This target hook should return 'true' if a function must have and
       use a frame pointer.  This target hook is called in the reload
!      pass.  If its return value is 'true' the function will have a frame
       pointer.
  
       This target hook can in principle examine the current function and
       decide according to the facts, but on most machines the constant
!      'false' or the constant 'true' suffices.  Use 'false' when the
       machine allows code to be generated with no frame pointer, and
!      doing so saves some time or space.  Use 'true' when there is no
       possible advantage to avoiding a frame pointer.
  
       In certain cases, the compiler does not know how to produce valid
       code without a frame pointer.  The compiler recognizes those cases
       and automatically gives the function a frame pointer regardless of
!      what 'targetm.frame_pointer_required' returns.  You don't need to
       worry about them.
  
       In a function that does not require a frame pointer, the frame
       pointer register can be allocated for ordinary usage, unless you
!      mark it as a fixed register.  See 'FIXED_REGISTERS' for more
       information.
  
!      Default return value is 'false'.
  
   -- Macro: ELIMINABLE_REGS
       This macro specifies a table of register pairs used to eliminate
--- 35936,35965 ----
  This is about eliminating the frame pointer and arg pointer.
  
   -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void)
!      This target hook should return ‘true’ if a function must have and
       use a frame pointer.  This target hook is called in the reload
!      pass.  If its return value is ‘true’ the function will have a frame
       pointer.
  
       This target hook can in principle examine the current function and
       decide according to the facts, but on most machines the constant
!      ‘false’ or the constant ‘true’ suffices.  Use ‘false’ when the
       machine allows code to be generated with no frame pointer, and
!      doing so saves some time or space.  Use ‘true’ when there is no
       possible advantage to avoiding a frame pointer.
  
       In certain cases, the compiler does not know how to produce valid
       code without a frame pointer.  The compiler recognizes those cases
       and automatically gives the function a frame pointer regardless of
!      what ‘targetm.frame_pointer_required’ returns.  You don't need to
       worry about them.
  
       In a function that does not require a frame pointer, the frame
       pointer register can be allocated for ordinary usage, unless you
!      mark it as a fixed register.  See ‘FIXED_REGISTERS’ for more
       information.
  
!      Default return value is ‘false’.
  
   -- Macro: ELIMINABLE_REGS
       This macro specifies a table of register pairs used to eliminate
*************** This is about eliminating the frame poin
*** 35988,36011 ****
  
   -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const
            int TO_REG)
!      This target hook should return 'true' if the compiler is allowed to
       try to replace register number FROM_REG with register number
!      TO_REG.  This target hook will usually be 'true', since most of the
       cases preventing register elimination are things that the compiler
       already knows about.
  
!      Default return value is 'true'.
  
   -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)
       This macro returns the initial difference between the specified
       pair of registers.  The value would be computed from information
!      such as the result of 'get_frame_size ()' and the tables of
!      registers 'df_regs_ever_live_p' and 'call_used_regs'.
  
   -- Target Hook: void TARGET_COMPUTE_FRAME_LAYOUT (void)
       This target hook is called once each time the frame layout needs to
       be recalculated.  The calculations can be cached by the target and
!      can then be used by 'INITIAL_ELIMINATION_OFFSET' instead of
       re-computing the layout on every invocation of that hook.  This is
       particularly useful for targets that have an expensive frame layout
       function.  Implementing this callback is optional.
--- 35987,36010 ----
  
   -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const
            int TO_REG)
!      This target hook should return ‘true’ if the compiler is allowed to
       try to replace register number FROM_REG with register number
!      TO_REG.  This target hook will usually be ‘true’, since most of the
       cases preventing register elimination are things that the compiler
       already knows about.
  
!      Default return value is ‘true’.
  
   -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)
       This macro returns the initial difference between the specified
       pair of registers.  The value would be computed from information
!      such as the result of ‘get_frame_size ()’ and the tables of
!      registers ‘df_regs_ever_live_p’ and ‘call_used_regs’.
  
   -- Target Hook: void TARGET_COMPUTE_FRAME_LAYOUT (void)
       This target hook is called once each time the frame layout needs to
       be recalculated.  The calculations can be cached by the target and
!      can then be used by ‘INITIAL_ELIMINATION_OFFSET’ instead of
       re-computing the layout on every invocation of that hook.  This is
       particularly useful for targets that have an expensive frame layout
       function.  Implementing this callback is optional.
*************** stack.  See the following section for ot
*** 36021,36047 ****
  certain arguments in registers.
  
   -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE)
!      This target hook returns 'true' if an argument declared in a
!      prototype as an integral type smaller than 'int' should actually be
!      passed as an 'int'.  In addition to avoiding errors in certain
       cases of mismatch, it also makes for better code on certain
       machines.  The default is to not promote prototypes.
  
   -- Target Hook: bool TARGET_PUSH_ARGUMENT (unsigned int NPUSH)
!      This target hook returns 'true' if push instructions will be used
       to pass outgoing arguments.  When the push instruction usage is
       optional, NPUSH is nonzero to indicate the number of bytes to push.
       Otherwise, NPUSH is zero.  If the target machine does not have a
!      push instruction or push instruction should be avoided, 'false'
       should be returned.  That directs GCC to use an alternate strategy:
       to allocate the entire argument block and then store the arguments
!      into it.  If this target hook may return 'true', 'PUSH_ROUNDING'
       must be defined.
  
   -- Macro: PUSH_ARGS_REVERSED
       A C expression.  If nonzero, function arguments will be evaluated
       from last to first, rather than from first to last.  If this macro
!      is not defined, it defaults to 'PUSH_ARGS' on targets where the
       stack and args grow in opposite directions, and 0 otherwise.
  
   -- Macro: PUSH_ROUNDING (NPUSHED)
--- 36020,36046 ----
  certain arguments in registers.
  
   -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE)
!      This target hook returns ‘true’ if an argument declared in a
!      prototype as an integral type smaller than ‘int’ should actually be
!      passed as an ‘int’.  In addition to avoiding errors in certain
       cases of mismatch, it also makes for better code on certain
       machines.  The default is to not promote prototypes.
  
   -- Target Hook: bool TARGET_PUSH_ARGUMENT (unsigned int NPUSH)
!      This target hook returns ‘true’ if push instructions will be used
       to pass outgoing arguments.  When the push instruction usage is
       optional, NPUSH is nonzero to indicate the number of bytes to push.
       Otherwise, NPUSH is zero.  If the target machine does not have a
!      push instruction or push instruction should be avoided, ‘false’
       should be returned.  That directs GCC to use an alternate strategy:
       to allocate the entire argument block and then store the arguments
!      into it.  If this target hook may return ‘true’, ‘PUSH_ROUNDING’
       must be defined.
  
   -- Macro: PUSH_ARGS_REVERSED
       A C expression.  If nonzero, function arguments will be evaluated
       from last to first, rather than from first to last.  If this macro
!      is not defined, it defaults to ‘PUSH_ARGS’ on targets where the
       stack and args grow in opposite directions, and 0 otherwise.
  
   -- Macro: PUSH_ROUNDING (NPUSHED)
*************** certain arguments in registers.
*** 36064,36074 ****
   -- Macro: ACCUMULATE_OUTGOING_ARGS
       A C expression.  If nonzero, the maximum amount of space required
       for outgoing arguments will be computed and placed into
!      'crtl->outgoing_args_size'.  No space will be pushed onto the stack
       for each call; instead, the function prologue should increase the
       stack frame size by this amount.
  
!      Setting both 'PUSH_ARGS' and 'ACCUMULATE_OUTGOING_ARGS' is not
       proper.
  
   -- Macro: REG_PARM_STACK_SPACE (FNDECL)
--- 36063,36073 ----
   -- Macro: ACCUMULATE_OUTGOING_ARGS
       A C expression.  If nonzero, the maximum amount of space required
       for outgoing arguments will be computed and placed into
!      ‘crtl->outgoing_args_size’.  No space will be pushed onto the stack
       for each call; instead, the function prologue should increase the
       stack frame size by this amount.
  
!      Setting both ‘PUSH_ARGS’ and ‘ACCUMULATE_OUTGOING_ARGS’ is not
       proper.
  
   -- Macro: REG_PARM_STACK_SPACE (FNDECL)
*************** certain arguments in registers.
*** 36083,36093 ****
       the function.
  
       This space can be allocated by the caller, or be a part of the
!      machine-dependent stack frame: 'OUTGOING_REG_PARM_STACK_SPACE' says
       which.
  
   -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL)
!      Like 'REG_PARM_STACK_SPACE', but for incoming register arguments.
       Define this macro if space guaranteed when compiling a function
       body is different to space required when making a call, a situation
       that can arise with K&R style function definitions.
--- 36082,36092 ----
       the function.
  
       This space can be allocated by the caller, or be a part of the
!      machine-dependent stack frame: ‘OUTGOING_REG_PARM_STACK_SPACE’ says
       which.
  
   -- Macro: INCOMING_REG_PARM_STACK_SPACE (FNDECL)
!      Like ‘REG_PARM_STACK_SPACE’, but for incoming register arguments.
       Define this macro if space guaranteed when compiling a function
       body is different to space required when making a call, a situation
       that can arise with K&R style function definitions.
*************** certain arguments in registers.
*** 36098,36113 ****
       registers when calling a function of FNTYPE.  FNTYPE may be NULL if
       the function called is a library function.
  
!      If 'ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
       whether the space for these arguments counts in the value of
!      'crtl->outgoing_args_size'.
  
   -- Macro: STACK_PARMS_IN_REG_PARM_AREA
!      Define this macro if 'REG_PARM_STACK_SPACE' is defined, but the
       stack parameters don't skip the area specified by it.
  
       Normally, when a parameter is not passed in registers, it is placed
!      on the stack beyond the 'REG_PARM_STACK_SPACE' area.  Defining this
       macro suppresses this behavior and causes the parameter to be
       passed on the stack in its natural location.
  
--- 36097,36112 ----
       registers when calling a function of FNTYPE.  FNTYPE may be NULL if
       the function called is a library function.
  
!      If ‘ACCUMULATE_OUTGOING_ARGS’ is defined, this macro controls
       whether the space for these arguments counts in the value of
!      ‘crtl->outgoing_args_size’.
  
   -- Macro: STACK_PARMS_IN_REG_PARM_AREA
!      Define this macro if ‘REG_PARM_STACK_SPACE’ is defined, but the
       stack parameters don't skip the area specified by it.
  
       Normally, when a parameter is not passed in registers, it is placed
!      on the stack beyond the ‘REG_PARM_STACK_SPACE’ area.  Defining this
       macro suppresses this behavior and causes the parameter to be
       passed on the stack in its natural location.
  
*************** certain arguments in registers.
*** 36120,36131 ****
  
       FUNDECL is a C variable whose value is a tree node that describes
       the function in question.  Normally it is a node of type
!      'FUNCTION_DECL' that describes the declaration of the function.
!      From this you can obtain the 'DECL_ATTRIBUTES' of the function.
  
       FUNTYPE is a C variable whose value is a tree node that describes
       the function in question.  Normally it is a node of type
!      'FUNCTION_TYPE' that describes the data type of the function.  From
       this it is possible to obtain the data types of the value and
       arguments (if known).
  
--- 36119,36130 ----
  
       FUNDECL is a C variable whose value is a tree node that describes
       the function in question.  Normally it is a node of type
!      ‘FUNCTION_DECL’ that describes the declaration of the function.
!      From this you can obtain the ‘DECL_ATTRIBUTES’ of the function.
  
       FUNTYPE is a C variable whose value is a tree node that describes
       the function in question.  Normally it is a node of type
!      ‘FUNCTION_TYPE’ that describes the data type of the function.  From
       this it is possible to obtain the data types of the value and
       arguments (if known).
  
*************** certain arguments in registers.
*** 36146,36152 ****
       calling convention, no functions pop their arguments, so the value
       of the macro is always 0 in this case.  But an alternative calling
       convention is available in which functions that take a fixed number
!      of arguments pop them but other functions (such as 'printf') pop
       nothing (the caller pops all).  When this convention is in use,
       FUNTYPE is examined to determine whether a function takes a fixed
       number of arguments.
--- 36145,36151 ----
       calling convention, no functions pop their arguments, so the value
       of the macro is always 0 in this case.  But an alternative calling
       convention is available in which functions that take a fixed number
!      of arguments pop them but other functions (such as ‘printf’) pop
       nothing (the caller pops all).  When this convention is in use,
       FUNTYPE is examined to determine whether a function takes a fixed
       number of arguments.
*************** certain arguments in registers.
*** 36154,36160 ****
   -- Macro: CALL_POPS_ARGS (CUM)
       A C expression that should indicate the number of bytes a call
       sequence pops off the stack.  It is added to the value of
!      'RETURN_POPS_ARGS' when compiling a function call.
  
       CUM is the variable in which all arguments to the called function
       have been accumulated.
--- 36153,36159 ----
   -- Macro: CALL_POPS_ARGS (CUM)
       A C expression that should indicate the number of bytes a call
       sequence pops off the stack.  It is added to the value of
!      ‘RETURN_POPS_ARGS’ when compiling a function call.
  
       CUM is the variable in which all arguments to the called function
       have been accumulated.
*************** certain arguments in registers.
*** 36163,36169 ****
       used that pops certain registers off the stack, depending on the
       arguments that have been passed to the function.  Since this is a
       property of the call site, not of the called function,
!      'RETURN_POPS_ARGS' is not appropriate.
  
  
  File: gccint.info,  Node: Register Arguments,  Next: Scalar Return,  Prev: Stack Arguments,  Up: Stack and Calling
--- 36162,36168 ----
       used that pops certain registers off the stack, depending on the
       arguments that have been passed to the function.  Since this is a
       property of the call site, not of the called function,
!      ‘RETURN_POPS_ARGS’ is not appropriate.
  
  
  File: gccint.info,  Node: Register Arguments,  Next: Scalar Return,  Prev: Stack Arguments,  Up: Stack and Calling
*************** the stack.
*** 36181,36226 ****
       a register and if so, which register.  Argument CA summarizes all
       the previous arguments.
  
!      The return value is usually either a 'reg' RTX for the hard
       register in which to pass the argument, or zero to pass the
       argument on the stack.
  
!      The value of the expression can also be a 'parallel' RTX.  This is
       used when an argument is passed in multiple locations.  The mode of
!      the 'parallel' should be the mode of the entire argument.  The
!      'parallel' holds any number of 'expr_list' pairs; each one
       describes where part of the argument is passed.  In each
!      'expr_list' the first operand must be a 'reg' RTX for the hard
       register in which to pass this part of the argument, and the mode
       of the register RTX indicates how large this part of the argument
!      is.  The second operand of the 'expr_list' is a 'const_int' which
       gives the offset in bytes into the entire argument of where this
!      part starts.  As a special exception the first 'expr_list' in the
!      'parallel' RTX may have a first operand of zero.  This indicates
       that the entire argument is also stored on the stack.
  
!      The last time this hook is called, it is called with 'MODE ==
!      VOIDmode', and its result is passed to the 'call' or 'call_value'
       pattern as operands 2 and 3 respectively.
  
!      The usual way to make the ISO library 'stdarg.h' work on a machine
       where some arguments are usually passed in registers, is to cause
       nameless arguments to be passed on the stack instead.  This is done
!      by making 'TARGET_FUNCTION_ARG' return 0 whenever NAMED is 'false'.
  
!      You may use the hook 'targetm.calls.must_pass_in_stack' in the
       definition of this macro to determine if this argument is of a type
!      that must be passed in the stack.  If 'REG_PARM_STACK_SPACE' is not
!      defined and 'TARGET_FUNCTION_ARG' returns nonzero for such an
!      argument, the compiler will abort.  If 'REG_PARM_STACK_SPACE' is
       defined, the argument will be computed in the stack and then loaded
       into a register.
  
   -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (const function_arg_info
            &ARG)
!      This target hook should return 'true' if we should not pass ARG
!      solely in registers.  The file 'expr.h' defines a definition that
!      is usually appropriate, refer to 'expr.h' for additional
       documentation.
  
   -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t CA,
--- 36180,36225 ----
       a register and if so, which register.  Argument CA summarizes all
       the previous arguments.
  
!      The return value is usually either a ‘reg’ RTX for the hard
       register in which to pass the argument, or zero to pass the
       argument on the stack.
  
!      The value of the expression can also be a ‘parallel’ RTX.  This is
       used when an argument is passed in multiple locations.  The mode of
!      the ‘parallel’ should be the mode of the entire argument.  The
!      ‘parallel’ holds any number of ‘expr_list’ pairs; each one
       describes where part of the argument is passed.  In each
!      ‘expr_list’ the first operand must be a ‘reg’ RTX for the hard
       register in which to pass this part of the argument, and the mode
       of the register RTX indicates how large this part of the argument
!      is.  The second operand of the ‘expr_list’ is a ‘const_int’ which
       gives the offset in bytes into the entire argument of where this
!      part starts.  As a special exception the first ‘expr_list’ in the
!      ‘parallel’ RTX may have a first operand of zero.  This indicates
       that the entire argument is also stored on the stack.
  
!      The last time this hook is called, it is called with ‘MODE ==
!      VOIDmode’, and its result is passed to the ‘call’ or ‘call_value’
       pattern as operands 2 and 3 respectively.
  
!      The usual way to make the ISO library ‘stdarg.h’ work on a machine
       where some arguments are usually passed in registers, is to cause
       nameless arguments to be passed on the stack instead.  This is done
!      by making ‘TARGET_FUNCTION_ARG’ return 0 whenever NAMED is ‘false’.
  
!      You may use the hook ‘targetm.calls.must_pass_in_stack’ in the
       definition of this macro to determine if this argument is of a type
!      that must be passed in the stack.  If ‘REG_PARM_STACK_SPACE’ is not
!      defined and ‘TARGET_FUNCTION_ARG’ returns nonzero for such an
!      argument, the compiler will abort.  If ‘REG_PARM_STACK_SPACE’ is
       defined, the argument will be computed in the stack and then loaded
       into a register.
  
   -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (const function_arg_info
            &ARG)
!      This target hook should return ‘true’ if we should not pass ARG
!      solely in registers.  The file ‘expr.h’ defines a definition that
!      is usually appropriate, refer to ‘expr.h’ for additional
       documentation.
  
   -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t CA,
*************** the stack.
*** 36231,36247 ****
       invoked by the hardware and which have nonstandard calling
       conventions.
  
!      In this case 'TARGET_FUNCTION_ARG' computes the register in which
!      the caller passes the value, and 'TARGET_FUNCTION_INCOMING_ARG'
       should be defined in a similar fashion to tell the function being
       called where the arguments will arrive.
  
!      'TARGET_FUNCTION_INCOMING_ARG' can also return arbitrary address
       computation using hard register, which can be forced into a
       register, so that it can be used to pass special arguments.
  
!      If 'TARGET_FUNCTION_INCOMING_ARG' is not defined,
!      'TARGET_FUNCTION_ARG' serves both purposes.
  
   -- Target Hook: bool TARGET_USE_PSEUDO_PIC_REG (void)
       This hook should return 1 in case pseudo register should be created
--- 36230,36246 ----
       invoked by the hardware and which have nonstandard calling
       conventions.
  
!      In this case ‘TARGET_FUNCTION_ARG’ computes the register in which
!      the caller passes the value, and ‘TARGET_FUNCTION_INCOMING_ARG’
       should be defined in a similar fashion to tell the function being
       called where the arguments will arrive.
  
!      ‘TARGET_FUNCTION_INCOMING_ARG’ can also return arbitrary address
       computation using hard register, which can be forced into a
       register, so that it can be used to pass special arguments.
  
!      If ‘TARGET_FUNCTION_INCOMING_ARG’ is not defined,
!      ‘TARGET_FUNCTION_ARG’ serves both purposes.
  
   -- Target Hook: bool TARGET_USE_PSEUDO_PIC_REG (void)
       This hook should return 1 in case pseudo register should be created
*************** the stack.
*** 36261,36282 ****
       On some machines, certain arguments must be passed partially in
       registers and partially in memory.  On these machines, typically
       the first few words of arguments are passed in registers, and the
!      rest on the stack.  If a multi-word argument (a 'double' or a
       structure) crosses that boundary, its first few words must be
       passed in registers and the rest must be pushed.  This macro tells
       the compiler when this occurs, and how many bytes should go in
       registers.
  
!      'TARGET_FUNCTION_ARG' for these arguments should return the first
       register to be used by the caller for this argument; likewise
!      'TARGET_FUNCTION_INCOMING_ARG', for the called function.
  
   -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM,
            const function_arg_info &ARG)
!      This target hook should return 'true' if argument ARG at the
       position indicated by CUM should be passed by reference.  This
       predicate is queried after target independent reasons for being
!      passed by reference, such as 'TREE_ADDRESSABLE (ARG.type)'.
  
       If the hook returns true, a copy of that argument is made in memory
       and a pointer to the argument is passed instead of the argument
--- 36260,36281 ----
       On some machines, certain arguments must be passed partially in
       registers and partially in memory.  On these machines, typically
       the first few words of arguments are passed in registers, and the
!      rest on the stack.  If a multi-word argument (a ‘double’ or a
       structure) crosses that boundary, its first few words must be
       passed in registers and the rest must be pushed.  This macro tells
       the compiler when this occurs, and how many bytes should go in
       registers.
  
!      ‘TARGET_FUNCTION_ARG’ for these arguments should return the first
       register to be used by the caller for this argument; likewise
!      ‘TARGET_FUNCTION_INCOMING_ARG’, for the called function.
  
   -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM,
            const function_arg_info &ARG)
!      This target hook should return ‘true’ if argument ARG at the
       position indicated by CUM should be passed by reference.  This
       predicate is queried after target independent reasons for being
!      passed by reference, such as ‘TREE_ADDRESSABLE (ARG.type)’.
  
       If the hook returns true, a copy of that argument is made in memory
       and a pointer to the argument is passed instead of the argument
*************** the stack.
*** 36298,36313 ****
  
   -- Macro: CUMULATIVE_ARGS
       A C type for declaring a variable that is used as the first
!      argument of 'TARGET_FUNCTION_ARG' and other related values.  For
!      some target machines, the type 'int' suffices and can hold the
       number of bytes of argument so far.
  
!      There is no need to record in 'CUMULATIVE_ARGS' anything about the
       arguments that have been passed on the stack.  The compiler has
       other variables to keep track of that.  For target machines on
       which all arguments are passed on the stack, there is no need to
!      store anything in 'CUMULATIVE_ARGS'; however, the data structure
!      must exist and should not be empty, so use 'int'.
  
   -- Macro: OVERRIDE_ABI_FORMAT (FNDECL)
       If defined, this macro is called before generating any code for a
--- 36297,36312 ----
  
   -- Macro: CUMULATIVE_ARGS
       A C type for declaring a variable that is used as the first
!      argument of ‘TARGET_FUNCTION_ARG’ and other related values.  For
!      some target machines, the type ‘int’ suffices and can hold the
       number of bytes of argument so far.
  
!      There is no need to record in ‘CUMULATIVE_ARGS’ anything about the
       arguments that have been passed on the stack.  The compiler has
       other variables to keep track of that.  For target machines on
       which all arguments are passed on the stack, there is no need to
!      store anything in ‘CUMULATIVE_ARGS’; however, the data structure
!      must exist and should not be empty, so use ‘int’.
  
   -- Macro: OVERRIDE_ABI_FORMAT (FNDECL)
       If defined, this macro is called before generating any code for a
*************** the stack.
*** 36315,36365 ****
       created.  The back end may use this macro to update CFUN to reflect
       an ABI other than that which would normally be used by default.  If
       the compiler is generating code for a compiler-generated function,
!      FNDECL may be 'NULL'.
  
   -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL,
            N_NAMED_ARGS)
       A C statement (sans semicolon) for initializing the variable CUM
       for the state at the beginning of the argument list.  The variable
!      has type 'CUMULATIVE_ARGS'.  The value of FNTYPE is the tree node
       for the data type of the function which will receive the args, or 0
       if the args are to a compiler support library function.  For direct
       calls that are not libcalls, FNDECL contain the declaration node of
!      the function.  FNDECL is also set when 'INIT_CUMULATIVE_ARGS' is
       used to find arguments for the function being compiled.
       N_NAMED_ARGS is set to the number of named arguments, including a
       structure return address if it is passed as a parameter, when
       making a call.  When processing incoming arguments, N_NAMED_ARGS is
!      set to -1.
  
       When processing a call to a compiler support library function,
!      LIBNAME identifies which one.  It is a 'symbol_ref' rtx which
       contains the name of the function, as a string.  LIBNAME is 0 when
       an ordinary C function call is being processed.  Thus, each time
       this macro is called, either LIBNAME or FNTYPE is nonzero, but
       never both of them at once.
  
   -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME)
!      Like 'INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, it
!      gets a 'MODE' argument instead of FNTYPE, that would be 'NULL'.
       INDIRECT would always be zero, too.  If this macro is not defined,
!      'INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead.
  
   -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)
!      Like 'INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
       finding the arguments for the function being compiled.  If this
!      macro is undefined, 'INIT_CUMULATIVE_ARGS' is used instead.
  
       The value passed for LIBNAME is always 0, since library routines
       with special calling conventions are never compiled with GCC.  The
!      argument LIBNAME exists for symmetry with 'INIT_CUMULATIVE_ARGS'.
  
   -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t CA,
            const function_arg_info &ARG)
       This hook updates the summarizer variable pointed to by CA to
       advance past argument ARG in the argument list.  Once this is done,
       the variable CUM is suitable for analyzing the _following_ argument
!      with 'TARGET_FUNCTION_ARG', etc.
  
       This hook need not do anything if the argument in question was
       passed on the stack.  The compiler knows how to track the amount of
--- 36314,36364 ----
       created.  The back end may use this macro to update CFUN to reflect
       an ABI other than that which would normally be used by default.  If
       the compiler is generating code for a compiler-generated function,
!      FNDECL may be ‘NULL’.
  
   -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL,
            N_NAMED_ARGS)
       A C statement (sans semicolon) for initializing the variable CUM
       for the state at the beginning of the argument list.  The variable
!      has type ‘CUMULATIVE_ARGS’.  The value of FNTYPE is the tree node
       for the data type of the function which will receive the args, or 0
       if the args are to a compiler support library function.  For direct
       calls that are not libcalls, FNDECL contain the declaration node of
!      the function.  FNDECL is also set when ‘INIT_CUMULATIVE_ARGS’ is
       used to find arguments for the function being compiled.
       N_NAMED_ARGS is set to the number of named arguments, including a
       structure return address if it is passed as a parameter, when
       making a call.  When processing incoming arguments, N_NAMED_ARGS is
!      set to −1.
  
       When processing a call to a compiler support library function,
!      LIBNAME identifies which one.  It is a ‘symbol_ref’ rtx which
       contains the name of the function, as a string.  LIBNAME is 0 when
       an ordinary C function call is being processed.  Thus, each time
       this macro is called, either LIBNAME or FNTYPE is nonzero, but
       never both of them at once.
  
   -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME)
!      Like ‘INIT_CUMULATIVE_ARGS’ but only used for outgoing libcalls, it
!      gets a ‘MODE’ argument instead of FNTYPE, that would be ‘NULL’.
       INDIRECT would always be zero, too.  If this macro is not defined,
!      ‘INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)’ is used instead.
  
   -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)
!      Like ‘INIT_CUMULATIVE_ARGS’ but overrides it for the purposes of
       finding the arguments for the function being compiled.  If this
!      macro is undefined, ‘INIT_CUMULATIVE_ARGS’ is used instead.
  
       The value passed for LIBNAME is always 0, since library routines
       with special calling conventions are never compiled with GCC.  The
!      argument LIBNAME exists for symmetry with ‘INIT_CUMULATIVE_ARGS’.
  
   -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t CA,
            const function_arg_info &ARG)
       This hook updates the summarizer variable pointed to by CA to
       advance past argument ARG in the argument list.  Once this is done,
       the variable CUM is suitable for analyzing the _following_ argument
!      with ‘TARGET_FUNCTION_ARG’, etc.
  
       This hook need not do anything if the argument in question was
       passed on the stack.  The compiler knows how to track the amount of
*************** the stack.
*** 36369,36400 ****
            MODE, const_tree TYPE)
       This hook returns the number of bytes to add to the offset of an
       argument of type TYPE and mode MODE when passed in memory.  This is
!      needed for the SPU, which passes 'char' and 'short' arguments in
       the preferred slot that is in the middle of the quad word instead
       of starting at the top.  The default implementation returns 0.
  
   -- Target Hook: pad_direction TARGET_FUNCTION_ARG_PADDING (machine_mode
            MODE, const_tree TYPE)
       This hook determines whether, and in which direction, to pad out an
!      argument of mode MODE and type TYPE.  It returns 'PAD_UPWARD' to
!      insert padding above the argument, 'PAD_DOWNWARD' to insert padding
!      below the argument, or 'PAD_NONE' to inhibit padding.
  
       The _amount_ of padding is not controlled by this hook, but by
!      'TARGET_FUNCTION_ARG_ROUND_BOUNDARY'.  It is always just enough to
       reach the next multiple of that boundary.
  
       This hook has a default definition that is right for most systems.
       For little-endian machines, the default is to pad upward.  For
       big-endian machines, the default is to pad downward for an argument
!      of constant size shorter than an 'int', and upward otherwise.
  
   -- Macro: PAD_VARARGS_DOWN
       If defined, a C expression which determines whether the default
       implementation of va_arg will attempt to pad down before reading
       the next argument, if that argument is smaller than its aligned
!      space as controlled by 'PARM_BOUNDARY'.  If this macro is not
!      defined, all such arguments are padded down if 'BYTES_BIG_ENDIAN'
       is true.
  
   -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST)
--- 36368,36399 ----
            MODE, const_tree TYPE)
       This hook returns the number of bytes to add to the offset of an
       argument of type TYPE and mode MODE when passed in memory.  This is
!      needed for the SPU, which passes ‘char’ and ‘short’ arguments in
       the preferred slot that is in the middle of the quad word instead
       of starting at the top.  The default implementation returns 0.
  
   -- Target Hook: pad_direction TARGET_FUNCTION_ARG_PADDING (machine_mode
            MODE, const_tree TYPE)
       This hook determines whether, and in which direction, to pad out an
!      argument of mode MODE and type TYPE.  It returns ‘PAD_UPWARD’ to
!      insert padding above the argument, ‘PAD_DOWNWARD’ to insert padding
!      below the argument, or ‘PAD_NONE’ to inhibit padding.
  
       The _amount_ of padding is not controlled by this hook, but by
!      ‘TARGET_FUNCTION_ARG_ROUND_BOUNDARY’.  It is always just enough to
       reach the next multiple of that boundary.
  
       This hook has a default definition that is right for most systems.
       For little-endian machines, the default is to pad upward.  For
       big-endian machines, the default is to pad downward for an argument
!      of constant size shorter than an ‘int’, and upward otherwise.
  
   -- Macro: PAD_VARARGS_DOWN
       If defined, a C expression which determines whether the default
       implementation of va_arg will attempt to pad down before reading
       the next argument, if that argument is smaller than its aligned
!      space as controlled by ‘PARM_BOUNDARY’.  If this macro is not
!      defined, all such arguments are padded down if ‘BYTES_BIG_ENDIAN’
       is true.
  
   -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST)
*************** the stack.
*** 36402,36408 ****
       registers and memory.  FIRST is nonzero if this is the only
       element.  Defining this macro allows better control of register
       function parameters on big-endian machines, without using
!      'PARALLEL' rtl.  In particular, 'MUST_PASS_IN_STACK' need not test
       padding and mode of types in registers, as there is no longer a
       "wrong" part of a register; For example, a three byte aggregate may
       be passed in the high part of a register if so required.
--- 36401,36407 ----
       registers and memory.  FIRST is nonzero if this is the only
       element.  Defining this macro allows better control of register
       function parameters on big-endian machines, without using
!      ‘PARALLEL’ rtl.  In particular, ‘MUST_PASS_IN_STACK’ need not test
       padding and mode of types in registers, as there is no longer a
       "wrong" part of a register; For example, a three byte aggregate may
       be passed in the high part of a register if so required.
*************** the stack.
*** 36411,36421 ****
            MODE, const_tree TYPE)
       This hook returns the alignment boundary, in bits, of an argument
       with the specified mode and type.  The default hook returns
!      'PARM_BOUNDARY' for all arguments.
  
   -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY
            (machine_mode MODE, const_tree TYPE)
!      Normally, the size of an argument is rounded up to 'PARM_BOUNDARY',
       which is the default value for this hook.  You can define this hook
       to return a different value if an argument size must be rounded to
       a larger value.
--- 36410,36420 ----
            MODE, const_tree TYPE)
       This hook returns the alignment boundary, in bits, of an argument
       with the specified mode and type.  The default hook returns
!      ‘PARM_BOUNDARY’ for all arguments.
  
   -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY
            (machine_mode MODE, const_tree TYPE)
!      Normally, the size of an argument is rounded up to ‘PARM_BOUNDARY’,
       which is the default value for this hook.  You can define this hook
       to return a different value if an argument size must be rounded to
       a larger value.
*************** the stack.
*** 36437,36455 ****
       in a pair of floating point registers, even though a complex float
       would fit in one 64-bit floating point register.
  
!      The default value of this hook is 'NULL', which is treated as
       always false.
  
   -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void)
!      This hook returns a type node for 'va_list' for the target.  The
!      default version of the hook returns 'void*'.
  
   -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char **PNAME,
            tree *PTREE)
!      This target hook is used in function 'c_common_nodes_and_builtins'
       to iterate through the target specific builtin types for va_list.
       The variable IDX is used as iterator.  PNAME has to be a pointer to
!      a 'const char *' and PTREE a pointer to a 'tree' typed variable.
       The arguments PNAME and PTREE are used to store the result of this
       macro and are set to the name of the va_list builtin type and its
       internal type.  If the return value of this macro is zero, then
--- 36436,36454 ----
       in a pair of floating point registers, even though a complex float
       would fit in one 64-bit floating point register.
  
!      The default value of this hook is ‘NULL’, which is treated as
       always false.
  
   -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void)
!      This hook returns a type node for ‘va_list’ for the target.  The
!      default version of the hook returns ‘void*’.
  
   -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char **PNAME,
            tree *PTREE)
!      This target hook is used in function ‘c_common_nodes_and_builtins’
       to iterate through the target specific builtin types for va_list.
       The variable IDX is used as iterator.  PNAME has to be a pointer to
!      a ‘const char *’ and PTREE a pointer to a ‘tree’ typed variable.
       The arguments PNAME and PTREE are used to store the result of this
       macro and are set to the name of the va_list builtin type and its
       internal type.  If the return value of this macro is zero, then
*************** the stack.
*** 36459,36481 ****
   -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL)
       This hook returns the va_list type of the calling convention
       specified by FNDECL.  The default version of this hook returns
!      'va_list_type_node'.
  
   -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE)
       This hook returns the va_list type of the calling convention
       specified by the type of TYPE.  If TYPE is not a valid va_list
!      type, it returns 'NULL_TREE'.
  
   -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree
            TYPE, gimple_seq *PRE_P, gimple_seq *POST_P)
!      This hook performs target-specific gimplification of 'VA_ARG_EXPR'.
!      The first two parameters correspond to the arguments to 'va_arg';
!      the latter two are as in 'gimplify.cc:gimplify_expr'.
  
   -- Target Hook: bool TARGET_VALID_POINTER_MODE (scalar_int_mode MODE)
       Define this to return nonzero if the port can handle pointers with
       machine mode MODE.  The default version of this hook returns true
!      for both 'ptr_mode' and 'Pmode'.
  
   -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (ao_ref *REF)
       Define this to return nonzero if the memory reference REF may alias
--- 36458,36480 ----
   -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL)
       This hook returns the va_list type of the calling convention
       specified by FNDECL.  The default version of this hook returns
!      ‘va_list_type_node’.
  
   -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE)
       This hook returns the va_list type of the calling convention
       specified by the type of TYPE.  If TYPE is not a valid va_list
!      type, it returns ‘NULL_TREE’.
  
   -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree
            TYPE, gimple_seq *PRE_P, gimple_seq *POST_P)
!      This hook performs target-specific gimplification of ‘VA_ARG_EXPR’.
!      The first two parameters correspond to the arguments to ‘va_arg’;
!      the latter two are as in ‘gimplify.cc:gimplify_expr’.
  
   -- Target Hook: bool TARGET_VALID_POINTER_MODE (scalar_int_mode MODE)
       Define this to return nonzero if the port can handle pointers with
       machine mode MODE.  The default version of this hook returns true
!      for both ‘ptr_mode’ and ‘Pmode’.
  
   -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (ao_ref *REF)
       Define this to return nonzero if the memory reference REF may alias
*************** the stack.
*** 36488,36494 ****
            (machine_mode MODE)
       Define this hook if during mode attribute processing, the port
       should translate machine_mode MODE to another mode.  For example,
!      rs6000's 'KFmode', when it is the same as 'TFmode'.
  
       The default version of the hook returns that mode that was passed
       in.
--- 36487,36493 ----
            (machine_mode MODE)
       Define this hook if during mode attribute processing, the port
       should translate machine_mode MODE to another mode.  For example,
!      rs6000's ‘KFmode’, when it is the same as ‘TFmode’.
  
       The default version of the hook returns that mode that was passed
       in.
*************** the stack.
*** 36502,36508 ****
       The default version of this hook returns true for any mode required
       to handle the basic C types (as defined by the port).  Included
       here are the double-word arithmetic supported by the code in
!      'optabs.cc'.
  
   -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE)
       Define this to return nonzero if the port is prepared to handle
--- 36501,36507 ----
       The default version of this hook returns true for any mode required
       to handle the basic C types (as defined by the port).  Included
       here are the double-word arithmetic supported by the code in
!      ‘optabs.cc’.
  
   -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (machine_mode MODE)
       Define this to return nonzero if the port is prepared to handle
*************** the stack.
*** 36521,36532 ****
       The main reason for defining this hook is to reject pairs of types
       that are handled differently by the target's calling convention.
       For example, when a new N-bit vector architecture is added to a
!      target, the target may want to handle normal N-bit 'VECTOR_TYPE'
       arguments and return values in the same way as before, to maintain
       backwards compatibility.  However, it may also provide new,
!      architecture-specific 'VECTOR_TYPE's that are passed and returned
       in a more efficient way.  It is then important to maintain a
!      distinction between the "normal" 'VECTOR_TYPE's and the new
       architecture-specific ones.
  
       The default implementation returns true, which is correct for most
--- 36520,36531 ----
       The main reason for defining this hook is to reject pairs of types
       that are handled differently by the target's calling convention.
       For example, when a new N-bit vector architecture is added to a
!      target, the target may want to handle normal N-bit ‘VECTOR_TYPE’
       arguments and return values in the same way as before, to maintain
       backwards compatibility.  However, it may also provide new,
!      architecture-specific ‘VECTOR_TYPE’s that are passed and returned
       in a more efficient way.  It is then important to maintain a
!      distinction between the "normal" ‘VECTOR_TYPE’s and the new
       architecture-specific ones.
  
       The default implementation returns true, which is correct for most
*************** the stack.
*** 36539,36546 ****
       the target has no special requirements.  In the latter case, GCC
       looks for an integer mode of the appropriate size if available and
       uses BLKmode otherwise.  Usually the search for the integer mode is
!      limited to 'MAX_FIXED_MODE_SIZE', but the
!      'TARGET_ARRAY_MODE_SUPPORTED_P' hook allows a larger mode to be
       used in specific cases.
  
       The main use of this hook is to specify that an array of vectors
--- 36538,36545 ----
       the target has no special requirements.  In the latter case, GCC
       looks for an integer mode of the appropriate size if available and
       uses BLKmode otherwise.  Usually the search for the integer mode is
!      limited to ‘MAX_FIXED_MODE_SIZE’, but the
!      ‘TARGET_ARRAY_MODE_SUPPORTED_P’ hook allows a larger mode to be
       used in specific cases.
  
       The main use of this hook is to specify that an array of vectors
*************** the stack.
*** 36551,36557 ****
            unsigned HOST_WIDE_INT NELEMS)
       Return true if GCC should try to use a scalar mode to store an
       array of NELEMS elements, given that each element has mode MODE.
!      Returning true here overrides the usual 'MAX_FIXED_MODE' limit and
       allows GCC to use any defined integer mode.
  
       One use of this hook is to support vector load and store operations
--- 36550,36556 ----
            unsigned HOST_WIDE_INT NELEMS)
       Return true if GCC should try to use a scalar mode to store an
       array of NELEMS elements, given that each element has mode MODE.
!      Returning true here overrides the usual ‘MAX_FIXED_MODE’ limit and
       allows GCC to use any defined integer mode.
  
       One use of this hook is to support vector load and store operations
*************** the stack.
*** 36567,36618 ****
              int8x8_t val[3];
            } int8x8x3_t;
  
!      If this hook allows 'val' to have a scalar mode, then 'int8x8x3_t'
!      can have the same mode.  GCC can then store 'int8x8x3_t's in
       registers rather than forcing them onto the stack.
  
   -- Target Hook: bool TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P
            (scalar_float_mode MODE)
       Define this to return nonzero if libgcc provides support for the
       floating-point mode MODE, which is known to pass
!      'TARGET_SCALAR_MODE_SUPPORTED_P'.  The default version of this hook
!      returns true for all of 'SFmode', 'DFmode', 'XFmode' and 'TFmode',
       if such modes exist.
  
   -- Target Hook: opt_scalar_float_mode TARGET_FLOATN_MODE (int N, bool
            EXTENDED)
       Define this to return the machine mode to use for the type
!      '_FloatN', if EXTENDED is false, or the type '_FloatNx', if
       EXTENDED is true.  If such a type is not supported, return
!      'opt_scalar_float_mode ()'.  The default version of this hook
!      returns 'SFmode' for '_Float32', 'DFmode' for '_Float64' and
!      '_Float32x' and 'TFmode' for '_Float128', if those modes exist and
       satisfy the requirements for those types and pass
!      'TARGET_SCALAR_MODE_SUPPORTED_P' and
!      'TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P'; for '_Float64x', it
!      returns the first of 'XFmode' and 'TFmode' that exists and
       satisfies the same requirements; for other types, it returns
!      'opt_scalar_float_mode ()'.  The hook is only called for values of
       N and EXTENDED that are valid according to ISO/IEC TS 18661-3:2015;
       that is, N is one of 32, 64, 128, or, if EXTENDED is false, 16 or
       greater than 128 and a multiple of 32.
  
   -- Target Hook: bool TARGET_FLOATN_BUILTIN_P (int FUNC)
!      Define this to return true if the '_FloatN' and '_FloatNx' built-in
       functions should implicitly enable the built-in function without
!      the '__builtin_' prefix in addition to the normal built-in function
!      with the '__builtin_' prefix.  The default is to only enable
!      built-in functions without the '__builtin_' prefix for the GNU C
       langauge.  In strict ANSI/ISO mode, the built-in function without
!      the '__builtin_' prefix is not enabled.  The argument 'FUNC' is the
!      'enum built_in_function' id of the function to be enabled.
  
   -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P
            (machine_mode MODE)
       Define this to return nonzero for machine modes for which the port
       has small register classes.  If this target hook returns nonzero
       for a given MODE, the compiler will try to minimize the lifetime of
!      registers in MODE.  The hook may be called with 'VOIDmode' as
       argument.  In this case, the hook is expected to return nonzero if
       it returns nonzero for any mode.
  
--- 36566,36617 ----
              int8x8_t val[3];
            } int8x8x3_t;
  
!      If this hook allows ‘val’ to have a scalar mode, then ‘int8x8x3_t’
!      can have the same mode.  GCC can then store ‘int8x8x3_t’s in
       registers rather than forcing them onto the stack.
  
   -- Target Hook: bool TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P
            (scalar_float_mode MODE)
       Define this to return nonzero if libgcc provides support for the
       floating-point mode MODE, which is known to pass
!      ‘TARGET_SCALAR_MODE_SUPPORTED_P’.  The default version of this hook
!      returns true for all of ‘SFmode’, ‘DFmode’, ‘XFmode’ and ‘TFmode’,
       if such modes exist.
  
   -- Target Hook: opt_scalar_float_mode TARGET_FLOATN_MODE (int N, bool
            EXTENDED)
       Define this to return the machine mode to use for the type
!      ‘_FloatN’, if EXTENDED is false, or the type ‘_FloatNx’, if
       EXTENDED is true.  If such a type is not supported, return
!      ‘opt_scalar_float_mode ()’.  The default version of this hook
!      returns ‘SFmode’ for ‘_Float32’, ‘DFmode’ for ‘_Float64’ and
!      ‘_Float32x’ and ‘TFmode’ for ‘_Float128’, if those modes exist and
       satisfy the requirements for those types and pass
!      ‘TARGET_SCALAR_MODE_SUPPORTED_P’ and
!      ‘TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P’; for ‘_Float64x’, it
!      returns the first of ‘XFmode’ and ‘TFmode’ that exists and
       satisfies the same requirements; for other types, it returns
!      ‘opt_scalar_float_mode ()’.  The hook is only called for values of
       N and EXTENDED that are valid according to ISO/IEC TS 18661-3:2015;
       that is, N is one of 32, 64, 128, or, if EXTENDED is false, 16 or
       greater than 128 and a multiple of 32.
  
   -- Target Hook: bool TARGET_FLOATN_BUILTIN_P (int FUNC)
!      Define this to return true if the ‘_FloatN’ and ‘_FloatNx’ built-in
       functions should implicitly enable the built-in function without
!      the ‘__builtin_’ prefix in addition to the normal built-in function
!      with the ‘__builtin_’ prefix.  The default is to only enable
!      built-in functions without the ‘__builtin_’ prefix for the GNU C
       langauge.  In strict ANSI/ISO mode, the built-in function without
!      the ‘__builtin_’ prefix is not enabled.  The argument ‘FUNC’ is the
!      ‘enum built_in_function’ id of the function to be enabled.
  
   -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P
            (machine_mode MODE)
       Define this to return nonzero for machine modes for which the port
       has small register classes.  If this target hook returns nonzero
       for a given MODE, the compiler will try to minimize the lifetime of
!      registers in MODE.  The hook may be called with ‘VOIDmode’ as
       argument.  In this case, the hook is expected to return nonzero if
       it returns nonzero for any mode.
  
*************** the stack.
*** 36630,36636 ****
       requires specific registers for the legacy x86 integer
       instructions, but there are many SSE registers for floating point
       operations.  On such targets, a good strategy may be to return
!      nonzero from this hook for 'INTEGRAL_MODE_P' machine modes but zero
       for the SSE register classes.
  
       The default version of this hook returns false for any mode.  It is
--- 36629,36635 ----
       requires specific registers for the legacy x86 integer
       instructions, but there are many SSE registers for floating point
       operations.  On such targets, a good strategy may be to return
!      nonzero from this hook for ‘INTEGRAL_MODE_P’ machine modes but zero
       for the SSE register classes.
  
       The default version of this hook returns false for any mode.  It is
*************** values--values that can fit in registers
*** 36656,36686 ****
       Define this to return an RTX representing the place where a
       function returns or receives a value of data type RET_TYPE, a tree
       node representing a data type.  FN_DECL_OR_TYPE is a tree node
!      representing 'FUNCTION_DECL' or 'FUNCTION_TYPE' of a function being
       called.  If OUTGOING is false, the hook should compute the register
       in which the caller will see the return value.  Otherwise, the hook
       should return an RTX representing the place where a function
       returns a value.
  
!      On many machines, only 'TYPE_MODE (RET_TYPE)' is relevant.
       (Actually, on most machines, scalar values are returned in the same
       place regardless of mode.)  The value of the expression is usually
!      a 'reg' RTX for the hard register where the return value is stored.
!      The value can also be a 'parallel' RTX, if the return value is in
!      multiple places.  See 'TARGET_FUNCTION_ARG' for an explanation of
!      the 'parallel' form.  Note that the callee will populate every
!      location specified in the 'parallel', but if the first element of
!      the 'parallel' contains the whole return value, callers will use
       that element as the canonical location and ignore the others.  The
!      m68k port uses this type of 'parallel' to return pointers in both
!      '%a0' (the canonical location) and '%d0'.
  
!      If 'TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply
!      the same promotion rules specified in 'PROMOTE_MODE' if VALTYPE is
       a scalar type.
  
       If the precise function being called is known, FUNC is a tree node
!      ('FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.  This
       makes it possible to use a different value-returning convention for
       specific functions when all their calls are known.
  
--- 36655,36685 ----
       Define this to return an RTX representing the place where a
       function returns or receives a value of data type RET_TYPE, a tree
       node representing a data type.  FN_DECL_OR_TYPE is a tree node
!      representing ‘FUNCTION_DECL’ or ‘FUNCTION_TYPE’ of a function being
       called.  If OUTGOING is false, the hook should compute the register
       in which the caller will see the return value.  Otherwise, the hook
       should return an RTX representing the place where a function
       returns a value.
  
!      On many machines, only ‘TYPE_MODE (RET_TYPE)’ is relevant.
       (Actually, on most machines, scalar values are returned in the same
       place regardless of mode.)  The value of the expression is usually
!      a ‘reg’ RTX for the hard register where the return value is stored.
!      The value can also be a ‘parallel’ RTX, if the return value is in
!      multiple places.  See ‘TARGET_FUNCTION_ARG’ for an explanation of
!      the ‘parallel’ form.  Note that the callee will populate every
!      location specified in the ‘parallel’, but if the first element of
!      the ‘parallel’ contains the whole return value, callers will use
       that element as the canonical location and ignore the others.  The
!      m68k port uses this type of ‘parallel’ to return pointers in both
!      ‘%a0’ (the canonical location) and ‘%d0’.
  
!      If ‘TARGET_PROMOTE_FUNCTION_RETURN’ returns true, you must apply
!      the same promotion rules specified in ‘PROMOTE_MODE’ if VALTYPE is
       a scalar type.
  
       If the precise function being called is known, FUNC is a tree node
!      (‘FUNCTION_DECL’) for it; otherwise, FUNC is a null pointer.  This
       makes it possible to use a different value-returning convention for
       specific functions when all their calls are known.
  
*************** values--values that can fit in registers
*** 36689,36700 ****
       which the caller sees the value.  For such machines, you should
       return different RTX depending on OUTGOING.
  
!      'TARGET_FUNCTION_VALUE' is not used for return values with
       aggregate data types, because these are returned in another way.
!      See 'TARGET_STRUCT_VALUE_RTX' and related macros, below.
  
   -- Macro: FUNCTION_VALUE (VALTYPE, FUNC)
!      This macro has been deprecated.  Use 'TARGET_FUNCTION_VALUE' for a
       new target instead.
  
   -- Macro: LIBCALL_VALUE (MODE)
--- 36688,36699 ----
       which the caller sees the value.  For such machines, you should
       return different RTX depending on OUTGOING.
  
!      ‘TARGET_FUNCTION_VALUE’ is not used for return values with
       aggregate data types, because these are returned in another way.
!      See ‘TARGET_STRUCT_VALUE_RTX’ and related macros, below.
  
   -- Macro: FUNCTION_VALUE (VALTYPE, FUNC)
!      This macro has been deprecated.  Use ‘TARGET_FUNCTION_VALUE’ for a
       new target instead.
  
   -- Macro: LIBCALL_VALUE (MODE)
*************** values--values that can fit in registers
*** 36724,36730 ****
       register in which the values of called function may come back.
  
       A register whose use for returning values is limited to serving as
!      the second of a pair (for a value of type 'double', say) need not
       be recognized by this macro.  So for most machines, this definition
       suffices:
  
--- 36723,36729 ----
       register in which the values of called function may come back.
  
       A register whose use for returning values is limited to serving as
!      the second of a pair (for a value of type ‘double’, say) need not
       be recognized by this macro.  So for most machines, this definition
       suffices:
  
*************** values--values that can fit in registers
*** 36735,36749 ****
       macro should recognize only the caller's register numbers.
  
       This macro has been deprecated.  Use
!      'TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead.
  
   -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int
            REGNO)
!      A target hook that return 'true' if REGNO is the number of a hard
       register in which the values of called function may come back.
  
       A register whose use for returning values is limited to serving as
!      the second of a pair (for a value of type 'double', say) need not
       be recognized by this target hook.
  
       If the machine has register windows, so that the caller and the
--- 36734,36748 ----
       macro should recognize only the caller's register numbers.
  
       This macro has been deprecated.  Use
!      ‘TARGET_FUNCTION_VALUE_REGNO_P’ for a new target instead.
  
   -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int
            REGNO)
!      A target hook that return ‘true’ if REGNO is the number of a hard
       register in which the values of called function may come back.
  
       A register whose use for returning values is limited to serving as
!      the second of a pair (for a value of type ‘double’, say) need not
       be recognized by this target hook.
  
       If the machine has register windows, so that the caller and the
*************** values--values that can fit in registers
*** 36754,36761 ****
       used.
  
   -- Macro: APPLY_RESULT_SIZE
!      Define this macro if 'untyped_call' and 'untyped_return' need more
!      space than is implied by 'FUNCTION_VALUE_REGNO_P' for saving and
       restoring an arbitrary return value.
  
   -- Target Hook: bool TARGET_OMIT_STRUCT_RETURN_REG
--- 36753,36760 ----
       used.
  
   -- Macro: APPLY_RESULT_SIZE
!      Define this macro if ‘untyped_call’ and ‘untyped_return’ need more
!      space than is implied by ‘FUNCTION_VALUE_REGNO_P’ for saving and
       restoring an arbitrary return value.
  
   -- Target Hook: bool TARGET_OMIT_STRUCT_RETURN_REG
*************** values--values that can fit in registers
*** 36771,36780 ****
       padded at the least significant end).  You can assume that TYPE is
       returned in a register; the caller is required to check this.
  
!      Note that the register provided by 'TARGET_FUNCTION_VALUE' must be
       able to hold the complete return value.  For example, if a 1-, 2-
       or 3-byte structure is returned at the most significant end of a
!      4-byte register, 'TARGET_FUNCTION_VALUE' should provide an 'SImode'
       rtx.
  
  
--- 36770,36779 ----
       padded at the least significant end).  You can assume that TYPE is
       returned in a register; the caller is required to check this.
  
!      Note that the register provided by ‘TARGET_FUNCTION_VALUE’ must be
       able to hold the complete return value.  For example, if a 1-, 2-
       or 3-byte structure is returned at the most significant end of a
!      4-byte register, ‘TARGET_FUNCTION_VALUE’ should provide an ‘SImode’
       rtx.
  
  
*************** File: gccint.info,  Node: Aggregate Retu
*** 36783,36793 ****
  18.9.9 How Large Values Are Returned
  ------------------------------------
  
! When a function value's mode is 'BLKmode' (and in some other cases), the
! value is not returned according to 'TARGET_FUNCTION_VALUE' (*note Scalar
  Return::).  Instead, the caller passes the address of a block of memory
  in which the value should be stored.  This address is called the
! "structure value address".
  
   This section describes how to control returning structure values in
  memory.
--- 36782,36792 ----
  18.9.9 How Large Values Are Returned
  ------------------------------------
  
! When a function value's mode is ‘BLKmode’ (and in some other cases), the
! value is not returned according to ‘TARGET_FUNCTION_VALUE’ (*note Scalar
  Return::).  Instead, the caller passes the address of a block of memory
  in which the value should be stored.  This address is called the
! “structure value address”.
  
   This section describes how to control returning structure values in
  memory.
*************** memory.
*** 36797,36815 ****
       This target hook should return a nonzero value to say to return the
       function value in memory, just as large structures are always
       returned.  Here TYPE will be the data type of the value, and FNTYPE
!      will be the type of the function doing the returning, or 'NULL' for
       libcalls.
  
!      Note that values of mode 'BLKmode' must be explicitly handled by
!      this function.  Also, the option '-fpcc-struct-return' takes effect
       regardless of this macro.  On most systems, it is possible to leave
       the hook undefined; this causes a default definition to be used,
!      whose value is the constant 1 for 'BLKmode' values, and 0
       otherwise.
  
       Do not use this hook to indicate that structures and unions should
       always be returned in memory.  You should instead use
!      'DEFAULT_PCC_STRUCT_RETURN' to indicate this.
  
   -- Macro: DEFAULT_PCC_STRUCT_RETURN
       Define this macro to be 1 if all structure and union return values
--- 36796,36814 ----
       This target hook should return a nonzero value to say to return the
       function value in memory, just as large structures are always
       returned.  Here TYPE will be the data type of the value, and FNTYPE
!      will be the type of the function doing the returning, or ‘NULL’ for
       libcalls.
  
!      Note that values of mode ‘BLKmode’ must be explicitly handled by
!      this function.  Also, the option ‘-fpcc-struct-return’ takes effect
       regardless of this macro.  On most systems, it is possible to leave
       the hook undefined; this causes a default definition to be used,
!      whose value is the constant 1 for ‘BLKmode’ values, and 0
       otherwise.
  
       Do not use this hook to indicate that structures and unions should
       always be returned in memory.  You should instead use
!      ‘DEFAULT_PCC_STRUCT_RETURN’ to indicate this.
  
   -- Macro: DEFAULT_PCC_STRUCT_RETURN
       Define this macro to be 1 if all structure and union return values
*************** memory.
*** 36817,36830 ****
       be defined only if needed for compatibility with other compilers or
       with an ABI.  If you define this macro to be 0, then the
       conventions used for structure and union return values are decided
!      by the 'TARGET_RETURN_IN_MEMORY' target hook.
  
       If not defined, this defaults to the value 1.
  
   -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING)
       This target hook should return the location of the structure value
!      address (normally a 'mem' or 'reg'), or 0 if the address is passed
!      as an "invisible" first argument.  Note that FNDECL may be 'NULL',
       for libcalls.  You do not need to define this target hook if the
       address is always passed as an "invisible" first argument.
  
--- 36816,36829 ----
       be defined only if needed for compatibility with other compilers or
       with an ABI.  If you define this macro to be 0, then the
       conventions used for structure and union return values are decided
!      by the ‘TARGET_RETURN_IN_MEMORY’ target hook.
  
       If not defined, this defaults to the value 1.
  
   -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING)
       This target hook should return the location of the structure value
!      address (normally a ‘mem’ or ‘reg’), or 0 if the address is passed
!      as an "invisible" first argument.  Note that FNDECL may be ‘NULL’,
       for libcalls.  You do not need to define this target hook if the
       address is always passed as an "invisible" first argument.
  
*************** memory.
*** 36832,36843 ****
       is found by the called function is not the same place that the
       caller put it.  This can be due to register windows, or it could be
       because the function prologue moves it to a different place.
!      INCOMING is '1' or '2' when the location is needed in the context
!      of the called function, and '0' in the context of the caller.
  
       If INCOMING is nonzero and the address is to be found on the stack,
!      return a 'mem' which refers to the frame pointer.  If INCOMING is
!      '2', the result is being used to fetch the structure value address
       at the beginning of a function.  If you need to emit adjusting
       code, you should do it at this point.
  
--- 36831,36842 ----
       is found by the called function is not the same place that the
       caller put it.  This can be due to register windows, or it could be
       because the function prologue moves it to a different place.
!      INCOMING is ‘1’ or ‘2’ when the location is needed in the context
!      of the called function, and ‘0’ in the context of the caller.
  
       If INCOMING is nonzero and the address is to be found on the stack,
!      return a ‘mem’ which refers to the frame pointer.  If INCOMING is
!      ‘2’, the result is being used to fetch the structure value address
       at the beginning of a function.  If you need to emit adjusting
       code, you should do it at this point.
  
*************** memory.
*** 36850,36873 ****
       Do not define this if the usual system convention is for the caller
       to pass an address to the subroutine.
  
!      This macro has effect in '-fpcc-struct-return' mode, but it does
!      nothing when you use '-freg-struct-return' mode.
  
   -- Target Hook: fixed_size_mode TARGET_GET_RAW_RESULT_MODE (int REGNO)
       This target hook returns the mode to be used when accessing raw
!      return registers in '__builtin_return'.  Define this macro if the
!      value in REG_RAW_MODE is not correct.  Use 'VOIDmode' if a register
!      should be ignored for '__builtin_return' purposes.
  
   -- Target Hook: fixed_size_mode TARGET_GET_RAW_ARG_MODE (int REGNO)
       This target hook returns the mode to be used when accessing raw
!      argument registers in '__builtin_apply_args'.  Define this macro if
!      the value in REG_RAW_MODE is not correct.  Use 'VOIDmode' if a
!      register should be ignored for '__builtin_apply_args' purposes.
  
   -- Target Hook: bool TARGET_EMPTY_RECORD_P (const_tree TYPE)
       This target hook returns true if the type is an empty record.  The
!      default is to return 'false'.
  
   -- Target Hook: void TARGET_WARN_PARAMETER_PASSING_ABI
            (cumulative_args_t CA, tree TYPE)
--- 36849,36872 ----
       Do not define this if the usual system convention is for the caller
       to pass an address to the subroutine.
  
!      This macro has effect in ‘-fpcc-struct-return’ mode, but it does
!      nothing when you use ‘-freg-struct-return’ mode.
  
   -- Target Hook: fixed_size_mode TARGET_GET_RAW_RESULT_MODE (int REGNO)
       This target hook returns the mode to be used when accessing raw
!      return registers in ‘__builtin_return’.  Define this macro if the
!      value in REG_RAW_MODE is not correct.  Use ‘VOIDmode’ if a register
!      should be ignored for ‘__builtin_return’ purposes.
  
   -- Target Hook: fixed_size_mode TARGET_GET_RAW_ARG_MODE (int REGNO)
       This target hook returns the mode to be used when accessing raw
!      argument registers in ‘__builtin_apply_args’.  Define this macro if
!      the value in REG_RAW_MODE is not correct.  Use ‘VOIDmode’ if a
!      register should be ignored for ‘__builtin_apply_args’ purposes.
  
   -- Target Hook: bool TARGET_EMPTY_RECORD_P (const_tree TYPE)
       This target hook returns true if the type is an empty record.  The
!      default is to return ‘false’.
  
   -- Target Hook: void TARGET_WARN_PARAMETER_PASSING_ABI
            (cumulative_args_t CA, tree TYPE)
*************** must live across calls.
*** 36887,36893 ****
   -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)
       A C expression specifying which mode is required for saving NREGS
       of a pseudo-register in call-clobbered hard register REGNO.  If
!      REGNO is unsuitable for caller save, 'VOIDmode' should be returned.
       For most machines this macro need not be defined since GCC will
       select the smallest suitable mode.
  
--- 36886,36892 ----
   -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)
       A C expression specifying which mode is required for saving NREGS
       of a pseudo-register in call-clobbered hard register REGNO.  If
!      REGNO is unsuitable for caller save, ‘VOIDmode’ should be returned.
       For most machines this macro need not be defined since GCC will
       select the smallest suitable mode.
  
*************** File: gccint.info,  Node: Function Entry
*** 36898,36904 ****
  -------------------------------
  
  This section describes the macros that output function entry
! ("prologue") and exit ("epilogue") code.
  
   -- Target Hook: void TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY (FILE
            *FILE, unsigned HOST_WIDE_INT PATCH_AREA_SIZE, bool RECORD_P)
--- 36897,36903 ----
  -------------------------------
  
  This section describes the macros that output function entry
! (“prologue”) and exit (“epilogue”) code.
  
   -- Target Hook: void TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY (FILE
            *FILE, unsigned HOST_WIDE_INT PATCH_AREA_SIZE, bool RECORD_P)
*************** This section describes the macros that o
*** 36907,36913 ****
       sections and if RECORD_P is true, insert a pointer to the current
       location in the table of patchable functions.  The default
       implementation of the hook places the table of pointers in the
!      special section named '__patchable_function_entries'.
  
   -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE)
       If defined, a function that outputs the assembler code for entry to
--- 36906,36912 ----
       sections and if RECORD_P is true, insert a pointer to the current
       location in the table of patchable functions.  The default
       implementation of the hook places the table of pointers in the
!      special section named ‘__patchable_function_entries’.
  
   -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE)
       If defined, a function that outputs the assembler code for entry to
*************** This section describes the macros that o
*** 36921,36931 ****
       this macro.  That has already been done when the macro is run.
  
       To determine which registers to save, the macro can refer to the
!      array 'regs_ever_live': element R is nonzero if hard register R is
       used anywhere within the function.  This implies the function
       prologue should save register R, provided it is not one of the
!      call-used registers.  ('TARGET_ASM_FUNCTION_EPILOGUE' must likewise
!      use 'regs_ever_live'.)
  
       On machines that have "register windows", the function entry code
       does not save on the stack the registers that are in the windows,
--- 36920,36930 ----
       this macro.  That has already been done when the macro is run.
  
       To determine which registers to save, the macro can refer to the
!      array ‘regs_ever_live’: element R is nonzero if hard register R is
       used anywhere within the function.  This implies the function
       prologue should save register R, provided it is not one of the
!      call-used registers.  (‘TARGET_ASM_FUNCTION_EPILOGUE’ must likewise
!      use ‘regs_ever_live’.)
  
       On machines that have "register windows", the function entry code
       does not save on the stack the registers that are in the windows,
*************** This section describes the macros that o
*** 36937,36950 ****
       function entry code must vary accordingly; it must set up the frame
       pointer if one is wanted, and not otherwise.  To determine whether
       a frame pointer is in wanted, the macro can refer to the variable
!      'frame_pointer_needed'.  The variable's value will be 1 at run time
       in a function that needs a frame pointer.  *Note Elimination::.
  
       The function entry code is responsible for allocating any stack
       space required for the function.  This stack space consists of the
       regions listed below.  In most cases, these regions are allocated
       in the order listed, with the last listed region closest to the top
!      of the stack (the lowest address if 'STACK_GROWS_DOWNWARD' is
       defined, and the highest address if it is not defined).  You can
       use a different order for a machine if doing so is more convenient
       or required for compatibility reasons.  Except in cases where
--- 36936,36949 ----
       function entry code must vary accordingly; it must set up the frame
       pointer if one is wanted, and not otherwise.  To determine whether
       a frame pointer is in wanted, the macro can refer to the variable
!      ‘frame_pointer_needed’.  The variable's value will be 1 at run time
       in a function that needs a frame pointer.  *Note Elimination::.
  
       The function entry code is responsible for allocating any stack
       space required for the function.  This stack space consists of the
       regions listed below.  In most cases, these regions are allocated
       in the order listed, with the last listed region closest to the top
!      of the stack (the lowest address if ‘STACK_GROWS_DOWNWARD’ is
       defined, and the highest address if it is not defined).  You can
       use a different order for a machine if doing so is more convenient
       or required for compatibility reasons.  Except in cases where
*************** This section describes the macros that o
*** 36969,37014 ****
       from a function.  The epilogue is responsible for restoring the
       saved registers and stack pointer to their values when the function
       was called, and returning control to the caller.  This macro takes
!      the same argument as the macro 'TARGET_ASM_FUNCTION_PROLOGUE', and
!      the registers to restore are determined from 'regs_ever_live' and
!      'CALL_USED_REGISTERS' in the same way.
  
       On some machines, there is a single instruction that does all the
       work of returning from the function.  On these machines, give that
!      instruction the name 'return' and do not define the macro
!      'TARGET_ASM_FUNCTION_EPILOGUE' at all.
  
!      Do not define a pattern named 'return' if you want the
!      'TARGET_ASM_FUNCTION_EPILOGUE' to be used.  If you want the target
       switches to control whether return instructions or epilogues are
!      used, define a 'return' pattern with a validity condition that
!      tests the target switches appropriately.  If the 'return' pattern's
       validity condition is false, epilogues will be used.
  
       On machines where functions may or may not have frame-pointers, the
       function exit code must vary accordingly.  Sometimes the code for
       these two cases is completely different.  To determine whether a
       frame pointer is wanted, the macro can refer to the variable
!      'frame_pointer_needed'.  The variable's value will be 1 when
       compiling a function that needs a frame pointer.
  
!      Normally, 'TARGET_ASM_FUNCTION_PROLOGUE' and
!      'TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially.
!      The C variable 'current_function_is_leaf' is nonzero for such a
       function.  *Note Leaf Functions::.
  
       On some machines, some functions pop their arguments on exit while
       others leave that for the caller to do.  For example, the 68020
!      when given '-mrtd' pops arguments in functions that take a fixed
       number of arguments.
  
!      Your definition of the macro 'RETURN_POPS_ARGS' decides which
!      functions pop their own arguments.  'TARGET_ASM_FUNCTION_EPILOGUE'
       needs to know what was decided.  The number of bytes of the current
       function's arguments that this function should pop is available in
!      'crtl->args.pops_args'.  *Note Scalar Return::.
  
!    * A region of 'crtl->args.pretend_args_size' bytes of uninitialized
       space just underneath the first argument arriving on the stack.
       (This may not be at the very start of the allocated stack region if
       the calling sequence has pushed anything else since pushing the
--- 36968,37013 ----
       from a function.  The epilogue is responsible for restoring the
       saved registers and stack pointer to their values when the function
       was called, and returning control to the caller.  This macro takes
!      the same argument as the macro ‘TARGET_ASM_FUNCTION_PROLOGUE’, and
!      the registers to restore are determined from ‘regs_ever_live’ and
!      ‘CALL_USED_REGISTERS’ in the same way.
  
       On some machines, there is a single instruction that does all the
       work of returning from the function.  On these machines, give that
!      instruction the name ‘return’ and do not define the macro
!      ‘TARGET_ASM_FUNCTION_EPILOGUE’ at all.
  
!      Do not define a pattern named ‘return’ if you want the
!      ‘TARGET_ASM_FUNCTION_EPILOGUE’ to be used.  If you want the target
       switches to control whether return instructions or epilogues are
!      used, define a ‘return’ pattern with a validity condition that
!      tests the target switches appropriately.  If the ‘return’ pattern's
       validity condition is false, epilogues will be used.
  
       On machines where functions may or may not have frame-pointers, the
       function exit code must vary accordingly.  Sometimes the code for
       these two cases is completely different.  To determine whether a
       frame pointer is wanted, the macro can refer to the variable
!      ‘frame_pointer_needed’.  The variable's value will be 1 when
       compiling a function that needs a frame pointer.
  
!      Normally, ‘TARGET_ASM_FUNCTION_PROLOGUE’ and
!      ‘TARGET_ASM_FUNCTION_EPILOGUE’ must treat leaf functions specially.
!      The C variable ‘current_function_is_leaf’ is nonzero for such a
       function.  *Note Leaf Functions::.
  
       On some machines, some functions pop their arguments on exit while
       others leave that for the caller to do.  For example, the 68020
!      when given ‘-mrtd’ pops arguments in functions that take a fixed
       number of arguments.
  
!      Your definition of the macro ‘RETURN_POPS_ARGS’ decides which
!      functions pop their own arguments.  ‘TARGET_ASM_FUNCTION_EPILOGUE’
       needs to know what was decided.  The number of bytes of the current
       function's arguments that this function should pop is available in
!      ‘crtl->args.pops_args’.  *Note Scalar Return::.
  
!    • A region of ‘crtl->args.pretend_args_size’ bytes of uninitialized
       space just underneath the first argument arriving on the stack.
       (This may not be at the very start of the allocated stack region if
       the calling sequence has pushed anything else since pushing the
*************** This section describes the macros that o
*** 37016,37038 ****
       been pushed yet, because the function prologue itself does all the
       pushing.)  This region is used on machines where an argument may be
       passed partly in registers and partly in memory, and, in some cases
!      to support the features in ''.
  
!    * An area of memory used to save certain registers used by the
       function.  The size of this area, which may also include space for
       such things as the return address and pointers to previous stack
       frames, is machine-specific and usually depends on which registers
       have been used in the function.  Machines with register windows
       often do not require a save area.
  
!    * A region of at least SIZE bytes, possibly rounded up to an
       allocation boundary, to contain the local variables of the
       function.  On some machines, this region and the save area may
       occur in the opposite order, with the save area closer to the top
       of the stack.
  
!    * Optionally, when 'ACCUMULATE_OUTGOING_ARGS' is defined, a region of
!      'crtl->outgoing_args_size' bytes to be used for outgoing argument
       lists of the function.  *Note Stack Arguments::.
  
   -- Macro: EXIT_IGNORE_STACK
--- 37015,37037 ----
       been pushed yet, because the function prologue itself does all the
       pushing.)  This region is used on machines where an argument may be
       passed partly in registers and partly in memory, and, in some cases
!      to support the features in ‘’.
  
!    • An area of memory used to save certain registers used by the
       function.  The size of this area, which may also include space for
       such things as the return address and pointers to previous stack
       frames, is machine-specific and usually depends on which registers
       have been used in the function.  Machines with register windows
       often do not require a save area.
  
!    • A region of at least SIZE bytes, possibly rounded up to an
       allocation boundary, to contain the local variables of the
       function.  On some machines, this region and the save area may
       occur in the opposite order, with the save area closer to the top
       of the stack.
  
!    • Optionally, when ‘ACCUMULATE_OUTGOING_ARGS’ is defined, a region of
!      ‘crtl->outgoing_args_size’ bytes to be used for outgoing argument
       lists of the function.  *Note Stack Arguments::.
  
   -- Macro: EXIT_IGNORE_STACK
*************** This section describes the macros that o
*** 37045,37055 ****
       Note that this macro's value is relevant only for functions for
       which frame pointers are maintained.  It is never safe to delete a
       final stack adjustment in a function that has no frame pointer, and
!      the compiler knows this regardless of 'EXIT_IGNORE_STACK'.
  
   -- Macro: EPILOGUE_USES (REGNO)
       Define this macro as a C expression that is nonzero for registers
!      that are used by the epilogue or the 'return' pattern.  The stack
       and frame pointer registers are already assumed to be used as
       needed.
  
--- 37044,37054 ----
       Note that this macro's value is relevant only for functions for
       which frame pointers are maintained.  It is never safe to delete a
       final stack adjustment in a function that has no frame pointer, and
!      the compiler knows this regardless of ‘EXIT_IGNORE_STACK’.
  
   -- Macro: EPILOGUE_USES (REGNO)
       Define this macro as a C expression that is nonzero for registers
!      that are used by the epilogue or the ‘return’ pattern.  The stack
       and frame pointer registers are already assumed to be used as
       needed.
  
*************** This section describes the macros that o
*** 37069,37094 ****
  
       First, emit code to add the integer DELTA to the location that
       contains the incoming first argument.  Assume that this argument
!      contains a pointer, and is the one used to pass the 'this' pointer
       in C++.  This is the incoming argument _before_ the function
!      prologue, e.g. '%o0' on a sparc.  The addition must preserve the
       values of all other incoming arguments.
  
       Then, if VCALL_OFFSET is nonzero, an additional adjustment should
!      be made after adding 'delta'.  In particular, if P is the adjusted
       pointer, the following adjustment should be made:
  
            p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)]
  
       After the additions, emit code to jump to FUNCTION, which is a
!      'FUNCTION_DECL'.  This is a direct pure jump, not a call, and does
       not touch the return address.  Hence returning from FUNCTION will
!      return to whoever called the current 'thunk'.
  
       The effect must be as if FUNCTION had been called directly with the
       adjusted first argument.  This macro is responsible for emitting
       all of the code for a thunk function;
!      'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE'
       are not invoked.
  
       The THUNK_FNDECL is redundant.  (DELTA and FUNCTION have already
--- 37068,37093 ----
  
       First, emit code to add the integer DELTA to the location that
       contains the incoming first argument.  Assume that this argument
!      contains a pointer, and is the one used to pass the ‘this’ pointer
       in C++.  This is the incoming argument _before_ the function
!      prologue, e.g. ‘%o0’ on a sparc.  The addition must preserve the
       values of all other incoming arguments.
  
       Then, if VCALL_OFFSET is nonzero, an additional adjustment should
!      be made after adding ‘delta’.  In particular, if P is the adjusted
       pointer, the following adjustment should be made:
  
            p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)]
  
       After the additions, emit code to jump to FUNCTION, which is a
!      ‘FUNCTION_DECL’.  This is a direct pure jump, not a call, and does
       not touch the return address.  Hence returning from FUNCTION will
!      return to whoever called the current ‘thunk’.
  
       The effect must be as if FUNCTION had been called directly with the
       adjusted first argument.  This macro is responsible for emitting
       all of the code for a thunk function;
!      ‘TARGET_ASM_FUNCTION_PROLOGUE’ and ‘TARGET_ASM_FUNCTION_EPILOGUE’
       are not invoked.
  
       The THUNK_FNDECL is redundant.  (DELTA and FUNCTION have already
*************** These macros will help you generate code
*** 37119,37147 ****
  
   -- Macro: FUNCTION_PROFILER (FILE, LABELNO)
       A C statement or compound statement to output to FILE some
!      assembler code to call the profiling subroutine 'mcount'.
  
!      The details of how 'mcount' expects to be called are determined by
       your operating system environment, not by GCC.  To figure them out,
       compile a small program for profiling using the system's installed
       C compiler and look at the assembler code that results.
  
!      Older implementations of 'mcount' expect the address of a counter
       variable to be loaded into some register.  The name of this
!      variable is 'LP' followed by the number LABELNO, so you would
!      generate the name using 'LP%d' in a 'fprintf'.
  
   -- Macro: PROFILE_HOOK
       A C statement or compound statement to output to FILE some assembly
!      code to call the profiling subroutine 'mcount' even the target does
       not support profiling.
  
   -- Macro: NO_PROFILE_COUNTERS
       Define this macro to be an expression with a nonzero value if the
!      'mcount' subroutine on your system does not need a counter variable
       allocated for each function.  This is true for almost all modern
       implementations.  If you define this macro, you must not use the
!      LABELNO argument to 'FUNCTION_PROFILER'.
  
   -- Macro: PROFILE_BEFORE_PROLOGUE
       Define this macro if the code for function profiling should come
--- 37118,37146 ----
  
   -- Macro: FUNCTION_PROFILER (FILE, LABELNO)
       A C statement or compound statement to output to FILE some
!      assembler code to call the profiling subroutine ‘mcount’.
  
!      The details of how ‘mcount’ expects to be called are determined by
       your operating system environment, not by GCC.  To figure them out,
       compile a small program for profiling using the system's installed
       C compiler and look at the assembler code that results.
  
!      Older implementations of ‘mcount’ expect the address of a counter
       variable to be loaded into some register.  The name of this
!      variable is ‘LP’ followed by the number LABELNO, so you would
!      generate the name using ‘LP%d’ in a ‘fprintf’.
  
   -- Macro: PROFILE_HOOK
       A C statement or compound statement to output to FILE some assembly
!      code to call the profiling subroutine ‘mcount’ even the target does
       not support profiling.
  
   -- Macro: NO_PROFILE_COUNTERS
       Define this macro to be an expression with a nonzero value if the
!      ‘mcount’ subroutine on your system does not need a counter variable
       allocated for each function.  This is true for almost all modern
       implementations.  If you define this macro, you must not use the
!      LABELNO argument to ‘FUNCTION_PROFILER’.
  
   -- Macro: PROFILE_BEFORE_PROLOGUE
       Define this macro if the code for function profiling should come
*************** File: gccint.info,  Node: Tail Calls,  N
*** 37164,37176 ****
   -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree
            EXP)
       True if it is OK to do sibling call optimization for the specified
!      call expression EXP.  DECL will be the called function, or 'NULL'
       if this is an indirect call.
  
       It is not uncommon for limitations of calling conventions to
       prevent tail calls to functions outside the current unit of
       translation, or during PIC compilation.  The hook is used to
!      enforce these restrictions, as the 'sibcall' md pattern cannot
       fail, or fall over to a "normal" call.  The criteria for successful
       sibling call optimization may vary greatly between different
       architectures.
--- 37163,37175 ----
   -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree
            EXP)
       True if it is OK to do sibling call optimization for the specified
!      call expression EXP.  DECL will be the called function, or ‘NULL’
       if this is an indirect call.
  
       It is not uncommon for limitations of calling conventions to
       prevent tail calls to functions outside the current unit of
       translation, or during PIC compilation.  The hook is used to
!      enforce these restrictions, as the ‘sibcall’ md pattern cannot
       fail, or fall over to a "normal" call.  The criteria for successful
       sibling call optimization may vary greatly between different
       architectures.
*************** teardown) those components do is not don
*** 37218,37242 ****
  paths where this would unnecessary.
  
   What exactly those components are is up to the target code; the generic
! code treats them abstractly, as a bit in an 'sbitmap'.  These 'sbitmap's
! are allocated by the 'shrink_wrap.get_separate_components' and
! 'shrink_wrap.components_for_bb' hooks, and deallocated by the generic
  code.
  
   -- Target Hook: sbitmap TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS
            (void)
!      This hook should return an 'sbitmap' with the bits set for those
       components that can be separately shrink-wrapped in the current
!      function.  Return 'NULL' if the current function should not get any
       separate shrink-wrapping.  Don't define this hook if it would
!      always return 'NULL'.  If it is defined, the other hooks in this
       group have to be defined as well.
  
   -- Target Hook: sbitmap TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB
            (basic_block)
!      This hook should return an 'sbitmap' with the bits set for those
       components where either the prologue component has to be executed
!      before the 'basic_block', or the epilogue component after it, or
       both.
  
   -- Target Hook: void TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS (sbitmap
--- 37217,37241 ----
  paths where this would unnecessary.
  
   What exactly those components are is up to the target code; the generic
! code treats them abstractly, as a bit in an ‘sbitmap’.  These ‘sbitmap’s
! are allocated by the ‘shrink_wrap.get_separate_components’ and
! ‘shrink_wrap.components_for_bb’ hooks, and deallocated by the generic
  code.
  
   -- Target Hook: sbitmap TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS
            (void)
!      This hook should return an ‘sbitmap’ with the bits set for those
       components that can be separately shrink-wrapped in the current
!      function.  Return ‘NULL’ if the current function should not get any
       separate shrink-wrapping.  Don't define this hook if it would
!      always return ‘NULL’.  If it is defined, the other hooks in this
       group have to be defined as well.
  
   -- Target Hook: sbitmap TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB
            (basic_block)
!      This hook should return an ‘sbitmap’ with the bits set for those
       components where either the prologue component has to be executed
!      before the ‘basic_block’, or the epilogue component after it, or
       both.
  
   -- Target Hook: void TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS (sbitmap
*************** code.
*** 37257,37264 ****
   -- Target Hook: void TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS
            (sbitmap)
       Mark the components in the parameter as handled, so that the
!      'prologue' and 'epilogue' named patterns know to ignore those
!      components.  The target code should not hang on to the 'sbitmap',
       it will be deleted after this call.
  
  
--- 37256,37263 ----
   -- Target Hook: void TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS
            (sbitmap)
       Mark the components in the parameter as handled, so that the
!      ‘prologue’ and ‘epilogue’ named patterns know to ignore those
!      components.  The target code should not hang on to the ‘sbitmap’,
       it will be deleted after this call.
  
  
*************** File: gccint.info,  Node: Stack Smashing
*** 37268,37290 ****
  ---------------------------------
  
   -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void)
!      This hook returns a 'DECL' node for the external variable to use
       for the stack protection guard.  This variable is initialized by
       the runtime to some random value and is used to initialize the
       guard value that is placed at the top of the local stack frame.
!      The type of this variable must be 'ptr_type_node'.
  
       The default version of this hook creates a variable called
!      '__stack_chk_guard', which is normally defined in 'libgcc2.c'.
  
   -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void)
!      This hook returns a 'CALL_EXPR' that alerts the runtime that the
       stack protect guard variable has been modified.  This expression
!      should involve a call to a 'noreturn' function.
  
       The default version of this hook invokes a function called
!      '__stack_chk_fail', taking no arguments.  This function is normally
!      defined in 'libgcc2.c'.
  
   -- Target Hook: bool TARGET_STACK_PROTECT_RUNTIME_ENABLED_P (void)
       Returns true if the target wants GCC's default stack protect
--- 37267,37289 ----
  ---------------------------------
  
   -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void)
!      This hook returns a ‘DECL’ node for the external variable to use
       for the stack protection guard.  This variable is initialized by
       the runtime to some random value and is used to initialize the
       guard value that is placed at the top of the local stack frame.
!      The type of this variable must be ‘ptr_type_node’.
  
       The default version of this hook creates a variable called
!      ‘__stack_chk_guard’, which is normally defined in ‘libgcc2.c’.
  
   -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void)
!      This hook returns a ‘CALL_EXPR’ that alerts the runtime that the
       stack protect guard variable has been modified.  This expression
!      should involve a call to a ‘noreturn’ function.
  
       The default version of this hook invokes a function called
!      ‘__stack_chk_fail’, taking no arguments.  This function is normally
!      defined in ‘libgcc2.c’.
  
   -- Target Hook: bool TARGET_STACK_PROTECT_RUNTIME_ENABLED_P (void)
       Returns true if the target wants GCC's default stack protect
*************** File: gccint.info,  Node: Varargs,  Next
*** 37333,37432 ****
  18.10 Implementing the Varargs Macros
  =====================================
  
! GCC comes with an implementation of '' and '' that
  work without change on machines that pass arguments on the stack.  Other
  machines require their own implementations of varargs, and the two
  machine independent header files must have conditionals to include it.
  
!  ISO '' differs from traditional '' mainly in the
! calling convention for 'va_start'.  The traditional implementation takes
  just one argument, which is the variable in which to store the argument
! pointer.  The ISO implementation of 'va_start' takes an additional
  second argument.  The user is supposed to write the last named argument
  of the function here.
  
!  However, 'va_start' should not use this argument.  The way to find the
  end of the named arguments is with the built-in functions described
  below.
  
   -- Macro: __builtin_saveregs ()
       Use this built-in function to save the argument registers in memory
       so that the varargs mechanism can access them.  Both ISO and
!      traditional versions of 'va_start' must use '__builtin_saveregs',
!      unless you use 'TARGET_SETUP_INCOMING_VARARGS' (see below) instead.
  
!      On some machines, '__builtin_saveregs' is open-coded under the
!      control of the target hook 'TARGET_EXPAND_BUILTIN_SAVEREGS'.  On
       other machines, it calls a routine written in assembler language,
!      found in 'libgcc2.c'.
  
!      Code generated for the call to '__builtin_saveregs' appears at the
       beginning of the function, as opposed to where the call to
!      '__builtin_saveregs' is written, regardless of what the code is.
       This is because the registers must be saved before the function
       starts to use them for its own purposes.
  
   -- Macro: __builtin_next_arg (LASTARG)
       This builtin returns the address of the first anonymous stack
!      argument, as type 'void *'.  If 'ARGS_GROW_DOWNWARD', it returns
       the address of the location above the first anonymous stack
!      argument.  Use it in 'va_start' to initialize the pointer for
!      fetching arguments from the stack.  Also use it in 'va_start' to
       verify that the second parameter LASTARG is the last named argument
       of the current function.
  
   -- Macro: __builtin_classify_type (OBJECT)
       Since each machine has its own conventions for which data types are
!      passed in which kind of register, your implementation of 'va_arg'
       has to embody these conventions.  The easiest way to categorize the
!      specified data type is to use '__builtin_classify_type' together
!      with 'sizeof' and '__alignof__'.
  
!      '__builtin_classify_type' ignores the value of OBJECT, considering
       only its data type.  It returns an integer describing what kind of
       type that is--integer, floating, pointer, structure, and so on.
  
!      The file 'typeclass.h' defines an enumeration that you can use to
!      interpret the values of '__builtin_classify_type'.
  
   These machine description macros help implement varargs:
  
   -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void)
       If defined, this hook produces the machine-specific code for a call
!      to '__builtin_saveregs'.  This code will be moved to the very
       beginning of the function, before any parameter access are made.
       The return value of this function should be an RTX that contains
!      the value to use as the return of '__builtin_saveregs'.
  
   -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t
            ARGS_SO_FAR, const function_arg_info &ARG, int
            *PRETEND_ARGS_SIZE, int SECOND_TIME)
       This target hook offers an alternative to using
!      '__builtin_saveregs' and defining the hook
!      'TARGET_EXPAND_BUILTIN_SAVEREGS'.  Use it to store the anonymous
       register arguments into the stack so that all the arguments appear
       to have been passed consecutively on the stack.  Once this is done,
       you can use the standard implementation of varargs that works for
       machines that pass all their arguments on the stack.
  
!      The argument ARGS_SO_FAR points to the 'CUMULATIVE_ARGS' data
       structure, containing the values that are obtained after processing
       the named arguments.  The argument ARG describes the last of these
       named arguments.  The argument ARG should not be used if the
!      function type satisfies 'TYPE_NO_NAMED_ARGS_STDARG_P', since in
       that case there are no named arguments and all arguments are
!      accessed with 'va_arg'.
  
       The target hook should do two things: first, push onto the stack
       all the argument registers _not_ used for the named arguments, and
       second, store the size of the data thus pushed into the
!      'int'-valued variable pointed to by PRETEND_ARGS_SIZE.  The value
       that you store here will serve as additional offset for setting up
       the stack frame.
  
       Because you must generate code to push the anonymous arguments at
       compile time without knowing their data types,
!      'TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that
       have just a single category of argument register and use it
       uniformly for all data types.
  
--- 37332,37431 ----
  18.10 Implementing the Varargs Macros
  =====================================
  
! GCC comes with an implementation of ‘’ and ‘’ that
  work without change on machines that pass arguments on the stack.  Other
  machines require their own implementations of varargs, and the two
  machine independent header files must have conditionals to include it.
  
!  ISO ‘’ differs from traditional ‘’ mainly in the
! calling convention for ‘va_start’.  The traditional implementation takes
  just one argument, which is the variable in which to store the argument
! pointer.  The ISO implementation of ‘va_start’ takes an additional
  second argument.  The user is supposed to write the last named argument
  of the function here.
  
!  However, ‘va_start’ should not use this argument.  The way to find the
  end of the named arguments is with the built-in functions described
  below.
  
   -- Macro: __builtin_saveregs ()
       Use this built-in function to save the argument registers in memory
       so that the varargs mechanism can access them.  Both ISO and
!      traditional versions of ‘va_start’ must use ‘__builtin_saveregs’,
!      unless you use ‘TARGET_SETUP_INCOMING_VARARGS’ (see below) instead.
  
!      On some machines, ‘__builtin_saveregs’ is open-coded under the
!      control of the target hook ‘TARGET_EXPAND_BUILTIN_SAVEREGS’.  On
       other machines, it calls a routine written in assembler language,
!      found in ‘libgcc2.c’.
  
!      Code generated for the call to ‘__builtin_saveregs’ appears at the
       beginning of the function, as opposed to where the call to
!      ‘__builtin_saveregs’ is written, regardless of what the code is.
       This is because the registers must be saved before the function
       starts to use them for its own purposes.
  
   -- Macro: __builtin_next_arg (LASTARG)
       This builtin returns the address of the first anonymous stack
!      argument, as type ‘void *’.  If ‘ARGS_GROW_DOWNWARD’, it returns
       the address of the location above the first anonymous stack
!      argument.  Use it in ‘va_start’ to initialize the pointer for
!      fetching arguments from the stack.  Also use it in ‘va_start’ to
       verify that the second parameter LASTARG is the last named argument
       of the current function.
  
   -- Macro: __builtin_classify_type (OBJECT)
       Since each machine has its own conventions for which data types are
!      passed in which kind of register, your implementation of ‘va_arg’
       has to embody these conventions.  The easiest way to categorize the
!      specified data type is to use ‘__builtin_classify_type’ together
!      with ‘sizeof’ and ‘__alignof__’.
  
!      ‘__builtin_classify_type’ ignores the value of OBJECT, considering
       only its data type.  It returns an integer describing what kind of
       type that is--integer, floating, pointer, structure, and so on.
  
!      The file ‘typeclass.h’ defines an enumeration that you can use to
!      interpret the values of ‘__builtin_classify_type’.
  
   These machine description macros help implement varargs:
  
   -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void)
       If defined, this hook produces the machine-specific code for a call
!      to ‘__builtin_saveregs’.  This code will be moved to the very
       beginning of the function, before any parameter access are made.
       The return value of this function should be an RTX that contains
!      the value to use as the return of ‘__builtin_saveregs’.
  
   -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t
            ARGS_SO_FAR, const function_arg_info &ARG, int
            *PRETEND_ARGS_SIZE, int SECOND_TIME)
       This target hook offers an alternative to using
!      ‘__builtin_saveregs’ and defining the hook
!      ‘TARGET_EXPAND_BUILTIN_SAVEREGS’.  Use it to store the anonymous
       register arguments into the stack so that all the arguments appear
       to have been passed consecutively on the stack.  Once this is done,
       you can use the standard implementation of varargs that works for
       machines that pass all their arguments on the stack.
  
!      The argument ARGS_SO_FAR points to the ‘CUMULATIVE_ARGS’ data
       structure, containing the values that are obtained after processing
       the named arguments.  The argument ARG describes the last of these
       named arguments.  The argument ARG should not be used if the
!      function type satisfies ‘TYPE_NO_NAMED_ARGS_STDARG_P’, since in
       that case there are no named arguments and all arguments are
!      accessed with ‘va_arg’.
  
       The target hook should do two things: first, push onto the stack
       all the argument registers _not_ used for the named arguments, and
       second, store the size of the data thus pushed into the
!      ‘int’-valued variable pointed to by PRETEND_ARGS_SIZE.  The value
       that you store here will serve as additional offset for setting up
       the stack frame.
  
       Because you must generate code to push the anonymous arguments at
       compile time without knowing their data types,
!      ‘TARGET_SETUP_INCOMING_VARARGS’ is only useful on machines that
       have just a single category of argument register and use it
       uniformly for all data types.
  
*************** below.
*** 37434,37470 ****
       of the function are being analyzed for the second time.  This
       happens for an inline function, which is not actually compiled
       until the end of the source file.  The hook
!      'TARGET_SETUP_INCOMING_VARARGS' should not generate any
       instructions in this case.
  
   -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t
            CA)
!      Define this hook to return 'true' if the location where a function
       argument is passed depends on whether or not it is a named
       argument.
  
!      This hook controls how the NAMED argument to 'TARGET_FUNCTION_ARG'
       is set for varargs and stdarg functions.  If this hook returns
!      'true', the NAMED argument is always true for named arguments, and
!      false for unnamed arguments.  If it returns 'false', but
!      'TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns 'true', then all
       arguments are treated as named.  Otherwise, all named arguments
       except the last are treated as named.
  
!      You need not define this hook if it always returns 'false'.
  
   -- Target Hook: void TARGET_CALL_ARGS (rtx, TREE)
       While generating RTL for a function call, this target hook is
       invoked once for each argument passed to the function, either a
!      register returned by 'TARGET_FUNCTION_ARG' or a memory location.
       It is called just before the point where argument registers are
       stored.  The type of the function to be called is also passed as
!      the second argument; it is 'NULL_TREE' for libcalls.  The
!      'TARGET_END_CALL_ARGS' hook is invoked just after the code to copy
       the return reg has been emitted.  This functionality can be used to
       perform special setup of call argument registers if a target needs
       it.  For functions without arguments, the hook is called once with
!      'pc_rtx' passed instead of an argument register.  Most ports do not
       need to implement anything for this hook.
  
   -- Target Hook: void TARGET_END_CALL_ARGS (void)
--- 37433,37469 ----
       of the function are being analyzed for the second time.  This
       happens for an inline function, which is not actually compiled
       until the end of the source file.  The hook
!      ‘TARGET_SETUP_INCOMING_VARARGS’ should not generate any
       instructions in this case.
  
   -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t
            CA)
!      Define this hook to return ‘true’ if the location where a function
       argument is passed depends on whether or not it is a named
       argument.
  
!      This hook controls how the NAMED argument to ‘TARGET_FUNCTION_ARG’
       is set for varargs and stdarg functions.  If this hook returns
!      ‘true’, the NAMED argument is always true for named arguments, and
!      false for unnamed arguments.  If it returns ‘false’, but
!      ‘TARGET_PRETEND_OUTGOING_VARARGS_NAMED’ returns ‘true’, then all
       arguments are treated as named.  Otherwise, all named arguments
       except the last are treated as named.
  
!      You need not define this hook if it always returns ‘false’.
  
   -- Target Hook: void TARGET_CALL_ARGS (rtx, TREE)
       While generating RTL for a function call, this target hook is
       invoked once for each argument passed to the function, either a
!      register returned by ‘TARGET_FUNCTION_ARG’ or a memory location.
       It is called just before the point where argument registers are
       stored.  The type of the function to be called is also passed as
!      the second argument; it is ‘NULL_TREE’ for libcalls.  The
!      ‘TARGET_END_CALL_ARGS’ hook is invoked just after the code to copy
       the return reg has been emitted.  This functionality can be used to
       perform special setup of call argument registers if a target needs
       it.  For functions without arguments, the hook is called once with
!      ‘pc_rtx’ passed instead of an argument register.  Most ports do not
       need to implement anything for this hook.
  
   -- Target Hook: void TARGET_END_CALL_ARGS (void)
*************** below.
*** 37477,37486 ****
   -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED
            (cumulative_args_t CA)
       If you need to conditionally change ABIs so that one works with
!      'TARGET_SETUP_INCOMING_VARARGS', but the other works like neither
!      'TARGET_SETUP_INCOMING_VARARGS' nor 'TARGET_STRICT_ARGUMENT_NAMING'
!      was defined, then define this hook to return 'true' if
!      'TARGET_SETUP_INCOMING_VARARGS' is used, 'false' otherwise.
       Otherwise, you should not define this hook.
  
  
--- 37476,37485 ----
   -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED
            (cumulative_args_t CA)
       If you need to conditionally change ABIs so that one works with
!      ‘TARGET_SETUP_INCOMING_VARARGS’, but the other works like neither
!      ‘TARGET_SETUP_INCOMING_VARARGS’ nor ‘TARGET_STRICT_ARGUMENT_NAMING’
!      was defined, then define this hook to return ‘true’ if
!      ‘TARGET_SETUP_INCOMING_VARARGS’ is used, ‘false’ otherwise.
       Otherwise, you should not define this hook.
  
  
*************** handling to ensure that the static chain
*** 37494,37500 ****
  function is invoked via an indirect call.
  
   GCC has traditionally supported nested functions by creating an
! executable "trampoline" at run time when the address of a nested
  function is taken.  This is a small piece of code which normally resides
  on the stack, in the stack frame of the containing function.  The
  trampoline loads the static chain register and then jumps to the real
--- 37493,37499 ----
  function is invoked via an indirect call.
  
   GCC has traditionally supported nested functions by creating an
! executable “trampoline” at run time when the address of a nested
  function is taken.  This is a small piece of code which normally resides
  on the stack, in the stack frame of the containing function.  The
  trampoline loads the static chain register and then jumps to the real
*************** chain from the descriptor is handled at
*** 37511,37525 ****
  mandated by the ABI or be otherwise handled in a target-specific way by
  the back end in its code generation strategy for indirect calls.  GCC
  also provides its own generic descriptor implementation to support the
! '-fno-trampolines' option.  In this case runtime detection of function
  descriptors at indirect call sites relies on descriptor pointers being
  tagged with a bit that is never set in bare function addresses.  Since
  GCC's generic function descriptors are not ABI-compliant, this option is
  typically used only on a per-language basis (notably by Ada) or when it
  can otherwise be applied to the whole program.
  
!  For languages other than Ada, the '-ftrampolines' and
! '-fno-trampolines' options currently have no effect, and trampolines are
  always generated on platforms that need them for nested functions.
  
   Define the following hook if your backend either implements
--- 37510,37524 ----
  mandated by the ABI or be otherwise handled in a target-specific way by
  the back end in its code generation strategy for indirect calls.  GCC
  also provides its own generic descriptor implementation to support the
! ‘-fno-trampolines’ option.  In this case runtime detection of function
  descriptors at indirect call sites relies on descriptor pointers being
  tagged with a bit that is never set in bare function addresses.  Since
  GCC's generic function descriptors are not ABI-compliant, this option is
  typically used only on a per-language basis (notably by Ada) or when it
  can otherwise be applied to the whole program.
  
!  For languages other than Ada, the ‘-ftrampolines’ and
! ‘-fno-trampolines’ options currently have no effect, and trampolines are
  always generated on platforms that need them for nested functions.
  
   Define the following hook if your backend either implements
*************** may be necessary to take out pieces of t
*** 37569,37575 ****
  separately.
  
   -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F)
!      This hook is called by 'assemble_trampoline_template' to output, on
       the stream F, assembler code for a block of data that contains the
       constant parts of a trampoline.  This code should not include a
       label--the label is taken care of automatically.
--- 37568,37574 ----
  separately.
  
   -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F)
!      This hook is called by ‘assemble_trampoline_template’ to output, on
       the stream F, assembler code for a block of data that contains the
       constant parts of a trampoline.  This code should not include a
       label--the label is taken care of automatically.
*************** separately.
*** 37582,37588 ****
   -- Macro: TRAMPOLINE_SECTION
       Return the section into which the trampoline template is to be
       placed (*note Sections::).  The default value is
!      'readonly_data_section'.
  
   -- Macro: TRAMPOLINE_SIZE
       A C expression for the size in bytes of the trampoline, as an
--- 37581,37587 ----
   -- Macro: TRAMPOLINE_SECTION
       Return the section into which the trampoline template is to be
       placed (*note Sections::).  The default value is
!      ‘readonly_data_section’.
  
   -- Macro: TRAMPOLINE_SIZE
       A C expression for the size in bytes of the trampoline, as an
*************** separately.
*** 37591,37613 ****
   -- Macro: TRAMPOLINE_ALIGNMENT
       Alignment required for trampolines, in bits.
  
!      If you don't define this macro, the value of 'FUNCTION_ALIGNMENT'
       is used for aligning trampolines.
  
   -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL,
            rtx STATIC_CHAIN)
       This hook is called to initialize a trampoline.  M_TRAMP is an RTX
       for the memory block for the trampoline; FNDECL is the
!      'FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX for
       the static chain value that should be passed to the function when
       it is called.
  
!      If the target defines 'TARGET_ASM_TRAMPOLINE_TEMPLATE', then the
       first thing this hook should do is emit a block move into M_TRAMP
!      from the memory block returned by 'assemble_trampoline_template'.
       Note that the block move need only cover the constant parts of the
       trampoline.  If the target isolates the variable parts of the
!      trampoline to the end, not all 'TRAMPOLINE_SIZE' bytes need be
       copied.
  
       If the target requires any other actions, such as flushing caches
--- 37590,37612 ----
   -- Macro: TRAMPOLINE_ALIGNMENT
       Alignment required for trampolines, in bits.
  
!      If you don't define this macro, the value of ‘FUNCTION_ALIGNMENT’
       is used for aligning trampolines.
  
   -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL,
            rtx STATIC_CHAIN)
       This hook is called to initialize a trampoline.  M_TRAMP is an RTX
       for the memory block for the trampoline; FNDECL is the
!      ‘FUNCTION_DECL’ for the nested function; STATIC_CHAIN is an RTX for
       the static chain value that should be passed to the function when
       it is called.
  
!      If the target defines ‘TARGET_ASM_TRAMPOLINE_TEMPLATE’, then the
       first thing this hook should do is emit a block move into M_TRAMP
!      from the memory block returned by ‘assemble_trampoline_template’.
       Note that the block move need only cover the constant parts of the
       trampoline.  If the target isolates the variable parts of the
!      trampoline to the end, not all ‘TRAMPOLINE_SIZE’ bytes need be
       copied.
  
       If the target requires any other actions, such as flushing caches
*************** separately.
*** 37617,37628 ****
  
   -- Target Hook: void TARGET_EMIT_CALL_BUILTIN___CLEAR_CACHE (rtx BEGIN,
            rtx END)
!      On targets that do not define a 'clear_cache' insn expander, but
!      that define the 'CLEAR_CACHE_INSN' macro,
       maybe_emit_call_builtin___clear_cache relies on this target hook to
       clear an address range in the instruction cache.
  
!      The default implementation calls the '__clear_cache' builtin,
       taking the assembler name from the builtin declaration.  Overriding
       definitions may call alternate functions, with alternate calling
       conventions, or emit alternate RTX to perform the job.
--- 37616,37627 ----
  
   -- Target Hook: void TARGET_EMIT_CALL_BUILTIN___CLEAR_CACHE (rtx BEGIN,
            rtx END)
!      On targets that do not define a ‘clear_cache’ insn expander, but
!      that define the ‘CLEAR_CACHE_INSN’ macro,
       maybe_emit_call_builtin___clear_cache relies on this target hook to
       clear an address range in the instruction cache.
  
!      The default implementation calls the ‘__clear_cache’ builtin,
       taking the assembler name from the builtin declaration.  Overriding
       definitions may call alternate functions, with alternate calling
       conventions, or emit alternate RTX to perform the job.
*************** separately.
*** 37630,37636 ****
   -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR)
       This hook should perform any machine-specific adjustment in the
       address of the trampoline.  Its argument contains the address of
!      the memory block that was passed to 'TARGET_TRAMPOLINE_INIT'.  In
       case the address to be used for a function call should be different
       from the address at which the template was stored, the different
       address should be returned; otherwise ADDR should be returned
--- 37629,37635 ----
   -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR)
       This hook should perform any machine-specific adjustment in the
       address of the trampoline.  Its argument contains the address of
!      the memory block that was passed to ‘TARGET_TRAMPOLINE_INIT’.  In
       case the address to be used for a function call should be different
       from the address at which the template was stored, the different
       address should be returned; otherwise ADDR should be returned
*************** the following macro.
*** 37654,37678 ****
   -- Macro: CLEAR_INSN_CACHE (BEG, END)
       If defined, expands to a C expression clearing the _instruction
       cache_ in the specified interval.  The definition of this macro
!      would typically be a series of 'asm' statements.  Both BEG and END
       are pointer expressions.
  
   To use a standard subroutine, define the following macro.  In addition,
  you must make sure that the instructions in a trampoline fill an entire
  cache line with identical instructions, or else ensure that the
  beginning of the trampoline code is always aligned at the same point in
! its cache line.  Look in 'm68k.h' as a guide.
  
   -- Macro: TRANSFER_FROM_TRAMPOLINE
       Define this macro if trampolines need a special subroutine to do
!      their work.  The macro should expand to a series of 'asm'
       statements which will be compiled with GCC.  They go in a library
!      function named '__transfer_from_trampoline'.
  
       If you need to avoid executing the ordinary prologue code of a
       compiled C function when you jump to the subroutine, you can do so
       by placing a special label of your own in the assembler code.  Use
!      one 'asm' statement to generate an assembler label, and another to
       make the label global.  Then trampolines can use that label to jump
       directly to your special assembler code.
  
--- 37653,37677 ----
   -- Macro: CLEAR_INSN_CACHE (BEG, END)
       If defined, expands to a C expression clearing the _instruction
       cache_ in the specified interval.  The definition of this macro
!      would typically be a series of ‘asm’ statements.  Both BEG and END
       are pointer expressions.
  
   To use a standard subroutine, define the following macro.  In addition,
  you must make sure that the instructions in a trampoline fill an entire
  cache line with identical instructions, or else ensure that the
  beginning of the trampoline code is always aligned at the same point in
! its cache line.  Look in ‘m68k.h’ as a guide.
  
   -- Macro: TRANSFER_FROM_TRAMPOLINE
       Define this macro if trampolines need a special subroutine to do
!      their work.  The macro should expand to a series of ‘asm’
       statements which will be compiled with GCC.  They go in a library
!      function named ‘__transfer_from_trampoline’.
  
       If you need to avoid executing the ordinary prologue code of a
       compiled C function when you jump to the subroutine, you can do so
       by placing a special label of your own in the assembler code.  Use
!      one ‘asm’ statement to generate an assembler label, and another to
       make the label global.  Then trampolines can use that label to jump
       directly to your special assembler code.
  
*************** Here is an explanation of implicit calls
*** 37693,37700 ****
  
   -- Target Hook: void TARGET_INIT_LIBFUNCS (void)
       This hook should declare additional library routines or rename
!      existing ones, using the functions 'set_optab_libfunc' and
!      'init_one_libfunc' defined in 'optabs.cc'.  'init_optabs' calls
       this macro after initializing all the normal library routines.
  
       The default is to do nothing.  Most ports don't need to define this
--- 37692,37699 ----
  
   -- Target Hook: void TARGET_INIT_LIBFUNCS (void)
       This hook should declare additional library routines or rename
!      existing ones, using the functions ‘set_optab_libfunc’ and
!      ‘init_one_libfunc’ defined in ‘optabs.cc’.  ‘init_optabs’ calls
       this macro after initializing all the normal library routines.
  
       The default is to do nothing.  Most ports don't need to define this
*************** Here is an explanation of implicit calls
*** 37702,37715 ****
  
   -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX
       If false (the default), internal library routines start with two
!      underscores.  If set to true, these routines start with '__gnu_'
!      instead.  E.g., '__muldi3' changes to '__gnu_muldi3'.  This
!      currently only affects functions defined in 'libgcc2.c'.  If this
!      is set to true, the 'tm.h' file must also '#define
!      LIBGCC2_GNU_PREFIX'.
  
   -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON)
!      This macro should return 'true' if the library routine that
       implements the floating point comparison operator COMPARISON in
       mode MODE will return a boolean, and FALSE if it will return a
       tristate.
--- 37701,37714 ----
  
   -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX
       If false (the default), internal library routines start with two
!      underscores.  If set to true, these routines start with ‘__gnu_’
!      instead.  E.g., ‘__muldi3’ changes to ‘__gnu_muldi3’.  This
!      currently only affects functions defined in ‘libgcc2.c’.  If this
!      is set to true, the ‘tm.h’ file must also ‘#define
!      LIBGCC2_GNU_PREFIX’.
  
   -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON)
!      This macro should return ‘true’ if the library routine that
       implements the floating point comparison operator COMPARISON in
       mode MODE will return a boolean, and FALSE if it will return a
       tristate.
*************** Here is an explanation of implicit calls
*** 37719,37731 ****
       ports don't need to define this macro.
  
   -- Macro: TARGET_LIB_INT_CMP_BIASED
!      This macro should evaluate to 'true' if the integer comparison
!      functions (like '__cmpdi2') return 0 to indicate that the first
       operand is smaller than the second, 1 to indicate that they are
       equal, and 2 to indicate that the first operand is greater than the
!      second.  If this macro evaluates to 'false' the comparison
!      functions return -1, 0, and 1 instead of 0, 1, and 2.  If the
!      target uses the routines in 'libgcc.a', you do not need to define
       this macro.
  
   -- Macro: TARGET_HAS_NO_HW_DIVIDE
--- 37718,37730 ----
       ports don't need to define this macro.
  
   -- Macro: TARGET_LIB_INT_CMP_BIASED
!      This macro should evaluate to ‘true’ if the integer comparison
!      functions (like ‘__cmpdi2’) return 0 to indicate that the first
       operand is smaller than the second, 1 to indicate that they are
       equal, and 2 to indicate that the first operand is greater than the
!      second.  If this macro evaluates to ‘false’ the comparison
!      functions return −1, 0, and 1 instead of 0, 1, and 2.  If the
!      target uses the routines in ‘libgcc.a’, you do not need to define
       this macro.
  
   -- Macro: TARGET_HAS_NO_HW_DIVIDE
*************** Here is an explanation of implicit calls
*** 37736,37756 ****
       algorithm which make use of a 64-bit by 32-bit divide primitive.
  
   -- Macro: TARGET_EDOM
!      The value of 'EDOM' on the target machine, as a C integer constant
       expression.  If you don't define this macro, GCC does not attempt
!      to deposit the value of 'EDOM' into 'errno' directly.  Look in
!      '/usr/include/errno.h' to find the value of 'EDOM' on your system.
  
!      If you do not define 'TARGET_EDOM', then compiled code reports
       domain errors by calling the library function and letting it report
!      the error.  If mathematical functions on your system use 'matherr'
!      when there is an error, then you should leave 'TARGET_EDOM'
!      undefined so that 'matherr' is used normally.
  
   -- Macro: GEN_ERRNO_RTX
       Define this macro as a C expression to create an rtl expression
!      that refers to the global "variable" 'errno'.  (On certain systems,
!      'errno' may not actually be a variable.)  If you don't define this
       macro, a reasonable default is used.
  
   -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class
--- 37735,37755 ----
       algorithm which make use of a 64-bit by 32-bit divide primitive.
  
   -- Macro: TARGET_EDOM
!      The value of ‘EDOM’ on the target machine, as a C integer constant
       expression.  If you don't define this macro, GCC does not attempt
!      to deposit the value of ‘EDOM’ into ‘errno’ directly.  Look in
!      ‘/usr/include/errno.h’ to find the value of ‘EDOM’ on your system.
  
!      If you do not define ‘TARGET_EDOM’, then compiled code reports
       domain errors by calling the library function and letting it report
!      the error.  If mathematical functions on your system use ‘matherr’
!      when there is an error, then you should leave ‘TARGET_EDOM’
!      undefined so that ‘matherr’ is used normally.
  
   -- Macro: GEN_ERRNO_RTX
       Define this macro as a C expression to create an rtl expression
!      that refers to the global "variable" ‘errno’.  (On certain systems,
!      ‘errno’ may not actually be a variable.)  If you don't define this
       macro, a reasonable default is used.
  
   -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class
*************** Here is an explanation of implicit calls
*** 37763,37769 ****
  
   -- Target Hook: bool TARGET_LIBC_HAS_FAST_FUNCTION (int FCODE)
       This hook determines whether a function from a class of functions
!      '(enum function_class)'FCODE has a fast implementation.
  
   -- Macro: NEXT_OBJC_RUNTIME
       Set this macro to 1 to use the "NeXT" Objective-C message sending
--- 37762,37768 ----
  
   -- Target Hook: bool TARGET_LIBC_HAS_FAST_FUNCTION (int FCODE)
       This hook determines whether a function from a class of functions
!      ‘(enum function_class)’FCODE has a fast implementation.
  
   -- Macro: NEXT_OBJC_RUNTIME
       Set this macro to 1 to use the "NeXT" Objective-C message sending
*************** This is about addressing modes.
*** 37812,37832 ****
   -- Macro: CONSTANT_ADDRESS_P (X)
       A C expression that is 1 if the RTX X is a constant which is a
       valid address.  On most machines the default definition of
!      '(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable,
       but a few machines are more restrictive as to which constant
       addresses are supported.
  
   -- Macro: CONSTANT_P (X)
!      'CONSTANT_P', which is defined by target-independent code, accepts
       integer-values expressions whose values are not explicitly known,
!      such as 'symbol_ref', 'label_ref', and 'high' expressions and
!      'const' arithmetic expressions, in addition to 'const_int' and
!      'const_double' expressions.
  
   -- Macro: MAX_REGS_PER_ADDRESS
       A number, the maximum number of registers that can appear in a
       valid memory address.  Note that it is up to you to specify a value
!      equal to the maximum number that 'TARGET_LEGITIMATE_ADDRESS_P'
       would ever accept.
  
   -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode MODE,
--- 37811,37831 ----
   -- Macro: CONSTANT_ADDRESS_P (X)
       A C expression that is 1 if the RTX X is a constant which is a
       valid address.  On most machines the default definition of
!      ‘(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)’ is acceptable,
       but a few machines are more restrictive as to which constant
       addresses are supported.
  
   -- Macro: CONSTANT_P (X)
!      ‘CONSTANT_P’, which is defined by target-independent code, accepts
       integer-values expressions whose values are not explicitly known,
!      such as ‘symbol_ref’, ‘label_ref’, and ‘high’ expressions and
!      ‘const’ arithmetic expressions, in addition to ‘const_int’ and
!      ‘const_double’ expressions.
  
   -- Macro: MAX_REGS_PER_ADDRESS
       A number, the maximum number of registers that can appear in a
       valid memory address.  Note that it is up to you to specify a value
!      equal to the maximum number that ‘TARGET_LEGITIMATE_ADDRESS_P’
       would ever accept.
  
   -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (machine_mode MODE,
*************** This is about addressing modes.
*** 37843,37908 ****
       register is considered a memory reference.  This is because in
       contexts where some kind of register is required, a pseudo-register
       with no hard register must be rejected.  For non-hard registers,
!      the strict variant should look up the 'reg_renumber' array; it
       should then proceed using the hard register number in the array, or
!      treat the pseudo as a memory reference if the array holds '-1'.
  
       The non-strict variant is used in other passes.  It must be defined
       to accept all pseudo-registers in every context where some kind of
       register is required.
  
!      Normally, constant addresses which are the sum of a 'symbol_ref'
!      and an integer are stored inside a 'const' RTX to mark them as
       constant.  Therefore, there is no need to recognize such sums
       specifically as legitimate addresses.  Normally you would simply
!      recognize any 'const' as legitimate.
  
!      Usually 'PRINT_OPERAND_ADDRESS' is not prepared to handle constant
!      sums that are not marked with 'const'.  It assumes that a naked
!      'plus' indicates indexing.  If so, then you _must_ reject such
       naked constant sums as illegitimate addresses, so that none of them
!      will be given to 'PRINT_OPERAND_ADDRESS'.
  
       On some machines, whether a symbolic address is legitimate depends
       on the section that the address refers to.  On these machines,
!      define the target hook 'TARGET_ENCODE_SECTION_INFO' to store the
!      information into the 'symbol_ref', and then check for it here.
!      When you see a 'const', you will have to look inside it to find the
!      'symbol_ref' in order to determine the section.  *Note Assembler
       Format::.
  
       Some ports are still using a deprecated legacy substitute for this
!      hook, the 'GO_IF_LEGITIMATE_ADDRESS' macro.  This macro has this
       syntax:
  
            #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)
  
!      and should 'goto LABEL' if the address X is a valid address on the
       target machine for a memory operand of mode MODE.
  
       Compiler source files that want to use the strict variant of this
!      macro define the macro 'REG_OK_STRICT'.  You should use an '#ifdef
!      REG_OK_STRICT' conditional to define the strict variant in that
       case and the non-strict variant otherwise.
  
       Using the hook is usually simpler because it limits the number of
       files that are recompiled when changes are made.
  
   -- Macro: TARGET_MEM_CONSTRAINT
!      A single character to be used instead of the default ''m''
       character for general memory addresses.  This defines the
       constraint letter which matches the memory addresses accepted by
!      'TARGET_LEGITIMATE_ADDRESS_P'.  Define this macro if you want to
       support new address formats in your back end without changing the
!      semantics of the ''m'' constraint.  This is necessary in order to
       preserve functionality of inline assembly constructs using the
!      ''m'' constraint.
  
   -- Macro: FIND_BASE_TERM (X)
       A C expression to determine the base term of address X, or to
!      provide a simplified version of X from which 'alias.cc' can easily
       find the base term.  This macro is used in only two places:
!      'find_base_value' and 'find_base_term' in 'alias.cc'.
  
       It is always safe for this macro to not be defined.  It exists so
       that alias analysis can understand machine-dependent addresses.
--- 37842,37907 ----
       register is considered a memory reference.  This is because in
       contexts where some kind of register is required, a pseudo-register
       with no hard register must be rejected.  For non-hard registers,
!      the strict variant should look up the ‘reg_renumber’ array; it
       should then proceed using the hard register number in the array, or
!      treat the pseudo as a memory reference if the array holds ‘-1’.
  
       The non-strict variant is used in other passes.  It must be defined
       to accept all pseudo-registers in every context where some kind of
       register is required.
  
!      Normally, constant addresses which are the sum of a ‘symbol_ref’
!      and an integer are stored inside a ‘const’ RTX to mark them as
       constant.  Therefore, there is no need to recognize such sums
       specifically as legitimate addresses.  Normally you would simply
!      recognize any ‘const’ as legitimate.
  
!      Usually ‘PRINT_OPERAND_ADDRESS’ is not prepared to handle constant
!      sums that are not marked with ‘const’.  It assumes that a naked
!      ‘plus’ indicates indexing.  If so, then you _must_ reject such
       naked constant sums as illegitimate addresses, so that none of them
!      will be given to ‘PRINT_OPERAND_ADDRESS’.
  
       On some machines, whether a symbolic address is legitimate depends
       on the section that the address refers to.  On these machines,
!      define the target hook ‘TARGET_ENCODE_SECTION_INFO’ to store the
!      information into the ‘symbol_ref’, and then check for it here.
!      When you see a ‘const’, you will have to look inside it to find the
!      ‘symbol_ref’ in order to determine the section.  *Note Assembler
       Format::.
  
       Some ports are still using a deprecated legacy substitute for this
!      hook, the ‘GO_IF_LEGITIMATE_ADDRESS’ macro.  This macro has this
       syntax:
  
            #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)
  
!      and should ‘goto LABEL’ if the address X is a valid address on the
       target machine for a memory operand of mode MODE.
  
       Compiler source files that want to use the strict variant of this
!      macro define the macro ‘REG_OK_STRICT’.  You should use an ‘#ifdef
!      REG_OK_STRICT’ conditional to define the strict variant in that
       case and the non-strict variant otherwise.
  
       Using the hook is usually simpler because it limits the number of
       files that are recompiled when changes are made.
  
   -- Macro: TARGET_MEM_CONSTRAINT
!      A single character to be used instead of the default ‘'m'’
       character for general memory addresses.  This defines the
       constraint letter which matches the memory addresses accepted by
!      ‘TARGET_LEGITIMATE_ADDRESS_P’.  Define this macro if you want to
       support new address formats in your back end without changing the
!      semantics of the ‘'m'’ constraint.  This is necessary in order to
       preserve functionality of inline assembly constructs using the
!      ‘'m'’ constraint.
  
   -- Macro: FIND_BASE_TERM (X)
       A C expression to determine the base term of address X, or to
!      provide a simplified version of X from which ‘alias.cc’ can easily
       find the base term.  This macro is used in only two places:
!      ‘find_base_value’ and ‘find_base_term’ in ‘alias.cc’.
  
       It is always safe for this macro to not be defined.  It exists so
       that alias analysis can understand machine-dependent addresses.
*************** This is about addressing modes.
*** 37915,37921 ****
       This hook is given an invalid memory address X for an operand of
       mode MODE and should try to return a valid memory address.
  
!      X will always be the result of a call to 'break_out_memory_refs',
       and OLDX will be the operand that was given to that function to
       produce X.
  
--- 37914,37920 ----
       This hook is given an invalid memory address X for an operand of
       mode MODE and should try to return a valid memory address.
  
!      X will always be the result of a call to ‘break_out_memory_refs’,
       and OLDX will be the operand that was given to that function to
       produce X.
  
*************** This is about addressing modes.
*** 37944,37950 ****
       registers into a register.  On the other hand, for number of RISC
       processors offsets are limited so that often an intermediate
       address needs to be generated in order to address a stack slot.  By
!      defining 'LEGITIMIZE_RELOAD_ADDRESS' appropriately, the
       intermediate addresses generated for adjacent some stack slots can
       be made identical, and thus be shared.
  
--- 37943,37949 ----
       registers into a register.  On the other hand, for number of RISC
       processors offsets are limited so that often an intermediate
       address needs to be generated in order to address a stack slot.  By
!      defining ‘LEGITIMIZE_RELOAD_ADDRESS’ appropriately, the
       intermediate addresses generated for adjacent some stack slots can
       be made identical, and thus be shared.
  
*************** This is about addressing modes.
*** 37957,37977 ****
       previous invocation of this macro.  If it fails to handle such
       addresses then the compiler may generate incorrect code or abort.
  
!      The macro definition should use 'push_reload' to indicate parts
       that need reloading; OPNUM, TYPE and IND_LEVELS are usually
!      suitable to be passed unaltered to 'push_reload'.
  
       The code generated by this macro must not alter the substructure of
       X.  If it transforms X into a more legitimate form, it should
       assign X (which will always be a C variable) a new value.  This
       also applies to parts that you change indirectly by calling
!      'push_reload'.
  
!      The macro definition may use 'strict_memory_address_p' to test if
       the address has become legitimate.
  
       If you want to change only a part of X, one standard way of doing
!      this is to use 'copy_rtx'.  Note, however, that it unshares only a
       single level of rtl.  Thus, if the part to be changed is not at the
       top level, you'll need to replace first the top level.  It is not
       necessary for this macro to come up with a legitimate address; but
--- 37956,37976 ----
       previous invocation of this macro.  If it fails to handle such
       addresses then the compiler may generate incorrect code or abort.
  
!      The macro definition should use ‘push_reload’ to indicate parts
       that need reloading; OPNUM, TYPE and IND_LEVELS are usually
!      suitable to be passed unaltered to ‘push_reload’.
  
       The code generated by this macro must not alter the substructure of
       X.  If it transforms X into a more legitimate form, it should
       assign X (which will always be a C variable) a new value.  This
       also applies to parts that you change indirectly by calling
!      ‘push_reload’.
  
!      The macro definition may use ‘strict_memory_address_p’ to test if
       the address has become legitimate.
  
       If you want to change only a part of X, one standard way of doing
!      this is to use ‘copy_rtx’.  Note, however, that it unshares only a
       single level of rtl.  Thus, if the part to be changed is not at the
       top level, you'll need to replace first the top level.  It is not
       necessary for this macro to come up with a legitimate address; but
*************** This is about addressing modes.
*** 37979,37985 ****
  
   -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR,
            addr_space_t ADDRSPACE)
!      This hook returns 'true' if memory address ADDR in address space
       ADDRSPACE can have different meanings depending on the machine mode
       of the memory reference it is used for or if the address is valid
       for some modes but not others.
--- 37978,37984 ----
  
   -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR,
            addr_space_t ADDRSPACE)
!      This hook returns ‘true’ if memory address ADDR in address space
       ADDRSPACE can have different meanings depending on the machine mode
       of the memory reference it is used for or if the address is valid
       for some modes but not others.
*************** This is about addressing modes.
*** 37992,38022 ****
  
       You may assume that ADDR is a valid address for the machine.
  
!      The default version of this hook returns 'false'.
  
   -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode MODE,
            rtx X)
       This hook returns true if X is a legitimate constant for a
       MODE-mode immediate operand on the target machine.  You can assume
!      that X satisfies 'CONSTANT_P', so you need not check this.
  
       The default definition returns true.
  
   -- Target Hook: bool TARGET_PRECOMPUTE_TLS_P (machine_mode MODE, rtx X)
       This hook returns true if X is a TLS operand on the target machine
       that should be pre-computed when used as the argument in a call.
!      You can assume that X satisfies 'CONSTANT_P', so you need not check
       this.
  
       The default definition returns false.
  
   -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X)
       This hook is used to undo the possibly obfuscating effects of the
!      'LEGITIMIZE_ADDRESS' and 'LEGITIMIZE_RELOAD_ADDRESS' target macros.
       Some backend implementations of these macros wrap symbol references
!      inside an 'UNSPEC' rtx to represent PIC or similar addressing
       modes.  This target hook allows GCC's optimizers to understand the
!      semantics of these opaque 'UNSPEC's by converting them back into
       their original form.
  
   -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X)
--- 37991,38021 ----
  
       You may assume that ADDR is a valid address for the machine.
  
!      The default version of this hook returns ‘false’.
  
   -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (machine_mode MODE,
            rtx X)
       This hook returns true if X is a legitimate constant for a
       MODE-mode immediate operand on the target machine.  You can assume
!      that X satisfies ‘CONSTANT_P’, so you need not check this.
  
       The default definition returns true.
  
   -- Target Hook: bool TARGET_PRECOMPUTE_TLS_P (machine_mode MODE, rtx X)
       This hook returns true if X is a TLS operand on the target machine
       that should be pre-computed when used as the argument in a call.
!      You can assume that X satisfies ‘CONSTANT_P’, so you need not check
       this.
  
       The default definition returns false.
  
   -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X)
       This hook is used to undo the possibly obfuscating effects of the
!      ‘LEGITIMIZE_ADDRESS’ and ‘LEGITIMIZE_RELOAD_ADDRESS’ target macros.
       Some backend implementations of these macros wrap symbol references
!      inside an ‘UNSPEC’ rtx to represent PIC or similar addressing
       modes.  This target hook allows GCC's optimizers to understand the
!      semantics of these opaque ‘UNSPEC’s by converting them back into
       their original form.
  
   -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X)
*************** This is about addressing modes.
*** 38040,38059 ****
   -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode
            MODE, const_rtx X)
       This hook should return true if pool entries for constant X can be
!      placed in an 'object_block' structure.  MODE is the mode of X.
  
       The default version returns false for all constants.
  
   -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL)
       This hook should return true if pool entries for DECL should be
!      placed in an 'object_block' structure.
  
       The default version returns true for all decls.
  
   -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (tree FNDECL)
       This hook should return the DECL of a function that implements the
       reciprocal of the machine-specific builtin function FNDECL, or
!      'NULL_TREE' if such a function is not available.
  
   -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void)
       This hook should return the DECL of a function F that given an
--- 38039,38058 ----
   -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (machine_mode
            MODE, const_rtx X)
       This hook should return true if pool entries for constant X can be
!      placed in an ‘object_block’ structure.  MODE is the mode of X.
  
       The default version returns false for all constants.
  
   -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL)
       This hook should return true if pool entries for DECL should be
!      placed in an ‘object_block’ structure.
  
       The default version returns true for all decls.
  
   -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (tree FNDECL)
       This hook should return the DECL of a function that implements the
       reciprocal of the machine-specific builtin function FNDECL, or
!      ‘NULL_TREE’ if such a function is not available.
  
   -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void)
       This hook should return the DECL of a function F that given an
*************** This is about addressing modes.
*** 38064,38071 ****
       The autovectorizer, when vectorizing a load operation from an
       address ADDR that may be unaligned, will generate two vector loads
       from the two aligned addresses around ADDR.  It then generates a
!      'REALIGN_LOAD' operation to extract the relevant data from the two
!      loaded vectors.  The first two arguments to 'REALIGN_LOAD', V1 and
       V2, are the two vectors, each of size VS, and the third argument,
       OFF, defines how the data will be extracted from these two vectors:
       if OFF is 0, then the returned vector is V2; otherwise, the
--- 38063,38070 ----
       The autovectorizer, when vectorizing a load operation from an
       address ADDR that may be unaligned, will generate two vector loads
       from the two aligned addresses around ADDR.  It then generates a
!      ‘REALIGN_LOAD’ operation to extract the relevant data from the two
!      loaded vectors.  The first two arguments to ‘REALIGN_LOAD’, V1 and
       V2, are the two vectors, each of size VS, and the third argument,
       OFF, defines how the data will be extracted from these two vectors:
       if OFF is 0, then the returned vector is V2; otherwise, the
*************** This is about addressing modes.
*** 38074,38084 ****
  
       If this hook is defined, the autovectorizer will generate a call to
       F (using the DECL tree that this hook returns) and will use the
!      return value of F as the argument OFF to 'REALIGN_LOAD'.
       Therefore, the mask M returned by F should comply with the
!      semantics expected by 'REALIGN_LOAD' described above.  If this hook
       is not defined, then ADDR will be used as the argument OFF to
!      'REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR
       will be considered.
  
   -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum
--- 38073,38083 ----
  
       If this hook is defined, the autovectorizer will generate a call to
       F (using the DECL tree that this hook returns) and will use the
!      return value of F as the argument OFF to ‘REALIGN_LOAD’.
       Therefore, the mask M returned by F should comply with the
!      semantics expected by ‘REALIGN_LOAD’ described above.  If this hook
       is not defined, then ADDR will be used as the argument OFF to
!      ‘REALIGN_LOAD’, in which case the low log2(VS) − 1 bits of ADDR
       will be considered.
  
   -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum
*************** This is about addressing modes.
*** 38092,38102 ****
       This hook returns the preferred alignment in bits for accesses to
       vectors of type TYPE in vectorized code.  This might be less than
       or greater than the ABI-defined value returned by
!      'TARGET_VECTOR_ALIGNMENT'.  It can be equal to the alignment of a
       single element, in which case the vectorizer will not try to
       optimize for alignment.
  
!      The default hook returns 'TYPE_ALIGN (TYPE)', which is correct for
       most targets.
  
   -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE
--- 38091,38101 ----
       This hook returns the preferred alignment in bits for accesses to
       vectors of type TYPE in vectorized code.  This might be less than
       or greater than the ABI-defined value returned by
!      ‘TARGET_VECTOR_ALIGNMENT’.  It can be equal to the alignment of a
       single element, in which case the vectorizer will not try to
       optimize for alignment.
  
!      The default hook returns ‘TYPE_ALIGN (TYPE)’, which is correct for
       most targets.
  
   -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE
*************** This is about addressing modes.
*** 38109,38115 ****
            MODE, machine_mode OP_MODE, rtx OUTPUT, rtx IN0, rtx IN1,
            const vec_perm_indices &SEL)
       This hook is used to test whether the target can permute up to two
!      vectors of mode OP_MODE using the permutation vector 'sel',
       producing a vector of mode MODE.  The hook is also used to emit
       such a permutation.
  
--- 38108,38114 ----
            MODE, machine_mode OP_MODE, rtx OUTPUT, rtx IN0, rtx IN1,
            const vec_perm_indices &SEL)
       This hook is used to test whether the target can permute up to two
!      vectors of mode OP_MODE using the permutation vector ‘sel’,
       producing a vector of mode MODE.  The hook is also used to emit
       such a permutation.
  
*************** This is about addressing modes.
*** 38135,38155 ****
       sequence of two addition-shift pairs, giving four instructions in
       total.  Return true if taking this approach for VECTYPE is likely
       to be better than using a sequence involving highpart
!      multiplication.  Default is false if 'can_mult_highpart_p',
       otherwise true.
  
   -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
            (unsigned CODE, tree VEC_TYPE_OUT, tree VEC_TYPE_IN)
       This hook should return the decl of a function that implements the
!      vectorized variant of the function with the 'combined_fn' code CODE
!      or 'NULL_TREE' if such a function is not available.  The return
       type of the vectorized function shall be of vector type
       VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN.
  
   -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION
            (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN)
       This hook should return the decl of a function that implements the
!      vectorized variant of target built-in function 'fndecl'.  The
       return type of the vectorized function shall be of vector type
       VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN.
  
--- 38134,38154 ----
       sequence of two addition-shift pairs, giving four instructions in
       total.  Return true if taking this approach for VECTYPE is likely
       to be better than using a sequence involving highpart
!      multiplication.  Default is false if ‘can_mult_highpart_p’,
       otherwise true.
  
   -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION
            (unsigned CODE, tree VEC_TYPE_OUT, tree VEC_TYPE_IN)
       This hook should return the decl of a function that implements the
!      vectorized variant of the function with the ‘combined_fn’ code CODE
!      or ‘NULL_TREE’ if such a function is not available.  The return
       type of the vectorized function shall be of vector type
       VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN.
  
   -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MD_VECTORIZED_FUNCTION
            (tree FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN)
       This hook should return the decl of a function that implements the
!      vectorized variant of target built-in function ‘fndecl’.  The
       return type of the vectorized function shall be of vector type
       VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN.
  
*************** This is about addressing modes.
*** 38166,38172 ****
   -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE
            (scalar_mode MODE)
       This hook should return the preferred mode for vectorizing scalar
!      mode MODE.  The default is equal to 'word_mode', because the
       vectorizer can do some transformations even in absence of
       specialized SIMD hardware.
  
--- 38165,38171 ----
   -- Target Hook: machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE
            (scalar_mode MODE)
       This hook should return the preferred mode for vectorizing scalar
!      mode MODE.  The default is equal to ‘word_mode’, because the
       vectorizer can do some transformations even in absence of
       specialized SIMD hardware.
  
*************** This is about addressing modes.
*** 38182,38211 ****
            TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES (vector_modes
            *MODES, bool ALL)
       If using the mode returned by
!      'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is not the only approach
       worth considering, this hook should add one mode to MODES for each
       useful alternative approach.  These modes are then passed to
!      'TARGET_VECTORIZE_RELATED_MODE' to obtain the vector mode for a
       given element mode.
  
       The modes returned in MODES should use the smallest element mode
       possible for the vectorization approach that they represent,
       preferring integer modes over floating-poing modes in the event of
       a tie.  The first mode should be the
!      'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' for its element mode.
  
       If ALL is true, add suitable vector modes even when they are
       generally not expected to be worthwhile.
  
       The hook returns a bitmask of flags that control how the modes in
       MODES are used.  The flags are:
!      'VECT_COMPARE_COSTS'
            Tells the loop vectorizer to try all the provided modes and
            pick the one with the lowest cost.  By default the vectorizer
            will choose the first mode that works.
  
       The hook does not need to do anything if the vector returned by
!      'TARGET_VECTORIZE_PREFERRED_SIMD_MODE' is the only one relevant for
       autovectorization.  The default implementation adds no modes and
       returns 0.
  
--- 38181,38210 ----
            TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES (vector_modes
            *MODES, bool ALL)
       If using the mode returned by
!      ‘TARGET_VECTORIZE_PREFERRED_SIMD_MODE’ is not the only approach
       worth considering, this hook should add one mode to MODES for each
       useful alternative approach.  These modes are then passed to
!      ‘TARGET_VECTORIZE_RELATED_MODE’ to obtain the vector mode for a
       given element mode.
  
       The modes returned in MODES should use the smallest element mode
       possible for the vectorization approach that they represent,
       preferring integer modes over floating-poing modes in the event of
       a tie.  The first mode should be the
!      ‘TARGET_VECTORIZE_PREFERRED_SIMD_MODE’ for its element mode.
  
       If ALL is true, add suitable vector modes even when they are
       generally not expected to be worthwhile.
  
       The hook returns a bitmask of flags that control how the modes in
       MODES are used.  The flags are:
!      ‘VECT_COMPARE_COSTS’
            Tells the loop vectorizer to try all the provided modes and
            pick the one with the lowest cost.  By default the vectorizer
            will choose the first mode that works.
  
       The hook does not need to do anything if the vector returned by
!      ‘TARGET_VECTORIZE_PREFERRED_SIMD_MODE’ is the only one relevant for
       autovectorization.  The default implementation adds no modes and
       returns 0.
  
*************** This is about addressing modes.
*** 38217,38223 ****
       it should use for those elements.  If NUNITS is nonzero, ensure
       that the mode has exactly NUNITS elements, otherwise pick whichever
       vector size pairs the most naturally with VECTOR_MODE.  Return an
!      empty 'opt_machine_mode' if there is no supported vector mode with
       the required properties.
  
       There is no prescribed way of handling the case in which NUNITS is
--- 38216,38222 ----
       it should use for those elements.  If NUNITS is nonzero, ensure
       that the mode has exactly NUNITS elements, otherwise pick whichever
       vector size pairs the most naturally with VECTOR_MODE.  Return an
!      empty ‘opt_machine_mode’ if there is no supported vector mode with
       the required properties.
  
       There is no prescribed way of handling the case in which NUNITS is
*************** This is about addressing modes.
*** 38230,38236 ****
       trying to keep the number of elements as similar as possible while
       applying maximum and minimum vector sizes.
  
!      The default implementation uses 'mode_for_vector' to find the
       requested mode, returning a mode with the same size as VECTOR_MODE
       when NUNITS is zero.  This is the correct behavior for most
       targets.
--- 38229,38235 ----
       trying to keep the number of elements as similar as possible while
       applying maximum and minimum vector sizes.
  
!      The default implementation uses ‘mode_for_vector’ to find the
       requested mode, returning a mode with the same size as VECTOR_MODE
       when NUNITS is zero.  This is the correct behavior for most
       targets.
*************** This is about addressing modes.
*** 38239,38256 ****
            (machine_mode MODE)
       Return the mode to use for a vector mask that holds one boolean
       result for each element of vector mode MODE.  The returned mask
!      mode can be a vector of integers (class 'MODE_VECTOR_INT'), a
!      vector of booleans (class 'MODE_VECTOR_BOOL') or a scalar integer
!      (class 'MODE_INT').  Return an empty 'opt_machine_mode' if no such
       mask mode exists.
  
!      The default implementation returns a 'MODE_VECTOR_INT' with the
       same size and number of elements as MODE, if such a mode exists.
  
   -- Target Hook: bool TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE (unsigned
            IFN)
       This hook returns true if masked internal function IFN (really of
!      type 'internal_fn') should be considered expensive when the mask is
       all zeros.  GCC can then try to branch around the instruction
       instead.
  
--- 38238,38255 ----
            (machine_mode MODE)
       Return the mode to use for a vector mask that holds one boolean
       result for each element of vector mode MODE.  The returned mask
!      mode can be a vector of integers (class ‘MODE_VECTOR_INT’), a
!      vector of booleans (class ‘MODE_VECTOR_BOOL’) or a scalar integer
!      (class ‘MODE_INT’).  Return an empty ‘opt_machine_mode’ if no such
       mask mode exists.
  
!      The default implementation returns a ‘MODE_VECTOR_INT’ with the
       same size and number of elements as MODE, if such a mode exists.
  
   -- Target Hook: bool TARGET_VECTORIZE_EMPTY_MASK_IS_EXPENSIVE (unsigned
            IFN)
       This hook returns true if masked internal function IFN (really of
!      type ‘internal_fn’) should be considered expensive when the mask is
       all zeros.  GCC can then try to branch around the instruction
       instead.
  
*************** This is about addressing modes.
*** 38270,38283 ****
            MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE)
       Target builtin that implements vector gather operation.
       MEM_VECTYPE is the vector type of the load and INDEX_TYPE is scalar
!      type of the index, scaled by SCALE.  The default is 'NULL_TREE'
       which means to not vectorize gather loads.
  
   -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_SCATTER (const_tree
            VECTYPE, const_tree INDEX_TYPE, int SCALE)
       Target builtin that implements vector scatter operation.  VECTYPE
       is the vector type of the store and INDEX_TYPE is scalar type of
!      the index, scaled by SCALE.  The default is 'NULL_TREE' which means
       to not vectorize scatter stores.
  
   -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN
--- 38269,38282 ----
            MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE)
       Target builtin that implements vector gather operation.
       MEM_VECTYPE is the vector type of the load and INDEX_TYPE is scalar
!      type of the index, scaled by SCALE.  The default is ‘NULL_TREE’
       which means to not vectorize gather loads.
  
   -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_SCATTER (const_tree
            VECTYPE, const_tree INDEX_TYPE, int SCALE)
       Target builtin that implements vector scatter operation.  VECTYPE
       is the vector type of the store and INDEX_TYPE is scalar type of
!      the index, scaled by SCALE.  The default is ‘NULL_TREE’ which means
       to not vectorize scatter stores.
  
   -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN
*************** This is about addressing modes.
*** 38293,38299 ****
       VECSIZE_MANGLE variants that should be emitted.
  
   -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *)
!      This hook should add implicit 'attribute(target("..."))' attribute
       to SIMD clone NODE if needed.
  
   -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *)
--- 38292,38298 ----
       VECSIZE_MANGLE variants that should be emitted.
  
   -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *)
!      This hook should add implicit ‘attribute(target("..."))’ attribute
       to SIMD clone NODE if needed.
  
   -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *)
*************** This is about addressing modes.
*** 38353,38396 ****
            TYPE, unsigned NOPS, tree *OPS)
       This hook returns the target's preferred final argument for a call
       to conditional internal function IFN (really of type
!      'internal_fn').  TYPE specifies the return type of the function and
       OPS are the operands to the conditional operation, of which there
       are NOPS.
  
!      For example, if IFN is 'IFN_COND_ADD', the hook returns a value of
!      type TYPE that should be used when 'OPS[0]' and 'OPS[1]' are
       conditionally added together.
  
       This hook is only relevant if the target supports conditional
!      patterns like 'cond_addM'.  The default implementation returns a
       zero constant of type TYPE.
  
   -- Target Hook: tree TARGET_GOACC_ADJUST_PRIVATE_DECL (location_t LOC,
            tree VAR, int LEVEL)
       This hook, if defined, is used by accelerator target back-ends to
       adjust OpenACC variable declarations that should be made private to
!      the given parallelism level (i.e.  'GOMP_DIM_GANG',
!      'GOMP_DIM_WORKER' or 'GOMP_DIM_VECTOR').  A typical use for this
!      hook is to force variable declarations at the 'gang' level to
       reside in GPU shared memory.  LOC may be used for diagnostic
       purposes.
  
!      You may also use the 'TARGET_GOACC_EXPAND_VAR_DECL' hook if the
       adjusted variable declaration needs to be expanded to RTL in a
       non-standard way.
  
   -- Target Hook: rtx TARGET_GOACC_EXPAND_VAR_DECL (tree VAR)
       This hook, if defined, is used by accelerator target back-ends to
!      expand specially handled kinds of 'VAR_DECL' expressions.  A
       particular use is to place variables with specific attributes
!      inside special accelarator memories.  A return value of 'NULL'
!      indicates that the target does not handle this 'VAR_DECL', and
       normal RTL expanding is resumed.
  
       Only define this hook if your accelerator target needs to expand
!      certain 'VAR_DECL' nodes in a way that differs from the default.
       You can also adjust private variables at OpenACC device-lowering
!      time using the 'TARGET_GOACC_ADJUST_PRIVATE_DECL' target hook.
  
   -- Target Hook: tree TARGET_GOACC_CREATE_WORKER_BROADCAST_RECORD (tree
            REC, bool SENDER, const char *NAME, unsigned HOST_WIDE_INT
--- 38352,38395 ----
            TYPE, unsigned NOPS, tree *OPS)
       This hook returns the target's preferred final argument for a call
       to conditional internal function IFN (really of type
!      ‘internal_fn’).  TYPE specifies the return type of the function and
       OPS are the operands to the conditional operation, of which there
       are NOPS.
  
!      For example, if IFN is ‘IFN_COND_ADD’, the hook returns a value of
!      type TYPE that should be used when ‘OPS[0]’ and ‘OPS[1]’ are
       conditionally added together.
  
       This hook is only relevant if the target supports conditional
!      patterns like ‘cond_addM’.  The default implementation returns a
       zero constant of type TYPE.
  
   -- Target Hook: tree TARGET_GOACC_ADJUST_PRIVATE_DECL (location_t LOC,
            tree VAR, int LEVEL)
       This hook, if defined, is used by accelerator target back-ends to
       adjust OpenACC variable declarations that should be made private to
!      the given parallelism level (i.e.  ‘GOMP_DIM_GANG’,
!      ‘GOMP_DIM_WORKER’ or ‘GOMP_DIM_VECTOR’).  A typical use for this
!      hook is to force variable declarations at the ‘gang’ level to
       reside in GPU shared memory.  LOC may be used for diagnostic
       purposes.
  
!      You may also use the ‘TARGET_GOACC_EXPAND_VAR_DECL’ hook if the
       adjusted variable declaration needs to be expanded to RTL in a
       non-standard way.
  
   -- Target Hook: rtx TARGET_GOACC_EXPAND_VAR_DECL (tree VAR)
       This hook, if defined, is used by accelerator target back-ends to
!      expand specially handled kinds of ‘VAR_DECL’ expressions.  A
       particular use is to place variables with specific attributes
!      inside special accelarator memories.  A return value of ‘NULL’
!      indicates that the target does not handle this ‘VAR_DECL’, and
       normal RTL expanding is resumed.
  
       Only define this hook if your accelerator target needs to expand
!      certain ‘VAR_DECL’ nodes in a way that differs from the default.
       You can also adjust private variables at OpenACC device-lowering
!      time using the ‘TARGET_GOACC_ADJUST_PRIVATE_DECL’ target hook.
  
   -- Target Hook: tree TARGET_GOACC_CREATE_WORKER_BROADCAST_RECORD (tree
            REC, bool SENDER, const char *NAME, unsigned HOST_WIDE_INT
*************** example, if we have:
*** 38423,38430 ****
       static int a, b, c;
       int foo (void) { return a + b + c; }
  
!  the code for 'foo' will usually calculate three separate symbolic
! addresses: those of 'a', 'b' and 'c'.  On some targets, it would be
  better to calculate just one symbolic address and access the three
  variables relative to it.  The equivalent pseudocode would be something
  like:
--- 38422,38429 ----
       static int a, b, c;
       int foo (void) { return a + b + c; }
  
!  the code for ‘foo’ will usually calculate three separate symbolic
! addresses: those of ‘a’, ‘b’ and ‘c’.  On some targets, it would be
  better to calculate just one symbolic address and access the three
  variables relative to it.  The equivalent pseudocode would be something
  like:
*************** like:
*** 38435,38447 ****
         return xr[&a - &x] + xr[&b - &x] + xr[&c - &x];
       }
  
!  (which isn't valid C). We refer to shared addresses like 'x' as
! "section anchors".  Their use is controlled by '-fsection-anchors'.
  
   The hooks below describe the target properties that GCC needs to know
  in order to make effective use of section anchors.  It won't use section
! anchors at all unless either 'TARGET_MIN_ANCHOR_OFFSET' or
! 'TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value.
  
   -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET
       The minimum offset that should be applied to a section anchor.  On
--- 38434,38446 ----
         return xr[&a - &x] + xr[&b - &x] + xr[&c - &x];
       }
  
!  (which isn't valid C). We refer to shared addresses like ‘x’ as
! "section anchors".  Their use is controlled by ‘-fsection-anchors’.
  
   The hooks below describe the target properties that GCC needs to know
  in order to make effective use of section anchors.  It won't use section
! anchors at all unless either ‘TARGET_MIN_ANCHOR_OFFSET’ or
! ‘TARGET_MAX_ANCHOR_OFFSET’ is set to a nonzero value.
  
   -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET
       The minimum offset that should be applied to a section anchor.  On
*************** anchors at all unless either 'TARGET_MIN
*** 38450,38473 ****
       every mode.  The default value is 0.
  
   -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET
!      Like 'TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) offset
       that should be applied to section anchors.  The default value is 0.
  
   -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X)
       Write the assembly code to define section anchor X, which is a
!      'SYMBOL_REF' for which 'SYMBOL_REF_ANCHOR_P (X)' is true.  The hook
       is called with the assembly output position set to the beginning of
!      'SYMBOL_REF_BLOCK (X)'.
  
!      If 'ASM_OUTPUT_DEF' is available, the hook's default definition
!      uses it to define the symbol as '. + SYMBOL_REF_BLOCK_OFFSET (X)'.
!      If 'ASM_OUTPUT_DEF' is not available, the hook's default definition
!      is 'NULL', which disables the use of section anchors altogether.
  
   -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X)
       Return true if GCC should attempt to use anchors to access
!      'SYMBOL_REF' X.  You can assume 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)'
!      and '!SYMBOL_REF_ANCHOR_P (X)'.
  
       The default version is correct for most targets, but you might need
       to intercept this hook to handle things like target-specific
--- 38449,38472 ----
       every mode.  The default value is 0.
  
   -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET
!      Like ‘TARGET_MIN_ANCHOR_OFFSET’, but the maximum (inclusive) offset
       that should be applied to section anchors.  The default value is 0.
  
   -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X)
       Write the assembly code to define section anchor X, which is a
!      ‘SYMBOL_REF’ for which ‘SYMBOL_REF_ANCHOR_P (X)’ is true.  The hook
       is called with the assembly output position set to the beginning of
!      ‘SYMBOL_REF_BLOCK (X)’.
  
!      If ‘ASM_OUTPUT_DEF’ is available, the hook's default definition
!      uses it to define the symbol as ‘. + SYMBOL_REF_BLOCK_OFFSET (X)’.
!      If ‘ASM_OUTPUT_DEF’ is not available, the hook's default definition
!      is ‘NULL’, which disables the use of section anchors altogether.
  
   -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X)
       Return true if GCC should attempt to use anchors to access
!      ‘SYMBOL_REF’ X.  You can assume ‘SYMBOL_REF_HAS_BLOCK_INFO_P (X)’
!      and ‘!SYMBOL_REF_ANCHOR_P (X)’.
  
       The default version is correct for most targets, but you might need
       to intercept this hook to handle things like target-specific
*************** category includes most RISC machines.
*** 38488,38494 ****
  the definition and use of the condition code.  In the past the
  definition and use were always adjacent.  However, recent changes to
  support trapping arithmetic may result in the definition and user being
! in different blocks.  Thus, there may be a 'NOTE_INSN_BASIC_BLOCK'
  between them.  Additionally, the definition may be the source of
  exception handling edges.
  
--- 38487,38493 ----
  the definition and use of the condition code.  In the past the
  definition and use were always adjacent.  However, recent changes to
  support trapping arithmetic may result in the definition and user being
! in different blocks.  Thus, there may be a ‘NOTE_INSN_BASIC_BLOCK’
  between them.  Additionally, the definition may be the source of
  exception handling edges.
  
*************** definition and use of the condition code
*** 38503,38511 ****
  hard register.  If the condition code or comparison result can be placed
  in any general register, or if there are multiple condition registers,
  use a pseudo register.  Registers used to store the condition code value
! will usually have a mode that is in class 'MODE_CC'.
  
!  Alternatively, you can use 'BImode' if the comparison operator is
  specified already in the compare instruction.  In this case, you are not
  interested in most macros in this section.
  
--- 38502,38510 ----
  hard register.  If the condition code or comparison result can be placed
  in any general register, or if there are multiple condition registers,
  use a pseudo register.  Registers used to store the condition code value
! will usually have a mode that is in class ‘MODE_CC’.
  
!  Alternatively, you can use ‘BImode’ if the comparison operator is
  specified already in the compare instruction.  In this case, you are not
  interested in most macros in this section.
  
*************** File: gccint.info,  Node: MODE_CC Condit
*** 38532,38543 ****
       which compare instruction (e.g. a signed or an unsigned comparison)
       produced the condition codes.
  
!      If other modes than 'CCmode' are required, add them to
!      'MACHINE-modes.def' and define 'SELECT_CC_MODE' to choose a mode
       given an operand of a compare.  This is needed because the modes
       have to be chosen not only during RTL generation but also, for
       example, by instruction combination.  The result of
!      'SELECT_CC_MODE' should be consistent with the mode used in the
       patterns; for example to support the case of the add on the SPARC
       discussed above, we have the pattern
  
--- 38531,38542 ----
       which compare instruction (e.g. a signed or an unsigned comparison)
       produced the condition codes.
  
!      If other modes than ‘CCmode’ are required, add them to
!      ‘MACHINE-modes.def’ and define ‘SELECT_CC_MODE’ to choose a mode
       given an operand of a compare.  This is needed because the modes
       have to be chosen not only during RTL generation but also, for
       example, by instruction combination.  The result of
!      ‘SELECT_CC_MODE’ should be consistent with the mode used in the
       patterns; for example to support the case of the add on the SPARC
       discussed above, we have the pattern
  
*************** File: gccint.info,  Node: MODE_CC Condit
*** 38550,38557 ****
              ""
              "...")
  
!      together with a 'SELECT_CC_MODE' that returns 'CCNZmode' for
!      comparisons whose argument is a 'plus':
  
            #define SELECT_CC_MODE(OP,X,Y) \
              (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT           \
--- 38549,38556 ----
              ""
              "...")
  
!      together with a ‘SELECT_CC_MODE’ that returns ‘CCNZmode’ for
!      comparisons whose argument is a ‘plus’:
  
            #define SELECT_CC_MODE(OP,X,Y) \
              (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT           \
*************** File: gccint.info,  Node: MODE_CC Condit
*** 38562,38606 ****
                  ? CCNZmode : CCmode))
  
       Another reason to use modes is to retain information on which
!      operands were used by the comparison; see 'REVERSIBLE_CC_MODE'
       later in this section.
  
       You should define this macro if and only if you define extra CC
!      modes in 'MACHINE-modes.def'.
  
   -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx
            *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE)
       On some machines not all possible comparisons are defined, but you
       can convert an invalid comparison into a valid one.  For example,
!      the Alpha does not have a 'GT' comparison, but you can use an 'LT'
       comparison instead and swap the order of the operands.
  
       On such machines, implement this hook to do any required
       conversions.  CODE is the initial comparison code and OP0 and OP1
       are the left and right operands of the comparison, respectively.
!      If OP0_PRESERVE_VALUE is 'true' the implementation is not allowed
       to change the value of OP0 since the value might be used in RTXs
       which aren't comparisons.  E.g.  the implementation is not allowed
       to swap operands in that case.
  
       GCC will not assume that the comparison resulting from this macro
       is valid but will see if the resulting insn matches a pattern in
!      the 'md' file.
  
       You need not to implement this hook if it would never change the
       comparison code or operands.
  
   -- Macro: REVERSIBLE_CC_MODE (MODE)
       A C expression whose value is one if it is always safe to reverse a
!      comparison whose mode is MODE.  If 'SELECT_CC_MODE' can ever return
       MODE for a floating-point inequality comparison, then
!      'REVERSIBLE_CC_MODE (MODE)' must be zero.
  
       You need not define this macro if it would always returns zero or
       if the floating-point format is anything other than
!      'IEEE_FLOAT_FORMAT'.  For example, here is the definition used on
       the SPARC, where floating-point inequality comparisons are given
!      either 'CCFPEmode' or 'CCFPmode':
  
            #define REVERSIBLE_CC_MODE(MODE) \
               ((MODE) != CCFPEmode && (MODE) != CCFPmode)
--- 38561,38605 ----
                  ? CCNZmode : CCmode))
  
       Another reason to use modes is to retain information on which
!      operands were used by the comparison; see ‘REVERSIBLE_CC_MODE’
       later in this section.
  
       You should define this macro if and only if you define extra CC
!      modes in ‘MACHINE-modes.def’.
  
   -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx
            *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE)
       On some machines not all possible comparisons are defined, but you
       can convert an invalid comparison into a valid one.  For example,
!      the Alpha does not have a ‘GT’ comparison, but you can use an ‘LT’
       comparison instead and swap the order of the operands.
  
       On such machines, implement this hook to do any required
       conversions.  CODE is the initial comparison code and OP0 and OP1
       are the left and right operands of the comparison, respectively.
!      If OP0_PRESERVE_VALUE is ‘true’ the implementation is not allowed
       to change the value of OP0 since the value might be used in RTXs
       which aren't comparisons.  E.g.  the implementation is not allowed
       to swap operands in that case.
  
       GCC will not assume that the comparison resulting from this macro
       is valid but will see if the resulting insn matches a pattern in
!      the ‘md’ file.
  
       You need not to implement this hook if it would never change the
       comparison code or operands.
  
   -- Macro: REVERSIBLE_CC_MODE (MODE)
       A C expression whose value is one if it is always safe to reverse a
!      comparison whose mode is MODE.  If ‘SELECT_CC_MODE’ can ever return
       MODE for a floating-point inequality comparison, then
!      ‘REVERSIBLE_CC_MODE (MODE)’ must be zero.
  
       You need not define this macro if it would always returns zero or
       if the floating-point format is anything other than
!      ‘IEEE_FLOAT_FORMAT’.  For example, here is the definition used on
       the SPARC, where floating-point inequality comparisons are given
!      either ‘CCFPEmode’ or ‘CCFPmode’:
  
            #define REVERSIBLE_CC_MODE(MODE) \
               ((MODE) != CCFPEmode && (MODE) != CCFPmode)
*************** File: gccint.info,  Node: MODE_CC Condit
*** 38608,38614 ****
   -- Macro: REVERSE_CONDITION (CODE, MODE)
       A C expression whose value is reversed condition code of the CODE
       for comparison done in CC_MODE MODE.  The macro is used only in
!      case 'REVERSIBLE_CC_MODE (MODE)' is nonzero.  Define this macro in
       case machine has some non-standard way how to reverse certain
       conditionals.  For instance in case all floating point conditions
       are non-trapping, compiler may freely convert unordered compares to
--- 38607,38613 ----
   -- Macro: REVERSE_CONDITION (CODE, MODE)
       A C expression whose value is reversed condition code of the CODE
       for comparison done in CC_MODE MODE.  The macro is used only in
!      case ‘REVERSIBLE_CC_MODE (MODE)’ is nonzero.  Define this macro in
       case machine has some non-standard way how to reverse certain
       conditionals.  For instance in case all floating point conditions
       are non-trapping, compiler may freely convert unordered compares to
*************** File: gccint.info,  Node: MODE_CC Condit
*** 38628,38649 ****
       should set the integers to which its arguments point to the hard
       register numbers used for condition codes.  When there is only one
       such register, as is true on most systems, the integer pointed to
!      by P2 should be set to 'INVALID_REGNUM'.
  
       The default version of this hook returns false.
  
   -- Target Hook: machine_mode TARGET_CC_MODES_COMPATIBLE (machine_mode
            M1, machine_mode M2)
       On targets which use multiple condition code modes in class
!      'MODE_CC', it is sometimes the case that a comparison can be
       validly done in more than one mode.  On such a system, define this
       target hook to take two mode arguments and to return a mode in
       which both comparisons may be validly done.  If there is no such
!      mode, return 'VOIDmode'.
  
       The default version of this hook checks whether the modes are the
       same.  If they are, it returns that mode.  If they are different,
!      it returns 'VOIDmode'.
  
   -- Target Hook: unsigned int TARGET_FLAGS_REGNUM
       If the target has a dedicated flags register, and it needs to use
--- 38627,38648 ----
       should set the integers to which its arguments point to the hard
       register numbers used for condition codes.  When there is only one
       such register, as is true on most systems, the integer pointed to
!      by P2 should be set to ‘INVALID_REGNUM’.
  
       The default version of this hook returns false.
  
   -- Target Hook: machine_mode TARGET_CC_MODES_COMPATIBLE (machine_mode
            M1, machine_mode M2)
       On targets which use multiple condition code modes in class
!      ‘MODE_CC’, it is sometimes the case that a comparison can be
       validly done in more than one mode.  On such a system, define this
       target hook to take two mode arguments and to return a mode in
       which both comparisons may be validly done.  If there is no such
!      mode, return ‘VOIDmode’.
  
       The default version of this hook checks whether the modes are the
       same.  If they are, it returns that mode.  If they are different,
!      it returns ‘VOIDmode’.
  
   -- Target Hook: unsigned int TARGET_FLAGS_REGNUM
       If the target has a dedicated flags register, and it needs to use
*************** on the target machine.
*** 38662,38668 ****
   -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO)
       A C expression for the cost of moving data of mode MODE from a
       register in class FROM to one in class TO.  The classes are
!      expressed using the enumeration values such as 'GENERAL_REGS'.  A
       value of 2 is the default; other values are interpreted relative to
       that.
  
--- 38661,38667 ----
   -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO)
       A C expression for the cost of moving data of mode MODE from a
       register in class FROM to one in class TO.  The classes are
!      expressed using the enumeration values such as ‘GENERAL_REGS’.  A
       value of 2 is the default; other values are interpreted relative to
       that.
  
*************** on the target machine.
*** 38670,38691 ****
       same as TO; on some machines it is expensive to move between
       registers if they are not general registers.
  
!      If reload sees an insn consisting of a single 'set' between two
!      hard registers, and if 'REGISTER_MOVE_COST' applied to their
       classes returns a value of 2, reload does not check to ensure that
       the constraints of the insn are met.  Setting a cost of other than
       2 will allow reload to verify that the constraints are met.  You
!      should do this if the 'movM' pattern's constraints do not allow
       such copying.
  
       These macros are obsolete, new ports should use the target hook
!      'TARGET_REGISTER_MOVE_COST' instead.
  
   -- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE,
            reg_class_t FROM, reg_class_t TO)
       This target hook should return the cost of moving data of mode MODE
       from a register in class FROM to one in class TO.  The classes are
!      expressed using the enumeration values such as 'GENERAL_REGS'.  A
       value of 2 is the default; other values are interpreted relative to
       that.
  
--- 38669,38690 ----
       same as TO; on some machines it is expensive to move between
       registers if they are not general registers.
  
!      If reload sees an insn consisting of a single ‘set’ between two
!      hard registers, and if ‘REGISTER_MOVE_COST’ applied to their
       classes returns a value of 2, reload does not check to ensure that
       the constraints of the insn are met.  Setting a cost of other than
       2 will allow reload to verify that the constraints are met.  You
!      should do this if the ‘movM’ pattern's constraints do not allow
       such copying.
  
       These macros are obsolete, new ports should use the target hook
!      ‘TARGET_REGISTER_MOVE_COST’ instead.
  
   -- Target Hook: int TARGET_REGISTER_MOVE_COST (machine_mode MODE,
            reg_class_t FROM, reg_class_t TO)
       This target hook should return the cost of moving data of mode MODE
       from a register in class FROM to one in class TO.  The classes are
!      expressed using the enumeration values such as ‘GENERAL_REGS’.  A
       value of 2 is the default; other values are interpreted relative to
       that.
  
*************** on the target machine.
*** 38693,38704 ****
       same as TO; on some machines it is expensive to move between
       registers if they are not general registers.
  
!      If reload sees an insn consisting of a single 'set' between two
!      hard registers, and if 'TARGET_REGISTER_MOVE_COST' applied to their
       classes returns a value of 2, reload does not check to ensure that
       the constraints of the insn are met.  Setting a cost of other than
       2 will allow reload to verify that the constraints are met.  You
!      should do this if the 'movM' pattern's constraints do not allow
       such copying.
  
       The default version of this function returns 2.
--- 38692,38703 ----
       same as TO; on some machines it is expensive to move between
       registers if they are not general registers.
  
!      If reload sees an insn consisting of a single ‘set’ between two
!      hard registers, and if ‘TARGET_REGISTER_MOVE_COST’ applied to their
       classes returns a value of 2, reload does not check to ensure that
       the constraints of the insn are met.  Setting a cost of other than
       2 will allow reload to verify that the constraints are met.  You
!      should do this if the ‘movM’ pattern's constraints do not allow
       such copying.
  
       The default version of this function returns 2.
*************** on the target machine.
*** 38707,38713 ****
       A C expression for the cost of moving data of mode MODE between a
       register of class CLASS and memory; IN is zero if the value is to
       be written to memory, nonzero if it is to be read in.  This cost is
!      relative to those in 'REGISTER_MOVE_COST'.  If moving between
       registers and memory is more expensive than between two registers,
       you should define this macro to express the relative cost.
  
--- 38706,38712 ----
       A C expression for the cost of moving data of mode MODE between a
       register of class CLASS and memory; IN is zero if the value is to
       be written to memory, nonzero if it is to be read in.  This cost is
!      relative to those in ‘REGISTER_MOVE_COST’.  If moving between
       registers and memory is more expensive than between two registers,
       you should define this macro to express the relative cost.
  
*************** on the target machine.
*** 38718,38724 ****
       mechanism is more complex than copying via an intermediate, define
       this macro to reflect the actual cost of the move.
  
!      GCC defines the function 'memory_move_secondary_cost' if secondary
       reloads are needed.  It computes the costs due to copying via a
       secondary register.  If your machine copies from memory using a
       secondary register in the conventional way but the default base
--- 38717,38723 ----
       mechanism is more complex than copying via an intermediate, define
       this macro to reflect the actual cost of the move.
  
!      GCC defines the function ‘memory_move_secondary_cost’ if secondary
       reloads are needed.  It computes the costs due to copying via a
       secondary register.  If your machine copies from memory using a
       secondary register in the conventional way but the default base
*************** on the target machine.
*** 38727,38740 ****
       to that function are the same as to this macro.
  
       These macros are obsolete, new ports should use the target hook
!      'TARGET_MEMORY_MOVE_COST' instead.
  
   -- Target Hook: int TARGET_MEMORY_MOVE_COST (machine_mode MODE,
            reg_class_t RCLASS, bool IN)
       This target hook should return the cost of moving data of mode MODE
!      between a register of class RCLASS and memory; IN is 'false' if the
!      value is to be written to memory, 'true' if it is to be read in.
!      This cost is relative to those in 'TARGET_REGISTER_MOVE_COST'.  If
       moving between registers and memory is more expensive than between
       two registers, you should add this target hook to express the
       relative cost.
--- 38726,38739 ----
       to that function are the same as to this macro.
  
       These macros are obsolete, new ports should use the target hook
!      ‘TARGET_MEMORY_MOVE_COST’ instead.
  
   -- Target Hook: int TARGET_MEMORY_MOVE_COST (machine_mode MODE,
            reg_class_t RCLASS, bool IN)
       This target hook should return the cost of moving data of mode MODE
!      between a register of class RCLASS and memory; IN is ‘false’ if the
!      value is to be written to memory, ‘true’ if it is to be read in.
!      This cost is relative to those in ‘TARGET_REGISTER_MOVE_COST’.  If
       moving between registers and memory is more expensive than between
       two registers, you should add this target hook to express the
       relative cost.
*************** on the target machine.
*** 38746,38752 ****
       mechanism is more complex than copying via an intermediate, use
       this target hook to reflect the actual cost of the move.
  
!      GCC defines the function 'memory_move_secondary_cost' if secondary
       reloads are needed.  It computes the costs due to copying via a
       secondary register.  If your machine copies from memory using a
       secondary register in the conventional way but the default base
--- 38745,38751 ----
       mechanism is more complex than copying via an intermediate, use
       this target hook to reflect the actual cost of the move.
  
!      GCC defines the function ‘memory_move_secondary_cost’ if secondary
       reloads are needed.  It computes the costs due to copying via a
       secondary register.  If your machine copies from memory using a
       secondary register in the conventional way but the default base
*************** on the target machine.
*** 38758,38767 ****
       A C expression for the cost of a branch instruction.  A value of 1
       is the default; other values are interpreted relative to that.
       Parameter SPEED_P is true when the branch in question should be
!      optimized for speed.  When it is false, 'BRANCH_COST' should return
       a value optimal for code size rather than performance.
       PREDICTABLE_P is true for well-predicted branches.  On many
!      architectures the 'BRANCH_COST' can be reduced then.
  
   Here are additional macros which do not specify precise relative costs,
  but only that certain actions are more expensive than GCC would
--- 38757,38766 ----
       A C expression for the cost of a branch instruction.  A value of 1
       is the default; other values are interpreted relative to that.
       Parameter SPEED_P is true when the branch in question should be
!      optimized for speed.  When it is false, ‘BRANCH_COST’ should return
       a value optimal for code size rather than performance.
       PREDICTABLE_P is true for well-predicted branches.  On many
!      architectures the ‘BRANCH_COST’ can be reduced then.
  
   Here are additional macros which do not specify precise relative costs,
  but only that certain actions are more expensive than GCC would
*************** ordinarily expect.
*** 38769,38775 ****
  
   -- Macro: SLOW_BYTE_ACCESS
       Define this macro as a C expression which is nonzero if accessing
!      less than a word of memory (i.e. a 'char' or a 'short') is no
       faster than accessing a word of memory, i.e., if such access
       require more than one instruction or if there is no difference in
       cost between byte and (aligned) word loads.
--- 38768,38774 ----
  
   -- Macro: SLOW_BYTE_ACCESS
       Define this macro as a C expression which is nonzero if accessing
!      less than a word of memory (i.e. a ‘char’ or a ‘short’) is no
       faster than accessing a word of memory, i.e., if such access
       require more than one instruction or if there is no difference in
       cost between byte and (aligned) word loads.
*************** ordinarily expect.
*** 38787,38803 ****
       This hook returns true if memory accesses described by the MODE and
       ALIGNMENT parameters have a cost many times greater than aligned
       accesses, for example if they are emulated in a trap handler.  This
!      hook is invoked only for unaligned accesses, i.e. when 'ALIGNMENT <
!      GET_MODE_ALIGNMENT (MODE)'.
  
       When this hook returns true, the compiler will act as if
!      'STRICT_ALIGNMENT' were true when generating code for block moves.
       This can cause significantly more instructions to be produced.
       Therefore, do not make this hook return true if unaligned accesses
       only add a cycle or two to the time for a memory access.
  
!      The hook must return true whenever 'STRICT_ALIGNMENT' is true.  The
!      default implementation returns 'STRICT_ALIGNMENT'.
  
   -- Macro: MOVE_RATIO (SPEED)
       The threshold of number of scalar memory-to-memory move insns,
--- 38786,38802 ----
       This hook returns true if memory accesses described by the MODE and
       ALIGNMENT parameters have a cost many times greater than aligned
       accesses, for example if they are emulated in a trap handler.  This
!      hook is invoked only for unaligned accesses, i.e. when ‘ALIGNMENT <
!      GET_MODE_ALIGNMENT (MODE)’.
  
       When this hook returns true, the compiler will act as if
!      ‘STRICT_ALIGNMENT’ were true when generating code for block moves.
       This can cause significantly more instructions to be produced.
       Therefore, do not make this hook return true if unaligned accesses
       only add a cycle or two to the time for a memory access.
  
!      The hook must return true whenever ‘STRICT_ALIGNMENT’ is true.  The
!      default implementation returns ‘STRICT_ALIGNMENT’.
  
   -- Macro: MOVE_RATIO (SPEED)
       The threshold of number of scalar memory-to-memory move insns,
*************** ordinarily expect.
*** 38807,38813 ****
       increased code size.
  
       Note that on machines where the corresponding move insn is a
!      'define_expand' that emits a sequence of insns, this macro counts
       the number of such sequences.
  
       The parameter SPEED is true if the code is currently being
--- 38806,38812 ----
       increased code size.
  
       Note that on machines where the corresponding move insn is a
!      ‘define_expand’ that emits a sequence of insns, this macro counts
       the number of such sequences.
  
       The parameter SPEED is true if the code is currently being
*************** ordinarily expect.
*** 38820,38838 ****
            by_pieces_operation OP, bool SPEED_P)
       GCC will attempt several strategies when asked to copy between two
       areas of memory, or to set, clear or store to memory, for example
!      when copying a 'struct'.  The 'by_pieces' infrastructure implements
       such memory operations as a sequence of load, store or move insns.
!      Alternate strategies are to expand the 'cpymem' or 'setmem' optabs,
       to emit a library call, or to emit unit-by-unit, loop-based
       operations.
  
       This target hook should return true if, for a memory operation with
!      a given SIZE and ALIGNMENT, using the 'by_pieces' infrastructure is
       expected to result in better code generation.  Both SIZE and
       ALIGNMENT are measured in terms of storage units.
  
!      The parameter OP is one of: 'CLEAR_BY_PIECES', 'MOVE_BY_PIECES',
!      'SET_BY_PIECES', 'STORE_BY_PIECES' or 'COMPARE_BY_PIECES'.  These
       describe the type of memory operation under consideration.
  
       The parameter SPEED_P is true if the code is currently being
--- 38819,38837 ----
            by_pieces_operation OP, bool SPEED_P)
       GCC will attempt several strategies when asked to copy between two
       areas of memory, or to set, clear or store to memory, for example
!      when copying a ‘struct’.  The ‘by_pieces’ infrastructure implements
       such memory operations as a sequence of load, store or move insns.
!      Alternate strategies are to expand the ‘cpymem’ or ‘setmem’ optabs,
       to emit a library call, or to emit unit-by-unit, loop-based
       operations.
  
       This target hook should return true if, for a memory operation with
!      a given SIZE and ALIGNMENT, using the ‘by_pieces’ infrastructure is
       expected to result in better code generation.  Both SIZE and
       ALIGNMENT are measured in terms of storage units.
  
!      The parameter OP is one of: ‘CLEAR_BY_PIECES’, ‘MOVE_BY_PIECES’,
!      ‘SET_BY_PIECES’, ‘STORE_BY_PIECES’ or ‘COMPARE_BY_PIECES’.  These
       describe the type of memory operation under consideration.
  
       The parameter SPEED_P is true if the code is currently being
*************** ordinarily expect.
*** 38840,38857 ****
  
       Returning true for higher values of SIZE can improve code
       generation for speed if the target does not provide an
!      implementation of the 'cpymem' or 'setmem' standard names, if the
!      'cpymem' or 'setmem' implementation would be more expensive than a
       sequence of insns, or if the overhead of a library call would
       dominate that of the body of the memory operation.
  
!      Returning true for higher values of 'size' may also cause an
       increase in code size, for example where the number of insns
       emitted to perform a move would be greater than that of a library
       call.
  
   -- Target Hook: bool TARGET_OVERLAP_OP_BY_PIECES_P (void)
!      This target hook should return true if when the 'by_pieces'
       infrastructure is used, an offset adjusted unaligned memory
       operation in the smallest integer mode for the last piece operation
       of a memory region can be generated to avoid doing more than one
--- 38839,38856 ----
  
       Returning true for higher values of SIZE can improve code
       generation for speed if the target does not provide an
!      implementation of the ‘cpymem’ or ‘setmem’ standard names, if the
!      ‘cpymem’ or ‘setmem’ implementation would be more expensive than a
       sequence of insns, or if the overhead of a library call would
       dominate that of the body of the memory operation.
  
!      Returning true for higher values of ‘size’ may also cause an
       increase in code size, for example where the number of insns
       emitted to perform a move would be greater than that of a library
       call.
  
   -- Target Hook: bool TARGET_OVERLAP_OP_BY_PIECES_P (void)
!      This target hook should return true if when the ‘by_pieces’
       infrastructure is used, an offset adjusted unaligned memory
       operation in the smallest integer mode for the last piece operation
       of a memory region can be generated to avoid doing more than one
*************** ordinarily expect.
*** 38868,38886 ****
       comparisons by returning a negative number from this hook.
  
   -- Macro: MOVE_MAX_PIECES
!      A C expression used by 'move_by_pieces' to determine the largest
       unit a load or store used to copy memory is.  Defaults to
!      'MOVE_MAX'.
  
   -- Macro: STORE_MAX_PIECES
!      A C expression used by 'store_by_pieces' to determine the largest
!      unit a store used to memory is.  Defaults to 'MOVE_MAX_PIECES', or
!      two times the size of 'HOST_WIDE_INT', whichever is smaller.
  
   -- Macro: COMPARE_MAX_PIECES
!      A C expression used by 'compare_by_pieces' to determine the largest
       unit a load or store used to compare memory is.  Defaults to
!      'MOVE_MAX_PIECES'.
  
   -- Macro: CLEAR_RATIO (SPEED)
       The threshold of number of scalar move insns, _below_ which a
--- 38867,38885 ----
       comparisons by returning a negative number from this hook.
  
   -- Macro: MOVE_MAX_PIECES
!      A C expression used by ‘move_by_pieces’ to determine the largest
       unit a load or store used to copy memory is.  Defaults to
!      ‘MOVE_MAX’.
  
   -- Macro: STORE_MAX_PIECES
!      A C expression used by ‘store_by_pieces’ to determine the largest
!      unit a store used to memory is.  Defaults to ‘MOVE_MAX_PIECES’, or
!      two times the size of ‘HOST_WIDE_INT’, whichever is smaller.
  
   -- Macro: COMPARE_MAX_PIECES
!      A C expression used by ‘compare_by_pieces’ to determine the largest
       unit a load or store used to compare memory is.  Defaults to
!      ‘MOVE_MAX_PIECES’.
  
   -- Macro: CLEAR_RATIO (SPEED)
       The threshold of number of scalar move insns, _below_ which a
*************** ordinarily expect.
*** 38904,38950 ****
       The parameter SPEED is true if the code is currently being
       optimized for speed rather than size.
  
!      If you don't define this, it defaults to the value of 'MOVE_RATIO'.
  
   -- Macro: USE_LOAD_POST_INCREMENT (MODE)
       A C expression used to determine whether a load postincrement is a
       good thing to use for a given mode.  Defaults to the value of
!      'HAVE_POST_INCREMENT'.
  
   -- Macro: USE_LOAD_POST_DECREMENT (MODE)
       A C expression used to determine whether a load postdecrement is a
       good thing to use for a given mode.  Defaults to the value of
!      'HAVE_POST_DECREMENT'.
  
   -- Macro: USE_LOAD_PRE_INCREMENT (MODE)
       A C expression used to determine whether a load preincrement is a
       good thing to use for a given mode.  Defaults to the value of
!      'HAVE_PRE_INCREMENT'.
  
   -- Macro: USE_LOAD_PRE_DECREMENT (MODE)
       A C expression used to determine whether a load predecrement is a
       good thing to use for a given mode.  Defaults to the value of
!      'HAVE_PRE_DECREMENT'.
  
   -- Macro: USE_STORE_POST_INCREMENT (MODE)
       A C expression used to determine whether a store postincrement is a
       good thing to use for a given mode.  Defaults to the value of
!      'HAVE_POST_INCREMENT'.
  
   -- Macro: USE_STORE_POST_DECREMENT (MODE)
       A C expression used to determine whether a store postdecrement is a
       good thing to use for a given mode.  Defaults to the value of
!      'HAVE_POST_DECREMENT'.
  
   -- Macro: USE_STORE_PRE_INCREMENT (MODE)
       This macro is used to determine whether a store preincrement is a
       good thing to use for a given mode.  Defaults to the value of
!      'HAVE_PRE_INCREMENT'.
  
   -- Macro: USE_STORE_PRE_DECREMENT (MODE)
       This macro is used to determine whether a store predecrement is a
       good thing to use for a given mode.  Defaults to the value of
!      'HAVE_PRE_DECREMENT'.
  
   -- Macro: NO_FUNCTION_CSE
       Define this macro to be true if it is as good or better to call a
--- 38903,38949 ----
       The parameter SPEED is true if the code is currently being
       optimized for speed rather than size.
  
!      If you don't define this, it defaults to the value of ‘MOVE_RATIO’.
  
   -- Macro: USE_LOAD_POST_INCREMENT (MODE)
       A C expression used to determine whether a load postincrement is a
       good thing to use for a given mode.  Defaults to the value of
!      ‘HAVE_POST_INCREMENT’.
  
   -- Macro: USE_LOAD_POST_DECREMENT (MODE)
       A C expression used to determine whether a load postdecrement is a
       good thing to use for a given mode.  Defaults to the value of
!      ‘HAVE_POST_DECREMENT’.
  
   -- Macro: USE_LOAD_PRE_INCREMENT (MODE)
       A C expression used to determine whether a load preincrement is a
       good thing to use for a given mode.  Defaults to the value of
!      ‘HAVE_PRE_INCREMENT’.
  
   -- Macro: USE_LOAD_PRE_DECREMENT (MODE)
       A C expression used to determine whether a load predecrement is a
       good thing to use for a given mode.  Defaults to the value of
!      ‘HAVE_PRE_DECREMENT’.
  
   -- Macro: USE_STORE_POST_INCREMENT (MODE)
       A C expression used to determine whether a store postincrement is a
       good thing to use for a given mode.  Defaults to the value of
!      ‘HAVE_POST_INCREMENT’.
  
   -- Macro: USE_STORE_POST_DECREMENT (MODE)
       A C expression used to determine whether a store postdecrement is a
       good thing to use for a given mode.  Defaults to the value of
!      ‘HAVE_POST_DECREMENT’.
  
   -- Macro: USE_STORE_PRE_INCREMENT (MODE)
       This macro is used to determine whether a store preincrement is a
       good thing to use for a given mode.  Defaults to the value of
!      ‘HAVE_PRE_INCREMENT’.
  
   -- Macro: USE_STORE_PRE_DECREMENT (MODE)
       This macro is used to determine whether a store predecrement is a
       good thing to use for a given mode.  Defaults to the value of
!      ‘HAVE_PRE_DECREMENT’.
  
   -- Macro: NO_FUNCTION_CSE
       Define this macro to be true if it is as good or better to call a
*************** ordinarily expect.
*** 38953,38972 ****
  
   -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT
       Define this macro if a non-short-circuit operation produced by
!      'fold_range_test ()' is optimal.  This macro defaults to true if
!      'BRANCH_COST' is greater than or equal to the value 2.
  
   -- Target Hook: bool TARGET_OPTAB_SUPPORTED_P (int OP, machine_mode
            MODE1, machine_mode MODE2, optimization_type OPT_TYPE)
       Return true if the optimizers should use optab OP with modes MODE1
       and MODE2 for optimization type OPT_TYPE.  The optab is known to
!      have an associated '.md' instruction whose C condition is true.
       MODE2 is only meaningful for conversion optabs; for direct optabs
       it is a copy of MODE1.
  
!      For example, when called with OP equal to 'rint_optab' and MODE1
!      equal to 'DFmode', the hook should say whether the optimizers
!      should use optab 'rintdf2'.
  
       The default hook returns true for all inputs.
  
--- 38952,38971 ----
  
   -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT
       Define this macro if a non-short-circuit operation produced by
!      ‘fold_range_test ()’ is optimal.  This macro defaults to true if
!      ‘BRANCH_COST’ is greater than or equal to the value 2.
  
   -- Target Hook: bool TARGET_OPTAB_SUPPORTED_P (int OP, machine_mode
            MODE1, machine_mode MODE2, optimization_type OPT_TYPE)
       Return true if the optimizers should use optab OP with modes MODE1
       and MODE2 for optimization type OPT_TYPE.  The optab is known to
!      have an associated ‘.md’ instruction whose C condition is true.
       MODE2 is only meaningful for conversion optabs; for direct optabs
       it is a copy of MODE1.
  
!      For example, when called with OP equal to ‘rint_optab’ and MODE1
!      equal to ‘DFmode’, the hook should say whether the optimizers
!      should use optab ‘rintdf2’.
  
       The default hook returns true for all inputs.
  
*************** ordinarily expect.
*** 38977,39011 ****
       The cost may depend on the precise form of the expression, which is
       available for examination in X, and the fact that X appears as
       operand OPNO of an expression with rtx code OUTER_CODE.  That is,
!      the hook can assume that there is some rtx Y such that 'GET_CODE
!      (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X'
!      or (b) 'XVEC (Y, OPNO)' contains X.
  
!      MODE is X's machine mode, or for cases like 'const_int' that do not
       have a mode, the mode in which X is used.
  
!      In implementing this hook, you can use the construct 'COSTS_N_INSNS
!      (N)' to specify a cost equal to N fast instructions.
  
!      On entry to the hook, '*TOTAL' contains a default estimate for the
       cost of the expression.  The hook should modify this value as
!      necessary.  Traditionally, the default costs are 'COSTS_N_INSNS
!      (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and
!      modulus operations, and 'COSTS_N_INSNS (1)' for all other
       operations.
  
!      When optimizing for code size, i.e. when 'speed' is false, this
       target hook should be used to estimate the relative size cost of an
!      expression, again relative to 'COSTS_N_INSNS'.
  
       The hook returns true when all subexpressions of X have been
!      processed, and false when 'rtx_cost' should recurse.
  
   -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, machine_mode
            MODE, addr_space_t AS, bool SPEED)
       This hook computes the cost of an addressing mode that contains
       ADDRESS.  If not defined, the cost is computed from the ADDRESS
!      expression and the 'TARGET_RTX_COST' hook.
  
       For most CISC machines, the default cost is a good approximation of
       the true cost of the addressing mode.  However, on RISC machines,
--- 38976,39010 ----
       The cost may depend on the precise form of the expression, which is
       available for examination in X, and the fact that X appears as
       operand OPNO of an expression with rtx code OUTER_CODE.  That is,
!      the hook can assume that there is some rtx Y such that ‘GET_CODE
!      (Y) == OUTER_CODE’ and such that either (a) ‘XEXP (Y, OPNO) == X’
!      or (b) ‘XVEC (Y, OPNO)’ contains X.
  
!      MODE is X's machine mode, or for cases like ‘const_int’ that do not
       have a mode, the mode in which X is used.
  
!      In implementing this hook, you can use the construct ‘COSTS_N_INSNS
!      (N)’ to specify a cost equal to N fast instructions.
  
!      On entry to the hook, ‘*TOTAL’ contains a default estimate for the
       cost of the expression.  The hook should modify this value as
!      necessary.  Traditionally, the default costs are ‘COSTS_N_INSNS
!      (5)’ for multiplications, ‘COSTS_N_INSNS (7)’ for division and
!      modulus operations, and ‘COSTS_N_INSNS (1)’ for all other
       operations.
  
!      When optimizing for code size, i.e. when ‘speed’ is false, this
       target hook should be used to estimate the relative size cost of an
!      expression, again relative to ‘COSTS_N_INSNS’.
  
       The hook returns true when all subexpressions of X have been
!      processed, and false when ‘rtx_cost’ should recurse.
  
   -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, machine_mode
            MODE, addr_space_t AS, bool SPEED)
       This hook computes the cost of an addressing mode that contains
       ADDRESS.  If not defined, the cost is computed from the ADDRESS
!      expression and the ‘TARGET_RTX_COST’ hook.
  
       For most CISC machines, the default cost is a good approximation of
       the true cost of the addressing mode.  However, on RISC machines,
*************** ordinarily expect.
*** 39030,39038 ****
  
       On machines where an address involving more than one register is as
       cheap as an address computation involving only one register,
!      defining 'TARGET_ADDRESS_COST' to reflect this can cause two
       registers to be live over a region of code where only one would
!      have been if 'TARGET_ADDRESS_COST' were not defined in that manner.
       This effect should be considered in the definition of this macro.
       Equivalent costs should probably only be given to addresses with
       different numbers of registers on machines with lots of registers.
--- 39029,39037 ----
  
       On machines where an address involving more than one register is as
       cheap as an address computation involving only one register,
!      defining ‘TARGET_ADDRESS_COST’ to reflect this can cause two
       registers to be live over a region of code where only one would
!      have been if ‘TARGET_ADDRESS_COST’ were not defined in that manner.
       This effect should be considered in the definition of this macro.
       Equivalent costs should probably only be given to addresses with
       different numbers of registers on machines with lots of registers.
*************** ordinarily expect.
*** 39040,39083 ****
   -- Target Hook: int TARGET_INSN_COST (rtx_insn *INSN, bool SPEED)
       This target hook describes the relative costs of RTL instructions.
  
!      In implementing this hook, you can use the construct 'COSTS_N_INSNS
!      (N)' to specify a cost equal to N fast instructions.
  
!      When optimizing for code size, i.e. when 'speed' is false, this
       target hook should be used to estimate the relative size cost of an
!      expression, again relative to 'COSTS_N_INSNS'.
  
   -- Target Hook: unsigned int TARGET_MAX_NOCE_IFCVT_SEQ_COST (edge E)
!      This hook returns a value in the same units as 'TARGET_RTX_COSTS',
       giving the maximum acceptable cost for a sequence generated by the
       RTL if-conversion pass when conditional execution is not available.
       The RTL if-conversion pass attempts to convert conditional
       operations that would require a branch to a series of unconditional
!      operations and 'movMODEcc' insns.  This hook returns the maximum
!      cost of the unconditional instructions and the 'movMODEcc' insns.
       RTL if-conversion is cancelled if the cost of the converted
       sequence is greater than the value returned by this hook.
  
!      'e' is the edge between the basic block containing the conditional
       branch to the basic block which would be executed if the condition
       were true.
  
       The default implementation of this hook uses the
!      'max-rtl-if-conversion-[un]predictable' parameters if they are set,
!      and uses a multiple of 'BRANCH_COST' otherwise.
  
   -- Target Hook: bool TARGET_NOCE_CONVERSION_PROFITABLE_P (rtx_insn
            *SEQ, struct noce_if_info *IF_INFO)
!      This hook returns true if the instruction sequence 'seq' is a good
       candidate as a replacement for the if-convertible sequence
!      described in 'if_info'.
  
   -- Target Hook: bool TARGET_NEW_ADDRESS_PROFITABLE_P (rtx MEMREF,
            rtx_insn * INSN, rtx NEW_ADDR)
!      Return 'true' if it is profitable to replace the address in MEMREF
       with NEW_ADDR.  This allows targets to prevent the scheduler from
       undoing address optimizations.  The instruction containing the
!      memref is INSN.  The default implementation returns 'true'.
  
   -- Target Hook: bool TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P (void)
       This predicate controls the use of the eager delay slot filler to
--- 39039,39082 ----
   -- Target Hook: int TARGET_INSN_COST (rtx_insn *INSN, bool SPEED)
       This target hook describes the relative costs of RTL instructions.
  
!      In implementing this hook, you can use the construct ‘COSTS_N_INSNS
!      (N)’ to specify a cost equal to N fast instructions.
  
!      When optimizing for code size, i.e. when ‘speed’ is false, this
       target hook should be used to estimate the relative size cost of an
!      expression, again relative to ‘COSTS_N_INSNS’.
  
   -- Target Hook: unsigned int TARGET_MAX_NOCE_IFCVT_SEQ_COST (edge E)
!      This hook returns a value in the same units as ‘TARGET_RTX_COSTS’,
       giving the maximum acceptable cost for a sequence generated by the
       RTL if-conversion pass when conditional execution is not available.
       The RTL if-conversion pass attempts to convert conditional
       operations that would require a branch to a series of unconditional
!      operations and ‘movMODEcc’ insns.  This hook returns the maximum
!      cost of the unconditional instructions and the ‘movMODEcc’ insns.
       RTL if-conversion is cancelled if the cost of the converted
       sequence is greater than the value returned by this hook.
  
!      ‘e’ is the edge between the basic block containing the conditional
       branch to the basic block which would be executed if the condition
       were true.
  
       The default implementation of this hook uses the
!      ‘max-rtl-if-conversion-[un]predictable’ parameters if they are set,
!      and uses a multiple of ‘BRANCH_COST’ otherwise.
  
   -- Target Hook: bool TARGET_NOCE_CONVERSION_PROFITABLE_P (rtx_insn
            *SEQ, struct noce_if_info *IF_INFO)
!      This hook returns true if the instruction sequence ‘seq’ is a good
       candidate as a replacement for the if-convertible sequence
!      described in ‘if_info’.
  
   -- Target Hook: bool TARGET_NEW_ADDRESS_PROFITABLE_P (rtx MEMREF,
            rtx_insn * INSN, rtx NEW_ADDR)
!      Return ‘true’ if it is profitable to replace the address in MEMREF
       with NEW_ADDR.  This allows targets to prevent the scheduler from
       undoing address optimizations.  The instruction containing the
!      memref is INSN.  The default implementation returns ‘true’.
  
   -- Target Hook: bool TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P (void)
       This predicate controls the use of the eager delay slot filler to
*************** ordinarily expect.
*** 39094,39101 ****
       Return an estimate of the runtime value of VAL, for use in things
       like cost calculations or profiling frequencies.  KIND is used to
       ask for the minimum, maximum, and likely estimates of the value
!      through the 'POLY_VALUE_MIN', 'POLY_VALUE_MAX' and
!      'POLY_VALUE_LIKELY' values.  The default implementation returns the
       lowest possible value of VAL.
  
  
--- 39093,39100 ----
       Return an estimate of the runtime value of VAL, for use in things
       like cost calculations or profiling frequencies.  KIND is used to
       ask for the minimum, maximum, and likely estimates of the value
!      through the ‘POLY_VALUE_MIN’, ‘POLY_VALUE_MAX’ and
!      ‘POLY_VALUE_LIKELY’ values.  The default implementation returns the
       lowest possible value of VAL.
  
  
*************** them: try the first ones in this list fi
*** 39115,39136 ****
       Although the insn scheduler can define itself the possibility of
       issue an insn on the same cycle, the value can serve as an
       additional constraint to issue insns on the same simulated
!      processor cycle (see hooks 'TARGET_SCHED_REORDER' and
!      'TARGET_SCHED_REORDER2').  This value must be constant over the
       entire compilation.  If you need it to vary depending on what the
!      instructions are, you must use 'TARGET_SCHED_VARIABLE_ISSUE'.
  
   -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int
            VERBOSE, rtx_insn *INSN, int MORE)
       This hook is executed by the scheduler after it has scheduled an
       insn from the ready list.  It should return the number of insns
       which can still be issued in the current cycle.  The default is
!      'MORE - 1' for insns other than 'CLOBBER' and 'USE', which normally
       are not counted against the issue rate.  You should define this
       hook if some insns take more machine resources than others, so that
       fewer insns can follow them in the same cycle.  FILE is either a
       null pointer, or a stdio stream to write any debug output to.
!      VERBOSE is the verbose level provided by '-fsched-verbose-N'.  INSN
       is the instruction that was scheduled.
  
   -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx_insn *INSN, int
--- 39114,39135 ----
       Although the insn scheduler can define itself the possibility of
       issue an insn on the same cycle, the value can serve as an
       additional constraint to issue insns on the same simulated
!      processor cycle (see hooks ‘TARGET_SCHED_REORDER’ and
!      ‘TARGET_SCHED_REORDER2’).  This value must be constant over the
       entire compilation.  If you need it to vary depending on what the
!      instructions are, you must use ‘TARGET_SCHED_VARIABLE_ISSUE’.
  
   -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int
            VERBOSE, rtx_insn *INSN, int MORE)
       This hook is executed by the scheduler after it has scheduled an
       insn from the ready list.  It should return the number of insns
       which can still be issued in the current cycle.  The default is
!      ‘MORE - 1’ for insns other than ‘CLOBBER’ and ‘USE’, which normally
       are not counted against the issue rate.  You should define this
       hook if some insns take more machine resources than others, so that
       fewer insns can follow them in the same cycle.  FILE is either a
       null pointer, or a stdio stream to write any debug output to.
!      VERBOSE is the verbose level provided by ‘-fsched-verbose-N’.  INSN
       is the instruction that was scheduled.
  
   -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx_insn *INSN, int
*************** them: try the first ones in this list fi
*** 39160,39184 ****
            rtx_insn **READY, int *N_READYP, int CLOCK)
       This hook is executed by the scheduler after it has scheduled the
       ready list, to allow the machine description to reorder it (for
!      example to combine two small instructions together on 'VLIW'
       machines).  FILE is either a null pointer, or a stdio stream to
       write any debug output to.  VERBOSE is the verbose level provided
!      by '-fsched-verbose-N'.  READY is a pointer to the ready list of
       instructions that are ready to be scheduled.  N_READYP is a pointer
       to the number of elements in the ready list.  The scheduler reads
!      the ready list in reverse order, starting with READY[*N_READYP - 1]
       and going to READY[0].  CLOCK is the timer tick of the scheduler.
       You may modify the ready list and the number of ready insns.  The
       return value is the number of insns that can issue this cycle;
!      normally this is just 'issue_rate'.  See also
!      'TARGET_SCHED_REORDER2'.
  
   -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE,
            rtx_insn **READY, int *N_READYP, int CLOCK)
!      Like 'TARGET_SCHED_REORDER', but called at a different time.  That
       function is called whenever the scheduler starts a new cycle.  This
       one is called once per iteration over a cycle, immediately after
!      'TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list and
       return the number of insns to be scheduled in the same cycle.
       Defining this hook can be useful if there are frequent situations
       where scheduling one insn causes other insns to become ready in the
--- 39159,39183 ----
            rtx_insn **READY, int *N_READYP, int CLOCK)
       This hook is executed by the scheduler after it has scheduled the
       ready list, to allow the machine description to reorder it (for
!      example to combine two small instructions together on ‘VLIW’
       machines).  FILE is either a null pointer, or a stdio stream to
       write any debug output to.  VERBOSE is the verbose level provided
!      by ‘-fsched-verbose-N’.  READY is a pointer to the ready list of
       instructions that are ready to be scheduled.  N_READYP is a pointer
       to the number of elements in the ready list.  The scheduler reads
!      the ready list in reverse order, starting with READY[*N_READYP − 1]
       and going to READY[0].  CLOCK is the timer tick of the scheduler.
       You may modify the ready list and the number of ready insns.  The
       return value is the number of insns that can issue this cycle;
!      normally this is just ‘issue_rate’.  See also
!      ‘TARGET_SCHED_REORDER2’.
  
   -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE,
            rtx_insn **READY, int *N_READYP, int CLOCK)
!      Like ‘TARGET_SCHED_REORDER’, but called at a different time.  That
       function is called whenever the scheduler starts a new cycle.  This
       one is called once per iteration over a cycle, immediately after
!      ‘TARGET_SCHED_VARIABLE_ISSUE’; it can reorder the ready list and
       return the number of insns to be scheduled in the same cycle.
       Defining this hook can be useful if there are frequent situations
       where scheduling one insn causes other insns to become ready in the
*************** them: try the first ones in this list fi
*** 39214,39246 ****
       This hook is executed by the scheduler at the beginning of each
       block of instructions that are to be scheduled.  FILE is either a
       null pointer, or a stdio stream to write any debug output to.
!      VERBOSE is the verbose level provided by '-fsched-verbose-N'.
       MAX_READY is the maximum number of insns in the current scheduling
       region that can be live at the same time.  This can be used to
       allocate scratch space if it is needed, e.g. by
!      'TARGET_SCHED_REORDER'.
  
   -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE)
       This hook is executed by the scheduler at the end of each block of
       instructions that are to be scheduled.  It can be used to perform
       cleanup of any actions done by the other scheduling hooks.  FILE is
       either a null pointer, or a stdio stream to write any debug output
!      to.  VERBOSE is the verbose level provided by '-fsched-verbose-N'.
  
   -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int VERBOSE,
            int OLD_MAX_UID)
       This hook is executed by the scheduler after function level
       initializations.  FILE is either a null pointer, or a stdio stream
       to write any debug output to.  VERBOSE is the verbose level
!      provided by '-fsched-verbose-N'.  OLD_MAX_UID is the maximum insn
       uid when scheduling begins.
  
   -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int
            VERBOSE)
       This is the cleanup hook corresponding to
!      'TARGET_SCHED_INIT_GLOBAL'.  FILE is either a null pointer, or a
       stdio stream to write any debug output to.  VERBOSE is the verbose
!      level provided by '-fsched-verbose-N'.
  
   -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void)
       The hook returns an RTL insn.  The automaton state used in the
--- 39213,39245 ----
       This hook is executed by the scheduler at the beginning of each
       block of instructions that are to be scheduled.  FILE is either a
       null pointer, or a stdio stream to write any debug output to.
!      VERBOSE is the verbose level provided by ‘-fsched-verbose-N’.
       MAX_READY is the maximum number of insns in the current scheduling
       region that can be live at the same time.  This can be used to
       allocate scratch space if it is needed, e.g. by
!      ‘TARGET_SCHED_REORDER’.
  
   -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE)
       This hook is executed by the scheduler at the end of each block of
       instructions that are to be scheduled.  It can be used to perform
       cleanup of any actions done by the other scheduling hooks.  FILE is
       either a null pointer, or a stdio stream to write any debug output
!      to.  VERBOSE is the verbose level provided by ‘-fsched-verbose-N’.
  
   -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int VERBOSE,
            int OLD_MAX_UID)
       This hook is executed by the scheduler after function level
       initializations.  FILE is either a null pointer, or a stdio stream
       to write any debug output to.  VERBOSE is the verbose level
!      provided by ‘-fsched-verbose-N’.  OLD_MAX_UID is the maximum insn
       uid when scheduling begins.
  
   -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int
            VERBOSE)
       This is the cleanup hook corresponding to
!      ‘TARGET_SCHED_INIT_GLOBAL’.  FILE is either a null pointer, or a
       stdio stream to write any debug output to.  VERBOSE is the verbose
!      level provided by ‘-fsched-verbose-N’.
  
   -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void)
       The hook returns an RTL insn.  The automaton state used in the
*************** them: try the first ones in this list fi
*** 39255,39279 ****
       The hook can be used to initialize data used by the previous hook.
  
   -- Target Hook: rtx_insn * TARGET_SCHED_DFA_POST_CYCLE_INSN (void)
!      The hook is analogous to 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used
       to changed the state as if the insn were scheduled when the new
       simulated processor cycle finishes.
  
   -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void)
!      The hook is analogous to 'TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but
       used to initialize data used by the previous hook.
  
   -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void)
       The hook to notify target that the current simulated cycle is about
       to finish.  The hook is analogous to
!      'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in
       more complicated situations - e.g., when advancing state on a
       single insn is not enough.
  
   -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void)
       The hook to notify target that new simulated cycle has just
       started.  The hook is analogous to
!      'TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in
       more complicated situations - e.g., when advancing state on a
       single insn is not enough.
  
--- 39254,39278 ----
       The hook can be used to initialize data used by the previous hook.
  
   -- Target Hook: rtx_insn * TARGET_SCHED_DFA_POST_CYCLE_INSN (void)
!      The hook is analogous to ‘TARGET_SCHED_DFA_PRE_CYCLE_INSN’ but used
       to changed the state as if the insn were scheduled when the new
       simulated processor cycle finishes.
  
   -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void)
!      The hook is analogous to ‘TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN’ but
       used to initialize data used by the previous hook.
  
   -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void)
       The hook to notify target that the current simulated cycle is about
       to finish.  The hook is analogous to
!      ‘TARGET_SCHED_DFA_PRE_CYCLE_INSN’ but used to change the state in
       more complicated situations - e.g., when advancing state on a
       single insn is not enough.
  
   -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void)
       The hook to notify target that new simulated cycle has just
       started.  The hook is analogous to
!      ‘TARGET_SCHED_DFA_POST_CYCLE_INSN’ but used to change the state in
       more complicated situations - e.g., when advancing state on a
       single insn is not enough.
  
*************** them: try the first ones in this list fi
*** 39283,39289 ****
       queue for the DFA-based insn scheduler.  Usually the scheduler
       chooses the first insn from the queue.  If the hook returns a
       positive value, an additional scheduler code tries all permutations
!      of 'TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()' subsequent
       ready insns to choose an insn whose issue will result in maximal
       number of issued insns on the same cycle.  For the VLIW processor,
       the code could actually solve the problem of packing simple insns
--- 39282,39288 ----
       queue for the DFA-based insn scheduler.  Usually the scheduler
       chooses the first insn from the queue.  If the hook returns a
       positive value, an additional scheduler code tries all permutations
!      of ‘TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()’ subsequent
       ready insns to choose an insn whose issue will result in maximal
       number of issued insns on the same cycle.  For the VLIW processor,
       the code could actually solve the problem of packing simple insns
*************** them: try the first ones in this list fi
*** 39374,39382 ****
       _DEP is the dependence being evaluated.  The second parameter COST
       is the cost of the dependence as estimated by the scheduler, and
       the third parameter DISTANCE is the distance in cycles between the
!      two insns.  The hook returns 'true' if considering the distance
       between the two insns the dependence between them is considered
!      costly by the target, and 'false' otherwise.
  
       Defining this hook can be useful in multiple-issue out-of-order
       machines, where (a) it's practically hopeless to predict the actual
--- 39373,39381 ----
       _DEP is the dependence being evaluated.  The second parameter COST
       is the cost of the dependence as estimated by the scheduler, and
       the third parameter DISTANCE is the distance in cycles between the
!      two insns.  The hook returns ‘true’ if considering the distance
       between the two insns the dependence between them is considered
!      costly by the target, and ‘false’ otherwise.
  
       Defining this hook can be useful in multiple-issue out-of-order
       machines, where (a) it's practically hopeless to predict the actual
*************** them: try the first ones in this list fi
*** 39421,39427 ****
       speculatively.  The hook is used to check if the pattern of INSN
       has a speculative version and, in case of successful check, to
       generate that speculative pattern.  The hook should return 1, if
!      the instruction has a speculative form, or -1, if it doesn't.
       REQUEST describes the type of requested speculation.  If the return
       value equals 1 then NEW_PAT is assigned the generated speculative
       pattern.
--- 39420,39426 ----
       speculatively.  The hook is used to check if the pattern of INSN
       has a speculative version and, in case of successful check, to
       generate that speculative pattern.  The hook should return 1, if
!      the instruction has a speculative form, or −1, if it doesn't.
       REQUEST describes the type of requested speculation.  If the return
       value equals 1 then NEW_PAT is assigned the generated speculative
       pattern.
*************** them: try the first ones in this list fi
*** 39429,39437 ****
   -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int
            DEP_STATUS)
       This hook is called by the insn scheduler during generation of
!      recovery code for INSN.  It should return 'true', if the
       corresponding check instruction should branch to recovery code, or
!      'false' otherwise.
  
   -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx_insn *INSN,
            rtx_insn *LABEL, unsigned int DS)
--- 39428,39436 ----
   -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int
            DEP_STATUS)
       This hook is called by the insn scheduler during generation of
!      recovery code for INSN.  It should return ‘true’, if the
       corresponding check instruction should branch to recovery code, or
!      ‘false’ otherwise.
  
   -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx_insn *INSN,
            rtx_insn *LABEL, unsigned int DS)
*************** them: try the first ones in this list fi
*** 39457,39463 ****
       usually because the instruction is too expensive to get this wrong.
       Often such instructions have long latency, and often they are not
       fully modeled in the pipeline descriptions.  This hook should
!      return 'false' if INSN should not be speculated.
  
   -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G)
       This hook is called by the swing modulo scheduler to calculate a
--- 39456,39462 ----
       usually because the instruction is too expensive to get this wrong.
       Often such instructions have long latency, and often they are not
       fully modeled in the pipeline descriptions.  This hook should
!      return ‘false’ if INSN should not be speculated.
  
   -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G)
       This hook is called by the swing modulo scheduler to calculate a
*************** File: gccint.info,  Node: Sections,  Nex
*** 39572,39611 ****
  ==========================================================
  
  An object file is divided into sections containing different types of
! data.  In the most common case, there are three sections: the "text
! section", which holds instructions and read-only data; the "data
! section", which holds initialized writable data; and the "bss section",
  which holds uninitialized data.  Some systems have other kinds of
  sections.
  
!  'varasm.cc' provides several well-known sections, such as
! 'text_section', 'data_section' and 'bss_section'.  The normal way of
! controlling a 'FOO_section' variable is to define the associated
! 'FOO_SECTION_ASM_OP' macro, as described below.  The macros are only
! read once, when 'varasm.cc' initializes itself, so their values must be
  run-time constants.  They may however depend on command-line flags.
  
!  _Note:_ Some run-time files, such 'crtstuff.c', also make use of the
! 'FOO_SECTION_ASM_OP' macros, and expect them to be string literals.
  
   Some assemblers require a different string to be written every time a
  section is selected.  If your assembler falls into this category, you
! should define the 'TARGET_ASM_INIT_SECTIONS' hook and use
! 'get_unnamed_section' to set up the sections.
  
!  You must always create a 'text_section', either by defining
! 'TEXT_SECTION_ASM_OP' or by initializing 'text_section' in
! 'TARGET_ASM_INIT_SECTIONS'.  The same is true of 'data_section' and
! 'DATA_SECTION_ASM_OP'.  If you do not create a distinct
! 'readonly_data_section', the default is to reuse 'text_section'.
  
!  All the other 'varasm.cc' sections are optional, and are null if the
  target does not provide them.
  
   -- Macro: TEXT_SECTION_ASM_OP
       A C expression whose value is a string, including spacing,
       containing the assembler operation that should precede instructions
!      and read-only data.  Normally '"\t.text"' is right.
  
   -- Macro: HOT_TEXT_SECTION_NAME
       If defined, a C string constant for the name of the section
--- 39571,39610 ----
  ==========================================================
  
  An object file is divided into sections containing different types of
! data.  In the most common case, there are three sections: the “text
! section”, which holds instructions and read-only data; the “data
! section”, which holds initialized writable data; and the “bss section”,
  which holds uninitialized data.  Some systems have other kinds of
  sections.
  
!  ‘varasm.cc’ provides several well-known sections, such as
! ‘text_section’, ‘data_section’ and ‘bss_section’.  The normal way of
! controlling a ‘FOO_section’ variable is to define the associated
! ‘FOO_SECTION_ASM_OP’ macro, as described below.  The macros are only
! read once, when ‘varasm.cc’ initializes itself, so their values must be
  run-time constants.  They may however depend on command-line flags.
  
!  _Note:_ Some run-time files, such ‘crtstuff.c’, also make use of the
! ‘FOO_SECTION_ASM_OP’ macros, and expect them to be string literals.
  
   Some assemblers require a different string to be written every time a
  section is selected.  If your assembler falls into this category, you
! should define the ‘TARGET_ASM_INIT_SECTIONS’ hook and use
! ‘get_unnamed_section’ to set up the sections.
  
!  You must always create a ‘text_section’, either by defining
! ‘TEXT_SECTION_ASM_OP’ or by initializing ‘text_section’ in
! ‘TARGET_ASM_INIT_SECTIONS’.  The same is true of ‘data_section’ and
! ‘DATA_SECTION_ASM_OP’.  If you do not create a distinct
! ‘readonly_data_section’, the default is to reuse ‘text_section’.
  
!  All the other ‘varasm.cc’ sections are optional, and are null if the
  target does not provide them.
  
   -- Macro: TEXT_SECTION_ASM_OP
       A C expression whose value is a string, including spacing,
       containing the assembler operation that should precede instructions
!      and read-only data.  Normally ‘"\t.text"’ is right.
  
   -- Macro: HOT_TEXT_SECTION_NAME
       If defined, a C string constant for the name of the section
*************** target does not provide them.
*** 39620,39626 ****
   -- Macro: DATA_SECTION_ASM_OP
       A C expression whose value is a string, including spacing,
       containing the assembler operation to identify the following data
!      as writable initialized data.  Normally '"\t.data"' is right.
  
   -- Macro: SDATA_SECTION_ASM_OP
       If defined, a C expression whose value is a string, including
--- 39619,39625 ----
   -- Macro: DATA_SECTION_ASM_OP
       A C expression whose value is a string, including spacing,
       containing the assembler operation to identify the following data
!      as writable initialized data.  Normally ‘"\t.data"’ is right.
  
   -- Macro: SDATA_SECTION_ASM_OP
       If defined, a C expression whose value is a string, including
*************** target does not provide them.
*** 39636,39644 ****
       If defined, a C expression whose value is a string, including
       spacing, containing the assembler operation to identify the
       following data as uninitialized global data.  If not defined, and
!      'ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data
!      will be output in the data section if '-fno-common' is passed,
!      otherwise 'ASM_OUTPUT_COMMON' will be used.
  
   -- Macro: SBSS_SECTION_ASM_OP
       If defined, a C expression whose value is a string, including
--- 39635,39643 ----
       If defined, a C expression whose value is a string, including
       spacing, containing the assembler operation to identify the
       following data as uninitialized global data.  If not defined, and
!      ‘ASM_OUTPUT_ALIGNED_BSS’ not defined, uninitialized global data
!      will be output in the data section if ‘-fno-common’ is passed,
!      otherwise ‘ASM_OUTPUT_COMMON’ will be used.
  
   -- Macro: SBSS_SECTION_ASM_OP
       If defined, a C expression whose value is a string, including
*************** target does not provide them.
*** 39648,39666 ****
   -- Macro: TLS_COMMON_ASM_OP
       If defined, a C expression whose value is a string containing the
       assembler operation to identify the following data as thread-local
!      common data.  The default is '".tls_common"'.
  
   -- Macro: TLS_SECTION_ASM_FLAG
       If defined, a C expression whose value is a character constant
       containing the flag used to mark a section as a TLS section.  The
!      default is ''T''.
  
   -- Macro: INIT_SECTION_ASM_OP
       If defined, a C expression whose value is a string, including
       spacing, containing the assembler operation to identify the
       following data as initialization code.  If not defined, GCC will
       assume such a section does not exist.  This section has no
!      corresponding 'init_section' variable; it is used entirely in
       runtime code.
  
   -- Macro: FINI_SECTION_ASM_OP
--- 39647,39665 ----
   -- Macro: TLS_COMMON_ASM_OP
       If defined, a C expression whose value is a string containing the
       assembler operation to identify the following data as thread-local
!      common data.  The default is ‘".tls_common"’.
  
   -- Macro: TLS_SECTION_ASM_FLAG
       If defined, a C expression whose value is a character constant
       containing the flag used to mark a section as a TLS section.  The
!      default is ‘'T'’.
  
   -- Macro: INIT_SECTION_ASM_OP
       If defined, a C expression whose value is a string, including
       spacing, containing the assembler operation to identify the
       following data as initialization code.  If not defined, GCC will
       assume such a section does not exist.  This section has no
!      corresponding ‘init_section’ variable; it is used entirely in
       runtime code.
  
   -- Macro: FINI_SECTION_ASM_OP
*************** target does not provide them.
*** 39668,39700 ****
       spacing, containing the assembler operation to identify the
       following data as finalization code.  If not defined, GCC will
       assume such a section does not exist.  This section has no
!      corresponding 'fini_section' variable; it is used entirely in
       runtime code.
  
   -- Macro: INIT_ARRAY_SECTION_ASM_OP
       If defined, a C expression whose value is a string, including
       spacing, containing the assembler operation to identify the
!      following data as part of the '.init_array' (or equivalent)
       section.  If not defined, GCC will assume such a section does not
!      exist.  Do not define both this macro and 'INIT_SECTION_ASM_OP'.
  
   -- Macro: FINI_ARRAY_SECTION_ASM_OP
       If defined, a C expression whose value is a string, including
       spacing, containing the assembler operation to identify the
!      following data as part of the '.fini_array' (or equivalent)
       section.  If not defined, GCC will assume such a section does not
!      exist.  Do not define both this macro and 'FINI_SECTION_ASM_OP'.
  
   -- Macro: MACH_DEP_SECTION_ASM_FLAG
       If defined, a C expression whose value is a character constant
       containing the flag used to mark a machine-dependent section.  This
!      corresponds to the 'SECTION_MACH_DEP' section flag.
  
   -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION)
       If defined, an ASM statement that switches to a different section
       via SECTION_OP, calls FUNCTION, and switches back to the text
!      section.  This is used in 'crtstuff.c' if 'INIT_SECTION_ASM_OP' or
!      'FINI_SECTION_ASM_OP' to calls to initialization and finalization
       functions from the init and fini sections.  By default, this macro
       uses a simple function call.  Some ports need hand-crafted assembly
       code to avoid dependencies on registers initialized in the function
--- 39667,39699 ----
       spacing, containing the assembler operation to identify the
       following data as finalization code.  If not defined, GCC will
       assume such a section does not exist.  This section has no
!      corresponding ‘fini_section’ variable; it is used entirely in
       runtime code.
  
   -- Macro: INIT_ARRAY_SECTION_ASM_OP
       If defined, a C expression whose value is a string, including
       spacing, containing the assembler operation to identify the
!      following data as part of the ‘.init_array’ (or equivalent)
       section.  If not defined, GCC will assume such a section does not
!      exist.  Do not define both this macro and ‘INIT_SECTION_ASM_OP’.
  
   -- Macro: FINI_ARRAY_SECTION_ASM_OP
       If defined, a C expression whose value is a string, including
       spacing, containing the assembler operation to identify the
!      following data as part of the ‘.fini_array’ (or equivalent)
       section.  If not defined, GCC will assume such a section does not
!      exist.  Do not define both this macro and ‘FINI_SECTION_ASM_OP’.
  
   -- Macro: MACH_DEP_SECTION_ASM_FLAG
       If defined, a C expression whose value is a character constant
       containing the flag used to mark a machine-dependent section.  This
!      corresponds to the ‘SECTION_MACH_DEP’ section flag.
  
   -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION)
       If defined, an ASM statement that switches to a different section
       via SECTION_OP, calls FUNCTION, and switches back to the text
!      section.  This is used in ‘crtstuff.c’ if ‘INIT_SECTION_ASM_OP’ or
!      ‘FINI_SECTION_ASM_OP’ to calls to initialization and finalization
       functions from the init and fini sections.  By default, this macro
       uses a simple function call.  Some ports need hand-crafted assembly
       code to avoid dependencies on registers initialized in the function
*************** target does not provide them.
*** 39707,39728 ****
       when the target has options for optimizing access to small data,
       and you want the crtstuff and libgcc routines to be conservative in
       what they expect of your application yet liberal in what your
!      application expects.  For example, for targets with a '.sdata'
!      section (like MIPS), you could compile crtstuff with '-G 0' so that
       it doesn't require small data support from your application, but
!      use this macro to put small data into '.sdata' so that your
       application can access these variables whether it uses small data
       or not.
  
   -- Macro: FORCE_CODE_SECTION_ALIGN
       If defined, an ASM statement that aligns a code section to some
       arbitrary boundary.  This is used to force all fragments of the
!      '.init' and '.fini' sections to have to same alignment and thus
       prevent the linker from having to add any padding.
  
   -- Macro: JUMP_TABLES_IN_TEXT_SECTION
       Define this macro to be an expression with a nonzero value if jump
!      tables (for 'tablejump' insns) should be output in the text
       section, along with the assembler instructions.  Otherwise, the
       readonly data section is used.
  
--- 39706,39727 ----
       when the target has options for optimizing access to small data,
       and you want the crtstuff and libgcc routines to be conservative in
       what they expect of your application yet liberal in what your
!      application expects.  For example, for targets with a ‘.sdata’
!      section (like MIPS), you could compile crtstuff with ‘-G 0’ so that
       it doesn't require small data support from your application, but
!      use this macro to put small data into ‘.sdata’ so that your
       application can access these variables whether it uses small data
       or not.
  
   -- Macro: FORCE_CODE_SECTION_ALIGN
       If defined, an ASM statement that aligns a code section to some
       arbitrary boundary.  This is used to force all fragments of the
!      ‘.init’ and ‘.fini’ sections to have to same alignment and thus
       prevent the linker from having to add any padding.
  
   -- Macro: JUMP_TABLES_IN_TEXT_SECTION
       Define this macro to be an expression with a nonzero value if jump
!      tables (for ‘tablejump’ insns) should be output in the text
       section, along with the assembler instructions.  Otherwise, the
       readonly data section is used.
  
*************** target does not provide them.
*** 39731,39737 ****
  
   -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void)
       Define this hook if you need to do something special to set up the
!      'varasm.cc' sections, or if your target has some special sections
       of its own that you need to create.
  
       GCC calls this hook after processing the command line, but before
--- 39730,39736 ----
  
   -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void)
       Define this hook if you need to do something special to set up the
!      ‘varasm.cc’ sections, or if your target has some special sections
       of its own that you need to create.
  
       GCC calls this hook after processing the command line, but before
*************** target does not provide them.
*** 39744,39750 ****
       should be placed in a read-write section; bit 0 should be set if
       local relocations should be placed in a read-write section.
  
!      The default version of this function returns 3 when '-fpic' is in
       effect, and 0 otherwise.  The hook is typically redefined when the
       target cannot support (some kinds of) dynamic relocations in
       read-only sections even in executables.
--- 39743,39749 ----
       should be placed in a read-write section; bit 0 should be set if
       local relocations should be placed in a read-write section.
  
!      The default version of this function returns 3 when ‘-fpic’ is in
       effect, and 0 otherwise.  The hook is typically redefined when the
       target cannot support (some kinds of) dynamic relocations in
       read-only sections even in executables.
*************** target does not provide them.
*** 39759,39807 ****
   -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int
            RELOC, unsigned HOST_WIDE_INT ALIGN)
       Return the section into which EXP should be placed.  You can assume
!      that EXP is either a 'VAR_DECL' node or a constant of some sort.
       RELOC indicates whether the initial value of EXP requires link-time
       relocations.  Bit 0 is set when variable contains local relocations
       only, while bit 1 is set for global relocations.  ALIGN is the
       constant alignment in bits.
  
       The default version of this function takes care of putting
!      read-only variables in 'readonly_data_section'.
  
       See also USE_SELECT_SECTION_FOR_FUNCTIONS.
  
   -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS
       Define this macro if you wish TARGET_ASM_SELECT_SECTION to be
!      called for 'FUNCTION_DECL's as well as for variables and constants.
  
!      In the case of a 'FUNCTION_DECL', RELOC will be zero if the
       function has been determined to be likely to be called, and nonzero
       if it is unlikely to be called.
  
   -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC)
!      Build up a unique section name, expressed as a 'STRING_CST' node,
!      and assign it to 'DECL_SECTION_NAME (DECL)'.  As with
!      'TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial
       value of EXP requires link-time relocations.
  
       The default version of this function appends the symbol name to the
       ELF section name that would normally be used for the symbol.  For
!      example, the function 'foo' would be placed in '.text.foo'.
       Whatever the actual target object format, this is often good
       enough.
  
   -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree
            DECL, bool RELOCATABLE)
       Return the readonly data or reloc readonly data section associated
!      with 'DECL_SECTION_NAME (DECL)'.  RELOCATABLE selects the latter
       over the former.  The default version of this function selects
!      '.gnu.linkonce.r.name' if the function's section is
!      '.gnu.linkonce.t.name', '.rodata.name' or '.data.rel.ro.name' if
!      function is in '.text.name', and the normal readonly-data or reloc
       readonly data section otherwise.
  
   -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX
!      Usually, the compiler uses the prefix '".rodata"' to construct
       section names for mergeable constant data.  Define this macro to
       override the string if a different section name should be used.
  
--- 39758,39806 ----
   -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int
            RELOC, unsigned HOST_WIDE_INT ALIGN)
       Return the section into which EXP should be placed.  You can assume
!      that EXP is either a ‘VAR_DECL’ node or a constant of some sort.
       RELOC indicates whether the initial value of EXP requires link-time
       relocations.  Bit 0 is set when variable contains local relocations
       only, while bit 1 is set for global relocations.  ALIGN is the
       constant alignment in bits.
  
       The default version of this function takes care of putting
!      read-only variables in ‘readonly_data_section’.
  
       See also USE_SELECT_SECTION_FOR_FUNCTIONS.
  
   -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS
       Define this macro if you wish TARGET_ASM_SELECT_SECTION to be
!      called for ‘FUNCTION_DECL’s as well as for variables and constants.
  
!      In the case of a ‘FUNCTION_DECL’, RELOC will be zero if the
       function has been determined to be likely to be called, and nonzero
       if it is unlikely to be called.
  
   -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC)
!      Build up a unique section name, expressed as a ‘STRING_CST’ node,
!      and assign it to ‘DECL_SECTION_NAME (DECL)’.  As with
!      ‘TARGET_ASM_SELECT_SECTION’, RELOC indicates whether the initial
       value of EXP requires link-time relocations.
  
       The default version of this function appends the symbol name to the
       ELF section name that would normally be used for the symbol.  For
!      example, the function ‘foo’ would be placed in ‘.text.foo’.
       Whatever the actual target object format, this is often good
       enough.
  
   -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree
            DECL, bool RELOCATABLE)
       Return the readonly data or reloc readonly data section associated
!      with ‘DECL_SECTION_NAME (DECL)’.  RELOCATABLE selects the latter
       over the former.  The default version of this function selects
!      ‘.gnu.linkonce.r.name’ if the function's section is
!      ‘.gnu.linkonce.t.name’, ‘.rodata.name’ or ‘.data.rel.ro.name’ if
!      function is in ‘.text.name’, and the normal readonly-data or reloc
       readonly data section otherwise.
  
   -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX
!      Usually, the compiler uses the prefix ‘".rodata"’ to construct
       section names for mergeable constant data.  Define this macro to
       override the string if a different section name should be used.
  
*************** target does not provide them.
*** 39813,39832 ****
            MODE, rtx X, unsigned HOST_WIDE_INT ALIGN)
       Return the section into which a constant X, of mode MODE, should be
       placed.  You can assume that X is some kind of constant in RTL.
!      The argument MODE is redundant except in the case of a 'const_int'
       rtx.  ALIGN is the constant alignment in bits.
  
       The default version of this function takes care of putting symbolic
!      constants in 'flag_pic' mode in 'data_section' and everything else
!      in 'readonly_data_section'.
  
   -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, tree
            ID)
       Define this hook if you need to postprocess the assembler name
       generated by target-independent code.  The ID provided to this hook
!      will be the computed name (e.g., the macro 'DECL_NAME' of the DECL
       in C, or the mangled name of the DECL in C++).  The return value of
!      the hook is an 'IDENTIFIER_NODE' for the appropriate mangled name
       on your target system.  The default implementation of this hook
       just returns the ID provided.
  
--- 39812,39831 ----
            MODE, rtx X, unsigned HOST_WIDE_INT ALIGN)
       Return the section into which a constant X, of mode MODE, should be
       placed.  You can assume that X is some kind of constant in RTL.
!      The argument MODE is redundant except in the case of a ‘const_int’
       rtx.  ALIGN is the constant alignment in bits.
  
       The default version of this function takes care of putting symbolic
!      constants in ‘flag_pic’ mode in ‘data_section’ and everything else
!      in ‘readonly_data_section’.
  
   -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, tree
            ID)
       Define this hook if you need to postprocess the assembler name
       generated by target-independent code.  The ID provided to this hook
!      will be the computed name (e.g., the macro ‘DECL_NAME’ of the DECL
       in C, or the mangled name of the DECL in C++).  The return value of
!      the hook is an ‘IDENTIFIER_NODE’ for the appropriate mangled name
       on your target system.  The default implementation of this hook
       just returns the ID provided.
  
*************** target does not provide them.
*** 39839,39876 ****
       The hook is executed immediately after rtl has been created for
       DECL, which may be a variable or function declaration or an entry
       in the constant pool.  In either case, RTL is the rtl in question.
!      Do _not_ use 'DECL_RTL (DECL)' in this hook; that field may not
       have been initialized yet.
  
       In the case of a constant, it is safe to assume that the rtl is a
!      'mem' whose address is a 'symbol_ref'.  Most decls will also have
       this form, but that is not guaranteed.  Global register variables,
!      for instance, will have a 'reg' for their rtl.  (Normally the right
       thing to do with such unusual rtl is leave it alone.)
  
       The NEW_DECL_P argument will be true if this is the first time that
!      'TARGET_ENCODE_SECTION_INFO' has been invoked on this decl.  It
       will be false for subsequent invocations, which will happen for
       duplicate declarations.  Whether or not anything must be done for
       the duplicate declaration depends on whether the hook examines
!      'DECL_ATTRIBUTES'.  NEW_DECL_P is always true when the hook is
       called for a constant.
  
       The usual thing for this hook to do is to record flags in the
!      'symbol_ref', using 'SYMBOL_REF_FLAG' or 'SYMBOL_REF_FLAGS'.
       Historically, the name string was modified if it was necessary to
       encode more than one bit of information, but this practice is now
!      discouraged; use 'SYMBOL_REF_FLAGS'.
  
!      The default definition of this hook, 'default_encode_section_info'
!      in 'varasm.cc', sets a number of commonly-useful bits in
!      'SYMBOL_REF_FLAGS'.  Check whether the default does what you need
       before overriding it.
  
   -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char
            *NAME)
       Decode NAME and return the real name part, sans the characters that
!      'TARGET_ENCODE_SECTION_INFO' may have added.
  
   -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP)
       Returns true if EXP should be placed into a "small data" section.
--- 39838,39875 ----
       The hook is executed immediately after rtl has been created for
       DECL, which may be a variable or function declaration or an entry
       in the constant pool.  In either case, RTL is the rtl in question.
!      Do _not_ use ‘DECL_RTL (DECL)’ in this hook; that field may not
       have been initialized yet.
  
       In the case of a constant, it is safe to assume that the rtl is a
!      ‘mem’ whose address is a ‘symbol_ref’.  Most decls will also have
       this form, but that is not guaranteed.  Global register variables,
!      for instance, will have a ‘reg’ for their rtl.  (Normally the right
       thing to do with such unusual rtl is leave it alone.)
  
       The NEW_DECL_P argument will be true if this is the first time that
!      ‘TARGET_ENCODE_SECTION_INFO’ has been invoked on this decl.  It
       will be false for subsequent invocations, which will happen for
       duplicate declarations.  Whether or not anything must be done for
       the duplicate declaration depends on whether the hook examines
!      ‘DECL_ATTRIBUTES’.  NEW_DECL_P is always true when the hook is
       called for a constant.
  
       The usual thing for this hook to do is to record flags in the
!      ‘symbol_ref’, using ‘SYMBOL_REF_FLAG’ or ‘SYMBOL_REF_FLAGS’.
       Historically, the name string was modified if it was necessary to
       encode more than one bit of information, but this practice is now
!      discouraged; use ‘SYMBOL_REF_FLAGS’.
  
!      The default definition of this hook, ‘default_encode_section_info’
!      in ‘varasm.cc’, sets a number of commonly-useful bits in
!      ‘SYMBOL_REF_FLAGS’.  Check whether the default does what you need
       before overriding it.
  
   -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char
            *NAME)
       Decode NAME and return the real name part, sans the characters that
!      ‘TARGET_ENCODE_SECTION_INFO’ may have added.
  
   -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP)
       Returns true if EXP should be placed into a "small data" section.
*************** target does not provide them.
*** 39885,39891 ****
       prologue.
  
       The default version of this hook use the target macro
!      'PROFILE_BEFORE_PROLOGUE'.
  
   -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP)
       Returns true if EXP names an object for which name resolution rules
--- 39884,39890 ----
       prologue.
  
       The default version of this hook use the target macro
!      ‘PROFILE_BEFORE_PROLOGUE’.
  
   -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP)
       Returns true if EXP names an object for which name resolution rules
*************** File: gccint.info,  Node: PIC,  Next: As
*** 39909,39917 ****
  This section describes macros that help implement generation of position
  independent code.  Simply defining these macros is not enough to
  generate valid PIC; you must also add support to the hook
! 'TARGET_LEGITIMATE_ADDRESS_P' and to the macro 'PRINT_OPERAND_ADDRESS',
! as well as 'LEGITIMIZE_ADDRESS'.  You must modify the definition of
! 'movsi' to do something appropriate when the source operand contains a
  symbolic address.  You may also need to alter the handling of switch
  statements so that they use relative addresses.
  
--- 39908,39916 ----
  This section describes macros that help implement generation of position
  independent code.  Simply defining these macros is not enough to
  generate valid PIC; you must also add support to the hook
! ‘TARGET_LEGITIMATE_ADDRESS_P’ and to the macro ‘PRINT_OPERAND_ADDRESS’,
! as well as ‘LEGITIMIZE_ADDRESS’.  You must modify the definition of
! ‘movsi’ to do something appropriate when the source operand contains a
  symbolic address.  You may also need to alter the handling of switch
  statements so that they use relative addresses.
  
*************** statements so that they use relative add
*** 39923,39943 ****
       once, as with the stack pointer and frame pointer registers.  If
       this macro is not defined, it is up to the machine-dependent files
       to allocate such a register (if necessary).  Note that this
!      register must be fixed when in use (e.g. when 'flag_pic' is true).
  
   -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
       A C expression that is nonzero if the register defined by
!      'PIC_OFFSET_TABLE_REGNUM' is clobbered by calls.  If not defined,
       the default is zero.  Do not define this macro if
!      'PIC_OFFSET_TABLE_REGNUM' is not defined.
  
   -- Macro: LEGITIMATE_PIC_OPERAND_P (X)
       A C expression that is nonzero if X is a legitimate immediate
       operand on the target machine when generating position independent
!      code.  You can assume that X satisfies 'CONSTANT_P', so you need
       not check this.  You can also assume FLAG_PIC is true, so you need
       not check it either.  You need not define this macro if all
!      constants (including 'SYMBOL_REF') can be immediate operands when
       generating position independent code.
  
  
--- 39922,39942 ----
       once, as with the stack pointer and frame pointer registers.  If
       this macro is not defined, it is up to the machine-dependent files
       to allocate such a register (if necessary).  Note that this
!      register must be fixed when in use (e.g. when ‘flag_pic’ is true).
  
   -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
       A C expression that is nonzero if the register defined by
!      ‘PIC_OFFSET_TABLE_REGNUM’ is clobbered by calls.  If not defined,
       the default is zero.  Do not define this macro if
!      ‘PIC_OFFSET_TABLE_REGNUM’ is not defined.
  
   -- Macro: LEGITIMATE_PIC_OPERAND_P (X)
       A C expression that is nonzero if X is a legitimate immediate
       operand on the target machine when generating position independent
!      code.  You can assume that X satisfies ‘CONSTANT_P’, so you need
       not check this.  You can also assume FLAG_PIC is true, so you need
       not check it either.  You need not define this macro if all
!      constants (including ‘SYMBOL_REF’) can be immediate operands when
       generating position independent code.
  
  
*************** File: gccint.info,  Node: File Framework
*** 39975,39993 ****
  This describes the overall framework of an assembly file.
  
   -- Target Hook: void TARGET_ASM_FILE_START (void)
!      Output to 'asm_out_file' any text which the assembler expects to
       find at the beginning of a file.  The default behavior is
       controlled by two flags, documented below.  Unless your target's
       assembler is quite unusual, if you override the default, you should
!      call 'default_file_start' at some point in your target hook.  This
       lets other target files rely on these variables.
  
   -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF
!      If this flag is true, the text of the macro 'ASM_APP_OFF' will be
       printed as the very first line in the assembly file, unless
!      '-fverbose-asm' is in effect.  (If that macro has been defined to
       the empty string, this variable has no effect.)  With the normal
!      definition of 'ASM_APP_OFF', the effect is to notify the GNU
       assembler that it need not bother stripping comments or extra
       whitespace from its input.  This allows it to work a bit faster.
  
--- 39974,39992 ----
  This describes the overall framework of an assembly file.
  
   -- Target Hook: void TARGET_ASM_FILE_START (void)
!      Output to ‘asm_out_file’ any text which the assembler expects to
       find at the beginning of a file.  The default behavior is
       controlled by two flags, documented below.  Unless your target's
       assembler is quite unusual, if you override the default, you should
!      call ‘default_file_start’ at some point in your target hook.  This
       lets other target files rely on these variables.
  
   -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF
!      If this flag is true, the text of the macro ‘ASM_APP_OFF’ will be
       printed as the very first line in the assembly file, unless
!      ‘-fverbose-asm’ is in effect.  (If that macro has been defined to
       the empty string, this variable has no effect.)  With the normal
!      definition of ‘ASM_APP_OFF’, the effect is to notify the GNU
       assembler that it need not bother stripping comments or extra
       whitespace from its input.  This allows it to work a bit faster.
  
*************** This describes the overall framework of
*** 39996,40030 ****
       or comments that will cause GAS to issue errors in NO_APP mode.
  
   -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE
!      If this flag is true, 'output_file_directive' will be called for
!      the primary source file, immediately after printing 'ASM_APP_OFF'
       (if that is enabled).  Most ELF assemblers expect this to be done.
       The default is false.
  
   -- Target Hook: void TARGET_ASM_FILE_END (void)
!      Output to 'asm_out_file' any text which the assembler expects to
       find at the end of a file.  The default is to output nothing.
  
   -- Function: void file_end_indicate_exec_stack ()
!      Some systems use a common convention, the '.note.GNU-stack' special
       section, to indicate whether or not an object file relies on the
       stack being executable.  If your system uses this convention, you
!      should define 'TARGET_ASM_FILE_END' to this function.  If you need
       to do other things in that hook, have your hook function call this
       function.
  
   -- Target Hook: void TARGET_ASM_LTO_START (void)
!      Output to 'asm_out_file' any text which the assembler expects to
       find at the start of an LTO section.  The default is to output
       nothing.
  
   -- Target Hook: void TARGET_ASM_LTO_END (void)
!      Output to 'asm_out_file' any text which the assembler expects to
       find at the end of an LTO section.  The default is to output
       nothing.
  
   -- Target Hook: void TARGET_ASM_CODE_END (void)
!      Output to 'asm_out_file' any text which is needed before emitting
       unwind info and debug info at the end of a file.  Some targets emit
       here PIC setup thunks that cannot be emitted at the end of file,
       because they couldn't have unwind info then.  The default is to
--- 39995,40029 ----
       or comments that will cause GAS to issue errors in NO_APP mode.
  
   -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE
!      If this flag is true, ‘output_file_directive’ will be called for
!      the primary source file, immediately after printing ‘ASM_APP_OFF’
       (if that is enabled).  Most ELF assemblers expect this to be done.
       The default is false.
  
   -- Target Hook: void TARGET_ASM_FILE_END (void)
!      Output to ‘asm_out_file’ any text which the assembler expects to
       find at the end of a file.  The default is to output nothing.
  
   -- Function: void file_end_indicate_exec_stack ()
!      Some systems use a common convention, the ‘.note.GNU-stack’ special
       section, to indicate whether or not an object file relies on the
       stack being executable.  If your system uses this convention, you
!      should define ‘TARGET_ASM_FILE_END’ to this function.  If you need
       to do other things in that hook, have your hook function call this
       function.
  
   -- Target Hook: void TARGET_ASM_LTO_START (void)
!      Output to ‘asm_out_file’ any text which the assembler expects to
       find at the start of an LTO section.  The default is to output
       nothing.
  
   -- Target Hook: void TARGET_ASM_LTO_END (void)
!      Output to ‘asm_out_file’ any text which the assembler expects to
       find at the end of an LTO section.  The default is to output
       nothing.
  
   -- Target Hook: void TARGET_ASM_CODE_END (void)
!      Output to ‘asm_out_file’ any text which is needed before emitting
       unwind info and debug info at the end of a file.  Some targets emit
       here PIC setup thunks that cannot be emitted at the end of file,
       because they couldn't have unwind info then.  The default is to
*************** This describes the overall framework of
*** 40036,40051 ****
       at the end of the line.
  
   -- Macro: ASM_APP_ON
!      A C string constant for text to be output before each 'asm'
!      statement or group of consecutive ones.  Normally this is '"#APP"',
       which is a comment that has no effect on most assemblers but tells
       the GNU assembler that it must check the lines that follow for all
       valid assembler constructs.
  
   -- Macro: ASM_APP_OFF
!      A C string constant for text to be output after each 'asm'
       statement or group of consecutive ones.  Normally this is
!      '"#NO_APP"', which tells the GNU assembler to resume making the
       time-saving assumptions that are valid for ordinary compiler
       output.
  
--- 40035,40050 ----
       at the end of the line.
  
   -- Macro: ASM_APP_ON
!      A C string constant for text to be output before each ‘asm’
!      statement or group of consecutive ones.  Normally this is ‘"#APP"’,
       which is a comment that has no effect on most assemblers but tells
       the GNU assembler that it must check the lines that follow for all
       valid assembler constructs.
  
   -- Macro: ASM_APP_OFF
!      A C string constant for text to be output after each ‘asm’
       statement or group of consecutive ones.  Normally this is
!      ‘"#NO_APP"’, which tells the GNU assembler to resume making the
       time-saving assumptions that are valid for ordinary compiler
       output.
  
*************** This describes the overall framework of
*** 40066,40079 ****
       for the file format in use is appropriate.
  
   -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME)
!      Output a string based on NAME, suitable for the '#ident' directive,
       or the equivalent directive or pragma in non-C-family languages.
!      If this hook is not defined, nothing is output for the '#ident'
       directive.
  
   -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING)
       A C statement to output the string STRING to the stdio stream
!      STREAM.  If you do not call the function 'output_quoted_string' in
       your config files, GCC will only call it to output filenames to the
       assembler source.  So you can use it to canonicalize the format of
       the filename using this macro.
--- 40065,40078 ----
       for the file format in use is appropriate.
  
   -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME)
!      Output a string based on NAME, suitable for the ‘#ident’ directive,
       or the equivalent directive or pragma in non-C-family languages.
!      If this hook is not defined, nothing is output for the ‘#ident’
       directive.
  
   -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING)
       A C statement to output the string STRING to the stdio stream
!      STREAM.  If you do not call the function ‘output_quoted_string’ in
       your config files, GCC will only call it to output filenames to the
       assembler source.  So you can use it to canonicalize the format of
       the filename using this macro.
*************** This describes the overall framework of
*** 40082,40096 ****
            unsigned int FLAGS, tree DECL)
       Output assembly directives to switch to section NAME.  The section
       should have attributes as specified by FLAGS, which is a bit mask
!      of the 'SECTION_*' flags defined in 'output.h'.  If DECL is
!      non-NULL, it is the 'VAR_DECL' or 'FUNCTION_DECL' with which this
       section is associated.
  
   -- Target Hook: bool TARGET_ASM_ELF_FLAGS_NUMERIC (unsigned int FLAGS,
            unsigned int *NUM)
       This hook can be used to encode ELF section flags for which no
       letter code has been defined in the assembler.  It is called by
!      'default_asm_named_section' whenever the section flags need to be
       emitted in the assembler output.  If the hook returns true, then
       the numerical value for ELF section flags should be calculated from
       FLAGS and saved in *NUM; the value is printed out instead of the
--- 40081,40095 ----
            unsigned int FLAGS, tree DECL)
       Output assembly directives to switch to section NAME.  The section
       should have attributes as specified by FLAGS, which is a bit mask
!      of the ‘SECTION_*’ flags defined in ‘output.h’.  If DECL is
!      non-NULL, it is the ‘VAR_DECL’ or ‘FUNCTION_DECL’ with which this
       section is associated.
  
   -- Target Hook: bool TARGET_ASM_ELF_FLAGS_NUMERIC (unsigned int FLAGS,
            unsigned int *NUM)
       This hook can be used to encode ELF section flags for which no
       letter code has been defined in the assembler.  It is called by
!      ‘default_asm_named_section’ whenever the section flags need to be
       emitted in the assembler output.  If the hook returns true, then
       the numerical value for ELF section flags should be calculated from
       FLAGS and saved in *NUM; the value is printed out instead of the
*************** This describes the overall framework of
*** 40103,40109 ****
       Return preferred text (sub)section for function DECL.  Main purpose
       of this function is to separate cold, normal and hot functions.
       STARTUP is true when function is known to be used only at startup
!      (from static constructors or it is 'main()').  EXIT is true when
       function is known to be used only at exit (from static
       destructors).  Return NULL if function should go to default text
       section.
--- 40102,40108 ----
       Return preferred text (sub)section for function DECL.  Main purpose
       of this function is to separate cold, normal and hot functions.
       STARTUP is true when function is known to be used only at startup
!      (from static constructors or it is ‘main()’).  EXIT is true when
       function is known to be used only at exit (from static
       destructors).  Return NULL if function should go to default text
       section.
*************** This describes the overall framework of
*** 40114,40143 ****
       labels needed when a function is partitioned between different
       sections.  Output should be written to FILE.  The function decl is
       available as DECL and the new section is 'cold' if NEW_IS_COLD is
!      'true'.
  
   -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS
       This flag is true if the target supports
!      'TARGET_ASM_NAMED_SECTION'.  It must not be modified by
       command-line option processing.
  
   -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS
       This flag is true if we can create zeroed data by switching to a
!      BSS section and then using 'ASM_OUTPUT_SKIP' to allocate the space.
       This is true on most ELF targets.
  
   -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL,
            const char *NAME, int RELOC)
       Choose a set of section attributes for use by
!      'TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a
       section name, and whether or not the declaration's initializer may
       contain runtime relocations.  DECL may be null, in which case
       read-write data should be assumed.
  
       The default version of this function handles choosing code vs data,
!      read-only vs read-write data, and 'flag_pic'.  You should only need
       to override this if your target has special flags that might be set
!      via '__attribute__'.
  
   -- Target Hook: void TARGET_ASM_RECORD_GCC_SWITCHES (const char *)
       Provides the target with the ability to record the gcc command line
--- 40113,40142 ----
       labels needed when a function is partitioned between different
       sections.  Output should be written to FILE.  The function decl is
       available as DECL and the new section is 'cold' if NEW_IS_COLD is
!      ‘true’.
  
   -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS
       This flag is true if the target supports
!      ‘TARGET_ASM_NAMED_SECTION’.  It must not be modified by
       command-line option processing.
  
   -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS
       This flag is true if we can create zeroed data by switching to a
!      BSS section and then using ‘ASM_OUTPUT_SKIP’ to allocate the space.
       This is true on most ELF targets.
  
   -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL,
            const char *NAME, int RELOC)
       Choose a set of section attributes for use by
!      ‘TARGET_ASM_NAMED_SECTION’ based on a variable or function decl, a
       section name, and whether or not the declaration's initializer may
       contain runtime relocations.  DECL may be null, in which case
       read-write data should be assumed.
  
       The default version of this function handles choosing code vs data,
!      read-only vs read-write data, and ‘flag_pic’.  You should only need
       to override this if your target has special flags that might be set
!      via ‘__attribute__’.
  
   -- Target Hook: void TARGET_ASM_RECORD_GCC_SWITCHES (const char *)
       Provides the target with the ability to record the gcc command line
*************** This describes the overall framework of
*** 40148,40158 ****
       it records the switches as ASCII text inside a new, string
       mergeable section in the assembler output file.  The name of the
       new section is provided by the
!      'TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook.
  
   -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION
       This is the name of the section that will be created by the example
!      ELF implementation of the 'TARGET_ASM_RECORD_GCC_SWITCHES' target
       hook.
  
  
--- 40147,40157 ----
       it records the switches as ASCII text inside a new, string
       mergeable section in the assembler output file.  The name of the
       new section is provided by the
!      ‘TARGET_ASM_RECORD_GCC_SWITCHES_SECTION’ target hook.
  
   -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION
       This is the name of the section that will be created by the example
!      ELF implementation of the ‘TARGET_ASM_RECORD_GCC_SWITCHES’ target
       hook.
  
  
*************** File: gccint.info,  Node: Data Output,
*** 40177,40186 ****
   -- Target Hook: const char * TARGET_ASM_UNALIGNED_PTI_OP
   -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP
       These hooks specify assembly directives for creating certain kinds
!      of integer object.  The 'TARGET_ASM_BYTE_OP' directive creates a
!      byte-sized object, the 'TARGET_ASM_ALIGNED_HI_OP' one creates an
       aligned two-byte object, and so on.  Any of the hooks may be
!      'NULL', indicating that no suitable directive is available.
  
       The compiler will print these strings at the start of a new line,
       followed immediately by the object's initial value.  In most cases,
--- 40176,40185 ----
   -- Target Hook: const char * TARGET_ASM_UNALIGNED_PTI_OP
   -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP
       These hooks specify assembly directives for creating certain kinds
!      of integer object.  The ‘TARGET_ASM_BYTE_OP’ directive creates a
!      byte-sized object, the ‘TARGET_ASM_ALIGNED_HI_OP’ one creates an
       aligned two-byte object, and so on.  Any of the hooks may be
!      ‘NULL’, indicating that no suitable directive is available.
  
       The compiler will print these strings at the start of a new line,
       followed immediately by the object's initial value.  In most cases,
*************** File: gccint.info,  Node: Data Output,
*** 40188,40203 ****
  
   -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int
            ALIGNED_P)
!      The 'assemble_integer' function uses this hook to output an integer
       object.  X is the object's value, SIZE is its size in bytes and
       ALIGNED_P indicates whether it is aligned.  The function should
!      return 'true' if it was able to output the object.  If it returns
!      false, 'assemble_integer' will try to split the object into smaller
       parts.
  
       The default implementation of this hook will use the
!      'TARGET_ASM_BYTE_OP' family of strings, returning 'false' when the
!      relevant string is 'NULL'.
  
   -- Target Hook: void TARGET_ASM_DECL_END (void)
       Define this hook if the target assembler requires a special marker
--- 40187,40202 ----
  
   -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int
            ALIGNED_P)
!      The ‘assemble_integer’ function uses this hook to output an integer
       object.  X is the object's value, SIZE is its size in bytes and
       ALIGNED_P indicates whether it is aligned.  The function should
!      return ‘true’ if it was able to output the object.  If it returns
!      false, ‘assemble_integer’ will try to split the object into smaller
       parts.
  
       The default implementation of this hook will use the
!      ‘TARGET_ASM_BYTE_OP’ family of strings, returning ‘false’ when the
!      relevant string is ‘NULL’.
  
   -- Target Hook: void TARGET_ASM_DECL_END (void)
       Define this hook if the target assembler requires a special marker
*************** File: gccint.info,  Node: Data Output,
*** 40205,40232 ****
  
   -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE,
            rtx X)
!      A target hook to recognize RTX patterns that 'output_addr_const'
       can't deal with, and output assembly code to FILE corresponding to
       the pattern X.  This may be used to allow machine-dependent
!      'UNSPEC's to appear within constants.
  
       If target hook fails to recognize a pattern, it must return
!      'false', so that a standard error message is printed.  If it prints
       an error message itself, by calling, for example,
!      'output_operand_lossage', it may just return 'true'.
  
   -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN)
       A C statement to output to the stdio stream STREAM an assembler
       instruction to assemble a string constant containing the LEN bytes
!      at PTR.  PTR will be a C expression of type 'char *' and LEN a C
!      expression of type 'int'.
  
!      If the assembler has a '.ascii' pseudo-op as found in the Berkeley
!      Unix assembler, do not define the macro 'ASM_OUTPUT_ASCII'.
  
   -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N)
       A C statement to output word N of a function descriptor for DECL.
!      This must be defined if 'TARGET_VTABLE_USES_DESCRIPTORS' is
       defined, and is otherwise unused.
  
   -- Macro: CONSTANT_POOL_BEFORE_FUNCTION
--- 40204,40231 ----
  
   -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE,
            rtx X)
!      A target hook to recognize RTX patterns that ‘output_addr_const’
       can't deal with, and output assembly code to FILE corresponding to
       the pattern X.  This may be used to allow machine-dependent
!      ‘UNSPEC’s to appear within constants.
  
       If target hook fails to recognize a pattern, it must return
!      ‘false’, so that a standard error message is printed.  If it prints
       an error message itself, by calling, for example,
!      ‘output_operand_lossage’, it may just return ‘true’.
  
   -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN)
       A C statement to output to the stdio stream STREAM an assembler
       instruction to assemble a string constant containing the LEN bytes
!      at PTR.  PTR will be a C expression of type ‘char *’ and LEN a C
!      expression of type ‘int’.
  
!      If the assembler has a ‘.ascii’ pseudo-op as found in the Berkeley
!      Unix assembler, do not define the macro ‘ASM_OUTPUT_ASCII’.
  
   -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N)
       A C statement to output word N of a function descriptor for DECL.
!      This must be defined if ‘TARGET_VTABLE_USES_DESCRIPTORS’ is
       defined, and is otherwise unused.
  
   -- Macro: CONSTANT_POOL_BEFORE_FUNCTION
*************** File: gccint.info,  Node: Data Output,
*** 40256,40262 ****
  
       The argument FILE is the standard I/O stream to output the
       assembler code on.  X is the RTL expression for the constant to
!      output, and MODE is the machine mode (in case X is a 'const_int').
       ALIGN is the required alignment for the value X; you should output
       an assembler directive to force this much alignment.
  
--- 40255,40261 ----
  
       The argument FILE is the standard I/O stream to output the
       assembler code on.  X is the RTL expression for the constant to
!      output, and MODE is the machine mode (in case X is a ‘const_int’).
       ALIGN is the required alignment for the value X; you should output
       an assembler directive to force this much alignment.
  
*************** File: gccint.info,  Node: Data Output,
*** 40268,40274 ****
            (*targetm.asm_out.internal_label) (FILE, "LC", LABELNO);
  
       When you output a pool entry specially, you should end with a
!      'goto' to the label JUMPTO.  This will prevent the same pool entry
       from being output a second time in the usual manner.
  
       You need not define this macro if it would do nothing.
--- 40267,40273 ----
            (*targetm.asm_out.internal_label) (FILE, "LC", LABELNO);
  
       When you output a pool entry specially, you should end with a
!      ‘goto’ to the label JUMPTO.  This will prevent the same pool entry
       from being output a second time in the usual manner.
  
       You need not define this macro if it would do nothing.
*************** File: gccint.info,  Node: Data Output,
*** 40291,40297 ****
       line separator uses multiple characters.
  
       If you do not define this macro, the default is that only the
!      character ';' is treated as a logical line separator.
  
   -- Target Hook: const char * TARGET_ASM_OPEN_PAREN
   -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN
--- 40290,40296 ----
       line separator uses multiple characters.
  
       If you do not define this macro, the default is that only the
!      character ‘;’ is treated as a logical line separator.
  
   -- Target Hook: const char * TARGET_ASM_OPEN_PAREN
   -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN
*************** File: gccint.info,  Node: Data Output,
*** 40300,40307 ****
       overridden, they default to normal parentheses, which is correct
       for most assemblers.
  
!  These macros are provided by 'real.h' for writing the definitions of
! 'ASM_OUTPUT_DOUBLE' and the like:
  
   -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L)
   -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L)
--- 40299,40306 ----
       overridden, they default to normal parentheses, which is correct
       for most assemblers.
  
!  These macros are provided by ‘real.h’ for writing the definitions of
! ‘ASM_OUTPUT_DOUBLE’ and the like:
  
   -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L)
   -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L)
*************** File: gccint.info,  Node: Data Output,
*** 40309,40327 ****
   -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L)
   -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L)
   -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L)
!      These translate X, of type 'REAL_VALUE_TYPE', to the target's
       floating point representation, and store its bit pattern in the
!      variable L.  For 'REAL_VALUE_TO_TARGET_SINGLE' and
!      'REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple
!      'long int'.  For the others, it should be an array of 'long int'.
       The number of elements in this array is determined by the size of
       the desired target floating point data type: 32 bits of it go in
!      each 'long int' array element.  Each array element holds 32 bits of
!      the result, even if 'long int' is wider than 32 bits on the host
       machine.
  
       The array element values are designed so that you can print them
!      out using 'fprintf' in the order they should appear in the target
       machine's memory.
  
  
--- 40308,40326 ----
   -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L)
   -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L)
   -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L)
!      These translate X, of type ‘REAL_VALUE_TYPE’, to the target's
       floating point representation, and store its bit pattern in the
!      variable L.  For ‘REAL_VALUE_TO_TARGET_SINGLE’ and
!      ‘REAL_VALUE_TO_TARGET_DECIMAL32’, this variable should be a simple
!      ‘long int’.  For the others, it should be an array of ‘long int’.
       The number of elements in this array is determined by the size of
       the desired target floating point data type: 32 bits of it go in
!      each ‘long int’ array element.  Each array element holds 32 bits of
!      the result, even if ‘long int’ is wider than 32 bits on the host
       machine.
  
       The array element values are designed so that you can print them
!      out using ‘fprintf’ in the order they should appear in the target
       machine's memory.
  
  
*************** outputting a single uninitialized variab
*** 40346,40352 ****
       the concept of a zero-sized common symbol, as that is how they
       represent an ordinary undefined external.
  
!      Use the expression 'assemble_name (STREAM, NAME)' to output the
       name itself; before and after that, output the additional assembler
       syntax for defining the name, and a newline.
  
--- 40345,40351 ----
       the concept of a zero-sized common symbol, as that is how they
       represent an ordinary undefined external.
  
!      Use the expression ‘assemble_name (STREAM, NAME)’ to output the
       name itself; before and after that, output the additional assembler
       syntax for defining the name, and a newline.
  
*************** outputting a single uninitialized variab
*** 40354,40372 ****
       common global variables are output.
  
   -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT)
!      Like 'ASM_OUTPUT_COMMON' except takes the required alignment as a
       separate, explicit argument.  If you define this macro, it is used
!      in place of 'ASM_OUTPUT_COMMON', and gives you more flexibility in
       handling the required alignment of the variable.  The alignment is
       specified as the number of bits.
  
   -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE,
            ALIGNMENT)
!      Like 'ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable
!      to be output, if there is one, or 'NULL_TREE' if there is no
       corresponding variable.  If you define this macro, GCC will use it
!      in place of both 'ASM_OUTPUT_COMMON' and
!      'ASM_OUTPUT_ALIGNED_COMMON'.  Define this macro when you need to
       see the variable's decl in order to chose what to output.
  
   -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT)
--- 40353,40371 ----
       common global variables are output.
  
   -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT)
!      Like ‘ASM_OUTPUT_COMMON’ except takes the required alignment as a
       separate, explicit argument.  If you define this macro, it is used
!      in place of ‘ASM_OUTPUT_COMMON’, and gives you more flexibility in
       handling the required alignment of the variable.  The alignment is
       specified as the number of bits.
  
   -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE,
            ALIGNMENT)
!      Like ‘ASM_OUTPUT_ALIGNED_COMMON’ except that DECL of the variable
!      to be output, if there is one, or ‘NULL_TREE’ if there is no
       corresponding variable.  If you define this macro, GCC will use it
!      in place of both ‘ASM_OUTPUT_COMMON’ and
!      ‘ASM_OUTPUT_ALIGNED_COMMON’.  Define this macro when you need to
       see the variable's decl in order to chose what to output.
  
   -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT)
*************** outputting a single uninitialized variab
*** 40375,40393 ****
       whose size is SIZE bytes.  The variable ALIGNMENT is the alignment
       specified as the number of bits.
  
!      Try to use function 'asm_output_aligned_bss' defined in file
!      'varasm.cc' when defining this macro.  If unable, use the
!      expression 'assemble_name (STREAM, NAME)' to output the name
       itself; before and after that, output the additional assembler
       syntax for defining the name, and a newline.
  
       There are two ways of handling global BSS.  One is to define this
!      macro.  The other is to have 'TARGET_ASM_SELECT_SECTION' return a
       switchable BSS section (*note
       TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::).  You do not need to do
       both.
  
!      Some languages do not have 'common' data, and require a non-common
       form of global BSS in order to handle uninitialized globals
       efficiently.  C++ is one example of this.  However, if the target
       does not support global BSS, the front end may choose to make
--- 40374,40392 ----
       whose size is SIZE bytes.  The variable ALIGNMENT is the alignment
       specified as the number of bits.
  
!      Try to use function ‘asm_output_aligned_bss’ defined in file
!      ‘varasm.cc’ when defining this macro.  If unable, use the
!      expression ‘assemble_name (STREAM, NAME)’ to output the name
       itself; before and after that, output the additional assembler
       syntax for defining the name, and a newline.
  
       There are two ways of handling global BSS.  One is to define this
!      macro.  The other is to have ‘TARGET_ASM_SELECT_SECTION’ return a
       switchable BSS section (*note
       TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::).  You do not need to do
       both.
  
!      Some languages do not have ‘common’ data, and require a non-common
       form of global BSS in order to handle uninitialized globals
       efficiently.  C++ is one example of this.  However, if the target
       does not support global BSS, the front end may choose to make
*************** outputting a single uninitialized variab
*** 40399,40405 ****
       size is SIZE bytes.  The variable ROUNDED is the size rounded up to
       whatever alignment the caller wants.
  
!      Use the expression 'assemble_name (STREAM, NAME)' to output the
       name itself; before and after that, output the additional assembler
       syntax for defining the name, and a newline.
  
--- 40398,40404 ----
       size is SIZE bytes.  The variable ROUNDED is the size rounded up to
       whatever alignment the caller wants.
  
!      Use the expression ‘assemble_name (STREAM, NAME)’ to output the
       name itself; before and after that, output the additional assembler
       syntax for defining the name, and a newline.
  
*************** outputting a single uninitialized variab
*** 40407,40424 ****
       static variables are output.
  
   -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT)
!      Like 'ASM_OUTPUT_LOCAL' except takes the required alignment as a
       separate, explicit argument.  If you define this macro, it is used
!      in place of 'ASM_OUTPUT_LOCAL', and gives you more flexibility in
       handling the required alignment of the variable.  The alignment is
       specified as the number of bits.
  
   -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE,
            ALIGNMENT)
!      Like 'ASM_OUTPUT_ALIGNED_LOCAL' except that DECL of the variable to
!      be output, if there is one, or 'NULL_TREE' if there is no
       corresponding variable.  If you define this macro, GCC will use it
!      in place of both 'ASM_OUTPUT_LOCAL' and 'ASM_OUTPUT_ALIGNED_LOCAL'.
       Define this macro when you need to see the variable's decl in order
       to chose what to output.
  
--- 40406,40423 ----
       static variables are output.
  
   -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT)
!      Like ‘ASM_OUTPUT_LOCAL’ except takes the required alignment as a
       separate, explicit argument.  If you define this macro, it is used
!      in place of ‘ASM_OUTPUT_LOCAL’, and gives you more flexibility in
       handling the required alignment of the variable.  The alignment is
       specified as the number of bits.
  
   -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE,
            ALIGNMENT)
!      Like ‘ASM_OUTPUT_ALIGNED_LOCAL’ except that DECL of the variable to
!      be output, if there is one, or ‘NULL_TREE’ if there is no
       corresponding variable.  If you define this macro, GCC will use it
!      in place of both ‘ASM_OUTPUT_LOCAL’ and ‘ASM_OUTPUT_ALIGNED_LOCAL’.
       Define this macro when you need to see the variable's decl in order
       to chose what to output.
  
*************** This is about outputting labels.
*** 40433,40439 ****
   -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       the assembler definition of a label named NAME.  Use the expression
!      'assemble_name (STREAM, NAME)' to output the name itself; before
       and after that, output the additional assembler syntax for defining
       the name, and a newline.  A default definition of this macro is
       provided which is correct for most systems.
--- 40432,40438 ----
   -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       the assembler definition of a label named NAME.  Use the expression
!      ‘assemble_name (STREAM, NAME)’ to output the name itself; before
       and after that, output the additional assembler syntax for defining
       the name, and a newline.  A default definition of this macro is
       provided which is correct for most systems.
*************** This is about outputting labels.
*** 40441,40476 ****
   -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       the assembler definition of a label named NAME of a function.  Use
!      the expression 'assemble_name (STREAM, NAME)' to output the name
       itself; before and after that, output the additional assembler
       syntax for defining the name, and a newline.  A default definition
       of this macro is provided which is correct for most systems.
  
       If this macro is not defined, then the function name is defined in
!      the usual manner as a label (by means of 'ASM_OUTPUT_LABEL').
  
   -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME)
!      Identical to 'ASM_OUTPUT_LABEL', except that NAME is known to refer
       to a compiler-generated label.  The default definition uses
!      'assemble_name_raw', which is like 'assemble_name' except that it
       is more efficient.
  
   -- Macro: SIZE_ASM_OP
       A C string containing the appropriate assembler directive to
       specify the size of a symbol, without any arguments.  On systems
!      that use ELF, the default (in 'config/elfos.h') is '"\t.size\t"';
       on other systems, the default is not to define this macro.
  
       Define this macro only if it is correct to use the default
!      definitions of 'ASM_OUTPUT_SIZE_DIRECTIVE' and
!      'ASM_OUTPUT_MEASURED_SIZE' for your system.  If you need your own
       custom definitions of those macros, or if you do not need explicit
       symbol sizes at all, do not define this macro.
  
   -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       a directive telling the assembler that the size of the symbol NAME
!      is SIZE.  SIZE is a 'HOST_WIDE_INT'.  If you define 'SIZE_ASM_OP',
       a default definition of this macro is provided.
  
   -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME)
--- 40440,40475 ----
   -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       the assembler definition of a label named NAME of a function.  Use
!      the expression ‘assemble_name (STREAM, NAME)’ to output the name
       itself; before and after that, output the additional assembler
       syntax for defining the name, and a newline.  A default definition
       of this macro is provided which is correct for most systems.
  
       If this macro is not defined, then the function name is defined in
!      the usual manner as a label (by means of ‘ASM_OUTPUT_LABEL’).
  
   -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME)
!      Identical to ‘ASM_OUTPUT_LABEL’, except that NAME is known to refer
       to a compiler-generated label.  The default definition uses
!      ‘assemble_name_raw’, which is like ‘assemble_name’ except that it
       is more efficient.
  
   -- Macro: SIZE_ASM_OP
       A C string containing the appropriate assembler directive to
       specify the size of a symbol, without any arguments.  On systems
!      that use ELF, the default (in ‘config/elfos.h’) is ‘"\t.size\t"’;
       on other systems, the default is not to define this macro.
  
       Define this macro only if it is correct to use the default
!      definitions of ‘ASM_OUTPUT_SIZE_DIRECTIVE’ and
!      ‘ASM_OUTPUT_MEASURED_SIZE’ for your system.  If you need your own
       custom definitions of those macros, or if you do not need explicit
       symbol sizes at all, do not define this macro.
  
   -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       a directive telling the assembler that the size of the symbol NAME
!      is SIZE.  SIZE is a ‘HOST_WIDE_INT’.  If you define ‘SIZE_ASM_OP’,
       a default definition of this macro is provided.
  
   -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME)
*************** This is about outputting labels.
*** 40478,40522 ****
       a directive telling the assembler to calculate the size of the
       symbol NAME by subtracting its address from the current address.
  
!      If you define 'SIZE_ASM_OP', a default definition of this macro is
       provided.  The default assumes that the assembler recognizes a
!      special '.' symbol as referring to the current address, and can
       calculate the difference between this and another symbol.  If your
!      assembler does not recognize '.' or cannot do calculations with it,
!      you will need to redefine 'ASM_OUTPUT_MEASURED_SIZE' to use some
       other technique.
  
   -- Macro: NO_DOLLAR_IN_LABEL
       Define this macro if the assembler does not accept the character
!      '$' in label names.  By default constructors and destructors in G++
!      have '$' in the identifiers.  If this macro is defined, '.' is used
       instead.
  
   -- Macro: NO_DOT_IN_LABEL
       Define this macro if the assembler does not accept the character
!      '.' in label names.  By default constructors and destructors in G++
!      have names that use '.'.  If this macro is defined, these names are
!      rewritten to avoid '.'.
  
   -- Macro: TYPE_ASM_OP
       A C string containing the appropriate assembler directive to
       specify the type of a symbol, without any arguments.  On systems
!      that use ELF, the default (in 'config/elfos.h') is '"\t.type\t"';
       on other systems, the default is not to define this macro.
  
       Define this macro only if it is correct to use the default
!      definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system.  If you
       need your own custom definition of this macro, or if you do not
       need explicit symbol types at all, do not define this macro.
  
   -- Macro: TYPE_OPERAND_FMT
!      A C string which specifies (using 'printf' syntax) the format of
!      the second operand to 'TYPE_ASM_OP'.  On systems that use ELF, the
!      default (in 'config/elfos.h') is '"@%s"'; on other systems, the
       default is not to define this macro.
  
       Define this macro only if it is correct to use the default
!      definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system.  If you
       need your own custom definition of this macro, or if you do not
       need explicit symbol types at all, do not define this macro.
  
--- 40477,40521 ----
       a directive telling the assembler to calculate the size of the
       symbol NAME by subtracting its address from the current address.
  
!      If you define ‘SIZE_ASM_OP’, a default definition of this macro is
       provided.  The default assumes that the assembler recognizes a
!      special ‘.’ symbol as referring to the current address, and can
       calculate the difference between this and another symbol.  If your
!      assembler does not recognize ‘.’ or cannot do calculations with it,
!      you will need to redefine ‘ASM_OUTPUT_MEASURED_SIZE’ to use some
       other technique.
  
   -- Macro: NO_DOLLAR_IN_LABEL
       Define this macro if the assembler does not accept the character
!      ‘$’ in label names.  By default constructors and destructors in G++
!      have ‘$’ in the identifiers.  If this macro is defined, ‘.’ is used
       instead.
  
   -- Macro: NO_DOT_IN_LABEL
       Define this macro if the assembler does not accept the character
!      ‘.’ in label names.  By default constructors and destructors in G++
!      have names that use ‘.’.  If this macro is defined, these names are
!      rewritten to avoid ‘.’.
  
   -- Macro: TYPE_ASM_OP
       A C string containing the appropriate assembler directive to
       specify the type of a symbol, without any arguments.  On systems
!      that use ELF, the default (in ‘config/elfos.h’) is ‘"\t.type\t"’;
       on other systems, the default is not to define this macro.
  
       Define this macro only if it is correct to use the default
!      definition of ‘ASM_OUTPUT_TYPE_DIRECTIVE’ for your system.  If you
       need your own custom definition of this macro, or if you do not
       need explicit symbol types at all, do not define this macro.
  
   -- Macro: TYPE_OPERAND_FMT
!      A C string which specifies (using ‘printf’ syntax) the format of
!      the second operand to ‘TYPE_ASM_OP’.  On systems that use ELF, the
!      default (in ‘config/elfos.h’) is ‘"@%s"’; on other systems, the
       default is not to define this macro.
  
       Define this macro only if it is correct to use the default
!      definition of ‘ASM_OUTPUT_TYPE_DIRECTIVE’ for your system.  If you
       need your own custom definition of this macro, or if you do not
       need explicit symbol types at all, do not define this macro.
  
*************** This is about outputting labels.
*** 40524,40561 ****
       A C statement (sans semicolon) to output to the stdio stream STREAM
       a directive telling the assembler that the type of the symbol NAME
       is TYPE.  TYPE is a C string; currently, that string is always
!      either '"function"' or '"object"', but you should not count on
       this.
  
!      If you define 'TYPE_ASM_OP' and 'TYPE_OPERAND_FMT', a default
       definition of this macro is provided.
  
   -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       any text necessary for declaring the name NAME of a function which
       is being defined.  This macro is responsible for outputting the
!      label definition (perhaps using 'ASM_OUTPUT_FUNCTION_LABEL').  The
!      argument DECL is the 'FUNCTION_DECL' tree node representing the
       function.
  
       If this macro is not defined, then the function name is defined in
       the usual manner as a label (by means of
!      'ASM_OUTPUT_FUNCTION_LABEL').
  
!      You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition
       of this macro.
  
   -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       any text necessary for declaring the size of a function which is
       being defined.  The argument NAME is the name of the function.  The
!      argument DECL is the 'FUNCTION_DECL' tree node representing the
       function.
  
       If this macro is not defined, then the function size is not
       defined.
  
!      You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of
       this macro.
  
   -- Macro: ASM_DECLARE_COLD_FUNCTION_NAME (STREAM, NAME, DECL)
--- 40523,40560 ----
       A C statement (sans semicolon) to output to the stdio stream STREAM
       a directive telling the assembler that the type of the symbol NAME
       is TYPE.  TYPE is a C string; currently, that string is always
!      either ‘"function"’ or ‘"object"’, but you should not count on
       this.
  
!      If you define ‘TYPE_ASM_OP’ and ‘TYPE_OPERAND_FMT’, a default
       definition of this macro is provided.
  
   -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       any text necessary for declaring the name NAME of a function which
       is being defined.  This macro is responsible for outputting the
!      label definition (perhaps using ‘ASM_OUTPUT_FUNCTION_LABEL’).  The
!      argument DECL is the ‘FUNCTION_DECL’ tree node representing the
       function.
  
       If this macro is not defined, then the function name is defined in
       the usual manner as a label (by means of
!      ‘ASM_OUTPUT_FUNCTION_LABEL’).
  
!      You may wish to use ‘ASM_OUTPUT_TYPE_DIRECTIVE’ in the definition
       of this macro.
  
   -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       any text necessary for declaring the size of a function which is
       being defined.  The argument NAME is the name of the function.  The
!      argument DECL is the ‘FUNCTION_DECL’ tree node representing the
       function.
  
       If this macro is not defined, then the function size is not
       defined.
  
!      You may wish to use ‘ASM_OUTPUT_MEASURED_SIZE’ in the definition of
       this macro.
  
   -- Macro: ASM_DECLARE_COLD_FUNCTION_NAME (STREAM, NAME, DECL)
*************** This is about outputting labels.
*** 40563,40576 ****
       any text necessary for declaring the name NAME of a cold function
       partition which is being defined.  This macro is responsible for
       outputting the label definition (perhaps using
!      'ASM_OUTPUT_FUNCTION_LABEL').  The argument DECL is the
!      'FUNCTION_DECL' tree node representing the function.
  
       If this macro is not defined, then the cold partition name is
       defined in the usual manner as a label (by means of
!      'ASM_OUTPUT_LABEL').
  
!      You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition
       of this macro.
  
   -- Macro: ASM_DECLARE_COLD_FUNCTION_SIZE (STREAM, NAME, DECL)
--- 40562,40575 ----
       any text necessary for declaring the name NAME of a cold function
       partition which is being defined.  This macro is responsible for
       outputting the label definition (perhaps using
!      ‘ASM_OUTPUT_FUNCTION_LABEL’).  The argument DECL is the
!      ‘FUNCTION_DECL’ tree node representing the function.
  
       If this macro is not defined, then the cold partition name is
       defined in the usual manner as a label (by means of
!      ‘ASM_OUTPUT_LABEL’).
  
!      You may wish to use ‘ASM_OUTPUT_TYPE_DIRECTIVE’ in the definition
       of this macro.
  
   -- Macro: ASM_DECLARE_COLD_FUNCTION_SIZE (STREAM, NAME, DECL)
*************** This is about outputting labels.
*** 40578,40617 ****
       any text necessary for declaring the size of a cold function
       partition which is being defined.  The argument NAME is the name of
       the cold partition of the function.  The argument DECL is the
!      'FUNCTION_DECL' tree node representing the function.
  
       If this macro is not defined, then the partition size is not
       defined.
  
!      You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of
       this macro.
  
   -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       any text necessary for declaring the name NAME of an initialized
       variable which is being defined.  This macro must output the label
!      definition (perhaps using 'ASM_OUTPUT_LABEL').  The argument DECL
!      is the 'VAR_DECL' tree node representing the variable.
  
       If this macro is not defined, then the variable name is defined in
!      the usual manner as a label (by means of 'ASM_OUTPUT_LABEL').
  
!      You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' and/or
!      'ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro.
  
   -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE,
            const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE)
       A target hook to output to the stdio stream FILE any text necessary
       for declaring the name NAME of a constant which is being defined.
       This target hook is responsible for outputting the label definition
!      (perhaps using 'assemble_label').  The argument EXP is the value of
       the constant, and SIZE is the size of the constant in bytes.  The
       NAME will be an internal label.
  
       The default version of this target hook, define the NAME in the
!      usual manner as a label (by means of 'assemble_label').
  
!      You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in this target
       hook.
  
   -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME)
--- 40577,40616 ----
       any text necessary for declaring the size of a cold function
       partition which is being defined.  The argument NAME is the name of
       the cold partition of the function.  The argument DECL is the
!      ‘FUNCTION_DECL’ tree node representing the function.
  
       If this macro is not defined, then the partition size is not
       defined.
  
!      You may wish to use ‘ASM_OUTPUT_MEASURED_SIZE’ in the definition of
       this macro.
  
   -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       any text necessary for declaring the name NAME of an initialized
       variable which is being defined.  This macro must output the label
!      definition (perhaps using ‘ASM_OUTPUT_LABEL’).  The argument DECL
!      is the ‘VAR_DECL’ tree node representing the variable.
  
       If this macro is not defined, then the variable name is defined in
!      the usual manner as a label (by means of ‘ASM_OUTPUT_LABEL’).
  
!      You may wish to use ‘ASM_OUTPUT_TYPE_DIRECTIVE’ and/or
!      ‘ASM_OUTPUT_SIZE_DIRECTIVE’ in the definition of this macro.
  
   -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE,
            const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE)
       A target hook to output to the stdio stream FILE any text necessary
       for declaring the name NAME of a constant which is being defined.
       This target hook is responsible for outputting the label definition
!      (perhaps using ‘assemble_label’).  The argument EXP is the value of
       the constant, and SIZE is the size of the constant in bytes.  The
       NAME will be an internal label.
  
       The default version of this target hook, define the NAME in the
!      usual manner as a label (by means of ‘assemble_label’).
  
!      You may wish to use ‘ASM_OUTPUT_TYPE_DIRECTIVE’ in this target
       hook.
  
   -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME)
*************** This is about outputting labels.
*** 40632,40639 ****
       If you don't define this macro, that is equivalent to defining it
       to do nothing.
  
!      You may wish to use 'ASM_OUTPUT_SIZE_DIRECTIVE' and/or
!      'ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro.
  
   -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const
            char *NAME)
--- 40631,40638 ----
       If you don't define this macro, that is equivalent to defining it
       to do nothing.
  
!      You may wish to use ‘ASM_OUTPUT_SIZE_DIRECTIVE’ and/or
!      ‘ASM_OUTPUT_MEASURED_SIZE’ in the definition of this macro.
  
   -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const
            char *NAME)
*************** This is about outputting labels.
*** 40642,40648 ****
       available for reference from other files.
  
       The default implementation relies on a proper definition of
!      'GLOBAL_ASM_OP'.
  
   -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, tree
            DECL)
--- 40641,40647 ----
       available for reference from other files.
  
       The default implementation relies on a proper definition of
!      ‘GLOBAL_ASM_OP’.
  
   -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, tree
            DECL)
*************** This is about outputting labels.
*** 40664,40713 ****
       A C statement (sans semicolon) to output to the stdio stream STREAM
       some commands that will make the label NAME weak; that is,
       available for reference from other files but only used if no other
!      definition is available.  Use the expression 'assemble_name
!      (STREAM, NAME)' to output the name itself; before and after that,
       output the additional assembler syntax for making that name weak,
       and a newline.
  
!      If you don't define this macro or 'ASM_WEAKEN_DECL', GCC will not
!      support weak symbols and you should not define the 'SUPPORTS_WEAK'
       macro.
  
   -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE)
!      Combines (and replaces) the function of 'ASM_WEAKEN_LABEL' and
!      'ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function
!      or variable decl.  If VALUE is not 'NULL', this C statement should
       output to the stdio stream STREAM assembler code which defines
       (equates) the weak symbol NAME to have the value VALUE.  If VALUE
!      is 'NULL', it should output commands to make NAME weak.
  
   -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE)
       Outputs a directive that enables NAME to be used to refer to symbol
!      VALUE with weak-symbol semantics.  'decl' is the declaration of
!      'name'.
  
   -- Macro: SUPPORTS_WEAK
       A preprocessor constant expression which evaluates to true if the
       target supports weak symbols.
  
!      If you don't define this macro, 'defaults.h' provides a default
!      definition.  If either 'ASM_WEAKEN_LABEL' or 'ASM_WEAKEN_DECL' is
!      defined, the default definition is '1'; otherwise, it is '0'.
  
   -- Macro: TARGET_SUPPORTS_WEAK
       A C expression which evaluates to true if the target supports weak
       symbols.
  
!      If you don't define this macro, 'defaults.h' provides a default
!      definition.  The default definition is '(SUPPORTS_WEAK)'.  Define
       this macro if you want to control weak symbol support with a
!      compiler flag such as '-melf'.
  
   -- Macro: MAKE_DECL_ONE_ONLY (DECL)
       A C statement (sans semicolon) to mark DECL to be emitted as a
       public symbol such that extra copies in multiple translation units
       will be discarded by the linker.  Define this macro if your object
!      file format provides support for this concept, such as the 'COMDAT'
       section flags in the Microsoft Windows PE/COFF format, and this
       support requires changes to DECL, such as putting it in a separate
       section.
--- 40663,40712 ----
       A C statement (sans semicolon) to output to the stdio stream STREAM
       some commands that will make the label NAME weak; that is,
       available for reference from other files but only used if no other
!      definition is available.  Use the expression ‘assemble_name
!      (STREAM, NAME)’ to output the name itself; before and after that,
       output the additional assembler syntax for making that name weak,
       and a newline.
  
!      If you don't define this macro or ‘ASM_WEAKEN_DECL’, GCC will not
!      support weak symbols and you should not define the ‘SUPPORTS_WEAK’
       macro.
  
   -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE)
!      Combines (and replaces) the function of ‘ASM_WEAKEN_LABEL’ and
!      ‘ASM_OUTPUT_WEAK_ALIAS’, allowing access to the associated function
!      or variable decl.  If VALUE is not ‘NULL’, this C statement should
       output to the stdio stream STREAM assembler code which defines
       (equates) the weak symbol NAME to have the value VALUE.  If VALUE
!      is ‘NULL’, it should output commands to make NAME weak.
  
   -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE)
       Outputs a directive that enables NAME to be used to refer to symbol
!      VALUE with weak-symbol semantics.  ‘decl’ is the declaration of
!      ‘name’.
  
   -- Macro: SUPPORTS_WEAK
       A preprocessor constant expression which evaluates to true if the
       target supports weak symbols.
  
!      If you don't define this macro, ‘defaults.h’ provides a default
!      definition.  If either ‘ASM_WEAKEN_LABEL’ or ‘ASM_WEAKEN_DECL’ is
!      defined, the default definition is ‘1’; otherwise, it is ‘0’.
  
   -- Macro: TARGET_SUPPORTS_WEAK
       A C expression which evaluates to true if the target supports weak
       symbols.
  
!      If you don't define this macro, ‘defaults.h’ provides a default
!      definition.  The default definition is ‘(SUPPORTS_WEAK)’.  Define
       this macro if you want to control weak symbol support with a
!      compiler flag such as ‘-melf’.
  
   -- Macro: MAKE_DECL_ONE_ONLY (DECL)
       A C statement (sans semicolon) to mark DECL to be emitted as a
       public symbol such that extra copies in multiple translation units
       will be discarded by the linker.  Define this macro if your object
!      file format provides support for this concept, such as the ‘COMDAT’
       section flags in the Microsoft Windows PE/COFF format, and this
       support requires changes to DECL, such as putting it in a separate
       section.
*************** This is about outputting labels.
*** 40716,40726 ****
       A C expression which evaluates to true if the target supports
       one-only semantics.
  
!      If you don't define this macro, 'varasm.cc' provides a default
!      definition.  If 'MAKE_DECL_ONE_ONLY' is defined, the default
!      definition is '1'; otherwise, it is '0'.  Define this macro if you
       want to control one-only symbol support with a compiler flag, or if
!      setting the 'DECL_ONE_ONLY' flag is enough to mark a declaration to
       be emitted as one-only.
  
   -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int
--- 40715,40725 ----
       A C expression which evaluates to true if the target supports
       one-only semantics.
  
!      If you don't define this macro, ‘varasm.cc’ provides a default
!      definition.  If ‘MAKE_DECL_ONE_ONLY’ is defined, the default
!      definition is ‘1’; otherwise, it is ‘0’.  Define this macro if you
       want to control one-only symbol support with a compiler flag, or if
!      setting the ‘DECL_ONE_ONLY’ flag is enough to mark a declaration to
       be emitted as one-only.
  
   -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int
*************** This is about outputting labels.
*** 40733,40739 ****
   -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC
       A C expression that evaluates to true if the target's linker
       expects that weak symbols do not appear in a static archive's table
!      of contents.  The default is '0'.
  
       Leaving weak symbols out of an archive's table of contents means
       that, if a symbol will only have a definition in one translation
--- 40732,40738 ----
   -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC
       A C expression that evaluates to true if the target's linker
       expects that weak symbols do not appear in a static archive's table
!      of contents.  The default is ‘0’.
  
       Leaving weak symbols out of an archive's table of contents means
       that, if a symbol will only have a definition in one translation
*************** This is about outputting labels.
*** 40763,40769 ****
       This target hook is a function to output to ASM_OUT_FILE an
       assembler pseudo-op to declare a library function name external.
       The name of the library function is given by SYMREF, which is a
!      'symbol_ref'.
  
   -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char
            *SYMBOL)
--- 40762,40768 ----
       This target hook is a function to output to ASM_OUT_FILE an
       assembler pseudo-op to declare a library function name external.
       The name of the library function is given by SYMREF, which is a
!      ‘symbol_ref’.
  
   -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char
            *SYMBOL)
*************** This is about outputting labels.
*** 40774,40803 ****
   -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       a reference in assembler syntax to a label named NAME.  This should
!      add '_' to the front of the name, if that is customary on your
       operating system, as it is in most Berkeley Unix systems.  This
!      macro is used in 'assemble_name'.
  
   -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME)
!      Given a symbol NAME, perform same mangling as 'varasm.cc''s
!      'assemble_name', but in memory rather than to a file stream,
!      returning result as an 'IDENTIFIER_NODE'.  Required for correct LTO
       symtabs.  The default implementation calls the
!      'TARGET_STRIP_NAME_ENCODING' hook and then prepends the
!      'USER_LABEL_PREFIX', if any.
  
   -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM)
       A C statement (sans semicolon) to output a reference to
!      'SYMBOL_REF' SYM.  If not defined, 'assemble_name' will be used to
       output the name of the symbol.  This macro may be used to modify
       the way a symbol is referenced depending on information encoded by
!      'TARGET_ENCODE_SECTION_INFO'.
  
   -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF)
       A C statement (sans semicolon) to output a reference to BUF, the
!      result of 'ASM_GENERATE_INTERNAL_LABEL'.  If not defined,
!      'assemble_name' will be used to output the name of the symbol.
!      This macro is not used by 'output_asm_label', or the '%l' specifier
       that calls it; the intention is that this macro should be set when
       it is necessary to output a label differently when its address is
       being taken.
--- 40773,40802 ----
   -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME)
       A C statement (sans semicolon) to output to the stdio stream STREAM
       a reference in assembler syntax to a label named NAME.  This should
!      add ‘_’ to the front of the name, if that is customary on your
       operating system, as it is in most Berkeley Unix systems.  This
!      macro is used in ‘assemble_name’.
  
   -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME)
!      Given a symbol NAME, perform same mangling as ‘varasm.cc’'s
!      ‘assemble_name’, but in memory rather than to a file stream,
!      returning result as an ‘IDENTIFIER_NODE’.  Required for correct LTO
       symtabs.  The default implementation calls the
!      ‘TARGET_STRIP_NAME_ENCODING’ hook and then prepends the
!      ‘USER_LABEL_PREFIX’, if any.
  
   -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM)
       A C statement (sans semicolon) to output a reference to
!      ‘SYMBOL_REF’ SYM.  If not defined, ‘assemble_name’ will be used to
       output the name of the symbol.  This macro may be used to modify
       the way a symbol is referenced depending on information encoded by
!      ‘TARGET_ENCODE_SECTION_INFO’.
  
   -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF)
       A C statement (sans semicolon) to output a reference to BUF, the
!      result of ‘ASM_GENERATE_INTERNAL_LABEL’.  If not defined,
!      ‘assemble_name’ will be used to output the name of the symbol.
!      This macro is not used by ‘output_asm_label’, or the ‘%l’ specifier
       that calls it; the intention is that this macro should be set when
       it is necessary to output a label differently when its address is
       being taken.
*************** This is about outputting labels.
*** 40813,40824 ****
  
       It is desirable to exclude internal labels from the symbol table of
       the object file.  Most assemblers have a naming convention for
!      labels that should be excluded; on many systems, the letter 'L' at
       the beginning of a label has this effect.  You should find out what
       convention your system uses, and follow it.
  
       The default version of this function utilizes
!      'ASM_GENERATE_INTERNAL_LABEL'.
  
   -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM)
       A C statement to output to the stdio stream STREAM a debug info
--- 40812,40823 ----
  
       It is desirable to exclude internal labels from the symbol table of
       the object file.  Most assemblers have a naming convention for
!      labels that should be excluded; on many systems, the letter ‘L’ at
       the beginning of a label has this effect.  You should find out what
       convention your system uses, and follow it.
  
       The default version of this function utilizes
!      ‘ASM_GENERATE_INTERNAL_LABEL’.
  
   -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM)
       A C statement to output to the stdio stream STREAM a debug info
*************** This is about outputting labels.
*** 40830,40860 ****
       of instruction bundles.
  
       If this macro is not defined, then
!      '(*targetm.asm_out.internal_label)' will be used.
  
   -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM)
       A C statement to store into the string STRING a label whose name is
       made from the string PREFIX and the number NUM.
  
!      This string, when output subsequently by 'assemble_name', should
!      produce the output that '(*targetm.asm_out.internal_label)' would
       produce with the same PREFIX and NUM.
  
!      If the string begins with '*', then 'assemble_name' will output the
       rest of the string unchanged.  It is often convenient for
!      'ASM_GENERATE_INTERNAL_LABEL' to use '*' in this way.  If the
!      string doesn't start with '*', then 'ASM_OUTPUT_LABELREF' gets to
       output the string, and may change it.  (Of course,
!      'ASM_OUTPUT_LABELREF' is also part of your machine description, so
       you should know what it does on your machine.)
  
   -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER)
       A C expression to assign to OUTVAR (which is a variable of type
!      'char *') a newly allocated string made from the string NAME and
       the number NUMBER, with some suitable punctuation added.  Use
!      'alloca' to get space for the string.
  
!      The string will be used as an argument to 'ASM_OUTPUT_LABELREF' to
       produce an assembler label for an internal static variable whose
       name is NAME.  Therefore, the string must be such as to result in
       valid assembler code.  The argument NUMBER is different each time
--- 40829,40859 ----
       of instruction bundles.
  
       If this macro is not defined, then
!      ‘(*targetm.asm_out.internal_label)’ will be used.
  
   -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM)
       A C statement to store into the string STRING a label whose name is
       made from the string PREFIX and the number NUM.
  
!      This string, when output subsequently by ‘assemble_name’, should
!      produce the output that ‘(*targetm.asm_out.internal_label)’ would
       produce with the same PREFIX and NUM.
  
!      If the string begins with ‘*’, then ‘assemble_name’ will output the
       rest of the string unchanged.  It is often convenient for
!      ‘ASM_GENERATE_INTERNAL_LABEL’ to use ‘*’ in this way.  If the
!      string doesn't start with ‘*’, then ‘ASM_OUTPUT_LABELREF’ gets to
       output the string, and may change it.  (Of course,
!      ‘ASM_OUTPUT_LABELREF’ is also part of your machine description, so
       you should know what it does on your machine.)
  
   -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER)
       A C expression to assign to OUTVAR (which is a variable of type
!      ‘char *’) a newly allocated string made from the string NAME and
       the number NUMBER, with some suitable punctuation added.  Use
!      ‘alloca’ to get space for the string.
  
!      The string will be used as an argument to ‘ASM_OUTPUT_LABELREF’ to
       produce an assembler label for an internal static variable whose
       name is NAME.  Therefore, the string must be such as to result in
       valid assembler code.  The argument NUMBER is different each time
*************** This is about outputting labels.
*** 40873,40879 ****
       A C statement to output to the stdio stream STREAM assembler code
       which defines (equates) the symbol NAME to have the value VALUE.
  
!      If 'SET_ASM_OP' is defined, a default definition is provided which
       is correct for most systems.
  
   -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME,
--- 40872,40878 ----
       A C statement to output to the stdio stream STREAM assembler code
       which defines (equates) the symbol NAME to have the value VALUE.
  
!      If ‘SET_ASM_OP’ is defined, a default definition is provided which
       is correct for most systems.
  
   -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME,
*************** This is about outputting labels.
*** 40881,40890 ****
       A C statement to output to the stdio stream STREAM assembler code
       which defines (equates) the symbol whose tree node is DECL_OF_NAME
       to have the value of the tree node DECL_OF_VALUE.  This macro will
!      be used in preference to 'ASM_OUTPUT_DEF' if it is defined and if
       the tree nodes are available.
  
!      If 'SET_ASM_OP' is defined, a default definition is provided which
       is correct for most systems.
  
   -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE)
--- 40880,40889 ----
       A C statement to output to the stdio stream STREAM assembler code
       which defines (equates) the symbol whose tree node is DECL_OF_NAME
       to have the value of the tree node DECL_OF_VALUE.  This macro will
!      be used in preference to ‘ASM_OUTPUT_DEF’ if it is defined and if
       the tree nodes are available.
  
!      If ‘SET_ASM_OP’ is defined, a default definition is provided which
       is correct for most systems.
  
   -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE)
*************** This is about outputting labels.
*** 40893,40908 ****
       have the value of the tree node DECL_OF_VALUE should be emitted
       near the end of the current compilation unit.  The default is to
       not defer output of defines.  This macro affects defines output by
!      'ASM_OUTPUT_DEF' and 'ASM_OUTPUT_DEF_FROM_DECLS'.
  
   -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE)
       A C statement to output to the stdio stream STREAM assembler code
       which defines (equates) the weak symbol NAME to have the value
!      VALUE.  If VALUE is 'NULL', it defines NAME as an undefined weak
       symbol.
  
       Define this macro if the target only supports weak aliases; define
!      'ASM_OUTPUT_DEF' instead if possible.
  
   -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME,
            SEL_NAME)
--- 40892,40907 ----
       have the value of the tree node DECL_OF_VALUE should be emitted
       near the end of the current compilation unit.  The default is to
       not defer output of defines.  This macro affects defines output by
!      ‘ASM_OUTPUT_DEF’ and ‘ASM_OUTPUT_DEF_FROM_DECLS’.
  
   -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE)
       A C statement to output to the stdio stream STREAM assembler code
       which defines (equates) the weak symbol NAME to have the value
!      VALUE.  If VALUE is ‘NULL’, it defines NAME as an undefined weak
       symbol.
  
       Define this macro if the target only supports weak aliases; define
!      ‘ASM_OUTPUT_DEF’ instead if possible.
  
   -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME,
            SEL_NAME)
*************** This is about outputting labels.
*** 40910,40930 ****
       Objective-C methods.
  
       The default name is a unique method number followed by the name of
!      the class (e.g. '_1_Foo').  For methods in categories, the name of
       the category is also included in the assembler name (e.g.
!      '_1_Foo_Bar').
  
       These names are safe on most systems, but make debugging difficult
       since the method's selector is not present in the name.  Therefore,
       particular systems define other ways of computing names.
  
!      BUF is an expression of type 'char *' which gives you a buffer in
       which to store the name; its length is as long as CLASS_NAME,
       CAT_NAME and SEL_NAME put together, plus 50 characters extra.
  
       The argument IS_INST specifies whether the method is an instance
       method or a class method; CLASS_NAME is the name of the class;
!      CAT_NAME is the name of the category (or 'NULL' if the method is
       not in a category); and SEL_NAME is the name of the selector.
  
       On systems where the assembler can handle quoted names, you can use
--- 40909,40929 ----
       Objective-C methods.
  
       The default name is a unique method number followed by the name of
!      the class (e.g. ‘_1_Foo’).  For methods in categories, the name of
       the category is also included in the assembler name (e.g.
!      ‘_1_Foo_Bar’).
  
       These names are safe on most systems, but make debugging difficult
       since the method's selector is not present in the name.  Therefore,
       particular systems define other ways of computing names.
  
!      BUF is an expression of type ‘char *’ which gives you a buffer in
       which to store the name; its length is as long as CLASS_NAME,
       CAT_NAME and SEL_NAME put together, plus 50 characters extra.
  
       The argument IS_INST specifies whether the method is an instance
       method or a class method; CLASS_NAME is the name of the class;
!      CAT_NAME is the name of the category (or ‘NULL’ if the method is
       not in a category); and SEL_NAME is the name of the selector.
  
       On systems where the assembler can handle quoted names, you can use
*************** File: gccint.info,  Node: Initialization
*** 40936,40949 ****
  18.20.5 How Initialization Functions Are Handled
  ------------------------------------------------
  
! The compiled code for certain languages includes "constructors" (also
! called "initialization routines")--functions to initialize data in the
  program when the program is started.  These functions need to be called
! before the program is "started"--that is to say, before 'main' is
  called.
  
!  Compiling some languages generates "destructors" (also called
! "termination routines") that should be called when the program
  terminates.
  
   To make the initialization and termination functions work, the compiler
--- 40935,40948 ----
  18.20.5 How Initialization Functions Are Handled
  ------------------------------------------------
  
! The compiled code for certain languages includes “constructors” (also
! called “initialization routines”)--functions to initialize data in the
  program when the program is started.  These functions need to be called
! before the program is "started"--that is to say, before ‘main’ is
  called.
  
!  Compiling some languages generates “destructors” (also called
! “termination routines”) that should be called when the program
  terminates.
  
   To make the initialization and termination functions work, the compiler
*************** initialization and termination functions
*** 40956,41046 ****
  Much of the structure is common to all four variations.
  
   The linker must build two lists of these functions--a list of
! initialization functions, called '__CTOR_LIST__', and a list of
! termination functions, called '__DTOR_LIST__'.
  
   Each list always begins with an ignored function pointer (which may
! hold 0, -1, or a count of the function pointers after it, depending on
  the environment).  This is followed by a series of zero or more function
  pointers to constructors (or destructors), followed by a function
  pointer containing zero.
  
   Depending on the operating system and its executable file format,
! either 'crtstuff.c' or 'libgcc2.c' traverses these lists at startup time
  and exit time.  Constructors are called in reverse order of the list;
  destructors in forward order.
  
   The best way to handle static constructors works only for object file
  formats which provide arbitrarily-named sections.  A section is set
  aside for a list of constructors, and another for a list of destructors.
! Traditionally these are called '.ctors' and '.dtors'.  Each object file
  that defines an initialization function also puts a word in the
  constructor section to point to that function.  The linker accumulates
! all these words into one contiguous '.ctors' section.  Termination
  functions are handled similarly.
  
!  This method will be chosen as the default by 'target-def.h' if
! 'TARGET_ASM_NAMED_SECTION' is defined.  A target that does not support
  arbitrary sections, but does support special designated constructor and
! destructor sections may define 'CTORS_SECTION_ASM_OP' and
! 'DTORS_SECTION_ASM_OP' to achieve the same effect.
  
   When arbitrary sections are available, there are two variants,
! depending upon how the code in 'crtstuff.c' is called.  On systems that
! support a ".init" section which is executed at program startup, parts of
! 'crtstuff.c' are compiled into that section.  The program is linked by
! the 'gcc' driver like this:
  
       ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o
  
!  The prologue of a function ('__init') appears in the '.init' section of
! 'crti.o'; the epilogue appears in 'crtn.o'.  Likewise for the function
! '__fini' in the ".fini" section.  Normally these files are provided by
  the operating system or by the GNU C library, but are provided by GCC
  for a few targets.
  
!  The objects 'crtbegin.o' and 'crtend.o' are (for most targets) compiled
! from 'crtstuff.c'.  They contain, among other things, code fragments
! within the '.init' and '.fini' sections that branch to routines in the
! '.text' section.  The linker will pull all parts of a section together,
! which results in a complete '__init' function that invokes the routines
  we need at startup.
  
!  To use this variant, you must define the 'INIT_SECTION_ASM_OP' macro
  properly.
  
   If no init section is available, when GCC compiles any function called
! 'main' (or more accurately, any function designated as a program entry
! point by the language front end calling 'expand_main_function'), it
! inserts a procedure call to '__main' as the first executable code after
! the function prologue.  The '__main' function is defined in 'libgcc2.c'
  and runs the global constructors.
  
   In file formats that don't support arbitrary sections, there are again
! two variants.  In the simplest variant, the GNU linker (GNU 'ld') and an
! 'a.out' format must be used.  In this case, 'TARGET_ASM_CONSTRUCTOR' is
! defined to produce a '.stabs' entry of type 'N_SETT', referencing the
! name '__CTOR_LIST__', and with the address of the void function
  containing the initialization code as its value.  The GNU linker
! recognizes this as a request to add the value to a "set"; the values are
  accumulated, and are eventually placed in the executable as a vector in
  the format described above, with a leading (ignored) count and a
! trailing zero element.  'TARGET_ASM_DESTRUCTOR' is handled similarly.
! Since no init section is available, the absence of 'INIT_SECTION_ASM_OP'
! causes the compilation of 'main' to call '__main' as above, starting the
  initialization process.
  
   The last variant uses neither arbitrary sections nor the GNU linker.
  This is preferable when you want to do dynamic linking and when using
  file formats which the GNU linker does not support, such as 'ECOFF'.  In
! this case, 'TARGET_HAVE_CTORS_DTORS' is false, initialization and
  termination functions are recognized simply by their names.  This
! requires an extra program in the linkage step, called 'collect2'.  This
  program pretends to be the linker, for use with GCC; it does its job by
  running the ordinary linker, but also arranges to include the vectors of
  initialization and termination functions.  These functions are called
! via '__main' as described above.  In order to use this method,
! 'use_collect2' must be defined in the target in 'config.gcc'.
  
   The following section describes the specific macros that control and
  customize the handling of initialization and termination functions.
--- 40955,41045 ----
  Much of the structure is common to all four variations.
  
   The linker must build two lists of these functions--a list of
! initialization functions, called ‘__CTOR_LIST__’, and a list of
! termination functions, called ‘__DTOR_LIST__’.
  
   Each list always begins with an ignored function pointer (which may
! hold 0, −1, or a count of the function pointers after it, depending on
  the environment).  This is followed by a series of zero or more function
  pointers to constructors (or destructors), followed by a function
  pointer containing zero.
  
   Depending on the operating system and its executable file format,
! either ‘crtstuff.c’ or ‘libgcc2.c’ traverses these lists at startup time
  and exit time.  Constructors are called in reverse order of the list;
  destructors in forward order.
  
   The best way to handle static constructors works only for object file
  formats which provide arbitrarily-named sections.  A section is set
  aside for a list of constructors, and another for a list of destructors.
! Traditionally these are called ‘.ctors’ and ‘.dtors’.  Each object file
  that defines an initialization function also puts a word in the
  constructor section to point to that function.  The linker accumulates
! all these words into one contiguous ‘.ctors’ section.  Termination
  functions are handled similarly.
  
!  This method will be chosen as the default by ‘target-def.h’ if
! ‘TARGET_ASM_NAMED_SECTION’ is defined.  A target that does not support
  arbitrary sections, but does support special designated constructor and
! destructor sections may define ‘CTORS_SECTION_ASM_OP’ and
! ‘DTORS_SECTION_ASM_OP’ to achieve the same effect.
  
   When arbitrary sections are available, there are two variants,
! depending upon how the code in ‘crtstuff.c’ is called.  On systems that
! support a “.init” section which is executed at program startup, parts of
! ‘crtstuff.c’ are compiled into that section.  The program is linked by
! the ‘gcc’ driver like this:
  
       ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o
  
!  The prologue of a function (‘__init’) appears in the ‘.init’ section of
! ‘crti.o’; the epilogue appears in ‘crtn.o’.  Likewise for the function
! ‘__fini’ in the “.fini” section.  Normally these files are provided by
  the operating system or by the GNU C library, but are provided by GCC
  for a few targets.
  
!  The objects ‘crtbegin.o’ and ‘crtend.o’ are (for most targets) compiled
! from ‘crtstuff.c’.  They contain, among other things, code fragments
! within the ‘.init’ and ‘.fini’ sections that branch to routines in the
! ‘.text’ section.  The linker will pull all parts of a section together,
! which results in a complete ‘__init’ function that invokes the routines
  we need at startup.
  
!  To use this variant, you must define the ‘INIT_SECTION_ASM_OP’ macro
  properly.
  
   If no init section is available, when GCC compiles any function called
! ‘main’ (or more accurately, any function designated as a program entry
! point by the language front end calling ‘expand_main_function’), it
! inserts a procedure call to ‘__main’ as the first executable code after
! the function prologue.  The ‘__main’ function is defined in ‘libgcc2.c’
  and runs the global constructors.
  
   In file formats that don't support arbitrary sections, there are again
! two variants.  In the simplest variant, the GNU linker (GNU ‘ld’) and an
! 'a.out' format must be used.  In this case, ‘TARGET_ASM_CONSTRUCTOR’ is
! defined to produce a ‘.stabs’ entry of type ‘N_SETT’, referencing the
! name ‘__CTOR_LIST__’, and with the address of the void function
  containing the initialization code as its value.  The GNU linker
! recognizes this as a request to add the value to a “set”; the values are
  accumulated, and are eventually placed in the executable as a vector in
  the format described above, with a leading (ignored) count and a
! trailing zero element.  ‘TARGET_ASM_DESTRUCTOR’ is handled similarly.
! Since no init section is available, the absence of ‘INIT_SECTION_ASM_OP’
! causes the compilation of ‘main’ to call ‘__main’ as above, starting the
  initialization process.
  
   The last variant uses neither arbitrary sections nor the GNU linker.
  This is preferable when you want to do dynamic linking and when using
  file formats which the GNU linker does not support, such as 'ECOFF'.  In
! this case, ‘TARGET_HAVE_CTORS_DTORS’ is false, initialization and
  termination functions are recognized simply by their names.  This
! requires an extra program in the linkage step, called ‘collect2’.  This
  program pretends to be the linker, for use with GCC; it does its job by
  running the ordinary linker, but also arranges to include the vectors of
  initialization and termination functions.  These functions are called
! via ‘__main’ as described above.  In order to use this method,
! ‘use_collect2’ must be defined in the target in ‘config.gcc’.
  
   The following section describes the specific macros that control and
  customize the handling of initialization and termination functions.
*************** and termination functions:
*** 41060,41073 ****
       initialization code.  If not defined, GCC will assume such a
       section does not exist.  When you are using special sections for
       initialization and termination functions, this macro also controls
!      how 'crtstuff.c' and 'libgcc2.c' arrange to run the initialization
       functions.
  
   -- Macro: HAS_INIT_SECTION
!      If defined, 'main' will not call '__main' as described above.  This
       macro should be defined for systems that control start-up code on a
       symbol-by-symbol basis, such as OSF/1, and should not be defined
!      explicitly for systems that support 'INIT_SECTION_ASM_OP'.
  
   -- Macro: LD_INIT_SWITCH
       If defined, a C string constant for a switch that tells the linker
--- 41059,41072 ----
       initialization code.  If not defined, GCC will assume such a
       section does not exist.  When you are using special sections for
       initialization and termination functions, this macro also controls
!      how ‘crtstuff.c’ and ‘libgcc2.c’ arrange to run the initialization
       functions.
  
   -- Macro: HAS_INIT_SECTION
!      If defined, ‘main’ will not call ‘__main’ as described above.  This
       macro should be defined for systems that control start-up code on a
       symbol-by-symbol basis, such as OSF/1, and should not be defined
!      explicitly for systems that support ‘INIT_SECTION_ASM_OP’.
  
   -- Macro: LD_INIT_SWITCH
       If defined, a C string constant for a switch that tells the linker
*************** and termination functions:
*** 41082,41088 ****
       automatically called when a shared library is loaded.  The function
       should call FUNC, which takes no arguments.  If not defined, and
       the object format requires an explicit initialization function,
!      then a function called '_GLOBAL__DI' will be generated.
  
       This function and the following one are used by collect2 when
       linking a shared library that needs constructors or destructors, or
--- 41081,41087 ----
       automatically called when a shared library is loaded.  The function
       should call FUNC, which takes no arguments.  If not defined, and
       the object format requires an explicit initialization function,
!      then a function called ‘_GLOBAL__DI’ will be generated.
  
       This function and the following one are used by collect2 when
       linking a shared library that needs constructors or destructors, or
*************** and termination functions:
*** 41093,41117 ****
       automatically called when a shared library is unloaded.  The
       function should call FUNC, which takes no arguments.  If not
       defined, and the object format requires an explicit finalization
!      function, then a function called '_GLOBAL__DD' will be generated.
  
   -- Macro: INVOKE__main
!      If defined, 'main' will call '__main' despite the presence of
!      'INIT_SECTION_ASM_OP'.  This macro should be defined for systems
       where the init section is not actually run automatically, but is
       still useful for collecting the lists of constructors and
       destructors.
  
   -- Macro: SUPPORTS_INIT_PRIORITY
!      If nonzero, the C++ 'init_priority' attribute is supported and the
       compiler should emit instructions to control the order of
       initialization of objects.  If zero, the compiler will issue an
!      error message upon encountering an 'init_priority' attribute.
  
   -- Target Hook: bool TARGET_HAVE_CTORS_DTORS
       This value is true if the target supports some "native" method of
       collecting constructors and destructors to be run at startup and
!      exit.  It is false if we must use 'collect2'.
  
   -- Target Hook: bool TARGET_DTORS_FROM_CXA_ATEXIT
       This value is true if the target wants destructors to be queued to
--- 41092,41116 ----
       automatically called when a shared library is unloaded.  The
       function should call FUNC, which takes no arguments.  If not
       defined, and the object format requires an explicit finalization
!      function, then a function called ‘_GLOBAL__DD’ will be generated.
  
   -- Macro: INVOKE__main
!      If defined, ‘main’ will call ‘__main’ despite the presence of
!      ‘INIT_SECTION_ASM_OP’.  This macro should be defined for systems
       where the init section is not actually run automatically, but is
       still useful for collecting the lists of constructors and
       destructors.
  
   -- Macro: SUPPORTS_INIT_PRIORITY
!      If nonzero, the C++ ‘init_priority’ attribute is supported and the
       compiler should emit instructions to control the order of
       initialization of objects.  If zero, the compiler will issue an
!      error message upon encountering an ‘init_priority’ attribute.
  
   -- Target Hook: bool TARGET_HAVE_CTORS_DTORS
       This value is true if the target supports some "native" method of
       collecting constructors and destructors to be run at startup and
!      exit.  It is false if we must use ‘collect2’.
  
   -- Target Hook: bool TARGET_DTORS_FROM_CXA_ATEXIT
       This value is true if the target wants destructors to be queued to
*************** and termination functions:
*** 41119,41173 ****
       priority level, a new constructor will be entered that registers
       the destructors for that level with __cxa_atexit (and there will be
       no destructors emitted).  It is false the method implied by
!      'have_ctors_dtors' is used.
  
   -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY)
       If defined, a function that outputs assembler code to arrange to
       call the function referenced by SYMBOL at initialization time.
  
!      Assume that SYMBOL is a 'SYMBOL_REF' for a function taking no
       arguments and with no return value.  If the target supports
       initialization priorities, PRIORITY is a value between 0 and
!      'MAX_INIT_PRIORITY'; otherwise it must be 'DEFAULT_INIT_PRIORITY'.
  
       If this macro is not defined by the target, a suitable default will
       be chosen if (1) the target supports arbitrary section names, (2)
!      the target defines 'CTORS_SECTION_ASM_OP', or (3) 'USE_COLLECT2' is
       not defined.
  
   -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY)
!      This is like 'TARGET_ASM_CONSTRUCTOR' but used for termination
       functions rather than initialization functions.
  
!  If 'TARGET_HAVE_CTORS_DTORS' is true, the initialization routine
  generated for the generated object file will have static linkage.
  
!  If your system uses 'collect2' as the means of processing constructors,
! then that program normally uses 'nm' to scan an object file for
  constructor functions to be called.
  
   On certain kinds of systems, you can define this macro to make
! 'collect2' work faster (and, in some cases, make it work at all):
  
   -- Macro: OBJECT_FORMAT_COFF
       Define this macro if the system uses COFF (Common Object File
!      Format) object files, so that 'collect2' can assume this format and
       scan object files directly for dynamic constructor/destructor
       functions.
  
!      This macro is effective only in a native compiler; 'collect2' as
!      part of a cross compiler always uses 'nm' for the target machine.
  
   -- Macro: REAL_NM_FILE_NAME
       Define this macro as a C string constant containing the file name
!      to use to execute 'nm'.  The default is to search the path normally
!      for 'nm'.
  
   -- Macro: NM_FLAGS
!      'collect2' calls 'nm' to scan object files for static constructors
!      and destructors and LTO info.  By default, '-n' is passed.  Define
!      'NM_FLAGS' to a C string constant if other options are needed to
!      get the same output format as GNU 'nm -n' produces.
  
   If your system supports shared libraries and has a program to list the
  dynamic dependencies of a given library or executable, you can define
--- 41118,41172 ----
       priority level, a new constructor will be entered that registers
       the destructors for that level with __cxa_atexit (and there will be
       no destructors emitted).  It is false the method implied by
!      ‘have_ctors_dtors’ is used.
  
   -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY)
       If defined, a function that outputs assembler code to arrange to
       call the function referenced by SYMBOL at initialization time.
  
!      Assume that SYMBOL is a ‘SYMBOL_REF’ for a function taking no
       arguments and with no return value.  If the target supports
       initialization priorities, PRIORITY is a value between 0 and
!      ‘MAX_INIT_PRIORITY’; otherwise it must be ‘DEFAULT_INIT_PRIORITY’.
  
       If this macro is not defined by the target, a suitable default will
       be chosen if (1) the target supports arbitrary section names, (2)
!      the target defines ‘CTORS_SECTION_ASM_OP’, or (3) ‘USE_COLLECT2’ is
       not defined.
  
   -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY)
!      This is like ‘TARGET_ASM_CONSTRUCTOR’ but used for termination
       functions rather than initialization functions.
  
!  If ‘TARGET_HAVE_CTORS_DTORS’ is true, the initialization routine
  generated for the generated object file will have static linkage.
  
!  If your system uses ‘collect2’ as the means of processing constructors,
! then that program normally uses ‘nm’ to scan an object file for
  constructor functions to be called.
  
   On certain kinds of systems, you can define this macro to make
! ‘collect2’ work faster (and, in some cases, make it work at all):
  
   -- Macro: OBJECT_FORMAT_COFF
       Define this macro if the system uses COFF (Common Object File
!      Format) object files, so that ‘collect2’ can assume this format and
       scan object files directly for dynamic constructor/destructor
       functions.
  
!      This macro is effective only in a native compiler; ‘collect2’ as
!      part of a cross compiler always uses ‘nm’ for the target machine.
  
   -- Macro: REAL_NM_FILE_NAME
       Define this macro as a C string constant containing the file name
!      to use to execute ‘nm’.  The default is to search the path normally
!      for ‘nm’.
  
   -- Macro: NM_FLAGS
!      ‘collect2’ calls ‘nm’ to scan object files for static constructors
!      and destructors and LTO info.  By default, ‘-n’ is passed.  Define
!      ‘NM_FLAGS’ to a C string constant if other options are needed to
!      get the same output format as GNU ‘nm -n’ produces.
  
   If your system supports shared libraries and has a program to list the
  dynamic dependencies of a given library or executable, you can define
*************** termination functions in shared librarie
*** 41176,41197 ****
  
   -- Macro: LDD_SUFFIX
       Define this macro to a C string constant containing the name of the
!      program which lists dynamic dependencies, like 'ldd' under SunOS 4.
  
   -- Macro: PARSE_LDD_OUTPUT (PTR)
       Define this macro to be C code that extracts filenames from the
!      output of the program denoted by 'LDD_SUFFIX'.  PTR is a variable
!      of type 'char *' that points to the beginning of a line of output
!      from 'LDD_SUFFIX'.  If the line lists a dynamic dependency, the
       code must advance PTR to the beginning of the filename on that
!      line.  Otherwise, it must set PTR to 'NULL'.
  
   -- Macro: SHLIB_SUFFIX
       Define this macro to a C string constant containing the default
!      shared library extension of the target (e.g., '".so"').  'collect2'
       strips version information after this suffix when generating global
       constructor and destructor names.  This define is only needed on
!      targets that use 'collect2' to process constructors and
       destructors.
  
  
--- 41175,41196 ----
  
   -- Macro: LDD_SUFFIX
       Define this macro to a C string constant containing the name of the
!      program which lists dynamic dependencies, like ‘ldd’ under SunOS 4.
  
   -- Macro: PARSE_LDD_OUTPUT (PTR)
       Define this macro to be C code that extracts filenames from the
!      output of the program denoted by ‘LDD_SUFFIX’.  PTR is a variable
!      of type ‘char *’ that points to the beginning of a line of output
!      from ‘LDD_SUFFIX’.  If the line lists a dynamic dependency, the
       code must advance PTR to the beginning of the filename on that
!      line.  Otherwise, it must set PTR to ‘NULL’.
  
   -- Macro: SHLIB_SUFFIX
       Define this macro to a C string constant containing the default
!      shared library extension of the target (e.g., ‘".so"’).  ‘collect2’
       strips version information after this suffix when generating global
       constructor and destructor names.  This define is only needed on
!      targets that use ‘collect2’ to process constructors and
       destructors.
  
  
*************** This describes assembler instruction out
*** 41211,41230 ****
   -- Macro: ADDITIONAL_REGISTER_NAMES
       If defined, a C initializer for an array of structures containing a
       name and a register number.  This macro defines additional names
!      for hard registers, thus allowing the 'asm' option in declarations
       to refer to registers using alternate names.
  
   -- Macro: OVERLAPPING_REGISTER_NAMES
       If defined, a C initializer for an array of structures containing a
       name, a register number and a count of the number of consecutive
       machine registers the name overlaps.  This macro defines additional
!      names for hard registers, thus allowing the 'asm' option in
       declarations to refer to registers using alternate names.  Unlike
!      'ADDITIONAL_REGISTER_NAMES', this macro should be used when the
       register name implies multiple underlying registers.
  
       This macro should be used when it is important that a clobber in an
!      'asm' statement clobbers all the underlying values implied by the
       register name.  For example, on ARM, clobbering the
       double-precision VFP register "d0" implies clobbering both
       single-precision registers "s0" and "s1".
--- 41210,41229 ----
   -- Macro: ADDITIONAL_REGISTER_NAMES
       If defined, a C initializer for an array of structures containing a
       name and a register number.  This macro defines additional names
!      for hard registers, thus allowing the ‘asm’ option in declarations
       to refer to registers using alternate names.
  
   -- Macro: OVERLAPPING_REGISTER_NAMES
       If defined, a C initializer for an array of structures containing a
       name, a register number and a count of the number of consecutive
       machine registers the name overlaps.  This macro defines additional
!      names for hard registers, thus allowing the ‘asm’ option in
       declarations to refer to registers using alternate names.  Unlike
!      ‘ADDITIONAL_REGISTER_NAMES’, this macro should be used when the
       register name implies multiple underlying registers.
  
       This macro should be used when it is important that a clobber in an
!      ‘asm’ statement clobbers all the underlying values implied by the
       register name.  For example, on ARM, clobbering the
       double-precision VFP register "d0" implies clobbering both
       single-precision registers "s0" and "s1".
*************** This describes assembler instruction out
*** 41235,41241 ****
  
       The definition is a C statement or statements which output an
       assembler instruction opcode to the stdio stream STREAM.  The
!      macro-operand PTR is a variable of type 'char *' which points to
       the opcode name in its "internal" form--the form that is written in
       the machine description.  The definition should output the opcode
       name to STREAM, performing any translation you desire, and
--- 41234,41240 ----
  
       The definition is a C statement or statements which output an
       assembler instruction opcode to the stdio stream STREAM.  The
!      macro-operand PTR is a variable of type ‘char *’ which points to
       the opcode name in its "internal" form--the form that is written in
       the machine description.  The definition should output the opcode
       name to STREAM, performing any translation you desire, and
*************** This describes assembler instruction out
*** 41244,41255 ****
  
       In fact, your macro definition may process less than the entire
       opcode name, or more than the opcode name; but if you want to
!      process text that includes '%'-sequences to substitute operands,
       you must take care of the substitution yourself.  Just be sure to
       increment PTR over whatever text should not be output normally.
  
       If you need to look at the operand values, they can be found as the
!      elements of 'recog_data.operand'.
  
       If the macro definition does nothing, the instruction is output in
       the usual way.
--- 41243,41254 ----
  
       In fact, your macro definition may process less than the entire
       opcode name, or more than the opcode name; but if you want to
!      process text that includes ‘%’-sequences to substitute operands,
       you must take care of the substitution yourself.  Just be sure to
       increment PTR over whatever text should not be output normally.
  
       If you need to look at the operand values, they can be found as the
!      elements of ‘recog_data.operand’.
  
       If the macro definition does nothing, the instruction is output in
       the usual way.
*************** This describes assembler instruction out
*** 41297,41319 ****
       CODE is a value that can be used to specify one of several ways of
       printing the operand.  It is used when identical operands must be
       printed differently depending on the context.  CODE comes from the
!      '%' specification that was used to request printing of the operand.
!      If the specification was just '%DIGIT' then CODE is 0; if the
!      specification was '%LTR DIGIT' then CODE is the ASCII code for LTR.
  
       If X is a register, this macro should print the register's name.
!      The names can be found in an array 'reg_names' whose type is 'char
!      *[]'.  'reg_names' is initialized from 'REGISTER_NAMES'.
  
!      When the machine description has a specification '%PUNCT' (a '%'
       followed by a punctuation character), this macro is called with a
       null pointer for X and the punctuation character for CODE.
  
   -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE)
       A C expression which evaluates to true if CODE is a valid
!      punctuation character for use in the 'PRINT_OPERAND' macro.  If
!      'PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no
!      punctuation characters (except for the standard one, '%') are used
       in this way.
  
   -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X)
--- 41296,41318 ----
       CODE is a value that can be used to specify one of several ways of
       printing the operand.  It is used when identical operands must be
       printed differently depending on the context.  CODE comes from the
!      ‘%’ specification that was used to request printing of the operand.
!      If the specification was just ‘%DIGIT’ then CODE is 0; if the
!      specification was ‘%LTR DIGIT’ then CODE is the ASCII code for LTR.
  
       If X is a register, this macro should print the register's name.
!      The names can be found in an array ‘reg_names’ whose type is ‘char
!      *[]’.  ‘reg_names’ is initialized from ‘REGISTER_NAMES’.
  
!      When the machine description has a specification ‘%PUNCT’ (a ‘%’
       followed by a punctuation character), this macro is called with a
       null pointer for X and the punctuation character for CODE.
  
   -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE)
       A C expression which evaluates to true if CODE is a valid
!      punctuation character for use in the ‘PRINT_OPERAND’ macro.  If
!      ‘PRINT_OPERAND_PUNCT_VALID_P’ is not defined, it means that no
!      punctuation characters (except for the standard one, ‘%’) are used
       in this way.
  
   -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X)
*************** This describes assembler instruction out
*** 41323,41335 ****
  
       On some machines, the syntax for a symbolic address depends on the
       section that the address refers to.  On these machines, define the
!      hook 'TARGET_ENCODE_SECTION_INFO' to store the information into the
!      'symbol_ref', and then check for it here.  *Note Assembler
       Format::.
  
   -- Macro: DBR_OUTPUT_SEQEND (FILE)
       A C statement, to be executed after all slot-filler instructions
!      have been output.  If necessary, call 'dbr_sequence_length' to
       determine the number of slots filled in a sequence (zero if not
       currently outputting a sequence), to decide how many no-ops to
       output, or whatever.
--- 41322,41334 ----
  
       On some machines, the syntax for a symbolic address depends on the
       section that the address refers to.  On these machines, define the
!      hook ‘TARGET_ENCODE_SECTION_INFO’ to store the information into the
!      ‘symbol_ref’, and then check for it here.  *Note Assembler
       Format::.
  
   -- Macro: DBR_OUTPUT_SEQEND (FILE)
       A C statement, to be executed after all slot-filler instructions
!      have been output.  If necessary, call ‘dbr_sequence_length’ to
       determine the number of slots filled in a sequence (zero if not
       currently outputting a sequence), to decide how many no-ops to
       output, or whatever.
*************** This describes assembler instruction out
*** 41341,41363 ****
   Note that output routines for instructions with delay slots must be
  prepared to deal with not being output as part of a sequence (i.e. when
  the scheduling pass is not run, or when no slot fillers could be found.)
! The variable 'final_sequence' is null when not processing a sequence,
! otherwise it contains the 'sequence' rtx being output.
  
   -- Macro: REGISTER_PREFIX
   -- Macro: LOCAL_LABEL_PREFIX
   -- Macro: USER_LABEL_PREFIX
   -- Macro: IMMEDIATE_PREFIX
!      If defined, C string expressions to be used for the '%R', '%L',
!      '%U', and '%I' options of 'asm_fprintf' (see 'final.cc').  These
!      are useful when a single 'md' file must support multiple assembler
!      formats.  In that case, the various 'tm.h' files can define these
       macros differently.
  
   -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT)
!      If defined this macro should expand to a series of 'case'
!      statements which will be parsed inside the 'switch' statement of
!      the 'asm_fprintf' function.  This allows targets to define extra
       printf formats which may useful when generating their assembler
       statements.  Note that uppercase letters are reserved for future
       generic extensions to asm_fprintf, and so are not available to
--- 41340,41362 ----
   Note that output routines for instructions with delay slots must be
  prepared to deal with not being output as part of a sequence (i.e. when
  the scheduling pass is not run, or when no slot fillers could be found.)
! The variable ‘final_sequence’ is null when not processing a sequence,
! otherwise it contains the ‘sequence’ rtx being output.
  
   -- Macro: REGISTER_PREFIX
   -- Macro: LOCAL_LABEL_PREFIX
   -- Macro: USER_LABEL_PREFIX
   -- Macro: IMMEDIATE_PREFIX
!      If defined, C string expressions to be used for the ‘%R’, ‘%L’,
!      ‘%U’, and ‘%I’ options of ‘asm_fprintf’ (see ‘final.cc’).  These
!      are useful when a single ‘md’ file must support multiple assembler
!      formats.  In that case, the various ‘tm.h’ files can define these
       macros differently.
  
   -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT)
!      If defined this macro should expand to a series of ‘case’
!      statements which will be parsed inside the ‘switch’ statement of
!      the ‘asm_fprintf’ function.  This allows targets to define extra
       printf formats which may useful when generating their assembler
       statements.  Note that uppercase letters are reserved for future
       generic extensions to asm_fprintf, and so are not available to
*************** otherwise it contains the 'sequence' rtx
*** 41373,41397 ****
       use, with zero as the first variant.
  
       If this macro is defined, you may use constructs of the form
!           '{option0|option1|option2...}'
       in the output templates of patterns (*note Output Template::) or in
!      the first argument of 'asm_fprintf'.  This construct outputs
!      'option0', 'option1', 'option2', etc., if the value of
!      'ASSEMBLER_DIALECT' is zero, one, two, etc.  Any special characters
       within these strings retain their usual meaning.  If there are
       fewer alternatives within the braces than the value of
!      'ASSEMBLER_DIALECT', the construct outputs nothing.  If it's needed
!      to print curly braces or '|' character in assembler output
!      directly, '%{', '%}' and '%|' can be used.
  
!      If you do not define this macro, the characters '{', '|' and '}' do
       not have any special meaning when used in templates or operands to
!      'asm_fprintf'.
  
!      Define the macros 'REGISTER_PREFIX', 'LOCAL_LABEL_PREFIX',
!      'USER_LABEL_PREFIX' and 'IMMEDIATE_PREFIX' if you can express the
       variations in assembler language syntax with that mechanism.
!      Define 'ASSEMBLER_DIALECT' and use the '{option0|option1}' syntax
       if the syntax variant are larger and involve such things as
       different opcodes or operand order.
  
--- 41372,41396 ----
       use, with zero as the first variant.
  
       If this macro is defined, you may use constructs of the form
!           ‘{option0|option1|option2...}’
       in the output templates of patterns (*note Output Template::) or in
!      the first argument of ‘asm_fprintf’.  This construct outputs
!      ‘option0’, ‘option1’, ‘option2’, etc., if the value of
!      ‘ASSEMBLER_DIALECT’ is zero, one, two, etc.  Any special characters
       within these strings retain their usual meaning.  If there are
       fewer alternatives within the braces than the value of
!      ‘ASSEMBLER_DIALECT’, the construct outputs nothing.  If it's needed
!      to print curly braces or ‘|’ character in assembler output
!      directly, ‘%{’, ‘%}’ and ‘%|’ can be used.
  
!      If you do not define this macro, the characters ‘{’, ‘|’ and ‘}’ do
       not have any special meaning when used in templates or operands to
!      ‘asm_fprintf’.
  
!      Define the macros ‘REGISTER_PREFIX’, ‘LOCAL_LABEL_PREFIX’,
!      ‘USER_LABEL_PREFIX’ and ‘IMMEDIATE_PREFIX’ if you can express the
       variations in assembler language syntax with that mechanism.
!      Define ‘ASSEMBLER_DIALECT’ and use the ‘{option0|option1}’ syntax
       if the syntax variant are larger and involve such things as
       different opcodes or operand order.
  
*************** This concerns dispatch tables.
*** 41418,41424 ****
       pseudo-instruction to generate a difference between two labels.
       VALUE and REL are the numbers of two internal labels.  The
       definitions of these labels are output using
!      '(*targetm.asm_out.internal_label)', and they must be printed in
       the same way here.  For example,
  
            fprintf (STREAM, "\t.word L%d-L%d\n",
--- 41417,41423 ----
       pseudo-instruction to generate a difference between two labels.
       VALUE and REL are the numbers of two internal labels.  The
       definitions of these labels are output using
!      ‘(*targetm.asm_out.internal_label)’, and they must be printed in
       the same way here.  For example,
  
            fprintf (STREAM, "\t.word L%d-L%d\n",
*************** This concerns dispatch tables.
*** 41427,41433 ****
       You must provide this macro on machines where the addresses in a
       dispatch table are relative to the table's own address.  If
       defined, GCC will also use this macro on all machines when
!      producing PIC.  BODY is the body of the 'ADDR_DIFF_VEC'; it is
       provided so that the mode and flags can be read.
  
   -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)
--- 41426,41432 ----
       You must provide this macro on machines where the addresses in a
       dispatch table are relative to the table's own address.  If
       defined, GCC will also use this macro on all machines when
!      producing PIC.  BODY is the body of the ‘ADDR_DIFF_VEC’; it is
       provided so that the mode and flags can be read.
  
   -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)
*************** This concerns dispatch tables.
*** 41438,41459 ****
       stream STREAM an assembler pseudo-instruction to generate a
       reference to a label.  VALUE is the number of an internal label
       whose definition is output using
!      '(*targetm.asm_out.internal_label)'.  For example,
  
            fprintf (STREAM, "\t.word L%d\n", VALUE)
  
   -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)
       Define this if the label before a jump-table needs to be output
       specially.  The first three arguments are the same as for
!      '(*targetm.asm_out.internal_label)'; the fourth argument is the
!      jump-table which follows (a 'jump_table_data' containing an
!      'addr_vec' or 'addr_diff_vec').
  
!      This feature is used on system V to output a 'swbeg' statement for
       the table.
  
       If this macro is not defined, these labels are output with
!      '(*targetm.asm_out.internal_label)'.
  
   -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)
       Define this if something special must be output at the end of a
--- 41437,41458 ----
       stream STREAM an assembler pseudo-instruction to generate a
       reference to a label.  VALUE is the number of an internal label
       whose definition is output using
!      ‘(*targetm.asm_out.internal_label)’.  For example,
  
            fprintf (STREAM, "\t.word L%d\n", VALUE)
  
   -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)
       Define this if the label before a jump-table needs to be output
       specially.  The first three arguments are the same as for
!      ‘(*targetm.asm_out.internal_label)’; the fourth argument is the
!      jump-table which follows (a ‘jump_table_data’ containing an
!      ‘addr_vec’ or ‘addr_diff_vec’).
  
!      This feature is used on system V to output a ‘swbeg’ statement for
       the table.
  
       If this macro is not defined, these labels are output with
!      ‘(*targetm.asm_out.internal_label)’.
  
   -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)
       Define this if something special must be output at the end of a
*************** This concerns dispatch tables.
*** 41496,41502 ****
  
   -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx
            PERSONALITY)
!      If the target implements 'TARGET_ASM_UNWIND_EMIT', this hook may be
       used to emit a directive to install a personality hook into the
       unwind info.  This hook should not be used if dwarf2 unwind info is
       used.
--- 41495,41501 ----
  
   -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx
            PERSONALITY)
!      If the target implements ‘TARGET_ASM_UNWIND_EMIT’, this hook may be
       used to emit a directive to install a personality hook into the
       unwind info.  This hook should not be used if dwarf2 unwind info is
       used.
*************** This concerns dispatch tables.
*** 41505,41520 ****
            *INSN)
       This target hook emits assembly directives required to unwind the
       given instruction.  This is only used when
!      'TARGET_EXCEPT_UNWIND_INFO' returns 'UI_TARGET'.
  
   -- Target Hook: rtx TARGET_ASM_MAKE_EH_SYMBOL_INDIRECT (rtx ORIGSYMBOL,
            bool PUBVIS)
       If necessary, modify personality and LSDA references to handle
!      indirection.  The original symbol is in 'origsymbol' and if
!      'pubvis' is true the symbol is visible outside the TU.
  
   -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN
!      True if the 'TARGET_ASM_UNWIND_EMIT' hook should be called before
       the assembly for INSN has been emitted, false if the hook should be
       called afterward.
  
--- 41504,41519 ----
            *INSN)
       This target hook emits assembly directives required to unwind the
       given instruction.  This is only used when
!      ‘TARGET_EXCEPT_UNWIND_INFO’ returns ‘UI_TARGET’.
  
   -- Target Hook: rtx TARGET_ASM_MAKE_EH_SYMBOL_INDIRECT (rtx ORIGSYMBOL,
            bool PUBVIS)
       If necessary, modify personality and LSDA references to handle
!      indirection.  The original symbol is in ‘origsymbol’ and if
!      ‘pubvis’ is true the symbol is visible outside the TU.
  
   -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN
!      True if the ‘TARGET_ASM_UNWIND_EMIT’ hook should be called before
       the assembly for INSN has been emitted, false if the hook should be
       called afterward.
  
*************** region.
*** 41542,41548 ****
       If defined, a C string constant for the name of the section
       containing exception handling frame unwind information.  If not
       defined, GCC will provide a default definition if the target
!      supports named sections.  'crtstuff.c' uses this macro to switch to
       the appropriate section.
  
       You should define this symbol if your target supports DWARF 2 frame
--- 41541,41547 ----
       If defined, a C string constant for the name of the section
       containing exception handling frame unwind information.  If not
       defined, GCC will provide a default definition if the target
!      supports named sections.  ‘crtstuff.c’ uses this macro to switch to
       the appropriate section.
  
       You should define this symbol if your target supports DWARF 2 frame
*************** region.
*** 41554,41560 ****
       labels and generate code to register the frames.
  
       This might be necessary, for instance, if the system linker will
!      not place the eh_frames in-between the sentinals from 'crtstuff.c',
       or if the system linker does garbage collection and sections cannot
       be marked as not to be collected.
  
--- 41553,41559 ----
       labels and generate code to register the frames.
  
       This might be necessary, for instance, if the system linker will
!      not place the eh_frames in-between the sentinals from ‘crtstuff.c’,
       or if the system linker does garbage collection and sections cannot
       be marked as not to be collected.
  
*************** region.
*** 41565,41636 ****
       read-only and read-write sections into a single read-write section.
  
   -- Macro: MASK_RETURN_ADDR
!      An rtx used to mask the return address found via 'RETURN_ADDR_RTX',
       so that it does not contain any extraneous set bits in it.
  
   -- Macro: DWARF2_UNWIND_INFO
       Define this macro to 0 if your target supports DWARF 2 frame unwind
       information, but it does not yet work with exception handling.
       Otherwise, if your target supports this information (if it defines
!      'INCOMING_RETURN_ADDR_RTX' and 'OBJECT_FORMAT_ELF'), GCC will
       provide a default definition of 1.
  
   -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO
            (struct gcc_options *OPTS)
       This hook defines the mechanism that will be used for exception
       handling by the target.  If the target has ABI specified unwind
!      tables, the hook should return 'UI_TARGET'.  If the target is to
!      use the 'setjmp'/'longjmp'-based exception handling scheme, the
!      hook should return 'UI_SJLJ'.  If the target supports DWARF 2 frame
!      unwind information, the hook should return 'UI_DWARF2'.
  
       A target may, if exceptions are disabled, choose to return
!      'UI_NONE'.  This may end up simplifying other parts of
       target-specific code.  The default implementation of this hook
!      never returns 'UI_NONE'.
  
       Note that the value returned by this hook should be constant.  It
       should not depend on anything except the command-line switches
!      described by OPTS.  In particular, the setting 'UI_SJLJ' must be
       fixed at compiler start-up as C pre-processor macros and builtin
       functions related to exception handling are set up depending on
       this setting.
  
       The default implementation of the hook first honors the
!      '--enable-sjlj-exceptions' configure option, then
!      'DWARF2_UNWIND_INFO', and finally defaults to 'UI_SJLJ'.  If
!      'DWARF2_UNWIND_INFO' depends on command-line options, the target
       must define this hook so that OPTS is used correctly.
  
   -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT
!      This variable should be set to 'true' if the target ABI requires
       unwinding tables even when exceptions are not used.  It must not be
       modified by command-line option processing.
  
   -- Macro: DONT_USE_BUILTIN_SETJMP
!      Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme
!      should use the 'setjmp'/'longjmp' functions from the C library
!      instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery.
  
   -- Macro: JMP_BUF_SIZE
!      This macro has no effect unless 'DONT_USE_BUILTIN_SETJMP' is also
!      defined.  Define this macro if the default size of 'jmp_buf' buffer
!      for the 'setjmp'/'longjmp'-based exception handling mechanism is
       not large enough, or if it is much too large.  The default size is
!      'FIRST_PSEUDO_REGISTER * sizeof(void *)'.
  
   -- Macro: DWARF_CIE_DATA_ALIGNMENT
       This macro need only be defined if the target might save registers
       in the function prologue at an offset to the stack pointer that is
!      not aligned to 'UNITS_PER_WORD'.  The definition should be the
!      negative minimum alignment if 'STACK_GROWS_DOWNWARD' is true, and
       the positive minimum alignment otherwise.  *Note DWARF::.  Only
       applicable if the target supports DWARF 2 frame unwind information.
  
   -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO
       Contains the value true if the target should add a zero word onto
       the end of a Dwarf-2 frame info section when used for exception
!      handling.  Default value is false if 'EH_FRAME_SECTION_NAME' is
       defined, and true otherwise.
  
   -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG)
--- 41564,41635 ----
       read-only and read-write sections into a single read-write section.
  
   -- Macro: MASK_RETURN_ADDR
!      An rtx used to mask the return address found via ‘RETURN_ADDR_RTX’,
       so that it does not contain any extraneous set bits in it.
  
   -- Macro: DWARF2_UNWIND_INFO
       Define this macro to 0 if your target supports DWARF 2 frame unwind
       information, but it does not yet work with exception handling.
       Otherwise, if your target supports this information (if it defines
!      ‘INCOMING_RETURN_ADDR_RTX’ and ‘OBJECT_FORMAT_ELF’), GCC will
       provide a default definition of 1.
  
   -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO
            (struct gcc_options *OPTS)
       This hook defines the mechanism that will be used for exception
       handling by the target.  If the target has ABI specified unwind
!      tables, the hook should return ‘UI_TARGET’.  If the target is to
!      use the ‘setjmp’/‘longjmp’-based exception handling scheme, the
!      hook should return ‘UI_SJLJ’.  If the target supports DWARF 2 frame
!      unwind information, the hook should return ‘UI_DWARF2’.
  
       A target may, if exceptions are disabled, choose to return
!      ‘UI_NONE’.  This may end up simplifying other parts of
       target-specific code.  The default implementation of this hook
!      never returns ‘UI_NONE’.
  
       Note that the value returned by this hook should be constant.  It
       should not depend on anything except the command-line switches
!      described by OPTS.  In particular, the setting ‘UI_SJLJ’ must be
       fixed at compiler start-up as C pre-processor macros and builtin
       functions related to exception handling are set up depending on
       this setting.
  
       The default implementation of the hook first honors the
!      ‘--enable-sjlj-exceptions’ configure option, then
!      ‘DWARF2_UNWIND_INFO’, and finally defaults to ‘UI_SJLJ’.  If
!      ‘DWARF2_UNWIND_INFO’ depends on command-line options, the target
       must define this hook so that OPTS is used correctly.
  
   -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT
!      This variable should be set to ‘true’ if the target ABI requires
       unwinding tables even when exceptions are not used.  It must not be
       modified by command-line option processing.
  
   -- Macro: DONT_USE_BUILTIN_SETJMP
!      Define this macro to 1 if the ‘setjmp’/‘longjmp’-based scheme
!      should use the ‘setjmp’/‘longjmp’ functions from the C library
!      instead of the ‘__builtin_setjmp’/‘__builtin_longjmp’ machinery.
  
   -- Macro: JMP_BUF_SIZE
!      This macro has no effect unless ‘DONT_USE_BUILTIN_SETJMP’ is also
!      defined.  Define this macro if the default size of ‘jmp_buf’ buffer
!      for the ‘setjmp’/‘longjmp’-based exception handling mechanism is
       not large enough, or if it is much too large.  The default size is
!      ‘FIRST_PSEUDO_REGISTER * sizeof(void *)’.
  
   -- Macro: DWARF_CIE_DATA_ALIGNMENT
       This macro need only be defined if the target might save registers
       in the function prologue at an offset to the stack pointer that is
!      not aligned to ‘UNITS_PER_WORD’.  The definition should be the
!      negative minimum alignment if ‘STACK_GROWS_DOWNWARD’ is true, and
       the positive minimum alignment otherwise.  *Note DWARF::.  Only
       applicable if the target supports DWARF 2 frame unwind information.
  
   -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO
       Contains the value true if the target should add a zero word onto
       the end of a Dwarf-2 frame info section when used for exception
!      handling.  Default value is false if ‘EH_FRAME_SECTION_NAME’ is
       defined, and true otherwise.
  
   -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG)
*************** region.
*** 41639,41646 ****
       if the register and its mode are represented in Dwarf in
       non-contiguous locations, or if the register should be represented
       in more than one register in Dwarf.  Otherwise, this hook should
!      return 'NULL_RTX'.  If not defined, the default is to return
!      'NULL_RTX'.
  
   -- Target Hook: machine_mode TARGET_DWARF_FRAME_REG_MODE (int REGNO)
       Given a register, this hook should return the mode which the
--- 41638,41645 ----
       if the register and its mode are represented in Dwarf in
       non-contiguous locations, or if the register should be represented
       in more than one register in Dwarf.  Otherwise, this hook should
!      return ‘NULL_RTX’.  If not defined, the default is to return
!      ‘NULL_RTX’.
  
   -- Target Hook: machine_mode TARGET_DWARF_FRAME_REG_MODE (int REGNO)
       Given a register, this hook should return the mode which the
*************** region.
*** 41652,41672 ****
       If some registers are represented in Dwarf-2 unwind information in
       multiple pieces, define this hook to fill in information about the
       sizes of those pieces in the table used by the unwinder at runtime.
!      It will be called by 'expand_builtin_init_dwarf_reg_sizes' after
       filling in a single size corresponding to each hard register;
       ADDRESS is the address of the table.
  
   -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM)
       This hook is used to output a reference from a frame unwinding
       table to the type_info object identified by SYM.  It should return
!      'true' if the reference was output.  Returning 'false' will cause
       the reference to be output using the normal Dwarf2 routines.
  
   -- Target Hook: bool TARGET_ARM_EABI_UNWINDER
!      This flag should be set to 'true' on targets that use an ARM EABI
!      based unwinding library, and 'false' on other targets.  This
       effects the format of unwinding tables, and how the unwinder in
!      entered after running a cleanup.  The default is 'false'.
  
  
  File: gccint.info,  Node: Alignment Output,  Prev: Exception Region Output,  Up: Assembler Format
--- 41651,41671 ----
       If some registers are represented in Dwarf-2 unwind information in
       multiple pieces, define this hook to fill in information about the
       sizes of those pieces in the table used by the unwinder at runtime.
!      It will be called by ‘expand_builtin_init_dwarf_reg_sizes’ after
       filling in a single size corresponding to each hard register;
       ADDRESS is the address of the table.
  
   -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM)
       This hook is used to output a reference from a frame unwinding
       table to the type_info object identified by SYM.  It should return
!      ‘true’ if the reference was output.  Returning ‘false’ will cause
       the reference to be output using the normal Dwarf2 routines.
  
   -- Target Hook: bool TARGET_ARM_EABI_UNWINDER
!      This flag should be set to ‘true’ on targets that use an ARM EABI
!      based unwinding library, and ‘false’ on other targets.  This
       effects the format of unwinding tables, and how the unwinder in
!      entered after running a cleanup.  The default is ‘false’.
  
  
  File: gccint.info,  Node: Alignment Output,  Prev: Exception Region Output,  Up: Assembler Format
*************** This describes commands for alignment.
*** 41686,41697 ****
  
       Unless it's necessary to inspect the LABEL parameter, it is better
       to set the variable ALIGN_JUMPS in the target's
!      'TARGET_OPTION_OVERRIDE'.  Otherwise, you should try to honor the
!      user's selection in ALIGN_JUMPS in a 'JUMP_ALIGN' implementation.
  
   -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL)
       The alignment (log base 2) to put in front of LABEL, which follows
!      a 'BARRIER'.
  
       This macro need not be defined if you don't want any special
       alignment to be done at such a time.  Most machine descriptions do
--- 41685,41696 ----
  
       Unless it's necessary to inspect the LABEL parameter, it is better
       to set the variable ALIGN_JUMPS in the target's
!      ‘TARGET_OPTION_OVERRIDE’.  Otherwise, you should try to honor the
!      user's selection in ALIGN_JUMPS in a ‘JUMP_ALIGN’ implementation.
  
   -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL)
       The alignment (log base 2) to put in front of LABEL, which follows
!      a ‘BARRIER’.
  
       This macro need not be defined if you don't want any special
       alignment to be done at such a time.  Most machine descriptions do
*************** This describes commands for alignment.
*** 41706,41734 ****
       not currently define the macro.
  
       Unless it's necessary to inspect the LABEL parameter, it is better
!      to set the variable 'align_loops' in the target's
!      'TARGET_OPTION_OVERRIDE'.  Otherwise, you should try to honor the
!      user's selection in 'align_loops' in a 'LOOP_ALIGN' implementation.
  
   -- Macro: LABEL_ALIGN (LABEL)
       The alignment (log base 2) to put in front of LABEL.  If
!      'LABEL_ALIGN_AFTER_BARRIER' / 'LOOP_ALIGN' specify a different
       alignment, the maximum of the specified values is used.
  
       Unless it's necessary to inspect the LABEL parameter, it is better
!      to set the variable 'align_labels' in the target's
!      'TARGET_OPTION_OVERRIDE'.  Otherwise, you should try to honor the
!      user's selection in 'align_labels' in a 'LABEL_ALIGN'
       implementation.
  
   -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES)
       A C statement to output to the stdio stream STREAM an assembler
       instruction to advance the location counter by NBYTES bytes.  Those
       bytes should be zero when loaded.  NBYTES will be a C expression of
!      type 'unsigned HOST_WIDE_INT'.
  
   -- Macro: ASM_NO_SKIP_IN_TEXT
!      Define this macro if 'ASM_OUTPUT_SKIP' should not be used in the
       text section because it fails to put zeros in the bytes that are
       skipped.  This is true on many Unix systems, where the pseudo-op to
       skip bytes produces no-op instructions rather than zeros when used
--- 41705,41733 ----
       not currently define the macro.
  
       Unless it's necessary to inspect the LABEL parameter, it is better
!      to set the variable ‘align_loops’ in the target's
!      ‘TARGET_OPTION_OVERRIDE’.  Otherwise, you should try to honor the
!      user's selection in ‘align_loops’ in a ‘LOOP_ALIGN’ implementation.
  
   -- Macro: LABEL_ALIGN (LABEL)
       The alignment (log base 2) to put in front of LABEL.  If
!      ‘LABEL_ALIGN_AFTER_BARRIER’ / ‘LOOP_ALIGN’ specify a different
       alignment, the maximum of the specified values is used.
  
       Unless it's necessary to inspect the LABEL parameter, it is better
!      to set the variable ‘align_labels’ in the target's
!      ‘TARGET_OPTION_OVERRIDE’.  Otherwise, you should try to honor the
!      user's selection in ‘align_labels’ in a ‘LABEL_ALIGN’
       implementation.
  
   -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES)
       A C statement to output to the stdio stream STREAM an assembler
       instruction to advance the location counter by NBYTES bytes.  Those
       bytes should be zero when loaded.  NBYTES will be a C expression of
!      type ‘unsigned HOST_WIDE_INT’.
  
   -- Macro: ASM_NO_SKIP_IN_TEXT
!      Define this macro if ‘ASM_OUTPUT_SKIP’ should not be used in the
       text section because it fails to put zeros in the bytes that are
       skipped.  This is true on many Unix systems, where the pseudo-op to
       skip bytes produces no-op instructions rather than zeros when used
*************** This describes commands for alignment.
*** 41737,41746 ****
   -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER)
       A C statement to output to the stdio stream STREAM an assembler
       command to advance the location counter to a multiple of 2 to the
!      POWER bytes.  POWER will be a C expression of type 'int'.
  
   -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER)
!      Like 'ASM_OUTPUT_ALIGN', except that the "nop" instruction is used
       for padding, if necessary.
  
   -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP)
--- 41736,41745 ----
   -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER)
       A C statement to output to the stdio stream STREAM an assembler
       command to advance the location counter to a multiple of 2 to the
!      POWER bytes.  POWER will be a C expression of type ‘int’.
  
   -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER)
!      Like ‘ASM_OUTPUT_ALIGN’, except that the "nop" instruction is used
       for padding, if necessary.
  
   -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP)
*************** This describes commands for alignment.
*** 41748,41754 ****
       command to advance the location counter to a multiple of 2 to the
       POWER bytes, but only if MAX_SKIP or fewer bytes are needed to
       satisfy the alignment request.  POWER and MAX_SKIP will be a C
!      expression of type 'int'.
  
  
  File: gccint.info,  Node: Debugging Info,  Next: Floating Point,  Prev: Assembler Format,  Up: Target Macros
--- 41747,41753 ----
       command to advance the location counter to a multiple of 2 to the
       POWER bytes, but only if MAX_SKIP or fewer bytes are needed to
       satisfy the alignment request.  POWER and MAX_SKIP will be a C
!      expression of type ‘int’.
  
  
  File: gccint.info,  Node: Debugging Info,  Next: Floating Point,  Prev: Assembler Format,  Up: Target Macros
*************** These macros affect all debugging format
*** 41784,41795 ****
  
       If two registers have consecutive numbers inside GCC, and they can
       be used as a pair to hold a multiword value, then they _must_ have
!      consecutive numbers after renumbering with 'DEBUGGER_REGNO'.
       Otherwise, debuggers will be unable to access such a pair, because
       they expect register pairs to be consecutive in their own numbering
       scheme.
  
!      If you find yourself defining 'DEBUGGER_REGNO' in way that does not
       preserve register pairs, then what you must do instead is redefine
       the actual register numbering scheme.
  
--- 41783,41794 ----
  
       If two registers have consecutive numbers inside GCC, and they can
       be used as a pair to hold a multiword value, then they _must_ have
!      consecutive numbers after renumbering with ‘DEBUGGER_REGNO’.
       Otherwise, debuggers will be unable to access such a pair, because
       they expect register pairs to be consecutive in their own numbering
       scheme.
  
!      If you find yourself defining ‘DEBUGGER_REGNO’ in way that does not
       preserve register pairs, then what you must do instead is redefine
       the actual register numbering scheme.
  
*************** These macros affect all debugging format
*** 41799,41805 ****
       default computation assumes that X is based on the frame-pointer
       and gives the offset from the frame-pointer.  This is required for
       targets that produce debugging output for debugger and allow the
!      frame-pointer to be eliminated when the '-g' option is used.
  
   -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X)
       A C expression that returns the integer offset value for an
--- 41798,41804 ----
       default computation assumes that X is based on the frame-pointer
       and gives the offset from the frame-pointer.  This is required for
       targets that produce debugging output for debugger and allow the
!      frame-pointer to be eliminated when the ‘-g’ option is used.
  
   -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X)
       A C expression that returns the integer offset value for an
*************** These macros affect all debugging format
*** 41808,41826 ****
  
   -- Macro: PREFERRED_DEBUGGING_TYPE
       A C expression that returns the type of debugging output GCC should
!      produce when the user specifies just '-g'.  Define this if you have
       arranged for GCC to support more than one format of debugging
!      output.  Currently, the allowable values are 'DWARF2_DEBUG',
!      'VMS_DEBUG', and 'VMS_AND_DWARF2_DEBUG'.
  
!      When the user specifies '-ggdb', GCC normally also uses the value
       of this macro to select the debugging output format, but with two
!      exceptions.  If 'DWARF2_DEBUGGING_INFO' is defined, GCC uses the
!      value 'DWARF2_DEBUG'.
  
       The value of this macro only affects the default debugging output;
       the user can always get a specific type of output by using
!      '-gdwarf-2', or '-gvms'.
  
   -- Macro: DEFAULT_GDB_EXTENSIONS
       Define this macro to control whether GCC should by default generate
--- 41807,41825 ----
  
   -- Macro: PREFERRED_DEBUGGING_TYPE
       A C expression that returns the type of debugging output GCC should
!      produce when the user specifies just ‘-g’.  Define this if you have
       arranged for GCC to support more than one format of debugging
!      output.  Currently, the allowable values are ‘DWARF2_DEBUG’,
!      ‘VMS_DEBUG’, and ‘VMS_AND_DWARF2_DEBUG’.
  
!      When the user specifies ‘-ggdb’, GCC normally also uses the value
       of this macro to select the debugging output format, but with two
!      exceptions.  If ‘DWARF2_DEBUGGING_INFO’ is defined, GCC uses the
!      value ‘DWARF2_DEBUG’.
  
       The value of this macro only affects the default debugging output;
       the user can always get a specific type of output by using
!      ‘-gdwarf-2’, or ‘-gvms’.
  
   -- Macro: DEFAULT_GDB_EXTENSIONS
       Define this macro to control whether GCC should by default generate
*************** Here are macros for DWARF output.
*** 41838,41874 ****
  
   -- Macro: DWARF2_DEBUGGING_INFO
       Define this macro if GCC should produce dwarf version 2 format
!      debugging output in response to the '-g' option.
  
       To support optional call frame debugging information, you must also
!      define 'INCOMING_RETURN_ADDR_RTX' and either set
!      'RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the
!      prologue, or call 'dwarf2out_def_cfa' and 'dwarf2out_reg_save' as
!      appropriate from 'TARGET_ASM_FUNCTION_PROLOGUE' if you don't.
  
   -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree
            FUNCTION)
       Define this to enable the dwarf attribute
!      'DW_AT_calling_convention' to be emitted for each function.
!      Instead of an integer return the enum value for the 'DW_CC_' tag.
  
   -- Macro: DWARF2_FRAME_INFO
       Define this macro to a nonzero value if GCC should always output
!      Dwarf 2 frame information.  If 'TARGET_EXCEPT_UNWIND_INFO' (*note
!      Exception Region Output::) returns 'UI_DWARF2', and exceptions are
       enabled, GCC will output this information not matter how you define
!      'DWARF2_FRAME_INFO'.
  
   -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void)
       This hook defines the mechanism that will be used for describing
       frame unwind information to the debugger.  Normally the hook will
!      return 'UI_DWARF2' if DWARF 2 debug information is enabled, and
!      return 'UI_NONE' otherwise.
  
!      A target may return 'UI_DWARF2' even when DWARF 2 debug information
       is disabled in order to always output DWARF 2 frame information.
  
!      A target may return 'UI_TARGET' if it has ABI specified unwind
       tables.  This will suppress generation of the normal debug frame
       unwind information.
  
--- 41837,41873 ----
  
   -- Macro: DWARF2_DEBUGGING_INFO
       Define this macro if GCC should produce dwarf version 2 format
!      debugging output in response to the ‘-g’ option.
  
       To support optional call frame debugging information, you must also
!      define ‘INCOMING_RETURN_ADDR_RTX’ and either set
!      ‘RTX_FRAME_RELATED_P’ on the prologue insns if you use RTL for the
!      prologue, or call ‘dwarf2out_def_cfa’ and ‘dwarf2out_reg_save’ as
!      appropriate from ‘TARGET_ASM_FUNCTION_PROLOGUE’ if you don't.
  
   -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree
            FUNCTION)
       Define this to enable the dwarf attribute
!      ‘DW_AT_calling_convention’ to be emitted for each function.
!      Instead of an integer return the enum value for the ‘DW_CC_’ tag.
  
   -- Macro: DWARF2_FRAME_INFO
       Define this macro to a nonzero value if GCC should always output
!      Dwarf 2 frame information.  If ‘TARGET_EXCEPT_UNWIND_INFO’ (*note
!      Exception Region Output::) returns ‘UI_DWARF2’, and exceptions are
       enabled, GCC will output this information not matter how you define
!      ‘DWARF2_FRAME_INFO’.
  
   -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void)
       This hook defines the mechanism that will be used for describing
       frame unwind information to the debugger.  Normally the hook will
!      return ‘UI_DWARF2’ if DWARF 2 debug information is enabled, and
!      return ‘UI_NONE’ otherwise.
  
!      A target may return ‘UI_DWARF2’ even when DWARF 2 debug information
       is disabled in order to always output DWARF 2 frame information.
  
!      A target may return ‘UI_TARGET’ if it has ABI specified unwind
       tables.  This will suppress generation of the normal debug frame
       unwind information.
  
*************** Here are macros for DWARF output.
*** 41880,41886 ****
  
   -- Macro: DWARF2_ASM_VIEW_DEBUG_INFO
       Define this macro to be a nonzero value if the assembler supports
!      view assignment and verification in '.loc'.  If it does not, but
       the user enables location views, the compiler may have to fallback
       to internal line number tables.
  
--- 41879,41885 ----
  
   -- Macro: DWARF2_ASM_VIEW_DEBUG_INFO
       Define this macro to be a nonzero value if the assembler supports
!      view assignment and verification in ‘.loc’.  If it does not, but
       the user enables location views, the compiler may have to fallback
       to internal line number tables.
  
*************** Here are macros for DWARF output.
*** 41897,41906 ****
       be reset; or zero to decide based on the estimated insn length.
  
       If insn length is to be regarded as reliable, set the hook to
!      'hook_int_rtx_insn_0'.
  
   -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS
!      True if the '.debug_pubtypes' and '.debug_pubnames' sections should
       be emitted.  These sections are not used on most platforms, and in
       particular GDB does not use them.
  
--- 41896,41905 ----
       be reset; or zero to decide based on the estimated insn length.
  
       If insn length is to be regarded as reliable, set the hook to
!      ‘hook_int_rtx_insn_0’.
  
   -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS
!      True if the ‘.debug_pubtypes’ and ‘.debug_pubnames’ sections should
       be emitted.  These sections are not used on most platforms, and in
       particular GDB does not use them.
  
*************** Here are macros for VMS debug format.
*** 41964,41974 ****
  
   -- Macro: VMS_DEBUGGING_INFO
       Define this macro if GCC should produce debugging output for VMS in
!      response to the '-g' option.  The default behavior for VMS is to
!      generate minimal debug info for a traceback in the absence of '-g'
!      unless explicitly overridden with '-g0'.  This behavior is
!      controlled by 'TARGET_OPTION_OPTIMIZATION' and
!      'TARGET_OPTION_OVERRIDE'.
  
  
  File: gccint.info,  Node: CTF Debug,  Next: BTF Debug,  Prev: VMS Debug,  Up: Debugging Info
--- 41963,41973 ----
  
   -- Macro: VMS_DEBUGGING_INFO
       Define this macro if GCC should produce debugging output for VMS in
!      response to the ‘-g’ option.  The default behavior for VMS is to
!      generate minimal debug info for a traceback in the absence of ‘-g’
!      unless explicitly overridden with ‘-g0’.  This behavior is
!      controlled by ‘TARGET_OPTION_OPTIMIZATION’ and
!      ‘TARGET_OPTION_OVERRIDE’.
  
  
  File: gccint.info,  Node: CTF Debug,  Next: BTF Debug,  Prev: VMS Debug,  Up: Debugging Info
*************** Here are macros for CTF debug format.
*** 41980,41986 ****
  
   -- Macro: CTF_DEBUGGING_INFO
       Define this macro if GCC should produce debugging output in CTF
!      debug format in response to the '-gctf' option.
  
  
  File: gccint.info,  Node: BTF Debug,  Prev: CTF Debug,  Up: Debugging Info
--- 41979,41985 ----
  
   -- Macro: CTF_DEBUGGING_INFO
       Define this macro if GCC should produce debugging output in CTF
!      debug format in response to the ‘-gctf’ option.
  
  
  File: gccint.info,  Node: BTF Debug,  Prev: CTF Debug,  Up: Debugging Info
*************** Here are macros for BTF debug format.
*** 41992,41998 ****
  
   -- Macro: BTF_DEBUGGING_INFO
       Define this macro if GCC should produce debugging output in BTF
!      debug format in response to the '-gbtf' option.
  
  
  File: gccint.info,  Node: Floating Point,  Next: Mode Switching,  Prev: Debugging Info,  Up: Target Macros
--- 41991,41997 ----
  
   -- Macro: BTF_DEBUGGING_INFO
       Define this macro if GCC should produce debugging output in BTF
!      debug format in response to the ‘-gbtf’ option.
  
  
  File: gccint.info,  Node: Floating Point,  Next: Mode Switching,  Prev: Debugging Info,  Up: Target Macros
*************** the target's arithmetic.  To ensure cons
*** 42014,42028 ****
  emulation to work with floating point values, even when the host and
  target floating point formats are identical.
  
!  The following macros are provided by 'real.h' for the compiler to use.
  All parts of the compiler which generate or optimize floating-point
  calculations must use these macros.  They may evaluate their operands
  more than once, so operands must not have side effects.
  
   -- Macro: REAL_VALUE_TYPE
       The C data type to be used to hold a floating point value in the
!      target machine's format.  Typically this is a 'struct' containing
!      an array of 'HOST_WIDE_INT', but all code should treat it as an
       opaque quantity.
  
   -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X)
--- 42013,42027 ----
  emulation to work with floating point values, even when the host and
  target floating point formats are identical.
  
!  The following macros are provided by ‘real.h’ for the compiler to use.
  All parts of the compiler which generate or optimize floating-point
  calculations must use these macros.  They may evaluate their operands
  more than once, so operands must not have side effects.
  
   -- Macro: REAL_VALUE_TYPE
       The C data type to be used to hold a floating point value in the
!      target machine's format.  Typically this is a ‘struct’ containing
!      an array of ‘HOST_WIDE_INT’, but all code should treat it as an
       opaque quantity.
  
   -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X)
*************** The following macros control mode switch
*** 42074,42092 ****
       PR bit requires a general purpose register as a scratch register,
       hence these FPSCR sets have to be inserted before reload, i.e. you
       cannot put this into instruction emitting or
!      'TARGET_MACHINE_DEPENDENT_REORG'.
  
       You can have multiple entities that are mode-switched, and select
       at run time which entities actually need it.
!      'OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY that
       needs mode-switching.  If you define this macro, you also have to
!      define 'NUM_MODES_FOR_MODE_SWITCHING', 'TARGET_MODE_NEEDED',
!      'TARGET_MODE_PRIORITY' and 'TARGET_MODE_EMIT'.
!      'TARGET_MODE_AFTER', 'TARGET_MODE_ENTRY', and 'TARGET_MODE_EXIT'
       are optional.
  
   -- Macro: NUM_MODES_FOR_MODE_SWITCHING
!      If you define 'OPTIMIZE_MODE_SWITCHING', you have to define this as
       initializer for an array of integers.  Each initializer element N
       refers to an entity that needs mode switching, and specifies the
       number of different modes that might need to be set for this
--- 42073,42091 ----
       PR bit requires a general purpose register as a scratch register,
       hence these FPSCR sets have to be inserted before reload, i.e. you
       cannot put this into instruction emitting or
!      ‘TARGET_MACHINE_DEPENDENT_REORG’.
  
       You can have multiple entities that are mode-switched, and select
       at run time which entities actually need it.
!      ‘OPTIMIZE_MODE_SWITCHING’ should return nonzero for any ENTITY that
       needs mode-switching.  If you define this macro, you also have to
!      define ‘NUM_MODES_FOR_MODE_SWITCHING’, ‘TARGET_MODE_NEEDED’,
!      ‘TARGET_MODE_PRIORITY’ and ‘TARGET_MODE_EMIT’.
!      ‘TARGET_MODE_AFTER’, ‘TARGET_MODE_ENTRY’, and ‘TARGET_MODE_EXIT’
       are optional.
  
   -- Macro: NUM_MODES_FOR_MODE_SWITCHING
!      If you define ‘OPTIMIZE_MODE_SWITCHING’, you have to define this as
       initializer for an array of integers.  Each initializer element N
       refers to an entity that needs mode switching, and specifies the
       number of different modes that might need to be set for this
*************** The following macros control mode switch
*** 42094,42100 ****
       initializer--starting counting at zero--determines the integer that
       is used to refer to the mode-switched entity in question.  In
       macros that take mode arguments / yield a mode result, modes are
!      represented as numbers 0 ... N - 1.  N is used to specify that no
       mode switch is needed / supplied.
  
   -- Target Hook: void TARGET_MODE_EMIT (int ENTITY, int MODE, int
--- 42093,42099 ----
       initializer--starting counting at zero--determines the integer that
       is used to refer to the mode-switched entity in question.  In
       macros that take mode arguments / yield a mode result, modes are
!      represented as numbers 0 ... N − 1.  N is used to specify that no
       mode switch is needed / supplied.
  
   -- Target Hook: void TARGET_MODE_EMIT (int ENTITY, int MODE, int
*************** The following macros control mode switch
*** 42107,42115 ****
  
   -- Target Hook: int TARGET_MODE_NEEDED (int ENTITY, rtx_insn *INSN)
       ENTITY is an integer specifying a mode-switched entity.  If
!      'OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to
       return an integer value not larger than the corresponding element
!      in 'NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY
       must be switched into prior to the execution of INSN.
  
   -- Target Hook: int TARGET_MODE_AFTER (int ENTITY, int MODE, rtx_insn
--- 42106,42114 ----
  
   -- Target Hook: int TARGET_MODE_NEEDED (int ENTITY, rtx_insn *INSN)
       ENTITY is an integer specifying a mode-switched entity.  If
!      ‘OPTIMIZE_MODE_SWITCHING’ is defined, you must define this macro to
       return an integer value not larger than the corresponding element
!      in ‘NUM_MODES_FOR_MODE_SWITCHING’, to denote the mode that ENTITY
       must be switched into prior to the execution of INSN.
  
   -- Target Hook: int TARGET_MODE_AFTER (int ENTITY, int MODE, rtx_insn
*************** The following macros control mode switch
*** 42123,42159 ****
       If this macro is defined, it is evaluated for every ENTITY that
       needs mode switching.  It should evaluate to an integer, which is a
       mode that ENTITY is assumed to be switched to at function entry.
!      If 'TARGET_MODE_ENTRY' is defined then 'TARGET_MODE_EXIT' must be
       defined.
  
   -- Target Hook: int TARGET_MODE_EXIT (int ENTITY)
       If this macro is defined, it is evaluated for every ENTITY that
       needs mode switching.  It should evaluate to an integer, which is a
       mode that ENTITY is assumed to be switched to at function exit.  If
!      'TARGET_MODE_EXIT' is defined then 'TARGET_MODE_ENTRY' must be
       defined.
  
   -- Target Hook: int TARGET_MODE_PRIORITY (int ENTITY, int N)
       This macro specifies the order in which modes for ENTITY are
       processed.  0 is the highest priority,
!      'NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest.  The value
       of the macro should be an integer designating a mode for ENTITY.
!      For any fixed ENTITY, 'mode_priority' (ENTITY, N) shall be a
!      bijection in 0 ... 'num_modes_for_mode_switching[ENTITY] - 1'.
  
  
  File: gccint.info,  Node: Target Attributes,  Next: Emulated TLS,  Prev: Mode Switching,  Up: Target Macros
  
! 18.24 Defining target-specific uses of '__attribute__'
  ======================================================
  
  Target-specific attributes may be defined for functions, data and types.
  These are described using the following target hooks; they also need to
! be documented in 'extend.texi'.
  
   -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE
!      If defined, this target hook points to an array of 'struct
!      attribute_spec' (defined in 'tree-core.h') specifying the machine
       specific attributes for this target and some of the restrictions on
       the entities to which these attributes are applied and the
       arguments they take.
--- 42122,42158 ----
       If this macro is defined, it is evaluated for every ENTITY that
       needs mode switching.  It should evaluate to an integer, which is a
       mode that ENTITY is assumed to be switched to at function entry.
!      If ‘TARGET_MODE_ENTRY’ is defined then ‘TARGET_MODE_EXIT’ must be
       defined.
  
   -- Target Hook: int TARGET_MODE_EXIT (int ENTITY)
       If this macro is defined, it is evaluated for every ENTITY that
       needs mode switching.  It should evaluate to an integer, which is a
       mode that ENTITY is assumed to be switched to at function exit.  If
!      ‘TARGET_MODE_EXIT’ is defined then ‘TARGET_MODE_ENTRY’ must be
       defined.
  
   -- Target Hook: int TARGET_MODE_PRIORITY (int ENTITY, int N)
       This macro specifies the order in which modes for ENTITY are
       processed.  0 is the highest priority,
!      ‘NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1’ the lowest.  The value
       of the macro should be an integer designating a mode for ENTITY.
!      For any fixed ENTITY, ‘mode_priority’ (ENTITY, N) shall be a
!      bijection in 0 ... ‘num_modes_for_mode_switching[ENTITY] - 1’.
  
  
  File: gccint.info,  Node: Target Attributes,  Next: Emulated TLS,  Prev: Mode Switching,  Up: Target Macros
  
! 18.24 Defining target-specific uses of ‘__attribute__’
  ======================================================
  
  Target-specific attributes may be defined for functions, data and types.
  These are described using the following target hooks; they also need to
! be documented in ‘extend.texi’.
  
   -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE
!      If defined, this target hook points to an array of ‘struct
!      attribute_spec’ (defined in ‘tree-core.h’) specifying the machine
       specific attributes for this target and some of the restrictions on
       the entities to which these attributes are applied and the
       arguments they take.
*************** be documented in 'extend.texi'.
*** 42182,42224 ****
            TYPE2)
       Define this target hook if the merging of type attributes needs
       special handling.  If defined, the result is a list of the combined
!      'TYPE_ATTRIBUTES' of TYPE1 and TYPE2.  It is assumed that
!      'comptypes' has already been called and returned 1.  This function
!      may call 'merge_attributes' to handle machine-independent merging.
  
   -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree
            NEWDECL)
       Define this target hook if the merging of decl attributes needs
       special handling.  If defined, the result is a list of the combined
!      'DECL_ATTRIBUTES' of OLDDECL and NEWDECL.  NEWDECL is a duplicate
       declaration of OLDDECL.  Examples of when this is needed are when
       one attribute overrides another, or when an attribute is nullified
       by a subsequent definition.  This function may call
!      'merge_attributes' to handle machine-independent merging.
  
!      If the only target-specific handling you require is 'dllimport' for
       Microsoft Windows targets, you should define the macro
!      'TARGET_DLLIMPORT_DECL_ATTRIBUTES' to '1'.  The compiler will then
!      define a function called 'merge_dllimport_decl_attributes' which
       can then be defined as the expansion of
!      'TARGET_MERGE_DECL_ATTRIBUTES'.  You can also add
!      'handle_dll_attribute' in the attribute table for your port to
!      perform initial processing of the 'dllimport' and 'dllexport'
!      attributes.  This is done in 'i386/cygwin.h' and 'i386/i386.cc',
       for example.
  
   -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree
            DECL)
!      DECL is a variable or function with '__attribute__((dllimport))'
       specified.  Use this hook if the target needs to add extra
!      validation checks to 'handle_dll_attribute'.
  
   -- Macro: TARGET_DECLSPEC
       Define this macro to a nonzero value if you want to treat
!      '__declspec(X)' as equivalent to '__attribute((X))'.  By default,
       this behavior is enabled only for targets that define
!      'TARGET_DLLIMPORT_DECL_ATTRIBUTES'.  The current implementation of
!      '__declspec' is via a built-in macro, but you should not rely on
       this implementation detail.
  
   -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree
--- 42181,42223 ----
            TYPE2)
       Define this target hook if the merging of type attributes needs
       special handling.  If defined, the result is a list of the combined
!      ‘TYPE_ATTRIBUTES’ of TYPE1 and TYPE2.  It is assumed that
!      ‘comptypes’ has already been called and returned 1.  This function
!      may call ‘merge_attributes’ to handle machine-independent merging.
  
   -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree
            NEWDECL)
       Define this target hook if the merging of decl attributes needs
       special handling.  If defined, the result is a list of the combined
!      ‘DECL_ATTRIBUTES’ of OLDDECL and NEWDECL.  NEWDECL is a duplicate
       declaration of OLDDECL.  Examples of when this is needed are when
       one attribute overrides another, or when an attribute is nullified
       by a subsequent definition.  This function may call
!      ‘merge_attributes’ to handle machine-independent merging.
  
!      If the only target-specific handling you require is ‘dllimport’ for
       Microsoft Windows targets, you should define the macro
!      ‘TARGET_DLLIMPORT_DECL_ATTRIBUTES’ to ‘1’.  The compiler will then
!      define a function called ‘merge_dllimport_decl_attributes’ which
       can then be defined as the expansion of
!      ‘TARGET_MERGE_DECL_ATTRIBUTES’.  You can also add
!      ‘handle_dll_attribute’ in the attribute table for your port to
!      perform initial processing of the ‘dllimport’ and ‘dllexport’
!      attributes.  This is done in ‘i386/cygwin.h’ and ‘i386/i386.cc’,
       for example.
  
   -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree
            DECL)
!      DECL is a variable or function with ‘__attribute__((dllimport))’
       specified.  Use this hook if the target needs to add extra
!      validation checks to ‘handle_dll_attribute’.
  
   -- Macro: TARGET_DECLSPEC
       Define this macro to a nonzero value if you want to treat
!      ‘__declspec(X)’ as equivalent to ‘__attribute((X))’.  By default,
       this behavior is enabled only for targets that define
!      ‘TARGET_DLLIMPORT_DECL_ATTRIBUTES’.  The current implementation of
!      ‘__declspec’ is via a built-in macro, but you should not rely on
       this implementation detail.
  
   -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree
*************** be documented in 'extend.texi'.
*** 42230,42236 ****
       which is being created.  The ATTR_PTR argument is a pointer to the
       attribute list for this decl.  The list itself should not be
       modified, since it may be shared with other decls, but attributes
!      may be chained on the head of the list and '*ATTR_PTR' modified to
       point to the new attributes, or a copy of the list may be made if
       further changes are needed.
  
--- 42229,42235 ----
       which is being created.  The ATTR_PTR argument is a pointer to the
       attribute list for this decl.  The list itself should not be
       modified, since it may be shared with other decls, but attributes
!      may be chained on the head of the list and ‘*ATTR_PTR’ modified to
       point to the new attributes, or a copy of the list may be made if
       further changes are needed.
  
*************** be documented in 'extend.texi'.
*** 42244,42321 ****
  
   -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree
            FNDECL)
!      This target hook returns 'true' if it is OK to inline FNDECL into
       the current function, despite its having target-specific
!      attributes, 'false' otherwise.  By default, if a function has a
       target specific attribute attached to it, it will not be inlined.
  
   -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, tree
            NAME, tree ARGS, int FLAGS)
!      This hook is called to parse 'attribute(target("..."))', which
       allows setting target-specific options on individual functions.
       These function-specific options may differ from the options
!      specified on the command line.  The hook should return 'true' if
       the options are valid.
  
!      The hook should set the 'DECL_FUNCTION_SPECIFIC_TARGET' field in
       the function declaration to hold a pointer to a target-specific
!      'struct cl_target_option' structure.
  
   -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR,
            struct gcc_options *OPTS, struct gcc_options *OPTS_SET)
       This hook is called to save any additional target-specific
!      information in the 'struct cl_target_option' structure for
!      function-specific options from the 'struct gcc_options' structure.
       *Note Option file format::.
  
   -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS,
            struct gcc_options *OPTS_SET, struct cl_target_option *PTR)
       This hook is called to restore any additional target-specific
!      information in the 'struct cl_target_option' structure for
!      function-specific options to the 'struct gcc_options' structure.
  
   -- Target Hook: void TARGET_OPTION_POST_STREAM_IN (struct
            cl_target_option *PTR)
       This hook is called to update target-specific information in the
!      'struct cl_target_option' structure after it is streamed in from
       LTO bytecode.
  
   -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT,
            struct cl_target_option *PTR)
       This hook is called to print any additional target-specific
!      information in the 'struct cl_target_option' structure for
       function-specific options.
  
   -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree
            POP_TARGET)
!      This target hook parses the options for '#pragma GCC target', which
       sets the target-specific options for functions that occur later in
       the input stream.  The options accepted should be the same as those
!      handled by the 'TARGET_OPTION_VALID_ATTRIBUTE_P' hook.
  
   -- Target Hook: void TARGET_OPTION_OVERRIDE (void)
       Sometimes certain combinations of command options do not make sense
       on a particular target machine.  You can override the hook
!      'TARGET_OPTION_OVERRIDE' to take account of this.  This hooks is
       called once just after all the command options have been parsed.
  
       Don't use this hook to turn on various extra optimizations for
!      '-O'.  That is what 'TARGET_OPTION_OPTIMIZATION' is for.
  
       If you need to do something whenever the optimization level is
       changed via the optimize attribute or pragma, see
!      'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'
  
   -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree
            DECL2)
!      This target hook returns 'true' if DECL1 and DECL2 are versions of
       the same function.  DECL1 and DECL2 are function versions if and
       only if they have the same function signature and different target
       specific attributes, that is, they are compiled for different
       target machines.
  
   -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE)
!      This target hook returns 'false' if the CALLER function cannot
       inline CALLEE, based on target specific information.  By default,
       inlining is not allowed if the callee function has function
       specific target options and the caller does not use the same
--- 42243,42320 ----
  
   -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree
            FNDECL)
!      This target hook returns ‘true’ if it is OK to inline FNDECL into
       the current function, despite its having target-specific
!      attributes, ‘false’ otherwise.  By default, if a function has a
       target specific attribute attached to it, it will not be inlined.
  
   -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, tree
            NAME, tree ARGS, int FLAGS)
!      This hook is called to parse ‘attribute(target("..."))’, which
       allows setting target-specific options on individual functions.
       These function-specific options may differ from the options
!      specified on the command line.  The hook should return ‘true’ if
       the options are valid.
  
!      The hook should set the ‘DECL_FUNCTION_SPECIFIC_TARGET’ field in
       the function declaration to hold a pointer to a target-specific
!      ‘struct cl_target_option’ structure.
  
   -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR,
            struct gcc_options *OPTS, struct gcc_options *OPTS_SET)
       This hook is called to save any additional target-specific
!      information in the ‘struct cl_target_option’ structure for
!      function-specific options from the ‘struct gcc_options’ structure.
       *Note Option file format::.
  
   -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS,
            struct gcc_options *OPTS_SET, struct cl_target_option *PTR)
       This hook is called to restore any additional target-specific
!      information in the ‘struct cl_target_option’ structure for
!      function-specific options to the ‘struct gcc_options’ structure.
  
   -- Target Hook: void TARGET_OPTION_POST_STREAM_IN (struct
            cl_target_option *PTR)
       This hook is called to update target-specific information in the
!      ‘struct cl_target_option’ structure after it is streamed in from
       LTO bytecode.
  
   -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT,
            struct cl_target_option *PTR)
       This hook is called to print any additional target-specific
!      information in the ‘struct cl_target_option’ structure for
       function-specific options.
  
   -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree
            POP_TARGET)
!      This target hook parses the options for ‘#pragma GCC target’, which
       sets the target-specific options for functions that occur later in
       the input stream.  The options accepted should be the same as those
!      handled by the ‘TARGET_OPTION_VALID_ATTRIBUTE_P’ hook.
  
   -- Target Hook: void TARGET_OPTION_OVERRIDE (void)
       Sometimes certain combinations of command options do not make sense
       on a particular target machine.  You can override the hook
!      ‘TARGET_OPTION_OVERRIDE’ to take account of this.  This hooks is
       called once just after all the command options have been parsed.
  
       Don't use this hook to turn on various extra optimizations for
!      ‘-O’.  That is what ‘TARGET_OPTION_OPTIMIZATION’ is for.
  
       If you need to do something whenever the optimization level is
       changed via the optimize attribute or pragma, see
!      ‘TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE’
  
   -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree
            DECL2)
!      This target hook returns ‘true’ if DECL1 and DECL2 are versions of
       the same function.  DECL1 and DECL2 are function versions if and
       only if they have the same function signature and different target
       specific attributes, that is, they are compiled for different
       target machines.
  
   -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE)
!      This target hook returns ‘false’ if the CALLER function cannot
       inline CALLEE, based on target specific information.  By default,
       inlining is not allowed if the callee function has function
       specific target options and the caller does not use the same
*************** be documented in 'extend.texi'.
*** 42331,42337 ****
       with the conservative analysis on all statements of the callee if
       we are able to guarantee the callee does not exploit any
       instructions from the mismatch isa feature, it would be safe to
!      allow the caller to inline the callee.  INFO is one 'unsigned int'
       value to record information in which one set bit indicates one
       corresponding feature is detected in the analysis, STMT is the
       statement being analyzed.  Return true if target still need to
--- 42330,42336 ----
       with the conservative analysis on all statements of the callee if
       we are able to guarantee the callee does not exploit any
       instructions from the mismatch isa feature, it would be safe to
!      allow the caller to inline the callee.  INFO is one ‘unsigned int’
       value to record information in which one set bit indicates one
       corresponding feature is detected in the analysis, STMT is the
       statement being analyzed.  Return true if target still need to
*************** be documented in 'extend.texi'.
*** 42343,42353 ****
            unsigned int& INFO)
       Allow target to check early whether it is necessary to analyze all
       gimple statements in the given function to update target specific
!      information for inlining.  See hook 'update_ipa_fn_target_info' for
       usage example of target specific information.  This hook is
       expected to be invoked ahead of the iterating with hook
!      'update_ipa_fn_target_info'.  DECL is the function being analyzed,
!      INFO is the same as what in hook 'update_ipa_fn_target_info',
       target can do one time update into INFO without iterating for some
       case.  Return true if target decides to analyze all gimple
       statements to collect information, otherwise return false.  The
--- 42342,42352 ----
            unsigned int& INFO)
       Allow target to check early whether it is necessary to analyze all
       gimple statements in the given function to update target specific
!      information for inlining.  See hook ‘update_ipa_fn_target_info’ for
       usage example of target specific information.  This hook is
       expected to be invoked ahead of the iterating with hook
!      ‘update_ipa_fn_target_info’.  DECL is the function being analyzed,
!      INFO is the same as what in hook ‘update_ipa_fn_target_info’,
       target can do one time update into INFO without iterating for some
       case.  Return true if target decides to analyze all gimple
       statements to collect information, otherwise return false.  The
*************** the current thread's instance of the TLS
*** 42384,42416 ****
   -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON
       Contains the name of the helper function that should be used at
       program startup to register TLS objects that are implicitly
!      initialized to zero.  If this is 'NULL', all TLS objects will have
       explicit initializers.  The default causes libgcc's emulated TLS
       registration function to be used.
  
   -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION
       Contains the name of the section in which TLS control variables
!      should be placed.  The default of 'NULL' allows these to be placed
       in any section.
  
   -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION
       Contains the name of the section in which TLS initializers should
!      be placed.  The default of 'NULL' allows these to be placed in any
       section.
  
   -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX
       Contains the prefix to be prepended to TLS control variable names.
!      The default of 'NULL' uses a target-specific prefix.
  
   -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX
       Contains the prefix to be prepended to TLS initializer objects.
!      The default of 'NULL' uses a target-specific prefix.
  
   -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME)
       Specifies a function that generates the FIELD_DECLs for a TLS
       control object type.  TYPE is the RECORD_TYPE the fields are for
       and NAME should be filled with the structure tag, if the default of
!      '__emutls_object' is unsuitable.  The default creates a type
       suitable for libgcc's emulated TLS function.
  
   -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree
--- 42383,42415 ----
   -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON
       Contains the name of the helper function that should be used at
       program startup to register TLS objects that are implicitly
!      initialized to zero.  If this is ‘NULL’, all TLS objects will have
       explicit initializers.  The default causes libgcc's emulated TLS
       registration function to be used.
  
   -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION
       Contains the name of the section in which TLS control variables
!      should be placed.  The default of ‘NULL’ allows these to be placed
       in any section.
  
   -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION
       Contains the name of the section in which TLS initializers should
!      be placed.  The default of ‘NULL’ allows these to be placed in any
       section.
  
   -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX
       Contains the prefix to be prepended to TLS control variable names.
!      The default of ‘NULL’ uses a target-specific prefix.
  
   -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX
       Contains the prefix to be prepended to TLS initializer objects.
!      The default of ‘NULL’ uses a target-specific prefix.
  
   -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME)
       Specifies a function that generates the FIELD_DECLs for a TLS
       control object type.  TYPE is the RECORD_TYPE the fields are for
       and NAME should be filled with the structure tag, if the default of
!      ‘__emutls_object’ is unsuitable.  The default creates a type
       suitable for libgcc's emulated TLS function.
  
   -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree
*************** the current thread's instance of the TLS
*** 42426,42432 ****
       optimize single objects.  The default is false.
  
   -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS
!      Specifies whether a DWARF 'DW_OP_form_tls_address' location
       descriptor may be used to describe emulated TLS control objects.
  
  
--- 42425,42431 ----
       optimize single objects.  The default is false.
  
   -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS
!      Specifies whether a DWARF ‘DW_OP_form_tls_address’ location
       descriptor may be used to describe emulated TLS control objects.
  
  
*************** and memory using asm-ized variables.  Fo
*** 42447,42453 ****
  
   ("c0r1" is the default name of register 1 in coprocessor 0; alternate
  names may be added as described below, or the default names may be
! overridden entirely in 'SUBTARGET_CONDITIONAL_REGISTER_USAGE'.)
  
   Coprocessor registers are assumed to be epilogue-used; sets to them
  will be preserved even if it does not appear that the register is used
--- 42446,42452 ----
  
   ("c0r1" is the default name of register 1 in coprocessor 0; alternate
  names may be added as described below, or the default names may be
! overridden entirely in ‘SUBTARGET_CONDITIONAL_REGISTER_USAGE’.)
  
   Coprocessor registers are assumed to be epilogue-used; sets to them
  will be preserved even if it does not appear that the register is used
*************** File: gccint.info,  Node: PCH Target,  N
*** 42465,42495 ****
  
   -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ)
       This hook returns a pointer to the data needed by
!      'TARGET_PCH_VALID_P' and sets '*SZ' to the size of the data in
       bytes.
  
   -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA,
            size_t SZ)
       This hook checks whether the options used to create a PCH file are
!      compatible with the current settings.  It returns 'NULL' if so and
       a suitable error message if not.  Error messages will be presented
!      to the user and must be localized using '_(MSG)'.
  
!      DATA is the data that was returned by 'TARGET_GET_PCH_VALIDITY'
       when the PCH file was created and SZ is the size of that data in
       bytes.  It's safe to assume that the data was created by the same
       version of the compiler, so no format checking is needed.
  
!      The default definition of 'default_pch_valid_p' should be suitable
       for most targets.
  
   -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int
            PCH_FLAGS)
       If this hook is nonnull, the default implementation of
!      'TARGET_PCH_VALID_P' will use it to check for compatible values of
!      'target_flags'.  PCH_FLAGS specifies the value that 'target_flags'
       had when the PCH file was created.  The return value is the same as
!      for 'TARGET_PCH_VALID_P'.
  
   -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void)
       Called before writing out a PCH file.  If the target has some
--- 42464,42494 ----
  
   -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ)
       This hook returns a pointer to the data needed by
!      ‘TARGET_PCH_VALID_P’ and sets ‘*SZ’ to the size of the data in
       bytes.
  
   -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA,
            size_t SZ)
       This hook checks whether the options used to create a PCH file are
!      compatible with the current settings.  It returns ‘NULL’ if so and
       a suitable error message if not.  Error messages will be presented
!      to the user and must be localized using ‘_(MSG)’.
  
!      DATA is the data that was returned by ‘TARGET_GET_PCH_VALIDITY’
       when the PCH file was created and SZ is the size of that data in
       bytes.  It's safe to assume that the data was created by the same
       version of the compiler, so no format checking is needed.
  
!      The default definition of ‘default_pch_valid_p’ should be suitable
       for most targets.
  
   -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int
            PCH_FLAGS)
       If this hook is nonnull, the default implementation of
!      ‘TARGET_PCH_VALID_P’ will use it to check for compatible values of
!      ‘target_flags’.  PCH_FLAGS specifies the value that ‘target_flags’
       had when the PCH file was created.  The return value is the same as
!      for ‘TARGET_PCH_VALID_P’.
  
   -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void)
       Called before writing out a PCH file.  If the target has some
*************** File: gccint.info,  Node: C++ ABI,  Next
*** 42510,42543 ****
  
   -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void)
       This hook determines how guard variables are used.  It should
!      return 'false' (the default) if the first byte should be used.  A
!      return value of 'true' indicates that only the least significant
       bit should be used.
  
   -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE)
       This hook returns the size of the cookie to use when allocating an
       array whose elements have the indicated TYPE.  Assumes that it is
!      already known that a cookie is needed.  The default is 'max(sizeof
!      (size_t), alignof(type))', as defined in section 2.7 of the
       IA64/Generic C++ ABI.
  
   -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void)
!      This hook should return 'true' if the element size should be stored
!      in array cookies.  The default is to return 'false'.
  
   -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int
            IMPORT_EXPORT)
       If defined by a backend this hook allows the decision made to
       export class TYPE to be overruled.  Upon entry IMPORT_EXPORT will
!      contain 1 if the class is going to be exported, -1 if it is going
       to be imported and 0 otherwise.  This function should return the
       modified value and perform any other actions necessary to support
       the backend's targeted operating system.
  
   -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void)
!      This hook should return 'true' if constructors and destructors
       return the address of the object created/destroyed.  The default is
!      to return 'false'.
  
   -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void)
       This hook returns true if the key method for a class (i.e., the
--- 42509,42542 ----
  
   -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void)
       This hook determines how guard variables are used.  It should
!      return ‘false’ (the default) if the first byte should be used.  A
!      return value of ‘true’ indicates that only the least significant
       bit should be used.
  
   -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE)
       This hook returns the size of the cookie to use when allocating an
       array whose elements have the indicated TYPE.  Assumes that it is
!      already known that a cookie is needed.  The default is ‘max(sizeof
!      (size_t), alignof(type))’, as defined in section 2.7 of the
       IA64/Generic C++ ABI.
  
   -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void)
!      This hook should return ‘true’ if the element size should be stored
!      in array cookies.  The default is to return ‘false’.
  
   -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int
            IMPORT_EXPORT)
       If defined by a backend this hook allows the decision made to
       export class TYPE to be overruled.  Upon entry IMPORT_EXPORT will
!      contain 1 if the class is going to be exported, −1 if it is going
       to be imported and 0 otherwise.  This function should return the
       modified value and perform any other actions necessary to support
       the backend's targeted operating system.
  
   -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void)
!      This hook should return ‘true’ if constructors and destructors
       return the address of the object created/destroyed.  The default is
!      to return ‘false’.
  
   -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void)
       This hook returns true if the key method for a class (i.e., the
*************** File: gccint.info,  Node: C++ ABI,  Next
*** 42547,42553 ****
       function so long as the function is not declared inline in the
       class definition.  Under some variants of the ABI, an inline
       function can never be the key method.  The default is to return
!      'true'.
  
   -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree
            DECL)
--- 42546,42552 ----
       function so long as the function is not declared inline in the
       class definition.  Under some variants of the ABI, an inline
       function can never be the key method.  The default is to return
!      ‘true’.
  
   -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree
            DECL)
*************** File: gccint.info,  Node: C++ ABI,  Next
*** 42556,42562 ****
       external linkage in this translation unit.  No ELF visibility has
       been explicitly specified.  If the target needs to specify a
       visibility other than that of the containing class, use this hook
!      to set 'DECL_VISIBILITY' and 'DECL_VISIBILITY_SPECIFIED'.
  
   -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void)
       This hook returns true (the default) if virtual tables and other
--- 42555,42561 ----
       external linkage in this translation unit.  No ELF visibility has
       been explicitly specified.  If the target needs to specify a
       visibility other than that of the containing class, use this hook
!      to set ‘DECL_VISIBILITY’ and ‘DECL_VISIBILITY_SPECIFIED’.
  
   -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void)
       This hook returns true (the default) if virtual tables and other
*************** File: gccint.info,  Node: C++ ABI,  Next
*** 42571,42585 ****
       be COMDAT, false if it should not be COMDAT.
  
   -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void)
!      This hook returns true if '__aeabi_atexit' (as defined by the ARM
       EABI) should be used to register static destructors when
!      '-fuse-cxa-atexit' is in effect.  The default is to return false to
!      use '__cxa_atexit'.
  
   -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void)
!      This hook returns true if the target 'atexit' function can be used
!      in the same manner as '__cxa_atexit' to register C++ static
!      destructors.  This requires that 'atexit'-registered functions in
       shared libraries are run in the correct order when the libraries
       are unloaded.  The default is to return false.
  
--- 42570,42584 ----
       be COMDAT, false if it should not be COMDAT.
  
   -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void)
!      This hook returns true if ‘__aeabi_atexit’ (as defined by the ARM
       EABI) should be used to register static destructors when
!      ‘-fuse-cxa-atexit’ is in effect.  The default is to return false to
!      use ‘__cxa_atexit’.
  
   -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void)
!      This hook returns true if the target ‘atexit’ function can be used
!      in the same manner as ‘__cxa_atexit’ to register C++ static
!      destructors.  This requires that ‘atexit’-registered functions in
       shared libraries are run in the correct order when the libraries
       are unloaded.  The default is to return false.
  
*************** File: gccint.info,  Node: C++ ABI,  Next
*** 42590,42596 ****
       modifications).
  
   -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL)
!      Return target-specific mangling context of DECL or 'NULL_TREE'.
  
  
  File: gccint.info,  Node: D Language and ABI,  Next: Named Address Spaces,  Prev: C++ ABI,  Up: Target Macros
--- 42589,42595 ----
       modifications).
  
   -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL)
!      Return target-specific mangling context of DECL or ‘NULL_TREE’.
  
  
  File: gccint.info,  Node: D Language and ABI,  Next: Named Address Spaces,  Prev: C++ ABI,  Up: Target Macros
*************** File: gccint.info,  Node: D Language and
*** 42600,42661 ****
  
   -- D Target Hook: void TARGET_D_CPU_VERSIONS (void)
       Declare all environmental version identifiers relating to the
!      target CPU using the function 'builtin_version', which takes a
       string representing the name of the version.  Version identifiers
       predefined by this hook apply to all modules that are being
       compiled and imported.
  
   -- D Target Hook: void TARGET_D_OS_VERSIONS (void)
!      Similarly to 'TARGET_D_CPU_VERSIONS', but is used for versions
       relating to the target operating system.
  
   -- D Target Hook: void TARGET_D_REGISTER_CPU_TARGET_INFO (void)
       Register all target information keys relating to the target CPU
!      using the function 'd_add_target_info_handlers', which takes a
!      'struct d_target_info_spec' (defined in 'd/d-target.h').  The keys
       added by this hook are made available at compile time by the
!      '__traits(getTargetInfo)' extension, the result is an expression
       describing the requested target information.
  
   -- D Target Hook: void TARGET_D_REGISTER_OS_TARGET_INFO (void)
!      Same as 'TARGET_D_CPU_TARGET_INFO', but is used for keys relating
       to the target operating system.
  
   -- D Target Hook: const char * TARGET_D_MINFO_SECTION
       Contains the name of the section in which module info references
       should be placed.  By default, the compiler puts all module info
!      symbols in the '"minfo"' section.  Define this macro to override
       the string if a different section name should be used.  This
       section is expected to be bracketed by two symbols
!      'TARGET_D_MINFO_SECTION_START' and 'TARGET_D_MINFO_SECTION_END' to
       indicate the start and end address of the section, so that the
       runtime library can collect all modules for each loaded shared
!      library and executable.  Setting the value to 'NULL' disables the
       use of sections for storing module info altogether.
  
   -- D Target Hook: const char * TARGET_D_MINFO_SECTION_START
!      If 'TARGET_D_MINFO_SECTION' is defined, then this must also be
       defined as the name of the symbol indicating the start address of
       the module info section
  
   -- D Target Hook: const char * TARGET_D_MINFO_SECTION_END
!      If 'TARGET_D_MINFO_SECTION' is defined, then this must also be
       defined as the name of the symbol indicating the end address of the
       module info section
  
   -- D Target Hook: bool TARGET_D_HAS_STDCALL_CONVENTION (unsigned int
            *LINK_SYSTEM, unsigned int *LINK_WINDOWS)
!      Returns 'true' if the target supports the stdcall calling
!      convention.  The hook should also set LINK_SYSTEM to '1' if the
!      'stdcall' attribute should be applied to functions with
!      'extern(System)' linkage, and LINK_WINDOWS to '1' to apply
!      'stdcall' to functions with 'extern(Windows)' linkage.
  
   -- D Target Hook: bool TARGET_D_TEMPLATES_ALWAYS_COMDAT
       This flag is true if instantiated functions and variables are
       always COMDAT if they have external linkage.  If this flag is
       false, then instantiated decls will be emitted as weak symbols.
!      The default is 'false'.
  
  
  File: gccint.info,  Node: Named Address Spaces,  Next: Misc,  Prev: D Language and ABI,  Up: Target Macros
--- 42599,42660 ----
  
   -- D Target Hook: void TARGET_D_CPU_VERSIONS (void)
       Declare all environmental version identifiers relating to the
!      target CPU using the function ‘builtin_version’, which takes a
       string representing the name of the version.  Version identifiers
       predefined by this hook apply to all modules that are being
       compiled and imported.
  
   -- D Target Hook: void TARGET_D_OS_VERSIONS (void)
!      Similarly to ‘TARGET_D_CPU_VERSIONS’, but is used for versions
       relating to the target operating system.
  
   -- D Target Hook: void TARGET_D_REGISTER_CPU_TARGET_INFO (void)
       Register all target information keys relating to the target CPU
!      using the function ‘d_add_target_info_handlers’, which takes a
!      ‘struct d_target_info_spec’ (defined in ‘d/d-target.h’).  The keys
       added by this hook are made available at compile time by the
!      ‘__traits(getTargetInfo)’ extension, the result is an expression
       describing the requested target information.
  
   -- D Target Hook: void TARGET_D_REGISTER_OS_TARGET_INFO (void)
!      Same as ‘TARGET_D_CPU_TARGET_INFO’, but is used for keys relating
       to the target operating system.
  
   -- D Target Hook: const char * TARGET_D_MINFO_SECTION
       Contains the name of the section in which module info references
       should be placed.  By default, the compiler puts all module info
!      symbols in the ‘"minfo"’ section.  Define this macro to override
       the string if a different section name should be used.  This
       section is expected to be bracketed by two symbols
!      ‘TARGET_D_MINFO_SECTION_START’ and ‘TARGET_D_MINFO_SECTION_END’ to
       indicate the start and end address of the section, so that the
       runtime library can collect all modules for each loaded shared
!      library and executable.  Setting the value to ‘NULL’ disables the
       use of sections for storing module info altogether.
  
   -- D Target Hook: const char * TARGET_D_MINFO_SECTION_START
!      If ‘TARGET_D_MINFO_SECTION’ is defined, then this must also be
       defined as the name of the symbol indicating the start address of
       the module info section
  
   -- D Target Hook: const char * TARGET_D_MINFO_SECTION_END
!      If ‘TARGET_D_MINFO_SECTION’ is defined, then this must also be
       defined as the name of the symbol indicating the end address of the
       module info section
  
   -- D Target Hook: bool TARGET_D_HAS_STDCALL_CONVENTION (unsigned int
            *LINK_SYSTEM, unsigned int *LINK_WINDOWS)
!      Returns ‘true’ if the target supports the stdcall calling
!      convention.  The hook should also set LINK_SYSTEM to ‘1’ if the
!      ‘stdcall’ attribute should be applied to functions with
!      ‘extern(System)’ linkage, and LINK_WINDOWS to ‘1’ to apply
!      ‘stdcall’ to functions with ‘extern(Windows)’ linkage.
  
   -- D Target Hook: bool TARGET_D_TEMPLATES_ALWAYS_COMDAT
       This flag is true if instantiated functions and variables are
       always COMDAT if they have external linkage.  If this flag is
       false, then instantiated decls will be emitted as weak symbols.
!      The default is ‘false’.
  
  
  File: gccint.info,  Node: Named Address Spaces,  Next: Misc,  Prev: D Language and ABI,  Up: Target Macros
*************** File: gccint.info,  Node: Named Address
*** 42664,42685 ****
  =============================================
  
  The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards
! committee, 'Programming Languages - C - Extensions to support embedded
! processors', specifies a syntax for embedded processors to specify
  alternate address spaces.  You can configure a GCC port to support
  section 5.1 of the draft report to add support for address spaces other
  than the default address space.  These address spaces are new keywords
! that are similar to the 'volatile' and 'const' type attributes.
  
   Pointers to named address spaces can have a different size than
  pointers to the generic address space.
  
!  For example, the SPU port uses the '__ea' address space to refer to
  memory in the host processor, rather than memory local to the SPU
! processor.  Access to memory in the '__ea' address space involves
  issuing DMA operations to move data between the host processor and the
! local processor memory address space.  Pointers in the '__ea' address
! space are either 32 bits or 64 bits based on the '-mea32' or '-mea64'
  switches (native SPU pointers are always 32 bits).
  
   Internally, address spaces are represented as a small integer in the
--- 42663,42684 ----
  =============================================
  
  The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards
! committee, ‘Programming Languages - C - Extensions to support embedded
! processors’, specifies a syntax for embedded processors to specify
  alternate address spaces.  You can configure a GCC port to support
  section 5.1 of the draft report to add support for address spaces other
  than the default address space.  These address spaces are new keywords
! that are similar to the ‘volatile’ and ‘const’ type attributes.
  
   Pointers to named address spaces can have a different size than
  pointers to the generic address space.
  
!  For example, the SPU port uses the ‘__ea’ address space to refer to
  memory in the host processor, rather than memory local to the SPU
! processor.  Access to memory in the ‘__ea’ address space involves
  issuing DMA operations to move data between the host processor and the
! local processor memory address space.  Pointers in the ‘__ea’ address
! space are either 32 bits or 64 bits based on the ‘-mea32’ or ‘-mea64’
  switches (native SPU pointers are always 32 bits).
  
   Internally, address spaces are represented as a small integer in the
*************** range 0 to 15 with address space 0 being
*** 42687,42694 ****
  address space.
  
   To register a named address space qualifier keyword with the C front
! end, the target may call the 'c_register_addr_space' routine.  For
! example, the SPU port uses the following to declare '__ea' as the
  keyword for named address space #1:
       #define ADDR_SPACE_EA 1
       c_register_addr_space ("__ea", ADDR_SPACE_EA);
--- 42686,42693 ----
  address space.
  
   To register a named address space qualifier keyword with the C front
! end, the target may call the ‘c_register_addr_space’ routine.  For
! example, the SPU port uses the following to declare ‘__ea’ as the
  keyword for named address space #1:
       #define ADDR_SPACE_EA 1
       c_register_addr_space ("__ea", ADDR_SPACE_EA);
*************** keyword for named address space #1:
*** 42697,42719 ****
            (addr_space_t ADDRESS_SPACE)
       Define this to return the machine mode to use for pointers to
       ADDRESS_SPACE if the target supports named address spaces.  The
!      default version of this hook returns 'ptr_mode'.
  
   -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_ADDRESS_MODE
            (addr_space_t ADDRESS_SPACE)
       Define this to return the machine mode to use for addresses in
       ADDRESS_SPACE if the target supports named address spaces.  The
!      default version of this hook returns 'Pmode'.
  
   -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE
            (scalar_int_mode MODE, addr_space_t AS)
       Define this to return nonzero if the port can handle pointers with
       machine mode MODE to address space AS.  This target hook is the
!      same as the 'TARGET_VALID_POINTER_MODE' target hook, except that it
       includes explicit named address space support.  The default version
       of this hook returns true for the modes returned by either the
!      'TARGET_ADDR_SPACE_POINTER_MODE' or
!      'TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given address
       space.
  
   -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
--- 42696,42718 ----
            (addr_space_t ADDRESS_SPACE)
       Define this to return the machine mode to use for pointers to
       ADDRESS_SPACE if the target supports named address spaces.  The
!      default version of this hook returns ‘ptr_mode’.
  
   -- Target Hook: scalar_int_mode TARGET_ADDR_SPACE_ADDRESS_MODE
            (addr_space_t ADDRESS_SPACE)
       Define this to return the machine mode to use for addresses in
       ADDRESS_SPACE if the target supports named address spaces.  The
!      default version of this hook returns ‘Pmode’.
  
   -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE
            (scalar_int_mode MODE, addr_space_t AS)
       Define this to return nonzero if the port can handle pointers with
       machine mode MODE to address space AS.  This target hook is the
!      same as the ‘TARGET_VALID_POINTER_MODE’ target hook, except that it
       includes explicit named address space support.  The default version
       of this hook returns true for the modes returned by either the
!      ‘TARGET_ADDR_SPACE_POINTER_MODE’ or
!      ‘TARGET_ADDR_SPACE_ADDRESS_MODE’ target hooks for the given address
       space.
  
   -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P
*************** keyword for named address space #1:
*** 42721,42734 ****
       Define this to return true if EXP is a valid address for mode MODE
       in the named address space AS.  The STRICT parameter says whether
       strict addressing is in effect after reload has finished.  This
!      target hook is the same as the 'TARGET_LEGITIMATE_ADDRESS_P' target
       hook, except that it includes explicit named address space support.
  
   -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx
            OLDX, machine_mode MODE, addr_space_t AS)
       Define this to modify an invalid address X to be a valid address
       with mode MODE in the named address space AS.  This target hook is
!      the same as the 'TARGET_LEGITIMIZE_ADDRESS' target hook, except
       that it includes explicit named address space support.
  
   -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET,
--- 42720,42733 ----
       Define this to return true if EXP is a valid address for mode MODE
       in the named address space AS.  The STRICT parameter says whether
       strict addressing is in effect after reload has finished.  This
!      target hook is the same as the ‘TARGET_LEGITIMATE_ADDRESS_P’ target
       hook, except that it includes explicit named address space support.
  
   -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx
            OLDX, machine_mode MODE, addr_space_t AS)
       Define this to modify an invalid address X to be a valid address
       with mode MODE in the named address space AS.  This target hook is
!      the same as the ‘TARGET_LEGITIMIZE_ADDRESS’ target hook, except
       that it includes explicit named address space support.
  
   -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET,
*************** keyword for named address space #1:
*** 42753,42764 ****
       a new pointer expression with type TO_TYPE that points to a
       different named address space.  When this hook it called, it is
       guaranteed that one of the two address spaces is a subset of the
!      other, as determined by the 'TARGET_ADDR_SPACE_SUBSET_P' target
       hook.
  
   -- Target Hook: int TARGET_ADDR_SPACE_DEBUG (addr_space_t AS)
       Define this to define how the address space is encoded in dwarf.
!      The result is the value to be used with 'DW_AT_address_class'.
  
   -- Target Hook: void TARGET_ADDR_SPACE_DIAGNOSE_USAGE (addr_space_t AS,
            location_t LOC)
--- 42752,42763 ----
       a new pointer expression with type TO_TYPE that points to a
       different named address space.  When this hook it called, it is
       guaranteed that one of the two address spaces is a subset of the
!      other, as determined by the ‘TARGET_ADDR_SPACE_SUBSET_P’ target
       hook.
  
   -- Target Hook: int TARGET_ADDR_SPACE_DEBUG (addr_space_t AS)
       Define this to define how the address space is encoded in dwarf.
!      The result is the value to be used with ‘DW_AT_address_class’.
  
   -- Target Hook: void TARGET_ADDR_SPACE_DIAGNOSE_USAGE (addr_space_t AS,
            location_t LOC)
*************** keyword for named address space #1:
*** 42766,42773 ****
       command line options and some diagnostics should be printed when
       the address space is used.  This hook is called during parsing and
       allows to emit a better diagnostic compared to the case where the
!      address space was not registered with 'c_register_addr_space'.  AS
!      is the address space as registered with 'c_register_addr_space'.
       LOC is the location of the address space qualifier token.  The
       default implementation does nothing.
  
--- 42765,42772 ----
       command line options and some diagnostics should be printed when
       the address space is used.  This hook is called during parsing and
       allows to emit a better diagnostic compared to the case where the
!      address space was not registered with ‘c_register_addr_space’.  AS
!      is the address space as registered with ‘c_register_addr_space’.
       LOC is the location of the address space qualifier token.  The
       default implementation does nothing.
  
*************** Here are several miscellaneous parameter
*** 42802,42812 ****
       elements of a jump-table should have.
  
   -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY)
!      Optional: return the preferred mode for an 'addr_diff_vec' when the
       minimum and maximum offset are known.  If you define this, it
       enables extra code in branch shortening to deal with
!      'addr_diff_vec'.  To make this work, you also have to define
!      'INSN_ALIGN' and make the alignment for 'addr_diff_vec' explicit.
       The BODY argument is provided so that the offset_unsigned and scale
       flags can be updated.
  
--- 42801,42811 ----
       elements of a jump-table should have.
  
   -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY)
!      Optional: return the preferred mode for an ‘addr_diff_vec’ when the
       minimum and maximum offset are known.  If you define this, it
       enables extra code in branch shortening to deal with
!      ‘addr_diff_vec’.  To make this work, you also have to define
!      ‘INSN_ALIGN’ and make the alignment for ‘addr_diff_vec’ explicit.
       The BODY argument is provided so that the offset_unsigned and scale
       flags can be updated.
  
*************** Here are several miscellaneous parameter
*** 42814,42837 ****
       Define this macro to be a C expression to indicate when jump-tables
       should contain relative addresses.  You need not define this macro
       if jump-tables never contain relative addresses, or jump-tables
!      should contain relative addresses only when '-fPIC' or '-fPIC' is
       in effect.
  
   -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void)
       This function return the smallest number of different values for
       which it is best to use a jump-table instead of a tree of
       conditional branches.  The default is four for machines with a
!      'casesi' instruction and five otherwise.  This is best for most
       machines.
  
   -- Macro: WORD_REGISTER_OPERATIONS
       Define this macro to 1 if operations between registers with
       integral mode smaller than a word are always performed on the
       entire register.  To be more explicit, if you start with a pair of
!      'word_mode' registers with known values and you do a subword, for
!      example 'QImode', addition on the low part of the registers, then
       the compiler may consider that the result has a known value in
!      'word_mode' too if the macro is defined to 1.  Most RISC machines
       have this property and most CISC machines do not.
  
   -- Target Hook: unsigned int TARGET_MIN_ARITHMETIC_PRECISION (void)
--- 42813,42836 ----
       Define this macro to be a C expression to indicate when jump-tables
       should contain relative addresses.  You need not define this macro
       if jump-tables never contain relative addresses, or jump-tables
!      should contain relative addresses only when ‘-fPIC’ or ‘-fPIC’ is
       in effect.
  
   -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void)
       This function return the smallest number of different values for
       which it is best to use a jump-table instead of a tree of
       conditional branches.  The default is four for machines with a
!      ‘casesi’ instruction and five otherwise.  This is best for most
       machines.
  
   -- Macro: WORD_REGISTER_OPERATIONS
       Define this macro to 1 if operations between registers with
       integral mode smaller than a word are always performed on the
       entire register.  To be more explicit, if you start with a pair of
!      ‘word_mode’ registers with known values and you do a subword, for
!      example ‘QImode’, addition on the low part of the registers, then
       the compiler may consider that the result has a known value in
!      ‘word_mode’ too if the macro is defined to 1.  Most RISC machines
       have this property and most CISC machines do not.
  
   -- Target Hook: unsigned int TARGET_MIN_ARITHMETIC_PRECISION (void)
*************** Here are several miscellaneous parameter
*** 42848,42883 ****
       the compiler to try using arithmetical operations setting the
       condition codes with a precision lower than the word precision.
  
!      You need not define this hook if 'WORD_REGISTER_OPERATIONS' is not
       defined to 1.
  
   -- Macro: LOAD_EXTEND_OP (MEM_MODE)
       Define this macro to be a C expression indicating when insns that
       read memory in MEM_MODE, an integral mode narrower than a word, set
       the bits outside of MEM_MODE to be either the sign-extension or the
!      zero-extension of the data read.  Return 'SIGN_EXTEND' for values
!      of MEM_MODE for which the insn sign-extends, 'ZERO_EXTEND' for
!      which it zero-extends, and 'UNKNOWN' for other modes.
  
       This macro is not called with MEM_MODE non-integral or with a width
!      greater than or equal to 'BITS_PER_WORD', so you may return any
       value in this case.  Do not define this macro if it would always
!      return 'UNKNOWN'.  On machines where this macro is defined, you
!      will normally define it as the constant 'SIGN_EXTEND' or
!      'ZERO_EXTEND'.
  
!      You may return a non-'UNKNOWN' value even if for some hard
       registers the sign extension is not performed, if for the
!      'REGNO_REG_CLASS' of these hard registers
!      'TARGET_CAN_CHANGE_MODE_CLASS' returns false when the FROM mode is
       MEM_MODE and the TO mode is any integral mode larger than this but
!      not larger than 'word_mode'.
  
!      You must return 'UNKNOWN' if for some hard registers that allow
!      this mode, 'TARGET_CAN_CHANGE_MODE_CLASS' says that they cannot
!      change to 'word_mode', but that they can change to another integral
       mode that is larger then MEM_MODE but still smaller than
!      'word_mode'.
  
   -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND
       Define this macro to 1 if loading short immediate values into
--- 42847,42882 ----
       the compiler to try using arithmetical operations setting the
       condition codes with a precision lower than the word precision.
  
!      You need not define this hook if ‘WORD_REGISTER_OPERATIONS’ is not
       defined to 1.
  
   -- Macro: LOAD_EXTEND_OP (MEM_MODE)
       Define this macro to be a C expression indicating when insns that
       read memory in MEM_MODE, an integral mode narrower than a word, set
       the bits outside of MEM_MODE to be either the sign-extension or the
!      zero-extension of the data read.  Return ‘SIGN_EXTEND’ for values
!      of MEM_MODE for which the insn sign-extends, ‘ZERO_EXTEND’ for
!      which it zero-extends, and ‘UNKNOWN’ for other modes.
  
       This macro is not called with MEM_MODE non-integral or with a width
!      greater than or equal to ‘BITS_PER_WORD’, so you may return any
       value in this case.  Do not define this macro if it would always
!      return ‘UNKNOWN’.  On machines where this macro is defined, you
!      will normally define it as the constant ‘SIGN_EXTEND’ or
!      ‘ZERO_EXTEND’.
  
!      You may return a non-‘UNKNOWN’ value even if for some hard
       registers the sign extension is not performed, if for the
!      ‘REGNO_REG_CLASS’ of these hard registers
!      ‘TARGET_CAN_CHANGE_MODE_CLASS’ returns false when the FROM mode is
       MEM_MODE and the TO mode is any integral mode larger than this but
!      not larger than ‘word_mode’.
  
!      You must return ‘UNKNOWN’ if for some hard registers that allow
!      this mode, ‘TARGET_CAN_CHANGE_MODE_CLASS’ says that they cannot
!      change to ‘word_mode’, but that they can change to another integral
       mode that is larger then MEM_MODE but still smaller than
!      ‘word_mode’.
  
   -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND
       Define this macro to 1 if loading short immediate values into
*************** Here are several miscellaneous parameter
*** 42885,42891 ****
  
   -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL
            (machine_mode MODE)
!      When '-ffast-math' is in effect, GCC tries to optimize divisions by
       the same divisor, by turning them into multiplications by the
       reciprocal.  This target hook specifies the minimum number of
       divisions that should be there for GCC to perform the optimization
--- 42884,42890 ----
  
   -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL
            (machine_mode MODE)
!      When ‘-ffast-math’ is in effect, GCC tries to optimize divisions by
       the same divisor, by turning them into multiplications by the
       reciprocal.  This target hook specifies the minimum number of
       divisions that should be there for GCC to perform the optimization
*************** Here are several miscellaneous parameter
*** 42901,42909 ****
   -- Macro: MAX_MOVE_MAX
       The maximum number of bytes that a single instruction can move
       quickly between memory and registers or between two memory
!      locations.  If this is undefined, the default is 'MOVE_MAX'.
       Otherwise, it is the constant value that is the largest value that
!      'MOVE_MAX' can have at run-time.
  
   -- Macro: SHIFT_COUNT_TRUNCATED
       A C expression that is nonzero if on this machine the number of
--- 42900,42908 ----
   -- Macro: MAX_MOVE_MAX
       The maximum number of bytes that a single instruction can move
       quickly between memory and registers or between two memory
!      locations.  If this is undefined, the default is ‘MOVE_MAX’.
       Otherwise, it is the constant value that is the largest value that
!      ‘MOVE_MAX’ can have at run-time.
  
   -- Macro: SHIFT_COUNT_TRUNCATED
       A C expression that is nonzero if on this machine the number of
*************** Here are several miscellaneous parameter
*** 42914,42920 ****
       'and' instructions that truncates the count of a shift operation.
       On machines that have instructions that act on bit-fields at
       variable positions, which may include 'bit test' instructions, a
!      nonzero 'SHIFT_COUNT_TRUNCATED' also enables deletion of
       truncations of the values that serve as arguments to bit-field
       instructions.
  
--- 42913,42919 ----
       'and' instructions that truncates the count of a shift operation.
       On machines that have instructions that act on bit-fields at
       variable positions, which may include 'bit test' instructions, a
!      nonzero ‘SHIFT_COUNT_TRUNCATED’ also enables deletion of
       truncations of the values that serve as arguments to bit-field
       instructions.
  
*************** Here are several miscellaneous parameter
*** 42924,42931 ****
  
       However, on some machines, such as the 80386 and the 680x0,
       truncation only applies to shift operations and not the (real or
!      pretended) bit-field operations.  Define 'SHIFT_COUNT_TRUNCATED' to
!      be zero on such machines.  Instead, add patterns to the 'md' file
       that include the implied truncation of the shift instructions.
  
       You need not define this macro if it would always have the value of
--- 42923,42930 ----
  
       However, on some machines, such as the 80386 and the 680x0,
       truncation only applies to shift operations and not the (real or
!      pretended) bit-field operations.  Define ‘SHIFT_COUNT_TRUNCATED’ to
!      be zero on such machines.  Instead, add patterns to the ‘md’ file
       that include the implied truncation of the shift instructions.
  
       You need not define this macro if it would always have the value of
*************** Here are several miscellaneous parameter
*** 42944,42957 ****
       should return 0.  A return value of 0 indicates that no particular
       behavior is guaranteed.
  
!      Note that, unlike 'SHIFT_COUNT_TRUNCATED', this function does _not_
       apply to general shift rtxes; it applies only to instructions that
       are generated by the named shift patterns.
  
       The default implementation of this function returns
!      'GET_MODE_BITSIZE (MODE) - 1' if 'SHIFT_COUNT_TRUNCATED' and 0
       otherwise.  This definition is always safe, but if
!      'SHIFT_COUNT_TRUNCATED' is false, and some shift patterns
       nevertheless truncate the shift count, you may get better code by
       overriding it.
  
--- 42943,42956 ----
       should return 0.  A return value of 0 indicates that no particular
       behavior is guaranteed.
  
!      Note that, unlike ‘SHIFT_COUNT_TRUNCATED’, this function does _not_
       apply to general shift rtxes; it applies only to instructions that
       are generated by the named shift patterns.
  
       The default implementation of this function returns
!      ‘GET_MODE_BITSIZE (MODE) - 1’ if ‘SHIFT_COUNT_TRUNCATED’ and 0
       otherwise.  This definition is always safe, but if
!      ‘SHIFT_COUNT_TRUNCATED’ is false, and some shift patterns
       nevertheless truncate the shift count, you may get better code by
       overriding it.
  
*************** Here are several miscellaneous parameter
*** 42961,42971 ****
       bits to one of OUTPREC bits (where OUTPREC is smaller than INPREC)
       by merely operating on it as if it had only OUTPREC bits.  The
       default returns true unconditionally, which is correct for most
!      machines.  When 'TARGET_TRULY_NOOP_TRUNCATION' returns false, the
!      machine description should provide a 'trunc' optab to specify the
       RTL that performs the required truncation.
  
!      If 'TARGET_MODES_TIEABLE_P' returns false for a pair of modes,
       suboptimal code can result if this hook returns true for the
       corresponding mode sizes.  Making this hook return false in such
       cases may improve things.
--- 42960,42970 ----
       bits to one of OUTPREC bits (where OUTPREC is smaller than INPREC)
       by merely operating on it as if it had only OUTPREC bits.  The
       default returns true unconditionally, which is correct for most
!      machines.  When ‘TARGET_TRULY_NOOP_TRUNCATION’ returns false, the
!      machine description should provide a ‘trunc’ optab to specify the
       RTL that performs the required truncation.
  
!      If ‘TARGET_MODES_TIEABLE_P’ returns false for a pair of modes,
       suboptimal code can result if this hook returns true for the
       corresponding mode sizes.  Making this hook return false in such
       cases may improve things.
*************** Here are several miscellaneous parameter
*** 42973,43037 ****
   -- Target Hook: int TARGET_MODE_REP_EXTENDED (scalar_int_mode MODE,
            scalar_int_mode REP_MODE)
       The representation of an integral mode can be such that the values
!      are always extended to a wider integral mode.  Return 'SIGN_EXTEND'
       if values of MODE are represented in sign-extended form to
!      REP_MODE.  Return 'UNKNOWN' otherwise.  (Currently, none of the
       targets use zero-extended representation this way so unlike
!      'LOAD_EXTEND_OP', 'TARGET_MODE_REP_EXTENDED' is expected to return
!      either 'SIGN_EXTEND' or 'UNKNOWN'.  Also no target extends MODE to
       REP_MODE so that REP_MODE is not the next widest integral mode and
       currently we take advantage of this fact.)
  
!      Similarly to 'LOAD_EXTEND_OP' you may return a non-'UNKNOWN' value
       even if the extension is not performed on certain hard registers as
!      long as for the 'REGNO_REG_CLASS' of these hard registers
!      'TARGET_CAN_CHANGE_MODE_CLASS' returns false.
  
!      Note that 'TARGET_MODE_REP_EXTENDED' and 'LOAD_EXTEND_OP' describe
!      two related properties.  If you define 'TARGET_MODE_REP_EXTENDED
!      (mode, word_mode)' you probably also want to define 'LOAD_EXTEND_OP
!      (mode)' to return the same type of extension.
  
!      In order to enforce the representation of 'mode',
!      'TARGET_TRULY_NOOP_TRUNCATION' should return false when truncating
!      to 'mode'.
  
   -- Target Hook: bool TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P (void)
       On some targets, it is assumed that the compiler will spill all
!      pseudos that are live across a call to 'setjmp', while other
!      targets treat 'setjmp' calls as normal function calls.
  
!      This hook returns false if 'setjmp' calls do not preserve all
       non-volatile registers so that gcc that must spill all pseudos that
!      are live across 'setjmp' calls.  Define this to return true if the
!      target does not need to spill all pseudos live across 'setjmp'
       calls.  The default implementation conservatively assumes all
!      pseudos must be spilled across 'setjmp' calls.
  
   -- Macro: STORE_FLAG_VALUE
       A C expression describing the value returned by a comparison
       operator with an integral mode and stored by a store-flag
!      instruction ('cstoreMODE4') when the condition is true.  This
!      description must apply to _all_ the 'cstoreMODE4' patterns and all
!      the comparison operators whose results have a 'MODE_INT' mode.
  
!      A value of 1 or -1 means that the instruction implementing the
!      comparison operator returns exactly 1 or -1 when the comparison is
       true and 0 when the comparison is false.  Otherwise, the value
       indicates which bits of the result are guaranteed to be 1 when the
       comparison is true.  This value is interpreted in the mode of the
       comparison operation, which is given by the mode of the first
!      operand in the 'cstoreMODE4' pattern.  Either the low bit or the
!      sign bit of 'STORE_FLAG_VALUE' be on.  Presently, only those bits
       are used by the compiler.
  
!      If 'STORE_FLAG_VALUE' is neither 1 or -1, the compiler will
       generate code that depends only on the specified bits.  It can also
       replace comparison operators with equivalent operations if they
       cause the required bits to be set, even if the remaining bits are
       undefined.  For example, on a machine whose comparison operators
!      return an 'SImode' value and where 'STORE_FLAG_VALUE' is defined as
!      '0x80000000', saying that just the sign bit is relevant, the
       expression
  
            (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0))
--- 42972,43036 ----
   -- Target Hook: int TARGET_MODE_REP_EXTENDED (scalar_int_mode MODE,
            scalar_int_mode REP_MODE)
       The representation of an integral mode can be such that the values
!      are always extended to a wider integral mode.  Return ‘SIGN_EXTEND’
       if values of MODE are represented in sign-extended form to
!      REP_MODE.  Return ‘UNKNOWN’ otherwise.  (Currently, none of the
       targets use zero-extended representation this way so unlike
!      ‘LOAD_EXTEND_OP’, ‘TARGET_MODE_REP_EXTENDED’ is expected to return
!      either ‘SIGN_EXTEND’ or ‘UNKNOWN’.  Also no target extends MODE to
       REP_MODE so that REP_MODE is not the next widest integral mode and
       currently we take advantage of this fact.)
  
!      Similarly to ‘LOAD_EXTEND_OP’ you may return a non-‘UNKNOWN’ value
       even if the extension is not performed on certain hard registers as
!      long as for the ‘REGNO_REG_CLASS’ of these hard registers
!      ‘TARGET_CAN_CHANGE_MODE_CLASS’ returns false.
  
!      Note that ‘TARGET_MODE_REP_EXTENDED’ and ‘LOAD_EXTEND_OP’ describe
!      two related properties.  If you define ‘TARGET_MODE_REP_EXTENDED
!      (mode, word_mode)’ you probably also want to define ‘LOAD_EXTEND_OP
!      (mode)’ to return the same type of extension.
  
!      In order to enforce the representation of ‘mode’,
!      ‘TARGET_TRULY_NOOP_TRUNCATION’ should return false when truncating
!      to ‘mode’.
  
   -- Target Hook: bool TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P (void)
       On some targets, it is assumed that the compiler will spill all
!      pseudos that are live across a call to ‘setjmp’, while other
!      targets treat ‘setjmp’ calls as normal function calls.
  
!      This hook returns false if ‘setjmp’ calls do not preserve all
       non-volatile registers so that gcc that must spill all pseudos that
!      are live across ‘setjmp’ calls.  Define this to return true if the
!      target does not need to spill all pseudos live across ‘setjmp’
       calls.  The default implementation conservatively assumes all
!      pseudos must be spilled across ‘setjmp’ calls.
  
   -- Macro: STORE_FLAG_VALUE
       A C expression describing the value returned by a comparison
       operator with an integral mode and stored by a store-flag
!      instruction (‘cstoreMODE4’) when the condition is true.  This
!      description must apply to _all_ the ‘cstoreMODE4’ patterns and all
!      the comparison operators whose results have a ‘MODE_INT’ mode.
  
!      A value of 1 or −1 means that the instruction implementing the
!      comparison operator returns exactly 1 or −1 when the comparison is
       true and 0 when the comparison is false.  Otherwise, the value
       indicates which bits of the result are guaranteed to be 1 when the
       comparison is true.  This value is interpreted in the mode of the
       comparison operation, which is given by the mode of the first
!      operand in the ‘cstoreMODE4’ pattern.  Either the low bit or the
!      sign bit of ‘STORE_FLAG_VALUE’ be on.  Presently, only those bits
       are used by the compiler.
  
!      If ‘STORE_FLAG_VALUE’ is neither 1 or −1, the compiler will
       generate code that depends only on the specified bits.  It can also
       replace comparison operators with equivalent operations if they
       cause the required bits to be set, even if the remaining bits are
       undefined.  For example, on a machine whose comparison operators
!      return an ‘SImode’ value and where ‘STORE_FLAG_VALUE’ is defined as
!      ‘0x80000000’, saying that just the sign bit is relevant, the
       expression
  
            (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0))
*************** Here are several miscellaneous parameter
*** 43053,43100 ****
  
       Often, a machine will have multiple instructions that obtain a
       value from a comparison (or the condition codes).  Here are rules
!      to guide the choice of value for 'STORE_FLAG_VALUE', and hence the
       instructions to be used:
  
!         * Use the shortest sequence that yields a valid definition for
!           'STORE_FLAG_VALUE'.  It is more efficient for the compiler to
            "normalize" the value (convert it to, e.g., 1 or 0) than for
            the comparison operators to do so because there may be
            opportunities to combine the normalization with other
            operations.
  
!         * For equal-length sequences, use a value of 1 or -1, with -1
            being slightly preferred on machines with expensive jumps and
            1 preferred on other machines.
  
!         * As a second choice, choose a value of '0x80000001' if
            instructions exist that set both the sign and low-order bits
            but do not define the others.
  
!         * Otherwise, use a value of '0x80000000'.
  
       Many machines can produce both the value chosen for
!      'STORE_FLAG_VALUE' and its negation in the same number of
       instructions.  On those machines, you should also define a pattern
       for those cases, e.g., one matching
  
            (set A (neg:M (ne:M B C)))
  
!      Some machines can also perform 'and' or 'plus' operations on
       condition code values with less instructions than the corresponding
!      'cstoreMODE4' insn followed by 'and' or 'plus'.  On those machines,
!      define the appropriate patterns.  Use the names 'incscc' and
!      'decscc', respectively, for the patterns which perform 'plus' or
!      'minus' operations on condition code values.  See 'rs6000.md' for
       some examples.  The GNU Superoptimizer can be used to find such
       instruction sequences on other machines.
  
       If this macro is not defined, the default value, 1, is used.  You
!      need not define 'STORE_FLAG_VALUE' if the machine has no store-flag
       instructions, or if the value generated by these instructions is 1.
  
   -- Macro: FLOAT_STORE_FLAG_VALUE (MODE)
!      A C expression that gives a nonzero 'REAL_VALUE_TYPE' value that is
       returned when comparison operators with floating-point results are
       true.  Define this macro on machines that have comparison
       operations that return floating-point values.  If there are no such
--- 43052,43099 ----
  
       Often, a machine will have multiple instructions that obtain a
       value from a comparison (or the condition codes).  Here are rules
!      to guide the choice of value for ‘STORE_FLAG_VALUE’, and hence the
       instructions to be used:
  
!         • Use the shortest sequence that yields a valid definition for
!           ‘STORE_FLAG_VALUE’.  It is more efficient for the compiler to
            "normalize" the value (convert it to, e.g., 1 or 0) than for
            the comparison operators to do so because there may be
            opportunities to combine the normalization with other
            operations.
  
!         • For equal-length sequences, use a value of 1 or −1, with −1
            being slightly preferred on machines with expensive jumps and
            1 preferred on other machines.
  
!         • As a second choice, choose a value of ‘0x80000001’ if
            instructions exist that set both the sign and low-order bits
            but do not define the others.
  
!         • Otherwise, use a value of ‘0x80000000’.
  
       Many machines can produce both the value chosen for
!      ‘STORE_FLAG_VALUE’ and its negation in the same number of
       instructions.  On those machines, you should also define a pattern
       for those cases, e.g., one matching
  
            (set A (neg:M (ne:M B C)))
  
!      Some machines can also perform ‘and’ or ‘plus’ operations on
       condition code values with less instructions than the corresponding
!      ‘cstoreMODE4’ insn followed by ‘and’ or ‘plus’.  On those machines,
!      define the appropriate patterns.  Use the names ‘incscc’ and
!      ‘decscc’, respectively, for the patterns which perform ‘plus’ or
!      ‘minus’ operations on condition code values.  See ‘rs6000.md’ for
       some examples.  The GNU Superoptimizer can be used to find such
       instruction sequences on other machines.
  
       If this macro is not defined, the default value, 1, is used.  You
!      need not define ‘STORE_FLAG_VALUE’ if the machine has no store-flag
       instructions, or if the value generated by these instructions is 1.
  
   -- Macro: FLOAT_STORE_FLAG_VALUE (MODE)
!      A C expression that gives a nonzero ‘REAL_VALUE_TYPE’ value that is
       returned when comparison operators with floating-point results are
       true.  Define this macro on machines that have comparison
       operations that return floating-point values.  If there are no such
*************** Here are several miscellaneous parameter
*** 43107,43137 ****
       Define this macro on machines that have vector comparison
       operations that return a vector result.  If there are no such
       operations, do not define this macro.  Typically, this macro is
!      defined as 'const1_rtx' or 'constm1_rtx'.  This macro may return
!      'NULL_RTX' to prevent the compiler optimizing such vector
       comparison operations for the given mode.
  
   -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
   -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
       A C expression that indicates whether the architecture defines a
!      value for 'clz' or 'ctz' with a zero operand.  A result of '0'
       indicates the value is undefined.  If the value is defined for only
!      the RTL expression, the macro should evaluate to '1'; if the value
       applies also to the corresponding optab entry (which is normally
       the case if it expands directly into the corresponding RTL), then
!      the macro should evaluate to '2'.  In the cases where the value is
       defined, VALUE should be set to this value.
  
!      If this macro is not defined, the value of 'clz' or 'ctz' at zero
       is assumed to be undefined.
  
!      This macro must be defined if the target's expansion for 'ffs'
       relies on a particular value to get correct results.  Otherwise it
       is not necessary, though it may be used to optimize some corner
!      cases, and to provide a default expansion for the 'ffs' optab.
  
!      Note that regardless of this macro the "definedness" of 'clz' and
!      'ctz' at zero do _not_ extend to the builtin functions visible to
       the user.  Thus one may be free to adjust the value at will to
       match the target expansion of these operations without fear of
       breaking the API.
--- 43106,43136 ----
       Define this macro on machines that have vector comparison
       operations that return a vector result.  If there are no such
       operations, do not define this macro.  Typically, this macro is
!      defined as ‘const1_rtx’ or ‘constm1_rtx’.  This macro may return
!      ‘NULL_RTX’ to prevent the compiler optimizing such vector
       comparison operations for the given mode.
  
   -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
   -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
       A C expression that indicates whether the architecture defines a
!      value for ‘clz’ or ‘ctz’ with a zero operand.  A result of ‘0’
       indicates the value is undefined.  If the value is defined for only
!      the RTL expression, the macro should evaluate to ‘1’; if the value
       applies also to the corresponding optab entry (which is normally
       the case if it expands directly into the corresponding RTL), then
!      the macro should evaluate to ‘2’.  In the cases where the value is
       defined, VALUE should be set to this value.
  
!      If this macro is not defined, the value of ‘clz’ or ‘ctz’ at zero
       is assumed to be undefined.
  
!      This macro must be defined if the target's expansion for ‘ffs’
       relies on a particular value to get correct results.  Otherwise it
       is not necessary, though it may be used to optimize some corner
!      cases, and to provide a default expansion for the ‘ffs’ optab.
  
!      Note that regardless of this macro the "definedness" of ‘clz’ and
!      ‘ctz’ at zero do _not_ extend to the builtin functions visible to
       the user.  Thus one may be free to adjust the value at will to
       match the target expansion of these operations without fear of
       breaking the API.
*************** Here are several miscellaneous parameter
*** 43139,43179 ****
   -- Macro: Pmode
       An alias for the machine mode for pointers.  On most machines,
       define this to be the integer mode corresponding to the width of a
!      hardware pointer; 'SImode' on 32-bit machine or 'DImode' on 64-bit
       machines.  On some machines you must define this to be one of the
!      partial integer modes, such as 'PSImode'.
  
!      The width of 'Pmode' must be at least as large as the value of
!      'POINTER_SIZE'.  If it is not equal, you must define the macro
!      'POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to
!      'Pmode'.
  
   -- Macro: FUNCTION_MODE
       An alias for the machine mode used for memory references to
!      functions being called, in 'call' RTL expressions.  On most CISC
       machines, where an instruction can begin at any byte address, this
!      should be 'QImode'.  On most RISC machines, where all instructions
       have fixed size and alignment, this should be a mode with the same
       size and alignment as the machine instruction words - typically
!      'SImode' or 'HImode'.
  
   -- Macro: STDC_0_IN_SYSTEM_HEADERS
!      In normal operation, the preprocessor expands '__STDC__' to the
       constant 1, to signify that GCC conforms to ISO Standard C.  On
       some hosts, like Solaris, the system compiler uses a different
!      convention, where '__STDC__' is normally 0, but is 1 if the user
       specifies strict conformance to the C Standard.
  
!      Defining 'STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host
       convention when processing system header files, but when processing
!      user files '__STDC__' will always expand to 1.
  
   -- C Target Hook: const char * TARGET_C_PREINCLUDE (void)
       Define this hook to return the name of a header file to be included
       at the start of all compilations, as if it had been included with
!      '#include '.  If this hook returns 'NULL', or is not defined,
       or the header is not found, or if the user specifies
!      '-ffreestanding' or '-nostdinc', no header is included.
  
       This hook can be used together with a header provided by the system
       C library to implement ISO C requirements for certain macros to be
--- 43138,43178 ----
   -- Macro: Pmode
       An alias for the machine mode for pointers.  On most machines,
       define this to be the integer mode corresponding to the width of a
!      hardware pointer; ‘SImode’ on 32-bit machine or ‘DImode’ on 64-bit
       machines.  On some machines you must define this to be one of the
!      partial integer modes, such as ‘PSImode’.
  
!      The width of ‘Pmode’ must be at least as large as the value of
!      ‘POINTER_SIZE’.  If it is not equal, you must define the macro
!      ‘POINTERS_EXTEND_UNSIGNED’ to specify how pointers are extended to
!      ‘Pmode’.
  
   -- Macro: FUNCTION_MODE
       An alias for the machine mode used for memory references to
!      functions being called, in ‘call’ RTL expressions.  On most CISC
       machines, where an instruction can begin at any byte address, this
!      should be ‘QImode’.  On most RISC machines, where all instructions
       have fixed size and alignment, this should be a mode with the same
       size and alignment as the machine instruction words - typically
!      ‘SImode’ or ‘HImode’.
  
   -- Macro: STDC_0_IN_SYSTEM_HEADERS
!      In normal operation, the preprocessor expands ‘__STDC__’ to the
       constant 1, to signify that GCC conforms to ISO Standard C.  On
       some hosts, like Solaris, the system compiler uses a different
!      convention, where ‘__STDC__’ is normally 0, but is 1 if the user
       specifies strict conformance to the C Standard.
  
!      Defining ‘STDC_0_IN_SYSTEM_HEADERS’ makes GNU CPP follows the host
       convention when processing system header files, but when processing
!      user files ‘__STDC__’ will always expand to 1.
  
   -- C Target Hook: const char * TARGET_C_PREINCLUDE (void)
       Define this hook to return the name of a header file to be included
       at the start of all compilations, as if it had been included with
!      ‘#include ’.  If this hook returns ‘NULL’, or is not defined,
       or the header is not found, or if the user specifies
!      ‘-ffreestanding’ or ‘-nostdinc’, no header is included.
  
       This hook can be used together with a header provided by the system
       C library to implement ISO C requirements for certain macros to be
*************** Here are several miscellaneous parameter
*** 43191,43202 ****
   -- Macro: SYSTEM_IMPLICIT_EXTERN_C
       Define this macro if the system header files do not support C++.
       This macro handles system header files by pretending that system
!      header files are enclosed in 'extern "C" {...}'.
  
   -- Macro: REGISTER_TARGET_PRAGMAS ()
       Define this macro if you want to implement any target-specific
       pragmas.  If defined, it is a C expression which makes a series of
!      calls to 'c_register_pragma' or 'c_register_pragma_with_expansion'
       for each pragma.  The macro may also do any setup required for the
       pragmas.
  
--- 43190,43201 ----
   -- Macro: SYSTEM_IMPLICIT_EXTERN_C
       Define this macro if the system header files do not support C++.
       This macro handles system header files by pretending that system
!      header files are enclosed in ‘extern "C" {...}’.
  
   -- Macro: REGISTER_TARGET_PRAGMAS ()
       Define this macro if you want to implement any target-specific
       pragmas.  If defined, it is a C expression which makes a series of
!      calls to ‘c_register_pragma’ or ‘c_register_pragma_with_expansion’
       for each pragma.  The macro may also do any setup required for the
       pragmas.
  
*************** Here are several miscellaneous parameter
*** 43205,43266 ****
       discourage definition of target-specific pragmas for GCC.
  
       If the pragma can be implemented by attributes then you should
!      consider defining the target hook 'TARGET_INSERT_ATTRIBUTES' as
       well.
  
       Preprocessor macros that appear on pragma lines are not expanded.
!      All '#pragma' directives that do not match any registered pragma
       are silently ignored, unless the user specifies
!      '-Wunknown-pragmas'.
  
   -- Function: void c_register_pragma (const char *SPACE, const char
            *NAME, void (*CALLBACK) (struct cpp_reader *))
   -- Function: void c_register_pragma_with_expansion (const char *SPACE,
            const char *NAME, void (*CALLBACK) (struct cpp_reader *))
  
!      Each call to 'c_register_pragma' or
!      'c_register_pragma_with_expansion' establishes one pragma.  The
       CALLBACK routine will be called when the preprocessor encounters a
       pragma of the form
  
            #pragma [SPACE] NAME ...
  
!      SPACE is the case-sensitive namespace of the pragma, or 'NULL' to
       put the pragma in the global namespace.  The callback routine
       receives PFILE as its first argument, which can be passed on to
       cpplib's functions if necessary.  You can lex tokens after the NAME
!      by calling 'pragma_lex'.  Tokens that are not read by the callback
       will be silently ignored.  The end of the line is indicated by a
!      token of type 'CPP_EOF'.  Macro expansion occurs on the arguments
!      of pragmas registered with 'c_register_pragma_with_expansion' but
       not on the arguments of pragmas registered with
!      'c_register_pragma'.
  
!      Note that the use of 'pragma_lex' is specific to the C and C++
       compilers.  It will not work in the Java or Fortran compilers, or
!      any other language compilers for that matter.  Thus if 'pragma_lex'
       is going to be called from target-specific code, it must only be
       done so when building the C and C++ compilers.  This can be done by
!      defining the variables 'c_target_objs' and 'cxx_target_objs' in the
!      target entry in the 'config.gcc' file.  These variables should name
       the target-specific, language-specific object file which contains
!      the code that uses 'pragma_lex'.  Note it will also be necessary to
!      add a rule to the makefile fragment pointed to by 'tmake_file' that
       shows how to build this object file.
  
   -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION
       Define this macro if macros should be expanded in the arguments of
!      '#pragma pack'.
  
   -- Macro: TARGET_DEFAULT_PACK_STRUCT
       If your target requires a structure packing default other than 0
       (meaning the machine default), define this macro to the necessary
       value (in bytes).  This must be a value that would also be valid to
!      use with '#pragma pack()' (that is, a small power of two).
  
   -- Macro: DOLLARS_IN_IDENTIFIERS
!      Define this macro to control use of the character '$' in identifier
!      names for the C family of languages.  0 means '$' is not allowed by
       default; 1 means it is allowed.  1 is the default; there is no need
       to define this macro in that case.
  
--- 43204,43265 ----
       discourage definition of target-specific pragmas for GCC.
  
       If the pragma can be implemented by attributes then you should
!      consider defining the target hook ‘TARGET_INSERT_ATTRIBUTES’ as
       well.
  
       Preprocessor macros that appear on pragma lines are not expanded.
!      All ‘#pragma’ directives that do not match any registered pragma
       are silently ignored, unless the user specifies
!      ‘-Wunknown-pragmas’.
  
   -- Function: void c_register_pragma (const char *SPACE, const char
            *NAME, void (*CALLBACK) (struct cpp_reader *))
   -- Function: void c_register_pragma_with_expansion (const char *SPACE,
            const char *NAME, void (*CALLBACK) (struct cpp_reader *))
  
!      Each call to ‘c_register_pragma’ or
!      ‘c_register_pragma_with_expansion’ establishes one pragma.  The
       CALLBACK routine will be called when the preprocessor encounters a
       pragma of the form
  
            #pragma [SPACE] NAME ...
  
!      SPACE is the case-sensitive namespace of the pragma, or ‘NULL’ to
       put the pragma in the global namespace.  The callback routine
       receives PFILE as its first argument, which can be passed on to
       cpplib's functions if necessary.  You can lex tokens after the NAME
!      by calling ‘pragma_lex’.  Tokens that are not read by the callback
       will be silently ignored.  The end of the line is indicated by a
!      token of type ‘CPP_EOF’.  Macro expansion occurs on the arguments
!      of pragmas registered with ‘c_register_pragma_with_expansion’ but
       not on the arguments of pragmas registered with
!      ‘c_register_pragma’.
  
!      Note that the use of ‘pragma_lex’ is specific to the C and C++
       compilers.  It will not work in the Java or Fortran compilers, or
!      any other language compilers for that matter.  Thus if ‘pragma_lex’
       is going to be called from target-specific code, it must only be
       done so when building the C and C++ compilers.  This can be done by
!      defining the variables ‘c_target_objs’ and ‘cxx_target_objs’ in the
!      target entry in the ‘config.gcc’ file.  These variables should name
       the target-specific, language-specific object file which contains
!      the code that uses ‘pragma_lex’.  Note it will also be necessary to
!      add a rule to the makefile fragment pointed to by ‘tmake_file’ that
       shows how to build this object file.
  
   -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION
       Define this macro if macros should be expanded in the arguments of
!      ‘#pragma pack’.
  
   -- Macro: TARGET_DEFAULT_PACK_STRUCT
       If your target requires a structure packing default other than 0
       (meaning the machine default), define this macro to the necessary
       value (in bytes).  This must be a value that would also be valid to
!      use with ‘#pragma pack()’ (that is, a small power of two).
  
   -- Macro: DOLLARS_IN_IDENTIFIERS
!      Define this macro to control use of the character ‘$’ in identifier
!      names for the C family of languages.  0 means ‘$’ is not allowed by
       default; 1 means it is allowed.  1 is the default; there is no need
       to define this macro in that case.
  
*************** Here are several miscellaneous parameter
*** 43268,43276 ****
       Define this macro as a C expression that is nonzero if it is safe
       for the delay slot scheduler to place instructions in the delay
       slot of INSN, even if they appear to use a resource set or
!      clobbered in INSN.  INSN is always a 'jump_insn' or an 'insn'; GCC
!      knows that every 'call_insn' has this behavior.  On machines where
!      some 'insn' or 'jump_insn' is really a function call and hence has
       this behavior, you should define this macro.
  
       You need not define this macro if it would always return zero.
--- 43267,43275 ----
       Define this macro as a C expression that is nonzero if it is safe
       for the delay slot scheduler to place instructions in the delay
       slot of INSN, even if they appear to use a resource set or
!      clobbered in INSN.  INSN is always a ‘jump_insn’ or an ‘insn’; GCC
!      knows that every ‘call_insn’ has this behavior.  On machines where
!      some ‘insn’ or ‘jump_insn’ is really a function call and hence has
       this behavior, you should define this macro.
  
       You need not define this macro if it would always return zero.
*************** Here are several miscellaneous parameter
*** 43279,43286 ****
       Define this macro as a C expression that is nonzero if it is safe
       for the delay slot scheduler to place instructions in the delay
       slot of INSN, even if they appear to set or clobber a resource
!      referenced in INSN.  INSN is always a 'jump_insn' or an 'insn'.  On
!      machines where some 'insn' or 'jump_insn' is really a function call
       and its operands are registers whose use is actually in the
       subroutine it calls, you should define this macro.  Doing so allows
       the delay slot scheduler to move instructions which copy arguments
--- 43278,43285 ----
       Define this macro as a C expression that is nonzero if it is safe
       for the delay slot scheduler to place instructions in the delay
       slot of INSN, even if they appear to set or clobber a resource
!      referenced in INSN.  INSN is always a ‘jump_insn’ or an ‘insn’.  On
!      machines where some ‘insn’ or ‘jump_insn’ is really a function call
       and its operands are registers whose use is actually in the
       subroutine it calls, you should define this macro.  Doing so allows
       the delay slot scheduler to move instructions which copy arguments
*************** Here are several miscellaneous parameter
*** 43301,43307 ****
            vec& INPUTS, vec& INPUT_MODES, vec& CONSTRAINTS, vec& CLOBBERS, HARD_REG_SET&
            CLOBBERED_REGS, location_t LOC)
!      This target hook may add "clobbers" to CLOBBERS and CLOBBERED_REGS
       for any hard regs the port wishes to automatically clobber for an
       asm.  The OUTPUTS and INPUTS may be inspected to avoid clobbering a
       register that is already used by the asm.  LOC is the source
--- 43300,43306 ----
            vec& INPUTS, vec& INPUT_MODES, vec& CONSTRAINTS, vec& CLOBBERS, HARD_REG_SET&
            CLOBBERED_REGS, location_t LOC)
!      This target hook may add “clobbers” to CLOBBERS and CLOBBERED_REGS
       for any hard regs the port wishes to automatically clobber for an
       asm.  The OUTPUTS and INPUTS may be inspected to avoid clobbering a
       register that is already used by the asm.  LOC is the source
*************** Here are several miscellaneous parameter
*** 43315,43336 ****
  
   -- Macro: MATH_LIBRARY
       Define this macro as a C string constant for the linker argument to
!      link in the system math library, minus the initial '"-l"', or '""'
       if the target does not have a separate math library.
  
!      You need only define this macro if the default of '"m"' is wrong.
  
   -- Macro: LIBRARY_PATH_ENV
       Define this macro as a C string constant for the environment
       variable that specifies where the linker should look for libraries.
  
!      You need only define this macro if the default of '"LIBRARY_PATH"'
       is wrong.
  
   -- Macro: TARGET_POSIX_IO
       Define this macro if the target supports the following POSIX file
       functions, access, mkdir and file locking with fcntl / F_SETLKW.
!      Defining 'TARGET_POSIX_IO' will enable the test coverage code to
       use file locking when exiting a program, which avoids race
       conditions if the program has forked.  It will also create
       directories at run-time for cross-profiling.
--- 43314,43335 ----
  
   -- Macro: MATH_LIBRARY
       Define this macro as a C string constant for the linker argument to
!      link in the system math library, minus the initial ‘"-l"’, or ‘""’
       if the target does not have a separate math library.
  
!      You need only define this macro if the default of ‘"m"’ is wrong.
  
   -- Macro: LIBRARY_PATH_ENV
       Define this macro as a C string constant for the environment
       variable that specifies where the linker should look for libraries.
  
!      You need only define this macro if the default of ‘"LIBRARY_PATH"’
       is wrong.
  
   -- Macro: TARGET_POSIX_IO
       Define this macro if the target supports the following POSIX file
       functions, access, mkdir and file locking with fcntl / F_SETLKW.
!      Defining ‘TARGET_POSIX_IO’ will enable the test coverage code to
       use file locking when exiting a program, which avoids race
       conditions if the program has forked.  It will also create
       directories at run-time for cross-profiling.
*************** Here are several miscellaneous parameter
*** 43339,43351 ****
  
       A C expression for the maximum number of instructions to execute
       via conditional execution instructions instead of a branch.  A
!      value of 'BRANCH_COST'+1 is the default.
  
   -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR)
       Used if the target needs to perform machine-dependent modifications
       on the conditionals used for turning basic blocks into
       conditionally executed code.  CE_INFO points to a data structure,
!      'struct ce_if_block', which contains information about the
       currently processed blocks.  TRUE_EXPR and FALSE_EXPR are the tests
       that are used for converting the then-block and the else-block,
       respectively.  Set either TRUE_EXPR or FALSE_EXPR to a null pointer
--- 43338,43350 ----
  
       A C expression for the maximum number of instructions to execute
       via conditional execution instructions instead of a branch.  A
!      value of ‘BRANCH_COST’+1 is the default.
  
   -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR)
       Used if the target needs to perform machine-dependent modifications
       on the conditionals used for turning basic blocks into
       conditionally executed code.  CE_INFO points to a data structure,
!      ‘struct ce_if_block’, which contains information about the
       currently processed blocks.  TRUE_EXPR and FALSE_EXPR are the tests
       that are used for converting the then-block and the else-block,
       respectively.  Set either TRUE_EXPR or FALSE_EXPR to a null pointer
*************** Here are several miscellaneous parameter
*** 43353,43385 ****
  
   -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR,
            FALSE_EXPR)
!      Like 'IFCVT_MODIFY_TESTS', but used when converting more
!      complicated if-statements into conditions combined by 'and' and
!      'or' operations.  BB contains the basic block that contains the
       test that is currently being processed and about to be turned into
       a condition.
  
   -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN)
       A C expression to modify the PATTERN of an INSN that is to be
       converted to conditional execution format.  CE_INFO points to a
!      data structure, 'struct ce_if_block', which contains information
       about the currently processed blocks.
  
   -- Macro: IFCVT_MODIFY_FINAL (CE_INFO)
       A C expression to perform any final machine dependent modifications
       in converting code to conditional execution.  The involved basic
!      blocks can be found in the 'struct ce_if_block' structure that is
       pointed to by CE_INFO.
  
   -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO)
       A C expression to cancel any machine dependent modifications in
       converting code to conditional execution.  The involved basic
!      blocks can be found in the 'struct ce_if_block' structure that is
       pointed to by CE_INFO.
  
   -- Macro: IFCVT_MACHDEP_INIT (CE_INFO)
       A C expression to initialize any machine specific data for
!      if-conversion of the if-block in the 'struct ce_if_block' structure
       that is pointed to by CE_INFO.
  
   -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void)
--- 43352,43384 ----
  
   -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR,
            FALSE_EXPR)
!      Like ‘IFCVT_MODIFY_TESTS’, but used when converting more
!      complicated if-statements into conditions combined by ‘and’ and
!      ‘or’ operations.  BB contains the basic block that contains the
       test that is currently being processed and about to be turned into
       a condition.
  
   -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN)
       A C expression to modify the PATTERN of an INSN that is to be
       converted to conditional execution format.  CE_INFO points to a
!      data structure, ‘struct ce_if_block’, which contains information
       about the currently processed blocks.
  
   -- Macro: IFCVT_MODIFY_FINAL (CE_INFO)
       A C expression to perform any final machine dependent modifications
       in converting code to conditional execution.  The involved basic
!      blocks can be found in the ‘struct ce_if_block’ structure that is
       pointed to by CE_INFO.
  
   -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO)
       A C expression to cancel any machine dependent modifications in
       converting code to conditional execution.  The involved basic
!      blocks can be found in the ‘struct ce_if_block’ structure that is
       pointed to by CE_INFO.
  
   -- Macro: IFCVT_MACHDEP_INIT (CE_INFO)
       A C expression to initialize any machine specific data for
!      if-conversion of the if-block in the ‘struct ce_if_block’ structure
       that is pointed to by CE_INFO.
  
   -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void)
*************** Here are several miscellaneous parameter
*** 43408,43417 ****
       example, SIMD vector instructions or prefetch instructions).
  
       To create a built-in function, call the function
!      'lang_hooks.builtin_function' which is defined by the language
       front end.  You can use any type nodes set up by
!      'build_common_tree_nodes'; only language front ends that use those
!      two functions will call 'TARGET_INIT_BUILTINS'.
  
   -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool
            INITIALIZE_P)
--- 43407,43416 ----
       example, SIMD vector instructions or prefetch instructions).
  
       To create a built-in function, call the function
!      ‘lang_hooks.builtin_function’ which is defined by the language
       front end.  You can use any type nodes set up by
!      ‘build_common_tree_nodes’; only language front ends that use those
!      two functions will call ‘TARGET_INIT_BUILTINS’.
  
   -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool
            INITIALIZE_P)
*************** Here are several miscellaneous parameter
*** 43420,43433 ****
       returns the builtin function declaration for the builtin function
       code CODE.  If there is no such builtin and it cannot be
       initialized at this time if INITIALIZE_P is true the function
!      should return 'NULL_TREE'.  If CODE is out of range the function
!      should return 'error_mark_node'.
  
   -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx
            SUBTARGET, machine_mode MODE, int IGNORE)
  
       Expand a call to a machine specific built-in function that was set
!      up by 'TARGET_INIT_BUILTINS'.  EXP is the expression for the
       function call; the result should go to TARGET if that is
       convenient, and have mode MODE if that is convenient.  SUBTARGET
       may be used as the target for computing one of EXP's operands.
--- 43419,43432 ----
       returns the builtin function declaration for the builtin function
       code CODE.  If there is no such builtin and it cannot be
       initialized at this time if INITIALIZE_P is true the function
!      should return ‘NULL_TREE’.  If CODE is out of range the function
!      should return ‘error_mark_node’.
  
   -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx
            SUBTARGET, machine_mode MODE, int IGNORE)
  
       Expand a call to a machine specific built-in function that was set
!      up by ‘TARGET_INIT_BUILTINS’.  EXP is the expression for the
       function call; the result should go to TARGET if that is
       convenient, and have mode MODE if that is convenient.  SUBTARGET
       may be used as the target for computing one of EXP's operands.
*************** Here are several miscellaneous parameter
*** 43437,43449 ****
   -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int
            LOC, tree FNDECL, void *ARGLIST)
       Select a replacement for a machine specific built-in function that
!      was set up by 'TARGET_INIT_BUILTINS'.  This is done _before_
       regular type checking, and so allows the target to implement a
       crude form of function overloading.  FNDECL is the declaration of
       the built-in function.  ARGLIST is the list of arguments passed to
       the built-in function.  The result is a complete expression that
!      implements the operation, usually another 'CALL_EXPR'.  ARGLIST
!      really has type 'VEC(tree,gc)*'
  
   -- Target Hook: bool TARGET_CHECK_BUILTIN_CALL (location_t LOC,
            vec ARG_LOC, tree FNDECL, tree ORIG_FNDECL,
--- 43436,43448 ----
   -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int
            LOC, tree FNDECL, void *ARGLIST)
       Select a replacement for a machine specific built-in function that
!      was set up by ‘TARGET_INIT_BUILTINS’.  This is done _before_
       regular type checking, and so allows the target to implement a
       crude form of function overloading.  FNDECL is the declaration of
       the built-in function.  ARGLIST is the list of arguments passed to
       the built-in function.  The result is a complete expression that
!      implements the operation, usually another ‘CALL_EXPR’.  ARGLIST
!      really has type ‘VEC(tree,gc)*’
  
   -- Target Hook: bool TARGET_CHECK_BUILTIN_CALL (location_t LOC,
            vec ARG_LOC, tree FNDECL, tree ORIG_FNDECL,
*************** Here are several miscellaneous parameter
*** 43453,43461 ****
       signature.  Return true if the call is valid, otherwise report an
       error and return false.
  
!      This hook is called after 'TARGET_RESOLVE_OVERLOADED_BUILTIN'.  The
       call was originally to built-in function ORIG_FNDECL, but after the
!      optional 'TARGET_RESOLVE_OVERLOADED_BUILTIN' step is now to
       built-in function FNDECL.  LOC is the location of the call and ARGS
       is an array of function arguments, of which there are NARGS.
       ARG_LOC specifies the location of each argument.
--- 43452,43460 ----
       signature.  Return true if the call is valid, otherwise report an
       error and return false.
  
!      This hook is called after ‘TARGET_RESOLVE_OVERLOADED_BUILTIN’.  The
       call was originally to built-in function ORIG_FNDECL, but after the
!      optional ‘TARGET_RESOLVE_OVERLOADED_BUILTIN’ step is now to
       built-in function FNDECL.  LOC is the location of the call and ARGS
       is an array of function arguments, of which there are NARGS.
       ARG_LOC specifies the location of each argument.
*************** Here are several miscellaneous parameter
*** 43463,43469 ****
   -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, tree
            *ARGP, bool IGNORE)
       Fold a call to a machine specific built-in function that was set up
!      by 'TARGET_INIT_BUILTINS'.  FNDECL is the declaration of the
       built-in function.  N_ARGS is the number of arguments passed to the
       function; the arguments themselves are pointed to by ARGP.  The
       result is another tree, valid for both GIMPLE and GENERIC,
--- 43462,43468 ----
   -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, tree
            *ARGP, bool IGNORE)
       Fold a call to a machine specific built-in function that was set up
!      by ‘TARGET_INIT_BUILTINS’.  FNDECL is the declaration of the
       built-in function.  N_ARGS is the number of arguments passed to the
       function; the arguments themselves are pointed to by ARGP.  The
       result is another tree, valid for both GIMPLE and GENERIC,
*************** Here are several miscellaneous parameter
*** 43473,43479 ****
   -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator
            *GSI)
       Fold a call to a machine specific built-in function that was set up
!      by 'TARGET_INIT_BUILTINS'.  GSI points to the gimple statement
       holding the function call.  Returns true if any change was made to
       the GIMPLE stream.
  
--- 43472,43478 ----
   -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator
            *GSI)
       Fold a call to a machine specific built-in function that was set up
!      by ‘TARGET_INIT_BUILTINS’.  GSI points to the gimple statement
       holding the function call.  Returns true if any change was made to
       the GIMPLE stream.
  
*************** Here are several miscellaneous parameter
*** 43537,43543 ****
            &ITERATIONS, const widest_int &ITERATIONS_MAX, unsigned int
            LOOP_DEPTH, bool ENTERED_AT_TOP)
       Return true if it is possible to use low-overhead loops
!      ('doloop_end' and 'doloop_begin') for a particular loop.
       ITERATIONS gives the exact number of iterations, or 0 if not known.
       ITERATIONS_MAX gives the maximum number of iterations, or 0 if not
       known.  LOOP_DEPTH is the nesting depth of the loop, with 1 for
--- 43536,43542 ----
            &ITERATIONS, const widest_int &ITERATIONS_MAX, unsigned int
            LOOP_DEPTH, bool ENTERED_AT_TOP)
       Return true if it is possible to use low-overhead loops
!      (‘doloop_end’ and ‘doloop_begin’) for a particular loop.
       ITERATIONS gives the exact number of iterations, or 0 if not known.
       ITERATIONS_MAX gives the maximum number of iterations, or 0 if not
       known.  LOOP_DEPTH is the nesting depth of the loop, with 1 for
*************** Here are several miscellaneous parameter
*** 43545,43553 ****
       on.  ENTERED_AT_TOP is true if the loop is only entered from the
       top.
  
!      This hook is only used if 'doloop_end' is available.  The default
       implementation returns true.  You can use
!      'can_use_doloop_if_innermost' if the loop must be the innermost,
       and if there are no other restrictions.
  
   -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const
--- 43544,43552 ----
       on.  ENTERED_AT_TOP is true if the loop is only entered from the
       top.
  
!      This hook is only used if ‘doloop_end’ is available.  The default
       implementation returns true.  You can use
!      ‘can_use_doloop_if_innermost’ if the loop must be the innermost,
       and if there are no other restrictions.
  
   -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const
*************** Here are several miscellaneous parameter
*** 43566,43581 ****
  
   -- Target Hook: machine_mode TARGET_PREFERRED_DOLOOP_MODE (machine_mode
            MODE)
!      This hook takes a MODE for a doloop IV, where 'mode' is the
       original mode for the operation.  If the target prefers an
!      alternate 'mode' for the operation, then this hook should return
!      that mode; otherwise the original 'mode' should be returned.  For
!      example, on a 64-bit target, 'DImode' might be preferred over
!      'SImode'.  Both the original and the returned modes should be
!      'MODE_INT'.
  
   -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx_insn *INSN)
!      Take an instruction in INSN and return 'false' if the instruction
       is not appropriate as a combination of two or more instructions.
       The default is to accept all instructions.
  
--- 43565,43580 ----
  
   -- Target Hook: machine_mode TARGET_PREFERRED_DOLOOP_MODE (machine_mode
            MODE)
!      This hook takes a MODE for a doloop IV, where ‘mode’ is the
       original mode for the operation.  If the target prefers an
!      alternate ‘mode’ for the operation, then this hook should return
!      that mode; otherwise the original ‘mode’ should be returned.  For
!      example, on a 64-bit target, ‘DImode’ might be preferred over
!      ‘SImode’.  Both the original and the returned modes should be
!      ‘MODE_INT’.
  
   -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx_insn *INSN)
!      Take an instruction in INSN and return ‘false’ if the instruction
       is not appropriate as a combination of two or more instructions.
       The default is to accept all instructions.
  
*************** Here are several miscellaneous parameter
*** 43587,43593 ****
       made to follow through a hot/cold partitioning.
  
   -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE)
!      This target hook returns 'true' if X is considered to be
       commutative.  Usually, this is just COMMUTATIVE_P (X), but the HP
       PA doesn't consider PLUS to be commutative inside a MEM.
       OUTER_CODE is the rtx code of the enclosing rtl, if known,
--- 43586,43592 ----
       made to follow through a hot/cold partitioning.
  
   -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE)
!      This target hook returns ‘true’ if X is considered to be
       commutative.  Usually, this is just COMMUTATIVE_P (X), but the HP
       PA doesn't consider PLUS to be commutative inside a MEM.
       OUTER_CODE is the rtx code of the enclosing rtl, if known,
*************** Here are several miscellaneous parameter
*** 43599,43629 ****
       pseudo register, it is often not necessary to actually allocate
       another register to this pseudo register, because the original hard
       register or a stack slot it has been saved into can be used.
!      'TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register
       allocation once for each hard register that had its initial value
!      copied by using 'get_func_hard_reg_initial_val' or
!      'get_hard_reg_initial_val'.  Possible values are 'NULL_RTX', if you
!      don't want to do any special allocation, a 'REG' rtx--that would
       typically be the hard register itself, if it is known not to be
!      clobbered--or a 'MEM'.  If you are returning a 'MEM', this is only
       a hint for the allocator; it might decide to use another register
!      anyways.  You may use 'current_function_is_leaf' or 'REG_N_SETS' in
       the hook to determine if the hard register in question will not be
!      clobbered.  The default value of this hook is 'NULL', which
       disables any special allocation.
  
   -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned
            FLAGS)
!      This target hook returns nonzero if X, an 'unspec' or
!      'unspec_volatile' operation, might cause a trap.  Targets can use
!      this hook to enhance precision of analysis for 'unspec' and
!      'unspec_volatile' operations.  You may call 'may_trap_p_1' to
       analyze inner elements of X in which case FLAGS should be passed
       along.
  
   -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL)
       The compiler invokes this hook whenever it changes its current
!      function context ('cfun').  You can define this function if the
       back end needs to perform any initialization or reset actions on a
       per-function basis.  For example, it may be used to implement
       function attributes that affect register usage or code generation
--- 43598,43628 ----
       pseudo register, it is often not necessary to actually allocate
       another register to this pseudo register, because the original hard
       register or a stack slot it has been saved into can be used.
!      ‘TARGET_ALLOCATE_INITIAL_VALUE’ is called at the start of register
       allocation once for each hard register that had its initial value
!      copied by using ‘get_func_hard_reg_initial_val’ or
!      ‘get_hard_reg_initial_val’.  Possible values are ‘NULL_RTX’, if you
!      don't want to do any special allocation, a ‘REG’ rtx--that would
       typically be the hard register itself, if it is known not to be
!      clobbered--or a ‘MEM’.  If you are returning a ‘MEM’, this is only
       a hint for the allocator; it might decide to use another register
!      anyways.  You may use ‘current_function_is_leaf’ or ‘REG_N_SETS’ in
       the hook to determine if the hard register in question will not be
!      clobbered.  The default value of this hook is ‘NULL’, which
       disables any special allocation.
  
   -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned
            FLAGS)
!      This target hook returns nonzero if X, an ‘unspec’ or
!      ‘unspec_volatile’ operation, might cause a trap.  Targets can use
!      this hook to enhance precision of analysis for ‘unspec’ and
!      ‘unspec_volatile’ operations.  You may call ‘may_trap_p_1’ to
       analyze inner elements of X in which case FLAGS should be passed
       along.
  
   -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL)
       The compiler invokes this hook whenever it changes its current
!      function context (‘cfun’).  You can define this function if the
       back end needs to perform any initialization or reset actions on a
       per-function basis.  For example, it may be used to implement
       function attributes that affect register usage or code generation
*************** Here are several miscellaneous parameter
*** 43632,43648 ****
       left a function context and is returning to processing at the top
       level.  The default hook function does nothing.
  
!      GCC sets 'cfun' to a dummy function context during initialization
       of some parts of the back end.  The hook function is not invoked in
       this situation; you need not worry about the hook being invoked
       recursively, or when the back end is in a partially-initialized
!      state.  'cfun' might be 'NULL' to indicate processing at top level,
       outside of any function scope.
  
   -- Macro: TARGET_OBJECT_SUFFIX
       Define this macro to be a C string representing the suffix for
       object files on your target machine.  If you do not define this
!      macro, GCC will use '.o' as the suffix for object files.
  
   -- Macro: TARGET_EXECUTABLE_SUFFIX
       Define this macro to be a C string representing the suffix to be
--- 43631,43647 ----
       left a function context and is returning to processing at the top
       level.  The default hook function does nothing.
  
!      GCC sets ‘cfun’ to a dummy function context during initialization
       of some parts of the back end.  The hook function is not invoked in
       this situation; you need not worry about the hook being invoked
       recursively, or when the back end is in a partially-initialized
!      state.  ‘cfun’ might be ‘NULL’ to indicate processing at top level,
       outside of any function scope.
  
   -- Macro: TARGET_OBJECT_SUFFIX
       Define this macro to be a C string representing the suffix for
       object files on your target machine.  If you do not define this
!      macro, GCC will use ‘.o’ as the suffix for object files.
  
   -- Macro: TARGET_EXECUTABLE_SUFFIX
       Define this macro to be a C string representing the suffix to be
*************** Here are several miscellaneous parameter
*** 43651,43664 ****
       suffix for executable files.
  
   -- Macro: COLLECT_EXPORT_LIST
!      If defined, 'collect2' will scan the individual object files
       specified on its command line and create an export list for the
       linker.  Define this macro for systems like AIX, where the linker
!      discards object files that are not referenced from 'main' and uses
       export lists.
  
   -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void)
!      This target hook returns 'true' past the point in which new jump
       instructions could be created.  On machines that require a register
       for every jump such as the SHmedia ISA of SH5, this point would
       typically be reload, so this target hook should be defined to a
--- 43650,43663 ----
       suffix for executable files.
  
   -- Macro: COLLECT_EXPORT_LIST
!      If defined, ‘collect2’ will scan the individual object files
       specified on its command line and create an export list for the
       linker.  Define this macro for systems like AIX, where the linker
!      discards object files that are not referenced from ‘main’ and uses
       export lists.
  
   -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void)
!      This target hook returns ‘true’ past the point in which new jump
       instructions could be created.  On machines that require a register
       for every jump such as the SHmedia ISA of SH5, this point would
       typically be reload, so this target hook should be defined to a
*************** Here are several miscellaneous parameter
*** 43680,43690 ****
            rtx_insn **GEN_SEQ, int CODE, tree OP0, tree OP1)
       This function prepares to emit a comparison insn for the first
       compare in a sequence of conditional comparisions.  It returns an
!      appropriate comparison with 'CC' for passing to 'gen_ccmp_next' or
!      'cbranch_optab'.  The insns to prepare the compare are saved in
       PREP_SEQ and the compare insns are saved in GEN_SEQ.  They will be
       emitted when all the compares in the conditional comparision are
!      generated without error.  CODE is the 'rtx_code' of the compare for
       OP0 and OP1.
  
   -- Target Hook: rtx TARGET_GEN_CCMP_NEXT (rtx_insn **PREP_SEQ, rtx_insn
--- 43679,43689 ----
            rtx_insn **GEN_SEQ, int CODE, tree OP0, tree OP1)
       This function prepares to emit a comparison insn for the first
       compare in a sequence of conditional comparisions.  It returns an
!      appropriate comparison with ‘CC’ for passing to ‘gen_ccmp_next’ or
!      ‘cbranch_optab’.  The insns to prepare the compare are saved in
       PREP_SEQ and the compare insns are saved in GEN_SEQ.  They will be
       emitted when all the compares in the conditional comparision are
!      generated without error.  CODE is the ‘rtx_code’ of the compare for
       OP0 and OP1.
  
   -- Target Hook: rtx TARGET_GEN_CCMP_NEXT (rtx_insn **PREP_SEQ, rtx_insn
*************** Here are several miscellaneous parameter
*** 43692,43707 ****
            BIT_CODE)
       This function prepares to emit a conditional comparison within a
       sequence of conditional comparisons.  It returns an appropriate
!      comparison with 'CC' for passing to 'gen_ccmp_next' or
!      'cbranch_optab'.  The insns to prepare the compare are saved in
       PREP_SEQ and the compare insns are saved in GEN_SEQ.  They will be
       emitted when all the compares in the conditional comparision are
       generated without error.  The PREV expression is the result of a
!      prior call to 'gen_ccmp_first' or 'gen_ccmp_next'.  It may return
!      'NULL' if the combination of PREV and this comparison is not
       supported, otherwise the result must be appropriate for passing to
!      'gen_ccmp_next' or 'cbranch_optab'.  CODE is the 'rtx_code' of the
!      compare for OP0 and OP1.  BIT_CODE is 'AND' or 'IOR', which is the
       op on the compares.
  
   -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL,
--- 43691,43706 ----
            BIT_CODE)
       This function prepares to emit a conditional comparison within a
       sequence of conditional comparisons.  It returns an appropriate
!      comparison with ‘CC’ for passing to ‘gen_ccmp_next’ or
!      ‘cbranch_optab’.  The insns to prepare the compare are saved in
       PREP_SEQ and the compare insns are saved in GEN_SEQ.  They will be
       emitted when all the compares in the conditional comparision are
       generated without error.  The PREV expression is the result of a
!      prior call to ‘gen_ccmp_first’ or ‘gen_ccmp_next’.  It may return
!      ‘NULL’ if the combination of PREV and this comparison is not
       supported, otherwise the result must be appropriate for passing to
!      ‘gen_ccmp_next’ or ‘cbranch_optab’.  CODE is the ‘rtx_code’ of the
!      compare for OP0 and OP1.  BIT_CODE is ‘AND’ or ‘IOR’, which is the
       op on the compares.
  
   -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL,
*************** Here are several miscellaneous parameter
*** 43720,43726 ****
       exponentiation by an integer constant inline.  When this value is
       defined, exponentiation requiring more than this number of
       multiplications is implemented by calling the system library's
!      'pow', 'powf' or 'powl' routines.  The default value places no
       upper bound on the multiplication count.
  
   -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char
--- 43719,43725 ----
       exponentiation by an integer constant inline.  When this value is
       defined, exponentiation requiring more than this number of
       multiplications is implemented by calling the system library's
!      ‘pow’, ‘powf’ or ‘powl’ routines.  The default value places no
       upper bound on the multiplication count.
  
   -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char
*************** Here are several miscellaneous parameter
*** 43742,43775 ****
       This target hook should register special include paths for the
       target.  The parameter PATH is the include to register.  On Darwin
       systems, this is used for Framework includes, which have semantics
!      that are different from '-I'.
  
   -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL)
!      This target macro returns 'true' if it is safe to use a local alias
!      for a virtual function FNDECL when constructing thunks, 'false'
!      otherwise.  By default, the macro returns 'true' for all functions,
!      if a target supports aliases (i.e. defines 'ASM_OUTPUT_DEF'),
!      'false' otherwise,
  
   -- Macro: TARGET_FORMAT_TYPES
       If defined, this macro is the name of a global variable containing
!      target-specific format checking information for the '-Wformat'
       option.  The default is to have no target-specific format checks.
  
   -- Macro: TARGET_N_FORMAT_TYPES
       If defined, this macro is the number of entries in
!      'TARGET_FORMAT_TYPES'.
  
   -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES
       If defined, this macro is the name of a global variable containing
!      target-specific format overrides for the '-Wformat' option.  The
       default is to have no target-specific format overrides.  If
!      defined, 'TARGET_FORMAT_TYPES' and
!      'TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT' must be defined, too.
  
   -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT
       If defined, this macro specifies the number of entries in
!      'TARGET_OVERRIDES_FORMAT_ATTRIBUTES'.
  
   -- Macro: TARGET_OVERRIDES_FORMAT_INIT
       If defined, this macro specifies the optional initialization
--- 43741,43774 ----
       This target hook should register special include paths for the
       target.  The parameter PATH is the include to register.  On Darwin
       systems, this is used for Framework includes, which have semantics
!      that are different from ‘-I’.
  
   -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL)
!      This target macro returns ‘true’ if it is safe to use a local alias
!      for a virtual function FNDECL when constructing thunks, ‘false’
!      otherwise.  By default, the macro returns ‘true’ for all functions,
!      if a target supports aliases (i.e. defines ‘ASM_OUTPUT_DEF’),
!      ‘false’ otherwise,
  
   -- Macro: TARGET_FORMAT_TYPES
       If defined, this macro is the name of a global variable containing
!      target-specific format checking information for the ‘-Wformat’
       option.  The default is to have no target-specific format checks.
  
   -- Macro: TARGET_N_FORMAT_TYPES
       If defined, this macro is the number of entries in
!      ‘TARGET_FORMAT_TYPES’.
  
   -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES
       If defined, this macro is the name of a global variable containing
!      target-specific format overrides for the ‘-Wformat’ option.  The
       default is to have no target-specific format overrides.  If
!      defined, ‘TARGET_FORMAT_TYPES’ and
!      ‘TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT’ must be defined, too.
  
   -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT
       If defined, this macro specifies the number of entries in
!      ‘TARGET_OVERRIDES_FORMAT_ATTRIBUTES’.
  
   -- Macro: TARGET_OVERRIDES_FORMAT_INIT
       If defined, this macro specifies the optional initialization
*************** Here are several miscellaneous parameter
*** 43785,43817 ****
   -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree
            FROMTYPE, const_tree TOTYPE)
       If defined, this macro returns the diagnostic message when it is
!      invalid to convert from FROMTYPE to TOTYPE, or 'NULL' if validity
       should be determined by the front end.
  
   -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP,
            const_tree TYPE)
       If defined, this macro returns the diagnostic message when it is
       invalid to apply operation OP (where unary plus is denoted by
!      'CONVERT_EXPR') to an operand of type TYPE, or 'NULL' if validity
       should be determined by the front end.
  
   -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP,
            const_tree TYPE1, const_tree TYPE2)
       If defined, this macro returns the diagnostic message when it is
       invalid to apply operation OP to operands of types TYPE1 and TYPE2,
!      or 'NULL' if validity should be determined by the front end.
  
   -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE)
       If defined, this target hook returns the type to which values of
       TYPE should be promoted when they appear in expressions, analogous
!      to the integer promotions, or 'NULL_TREE' to use the front end's
       normal promotion rules.  This hook is useful when there are
       target-specific types with special promotion rules.  This is
       currently used only by the C and C++ front ends.
  
   -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR)
       If defined, this hook returns the result of converting EXPR to
!      TYPE.  It should return the converted expression, or 'NULL_TREE' to
       apply the front end's normal conversion rules.  This hook is useful
       when there are target-specific types with special conversion rules.
       This is currently used only by the C and C++ front ends.
--- 43784,43816 ----
   -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree
            FROMTYPE, const_tree TOTYPE)
       If defined, this macro returns the diagnostic message when it is
!      invalid to convert from FROMTYPE to TOTYPE, or ‘NULL’ if validity
       should be determined by the front end.
  
   -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP,
            const_tree TYPE)
       If defined, this macro returns the diagnostic message when it is
       invalid to apply operation OP (where unary plus is denoted by
!      ‘CONVERT_EXPR’) to an operand of type TYPE, or ‘NULL’ if validity
       should be determined by the front end.
  
   -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP,
            const_tree TYPE1, const_tree TYPE2)
       If defined, this macro returns the diagnostic message when it is
       invalid to apply operation OP to operands of types TYPE1 and TYPE2,
!      or ‘NULL’ if validity should be determined by the front end.
  
   -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE)
       If defined, this target hook returns the type to which values of
       TYPE should be promoted when they appear in expressions, analogous
!      to the integer promotions, or ‘NULL_TREE’ to use the front end's
       normal promotion rules.  This hook is useful when there are
       target-specific types with special promotion rules.  This is
       currently used only by the C and C++ front ends.
  
   -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR)
       If defined, this hook returns the result of converting EXPR to
!      TYPE.  It should return the converted expression, or ‘NULL_TREE’ to
       apply the front end's normal conversion rules.  This hook is useful
       when there are target-specific types with special conversion rules.
       This is currently used only by the C and C++ front ends.
*************** Here are several miscellaneous parameter
*** 43824,43831 ****
       reports an error against LOC for invalid uses of TYPE.
  
       Calls to this hook should be made through the global function
!      'verify_type_context', which makes the SILENT_P parameter default
!      to false and also handles 'error_mark_node'.
  
       The default implementation always returns true.
  
--- 43823,43830 ----
       reports an error against LOC for invalid uses of TYPE.
  
       Calls to this hook should be made through the global function
!      ‘verify_type_context’, which makes the SILENT_P parameter default
!      to false and also handles ‘error_mark_node’.
  
       The default implementation always returns true.
  
*************** Here are several miscellaneous parameter
*** 43836,43844 ****
  
   -- Macro: LIBGCC2_UNWIND_ATTRIBUTE
       Define this macro if any target-specific attributes need to be
!      attached to the functions in 'libgcc' that provide low-level
       support for call stack unwinding.  It is used in declarations in
!      'unwind-generic.h' and the associated definitions of those
       functions.
  
   -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void)
--- 43835,43843 ----
  
   -- Macro: LIBGCC2_UNWIND_ATTRIBUTE
       Define this macro if any target-specific attributes need to be
!      attached to the functions in ‘libgcc’ that provide low-level
       support for call stack unwinding.  It is used in declarations in
!      ‘unwind-generic.h’ and the associated definitions of those
       functions.
  
   -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void)
*************** Here are several miscellaneous parameter
*** 43849,43855 ****
       This hook should return an rtx for Dynamic Realign Argument Pointer
       (DRAP) if a different argument pointer register is needed to access
       the function's argument list due to stack realignment.  Return
!      'NULL' if no DRAP is needed.
  
   -- Target Hook: HARD_REG_SET TARGET_ZERO_CALL_USED_REGS (HARD_REG_SET
            SELECTED_REGS)
--- 43848,43854 ----
       This hook should return an rtx for Dynamic Realign Argument Pointer
       (DRAP) if a different argument pointer register is needed to access
       the function's argument list due to stack realignment.  Return
!      ‘NULL’ if no DRAP is needed.
  
   -- Target Hook: HARD_REG_SET TARGET_ZERO_CALL_USED_REGS (HARD_REG_SET
            SELECTED_REGS)
*************** Here are several miscellaneous parameter
*** 43876,43882 ****
       arguments should be allocated to stack slots.  Normally, GCC
       allocates stacks slots for arguments when not optimizing in order
       to make debugging easier.  However, when a function is declared
!      with '__attribute__((naked))', there is no stack frame, and the
       compiler cannot safely move arguments from the registers in which
       they are passed to the stack.  Therefore, this hook should return
       true in general, but false for naked functions.  The default
--- 43875,43881 ----
       arguments should be allocated to stack slots.  Normally, GCC
       allocates stacks slots for arguments when not optimizing in order
       to make debugging easier.  However, when a function is declared
!      with ‘__attribute__((naked))’, there is no stack frame, and the
       compiler cannot safely move arguments from the registers in which
       they are passed to the stack.  Therefore, this hook should return
       true in general, but false for naked functions.  The default
*************** Here are several miscellaneous parameter
*** 43892,43902 ****
       anchor to the available expressions.  These are then queried when
       encountering new constants.  The anchors are computed by rounding
       the constant up and down to a multiple of the value of
!      'TARGET_CONST_ANCHOR'.  'TARGET_CONST_ANCHOR' should be the maximum
       positive value accepted by immediate-add plus one.  We currently
!      assume that the value of 'TARGET_CONST_ANCHOR' is a power of 2.
       For example, on MIPS, where add-immediate takes a 16-bit signed
!      value, 'TARGET_CONST_ANCHOR' is set to '0x8000'.  The default value
       is zero, which disables this optimization.
  
   -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void)
--- 43891,43901 ----
       anchor to the available expressions.  These are then queried when
       encountering new constants.  The anchors are computed by rounding
       the constant up and down to a multiple of the value of
!      ‘TARGET_CONST_ANCHOR’.  ‘TARGET_CONST_ANCHOR’ should be the maximum
       positive value accepted by immediate-add plus one.  We currently
!      assume that the value of ‘TARGET_CONST_ANCHOR’ is a power of 2.
       For example, on MIPS, where add-immediate takes a 16-bit signed
!      value, ‘TARGET_CONST_ANCHOR’ is set to ‘0x8000’.  The default value
       is zero, which disables this optimization.
  
   -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void)
*************** Here are several miscellaneous parameter
*** 43912,43918 ****
  
   -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
       This value should be set if the result written by
!      'atomic_test_and_set' is not exactly 1, i.e. the 'bool' 'true'.
  
   -- Target Hook: bool TARGET_HAS_IFUNC_P (void)
       It returns true if the target supports GNU indirect functions.  The
--- 43911,43917 ----
  
   -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
       This value should be set if the result written by
!      ‘atomic_test_and_set’ is not exactly 1, i.e. the ‘bool’ ‘true’.
  
   -- Target Hook: bool TARGET_HAS_IFUNC_P (void)
       It returns true if the target supports GNU indirect functions.  The
*************** Here are several miscellaneous parameter
*** 43935,43951 ****
       floating-point exceptions to raise exceptions corresponding to the
       arithmetic operation whose result was successfully stored in a
       compare-and-exchange sequence.  This requires code equivalent to
!      calls to 'feholdexcept', 'feclearexcept' and 'feupdateenv' to be
       generated at appropriate points in the compare-and-exchange
!      sequence.  This hook should set '*HOLD' to an expression equivalent
!      to the call to 'feholdexcept', '*CLEAR' to an expression equivalent
!      to the call to 'feclearexcept' and '*UPDATE' to an expression
!      equivalent to the call to 'feupdateenv'.  The three expressions are
!      'NULL_TREE' on entry to the hook and may be left as 'NULL_TREE' if
       no code is required in a particular place.  The default
!      implementation leaves all three expressions as 'NULL_TREE'.  The
!      '__atomic_feraiseexcept' function from 'libatomic' may be of use as
!      part of the code generated in '*UPDATE'.
  
   -- Target Hook: void TARGET_RECORD_OFFLOAD_SYMBOL (tree)
       Used when offloaded functions are seen in the compilation unit and
--- 43934,43950 ----
       floating-point exceptions to raise exceptions corresponding to the
       arithmetic operation whose result was successfully stored in a
       compare-and-exchange sequence.  This requires code equivalent to
!      calls to ‘feholdexcept’, ‘feclearexcept’ and ‘feupdateenv’ to be
       generated at appropriate points in the compare-and-exchange
!      sequence.  This hook should set ‘*HOLD’ to an expression equivalent
!      to the call to ‘feholdexcept’, ‘*CLEAR’ to an expression equivalent
!      to the call to ‘feclearexcept’ and ‘*UPDATE’ to an expression
!      equivalent to the call to ‘feupdateenv’.  The three expressions are
!      ‘NULL_TREE’ on entry to the hook and may be left as ‘NULL_TREE’ if
       no code is required in a particular place.  The default
!      implementation leaves all three expressions as ‘NULL_TREE’.  The
!      ‘__atomic_feraiseexcept’ function from ‘libatomic’ may be of use as
!      part of the code generated in ‘*UPDATE’.
  
   -- Target Hook: void TARGET_RECORD_OFFLOAD_SYMBOL (tree)
       Used when offloaded functions are seen in the compilation unit and
*************** Here are several miscellaneous parameter
*** 43955,44029 ****
   -- Target Hook: char * TARGET_OFFLOAD_OPTIONS (void)
       Used when writing out the list of options into an LTO file.  It
       should translate any relevant target-specific options (such as the
!      ABI in use) into one of the '-foffload' options that exist as a
       common interface to express such options.  It should return a
       string containing these options, separated by spaces, which the
       caller will free.
  
   -- Macro: TARGET_SUPPORTS_WIDE_INT
  
!      On older ports, large integers are stored in 'CONST_DOUBLE' rtl
!      objects.  Newer ports define 'TARGET_SUPPORTS_WIDE_INT' to be
       nonzero to indicate that large integers are stored in
!      'CONST_WIDE_INT' rtl objects.  The 'CONST_WIDE_INT' allows very
!      large integer constants to be represented.  'CONST_DOUBLE' is
!      limited to twice the size of the host's 'HOST_WIDE_INT'
       representation.
  
       Converting a port mostly requires looking for the places where
!      'CONST_DOUBLE's are used with 'VOIDmode' and replacing that code
!      with code that accesses 'CONST_WIDE_INT's.  '"grep -i
!      const_double"' at the port level gets you to 95% of the changes
       that need to be made.  There are a few places that require a deeper
       look.
  
!         * There is no equivalent to 'hval' and 'lval' for
!           'CONST_WIDE_INT's.  This would be difficult to express in the
            md language since there are a variable number of elements.
  
!           Most ports only check that 'hval' is either 0 or -1 to see if
            the value is small.  As mentioned above, this will no longer
!           be necessary since small constants are always 'CONST_INT'.  Of
            course there are still a few exceptions, the alpha's
            constraint used by the zap instruction certainly requires
            careful examination by C code.  However, all the current code
            does is pass the hval and lval to C code, so evolving the c
!           code to look at the 'CONST_WIDE_INT' is not really a large
            change.
  
!         * Because there is no standard template that ports use to
            materialize constants, there is likely to be some futzing that
            is unique to each port in this code.
  
!         * The rtx costs may have to be adjusted to properly account for
!           larger constants that are represented as 'CONST_WIDE_INT'.
  
       All and all it does not take long to convert ports that the
       maintainer is familiar with.
  
   -- Target Hook: bool TARGET_HAVE_SPECULATION_SAFE_VALUE (bool ACTIVE)
       This hook is used to determine the level of target support for
!      '__builtin_speculation_safe_value'.  If called with an argument of
       false, it returns true if the target has been modified to support
       this builtin.  If called with an argument of true, it returns true
       if the target requires active mitigation execution might be
       speculative.
  
       The default implementation returns false if the target does not
!      define a pattern named 'speculation_barrier'.  Else it returns true
       for the first case and whether the pattern is enabled for the
       current compilation for the second case.
  
       For targets that have no processors that can execute instructions
       speculatively an alternative implemenation of this hook is
       available: simply redefine this hook to
!      'speculation_safe_value_not_needed' along with your other target
       hooks.
  
   -- Target Hook: rtx TARGET_SPECULATION_SAFE_VALUE (machine_mode MODE,
            rtx RESULT, rtx VAL, rtx FAILVAL)
       This target hook can be used to generate a target-specific code
!      sequence that implements the '__builtin_speculation_safe_value'
       built-in function.  The function must always return VAL in RESULT
       in mode MODE when the cpu is not executing speculatively, but must
       never return that when speculating until it is known that the
--- 43954,44028 ----
   -- Target Hook: char * TARGET_OFFLOAD_OPTIONS (void)
       Used when writing out the list of options into an LTO file.  It
       should translate any relevant target-specific options (such as the
!      ABI in use) into one of the ‘-foffload’ options that exist as a
       common interface to express such options.  It should return a
       string containing these options, separated by spaces, which the
       caller will free.
  
   -- Macro: TARGET_SUPPORTS_WIDE_INT
  
!      On older ports, large integers are stored in ‘CONST_DOUBLE’ rtl
!      objects.  Newer ports define ‘TARGET_SUPPORTS_WIDE_INT’ to be
       nonzero to indicate that large integers are stored in
!      ‘CONST_WIDE_INT’ rtl objects.  The ‘CONST_WIDE_INT’ allows very
!      large integer constants to be represented.  ‘CONST_DOUBLE’ is
!      limited to twice the size of the host's ‘HOST_WIDE_INT’
       representation.
  
       Converting a port mostly requires looking for the places where
!      ‘CONST_DOUBLE’s are used with ‘VOIDmode’ and replacing that code
!      with code that accesses ‘CONST_WIDE_INT’s.  ‘"grep -i
!      const_double"’ at the port level gets you to 95% of the changes
       that need to be made.  There are a few places that require a deeper
       look.
  
!         • There is no equivalent to ‘hval’ and ‘lval’ for
!           ‘CONST_WIDE_INT’s.  This would be difficult to express in the
            md language since there are a variable number of elements.
  
!           Most ports only check that ‘hval’ is either 0 or -1 to see if
            the value is small.  As mentioned above, this will no longer
!           be necessary since small constants are always ‘CONST_INT’.  Of
            course there are still a few exceptions, the alpha's
            constraint used by the zap instruction certainly requires
            careful examination by C code.  However, all the current code
            does is pass the hval and lval to C code, so evolving the c
!           code to look at the ‘CONST_WIDE_INT’ is not really a large
            change.
  
!         • Because there is no standard template that ports use to
            materialize constants, there is likely to be some futzing that
            is unique to each port in this code.
  
!         • The rtx costs may have to be adjusted to properly account for
!           larger constants that are represented as ‘CONST_WIDE_INT’.
  
       All and all it does not take long to convert ports that the
       maintainer is familiar with.
  
   -- Target Hook: bool TARGET_HAVE_SPECULATION_SAFE_VALUE (bool ACTIVE)
       This hook is used to determine the level of target support for
!      ‘__builtin_speculation_safe_value’.  If called with an argument of
       false, it returns true if the target has been modified to support
       this builtin.  If called with an argument of true, it returns true
       if the target requires active mitigation execution might be
       speculative.
  
       The default implementation returns false if the target does not
!      define a pattern named ‘speculation_barrier’.  Else it returns true
       for the first case and whether the pattern is enabled for the
       current compilation for the second case.
  
       For targets that have no processors that can execute instructions
       speculatively an alternative implemenation of this hook is
       available: simply redefine this hook to
!      ‘speculation_safe_value_not_needed’ along with your other target
       hooks.
  
   -- Target Hook: rtx TARGET_SPECULATION_SAFE_VALUE (machine_mode MODE,
            rtx RESULT, rtx VAL, rtx FAILVAL)
       This target hook can be used to generate a target-specific code
!      sequence that implements the ‘__builtin_speculation_safe_value’
       built-in function.  The function must always return VAL in RESULT
       in mode MODE when the cpu is not executing speculatively, but must
       never return that when speculating until it is known that the
*************** Here are several miscellaneous parameter
*** 44036,44053 ****
       must be unwound at a later time.
  
       The default implementation simply copies VAL to RESULT and emits a
!      'speculation_barrier' instruction if that is defined.
  
   -- Target Hook: void TARGET_RUN_TARGET_SELFTESTS (void)
       If selftests are enabled, run any selftests for this target.
  
   -- Target Hook: bool TARGET_MEMTAG_CAN_TAG_ADDRESSES ()
       True if the backend architecture naturally supports ignoring some
!      region of pointers.  This feature means that '-fsanitize=hwaddress'
       can work.
  
       At preset, this feature does not support address spaces.  It also
!      requires 'Pmode' to be the same as 'ptr_mode'.
  
   -- Target Hook: uint8_t TARGET_MEMTAG_TAG_SIZE ()
       Return the size of a tag (in bits) for this platform.
--- 44035,44052 ----
       must be unwound at a later time.
  
       The default implementation simply copies VAL to RESULT and emits a
!      ‘speculation_barrier’ instruction if that is defined.
  
   -- Target Hook: void TARGET_RUN_TARGET_SELFTESTS (void)
       If selftests are enabled, run any selftests for this target.
  
   -- Target Hook: bool TARGET_MEMTAG_CAN_TAG_ADDRESSES ()
       True if the backend architecture naturally supports ignoring some
!      region of pointers.  This feature means that ‘-fsanitize=hwaddress’
       can work.
  
       At preset, this feature does not support address spaces.  It also
!      requires ‘Pmode’ to be the same as ‘ptr_mode’.
  
   -- Target Hook: uint8_t TARGET_MEMTAG_TAG_SIZE ()
       Return the size of a tag (in bits) for this platform.
*************** Here are several miscellaneous parameter
*** 44078,44084 ****
       Return an RTX that represents the result of adding ADDR_OFFSET to
       the address in pointer BASE and TAG_OFFSET to the tag in pointer
       BASE.  The resulting RTX must either be a valid memory address or
!      be able to get put into an operand with 'force_operand'.
  
       Unlike other memtag hooks, this must return an expression and not
       emit any RTL.
--- 44077,44083 ----
       Return an RTX that represents the result of adding ADDR_OFFSET to
       the address in pointer BASE and TAG_OFFSET to the tag in pointer
       BASE.  The resulting RTX must either be a valid memory address or
!      be able to get put into an operand with ‘force_operand’.
  
       Unlike other memtag hooks, this must return an expression and not
       emit any RTL.
*************** Here are several miscellaneous parameter
*** 44108,44121 ****
       The default value is 64, if the type size of long long is greater
       than 32, otherwise the default value is 32.  A 64-bit type is
       recommended to avoid overflows of the counters.  If the
!      '-fprofile-update=atomic' is used, then the counters are
       incremented using atomic operations.  Targets not supporting 64-bit
       atomic operations may override the default value and request a
       32-bit type.
  
   -- Target Hook: bool TARGET_HAVE_SHADOW_CALL_STACK
       This value is true if the target platform supports
!      '-fsanitize=shadow-call-stack'.  The default value is false.
  
  
  File: gccint.info,  Node: Host Config,  Next: Fragments,  Prev: Target Macros,  Up: Top
--- 44107,44120 ----
       The default value is 64, if the type size of long long is greater
       than 32, otherwise the default value is 32.  A 64-bit type is
       recommended to avoid overflows of the counters.  If the
!      ‘-fprofile-update=atomic’ is used, then the counters are
       incremented using atomic operations.  Targets not supporting 64-bit
       atomic operations may override the default value and request a
       32-bit type.
  
   -- Target Hook: bool TARGET_HAVE_SHADOW_CALL_STACK
       This value is true if the target platform supports
!      ‘-fsanitize=shadow-call-stack’.  The default value is false.
  
  
  File: gccint.info,  Node: Host Config,  Next: Fragments,  Prev: Target Macros,  Up: Top
*************** File: gccint.info,  Node: Host Config,
*** 44124,44140 ****
  *********************
  
  Most details about the machine and system on which the compiler is
! actually running are detected by the 'configure' script.  Some things
! are impossible for 'configure' to detect; these are described in two
! ways, either by macros defined in a file named 'xm-MACHINE.h' or by hook
  functions in the file specified by the OUT_HOST_HOOK_OBJ variable in
! 'config.gcc'.  (The intention is that very few hosts will need a header
  file but nearly every fully supported host will need to override some
  hooks.)
  
   If you need to define only a few macros, and they have simple
! definitions, consider using the 'xm_defines' variable in your
! 'config.gcc' entry instead of creating a host configuration header.
  *Note System Config::.
  
  * Menu:
--- 44123,44139 ----
  *********************
  
  Most details about the machine and system on which the compiler is
! actually running are detected by the ‘configure’ script.  Some things
! are impossible for ‘configure’ to detect; these are described in two
! ways, either by macros defined in a file named ‘xm-MACHINE.h’ or by hook
  functions in the file specified by the OUT_HOST_HOOK_OBJ variable in
! ‘config.gcc’.  (The intention is that very few hosts will need a header
  file but nearly every fully supported host will need to override some
  hooks.)
  
   If you need to define only a few macros, and they have simple
! definitions, consider using the ‘xm_defines’ variable in your
! ‘config.gcc’ entry instead of creating a host configuration header.
  *Note System Config::.
  
  * Menu:
*************** File: gccint.info,  Node: Host Common,
*** 44152,44158 ****
  Some things are just not portable, even between similar operating
  systems, and are too difficult for autoconf to detect.  They get
  implemented using hook functions in the file specified by the
! HOST_HOOK_OBJ variable in 'config.gcc'.
  
   -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void)
       This host hook is used to set up handling for extra signals.  The
--- 44151,44157 ----
  Some things are just not portable, even between similar operating
  systems, and are too difficult for autoconf to detect.  They get
  implemented using hook functions in the file specified by the
! HOST_HOOK_OBJ variable in ‘config.gcc’.
  
   -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void)
       This host hook is used to set up handling for extra signals.  The
*************** HOST_HOOK_OBJ variable in 'config.gcc'.
*** 44164,44170 ****
       be free in some subsequent invocation of the compiler.  We intend
       to load the PCH data at this address such that the data need not be
       relocated.  The area should be able to hold SIZE bytes.  If the
!      host uses 'mmap', FD is an open file descriptor that can be used
       for probing.
  
   -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t
--- 44163,44169 ----
       be free in some subsequent invocation of the compiler.  We intend
       to load the PCH data at this address such that the data need not be
       relocated.  The area should be able to hold SIZE bytes.  If the
!      host uses ‘mmap’, FD is an open file descriptor that can be used
       for probing.
  
   -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t
*************** HOST_HOOK_OBJ variable in 'config.gcc'.
*** 44172,44178 ****
       This host hook is called when a PCH file is about to be loaded.  We
       want to load SIZE bytes from FD at OFFSET into memory at ADDRESS.
       The given address will be the result of a previous invocation of
!      'HOST_HOOKS_GT_PCH_GET_ADDRESS'.  Return -1 if we couldn't allocate
       SIZE bytes at ADDRESS.  Return 0 if the memory is allocated but the
       data is not loaded.  Return 1 if the hook has performed everything.
  
--- 44171,44177 ----
       This host hook is called when a PCH file is about to be loaded.  We
       want to load SIZE bytes from FD at OFFSET into memory at ADDRESS.
       The given address will be the result of a previous invocation of
!      ‘HOST_HOOKS_GT_PCH_GET_ADDRESS’.  Return −1 if we couldn't allocate
       SIZE bytes at ADDRESS.  Return 0 if the memory is allocated but the
       data is not loaded.  Return 1 if the hook has performed everything.
  
*************** HOST_HOOK_OBJ variable in 'config.gcc'.
*** 44182,44188 ****
       which case all reserved address space should be freed.
  
       Do not try to handle values of ADDRESS that could not have been
!      returned by this executable; just return -1.  Such values usually
       indicate an out-of-date PCH file (built by some other GCC
       executable), and such a PCH file won't work.
  
--- 44181,44187 ----
       which case all reserved address space should be freed.
  
       Do not try to handle values of ADDRESS that could not have been
!      returned by this executable; just return −1.  Such values usually
       indicate an out-of-date PCH file (built by some other GCC
       executable), and such a PCH file won't work.
  
*************** File: gccint.info,  Node: Filesystem,  N
*** 44201,44257 ****
  GCC needs to know a number of things about the semantics of the host
  machine's filesystem.  Filesystems with Unix and MS-DOS semantics are
  automatically detected.  For other systems, you can define the following
! macros in 'xm-MACHINE.h'.
  
! 'HAVE_DOS_BASED_FILE_SYSTEM'
!      This macro is automatically defined by 'system.h' if the host file
       system obeys the semantics defined by MS-DOS instead of Unix.  DOS
       file systems are case insensitive, file specifications may begin
!      with a drive letter, and both forward slash and backslash ('/' and
!      '\') are directory separators.
  
! 'DIR_SEPARATOR'
! 'DIR_SEPARATOR_2'
       If defined, these macros expand to character constants specifying
       separators for directory names within a file specification.
!      'system.h' will automatically give them appropriate values on Unix
       and MS-DOS file systems.  If your file system is neither of these,
!      define one or both appropriately in 'xm-MACHINE.h'.
  
       However, operating systems like VMS, where constructing a pathname
       is more complicated than just stringing together directory names
       separated by a special character, should not define either of these
       macros.
  
! 'PATH_SEPARATOR'
       If defined, this macro should expand to a character constant
       specifying the separator for elements of search paths.  The default
!      value is a colon (':').  DOS-based systems usually, but not always,
!      use semicolon (';').
  
! 'VMS'
       Define this macro if the host system is VMS.
  
! 'HOST_OBJECT_SUFFIX'
       Define this macro to be a C string representing the suffix for
       object files on your host machine.  If you do not define this
!      macro, GCC will use '.o' as the suffix for object files.
  
! 'HOST_EXECUTABLE_SUFFIX'
       Define this macro to be a C string representing the suffix for
       executable files on your host machine.  If you do not define this
       macro, GCC will use the null string as the suffix for executable
       files.
  
! 'HOST_BIT_BUCKET'
       A pathname defined by the host operating system, which can be
       opened as a file and written to, but all the information written is
!      discarded.  This is commonly known as a "bit bucket" or "null
!      device".  If you do not define this macro, GCC will use '/dev/null'
       as the bit bucket.  If the host does not support a bit bucket,
       define this macro to an invalid filename.
  
! 'UPDATE_PATH_HOST_CANONICALIZE (PATH)'
       If defined, a C statement (sans semicolon) that performs
       host-dependent canonicalization when a path used in a compilation
       driver or preprocessor is canonicalized.  PATH is a malloc-ed path
--- 44200,44256 ----
  GCC needs to know a number of things about the semantics of the host
  machine's filesystem.  Filesystems with Unix and MS-DOS semantics are
  automatically detected.  For other systems, you can define the following
! macros in ‘xm-MACHINE.h’.
  
! ‘HAVE_DOS_BASED_FILE_SYSTEM’
!      This macro is automatically defined by ‘system.h’ if the host file
       system obeys the semantics defined by MS-DOS instead of Unix.  DOS
       file systems are case insensitive, file specifications may begin
!      with a drive letter, and both forward slash and backslash (‘/’ and
!      ‘\’) are directory separators.
  
! ‘DIR_SEPARATOR’
! ‘DIR_SEPARATOR_2’
       If defined, these macros expand to character constants specifying
       separators for directory names within a file specification.
!      ‘system.h’ will automatically give them appropriate values on Unix
       and MS-DOS file systems.  If your file system is neither of these,
!      define one or both appropriately in ‘xm-MACHINE.h’.
  
       However, operating systems like VMS, where constructing a pathname
       is more complicated than just stringing together directory names
       separated by a special character, should not define either of these
       macros.
  
! ‘PATH_SEPARATOR’
       If defined, this macro should expand to a character constant
       specifying the separator for elements of search paths.  The default
!      value is a colon (‘:’).  DOS-based systems usually, but not always,
!      use semicolon (‘;’).
  
! ‘VMS’
       Define this macro if the host system is VMS.
  
! ‘HOST_OBJECT_SUFFIX’
       Define this macro to be a C string representing the suffix for
       object files on your host machine.  If you do not define this
!      macro, GCC will use ‘.o’ as the suffix for object files.
  
! ‘HOST_EXECUTABLE_SUFFIX’
       Define this macro to be a C string representing the suffix for
       executable files on your host machine.  If you do not define this
       macro, GCC will use the null string as the suffix for executable
       files.
  
! ‘HOST_BIT_BUCKET’
       A pathname defined by the host operating system, which can be
       opened as a file and written to, but all the information written is
!      discarded.  This is commonly known as a “bit bucket” or “null
!      device”.  If you do not define this macro, GCC will use ‘/dev/null’
       as the bit bucket.  If the host does not support a bit bucket,
       define this macro to an invalid filename.
  
! ‘UPDATE_PATH_HOST_CANONICALIZE (PATH)’
       If defined, a C statement (sans semicolon) that performs
       host-dependent canonicalization when a path used in a compilation
       driver or preprocessor is canonicalized.  PATH is a malloc-ed path
*************** macros in 'xm-MACHINE.h'.
*** 44259,44277 ****
       into a different buffer, the old path should be freed and the new
       buffer should have been allocated with malloc.
  
! 'DUMPFILE_FORMAT'
       Define this macro to be a C string representing the format to use
       for constructing the index part of debugging dump file names.  The
       resultant string must fit in fifteen bytes.  The full filename will
       be the concatenation of: the prefix of the assembler file name, the
       string resulting from applying this format to an index number, and
!      a string unique to each dump file kind, e.g. 'rtl'.
  
!      If you do not define this macro, GCC will use '.%02d.'.  You should
       define this macro if using the default will create an invalid file
       name.
  
! 'DELETE_IF_ORDINARY'
       Define this macro to be a C statement (sans semicolon) that
       performs host-dependent removal of ordinary temp files in the
       compilation driver.
--- 44258,44276 ----
       into a different buffer, the old path should be freed and the new
       buffer should have been allocated with malloc.
  
! ‘DUMPFILE_FORMAT’
       Define this macro to be a C string representing the format to use
       for constructing the index part of debugging dump file names.  The
       resultant string must fit in fifteen bytes.  The full filename will
       be the concatenation of: the prefix of the assembler file name, the
       string resulting from applying this format to an index number, and
!      a string unique to each dump file kind, e.g. ‘rtl’.
  
!      If you do not define this macro, GCC will use ‘.%02d.’.  You should
       define this macro if using the default will create an invalid file
       name.
  
! ‘DELETE_IF_ORDINARY’
       Define this macro to be a C statement (sans semicolon) that
       performs host-dependent removal of ordinary temp files in the
       compilation driver.
*************** macros in 'xm-MACHINE.h'.
*** 44281,44287 ****
       reliably remove the temp file as, for example, on VMS which allows
       multiple versions of a file.
  
! 'HOST_LACKS_INODE_NUMBERS'
       Define this macro if the host filesystem does not report meaningful
       inode numbers in struct stat.
  
--- 44280,44286 ----
       reliably remove the temp file as, for example, on VMS which allows
       multiple versions of a file.
  
! ‘HOST_LACKS_INODE_NUMBERS’
       Define this macro if the host filesystem does not report meaningful
       inode numbers in struct stat.
  
*************** File: gccint.info,  Node: Host Misc,  Pr
*** 44291,44347 ****
  19.3 Host Misc
  ==============
  
! 'FATAL_EXIT_CODE'
       A C expression for the status code to be returned when the compiler
       exits after serious errors.  The default is the system-provided
!      macro 'EXIT_FAILURE', or '1' if the system doesn't define that
       macro.  Define this macro only if these defaults are incorrect.
  
! 'SUCCESS_EXIT_CODE'
       A C expression for the status code to be returned when the compiler
       exits without serious errors.  (Warnings are not serious errors.)
!      The default is the system-provided macro 'EXIT_SUCCESS', or '0' if
       the system doesn't define that macro.  Define this macro only if
       these defaults are incorrect.
  
! 'USE_C_ALLOCA'
       Define this macro if GCC should use the C implementation of
!      'alloca' provided by 'libiberty.a'.  This only affects how some
       parts of the compiler itself allocate memory.  It does not change
       code generation.
  
!      When GCC is built with a compiler other than itself, the C 'alloca'
       is always used.  This is because most other implementations have
       serious bugs.  You should define this macro only on a system where
!      no stack-based 'alloca' can possibly work.  For instance, if a
       system has a small limit on the size of the stack, GCC's builtin
!      'alloca' will not work reliably.
  
! 'COLLECT2_HOST_INITIALIZATION'
       If defined, a C statement (sans semicolon) that performs
!      host-dependent initialization when 'collect2' is being initialized.
  
! 'GCC_DRIVER_HOST_INITIALIZATION'
       If defined, a C statement (sans semicolon) that performs
       host-dependent initialization when a compilation driver is being
       initialized.
  
! 'HOST_LONG_LONG_FORMAT'
!      If defined, the string used to indicate an argument of type 'long
!      long' to functions like 'printf'.  The default value is '"ll"'.
  
! 'HOST_LONG_FORMAT'
!      If defined, the string used to indicate an argument of type 'long'
!      to functions like 'printf'.  The default value is '"l"'.
  
! 'HOST_PTR_PRINTF'
!      If defined, the string used to indicate an argument of type 'void
!      *' to functions like 'printf'.  The default value is '"%p"'.
  
!  In addition, if 'configure' generates an incorrect definition of any of
! the macros in 'auto-host.h', you can override that definition in a host
  configuration header.  If you need to do this, first see if it is
! possible to fix 'configure'.
  
  
  File: gccint.info,  Node: Fragments,  Next: Collect2,  Prev: Host Config,  Up: Top
--- 44290,44346 ----
  19.3 Host Misc
  ==============
  
! ‘FATAL_EXIT_CODE’
       A C expression for the status code to be returned when the compiler
       exits after serious errors.  The default is the system-provided
!      macro ‘EXIT_FAILURE’, or ‘1’ if the system doesn't define that
       macro.  Define this macro only if these defaults are incorrect.
  
! ‘SUCCESS_EXIT_CODE’
       A C expression for the status code to be returned when the compiler
       exits without serious errors.  (Warnings are not serious errors.)
!      The default is the system-provided macro ‘EXIT_SUCCESS’, or ‘0’ if
       the system doesn't define that macro.  Define this macro only if
       these defaults are incorrect.
  
! ‘USE_C_ALLOCA’
       Define this macro if GCC should use the C implementation of
!      ‘alloca’ provided by ‘libiberty.a’.  This only affects how some
       parts of the compiler itself allocate memory.  It does not change
       code generation.
  
!      When GCC is built with a compiler other than itself, the C ‘alloca’
       is always used.  This is because most other implementations have
       serious bugs.  You should define this macro only on a system where
!      no stack-based ‘alloca’ can possibly work.  For instance, if a
       system has a small limit on the size of the stack, GCC's builtin
!      ‘alloca’ will not work reliably.
  
! ‘COLLECT2_HOST_INITIALIZATION’
       If defined, a C statement (sans semicolon) that performs
!      host-dependent initialization when ‘collect2’ is being initialized.
  
! ‘GCC_DRIVER_HOST_INITIALIZATION’
       If defined, a C statement (sans semicolon) that performs
       host-dependent initialization when a compilation driver is being
       initialized.
  
! ‘HOST_LONG_LONG_FORMAT’
!      If defined, the string used to indicate an argument of type ‘long
!      long’ to functions like ‘printf’.  The default value is ‘"ll"’.
  
! ‘HOST_LONG_FORMAT’
!      If defined, the string used to indicate an argument of type ‘long’
!      to functions like ‘printf’.  The default value is ‘"l"’.
  
! ‘HOST_PTR_PRINTF’
!      If defined, the string used to indicate an argument of type ‘void
!      *’ to functions like ‘printf’.  The default value is ‘"%p"’.
  
!  In addition, if ‘configure’ generates an incorrect definition of any of
! the macros in ‘auto-host.h’, you can override that definition in a host
  configuration header.  If you need to do this, first see if it is
! possible to fix ‘configure’.
  
  
  File: gccint.info,  Node: Fragments,  Next: Collect2,  Prev: Host Config,  Up: Top
*************** File: gccint.info,  Node: Fragments,  Ne
*** 44349,44376 ****
  20 Makefile Fragments
  *********************
  
! When you configure GCC using the 'configure' script, it will construct
! the file 'Makefile' from the template file 'Makefile.in'.  When it does
! this, it can incorporate makefile fragments from the 'config' directory.
  These are used to set Makefile parameters that are not amenable to being
  calculated by autoconf.  The list of fragments to incorporate is set by
! 'config.gcc' (and occasionally 'config.build' and 'config.host'); *Note
  System Config::.
  
!  Fragments are named either 't-TARGET' or 'x-HOST', depending on whether
  they are relevant to configuring GCC to produce code for a particular
  target, or to configuring GCC to run on a particular host.  Here TARGET
  and HOST are mnemonics which usually have some relationship to the
  canonical system name, but no formal connection.
  
   If these files do not exist, it means nothing needs to be added for a
! given target or host.  Most targets need a few 't-TARGET' fragments, but
! needing 'x-HOST' fragments is rare.
  
  * Menu:
  
! * Target Fragment:: Writing 't-TARGET' files.
! * Host Fragment::   Writing 'x-HOST' files.
  
  
  File: gccint.info,  Node: Target Fragment,  Next: Host Fragment,  Up: Fragments
--- 44348,44375 ----
  20 Makefile Fragments
  *********************
  
! When you configure GCC using the ‘configure’ script, it will construct
! the file ‘Makefile’ from the template file ‘Makefile.in’.  When it does
! this, it can incorporate makefile fragments from the ‘config’ directory.
  These are used to set Makefile parameters that are not amenable to being
  calculated by autoconf.  The list of fragments to incorporate is set by
! ‘config.gcc’ (and occasionally ‘config.build’ and ‘config.host’); *Note
  System Config::.
  
!  Fragments are named either ‘t-TARGET’ or ‘x-HOST’, depending on whether
  they are relevant to configuring GCC to produce code for a particular
  target, or to configuring GCC to run on a particular host.  Here TARGET
  and HOST are mnemonics which usually have some relationship to the
  canonical system name, but no formal connection.
  
   If these files do not exist, it means nothing needs to be added for a
! given target or host.  Most targets need a few ‘t-TARGET’ fragments, but
! needing ‘x-HOST’ fragments is rare.
  
  * Menu:
  
! * Target Fragment:: Writing ‘t-TARGET’ files.
! * Host Fragment::   Writing ‘x-HOST’ files.
  
  
  File: gccint.info,  Node: Target Fragment,  Next: Host Fragment,  Up: Fragments
*************** File: gccint.info,  Node: Target Fragmen
*** 44380,44551 ****
  
  Target makefile fragments can set these Makefile variables.
  
! 'LIBGCC2_CFLAGS'
!      Compiler flags to use when compiling 'libgcc2.c'.
  
! 'LIB2FUNCS_EXTRA'
       A list of source file names to be compiled or assembled and
!      inserted into 'libgcc.a'.
  
! 'CRTSTUFF_T_CFLAGS'
!      Special flags used when compiling 'crtstuff.c'.  *Note
       Initialization::.
  
! 'CRTSTUFF_T_CFLAGS_S'
!      Special flags used when compiling 'crtstuff.c' for shared linking.
!      Used if you use 'crtbeginS.o' and 'crtendS.o' in 'EXTRA-PARTS'.
       *Note Initialization::.
  
! 'MULTILIB_OPTIONS'
       For some targets, invoking GCC in different ways produces objects
       that cannot be linked together.  For example, for some targets GCC
       produces both big and little endian code.  For these targets, you
!      must arrange for multiple versions of 'libgcc.a' to be compiled,
       one for each set of incompatible options.  When GCC invokes the
!      linker, it arranges to link in the right version of 'libgcc.a',
       based on the command line options used.
  
!      The 'MULTILIB_OPTIONS' macro lists the set of options for which
!      special versions of 'libgcc.a' must be built.  Write options that
       are mutually incompatible side by side, separated by a slash.
       Write options that may be used together separated by a space.  The
       build procedure will build all combinations of compatible options.
  
!      For example, if you set 'MULTILIB_OPTIONS' to 'm68000/m68020
!      msoft-float', 'Makefile' will build special versions of 'libgcc.a'
!      using the following sets of options: '-m68000', '-m68020',
!      '-msoft-float', '-m68000 -msoft-float', and '-m68020 -msoft-float'.
  
! 'MULTILIB_DIRNAMES'
!      If 'MULTILIB_OPTIONS' is used, this variable specifies the
       directory names that should be used to hold the various libraries.
!      Write one element in 'MULTILIB_DIRNAMES' for each element in
!      'MULTILIB_OPTIONS'.  If 'MULTILIB_DIRNAMES' is not used, the
!      default value will be 'MULTILIB_OPTIONS', with all slashes treated
       as spaces.
  
!      'MULTILIB_DIRNAMES' describes the multilib directories using GCC
       conventions and is applied to directories that are part of the GCC
       installation.  When multilib-enabled, the compiler will add a
       subdirectory of the form PREFIX/MULTILIB before each directory in
       the search path for libraries and crt files.
  
!      For example, if 'MULTILIB_OPTIONS' is set to 'm68000/m68020
!      msoft-float', then the default value of 'MULTILIB_DIRNAMES' is
!      'm68000 m68020 msoft-float'.  You may specify a different value if
       you desire a different set of directory names.
  
! 'MULTILIB_MATCHES'
       Sometimes the same option may be written in two different ways.  If
!      an option is listed in 'MULTILIB_OPTIONS', GCC needs to know about
!      any synonyms.  In that case, set 'MULTILIB_MATCHES' to a list of
!      items of the form 'option=option' to describe all relevant
!      synonyms.  For example, 'm68000=mc68000 m68020=mc68020'.
  
! 'MULTILIB_EXCEPTIONS'
!      Sometimes when there are multiple sets of 'MULTILIB_OPTIONS' being
       specified, there are combinations that should not be built.  In
!      that case, set 'MULTILIB_EXCEPTIONS' to be all of the switch
       exceptions in shell case syntax that should not be built.
  
       For example the ARM processor cannot execute both hardware floating
       point instructions and the reduced size THUMB instructions at the
       same time, so there is no need to build libraries with both of
!      these options enabled.  Therefore 'MULTILIB_EXCEPTIONS' is set to:
            *mthumb/*mhard-float*
  
! 'MULTILIB_REQUIRED'
       Sometimes when there are only a few combinations are required, it
!      would be a big effort to come up with a 'MULTILIB_EXCEPTIONS' list
       to cover all undesired ones.  In such a case, just listing all the
!      required combinations in 'MULTILIB_REQUIRED' would be more
       straightforward.
  
!      The way to specify the entries in 'MULTILIB_REQUIRED' is same with
!      the way used for 'MULTILIB_EXCEPTIONS', only this time what are
       required will be specified.  Suppose there are multiple sets of
!      'MULTILIB_OPTIONS' and only two combinations are required, one for
       ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU,
!      the 'MULTILIB_REQUIRED' can be set to:
            MULTILIB_REQUIRED =  mthumb/march=armv7-m
            MULTILIB_REQUIRED += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16
  
!      The 'MULTILIB_REQUIRED' can be used together with
!      'MULTILIB_EXCEPTIONS'.  The option combinations generated from
!      'MULTILIB_OPTIONS' will be filtered by 'MULTILIB_EXCEPTIONS' and
!      then by 'MULTILIB_REQUIRED'.
  
! 'MULTILIB_REUSE'
       Sometimes it is desirable to reuse one existing multilib for
       different sets of options.  Such kind of reuse can minimize the
       number of multilib variants.  And for some targets it is better to
       reuse an existing multilib than to fall back to default multilib
       when there is no corresponding multilib.  This can be done by
!      adding reuse rules to 'MULTILIB_REUSE'.
  
       A reuse rule is comprised of two parts connected by equality sign.
       The left part is the option set used to build multilib and the
       right part is the option set that will reuse this multilib.  Both
!      parts should only use options specified in 'MULTILIB_OPTIONS' and
       the equality signs found in options name should be replaced with
       periods.  An explicit period in the rule can be escaped by
       preceding it with a backslash.  The order of options in the left
       part matters and should be same with those specified in
!      'MULTILIB_REQUIRED' or aligned with the order in
!      'MULTILIB_OPTIONS'.  There is no such limitation for options in the
       right part as we don't build multilib from them.
  
!      'MULTILIB_REUSE' is different from 'MULTILIB_MATCHES' in that it
       sets up relations between two option sets rather than two options.
       Here is an example to demo how we reuse libraries built in Thumb
       mode for applications built in ARM mode:
            MULTILIB_REUSE = mthumb/march.armv7-r=marm/march.armv7-r
  
!      Before the advent of 'MULTILIB_REUSE', GCC select multilib by
       comparing command line options with options used to build multilib.
!      The 'MULTILIB_REUSE' is complementary to that way.  Only when the
       original comparison matches nothing it will work to see if it is OK
       to reuse some existing multilib.
  
! 'MULTILIB_EXTRA_OPTS'
       Sometimes it is desirable that when building multiple versions of
!      'libgcc.a' certain options should always be passed on to the
!      compiler.  In that case, set 'MULTILIB_EXTRA_OPTS' to be the list
       of options to be used for all builds.  If you set this, you should
!      probably set 'CRTSTUFF_T_CFLAGS' to a dash followed by it.
  
! 'MULTILIB_OSDIRNAMES'
!      If 'MULTILIB_OPTIONS' is used, this variable specifies a list of
       subdirectory names, that are used to modify the search path
!      depending on the chosen multilib.  Unlike 'MULTILIB_DIRNAMES',
!      'MULTILIB_OSDIRNAMES' describes the multilib directories using
       operating systems conventions, and is applied to the directories
!      such as 'lib' or those in the 'LIBRARY_PATH' environment variable.
!      The format is either the same as of 'MULTILIB_DIRNAMES', or a set
!      of mappings.  When it is the same as 'MULTILIB_DIRNAMES', it
       describes the multilib directories using operating system
       conventions, rather than GCC conventions.  When it is a set of
       mappings of the form GCCDIR=OSDIR, the left side gives the GCC
       convention and the right gives the equivalent OS defined location.
!      If the OSDIR part begins with a '!', GCC will not search in the
       non-multilib directory and use exclusively the multilib directory.
       Otherwise, the compiler will examine the search path for libraries
       and crt files twice; the first time it will add MULTILIB to each
       directory in the search path, the second it will not.
  
       For configurations that support both multilib and multiarch,
!      'MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus
!      subsuming 'MULTIARCH_DIRNAME'.  The multiarch name is appended to
       each directory name, separated by a colon (e.g.
!      '../lib32:i386-linux-gnu').
  
       Each multiarch subdirectory will be searched before the
       corresponding OS multilib directory, for example
!      '/lib/i386-linux-gnu' before '/lib/../lib32'.  The multiarch name
       will also be used to modify the system header search path, as
!      explained for 'MULTIARCH_DIRNAME'.
  
! 'MULTIARCH_DIRNAME'
       This variable specifies the multiarch name for configurations that
       are multiarch-enabled but not multilibbed configurations.
  
--- 44379,44550 ----
  
  Target makefile fragments can set these Makefile variables.
  
! ‘LIBGCC2_CFLAGS’
!      Compiler flags to use when compiling ‘libgcc2.c’.
  
! ‘LIB2FUNCS_EXTRA’
       A list of source file names to be compiled or assembled and
!      inserted into ‘libgcc.a’.
  
! ‘CRTSTUFF_T_CFLAGS’
!      Special flags used when compiling ‘crtstuff.c’.  *Note
       Initialization::.
  
! ‘CRTSTUFF_T_CFLAGS_S’
!      Special flags used when compiling ‘crtstuff.c’ for shared linking.
!      Used if you use ‘crtbeginS.o’ and ‘crtendS.o’ in ‘EXTRA-PARTS’.
       *Note Initialization::.
  
! ‘MULTILIB_OPTIONS’
       For some targets, invoking GCC in different ways produces objects
       that cannot be linked together.  For example, for some targets GCC
       produces both big and little endian code.  For these targets, you
!      must arrange for multiple versions of ‘libgcc.a’ to be compiled,
       one for each set of incompatible options.  When GCC invokes the
!      linker, it arranges to link in the right version of ‘libgcc.a’,
       based on the command line options used.
  
!      The ‘MULTILIB_OPTIONS’ macro lists the set of options for which
!      special versions of ‘libgcc.a’ must be built.  Write options that
       are mutually incompatible side by side, separated by a slash.
       Write options that may be used together separated by a space.  The
       build procedure will build all combinations of compatible options.
  
!      For example, if you set ‘MULTILIB_OPTIONS’ to ‘m68000/m68020
!      msoft-float’, ‘Makefile’ will build special versions of ‘libgcc.a’
!      using the following sets of options: ‘-m68000’, ‘-m68020’,
!      ‘-msoft-float’, ‘-m68000 -msoft-float’, and ‘-m68020 -msoft-float’.
  
! ‘MULTILIB_DIRNAMES’
!      If ‘MULTILIB_OPTIONS’ is used, this variable specifies the
       directory names that should be used to hold the various libraries.
!      Write one element in ‘MULTILIB_DIRNAMES’ for each element in
!      ‘MULTILIB_OPTIONS’.  If ‘MULTILIB_DIRNAMES’ is not used, the
!      default value will be ‘MULTILIB_OPTIONS’, with all slashes treated
       as spaces.
  
!      ‘MULTILIB_DIRNAMES’ describes the multilib directories using GCC
       conventions and is applied to directories that are part of the GCC
       installation.  When multilib-enabled, the compiler will add a
       subdirectory of the form PREFIX/MULTILIB before each directory in
       the search path for libraries and crt files.
  
!      For example, if ‘MULTILIB_OPTIONS’ is set to ‘m68000/m68020
!      msoft-float’, then the default value of ‘MULTILIB_DIRNAMES’ is
!      ‘m68000 m68020 msoft-float’.  You may specify a different value if
       you desire a different set of directory names.
  
! ‘MULTILIB_MATCHES’
       Sometimes the same option may be written in two different ways.  If
!      an option is listed in ‘MULTILIB_OPTIONS’, GCC needs to know about
!      any synonyms.  In that case, set ‘MULTILIB_MATCHES’ to a list of
!      items of the form ‘option=option’ to describe all relevant
!      synonyms.  For example, ‘m68000=mc68000 m68020=mc68020’.
  
! ‘MULTILIB_EXCEPTIONS’
!      Sometimes when there are multiple sets of ‘MULTILIB_OPTIONS’ being
       specified, there are combinations that should not be built.  In
!      that case, set ‘MULTILIB_EXCEPTIONS’ to be all of the switch
       exceptions in shell case syntax that should not be built.
  
       For example the ARM processor cannot execute both hardware floating
       point instructions and the reduced size THUMB instructions at the
       same time, so there is no need to build libraries with both of
!      these options enabled.  Therefore ‘MULTILIB_EXCEPTIONS’ is set to:
            *mthumb/*mhard-float*
  
! ‘MULTILIB_REQUIRED’
       Sometimes when there are only a few combinations are required, it
!      would be a big effort to come up with a ‘MULTILIB_EXCEPTIONS’ list
       to cover all undesired ones.  In such a case, just listing all the
!      required combinations in ‘MULTILIB_REQUIRED’ would be more
       straightforward.
  
!      The way to specify the entries in ‘MULTILIB_REQUIRED’ is same with
!      the way used for ‘MULTILIB_EXCEPTIONS’, only this time what are
       required will be specified.  Suppose there are multiple sets of
!      ‘MULTILIB_OPTIONS’ and only two combinations are required, one for
       ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU,
!      the ‘MULTILIB_REQUIRED’ can be set to:
            MULTILIB_REQUIRED =  mthumb/march=armv7-m
            MULTILIB_REQUIRED += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16
  
!      The ‘MULTILIB_REQUIRED’ can be used together with
!      ‘MULTILIB_EXCEPTIONS’.  The option combinations generated from
!      ‘MULTILIB_OPTIONS’ will be filtered by ‘MULTILIB_EXCEPTIONS’ and
!      then by ‘MULTILIB_REQUIRED’.
  
! ‘MULTILIB_REUSE’
       Sometimes it is desirable to reuse one existing multilib for
       different sets of options.  Such kind of reuse can minimize the
       number of multilib variants.  And for some targets it is better to
       reuse an existing multilib than to fall back to default multilib
       when there is no corresponding multilib.  This can be done by
!      adding reuse rules to ‘MULTILIB_REUSE’.
  
       A reuse rule is comprised of two parts connected by equality sign.
       The left part is the option set used to build multilib and the
       right part is the option set that will reuse this multilib.  Both
!      parts should only use options specified in ‘MULTILIB_OPTIONS’ and
       the equality signs found in options name should be replaced with
       periods.  An explicit period in the rule can be escaped by
       preceding it with a backslash.  The order of options in the left
       part matters and should be same with those specified in
!      ‘MULTILIB_REQUIRED’ or aligned with the order in
!      ‘MULTILIB_OPTIONS’.  There is no such limitation for options in the
       right part as we don't build multilib from them.
  
!      ‘MULTILIB_REUSE’ is different from ‘MULTILIB_MATCHES’ in that it
       sets up relations between two option sets rather than two options.
       Here is an example to demo how we reuse libraries built in Thumb
       mode for applications built in ARM mode:
            MULTILIB_REUSE = mthumb/march.armv7-r=marm/march.armv7-r
  
!      Before the advent of ‘MULTILIB_REUSE’, GCC select multilib by
       comparing command line options with options used to build multilib.
!      The ‘MULTILIB_REUSE’ is complementary to that way.  Only when the
       original comparison matches nothing it will work to see if it is OK
       to reuse some existing multilib.
  
! ‘MULTILIB_EXTRA_OPTS’
       Sometimes it is desirable that when building multiple versions of
!      ‘libgcc.a’ certain options should always be passed on to the
!      compiler.  In that case, set ‘MULTILIB_EXTRA_OPTS’ to be the list
       of options to be used for all builds.  If you set this, you should
!      probably set ‘CRTSTUFF_T_CFLAGS’ to a dash followed by it.
  
! ‘MULTILIB_OSDIRNAMES’
!      If ‘MULTILIB_OPTIONS’ is used, this variable specifies a list of
       subdirectory names, that are used to modify the search path
!      depending on the chosen multilib.  Unlike ‘MULTILIB_DIRNAMES’,
!      ‘MULTILIB_OSDIRNAMES’ describes the multilib directories using
       operating systems conventions, and is applied to the directories
!      such as ‘lib’ or those in the ‘LIBRARY_PATH’ environment variable.
!      The format is either the same as of ‘MULTILIB_DIRNAMES’, or a set
!      of mappings.  When it is the same as ‘MULTILIB_DIRNAMES’, it
       describes the multilib directories using operating system
       conventions, rather than GCC conventions.  When it is a set of
       mappings of the form GCCDIR=OSDIR, the left side gives the GCC
       convention and the right gives the equivalent OS defined location.
!      If the OSDIR part begins with a ‘!’, GCC will not search in the
       non-multilib directory and use exclusively the multilib directory.
       Otherwise, the compiler will examine the search path for libraries
       and crt files twice; the first time it will add MULTILIB to each
       directory in the search path, the second it will not.
  
       For configurations that support both multilib and multiarch,
!      ‘MULTILIB_OSDIRNAMES’ also encodes the multiarch name, thus
!      subsuming ‘MULTIARCH_DIRNAME’.  The multiarch name is appended to
       each directory name, separated by a colon (e.g.
!      ‘../lib32:i386-linux-gnu’).
  
       Each multiarch subdirectory will be searched before the
       corresponding OS multilib directory, for example
!      ‘/lib/i386-linux-gnu’ before ‘/lib/../lib32’.  The multiarch name
       will also be used to modify the system header search path, as
!      explained for ‘MULTIARCH_DIRNAME’.
  
! ‘MULTIARCH_DIRNAME’
       This variable specifies the multiarch name for configurations that
       are multiarch-enabled but not multilibbed configurations.
  
*************** Target makefile fragments can set these
*** 44554,44587 ****
       locations.  The compiler will add a multiarch subdirectory of the
       form PREFIX/MULTIARCH before each directory in the library and crt
       search path.  It will also add two directories
!      'LOCAL_INCLUDE_DIR'/MULTIARCH and
!      'NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search
!      path, respectively before 'LOCAL_INCLUDE_DIR' and
!      'NATIVE_SYSTEM_HEADER_DIR'.
  
!      'MULTIARCH_DIRNAME' is not used for configurations that support
       both multilib and multiarch.  In that case, multiarch names are
!      encoded in 'MULTILIB_OSDIRNAMES' instead.
  
       More documentation about multiarch can be found at
       .
  
! 'SPECS'
!      Unfortunately, setting 'MULTILIB_EXTRA_OPTS' is not enough, since
       it does not affect the build of target libraries, at least not the
       build of the default multilib.  One possible work-around is to use
!      'DRIVER_SELF_SPECS' to bring options from the 'specs' file as if
       they had been passed in the compiler driver command line.  However,
       you don't want to be adding these options after the toolchain is
!      installed, so you can instead tweak the 'specs' file that will be
       used during the toolchain build, while you still install the
!      original, built-in 'specs'.  The trick is to set 'SPECS' to some
!      other filename (say 'specs.install'), that will then be created out
!      of the built-in specs, and introduce a 'Makefile' rule to generate
!      the 'specs' file that's going to be used at build time out of your
!      'specs.install'.
  
! 'T_CFLAGS'
       These are extra flags to pass to the C compiler.  They are used
       both when building GCC, and when compiling things with the
       just-built GCC.  This variable is deprecated and should not be
--- 44553,44586 ----
       locations.  The compiler will add a multiarch subdirectory of the
       form PREFIX/MULTIARCH before each directory in the library and crt
       search path.  It will also add two directories
!      ‘LOCAL_INCLUDE_DIR’/MULTIARCH and
!      ‘NATIVE_SYSTEM_HEADER_DIR’/MULTIARCH) to the system header search
!      path, respectively before ‘LOCAL_INCLUDE_DIR’ and
!      ‘NATIVE_SYSTEM_HEADER_DIR’.
  
!      ‘MULTIARCH_DIRNAME’ is not used for configurations that support
       both multilib and multiarch.  In that case, multiarch names are
!      encoded in ‘MULTILIB_OSDIRNAMES’ instead.
  
       More documentation about multiarch can be found at
       .
  
! ‘SPECS’
!      Unfortunately, setting ‘MULTILIB_EXTRA_OPTS’ is not enough, since
       it does not affect the build of target libraries, at least not the
       build of the default multilib.  One possible work-around is to use
!      ‘DRIVER_SELF_SPECS’ to bring options from the ‘specs’ file as if
       they had been passed in the compiler driver command line.  However,
       you don't want to be adding these options after the toolchain is
!      installed, so you can instead tweak the ‘specs’ file that will be
       used during the toolchain build, while you still install the
!      original, built-in ‘specs’.  The trick is to set ‘SPECS’ to some
!      other filename (say ‘specs.install’), that will then be created out
!      of the built-in specs, and introduce a ‘Makefile’ rule to generate
!      the ‘specs’ file that's going to be used at build time out of your
!      ‘specs.install’.
  
! ‘T_CFLAGS’
       These are extra flags to pass to the C compiler.  They are used
       both when building GCC, and when compiling things with the
       just-built GCC.  This variable is deprecated and should not be
*************** File: gccint.info,  Node: Host Fragment,
*** 44593,44671 ****
  20.2 Host Makefile Fragments
  ============================
  
! The use of 'x-HOST' fragments is discouraged.  You should only use it
  for makefile dependencies.
  
  
  File: gccint.info,  Node: Collect2,  Next: Header Dirs,  Prev: Fragments,  Up: Top
  
! 21 'collect2'
  *************
  
! GCC uses a utility called 'collect2' on nearly all systems to arrange to
  call various initialization functions at start time.
  
!  The program 'collect2' works by linking the program once and looking
  through the linker output file for symbols with particular names
  indicating they are constructor functions.  If it finds any, it creates
! a new temporary '.c' file containing a table of them, compiles it, and
  links the program a second time including that file.
  
   The actual calls to the constructors are carried out by a subroutine
! called '__main', which is called (automatically) at the beginning of the
! body of 'main' (provided 'main' was compiled with GNU CC).  Calling
! '__main' is necessary, even when compiling C code, to allow linking C
! and C++ object code together.  (If you use '-nostdlib', you get an
! unresolved reference to '__main', since it's defined in the standard GCC
! library.  Include '-lgcc' at the end of your compiler command line to
  resolve this reference.)
  
!  The program 'collect2' is installed as 'ld' in the directory where the
! passes of the compiler are installed.  When 'collect2' needs to find the
! _real_ 'ld', it tries the following file names:
  
!    * a hard coded linker file name, if GCC was configured with the
!      '--with-ld' option.
  
!    * 'real-ld' in the directories listed in the compiler's search
       directories.
  
!    * 'real-ld' in the directories listed in the environment variable
!      'PATH'.
  
!    * The file specified in the 'REAL_LD_FILE_NAME' configuration macro,
       if specified.
  
!    * 'ld' in the compiler's search directories, except that 'collect2'
       will not execute itself recursively.
  
!    * 'ld' in 'PATH'.
  
   "The compiler's search directories" means all the directories where
! 'gcc' searches for passes of the compiler.  This includes directories
! that you specify with '-B'.
  
   Cross-compilers search a little differently:
  
!    * 'real-ld' in the compiler's search directories.
  
!    * 'TARGET-real-ld' in 'PATH'.
  
!    * The file specified in the 'REAL_LD_FILE_NAME' configuration macro,
       if specified.
  
!    * 'ld' in the compiler's search directories.
  
!    * 'TARGET-ld' in 'PATH'.
  
!  'collect2' explicitly avoids running 'ld' using the file name under
! which 'collect2' itself was invoked.  In fact, it remembers up a list of
! such names--in case one copy of 'collect2' finds another copy (or
! version) of 'collect2' installed as 'ld' in a second place in the search
  path.
  
!  'collect2' searches for the utilities 'nm' and 'strip' using the same
! algorithm as above for 'ld'.
  
  
  File: gccint.info,  Node: Header Dirs,  Next: Type Information,  Prev: Collect2,  Up: Top
--- 44592,44670 ----
  20.2 Host Makefile Fragments
  ============================
  
! The use of ‘x-HOST’ fragments is discouraged.  You should only use it
  for makefile dependencies.
  
  
  File: gccint.info,  Node: Collect2,  Next: Header Dirs,  Prev: Fragments,  Up: Top
  
! 21 ‘collect2’
  *************
  
! GCC uses a utility called ‘collect2’ on nearly all systems to arrange to
  call various initialization functions at start time.
  
!  The program ‘collect2’ works by linking the program once and looking
  through the linker output file for symbols with particular names
  indicating they are constructor functions.  If it finds any, it creates
! a new temporary ‘.c’ file containing a table of them, compiles it, and
  links the program a second time including that file.
  
   The actual calls to the constructors are carried out by a subroutine
! called ‘__main’, which is called (automatically) at the beginning of the
! body of ‘main’ (provided ‘main’ was compiled with GNU CC).  Calling
! ‘__main’ is necessary, even when compiling C code, to allow linking C
! and C++ object code together.  (If you use ‘-nostdlib’, you get an
! unresolved reference to ‘__main’, since it's defined in the standard GCC
! library.  Include ‘-lgcc’ at the end of your compiler command line to
  resolve this reference.)
  
!  The program ‘collect2’ is installed as ‘ld’ in the directory where the
! passes of the compiler are installed.  When ‘collect2’ needs to find the
! _real_ ‘ld’, it tries the following file names:
  
!    • a hard coded linker file name, if GCC was configured with the
!      ‘--with-ld’ option.
  
!    • ‘real-ld’ in the directories listed in the compiler's search
       directories.
  
!    • ‘real-ld’ in the directories listed in the environment variable
!      ‘PATH’.
  
!    • The file specified in the ‘REAL_LD_FILE_NAME’ configuration macro,
       if specified.
  
!    • ‘ld’ in the compiler's search directories, except that ‘collect2’
       will not execute itself recursively.
  
!    • ‘ld’ in ‘PATH’.
  
   "The compiler's search directories" means all the directories where
! ‘gcc’ searches for passes of the compiler.  This includes directories
! that you specify with ‘-B’.
  
   Cross-compilers search a little differently:
  
!    • ‘real-ld’ in the compiler's search directories.
  
!    • ‘TARGET-real-ld’ in ‘PATH’.
  
!    • The file specified in the ‘REAL_LD_FILE_NAME’ configuration macro,
       if specified.
  
!    • ‘ld’ in the compiler's search directories.
  
!    • ‘TARGET-ld’ in ‘PATH’.
  
!  ‘collect2’ explicitly avoids running ‘ld’ using the file name under
! which ‘collect2’ itself was invoked.  In fact, it remembers up a list of
! such names--in case one copy of ‘collect2’ finds another copy (or
! version) of ‘collect2’ installed as ‘ld’ in a second place in the search
  path.
  
!  ‘collect2’ searches for the utilities ‘nm’ and ‘strip’ using the same
! algorithm as above for ‘ld’.
  
  
  File: gccint.info,  Node: Header Dirs,  Next: Type Information,  Prev: Collect2,  Up: Top
*************** File: gccint.info,  Node: Header Dirs,
*** 44673,44701 ****
  22 Standard Header File Directories
  ***********************************
  
! 'GCC_INCLUDE_DIR' means the same thing for native and cross.  It is
  where GCC stores its private include files, and also where GCC stores
! the fixed include files.  A cross compiled GCC runs 'fixincludes' on the
! header files in '$(tooldir)/include'.  (If the cross compilation header
  files need to be fixed, they must be installed before GCC is built.  If
  the cross compilation header files are already suitable for GCC, nothing
  special need be done).
  
!  'GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross.  It
! is where 'g++' looks first for header files.  The C++ library installs
  only target independent header files in that directory.
  
!  'LOCAL_INCLUDE_DIR' is used only by native compilers.  GCC doesn't
! install anything there.  It is normally '/usr/local/include'.  This is
  where local additions to a packaged system should place header files.
  
!  'CROSS_INCLUDE_DIR' is used only by cross compilers.  GCC doesn't
  install anything there.
  
!  'TOOL_INCLUDE_DIR' is used for both native and cross compilers.  It is
  the place for other packages to install header files that GCC will use.
! For a cross-compiler, this is the equivalent of '/usr/include'.  When
! you build a cross-compiler, 'fixincludes' processes any header files in
  this directory.
  
  
--- 44672,44700 ----
  22 Standard Header File Directories
  ***********************************
  
! ‘GCC_INCLUDE_DIR’ means the same thing for native and cross.  It is
  where GCC stores its private include files, and also where GCC stores
! the fixed include files.  A cross compiled GCC runs ‘fixincludes’ on the
! header files in ‘$(tooldir)/include’.  (If the cross compilation header
  files need to be fixed, they must be installed before GCC is built.  If
  the cross compilation header files are already suitable for GCC, nothing
  special need be done).
  
!  ‘GPLUSPLUS_INCLUDE_DIR’ means the same thing for native and cross.  It
! is where ‘g++’ looks first for header files.  The C++ library installs
  only target independent header files in that directory.
  
!  ‘LOCAL_INCLUDE_DIR’ is used only by native compilers.  GCC doesn't
! install anything there.  It is normally ‘/usr/local/include’.  This is
  where local additions to a packaged system should place header files.
  
!  ‘CROSS_INCLUDE_DIR’ is used only by cross compilers.  GCC doesn't
  install anything there.
  
!  ‘TOOL_INCLUDE_DIR’ is used for both native and cross compilers.  It is
  the place for other packages to install header files that GCC will use.
! For a cross-compiler, this is the equivalent of ‘/usr/include’.  When
! you build a cross-compiler, ‘fixincludes’ processes any header files in
  this directory.
  
  
*************** implement precompiled headers.
*** 44711,44718 ****
  
   A full C++ parser would be too complicated for this task, so a limited
  subset of C++ is interpreted and special markers are used to determine
! what parts of the source to look at.  All 'struct', 'union' and
! 'template' structure declarations that define data structures that are
  allocated under control of the garbage collector must be marked.  All
  global variables that hold pointers to garbage-collected memory must
  also be marked.  Finally, all global variables that need to be saved and
--- 44710,44717 ----
  
   A full C++ parser would be too complicated for this task, so a limited
  subset of C++ is interpreted and special markers are used to determine
! what parts of the source to look at.  All ‘struct’, ‘union’ and
! ‘template’ structure declarations that define data structures that are
  allocated under control of the garbage collector must be marked.  All
  global variables that hold pointers to garbage-collected memory must
  also be marked.  Finally, all global variables that need to be saved and
*************** be saved in a precompiled header.)
*** 44724,44735 ****
   The full format of a marker is
       GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...))
  but in most cases no options are needed.  The outer double parentheses
! are still necessary, though: 'GTY(())'.  Markers can appear:
  
!    * In a structure definition, before the open brace;
!    * In a global variable declaration, after the keyword 'static' or
!      'extern'; and
!    * In a structure field definition, before the name of the field.
  
   Here are some examples of marking simple data structures and globals.
  
--- 44723,44734 ----
   The full format of a marker is
       GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...))
  but in most cases no options are needed.  The outer double parentheses
! are still necessary, though: ‘GTY(())’.  Markers can appear:
  
!    • In a structure definition, before the open brace;
!    • In a global variable declaration, after the keyword ‘static’ or
!      ‘extern’; and
!    • In a structure field definition, before the name of the field.
  
   Here are some examples of marking simple data structures and globals.
  
*************** are still necessary, though: 'GTY(())'.
*** 44746,44779 ****
       static GTY(()) struct TAG *LIST;   /* points to GC memory */
       static GTY(()) int COUNTER;        /* save counter in a PCH */
  
!  The parser understands simple typedefs such as 'typedef struct TAG
! *NAME;' and 'typedef int NAME;'.  These don't need to be marked.
  
!  However, in combination with GTY, avoid using typedefs such as 'typedef
! int_hash<...> NAME;' for these generate infinite-recursion code.  See
! PR103157 (https://gcc.gnu.org/PR103157).  Instead, you may use 'struct
! NAME : int_hash<...> {};', for example.
  
!  Since 'gengtype''s understanding of C++ is limited, there are several
  constructs and declarations that are not supported inside
  classes/structures marked for automatic GC code generation.  The
! following C++ constructs produce a 'gengtype' error on
  structures/classes marked for automatic GC code generation:
  
!    * Type definitions inside classes/structures are not supported.
!    * Enumerations inside classes/structures are not supported.
  
   If you have a class or structure using any of the above constructs, you
! need to mark that class as 'GTY ((user))' and provide your own marking
  routines (see section *note User GC:: for details).
  
   It is always valid to include function definitions inside classes.
! Those are always ignored by 'gengtype', as it only cares about data
  members.
  
  * Menu:
  
! * GTY Options::         What goes inside a 'GTY(())'.
  * Inheritance and GTY:: Adding GTY to a class hierarchy.
  * User GC::		Adding user-provided GC marking routines.
  * GGC Roots::           Making global variables GGC roots.
--- 44745,44778 ----
       static GTY(()) struct TAG *LIST;   /* points to GC memory */
       static GTY(()) int COUNTER;        /* save counter in a PCH */
  
!  The parser understands simple typedefs such as ‘typedef struct TAG
! *NAME;’ and ‘typedef int NAME;’.  These don't need to be marked.
  
!  However, in combination with GTY, avoid using typedefs such as ‘typedef
! int_hash<...> NAME;’ for these generate infinite-recursion code.  See
! PR103157 (https://gcc.gnu.org/PR103157).  Instead, you may use ‘struct
! NAME : int_hash<...> {};’, for example.
  
!  Since ‘gengtype’'s understanding of C++ is limited, there are several
  constructs and declarations that are not supported inside
  classes/structures marked for automatic GC code generation.  The
! following C++ constructs produce a ‘gengtype’ error on
  structures/classes marked for automatic GC code generation:
  
!    • Type definitions inside classes/structures are not supported.
!    • Enumerations inside classes/structures are not supported.
  
   If you have a class or structure using any of the above constructs, you
! need to mark that class as ‘GTY ((user))’ and provide your own marking
  routines (see section *note User GC:: for details).
  
   It is always valid to include function definitions inside classes.
! Those are always ignored by ‘gengtype’, as it only cares about data
  members.
  
  * Menu:
  
! * GTY Options::         What goes inside a ‘GTY(())’.
  * Inheritance and GTY:: Adding GTY to a class hierarchy.
  * User GC::		Adding user-provided GC marking routines.
  * GGC Roots::           Making global variables GGC roots.
*************** members.
*** 44784,44812 ****
  
  File: gccint.info,  Node: GTY Options,  Next: Inheritance and GTY,  Up: Type Information
  
! 23.1 The Inside of a 'GTY(())'
  ==============================
  
  Sometimes the C code is not enough to fully describe the type structure.
! Extra information can be provided with 'GTY' options and additional
  markers.  Some options take a parameter, which may be either a string or
  a type name, depending on the parameter.  If an option takes no
  parameter, it is acceptable either to omit the parameter entirely, or to
! provide an empty string as a parameter.  For example, 'GTY ((skip))' and
! 'GTY ((skip ("")))' are equivalent.
  
   When the parameter is a string, often it is a fragment of C code.  Four
  special escapes may be used in these strings, to refer to pieces of the
  data structure being marked:
  
! '%h'
       The current structure.
! '%1'
       The structure that immediately contains the current structure.
! '%0'
       The outermost structure that contains the current structure.
! '%a'
!      A partial expression of the form '[i1][i2]...' that indexes the
       array item currently being marked.
  
   For instance, suppose that you have a structure of the form
--- 44783,44811 ----
  
  File: gccint.info,  Node: GTY Options,  Next: Inheritance and GTY,  Up: Type Information
  
! 23.1 The Inside of a ‘GTY(())’
  ==============================
  
  Sometimes the C code is not enough to fully describe the type structure.
! Extra information can be provided with ‘GTY’ options and additional
  markers.  Some options take a parameter, which may be either a string or
  a type name, depending on the parameter.  If an option takes no
  parameter, it is acceptable either to omit the parameter entirely, or to
! provide an empty string as a parameter.  For example, ‘GTY ((skip))’ and
! ‘GTY ((skip ("")))’ are equivalent.
  
   When the parameter is a string, often it is a fragment of C code.  Four
  special escapes may be used in these strings, to refer to pieces of the
  data structure being marked:
  
! ‘%h’
       The current structure.
! ‘%1’
       The structure that immediately contains the current structure.
! ‘%0’
       The outermost structure that contains the current structure.
! ‘%a’
!      A partial expression of the form ‘[i1][i2]...’ that indexes the
       array item currently being marked.
  
   For instance, suppose that you have a structure of the form
*************** data structure being marked:
*** 44816,44824 ****
       struct B {
         struct A foo[12];
       };
! and 'b' is a variable of type 'struct B'.  When marking 'b.foo[11]',
! '%h' would expand to 'b.foo[11]', '%0' and '%1' would both expand to
! 'b', and '%a' would expand to '[11]'.
  
   As in ordinary C, adjacent strings will be concatenated; this is
  helpful when you have a complicated expression.
--- 44815,44823 ----
       struct B {
         struct A foo[12];
       };
! and ‘b’ is a variable of type ‘struct B’.  When marking ‘b.foo[11]’,
! ‘%h’ would expand to ‘b.foo[11]’, ‘%0’ and ‘%1’ would both expand to
! ‘b’, and ‘%a’ would expand to ‘[11]’.
  
   As in ordinary C, adjacent strings will be concatenated; this is
  helpful when you have a complicated expression.
*************** helpful when you have a complicated expr
*** 44828,44834 ****
  
   The available options are:
  
! 'length ("EXPRESSION")'
  
       There are two places the type machinery will need to be explicitly
       told the length of an array of non-atomic objects.  The first case
--- 44827,44833 ----
  
   The available options are:
  
! ‘length ("EXPRESSION")’
  
       There are two places the type machinery will need to be explicitly
       told the length of an array of non-atomic objects.  The first case
*************** helpful when you have a complicated expr
*** 44838,44872 ****
              rtx GTY ((length ("%h.num_elem"))) elem[1];
            };
  
!      In this case, the 'length' option is used to override the specified
!      array length (which should usually be '1').  The parameter of the
       option is a fragment of C code that calculates the length.
  
       The second case is when a structure or a global variable contains a
       pointer to an array, like this:
            struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter;
!      In this case, 'iter' has been allocated by writing something like
              x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse);
!      and the 'collapse' provides the length of the field.
  
!      This second use of 'length' also works on global variables, like:
       static GTY((length("reg_known_value_size"))) rtx *reg_known_value;
  
!      Note that the 'length' option is only meant for use with arrays of
       non-atomic objects, that is, objects that contain pointers pointing
       to other GTY-managed objects.  For other GC-allocated arrays and
!      strings you should use 'atomic' or 'string_length'.
  
! 'string_length ("EXPRESSION")'
  
       In order to simplify production of PCH, a structure member that is
!      a plain array of bytes (an optionally 'const' and/or 'unsigned'
!      'char *') is treated specially by the infrastructure.  Even if such
       an array has not been allocated in GC-controlled memory, it will
       still be written properly into a PCH. The machinery responsible for
       this needs to know the length of the data; by default, the length
!      is determined by calling 'strlen' on the pointer.  The
!      'string_length' option specifies an alternate way to determine the
       length, such as by inspecting another struct member:
  
            struct GTY(()) non_terminated_string {
--- 44837,44871 ----
              rtx GTY ((length ("%h.num_elem"))) elem[1];
            };
  
!      In this case, the ‘length’ option is used to override the specified
!      array length (which should usually be ‘1’).  The parameter of the
       option is a fragment of C code that calculates the length.
  
       The second case is when a structure or a global variable contains a
       pointer to an array, like this:
            struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter;
!      In this case, ‘iter’ has been allocated by writing something like
              x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse);
!      and the ‘collapse’ provides the length of the field.
  
!      This second use of ‘length’ also works on global variables, like:
       static GTY((length("reg_known_value_size"))) rtx *reg_known_value;
  
!      Note that the ‘length’ option is only meant for use with arrays of
       non-atomic objects, that is, objects that contain pointers pointing
       to other GTY-managed objects.  For other GC-allocated arrays and
!      strings you should use ‘atomic’ or ‘string_length’.
  
! ‘string_length ("EXPRESSION")’
  
       In order to simplify production of PCH, a structure member that is
!      a plain array of bytes (an optionally ‘const’ and/or ‘unsigned’
!      ‘char *’) is treated specially by the infrastructure.  Even if such
       an array has not been allocated in GC-controlled memory, it will
       still be written properly into a PCH. The machinery responsible for
       this needs to know the length of the data; by default, the length
!      is determined by calling ‘strlen’ on the pointer.  The
!      ‘string_length’ option specifies an alternate way to determine the
       length, such as by inspecting another struct member:
  
            struct GTY(()) non_terminated_string {
*************** helpful when you have a complicated expr
*** 44874,44894 ****
              const char * GTY((string_length ("%h.sz"))) data;
            };
  
! 'skip'
  
!      If 'skip' is applied to a field, the type machinery will ignore it.
       This is somewhat dangerous; the only safe use is in a union when
       one field really isn't ever used.
  
! 'callback'
  
!      'callback' should be applied to fields with pointer to function
!      type and causes the field to be ignored similarly to 'skip', except
       when writing PCH and the field is non-NULL it will remember the
       field's address for relocation purposes if the process writing PCH
       has different load base from a process reading PCH.
  
! 'for_user'
  
       Use this to mark types that need to be marked by user gc routines,
       but are not refered to in a template argument.  So if you have some
--- 44873,44893 ----
              const char * GTY((string_length ("%h.sz"))) data;
            };
  
! ‘skip’
  
!      If ‘skip’ is applied to a field, the type machinery will ignore it.
       This is somewhat dangerous; the only safe use is in a union when
       one field really isn't ever used.
  
! ‘callback’
  
!      ‘callback’ should be applied to fields with pointer to function
!      type and causes the field to be ignored similarly to ‘skip’, except
       when writing PCH and the field is non-NULL it will remember the
       field's address for relocation purposes if the process writing PCH
       has different load base from a process reading PCH.
  
! ‘for_user’
  
       Use this to mark types that need to be marked by user gc routines,
       but are not refered to in a template argument.  So if you have some
*************** helpful when you have a complicated expr
*** 44896,44916 ****
       for_user option so that the marking functions for T1 can call non
       mangled functions to mark T2.
  
! 'desc ("EXPRESSION")'
! 'tag ("CONSTANT")'
! 'default'
  
!      The type machinery needs to be told which field of a 'union' is
       currently active.  This is done by giving each field a constant
!      'tag' value, and then specifying a discriminator using 'desc'.  The
!      value of the expression given by 'desc' is compared against each
!      'tag' value, each of which should be different.  If no 'tag' is
!      matched, the field marked with 'default' is used if there is one,
       otherwise no field in the union will be marked.
  
!      In the 'desc' option, the "current structure" is the union that it
!      discriminates.  Use '%1' to mean the structure containing it.
!      There are no escapes available to the 'tag' option, since it is a
       constant.
  
       For example,
--- 44895,44915 ----
       for_user option so that the marking functions for T1 can call non
       mangled functions to mark T2.
  
! ‘desc ("EXPRESSION")’
! ‘tag ("CONSTANT")’
! ‘default’
  
!      The type machinery needs to be told which field of a ‘union’ is
       currently active.  This is done by giving each field a constant
!      ‘tag’ value, and then specifying a discriminator using ‘desc’.  The
!      value of the expression given by ‘desc’ is compared against each
!      ‘tag’ value, each of which should be different.  If no ‘tag’ is
!      matched, the field marked with ‘default’ is used if there is one,
       otherwise no field in the union will be marked.
  
!      In the ‘desc’ option, the "current structure" is the union that it
!      discriminates.  Use ‘%1’ to mean the structure containing it.
!      There are no escapes available to the ‘tag’ option, since it is a
       constant.
  
       For example,
*************** helpful when you have a complicated expr
*** 44925,44961 ****
            };
  
       In this example, the value of BINDING_HAS_LEVEL_P when applied to a
!      'struct tree_binding *' is presumed to be 0 or 1.  If 1, the type
!      mechanism will treat the field 'level' as being present and if 0,
!      will treat the field 'scope' as being present.
  
!      The 'desc' and 'tag' options can also be used for inheritance to
       denote which subclass an instance is.  See *note Inheritance and
       GTY:: for more information.
  
! 'cache'
  
!      When the 'cache' option is applied to a global variable
       gt_cleare_cache is called on that variable between the mark and
       sweep phases of garbage collection.  The gt_clear_cache function is
       free to mark blocks as used, or to clear pointers in the variable.
  
! 'deletable'
  
!      'deletable', when applied to a global variable, indicates that when
       garbage collection runs, there's no need to mark anything pointed
!      to by this variable, it can just be set to 'NULL' instead.  This is
       used to keep a list of free structures around for re-use.
  
! 'maybe_undef'
  
!      When applied to a field, 'maybe_undef' indicates that it's OK if
       the structure that this fields points to is never defined, so long
!      as this field is always 'NULL'.  This is used to avoid requiring
       backends to define certain optional structures.  It doesn't work
       with language frontends.
  
! 'nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")'
  
       The type machinery expects all pointers to point to the start of an
       object.  Sometimes for abstraction purposes it's convenient to have
--- 44924,44960 ----
            };
  
       In this example, the value of BINDING_HAS_LEVEL_P when applied to a
!      ‘struct tree_binding *’ is presumed to be 0 or 1.  If 1, the type
!      mechanism will treat the field ‘level’ as being present and if 0,
!      will treat the field ‘scope’ as being present.
  
!      The ‘desc’ and ‘tag’ options can also be used for inheritance to
       denote which subclass an instance is.  See *note Inheritance and
       GTY:: for more information.
  
! ‘cache’
  
!      When the ‘cache’ option is applied to a global variable
       gt_cleare_cache is called on that variable between the mark and
       sweep phases of garbage collection.  The gt_clear_cache function is
       free to mark blocks as used, or to clear pointers in the variable.
  
! ‘deletable’
  
!      ‘deletable’, when applied to a global variable, indicates that when
       garbage collection runs, there's no need to mark anything pointed
!      to by this variable, it can just be set to ‘NULL’ instead.  This is
       used to keep a list of free structures around for re-use.
  
! ‘maybe_undef’
  
!      When applied to a field, ‘maybe_undef’ indicates that it's OK if
       the structure that this fields points to is never defined, so long
!      as this field is always ‘NULL’.  This is used to avoid requiring
       backends to define certain optional structures.  It doesn't work
       with language frontends.
  
! ‘nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")’
  
       The type machinery expects all pointers to point to the start of an
       object.  Sometimes for abstraction purposes it's convenient to have
*************** helpful when you have a complicated expr
*** 44964,44995 ****
       pointers can still be used.  TYPE is the type of the original
       object, the TO EXPRESSION returns the pointer given the original
       object, and the FROM EXPRESSION returns the original object given
!      the pointer.  The pointer will be available using the '%h' escape.
  
! 'chain_next ("EXPRESSION")'
! 'chain_prev ("EXPRESSION")'
! 'chain_circular ("EXPRESSION")'
  
       It's helpful for the type machinery to know if objects are often
       chained together in long lists; this lets it generate code that
       uses less stack space by iterating along the list instead of
!      recursing down it.  'chain_next' is an expression for the next item
!      in the list, 'chain_prev' is an expression for the previous item.
!      For singly linked lists, use only 'chain_next'; for doubly linked
       lists, use both.  The machinery requires that taking the next item
!      of the previous item gives the original item.  'chain_circular' is
!      similar to 'chain_next', but can be used for circular single linked
       lists.
  
! 'reorder ("FUNCTION NAME")'
  
       Some data structures depend on the relative ordering of pointers.
       If the precompiled header machinery needs to change that ordering,
!      it will call the function referenced by the 'reorder' option,
       before changing the pointers in the object that's pointed to by the
       field the option applies to.  The function must take four
       arguments, with the signature
!      'void *, void *, gt_pointer_operator, void *'.  The first parameter
       is a pointer to the structure that contains the object being
       updated, or the object itself if there is no containing structure.
       The second parameter is a cookie that should be ignored.  The third
--- 44963,44994 ----
       pointers can still be used.  TYPE is the type of the original
       object, the TO EXPRESSION returns the pointer given the original
       object, and the FROM EXPRESSION returns the original object given
!      the pointer.  The pointer will be available using the ‘%h’ escape.
  
! ‘chain_next ("EXPRESSION")’
! ‘chain_prev ("EXPRESSION")’
! ‘chain_circular ("EXPRESSION")’
  
       It's helpful for the type machinery to know if objects are often
       chained together in long lists; this lets it generate code that
       uses less stack space by iterating along the list instead of
!      recursing down it.  ‘chain_next’ is an expression for the next item
!      in the list, ‘chain_prev’ is an expression for the previous item.
!      For singly linked lists, use only ‘chain_next’; for doubly linked
       lists, use both.  The machinery requires that taking the next item
!      of the previous item gives the original item.  ‘chain_circular’ is
!      similar to ‘chain_next’, but can be used for circular single linked
       lists.
  
! ‘reorder ("FUNCTION NAME")’
  
       Some data structures depend on the relative ordering of pointers.
       If the precompiled header machinery needs to change that ordering,
!      it will call the function referenced by the ‘reorder’ option,
       before changing the pointers in the object that's pointed to by the
       field the option applies to.  The function must take four
       arguments, with the signature
!      ‘void *, void *, gt_pointer_operator, void *’.  The first parameter
       is a pointer to the structure that contains the object being
       updated, or the object itself if there is no containing structure.
       The second parameter is a cookie that should be ignored.  The third
*************** helpful when you have a complicated expr
*** 44998,45010 ****
       passed to the second parameter.
  
       PCH cannot handle data structures that depend on the absolute
!      values of pointers.  'reorder' functions can be expensive.  When
       possible, it is better to depend on properties of the data, like an
       ID number or the hash of a string instead.
  
! 'atomic'
  
!      The 'atomic' option can only be used with pointers.  It informs the
       GC machinery that the memory that the pointer points to does not
       contain any pointers, and hence it should be treated by the GC and
       PCH machinery as an "atomic" block of memory that does not need to
--- 44997,45009 ----
       passed to the second parameter.
  
       PCH cannot handle data structures that depend on the absolute
!      values of pointers.  ‘reorder’ functions can be expensive.  When
       possible, it is better to depend on properties of the data, like an
       ID number or the hash of a string instead.
  
! ‘atomic’
  
!      The ‘atomic’ option can only be used with pointers.  It informs the
       GC machinery that the memory that the pointer points to does not
       contain any pointers, and hence it should be treated by the GC and
       PCH machinery as an "atomic" block of memory that does not need to
*************** helpful when you have a complicated expr
*** 45013,45026 ****
       reachable (when marking pointers for GC) or to relocate them (when
       writing a PCH file).
  
!      The 'atomic' option differs from the 'skip' option.  'atomic' keeps
       the memory under Garbage Collection, but makes the GC ignore the
!      contents of the memory.  'skip' is more drastic in that it causes
       the pointer and the memory to be completely ignored by the Garbage
!      Collector.  So, memory marked as 'atomic' is automatically freed
!      when no longer reachable, while memory marked as 'skip' is not.
  
!      The 'atomic' option must be used with great care, because all sorts
       of problem can occur if used incorrectly, that is, if the memory
       the pointer points to does actually contain a pointer.
  
--- 45012,45025 ----
       reachable (when marking pointers for GC) or to relocate them (when
       writing a PCH file).
  
!      The ‘atomic’ option differs from the ‘skip’ option.  ‘atomic’ keeps
       the memory under Garbage Collection, but makes the GC ignore the
!      contents of the memory.  ‘skip’ is more drastic in that it causes
       the pointer and the memory to be completely ignored by the Garbage
!      Collector.  So, memory marked as ‘atomic’ is automatically freed
!      when no longer reachable, while memory marked as ‘skip’ is not.
  
!      The ‘atomic’ option must be used with great care, because all sorts
       of problem can occur if used incorrectly, that is, if the memory
       the pointer points to does actually contain a pointer.
  
*************** helpful when you have a complicated expr
*** 45029,45058 ****
              int number_of_elements;
              unsigned int * GTY ((atomic)) elements;
            };
!      In this case, 'elements' is a pointer under GC, and the memory it
       points to needs to be allocated using the Garbage Collector, and
       will be freed automatically by the Garbage Collector when it is no
       longer referenced.  But the memory that the pointer points to is an
!      array of 'unsigned int' elements, and the GC must not try to scan
       it to find pointers to mark or relocate, which is why it is marked
!      with the 'atomic' option.
  
       Note that, currently, global variables cannot be marked with
!      'atomic'; only fields of a struct can.  This is a known limitation.
!      It would be useful to be able to mark global pointers with 'atomic'
       to make the PCH machinery aware of them so that they are saved and
       restored correctly to PCH files.
  
! 'special ("NAME")'
  
!      The 'special' option is used to mark types that have to be dealt
       with by special case machinery.  The parameter is the name of the
!      special case.  See 'gengtype.cc' for further details.  Avoid adding
       new special cases unless there is no other alternative.
  
! 'user'
  
!      The 'user' option indicates that the code to mark structure fields
       is completely handled by user-provided routines.  See section *note
       User GC:: for details on what functions need to be provided.
  
--- 45028,45057 ----
              int number_of_elements;
              unsigned int * GTY ((atomic)) elements;
            };
!      In this case, ‘elements’ is a pointer under GC, and the memory it
       points to needs to be allocated using the Garbage Collector, and
       will be freed automatically by the Garbage Collector when it is no
       longer referenced.  But the memory that the pointer points to is an
!      array of ‘unsigned int’ elements, and the GC must not try to scan
       it to find pointers to mark or relocate, which is why it is marked
!      with the ‘atomic’ option.
  
       Note that, currently, global variables cannot be marked with
!      ‘atomic’; only fields of a struct can.  This is a known limitation.
!      It would be useful to be able to mark global pointers with ‘atomic’
       to make the PCH machinery aware of them so that they are saved and
       restored correctly to PCH files.
  
! ‘special ("NAME")’
  
!      The ‘special’ option is used to mark types that have to be dealt
       with by special case machinery.  The parameter is the name of the
!      special case.  See ‘gengtype.cc’ for further details.  Avoid adding
       new special cases unless there is no other alternative.
  
! ‘user’
  
!      The ‘user’ option indicates that the code to mark structure fields
       is completely handled by user-provided routines.  See section *note
       User GC:: for details on what functions need to be provided.
  
*************** File: gccint.info,  Node: Inheritance an
*** 45065,45075 ****
  gengtype has some support for simple class hierarchies.  You can use
  this to have gengtype autogenerate marking routines, provided:
  
!    * There must be a concrete base class, with a discriminator
       expression that can be used to identify which subclass an instance
       is.
!    * Only single inheritance is used.
!    * None of the classes within the hierarchy are templates.
  
   If your class hierarchy does not fit in this pattern, you must use
  *note User GC:: instead.
--- 45064,45074 ----
  gengtype has some support for simple class hierarchies.  You can use
  this to have gengtype autogenerate marking routines, provided:
  
!    • There must be a concrete base class, with a discriminator
       expression that can be used to identify which subclass an instance
       is.
!    • Only single inheritance is used.
!    • None of the classes within the hierarchy are templates.
  
   If your class hierarchy does not fit in this pattern, you must use
  *note User GC:: instead.
*************** this to have gengtype autogenerate marki
*** 45078,45084 ****
  "desc" option.  Each concrete subclass must use the "tag" option to
  identify which value of the discriminator it corresponds to.
  
!  Every class in the hierarchy must have a 'GTY(())' marker, as gengtype
  will only attempt to parse classes that have such a marker (1).
  
       class GTY((desc("%h.kind"), tag("0"))) example_base
--- 45077,45083 ----
  "desc" option.  Each concrete subclass must use the "tag" option to
  identify which value of the discriminator it corresponds to.
  
!  Every class in the hierarchy must have a ‘GTY(())’ marker, as gengtype
  will only attempt to parse classes that have such a marker (1).
  
       class GTY((desc("%h.kind"), tag("0"))) example_base
*************** is generated.  For these types, the user
*** 45122,45129 ****
  functions: one to act as a marker for garbage collection, and two
  functions to act as marker and pointer walker for pre-compiled headers.
  
!  Given a structure 'struct GTY((user)) my_struct', the following
! functions should be defined to mark 'my_struct':
  
       void gt_ggc_mx (my_struct *p)
       {
--- 45121,45128 ----
  functions: one to act as a marker for garbage collection, and two
  functions to act as marker and pointer walker for pre-compiled headers.
  
!  Given a structure ‘struct GTY((user)) my_struct’, the following
! functions should be defined to mark ‘my_struct’:
  
       void gt_ggc_mx (my_struct *p)
       {
*************** functions should be defined to mark 'my_
*** 45143,45170 ****
         op (&(tp->fld), NULL, cookie);
       }
  
!  In general, each marker 'M' should call 'M' for every pointer field in
  the structure.  Fields that are not allocated in GC or are not pointers
  must be ignored.
  
!  For embedded lists (e.g., structures with a 'next' or 'prev' pointer),
  the marker must follow the chain and mark every element in it.
  
!  Note that the rules for the pointer walker 'gt_pch_nx (my_struct *,
! gt_pointer_operator, void *)' are slightly different.  In this case, the
! operation 'op' must be applied to the _address_ of every pointer field.
  
  23.3.1 User-provided marking routines for template types
  --------------------------------------------------------
  
! When a template type 'TP' is marked with 'GTY', all instances of that
  type are considered user-provided types.  This means that the individual
! instances of 'TP' do not need to be marked with 'GTY'.  The user needs
  to provide template functions to mark all the fields of the type.
  
   The following code snippets represent all the functions that need to be
! provided.  Note that type 'TP' may reference to more than one type.  In
! these snippets, there is only one type 'T', but there could be more.
  
       template
       void gt_ggc_mx (TP *tp)
--- 45142,45169 ----
         op (&(tp->fld), NULL, cookie);
       }
  
!  In general, each marker ‘M’ should call ‘M’ for every pointer field in
  the structure.  Fields that are not allocated in GC or are not pointers
  must be ignored.
  
!  For embedded lists (e.g., structures with a ‘next’ or ‘prev’ pointer),
  the marker must follow the chain and mark every element in it.
  
!  Note that the rules for the pointer walker ‘gt_pch_nx (my_struct *,
! gt_pointer_operator, void *)’ are slightly different.  In this case, the
! operation ‘op’ must be applied to the _address_ of every pointer field.
  
  23.3.1 User-provided marking routines for template types
  --------------------------------------------------------
  
! When a template type ‘TP’ is marked with ‘GTY’, all instances of that
  type are considered user-provided types.  This means that the individual
! instances of ‘TP’ do not need to be marked with ‘GTY’.  The user needs
  to provide template functions to mark all the fields of the type.
  
   The following code snippets represent all the functions that need to be
! provided.  Note that type ‘TP’ may reference to more than one type.  In
! these snippets, there is only one type ‘T’, but there could be more.
  
       template
       void gt_ggc_mx (TP *tp)
*************** these snippets, there is only one type '
*** 45205,45219 ****
   Support for user-defined types is currently limited.  The following
  restrictions apply:
  
!   1. Type 'TP' and all the argument types 'T' must be marked with 'GTY'.
  
!   2. Type 'TP' can only have type names in its argument list.
  
!   3. The pointer walker functions are different for 'TP' and 'TP'.  In the case of 'TP', references to 'T' must be handled by
!      calling 'gt_pch_nx' (which will, in turn, walk all the pointers
!      inside fields of 'T').  In the case of 'TP', references to 'T
!      *' must be handled by calling the 'op' function on the address of
       the pointer (see the code snippets above).
  
  
--- 45204,45218 ----
   Support for user-defined types is currently limited.  The following
  restrictions apply:
  
!   1. Type ‘TP’ and all the argument types ‘T’ must be marked with ‘GTY’.
  
!   2. Type ‘TP’ can only have type names in its argument list.
  
!   3. The pointer walker functions are different for ‘TP’ and ‘TP’.  In the case of ‘TP’, references to ‘T’ must be handled by
!      calling ‘gt_pch_nx’ (which will, in turn, walk all the pointers
!      inside fields of ‘T’).  In the case of ‘TP’, references to ‘T
!      *’ must be handled by calling the ‘op’ function on the address of
       the pointer (see the code snippets above).
  
  
*************** File: gccint.info,  Node: GGC Roots,  Ne
*** 45223,45238 ****
  ============================================
  
  In addition to keeping track of types, the type machinery also locates
! the global variables ("roots") that the garbage collector starts at.
  Roots must be declared using one of the following syntaxes:
  
!    * 'extern GTY(([OPTIONS])) TYPE NAME;'
!    * 'static GTY(([OPTIONS])) TYPE NAME;'
  The syntax
!    * 'GTY(([OPTIONS])) TYPE NAME;'
! is _not_ accepted.  There should be an 'extern' declaration of such a
  variable in a header somewhere--mark that, not the definition.  Or, if
! the variable is only used in one file, make it 'static'.
  
  
  File: gccint.info,  Node: Files,  Next: Invoking the garbage collector,  Prev: GGC Roots,  Up: Type Information
--- 45222,45237 ----
  ============================================
  
  In addition to keeping track of types, the type machinery also locates
! the global variables (“roots”) that the garbage collector starts at.
  Roots must be declared using one of the following syntaxes:
  
!    • ‘extern GTY(([OPTIONS])) TYPE NAME;’
!    • ‘static GTY(([OPTIONS])) TYPE NAME;’
  The syntax
!    • ‘GTY(([OPTIONS])) TYPE NAME;’
! is _not_ accepted.  There should be an ‘extern’ declaration of such a
  variable in a header somewhere--mark that, not the definition.  Or, if
! the variable is only used in one file, make it ‘static’.
  
  
  File: gccint.info,  Node: Files,  Next: Invoking the garbage collector,  Prev: GGC Roots,  Up: Type Information
*************** File: gccint.info,  Node: Files,  Next:
*** 45240,45291 ****
  23.5 Source Files Containing Type Information
  =============================================
  
! Whenever you add 'GTY' markers to a source file that previously had
! none, or create a new source file containing 'GTY' markers, there are
  three things you need to do:
  
    1. You need to add the file to the list of source files the type
       machinery scans.  There are four cases:
  
         a. For a back-end file, this is usually done automatically; if
!           not, you should add it to 'target_gtfiles' in the appropriate
!           port's entries in 'config.gcc'.
  
         b. For files shared by all front ends, add the filename to the
!           'GTFILES' variable in 'Makefile.in'.
  
         c. For files that are part of one front end, add the filename to
!           the 'gtfiles' variable defined in the appropriate
!           'config-lang.in'.  Headers should appear before non-headers in
            this list.
  
         d. For files that are part of some but not all front ends, add
!           the filename to the 'gtfiles' variable of _all_ the front ends
            that use it.
  
    2. If the file was a header file, you'll need to check that it's
       included in the right place to be visible to the generated files.
       For a back-end header file, this should be done automatically.  For
       a front-end header file, it needs to be included by the same file
!      that includes 'gtype-LANG.h'.  For other header files, it needs to
!      be included in 'gtype-desc.cc', which is a generated file, so add
!      it to 'ifiles' in 'open_base_file' in 'gengtype.cc'.
  
       For source files that aren't header files, the machinery will
       generate a header file that should be included in the source file
!      you just changed.  The file will be called 'gt-PATH.h' where PATH
!      is the pathname relative to the 'gcc' directory with slashes
       replaced by -, so for example the header file to be included in
!      'cp/parser.cc' is called 'gt-cp-parser.h'.  The generated header
       file should be included after everything else in the source file.
  
   For language frontends, there is another file that needs to be included
! somewhere.  It will be called 'gtype-LANG.h', where LANG is the name of
  the subdirectory the language is contained in.
  
!  Plugins can add additional root tables.  Run the 'gengtype' utility in
! plugin mode as 'gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C'
! with your plugin files PLUGIN*.C using 'GTY' to generate the PLUGINOUT.H
  file.  The GCC build tree is needed to be present in that mode.
  
  
--- 45239,45290 ----
  23.5 Source Files Containing Type Information
  =============================================
  
! Whenever you add ‘GTY’ markers to a source file that previously had
! none, or create a new source file containing ‘GTY’ markers, there are
  three things you need to do:
  
    1. You need to add the file to the list of source files the type
       machinery scans.  There are four cases:
  
         a. For a back-end file, this is usually done automatically; if
!           not, you should add it to ‘target_gtfiles’ in the appropriate
!           port's entries in ‘config.gcc’.
  
         b. For files shared by all front ends, add the filename to the
!           ‘GTFILES’ variable in ‘Makefile.in’.
  
         c. For files that are part of one front end, add the filename to
!           the ‘gtfiles’ variable defined in the appropriate
!           ‘config-lang.in’.  Headers should appear before non-headers in
            this list.
  
         d. For files that are part of some but not all front ends, add
!           the filename to the ‘gtfiles’ variable of _all_ the front ends
            that use it.
  
    2. If the file was a header file, you'll need to check that it's
       included in the right place to be visible to the generated files.
       For a back-end header file, this should be done automatically.  For
       a front-end header file, it needs to be included by the same file
!      that includes ‘gtype-LANG.h’.  For other header files, it needs to
!      be included in ‘gtype-desc.cc’, which is a generated file, so add
!      it to ‘ifiles’ in ‘open_base_file’ in ‘gengtype.cc’.
  
       For source files that aren't header files, the machinery will
       generate a header file that should be included in the source file
!      you just changed.  The file will be called ‘gt-PATH.h’ where PATH
!      is the pathname relative to the ‘gcc’ directory with slashes
       replaced by -, so for example the header file to be included in
!      ‘cp/parser.cc’ is called ‘gt-cp-parser.h’.  The generated header
       file should be included after everything else in the source file.
  
   For language frontends, there is another file that needs to be included
! somewhere.  It will be called ‘gtype-LANG.h’, where LANG is the name of
  the subdirectory the language is contained in.
  
!  Plugins can add additional root tables.  Run the ‘gengtype’ utility in
! plugin mode as ‘gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C’
! with your plugin files PLUGIN*.C using ‘GTY’ to generate the PLUGINOUT.H
  file.  The GCC build tree is needed to be present in that mode.
  
  
*************** File: gccint.info,  Node: Invoking the g
*** 45297,45317 ****
  The GCC garbage collector GGC is only invoked explicitly.  In contrast
  with many other garbage collectors, it is not implicitly invoked by
  allocation routines when a lot of memory has been consumed.  So the only
! way to have GGC reclaim storage is to call the 'ggc_collect' function
! explicitly.  With MODE 'GGC_COLLECT_FORCE' or otherwise (default
! 'GGC_COLLECT_HEURISTIC') when the internal heuristic decides to collect,
  this call is potentially an expensive operation, as it may have to scan
  the entire heap.  Beware that local variables (on the GCC call stack)
  are not followed by such an invocation (as many other garbage collectors
! do): you should reference all your data from static or external 'GTY'-ed
! variables, and it is advised to call 'ggc_collect' with a shallow call
  stack.  The GGC is an exact mark and sweep garbage collector (so it does
  not scan the call stack for pointers).  In practice GCC passes don't
! often call 'ggc_collect' themselves, because it is called by the pass
  manager between passes.
  
!  At the time of the 'ggc_collect' call all pointers in the GC-marked
! structures must be valid or 'NULL'.  In practice this means that there
  should not be uninitialized pointer fields in the structures even if
  your code never reads or writes those fields at a particular instance.
  One way to ensure this is to use cleared versions of allocators unless
--- 45296,45316 ----
  The GCC garbage collector GGC is only invoked explicitly.  In contrast
  with many other garbage collectors, it is not implicitly invoked by
  allocation routines when a lot of memory has been consumed.  So the only
! way to have GGC reclaim storage is to call the ‘ggc_collect’ function
! explicitly.  With MODE ‘GGC_COLLECT_FORCE’ or otherwise (default
! ‘GGC_COLLECT_HEURISTIC’) when the internal heuristic decides to collect,
  this call is potentially an expensive operation, as it may have to scan
  the entire heap.  Beware that local variables (on the GCC call stack)
  are not followed by such an invocation (as many other garbage collectors
! do): you should reference all your data from static or external ‘GTY’-ed
! variables, and it is advised to call ‘ggc_collect’ with a shallow call
  stack.  The GGC is an exact mark and sweep garbage collector (so it does
  not scan the call stack for pointers).  In practice GCC passes don't
! often call ‘ggc_collect’ themselves, because it is called by the pass
  manager between passes.
  
!  At the time of the ‘ggc_collect’ call all pointers in the GC-marked
! structures must be valid or ‘NULL’.  In practice this means that there
  should not be uninitialized pointer fields in the structures even if
  your code never reads or writes those fields at a particular instance.
  One way to ensure this is to use cleared versions of allocators unless
*************** With the current garbage collector imple
*** 45327,45344 ****
  show up as GCC compilation errors.  Some of the most commonly
  encountered issues are described below.
  
!    * Gengtype does not produce allocators for a 'GTY'-marked type.
       Gengtype checks if there is at least one possible path from GC
       roots to at least one instance of each type before outputting
!      allocators.  If there is no such path, the 'GTY' markers will be
       ignored and no allocators will be output.  Solve this by making
       sure that there exists at least one such path.  If creating it is
       unfeasible or raises a "code smell", consider if you really must
       use GC for allocating such type.
  
!    * Link-time errors about undefined 'gt_ggc_r_foo_bar' and
!      similarly-named symbols.  Check if your 'foo_bar' source file has
!      '#include "gt-foo_bar.h"' as its very last line.
  
  
  File: gccint.info,  Node: Plugins,  Next: LTO,  Prev: Type Information,  Up: Top
--- 45326,45343 ----
  show up as GCC compilation errors.  Some of the most commonly
  encountered issues are described below.
  
!    • Gengtype does not produce allocators for a ‘GTY’-marked type.
       Gengtype checks if there is at least one possible path from GC
       roots to at least one instance of each type before outputting
!      allocators.  If there is no such path, the ‘GTY’ markers will be
       ignored and no allocators will be output.  Solve this by making
       sure that there exists at least one such path.  If creating it is
       unfeasible or raises a "code smell", consider if you really must
       use GC for allocating such type.
  
!    • Link-time errors about undefined ‘gt_ggc_r_foo_bar’ and
!      similarly-named symbols.  Check if your ‘foo_bar’ source file has
!      ‘#include "gt-foo_bar.h"’ as its very last line.
  
  
  File: gccint.info,  Node: Plugins,  Next: LTO,  Prev: Type Information,  Up: Top
*************** File: gccint.info,  Node: Plugins loadin
*** 45374,45400 ****
  24.1 Loading Plugins
  ====================
  
! Plugins are supported on platforms that support '-ldl -rdynamic' as well
! as Windows/MinGW. They are loaded by the compiler using 'dlopen' or
  equivalent and invoked at pre-determined locations in the compilation
  process.
  
   Plugins are loaded with
  
!  '-fplugin=/path/to/NAME.EXT' '-fplugin-arg-NAME-KEY1[=VALUE1]'
  
   Where NAME is the plugin name and EXT is the platform-specific dynamic
! library extension.  It should be 'dll' on Windows/MinGW, 'dylib' on
! Darwin/Mac OS X, and 'so' on all other platforms.  The plugin arguments
  are parsed by GCC and passed to respective plugins as key-value pairs.
! Multiple plugins can be invoked by specifying multiple '-fplugin'
  arguments.
  
   A plugin can be simply given by its short name (no dots or slashes).
! When simply passing '-fplugin=NAME', the plugin is loaded from the
! 'plugin' directory, so '-fplugin=NAME' is the same as '-fplugin=`gcc
! -print-file-name=plugin`/NAME.EXT', using backquote shell syntax to
! query the 'plugin' directory.
  
  
  File: gccint.info,  Node: Plugin API,  Next: Plugins pass,  Prev: Plugins loading,  Up: Plugins
--- 45373,45399 ----
  24.1 Loading Plugins
  ====================
  
! Plugins are supported on platforms that support ‘-ldl -rdynamic’ as well
! as Windows/MinGW. They are loaded by the compiler using ‘dlopen’ or
  equivalent and invoked at pre-determined locations in the compilation
  process.
  
   Plugins are loaded with
  
!  ‘-fplugin=/path/to/NAME.EXT’ ‘-fplugin-arg-NAME-KEY1[=VALUE1]’
  
   Where NAME is the plugin name and EXT is the platform-specific dynamic
! library extension.  It should be ‘dll’ on Windows/MinGW, ‘dylib’ on
! Darwin/Mac OS X, and ‘so’ on all other platforms.  The plugin arguments
  are parsed by GCC and passed to respective plugins as key-value pairs.
! Multiple plugins can be invoked by specifying multiple ‘-fplugin’
  arguments.
  
   A plugin can be simply given by its short name (no dots or slashes).
! When simply passing ‘-fplugin=NAME’, the plugin is loaded from the
! ‘plugin’ directory, so ‘-fplugin=NAME’ is the same as ‘-fplugin=`gcc
! -print-file-name=plugin`/NAME.EXT’, using backquote shell syntax to
! query the ‘plugin’ directory.
  
  
  File: gccint.info,  Node: Plugin API,  Next: Plugins pass,  Prev: Plugins loading,  Up: Plugins
*************** File: gccint.info,  Node: Plugin API,  N
*** 45403,45418 ****
  ===============
  
  Plugins are activated by the compiler at specific events as defined in
! 'gcc-plugin.h'.  For each event of interest, the plugin should call
! 'register_callback' specifying the name of the event and address of the
  callback function that will handle that event.
  
!  The header 'gcc-plugin.h' must be the first gcc header to be included.
  
  24.2.1 Plugin license check
  ---------------------------
  
! Every plugin should define the global symbol 'plugin_is_GPL_compatible'
  to assert that it has been licensed under a GPL-compatible license.  If
  this symbol does not exist, the compiler will emit a fatal error and
  exit with the error message:
--- 45402,45417 ----
  ===============
  
  Plugins are activated by the compiler at specific events as defined in
! ‘gcc-plugin.h’.  For each event of interest, the plugin should call
! ‘register_callback’ specifying the name of the event and address of the
  callback function that will handle that event.
  
!  The header ‘gcc-plugin.h’ must be the first gcc header to be included.
  
  24.2.1 Plugin license check
  ---------------------------
  
! Every plugin should define the global symbol ‘plugin_is_GPL_compatible’
  to assert that it has been licensed under a GPL-compatible license.  If
  this symbol does not exist, the compiler will emit a fatal error and
  exit with the error message:
*************** exit with the error message:
*** 45422,45428 ****
       compilation terminated
  
   The declared type of the symbol should be int, to match a forward
! declaration in 'gcc-plugin.h' that suppresses C++ mangling.  It does not
  need to be in any allocated section, though.  The compiler merely
  asserts that the symbol exists in the global scope.  Something like this
  is enough:
--- 45421,45427 ----
       compilation terminated
  
   The declared type of the symbol should be int, to match a forward
! declaration in ‘gcc-plugin.h’ that suppresses C++ mangling.  It does not
  need to be in any allocated section, though.  The compiler merely
  asserts that the symbol exists in the global scope.  Something like this
  is enough:
*************** is enough:
*** 45432,45449 ****
  24.2.2 Plugin initialization
  ----------------------------
  
! Every plugin should export a function called 'plugin_init' that is
  called right after the plugin is loaded.  This function is responsible
  for registering all the callbacks required by the plugin and do any
  other required initialization.
  
!  This function is called from 'compile_file' right before invoking the
! parser.  The arguments to 'plugin_init' are:
  
!    * 'plugin_info': Plugin invocation information.
!    * 'version': GCC version.
  
!  The 'plugin_info' struct is defined as follows:
  
       struct plugin_name_args
       {
--- 45431,45448 ----
  24.2.2 Plugin initialization
  ----------------------------
  
! Every plugin should export a function called ‘plugin_init’ that is
  called right after the plugin is loaded.  This function is responsible
  for registering all the callbacks required by the plugin and do any
  other required initialization.
  
!  This function is called from ‘compile_file’ right before invoking the
! parser.  The arguments to ‘plugin_init’ are:
  
!    • ‘plugin_info’: Plugin invocation information.
!    • ‘version’: GCC version.
  
!  The ‘plugin_info’ struct is defined as follows:
  
       struct plugin_name_args
       {
*************** parser.  The arguments to 'plugin_init'
*** 45458,45464 ****
         const char *help;             /* Help string provided by plugin. */
       }
  
!  If initialization fails, 'plugin_init' must return a non-zero value.
  Otherwise, it should return 0.
  
   The version of the GCC compiler loading the plugin is described by the
--- 45457,45463 ----
         const char *help;             /* Help string provided by plugin. */
       }
  
!  If initialization fails, ‘plugin_init’ must return a non-zero value.
  Otherwise, it should return 0.
  
   The version of the GCC compiler loading the plugin is described by the
*************** following structure:
*** 45473,45484 ****
         const char *configuration_arguments;
       };
  
!  The function 'plugin_default_version_check' takes two pointers to such
  structure and compare them field by field.  It can be used by the
! plugin's 'plugin_init' function.
  
   The version of GCC used to compile the plugin can be found in the
! symbol 'gcc_version' defined in the header 'plugin-version.h'.  The
  recommended version check to perform looks like
  
       #include "plugin-version.h"
--- 45472,45483 ----
         const char *configuration_arguments;
       };
  
!  The function ‘plugin_default_version_check’ takes two pointers to such
  structure and compare them field by field.  It can be used by the
! plugin's ‘plugin_init’ function.
  
   The version of GCC used to compile the plugin can be found in the
! symbol ‘gcc_version’ defined in the header ‘plugin-version.h’.  The
  recommended version check to perform looks like
  
       #include "plugin-version.h"
*************** Callback functions have the following pr
*** 45561,45591 ****
  
   In addition, plugins can also look up the enumerator of a named event,
  and / or generate new events dynamically, by calling the function
! 'get_named_event_id'.
  
!  To register a callback, the plugin calls 'register_callback' with the
  arguments:
  
!    * 'char *name': Plugin name.
!    * 'int event': The event code.
!    * 'plugin_callback_func callback': The function that handles 'event'.
!    * 'void *user_data': Pointer to plugin-specific data.
  
   For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, and
! PLUGIN_REGISTER_GGC_ROOTS pseudo-events the 'callback' should be null,
! and the 'user_data' is specific.
  
   When the PLUGIN_PRAGMAS event is triggered (with a null pointer as data
  from GCC), plugins may register their own pragmas.  Notice that pragmas
! are not available from 'lto1', so plugins used with '-flto' option to
  GCC during link-time optimization cannot use pragmas and do not even see
! functions like 'c_register_pragma' or 'pragma_lex'.
  
!  The PLUGIN_INCLUDE_FILE event, with a 'const char*' file path as GCC
! data, is triggered for processing of '#include' or '#line' directives.
  
   The PLUGIN_FINISH event is the last time that plugins can call GCC
! functions, notably emit diagnostics with 'warning', 'error' etc.
  
  
  File: gccint.info,  Node: Plugins pass,  Next: Plugins GC,  Prev: Plugin API,  Up: Plugins
--- 45560,45590 ----
  
   In addition, plugins can also look up the enumerator of a named event,
  and / or generate new events dynamically, by calling the function
! ‘get_named_event_id’.
  
!  To register a callback, the plugin calls ‘register_callback’ with the
  arguments:
  
!    • ‘char *name’: Plugin name.
!    • ‘int event’: The event code.
!    • ‘plugin_callback_func callback’: The function that handles ‘event’.
!    • ‘void *user_data’: Pointer to plugin-specific data.
  
   For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO, and
! PLUGIN_REGISTER_GGC_ROOTS pseudo-events the ‘callback’ should be null,
! and the ‘user_data’ is specific.
  
   When the PLUGIN_PRAGMAS event is triggered (with a null pointer as data
  from GCC), plugins may register their own pragmas.  Notice that pragmas
! are not available from ‘lto1’, so plugins used with ‘-flto’ option to
  GCC during link-time optimization cannot use pragmas and do not even see
! functions like ‘c_register_pragma’ or ‘pragma_lex’.
  
!  The PLUGIN_INCLUDE_FILE event, with a ‘const char*’ file path as GCC
! data, is triggered for processing of ‘#include’ or ‘#line’ directives.
  
   The PLUGIN_FINISH event is the last time that plugins can call GCC
! functions, notably emit diagnostics with ‘warning’, ‘error’ etc.
  
  
  File: gccint.info,  Node: Plugins pass,  Next: Plugins GC,  Prev: Plugin API,  Up: Plugins
*************** such as CFG or an IPA pass) and optimiza
*** 45599,45606 ****
  
   Basic support for inserting new passes or replacing existing passes is
  provided.  A plugin registers a new pass with GCC by calling
! 'register_callback' with the 'PLUGIN_PASS_MANAGER_SETUP' event and a
! pointer to a 'struct register_pass_info' object defined as follows
  
       enum pass_positioning_ops
       {
--- 45598,45605 ----
  
   Basic support for inserting new passes or replacing existing passes is
  provided.  A plugin registers a new pass with GCC by calling
! ‘register_callback’ with the ‘PLUGIN_PASS_MANAGER_SETUP’ event and a
! pointer to a ‘struct register_pass_info’ object defined as follows
  
       enum pass_positioning_ops
       {
*************** File: gccint.info,  Node: Plugins GC,  N
*** 45648,45678 ****
  
  Some plugins may want to be informed when GGC (the GCC Garbage
  Collector) is running.  They can register callbacks for the
! 'PLUGIN_GGC_START' and 'PLUGIN_GGC_END' events (for which the callback
! is called with a null 'gcc_data') to be notified of the start or end of
  the GCC garbage collection.
  
   Some plugins may need to have GGC mark additional data.  This can be
! done by registering a callback (called with a null 'gcc_data') for the
! 'PLUGIN_GGC_MARKING' event.  Such callbacks can call the 'ggc_set_mark'
! routine, preferably through the 'ggc_mark' macro (and conversely, these
  routines should usually not be used in plugins outside of the
! 'PLUGIN_GGC_MARKING' event).  Plugins that wish to hold weak references
  to gc data may also use this event to drop weak references when the
! object is about to be collected.  The 'ggc_marked_p' function can be
  used to tell if an object is marked, or is about to be collected.  The
! 'gt_clear_cache' overloads which some types define may also be of use in
  managing weak references.
  
   Some plugins may need to add extra GGC root tables, e.g. to handle
! their own 'GTY'-ed data.  This can be done with the
! 'PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the
! extra root table (of type 'struct ggc_root_tab*') as 'user_data'.
! Running the 'gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility
  generates these extra root tables.
  
   You should understand the details of memory management inside GCC
! before using 'PLUGIN_GGC_MARKING' or 'PLUGIN_REGISTER_GGC_ROOTS'.
  
  
  File: gccint.info,  Node: Plugins description,  Next: Plugins attr,  Prev: Plugins GC,  Up: Plugins
--- 45647,45677 ----
  
  Some plugins may want to be informed when GGC (the GCC Garbage
  Collector) is running.  They can register callbacks for the
! ‘PLUGIN_GGC_START’ and ‘PLUGIN_GGC_END’ events (for which the callback
! is called with a null ‘gcc_data’) to be notified of the start or end of
  the GCC garbage collection.
  
   Some plugins may need to have GGC mark additional data.  This can be
! done by registering a callback (called with a null ‘gcc_data’) for the
! ‘PLUGIN_GGC_MARKING’ event.  Such callbacks can call the ‘ggc_set_mark’
! routine, preferably through the ‘ggc_mark’ macro (and conversely, these
  routines should usually not be used in plugins outside of the
! ‘PLUGIN_GGC_MARKING’ event).  Plugins that wish to hold weak references
  to gc data may also use this event to drop weak references when the
! object is about to be collected.  The ‘ggc_marked_p’ function can be
  used to tell if an object is marked, or is about to be collected.  The
! ‘gt_clear_cache’ overloads which some types define may also be of use in
  managing weak references.
  
   Some plugins may need to add extra GGC root tables, e.g. to handle
! their own ‘GTY’-ed data.  This can be done with the
! ‘PLUGIN_REGISTER_GGC_ROOTS’ pseudo-event with a null callback and the
! extra root table (of type ‘struct ggc_root_tab*’) as ‘user_data’.
! Running the ‘gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...’ utility
  generates these extra root tables.
  
   You should understand the details of memory management inside GCC
! before using ‘PLUGIN_GGC_MARKING’ or ‘PLUGIN_REGISTER_GGC_ROOTS’.
  
  
  File: gccint.info,  Node: Plugins description,  Next: Plugins attr,  Prev: Plugins GC,  Up: Plugins
*************** uses the following structure:
*** 45689,45696 ****
         const char *help;
       };
  
!  Such a structure is passed as the 'user_data' by the plugin's init
! routine using 'register_callback' with the 'PLUGIN_INFO' pseudo-event
  and a null callback.
  
  
--- 45688,45695 ----
         const char *help;
       };
  
!  Such a structure is passed as the ‘user_data’ by the plugin's init
! routine using ‘register_callback’ with the ‘PLUGIN_INFO’ pseudo-event
  and a null callback.
  
  
*************** File: gccint.info,  Node: Plugins attr,
*** 45702,45709 ****
  For analysis (or other) purposes it is useful to be able to add custom
  attributes or pragmas.
  
!  The 'PLUGIN_ATTRIBUTES' callback is called during attribute
! registration.  Use the 'register_attribute' function to register custom
  attributes.
  
       /* Attribute handler callback */
--- 45701,45708 ----
  For analysis (or other) purposes it is useful to be able to add custom
  attributes or pragmas.
  
!  The ‘PLUGIN_ATTRIBUTES’ callback is called during attribute
! registration.  Use the ‘register_attribute’ function to register custom
  attributes.
  
       /* Attribute handler callback */
*************** attributes.
*** 45730,45740 ****
  
  
   The PLUGIN_PRAGMAS callback is called once during pragmas registration.
! Use the 'c_register_pragma', 'c_register_pragma_with_data',
! 'c_register_pragma_with_expansion',
! 'c_register_pragma_with_expansion_and_data' functions to register custom
! pragmas and their handlers (which often want to call 'pragma_lex') from
! 'c-family/c-pragma.h'.
  
       /* Plugin callback called during pragmas registration. Registered with
            register_callback (plugin_name, PLUGIN_PRAGMAS,
--- 45729,45739 ----
  
  
   The PLUGIN_PRAGMAS callback is called once during pragmas registration.
! Use the ‘c_register_pragma’, ‘c_register_pragma_with_data’,
! ‘c_register_pragma_with_expansion’,
! ‘c_register_pragma_with_expansion_and_data’ functions to register custom
! pragmas and their handlers (which often want to call ‘pragma_lex’) from
! ‘c-family/c-pragma.h’.
  
       /* Plugin callback called during pragmas registration. Registered with
            register_callback (plugin_name, PLUGIN_PRAGMAS,
*************** pragmas and their handlers (which often
*** 45747,45757 ****
         c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello);
       }
  
!  It is suggested to pass '"GCCPLUGIN"' (or a short name identifying your
  plugin) as the "space" argument of your pragma.
  
!  Pragmas registered with 'c_register_pragma_with_expansion' or
! 'c_register_pragma_with_expansion_and_data' support preprocessor
  expansions.  For example:
  
       #define NUMBER 10
--- 45746,45756 ----
         c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello);
       }
  
!  It is suggested to pass ‘"GCCPLUGIN"’ (or a short name identifying your
  plugin) as the "space" argument of your pragma.
  
!  Pragmas registered with ‘c_register_pragma_with_expansion’ or
! ‘c_register_pragma_with_expansion_and_data’ support preprocessor
  expansions.  For example:
  
       #define NUMBER 10
*************** File: gccint.info,  Node: Plugins record
*** 45764,45777 ****
  ===============================================
  
  The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass
! (the same as current_pass) as 'gcc_data' to the callback.  You can also
  inspect cfun to find out about which function this pass is executed for.
  Note that this event will only be invoked if the gate check (if
  applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds.  You can use
! other hooks, like 'PLUGIN_ALL_PASSES_START', 'PLUGIN_ALL_PASSES_END',
! 'PLUGIN_ALL_IPA_PASSES_START', 'PLUGIN_ALL_IPA_PASSES_END',
! 'PLUGIN_EARLY_GIMPLE_PASSES_START', and/or
! 'PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your
  plugin(s) in order to get context for the pass execution.
  
  
--- 45763,45776 ----
  ===============================================
  
  The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass
! (the same as current_pass) as ‘gcc_data’ to the callback.  You can also
  inspect cfun to find out about which function this pass is executed for.
  Note that this event will only be invoked if the gate check (if
  applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds.  You can use
! other hooks, like ‘PLUGIN_ALL_PASSES_START’, ‘PLUGIN_ALL_PASSES_END’,
! ‘PLUGIN_ALL_IPA_PASSES_START’, ‘PLUGIN_ALL_IPA_PASSES_END’,
! ‘PLUGIN_EARLY_GIMPLE_PASSES_START’, and/or
! ‘PLUGIN_EARLY_GIMPLE_PASSES_END’ to manipulate global state in your
  plugin(s) in order to get context for the pass execution.
  
  
*************** File: gccint.info,  Node: Plugins gate,
*** 45782,45789 ****
  
  After the original gate function for a pass is called, its result - the
  gate status - is stored as an integer.  Then the event
! 'PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in
! the 'gcc_data' parameter to the callback function.  A nonzero value of
  the gate status means that the pass is to be executed.  You can both
  read and write the gate status via the passed pointer.
  
--- 45781,45788 ----
  
  After the original gate function for a pass is called, its result - the
  gate status - is stored as an integer.  Then the event
! ‘PLUGIN_OVERRIDE_GATE’ is invoked, with a pointer to the gate status in
! the ‘gcc_data’ parameter to the callback function.  A nonzero value of
  the gate status means that the pass is to be executed.  You can both
  read and write the gate status via the passed pointer.
  
*************** When your plugin is loaded, you can insp
*** 45797,45804 ****
  determine what passes are available.  However, other plugins might add
  new passes.  Also, future changes to GCC might cause generic passes to
  be added after plugin loading.  When a pass is first added to one of the
! pass lists, the event 'PLUGIN_NEW_PASS' is invoked, with the callback
! parameter 'gcc_data' pointing to the new pass.
  
  
  File: gccint.info,  Node: Plugins building,  Prev: Plugins tracking,  Up: Plugins
--- 45796,45803 ----
  determine what passes are available.  However, other plugins might add
  new passes.  Also, future changes to GCC might cause generic passes to
  be added after plugin loading.  When a pass is first added to one of the
! pass lists, the event ‘PLUGIN_NEW_PASS’ is invoked, with the callback
! parameter ‘gcc_data’ pointing to the new pass.
  
  
  File: gccint.info,  Node: Plugins building,  Prev: Plugins tracking,  Up: Plugins
*************** File: gccint.info,  Node: Plugins buildi
*** 45807,45827 ****
  ==========================
  
  If plugins are enabled, GCC installs the headers needed to build a
! plugin (somewhere in the installation tree, e.g. under '/usr/local').
! In particular a 'plugin/include' directory is installed, containing all
  the header files needed to build plugins.
  
!  On most systems, you can query this 'plugin' directory by invoking 'gcc
! -print-file-name=plugin' (replace if needed 'gcc' with the appropriate
  program path).
  
!  Inside plugins, this 'plugin' directory name can be queried by calling
! 'default_plugin_dir_name ()'.
  
   Plugins may know, when they are compiled, the GCC version for which
! 'plugin-version.h' is provided.  The constant macros
! 'GCCPLUGIN_VERSION_MAJOR', 'GCCPLUGIN_VERSION_MINOR',
! 'GCCPLUGIN_VERSION_PATCHLEVEL', 'GCCPLUGIN_VERSION' are integer numbers,
  so a plugin could ensure it is built for GCC 4.7 with
       #if GCCPLUGIN_VERSION != 4007
       #error this GCC plugin is for GCC 4.7
--- 45806,45826 ----
  ==========================
  
  If plugins are enabled, GCC installs the headers needed to build a
! plugin (somewhere in the installation tree, e.g. under ‘/usr/local’).
! In particular a ‘plugin/include’ directory is installed, containing all
  the header files needed to build plugins.
  
!  On most systems, you can query this ‘plugin’ directory by invoking ‘gcc
! -print-file-name=plugin’ (replace if needed ‘gcc’ with the appropriate
  program path).
  
!  Inside plugins, this ‘plugin’ directory name can be queried by calling
! ‘default_plugin_dir_name ()’.
  
   Plugins may know, when they are compiled, the GCC version for which
! ‘plugin-version.h’ is provided.  The constant macros
! ‘GCCPLUGIN_VERSION_MAJOR’, ‘GCCPLUGIN_VERSION_MINOR’,
! ‘GCCPLUGIN_VERSION_PATCHLEVEL’, ‘GCCPLUGIN_VERSION’ are integer numbers,
  so a plugin could ensure it is built for GCC 4.7 with
       #if GCCPLUGIN_VERSION != 4007
       #error this GCC plugin is for GCC 4.7
*************** so a plugin could ensure it is built for
*** 45838,45852 ****
       plugin.so: $(PLUGIN_SOURCE_FILES)
          $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@
  
!  A single source file plugin may be built with 'g++ -I`gcc
  -print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.cc
! -o plugin.so', using backquote shell syntax to query the 'plugin'
  directory.
  
   Plugin support on Windows/MinGW has a number of limitations and
  additional requirements.  When building a plugin on Windows we have to
  link an import library for the corresponding backend executable, for
! example, 'cc1.exe', 'cc1plus.exe', etc., in order to gain access to the
  symbols provided by GCC. This means that on Windows a plugin is
  language-specific, for example, for C, C++, etc.  If you wish to use
  your plugin with multiple languages, then you will need to build
--- 45837,45851 ----
       plugin.so: $(PLUGIN_SOURCE_FILES)
          $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@
  
!  A single source file plugin may be built with ‘g++ -I`gcc
  -print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.cc
! -o plugin.so’, using backquote shell syntax to query the ‘plugin’
  directory.
  
   Plugin support on Windows/MinGW has a number of limitations and
  additional requirements.  When building a plugin on Windows we have to
  link an import library for the corresponding backend executable, for
! example, ‘cc1.exe’, ‘cc1plus.exe’, etc., in order to gain access to the
  symbols provided by GCC. This means that on Windows a plugin is
  language-specific, for example, for C, C++, etc.  If you wish to use
  your plugin with multiple languages, then you will need to build
*************** the correct version or provide a compile
*** 45855,45865 ****
  automatically.
  
   Additionally, on Windows the plugin library has to export the
! 'plugin_is_GPL_compatible' and 'plugin_init' symbols.  If you do not
  wish to modify the source code of your plugin, then you can use the
! '-Wl,--export-all-symbols' option or provide a suitable DEF file.
  Alternatively, you can export just these two symbols by decorating them
! with '__declspec(dllexport)', for example:
  
       #ifdef _WIN32
       __declspec(dllexport)
--- 45854,45864 ----
  automatically.
  
   Additionally, on Windows the plugin library has to export the
! ‘plugin_is_GPL_compatible’ and ‘plugin_init’ symbols.  If you do not
  wish to modify the source code of your plugin, then you can use the
! ‘-Wl,--export-all-symbols’ option or provide a suitable DEF file.
  Alternatively, you can export just these two symbols by decorating them
! with ‘__declspec(dllexport)’, for example:
  
       #ifdef _WIN32
       __declspec(dllexport)
*************** with '__declspec(dllexport)', for exampl
*** 45871,45887 ****
       #endif
       int plugin_init (plugin_name_args *, plugin_gcc_version *)
  
!  The import libraries are installed into the 'plugin' directory and
! their names are derived by appending the '.a' extension to the backend
! executable names, for example, 'cc1.exe.a', 'cc1plus.exe.a', etc.  The
  following command line shows how to build the single source file plugin
  on Windows to be used with the C++ compiler:
  
       g++ -I`gcc -print-file-name=plugin`/include -shared -Wl,--export-all-symbols \
       -o plugin.dll plugin.cc `gcc -print-file-name=plugin`/cc1plus.exe.a
  
!  When a plugin needs to use 'gengtype', be sure that both 'gengtype' and
! 'gtype.state' have the same version as the GCC for which the plugin is
  built.
  
  
--- 45870,45886 ----
       #endif
       int plugin_init (plugin_name_args *, plugin_gcc_version *)
  
!  The import libraries are installed into the ‘plugin’ directory and
! their names are derived by appending the ‘.a’ extension to the backend
! executable names, for example, ‘cc1.exe.a’, ‘cc1plus.exe.a’, etc.  The
  following command line shows how to build the single source file plugin
  on Windows to be used with the C++ compiler:
  
       g++ -I`gcc -print-file-name=plugin`/include -shared -Wl,--export-all-symbols \
       -o plugin.dll plugin.cc `gcc -print-file-name=plugin`/cc1plus.exe.a
  
!  When a plugin needs to use ‘gengtype’, be sure that both ‘gengtype’ and
! ‘gtype.state’ have the same version as the GCC for which the plugin is
  built.
  
  
*************** at link time).
*** 45904,45910 ****
  * IPA::                     Using summary information in IPA passes.
  * WHOPR::                   Whole program assumptions,
                              linker plugin and symbol visibilities.
! * Internal flags::          Internal flags controlling 'lto1'.
  
  
  File: gccint.info,  Node: LTO Overview,  Next: LTO object file layout,  Up: LTO
--- 45903,45909 ----
  * IPA::                     Using summary information in IPA passes.
  * WHOPR::                   Whole program assumptions,
                              linker plugin and symbol visibilities.
! * Internal flags::          Internal flags controlling ‘lto1’.
  
  
  File: gccint.info,  Node: LTO Overview,  Next: LTO object file layout,  Up: LTO
*************** File: gccint.info,  Node: LTO Overview,
*** 45913,45938 ****
  ====================
  
  Link time optimization is implemented as a GCC front end for a bytecode
! representation of GIMPLE that is emitted in special sections of '.o'
  files.  Currently, LTO support is enabled in most ELF-based systems, as
  well as darwin, cygwin and mingw systems.
  
   By default, object files generated with LTO support contain only GIMPLE
  bytecode.  Such objects are called "slim", and they require that tools
! like 'ar' and 'nm' understand symbol tables of LTO sections.  For most
  targets these tools have been extended to use the plugin infrastructure,
  so GCC can support "slim" objects consisting of the intermediate code
  alone.
  
   GIMPLE bytecode could also be saved alongside final object code if the
! '-ffat-lto-objects' option is passed, or if no plugin support is
! detected for 'ar' and 'nm' when GCC is configured.  It makes the object
  files generated with LTO support larger than regular object files.  This
  "fat" object format allows to ship one set of fat objects which could be
  used both for development and the production of optimized builds.  A,
  perhaps surprising, side effect of this feature is that any mistake in
  the toolchain leads to LTO information not being used (e.g. an older
! 'libtool' calling 'ld' directly).  This is both an advantage, as the
  system is more robust, and a disadvantage, as the user is not informed
  that the optimization has been disabled.
  
--- 45912,45937 ----
  ====================
  
  Link time optimization is implemented as a GCC front end for a bytecode
! representation of GIMPLE that is emitted in special sections of ‘.o’
  files.  Currently, LTO support is enabled in most ELF-based systems, as
  well as darwin, cygwin and mingw systems.
  
   By default, object files generated with LTO support contain only GIMPLE
  bytecode.  Such objects are called "slim", and they require that tools
! like ‘ar’ and ‘nm’ understand symbol tables of LTO sections.  For most
  targets these tools have been extended to use the plugin infrastructure,
  so GCC can support "slim" objects consisting of the intermediate code
  alone.
  
   GIMPLE bytecode could also be saved alongside final object code if the
! ‘-ffat-lto-objects’ option is passed, or if no plugin support is
! detected for ‘ar’ and ‘nm’ when GCC is configured.  It makes the object
  files generated with LTO support larger than regular object files.  This
  "fat" object format allows to ship one set of fat objects which could be
  used both for development and the production of optimized builds.  A,
  perhaps surprising, side effect of this feature is that any mistake in
  the toolchain leads to LTO information not being used (e.g. an older
! ‘libtool’ calling ‘ld’ directly).  This is both an advantage, as the
  system is more robust, and a disadvantage, as the user is not informed
  that the optimization has been disabled.
  
*************** data structures needed to optimize and g
*** 45942,45968 ****
  declarations, types, the callgraph and the GIMPLE representation of
  function bodies.
  
!  When '-flto' is given during compilation of a source file, the pass
! manager executes all the passes in 'all_lto_gen_passes'.  Currently,
  this phase is composed of two IPA passes:
  
!    * 'pass_ipa_lto_gimple_out' This pass executes the function
!      'lto_output' in 'lto-streamer-out.cc', which traverses the call
       graph encoding every reachable declaration, type and function.
       This generates a memory representation of all the file sections
       described below.
  
!    * 'pass_ipa_lto_finish_out' This pass executes the function
!      'produce_asm_for_decls' in 'lto-streamer-out.cc', which takes the
       memory image built in the previous pass and encodes it in the
       corresponding ELF file sections.
  
   The second half of LTO support is the "reader".  This is implemented as
! the GCC front end 'lto1' in 'lto/lto.cc'.  When 'collect2' detects a
! link set of '.o'/'.a' files with LTO information and the '-flto' is
! enabled, it invokes 'lto1' which reads the set of files and aggregates
  them into a single translation unit for optimization.  The main entry
! point for the reader is 'lto/lto.cc':'lto_main'.
  
  25.1.1 LTO modes of operation
  -----------------------------
--- 45941,45967 ----
  declarations, types, the callgraph and the GIMPLE representation of
  function bodies.
  
!  When ‘-flto’ is given during compilation of a source file, the pass
! manager executes all the passes in ‘all_lto_gen_passes’.  Currently,
  this phase is composed of two IPA passes:
  
!    • ‘pass_ipa_lto_gimple_out’ This pass executes the function
!      ‘lto_output’ in ‘lto-streamer-out.cc’, which traverses the call
       graph encoding every reachable declaration, type and function.
       This generates a memory representation of all the file sections
       described below.
  
!    • ‘pass_ipa_lto_finish_out’ This pass executes the function
!      ‘produce_asm_for_decls’ in ‘lto-streamer-out.cc’, which takes the
       memory image built in the previous pass and encodes it in the
       corresponding ELF file sections.
  
   The second half of LTO support is the "reader".  This is implemented as
! the GCC front end ‘lto1’ in ‘lto/lto.cc’.  When ‘collect2’ detects a
! link set of ‘.o’/‘.a’ files with LTO information and the ‘-flto’ is
! enabled, it invokes ‘lto1’ which reads the set of files and aggregates
  them into a single translation unit for optimization.  The main entry
! point for the reader is ‘lto/lto.cc’:‘lto_main’.
  
  25.1.1 LTO modes of operation
  -----------------------------
*************** two link-time compilation modes.
*** 45978,45989 ****
    2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs
       and/or a distributed compilation environment to quickly link large
       applications.  WHOPR stands for WHOle Program optimizeR (not to be
!      confused with the semantics of '-fwhole-program').  It partitions
!      the aggregated callgraph from many different '.o' files and
       distributes the compilation of the sub-graphs to different CPUs.
  
       Note that distributed compilation is not implemented yet, but since
!      the parallelism is facilitated via generating a 'Makefile', it
       would be easy to implement.
  
   WHOPR splits LTO into three main stages:
--- 45977,45988 ----
    2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs
       and/or a distributed compilation environment to quickly link large
       applications.  WHOPR stands for WHOle Program optimizeR (not to be
!      confused with the semantics of ‘-fwhole-program’).  It partitions
!      the aggregated callgraph from many different ‘.o’ files and
       distributes the compilation of the sub-graphs to different CPUs.
  
       Note that distributed compilation is not implemented yet, but since
!      the parallelism is facilitated via generating a ‘Makefile’, it
       would be easy to implement.
  
   WHOPR splits LTO into three main stages:
*************** File: gccint.info,  Node: LTO object fil
*** 46028,46040 ****
  
  LTO information is stored in several ELF sections inside object files.
  Data structures and enum codes for sections are defined in
! 'lto-streamer.h'.
  
!  These sections are emitted from 'lto-streamer-out.cc' and mapped in all
! at once from 'lto/lto.cc':'lto_file_read'.  The individual functions
  dealing with the reading/writing of each section are described below.
  
!    * Command line options ('.gnu.lto_.opts')
  
       This section contains the command line options used to generate the
       object files.  This is used at link time to determine the
--- 46027,46039 ----
  
  LTO information is stored in several ELF sections inside object files.
  Data structures and enum codes for sections are defined in
! ‘lto-streamer.h’.
  
!  These sections are emitted from ‘lto-streamer-out.cc’ and mapped in all
! at once from ‘lto/lto.cc’:‘lto_file_read’.  The individual functions
  dealing with the reading/writing of each section are described below.
  
!    • Command line options (‘.gnu.lto_.opts’)
  
       This section contains the command line options used to generate the
       object files.  This is used at link time to determine the
*************** dealing with the reading/writing of each
*** 46045,46053 ****
       restored when processing the functions at link time.  Global
       options are composed from options specified at compile time and
       link time.  How exactly they are combined or mismatches diagnosed
!      is implemented in 'lto-wrapper.cc':'find_and_merge_options'.
  
!    * Symbol table ('.gnu.lto_.symtab')
  
       This table replaces the ELF symbol table for functions and
       variables represented in the LTO IL. Symbols used and exported by
--- 46044,46052 ----
       restored when processing the functions at link time.  Global
       options are composed from options specified at compile time and
       link time.  How exactly they are combined or mismatches diagnosed
!      is implemented in ‘lto-wrapper.cc’:‘find_and_merge_options’.
  
!    • Symbol table (‘.gnu.lto_.symtab’)
  
       This table replaces the ELF symbol table for functions and
       variables represented in the LTO IL. Symbols used and exported by
*************** dealing with the reading/writing of each
*** 46064,46119 ****
       symbol table was used.
  
       The symbol table is emitted in
!      'lto-streamer-out.cc':'produce_symtab'.
  
!    * Global declarations and types ('.gnu.lto_.decls')
  
       This section contains an intermediate language dump of all
       declarations and types required to represent the callgraph, static
       variables and top-level debug info.
  
       The contents of this section are emitted in
!      'lto-streamer-out.cc':'produce_asm_for_decls'.  Types and symbols
       are emitted in a topological order that preserves the sharing of
       pointers when the file is read back in
!      ('lto.cc':'read_cgraph_and_symbols').
  
!    * The callgraph ('.gnu.lto_.cgraph')
  
       This section contains the basic data structure used by the GCC
       inter-procedural optimization infrastructure.  This section stores
       an annotated multi-graph which represents the functions and call
!      sites as well as the variables, aliases and top-level 'asm'
       statements.
  
!      This section is emitted in 'lto-streamer-out.cc':'output_cgraph'
!      and read in 'lto-cgraph.cc':'input_cgraph'.
  
!    * IPA references ('.gnu.lto_.refs')
  
       This section contains references between function and static
!      variables.  It is emitted by 'lto-cgraph.cc':'output_refs' and read
!      by 'lto-cgraph.cc':'input_refs'.
  
!    * Function bodies ('.gnu.lto_.function_body.')
  
       This section contains function bodies in the intermediate language
       representation.  Every function body is in a separate section to
       allow copying of the section independently to different object
       files or reading the function on demand.
  
!      Functions are emitted in 'lto-streamer-out.cc':'output_function'
!      and read in 'lto-streamer-in.cc':'input_function'.
  
!    * Static variable initializers ('.gnu.lto_.vars')
  
       This section contains all the symbols in the global variable pool.
!      It is emitted by 'lto-cgraph.cc':'output_varpool' and read in
!      'lto-cgraph.cc':'input_cgraph'.
  
!    * Summaries and optimization summaries used by IPA passes
!      ('.gnu.lto_.', where '' is one of 'jmpfuncs', 'pureconst'
!      or 'reference')
  
       These sections are used by IPA passes that need to emit summary
       information during LTO generation to be read and aggregated at link
--- 46063,46118 ----
       symbol table was used.
  
       The symbol table is emitted in
!      ‘lto-streamer-out.cc’:‘produce_symtab’.
  
!    • Global declarations and types (‘.gnu.lto_.decls’)
  
       This section contains an intermediate language dump of all
       declarations and types required to represent the callgraph, static
       variables and top-level debug info.
  
       The contents of this section are emitted in
!      ‘lto-streamer-out.cc’:‘produce_asm_for_decls’.  Types and symbols
       are emitted in a topological order that preserves the sharing of
       pointers when the file is read back in
!      (‘lto.cc’:‘read_cgraph_and_symbols’).
  
!    • The callgraph (‘.gnu.lto_.cgraph’)
  
       This section contains the basic data structure used by the GCC
       inter-procedural optimization infrastructure.  This section stores
       an annotated multi-graph which represents the functions and call
!      sites as well as the variables, aliases and top-level ‘asm’
       statements.
  
!      This section is emitted in ‘lto-streamer-out.cc’:‘output_cgraph’
!      and read in ‘lto-cgraph.cc’:‘input_cgraph’.
  
!    • IPA references (‘.gnu.lto_.refs’)
  
       This section contains references between function and static
!      variables.  It is emitted by ‘lto-cgraph.cc’:‘output_refs’ and read
!      by ‘lto-cgraph.cc’:‘input_refs’.
  
!    • Function bodies (‘.gnu.lto_.function_body.’)
  
       This section contains function bodies in the intermediate language
       representation.  Every function body is in a separate section to
       allow copying of the section independently to different object
       files or reading the function on demand.
  
!      Functions are emitted in ‘lto-streamer-out.cc’:‘output_function’
!      and read in ‘lto-streamer-in.cc’:‘input_function’.
  
!    • Static variable initializers (‘.gnu.lto_.vars’)
  
       This section contains all the symbols in the global variable pool.
!      It is emitted by ‘lto-cgraph.cc’:‘output_varpool’ and read in
!      ‘lto-cgraph.cc’:‘input_cgraph’.
  
!    • Summaries and optimization summaries used by IPA passes
!      (‘.gnu.lto_.’, where ‘’ is one of ‘jmpfuncs’, ‘pureconst’
!      or ‘reference’)
  
       These sections are used by IPA passes that need to emit summary
       information during LTO generation to be read and aggregated at link
*************** make the implementation of WHOPR possibl
*** 46139,46207 ****
  optimization pass is split into several stages that are executed at
  different times during WHOPR compilation:
  
!    * LGEN time
!        1. _Generate summary_ ('generate_summary' in 'struct
!           ipa_opt_pass_d').  This stage analyzes every function body and
            variable initializer is examined and stores relevant
            information into a pass-specific data structure.
  
!        2. _Write summary_ ('write_summary' in 'struct ipa_opt_pass_d').
            This stage writes all the pass-specific information generated
!           by 'generate_summary'.  Summaries go into their own
!           'LTO_section_*' sections that have to be declared in
!           'lto-streamer.h':'enum lto_section_type'.  A new section is
!           created by calling 'create_output_block' and data can be
!           written using the 'lto_output_*' routines.
  
!    * WPA time
!        1. _Read summary_ ('read_summary' in 'struct ipa_opt_pass_d').
            This stage reads all the pass-specific information in exactly
!           the same order that it was written by 'write_summary'.
  
!        2. _Execute_ ('execute' in 'struct opt_pass').  This performs
            inter-procedural propagation.  This must be done without
            actual access to the individual function bodies or variable
            initializers.  Typically, this results in a transitive closure
            operation over the summary information of all the nodes in the
            callgraph.
  
!        3. _Write optimization summary_ ('write_optimization_summary' in
!           'struct ipa_opt_pass_d').  This writes the result of the
            inter-procedural propagation into the object file.  This can
            use the same data structures and helper routines used in
!           'write_summary'.
  
!    * LTRANS time
!        1. _Read optimization summary_ ('read_optimization_summary' in
!           'struct ipa_opt_pass_d').  The counterpart to
!           'write_optimization_summary'.  This reads the interprocedural
            optimization decisions in exactly the same format emitted by
!           'write_optimization_summary'.
  
!        2. _Transform_ ('function_transform' and 'variable_transform' in
!           'struct ipa_opt_pass_d').  The actual function bodies and
            variable initializers are updated based on the information
            passed down from the _Execute_ stage.
  
   The implementation of the inter-procedural passes are shared between
  LTO, WHOPR and classic non-LTO compilation.
  
!    * During the traditional file-by-file mode every pass executes its
       own _Generate summary_, _Execute_, and _Transform_ stages within
       the single execution context of the compiler.
  
!    * In LTO compilation mode, every pass uses _Generate summary_ and
       _Write summary_ stages at compilation time, while the _Read
       summary_, _Execute_, and _Transform_ stages are executed at link
       time.
  
!    * In WHOPR mode all stages are used.
  
   To simplify development, the GCC pass manager differentiates between
  normal inter-procedural passes (*note Regular IPA passes::), small
  inter-procedural passes (*note Small IPA passes::) and late
  inter-procedural passes (*note Late IPA passes::).  A small or late IPA
! pass ('SIMPLE_IPA_PASS') does everything at once and thus cannot be
  executed during WPA in WHOPR mode.  It defines only the _Execute_ stage
  and during this stage it accesses and modifies the function bodies.
  Such passes are useful for optimization at LGEN or LTRANS time and are
--- 46138,46206 ----
  optimization pass is split into several stages that are executed at
  different times during WHOPR compilation:
  
!    • LGEN time
!        1. _Generate summary_ (‘generate_summary’ in ‘struct
!           ipa_opt_pass_d’).  This stage analyzes every function body and
            variable initializer is examined and stores relevant
            information into a pass-specific data structure.
  
!        2. _Write summary_ (‘write_summary’ in ‘struct ipa_opt_pass_d’).
            This stage writes all the pass-specific information generated
!           by ‘generate_summary’.  Summaries go into their own
!           ‘LTO_section_*’ sections that have to be declared in
!           ‘lto-streamer.h’:‘enum lto_section_type’.  A new section is
!           created by calling ‘create_output_block’ and data can be
!           written using the ‘lto_output_*’ routines.
  
!    • WPA time
!        1. _Read summary_ (‘read_summary’ in ‘struct ipa_opt_pass_d’).
            This stage reads all the pass-specific information in exactly
!           the same order that it was written by ‘write_summary’.
  
!        2. _Execute_ (‘execute’ in ‘struct opt_pass’).  This performs
            inter-procedural propagation.  This must be done without
            actual access to the individual function bodies or variable
            initializers.  Typically, this results in a transitive closure
            operation over the summary information of all the nodes in the
            callgraph.
  
!        3. _Write optimization summary_ (‘write_optimization_summary’ in
!           ‘struct ipa_opt_pass_d’).  This writes the result of the
            inter-procedural propagation into the object file.  This can
            use the same data structures and helper routines used in
!           ‘write_summary’.
  
!    • LTRANS time
!        1. _Read optimization summary_ (‘read_optimization_summary’ in
!           ‘struct ipa_opt_pass_d’).  The counterpart to
!           ‘write_optimization_summary’.  This reads the interprocedural
            optimization decisions in exactly the same format emitted by
!           ‘write_optimization_summary’.
  
!        2. _Transform_ (‘function_transform’ and ‘variable_transform’ in
!           ‘struct ipa_opt_pass_d’).  The actual function bodies and
            variable initializers are updated based on the information
            passed down from the _Execute_ stage.
  
   The implementation of the inter-procedural passes are shared between
  LTO, WHOPR and classic non-LTO compilation.
  
!    • During the traditional file-by-file mode every pass executes its
       own _Generate summary_, _Execute_, and _Transform_ stages within
       the single execution context of the compiler.
  
!    • In LTO compilation mode, every pass uses _Generate summary_ and
       _Write summary_ stages at compilation time, while the _Read
       summary_, _Execute_, and _Transform_ stages are executed at link
       time.
  
!    • In WHOPR mode all stages are used.
  
   To simplify development, the GCC pass manager differentiates between
  normal inter-procedural passes (*note Regular IPA passes::), small
  inter-procedural passes (*note Small IPA passes::) and late
  inter-procedural passes (*note Late IPA passes::).  A small or late IPA
! pass (‘SIMPLE_IPA_PASS’) does everything at once and thus cannot be
  executed during WPA in WHOPR mode.  It defines only the _Execute_ stage
  and during this stage it accesses and modifies the function bodies.
  Such passes are useful for optimization at LGEN or LTRANS time and are
*************** summaries updated for the _Transform_ st
*** 46286,46305 ****
  ---------------------
  
  GCC represents IPA references in the callgraph.  For a function or
! variable 'A', the _IPA reference_ is a list of all locations where the
! address of 'A' is taken and, when 'A' is a variable, a list of all
! direct stores and reads to/from 'A'.  References represent an oriented
  multi-graph on the union of nodes of the callgraph and the varpool.  See
! 'ipa-reference.cc':'ipa_reference_write_optimization_summary' and
! 'ipa-reference.cc':'ipa_reference_read_optimization_summary' for
  details.
  
  25.3.3 Jump functions
  ---------------------
  
! Suppose that an optimization pass sees a function 'A' and it knows the
  values of (some of) its arguments.  The _jump function_ describes the
! value of a parameter of a given function call in function 'A' based on
  this knowledge.
  
   Jump functions are used by several optimizations, such as the
--- 46285,46304 ----
  ---------------------
  
  GCC represents IPA references in the callgraph.  For a function or
! variable ‘A’, the _IPA reference_ is a list of all locations where the
! address of ‘A’ is taken and, when ‘A’ is a variable, a list of all
! direct stores and reads to/from ‘A’.  References represent an oriented
  multi-graph on the union of nodes of the callgraph and the varpool.  See
! ‘ipa-reference.cc’:‘ipa_reference_write_optimization_summary’ and
! ‘ipa-reference.cc’:‘ipa_reference_read_optimization_summary’ for
  details.
  
  25.3.3 Jump functions
  ---------------------
  
! Suppose that an optimization pass sees a function ‘A’ and it knows the
  values of (some of) its arguments.  The _jump function_ describes the
! value of a parameter of a given function call in function ‘A’ based on
  this knowledge.
  
   Jump functions are used by several optimizations, such as the
*************** rules allow one to overwrite any externa
*** 46325,46345 ****
  different symbol at runtime.  This basically disables any optimizations
  across such functions and variables, because the compiler cannot be sure
  that the function body it is seeing is the same function body that will
! be used at runtime.  Any function or variable not declared 'static' in
  the sources degrades the quality of inter-procedural optimization.
  
   To avoid this problem the compiler must assume that it sees the whole
  program when doing link-time optimization.  Strictly speaking, the whole
  program is rarely visible even at link-time.  Standard system libraries
  are usually linked dynamically or not provided with the link-time
! information.  In GCC, the whole program option ('-fwhole-program')
  asserts that every function and variable defined in the current
! compilation unit is static, except for function 'main' (note: at link
  time, the current unit is the union of all objects compiled with LTO).
  Since some functions and variables need to be referenced externally, for
  example by another DSO or from an assembler file, GCC also provides the
! function and variable attribute 'externally_visible' which can be used
! to disable the effect of '-fwhole-program' on a specific symbol.
  
   The whole program mode assumptions are slightly more complex in C++,
  where inline functions in headers are put into _COMDAT_ sections.
--- 46324,46344 ----
  different symbol at runtime.  This basically disables any optimizations
  across such functions and variables, because the compiler cannot be sure
  that the function body it is seeing is the same function body that will
! be used at runtime.  Any function or variable not declared ‘static’ in
  the sources degrades the quality of inter-procedural optimization.
  
   To avoid this problem the compiler must assume that it sees the whole
  program when doing link-time optimization.  Strictly speaking, the whole
  program is rarely visible even at link-time.  Standard system libraries
  are usually linked dynamically or not provided with the link-time
! information.  In GCC, the whole program option (‘-fwhole-program’)
  asserts that every function and variable defined in the current
! compilation unit is static, except for function ‘main’ (note: at link
  time, the current unit is the union of all objects compiled with LTO).
  Since some functions and variables need to be referenced externally, for
  example by another DSO or from an assembler file, GCC also provides the
! function and variable attribute ‘externally_visible’ which can be used
! to disable the effect of ‘-fwhole-program’ on a specific symbol.
  
   The whole program mode assumptions are slightly more complex in C++,
  where inline functions in headers are put into _COMDAT_ sections.
*************** always remain externally visible, howeve
*** 46351,46363 ****
  assumed that their initializers cannot be overwritten by a different
  value.
  
!  GCC provides the function and variable attribute 'visibility' that can
  be used to specify the visibility of externally visible symbols (or
! alternatively an '-fdefault-visibility' command line option).  ELF
! defines the 'default', 'protected', 'hidden' and 'internal'
  visibilities.
  
!  The most commonly used is visibility is 'hidden'.  It specifies that
  the symbol cannot be referenced from outside of the current shared
  library.  Unfortunately, this information cannot be used directly by the
  link-time optimization in the compiler since the whole shared library
--- 46350,46362 ----
  assumed that their initializers cannot be overwritten by a different
  value.
  
!  GCC provides the function and variable attribute ‘visibility’ that can
  be used to specify the visibility of externally visible symbols (or
! alternatively an ‘-fdefault-visibility’ command line option).  ELF
! defines the ‘default’, ‘protected’, ‘hidden’ and ‘internal’
  visibilities.
  
!  The most commonly used is visibility is ‘hidden’.  It specifies that
  the symbol cannot be referenced from outside of the current shared
  library.  Unfortunately, this information cannot be used directly by the
  link-time optimization in the compiler since the whole shared library
*************** the rest of a binary being linked.
*** 46377,46402 ****
   GCC is designed to be independent of the rest of the toolchain and aims
  to support linkers without plugin support.  For this reason it does not
  use the linker plugin by default.  Instead, the object files are
! examined by 'collect2' before being passed to the linker and objects
! found to have LTO sections are passed to 'lto1' first.  This mode does
  not work for library archives.  The decision on what object files from
  the archive are needed depends on the actual linking and thus GCC would
  have to implement the linker itself.  The resolution information is
  missing too and thus GCC needs to make an educated guess based on
! '-fwhole-program'.  Without the linker plugin GCC also assumes that
! symbols are declared 'hidden' and not referred by non-LTO code by
  default.
  
  
  File: gccint.info,  Node: Internal flags,  Prev: WHOPR,  Up: LTO
  
! 25.5 Internal flags controlling 'lto1'
  ======================================
  
! The following flags are passed into 'lto1' and are not meant to be used
  directly from the command line.
  
!    * -fwpa This option runs the serial part of the link-time optimizer
       performing the inter-procedural propagation (WPA mode).  The
       compiler reads in summary information from all inputs and performs
       an analysis based on summary information only.  It generates object
--- 46376,46401 ----
   GCC is designed to be independent of the rest of the toolchain and aims
  to support linkers without plugin support.  For this reason it does not
  use the linker plugin by default.  Instead, the object files are
! examined by ‘collect2’ before being passed to the linker and objects
! found to have LTO sections are passed to ‘lto1’ first.  This mode does
  not work for library archives.  The decision on what object files from
  the archive are needed depends on the actual linking and thus GCC would
  have to implement the linker itself.  The resolution information is
  missing too and thus GCC needs to make an educated guess based on
! ‘-fwhole-program’.  Without the linker plugin GCC also assumes that
! symbols are declared ‘hidden’ and not referred by non-LTO code by
  default.
  
  
  File: gccint.info,  Node: Internal flags,  Prev: WHOPR,  Up: LTO
  
! 25.5 Internal flags controlling ‘lto1’
  ======================================
  
! The following flags are passed into ‘lto1’ and are not meant to be used
  directly from the command line.
  
!    • -fwpa This option runs the serial part of the link-time optimizer
       performing the inter-procedural propagation (WPA mode).  The
       compiler reads in summary information from all inputs and performs
       an analysis based on summary information only.  It generates object
*************** directly from the command line.
*** 46405,46421 ****
       information from the WPA mode and the actual function bodies.  It
       then drives the LTRANS phase.
  
!    * -fltrans This option runs the link-time optimizer in the
       local-transformation (LTRANS) mode, which reads in output from a
       previous run of the LTO in WPA mode.  In the LTRANS mode, LTO
       optimizes an object and produces the final assembly.
  
!    * -fltrans-output-list=FILE This option specifies a file to which the
       names of LTRANS output files are written.  This option is only
!      meaningful in conjunction with '-fwpa'.
  
!    * -fresolution=FILE This option specifies the linker resolution file.
!      This option is only meaningful in conjunction with '-fwpa' and as
       option to pass through to the LTO linker plugin.
  
  
--- 46404,46420 ----
       information from the WPA mode and the actual function bodies.  It
       then drives the LTRANS phase.
  
!    • -fltrans This option runs the link-time optimizer in the
       local-transformation (LTRANS) mode, which reads in output from a
       previous run of the LTO in WPA mode.  In the LTRANS mode, LTO
       optimizes an object and produces the final assembly.
  
!    • -fltrans-output-list=FILE This option specifies a file to which the
       names of LTRANS output files are written.  This option is only
!      meaningful in conjunction with ‘-fwpa’.
  
!    • -fresolution=FILE This option specifies the linker resolution file.
!      This option is only meaningful in conjunction with ‘-fwpa’ and as
       option to pass through to the LTO linker plugin.
  
  
*************** File: gccint.info,  Node: GIMPLE API,  N
*** 46470,46485 ****
  
   thus providing n-ary overloads for operation or function.  The
  additional arguments are a gimple_seq where built statements are
! inserted on (if 'NULL' then simplifications requiring new statements are
  not performed) and a valueization hook that can be used to tie
  simplifications to a SSA lattice.
  
!  In addition to those APIs 'fold_stmt' is overloaded with a valueization
  hook:
  
   -- bool: fold_stmt (gimple_stmt_iterator *, tree (*)(tree));
  
!  On top of these a 'fold_buildN'-like API for GIMPLE is introduced:
  
   -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum
            tree_code, tree, tree, tree (*valueize) (tree) = NULL);
--- 46469,46484 ----
  
   thus providing n-ary overloads for operation or function.  The
  additional arguments are a gimple_seq where built statements are
! inserted on (if ‘NULL’ then simplifications requiring new statements are
  not performed) and a valueization hook that can be used to tie
  simplifications to a SSA lattice.
  
!  In addition to those APIs ‘fold_stmt’ is overloaded with a valueization
  hook:
  
   -- bool: fold_stmt (gimple_stmt_iterator *, tree (*)(tree));
  
!  On top of these a ‘fold_buildN’-like API for GIMPLE is introduced:
  
   -- GIMPLE function: tree gimple_build (gimple_seq *, location_t, enum
            tree_code, tree, tree, tree (*valueize) (tree) = NULL);
*************** hook:
*** 46500,46507 ****
   -- GIMPLE function: tree gimple_convert (gimple_seq *, location_t,
            tree, tree);
  
!  which is supposed to replace 'force_gimple_operand (fold_buildN (...),
! ...)' and calls to 'fold_convert'.  Overloads without the 'location_t'
  argument exist.  Built statements are inserted on the provided sequence
  and simplification is performed using the optional valueization hook.
  
--- 46499,46506 ----
   -- GIMPLE function: tree gimple_convert (gimple_seq *, location_t,
            tree, tree);
  
!  which is supposed to replace ‘force_gimple_operand (fold_buildN (...),
! ...)’ and calls to ‘fold_convert’.  Overloads without the ‘location_t’
  argument exist.  Built statements are inserted on the provided sequence
  and simplification is performed using the optional valueization hook.
  
*************** start with an example from the match.pd
*** 46520,46547 ****
         @0)
  
   This example contains all required parts of an expression
! simplification.  A simplification is wrapped inside a '(simplify ...)'
  expression.  That contains at least two operands - an expression that is
  matched with the GIMPLE or GENERIC IL and a replacement expression that
  is returned if the match was successful.
  
!  Expressions have an operator ID, 'bit_and' in this case.  Expressions
! can be lower-case tree codes with '_expr' stripped off or builtin
! function code names in all-caps, like 'BUILT_IN_SQRT'.
  
!  '@n' denotes a so-called capture.  It captures the operand and lets you
  refer to it in other places of the match-and-simplify.  In the above
  example it is referred to in the replacement expression.  Captures are
! '@' followed by a number or an identifier.
  
       (simplify
         (bit_xor @0 @0)
         { build_zero_cst (type); })
  
!  In this example '@0' is mentioned twice which constrains the matched
  expression to have two equal operands.  Usually matches are constrained
  to equal types.  If operands may be constants and conversions are
! involved, matching by value might be preferred in which case use '@@0'
  to denote a by-value match and the specific operand you want to refer to
  in the result part.  This example also introduces operands written in C
  code.  These can be used in the expression replacements and are supposed
--- 46519,46546 ----
         @0)
  
   This example contains all required parts of an expression
! simplification.  A simplification is wrapped inside a ‘(simplify ...)’
  expression.  That contains at least two operands - an expression that is
  matched with the GIMPLE or GENERIC IL and a replacement expression that
  is returned if the match was successful.
  
!  Expressions have an operator ID, ‘bit_and’ in this case.  Expressions
! can be lower-case tree codes with ‘_expr’ stripped off or builtin
! function code names in all-caps, like ‘BUILT_IN_SQRT’.
  
!  ‘@n’ denotes a so-called capture.  It captures the operand and lets you
  refer to it in other places of the match-and-simplify.  In the above
  example it is referred to in the replacement expression.  Captures are
! ‘@’ followed by a number or an identifier.
  
       (simplify
         (bit_xor @0 @0)
         { build_zero_cst (type); })
  
!  In this example ‘@0’ is mentioned twice which constrains the matched
  expression to have two equal operands.  Usually matches are constrained
  to equal types.  If operands may be constants and conversions are
! involved, matching by value might be preferred in which case use ‘@@0’
  to denote a by-value match and the specific operand you want to refer to
  in the result part.  This example also introduces operands written in C
  code.  These can be used in the expression replacements and are supposed
*************** you cannot generate expressions in C cod
*** 46553,46560 ****
         (if (!integer_zerop (@1))
          @0))
  
!  Here '@0' captures the first operand of the trunc_mod expression which
! is also predicated with 'integer_zerop'.  Expression operands may be
  either expressions, predicates or captures.  Captures can be
  unconstrained or capture expressions or predicates.
  
--- 46552,46559 ----
         (if (!integer_zerop (@1))
          @0))
  
!  Here ‘@0’ captures the first operand of the trunc_mod expression which
! is also predicated with ‘integer_zerop’.  Expression operands may be
  either expressions, predicates or captures.  Captures can be
  unconstrained or capture expressions or predicates.
  
*************** unconstrained or capture expressions or
*** 46562,46573 ****
  if-expression.  This condition is evaluated after the expression matched
  in the IL and is required to evaluate to true to enable the replacement
  expression in the second operand position.  The expression operand of
! the 'if' is a standard C expression which may contain references to
! captures.  The 'if' has an optional third operand which may contain the
  replacement expression that is enabled when the condition evaluates to
  false.
  
!  A 'if' expression can be used to specify a common condition for
  multiple simplify patterns, avoiding the need to repeat that multiple
  times:
  
--- 46561,46572 ----
  if-expression.  This condition is evaluated after the expression matched
  in the IL and is required to evaluate to true to enable the replacement
  expression in the second operand position.  The expression operand of
! the ‘if’ is a standard C expression which may contain references to
! captures.  The ‘if’ has an optional third operand which may contain the
  replacement expression that is enabled when the condition evaluates to
  false.
  
!  A ‘if’ expression can be used to specify a common condition for
  multiple simplify patterns, avoiding the need to repeat that multiple
  times:
  
*************** times:
*** 46580,46592 ****
           (minus (minus @0 @1) @0)
           (negate @1)))
  
!  Note that 'if's in outer position do not have the optional else clause
  but instead have multiple then clauses.
  
   Ifs can be nested.
  
!  There exists a 'switch' expression which can be used to chain
! conditions avoiding nesting 'if's too much:
  
       (simplify
        (simple_comparison @0 REAL_CST@1)
--- 46579,46591 ----
           (minus (minus @0 @1) @0)
           (negate @1)))
  
!  Note that ‘if’s in outer position do not have the optional else clause
  but instead have multiple then clauses.
  
   Ifs can be nested.
  
!  There exists a ‘switch’ expression which can be used to chain
! conditions avoiding nesting ‘if’s too much:
  
       (simplify
        (simple_comparison @0 REAL_CST@1)
*************** conditions avoiding nesting 'if's too mu
*** 46612,46619 ****
               && ! HONOR_SNANS (@1))
           { constant_boolean_node (cmp == NE_EXPR, type); }))))
  
!  which has the second 'if' in the else operand of the first.  The
! 'switch' expression takes 'if' expressions as operands (which may not
  have else clauses) and as a last operand a replacement expression which
  should be enabled by default if no other condition evaluated to true.
  
--- 46611,46618 ----
               && ! HONOR_SNANS (@1))
           { constant_boolean_node (cmp == NE_EXPR, type); }))))
  
!  which has the second ‘if’ in the else operand of the first.  The
! ‘switch’ expression takes ‘if’ expressions as operands (which may not
  have else clauses) and as a last operand a replacement expression which
  should be enabled by default if no other condition evaluated to true.
  
*************** should be enabled by default if no other
*** 46636,46654 ****
         })
       #endif
  
!  In the above example, '@2' captures the result of the expression '(addr
! @0)'.  For the outermost expression only its type can be captured, and
! the keyword 'type' is reserved for this purpose.  The above example also
! gives a way to conditionalize patterns to only apply to 'GIMPLE' or
! 'GENERIC' by means of using the pre-defined preprocessor macros 'GIMPLE'
! and 'GENERIC' and using preprocessor directives.
  
       (simplify
         (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1))
         (bit_and @1 @0))
  
   Here we introduce flags on match expressions.  The flag used above,
! 'c', denotes that the expression should be also matched commutated.
  Thus the above match expression is really the following four match
  expressions:
  
--- 46635,46653 ----
         })
       #endif
  
!  In the above example, ‘@2’ captures the result of the expression ‘(addr
! @0)’.  For the outermost expression only its type can be captured, and
! the keyword ‘type’ is reserved for this purpose.  The above example also
! gives a way to conditionalize patterns to only apply to ‘GIMPLE’ or
! ‘GENERIC’ by means of using the pre-defined preprocessor macros ‘GIMPLE’
! and ‘GENERIC’ and using preprocessor directives.
  
       (simplify
         (bit_and:c integral_op_p@0 (bit_ior:c (bit_not @0) @1))
         (bit_and @1 @0))
  
   Here we introduce flags on match expressions.  The flag used above,
! ‘c’, denotes that the expression should be also matched commutated.
  Thus the above match expression is really the following four match
  expressions:
  
*************** expressions:
*** 46661,46668 ****
  before matching, so for example constant operands always come second in
  commutative expressions.
  
!  The second supported flag is 's' which tells the code generator to fail
! the pattern if the expression marked with 's' does have more than one
  use and the simplification results in an expression with more than one
  operator.  For example in
  
--- 46660,46667 ----
  before matching, so for example constant operands always come second in
  commutative expressions.
  
!  The second supported flag is ‘s’ which tells the code generator to fail
! the pattern if the expression marked with ‘s’ does have more than one
  use and the simplification results in an expression with more than one
  operator.  For example in
  
*************** operator.  For example in
*** 46670,46683 ****
         (pointer_plus (pointer_plus:s @0 @1) @3)
         (pointer_plus @0 (plus @1 @3)))
  
!  this avoids the association if '(pointer_plus @0 @1)' is used outside
  of the matched expression and thus it would stay live and not trivially
! removed by dead code elimination.  Now consider '((x + 3) + -3)' with
! the temporary holding '(x + 3)' used elsewhere.  This simplifies down to
! 'x' which is desirable and thus flagging with 's' does not prevent the
! transform.  Now consider '((x + 3) + 1)' which simplifies to '(x + 4)'.
! Despite being flagged with 's' the simplification will be performed.
! The simplification of '((x + a) + 1)' to '(x + (a + 1))' will not
  performed in this case though.
  
   More features exist to avoid too much repetition.
--- 46669,46682 ----
         (pointer_plus (pointer_plus:s @0 @1) @3)
         (pointer_plus @0 (plus @1 @3)))
  
!  this avoids the association if ‘(pointer_plus @0 @1)’ is used outside
  of the matched expression and thus it would stay live and not trivially
! removed by dead code elimination.  Now consider ‘((x + 3) + -3)’ with
! the temporary holding ‘(x + 3)’ used elsewhere.  This simplifies down to
! ‘x’ which is desirable and thus flagging with ‘s’ does not prevent the
! transform.  Now consider ‘((x + 3) + 1)’ which simplifies to ‘(x + 4)’.
! Despite being flagged with ‘s’ the simplification will be performed.
! The simplification of ‘((x + a) + 1)’ to ‘(x + (a + 1))’ will not
  performed in this case though.
  
   More features exist to avoid too much repetition.
*************** performed in this case though.
*** 46687,46694 ****
           (op @0 integer_zerop)
           @0))
  
!  A 'for' expression can be used to repeat a pattern for each operator
! specified, substituting 'op'.  'for' can be nested and a 'for' can have
  multiple operators to iterate.
  
       (for opa (plus minus)
--- 46686,46693 ----
           (op @0 integer_zerop)
           @0))
  
!  A ‘for’ expression can be used to repeat a pattern for each operator
! specified, substituting ‘op’.  ‘for’ can be nested and a ‘for’ can have
  multiple operators to iterate.
  
       (for opa (plus minus)
*************** multiple operators to iterate.
*** 46696,46719 ****
         (for opc (plus minus)
           (simplify...
  
!  In this example the pattern will be repeated four times with 'opa, opb,
! opc' being 'plus, minus, plus'; 'plus, minus, minus'; 'minus, plus,
! plus'; 'minus, plus, minus'.
  
!  To avoid repeating operator lists in 'for' you can name them via
  
       (define_operator_list pmm plus minus mult)
  
!  and use them in 'for' operator lists where they get expanded.
  
       (for opa (pmm trunc_div)
        (simplify...
  
!  So this example iterates over 'plus', 'minus', 'mult' and 'trunc_div'.
  
   Using operator lists can also remove the need to explicitly write a
! 'for'.  All operator list uses that appear in a 'simplify' or 'match'
! pattern in operator positions will implicitly be added to a new 'for'.
  For example
  
       (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL)
--- 46695,46718 ----
         (for opc (plus minus)
           (simplify...
  
!  In this example the pattern will be repeated four times with ‘opa, opb,
! opc’ being ‘plus, minus, plus’; ‘plus, minus, minus’; ‘minus, plus,
! plus’; ‘minus, plus, minus’.
  
!  To avoid repeating operator lists in ‘for’ you can name them via
  
       (define_operator_list pmm plus minus mult)
  
!  and use them in ‘for’ operator lists where they get expanded.
  
       (for opa (pmm trunc_div)
        (simplify...
  
!  So this example iterates over ‘plus’, ‘minus’, ‘mult’ and ‘trunc_div’.
  
   Using operator lists can also remove the need to explicitly write a
! ‘for’.  All operator list uses that appear in a ‘simplify’ or ‘match’
! pattern in operator positions will implicitly be added to a new ‘for’.
  For example
  
       (define_operator_list SQRT BUILT_IN_SQRTF BUILT_IN_SQRT BUILT_IN_SQRTL)
*************** For example
*** 46730,46741 ****
         (SQRT (POW @0 @1))
         (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); }))))
  
!  'for's and operator lists can include the special identifier 'null'
  that matches nothing and can never be generated.  This can be used to
  pad an operator list so that it has a standard form, even if there isn't
  a suitable operator for every form.
  
!  Another building block are 'with' expressions in the result expression
  which nest the generated code in a new C block followed by its argument:
  
       (simplify
--- 46729,46740 ----
         (SQRT (POW @0 @1))
         (POW (abs @0) (mult @1 { built_real (TREE_TYPE (@1), dconsthalf); }))))
  
!  ‘for’s and operator lists can include the special identifier ‘null’
  that matches nothing and can never be generated.  This can be used to
  pad an operator list so that it has a standard form, even if there isn't
  a suitable operator for every form.
  
!  Another building block are ‘with’ expressions in the result expression
  which nest the generated code in a new C block followed by its argument:
  
       (simplify
*************** which nest the generated code in a new C
*** 46743,46757 ****
        (with { tree utype = unsigned_type_for (type); }
         (convert (mult (convert:utype @0) (convert:utype @1)))))
  
!  This allows code nested in the 'with' to refer to the declared
  variables.  In the above case we use the feature to specify the type of
! a generated expression with the ':type' syntax where 'type' needs to be
  an identifier that refers to the desired type.  Usually the types of the
  generated result expressions are determined from the context, but
  sometimes like in the above case it is required that you specify them
  explicitly.
  
!  Another modifier for generated expressions is '!' which tells the
  machinery to only consider the simplification in case the marked
  expression simplified to a simple operand.  Consider for example
  
--- 46742,46756 ----
        (with { tree utype = unsigned_type_for (type); }
         (convert (mult (convert:utype @0) (convert:utype @1)))))
  
!  This allows code nested in the ‘with’ to refer to the declared
  variables.  In the above case we use the feature to specify the type of
! a generated expression with the ‘:type’ syntax where ‘type’ needs to be
  an identifier that refers to the desired type.  Usually the types of the
  generated result expressions are determined from the context, but
  sometimes like in the above case it is required that you specify them
  explicitly.
  
!  Another modifier for generated expressions is ‘!’ which tells the
  machinery to only consider the simplification in case the marked
  expression simplified to a simple operand.  Consider for example
  
*************** expression simplified to a simple operan
*** 46759,46796 ****
         (plus (vec_cond:s @0 @1 @2) @3)
         (vec_cond @0 (plus! @1 @3) (plus! @2 @3)))
  
!  which moves the outer 'plus' operation to the inner arms of the
! 'vec_cond' expression but only if the actual plus operations both
! simplify.  Note that on 'GENERIC' a simple operand means that the result
! satisfies '!EXPR_P' which can be limiting if the operation itself
  simplifies but the remaining operand is an (unrelated) expression.
  
   As intermediate conversions are often optional there is a way to avoid
  the need to repeat patterns both with and without such conversions.
! Namely you can mark a conversion as being optional with a '?':
  
       (simplify
        (eq (convert@0 @1) (convert? @2))
        (eq @1 (convert @2)))
  
!  which will match both '(eq (convert @1) (convert @2))' and '(eq
! (convert @1) @2)'.  The optional converts are supposed to be all either
! present or not, thus '(eq (convert? @1) (convert? @2))' will result in
  two patterns only.  If you want to match all four combinations you have
! access to two additional conditional converts as in '(eq (convert1? @1)
! (convert2? @2))'.
  
!  The support for '?' marking extends to all unary operations including
! predicates you declare yourself with 'match'.
  
   Predicates available from the GCC middle-end need to be made available
! explicitly via 'define_predicates':
  
       (define_predicates
        integer_onep integer_zerop integer_all_onesp)
  
   You can also define predicates using the pattern matching language and
! the 'match' form:
  
       (match negate_expr_p
        INTEGER_CST
--- 46758,46795 ----
         (plus (vec_cond:s @0 @1 @2) @3)
         (vec_cond @0 (plus! @1 @3) (plus! @2 @3)))
  
!  which moves the outer ‘plus’ operation to the inner arms of the
! ‘vec_cond’ expression but only if the actual plus operations both
! simplify.  Note that on ‘GENERIC’ a simple operand means that the result
! satisfies ‘!EXPR_P’ which can be limiting if the operation itself
  simplifies but the remaining operand is an (unrelated) expression.
  
   As intermediate conversions are often optional there is a way to avoid
  the need to repeat patterns both with and without such conversions.
! Namely you can mark a conversion as being optional with a ‘?’:
  
       (simplify
        (eq (convert@0 @1) (convert? @2))
        (eq @1 (convert @2)))
  
!  which will match both ‘(eq (convert @1) (convert @2))’ and ‘(eq
! (convert @1) @2)’.  The optional converts are supposed to be all either
! present or not, thus ‘(eq (convert? @1) (convert? @2))’ will result in
  two patterns only.  If you want to match all four combinations you have
! access to two additional conditional converts as in ‘(eq (convert1? @1)
! (convert2? @2))’.
  
!  The support for ‘?’ marking extends to all unary operations including
! predicates you declare yourself with ‘match’.
  
   Predicates available from the GCC middle-end need to be made available
! explicitly via ‘define_predicates’:
  
       (define_predicates
        integer_onep integer_zerop integer_all_onesp)
  
   You can also define predicates using the pattern matching language and
! the ‘match’ form:
  
       (match negate_expr_p
        INTEGER_CST
*************** the 'match' form:
*** 46799,46809 ****
       (match negate_expr_p
        (negate @0))
  
!  This shows that for 'match' expressions there is 't' available which
  captures the outermost expression (something not possible in the
! 'simplify' context).  As you can see 'match' has an identifier as first
  operand which is how you refer to the predicate in patterns.  Multiple
! 'match' for the same identifier add additional cases where the predicate
  matches.
  
   Predicates can also match an expression in which case you need to
--- 46798,46808 ----
       (match negate_expr_p
        (negate @0))
  
!  This shows that for ‘match’ expressions there is ‘t’ available which
  captures the outermost expression (something not possible in the
! ‘simplify’ context).  As you can see ‘match’ has an identifier as first
  operand which is how you refer to the predicate in patterns.  Multiple
! ‘match’ for the same identifier add additional cases where the predicate
  matches.
  
   Predicates can also match an expression in which case you need to
*************** whole-program analysis).
*** 46851,46875 ****
   The implementation is read-only: it doesn't attempt to change anything,
  just emit warnings.
  
!  The gimple representation can be seen using '-fdump-ipa-analyzer'.
       Tip: If the analyzer ICEs before this is written out, one
!      workaround is to use '--param=analyzer-bb-explosion-factor=0' to
       force the analyzer to bail out after analyzing the first basic
       block.
  
!  First, we build a 'supergraph' which combines the callgraph and all of
  the CFGs into a single directed graph, with both interprocedural and
  intraprocedural edges.  The nodes and edges in the supergraph are called
! "supernodes" and "superedges", and often referred to in code as 'snodes'
! and 'sedges'.  Basic blocks in the CFGs are split at interprocedural
  calls, so there can be more than one supernode per basic block.  Most
  statements will be in just one supernode, but a call statement can
  appear in two supernodes: at the end of one for the call, and again at
  the start of another for the return.
  
!  The supergraph can be seen using '-fdump-analyzer-supergraph'.
  
!  We then build an 'analysis_plan' which walks the callgraph to determine
  which calls might be suitable for being summarized (rather than fully
  explored) and thus in what order to explore the functions.
  
--- 46850,46874 ----
   The implementation is read-only: it doesn't attempt to change anything,
  just emit warnings.
  
!  The gimple representation can be seen using ‘-fdump-ipa-analyzer’.
       Tip: If the analyzer ICEs before this is written out, one
!      workaround is to use ‘--param=analyzer-bb-explosion-factor=0’ to
       force the analyzer to bail out after analyzing the first basic
       block.
  
!  First, we build a ‘supergraph’ which combines the callgraph and all of
  the CFGs into a single directed graph, with both interprocedural and
  intraprocedural edges.  The nodes and edges in the supergraph are called
! "supernodes" and "superedges", and often referred to in code as ‘snodes’
! and ‘sedges’.  Basic blocks in the CFGs are split at interprocedural
  calls, so there can be more than one supernode per basic block.  Most
  statements will be in just one supernode, but a call statement can
  appear in two supernodes: at the end of one for the call, and again at
  the start of another for the return.
  
!  The supergraph can be seen using ‘-fdump-analyzer-supergraph’.
  
!  We then build an ‘analysis_plan’ which walks the callgraph to determine
  which calls might be suitable for being summarized (rather than fully
  explored) and thus in what order to explore the functions.
  
*************** CFG and supergraph, with points (and thu
*** 46902,46908 ****
  for various events, including before individual statements.  By default
  the exploded graph merges multiple consecutive statements in a supernode
  into one exploded edge to minimize the size of the exploded graph.  This
! can be suppressed via '-fanalyzer-fine-grained'.  The fine-grained
  approach seems to make things simpler and more debuggable that other
  approaches I tried, in that each point is responsible for one thing.
  
--- 46901,46907 ----
  for various events, including before individual statements.  By default
  the exploded graph merges multiple consecutive statements in a supernode
  into one exploded edge to minimize the size of the exploded graph.  This
! can be suppressed via ‘-fanalyzer-fine-grained’.  The fine-grained
  approach seems to make things simpler and more debuggable that other
  approaches I tried, in that each point is responsible for one thing.
  
*************** the stack of callsites below them, so th
*** 46911,46933 ****
  correspond to interprocedurally valid paths: we always return to the
  correct call site, propagating state information accordingly.  We avoid
  infinite recursion by stopping the analysis if a callsite appears more
! than 'analyzer-max-recursion-depth' in a callstring (defaulting to 2).
  
  27.1.2 Graphs
  -------------
  
  Nodes and edges in the exploded graph are called "exploded nodes" and
! "exploded edges" and often referred to in the code as 'enodes' and
! 'eedges' (especially when distinguishing them from the 'snodes' and
! 'sedges' in the supergraph).
  
   Each graph numbers its nodes, giving unique identifiers - supernodes
! are referred to throughout dumps in the form 'SN': INDEX' and exploded
! nodes in the form 'EN: INDEX' (e.g.  'SN: 2' and 'EN:29').
  
!  The supergraph can be seen using '-fdump-analyzer-supergraph-graph'.
  
!  The exploded graph can be seen using '-fdump-analyzer-exploded-graph'
  and other dump options.  Exploded nodes are color-coded in the .dot
  output based on state-machine states to make it easier to see state
  changes at a glance.
--- 46910,46932 ----
  correspond to interprocedurally valid paths: we always return to the
  correct call site, propagating state information accordingly.  We avoid
  infinite recursion by stopping the analysis if a callsite appears more
! than ‘analyzer-max-recursion-depth’ in a callstring (defaulting to 2).
  
  27.1.2 Graphs
  -------------
  
  Nodes and edges in the exploded graph are called "exploded nodes" and
! "exploded edges" and often referred to in the code as ‘enodes’ and
! ‘eedges’ (especially when distinguishing them from the ‘snodes’ and
! ‘sedges’ in the supergraph).
  
   Each graph numbers its nodes, giving unique identifiers - supernodes
! are referred to throughout dumps in the form ‘SN': INDEX’ and exploded
! nodes in the form ‘EN: INDEX’ (e.g.  ‘SN: 2’ and ‘EN:29’).
  
!  The supergraph can be seen using ‘-fdump-analyzer-supergraph-graph’.
  
!  The exploded graph can be seen using ‘-fdump-analyzer-exploded-graph’
  and other dump options.  Exploded nodes are color-coded in the .dot
  output based on state-machine states to make it easier to see state
  changes at a glance.
*************** changes at a glance.
*** 46936,46943 ****
  ---------------------
  
  There's a tension between:
!    * precision of analysis in the straight-line case, vs
!    * exponential blow-up in the face of control flow.
  
   For example, in general, given this CFG:
  
--- 46935,46942 ----
  ---------------------
  
  There's a tension between:
!    • precision of analysis in the straight-line case, vs
!    • exponential blow-up in the face of control flow.
  
   For example, in general, given this CFG:
  
*************** exponential growth of the exploded graph
*** 46975,46981 ****
  
    a. state pruning: which tries to discard state that won't be relevant
       later on withing the function.  This can be disabled via
!      '-fno-analyzer-state-purge'.
  
    b. state merging.  We can try to find the commonality between two
       program_state instances to make a third, simpler program_state.  We
--- 46974,46980 ----
  
    a. state pruning: which tries to discard state that won't be relevant
       later on withing the function.  This can be disabled via
!      ‘-fno-analyzer-state-purge’.
  
    b. state merging.  We can try to find the commonality between two
       program_state instances to make a third, simpler program_state.  We
*************** exponential growth of the exploded graph
*** 47039,47069 ****
       where some duplication has occurred, but only for the places where
       the the different paths are worth exploringly separately.
  
!      Merging can be disabled via '-fno-analyzer-state-merge'.
  
  27.1.4 Region Model
  -------------------
  
! Part of the state stored at a 'exploded_node' is a 'region_model'.  This
  is an implementation of the region-based ternary model described in "A
  Memory Model for Static Analysis of C Programs"
  (https://www.researchgate.net/publication/221430855_A_Memory_Model_for_Static_Analysis_of_C_Programs)
  (Zhongxing Xu, Ted Kremenek, and Jian Zhang).
  
!  A 'region_model' encapsulates a representation of the state of memory,
! with a 'store' recording a binding between 'region' instances, to
! 'svalue' instances.  The bindings are organized into clusters, where
  regions accessible via well-defined pointer arithmetic are in the same
  cluster.  The representation is graph-like because values can be
  pointers to regions.  It also stores a constraint_manager, capturing
  relationships between the values.
  
!  Because each node in the 'exploded_graph' has a 'region_model', and
! each of the latter is graph-like, the 'exploded_graph' is in some ways a
  graph of graphs.
  
!  Here's an example of printing a 'program_state', showing the
! 'region_model' within it, along with state for the 'malloc' state
  machine.
  
       (gdb) call debug (*this)
--- 47038,47068 ----
       where some duplication has occurred, but only for the places where
       the the different paths are worth exploringly separately.
  
!      Merging can be disabled via ‘-fno-analyzer-state-merge’.
  
  27.1.4 Region Model
  -------------------
  
! Part of the state stored at a ‘exploded_node’ is a ‘region_model’.  This
  is an implementation of the region-based ternary model described in "A
  Memory Model for Static Analysis of C Programs"
  (https://www.researchgate.net/publication/221430855_A_Memory_Model_for_Static_Analysis_of_C_Programs)
  (Zhongxing Xu, Ted Kremenek, and Jian Zhang).
  
!  A ‘region_model’ encapsulates a representation of the state of memory,
! with a ‘store’ recording a binding between ‘region’ instances, to
! ‘svalue’ instances.  The bindings are organized into clusters, where
  regions accessible via well-defined pointer arithmetic are in the same
  cluster.  The representation is graph-like because values can be
  pointers to regions.  It also stores a constraint_manager, capturing
  relationships between the values.
  
!  Because each node in the ‘exploded_graph’ has a ‘region_model’, and
! each of the latter is graph-like, the ‘exploded_graph’ is in some ways a
  graph of graphs.
  
!  Here's an example of printing a ‘program_state’, showing the
! ‘region_model’ within it, along with state for the ‘malloc’ state
  machine.
  
       (gdb) call debug (*this)
*************** machine.
*** 47079,47086 ****
       malloc:
         0x2e89590: &HEAP_ALLOCATED_REGION(12): unchecked ('ptr_3')
  
!  This is the state at the point of returning from 'calls_malloc' back to
! 'test' in the following:
  
       void *
       calls_malloc (void)
--- 47078,47085 ----
       malloc:
         0x2e89590: &HEAP_ALLOCATED_REGION(12): unchecked ('ptr_3')
  
!  This is the state at the point of returning from ‘calls_malloc’ back to
! ‘test’ in the following:
  
       void *
       calls_malloc (void)
*************** machine.
*** 47095,47116 ****
         /* etc.  */
       }
  
!  Within the store, there is the cluster for 'ptr_3' within the frame for
! 'test', where the whole cluster is bound to a pointer value, pointing at
! 'HEAP_ALLOCATED_REGION(12)'.  Additionally, this pointer has the
! 'unchecked' state for the 'malloc' state machine indicating it hasn't
  yet been checked against NULL since the allocation call.
  
  27.1.5 Analyzer Paths
  ---------------------
  
  We need to explain to the user what the problem is, and to persuade them
! that there really is a problem.  Hence having a 'diagnostic_path' isn't
  just an incidental detail of the analyzer; it's required.
  
   Paths ought to be:
!    * interprocedurally-valid
!    * feasible
  
   Without state-merging, all paths in the exploded graph are feasible (in
  terms of constraints being satisfied).  With state-merging, paths in the
--- 47094,47115 ----
         /* etc.  */
       }
  
!  Within the store, there is the cluster for ‘ptr_3’ within the frame for
! ‘test’, where the whole cluster is bound to a pointer value, pointing at
! ‘HEAP_ALLOCATED_REGION(12)’.  Additionally, this pointer has the
! ‘unchecked’ state for the ‘malloc’ state machine indicating it hasn't
  yet been checked against NULL since the allocation call.
  
  27.1.5 Analyzer Paths
  ---------------------
  
  We need to explain to the user what the problem is, and to persuade them
! that there really is a problem.  Hence having a ‘diagnostic_path’ isn't
  just an incidental detail of the analyzer; it's required.
  
   Paths ought to be:
!    • interprocedurally-valid
!    • feasible
  
   Without state-merging, all paths in the exploded graph are feasible (in
  terms of constraints being satisfied).  With state-merging, paths in the
*************** target node is the shortest possible pat
*** 47145,47151 ****
  shortest possible path, but if that fails, we explore progressively
  longer paths, eventually trying iterations through loops.  The
  exploration is captured in the feasible_graph, which can be dumped as a
! .dot file via '-fdump-analyzer-feasibility' to visualize the
  exploration.  The indices of the feasible nodes show the order in which
  they were created.  We effectively explore the tree of feasible paths in
  order of shortest path until we either find a feasible path to the
--- 47144,47150 ----
  shortest possible path, but if that fails, we explore progressively
  longer paths, eventually trying iterations through loops.  The
  exploration is captured in the feasible_graph, which can be dumped as a
! .dot file via ‘-fdump-analyzer-feasibility’ to visualize the
  exploration.  The indices of the feasible nodes show the order in which
  they were created.  We effectively explore the tree of feasible paths in
  order of shortest path until we either find a feasible path to the
*************** target node, or hit a limit and give up.
*** 47155,47182 ****
  hopefully keeps the complexity manageable.
  
   This algorithm can be disabled (for debugging purposes) via
! '-fno-analyzer-feasibility', which simply uses the shortest path, and
  notes if it is infeasible.
  
!  The above gives us a shortest feasible 'exploded_path' through the
! 'exploded_graph' (a list of 'exploded_edge *').  We use this
! 'exploded_path' to build a 'diagnostic_path' (a list of *events* for the
! diagnostic subsystem) - specifically a 'checker_path'.
  
!  Having built the 'checker_path', we prune it to try to eliminate events
  that aren't relevant, to minimize how much the user has to read.
  
   After pruning, we notify each event in the path of its ID and record
  the IDs of interesting events, allowing for events to refer to other
! events in their descriptions.  The 'pending_diagnostic' class has
  various vfuncs to support emitting more precise descriptions, so that
  e.g.
  
!    * a deref-of-unchecked-malloc diagnostic might use:
              returning possibly-NULL pointer to 'make_obj' from 'allocator'
!      for a 'return_event' to make it clearer how the unchecked value
       moves from callee back to caller
!    * a double-free diagnostic might use:
              second 'free' here; first 'free' was at (3)
       and a use-after-free might use
              use after 'free' here; memory was freed at (2)
--- 47154,47181 ----
  hopefully keeps the complexity manageable.
  
   This algorithm can be disabled (for debugging purposes) via
! ‘-fno-analyzer-feasibility’, which simply uses the shortest path, and
  notes if it is infeasible.
  
!  The above gives us a shortest feasible ‘exploded_path’ through the
! ‘exploded_graph’ (a list of ‘exploded_edge *’).  We use this
! ‘exploded_path’ to build a ‘diagnostic_path’ (a list of *events* for the
! diagnostic subsystem) - specifically a ‘checker_path’.
  
!  Having built the ‘checker_path’, we prune it to try to eliminate events
  that aren't relevant, to minimize how much the user has to read.
  
   After pruning, we notify each event in the path of its ID and record
  the IDs of interesting events, allowing for events to refer to other
! events in their descriptions.  The ‘pending_diagnostic’ class has
  various vfuncs to support emitting more precise descriptions, so that
  e.g.
  
!    • a deref-of-unchecked-malloc diagnostic might use:
              returning possibly-NULL pointer to 'make_obj' from 'allocator'
!      for a ‘return_event’ to make it clearer how the unchecked value
       moves from callee back to caller
!    • a double-free diagnostic might use:
              second 'free' here; first 'free' was at (3)
       and a use-after-free might use
              use after 'free' here; memory was freed at (2)
*************** e.g.
*** 47186,47206 ****
  27.1.6 Limitations
  ------------------
  
!    * Only for C so far
!    * The implementation of call summaries is currently very simplistic.
!    * Lack of function pointer analysis
!    * The constraint-handling code assumes reflexivity in some places
       (that values are equal to themselves), which is not the case for
       NaN. As a simple workaround, constraints on floating-point values
       are currently ignored.
!    * There are various other limitations in the region model (grep for
       TODO/xfail in the testsuite).
!    * The constraint_manager's implementation of transitivity is
       currently too expensive to enable by default and so must be
!      manually enabled via '-fanalyzer-transitivity').
!    * The checkers are currently hardcoded and don't allow for user
       extensibility (e.g.  adding allocate/release pairs).
!    * Although the analyzer's test suite has a proof-of-concept test case
       for LTO, LTO support hasn't had extensive testing.  There are
       various lang-specific things in the analyzer that assume C rather
       than LTO. For example, SSA names are printed to the user in "raw"
--- 47185,47205 ----
  27.1.6 Limitations
  ------------------
  
!    • Only for C so far
!    • The implementation of call summaries is currently very simplistic.
!    • Lack of function pointer analysis
!    • The constraint-handling code assumes reflexivity in some places
       (that values are equal to themselves), which is not the case for
       NaN. As a simple workaround, constraints on floating-point values
       are currently ignored.
!    • There are various other limitations in the region model (grep for
       TODO/xfail in the testsuite).
!    • The constraint_manager's implementation of transitivity is
       currently too expensive to enable by default and so must be
!      manually enabled via ‘-fanalyzer-transitivity’).
!    • The checkers are currently hardcoded and don't allow for user
       extensibility (e.g.  adding allocate/release pairs).
!    • Although the analyzer's test suite has a proof-of-concept test case
       for LTO, LTO support hasn't had extensive testing.  There are
       various lang-specific things in the analyzer that assume C rather
       than LTO. For example, SSA names are printed to the user in "raw"
*************** together:
*** 47226,47263 ****
  
   where:
  
!    * './xgcc -B.' is the usual way to invoke a self-built GCC from
!      within the 'BUILDDIR/gcc' subdirectory.
  
!    * '-S' so that the driver ('./xgcc') invokes 'cc1', but doesn't
       bother running the assembler or linker (since the analyzer runs
!      inside 'cc1').
  
!    * '-fanalyzer' enables the analyzer, obviously.
  
!    * '-wrapper gdb,--args' invokes 'cc1' under the debugger so that I
!      can debug 'cc1' and set breakpoints and step through things.
  
!    * '-fdump-analyzer-stderr' so that the logging interface is enabled
       and goes to stderr, which often gives valuable context into what's
       happening when stepping through the analyzer
  
!    * '-fanalyzer-fine-grained' which splits the effect of every
       statement into its own exploded_node, rather than the default
       (which tries to combine successive stmts to reduce the size of the
       exploded_graph).  This makes it easier to see exactly where a
       particular change happens.
  
!    * '-fdump-ipa-analyzer=stderr' which dumps the GIMPLE IR seen by the
       analyzer pass to stderr
  
   Other useful options:
  
!    * '-fdump-analyzer-exploded-graph' which dumps a 'SRC.eg.dot'
       GraphViz file that I can look at (with python-xdot)
  
!    * '-fdump-analyzer-exploded-nodes-2' which dumps a 'SRC.eg.txt' file
!      containing the full 'exploded_graph'.
  
   Assuming that you have the python support scripts for gdb installed,
  you can use:
--- 47225,47262 ----
  
   where:
  
!    • ‘./xgcc -B.’ is the usual way to invoke a self-built GCC from
!      within the ‘BUILDDIR/gcc’ subdirectory.
  
!    • ‘-S’ so that the driver (‘./xgcc’) invokes ‘cc1’, but doesn't
       bother running the assembler or linker (since the analyzer runs
!      inside ‘cc1’).
  
!    • ‘-fanalyzer’ enables the analyzer, obviously.
  
!    • ‘-wrapper gdb,--args’ invokes ‘cc1’ under the debugger so that I
!      can debug ‘cc1’ and set breakpoints and step through things.
  
!    • ‘-fdump-analyzer-stderr’ so that the logging interface is enabled
       and goes to stderr, which often gives valuable context into what's
       happening when stepping through the analyzer
  
!    • ‘-fanalyzer-fine-grained’ which splits the effect of every
       statement into its own exploded_node, rather than the default
       (which tries to combine successive stmts to reduce the size of the
       exploded_graph).  This makes it easier to see exactly where a
       particular change happens.
  
!    • ‘-fdump-ipa-analyzer=stderr’ which dumps the GIMPLE IR seen by the
       analyzer pass to stderr
  
   Other useful options:
  
!    • ‘-fdump-analyzer-exploded-graph’ which dumps a ‘SRC.eg.dot’
       GraphViz file that I can look at (with python-xdot)
  
!    • ‘-fdump-analyzer-exploded-nodes-2’ which dumps a ‘SRC.eg.txt’ file
!      containing the full ‘exploded_graph’.
  
   Assuming that you have the python support scripts for gdb installed,
  you can use:
*************** you can use:
*** 47265,47271 ****
       (gdb) break-on-saved-diagnostic
  
   to put a breakpoint at the place where a diagnostic is saved during
! 'exploded_graph' exploration, to see where a particular diagnostic is
  being saved, and:
  
       (gdb) break-on-diagnostic
--- 47264,47270 ----
       (gdb) break-on-saved-diagnostic
  
   to put a breakpoint at the place where a diagnostic is saved during
! ‘exploded_graph’ exploration, to see where a particular diagnostic is
  being saved, and:
  
       (gdb) break-on-diagnostic
*************** The analyzer recognizes various special
*** 47280,47290 ****
  debugging the analyzer, and for use in DejaGnu tests.
  
   The declarations of these functions can be seen in the testsuite in
! 'analyzer-decls.h'.  None of these functions are actually implemented in
! terms of code, merely as 'known_function' subclasses (in
! 'gcc/analyzer/kf-analyzer.cc').
  
! '__analyzer_break'
       Add:
              __analyzer_break ();
       to the source being analyzed to trigger a breakpoint in the
--- 47279,47289 ----
  debugging the analyzer, and for use in DejaGnu tests.
  
   The declarations of these functions can be seen in the testsuite in
! ‘analyzer-decls.h’.  None of these functions are actually implemented in
! terms of code, merely as ‘known_function’ subclasses (in
! ‘gcc/analyzer/kf-analyzer.cc’).
  
! ‘__analyzer_break’
       Add:
              __analyzer_break ();
       to the source being analyzed to trigger a breakpoint in the
*************** terms of code, merely as 'known_function
*** 47292,47298 ****
       in the source, it's much easier to effectively step through the
       program state as it's analyzed.
  
! '__analyzer_describe'
       The analyzer handles:
  
            __analyzer_describe (0, expr);
--- 47291,47297 ----
       in the source, it's much easier to effectively step through the
       program state as it's analyzed.
  
! ‘__analyzer_describe’
       The analyzer handles:
  
            __analyzer_describe (0, expr);
*************** terms of code, merely as 'known_function
*** 47301,47326 ****
       any type), at a verbosity level given by the 1st argument.  This is
       for use when debugging, and may be of use in DejaGnu tests.
  
! '__analyzer_dump'
            __analyzer_dump ();
  
       will dump the copious information about the analyzer's state each
       time it reaches the call in its traversal of the source.
  
! '__analyzer_dump_capacity'
            extern void __analyzer_dump_capacity (const void *ptr);
  
       will emit a warning describing the capacity of the base region of
       the region pointed to by the 1st argument.
  
! '__analyzer_dump_escaped'
            extern void __analyzer_dump_escaped (void);
  
       will emit a warning giving the number of decls that have escaped on
       this analysis path, followed by a comma-separated list of their
       names, in alphabetical order.
  
! '__analyzer_dump_path'
            __analyzer_dump_path ();
  
       will emit a placeholder "note" diagnostic with a path to that call
--- 47300,47325 ----
       any type), at a verbosity level given by the 1st argument.  This is
       for use when debugging, and may be of use in DejaGnu tests.
  
! ‘__analyzer_dump’
            __analyzer_dump ();
  
       will dump the copious information about the analyzer's state each
       time it reaches the call in its traversal of the source.
  
! ‘__analyzer_dump_capacity’
            extern void __analyzer_dump_capacity (const void *ptr);
  
       will emit a warning describing the capacity of the base region of
       the region pointed to by the 1st argument.
  
! ‘__analyzer_dump_escaped’
            extern void __analyzer_dump_escaped (void);
  
       will emit a warning giving the number of decls that have escaped on
       this analysis path, followed by a comma-separated list of their
       names, in alphabetical order.
  
! ‘__analyzer_dump_path’
            __analyzer_dump_path ();
  
       will emit a placeholder "note" diagnostic with a path to that call
*************** terms of code, merely as 'known_function
*** 47328,47335 ****
       useful for writing DejaGnu tests for constraint-tracking and
       feasibility checking.
  
! '__analyzer_dump_exploded_nodes'
!      For every callsite to '__analyzer_dump_exploded_nodes' the analyzer
       will emit a warning after it finished the analysis containing
       information on all of the exploded nodes at that program point.
  
--- 47327,47334 ----
       useful for writing DejaGnu tests for constraint-tracking and
       feasibility checking.
  
! ‘__analyzer_dump_exploded_nodes’
!      For every callsite to ‘__analyzer_dump_exploded_nodes’ the analyzer
       will emit a warning after it finished the analysis containing
       information on all of the exploded nodes at that program point.
  
*************** terms of code, merely as 'known_function
*** 47346,47353 ****
  
       it will also dump all of the states within the "processed" nodes.
  
! '__analyzer_dump_named_constant'
!      When the analyzer sees a call to '__analyzer_dump_named_constant'
       it will emit a warning describing what is known about the value of
       a given named constant, for parts of the analyzer that interact
       with target headers.
--- 47345,47352 ----
  
       it will also dump all of the states within the "processed" nodes.
  
! ‘__analyzer_dump_named_constant’
!      When the analyzer sees a call to ‘__analyzer_dump_named_constant’
       it will emit a warning describing what is known about the value of
       a given named constant, for parts of the analyzer that interact
       with target headers.
*************** terms of code, merely as 'known_function
*** 47360,47370 ****
  
            warning: named constant 'O_RDONLY' has value '1'
  
! '__analyzer_dump_region_model'
               __analyzer_dump_region_model ();
       will dump the region_model's state to stderr.
  
! '__analyzer_dump_state'
            __analyzer_dump_state ("malloc", ptr);
  
       will emit a warning describing the state of the 2nd argument (which
--- 47359,47369 ----
  
            warning: named constant 'O_RDONLY' has value '1'
  
! ‘__analyzer_dump_region_model’
               __analyzer_dump_region_model ();
       will dump the region_model's state to stderr.
  
! ‘__analyzer_dump_state’
            __analyzer_dump_state ("malloc", ptr);
  
       will emit a warning describing the state of the 2nd argument (which
*************** terms of code, merely as 'known_function
*** 47372,47413 ****
       matching the 1st argument (which must be a string literal).  This
       is for use when debugging, and may be of use in DejaGnu tests.
  
! '__analyzer_eval'
            __analyzer_eval (expr);
       will emit a warning with text "TRUE", FALSE" or "UNKNOWN" based on
       the truthfulness of the argument.  This is useful for writing
       DejaGnu tests.
  
! '__analyzer_get_unknown_ptr'
            __analyzer_get_unknown_ptr ();
!      will obtain an unknown 'void *'.
  
  27.2.2 Other Debugging Techniques
  ---------------------------------
  
  To compare two different exploded graphs, try
! '-fdump-analyzer-exploded-nodes-2 -fdump-noaddr
! -fanalyzer-fine-grained'.  This will dump a 'SRC.eg.txt' file containing
! the full 'exploded_graph'.  I use 'diff -u50 -p' to compare two
  different such files (e.g.  before and after a patch) to find the first
! place where the two graphs diverge.  The option '-fdump-noaddr' will
  suppress printing pointers withihn the dumps (which would otherwise hide
  the real differences with irrelevent churn).
  
!  The option '-fdump-analyzer-json' will dump both the supergraph and the
  exploded graph in compressed JSON form.
  
   One approach when tracking down where a particular bogus state is
! introduced into the 'exploded_graph' is to add custom code to
! 'program_state::validate'.
  
!  The debug function 'region::is_named_decl_p' can be used when
  debugging, such as for assertions and conditional breakpoints.  For
  example, when tracking down a bug in handling a decl called
! 'yy_buffer_stack', I temporarily added a:
         gcc_assert (!m_base_region->is_named_decl_p ("yy_buffer_stack"));
!  to 'binding_cluster::mark_as_escaped' to trap a point where
! 'yy_buffer_stack' was mistakenly being treated as having escaped.
  
  
  File: gccint.info,  Node: User Experience Guidelines,  Next: Funding,  Prev: Static Analyzer,  Up: Top
--- 47371,47412 ----
       matching the 1st argument (which must be a string literal).  This
       is for use when debugging, and may be of use in DejaGnu tests.
  
! ‘__analyzer_eval’
            __analyzer_eval (expr);
       will emit a warning with text "TRUE", FALSE" or "UNKNOWN" based on
       the truthfulness of the argument.  This is useful for writing
       DejaGnu tests.
  
! ‘__analyzer_get_unknown_ptr’
            __analyzer_get_unknown_ptr ();
!      will obtain an unknown ‘void *’.
  
  27.2.2 Other Debugging Techniques
  ---------------------------------
  
  To compare two different exploded graphs, try
! ‘-fdump-analyzer-exploded-nodes-2 -fdump-noaddr
! -fanalyzer-fine-grained’.  This will dump a ‘SRC.eg.txt’ file containing
! the full ‘exploded_graph’.  I use ‘diff -u50 -p’ to compare two
  different such files (e.g.  before and after a patch) to find the first
! place where the two graphs diverge.  The option ‘-fdump-noaddr’ will
  suppress printing pointers withihn the dumps (which would otherwise hide
  the real differences with irrelevent churn).
  
!  The option ‘-fdump-analyzer-json’ will dump both the supergraph and the
  exploded graph in compressed JSON form.
  
   One approach when tracking down where a particular bogus state is
! introduced into the ‘exploded_graph’ is to add custom code to
! ‘program_state::validate’.
  
!  The debug function ‘region::is_named_decl_p’ can be used when
  debugging, such as for assertions and conditional breakpoints.  For
  example, when tracking down a bug in handling a decl called
! ‘yy_buffer_stack’, I temporarily added a:
         gcc_assert (!m_base_region->is_named_decl_p ("yy_buffer_stack"));
!  to ‘binding_cluster::mark_as_escaped’ to trap a point where
! ‘yy_buffer_stack’ was mistakenly being treated as having escaped.
  
  
  File: gccint.info,  Node: User Experience Guidelines,  Next: Funding,  Prev: Static Analyzer,  Up: Top
*************** source language, rather than GCC's own i
*** 47448,47454 ****
  28.1.2 Diagnostics are actionable
  ---------------------------------
  
! A good diagnostic is "actionable": it should assist the user in taking
  action.
  
   Consider what an end user will want to do when encountering a
--- 47447,47453 ----
  28.1.2 Diagnostics are actionable
  ---------------------------------
  
! A good diagnostic is “actionable”: it should assist the user in taking
  action.
  
   Consider what an end user will want to do when encountering a
*************** diagnostic.
*** 47458,47466 ****
  
   Given a warning, an end user will think:
  
!    * "Is this a real problem?"
!    * "Do I care?"
!    * if they decide it's genuine: "How do I fix this?"
  
   A good diagnostic provides pertinent information to allow the user to
  easily answer the above questions.
--- 47457,47465 ----
  
   Given a warning, an end user will think:
  
!    • "Is this a real problem?"
!    • "Do I care?"
!    • if they decide it's genuine: "How do I fix this?"
  
   A good diagnostic provides pertinent information to allow the user to
  easily answer the above questions.
*************** A perfect compiler would issue a warning
*** 47472,47480 ****
  source code that ought to be fixed, and issue no other warnings.
  Naturally, this ideal is impossible to achieve.
  
!  Warnings should have a good "signal-to-noise ratio": we should have few
! "false positives" (falsely issuing a warning when no warning is
! warranted) and few "false negatives" (failing to issue a warning when
  one _is_ justified).
  
   Note that a false positive can mean, in practice, a warning that the
--- 47471,47479 ----
  source code that ought to be fixed, and issue no other warnings.
  Naturally, this ideal is impossible to achieve.
  
!  Warnings should have a good “signal-to-noise ratio”: we should have few
! “false positives” (falsely issuing a warning when no warning is
! warranted) and few “false negatives” (failing to issue a warning when
  one _is_ justified).
  
   Note that a false positive can mean, in practice, a warning that the
*************** against overloading the user with irrele
*** 47488,47501 ****
  
  GCC is typically used in two different ways:
  
!    * Semi-interactive usage: GCC is used as a development tool when the
       user is writing code, as the "compile" part of the
       "edit-compile-debug" cycle.  The user is actively hacking on the
       code themself (perhaps a project they wrote, or someone else's),
       where they just made a change to the code and want to see what
       happens, and to be warned about mistakes.
  
!    * Batch rebuilds: where the user is recompiling one or more existing
       packages, and GCC is a detail that's being invoked by various build
       scripts.  Examples include a user trying to bring up an operating
       system consisting of hundreds of packages on a new CPU
--- 47487,47500 ----
  
  GCC is typically used in two different ways:
  
!    • Semi-interactive usage: GCC is used as a development tool when the
       user is writing code, as the "compile" part of the
       "edit-compile-debug" cycle.  The user is actively hacking on the
       code themself (perhaps a project they wrote, or someone else's),
       where they just made a change to the code and want to see what
       happens, and to be warned about mistakes.
  
!    • Batch rebuilds: where the user is recompiling one or more existing
       packages, and GCC is a detail that's being invoked by various build
       scripts.  Examples include a user trying to bring up an operating
       system consisting of hundreds of packages on a new CPU
*************** problem is.  For example, the vaguely-wo
*** 47520,47526 ****
  doesn't tell the user why the attribute was ignored, or what kind of
  entity the compiler thought the attribute was being applied to (the
  source location for the diagnostic is also poor; *note discussion of
! 'input_location': input_location_example.).  A better message would be:
  
       demo.c:1:24: warning: attribute 'noinline' on variable 'foo' was
          ignored [-Wattributes]
--- 47519,47525 ----
  doesn't tell the user why the attribute was ignored, or what kind of
  entity the compiler thought the attribute was being applied to (the
  source location for the diagnostic is also poor; *note discussion of
! ‘input_location’: input_location_example.).  A better message would be:
  
       demo.c:1:24: warning: attribute 'noinline' on variable 'foo' was
          ignored [-Wattributes]
*************** what it doesn't complain about.
*** 47550,47572 ****
  
  Many diagnostics relate to a mismatch between two different places in
  the user's source code.  Examples include:
!    * a type mismatch, where the type at a usage site does not match the
       type at a declaration
  
!    * the argument count at a call site does not match the parameter
       count at the declaration
  
!    * something is erroneously duplicated (e.g. an error, due to breaking
       a uniqueness requirement, or a warning, if it's suggestive of a
       bug)
  
!    * an "opened" syntactic construct (such as an open-parenthesis) is
       not closed
  
   In each case, the diagnostic should indicate *both* pertinent locations
  (so that the user can easily see the problem and how to fix it).
  
!  The standard way to do this is with a note (via 'inform').  For
  example:
  
         auto_diagnostic_group d;
--- 47549,47571 ----
  
  Many diagnostics relate to a mismatch between two different places in
  the user's source code.  Examples include:
!    • a type mismatch, where the type at a usage site does not match the
       type at a declaration
  
!    • the argument count at a call site does not match the parameter
       count at the declaration
  
!    • something is erroneously duplicated (e.g. an error, due to breaking
       a uniqueness requirement, or a warning, if it's suggestive of a
       bug)
  
!    • an "opened" syntactic construct (such as an open-parenthesis) is
       not closed
  
   In each case, the diagnostic should indicate *both* pertinent locations
  (so that the user can easily see the problem and how to fix it).
  
!  The standard way to do this is with a note (via ‘inform’).  For
  example:
  
         auto_diagnostic_group d;
*************** which leads to:
*** 47584,47596 ****
           3 |   if (flag > 3)
             |       ~~~~~^~~
  
! The 'inform' call should be guarded by the return value from the
! 'warning_at' call so that the note isn't emitted when the warning is
  suppressed.
  
   For cases involving punctuation where the locations might be near each
  other, they can be conditionally consolidated via
! 'gcc_rich_location::add_location_if_nearby':
  
           auto_diagnostic_group d;
           gcc_rich_location richloc (primary_loc);
--- 47583,47595 ----
           3 |   if (flag > 3)
             |       ~~~~~^~~
  
! The ‘inform’ call should be guarded by the return value from the
! ‘warning_at’ call so that the note isn't emitted when the warning is
  suppressed.
  
   For cases involving punctuation where the locations might be near each
  other, they can be conditionally consolidated via
! ‘gcc_rich_location::add_location_if_nearby’:
  
           auto_diagnostic_group d;
           gcc_rich_location richloc (primary_loc);
*************** or two diagnostics:
*** 47616,47626 ****
  28.1.8 Location Information
  ---------------------------
  
! GCC's 'location_t' type can support both ordinary locations, and
  locations relating to a macro expansion.
  
   As of GCC 6, ordinary locations changed from supporting just a point in
! the user's source code to supporting three points: the "caret" location,
  plus a start and a finish:
  
             a = foo && bar;
--- 47615,47625 ----
  28.1.8 Location Information
  ---------------------------
  
! GCC's ‘location_t’ type can support both ordinary locations, and
  locations relating to a macro expansion.
  
   As of GCC 6, ordinary locations changed from supporting just a point in
! the user's source code to supporting three points: the “caret” location,
  plus a start and a finish:
  
             a = foo && bar;
*************** plus a start and a finish:
*** 47630,47637 ****
                 |   caret
                 start
  
!  Tokens coming out of libcpp have locations of the form 'caret ==
! start', such as for 'foo' here:
  
             a = foo && bar;
                 ^~~
--- 47629,47636 ----
                 |   caret
                 start
  
!  Tokens coming out of libcpp have locations of the form ‘caret ==
! start’, such as for ‘foo’ here:
  
             a = foo && bar;
                 ^~~
*************** start', such as for 'foo' here:
*** 47642,47648 ****
   Compound expressions should be reported using the location of the
  expression as a whole, rather than just of one token within it.
  
!  For example, in '-Wformat', rather than underlining just the first
  token of a bad argument:
  
          printf("hello %i %s", (long)0, "world");
--- 47641,47647 ----
   Compound expressions should be reported using the location of the
  expression as a whole, rather than just of one token within it.
  
!  For example, in ‘-Wformat’, rather than underlining just the first
  token of a bad argument:
  
          printf("hello %i %s", (long)0, "world");
*************** easily identify what is being referred t
*** 47656,47669 ****
                        ~^      ~~~~~~~
                        %li
  
!  Avoid using the 'input_location' global, and the diagnostic functions
! that implicitly use it--use 'error_at' and 'warning_at' rather than
! 'error' and 'warning', and provide the most appropriate 'location_t'
  value available at that phase of the compilation.  It's possible to
! supply secondary 'location_t' values via 'rich_location'.
  
  For example, in the example of imprecise wording above, generating the
! diagnostic using 'warning':
  
         // BAD: implicitly uses input_location
         warning (OPT_Wattributes, "%qE attribute ignored", name);
--- 47655,47668 ----
                        ~^      ~~~~~~~
                        %li
  
!  Avoid using the ‘input_location’ global, and the diagnostic functions
! that implicitly use it--use ‘error_at’ and ‘warning_at’ rather than
! ‘error’ and ‘warning’, and provide the most appropriate ‘location_t’
  value available at that phase of the compilation.  It's possible to
! supply secondary ‘location_t’ values via ‘rich_location’.
  
  For example, in the example of imprecise wording above, generating the
! diagnostic using ‘warning’:
  
         // BAD: implicitly uses input_location
         warning (OPT_Wattributes, "%qE attribute ignored", name);
*************** leads to:
*** 47675,47682 ****
           1 | int foo __attribute__((noinline));
             | ^~~
  
! which thus happened to use the location of the 'int' token, rather than
! that of the attribute.  Using 'warning_at' with the location of the
  attribute, providing the location of the declaration in question as a
  secondary location, and adding a note:
  
--- 47674,47681 ----
           1 | int foo __attribute__((noinline));
             | ^~~
  
! which thus happened to use the location of the ‘int’ token, rather than
! that of the attribute.  Using ‘warning_at’ with the location of the
  attribute, providing the location of the declaration in question as a
  secondary location, and adding a note:
  
*************** See the diagnostics section
*** 47703,47712 ****
  (https://gcc.gnu.org/codingconventions.html#Diagnostics) of the GCC
  coding conventions.
  
!  In the C++ front end, when comparing two types in a message, use '%H'
! and '%I' rather than '%T', as this allows the diagnostics subsystem to
  highlight differences between template-based types.  For example, rather
! than using '%qT':
  
         // BAD: a pair of %qT used in C++ front end for type comparison
         error_at (loc, "could not convert %qE from %qT to %qT", expr,
--- 47702,47711 ----
  (https://gcc.gnu.org/codingconventions.html#Diagnostics) of the GCC
  coding conventions.
  
!  In the C++ front end, when comparing two types in a message, use ‘%H’
! and ‘%I’ rather than ‘%T’, as this allows the diagnostics subsystem to
  highlight differences between template-based types.  For example, rather
! than using ‘%qT’:
  
         // BAD: a pair of %qT used in C++ front end for type comparison
         error_at (loc, "could not convert %qE from %qT to %qT", expr,
*************** which could lead to:
*** 47717,47723 ****
       error: could not convert 'map()' from 'map'
          to 'map'
  
! using '%H' and '%I' (via '%qH' and '%qI'):
  
         // OK: compare types in C++ front end via %qH and %qI
         error_at (loc, "could not convert %qE from %qH to %qI", expr,
--- 47716,47722 ----
       error: could not convert 'map()' from 'map'
          to 'map'
  
! using ‘%H’ and ‘%I’ (via ‘%qH’ and ‘%qI’):
  
         // OK: compare types in C++ front end via %qH and %qI
         error_at (loc, "could not convert %qE from %qH to %qI", expr,
*************** allows the above output to be simplified
*** 47728,47762 ****
       error: could not convert 'map()' from 'map<[...],double>'
          to 'map<[...],int>'
  
! where the 'double' and 'int' are colorized to highlight them.
  
  28.1.10 Group logically-related diagnostics
  -------------------------------------------
  
! Use 'auto_diagnostic_group' when issuing multiple related diagnostics
  (seen in various examples on this page).  This informs the diagnostic
  subsystem that all diagnostics issued within the lifetime of the
! 'auto_diagnostic_group' are related.  For example,
! '-fdiagnostics-format=json' will treat the first diagnostic emitted
  within the group as a top-level diagnostic, and all subsequent
  diagnostics within the group as its children.
  
  28.1.11 Quoting
  ---------------
  
! Text should be quoted by either using the 'q' modifier in a directive
! such as '%qE', or by enclosing the quoted text in a pair of '%<' and
! '%>' directives, and never by using explicit quote characters.  The
  directives handle the appropriate quote characters for each language and
  apply the correct color or highlighting.
  
   The following elements should be quoted in GCC diagnostics:
  
!    * Language keywords.
!    * Tokens.
!    * Boolean, numerical, character, and string constants that appear in
       the source code.
!    * Identifiers, including function, macro, type, and variable names.
  
   Other elements such as numbers that do not refer to numeric constants
  that appear in the source code should not be quoted.  For example, in
--- 47727,47761 ----
       error: could not convert 'map()' from 'map<[...],double>'
          to 'map<[...],int>'
  
! where the ‘double’ and ‘int’ are colorized to highlight them.
  
  28.1.10 Group logically-related diagnostics
  -------------------------------------------
  
! Use ‘auto_diagnostic_group’ when issuing multiple related diagnostics
  (seen in various examples on this page).  This informs the diagnostic
  subsystem that all diagnostics issued within the lifetime of the
! ‘auto_diagnostic_group’ are related.  For example,
! ‘-fdiagnostics-format=json’ will treat the first diagnostic emitted
  within the group as a top-level diagnostic, and all subsequent
  diagnostics within the group as its children.
  
  28.1.11 Quoting
  ---------------
  
! Text should be quoted by either using the ‘q’ modifier in a directive
! such as ‘%qE’, or by enclosing the quoted text in a pair of ‘%<’ and
! ‘%>’ directives, and never by using explicit quote characters.  The
  directives handle the appropriate quote characters for each language and
  apply the correct color or highlighting.
  
   The following elements should be quoted in GCC diagnostics:
  
!    • Language keywords.
!    • Tokens.
!    • Boolean, numerical, character, and string constants that appear in
       the source code.
!    • Identifiers, including function, macro, type, and variable names.
  
   Other elements such as numbers that do not refer to numeric constants
  that appear in the source code should not be quoted.  For example, in
*************** of the GCC coding conventions.
*** 47777,47800 ****
  28.1.13 Fix-it hints
  --------------------
  
! GCC's diagnostic subsystem can emit "fix-it hints": small suggested
  edits to the user's source code.
  
   They are printed by default underneath the code in question.  They can
! also be viewed via '-fdiagnostics-generate-patch' and
! '-fdiagnostics-parseable-fixits'.  With the latter, an IDE ought to be
  able to offer to automatically apply the suggested fix.
  
   Fix-it hints contain code fragments, and thus they should not be marked
  for translation.
  
!  Fix-it hints can be added to a diagnostic by using a 'rich_location'
! rather than a 'location_t' - the fix-it hints are added to the
! 'rich_location' using one of the various 'add_fixit' member functions of
! 'rich_location'.  They are documented with 'rich_location' in
! 'libcpp/line-map.h'.  It's easiest to use the 'gcc_rich_location'
! subclass of 'rich_location' found in 'gcc-rich-location.h', as this
! implicitly supplies the 'line_table' variable.
  
   For example:
  
--- 47776,47799 ----
  28.1.13 Fix-it hints
  --------------------
  
! GCC's diagnostic subsystem can emit “fix-it hints”: small suggested
  edits to the user's source code.
  
   They are printed by default underneath the code in question.  They can
! also be viewed via ‘-fdiagnostics-generate-patch’ and
! ‘-fdiagnostics-parseable-fixits’.  With the latter, an IDE ought to be
  able to offer to automatically apply the suggested fix.
  
   Fix-it hints contain code fragments, and thus they should not be marked
  for translation.
  
!  Fix-it hints can be added to a diagnostic by using a ‘rich_location’
! rather than a ‘location_t’ - the fix-it hints are added to the
! ‘rich_location’ using one of the various ‘add_fixit’ member functions of
! ‘rich_location’.  They are documented with ‘rich_location’ in
! ‘libcpp/line-map.h’.  It's easiest to use the ‘gcc_rich_location’
! subclass of ‘rich_location’ found in ‘gcc-rich-location.h’, as this
! implicitly supplies the ‘line_table’ variable.
  
   For example:
  
*************** which can lead to:
*** 47816,47837 ****
             | signed
  
   Non-trivial edits can be built up by adding multiple fix-it hints to
! one 'rich_location'.  It's best to express the edits in terms of the
  locations of individual tokens.  Various handy functions for adding
  fix-it hints for idiomatic C and C++ can be seen in
! 'gcc-rich-location.h'.
  
  28.1.13.1 Fix-it hints should work
  ..................................
  
  When implementing a fix-it hint, please verify that the suggested edit
  leads to fixed, compilable code.  (Unfortunately, this currently must be
! done by hand using '-fdiagnostics-generate-patch'.  It would be good to
  have an automated way of verifying that fix-it hints actually fix the
  code).
  
   For example, a "gotcha" here is to forget to add a space when adding a
! missing reserved word.  Consider a C++ fix-it hint that adds 'typename'
  in front of a template declaration.  A naive way to implement this might
  be:
  
--- 47815,47836 ----
             | signed
  
   Non-trivial edits can be built up by adding multiple fix-it hints to
! one ‘rich_location’.  It's best to express the edits in terms of the
  locations of individual tokens.  Various handy functions for adding
  fix-it hints for idiomatic C and C++ can be seen in
! ‘gcc-rich-location.h’.
  
  28.1.13.1 Fix-it hints should work
  ..................................
  
  When implementing a fix-it hint, please verify that the suggested edit
  leads to fixed, compilable code.  (Unfortunately, this currently must be
! done by hand using ‘-fdiagnostics-generate-patch’.  It would be good to
  have an automated way of verifying that fix-it hints actually fix the
  code).
  
   For example, a "gotcha" here is to forget to add a space when adding a
! missing reserved word.  Consider a C++ fix-it hint that adds ‘typename’
  in front of a template declaration.  A naive way to implement this might
  be:
  
*************** being "corrected" to:
*** 47851,47857 ****
       typenameT::type x;
  
  In this case, the correct thing to do is to add a trailing space after
! 'typename':
  
       gcc_rich_location richloc (loc);
       // OK: note that here we have a trailing space
--- 47850,47856 ----
       typenameT::type x;
  
  In this case, the correct thing to do is to add a trailing space after
! ‘typename’:
  
       gcc_rich_location richloc (loc);
       // OK: note that here we have a trailing space
*************** this:
*** 47878,47884 ****
           warning_at (&richloc, OPT_Wredundant_move,
                       "redundant move in return statement");
  
! which is intended to e.g. replace a 'std::move' with the underlying
  value:
  
          return std::move (retval);
--- 47877,47883 ----
           warning_at (&richloc, OPT_Wredundant_move,
                       "redundant move in return statement");
  
! which is intended to e.g. replace a ‘std::move’ with the underlying
  value:
  
          return std::move (retval);
*************** and thus this resulting code:
*** 47912,47918 ****
          return global_a;
  
  It's better to do deletions in terms of deletions; deleting the
! 'std::move (' and the trailing close-paren, leading to this:
  
          return std::move (CONFIGURY_GLOBAL /* some comment */);
                 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--- 47911,47917 ----
          return global_a;
  
  It's better to do deletions in terms of deletions; deleting the
! ‘std::move (’ and the trailing close-paren, leading to this:
  
          return std::move (CONFIGURY_GLOBAL /* some comment */);
                 ~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*************** and thus this result:
*** 47922,47928 ****
  
          return CONFIGURY_GLOBAL /* some comment */;
  
! Unfortunately, the pertinent 'location_t' values are not always
  available.
  
  28.1.13.3 Multiple suggestions
--- 47921,47927 ----
  
          return CONFIGURY_GLOBAL /* some comment */;
  
! Unfortunately, the pertinent ‘location_t’ values are not always
  available.
  
  28.1.13.3 Multiple suggestions
*************** available.
*** 47930,47938 ****
  
  In the rare cases where you need to suggest more than one mutually
  exclusive solution to a problem, this can be done by emitting multiple
! notes and calling 'rich_location::fixits_cannot_be_auto_applied' on each
! note's 'rich_location'.  If this is called, then the fix-it hints in the
! 'rich_location' will be printed, but will not be added to generated
  patches.
  
  
--- 47929,47937 ----
  
  In the rare cases where you need to suggest more than one mutually
  exclusive solution to a problem, this can be done by emitting multiple
! notes and calling ‘rich_location::fixits_cannot_be_auto_applied’ on each
! note's ‘rich_location’.  If this is called, then the fix-it hints in the
! ‘rich_location’ will be printed, but will not be added to generated
  patches.
  
  
*************** more; major new features or packages con
*** 47987,47993 ****
  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.
  
--- 47986,47992 ----
  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 © 1994 Free Software Foundation, Inc.
       Verbatim copying and redistribution of this section is permitted
       without royalty; alteration is not permitted.
  
*************** GNU General Public License
*** 48016,48022 ****
  
                          Version 3, 29 June 2007
  
!      Copyright (C) 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
--- 48015,48021 ----
  
                          Version 3, 29 June 2007
  
!      Copyright © 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
*************** mail.
*** 48703,48713 ****
  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".
--- 48702,48712 ----
  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".
*************** GNU Free Documentation License
*** 48732,48738 ****
  
                       Version 1.3, 3 November 2008
  
!      Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
--- 48731,48737 ----
  
                       Version 1.3, 3 November 2008
  
!      Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
*************** GNU Free Documentation License
*** 48741,48747 ****
    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
--- 48740,48746 ----
    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
*************** Any omissions in this list are accidenta
*** 49219,49603 ****
  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 DWARF 2 support, faster/better
       optimizations, improved alias analysis, plus migrating GCC to
       Bugzilla.
  
!    * Geoff Berry for his Java object serialization work and various
       patches.
  
!    * David Binderman tests weekly snapshots of GCC trunk against Fedora
       Rawhide for several architectures.
  
!    * Laurynas Biveinis for memory management work and DJGPP port fixes.
  
!    * 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.
  
!    * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
       other Java work.
  
!    * Segher Boessenkool for helping maintain the PowerPC port and the
       instruction combiner plus various contributions to the middle end.
  
!    * 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.
  
!    * James Bowman for the FT32 port.
  
!    * 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 from its
       creation to 2013.
  
!    * Iain Buclaw for the D frontend.
  
!    * Craig Burley for leadership of the G77 Fortran effort.
  
!    * Tobias Burnus for contributions to GNU Fortran.
  
!    * 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.
  
!    * Kito Cheng for his work on the RISC-V port, including bringing up
       the test suite and maintenance.
  
!    * Scott Christley for his Objective-C contributions.
  
!    * Eric Christopher for his Java porting help and clean-ups.
  
!    * Branko Cibej for more warning contributions.
  
!    * The GNU Classpath project for all of their merged runtime code.
  
!    * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work,
!      '--help', and other random hacking.
  
!    * Michael Cook for libstdc++ cleanup patches to reduce warnings.
  
!    * R. Kelley Cook for making GCC buildable from a read-only directory
       as well as other miscellaneous build process and documentation
       clean-ups.
  
!    * Ralf Corsepius for SH testing and minor bug fixing.
  
!    * François-Xavier Coudert for contributions to GNU Fortran.
  
!    * 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.
  
!    * Palmer Dabbelt for his work maintaining the RISC-V port.
  
!    * 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.
  
!    * Jerry DeLisle for contributions to GNU Fortran.
  
!    * DJ Delorie for the DJGPP port, build and libiberty maintenance,
       various bug fixes, and the M32C, MeP, MSP430, and RL78 ports.
  
!    * Arnaud Desitter for helping to debug GNU Fortran.
  
!    * Gabriel Dos Reis for contributions to G++, contributions and
       maintenance of GCC diagnostics infrastructure, libstdc++-v3,
!      including 'valarray<>', 'complex<>', maintaining the numerics
!      library (including that pesky '' :-) 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.
  
!    * François Dumont for his work on libstdc++-v3, especially
!      maintaining and improving 'debug-mode' and associative and
       unordered containers.
  
!    * Zdenek Dvorak for a new loop unroller and various fixes.
  
!    * Michael Eager for his work on the Xilinx MicroBlaze port.
  
!    * Richard Earnshaw for his ongoing work with the ARM.
  
!    * David Edelsohn for his direction via the steering committee,
       ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
       loop changes, doing the entire AIX port of libstdc++ with his bare
       hands, and for ensuring GCC properly keeps working on AIX.
  
!    * Kevin Ediger for the floating point formatting of num_put::do_put
       in libstdc++.
  
!    * Phil Edwards for libstdc++ work including configuration hackery,
       documentation maintainer, chief breaker of the web pages, the
       occasional iostream bug fix, and work on shared library symbol
       versioning.
  
!    * Paul Eggert for random hacking all over GCC.
  
!    * Mark Elbrecht for various DJGPP improvements, and for libstdc++
       configuration support for locales and fstream-related fixes.
  
!    * Vadim Egorov for libstdc++ fixes in strings, streambufs, and
       iostreams.
  
!    * Christian Ehrhardt for dealing with bug reports.
  
!    * Ben Elliston for his work to move the Objective-C runtime into its
       own subdirectory and for his work on autoconf.
  
!    * Revital Eres for work on the PowerPC 750CL port.
  
!    * Marc Espie for OpenBSD support.
  
!    * Doug Evans for much of the global optimization framework, arc,
       m32r, and SPARC work.
  
!    * Christopher Faylor for his work on the Cygwin port and for caring
       and feeding the gcc.gnu.org box and saving its users tons of spam.
  
!    * Fred Fish for BeOS support and Ada fixes.
  
!    * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
  
!    * Peter Gerwinski for various bug fixes and the Pascal front end.
  
!    * Kaveh R. Ghazi for his direction via the steering committee,
!      amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC
       on a plethora of platforms.  Kaveh extends his gratitude to the
       CAIP Center at Rutgers University for providing him with computing
       resources to work on Free Software from the late 1980s to 2010.
  
!    * John Gilmore for a donation to the FSF earmarked improving GNU
       Java.
  
!    * Judy Goldberg for c++ contributions.
  
!    * Torbjorn Granlund for various fixes and the c-torture testsuite,
       multiply- and divide-by-constant optimization, improved long long
       support, improved leaf function register allocation, and his
       direction via the steering committee.
  
!    * Jonny Grant for improvements to 'collect2's' '--help'
       documentation.
  
!    * Anthony Green for his '-Os' contributions, the moxie port, and Java
       front end work.
  
!    * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java
       code.
  
!    * Michael K. Gschwind contributed the port to the PDP-11.
  
!    * Richard Biener for his ongoing middle-end contributions and bug
       fixes and for release management.
  
!    * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools,
       the support for DWARF 1 symbolic debugging information, and much of
       the support for System V Release 4.  He has also worked heavily on
       the Intel 386 and 860 support.
  
!    * Sumanth Gundapaneni for contributing the CR16 port.
  
!    * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
       GCSE.
  
!    * Bruno Haible for improvements in the runtime overhead for EH, new
       warnings and assorted bug fixes.
  
!    * Andrew Haley for his amazing Java compiler and library efforts.
  
!    * Chris Hanson assisted in making GCC work on HP-UX for the 9000
       series 300.
  
!    * Michael Hayes for various thankless work he's done trying to get
       the c30/c40 ports functional.  Lots of loop and unroll improvements
       and fixes.
  
!    * Dara Hazeghi for wading through myriads of target-specific bug
       reports.
  
!    * Kate Hedstrom for staking the G77 folks with an initial testsuite.
  
!    * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
       work, loop opts, and generally fixing lots of old problems we've
       ignored for years, flow rewrite and lots of further stuff,
       including reviewing tons of patches.
  
!    * Aldy Hernandez for working on the PowerPC port, SIMD support, and
       various fixes.
  
!    * Nobuyuki Hikichi of Software Research Associates, Tokyo,
       contributed the support for the Sony NEWS machine.
  
!    * Kazu Hirata for caring and feeding the Renesas H8/300 port and
       various fixes.
  
!    * Katherine Holcomb for work on GNU Fortran.
  
!    * Manfred Hollstein for his ongoing work to keep the m88k alive, lots
       of testing and bug fixing, particularly of GCC configury code.
  
!    * Steve Holmgren for MachTen patches.
  
!    * Mat Hostetter for work on the TILE-Gx and TILEPro ports.
  
!    * Jan Hubicka for his x86 port improvements.
  
!    * Falk Hueffner for working on C and optimization bug reports.
  
!    * Bernardo Innocenti for his m68k work, including merging of ColdFire
       improvements and uClinux support.
  
!    * Christian Iseli for various bug fixes.
  
!    * Kamil Iskra for general m68k hacking.
  
!    * Lee Iverson for random fixes and MIPS testing.
  
!    * Balaji V. Iyer for Cilk+ development and merging.
  
!    * Andreas Jaeger for testing and benchmarking of GCC and various bug
       fixes.
  
!    * Martin Jambor for his work on inter-procedural optimizations, the
       switch conversion pass, and scalar replacement of aggregates.
  
!    * 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
--- 49218,49602 ----
  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 DWARF 2 support, faster/better
       optimizations, improved alias analysis, plus migrating GCC to
       Bugzilla.
  
!    • Geoff Berry for his Java object serialization work and various
       patches.
  
!    • David Binderman tests weekly snapshots of GCC trunk against Fedora
       Rawhide for several architectures.
  
!    • Laurynas Biveinis for memory management work and DJGPP port fixes.
  
!    • 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.
  
!    • Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
       other Java work.
  
!    • Segher Boessenkool for helping maintain the PowerPC port and the
       instruction combiner plus various contributions to the middle end.
  
!    • 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.
  
!    • James Bowman for the FT32 port.
  
!    • 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 from its
       creation to 2013.
  
!    • Iain Buclaw for the D frontend.
  
!    • Craig Burley for leadership of the G77 Fortran effort.
  
!    • Tobias Burnus for contributions to GNU Fortran.
  
!    • 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.
  
!    • Kito Cheng for his work on the RISC-V port, including bringing up
       the test suite and maintenance.
  
!    • Scott Christley for his Objective-C contributions.
  
!    • Eric Christopher for his Java porting help and clean-ups.
  
!    • Branko Cibej for more warning contributions.
  
!    • The GNU Classpath project for all of their merged runtime code.
  
!    • Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work,
!      ‘--help’, and other random hacking.
  
!    • Michael Cook for libstdc++ cleanup patches to reduce warnings.
  
!    • R. Kelley Cook for making GCC buildable from a read-only directory
       as well as other miscellaneous build process and documentation
       clean-ups.
  
!    • Ralf Corsepius for SH testing and minor bug fixing.
  
!    • François-Xavier Coudert for contributions to GNU Fortran.
  
!    • 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.
  
!    • Palmer Dabbelt for his work maintaining the RISC-V port.
  
!    • 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.
  
!    • Jerry DeLisle for contributions to GNU Fortran.
  
!    • DJ Delorie for the DJGPP port, build and libiberty maintenance,
       various bug fixes, and the M32C, MeP, MSP430, and RL78 ports.
  
!    • Arnaud Desitter for helping to debug GNU Fortran.
  
!    • Gabriel Dos Reis for contributions to G++, contributions and
       maintenance of GCC diagnostics infrastructure, libstdc++-v3,
!      including ‘valarray<>’, ‘complex<>’, maintaining the numerics
!      library (including that pesky ‘’ :-) 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.
  
!    • François Dumont for his work on libstdc++-v3, especially
!      maintaining and improving ‘debug-mode’ and associative and
       unordered containers.
  
!    • Zdenek Dvorak for a new loop unroller and various fixes.
  
!    • Michael Eager for his work on the Xilinx MicroBlaze port.
  
!    • Richard Earnshaw for his ongoing work with the ARM.
  
!    • David Edelsohn for his direction via the steering committee,
       ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
       loop changes, doing the entire AIX port of libstdc++ with his bare
       hands, and for ensuring GCC properly keeps working on AIX.
  
!    • Kevin Ediger for the floating point formatting of num_put::do_put
       in libstdc++.
  
!    • Phil Edwards for libstdc++ work including configuration hackery,
       documentation maintainer, chief breaker of the web pages, the
       occasional iostream bug fix, and work on shared library symbol
       versioning.
  
!    • Paul Eggert for random hacking all over GCC.
  
!    • Mark Elbrecht for various DJGPP improvements, and for libstdc++
       configuration support for locales and fstream-related fixes.
  
!    • Vadim Egorov for libstdc++ fixes in strings, streambufs, and
       iostreams.
  
!    • Christian Ehrhardt for dealing with bug reports.
  
!    • Ben Elliston for his work to move the Objective-C runtime into its
       own subdirectory and for his work on autoconf.
  
!    • Revital Eres for work on the PowerPC 750CL port.
  
!    • Marc Espie for OpenBSD support.
  
!    • Doug Evans for much of the global optimization framework, arc,
       m32r, and SPARC work.
  
!    • Christopher Faylor for his work on the Cygwin port and for caring
       and feeding the gcc.gnu.org box and saving its users tons of spam.
  
!    • Fred Fish for BeOS support and Ada fixes.
  
!    • Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
  
!    • Peter Gerwinski for various bug fixes and the Pascal front end.
  
!    • Kaveh R. Ghazi for his direction via the steering committee,
!      amazing work to make ‘-W -Wall -W* -Werror’ useful, and testing GCC
       on a plethora of platforms.  Kaveh extends his gratitude to the
       CAIP Center at Rutgers University for providing him with computing
       resources to work on Free Software from the late 1980s to 2010.
  
!    • John Gilmore for a donation to the FSF earmarked improving GNU
       Java.
  
!    • Judy Goldberg for c++ contributions.
  
!    • Torbjorn Granlund for various fixes and the c-torture testsuite,
       multiply- and divide-by-constant optimization, improved long long
       support, improved leaf function register allocation, and his
       direction via the steering committee.
  
!    • Jonny Grant for improvements to ‘collect2's’ ‘--help’
       documentation.
  
!    • Anthony Green for his ‘-Os’ contributions, the moxie port, and Java
       front end work.
  
!    • Stu Grossman for gdb hacking, allowing GCJ developers to debug Java
       code.
  
!    • Michael K. Gschwind contributed the port to the PDP-11.
  
!    • Richard Biener for his ongoing middle-end contributions and bug
       fixes and for release management.
  
!    • Ron Guilmette implemented the ‘protoize’ and ‘unprotoize’ tools,
       the support for DWARF 1 symbolic debugging information, and much of
       the support for System V Release 4.  He has also worked heavily on
       the Intel 386 and 860 support.
  
!    • Sumanth Gundapaneni for contributing the CR16 port.
  
!    • Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
       GCSE.
  
!    • Bruno Haible for improvements in the runtime overhead for EH, new
       warnings and assorted bug fixes.
  
!    • Andrew Haley for his amazing Java compiler and library efforts.
  
!    • Chris Hanson assisted in making GCC work on HP-UX for the 9000
       series 300.
  
!    • Michael Hayes for various thankless work he's done trying to get
       the c30/c40 ports functional.  Lots of loop and unroll improvements
       and fixes.
  
!    • Dara Hazeghi for wading through myriads of target-specific bug
       reports.
  
!    • Kate Hedstrom for staking the G77 folks with an initial testsuite.
  
!    • Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
       work, loop opts, and generally fixing lots of old problems we've
       ignored for years, flow rewrite and lots of further stuff,
       including reviewing tons of patches.
  
!    • Aldy Hernandez for working on the PowerPC port, SIMD support, and
       various fixes.
  
!    • Nobuyuki Hikichi of Software Research Associates, Tokyo,
       contributed the support for the Sony NEWS machine.
  
!    • Kazu Hirata for caring and feeding the Renesas H8/300 port and
       various fixes.
  
!    • Katherine Holcomb for work on GNU Fortran.
  
!    • Manfred Hollstein for his ongoing work to keep the m88k alive, lots
       of testing and bug fixing, particularly of GCC configury code.
  
!    • Steve Holmgren for MachTen patches.
  
!    • Mat Hostetter for work on the TILE-Gx and TILEPro ports.
  
!    • Jan Hubicka for his x86 port improvements.
  
!    • Falk Hueffner for working on C and optimization bug reports.
  
!    • Bernardo Innocenti for his m68k work, including merging of ColdFire
       improvements and uClinux support.
  
!    • Christian Iseli for various bug fixes.
  
!    • Kamil Iskra for general m68k hacking.
  
!    • Lee Iverson for random fixes and MIPS testing.
  
!    • Balaji V. Iyer for Cilk+ development and merging.
  
!    • Andreas Jaeger for testing and benchmarking of GCC and various bug
       fixes.
  
!    • Martin Jambor for his work on inter-procedural optimizations, the
       switch conversion pass, and scalar replacement of aggregates.
  
!    • 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
*************** in alphabetical order.
*** 49608,50520 ****
       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.
  
!    * Maxim Kuvyrkov for contributions to the instruction scheduler, the
       Android and m68k/Coldfire ports, and optimizations.
  
!    * Charles LaBrec contributed the support for the Integrated Solutions
       68020 system.
  
!    * Asher Langton and Mike Kumbera for contributing Cray pointer
       support to GNU Fortran, and for other GNU Fortran improvements.
  
!    * Jeff Law for his direction via the steering committee, coordinating
       the entire egcs project and GCC 2.95, rolling out snapshots and
       releases, handling merges from GCC2, reviewing tons of patches that
       might have fallen through the cracks else, and random but extensive
       hacking.
  
!    * Walter Lee for work on the TILE-Gx and TILEPro ports.
  
!    * Marc Lehmann for his direction via the steering committee and
       helping with analysis and improvements of x86 performance.
  
!    * Victor Leikehman for work on GNU Fortran.
  
!    * Ted Lemon wrote parts of the RTL reader and printer.
  
!    * Kriang Lerdsuwanakij for C++ improvements including template as
       template parameter support, and many C++ fixes.
  
!    * Warren Levy for tremendous work on libgcj (Java Runtime Library)
       and random work on the Java front end.
  
!    * Alain Lichnewsky ported GCC to the MIPS CPU.
  
!    * Oskar Liljeblad for hacking on AWT and his many Java bug reports
       and patches.
  
!    * Robert Lipe for OpenServer support, new testsuites, testing, etc.
  
!    * Chen Liqin for various S+core related fixes/improvement, and for
       maintaining the S+core port.
  
!    * Martin Liska for his work on identical code folding, the
       sanitizers, HSA, general bug fixing and for running automated
       regression testing of GCC and reporting numerous bugs.
  
!    * Weiwen Liu for testing and various bug fixes.
  
!    * Manuel López-Ibáñ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 Lö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, design and
       implementation of the automaton based instruction scheduler and
       design and implementation of the integrated and local register
       allocators.
  
!    * David Malcolm for his work on improving GCC diagnostics, JIT,
       self-tests and unit testing.
  
!    * Bob Manson for his behind the scenes work on dejagnu.
  
!    * Jose E. Marchesi for contributing the eBPF backend and his ongoing
       work maintaining it.
  
!    * John Marino for contributing the DragonFly BSD port.
  
!    * Philip Martin for lots of libstdc++ string and vector iterator
       fixes and improvements, and string clean up and testsuites.
  
!    * Michael Matz for his work on dominance tree discovery, the x86-64
       port, link-time optimization framework and general optimization
       improvements.
  
!    * 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.cc and interfacing with the Linux
       kernel developers.
  
!    * Gary Miller ported GCC to Charles River Data Systems machines.
  
!    * Alfred Minarik for libstdc++ string and ios bug fixes, and turning
       the entire libstdc++ testsuite namespace-compatible.
  
!    * Mark Mitchell for his direction via the steering committee,
       mountains of C++ work, load/store hoisting out of loops, alias
!      analysis improvements, ISO C 'restrict' support, and serving as
       release manager from 2000 to 2011.
  
!    * Alan Modra for various GNU/Linux bits and testing.
  
!    * Toon Moene for his direction via the steering committee, Fortran
       maintenance, and his ongoing work to make us make Fortran run fast.
  
!    * Jason Molenda for major help in the care and feeding of all the
       services on the gcc.gnu.org (formerly egcs.cygnus.com)
       machine--mail, web services, ftp services, etc etc.  Doing all this
       work on scrap paper and the backs of envelopes would have been...
       difficult.
  
!    * Catherine Moore for fixing various ugly problems we have sent her
       way, including the haifa bug which was killing the Alpha & PowerPC
       Linux kernels.
  
!    * Mike Moreton for his various Java patches.
  
!    * David Mosberger-Tang for various Alpha improvements, and for the
       initial IA-64 port.
  
!    * Stephen Moshier contributed the floating point emulator that
       assists in cross-compilation and permits support for floating point
       numbers wider than 64 bits and for ISO C99 support.
  
!    * Bill Moyer for his behind the scenes work on various issues.
  
!    * Philippe De Muyter for his work on the m68k port.
  
!    * Joseph S. Myers for his work on the PDP-11 port, format checking
       and ISO C99 support, and continuous emphasis on (and contributions
       to) documentation.
  
!    * Nathan Myers for his work on libstdc++-v3: architecture and
       authorship through the first three snapshots, including
       implementation of locale infrastructure, string, shadow C headers,
       and the initial project documentation (DESIGN, CHECKLIST, and so
       forth).  Later, more work on MT-safe string and shadow headers.
  
!    * Felix Natter for documentation on porting libstdc++.
  
!    * Nathanael Nerode for cleaning up the configuration/build process.
  
!    * NeXT, Inc. donated the front end that supports the Objective-C
       language.
  
!    * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the
       search engine setup, various documentation fixes and other small
       fixes.
  
!    * Geoff Noer for his work on getting cygwin native builds working.
  
!    * Vegard Nossum for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * 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.
  
!    * Steven Pemberton for his contribution of 'enquire' which allowed
       GCC to determine various properties of the floating point unit and
!      generate 'float.h' in older versions of GCC.
  
!    * 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.
  
!    * Marek Polacek for his work on the C front end, the sanitizers and
       general bug fixing.
  
!    * 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.
  
!    * John Regehr for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * Volker Reichelt for running automated regression testing of GCC and
       reporting numerous bugs and for keeping up with the problem
       reports.
  
!    * Joern Rennecke for maintaining the sh port, loop, regmove & reload
       hacking and developing and maintaining the Epiphany port.
  
!    * Loren J. Rittle for improvements to libstdc++-v3 including the
       FreeBSD port, threading fixes, thread-related configury changes,
       critical threading documentation, and solutions to really tricky
       I/O problems, as well as keeping GCC properly working on FreeBSD
       and continuous testing.
  
!    * Craig Rodrigues for processing tons of bug reports.
  
!    * Ola Rö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.
  
!    * Ira Rosen for her contributions to the auto-vectorizer.
  
!    * Paul Rubin wrote most of the preprocessor.
  
!    * Pétur Runó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 Schlüter for work on GNU Fortran.
  
!    * Bernd Schmidt for various code generation improvements and major
       work in the reload pass, serving as release manager for GCC 2.95.3,
       and work on the Blackfin and C6X ports.
  
!    * Peter Schmid for constant testing of libstdc++--especially
       application testing, going above and beyond what was requested for
       the release criteria--and libstdc++ header file tweaks.
  
!    * Jason Schroeder for jcf-dump patches.
  
!    * Andreas Schwab for his work on the m68k port.
  
!    * Lars Segerlund for work on GNU Fortran.
  
!    * Dodji Seketeli for numerous C++ bug fixes and debug info
       improvements.
  
!    * Tim Shen for major work on ''.
  
!    * 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.
       Retired from GCC maintainership August 2010, having mentored two
       new maintainers into the role.
  
!    * Randy Smith finished the Sun FPA support.
  
!    * Ed Smith-Rowland for his continuous work on libstdc++-v3, special
!      functions, '', and various improvements to C++11 features.
  
!    * Scott Snyder for queue, iterator, istream, and string fixes and
       libstdc++ testsuite entries.  Also for providing the patch to G77
!      to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and
!      'LOGICAL*1'.
  
!    * Zdenek Sojka for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * Arseny Solokha for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * Jayant Sonar for contributing the CR16 port.
  
!    * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
  
!    * Richard Stallman, for writing the original GCC and launching the
       GNU project.
  
!    * Jan Stein of the Chalmers Computer Society provided support for
       Genix, as well as part of the 32000 machine description.
  
!    * Gerhard Steinmetz for running automated regression testing of GCC
       and reporting numerous bugs.
  
!    * 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.
  
!    * Zhendong Su for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * Chengnian Sun for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * 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.
  
!    * Paul Thomas for contributions to GNU Fortran.
  
!    * 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.
  
!    * Andrew Waterman for contributing the RISC-V port, as well as
       maintaining it.
  
!    * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
       guidance and maintaining libstdc++.
  
!    * Dean Wakerley for converting the install documentation from HTML to
       texinfo in time for GCC 3.0.
  
!    * Krister Walfridsson for random bug fixes.
  
!    * Feng Wang for contributions to GNU Fortran.
  
!    * Stephen M. Webb for time and effort on making libstdc++ shadow
       files work with the tricky Solaris 8+ headers, and for pushing the
       build-time header tree.  Also, for starting and driving the
!      '' effort.
  
!    * John Wehle for various improvements for the x86 code generator,
       related infrastructure improvements to help x86 code generation,
       value range propagation and other work, WE32k port.
  
!    * Ulrich Weigand for work on the s390 port.
  
!    * Janus Weil for contributions to GNU Fortran.
  
!    * Zack Weinberg for major work on cpplib and various other bug fixes.
  
!    * Matt Welsh for help with Linux Threads support in GCJ.
  
!    * Urban Widmark for help fixing java.io.
  
!    * Mark Wielaard for new Java library code and his work integrating
       with Classpath.
  
!    * Dale Wiles helped port GCC to the Tahoe.
  
!    * Bob Wilson from Tensilica, Inc. for the Xtensa port.
  
!    * Jim Wilson for his direction via the steering committee, tackling
       hard problems in various places that nobody else wanted to work on,
       strength reduction and other loop optimizations.
  
!    * Paul Woegerer and Tal Agmon for the CRX port.
  
!    * Carlo Wood for various fixes.
  
!    * Tom Wood for work on the m88k port.
  
!    * Chung-Ju Wu for his work on the Andes NDS32 port.
  
!    * Canqun Yang for work on GNU Fortran.
  
!    * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
       description for the Tron architecture (specifically, the Gmicro).
  
!    * Kevin Zachmann helped port GCC to the Tahoe.
  
!    * Ayal Zaks for Swing Modulo Scheduling (SMS).
  
!    * Qirun Zhang for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    * 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
  
!    * Jö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
--- 49607,50519 ----
       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.
  
!    • Maxim Kuvyrkov for contributions to the instruction scheduler, the
       Android and m68k/Coldfire ports, and optimizations.
  
!    • Charles LaBrec contributed the support for the Integrated Solutions
       68020 system.
  
!    • Asher Langton and Mike Kumbera for contributing Cray pointer
       support to GNU Fortran, and for other GNU Fortran improvements.
  
!    • Jeff Law for his direction via the steering committee, coordinating
       the entire egcs project and GCC 2.95, rolling out snapshots and
       releases, handling merges from GCC2, reviewing tons of patches that
       might have fallen through the cracks else, and random but extensive
       hacking.
  
!    • Walter Lee for work on the TILE-Gx and TILEPro ports.
  
!    • Marc Lehmann for his direction via the steering committee and
       helping with analysis and improvements of x86 performance.
  
!    • Victor Leikehman for work on GNU Fortran.
  
!    • Ted Lemon wrote parts of the RTL reader and printer.
  
!    • Kriang Lerdsuwanakij for C++ improvements including template as
       template parameter support, and many C++ fixes.
  
!    • Warren Levy for tremendous work on libgcj (Java Runtime Library)
       and random work on the Java front end.
  
!    • Alain Lichnewsky ported GCC to the MIPS CPU.
  
!    • Oskar Liljeblad for hacking on AWT and his many Java bug reports
       and patches.
  
!    • Robert Lipe for OpenServer support, new testsuites, testing, etc.
  
!    • Chen Liqin for various S+core related fixes/improvement, and for
       maintaining the S+core port.
  
!    • Martin Liska for his work on identical code folding, the
       sanitizers, HSA, general bug fixing and for running automated
       regression testing of GCC and reporting numerous bugs.
  
!    • Weiwen Liu for testing and various bug fixes.
  
!    • Manuel López-Ibáñ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 Lö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, design and
       implementation of the automaton based instruction scheduler and
       design and implementation of the integrated and local register
       allocators.
  
!    • David Malcolm for his work on improving GCC diagnostics, JIT,
       self-tests and unit testing.
  
!    • Bob Manson for his behind the scenes work on dejagnu.
  
!    • Jose E. Marchesi for contributing the eBPF backend and his ongoing
       work maintaining it.
  
!    • John Marino for contributing the DragonFly BSD port.
  
!    • Philip Martin for lots of libstdc++ string and vector iterator
       fixes and improvements, and string clean up and testsuites.
  
!    • Michael Matz for his work on dominance tree discovery, the x86-64
       port, link-time optimization framework and general optimization
       improvements.
  
!    • 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.cc and interfacing with the Linux
       kernel developers.
  
!    • Gary Miller ported GCC to Charles River Data Systems machines.
  
!    • Alfred Minarik for libstdc++ string and ios bug fixes, and turning
       the entire libstdc++ testsuite namespace-compatible.
  
!    • Mark Mitchell for his direction via the steering committee,
       mountains of C++ work, load/store hoisting out of loops, alias
!      analysis improvements, ISO C ‘restrict’ support, and serving as
       release manager from 2000 to 2011.
  
!    • Alan Modra for various GNU/Linux bits and testing.
  
!    • Toon Moene for his direction via the steering committee, Fortran
       maintenance, and his ongoing work to make us make Fortran run fast.
  
!    • Jason Molenda for major help in the care and feeding of all the
       services on the gcc.gnu.org (formerly egcs.cygnus.com)
       machine--mail, web services, ftp services, etc etc.  Doing all this
       work on scrap paper and the backs of envelopes would have been...
       difficult.
  
!    • Catherine Moore for fixing various ugly problems we have sent her
       way, including the haifa bug which was killing the Alpha & PowerPC
       Linux kernels.
  
!    • Mike Moreton for his various Java patches.
  
!    • David Mosberger-Tang for various Alpha improvements, and for the
       initial IA-64 port.
  
!    • Stephen Moshier contributed the floating point emulator that
       assists in cross-compilation and permits support for floating point
       numbers wider than 64 bits and for ISO C99 support.
  
!    • Bill Moyer for his behind the scenes work on various issues.
  
!    • Philippe De Muyter for his work on the m68k port.
  
!    • Joseph S. Myers for his work on the PDP-11 port, format checking
       and ISO C99 support, and continuous emphasis on (and contributions
       to) documentation.
  
!    • Nathan Myers for his work on libstdc++-v3: architecture and
       authorship through the first three snapshots, including
       implementation of locale infrastructure, string, shadow C headers,
       and the initial project documentation (DESIGN, CHECKLIST, and so
       forth).  Later, more work on MT-safe string and shadow headers.
  
!    • Felix Natter for documentation on porting libstdc++.
  
!    • Nathanael Nerode for cleaning up the configuration/build process.
  
!    • NeXT, Inc. donated the front end that supports the Objective-C
       language.
  
!    • Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the
       search engine setup, various documentation fixes and other small
       fixes.
  
!    • Geoff Noer for his work on getting cygwin native builds working.
  
!    • Vegard Nossum for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • 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.
  
!    • Steven Pemberton for his contribution of ‘enquire’ which allowed
       GCC to determine various properties of the floating point unit and
!      generate ‘float.h’ in older versions of GCC.
  
!    • 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.
  
!    • Marek Polacek for his work on the C front end, the sanitizers and
       general bug fixing.
  
!    • 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.
  
!    • John Regehr for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • Volker Reichelt for running automated regression testing of GCC and
       reporting numerous bugs and for keeping up with the problem
       reports.
  
!    • Joern Rennecke for maintaining the sh port, loop, regmove & reload
       hacking and developing and maintaining the Epiphany port.
  
!    • Loren J. Rittle for improvements to libstdc++-v3 including the
       FreeBSD port, threading fixes, thread-related configury changes,
       critical threading documentation, and solutions to really tricky
       I/O problems, as well as keeping GCC properly working on FreeBSD
       and continuous testing.
  
!    • Craig Rodrigues for processing tons of bug reports.
  
!    • Ola Rö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.
  
!    • Ira Rosen for her contributions to the auto-vectorizer.
  
!    • Paul Rubin wrote most of the preprocessor.
  
!    • Pétur Runó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 Schlüter for work on GNU Fortran.
  
!    • Bernd Schmidt for various code generation improvements and major
       work in the reload pass, serving as release manager for GCC 2.95.3,
       and work on the Blackfin and C6X ports.
  
!    • Peter Schmid for constant testing of libstdc++--especially
       application testing, going above and beyond what was requested for
       the release criteria--and libstdc++ header file tweaks.
  
!    • Jason Schroeder for jcf-dump patches.
  
!    • Andreas Schwab for his work on the m68k port.
  
!    • Lars Segerlund for work on GNU Fortran.
  
!    • Dodji Seketeli for numerous C++ bug fixes and debug info
       improvements.
  
!    • Tim Shen for major work on ‘’.
  
!    • 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.
       Retired from GCC maintainership August 2010, having mentored two
       new maintainers into the role.
  
!    • Randy Smith finished the Sun FPA support.
  
!    • Ed Smith-Rowland for his continuous work on libstdc++-v3, special
!      functions, ‘’, and various improvements to C++11 features.
  
!    • Scott Snyder for queue, iterator, istream, and string fixes and
       libstdc++ testsuite entries.  Also for providing the patch to G77
!      to add rudimentary support for ‘INTEGER*1’, ‘INTEGER*2’, and
!      ‘LOGICAL*1’.
  
!    • Zdenek Sojka for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • Arseny Solokha for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • Jayant Sonar for contributing the CR16 port.
  
!    • Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
  
!    • Richard Stallman, for writing the original GCC and launching the
       GNU project.
  
!    • Jan Stein of the Chalmers Computer Society provided support for
       Genix, as well as part of the 32000 machine description.
  
!    • Gerhard Steinmetz for running automated regression testing of GCC
       and reporting numerous bugs.
  
!    • 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.
  
!    • Zhendong Su for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • Chengnian Sun for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • 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.
  
!    • Paul Thomas for contributions to GNU Fortran.
  
!    • 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.
  
!    • Andrew Waterman for contributing the RISC-V port, as well as
       maintaining it.
  
!    • Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
       guidance and maintaining libstdc++.
  
!    • Dean Wakerley for converting the install documentation from HTML to
       texinfo in time for GCC 3.0.
  
!    • Krister Walfridsson for random bug fixes.
  
!    • Feng Wang for contributions to GNU Fortran.
  
!    • Stephen M. Webb for time and effort on making libstdc++ shadow
       files work with the tricky Solaris 8+ headers, and for pushing the
       build-time header tree.  Also, for starting and driving the
!      ‘’ effort.
  
!    • John Wehle for various improvements for the x86 code generator,
       related infrastructure improvements to help x86 code generation,
       value range propagation and other work, WE32k port.
  
!    • Ulrich Weigand for work on the s390 port.
  
!    • Janus Weil for contributions to GNU Fortran.
  
!    • Zack Weinberg for major work on cpplib and various other bug fixes.
  
!    • Matt Welsh for help with Linux Threads support in GCJ.
  
!    • Urban Widmark for help fixing java.io.
  
!    • Mark Wielaard for new Java library code and his work integrating
       with Classpath.
  
!    • Dale Wiles helped port GCC to the Tahoe.
  
!    • Bob Wilson from Tensilica, Inc. for the Xtensa port.
  
!    • Jim Wilson for his direction via the steering committee, tackling
       hard problems in various places that nobody else wanted to work on,
       strength reduction and other loop optimizations.
  
!    • Paul Woegerer and Tal Agmon for the CRX port.
  
!    • Carlo Wood for various fixes.
  
!    • Tom Wood for work on the m88k port.
  
!    • Chung-Ju Wu for his work on the Andes NDS32 port.
  
!    • Canqun Yang for work on GNU Fortran.
  
!    • Masanobu Yuhara of Fujitsu Laboratories implemented the machine
       description for the Tron architecture (specifically, the Gmicro).
  
!    • Kevin Zachmann helped port GCC to the Tahoe.
  
!    • Ayal Zaks for Swing Modulo Scheduling (SMS).
  
!    • Qirun Zhang for running automated regression testing of GCC and
       reporting numerous bugs.
  
!    • 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
  
!    • Jö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
*************** File: gccint.info,  Node: Option Index,
*** 50526,50534 ****
  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.
  
--- 50525,50533 ----
  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.
  
*************** Concept Index
*** 50551,50624 ****
  [index]
  * Menu:
  
- * ! in constraint:                       Multi-Alternative.  (line   48)
- * "real" instructions, RTL SSA:          RTL SSA Basic Blocks.
-                                                              (line   11)
- * # in constraint:                       Modifiers.          (line   78)
- * # in template:                         Output Template.    (line   66)
- * #pragma:                               Misc.               (line  422)
- * $ in constraint:                       Multi-Alternative.  (line   57)
- * % in constraint:                       Modifiers.          (line   52)
- * % in GTY option:                       GTY Options.        (line   18)
- * % in template:                         Output Template.    (line    6)
- * & in constraint:                       Modifiers.          (line   25)
- * (gimple_stmt_iterator:                 GIMPLE API.         (line   31)
- * (nil):                                 RTL Objects.        (line   73)
- * * in constraint:                       Modifiers.          (line   83)
- * * in template:                         Output Statement.   (line   29)
- * *gimple_build_asm_vec:                 GIMPLE_ASM.         (line    6)
- * *gimple_build_assign:                  GIMPLE_ASSIGN.      (line    6)
- * *gimple_build_assign <1>:              GIMPLE_ASSIGN.      (line   18)
- * *gimple_build_assign <2>:              GIMPLE_ASSIGN.      (line   29)
- * *gimple_build_assign <3>:              GIMPLE_ASSIGN.      (line   35)
- * *gimple_build_bind:                    GIMPLE_BIND.        (line    6)
- * *gimple_build_call:                    GIMPLE_CALL.        (line    6)
- * *gimple_build_call_from_tree:          GIMPLE_CALL.        (line   15)
- * *gimple_build_call_vec:                GIMPLE_CALL.        (line   25)
- * *gimple_build_catch:                   GIMPLE_CATCH.       (line    6)
- * *gimple_build_cond:                    GIMPLE_COND.        (line    6)
- * *gimple_build_cond_from_tree:          GIMPLE_COND.        (line   14)
- * *gimple_build_debug_bind:              GIMPLE_DEBUG.       (line    6)
- * *gimple_build_eh_filter:               GIMPLE_EH_FILTER.   (line    6)
- * *gimple_build_goto:                    GIMPLE_GOTO.        (line    6)
- * *gimple_build_label:                   GIMPLE_LABEL.       (line    6)
- * *gimple_build_omp_atomic_load:         GIMPLE_OMP_ATOMIC_LOAD.
-                                                              (line    6)
- * *gimple_build_omp_atomic_store:        GIMPLE_OMP_ATOMIC_STORE.
-                                                              (line    6)
- * *gimple_build_omp_continue:            GIMPLE_OMP_CONTINUE.
-                                                              (line    6)
- * *gimple_build_omp_critical:            GIMPLE_OMP_CRITICAL.
-                                                              (line    6)
- * *gimple_build_omp_for:                 GIMPLE_OMP_FOR.     (line    6)
- * *gimple_build_omp_parallel:            GIMPLE_OMP_PARALLEL.
-                                                              (line    6)
- * *gimple_build_omp_sections:            GIMPLE_OMP_SECTIONS.
-                                                              (line    6)
- * *gimple_build_omp_single:              GIMPLE_OMP_SINGLE.  (line    6)
- * *gimple_build_resx:                    GIMPLE_RESX.        (line    6)
- * *gimple_build_return:                  GIMPLE_RETURN.      (line    6)
- * *gimple_build_switch:                  GIMPLE_SWITCH.      (line    6)
- * *gimple_build_try:                     GIMPLE_TRY.         (line    6)
- * + in constraint:                       Modifiers.          (line   12)
- * -fsection-anchors:                     Special Accessors.  (line  117)
- * -fsection-anchors <1>:                 Anchored Addresses. (line    6)
- * /c in RTL dump:                        Flags.              (line  230)
- * /f in RTL dump:                        Flags.              (line  238)
- * /i in RTL dump:                        Flags.              (line  283)
- * /j in RTL dump:                        Flags.              (line  295)
- * /s in RTL dump:                        Flags.              (line  254)
- * /u in RTL dump:                        Flags.              (line  307)
- * /v in RTL dump:                        Flags.              (line  339)
- * 0 in constraint:                       Simple Constraints. (line  128)
- * < in constraint:                       Simple Constraints. (line   47)
- * = in constraint:                       Modifiers.          (line    8)
- * > in constraint:                       Simple Constraints. (line   59)
- * ? in constraint:                       Multi-Alternative.  (line   42)
- * @ in instruction pattern names:        Parameterized Names.
-                                                              (line    6)
- * \:                                     Output Template.    (line   46)
- * ^ in constraint:                       Multi-Alternative.  (line   53)
  * __absvdi2:                             Integer library routines.
                                                               (line  106)
  * __absvsi2:                             Integer library routines.
--- 50550,50555 ----
*************** Concept Index
*** 53897,53919 ****
                                                               (line  138)
  * __ussubuta3:                           Fixed-point fractional library routines.
                                                               (line  148)
  * abort:                                 Portability.        (line   20)
  * abs:                                   Arithmetic.         (line  206)
  * abs and attributes:                    Expressions.        (line   83)
  * absence_set:                           Processor pipeline description.
                                                               (line  223)
  * absM2 instruction pattern:             Standard Names.     (line 1009)
  * absolute value:                        Arithmetic.         (line  206)
  * ABSU_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
- * ABS_EXPR:                              Unary and Binary Expressions.
-                                                              (line    6)
  * access to operands:                    Accessors.          (line    6)
  * access to special operands:            Special Accessors.  (line    6)
  * accessors:                             Accessors.          (line    6)
  * ACCUMULATE_OUTGOING_ARGS:              Stack Arguments.    (line   51)
  * ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line  140)
- * ACCUM_TYPE_SIZE:                       Type Layout.        (line   87)
  * acosM2 instruction pattern:            Standard Names.     (line 1096)
  * ADA_LONG_TYPE_SIZE:                    Type Layout.        (line   25)
  * Adding a new GIMPLE statement code:    Adding a new GIMPLE statement code.
--- 53828,53918 ----
                                                               (line  138)
  * __ussubuta3:                           Fixed-point fractional library routines.
                                                               (line  148)
+ * -fsection-anchors:                     Special Accessors.  (line  117)
+ * -fsection-anchors <1>:                 Anchored Addresses. (line    6)
+ * ! in constraint:                       Multi-Alternative.  (line   48)
+ * ? in constraint:                       Multi-Alternative.  (line   42)
+ * "real" instructions, RTL SSA:          RTL SSA Basic Blocks.
+                                                              (line   11)
+ * (gimple_stmt_iterator:                 GIMPLE API.         (line   31)
+ * (nil):                                 RTL Objects.        (line   73)
+ * @ in instruction pattern names:        Parameterized Names.
+                                                              (line    6)
+ * * in constraint:                       Modifiers.          (line   83)
+ * * in template:                         Output Statement.   (line   29)
+ * *gimple_build_asm_vec:                 GIMPLE_ASM.         (line    6)
+ * *gimple_build_assign:                  GIMPLE_ASSIGN.      (line    6)
+ * *gimple_build_assign <1>:              GIMPLE_ASSIGN.      (line   18)
+ * *gimple_build_assign <2>:              GIMPLE_ASSIGN.      (line   29)
+ * *gimple_build_assign <3>:              GIMPLE_ASSIGN.      (line   35)
+ * *gimple_build_bind:                    GIMPLE_BIND.        (line    6)
+ * *gimple_build_call:                    GIMPLE_CALL.        (line    6)
+ * *gimple_build_call_from_tree:          GIMPLE_CALL.        (line   15)
+ * *gimple_build_call_vec:                GIMPLE_CALL.        (line   25)
+ * *gimple_build_catch:                   GIMPLE_CATCH.       (line    6)
+ * *gimple_build_cond:                    GIMPLE_COND.        (line    6)
+ * *gimple_build_cond_from_tree:          GIMPLE_COND.        (line   14)
+ * *gimple_build_debug_bind:              GIMPLE_DEBUG.       (line    6)
+ * *gimple_build_eh_filter:               GIMPLE_EH_FILTER.   (line    6)
+ * *gimple_build_goto:                    GIMPLE_GOTO.        (line    6)
+ * *gimple_build_label:                   GIMPLE_LABEL.       (line    6)
+ * *gimple_build_omp_atomic_load:         GIMPLE_OMP_ATOMIC_LOAD.
+                                                              (line    6)
+ * *gimple_build_omp_atomic_store:        GIMPLE_OMP_ATOMIC_STORE.
+                                                              (line    6)
+ * *gimple_build_omp_continue:            GIMPLE_OMP_CONTINUE.
+                                                              (line    6)
+ * *gimple_build_omp_critical:            GIMPLE_OMP_CRITICAL.
+                                                              (line    6)
+ * *gimple_build_omp_for:                 GIMPLE_OMP_FOR.     (line    6)
+ * *gimple_build_omp_parallel:            GIMPLE_OMP_PARALLEL.
+                                                              (line    6)
+ * *gimple_build_omp_sections:            GIMPLE_OMP_SECTIONS.
+                                                              (line    6)
+ * *gimple_build_omp_single:              GIMPLE_OMP_SINGLE.  (line    6)
+ * *gimple_build_resx:                    GIMPLE_RESX.        (line    6)
+ * *gimple_build_return:                  GIMPLE_RETURN.      (line    6)
+ * *gimple_build_switch:                  GIMPLE_SWITCH.      (line    6)
+ * *gimple_build_try:                     GIMPLE_TRY.         (line    6)
+ * /c in RTL dump:                        Flags.              (line  230)
+ * /f in RTL dump:                        Flags.              (line  238)
+ * /i in RTL dump:                        Flags.              (line  283)
+ * /j in RTL dump:                        Flags.              (line  295)
+ * /s in RTL dump:                        Flags.              (line  254)
+ * /u in RTL dump:                        Flags.              (line  307)
+ * /v in RTL dump:                        Flags.              (line  339)
+ * \:                                     Output Template.    (line   46)
+ * & in constraint:                       Modifiers.          (line   25)
+ * # in constraint:                       Modifiers.          (line   78)
+ * # in template:                         Output Template.    (line   66)
+ * #pragma:                               Misc.               (line  422)
+ * % in constraint:                       Modifiers.          (line   52)
+ * % in GTY option:                       GTY Options.        (line   18)
+ * % in template:                         Output Template.    (line    6)
+ * ^ in constraint:                       Multi-Alternative.  (line   53)
+ * + in constraint:                       Modifiers.          (line   12)
+ * < in constraint:                       Simple Constraints. (line   47)
+ * = in constraint:                       Modifiers.          (line    8)
+ * > in constraint:                       Simple Constraints. (line   59)
+ * $ in constraint:                       Multi-Alternative.  (line   57)
+ * 0 in constraint:                       Simple Constraints. (line  128)
  * abort:                                 Portability.        (line   20)
  * abs:                                   Arithmetic.         (line  206)
  * abs and attributes:                    Expressions.        (line   83)
+ * ABS_EXPR:                              Unary and Binary Expressions.
+                                                              (line    6)
  * absence_set:                           Processor pipeline description.
                                                               (line  223)
  * absM2 instruction pattern:             Standard Names.     (line 1009)
  * absolute value:                        Arithmetic.         (line  206)
  * ABSU_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * access to operands:                    Accessors.          (line    6)
  * access to special operands:            Special Accessors.  (line    6)
  * accessors:                             Accessors.          (line    6)
+ * ACCUM_TYPE_SIZE:                       Type Layout.        (line   87)
  * ACCUMULATE_OUTGOING_ARGS:              Stack Arguments.    (line   51)
  * ACCUMULATE_OUTGOING_ARGS and stack frames: Function Entry. (line  140)
  * acosM2 instruction pattern:            Standard Names.     (line 1096)
  * ADA_LONG_TYPE_SIZE:                    Type Layout.        (line   25)
  * Adding a new GIMPLE statement code:    Adding a new GIMPLE statement code.
*************** Concept Index
*** 53922,53945 ****
  * addM3 instruction pattern:             Standard Names.     (line  488)
  * addMODEcc instruction pattern:         Standard Names.     (line 1917)
  * addptrM3 instruction pattern:          Standard Names.     (line  521)
  * address constraints:                   Simple Constraints. (line  162)
- * addressing modes:                      Addressing Modes.   (line    6)
  * address_operand:                       Machine-Independent Predicates.
                                                               (line   62)
  * address_operand <1>:                   Simple Constraints. (line  166)
! * addr_diff_vec:                         Side Effects.       (line  305)
! * addr_diff_vec, length of:              Insn Lengths.       (line   26)
! * ADDR_EXPR:                             Storage References. (line    6)
! * addr_vec:                              Side Effects.       (line  300)
! * addr_vec, length of:                   Insn Lengths.       (line   26)
  * addvM4 instruction pattern:            Standard Names.     (line  504)
  * ADJUST_FIELD_ALIGN:                    Storage Layout.     (line  217)
  * ADJUST_INSN_LENGTH:                    Insn Lengths.       (line   41)
  * ADJUST_REG_ALLOC_ORDER:                Allocation Order.   (line   22)
  * aggregates as return values:           Aggregate Return.   (line    6)
  * alias:                                 Alias analysis.     (line    6)
- * allocate_stack instruction pattern:    Standard Names.     (line 2304)
  * ALL_REGS:                              Register Classes.   (line   17)
  * alternate entry points:                Insns.              (line  146)
  * analyzer:                              Static Analyzer.    (line    6)
  * analyzer, debugging:                   Debugging the Analyzer.
--- 53921,53944 ----
  * addM3 instruction pattern:             Standard Names.     (line  488)
  * addMODEcc instruction pattern:         Standard Names.     (line 1917)
  * addptrM3 instruction pattern:          Standard Names.     (line  521)
+ * addr_diff_vec:                         Side Effects.       (line  304)
+ * addr_diff_vec, length of:              Insn Lengths.       (line   26)
+ * ADDR_EXPR:                             Storage References. (line    6)
+ * addr_vec:                              Side Effects.       (line  299)
+ * addr_vec, length of:                   Insn Lengths.       (line   26)
  * address constraints:                   Simple Constraints. (line  162)
  * address_operand:                       Machine-Independent Predicates.
                                                               (line   62)
  * address_operand <1>:                   Simple Constraints. (line  166)
! * addressing modes:                      Addressing Modes.   (line    6)
  * addvM4 instruction pattern:            Standard Names.     (line  504)
  * ADJUST_FIELD_ALIGN:                    Storage Layout.     (line  217)
  * ADJUST_INSN_LENGTH:                    Insn Lengths.       (line   41)
  * ADJUST_REG_ALLOC_ORDER:                Allocation Order.   (line   22)
  * aggregates as return values:           Aggregate Return.   (line    6)
  * alias:                                 Alias analysis.     (line    6)
  * ALL_REGS:                              Register Classes.   (line   17)
+ * allocate_stack instruction pattern:    Standard Names.     (line 2304)
  * alternate entry points:                Insns.              (line  146)
  * analyzer:                              Static Analyzer.    (line    6)
  * analyzer, debugging:                   Debugging the Analyzer.
*************** Concept Index
*** 53955,53979 ****
                                                               (line    6)
  * annotations:                           Annotations.        (line    6)
  * APPLY_RESULT_SIZE:                     Scalar Return.      (line  112)
- * ARGS_GROW_DOWNWARD:                    Frame Layout.       (line   30)
- * argument passing:                      Interface.          (line   36)
- * arguments in registers:                Register Arguments. (line    6)
- * arguments on stack:                    Stack Arguments.    (line    6)
  * ARG_POINTER_CFA_OFFSET:                Frame Layout.       (line  213)
  * ARG_POINTER_REGNUM:                    Frame Registers.    (line   40)
  * ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line   65)
  * arg_pointer_rtx:                       Frame Registers.    (line  104)
  * arithmetic library:                    Soft float library routines.
                                                               (line    6)
  * arithmetic shift:                      Arithmetic.         (line  179)
  * arithmetic shift with signed saturation: Arithmetic.       (line  179)
  * arithmetic shift with unsigned saturation: Arithmetic.     (line  179)
- * arithmetic, in RTL:                    Arithmetic.         (line    6)
  * ARITHMETIC_TYPE_P:                     Types for C++.      (line   59)
  * array:                                 Types.              (line    6)
  * ARRAY_RANGE_REF:                       Storage References. (line    6)
  * ARRAY_REF:                             Storage References. (line    6)
  * ARRAY_TYPE:                            Types.              (line    6)
  * ashift:                                Arithmetic.         (line  179)
  * ashift and attributes:                 Expressions.        (line   83)
  * ashiftrt:                              Arithmetic.         (line  196)
--- 53954,53979 ----
                                                               (line    6)
  * annotations:                           Annotations.        (line    6)
  * APPLY_RESULT_SIZE:                     Scalar Return.      (line  112)
  * ARG_POINTER_CFA_OFFSET:                Frame Layout.       (line  213)
  * ARG_POINTER_REGNUM:                    Frame Registers.    (line   40)
  * ARG_POINTER_REGNUM and virtual registers: Regs and Memory. (line   65)
  * arg_pointer_rtx:                       Frame Registers.    (line  104)
+ * ARGS_GROW_DOWNWARD:                    Frame Layout.       (line   30)
+ * argument passing:                      Interface.          (line   36)
+ * arguments in registers:                Register Arguments. (line    6)
+ * arguments on stack:                    Stack Arguments.    (line    6)
  * arithmetic library:                    Soft float library routines.
                                                               (line    6)
  * arithmetic shift:                      Arithmetic.         (line  179)
  * arithmetic shift with signed saturation: Arithmetic.       (line  179)
  * arithmetic shift with unsigned saturation: Arithmetic.     (line  179)
  * ARITHMETIC_TYPE_P:                     Types for C++.      (line   59)
+ * arithmetic, in RTL:                    Arithmetic.         (line    6)
  * array:                                 Types.              (line    6)
  * ARRAY_RANGE_REF:                       Storage References. (line    6)
  * ARRAY_REF:                             Storage References. (line    6)
  * ARRAY_TYPE:                            Types.              (line    6)
+ * AS_NEEDS_DASH_FOR_PIPED_INPUT:         Driver.             (line   88)
  * ashift:                                Arithmetic.         (line  179)
  * ashift and attributes:                 Expressions.        (line   83)
  * ashiftrt:                              Arithmetic.         (line  196)
*************** Concept Index
*** 53996,54018 ****
  * asm_fprintf:                           Instruction Output. (line  150)
  * ASM_FPRINTF_EXTENSIONS:                Instruction Output. (line  160)
  * ASM_GENERATE_INTERNAL_LABEL:           Label Output.       (line  410)
! * asm_input:                             Side Effects.       (line  287)
  * asm_input and /v:                      Flags.              (line   65)
  * ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX:     Exception Handling. (line   80)
- * asm_noperands:                         Insns.              (line  327)
  * ASM_NO_SKIP_IN_TEXT:                   Alignment Output.   (line   59)
  * asm_operands and /v:                   Flags.              (line   65)
  * asm_operands, RTL sharing:             Sharing.            (line   46)
  * asm_operands, usage:                   Assembler.          (line    6)
  * ASM_OUTPUT_ADDR_DIFF_ELT:              Dispatch Tables.    (line    8)
  * ASM_OUTPUT_ADDR_VEC_ELT:               Dispatch Tables.    (line   25)
  * ASM_OUTPUT_ALIGN:                      Alignment Output.   (line   66)
  * ASM_OUTPUT_ALIGNED_BSS:                Uninitialized Data. (line   45)
  * ASM_OUTPUT_ALIGNED_COMMON:             Uninitialized Data. (line   29)
  * ASM_OUTPUT_ALIGNED_DECL_COMMON:        Uninitialized Data. (line   36)
  * ASM_OUTPUT_ALIGNED_DECL_LOCAL:         Uninitialized Data. (line   89)
  * ASM_OUTPUT_ALIGNED_LOCAL:              Uninitialized Data. (line   82)
- * ASM_OUTPUT_ALIGN_WITH_NOP:             Alignment Output.   (line   71)
  * ASM_OUTPUT_ASCII:                      Data Output.        (line   60)
  * ASM_OUTPUT_CASE_END:                   Dispatch Tables.    (line   50)
  * ASM_OUTPUT_CASE_LABEL:                 Dispatch Tables.    (line   37)
--- 53996,54018 ----
  * asm_fprintf:                           Instruction Output. (line  150)
  * ASM_FPRINTF_EXTENSIONS:                Instruction Output. (line  160)
  * ASM_GENERATE_INTERNAL_LABEL:           Label Output.       (line  410)
! * asm_input:                             Side Effects.       (line  286)
  * asm_input and /v:                      Flags.              (line   65)
  * ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX:     Exception Handling. (line   80)
  * ASM_NO_SKIP_IN_TEXT:                   Alignment Output.   (line   59)
+ * asm_noperands:                         Insns.              (line  327)
  * asm_operands and /v:                   Flags.              (line   65)
  * asm_operands, RTL sharing:             Sharing.            (line   46)
  * asm_operands, usage:                   Assembler.          (line    6)
  * ASM_OUTPUT_ADDR_DIFF_ELT:              Dispatch Tables.    (line    8)
  * ASM_OUTPUT_ADDR_VEC_ELT:               Dispatch Tables.    (line   25)
  * ASM_OUTPUT_ALIGN:                      Alignment Output.   (line   66)
+ * ASM_OUTPUT_ALIGN_WITH_NOP:             Alignment Output.   (line   71)
  * ASM_OUTPUT_ALIGNED_BSS:                Uninitialized Data. (line   45)
  * ASM_OUTPUT_ALIGNED_COMMON:             Uninitialized Data. (line   29)
  * ASM_OUTPUT_ALIGNED_DECL_COMMON:        Uninitialized Data. (line   36)
  * ASM_OUTPUT_ALIGNED_DECL_LOCAL:         Uninitialized Data. (line   89)
  * ASM_OUTPUT_ALIGNED_LOCAL:              Uninitialized Data. (line   82)
  * ASM_OUTPUT_ASCII:                      Data Output.        (line   60)
  * ASM_OUTPUT_CASE_END:                   Dispatch Tables.    (line   50)
  * ASM_OUTPUT_CASE_LABEL:                 Dispatch Tables.    (line   37)
*************** Concept Index
*** 54031,54038 ****
  * ASM_OUTPUT_FUNCTION_LABEL:             Label Output.       (line   16)
  * ASM_OUTPUT_INTERNAL_LABEL:             Label Output.       (line   27)
  * ASM_OUTPUT_LABEL:                      Label Output.       (line    8)
- * ASM_OUTPUT_LABELREF:                   Label Output.       (line  349)
  * ASM_OUTPUT_LABEL_REF:                  Label Output.       (line  371)
  * ASM_OUTPUT_LOCAL:                      Uninitialized Data. (line   69)
  * ASM_OUTPUT_MAX_SKIP_ALIGN:             Alignment Output.   (line   75)
  * ASM_OUTPUT_MEASURED_SIZE:              Label Output.       (line   51)
--- 54031,54038 ----
  * ASM_OUTPUT_FUNCTION_LABEL:             Label Output.       (line   16)
  * ASM_OUTPUT_INTERNAL_LABEL:             Label Output.       (line   27)
  * ASM_OUTPUT_LABEL:                      Label Output.       (line    8)
  * ASM_OUTPUT_LABEL_REF:                  Label Output.       (line  371)
+ * ASM_OUTPUT_LABELREF:                   Label Output.       (line  349)
  * ASM_OUTPUT_LOCAL:                      Uninitialized Data. (line   69)
  * ASM_OUTPUT_MAX_SKIP_ALIGN:             Alignment Output.   (line   75)
  * ASM_OUTPUT_MEASURED_SIZE:              Label Output.       (line   51)
*************** Concept Index
*** 54047,54078 ****
  * ASM_OUTPUT_SPECIAL_POOL_ENTRY:         Data Output.        (line   93)
  * ASM_OUTPUT_SYMBOL_REF:                 Label Output.       (line  364)
  * ASM_OUTPUT_TYPE_DIRECTIVE:             Label Output.       (line   98)
- * ASM_OUTPUT_WEAKREF:                    Label Output.       (line  259)
  * ASM_OUTPUT_WEAK_ALIAS:                 Label Output.       (line  473)
  * ASM_PREFERRED_EH_DATA_FORMAT:          Exception Handling. (line   66)
  * ASM_SPEC:                              Driver.             (line   73)
  * ASM_WEAKEN_DECL:                       Label Output.       (line  251)
  * ASM_WEAKEN_LABEL:                      Label Output.       (line  238)
  * assembler format:                      File Framework.     (line    6)
  * assembler instructions in RTL:         Assembler.          (line    6)
  * ASSEMBLER_DIALECT:                     Instruction Output. (line  172)
- * assemble_name:                         Label Output.       (line    8)
- * assemble_name_raw:                     Label Output.       (line   27)
  * assigning attribute values to insns:   Tagging Insns.      (line    6)
  * ASSUME_EXTENDED_UNWIND_CONTEXT:        Frame Registers.    (line  163)
  * asterisk in template:                  Output Statement.   (line   29)
- * AS_NEEDS_DASH_FOR_PIPED_INPUT:         Driver.             (line   88)
  * atan2M3 instruction pattern:           Standard Names.     (line 1214)
  * atanM2 instruction pattern:            Standard Names.     (line 1102)
  * atomic:                                GTY Options.        (line  221)
- * atomic_addMODE instruction pattern:    Standard Names.     (line 2728)
- * atomic_add_fetchMODE instruction pattern: Standard Names.  (line 2757)
  * atomic_add_fetch_cmp_0MODE instruction pattern: Standard Names.
                                                               (line 2810)
! * atomic_andMODE instruction pattern:    Standard Names.     (line 2728)
! * atomic_and_fetchMODE instruction pattern: Standard Names.  (line 2757)
  * atomic_and_fetch_cmp_0MODE instruction pattern: Standard Names.
                                                               (line 2810)
  * atomic_bit_test_and_complementMODE instruction pattern: Standard Names.
                                                               (line 2785)
  * atomic_bit_test_and_resetMODE instruction pattern: Standard Names.
--- 54047,54077 ----
  * ASM_OUTPUT_SPECIAL_POOL_ENTRY:         Data Output.        (line   93)
  * ASM_OUTPUT_SYMBOL_REF:                 Label Output.       (line  364)
  * ASM_OUTPUT_TYPE_DIRECTIVE:             Label Output.       (line   98)
  * ASM_OUTPUT_WEAK_ALIAS:                 Label Output.       (line  473)
+ * ASM_OUTPUT_WEAKREF:                    Label Output.       (line  259)
  * ASM_PREFERRED_EH_DATA_FORMAT:          Exception Handling. (line   66)
  * ASM_SPEC:                              Driver.             (line   73)
  * ASM_WEAKEN_DECL:                       Label Output.       (line  251)
  * ASM_WEAKEN_LABEL:                      Label Output.       (line  238)
+ * assemble_name:                         Label Output.       (line    8)
+ * assemble_name_raw:                     Label Output.       (line   27)
  * assembler format:                      File Framework.     (line    6)
  * assembler instructions in RTL:         Assembler.          (line    6)
  * ASSEMBLER_DIALECT:                     Instruction Output. (line  172)
  * assigning attribute values to insns:   Tagging Insns.      (line    6)
  * ASSUME_EXTENDED_UNWIND_CONTEXT:        Frame Registers.    (line  163)
  * asterisk in template:                  Output Statement.   (line   29)
  * atan2M3 instruction pattern:           Standard Names.     (line 1214)
  * atanM2 instruction pattern:            Standard Names.     (line 1102)
  * atomic:                                GTY Options.        (line  221)
  * atomic_add_fetch_cmp_0MODE instruction pattern: Standard Names.
                                                               (line 2810)
! * atomic_add_fetchMODE instruction pattern: Standard Names.  (line 2757)
! * atomic_addMODE instruction pattern:    Standard Names.     (line 2728)
  * atomic_and_fetch_cmp_0MODE instruction pattern: Standard Names.
                                                               (line 2810)
+ * atomic_and_fetchMODE instruction pattern: Standard Names.  (line 2757)
+ * atomic_andMODE instruction pattern:    Standard Names.     (line 2728)
  * atomic_bit_test_and_complementMODE instruction pattern: Standard Names.
                                                               (line 2785)
  * atomic_bit_test_and_resetMODE instruction pattern: Standard Names.
*************** Concept Index
*** 54089,54121 ****
  * atomic_fetch_subMODE instruction pattern: Standard Names.  (line 2742)
  * atomic_fetch_xorMODE instruction pattern: Standard Names.  (line 2742)
  * atomic_loadMODE instruction pattern:   Standard Names.     (line 2695)
- * atomic_nandMODE instruction pattern:   Standard Names.     (line 2728)
  * atomic_nand_fetchMODE instruction pattern: Standard Names. (line 2757)
! * atomic_orMODE instruction pattern:     Standard Names.     (line 2728)
! * atomic_or_fetchMODE instruction pattern: Standard Names.   (line 2757)
  * atomic_or_fetch_cmp_0MODE instruction pattern: Standard Names.
                                                               (line 2810)
  * atomic_storeMODE instruction pattern:  Standard Names.     (line 2705)
- * atomic_subMODE instruction pattern:    Standard Names.     (line 2728)
- * atomic_sub_fetchMODE instruction pattern: Standard Names.  (line 2757)
  * atomic_sub_fetch_cmp_0MODE instruction pattern: Standard Names.
                                                               (line 2810)
  * atomic_test_and_set instruction pattern: Standard Names.   (line 2774)
- * atomic_xorMODE instruction pattern:    Standard Names.     (line 2728)
- * atomic_xor_fetchMODE instruction pattern: Standard Names.  (line 2757)
  * atomic_xor_fetch_cmp_0MODE instruction pattern: Standard Names.
                                                               (line 2810)
  * attr:                                  Expressions.        (line  163)
  * attr <1>:                              Tagging Insns.      (line   54)
  * attribute expressions:                 Expressions.        (line    6)
  * attribute specifications:              Attr Example.       (line    6)
  * attribute specifications example:      Attr Example.       (line    6)
  * attributes:                            Attributes.         (line    6)
  * attributes, defining:                  Defining Attributes.
                                                               (line    6)
  * attributes, target-specific:           Target Attributes.  (line    6)
- * ATTRIBUTE_ALIGNED_VALUE:               Storage Layout.     (line  199)
- * attr_flag:                             Expressions.        (line  138)
  * autoincrement addressing, availability: Portability.       (line   20)
  * autoincrement/decrement addressing:    Simple Constraints. (line   30)
  * automata_option:                       Processor pipeline description.
--- 54088,54120 ----
  * atomic_fetch_subMODE instruction pattern: Standard Names.  (line 2742)
  * atomic_fetch_xorMODE instruction pattern: Standard Names.  (line 2742)
  * atomic_loadMODE instruction pattern:   Standard Names.     (line 2695)
  * atomic_nand_fetchMODE instruction pattern: Standard Names. (line 2757)
! * atomic_nandMODE instruction pattern:   Standard Names.     (line 2728)
  * atomic_or_fetch_cmp_0MODE instruction pattern: Standard Names.
                                                               (line 2810)
+ * atomic_or_fetchMODE instruction pattern: Standard Names.   (line 2757)
+ * atomic_orMODE instruction pattern:     Standard Names.     (line 2728)
  * atomic_storeMODE instruction pattern:  Standard Names.     (line 2705)
  * atomic_sub_fetch_cmp_0MODE instruction pattern: Standard Names.
                                                               (line 2810)
+ * atomic_sub_fetchMODE instruction pattern: Standard Names.  (line 2757)
+ * atomic_subMODE instruction pattern:    Standard Names.     (line 2728)
  * atomic_test_and_set instruction pattern: Standard Names.   (line 2774)
  * atomic_xor_fetch_cmp_0MODE instruction pattern: Standard Names.
                                                               (line 2810)
+ * atomic_xor_fetchMODE instruction pattern: Standard Names.  (line 2757)
+ * atomic_xorMODE instruction pattern:    Standard Names.     (line 2728)
  * attr:                                  Expressions.        (line  163)
  * attr <1>:                              Tagging Insns.      (line   54)
+ * attr_flag:                             Expressions.        (line  138)
  * attribute expressions:                 Expressions.        (line    6)
  * attribute specifications:              Attr Example.       (line    6)
  * attribute specifications example:      Attr Example.       (line    6)
+ * ATTRIBUTE_ALIGNED_VALUE:               Storage Layout.     (line  199)
  * attributes:                            Attributes.         (line    6)
  * attributes, defining:                  Defining Attributes.
                                                               (line    6)
  * attributes, target-specific:           Target Attributes.  (line    6)
  * autoincrement addressing, availability: Portability.       (line   20)
  * autoincrement/decrement addressing:    Simple Constraints. (line   30)
  * automata_option:                       Processor pipeline description.
*************** Concept Index
*** 54139,54149 ****
  * basic blocks, RTL SSA:                 RTL SSA Basic Blocks.
                                                               (line    6)
  * Basic Statements:                      Basic Statements.   (line    6)
- * basic-block.h:                         Control Flow.       (line    6)
  * basic_block:                           RTL SSA Basic Blocks.
                                                               (line    6)
  * basic_block <1>:                       Basic Blocks.       (line    6)
  * BASIC_BLOCK:                           Basic Blocks.       (line   14)
  * BB_HEAD, BB_END:                       Maintaining the CFG.
                                                               (line   76)
  * bb_seq:                                GIMPLE sequences.   (line   72)
--- 54138,54148 ----
  * basic blocks, RTL SSA:                 RTL SSA Basic Blocks.
                                                               (line    6)
  * Basic Statements:                      Basic Statements.   (line    6)
  * basic_block:                           RTL SSA Basic Blocks.
                                                               (line    6)
  * basic_block <1>:                       Basic Blocks.       (line    6)
  * BASIC_BLOCK:                           Basic Blocks.       (line   14)
+ * basic-block.h:                         Control Flow.       (line    6)
  * BB_HEAD, BB_END:                       Maintaining the CFG.
                                                               (line   76)
  * bb_seq:                                GIMPLE sequences.   (line   72)
*************** Concept Index
*** 54153,54158 ****
--- 54152,54165 ----
  * BIND_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * BINFO_TYPE:                            Classes.            (line    6)
+ * BIT_AND_EXPR:                          Unary and Binary Expressions.
+                                                              (line    6)
+ * BIT_IOR_EXPR:                          Unary and Binary Expressions.
+                                                              (line    6)
+ * BIT_NOT_EXPR:                          Unary and Binary Expressions.
+                                                              (line    6)
+ * BIT_XOR_EXPR:                          Unary and Binary Expressions.
+                                                              (line    6)
  * bit-fields:                            Bit-Fields.         (line    6)
  * BITFIELD_NBYTES_LIMITED:               Storage Layout.     (line  437)
  * BITS_BIG_ENDIAN:                       Storage Layout.     (line   11)
*************** Concept Index
*** 54163,54188 ****
  * bitwise exclusive-or:                  Arithmetic.         (line  174)
  * bitwise inclusive-or:                  Arithmetic.         (line  169)
  * bitwise logical-and:                   Arithmetic.         (line  164)
- * BIT_AND_EXPR:                          Unary and Binary Expressions.
-                                                              (line    6)
- * BIT_IOR_EXPR:                          Unary and Binary Expressions.
-                                                              (line    6)
- * BIT_NOT_EXPR:                          Unary and Binary Expressions.
-                                                              (line    6)
- * BIT_XOR_EXPR:                          Unary and Binary Expressions.
-                                                              (line    6)
  * BLKmode:                               Machine Modes.      (line  184)
  * BLKmode, and function return values:   Calls.              (line   23)
- * blockage instruction pattern:          Standard Names.     (line 2504)
- * Blocks:                                Blocks.             (line    6)
  * BLOCK_FOR_INSN, gimple_bb:             Maintaining the CFG.
                                                               (line   28)
  * BLOCK_REG_PADDING:                     Register Arguments. (line  232)
  * BND32mode:                             Machine Modes.      (line  209)
  * BND64mode:                             Machine Modes.      (line  209)
  * bool:                                  Misc.               (line  973)
- * BOOLEAN_TYPE:                          Types.              (line    6)
  * BOOL_TYPE_SIZE:                        Type Layout.        (line   43)
  * branch prediction:                     Profile information.
                                                               (line   24)
  * BRANCH_COST:                           Costs.              (line  104)
--- 54170,54187 ----
  * bitwise exclusive-or:                  Arithmetic.         (line  174)
  * bitwise inclusive-or:                  Arithmetic.         (line  169)
  * bitwise logical-and:                   Arithmetic.         (line  164)
  * BLKmode:                               Machine Modes.      (line  184)
  * BLKmode, and function return values:   Calls.              (line   23)
  * BLOCK_FOR_INSN, gimple_bb:             Maintaining the CFG.
                                                               (line   28)
  * BLOCK_REG_PADDING:                     Register Arguments. (line  232)
+ * blockage instruction pattern:          Standard Names.     (line 2504)
+ * Blocks:                                Blocks.             (line    6)
  * BND32mode:                             Machine Modes.      (line  209)
  * BND64mode:                             Machine Modes.      (line  209)
  * bool:                                  Misc.               (line  973)
  * BOOL_TYPE_SIZE:                        Type Layout.        (line   43)
+ * BOOLEAN_TYPE:                          Types.              (line    6)
  * branch prediction:                     Profile information.
                                                               (line   24)
  * BRANCH_COST:                           Costs.              (line  104)
*************** Concept Index
*** 54212,54221 ****
  * builtin_setjmp_receiver instruction pattern: Standard Names.
                                                               (line 2392)
  * builtin_setjmp_setup instruction pattern: Standard Names.  (line 2381)
  * BYTES_BIG_ENDIAN:                      Storage Layout.     (line   23)
  * BYTES_BIG_ENDIAN, effect on subreg:    Regs and Memory.    (line  229)
- * byte_mode:                             Machine Modes.      (line  462)
  * C statements for assembler output:     Output Statement.   (line    6)
  * cache:                                 GTY Options.        (line  152)
  * cadd270M3 instruction pattern:         Standard Names.     (line 1336)
  * cadd90M3 instruction pattern:          Standard Names.     (line 1314)
--- 54211,54223 ----
  * builtin_setjmp_receiver instruction pattern: Standard Names.
                                                               (line 2392)
  * builtin_setjmp_setup instruction pattern: Standard Names.  (line 2381)
+ * byte_mode:                             Machine Modes.      (line  462)
  * BYTES_BIG_ENDIAN:                      Storage Layout.     (line   23)
  * BYTES_BIG_ENDIAN, effect on subreg:    Regs and Memory.    (line  229)
  * C statements for assembler output:     Output Statement.   (line    6)
+ * C_COMMON_OVERRIDE_OPTIONS:             Run-time Target.    (line  136)
+ * c_register_pragma:                     Misc.               (line  442)
+ * c_register_pragma_with_expansion:      Misc.               (line  444)
  * cache:                                 GTY Options.        (line  152)
  * cadd270M3 instruction pattern:         Standard Names.     (line 1336)
  * cadd90M3 instruction pattern:          Standard Names.     (line 1314)
*************** Concept Index
*** 54223,54245 ****
  * call <1>:                              Side Effects.       (line   85)
  * call instruction pattern:              Standard Names.     (line 2053)
  * call usage:                            Calls.              (line   10)
- * call, in call_insn:                    Flags.              (line  129)
- * call, in mem:                          Flags.              (line   70)
- * call-clobbered register:               Register Basics.    (line   35)
- * call-clobbered register <1>:           Register Basics.    (line   50)
- * call-clobbered register <2>:           Register Basics.    (line   58)
- * call-clobbered register <3>:           Register Basics.    (line   76)
- * call-saved register:                   Register Basics.    (line   35)
- * call-saved register <1>:               Register Basics.    (line   50)
- * call-saved register <2>:               Register Basics.    (line   58)
- * call-saved register <3>:               Register Basics.    (line   76)
- * call-used register:                    Register Basics.    (line   35)
- * call-used register <1>:                Register Basics.    (line   50)
- * call-used register <2>:                Register Basics.    (line   58)
- * call-used register <3>:                Register Basics.    (line   76)
- * callback:                              GTY Options.        (line   99)
- * calling conventions:                   Stack and Calling.  (line    6)
- * calling functions in RTL:              Calls.              (line    6)
  * CALL_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * call_insn:                             Insns.              (line   95)
--- 54225,54230 ----
*************** Concept Index
*** 54261,54292 ****
  * call_used_regs:                        Register Basics.    (line  102)
  * call_value instruction pattern:        Standard Names.     (line 2077)
  * call_value_pop instruction pattern:    Standard Names.     (line 2085)
  * canadian:                              Configure Terms.    (line    6)
  * canonicalization of instructions:      Insn Canonicalizations.
                                                               (line    6)
  * canonicalize_funcptr_for_compare instruction pattern: Standard Names.
                                                               (line 2236)
- * can_create_pseudo_p:                   Standard Names.     (line   75)
- * can_fallthru:                          Basic Blocks.       (line   67)
  * caret:                                 Multi-Alternative.  (line   53)
  * caret <1>:                             Guidelines for Diagnostics.
                                                               (line  183)
- * casesi instruction pattern:            Standard Names.     (line 2178)
  * CASE_VECTOR_MODE:                      Misc.               (line   26)
  * CASE_VECTOR_PC_RELATIVE:               Misc.               (line   39)
  * CASE_VECTOR_SHORTEN_MODE:              Misc.               (line   30)
  * cbranchMODE4 instruction pattern:      Standard Names.     (line 2042)
- * CC1PLUS_SPEC:                          Driver.             (line   63)
  * CC1_SPEC:                              Driver.             (line   55)
  * CCmode:                                Machine Modes.      (line  178)
  * CCmode <1>:                            MODE_CC Condition Codes.
                                                               (line    6)
  * CDImode:                               Machine Modes.      (line  203)
- * ceilM2 instruction pattern:            Standard Names.     (line 1250)
  * CEIL_DIV_EXPR:                         Unary and Binary Expressions.
                                                               (line    6)
  * CEIL_MOD_EXPR:                         Unary and Binary Expressions.
                                                               (line    6)
  * CFA_FRAME_BASE_OFFSET:                 Frame Layout.       (line  245)
  * CFG verification:                      Maintaining the CFG.
                                                               (line  116)
--- 54246,54294 ----
  * call_used_regs:                        Register Basics.    (line  102)
  * call_value instruction pattern:        Standard Names.     (line 2077)
  * call_value_pop instruction pattern:    Standard Names.     (line 2085)
+ * call-clobbered register:               Register Basics.    (line   35)
+ * call-clobbered register <1>:           Register Basics.    (line   50)
+ * call-clobbered register <2>:           Register Basics.    (line   58)
+ * call-clobbered register <3>:           Register Basics.    (line   76)
+ * call-saved register:                   Register Basics.    (line   35)
+ * call-saved register <1>:               Register Basics.    (line   50)
+ * call-saved register <2>:               Register Basics.    (line   58)
+ * call-saved register <3>:               Register Basics.    (line   76)
+ * call-used register:                    Register Basics.    (line   35)
+ * call-used register <1>:                Register Basics.    (line   50)
+ * call-used register <2>:                Register Basics.    (line   58)
+ * call-used register <3>:                Register Basics.    (line   76)
+ * call, in call_insn:                    Flags.              (line  129)
+ * call, in mem:                          Flags.              (line   70)
+ * callback:                              GTY Options.        (line   99)
+ * calling conventions:                   Stack and Calling.  (line    6)
+ * calling functions in RTL:              Calls.              (line    6)
+ * can_create_pseudo_p:                   Standard Names.     (line   75)
+ * can_fallthru:                          Basic Blocks.       (line   67)
  * canadian:                              Configure Terms.    (line    6)
  * canonicalization of instructions:      Insn Canonicalizations.
                                                               (line    6)
  * canonicalize_funcptr_for_compare instruction pattern: Standard Names.
                                                               (line 2236)
  * caret:                                 Multi-Alternative.  (line   53)
  * caret <1>:                             Guidelines for Diagnostics.
                                                               (line  183)
  * CASE_VECTOR_MODE:                      Misc.               (line   26)
  * CASE_VECTOR_PC_RELATIVE:               Misc.               (line   39)
  * CASE_VECTOR_SHORTEN_MODE:              Misc.               (line   30)
+ * casesi instruction pattern:            Standard Names.     (line 2178)
  * cbranchMODE4 instruction pattern:      Standard Names.     (line 2042)
  * CC1_SPEC:                              Driver.             (line   55)
+ * CC1PLUS_SPEC:                          Driver.             (line   63)
  * CCmode:                                Machine Modes.      (line  178)
  * CCmode <1>:                            MODE_CC Condition Codes.
                                                               (line    6)
  * CDImode:                               Machine Modes.      (line  203)
  * CEIL_DIV_EXPR:                         Unary and Binary Expressions.
                                                               (line    6)
  * CEIL_MOD_EXPR:                         Unary and Binary Expressions.
                                                               (line    6)
+ * ceilM2 instruction pattern:            Standard Names.     (line 1250)
  * CFA_FRAME_BASE_OFFSET:                 Frame Layout.       (line  245)
  * CFG verification:                      Maintaining the CFG.
                                                               (line  116)
*************** Concept Index
*** 54305,54318 ****
  * CHImode:                               Machine Modes.      (line  203)
  * class definitions, register:           Register Classes.   (line    6)
  * class preference constraints:          Class Preferences.  (line    6)
  * class, scope:                          Classes.            (line    6)
  * classes of RTX codes:                  RTL Classes.        (line    6)
  * CLASSTYPE_DECLARED_CLASS:              Classes.            (line    6)
  * CLASSTYPE_HAS_MUTABLE:                 Classes.            (line   82)
  * CLASSTYPE_NON_POD_P:                   Classes.            (line   87)
- * CLASS_MAX_NREGS:                       Register Classes.   (line  531)
- * CLASS_TYPE_P:                          Types for C++.      (line   63)
- * Cleanups:                              Cleanups.           (line    6)
  * CLEANUP_DECL:                          Statements for C and C++.
                                                               (line    6)
  * CLEANUP_EXPR:                          Statements for C and C++.
--- 54307,54319 ----
  * CHImode:                               Machine Modes.      (line  203)
  * class definitions, register:           Register Classes.   (line    6)
  * class preference constraints:          Class Preferences.  (line    6)
+ * CLASS_MAX_NREGS:                       Register Classes.   (line  531)
+ * CLASS_TYPE_P:                          Types for C++.      (line   63)
  * class, scope:                          Classes.            (line    6)
  * classes of RTX codes:                  RTL Classes.        (line    6)
  * CLASSTYPE_DECLARED_CLASS:              Classes.            (line    6)
  * CLASSTYPE_HAS_MUTABLE:                 Classes.            (line   82)
  * CLASSTYPE_NON_POD_P:                   Classes.            (line   87)
  * CLEANUP_DECL:                          Statements for C and C++.
                                                               (line    6)
  * CLEANUP_EXPR:                          Statements for C and C++.
*************** Concept Index
*** 54321,54326 ****
--- 54322,54328 ----
                                                               (line    6)
  * CLEANUP_STMT:                          Statements for C and C++.
                                                               (line    6)
+ * Cleanups:                              Cleanups.           (line    6)
  * clear_cache instruction pattern:       Standard Names.     (line 2910)
  * CLEAR_INSN_CACHE:                      Trampolines.        (line  168)
  * CLEAR_RATIO:                           Costs.              (line  232)
*************** Concept Index
*** 54328,54368 ****
  * clrsb:                                 Arithmetic.         (line  221)
  * clrsbM2 instruction pattern:           Standard Names.     (line 1492)
  * clz:                                   Arithmetic.         (line  228)
- * clzM2 instruction pattern:             Standard Names.     (line 1508)
  * CLZ_DEFINED_VALUE_AT_ZERO:             Misc.               (line  340)
! * cmlaM4 instruction pattern:            Standard Names.     (line 1358)
  * cmla_conjM4 instruction pattern:       Standard Names.     (line 1378)
! * cmlsM4 instruction pattern:            Standard Names.     (line 1399)
  * cmls_conjM4 instruction pattern:       Standard Names.     (line 1419)
  * cmpmemM instruction pattern:           Standard Names.     (line 1711)
  * cmpstrM instruction pattern:           Standard Names.     (line 1690)
  * cmpstrnM instruction pattern:          Standard Names.     (line 1677)
- * cmulM4 instruction pattern:            Standard Names.     (line 1440)
  * cmul_conjM4 instruction pattern:       Standard Names.     (line 1459)
  * code generation RTL sequences:         Expander Definitions.
                                                               (line    6)
  * code iterators in .md files:           Code Iterators.     (line    6)
- * codes, RTL expression:                 RTL Objects.        (line   47)
  * code_label:                            Insns.              (line  125)
  * CODE_LABEL:                            Basic Blocks.       (line   50)
  * code_label and /i:                     Flags.              (line   48)
  * code_label and /v:                     Flags.              (line   33)
  * CODE_LABEL_NUMBER:                     Insns.              (line  125)
  * COImode:                               Machine Modes.      (line  203)
- * COLLECT2_HOST_INITIALIZATION:          Host Misc.          (line   32)
  * COLLECT_EXPORT_LIST:                   Misc.               (line  879)
  * COLLECT_SHARED_FINI_FUNC:              Macros for Initialization.
                                                               (line   43)
  * COLLECT_SHARED_INIT_FUNC:              Macros for Initialization.
                                                               (line   32)
  * command-line options, guidelines for:  Guidelines for Options.
                                                               (line    6)
  * commit_edge_insertions:                Maintaining the CFG.
                                                               (line  104)
  * compare:                               Arithmetic.         (line   46)
  * compare, canonicalization of:          Insn Canonicalizations.
                                                               (line   36)
- * COMPARE_MAX_PIECES:                    Costs.              (line  227)
  * comparison_operator:                   Machine-Independent Predicates.
                                                               (line  110)
  * compiler passes and files:             Passes.             (line    6)
--- 54330,54370 ----
  * clrsb:                                 Arithmetic.         (line  221)
  * clrsbM2 instruction pattern:           Standard Names.     (line 1492)
  * clz:                                   Arithmetic.         (line  228)
  * CLZ_DEFINED_VALUE_AT_ZERO:             Misc.               (line  340)
! * clzM2 instruction pattern:             Standard Names.     (line 1508)
  * cmla_conjM4 instruction pattern:       Standard Names.     (line 1378)
! * cmlaM4 instruction pattern:            Standard Names.     (line 1358)
  * cmls_conjM4 instruction pattern:       Standard Names.     (line 1419)
+ * cmlsM4 instruction pattern:            Standard Names.     (line 1399)
  * cmpmemM instruction pattern:           Standard Names.     (line 1711)
  * cmpstrM instruction pattern:           Standard Names.     (line 1690)
  * cmpstrnM instruction pattern:          Standard Names.     (line 1677)
  * cmul_conjM4 instruction pattern:       Standard Names.     (line 1459)
+ * cmulM4 instruction pattern:            Standard Names.     (line 1440)
  * code generation RTL sequences:         Expander Definitions.
                                                               (line    6)
  * code iterators in .md files:           Code Iterators.     (line    6)
  * code_label:                            Insns.              (line  125)
  * CODE_LABEL:                            Basic Blocks.       (line   50)
  * code_label and /i:                     Flags.              (line   48)
  * code_label and /v:                     Flags.              (line   33)
  * CODE_LABEL_NUMBER:                     Insns.              (line  125)
+ * codes, RTL expression:                 RTL Objects.        (line   47)
  * COImode:                               Machine Modes.      (line  203)
  * COLLECT_EXPORT_LIST:                   Misc.               (line  879)
  * COLLECT_SHARED_FINI_FUNC:              Macros for Initialization.
                                                               (line   43)
  * COLLECT_SHARED_INIT_FUNC:              Macros for Initialization.
                                                               (line   32)
+ * COLLECT2_HOST_INITIALIZATION:          Host Misc.          (line   32)
  * command-line options, guidelines for:  Guidelines for Options.
                                                               (line    6)
  * commit_edge_insertions:                Maintaining the CFG.
                                                               (line  104)
  * compare:                               Arithmetic.         (line   46)
+ * COMPARE_MAX_PIECES:                    Costs.              (line  227)
  * compare, canonicalization of:          Insn Canonicalizations.
                                                               (line   36)
  * comparison_operator:                   Machine-Independent Predicates.
                                                               (line  110)
  * compiler passes and files:             Passes.             (line    6)
*************** Concept Index
*** 54391,54409 ****
  * concatn:                               Regs and Memory.    (line  377)
  * cond:                                  Comparisons.        (line   80)
  * cond and attributes:                   Expressions.        (line   37)
- * condition code status:                 Condition Code.     (line    6)
- * condition codes:                       Comparisons.        (line   20)
- * conditional execution:                 Conditional Execution.
-                                                              (line    6)
- * Conditional Expressions:               Conditional Expressions.
-                                                              (line    6)
- * conditions, in patterns:               Patterns.           (line   55)
  * cond_addMODE instruction pattern:      Standard Names.     (line 1924)
  * cond_andMODE instruction pattern:      Standard Names.     (line 1924)
  * cond_ashlMODE instruction pattern:     Standard Names.     (line 1924)
  * cond_ashrMODE instruction pattern:     Standard Names.     (line 1924)
  * cond_divMODE instruction pattern:      Standard Names.     (line 1924)
! * cond_exec:                             Side Effects.       (line  245)
  * COND_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * cond_fmaMODE instruction pattern:      Standard Names.     (line 1972)
--- 54393,54404 ----
  * concatn:                               Regs and Memory.    (line  377)
  * cond:                                  Comparisons.        (line   80)
  * cond and attributes:                   Expressions.        (line   37)
  * cond_addMODE instruction pattern:      Standard Names.     (line 1924)
  * cond_andMODE instruction pattern:      Standard Names.     (line 1924)
  * cond_ashlMODE instruction pattern:     Standard Names.     (line 1924)
  * cond_ashrMODE instruction pattern:     Standard Names.     (line 1924)
  * cond_divMODE instruction pattern:      Standard Names.     (line 1924)
! * cond_exec:                             Side Effects.       (line  244)
  * COND_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * cond_fmaMODE instruction pattern:      Standard Names.     (line 1972)
*************** Concept Index
*** 54424,54435 ****
--- 54419,54462 ----
  * cond_uminMODE instruction pattern:     Standard Names.     (line 1924)
  * cond_umodMODE instruction pattern:     Standard Names.     (line 1924)
  * cond_xorMODE instruction pattern:      Standard Names.     (line 1924)
+ * condition code status:                 Condition Code.     (line    6)
+ * condition codes:                       Comparisons.        (line   20)
+ * conditional execution:                 Conditional Execution.
+                                                              (line    6)
+ * Conditional Expressions:               Conditional Expressions.
+                                                              (line    6)
+ * conditions, in patterns:               Patterns.           (line   55)
  * configuration file:                    Filesystem.         (line    6)
  * configuration file <1>:                Host Misc.          (line    6)
  * configure terms:                       Configure Terms.    (line    6)
  * CONJ_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * const:                                 Constants.          (line  226)
+ * CONST_DECL:                            Declarations.       (line    6)
+ * const_double:                          Constants.          (line   37)
+ * CONST_DOUBLE_LOW:                      Constants.          (line   54)
+ * const_double_operand:                  Machine-Independent Predicates.
+                                                              (line   20)
+ * const_double_zero:                     Constants.          (line   67)
+ * const_double, RTL sharing:             Sharing.            (line   30)
+ * const_fixed:                           Constants.          (line  107)
+ * const_int:                             Constants.          (line    8)
+ * const_int and attribute tests:         Expressions.        (line   47)
+ * const_int and attributes:              Expressions.        (line   10)
+ * const_int_operand:                     Machine-Independent Predicates.
+                                                              (line   15)
+ * const_int, RTL sharing:                Sharing.            (line   23)
+ * const_poly_int:                        Constants.          (line  114)
+ * const_poly_int, RTL sharing:           Sharing.            (line   25)
+ * const_string:                          Constants.          (line  198)
+ * const_string and attributes:           Expressions.        (line   20)
+ * const_true_rtx:                        Constants.          (line   31)
+ * const_vector:                          Constants.          (line  121)
+ * const_vector, RTL sharing:             Sharing.            (line   33)
+ * CONST_WIDE_INT:                        Constants.          (line   81)
+ * CONST_WIDE_INT_ELT:                    Constants.          (line  103)
+ * CONST_WIDE_INT_NUNITS:                 Constants.          (line   98)
+ * CONST_WIDE_INT_VEC:                    Constants.          (line   94)
  * const0_rtx:                            Constants.          (line   21)
  * CONST0_RTX:                            Constants.          (line  244)
  * const1_rtx:                            Constants.          (line   21)
*************** Concept Index
*** 54440,54452 ****
                                                               (line    6)
  * constant definitions:                  Constant Definitions.
                                                               (line    6)
- * constants in constraints:              Simple Constraints. (line   68)
  * CONSTANT_ADDRESS_P:                    Addressing Modes.   (line   28)
  * CONSTANT_P:                            Addressing Modes.   (line   35)
  * CONSTANT_POOL_ADDRESS_P:               Flags.              (line   19)
  * CONSTANT_POOL_BEFORE_FUNCTION:         Data Output.        (line   74)
  * constm1_rtx:                           Constants.          (line   21)
  * constraint modifier characters:        Modifiers.          (line    6)
  * constraint, matching:                  Simple Constraints. (line  140)
  * constraints:                           Constraints.        (line    6)
  * constraints, defining:                 Define Constraints. (line    6)
--- 54467,54483 ----
                                                               (line    6)
  * constant definitions:                  Constant Definitions.
                                                               (line    6)
  * CONSTANT_ADDRESS_P:                    Addressing Modes.   (line   28)
  * CONSTANT_P:                            Addressing Modes.   (line   35)
  * CONSTANT_POOL_ADDRESS_P:               Flags.              (line   19)
  * CONSTANT_POOL_BEFORE_FUNCTION:         Data Output.        (line   74)
+ * constants in constraints:              Simple Constraints. (line   68)
  * constm1_rtx:                           Constants.          (line   21)
  * constraint modifier characters:        Modifiers.          (line    6)
+ * constraint_num:                        C Constraint Interface.
+                                                              (line   30)
+ * constraint_satisfied_p:                C Constraint Interface.
+                                                              (line   42)
  * constraint, matching:                  Simple Constraints. (line  140)
  * constraints:                           Constraints.        (line    6)
  * constraints, defining:                 Define Constraints. (line    6)
*************** Concept Index
*** 54454,54492 ****
                                                               (line    6)
  * constraints, testing:                  C Constraint Interface.
                                                               (line    6)
- * constraint_num:                        C Constraint Interface.
-                                                              (line   30)
- * constraint_satisfied_p:                C Constraint Interface.
-                                                              (line   42)
  * CONSTRUCTOR:                           Unary and Binary Expressions.
                                                               (line    6)
  * constructors, automatic calls:         Collect2.           (line   15)
  * constructors, output of:               Initialization.     (line    6)
- * CONST_DECL:                            Declarations.       (line    6)
- * const_double:                          Constants.          (line   37)
- * const_double, RTL sharing:             Sharing.            (line   30)
- * CONST_DOUBLE_LOW:                      Constants.          (line   54)
- * const_double_operand:                  Machine-Independent Predicates.
-                                                              (line   20)
- * const_double_zero:                     Constants.          (line   67)
- * const_fixed:                           Constants.          (line  107)
- * const_int:                             Constants.          (line    8)
- * const_int and attribute tests:         Expressions.        (line   47)
- * const_int and attributes:              Expressions.        (line   10)
- * const_int, RTL sharing:                Sharing.            (line   23)
- * const_int_operand:                     Machine-Independent Predicates.
-                                                              (line   15)
- * const_poly_int:                        Constants.          (line  114)
- * const_poly_int, RTL sharing:           Sharing.            (line   25)
- * const_string:                          Constants.          (line  198)
- * const_string and attributes:           Expressions.        (line   20)
- * const_true_rtx:                        Constants.          (line   31)
- * const_vector:                          Constants.          (line  121)
- * const_vector, RTL sharing:             Sharing.            (line   33)
- * CONST_WIDE_INT:                        Constants.          (line   81)
- * CONST_WIDE_INT_ELT:                    Constants.          (line  103)
- * CONST_WIDE_INT_NUNITS:                 Constants.          (line   98)
- * CONST_WIDE_INT_VEC:                    Constants.          (line   94)
  * container:                             Containers.         (line    6)
  * CONTINUE_STMT:                         Statements for C and C++.
                                                               (line    6)
--- 54485,54494 ----
*************** Concept Index
*** 54497,54511 ****
  * conversions:                           Conversions.        (line    6)
  * CONVERT_EXPR:                          Unary and Binary Expressions.
                                                               (line    6)
- * copysignM3 instruction pattern:        Standard Names.     (line 1295)
  * copy_rtx:                              Addressing Modes.   (line  189)
  * copy_rtx_if_shared:                    Sharing.            (line   65)
  * cosM2 instruction pattern:             Standard Names.     (line 1061)
  * costs of instructions:                 Costs.              (line    6)
- * CPLUSPLUS_CPP_SPEC:                    Driver.             (line   50)
- * CPP_SPEC:                              Driver.             (line   43)
- * CPSImode:                              Machine Modes.      (line  203)
- * cpymemM instruction pattern:           Standard Names.     (line 1566)
  * CP_INTEGRAL_TYPE:                      Types for C++.      (line   55)
  * cp_namespace_decls:                    Namespaces.         (line   49)
  * CP_TYPE_CONST_NON_VOLATILE_P:          Types for C++.      (line   33)
--- 54499,54509 ----
  * conversions:                           Conversions.        (line    6)
  * CONVERT_EXPR:                          Unary and Binary Expressions.
                                                               (line    6)
  * copy_rtx:                              Addressing Modes.   (line  189)
  * copy_rtx_if_shared:                    Sharing.            (line   65)
+ * copysignM3 instruction pattern:        Standard Names.     (line 1295)
  * cosM2 instruction pattern:             Standard Names.     (line 1061)
  * costs of instructions:                 Costs.              (line    6)
  * CP_INTEGRAL_TYPE:                      Types for C++.      (line   55)
  * cp_namespace_decls:                    Namespaces.         (line   49)
  * CP_TYPE_CONST_NON_VOLATILE_P:          Types for C++.      (line   33)
*************** Concept Index
*** 54514,54544 ****
  * cp_type_quals <1>:                     Types for C++.      (line   16)
  * CP_TYPE_RESTRICT_P:                    Types for C++.      (line   30)
  * CP_TYPE_VOLATILE_P:                    Types for C++.      (line   27)
  * CQImode:                               Machine Modes.      (line  203)
  * cross compilation and floating point:  Floating Point.     (line    6)
  * CROSSING_JUMP_P:                       Flags.              (line   10)
  * crtl->args.pops_args:                  Function Entry.     (line  111)
  * crtl->args.pretend_args_size:          Function Entry.     (line  117)
  * crtl->outgoing_args_size:              Stack Arguments.    (line   51)
  * CRTSTUFF_T_CFLAGS:                     Target Fragment.    (line   15)
  * CRTSTUFF_T_CFLAGS_S:                   Target Fragment.    (line   19)
- * CRT_CALL_STATIC_FUNCTION:              Sections.           (line  125)
  * CSImode:                               Machine Modes.      (line  203)
  * cstoreMODE4 instruction pattern:       Standard Names.     (line 1997)
  * CTF_DEBUGGING_INFO:                    CTF Debug.          (line    8)
  * CTImode:                               Machine Modes.      (line  203)
  * ctrapMM4 instruction pattern:          Standard Names.     (line 2473)
  * ctz:                                   Arithmetic.         (line  236)
- * ctzM2 instruction pattern:             Standard Names.     (line 1523)
  * CTZ_DEFINED_VALUE_AT_ZERO:             Misc.               (line  341)
  * CUMULATIVE_ARGS:                       Register Arguments. (line  131)
  * current_function_is_leaf:              Leaf Functions.     (line   50)
  * current_function_uses_only_leaf_regs:  Leaf Functions.     (line   50)
  * current_insn_predicate:                Conditional Execution.
                                                               (line   27)
- * C_COMMON_OVERRIDE_OPTIONS:             Run-time Target.    (line  136)
- * c_register_pragma:                     Misc.               (line  442)
- * c_register_pragma_with_expansion:      Misc.               (line  444)
  * DAmode:                                Machine Modes.      (line  154)
  * data bypass:                           Processor pipeline description.
                                                               (line  105)
--- 54512,54543 ----
  * cp_type_quals <1>:                     Types for C++.      (line   16)
  * CP_TYPE_RESTRICT_P:                    Types for C++.      (line   30)
  * CP_TYPE_VOLATILE_P:                    Types for C++.      (line   27)
+ * CPLUSPLUS_CPP_SPEC:                    Driver.             (line   50)
+ * CPP_SPEC:                              Driver.             (line   43)
+ * CPSImode:                              Machine Modes.      (line  203)
+ * cpymemM instruction pattern:           Standard Names.     (line 1566)
  * CQImode:                               Machine Modes.      (line  203)
  * cross compilation and floating point:  Floating Point.     (line    6)
  * CROSSING_JUMP_P:                       Flags.              (line   10)
+ * CRT_CALL_STATIC_FUNCTION:              Sections.           (line  125)
  * crtl->args.pops_args:                  Function Entry.     (line  111)
  * crtl->args.pretend_args_size:          Function Entry.     (line  117)
  * crtl->outgoing_args_size:              Stack Arguments.    (line   51)
  * CRTSTUFF_T_CFLAGS:                     Target Fragment.    (line   15)
  * CRTSTUFF_T_CFLAGS_S:                   Target Fragment.    (line   19)
  * CSImode:                               Machine Modes.      (line  203)
  * cstoreMODE4 instruction pattern:       Standard Names.     (line 1997)
  * CTF_DEBUGGING_INFO:                    CTF Debug.          (line    8)
  * CTImode:                               Machine Modes.      (line  203)
  * ctrapMM4 instruction pattern:          Standard Names.     (line 2473)
  * ctz:                                   Arithmetic.         (line  236)
  * CTZ_DEFINED_VALUE_AT_ZERO:             Misc.               (line  341)
+ * ctzM2 instruction pattern:             Standard Names.     (line 1523)
  * CUMULATIVE_ARGS:                       Register Arguments. (line  131)
  * current_function_is_leaf:              Leaf Functions.     (line   50)
  * current_function_uses_only_leaf_regs:  Leaf Functions.     (line   50)
  * current_insn_predicate:                Conditional Execution.
                                                               (line   27)
  * DAmode:                                Machine Modes.      (line  154)
  * data bypass:                           Processor pipeline description.
                                                               (line  105)
*************** Concept Index
*** 54559,54578 ****
  * De Morgan's law:                       Insn Canonicalizations.
                                                               (line   67)
  * dead_or_set_p:                         define_peephole.    (line   65)
- * DEBUGGER_ARG_OFFSET:                   All Debuggers.      (line   35)
- * DEBUGGER_AUTO_OFFSET:                  All Debuggers.      (line   27)
- * DEBUGGER_REGNO:                        All Debuggers.      (line    8)
  * debug_expr:                            Debug Information.  (line   22)
  * DEBUG_EXPR_DECL:                       Declarations.       (line    6)
  * debug_implicit_ptr:                    Debug Information.  (line   27)
  * debug_insn:                            Insns.              (line  247)
  * debug_marker:                          Debug Information.  (line   37)
  * debug_parameter_ref:                   Debug Information.  (line   34)
  * decimal float library:                 Decimal float library routines.
                                                               (line    6)
- * declaration:                           Declarations.       (line    6)
- * declarations, RTL:                     RTL Declarations.   (line    6)
- * DECLARE_LIBRARY_RENAMES:               Library Calls.      (line    8)
  * DECL_ALIGN:                            Declarations.       (line    6)
  * DECL_ANTICIPATED:                      Functions for C++.  (line   42)
  * DECL_ARGUMENTS:                        Function Basics.    (line   36)
--- 54558,54574 ----
  * De Morgan's law:                       Insn Canonicalizations.
                                                               (line   67)
  * dead_or_set_p:                         define_peephole.    (line   65)
  * debug_expr:                            Debug Information.  (line   22)
  * DEBUG_EXPR_DECL:                       Declarations.       (line    6)
  * debug_implicit_ptr:                    Debug Information.  (line   27)
  * debug_insn:                            Insns.              (line  247)
  * debug_marker:                          Debug Information.  (line   37)
  * debug_parameter_ref:                   Debug Information.  (line   34)
+ * DEBUGGER_ARG_OFFSET:                   All Debuggers.      (line   35)
+ * DEBUGGER_AUTO_OFFSET:                  All Debuggers.      (line   27)
+ * DEBUGGER_REGNO:                        All Debuggers.      (line    8)
  * decimal float library:                 Decimal float library routines.
                                                               (line    6)
  * DECL_ALIGN:                            Declarations.       (line    6)
  * DECL_ANTICIPATED:                      Functions for C++.  (line   42)
  * DECL_ARGUMENTS:                        Function Basics.    (line   36)
*************** Concept Index
*** 54588,54603 ****
  * DECL_BASE_CONSTRUCTOR_P:               Functions for C++.  (line   88)
  * DECL_COMPLETE_CONSTRUCTOR_P:           Functions for C++.  (line   84)
  * DECL_COMPLETE_DESTRUCTOR_P:            Functions for C++.  (line   98)
- * DECL_CONSTRUCTOR_P:                    Functions for C++.  (line   77)
  * DECL_CONST_MEMFUNC_P:                  Functions for C++.  (line   71)
  * DECL_CONTEXT:                          Namespaces.         (line   31)
  * DECL_CONV_FN_P:                        Functions for C++.  (line  105)
  * DECL_COPY_CONSTRUCTOR_P:               Functions for C++.  (line   92)
  * DECL_DESTRUCTOR_P:                     Functions for C++.  (line   95)
  * DECL_EXTERNAL:                         Declarations.       (line    6)
  * DECL_EXTERNAL <1>:                     Function Properties.
                                                               (line   25)
- * DECL_EXTERN_C_FUNCTION_P:              Functions for C++.  (line   46)
  * DECL_FUNCTION_MEMBER_P:                Functions for C++.  (line   61)
  * DECL_FUNCTION_SPECIFIC_OPTIMIZATION:   Function Basics.    (line    6)
  * DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties.
--- 54584,54599 ----
  * DECL_BASE_CONSTRUCTOR_P:               Functions for C++.  (line   88)
  * DECL_COMPLETE_CONSTRUCTOR_P:           Functions for C++.  (line   84)
  * DECL_COMPLETE_DESTRUCTOR_P:            Functions for C++.  (line   98)
  * DECL_CONST_MEMFUNC_P:                  Functions for C++.  (line   71)
+ * DECL_CONSTRUCTOR_P:                    Functions for C++.  (line   77)
  * DECL_CONTEXT:                          Namespaces.         (line   31)
  * DECL_CONV_FN_P:                        Functions for C++.  (line  105)
  * DECL_COPY_CONSTRUCTOR_P:               Functions for C++.  (line   92)
  * DECL_DESTRUCTOR_P:                     Functions for C++.  (line   95)
+ * DECL_EXTERN_C_FUNCTION_P:              Functions for C++.  (line   46)
  * DECL_EXTERNAL:                         Declarations.       (line    6)
  * DECL_EXTERNAL <1>:                     Function Properties.
                                                               (line   25)
  * DECL_FUNCTION_MEMBER_P:                Functions for C++.  (line   61)
  * DECL_FUNCTION_SPECIFIC_OPTIMIZATION:   Function Basics.    (line    6)
  * DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties.
*************** Concept Index
*** 54619,54627 ****
  * DECL_NAME <3>:                         Namespaces.         (line   20)
  * DECL_NAMESPACE_ALIAS:                  Namespaces.         (line   35)
  * DECL_NAMESPACE_STD_P:                  Namespaces.         (line   45)
  * DECL_NONCONVERTING_P:                  Functions for C++.  (line   80)
  * DECL_NONSTATIC_MEMBER_FUNCTION_P:      Functions for C++.  (line   68)
- * DECL_NON_THUNK_FUNCTION_P:             Functions for C++.  (line  138)
  * DECL_OVERLOADED_OPERATOR_P:            Functions for C++.  (line  102)
  * DECL_PURE_P:                           Function Properties.
                                                               (line   40)
--- 54615,54623 ----
  * DECL_NAME <3>:                         Namespaces.         (line   20)
  * DECL_NAMESPACE_ALIAS:                  Namespaces.         (line   35)
  * DECL_NAMESPACE_STD_P:                  Namespaces.         (line   45)
+ * DECL_NON_THUNK_FUNCTION_P:             Functions for C++.  (line  138)
  * DECL_NONCONVERTING_P:                  Functions for C++.  (line   80)
  * DECL_NONSTATIC_MEMBER_FUNCTION_P:      Functions for C++.  (line   68)
  * DECL_OVERLOADED_OPERATOR_P:            Functions for C++.  (line  102)
  * DECL_PURE_P:                           Function Properties.
                                                               (line   40)
*************** Concept Index
*** 54637,54642 ****
--- 54633,54641 ----
  * DECL_VIRTUAL_P:                        Function Properties.
                                                               (line   44)
  * DECL_VOLATILE_MEMFUNC_P:               Functions for C++.  (line   74)
+ * declaration:                           Declarations.       (line    6)
+ * declarations, RTL:                     RTL Declarations.   (line    6)
+ * DECLARE_LIBRARY_RENAMES:               Library Calls.      (line    8)
  * default:                               GTY Options.        (line  115)
  * default_file_start:                    File Framework.     (line    8)
  * DEFAULT_GDB_EXTENSIONS:                All Debuggers.      (line   56)
*************** Concept Index
*** 54651,54656 ****
--- 54650,54657 ----
                                                               (line   53)
  * define_bypass:                         Processor pipeline description.
                                                               (line  196)
+ * define_c_enum:                         Constant Definitions.
+                                                              (line   49)
  * define_code_attr:                      Code Iterators.     (line    6)
  * define_code_iterator:                  Code Iterators.     (line    6)
  * define_cond_exec:                      Conditional Execution.
*************** Concept Index
*** 54660,54667 ****
  * define_constraint:                     Define Constraints. (line   45)
  * define_cpu_unit:                       Processor pipeline description.
                                                               (line   68)
- * define_c_enum:                         Constant Definitions.
-                                                              (line   49)
  * define_delay:                          Delay Slots.        (line   25)
  * define_enum:                           Constant Definitions.
                                                               (line  122)
--- 54661,54666 ----
*************** Concept Index
*** 54747,54755 ****
                                                               (line   39)
  * digits in constraint:                  Simple Constraints. (line  128)
  * DImode:                                Machine Modes.      (line   45)
- * directory options .md:                 Including Patterns. (line   46)
  * DIR_SEPARATOR:                         Filesystem.         (line   18)
  * DIR_SEPARATOR_2:                       Filesystem.         (line   19)
  * disabling certain registers:           Register Basics.    (line  116)
  * dispatch table:                        Dispatch Tables.    (line    8)
  * div:                                   Arithmetic.         (line  122)
--- 54746,54754 ----
                                                               (line   39)
  * digits in constraint:                  Simple Constraints. (line  128)
  * DImode:                                Machine Modes.      (line   45)
  * DIR_SEPARATOR:                         Filesystem.         (line   18)
  * DIR_SEPARATOR_2:                       Filesystem.         (line   19)
+ * directory options .md:                 Including Patterns. (line   46)
  * disabling certain registers:           Register Basics.    (line  116)
  * dispatch table:                        Dispatch Tables.    (line    8)
  * div:                                   Arithmetic.         (line  122)
*************** Concept Index
*** 54759,54764 ****
--- 54758,54769 ----
  * division <2>:                          Arithmetic.         (line  142)
  * divM3 instruction pattern:             Standard Names.     (line  494)
  * divmodM4 instruction pattern:          Standard Names.     (line  938)
+ * DO_BODY:                               Statements for C and C++.
+                                                              (line    6)
+ * DO_COND:                               Statements for C and C++.
+                                                              (line    6)
+ * DO_STMT:                               Statements for C and C++.
+                                                              (line    6)
  * dollar sign:                           Multi-Alternative.  (line   57)
  * DOLLARS_IN_IDENTIFIERS:                Misc.               (line  487)
  * doloop_begin instruction pattern:      Standard Names.     (line 2227)
*************** Concept Index
*** 54770,54781 ****
  * DONT_USE_BUILTIN_SETJMP:               Exception Region Output.
                                                               (line   78)
  * DOUBLE_TYPE_SIZE:                      Type Layout.        (line   52)
- * DO_BODY:                               Statements for C and C++.
-                                                              (line    6)
- * DO_COND:                               Statements for C and C++.
-                                                              (line    6)
- * DO_STMT:                               Statements for C and C++.
-                                                              (line    6)
  * DQmode:                                Machine Modes.      (line  118)
  * driver:                                Driver.             (line    6)
  * DRIVER_SELF_SPECS:                     Driver.             (line    8)
--- 54775,54780 ----
*************** Concept Index
*** 54784,54801 ****
  * dump types:                            Dump types.         (line    6)
  * dump verbosity:                        Dump output verbosity.
                                                               (line    6)
- * DUMPFILE_FORMAT:                       Filesystem.         (line   67)
  * dump_basic_block:                      Dump types.         (line   29)
  * dump_generic_expr:                     Dump types.         (line   31)
  * dump_gimple_stmt:                      Dump types.         (line   33)
  * dump_printf:                           Dump types.         (line    6)
! * DWARF2_ASM_LINE_DEBUG_INFO:            DWARF.              (line   44)
! * DWARF2_ASM_VIEW_DEBUG_INFO:            DWARF.              (line   50)
! * DWARF2_DEBUGGING_INFO:                 DWARF.              (line    8)
! * DWARF2_FRAME_INFO:                     DWARF.              (line   24)
! * DWARF2_FRAME_REG_OUT:                  Frame Registers.    (line  149)
! * DWARF2_UNWIND_INFO:                    Exception Region Output.
!                                                              (line   39)
  * DWARF_ALT_FRAME_RETURN_COLUMN:         Frame Layout.       (line  146)
  * DWARF_CIE_DATA_ALIGNMENT:              Exception Region Output.
                                                               (line   90)
--- 54783,54793 ----
  * dump types:                            Dump types.         (line    6)
  * dump verbosity:                        Dump output verbosity.
                                                               (line    6)
  * dump_basic_block:                      Dump types.         (line   29)
  * dump_generic_expr:                     Dump types.         (line   31)
  * dump_gimple_stmt:                      Dump types.         (line   33)
  * dump_printf:                           Dump types.         (line    6)
! * DUMPFILE_FORMAT:                       Filesystem.         (line   67)
  * DWARF_ALT_FRAME_RETURN_COLUMN:         Frame Layout.       (line  146)
  * DWARF_CIE_DATA_ALIGNMENT:              Exception Region Output.
                                                               (line   90)
*************** Concept Index
*** 54805,54810 ****
--- 54797,54809 ----
  * DWARF_REG_TO_UNWIND_COLUMN:            Frame Registers.    (line  134)
  * DWARF_VERSION_DEFAULT:                 Frame Layout.       (line  165)
  * DWARF_ZERO_REG:                        Frame Layout.       (line  157)
+ * DWARF2_ASM_LINE_DEBUG_INFO:            DWARF.              (line   44)
+ * DWARF2_ASM_VIEW_DEBUG_INFO:            DWARF.              (line   50)
+ * DWARF2_DEBUGGING_INFO:                 DWARF.              (line    8)
+ * DWARF2_FRAME_INFO:                     DWARF.              (line   24)
+ * DWARF2_FRAME_REG_OUT:                  Frame Registers.    (line  149)
+ * DWARF2_UNWIND_INFO:                    Exception Region Output.
+                                                              (line   39)
  * DYNAMIC_CHAIN_ADDRESS:                 Frame Layout.       (line   84)
  * E in constraint:                       Simple Constraints. (line   87)
  * earlyclobber operand:                  Modifiers.          (line   25)
*************** Concept Index
*** 54863,54872 ****
  * EPILOGUE_USES:                         Function Entry.     (line  156)
  * eq:                                    Comparisons.        (line   42)
  * eq and attributes:                     Expressions.        (line   83)
- * equal:                                 Comparisons.        (line   42)
  * eq_attr:                               Expressions.        (line  104)
  * EQ_EXPR:                               Unary and Binary Expressions.
                                                               (line    6)
  * errno, implicit usage:                 Library Calls.      (line   71)
  * EXACT_DIV_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
--- 54862,54871 ----
  * EPILOGUE_USES:                         Function Entry.     (line  156)
  * eq:                                    Comparisons.        (line   42)
  * eq and attributes:                     Expressions.        (line   83)
  * eq_attr:                               Expressions.        (line  104)
  * EQ_EXPR:                               Unary and Binary Expressions.
                                                               (line    6)
+ * equal:                                 Comparisons.        (line   42)
  * errno, implicit usage:                 Library Calls.      (line   71)
  * EXACT_DIV_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
*************** Concept Index
*** 54887,54894 ****
                                                               (line    6)
  * expm1M2 instruction pattern:           Standard Names.     (line 1128)
  * expM2 instruction pattern:             Standard Names.     (line 1121)
- * expression:                            Expression trees.   (line    6)
- * expression codes:                      RTL Objects.        (line   47)
  * EXPR_FILENAME:                         Working with declarations.
                                                               (line   14)
  * EXPR_LINENO:                           Working with declarations.
--- 54886,54891 ----
*************** Concept Index
*** 54898,54909 ****
                                                               (line    6)
  * EXPR_STMT_EXPR:                        Statements for C and C++.
                                                               (line    6)
  * extended basic blocks, RTL SSA:        RTL SSA Basic Blocks.
                                                               (line   29)
  * extendMN2 instruction pattern:         Standard Names.     (line 1775)
  * extensible constraints:                Simple Constraints. (line  171)
- * extract_last_M instruction pattern:    Standard Names.     (line  601)
  * EXTRA_SPECS:                           Driver.             (line  182)
  * extv instruction pattern:              Standard Names.     (line 1866)
  * extvM instruction pattern:             Standard Names.     (line 1811)
  * extvmisalignM instruction pattern:     Standard Names.     (line 1821)
--- 54895,54908 ----
                                                               (line    6)
  * EXPR_STMT_EXPR:                        Statements for C and C++.
                                                               (line    6)
+ * expression:                            Expression trees.   (line    6)
+ * expression codes:                      RTL Objects.        (line   47)
  * extended basic blocks, RTL SSA:        RTL SSA Basic Blocks.
                                                               (line   29)
  * extendMN2 instruction pattern:         Standard Names.     (line 1775)
  * extensible constraints:                Simple Constraints. (line  171)
  * EXTRA_SPECS:                           Driver.             (line  182)
+ * extract_last_M instruction pattern:    Standard Names.     (line  601)
  * extv instruction pattern:              Standard Names.     (line 1866)
  * extvM instruction pattern:             Standard Names.     (line 1811)
  * extvmisalignM instruction pattern:     Standard Names.     (line 1821)
*************** Concept Index
*** 54929,54937 ****
  * ffs:                                   Arithmetic.         (line  216)
  * ffsM2 instruction pattern:             Standard Names.     (line 1479)
  * FIELD_DECL:                            Declarations.       (line    6)
  * files and passes of the compiler:      Passes.             (line    6)
  * files, generated:                      Files.              (line    6)
- * file_end_indicate_exec_stack:          File Framework.     (line   39)
  * final_absence_set:                     Processor pipeline description.
                                                               (line  223)
  * FINAL_PRESCAN_INSN:                    Instruction Output. (line   60)
--- 54928,54936 ----
  * ffs:                                   Arithmetic.         (line  216)
  * ffsM2 instruction pattern:             Standard Names.     (line 1479)
  * FIELD_DECL:                            Declarations.       (line    6)
+ * file_end_indicate_exec_stack:          File Framework.     (line   39)
  * files and passes of the compiler:      Passes.             (line    6)
  * files, generated:                      Files.              (line    6)
  * final_absence_set:                     Processor pipeline description.
                                                               (line  223)
  * FINAL_PRESCAN_INSN:                    Instruction Output. (line   60)
*************** Concept Index
*** 54939,54959 ****
                                                               (line  223)
  * final_sequence:                        Instruction Output. (line  144)
  * FIND_BASE_TERM:                        Addressing Modes.   (line  117)
- * finite state automaton minimization:   Processor pipeline description.
-                                                              (line  304)
  * FINI_ARRAY_SECTION_ASM_OP:             Sections.           (line  113)
  * FINI_SECTION_ASM_OP:                   Sections.           (line   98)
  * FIRST_PARM_OFFSET:                     Frame Layout.       (line   59)
  * FIRST_PARM_OFFSET and virtual registers: Regs and Memory.  (line   65)
  * FIRST_PSEUDO_REGISTER:                 Register Basics.    (line    8)
  * FIRST_STACK_REG:                       Stack Registers.    (line   26)
  * FIRST_VIRTUAL_REGISTER:                Regs and Memory.    (line   51)
  * fix:                                   Conversions.        (line   66)
  * fix-it hints:                          Guidelines for Diagnostics.
                                                               (line  344)
  * fixed register:                        Register Basics.    (line   15)
- * fixed-point fractional library:        Fixed-point fractional library routines.
-                                                              (line    6)
  * FIXED_CONVERT_EXPR:                    Unary and Binary Expressions.
                                                               (line    6)
  * FIXED_CST:                             Constant expressions.
--- 54938,54959 ----
                                                               (line  223)
  * final_sequence:                        Instruction Output. (line  144)
  * FIND_BASE_TERM:                        Addressing Modes.   (line  117)
  * FINI_ARRAY_SECTION_ASM_OP:             Sections.           (line  113)
  * FINI_SECTION_ASM_OP:                   Sections.           (line   98)
+ * finite state automaton minimization:   Processor pipeline description.
+                                                              (line  304)
  * FIRST_PARM_OFFSET:                     Frame Layout.       (line   59)
  * FIRST_PARM_OFFSET and virtual registers: Regs and Memory.  (line   65)
  * FIRST_PSEUDO_REGISTER:                 Register Basics.    (line    8)
  * FIRST_STACK_REG:                       Stack Registers.    (line   26)
  * FIRST_VIRTUAL_REGISTER:                Regs and Memory.    (line   51)
  * fix:                                   Conversions.        (line   66)
+ * FIX_TRUNC_EXPR:                        Unary and Binary Expressions.
+                                                              (line    6)
+ * fix_truncMN2 instruction pattern:      Standard Names.     (line 1762)
  * fix-it hints:                          Guidelines for Diagnostics.
                                                               (line  344)
  * fixed register:                        Register Basics.    (line   15)
  * FIXED_CONVERT_EXPR:                    Unary and Binary Expressions.
                                                               (line    6)
  * FIXED_CST:                             Constant expressions.
*************** Concept Index
*** 54962,54978 ****
  * FIXED_REGISTERS:                       Register Basics.    (line   14)
  * fixed_regs:                            Register Basics.    (line  102)
  * fixed_size_mode:                       Machine Modes.      (line  309)
  * fixMN2 instruction pattern:            Standard Names.     (line 1742)
- * fixunsMN2 instruction pattern:         Standard Names.     (line 1751)
  * fixuns_truncMN2 instruction pattern:   Standard Names.     (line 1766)
! * fix_truncMN2 instruction pattern:      Standard Names.     (line 1762)
! * FIX_TRUNC_EXPR:                        Unary and Binary Expressions.
!                                                              (line    6)
  * flags in RTL expression:               Flags.              (line    6)
  * float:                                 Conversions.        (line   58)
- * floating point and cross compilation:  Floating Point.     (line    6)
- * floatMN2 instruction pattern:          Standard Names.     (line 1734)
- * floatunsMN2 instruction pattern:       Standard Names.     (line 1738)
  * FLOAT_EXPR:                            Unary and Binary Expressions.
                                                               (line    6)
  * float_extend:                          Conversions.        (line   33)
--- 54962,54974 ----
  * FIXED_REGISTERS:                       Register Basics.    (line   14)
  * fixed_regs:                            Register Basics.    (line  102)
  * fixed_size_mode:                       Machine Modes.      (line  309)
+ * fixed-point fractional library:        Fixed-point fractional library routines.
+                                                              (line    6)
  * fixMN2 instruction pattern:            Standard Names.     (line 1742)
  * fixuns_truncMN2 instruction pattern:   Standard Names.     (line 1766)
! * fixunsMN2 instruction pattern:         Standard Names.     (line 1751)
  * flags in RTL expression:               Flags.              (line    6)
  * float:                                 Conversions.        (line   58)
  * FLOAT_EXPR:                            Unary and Binary Expressions.
                                                               (line    6)
  * float_extend:                          Conversions.        (line   33)
*************** Concept Index
*** 54983,54993 ****
  * FLOAT_WORDS_BIG_ENDIAN:                Storage Layout.     (line   41)
  * FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory.
                                                               (line  234)
! * floorM2 instruction pattern:           Standard Names.     (line 1222)
  * FLOOR_DIV_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * FLOOR_MOD_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * flow-insensitive alias analysis:       Alias analysis.     (line    6)
  * flow-sensitive alias analysis:         Alias analysis.     (line    6)
  * fma:                                   Arithmetic.         (line  118)
--- 54979,54992 ----
  * FLOAT_WORDS_BIG_ENDIAN:                Storage Layout.     (line   41)
  * FLOAT_WORDS_BIG_ENDIAN, (lack of) effect on subreg: Regs and Memory.
                                                               (line  234)
! * floating point and cross compilation:  Floating Point.     (line    6)
! * floatMN2 instruction pattern:          Standard Names.     (line 1734)
! * floatunsMN2 instruction pattern:       Standard Names.     (line 1738)
  * FLOOR_DIV_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * FLOOR_MOD_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
+ * floorM2 instruction pattern:           Standard Names.     (line 1222)
  * flow-insensitive alias analysis:       Alias analysis.     (line    6)
  * flow-sensitive alias analysis:         Alias analysis.     (line    6)
  * fma:                                   Arithmetic.         (line  118)
*************** Concept Index
*** 55000,55007 ****
  * fnmsM4 instruction pattern:            Standard Names.     (line  549)
  * fold_extract_last_M instruction pattern: Standard Names.   (line  608)
  * fold_left_plus_M instruction pattern:  Standard Names.     (line  616)
- * FORCE_CODE_SECTION_ALIGN:              Sections.           (line  149)
- * force_reg:                             Standard Names.     (line   36)
  * FOR_BODY:                              Statements for C and C++.
                                                               (line    6)
  * FOR_COND:                              Statements for C and C++.
--- 54999,55004 ----
*************** Concept Index
*** 55013,55024 ****
  * FOR_STMT:                              Statements for C and C++.
                                                               (line    6)
  * for_user:                              GTY Options.        (line  107)
  * fractional types:                      Fixed-point fractional library routines.
                                                               (line    6)
  * fractMN2 instruction pattern:          Standard Names.     (line 1784)
  * fractunsMN2 instruction pattern:       Standard Names.     (line 1799)
- * fract_convert:                         Conversions.        (line   82)
- * FRACT_TYPE_SIZE:                       Type Layout.        (line   67)
  * frame layout:                          Frame Layout.       (line    6)
  * FRAME_ADDR_RTX:                        Frame Layout.       (line  108)
  * FRAME_GROWS_DOWNWARD:                  Frame Layout.       (line   26)
--- 55010,55023 ----
  * FOR_STMT:                              Statements for C and C++.
                                                               (line    6)
  * for_user:                              GTY Options.        (line  107)
+ * FORCE_CODE_SECTION_ALIGN:              Sections.           (line  149)
+ * force_reg:                             Standard Names.     (line   36)
+ * fract_convert:                         Conversions.        (line   82)
+ * FRACT_TYPE_SIZE:                       Type Layout.        (line   67)
  * fractional types:                      Fixed-point fractional library routines.
                                                               (line    6)
  * fractMN2 instruction pattern:          Standard Names.     (line 1784)
  * fractunsMN2 instruction pattern:       Standard Names.     (line 1799)
  * frame layout:                          Frame Layout.       (line    6)
  * FRAME_ADDR_RTX:                        Frame Layout.       (line  108)
  * FRAME_GROWS_DOWNWARD:                  Frame Layout.       (line   26)
*************** Concept Index
*** 55047,55054 ****
                                                               (line  179)
  * function properties:                   Function Properties.
                                                               (line    6)
- * function-call insns:                   Calls.              (line    6)
- * functions, leaf:                       Leaf Functions.     (line    6)
  * FUNCTION_ARG_REGNO_P:                  Register Arguments. (line  255)
  * FUNCTION_BOUNDARY:                     Storage Layout.     (line  181)
  * FUNCTION_DECL:                         Functions.          (line    6)
--- 55046,55051 ----
*************** Concept Index
*** 55058,55063 ****
--- 55055,55062 ----
  * FUNCTION_TYPE:                         Types.              (line    6)
  * FUNCTION_VALUE:                        Scalar Return.      (line   52)
  * FUNCTION_VALUE_REGNO_P:                Scalar Return.      (line   78)
+ * function-call insns:                   Calls.              (line    6)
+ * functions, leaf:                       Leaf Functions.     (line    6)
  * fundamental type:                      Types.              (line    6)
  * fused multiply-add:                    Arithmetic.         (line  118)
  * G in constraint:                       Simple Constraints. (line   96)
*************** Concept Index
*** 55072,55077 ****
--- 55071,55079 ----
                                                               (line   41)
  * ge:                                    Comparisons.        (line   62)
  * ge and attributes:                     Expressions.        (line   83)
+ * GE_EXPR:                               Unary and Binary Expressions.
+                                                              (line    6)
+ * GEN_ERRNO_RTX:                         Library Calls.      (line   71)
  * gencodes:                              RTL passes.         (line   18)
  * general_operand:                       Machine-Independent Predicates.
                                                               (line  104)
*************** Concept Index
*** 55084,55090 ****
  * generic predicates:                    Machine-Independent Predicates.
                                                               (line    6)
  * genflags:                              RTL passes.         (line   18)
- * GEN_ERRNO_RTX:                         Library Calls.      (line   71)
  * get_attr:                              Expressions.        (line   99)
  * get_attr_length:                       Insn Lengths.       (line   52)
  * GET_CLASS_NARROWEST_MODE:              Machine Modes.      (line  434)
--- 55086,55091 ----
*************** Concept Index
*** 55110,55117 ****
                                                               (line 2844)
  * geu:                                   Comparisons.        (line   62)
  * geu and attributes:                    Expressions.        (line   83)
- * GE_EXPR:                               Unary and Binary Expressions.
-                                                              (line    6)
  * GGC:                                   Type Information.   (line    6)
  * ggc_collect:                           Invoking the garbage collector.
                                                               (line    6)
--- 55111,55116 ----
*************** Concept Index
*** 55152,55165 ****
  * gimple_assign_cast_p <1>:              GIMPLE_ASSIGN.      (line  104)
  * gimple_assign_lhs:                     GIMPLE_ASSIGN.      (line   62)
  * gimple_assign_lhs_ptr:                 GIMPLE_ASSIGN.      (line   65)
  * gimple_assign_rhs1:                    GIMPLE_ASSIGN.      (line   68)
  * gimple_assign_rhs1_ptr:                GIMPLE_ASSIGN.      (line   71)
  * gimple_assign_rhs2:                    GIMPLE_ASSIGN.      (line   75)
  * gimple_assign_rhs2_ptr:                GIMPLE_ASSIGN.      (line   78)
  * gimple_assign_rhs3:                    GIMPLE_ASSIGN.      (line   82)
  * gimple_assign_rhs3_ptr:                GIMPLE_ASSIGN.      (line   85)
- * gimple_assign_rhs_class:               GIMPLE_ASSIGN.      (line   56)
- * gimple_assign_rhs_code:                GIMPLE_ASSIGN.      (line   52)
  * gimple_assign_set_lhs:                 GIMPLE_ASSIGN.      (line   89)
  * gimple_assign_set_rhs1:                GIMPLE_ASSIGN.      (line   92)
  * gimple_assign_set_rhs2:                GIMPLE_ASSIGN.      (line   96)
--- 55151,55164 ----
  * gimple_assign_cast_p <1>:              GIMPLE_ASSIGN.      (line  104)
  * gimple_assign_lhs:                     GIMPLE_ASSIGN.      (line   62)
  * gimple_assign_lhs_ptr:                 GIMPLE_ASSIGN.      (line   65)
+ * gimple_assign_rhs_class:               GIMPLE_ASSIGN.      (line   56)
+ * gimple_assign_rhs_code:                GIMPLE_ASSIGN.      (line   52)
  * gimple_assign_rhs1:                    GIMPLE_ASSIGN.      (line   68)
  * gimple_assign_rhs1_ptr:                GIMPLE_ASSIGN.      (line   71)
  * gimple_assign_rhs2:                    GIMPLE_ASSIGN.      (line   75)
  * gimple_assign_rhs2_ptr:                GIMPLE_ASSIGN.      (line   78)
  * gimple_assign_rhs3:                    GIMPLE_ASSIGN.      (line   82)
  * gimple_assign_rhs3_ptr:                GIMPLE_ASSIGN.      (line   85)
  * gimple_assign_set_lhs:                 GIMPLE_ASSIGN.      (line   89)
  * gimple_assign_set_rhs1:                GIMPLE_ASSIGN.      (line   92)
  * gimple_assign_set_rhs2:                GIMPLE_ASSIGN.      (line   96)
*************** Concept Index
*** 55285,55294 ****
                                                               (line   40)
  * gimple_modified_p:                     Manipulating GIMPLE statements.
                                                               (line  122)
- * GIMPLE_NOP:                            GIMPLE_NOP.         (line    6)
- * gimple_nop_p:                          GIMPLE_NOP.         (line    9)
  * gimple_no_warning_p:                   Manipulating GIMPLE statements.
                                                               (line   43)
  * gimple_num_ops:                        Logical Operators.  (line   75)
  * gimple_num_ops <1>:                    Manipulating GIMPLE statements.
                                                               (line   67)
--- 55284,55293 ----
                                                               (line   40)
  * gimple_modified_p:                     Manipulating GIMPLE statements.
                                                               (line  122)
  * gimple_no_warning_p:                   Manipulating GIMPLE statements.
                                                               (line   43)
+ * GIMPLE_NOP:                            GIMPLE_NOP.         (line    6)
+ * gimple_nop_p:                          GIMPLE_NOP.         (line    9)
  * gimple_num_ops:                        Logical Operators.  (line   75)
  * gimple_num_ops <1>:                    Manipulating GIMPLE statements.
                                                               (line   67)
*************** Concept Index
*** 55382,55387 ****
--- 55381,55388 ----
  * gimple_omp_return_nowait_p:            GIMPLE_OMP_RETURN.  (line   13)
  * gimple_omp_return_set_nowait:          GIMPLE_OMP_RETURN.  (line   10)
  * GIMPLE_OMP_SECTION:                    GIMPLE_OMP_SECTION. (line    6)
+ * gimple_omp_section_last_p:             GIMPLE_OMP_SECTION. (line   11)
+ * gimple_omp_section_set_last:           GIMPLE_OMP_SECTION. (line   15)
  * GIMPLE_OMP_SECTIONS:                   GIMPLE_OMP_SECTIONS.
                                                               (line    6)
  * gimple_omp_sections_clauses:           GIMPLE_OMP_SECTIONS.
*************** Concept Index
*** 55396,55403 ****
                                                               (line   35)
  * gimple_omp_sections_set_control:       GIMPLE_OMP_SECTIONS.
                                                               (line   24)
- * gimple_omp_section_last_p:             GIMPLE_OMP_SECTION. (line   11)
- * gimple_omp_section_set_last:           GIMPLE_OMP_SECTION. (line   15)
  * gimple_omp_set_body:                   GIMPLE_OMP_PARALLEL.
                                                               (line   26)
  * GIMPLE_OMP_SINGLE:                     GIMPLE_OMP_SINGLE.  (line    6)
--- 55397,55402 ----
*************** Concept Index
*** 55407,55417 ****
  * gimple_op:                             Logical Operators.  (line   78)
  * gimple_op <1>:                         Manipulating GIMPLE statements.
                                                               (line   73)
  * gimple_ops:                            Logical Operators.  (line   81)
  * gimple_ops <1>:                        Manipulating GIMPLE statements.
                                                               (line   70)
- * gimple_op_ptr:                         Manipulating GIMPLE statements.
-                                                              (line   76)
  * GIMPLE_PHI:                            GIMPLE_PHI.         (line    6)
  * gimple_phi_arg:                        GIMPLE_PHI.         (line   24)
  * gimple_phi_arg <1>:                    SSA.                (line   62)
--- 55406,55416 ----
  * gimple_op:                             Logical Operators.  (line   78)
  * gimple_op <1>:                         Manipulating GIMPLE statements.
                                                               (line   73)
+ * gimple_op_ptr:                         Manipulating GIMPLE statements.
+                                                              (line   76)
  * gimple_ops:                            Logical Operators.  (line   81)
  * gimple_ops <1>:                        Manipulating GIMPLE statements.
                                                               (line   70)
  * GIMPLE_PHI:                            GIMPLE_PHI.         (line    6)
  * gimple_phi_arg:                        GIMPLE_PHI.         (line   24)
  * gimple_phi_arg <1>:                    SSA.                (line   62)
*************** Concept Index
*** 55582,55592 ****
  * gsi_stmt_ptr:                          Sequence iterators. (line   79)
  * gt:                                    Comparisons.        (line   50)
  * gt and attributes:                     Expressions.        (line   83)
  * gtu:                                   Comparisons.        (line   54)
  * gtu and attributes:                    Expressions.        (line   83)
  * GTY:                                   Type Information.   (line    6)
- * GT_EXPR:                               Unary and Binary Expressions.
-                                                              (line    6)
  * guidelines for diagnostics:            Guidelines for Diagnostics.
                                                               (line    6)
  * guidelines for options:                Guidelines for Options.
--- 55581,55591 ----
  * gsi_stmt_ptr:                          Sequence iterators. (line   79)
  * gt:                                    Comparisons.        (line   50)
  * gt and attributes:                     Expressions.        (line   83)
+ * GT_EXPR:                               Unary and Binary Expressions.
+                                                              (line    6)
  * gtu:                                   Comparisons.        (line   54)
  * gtu and attributes:                    Expressions.        (line   83)
  * GTY:                                   Type Information.   (line    6)
  * guidelines for diagnostics:            Guidelines for Diagnostics.
                                                               (line    6)
  * guidelines for options:                Guidelines for Options.
*************** Concept Index
*** 55595,55607 ****
                                                               (line    6)
  * H in constraint:                       Simple Constraints. (line   96)
  * HAmode:                                Machine Modes.      (line  146)
  * HANDLER:                               Statements for C and C++.
                                                               (line    6)
  * HANDLER_BODY:                          Statements for C and C++.
                                                               (line    6)
  * HANDLER_PARMS:                         Statements for C and C++.
                                                               (line    6)
- * HANDLE_PRAGMA_PACK_WITH_EXPANSION:     Misc.               (line  477)
  * hard registers:                        Regs and Memory.    (line    9)
  * HARD_FRAME_POINTER_IS_ARG_POINTER:     Frame Registers.    (line   57)
  * HARD_FRAME_POINTER_IS_FRAME_POINTER:   Frame Registers.    (line   50)
--- 55594,55606 ----
                                                               (line    6)
  * H in constraint:                       Simple Constraints. (line   96)
  * HAmode:                                Machine Modes.      (line  146)
+ * HANDLE_PRAGMA_PACK_WITH_EXPANSION:     Misc.               (line  477)
  * HANDLER:                               Statements for C and C++.
                                                               (line    6)
  * HANDLER_BODY:                          Statements for C and C++.
                                                               (line    6)
  * HANDLER_PARMS:                         Statements for C and C++.
                                                               (line    6)
  * hard registers:                        Regs and Memory.    (line    9)
  * HARD_FRAME_POINTER_IS_ARG_POINTER:     Frame Registers.    (line   57)
  * HARD_FRAME_POINTER_IS_FRAME_POINTER:   Frame Registers.    (line   50)
*************** Concept Index
*** 55660,55671 ****
  * IDENTIFIER_TYPENAME_P:                 Identifiers.        (line   33)
  * IEEE 754-2008:                         Decimal float library routines.
                                                               (line    6)
- * IFCVT_MACHDEP_INIT:                    Misc.               (line  606)
- * IFCVT_MODIFY_CANCEL:                   Misc.               (line  600)
- * IFCVT_MODIFY_FINAL:                    Misc.               (line  594)
- * IFCVT_MODIFY_INSN:                     Misc.               (line  588)
- * IFCVT_MODIFY_MULTIPLE_TESTS:           Misc.               (line  580)
- * IFCVT_MODIFY_TESTS:                    Misc.               (line  570)
  * IF_COND:                               Statements for C and C++.
                                                               (line    6)
  * IF_STMT:                               Statements for C and C++.
--- 55659,55664 ----
*************** Concept Index
*** 55673,55690 ****
  * if_then_else:                          Comparisons.        (line   70)
  * if_then_else and attributes:           Expressions.        (line   32)
  * if_then_else usage:                    Side Effects.       (line   49)
  * IMAGPART_EXPR:                         Unary and Binary Expressions.
                                                               (line    6)
  * Immediate Uses:                        SSA Operands.       (line  258)
  * immediate_operand:                     Machine-Independent Predicates.
                                                               (line   10)
  * IMMEDIATE_PREFIX:                      Instruction Output. (line  153)
  * include:                               Including Patterns. (line    6)
  * INCLUDE_DEFAULTS:                      Driver.             (line  331)
  * inclusive-or, bitwise:                 Arithmetic.         (line  169)
  * INCOMING_FRAME_SP_OFFSET:              Frame Layout.       (line  194)
- * INCOMING_REGNO:                        Register Basics.    (line  129)
  * INCOMING_REG_PARM_STACK_SPACE:         Stack Arguments.    (line   76)
  * INCOMING_RETURN_ADDR_RTX:              Frame Layout.       (line  133)
  * INCOMING_STACK_BOUNDARY:               Storage Layout.     (line  176)
  * INDEX_REG_CLASS:                       Register Classes.   (line  140)
--- 55666,55695 ----
  * if_then_else:                          Comparisons.        (line   70)
  * if_then_else and attributes:           Expressions.        (line   32)
  * if_then_else usage:                    Side Effects.       (line   49)
+ * IFCVT_MACHDEP_INIT:                    Misc.               (line  606)
+ * IFCVT_MODIFY_CANCEL:                   Misc.               (line  600)
+ * IFCVT_MODIFY_FINAL:                    Misc.               (line  594)
+ * IFCVT_MODIFY_INSN:                     Misc.               (line  588)
+ * IFCVT_MODIFY_MULTIPLE_TESTS:           Misc.               (line  580)
+ * IFCVT_MODIFY_TESTS:                    Misc.               (line  570)
  * IMAGPART_EXPR:                         Unary and Binary Expressions.
                                                               (line    6)
  * Immediate Uses:                        SSA Operands.       (line  258)
  * immediate_operand:                     Machine-Independent Predicates.
                                                               (line   10)
  * IMMEDIATE_PREFIX:                      Instruction Output. (line  153)
+ * in_struct:                             Flags.              (line  254)
+ * in_struct, in code_label and note:     Flags.              (line   48)
+ * in_struct, in insn and jump_insn and call_insn: Flags.     (line   38)
+ * in_struct, in insn, call_insn, jump_insn and jump_table_data: Flags.
+                                                              (line  162)
+ * in_struct, in subreg:                  Flags.              (line  201)
  * include:                               Including Patterns. (line    6)
  * INCLUDE_DEFAULTS:                      Driver.             (line  331)
  * inclusive-or, bitwise:                 Arithmetic.         (line  169)
  * INCOMING_FRAME_SP_OFFSET:              Frame Layout.       (line  194)
  * INCOMING_REG_PARM_STACK_SPACE:         Stack Arguments.    (line   76)
+ * INCOMING_REGNO:                        Register Basics.    (line  129)
  * INCOMING_RETURN_ADDR_RTX:              Frame Layout.       (line  133)
  * INCOMING_STACK_BOUNDARY:               Storage Layout.     (line  176)
  * INDEX_REG_CLASS:                       Register Classes.   (line  140)
*************** Concept Index
*** 55692,55700 ****
  * indirect_operand:                      Machine-Independent Predicates.
                                                               (line   70)
  * INDIRECT_REF:                          Storage References. (line    6)
- * initialization routines:               Initialization.     (line    6)
- * INITIAL_ELIMINATION_OFFSET:            Elimination.        (line   68)
- * INITIAL_FRAME_ADDRESS_RTX:             Frame Layout.       (line   75)
  * INIT_ARRAY_SECTION_ASM_OP:             Sections.           (line  106)
  * INIT_CUMULATIVE_ARGS:                  Register Arguments. (line  152)
  * INIT_CUMULATIVE_INCOMING_ARGS:         Register Arguments. (line  180)
--- 55697,55702 ----
*************** Concept Index
*** 55708,55713 ****
--- 55710,55718 ----
  * INIT_SECTION_ASM_OP:                   Sections.           (line   90)
  * INIT_SECTION_ASM_OP <1>:               Macros for Initialization.
                                                               (line    9)
+ * INITIAL_ELIMINATION_OFFSET:            Elimination.        (line   68)
+ * INITIAL_FRAME_ADDRESS_RTX:             Frame Layout.       (line   75)
+ * initialization routines:               Initialization.     (line    6)
  * inlining:                              Target Attributes.  (line  103)
  * insert_insn_on_edge:                   Maintaining the CFG.
                                                               (line  104)
*************** Concept Index
*** 55725,55735 ****
  * insn lengths, computing:               Insn Lengths.       (line    6)
  * insn notes, notes:                     Basic Blocks.       (line   52)
  * insn splitting:                        Insn Splitting.     (line    6)
- * insn-attr.h:                           Defining Attributes.
-                                                              (line   34)
- * insns:                                 Insns.              (line    6)
- * insns, generating:                     RTL Template.       (line    6)
- * insns, recognizing:                    RTL Template.       (line    6)
  * INSN_ANNULLED_BRANCH_P:                Flags.              (line   28)
  * INSN_CODE:                             Insns.              (line  318)
  * INSN_DELETED_P:                        Flags.              (line   33)
--- 55730,55735 ----
*************** Concept Index
*** 55739,55744 ****
--- 55739,55749 ----
  * INSN_SETS_ARE_DELAYED:                 Misc.               (line  493)
  * INSN_UID:                              Insns.              (line   23)
  * INSN_VAR_LOCATION:                     Insns.              (line  247)
+ * insn-attr.h:                           Defining Attributes.
+                                                              (line   34)
+ * insns:                                 Insns.              (line    6)
+ * insns, generating:                     RTL Template.       (line    6)
+ * insns, recognizing:                    RTL Template.       (line    6)
  * instruction attributes:                Insn Attributes.    (line    6)
  * instruction latency time:              Processor pipeline description.
                                                               (line    6)
*************** Concept Index
*** 55754,55759 ****
--- 55759,55773 ----
  * insvM instruction pattern:             Standard Names.     (line 1842)
  * insvmisalignM instruction pattern:     Standard Names.     (line 1852)
  * int iterators in .md files:            Int Iterators.      (line    6)
+ * INT_FAST16_TYPE:                       Type Layout.        (line  226)
+ * INT_FAST32_TYPE:                       Type Layout.        (line  227)
+ * INT_FAST64_TYPE:                       Type Layout.        (line  228)
+ * INT_FAST8_TYPE:                        Type Layout.        (line  225)
+ * INT_LEAST16_TYPE:                      Type Layout.        (line  218)
+ * INT_LEAST32_TYPE:                      Type Layout.        (line  219)
+ * INT_LEAST64_TYPE:                      Type Layout.        (line  220)
+ * INT_LEAST8_TYPE:                       Type Layout.        (line  217)
+ * INT_TYPE_SIZE:                         Type Layout.        (line   11)
  * INT16_TYPE:                            Type Layout.        (line  210)
  * INT32_TYPE:                            Type Layout.        (line  211)
  * INT64_TYPE:                            Type Layout.        (line  212)
*************** Concept Index
*** 55770,55792 ****
  * INTMAX_TYPE:                           Type Layout.        (line  186)
  * INTPTR_TYPE:                           Type Layout.        (line  233)
  * introduction:                          Top.                (line    6)
- * INT_FAST16_TYPE:                       Type Layout.        (line  226)
- * INT_FAST32_TYPE:                       Type Layout.        (line  227)
- * INT_FAST64_TYPE:                       Type Layout.        (line  228)
- * INT_FAST8_TYPE:                        Type Layout.        (line  225)
- * INT_LEAST16_TYPE:                      Type Layout.        (line  218)
- * INT_LEAST32_TYPE:                      Type Layout.        (line  219)
- * INT_LEAST64_TYPE:                      Type Layout.        (line  220)
- * INT_LEAST8_TYPE:                       Type Layout.        (line  217)
- * INT_TYPE_SIZE:                         Type Layout.        (line   11)
  * INVOKE__main:                          Macros for Initialization.
                                                               (line   50)
- * in_struct:                             Flags.              (line  254)
- * in_struct, in code_label and note:     Flags.              (line   48)
- * in_struct, in insn and jump_insn and call_insn: Flags.     (line   38)
- * in_struct, in insn, call_insn, jump_insn and jump_table_data: Flags.
-                                                              (line  162)
- * in_struct, in subreg:                  Flags.              (line  201)
  * ior:                                   Arithmetic.         (line  169)
  * ior and attributes:                    Expressions.        (line   50)
  * ior, canonicalization of:              Insn Canonicalizations.
--- 55784,55791 ----
*************** Concept Index
*** 55794,55800 ****
  * iorM3 instruction pattern:             Standard Names.     (line  494)
  * IPA passes:                            IPA passes.         (line    6)
  * IRA_HARD_REGNO_ADD_COST_MULTIPLIER:    Allocation Order.   (line   44)
- * issignalingM2 instruction pattern:     Standard Names.     (line 1310)
  * is_a:                                  Machine Modes.      (line  351)
  * IS_ASM_LOGICAL_LINE_SEPARATOR:         Data Output.        (line  129)
  * is_gimple_addressable:                 Logical Operators.  (line  112)
--- 55793,55798 ----
*************** Concept Index
*** 55810,55815 ****
--- 55808,55814 ----
  * is_gimple_min_invariant:               Logical Operators.  (line  130)
  * is_gimple_omp:                         Logical Operators.  (line  165)
  * is_gimple_val:                         Logical Operators.  (line  106)
+ * issignalingM2 instruction pattern:     Standard Names.     (line 1310)
  * iterators in .md files:                Iterators.          (line    6)
  * IV analysis on GIMPLE:                 Scalar evolutions.  (line    6)
  * IV analysis on RTL:                    loop-iv.            (line    6)
*************** Concept Index
*** 55819,55828 ****
  * jump instruction pattern:              Standard Names.     (line 2048)
  * jump instruction patterns:             Jump Patterns.      (line    6)
  * jump instructions and set:             Side Effects.       (line   49)
- * jump, in call_insn:                    Flags.              (line  175)
- * jump, in insn:                         Flags.              (line  171)
- * jump, in mem:                          Flags.              (line   59)
- * Jumps:                                 Jumps.              (line    6)
  * JUMP_ALIGN:                            Alignment Output.   (line    8)
  * jump_insn:                             Insns.              (line   73)
  * jump_insn and /f:                      Flags.              (line  135)
--- 55818,55823 ----
*************** Concept Index
*** 55832,55903 ****
  * jump_insn and /u:                      Flags.              (line   28)
  * jump_insn and /v:                      Flags.              (line   33)
  * JUMP_LABEL:                            Insns.              (line   80)
- * JUMP_TABLES_IN_TEXT_SECTION:           Sections.           (line  155)
  * jump_table_data:                       Insns.              (line  166)
  * jump_table_data and /s:                Flags.              (line  162)
  * jump_table_data and /v:                Flags.              (line   33)
  * LABEL_ALIGN:                           Alignment Output.   (line   42)
  * LABEL_ALIGN_AFTER_BARRIER:             Alignment Output.   (line   21)
- * LABEL_ALTERNATE_NAME:                  Edges.              (line  179)
  * LABEL_ALT_ENTRY_P:                     Insns.              (line  146)
  * LABEL_DECL:                            Declarations.       (line    6)
  * LABEL_KIND:                            Insns.              (line  146)
  * LABEL_NUSES:                           Insns.              (line  142)
  * LABEL_PRESERVE_P:                      Flags.              (line   48)
  * label_ref:                             Constants.          (line  213)
  * label_ref and /v:                      Flags.              (line   54)
- * label_ref, RTL sharing:                Sharing.            (line   36)
  * LABEL_REF_NONLOCAL_P:                  Flags.              (line   54)
  * language-dependent trees:              Language-dependent trees.
                                                               (line    6)
  * language-independent intermediate representation: Parsing pass.
                                                               (line   13)
- * lang_hooks.gimplify_expr:              Gimplification pass.
-                                                              (line   18)
- * lang_hooks.parse_file:                 Parsing pass.       (line    6)
  * large return values:                   Aggregate Return.   (line    6)
  * LAST_STACK_REG:                        Stack Registers.    (line   30)
  * LAST_VIRTUAL_REGISTER:                 Regs and Memory.    (line   51)
  * late IPA passes:                       Late IPA passes.    (line    6)
  * lceilMN2:                              Standard Names.     (line 1290)
  * LCSSA:                                 LCSSA.              (line    6)
- * LDD_SUFFIX:                            Macros for Initialization.
-                                                              (line  129)
- * ldexpM3 instruction pattern:           Standard Names.     (line 1052)
  * LD_FINI_SWITCH:                        Macros for Initialization.
                                                               (line   28)
  * LD_INIT_SWITCH:                        Macros for Initialization.
                                                               (line   24)
  * le:                                    Comparisons.        (line   66)
  * le and attributes:                     Expressions.        (line   83)
  * leaf functions:                        Leaf Functions.     (line    6)
  * leaf_function_p:                       Standard Names.     (line 2136)
- * LEAF_REGISTERS:                        Leaf Functions.     (line   23)
  * LEAF_REG_REMAP:                        Leaf Functions.     (line   37)
  * left rotate:                           Arithmetic.         (line  201)
  * left shift:                            Arithmetic.         (line  179)
  * LEGITIMATE_PIC_OPERAND_P:              PIC.                (line   31)
  * LEGITIMIZE_RELOAD_ADDRESS:             Addressing Modes.   (line  150)
- * length:                                GTY Options.        (line   47)
  * len_load_M instruction pattern:        Standard Names.     (line  418)
  * len_store_M instruction pattern:       Standard Names.     (line  440)
  * less than:                             Comparisons.        (line   58)
  * less than or equal:                    Comparisons.        (line   66)
  * leu:                                   Comparisons.        (line   66)
  * leu and attributes:                    Expressions.        (line   83)
- * LE_EXPR:                               Unary and Binary Expressions.
-                                                              (line    6)
  * lfloorMN2:                             Standard Names.     (line 1285)
  * LIB2FUNCS_EXTRA:                       Target Fragment.    (line   11)
  * LIBCALL_VALUE:                         Scalar Return.      (line   56)
  * libgcc.a:                              Library Calls.      (line    6)
  * LIBGCC2_CFLAGS:                        Target Fragment.    (line    8)
  * LIBGCC2_GNU_PREFIX:                    Type Layout.        (line  102)
  * LIBGCC2_UNWIND_ATTRIBUTE:              Misc.               (line 1063)
- * LIBGCC_SPEC:                           Driver.             (line  115)
  * library subroutine names:              Library Calls.      (line    6)
  * LIBRARY_PATH_ENV:                      Misc.               (line  549)
- * LIB_SPEC:                              Driver.             (line  107)
  * LIMIT_RELOAD_CLASS:                    Register Classes.   (line  296)
  * LINK_COMMAND_SPEC:                     Driver.             (line  240)
  * LINK_EH_SPEC:                          Driver.             (line  142)
--- 55827,55902 ----
  * jump_insn and /u:                      Flags.              (line   28)
  * jump_insn and /v:                      Flags.              (line   33)
  * JUMP_LABEL:                            Insns.              (line   80)
  * jump_table_data:                       Insns.              (line  166)
  * jump_table_data and /s:                Flags.              (line  162)
  * jump_table_data and /v:                Flags.              (line   33)
+ * JUMP_TABLES_IN_TEXT_SECTION:           Sections.           (line  155)
+ * jump, in call_insn:                    Flags.              (line  175)
+ * jump, in insn:                         Flags.              (line  171)
+ * jump, in mem:                          Flags.              (line   59)
+ * Jumps:                                 Jumps.              (line    6)
  * LABEL_ALIGN:                           Alignment Output.   (line   42)
  * LABEL_ALIGN_AFTER_BARRIER:             Alignment Output.   (line   21)
  * LABEL_ALT_ENTRY_P:                     Insns.              (line  146)
+ * LABEL_ALTERNATE_NAME:                  Edges.              (line  179)
  * LABEL_DECL:                            Declarations.       (line    6)
  * LABEL_KIND:                            Insns.              (line  146)
  * LABEL_NUSES:                           Insns.              (line  142)
  * LABEL_PRESERVE_P:                      Flags.              (line   48)
  * label_ref:                             Constants.          (line  213)
  * label_ref and /v:                      Flags.              (line   54)
  * LABEL_REF_NONLOCAL_P:                  Flags.              (line   54)
+ * label_ref, RTL sharing:                Sharing.            (line   36)
+ * lang_hooks.gimplify_expr:              Gimplification pass.
+                                                              (line   18)
+ * lang_hooks.parse_file:                 Parsing pass.       (line    6)
  * language-dependent trees:              Language-dependent trees.
                                                               (line    6)
  * language-independent intermediate representation: Parsing pass.
                                                               (line   13)
  * large return values:                   Aggregate Return.   (line    6)
  * LAST_STACK_REG:                        Stack Registers.    (line   30)
  * LAST_VIRTUAL_REGISTER:                 Regs and Memory.    (line   51)
  * late IPA passes:                       Late IPA passes.    (line    6)
  * lceilMN2:                              Standard Names.     (line 1290)
  * LCSSA:                                 LCSSA.              (line    6)
  * LD_FINI_SWITCH:                        Macros for Initialization.
                                                               (line   28)
  * LD_INIT_SWITCH:                        Macros for Initialization.
                                                               (line   24)
+ * LDD_SUFFIX:                            Macros for Initialization.
+                                                              (line  129)
+ * ldexpM3 instruction pattern:           Standard Names.     (line 1052)
  * le:                                    Comparisons.        (line   66)
  * le and attributes:                     Expressions.        (line   83)
+ * LE_EXPR:                               Unary and Binary Expressions.
+                                                              (line    6)
  * leaf functions:                        Leaf Functions.     (line    6)
  * leaf_function_p:                       Standard Names.     (line 2136)
  * LEAF_REG_REMAP:                        Leaf Functions.     (line   37)
+ * LEAF_REGISTERS:                        Leaf Functions.     (line   23)
  * left rotate:                           Arithmetic.         (line  201)
  * left shift:                            Arithmetic.         (line  179)
  * LEGITIMATE_PIC_OPERAND_P:              PIC.                (line   31)
  * LEGITIMIZE_RELOAD_ADDRESS:             Addressing Modes.   (line  150)
  * len_load_M instruction pattern:        Standard Names.     (line  418)
  * len_store_M instruction pattern:       Standard Names.     (line  440)
+ * length:                                GTY Options.        (line   47)
  * less than:                             Comparisons.        (line   58)
  * less than or equal:                    Comparisons.        (line   66)
  * leu:                                   Comparisons.        (line   66)
  * leu and attributes:                    Expressions.        (line   83)
  * lfloorMN2:                             Standard Names.     (line 1285)
+ * LIB_SPEC:                              Driver.             (line  107)
  * LIB2FUNCS_EXTRA:                       Target Fragment.    (line   11)
  * LIBCALL_VALUE:                         Scalar Return.      (line   56)
+ * LIBGCC_SPEC:                           Driver.             (line  115)
  * libgcc.a:                              Library Calls.      (line    6)
  * LIBGCC2_CFLAGS:                        Target Fragment.    (line    8)
  * LIBGCC2_GNU_PREFIX:                    Type Layout.        (line  102)
  * LIBGCC2_UNWIND_ATTRIBUTE:              Misc.               (line 1063)
  * library subroutine names:              Library Calls.      (line    6)
  * LIBRARY_PATH_ENV:                      Misc.               (line  549)
  * LIMIT_RELOAD_CLASS:                    Register Classes.   (line  296)
  * LINK_COMMAND_SPEC:                     Driver.             (line  240)
  * LINK_EH_SPEC:                          Driver.             (line  142)
*************** Concept Index
*** 55907,55912 ****
--- 55906,55912 ----
  * list:                                  Containers.         (line    6)
  * Liveness representation:               Liveness information.
                                                               (line    6)
+ * lo_sum:                                Arithmetic.         (line   25)
  * load address instruction:              Simple Constraints. (line  162)
  * LOAD_EXTEND_OP:                        Misc.               (line   80)
  * load_multiple instruction pattern:     Standard Names.     (line  136)
*************** Concept Index
*** 55924,55933 ****
  * log2M2 instruction pattern:            Standard Names.     (line 1176)
  * logbM2 instruction pattern:            Standard Names.     (line 1183)
  * Logical Operators:                     Logical Operators.  (line    6)
- * logical-and, bitwise:                  Arithmetic.         (line  164)
  * LOGICAL_OP_NON_SHORT_CIRCUIT:          Costs.              (line  301)
  * logM2 instruction pattern:             Standard Names.     (line 1152)
- * longjmp and automatic variables:       Interface.          (line   52)
  * LONG_ACCUM_TYPE_SIZE:                  Type Layout.        (line   92)
  * LONG_DOUBLE_TYPE_SIZE:                 Type Layout.        (line   57)
  * LONG_FRACT_TYPE_SIZE:                  Type Layout.        (line   72)
--- 55924,55932 ----
  * log2M2 instruction pattern:            Standard Names.     (line 1176)
  * logbM2 instruction pattern:            Standard Names.     (line 1183)
  * Logical Operators:                     Logical Operators.  (line    6)
  * LOGICAL_OP_NON_SHORT_CIRCUIT:          Costs.              (line  301)
+ * logical-and, bitwise:                  Arithmetic.         (line  164)
  * logM2 instruction pattern:             Standard Names.     (line 1152)
  * LONG_ACCUM_TYPE_SIZE:                  Type Layout.        (line   92)
  * LONG_DOUBLE_TYPE_SIZE:                 Type Layout.        (line   57)
  * LONG_FRACT_TYPE_SIZE:                  Type Layout.        (line   72)
*************** Concept Index
*** 55935,55971 ****
  * LONG_LONG_FRACT_TYPE_SIZE:             Type Layout.        (line   77)
  * LONG_LONG_TYPE_SIZE:                   Type Layout.        (line   32)
  * LONG_TYPE_SIZE:                        Type Layout.        (line   21)
  * Loop analysis:                         Loop representation.
                                                               (line    6)
  * Loop manipulation:                     Loop manipulation.  (line    6)
  * Loop querying:                         Loop querying.      (line    6)
  * Loop representation:                   Loop representation.
                                                               (line    6)
- * Loop-closed SSA form:                  LCSSA.              (line    6)
- * looping instruction patterns:          Looping Patterns.   (line    6)
  * LOOP_ALIGN:                            Alignment Output.   (line   29)
  * LOOP_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * lowering, language-dependent intermediate representation: Parsing pass.
                                                               (line   13)
- * lo_sum:                                Arithmetic.         (line   25)
  * lrintMN2:                              Standard Names.     (line 1275)
  * lroundMN2:                             Standard Names.     (line 1280)
- * lshiftrt:                              Arithmetic.         (line  196)
- * lshiftrt and attributes:               Expressions.        (line   83)
  * LSHIFT_EXPR:                           Unary and Binary Expressions.
                                                               (line    6)
  * lshrM3 instruction pattern:            Standard Names.     (line  970)
  * lt:                                    Comparisons.        (line   58)
  * lt and attributes:                     Expressions.        (line   83)
  * LTGT_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * lto:                                   LTO.                (line    6)
  * ltrans:                                LTO.                (line    6)
  * ltu:                                   Comparisons.        (line   58)
- * LT_EXPR:                               Unary and Binary Expressions.
-                                                              (line    6)
  * m in constraint:                       Simple Constraints. (line   17)
  * machine attributes:                    Target Attributes.  (line    6)
  * machine description macros:            Target Macros.      (line    6)
  * machine descriptions:                  Machine Desc.       (line    6)
--- 55934,55971 ----
  * LONG_LONG_FRACT_TYPE_SIZE:             Type Layout.        (line   77)
  * LONG_LONG_TYPE_SIZE:                   Type Layout.        (line   32)
  * LONG_TYPE_SIZE:                        Type Layout.        (line   21)
+ * longjmp and automatic variables:       Interface.          (line   52)
  * Loop analysis:                         Loop representation.
                                                               (line    6)
  * Loop manipulation:                     Loop manipulation.  (line    6)
  * Loop querying:                         Loop querying.      (line    6)
  * Loop representation:                   Loop representation.
                                                               (line    6)
  * LOOP_ALIGN:                            Alignment Output.   (line   29)
  * LOOP_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
+ * Loop-closed SSA form:                  LCSSA.              (line    6)
+ * looping instruction patterns:          Looping Patterns.   (line    6)
  * lowering, language-dependent intermediate representation: Parsing pass.
                                                               (line   13)
  * lrintMN2:                              Standard Names.     (line 1275)
  * lroundMN2:                             Standard Names.     (line 1280)
  * LSHIFT_EXPR:                           Unary and Binary Expressions.
                                                               (line    6)
+ * lshiftrt:                              Arithmetic.         (line  196)
+ * lshiftrt and attributes:               Expressions.        (line   83)
  * lshrM3 instruction pattern:            Standard Names.     (line  970)
  * lt:                                    Comparisons.        (line   58)
  * lt and attributes:                     Expressions.        (line   83)
+ * LT_EXPR:                               Unary and Binary Expressions.
+                                                              (line    6)
  * LTGT_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * lto:                                   LTO.                (line    6)
  * ltrans:                                LTO.                (line    6)
  * ltu:                                   Comparisons.        (line   58)
  * m in constraint:                       Simple Constraints. (line   17)
+ * MACH_DEP_SECTION_ASM_FLAG:             Sections.           (line  120)
  * machine attributes:                    Target Attributes.  (line    6)
  * machine description macros:            Target Macros.      (line    6)
  * machine descriptions:                  Machine Desc.       (line    6)
*************** Concept Index
*** 55974,56033 ****
  * machine modes:                         Machine Modes.      (line    6)
  * machine specific constraints:          Machine Constraints.
                                                               (line    6)
  * machine-independent predicates:        Machine-Independent Predicates.
                                                               (line    6)
- * machine_mode:                          Machine Modes.      (line    6)
- * MACH_DEP_SECTION_ASM_FLAG:             Sections.           (line  120)
  * macros, target description:            Target Macros.      (line    6)
  * maddMN4 instruction pattern:           Standard Names.     (line  891)
- * makefile fragment:                     Fragments.          (line    6)
- * makefile targets:                      Makefile.           (line    6)
  * MAKE_DECL_ONE_ONLY:                    Label Output.       (line  281)
  * make_safe_from:                        Expander Definitions.
                                                               (line  150)
  * MALLOC_ABI_ALIGNMENT:                  Storage Layout.     (line  195)
  * Manipulating GIMPLE statements:        Manipulating GIMPLE statements.
                                                               (line    6)
  * marking roots:                         GGC Roots.          (line    6)
- * maskloadMN instruction pattern:        Standard Names.     (line  404)
- * maskstoreMN instruction pattern:       Standard Names.     (line  411)
  * mask_fold_left_plus_M instruction pattern: Standard Names. (line  622)
  * mask_gather_loadMN instruction pattern: Standard Names.    (line  249)
  * MASK_RETURN_ADDR:                      Exception Region Output.
                                                               (line   35)
  * mask_scatter_storeMN instruction pattern: Standard Names.  (line  272)
  * Match and Simplify:                    Match and Simplify. (line    6)
- * matching constraint:                   Simple Constraints. (line  140)
- * matching operands:                     Output Template.    (line   49)
  * match_dup:                             RTL Template.       (line   73)
  * match_dup <1>:                         define_peephole2.   (line   28)
  * match_dup and attributes:              Insn Lengths.       (line   16)
  * match_operand:                         RTL Template.       (line   16)
  * match_operand and attributes:          Expressions.        (line   55)
  * match_operator:                        RTL Template.       (line   95)
- * match_op_dup:                          RTL Template.       (line  163)
- * match_parallel:                        RTL Template.       (line  172)
  * match_par_dup:                         RTL Template.       (line  219)
  * match_scratch:                         RTL Template.       (line   58)
  * match_scratch <1>:                     define_peephole2.   (line   28)
  * match_test and attributes:             Expressions.        (line   64)
  * math library:                          Soft float library routines.
                                                               (line    6)
  * math, in RTL:                          Arithmetic.         (line    6)
  * matherr:                               Library Calls.      (line   59)
! * MATH_LIBRARY:                          Misc.               (line  542)
! * maxM3 instruction pattern:             Standard Names.     (line  555)
  * MAX_BITSIZE_MODE_ANY_INT:              Machine Modes.      (line  448)
  * MAX_BITSIZE_MODE_ANY_MODE:             Machine Modes.      (line  454)
- * MAX_BITS_PER_WORD:                     Storage Layout.     (line   54)
  * MAX_CONDITIONAL_EXECUTE:               Misc.               (line  564)
  * MAX_FIXED_MODE_SIZE:                   Storage Layout.     (line  475)
  * MAX_MOVE_MAX:                          Misc.               (line  127)
  * MAX_OFILE_ALIGNMENT:                   Storage Layout.     (line  233)
  * MAX_REGS_PER_ADDRESS:                  Addressing Modes.   (line   42)
  * MAX_STACK_ALIGNMENT:                   Storage Layout.     (line  227)
! * maybe_undef:                           GTY Options.        (line  166)
  * may_trap_p, tree_could_trap_p:         Edges.              (line  114)
  * mcount:                                Profiling.          (line   12)
  * MD_EXEC_PREFIX:                        Driver.             (line  271)
  * MD_FALLBACK_FRAME_STATE_FOR:           Exception Handling. (line   93)
--- 55974,56032 ----
  * machine modes:                         Machine Modes.      (line    6)
  * machine specific constraints:          Machine Constraints.
                                                               (line    6)
+ * machine_mode:                          Machine Modes.      (line    6)
  * machine-independent predicates:        Machine-Independent Predicates.
                                                               (line    6)
  * macros, target description:            Target Macros.      (line    6)
  * maddMN4 instruction pattern:           Standard Names.     (line  891)
  * MAKE_DECL_ONE_ONLY:                    Label Output.       (line  281)
  * make_safe_from:                        Expander Definitions.
                                                               (line  150)
+ * makefile fragment:                     Fragments.          (line    6)
+ * makefile targets:                      Makefile.           (line    6)
  * MALLOC_ABI_ALIGNMENT:                  Storage Layout.     (line  195)
  * Manipulating GIMPLE statements:        Manipulating GIMPLE statements.
                                                               (line    6)
  * marking roots:                         GGC Roots.          (line    6)
  * mask_fold_left_plus_M instruction pattern: Standard Names. (line  622)
  * mask_gather_loadMN instruction pattern: Standard Names.    (line  249)
  * MASK_RETURN_ADDR:                      Exception Region Output.
                                                               (line   35)
  * mask_scatter_storeMN instruction pattern: Standard Names.  (line  272)
+ * maskloadMN instruction pattern:        Standard Names.     (line  404)
+ * maskstoreMN instruction pattern:       Standard Names.     (line  411)
  * Match and Simplify:                    Match and Simplify. (line    6)
  * match_dup:                             RTL Template.       (line   73)
  * match_dup <1>:                         define_peephole2.   (line   28)
  * match_dup and attributes:              Insn Lengths.       (line   16)
+ * match_op_dup:                          RTL Template.       (line  163)
  * match_operand:                         RTL Template.       (line   16)
  * match_operand and attributes:          Expressions.        (line   55)
  * match_operator:                        RTL Template.       (line   95)
  * match_par_dup:                         RTL Template.       (line  219)
+ * match_parallel:                        RTL Template.       (line  172)
  * match_scratch:                         RTL Template.       (line   58)
  * match_scratch <1>:                     define_peephole2.   (line   28)
  * match_test and attributes:             Expressions.        (line   64)
+ * matching constraint:                   Simple Constraints. (line  140)
+ * matching operands:                     Output Template.    (line   49)
  * math library:                          Soft float library routines.
                                                               (line    6)
+ * MATH_LIBRARY:                          Misc.               (line  542)
  * math, in RTL:                          Arithmetic.         (line    6)
  * matherr:                               Library Calls.      (line   59)
! * MAX_BITS_PER_WORD:                     Storage Layout.     (line   54)
  * MAX_BITSIZE_MODE_ANY_INT:              Machine Modes.      (line  448)
  * MAX_BITSIZE_MODE_ANY_MODE:             Machine Modes.      (line  454)
  * MAX_CONDITIONAL_EXECUTE:               Misc.               (line  564)
  * MAX_FIXED_MODE_SIZE:                   Storage Layout.     (line  475)
  * MAX_MOVE_MAX:                          Misc.               (line  127)
  * MAX_OFILE_ALIGNMENT:                   Storage Layout.     (line  233)
  * MAX_REGS_PER_ADDRESS:                  Addressing Modes.   (line   42)
  * MAX_STACK_ALIGNMENT:                   Storage Layout.     (line  227)
! * maxM3 instruction pattern:             Standard Names.     (line  555)
  * may_trap_p, tree_could_trap_p:         Edges.              (line  114)
+ * maybe_undef:                           GTY Options.        (line  166)
  * mcount:                                Profiling.          (line   12)
  * MD_EXEC_PREFIX:                        Driver.             (line  271)
  * MD_FALLBACK_FRAME_STATE_FOR:           Exception Handling. (line   93)
*************** Concept Index
*** 56040,56054 ****
  * mem and /j:                            Flags.              (line   59)
  * mem and /u:                            Flags.              (line   78)
  * mem and /v:                            Flags.              (line   65)
- * mem, RTL sharing:                      Sharing.            (line   41)
- * memory model:                          Memory model.       (line    6)
- * memory reference, nonoffsettable:      Simple Constraints. (line  254)
- * memory references in constraints:      Simple Constraints. (line   17)
- * memory_barrier instruction pattern:    Standard Names.     (line 2520)
- * memory_blockage instruction pattern:   Standard Names.     (line 2511)
- * MEMORY_MOVE_COST:                      Costs.              (line   53)
- * memory_operand:                        Machine-Independent Predicates.
-                                                              (line   57)
  * MEM_ADDR_SPACE:                        Special Accessors.  (line   48)
  * MEM_ALIAS_SET:                         Special Accessors.  (line    9)
  * MEM_ALIGN:                             Special Accessors.  (line   45)
--- 56039,56044 ----
*************** Concept Index
*** 56064,56080 ****
  * MEM_SIZE_KNOWN_P:                      Special Accessors.  (line   35)
  * mem_thread_fence instruction pattern:  Standard Names.     (line 2829)
  * MEM_VOLATILE_P:                        Flags.              (line   65)
  * METHOD_TYPE:                           Types.              (line    6)
  * MINIMUM_ALIGNMENT:                     Storage Layout.     (line  343)
  * MINIMUM_ATOMIC_ALIGNMENT:              Storage Layout.     (line  203)
  * minM3 instruction pattern:             Standard Names.     (line  555)
  * minus:                                 Arithmetic.         (line   38)
  * minus and attributes:                  Expressions.        (line   83)
- * minus, canonicalization of:            Insn Canonicalizations.
-                                                              (line   27)
  * MINUS_EXPR:                            Unary and Binary Expressions.
                                                               (line    6)
! * MIN_UNITS_PER_WORD:                    Storage Layout.     (line   64)
  * MIPS coprocessor-definition macros:    MIPS Coprocessors.  (line    6)
  * miscellaneous register hooks:          Miscellaneous Register Hooks.
                                                               (line    6)
--- 56054,56079 ----
  * MEM_SIZE_KNOWN_P:                      Special Accessors.  (line   35)
  * mem_thread_fence instruction pattern:  Standard Names.     (line 2829)
  * MEM_VOLATILE_P:                        Flags.              (line   65)
+ * mem, RTL sharing:                      Sharing.            (line   41)
+ * memory model:                          Memory model.       (line    6)
+ * memory reference, nonoffsettable:      Simple Constraints. (line  254)
+ * memory references in constraints:      Simple Constraints. (line   17)
+ * memory_barrier instruction pattern:    Standard Names.     (line 2520)
+ * memory_blockage instruction pattern:   Standard Names.     (line 2511)
+ * MEMORY_MOVE_COST:                      Costs.              (line   53)
+ * memory_operand:                        Machine-Independent Predicates.
+                                                              (line   57)
  * METHOD_TYPE:                           Types.              (line    6)
+ * MIN_UNITS_PER_WORD:                    Storage Layout.     (line   64)
  * MINIMUM_ALIGNMENT:                     Storage Layout.     (line  343)
  * MINIMUM_ATOMIC_ALIGNMENT:              Storage Layout.     (line  203)
  * minM3 instruction pattern:             Standard Names.     (line  555)
  * minus:                                 Arithmetic.         (line   38)
  * minus and attributes:                  Expressions.        (line   83)
  * MINUS_EXPR:                            Unary and Binary Expressions.
                                                               (line    6)
! * minus, canonicalization of:            Insn Canonicalizations.
!                                                              (line   27)
  * MIPS coprocessor-definition macros:    MIPS Coprocessors.  (line    6)
  * miscellaneous register hooks:          Miscellaneous Register Hooks.
                                                               (line    6)
*************** Concept Index
*** 56124,56129 ****
--- 56123,56132 ----
  * mulsidi3 instruction pattern:          Standard Names.     (line  868)
  * mult:                                  Arithmetic.         (line   92)
  * mult and attributes:                   Expressions.        (line   83)
+ * MULT_EXPR:                             Unary and Binary Expressions.
+                                                              (line    6)
+ * MULT_HIGHPART_EXPR:                    Unary and Binary Expressions.
+                                                              (line    6)
  * mult, canonicalization of:             Insn Canonicalizations.
                                                               (line   27)
  * mult, canonicalization of <1>:         Insn Canonicalizations.
*************** Concept Index
*** 56144,56166 ****
  * multiplication high part:              Arithmetic.         (line  111)
  * multiplication with signed saturation: Arithmetic.         (line   92)
  * multiplication with unsigned saturation: Arithmetic.       (line   92)
- * MULT_EXPR:                             Unary and Binary Expressions.
-                                                              (line    6)
- * MULT_HIGHPART_EXPR:                    Unary and Binary Expressions.
-                                                              (line    6)
  * mulvM4 instruction pattern:            Standard Names.     (line  510)
  * n in constraint:                       Simple Constraints. (line   73)
  * name:                                  Identifiers.        (line    6)
  * named address spaces:                  Named Address Spaces.
                                                               (line    6)
  * named patterns and conditions:         Patterns.           (line   61)
  * names, pattern:                        Standard Names.     (line    6)
- * namespace, scope:                      Namespaces.         (line    6)
  * NAMESPACE_DECL:                        Declarations.       (line    6)
  * NAMESPACE_DECL <1>:                    Namespaces.         (line    6)
  * NATIVE_SYSTEM_HEADER_COMPONENT:        Driver.             (line  326)
  * ne:                                    Comparisons.        (line   46)
  * ne and attributes:                     Expressions.        (line   83)
  * nearbyintM2 instruction pattern:       Standard Names.     (line 1259)
  * neg:                                   Arithmetic.         (line   81)
  * neg and attributes:                    Expressions.        (line   83)
--- 56147,56168 ----
  * multiplication high part:              Arithmetic.         (line  111)
  * multiplication with signed saturation: Arithmetic.         (line   92)
  * multiplication with unsigned saturation: Arithmetic.       (line   92)
  * mulvM4 instruction pattern:            Standard Names.     (line  510)
  * n in constraint:                       Simple Constraints. (line   73)
+ * N_REG_CLASSES:                         Register Classes.   (line   81)
  * name:                                  Identifiers.        (line    6)
  * named address spaces:                  Named Address Spaces.
                                                               (line    6)
  * named patterns and conditions:         Patterns.           (line   61)
  * names, pattern:                        Standard Names.     (line    6)
  * NAMESPACE_DECL:                        Declarations.       (line    6)
  * NAMESPACE_DECL <1>:                    Namespaces.         (line    6)
+ * namespace, scope:                      Namespaces.         (line    6)
  * NATIVE_SYSTEM_HEADER_COMPONENT:        Driver.             (line  326)
  * ne:                                    Comparisons.        (line   46)
  * ne and attributes:                     Expressions.        (line   83)
+ * NE_EXPR:                               Unary and Binary Expressions.
+                                                              (line    6)
  * nearbyintM2 instruction pattern:       Standard Names.     (line 1259)
  * neg:                                   Arithmetic.         (line   81)
  * neg and attributes:                    Expressions.        (line   83)
*************** Concept Index
*** 56179,56189 ****
  * next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks.   (line   25)
  * NEXT_INSN:                             Insns.              (line   30)
  * NEXT_OBJC_RUNTIME:                     Library Calls.      (line   89)
- * NE_EXPR:                               Unary and Binary Expressions.
-                                                              (line    6)
  * nil:                                   RTL Objects.        (line   73)
  * NM_FLAGS:                              Macros for Initialization.
                                                               (line  118)
  * nondeterministic finite state automaton: Processor pipeline description.
                                                               (line  304)
  * nonimmediate_operand:                  Machine-Independent Predicates.
--- 56181,56196 ----
  * next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks.   (line   25)
  * NEXT_INSN:                             Insns.              (line   30)
  * NEXT_OBJC_RUNTIME:                     Library Calls.      (line   89)
  * nil:                                   RTL Objects.        (line   73)
  * NM_FLAGS:                              Macros for Initialization.
                                                               (line  118)
+ * NO_DOLLAR_IN_LABEL:                    Label Output.       (line   64)
+ * NO_DOT_IN_LABEL:                       Label Output.       (line   70)
+ * NO_FUNCTION_CSE:                       Costs.              (line  296)
+ * NO_PROFILE_COUNTERS:                   Profiling.          (line   27)
+ * NO_REGS:                               Register Classes.   (line   17)
+ * NON_LVALUE_EXPR:                       Unary and Binary Expressions.
+                                                              (line    6)
  * nondeterministic finite state automaton: Processor pipeline description.
                                                               (line  304)
  * nonimmediate_operand:                  Machine-Independent Predicates.
*************** Concept Index
*** 56195,56202 ****
  * nonmemory_operand:                     Machine-Independent Predicates.
                                                               (line   96)
  * nonoffsettable memory reference:       Simple Constraints. (line  254)
- * NON_LVALUE_EXPR:                       Unary and Binary Expressions.
-                                                              (line    6)
  * nop instruction pattern:               Standard Names.     (line 2169)
  * NOP_EXPR:                              Unary and Binary Expressions.
                                                               (line    6)
--- 56202,56207 ----
*************** Concept Index
*** 56225,56242 ****
  * NOTE_SOURCE_FILE:                      Insns.              (line  183)
  * NOTE_VAR_LOCATION:                     Insns.              (line  225)
  * notMODEcc instruction pattern:         Standard Names.     (line 1990)
- * NO_DOLLAR_IN_LABEL:                    Label Output.       (line   64)
- * NO_DOT_IN_LABEL:                       Label Output.       (line   70)
- * NO_FUNCTION_CSE:                       Costs.              (line  296)
- * NO_PROFILE_COUNTERS:                   Profiling.          (line   27)
- * NO_REGS:                               Register Classes.   (line   17)
- * Number of iterations analysis:         Number of iterations.
-                                                              (line    6)
  * NUM_MACHINE_MODES:                     Machine Modes.      (line  387)
  * NUM_MODES_FOR_MODE_SWITCHING:          Mode Switching.     (line   30)
  * NUM_POLY_INT_COEFFS:                   Overview of poly_int.
                                                               (line   24)
! * N_REG_CLASSES:                         Register Classes.   (line   81)
  * o in constraint:                       Simple Constraints. (line   23)
  * OACC_CACHE:                            OpenACC.            (line    6)
  * OACC_DATA:                             OpenACC.            (line    6)
--- 56230,56241 ----
  * NOTE_SOURCE_FILE:                      Insns.              (line  183)
  * NOTE_VAR_LOCATION:                     Insns.              (line  225)
  * notMODEcc instruction pattern:         Standard Names.     (line 1990)
  * NUM_MACHINE_MODES:                     Machine Modes.      (line  387)
  * NUM_MODES_FOR_MODE_SWITCHING:          Mode Switching.     (line   30)
  * NUM_POLY_INT_COEFFS:                   Overview of poly_int.
                                                               (line   24)
! * Number of iterations analysis:         Number of iterations.
!                                                              (line    6)
  * o in constraint:                       Simple Constraints. (line   23)
  * OACC_CACHE:                            OpenACC.            (line    6)
  * OACC_DATA:                             OpenACC.            (line    6)
*************** Concept Index
*** 56253,56260 ****
  * OBJC_JBLEN:                            Misc.               (line 1058)
  * OBJECT_FORMAT_COFF:                    Macros for Initialization.
                                                               (line  104)
- * offsettable address:                   Simple Constraints. (line   23)
  * OFFSET_TYPE:                           Types.              (line    6)
  * OImode:                                Machine Modes.      (line   51)
  * OMP_ATOMIC:                            OpenMP.             (line    6)
  * OMP_CLAUSE:                            OpenMP.             (line    6)
--- 56252,56259 ----
  * OBJC_JBLEN:                            Misc.               (line 1058)
  * OBJECT_FORMAT_COFF:                    Macros for Initialization.
                                                               (line  104)
  * OFFSET_TYPE:                           Types.              (line    6)
+ * offsettable address:                   Simple Constraints. (line   23)
  * OImode:                                Machine Modes.      (line   51)
  * OMP_ATOMIC:                            OpenMP.             (line    6)
  * OMP_CLAUSE:                            OpenMP.             (line    6)
*************** Concept Index
*** 56284,56289 ****
--- 56283,56289 ----
  * operands:                              SSA Operands.       (line    6)
  * operands <1>:                          Patterns.           (line   67)
  * operator predicates:                   Predicates.         (line    6)
+ * opt_mode:                              Machine Modes.      (line  326)
  * optc-gen.awk:                          Options.            (line    6)
  * OPTGROUP_ALL:                          Optimization groups.
                                                               (line   28)
*************** Concept Index
*** 56307,56318 ****
  * Optimization infrastructure for GIMPLE: Tree SSA.          (line    6)
  * OPTIMIZE_MODE_SWITCHING:               Mode Switching.     (line    8)
  * option specification files:            Options.            (line    6)
  * optional hardware or system features:  Run-time Target.    (line   59)
  * options, directory search:             Including Patterns. (line   46)
  * options, guidelines for:               Guidelines for Options.
                                                               (line    6)
- * OPTION_DEFAULT_SPECS:                  Driver.             (line   25)
- * opt_mode:                              Machine Modes.      (line  326)
  * order of register allocation:          Allocation Order.   (line    6)
  * ordered_comparison_operator:           Machine-Independent Predicates.
                                                               (line  115)
--- 56307,56317 ----
  * Optimization infrastructure for GIMPLE: Tree SSA.          (line    6)
  * OPTIMIZE_MODE_SWITCHING:               Mode Switching.     (line    8)
  * option specification files:            Options.            (line    6)
+ * OPTION_DEFAULT_SPECS:                  Driver.             (line   25)
  * optional hardware or system features:  Run-time Target.    (line   59)
  * options, directory search:             Including Patterns. (line   46)
  * options, guidelines for:               Guidelines for Options.
                                                               (line    6)
  * order of register allocation:          Allocation Order.   (line    6)
  * ordered_comparison_operator:           Machine-Independent Predicates.
                                                               (line  115)
*************** Concept Index
*** 56322,56329 ****
  * ORIGINAL_REGNO:                        Special Accessors.  (line   53)
  * other register constraints:            Simple Constraints. (line  171)
  * outgoing_args_size:                    Stack Arguments.    (line   51)
- * OUTGOING_REGNO:                        Register Basics.    (line  136)
  * OUTGOING_REG_PARM_STACK_SPACE:         Stack Arguments.    (line   82)
  * output of assembler code:              File Framework.     (line    6)
  * output statements:                     Output Statement.   (line    6)
  * output templates:                      Output Template.    (line    6)
--- 56321,56328 ----
  * ORIGINAL_REGNO:                        Special Accessors.  (line   53)
  * other register constraints:            Simple Constraints. (line  171)
  * outgoing_args_size:                    Stack Arguments.    (line   51)
  * OUTGOING_REG_PARM_STACK_SPACE:         Stack Arguments.    (line   82)
+ * OUTGOING_REGNO:                        Register Basics.    (line  136)
  * output of assembler code:              File Framework.     (line    6)
  * output statements:                     Output Statement.   (line    6)
  * output templates:                      Output Template.    (line    6)
*************** Concept Index
*** 56336,56342 ****
  * OVL_NEXT:                              Functions for C++.  (line    6)
  * p in constraint:                       Simple Constraints. (line  162)
  * PAD_VARARGS_DOWN:                      Register Arguments. (line  224)
! * parallel:                              Side Effects.       (line  203)
  * parameters, c++ abi:                   C++ ABI.            (line    6)
  * parameters, d abi:                     D Language and ABI. (line    6)
  * parameters, miscellaneous:             Misc.               (line    6)
--- 56335,56341 ----
  * OVL_NEXT:                              Functions for C++.  (line    6)
  * p in constraint:                       Simple Constraints. (line  162)
  * PAD_VARARGS_DOWN:                      Register Arguments. (line  224)
! * parallel:                              Side Effects.       (line  202)
  * parameters, c++ abi:                   C++ ABI.            (line    6)
  * parameters, d abi:                     D Language and ABI. (line    6)
  * parameters, miscellaneous:             Misc.               (line    6)
*************** Concept Index
*** 56348,56356 ****
  * PARSE_LDD_OUTPUT:                      Macros for Initialization.
                                                               (line  133)
  * pass dumps:                            Passes.             (line    6)
  * passes and files of the compiler:      Passes.             (line    6)
  * passing arguments:                     Interface.          (line   36)
- * pass_duplicate_computed_gotos:         Edges.              (line  161)
  * PATH_SEPARATOR:                        Filesystem.         (line   31)
  * PATTERN:                               Insns.              (line  307)
  * pattern conditions:                    Patterns.           (line   55)
--- 56347,56355 ----
  * PARSE_LDD_OUTPUT:                      Macros for Initialization.
                                                               (line  133)
  * pass dumps:                            Passes.             (line    6)
+ * pass_duplicate_computed_gotos:         Edges.              (line  161)
  * passes and files of the compiler:      Passes.             (line    6)
  * passing arguments:                     Interface.          (line   36)
  * PATH_SEPARATOR:                        Filesystem.         (line   31)
  * PATTERN:                               Insns.              (line  307)
  * pattern conditions:                    Patterns.           (line   55)
*************** Concept Index
*** 56359,56371 ****
  * patterns:                              Patterns.           (line    6)
  * pc:                                    Regs and Memory.    (line  347)
  * pc and attributes:                     Insn Lengths.       (line   20)
  * pc, RTL sharing:                       Sharing.            (line   28)
  * PCC_BITFIELD_TYPE_MATTERS:             Storage Layout.     (line  369)
  * PCC_STATIC_STRUCT_RETURN:              Aggregate Return.   (line   64)
- * PC_REGNUM:                             Register Basics.    (line  150)
- * pc_rtx:                                Regs and Memory.    (line  352)
  * PDImode:                               Machine Modes.      (line   40)
! * peephole optimization, RTL representation: Side Effects.   (line  237)
  * peephole optimizer definitions:        Peephole Definitions.
                                                               (line    6)
  * per-function data:                     Per-Function Data.  (line    6)
--- 56358,56370 ----
  * patterns:                              Patterns.           (line    6)
  * pc:                                    Regs and Memory.    (line  347)
  * pc and attributes:                     Insn Lengths.       (line   20)
+ * PC_REGNUM:                             Register Basics.    (line  150)
+ * pc_rtx:                                Regs and Memory.    (line  352)
  * pc, RTL sharing:                       Sharing.            (line   28)
  * PCC_BITFIELD_TYPE_MATTERS:             Storage Layout.     (line  369)
  * PCC_STATIC_STRUCT_RETURN:              Aggregate Return.   (line   64)
  * PDImode:                               Machine Modes.      (line   40)
! * peephole optimization, RTL representation: Side Effects.   (line  236)
  * peephole optimizer definitions:        Peephole Definitions.
                                                               (line    6)
  * per-function data:                     Per-Function Data.  (line    6)
*************** Concept Index
*** 56373,56380 ****
  * PHI nodes:                             SSA.                (line   31)
  * phi nodes, RTL SSA:                    RTL SSA Phi Nodes.  (line    6)
  * PIC:                                   PIC.                (line    6)
- * PIC_OFFSET_TABLE_REGNUM:               PIC.                (line   15)
  * PIC_OFFSET_TABLE_REG_CALL_CLOBBERED:   PIC.                (line   25)
  * pipeline hazard recognizer:            Processor pipeline description.
                                                               (line    6)
  * pipeline hazard recognizer <1>:        Processor pipeline description.
--- 56372,56379 ----
  * PHI nodes:                             SSA.                (line   31)
  * phi nodes, RTL SSA:                    RTL SSA Phi Nodes.  (line    6)
  * PIC:                                   PIC.                (line    6)
  * PIC_OFFSET_TABLE_REG_CALL_CLOBBERED:   PIC.                (line   25)
+ * PIC_OFFSET_TABLE_REGNUM:               PIC.                (line   15)
  * pipeline hazard recognizer:            Processor pipeline description.
                                                               (line    6)
  * pipeline hazard recognizer <1>:        Processor pipeline description.
*************** Concept Index
*** 56382,56404 ****
  * Plugins:                               Plugins.            (line    6)
  * plus:                                  Arithmetic.         (line   14)
  * plus and attributes:                   Expressions.        (line   83)
- * plus, canonicalization of:             Insn Canonicalizations.
-                                                              (line   27)
  * PLUS_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * Pmode:                                 Misc.               (line  365)
  * pmode_register_operand:                Machine-Independent Predicates.
                                                               (line   34)
  * pointer:                               Types.              (line    6)
- * POINTERS_EXTEND_UNSIGNED:              Storage Layout.     (line   76)
  * POINTER_DIFF_EXPR:                     Unary and Binary Expressions.
                                                               (line    6)
  * POINTER_PLUS_EXPR:                     Unary and Binary Expressions.
                                                               (line    6)
  * POINTER_SIZE:                          Storage Layout.     (line   70)
  * POINTER_TYPE:                          Types.              (line    6)
! * polynomial integers:                   poly_int.           (line    6)
  * poly_int:                              poly_int.           (line    6)
  * poly_int, invariant range:             Overview of poly_int.
                                                               (line   31)
  * poly_int, main typedefs:               Overview of poly_int.
--- 56381,56404 ----
  * Plugins:                               Plugins.            (line    6)
  * plus:                                  Arithmetic.         (line   14)
  * plus and attributes:                   Expressions.        (line   83)
  * PLUS_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
+ * plus, canonicalization of:             Insn Canonicalizations.
+                                                              (line   27)
  * Pmode:                                 Misc.               (line  365)
  * pmode_register_operand:                Machine-Independent Predicates.
                                                               (line   34)
  * pointer:                               Types.              (line    6)
  * POINTER_DIFF_EXPR:                     Unary and Binary Expressions.
                                                               (line    6)
  * POINTER_PLUS_EXPR:                     Unary and Binary Expressions.
                                                               (line    6)
  * POINTER_SIZE:                          Storage Layout.     (line   70)
  * POINTER_TYPE:                          Types.              (line    6)
! * POINTERS_EXTEND_UNSIGNED:              Storage Layout.     (line   76)
  * poly_int:                              poly_int.           (line    6)
+ * POLY_INT_CST:                          Constant expressions.
+                                                              (line    6)
  * poly_int, invariant range:             Overview of poly_int.
                                                               (line   31)
  * poly_int, main typedefs:               Overview of poly_int.
*************** Concept Index
*** 56411,56438 ****
                                                               (line   32)
  * poly_int, use in target-specific code: Consequences of using poly_int.
                                                               (line   40)
! * POLY_INT_CST:                          Constant expressions.
!                                                              (line    6)
  * popcount:                              Arithmetic.         (line  244)
  * popcountM2 instruction pattern:        Standard Names.     (line 1538)
  * pops_args:                             Function Entry.     (line  111)
- * pop_operand:                           Machine-Independent Predicates.
-                                                              (line   87)
  * portability:                           Portability.        (line    6)
  * position independent code:             PIC.                (line    6)
- * POSTDECREMENT_EXPR:                    Unary and Binary Expressions.
-                                                              (line    6)
- * POSTINCREMENT_EXPR:                    Unary and Binary Expressions.
-                                                              (line    6)
  * post_dec:                              Incdec.             (line   25)
  * post_inc:                              Incdec.             (line   30)
  * POST_LINK_SPEC:                        Driver.             (line  236)
  * post_modify:                           Incdec.             (line   33)
  * post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks.
                                                               (line   34)
  * POWI_MAX_MULTS:                        Misc.               (line  942)
  * powM3 instruction pattern:             Standard Names.     (line 1207)
  * pragma:                                Misc.               (line  422)
  * PREDECREMENT_EXPR:                     Unary and Binary Expressions.
                                                               (line    6)
  * predefined macros:                     Run-time Target.    (line    6)
--- 56411,56441 ----
                                                               (line   32)
  * poly_int, use in target-specific code: Consequences of using poly_int.
                                                               (line   40)
! * polynomial integers:                   poly_int.           (line    6)
! * pop_operand:                           Machine-Independent Predicates.
!                                                              (line   87)
  * popcount:                              Arithmetic.         (line  244)
  * popcountM2 instruction pattern:        Standard Names.     (line 1538)
  * pops_args:                             Function Entry.     (line  111)
  * portability:                           Portability.        (line    6)
  * position independent code:             PIC.                (line    6)
  * post_dec:                              Incdec.             (line   25)
  * post_inc:                              Incdec.             (line   30)
  * POST_LINK_SPEC:                        Driver.             (line  236)
  * post_modify:                           Incdec.             (line   33)
  * post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks.
                                                               (line   34)
+ * POSTDECREMENT_EXPR:                    Unary and Binary Expressions.
+                                                              (line    6)
+ * POSTINCREMENT_EXPR:                    Unary and Binary Expressions.
+                                                              (line    6)
  * POWI_MAX_MULTS:                        Misc.               (line  942)
  * powM3 instruction pattern:             Standard Names.     (line 1207)
  * pragma:                                Misc.               (line  422)
+ * pre_dec:                               Incdec.             (line    8)
+ * PRE_GCC3_DWARF_FRAME_REGISTERS:        Frame Registers.    (line  126)
+ * pre_inc:                               Incdec.             (line   22)
+ * pre_modify:                            Incdec.             (line   52)
  * PREDECREMENT_EXPR:                     Unary and Binary Expressions.
                                                               (line    6)
  * predefined macros:                     Run-time Target.    (line    6)
*************** Concept Index
*** 56445,56451 ****
  * PREFERRED_DEBUGGING_TYPE:              All Debuggers.      (line   40)
  * PREFERRED_RELOAD_CLASS:                Register Classes.   (line  249)
  * PREFERRED_STACK_BOUNDARY:              Storage Layout.     (line  169)
! * prefetch:                              Side Effects.       (line  315)
  * prefetch and /v:                       Flags.              (line   92)
  * prefetch instruction pattern:          Standard Names.     (line 2488)
  * PREFETCH_SCHEDULE_BARRIER_P:           Flags.              (line   92)
--- 56448,56454 ----
  * PREFERRED_DEBUGGING_TYPE:              All Debuggers.      (line   40)
  * PREFERRED_RELOAD_CLASS:                Register Classes.   (line  249)
  * PREFERRED_STACK_BOUNDARY:              Storage Layout.     (line  169)
! * prefetch:                              Side Effects.       (line  314)
  * prefetch and /v:                       Flags.              (line   92)
  * prefetch instruction pattern:          Standard Names.     (line 2488)
  * PREFETCH_SCHEDULE_BARRIER_P:           Flags.              (line   92)
*************** Concept Index
*** 56457,56466 ****
  * pretend_args_size:                     Function Entry.     (line  117)
  * prev_active_insn:                      define_peephole.    (line   60)
  * PREV_INSN:                             Insns.              (line   26)
- * pre_dec:                               Incdec.             (line    8)
- * PRE_GCC3_DWARF_FRAME_REGISTERS:        Frame Registers.    (line  126)
- * pre_inc:                               Incdec.             (line   22)
- * pre_modify:                            Incdec.             (line   52)
  * PRINT_OPERAND:                         Instruction Output. (line   95)
  * PRINT_OPERAND_ADDRESS:                 Instruction Output. (line  122)
  * PRINT_OPERAND_PUNCT_VALID_P:           Instruction Output. (line  115)
--- 56460,56465 ----
*************** Concept Index
*** 56491,56502 ****
  * purge_dead_edges <1>:                  Maintaining the CFG.
                                                               (line   81)
  * push address instruction:              Simple Constraints. (line  162)
- * pushM1 instruction pattern:            Standard Names.     (line  481)
  * PUSH_ARGS_REVERSED:                    Stack Arguments.    (line   28)
  * push_operand:                          Machine-Independent Predicates.
                                                               (line   80)
  * push_reload:                           Addressing Modes.   (line  176)
  * PUSH_ROUNDING:                         Stack Arguments.    (line   34)
  * PUT_CODE:                              RTL Objects.        (line   47)
  * PUT_MODE:                              Machine Modes.      (line  384)
  * PUT_REG_NOTE_KIND:                     Insns.              (line  349)
--- 56490,56501 ----
  * purge_dead_edges <1>:                  Maintaining the CFG.
                                                               (line   81)
  * push address instruction:              Simple Constraints. (line  162)
  * PUSH_ARGS_REVERSED:                    Stack Arguments.    (line   28)
  * push_operand:                          Machine-Independent Predicates.
                                                               (line   80)
  * push_reload:                           Addressing Modes.   (line  176)
  * PUSH_ROUNDING:                         Stack Arguments.    (line   34)
+ * pushM1 instruction pattern:            Standard Names.     (line  481)
  * PUT_CODE:                              RTL Objects.        (line   47)
  * PUT_MODE:                              Machine Modes.      (line  384)
  * PUT_REG_NOTE_KIND:                     Insns.              (line  349)
*************** Concept Index
*** 56517,56524 ****
                                                               (line    6)
  * READONLY_DATA_SECTION_ASM_OP:          Sections.           (line   62)
  * real operands:                         SSA Operands.       (line    6)
- * REALPART_EXPR:                         Unary and Binary Expressions.
-                                                              (line    6)
  * REAL_CST:                              Constant expressions.
                                                               (line    6)
  * REAL_LIBGCC_SPEC:                      Driver.             (line  124)
--- 56516,56521 ----
*************** Concept Index
*** 56540,56547 ****
  * REAL_VALUE_TO_TARGET_SINGLE:           Data Output.        (line  148)
  * REAL_VALUE_TYPE:                       Floating Point.     (line   25)
  * REAL_VALUE_UNSIGNED_FIX:               Floating Point.     (line   34)
! * recognizing insns:                     RTL Template.       (line    6)
  * recog_data.operand:                    Instruction Output. (line   54)
  * RECORD_TYPE:                           Types.              (line    6)
  * RECORD_TYPE <1>:                       Classes.            (line    6)
  * redirect_edge_and_branch:              Profile information.
--- 56537,56546 ----
  * REAL_VALUE_TO_TARGET_SINGLE:           Data Output.        (line  148)
  * REAL_VALUE_TYPE:                       Floating Point.     (line   25)
  * REAL_VALUE_UNSIGNED_FIX:               Floating Point.     (line   34)
! * REALPART_EXPR:                         Unary and Binary Expressions.
!                                                              (line    6)
  * recog_data.operand:                    Instruction Output. (line   54)
+ * recognizing insns:                     RTL Template.       (line    6)
  * RECORD_TYPE:                           Types.              (line    6)
  * RECORD_TYPE <1>:                       Classes.            (line    6)
  * redirect_edge_and_branch:              Profile information.
*************** Concept Index
*** 56564,56601 ****
  * reg and /f:                            Flags.              (line  102)
  * reg and /i:                            Flags.              (line   97)
  * reg and /v:                            Flags.              (line  106)
- * reg, RTL sharing:                      Sharing.            (line   17)
- * register allocation order:             Allocation Order.   (line    6)
- * register class definitions:            Register Classes.   (line    6)
- * register class preference constraints: Class Preferences.  (line    6)
- * register pairs:                        Values in Registers.
-                                                              (line   65)
- * Register Transfer Language (RTL):      RTL.                (line    6)
- * register usage:                        Registers.          (line    6)
- * registers arguments:                   Register Arguments. (line    6)
- * registers in constraints:              Simple Constraints. (line   64)
- * REGISTER_MOVE_COST:                    Costs.              (line    9)
- * REGISTER_NAMES:                        Instruction Output. (line    8)
- * register_operand:                      Machine-Independent Predicates.
-                                                              (line   29)
- * REGISTER_PREFIX:                       Instruction Output. (line  150)
- * REGISTER_TARGET_PRAGMAS:               Misc.               (line  422)
- * REGMODE_NATURAL_SIZE:                  Regs and Memory.    (line  191)
- * REGMODE_NATURAL_SIZE <1>:              Regs and Memory.    (line  273)
- * REGMODE_NATURAL_SIZE <2>:              Values in Registers.
-                                                              (line   46)
- * REGNO_MODE_CODE_OK_FOR_BASE_P:         Register Classes.   (line  172)
- * REGNO_MODE_OK_FOR_BASE_P:              Register Classes.   (line  150)
- * REGNO_MODE_OK_FOR_REG_BASE_P:          Register Classes.   (line  160)
- * REGNO_OK_FOR_BASE_P:                   Register Classes.   (line  146)
- * REGNO_OK_FOR_INDEX_P:                  Register Classes.   (line  186)
- * REGNO_REG_CLASS:                       Register Classes.   (line  105)
- * regs_ever_live:                        Function Entry.     (line   29)
- * regular expressions:                   Processor pipeline description.
-                                                              (line    6)
- * regular expressions <1>:               Processor pipeline description.
-                                                              (line  105)
- * regular IPA passes:                    Regular IPA passes. (line    6)
  * REG_ALLOC_ORDER:                       Allocation Order.   (line    8)
  * REG_BR_PRED:                           Insns.              (line  505)
  * REG_BR_PROB:                           Insns.              (line  497)
--- 56563,56568 ----
*************** Concept Index
*** 56628,56635 ****
  * reg_names:                             Register Basics.    (line  102)
  * reg_names <1>:                         Instruction Output. (line  107)
  * REG_NONNEG:                            Insns.              (line  381)
- * REG_NOTES:                             Insns.              (line  337)
  * REG_NOTE_KIND:                         Insns.              (line  349)
  * REG_OFFSET:                            Special Accessors.  (line   62)
  * REG_OK_STRICT:                         Addressing Modes.   (line   99)
  * REG_PARM_STACK_SPACE:                  Stack Arguments.    (line   61)
--- 56595,56602 ----
  * reg_names:                             Register Basics.    (line  102)
  * reg_names <1>:                         Instruction Output. (line  107)
  * REG_NONNEG:                            Insns.              (line  381)
  * REG_NOTE_KIND:                         Insns.              (line  349)
+ * REG_NOTES:                             Insns.              (line  337)
  * REG_OFFSET:                            Special Accessors.  (line   62)
  * REG_OK_STRICT:                         Addressing Modes.   (line   99)
  * REG_PARM_STACK_SPACE:                  Stack Arguments.    (line   61)
*************** Concept Index
*** 56641,56676 ****
  * REG_USERVAR_P:                         Flags.              (line  106)
  * REG_VALUE_IN_UNWIND_CONTEXT:           Frame Registers.    (line  156)
  * REG_WORDS_BIG_ENDIAN:                  Storage Layout.     (line   35)
  * relative costs:                        Costs.              (line    6)
  * RELATIVE_PREFIX_NOT_LINKDIR:           Driver.             (line  266)
- * reloading:                             RTL passes.         (line  171)
  * reload_completed:                      Standard Names.     (line 2136)
  * reload_in instruction pattern:         Standard Names.     (line   98)
  * reload_in_progress:                    Standard Names.     (line   57)
  * reload_out instruction pattern:        Standard Names.     (line   98)
  * remainder:                             Arithmetic.         (line  142)
  * remainderM3 instruction pattern:       Standard Names.     (line 1038)
  * reorder:                               GTY Options.        (line  200)
  * representation of RTL:                 RTL.                (line    6)
  * reservation delays:                    Processor pipeline description.
                                                               (line    6)
  * restore_stack_block instruction pattern: Standard Names.   (line 2252)
  * restore_stack_function instruction pattern: Standard Names.
                                                               (line 2252)
  * restore_stack_nonlocal instruction pattern: Standard Names.
                                                               (line 2252)
- * rest_of_decl_compilation:              Parsing pass.       (line   51)
- * rest_of_type_compilation:              Parsing pass.       (line   51)
  * RESULT_DECL:                           Declarations.       (line    6)
  * return:                                Side Effects.       (line   65)
  * return instruction pattern:            Standard Names.     (line 2110)
  * return values in registers:            Scalar Return.      (line    6)
- * returning aggregate values:            Aggregate Return.   (line    6)
- * returning structures and unions:       Interface.          (line   10)
- * RETURN_ADDRESS_POINTER_REGNUM:         Frame Registers.    (line   64)
  * RETURN_ADDR_IN_PREVIOUS_FRAME:         Frame Layout.       (line  127)
  * RETURN_ADDR_OFFSET:                    Exception Handling. (line   59)
  * RETURN_ADDR_RTX:                       Frame Layout.       (line  116)
  * RETURN_EXPR:                           Statements for C and C++.
                                                               (line    6)
  * RETURN_STMT:                           Statements for C and C++.
--- 56608,56673 ----
  * REG_USERVAR_P:                         Flags.              (line  106)
  * REG_VALUE_IN_UNWIND_CONTEXT:           Frame Registers.    (line  156)
  * REG_WORDS_BIG_ENDIAN:                  Storage Layout.     (line   35)
+ * reg, RTL sharing:                      Sharing.            (line   17)
+ * register allocation order:             Allocation Order.   (line    6)
+ * register class definitions:            Register Classes.   (line    6)
+ * register class preference constraints: Class Preferences.  (line    6)
+ * register pairs:                        Values in Registers.
+                                                              (line   65)
+ * Register Transfer Language (RTL):      RTL.                (line    6)
+ * register usage:                        Registers.          (line    6)
+ * REGISTER_MOVE_COST:                    Costs.              (line    9)
+ * REGISTER_NAMES:                        Instruction Output. (line    8)
+ * register_operand:                      Machine-Independent Predicates.
+                                                              (line   29)
+ * REGISTER_PREFIX:                       Instruction Output. (line  150)
+ * REGISTER_TARGET_PRAGMAS:               Misc.               (line  422)
+ * registers arguments:                   Register Arguments. (line    6)
+ * registers in constraints:              Simple Constraints. (line   64)
+ * REGMODE_NATURAL_SIZE:                  Regs and Memory.    (line  191)
+ * REGMODE_NATURAL_SIZE <1>:              Regs and Memory.    (line  273)
+ * REGMODE_NATURAL_SIZE <2>:              Values in Registers.
+                                                              (line   46)
+ * REGNO_MODE_CODE_OK_FOR_BASE_P:         Register Classes.   (line  172)
+ * REGNO_MODE_OK_FOR_BASE_P:              Register Classes.   (line  150)
+ * REGNO_MODE_OK_FOR_REG_BASE_P:          Register Classes.   (line  160)
+ * REGNO_OK_FOR_BASE_P:                   Register Classes.   (line  146)
+ * REGNO_OK_FOR_INDEX_P:                  Register Classes.   (line  186)
+ * REGNO_REG_CLASS:                       Register Classes.   (line  105)
+ * regs_ever_live:                        Function Entry.     (line   29)
+ * regular expressions:                   Processor pipeline description.
+                                                              (line    6)
+ * regular expressions <1>:               Processor pipeline description.
+                                                              (line  105)
+ * regular IPA passes:                    Regular IPA passes. (line    6)
  * relative costs:                        Costs.              (line    6)
  * RELATIVE_PREFIX_NOT_LINKDIR:           Driver.             (line  266)
  * reload_completed:                      Standard Names.     (line 2136)
  * reload_in instruction pattern:         Standard Names.     (line   98)
  * reload_in_progress:                    Standard Names.     (line   57)
  * reload_out instruction pattern:        Standard Names.     (line   98)
+ * reloading:                             RTL passes.         (line  171)
  * remainder:                             Arithmetic.         (line  142)
  * remainderM3 instruction pattern:       Standard Names.     (line 1038)
  * reorder:                               GTY Options.        (line  200)
  * representation of RTL:                 RTL.                (line    6)
  * reservation delays:                    Processor pipeline description.
                                                               (line    6)
+ * rest_of_decl_compilation:              Parsing pass.       (line   51)
+ * rest_of_type_compilation:              Parsing pass.       (line   51)
  * restore_stack_block instruction pattern: Standard Names.   (line 2252)
  * restore_stack_function instruction pattern: Standard Names.
                                                               (line 2252)
  * restore_stack_nonlocal instruction pattern: Standard Names.
                                                               (line 2252)
  * RESULT_DECL:                           Declarations.       (line    6)
  * return:                                Side Effects.       (line   65)
  * return instruction pattern:            Standard Names.     (line 2110)
  * return values in registers:            Scalar Return.      (line    6)
  * RETURN_ADDR_IN_PREVIOUS_FRAME:         Frame Layout.       (line  127)
  * RETURN_ADDR_OFFSET:                    Exception Handling. (line   59)
  * RETURN_ADDR_RTX:                       Frame Layout.       (line  116)
+ * RETURN_ADDRESS_POINTER_REGNUM:         Frame Registers.    (line   64)
  * RETURN_EXPR:                           Statements for C and C++.
                                                               (line    6)
  * RETURN_STMT:                           Statements for C and C++.
*************** Concept Index
*** 56679,56684 ****
--- 56676,56683 ----
  * return_val, in call_insn:              Flags.              (line  120)
  * return_val, in reg:                    Flags.              (line   97)
  * return_val, in symbol_ref:             Flags.              (line  216)
+ * returning aggregate values:            Aggregate Return.   (line    6)
+ * returning structures and unions:       Interface.          (line   10)
  * reverse postorder:                     RTL SSA Instructions.
                                                               (line    6)
  * reverse probability:                   Profile information.
*************** Concept Index
*** 56700,56711 ****
  * rotatert:                              Arithmetic.         (line  201)
  * rotlM3 instruction pattern:            Standard Names.     (line  970)
  * rotrM3 instruction pattern:            Standard Names.     (line  970)
- * roundM2 instruction pattern:           Standard Names.     (line 1240)
  * ROUND_DIV_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * ROUND_MOD_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * ROUND_TYPE_ALIGN:                      Storage Layout.     (line  466)
  * RPO:                                   RTL SSA Instructions.
                                                               (line    6)
  * RSHIFT_EXPR:                           Unary and Binary Expressions.
--- 56699,56710 ----
  * rotatert:                              Arithmetic.         (line  201)
  * rotlM3 instruction pattern:            Standard Names.     (line  970)
  * rotrM3 instruction pattern:            Standard Names.     (line  970)
  * ROUND_DIV_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * ROUND_MOD_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * ROUND_TYPE_ALIGN:                      Storage Layout.     (line  466)
+ * roundM2 instruction pattern:           Standard Names.     (line 1240)
  * RPO:                                   RTL SSA Instructions.
                                                               (line    6)
  * RSHIFT_EXPR:                           Unary and Binary Expressions.
*************** Concept Index
*** 56773,56783 ****
  * SAD_EXPR:                              Vectors.            (line    6)
  * same_type_p:                           Types.              (line   86)
  * SAmode:                                Machine Modes.      (line  150)
  * satfractMN2 instruction pattern:       Standard Names.     (line 1792)
  * satfractunsMN2 instruction pattern:    Standard Names.     (line 1805)
  * satisfies_constraint_M:                C Constraint Interface.
                                                               (line   36)
- * sat_fract:                             Conversions.        (line   90)
  * SAVE_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * save_stack_block instruction pattern:  Standard Names.     (line 2252)
--- 56772,56782 ----
  * SAD_EXPR:                              Vectors.            (line    6)
  * same_type_p:                           Types.              (line   86)
  * SAmode:                                Machine Modes.      (line  150)
+ * sat_fract:                             Conversions.        (line   90)
  * satfractMN2 instruction pattern:       Standard Names.     (line 1792)
  * satfractunsMN2 instruction pattern:    Standard Names.     (line 1805)
  * satisfies_constraint_M:                C Constraint Interface.
                                                               (line   36)
  * SAVE_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * save_stack_block instruction pattern:  Standard Names.     (line 2252)
*************** Concept Index
*** 56785,56803 ****
  * save_stack_nonlocal instruction pattern: Standard Names.   (line 2252)
  * SBSS_SECTION_ASM_OP:                   Sections.           (line   75)
  * Scalar evolutions:                     Scalar evolutions.  (line    6)
- * scalars, returned as values:           Scalar Return.      (line    6)
  * scalar_float_mode:                     Machine Modes.      (line  297)
  * scalar_int_mode:                       Machine Modes.      (line  294)
  * scalar_mode:                           Machine Modes.      (line  300)
  * scalbM3 instruction pattern:           Standard Names.     (line 1045)
  * scatter_storeMN instruction pattern:   Standard Names.     (line  255)
  * SCHED_GROUP_P:                         Flags.              (line  162)
  * SCmode:                                Machine Modes.      (line  198)
  * scratch:                               Regs and Memory.    (line  325)
  * scratch operands:                      Regs and Memory.    (line  325)
- * scratch, RTL sharing:                  Sharing.            (line   36)
  * scratch_operand:                       Machine-Independent Predicates.
                                                               (line   49)
  * SDATA_SECTION_ASM_OP:                  Sections.           (line   57)
  * sdiv_pow2M3 instruction pattern:       Standard Names.     (line  708)
  * sdiv_pow2M3 instruction pattern <1>:   Standard Names.     (line  708)
--- 56784,56802 ----
  * save_stack_nonlocal instruction pattern: Standard Names.   (line 2252)
  * SBSS_SECTION_ASM_OP:                   Sections.           (line   75)
  * Scalar evolutions:                     Scalar evolutions.  (line    6)
  * scalar_float_mode:                     Machine Modes.      (line  297)
  * scalar_int_mode:                       Machine Modes.      (line  294)
  * scalar_mode:                           Machine Modes.      (line  300)
+ * scalars, returned as values:           Scalar Return.      (line    6)
  * scalbM3 instruction pattern:           Standard Names.     (line 1045)
  * scatter_storeMN instruction pattern:   Standard Names.     (line  255)
  * SCHED_GROUP_P:                         Flags.              (line  162)
  * SCmode:                                Machine Modes.      (line  198)
  * scratch:                               Regs and Memory.    (line  325)
  * scratch operands:                      Regs and Memory.    (line  325)
  * scratch_operand:                       Machine-Independent Predicates.
                                                               (line   49)
+ * scratch, RTL sharing:                  Sharing.            (line   36)
  * SDATA_SECTION_ASM_OP:                  Sections.           (line   57)
  * sdiv_pow2M3 instruction pattern:       Standard Names.     (line  708)
  * sdiv_pow2M3 instruction pattern <1>:   Standard Names.     (line  708)
*************** Concept Index
*** 56810,56821 ****
  * SECONDARY_RELOAD_CLASS:                Register Classes.   (line  390)
  * SELECT_CC_MODE:                        MODE_CC Condition Codes.
                                                               (line    6)
! * sequence:                              Side Effects.       (line  250)
  * Sequence iterators:                    Sequence iterators. (line    6)
  * set:                                   Side Effects.       (line   15)
  * set and /f:                            Flags.              (line  135)
- * setmemM instruction pattern:           Standard Names.     (line 1650)
- * SETUP_FRAME_ADDRESSES:                 Frame Layout.       (line   94)
  * SET_ASM_OP:                            Label Output.       (line  451)
  * SET_ASM_OP <1>:                        Label Output.       (line  462)
  * set_attr:                              Tagging Insns.      (line   31)
--- 56809,56818 ----
  * SECONDARY_RELOAD_CLASS:                Register Classes.   (line  390)
  * SELECT_CC_MODE:                        MODE_CC Condition Codes.
                                                               (line    6)
! * sequence:                              Side Effects.       (line  249)
  * Sequence iterators:                    Sequence iterators. (line    6)
  * set:                                   Side Effects.       (line   15)
  * set and /f:                            Flags.              (line  135)
  * SET_ASM_OP:                            Label Output.       (line  451)
  * SET_ASM_OP <1>:                        Label Output.       (line  462)
  * set_attr:                              Tagging Insns.      (line   31)
*************** Concept Index
*** 56831,56836 ****
--- 56828,56835 ----
                                                               (line 2844)
  * SET_TYPE_STRUCTURAL_EQUALITY:          Types.              (line    6)
  * SET_TYPE_STRUCTURAL_EQUALITY <1>:      Types.              (line   81)
+ * setmemM instruction pattern:           Standard Names.     (line 1650)
+ * SETUP_FRAME_ADDRESSES:                 Frame Layout.       (line   94)
  * SFmode:                                Machine Modes.      (line   69)
  * sharing of RTL components:             Sharing.            (line    6)
  * shift:                                 Arithmetic.         (line  179)
*************** Concept Index
*** 56846,56851 ****
--- 56845,56855 ----
  * sibcall_epilogue instruction pattern:  Standard Names.     (line 2459)
  * sibling call:                          Edges.              (line  120)
  * SIBLING_CALL_P:                        Flags.              (line  175)
+ * SIG_ATOMIC_TYPE:                       Type Layout.        (line  208)
+ * sign_extend:                           Conversions.        (line   23)
+ * sign_extract:                          Bit-Fields.         (line    8)
+ * sign_extract, canonicalization of:     Insn Canonicalizations.
+                                                              (line  103)
  * signal-to-noise ratio (metaphorical usage for diagnostics): Guidelines for Diagnostics.
                                                               (line   39)
  * signbitM2 instruction pattern:         Standard Names.     (line 1190)
*************** Concept Index
*** 56854,56883 ****
  * signed maximum:                        Arithmetic.         (line  147)
  * signed minimum:                        Arithmetic.         (line  147)
  * significandM2 instruction pattern:     Standard Names.     (line 1200)
- * sign_extend:                           Conversions.        (line   23)
- * sign_extract:                          Bit-Fields.         (line    8)
- * sign_extract, canonicalization of:     Insn Canonicalizations.
-                                                              (line  103)
- * SIG_ATOMIC_TYPE:                       Type Layout.        (line  208)
  * SImode:                                Machine Modes.      (line   37)
  * simple constraints:                    Simple Constraints. (line    6)
  * simple_return:                         Side Effects.       (line   79)
  * simple_return instruction pattern:     Standard Names.     (line 2125)
  * sincosM3 instruction pattern:          Standard Names.     (line 1073)
  * sinM2 instruction pattern:             Standard Names.     (line 1067)
- * SIZETYPE:                              Type Layout.        (line  147)
  * SIZE_ASM_OP:                           Label Output.       (line   33)
  * SIZE_TYPE:                             Type Layout.        (line  131)
  * skip:                                  GTY Options.        (line   93)
  * SLOW_BYTE_ACCESS:                      Costs.              (line  117)
  * small IPA passes:                      Small IPA passes.   (line    6)
  * smax:                                  Arithmetic.         (line  147)
  * smin:                                  Arithmetic.         (line  147)
  * sms, swing, software pipelining:       RTL passes.         (line  124)
  * smulhrsM3 instruction pattern:         Standard Names.     (line  698)
  * smulhsM3 instruction pattern:          Standard Names.     (line  688)
  * smulM3_highpart instruction pattern:   Standard Names.     (line  880)
- * smul_highpart:                         Arithmetic.         (line  111)
  * soft float library:                    Soft float library routines.
                                                               (line    6)
  * source code, location information:     Guidelines for Diagnostics.
--- 56858,56882 ----
  * signed maximum:                        Arithmetic.         (line  147)
  * signed minimum:                        Arithmetic.         (line  147)
  * significandM2 instruction pattern:     Standard Names.     (line 1200)
  * SImode:                                Machine Modes.      (line   37)
  * simple constraints:                    Simple Constraints. (line    6)
  * simple_return:                         Side Effects.       (line   79)
  * simple_return instruction pattern:     Standard Names.     (line 2125)
  * sincosM3 instruction pattern:          Standard Names.     (line 1073)
  * sinM2 instruction pattern:             Standard Names.     (line 1067)
  * SIZE_ASM_OP:                           Label Output.       (line   33)
  * SIZE_TYPE:                             Type Layout.        (line  131)
+ * SIZETYPE:                              Type Layout.        (line  147)
  * skip:                                  GTY Options.        (line   93)
  * SLOW_BYTE_ACCESS:                      Costs.              (line  117)
  * small IPA passes:                      Small IPA passes.   (line    6)
  * smax:                                  Arithmetic.         (line  147)
  * smin:                                  Arithmetic.         (line  147)
  * sms, swing, software pipelining:       RTL passes.         (line  124)
+ * smul_highpart:                         Arithmetic.         (line  111)
  * smulhrsM3 instruction pattern:         Standard Names.     (line  698)
  * smulhsM3 instruction pattern:          Standard Names.     (line  688)
  * smulM3_highpart instruction pattern:   Standard Names.     (line  880)
  * soft float library:                    Soft float library routines.
                                                               (line    6)
  * source code, location information:     Guidelines for Diagnostics.
*************** Concept Index
*** 56888,56921 ****
  * SPECS:                                 Target Fragment.    (line  194)
  * speculation_barrier instruction pattern: Standard Names.   (line 2526)
  * speed of instructions:                 Costs.              (line    6)
- * splitting instructions:                Insn Splitting.     (line    6)
  * split_block:                           Maintaining the CFG.
                                                               (line   96)
  * SQmode:                                Machine Modes.      (line  114)
  * sqrt:                                  Arithmetic.         (line  212)
  * sqrtM2 instruction pattern:            Standard Names.     (line 1012)
  * square root:                           Arithmetic.         (line  212)
  * SSA:                                   SSA.                (line    6)
  * SSA, RTL form:                         RTL SSA.            (line    6)
  * ssaddM3 instruction pattern:           Standard Names.     (line  494)
  * ssadM instruction pattern:             Standard Names.     (line  672)
  * ssashlM3 instruction pattern:          Standard Names.     (line  958)
- * SSA_NAME_DEF_STMT:                     SSA.                (line  184)
- * SSA_NAME_VERSION:                      SSA.                (line  189)
  * ssdivM3 instruction pattern:           Standard Names.     (line  494)
  * ssmaddMN4 instruction pattern:         Standard Names.     (line  906)
  * ssmsubMN4 instruction pattern:         Standard Names.     (line  930)
  * ssmulM3 instruction pattern:           Standard Names.     (line  494)
  * ssnegM2 instruction pattern:           Standard Names.     (line 1002)
  * sssubM3 instruction pattern:           Standard Names.     (line  494)
- * ss_abs:                                Arithmetic.         (line  206)
- * ss_ashift:                             Arithmetic.         (line  179)
- * ss_div:                                Arithmetic.         (line  122)
- * ss_minus:                              Arithmetic.         (line   38)
- * ss_mult:                               Arithmetic.         (line   92)
- * ss_neg:                                Arithmetic.         (line   81)
- * ss_plus:                               Arithmetic.         (line   14)
- * ss_truncate:                           Conversions.        (line   43)
  * stack arguments:                       Stack Arguments.    (line    6)
  * stack frame layout:                    Frame Layout.       (line    6)
  * stack smashing protection:             Stack Smashing Protection.
--- 56887,56920 ----
  * SPECS:                                 Target Fragment.    (line  194)
  * speculation_barrier instruction pattern: Standard Names.   (line 2526)
  * speed of instructions:                 Costs.              (line    6)
  * split_block:                           Maintaining the CFG.
                                                               (line   96)
+ * splitting instructions:                Insn Splitting.     (line    6)
  * SQmode:                                Machine Modes.      (line  114)
  * sqrt:                                  Arithmetic.         (line  212)
  * sqrtM2 instruction pattern:            Standard Names.     (line 1012)
  * square root:                           Arithmetic.         (line  212)
+ * ss_abs:                                Arithmetic.         (line  206)
+ * ss_ashift:                             Arithmetic.         (line  179)
+ * ss_div:                                Arithmetic.         (line  122)
+ * ss_minus:                              Arithmetic.         (line   38)
+ * ss_mult:                               Arithmetic.         (line   92)
+ * ss_neg:                                Arithmetic.         (line   81)
+ * ss_plus:                               Arithmetic.         (line   14)
+ * ss_truncate:                           Conversions.        (line   43)
  * SSA:                                   SSA.                (line    6)
+ * SSA_NAME_DEF_STMT:                     SSA.                (line  184)
+ * SSA_NAME_VERSION:                      SSA.                (line  189)
  * SSA, RTL form:                         RTL SSA.            (line    6)
  * ssaddM3 instruction pattern:           Standard Names.     (line  494)
  * ssadM instruction pattern:             Standard Names.     (line  672)
  * ssashlM3 instruction pattern:          Standard Names.     (line  958)
  * ssdivM3 instruction pattern:           Standard Names.     (line  494)
  * ssmaddMN4 instruction pattern:         Standard Names.     (line  906)
  * ssmsubMN4 instruction pattern:         Standard Names.     (line  930)
  * ssmulM3 instruction pattern:           Standard Names.     (line  494)
  * ssnegM2 instruction pattern:           Standard Names.     (line 1002)
  * sssubM3 instruction pattern:           Standard Names.     (line  494)
  * stack arguments:                       Stack Arguments.    (line    6)
  * stack frame layout:                    Frame Layout.       (line    6)
  * stack smashing protection:             Stack Smashing Protection.
*************** Concept Index
*** 56949,56956 ****
  * stack_protect_set instruction pattern: Standard Names.     (line 2870)
  * stack_protect_test instruction pattern: Standard Names.    (line 2901)
  * STACK_PUSH_CODE:                       Frame Layout.       (line   12)
- * STACK_REGS:                            Stack Registers.    (line   19)
  * STACK_REG_COVER_CLASS:                 Stack Registers.    (line   22)
  * STACK_SAVEAREA_MODE:                   Storage Layout.     (line  482)
  * STACK_SIZE_MODE:                       Storage Layout.     (line  493)
  * STACK_SLOT_ALIGNMENT:                  Storage Layout.     (line  314)
--- 56948,56955 ----
  * stack_protect_set instruction pattern: Standard Names.     (line 2870)
  * stack_protect_test instruction pattern: Standard Names.    (line 2901)
  * STACK_PUSH_CODE:                       Frame Layout.       (line   12)
  * STACK_REG_COVER_CLASS:                 Stack Registers.    (line   22)
+ * STACK_REGS:                            Stack Registers.    (line   19)
  * STACK_SAVEAREA_MODE:                   Storage Layout.     (line  482)
  * STACK_SIZE_MODE:                       Storage Layout.     (line  493)
  * STACK_SLOT_ALIGNMENT:                  Storage Layout.     (line  314)
*************** Concept Index
*** 56998,57005 ****
  * STRING_POOL_ADDRESS_P:                 Flags.              (line  179)
  * strlenM instruction pattern:           Standard Names.     (line 1721)
  * structure value address:               Aggregate Return.   (line    6)
- * structures, returning:                 Interface.          (line   10)
  * STRUCTURE_SIZE_BOUNDARY:               Storage Layout.     (line  356)
  * subM3 instruction pattern:             Standard Names.     (line  494)
  * SUBOBJECT:                             Statements for C and C++.
                                                               (line    6)
--- 56997,57004 ----
  * STRING_POOL_ADDRESS_P:                 Flags.              (line  179)
  * strlenM instruction pattern:           Standard Names.     (line 1721)
  * structure value address:               Aggregate Return.   (line    6)
  * STRUCTURE_SIZE_BOUNDARY:               Storage Layout.     (line  356)
+ * structures, returning:                 Interface.          (line   10)
  * subM3 instruction pattern:             Standard Names.     (line  494)
  * SUBOBJECT:                             Statements for C and C++.
                                                               (line    6)
*************** Concept Index
*** 57009,57020 ****
  * subreg and /s:                         Flags.              (line  201)
  * subreg and /u:                         Flags.              (line  194)
  * subreg and /u and /v:                  Flags.              (line  184)
- * subreg, in strict_low_part:            RTL Declarations.   (line    9)
  * SUBREG_BYTE:                           Regs and Memory.    (line  316)
  * SUBREG_PROMOTED_UNSIGNED_P:            Flags.              (line  184)
  * SUBREG_PROMOTED_UNSIGNED_SET:          Flags.              (line  194)
  * SUBREG_PROMOTED_VAR_P:                 Flags.              (line  201)
  * SUBREG_REG:                            Regs and Memory.    (line  316)
  * subst iterators in .md files:          Subst Iterators.    (line    6)
  * subvM4 instruction pattern:            Standard Names.     (line  510)
  * SUCCESS_EXIT_CODE:                     Host Misc.          (line   12)
--- 57008,57019 ----
  * subreg and /s:                         Flags.              (line  201)
  * subreg and /u:                         Flags.              (line  194)
  * subreg and /u and /v:                  Flags.              (line  184)
  * SUBREG_BYTE:                           Regs and Memory.    (line  316)
  * SUBREG_PROMOTED_UNSIGNED_P:            Flags.              (line  184)
  * SUBREG_PROMOTED_UNSIGNED_SET:          Flags.              (line  194)
  * SUBREG_PROMOTED_VAR_P:                 Flags.              (line  201)
  * SUBREG_REG:                            Regs and Memory.    (line  316)
+ * subreg, in strict_low_part:            RTL Declarations.   (line    9)
  * subst iterators in .md files:          Subst Iterators.    (line    6)
  * subvM4 instruction pattern:            Standard Names.     (line  510)
  * SUCCESS_EXIT_CODE:                     Host Misc.          (line   12)
*************** Concept Index
*** 57023,57036 ****
                                                               (line   57)
  * SUPPORTS_ONE_ONLY:                     Label Output.       (line  290)
  * SUPPORTS_WEAK:                         Label Output.       (line  264)
- * SWITCHABLE_TARGET:                     Run-time Target.    (line  178)
  * SWITCH_BODY:                           Statements for C and C++.
                                                               (line    6)
  * SWITCH_COND:                           Statements for C and C++.
                                                               (line    6)
  * SWITCH_STMT:                           Statements for C and C++.
                                                               (line    6)
! * symbolic label:                        Sharing.            (line   20)
  * SYMBOL_FLAG_ANCHOR:                    Special Accessors.  (line  117)
  * SYMBOL_FLAG_EXTERNAL:                  Special Accessors.  (line   99)
  * SYMBOL_FLAG_FUNCTION:                  Special Accessors.  (line   92)
--- 57022,57034 ----
                                                               (line   57)
  * SUPPORTS_ONE_ONLY:                     Label Output.       (line  290)
  * SUPPORTS_WEAK:                         Label Output.       (line  264)
  * SWITCH_BODY:                           Statements for C and C++.
                                                               (line    6)
  * SWITCH_COND:                           Statements for C and C++.
                                                               (line    6)
  * SWITCH_STMT:                           Statements for C and C++.
                                                               (line    6)
! * SWITCHABLE_TARGET:                     Run-time Target.    (line  178)
  * SYMBOL_FLAG_ANCHOR:                    Special Accessors.  (line  117)
  * SYMBOL_FLAG_EXTERNAL:                  Special Accessors.  (line   99)
  * SYMBOL_FLAG_FUNCTION:                  Special Accessors.  (line   92)
*************** Concept Index
*** 57043,57049 ****
  * symbol_ref and /i:                     Flags.              (line  216)
  * symbol_ref and /u:                     Flags.              (line   19)
  * symbol_ref and /v:                     Flags.              (line  220)
- * symbol_ref, RTL sharing:               Sharing.            (line   20)
  * SYMBOL_REF_ANCHOR_P:                   Special Accessors.  (line  117)
  * SYMBOL_REF_BLOCK:                      Special Accessors.  (line  130)
  * SYMBOL_REF_BLOCK_OFFSET:               Special Accessors.  (line  135)
--- 57041,57046 ----
*************** Concept Index
*** 57061,57066 ****
--- 57058,57065 ----
  * SYMBOL_REF_TLS_MODEL:                  Special Accessors.  (line  108)
  * SYMBOL_REF_USED:                       Flags.              (line  211)
  * SYMBOL_REF_WEAK:                       Flags.              (line  216)
+ * symbol_ref, RTL sharing:               Sharing.            (line   20)
+ * symbolic label:                        Sharing.            (line   20)
  * sync_addMODE instruction pattern:      Standard Names.     (line 2580)
  * sync_andMODE instruction pattern:      Standard Names.     (line 2580)
  * sync_compare_and_swapMODE instruction pattern: Standard Names.
*************** Concept Index
*** 57101,57111 ****
  * target hooks:                          Target Structure.   (line    6)
  * target makefile fragment:              Target Fragment.    (line    6)
  * target specifications:                 Run-time Target.    (line    6)
- * targetm:                               Target Structure.   (line    6)
- * targets, makefile:                     Makefile.           (line    6)
  * TARGET_ABSOLUTE_BIGGEST_ALIGNMENT:     Storage Layout.     (line  190)
  * TARGET_ADDITIONAL_ALLOCNO_CLASS_P:     Register Classes.   (line  644)
- * TARGET_ADDRESS_COST:                   Costs.              (line  351)
  * TARGET_ADDR_SPACE_ADDRESS_MODE:        Named Address Spaces.
                                                               (line   42)
  * TARGET_ADDR_SPACE_CONVERT:             Named Address Spaces.
--- 57100,57107 ----
*************** Concept Index
*** 57126,57131 ****
--- 57122,57128 ----
                                                               (line   48)
  * TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID:  Named Address Spaces.
                                                               (line   83)
+ * TARGET_ADDRESS_COST:                   Costs.              (line  351)
  * TARGET_ALIGN_ANON_BITFIELD:            Storage Layout.     (line  441)
  * TARGET_ALLOCATE_INITIAL_VALUE:         Misc.               (line  822)
  * TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS:  Misc.               (line 1100)
*************** Concept Index
*** 57151,57158 ****
  * TARGET_ASM_CODE_END:                   File Framework.     (line   57)
  * TARGET_ASM_CONSTRUCTOR:                Macros for Initialization.
                                                               (line   76)
- * TARGET_ASM_DECLARE_CONSTANT_NAME:      Label Output.       (line  177)
  * TARGET_ASM_DECL_END:                   Data Output.        (line   44)
  * TARGET_ASM_DESTRUCTOR:                 Macros for Initialization.
                                                               (line   90)
  * TARGET_ASM_ELF_FLAGS_NUMERIC:          File Framework.     (line  120)
--- 57148,57155 ----
  * TARGET_ASM_CODE_END:                   File Framework.     (line   57)
  * TARGET_ASM_CONSTRUCTOR:                Macros for Initialization.
                                                               (line   76)
  * TARGET_ASM_DECL_END:                   Data Output.        (line   44)
+ * TARGET_ASM_DECLARE_CONSTANT_NAME:      Label Output.       (line  177)
  * TARGET_ASM_DESTRUCTOR:                 Macros for Initialization.
                                                               (line   90)
  * TARGET_ASM_ELF_FLAGS_NUMERIC:          File Framework.     (line  120)
*************** Concept Index
*** 57224,57239 ****
  * TARGET_BUILTIN_DECL:                   Misc.               (line  642)
  * TARGET_BUILTIN_RECIPROCAL:             Addressing Modes.   (line  269)
  * TARGET_BUILTIN_SETJMP_FRAME_VALUE:     Frame Layout.       (line  101)
! * TARGET_CALLEE_COPIES:                  Register Arguments. (line  118)
  * TARGET_CALL_ARGS:                      Varargs.            (line  126)
  * TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS: Miscellaneous Register Hooks.
                                                               (line    6)
! * TARGET_CANNOT_FORCE_CONST_MEM:         Addressing Modes.   (line  242)
! * TARGET_CANNOT_MODIFY_JUMPS_P:          Misc.               (line  886)
! * TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P:  Register Classes.   (line  615)
! * TARGET_CANONICALIZE_COMPARISON:        MODE_CC Condition Codes.
!                                                              (line   55)
! * TARGET_CANONICAL_VA_LIST_TYPE:         Register Arguments. (line  296)
  * TARGET_CAN_CHANGE_MODE_CLASS:          Register Classes.   (line  543)
  * TARGET_CAN_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory.
                                                               (line  299)
--- 57221,57232 ----
  * TARGET_BUILTIN_DECL:                   Misc.               (line  642)
  * TARGET_BUILTIN_RECIPROCAL:             Addressing Modes.   (line  269)
  * TARGET_BUILTIN_SETJMP_FRAME_VALUE:     Frame Layout.       (line  101)
! * TARGET_C_EXCESS_PRECISION:             Storage Layout.     (line  109)
! * TARGET_C_PREINCLUDE:                   Misc.               (line  397)
  * TARGET_CALL_ARGS:                      Varargs.            (line  126)
  * TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS: Miscellaneous Register Hooks.
                                                               (line    6)
! * TARGET_CALLEE_COPIES:                  Register Arguments. (line  118)
  * TARGET_CAN_CHANGE_MODE_CLASS:          Register Classes.   (line  543)
  * TARGET_CAN_CHANGE_MODE_CLASS and subreg semantics: Regs and Memory.
                                                               (line  299)
*************** Concept Index
*** 57241,57246 ****
--- 57234,57245 ----
  * TARGET_CAN_FOLLOW_JUMP:                Misc.               (line  808)
  * TARGET_CAN_INLINE_P:                   Target Attributes.  (line  173)
  * TARGET_CAN_USE_DOLOOP_P:               Misc.               (line  762)
+ * TARGET_CANNOT_FORCE_CONST_MEM:         Addressing Modes.   (line  242)
+ * TARGET_CANNOT_MODIFY_JUMPS_P:          Misc.               (line  886)
+ * TARGET_CANNOT_SUBSTITUTE_MEM_EQUIV_P:  Register Classes.   (line  615)
+ * TARGET_CANONICAL_VA_LIST_TYPE:         Register Arguments. (line  296)
+ * TARGET_CANONICALIZE_COMPARISON:        MODE_CC Condition Codes.
+                                                              (line   55)
  * TARGET_CASE_VALUES_THRESHOLD:          Misc.               (line   46)
  * TARGET_CC_MODES_COMPATIBLE:            MODE_CC Condition Codes.
                                                               (line  119)
*************** Concept Index
*** 57250,57266 ****
  * TARGET_CLASS_LIKELY_SPILLED_P:         Register Classes.   (line  499)
  * TARGET_CLASS_MAX_NREGS:                Register Classes.   (line  515)
  * TARGET_COMMUTATIVE_P:                  Misc.               (line  815)
  * TARGET_COMPARE_BY_PIECES_BRANCH_RATIO: Costs.              (line  207)
  * TARGET_COMPARE_VERSION_PRIORITY:       Misc.               (line  706)
  * TARGET_COMPATIBLE_VECTOR_TYPES_P:      Register Arguments. (line  344)
  * TARGET_COMPUTE_FRAME_LAYOUT:           Elimination.        (line   74)
  * TARGET_COMPUTE_MULTILIB:               Run-time Target.    (line  160)
  * TARGET_COMPUTE_PRESSURE_CLASSES:       Register Classes.   (line  660)
- * TARGET_COMP_TYPE_ATTRIBUTES:           Target Attributes.  (line   25)
  * TARGET_CONDITIONAL_REGISTER_USAGE:     Register Basics.    (line  102)
- * TARGET_CONSTANT_ALIGNMENT:             Storage Layout.     (line  280)
  * TARGET_CONST_ANCHOR:                   Misc.               (line 1111)
  * TARGET_CONST_NOT_OK_FOR_DEBUG_P:       Addressing Modes.   (line  238)
  * TARGET_CONVERT_TO_TYPE:                Misc.               (line 1038)
  * TARGET_CPU_CPP_BUILTINS:               Run-time Target.    (line    8)
  * TARGET_CSTORE_MODE:                    Register Classes.   (line  652)
--- 57249,57265 ----
  * TARGET_CLASS_LIKELY_SPILLED_P:         Register Classes.   (line  499)
  * TARGET_CLASS_MAX_NREGS:                Register Classes.   (line  515)
  * TARGET_COMMUTATIVE_P:                  Misc.               (line  815)
+ * TARGET_COMP_TYPE_ATTRIBUTES:           Target Attributes.  (line   25)
  * TARGET_COMPARE_BY_PIECES_BRANCH_RATIO: Costs.              (line  207)
  * TARGET_COMPARE_VERSION_PRIORITY:       Misc.               (line  706)
  * TARGET_COMPATIBLE_VECTOR_TYPES_P:      Register Arguments. (line  344)
  * TARGET_COMPUTE_FRAME_LAYOUT:           Elimination.        (line   74)
  * TARGET_COMPUTE_MULTILIB:               Run-time Target.    (line  160)
  * TARGET_COMPUTE_PRESSURE_CLASSES:       Register Classes.   (line  660)
  * TARGET_CONDITIONAL_REGISTER_USAGE:     Register Basics.    (line  102)
  * TARGET_CONST_ANCHOR:                   Misc.               (line 1111)
  * TARGET_CONST_NOT_OK_FOR_DEBUG_P:       Addressing Modes.   (line  238)
+ * TARGET_CONSTANT_ALIGNMENT:             Storage Layout.     (line  280)
  * TARGET_CONVERT_TO_TYPE:                Misc.               (line 1038)
  * TARGET_CPU_CPP_BUILTINS:               Run-time Target.    (line    8)
  * TARGET_CSTORE_MODE:                    Register Classes.   (line  652)
*************** Concept Index
*** 57280,57287 ****
  * TARGET_CXX_LIBRARY_RTTI_COMDAT:        C++ ABI.            (line   68)
  * TARGET_CXX_USE_AEABI_ATEXIT:           C++ ABI.            (line   73)
  * TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT:  C++ ABI.            (line   79)
! * TARGET_C_EXCESS_PRECISION:             Storage Layout.     (line  109)
! * TARGET_C_PREINCLUDE:                   Misc.               (line  397)
  * TARGET_DEBUG_UNWIND_INFO:              DWARF.              (line   31)
  * TARGET_DECIMAL_FLOAT_SUPPORTED_P:      Storage Layout.     (line  546)
  * TARGET_DECLSPEC:                       Target Attributes.  (line   72)
--- 57279,57293 ----
  * TARGET_CXX_LIBRARY_RTTI_COMDAT:        C++ ABI.            (line   68)
  * TARGET_CXX_USE_AEABI_ATEXIT:           C++ ABI.            (line   73)
  * TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT:  C++ ABI.            (line   79)
! * TARGET_D_CPU_VERSIONS:                 D Language and ABI. (line    6)
! * TARGET_D_HAS_STDCALL_CONVENTION:       D Language and ABI. (line   51)
! * TARGET_D_MINFO_SECTION:                D Language and ABI. (line   29)
! * TARGET_D_MINFO_SECTION_END:            D Language and ABI. (line   46)
! * TARGET_D_MINFO_SECTION_START:          D Language and ABI. (line   41)
! * TARGET_D_OS_VERSIONS:                  D Language and ABI. (line   13)
! * TARGET_D_REGISTER_CPU_TARGET_INFO:     D Language and ABI. (line   17)
! * TARGET_D_REGISTER_OS_TARGET_INFO:      D Language and ABI. (line   25)
! * TARGET_D_TEMPLATES_ALWAYS_COMDAT:      D Language and ABI. (line   59)
  * TARGET_DEBUG_UNWIND_INFO:              DWARF.              (line   31)
  * TARGET_DECIMAL_FLOAT_SUPPORTED_P:      Storage Layout.     (line  546)
  * TARGET_DECLSPEC:                       Target Attributes.  (line   72)
*************** Concept Index
*** 57305,57319 ****
  * TARGET_DWARF_POLY_INDETERMINATE_VALUE: Frame Layout.       (line  183)
  * TARGET_DWARF_REGISTER_SPAN:            Exception Region Output.
                                                               (line  104)
- * TARGET_D_CPU_VERSIONS:                 D Language and ABI. (line    6)
- * TARGET_D_HAS_STDCALL_CONVENTION:       D Language and ABI. (line   51)
- * TARGET_D_MINFO_SECTION:                D Language and ABI. (line   29)
- * TARGET_D_MINFO_SECTION_END:            D Language and ABI. (line   46)
- * TARGET_D_MINFO_SECTION_START:          D Language and ABI. (line   41)
- * TARGET_D_OS_VERSIONS:                  D Language and ABI. (line   13)
- * TARGET_D_REGISTER_CPU_TARGET_INFO:     D Language and ABI. (line   17)
- * TARGET_D_REGISTER_OS_TARGET_INFO:      D Language and ABI. (line   25)
- * TARGET_D_TEMPLATES_ALWAYS_COMDAT:      D Language and ABI. (line   59)
  * TARGET_EDOM:                           Library Calls.      (line   59)
  * TARGET_EMIT_CALL_BUILTIN___CLEAR_CACHE: Trampolines.       (line  132)
  * TARGET_EMIT_SUPPORT_TINFOS:            Storage Layout.     (line  596)
--- 57311,57316 ----
*************** Concept Index
*** 57353,57364 ****
  * target_flags:                          Run-time Target.    (line   51)
  * TARGET_FLAGS_REGNUM:                   MODE_CC Condition Codes.
                                                               (line  132)
- * TARGET_FLOATN_BUILTIN_P:               Register Arguments. (line  432)
- * TARGET_FLOATN_MODE:                    Register Arguments. (line  414)
  * TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target.
                                                               (line  197)
! * TARGET_FNTYPE_ABI:                     Register Basics.    (line   58)
  * TARGET_FN_ABI_VA_LIST:                 Register Arguments. (line  291)
  * TARGET_FOLD_BUILTIN:                   Misc.               (line  689)
  * TARGET_FORMAT_TYPES:                   Misc.               (line  980)
  * TARGET_FRAME_POINTER_REQUIRED:         Elimination.        (line    8)
--- 57350,57361 ----
  * target_flags:                          Run-time Target.    (line   51)
  * TARGET_FLAGS_REGNUM:                   MODE_CC Condition Codes.
                                                               (line  132)
  * TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target.
                                                               (line  197)
! * TARGET_FLOATN_BUILTIN_P:               Register Arguments. (line  432)
! * TARGET_FLOATN_MODE:                    Register Arguments. (line  414)
  * TARGET_FN_ABI_VA_LIST:                 Register Arguments. (line  291)
+ * TARGET_FNTYPE_ABI:                     Register Basics.    (line   58)
  * TARGET_FOLD_BUILTIN:                   Misc.               (line  689)
  * TARGET_FORMAT_TYPES:                   Misc.               (line  980)
  * TARGET_FRAME_POINTER_REQUIRED:         Elimination.        (line    8)
*************** Concept Index
*** 57374,57382 ****
  * TARGET_FUNCTION_VALUE:                 Scalar Return.      (line    9)
  * TARGET_FUNCTION_VALUE_REGNO_P:         Scalar Return.      (line   96)
  * TARGET_GCOV_TYPE_SIZE:                 Misc.               (line 1331)
- * TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc.             (line  722)
  * TARGET_GEN_CCMP_FIRST:                 Misc.               (line  905)
  * TARGET_GEN_CCMP_NEXT:                  Misc.               (line  916)
  * TARGET_GET_DRAP_RTX:                   Misc.               (line 1074)
  * TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc.             (line  715)
  * TARGET_GET_MULTILIB_ABI_NAME:          Register Basics.    (line   99)
--- 57371,57379 ----
  * TARGET_FUNCTION_VALUE:                 Scalar Return.      (line    9)
  * TARGET_FUNCTION_VALUE_REGNO_P:         Scalar Return.      (line   96)
  * TARGET_GCOV_TYPE_SIZE:                 Misc.               (line 1331)
  * TARGET_GEN_CCMP_FIRST:                 Misc.               (line  905)
  * TARGET_GEN_CCMP_NEXT:                  Misc.               (line  916)
+ * TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc.             (line  722)
  * TARGET_GET_DRAP_RTX:                   Misc.               (line 1074)
  * TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc.             (line  715)
  * TARGET_GET_MULTILIB_ABI_NAME:          Register Basics.    (line   99)
*************** Concept Index
*** 57419,57424 ****
--- 57416,57422 ----
  * TARGET_HAVE_SWITCHABLE_BSS_SECTIONS:   File Framework.     (line  155)
  * TARGET_HAVE_TLS:                       Sections.           (line  331)
  * TARGET_IFUNC_REF_LOCAL_OK:             Misc.               (line 1148)
+ * TARGET_IN_SMALL_DATA_P:                Sections.           (line  307)
  * TARGET_INIT_BUILTINS:                  Misc.               (line  626)
  * TARGET_INIT_DWARF_REG_SIZES_EXTRA:     Exception Region Output.
                                                               (line  119)
*************** Concept Index
*** 57433,57439 ****
  * TARGET_INVALID_CONVERSION:             Misc.               (line 1011)
  * TARGET_INVALID_UNARY_OP:               Misc.               (line 1017)
  * TARGET_INVALID_WITHIN_DOLOOP:          Misc.               (line  779)
- * TARGET_IN_SMALL_DATA_P:                Sections.           (line  307)
  * TARGET_IRA_CHANGE_PSEUDO_ALLOCNO_CLASS: Register Classes.  (line  570)
  * TARGET_KEEP_LEAF_WHEN_PROFILED:        Profiling.          (line   39)
  * TARGET_LEGITIMATE_ADDRESS_P:           Addressing Modes.   (line   48)
--- 57431,57436 ----
*************** Concept Index
*** 57441,57456 ****
  * TARGET_LEGITIMATE_CONSTANT_P:          Addressing Modes.   (line  213)
  * TARGET_LEGITIMIZE_ADDRESS:             Addressing Modes.   (line  129)
  * TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: Register Classes.  (line  623)
! * TARGET_LIBCALL_VALUE:                  Scalar Return.      (line   65)
  * TARGET_LIBC_HAS_FAST_FUNCTION:         Library Calls.      (line   85)
  * TARGET_LIBC_HAS_FUNCTION:              Library Calls.      (line   77)
  * TARGET_LIBFUNC_GNU_PREFIX:             Library Calls.      (line   24)
  * TARGET_LIBGCC_CMP_RETURN_MODE:         Storage Layout.     (line  502)
  * TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P: Register Arguments.
                                                               (line  406)
  * TARGET_LIBGCC_SDATA_SECTION:           Sections.           (line  136)
  * TARGET_LIBGCC_SHIFT_COUNT_MODE:        Storage Layout.     (line  508)
- * TARGET_LIB_INT_CMP_BIASED:             Library Calls.      (line   42)
  * TARGET_LOOP_UNROLL_ADJUST:             Misc.               (line  933)
  * TARGET_LOWER_LOCAL_DECL_ALIGNMENT:     Storage Layout.     (line  248)
  * TARGET_LRA_P:                          Register Classes.   (line  577)
--- 57438,57453 ----
  * TARGET_LEGITIMATE_CONSTANT_P:          Addressing Modes.   (line  213)
  * TARGET_LEGITIMIZE_ADDRESS:             Addressing Modes.   (line  129)
  * TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT: Register Classes.  (line  623)
! * TARGET_LIB_INT_CMP_BIASED:             Library Calls.      (line   42)
  * TARGET_LIBC_HAS_FAST_FUNCTION:         Library Calls.      (line   85)
  * TARGET_LIBC_HAS_FUNCTION:              Library Calls.      (line   77)
+ * TARGET_LIBCALL_VALUE:                  Scalar Return.      (line   65)
  * TARGET_LIBFUNC_GNU_PREFIX:             Library Calls.      (line   24)
  * TARGET_LIBGCC_CMP_RETURN_MODE:         Storage Layout.     (line  502)
  * TARGET_LIBGCC_FLOATING_MODE_SUPPORTED_P: Register Arguments.
                                                               (line  406)
  * TARGET_LIBGCC_SDATA_SECTION:           Sections.           (line  136)
  * TARGET_LIBGCC_SHIFT_COUNT_MODE:        Storage Layout.     (line  508)
  * TARGET_LOOP_UNROLL_ADJUST:             Misc.               (line  933)
  * TARGET_LOWER_LOCAL_DECL_ALIGNMENT:     Storage Layout.     (line  248)
  * TARGET_LRA_P:                          Register Classes.   (line  577)
*************** Concept Index
*** 57461,57466 ****
--- 57458,57465 ----
  * TARGET_MAX_ANCHOR_OFFSET:              Anchored Addresses. (line   38)
  * TARGET_MAX_NOCE_IFCVT_SEQ_COST:        Costs.              (line  397)
  * TARGET_MD_ASM_ADJUST:                  Misc.               (line  526)
+ * TARGET_MEM_CONSTRAINT:                 Addressing Modes.   (line  107)
+ * TARGET_MEM_REF:                        Storage References. (line    6)
  * TARGET_MEMBER_TYPE_FORCES_BLK:         Storage Layout.     (line  454)
  * TARGET_MEMMODEL_CHECK:                 Misc.               (line 1134)
  * TARGET_MEMORY_MOVE_COST:               Costs.              (line   79)
*************** Concept Index
*** 57472,57486 ****
  * TARGET_MEMTAG_SET_TAG:                 Misc.               (line 1312)
  * TARGET_MEMTAG_TAG_SIZE:                Misc.               (line 1278)
  * TARGET_MEMTAG_UNTAGGED_POINTER:        Misc.               (line 1325)
- * TARGET_MEM_CONSTRAINT:                 Addressing Modes.   (line  107)
- * TARGET_MEM_REF:                        Storage References. (line    6)
  * TARGET_MERGE_DECL_ATTRIBUTES:          Target Attributes.  (line   45)
  * TARGET_MERGE_TYPE_ATTRIBUTES:          Target Attributes.  (line   37)
  * TARGET_MIN_ANCHOR_OFFSET:              Anchored Addresses. (line   32)
  * TARGET_MIN_ARITHMETIC_PRECISION:       Misc.               (line   63)
  * TARGET_MIN_DIVISIONS_FOR_RECIP_MUL:    Misc.               (line  112)
- * TARGET_MODES_TIEABLE_P:                Values in Registers.
-                                                              (line  123)
  * TARGET_MODE_AFTER:                     Mode Switching.     (line   57)
  * TARGET_MODE_DEPENDENT_ADDRESS_P:       Addressing Modes.   (line  196)
  * TARGET_MODE_EMIT:                      Mode Switching.     (line   42)
--- 57471,57481 ----
*************** Concept Index
*** 57489,57505 ****
  * TARGET_MODE_NEEDED:                    Mode Switching.     (line   50)
  * TARGET_MODE_PRIORITY:                  Mode Switching.     (line   78)
  * TARGET_MODE_REP_EXTENDED:              Misc.               (line  199)
  * TARGET_MS_BITFIELD_LAYOUT_P:           Storage Layout.     (line  518)
  * TARGET_MUST_PASS_IN_STACK:             Register Arguments. (line   51)
  * TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments.
                                                               (line   43)
  * TARGET_NARROW_VOLATILE_BITFIELD:       Storage Layout.     (line  447)
  * TARGET_NEED_IPA_FN_TARGET_INFO:        Target Attributes.  (line  198)
  * TARGET_NEW_ADDRESS_PROFITABLE_P:       Costs.              (line  422)
- * TARGET_NOCE_CONVERSION_PROFITABLE_P:   Costs.              (line  416)
  * TARGET_NO_REGISTER_ALLOCATION:         DWARF.              (line   84)
  * TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P: Costs.             (line  429)
! * TARGET_N_FORMAT_TYPES:                 Misc.               (line  985)
  * TARGET_OBJC_CONSTRUCT_STRING_OBJECT:   Run-time Target.    (line   88)
  * TARGET_OBJC_DECLARE_CLASS_DEFINITION:  Run-time Target.    (line  109)
  * TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target.
--- 57484,57502 ----
  * TARGET_MODE_NEEDED:                    Mode Switching.     (line   50)
  * TARGET_MODE_PRIORITY:                  Mode Switching.     (line   78)
  * TARGET_MODE_REP_EXTENDED:              Misc.               (line  199)
+ * TARGET_MODES_TIEABLE_P:                Values in Registers.
+                                                              (line  123)
  * TARGET_MS_BITFIELD_LAYOUT_P:           Storage Layout.     (line  518)
  * TARGET_MUST_PASS_IN_STACK:             Register Arguments. (line   51)
  * TARGET_MUST_PASS_IN_STACK, and TARGET_FUNCTION_ARG: Register Arguments.
                                                               (line   43)
+ * TARGET_N_FORMAT_TYPES:                 Misc.               (line  985)
  * TARGET_NARROW_VOLATILE_BITFIELD:       Storage Layout.     (line  447)
  * TARGET_NEED_IPA_FN_TARGET_INFO:        Target Attributes.  (line  198)
  * TARGET_NEW_ADDRESS_PROFITABLE_P:       Costs.              (line  422)
  * TARGET_NO_REGISTER_ALLOCATION:         DWARF.              (line   84)
  * TARGET_NO_SPECULATION_IN_DELAY_SLOTS_P: Costs.             (line  429)
! * TARGET_NOCE_CONVERSION_PROFITABLE_P:   Costs.              (line  416)
  * TARGET_OBJC_CONSTRUCT_STRING_OBJECT:   Run-time Target.    (line   88)
  * TARGET_OBJC_DECLARE_CLASS_DEFINITION:  Run-time Target.    (line  109)
  * TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target.
*************** Concept Index
*** 57523,57532 ****
  * TARGET_OPTION_VALID_ATTRIBUTE_P:       Target Attributes.  (line  108)
  * TARGET_OS_CPP_BUILTINS:                Run-time Target.    (line   41)
  * TARGET_OVERLAP_OP_BY_PIECES_P:         Costs.              (line  200)
  * TARGET_OVERRIDES_FORMAT_ATTRIBUTES:    Misc.               (line  989)
  * TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc.            (line  996)
  * TARGET_OVERRIDES_FORMAT_INIT:          Misc.               (line 1000)
- * TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE:  Run-time Target.    (line  126)
  * TARGET_PASS_BY_REFERENCE:              Register Arguments. (line  106)
  * TARGET_PCH_VALID_P:                    PCH Target.         (line   11)
  * TARGET_POSIX_IO:                       Misc.               (line  556)
--- 57520,57529 ----
  * TARGET_OPTION_VALID_ATTRIBUTE_P:       Target Attributes.  (line  108)
  * TARGET_OS_CPP_BUILTINS:                Run-time Target.    (line   41)
  * TARGET_OVERLAP_OP_BY_PIECES_P:         Costs.              (line  200)
+ * TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE:  Run-time Target.    (line  126)
  * TARGET_OVERRIDES_FORMAT_ATTRIBUTES:    Misc.               (line  989)
  * TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc.            (line  996)
  * TARGET_OVERRIDES_FORMAT_INIT:          Misc.               (line 1000)
  * TARGET_PASS_BY_REFERENCE:              Register Arguments. (line  106)
  * TARGET_PCH_VALID_P:                    PCH Target.         (line   11)
  * TARGET_POSIX_IO:                       Misc.               (line  556)
*************** Concept Index
*** 57540,57548 ****
  * TARGET_PREPARE_PCH_SAVE:               PCH Target.         (line   34)
  * TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs.            (line  147)
  * TARGET_PROFILE_BEFORE_PROLOGUE:        Sections.           (line  315)
- * TARGET_PROMOTED_TYPE:                  Misc.               (line 1030)
  * TARGET_PROMOTE_FUNCTION_MODE:          Storage Layout.     (line  131)
  * TARGET_PROMOTE_PROTOTYPES:             Stack Arguments.    (line   10)
  * TARGET_PTRMEMFUNC_VBIT_LOCATION:       Type Layout.        (line  250)
  * TARGET_PUSH_ARGUMENT:                  Stack Arguments.    (line   17)
  * TARGET_RECORD_OFFLOAD_SYMBOL:          Misc.               (line 1176)
--- 57537,57545 ----
  * TARGET_PREPARE_PCH_SAVE:               PCH Target.         (line   34)
  * TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs.            (line  147)
  * TARGET_PROFILE_BEFORE_PROLOGUE:        Sections.           (line  315)
  * TARGET_PROMOTE_FUNCTION_MODE:          Storage Layout.     (line  131)
  * TARGET_PROMOTE_PROTOTYPES:             Stack Arguments.    (line   10)
+ * TARGET_PROMOTED_TYPE:                  Misc.               (line 1030)
  * TARGET_PTRMEMFUNC_VBIT_LOCATION:       Type Layout.        (line  250)
  * TARGET_PUSH_ARGUMENT:                  Stack Arguments.    (line   17)
  * TARGET_RECORD_OFFLOAD_SYMBOL:          Misc.               (line 1176)
*************** Concept Index
*** 57594,57601 ****
  * TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN:  Scheduling.         (line  153)
  * TARGET_SCHED_INIT_GLOBAL:              Scheduling.         (line  129)
  * TARGET_SCHED_INIT_SCHED_CONTEXT:       Scheduling.         (line  298)
- * TARGET_SCHED_ISSUE_RATE:               Scheduling.         (line   11)
  * TARGET_SCHED_IS_COSTLY_DEPENDENCE:     Scheduling.         (line  267)
  * TARGET_SCHED_MACRO_FUSION_P:           Scheduling.         (line   87)
  * TARGET_SCHED_MACRO_FUSION_PAIR_P:      Scheduling.         (line   91)
  * TARGET_SCHED_NEEDS_BLOCK_P:            Scheduling.         (line  328)
--- 57591,57598 ----
  * TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN:  Scheduling.         (line  153)
  * TARGET_SCHED_INIT_GLOBAL:              Scheduling.         (line  129)
  * TARGET_SCHED_INIT_SCHED_CONTEXT:       Scheduling.         (line  298)
  * TARGET_SCHED_IS_COSTLY_DEPENDENCE:     Scheduling.         (line  267)
+ * TARGET_SCHED_ISSUE_RATE:               Scheduling.         (line   11)
  * TARGET_SCHED_MACRO_FUSION_P:           Scheduling.         (line   87)
  * TARGET_SCHED_MACRO_FUSION_PAIR_P:      Scheduling.         (line   91)
  * TARGET_SCHED_NEEDS_BLOCK_P:            Scheduling.         (line  328)
*************** Concept Index
*** 57612,57622 ****
  * TARGET_SECONDARY_RELOAD:               Register Classes.   (line  312)
  * TARGET_SECTION_TYPE_FLAGS:             File Framework.     (line  160)
  * TARGET_SELECT_EARLY_REMAT_MODES:       Register Classes.   (line  488)
- * TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P: Misc.          (line  225)
- * TARGET_SETUP_INCOMING_VARARGS:         Varargs.            (line   71)
  * TARGET_SET_CURRENT_FUNCTION:           Misc.               (line  850)
  * TARGET_SET_DEFAULT_TYPE_ATTRIBUTES:    Target Attributes.  (line   33)
  * TARGET_SET_UP_BY_PROLOGUE:             Tail Calls.         (line   29)
  * TARGET_SHIFT_TRUNCATION_MASK:          Misc.               (line  160)
  * TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB:  Shrink-wrapping separate components.
                                                               (line   36)
--- 57609,57619 ----
  * TARGET_SECONDARY_RELOAD:               Register Classes.   (line  312)
  * TARGET_SECTION_TYPE_FLAGS:             File Framework.     (line  160)
  * TARGET_SELECT_EARLY_REMAT_MODES:       Register Classes.   (line  488)
  * TARGET_SET_CURRENT_FUNCTION:           Misc.               (line  850)
  * TARGET_SET_DEFAULT_TYPE_ATTRIBUTES:    Target Attributes.  (line   33)
  * TARGET_SET_UP_BY_PROLOGUE:             Tail Calls.         (line   29)
+ * TARGET_SETJMP_PRESERVES_NONVOLATILE_REGS_P: Misc.          (line  225)
+ * TARGET_SETUP_INCOMING_VARARGS:         Varargs.            (line   71)
  * TARGET_SHIFT_TRUNCATION_MASK:          Misc.               (line  160)
  * TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB:  Shrink-wrapping separate components.
                                                               (line   36)
*************** Concept Index
*** 57674,57687 ****
  * TARGET_UNWIND_WORD_MODE:               Storage Layout.     (line  514)
  * TARGET_UPDATE_IPA_FN_TARGET_INFO:      Target Attributes.  (line  180)
  * TARGET_UPDATE_STACK_BOUNDARY:          Misc.               (line 1070)
- * TARGET_USES_WEAK_UNWIND_INFO:          Exception Handling. (line  123)
  * TARGET_USE_ANCHORS_FOR_SYMBOL_P:       Anchored Addresses. (line   53)
  * TARGET_USE_BLOCKS_FOR_CONSTANT_P:      Addressing Modes.   (line  256)
  * TARGET_USE_BLOCKS_FOR_DECL_P:          Addressing Modes.   (line  263)
  * TARGET_USE_BY_PIECES_INFRASTRUCTURE_P: Costs.              (line  165)
  * TARGET_USE_PSEUDO_PIC_REG:             Register Arguments. (line   78)
  * TARGET_VALID_DLLIMPORT_ATTRIBUTE_P:    Target Attributes.  (line   66)
  * TARGET_VALID_POINTER_MODE:             Register Arguments. (line  307)
  * TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES: Addressing Modes.
                                                               (line  397)
  * TARGET_VECTORIZE_BUILTIN_GATHER:       Addressing Modes.   (line  485)
--- 57671,57686 ----
  * TARGET_UNWIND_WORD_MODE:               Storage Layout.     (line  514)
  * TARGET_UPDATE_IPA_FN_TARGET_INFO:      Target Attributes.  (line  180)
  * TARGET_UPDATE_STACK_BOUNDARY:          Misc.               (line 1070)
  * TARGET_USE_ANCHORS_FOR_SYMBOL_P:       Anchored Addresses. (line   53)
  * TARGET_USE_BLOCKS_FOR_CONSTANT_P:      Addressing Modes.   (line  256)
  * TARGET_USE_BLOCKS_FOR_DECL_P:          Addressing Modes.   (line  263)
  * TARGET_USE_BY_PIECES_INFRASTRUCTURE_P: Costs.              (line  165)
  * TARGET_USE_PSEUDO_PIC_REG:             Register Arguments. (line   78)
+ * TARGET_USES_WEAK_UNWIND_INFO:          Exception Handling. (line  123)
  * TARGET_VALID_DLLIMPORT_ATTRIBUTE_P:    Target Attributes.  (line   66)
  * TARGET_VALID_POINTER_MODE:             Register Arguments. (line  307)
+ * TARGET_VECTOR_ALIGNMENT:               Storage Layout.     (line  307)
+ * TARGET_VECTOR_MODE_SUPPORTED_P:        Register Arguments. (line  339)
  * TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_MODES: Addressing Modes.
                                                               (line  397)
  * TARGET_VECTORIZE_BUILTIN_GATHER:       Addressing Modes.   (line  485)
*************** Concept Index
*** 57706,57716 ****
  * TARGET_VECTORIZE_SPLIT_REDUCTION:      Addressing Modes.   (line  389)
  * TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes.
                                                               (line  372)
  * TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes.
                                                               (line  318)
- * TARGET_VECTORIZE_VEC_PERM_CONST:       Addressing Modes.   (line  324)
- * TARGET_VECTOR_ALIGNMENT:               Storage Layout.     (line  307)
- * TARGET_VECTOR_MODE_SUPPORTED_P:        Register Arguments. (line  339)
  * TARGET_VERIFY_TYPE_CONTEXT:            Misc.               (line 1045)
  * TARGET_VTABLE_DATA_ENTRY_DISTANCE:     Type Layout.        (line  303)
  * TARGET_VTABLE_ENTRY_ALIGN:             Type Layout.        (line  297)
--- 57705,57713 ----
  * TARGET_VECTORIZE_SPLIT_REDUCTION:      Addressing Modes.   (line  389)
  * TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes.
                                                               (line  372)
+ * TARGET_VECTORIZE_VEC_PERM_CONST:       Addressing Modes.   (line  324)
  * TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes.
                                                               (line  318)
  * TARGET_VERIFY_TYPE_CONTEXT:            Misc.               (line 1045)
  * TARGET_VTABLE_DATA_ENTRY_DISTANCE:     Type Layout.        (line  303)
  * TARGET_VTABLE_ENTRY_ALIGN:             Type Layout.        (line  297)
*************** Concept Index
*** 57720,57725 ****
--- 57717,57724 ----
  * TARGET_WARN_PARAMETER_PASSING_ABI:     Aggregate Return.   (line   92)
  * TARGET_WEAK_NOT_IN_ARCHIVE_TOC:        Label Output.       (line  308)
  * TARGET_ZERO_CALL_USED_REGS:            Misc.               (line 1080)
+ * targetm:                               Target Structure.   (line    6)
+ * targets, makefile:                     Makefile.           (line    6)
  * tbranch_OPMODE3 instruction pattern:   Standard Names.     (line 2036)
  * TCmode:                                Machine Modes.      (line  198)
  * TDmode:                                Machine Modes.      (line   97)
*************** Concept Index
*** 57745,57754 ****
  * tm.h macros:                           Target Macros.      (line    6)
  * TQFmode:                               Machine Modes.      (line   65)
  * TQmode:                                Machine Modes.      (line  122)
- * trampolines for nested functions:      Trampolines.        (line    6)
  * TRAMPOLINE_ALIGNMENT:                  Trampolines.        (line  105)
  * TRAMPOLINE_SECTION:                    Trampolines.        (line   96)
  * TRAMPOLINE_SIZE:                       Trampolines.        (line  101)
  * TRANSFER_FROM_TRAMPOLINE:              Trampolines.        (line  180)
  * trap instruction pattern:              Standard Names.     (line 2469)
  * tree:                                  Tree overview.      (line    6)
--- 57744,57753 ----
  * tm.h macros:                           Target Macros.      (line    6)
  * TQFmode:                               Machine Modes.      (line   65)
  * TQmode:                                Machine Modes.      (line  122)
  * TRAMPOLINE_ALIGNMENT:                  Trampolines.        (line  105)
  * TRAMPOLINE_SECTION:                    Trampolines.        (line   96)
  * TRAMPOLINE_SIZE:                       Trampolines.        (line  101)
+ * trampolines for nested functions:      Trampolines.        (line    6)
  * TRANSFER_FROM_TRAMPOLINE:              Trampolines.        (line  180)
  * trap instruction pattern:              Standard Names.     (line 2469)
  * tree:                                  Tree overview.      (line    6)
*************** Concept Index
*** 57809,57830 ****
  * TREE_VEC_LENGTH:                       Containers.         (line    6)
  * true positive:                         Guidelines for Diagnostics.
                                                               (line   39)
- * truncate:                              Conversions.        (line   38)
- * truncMN2 instruction pattern:          Standard Names.     (line 1770)
  * TRUNC_DIV_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * TRUNC_MOD_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
! * TRUTH_ANDIF_EXPR:                      Unary and Binary Expressions.
!                                                              (line    6)
  * TRUTH_AND_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
! * TRUTH_NOT_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
! * TRUTH_ORIF_EXPR:                       Unary and Binary Expressions.
                                                               (line    6)
  * TRUTH_OR_EXPR:                         Unary and Binary Expressions.
                                                               (line    6)
  * TRUTH_XOR_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * TRY_BLOCK:                             Statements for C and C++.
--- 57808,57829 ----
  * TREE_VEC_LENGTH:                       Containers.         (line    6)
  * true positive:                         Guidelines for Diagnostics.
                                                               (line   39)
  * TRUNC_DIV_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * TRUNC_MOD_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
! * truncate:                              Conversions.        (line   38)
! * truncMN2 instruction pattern:          Standard Names.     (line 1770)
  * TRUTH_AND_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
! * TRUTH_ANDIF_EXPR:                      Unary and Binary Expressions.
                                                               (line    6)
! * TRUTH_NOT_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * TRUTH_OR_EXPR:                         Unary and Binary Expressions.
                                                               (line    6)
+ * TRUTH_ORIF_EXPR:                       Unary and Binary Expressions.
+                                                              (line    6)
  * TRUTH_XOR_EXPR:                        Unary and Binary Expressions.
                                                               (line    6)
  * TRY_BLOCK:                             Statements for C and C++.
*************** Concept Index
*** 57839,57848 ****
                                                               (line    6)
  * type:                                  Types.              (line    6)
  * type declaration:                      Declarations.       (line    6)
- * TYPENAME_TYPE:                         Types for C++.      (line    6)
- * TYPENAME_TYPE_FULLNAME:                Types.              (line    6)
- * TYPENAME_TYPE_FULLNAME <1>:            Types for C++.      (line    6)
- * TYPEOF_TYPE:                           Types for C++.      (line    6)
  * TYPE_ALIGN:                            Types.              (line    6)
  * TYPE_ALIGN <1>:                        Types.              (line   30)
  * TYPE_ALIGN <2>:                        Types for C++.      (line    6)
--- 57838,57843 ----
*************** Concept Index
*** 57886,57897 ****
  * TYPE_POLYMORPHIC_P:                    Classes.            (line   74)
  * TYPE_PRECISION:                        Types.              (line    6)
  * TYPE_PRECISION <1>:                    Types for C++.      (line    6)
  * TYPE_PTRDATAMEM_P:                     Types for C++.      (line    6)
  * TYPE_PTRDATAMEM_P <1>:                 Types for C++.      (line   69)
  * TYPE_PTRFN_P:                          Types for C++.      (line   76)
- * TYPE_PTROBV_P:                         Types for C++.      (line    6)
  * TYPE_PTROB_P:                          Types for C++.      (line   79)
! * TYPE_PTR_P:                            Types for C++.      (line   72)
  * TYPE_QUAL_CONST:                       Types.              (line    6)
  * TYPE_QUAL_CONST <1>:                   Types for C++.      (line    6)
  * TYPE_QUAL_RESTRICT:                    Types.              (line    6)
--- 57881,57892 ----
  * TYPE_POLYMORPHIC_P:                    Classes.            (line   74)
  * TYPE_PRECISION:                        Types.              (line    6)
  * TYPE_PRECISION <1>:                    Types for C++.      (line    6)
+ * TYPE_PTR_P:                            Types for C++.      (line   72)
  * TYPE_PTRDATAMEM_P:                     Types for C++.      (line    6)
  * TYPE_PTRDATAMEM_P <1>:                 Types for C++.      (line   69)
  * TYPE_PTRFN_P:                          Types for C++.      (line   76)
  * TYPE_PTROB_P:                          Types for C++.      (line   79)
! * TYPE_PTROBV_P:                         Types for C++.      (line    6)
  * TYPE_QUAL_CONST:                       Types.              (line    6)
  * TYPE_QUAL_CONST <1>:                   Types for C++.      (line    6)
  * TYPE_QUAL_RESTRICT:                    Types.              (line    6)
*************** Concept Index
*** 57908,57913 ****
--- 57903,57912 ----
  * TYPE_UNQUALIFIED:                      Types.              (line    6)
  * TYPE_UNQUALIFIED <1>:                  Types for C++.      (line    6)
  * TYPE_VFIELD:                           Classes.            (line    6)
+ * TYPENAME_TYPE:                         Types for C++.      (line    6)
+ * TYPENAME_TYPE_FULLNAME:                Types.              (line    6)
+ * TYPENAME_TYPE_FULLNAME <1>:            Types for C++.      (line    6)
+ * TYPEOF_TYPE:                           Types for C++.      (line    6)
  * uaddvM4 instruction pattern:           Standard Names.     (line  513)
  * uavgM3_ceil instruction pattern:       Standard Names.     (line  990)
  * uavgM3_floor instruction pattern:      Standard Names.     (line  978)
*************** Concept Index
*** 57919,57930 ****
  * UDQmode:                               Machine Modes.      (line  138)
  * UHAmode:                               Machine Modes.      (line  162)
  * UHQmode:                               Machine Modes.      (line  130)
- * UINT16_TYPE:                           Type Layout.        (line  214)
- * UINT32_TYPE:                           Type Layout.        (line  215)
- * UINT64_TYPE:                           Type Layout.        (line  216)
- * UINT8_TYPE:                            Type Layout.        (line  213)
- * UINTMAX_TYPE:                          Type Layout.        (line  197)
- * UINTPTR_TYPE:                          Type Layout.        (line  234)
  * UINT_FAST16_TYPE:                      Type Layout.        (line  230)
  * UINT_FAST32_TYPE:                      Type Layout.        (line  231)
  * UINT_FAST64_TYPE:                      Type Layout.        (line  232)
--- 57918,57923 ----
*************** Concept Index
*** 57933,57938 ****
--- 57926,57937 ----
  * UINT_LEAST32_TYPE:                     Type Layout.        (line  223)
  * UINT_LEAST64_TYPE:                     Type Layout.        (line  224)
  * UINT_LEAST8_TYPE:                      Type Layout.        (line  221)
+ * UINT16_TYPE:                           Type Layout.        (line  214)
+ * UINT32_TYPE:                           Type Layout.        (line  215)
+ * UINT64_TYPE:                           Type Layout.        (line  216)
+ * UINT8_TYPE:                            Type Layout.        (line  213)
+ * UINTMAX_TYPE:                          Type Layout.        (line  197)
+ * UINTPTR_TYPE:                          Type Layout.        (line  234)
  * umaddMN4 instruction pattern:          Standard Names.     (line  902)
  * umax:                                  Arithmetic.         (line  155)
  * umaxM3 instruction pattern:            Standard Names.     (line  494)
*************** Concept Index
*** 57941,57946 ****
--- 57940,57946 ----
  * umod:                                  Arithmetic.         (line  142)
  * umodM3 instruction pattern:            Standard Names.     (line  494)
  * umsubMN4 instruction pattern:          Standard Names.     (line  926)
+ * umul_highpart:                         Arithmetic.         (line  111)
  * umulhisi3 instruction pattern:         Standard Names.     (line  871)
  * umulhrsM3 instruction pattern:         Standard Names.     (line  698)
  * umulhsM3 instruction pattern:          Standard Names.     (line  688)
*************** Concept Index
*** 57948,57954 ****
  * umulqihi3 instruction pattern:         Standard Names.     (line  871)
  * umulsidi3 instruction pattern:         Standard Names.     (line  871)
  * umulvM4 instruction pattern:           Standard Names.     (line  518)
- * umul_highpart:                         Arithmetic.         (line  111)
  * unchanging:                            Flags.              (line  307)
  * unchanging, in call_insn:              Flags.              (line  115)
  * unchanging, in jump_insn, call_insn and insn: Flags.       (line   28)
--- 57948,57953 ----
*************** Concept Index
*** 57962,57970 ****
                                                               (line    6)
  * UNGT_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
- * unions, returning:                     Interface.          (line   10)
  * UNION_TYPE:                            Types.              (line    6)
  * UNION_TYPE <1>:                        Classes.            (line    6)
  * UNITS_PER_WORD:                        Storage Layout.     (line   60)
  * UNKNOWN_TYPE:                          Types.              (line    6)
  * UNKNOWN_TYPE <1>:                      Types for C++.      (line    6)
--- 57961,57969 ----
                                                               (line    6)
  * UNGT_EXPR:                             Unary and Binary Expressions.
                                                               (line    6)
  * UNION_TYPE:                            Types.              (line    6)
  * UNION_TYPE <1>:                        Classes.            (line    6)
+ * unions, returning:                     Interface.          (line   10)
  * UNITS_PER_WORD:                        Storage Layout.     (line   60)
  * UNKNOWN_TYPE:                          Types.              (line    6)
  * UNKNOWN_TYPE <1>:                      Types for C++.      (line    6)
*************** Concept Index
*** 57987,57996 ****
  * unsigned_float:                        Conversions.        (line   62)
  * unsigned_fract_convert:                Conversions.        (line   97)
  * unsigned_sat_fract:                    Conversions.        (line  103)
! * unspec:                                Side Effects.       (line  290)
  * unspec <1>:                            Constant Definitions.
                                                               (line  114)
! * unspec_volatile:                       Side Effects.       (line  290)
  * unspec_volatile <1>:                   Constant Definitions.
                                                               (line  102)
  * untyped_call instruction pattern:      Standard Names.     (line 2095)
--- 57986,57995 ----
  * unsigned_float:                        Conversions.        (line   62)
  * unsigned_fract_convert:                Conversions.        (line   97)
  * unsigned_sat_fract:                    Conversions.        (line  103)
! * unspec:                                Side Effects.       (line  289)
  * unspec <1>:                            Constant Definitions.
                                                               (line  114)
! * unspec_volatile:                       Side Effects.       (line  289)
  * unspec_volatile <1>:                   Constant Definitions.
                                                               (line  102)
  * untyped_call instruction pattern:      Standard Names.     (line 2095)
*************** Concept Index
*** 58003,58008 ****
--- 58002,58013 ----
  * update_stmt_if_modified:               Manipulating GIMPLE statements.
                                                               (line  136)
  * UQQmode:                               Machine Modes.      (line  126)
+ * us_ashift:                             Arithmetic.         (line  179)
+ * us_minus:                              Arithmetic.         (line   38)
+ * us_mult:                               Arithmetic.         (line   92)
+ * us_neg:                                Arithmetic.         (line   81)
+ * us_plus:                               Arithmetic.         (line   14)
+ * us_truncate:                           Conversions.        (line   48)
  * usaddM3 instruction pattern:           Standard Names.     (line  494)
  * usadM instruction pattern:             Standard Names.     (line  672)
  * USAmode:                               Machine Modes.      (line  166)
*************** Concept Index
*** 58010,58022 ****
  * usdivM3 instruction pattern:           Standard Names.     (line  494)
  * usdot_prodM instruction pattern:       Standard Names.     (line  657)
  * use:                                   Side Effects.       (line  161)
- * used:                                  Flags.              (line  325)
- * used, in symbol_ref:                   Flags.              (line  211)
- * user:                                  GTY Options.        (line  269)
- * user experience guidelines:            User Experience Guidelines.
-                                                              (line    6)
- * user gc:                               User GC.            (line    6)
- * USER_LABEL_PREFIX:                     Instruction Output. (line  152)
  * USE_C_ALLOCA:                          Host Misc.          (line   19)
  * USE_LD_AS_NEEDED:                      Driver.             (line  135)
  * USE_LOAD_POST_DECREMENT:               Costs.              (line  261)
--- 58015,58020 ----
*************** Concept Index
*** 58028,58033 ****
--- 58026,58038 ----
  * USE_STORE_POST_INCREMENT:              Costs.              (line  276)
  * USE_STORE_PRE_DECREMENT:               Costs.              (line  291)
  * USE_STORE_PRE_INCREMENT:               Costs.              (line  286)
+ * used:                                  Flags.              (line  325)
+ * used, in symbol_ref:                   Flags.              (line  211)
+ * user:                                  GTY Options.        (line  269)
+ * user experience guidelines:            User Experience Guidelines.
+                                                              (line    6)
+ * user gc:                               User GC.            (line    6)
+ * USER_LABEL_PREFIX:                     Instruction Output. (line  152)
  * USING_STMT:                            Statements for C and C++.
                                                               (line    6)
  * usmaddMN4 instruction pattern:         Standard Names.     (line  910)
*************** Concept Index
*** 58040,58074 ****
  * USQmode:                               Machine Modes.      (line  134)
  * ussubM3 instruction pattern:           Standard Names.     (line  494)
  * usubvM4 instruction pattern:           Standard Names.     (line  518)
- * us_ashift:                             Arithmetic.         (line  179)
- * us_minus:                              Arithmetic.         (line   38)
- * us_mult:                               Arithmetic.         (line   92)
- * us_neg:                                Arithmetic.         (line   81)
- * us_plus:                               Arithmetic.         (line   14)
- * us_truncate:                           Conversions.        (line   48)
  * UTAmode:                               Machine Modes.      (line  174)
  * UTQmode:                               Machine Modes.      (line  142)
  * V in constraint:                       Simple Constraints. (line   43)
  * values, returned by functions:         Scalar Return.      (line    6)
  * varargs implementation:                Varargs.            (line    6)
  * variable:                              Declarations.       (line    6)
  * Variable Location Debug Information in RTL: Debug Information.
                                                               (line    6)
- * VAR_DECL:                              Declarations.       (line    6)
- * var_location:                          Debug Information.  (line   14)
  * vashlM3 instruction pattern:           Standard Names.     (line  974)
  * vashrM3 instruction pattern:           Standard Names.     (line  974)
! * VA_ARG_EXPR:                           Unary and Binary Expressions.
!                                                              (line    6)
  * vcondeqMN instruction pattern:         Standard Names.     (line  393)
  * vcondMN instruction pattern:           Standard Names.     (line  380)
  * vconduMN instruction pattern:          Standard Names.     (line  390)
- * vcond_mask_MN instruction pattern:     Standard Names.     (line  400)
- * vector:                                Containers.         (line    6)
- * vector operations:                     Vector Operations.  (line    6)
- * VECTOR_CST:                            Constant expressions.
-                                                              (line    6)
- * VECTOR_STORE_FLAG_VALUE:               Misc.               (line  329)
  * vec_addsubM3 instruction pattern:      Standard Names.     (line  845)
  * vec_cmpeqMN instruction pattern:       Standard Names.     (line  373)
  * vec_cmpMN instruction pattern:         Standard Names.     (line  363)
--- 58045,58068 ----
  * USQmode:                               Machine Modes.      (line  134)
  * ussubM3 instruction pattern:           Standard Names.     (line  494)
  * usubvM4 instruction pattern:           Standard Names.     (line  518)
  * UTAmode:                               Machine Modes.      (line  174)
  * UTQmode:                               Machine Modes.      (line  142)
  * V in constraint:                       Simple Constraints. (line   43)
+ * VA_ARG_EXPR:                           Unary and Binary Expressions.
+                                                              (line    6)
  * values, returned by functions:         Scalar Return.      (line    6)
+ * VAR_DECL:                              Declarations.       (line    6)
+ * var_location:                          Debug Information.  (line   14)
  * varargs implementation:                Varargs.            (line    6)
  * variable:                              Declarations.       (line    6)
  * Variable Location Debug Information in RTL: Debug Information.
                                                               (line    6)
  * vashlM3 instruction pattern:           Standard Names.     (line  974)
  * vashrM3 instruction pattern:           Standard Names.     (line  974)
! * vcond_mask_MN instruction pattern:     Standard Names.     (line  400)
  * vcondeqMN instruction pattern:         Standard Names.     (line  393)
  * vcondMN instruction pattern:           Standard Names.     (line  380)
  * vconduMN instruction pattern:          Standard Names.     (line  390)
  * vec_addsubM3 instruction pattern:      Standard Names.     (line  845)
  * vec_cmpeqMN instruction pattern:       Standard Names.     (line  373)
  * vec_cmpMN instruction pattern:         Standard Names.     (line  363)
*************** Concept Index
*** 58076,58083 ****
  * vec_concat:                            Vector Operations.  (line   29)
  * VEC_COND_EXPR:                         Vectors.            (line    6)
  * vec_duplicate:                         Vector Operations.  (line   34)
- * vec_duplicateM instruction pattern:    Standard Names.     (line  298)
  * VEC_DUPLICATE_EXPR:                    Vectors.            (line    6)
  * vec_extractMN instruction pattern:     Standard Names.     (line  282)
  * vec_fmaddsubM4 instruction pattern:    Standard Names.     (line  850)
  * vec_fmsubaddM4 instruction pattern:    Standard Names.     (line  856)
--- 58070,58077 ----
  * vec_concat:                            Vector Operations.  (line   29)
  * VEC_COND_EXPR:                         Vectors.            (line    6)
  * vec_duplicate:                         Vector Operations.  (line   34)
  * VEC_DUPLICATE_EXPR:                    Vectors.            (line    6)
+ * vec_duplicateM instruction pattern:    Standard Names.     (line  298)
  * vec_extractMN instruction pattern:     Standard Names.     (line  282)
  * vec_fmaddsubM4 instruction pattern:    Standard Names.     (line  850)
  * vec_fmsubaddM4 instruction pattern:    Standard Names.     (line  856)
*************** Concept Index
*** 58088,58095 ****
  * vec_mask_store_lanesMN instruction pattern: Standard Names.
                                                               (line  219)
  * vec_merge:                             Vector Operations.  (line   11)
- * vec_packs_float_M instruction pattern: Standard Names.     (line  764)
- * vec_packu_float_M instruction pattern: Standard Names.     (line  764)
  * VEC_PACK_FIX_TRUNC_EXPR:               Vectors.            (line    6)
  * VEC_PACK_FLOAT_EXPR:                   Vectors.            (line    6)
  * VEC_PACK_SAT_EXPR:                     Vectors.            (line    6)
--- 58082,58087 ----
*************** Concept Index
*** 58101,58118 ****
  * vec_pack_trunc_M instruction pattern:  Standard Names.     (line  734)
  * vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line  757)
  * vec_pack_usat_M instruction pattern:   Standard Names.     (line  750)
  * vec_permM instruction pattern:         Standard Names.     (line  462)
  * vec_permM instruction pattern <1>:     Addressing Modes.   (line  342)
  * VEC_RSHIFT_EXPR:                       Vectors.            (line    6)
  * vec_select:                            Vector Operations.  (line   19)
  * vec_series:                            Vector Operations.  (line   41)
- * vec_seriesM instruction pattern:       Standard Names.     (line  308)
  * VEC_SERIES_EXPR:                       Vectors.            (line    6)
  * vec_setM instruction pattern:          Standard Names.     (line  277)
  * vec_shl_insert_M instruction pattern:  Standard Names.     (line  715)
  * vec_shl_M instruction pattern:         Standard Names.     (line  722)
  * vec_shr_M instruction pattern:         Standard Names.     (line  728)
  * vec_store_lanesMN instruction pattern: Standard Names.     (line  206)
  * vec_unpacks_float_hi_M instruction pattern: Standard Names.
                                                               (line  794)
  * vec_unpacks_float_lo_M instruction pattern: Standard Names.
--- 58093,58126 ----
  * vec_pack_trunc_M instruction pattern:  Standard Names.     (line  734)
  * vec_pack_ufix_trunc_M instruction pattern: Standard Names. (line  757)
  * vec_pack_usat_M instruction pattern:   Standard Names.     (line  750)
+ * vec_packs_float_M instruction pattern: Standard Names.     (line  764)
+ * vec_packu_float_M instruction pattern: Standard Names.     (line  764)
  * vec_permM instruction pattern:         Standard Names.     (line  462)
  * vec_permM instruction pattern <1>:     Addressing Modes.   (line  342)
  * VEC_RSHIFT_EXPR:                       Vectors.            (line    6)
  * vec_select:                            Vector Operations.  (line   19)
  * vec_series:                            Vector Operations.  (line   41)
  * VEC_SERIES_EXPR:                       Vectors.            (line    6)
+ * vec_seriesM instruction pattern:       Standard Names.     (line  308)
  * vec_setM instruction pattern:          Standard Names.     (line  277)
  * vec_shl_insert_M instruction pattern:  Standard Names.     (line  715)
  * vec_shl_M instruction pattern:         Standard Names.     (line  722)
  * vec_shr_M instruction pattern:         Standard Names.     (line  728)
  * vec_store_lanesMN instruction pattern: Standard Names.     (line  206)
+ * VEC_UNPACK_FIX_TRUNC_HI_EXPR:          Vectors.            (line    6)
+ * VEC_UNPACK_FIX_TRUNC_LO_EXPR:          Vectors.            (line    6)
+ * VEC_UNPACK_FLOAT_HI_EXPR:              Vectors.            (line    6)
+ * VEC_UNPACK_FLOAT_LO_EXPR:              Vectors.            (line    6)
+ * VEC_UNPACK_HI_EXPR:                    Vectors.            (line    6)
+ * VEC_UNPACK_LO_EXPR:                    Vectors.            (line    6)
+ * vec_unpack_sfix_trunc_hi_M instruction pattern: Standard Names.
+                                                              (line  803)
+ * vec_unpack_sfix_trunc_lo_M instruction pattern: Standard Names.
+                                                              (line  803)
+ * vec_unpack_ufix_trunc_hi_M instruction pattern: Standard Names.
+                                                              (line  803)
+ * vec_unpack_ufix_trunc_lo_M instruction pattern: Standard Names.
+                                                              (line  803)
  * vec_unpacks_float_hi_M instruction pattern: Standard Names.
                                                               (line  794)
  * vec_unpacks_float_lo_M instruction pattern: Standard Names.
*************** Concept Index
*** 58129,58148 ****
                                                               (line  794)
  * vec_unpacku_hi_M instruction pattern:  Standard Names.     (line  778)
  * vec_unpacku_lo_M instruction pattern:  Standard Names.     (line  778)
- * VEC_UNPACK_FIX_TRUNC_HI_EXPR:          Vectors.            (line    6)
- * VEC_UNPACK_FIX_TRUNC_LO_EXPR:          Vectors.            (line    6)
- * VEC_UNPACK_FLOAT_HI_EXPR:              Vectors.            (line    6)
- * VEC_UNPACK_FLOAT_LO_EXPR:              Vectors.            (line    6)
- * VEC_UNPACK_HI_EXPR:                    Vectors.            (line    6)
- * VEC_UNPACK_LO_EXPR:                    Vectors.            (line    6)
- * vec_unpack_sfix_trunc_hi_M instruction pattern: Standard Names.
-                                                              (line  803)
- * vec_unpack_sfix_trunc_lo_M instruction pattern: Standard Names.
-                                                              (line  803)
- * vec_unpack_ufix_trunc_hi_M instruction pattern: Standard Names.
-                                                              (line  803)
- * vec_unpack_ufix_trunc_lo_M instruction pattern: Standard Names.
-                                                              (line  803)
  * VEC_WIDEN_MINUS_HI_EXPR:               Vectors.            (line    6)
  * VEC_WIDEN_MINUS_LO_EXPR:               Vectors.            (line    6)
  * VEC_WIDEN_MULT_HI_EXPR:                Vectors.            (line    6)
--- 58137,58142 ----
*************** Concept Index
*** 58175,58180 ****
--- 58169,58179 ----
                                                               (line  824)
  * vec_widen_usubl_hi_M instruction pattern: Standard Names.  (line  838)
  * vec_widen_usubl_lo_M instruction pattern: Standard Names.  (line  838)
+ * vector:                                Containers.         (line    6)
+ * vector operations:                     Vector Operations.  (line    6)
+ * VECTOR_CST:                            Constant expressions.
+                                                              (line    6)
+ * VECTOR_STORE_FLAG_VALUE:               Misc.               (line  329)
  * verify_flow_info:                      Maintaining the CFG.
                                                               (line  116)
  * virtual operands:                      SSA Operands.       (line    6)
*************** Concept Index
*** 58189,58196 ****
  * vlshrM3 instruction pattern:           Standard Names.     (line  974)
  * VMS:                                   Filesystem.         (line   37)
  * VMS_DEBUGGING_INFO:                    VMS Debug.          (line    8)
- * VOIDmode:                              Machine Modes.      (line  191)
  * VOID_TYPE:                             Types.              (line    6)
  * volatil:                               Flags.              (line  339)
  * volatil, in insn, call_insn, jump_insn, code_label, jump_table_data, barrier, and note: Flags.
                                                               (line   33)
--- 58188,58195 ----
  * vlshrM3 instruction pattern:           Standard Names.     (line  974)
  * VMS:                                   Filesystem.         (line   37)
  * VMS_DEBUGGING_INFO:                    VMS Debug.          (line    8)
  * VOID_TYPE:                             Types.              (line    6)
+ * VOIDmode:                              Machine Modes.      (line  191)
  * volatil:                               Flags.              (line  339)
  * volatil, in insn, call_insn, jump_insn, code_label, jump_table_data, barrier, and note: Flags.
                                                               (line   33)
*************** Concept Index
*** 58230,58239 ****
  * WIDEST_HARDWARE_FP_SIZE:               Type Layout.        (line  110)
  * window_save instruction pattern:       Standard Names.     (line 2440)
  * WINT_TYPE:                             Type Layout.        (line  178)
- * WORDS_BIG_ENDIAN:                      Storage Layout.     (line   28)
- * WORDS_BIG_ENDIAN, effect on subreg:    Regs and Memory.    (line  225)
  * word_mode:                             Machine Modes.      (line  462)
  * WORD_REGISTER_OPERATIONS:              Misc.               (line   53)
  * wpa:                                   LTO.                (line    6)
  * X in constraint:                       Simple Constraints. (line  122)
  * x-HOST:                                Host Fragment.      (line    6)
--- 58229,58238 ----
  * WIDEST_HARDWARE_FP_SIZE:               Type Layout.        (line  110)
  * window_save instruction pattern:       Standard Names.     (line 2440)
  * WINT_TYPE:                             Type Layout.        (line  178)
  * word_mode:                             Machine Modes.      (line  462)
  * WORD_REGISTER_OPERATIONS:              Misc.               (line   53)
+ * WORDS_BIG_ENDIAN:                      Storage Layout.     (line   28)
+ * WORDS_BIG_ENDIAN, effect on subreg:    Regs and Memory.    (line  225)
  * wpa:                                   LTO.                (line    6)
  * X in constraint:                       Simple Constraints. (line  122)
  * x-HOST:                                Host Fragment.      (line    6)
*************** Concept Index
*** 58263,58722 ****
  
  
  Tag Table:
! Node: Top1789
! Node: Contributing5176
! Node: Portability5911
! Node: Interface7699
! Node: Libgcc10740
! Node: Integer library routines12567
! Node: Soft float library routines19535
! Node: Decimal float library routines31473
! Node: Fixed-point fractional library routines47231
! Node: Exception handling routines147627
! Node: Miscellaneous routines148734
! Node: Languages150854
! Node: Source Tree152401
! Node: Configure Terms152984
! Node: Top Level155940
! Node: gcc Directory160010
! Node: Subdirectories160962
! Node: Configuration163150
! Node: Config Fragments163870
! Node: System Config165095
! Node: Configuration Files166031
! Node: Build168647
! Node: Makefile169059
! Ref: Makefile-Footnote-1176253
! Ref: Makefile-Footnote-2176400
! Node: Library Files176474
! Node: Headers177036
! Node: Documentation179119
! Node: Texinfo Manuals179978
! Node: Man Page Generation182307
! Node: Miscellaneous Docs184019
! Node: Front End185406
! Node: Front End Directory189086
! Node: Front End Config190403
! Node: Front End Makefile193240
! Node: Back End197008
! Node: Testsuites201894
! Node: Test Idioms202883
! Node: Test Directives206281
! Node: Directives206808
! Node: Selectors219410
! Node: Effective-Target Keywords222738
! Ref: arm_fp_ok238007
! Ref: arm_fp_dp_ok238174
! Ref: arm_neon_ok239207
! Ref: arm_neon_ok_no_float_abi239376
! Ref: arm_neonv2_ok239543
! Ref: arm_fp16_ok239710
! Ref: arm_neon_fp16_ok240052
! Ref: arm_vfp3_ok240984
! Ref: arm_arch_v8a_hard_ok241127
! Ref: arm_v8_1a_neon_ok241877
! Ref: arm_v8_2a_fp16_scalar_ok242305
! Ref: arm_v8_2a_fp16_neon_ok242756
! Ref: arm_v8_2a_dotprod_neon_ok243231
! Ref: arm_fp16fml_neon_ok243876
! Ref: arm_coproc1_ok246574
! Ref: arm_coproc2_ok246700
! Ref: arm_coproc3_ok246928
! Ref: arm_simd32_ok247295
! Ref: arm_sat_ok247472
! Ref: arm_dsp_ok247653
! Ref: arm_softfp_ok247830
! Ref: arm_hard_ok247903
! Ref: arm_mve247970
! Ref: arm_v8_1_lob_ok248043
! Ref: default_packed261530
! Ref: stack_size_et264722
! Node: Add Options267409
! Ref: arm_fp16_ieee268647
! Ref: arm_fp16_alternative268902
! Ref: stack_size_ao271466
! Node: Require Support271918
! Node: Final Actions274820
! Node: Ada Tests285106
! Node: C Tests286269
! Node: LTO Testing290641
! Node: gcov Testing292284
! Node: profopt Testing295254
! Node: compat Testing296969
! Node: Torture Tests301209
! Node: GIMPLE Tests302843
! Node: RTL Tests304085
! Node: Options305391
! Node: Option file format305832
! Node: Option properties314320
! Node: Passes331269
! Node: Parsing pass332142
! Node: Gimplification pass335670
! Node: Pass manager337504
! Node: IPA passes339346
! Node: Small IPA passes340239
! Node: Regular IPA passes343689
! Node: Late IPA passes348491
! Node: Tree SSA passes349452
! Node: RTL passes371380
! Node: Optimization info383663
! Node: Dump setup384482
! Node: Optimization groups385612
! Node: Dump files and streams386591
! Node: Dump output verbosity387789
! Node: Dump types388845
! Node: Dump examples391188
! Node: poly_int392669
! Node: Overview of poly_int394149
! Node: Consequences of using poly_int396753
! Node: Comparisons involving poly_int398388
! Node: Comparison functions for poly_int400026
! Node: Properties of the poly_int comparisons401233
! Node: Comparing potentially-unordered poly_ints403675
! Node: Comparing ordered poly_ints404586
! Node: Checking for a poly_int marker value406610
! Node: Range checks on poly_ints407459
! Node: Sorting poly_ints410113
! Node: Arithmetic on poly_ints410886
! Node: Using poly_int with C++ arithmetic operators411687
! Node: wi arithmetic on poly_ints413218
! Node: Division of poly_ints414070
! Node: Other poly_int arithmetic415577
! Node: Alignment of poly_ints416983
! Node: Computing bounds on poly_ints420260
! Node: Converting poly_ints421649
! Node: Miscellaneous poly_int routines425196
! Node: Guidelines for using poly_int425836
! Node: GENERIC430768
! Node: Deficiencies432590
! Node: Tree overview432831
! Node: Macros and Functions436955
! Node: Identifiers437780
! Node: Containers439389
! Node: Types440546
! Node: Declarations452957
! Node: Working with declarations453452
! Node: Internal structure459056
! Node: Current structure hierarchy459440
! Node: Adding new DECL node types461533
! Node: Attributes465819
! Node: Expression trees467063
! Node: Constant expressions468817
! Node: Storage References474909
! Node: Unary and Binary Expressions478750
! Node: Vectors500083
! Node: Statements508573
! Node: Basic Statements509105
! Node: Blocks513880
! Node: Statement Sequences515581
! Node: Empty Statements515914
! Node: Jumps516488
! Node: Cleanups517141
! Node: OpenMP519182
! Node: OpenACC526895
! Node: Functions528012
! Node: Function Basics528483
! Node: Function Properties532167
! Node: Language-dependent trees534948
! Node: C and C++ Trees535835
! Node: Types for C++538720
! Node: Namespaces543690
! Node: Classes546796
! Node: Functions for C++551704
! Node: Statements for C and C++557961
! Node: C++ Expressions566468
! Node: GIMPLE567979
! Node: Tuple representation571644
! Node: Class hierarchy of GIMPLE statements578604
! Node: GIMPLE instruction set583592
! Node: GIMPLE Exception Handling585224
! Node: Temporaries587136
! Ref: Temporaries-Footnote-1588454
! Node: Operands588519
! Node: Compound Expressions589280
! Node: Compound Lvalues589514
! Node: Conditional Expressions590276
! Node: Logical Operators590935
! Node: Manipulating GIMPLE statements598246
! Node: Tuple specific accessors603828
! Node: GIMPLE_ASM604607
! Node: GIMPLE_ASSIGN606990
! Node: GIMPLE_BIND611694
! Node: GIMPLE_CALL613508
! Node: GIMPLE_CATCH617649
! Node: GIMPLE_COND618799
! Node: GIMPLE_DEBUG621594
! Node: GIMPLE_EH_FILTER626192
! Node: GIMPLE_LABEL627755
! Node: GIMPLE_GOTO628368
! Node: GIMPLE_NOP628891
! Node: GIMPLE_OMP_ATOMIC_LOAD629253
! Node: GIMPLE_OMP_ATOMIC_STORE630249
! Node: GIMPLE_OMP_CONTINUE630948
! Node: GIMPLE_OMP_CRITICAL632427
! Node: GIMPLE_OMP_FOR633421
! Node: GIMPLE_OMP_MASTER636837
! Node: GIMPLE_OMP_ORDERED637215
! Node: GIMPLE_OMP_PARALLEL637618
! Node: GIMPLE_OMP_RETURN640405
! Node: GIMPLE_OMP_SECTION641050
! Node: GIMPLE_OMP_SECTIONS641714
! Node: GIMPLE_OMP_SINGLE643324
! Node: GIMPLE_PHI644270
! Node: GIMPLE_RESX645549
! Node: GIMPLE_RETURN646268
! Node: GIMPLE_SWITCH646842
! Node: GIMPLE_TRY648715
! Node: GIMPLE_WITH_CLEANUP_EXPR650487
! Node: GIMPLE sequences651366
! Node: Sequence iterators654572
! Node: Adding a new GIMPLE statement code663029
! Node: Statement and operand traversals664378
! Node: Tree SSA666970
! Node: Annotations668758
! Node: SSA Operands669163
! Node: SSA682967
! Node: Alias analysis692674
! Node: Memory model696449
! Node: RTL697808
! Node: RTL Objects700050
! Node: RTL Classes703934
! Node: Accessors709232
! Node: Special Accessors711405
! Node: Flags717192
! Node: Machine Modes732455
! Node: Constants750022
! Node: Regs and Memory761821
! Node: Arithmetic779092
! Node: Comparisons789471
! Node: Bit-Fields793173
! Node: Vector Operations794724
! Node: Conversions796828
! Node: RTL Declarations801326
! Node: Side Effects802170
! Node: Incdec818658
! Node: Assembler821994
! Node: Debug Information823539
! Node: Insns825466
! Node: Calls851355
! Node: RTL SSA853948
! Node: Using RTL SSA855339
! Node: RTL SSA Instructions857256
! Ref: RTL SSA Instructions-Footnote-1858642
! Node: RTL SSA Basic Blocks858776
! Ref: real RTL SSA insns859244
! Ref: RTL SSA Basic Blocks-Footnote-1861466
! Node: RTL SSA Resources861600
! Node: RTL SSA Accesses862717
! Ref: RTL SSA Accesses-Footnote-1864418
! Node: RTL SSA Phi Nodes864561
! Node: RTL SSA Access Lists866565
! Node: Changing RTL Instructions870846
! Node: Changing One RTL SSA Instruction871455
! Node: Changing Multiple RTL SSA Instructions876391
! Node: Sharing880634
! Node: Reading RTL883790
! Node: Control Flow884782
! Node: Basic Blocks886550
! Node: Edges892004
! Node: Profile information900623
! Node: Maintaining the CFG905307
! Node: Liveness information911075
! Node: Loop Analysis and Representation913202
! Node: Loop representation914238
! Node: Loop querying921682
! Node: Loop manipulation924491
! Node: LCSSA926837
! Node: Scalar evolutions928906
! Node: loop-iv932150
! Node: Number of iterations934072
! Node: Dependency analysis938153
! Node: Machine Desc944505
! Node: Overview947068
! Node: Patterns949108
! Node: Example954075
! Node: RTL Template955536
! Node: Output Template966184
! Node: Output Statement970365
! Node: Predicates974704
! Node: Machine-Independent Predicates977622
! Node: Defining Predicates982567
! Node: Constraints988530
! Node: Simple Constraints989999
! Node: Multi-Alternative1002839
! Node: Class Preferences1006039
! Node: Modifiers1006931
! Node: Machine Constraints1011665
! Node: Disable Insn Alternatives1071240
! Node: Define Constraints1074732
! Node: C Constraint Interface1083321
! Node: Standard Names1086448
! Ref: shift patterns1128440
! Ref: prologue instruction pattern1190927
! Ref: window_save instruction pattern1191420
! Ref: epilogue instruction pattern1191697
! Node: Pattern Ordering1214922
! Node: Dependent Patterns1216158
! Node: Jump Patterns1217778
! Node: Looping Patterns1219455
! Node: Insn Canonicalizations1225094
! Node: Expander Definitions1230291
! Node: Insn Splitting1238504
! Node: Including Patterns1253595
! Node: Peephole Definitions1255372
! Node: define_peephole1256625
! Node: define_peephole21262955
! Node: Insn Attributes1267044
! Node: Defining Attributes1268141
! Ref: define_enum_attr1271633
! Node: Expressions1272669
! Node: Tagging Insns1279419
! Node: Attr Example1283772
! Node: Insn Lengths1286145
! Node: Constant Attributes1289557
! Node: Mnemonic Attribute1290733
! Node: Delay Slots1292252
! Node: Processor pipeline description1295475
! Ref: Processor pipeline description-Footnote-11314287
! Node: Conditional Execution1314611
! Node: Define Subst1318094
! Node: Define Subst Example1320129
! Node: Define Subst Pattern Matching1323124
! Node: Define Subst Output Template1324350
! Node: Constant Definitions1326673
! Ref: define_enum1330532
! Node: Iterators1331020
! Node: Mode Iterators1331665
! Node: Defining Mode Iterators1332643
! Node: Substitutions1334137
! Node: Examples1336379
! Node: Code Iterators1337839
! Node: Int Iterators1340969
! Node: Subst Iterators1343433
! Node: Parameterized Names1345153
! Node: Target Macros1349171
! Node: Target Structure1352234
! Node: Driver1354726
! Node: Run-time Target1373699
! Node: Per-Function Data1384356
! Node: Storage Layout1387120
! Node: Type Layout1415539
! Node: Registers1428881
! Node: Register Basics1429855
! Node: Allocation Order1437417
! Node: Values in Registers1439901
! Node: Leaf Functions1447377
! Node: Stack Registers1450236
! Node: Register Classes1451509
! Node: Stack and Calling1486286
! Node: Frame Layout1486892
! Node: Exception Handling1498986
! Node: Stack Checking1505196
! Node: Frame Registers1510822
! Node: Elimination1519368
! Node: Stack Arguments1523224
! Node: Register Arguments1530677
! Node: Scalar Return1555237
! Node: Aggregate Return1561693
! Node: Caller Saves1566423
! Node: Function Entry1567165
! Node: Profiling1578717
! Node: Tail Calls1580827
! Node: Shrink-wrapping separate components1582737
! Node: Stack Smashing Protection1585778
! Node: Miscellaneous Register Hooks1588267
! Node: Varargs1589132
! Node: Trampolines1597226
! Node: Library Calls1606919
! Node: Addressing Modes1612006
! Node: Anchored Addresses1643497
! Node: Condition Code1646140
! Node: MODE_CC Condition Codes1647985
! Node: Costs1654748
! Node: Scheduling1677068
! Node: Sections1700990
! Node: PIC1717360
! Node: Assembler Format1719419
! Node: File Framework1720557
! Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1728156
! Node: Data Output1729831
! Node: Uninitialized Data1738119
! Node: Label Output1743134
! Node: Initialization1767747
! Node: Macros for Initialization1773708
! Node: Instruction Output1780859
! Node: Dispatch Tables1791489
! Node: Exception Region Output1797240
! Node: Alignment Output1804322
! Node: Debugging Info1808009
! Node: All Debuggers1808559
! Node: DWARF1811492
! Node: VMS Debug1817267
! Node: CTF Debug1817864
! Node: BTF Debug1818225
! Node: Floating Point1818568
! Node: Mode Switching1821323
! Node: Target Attributes1825760
! Node: Emulated TLS1837163
! Node: MIPS Coprocessors1840553
! Node: PCH Target1841712
! Node: C++ ABI1843554
! Node: D Language and ABI1848346
! Node: Named Address Spaces1851570
! Node: Misc1857497
! Ref: TARGET_SHIFT_TRUNCATION_MASK1865368
! Node: Host Config1926377
! Node: Host Common1927446
! Node: Filesystem1929820
! Node: Host Misc1933935
! Node: Fragments1936384
! Node: Target Fragment1937579
! Node: Host Fragment1948391
! Node: Collect21948631
! Node: Header Dirs1951267
! Node: Type Information1952690
! Node: GTY Options1956221
! Node: Inheritance and GTY1968652
! Ref: Inheritance and GTY-Footnote-11970217
! Node: User GC1970487
! Node: GGC Roots1974238
! Node: Files1974951
! Node: Invoking the garbage collector1977582
! Node: Troubleshooting1979224
! Node: Plugins1980299
! Node: Plugins loading1981428
! Node: Plugin API1982527
! Node: Plugins pass1990394
! Node: Plugins GC1992365
! Node: Plugins description1994082
! Node: Plugins attr1994618
! Node: Plugins recording1996898
! Node: Plugins gate1997748
! Node: Plugins tracking1998339
! Node: Plugins building1998927
! Node: LTO2002430
! Node: LTO Overview2003302
! Node: LTO object file layout2009058
! Node: IPA2013557
! Node: WHOPR2022609
! Node: Internal flags2027169
! Node: Match and Simplify2028580
! Node: GIMPLE API2029550
! Node: The Language2032352
! Node: Static Analyzer2044979
! Node: Analyzer Internals2045244
! Node: Debugging the Analyzer2061014
! Node: User Experience Guidelines2068381
! Node: Guidelines for Diagnostics2069317
! Ref: input_location_example2077492
! Node: Guidelines for Options2087177
! Node: Funding2087354
! Node: GNU Project2089861
! Node: Copying2090512
! Node: GNU Free Documentation License2128029
! Node: Contributors2153155
! Node: Option Index2194238
! Node: Concept Index2195115
  
  End Tag Table
  
--- 58262,58721 ----
  
  
  Tag Table:
! Node: Top1787
! Node: Contributing5194
! Node: Portability5929
! Node: Interface7733
! Node: Libgcc10798
! Node: Integer library routines12713
! Node: Soft float library routines19701
! Node: Decimal float library routines31657
! Node: Fixed-point fractional library routines47415
! Node: Exception handling routines147975
! Node: Miscellaneous routines149082
! Node: Languages151218
! Node: Source Tree152775
! Node: Configure Terms153362
! Node: Top Level156402
! Node: gcc Directory160676
! Node: Subdirectories161652
! Node: Configuration163944
! Node: Config Fragments164724
! Node: System Config166013
! Node: Configuration Files166973
! Node: Build169781
! Node: Makefile170197
! Ref: Makefile-Footnote-1177631
! Ref: Makefile-Footnote-2177782
! Node: Library Files177860
! Node: Headers178442
! Node: Documentation180637
! Node: Texinfo Manuals181512
! Node: Man Page Generation183965
! Node: Miscellaneous Docs185745
! Node: Front End187200
! Node: Front End Directory191054
! Node: Front End Config192423
! Node: Front End Makefile195376
! Node: Back End199344
! Node: Testsuites204474
! Node: Test Idioms205463
! Node: Test Directives208925
! Node: Directives209464
! Node: Selectors222484
! Node: Effective-Target Keywords225942
! Ref: arm_fp_ok242335
! Ref: arm_fp_dp_ok242514
! Ref: arm_neon_ok243603
! Ref: arm_neon_ok_no_float_abi243780
! Ref: arm_neonv2_ok243955
! Ref: arm_fp16_ok244130
! Ref: arm_neon_fp16_ok244480
! Ref: arm_vfp3_ok245468
! Ref: arm_arch_v8a_hard_ok245619
! Ref: arm_v8_1a_neon_ok246409
! Ref: arm_v8_2a_fp16_scalar_ok246849
! Ref: arm_v8_2a_fp16_neon_ok247308
! Ref: arm_v8_2a_dotprod_neon_ok247791
! Ref: arm_fp16fml_neon_ok248448
! Ref: arm_coproc1_ok251262
! Ref: arm_coproc2_ok251412
! Ref: arm_coproc3_ok251672
! Ref: arm_simd32_ok252063
! Ref: arm_sat_ok252248
! Ref: arm_dsp_ok252437
! Ref: arm_softfp_ok252622
! Ref: arm_hard_ok252703
! Ref: arm_mve252778
! Ref: arm_v8_1_lob_ok252855
! Ref: default_packed267338
! Ref: stack_size_et270794
! Node: Add Options273701
! Ref: arm_fp16_ieee274975
! Ref: arm_fp16_alternative275234
! Ref: stack_size_ao277878
! Node: Require Support278346
! Node: Final Actions281408
! Node: Ada Tests291970
! Node: C Tests293169
! Node: LTO Testing297681
! Node: gcov Testing299396
! Node: profopt Testing302434
! Node: compat Testing304197
! Node: Torture Tests308553
! Node: GIMPLE Tests310261
! Node: RTL Tests311531
! Node: Options312853
! Node: Option file format313298
! Node: Option properties322042
! Node: Passes339863
! Node: Parsing pass340736
! Node: Gimplification pass344284
! Node: Pass manager346154
! Node: IPA passes348016
! Node: Small IPA passes348909
! Node: Regular IPA passes352513
! Node: Late IPA passes357479
! Node: Tree SSA passes358462
! Node: RTL passes381180
! Node: Optimization info393821
! Node: Dump setup394640
! Node: Optimization groups395802
! Node: Dump files and streams396837
! Node: Dump output verbosity398079
! Node: Dump types399151
! Node: Dump examples401584
! Node: poly_int403113
! Node: Overview of poly_int404625
! Node: Consequences of using poly_int407349
! Node: Comparisons involving poly_int409016
! Node: Comparison functions for poly_int410674
! Node: Properties of the poly_int comparisons411917
! Node: Comparing potentially-unordered poly_ints414481
! Node: Comparing ordered poly_ints415404
! Node: Checking for a poly_int marker value417494
! Node: Range checks on poly_ints418363
! Node: Sorting poly_ints421069
! Node: Arithmetic on poly_ints421866
! Node: Using poly_int with C++ arithmetic operators422679
! Node: wi arithmetic on poly_ints424254
! Node: Division of poly_ints425122
! Node: Other poly_int arithmetic426697
! Node: Alignment of poly_ints428143
! Node: Computing bounds on poly_ints431504
! Node: Converting poly_ints432929
! Node: Miscellaneous poly_int routines436680
! Node: Guidelines for using poly_int437344
! Node: GENERIC442402
! Node: Deficiencies444244
! Node: Tree overview444485
! Node: Macros and Functions448685
! Node: Identifiers449570
! Node: Containers451271
! Node: Types452496
! Node: Declarations465631
! Node: Working with declarations466130
! Node: Internal structure472046
! Node: Current structure hierarchy472434
! Node: Adding new DECL node types474663
! Node: Attributes479121
! Node: Expression trees480405
! Node: Constant expressions482175
! Node: Storage References488527
! Node: Unary and Binary Expressions492468
! Node: Vectors514613
! Node: Statements523355
! Node: Basic Statements523895
! Node: Blocks528946
! Node: Statement Sequences530691
! Node: Empty Statements531032
! Node: Jumps531614
! Node: Cleanups532307
! Node: OpenMP534384
! Node: OpenACC542533
! Node: Functions543746
! Node: Function Basics544221
! Node: Function Properties548013
! Node: Language-dependent trees550886
! Node: C and C++ Trees551781
! Node: Types for C++554674
! Node: Namespaces559956
! Node: Classes563202
! Node: Functions for C++568410
! Node: Statements for C and C++574991
! Node: C++ Expressions583918
! Node: GIMPLE585533
! Node: Tuple representation589246
! Node: Class hierarchy of GIMPLE statements596566
! Node: GIMPLE instruction set601562
! Node: GIMPLE Exception Handling603310
! Node: Temporaries605258
! Ref: Temporaries-Footnote-1606596
! Node: Operands606661
! Node: Compound Expressions607434
! Node: Compound Lvalues607668
! Node: Conditional Expressions608450
! Node: Logical Operators609129
! Node: Manipulating GIMPLE statements616642
! Node: Tuple specific accessors622500
! Node: GIMPLE_ASM623279
! Node: GIMPLE_ASSIGN625818
! Node: GIMPLE_BIND630738
! Node: GIMPLE_CALL632660
! Node: GIMPLE_CATCH637009
! Node: GIMPLE_COND638223
! Node: GIMPLE_DEBUG641178
! Node: GIMPLE_EH_FILTER645956
! Node: GIMPLE_LABEL647579
! Node: GIMPLE_GOTO648232
! Node: GIMPLE_NOP648779
! Node: GIMPLE_OMP_ATOMIC_LOAD649161
! Node: GIMPLE_OMP_ATOMIC_STORE650189
! Node: GIMPLE_OMP_CONTINUE650900
! Node: GIMPLE_OMP_CRITICAL652427
! Node: GIMPLE_OMP_FOR653465
! Node: GIMPLE_OMP_MASTER657113
! Node: GIMPLE_OMP_ORDERED657503
! Node: GIMPLE_OMP_PARALLEL657918
! Node: GIMPLE_OMP_RETURN660861
! Node: GIMPLE_OMP_SECTION661538
! Node: GIMPLE_OMP_SECTIONS662234
! Node: GIMPLE_OMP_SINGLE663924
! Node: GIMPLE_PHI664918
! Node: GIMPLE_RESX666293
! Node: GIMPLE_RETURN667044
! Node: GIMPLE_SWITCH667646
! Node: GIMPLE_TRY669583
! Node: GIMPLE_WITH_CLEANUP_EXPR671447
! Node: GIMPLE sequences672366
! Node: Sequence iterators675712
! Node: Adding a new GIMPLE statement code684507
! Node: Statement and operand traversals685916
! Node: Tree SSA688668
! Node: Annotations690456
! Node: SSA Operands690869
! Node: SSA705041
! Node: Alias analysis715000
! Node: Memory model718869
! Node: RTL720228
! Node: RTL Objects722474
! Node: RTL Classes726422
! Node: Accessors732172
! Node: Special Accessors734421
! Node: Flags740464
! Node: Machine Modes756655
! Node: Constants775202
! Node: Regs and Memory787499
! Node: Arithmetic805364
! Node: Comparisons816207
! Node: Bit-Fields820045
! Node: Vector Operations821636
! Node: Conversions823776
! Node: RTL Declarations828346
! Node: Side Effects829210
! Node: Incdec846209
! Node: Assembler849633
! Node: Debug Information851230
! Node: Insns853221
! Node: Calls880266
! Node: RTL SSA882939
! Node: Using RTL SSA884334
! Node: RTL SSA Instructions886275
! Ref: RTL SSA Instructions-Footnote-1887673
! Node: RTL SSA Basic Blocks887807
! Ref: real RTL SSA insns888287
! Ref: RTL SSA Basic Blocks-Footnote-1890561
! Node: RTL SSA Resources890703
! Node: RTL SSA Accesses891832
! Ref: RTL SSA Accesses-Footnote-1893577
! Node: RTL SSA Phi Nodes893724
! Node: RTL SSA Access Lists895736
! Node: Changing RTL Instructions900083
! Node: Changing One RTL SSA Instruction900692
! Node: Changing Multiple RTL SSA Instructions905718
! Node: Sharing910001
! Node: Reading RTL913259
! Node: Control Flow914267
! Node: Basic Blocks916063
! Node: Edges921737
! Node: Profile information930584
! Node: Maintaining the CFG935352
! Node: Liveness information941296
! Node: Loop Analysis and Representation943495
! Node: Loop representation944531
! Node: Loop querying952141
! Node: Loop manipulation955108
! Node: LCSSA957530
! Node: Scalar evolutions959613
! Node: loop-iv962917
! Node: Number of iterations964925
! Node: Dependency analysis969122
! Node: Machine Desc975686
! Node: Overview978273
! Node: Patterns980373
! Node: Example985436
! Node: RTL Template986913
! Node: Output Template997797
! Node: Output Statement1002102
! Node: Predicates1006525
! Node: Machine-Independent Predicates1009523
! Node: Defining Predicates1014624
! Node: Constraints1020805
! Node: Simple Constraints1022290
! Node: Multi-Alternative1035452
! Node: Class Preferences1038740
! Node: Modifiers1039648
! Node: Machine Constraints1044502
! Node: Disable Insn Alternatives1108619
! Node: Define Constraints1112183
! Node: C Constraint Interface1121032
! Node: Standard Names1124243
! Ref: shift patterns1167515
! Ref: prologue instruction pattern1231758
! Ref: window_save instruction pattern1232263
! Ref: epilogue instruction pattern1232544
! Node: Pattern Ordering1256321
! Node: Dependent Patterns1257557
! Node: Jump Patterns1259185
! Node: Looping Patterns1260870
! Node: Insn Canonicalizations1266617
! Node: Expander Definitions1272070
! Node: Insn Splitting1280497
! Node: Including Patterns1295874
! Node: Peephole Definitions1297679
! Node: define_peephole1298952
! Node: define_peephole21305382
! Node: Insn Attributes1309563
! Node: Defining Attributes1310668
! Ref: define_enum_attr1314270
! Node: Expressions1315322
! Node: Tagging Insns1322364
! Node: Attr Example1326837
! Node: Insn Lengths1329222
! Node: Constant Attributes1332698
! Node: Mnemonic Attribute1333894
! Node: Delay Slots1335433
! Node: Processor pipeline description1338688
! Ref: Processor pipeline description-Footnote-11357828
! Node: Conditional Execution1358152
! Node: Define Subst1361711
! Node: Define Subst Example1363802
! Node: Define Subst Pattern Matching1366857
! Node: Define Subst Output Template1368171
! Node: Constant Definitions1370594
! Ref: define_enum1374521
! Node: Iterators1375021
! Node: Mode Iterators1375666
! Node: Defining Mode Iterators1376688
! Node: Substitutions1378266
! Node: Examples1380582
! Node: Code Iterators1382050
! Node: Int Iterators1385224
! Node: Subst Iterators1387688
! Node: Parameterized Names1389440
! Node: Target Macros1393558
! Node: Target Structure1396693
! Node: Driver1399313
! Node: Run-time Target1418858
! Node: Per-Function Data1429747
! Node: Storage Layout1432567
! Node: Type Layout1461502
! Node: Registers1475320
! Node: Register Basics1476294
! Node: Allocation Order1484060
! Node: Values in Registers1486560
! Node: Leaf Functions1494124
! Node: Stack Registers1497013
! Node: Register Classes1498290
! Node: Stack and Calling1533611
! Node: Frame Layout1534217
! Node: Exception Handling1546517
! Node: Stack Checking1552847
! Node: Frame Registers1558509
! Node: Elimination1567219
! Node: Stack Arguments1571139
! Node: Register Arguments1578684
! Node: Scalar Return1603726
! Node: Aggregate Return1610294
! Node: Caller Saves1615128
! Node: Function Entry1615874
! Node: Profiling1627586
! Node: Tail Calls1629732
! Node: Shrink-wrapping separate components1631650
! Node: Stack Smashing Protection1634739
! Node: Miscellaneous Register Hooks1637260
! Node: Varargs1638125
! Node: Trampolines1646431
! Node: Library Calls1656204
! Node: Addressing Modes1661401
! Node: Anchored Addresses1693278
! Node: Condition Code1695997
! Node: MODE_CC Condition Codes1697854
! Node: Costs1704709
! Node: Scheduling1727405
! Node: Sections1751447
! Node: PIC1768157
! Node: Assembler Format1770252
! Node: File Framework1771390
! Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1779101
! Node: Data Output1780800
! Node: Uninitialized Data1789216
! Node: Label Output1794307
! Node: Initialization1819408
! Node: Macros for Initialization1825587
! Node: Instruction Output1832906
! Node: Dispatch Tables1843760
! Node: Exception Region Output1849571
! Node: Alignment Output1856813
! Node: Debugging Info1860572
! Node: All Debuggers1861122
! Node: DWARF1864103
! Node: VMS Debug1869954
! Node: CTF Debug1870571
! Node: BTF Debug1870936
! Node: Floating Point1871283
! Node: Mode Switching1874050
! Node: Target Attributes1878565
! Node: Emulated TLS1890168
! Node: MIPS Coprocessors1893586
! Node: PCH Target1894749
! Node: C++ ABI1896631
! Node: D Language and ABI1901493
! Node: Named Address Spaces1904801
! Node: Misc1910812
! Ref: TARGET_SHIFT_TRUNCATION_MASK1918811
! Node: Host Config1980960
! Node: Host Common1982053
! Node: Filesystem1984443
! Node: Host Misc1988662
! Node: Fragments1991231
! Node: Target Fragment1992478
! Node: Host Fragment2003706
! Node: Collect22003950
! Node: Header Dirs2006780
! Node: Type Information2008247
! Node: GTY Options2011848
! Node: Inheritance and GTY2024675
! Ref: Inheritance and GTY-Footnote-12026250
! Node: User GC2026520
! Node: GGC Roots2030379
! Node: Files2031122
! Node: Invoking the garbage collector2033841
! Node: Troubleshooting2035515
! Node: Plugins2036614
! Node: Plugins loading2037743
! Node: Plugin API2038894
! Node: Plugins pass2046909
! Node: Plugins GC2048892
! Node: Plugins description2050677
! Node: Plugins attr2051225
! Node: Plugins recording2053549
! Node: Plugins gate2054427
! Node: Plugins tracking2055026
! Node: Plugins building2055622
! Node: LTO2059233
! Node: LTO Overview2060109
! Node: LTO object file layout2065981
! Node: IPA2070660
! Node: WHOPR2079868
! Node: Internal flags2084492
! Node: Match and Simplify2085927
! Node: GIMPLE API2086897
! Node: The Language2089723
! Node: Static Analyzer2102682
! Node: Analyzer Internals2102947
! Node: Debugging the Analyzer2118957
! Node: User Experience Guidelines2126538
! Node: Guidelines for Diagnostics2127474
! Ref: input_location_example2135755
! Node: Guidelines for Options2145628
! Node: Funding2145805
! Node: GNU Project2148311
! Node: Copying2148962
! Node: GNU Free Documentation License2186494
! Node: Contributors2211623
! Node: Option Index2254066
! Node: Concept Index2254959
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/doc/gcov-dump.1 gcc-13.5.0-RC-20260904/gcc/doc/gcov-dump.1
*** gcc-13.4.0/gcc/doc/gcov-dump.1	Thu Jun  5 16:06:29 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gcov-dump.1	Fri Sep  4 07:36:30 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,223 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GCOV-DUMP 1"
! .TH GCOV-DUMP 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gcov\-dump \- offline gcda and gcno profile dump tool
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
! gcov-dump [\fB\-v\fR|\fB\-\-version\fR]
       [\fB\-h\fR|\fB\-\-help\fR]
       [\fB\-l\fR|\fB\-\-long\fR]
       [\fB\-p\fR|\fB\-\-positions\fR]
       [\fB\-r\fR|\fB\-\-raw\fR]
       [\fB\-s\fR|\fB\-\-stable\fR]
       \fIgcovfiles\fR
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
! \&\fBgcov-dump\fR is a tool you can use in conjunction with \s-1GCC\s0 to
  dump content of gcda and gcno profile files offline.
! .SH "OPTIONS"
  .IX Header "OPTIONS"
! .IP "\fB\-h\fR" 4
  .IX Item "-h"
  .PD 0
! .IP "\fB\-\-help\fR" 4
  .IX Item "--help"
  .PD
! Display help about using \fBgcov-dump\fR (on the standard output), and
  exit without doing any further processing.
! .IP "\fB\-l\fR" 4
  .IX Item "-l"
  .PD 0
! .IP "\fB\-\-long\fR" 4
  .IX Item "--long"
  .PD
  Dump content of records.
! .IP "\fB\-p\fR" 4
  .IX Item "-p"
  .PD 0
! .IP "\fB\-\-positions\fR" 4
  .IX Item "--positions"
  .PD
  Dump positions of records.
! .IP "\fB\-r\fR" 4
  .IX Item "-r"
  .PD 0
! .IP "\fB\-\-raw\fR" 4
  .IX Item "--raw"
  .PD
  Print content records in raw format.
! .IP "\fB\-s\fR" 4
  .IX Item "-s"
  .PD 0
! .IP "\fB\-\-stable\fR" 4
  .IX Item "--stable"
  .PD
  Print content in stable format usable for comparison.
! .IP "\fB\-v\fR" 4
  .IX Item "-v"
  .PD 0
! .IP "\fB\-\-version\fR" 4
  .IX Item "--version"
  .PD
! Display the \fBgcov-dump\fR version number (on the standard output),
  and exit without doing any further processing.
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 2017\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
! Free Software\*(R", the Front-Cover texts being (a) (see below), and with
! the Back-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The \s-1FSF\s0's Front-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The \s-1FSF\s0's Back-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
--- 53,148 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GCOV-DUMP 1"
! .TH GCOV-DUMP 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gcov\-dump \- offline gcda and gcno profile dump tool
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
! gcov\-dump [\fB\-v\fR|\fB\-\-version\fR]
       [\fB\-h\fR|\fB\-\-help\fR]
       [\fB\-l\fR|\fB\-\-long\fR]
       [\fB\-p\fR|\fB\-\-positions\fR]
       [\fB\-r\fR|\fB\-\-raw\fR]
       [\fB\-s\fR|\fB\-\-stable\fR]
       \fIgcovfiles\fR
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
! \&\fBgcov\-dump\fR is a tool you can use in conjunction with GCC to
  dump content of gcda and gcno profile files offline.
! .SH OPTIONS
  .IX Header "OPTIONS"
! .IP \fB\-h\fR 4
  .IX Item "-h"
  .PD 0
! .IP \fB\-\-help\fR 4
  .IX Item "--help"
  .PD
! Display help about using \fBgcov\-dump\fR (on the standard output), and
  exit without doing any further processing.
! .IP \fB\-l\fR 4
  .IX Item "-l"
  .PD 0
! .IP \fB\-\-long\fR 4
  .IX Item "--long"
  .PD
  Dump content of records.
! .IP \fB\-p\fR 4
  .IX Item "-p"
  .PD 0
! .IP \fB\-\-positions\fR 4
  .IX Item "--positions"
  .PD
  Dump positions of records.
! .IP \fB\-r\fR 4
  .IX Item "-r"
  .PD 0
! .IP \fB\-\-raw\fR 4
  .IX Item "--raw"
  .PD
  Print content records in raw format.
! .IP \fB\-s\fR 4
  .IX Item "-s"
  .PD 0
! .IP \fB\-\-stable\fR 4
  .IX Item "--stable"
  .PD
  Print content in stable format usable for comparison.
! .IP \fB\-v\fR 4
  .IX Item "-v"
  .PD 0
! .IP \fB\-\-version\fR 4
  .IX Item "--version"
  .PD
! Display the \fBgcov\-dump\fR version number (on the standard output),
  and exit without doing any further processing.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 2017\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the GNU Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being "GNU General Public License" and "Funding
! Free Software", the Front\-Cover texts being (a) (see below), and with
! the Back\-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The FSF\*(Aqs Front\-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The FSF\*(Aqs Back\-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
diff -Nrcpad gcc-13.4.0/gcc/doc/gcov-tool.1 gcc-13.5.0-RC-20260904/gcc/doc/gcov-tool.1
*** gcc-13.4.0/gcc/doc/gcov-tool.1	Thu Jun  5 16:06:29 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gcov-tool.1	Fri Sep  4 07:36:30 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,239 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GCOV-TOOL 1"
! .TH GCOV-TOOL 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gcov\-tool \- offline gcda profile processing tool
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
! gcov-tool [\fB\-v\fR|\fB\-\-version\fR] [\fB\-h\fR|\fB\-\-help\fR]
  .PP
! gcov-tool merge [merge\-options] \fIdirectory1\fR \fIdirectory2\fR
       [\fB\-o\fR|\fB\-\-output\fR \fIdirectory\fR]
       [\fB\-v\fR|\fB\-\-verbose\fR]
       [\fB\-w\fR|\fB\-\-weight\fR \fIw1,w2\fR]
  .PP
! gcov-tool merge-stream [merge\-stream\-options] [\fIfile\fR]
       [\fB\-v\fR|\fB\-\-verbose\fR]
       [\fB\-w\fR|\fB\-\-weight\fR \fIw1,w2\fR]
  .PP
! gcov-tool rewrite [rewrite\-options] \fIdirectory\fR
       [\fB\-n\fR|\fB\-\-normalize\fR \fIlong_long_value\fR]
       [\fB\-o\fR|\fB\-\-output\fR \fIdirectory\fR]
       [\fB\-s\fR|\fB\-\-scale\fR \fIfloat_or_simple\-frac_value\fR]
       [\fB\-v\fR|\fB\-\-verbose\fR]
  .PP
! gcov-tool overlap [overlap\-options] \fIdirectory1\fR \fIdirectory2\fR
       [\fB\-f\fR|\fB\-\-function\fR]
       [\fB\-F\fR|\fB\-\-fullname\fR]
       [\fB\-h\fR|\fB\-\-hotonly\fR]
       [\fB\-o\fR|\fB\-\-object\fR]
       [\fB\-t\fR|\fB\-\-hot_threshold\fR] \fIfloat\fR
       [\fB\-v\fR|\fB\-\-verbose\fR]
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
! \&\fBgcov-tool\fR is an offline tool to process gcc's gcda profile files.
  .PP
! Current gcov-tool supports the following functionalities:
! .IP "*" 4
  merge two sets of profiles with weights.
! .IP "*" 4
  read a stream of profiles with associated filenames and merge it with a set of
  profiles with weights.
! .IP "*" 4
  read one set of profile and rewrite profile contents. One can scale or
  normalize the count values.
  .PP
  Examples of the use cases for this tool are:
! .IP "*" 4
  Collect the profiles for different set of inputs, and use this tool to merge
  them. One can specify the weight to factor in the relative importance of
  each input.
! .IP "*" 4
  Collect profiles from target systems without a filesystem (freestanding
  environments).  Merge the collected profiles with associated profiles
  present on the host system.  One can specify the weight to factor in the
  relative importance of each input.
! .IP "*" 4
  Rewrite the profile after removing a subset of the gcda files, while maintaining
  the consistency of the summary and the histogram.
! .IP "*" 4
  It can also be used to debug or libgcov code as the tools shares the majority
  code as the runtime library.
  .PP
  Note that for the merging operation, this profile generated offline may
  contain slight different values from the online merged profile. Here are
  a list of typical differences:
! .IP "*" 4
  histogram difference: This offline tool recomputes the histogram after merging
  the counters. The resulting histogram, therefore, is precise. The online
! merging does not have this capability \*(-- the histogram is merged from two
  histograms and the result is an approximation.
! .IP "*" 4
! summary checksum difference: Summary checksum uses a \s-1CRC32\s0 operation. The value
! depends on the link list order of gcov-info objects. This order is different in
! gcov-tool from that in the online merge. It's expected to have different
  summary checksums. It does not really matter as the compiler does not use this
  checksum anywhere.
! .IP "*" 4
  value profile counter values difference: Some counter values for value profile
! are runtime dependent, like heap addresses. It's normal to see some difference
  in these kind of counters.
! .SH "OPTIONS"
  .IX Header "OPTIONS"
! .IP "\fB\-h\fR" 4
  .IX Item "-h"
  .PD 0
! .IP "\fB\-\-help\fR" 4
  .IX Item "--help"
  .PD
! Display help about using \fBgcov-tool\fR (on the standard output), and
  exit without doing any further processing.
! .IP "\fB\-v\fR" 4
  .IX Item "-v"
  .PD 0
! .IP "\fB\-\-version\fR" 4
  .IX Item "--version"
  .PD
! Display the \fBgcov-tool\fR version number (on the standard output),
  and exit without doing any further processing.
! .IP "\fBmerge\fR" 4
  .IX Item "merge"
  Merge two profile directories.
  .RS 4
--- 53,164 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GCOV-TOOL 1"
! .TH GCOV-TOOL 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gcov\-tool \- offline gcda profile processing tool
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
! gcov\-tool [\fB\-v\fR|\fB\-\-version\fR] [\fB\-h\fR|\fB\-\-help\fR]
  .PP
! gcov\-tool merge [merge\-options] \fIdirectory1\fR \fIdirectory2\fR
       [\fB\-o\fR|\fB\-\-output\fR \fIdirectory\fR]
       [\fB\-v\fR|\fB\-\-verbose\fR]
       [\fB\-w\fR|\fB\-\-weight\fR \fIw1,w2\fR]
  .PP
! gcov\-tool merge\-stream [merge\-stream\-options] [\fIfile\fR]
       [\fB\-v\fR|\fB\-\-verbose\fR]
       [\fB\-w\fR|\fB\-\-weight\fR \fIw1,w2\fR]
  .PP
! gcov\-tool rewrite [rewrite\-options] \fIdirectory\fR
       [\fB\-n\fR|\fB\-\-normalize\fR \fIlong_long_value\fR]
       [\fB\-o\fR|\fB\-\-output\fR \fIdirectory\fR]
       [\fB\-s\fR|\fB\-\-scale\fR \fIfloat_or_simple\-frac_value\fR]
       [\fB\-v\fR|\fB\-\-verbose\fR]
  .PP
! gcov\-tool overlap [overlap\-options] \fIdirectory1\fR \fIdirectory2\fR
       [\fB\-f\fR|\fB\-\-function\fR]
       [\fB\-F\fR|\fB\-\-fullname\fR]
       [\fB\-h\fR|\fB\-\-hotonly\fR]
       [\fB\-o\fR|\fB\-\-object\fR]
       [\fB\-t\fR|\fB\-\-hot_threshold\fR] \fIfloat\fR
       [\fB\-v\fR|\fB\-\-verbose\fR]
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
! \&\fBgcov\-tool\fR is an offline tool to process gcc\*(Aqs gcda profile files.
  .PP
! Current gcov\-tool supports the following functionalities:
! .IP * 4
  merge two sets of profiles with weights.
! .IP * 4
  read a stream of profiles with associated filenames and merge it with a set of
  profiles with weights.
! .IP * 4
  read one set of profile and rewrite profile contents. One can scale or
  normalize the count values.
  .PP
  Examples of the use cases for this tool are:
! .IP * 4
  Collect the profiles for different set of inputs, and use this tool to merge
  them. One can specify the weight to factor in the relative importance of
  each input.
! .IP * 4
  Collect profiles from target systems without a filesystem (freestanding
  environments).  Merge the collected profiles with associated profiles
  present on the host system.  One can specify the weight to factor in the
  relative importance of each input.
! .IP * 4
  Rewrite the profile after removing a subset of the gcda files, while maintaining
  the consistency of the summary and the histogram.
! .IP * 4
  It can also be used to debug or libgcov code as the tools shares the majority
  code as the runtime library.
  .PP
  Note that for the merging operation, this profile generated offline may
  contain slight different values from the online merged profile. Here are
  a list of typical differences:
! .IP * 4
  histogram difference: This offline tool recomputes the histogram after merging
  the counters. The resulting histogram, therefore, is precise. The online
! merging does not have this capability \-\- the histogram is merged from two
  histograms and the result is an approximation.
! .IP * 4
! summary checksum difference: Summary checksum uses a CRC32 operation. The value
! depends on the link list order of gcov\-info objects. This order is different in
! gcov\-tool from that in the online merge. It\*(Aqs expected to have different
  summary checksums. It does not really matter as the compiler does not use this
  checksum anywhere.
! .IP * 4
  value profile counter values difference: Some counter values for value profile
! are runtime dependent, like heap addresses. It\*(Aqs normal to see some difference
  in these kind of counters.
! .SH OPTIONS
  .IX Header "OPTIONS"
! .IP \fB\-h\fR 4
  .IX Item "-h"
  .PD 0
! .IP \fB\-\-help\fR 4
  .IX Item "--help"
  .PD
! Display help about using \fBgcov\-tool\fR (on the standard output), and
  exit without doing any further processing.
! .IP \fB\-v\fR 4
  .IX Item "-v"
  .PD 0
! .IP \fB\-\-version\fR 4
  .IX Item "--version"
  .PD
! Display the \fBgcov\-tool\fR version number (on the standard output),
  and exit without doing any further processing.
! .IP \fBmerge\fR 4
  .IX Item "merge"
  Merge two profile directories.
  .RS 4
*************** Merge two profile directories.
*** 245,254 ****
  .PD
  Set the output profile directory. Default output directory name is
  \&\fImerged_profile\fR.
! .IP "\fB\-v\fR" 4
  .IX Item "-v"
  .PD 0
! .IP "\fB\-\-verbose\fR" 4
  .IX Item "--verbose"
  .PD
  Set the verbose mode.
--- 170,179 ----
  .PD
  Set the output profile directory. Default output directory name is
  \&\fImerged_profile\fR.
! .IP \fB\-v\fR 4
  .IX Item "-v"
  .PD 0
! .IP \fB\-\-verbose\fR 4
  .IX Item "--verbose"
  .PD
  Set the verbose mode.
*************** respectively. The default weights are 1
*** 263,269 ****
  .RE
  .RS 4
  .RE
! .IP "\fBmerge-stream\fR" 4
  .IX Item "merge-stream"
  Collect profiles with associated filenames from a \fIgcfn\fR and \fIgcda\fR
  data stream.  Read the stream from the file specified by \fIfile\fR or from
--- 188,194 ----
  .RE
  .RS 4
  .RE
! .IP \fBmerge\-stream\fR 4
  .IX Item "merge-stream"
  Collect profiles with associated filenames from a \fIgcfn\fR and \fIgcda\fR
  data stream.  Read the stream from the file specified by \fIfile\fR or from
*************** For the generation of a \fIgcfn\fR and \
*** 274,283 ****
  system, please have a look at the \f(CW\*(C`_\|_gcov_filename_to_gcfn()\*(C'\fR and
  \&\f(CW\*(C`_\|_gcov_info_to_gcda()\*(C'\fR functions declared in \f(CW\*(C`#include \*(C'\fR.
  .RS 4
! .IP "\fB\-v\fR" 4
  .IX Item "-v"
  .PD 0
! .IP "\fB\-\-verbose\fR" 4
  .IX Item "--verbose"
  .PD
  Set the verbose mode.
--- 199,208 ----
  system, please have a look at the \f(CW\*(C`_\|_gcov_filename_to_gcfn()\*(C'\fR and
  \&\f(CW\*(C`_\|_gcov_info_to_gcda()\*(C'\fR functions declared in \f(CW\*(C`#include \*(C'\fR.
  .RS 4
! .IP \fB\-v\fR 4
  .IX Item "-v"
  .PD 0
! .IP \fB\-\-verbose\fR 4
  .IX Item "--verbose"
  .PD
  Set the verbose mode.
*************** default weights are 1 for both.
*** 293,299 ****
  .RE
  .RS 4
  .RE
! .IP "\fBrewrite\fR" 4
  .IX Item "rewrite"
  Read the specified profile directory and rewrite to a new directory.
  .RS 4
--- 218,224 ----
  .RE
  .RS 4
  .RE
! .IP \fBrewrite\fR 4
  .IX Item "rewrite"
  Read the specified profile directory and rewrite to a new directory.
  .RS 4
*************** Set the output profile directory. Defaul
*** 320,336 ****
  .PD
  Scale the profile counters. The specified value can be in floating point value,
  or simple fraction value form, such 1, 2, 2/3, and 5/3.
! .IP "\fB\-v\fR" 4
  .IX Item "-v"
  .PD 0
! .IP "\fB\-\-verbose\fR" 4
  .IX Item "--verbose"
  .PD
  Set the verbose mode.
  .RE
  .RS 4
  .RE
! .IP "\fBoverlap\fR" 4
  .IX Item "overlap"
  Compute the overlap score between the two specified profile directories.
  The overlap score is computed based on the arc profiles. It is defined as
--- 245,261 ----
  .PD
  Scale the profile counters. The specified value can be in floating point value,
  or simple fraction value form, such 1, 2, 2/3, and 5/3.
! .IP \fB\-v\fR 4
  .IX Item "-v"
  .PD 0
! .IP \fB\-\-verbose\fR 4
  .IX Item "--verbose"
  .PD
  Set the verbose mode.
  .RE
  .RS 4
  .RE
! .IP \fBoverlap\fR 4
  .IX Item "overlap"
  Compute the overlap score between the two specified profile directories.
  The overlap score is computed based on the arc profiles. It is defined as
*************** for all arc counter i, where p1_counter[
*** 339,369 ****
  matched counters and p1_sum_all and p2_sum_all are the sum of counter
  values in profile 1 and profile 2, respectively.
  .RS 4
! .IP "\fB\-f\fR" 4
  .IX Item "-f"
  .PD 0
! .IP "\fB\-\-function\fR" 4
  .IX Item "--function"
  .PD
  Print function level overlap score.
! .IP "\fB\-F\fR" 4
  .IX Item "-F"
  .PD 0
! .IP "\fB\-\-fullname\fR" 4
  .IX Item "--fullname"
  .PD
  Print full gcda filename.
! .IP "\fB\-h\fR" 4
  .IX Item "-h"
  .PD 0
! .IP "\fB\-\-hotonly\fR" 4
  .IX Item "--hotonly"
  .PD
  Only print info for hot objects/functions.
! .IP "\fB\-o\fR" 4
  .IX Item "-o"
  .PD 0
! .IP "\fB\-\-object\fR" 4
  .IX Item "--object"
  .PD
  Print object level overlap score.
--- 264,294 ----
  matched counters and p1_sum_all and p2_sum_all are the sum of counter
  values in profile 1 and profile 2, respectively.
  .RS 4
! .IP \fB\-f\fR 4
  .IX Item "-f"
  .PD 0
! .IP \fB\-\-function\fR 4
  .IX Item "--function"
  .PD
  Print function level overlap score.
! .IP \fB\-F\fR 4
  .IX Item "-F"
  .PD 0
! .IP \fB\-\-fullname\fR 4
  .IX Item "--fullname"
  .PD
  Print full gcda filename.
! .IP \fB\-h\fR 4
  .IX Item "-h"
  .PD 0
! .IP \fB\-\-hotonly\fR 4
  .IX Item "--hotonly"
  .PD
  Only print info for hot objects/functions.
! .IP \fB\-o\fR 4
  .IX Item "-o"
  .PD 0
! .IP \fB\-\-object\fR 4
  .IX Item "--object"
  .PD
  Print object level overlap score.
*************** Print object level overlap score.
*** 374,383 ****
  .IX Item "--hot_threshold "
  .PD
  Set the threshold for hot counter value.
! .IP "\fB\-v\fR" 4
  .IX Item "-v"
  .PD 0
! .IP "\fB\-\-verbose\fR" 4
  .IX Item "--verbose"
  .PD
  Set the verbose mode.
--- 299,308 ----
  .IX Item "--hot_threshold "
  .PD
  Set the threshold for hot counter value.
! .IP \fB\-v\fR 4
  .IX Item "-v"
  .PD 0
! .IP \fB\-\-verbose\fR 4
  .IX Item "--verbose"
  .PD
  Set the verbose mode.
*************** Set the verbose mode.
*** 388,412 ****
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7), \fBgcc\fR\|(1), \fBgcov\fR\|(1) and the Info entry for
  \&\fIgcc\fR.
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 2014\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
! Free Software\*(R", the Front-Cover texts being (a) (see below), and with
! the Back-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The \s-1FSF\s0's Front-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The \s-1FSF\s0's Back-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
--- 313,337 ----
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7), \fBgcc\fR\|(1), \fBgcov\fR\|(1) and the Info entry for
  \&\fIgcc\fR.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 2014\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the GNU Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being "GNU General Public License" and "Funding
! Free Software", the Front\-Cover texts being (a) (see below), and with
! the Back\-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The FSF\*(Aqs Front\-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The FSF\*(Aqs Back\-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
diff -Nrcpad gcc-13.4.0/gcc/doc/gcov.1 gcc-13.5.0-RC-20260904/gcc/doc/gcov.1
*** gcc-13.4.0/gcc/doc/gcov.1	Thu Jun  5 16:06:29 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gcov.1	Fri Sep  4 07:36:30 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,146 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GCOV 1"
! .TH GCOV 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gcov \- coverage testing tool
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
  gcov [\fB\-v\fR|\fB\-\-version\fR] [\fB\-h\fR|\fB\-\-help\fR]
       [\fB\-a\fR|\fB\-\-all\-blocks\fR]
--- 53,71 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GCOV 1"
! .TH GCOV 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gcov \- coverage testing tool
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
  gcov [\fB\-v\fR|\fB\-\-version\fR] [\fB\-h\fR|\fB\-\-help\fR]
       [\fB\-a\fR|\fB\-\-all\-blocks\fR]
*************** gcov [\fB\-v\fR|\fB\-\-version\fR] [\fB\
*** 163,171 ****
       [\fB\-u\fR|\fB\-\-unconditional\-branches\fR]
       [\fB\-x\fR|\fB\-\-hash\-filenames\fR]
       \fIfiles\fR
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
! \&\fBgcov\fR is a test coverage program.  Use it in concert with \s-1GCC\s0
  to analyze your programs to help create more efficient, faster running
  code and to discover untested parts of your program.  You can use
  \&\fBgcov\fR as a profiling tool to help discover where your
--- 88,96 ----
       [\fB\-u\fR|\fB\-\-unconditional\-branches\fR]
       [\fB\-x\fR|\fB\-\-hash\-filenames\fR]
       \fIfiles\fR
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
! \&\fBgcov\fR 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
  \&\fBgcov\fR as a profiling tool to help discover where your
*************** optimization efforts will best affect yo
*** 174,187 ****
  assess which parts of your code use the greatest amount of computing
  time.
  .PP
! Profiling tools help you analyze your code's performance.  Using a
  profiler such as \fBgcov\fR or \fBgprof\fR, you can find out some
  basic performance statistics, such as:
! .IP "*" 4
  how often each line of code executes
! .IP "*" 4
  what lines of code are actually executed
! .IP "*" 4
  how much computing time each section of code uses
  .PP
  Once you know these things about how your code works when compiled, you
--- 99,112 ----
  assess which parts of your code use the greatest amount of computing
  time.
  .PP
! Profiling tools help you analyze your code\*(Aqs performance.  Using a
  profiler such as \fBgcov\fR or \fBgprof\fR, you can find out some
  basic performance statistics, such as:
! .IP * 4
  how often each line of code executes
! .IP * 4
  what lines of code are actually executed
! .IP * 4
  how much computing time each section of code uses
  .PP
  Once you know these things about how your code works when compiled, you
*************** final product.
*** 199,205 ****
  You should compile your code without optimization if you plan to use
  \&\fBgcov\fR because the optimization, by combining some lines of code
  into one function, may not give you as much information as you need to
! look for `hot spots' where the code is using a great deal of computer
  time.  Likewise, because \fBgcov\fR accumulates statistics by line (at
  the lowest resolution), it works best with a programming style that
  places only one statement on each line.  If you use complicated macros
--- 124,130 ----
  You should compile your code without optimization if you plan to use
  \&\fBgcov\fR because the optimization, by combining some lines of code
  into one function, may not give you as much information as you need to
! look for \`hot spots\*(Aq where the code is using a great deal of computer
  time.  Likewise, because \fBgcov\fR accumulates statistics by line (at
  the lowest resolution), it works best with a programming style that
  places only one statement on each line.  If you use complicated macros
*************** less helpful\-\-\-they only report on th
*** 208,286 ****
  appears.  If your complex macros behave like functions, you can replace
  them with inline functions to solve this problem.
  .PP
! \&\fBgcov\fR creates a logfile called \fI\fIsourcefile\fI.gcov\fR which
! indicates how many times each line of a source file \fI\fIsourcefile\fI.c\fR
  has executed.  You can use these logfiles along with \fBgprof\fR to aid
! in fine-tuning the performance of your programs.  \fBgprof\fR gives
  timing information you can use along with the information you get from
  \&\fBgcov\fR.
  .PP
! \&\fBgcov\fR works only on code compiled with \s-1GCC.\s0  It is not
  compatible with any other profiling or test coverage mechanism.
! .SH "OPTIONS"
  .IX Header "OPTIONS"
! .IP "\fB\-a\fR" 4
  .IX Item "-a"
  .PD 0
! .IP "\fB\-\-all\-blocks\fR" 4
  .IX Item "--all-blocks"
  .PD
  Write individual execution counts for every basic block.  Normally gcov
  outputs execution counts only for the main blocks of a line.  With this
  option you can determine if blocks within a single line are not being
  executed.
! .IP "\fB\-b\fR" 4
  .IX Item "-b"
  .PD 0
! .IP "\fB\-\-branch\-probabilities\fR" 4
  .IX Item "--branch-probabilities"
  .PD
  Write branch frequencies to the output file, and write branch summary
  info to the standard output.  This option allows you to see how often
  each branch in your program was taken.  Unconditional branches will not
  be shown, unless the \fB\-u\fR option is given.
! .IP "\fB\-c\fR" 4
  .IX Item "-c"
  .PD 0
! .IP "\fB\-\-branch\-counts\fR" 4
  .IX Item "--branch-counts"
  .PD
  Write branch frequencies as the number of branches taken, rather than
  the percentage of branches taken.
! .IP "\fB\-d\fR" 4
  .IX Item "-d"
  .PD 0
! .IP "\fB\-\-display\-progress\fR" 4
  .IX Item "--display-progress"
  .PD
  Display the progress on the standard output.
! .IP "\fB\-f\fR" 4
  .IX Item "-f"
  .PD 0
! .IP "\fB\-\-function\-summaries\fR" 4
  .IX Item "--function-summaries"
  .PD
  Output summaries for each function in addition to the file level summary.
! .IP "\fB\-h\fR" 4
  .IX Item "-h"
  .PD 0
! .IP "\fB\-\-help\fR" 4
  .IX Item "--help"
  .PD
  Display help about using \fBgcov\fR (on the standard output), and
  exit without doing any further processing.
! .IP "\fB\-j\fR" 4
  .IX Item "-j"
  .PD 0
! .IP "\fB\-\-json\-format\fR" 4
  .IX Item "--json-format"
  .PD
! Output gcov file in an easy-to-parse \s-1JSON\s0 intermediate format
! which does not require source code for generation.  The \s-1JSON\s0
  file is compressed with gzip compression algorithm
  and the files have \fI.gcov.json.gz\fR extension.
  .Sp
! Structure of the \s-1JSON\s0 is following:
  .Sp
  .Vb 7
  \&        {
--- 133,211 ----
  appears.  If your complex macros behave like functions, you can replace
  them with inline functions to solve this problem.
  .PP
! \&\fBgcov\fR creates a logfile called \fIsourcefile.gcov\fR which
! indicates how many times each line of a source file \fIsourcefile.c\fR
  has executed.  You can use these logfiles along with \fBgprof\fR to aid
! in fine\-tuning the performance of your programs.  \fBgprof\fR gives
  timing information you can use along with the information you get from
  \&\fBgcov\fR.
  .PP
! \&\fBgcov\fR works only on code compiled with GCC.  It is not
  compatible with any other profiling or test coverage mechanism.
! .SH OPTIONS
  .IX Header "OPTIONS"
! .IP \fB\-a\fR 4
  .IX Item "-a"
  .PD 0
! .IP \fB\-\-all\-blocks\fR 4
  .IX Item "--all-blocks"
  .PD
  Write individual execution counts for every basic block.  Normally gcov
  outputs execution counts only for the main blocks of a line.  With this
  option you can determine if blocks within a single line are not being
  executed.
! .IP \fB\-b\fR 4
  .IX Item "-b"
  .PD 0
! .IP \fB\-\-branch\-probabilities\fR 4
  .IX Item "--branch-probabilities"
  .PD
  Write branch frequencies to the output file, and write branch summary
  info to the standard output.  This option allows you to see how often
  each branch in your program was taken.  Unconditional branches will not
  be shown, unless the \fB\-u\fR option is given.
! .IP \fB\-c\fR 4
  .IX Item "-c"
  .PD 0
! .IP \fB\-\-branch\-counts\fR 4
  .IX Item "--branch-counts"
  .PD
  Write branch frequencies as the number of branches taken, rather than
  the percentage of branches taken.
! .IP \fB\-d\fR 4
  .IX Item "-d"
  .PD 0
! .IP \fB\-\-display\-progress\fR 4
  .IX Item "--display-progress"
  .PD
  Display the progress on the standard output.
! .IP \fB\-f\fR 4
  .IX Item "-f"
  .PD 0
! .IP \fB\-\-function\-summaries\fR 4
  .IX Item "--function-summaries"
  .PD
  Output summaries for each function in addition to the file level summary.
! .IP \fB\-h\fR 4
  .IX Item "-h"
  .PD 0
! .IP \fB\-\-help\fR 4
  .IX Item "--help"
  .PD
  Display help about using \fBgcov\fR (on the standard output), and
  exit without doing any further processing.
! .IP \fB\-j\fR 4
  .IX Item "-j"
  .PD 0
! .IP \fB\-\-json\-format\fR 4
  .IX Item "--json-format"
  .PD
! Output gcov file in an easy\-to\-parse JSON intermediate format
! which does not require source code for generation.  The JSON
  file is compressed with gzip compression algorithm
  and the files have \fI.gcov.json.gz\fR extension.
  .Sp
! Structure of the JSON is following:
  .Sp
  .Vb 7
  \&        {
*************** Structure of the \s-1JSON\s0 is followin
*** 294,308 ****
  .Sp
  Fields of the root element have following semantics:
  .RS 4
! .IP "*" 4
  \&\fIcurrent_working_directory\fR: working directory where
  a compilation unit was compiled
! .IP "*" 4
! \&\fIdata_file\fR: name of the data file (\s-1GCDA\s0)
! .IP "*" 4
  \&\fIformat_version\fR: semantic version of the format
! .IP "*" 4
! \&\fIgcc_version\fR: version of the \s-1GCC\s0 compiler
  .RE
  .RS 4
  .Sp
--- 219,233 ----
  .Sp
  Fields of the root element have following semantics:
  .RS 4
! .IP * 4
  \&\fIcurrent_working_directory\fR: working directory where
  a compilation unit was compiled
! .IP * 4
! \&\fIdata_file\fR: name of the data file (GCDA)
! .IP * 4
  \&\fIformat_version\fR: semantic version of the format
! .IP * 4
! \&\fIgcc_version\fR: version of the GCC compiler
  .RE
  .RS 4
  .Sp
*************** Each \fIfile\fR has the following form:
*** 317,323 ****
  .Ve
  .Sp
  Fields of the \fIfile\fR element have following semantics:
! .IP "*" 4
  \&\fIfile_name\fR: name of the source file
  .RE
  .RS 4
--- 242,248 ----
  .Ve
  .Sp
  Fields of the \fIfile\fR element have following semantics:
! .IP * 4
  \&\fIfile_name\fR: name of the source file
  .RE
  .RS 4
*************** Each \fIfunction\fR has the following fo
*** 339,361 ****
  .Ve
  .Sp
  Fields of the \fIfunction\fR element have following semantics:
! .IP "*" 4
  \&\fIblocks\fR: number of blocks that are in the function
! .IP "*" 4
  \&\fIblocks_executed\fR: number of executed blocks of the function
! .IP "*" 4
  \&\fIdemangled_name\fR: demangled name of the function
! .IP "*" 4
  \&\fIend_column\fR: column in the source file where the function ends
! .IP "*" 4
  \&\fIend_line\fR: line in the source file where the function ends
! .IP "*" 4
  \&\fIexecution_count\fR: number of executions of the function
! .IP "*" 4
  \&\fIname\fR: name of the function
! .IP "*" 4
  \&\fIstart_column\fR: column in the source file where the function begins
! .IP "*" 4
  \&\fIstart_line\fR: line in the source file where the function begins
  .RE
  .RS 4
--- 264,286 ----
  .Ve
  .Sp
  Fields of the \fIfunction\fR element have following semantics:
! .IP * 4
  \&\fIblocks\fR: number of blocks that are in the function
! .IP * 4
  \&\fIblocks_executed\fR: number of executed blocks of the function
! .IP * 4
  \&\fIdemangled_name\fR: demangled name of the function
! .IP * 4
  \&\fIend_column\fR: column in the source file where the function ends
! .IP * 4
  \&\fIend_line\fR: line in the source file where the function ends
! .IP * 4
  \&\fIexecution_count\fR: number of executions of the function
! .IP * 4
  \&\fIname\fR: name of the function
! .IP * 4
  \&\fIstart_column\fR: column in the source file where the function begins
! .IP * 4
  \&\fIstart_line\fR: line in the source file where the function begins
  .RE
  .RS 4
*************** Each \fIline\fR has the following form:
*** 379,392 ****
  .Sp
  Branches are present only with \fI\-b\fR option.
  Fields of the \fIline\fR element have following semantics:
! .IP "*" 4
  \&\fIcount\fR: number of executions of the line
! .IP "*" 4
  \&\fIline_number\fR: line number
! .IP "*" 4
  \&\fIunexecuted_block\fR: flag whether the line contains an unexecuted block
  (not all statements on the line are executed)
! .IP "*" 4
  \&\fIfunction_name\fR: a name of a function this \fIline\fR belongs to
  (for a line with an inlined statements can be not set)
  .RE
--- 304,317 ----
  .Sp
  Branches are present only with \fI\-b\fR option.
  Fields of the \fIline\fR element have following semantics:
! .IP * 4
  \&\fIcount\fR: number of executions of the line
! .IP * 4
  \&\fIline_number\fR: line number
! .IP * 4
  \&\fIunexecuted_block\fR: flag whether the line contains an unexecuted block
  (not all statements on the line are executed)
! .IP * 4
  \&\fIfunction_name\fR: a name of a function this \fIline\fR belongs to
  (for a line with an inlined statements can be not set)
  .RE
*************** Each \fIbranch\fR has the following form
*** 403,437 ****
  .Ve
  .Sp
  Fields of the \fIbranch\fR element have following semantics:
! .IP "*" 4
  \&\fIcount\fR: number of executions of the branch
! .IP "*" 4
  \&\fIfallthrough\fR: true when the branch is a fall through branch
! .IP "*" 4
  \&\fIthrow\fR: true when the branch is an exceptional branch
  .RE
  .RS 4
  .RE
! .IP "\fB\-H\fR" 4
  .IX Item "-H"
  .PD 0
! .IP "\fB\-\-human\-readable\fR" 4
  .IX Item "--human-readable"
  .PD
  Write counts in human readable format (like 24.6k).
! .IP "\fB\-k\fR" 4
  .IX Item "-k"
  .PD 0
! .IP "\fB\-\-use\-colors\fR" 4
  .IX Item "--use-colors"
  .PD
  Use colors for lines of code that have zero coverage.  We use red color for
! non-exceptional lines and cyan for exceptional.  Same colors are used for
  basic blocks with \fB\-a\fR option.
! .IP "\fB\-l\fR" 4
  .IX Item "-l"
  .PD 0
! .IP "\fB\-\-long\-file\-names\fR" 4
  .IX Item "--long-file-names"
  .PD
  Create long file names for included source files.  For example, if the
--- 328,362 ----
  .Ve
  .Sp
  Fields of the \fIbranch\fR element have following semantics:
! .IP * 4
  \&\fIcount\fR: number of executions of the branch
! .IP * 4
  \&\fIfallthrough\fR: true when the branch is a fall through branch
! .IP * 4
  \&\fIthrow\fR: true when the branch is an exceptional branch
  .RE
  .RS 4
  .RE
! .IP \fB\-H\fR 4
  .IX Item "-H"
  .PD 0
! .IP \fB\-\-human\-readable\fR 4
  .IX Item "--human-readable"
  .PD
  Write counts in human readable format (like 24.6k).
! .IP \fB\-k\fR 4
  .IX Item "-k"
  .PD 0
! .IP \fB\-\-use\-colors\fR 4
  .IX Item "--use-colors"
  .PD
  Use colors for lines of code that have zero coverage.  We use red color for
! non\-exceptional lines and cyan for exceptional.  Same colors are used for
  basic blocks with \fB\-a\fR option.
! .IP \fB\-l\fR 4
  .IX Item "-l"
  .PD 0
! .IP \fB\-\-long\-file\-names\fR 4
  .IX Item "--long-file-names"
  .PD
  Create long file names for included source files.  For example, if the
*************** produce an output file called \fIa.c##x.
*** 442,459 ****
  multiple source files and you want to see the individual
  contributions.  If you use the \fB\-p\fR option, both the including
  and included file names will be complete path names.
! .IP "\fB\-m\fR" 4
  .IX Item "-m"
  .PD 0
! .IP "\fB\-\-demangled\-names\fR" 4
  .IX Item "--demangled-names"
  .PD
  Display demangled function names in output. The default is to show
  mangled function names.
! .IP "\fB\-n\fR" 4
  .IX Item "-n"
  .PD 0
! .IP "\fB\-\-no\-output\fR" 4
  .IX Item "--no-output"
  .PD
  Do not create the \fBgcov\fR output file.
--- 367,384 ----
  multiple source files and you want to see the individual
  contributions.  If you use the \fB\-p\fR option, both the including
  and included file names will be complete path names.
! .IP \fB\-m\fR 4
  .IX Item "-m"
  .PD 0
! .IP \fB\-\-demangled\-names\fR 4
  .IX Item "--demangled-names"
  .PD
  Display demangled function names in output. The default is to show
  mangled function names.
! .IP \fB\-n\fR 4
  .IX Item "-n"
  .PD 0
! .IP \fB\-\-no\-output\fR 4
  .IX Item "--no-output"
  .PD
  Do not create the \fBgcov\fR output file.
*************** object path name.  The \fI.gcno\fR, and
*** 471,480 ****
  is specified, the data files are in that directory and named after the
  input file name, without its extension.  If a file is specified here,
  the data files are named after that file, without its extension.
! .IP "\fB\-p\fR" 4
  .IX Item "-p"
  .PD 0
! .IP "\fB\-\-preserve\-paths\fR" 4
  .IX Item "--preserve-paths"
  .PD
  Preserve complete path information in the names of generated
--- 396,405 ----
  is specified, the data files are in that directory and named after the
  input file name, without its extension.  If a file is specified here,
  the data files are named after that file, without its extension.
! .IP \fB\-p\fR 4
  .IX Item "-p"
  .PD 0
! .IP \fB\-\-preserve\-paths\fR 4
  .IX Item "--preserve-paths"
  .PD
  Preserve complete path information in the names of generated
*************** translated to \fB#\fR characters, \fI.\f
*** 484,501 ****
  removed and unremoveable \fI..\fR
  components renamed to \fB^\fR.  This is useful if sourcefiles are in several
  different directories.
! .IP "\fB\-q\fR" 4
  .IX Item "-q"
  .PD 0
! .IP "\fB\-\-use\-hotness\-colors\fR" 4
  .IX Item "--use-hotness-colors"
  .PD
! Emit perf-like colored output for hot lines.  Legend of the color scale
  is printed at the very beginning of the output file.
! .IP "\fB\-r\fR" 4
  .IX Item "-r"
  .PD 0
! .IP "\fB\-\-relative\-only\fR" 4
  .IX Item "--relative-only"
  .PD
  Only output information about source files with a relative pathname
--- 409,426 ----
  removed and unremoveable \fI..\fR
  components renamed to \fB^\fR.  This is useful if sourcefiles are in several
  different directories.
! .IP \fB\-q\fR 4
  .IX Item "-q"
  .PD 0
! .IP \fB\-\-use\-hotness\-colors\fR 4
  .IX Item "--use-hotness-colors"
  .PD
! Emit perf\-like colored output for hot lines.  Legend of the color scale
  is printed at the very beginning of the output file.
! .IP \fB\-r\fR 4
  .IX Item "-r"
  .PD 0
! .IP \fB\-\-relative\-only\fR 4
  .IX Item "--relative-only"
  .PD
  Only output information about source files with a relative pathname
*************** coverage files.  This option is useful w
*** 513,560 ****
  directory, and the pathname to the source directory is not wanted when
  determining the output file names.  Note that this prefix detection is
  applied before determining whether the source file is absolute.
! .IP "\fB\-t\fR" 4
  .IX Item "-t"
  .PD 0
! .IP "\fB\-\-stdout\fR" 4
  .IX Item "--stdout"
  .PD
  Output to standard output instead of output files.
! .IP "\fB\-u\fR" 4
  .IX Item "-u"
  .PD 0
! .IP "\fB\-\-unconditional\-branches\fR" 4
  .IX Item "--unconditional-branches"
  .PD
  When branch probabilities are given, include those of unconditional branches.
  Unconditional branches are normally not interesting.
! .IP "\fB\-v\fR" 4
  .IX Item "-v"
  .PD 0
! .IP "\fB\-\-version\fR" 4
  .IX Item "--version"
  .PD
  Display the \fBgcov\fR version number (on the standard output),
  and exit without doing any further processing.
! .IP "\fB\-w\fR" 4
  .IX Item "-w"
  .PD 0
! .IP "\fB\-\-verbose\fR" 4
  .IX Item "--verbose"
  .PD
  Print verbose informations related to basic blocks and arcs.
! .IP "\fB\-x\fR" 4
  .IX Item "-x"
  .PD 0
! .IP "\fB\-\-hash\-filenames\fR" 4
  .IX Item "--hash-filenames"
  .PD
  When using \fI\-\-preserve\-paths\fR,
  gcov uses the full pathname of the source files to create
  an output filename.  This can lead to long filenames that can overflow
  filesystem limits.  This option creates names of the form
! \&\fI\fIsource-file\fI##\fImd5\fI.gcov\fR,
! where the \fIsource-file\fR component is the final filename part and
  the \fImd5\fR component is calculated from the full mangled name that
  would have been used otherwise.  The option is an alternative
  to the \fI\-\-preserve\-paths\fR on systems which have a filesystem limit.
--- 438,485 ----
  directory, and the pathname to the source directory is not wanted when
  determining the output file names.  Note that this prefix detection is
  applied before determining whether the source file is absolute.
! .IP \fB\-t\fR 4
  .IX Item "-t"
  .PD 0
! .IP \fB\-\-stdout\fR 4
  .IX Item "--stdout"
  .PD
  Output to standard output instead of output files.
! .IP \fB\-u\fR 4
  .IX Item "-u"
  .PD 0
! .IP \fB\-\-unconditional\-branches\fR 4
  .IX Item "--unconditional-branches"
  .PD
  When branch probabilities are given, include those of unconditional branches.
  Unconditional branches are normally not interesting.
! .IP \fB\-v\fR 4
  .IX Item "-v"
  .PD 0
! .IP \fB\-\-version\fR 4
  .IX Item "--version"
  .PD
  Display the \fBgcov\fR version number (on the standard output),
  and exit without doing any further processing.
! .IP \fB\-w\fR 4
  .IX Item "-w"
  .PD 0
! .IP \fB\-\-verbose\fR 4
  .IX Item "--verbose"
  .PD
  Print verbose informations related to basic blocks and arcs.
! .IP \fB\-x\fR 4
  .IX Item "-x"
  .PD 0
! .IP \fB\-\-hash\-filenames\fR 4
  .IX Item "--hash-filenames"
  .PD
  When using \fI\-\-preserve\-paths\fR,
  gcov uses the full pathname of the source files to create
  an output filename.  This can lead to long filenames that can overflow
  filesystem limits.  This option creates names of the form
! \&\fIsource\-file##md5.gcov\fR,
! where the \fIsource\-file\fR component is the final filename part and
  the \fImd5\fR component is calculated from the full mangled name that
  would have been used otherwise.  The option is an alternative
  to the \fI\-\-preserve\-paths\fR on systems which have a filesystem limit.
*************** to the \fI\-\-preserve\-paths\fR on syst
*** 562,568 ****
  \&\fBgcov\fR should be run with the current directory the same as that
  when you invoked the compiler.  Otherwise it will not be able to locate
  the source files.  \fBgcov\fR produces files called
! \&\fI\fImangledname\fI.gcov\fR in the current directory.  These contain
  the coverage information of the source file they correspond to.
  One \fI.gcov\fR file is produced for each source (or header) file
  containing code,
--- 487,493 ----
  \&\fBgcov\fR should be run with the current directory the same as that
  when you invoked the compiler.  Otherwise it will not be able to locate
  the source files.  \fBgcov\fR produces files called
! \&\fImangledname.gcov\fR in the current directory.  These contain
  the coverage information of the source file they correspond to.
  One \fI.gcov\fR file is produced for each source (or header) file
  containing code,
*************** Additional block information may succeed
*** 586,601 ****
  command line option.  The \fIexecution_count\fR is \fB\-\fR for lines
  containing no code.  Unexecuted lines are marked \fB#####\fR or
  \&\fB=====\fR, depending on whether they are reachable by
! non-exceptional paths or only exceptional paths such as \*(C+ exception
  handlers, respectively. Given the \fB\-a\fR option, unexecuted blocks are
  marked \fB$$$$$\fR or \fB%%%%%\fR, depending on whether a basic block
! is reachable via non-exceptional or exceptional paths.
  Executed basic blocks having a statement with zero \fIexecution_count\fR
  end with \fB*\fR character and are colored with magenta color with
  the \fB\-k\fR option.  This functionality is not supported in Ada.
  .PP
! Note that \s-1GCC\s0 can completely remove the bodies of functions that are
! not needed \*(-- for instance if they are inlined everywhere.  Such functions
  are marked with \fB\-\fR, which can be confusing.
  Use the \fB\-fkeep\-inline\-functions\fR and \fB\-fkeep\-static\-functions\fR
  options to retain these functions and
--- 511,526 ----
  command line option.  The \fIexecution_count\fR is \fB\-\fR for lines
  containing no code.  Unexecuted lines are marked \fB#####\fR or
  \&\fB=====\fR, depending on whether they are reachable by
! non\-exceptional paths or only exceptional paths such as C++ exception
  handlers, respectively. Given the \fB\-a\fR option, unexecuted blocks are
  marked \fB$$$$$\fR or \fB%%%%%\fR, depending on whether a basic block
! is reachable via non\-exceptional or exceptional paths.
  Executed basic blocks having a statement with zero \fIexecution_count\fR
  end with \fB*\fR character and are colored with magenta color with
  the \fB\-k\fR option.  This functionality is not supported in Ada.
  .PP
! Note that GCC can completely remove the bodies of functions that are
! not needed \-\- for instance if they are inlined everywhere.  Such functions
  are marked with \fB\-\fR, which can be confusing.
  Use the \fB\-fkeep\-inline\-functions\fR and \fB\-fkeep\-static\-functions\fR
  options to retain these functions and
*************** enough for machine parsing too.
*** 624,633 ****
  When printing percentages, 0% and 100% are only printed when the values
  are \fIexactly\fR 0% and 100% respectively.  Other values which would
  conventionally be rounded to 0% or 100% are instead printed as the
! nearest non-boundary value.
  .PP
  When using \fBgcov\fR, you must first compile your program
! with a special \s-1GCC\s0 option \fB\-\-coverage\fR.
  This tells the compiler to generate additional information needed by
  gcov (basically a flow graph of the program) and also includes
  additional code in the object files for generating the extra profiling
--- 549,558 ----
  When printing percentages, 0% and 100% are only printed when the values
  are \fIexactly\fR 0% and 100% respectively.  Other values which would
  conventionally be rounded to 0% or 100% are instead printed as the
! nearest non\-boundary value.
  .PP
  When using \fBgcov\fR, you must first compile your program
! with a special GCC option \fB\-\-coverage\fR.
  This tells the compiler to generate additional information needed by
  gcov (basically a flow graph of the program) and also includes
  additional code in the object files for generating the extra profiling
*************** Running the program will cause profile o
*** 638,644 ****
  source file compiled with \fB\-fprofile\-arcs\fR, an accompanying
  \&\fI.gcda\fR file will be placed in the object file directory.
  .PP
! Running \fBgcov\fR with your program's source file names as arguments
  will now produce a listing of the code along with frequency of execution
  for each line.  For example, if your program is called \fItmp.cpp\fR, this
  is what you see when you use the basic \fBgcov\fR facility:
--- 563,569 ----
  source file compiled with \fB\-fprofile\-arcs\fR, an accompanying
  \&\fI.gcda\fR file will be placed in the object file directory.
  .PP
! Running \fBgcov\fR with your program\*(Aqs source file names as arguments
  will now produce a listing of the code along with frequency of execution
  for each line.  For example, if your program is called \fItmp.cpp\fR, this
  is what you see when you use the basic \fBgcov\fR facility:
*************** counts, and the output looks like this:
*** 797,804 ****
  \&                \-:   37:}
  .Ve
  .PP
! In this mode, each basic block is only shown on one line \*(-- the last
! line of the block.  A multi-line block will only contribute to the
  execution count of that last line, and other lines will not be shown
  to contain code, unless previous blocks end on those lines.
  The total execution count of a line is shown and subsequent lines show
--- 722,729 ----
  \&                \-:   37:}
  .Ve
  .PP
! In this mode, each basic block is only shown on one line \-\- the last
! line of the block.  A multi\-line block will only contribute to the
  execution count of that last line, and other lines will not be shown
  to contain code, unless previous blocks end on those lines.
  The total execution count of a line is shown and subsequent lines show
*************** the execution counts for individual bloc
*** 806,812 ****
  block, the branch and call counts of the block will be shown, if the
  \&\fB\-b\fR option is given.
  .PP
! Because of the way \s-1GCC\s0 instruments calls, a call count can be shown
  after a line with no individual blocks.
  As you can see, line 33 contains a basic block that was not executed.
  .PP
--- 731,737 ----
  block, the branch and call counts of the block will be shown, if the
  \&\fB\-b\fR option is given.
  .PP
! Because of the way GCC instruments calls, a call count can be shown
  after a line with no individual blocks.
  As you can see, line 33 contains a basic block that was not executed.
  .PP
*************** When you use the \fB\-b\fR option, your
*** 900,906 ****
  .PP
  For each function, a line is printed showing how many times the function
  is called, how many times it returns and what percentage of the
! function's blocks were executed.
  .PP
  For each basic block, a line is printed after the last line of the basic
  block describing the branch or call that ends the basic block.  There can
--- 825,831 ----
  .PP
  For each function, a line is printed showing how many times the function
  is called, how many times it returns and what percentage of the
! function\*(Aqs blocks were executed.
  .PP
  For each basic block, a line is printed after the last line of the basic
  block describing the branch or call that ends the basic block.  There can
*************** on the source line.
*** 914,920 ****
  For a branch, if it was executed at least once, then a percentage
  indicating the number of times the branch was taken divided by the
  number of times the branch was executed will be printed.  Otherwise, the
! message \*(L"never executed\*(R" is printed.
  .PP
  For a call, if it was executed at least once, then a percentage
  indicating the number of times the call returned divided by the number
--- 839,845 ----
  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.
  .PP
  For a call, if it was executed at least once, then a percentage
  indicating the number of times the call returned divided by the number
*************** number of times each line in the source
*** 928,948 ****
  the results of the previous run(s).  This is potentially useful in
  several ways.  For example, it could be used to accumulate data over a
  number of program runs as part of a test verification suite, or to
! provide more accurate long-term information over a large number of
  program runs.
  .PP
  The data in the \fI.gcda\fR files is saved immediately before the program
  exits.  For each source file compiled with \fB\-fprofile\-arcs\fR, the
  profiling code first attempts to read in an existing \fI.gcda\fR file; if
! the file doesn't match the executable (differing number of basic block
  counts) it will ignore the contents of the file.  It then adds in the
  new execution counts and finally writes the data to the file.
! .SS "Using \fBgcov\fP with \s-1GCC\s0 Optimization"
  .IX Subsection "Using gcov with GCC Optimization"
  If you plan to use \fBgcov\fR to help optimize your code, you must
! first compile your program with a special \s-1GCC\s0 option
  \&\fB\-\-coverage\fR.  Aside from that, you can use any
! other \s-1GCC\s0 options; but if you want to prove that every single line
  in your program was executed, you should not compile with optimization
  at the same time.  On some machines the optimizer can eliminate some
  simple code lines by combining them with other lines.  For example, code
--- 853,873 ----
  the results of the previous run(s).  This is potentially useful in
  several ways.  For example, it could be used to accumulate data over a
  number of program runs as part of a test verification suite, or to
! provide more accurate long\-term information over a large number of
  program runs.
  .PP
  The data in the \fI.gcda\fR files is saved immediately before the program
  exits.  For each source file compiled with \fB\-fprofile\-arcs\fR, the
  profiling code first attempts to read in an existing \fI.gcda\fR file; if
! the file doesn\*(Aqt match the executable (differing number of basic block
  counts) it will ignore the contents of the file.  It then adds in the
  new execution counts and finally writes the data to the file.
! .SS "Using \fBgcov\fP with GCC Optimization"
  .IX Subsection "Using gcov with GCC Optimization"
  If you plan to use \fBgcov\fR to help optimize your code, you must
! first compile your program with a special GCC option
  \&\fB\-\-coverage\fR.  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:
*** 957,963 ****
  .PP
  can be compiled into one instruction on some machines.  In this case,
  there is no way for \fBgcov\fR to calculate separate execution counts
! for each line because there isn't separate code for each line.  Hence
  the \fBgcov\fR output looks like this if you compiled the program with
  optimization:
  .PP
--- 882,888 ----
  .PP
  can be compiled into one instruction on some machines.  In this case,
  there is no way for \fBgcov\fR to calculate separate execution counts
! for each line because there isn\*(Aqt separate code for each line.  Hence
  the \fBgcov\fR output looks like this if you compiled the program with
  optimization:
  .PP
*************** now be calculable at compile time in som
*** 995,1003 ****
  coverage of all the uses of the inline function will be shown for the
  same source lines, the line counts themselves might seem inconsistent.
  .PP
! Long-running applications can use the \f(CW\*(C`_\|_gcov_reset\*(C'\fR and \f(CW\*(C`_\|_gcov_dump\*(C'\fR
  facilities to restrict profile collection to the program region of
! interest. Calling \f(CW\*(C`_\|_gcov_reset(void)\*(C'\fR will clear all run-time profile
  counters to zero, and calling \f(CW\*(C`_\|_gcov_dump(void)\*(C'\fR will cause the profile
  information collected at that point to be dumped to \fI.gcda\fR output files.
  Instrumented applications use a static destructor with priority 99
--- 920,928 ----
  coverage of all the uses of the inline function will be shown for the
  same source lines, the line counts themselves might seem inconsistent.
  .PP
! Long\-running applications can use the \f(CW\*(C`_\|_gcov_reset\*(C'\fR and \f(CW\*(C`_\|_gcov_dump\*(C'\fR
  facilities to restrict profile collection to the program region of
! interest. Calling \f(CW\*(C`_\|_gcov_reset(void)\*(C'\fR will clear all run\-time profile
  counters to zero, and calling \f(CW\*(C`_\|_gcov_dump(void)\*(C'\fR will cause the profile
  information collected at that point to be dumped to \fI.gcda\fR output files.
  Instrumented applications use a static destructor with priority 99
*************** as well as handlers registered with \f(C
*** 1008,1042 ****
  If an executable loads a dynamic shared object via dlopen functionality,
  \&\fB\-Wl,\-\-dynamic\-list\-data\fR is needed to dump all profile data.
  .PP
! Profiling run-time library reports various errors related to profile
  manipulation and profile saving.  Errors are printed into standard error output
! or \fB\s-1GCOV_ERROR_FILE\s0\fR file, if environment variable is used.
  In order to terminate immediately after an errors occurs
! set \fB\s-1GCOV_EXIT_AT_ERROR\s0\fR environment variable.
  That can help users to find profile clashing which leads
  to a misleading profile.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7), \fBgcc\fR\|(1) and the Info entry for \fIgcc\fR.
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 1996\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
! Free Software\*(R", the Front-Cover texts being (a) (see below), and with
! the Back-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The \s-1FSF\s0's Front-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The \s-1FSF\s0's Back-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
--- 933,967 ----
  If an executable loads a dynamic shared object via dlopen functionality,
  \&\fB\-Wl,\-\-dynamic\-list\-data\fR is needed to dump all profile data.
  .PP
! Profiling run\-time library reports various errors related to profile
  manipulation and profile saving.  Errors are printed into standard error output
! or \fBGCOV_ERROR_FILE\fR file, if environment variable is used.
  In order to terminate immediately after an errors occurs
! set \fBGCOV_EXIT_AT_ERROR\fR environment variable.
  That can help users to find profile clashing which leads
  to a misleading profile.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7), \fBgcc\fR\|(1) and the Info entry for \fIgcc\fR.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 1996\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the GNU Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being "GNU General Public License" and "Funding
! Free Software", the Front\-Cover texts being (a) (see below), and with
! the Back\-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The FSF\*(Aqs Front\-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The FSF\*(Aqs Back\-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
diff -Nrcpad gcc-13.4.0/gcc/doc/gdc.1 gcc-13.5.0-RC-20260904/gcc/doc/gdc.1
*** gcc-13.4.0/gcc/doc/gdc.1	Thu Jun  5 16:30:28 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gdc.1	Fri Sep  4 07:57:49 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,179 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GDC 1"
! .TH GDC 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gdc \- A GCC\-based compiler for the D language
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
  gdc [\fB\-c\fR|\fB\-S\fR] [\fB\-g\fR] [\fB\-pg\fR]
      [\fB\-O\fR\fIlevel\fR] [\fB\-W\fR\fIwarn\fR...]
      [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
!     [\fB\-f\fR\fIoption\fR...] [\fB\-m\fR\fImachine-option\fR...]
      [\fB\-o\fR \fIoutfile\fR] [@\fIfile\fR] \fIinfile\fR...
  .PP
  Only the most useful options are listed here; see below for the
  remainder.
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
! The \fBgdc\fR command is the \s-1GNU\s0 compiler for the D language and
  supports many of the same options as \fBgcc\fR.  
  This manual only documents the options specific to \fBgdc\fR.
! .SH "OPTIONS"
  .IX Header "OPTIONS"
  .SS "Input and Output files"
  .IX Subsection "Input and Output files"
  For any given input file, the file name suffix determines what kind of
  compilation is done.  The following kinds of input file names are supported:
! .IP "\fIfile\fR\fB.d\fR" 4
  .IX Item "file.d"
  D source files.
! .IP "\fIfile\fR\fB.dd\fR" 4
  .IX Item "file.dd"
  Ddoc source files.
! .IP "\fIfile\fR\fB.di\fR" 4
  .IX Item "file.di"
  D interface files.
  .PP
  You can specify more than one input file on the \fBgdc\fR command line,
  each being compiled separately in the compilation process.  If you specify a
! \&\f(CW\*(C`\-o \f(CIfile\f(CW\*(C'\fR option, all the input files are compiled together,
  producing a single output file, named \fIfile\fR.  This is allowed even
  when using \f(CW\*(C`\-S\*(C'\fR or \f(CW\*(C`\-c\*(C'\fR.
  .PP
--- 53,104 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GDC 1"
! .TH GDC 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gdc \- A GCC\-based compiler for the D language
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
  gdc [\fB\-c\fR|\fB\-S\fR] [\fB\-g\fR] [\fB\-pg\fR]
      [\fB\-O\fR\fIlevel\fR] [\fB\-W\fR\fIwarn\fR...]
      [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
!     [\fB\-f\fR\fIoption\fR...] [\fB\-m\fR\fImachine\-option\fR...]
      [\fB\-o\fR \fIoutfile\fR] [@\fIfile\fR] \fIinfile\fR...
  .PP
  Only the most useful options are listed here; see below for the
  remainder.
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
! The \fBgdc\fR command is the GNU compiler for the D language and
  supports many of the same options as \fBgcc\fR.  
  This manual only documents the options specific to \fBgdc\fR.
! .SH OPTIONS
  .IX Header "OPTIONS"
  .SS "Input and Output files"
  .IX Subsection "Input and Output files"
  For any given input file, the file name suffix determines what kind of
  compilation is done.  The following kinds of input file names are supported:
! .IP \fIfile\fR\fB.d\fR 4
  .IX Item "file.d"
  D source files.
! .IP \fIfile\fR\fB.dd\fR 4
  .IX Item "file.dd"
  Ddoc source files.
! .IP \fIfile\fR\fB.di\fR 4
  .IX Item "file.di"
  D interface files.
  .PP
  You can specify more than one input file on the \fBgdc\fR command line,
  each being compiled separately in the compilation process.  If you specify a
! \&\f(CW\*(C`\-o \fR\f(CIfile\fR\f(CW\*(C'\fR option, all the input files are compiled together,
  producing a single output file, named \fIfile\fR.  This is allowed even
  when using \f(CW\*(C`\-S\*(C'\fR or \f(CW\*(C`\-c\*(C'\fR.
  .PP
*************** When the compiler resolves an import dec
*** 185,257 ****
  .PP
  A Ddoc source file contains code in the D macro processor language.  It is
  primarily designed for use in producing user documentation from embedded
! comments, with a slight affinity towards \s-1HTML\s0 generation.  If a \fI.d\fR
  source file starts with the string \f(CW\*(C`Ddoc\*(C'\fR then it is treated as general
  purpose documentation, not as a D source file.
  .SS "Runtime Options"
  .IX Subsection "Runtime Options"
  These options affect the runtime behavior of programs compiled with
  \&\fBgdc\fR.
! .IP "\fB\-fall\-instantiations\fR" 4
  .IX Item "-fall-instantiations"
  Generate code for all template instantiations.  The default template emission
  strategy is to not generate code for declarations that were either
  instantiated speculatively, such as from \f(CW\*(C`_\|_traits(compiles, ...)\*(C'\fR, or
  that come from an imported module not being compiled.
! .IP "\fB\-fno\-assert\fR" 4
  .IX Item "-fno-assert"
  Turn off code generation for \f(CW\*(C`assert\*(C'\fR contracts.
! .IP "\fB\-fno\-bounds\-check\fR" 4
  .IX Item "-fno-bounds-check"
  Turns off array bounds checking for all functions, which can improve
  performance for code that uses arrays extensively.  Note that this
  can result in unpredictable behavior if the code in question actually
  does violate array bounds constraints.  It is safe to use this option
  if you are sure that your code never throws a \f(CW\*(C`RangeError\*(C'\fR.
! .IP "\fB\-fbounds\-check=\fR\fIvalue\fR" 4
  .IX Item "-fbounds-check=value"
  An alternative to \fB\-fbounds\-check\fR that allows more control
  as to where bounds checking is turned on or off.  The following values
  are supported:
  .RS 4
! .IP "\fBon\fR" 4
  .IX Item "on"
  Turns on array bounds checking for all functions.
! .IP "\fBsafeonly\fR" 4
  .IX Item "safeonly"
  Turns on array bounds checking only for \f(CW@safe\fR functions.
! .IP "\fBoff\fR" 4
  .IX Item "off"
  Turns off array bounds checking completely.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fno\-builtin\fR" 4
  .IX Item "-fno-builtin"
! Don't recognize built-in functions unless they begin with the prefix
  \&\fB_\|_builtin_\fR.  By default, the compiler will recognize when a
! function in the \f(CW\*(C`core.stdc\*(C'\fR package is a built-in function.
! .IP "\fB\-fcheckaction=\fR\fIvalue\fR" 4
  .IX Item "-fcheckaction=value"
  This option controls what code is generated on an assertion, bounds check, or
  final switch failure.  The following values are supported:
  .RS 4
! .IP "\fBcontext\fR" 4
  .IX Item "context"
  Throw an \f(CW\*(C`AssertError\*(C'\fR with extra context information.
! .IP "\fBhalt\fR" 4
  .IX Item "halt"
  Halt the program execution.
! .IP "\fBthrow\fR" 4
  .IX Item "throw"
  Throw an \f(CW\*(C`AssertError\*(C'\fR (the default).
  .RE
  .RS 4
  .RE
! .IP "\fB\-fdebug\fR" 4
  .IX Item "-fdebug"
  .PD 0
! .IP "\fB\-fdebug=\fR\fIvalue\fR" 4
  .IX Item "-fdebug=value"
  .PD
  Turn on compilation of conditional \f(CW\*(C`debug\*(C'\fR code into the program.
--- 110,182 ----
  .PP
  A Ddoc source file contains code in the D macro processor language.  It is
  primarily designed for use in producing user documentation from embedded
! comments, with a slight affinity towards HTML generation.  If a \fI.d\fR
  source file starts with the string \f(CW\*(C`Ddoc\*(C'\fR then it is treated as general
  purpose documentation, not as a D source file.
  .SS "Runtime Options"
  .IX Subsection "Runtime Options"
  These options affect the runtime behavior of programs compiled with
  \&\fBgdc\fR.
! .IP \fB\-fall\-instantiations\fR 4
  .IX Item "-fall-instantiations"
  Generate code for all template instantiations.  The default template emission
  strategy is to not generate code for declarations that were either
  instantiated speculatively, such as from \f(CW\*(C`_\|_traits(compiles, ...)\*(C'\fR, or
  that come from an imported module not being compiled.
! .IP \fB\-fno\-assert\fR 4
  .IX Item "-fno-assert"
  Turn off code generation for \f(CW\*(C`assert\*(C'\fR contracts.
! .IP \fB\-fno\-bounds\-check\fR 4
  .IX Item "-fno-bounds-check"
  Turns off array bounds checking for all functions, which can improve
  performance for code that uses arrays extensively.  Note that this
  can result in unpredictable behavior if the code in question actually
  does violate array bounds constraints.  It is safe to use this option
  if you are sure that your code never throws a \f(CW\*(C`RangeError\*(C'\fR.
! .IP \fB\-fbounds\-check=\fR\fIvalue\fR 4
  .IX Item "-fbounds-check=value"
  An alternative to \fB\-fbounds\-check\fR that allows more control
  as to where bounds checking is turned on or off.  The following values
  are supported:
  .RS 4
! .IP \fBon\fR 4
  .IX Item "on"
  Turns on array bounds checking for all functions.
! .IP \fBsafeonly\fR 4
  .IX Item "safeonly"
  Turns on array bounds checking only for \f(CW@safe\fR functions.
! .IP \fBoff\fR 4
  .IX Item "off"
  Turns off array bounds checking completely.
  .RE
  .RS 4
  .RE
! .IP \fB\-fno\-builtin\fR 4
  .IX Item "-fno-builtin"
! Don\*(Aqt recognize built\-in functions unless they begin with the prefix
  \&\fB_\|_builtin_\fR.  By default, the compiler will recognize when a
! function in the \f(CW\*(C`core.stdc\*(C'\fR package is a built\-in function.
! .IP \fB\-fcheckaction=\fR\fIvalue\fR 4
  .IX Item "-fcheckaction=value"
  This option controls what code is generated on an assertion, bounds check, or
  final switch failure.  The following values are supported:
  .RS 4
! .IP \fBcontext\fR 4
  .IX Item "context"
  Throw an \f(CW\*(C`AssertError\*(C'\fR with extra context information.
! .IP \fBhalt\fR 4
  .IX Item "halt"
  Halt the program execution.
! .IP \fBthrow\fR 4
  .IX Item "throw"
  Throw an \f(CW\*(C`AssertError\*(C'\fR (the default).
  .RE
  .RS 4
  .RE
! .IP \fB\-fdebug\fR 4
  .IX Item "-fdebug"
  .PD 0
! .IP \fB\-fdebug=\fR\fIvalue\fR 4
  .IX Item "-fdebug=value"
  .PD
  Turn on compilation of conditional \f(CW\*(C`debug\*(C'\fR code into the program.
*************** The \fB\-fdebug\fR option itself sets th
*** 259,271 ****
  while \fB\-fdebug=\fR enables \f(CW\*(C`debug\*(C'\fR code that are identified
  by any of the following values:
  .RS 4
! .IP "\fBident\fR" 4
  .IX Item "ident"
  Turns on compilation of any \f(CW\*(C`debug\*(C'\fR code identified by \fIident\fR.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fno\-druntime\fR" 4
  .IX Item "-fno-druntime"
  Implements <\fBhttps://dlang.org/spec/betterc.html\fR>.  Assumes that
  compilation targets an environment without a D runtime library.
--- 184,196 ----
  while \fB\-fdebug=\fR enables \f(CW\*(C`debug\*(C'\fR code that are identified
  by any of the following values:
  .RS 4
! .IP \fBident\fR 4
  .IX Item "ident"
  Turns on compilation of any \f(CW\*(C`debug\*(C'\fR code identified by \fIident\fR.
  .RE
  .RS 4
  .RE
! .IP \fB\-fno\-druntime\fR 4
  .IX Item "-fno-druntime"
  Implements <\fBhttps://dlang.org/spec/betterc.html\fR>.  Assumes that
  compilation targets an environment without a D runtime library.
*************** This is equivalent to compiling with the
*** 275,318 ****
  .Vb 1
  \&        gdc \-nophoboslib \-fno\-exceptions \-fno\-moduleinfo \-fno\-rtti
  .Ve
! .IP "\fB\-fextern\-std=\fR\fIstandard\fR" 4
  .IX Item "-fextern-std=standard"
! Sets the \*(C+ name mangling compatibility to the version identified by
  \&\fIstandard\fR.  The following values are supported:
  .RS 4
! .IP "\fBc++98\fR" 4
  .IX Item "c++98"
  .PD 0
! .IP "\fBc++03\fR" 4
  .IX Item "c++03"
  .PD
  Sets \f(CW\*(C`_\|_traits(getTargetInfo, "cppStd")\*(C'\fR to \f(CW199711\fR.
! .IP "\fBc++11\fR" 4
  .IX Item "c++11"
  Sets \f(CW\*(C`_\|_traits(getTargetInfo, "cppStd")\*(C'\fR to \f(CW201103\fR.
! .IP "\fBc++14\fR" 4
  .IX Item "c++14"
  Sets \f(CW\*(C`_\|_traits(getTargetInfo, "cppStd")\*(C'\fR to \f(CW201402\fR.
! .IP "\fBc++17\fR" 4
  .IX Item "c++17"
  Sets \f(CW\*(C`_\|_traits(getTargetInfo, "cppStd")\*(C'\fR to \f(CW201703\fR.
  This is the default.
! .IP "\fBc++20\fR" 4
  .IX Item "c++20"
  Sets \f(CW\*(C`_\|_traits(getTargetInfo, "cppStd")\*(C'\fR to \f(CW202002\fR.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fno\-invariants\fR" 4
  .IX Item "-fno-invariants"
  Turns off code generation for class \f(CW\*(C`invariant\*(C'\fR contracts.
! .IP "\fB\-fmain\fR" 4
  .IX Item "-fmain"
! Generates a default \f(CW\*(C`main()\*(C'\fR function when compiling.  This is useful when
  unittesting a library, as it enables running the unittests in a library without
! having to manually define an entry-point function.  This option does nothing
  when \f(CW\*(C`main\*(C'\fR is already defined in user code.
! .IP "\fB\-fno\-moduleinfo\fR" 4
  .IX Item "-fno-moduleinfo"
  Turns off generation of the \f(CW\*(C`ModuleInfo\*(C'\fR and related functions
  that would become unreferenced without it, which may allow linking
--- 200,243 ----
  .Vb 1
  \&        gdc \-nophoboslib \-fno\-exceptions \-fno\-moduleinfo \-fno\-rtti
  .Ve
! .IP \fB\-fextern\-std=\fR\fIstandard\fR 4
  .IX Item "-fextern-std=standard"
! Sets the C++ name mangling compatibility to the version identified by
  \&\fIstandard\fR.  The following values are supported:
  .RS 4
! .IP \fBc++98\fR 4
  .IX Item "c++98"
  .PD 0
! .IP \fBc++03\fR 4
  .IX Item "c++03"
  .PD
  Sets \f(CW\*(C`_\|_traits(getTargetInfo, "cppStd")\*(C'\fR to \f(CW199711\fR.
! .IP \fBc++11\fR 4
  .IX Item "c++11"
  Sets \f(CW\*(C`_\|_traits(getTargetInfo, "cppStd")\*(C'\fR to \f(CW201103\fR.
! .IP \fBc++14\fR 4
  .IX Item "c++14"
  Sets \f(CW\*(C`_\|_traits(getTargetInfo, "cppStd")\*(C'\fR to \f(CW201402\fR.
! .IP \fBc++17\fR 4
  .IX Item "c++17"
  Sets \f(CW\*(C`_\|_traits(getTargetInfo, "cppStd")\*(C'\fR to \f(CW201703\fR.
  This is the default.
! .IP \fBc++20\fR 4
  .IX Item "c++20"
  Sets \f(CW\*(C`_\|_traits(getTargetInfo, "cppStd")\*(C'\fR to \f(CW202002\fR.
  .RE
  .RS 4
  .RE
! .IP \fB\-fno\-invariants\fR 4
  .IX Item "-fno-invariants"
  Turns off code generation for class \f(CW\*(C`invariant\*(C'\fR contracts.
! .IP \fB\-fmain\fR 4
  .IX Item "-fmain"
! Generates a default \f(CWmain()\fR function when compiling.  This is useful when
  unittesting a library, as it enables running the unittests in a library without
! having to manually define an entry\-point function.  This option does nothing
  when \f(CW\*(C`main\*(C'\fR is already defined in user code.
! .IP \fB\-fno\-moduleinfo\fR 4
  .IX Item "-fno-moduleinfo"
  Turns off generation of the \f(CW\*(C`ModuleInfo\*(C'\fR and related functions
  that would become unreferenced without it, which may allow linking
*************** to programs not written in D.  Functions
*** 320,398 ****
  include module constructors and destructors (\f(CW\*(C`static this\*(C'\fR and
  \&\f(CW\*(C`static ~this\*(C'\fR), \f(CW\*(C`unittest\*(C'\fR code, and \f(CW\*(C`DSO\*(C'\fR registry
  functions for dynamically linked code.
! .IP "\fB\-fonly=\fR\fIfilename\fR" 4
  .IX Item "-fonly=filename"
  Tells the compiler to parse and run semantic analysis on all modules
  on the command line, but only generate code for the module specified
  by \fIfilename\fR.
! .IP "\fB\-fno\-postconditions\fR" 4
  .IX Item "-fno-postconditions"
  Turns off code generation for postcondition \f(CW\*(C`out\*(C'\fR contracts.
! .IP "\fB\-fno\-preconditions\fR" 4
  .IX Item "-fno-preconditions"
  Turns off code generation for precondition \f(CW\*(C`in\*(C'\fR contracts.
! .IP "\fB\-fpreview=\fR\fIid\fR" 4
  .IX Item "-fpreview=id"
  Turns on an upcoming D language change identified by \fIid\fR.  The following
  values are supported:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
  Turns on all upcoming D language features.
! .IP "\fBbitfields\fR" 4
  .IX Item "bitfields"
! Implements bit-fields in D.
! .IP "\fBdip1000\fR" 4
  .IX Item "dip1000"
  Implements <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md\fR>
  (Scoped pointers).
! .IP "\fBdip1008\fR" 4
  .IX Item "dip1008"
  Implements <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md\fR>
  (Allow exceptions in \f(CW@nogc\fR code).
! .IP "\fBdip1021\fR" 4
  .IX Item "dip1021"
  Implements <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md\fR>
  (Mutable function arguments).
! .IP "\fBdip25\fR" 4
  .IX Item "dip25"
  Implements <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP25.md\fR>
  (Sealed references).
! .IP "\fBdtorfields\fR" 4
  .IX Item "dtorfields"
  Turns on generation for destructing fields of partially constructed objects.
! .IP "\fBfieldwise\fR" 4
  .IX Item "fieldwise"
! Turns on generation of struct equality to use field-wise comparisons.
! .IP "\fBfixaliasthis\fR" 4
  .IX Item "fixaliasthis"
  Implements new lookup rules that check the current scope for \f(CW\*(C`alias this\*(C'\fR
  before searching in upper scopes.
! .IP "\fBfiximmutableconv\fR" 4
  .IX Item "fiximmutableconv"
  Disallows unsound immutable conversions that were formerly incorrectly
  permitted.
! .IP "\fBin\fR" 4
  .IX Item "in"
  Implements \f(CW\*(C`in\*(C'\fR parameters to mean \f(CW\*(C`scope const [ref]\*(C'\fR and accepts
  rvalues.
! .IP "\fBinclusiveincontracts\fR" 4
  .IX Item "inclusiveincontracts"
  Implements \f(CW\*(C`in\*(C'\fR contracts of overridden methods to be a superset of parent
  contract.
! .IP "\fBnosharedaccess\fR" 4
  .IX Item "nosharedaccess"
  Turns off and disallows all access to shared memory objects.
! .IP "\fBrvaluerefparam\fR" 4
  .IX Item "rvaluerefparam"
  Implements rvalue arguments to \f(CW\*(C`ref\*(C'\fR parameters.
! .IP "\fBsystemvariables\fR" 4
  .IX Item "systemvariables"
  Disables access to variables marked \f(CW@system\fR from \f(CW@safe\fR code.
  .RE
  .RS 4
  .RE
! .IP "\fB\-frelease\fR" 4
  .IX Item "-frelease"
  Turns on compiling in release mode, which means not emitting runtime
  checks for contracts and asserts.  Array bounds checking is not done
--- 245,323 ----
  include module constructors and destructors (\f(CW\*(C`static this\*(C'\fR and
  \&\f(CW\*(C`static ~this\*(C'\fR), \f(CW\*(C`unittest\*(C'\fR code, and \f(CW\*(C`DSO\*(C'\fR registry
  functions for dynamically linked code.
! .IP \fB\-fonly=\fR\fIfilename\fR 4
  .IX Item "-fonly=filename"
  Tells the compiler to parse and run semantic analysis on all modules
  on the command line, but only generate code for the module specified
  by \fIfilename\fR.
! .IP \fB\-fno\-postconditions\fR 4
  .IX Item "-fno-postconditions"
  Turns off code generation for postcondition \f(CW\*(C`out\*(C'\fR contracts.
! .IP \fB\-fno\-preconditions\fR 4
  .IX Item "-fno-preconditions"
  Turns off code generation for precondition \f(CW\*(C`in\*(C'\fR contracts.
! .IP \fB\-fpreview=\fR\fIid\fR 4
  .IX Item "-fpreview=id"
  Turns on an upcoming D language change identified by \fIid\fR.  The following
  values are supported:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
  Turns on all upcoming D language features.
! .IP \fBbitfields\fR 4
  .IX Item "bitfields"
! Implements bit\-fields in D.
! .IP \fBdip1000\fR 4
  .IX Item "dip1000"
  Implements <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md\fR>
  (Scoped pointers).
! .IP \fBdip1008\fR 4
  .IX Item "dip1008"
  Implements <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1008.md\fR>
  (Allow exceptions in \f(CW@nogc\fR code).
! .IP \fBdip1021\fR 4
  .IX Item "dip1021"
  Implements <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/accepted/DIP1021.md\fR>
  (Mutable function arguments).
! .IP \fBdip25\fR 4
  .IX Item "dip25"
  Implements <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP25.md\fR>
  (Sealed references).
! .IP \fBdtorfields\fR 4
  .IX Item "dtorfields"
  Turns on generation for destructing fields of partially constructed objects.
! .IP \fBfieldwise\fR 4
  .IX Item "fieldwise"
! Turns on generation of struct equality to use field\-wise comparisons.
! .IP \fBfixaliasthis\fR 4
  .IX Item "fixaliasthis"
  Implements new lookup rules that check the current scope for \f(CW\*(C`alias this\*(C'\fR
  before searching in upper scopes.
! .IP \fBfiximmutableconv\fR 4
  .IX Item "fiximmutableconv"
  Disallows unsound immutable conversions that were formerly incorrectly
  permitted.
! .IP \fBin\fR 4
  .IX Item "in"
  Implements \f(CW\*(C`in\*(C'\fR parameters to mean \f(CW\*(C`scope const [ref]\*(C'\fR and accepts
  rvalues.
! .IP \fBinclusiveincontracts\fR 4
  .IX Item "inclusiveincontracts"
  Implements \f(CW\*(C`in\*(C'\fR contracts of overridden methods to be a superset of parent
  contract.
! .IP \fBnosharedaccess\fR 4
  .IX Item "nosharedaccess"
  Turns off and disallows all access to shared memory objects.
! .IP \fBrvaluerefparam\fR 4
  .IX Item "rvaluerefparam"
  Implements rvalue arguments to \f(CW\*(C`ref\*(C'\fR parameters.
! .IP \fBsystemvariables\fR 4
  .IX Item "systemvariables"
  Disables access to variables marked \f(CW@system\fR from \f(CW@safe\fR code.
  .RE
  .RS 4
  .RE
! .IP \fB\-frelease\fR 4
  .IX Item "-frelease"
  Turns on compiling in release mode, which means not emitting runtime
  checks for contracts and asserts.  Array bounds checking is not done
*************** This is equivalent to compiling with the
*** 405,491 ****
  \&        gdc \-fno\-assert \-fbounds\-check=safe \-fno\-invariants \e
  \&            \-fno\-postconditions \-fno\-preconditions \-fno\-switch\-errors
  .Ve
! .IP "\fB\-frevert=\fR" 4
  .IX Item "-frevert="
  Turns off a D language feature identified by \fIid\fR.  The following values
  are supported:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
  Turns off all revertable D language features.
! .IP "\fBdip1000\fR" 4
  .IX Item "dip1000"
  Reverts <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md\fR>
  (Scoped pointers).
! .IP "\fBdip25\fR" 4
  .IX Item "dip25"
  Reverts <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP25.md\fR>
  (Sealed references).
! .IP "\fBdtorfields\fR" 4
  .IX Item "dtorfields"
  Turns off generation for destructing fields of partially constructed objects.
! .IP "\fBintpromote\fR" 4
  .IX Item "intpromote"
  Turns off C\-style integral promotion for unary \f(CW\*(C`+\*(C'\fR, \f(CW\*(C`\-\*(C'\fR and \f(CW\*(C`~\*(C'\fR
  expressions.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fno\-rtti\fR" 4
  .IX Item "-fno-rtti"
! Turns off generation of run-time type information for all user defined types.
  Any code that uses features of the language that require access to this
  information will result in an error.
! .IP "\fB\-fno\-switch\-errors\fR" 4
  .IX Item "-fno-switch-errors"
  This option controls what code is generated when no case is matched
  in a \f(CW\*(C`final switch\*(C'\fR statement.  The default run time behavior
  is to throw a \f(CW\*(C`SwitchError\*(C'\fR.  Turning off \fB\-fswitch\-errors\fR
  means that instead the execution of the program is immediately halted.
! .IP "\fB\-funittest\fR" 4
  .IX Item "-funittest"
  Turns on compilation of \f(CW\*(C`unittest\*(C'\fR code, and turns on the
! \&\f(CW\*(C`version(unittest)\*(C'\fR identifier.  This implies \fB\-fassert\fR.
! .IP "\fB\-fversion=\fR\fIvalue\fR" 4
  .IX Item "-fversion=value"
  Turns on compilation of conditional \f(CW\*(C`version\*(C'\fR code into the program
  identified by any of the following values:
  .RS 4
! .IP "\fBident\fR" 4
  .IX Item "ident"
  Turns on compilation of \f(CW\*(C`version\*(C'\fR code identified by \fIident\fR.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fno\-weak\-templates\fR" 4
  .IX Item "-fno-weak-templates"
  Turns off emission of declarations that can be defined in multiple objects as
  weak symbols.  The default is to emit all public symbols as weak, unless the
  target lacks support for weak symbols.  Disabling this option means that common
! symbols are instead put in \s-1COMDAT\s0 or become private.
  .SS "Options for Directory Search"
  .IX Subsection "Options for Directory Search"
  These options specify directories to search for files, libraries, and
  other parts of the compiler:
! .IP "\fB\-I\fR\fIdir\fR" 4
  .IX Item "-Idir"
  Specify a directory to use when searching for imported modules at
  compile time.  Multiple \fB\-I\fR options can be used, and the
  paths are searched in the same order.
! .IP "\fB\-J\fR\fIdir\fR" 4
  .IX Item "-Jdir"
  Specify a directory to use when searching for files in string imports
  at compile time.  This switch is required in order to use
! \&\f(CW\*(C`import(file)\*(C'\fR expressions.  Multiple \fB\-J\fR options can be
  used, and the paths are searched in the same order.
! .IP "\fB\-L\fR\fIdir\fR" 4
  .IX Item "-Ldir"
  When linking, specify a library search directory, as with \fBgcc\fR.
! .IP "\fB\-B\fR\fIdir\fR" 4
  .IX Item "-Bdir"
  This option specifies where to find the executables, libraries,
  source files, and data files of the compiler itself, as with \fBgcc\fR.
! .IP "\fB\-fmodule\-file=\fR\fImodule\fR\fB=\fR\fIspec\fR" 4
  .IX Item "-fmodule-file=module=spec"
  This option manipulates file paths of imported modules, such that if an
  imported module matches all or the leftmost part of \fImodule\fR, the file
--- 330,416 ----
  \&        gdc \-fno\-assert \-fbounds\-check=safe \-fno\-invariants \e
  \&            \-fno\-postconditions \-fno\-preconditions \-fno\-switch\-errors
  .Ve
! .IP \fB\-frevert=\fR 4
  .IX Item "-frevert="
  Turns off a D language feature identified by \fIid\fR.  The following values
  are supported:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
  Turns off all revertable D language features.
! .IP \fBdip1000\fR 4
  .IX Item "dip1000"
  Reverts <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1000.md\fR>
  (Scoped pointers).
! .IP \fBdip25\fR 4
  .IX Item "dip25"
  Reverts <\fBhttps://github.com/dlang/DIPs/blob/master/DIPs/archive/DIP25.md\fR>
  (Sealed references).
! .IP \fBdtorfields\fR 4
  .IX Item "dtorfields"
  Turns off generation for destructing fields of partially constructed objects.
! .IP \fBintpromote\fR 4
  .IX Item "intpromote"
  Turns off C\-style integral promotion for unary \f(CW\*(C`+\*(C'\fR, \f(CW\*(C`\-\*(C'\fR and \f(CW\*(C`~\*(C'\fR
  expressions.
  .RE
  .RS 4
  .RE
! .IP \fB\-fno\-rtti\fR 4
  .IX Item "-fno-rtti"
! Turns off generation of run\-time type information for all user defined types.
  Any code that uses features of the language that require access to this
  information will result in an error.
! .IP \fB\-fno\-switch\-errors\fR 4
  .IX Item "-fno-switch-errors"
  This option controls what code is generated when no case is matched
  in a \f(CW\*(C`final switch\*(C'\fR statement.  The default run time behavior
  is to throw a \f(CW\*(C`SwitchError\*(C'\fR.  Turning off \fB\-fswitch\-errors\fR
  means that instead the execution of the program is immediately halted.
! .IP \fB\-funittest\fR 4
  .IX Item "-funittest"
  Turns on compilation of \f(CW\*(C`unittest\*(C'\fR code, and turns on the
! \&\f(CWversion(unittest)\fR identifier.  This implies \fB\-fassert\fR.
! .IP \fB\-fversion=\fR\fIvalue\fR 4
  .IX Item "-fversion=value"
  Turns on compilation of conditional \f(CW\*(C`version\*(C'\fR code into the program
  identified by any of the following values:
  .RS 4
! .IP \fBident\fR 4
  .IX Item "ident"
  Turns on compilation of \f(CW\*(C`version\*(C'\fR code identified by \fIident\fR.
  .RE
  .RS 4
  .RE
! .IP \fB\-fno\-weak\-templates\fR 4
  .IX Item "-fno-weak-templates"
  Turns off emission of declarations that can be defined in multiple objects as
  weak symbols.  The default is to emit all public symbols as weak, unless the
  target lacks support for weak symbols.  Disabling this option means that common
! symbols are instead put in COMDAT or become private.
  .SS "Options for Directory Search"
  .IX Subsection "Options for Directory Search"
  These options specify directories to search for files, libraries, and
  other parts of the compiler:
! .IP \fB\-I\fR\fIdir\fR 4
  .IX Item "-Idir"
  Specify a directory to use when searching for imported modules at
  compile time.  Multiple \fB\-I\fR options can be used, and the
  paths are searched in the same order.
! .IP \fB\-J\fR\fIdir\fR 4
  .IX Item "-Jdir"
  Specify a directory to use when searching for files in string imports
  at compile time.  This switch is required in order to use
! \&\f(CWimport(file)\fR expressions.  Multiple \fB\-J\fR options can be
  used, and the paths are searched in the same order.
! .IP \fB\-L\fR\fIdir\fR 4
  .IX Item "-Ldir"
  When linking, specify a library search directory, as with \fBgcc\fR.
! .IP \fB\-B\fR\fIdir\fR 4
  .IX Item "-Bdir"
  This option specifies where to find the executables, libraries,
  source files, and data files of the compiler itself, as with \fBgcc\fR.
! .IP \fB\-fmodule\-file=\fR\fImodule\fR\fB=\fR\fIspec\fR 4
  .IX Item "-fmodule-file=module=spec"
  This option manipulates file paths of imported modules, such that if an
  imported module matches all or the leftmost part of \fImodule\fR, the file
*************** when importing \fIC\fR, as annotated in
*** 510,522 ****
  .IP "\fB\-imultilib\fR \fIdir\fR" 4
  .IX Item "-imultilib dir"
  Use \fIdir\fR as a subdirectory of the gcc directory containing
! target-specific D sources and interfaces.
  .IP "\fB\-iprefix\fR \fIprefix\fR" 4
  .IX Item "-iprefix prefix"
  Specify \fIprefix\fR as the prefix for the gcc directory containing
! target-specific D sources and interfaces.  If the \fIprefix\fR represents
  a directory, you should include the final \f(CW\*(Aq/\*(Aq\fR.
! .IP "\fB\-nostdinc\fR" 4
  .IX Item "-nostdinc"
  Do not search the standard system directories for D source and interface
  files.  Only the directories that have been specified with \fB\-I\fR options
--- 435,447 ----
  .IP "\fB\-imultilib\fR \fIdir\fR" 4
  .IX Item "-imultilib dir"
  Use \fIdir\fR as a subdirectory of the gcc directory containing
! target\-specific D sources and interfaces.
  .IP "\fB\-iprefix\fR \fIprefix\fR" 4
  .IX Item "-iprefix prefix"
  Specify \fIprefix\fR as the prefix for the gcc directory containing
! target\-specific D sources and interfaces.  If the \fIprefix\fR represents
  a directory, you should include the final \f(CW\*(Aq/\*(Aq\fR.
! .IP \fB\-nostdinc\fR 4
  .IX Item "-nostdinc"
  Do not search the standard system directories for D source and interface
  files.  Only the directories that have been specified with \fB\-I\fR options
*************** files.  Only the directories that have b
*** 525,531 ****
  .IX Subsection "Code Generation"
  In addition to the many \fBgcc\fR options controlling code generation,
  \&\fBgdc\fR has several options specific to itself.
! .IP "\fB\-H\fR" 4
  .IX Item "-H"
  Generates D interface files for all modules being compiled.  The compiler
  determines the output file based on the name of the input file, removes
--- 450,456 ----
  .IX Subsection "Code Generation"
  In addition to the many \fBgcc\fR options controlling code generation,
  \&\fBgdc\fR has several options specific to itself.
! .IP \fB\-H\fR 4
  .IX Item "-H"
  Generates D interface files for all modules being compiled.  The compiler
  determines the output file based on the name of the input file, removes
*************** output file and directory path.
*** 540,552 ****
  Same as \fB\-H\fR but writes interface files to \fIfile\fR.  This option can
  be used with \fB\-Hd\fR \fIdir\fR to independently set the output file and
  directory path.
! .IP "\fB\-M\fR" 4
  .IX Item "-M"
  Output the module dependencies of all source files being compiled in a
  format suitable for \fBmake\fR.  The compiler outputs one
  \&\fBmake\fR rule containing the object file name for that source file,
  a colon, and the names of all imported files.
! .IP "\fB\-MM\fR" 4
  .IX Item "-MM"
  Like \fB\-M\fR but does not mention imported modules from the D standard
  library package directories.
--- 465,477 ----
  Same as \fB\-H\fR but writes interface files to \fIfile\fR.  This option can
  be used with \fB\-Hd\fR \fIdir\fR to independently set the output file and
  directory path.
! .IP \fB\-M\fR 4
  .IX Item "-M"
  Output the module dependencies of all source files being compiled in a
  format suitable for \fBmake\fR.  The compiler outputs one
  \&\fBmake\fR rule containing the object file name for that source file,
  a colon, and the names of all imported files.
! .IP \fB\-MM\fR 4
  .IX Item "-MM"
  Like \fB\-M\fR but does not mention imported modules from the D standard
  library package directories.
*************** library package directories.
*** 555,565 ****
  When used with \fB\-M\fR or \fB\-MM\fR, specifies a \fIfile\fR to write
  the dependencies to.  When used with the driver options \fB\-MD\fR or
  \&\fB\-MMD\fR, \fB\-MF\fR overrides the default dependency output file.
! .IP "\fB\-MG\fR" 4
  .IX Item "-MG"
  This option is for compatibility with \fBgcc\fR, and is ignored by the
  compiler.
! .IP "\fB\-MP\fR" 4
  .IX Item "-MP"
  Outputs a phony target for each dependency other than the modules being
  compiled, causing each to depend on nothing.
--- 480,490 ----
  When used with \fB\-M\fR or \fB\-MM\fR, specifies a \fIfile\fR to write
  the dependencies to.  When used with the driver options \fB\-MD\fR or
  \&\fB\-MMD\fR, \fB\-MF\fR overrides the default dependency output file.
! .IP \fB\-MG\fR 4
  .IX Item "-MG"
  This option is for compatibility with \fBgcc\fR, and is ignored by the
  compiler.
! .IP \fB\-MP\fR 4
  .IX Item "-MP"
  Outputs a phony target for each dependency other than the modules being
  compiled, causing each to depend on nothing.
*************** multiple \fB\-MT\fR options.
*** 573,666 ****
  .IX Item "-MQ target"
  Same as \fB\-MT\fR, but it quotes any characters which are special to
  \&\fBmake\fR.
! .IP "\fB\-MD\fR" 4
  .IX Item "-MD"
  This option is equivalent to \fB\-M \-MF\fR \fIfile\fR.  The driver
  determines \fIfile\fR by removing any directory components and suffix
  from the input file, and then adding a \fI.deps\fR suffix.
! .IP "\fB\-MMD\fR" 4
  .IX Item "-MMD"
  Like \fB\-MD\fR but does not mention imported modules from the D standard
  library package directories.
! .IP "\fB\-X\fR" 4
  .IX Item "-X"
  Output information describing the contents of all source files being
! compiled in \s-1JSON\s0 format to a file.  The driver determines \fIfile\fR by
  removing any directory components and suffix from the input file, and then
  adding a \fI.json\fR suffix.
  .IP "\fB\-Xf\fR \fIfile\fR" 4
  .IX Item "-Xf file"
! Same as \fB\-X\fR, but writes all \s-1JSON\s0 contents to the specified
  \&\fIfile\fR.
! .IP "\fB\-fdoc\fR" 4
  .IX Item "-fdoc"
  Generates \f(CW\*(C`Ddoc\*(C'\fR documentation and writes it to a file.  The compiler
  determines \fIfile\fR by removing any directory components and suffix
  from the input file, and then adding a \fI.html\fR suffix.
! .IP "\fB\-fdoc\-dir=\fR\fIdir\fR" 4
  .IX Item "-fdoc-dir=dir"
  Same as \fB\-fdoc\fR, but writes documentation to directory \fIdir\fR.
  This option can be used with \fB\-fdoc\-file=\fR\fIfile\fR to
  independently set the output file and directory path.
! .IP "\fB\-fdoc\-file=\fR\fIfile\fR" 4
  .IX Item "-fdoc-file=file"
  Same as \fB\-fdoc\fR, but writes documentation to \fIfile\fR.  This
  option can be used with \fB\-fdoc\-dir=\fR\fIdir\fR to independently
  set the output file and directory path.
! .IP "\fB\-fdoc\-inc=\fR\fIfile\fR" 4
  .IX Item "-fdoc-inc=file"
  Specify \fIfile\fR as a \fIDdoc\fR macro file to be read.  Multiple
  \&\fB\-fdoc\-inc\fR options can be used, and files are read and processed
  in the same order.
! .IP "\fB\-fdump\-c++\-spec=\fR\fIfile\fR" 4
  .IX Item "-fdump-c++-spec=file"
! For D source files, generate corresponding \*(C+ declarations in \fIfile\fR.
! .IP "\fB\-fdump\-c++\-spec\-verbose\fR" 4
  .IX Item "-fdump-c++-spec-verbose"
  In conjunction with \fB\-fdump\-c++\-spec=\fR above, add comments for ignored
! declarations in the generated \*(C+ header.
! .IP "\fB\-fsave\-mixins=\fR\fIfile\fR" 4
  .IX Item "-fsave-mixins=file"
  Generates code expanded from D \f(CW\*(C`mixin\*(C'\fR statements and writes the
  processed sources to \fIfile\fR.  This is useful to debug errors in compilation
  and provides source for debuggers to show when requested.
! .SS "Warnings"
  .IX Subsection "Warnings"
  Warnings are diagnostic messages that report constructions that
  are not inherently erroneous but that are risky or suggest there
  is likely to be a bug in the program.  Unless \fB\-Werror\fR is
  specified, they do not prevent compilation of the program.
! .IP "\fB\-Wall\fR" 4
  .IX Item "-Wall"
  Turns on all warnings messages.  Warnings are not a defined part of
  the D language, and all constructs for which this may generate a
  warning message are valid code.
! .IP "\fB\-Walloca\fR" 4
  .IX Item "-Walloca"
! This option warns on all uses of \*(L"alloca\*(R" in the source.
! .IP "\fB\-Walloca\-larger\-than=\fR\fIn\fR" 4
  .IX Item "-Walloca-larger-than=n"
  Warn on unbounded uses of alloca, and on bounded uses of alloca
  whose bound can be larger than \fIn\fR bytes.
  \&\fB\-Wno\-alloca\-larger\-than\fR disables
  \&\fB\-Walloca\-larger\-than\fR warning and is equivalent to
! \&\fB\-Walloca\-larger\-than=\fR\fI\s-1SIZE_MAX\s0\fR or larger.
! .IP "\fB\-Wno\-builtin\-declaration\-mismatch\fR" 4
  .IX Item "-Wno-builtin-declaration-mismatch"
! Warn if a built-in function is declared with an incompatible signature.
! .IP "\fB\-Wcast\-result\fR" 4
  .IX Item "-Wcast-result"
  Warn about casts that will produce a null or zero result.  Currently
! this is only done for casting between an imaginary and non-imaginary
! data type, or casting between a D and \*(C+ class.
! .IP "\fB\-Wno\-deprecated\fR" 4
  .IX Item "-Wno-deprecated"
  Do not warn about usage of deprecated features and symbols with
  \&\f(CW\*(C`deprecated\*(C'\fR attributes.
! .IP "\fB\-Werror\fR" 4
  .IX Item "-Werror"
  Turns all warnings into errors.
! .IP "\fB\-Wextra\fR" 4
  .IX Item "-Wextra"
  This enables some extra warning flags that are not enabled by
  \&\fB\-Wall\fR.
--- 498,591 ----
  .IX Item "-MQ target"
  Same as \fB\-MT\fR, but it quotes any characters which are special to
  \&\fBmake\fR.
! .IP \fB\-MD\fR 4
  .IX Item "-MD"
  This option is equivalent to \fB\-M \-MF\fR \fIfile\fR.  The driver
  determines \fIfile\fR by removing any directory components and suffix
  from the input file, and then adding a \fI.deps\fR suffix.
! .IP \fB\-MMD\fR 4
  .IX Item "-MMD"
  Like \fB\-MD\fR but does not mention imported modules from the D standard
  library package directories.
! .IP \fB\-X\fR 4
  .IX Item "-X"
  Output information describing the contents of all source files being
! compiled in JSON format to a file.  The driver determines \fIfile\fR by
  removing any directory components and suffix from the input file, and then
  adding a \fI.json\fR suffix.
  .IP "\fB\-Xf\fR \fIfile\fR" 4
  .IX Item "-Xf file"
! Same as \fB\-X\fR, but writes all JSON contents to the specified
  \&\fIfile\fR.
! .IP \fB\-fdoc\fR 4
  .IX Item "-fdoc"
  Generates \f(CW\*(C`Ddoc\*(C'\fR documentation and writes it to a file.  The compiler
  determines \fIfile\fR by removing any directory components and suffix
  from the input file, and then adding a \fI.html\fR suffix.
! .IP \fB\-fdoc\-dir=\fR\fIdir\fR 4
  .IX Item "-fdoc-dir=dir"
  Same as \fB\-fdoc\fR, but writes documentation to directory \fIdir\fR.
  This option can be used with \fB\-fdoc\-file=\fR\fIfile\fR to
  independently set the output file and directory path.
! .IP \fB\-fdoc\-file=\fR\fIfile\fR 4
  .IX Item "-fdoc-file=file"
  Same as \fB\-fdoc\fR, but writes documentation to \fIfile\fR.  This
  option can be used with \fB\-fdoc\-dir=\fR\fIdir\fR to independently
  set the output file and directory path.
! .IP \fB\-fdoc\-inc=\fR\fIfile\fR 4
  .IX Item "-fdoc-inc=file"
  Specify \fIfile\fR as a \fIDdoc\fR macro file to be read.  Multiple
  \&\fB\-fdoc\-inc\fR options can be used, and files are read and processed
  in the same order.
! .IP \fB\-fdump\-c++\-spec=\fR\fIfile\fR 4
  .IX Item "-fdump-c++-spec=file"
! For D source files, generate corresponding C++ declarations in \fIfile\fR.
! .IP \fB\-fdump\-c++\-spec\-verbose\fR 4
  .IX Item "-fdump-c++-spec-verbose"
  In conjunction with \fB\-fdump\-c++\-spec=\fR above, add comments for ignored
! declarations in the generated C++ header.
! .IP \fB\-fsave\-mixins=\fR\fIfile\fR 4
  .IX Item "-fsave-mixins=file"
  Generates code expanded from D \f(CW\*(C`mixin\*(C'\fR statements and writes the
  processed sources to \fIfile\fR.  This is useful to debug errors in compilation
  and provides source for debuggers to show when requested.
! .SS Warnings
  .IX Subsection "Warnings"
  Warnings are diagnostic messages that report constructions that
  are not inherently erroneous but that are risky or suggest there
  is likely to be a bug in the program.  Unless \fB\-Werror\fR is
  specified, they do not prevent compilation of the program.
! .IP \fB\-Wall\fR 4
  .IX Item "-Wall"
  Turns on all warnings messages.  Warnings are not a defined part of
  the D language, and all constructs for which this may generate a
  warning message are valid code.
! .IP \fB\-Walloca\fR 4
  .IX Item "-Walloca"
! This option warns on all uses of "alloca" in the source.
! .IP \fB\-Walloca\-larger\-than=\fR\fIn\fR 4
  .IX Item "-Walloca-larger-than=n"
  Warn on unbounded uses of alloca, and on bounded uses of alloca
  whose bound can be larger than \fIn\fR bytes.
  \&\fB\-Wno\-alloca\-larger\-than\fR disables
  \&\fB\-Walloca\-larger\-than\fR warning and is equivalent to
! \&\fB\-Walloca\-larger\-than=\fR\fISIZE_MAX\fR or larger.
! .IP \fB\-Wno\-builtin\-declaration\-mismatch\fR 4
  .IX Item "-Wno-builtin-declaration-mismatch"
! Warn if a built\-in function is declared with an incompatible signature.
! .IP \fB\-Wcast\-result\fR 4
  .IX Item "-Wcast-result"
  Warn about casts that will produce a null or zero result.  Currently
! this is only done for casting between an imaginary and non\-imaginary
! data type, or casting between a D and C++ class.
! .IP \fB\-Wno\-deprecated\fR 4
  .IX Item "-Wno-deprecated"
  Do not warn about usage of deprecated features and symbols with
  \&\f(CW\*(C`deprecated\*(C'\fR attributes.
! .IP \fB\-Werror\fR 4
  .IX Item "-Werror"
  Turns all warnings into errors.
! .IP \fB\-Wextra\fR 4
  .IX Item "-Wextra"
  This enables some extra warning flags that are not enabled by
  \&\fB\-Wall\fR.
*************** This enables some extra warning flags th
*** 669,733 ****
  \&\-Wcast\-result
  \&\-Wmismatched\-special\-enum
  \&\-Wunknown\-pragmas\fR
! .IP "\fB\-Wmismatched\-special\-enum\fR" 4
  .IX Item "-Wmismatched-special-enum"
  Warn when an enum the compiler recognizes as special is declared with a
! different size to the built-in type it is representing.
! .IP "\fB\-Wspeculative\fR" 4
  .IX Item "-Wspeculative"
  List all error messages from speculative compiles, such as
  \&\f(CW\*(C`_\|_traits(compiles, ...)\*(C'\fR.  This option does not report
  messages as warnings, and these messages therefore never become
  errors when the \fB\-Werror\fR option is also used.
! .IP "\fB\-Wunknown\-pragmas\fR" 4
  .IX Item "-Wunknown-pragmas"
! Warn when a \f(CW\*(C`pragma()\*(C'\fR is encountered that is not understood by
  \&\fBgdc\fR.  This differs from \fB\-fignore\-unknown\-pragmas\fR
  where a pragma that is part of the D language, but not implemented by
! the compiler, won't get reported.
! .IP "\fB\-Wno\-varargs\fR" 4
  .IX Item "-Wno-varargs"
  Do not warn upon questionable usage of the macros used to handle variable
  arguments like \f(CW\*(C`va_start\*(C'\fR.
! .IP "\fB\-fignore\-unknown\-pragmas\fR" 4
  .IX Item "-fignore-unknown-pragmas"
  Turns off errors for unsupported pragmas.
! .IP "\fB\-fmax\-errors=\fR\fIn\fR" 4
  .IX Item "-fmax-errors=n"
  Limits the maximum number of error messages to \fIn\fR, at which point
  \&\fBgdc\fR bails out rather than attempting to continue processing the
  source code.  If \fIn\fR is 0 (the default), there is no limit on the
  number of error messages produced.
! .IP "\fB\-fsyntax\-only\fR" 4
  .IX Item "-fsyntax-only"
  Check the code for syntax errors, but do not actually compile it.  This
  can be used in conjunction with \fB\-fdoc\fR or \fB\-H\fR to generate
! files for each module present on the command-line, but no other output
  file.
! .IP "\fB\-ftransition=\fR\fIid\fR" 4
  .IX Item "-ftransition=id"
  Report additional information about D language changes identified by
  \&\fIid\fR.  The following values are supported:
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
  List information on all D language transitions.
! .IP "\fBcomplex\fR" 4
  .IX Item "complex"
  List all usages of complex or imaginary types.
! .IP "\fBfield\fR" 4
  .IX Item "field"
! List all non-mutable fields which occupy an object instance.
! .IP "\fBin\fR" 4
  .IX Item "in"
  List all usages of \f(CW\*(C`in\*(C'\fR on parameter.
! .IP "\fBnogc\fR" 4
  .IX Item "nogc"
! List all hidden \s-1GC\s0 allocations.
! .IP "\fBtemplates\fR" 4
  .IX Item "templates"
  List statistics on template instantiations.
! .IP "\fBtls\fR" 4
  .IX Item "tls"
  List all variables going into thread local storage.
  .RE
--- 594,658 ----
  \&\-Wcast\-result
  \&\-Wmismatched\-special\-enum
  \&\-Wunknown\-pragmas\fR
! .IP \fB\-Wmismatched\-special\-enum\fR 4
  .IX Item "-Wmismatched-special-enum"
  Warn when an enum the compiler recognizes as special is declared with a
! different size to the built\-in type it is representing.
! .IP \fB\-Wspeculative\fR 4
  .IX Item "-Wspeculative"
  List all error messages from speculative compiles, such as
  \&\f(CW\*(C`_\|_traits(compiles, ...)\*(C'\fR.  This option does not report
  messages as warnings, and these messages therefore never become
  errors when the \fB\-Werror\fR option is also used.
! .IP \fB\-Wunknown\-pragmas\fR 4
  .IX Item "-Wunknown-pragmas"
! Warn when a \f(CWpragma()\fR is encountered that is not understood by
  \&\fBgdc\fR.  This differs from \fB\-fignore\-unknown\-pragmas\fR
  where a pragma that is part of the D language, but not implemented by
! the compiler, won\*(Aqt get reported.
! .IP \fB\-Wno\-varargs\fR 4
  .IX Item "-Wno-varargs"
  Do not warn upon questionable usage of the macros used to handle variable
  arguments like \f(CW\*(C`va_start\*(C'\fR.
! .IP \fB\-fignore\-unknown\-pragmas\fR 4
  .IX Item "-fignore-unknown-pragmas"
  Turns off errors for unsupported pragmas.
! .IP \fB\-fmax\-errors=\fR\fIn\fR 4
  .IX Item "-fmax-errors=n"
  Limits the maximum number of error messages to \fIn\fR, at which point
  \&\fBgdc\fR bails out rather than attempting to continue processing the
  source code.  If \fIn\fR is 0 (the default), there is no limit on the
  number of error messages produced.
! .IP \fB\-fsyntax\-only\fR 4
  .IX Item "-fsyntax-only"
  Check the code for syntax errors, but do not actually compile it.  This
  can be used in conjunction with \fB\-fdoc\fR or \fB\-H\fR to generate
! files for each module present on the command\-line, but no other output
  file.
! .IP \fB\-ftransition=\fR\fIid\fR 4
  .IX Item "-ftransition=id"
  Report additional information about D language changes identified by
  \&\fIid\fR.  The following values are supported:
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
  List information on all D language transitions.
! .IP \fBcomplex\fR 4
  .IX Item "complex"
  List all usages of complex or imaginary types.
! .IP \fBfield\fR 4
  .IX Item "field"
! List all non\-mutable fields which occupy an object instance.
! .IP \fBin\fR 4
  .IX Item "in"
  List all usages of \f(CW\*(C`in\*(C'\fR on parameter.
! .IP \fBnogc\fR 4
  .IX Item "nogc"
! List all hidden GC allocations.
! .IP \fBtemplates\fR 4
  .IX Item "templates"
  List statistics on template instantiations.
! .IP \fBtls\fR 4
  .IX Item "tls"
  List all variables going into thread local storage.
  .RE
*************** List all variables going into thread loc
*** 738,767 ****
  These options come into play when the compiler links object files into an
  executable output file.  They are meaningless if the compiler is not doing
  a link step.
! .IP "\fB\-defaultlib=\fR\fIlibname\fR" 4
  .IX Item "-defaultlib=libname"
  Specify the library to use instead of libphobos when linking.  Options
  specifying the linkage of libphobos, such as \fB\-static\-libphobos\fR
  or \fB\-shared\-libphobos\fR, are ignored.
! .IP "\fB\-debuglib=\fR\fIlibname\fR" 4
  .IX Item "-debuglib=libname"
  Specify the debug library to use instead of libphobos when linking.
  This option has no effect unless the \fB\-g\fR option was also given
  on the command line.  Options specifying the linkage of libphobos, such
  as \fB\-static\-libphobos\fR or \fB\-shared\-libphobos\fR, are ignored.
! .IP "\fB\-nophoboslib\fR" 4
  .IX Item "-nophoboslib"
  Do not use the Phobos or D runtime library when linking.  Options specifying
  the linkage of libphobos, such as \fB\-static\-libphobos\fR or
  \&\fB\-shared\-libphobos\fR, are ignored.  The standard system libraries are
  used normally, unless \fB\-nostdlib\fR or \fB\-nodefaultlibs\fR is used.
! .IP "\fB\-shared\-libphobos\fR" 4
  .IX Item "-shared-libphobos"
  On systems that provide \fIlibgphobos\fR and \fIlibgdruntime\fR as a
  shared and a static library, this option forces the use of the shared
  version.  If no shared version was built when the compiler was configured,
  this option has no effect.
! .IP "\fB\-static\-libphobos\fR" 4
  .IX Item "-static-libphobos"
  On systems that provide \fIlibgphobos\fR and \fIlibgdruntime\fR as a
  shared and a static library, this option forces the use of the static
--- 663,692 ----
  These options come into play when the compiler links object files into an
  executable output file.  They are meaningless if the compiler is not doing
  a link step.
! .IP \fB\-defaultlib=\fR\fIlibname\fR 4
  .IX Item "-defaultlib=libname"
  Specify the library to use instead of libphobos when linking.  Options
  specifying the linkage of libphobos, such as \fB\-static\-libphobos\fR
  or \fB\-shared\-libphobos\fR, are ignored.
! .IP \fB\-debuglib=\fR\fIlibname\fR 4
  .IX Item "-debuglib=libname"
  Specify the debug library to use instead of libphobos when linking.
  This option has no effect unless the \fB\-g\fR option was also given
  on the command line.  Options specifying the linkage of libphobos, such
  as \fB\-static\-libphobos\fR or \fB\-shared\-libphobos\fR, are ignored.
! .IP \fB\-nophoboslib\fR 4
  .IX Item "-nophoboslib"
  Do not use the Phobos or D runtime library when linking.  Options specifying
  the linkage of libphobos, such as \fB\-static\-libphobos\fR or
  \&\fB\-shared\-libphobos\fR, are ignored.  The standard system libraries are
  used normally, unless \fB\-nostdlib\fR or \fB\-nodefaultlibs\fR is used.
! .IP \fB\-shared\-libphobos\fR 4
  .IX Item "-shared-libphobos"
  On systems that provide \fIlibgphobos\fR and \fIlibgdruntime\fR as a
  shared and a static library, this option forces the use of the shared
  version.  If no shared version was built when the compiler was configured,
  this option has no effect.
! .IP \fB\-static\-libphobos\fR 4
  .IX Item "-static-libphobos"
  On systems that provide \fIlibgphobos\fR and \fIlibgdruntime\fR as a
  shared and a static library, this option forces the use of the static
*************** version.  If no static version was built
*** 769,781 ****
  this option has no effect.
  .SS "Developer Options"
  .IX Subsection "Developer Options"
! This section describes command-line options that are primarily of
  interest to developers or language tooling.
! .IP "\fB\-fdump\-d\-original\fR" 4
  .IX Item "-fdump-d-original"
! Output the internal front-end \s-1AST\s0 after the \f(CW\*(C`semantic3\*(C'\fR stage.
! This option is only useful for debugging the \s-1GNU D\s0 compiler itself.
! .IP "\fB\-v\fR" 4
  .IX Item "-v"
  Dump information about the compiler language processing stages as the source
  program is being compiled.  This includes listing all modules that are
--- 694,706 ----
  this option has no effect.
  .SS "Developer Options"
  .IX Subsection "Developer Options"
! This section describes command\-line options that are primarily of
  interest to developers or language tooling.
! .IP \fB\-fdump\-d\-original\fR 4
  .IX Item "-fdump-d-original"
! Output the internal front\-end AST after the \f(CW\*(C`semantic3\*(C'\fR stage.
! This option is only useful for debugging the GNU D compiler itself.
! .IP \fB\-v\fR 4
  .IX Item "-v"
  Dump information about the compiler language processing stages as the source
  program is being compiled.  This includes listing all modules that are
*************** and all \f(CW\*(C`function\*(C'\fR bodie
*** 786,798 ****
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7), \fBgcc\fR\|(1)
  and the Info entries for \fIgdc\fR and \fIgcc\fR.
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 2006\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with no
! Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
  A copy of the license is included in the
  man page \fBgfdl\fR\|(7).
--- 711,723 ----
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7), \fBgcc\fR\|(1)
  and the Info entries for \fIgdc\fR and \fIgcc\fR.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 2006\-2023 Free Software Foundation, Inc.
  .PP
  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
  man page \fBgfdl\fR\|(7).
diff -Nrcpad gcc-13.4.0/gcc/doc/gdc.info gcc-13.5.0-RC-20260904/gcc/doc/gdc.info
*** gcc-13.4.0/gcc/doc/gdc.info	Thu Jun  5 16:30:28 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gdc.info	Fri Sep  4 07:57:49 2026
***************
*** 1,6 ****
! This is gdc.info, produced by makeinfo version 6.8 from gdc.texi.
  
! Copyright (C) 2006-2023 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
--- 1,6 ----
! This is gdc.info, produced by makeinfo version 7.1 from gdc.texi.
  
! Copyright © 2006-2023 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
*************** START-INFO-DIR-ENTRY
*** 14,20 ****
  END-INFO-DIR-ENTRY
  
  
!    Copyright (C) 2006-2023 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
--- 14,20 ----
  END-INFO-DIR-ENTRY
  
  
!    Copyright © 2006-2023 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
*************** File: gdc.info,  Node: Top,  Next: Invok
*** 29,37 ****
  Introduction
  ************
  
! This manual describes how to use 'gdc', the GNU compiler for the D
  programming language.  This manual is specifically about how to invoke
! 'gdc', as well as its features and incompatibilities.  For more
  information about the D programming language in general, including
  language specifications and standard package documentation, see
  .
--- 29,37 ----
  Introduction
  ************
  
! This manual describes how to use ‘gdc’, the GNU compiler for the D
  programming language.  This manual is specifically about how to invoke
! ‘gdc’, as well as its features and incompatibilities.  For more
  information about the D programming language in general, including
  language specifications and standard package documentation, see
  .
*************** File: gdc.info,  Node: Invoking gdc,  Ne
*** 52,60 ****
  1 Invoking gdc
  **************
  
! The 'gdc' command is the GNU compiler for the D language and supports
! many of the same options as 'gcc'.  *Note Option Summary: (gcc)Option
! Summary.  This manual only documents the options specific to 'gdc'.
  
  * Menu:
  
--- 52,60 ----
  1 Invoking gdc
  **************
  
! The ‘gdc’ command is the GNU compiler for the D language and supports
! many of the same options as ‘gcc’.  *Note Option Summary: (gcc)Option
! Summary.  This manual only documents the options specific to ‘gdc’.
  
  * Menu:
  
*************** For any given input file, the file name
*** 77,105 ****
  compilation is done.  The following kinds of input file names are
  supported:
  
! 'FILE.d'
       D source files.
! 'FILE.dd'
       Ddoc source files.
! 'FILE.di'
       D interface files.
  
!    You can specify more than one input file on the 'gdc' command line,
  each being compiled separately in the compilation process.  If you
! specify a '-o FILE' option, all the input files are compiled together,
  producing a single output file, named FILE.  This is allowed even when
! using '-S' or '-c'.
  
     A D interface file contains only what an import of the module needs,
  rather than the whole implementation of that module.  They can be
! created by 'gdc' from a D source file by using the '-H' option.  When
  the compiler resolves an import declaration, it searches for matching
! '.di' files first, then for '.d'.
  
     A Ddoc source file contains code in the D macro processor language.
  It is primarily designed for use in producing user documentation from
  embedded comments, with a slight affinity towards HTML generation.  If a
! '.d' source file starts with the string 'Ddoc' then it is treated as
  general purpose documentation, not as a D source file.
  
  
--- 77,105 ----
  compilation is done.  The following kinds of input file names are
  supported:
  
! ‘FILE.d’
       D source files.
! ‘FILE.dd’
       Ddoc source files.
! ‘FILE.di’
       D interface files.
  
!    You can specify more than one input file on the ‘gdc’ command line,
  each being compiled separately in the compilation process.  If you
! specify a ‘-o FILE’ option, all the input files are compiled together,
  producing a single output file, named FILE.  This is allowed even when
! using ‘-S’ or ‘-c’.
  
     A D interface file contains only what an import of the module needs,
  rather than the whole implementation of that module.  They can be
! created by ‘gdc’ from a D source file by using the ‘-H’ option.  When
  the compiler resolves an import declaration, it searches for matching
! ‘.di’ files first, then for ‘.d’.
  
     A Ddoc source file contains code in the D macro processor language.
  It is primarily designed for use in producing user documentation from
  embedded comments, with a slight affinity towards HTML generation.  If a
! ‘.d’ source file starts with the string ‘Ddoc’ then it is treated as
  general purpose documentation, not as a D source file.
  
  
*************** File: gdc.info,  Node: Runtime Options,
*** 109,174 ****
  ===================
  
  These options affect the runtime behavior of programs compiled with
! 'gdc'.
  
! '-fall-instantiations'
       Generate code for all template instantiations.  The default
       template emission strategy is to not generate code for declarations
       that were either instantiated speculatively, such as from
!      '__traits(compiles, ...)', or that come from an imported module not
       being compiled.
  
! '-fno-assert'
!      Turn off code generation for 'assert' contracts.
  
! '-fno-bounds-check'
       Turns off array bounds checking for all functions, which can
       improve performance for code that uses arrays extensively.  Note
       that this can result in unpredictable behavior if the code in
       question actually does violate array bounds constraints.  It is
       safe to use this option if you are sure that your code never throws
!      a 'RangeError'.
  
! '-fbounds-check=VALUE'
!      An alternative to '-fbounds-check' that allows more control as to
       where bounds checking is turned on or off.  The following values
       are supported:
  
!      'on'
            Turns on array bounds checking for all functions.
!      'safeonly'
!           Turns on array bounds checking only for '@safe' functions.
!      'off'
            Turns off array bounds checking completely.
  
! '-fno-builtin'
       Don't recognize built-in functions unless they begin with the
!      prefix '__builtin_'.  By default, the compiler will recognize when
!      a function in the 'core.stdc' package is a built-in function.
  
! '-fcheckaction=VALUE'
       This option controls what code is generated on an assertion, bounds
       check, or final switch failure.  The following values are
       supported:
  
!      'context'
!           Throw an 'AssertError' with extra context information.
!      'halt'
            Halt the program execution.
!      'throw'
!           Throw an 'AssertError' (the default).
  
! '-fdebug'
! '-fdebug=VALUE'
!      Turn on compilation of conditional 'debug' code into the program.
!      The '-fdebug' option itself sets the debug level to '1', while
!      '-fdebug=' enables 'debug' code that are identified by any of the
       following values:
  
!      'ident'
!           Turns on compilation of any 'debug' code identified by IDENT.
  
! '-fno-druntime'
       Implements .  Assumes that
       compilation targets an environment without a D runtime library.
  
--- 109,174 ----
  ===================
  
  These options affect the runtime behavior of programs compiled with
! ‘gdc’.
  
! ‘-fall-instantiations’
       Generate code for all template instantiations.  The default
       template emission strategy is to not generate code for declarations
       that were either instantiated speculatively, such as from
!      ‘__traits(compiles, ...)’, or that come from an imported module not
       being compiled.
  
! ‘-fno-assert’
!      Turn off code generation for ‘assert’ contracts.
  
! ‘-fno-bounds-check’
       Turns off array bounds checking for all functions, which can
       improve performance for code that uses arrays extensively.  Note
       that this can result in unpredictable behavior if the code in
       question actually does violate array bounds constraints.  It is
       safe to use this option if you are sure that your code never throws
!      a ‘RangeError’.
  
! ‘-fbounds-check=VALUE’
!      An alternative to ‘-fbounds-check’ that allows more control as to
       where bounds checking is turned on or off.  The following values
       are supported:
  
!      ‘on’
            Turns on array bounds checking for all functions.
!      ‘safeonly’
!           Turns on array bounds checking only for ‘@safe’ functions.
!      ‘off’
            Turns off array bounds checking completely.
  
! ‘-fno-builtin’
       Don't recognize built-in functions unless they begin with the
!      prefix ‘__builtin_’.  By default, the compiler will recognize when
!      a function in the ‘core.stdc’ package is a built-in function.
  
! ‘-fcheckaction=VALUE’
       This option controls what code is generated on an assertion, bounds
       check, or final switch failure.  The following values are
       supported:
  
!      ‘context’
!           Throw an ‘AssertError’ with extra context information.
!      ‘halt’
            Halt the program execution.
!      ‘throw’
!           Throw an ‘AssertError’ (the default).
  
! ‘-fdebug’
! ‘-fdebug=VALUE’
!      Turn on compilation of conditional ‘debug’ code into the program.
!      The ‘-fdebug’ option itself sets the debug level to ‘1’, while
!      ‘-fdebug=’ enables ‘debug’ code that are identified by any of the
       following values:
  
!      ‘ident’
!           Turns on compilation of any ‘debug’ code identified by IDENT.
  
! ‘-fno-druntime’
       Implements .  Assumes that
       compilation targets an environment without a D runtime library.
  
*************** These options affect the runtime behavio
*** 176,281 ****
  
            gdc -nophoboslib -fno-exceptions -fno-moduleinfo -fno-rtti
  
! '-fextern-std=STANDARD'
       Sets the C++ name mangling compatibility to the version identified
       by STANDARD.  The following values are supported:
  
!      'c++98'
!      'c++03'
!           Sets '__traits(getTargetInfo, "cppStd")' to '199711'.
!      'c++11'
!           Sets '__traits(getTargetInfo, "cppStd")' to '201103'.
!      'c++14'
!           Sets '__traits(getTargetInfo, "cppStd")' to '201402'.
!      'c++17'
!           Sets '__traits(getTargetInfo, "cppStd")' to '201703'.  This is
            the default.
!      'c++20'
!           Sets '__traits(getTargetInfo, "cppStd")' to '202002'.
  
! '-fno-invariants'
!      Turns off code generation for class 'invariant' contracts.
  
! '-fmain'
!      Generates a default 'main()' function when compiling.  This is
       useful when unittesting a library, as it enables running the
       unittests in a library without having to manually define an
!      entry-point function.  This option does nothing when 'main' is
       already defined in user code.
  
! '-fno-moduleinfo'
!      Turns off generation of the 'ModuleInfo' and related functions that
       would become unreferenced without it, which may allow linking to
       programs not written in D. Functions that are not be generated
!      include module constructors and destructors ('static this' and
!      'static ~this'), 'unittest' code, and 'DSO' registry functions for
       dynamically linked code.
  
! '-fonly=FILENAME'
       Tells the compiler to parse and run semantic analysis on all
       modules on the command line, but only generate code for the module
       specified by FILENAME.
  
! '-fno-postconditions'
!      Turns off code generation for postcondition 'out' contracts.
  
! '-fno-preconditions'
!      Turns off code generation for precondition 'in' contracts.
  
! '-fpreview=ID'
       Turns on an upcoming D language change identified by ID.  The
       following values are supported:
  
!      'all'
            Turns on all upcoming D language features.
!      'bitfields'
            Implements bit-fields in D.
!      'dip1000'
            Implements
            
            (Scoped pointers).
!      'dip1008'
            Implements
            
!           (Allow exceptions in '@nogc' code).
!      'dip1021'
            Implements
            
            (Mutable function arguments).
!      'dip25'
            Implements
            
            (Sealed references).
!      'dtorfields'
            Turns on generation for destructing fields of partially
            constructed objects.
!      'fieldwise'
            Turns on generation of struct equality to use field-wise
            comparisons.
!      'fixaliasthis'
            Implements new lookup rules that check the current scope for
!           'alias this' before searching in upper scopes.
!      'fiximmutableconv'
            Disallows unsound immutable conversions that were formerly
            incorrectly permitted.
!      'in'
!           Implements 'in' parameters to mean 'scope const [ref]' and
            accepts rvalues.
!      'inclusiveincontracts'
!           Implements 'in' contracts of overridden methods to be a
            superset of parent contract.
!      'nosharedaccess'
            Turns off and disallows all access to shared memory objects.
!      'rvaluerefparam'
!           Implements rvalue arguments to 'ref' parameters.
!      'systemvariables'
!           Disables access to variables marked '@system' from '@safe'
            code.
  
! '-frelease'
       Turns on compiling in release mode, which means not emitting
       runtime checks for contracts and asserts.  Array bounds checking is
!      not done for '@system' and '@trusted' functions, and assertion
       failures are undefined behavior.
  
       This is equivalent to compiling with the following options:
--- 176,281 ----
  
            gdc -nophoboslib -fno-exceptions -fno-moduleinfo -fno-rtti
  
! ‘-fextern-std=STANDARD’
       Sets the C++ name mangling compatibility to the version identified
       by STANDARD.  The following values are supported:
  
!      ‘c++98’
!      ‘c++03’
!           Sets ‘__traits(getTargetInfo, "cppStd")’ to ‘199711’.
!      ‘c++11’
!           Sets ‘__traits(getTargetInfo, "cppStd")’ to ‘201103’.
!      ‘c++14’
!           Sets ‘__traits(getTargetInfo, "cppStd")’ to ‘201402’.
!      ‘c++17’
!           Sets ‘__traits(getTargetInfo, "cppStd")’ to ‘201703’.  This is
            the default.
!      ‘c++20’
!           Sets ‘__traits(getTargetInfo, "cppStd")’ to ‘202002’.
  
! ‘-fno-invariants’
!      Turns off code generation for class ‘invariant’ contracts.
  
! ‘-fmain’
!      Generates a default ‘main()’ function when compiling.  This is
       useful when unittesting a library, as it enables running the
       unittests in a library without having to manually define an
!      entry-point function.  This option does nothing when ‘main’ is
       already defined in user code.
  
! ‘-fno-moduleinfo’
!      Turns off generation of the ‘ModuleInfo’ and related functions that
       would become unreferenced without it, which may allow linking to
       programs not written in D. Functions that are not be generated
!      include module constructors and destructors (‘static this’ and
!      ‘static ~this’), ‘unittest’ code, and ‘DSO’ registry functions for
       dynamically linked code.
  
! ‘-fonly=FILENAME’
       Tells the compiler to parse and run semantic analysis on all
       modules on the command line, but only generate code for the module
       specified by FILENAME.
  
! ‘-fno-postconditions’
!      Turns off code generation for postcondition ‘out’ contracts.
  
! ‘-fno-preconditions’
!      Turns off code generation for precondition ‘in’ contracts.
  
! ‘-fpreview=ID’
       Turns on an upcoming D language change identified by ID.  The
       following values are supported:
  
!      ‘all’
            Turns on all upcoming D language features.
!      ‘bitfields’
            Implements bit-fields in D.
!      ‘dip1000’
            Implements
            
            (Scoped pointers).
!      ‘dip1008’
            Implements
            
!           (Allow exceptions in ‘@nogc’ code).
!      ‘dip1021’
            Implements
            
            (Mutable function arguments).
!      ‘dip25’
            Implements
            
            (Sealed references).
!      ‘dtorfields’
            Turns on generation for destructing fields of partially
            constructed objects.
!      ‘fieldwise’
            Turns on generation of struct equality to use field-wise
            comparisons.
!      ‘fixaliasthis’
            Implements new lookup rules that check the current scope for
!           ‘alias this’ before searching in upper scopes.
!      ‘fiximmutableconv’
            Disallows unsound immutable conversions that were formerly
            incorrectly permitted.
!      ‘in’
!           Implements ‘in’ parameters to mean ‘scope const [ref]’ and
            accepts rvalues.
!      ‘inclusiveincontracts’
!           Implements ‘in’ contracts of overridden methods to be a
            superset of parent contract.
!      ‘nosharedaccess’
            Turns off and disallows all access to shared memory objects.
!      ‘rvaluerefparam’
!           Implements rvalue arguments to ‘ref’ parameters.
!      ‘systemvariables’
!           Disables access to variables marked ‘@system’ from ‘@safe’
            code.
  
! ‘-frelease’
       Turns on compiling in release mode, which means not emitting
       runtime checks for contracts and asserts.  Array bounds checking is
!      not done for ‘@system’ and ‘@trusted’ functions, and assertion
       failures are undefined behavior.
  
       This is equivalent to compiling with the following options:
*************** These options affect the runtime behavio
*** 283,332 ****
            gdc -fno-assert -fbounds-check=safe -fno-invariants \
                -fno-postconditions -fno-preconditions -fno-switch-errors
  
! '-frevert='
       Turns off a D language feature identified by ID.  The following
       values are supported:
  
!      'all'
            Turns off all revertable D language features.
!      'dip1000'
            Reverts
            
            (Scoped pointers).
!      'dip25'
            Reverts
            
            (Sealed references).
!      'dtorfields'
            Turns off generation for destructing fields of partially
            constructed objects.
!      'intpromote'
!           Turns off C-style integral promotion for unary '+', '-' and
!           '~' expressions.
  
! '-fno-rtti'
       Turns off generation of run-time type information for all user
       defined types.  Any code that uses features of the language that
       require access to this information will result in an error.
  
! '-fno-switch-errors'
       This option controls what code is generated when no case is matched
!      in a 'final switch' statement.  The default run time behavior is to
!      throw a 'SwitchError'.  Turning off '-fswitch-errors' means that
       instead the execution of the program is immediately halted.
  
! '-funittest'
!      Turns on compilation of 'unittest' code, and turns on the
!      'version(unittest)' identifier.  This implies '-fassert'.
  
! '-fversion=VALUE'
!      Turns on compilation of conditional 'version' code into the program
       identified by any of the following values:
  
!      'ident'
!           Turns on compilation of 'version' code identified by IDENT.
  
! '-fno-weak-templates'
       Turns off emission of declarations that can be defined in multiple
       objects as weak symbols.  The default is to emit all public symbols
       as weak, unless the target lacks support for weak symbols.
--- 283,332 ----
            gdc -fno-assert -fbounds-check=safe -fno-invariants \
                -fno-postconditions -fno-preconditions -fno-switch-errors
  
! ‘-frevert=’
       Turns off a D language feature identified by ID.  The following
       values are supported:
  
!      ‘all’
            Turns off all revertable D language features.
!      ‘dip1000’
            Reverts
            
            (Scoped pointers).
!      ‘dip25’
            Reverts
            
            (Sealed references).
!      ‘dtorfields’
            Turns off generation for destructing fields of partially
            constructed objects.
!      ‘intpromote’
!           Turns off C-style integral promotion for unary ‘+’, ‘-’ and
!           ‘~’ expressions.
  
! ‘-fno-rtti’
       Turns off generation of run-time type information for all user
       defined types.  Any code that uses features of the language that
       require access to this information will result in an error.
  
! ‘-fno-switch-errors’
       This option controls what code is generated when no case is matched
!      in a ‘final switch’ statement.  The default run time behavior is to
!      throw a ‘SwitchError’.  Turning off ‘-fswitch-errors’ means that
       instead the execution of the program is immediately halted.
  
! ‘-funittest’
!      Turns on compilation of ‘unittest’ code, and turns on the
!      ‘version(unittest)’ identifier.  This implies ‘-fassert’.
  
! ‘-fversion=VALUE’
!      Turns on compilation of conditional ‘version’ code into the program
       identified by any of the following values:
  
!      ‘ident’
!           Turns on compilation of ‘version’ code identified by IDENT.
  
! ‘-fno-weak-templates’
       Turns off emission of declarations that can be defined in multiple
       objects as weak symbols.  The default is to emit all public symbols
       as weak, unless the target lacks support for weak symbols.
*************** File: gdc.info,  Node: Directory Options
*** 342,366 ****
  These options specify directories to search for files, libraries, and
  other parts of the compiler:
  
! '-IDIR'
       Specify a directory to use when searching for imported modules at
!      compile time.  Multiple '-I' options can be used, and the paths are
       searched in the same order.
  
! '-JDIR'
       Specify a directory to use when searching for files in string
       imports at compile time.  This switch is required in order to use
!      'import(file)' expressions.  Multiple '-J' options can be used, and
       the paths are searched in the same order.
  
! '-LDIR'
!      When linking, specify a library search directory, as with 'gcc'.
  
! '-BDIR'
       This option specifies where to find the executables, libraries,
!      source files, and data files of the compiler itself, as with 'gcc'.
  
! '-fmodule-file=MODULE=SPEC'
       This option manipulates file paths of imported modules, such that
       if an imported module matches all or the leftmost part of MODULE,
       the file path in SPEC is used as the location to search for D
--- 342,366 ----
  These options specify directories to search for files, libraries, and
  other parts of the compiler:
  
! ‘-IDIR’
       Specify a directory to use when searching for imported modules at
!      compile time.  Multiple ‘-I’ options can be used, and the paths are
       searched in the same order.
  
! ‘-JDIR’
       Specify a directory to use when searching for files in string
       imports at compile time.  This switch is required in order to use
!      ‘import(file)’ expressions.  Multiple ‘-J’ options can be used, and
       the paths are searched in the same order.
  
! ‘-LDIR’
!      When linking, specify a library search directory, as with ‘gcc’.
  
! ‘-BDIR’
       This option specifies where to find the executables, libraries,
!      source files, and data files of the compiler itself, as with ‘gcc’.
  
! ‘-fmodule-file=MODULE=SPEC’
       This option manipulates file paths of imported modules, such that
       if an imported module matches all or the leftmost part of MODULE,
       the file path in SPEC is used as the location to search for D
*************** other parts of the compiler:
*** 379,397 ****
            import C.D.E;   // Matches C, searches for bar/D/E.d
            import A.B.C;   // No match, searches for A/B/C.d
  
! '-imultilib DIR'
       Use DIR as a subdirectory of the gcc directory containing
       target-specific D sources and interfaces.
  
! '-iprefix PREFIX'
       Specify PREFIX as the prefix for the gcc directory containing
       target-specific D sources and interfaces.  If the PREFIX represents
!      a directory, you should include the final ''/''.
  
! '-nostdinc'
       Do not search the standard system directories for D source and
       interface files.  Only the directories that have been specified
!      with '-I' options (and the directory of the current file, if
       appropriate) are searched.
  
  
--- 379,397 ----
            import C.D.E;   // Matches C, searches for bar/D/E.d
            import A.B.C;   // No match, searches for A/B/C.d
  
! ‘-imultilib DIR’
       Use DIR as a subdirectory of the gcc directory containing
       target-specific D sources and interfaces.
  
! ‘-iprefix PREFIX’
       Specify PREFIX as the prefix for the gcc directory containing
       target-specific D sources and interfaces.  If the PREFIX represents
!      a directory, you should include the final ‘'/'’.
  
! ‘-nostdinc’
       Do not search the standard system directories for D source and
       interface files.  Only the directories that have been specified
!      with ‘-I’ options (and the directory of the current file, if
       appropriate) are searched.
  
  
*************** File: gdc.info,  Node: Code Generation,
*** 400,505 ****
  1.4 Code Generation
  ===================
  
! In addition to the many 'gcc' options controlling code generation, 'gdc'
  has several options specific to itself.
  
! '-H'
       Generates D interface files for all modules being compiled.  The
       compiler determines the output file based on the name of the input
       file, removes any directory components and suffix, and applies the
!      '.di' suffix.
  
! '-Hd DIR'
!      Same as '-H', but writes interface files to directory DIR.  This
!      option can be used with '-Hf FILE' to independently set the output
       file and directory path.
  
! '-Hf FILE'
!      Same as '-H' but writes interface files to FILE.  This option can
!      be used with '-Hd DIR' to independently set the output file and
       directory path.
  
! '-M'
       Output the module dependencies of all source files being compiled
!      in a format suitable for 'make'.  The compiler outputs one 'make'
       rule containing the object file name for that source file, a colon,
       and the names of all imported files.
  
! '-MM'
!      Like '-M' but does not mention imported modules from the D standard
       library package directories.
  
! '-MF FILE'
!      When used with '-M' or '-MM', specifies a FILE to write the
!      dependencies to.  When used with the driver options '-MD' or
!      '-MMD', '-MF' overrides the default dependency output file.
  
! '-MG'
!      This option is for compatibility with 'gcc', and is ignored by the
       compiler.
  
! '-MP'
       Outputs a phony target for each dependency other than the modules
       being compiled, causing each to depend on nothing.
  
! '-MT TARGET'
       Change the TARGET of the rule emitted by dependency generation 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.
  
! '-MQ TARGET'
!      Same as '-MT', but it quotes any characters which are special to
!      'make'.
  
! '-MD'
!      This option is equivalent to '-M -MF FILE'.  The driver determines
       FILE by removing any directory components and suffix from the input
!      file, and then adding a '.deps' suffix.
  
! '-MMD'
!      Like '-MD' but does not mention imported modules from the D
       standard library package directories.
  
! '-X'
       Output information describing the contents of all source files
       being compiled in JSON format to a file.  The driver determines
       FILE by removing any directory components and suffix from the input
!      file, and then adding a '.json' suffix.
  
! '-Xf FILE'
!      Same as '-X', but writes all JSON contents to the specified FILE.
  
! '-fdoc'
!      Generates 'Ddoc' documentation and writes it to a file.  The
       compiler determines FILE by removing any directory components and
!      suffix from the input file, and then adding a '.html' suffix.
  
! '-fdoc-dir=DIR'
!      Same as '-fdoc', but writes documentation to directory DIR.  This
!      option can be used with '-fdoc-file=FILE' to independently set the
       output file and directory path.
  
! '-fdoc-file=FILE'
!      Same as '-fdoc', but writes documentation to FILE.  This option can
!      be used with '-fdoc-dir=DIR' to independently set the output file
       and directory path.
  
! '-fdoc-inc=FILE'
!      Specify FILE as a DDOC macro file to be read.  Multiple '-fdoc-inc'
       options can be used, and files are read and processed in the same
       order.
  
! '-fdump-c++-spec=FILE'
       For D source files, generate corresponding C++ declarations in
       FILE.
  
! '-fdump-c++-spec-verbose'
!      In conjunction with '-fdump-c++-spec=' above, add comments for
       ignored declarations in the generated C++ header.
  
! '-fsave-mixins=FILE'
!      Generates code expanded from D 'mixin' statements and writes the
       processed sources to FILE.  This is useful to debug errors in
       compilation and provides source for debuggers to show when
       requested.
--- 400,505 ----
  1.4 Code Generation
  ===================
  
! In addition to the many ‘gcc’ options controlling code generation, ‘gdc’
  has several options specific to itself.
  
! ‘-H’
       Generates D interface files for all modules being compiled.  The
       compiler determines the output file based on the name of the input
       file, removes any directory components and suffix, and applies the
!      ‘.di’ suffix.
  
! ‘-Hd DIR’
!      Same as ‘-H’, but writes interface files to directory DIR.  This
!      option can be used with ‘-Hf FILE’ to independently set the output
       file and directory path.
  
! ‘-Hf FILE’
!      Same as ‘-H’ but writes interface files to FILE.  This option can
!      be used with ‘-Hd DIR’ to independently set the output file and
       directory path.
  
! ‘-M’
       Output the module dependencies of all source files being compiled
!      in a format suitable for ‘make’.  The compiler outputs one ‘make’
       rule containing the object file name for that source file, a colon,
       and the names of all imported files.
  
! ‘-MM’
!      Like ‘-M’ but does not mention imported modules from the D standard
       library package directories.
  
! ‘-MF FILE’
!      When used with ‘-M’ or ‘-MM’, specifies a FILE to write the
!      dependencies to.  When used with the driver options ‘-MD’ or
!      ‘-MMD’, ‘-MF’ overrides the default dependency output file.
  
! ‘-MG’
!      This option is for compatibility with ‘gcc’, and is ignored by the
       compiler.
  
! ‘-MP’
       Outputs a phony target for each dependency other than the modules
       being compiled, causing each to depend on nothing.
  
! ‘-MT TARGET’
       Change the TARGET of the rule emitted by dependency generation 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.
  
! ‘-MQ TARGET’
!      Same as ‘-MT’, but it quotes any characters which are special to
!      ‘make’.
  
! ‘-MD’
!      This option is equivalent to ‘-M -MF FILE’.  The driver determines
       FILE by removing any directory components and suffix from the input
!      file, and then adding a ‘.deps’ suffix.
  
! ‘-MMD’
!      Like ‘-MD’ but does not mention imported modules from the D
       standard library package directories.
  
! ‘-X’
       Output information describing the contents of all source files
       being compiled in JSON format to a file.  The driver determines
       FILE by removing any directory components and suffix from the input
!      file, and then adding a ‘.json’ suffix.
  
! ‘-Xf FILE’
!      Same as ‘-X’, but writes all JSON contents to the specified FILE.
  
! ‘-fdoc’
!      Generates ‘Ddoc’ documentation and writes it to a file.  The
       compiler determines FILE by removing any directory components and
!      suffix from the input file, and then adding a ‘.html’ suffix.
  
! ‘-fdoc-dir=DIR’
!      Same as ‘-fdoc’, but writes documentation to directory DIR.  This
!      option can be used with ‘-fdoc-file=FILE’ to independently set the
       output file and directory path.
  
! ‘-fdoc-file=FILE’
!      Same as ‘-fdoc’, but writes documentation to FILE.  This option can
!      be used with ‘-fdoc-dir=DIR’ to independently set the output file
       and directory path.
  
! ‘-fdoc-inc=FILE’
!      Specify FILE as a DDOC macro file to be read.  Multiple ‘-fdoc-inc’
       options can be used, and files are read and processed in the same
       order.
  
! ‘-fdump-c++-spec=FILE’
       For D source files, generate corresponding C++ declarations in
       FILE.
  
! ‘-fdump-c++-spec-verbose’
!      In conjunction with ‘-fdump-c++-spec=’ above, add comments for
       ignored declarations in the generated C++ header.
  
! ‘-fsave-mixins=FILE’
!      Generates code expanded from D ‘mixin’ statements and writes the
       processed sources to FILE.  This is useful to debug errors in
       compilation and provides source for debuggers to show when
       requested.
*************** File: gdc.info,  Node: Warnings,  Next:
*** 512,611 ****
  
  Warnings are diagnostic messages that report constructions that are not
  inherently erroneous but that are risky or suggest there is likely to be
! a bug in the program.  Unless '-Werror' is specified, they do not
  prevent compilation of the program.
  
! '-Wall'
       Turns on all warnings messages.  Warnings are not a defined part of
       the D language, and all constructs for which this may generate a
       warning message are valid code.
  
! '-Walloca'
       This option warns on all uses of "alloca" in the source.
  
! '-Walloca-larger-than=N'
       Warn on unbounded uses of alloca, and on bounded uses of alloca
!      whose bound can be larger than N bytes.  '-Wno-alloca-larger-than'
!      disables '-Walloca-larger-than' warning and is equivalent to
!      '-Walloca-larger-than=SIZE_MAX' or larger.
  
! '-Wno-builtin-declaration-mismatch'
       Warn if a built-in function is declared with an incompatible
       signature.
  
! '-Wcast-result'
       Warn about casts that will produce a null or zero result.
       Currently this is only done for casting between an imaginary and
       non-imaginary data type, or casting between a D and C++ class.
  
! '-Wno-deprecated'
       Do not warn about usage of deprecated features and symbols with
!      'deprecated' attributes.
  
! '-Werror'
       Turns all warnings into errors.
  
! '-Wextra'
       This enables some extra warning flags that are not enabled by
!      '-Wall'.
  
            -Waddress
            -Wcast-result
            -Wmismatched-special-enum
            -Wunknown-pragmas
  
! '-Wmismatched-special-enum'
       Warn when an enum the compiler recognizes as special is declared
       with a different size to the built-in type it is representing.
  
! '-Wspeculative'
       List all error messages from speculative compiles, such as
!      '__traits(compiles, ...)'.  This option does not report messages as
       warnings, and these messages therefore never become errors when the
!      '-Werror' option is also used.
  
! '-Wunknown-pragmas'
!      Warn when a 'pragma()' is encountered that is not understood by
!      'gdc'.  This differs from '-fignore-unknown-pragmas' where a pragma
       that is part of the D language, but not implemented by the
       compiler, won't get reported.
  
! '-Wno-varargs'
       Do not warn upon questionable usage of the macros used to handle
!      variable arguments like 'va_start'.
  
! '-fignore-unknown-pragmas'
       Turns off errors for unsupported pragmas.
  
! '-fmax-errors=N'
       Limits the maximum number of error messages to N, at which point
!      'gdc' 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.
  
! '-fsyntax-only'
       Check the code for syntax errors, but do not actually compile it.
!      This can be used in conjunction with '-fdoc' or '-H' to generate
       files for each module present on the command-line, but no other
       output file.
  
! '-ftransition=ID'
       Report additional information about D language changes identified
       by ID.  The following values are supported:
  
!      'all'
            List information on all D language transitions.
!      'complex'
            List all usages of complex or imaginary types.
!      'field'
            List all non-mutable fields which occupy an object instance.
!      'in'
!           List all usages of 'in' on parameter.
!      'nogc'
            List all hidden GC allocations.
!      'templates'
            List statistics on template instantiations.
!      'tls'
            List all variables going into thread local storage.
  
  
--- 512,611 ----
  
  Warnings are diagnostic messages that report constructions that are not
  inherently erroneous but that are risky or suggest there is likely to be
! a bug in the program.  Unless ‘-Werror’ is specified, they do not
  prevent compilation of the program.
  
! ‘-Wall’
       Turns on all warnings messages.  Warnings are not a defined part of
       the D language, and all constructs for which this may generate a
       warning message are valid code.
  
! ‘-Walloca’
       This option warns on all uses of "alloca" in the source.
  
! ‘-Walloca-larger-than=N’
       Warn on unbounded uses of alloca, and on bounded uses of alloca
!      whose bound can be larger than N bytes.  ‘-Wno-alloca-larger-than’
!      disables ‘-Walloca-larger-than’ warning and is equivalent to
!      ‘-Walloca-larger-than=SIZE_MAX’ or larger.
  
! ‘-Wno-builtin-declaration-mismatch’
       Warn if a built-in function is declared with an incompatible
       signature.
  
! ‘-Wcast-result’
       Warn about casts that will produce a null or zero result.
       Currently this is only done for casting between an imaginary and
       non-imaginary data type, or casting between a D and C++ class.
  
! ‘-Wno-deprecated’
       Do not warn about usage of deprecated features and symbols with
!      ‘deprecated’ attributes.
  
! ‘-Werror’
       Turns all warnings into errors.
  
! ‘-Wextra’
       This enables some extra warning flags that are not enabled by
!      ‘-Wall’.
  
            -Waddress
            -Wcast-result
            -Wmismatched-special-enum
            -Wunknown-pragmas
  
! ‘-Wmismatched-special-enum’
       Warn when an enum the compiler recognizes as special is declared
       with a different size to the built-in type it is representing.
  
! ‘-Wspeculative’
       List all error messages from speculative compiles, such as
!      ‘__traits(compiles, ...)’.  This option does not report messages as
       warnings, and these messages therefore never become errors when the
!      ‘-Werror’ option is also used.
  
! ‘-Wunknown-pragmas’
!      Warn when a ‘pragma()’ is encountered that is not understood by
!      ‘gdc’.  This differs from ‘-fignore-unknown-pragmas’ where a pragma
       that is part of the D language, but not implemented by the
       compiler, won't get reported.
  
! ‘-Wno-varargs’
       Do not warn upon questionable usage of the macros used to handle
!      variable arguments like ‘va_start’.
  
! ‘-fignore-unknown-pragmas’
       Turns off errors for unsupported pragmas.
  
! ‘-fmax-errors=N’
       Limits the maximum number of error messages to N, at which point
!      ‘gdc’ 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.
  
! ‘-fsyntax-only’
       Check the code for syntax errors, but do not actually compile it.
!      This can be used in conjunction with ‘-fdoc’ or ‘-H’ to generate
       files for each module present on the command-line, but no other
       output file.
  
! ‘-ftransition=ID’
       Report additional information about D language changes identified
       by ID.  The following values are supported:
  
!      ‘all’
            List information on all D language transitions.
!      ‘complex’
            List all usages of complex or imaginary types.
!      ‘field’
            List all non-mutable fields which occupy an object instance.
!      ‘in’
!           List all usages of ‘in’ on parameter.
!      ‘nogc’
            List all hidden GC allocations.
!      ‘templates’
            List statistics on template instantiations.
!      ‘tls’
            List all variables going into thread local storage.
  
  
*************** These options come into play when the co
*** 618,648 ****
  an executable output file.  They are meaningless if the compiler is not
  doing a link step.
  
! '-defaultlib=LIBNAME'
       Specify the library to use instead of libphobos when linking.
       Options specifying the linkage of libphobos, such as
!      '-static-libphobos' or '-shared-libphobos', are ignored.
  
! '-debuglib=LIBNAME'
       Specify the debug library to use instead of libphobos when linking.
!      This option has no effect unless the '-g' option was also given on
       the command line.  Options specifying the linkage of libphobos,
!      such as '-static-libphobos' or '-shared-libphobos', are ignored.
  
! '-nophoboslib'
       Do not use the Phobos or D runtime library when linking.  Options
!      specifying the linkage of libphobos, such as '-static-libphobos' or
!      '-shared-libphobos', are ignored.  The standard system libraries
!      are used normally, unless '-nostdlib' or '-nodefaultlibs' is used.
  
! '-shared-libphobos'
!      On systems that provide 'libgphobos' and 'libgdruntime' as a shared
       and a static library, this option forces the use of the shared
       version.  If no shared version was built when the compiler was
       configured, this option has no effect.
  
! '-static-libphobos'
!      On systems that provide 'libgphobos' and 'libgdruntime' as a shared
       and a static library, this option forces the use of the static
       version.  If no static version was built when the compiler was
       configured, this option has no effect.
--- 618,648 ----
  an executable output file.  They are meaningless if the compiler is not
  doing a link step.
  
! ‘-defaultlib=LIBNAME’
       Specify the library to use instead of libphobos when linking.
       Options specifying the linkage of libphobos, such as
!      ‘-static-libphobos’ or ‘-shared-libphobos’, are ignored.
  
! ‘-debuglib=LIBNAME’
       Specify the debug library to use instead of libphobos when linking.
!      This option has no effect unless the ‘-g’ option was also given on
       the command line.  Options specifying the linkage of libphobos,
!      such as ‘-static-libphobos’ or ‘-shared-libphobos’, are ignored.
  
! ‘-nophoboslib’
       Do not use the Phobos or D runtime library when linking.  Options
!      specifying the linkage of libphobos, such as ‘-static-libphobos’ or
!      ‘-shared-libphobos’, are ignored.  The standard system libraries
!      are used normally, unless ‘-nostdlib’ or ‘-nodefaultlibs’ is used.
  
! ‘-shared-libphobos’
!      On systems that provide ‘libgphobos’ and ‘libgdruntime’ as a shared
       and a static library, this option forces the use of the shared
       version.  If no shared version was built when the compiler was
       configured, this option has no effect.
  
! ‘-static-libphobos’
!      On systems that provide ‘libgphobos’ and ‘libgdruntime’ as a shared
       and a static library, this option forces the use of the static
       version.  If no static version was built when the compiler was
       configured, this option has no effect.
*************** File: gdc.info,  Node: Developer Options
*** 656,671 ****
  This section describes command-line options that are primarily of
  interest to developers or language tooling.
  
! '-fdump-d-original'
!      Output the internal front-end AST after the 'semantic3' stage.
       This option is only useful for debugging the GNU D compiler itself.
  
! '-v'
       Dump information about the compiler language processing stages as
       the source program is being compiled.  This includes listing all
!      modules that are processed through the 'parse', 'semantic',
!      'semantic2', and 'semantic3' stages; all 'import' modules and their
!      file paths; and all 'function' bodies that are being compiled.
  
  
  File: gdc.info,  Node: D Implementation,  Next: Copying,  Prev: Invoking gdc,  Up: Top
--- 656,671 ----
  This section describes command-line options that are primarily of
  interest to developers or language tooling.
  
! ‘-fdump-d-original’
!      Output the internal front-end AST after the ‘semantic3’ stage.
       This option is only useful for debugging the GNU D compiler itself.
  
! ‘-v’
       Dump information about the compiler language processing stages as
       the source program is being compiled.  This includes listing all
!      modules that are processed through the ‘parse’, ‘semantic’,
!      ‘semantic2’, and ‘semantic3’ stages; all ‘import’ modules and their
!      file paths; and all ‘function’ bodies that are being compiled.
  
  
  File: gdc.info,  Node: D Implementation,  Next: Copying,  Prev: Invoking gdc,  Up: Top
*************** D programming language defined in the do
*** 682,689 ****
     The implementation details described in this manual are GNU D
  extensions to the D programming language.  If you want to write code
  that checks whether these features are available, you can test for the
! predefined version 'GNU', or you can check whether a specific feature is
! compilable using '__traits(compiles)'.
  
       version (GNU)
       {
--- 682,689 ----
     The implementation details described in this manual are GNU D
  extensions to the D programming language.  If you want to write code
  that checks whether these features are available, you can test for the
! predefined version ‘GNU’, or you can check whether a specific feature is
! compilable using ‘__traits(compiles)’.
  
       version (GNU)
       {
*************** File: gdc.info,  Node: Attributes,  Next
*** 718,735 ****
  ==============
  
  User-Defined Attributes (UDA) are compile-time expressions introduced by
! the '@' token that can be attached to a declaration.  These attributes
  can then be queried, extracted, and manipulated at compile time.
  
     GNU D provides a number of extra special attributes to control
  specific compiler behavior that may help the compiler optimize or check
  code more carefully for correctness.  The attributes are defined in the
! 'gcc.attributes' module.
  
     There is some overlap between the purposes of attributes and pragmas.
! It has been found more convenient to use '@attribute' to achieve a
  natural attachment of attributes to their corresponding declarations,
! whereas 'pragma' is of use for compatibility with other compilers or
  constructs that do not naturally form part of the grammar.
  
  * Menu:
--- 718,735 ----
  ==============
  
  User-Defined Attributes (UDA) are compile-time expressions introduced by
! the ‘@’ token that can be attached to a declaration.  These attributes
  can then be queried, extracted, and manipulated at compile time.
  
     GNU D provides a number of extra special attributes to control
  specific compiler behavior that may help the compiler optimize or check
  code more carefully for correctness.  The attributes are defined in the
! ‘gcc.attributes’ module.
  
     There is some overlap between the purposes of attributes and pragmas.
! It has been found more convenient to use ‘@attribute’ to achieve a
  natural attachment of attributes to their corresponding declarations,
! whereas ‘pragma’ is of use for compatibility with other compilers or
  constructs that do not naturally form part of the grammar.
  
  * Menu:
*************** File: gdc.info,  Node: Attribute Syntax,
*** 745,758 ****
  2.1.1 Attribute Syntax
  ----------------------
  
! '@(gcc.attributes.attribute)' is the generic entrypoint for applying GCC
  attributes to a function, variable, or type.  There is no type checking
  done, as well as no deprecation path for attributes removed from the
  compiler.  So the recommendation is to use any of the other UDAs
  available as described in *note Common Attributes:: unless it is a
  target-specific attribute (*Note Target Attributes::).
  
!    Function attributes introduced by the '@attribute' UDA are used in
  the declaration of a function, followed by an attribute name string and
  any arguments separated by commas enclosed in parentheses.
  
--- 745,758 ----
  2.1.1 Attribute Syntax
  ----------------------
  
! ‘@(gcc.attributes.attribute)’ is the generic entrypoint for applying GCC
  attributes to a function, variable, or type.  There is no type checking
  done, as well as no deprecation path for attributes removed from the
  compiler.  So the recommendation is to use any of the other UDAs
  available as described in *note Common Attributes:: unless it is a
  target-specific attribute (*Note Target Attributes::).
  
!    Function attributes introduced by the ‘@attribute’ UDA are used in
  the declaration of a function, followed by an attribute name string and
  any arguments separated by commas enclosed in parentheses.
  
*************** any arguments separated by commas enclos
*** 760,766 ****
       @attribute("regparm", 1) int func(int size);
  
  Multiple attributes can be applied to a single declaration either with
! multiple '@attribute' attributes, or passing all attributes as a
  comma-separated list enclosed by parentheses.
  
       // Both func1 and func2 have the same attributes applied.
--- 760,766 ----
       @attribute("regparm", 1) int func(int size);
  
  Multiple attributes can be applied to a single declaration either with
! multiple ‘@attribute’ attributes, or passing all attributes as a
  comma-separated list enclosed by parentheses.
  
       // Both func1 and func2 have the same attributes applied.
*************** comma-separated list enclosed by parenth
*** 770,776 ****
  There are some problems with the semantics of such attributes in D. 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 D are restricted to declarations only.
  
--- 770,776 ----
  There are some problems with the semantics of such attributes in D. 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 D are restricted to declarations only.
  
*************** File: gdc.info,  Node: Common Attributes
*** 782,802 ****
  
  The following attributes are supported on most targets.
  
! '@(gcc.attributes.alloc_size (SIZEARGIDX))'
! '@(gcc.attributes.alloc_size (SIZEARGIDX, NUMARGIDX))'
! '@(gcc.attributes.alloc_size (SIZEARGIDX, NUMARGIDX, ZEROBASEDNUMBERING))'
  
!      The '@alloc_size' attribute may be applied to a function - or a
       function pointer variable - that returns a pointer and takes at
       least one argument of an integer or enumerated type.  It indicates
       that the returned pointer points to memory whose size is given by
!      the function argument at 'sizeArgIdx', or by the product of the
!      arguments at 'sizeArgIdx' and 'numArgIdx'.  Meaningful sizes are
!      positive values less than 'ptrdiff_t.max'.  Unless
!      'zeroBasedNumbering' is true, argument numbering starts at one for
       ordinary functions, and at two for non-static member functions.
  
!      If 'numArgIdx' is less than '0', it is taken to mean there is no
       argument specifying the element count.
  
            @alloc_size(1) void* malloc(size_t);
--- 782,802 ----
  
  The following attributes are supported on most targets.
  
! ‘@(gcc.attributes.alloc_size (SIZEARGIDX))’
! ‘@(gcc.attributes.alloc_size (SIZEARGIDX, NUMARGIDX))’
! ‘@(gcc.attributes.alloc_size (SIZEARGIDX, NUMARGIDX, ZEROBASEDNUMBERING))’
  
!      The ‘@alloc_size’ attribute may be applied to a function - or a
       function pointer variable - that returns a pointer and takes at
       least one argument of an integer or enumerated type.  It indicates
       that the returned pointer points to memory whose size is given by
!      the function argument at ‘sizeArgIdx’, or by the product of the
!      arguments at ‘sizeArgIdx’ and ‘numArgIdx’.  Meaningful sizes are
!      positive values less than ‘ptrdiff_t.max’.  Unless
!      ‘zeroBasedNumbering’ is true, argument numbering starts at one for
       ordinary functions, and at two for non-static member functions.
  
!      If ‘numArgIdx’ is less than ‘0’, it is taken to mean there is no
       argument specifying the element count.
  
            @alloc_size(1) void* malloc(size_t);
*************** The following attributes are supported o
*** 804,820 ****
            @alloc_size(1,2) void* my_calloc(size_t, size_t, bool);
            void malloc_cb(@alloc_size(1) void* function(size_t) ptr) { }
  
! '@(gcc.attributes.always_inline)'
  
!      The '@always_inline' attribute inlines the function independent of
       any restrictions that otherwise apply to inlining.  Failure to
       inline such a function is diagnosed as an error.
  
            @always_inline int func();
  
! '@(gcc.attributes.cold)'
  
!      The '@cold' attribute on functions is used to inform the compiler
       that the function is unlikely to be executed.  The function is
       optimized for size rather than speed and on many targets it is
       placed into a special subsection of the text section so all cold
--- 804,820 ----
            @alloc_size(1,2) void* my_calloc(size_t, size_t, bool);
            void malloc_cb(@alloc_size(1) void* function(size_t) ptr) { }
  
! ‘@(gcc.attributes.always_inline)’
  
!      The ‘@always_inline’ attribute inlines the function independent of
       any restrictions that otherwise apply to inlining.  Failure to
       inline such a function is diagnosed as an error.
  
            @always_inline int func();
  
! ‘@(gcc.attributes.cold)’
  
!      The ‘@cold’ attribute on functions is used to inform the compiler
       that the function is unlikely to be executed.  The function is
       optimized for size rather than speed and on many targets it is
       placed into a special subsection of the text section so all cold
*************** The following attributes are supported o
*** 824,882 ****
  
            @cold int func();
  
! '@(gcc.attributes.flatten)'
  
!      The '@flatten' attribute is used to inform the compiler that every
       call inside this function should be inlined, if possible.
!      Functions declared with attribute '@noinline' and similar are not
       inlined.
  
            @flatten int func();
  
! '@(gcc.attributes.no_icf)'
  
!      The '@no_icf' attribute prevents a function from being merged with
       another semantically equivalent function.
  
            @no_icf int func();
  
! '@(gcc.attributes.no_sanitize ("SANITIZE_OPTION"))'
  
!      The '@no_sanitize' attribute on functions is used to inform the
       compiler that it should not do sanitization of any option mentioned
       in SANITIZE_OPTION.  A list of values acceptable by the
!      '-fsanitize' option can be provided.
  
            @no_sanitize("alignment", "object-size") void func1() { }
            @no_sanitize("alignment,object-size") void func2() { }
  
! '@(gcc.attributes.noclone)'
  
!      The '@noclone' attribute prevents a function from being considered
       for cloning - a mechanism that produces specialized copies of
       functions and which is (currently) performed by interprocedural
       constant propagation.
  
            @noclone int func();
  
! '@(gcc.attributes.noinline)'
  
!      The '@noinline' attribute prevents a function from being considered
       for inlining.  If the function does not have side effects, there
       are optimizations other than inlining that cause function calls to
       be optimized away, although the function call is live.  To keep
!      such calls from being optimized away, put 'asm { ""; }' in the
       called function, to serve as a special side effect.
  
            @noinline int func();
  
! '@(gcc.attributes.noipa)'
  
!      The '@noipa' attribute disables interprocedural optimizations
       between the function with this attribute and its callers, as if the
       body of the function is not available when optimizing callers and
       the callers are unavailable when optimizing the body.  This
!      attribute implies '@noinline', '@noclone', and '@no_icf'
       attributes.  However, this attribute is not equivalent to a
       combination of other attributes, because its purpose is to suppress
       existing and future optimizations employing interprocedural
--- 824,882 ----
  
            @cold int func();
  
! ‘@(gcc.attributes.flatten)’
  
!      The ‘@flatten’ attribute is used to inform the compiler that every
       call inside this function should be inlined, if possible.
!      Functions declared with attribute ‘@noinline’ and similar are not
       inlined.
  
            @flatten int func();
  
! ‘@(gcc.attributes.no_icf)’
  
!      The ‘@no_icf’ attribute prevents a function from being merged with
       another semantically equivalent function.
  
            @no_icf int func();
  
! ‘@(gcc.attributes.no_sanitize ("SANITIZE_OPTION"))’
  
!      The ‘@no_sanitize’ attribute on functions is used to inform the
       compiler that it should not do sanitization of any option mentioned
       in SANITIZE_OPTION.  A list of values acceptable by the
!      ‘-fsanitize’ option can be provided.
  
            @no_sanitize("alignment", "object-size") void func1() { }
            @no_sanitize("alignment,object-size") void func2() { }
  
! ‘@(gcc.attributes.noclone)’
  
!      The ‘@noclone’ attribute prevents a function from being considered
       for cloning - a mechanism that produces specialized copies of
       functions and which is (currently) performed by interprocedural
       constant propagation.
  
            @noclone int func();
  
! ‘@(gcc.attributes.noinline)’
  
!      The ‘@noinline’ attribute prevents a function from being considered
       for inlining.  If the function does not have side effects, there
       are optimizations other than inlining that cause function calls to
       be optimized away, although the function call is live.  To keep
!      such calls from being optimized away, put ‘asm { ""; }’ in the
       called function, to serve as a special side effect.
  
            @noinline int func();
  
! ‘@(gcc.attributes.noipa)’
  
!      The ‘@noipa’ attribute disables interprocedural optimizations
       between the function with this attribute and its callers, as if the
       body of the function is not available when optimizing callers and
       the callers are unavailable when optimizing the body.  This
!      attribute implies ‘@noinline’, ‘@noclone’, and ‘@no_icf’
       attributes.  However, this attribute is not equivalent to a
       combination of other attributes, because its purpose is to suppress
       existing and future optimizations employing interprocedural
*************** The following attributes are supported o
*** 888,896 ****
  
            @noipa int func();
  
! '@(gcc.attributes.noplt)'
  
!      The '@noplt' attribute is the counterpart to option '-fno-plt'.
       Calls to functions marked with this attribute in
       position-independent code do not use the PLT in
       position-independent code.
--- 888,896 ----
  
            @noipa int func();
  
! ‘@(gcc.attributes.noplt)’
  
!      The ‘@noplt’ attribute is the counterpart to option ‘-fno-plt’.
       Calls to functions marked with this attribute in
       position-independent code do not use the PLT in
       position-independent code.
*************** The following attributes are supported o
*** 901,921 ****
  
            @noplt int func();
  
! '@(gcc.attributes.optimize (ARGUMENTS))'
  
!      The '@optimize' attribute is used to specify that a function is to
       be compiled with different optimization options than specified on
       the command line.  Valid ARGUMENTS are constant non-negative
       integers and strings.  Multiple arguments can be provided,
       separated by commas to specify multiple options.  Each numeric
       argument specifies an optimization level.  Each string argument
!      that begins with the letter 'O' refers to an optimization option
!      such as '-O0' or '-Os'.  Other options are taken as suffixes to the
!      '-f' prefix jointly forming the name of an optimization option.
  
!      Not every optimization option that starts with the '-f' prefix
       specified by the attribute necessarily has an effect on the
!      function.  The '@optimize' attribute should be used for debugging
       purposes only.  It is not suitable in production code.
  
            @optimize(2) double fn0(double x);
--- 901,921 ----
  
            @noplt int func();
  
! ‘@(gcc.attributes.optimize (ARGUMENTS))’
  
!      The ‘@optimize’ attribute is used to specify that a function is to
       be compiled with different optimization options than specified on
       the command line.  Valid ARGUMENTS are constant non-negative
       integers and strings.  Multiple arguments can be provided,
       separated by commas to specify multiple options.  Each numeric
       argument specifies an optimization level.  Each string argument
!      that begins with the letter ‘O’ refers to an optimization option
!      such as ‘-O0’ or ‘-Os’.  Other options are taken as suffixes to the
!      ‘-f’ prefix jointly forming the name of an optimization option.
  
!      Not every optimization option that starts with the ‘-f’ prefix
       specified by the attribute necessarily has an effect on the
!      function.  The ‘@optimize’ attribute should be used for debugging
       purposes only.  It is not suitable in production code.
  
            @optimize(2) double fn0(double x);
*************** The following attributes are supported o
*** 927,958 ****
            @optimize("-ftree-vectorize") double fn6(double x);
            @optimize("no-finite-math-only", 3) double fn7(double x);
  
! '@(gcc.attributes.register ("REGISTERNAME"))'
  
!      The '@register' attribute specifies that a local or '__gshared'
       variable is to be given a register storage-class in the C99 sense
       of the term, and will be placed into a register named REGISTERNAME.
  
       The variable needs to boiled down to a data type that fits the
       target register.  It also cannot have either thread-local or
!      'extern' storage.  It is an error to take the address of a register
       variable.
  
            @register("ebx") __gshared int ebx = void;
            void func() { @register("r10") long r10 = 0x2a; }
  
! '@(gcc.attributes.restrict)'
  
!      The '@restrict' attribute specifies that a function parameter is to
       be restrict-qualified in the C99 sense of the term.  The parameter
       needs to boil down to either a pointer or reference type, such as a
!      D pointer, class reference, or a 'ref' parameter.
  
            void func(@restrict ref const float[16] array);
  
! '@(gcc.attributes.section ("SECTIONNAME"))'
  
!      The '@section' attribute specifies that a function or variable
       lives in a particular section.  For when you need certain
       particular functions to appear in special sections.
  
--- 927,958 ----
            @optimize("-ftree-vectorize") double fn6(double x);
            @optimize("no-finite-math-only", 3) double fn7(double x);
  
! ‘@(gcc.attributes.register ("REGISTERNAME"))’
  
!      The ‘@register’ attribute specifies that a local or ‘__gshared’
       variable is to be given a register storage-class in the C99 sense
       of the term, and will be placed into a register named REGISTERNAME.
  
       The variable needs to boiled down to a data type that fits the
       target register.  It also cannot have either thread-local or
!      ‘extern’ storage.  It is an error to take the address of a register
       variable.
  
            @register("ebx") __gshared int ebx = void;
            void func() { @register("r10") long r10 = 0x2a; }
  
! ‘@(gcc.attributes.restrict)’
  
!      The ‘@restrict’ attribute specifies that a function parameter is to
       be restrict-qualified in the C99 sense of the term.  The parameter
       needs to boil down to either a pointer or reference type, such as a
!      D pointer, class reference, or a ‘ref’ parameter.
  
            void func(@restrict ref const float[16] array);
  
! ‘@(gcc.attributes.section ("SECTIONNAME"))’
  
!      The ‘@section’ attribute specifies that a function or variable
       lives in a particular section.  For when you need certain
       particular functions to appear in special sections.
  
*************** The following attributes are supported o
*** 964,972 ****
            @section("bar") extern void func();
            @section("stack") ubyte[10000] stack;
  
! '@(gcc.attributes.simd)'
  
!      The '@simd' attribute enables creation of one or more function
       versions that can process multiple arguments using SIMD
       instructions from a single invocation.  Specifying this attribute
       allows compiler to assume that such versions are available at link
--- 964,972 ----
            @section("bar") extern void func();
            @section("stack") ubyte[10000] stack;
  
! ‘@(gcc.attributes.simd)’
  
!      The ‘@simd’ attribute enables creation of one or more function
       versions that can process multiple arguments using SIMD
       instructions from a single invocation.  Specifying this attribute
       allows compiler to assume that such versions are available at link
*************** The following attributes are supported o
*** 976,1013 ****
  
            @simd double sqrt(double x);
  
! '@(gcc.attributes.simd_clones ("MASK"))'
  
!      The '@simd_clones' attribute is the same as '@simd', but also
!      includes a MASK argument.  Valid masks values are 'notinbranch' or
!      'inbranch', and instructs the compiler to generate non-masked or
       masked clones correspondingly.
  
            @simd_clones("notinbranch") double atan2(double y, double x);
  
! '@(gcc.attributes.symver ("ARGUMENTS"))'
  
!      The '@symver' attribute creates a symbol version on ELF targets.
!      The syntax of the string parameter is '"NAME@NODENAME"'.  The NAME
       part of the parameter is the actual name of the symbol by which it
       will be externally referenced.  The NODENAME portion should be the
       name of a node specified in the version script supplied to the
       linker when building a shared library.  Versioned symbol must be
       defined and must be exported with default visibility.
  
!      Finally if the parameter is '"NAME@@NODENAME"' then in addition to
!      creating a symbol version (as if '"NAME@NODENAME"' was used) the
       version will be also used to resolve NAME by the linker.
  
            @symver("foo@VERS_1") int foo_v1();
  
! '@(gcc.attributes.target ("OPTIONS"))'
  
!      The '@target' attribute is used to specify that a function is to be
       compiled with different target options than specified on the
       command line.  One or more strings can be provided as arguments,
       separated by commas to specify multiple options.  Each string
!      consists of one or more comma-separated suffixes to the '-m' prefix
       jointly forming the name of a machine-dependent option.
  
       The target attribute can be used for instance to have a function
--- 976,1013 ----
  
            @simd double sqrt(double x);
  
! ‘@(gcc.attributes.simd_clones ("MASK"))’
  
!      The ‘@simd_clones’ attribute is the same as ‘@simd’, but also
!      includes a MASK argument.  Valid masks values are ‘notinbranch’ or
!      ‘inbranch’, and instructs the compiler to generate non-masked or
       masked clones correspondingly.
  
            @simd_clones("notinbranch") double atan2(double y, double x);
  
! ‘@(gcc.attributes.symver ("ARGUMENTS"))’
  
!      The ‘@symver’ attribute creates a symbol version on ELF targets.
!      The syntax of the string parameter is ‘"NAME@NODENAME"’.  The NAME
       part of the parameter is the actual name of the symbol by which it
       will be externally referenced.  The NODENAME portion should be the
       name of a node specified in the version script supplied to the
       linker when building a shared library.  Versioned symbol must be
       defined and must be exported with default visibility.
  
!      Finally if the parameter is ‘"NAME@@NODENAME"’ then in addition to
!      creating a symbol version (as if ‘"NAME@NODENAME"’ was used) the
       version will be also used to resolve NAME by the linker.
  
            @symver("foo@VERS_1") int foo_v1();
  
! ‘@(gcc.attributes.target ("OPTIONS"))’
  
!      The ‘@target’ attribute is used to specify that a function is to be
       compiled with different target options than specified on the
       command line.  One or more strings can be provided as arguments,
       separated by commas to specify multiple options.  Each string
!      consists of one or more comma-separated suffixes to the ‘-m’ prefix
       jointly forming the name of a machine-dependent option.
  
       The target attribute can be used for instance to have a function
*************** The following attributes are supported o
*** 1019,1061 ****
            @target("arch=core2") void core2_func();
            @target("sse3") void sse3_func();
  
! '@(gcc.attributes.target_clones ("OPTIONS"))'
  
!      The '@target_clones' attribute is used to specify that a function
       be cloned into multiple versions compiled with different target
       OPTIONS than specified on the command line.  The supported options
!      and restrictions are the same as for '@target' attribute.
  
       It also creates a resolver function that dynamically selects a
       clone suitable for current architecture.  The resolver is created
!      only if there is a usage of a function with '@target_clones'
       attribute.
  
            @target_clones("sse4.1,avx,default") double func(double x);
  
! '@(gcc.attributes.used)'
  
!      The '@used' attribute, annotated to a function or variable, 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.
  
            @used __gshared int var = 0x1000;
  
! '@(gcc.attributes.visibility ("VISIBILITYNAME"))'
  
!      The '@visibility' attribute affects the linkage of the declaration
       to which it is attached.  It can be applied to variables, types,
       and functions.
  
!      There are four supported visibility_type values: 'default',
!      'hidden', 'protected', or 'internal' visibility.
  
            @visibility("protected") void func() {  }
  
! '@(gcc.attributes.weak)'
  
!      The '@weak' attribute causes a declaration of an external symbol to
       be emitted as a weak symbol rather than a global.  This is
       primarily useful in defining library functions that can be
       overridden in user code, though it can also be used with
--- 1019,1061 ----
            @target("arch=core2") void core2_func();
            @target("sse3") void sse3_func();
  
! ‘@(gcc.attributes.target_clones ("OPTIONS"))’
  
!      The ‘@target_clones’ attribute is used to specify that a function
       be cloned into multiple versions compiled with different target
       OPTIONS than specified on the command line.  The supported options
!      and restrictions are the same as for ‘@target’ attribute.
  
       It also creates a resolver function that dynamically selects a
       clone suitable for current architecture.  The resolver is created
!      only if there is a usage of a function with ‘@target_clones’
       attribute.
  
            @target_clones("sse4.1,avx,default") double func(double x);
  
! ‘@(gcc.attributes.used)’
  
!      The ‘@used’ attribute, annotated to a function or variable, 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.
  
            @used __gshared int var = 0x1000;
  
! ‘@(gcc.attributes.visibility ("VISIBILITYNAME"))’
  
!      The ‘@visibility’ attribute affects the linkage of the declaration
       to which it is attached.  It can be applied to variables, types,
       and functions.
  
!      There are four supported visibility_type values: ‘default’,
!      ‘hidden’, ‘protected’, or ‘internal’ visibility.
  
            @visibility("protected") void func() {  }
  
! ‘@(gcc.attributes.weak)’
  
!      The ‘@weak’ attribute causes a declaration of an external symbol to
       be emitted as a weak symbol rather than a global.  This is
       primarily useful in defining library functions that can be
       overridden in user code, though it can also be used with
*************** File: gdc.info,  Node: Other Attributes,
*** 1078,1136 ****
  The following attributes are defined for compatibility with other
  compilers.
  
! '@(gcc.attributes.allocSize (SIZEARGIDX))'
! '@(gcc.attributes.allocSize (SIZEARGIDX, NUMARGIDX))'
! '@(gcc.attributes.allocSize (SIZEARGIDX))'
  
!      These attributes are a synonym for '@alloc_size(SIZEARGIDX,
!      NUMARGIDX, true)'.  Unlike '@alloc_size', it uses 0-based index of
       the function arguments.
  
! '@(gcc.attributes.assumeUsed)'
  
!      This attribute is a synonym for '@used'.
  
! '@(gcc.attributes.dynamicCompile)'
! '@(gcc.attributes.dynamicCompileConst)'
! '@(gcc.attributes.dynamicCompileEmit)'
  
       These attributes are accepted, but have no effect.
  
! '@(gcc.attributes.fastmath)'
  
!      This attribute is a synonym for '@optimize("Ofast")'.  Explicitly
       sets "fast-math" for a function, enabling aggressive math
       optimizations.
  
! '@(gcc.attributes.hidden)'
  
!      This attribute is a synonym for '@visibility("hidden")'.  Sets the
       visibility of a function or global variable to "hidden".
  
! '@(gcc.attributes.naked)'
  
!      This attribute is a synonym for '@attribute("naked")'.  Adds GCC's
       "naked" attribute to a function, disabling function prologue /
       epilogue emission.  Intended to be used in combination with basic
!      'asm' statements.  While using extended 'asm' or a mixture of basic
!      'asm' and D code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! '@(gcc.attributes.noSanitize ("SANITIZE_OPTION"))'
  
!      This attribute is a synonym for '@no_sanitize("sanitize_option")'.
  
! '@(gcc.attributes.optStrategy ("STRATEGY"))'
  
!      This attribute is a synonym for '@optimize("O0")' and
!      '@optimize("Os")'.  Sets the optimization strategy for a function.
       Valid strategies are "none", "optsize", "minsize".  The strategies
       are mutually exclusive.
  
! '@(gcc.attributes.polly)'
  
!      This attribute is a synonym for '@optimize("loop-parallelize-all",
!      "loop-nest-optimize")'.  Only effective when GDC was built with ISL
       included.
  
  
--- 1078,1136 ----
  The following attributes are defined for compatibility with other
  compilers.
  
! ‘@(gcc.attributes.allocSize (SIZEARGIDX))’
! ‘@(gcc.attributes.allocSize (SIZEARGIDX, NUMARGIDX))’
! ‘@(gcc.attributes.allocSize (SIZEARGIDX))’
  
!      These attributes are a synonym for ‘@alloc_size(SIZEARGIDX,
!      NUMARGIDX, true)’.  Unlike ‘@alloc_size’, it uses 0-based index of
       the function arguments.
  
! ‘@(gcc.attributes.assumeUsed)’
  
!      This attribute is a synonym for ‘@used’.
  
! ‘@(gcc.attributes.dynamicCompile)’
! ‘@(gcc.attributes.dynamicCompileConst)’
! ‘@(gcc.attributes.dynamicCompileEmit)’
  
       These attributes are accepted, but have no effect.
  
! ‘@(gcc.attributes.fastmath)’
  
!      This attribute is a synonym for ‘@optimize("Ofast")’.  Explicitly
       sets "fast-math" for a function, enabling aggressive math
       optimizations.
  
! ‘@(gcc.attributes.hidden)’
  
!      This attribute is a synonym for ‘@visibility("hidden")’.  Sets the
       visibility of a function or global variable to "hidden".
  
! ‘@(gcc.attributes.naked)’
  
!      This attribute is a synonym for ‘@attribute("naked")’.  Adds GCC's
       "naked" attribute to a function, disabling function prologue /
       epilogue emission.  Intended to be used in combination with basic
!      ‘asm’ statements.  While using extended ‘asm’ or a mixture of basic
!      ‘asm’ and D code may appear to work, they cannot be depended upon
       to work reliably and are not supported.
  
! ‘@(gcc.attributes.noSanitize ("SANITIZE_OPTION"))’
  
!      This attribute is a synonym for ‘@no_sanitize("sanitize_option")’.
  
! ‘@(gcc.attributes.optStrategy ("STRATEGY"))’
  
!      This attribute is a synonym for ‘@optimize("O0")’ and
!      ‘@optimize("Os")’.  Sets the optimization strategy for a function.
       Valid strategies are "none", "optsize", "minsize".  The strategies
       are mutually exclusive.
  
! ‘@(gcc.attributes.polly)’
  
!      This attribute is a synonym for ‘@optimize("loop-parallelize-all",
!      "loop-nest-optimize")’.  Only effective when GDC was built with ISL
       included.
  
  
*************** File: gdc.info,  Node: Target Attributes
*** 1140,1147 ****
  --------------------------------
  
  Many targets have their own target-specific attributes.  These are also
! exposed via the 'gcc.attributes' module with use of the generic
! '@(gcc.attributes.attribute)' UDA function.
  
     *Note Attribute Syntax::, for details of the exact syntax for using
  attributes.
--- 1140,1147 ----
  --------------------------------
  
  Many targets have their own target-specific attributes.  These are also
! exposed via the ‘gcc.attributes’ module with use of the generic
! ‘@(gcc.attributes.attribute)’ UDA function.
  
     *Note Attribute Syntax::, for details of the exact syntax for using
  attributes.
*************** File: gdc.info,  Node: Builtin Functions
*** 1185,1193 ****
  ======================
  
  GCC provides a large number of built-in functions that are made
! available in GNU D by importing the 'gcc.builtins' module.  Declarations
  in this module are automatically created by the compiler.  All
! declarations start with '__builtin_'.  Refer to the built-in function
  documentation in the GCC manual for a full list of functions that are
  available.
  
--- 1185,1193 ----
  ======================
  
  GCC provides a large number of built-in functions that are made
! available in GNU D by importing the ‘gcc.builtins’ module.  Declarations
  in this module are automatically created by the compiler.  All
! declarations start with ‘__builtin_’.  Refer to the built-in function
  documentation in the GCC manual for a full list of functions that are
  available.
  
*************** File: gdc.info,  Node: Builtin Types,  N
*** 1204,1249 ****
  --------------------
  
  In addition to built-in functions, the following types are defined in
! the 'gcc.builtins' module.
  
! '___builtin_clong'
!      The D equivalent of the target's C 'long' type.
  
! '___builtin_clonglong'
!      The D equivalent of the target's C 'long long' type.
  
! '___builtin_culong'
!      The D equivalent of the target's C 'unsigned long' type.
  
! '___builtin_culonglong'
!      The D equivalent of the target's C 'unsigned long long' type.
  
! '___builtin_machine_byte'
       Signed unit-sized integer type.
  
! '___builtin_machine_int'
       Signed word-sized integer type.
  
! '___builtin_machine_ubyte'
       Unsigned unit-sized integer type.
  
! '___builtin_machine_uint'
       Unsigned word-sized integer type.
  
! '___builtin_pointer_int'
       Signed pointer-sized integer type.
  
! '___builtin_pointer_uint'
       Unsigned pointer-sized integer type.
  
! '___builtin_unwind_int'
!      The D equivalent of the target's C '_Unwind_Sword' type.
  
! '___builtin_unwind_uint'
!      The D equivalent of the target's C '_Unwind_Word' type.
  
! '___builtin_va_list'
!      The target's 'va_list' type.
  
  
  File: gdc.info,  Node: Query Builtins,  Next: Other Builtins,  Prev: Builtin Types,  Up: Builtin Functions
--- 1204,1249 ----
  --------------------
  
  In addition to built-in functions, the following types are defined in
! the ‘gcc.builtins’ module.
  
! ‘___builtin_clong’
!      The D equivalent of the target's C ‘long’ type.
  
! ‘___builtin_clonglong’
!      The D equivalent of the target's C ‘long long’ type.
  
! ‘___builtin_culong’
!      The D equivalent of the target's C ‘unsigned long’ type.
  
! ‘___builtin_culonglong’
!      The D equivalent of the target's C ‘unsigned long long’ type.
  
! ‘___builtin_machine_byte’
       Signed unit-sized integer type.
  
! ‘___builtin_machine_int’
       Signed word-sized integer type.
  
! ‘___builtin_machine_ubyte’
       Unsigned unit-sized integer type.
  
! ‘___builtin_machine_uint’
       Unsigned word-sized integer type.
  
! ‘___builtin_pointer_int’
       Signed pointer-sized integer type.
  
! ‘___builtin_pointer_uint’
       Unsigned pointer-sized integer type.
  
! ‘___builtin_unwind_int’
!      The D equivalent of the target's C ‘_Unwind_Sword’ type.
  
! ‘___builtin_unwind_uint’
!      The D equivalent of the target's C ‘_Unwind_Word’ type.
  
! ‘___builtin_va_list’
!      The target's ‘va_list’ type.
  
  
  File: gdc.info,  Node: Query Builtins,  Next: Other Builtins,  Prev: Builtin Types,  Up: Builtin Functions
*************** File: gdc.info,  Node: Query Builtins,
*** 1254,1263 ****
  Not all of the functions are supported, and some target-specific
  functions may only be available when compiling for a particular ISA. One
  way of finding out what is exposed by the built-ins module is by
! generating a D interface file.  Assuming you have no file 'builtins.d',
  the command
         echo "module gcc.builtins;" > builtins.d; gdc -H -fsyntax-only builtins.d
! will save all built-in declarations to the file 'builtins.di'.
  
     Another way to determine whether a specific built-in is available is
  by using compile-time reflection.
--- 1254,1263 ----
  Not all of the functions are supported, and some target-specific
  functions may only be available when compiling for a particular ISA. One
  way of finding out what is exposed by the built-ins module is by
! generating a D interface file.  Assuming you have no file ‘builtins.d’,
  the command
         echo "module gcc.builtins;" > builtins.d; gdc -H -fsyntax-only builtins.d
! will save all built-in declarations to the file ‘builtins.di’.
  
     Another way to determine whether a specific built-in is available is
  by using compile-time reflection.
*************** File: gdc.info,  Node: Other Builtins,
*** 1275,1380 ****
  2.2.3 Other Built-in Functions
  ------------------------------
  
! As well as built-ins being available from the 'gcc.builtins' module, GNU
! D will also recognize when an 'extern(C)' library function is a GCC
  built-in.  Many of these functions are only optimized in certain cases;
  if they are not optimized in a particular case, a call to the library
  function is emitted.  This optimization can be disabled with the
! '-fno-builtin' option (*note Runtime Options::).
  
!    In the 'core.stdc.complex' module, the functions 'cabs', 'cabsf',
! 'cabsl', 'cacos', 'cacosf', 'cacosh', 'cacoshf', 'cacoshl', 'cacosl',
! 'carg', 'cargf', 'cargl', 'casin', 'casinf', 'casinh', 'casinhf',
! 'casinhl', 'casinl', 'catan', 'catanf', 'catanh', 'catanhf', 'catanhl',
! 'catanl', 'ccos', 'ccosf', 'ccosh', 'ccoshf', 'ccoshl', 'ccosl', 'cexp',
! 'cexpf', 'cexpl', 'clog', 'clogf', 'clogl', 'conj', 'conjf', 'conjl',
! 'cpow', 'cpowf', 'cpowl', 'cproj', 'cprojf', 'cprojl', 'csin', 'csinf',
! 'csinh', 'csinhf', 'csinhl', 'csinl', 'csqrt', 'csqrtf', 'csqrtl',
! 'ctan', 'ctanf', 'ctanh', 'ctanhf', 'ctanhl', 'ctanl' may be handled as
  built-in functions.  All these functions have corresponding versions
! prefixed with '__builtin_' in the 'gcc.builtins' module.
  
!    In the 'core.stdc.ctype' module, the functions 'isalnum', 'isalpha',
! 'isblank', 'iscntrl', 'isdigit', 'isgraph', 'islower', 'isprint',
! 'ispunct', 'isspace', 'isupper', 'isxdigit', 'tolower', 'toupper' may be
  handled as built-in functions.  All these functions have corresponding
! versions prefixed with '__builtin_' in the 'gcc.builtins' module.
  
!    In the 'core.stdc.fenv' module, the functions 'feclearexcept',
! 'fegetenv', 'fegetexceptflag', 'fegetround', 'feholdexcept',
! 'feraiseexcept', 'fesetenv', 'fesetexceptflag', 'fesetround',
! 'fetestexcept', 'feupdateenv' may be handled as built-in functions.  All
! these functions have corresponding versions prefixed with '__builtin_'
! in the 'gcc.builtins' module.
  
!    In the 'core.stdc.inttypes' module, the function 'imaxabs' may be
  handled as a built-in function.  All these functions have corresponding
! versions prefixed with '__builtin_' in the 'gcc.builtins' module.
  
!    In the 'core.stdc.math' module, the functions 'acos', 'acosf',
! 'acosh', 'acoshf', 'acoshl', 'acosl', 'asin', 'asinf', 'asinh',
! 'asinhf', 'asinhl', 'asinl', 'atan', 'atan2', 'atan2f', 'atan2l',
! 'atanf', 'atanh', 'atanhf', 'atanhl', 'atanl', 'cbrt', 'cbrtf', 'cbrtl',
! 'ceil', 'ceilf', 'ceill', 'copysign', 'copysignf', 'copysignl', 'cos',
! 'cosf', 'cosh', 'coshf', 'coshl', 'cosl', 'erf', 'erfc', 'erfcf',
! 'erfcl', 'erff', 'erfl', 'exp', 'exp2', 'exp2f', 'exp2l', 'expf',
! 'expl', 'expm1', 'expm1f', 'expm1l', 'fabs', 'fabsf', 'fabsl', 'fdim',
! 'fdimf', 'fdiml', 'floor', 'floorf', 'floorl', 'fma', 'fmaf', 'fmal',
! 'fmax', 'fmaxf', 'fmaxl', 'fmin', 'fminf', 'fminl', 'fmod', 'fmodf',
! 'fmodl', 'frexp', 'frexpf', 'frexpl', 'hypot', 'hypotf', 'hypotl',
! 'ilogb', 'ilogbf', 'ilogbl', 'isinf', 'isnan', 'ldexp', 'ldexpf',
! 'ldexpl', 'lgamma', 'lgammaf', 'lgammal', 'llrint', 'llrintf',
! 'llrintl', 'llround', 'llroundf', 'llroundl', 'log', 'log10', 'log10f',
! 'log10l', 'log1p', 'log1pf', 'log1pl', 'log2', 'log2f', 'log2l', 'logb',
! 'logbf', 'logbl', 'logf', 'logl', 'lrint', 'lrintf', 'lrintl', 'lround',
! 'lroundf', 'lroundl', 'modf', 'modff', 'modfl', 'nan', 'nanf', 'nanl',
! 'nearbyint', 'nearbyintf', 'nearbyintl', 'nextafter', 'nextafterf',
! 'nextafterl', 'nexttoward', 'nexttowardf', 'nexttowardl', 'pow', 'powf',
! 'powl', 'remainder', 'remainderf', 'remainderl', 'remquo', 'remquof',
! 'remquol', 'rint', 'rintf', 'rintl', 'round', 'roundf', 'roundl',
! 'scalbln', 'scalblnf', 'scalblnl', 'scalbn', 'scalbnf', 'scalbnl',
! 'signbit', 'sin', 'sinf', 'sinh', 'sinhf', 'sinhl', 'sinl', 'sqrt',
! 'sqrtf', 'sqrtl', 'tan', 'tanf', 'tanh', 'tanhf', 'tanhl', 'tanl',
! 'tgamma', 'tgammaf', 'tgammal', 'trunc', 'truncf', 'truncl' may be
  handled as built-in functions.  All these functions have corresponding
! versions prefixed with '__builtin_' in the 'gcc.builtins' module.
  
!    In the 'core.stdc.stdio' module, the functions 'fprintf', 'fputc',
! 'fputc_unlocked', 'fputs', 'fwrite', 'printf', 'puts', 'snprintf',
! 'sprintf', 'vfprintf', 'vprintf', 'vsnprintf', 'vsprintf' may be handled
  as built-in functions.  All these functions have corresponding versions
! prefixed with '__builtin_' in the 'gcc.builtins' module.
  
!    In the 'core.stdc.stdlib' module, the functions 'abort', 'abs',
! 'aligned_alloc', 'alloca', 'calloc', 'exit', '_Exit', 'free', 'labs',
! 'llabs', 'malloc', 'realloc' may be handled as built-in functions.  All
! these functions have corresponding versions prefixed with '__builtin_'
! in the 'gcc.builtins' module.
  
!    In the 'core.stdc.string' module, the functions 'memchr', 'memcmp',
! 'memcpy', 'memmove', 'memset', 'strcat', 'strchr', 'strcmp', 'strcpy',
! 'strcspn', 'strdup', 'strlen', 'strncat', 'strncmp', 'strncpy',
! 'strpbrk', 'strrchr', 'strspn', 'strstr' may be handled as built-in
  functions.  All these functions have corresponding versions prefixed
! with '__builtin_' in the 'gcc.builtins' module.
  
!    In the 'core.stdc.time' module, the function 'strftime' may be
  handled as a built-in function.  All these functions have corresponding
! versions prefixed with '__builtin_' in the 'gcc.builtins' module.
  
!    In the 'core.stdc.wctype' module, the functions 'iswalnum',
! 'iswalpha', 'iswblank', 'iswcntrl', 'iswdigit', 'iswgraph', 'iswlower',
! 'iswprint', 'iswpunct', 'iswspace', 'iswupper', 'iswxdigit', 'towlower',
! 'towupper' may be handled as built-in functions.  All these functions
! have corresponding versions prefixed with '__builtin_' in the
! 'gcc.builtins' module.
  
!    Within the 'core.sys' package for POSIX and platform definitions, the
! functions 'putchar_unlocked', 'putc_unlocked', 'posix_memalign', 'ffs',
! 'strcasecmp', 'strncasecmp', 'stpcpy', 'stpncpy', 'strndup', 'strnlen',
! 'execl', 'execle', 'execlp', 'execv', 'execve', 'execvp', '_exit',
! 'fork' may be handled as built-in functions.  All these functions have
! corresponding versions prefixed with '__builtin_' in the 'gcc.builtins'
  module.
  
  
--- 1275,1380 ----
  2.2.3 Other Built-in Functions
  ------------------------------
  
! As well as built-ins being available from the ‘gcc.builtins’ module, GNU
! D will also recognize when an ‘extern(C)’ library function is a GCC
  built-in.  Many of these functions are only optimized in certain cases;
  if they are not optimized in a particular case, a call to the library
  function is emitted.  This optimization can be disabled with the
! ‘-fno-builtin’ option (*note Runtime Options::).
  
!    In the ‘core.stdc.complex’ module, the functions ‘cabs’, ‘cabsf’,
! ‘cabsl’, ‘cacos’, ‘cacosf’, ‘cacosh’, ‘cacoshf’, ‘cacoshl’, ‘cacosl’,
! ‘carg’, ‘cargf’, ‘cargl’, ‘casin’, ‘casinf’, ‘casinh’, ‘casinhf’,
! ‘casinhl’, ‘casinl’, ‘catan’, ‘catanf’, ‘catanh’, ‘catanhf’, ‘catanhl’,
! ‘catanl’, ‘ccos’, ‘ccosf’, ‘ccosh’, ‘ccoshf’, ‘ccoshl’, ‘ccosl’, ‘cexp’,
! ‘cexpf’, ‘cexpl’, ‘clog’, ‘clogf’, ‘clogl’, ‘conj’, ‘conjf’, ‘conjl’,
! ‘cpow’, ‘cpowf’, ‘cpowl’, ‘cproj’, ‘cprojf’, ‘cprojl’, ‘csin’, ‘csinf’,
! ‘csinh’, ‘csinhf’, ‘csinhl’, ‘csinl’, ‘csqrt’, ‘csqrtf’, ‘csqrtl’,
! ‘ctan’, ‘ctanf’, ‘ctanh’, ‘ctanhf’, ‘ctanhl’, ‘ctanl’ may be handled as
  built-in functions.  All these functions have corresponding versions
! prefixed with ‘__builtin_’ in the ‘gcc.builtins’ module.
  
!    In the ‘core.stdc.ctype’ module, the functions ‘isalnum’, ‘isalpha’,
! ‘isblank’, ‘iscntrl’, ‘isdigit’, ‘isgraph’, ‘islower’, ‘isprint’,
! ‘ispunct’, ‘isspace’, ‘isupper’, ‘isxdigit’, ‘tolower’, ‘toupper’ may be
  handled as built-in functions.  All these functions have corresponding
! versions prefixed with ‘__builtin_’ in the ‘gcc.builtins’ module.
  
!    In the ‘core.stdc.fenv’ module, the functions ‘feclearexcept’,
! ‘fegetenv’, ‘fegetexceptflag’, ‘fegetround’, ‘feholdexcept’,
! ‘feraiseexcept’, ‘fesetenv’, ‘fesetexceptflag’, ‘fesetround’,
! ‘fetestexcept’, ‘feupdateenv’ may be handled as built-in functions.  All
! these functions have corresponding versions prefixed with ‘__builtin_’
! in the ‘gcc.builtins’ module.
  
!    In the ‘core.stdc.inttypes’ module, the function ‘imaxabs’ may be
  handled as a built-in function.  All these functions have corresponding
! versions prefixed with ‘__builtin_’ in the ‘gcc.builtins’ module.
  
!    In the ‘core.stdc.math’ module, the functions ‘acos’, ‘acosf’,
! ‘acosh’, ‘acoshf’, ‘acoshl’, ‘acosl’, ‘asin’, ‘asinf’, ‘asinh’,
! ‘asinhf’, ‘asinhl’, ‘asinl’, ‘atan’, ‘atan2’, ‘atan2f’, ‘atan2l’,
! ‘atanf’, ‘atanh’, ‘atanhf’, ‘atanhl’, ‘atanl’, ‘cbrt’, ‘cbrtf’, ‘cbrtl’,
! ‘ceil’, ‘ceilf’, ‘ceill’, ‘copysign’, ‘copysignf’, ‘copysignl’, ‘cos’,
! ‘cosf’, ‘cosh’, ‘coshf’, ‘coshl’, ‘cosl’, ‘erf’, ‘erfc’, ‘erfcf’,
! ‘erfcl’, ‘erff’, ‘erfl’, ‘exp’, ‘exp2’, ‘exp2f’, ‘exp2l’, ‘expf’,
! ‘expl’, ‘expm1’, ‘expm1f’, ‘expm1l’, ‘fabs’, ‘fabsf’, ‘fabsl’, ‘fdim’,
! ‘fdimf’, ‘fdiml’, ‘floor’, ‘floorf’, ‘floorl’, ‘fma’, ‘fmaf’, ‘fmal’,
! ‘fmax’, ‘fmaxf’, ‘fmaxl’, ‘fmin’, ‘fminf’, ‘fminl’, ‘fmod’, ‘fmodf’,
! ‘fmodl’, ‘frexp’, ‘frexpf’, ‘frexpl’, ‘hypot’, ‘hypotf’, ‘hypotl’,
! ‘ilogb’, ‘ilogbf’, ‘ilogbl’, ‘isinf’, ‘isnan’, ‘ldexp’, ‘ldexpf’,
! ‘ldexpl’, ‘lgamma’, ‘lgammaf’, ‘lgammal’, ‘llrint’, ‘llrintf’,
! ‘llrintl’, ‘llround’, ‘llroundf’, ‘llroundl’, ‘log’, ‘log10’, ‘log10f’,
! ‘log10l’, ‘log1p’, ‘log1pf’, ‘log1pl’, ‘log2’, ‘log2f’, ‘log2l’, ‘logb’,
! ‘logbf’, ‘logbl’, ‘logf’, ‘logl’, ‘lrint’, ‘lrintf’, ‘lrintl’, ‘lround’,
! ‘lroundf’, ‘lroundl’, ‘modf’, ‘modff’, ‘modfl’, ‘nan’, ‘nanf’, ‘nanl’,
! ‘nearbyint’, ‘nearbyintf’, ‘nearbyintl’, ‘nextafter’, ‘nextafterf’,
! ‘nextafterl’, ‘nexttoward’, ‘nexttowardf’, ‘nexttowardl’, ‘pow’, ‘powf’,
! ‘powl’, ‘remainder’, ‘remainderf’, ‘remainderl’, ‘remquo’, ‘remquof’,
! ‘remquol’, ‘rint’, ‘rintf’, ‘rintl’, ‘round’, ‘roundf’, ‘roundl’,
! ‘scalbln’, ‘scalblnf’, ‘scalblnl’, ‘scalbn’, ‘scalbnf’, ‘scalbnl’,
! ‘signbit’, ‘sin’, ‘sinf’, ‘sinh’, ‘sinhf’, ‘sinhl’, ‘sinl’, ‘sqrt’,
! ‘sqrtf’, ‘sqrtl’, ‘tan’, ‘tanf’, ‘tanh’, ‘tanhf’, ‘tanhl’, ‘tanl’,
! ‘tgamma’, ‘tgammaf’, ‘tgammal’, ‘trunc’, ‘truncf’, ‘truncl’ may be
  handled as built-in functions.  All these functions have corresponding
! versions prefixed with ‘__builtin_’ in the ‘gcc.builtins’ module.
  
!    In the ‘core.stdc.stdio’ module, the functions ‘fprintf’, ‘fputc’,
! ‘fputc_unlocked’, ‘fputs’, ‘fwrite’, ‘printf’, ‘puts’, ‘snprintf’,
! ‘sprintf’, ‘vfprintf’, ‘vprintf’, ‘vsnprintf’, ‘vsprintf’ may be handled
  as built-in functions.  All these functions have corresponding versions
! prefixed with ‘__builtin_’ in the ‘gcc.builtins’ module.
  
!    In the ‘core.stdc.stdlib’ module, the functions ‘abort’, ‘abs’,
! ‘aligned_alloc’, ‘alloca’, ‘calloc’, ‘exit’, ‘_Exit’, ‘free’, ‘labs’,
! ‘llabs’, ‘malloc’, ‘realloc’ may be handled as built-in functions.  All
! these functions have corresponding versions prefixed with ‘__builtin_’
! in the ‘gcc.builtins’ module.
  
!    In the ‘core.stdc.string’ module, the functions ‘memchr’, ‘memcmp’,
! ‘memcpy’, ‘memmove’, ‘memset’, ‘strcat’, ‘strchr’, ‘strcmp’, ‘strcpy’,
! ‘strcspn’, ‘strdup’, ‘strlen’, ‘strncat’, ‘strncmp’, ‘strncpy’,
! ‘strpbrk’, ‘strrchr’, ‘strspn’, ‘strstr’ may be handled as built-in
  functions.  All these functions have corresponding versions prefixed
! with ‘__builtin_’ in the ‘gcc.builtins’ module.
  
!    In the ‘core.stdc.time’ module, the function ‘strftime’ may be
  handled as a built-in function.  All these functions have corresponding
! versions prefixed with ‘__builtin_’ in the ‘gcc.builtins’ module.
  
!    In the ‘core.stdc.wctype’ module, the functions ‘iswalnum’,
! ‘iswalpha’, ‘iswblank’, ‘iswcntrl’, ‘iswdigit’, ‘iswgraph’, ‘iswlower’,
! ‘iswprint’, ‘iswpunct’, ‘iswspace’, ‘iswupper’, ‘iswxdigit’, ‘towlower’,
! ‘towupper’ may be handled as built-in functions.  All these functions
! have corresponding versions prefixed with ‘__builtin_’ in the
! ‘gcc.builtins’ module.
  
!    Within the ‘core.sys’ package for POSIX and platform definitions, the
! functions ‘putchar_unlocked’, ‘putc_unlocked’, ‘posix_memalign’, ‘ffs’,
! ‘strcasecmp’, ‘strncasecmp’, ‘stpcpy’, ‘stpncpy’, ‘strndup’, ‘strnlen’,
! ‘execl’, ‘execle’, ‘execlp’, ‘execv’, ‘execve’, ‘execvp’, ‘_exit’,
! ‘fork’ may be handled as built-in functions.  All these functions have
! corresponding versions prefixed with ‘__builtin_’ in the ‘gcc.builtins’
  module.
  
  
*************** in the C file.
*** 1392,1398 ****
  referred to as C11.  Prior versions, such as C99, C89, and K+R C, are
  not supported.
  
!    Assuming you have no file 'cstdio.c' or 'main.d', the commands
         cat > cstdio.c << @EOC
         int printf(const char*, ...);
         @EOC
--- 1392,1398 ----
  referred to as C11.  Prior versions, such as C99, C89, and K+R C, are
  not supported.
  
!    Assuming you have no file ‘cstdio.c’ or ‘main.d’, the commands
         cat > cstdio.c << @EOC
         int printf(const char*, ...);
         @EOC
*************** not supported.
*** 1401,1415 ****
         void main() { printf("Hello ImportC\n"); }
         @EOD
         gdc main.d -o main; ./main
!    will generate a program which will print 'Hello ImportC'.
  
     ImportC does not have a preprocessor.  It is designed to compile C
  files after they have been first run through the C preprocessor.  If the
! C file has a '.i' extension, the file is presumed to be already
  preprocessed.  Preprocessing can be run manually:
         gcc -E file.c > file.i
  
! ImportC collects all the '#define' macros from the preprocessor run when
  it is run automatically.  The macros that look like manifest constants,
  such as:
       #define COLOR 0x123456
--- 1401,1415 ----
         void main() { printf("Hello ImportC\n"); }
         @EOD
         gdc main.d -o main; ./main
!    will generate a program which will print ‘Hello ImportC’.
  
     ImportC does not have a preprocessor.  It is designed to compile C
  files after they have been first run through the C preprocessor.  If the
! C file has a ‘.i’ extension, the file is presumed to be already
  preprocessed.  Preprocessing can be run manually:
         gcc -E file.c > file.i
  
! ImportC collects all the ‘#define’ macros from the preprocessor run when
  it is run automatically.  The macros that look like manifest constants,
  such as:
       #define COLOR 0x123456
*************** macros.
*** 1422,1429 ****
  
     GNU D does not directly compile C files into modules that can be
  linked in with D code to form an executable.  When given a source file
! with the suffix '.c', the compiler driver program 'gdc' instead runs the
! subprogram 'cc1'.
  
       gdc file1.d file2.c // d21 file1.d -o file1.s
                           // cc1 file2.c -o file2.s
--- 1422,1429 ----
  
     GNU D does not directly compile C files into modules that can be
  linked in with D code to form an executable.  When given a source file
! with the suffix ‘.c’, the compiler driver program ‘gdc’ instead runs the
! subprogram ‘cc1’.
  
       gdc file1.d file2.c // d21 file1.d -o file1.s
                           // cc1 file2.c -o file2.s
*************** File: gdc.info,  Node: Inline Assembly,
*** 1437,1445 ****
  2.4 Inline Assembly
  ===================
  
! The 'asm' keyword allows you to embed assembler instructions within D
! code.  GNU D provides two forms of inline 'asm' statements.  A "basic
! 'asm'" statement is one with no operands, while an "extended 'asm'"
  statement includes one or more operands.
  
       asm FUNCTIONATTRIBUTES {
--- 1437,1445 ----
  2.4 Inline Assembly
  ===================
  
! The ‘asm’ keyword allows you to embed assembler instructions within D
! code.  GNU D provides two forms of inline ‘asm’ statements.  A “basic
! ‘asm’” statement is one with no operands, while an “extended ‘asm’”
  statement includes one or more operands.
  
       asm FUNCTIONATTRIBUTES {
*************** statement includes one or more operands.
*** 1456,1462 ****
  
  The extended form is preferred for mixing D and assembly language within
  a function, but to include assembly language in a function declared with
! the 'naked' attribute you must use basic 'asm'.
  
       uint incr (uint value)
       {
--- 1456,1462 ----
  
  The extended form is preferred for mixing D and assembly language within
  a function, but to include assembly language in a function declared with
! the ‘naked’ attribute you must use basic ‘asm’.
  
       uint incr (uint value)
       {
*************** the 'naked' attribute you must use basic
*** 1468,1474 ****
           return result;
       }
  
! Multiple assembler instructions can appear within an 'asm' block, or the
  instruction template can be a multi-line or concatenated string.  In
  both cases, GCC's optimizers won't discard or move any instruction
  within the statement block.
--- 1468,1474 ----
           return result;
       }
  
! Multiple assembler instructions can appear within an ‘asm’ block, or the
  instruction template can be a multi-line or concatenated string.  In
  both cases, GCC's optimizers won't discard or move any instruction
  within the statement block.
*************** within the statement block.
*** 1488,1494 ****
           return (flags & 0x0020_0000) != 0;
       }
  
! The instruction templates for both basic and extended 'asm' can be any
  expression that can be evaluated at compile-time to a string, not just
  string literals.
  
--- 1488,1494 ----
           return (flags & 0x0020_0000) != 0;
       }
  
! The instruction templates for both basic and extended ‘asm’ can be any
  expression that can be evaluated at compile-time to a string, not just
  string literals.
  
*************** File: gdc.info,  Node: Bit Operation Int
*** 1538,1544 ****
  ------------------------------
  
  The following functions are a collection of intrinsics that do bit-level
! operations, available by importing the 'core.bitop' module.
  
     Although most are named after x86 hardware instructions, it is not
  guaranteed that they will result in generating equivalent assembly on
--- 1538,1544 ----
  ------------------------------
  
  The following functions are a collection of intrinsics that do bit-level
! operations, available by importing the ‘core.bitop’ module.
  
     Although most are named after x86 hardware instructions, it is not
  guaranteed that they will result in generating equivalent assembly on
*************** result in hardware, then that will be us
*** 1548,1559 ****
   -- Function: int core.bitop.bsf (uint V)
   -- Function: int core.bitop.bsf (ulong V)
  
!      Scans the bits in V starting with bit '0', looking for the first
       set bit.  Returns the bit number of the first bit set.  The return
       value is undefined if V is zero.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_ctz'.
  
   -- Function: int core.bitop.bsr (uint V)
   -- Function: int core.bitop.bsr (ulong V)
--- 1548,1559 ----
   -- Function: int core.bitop.bsf (uint V)
   -- Function: int core.bitop.bsf (ulong V)
  
!      Scans the bits in V starting with bit ‘0’, looking for the first
       set bit.  Returns the bit number of the first bit set.  The return
       value is undefined if V is zero.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_ctz’.
  
   -- Function: int core.bitop.bsr (uint V)
   -- Function: int core.bitop.bsr (ulong V)
*************** result in hardware, then that will be us
*** 1626,1636 ****
   -- Function: uint core.bitop.bswap (uint X)
   -- Function: ulong core.bitop.bswap (ulong X)
  
!      Swaps the bytes in X end-to-end; for example, in a 4-byte 'uint',
!      byte '0' becomes byte '3', byte '1' becomes byte '2', etc.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_bswap'.
  
   -- Function: int core.bitop.popcnt (uint X)
   -- Function: int core.bitop.popcnt (ulong X)
--- 1626,1636 ----
   -- Function: uint core.bitop.bswap (uint X)
   -- Function: ulong core.bitop.bswap (ulong X)
  
!      Swaps the bytes in X end-to-end; for example, in a 4-byte ‘uint’,
!      byte ‘0’ becomes byte ‘3’, byte ‘1’ becomes byte ‘2’, etc.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_bswap’.
  
   -- Function: int core.bitop.popcnt (uint X)
   -- Function: int core.bitop.popcnt (ulong X)
*************** result in hardware, then that will be us
*** 1638,1644 ****
       Calculates the number of set bits in X.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_popcount'.
  
   -- Template: T core.bitop.rol (T)(const T VALUE, const uint COUNT)
   -- Template: T core.bitop.rol (uint COUNT, T)(const T VALUE)
--- 1638,1644 ----
       Calculates the number of set bits in X.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_popcount’.
  
   -- Template: T core.bitop.rol (T)(const T VALUE, const uint COUNT)
   -- Template: T core.bitop.rol (uint COUNT, T)(const T VALUE)
*************** File: gdc.info,  Node: Integer Overflow
*** 1664,1670 ****
  
  The following functions are a collection of intrinsics that implement
  integral arithmetic primitives that check for out-of-range results,
! available by importing the 'core.checkedint' module.
  
     In all intrinsics, the overflow is sticky, meaning a sequence of
  operations can be done and overflow need only be checked at the end.
--- 1664,1670 ----
  
  The following functions are a collection of intrinsics that implement
  integral arithmetic primitives that check for out-of-range results,
! available by importing the ‘core.checkedint’ module.
  
     In all intrinsics, the overflow is sticky, meaning a sequence of
  operations can be done and overflow need only be checked at the end.
*************** operations can be done and overflow need
*** 1676,1682 ****
       Add two signed integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_sadd_overflow'.
  
   -- Function: int core.checkedint.addu (int X, int Y, ref bool OVERFLOW)
   -- Function: long core.checkedint.addu (long X, long Y, ref bool
--- 1676,1682 ----
       Add two signed integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_sadd_overflow’.
  
   -- Function: int core.checkedint.addu (int X, int Y, ref bool OVERFLOW)
   -- Function: long core.checkedint.addu (long X, long Y, ref bool
*************** operations can be done and overflow need
*** 1685,1691 ****
       Add two unsigned integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_uadd_overflow'.
  
   -- Function: int core.checkedint.muls (int X, int Y, ref bool OVERFLOW)
   -- Function: long core.checkedint.muls (long X, long Y, ref bool
--- 1685,1691 ----
       Add two unsigned integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_uadd_overflow’.
  
   -- Function: int core.checkedint.muls (int X, int Y, ref bool OVERFLOW)
   -- Function: long core.checkedint.muls (long X, long Y, ref bool
*************** operations can be done and overflow need
*** 1694,1700 ****
       Multiply two signed integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_smul_overflow'.
  
   -- Function: int core.checkedint.mulu (int X, int Y, ref bool OVERFLOW)
   -- Function: long core.checkedint.mulu (long X, long Y, ref bool
--- 1694,1700 ----
       Multiply two signed integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_smul_overflow’.
  
   -- Function: int core.checkedint.mulu (int X, int Y, ref bool OVERFLOW)
   -- Function: long core.checkedint.mulu (long X, long Y, ref bool
*************** operations can be done and overflow need
*** 1703,1709 ****
       Multiply two unsigned integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_umul_overflow'.
  
   -- Function: int core.checkedint.negs (int X, ref bool OVERFLOW)
   -- Function: long core.checkedint.negs (long X, ref bool OVERFLOW)
--- 1703,1709 ----
       Multiply two unsigned integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_umul_overflow’.
  
   -- Function: int core.checkedint.negs (int X, ref bool OVERFLOW)
   -- Function: long core.checkedint.negs (long X, ref bool OVERFLOW)
*************** operations can be done and overflow need
*** 1720,1726 ****
       Substract two signed integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_ssub_overflow'.
  
   -- Function: int core.checkedint.subu (int X, int Y, ref bool OVERFLOW)
   -- Function: long core.checkedint.subu (long X, long Y, ref bool
--- 1720,1726 ----
       Substract two signed integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_ssub_overflow’.
  
   -- Function: int core.checkedint.subu (int X, int Y, ref bool OVERFLOW)
   -- Function: long core.checkedint.subu (long X, long Y, ref bool
*************** operations can be done and overflow need
*** 1729,1735 ****
       Substract two unsigned integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_usub_overflow'.
  
  
  File: gdc.info,  Node: Math Intrinsics,  Next: Variadic Intrinsics,  Prev: Integer Overflow Intrinsics,  Up: Intrinsics
--- 1729,1735 ----
       Substract two unsigned integers, checking for overflow.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_usub_overflow’.
  
  
  File: gdc.info,  Node: Math Intrinsics,  Next: Variadic Intrinsics,  Prev: Integer Overflow Intrinsics,  Up: Intrinsics
*************** File: gdc.info,  Node: Math Intrinsics,
*** 1738,1744 ****
  ---------------------
  
  The following functions are a collection of mathematical intrinsics,
! available by importing the 'core.math' module.
  
   -- Function: float core.math.cos (float x)
   -- Function: double core.math.cos (double x)
--- 1738,1744 ----
  ---------------------
  
  The following functions are a collection of mathematical intrinsics,
! available by importing the ‘core.math’ module.
  
   -- Function: float core.math.cos (float x)
   -- Function: double core.math.cos (double x)
*************** available by importing the 'core.math' m
*** 1748,1754 ****
       undefined if X is greater than 2^{64}.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_cos'.
  
   -- Function: float core.math.fabs (float x)
   -- Function: double core.math.fabs (double x)
--- 1748,1754 ----
       undefined if X is greater than 2^{64}.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_cos’.
  
   -- Function: float core.math.fabs (float x)
   -- Function: double core.math.fabs (double x)
*************** available by importing the 'core.math' m
*** 1757,1763 ****
       Compute the absolute value of X.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_fabs'.
  
   -- Function: float core.math.ldexp (float n, int exp)
   -- Function: double core.math.ldexp (double n, int exp)
--- 1757,1763 ----
       Compute the absolute value of X.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_fabs’.
  
   -- Function: float core.math.ldexp (float n, int exp)
   -- Function: double core.math.ldexp (double n, int exp)
*************** available by importing the 'core.math' m
*** 1766,1795 ****
       Compute n * 2^{exp}.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_ldexp'.
  
   -- Function: float core.math.rint (float x)
   -- Function: double core.math.rint (double x)
   -- Function: real core.math.rint (real x)
  
       Rounds X to the nearest integer value, using the current rounding
!      mode.  If the return value is not equal to X, the 'FE_INEXACT'
!      exception is raised.  'nearbyint' performs the same operation, but
!      does not set the 'FE_INEXACT' exception.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_rint'.
  
   -- Function: float core.math.rndtol (float x)
   -- Function: double core.math.rndtol (double x)
   -- Function: real core.math.rndtol (real x)
  
       Returns X rounded to a long value using the current rounding mode.
!      If the integer value of X is greater than 'long.max', the result is
       indeterminate.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_llround'.
  
   -- Function: float core.math.sin (float x)
   -- Function: double core.math.sin (double x)
--- 1766,1795 ----
       Compute n * 2^{exp}.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_ldexp’.
  
   -- Function: float core.math.rint (float x)
   -- Function: double core.math.rint (double x)
   -- Function: real core.math.rint (real x)
  
       Rounds X to the nearest integer value, using the current rounding
!      mode.  If the return value is not equal to X, the ‘FE_INEXACT’
!      exception is raised.  ‘nearbyint’ performs the same operation, but
!      does not set the ‘FE_INEXACT’ exception.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_rint’.
  
   -- Function: float core.math.rndtol (float x)
   -- Function: double core.math.rndtol (double x)
   -- Function: real core.math.rndtol (real x)
  
       Returns X rounded to a long value using the current rounding mode.
!      If the integer value of X is greater than ‘long.max’, the result is
       indeterminate.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_llround’.
  
   -- Function: float core.math.sin (float x)
   -- Function: double core.math.sin (double x)
*************** available by importing the 'core.math' m
*** 1799,1805 ****
       undefined if X is greater than 2^{64}.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_sin'.
  
   -- Function: float core.math.sqrt (float x)
   -- Function: double core.math.sqrt (double x)
--- 1799,1805 ----
       undefined if X is greater than 2^{64}.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_sin’.
  
   -- Function: float core.math.sqrt (float x)
   -- Function: double core.math.sqrt (double x)
*************** available by importing the 'core.math' m
*** 1808,1814 ****
       Compute the sqrt of X.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_sqrt'.
  
   -- Template: T core.math.toPrec (T)(float f)
   -- Template: T core.math.toPrec (T)(double f)
--- 1808,1814 ----
       Compute the sqrt of X.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_sqrt’.
  
   -- Template: T core.math.toPrec (T)(float f)
   -- Template: T core.math.toPrec (T)(double f)
*************** available by importing the 'core.math' m
*** 1817,1825 ****
       Round F to a specific precision.
  
       In floating-point operations, D language types specify only a
!      minimum precision, not a maximum.  The 'toPrec' function forces
       rounding of the argument F to the precision of the specified
!      floating point type 'T'.  The rounding mode used is inevitably
       target-dependent, but will be done in a way to maximize accuracy.
       In most cases, the default is round-to-nearest.
  
--- 1817,1825 ----
       Round F to a specific precision.
  
       In floating-point operations, D language types specify only a
!      minimum precision, not a maximum.  The ‘toPrec’ function forces
       rounding of the argument F to the precision of the specified
!      floating point type ‘T’.  The rounding mode used is inevitably
       target-dependent, but will be done in a way to maximize accuracy.
       In most cases, the default is round-to-nearest.
  
*************** File: gdc.info,  Node: Variadic Intrinsi
*** 1830,1850 ****
  -------------------------
  
  The following functions are a collection of variadic intrinsics,
! available by importing the 'core.stdc.stdarg' module.
  
   -- Template: void core.stdc.stdarg.va_arg (T)(ref va_list ap, ref T
            parmn)
  
!      Retrieve and store in PARMN the next value from the 'va_list' AP
!      that is of type 'T'.
  
       This intrinsic is equivalent to writing the following:
            parmn = __builtin_va_arg (ap, T);
  
   -- Template: T core.stdc.stdarg.va_arg (T)(ref va_list ap)
  
!      Retrieve and return the next value from the 'va_list' AP that is of
!      type 'T'.
  
       This intrinsic is equivalent to writing the following:
            result = __builtin_va_arg (ap, T);
--- 1830,1850 ----
  -------------------------
  
  The following functions are a collection of variadic intrinsics,
! available by importing the ‘core.stdc.stdarg’ module.
  
   -- Template: void core.stdc.stdarg.va_arg (T)(ref va_list ap, ref T
            parmn)
  
!      Retrieve and store in PARMN the next value from the ‘va_list’ AP
!      that is of type ‘T’.
  
       This intrinsic is equivalent to writing the following:
            parmn = __builtin_va_arg (ap, T);
  
   -- Template: T core.stdc.stdarg.va_arg (T)(ref va_list ap)
  
!      Retrieve and return the next value from the ‘va_list’ AP that is of
!      type ‘T’.
  
       This intrinsic is equivalent to writing the following:
            result = __builtin_va_arg (ap, T);
*************** available by importing the 'core.stdc.st
*** 1855,1868 ****
       Make a copy of SRC in its current state and store to DEST.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_va_copy'.
  
   -- Function: void core.stdc.stdarg.va_end (va_list ap)
  
       Destroy AP so that it is no longer useable.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_va_end'.
  
   -- Template: void core.stdc.stdarg.va_start (T)(out va_list ap, ref T
            parmn)
--- 1855,1868 ----
       Make a copy of SRC in its current state and store to DEST.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_va_copy’.
  
   -- Function: void core.stdc.stdarg.va_end (va_list ap)
  
       Destroy AP so that it is no longer useable.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_va_end’.
  
   -- Template: void core.stdc.stdarg.va_start (T)(out va_list ap, ref T
            parmn)
*************** available by importing the 'core.stdc.st
*** 1871,1877 ****
       arguments that follow the named argument PARMN.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_va_start'.
  
  
  File: gdc.info,  Node: Volatile Intrinsics,  Next: CTFE Intrinsics,  Prev: Variadic Intrinsics,  Up: Intrinsics
--- 1871,1877 ----
       arguments that follow the named argument PARMN.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_va_start’.
  
  
  File: gdc.info,  Node: Volatile Intrinsics,  Next: CTFE Intrinsics,  Prev: Variadic Intrinsics,  Up: Intrinsics
*************** File: gdc.info,  Node: Volatile Intrinsi
*** 1880,1886 ****
  -------------------------
  
  The following functions are a collection of intrinsics for volatile
! operations, available by importing the 'core.volatile' module.
  
     Calls to them are guaranteed to not be removed (as dead assignment
  elimination or presumed to have no effect) or reordered in the same
--- 1880,1886 ----
  -------------------------
  
  The following functions are a collection of intrinsics for volatile
! operations, available by importing the ‘core.volatile’ module.
  
     Calls to them are guaranteed to not be removed (as dead assignment
  elimination or presumed to have no effect) or reordered in the same
*************** values from the same location due to ext
*** 1898,1904 ****
  
     These functions will, when possible, do the load/store as a single
  operation.  In general, this is possible when the size of the operation
! is less than or equal to '(void*).sizeof', although some targets may
  support larger operations.  If the load/store cannot be done as a single
  operation, multiple smaller operations will be used.
  
--- 1898,1904 ----
  
     These functions will, when possible, do the load/store as a single
  operation.  In general, this is possible when the size of the operation
! is less than or equal to ‘(void*).sizeof’, although some targets may
  support larger operations.  If the load/store cannot be done as a single
  operation, multiple smaller operations will be used.
  
*************** suppport.
*** 1950,1956 ****
       Calculates e^x.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_exp'.
  
   -- Function: float std.math.exponential.expm1 (float x)
   -- Function: double std.math.exponential.expm1 (double x)
--- 1950,1956 ----
       Calculates e^x.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_exp’.
  
   -- Function: float std.math.exponential.expm1 (float x)
   -- Function: double std.math.exponential.expm1 (double x)
*************** suppport.
*** 1959,1965 ****
       Calculates e^x-1.0.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_expm1'.
  
   -- Function: float std.math.exponential.exp2 (float x)
   -- Function: double std.math.exponential.exp2 (double x)
--- 1959,1965 ----
       Calculates e^x-1.0.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_expm1’.
  
   -- Function: float std.math.exponential.exp2 (float x)
   -- Function: double std.math.exponential.exp2 (double x)
*************** suppport.
*** 1968,1974 ****
       Calculates 2^x.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_exp2'.
  
   -- Function: float std.math.exponential.log (float x)
   -- Function: double std.math.exponential.log (double x)
--- 1968,1974 ----
       Calculates 2^x.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_exp2’.
  
   -- Function: float std.math.exponential.log (float x)
   -- Function: double std.math.exponential.log (double x)
*************** suppport.
*** 1977,1983 ****
       Calculate the natural logarithm of X.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_log'.
  
   -- Function: float std.math.exponential.log10 (float x)
   -- Function: double std.math.exponential.log10 (double x)
--- 1977,1983 ----
       Calculate the natural logarithm of X.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_log’.
  
   -- Function: float std.math.exponential.log10 (float x)
   -- Function: double std.math.exponential.log10 (double x)
*************** suppport.
*** 1986,1992 ****
       Calculates the base-10 logarithm of X.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_log10'.
  
   -- Function: float std.math.exponential.log2 (float x)
   -- Function: double std.math.exponential.log2 (double x)
--- 1986,1992 ----
       Calculates the base-10 logarithm of X.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_log10’.
  
   -- Function: float std.math.exponential.log2 (float x)
   -- Function: double std.math.exponential.log2 (double x)
*************** suppport.
*** 1995,2001 ****
       Calculates the base-2 logarithm of X.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_log2'.
  
   -- Template: Largest!(F, G) std.math.exponential.pow (F, G) (F x, G y)
   -- Template: real std.math.exponential.pow (I, F)(I x, F y)
--- 1995,2001 ----
       Calculates the base-2 logarithm of X.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_log2’.
  
   -- Template: Largest!(F, G) std.math.exponential.pow (F, G) (F x, G y)
   -- Template: real std.math.exponential.pow (I, F)(I x, F y)
*************** suppport.
*** 2003,2038 ****
       Calculates x^y, where Y is a float.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_pow'.
  
   -- Template: F std.math.exponential.pow (F, G) (F x, G n)
  
       Calculates x^n, where N is an integer.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_powi'.
  
   -- Function: real std.math.operations.fma (real x, real y, real z)
  
!      Returns '(x * y) + z', rounding only once according to the current
       rounding mode.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_fma'.
  
   -- Template: F std.math.operations.fmax (F)(const F x, const F y)
  
       Returns the larger of X and Y.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_fmax'.
  
   -- Template: F std.math.operations.fmin (F)(const F x, const F y)
  
       Returns the smaller of X and Y.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_fmin'.
  
   -- Function: float std.math.rounding.ceil (float x)
   -- Function: double std.math.rounding.ceil (double x)
--- 2003,2038 ----
       Calculates x^y, where Y is a float.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_pow’.
  
   -- Template: F std.math.exponential.pow (F, G) (F x, G n)
  
       Calculates x^n, where N is an integer.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_powi’.
  
   -- Function: real std.math.operations.fma (real x, real y, real z)
  
!      Returns ‘(x * y) + z’, rounding only once according to the current
       rounding mode.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_fma’.
  
   -- Template: F std.math.operations.fmax (F)(const F x, const F y)
  
       Returns the larger of X and Y.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_fmax’.
  
   -- Template: F std.math.operations.fmin (F)(const F x, const F y)
  
       Returns the smaller of X and Y.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_fmin’.
  
   -- Function: float std.math.rounding.ceil (float x)
   -- Function: double std.math.rounding.ceil (double x)
*************** suppport.
*** 2042,2048 ****
       positive infinity).
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_ceil'.
  
   -- Function: float std.math.rounding.floor (float x)
   -- Function: double std.math.rounding.floor (double x)
--- 2042,2048 ----
       positive infinity).
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_ceil’.
  
   -- Function: float std.math.rounding.floor (float x)
   -- Function: double std.math.rounding.floor (double x)
*************** suppport.
*** 2052,2058 ****
       negative infinity).
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_floor'.
  
   -- Function: real std.math.rounding.round (real x)
  
--- 2052,2058 ----
       negative infinity).
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_floor’.
  
   -- Function: real std.math.rounding.round (real x)
  
*************** suppport.
*** 2061,2102 ****
       away from zero.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_round'.
  
   -- Function: real std.math.rounding.trunc (real x)
  
       Returns the integer portion of X, dropping the fractional portion.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_trunc'.
  
   -- Template: R std.math.traits.copysign (R, X)(R to, X from)
  
       Returns a value composed of TO with FROM's sign bit.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_copysign'.
  
   -- Template: bool std.math.traits.isFinite (X)(X x)
  
       Returns true if X is finite.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_isfinite'.
  
   -- Template: bool std.math.traits.isInfinity (X)(X x)
  
       Returns true if X is infinite.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_isinf'.
  
   -- Template: bool std.math.traits.isNaN (X)(X x)
  
       Returns true if X is NaN.
  
       This function is evaluated during CTFE as the GCC built-in function
!      '__builtin_isnan'.
  
   -- Function: float std.math.trigoometry.tan (float x)
   -- Function: double std.math.trigoometry.tan (double x)
--- 2061,2102 ----
       away from zero.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_round’.
  
   -- Function: real std.math.rounding.trunc (real x)
  
       Returns the integer portion of X, dropping the fractional portion.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_trunc’.
  
   -- Template: R std.math.traits.copysign (R, X)(R to, X from)
  
       Returns a value composed of TO with FROM's sign bit.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_copysign’.
  
   -- Template: bool std.math.traits.isFinite (X)(X x)
  
       Returns true if X is finite.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_isfinite’.
  
   -- Template: bool std.math.traits.isInfinity (X)(X x)
  
       Returns true if X is infinite.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_isinf’.
  
   -- Template: bool std.math.traits.isNaN (X)(X x)
  
       Returns true if X is NaN.
  
       This function is evaluated during CTFE as the GCC built-in function
!      ‘__builtin_isnan’.
  
   -- Function: float std.math.trigoometry.tan (float x)
   -- Function: double std.math.trigoometry.tan (double x)
*************** suppport.
*** 2105,2111 ****
       Returns tangent of X, where X is in radians.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_tan'.
  
  
  File: gdc.info,  Node: Predefined Pragmas,  Next: Predefined Versions,  Prev: Intrinsics,  Up: D Implementation
--- 2105,2111 ----
       Returns tangent of X, where X is in radians.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_tan’.
  
  
  File: gdc.info,  Node: Predefined Pragmas,  Next: Predefined Versions,  Prev: Intrinsics,  Up: D Implementation
*************** File: gdc.info,  Node: Predefined Pragma
*** 2113,2119 ****
  2.6 Predefined Pragmas
  ======================
  
! The 'pragma' operator is used as a way to pass special information to
  the implementation and allow the addition of vendor specific extensions.
  The standard predefined pragmas are documented by the D language
  specification hosted at
--- 2113,2119 ----
  2.6 Predefined Pragmas
  ======================
  
! The ‘pragma’ operator is used as a way to pass special information to
  the implementation and allow the addition of vendor specific extensions.
  The standard predefined pragmas are documented by the D language
  specification hosted at
*************** specification hosted at
*** 2121,2173 ****
  must recognize, but is free to ignore any pragma in this list.
  
     Where a pragma is ignored, the GNU D compiler will emit a warning
! when the '-Wunknown-pragmas' option is seen on the command-line.
  
! 'pragma(crt_constructor)'
!      'pragma(crt_constructor)' annotates a function so it is run after
       the C runtime library is initialized and before the D runtime
       library is initialized.  Functions with this pragma must return
!      'void'.
            pragma(crt_constructor) void init() { }
  
! 'pragma(crt_destructor)'
!      'pragma(crt_destructor)' annotates a function so it is run after
       the D runtime library is terminated and before the C runtime
!      library is terminated.  Calling 'exit' function also causes the
       annotated functions to run.  Functions with this pragma must return
!      'void'.
            pragma(crt_destructor) void init() { }
  
! 'pragma(inline)'
! 'pragma(inline, false)'
! 'pragma(inline, true)'
!      'pragma(inline)' affects whether functions are declared inlined or
       not.  The pragma takes two forms.  In the first form, inlining is
       controlled by the command-line options for inlining.
  
!      Functions annotated with 'pragma(inline, false)' are marked
!      uninlinable.  Functions annotated with 'pragma(inline, true)' are
       always inlined.
  
! 'pragma(lib)'
       This pragma is accepted, but has no effect.
            pragma(lib, "advapi32");
  
! 'pragma(linkerDirective)'
       This pragma is accepted, but has no effect.
            pragma(linkerDirective, "/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2");
  
! 'pragma(mangle)'
!      'pragma(mangle, "symbol_name")' overrides the default mangling for
       a function or variable symbol.  The symbol name can be any
       expression that must evaluate at compile time to a string literal.
       This enables linking to a symbol which is a D keyword, since an
       identifier cannot be a keyword.
  
       Targets are free to apply a prefix to the user label of the symbol
!      name in assembly.  For example, on 'x86_64-apple-darwin',
!      'symbol_name' would produce '_symbol_name'.  If the mangle string
!      begins with '*', then 'pragma(mangle)' will output the rest of the
       string unchanged.
  
            pragma(mangle, "body")
--- 2121,2173 ----
  must recognize, but is free to ignore any pragma in this list.
  
     Where a pragma is ignored, the GNU D compiler will emit a warning
! when the ‘-Wunknown-pragmas’ option is seen on the command-line.
  
! ‘pragma(crt_constructor)’
!      ‘pragma(crt_constructor)’ annotates a function so it is run after
       the C runtime library is initialized and before the D runtime
       library is initialized.  Functions with this pragma must return
!      ‘void’.
            pragma(crt_constructor) void init() { }
  
! ‘pragma(crt_destructor)’
!      ‘pragma(crt_destructor)’ annotates a function so it is run after
       the D runtime library is terminated and before the C runtime
!      library is terminated.  Calling ‘exit’ function also causes the
       annotated functions to run.  Functions with this pragma must return
!      ‘void’.
            pragma(crt_destructor) void init() { }
  
! ‘pragma(inline)’
! ‘pragma(inline, false)’
! ‘pragma(inline, true)’
!      ‘pragma(inline)’ affects whether functions are declared inlined or
       not.  The pragma takes two forms.  In the first form, inlining is
       controlled by the command-line options for inlining.
  
!      Functions annotated with ‘pragma(inline, false)’ are marked
!      uninlinable.  Functions annotated with ‘pragma(inline, true)’ are
       always inlined.
  
! ‘pragma(lib)’
       This pragma is accepted, but has no effect.
            pragma(lib, "advapi32");
  
! ‘pragma(linkerDirective)’
       This pragma is accepted, but has no effect.
            pragma(linkerDirective, "/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=2");
  
! ‘pragma(mangle)’
!      ‘pragma(mangle, "symbol_name")’ overrides the default mangling for
       a function or variable symbol.  The symbol name can be any
       expression that must evaluate at compile time to a string literal.
       This enables linking to a symbol which is a D keyword, since an
       identifier cannot be a keyword.
  
       Targets are free to apply a prefix to the user label of the symbol
!      name in assembly.  For example, on ‘x86_64-apple-darwin’,
!      ‘symbol_name’ would produce ‘_symbol_name’.  If the mangle string
!      begins with ‘*’, then ‘pragma(mangle)’ will output the rest of the
       string unchanged.
  
            pragma(mangle, "body")
*************** when the '-Wunknown-pragmas' option is s
*** 2176,2200 ****
            pragma(mangle, "function")
            extern(C++) struct _function {}
  
! 'pragma(msg)'
!      'pragma(msg, "message")' causes the compiler to print an
!      informational message with the text 'message'.  The pragma accepts
       multiple arguments, each to which is evaluated at compile time and
       then all are combined into one concatenated message.
            pragma(msg, "compiling...", 6, 1.0); // prints "compiling...61.0"
  
! 'pragma(printf)'
! 'pragma(scanf)'
  
!      'pragma(printf)' and 'pragma(scanf)' specifies that a function
!      declaration with 'printf' or 'scanf' style arguments that should be
       type-checked against a format string.
  
!      A printf-like or scanf-like function can either be an 'extern(C)'
!      or 'extern(C++)' function with a FORMAT parameter accepting a
!      pointer to a 0-terminated 'char' string, immediately followed by
!      either a '...' variadic argument list or a parameter of type
!      'va_list' as the last parameter.
  
            extern(C):
            pragma(printf)
--- 2176,2200 ----
            pragma(mangle, "function")
            extern(C++) struct _function {}
  
! ‘pragma(msg)’
!      ‘pragma(msg, "message")’ causes the compiler to print an
!      informational message with the text ‘message’.  The pragma accepts
       multiple arguments, each to which is evaluated at compile time and
       then all are combined into one concatenated message.
            pragma(msg, "compiling...", 6, 1.0); // prints "compiling...61.0"
  
! ‘pragma(printf)’
! ‘pragma(scanf)’
  
!      ‘pragma(printf)’ and ‘pragma(scanf)’ specifies that a function
!      declaration with ‘printf’ or ‘scanf’ style arguments that should be
       type-checked against a format string.
  
!      A printf-like or scanf-like function can either be an ‘extern(C)’
!      or ‘extern(C++)’ function with a FORMAT parameter accepting a
!      pointer to a 0-terminated ‘char’ string, immediately followed by
!      either a ‘...’ variadic argument list or a parameter of type
!      ‘va_list’ as the last parameter.
  
            extern(C):
            pragma(printf)
*************** when the '-Wunknown-pragmas' option is s
*** 2203,2209 ****
            pragma(scanf)
            int vscanf(scope const char* format, va_list arg);
  
! 'pragma(startaddress)'
       This pragma is accepted, but has no effect.
            void foo() { }
            pragma(startaddress, foo);
--- 2203,2209 ----
            pragma(scanf)
            int vscanf(scope const char* format, va_list arg);
  
! ‘pragma(startaddress)’
       This pragma is accepted, but has no effect.
            void foo() { }
            pragma(startaddress, foo);
*************** standard, common, and target-specific.
*** 2220,2226 ****
  
     Predefined version identifiers from this list cannot be set from the
  command line or from version statements.  This prevents things like both
! 'Windows' and 'linux' being simultaneously set.
  
  * Menu:
  
--- 2220,2226 ----
  
     Predefined version identifiers from this list cannot be set from the
  command line or from version statements.  This prevents things like both
! ‘Windows’ and ‘linux’ being simultaneously set.
  
  * Menu:
  
*************** The standard predefined versions are doc
*** 2238,2346 ****
  specification hosted at
  .
  
! 'all'
! 'none'
!      Version 'none' is never defined; used to just disable a section of
!      code.  Version 'all' is always defined; used as the opposite of
!      'none'.
  
! 'BigEndian'
! 'LittleEndian'
       These versions reflect the byte order of multi-byte data in memory.
!      'LittleEndian' is set when the least significant byte is first.
!      'BigEndian' is set when the most significant byte is first.
  
! 'CRuntime_Bionic'
! 'CRuntime_Glibc'
! 'CRuntime_Microsoft'
! 'CRuntime_Musl'
! 'CRuntime_Newlib'
! 'CRuntime_UClibc'
  
       These versions reflect which standard C library is being linked in.
!      'CRuntime_Bionic' is set when Bionic is the default C library.
!      'CRuntime_Glibc' is set when GLIBC is the default C library.
!      'CRuntime_Microsoft' is set when MSVCRT is the default C library.
!      'CRuntime_Musl' is set when musl is the default C library.
!      'CRuntime_Newlib' is set when Newlib is the default C library.
!      'CRuntime_UClibc' is set when uClibc is the default C library.
  
! 'CppRuntime_Gcc'
       This version is defined when the standard C++ library being linked
!      in is 'libstdc++'.
  
! 'D_BetterC'
       This version is defined when the standard D libraries are not being
       implicitly linked in.  This also implies that features of the D
       language that rely on exceptions, module information, or run-time
!      type information are disabled as well.  Enabled by '-fno-druntime'.
  
! 'D_Coverage'
       This version is defined when code coverage analysis instrumentation
!      is being generated.  Enabled by '-ftest-coverage'.
  
! 'D_Ddoc'
       This version is defined when Ddoc documentation is being generated.
!      Enabled by '-fdoc'.
  
! 'D_Exceptions'
       This version is defined when exception handling is supported.
!      Disabled by '-fno-exceptions'.
  
! 'D_HardFloat'
! 'D_SoftFloat'
       These versions reflect the floating-point ABI in use by the target.
!      'D_HardFloat' is set when the target hardware has a floating-point
!      unit.  'D_SoftFloat' is set when the target hardware does not have
       a floating-point unit.
  
! 'D_Invariants'
       This version is defined when checks are being emitted for class
!      invariants and struct invariants.  Enabled by '-finvariants'.
  
! 'D_LP64'
       This version is defined when pointers are 64-bits.  Not to be
!      confused with with C's '__LP64__' model.
  
! 'D_ModuleInfo'
       This version is defined when run-time module information (also
!      known as 'ModuleInfo') is supported.  Disabled by
!      '-fno-moduleinfo'.
  
! 'D_NoBoundsChecks'
       This version is defined when array bounds checks are disabled.
!      Enabled by '-fno-bounds-checks'.
  
! 'D_Optimized'
       This version is defined in all optimizing compilations.
  
! 'D_PIC'
       This version is defined when position-independent code is being
!      generated.  Enabled by '-fPIC'.
  
! 'D_PIE'
       This version is defined when position-independent code that can be
       only linked into executables is being generated.  Enabled by
!      '-fPIE'.
  
! 'D_PreConditions'
!      This version is defined when checks are being emitted for 'in'
!      contracts.  Disabled by '-fno-preconditions'.
  
! 'D_PostConditions'
!      This version is defined when checks are being emitted for 'out'
!      contracts.  Disabled by '-fno-postconditions'.
  
! 'D_TypeInfo'
       This version is defined when run-time type information (also known
!      as 'TypeInfo') is supported.  Disabled by '-fno-rtti'.
  
! 'D_Version2'
       This version defined when this is a D version 2 compiler.
  
! 'unittest'
!      This version is defined when the 'unittest' code is being compiled
!      in.  Enabled by '-funittest'.
  
  
  File: gdc.info,  Node: Common Predefined Versions,  Next: Target Predefined Versions,  Prev: Standard Predefined Versions,  Up: Predefined Versions
--- 2238,2346 ----
  specification hosted at
  .
  
! ‘all’
! ‘none’
!      Version ‘none’ is never defined; used to just disable a section of
!      code.  Version ‘all’ is always defined; used as the opposite of
!      ‘none’.
  
! ‘BigEndian’
! ‘LittleEndian’
       These versions reflect the byte order of multi-byte data in memory.
!      ‘LittleEndian’ is set when the least significant byte is first.
!      ‘BigEndian’ is set when the most significant byte is first.
  
! ‘CRuntime_Bionic’
! ‘CRuntime_Glibc’
! ‘CRuntime_Microsoft’
! ‘CRuntime_Musl’
! ‘CRuntime_Newlib’
! ‘CRuntime_UClibc’
  
       These versions reflect which standard C library is being linked in.
!      ‘CRuntime_Bionic’ is set when Bionic is the default C library.
!      ‘CRuntime_Glibc’ is set when GLIBC is the default C library.
!      ‘CRuntime_Microsoft’ is set when MSVCRT is the default C library.
!      ‘CRuntime_Musl’ is set when musl is the default C library.
!      ‘CRuntime_Newlib’ is set when Newlib is the default C library.
!      ‘CRuntime_UClibc’ is set when uClibc is the default C library.
  
! ‘CppRuntime_Gcc’
       This version is defined when the standard C++ library being linked
!      in is ‘libstdc++’.
  
! ‘D_BetterC’
       This version is defined when the standard D libraries are not being
       implicitly linked in.  This also implies that features of the D
       language that rely on exceptions, module information, or run-time
!      type information are disabled as well.  Enabled by ‘-fno-druntime’.
  
! ‘D_Coverage’
       This version is defined when code coverage analysis instrumentation
!      is being generated.  Enabled by ‘-ftest-coverage’.
  
! ‘D_Ddoc’
       This version is defined when Ddoc documentation is being generated.
!      Enabled by ‘-fdoc’.
  
! ‘D_Exceptions’
       This version is defined when exception handling is supported.
!      Disabled by ‘-fno-exceptions’.
  
! ‘D_HardFloat’
! ‘D_SoftFloat’
       These versions reflect the floating-point ABI in use by the target.
!      ‘D_HardFloat’ is set when the target hardware has a floating-point
!      unit.  ‘D_SoftFloat’ is set when the target hardware does not have
       a floating-point unit.
  
! ‘D_Invariants’
       This version is defined when checks are being emitted for class
!      invariants and struct invariants.  Enabled by ‘-finvariants’.
  
! ‘D_LP64’
       This version is defined when pointers are 64-bits.  Not to be
!      confused with with C's ‘__LP64__’ model.
  
! ‘D_ModuleInfo’
       This version is defined when run-time module information (also
!      known as ‘ModuleInfo’) is supported.  Disabled by
!      ‘-fno-moduleinfo’.
  
! ‘D_NoBoundsChecks’
       This version is defined when array bounds checks are disabled.
!      Enabled by ‘-fno-bounds-checks’.
  
! ‘D_Optimized’
       This version is defined in all optimizing compilations.
  
! ‘D_PIC’
       This version is defined when position-independent code is being
!      generated.  Enabled by ‘-fPIC’.
  
! ‘D_PIE’
       This version is defined when position-independent code that can be
       only linked into executables is being generated.  Enabled by
!      ‘-fPIE’.
  
! ‘D_PreConditions’
!      This version is defined when checks are being emitted for ‘in’
!      contracts.  Disabled by ‘-fno-preconditions’.
  
! ‘D_PostConditions’
!      This version is defined when checks are being emitted for ‘out’
!      contracts.  Disabled by ‘-fno-postconditions’.
  
! ‘D_TypeInfo’
       This version is defined when run-time type information (also known
!      as ‘TypeInfo’) is supported.  Disabled by ‘-fno-rtti’.
  
! ‘D_Version2’
       This version defined when this is a D version 2 compiler.
  
! ‘unittest’
!      This version is defined when the ‘unittest’ code is being compiled
!      in.  Enabled by ‘-funittest’.
  
  
  File: gdc.info,  Node: Common Predefined Versions,  Next: Target Predefined Versions,  Prev: Standard Predefined Versions,  Up: Predefined Versions
*************** File: gdc.info,  Node: Common Predefined
*** 2350,2381 ****
  
  The common predefined macros are GNU D extensions.  They are available
  with the same meanings regardless of the machine or operating system on
! which you are using GNU D. Their names all start with 'GNU'.
  
! 'GNU'
       This version is defined by the GNU D compiler.  If all you need to
       know is whether or not your D program is being compiled by GDC, or
!      a non-GDC compiler, you can simply test 'version(GNU)'.
  
! 'GNU_DWARF2_Exceptions'
! 'GNU_SEH_Exceptions'
! 'GNU_SjLj_Exceptions'
       These versions reflect the mechanism that will be used for
!      exception handling by the target.  'GNU_DWARF2_Exceptions' is
       defined when the target uses DWARF 2 exceptions.
!      'GNU_SEH_Exceptions' is defined when the target uses SEH
!      exceptions.  'GNU_SjLj_Exceptions' is defined when the target uses
!      the 'setjmp'/'longjmp'-based exception handling scheme.
  
! 'GNU_EMUTLS'
       This version is defined if the target does not support thread-local
       storage, and an emulation layer is used instead.
  
! 'GNU_InlineAsm'
!      This version is defined when 'asm' statements use GNU D style
       syntax.  (*note Inline Assembly::)
  
! 'GNU_StackGrowsDown'
       This version is defined if pushing a word onto the stack moves the
       stack pointer to a smaller address, and is undefined otherwise.
  
--- 2350,2381 ----
  
  The common predefined macros are GNU D extensions.  They are available
  with the same meanings regardless of the machine or operating system on
! which you are using GNU D. Their names all start with ‘GNU’.
  
! ‘GNU’
       This version is defined by the GNU D compiler.  If all you need to
       know is whether or not your D program is being compiled by GDC, or
!      a non-GDC compiler, you can simply test ‘version(GNU)’.
  
! ‘GNU_DWARF2_Exceptions’
! ‘GNU_SEH_Exceptions’
! ‘GNU_SjLj_Exceptions’
       These versions reflect the mechanism that will be used for
!      exception handling by the target.  ‘GNU_DWARF2_Exceptions’ is
       defined when the target uses DWARF 2 exceptions.
!      ‘GNU_SEH_Exceptions’ is defined when the target uses SEH
!      exceptions.  ‘GNU_SjLj_Exceptions’ is defined when the target uses
!      the ‘setjmp’/‘longjmp’-based exception handling scheme.
  
! ‘GNU_EMUTLS’
       This version is defined if the target does not support thread-local
       storage, and an emulation layer is used instead.
  
! ‘GNU_InlineAsm’
!      This version is defined when ‘asm’ statements use GNU D style
       syntax.  (*note Inline Assembly::)
  
! ‘GNU_StackGrowsDown’
       This version is defined if pushing a word onto the stack moves the
       stack pointer to a smaller address, and is undefined otherwise.
  
*************** The D compiler normally predefines sever
*** 2389,2499 ****
  type of system and machine is in use.  They are obviously different on
  each target supported by GCC.
  
! 'AArch64'
       Version relating to the AArch64 family of processors.
  
! 'Android'
       Version relating to the Android platform.
  
! 'ARM'
! 'ARM_HardFloat'
! 'ARM_SoftFloat'
! 'ARM_SoftFP'
! 'ARM_Thumb'
       Versions relating to the ARM family of processors.
  
! 'Cygwin'
       Version relating to the Cygwin environment.
  
! 'darwin'
!      Deprecated; use 'OSX' instead.
  
! 'DragonFlyBSD'
       Versions relating to DragonFlyBSD systems.
  
! 'FreeBSD'
! 'FreeBSD_9'
! 'FreeBSD_10'
! 'FreeBSD_11'
! 'FreeBSD_...'
       Versions relating to FreeBSD systems.  The FreeBSD major version
       number is inferred from the target triplet.
  
! 'HPPA'
! 'HPPA64'
       Versions relating to the HPPA family of processors.
  
! 'Hurd'
       Version relating to GNU Hurd systems.
  
! 'linux'
       Version relating to Linux systems.
  
! 'MinGW'
       Version relating to the MinGW environment.
  
! 'MIPS32'
! 'MIPS64'
! 'MIPS_EABI'
! 'MIPS_HardFloat'
! 'MIPS_N32'
! 'MIPS_N64'
! 'MIPS_O32'
! 'MIPS_O64'
! 'MIPS_SoftFloat'
       Versions relating to the MIPS family of processors.
  
! 'NetBSD'
       Version relating to NetBSD systems.
  
! 'OpenBSD'
       Version relating to OpenBSD systems.
  
! 'OSX'
       Version relating to OSX systems.
  
! 'Posix'
       Version relating to POSIX systems (includes Linux, FreeBSD, OSX,
       Solaris, etc).
  
! 'PPC'
! 'PPC64'
! 'PPC_HardFloat'
! 'PPC_SoftFloat'
       Versions relating to the PowerPC family of processors.
  
! 'RISCV32'
! 'RISCV64'
       Versions relating to the RISC-V family of processors.
  
! 'S390'
! 'SystemZ'
       Versions relating to the S/390 and System Z family of processors.
  
! 'S390X'
!      Deprecated; use 'SystemZ' instead.
  
! 'Solaris'
       Versions relating to Solaris systems.
  
! 'SPARC'
! 'SPARC64'
! 'SPARC_HardFloat'
! 'SPARC_SoftFloat'
! 'SPARC_V8Plus'
       Versions relating to the SPARC family of processors.
  
! 'Thumb'
!      Deprecated; use 'ARM_Thumb' instead.
  
! 'D_X32'
! 'X86'
! 'X86_64'
       Versions relating to the x86-32 and x86-64 family of processors.
  
! 'Windows'
! 'Win32'
! 'Win64'
       Versions relating to Microsoft Windows systems.
  
  
--- 2389,2499 ----
  type of system and machine is in use.  They are obviously different on
  each target supported by GCC.
  
! ‘AArch64’
       Version relating to the AArch64 family of processors.
  
! ‘Android’
       Version relating to the Android platform.
  
! ‘ARM’
! ‘ARM_HardFloat’
! ‘ARM_SoftFloat’
! ‘ARM_SoftFP’
! ‘ARM_Thumb’
       Versions relating to the ARM family of processors.
  
! ‘Cygwin’
       Version relating to the Cygwin environment.
  
! ‘darwin’
!      Deprecated; use ‘OSX’ instead.
  
! ‘DragonFlyBSD’
       Versions relating to DragonFlyBSD systems.
  
! ‘FreeBSD’
! ‘FreeBSD_9’
! ‘FreeBSD_10’
! ‘FreeBSD_11’
! ‘FreeBSD_...’
       Versions relating to FreeBSD systems.  The FreeBSD major version
       number is inferred from the target triplet.
  
! ‘HPPA’
! ‘HPPA64’
       Versions relating to the HPPA family of processors.
  
! ‘Hurd’
       Version relating to GNU Hurd systems.
  
! ‘linux’
       Version relating to Linux systems.
  
! ‘MinGW’
       Version relating to the MinGW environment.
  
! ‘MIPS32’
! ‘MIPS64’
! ‘MIPS_EABI’
! ‘MIPS_HardFloat’
! ‘MIPS_N32’
! ‘MIPS_N64’
! ‘MIPS_O32’
! ‘MIPS_O64’
! ‘MIPS_SoftFloat’
       Versions relating to the MIPS family of processors.
  
! ‘NetBSD’
       Version relating to NetBSD systems.
  
! ‘OpenBSD’
       Version relating to OpenBSD systems.
  
! ‘OSX’
       Version relating to OSX systems.
  
! ‘Posix’
       Version relating to POSIX systems (includes Linux, FreeBSD, OSX,
       Solaris, etc).
  
! ‘PPC’
! ‘PPC64’
! ‘PPC_HardFloat’
! ‘PPC_SoftFloat’
       Versions relating to the PowerPC family of processors.
  
! ‘RISCV32’
! ‘RISCV64’
       Versions relating to the RISC-V family of processors.
  
! ‘S390’
! ‘SystemZ’
       Versions relating to the S/390 and System Z family of processors.
  
! ‘S390X’
!      Deprecated; use ‘SystemZ’ instead.
  
! ‘Solaris’
       Versions relating to Solaris systems.
  
! ‘SPARC’
! ‘SPARC64’
! ‘SPARC_HardFloat’
! ‘SPARC_SoftFloat’
! ‘SPARC_V8Plus’
       Versions relating to the SPARC family of processors.
  
! ‘Thumb’
!      Deprecated; use ‘ARM_Thumb’ instead.
  
! ‘D_X32’
! ‘X86’
! ‘X86_64’
       Versions relating to the x86-32 and x86-64 family of processors.
  
! ‘Windows’
! ‘Win32’
! ‘Win64’
       Versions relating to Microsoft Windows systems.
  
  
*************** File: gdc.info,  Node: Special Enums,  N
*** 2502,2515 ****
  2.8 Special Enums
  =================
  
! Special 'enum' names are used to represent types that do not have an
  equivalent basic D type.  For example, C++ types used by the C++ name
  mangler.
  
     Special enums are declared opaque, with a base type explicitly set.
  Unlike regular opaque enums, special enums can be used as any other
! value type.  They have a default '.init' value, as well as other enum
! properties available ('.min', '.max').  Special enums can be declared in
  any module, and will be recognized by the compiler.
  
       import gcc.builtins;
--- 2502,2515 ----
  2.8 Special Enums
  =================
  
! Special ‘enum’ names are used to represent types that do not have an
  equivalent basic D type.  For example, C++ types used by the C++ name
  mangler.
  
     Special enums are declared opaque, with a base type explicitly set.
  Unlike regular opaque enums, special enums can be used as any other
! value type.  They have a default ‘.init’ value, as well as other enum
! properties available (‘.min’, ‘.max’).  Special enums can be declared in
  any module, and will be recognized by the compiler.
  
       import gcc.builtins;
*************** any module, and will be recognized by th
*** 2518,2551 ****
  
  The following identifiers are recognized by GNU D.
  
! '__c_complex_double'
!      C '_Complex double' type.
! '__c_complex_float'
!      C '_Complex float' type.
! '__c_complex_real'
!      C '_Complex long double' type.
! '__c_long'
!      C++ 'long' type.
! '__c_longlong'
!      C++ 'long long' type.
! '__c_long_double'
!      C 'long double' type.
! '__c_ulong'
!      C++ 'unsigned long' type.
! '__c_ulonglong'
!      C++ 'unsigned long long' type.
! '__c_wchar_t'
!      C++ 'wchar_t' type.
  
!    The 'core.stdc.config' module declares the following shorthand alias
! types for convenience: 'c_complex_double', 'c_complex_float',
! 'c_complex_real', 'cpp_long', 'cpp_longlong', 'c_long_double',
! 'cpp_ulong', 'cpp_ulonglong'.
  
     It may cause undefined behavior at runtime if a special enum is
  declared with a base type that has a different size to the target C/C++
  type it is representing.  The GNU D compiler will catch such
! declarations and emit a warning when the '-Wmismatched-special-enum'
  option is seen on the command-line.
  
  
--- 2518,2551 ----
  
  The following identifiers are recognized by GNU D.
  
! ‘__c_complex_double’
!      C ‘_Complex double’ type.
! ‘__c_complex_float’
!      C ‘_Complex float’ type.
! ‘__c_complex_real’
!      C ‘_Complex long double’ type.
! ‘__c_long’
!      C++ ‘long’ type.
! ‘__c_longlong’
!      C++ ‘long long’ type.
! ‘__c_long_double’
!      C ‘long double’ type.
! ‘__c_ulong’
!      C++ ‘unsigned long’ type.
! ‘__c_ulonglong’
!      C++ ‘unsigned long long’ type.
! ‘__c_wchar_t’
!      C++ ‘wchar_t’ type.
  
!    The ‘core.stdc.config’ module declares the following shorthand alias
! types for convenience: ‘c_complex_double’, ‘c_complex_float’,
! ‘c_complex_real’, ‘cpp_long’, ‘cpp_longlong’, ‘c_long_double’,
! ‘cpp_ulong’, ‘cpp_ulonglong’.
  
     It may cause undefined behavior at runtime if a special enum is
  declared with a base type that has a different size to the target C/C++
  type it is representing.  The GNU D compiler will catch such
! declarations and emit a warning when the ‘-Wmismatched-special-enum’
  option is seen on the command-line.
  
  
*************** Traits are extensions to the D programmi
*** 2558,2564 ****
  at compile time, to get at information internal to the compiler.  This
  is also known as compile time reflection.
  
!    GNU D implements a '__traits(getTargetInfo)' trait that receives a
  string key as its argument.  The result is an expression describing the
  requested target information.
  
--- 2558,2564 ----
  at compile time, to get at information internal to the compiler.  This
  is also known as compile time reflection.
  
!    GNU D implements a ‘__traits(getTargetInfo)’ trait that receives a
  string key as its argument.  The result is an expression describing the
  requested target information.
  
*************** hosted at >', the modulus
! operator '%', logical operations '&, |, ^', and the complement operator
! 'unary~' on integer-type vectors.
  
     For convenience, it is allowed to use a binary vector operation where
  one operand is a scalar.  In that case the compiler transforms the
--- 2638,2646 ----
  
       c = a + b;
  
! It is also possible to use shifting operators ‘<<’, ‘>>’, the modulus
! operator ‘%’, logical operations ‘&, |, ^’, and the complement operator
! ‘unary~’ on integer-type vectors.
  
     For convenience, it is allowed to use a binary vector operation where
  one operand is a scalar.  In that case the compiler transforms the
*************** code.
*** 2659,2666 ****
  
       a = l + a;    // Error, incompatible types.
  
! Vector comparison is supported with standard comparison operators: '==,
! !=, <, <=, >, >='.  Comparison operands can be vector expressions of
  integer-type or real-type.  Comparison between integer-type vectors and
  real-type vectors are not supported.  The result of the comparison is a
  vector of the same width and number of elements as the comparison
--- 2659,2666 ----
  
       a = l + a;    // Error, incompatible types.
  
! Vector comparison is supported with standard comparison operators: ‘==,
! !=, <, <=, >, >=’.  Comparison operands can be vector expressions of
  integer-type or real-type.  Comparison between integer-type vectors and
  real-type vectors are not supported.  The result of the comparison is a
  vector of the same width and number of elements as the comparison
*************** File: gdc.info,  Node: Vector Intrinsics
*** 2686,2692 ****
  ======================
  
  The following functions are a collection of vector operation intrinsics,
! available by importing the 'gcc.simd' module.
  
   -- Template: void gcc.simd.prefetch (bool RW, ubyte LOCALITY)
            (const(void)* ADDR)
--- 2686,2692 ----
  ======================
  
  The following functions are a collection of vector operation intrinsics,
! available by importing the ‘gcc.simd’ module.
  
   -- Template: void gcc.simd.prefetch (bool RW, ubyte LOCALITY)
            (const(void)* ADDR)
*************** available by importing the 'gcc.simd' mo
*** 2699,2705 ****
       compile-time constant integer between zero and three.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_prefetch'.
  
            for (i = 0; i < n; i++)
            {
--- 2699,2705 ----
       compile-time constant integer between zero and three.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_prefetch’.
  
            for (i = 0; i < n; i++)
            {
*************** available by importing the 'gcc.simd' mo
*** 2737,2743 ****
       the output vector.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_shuffle'.
  
            int4 a = [1, 2, 3, 4];
            int4 b = [5, 6, 7, 8];
--- 2737,2743 ----
       the output vector.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_shuffle’.
  
            int4 a = [1, 2, 3, 4];
            int4 b = [5, 6, 7, 8];
*************** available by importing the 'gcc.simd' mo
*** 2757,2763 ****
       length as the MASK.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_shufflevector'.
  
            int8 a = [1, -2, 3, -4, 5, -6, 7, -8];
            int4 b = shufflevector(a, a, 0, 2, 4, 6);   // b is [1,3,5,7]
--- 2757,2763 ----
       length as the MASK.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_shufflevector’.
  
            int8 a = [1, -2, 3, -4, 5, -6, 7, -8];
            int4 b = shufflevector(a, a, 0, 2, 4, 6);   // b is [1,3,5,7]
*************** available by importing the 'gcc.simd' mo
*** 2784,2790 ****
       every element cast to the element type of the return type.
  
       This intrinsic is the same as the GCC built-in function
!      '__builtin_convertvector'.
  
            int4 a = [1, -2, 3, -4];
            float4 b = [1.5, -2.5, 3, 7];
--- 2784,2790 ----
       every element cast to the element type of the return type.
  
       This intrinsic is the same as the GCC built-in function
!      ‘__builtin_convertvector’.
  
            int4 a = [1, -2, 3, -4];
            float4 b = [1.5, -2.5, 3, 7];
*************** Some parts of the D specification are ha
*** 2816,2829 ****
  with GCC, they should be listed here.
  
  Bit Operation Intrinsics
!      The Digital Mars D compiler implements the 'core.bitop' intrinsics
!      'inp', 'inpw', 'inpl', 'outp', 'outpw', and 'outpl'.  These are not
       recognized by GNU D. On most targets, equivalent intrinsics that
!      have the same effect would be 'core.volatile.loadVolatile' and
!      'core.volatile.storeVolatile' respectively (*note Volatile
       Intrinsics::).
  
!      On x86 targets, if an 'in' or 'out' instruction is specifically
       required, that can be achieved using assembler statements instead.
            ubyte inp(uint port)
            {
--- 2816,2829 ----
  with GCC, they should be listed here.
  
  Bit Operation Intrinsics
!      The Digital Mars D compiler implements the ‘core.bitop’ intrinsics
!      ‘inp’, ‘inpw’, ‘inpl’, ‘outp’, ‘outpw’, and ‘outpl’.  These are not
       recognized by GNU D. On most targets, equivalent intrinsics that
!      have the same effect would be ‘core.volatile.loadVolatile’ and
!      ‘core.volatile.storeVolatile’ respectively (*note Volatile
       Intrinsics::).
  
!      On x86 targets, if an ‘in’ or ‘out’ instruction is specifically
       required, that can be achieved using assembler statements instead.
            ubyte inp(uint port)
            {
*************** Bit Operation Intrinsics
*** 2840,2866 ****
  Floating-Point Intermediate Values
  
       GNU D uses a software compile-time floating-point type that assists
!      in cross-compilation and support for arbitrary target 'real'
       precisions wider than 80 bits.  Because of this, the result of
       floating-point CTFE operations may have different results in GNU D
       compared with other D compilers that use the host's native
       floating-point type for storage and CTFE. In particular, GNU D
       won't overflow or underflow when a target real features a higher
!      precision than the host.  Differences also extend to '.stringof'
       representations of intermediate values due to formatting
!      differences with 'sprintf("%Lg")'.
            version(GNU)
                assert((25.5).stringof ~ (3.01).stringof == "2.55e+13.01e+0");
            else
                assert((25.5).stringof ~ (3.01).stringof == "25.53.01");
  
  Function Calling Conventions
!      GNU D does not implement the 'extern(D)' calling convention for x86
       as described in the D specification hosted at
       .
  
!      Instead, there is no distinction between 'extern(C)' and
!      'extern(D)' other than name mangling.
  
  ImportC Limitations
       GNU D does not run the preprocessor automatically for any ImportC
--- 2840,2866 ----
  Floating-Point Intermediate Values
  
       GNU D uses a software compile-time floating-point type that assists
!      in cross-compilation and support for arbitrary target ‘real’
       precisions wider than 80 bits.  Because of this, the result of
       floating-point CTFE operations may have different results in GNU D
       compared with other D compilers that use the host's native
       floating-point type for storage and CTFE. In particular, GNU D
       won't overflow or underflow when a target real features a higher
!      precision than the host.  Differences also extend to ‘.stringof’
       representations of intermediate values due to formatting
!      differences with ‘sprintf("%Lg")’.
            version(GNU)
                assert((25.5).stringof ~ (3.01).stringof == "2.55e+13.01e+0");
            else
                assert((25.5).stringof ~ (3.01).stringof == "25.53.01");
  
  Function Calling Conventions
!      GNU D does not implement the ‘extern(D)’ calling convention for x86
       as described in the D specification hosted at
       .
  
!      Instead, there is no distinction between ‘extern(C)’ and
!      ‘extern(D)’ other than name mangling.
  
  ImportC Limitations
       GNU D does not run the preprocessor automatically for any ImportC
*************** Inline Assembler
*** 2871,2877 ****
       GNU D does not implement the D inline assembler for x86 and x86_64
       as described in the D specification hosted at
       .  Nor does GNU D predefine the
!      'D_InlineAsm_X86' and 'D_InlineAsm_X86_64' version identifiers to
       indicate support.
  
       The GNU D compiler uses an alternative, GCC-based syntax for inline
--- 2871,2877 ----
       GNU D does not implement the D inline assembler for x86 and x86_64
       as described in the D specification hosted at
       .  Nor does GNU D predefine the
!      ‘D_InlineAsm_X86’ and ‘D_InlineAsm_X86_64’ version identifiers to
       indicate support.
  
       The GNU D compiler uses an alternative, GCC-based syntax for inline
*************** Inline Assembler
*** 2880,2904 ****
  Interfacing to Objective-C
       GNU D does not support interfacing with Objective-C, nor its
       protocols, classes, subclasses, instance variables, instance
!      methods and class methods.  The 'extern(Objective-C)' linkage is
!      ignored, as are the '@optional' and '@selector' attributes.  The
!      'D_ObjectiveC' version identifier is not predefined for
       compilations.
  
  Pragma Directives
       Pragmas that are designed to embed information into object files or
       otherwise pass options to the linker are not supported by GNU D.
!      These include 'pragma(lib)', 'pragma(linkerDirective)', and
!      'pragma(startaddress)'.
  
  SIMD Intrinsics
!      The Digital Mars D compiler implements the 'core.simd' intrinsics
!      '__simd', '__simd_ib', '__simd_sto'.  These are not recognized by
!      GNU D, nor does GNU D predefine the 'D_SIMD' version identifier to
       indicate support.
  
       On x86 targets, all intrinsics are available as functions in the
!      'gcc.builtins' module, and have predictable equivalents.
            version (DigitalMars)
            {
                __simd(XMM.PSLLW, op1, op2);
--- 2880,2904 ----
  Interfacing to Objective-C
       GNU D does not support interfacing with Objective-C, nor its
       protocols, classes, subclasses, instance variables, instance
!      methods and class methods.  The ‘extern(Objective-C)’ linkage is
!      ignored, as are the ‘@optional’ and ‘@selector’ attributes.  The
!      ‘D_ObjectiveC’ version identifier is not predefined for
       compilations.
  
  Pragma Directives
       Pragmas that are designed to embed information into object files or
       otherwise pass options to the linker are not supported by GNU D.
!      These include ‘pragma(lib)’, ‘pragma(linkerDirective)’, and
!      ‘pragma(startaddress)’.
  
  SIMD Intrinsics
!      The Digital Mars D compiler implements the ‘core.simd’ intrinsics
!      ‘__simd’, ‘__simd_ib’, ‘__simd_sto’.  These are not recognized by
!      GNU D, nor does GNU D predefine the ‘D_SIMD’ version identifier to
       indicate support.
  
       On x86 targets, all intrinsics are available as functions in the
!      ‘gcc.builtins’ module, and have predictable equivalents.
            version (DigitalMars)
            {
                __simd(XMM.PSLLW, op1, op2);
*************** SIMD Intrinsics
*** 2912,2918 ****
  
  TypeInfo-based va_arg
       The Digital Mars D compiler implements a version of
!      'core.vararg.va_arg' that accepts a run-time 'TypeInfo' argument
       for use when the static type is not known.  This function is not
       implemented by GNU D. It is more portable to use variadic template
       functions instead.
--- 2912,2918 ----
  
  TypeInfo-based va_arg
       The Digital Mars D compiler implements a version of
!      ‘core.vararg.va_arg’ that accepts a run-time ‘TypeInfo’ argument
       for use when the static type is not known.  This function is not
       implemented by GNU D. It is more portable to use variadic template
       functions instead.
*************** GNU General Public License
*** 2925,2931 ****
  
                          Version 3, 29 June 2007
  
!      Copyright (C) 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
--- 2925,2931 ----
  
                          Version 3, 29 June 2007
  
!      Copyright © 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
*************** mail.
*** 3612,3622 ****
  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".
--- 3612,3622 ----
  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".
*************** GNU Free Documentation License
*** 3641,3647 ****
  
                       Version 1.3, 3 November 2008
  
!      Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
--- 3641,3647 ----
  
                       Version 1.3, 3 November 2008
  
!      Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
*************** GNU Free Documentation License
*** 3650,3656 ****
    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
--- 3650,3656 ----
    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
*************** File: gdc.info,  Node: Option Index,  Ne
*** 4121,4129 ****
  Option Index
  ************
  
! 'gdc''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.
  
--- 4121,4129 ----
  Option Index
  ************
  
! ‘gdc’'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.
  
*************** Keyword Index
*** 4242,4250 ****
  [index]
  * Menu:
  
- * allocSize function attribute:          Other Attributes.    (line   9)
  * alloc_size function attribute:         Common Attributes.   (line   8)
  * alloc_size variable attribute:         Common Attributes.   (line   8)
  * always_inline function attribute:      Common Attributes.   (line  30)
  * assembly language in D:                Inline Assembly.     (line   6)
  * assumeUsed function attribute:         Other Attributes.    (line  17)
--- 4242,4250 ----
  [index]
  * Menu:
  
  * alloc_size function attribute:         Common Attributes.   (line   8)
  * alloc_size variable attribute:         Common Attributes.   (line   8)
+ * allocSize function attribute:          Other Attributes.    (line   9)
  * always_inline function attribute:      Common Attributes.   (line  30)
  * assembly language in D:                Inline Assembly.     (line   6)
  * assumeUsed function attribute:         Other Attributes.    (line  17)
*************** Keyword Index
*** 4410,4422 ****
  * messages, warning:                     Warnings.            (line   6)
  * missing features:                      Missing Features.    (line   6)
  * naked function attribute:              Other Attributes.    (line  38)
  * noclone function attribute:            Common Attributes.   (line  76)
  * noinline function attribute:           Common Attributes.   (line  85)
  * noipa function attribute:              Common Attributes.   (line  96)
  * noplt function attribute:              Common Attributes.   (line 114)
  * noSanitize function attribute:         Other Attributes.    (line  47)
- * no_icf function attribute:             Common Attributes.   (line  59)
- * no_sanitize function attribute:        Common Attributes.   (line  66)
  * optimize function attribute:           Common Attributes.   (line 127)
  * options, code generation:              Code Generation.     (line   6)
  * options, directory search:             Directory Options.   (line   6)
--- 4410,4422 ----
  * messages, warning:                     Warnings.            (line   6)
  * missing features:                      Missing Features.    (line   6)
  * naked function attribute:              Other Attributes.    (line  38)
+ * no_icf function attribute:             Common Attributes.   (line  59)
+ * no_sanitize function attribute:        Common Attributes.   (line  66)
  * noclone function attribute:            Common Attributes.   (line  76)
  * noinline function attribute:           Common Attributes.   (line  85)
  * noipa function attribute:              Common Attributes.   (line  96)
  * noplt function attribute:              Common Attributes.   (line 114)
  * noSanitize function attribute:         Other Attributes.    (line  47)
  * optimize function attribute:           Common Attributes.   (line 127)
  * options, code generation:              Code Generation.     (line   6)
  * options, directory search:             Directory Options.   (line   6)
*************** Keyword Index
*** 4483,4491 ****
  * suppressing warnings:                  Warnings.            (line   6)
  * symver function attribute:             Common Attributes.   (line 211)
  * target function attribute:             Common Attributes.   (line 227)
  * target-specific predefined versions:   Target Predefined Versions.
                                                                (line   6)
- * target_clones function attribute:      Common Attributes.   (line 245)
  * traits:                                Traits.              (line   6)
  * used function attribute:               Common Attributes.   (line 259)
  * used variable attribute:               Common Attributes.   (line 259)
--- 4483,4491 ----
  * suppressing warnings:                  Warnings.            (line   6)
  * symver function attribute:             Common Attributes.   (line 211)
  * target function attribute:             Common Attributes.   (line 227)
+ * target_clones function attribute:      Common Attributes.   (line 245)
  * target-specific predefined versions:   Target Predefined Versions.
                                                                (line   6)
  * traits:                                Traits.              (line   6)
  * used function attribute:               Common Attributes.   (line 259)
  * used variable attribute:               Common Attributes.   (line 259)
*************** Keyword Index
*** 4500,4547 ****
  
  
  Tag Table:
! Node: Top1075
! Node: Invoking gdc1933
! Node: Input and Output files2792
! Node: Runtime Options4140
! Node: Directory Options12735
! Node: Code Generation15158
! Node: Warnings19092
! Node: Linking22737
! Node: Developer Options24410
! Node: D Implementation25160
! Node: Attributes26904
! Node: Attribute Syntax27902
! Node: Common Attributes29506
! Node: Other Attributes41890
! Node: Target Attributes44054
! Node: Builtin Functions45459
! Node: Builtin Types46026
! Node: Query Builtins47209
! Node: Other Builtins48439
! Node: ImportC54566
! Node: Inline Assembly56657
! Node: Intrinsics58805
! Node: Bit Operation Intrinsics59618
! Node: Integer Overflow Intrinsics64432
! Node: Math Intrinsics67109
! Node: Variadic Intrinsics70293
! Node: Volatile Intrinsics71857
! Node: CTFE Intrinsics74268
! Node: Predefined Pragmas80124
! Node: Predefined Versions84134
! Node: Standard Predefined Versions84777
! Node: Common Predefined Versions88699
! Node: Target Predefined Versions90210
! Node: Special Enums92558
! Node: Traits94276
! Node: Vector Extensions95532
! Node: Vector Intrinsics99160
! Node: Missing Features103799
! Node: Copying108399
! Node: GNU Free Documentation License145949
! Node: Option Index171078
! Node: Keyword Index178983
  
  End Tag Table
  
--- 4500,4547 ----
  
  
  Tag Table:
! Node: Top1073
! Node: Invoking gdc1939
! Node: Input and Output files2810
! Node: Runtime Options4210
! Node: Directory Options13265
! Node: Code Generation15748
! Node: Warnings19902
! Node: Linking23703
! Node: Developer Options25448
! Node: D Implementation26234
! Node: Attributes27986
! Node: Attribute Syntax29000
! Node: Common Attributes30620
! Node: Other Attributes43332
! Node: Target Attributes45600
! Node: Builtin Functions47013
! Node: Builtin Types47588
! Node: Query Builtins48855
! Node: Other Builtins50093
! Node: ImportC57712
! Node: Inline Assembly59835
! Node: Intrinsics62023
! Node: Bit Operation Intrinsics62836
! Node: Integer Overflow Intrinsics67690
! Node: Math Intrinsics70395
! Node: Variadic Intrinsics73635
! Node: Volatile Intrinsics75231
! Node: CTFE Intrinsics77650
! Node: Predefined Pragmas83590
! Node: Predefined Versions87756
! Node: Standard Predefined Versions88407
! Node: Common Predefined Versions92577
! Node: Target Predefined Versions94148
! Node: Special Enums96728
! Node: Traits98574
! Node: Vector Extensions99870
! Node: Vector Intrinsics103738
! Node: Missing Features108397
! Node: Copying113133
! Node: GNU Free Documentation License150698
! Node: Option Index175830
! Node: Keyword Index183755
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/doc/gfdl.7 gcc-13.5.0-RC-20260904/gcc/doc/gfdl.7
*** gcc-13.4.0/gcc/doc/gfdl.7	Thu Jun  5 16:06:29 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gfdl.7	Fri Sep  4 07:36:30 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,153 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GFDL 7"
! .TH GFDL 7 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gfdl \- GNU Free Documentation License
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
  \&\f(CW@comment\fR For some cases, this default \f(CW@node\fR/@unnumbered is not applicable and
  \&\f(CW@comment\fR causes warnings.  In those cases, the including file can set
! \&\f(CW@comment\fR nodefaultgnufreedocumentationlicensenode and provide it's own version.
  \&\f(CW@comment\fR F.i., when this file is included in an \f(CW@raisesections\fR context, the
  \&\f(CW@comment\fR including file can use an \f(CW@unnumberedsec\fR.
! .SS "\s-1GNU\s0 Free Documentation License"
  .IX Subsection "GNU Free Documentation License"
  .SS "Version 1.3, 3 November 2008"
  .IX Subsection "Version 1.3, 3 November 2008"
--- 53,78 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GFDL 7"
! .TH GFDL 7 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gfdl \- GNU Free Documentation License
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
  \&\f(CW@comment\fR For some cases, this default \f(CW@node\fR/@unnumbered is not applicable and
  \&\f(CW@comment\fR causes warnings.  In those cases, the including file can set
! \&\f(CW@comment\fR nodefaultgnufreedocumentationlicensenode and provide it\*(Aqs own version.
  \&\f(CW@comment\fR F.i., when this file is included in an \f(CW@raisesections\fR context, the
  \&\f(CW@comment\fR including file can use an \f(CW@unnumberedsec\fR.
! .SS "GNU Free Documentation License"
  .IX Subsection "GNU Free Documentation License"
  .SS "Version 1.3, 3 November 2008"
  .IX Subsection "Version 1.3, 3 November 2008"
*************** gfdl \- GNU Free Documentation License
*** 158,166 ****
  \&        Everyone is permitted to copy and distribute verbatim copies
  \&        of this license document, but changing it is not allowed.
  .Ve
! .IP "0." 4
  .IX Item "0."
! \&\s-1PREAMBLE\s0
  .Sp
  The purpose of this License is to make a manual, textbook, or other
  functional and useful document \fIfree\fR in the sense of freedom: to
--- 83,91 ----
  \&        Everyone is permitted to copy and distribute verbatim copies
  \&        of this license document, but changing it is not allowed.
  .Ve
! .IP 0. 4
  .IX Item "0."
! PREAMBLE
  .Sp
  The purpose of this License is to make a manual, textbook, or other
  functional and useful document \fIfree\fR in the sense of freedom: to
*************** Secondarily, this License preserves for
*** 170,178 ****
  to get credit for their work, while not being considered responsible
  for modifications made by others.
  .Sp
! This License is a kind of \*(L"copyleft\*(R", which means that derivative
  works of the document must themselves be free in the same sense.  It
! complements the \s-1GNU\s0 General Public License, which is a copyleft
  license designed for free software.
  .Sp
  We have designed this License in order to use it for manuals for free
--- 95,103 ----
  to get credit for their work, while not being considered responsible
  for modifications made by others.
  .Sp
! 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.
  .Sp
  We have designed this License in order to use it for manuals for free
*************** software does.  But this License is not
*** 182,208 ****
  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.
! .IP "1." 4
  .IX Item "1."
! \&\s-1APPLICABILITY AND DEFINITIONS\s0
  .Sp
  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 \*(L"Document\*(R", below,
  refers to any such manual or work.  Any member of the public is a
! licensee, and is addressed as \*(L"you\*(R".  You accept the license if you
  copy, modify or distribute the work in a way requiring permission
  under copyright law.
  .Sp
! A \*(L"Modified Version\*(R" 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.
  .Sp
! A \*(L"Secondary Section\*(R" 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
--- 107,133 ----
  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.
! .IP 1. 4
  .IX Item "1."
! APPLICABILITY AND DEFINITIONS
  .Sp
  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.
  .Sp
! 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.
  .Sp
! 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\*(Aqs 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
*************** connection with the subject or with rela
*** 211,217 ****
  commercial, philosophical, ethical or political position regarding
  them.
  .Sp
! The \*(L"Invariant Sections\*(R" 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
--- 136,142 ----
  commercial, philosophical, ethical or political position regarding
  them.
  .Sp
! 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.
*** 219,230 ****
  Invariant Sections.  If the Document does not identify any Invariant
  Sections then there are none.
  .Sp
! The \*(L"Cover Texts\*(R" 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.
  .Sp
! A \*(L"Transparent\*(R" 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
--- 144,155 ----
  Invariant Sections.  If the Document does not identify any Invariant
  Sections then there are none.
  .Sp
! 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.
  .Sp
! 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
*************** to text formatters.  A copy made in an o
*** 235,272 ****
  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 \*(L"Transparent\*(R" is called \*(L"Opaque\*(R".
  .Sp
  Examples of suitable formats for Transparent copies include plain
! \&\s-1ASCII\s0 without markup, Texinfo input format, LaTeX input
! format, \s-1SGML\s0 or \s-1XML\s0 using a publicly available
! \&\s-1DTD,\s0 and standard-conforming simple \s-1HTML,\s0
! PostScript or \s-1PDF\s0 designed for human modification.  Examples
! of transparent image formats include \s-1PNG, XCF\s0 and
! \&\s-1JPG.\s0  Opaque formats include proprietary formats that can be
! read and edited only by proprietary word processors, \s-1SGML\s0 or
! \&\s-1XML\s0 for which the \s-1DTD\s0 and/or processing tools are
! not generally available, and the machine-generated \s-1HTML,\s0
! PostScript or \s-1PDF\s0 produced by some word processors for
  output purposes only.
  .Sp
! The \*(L"Title Page\*(R" 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, \*(L"Title Page\*(R" means
! the text near the most prominent appearance of the work's title,
  preceding the beginning of the body of the text.
  .Sp
! The \*(L"publisher\*(R" means any person or entity that distributes copies
  of the Document to the public.
  .Sp
! A section \*(L"Entitled \s-1XYZ\*(R"\s0 means a named subunit of the Document whose
! title either is precisely \s-1XYZ\s0 or contains \s-1XYZ\s0 in parentheses following
! text that translates \s-1XYZ\s0 in another language.  (Here \s-1XYZ\s0 stands for a
! specific section name mentioned below, such as \*(L"Acknowledgements\*(R",
! \&\*(L"Dedications\*(R", \*(L"Endorsements\*(R", or \*(L"History\*(R".)  To \*(L"Preserve the Title\*(R"
  of such a section when you modify the Document means that it remains a
! section \*(L"Entitled \s-1XYZ\*(R"\s0 according to this definition.
  .Sp
  The Document may include Warranty Disclaimers next to the notice which
  states that this License applies to the Document.  These Warranty
--- 160,197 ----
  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".
  .Sp
  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.
  .Sp
! 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\*(Aqs title,
  preceding the beginning of the body of the text.
  .Sp
! The "publisher" means any person or entity that distributes copies
  of the Document to the public.
  .Sp
! 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.
  .Sp
  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 include
*** 274,282 ****
  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.
! .IP "2." 4
  .IX Item "2."
! \&\s-1VERBATIM COPYING\s0
  .Sp
  You may copy and distribute the Document in any medium, either
  commercially or noncommercially, provided that this License, the
--- 199,207 ----
  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.
! .IP 2. 4
  .IX Item "2."
! VERBATIM COPYING
  .Sp
  You may copy and distribute the Document in any medium, either
  commercially or noncommercially, provided that this License, the
*************** number of copies you must also follow th
*** 290,304 ****
  .Sp
  You may also lend copies, under the same conditions stated above, and
  you may publicly display copies.
! .IP "3." 4
  .IX Item "3."
! \&\s-1COPYING IN QUANTITY\s0
  .Sp
  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
--- 215,229 ----
  .Sp
  You may also lend copies, under the same conditions stated above, and
  you may publicly display copies.
! .IP 3. 4
  .IX Item "3."
! COPYING IN QUANTITY
  .Sp
  If you publish printed copies (or copies in media that commonly have
  printed covers) of the Document, numbering more than 100, and the
! Document\*(Aqs 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
*************** reasonably) on the actual cover, and con
*** 313,322 ****
  pages.
  .Sp
  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
--- 238,247 ----
  pages.
  .Sp
  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
*************** edition to the public.
*** 328,336 ****
  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.
! .IP "4." 4
  .IX Item "4."
! \&\s-1MODIFICATIONS\s0
  .Sp
  You may copy and distribute a Modified Version of the Document under
  the conditions of sections 2 and 3 above, provided that you release
--- 253,261 ----
  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.
! .IP 4. 4
  .IX Item "4."
! MODIFICATIONS
  .Sp
  You may copy and distribute a Modified Version of the Document under
  the conditions of sections 2 and 3 above, provided that you release
*************** Version filling the role of the Document
*** 339,441 ****
  and modification of the Modified Version to whoever possesses a copy
  of it.  In addition, you must do these things in the Modified Version:
  .RS 4
! .IP "A." 4
  .IX Item "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.
! .IP "B." 4
  .IX Item "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.
! .IP "C." 4
  .IX Item "C."
  State on the Title page the name of the publisher of the
  Modified Version, as the publisher.
! .IP "D." 4
  .IX Item "D."
  Preserve all the copyright notices of the Document.
! .IP "E." 4
  .IX Item "E."
  Add an appropriate copyright notice for your modifications
  adjacent to the other copyright notices.
! .IP "F." 4
  .IX Item "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.
! .IP "G." 4
  .IX Item "G."
  Preserve in that license notice the full lists of Invariant Sections
! and required Cover Texts given in the Document's license notice.
! .IP "H." 4
  .IX Item "H."
  Include an unaltered copy of this License.
! .IP "I." 4
  .IX Item "I."
! Preserve the section Entitled \*(L"History\*(R", 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 \*(L"History\*(R" 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.
! .IP "J." 4
  .IX Item "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 \*(L"History\*(R" 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.
! .IP "K." 4
  .IX Item "K."
! For any section Entitled \*(L"Acknowledgements\*(R" or \*(L"Dedications\*(R", 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.
! .IP "L." 4
  .IX Item "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.
! .IP "M." 4
  .IX Item "M."
! Delete any section Entitled \*(L"Endorsements\*(R".  Such a section
  may not be included in the Modified Version.
! .IP "N." 4
  .IX Item "N."
! Do not retitle any existing section to be Entitled \*(L"Endorsements\*(R" or
  to conflict in title with any Invariant Section.
! .IP "O." 4
  .IX Item "O."
  Preserve any Warranty Disclaimers.
  .RE
  .RS 4
  .Sp
! 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.
  .Sp
! You may add a section Entitled \*(L"Endorsements\*(R", 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.
  .Sp
! 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,
--- 264,366 ----
  and modification of the Modified Version to whoever possesses a copy
  of it.  In addition, you must do these things in the Modified Version:
  .RS 4
! .IP A. 4
  .IX Item "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.
! .IP B. 4
  .IX Item "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.
! .IP C. 4
  .IX Item "C."
  State on the Title page the name of the publisher of the
  Modified Version, as the publisher.
! .IP D. 4
  .IX Item "D."
  Preserve all the copyright notices of the Document.
! .IP E. 4
  .IX Item "E."
  Add an appropriate copyright notice for your modifications
  adjacent to the other copyright notices.
! .IP F. 4
  .IX Item "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.
! .IP G. 4
  .IX Item "G."
  Preserve in that license notice the full lists of Invariant Sections
! and required Cover Texts given in the Document\*(Aqs license notice.
! .IP H. 4
  .IX Item "H."
  Include an unaltered copy of this License.
! .IP I. 4
  .IX Item "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.
! .IP J. 4
  .IX Item "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.
! .IP K. 4
  .IX Item "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.
! .IP L. 4
  .IX Item "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.
! .IP M. 4
  .IX Item "M."
! Delete any section Entitled "Endorsements".  Such a section
  may not be included in the Modified Version.
! .IP N. 4
  .IX Item "N."
! Do not retitle any existing section to be Entitled "Endorsements" or
  to conflict in title with any Invariant Section.
! .IP O. 4
  .IX Item "O."
  Preserve any Warranty Disclaimers.
  .RE
  .RS 4
  .Sp
! 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\*(Aqs license notice.
  These titles must be distinct from any other section titles.
  .Sp
! 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.
  .Sp
! 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,
*************** The author(s) and publisher(s) of the Do
*** 446,454 ****
  give permission to use their names for publicity for or to assert or
  imply endorsement of any Modified Version.
  .RE
! .IP "5." 4
  .IX Item "5."
! \&\s-1COMBINING DOCUMENTS\s0
  .Sp
  You may combine the Document with other documents released under this
  License, under the terms defined in section 4 above for modified
--- 371,379 ----
  give permission to use their names for publicity for or to assert or
  imply endorsement of any Modified Version.
  .RE
! .IP 5. 4
  .IX Item "5."
! COMBINING DOCUMENTS
  .Sp
  You may combine the Document with other documents released under this
  License, under the terms defined in section 4 above for modified
*************** author or publisher of that section if k
*** 466,479 ****
  Make the same adjustment to the section titles in the list of
  Invariant Sections in the license notice of the combined work.
  .Sp
! In the combination, you must combine any sections Entitled \*(L"History\*(R"
  in the various original documents, forming one section Entitled
! \&\*(L"History\*(R"; likewise combine any sections Entitled \*(L"Acknowledgements\*(R",
! and any sections Entitled \*(L"Dedications\*(R".  You must delete all
! sections Entitled \*(L"Endorsements.\*(R"
! .IP "6." 4
  .IX Item "6."
! \&\s-1COLLECTIONS OF DOCUMENTS\s0
  .Sp
  You may make a collection consisting of the Document and other documents
  released under this License, and replace the individual copies of this
--- 391,404 ----
  Make the same adjustment to the section titles in the list of
  Invariant Sections in the license notice of the combined work.
  .Sp
! 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."
! .IP 6. 4
  .IX Item "6."
! COLLECTIONS OF DOCUMENTS
  .Sp
  You may make a collection consisting of the Document and other documents
  released under this License, and replace the individual copies of this
*************** You may extract a single document from s
*** 485,513 ****
  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.
! .IP "7." 4
  .IX Item "7."
! \&\s-1AGGREGATION WITH INDEPENDENT WORKS\s0
  .Sp
  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 \*(L"aggregate\*(R" 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.
  .Sp
  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.
! .IP "8." 4
  .IX Item "8."
! \&\s-1TRANSLATION\s0
  .Sp
  Translation is considered a kind of modification, so you may
  distribute translations of the Document under the terms of section 4.
--- 410,438 ----
  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.
! .IP 7. 4
  .IX Item "7."
! AGGREGATION WITH INDEPENDENT WORKS
  .Sp
  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\*(Aqs 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.
  .Sp
  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\*(Aqs 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.
! .IP 8. 4
  .IX Item "8."
! TRANSLATION
  .Sp
  Translation is considered a kind of modification, so you may
  distribute translations of the Document under the terms of section 4.
*************** of those notices and disclaimers.  In ca
*** 522,534 ****
  the translation and the original version of this License or a notice
  or disclaimer, the original version will prevail.
  .Sp
! If a section in the Document is Entitled \*(L"Acknowledgements\*(R",
! \&\*(L"Dedications\*(R", or \*(L"History\*(R", the requirement (section 4) to Preserve
  its Title (section 1) will typically require changing the actual
  title.
! .IP "9." 4
  .IX Item "9."
! \&\s-1TERMINATION\s0
  .Sp
  You may not copy, modify, sublicense, or distribute the Document
  except as expressly provided under this License.  Any attempt
--- 447,459 ----
  the translation and the original version of this License or a notice
  or disclaimer, the original version will prevail.
  .Sp
! 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.
! .IP 9. 4
  .IX Item "9."
! TERMINATION
  .Sp
  You may not copy, modify, sublicense, or distribute the Document
  except as expressly provided under this License.  Any attempt
*************** licenses of parties who have received co
*** 554,612 ****
  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.
! .IP "10." 4
  .IX Item "10."
! \&\s-1FUTURE REVISIONS OF THIS LICENSE\s0
  .Sp
  The Free Software Foundation may publish new, revised versions
! of the \s-1GNU\s0 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
  <\fBhttps://www.gnu.org/copyleft/\fR>.
  .Sp
  Each version of the License is given a distinguishing version number.
  If the Document specifies that a particular numbered version of this
! License \*(L"or any later version\*(R" 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.
! .IP "11." 4
  .IX Item "11."
! \&\s-1RELICENSING\s0
  .Sp
! \&\*(L"Massive Multiauthor Collaboration Site\*(R" (or \*(L"\s-1MMC\s0 Site\*(R") 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
! \&\*(L"Massive Multiauthor Collaboration\*(R" (or \*(L"\s-1MMC\*(R"\s0) contained in the
! site means any set of copyrightable works thus published on the \s-1MMC\s0
  site.
  .Sp
! \&\*(L"CC-BY-SA\*(R" 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.
  .Sp
! \&\*(L"Incorporate\*(R" means to publish or republish a Document, in whole or
  in part, as part of another Document.
  .Sp
! An \s-1MMC\s0 is \*(L"eligible for relicensing\*(R" if it is licensed under this
  License, and if all works that were first published under this License
! somewhere other than this \s-1MMC,\s0 and subsequently incorporated in whole
! or in part into the \s-1MMC,\s0 (1) had no cover texts or invariant sections,
  and (2) were thus incorporated prior to November 1, 2008.
  .Sp
! The operator of an \s-1MMC\s0 Site may republish an \s-1MMC\s0 contained in the site
! under CC-BY-SA on the same site at any time before August 1, 2009,
! provided the \s-1MMC\s0 is eligible for relicensing.
! .SS "\s-1ADDENDUM:\s0 How to use this License for your documents"
  .IX Subsection "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
--- 479,537 ----
  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.
! .IP 10. 4
  .IX Item "10."
! FUTURE REVISIONS OF THIS LICENSE
  .Sp
  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
  <\fBhttps://www.gnu.org/copyleft/\fR>.
  .Sp
  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\*(Aqs public statement of acceptance of a
  version permanently authorizes you to choose that version for the
  Document.
! .IP 11. 4
  .IX Item "11."
! RELICENSING
  .Sp
! "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.
  .Sp
! "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.
  .Sp
! "Incorporate" means to publish or republish a Document, in whole or
  in part, as part of another Document.
  .Sp
! 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.
  .Sp
! 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.
! .SS "ADDENDUM: How to use this License for your documents"
  .IX Subsection "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 pag
*** 622,629 ****
  \&          Free Documentation License".
  .Ve
  .PP
! If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
! replace the \*(L"with...Texts.\*(R" line with this:
  .PP
  .Vb 3
  \&            with the Invariant Sections being , with
--- 547,554 ----
  \&          Free Documentation License".
  .Ve
  .PP
! If you have Invariant Sections, Front\-Cover Texts and Back\-Cover Texts,
! replace the "with...Texts." line with this:
  .PP
  .Vb 3
  \&            with the Invariant Sections being , with
*************** situation.
*** 637,648 ****
  .PP
  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 \s-1GNU\s0 General Public License,
  to permit their use in free software.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBfsf\-funding\fR\|(7).
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
  <\fBhttps://www.fsf.org\fR>
--- 562,573 ----
  .PP
  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.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBfsf\-funding\fR\|(7).
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
  <\fBhttps://www.fsf.org\fR>
diff -Nrcpad gcc-13.4.0/gcc/doc/gfortran.1 gcc-13.5.0-RC-20260904/gcc/doc/gfortran.1
*** gcc-13.4.0/gcc/doc/gfortran.1	Thu Jun  5 16:30:32 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gfortran.1	Fri Sep  4 07:57:50 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,146 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GFORTRAN 1"
! .TH GFORTRAN 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gfortran \- GNU Fortran compiler
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
  gfortran [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR]
           [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
--- 53,71 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GFORTRAN 1"
! .TH GFORTRAN 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gfortran \- GNU Fortran compiler
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
  gfortran [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR]
           [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
*************** gfortran [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR]
*** 148,179 ****
           [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
           [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
           [\fB\-f\fR\fIoption\fR...]
!          [\fB\-m\fR\fImachine-option\fR...]
           [\fB\-o\fR \fIoutfile\fR] \fIinfile\fR...
  .PP
  Only the most useful options are listed here; see below for the
  remainder.
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
  The \fBgfortran\fR command supports all the options supported by the
! \&\fBgcc\fR command.  Only options specific to \s-1GNU\s0 Fortran are documented
  here.
  .PP
! All \s-1GCC\s0 and \s-1GNU\s0 Fortran options
  are accepted both by \fBgfortran\fR and by \fBgcc\fR
  (as well as any other drivers built at the same time,
  such as \fBg++\fR),
! since adding \s-1GNU\s0 Fortran to the \s-1GCC\s0 distribution
! enables acceptance of \s-1GNU\s0 Fortran options
  by all of the relevant drivers.
  .PP
  In some cases, options have positive and negative forms;
  the negative form of \fB\-ffoo\fR would be \fB\-fno\-foo\fR.
  This manual documents only one of these two forms, whichever
  one is not the default.
! .SH "OPTIONS"
  .IX Header "OPTIONS"
! Here is a summary of all the options specific to \s-1GNU\s0 Fortran, grouped
  by type.  Explanations are in the following sections.
  .IP "\fIFortran Language Options\fR" 4
  .IX Item "Fortran Language Options"
--- 73,104 ----
           [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
           [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
           [\fB\-f\fR\fIoption\fR...]
!          [\fB\-m\fR\fImachine\-option\fR...]
           [\fB\-o\fR \fIoutfile\fR] \fIinfile\fR...
  .PP
  Only the most useful options are listed here; see below for the
  remainder.
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
  The \fBgfortran\fR command supports all the options supported by the
! \&\fBgcc\fR command.  Only options specific to GNU Fortran are documented
  here.
  .PP
! All GCC and GNU Fortran options
  are accepted both by \fBgfortran\fR and by \fBgcc\fR
  (as well as any other drivers built at the same time,
  such as \fBg++\fR),
! since adding GNU Fortran to the GCC distribution
! enables acceptance of GNU Fortran options
  by all of the relevant drivers.
  .PP
  In some cases, options have positive and negative forms;
  the negative form of \fB\-ffoo\fR would be \fB\-fno\-foo\fR.
  This manual documents only one of these two forms, whichever
  one is not the default.
! .SH OPTIONS
  .IX Header "OPTIONS"
! Here is a summary of all the options specific to GNU Fortran, grouped
  by type.  Explanations are in the following sections.
  .IP "\fIFortran Language Options\fR" 4
  .IX Item "Fortran Language Options"
*************** by type.  Explanations are in the follow
*** 250,278 ****
  .IX Subsection "Options controlling Fortran dialect"
  The following options control the details of the Fortran dialect
  accepted by the compiler:
! .IP "\fB\-ffree\-form\fR" 4
  .IX Item "-ffree-form"
  .PD 0
! .IP "\fB\-ffixed\-form\fR" 4
  .IX Item "-ffixed-form"
  .PD
  Specify the layout used by the source file.  The free form layout
  was introduced in Fortran 90.  Fixed form was traditionally used in
  older Fortran programs.  When neither option is specified, the source
  form is determined by the file extension.
! .IP "\fB\-fall\-intrinsics\fR" 4
  .IX Item "-fall-intrinsics"
! This option causes all intrinsic procedures (including the GNU-specific
  extensions) to be accepted.  This can be useful with \fB\-std=\fR to
! force standard-compliance but get access to the full range of intrinsics
  available with \fBgfortran\fR.  As a consequence, \fB\-Wintrinsics\-std\fR
! will be ignored and no user-defined procedure with the same name as any
  intrinsic will be called except when it is explicitly declared \f(CW\*(C`EXTERNAL\*(C'\fR.
! .IP "\fB\-fallow\-argument\-mismatch\fR" 4
  .IX Item "-fallow-argument-mismatch"
  Some code contains calls to external procedures with mismatches
  between the calls and the procedure definition, or with mismatches
! between different calls. Such code is non-conforming, and will usually
  be flagged with an error.  This options degrades the error to a
  warning, which can only be disabled by disabling all warnings via
  \&\fB\-w\fR.  Only a single occurrence per argument is flagged by this
--- 175,203 ----
  .IX Subsection "Options controlling Fortran dialect"
  The following options control the details of the Fortran dialect
  accepted by the compiler:
! .IP \fB\-ffree\-form\fR 4
  .IX Item "-ffree-form"
  .PD 0
! .IP \fB\-ffixed\-form\fR 4
  .IX Item "-ffixed-form"
  .PD
  Specify the layout used by the source file.  The free form layout
  was introduced in Fortran 90.  Fixed form was traditionally used in
  older Fortran programs.  When neither option is specified, the source
  form is determined by the file extension.
! .IP \fB\-fall\-intrinsics\fR 4
  .IX Item "-fall-intrinsics"
! This option causes all intrinsic procedures (including the GNU\-specific
  extensions) to be accepted.  This can be useful with \fB\-std=\fR to
! force standard\-compliance but get access to the full range of intrinsics
  available with \fBgfortran\fR.  As a consequence, \fB\-Wintrinsics\-std\fR
! will be ignored and no user\-defined procedure with the same name as any
  intrinsic will be called except when it is explicitly declared \f(CW\*(C`EXTERNAL\*(C'\fR.
! .IP \fB\-fallow\-argument\-mismatch\fR 4
  .IX Item "-fallow-argument-mismatch"
  Some code contains calls to external procedures with mismatches
  between the calls and the procedure definition, or with mismatches
! between different calls. Such code is non\-conforming, and will usually
  be flagged with an error.  This options degrades the error to a
  warning, which can only be disabled by disabling all warnings via
  \&\fB\-w\fR.  Only a single occurrence per argument is flagged by this
*************** warning.  \fB\-fallow\-argument\-mismatc
*** 280,297 ****
  \&\fB\-std=legacy\fR.
  .Sp
  Using this option is \fIstrongly\fR discouraged.  It is possible to
! provide standard-conforming code which allows different types of
  arguments by using an explicit interface and \f(CWTYPE(*)\fR.
! .IP "\fB\-fallow\-invalid\-boz\fR" 4
  .IX Item "-fallow-invalid-boz"
! A \s-1BOZ\s0 literal constant can occur in a limited number of contexts in
  standard conforming Fortran.  This option degrades an error condition
! to a warning, and allows a \s-1BOZ\s0 literal constant to appear where the
  Fortran standard would otherwise prohibit its use.
! .IP "\fB\-fd\-lines\-as\-code\fR" 4
  .IX Item "-fd-lines-as-code"
  .PD 0
! .IP "\fB\-fd\-lines\-as\-comments\fR" 4
  .IX Item "-fd-lines-as-comments"
  .PD
  Enable special treatment for lines beginning with \f(CW\*(C`d\*(C'\fR or \f(CW\*(C`D\*(C'\fR
--- 205,222 ----
  \&\fB\-std=legacy\fR.
  .Sp
  Using this option is \fIstrongly\fR discouraged.  It is possible to
! provide standard\-conforming code which allows different types of
  arguments by using an explicit interface and \f(CWTYPE(*)\fR.
! .IP \fB\-fallow\-invalid\-boz\fR 4
  .IX Item "-fallow-invalid-boz"
! A BOZ literal constant can occur in a limited number of contexts in
  standard conforming Fortran.  This option degrades an error condition
! to a warning, and allows a BOZ literal constant to appear where the
  Fortran standard would otherwise prohibit its use.
! .IP \fB\-fd\-lines\-as\-code\fR 4
  .IX Item "-fd-lines-as-code"
  .PD 0
! .IP \fB\-fd\-lines\-as\-comments\fR 4
  .IX Item "-fd-lines-as-comments"
  .PD
  Enable special treatment for lines beginning with \f(CW\*(C`d\*(C'\fR or \f(CW\*(C`D\*(C'\fR
*************** in fixed form sources.  If the \fB\-fd\-
*** 299,310 ****
  given they are treated as if the first column contained a blank.  If the
  \&\fB\-fd\-lines\-as\-comments\fR option is given, they are treated as
  comment lines.
! .IP "\fB\-fdec\fR" 4
  .IX Item "-fdec"
! \&\s-1DEC\s0 compatibility mode. Enables extensions and other features that mimic
! the default behavior of older compilers (such as \s-1DEC\s0).
! These features are non-standard and should be avoided at all costs.
! For details on \s-1GNU\s0 Fortran's implementation of these extensions see the
  full documentation.
  .Sp
  Other flags enabled by this switch are:
--- 224,235 ----
  given they are treated as if the first column contained a blank.  If the
  \&\fB\-fd\-lines\-as\-comments\fR option is given, they are treated as
  comment lines.
! .IP \fB\-fdec\fR 4
  .IX Item "-fdec"
! DEC compatibility mode. Enables extensions and other features that mimic
! the default behavior of older compilers (such as DEC).
! These features are non\-standard and should be avoided at all costs.
! For details on GNU Fortran\*(Aqs implementation of these extensions see the
  full documentation.
  .Sp
  Other flags enabled by this switch are:
*************** Other flags enabled by this switch are:
*** 315,423 ****
  .Sp
  If \fB\-fd\-lines\-as\-code\fR/\fB\-fd\-lines\-as\-comments\fR are unset, then
  \&\fB\-fdec\fR also sets \fB\-fd\-lines\-as\-comments\fR.
! .IP "\fB\-fdec\-char\-conversions\fR" 4
  .IX Item "-fdec-char-conversions"
  Enable the use of character literals in assignments and \f(CW\*(C`DATA\*(C'\fR statements
! for non-character variables.
! .IP "\fB\-fdec\-structure\fR" 4
  .IX Item "-fdec-structure"
! Enable \s-1DEC\s0 \f(CW\*(C`STRUCTURE\*(C'\fR and \f(CW\*(C`RECORD\*(C'\fR as well as \f(CW\*(C`UNION\*(C'\fR,
! \&\f(CW\*(C`MAP\*(C'\fR, and dot ('.') as a member separator (in addition to '%'). This is
  provided for compatibility only; Fortran 90 derived types should be used
  instead where possible.
! .IP "\fB\-fdec\-intrinsic\-ints\fR" 4
  .IX Item "-fdec-intrinsic-ints"
! Enable B/I/J/K kind variants of existing integer functions (e.g. \s-1BIAND, IIAND,
! JIAND,\s0 etc...). For a complete list of intrinsics see the full documentation.
! .IP "\fB\-fdec\-math\fR" 4
  .IX Item "-fdec-math"
! Enable legacy math intrinsics such as \s-1COTAN\s0 and degree-valued trigonometric
! functions (e.g. \s-1TAND, ATAND,\s0 etc...) for compatability with older code.
! .IP "\fB\-fdec\-static\fR" 4
  .IX Item "-fdec-static"
! Enable DEC-style \s-1STATIC\s0 and \s-1AUTOMATIC\s0 attributes to explicitly specify
  the storage of variables and other objects.
! .IP "\fB\-fdec\-include\fR" 4
  .IX Item "-fdec-include"
! Enable parsing of \s-1INCLUDE\s0 as a statement in addition to parsing it as
! \&\s-1INCLUDE\s0 line.  When parsed as \s-1INCLUDE\s0 statement, \s-1INCLUDE\s0 does not have to
  be on a single line and can use line continuations.
! .IP "\fB\-fdec\-format\-defaults\fR" 4
  .IX Item "-fdec-format-defaults"
  Enable format specifiers F, G and I to be used without width specifiers,
  default widths will be used instead.
! .IP "\fB\-fdec\-blank\-format\-item\fR" 4
  .IX Item "-fdec-blank-format-item"
  Enable a blank format item at the end of a format specification i.e. nothing
  following the final comma.
! .IP "\fB\-fdollar\-ok\fR" 4
  .IX Item "-fdollar-ok"
! Allow \fB$\fR as a valid non-first character in a symbol name. Symbols 
  that start with \fB$\fR are rejected since it is unclear which rules to
  apply to implicit typing as different vendors implement different rules.
  Using \fB$\fR in \f(CW\*(C`IMPLICIT\*(C'\fR statements is also rejected.
! .IP "\fB\-fbackslash\fR" 4
  .IX Item "-fbackslash"
  Change the interpretation of backslashes in string literals from a single
! backslash character to \*(L"C\-style\*(R" escape characters. The following
  combinations are expanded \f(CW\*(C`\ea\*(C'\fR, \f(CW\*(C`\eb\*(C'\fR, \f(CW\*(C`\ef\*(C'\fR, \f(CW\*(C`\en\*(C'\fR,
! \&\f(CW\*(C`\er\*(C'\fR, \f(CW\*(C`\et\*(C'\fR, \f(CW\*(C`\ev\*(C'\fR, \f(CW\*(C`\e\e\*(C'\fR, and \f(CW\*(C`\e0\*(C'\fR to the \s-1ASCII\s0
  characters alert, backspace, form feed, newline, carriage return,
! horizontal tab, vertical tab, backslash, and \s-1NUL,\s0 respectively.
  Additionally, \f(CW\*(C`\ex\*(C'\fR\fInn\fR, \f(CW\*(C`\eu\*(C'\fR\fInnnn\fR and
  \&\f(CW\*(C`\eU\*(C'\fR\fInnnnnnnn\fR (where each \fIn\fR is a hexadecimal digit) are
  translated into the Unicode characters corresponding to the specified code
  points. All other combinations of a character preceded by \e are
  unexpanded.
! .IP "\fB\-fmodule\-private\fR" 4
  .IX Item "-fmodule-private"
  Set the default accessibility of module entities to \f(CW\*(C`PRIVATE\*(C'\fR.
! Use-associated entities will not be accessible unless they are explicitly
  declared as \f(CW\*(C`PUBLIC\*(C'\fR.
! .IP "\fB\-ffixed\-line\-length\-\fR\fIn\fR" 4
  .IX Item "-ffixed-line-length-n"
! Set column after which characters are ignored in typical fixed-form
  lines in the source file, and, unless \f(CW\*(C`\-fno\-pad\-source\*(C'\fR, through which
  spaces are assumed (as if padded to that length) after the ends of short
! fixed-form lines.
  .Sp
  Popular values for \fIn\fR include 72 (the
  standard and the default), 80 (card image), and 132 (corresponding
! to \*(L"extended-source\*(R" options in some popular compilers).
  \&\fIn\fR may also be \fBnone\fR, meaning that the entire line is meaningful
  and that continued character constants never have implicit spaces appended
  to them to fill out the line.
  \&\fB\-ffixed\-line\-length\-0\fR means the same thing as
  \&\fB\-ffixed\-line\-length\-none\fR.
! .IP "\fB\-fno\-pad\-source\fR" 4
  .IX Item "-fno-pad-source"
! By default fixed-form lines have spaces assumed (as if padded to that length)
! after the ends of short fixed-form lines.  This is not done either if
  \&\fB\-ffixed\-line\-length\-0\fR, \fB\-ffixed\-line\-length\-none\fR or
  if \fB\-fno\-pad\-source\fR option is used.  With any of those options
  continued character constants never have implicit spaces appended
  to them to fill out the line.
! .IP "\fB\-ffree\-line\-length\-\fR\fIn\fR" 4
  .IX Item "-ffree-line-length-n"
! Set column after which characters are ignored in typical free-form
  lines in the source file. The default value is 132.
  \&\fIn\fR may be \fBnone\fR, meaning that the entire line is meaningful.
  \&\fB\-ffree\-line\-length\-0\fR means the same thing as
  \&\fB\-ffree\-line\-length\-none\fR.
! .IP "\fB\-fmax\-identifier\-length=\fR\fIn\fR" 4
  .IX Item "-fmax-identifier-length=n"
  Specify the maximum allowed identifier length. Typical values are
  31 (Fortran 95) and 63 (Fortran 2003 and later).
! .IP "\fB\-fimplicit\-none\fR" 4
  .IX Item "-fimplicit-none"
  Specify that no implicit typing is allowed, unless overridden by explicit
  \&\f(CW\*(C`IMPLICIT\*(C'\fR statements.  This is the equivalent of adding
  \&\f(CW\*(C`implicit none\*(C'\fR to the start of every procedure.
! .IP "\fB\-fcray\-pointer\fR" 4
  .IX Item "-fcray-pointer"
  Enable the Cray pointer extension, which provides C\-like pointer
  functionality.
! .IP "\fB\-fopenacc\fR" 4
  .IX Item "-fopenacc"
  Enable the OpenACC extensions.  This includes OpenACC \f(CW\*(C`!$acc\*(C'\fR
  directives in free form and \f(CW\*(C`c$acc\*(C'\fR, \f(CW*$acc\fR and
--- 240,348 ----
  .Sp
  If \fB\-fd\-lines\-as\-code\fR/\fB\-fd\-lines\-as\-comments\fR are unset, then
  \&\fB\-fdec\fR also sets \fB\-fd\-lines\-as\-comments\fR.
! .IP \fB\-fdec\-char\-conversions\fR 4
  .IX Item "-fdec-char-conversions"
  Enable the use of character literals in assignments and \f(CW\*(C`DATA\*(C'\fR statements
! for non\-character variables.
! .IP \fB\-fdec\-structure\fR 4
  .IX Item "-fdec-structure"
! Enable DEC \f(CW\*(C`STRUCTURE\*(C'\fR and \f(CW\*(C`RECORD\*(C'\fR as well as \f(CW\*(C`UNION\*(C'\fR,
! \&\f(CW\*(C`MAP\*(C'\fR, and dot (\*(Aq.\*(Aq) as a member separator (in addition to \*(Aq%\*(Aq). This is
  provided for compatibility only; Fortran 90 derived types should be used
  instead where possible.
! .IP \fB\-fdec\-intrinsic\-ints\fR 4
  .IX Item "-fdec-intrinsic-ints"
! Enable B/I/J/K kind variants of existing integer functions (e.g. BIAND, IIAND,
! JIAND, etc...). For a complete list of intrinsics see the full documentation.
! .IP \fB\-fdec\-math\fR 4
  .IX Item "-fdec-math"
! Enable legacy math intrinsics such as COTAN and degree\-valued trigonometric
! functions (e.g. TAND, ATAND, etc...) for compatability with older code.
! .IP \fB\-fdec\-static\fR 4
  .IX Item "-fdec-static"
! Enable DEC\-style STATIC and AUTOMATIC attributes to explicitly specify
  the storage of variables and other objects.
! .IP \fB\-fdec\-include\fR 4
  .IX Item "-fdec-include"
! Enable parsing of INCLUDE as a statement in addition to parsing it as
! INCLUDE line.  When parsed as INCLUDE statement, INCLUDE does not have to
  be on a single line and can use line continuations.
! .IP \fB\-fdec\-format\-defaults\fR 4
  .IX Item "-fdec-format-defaults"
  Enable format specifiers F, G and I to be used without width specifiers,
  default widths will be used instead.
! .IP \fB\-fdec\-blank\-format\-item\fR 4
  .IX Item "-fdec-blank-format-item"
  Enable a blank format item at the end of a format specification i.e. nothing
  following the final comma.
! .IP \fB\-fdollar\-ok\fR 4
  .IX Item "-fdollar-ok"
! Allow \fB$\fR as a valid non\-first character in a symbol name. Symbols 
  that start with \fB$\fR are rejected since it is unclear which rules to
  apply to implicit typing as different vendors implement different rules.
  Using \fB$\fR in \f(CW\*(C`IMPLICIT\*(C'\fR statements is also rejected.
! .IP \fB\-fbackslash\fR 4
  .IX Item "-fbackslash"
  Change the interpretation of backslashes in string literals from a single
! backslash character to "C\-style" escape characters. The following
  combinations are expanded \f(CW\*(C`\ea\*(C'\fR, \f(CW\*(C`\eb\*(C'\fR, \f(CW\*(C`\ef\*(C'\fR, \f(CW\*(C`\en\*(C'\fR,
! \&\f(CW\*(C`\er\*(C'\fR, \f(CW\*(C`\et\*(C'\fR, \f(CW\*(C`\ev\*(C'\fR, \f(CW\*(C`\e\e\*(C'\fR, and \f(CW\*(C`\e0\*(C'\fR to the ASCII
  characters alert, backspace, form feed, newline, carriage return,
! horizontal tab, vertical tab, backslash, and NUL, respectively.
  Additionally, \f(CW\*(C`\ex\*(C'\fR\fInn\fR, \f(CW\*(C`\eu\*(C'\fR\fInnnn\fR and
  \&\f(CW\*(C`\eU\*(C'\fR\fInnnnnnnn\fR (where each \fIn\fR is a hexadecimal digit) are
  translated into the Unicode characters corresponding to the specified code
  points. All other combinations of a character preceded by \e are
  unexpanded.
! .IP \fB\-fmodule\-private\fR 4
  .IX Item "-fmodule-private"
  Set the default accessibility of module entities to \f(CW\*(C`PRIVATE\*(C'\fR.
! Use\-associated entities will not be accessible unless they are explicitly
  declared as \f(CW\*(C`PUBLIC\*(C'\fR.
! .IP \fB\-ffixed\-line\-length\-\fR\fIn\fR 4
  .IX Item "-ffixed-line-length-n"
! Set column after which characters are ignored in typical fixed\-form
  lines in the source file, and, unless \f(CW\*(C`\-fno\-pad\-source\*(C'\fR, through which
  spaces are assumed (as if padded to that length) after the ends of short
! fixed\-form lines.
  .Sp
  Popular values for \fIn\fR include 72 (the
  standard and the default), 80 (card image), and 132 (corresponding
! to "extended\-source" options in some popular compilers).
  \&\fIn\fR may also be \fBnone\fR, meaning that the entire line is meaningful
  and that continued character constants never have implicit spaces appended
  to them to fill out the line.
  \&\fB\-ffixed\-line\-length\-0\fR means the same thing as
  \&\fB\-ffixed\-line\-length\-none\fR.
! .IP \fB\-fno\-pad\-source\fR 4
  .IX Item "-fno-pad-source"
! By default fixed\-form lines have spaces assumed (as if padded to that length)
! after the ends of short fixed\-form lines.  This is not done either if
  \&\fB\-ffixed\-line\-length\-0\fR, \fB\-ffixed\-line\-length\-none\fR or
  if \fB\-fno\-pad\-source\fR option is used.  With any of those options
  continued character constants never have implicit spaces appended
  to them to fill out the line.
! .IP \fB\-ffree\-line\-length\-\fR\fIn\fR 4
  .IX Item "-ffree-line-length-n"
! Set column after which characters are ignored in typical free\-form
  lines in the source file. The default value is 132.
  \&\fIn\fR may be \fBnone\fR, meaning that the entire line is meaningful.
  \&\fB\-ffree\-line\-length\-0\fR means the same thing as
  \&\fB\-ffree\-line\-length\-none\fR.
! .IP \fB\-fmax\-identifier\-length=\fR\fIn\fR 4
  .IX Item "-fmax-identifier-length=n"
  Specify the maximum allowed identifier length. Typical values are
  31 (Fortran 95) and 63 (Fortran 2003 and later).
! .IP \fB\-fimplicit\-none\fR 4
  .IX Item "-fimplicit-none"
  Specify that no implicit typing is allowed, unless overridden by explicit
  \&\f(CW\*(C`IMPLICIT\*(C'\fR statements.  This is the equivalent of adding
  \&\f(CW\*(C`implicit none\*(C'\fR to the start of every procedure.
! .IP \fB\-fcray\-pointer\fR 4
  .IX Item "-fcray-pointer"
  Enable the Cray pointer extension, which provides C\-like pointer
  functionality.
! .IP \fB\-fopenacc\fR 4
  .IX Item "-fopenacc"
  Enable the OpenACC extensions.  This includes OpenACC \f(CW\*(C`!$acc\*(C'\fR
  directives in free form and \f(CW\*(C`c$acc\*(C'\fR, \f(CW*$acc\fR and
*************** directives in free form and \f(CW\*(C`c$
*** 425,431 ****
  compilation sentinels in free form and \f(CW\*(C`c$\*(C'\fR, \f(CW\*(C`*$\*(C'\fR and
  \&\f(CW\*(C`!$\*(C'\fR sentinels in fixed form, and when linking arranges for the
  OpenACC runtime library to be linked in.
! .IP "\fB\-fopenmp\fR" 4
  .IX Item "-fopenmp"
  Enable the OpenMP extensions.  This includes OpenMP \f(CW\*(C`!$omp\*(C'\fR directives
  in free form
--- 350,356 ----
  compilation sentinels in free form and \f(CW\*(C`c$\*(C'\fR, \f(CW\*(C`*$\*(C'\fR and
  \&\f(CW\*(C`!$\*(C'\fR sentinels in fixed form, and when linking arranges for the
  OpenACC runtime library to be linked in.
! .IP \fB\-fopenmp\fR 4
  .IX Item "-fopenmp"
  Enable the OpenMP extensions.  This includes OpenMP \f(CW\*(C`!$omp\*(C'\fR directives
  in free form
*************** and \f(CW\*(C`c$omp\*(C'\fR, \f(CW*$omp\
*** 434,489 ****
  and \f(CW\*(C`c$\*(C'\fR, \f(CW\*(C`*$\*(C'\fR and \f(CW\*(C`!$\*(C'\fR sentinels in fixed form, 
  and when linking arranges for the OpenMP runtime library to be linked
  in.  The option \fB\-fopenmp\fR implies \fB\-frecursive\fR.
! .IP "\fB\-fno\-range\-check\fR" 4
  .IX Item "-fno-range-check"
  Disable range checking on results of simplification of constant
! expressions during compilation.  For example, \s-1GNU\s0 Fortran will give
  an error at compile time when simplifying \f(CW\*(C`a = 1. / 0\*(C'\fR.
  With this option, no error will be given and \f(CW\*(C`a\*(C'\fR will be assigned
  the value \f(CW\*(C`+Infinity\*(C'\fR.  If an expression evaluates to a value
! outside of the relevant range of [\f(CW\*(C`\-HUGE()\*(C'\fR:\f(CW\*(C`HUGE()\*(C'\fR],
  then the expression will be replaced by \f(CW\*(C`\-Inf\*(C'\fR or \f(CW\*(C`+Inf\*(C'\fR
  as appropriate.
  Similarly, \f(CW\*(C`DATA i/Z\*(AqFFFFFFFF\*(Aq/\*(C'\fR will result in an integer overflow
  on most systems, but with \fB\-fno\-range\-check\fR the value will
! \&\*(L"wrap around\*(R" and \f(CW\*(C`i\*(C'\fR will be initialized to \-1 instead.
! .IP "\fB\-fdefault\-integer\-8\fR" 4
  .IX Item "-fdefault-integer-8"
  Set the default integer and logical types to an 8 byte wide type.  This option
  also affects the kind of integer constants like \f(CW42\fR. Unlike
  \&\fB\-finteger\-4\-integer\-8\fR, it does not promote variables with explicit
  kind declaration.
! .IP "\fB\-fdefault\-real\-8\fR" 4
  .IX Item "-fdefault-real-8"
  Set the default real type to an 8 byte wide type.  This option also affects
! the kind of non-double real constants like \f(CW1.0\fR.  This option promotes
  the default width of \f(CW\*(C`DOUBLE PRECISION\*(C'\fR and double real constants
  like \f(CW\*(C`1.d0\*(C'\fR to 16 bytes if possible.  If \f(CW\*(C`\-fdefault\-double\-8\*(C'\fR
  is given along with \f(CW\*(C`fdefault\-real\-8\*(C'\fR, \f(CW\*(C`DOUBLE PRECISION\*(C'\fR
  and double real constants are not promoted.  Unlike \fB\-freal\-4\-real\-8\fR,
  \&\f(CW\*(C`fdefault\-real\-8\*(C'\fR does not promote variables with explicit kind
  declarations.
! .IP "\fB\-fdefault\-real\-10\fR" 4
  .IX Item "-fdefault-real-10"
  Set the default real type to an 10 byte wide type.  This option also affects
! the kind of non-double real constants like \f(CW1.0\fR.  This option promotes
  the default width of \f(CW\*(C`DOUBLE PRECISION\*(C'\fR and double real constants
  like \f(CW\*(C`1.d0\*(C'\fR to 16 bytes if possible.  If \f(CW\*(C`\-fdefault\-double\-8\*(C'\fR
  is given along with \f(CW\*(C`fdefault\-real\-10\*(C'\fR, \f(CW\*(C`DOUBLE PRECISION\*(C'\fR
  and double real constants are not promoted.  Unlike \fB\-freal\-4\-real\-10\fR,
  \&\f(CW\*(C`fdefault\-real\-10\*(C'\fR does not promote variables with explicit kind
  declarations.
! .IP "\fB\-fdefault\-real\-16\fR" 4
  .IX Item "-fdefault-real-16"
  Set the default real type to an 16 byte wide type.  This option also affects
! the kind of non-double real constants like \f(CW1.0\fR.  This option promotes
  the default width of \f(CW\*(C`DOUBLE PRECISION\*(C'\fR and double real constants
  like \f(CW\*(C`1.d0\*(C'\fR to 16 bytes if possible.  If \f(CW\*(C`\-fdefault\-double\-8\*(C'\fR
  is given along with \f(CW\*(C`fdefault\-real\-16\*(C'\fR, \f(CW\*(C`DOUBLE PRECISION\*(C'\fR
  and double real constants are not promoted.  Unlike \fB\-freal\-4\-real\-16\fR,
  \&\f(CW\*(C`fdefault\-real\-16\*(C'\fR does not promote variables with explicit kind
  declarations.
! .IP "\fB\-fdefault\-double\-8\fR" 4
  .IX Item "-fdefault-double-8"
  Set the \f(CW\*(C`DOUBLE PRECISION\*(C'\fR type and double real constants
  like \f(CW\*(C`1.d0\*(C'\fR to an 8 byte wide type.  Do nothing if this
--- 359,414 ----
  and \f(CW\*(C`c$\*(C'\fR, \f(CW\*(C`*$\*(C'\fR and \f(CW\*(C`!$\*(C'\fR sentinels in fixed form, 
  and when linking arranges for the OpenMP runtime library to be linked
  in.  The option \fB\-fopenmp\fR implies \fB\-frecursive\fR.
! .IP \fB\-fno\-range\-check\fR 4
  .IX Item "-fno-range-check"
  Disable range checking on results of simplification of constant
! expressions during compilation.  For example, GNU Fortran will give
  an error at compile time when simplifying \f(CW\*(C`a = 1. / 0\*(C'\fR.
  With this option, no error will be given and \f(CW\*(C`a\*(C'\fR will be assigned
  the value \f(CW\*(C`+Infinity\*(C'\fR.  If an expression evaluates to a value
! outside of the relevant range of [\f(CW\*(C`\-HUGE()\*(C'\fR:\f(CWHUGE()\fR],
  then the expression will be replaced by \f(CW\*(C`\-Inf\*(C'\fR or \f(CW\*(C`+Inf\*(C'\fR
  as appropriate.
  Similarly, \f(CW\*(C`DATA i/Z\*(AqFFFFFFFF\*(Aq/\*(C'\fR will result in an integer overflow
  on most systems, but with \fB\-fno\-range\-check\fR the value will
! "wrap around" and \f(CW\*(C`i\*(C'\fR will be initialized to \-1 instead.
! .IP \fB\-fdefault\-integer\-8\fR 4
  .IX Item "-fdefault-integer-8"
  Set the default integer and logical types to an 8 byte wide type.  This option
  also affects the kind of integer constants like \f(CW42\fR. Unlike
  \&\fB\-finteger\-4\-integer\-8\fR, it does not promote variables with explicit
  kind declaration.
! .IP \fB\-fdefault\-real\-8\fR 4
  .IX Item "-fdefault-real-8"
  Set the default real type to an 8 byte wide type.  This option also affects
! the kind of non\-double real constants like \f(CW1.0\fR.  This option promotes
  the default width of \f(CW\*(C`DOUBLE PRECISION\*(C'\fR and double real constants
  like \f(CW\*(C`1.d0\*(C'\fR to 16 bytes if possible.  If \f(CW\*(C`\-fdefault\-double\-8\*(C'\fR
  is given along with \f(CW\*(C`fdefault\-real\-8\*(C'\fR, \f(CW\*(C`DOUBLE PRECISION\*(C'\fR
  and double real constants are not promoted.  Unlike \fB\-freal\-4\-real\-8\fR,
  \&\f(CW\*(C`fdefault\-real\-8\*(C'\fR does not promote variables with explicit kind
  declarations.
! .IP \fB\-fdefault\-real\-10\fR 4
  .IX Item "-fdefault-real-10"
  Set the default real type to an 10 byte wide type.  This option also affects
! the kind of non\-double real constants like \f(CW1.0\fR.  This option promotes
  the default width of \f(CW\*(C`DOUBLE PRECISION\*(C'\fR and double real constants
  like \f(CW\*(C`1.d0\*(C'\fR to 16 bytes if possible.  If \f(CW\*(C`\-fdefault\-double\-8\*(C'\fR
  is given along with \f(CW\*(C`fdefault\-real\-10\*(C'\fR, \f(CW\*(C`DOUBLE PRECISION\*(C'\fR
  and double real constants are not promoted.  Unlike \fB\-freal\-4\-real\-10\fR,
  \&\f(CW\*(C`fdefault\-real\-10\*(C'\fR does not promote variables with explicit kind
  declarations.
! .IP \fB\-fdefault\-real\-16\fR 4
  .IX Item "-fdefault-real-16"
  Set the default real type to an 16 byte wide type.  This option also affects
! the kind of non\-double real constants like \f(CW1.0\fR.  This option promotes
  the default width of \f(CW\*(C`DOUBLE PRECISION\*(C'\fR and double real constants
  like \f(CW\*(C`1.d0\*(C'\fR to 16 bytes if possible.  If \f(CW\*(C`\-fdefault\-double\-8\*(C'\fR
  is given along with \f(CW\*(C`fdefault\-real\-16\*(C'\fR, \f(CW\*(C`DOUBLE PRECISION\*(C'\fR
  and double real constants are not promoted.  Unlike \fB\-freal\-4\-real\-16\fR,
  \&\f(CW\*(C`fdefault\-real\-16\*(C'\fR does not promote variables with explicit kind
  declarations.
! .IP \fB\-fdefault\-double\-8\fR 4
  .IX Item "-fdefault-double-8"
  Set the \f(CW\*(C`DOUBLE PRECISION\*(C'\fR type and double real constants
  like \f(CW\*(C`1.d0\*(C'\fR to an 8 byte wide type.  Do nothing if this
*************** is already the default.  This option pre
*** 491,551 ****
  \&\fB\-fdefault\-real\-10\fR, and \fB\-fdefault\-real\-16\fR,
  from promoting \f(CW\*(C`DOUBLE PRECISION\*(C'\fR and double real constants like
  \&\f(CW\*(C`1.d0\*(C'\fR to 16 bytes.
! .IP "\fB\-finteger\-4\-integer\-8\fR" 4
  .IX Item "-finteger-4-integer-8"
! Promote all \f(CW\*(C`INTEGER(KIND=4)\*(C'\fR entities to an \f(CW\*(C`INTEGER(KIND=8)\*(C'\fR
  entities.  If \f(CW\*(C`KIND=8\*(C'\fR is unavailable, then an error will be issued.
  This option should be used with care and may not be suitable for your codes.
  Areas of possible concern include calls to external procedures,
  alignment in \f(CW\*(C`EQUIVALENCE\*(C'\fR and/or \f(CW\*(C`COMMON\*(C'\fR, generic interfaces,
! \&\s-1BOZ\s0 literal constant conversion, and I/O.  Inspection of the intermediate
  representation of the translated Fortran code, produced by
  \&\fB\-fdump\-tree\-original\fR, is suggested.
! .IP "\fB\-freal\-4\-real\-8\fR" 4
  .IX Item "-freal-4-real-8"
  .PD 0
! .IP "\fB\-freal\-4\-real\-10\fR" 4
  .IX Item "-freal-4-real-10"
! .IP "\fB\-freal\-4\-real\-16\fR" 4
  .IX Item "-freal-4-real-16"
! .IP "\fB\-freal\-8\-real\-4\fR" 4
  .IX Item "-freal-8-real-4"
! .IP "\fB\-freal\-8\-real\-10\fR" 4
  .IX Item "-freal-8-real-10"
! .IP "\fB\-freal\-8\-real\-16\fR" 4
  .IX Item "-freal-8-real-16"
  .PD
! Promote all \f(CW\*(C`REAL(KIND=M)\*(C'\fR entities to \f(CW\*(C`REAL(KIND=N)\*(C'\fR entities.
! If \f(CW\*(C`REAL(KIND=N)\*(C'\fR is unavailable, then an error will be issued.
  The \f(CW\*(C`\-freal\-4\-\*(C'\fR flags also affect the default real kind and the
! \&\f(CW\*(C`\-freal\-8\-\*(C'\fR flags also the double-precision real kind.  All other
! real-kind types are unaffected by this option.  The promotion is also
! applied to real literal constants of default and double-precision kind
  and a specified kind number of 4 or 8, respectively.
  However, \f(CW\*(C`\-fdefault\-real\-8\*(C'\fR, \f(CW\*(C`\-fdefault\-real\-10\*(C'\fR,
  \&\f(CW\*(C`\-fdefault\-real\-10\*(C'\fR, and \f(CW\*(C`\-fdefault\-double\-8\*(C'\fR take precedence
! for the default and double-precision real kinds, both for real literal
  constants and for declarations without a kind number.
  Note that for \f(CW\*(C`REAL(KIND=KIND(1.0))\*(C'\fR the literal may get promoted and
  then the result may get promoted again.
  These options should be used with care and may not be suitable for your
  codes.  Areas of possible concern include calls to external procedures,
  alignment in \f(CW\*(C`EQUIVALENCE\*(C'\fR and/or \f(CW\*(C`COMMON\*(C'\fR, generic interfaces,
! \&\s-1BOZ\s0 literal constant conversion, and I/O and calls to intrinsic procedures
  when passing a value to the \f(CW\*(C`kind=\*(C'\fR dummy argument.  Inspection of the
  intermediate representation of the translated Fortran code, produced by
  \&\fB\-fdump\-fortran\-original\fR or \fB\-fdump\-tree\-original\fR, is suggested.
! .IP "\fB\-std=\fR\fIstd\fR" 4
  .IX Item "-std=std"
  Specify the standard to which the program is expected to conform,
  which may be one of \fBf95\fR, \fBf2003\fR, \fBf2008\fR,
  \&\fBf2018\fR, \fBgnu\fR, or \fBlegacy\fR.  The default value for
  \&\fIstd\fR is \fBgnu\fR, which specifies a superset of the latest
! Fortran standard that includes all of the extensions supported by \s-1GNU\s0
  Fortran, although warnings will be given for obsolete extensions not
  recommended for use in new code.  The \fBlegacy\fR value is
  equivalent but without the warnings for obsolete extensions, and may
! be useful for old non-standard programs.  The \fBf95\fR,
  \&\fBf2003\fR, \fBf2008\fR, and \fBf2018\fR values specify strict
  conformance to the Fortran 95, Fortran 2003, Fortran 2008 and Fortran
  2018 standards, respectively; errors are given for all extensions
--- 416,476 ----
  \&\fB\-fdefault\-real\-10\fR, and \fB\-fdefault\-real\-16\fR,
  from promoting \f(CW\*(C`DOUBLE PRECISION\*(C'\fR and double real constants like
  \&\f(CW\*(C`1.d0\*(C'\fR to 16 bytes.
! .IP \fB\-finteger\-4\-integer\-8\fR 4
  .IX Item "-finteger-4-integer-8"
! Promote all \f(CWINTEGER(KIND=4)\fR entities to an \f(CWINTEGER(KIND=8)\fR
  entities.  If \f(CW\*(C`KIND=8\*(C'\fR is unavailable, then an error will be issued.
  This option should be used with care and may not be suitable for your codes.
  Areas of possible concern include calls to external procedures,
  alignment in \f(CW\*(C`EQUIVALENCE\*(C'\fR and/or \f(CW\*(C`COMMON\*(C'\fR, generic interfaces,
! BOZ literal constant conversion, and I/O.  Inspection of the intermediate
  representation of the translated Fortran code, produced by
  \&\fB\-fdump\-tree\-original\fR, is suggested.
! .IP \fB\-freal\-4\-real\-8\fR 4
  .IX Item "-freal-4-real-8"
  .PD 0
! .IP \fB\-freal\-4\-real\-10\fR 4
  .IX Item "-freal-4-real-10"
! .IP \fB\-freal\-4\-real\-16\fR 4
  .IX Item "-freal-4-real-16"
! .IP \fB\-freal\-8\-real\-4\fR 4
  .IX Item "-freal-8-real-4"
! .IP \fB\-freal\-8\-real\-10\fR 4
  .IX Item "-freal-8-real-10"
! .IP \fB\-freal\-8\-real\-16\fR 4
  .IX Item "-freal-8-real-16"
  .PD
! Promote all \f(CWREAL(KIND=M)\fR entities to \f(CWREAL(KIND=N)\fR entities.
! If \f(CWREAL(KIND=N)\fR is unavailable, then an error will be issued.
  The \f(CW\*(C`\-freal\-4\-\*(C'\fR flags also affect the default real kind and the
! \&\f(CW\*(C`\-freal\-8\-\*(C'\fR flags also the double\-precision real kind.  All other
! real\-kind types are unaffected by this option.  The promotion is also
! applied to real literal constants of default and double\-precision kind
  and a specified kind number of 4 or 8, respectively.
  However, \f(CW\*(C`\-fdefault\-real\-8\*(C'\fR, \f(CW\*(C`\-fdefault\-real\-10\*(C'\fR,
  \&\f(CW\*(C`\-fdefault\-real\-10\*(C'\fR, and \f(CW\*(C`\-fdefault\-double\-8\*(C'\fR take precedence
! for the default and double\-precision real kinds, both for real literal
  constants and for declarations without a kind number.
  Note that for \f(CW\*(C`REAL(KIND=KIND(1.0))\*(C'\fR the literal may get promoted and
  then the result may get promoted again.
  These options should be used with care and may not be suitable for your
  codes.  Areas of possible concern include calls to external procedures,
  alignment in \f(CW\*(C`EQUIVALENCE\*(C'\fR and/or \f(CW\*(C`COMMON\*(C'\fR, generic interfaces,
! BOZ literal constant conversion, and I/O and calls to intrinsic procedures
  when passing a value to the \f(CW\*(C`kind=\*(C'\fR dummy argument.  Inspection of the
  intermediate representation of the translated Fortran code, produced by
  \&\fB\-fdump\-fortran\-original\fR or \fB\-fdump\-tree\-original\fR, is suggested.
! .IP \fB\-std=\fR\fIstd\fR 4
  .IX Item "-std=std"
  Specify the standard to which the program is expected to conform,
  which may be one of \fBf95\fR, \fBf2003\fR, \fBf2008\fR,
  \&\fBf2018\fR, \fBgnu\fR, or \fBlegacy\fR.  The default value for
  \&\fIstd\fR is \fBgnu\fR, which specifies a superset of the latest
! Fortran standard that includes all of the extensions supported by GNU
  Fortran, although warnings will be given for obsolete extensions not
  recommended for use in new code.  The \fBlegacy\fR value is
  equivalent but without the warnings for obsolete extensions, and may
! be useful for old non\-standard programs.  The \fBf95\fR,
  \&\fBf2003\fR, \fBf2008\fR, and \fBf2018\fR values specify strict
  conformance to the Fortran 95, Fortran 2003, Fortran 2008 and Fortran
  2018 standards, respectively; errors are given for all extensions
*************** Fortran 77 features that are permitted b
*** 554,569 ****
  standards. The deprecated option \fB\-std=f2008ts\fR acts as an alias for
  \&\fB\-std=f2018\fR. It is only present for backwards compatibility with
  earlier gfortran versions and should not be used any more.
! .IP "\fB\-ftest\-forall\-temp\fR" 4
  .IX Item "-ftest-forall-temp"
  Enhance test coverage by forcing most forall assignments to use temporary.
  .SS "Enable and customize preprocessing"
  .IX Subsection "Enable and customize preprocessing"
! Many Fortran compilers including \s-1GNU\s0 Fortran allow passing the source code
! through a C preprocessor (\s-1CPP\s0; sometimes also called the Fortran preprocessor,
! \&\s-1FPP\s0) to allow for conditional compilation.  In the case of \s-1GNU\s0 Fortran,
! this is the \s-1GNU C\s0 Preprocessor in the traditional mode.  On systems with
! case-preserving file names, the preprocessor is automatically invoked if the
  filename extension is \fI.F\fR, \fI.FOR\fR, \fI.FTN\fR, \fI.fpp\fR,
  \&\fI.FPP\fR, \fI.F90\fR, \fI.F95\fR, \fI.F03\fR or \fI.F08\fR.  To manually
  invoke the preprocessor on any file, use \fB\-cpp\fR, to disable
--- 479,494 ----
  standards. The deprecated option \fB\-std=f2008ts\fR acts as an alias for
  \&\fB\-std=f2018\fR. It is only present for backwards compatibility with
  earlier gfortran versions and should not be used any more.
! .IP \fB\-ftest\-forall\-temp\fR 4
  .IX Item "-ftest-forall-temp"
  Enhance test coverage by forcing most forall assignments to use temporary.
  .SS "Enable and customize preprocessing"
  .IX Subsection "Enable and customize preprocessing"
! Many Fortran compilers including GNU Fortran allow passing the source code
! through a C preprocessor (CPP; sometimes also called the Fortran preprocessor,
! FPP) to allow for conditional compilation.  In the case of GNU Fortran,
! this is the GNU C Preprocessor in the traditional mode.  On systems with
! case\-preserving file names, the preprocessor is automatically invoked if the
  filename extension is \fI.F\fR, \fI.FOR\fR, \fI.FTN\fR, \fI.fpp\fR,
  \&\fI.FPP\fR, \fI.F90\fR, \fI.F95\fR, \fI.F03\fR or \fI.F08\fR.  To manually
  invoke the preprocessor on any file, use \fB\-cpp\fR, to disable
*************** If a preprocessed file includes another
*** 574,603 ****
  statement, the included file is not preprocessed.  To preprocess included
  files, use the equivalent preprocessor statement \f(CW\*(C`#include\*(C'\fR.
  .PP
! If \s-1GNU\s0 Fortran invokes the preprocessor, \f(CW\*(C`_\|_GFORTRAN_\|_\*(C'\fR
  is defined.  The macros \f(CW\*(C`_\|_GNUC_\|_\*(C'\fR, \f(CW\*(C`_\|_GNUC_MINOR_\|_\*(C'\fR and
  \&\f(CW\*(C`_\|_GNUC_PATCHLEVEL_\|_\*(C'\fR can be used to determine the version of the
  compiler.  See \fBTop,,Overview,cpp,The C Preprocessor\fR for details.
  .PP
! \&\s-1GNU\s0 Fortran supports a number of \f(CW\*(C`INTEGER\*(C'\fR and \f(CW\*(C`REAL\*(C'\fR kind types
  in additional to the kind types required by the Fortran standard.
  The availability of any given kind type is architecture dependent.  The
! following pre-defined preprocessor macros can be used to conditionally
  include code for these additional kind types: \f(CW\*(C`_\|_GFC_INT_1_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_GFC_INT_2_\|_\*(C'\fR, \f(CW\*(C`_\|_GFC_INT_8_\|_\*(C'\fR, \f(CW\*(C`_\|_GFC_INT_16_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_GFC_REAL_10_\|_\*(C'\fR, and \f(CW\*(C`_\|_GFC_REAL_16_\|_\*(C'\fR.
  .PP
! While \s-1CPP\s0 is the de-facto standard for preprocessing Fortran code,
! Part 3 of the Fortran 95 standard (\s-1ISO/IEC 1539\-3:1998\s0) defines
  Conditional Compilation, which is not widely used and not directly
! supported by the \s-1GNU\s0 Fortran compiler.  You can use the program coco
  to preprocess such files (<\fBhttp://www.daniellnagle.com/coco.html\fR>).
  .PP
  The following options control preprocessing of Fortran code:
! .IP "\fB\-cpp\fR" 4
  .IX Item "-cpp"
  .PD 0
! .IP "\fB\-nocpp\fR" 4
  .IX Item "-nocpp"
  .PD
  Enable preprocessing. The preprocessor is automatically invoked if
--- 499,528 ----
  statement, the included file is not preprocessed.  To preprocess included
  files, use the equivalent preprocessor statement \f(CW\*(C`#include\*(C'\fR.
  .PP
! If GNU Fortran invokes the preprocessor, \f(CW\*(C`_\|_GFORTRAN_\|_\*(C'\fR
  is defined.  The macros \f(CW\*(C`_\|_GNUC_\|_\*(C'\fR, \f(CW\*(C`_\|_GNUC_MINOR_\|_\*(C'\fR and
  \&\f(CW\*(C`_\|_GNUC_PATCHLEVEL_\|_\*(C'\fR can be used to determine the version of the
  compiler.  See \fBTop,,Overview,cpp,The C Preprocessor\fR for details.
  .PP
! GNU Fortran supports a number of \f(CW\*(C`INTEGER\*(C'\fR and \f(CW\*(C`REAL\*(C'\fR kind types
  in additional to the kind types required by the Fortran standard.
  The availability of any given kind type is architecture dependent.  The
! following pre\-defined preprocessor macros can be used to conditionally
  include code for these additional kind types: \f(CW\*(C`_\|_GFC_INT_1_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_GFC_INT_2_\|_\*(C'\fR, \f(CW\*(C`_\|_GFC_INT_8_\|_\*(C'\fR, \f(CW\*(C`_\|_GFC_INT_16_\|_\*(C'\fR,
  \&\f(CW\*(C`_\|_GFC_REAL_10_\|_\*(C'\fR, and \f(CW\*(C`_\|_GFC_REAL_16_\|_\*(C'\fR.
  .PP
! While CPP is the de\-facto standard for preprocessing Fortran code,
! Part 3 of the Fortran 95 standard (ISO/IEC 1539\-3:1998) defines
  Conditional Compilation, which is not widely used and not directly
! supported by the GNU Fortran compiler.  You can use the program coco
  to preprocess such files (<\fBhttp://www.daniellnagle.com/coco.html\fR>).
  .PP
  The following options control preprocessing of Fortran code:
! .IP \fB\-cpp\fR 4
  .IX Item "-cpp"
  .PD 0
! .IP \fB\-nocpp\fR 4
  .IX Item "-nocpp"
  .PD
  Enable preprocessing. The preprocessor is automatically invoked if
*************** To disable preprocessing of files with a
*** 609,619 ****
  use the negative form: \fB\-nocpp\fR.
  .Sp
  The preprocessor is run in traditional mode. Any restrictions of the
! file-format, especially the limits on line length, apply for
  preprocessed output as well, so it might be advisable to use the
  \&\fB\-ffree\-line\-length\-none\fR or \fB\-ffixed\-line\-length\-none\fR
  options.
! .IP "\fB\-dM\fR" 4
  .IX Item "-dM"
  Instead of the normal output, generate a list of \f(CW\*(Aq#define\*(Aq\fR
  directives for all the macros defined during the execution of the
--- 534,544 ----
  use the negative form: \fB\-nocpp\fR.
  .Sp
  The preprocessor is run in traditional mode. Any restrictions of the
! file\-format, especially the limits on line length, apply for
  preprocessed output as well, so it might be advisable to use the
  \&\fB\-ffree\-line\-length\-none\fR or \fB\-ffixed\-line\-length\-none\fR
  options.
! .IP \fB\-dM\fR 4
  .IX Item "-dM"
  Instead of the normal output, generate a list of \f(CW\*(Aq#define\*(Aq\fR
  directives for all the macros defined during the execution of the
*************** Assuming you have no file \fIfoo.f90\fR,
*** 626,657 ****
  .Ve
  .Sp
  will show all the predefined macros.
! .IP "\fB\-dD\fR" 4
  .IX Item "-dD"
  Like \fB\-dM\fR except in two respects: it does not include the
  predefined macros, and it outputs both the \f(CW\*(C`#define\*(C'\fR directives
  and the result of preprocessing. Both kinds of output go to the
  standard output file.
! .IP "\fB\-dN\fR" 4
  .IX Item "-dN"
  Like \fB\-dD\fR, but emit only the macro names, not their expansions.
! .IP "\fB\-dU\fR" 4
  .IX Item "-dU"
  Like \fBdD\fR except that only macros that are expanded, or whose
  definedness is tested in preprocessor directives, are output; the 
  output is delayed until the use or test of the macro; and \f(CW\*(Aq#undef\*(Aq\fR
  directives are also output for macros tested but undefined at the time.
! .IP "\fB\-dI\fR" 4
  .IX Item "-dI"
  Output \f(CW\*(Aq#include\*(Aq\fR directives in addition to the result
  of preprocessing.
! .IP "\fB\-fworking\-directory\fR" 4
  .IX Item "-fworking-directory"
  Enable generation of linemarkers in the preprocessor output that will
  let the compiler know the current working directory at the time of
  preprocessing. When this option is enabled, the preprocessor will emit,
  after the initial linemarker, a second linemarker with the current
! working directory followed by two slashes. \s-1GCC\s0 will use this directory,
  when it is present in the preprocessed input, as the directory emitted
  as the current working directory in some debugging information formats.
  This option is implicitly enabled if debugging information is enabled,
--- 551,582 ----
  .Ve
  .Sp
  will show all the predefined macros.
! .IP \fB\-dD\fR 4
  .IX Item "-dD"
  Like \fB\-dM\fR except in two respects: it does not include the
  predefined macros, and it outputs both the \f(CW\*(C`#define\*(C'\fR directives
  and the result of preprocessing. Both kinds of output go to the
  standard output file.
! .IP \fB\-dN\fR 4
  .IX Item "-dN"
  Like \fB\-dD\fR, but emit only the macro names, not their expansions.
! .IP \fB\-dU\fR 4
  .IX Item "-dU"
  Like \fBdD\fR except that only macros that are expanded, or whose
  definedness is tested in preprocessor directives, are output; the 
  output is delayed until the use or test of the macro; and \f(CW\*(Aq#undef\*(Aq\fR
  directives are also output for macros tested but undefined at the time.
! .IP \fB\-dI\fR 4
  .IX Item "-dI"
  Output \f(CW\*(Aq#include\*(Aq\fR directives in addition to the result
  of preprocessing.
! .IP \fB\-fworking\-directory\fR 4
  .IX Item "-fworking-directory"
  Enable generation of linemarkers in the preprocessor output that will
  let the compiler know the current working directory at the time of
  preprocessing. When this option is enabled, the preprocessor will emit,
  after the initial linemarker, a second linemarker with the current
! working directory followed by two slashes. GCC will use this directory,
  when it is present in the preprocessed input, as the directory emitted
  as the current working directory in some debugging information formats.
  This option is implicitly enabled if debugging information is enabled,
*************** If dir begins with \f(CW\*(C`=\*(C'\fR,
*** 668,675 ****
  the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
  .IP "\fB\-imultilib\fR \fIdir\fR" 4
  .IX Item "-imultilib dir"
! Use \fIdir\fR as a subdirectory of the directory containing target-specific
! \&\*(C+ headers.
  .IP "\fB\-iprefix\fR \fIprefix\fR" 4
  .IX Item "-iprefix prefix"
  Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
--- 593,600 ----
  the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
  .IP "\fB\-imultilib\fR \fIdir\fR" 4
  .IX Item "-imultilib dir"
! Use \fIdir\fR as a subdirectory of the directory containing target\-specific
! C++ headers.
  .IP "\fB\-iprefix\fR \fIprefix\fR" 4
  .IX Item "-iprefix prefix"
  Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
*************** system directory, so that it gets the sa
*** 694,717 ****
  applied to the standard system directories. If \fIdir\fR begins with
  \&\f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced by the sysroot prefix;
  see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
! .IP "\fB\-nostdinc\fR" 4
  .IX Item "-nostdinc"
  Do not search the standard system directories for header files. Only
  the directories you have specified with \fB\-I\fR options (and the
  directory of the current file, if appropriate) are searched.
! .IP "\fB\-undef\fR" 4
  .IX Item "-undef"
! Do not predefine any system-specific or GCC-specific macros.
  The standard predefined macros remain defined.
! .IP "\fB\-A\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4
  .IX Item "-Apredicate=answer"
  Make an assertion with the predicate \fIpredicate\fR and answer \fIanswer\fR.
  This form is preferred to the older form \-A predicate(answer), which is still
  supported, because it does not use shell special characters.
! .IP "\fB\-A\-\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4
  .IX Item "-A-predicate=answer"
  Cancel an assertion with the predicate \fIpredicate\fR and answer \fIanswer\fR.
! .IP "\fB\-C\fR" 4
  .IX Item "-C"
  Do not discard comments. All comments are passed through to the output
  file, except for comments in processed directives, which are deleted
--- 619,642 ----
  applied to the standard system directories. If \fIdir\fR begins with
  \&\f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced by the sysroot prefix;
  see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
! .IP \fB\-nostdinc\fR 4
  .IX Item "-nostdinc"
  Do not search the standard system directories for header files. Only
  the directories you have specified with \fB\-I\fR options (and the
  directory of the current file, if appropriate) are searched.
! .IP \fB\-undef\fR 4
  .IX Item "-undef"
! Do not predefine any system\-specific or GCC\-specific macros.
  The standard predefined macros remain defined.
! .IP \fB\-A\fR\fIpredicate\fR\fB=\fR\fIanswer\fR 4
  .IX Item "-Apredicate=answer"
  Make an assertion with the predicate \fIpredicate\fR and answer \fIanswer\fR.
  This form is preferred to the older form \-A predicate(answer), which is still
  supported, because it does not use shell special characters.
! .IP \fB\-A\-\fR\fIpredicate\fR\fB=\fR\fIanswer\fR 4
  .IX Item "-A-predicate=answer"
  Cancel an assertion with the predicate \fIpredicate\fR and answer \fIanswer\fR.
! .IP \fB\-C\fR 4
  .IX Item "-C"
  Do not discard comments. All comments are passed through to the output
  file, except for comments in processed directives, which are deleted
*************** effect of turning that line into an ordi
*** 724,759 ****
  token on the line is no longer a \f(CW\*(Aq#\*(Aq\fR.
  .Sp
  Warning: this currently handles C\-Style comments only. The preprocessor
! does not yet recognize Fortran-style comments.
! .IP "\fB\-CC\fR" 4
  .IX Item "-CC"
  Do not discard comments, including during macro expansion. This is like
  \&\fB\-C\fR, except that comments contained within macros are also passed
  through to the output file where the macro is expanded.
  .Sp
! In addition to the side-effects of the \fB\-C\fR option, the \fB\-CC\fR
! option causes all \*(C+\-style comments inside a macro to be converted to C\-style
  comments. This is to prevent later use of that macro from inadvertently
  commenting out the remainder of the source line. The \fB\-CC\fR option
  is generally used to support lint comments.
  .Sp
! Warning: this currently handles C\- and \*(C+\-Style comments only. The
! preprocessor does not yet recognize Fortran-style comments.
! .IP "\fB\-D\fR\fIname\fR" 4
  .IX Item "-Dname"
  Predefine name as a macro, with definition \f(CW1\fR.
! .IP "\fB\-D\fR\fIname\fR\fB=\fR\fIdefinition\fR" 4
  .IX Item "-Dname=definition"
  The contents of \fIdefinition\fR are tokenized and processed as if they
  appeared during translation phase three in a \f(CW\*(Aq#define\*(Aq\fR directive.
  In particular, the definition will be truncated by embedded newline
  characters.
  .Sp
! If you are invoking the preprocessor from a shell or shell-like program
! you may need to use the shell's quoting syntax to protect characters such
  as spaces that have a meaning in the shell syntax.
  .Sp
! If you wish to define a function-like macro on the command line, write
  its argument list with surrounding parentheses before the equals sign
  (if any). Parentheses are meaningful to most shells, so you will need
  to quote the option. With sh and csh, \f(CW\*(C`\-D\*(Aqname(args...)=definition\*(Aq\*(C'\fR
--- 649,684 ----
  token on the line is no longer a \f(CW\*(Aq#\*(Aq\fR.
  .Sp
  Warning: this currently handles C\-Style comments only. The preprocessor
! does not yet recognize Fortran\-style comments.
! .IP \fB\-CC\fR 4
  .IX Item "-CC"
  Do not discard comments, including during macro expansion. This is like
  \&\fB\-C\fR, except that comments contained within macros are also passed
  through to the output file where the macro is expanded.
  .Sp
! In addition to the side\-effects of the \fB\-C\fR option, the \fB\-CC\fR
! option causes all C++\-style comments inside a macro to be converted to C\-style
  comments. This is to prevent later use of that macro from inadvertently
  commenting out the remainder of the source line. The \fB\-CC\fR option
  is generally used to support lint comments.
  .Sp
! Warning: this currently handles C\- and C++\-Style comments only. The
! preprocessor does not yet recognize Fortran\-style comments.
! .IP \fB\-D\fR\fIname\fR 4
  .IX Item "-Dname"
  Predefine name as a macro, with definition \f(CW1\fR.
! .IP \fB\-D\fR\fIname\fR\fB=\fR\fIdefinition\fR 4
  .IX Item "-Dname=definition"
  The contents of \fIdefinition\fR are tokenized and processed as if they
  appeared during translation phase three in a \f(CW\*(Aq#define\*(Aq\fR directive.
  In particular, the definition will be truncated by embedded newline
  characters.
  .Sp
! If you are invoking the preprocessor from a shell or shell\-like program
! you may need to use the shell\*(Aqs quoting syntax to protect characters such
  as spaces that have a meaning in the shell syntax.
  .Sp
! If you wish to define a function\-like macro on the command line, write
  its argument list with surrounding parentheses before the equals sign
  (if any). Parentheses are meaningful to most shells, so you will need
  to quote the option. With sh and csh, \f(CW\*(C`\-D\*(Aqname(args...)=definition\*(Aq\*(C'\fR
*************** works.
*** 762,785 ****
  \&\fB\-D\fR and \fB\-U\fR options are processed in the order they are
  given on the command line. All \-imacros file and \-include file options
  are processed after all \-D and \-U options.
! .IP "\fB\-H\fR" 4
  .IX Item "-H"
  Print the name of each header file used, in addition to other normal
  activities. Each name is indented to show how deep in the \f(CW\*(Aq#include\*(Aq\fR
  stack it is.
! .IP "\fB\-P\fR" 4
  .IX Item "-P"
  Inhibit generation of linemarkers in the output from the preprocessor.
  This might be useful when running the preprocessor on something that
  is not C code, and will be sent to a program which might be confused
  by the linemarkers.
! .IP "\fB\-U\fR\fIname\fR" 4
  .IX Item "-Uname"
  Cancel any previous definition of \fIname\fR, either built in or provided
  with a \fB\-D\fR option.
  .SS "Options to request or suppress errors and warnings"
  .IX Subsection "Options to request or suppress errors and warnings"
! Errors are diagnostic messages that report that the \s-1GNU\s0 Fortran compiler
  cannot compile the relevant piece of source code.  The compiler will
  continue to process the program in an attempt to report further errors
  to aid in debugging, but will not produce any compiled output.
--- 687,710 ----
  \&\fB\-D\fR and \fB\-U\fR options are processed in the order they are
  given on the command line. All \-imacros file and \-include file options
  are processed after all \-D and \-U options.
! .IP \fB\-H\fR 4
  .IX Item "-H"
  Print the name of each header file used, in addition to other normal
  activities. Each name is indented to show how deep in the \f(CW\*(Aq#include\*(Aq\fR
  stack it is.
! .IP \fB\-P\fR 4
  .IX Item "-P"
  Inhibit generation of linemarkers in the output from the preprocessor.
  This might be useful when running the preprocessor on something that
  is not C code, and will be sent to a program which might be confused
  by the linemarkers.
! .IP \fB\-U\fR\fIname\fR 4
  .IX Item "-Uname"
  Cancel any previous definition of \fIname\fR, either built in or provided
  with a \fB\-D\fR option.
  .SS "Options to request or suppress errors and warnings"
  .IX Subsection "Options to request or suppress errors and warnings"
! Errors are diagnostic messages that report that the GNU Fortran compiler
  cannot compile the relevant piece of source code.  The compiler will
  continue to process the program in an attempt to report further errors
  to aid in debugging, but will not produce any compiled output.
*************** for example, \fB\-Wno\-implicit\fR.  Thi
*** 797,843 ****
  two forms, whichever is not the default.
  .PP
  These options control the amount and kinds of errors and warnings produced
! by \s-1GNU\s0 Fortran:
! .IP "\fB\-fmax\-errors=\fR\fIn\fR" 4
  .IX Item "-fmax-errors=n"
  Limits the maximum number of error messages to \fIn\fR, at which point
! \&\s-1GNU\s0 Fortran bails out rather than attempting to continue processing the
  source code.  If \fIn\fR is 0, there is no limit on the number of error
  messages produced.
! .IP "\fB\-fsyntax\-only\fR" 4
  .IX Item "-fsyntax-only"
  Check the code for syntax errors, but do not actually compile it.  This
  will generate module files for each module present in the code, but no
  other output file.
! .IP "\fB\-Wpedantic\fR" 4
  .IX Item "-Wpedantic"
  .PD 0
! .IP "\fB\-pedantic\fR" 4
  .IX Item "-pedantic"
  .PD
  Issue warnings for uses of extensions to Fortran.
  \&\fB\-pedantic\fR also applies to C\-language constructs where they
! occur in \s-1GNU\s0 Fortran source files, such as use of \fB\ee\fR in a
  character constant within a directive like \f(CW\*(C`#include\*(C'\fR.
  .Sp
  Valid Fortran programs should compile properly with or without
  this option.
! However, without this option, certain \s-1GNU\s0 extensions and traditional
  Fortran features are supported as well.
  With this option, many of them are rejected.
  .Sp
  Some users try to use \fB\-pedantic\fR to check programs for conformance.
  They soon find that it does not do quite what they want\-\-\-it finds some
  nonstandard practices, but not all.
! However, improvements to \s-1GNU\s0 Fortran in this area are welcome.
  .Sp
  This should be used in conjunction with \fB\-std=f95\fR,
  \&\fB\-std=f2003\fR, \fB\-std=f2008\fR or \fB\-std=f2018\fR.
! .IP "\fB\-pedantic\-errors\fR" 4
  .IX Item "-pedantic-errors"
  Like \fB\-pedantic\fR, except that errors are produced rather than
  warnings.
! .IP "\fB\-Wall\fR" 4
  .IX Item "-Wall"
  Enables commonly used warning options pertaining to usage that
  we recommend avoiding and that we believe are easy to avoid.
--- 722,768 ----
  two forms, whichever is not the default.
  .PP
  These options control the amount and kinds of errors and warnings produced
! by GNU Fortran:
! .IP \fB\-fmax\-errors=\fR\fIn\fR 4
  .IX Item "-fmax-errors=n"
  Limits the maximum number of error messages to \fIn\fR, at which point
! GNU Fortran bails out rather than attempting to continue processing the
  source code.  If \fIn\fR is 0, there is no limit on the number of error
  messages produced.
! .IP \fB\-fsyntax\-only\fR 4
  .IX Item "-fsyntax-only"
  Check the code for syntax errors, but do not actually compile it.  This
  will generate module files for each module present in the code, but no
  other output file.
! .IP \fB\-Wpedantic\fR 4
  .IX Item "-Wpedantic"
  .PD 0
! .IP \fB\-pedantic\fR 4
  .IX Item "-pedantic"
  .PD
  Issue warnings for uses of extensions to Fortran.
  \&\fB\-pedantic\fR also applies to C\-language constructs where they
! occur in GNU Fortran source files, such as use of \fB\ee\fR in a
  character constant within a directive like \f(CW\*(C`#include\*(C'\fR.
  .Sp
  Valid Fortran programs should compile properly with or without
  this option.
! However, without this option, certain GNU extensions and traditional
  Fortran features are supported as well.
  With this option, many of them are rejected.
  .Sp
  Some users try to use \fB\-pedantic\fR to check programs for conformance.
  They soon find that it does not do quite what they want\-\-\-it finds some
  nonstandard practices, but not all.
! However, improvements to GNU Fortran in this area are welcome.
  .Sp
  This should be used in conjunction with \fB\-std=f95\fR,
  \&\fB\-std=f2003\fR, \fB\-std=f2008\fR or \fB\-std=f2018\fR.
! .IP \fB\-pedantic\-errors\fR 4
  .IX Item "-pedantic-errors"
  Like \fB\-pedantic\fR, except that errors are produced rather than
  warnings.
! .IP \fB\-Wall\fR 4
  .IX Item "-Wall"
  Enables commonly used warning options pertaining to usage that
  we recommend avoiding and that we believe are easy to avoid.
*************** This currently includes \fB\-Waliasing\f
*** 847,857 ****
  \&\fB\-Wline\-truncation\fR, \fB\-Wtarget\-lifetime\fR,
  \&\fB\-Winteger\-division\fR, \fB\-Wreal\-q\-constant\fR, \fB\-Wunused\fR
  and \fB\-Wundefined\-do\-loop\fR.
! .IP "\fB\-Waliasing\fR" 4
  .IX Item "-Waliasing"
  Warn about possible aliasing of dummy arguments. Specifically, it warns
  if the same actual argument is associated with a dummy argument with
! \&\f(CW\*(C`INTENT(IN)\*(C'\fR and a dummy argument with \f(CW\*(C`INTENT(OUT)\*(C'\fR in a call
  with an explicit interface.
  .Sp
  The following example will trigger the warning.
--- 772,782 ----
  \&\fB\-Wline\-truncation\fR, \fB\-Wtarget\-lifetime\fR,
  \&\fB\-Winteger\-division\fR, \fB\-Wreal\-q\-constant\fR, \fB\-Wunused\fR
  and \fB\-Wundefined\-do\-loop\fR.
! .IP \fB\-Waliasing\fR 4
  .IX Item "-Waliasing"
  Warn about possible aliasing of dummy arguments. Specifically, it warns
  if the same actual argument is associated with a dummy argument with
! \&\f(CWINTENT(IN)\fR and a dummy argument with \f(CWINTENT(OUT)\fR in a call
  with an explicit interface.
  .Sp
  The following example will trigger the warning.
*************** The following example will trigger the w
*** 867,977 ****
  \&        
  \&          call bar(a,a)
  .Ve
! .IP "\fB\-Wampersand\fR" 4
  .IX Item "-Wampersand"
  Warn about missing ampersand in continued character constants. The
  warning is given with \fB\-Wampersand\fR, \fB\-pedantic\fR,
  \&\fB\-std=f95\fR, \fB\-std=f2003\fR, \fB\-std=f2008\fR and
  \&\fB\-std=f2018\fR. Note: With no ampersand given in a continued
! character constant, \s-1GNU\s0 Fortran assumes continuation at the first
! non-comment, non-whitespace character after the ampersand that
  initiated the continuation.
! .IP "\fB\-Warray\-temporaries\fR" 4
  .IX Item "-Warray-temporaries"
  Warn about array temporaries generated by the compiler.  The information
  generated by this warning is sometimes useful in optimization, in order to
  avoid such temporaries.
! .IP "\fB\-Wc\-binding\-type\fR" 4
  .IX Item "-Wc-binding-type"
  Warn if the a variable might not be C interoperable.  In particular, warn if 
  the variable has been declared using an intrinsic type with default kind
  instead of using a kind parameter defined for C interoperability in the
  intrinsic \f(CW\*(C`ISO_C_Binding\*(C'\fR module.  This option is implied by
  \&\fB\-Wall\fR.
! .IP "\fB\-Wcharacter\-truncation\fR" 4
  .IX Item "-Wcharacter-truncation"
  Warn when a character assignment will truncate the assigned string.
! .IP "\fB\-Wline\-truncation\fR" 4
  .IX Item "-Wline-truncation"
  Warn when a source code line will be truncated.  This option is
! implied by \fB\-Wall\fR.  For free-form source code, the default is
  \&\fB\-Werror=line\-truncation\fR such that truncations are reported as
  error.
! .IP "\fB\-Wconversion\fR" 4
  .IX Item "-Wconversion"
  Warn about implicit conversions that are likely to change the value of 
  the expression after conversion. Implied by \fB\-Wall\fR.
! .IP "\fB\-Wconversion\-extra\fR" 4
  .IX Item "-Wconversion-extra"
  Warn about implicit conversions between different types and kinds. This
  option does \fInot\fR imply \fB\-Wconversion\fR.
! .IP "\fB\-Wextra\fR" 4
  .IX Item "-Wextra"
  Enables some warning options for usages of language features which
  may be problematic. This currently includes \fB\-Wcompare\-reals\fR,
  \&\fB\-Wunused\-parameter\fR and \fB\-Wdo\-subscript\fR.
! .IP "\fB\-Wfrontend\-loop\-interchange\fR" 4
  .IX Item "-Wfrontend-loop-interchange"
  Warn when using \fB\-ffrontend\-loop\-interchange\fR for performing loop
  interchanges.
! .IP "\fB\-Wimplicit\-interface\fR" 4
  .IX Item "-Wimplicit-interface"
  Warn if a procedure is called without an explicit interface.
  Note this only checks that an explicit interface is present.  It does not
  check that the declared interfaces are consistent across program units.
! .IP "\fB\-Wimplicit\-procedure\fR" 4
  .IX Item "-Wimplicit-procedure"
  Warn if a procedure is called that has neither an explicit interface
  nor has been declared as \f(CW\*(C`EXTERNAL\*(C'\fR.
! .IP "\fB\-Winteger\-division\fR" 4
  .IX Item "-Winteger-division"
  Warn if a constant integer division truncates its result.
  As an example, 3/5 evaluates to 0.
! .IP "\fB\-Wintrinsics\-std\fR" 4
  .IX Item "-Wintrinsics-std"
  Warn if \fBgfortran\fR finds a procedure named like an intrinsic not
  available in the currently selected standard (with \fB\-std\fR) and treats
  it as \f(CW\*(C`EXTERNAL\*(C'\fR procedure because of this.  \fB\-fall\-intrinsics\fR can
  be used to never trigger this behavior and always link to the intrinsic
  regardless of the selected standard.
! .IP "\fB\-Wno\-overwrite\-recursive\fR" 4
  .IX Item "-Wno-overwrite-recursive"
  Do not warn when \fB\-fno\-automatic\fR is used with \fB\-frecursive\fR. Recursion
  will be broken if the relevant local variables do not have the attribute
  \&\f(CW\*(C`AUTOMATIC\*(C'\fR explicitly declared. This option can be used to suppress the warning
  when it is known that recursion is not broken. Useful for build environments that use
  \&\fB\-Werror\fR.
! .IP "\fB\-Wreal\-q\-constant\fR" 4
  .IX Item "-Wreal-q-constant"
! Produce a warning if a real-literal-constant contains a \f(CW\*(C`q\*(C'\fR
! exponent-letter.
! .IP "\fB\-Wsurprising\fR" 4
  .IX Item "-Wsurprising"
! Produce a warning when \*(L"suspicious\*(R" code constructs are encountered.
  While technically legal these usually indicate that an error has been made.
  .Sp
  This currently produces a warning under the following circumstances:
  .RS 4
! .IP "*" 4
! An \s-1INTEGER SELECT\s0 construct has a \s-1CASE\s0 that can never be matched as its
  lower value is greater than its upper value.
! .IP "*" 4
! A \s-1LOGICAL SELECT\s0 construct has three \s-1CASE\s0 statements.
! .IP "*" 4
! A \s-1TRANSFER\s0 specifies a source that is shorter than the destination.
! .IP "*" 4
  The type of a function result is declared more than once with the same type.  If
! \&\fB\-pedantic\fR or standard-conforming mode is enabled, this is an error.
! .IP "*" 4
  A \f(CW\*(C`CHARACTER\*(C'\fR variable is declared with negative length.
! .IP "*" 4
! With \fB\-fopenmp\fR, for fixed-form source code, when an \f(CW\*(C`omx\*(C'\fR
! vendor-extension sentinel is encountered. (The equivalent \f(CW\*(C`ompx\*(C'\fR,
! used in free-form source code, is diagnosed by default.)
  .RE
  .RS 4
  .RE
! .IP "\fB\-Wtabs\fR" 4
  .IX Item "-Wtabs"
  By default, tabs are accepted as whitespace, but tabs are not members
  of the Fortran Character Set.  For continuation lines, a tab followed
--- 792,902 ----
  \&        
  \&          call bar(a,a)
  .Ve
! .IP \fB\-Wampersand\fR 4
  .IX Item "-Wampersand"
  Warn about missing ampersand in continued character constants. The
  warning is given with \fB\-Wampersand\fR, \fB\-pedantic\fR,
  \&\fB\-std=f95\fR, \fB\-std=f2003\fR, \fB\-std=f2008\fR and
  \&\fB\-std=f2018\fR. Note: With no ampersand given in a continued
! character constant, GNU Fortran assumes continuation at the first
! non\-comment, non\-whitespace character after the ampersand that
  initiated the continuation.
! .IP \fB\-Warray\-temporaries\fR 4
  .IX Item "-Warray-temporaries"
  Warn about array temporaries generated by the compiler.  The information
  generated by this warning is sometimes useful in optimization, in order to
  avoid such temporaries.
! .IP \fB\-Wc\-binding\-type\fR 4
  .IX Item "-Wc-binding-type"
  Warn if the a variable might not be C interoperable.  In particular, warn if 
  the variable has been declared using an intrinsic type with default kind
  instead of using a kind parameter defined for C interoperability in the
  intrinsic \f(CW\*(C`ISO_C_Binding\*(C'\fR module.  This option is implied by
  \&\fB\-Wall\fR.
! .IP \fB\-Wcharacter\-truncation\fR 4
  .IX Item "-Wcharacter-truncation"
  Warn when a character assignment will truncate the assigned string.
! .IP \fB\-Wline\-truncation\fR 4
  .IX Item "-Wline-truncation"
  Warn when a source code line will be truncated.  This option is
! implied by \fB\-Wall\fR.  For free\-form source code, the default is
  \&\fB\-Werror=line\-truncation\fR such that truncations are reported as
  error.
! .IP \fB\-Wconversion\fR 4
  .IX Item "-Wconversion"
  Warn about implicit conversions that are likely to change the value of 
  the expression after conversion. Implied by \fB\-Wall\fR.
! .IP \fB\-Wconversion\-extra\fR 4
  .IX Item "-Wconversion-extra"
  Warn about implicit conversions between different types and kinds. This
  option does \fInot\fR imply \fB\-Wconversion\fR.
! .IP \fB\-Wextra\fR 4
  .IX Item "-Wextra"
  Enables some warning options for usages of language features which
  may be problematic. This currently includes \fB\-Wcompare\-reals\fR,
  \&\fB\-Wunused\-parameter\fR and \fB\-Wdo\-subscript\fR.
! .IP \fB\-Wfrontend\-loop\-interchange\fR 4
  .IX Item "-Wfrontend-loop-interchange"
  Warn when using \fB\-ffrontend\-loop\-interchange\fR for performing loop
  interchanges.
! .IP \fB\-Wimplicit\-interface\fR 4
  .IX Item "-Wimplicit-interface"
  Warn if a procedure is called without an explicit interface.
  Note this only checks that an explicit interface is present.  It does not
  check that the declared interfaces are consistent across program units.
! .IP \fB\-Wimplicit\-procedure\fR 4
  .IX Item "-Wimplicit-procedure"
  Warn if a procedure is called that has neither an explicit interface
  nor has been declared as \f(CW\*(C`EXTERNAL\*(C'\fR.
! .IP \fB\-Winteger\-division\fR 4
  .IX Item "-Winteger-division"
  Warn if a constant integer division truncates its result.
  As an example, 3/5 evaluates to 0.
! .IP \fB\-Wintrinsics\-std\fR 4
  .IX Item "-Wintrinsics-std"
  Warn if \fBgfortran\fR finds a procedure named like an intrinsic not
  available in the currently selected standard (with \fB\-std\fR) and treats
  it as \f(CW\*(C`EXTERNAL\*(C'\fR procedure because of this.  \fB\-fall\-intrinsics\fR can
  be used to never trigger this behavior and always link to the intrinsic
  regardless of the selected standard.
! .IP \fB\-Wno\-overwrite\-recursive\fR 4
  .IX Item "-Wno-overwrite-recursive"
  Do not warn when \fB\-fno\-automatic\fR is used with \fB\-frecursive\fR. Recursion
  will be broken if the relevant local variables do not have the attribute
  \&\f(CW\*(C`AUTOMATIC\*(C'\fR explicitly declared. This option can be used to suppress the warning
  when it is known that recursion is not broken. Useful for build environments that use
  \&\fB\-Werror\fR.
! .IP \fB\-Wreal\-q\-constant\fR 4
  .IX Item "-Wreal-q-constant"
! Produce a warning if a real\-literal\-constant contains a \f(CW\*(C`q\*(C'\fR
! exponent\-letter.
! .IP \fB\-Wsurprising\fR 4
  .IX Item "-Wsurprising"
! Produce a warning when "suspicious" code constructs are encountered.
  While technically legal these usually indicate that an error has been made.
  .Sp
  This currently produces a warning under the following circumstances:
  .RS 4
! .IP * 4
! An INTEGER SELECT construct has a CASE that can never be matched as its
  lower value is greater than its upper value.
! .IP * 4
! A LOGICAL SELECT construct has three CASE statements.
! .IP * 4
! A TRANSFER specifies a source that is shorter than the destination.
! .IP * 4
  The type of a function result is declared more than once with the same type.  If
! \&\fB\-pedantic\fR or standard\-conforming mode is enabled, this is an error.
! .IP * 4
  A \f(CW\*(C`CHARACTER\*(C'\fR variable is declared with negative length.
! .IP * 4
! With \fB\-fopenmp\fR, for fixed\-form source code, when an \f(CW\*(C`omx\*(C'\fR
! vendor\-extension sentinel is encountered. (The equivalent \f(CW\*(C`ompx\*(C'\fR,
! used in free\-form source code, is diagnosed by default.)
  .RE
  .RS 4
  .RE
! .IP \fB\-Wtabs\fR 4
  .IX Item "-Wtabs"
  By default, tabs are accepted as whitespace, but tabs are not members
  of the Fortran Character Set.  For continuation lines, a tab followed
*************** warning to be issued if a tab is encount
*** 980,1056 ****
  active for \fB\-pedantic\fR, \fB\-std=f95\fR, \fB\-std=f2003\fR,
  \&\fB\-std=f2008\fR, \fB\-std=f2018\fR and
  \&\fB\-Wall\fR.
! .IP "\fB\-Wundefined\-do\-loop\fR" 4
  .IX Item "-Wundefined-do-loop"
! Warn if a \s-1DO\s0 loop with step either 1 or \-1 yields an underflow or an overflow
  during iteration of an induction variable of the loop.
  This option is implied by \fB\-Wall\fR.
! .IP "\fB\-Wunderflow\fR" 4
  .IX Item "-Wunderflow"
  Produce a warning when numerical constant expressions are
! encountered, which yield an \s-1UNDERFLOW\s0 during compilation. Enabled by default.
! .IP "\fB\-Wintrinsic\-shadow\fR" 4
  .IX Item "-Wintrinsic-shadow"
! Warn if a user-defined procedure or module procedure has the same name as an
  intrinsic; in this case, an explicit interface or \f(CW\*(C`EXTERNAL\*(C'\fR or
  \&\f(CW\*(C`INTRINSIC\*(C'\fR declaration might be needed to get calls later resolved to
  the desired intrinsic/procedure.  This option is implied by \fB\-Wall\fR.
! .IP "\fB\-Wuse\-without\-only\fR" 4
  .IX Item "-Wuse-without-only"
  Warn if a \f(CW\*(C`USE\*(C'\fR statement has no \f(CW\*(C`ONLY\*(C'\fR qualifier and 
  thus implicitly imports all public entities of the used module.
! .IP "\fB\-Wunused\-dummy\-argument\fR" 4
  .IX Item "-Wunused-dummy-argument"
  Warn about unused dummy arguments. This option is implied by \fB\-Wall\fR.
! .IP "\fB\-Wunused\-parameter\fR" 4
  .IX Item "-Wunused-parameter"
! Contrary to \fBgcc\fR's meaning of \fB\-Wunused\-parameter\fR,
! \&\fBgfortran\fR's implementation of this option does not warn
  about unused dummy arguments (see \fB\-Wunused\-dummy\-argument\fR),
  but about unused \f(CW\*(C`PARAMETER\*(C'\fR values. \fB\-Wunused\-parameter\fR
  is implied by \fB\-Wextra\fR if also \fB\-Wunused\fR or
  \&\fB\-Wall\fR is used.
! .IP "\fB\-Walign\-commons\fR" 4
  .IX Item "-Walign-commons"
  By default, \fBgfortran\fR warns about any occasion of variables being
  padded for proper alignment inside a \f(CW\*(C`COMMON\*(C'\fR block. This warning can be turned
  off via \fB\-Wno\-align\-commons\fR. See also \fB\-falign\-commons\fR.
! .IP "\fB\-Wfunction\-elimination\fR" 4
  .IX Item "-Wfunction-elimination"
  Warn if any calls to impure functions are eliminated by the optimizations
  enabled by the \fB\-ffrontend\-optimize\fR option.
  This option is implied by \fB\-Wextra\fR.
! .IP "\fB\-Wrealloc\-lhs\fR" 4
  .IX Item "-Wrealloc-lhs"
  Warn when the compiler might insert code to for allocation or reallocation of
  an allocatable array variable of intrinsic type in intrinsic assignments.  In
  hot loops, the Fortran 2003 reallocation feature may reduce the performance.
  If the array is already allocated with the correct shape, consider using a
! whole-array array-spec (e.g. \f(CW\*(C`(:,:,:)\*(C'\fR) for the variable on the left-hand
  side to prevent the reallocation check. Note that in some cases the warning
  is shown, even if the compiler will optimize reallocation checks away.  For
! instance, when the right-hand side contains the same variable multiplied by
  a scalar.  See also \fB\-frealloc\-lhs\fR.
! .IP "\fB\-Wrealloc\-lhs\-all\fR" 4
  .IX Item "-Wrealloc-lhs-all"
  Warn when the compiler inserts code to for allocation or reallocation of an
  allocatable variable; this includes scalars and derived types.
! .IP "\fB\-Wcompare\-reals\fR" 4
  .IX Item "-Wcompare-reals"
  Warn when comparing real or complex types for equality or inequality.
  This option is implied by \fB\-Wextra\fR.
! .IP "\fB\-Wtarget\-lifetime\fR" 4
  .IX Item "-Wtarget-lifetime"
  Warn if the pointer in a pointer assignment might be longer than the its
  target. This option is implied by \fB\-Wall\fR.
! .IP "\fB\-Wzerotrip\fR" 4
  .IX Item "-Wzerotrip"
  Warn if a \f(CW\*(C`DO\*(C'\fR loop is known to execute zero times at compile
  time.  This option is implied by \fB\-Wall\fR.
! .IP "\fB\-Wdo\-subscript\fR" 4
  .IX Item "-Wdo-subscript"
! Warn if an array subscript inside a \s-1DO\s0 loop could lead to an
! out-of-bounds access even if the compiler cannot prove that the
  statement is actually executed, in cases like
  .Sp
  .Vb 6
--- 905,981 ----
  active for \fB\-pedantic\fR, \fB\-std=f95\fR, \fB\-std=f2003\fR,
  \&\fB\-std=f2008\fR, \fB\-std=f2018\fR and
  \&\fB\-Wall\fR.
! .IP \fB\-Wundefined\-do\-loop\fR 4
  .IX Item "-Wundefined-do-loop"
! Warn if a DO loop with step either 1 or \-1 yields an underflow or an overflow
  during iteration of an induction variable of the loop.
  This option is implied by \fB\-Wall\fR.
! .IP \fB\-Wunderflow\fR 4
  .IX Item "-Wunderflow"
  Produce a warning when numerical constant expressions are
! encountered, which yield an UNDERFLOW during compilation. Enabled by default.
! .IP \fB\-Wintrinsic\-shadow\fR 4
  .IX Item "-Wintrinsic-shadow"
! Warn if a user\-defined procedure or module procedure has the same name as an
  intrinsic; in this case, an explicit interface or \f(CW\*(C`EXTERNAL\*(C'\fR or
  \&\f(CW\*(C`INTRINSIC\*(C'\fR declaration might be needed to get calls later resolved to
  the desired intrinsic/procedure.  This option is implied by \fB\-Wall\fR.
! .IP \fB\-Wuse\-without\-only\fR 4
  .IX Item "-Wuse-without-only"
  Warn if a \f(CW\*(C`USE\*(C'\fR statement has no \f(CW\*(C`ONLY\*(C'\fR qualifier and 
  thus implicitly imports all public entities of the used module.
! .IP \fB\-Wunused\-dummy\-argument\fR 4
  .IX Item "-Wunused-dummy-argument"
  Warn about unused dummy arguments. This option is implied by \fB\-Wall\fR.
! .IP \fB\-Wunused\-parameter\fR 4
  .IX Item "-Wunused-parameter"
! Contrary to \fBgcc\fR\*(Aqs meaning of \fB\-Wunused\-parameter\fR,
! \&\fBgfortran\fR\*(Aqs implementation of this option does not warn
  about unused dummy arguments (see \fB\-Wunused\-dummy\-argument\fR),
  but about unused \f(CW\*(C`PARAMETER\*(C'\fR values. \fB\-Wunused\-parameter\fR
  is implied by \fB\-Wextra\fR if also \fB\-Wunused\fR or
  \&\fB\-Wall\fR is used.
! .IP \fB\-Walign\-commons\fR 4
  .IX Item "-Walign-commons"
  By default, \fBgfortran\fR warns about any occasion of variables being
  padded for proper alignment inside a \f(CW\*(C`COMMON\*(C'\fR block. This warning can be turned
  off via \fB\-Wno\-align\-commons\fR. See also \fB\-falign\-commons\fR.
! .IP \fB\-Wfunction\-elimination\fR 4
  .IX Item "-Wfunction-elimination"
  Warn if any calls to impure functions are eliminated by the optimizations
  enabled by the \fB\-ffrontend\-optimize\fR option.
  This option is implied by \fB\-Wextra\fR.
! .IP \fB\-Wrealloc\-lhs\fR 4
  .IX Item "-Wrealloc-lhs"
  Warn when the compiler might insert code to for allocation or reallocation of
  an allocatable array variable of intrinsic type in intrinsic assignments.  In
  hot loops, the Fortran 2003 reallocation feature may reduce the performance.
  If the array is already allocated with the correct shape, consider using a
! whole\-array array\-spec (e.g. \f(CW\*(C`(:,:,:)\*(C'\fR) for the variable on the left\-hand
  side to prevent the reallocation check. Note that in some cases the warning
  is shown, even if the compiler will optimize reallocation checks away.  For
! instance, when the right\-hand side contains the same variable multiplied by
  a scalar.  See also \fB\-frealloc\-lhs\fR.
! .IP \fB\-Wrealloc\-lhs\-all\fR 4
  .IX Item "-Wrealloc-lhs-all"
  Warn when the compiler inserts code to for allocation or reallocation of an
  allocatable variable; this includes scalars and derived types.
! .IP \fB\-Wcompare\-reals\fR 4
  .IX Item "-Wcompare-reals"
  Warn when comparing real or complex types for equality or inequality.
  This option is implied by \fB\-Wextra\fR.
! .IP \fB\-Wtarget\-lifetime\fR 4
  .IX Item "-Wtarget-lifetime"
  Warn if the pointer in a pointer assignment might be longer than the its
  target. This option is implied by \fB\-Wall\fR.
! .IP \fB\-Wzerotrip\fR 4
  .IX Item "-Wzerotrip"
  Warn if a \f(CW\*(C`DO\*(C'\fR loop is known to execute zero times at compile
  time.  This option is implied by \fB\-Wall\fR.
! .IP \fB\-Wdo\-subscript\fR 4
  .IX Item "-Wdo-subscript"
! Warn if an array subscript inside a DO loop could lead to an
! out\-of\-bounds access even if the compiler cannot prove that the
  statement is actually executed, in cases like
  .Sp
  .Vb 6
*************** statement is actually executed, in cases
*** 1063,1130 ****
  .Ve
  .Sp
  This option is implied by \fB\-Wextra\fR.
! .IP "\fB\-Werror\fR" 4
  .IX Item "-Werror"
  Turns all warnings into errors.
  .PP
  Some of these have no effect when compiling programs written in Fortran.
! .SS "Options for debugging your program or \s-1GNU\s0 Fortran"
  .IX Subsection "Options for debugging your program or GNU Fortran"
! \&\s-1GNU\s0 Fortran has various special options that are used for debugging
! either your program or the \s-1GNU\s0 Fortran compiler.
! .IP "\fB\-fdump\-fortran\-original\fR" 4
  .IX Item "-fdump-fortran-original"
  Output the internal parse tree after translating the source program
  into internal representation.  This option is mostly useful for
! debugging the \s-1GNU\s0 Fortran compiler itself. The output generated by
  this option might change between releases. This option may also
  generate internal compiler errors for features which have only
  recently been added.
! .IP "\fB\-fdump\-fortran\-optimized\fR" 4
  .IX Item "-fdump-fortran-optimized"
! Output the parse tree after front-end optimization.  Mostly useful for
! debugging the \s-1GNU\s0 Fortran compiler itself. The output generated by
  this option might change between releases.  This option may also
  generate internal compiler errors for features which have only
  recently been added.
! .IP "\fB\-fdump\-parse\-tree\fR" 4
  .IX Item "-fdump-parse-tree"
  Output the internal parse tree after translating the source program
! into internal representation.  Mostly useful for debugging the \s-1GNU\s0
  Fortran compiler itself. The output generated by this option might
  change between releases. This option may also generate internal
  compiler errors for features which have only recently been added. This
  option is deprecated; use \f(CW\*(C`\-fdump\-fortran\-original\*(C'\fR instead.
! .IP "\fB\-fdebug\-aux\-vars\fR" 4
  .IX Item "-fdebug-aux-vars"
  Renames internal variables created by the gfortran front end and makes
  them accessible to a debugger.  The name of the internal variables then
! start with upper-case letters followed by an underscore.  This option is
! useful for debugging the compiler's code generation together with
  \&\f(CW\*(C`\-fdump\-tree\-original\*(C'\fR and enabling debugging of the executable
  program by using \f(CW\*(C`\-g\*(C'\fR or \f(CW\*(C`\-ggdb3\*(C'\fR.
! .IP "\fB\-fdump\-fortran\-global\fR" 4
  .IX Item "-fdump-fortran-global"
  Output a list of the global identifiers after translating into
! middle-end representation. Mostly useful for debugging the \s-1GNU\s0 Fortran
  compiler itself. The output generated by this option might change
  between releases.  This option may also generate internal compiler
  errors for features which have only recently been added.
! .IP "\fB\-ffpe\-trap=\fR\fIlist\fR" 4
  .IX Item "-ffpe-trap=list"
  Specify a list of floating point exception traps to enable.  On most
  systems, if a floating point exception occurs and the trap for that
! exception is enabled, a \s-1SIGFPE\s0 signal will be sent and the program
  being aborted, producing a core file useful for debugging.  \fIlist\fR
! is a (possibly empty) comma-separated list of the following
  exceptions: \fBinvalid\fR (invalid floating point operation, such as
! \&\f(CW\*(C`SQRT(\-1.0)\*(C'\fR), \fBzero\fR (division by zero), \fBoverflow\fR
  (overflow in a floating point operation), \fBunderflow\fR (underflow
  in a floating point operation), \fBinexact\fR (loss of precision
  during operation), and \fBdenormal\fR (operation performed on a
  denormal value).  The first five exceptions correspond to the five
! \&\s-1IEEE 754\s0 exceptions, whereas the last one (\fBdenormal\fR) is not
! part of the \s-1IEEE 754\s0 standard but is available on some common
  architectures such as x86.
  .Sp
  The first three exceptions (\fBinvalid\fR, \fBzero\fR, and
--- 988,1055 ----
  .Ve
  .Sp
  This option is implied by \fB\-Wextra\fR.
! .IP \fB\-Werror\fR 4
  .IX Item "-Werror"
  Turns all warnings into errors.
  .PP
  Some of these have no effect when compiling programs written in Fortran.
! .SS "Options for debugging your program or GNU Fortran"
  .IX Subsection "Options for debugging your program or GNU Fortran"
! GNU Fortran has various special options that are used for debugging
! either your program or the GNU Fortran compiler.
! .IP \fB\-fdump\-fortran\-original\fR 4
  .IX Item "-fdump-fortran-original"
  Output the internal parse tree after translating the source program
  into internal representation.  This option is mostly useful for
! debugging the GNU Fortran compiler itself. The output generated by
  this option might change between releases. This option may also
  generate internal compiler errors for features which have only
  recently been added.
! .IP \fB\-fdump\-fortran\-optimized\fR 4
  .IX Item "-fdump-fortran-optimized"
! Output the parse tree after front\-end optimization.  Mostly useful for
! debugging the GNU Fortran compiler itself. The output generated by
  this option might change between releases.  This option may also
  generate internal compiler errors for features which have only
  recently been added.
! .IP \fB\-fdump\-parse\-tree\fR 4
  .IX Item "-fdump-parse-tree"
  Output the internal parse tree after translating the source program
! into internal representation.  Mostly useful for debugging the GNU
  Fortran compiler itself. The output generated by this option might
  change between releases. This option may also generate internal
  compiler errors for features which have only recently been added. This
  option is deprecated; use \f(CW\*(C`\-fdump\-fortran\-original\*(C'\fR instead.
! .IP \fB\-fdebug\-aux\-vars\fR 4
  .IX Item "-fdebug-aux-vars"
  Renames internal variables created by the gfortran front end and makes
  them accessible to a debugger.  The name of the internal variables then
! start with upper\-case letters followed by an underscore.  This option is
! useful for debugging the compiler\*(Aqs code generation together with
  \&\f(CW\*(C`\-fdump\-tree\-original\*(C'\fR and enabling debugging of the executable
  program by using \f(CW\*(C`\-g\*(C'\fR or \f(CW\*(C`\-ggdb3\*(C'\fR.
! .IP \fB\-fdump\-fortran\-global\fR 4
  .IX Item "-fdump-fortran-global"
  Output a list of the global identifiers after translating into
! middle\-end representation. Mostly useful for debugging the GNU Fortran
  compiler itself. The output generated by this option might change
  between releases.  This option may also generate internal compiler
  errors for features which have only recently been added.
! .IP \fB\-ffpe\-trap=\fR\fIlist\fR 4
  .IX Item "-ffpe-trap=list"
  Specify a list of floating point exception traps to enable.  On most
  systems, if a floating point exception occurs and the trap for that
! exception is enabled, a SIGFPE signal will be sent and the program
  being aborted, producing a core file useful for debugging.  \fIlist\fR
! is a (possibly empty) comma\-separated list of the following
  exceptions: \fBinvalid\fR (invalid floating point operation, such as
! \&\f(CWSQRT(\-1.0)\fR), \fBzero\fR (division by zero), \fBoverflow\fR
  (overflow in a floating point operation), \fBunderflow\fR (underflow
  in a floating point operation), \fBinexact\fR (loss of precision
  during operation), and \fBdenormal\fR (operation performed on a
  denormal value).  The first five exceptions correspond to the five
! IEEE 754 exceptions, whereas the last one (\fBdenormal\fR) is not
! part of the IEEE 754 standard but is available on some common
  architectures such as x86.
  .Sp
  The first three exceptions (\fBinvalid\fR, \fBzero\fR, and
*************** has provisions for dealing with these ex
*** 1133,1139 ****
  these three exceptions is probably a good idea.
  .Sp
  If the option is used more than once in the command line, the lists will
! be joined: '\f(CW\*(C`ffpe\-trap=\*(C'\fR\fIlist1\fR \f(CW\*(C`ffpe\-trap=\*(C'\fR\fIlist2\fR'
  is equivalent to \f(CW\*(C`ffpe\-trap=\*(C'\fR\fIlist1\fR,\fIlist2\fR.
  .Sp
  Note that once enabled an exception cannot be disabled (no negative form).
--- 1058,1064 ----
  these three exceptions is probably a good idea.
  .Sp
  If the option is used more than once in the command line, the lists will
! be joined: \*(Aq\f(CW\*(C`ffpe\-trap=\*(C'\fR\fIlist1\fR \f(CW\*(C`ffpe\-trap=\*(C'\fR\fIlist2\fR\*(Aq
  is equivalent to \f(CW\*(C`ffpe\-trap=\*(C'\fR\fIlist1\fR,\fIlist2\fR.
  .Sp
  Note that once enabled an exception cannot be disabled (no negative form).
*************** due to rounding, and hence the \f(CW\*(C
*** 1143,1153 ****
  be uninteresting in practice.
  .Sp
  By default no exception traps are enabled.
! .IP "\fB\-ffpe\-summary=\fR\fIlist\fR" 4
  .IX Item "-ffpe-summary=list"
! Specify a list of floating-point exceptions, whose flag status is printed
  to \f(CW\*(C`ERROR_UNIT\*(C'\fR when invoking \f(CW\*(C`STOP\*(C'\fR and \f(CW\*(C`ERROR STOP\*(C'\fR.
! \&\fIlist\fR can be either \fBnone\fR, \fBall\fR or a comma-separated list
  of the following exceptions: \fBinvalid\fR, \fBzero\fR, \fBoverflow\fR,
  \&\fBunderflow\fR, \fBinexact\fR and \fBdenormal\fR. (See
  \&\fB\-ffpe\-trap\fR for a description of the exceptions.)
--- 1068,1078 ----
  be uninteresting in practice.
  .Sp
  By default no exception traps are enabled.
! .IP \fB\-ffpe\-summary=\fR\fIlist\fR 4
  .IX Item "-ffpe-summary=list"
! Specify a list of floating\-point exceptions, whose flag status is printed
  to \f(CW\*(C`ERROR_UNIT\*(C'\fR when invoking \f(CW\*(C`STOP\*(C'\fR and \f(CW\*(C`ERROR STOP\*(C'\fR.
! \&\fIlist\fR can be either \fBnone\fR, \fBall\fR or a comma\-separated list
  of the following exceptions: \fBinvalid\fR, \fBzero\fR, \fBoverflow\fR,
  \&\fBunderflow\fR, \fBinexact\fR and \fBdenormal\fR. (See
  \&\fB\-ffpe\-trap\fR for a description of the exceptions.)
*************** If the option is used more than once in
*** 1156,1179 ****
  last one will be used.
  .Sp
  By default, a summary for all exceptions but \fBinexact\fR is shown.
! .IP "\fB\-fno\-backtrace\fR" 4
  .IX Item "-fno-backtrace"
  When a serious runtime error is encountered or a deadly signal is
  emitted (segmentation fault, illegal instruction, bus error,
! floating-point exception, and the other \s-1POSIX\s0 signals that have the
  action \fBcore\fR), the Fortran runtime library tries to output a
  backtrace of the error. \f(CW\*(C`\-fno\-backtrace\*(C'\fR disables the backtrace
  generation. This option only has influence for compilation of the
  Fortran main program.
  .SS "Options for directory search"
  .IX Subsection "Options for directory search"
! These options affect how \s-1GNU\s0 Fortran searches
  for files specified by the \f(CW\*(C`INCLUDE\*(C'\fR directive and where it searches
  for previously compiled modules.
  .PP
  It also affects the search paths used by \fBcpp\fR when used to preprocess
  Fortran source.
! .IP "\fB\-I\fR\fIdir\fR" 4
  .IX Item "-Idir"
  These affect interpretation of the \f(CW\*(C`INCLUDE\*(C'\fR directive
  (as well as of the \f(CW\*(C`#include\*(C'\fR directive of the \fBcpp\fR
--- 1081,1104 ----
  last one will be used.
  .Sp
  By default, a summary for all exceptions but \fBinexact\fR is shown.
! .IP \fB\-fno\-backtrace\fR 4
  .IX Item "-fno-backtrace"
  When a serious runtime error is encountered or a deadly signal is
  emitted (segmentation fault, illegal instruction, bus error,
! floating\-point exception, and the other POSIX signals that have the
  action \fBcore\fR), the Fortran runtime library tries to output a
  backtrace of the error. \f(CW\*(C`\-fno\-backtrace\*(C'\fR disables the backtrace
  generation. This option only has influence for compilation of the
  Fortran main program.
  .SS "Options for directory search"
  .IX Subsection "Options for directory search"
! These options affect how GNU Fortran searches
  for files specified by the \f(CW\*(C`INCLUDE\*(C'\fR directive and where it searches
  for previously compiled modules.
  .PP
  It also affects the search paths used by \fBcpp\fR when used to preprocess
  Fortran source.
! .IP \fB\-I\fR\fIdir\fR 4
  .IX Item "-Idir"
  These affect interpretation of the \f(CW\*(C`INCLUDE\*(C'\fR directive
  (as well as of the \f(CW\*(C`#include\*(C'\fR directive of the \fBcpp\fR
*************** looking for \fIheader.gcc\fR files and o
*** 1186,1192 ****
  .Sp
  This path is also used to search for \fI.mod\fR files when previously
  compiled modules are required by a \f(CW\*(C`USE\*(C'\fR statement.
! .IP "\fB\-J\fR\fIdir\fR" 4
  .IX Item "-Jdir"
  This option specifies where to put \fI.mod\fR files for compiled modules.
  It is also added to the list of directories to searched by an \f(CW\*(C`USE\*(C'\fR
--- 1111,1117 ----
  .Sp
  This path is also used to search for \fI.mod\fR files when previously
  compiled modules are required by a \f(CW\*(C`USE\*(C'\fR statement.
! .IP \fB\-J\fR\fIdir\fR 4
  .IX Item "-Jdir"
  This option specifies where to put \fI.mod\fR files for compiled modules.
  It is also added to the list of directories to searched by an \f(CW\*(C`USE\*(C'\fR
*************** statement.
*** 1195,1214 ****
  The default is the current directory.
  .IP "\fB\-fintrinsic\-modules\-path\fR \fIdir\fR" 4
  .IX Item "-fintrinsic-modules-path dir"
! This option specifies the location of pre-compiled intrinsic modules, if
  they are not in the default location expected by the compiler.
  .SS "Influencing the linking step"
  .IX Subsection "Influencing the linking step"
  These options come into play when the compiler links object files into an 
  executable output file. They are meaningless if the compiler is not doing 
  a link step.
! .IP "\fB\-static\-libgfortran\fR" 4
  .IX Item "-static-libgfortran"
  On systems that provide \fIlibgfortran\fR as a shared and a static
  library, this option forces the use of the static version. If no
  shared version of \fIlibgfortran\fR was built when the compiler was
  configured, this option has no effect.
! .IP "\fB\-static\-libquadmath\fR" 4
  .IX Item "-static-libquadmath"
  On systems that provide \fIlibquadmath\fR as a shared and a static
  library, this option forces the use of the static version. If no
--- 1120,1139 ----
  The default is the current directory.
  .IP "\fB\-fintrinsic\-modules\-path\fR \fIdir\fR" 4
  .IX Item "-fintrinsic-modules-path dir"
! This option specifies the location of pre\-compiled intrinsic modules, if
  they are not in the default location expected by the compiler.
  .SS "Influencing the linking step"
  .IX Subsection "Influencing the linking step"
  These options come into play when the compiler links object files into an 
  executable output file. They are meaningless if the compiler is not doing 
  a link step.
! .IP \fB\-static\-libgfortran\fR 4
  .IX Item "-static-libgfortran"
  On systems that provide \fIlibgfortran\fR as a shared and a static
  library, this option forces the use of the static version. If no
  shared version of \fIlibgfortran\fR was built when the compiler was
  configured, this option has no effect.
! .IP \fB\-static\-libquadmath\fR 4
  .IX Item "-static-libquadmath"
  On systems that provide \fIlibquadmath\fR as a shared and a static
  library, this option forces the use of the static version. If no
*************** shared version of \fIlibquadmath\fR was
*** 1216,1254 ****
  configured, this option has no effect.
  .Sp
  Please note that the \fIlibquadmath\fR runtime library is licensed under the
! \&\s-1GNU\s0 Lesser General Public License (\s-1LGPL\s0), and linking it statically introduces
  requirements when redistributing the resulting binaries.
  .SS "Influencing runtime behavior"
  .IX Subsection "Influencing runtime behavior"
! These options affect the runtime behavior of programs compiled with \s-1GNU\s0 Fortran.
! .IP "\fB\-fconvert=\fR\fIconversion\fR" 4
  .IX Item "-fconvert=conversion"
  Specify the representation of data for unformatted files.  Valid
  values for conversion on most systems are: \fBnative\fR, the default;
! \&\fBswap\fR, swap between big\- and little-endian; \fBbig-endian\fR, use
! big-endian representation for unformatted files; \fBlittle-endian\fR, use
! little-endian representation for unformatted files.
  .Sp
! On \s-1POWER\s0 systems which suppport \fB\-mabi=ieeelongdouble\fR,
  there are additional options, which can be combined with others with
  commas.  Those are
  .RS 4
! .ie n .IP "@w<\fB\-fconvert=r16_ieee\fR Use \s-1IEEE\s0 128\-bit format for>" 4
! .el .IP "\f(CW@w\fR<\fB\-fconvert=r16_ieee\fR Use \s-1IEEE\s0 128\-bit format for>" 4
  .IX Item "@w<-fconvert=r16_ieee Use IEEE 128-bit format for>"
! \&\f(CW\*(C`REAL(KIND=16)\*(C'\fR.
! .ie n .IP "@w<\fB\-fconvert=r16_ibm\fR Use \s-1IBM\s0 long double format for>" 4
! .el .IP "\f(CW@w\fR<\fB\-fconvert=r16_ibm\fR Use \s-1IBM\s0 long double format for>" 4
  .IX Item "@w<-fconvert=r16_ibm Use IBM long double format for>"
! \&\f(CW\*(C`REAL(KIND=16)\*(C'\fR.
  .RE
  .RS 4
  .Sp
  \&\fIThis option has an effect only when used in the main program.
! The \f(CI\*(C`CONVERT\*(C'\fI specifier and the \s-1GFORTRAN_CONVERT_UNIT\s0 environment
! variable override the default specified by \f(BI\-fconvert\fI.\fR
  .RE
! .IP "\fB\-frecord\-marker=\fR\fIlength\fR" 4
  .IX Item "-frecord-marker=length"
  Specify the length of record markers for unformatted files.
  Valid values for \fIlength\fR are 4 and 8.  Default is 4.
--- 1141,1179 ----
  configured, this option has no effect.
  .Sp
  Please note that the \fIlibquadmath\fR runtime library is licensed under the
! GNU Lesser General Public License (LGPL), and linking it statically introduces
  requirements when redistributing the resulting binaries.
  .SS "Influencing runtime behavior"
  .IX Subsection "Influencing runtime behavior"
! These options affect the runtime behavior of programs compiled with GNU Fortran.
! .IP \fB\-fconvert=\fR\fIconversion\fR 4
  .IX Item "-fconvert=conversion"
  Specify the representation of data for unformatted files.  Valid
  values for conversion on most systems are: \fBnative\fR, the default;
! \&\fBswap\fR, swap between big\- and little\-endian; \fBbig\-endian\fR, use
! big\-endian representation for unformatted files; \fBlittle\-endian\fR, use
! little\-endian representation for unformatted files.
  .Sp
! On POWER systems which suppport \fB\-mabi=ieeelongdouble\fR,
  there are additional options, which can be combined with others with
  commas.  Those are
  .RS 4
! .ie n .IP "@w<\fB\-fconvert=r16_ieee\fR Use IEEE 128\-bit format for>" 4
! .el .IP "\f(CW@w\fR<\fB\-fconvert=r16_ieee\fR Use IEEE 128\-bit format for>" 4
  .IX Item "@w<-fconvert=r16_ieee Use IEEE 128-bit format for>"
! \&\f(CWREAL(KIND=16)\fR.
! .ie n .IP "@w<\fB\-fconvert=r16_ibm\fR Use IBM long double format for>" 4
! .el .IP "\f(CW@w\fR<\fB\-fconvert=r16_ibm\fR Use IBM long double format for>" 4
  .IX Item "@w<-fconvert=r16_ibm Use IBM long double format for>"
! \&\f(CWREAL(KIND=16)\fR.
  .RE
  .RS 4
  .Sp
  \&\fIThis option has an effect only when used in the main program.
! The \fR\f(CI\*(C`CONVERT\*(C'\fR\fI specifier and the GFORTRAN_CONVERT_UNIT environment
! variable override the default specified by \fR\f(BI\-fconvert\fR\fI.\fR
  .RE
! .IP \fB\-frecord\-marker=\fR\fIlength\fR 4
  .IX Item "-frecord-marker=length"
  Specify the length of record markers for unformatted files.
  Valid values for \fIlength\fR are 4 and 8.  Default is 4.
*************** Valid values for \fIlength\fR are 4 and
*** 1256,1267 ****
  which specified a default record marker length of 8 on most
  systems.  If you want to read or write files compatible
  with earlier versions of \fBgfortran\fR, use \fB\-frecord\-marker=8\fR.
! .IP "\fB\-fmax\-subrecord\-length=\fR\fIlength\fR" 4
  .IX Item "-fmax-subrecord-length=length"
  Specify the maximum length for a subrecord.  The maximum permitted
  value for length is 2147483639, which is also the default.  Only
  really useful for use by the gfortran testsuite.
! .IP "\fB\-fsign\-zero\fR" 4
  .IX Item "-fsign-zero"
  When enabled, floating point numbers of value zero with the sign bit set
  are written as negative number in formatted output and treated as
--- 1181,1192 ----
  which specified a default record marker length of 8 on most
  systems.  If you want to read or write files compatible
  with earlier versions of \fBgfortran\fR, use \fB\-frecord\-marker=8\fR.
! .IP \fB\-fmax\-subrecord\-length=\fR\fIlength\fR 4
  .IX Item "-fmax-subrecord-length=length"
  Specify the maximum length for a subrecord.  The maximum permitted
  value for length is 2147483639, which is also the default.  Only
  really useful for use by the gfortran testsuite.
! .IP \fB\-fsign\-zero\fR 4
  .IX Item "-fsign-zero"
  When enabled, floating point numbers of value zero with the sign bit set
  are written as negative number in formatted output and treated as
*************** and regards zero as positive number in t
*** 1271,1277 ****
  compatibility with Fortran 77. The default is \fB\-fsign\-zero\fR.
  .SS "Options for code generation conventions"
  .IX Subsection "Options for code generation conventions"
! These machine-independent options control the interface conventions
  used in code generation.
  .PP
  Most of them have both positive and negative forms; the negative form
--- 1196,1202 ----
  compatibility with Fortran 77. The default is \fB\-fsign\-zero\fR.
  .SS "Options for code generation conventions"
  .IX Subsection "Options for code generation conventions"
! These machine\-independent options control the interface conventions
  used in code generation.
  .PP
  Most of them have both positive and negative forms; the negative form
*************** of \fB\-ffoo\fR would be \fB\-fno\-foo\f
*** 1279,1287 ****
  one of the forms is listed\-\-\-the one which is not the default.  You
  can figure out the other form by either removing \fBno\-\fR or adding
  it.
! .IP "\fB\-fno\-automatic\fR" 4
  .IX Item "-fno-automatic"
! Treat each program unit (except those marked as \s-1RECURSIVE\s0) as if the
  \&\f(CW\*(C`SAVE\*(C'\fR statement were specified for every local variable and array
  referenced in it. Does not affect common blocks. (Some Fortran compilers
  provide this option under the name \fB\-static\fR or \fB\-save\fR.)
--- 1204,1212 ----
  one of the forms is listed\-\-\-the one which is not the default.  You
  can figure out the other form by either removing \fBno\-\fR or adding
  it.
! .IP \fB\-fno\-automatic\fR 4
  .IX Item "-fno-automatic"
! Treat each program unit (except those marked as RECURSIVE) as if the
  \&\f(CW\*(C`SAVE\*(C'\fR statement were specified for every local variable and array
  referenced in it. Does not affect common blocks. (Some Fortran compilers
  provide this option under the name \fB\-static\fR or \fB\-save\fR.)
*************** Use the option \fB\-frecursive\fR to use
*** 1291,1297 ****
  .Sp
  Local variables or arrays having an explicit \f(CW\*(C`SAVE\*(C'\fR attribute are
  silently ignored unless the \fB\-pedantic\fR option is added.
! .IP "\fB\-ff2c\fR" 4
  .IX Item "-ff2c"
  Generate code designed to be compatible with code generated
  by \fBg77\fR and \fBf2c\fR.
--- 1216,1222 ----
  .Sp
  Local variables or arrays having an explicit \f(CW\*(C`SAVE\*(C'\fR attribute are
  silently ignored unless the \fB\-pedantic\fR option is added.
! .IP \fB\-ff2c\fR 4
  .IX Item "-ff2c"
  Generate code designed to be compatible with code generated
  by \fBg77\fR and \fBf2c\fR.
*************** in \fBf2c\fR) require functions that ret
*** 1301,1310 ****
  default \f(CW\*(C`REAL\*(C'\fR to actually return the C type \f(CW\*(C`double\*(C'\fR, and
  functions that return type \f(CW\*(C`COMPLEX\*(C'\fR to return the values via an
  extra argument in the calling sequence that points to where to
! store the return value.  Under the default \s-1GNU\s0 calling conventions, such
! functions simply return their results as they would in \s-1GNU\s0
  C\-\-\-default \f(CW\*(C`REAL\*(C'\fR functions return the C type \f(CW\*(C`float\*(C'\fR, and
! \&\f(CW\*(C`COMPLEX\*(C'\fR functions return the \s-1GNU C\s0 type \f(CW\*(C`complex\*(C'\fR.
  Additionally, this option implies the \fB\-fsecond\-underscore\fR
  option, unless \fB\-fno\-second\-underscore\fR is explicitly requested.
  .Sp
--- 1226,1235 ----
  default \f(CW\*(C`REAL\*(C'\fR to actually return the C type \f(CW\*(C`double\*(C'\fR, and
  functions that return type \f(CW\*(C`COMPLEX\*(C'\fR to return the values via an
  extra argument in the calling sequence that points to where to
! store the return value.  Under the default GNU calling conventions, such
! functions simply return their results as they would in GNU
  C\-\-\-default \f(CW\*(C`REAL\*(C'\fR functions return the C type \f(CW\*(C`float\*(C'\fR, and
! \&\f(CW\*(C`COMPLEX\*(C'\fR functions return the GNU C type \f(CW\*(C`complex\*(C'\fR.
  Additionally, this option implies the \fB\-fsecond\-underscore\fR
  option, unless \fB\-fno\-second\-underscore\fR is explicitly requested.
  .Sp
*************** calling conventions will break at execut
*** 1320,1347 ****
  \&\fICaution:\fR This will break code which passes intrinsic functions
  of type default \f(CW\*(C`REAL\*(C'\fR or \f(CW\*(C`COMPLEX\*(C'\fR as actual arguments, as
  the library implementations use the \fB\-fno\-f2c\fR calling conventions.
! .IP "\fB\-fno\-underscoring\fR" 4
  .IX Item "-fno-underscoring"
  Do not transform names of entities specified in the Fortran
  source file by appending underscores to them.
  .Sp
! With \fB\-funderscoring\fR in effect, \s-1GNU\s0 Fortran appends one
  underscore to external names.  This is done to ensure
! compatibility with code produced by many \s-1UNIX\s0 Fortran compilers.
  .Sp
! \&\fICaution\fR: The default behavior of \s-1GNU\s0 Fortran is
  incompatible with \fBf2c\fR and \fBg77\fR, please use the
  \&\fB\-ff2c\fR option if you want object files compiled with
! \&\s-1GNU\s0 Fortran to be compatible with object code created with these
  tools.
  .Sp
  Use of \fB\-fno\-underscoring\fR is not recommended unless you are
! experimenting with issues such as integration of \s-1GNU\s0 Fortran into
! existing system environments (vis\-a\*`\-vis existing libraries, tools,
  and so on).
  .Sp
! For example, with \fB\-funderscoring\fR, and assuming that \f(CW\*(C`j()\*(C'\fR and
! \&\f(CW\*(C`max_count()\*(C'\fR are external functions while \f(CW\*(C`my_var\*(C'\fR and
  \&\f(CW\*(C`lvar\*(C'\fR are local variables, a statement like
  .Sp
  .Vb 1
--- 1245,1272 ----
  \&\fICaution:\fR This will break code which passes intrinsic functions
  of type default \f(CW\*(C`REAL\*(C'\fR or \f(CW\*(C`COMPLEX\*(C'\fR as actual arguments, as
  the library implementations use the \fB\-fno\-f2c\fR calling conventions.
! .IP \fB\-fno\-underscoring\fR 4
  .IX Item "-fno-underscoring"
  Do not transform names of entities specified in the Fortran
  source file by appending underscores to them.
  .Sp
! With \fB\-funderscoring\fR in effect, GNU Fortran appends one
  underscore to external names.  This is done to ensure
! compatibility with code produced by many UNIX Fortran compilers.
  .Sp
! \&\fICaution\fR: The default behavior of GNU Fortran is
  incompatible with \fBf2c\fR and \fBg77\fR, please use the
  \&\fB\-ff2c\fR option if you want object files compiled with
! GNU Fortran to be compatible with object code created with these
  tools.
  .Sp
  Use of \fB\-fno\-underscoring\fR is not recommended unless you are
! experimenting with issues such as integration of GNU Fortran into
! existing system environments (vis\-à\-vis existing libraries, tools,
  and so on).
  .Sp
! For example, with \fB\-funderscoring\fR, and assuming that \f(CWj()\fR and
! \&\f(CWmax_count()\fR are external functions while \f(CW\*(C`my_var\*(C'\fR and
  \&\f(CW\*(C`lvar\*(C'\fR are local variables, a statement like
  .Sp
  .Vb 1
*************** With \fB\-fno\-underscoring\fR, the same
*** 1361,1373 ****
  .Ve
  .Sp
  Use of \fB\-fno\-underscoring\fR allows direct specification of
! user-defined names while debugging and when interfacing \s-1GNU\s0 Fortran
  code with other languages.
  .Sp
  Note that just because the names match does \fInot\fR mean that the
! interface implemented by \s-1GNU\s0 Fortran for an external name matches the
  interface implemented by some other language for that same name.
! That is, getting code produced by \s-1GNU\s0 Fortran to link to code produced
  by some other compiler using this or any other method can be only a
  small part of the overall solution\-\-\-getting the code generated by
  both compilers to agree on issues other than naming can require
--- 1286,1298 ----
  .Ve
  .Sp
  Use of \fB\-fno\-underscoring\fR allows direct specification of
! user\-defined names while debugging and when interfacing GNU Fortran
  code with other languages.
  .Sp
  Note that just because the names match does \fInot\fR mean that the
! interface implemented by GNU Fortran for an external name matches the
  interface implemented by some other language for that same name.
! That is, getting code produced by GNU Fortran to link to code produced
  by some other compiler using this or any other method can be only a
  small part of the overall solution\-\-\-getting the code generated by
  both compilers to agree on issues other than naming can require
*************** significant effort, and, unlike naming d
*** 1375,1397 ****
  cannot detect disagreements in these other areas.
  .Sp
  Also, note that with \fB\-fno\-underscoring\fR, the lack of appended
! underscores introduces the very real possibility that a user-defined
  external name will conflict with a name in a system library, which
! could make finding unresolved-reference bugs quite difficult in some
  cases\-\-\-they might occur at program run time, and show up only as
  buggy behavior at run time.
  .Sp
! In future versions of \s-1GNU\s0 Fortran we hope to improve naming and linking
  issues so that debugging always involves using the names as they appear
  in the source, even if the names as seen by the linker are mangled to
  prevent accidental linking between procedures with incompatible
  interfaces.
! .IP "\fB\-fsecond\-underscore\fR" 4
  .IX Item "-fsecond-underscore"
! By default, \s-1GNU\s0 Fortran appends an underscore to external
! names.  If this option is used \s-1GNU\s0 Fortran appends two
  underscores to names with underscores and one underscore to external names
! with no underscores.  \s-1GNU\s0 Fortran also appends two underscores to
  internal names with underscores to avoid naming collisions with external
  names.
  .Sp
--- 1300,1322 ----
  cannot detect disagreements in these other areas.
  .Sp
  Also, note that with \fB\-fno\-underscoring\fR, the lack of appended
! underscores introduces the very real possibility that a user\-defined
  external name will conflict with a name in a system library, which
! could make finding unresolved\-reference bugs quite difficult in some
  cases\-\-\-they might occur at program run time, and show up only as
  buggy behavior at run time.
  .Sp
! In future versions of GNU Fortran we hope to improve naming and linking
  issues so that debugging always involves using the names as they appear
  in the source, even if the names as seen by the linker are mangled to
  prevent accidental linking between procedures with incompatible
  interfaces.
! .IP \fB\-fsecond\-underscore\fR 4
  .IX Item "-fsecond-underscore"
! By default, GNU Fortran appends an underscore to external
! names.  If this option is used GNU Fortran appends two
  underscores to names with underscores and one underscore to external names
! with no underscores.  GNU Fortran also appends two underscores to
  internal names with underscores to avoid naming collisions with external
  names.
  .Sp
*************** This option has no effect if \fB\-fno\-u
*** 1399,1450 ****
  in effect.  It is implied by the \fB\-ff2c\fR option.
  .Sp
  Otherwise, with this option, an external name such as \f(CW\*(C`MAX_COUNT\*(C'\fR
! is implemented as a reference to the link-time external symbol
  \&\f(CW\*(C`max_count_\|_\*(C'\fR, instead of \f(CW\*(C`max_count_\*(C'\fR.  This is required
  for compatibility with \fBg77\fR and \fBf2c\fR, and is implied
  by use of the \fB\-ff2c\fR option.
! .IP "\fB\-fcoarray=\fR\fI\fR" 4
  .IX Item "-fcoarray="
  .RS 4
  .PD 0
! .IP "\fBnone\fR" 4
  .IX Item "none"
  .PD
! Disable coarray support; using coarray declarations and image-control
! statements will produce a compile-time error. (Default)
! .IP "\fBsingle\fR" 4
  .IX Item "single"
! Single-image mode, i.e. \f(CW\*(C`num_images()\*(C'\fR is always one.
! .IP "\fBlib\fR" 4
  .IX Item "lib"
! Library-based coarray parallelization; a suitable \s-1GNU\s0 Fortran coarray
  library needs to be linked.
  .RE
  .RS 4
  .RE
! .IP "\fB\-fcheck=\fR\fI\fR" 4
  .IX Item "-fcheck="
! Enable the generation of run-time checks; the argument shall be
! a comma-delimited list of the following keywords.  Prefixing a check with
  \&\fBno\-\fR disables it if it was activated by a previous specification.
  .RS 4
! .IP "\fBall\fR" 4
  .IX Item "all"
! Enable all run-time test of \fB\-fcheck\fR.
! .IP "\fBarray-temps\fR" 4
  .IX Item "array-temps"
  Warns at run time when for passing an actual argument a temporary array
  had to be generated. The information generated by this warning is
  sometimes useful in optimization, in order to avoid such temporaries.
  .Sp
  Note: The warning is only printed once per location.
! .IP "\fBbits\fR" 4
  .IX Item "bits"
! Enable generation of run-time checks for invalid arguments to the bit
  manipulation intrinsics.
! .IP "\fBbounds\fR" 4
  .IX Item "bounds"
! Enable generation of run-time checks for array subscripts
  and against the declared minimum and maximum values.  It also
  checks array indices for assumed and deferred
  shape arrays against the actual allocated bounds and ensures that all string
--- 1324,1375 ----
  in effect.  It is implied by the \fB\-ff2c\fR option.
  .Sp
  Otherwise, with this option, an external name such as \f(CW\*(C`MAX_COUNT\*(C'\fR
! is implemented as a reference to the link\-time external symbol
  \&\f(CW\*(C`max_count_\|_\*(C'\fR, instead of \f(CW\*(C`max_count_\*(C'\fR.  This is required
  for compatibility with \fBg77\fR and \fBf2c\fR, and is implied
  by use of the \fB\-ff2c\fR option.
! .IP \fB\-fcoarray=\fR\fI\fR 4
  .IX Item "-fcoarray="
  .RS 4
  .PD 0
! .IP \fBnone\fR 4
  .IX Item "none"
  .PD
! Disable coarray support; using coarray declarations and image\-control
! statements will produce a compile\-time error. (Default)
! .IP \fBsingle\fR 4
  .IX Item "single"
! Single\-image mode, i.e. \f(CWnum_images()\fR is always one.
! .IP \fBlib\fR 4
  .IX Item "lib"
! Library\-based coarray parallelization; a suitable GNU Fortran coarray
  library needs to be linked.
  .RE
  .RS 4
  .RE
! .IP \fB\-fcheck=\fR\fI\fR 4
  .IX Item "-fcheck="
! Enable the generation of run\-time checks; the argument shall be
! a comma\-delimited list of the following keywords.  Prefixing a check with
  \&\fBno\-\fR disables it if it was activated by a previous specification.
  .RS 4
! .IP \fBall\fR 4
  .IX Item "all"
! Enable all run\-time test of \fB\-fcheck\fR.
! .IP \fBarray\-temps\fR 4
  .IX Item "array-temps"
  Warns at run time when for passing an actual argument a temporary array
  had to be generated. The information generated by this warning is
  sometimes useful in optimization, in order to avoid such temporaries.
  .Sp
  Note: The warning is only printed once per location.
! .IP \fBbits\fR 4
  .IX Item "bits"
! Enable generation of run\-time checks for invalid arguments to the bit
  manipulation intrinsics.
! .IP \fBbounds\fR 4
  .IX Item "bounds"
! Enable generation of run\-time checks for array subscripts
  and against the declared minimum and maximum values.  It also
  checks array indices for assumed and deferred
  shape arrays against the actual allocated bounds and ensures that all string
*************** the compilation of the main program.
*** 1456,1476 ****
  .Sp
  Note: In the future this may also include other forms of checking, e.g.,
  checking substring references.
! .IP "\fBdo\fR" 4
  .IX Item "do"
! Enable generation of run-time checks for invalid modification of loop
  iteration variables.
! .IP "\fBmem\fR" 4
  .IX Item "mem"
! Enable generation of run-time checks for memory allocation.
  Note: This option does not affect explicit allocations using the
  \&\f(CW\*(C`ALLOCATE\*(C'\fR statement, which will be always checked.
! .IP "\fBpointer\fR" 4
  .IX Item "pointer"
! Enable generation of run-time checks for pointers and allocatables.
! .IP "\fBrecursion\fR" 4
  .IX Item "recursion"
! Enable generation of run-time checks for recursively called subroutines and
  functions which are not marked as recursive. See also \fB\-frecursive\fR.
  Note: This check does not work for OpenMP programs and is disabled if used
  together with \fB\-frecursive\fR and \fB\-fopenmp\fR.
--- 1381,1401 ----
  .Sp
  Note: In the future this may also include other forms of checking, e.g.,
  checking substring references.
! .IP \fBdo\fR 4
  .IX Item "do"
! Enable generation of run\-time checks for invalid modification of loop
  iteration variables.
! .IP \fBmem\fR 4
  .IX Item "mem"
! Enable generation of run\-time checks for memory allocation.
  Note: This option does not affect explicit allocations using the
  \&\f(CW\*(C`ALLOCATE\*(C'\fR statement, which will be always checked.
! .IP \fBpointer\fR 4
  .IX Item "pointer"
! Enable generation of run\-time checks for pointers and allocatables.
! .IP \fBrecursion\fR 4
  .IX Item "recursion"
! Enable generation of run\-time checks for recursively called subroutines and
  functions which are not marked as recursive. See also \fB\-frecursive\fR.
  Note: This check does not work for OpenMP programs and is disabled if used
  together with \fB\-frecursive\fR and \fB\-fopenmp\fR.
*************** Example: Assuming you have a file \fIfoo
*** 1486,1501 ****
  will compile the file with all checks enabled as specified above except
  warnings for generated array temporaries.
  .RE
! .IP "\fB\-fbounds\-check\fR" 4
  .IX Item "-fbounds-check"
  Deprecated alias for \fB\-fcheck=bounds\fR.
! .IP "\fB\-ftail\-call\-workaround\fR" 4
  .IX Item "-ftail-call-workaround"
  .PD 0
! .IP "\fB\-ftail\-call\-workaround=\fR\fIn\fR" 4
  .IX Item "-ftail-call-workaround=n"
  .PD
! Some C interfaces to Fortran codes violate the gfortran \s-1ABI\s0 by
  omitting the hidden character length arguments as described in
    This can lead to crashes
  because pushing arguments for tail calls can overflow the stack.
--- 1411,1426 ----
  will compile the file with all checks enabled as specified above except
  warnings for generated array temporaries.
  .RE
! .IP \fB\-fbounds\-check\fR 4
  .IX Item "-fbounds-check"
  Deprecated alias for \fB\-fcheck=bounds\fR.
! .IP \fB\-ftail\-call\-workaround\fR 4
  .IX Item "-ftail-call-workaround"
  .PD 0
! .IP \fB\-ftail\-call\-workaround=\fR\fIn\fR 4
  .IX Item "-ftail-call-workaround=n"
  .PD
! Some C interfaces to Fortran codes violate the gfortran ABI by
  omitting the hidden character length arguments as described in
    This can lead to crashes
  because pushing arguments for tail calls can overflow the stack.
*************** insufficient stack space.
*** 1513,1519 ****
  .Sp
  It is \fIvery strongly\fR recommended to fix the code in question.
  The \fB\-fc\-prototypes\-external\fR option can be used to generate
! prototypes which conform to gfortran's \s-1ABI,\s0 for inclusion in the
  source code.
  .Sp
  Support for this option will likely be withdrawn in a future release
--- 1438,1444 ----
  .Sp
  It is \fIvery strongly\fR recommended to fix the code in question.
  The \fB\-fc\-prototypes\-external\fR option can be used to generate
! prototypes which conform to gfortran\*(Aqs ABI, for inclusion in the
  source code.
  .Sp
  Support for this option will likely be withdrawn in a future release
*************** The negative form, \fB\-fno\-tail\-call\
*** 1524,1533 ****
  .Sp
  Default is currently \fB\-ftail\-call\-workaround\fR, this will change
  in future releases.
! .IP "\fB\-fcheck\-array\-temporaries\fR" 4
  .IX Item "-fcheck-array-temporaries"
  Deprecated alias for \fB\-fcheck=array\-temps\fR.
! .IP "\fB\-fmax\-array\-constructor=\fR\fIn\fR" 4
  .IX Item "-fmax-array-constructor=n"
  This option can be used to increase the upper limit permitted in 
  array constructors.  The code below requires this option to expand
--- 1449,1458 ----
  .Sp
  Default is currently \fB\-ftail\-call\-workaround\fR, this will change
  in future releases.
! .IP \fB\-fcheck\-array\-temporaries\fR 4
  .IX Item "-fcheck-array-temporaries"
  Deprecated alias for \fB\-fcheck=array\-temps\fR.
! .IP \fB\-fmax\-array\-constructor=\fR\fIn\fR 4
  .IX Item "-fmax-array-constructor=n"
  This option can be used to increase the upper limit permitted in 
  array constructors.  The code below requires this option to expand
*************** the array at compile time.
*** 1547,1566 ****
  large object files.\fR
  .Sp
  The default value for \fIn\fR is 65535.
! .IP "\fB\-fmax\-stack\-var\-size=\fR\fIn\fR" 4
  .IX Item "-fmax-stack-var-size=n"
  This option specifies the size in bytes of the largest array that will be put
  on the stack; if the size is exceeded static memory is used (except in
! procedures marked as \s-1RECURSIVE\s0). Use the option \fB\-frecursive\fR to
! allow for recursive procedures which do not have a \s-1RECURSIVE\s0 attribute or
  for parallel programs. Use \fB\-fno\-automatic\fR to never use the stack.
  .Sp
  This option currently only affects local arrays declared with constant
  bounds, and may not apply to all character variables.
! Future versions of \s-1GNU\s0 Fortran may improve this behavior.
  .Sp
  The default value for \fIn\fR is 65536.
! .IP "\fB\-fstack\-arrays\fR" 4
  .IX Item "-fstack-arrays"
  Adding this option will make the Fortran compiler put all arrays of
  unknown size and array temporaries onto stack memory.  If your program uses very
--- 1472,1491 ----
  large object files.\fR
  .Sp
  The default value for \fIn\fR is 65535.
! .IP \fB\-fmax\-stack\-var\-size=\fR\fIn\fR 4
  .IX Item "-fmax-stack-var-size=n"
  This option specifies the size in bytes of the largest array that will be put
  on the stack; if the size is exceeded static memory is used (except in
! procedures marked as RECURSIVE). Use the option \fB\-frecursive\fR to
! allow for recursive procedures which do not have a RECURSIVE attribute or
  for parallel programs. Use \fB\-fno\-automatic\fR to never use the stack.
  .Sp
  This option currently only affects local arrays declared with constant
  bounds, and may not apply to all character variables.
! Future versions of GNU Fortran may improve this behavior.
  .Sp
  The default value for \fIn\fR is 65536.
! .IP \fB\-fstack\-arrays\fR 4
  .IX Item "-fstack-arrays"
  Adding this option will make the Fortran compiler put all arrays of
  unknown size and array temporaries onto stack memory.  If your program uses very
*************** large local arrays it is possible that y
*** 1568,1581 ****
  limits for stack memory on some operating systems. This flag is enabled
  by default at optimization level \fB\-Ofast\fR unless
  \&\fB\-fmax\-stack\-var\-size\fR is specified.
! .IP "\fB\-fpack\-derived\fR" 4
  .IX Item "-fpack-derived"
! This option tells \s-1GNU\s0 Fortran to pack derived type members as closely as
  possible.  Code compiled with this option is likely to be incompatible
  with code compiled without this option, and may execute slower.
! .IP "\fB\-frepack\-arrays\fR" 4
  .IX Item "-frepack-arrays"
! In some circumstances \s-1GNU\s0 Fortran may pass assumed shape array
  sections via a descriptor describing a noncontiguous area of memory.
  This option adds code to the function prologue to repack the data into
  a contiguous block at runtime.
--- 1493,1506 ----
  limits for stack memory on some operating systems. This flag is enabled
  by default at optimization level \fB\-Ofast\fR unless
  \&\fB\-fmax\-stack\-var\-size\fR is specified.
! .IP \fB\-fpack\-derived\fR 4
  .IX Item "-fpack-derived"
! This option tells GNU Fortran to pack derived type members as closely as
  possible.  Code compiled with this option is likely to be incompatible
  with code compiled without this option, and may execute slower.
! .IP \fB\-frepack\-arrays\fR 4
  .IX Item "-frepack-arrays"
! In some circumstances GNU Fortran may pass assumed shape array
  sections via a descriptor describing a noncontiguous area of memory.
  This option adds code to the function prologue to repack the data into
  a contiguous block at runtime.
*************** a contiguous block at runtime.
*** 1583,1598 ****
  This should result in faster accesses to the array.  However it can introduce
  significant overhead to the function call, especially  when the passed data
  is noncontiguous.
! .IP "\fB\-fshort\-enums\fR" 4
  .IX Item "-fshort-enums"
  This option is provided for interoperability with C code that was
  compiled with the \fB\-fshort\-enums\fR option.  It will make
! \&\s-1GNU\s0 Fortran choose the smallest \f(CW\*(C`INTEGER\*(C'\fR kind a given
  enumerator set will fit in, and give all its enumerators this kind.
! .IP "\fB\-finline\-arg\-packing\fR" 4
  .IX Item "-finline-arg-packing"
! When passing an assumed-shape argument of a procedure as actual
! argument to an assumed-size or explicit size or as argument to a
  procedure that does not have an explicit interface, the argument may
  have to be packed, that is put into contiguous memory. An example is
  the call to \f(CW\*(C`foo\*(C'\fR in
--- 1508,1523 ----
  This should result in faster accesses to the array.  However it can introduce
  significant overhead to the function call, especially  when the passed data
  is noncontiguous.
! .IP \fB\-fshort\-enums\fR 4
  .IX Item "-fshort-enums"
  This option is provided for interoperability with C code that was
  compiled with the \fB\-fshort\-enums\fR option.  It will make
! GNU Fortran choose the smallest \f(CW\*(C`INTEGER\*(C'\fR kind a given
  enumerator set will fit in, and give all its enumerators this kind.
! .IP \fB\-finline\-arg\-packing\fR 4
  .IX Item "-finline-arg-packing"
! When passing an assumed\-shape argument of a procedure as actual
! argument to an assumed\-size or explicit size or as argument to a
  procedure that does not have an explicit interface, the argument may
  have to be packed, that is put into contiguous memory. An example is
  the call to \f(CW\*(C`foo\*(C'\fR in
*************** contains a very large number of argument
*** 1617,1643 ****
  size and also compilation time may become excessive.  If that is the
  case, it may be better to disable this option.  Instances of packing
  can be found by using \fB\-Warray\-temporaries\fR.
! .IP "\fB\-fexternal\-blas\fR" 4
  .IX Item "-fexternal-blas"
! This option will make \fBgfortran\fR generate calls to \s-1BLAS\s0 functions
  for some matrix operations like \f(CW\*(C`MATMUL\*(C'\fR, instead of using our own
  algorithms, if the size of the matrices involved is larger than a given
  limit (see \fB\-fblas\-matmul\-limit\fR).  This may be profitable if an
! optimized vendor \s-1BLAS\s0 library is available.  The \s-1BLAS\s0 library will have
  to be specified at link time.
! .IP "\fB\-fblas\-matmul\-limit=\fR\fIn\fR" 4
  .IX Item "-fblas-matmul-limit=n"
  Only significant when \fB\-fexternal\-blas\fR is in effect.
  Matrix multiplication of matrices with size larger than (or equal to) \fIn\fR
! will be performed by calls to \s-1BLAS\s0 functions, while others will be
  handled by \fBgfortran\fR internal algorithms. If the matrices
  involved are not square, the size comparison is performed using the
  geometric mean of the dimensions of the argument and result matrices.
  .Sp
  The default value for \fIn\fR is 30.
! .IP "\fB\-finline\-matmul\-limit=\fR\fIn\fR" 4
  .IX Item "-finline-matmul-limit=n"
! When front-end optimization is active, some calls to the \f(CW\*(C`MATMUL\*(C'\fR
  intrinsic function will be inlined.  This may result in code size
  increase if the size of the matrix cannot be determined at compile
  time, as code for both cases is generated.  Setting
--- 1542,1568 ----
  size and also compilation time may become excessive.  If that is the
  case, it may be better to disable this option.  Instances of packing
  can be found by using \fB\-Warray\-temporaries\fR.
! .IP \fB\-fexternal\-blas\fR 4
  .IX Item "-fexternal-blas"
! This option will make \fBgfortran\fR generate calls to BLAS functions
  for some matrix operations like \f(CW\*(C`MATMUL\*(C'\fR, instead of using our own
  algorithms, if the size of the matrices involved is larger than a given
  limit (see \fB\-fblas\-matmul\-limit\fR).  This may be profitable if an
! optimized vendor BLAS library is available.  The BLAS library will have
  to be specified at link time.
! .IP \fB\-fblas\-matmul\-limit=\fR\fIn\fR 4
  .IX Item "-fblas-matmul-limit=n"
  Only significant when \fB\-fexternal\-blas\fR is in effect.
  Matrix multiplication of matrices with size larger than (or equal to) \fIn\fR
! will be performed by calls to BLAS functions, while others will be
  handled by \fBgfortran\fR internal algorithms. If the matrices
  involved are not square, the size comparison is performed using the
  geometric mean of the dimensions of the argument and result matrices.
  .Sp
  The default value for \fIn\fR is 30.
! .IP \fB\-finline\-matmul\-limit=\fR\fIn\fR 4
  .IX Item "-finline-matmul-limit=n"
! When front\-end optimization is active, some calls to the \f(CW\*(C`MATMUL\*(C'\fR
  intrinsic function will be inlined.  This may result in code size
  increase if the size of the matrix cannot be determined at compile
  time, as code for both cases is generated.  Setting
*************** the dimensions of the argument and resul
*** 1649,1683 ****
  .Sp
  The default value for \fIn\fR is 30.  The \f(CW\*(C`\-fblas\-matmul\-limit\*(C'\fR
  can be used to change this value.
! .IP "\fB\-frecursive\fR" 4
  .IX Item "-frecursive"
  Allow indirect recursion by forcing all local arrays to be allocated
  on the stack. This flag cannot be used together with
  \&\fB\-fmax\-stack\-var\-size=\fR or \fB\-fno\-automatic\fR.
! .IP "\fB\-finit\-local\-zero\fR" 4
  .IX Item "-finit-local-zero"
  .PD 0
! .IP "\fB\-finit\-derived\fR" 4
  .IX Item "-finit-derived"
! .IP "\fB\-finit\-integer=\fR\fIn\fR" 4
  .IX Item "-finit-integer=n"
! .IP "\fB\-finit\-real=\fR\fI\fR" 4
  .IX Item "-finit-real="
! .IP "\fB\-finit\-logical=\fR\fI\fR" 4
  .IX Item "-finit-logical="
! .IP "\fB\-finit\-character=\fR\fIn\fR" 4
  .IX Item "-finit-character=n"
  .PD
  The \fB\-finit\-local\-zero\fR option instructs the compiler to
  initialize local \f(CW\*(C`INTEGER\*(C'\fR, \f(CW\*(C`REAL\*(C'\fR, and \f(CW\*(C`COMPLEX\*(C'\fR
  variables to zero, \f(CW\*(C`LOGICAL\*(C'\fR variables to false, and
! \&\f(CW\*(C`CHARACTER\*(C'\fR variables to a string of null bytes.  Finer-grained
  initialization options are provided by the
  \&\fB\-finit\-integer=\fR\fIn\fR,
  \&\fB\-finit\-real=\fR\fI\fR (which also initializes
  the real and imaginary parts of local \f(CW\*(C`COMPLEX\*(C'\fR variables),
  \&\fB\-finit\-logical=\fR\fI\fR, and
! \&\fB\-finit\-character=\fR\fIn\fR (where \fIn\fR is an \s-1ASCII\s0 character
  value) options.
  .Sp
  With \fB\-finit\-derived\fR, components of derived type variables will be
--- 1574,1608 ----
  .Sp
  The default value for \fIn\fR is 30.  The \f(CW\*(C`\-fblas\-matmul\-limit\*(C'\fR
  can be used to change this value.
! .IP \fB\-frecursive\fR 4
  .IX Item "-frecursive"
  Allow indirect recursion by forcing all local arrays to be allocated
  on the stack. This flag cannot be used together with
  \&\fB\-fmax\-stack\-var\-size=\fR or \fB\-fno\-automatic\fR.
! .IP \fB\-finit\-local\-zero\fR 4
  .IX Item "-finit-local-zero"
  .PD 0
! .IP \fB\-finit\-derived\fR 4
  .IX Item "-finit-derived"
! .IP \fB\-finit\-integer=\fR\fIn\fR 4
  .IX Item "-finit-integer=n"
! .IP \fB\-finit\-real=\fR\fI\fR 4
  .IX Item "-finit-real="
! .IP \fB\-finit\-logical=\fR\fI\fR 4
  .IX Item "-finit-logical="
! .IP \fB\-finit\-character=\fR\fIn\fR 4
  .IX Item "-finit-character=n"
  .PD
  The \fB\-finit\-local\-zero\fR option instructs the compiler to
  initialize local \f(CW\*(C`INTEGER\*(C'\fR, \f(CW\*(C`REAL\*(C'\fR, and \f(CW\*(C`COMPLEX\*(C'\fR
  variables to zero, \f(CW\*(C`LOGICAL\*(C'\fR variables to false, and
! \&\f(CW\*(C`CHARACTER\*(C'\fR variables to a string of null bytes.  Finer\-grained
  initialization options are provided by the
  \&\fB\-finit\-integer=\fR\fIn\fR,
  \&\fB\-finit\-real=\fR\fI\fR (which also initializes
  the real and imaginary parts of local \f(CW\*(C`COMPLEX\*(C'\fR variables),
  \&\fB\-finit\-logical=\fR\fI\fR, and
! \&\fB\-finit\-character=\fR\fIn\fR (where \fIn\fR is an ASCII character
  value) options.
  .Sp
  With \fB\-finit\-derived\fR, components of derived type variables will be
*************** an explicit \fB\-finit\-*\fR flag will b
*** 1687,1697 ****
  .Sp
  These options do not initialize
  .RS 4
! .IP "*" 4
! objects with the \s-1POINTER\s0 attribute
! .IP "*" 4
  allocatable arrays
! .IP "*" 4
  variables that appear in an \f(CW\*(C`EQUIVALENCE\*(C'\fR statement.
  .RE
  .RS 4
--- 1612,1622 ----
  .Sp
  These options do not initialize
  .RS 4
! .IP * 4
! objects with the POINTER attribute
! .IP * 4
  allocatable arrays
! .IP * 4
  variables that appear in an \f(CW\*(C`EQUIVALENCE\*(C'\fR statement.
  .RE
  .RS 4
*************** variables that appear in an \f(CW\*(C`EQ
*** 1700,1711 ****
  .Sp
  Note that the \fB\-finit\-real=nan\fR option initializes \f(CW\*(C`REAL\*(C'\fR
  and \f(CW\*(C`COMPLEX\*(C'\fR variables with a quiet NaN. For a signalling NaN
! use \fB\-finit\-real=snan\fR; note, however, that compile-time
  optimizations may convert them into quiet NaN and that trapping
  needs to be enabled (e.g. via \fB\-ffpe\-trap\fR).
  .Sp
  The \fB\-finit\-integer\fR option will parse the value into an
! integer of type \f(CW\*(C`INTEGER(kind=C_LONG)\*(C'\fR on the host.  Said value
  is then assigned to the integer variables in the Fortran code, which
  might result in wraparound if the value is too large for the kind.
  .Sp
--- 1625,1636 ----
  .Sp
  Note that the \fB\-finit\-real=nan\fR option initializes \f(CW\*(C`REAL\*(C'\fR
  and \f(CW\*(C`COMPLEX\*(C'\fR variables with a quiet NaN. For a signalling NaN
! use \fB\-finit\-real=snan\fR; note, however, that compile\-time
  optimizations may convert them into quiet NaN and that trapping
  needs to be enabled (e.g. via \fB\-ffpe\-trap\fR).
  .Sp
  The \fB\-finit\-integer\fR option will parse the value into an
! integer of type \f(CWINTEGER(kind=C_LONG)\fR on the host.  Said value
  is then assigned to the integer variables in the Fortran code, which
  might result in wraparound if the value is too large for the kind.
  .Sp
*************** Finally, note that enabling any of the \
*** 1713,1719 ****
  silence warnings that would have been emitted by \fB\-Wuninitialized\fR
  for the affected local variables.
  .RE
! .IP "\fB\-falign\-commons\fR" 4
  .IX Item "-falign-commons"
  By default, \fBgfortran\fR enforces proper alignment of all variables in a
  \&\f(CW\*(C`COMMON\*(C'\fR block by padding them as needed. On certain platforms this is mandatory,
--- 1638,1644 ----
  silence warnings that would have been emitted by \fB\-Wuninitialized\fR
  for the affected local variables.
  .RE
! .IP \fB\-falign\-commons\fR 4
  .IX Item "-falign-commons"
  By default, \fBgfortran\fR enforces proper alignment of all variables in a
  \&\f(CW\*(C`COMMON\*(C'\fR block by padding them as needed. On certain platforms this is mandatory,
*************** consistent data types everywhere, this p
*** 1723,1744 ****
  same form of this option should be used for all files that share a \f(CW\*(C`COMMON\*(C'\fR block.
  To avoid potential alignment issues in \f(CW\*(C`COMMON\*(C'\fR blocks, it is recommended to order
  objects from largest to smallest.
! .IP "\fB\-fno\-protect\-parens\fR" 4
  .IX Item "-fno-protect-parens"
  By default the parentheses in expression are honored for all optimization
! levels such that the compiler does not do any re-association. Using
  \&\fB\-fno\-protect\-parens\fR allows the compiler to reorder \f(CW\*(C`REAL\*(C'\fR and
! \&\f(CW\*(C`COMPLEX\*(C'\fR expressions to produce faster code. Note that for the re-association
  optimization \fB\-fno\-signed\-zeros\fR and \fB\-fno\-trapping\-math\fR
  need to be in effect. The parentheses protection is enabled by default, unless
  \&\fB\-Ofast\fR is given.
! .IP "\fB\-frealloc\-lhs\fR" 4
  .IX Item "-frealloc-lhs"
! An allocatable left-hand side of an intrinsic assignment is automatically
  (re)allocated if it is either unallocated or has a different shape. The
  option is enabled by default except when \fB\-std=f95\fR is given. See
  also \fB\-Wrealloc\-lhs\fR.
! .IP "\fB\-faggressive\-function\-elimination\fR" 4
  .IX Item "-faggressive-function-elimination"
  Functions with identical argument lists are eliminated within
  statements, regardless of whether these functions are marked
--- 1648,1669 ----
  same form of this option should be used for all files that share a \f(CW\*(C`COMMON\*(C'\fR block.
  To avoid potential alignment issues in \f(CW\*(C`COMMON\*(C'\fR blocks, it is recommended to order
  objects from largest to smallest.
! .IP \fB\-fno\-protect\-parens\fR 4
  .IX Item "-fno-protect-parens"
  By default the parentheses in expression are honored for all optimization
! levels such that the compiler does not do any re\-association. Using
  \&\fB\-fno\-protect\-parens\fR allows the compiler to reorder \f(CW\*(C`REAL\*(C'\fR and
! \&\f(CW\*(C`COMPLEX\*(C'\fR expressions to produce faster code. Note that for the re\-association
  optimization \fB\-fno\-signed\-zeros\fR and \fB\-fno\-trapping\-math\fR
  need to be in effect. The parentheses protection is enabled by default, unless
  \&\fB\-Ofast\fR is given.
! .IP \fB\-frealloc\-lhs\fR 4
  .IX Item "-frealloc-lhs"
! An allocatable left\-hand side of an intrinsic assignment is automatically
  (re)allocated if it is either unallocated or has a different shape. The
  option is enabled by default except when \fB\-std=f95\fR is given. See
  also \fB\-Wrealloc\-lhs\fR.
! .IP \fB\-faggressive\-function\-elimination\fR 4
  .IX Item "-faggressive-function-elimination"
  Functions with identical argument lists are eliminated within
  statements, regardless of whether these functions are marked
*************** statements, regardless of whether these
*** 1750,1758 ****
  .Sp
  there will only be a single call to \f(CW\*(C`f\*(C'\fR.  This option only works
  if \fB\-ffrontend\-optimize\fR is in effect.
! .IP "\fB\-ffrontend\-optimize\fR" 4
  .IX Item "-ffrontend-optimize"
! This option performs front-end optimization, based on manipulating
  parts the Fortran parse tree.  Enabled by default by any \fB\-O\fR option
  except \fB\-O0\fR and \fB\-Og\fR.  Optimizations enabled by this option
  include:
--- 1675,1683 ----
  .Sp
  there will only be a single call to \f(CW\*(C`f\*(C'\fR.  This option only works
  if \fB\-ffrontend\-optimize\fR is in effect.
! .IP \fB\-ffrontend\-optimize\fR 4
  .IX Item "-ffrontend-optimize"
! This option performs front\-end optimization, based on manipulating
  parts the Fortran parse tree.  Enabled by default by any \fB\-O\fR option
  except \fB\-O0\fR and \fB\-Og\fR.  Optimizations enabled by this option
  include:
*************** include:
*** 1772,1795 ****
  .ie n .IP "*" 4
  .el .IP "*" 4
  .IX Item "*"
  .RE
  .RS 4
- .PD
  .Sp
  It can be deselected by specifying \fB\-fno\-frontend\-optimize\fR.
  .RE
! .IP "\fB\-ffrontend\-loop\-interchange\fR" 4
  .IX Item "-ffrontend-loop-interchange"
  Attempt to interchange loops in the Fortran front end where
  profitable.  Enabled by default by any \fB\-O\fR option.
  At the moment, this option only affects \f(CW\*(C`FORALL\*(C'\fR and
  \&\f(CW\*(C`DO CONCURRENT\*(C'\fR statements with several forall triplets.
! .SH "ENVIRONMENT"
  .IX Header "ENVIRONMENT"
  The \fBgfortran\fR compiler currently does not make use of any environment
  variables to control its operation above and beyond those
  that affect the operation of \fBgcc\fR.
! .SH "BUGS"
  .IX Header "BUGS"
  For instructions on reporting bugs, see
  <\fBhttps://gcc.gnu.org/bugs/\fR>.
--- 1697,1720 ----
  .ie n .IP "*" 4
  .el .IP "*" 4
  .IX Item "*"
+ .PD
  .RE
  .RS 4
  .Sp
  It can be deselected by specifying \fB\-fno\-frontend\-optimize\fR.
  .RE
! .IP \fB\-ffrontend\-loop\-interchange\fR 4
  .IX Item "-ffrontend-loop-interchange"
  Attempt to interchange loops in the Fortran front end where
  profitable.  Enabled by default by any \fB\-O\fR option.
  At the moment, this option only affects \f(CW\*(C`FORALL\*(C'\fR and
  \&\f(CW\*(C`DO CONCURRENT\*(C'\fR statements with several forall triplets.
! .SH ENVIRONMENT
  .IX Header "ENVIRONMENT"
  The \fBgfortran\fR compiler currently does not make use of any environment
  variables to control its operation above and beyond those
  that affect the operation of \fBgcc\fR.
! .SH BUGS
  .IX Header "BUGS"
  For instructions on reporting bugs, see
  <\fBhttps://gcc.gnu.org/bugs/\fR>.
*************** For instructions on reporting bugs, see
*** 1799,1826 ****
  \&\fBcpp\fR\|(1), \fBgcov\fR\|(1), \fBgcc\fR\|(1), \fBas\fR\|(1), \fBld\fR\|(1), \fBgdb\fR\|(1), \fBdbx\fR\|(1)
  and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIgfortran\fR, \fIas\fR,
  \&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
! .SH "AUTHOR"
  .IX Header "AUTHOR"
! See the Info entry for \fBgfortran\fR for contributors to \s-1GCC\s0 and
! \&\s-1GNU\s0 Fortran.
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 2004\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being \*(L"Funding Free Software\*(R", the Front-Cover
! Texts being (a) (see below), and with the Back-Cover Texts being (b)
  (see below).  A copy of the license is included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The \s-1FSF\s0's Front-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The \s-1FSF\s0's Back-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
--- 1724,1751 ----
  \&\fBcpp\fR\|(1), \fBgcov\fR\|(1), \fBgcc\fR\|(1), \fBas\fR\|(1), \fBld\fR\|(1), \fBgdb\fR\|(1), \fBdbx\fR\|(1)
  and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIgfortran\fR, \fIas\fR,
  \&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
! .SH AUTHOR
  .IX Header "AUTHOR"
! See the Info entry for \fBgfortran\fR for contributors to GCC and
! GNU Fortran.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 2004\-2023 Free Software Foundation, Inc.
  .PP
  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 \fBgfdl\fR\|(7) man page.
  .PP
! (a) The FSF\*(Aqs Front\-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The FSF\*(Aqs Back\-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
diff -Nrcpad gcc-13.4.0/gcc/doc/gm2.1 gcc-13.5.0-RC-20260904/gcc/doc/gm2.1
*** gcc-13.4.0/gcc/doc/gm2.1	Thu Jun  5 16:12:10 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gm2.1	Fri Sep  4 07:41:18 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,174 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GM2 1"
! .TH GM2 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gm2 \- The GNU Modula\-2 Compiler
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
! .SH "OPTIONS"
  .IX Header "OPTIONS"
  For any given input file, the file name suffix determines what kind of
  compilation is done.  The following kinds of input file names are supported:
! .IP "\fIfile\fR\fB.mod\fR" 4
  .IX Item "file.mod"
  Modula\-2 implementation or program source files.  See the
  \&\fB\-fmod=\fR option if you wish to compile a project which uses a
  different source file extension.
! .IP "\fIfile\fR\fB.def\fR" 4
  .IX Item "file.def"
  Modula\-2 definition module source files.  Definition modules are not
! compiled separately, in \s-1GNU\s0 Modula\-2 definition modules are parsed as
  required when program or implementation modules are compiled.  See the
  \&\fB\-fdef=\fR option if you wish to compile a project which uses a
  different source file extension.
  .PP
  You can specify more than one input file on the \fBgm2\fR command line,
  .ie n .IP """\-g""" 4
! .el .IP "\f(CW\-g\fR" 4
  .IX Item "-g"
  create debugging information so that debuggers such as \fIgdb\fR
  can inspect and control executable.
  .ie n .IP """\-I""" 4
! .el .IP "\f(CW\-I\fR" 4
  .IX Item "-I"
  used to specify the search path for definition and implementation
  modules.  An example is:  \f(CW\*(C`gm2 \-g \-c \-I.:../../libs foo.mod\*(C'\fR.
--- 53,99 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GM2 1"
! .TH GM2 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gm2 \- The GNU Modula\-2 Compiler
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
! .SH OPTIONS
  .IX Header "OPTIONS"
  For any given input file, the file name suffix determines what kind of
  compilation is done.  The following kinds of input file names are supported:
! .IP \fIfile\fR\fB.mod\fR 4
  .IX Item "file.mod"
  Modula\-2 implementation or program source files.  See the
  \&\fB\-fmod=\fR option if you wish to compile a project which uses a
  different source file extension.
! .IP \fIfile\fR\fB.def\fR 4
  .IX Item "file.def"
  Modula\-2 definition module source files.  Definition modules are not
! compiled separately, in GNU Modula\-2 definition modules are parsed as
  required when program or implementation modules are compiled.  See the
  \&\fB\-fdef=\fR option if you wish to compile a project which uses a
  different source file extension.
  .PP
  You can specify more than one input file on the \fBgm2\fR command line,
  .ie n .IP """\-g""" 4
! .el .IP \f(CW\-g\fR 4
  .IX Item "-g"
  create debugging information so that debuggers such as \fIgdb\fR
  can inspect and control executable.
  .ie n .IP """\-I""" 4
! .el .IP \f(CW\-I\fR 4
  .IX Item "-I"
  used to specify the search path for definition and implementation
  modules.  An example is:  \f(CW\*(C`gm2 \-g \-c \-I.:../../libs foo.mod\*(C'\fR.
*************** If this option is not specified then the
*** 176,198 ****
  which consists of the current directory followed by the appropriate
  language dialect library directories.
  .ie n .IP """\-fauto\-init""" 4
! .el .IP "\f(CW\-fauto\-init\fR" 4
  .IX Item "-fauto-init"
! turns on auto initialization of pointers to \s-1NIL.\s0  Whenever a block is
  created all pointers declared within this scope will have their
! addresses assigned to \s-1NIL.\s0
  .ie n .IP """\-fbounds""" 4
! .el .IP "\f(CW\-fbounds\fR" 4
  .IX Item "-fbounds"
  turns on run time subrange, array index and indirection via \f(CW\*(C`NIL\*(C'\fR
  pointer checking.
  .ie n .IP """\-fcase""" 4
! .el .IP "\f(CW\-fcase\fR" 4
  .IX Item "-fcase"
  turns on compile time checking to check whether a \f(CW\*(C`CASE\*(C'\fR
  statement requires an \f(CW\*(C`ELSE\*(C'\fR clause when on was not specified.
  .ie n .IP """\-fcpp""" 4
! .el .IP "\f(CW\-fcpp\fR" 4
  .IX Item "-fcpp"
  preprocess the source with \fBcpp \-lang\-asm \-traditional\-cpp\fR
  For further details about these options 
--- 101,123 ----
  which consists of the current directory followed by the appropriate
  language dialect library directories.
  .ie n .IP """\-fauto\-init""" 4
! .el .IP \f(CW\-fauto\-init\fR 4
  .IX Item "-fauto-init"
! turns on auto initialization of pointers to NIL.  Whenever a block is
  created all pointers declared within this scope will have their
! addresses assigned to NIL.
  .ie n .IP """\-fbounds""" 4
! .el .IP \f(CW\-fbounds\fR 4
  .IX Item "-fbounds"
  turns on run time subrange, array index and indirection via \f(CW\*(C`NIL\*(C'\fR
  pointer checking.
  .ie n .IP """\-fcase""" 4
! .el .IP \f(CW\-fcase\fR 4
  .IX Item "-fcase"
  turns on compile time checking to check whether a \f(CW\*(C`CASE\*(C'\fR
  statement requires an \f(CW\*(C`ELSE\*(C'\fR clause when on was not specified.
  .ie n .IP """\-fcpp""" 4
! .el .IP \f(CW\-fcpp\fR 4
  .IX Item "-fcpp"
  preprocess the source with \fBcpp \-lang\-asm \-traditional\-cpp\fR
  For further details about these options 
*************** If \fB\-fcpp\fR is supplied then all def
*** 200,265 ****
  implementation modules which are parsed will be prepossessed by
  \&\fBcpp\fR.
  .ie n .IP """\-fdebug\-builtins""" 4
! .el .IP "\f(CW\-fdebug\-builtins\fR" 4
  .IX Item "-fdebug-builtins"
  call a real function, rather than the builtin equivalent.  This can
  be useful for debugging parameter values to a builtin function as
  it allows users to single step code into a real function.
  .ie n .IP """\-fdef=""" 4
! .el .IP "\f(CW\-fdef=\fR" 4
  .IX Item "-fdef="
  recognize the specified suffix as a definition module filename.
  The default implementation and module filename suffix is \fI.def\fR.
! If this option is used \s-1GNU\s0 Modula\-2 will still fall back to this
  default if a requested definition module is not found.
  .ie n .IP """\-fdump\-system\-exports""" 4
! .el .IP "\f(CW\-fdump\-system\-exports\fR" 4
  .IX Item "-fdump-system-exports"
  display all inbuilt system items.
  This is an internal command line option.
  .ie n .IP """\-fexceptions""" 4
! .el .IP "\f(CW\-fexceptions\fR" 4
  .IX Item "-fexceptions"
  turn on exception handling code.  By default this option is on.
  Exception handling can be disabled by \fB\-fno\-exceptions\fR
  and no references are made to the run time exception libraries.
  .ie n .IP """\-fextended\-opaque""" 4
! .el .IP "\f(CW\-fextended\-opaque\fR" 4
  .IX Item "-fextended-opaque"
! allows opaque types to be implemented as any type.  This is a \s-1GNU\s0
  Modula\-2 extension and it requires that the implementation module
  defining the opaque type is available so that it can be resolved when
  compiling the module which imports the opaque type.
  .ie n .IP """\-ffloatvalue""" 4
! .el .IP "\f(CW\-ffloatvalue\fR" 4
  .IX Item "-ffloatvalue"
  turns on run time checking to check whether a floating point number is
  about to exceed range.
! .ie n .IP """\-fgen\-module\-list=\fIfilename\fP""" 4
! .el .IP "\f(CW\-fgen\-module\-list=\f(CIfilename\f(CW\fR" 4
  .IX Item "-fgen-module-list=filename"
  attempt to find all modules when linking and generate a module list.
  If the \fIfilename\fR is \fB\-\fR then the contents are not written
  and only used to force the linking of all module ctors.
  This option cannot be used if \fB\-fuse\-list=\fR is enabled.
  .ie n .IP """\-findex""" 4
! .el .IP "\f(CW\-findex\fR" 4
  .IX Item "-findex"
  generate code to check whether array index values are out of bounds.
  Array index checking can be disabled via \fB\-fno\-index\fR.
  .ie n .IP """\-fiso""" 4
! .el .IP "\f(CW\-fiso\fR" 4
  .IX Item "-fiso"
! turn on \s-1ISO\s0 standard features.  Currently this enables the \s-1ISO\s0
  \&\f(CW\*(C`SYSTEM\*(C'\fR module and alters the default library search path so
! that the \s-1ISO\s0 libraries are searched before the \s-1PIM\s0 libraries.  It also
  effects the behavior of \f(CW\*(C`DIV\*(C'\fR and \f(CW\*(C`MOD\*(C'\fR operators.
  .ie n .IP """\-flibs=""" 4
! .el .IP "\f(CW\-flibs=\fR" 4
  .IX Item "-flibs="
  modifies the default library search path.  The libraries supplied are:
  m2pim, m2iso, m2min, m2log and m2cor.  These map onto the
! Programming in Modula\-2 base libraries, \s-1ISO\s0 standard libraries, minimal
  library support, Logitech compatible library and Programming in
  Modula\-2 with coroutines.
  Multiple libraries can be specified and are comma separated with precedence
--- 125,190 ----
  implementation modules which are parsed will be prepossessed by
  \&\fBcpp\fR.
  .ie n .IP """\-fdebug\-builtins""" 4
! .el .IP \f(CW\-fdebug\-builtins\fR 4
  .IX Item "-fdebug-builtins"
  call a real function, rather than the builtin equivalent.  This can
  be useful for debugging parameter values to a builtin function as
  it allows users to single step code into a real function.
  .ie n .IP """\-fdef=""" 4
! .el .IP \f(CW\-fdef=\fR 4
  .IX Item "-fdef="
  recognize the specified suffix as a definition module filename.
  The default implementation and module filename suffix is \fI.def\fR.
! If this option is used GNU Modula\-2 will still fall back to this
  default if a requested definition module is not found.
  .ie n .IP """\-fdump\-system\-exports""" 4
! .el .IP \f(CW\-fdump\-system\-exports\fR 4
  .IX Item "-fdump-system-exports"
  display all inbuilt system items.
  This is an internal command line option.
  .ie n .IP """\-fexceptions""" 4
! .el .IP \f(CW\-fexceptions\fR 4
  .IX Item "-fexceptions"
  turn on exception handling code.  By default this option is on.
  Exception handling can be disabled by \fB\-fno\-exceptions\fR
  and no references are made to the run time exception libraries.
  .ie n .IP """\-fextended\-opaque""" 4
! .el .IP \f(CW\-fextended\-opaque\fR 4
  .IX Item "-fextended-opaque"
! allows opaque types to be implemented as any type.  This is a GNU
  Modula\-2 extension and it requires that the implementation module
  defining the opaque type is available so that it can be resolved when
  compiling the module which imports the opaque type.
  .ie n .IP """\-ffloatvalue""" 4
! .el .IP \f(CW\-ffloatvalue\fR 4
  .IX Item "-ffloatvalue"
  turns on run time checking to check whether a floating point number is
  about to exceed range.
! .ie n .IP """\-fgen\-module\-list=\fIfilename\fR""" 4
! .el .IP \f(CW\-fgen\-module\-list=\fR\f(CIfilename\fR\f(CW\fR 4
  .IX Item "-fgen-module-list=filename"
  attempt to find all modules when linking and generate a module list.
  If the \fIfilename\fR is \fB\-\fR then the contents are not written
  and only used to force the linking of all module ctors.
  This option cannot be used if \fB\-fuse\-list=\fR is enabled.
  .ie n .IP """\-findex""" 4
! .el .IP \f(CW\-findex\fR 4
  .IX Item "-findex"
  generate code to check whether array index values are out of bounds.
  Array index checking can be disabled via \fB\-fno\-index\fR.
  .ie n .IP """\-fiso""" 4
! .el .IP \f(CW\-fiso\fR 4
  .IX Item "-fiso"
! turn on ISO standard features.  Currently this enables the ISO
  \&\f(CW\*(C`SYSTEM\*(C'\fR module and alters the default library search path so
! that the ISO libraries are searched before the PIM libraries.  It also
  effects the behavior of \f(CW\*(C`DIV\*(C'\fR and \f(CW\*(C`MOD\*(C'\fR operators.
  .ie n .IP """\-flibs=""" 4
! .el .IP \f(CW\-flibs=\fR 4
  .IX Item "-flibs="
  modifies the default library search path.  The libraries supplied are:
  m2pim, m2iso, m2min, m2log and m2cor.  These map onto the
! Programming in Modula\-2 base libraries, ISO standard libraries, minimal
  library support, Logitech compatible library and Programming in
  Modula\-2 with coroutines.
  Multiple libraries can be specified and are comma separated with precedence
*************** the they provide the base modules which
*** 270,281 ****
  The option \fB\-fno\-libs=\-\fR disables the \fBgm2\fR driver from
  modifying the search and library paths.
  .ie n .IP """\-static\-libgm2""" 4
! .el .IP "\f(CW\-static\-libgm2\fR" 4
  .IX Item "-static-libgm2"
  On systems that provide the m2 runtimes as both shared and static libraries,
  this option forces the use of the static version.
  .ie n .IP """\-fm2\-g""" 4
! .el .IP "\f(CW\-fm2\-g\fR" 4
  .IX Item "-fm2-g"
  improve the debugging experience for new programmers at the expense
  of generating \f(CW\*(C`nop\*(C'\fR instructions if necessary to ensure single
--- 195,206 ----
  The option \fB\-fno\-libs=\-\fR disables the \fBgm2\fR driver from
  modifying the search and library paths.
  .ie n .IP """\-static\-libgm2""" 4
! .el .IP \f(CW\-static\-libgm2\fR 4
  .IX Item "-static-libgm2"
  On systems that provide the m2 runtimes as both shared and static libraries,
  this option forces the use of the static version.
  .ie n .IP """\-fm2\-g""" 4
! .el .IP \f(CW\-fm2\-g\fR 4
  .IX Item "-fm2-g"
  improve the debugging experience for new programmers at the expense
  of generating \f(CW\*(C`nop\*(C'\fR instructions if necessary to ensure single
*************** of this is in termination of a list of n
*** 284,323 ****
  where multiple \f(CW\*(C`END\*(C'\fR keywords are mapped onto a sequence of
  \&\f(CW\*(C`nop\*(C'\fR instructions.
  .ie n .IP """\-fm2\-lower\-case""" 4
! .el .IP "\f(CW\-fm2\-lower\-case\fR" 4
  .IX Item "-fm2-lower-case"
  render keywords in error messages using lower case.
  .ie n .IP """\-fm2\-pathname=""" 4
! .el .IP "\f(CW\-fm2\-pathname=\fR" 4
  .IX Item "-fm2-pathname="
  specify the module mangled prefix name for all modules in the
  following include paths.
  .ie n .IP """\-fm2\-pathnameI""" 4
! .el .IP "\f(CW\-fm2\-pathnameI\fR" 4
  .IX Item "-fm2-pathnameI"
  for internal use only: used by the driver to copy the user facing \-I
  option.
  .ie n .IP """\-fm2\-plugin""" 4
! .el .IP "\f(CW\-fm2\-plugin\fR" 4
  .IX Item "-fm2-plugin"
  insert plugin to identify run time errors at compile time (default on).
  .ie n .IP """\-fm2\-prefix=""" 4
! .el .IP "\f(CW\-fm2\-prefix=\fR" 4
  .IX Item "-fm2-prefix="
  specify the module mangled prefix name.  All exported symbols from a
  definition module will have the prefix name.
  .ie n .IP """\-fm2\-statistics""" 4
! .el .IP "\f(CW\-fm2\-statistics\fR" 4
  .IX Item "-fm2-statistics"
  generates quadruple information: number of quadruples generated,
  number of quadruples remaining after optimization and number of source
  lines compiled.
  .ie n .IP """\-fm2\-strict\-type""" 4
! .el .IP "\f(CW\-fm2\-strict\-type\fR" 4
  .IX Item "-fm2-strict-type"
  experimental flag to turn on the new strict type checker.
  .ie n .IP """\-fm2\-whole\-program""" 4
! .el .IP "\f(CW\-fm2\-whole\-program\fR" 4
  .IX Item "-fm2-whole-program"
  compile all implementation modules and program module at once.  Notice
  that you need to take care if you are compiling different dialect
--- 209,248 ----
  where multiple \f(CW\*(C`END\*(C'\fR keywords are mapped onto a sequence of
  \&\f(CW\*(C`nop\*(C'\fR instructions.
  .ie n .IP """\-fm2\-lower\-case""" 4
! .el .IP \f(CW\-fm2\-lower\-case\fR 4
  .IX Item "-fm2-lower-case"
  render keywords in error messages using lower case.
  .ie n .IP """\-fm2\-pathname=""" 4
! .el .IP \f(CW\-fm2\-pathname=\fR 4
  .IX Item "-fm2-pathname="
  specify the module mangled prefix name for all modules in the
  following include paths.
  .ie n .IP """\-fm2\-pathnameI""" 4
! .el .IP \f(CW\-fm2\-pathnameI\fR 4
  .IX Item "-fm2-pathnameI"
  for internal use only: used by the driver to copy the user facing \-I
  option.
  .ie n .IP """\-fm2\-plugin""" 4
! .el .IP \f(CW\-fm2\-plugin\fR 4
  .IX Item "-fm2-plugin"
  insert plugin to identify run time errors at compile time (default on).
  .ie n .IP """\-fm2\-prefix=""" 4
! .el .IP \f(CW\-fm2\-prefix=\fR 4
  .IX Item "-fm2-prefix="
  specify the module mangled prefix name.  All exported symbols from a
  definition module will have the prefix name.
  .ie n .IP """\-fm2\-statistics""" 4
! .el .IP \f(CW\-fm2\-statistics\fR 4
  .IX Item "-fm2-statistics"
  generates quadruple information: number of quadruples generated,
  number of quadruples remaining after optimization and number of source
  lines compiled.
  .ie n .IP """\-fm2\-strict\-type""" 4
! .el .IP \f(CW\-fm2\-strict\-type\fR 4
  .IX Item "-fm2-strict-type"
  experimental flag to turn on the new strict type checker.
  .ie n .IP """\-fm2\-whole\-program""" 4
! .el .IP \f(CW\-fm2\-whole\-program\fR 4
  .IX Item "-fm2-whole-program"
  compile all implementation modules and program module at once.  Notice
  that you need to take care if you are compiling different dialect
*************** modules (particularly with the negative
*** 325,394 ****
  this option, when coupled together with \f(CW\*(C`\-O3\*(C'\fR, can deliver huge
  performance improvements.
  .ie n .IP """\-fmod=""" 4
! .el .IP "\f(CW\-fmod=\fR" 4
  .IX Item "-fmod="
  recognize the specified suffix as implementation and module filenames.
  The default implementation and module filename suffix is \fI.mod\fR.
! If this option is used \s-1GNU\s0 Modula\-2 will still fall back to this
  default if it needs to read an implementation module and the specified
  suffixed filename does not exist.
  .ie n .IP """\-fnil""" 4
! .el .IP "\f(CW\-fnil\fR" 4
  .IX Item "-fnil"
  generate code to detect accessing data through a \f(CW\*(C`NIL\*(C'\fR value
  pointer.  Dereferencing checking through a \f(CW\*(C`NIL\*(C'\fR pointer can be
  disabled by \fB\-fno\-nil\fR.
  .ie n .IP """\-fpim""" 4
! .el .IP "\f(CW\-fpim\fR" 4
  .IX Item "-fpim"
! turn on \s-1PIM\s0 standard features.  Currently this enables the \s-1PIM\s0
  \&\f(CW\*(C`SYSTEM\*(C'\fR module and determines which identifiers are pervasive
  (declared in the base module).  If no other \fB\-fpim[234]\fR switch is
! used then division and modulus operators behave as defined in \s-1PIM4.\s0
  .ie n .IP """\-fpim2""" 4
! .el .IP "\f(CW\-fpim2\fR" 4
  .IX Item "-fpim2"
! turn on \s-1PIM\-2\s0 standard features.  Currently this removes \f(CW\*(C`SIZE\*(C'\fR
  from being a pervasive identifier (declared in the base module).  It
  places \f(CW\*(C`SIZE\*(C'\fR in the \f(CW\*(C`SYSTEM\*(C'\fR module.  It also effects the
  behavior of \f(CW\*(C`DIV\*(C'\fR and \f(CW\*(C`MOD\*(C'\fR operators.
  .ie n .IP """\-fpim3""" 4
! .el .IP "\f(CW\-fpim3\fR" 4
  .IX Item "-fpim3"
! turn on \s-1PIM\-3\s0 standard features.  Currently this only effects the
  behavior of \f(CW\*(C`DIV\*(C'\fR and \f(CW\*(C`MOD\*(C'\fR operators.
  .ie n .IP """\-fpim4""" 4
! .el .IP "\f(CW\-fpim4\fR" 4
  .IX Item "-fpim4"
! turn on \s-1PIM\-4\s0 standard features.  Currently this only effects the
  behavior of \f(CW\*(C`DIV\*(C'\fR and \f(CW\*(C`MOD\*(C'\fR operators.
  .ie n .IP """\-fpositive\-mod\-floor\-div""" 4
! .el .IP "\f(CW\-fpositive\-mod\-floor\-div\fR" 4
  .IX Item "-fpositive-mod-floor-div"
! forces the \f(CW\*(C`DIV\*(C'\fR and \f(CW\*(C`MOD\*(C'\fR operators to behave as defined by \s-1PIM4.\s0
  All modulus results are positive and the results from the division are
  rounded to the floor.
  .ie n .IP """\-fpthread""" 4
! .el .IP "\f(CW\-fpthread\fR" 4
  .IX Item "-fpthread"
  link against the pthread library.  By default this option is on.  It
! can be disabled by \fB\-fno\-pthread\fR.  \s-1GNU\s0 Modula\-2 uses the \s-1GCC\s0
! pthread libraries to implement coroutines (see the \s-1SYSTEM\s0
  implementation module).
  .ie n .IP """\-frange""" 4
! .el .IP "\f(CW\-frange\fR" 4
  .IX Item "-frange"
  generate code to check the assignment range, return value range
  set range and constructor range.  Range checking can be disabled
  via \fB\-fno\-range\fR.
  .ie n .IP """\-freturn""" 4
! .el .IP "\f(CW\-freturn\fR" 4
  .IX Item "-freturn"
  generate code to check that functions always exit with a \f(CW\*(C`RETURN\*(C'\fR
  and do not fall out at the end.  Return checking can be disabled
  via \fB\-fno\-return\fR.
  .ie n .IP """\-fruntime\-modules=""" 4
! .el .IP "\f(CW\-fruntime\-modules=\fR" 4
  .IX Item "-fruntime-modules="
  specify, using a comma separated list, the run time modules and their
  order.  These modules will initialized first before any other modules
--- 250,319 ----
  this option, when coupled together with \f(CW\*(C`\-O3\*(C'\fR, can deliver huge
  performance improvements.
  .ie n .IP """\-fmod=""" 4
! .el .IP \f(CW\-fmod=\fR 4
  .IX Item "-fmod="
  recognize the specified suffix as implementation and module filenames.
  The default implementation and module filename suffix is \fI.mod\fR.
! If this option is used GNU Modula\-2 will still fall back to this
  default if it needs to read an implementation module and the specified
  suffixed filename does not exist.
  .ie n .IP """\-fnil""" 4
! .el .IP \f(CW\-fnil\fR 4
  .IX Item "-fnil"
  generate code to detect accessing data through a \f(CW\*(C`NIL\*(C'\fR value
  pointer.  Dereferencing checking through a \f(CW\*(C`NIL\*(C'\fR pointer can be
  disabled by \fB\-fno\-nil\fR.
  .ie n .IP """\-fpim""" 4
! .el .IP \f(CW\-fpim\fR 4
  .IX Item "-fpim"
! turn on PIM standard features.  Currently this enables the PIM
  \&\f(CW\*(C`SYSTEM\*(C'\fR module and determines which identifiers are pervasive
  (declared in the base module).  If no other \fB\-fpim[234]\fR switch is
! used then division and modulus operators behave as defined in PIM4.
  .ie n .IP """\-fpim2""" 4
! .el .IP \f(CW\-fpim2\fR 4
  .IX Item "-fpim2"
! turn on PIM\-2 standard features.  Currently this removes \f(CW\*(C`SIZE\*(C'\fR
  from being a pervasive identifier (declared in the base module).  It
  places \f(CW\*(C`SIZE\*(C'\fR in the \f(CW\*(C`SYSTEM\*(C'\fR module.  It also effects the
  behavior of \f(CW\*(C`DIV\*(C'\fR and \f(CW\*(C`MOD\*(C'\fR operators.
  .ie n .IP """\-fpim3""" 4
! .el .IP \f(CW\-fpim3\fR 4
  .IX Item "-fpim3"
! turn on PIM\-3 standard features.  Currently this only effects the
  behavior of \f(CW\*(C`DIV\*(C'\fR and \f(CW\*(C`MOD\*(C'\fR operators.
  .ie n .IP """\-fpim4""" 4
! .el .IP \f(CW\-fpim4\fR 4
  .IX Item "-fpim4"
! turn on PIM\-4 standard features.  Currently this only effects the
  behavior of \f(CW\*(C`DIV\*(C'\fR and \f(CW\*(C`MOD\*(C'\fR operators.
  .ie n .IP """\-fpositive\-mod\-floor\-div""" 4
! .el .IP \f(CW\-fpositive\-mod\-floor\-div\fR 4
  .IX Item "-fpositive-mod-floor-div"
! forces the \f(CW\*(C`DIV\*(C'\fR and \f(CW\*(C`MOD\*(C'\fR operators to behave as defined by PIM4.
  All modulus results are positive and the results from the division are
  rounded to the floor.
  .ie n .IP """\-fpthread""" 4
! .el .IP \f(CW\-fpthread\fR 4
  .IX Item "-fpthread"
  link against the pthread library.  By default this option is on.  It
! can be disabled by \fB\-fno\-pthread\fR.  GNU Modula\-2 uses the GCC
! pthread libraries to implement coroutines (see the SYSTEM
  implementation module).
  .ie n .IP """\-frange""" 4
! .el .IP \f(CW\-frange\fR 4
  .IX Item "-frange"
  generate code to check the assignment range, return value range
  set range and constructor range.  Range checking can be disabled
  via \fB\-fno\-range\fR.
  .ie n .IP """\-freturn""" 4
! .el .IP \f(CW\-freturn\fR 4
  .IX Item "-freturn"
  generate code to check that functions always exit with a \f(CW\*(C`RETURN\*(C'\fR
  and do not fall out at the end.  Return checking can be disabled
  via \fB\-fno\-return\fR.
  .ie n .IP """\-fruntime\-modules=""" 4
! .el .IP \f(CW\-fruntime\-modules=\fR 4
  .IX Item "-fruntime-modules="
  specify, using a comma separated list, the run time modules and their
  order.  These modules will initialized first before any other modules
*************** Adding a long list of dependent modules
*** 400,426 ****
  the executable it merely states the initialization order should they
  be required.
  .ie n .IP """\-fscaffold\-dynamic""" 4
! .el .IP "\f(CW\-fscaffold\-dynamic\fR" 4
  .IX Item "-fscaffold-dynamic"
  the option ensures that \fBgm2\fR will generate a dynamic scaffold
  infrastructure when compiling implementation and program modules.
  By default this option is on.  Use \fB\-fno\-scaffold\-dynamic\fR
  to turn it off or select \fB\-fno\-scaffold\-static\fR.
  .ie n .IP """\-fscaffold\-c""" 4
! .el .IP "\f(CW\-fscaffold\-c\fR" 4
  .IX Item "-fscaffold-c"
  generate a C source scaffold for the current module being compiled.
  .ie n .IP """\-fscaffold\-c++""" 4
! .el .IP "\f(CW\-fscaffold\-c++\fR" 4
  .IX Item "-fscaffold-c++"
! generate a \*(C+ source scaffold for the current module being compiled.
  .ie n .IP """\-fscaffold\-main""" 4
! .el .IP "\f(CW\-fscaffold\-main\fR" 4
  .IX Item "-fscaffold-main"
  force the generation of the \fBmain\fR function.  This is not
  necessary if the \fB\-c\fR is omitted.
  .ie n .IP """\-fscaffold\-static""" 4
! .el .IP "\f(CW\-fscaffold\-static\fR" 4
  .IX Item "-fscaffold-static"
  the option ensures that \fBgm2\fR will generate a static scaffold
  within the program module.  The static scaffold consists of sequences
--- 325,351 ----
  the executable it merely states the initialization order should they
  be required.
  .ie n .IP """\-fscaffold\-dynamic""" 4
! .el .IP \f(CW\-fscaffold\-dynamic\fR 4
  .IX Item "-fscaffold-dynamic"
  the option ensures that \fBgm2\fR will generate a dynamic scaffold
  infrastructure when compiling implementation and program modules.
  By default this option is on.  Use \fB\-fno\-scaffold\-dynamic\fR
  to turn it off or select \fB\-fno\-scaffold\-static\fR.
  .ie n .IP """\-fscaffold\-c""" 4
! .el .IP \f(CW\-fscaffold\-c\fR 4
  .IX Item "-fscaffold-c"
  generate a C source scaffold for the current module being compiled.
  .ie n .IP """\-fscaffold\-c++""" 4
! .el .IP \f(CW\-fscaffold\-c++\fR 4
  .IX Item "-fscaffold-c++"
! generate a C++ source scaffold for the current module being compiled.
  .ie n .IP """\-fscaffold\-main""" 4
! .el .IP \f(CW\-fscaffold\-main\fR 4
  .IX Item "-fscaffold-main"
  force the generation of the \fBmain\fR function.  This is not
  necessary if the \fB\-c\fR is omitted.
  .ie n .IP """\-fscaffold\-static""" 4
! .el .IP \f(CW\-fscaffold\-static\fR 4
  .IX Item "-fscaffold-static"
  the option ensures that \fBgm2\fR will generate a static scaffold
  within the program module.  The static scaffold consists of sequences
*************** of calls to all dependent module initial
*** 428,460 ****
  procedures.  The static scaffold is useful for debugging and single
  stepping the initialization blocks of implementation modules.
  .ie n .IP """\-fshared""" 4
! .el .IP "\f(CW\-fshared\fR" 4
  .IX Item "-fshared"
  generate a shared library from the module.
  .ie n .IP """\-fsoft\-check\-all""" 4
! .el .IP "\f(CW\-fsoft\-check\-all\fR" 4
  .IX Item "-fsoft-check-all"
  turns on all run time checks.  This is the same as invoking
! \&\s-1GNU\s0 Modula\-2 using the command options
  \&\f(CW\*(C`\-fnil\*(C'\fR \f(CW\*(C`\-frange\*(C'\fR \f(CW\*(C`\-findex\*(C'\fR
  \&\f(CW\*(C`\-fwholevalue\*(C'\fR
  \&\f(CW\*(C`\-fwholediv\*(C'\fR \f(CW\*(C`\-fcase\*(C'\fR \f(CW\*(C`\-freturn\*(C'\fR.
  .ie n .IP """\-fsources""" 4
! .el .IP "\f(CW\-fsources\fR" 4
  .IX Item "-fsources"
  displays the path to the source of each module.  This option
  can be used at compile time to check the correct definition module
  is being used.
  .ie n .IP """\-fswig""" 4
! .el .IP "\f(CW\-fswig\fR" 4
  .IX Item "-fswig"
  generate a swig interface file.
  .ie n .IP """\-funbounded\-by\-reference""" 4
! .el .IP "\f(CW\-funbounded\-by\-reference\fR" 4
  .IX Item "-funbounded-by-reference"
  enable optimization of unbounded parameters by attempting to pass non
  \&\f(CW\*(C`VAR\*(C'\fR unbounded parameters by reference.  This optimization
! avoids the implicit copy inside the callee procedure.  \s-1GNU\s0 Modula\-2
  will only allow unbounded parameters to be passed by reference if,
  inside the callee procedure, they are not written to, no address is
  calculated on the array and it is not passed as a \f(CW\*(C`VAR\*(C'\fR
--- 353,385 ----
  procedures.  The static scaffold is useful for debugging and single
  stepping the initialization blocks of implementation modules.
  .ie n .IP """\-fshared""" 4
! .el .IP \f(CW\-fshared\fR 4
  .IX Item "-fshared"
  generate a shared library from the module.
  .ie n .IP """\-fsoft\-check\-all""" 4
! .el .IP \f(CW\-fsoft\-check\-all\fR 4
  .IX Item "-fsoft-check-all"
  turns on all run time checks.  This is the same as invoking
! GNU Modula\-2 using the command options
  \&\f(CW\*(C`\-fnil\*(C'\fR \f(CW\*(C`\-frange\*(C'\fR \f(CW\*(C`\-findex\*(C'\fR
  \&\f(CW\*(C`\-fwholevalue\*(C'\fR
  \&\f(CW\*(C`\-fwholediv\*(C'\fR \f(CW\*(C`\-fcase\*(C'\fR \f(CW\*(C`\-freturn\*(C'\fR.
  .ie n .IP """\-fsources""" 4
! .el .IP \f(CW\-fsources\fR 4
  .IX Item "-fsources"
  displays the path to the source of each module.  This option
  can be used at compile time to check the correct definition module
  is being used.
  .ie n .IP """\-fswig""" 4
! .el .IP \f(CW\-fswig\fR 4
  .IX Item "-fswig"
  generate a swig interface file.
  .ie n .IP """\-funbounded\-by\-reference""" 4
! .el .IP \f(CW\-funbounded\-by\-reference\fR 4
  .IX Item "-funbounded-by-reference"
  enable optimization of unbounded parameters by attempting to pass non
  \&\f(CW\*(C`VAR\*(C'\fR unbounded parameters by reference.  This optimization
! avoids the implicit copy inside the callee procedure.  GNU Modula\-2
  will only allow unbounded parameters to be passed by reference if,
  inside the callee procedure, they are not written to, no address is
  calculated on the array and it is not passed as a \f(CW\*(C`VAR\*(C'\fR
*************** the procedure and write to the location
*** 466,473 ****
  .Sp
  Due to the dangerous nature of this option it is not enabled
  when the \fB\-O\fR option is specified.
! .ie n .IP """\-fuse\-list=\fIfilename\fP""" 4
! .el .IP "\f(CW\-fuse\-list=\f(CIfilename\f(CW\fR" 4
  .IX Item "-fuse-list=filename"
  if \fB\-fscaffold\-static\fR is enabled then use the file
  \&\fIfilename\fR for the initialization order of modules.  Whereas if
--- 391,398 ----
  .Sp
  Due to the dangerous nature of this option it is not enabled
  when the \fB\-O\fR option is specified.
! .ie n .IP """\-fuse\-list=\fIfilename\fR""" 4
! .el .IP \f(CW\-fuse\-list=\fR\f(CIfilename\fR\f(CW\fR 4
  .IX Item "-fuse-list=filename"
  if \fB\-fscaffold\-static\fR is enabled then use the file
  \&\fIfilename\fR for the initialization order of modules.  Whereas if
*************** if \fB\-fscaffold\-static\fR is enabled
*** 475,490 ****
  linking of all module ctors.
  This option cannot be used if \fB\-fgen\-module\-list=\fR is enabled.
  .ie n .IP """\-fwholediv""" 4
! .el .IP "\f(CW\-fwholediv\fR" 4
  .IX Item "-fwholediv"
  generate code to detect whole number division by zero or modulus by
  zero.
  .ie n .IP """\-fwholevalue""" 4
! .el .IP "\f(CW\-fwholevalue\fR" 4
  .IX Item "-fwholevalue"
  generate code to detect whole number overflow and underflow.
  .ie n .IP """\-Wcase\-enum""" 4
! .el .IP "\f(CW\-Wcase\-enum\fR" 4
  .IX Item "-Wcase-enum"
  generate a warning if a \f(CW\*(C`CASE\*(C'\fR statement selects on an enumerated
  type expression and the statement is missing one or more \f(CW\*(C`CASE\*(C'\fR
--- 400,415 ----
  linking of all module ctors.
  This option cannot be used if \fB\-fgen\-module\-list=\fR is enabled.
  .ie n .IP """\-fwholediv""" 4
! .el .IP \f(CW\-fwholediv\fR 4
  .IX Item "-fwholediv"
  generate code to detect whole number division by zero or modulus by
  zero.
  .ie n .IP """\-fwholevalue""" 4
! .el .IP \f(CW\-fwholevalue\fR 4
  .IX Item "-fwholevalue"
  generate code to detect whole number overflow and underflow.
  .ie n .IP """\-Wcase\-enum""" 4
! .el .IP \f(CW\-Wcase\-enum\fR 4
  .IX Item "-Wcase-enum"
  generate a warning if a \f(CW\*(C`CASE\*(C'\fR statement selects on an enumerated
  type expression and the statement is missing one or more \f(CW\*(C`CASE\*(C'\fR
*************** labels.  No warning is issued if the \f(
*** 492,504 ****
  \&\f(CW\*(C`ELSE\*(C'\fR clause.
  The option \fB\-Wall\fR will turn on this flag.
  .ie n .IP """\-Wuninit\-variable\-checking""" 4
! .el .IP "\f(CW\-Wuninit\-variable\-checking\fR" 4
  .IX Item "-Wuninit-variable-checking"
  issue a warning if a variable is used before it is initialized.
  The checking only occurs in the first basic block in each procedure.
  It does not check parameters, array types or set types.
  .ie n .IP """\-Wuninit\-variable\-checking=all,known,cond""" 4
! .el .IP "\f(CW\-Wuninit\-variable\-checking=all,known,cond\fR" 4
  .IX Item "-Wuninit-variable-checking=all,known,cond"
  issue a warning if a variable is used before it is initialized.
  The checking will only occur in the first basic block in each
--- 417,429 ----
  \&\f(CW\*(C`ELSE\*(C'\fR clause.
  The option \fB\-Wall\fR will turn on this flag.
  .ie n .IP """\-Wuninit\-variable\-checking""" 4
! .el .IP \f(CW\-Wuninit\-variable\-checking\fR 4
  .IX Item "-Wuninit-variable-checking"
  issue a warning if a variable is used before it is initialized.
  The checking only occurs in the first basic block in each procedure.
  It does not check parameters, array types or set types.
  .ie n .IP """\-Wuninit\-variable\-checking=all,known,cond""" 4
! .el .IP \f(CW\-Wuninit\-variable\-checking=all,known,cond\fR 4
  .IX Item "-Wuninit-variable-checking=all,known,cond"
  issue a warning if a variable is used before it is initialized.
  The checking will only occur in the first basic block in each
*************** The \fB\-Wuninit\-variable\-checking=all
*** 513,525 ****
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7), \fBgcc\fR\|(1)
  and the Info entries for \fIgm2\fR and \fIgcc\fR.
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 1999\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with no
! Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
  A copy of the license is included in the
  man page \fBgfdl\fR\|(7).
--- 438,450 ----
  .IX Header "SEE ALSO"
  \&\fBgpl\fR\|(7), \fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7), \fBgcc\fR\|(1)
  and the Info entries for \fIgm2\fR and \fIgcc\fR.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 1999\-2023 Free Software Foundation, Inc.
  .PP
  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
  man page \fBgfdl\fR\|(7).
diff -Nrcpad gcc-13.4.0/gcc/doc/gnat-style.info gcc-13.5.0-RC-20260904/gcc/doc/gnat-style.info
*** gcc-13.4.0/gcc/doc/gnat-style.info	Thu Jun  5 16:30:26 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gnat-style.info	Fri Sep  4 07:57:47 2026
***************
*** 1,4 ****
! This is gnat-style.info, produced by makeinfo version 6.8 from
  gnat-style.texi.
  
       GNAT Coding Style: A Guide for GNAT Developers , Aug 25, 2022
--- 1,4 ----
! This is gnat-style.info, produced by makeinfo version 7.1 from
  gnat-style.texi.
  
       GNAT Coding Style: A Guide for GNAT Developers , Aug 25, 2022
*************** File: gnat-style.info,  Node: Comments,
*** 170,176 ****
       comments after the declaration, there is no blank line before the
       comment, and if it is absolutely necessary to have blank lines
       within the comments, e.g.  to make paragraph separations within a
!      single comment, these blank lines ‘do’ have a ‘--’ (unlike the
       normal rule, which is to use entirely blank lines for separating
       comment paragraphs).  The comment starts at same level of
       indentation as code it is commenting.
--- 170,176 ----
       comments after the declaration, there is no blank line before the
       comment, and if it is absolutely necessary to have blank lines
       within the comments, e.g.  to make paragraph separations within a
!      single comment, these blank lines 'do' have a ‘--’ (unlike the
       normal rule, which is to use entirely blank lines for separating
       comment paragraphs).  The comment starts at same level of
       indentation as code it is commenting.
*************** File: gnat-style.info,  Node: Comments,
*** 204,214 ****
            My_Identifier := 5;      --  First comment
            Other_Id := 6;           --  Second comment
  
!    * Short comments that fit on a single line are ‘not’ ended with a
       period.  Comments taking more than a line are punctuated in the
       normal manner.
  
!    * Comments should focus on ‘why’ instead of ‘what’.  Descriptions of
       what subprograms do go with the specification.
  
     * Comments describing a subprogram spec should specifically mention
--- 204,214 ----
            My_Identifier := 5;      --  First comment
            Other_Id := 6;           --  Second comment
  
!    * Short comments that fit on a single line are 'not' ended with a
       period.  Comments taking more than a line are punctuated in the
       normal manner.
  
!    * Comments should focus on 'why' instead of 'what'.  Descriptions of
       what subprograms do go with the specification.
  
     * Comments describing a subprogram spec should specifically mention
*************** File: gnat-style.info,  Node: Comments,
*** 216,222 ****
       not depend on the names of things.  The names are supplementary,
       not sufficient, as comments.
  
!    * ‘Do not’ put two spaces after periods in comments.
  
  
  File: gnat-style.info,  Node: Declarations and Types,  Next: Expressions and Names,  Prev: Lexical Elements,  Up: Top
--- 216,222 ----
       not depend on the names of things.  The names are supplementary,
       not sufficient, as comments.
  
!    * 'Do not' put two spaces after periods in comments.
  
  
  File: gnat-style.info,  Node: Declarations and Types,  Next: Expressions and Names,  Prev: Lexical Elements,  Up: Top
*************** Copyright 2000, 2001, 2002, 2007, 2008 F
*** 704,710 ****
  Everyone is permitted to copy and distribute verbatim copies of this
  license document, but changing it is not allowed.
  
! ‘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
--- 704,710 ----
  Everyone is permitted to copy and distribute verbatim copies of this
  license document, but changing it is not allowed.
  
! '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
*************** used for any textual work, regardless of
*** 727,748 ****
  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
--- 727,748 ----
  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
*************** mathematics.)  The relationship could be
*** 752,758 ****
  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
--- 752,758 ----
  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 Documen
*** 760,771 ****
  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
--- 760,771 ----
  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
*************** formatters.  A copy made in an otherwise
*** 776,782 ****
  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
--- 776,782 ----
  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
*************** processing tools are not generally avail
*** 789,810 ****
  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
--- 789,810 ----
  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
*************** but only as regards disclaiming warranti
*** 814,820 ****
  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
--- 814,820 ----
  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
*************** number of copies you must also follow th
*** 829,835 ****
  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
--- 829,835 ----
  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
*************** It is requested, but not required, that
*** 866,872 ****
  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
--- 866,872 ----
  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
*************** The author(s) and publisher(s) of the Do
*** 964,970 ****
  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
--- 964,970 ----
  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
*************** likewise combine any sections Entitled 
*** 988,994 ****
  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
--- 988,994 ----
  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
*************** it individually under this License, prov
*** 1001,1007 ****
  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
--- 1001,1007 ----
  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
*************** that bracket the Document within the agg
*** 1019,1025 ****
  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
--- 1019,1025 ----
  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
*************** If a section in the Document is Entitled
*** 1038,1044 ****
  “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
--- 1038,1044 ----
  “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
*************** this License.  If your rights have been
*** 1065,1071 ****
  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
--- 1065,1071 ----
  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
*************** that a proxy can decide which future ver
*** 1085,1091 ****
  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
--- 1085,1091 ----
  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
*************** The operator of an MMC Site may republis
*** 1113,1119 ****
  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
--- 1113,1119 ----
  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
*************** Ref: 74480
*** 1231,1283 ****
  Node: Comments4698
  Ref: gnat-style comments4786
  Ref: 84786
! Node: Declarations and Types7318
! Ref: gnat-style declarations-and-types7439
! Ref: 97439
! Node: Expressions and Names8918
! Ref: gnat-style expressions-and-names9033
! Ref: a9033
! Node: Statements9561
! Ref: gnat-style statements9665
! Ref: b9665
! Node: Simple and Compound Statements9816
! Ref: gnat-style simple-and-compound-statements9919
! Ref: c9919
! Node: If Statements10169
! Ref: gnat-style if-statements10296
! Ref: d10296
! Node: Case Statements12771
! Ref: gnat-style case-statements12883
! Ref: e12883
! Node: Loop Statements13244
! Ref: gnat-style loop-statements13359
! Ref: f13359
! Node: Block Statements14056
! Ref: gnat-style block-statements14147
! Ref: 1014147
! Node: Subprograms14487
! Ref: gnat-style subprograms14599
! Ref: 1114599
! Node: Subprogram Declarations14688
! Ref: gnat-style subprogram-declarations14789
! Ref: 1214789
! Node: Subprogram Bodies16449
! Ref: gnat-style subprogram-bodies16550
! Ref: 1316550
! Node: Packages and Visibility Rules20286
! Ref: gnat-style packages-and-visibility-rules20428
! Ref: 1420428
! Node: Program Structure and Compilation Issues21451
! Ref: gnat-style program-structure-and-compilation-issues21587
! Ref: 1521587
! Node: GNU Free Documentation License22300
! Ref: share/gnu_free_documentation_license doc22411
! Ref: 1622411
! Ref: share/gnu_free_documentation_license gnu-fdl22411
! Ref: 1722411
! Ref: share/gnu_free_documentation_license gnu-free-documentation-license22411
! Ref: 1822411
! Node: Index45871
  
  End Tag Table
  
--- 1231,1283 ----
  Node: Comments4698
  Ref: gnat-style comments4786
  Ref: 84786
! Node: Declarations and Types7298
! Ref: gnat-style declarations-and-types7419
! Ref: 97419
! Node: Expressions and Names8898
! Ref: gnat-style expressions-and-names9013
! Ref: a9013
! Node: Statements9541
! Ref: gnat-style statements9645
! Ref: b9645
! Node: Simple and Compound Statements9796
! Ref: gnat-style simple-and-compound-statements9899
! Ref: c9899
! Node: If Statements10149
! Ref: gnat-style if-statements10276
! Ref: d10276
! Node: Case Statements12751
! Ref: gnat-style case-statements12863
! Ref: e12863
! Node: Loop Statements13224
! Ref: gnat-style loop-statements13339
! Ref: f13339
! Node: Block Statements14036
! Ref: gnat-style block-statements14127
! Ref: 1014127
! Node: Subprograms14467
! Ref: gnat-style subprograms14579
! Ref: 1114579
! Node: Subprogram Declarations14668
! Ref: gnat-style subprogram-declarations14769
! Ref: 1214769
! Node: Subprogram Bodies16429
! Ref: gnat-style subprogram-bodies16530
! Ref: 1316530
! Node: Packages and Visibility Rules20266
! Ref: gnat-style packages-and-visibility-rules20408
! Ref: 1420408
! Node: Program Structure and Compilation Issues21431
! Ref: gnat-style program-structure-and-compilation-issues21567
! Ref: 1521567
! Node: GNU Free Documentation License22280
! Ref: share/gnu_free_documentation_license doc22391
! Ref: 1622391
! Ref: share/gnu_free_documentation_license gnu-fdl22391
! Ref: 1722391
! Ref: share/gnu_free_documentation_license gnu-free-documentation-license22391
! Ref: 1822391
! Node: Index45735
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/doc/gnat_rm.info gcc-13.5.0-RC-20260904/gcc/doc/gnat_rm.info
*** gcc-13.4.0/gcc/doc/gnat_rm.info	Thu Jun  5 16:30:26 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gnat_rm.info	Fri Sep  4 07:57:47 2026
***************
*** 1,4 ****
! This is gnat_rm.info, produced by makeinfo version 6.8 from
  gnat_rm.texi.
  
       GNAT Reference Manual , Dec 01, 2022
--- 1,4 ----
! This is gnat_rm.info, produced by makeinfo version 7.1 from
  gnat_rm.texi.
  
       GNAT Reference Manual , Dec 01, 2022
*************** GNAT Reference Manual
*** 27,35 ****
  
       Copyright © 2008-2023, Free Software Foundation
  
! ‘GNAT, The GNU Ada Development Environment’
  
! GCC version 13.4.0
  AdaCore
  
  Permission is granted to copy, distribute and/or modify this document
--- 27,35 ----
  
       Copyright © 2008-2023, Free Software Foundation
  
! 'GNAT, The GNU Ada Development Environment'
  
! GCC version 13.4.1
  AdaCore
  
  Permission is granted to copy, distribute and/or modify this document
*************** included in the section entitled *note G
*** 64,70 ****
  * GNU Free Documentation License::
  * Index::
  
!  — The Detailed Node Listing —
  
  About This Guide
  
--- 64,70 ----
  * GNU Free Documentation License::
  * Index::
  
!  -- The Detailed Node Listing --
  
  About This Guide
  
*************** M of the Ada language standard.
*** 905,911 ****
  GNAT implements Ada 95, Ada 2005 and Ada 2012, and it may also be
  invoked in Ada 83 compatibility mode.  By default, GNAT assumes Ada
  2012, but you can override with a compiler switch to explicitly specify
! the language version.  (Please refer to the ‘GNAT User’s Guide’ for
  details on these switches.)  Throughout this manual, references to ‘Ada’
  without a year suffix apply to all the Ada versions of the language.
  
--- 905,911 ----
  GNAT implements Ada 95, Ada 2005 and Ada 2012, and it may also be
  invoked in Ada 83 compatibility mode.  By default, GNAT assumes Ada
  2012, but you can override with a compiler switch to explicitly specify
! the language version.  (Please refer to the 'GNAT User’s Guide' for
  details on these switches.)  Throughout this manual, references to ‘Ada’
  without a year suffix apply to all the Ada versions of the language.
  
*************** in this guide:
*** 1029,1035 ****
  
     * ‘Variables’
  
!    * ‘Emphasis’
  
     * [optional information or parameters]
  
--- 1029,1035 ----
  
     * ‘Variables’
  
!    * 'Emphasis'
  
     * [optional information or parameters]
  
*************** from this standard type.
*** 1663,1669 ****
  
  Assert checks can be either checked or ignored.  By default they are
  ignored.  They will be checked if either the command line switch
! ‘-gnata’ is used, or if an ‘Assertion_Policy’ or ‘Check_Policy’ pragma
  is used to enable ‘Assert_Checks’.
  
  If assertions are ignored, then there is no run-time effect (and in
--- 1663,1669 ----
  
  Assert checks can be either checked or ignored.  By default they are
  ignored.  They will be checked if either the command line switch
! '-gnata' is used, or if an ‘Assertion_Policy’ or ‘Check_Policy’ pragma
  is used to enable ‘Assert_Checks’.
  
  If assertions are ignored, then there is no run-time effect (and in
*************** intended to be identical to the correspo
*** 1777,1785 ****
  If the policy is ‘CHECK’, then assertions are enabled, i.e.  the
  corresponding pragma or aspect is activated.  If the policy is ‘IGNORE’,
  then assertions are ignored, i.e.  the corresponding pragma or aspect is
! deactivated.  This pragma overrides the effect of the ‘-gnata’ switch on
  the command line.  If the policy is ‘SUPPRESSIBLE’, then assertions are
! enabled by default, however, if the ‘-gnatp’ switch is specified all
  assertions are ignored.
  
  The implementation defined policy ‘DISABLE’ is like ‘IGNORE’ except that
--- 1777,1785 ----
  If the policy is ‘CHECK’, then assertions are enabled, i.e.  the
  corresponding pragma or aspect is activated.  If the policy is ‘IGNORE’,
  then assertions are ignored, i.e.  the corresponding pragma or aspect is
! deactivated.  This pragma overrides the effect of the '-gnata' switch on
  the command line.  If the policy is ‘SUPPRESSIBLE’, then assertions are
! enabled by default, however, if the '-gnatp' switch is specified all
  assertions are ignored.
  
  The implementation defined policy ‘DISABLE’ is like ‘IGNORE’ except that
*************** be independently controlled.  The identi
*** 1981,1987 ****
  refers to the normal set of pragma ‘Assert’ statements.
  
  Checks introduced by this pragma are normally deactivated by default.
! They can be activated either by the command line option ‘-gnata’, which
  turns on all checks, or individually controlled using pragma
  ‘Check_Policy’.
  
--- 1981,1987 ----
  refers to the normal set of pragma ‘Assert’ statements.
  
  Checks introduced by this pragma are normally deactivated by default.
! They can be activated either by the command line option '-gnata', which
  turns on all checks, or individually controlled using pragma
  ‘Check_Policy’.
  
*************** Syntax:
*** 2001,2007 ****
       pragma Check_Float_Overflow;
  
  In Ada, the predefined floating-point types (‘Short_Float’, ‘Float’,
! ‘Long_Float’, ‘Long_Long_Float’) are defined to be ‘unconstrained’.
  This means that even though each has a well-defined base range, an
  operation that delivers a result outside this base range is not required
  to raise an exception.  This implementation permission accommodates the
--- 2001,2007 ----
       pragma Check_Float_Overflow;
  
  In Ada, the predefined floating-point types (‘Short_Float’, ‘Float’,
! ‘Long_Float’, ‘Long_Long_Float’) are defined to be 'unconstrained'.
  This means that even though each has a well-defined base range, an
  operation that delivers a result outside this base range is not required
  to raise an exception.  This implementation permission accommodates the
*************** base types of these floating-point types
*** 2033,2039 ****
  types were constrained, and overflow checks will be generated.  The
  ‘Constraint_Error’ exception is raised if the result is out of range.
  
! This mode can also be set by use of the compiler switch ‘-gnateF’.
  
  
  File: gnat_rm.info,  Node: Pragma Check_Name,  Next: Pragma Check_Policy,  Prev: Pragma Check_Float_Overflow,  Up: Implementation Defined Pragmas
--- 2033,2039 ----
  types were constrained, and overflow checks will be generated.  The
  ‘Constraint_Error’ exception is raised if the result is out of range.
  
! This mode can also be set by use of the compiler switch '-gnateF'.
  
  
  File: gnat_rm.info,  Node: Pragma Check_Name,  Next: Pragma Check_Policy,  Prev: Pragma Check_Float_Overflow,  Up: Implementation Defined Pragmas
*************** is given, then subsequent ‘Check’ pr
*** 2123,2129 ****
  
  The check policy is ‘OFF’ to turn off corresponding checks, and ‘ON’ to
  turn on corresponding checks.  The default for a set of checks for which
! no ‘Check_Policy’ is given is ‘OFF’ unless the compiler switch ‘-gnata’
  is given, which turns on all checks by default.
  
  The check policy settings ‘CHECK’ and ‘IGNORE’ are recognized as
--- 2123,2129 ----
  
  The check policy is ‘OFF’ to turn off corresponding checks, and ‘ON’ to
  turn on corresponding checks.  The default for a set of checks for which
! no ‘Check_Policy’ is given is ‘OFF’ unless the compiler switch '-gnata'
  is given, which turns on all checks by default.
  
  The check policy settings ‘CHECK’ and ‘IGNORE’ are recognized as
*************** Syntax:
*** 2215,2221 ****
                (boolean_EXPRESSION, static_string_EXPRESSION);
  
  Same as pragma Compile_Time_Error, except a warning is issued instead of
! an error message.  If switch ‘-gnatw_C’ is used, a warning is only
  issued if the value of the expression is known to be True at compile
  time, not when the value of the expression is not known at compile time.
  Note that if this pragma is used in a package that is with’ed by a
--- 2215,2221 ----
                (boolean_EXPRESSION, static_string_EXPRESSION);
  
  Same as pragma Compile_Time_Error, except a warning is issued instead of
! an error message.  If switch '-gnatw_C' is used, a warning is only
  issued if the value of the expression is known to be True at compile
  time, not when the value of the expression is not known at compile time.
  Note that if this pragma is used in a package that is with’ed by a
*************** appropriately.  Another use with a first
*** 2229,2235 ****
  client about use of a package, for example that it is not fully
  implemented.
  
! In previous versions of the compiler, combining ‘-gnatwe’ with
  Compile_Time_Warning resulted in a fatal error.  Now the compiler always
  emits a warning.  You can use *note Pragma Compile_Time_Error: 3b. to
  force the generation of an error.
--- 2229,2235 ----
  client about use of a package, for example that it is not fully
  implemented.
  
! In previous versions of the compiler, combining '-gnatwe' with
  Compile_Time_Warning resulted in a fatal error.  Now the compiler always
  emits a warning.  You can use *note Pragma Compile_Time_Error: 3b. to
  force the generation of an error.
*************** Syntax:
*** 2293,2299 ****
  Specifies the alignment of components in array or record types.  The
  meaning of the ‘Form’ argument is as follows:
  
! ‘Component_Size’
  
       Aligns scalar components and subcomponents of the array or record
       type on boundaries appropriate to their inherent size (naturally
--- 2293,2299 ----
  Specifies the alignment of components in array or record types.  The
  meaning of the ‘Form’ argument is as follows:
  
! 'Component_Size'
  
       Aligns scalar components and subcomponents of the array or record
       type on boundaries appropriate to their inherent size (naturally
*************** meaning of the ‘Form’ argument is as
*** 2303,2321 ****
       boundaries and so on.  These alignment rules correspond to the
       normal rules for C compilers on all machines except the VAX.
  
! ‘Component_Size_4’
  
       Naturally aligns components with a size of four or fewer bytes.
       Components that are larger than 4 bytes are placed on the next
       4-byte boundary.
  
! ‘Storage_Unit’
  
       Specifies that array or record components are byte aligned, i.e.,
       aligned on boundaries determined by the value of the constant
       ‘System.Storage_Unit’.
  
! ‘Default’
  
       Specifies that array or record components are aligned on default
       boundaries, appropriate to the underlying hardware or operating
--- 2303,2321 ----
       boundaries and so on.  These alignment rules correspond to the
       normal rules for C compilers on all machines except the VAX.
  
! 'Component_Size_4'
  
       Naturally aligns components with a size of four or fewer bytes.
       Components that are larger than 4 bytes are placed on the next
       4-byte boundary.
  
! 'Storage_Unit'
  
       Specifies that array or record components are byte aligned, i.e.,
       aligned on boundaries determined by the value of the constant
       ‘System.Storage_Unit’.
  
! 'Default'
  
       Specifies that array or record components are aligned on default
       boundaries, appropriate to the underlying hardware or operating
*************** argument is a name that must have been p
*** 2507,2519 ****
  ‘Import’ with ‘Convention’ = ‘CPP’.  Such name must be of one of the
  following forms:
  
!    * ‘function’ ‘Fname’ ‘return’ T‘
  
!    * ‘function’ ‘Fname’ ‘return’ T’Class
  
!    * ‘function’ ‘Fname’ (…) ‘return’ T‘
  
!    * ‘function’ ‘Fname’ (…) ‘return’ T’Class
  
  where ‘T’ is a limited record type imported from C++ with pragma
  ‘Import’ and ‘Convention’ = ‘CPP’.
--- 2507,2519 ----
  ‘Import’ with ‘Convention’ = ‘CPP’.  Such name must be of one of the
  following forms:
  
!    * 'function' ‘Fname’ 'return' T'
  
!    * 'function' ‘Fname’ 'return' T’Class
  
!    * 'function' ‘Fname’ (…) 'return' T'
  
!    * 'function' ‘Fname’ (…) 'return' T’Class
  
  where ‘T’ is a limited record type imported from C++ with pragma
  ‘Import’ and ‘Convention’ = ‘CPP’.
*************** procedure call statement corresponding t
*** 2619,2625 ****
  terminating semicolon.  Pragmas are permitted in sequences of
  declarations, so you can use pragma ‘Debug’ to intersperse calls to
  debug procedures in the middle of declarations.  Debug pragmas can be
! enabled either by use of the command line switch ‘-gnata’ or by use of
  the pragma ‘Check_Policy’ with a first argument of ‘Debug’.
  
  
--- 2619,2625 ----
  terminating semicolon.  Pragmas are permitted in sequences of
  declarations, so you can use pragma ‘Debug’ to intersperse calls to
  debug procedures in the middle of declarations.  Debug pragmas can be
! enabled either by use of the command line switch '-gnata' or by use of
  the pragma ‘Check_Policy’ with a first argument of ‘Debug’.
  
  
*************** The following example shows the use of t
*** 2703,2711 ****
          end record;
       end DSSO1;
  
! In this example record types with names starting with ‘L’ have
  ‘Low_Order_First’ scalar storage order, and record types with names
! starting with ‘H’ have ‘High_Order_First’.  Note that in the case of
  ‘H4a’, the order is not inherited from the parent type.  Only an
  explicitly set ‘Scalar_Storage_Order’ gets inherited on type derivation.
  
--- 2703,2711 ----
          end record;
       end DSSO1;
  
! In this example record types with names starting with 'L' have
  ‘Low_Order_First’ scalar storage order, and record types with names
! starting with 'H' have ‘High_Order_First’.  Note that in the case of
  ‘H4a’, the order is not inherited from the parent type.  Only an
  explicitly set ‘Scalar_Storage_Order’ gets inherited on type derivation.
  
*************** Syntax:
*** 2857,2863 ****
  This is a configuration pragma which specifies the elaboration model to
  be used during compilation.  For more information on the elaboration
  models of GNAT, consult the chapter on elaboration order handling in the
! ‘GNAT User’s Guide’.
  
  The pragma may appear in the following contexts:
  
--- 2857,2863 ----
  This is a configuration pragma which specifies the elaboration model to
  be used during compilation.  For more information on the elaboration
  models of GNAT, consult the chapter on elaboration order handling in the
! 'GNAT User’s Guide'.
  
  The pragma may appear in the following contexts:
  
*************** entities either by selection or using a
*** 3249,3255 ****
  special processing is required.
  
  However, if existing code contains references such as ‘System.XXX’ where
! ‘xxx’ is an entity in the extended definitions provided in package
  ‘System’, you may use this pragma to extend visibility in ‘System’ in a
  non-standard way that provides greater compatibility with the existing
  code.  Pragma ‘Extend_System’ is a configuration pragma whose single
--- 3249,3255 ----
  special processing is required.
  
  However, if existing code contains references such as ‘System.XXX’ where
! 'xxx' is an entity in the extended definitions provided in package
  ‘System’, you may use this pragma to extend visibility in ‘System’ in a
  non-standard way that provides greater compatibility with the existing
  code.  Pragma ‘Extend_System’ is a configuration pragma whose single
*************** You can use this pragma either to access
*** 3264,3270 ****
  supplied with the compiler, for example ‘Aux_DEC’ or you can construct
  your own extension unit following the above definition.  Note that such
  a package is a child of ‘System’ and thus is considered part of the
! implementation.  To compile it you will have to use the ‘-gnatg’ switch
  for compiling System units, as explained in the GNAT User’s Guide.
  
  
--- 3264,3270 ----
  supplied with the compiler, for example ‘Aux_DEC’ or you can construct
  your own extension unit following the above definition.  Note that such
  a package is a child of ‘System’ and thus is considered part of the
! implementation.  To compile it you will have to use the '-gnatg' switch
  for compiling System units, as explained in the GNAT User’s Guide.
  
  
*************** Syntax:
*** 3279,3285 ****
  
  This configuration pragma enables (via the “On” or “All” argument) or
  disables (via the “Off” argument) the implementation extension mode; the
! pragma takes precedence over the ‘-gnatX’ and ‘-gnatX0’ command
  switches.
  
  If an argument of “All” is specified, the latest version of the Ada
--- 3279,3285 ----
  
  This configuration pragma enables (via the “On” or “All” argument) or
  disables (via the “Off” argument) the implementation extension mode; the
! pragma takes precedence over the '-gnatX' and '-gnatX0' command
  switches.
  
  If an argument of “All” is specified, the latest version of the Ada
*************** considered more important for floating-p
*** 3650,3656 ****
  accurate adherence to the requirements of the standard.  Currently the
  following operations are affected:
  
! ‘Complex Multiplication’
  
       The normal simple formula for complex multiplication can result in
       intermediate overflows for numbers near the end of the range.  The
--- 3650,3656 ----
  accurate adherence to the requirements of the standard.  Currently the
  following operations are affected:
  
! 'Complex Multiplication'
  
       The normal simple formula for complex multiplication can result in
       intermediate overflows for numbers near the end of the range.  The
*************** in several different ways:
*** 4230,4236 ****
  Note that pragma ‘Initialize_Scalars’ is particularly useful in
  conjunction with the enhanced validity checking that is now provided in
  GNAT, which checks for invalid values under more conditions.  Using this
! feature (see description of the ‘-gnatV’ flag in the GNAT User’s Guide)
  in conjunction with pragma ‘Initialize_Scalars’ provides a powerful new
  tool to assist in the detection of problems caused by uninitialized
  variables.
--- 4230,4236 ----
  Note that pragma ‘Initialize_Scalars’ is particularly useful in
  conjunction with the enhanced validity checking that is now provided in
  GNAT, which checks for invalid values under more conditions.  Using this
! feature (see description of the '-gnatV' flag in the GNAT User’s Guide)
  in conjunction with pragma ‘Initialize_Scalars’ provides a powerful new
  tool to assist in the detection of problems caused by uninitialized
  variables.
*************** Syntax:
*** 4280,4286 ****
  Similar to pragma ‘Inline’ except that inlining is unconditional.
  Inline_Always instructs the compiler to inline every direct call to the
  subprogram or else to emit a compilation error, independently of any
! option, in particular ‘-gnatn’ or ‘-gnatN’ or the optimization level.
  It is an error to take the address or access of ‘NAME’.  It is also an
  error to apply this pragma to a primitive operation of a tagged type.
  Thanks to such restrictions, the compiler is allowed to remove the
--- 4280,4286 ----
  Similar to pragma ‘Inline’ except that inlining is unconditional.
  Inline_Always instructs the compiler to inline every direct call to the
  subprogram or else to emit a compilation error, independently of any
! option, in particular '-gnatn' or '-gnatN' or the optimization level.
  It is an error to take the address or access of ‘NAME’.  It is also an
  error to apply this pragma to a primitive operation of a tagged type.
  Thanks to such restrictions, the compiler is allowed to remove the
*************** There are five supported optimization hi
*** 4879,4885 ****
  
  These hints do not remove the need to pass the appropriate switches to
  the compiler in order to enable the relevant optimizations, that is to
! say ‘-funroll-loops’ for unrolling and ‘-ftree-vectorize’ for
  vectorization.
  
  
--- 4879,4885 ----
  
  These hints do not remove the need to pass the appropriate switches to
  the compiler in order to enable the relevant optimizations, that is to
! say '-funroll-loops' for unrolling and '-ftree-vectorize' for
  vectorization.
  
  
*************** declarations.  This pragma is semantical
*** 4943,4949 ****
  ‘__attribute__((ATTRIBUTE_NAME))’ (if ‘info’ is not specified) or
  ‘__attribute__((ATTRIBUTE_NAME(INFO)))’ or
  ‘__attribute__((ATTRIBUTE_NAME(INFO,...)))’ in GNU C, where
! ‘attribute_name’ is recognized by the compiler middle-end or the
  ‘TARGET_ATTRIBUTE_TABLE’ machine specific macro.  Note that a string
  literal for the optional parameter ‘info’ or the following ones is
  transformed by default into an identifier, which may make this pragma
--- 4943,4949 ----
  ‘__attribute__((ATTRIBUTE_NAME))’ (if ‘info’ is not specified) or
  ‘__attribute__((ATTRIBUTE_NAME(INFO)))’ or
  ‘__attribute__((ATTRIBUTE_NAME(INFO,...)))’ in GNU C, where
! 'attribute_name' is recognized by the compiler middle-end or the
  ‘TARGET_ATTRIBUTE_TABLE’ machine specific macro.  Note that a string
  literal for the optional parameter ‘info’ or the following ones is
  transformed by default into an identifier, which may make this pragma
*************** Syntax:
*** 5123,5130 ****
  This pragma suppresses inlining for the callable entity or the instances
  of the generic subprogram designated by ‘NAME’, including inlining that
  results from the use of pragma ‘Inline’.  This pragma is always active,
! in particular it is not subject to the use of option ‘-gnatn’ or
! ‘-gnatN’.  It is illegal to specify both pragma ‘No_Inline’ and pragma
  ‘Inline_Always’ for the same ‘NAME’.
  
  
--- 5123,5130 ----
  This pragma suppresses inlining for the callable entity or the instances
  of the generic subprogram designated by ‘NAME’, including inlining that
  results from the use of pragma ‘Inline’.  This pragma is always active,
! in particular it is not subject to the use of option '-gnatn' or
! '-gnatN'.  It is illegal to specify both pragma ‘No_Inline’ and pragma
  ‘Inline_Always’ for the same ‘NAME’.
  
  
*************** The effect is to cause all scalar object
*** 5232,5259 ****
  initialized to be initialized.  The initial values are implementation
  dependent and are as follows:
  
! ‘Standard.Character’
  
       Objects whose root type is Standard.Character are initialized to
       Character’Last unless the subtype range excludes NUL (in which case
       NUL is used).  This choice will always generate an invalid value if
       one exists.
  
! ‘Standard.Wide_Character’
  
       Objects whose root type is Standard.Wide_Character are initialized
       to Wide_Character’Last unless the subtype range excludes NUL (in
       which case NUL is used).  This choice will always generate an
       invalid value if one exists.
  
! ‘Standard.Wide_Wide_Character’
  
       Objects whose root type is Standard.Wide_Wide_Character are
       initialized to the invalid value 16#FFFF_FFFF# unless the subtype
       range excludes NUL (in which case NUL is used).  This choice will
       always generate an invalid value if one exists.
  
! ‘Integer types’
  
       Objects of an integer type are treated differently depending on
       whether negative values are present in the subtype.  If no negative
--- 5232,5259 ----
  initialized to be initialized.  The initial values are implementation
  dependent and are as follows:
  
! 'Standard.Character'
  
       Objects whose root type is Standard.Character are initialized to
       Character’Last unless the subtype range excludes NUL (in which case
       NUL is used).  This choice will always generate an invalid value if
       one exists.
  
! 'Standard.Wide_Character'
  
       Objects whose root type is Standard.Wide_Character are initialized
       to Wide_Character’Last unless the subtype range excludes NUL (in
       which case NUL is used).  This choice will always generate an
       invalid value if one exists.
  
! 'Standard.Wide_Wide_Character'
  
       Objects whose root type is Standard.Wide_Wide_Character are
       initialized to the invalid value 16#FFFF_FFFF# unless the subtype
       range excludes NUL (in which case NUL is used).  This choice will
       always generate an invalid value if one exists.
  
! 'Integer types'
  
       Objects of an integer type are treated differently depending on
       whether negative values are present in the subtype.  If no negative
*************** dependent and are as follows:
*** 5268,5293 ****
       is not, in which case the largest positive value is used.  This
       choice will always generate an invalid value if one exists.
  
! ‘Floating-Point Types’
  
       Objects of all floating-point types are initialized to all 1-bits.
       For standard IEEE format, this corresponds to a NaN (not a number)
       which is indeed an invalid value.
  
! ‘Fixed-Point Types’
  
       Objects of all fixed-point types are treated as described above for
       integers, with the rules applying to the underlying integer value
       used to represent the fixed-point value.
  
! ‘Modular types’
  
       Objects of a modular type are initialized to all one bits, except
       in the special case where zero is excluded from the subtype, in
       which case all zero bits are used.  This choice will always
       generate an invalid value if one exists.
  
! ‘Enumeration types’
  
       Objects of an enumeration type are initialized to all one-bits,
       i.e., to the value ‘2 ** typ'Size - 1’ unless the subtype excludes
--- 5268,5293 ----
       is not, in which case the largest positive value is used.  This
       choice will always generate an invalid value if one exists.
  
! 'Floating-Point Types'
  
       Objects of all floating-point types are initialized to all 1-bits.
       For standard IEEE format, this corresponds to a NaN (not a number)
       which is indeed an invalid value.
  
! 'Fixed-Point Types'
  
       Objects of all fixed-point types are treated as described above for
       integers, with the rules applying to the underlying integer value
       used to represent the fixed-point value.
  
! 'Modular types'
  
       Objects of a modular type are initialized to all one bits, except
       in the special case where zero is excluded from the subtype, in
       which case all zero bits are used.  This choice will always
       generate an invalid value if one exists.
  
! 'Enumeration types'
  
       Objects of an enumeration type are initialized to all one-bits,
       i.e., to the value ‘2 ** typ'Size - 1’ unless the subtype excludes
*************** possible colors, and the order is unimpo
*** 5494,5500 ****
  
  For unordered enumeration types, it is generally a good idea if clients
  avoid comparisons (other than equality or inequality) and explicit
! ranges.  (A ‘client’ is a unit where the type is referenced, other than
  the unit where the type is declared, its body, and its subunits.)  For
  example, if code buried in some client says:
  
--- 5494,5500 ----
  
  For unordered enumeration types, it is generally a good idea if clients
  avoid comparisons (other than equality or inequality) and explicit
! ranges.  (A 'client' is a unit where the type is referenced, other than
  the unit where the type is declared, its body, and its subunits.)  For
  example, if code buried in some client says:
  
*************** depend on it, writing for example:
*** 5527,5533 ****
       if D in Mon .. Fri then ...
       if D < Wed then ...
  
! The pragma ‘Ordered’ is provided to mark enumeration types that are
  conceptually ordered, alerting the reader that clients may depend on the
  ordering.  GNAT provides a pragma to mark enumerations as ordered rather
  than one to mark them as unordered, since in our experience, the great
--- 5527,5533 ----
       if D in Mon .. Fri then ...
       if D < Wed then ...
  
! The pragma 'Ordered' is provided to mark enumeration types that are
  conceptually ordered, alerting the reader that clients may depend on the
  ordering.  GNAT provides a pragma to mark enumerations as ordered rather
  than one to mark them as unordered, since in our experience, the great
*************** The types ‘Boolean’, ‘Character’
*** 5538,5544 ****
  declared with a pragma ‘Ordered’ in package ‘Standard’.
  
  Normally pragma ‘Ordered’ serves only as documentation and a guide for
! coding standards, but GNAT provides a warning switch ‘-gnatw.u’ that
  requests warnings for inappropriate uses (comparisons and explicit
  subranges) for unordered types.  If this switch is used, then any
  enumeration type not marked with pragma ‘Ordered’ will be considered as
--- 5538,5544 ----
  declared with a pragma ‘Ordered’ in package ‘Standard’.
  
  Normally pragma ‘Ordered’ serves only as documentation and a guide for
! coding standards, but GNAT provides a warning switch '-gnatw.u' that
  requests warnings for inappropriate uses (comparisons and explicit
  subranges) for unordered types.  If this switch is used, then any
  enumeration type not marked with pragma ‘Ordered’ will be considered as
*************** the template can be instantiated for bot
*** 5549,5555 ****
  warnings for the case of generic enumerated types.
  
  For additional information please refer to the description of the
! ‘-gnatw.u’ switch in the GNAT User’s Guide.
  
  
  File: gnat_rm.info,  Node: Pragma Overflow_Mode,  Next: Pragma Overriding_Renamings,  Prev: Pragma Ordered,  Up: Implementation Defined Pragmas
--- 5549,5555 ----
  warnings for the case of generic enumerated types.
  
  For additional information please refer to the description of the
! '-gnatw.u' switch in the GNAT User’s Guide.
  
  
  File: gnat_rm.info,  Node: Pragma Overflow_Mode,  Next: Pragma Overriding_Renamings,  Prev: Pragma Ordered,  Up: Implementation Defined Pragmas
*************** expressions.
*** 5753,5759 ****
  The postconditions are collected and automatically tested just before
  any return (implicit or explicit) in the subprogram body.  A
  postcondition is only recognized if postconditions are active at the
! time the pragma is encountered.  The compiler switch ‘gnata’ turns on
  all postconditions by default, and pragma ‘Check_Policy’ with an
  identifier of ‘Postcondition’ can also be used to control whether
  postconditions are active.
--- 5753,5759 ----
  The postconditions are collected and automatically tested just before
  any return (implicit or explicit) in the subprogram body.  A
  postcondition is only recognized if postconditions are active at the
! time the pragma is encountered.  The compiler switch 'gnata' turns on
  all postconditions by default, and pragma ‘Check_Policy’ with an
  identifier of ‘Postcondition’ can also be used to control whether
  postconditions are active.
*************** program being compiled, or on the code g
*** 6702,6721 ****
  To obtain the required output specified in RM H.3.1, the compiler must
  be run with various special switches as follows:
  
!    * ‘Where compiler-generated run-time checks remain’
  
!      The switch ‘-gnatGL’ may be used to list the expanded code in
       pseudo-Ada form.  Runtime checks show up in the listing either as
       explicit checks or operators marked with {} to indicate a check is
       present.
  
!    * ‘An identification of known exceptions at compile time’
  
!      If the program is compiled with ‘-gnatwa’, the compiler warning
       messages will indicate all cases where the compiler detects that an
       exception is certain to occur at run time.
  
!    * ‘Possible reads of uninitialized variables’
  
       The compiler warns of many such cases, but its output is
       incomplete.
--- 6702,6721 ----
  To obtain the required output specified in RM H.3.1, the compiler must
  be run with various special switches as follows:
  
!    * 'Where compiler-generated run-time checks remain'
  
!      The switch '-gnatGL' may be used to list the expanded code in
       pseudo-Ada form.  Runtime checks show up in the listing either as
       explicit checks or operators marked with {} to indicate a check is
       present.
  
!    * 'An identification of known exceptions at compile time'
  
!      If the program is compiled with '-gnatwa', the compiler warning
       messages will indicate all cases where the compiler detects that an
       exception is certain to occur at run time.
  
!    * 'Possible reads of uninitialized variables'
  
       The compiler warns of many such cases, but its output is
       incomplete.
*************** A supplemental static analysis tool may
*** 6724,6764 ****
  comprehensive list of all possible points at which uninitialized data
  may be read.
  
!    * ‘Where run-time support routines are implicitly invoked’
  
!      In the output from ‘-gnatGL’, run-time calls are explicitly listed
       as calls to the relevant run-time routine.
  
!    * ‘Object code listing’
  
!      This may be obtained either by using the ‘-S’ switch, or the
       objdump utility.
  
!    * ‘Constructs known to be erroneous at compile time’
  
       These are identified by warnings issued by the compiler (use
!      ‘-gnatwa’).
  
!    * ‘Stack usage information’
  
       Static stack usage data (maximum per-subprogram) can be obtained
!      via the ‘-fstack-usage’ switch to the compiler.  Dynamic stack
!      usage data (per task) can be obtained via the ‘-u’ switch to
       gnatbind
  
!    * ‘Object code listing of entire partition’
  
!      This can be obtained by compiling the partition with ‘-S’, or by
       applying objdump to all the object files that are part of the
       partition.
  
!    * ‘A description of the run-time model’
  
       The full sources of the run-time are available, and the
       documentation of these routines describes how these run-time
       routines interface to the underlying operating system facilities.
  
!    * ‘Control and data-flow information’
  
  A supplemental static analysis tool may be used to obtain complete
  control and data-flow information, as well as comprehensive messages
--- 6724,6764 ----
  comprehensive list of all possible points at which uninitialized data
  may be read.
  
!    * 'Where run-time support routines are implicitly invoked'
  
!      In the output from '-gnatGL', run-time calls are explicitly listed
       as calls to the relevant run-time routine.
  
!    * 'Object code listing'
  
!      This may be obtained either by using the '-S' switch, or the
       objdump utility.
  
!    * 'Constructs known to be erroneous at compile time'
  
       These are identified by warnings issued by the compiler (use
!      '-gnatwa').
  
!    * 'Stack usage information'
  
       Static stack usage data (maximum per-subprogram) can be obtained
!      via the '-fstack-usage' switch to the compiler.  Dynamic stack
!      usage data (per task) can be obtained via the '-u' switch to
       gnatbind
  
!    * 'Object code listing of entire partition'
  
!      This can be obtained by compiling the partition with '-S', or by
       applying objdump to all the object files that are part of the
       partition.
  
!    * 'A description of the run-time model'
  
       The full sources of the run-time are available, and the
       documentation of these routines describes how these run-time
       routines interface to the underlying operating system facilities.
  
!    * 'Control and data-flow information'
  
  A supplemental static analysis tool may be used to obtain complete
  control and data-flow information, as well as comprehensive messages
*************** This pragma must appear as the first lin
*** 7045,7051 ****
  pragma line (for use in error messages and debugging information).
  ‘string_literal’ is a static string constant that specifies the file
  name to be used in error messages and debugging information.  This is
! most notably used for the output of ‘gnatchop’ with the ‘-r’ switch, to
  make sure that the original unchopped source file is the one referred
  to.
  
--- 7045,7051 ----
  pragma line (for use in error messages and debugging information).
  ‘string_literal’ is a static string constant that specifies the file
  name to be used in error messages and debugging information.  This is
! most notably used for the output of ‘gnatchop’ with the '-r' switch, to
  make sure that the original unchopped source file is the one referred
  to.
  
*************** is legal, including use as a configurati
*** 7235,7241 ****
  The form with a string literal specifies which style options are to be
  activated.  These are additive, so they apply in addition to any
  previously set style check options.  The codes for the options are the
! same as those used in the ‘-gnaty’ switch to ‘gcc’ or ‘gnatmake’.  For
  example the following two methods can be used to enable layout checking:
  
     *      pragma Style_Checks ("l");
--- 7235,7241 ----
  The form with a string literal specifies which style options are to be
  activated.  These are additive, so they apply in addition to any
  previously set style check options.  The codes for the options are the
! same as those used in the '-gnaty' switch to 'gcc' or 'gnatmake'.  For
  example the following two methods can be used to enable layout checking:
  
     *      pragma Style_Checks ("l");
*************** The form with a string literal specifies
*** 8021,8027 ****
  be activated.  The validity checks are first set to include only the
  default reference manual settings, and then a string of letters in the
  string specifies the exact set of options required.  The form of this
! string is exactly as described for the ‘-gnatVx’ compiler switch (see
  the GNAT User’s Guide for details).  For example the following two
  methods can be used to enable validity checking for mode ‘in’ and ‘in
  out’ subprogram parameters:
--- 8021,8027 ----
  be activated.  The validity checks are first set to include only the
  default reference manual settings, and then a string of letters in the
  string specifies the exact set of options required.  The form of this
! string is exactly as described for the '-gnatVx' compiler switch (see
  the GNAT User’s Guide for details).  For example the following two
  methods can be used to enable validity checking for mode ‘in’ and ‘in
  out’ subprogram parameters:
*************** message string (it is not necessary to p
*** 8130,8136 ****
  the end of the message, since this is implied).
  
  Another possibility for the static_string_EXPRESSION which works whether
! or not error tags are enabled (‘-gnatw.d’) is to use a single ‘-gnatw’
  tag string, enclosed in brackets, as shown in the example below, to
  treat one category of warnings as errors.  Note that if you want to
  treat multiple categories of warnings as errors, you can use multiple
--- 8130,8136 ----
  the end of the message, since this is implied).
  
  Another possibility for the static_string_EXPRESSION which works whether
! or not error tags are enabled ('-gnatw.d') is to use a single '-gnatw'
  tag string, enclosed in brackets, as shown in the example below, to
  treat one category of warnings as errors.  Note that if you want to
  treat multiple categories of warnings as errors, you can use multiple
*************** pragma Warning_As_Error.
*** 8139,8145 ****
  The above use of patterns to match the message applies only to warning
  messages generated by the front end.  This pragma can also be applied to
  warnings provided by the back end and mentioned in *note Pragma
! Warnings: 11a.  By using a single full ‘-Wxxx’ switch in the pragma,
  such warnings can also be treated as errors.
  
  The pragma can appear either in a global configuration pragma file (e.g.
--- 8139,8145 ----
  The above use of patterns to match the message applies only to warning
  messages generated by the front end.  This pragma can also be applied to
  warnings provided by the back end and mentioned in *note Pragma
! Warnings: 11a.  By using a single full '-Wxxx' switch in the pragma,
  such warnings can also be treated as errors.
  
  The pragma can appear either in a global configuration pragma file (e.g.
*************** pragma file containing:
*** 8149,8156 ****
       pragma Warning_As_Error ("[-gnatwj]");
  
  which will treat all obsolescent feature warnings as errors, the
! following program compiles as shown (compile options here are ‘-gnatwa.d
! -gnatl -gnatj55’).
  
           1. pragma Warning_As_Error ("*never assigned*");
           2. function Warnerr return String is
--- 8149,8156 ----
       pragma Warning_As_Error ("[-gnatwj]");
  
  which will treat all obsolescent feature warnings as errors, the
! following program compiles as shown (compile options here are '-gnatwa.d
! -gnatl -gnatj55').
  
           1. pragma Warning_As_Error ("*never assigned*");
           2. function Warnerr return String is
*************** string expression (which does not exist
*** 8208,8214 ****
  Note if the second argument of ‘DETAILS’ is a ‘local_NAME’ then the
  second form is always understood.  If the intention is to use the fourth
  form, then you can write ‘NAME & ""’ to force the interpretation as a
! ‘static_string_EXPRESSION’.
  
  Note: if the first argument is a valid ‘TOOL_NAME’, it will be
  interpreted that way.  The use of the ‘TOOL_NAME’ argument is relevant
--- 8208,8214 ----
  Note if the second argument of ‘DETAILS’ is a ‘local_NAME’ then the
  second form is always understood.  If the intention is to use the fourth
  form, then you can write ‘NAME & ""’ to force the interpretation as a
! 'static_string_EXPRESSION'.
  
  Note: if the first argument is a valid ‘TOOL_NAME’, it will be
  interpreted that way.  The use of the ‘TOOL_NAME’ argument is relevant
*************** front end of the compiler.  The GCC back
*** 8256,8262 ****
  warnings and they are controlled by the ‘-W’ switch.  Such warnings can
  be identified by the appearance of a string of the form ‘[-W{xxx}]’ in
  the message which designates the ‘-W`xxx'’ switch that controls the
! message.  The form with a single ‘static_string_EXPRESSION’ argument
  also works for these warnings, but the string must be a single full
  ‘-W`xxx'’ switch in this case.  The above reference lists a few examples
  of these additional warnings.
--- 8256,8262 ----
  warnings and they are controlled by the ‘-W’ switch.  Such warnings can
  be identified by the appearance of a string of the form ‘[-W{xxx}]’ in
  the message which designates the ‘-W`xxx'’ switch that controls the
! message.  The form with a single 'static_string_EXPRESSION' argument
  also works for these warnings, but the string must be a single full
  ‘-W`xxx'’ switch in this case.  The above reference lists a few examples
  of these additional warnings.
*************** pragmas must appear in sequence:
*** 8304,8310 ****
       pragma Warnings (On, Pattern);
  
  In this usage, the pattern string must match in the Off and On pragmas,
! and (if ‘-gnatw.w’ is given) at least one matching warning must be
  suppressed.
  
  Note: if the ON form is not found, then the effect of the OFF form
--- 8304,8310 ----
       pragma Warnings (On, Pattern);
  
  In this usage, the pattern string must match in the Off and On pragmas,
! and (if '-gnatw.w' is given) at least one matching warning must be
  suppressed.
  
  Note: if the ON form is not found, then the effect of the OFF form
*************** File: gnat_rm.info,  Node: Aspect Annota
*** 8544,8558 ****
  There are three forms of this aspect (where ID is an identifier, and ARG
  is a general expression), corresponding to *note pragma Annotate: 29.
  
! ‘Annotate => ID’
  
       Equivalent to ‘pragma Annotate (ID, Entity => Name);’
  
! ‘Annotate => (ID)’
  
       Equivalent to ‘pragma Annotate (ID, Entity => Name);’
  
! ‘Annotate => (ID ,ID {, ARG})’
  
       Equivalent to ‘pragma Annotate (ID, ID {, ARG}, Entity => Name);’
  
--- 8544,8558 ----
  There are three forms of this aspect (where ID is an identifier, and ARG
  is a general expression), corresponding to *note pragma Annotate: 29.
  
! 'Annotate => ID'
  
       Equivalent to ‘pragma Annotate (ID, Entity => Name);’
  
! 'Annotate => (ID)'
  
       Equivalent to ‘pragma Annotate (ID, Entity => Name);’
  
! 'Annotate => (ID ,ID {, ARG})'
  
       Equivalent to ‘pragma Annotate (ID, ID {, ARG}, Entity => Name);’
  
*************** File: gnat_rm.info,  Node: Attribute Bit
*** 9379,9385 ****
  ‘obj'Bit’, where ‘obj’ is any object, yields the bit offset within the
  storage unit (byte) that contains the first bit of storage allocated for
  the object.  The value of this attribute is of the type
! ‘universal_integer’ and is always a nonnegative number smaller than
  ‘System.Storage_Unit’.
  
  For an object that is a variable or a constant allocated in a register,
--- 9379,9385 ----
  ‘obj'Bit’, where ‘obj’ is any object, yields the bit offset within the
  storage unit (byte) that contains the first bit of storage allocated for
  the object.  The value of this attribute is of the type
! 'universal_integer' and is always a nonnegative number smaller than
  ‘System.Storage_Unit’.
  
  For an object that is a variable or a constant allocated in a register,
*************** File: gnat_rm.info,  Node: Attribute Bit
*** 9407,9413 ****
  ‘R.C'Bit_Position’, where ‘R’ is a record object and ‘C’ is one of the
  fields of the record type, yields the bit offset within the record
  contains the first bit of storage allocated for the object.  The value
! of this attribute is of the type ‘universal_integer’.  The value depends
  only on the field ‘C’ and is independent of the alignment of the
  containing record ‘R’.
  
--- 9407,9413 ----
  ‘R.C'Bit_Position’, where ‘R’ is a record object and ‘C’ is one of the
  fields of the record type, yields the bit offset within the record
  contains the first bit of storage allocated for the object.  The value
! of this attribute is of the type 'universal_integer'.  The value depends
  only on the field ‘C’ and is independent of the alignment of the
  containing record ‘R’.
  
*************** File: gnat_rm.info,  Node: Attribute Fin
*** 9701,9707 ****
  The prefix of attribute ‘Finalization_Size’ must be an object or a
  non-class-wide type.  This attribute returns the size of any hidden data
  reserved by the compiler to handle finalization-related actions.  The
! type of the attribute is ‘universal_integer’.
  
  ‘Finalization_Size’ yields a value of zero for a type with no controlled
  parts, an object whose type has no controlled parts, or an object of a
--- 9701,9707 ----
  The prefix of attribute ‘Finalization_Size’ must be an object or a
  non-class-wide type.  This attribute returns the size of any hidden data
  reserved by the compiler to handle finalization-related actions.  The
! type of the attribute is 'universal_integer'.
  
  ‘Finalization_Size’ yields a value of zero for a type with no controlled
  parts, an object whose type has no controlled parts, or an object of a
*************** File: gnat_rm.info,  Node: Attribute Mec
*** 9969,9983 ****
  
  ‘func'Mechanism_Code’ yields an integer code for the mechanism used for
  the result of function ‘func’, and ‘subprog'Mechanism_Code (n)’ yields
! the mechanism used for formal parameter number ‘n’ (a static integer
  value, with 1 meaning the first parameter) of subprogram ‘subprog’.  The
  code returned is:
  
! ‘1’
  
       by copy (value)
  
! ‘2’
  
       by reference
  
--- 9969,9983 ----
  
  ‘func'Mechanism_Code’ yields an integer code for the mechanism used for
  the result of function ‘func’, and ‘subprog'Mechanism_Code (n)’ yields
! the mechanism used for formal parameter number 'n' (a static integer
  value, with 1 meaning the first parameter) of subprogram ‘subprog’.  The
  code returned is:
  
! '1'
  
       by copy (value)
  
! '2'
  
       by reference
  
*************** normally the native ordering of the targ
*** 10320,10326 ****
  overridden using pragma ‘Default_Scalar_Storage_Order’.
  
  If a component of ‘T’ is itself of a record or array type, the specfied
! ‘Scalar_Storage_Order’ does ‘not’ apply to that nested type: an explicit
  attribute definition clause must be provided for the component type as
  well if desired.
  
--- 10320,10326 ----
  overridden using pragma ‘Default_Scalar_Storage_Order’.
  
  If a component of ‘T’ is itself of a record or array type, the specfied
! ‘Scalar_Storage_Order’ does 'not' apply to that nested type: an explicit
  attribute definition clause must be provided for the component type as
  well if desired.
  
*************** then the evaluation of an allocator for
*** 10416,10423 ****
  primitive ‘Allocate’ procedure for type ‘SSP’, passing
  ‘S'Simple_Storage_Pool’ as the pool parameter.  The detailed semantics
  of such allocators is the same as those defined for allocators in
! section 13.11 of the ‘Ada Reference Manual’, with the term ‘simple
! storage pool’ substituted for ‘storage pool’.
  
  If an access type ‘S’ has a specified simple storage pool of type ‘SSP’,
  then a call to an instance of the ‘Ada.Unchecked_Deallocation’ for that
--- 10416,10423 ----
  primitive ‘Allocate’ procedure for type ‘SSP’, passing
  ‘S'Simple_Storage_Pool’ as the pool parameter.  The detailed semantics
  of such allocators is the same as those defined for allocators in
! section 13.11 of the ‘Ada Reference Manual’, with the term 'simple
! storage pool' substituted for 'storage pool'.
  
  If an access type ‘S’ has a specified simple storage pool of type ‘SSP’,
  then a call to an instance of the ‘Ada.Unchecked_Deallocation’ for that
*************** access type invokes the primitive ‘Dea
*** 10425,10431 ****
  passing ‘S'Simple_Storage_Pool’ as the pool parameter.  The detailed
  semantics of such unchecked deallocations is the same as defined in
  section 13.11.2 of the Ada Reference Manual, except that the term
! ‘simple storage pool’ is substituted for ‘storage pool’.
  
  
  File: gnat_rm.info,  Node: Attribute Small,  Next: Attribute Small_Denominator,  Prev: Attribute Simple_Storage_Pool,  Up: Implementation Defined Attributes
--- 10425,10431 ----
  passing ‘S'Simple_Storage_Pool’ as the pool parameter.  The detailed
  semantics of such unchecked deallocations is the same as defined in
  section 13.11.2 of the Ada Reference Manual, except that the term
! 'simple storage pool' is substituted for 'storage pool'.
  
  
  File: gnat_rm.info,  Node: Attribute Small,  Next: Attribute Small_Denominator,  Prev: Attribute Simple_Storage_Pool,  Up: Implementation Defined Attributes
*************** Pragma                   Explanation
*** 12479,12512 ****
                           
  -------------------------------------------------
                           
! ‘Abort_Defer’            Affects semantics
                           
                           
! ‘Ada_83’                 Affects legality
                           
                           
! ‘Assert’                 Affects semantics
                           
                           
! ‘CPP_Class’              Affects semantics
                           
                           
! ‘CPP_Constructor’        Affects semantics
                           
                           
! ‘Debug’                  Affects semantics
                           
                           
! ‘Interface_Name’         Affects semantics
                           
                           
! ‘Machine_Attribute’      Affects semantics
                           
                           
! ‘Unimplemented_Unit’     Affects legality
                           
                           
! ‘Unchecked_Union’        Affects semantics
                           
  
  In each of the above cases, it is essential to the purpose of the pragma
--- 12479,12512 ----
                           
  -------------------------------------------------
                           
! 'Abort_Defer'            Affects semantics
                           
                           
! 'Ada_83'                 Affects legality
                           
                           
! 'Assert'                 Affects semantics
                           
                           
! 'CPP_Class'              Affects semantics
                           
                           
! 'CPP_Constructor'        Affects semantics
                           
                           
! 'Debug'                  Affects semantics
                           
                           
! 'Interface_Name'         Affects semantics
                           
                           
! 'Machine_Attribute'      Affects semantics
                           
                           
! 'Unimplemented_Unit'     Affects legality
                           
                           
! 'Unchecked_Union'        Affects semantics
                           
  
  In each of the above cases, it is essential to the purpose of the pragma
*************** File: gnat_rm.info,  Node: RM 3 6 2 11 M
*** 12635,12641 ****
       multidimensional array aggregates (see 4.3.3).  However, if a
       pragma ‘Convention’ (‘Fortran’, …) applies to a multidimensional
       array type, then column-major order should be used instead (see
!      B.5, ‘Interfacing with Fortran’).”
  
  Followed.
  
--- 12635,12641 ----
       multidimensional array aggregates (see 4.3.3).  However, if a
       pragma ‘Convention’ (‘Fortran’, …) applies to a multidimensional
       array type, then column-major order should be used instead (see
!      B.5, 'Interfacing with Fortran').”
  
  Followed.
  
*************** File: gnat_rm.info,  Node: RM 13 2 6-8 P
*** 12762,12768 ****
  
       For a packed record type, the components should be packed as
       tightly as possible subject to the Sizes of the component subtypes,
!      and subject to any ‘record_representation_clause’ that applies to
       the type; the implementation may, but need not, reorder components
       or cross aligned word boundaries to improve the packing.  A
       component whose ‘Size’ is greater than the word size may be
--- 12762,12768 ----
  
       For a packed record type, the components should be packed as
       tightly as possible subject to the Sizes of the component subtypes,
!      and subject to any 'record_representation_clause' that applies to
       the type; the implementation may, but need not, reorder components
       or cross aligned word boundaries to improve the packing.  A
       component whose ‘Size’ is greater than the word size may be
*************** File: gnat_rm.info,  Node: RM 13 5 1 17-
*** 12956,12962 ****
  ====================================================
  
       “The recommended level of support for
!      ‘record_representation_clause’s is:
  
       An implementation should support storage places that can be
       extracted with a load, mask, shift sequence of machine code, and
--- 12956,12962 ----
  ====================================================
  
       “The recommended level of support for
!      'record_representation_clause's is:
  
       An implementation should support storage places that can be
       extracted with a load, mask, shift sequence of machine code, and
*************** Followed.  The storage place for the tag
*** 12986,12992 ****
  tagged record, and its size is Address’Size.  GNAT will reject an
  explicit component clause for the tag field.
  
!      “An implementation need not support a ‘component_clause’ for a
       component of an extension part if the storage place is not after
       the storage places of all components of the parent type, whether or
       not those storage places had been specified.”
--- 12986,12992 ----
  tagged record, and its size is Address’Size.  GNAT will reject an
  explicit component clause for the tag field.
  
!      “An implementation need not support a 'component_clause' for a
       component of an extension part if the storage place is not after
       the storage places of all components of the parent type, whether or
       not those storage places had been specified.”
*************** Followed when the main program is in Ada
*** 13275,13284 ****
  foreign language, then ‘adainit’ must be called to elaborate
  pre-elaborated packages.
  
!      “For each supported convention ‘L’ other than ‘Intrinsic’, an
       implementation should support ‘Import’ and ‘Export’ pragmas for
!      objects of ‘L’-compatible types and for subprograms, and pragma
!      ‘Convention’ for ‘L’-eligible types and for subprograms, presuming
       the other language has corresponding features.  Pragma ‘Convention’
       need not be supported for scalar types.”
  
--- 13275,13284 ----
  foreign language, then ‘adainit’ must be called to elaborate
  pre-elaborated packages.
  
!      “For each supported convention 'L' other than ‘Intrinsic’, an
       implementation should support ‘Import’ and ‘Export’ pragmas for
!      objects of 'L'-compatible types and for subprograms, and pragma
!      ‘Convention’ for 'L'-eligible types and for subprograms, presuming
       the other language has corresponding features.  Pragma ‘Convention’
       need not be supported for scalar types.”
  
*************** File: gnat_rm.info,  Node: RM D 6 9-10 P
*** 13616,13625 ****
  6.54 RM D.6(9-10): Preemptive Abort
  ===================================
  
!      “Even though the ‘abort_statement’ is included in the list of
       potentially blocking operations (see 9.5.1), it is recommended that
       this statement be implemented in a way that never requires the task
!      executing the ‘abort_statement’ to block.”
  
  Followed.
  
--- 13616,13625 ----
  6.54 RM D.6(9-10): Preemptive Abort
  ===================================
  
!      “Even though the 'abort_statement' is included in the list of
       potentially blocking operations (see 9.5.1), it is recommended that
       this statement be implemented in a way that never requires the task
!      executing the 'abort_statement' to block.”
  
  Followed.
  
*************** There are no variations from the standar
*** 13888,13894 ****
     * “Which code_statements cause external interactions.  See
       1.1.3(10).”
  
! Any ‘code_statement’ can potentially cause external interactions.
  
     * “The coded representation for the text of an Ada program.  See
       2.1(4).”
--- 13888,13894 ----
     * “Which code_statements cause external interactions.  See
       1.1.3(10).”
  
! Any 'code_statement' can potentially cause external interactions.
  
     * “The coded representation for the text of an Ada program.  See
       2.1(4).”
*************** See separate section on source represent
*** 13909,13916 ****
  
  The maximum line length is 255 characters and the maximum length of a
  lexical element is also 255 characters.  This is the default setting if
! not overridden by the use of compiler switch ‘-gnaty’ (which sets the
! maximum to 79) or ‘-gnatyMnn’ which allows the maximum line length to be
  specified to be any value up to 32767.  The maximum length of a lexical
  element is the same as the maximum line length.
  
--- 13909,13916 ----
  
  The maximum line length is 255 characters and the maximum length of a
  lexical element is also 255 characters.  This is the default setting if
! not overridden by the use of compiler switch '-gnaty' (which sets the
! maximum to 79) or '-gnatyMnn' which allows the maximum line length to be
  specified to be any value up to 32767.  The maximum length of a lexical
  element is the same as the maximum line length.
  
*************** Type                          Representa
*** 13939,13962 ****
                                
  --------------------------------------------------------------------------
                                
! ‘Short_Short_Integer’         8-bit signed
                                
                                
! ‘Short_Integer’               16-bit signed
                                
                                
! ‘Integer’                     32-bit signed
                                
                                
! ‘Long_Integer’                64-bit signed (on most 64-bit targets,
                                depending on the C definition of long)
                                32-bit signed (on all other targets)
                                
                                
! ‘Long_Long_Integer’           64-bit signed
                                
                                
! ‘Long_Long_Long_Integer’      128-bit signed (on 64-bit targets) 64-bit
                                signed (on 32-bit targets)
                                
  
--- 13939,13962 ----
                                
  --------------------------------------------------------------------------
                                
! 'Short_Short_Integer'         8-bit signed
                                
                                
! 'Short_Integer'               16-bit signed
                                
                                
! 'Integer'                     32-bit signed
                                
                                
! 'Long_Integer'                64-bit signed (on most 64-bit targets,
                                depending on the C definition of long)
                                32-bit signed (on all other targets)
                                
                                
! 'Long_Long_Integer'           64-bit signed
                                
                                
! 'Long_Long_Long_Integer'      128-bit signed (on 64-bit targets) 64-bit
                                signed (on 32-bit targets)
                                
  
*************** Type                       Representatio
*** 13983,13998 ****
                             
  -------------------------------------------------------------------------------
                             
! ‘Short_Float’              IEEE Binary32 (Single)
                             
                             
! ‘Float’                    IEEE Binary32 (Single)
                             
                             
! ‘Long_Float’               IEEE Binary64 (Double)
                             
                             
! ‘Long_Long_Float’          IEEE Binary64 (Double) on non-x86 architectures
                             IEEE 80-bit Extended on x86 architecture
                             
  
--- 13983,13998 ----
                             
  -------------------------------------------------------------------------------
                             
! 'Short_Float'              IEEE Binary32 (Single)
                             
                             
! 'Float'                    IEEE Binary32 (Single)
                             
                             
! 'Long_Float'               IEEE Binary64 (Double)
                             
                             
! 'Long_Long_Float'          IEEE Binary64 (Double) on non-x86 architectures
                             IEEE 80-bit Extended on x86 architecture
                             
  
*************** in 1.0E-18 ..  1.0E+18 and the digits in
*** 14035,14043 ****
  the small must lie in 1.0E-38 ..  1.0E+38 and the digits in 1 ..  38.
  
     * “The result of ‘Tags.Expanded_Name’ for types declared within an
!      unnamed ‘block_statement’.  See 3.9(10).”
  
! Block numbers of the form ‘BNNN’, where ‘nnn’ is a decimal integer are
  allocated.
  
     * “The sequence of characters of the value returned by
--- 14035,14043 ----
  the small must lie in 1.0E-38 ..  1.0E+38 and the digits in 1 ..  38.
  
     * “The result of ‘Tags.Expanded_Name’ for types declared within an
!      unnamed 'block_statement'.  See 3.9(10).”
  
! Block numbers of the form ‘BNNN’, where 'nnn' is a decimal integer are
  allocated.
  
     * “The sequence of characters of the value returned by
*************** Difficult to characterize.
*** 14093,14099 ****
     * “Any extensions of the Default_Initial_Condition aspect.  See
       7.3.3(11).”
  
! SPARK allows specifying ‘null’ as the Default_Initial_Condition aspect
  of a type.  See the SPARK reference manual for further details.
  
     * “Any implementation-defined time types.  See 9.6(6).”
--- 14093,14099 ----
     * “Any extensions of the Default_Initial_Condition aspect.  See
       7.3.3(11).”
  
! SPARK allows specifying 'null' as the Default_Initial_Condition aspect
  of a type.  See the SPARK reference manual for further details.
  
     * “Any implementation-defined time types.  See 9.6(6).”
*************** The time zone used by package ‘Calenda
*** 14117,14123 ****
  setting for local time, as accessed by the C library function
  ‘localtime’.
  
!    * “Any limit on ‘delay_until_statements’ of ‘select_statements’.  See
       9.6(29).”
  
  There are no such limits.
--- 14117,14123 ----
  setting for local time, as accessed by the C library function
  ‘localtime’.
  
!    * “Any limit on 'delay_until_statements' of 'select_statements'.  See
       9.6(29).”
  
  There are no such limits.
*************** There are no implementation-defined conf
*** 14134,14140 ****
     * “The representation for a compilation.  See 10.1(2).”
  
  A compilation is represented by a sequence of files presented to the
! compiler in a single invocation of the ‘gcc’ command.
  
     * “Any restrictions on compilations that contain multiple
       compilation_units.  See 10.1(4).”
--- 14134,14140 ----
     * “The representation for a compilation.  See 10.1(2).”
  
  A compilation is represented by a sequence of files presented to the
! compiler in a single invocation of the 'gcc' command.
  
     * “Any restrictions on compilations that contain multiple
       compilation_units.  See 10.1(4).”
*************** e.g., by foreign language units, then al
*** 14163,14174 ****
  context clause of one of the needed Ada units.
  
  If the partition contains no main program, or if the main program is in
! a language other than Ada, then GNAT provides the binder options ‘-z’
! and ‘-n’ respectively, and in this case a list of units can be
  explicitly supplied to the binder for inclusion in the partition (all
  units needed by these units will also be included automatically).  For
! full details on the use of these options, refer to ‘GNAT Make Program
! gnatmake’ in the ‘GNAT User’s Guide’.
  
     * “The implementation-defined means, if any, of specifying which
       compilation units are needed by a given compilation unit.  See
--- 14163,14174 ----
  context clause of one of the needed Ada units.
  
  If the partition contains no main program, or if the main program is in
! a language other than Ada, then GNAT provides the binder options '-z'
! and '-n' respectively, and in this case a list of units can be
  explicitly supplied to the binder for inclusion in the partition (all
  units needed by these units will also be included automatically).  For
! full details on the use of these options, refer to 'GNAT Make Program
! gnatmake' in the ‘GNAT User’s Guide’.
  
     * “The implementation-defined means, if any, of specifying which
       compilation units are needed by a given compilation unit.  See
*************** units.
*** 14185,14191 ****
  The main program is designated by providing the name of the
  corresponding ‘ALI’ file as the input parameter to the binder.
  
!    * “The order of elaboration of ‘library_items’.  See 10.2(18).”
  
  The first constraint on ordering is that it meets the requirements of
  Chapter 10 of the Ada Reference Manual.  This still leaves some
--- 14185,14191 ----
  The main program is designated by providing the name of the
  corresponding ‘ALI’ file as the input parameter to the binder.
  
!    * “The order of elaboration of 'library_items'.  See 10.2(18).”
  
  The first constraint on ordering is that it meets the requirements of
  Chapter 10 of the Ada Reference Manual.  This still leaves some
*************** Exception message returns the null strin
*** 14228,14236 ****
  been passed by the program.
  
     * “The result of ‘Exceptions.Exception_Name’ for types declared
!      within an unnamed ‘block_statement’.  See 11.4.1(12).”
  
! Blocks have implementation defined names of the form ‘BNNN’ where ‘nnn’
  is an integer.
  
     * “The information returned by ‘Exception_Information’.  See
--- 14228,14236 ----
  been passed by the program.
  
     * “The result of ‘Exceptions.Exception_Name’ for types declared
!      within an unnamed 'block_statement'.  See 11.4.1(12).”
  
! Blocks have implementation defined names of the form ‘BNNN’ where 'nnn'
  is an integer.
  
     * “The information returned by ‘Exception_Information’.  See
*************** declarations are added to package System
*** 14389,14395 ****
  See the definition of package System.Storage_Elements in ‘s-stoele.ads’.
  
     * “The contents of the visible part of package ‘System.Machine_Code’,
!      and the meaning of ‘code_statements’.  See 13.8(7).”
  
  See the definition and documentation in file ‘s-maccod.ads’.
  
--- 14389,14395 ----
  See the definition of package System.Storage_Elements in ‘s-stoele.ads’.
  
     * “The contents of the visible part of package ‘System.Machine_Code’,
!      and the meaning of 'code_statements'.  See 13.8(7).”
  
  See the definition and documentation in file ‘s-maccod.ads’.
  
*************** state vector.
*** 14527,14533 ****
       ‘Model’, ‘Safe_First’, and ‘Safe_Last’ attributes, if the Numerics
       Annex is not supported.  See A.5.3(72).”
  
! Running the compiler with ‘-gnatS’ to produce a listing of package
  ‘Standard’ displays the values of these attributes.
  
     * “The value of ‘Buffer_Size’ in ‘Storage_IO’.  See A.9(10).”
--- 14527,14533 ----
       ‘Model’, ‘Safe_First’, and ‘Safe_Last’ attributes, if the Numerics
       Annex is not supported.  See A.5.3(72).”
  
! Running the compiler with '-gnatS' to produce a listing of package
  ‘Standard’ displays the values of these attributes.
  
     * “The value of ‘Buffer_Size’ in ‘Storage_IO’.  See A.9(10).”
*************** Convention Name             Interpretati
*** 14623,14689 ****
                              
  ---------------------------------------------------------------------------------------------------------------
                              
! ‘Ada’                       Ada
                              
                              
! ‘Ada_Pass_By_Copy’          Allowed for any types except by-reference types such as limited records.
                              Compatible with convention Ada, but causes any parameters with this convention
                              to be passed by copy.
                              
                              
! ‘Ada_Pass_By_Reference’     Allowed for any types except by-copy types such as scalars.  Compatible with
                              convention Ada, but causes any parameters with this convention to be passed by
                              reference.
                              
                              
! ‘Assembler’                 Assembly language
                              
                              
! ‘Asm’                       Synonym for Assembler
                              
                              
! ‘Assembly’                  Synonym for Assembler
                              
                              
! ‘C’                         C
                              
                              
! ‘C_Pass_By_Copy’            Allowed only for record types, like C, but also notes that record is to be
                              passed by copy rather than reference.
                              
                              
! ‘COBOL’                     COBOL
                              
                              
! ‘C_Plus_Plus (or CPP)’      C++
                              
                              
! ‘Default’                   Treated the same as C
                              
                              
! ‘External’                  Treated the same as C
                              
                              
! ‘Fortran’                   Fortran
                              
                              
! ‘Intrinsic’                 For support of pragma ‘Import’ with convention Intrinsic, see separate section
                              on Intrinsic Subprograms.
                              
                              
! ‘Stdcall’                   Stdcall (used for Windows implementations only).  This convention correspond to
                              the WINAPI (previously called Pascal convention) C/C++ convention under Windows.
                              A routine with this convention cleans the stack before exit.  This pragma cannot
                              be applied to a dispatching call.
                              
                              
! ‘DLL’                       Synonym for Stdcall
                              
                              
! ‘Win32’                     Synonym for Stdcall
                              
                              
! ‘Stubbed’                   Stubbed is a special convention used to indicate that the body of the subprogram
                              will be entirely ignored.  Any call to the subprogram is converted into a raise
                              of the ‘Program_Error’ exception.  If a pragma ‘Import’ specifies convention
                              ‘stubbed’ then no body need be present at all.  This convention is useful during
--- 14623,14689 ----
                              
  ---------------------------------------------------------------------------------------------------------------
                              
! 'Ada'                       Ada
                              
                              
! 'Ada_Pass_By_Copy'          Allowed for any types except by-reference types such as limited records.
                              Compatible with convention Ada, but causes any parameters with this convention
                              to be passed by copy.
                              
                              
! 'Ada_Pass_By_Reference'     Allowed for any types except by-copy types such as scalars.  Compatible with
                              convention Ada, but causes any parameters with this convention to be passed by
                              reference.
                              
                              
! 'Assembler'                 Assembly language
                              
                              
! 'Asm'                       Synonym for Assembler
                              
                              
! 'Assembly'                  Synonym for Assembler
                              
                              
! 'C'                         C
                              
                              
! 'C_Pass_By_Copy'            Allowed only for record types, like C, but also notes that record is to be
                              passed by copy rather than reference.
                              
                              
! 'COBOL'                     COBOL
                              
                              
! 'C_Plus_Plus (or CPP)'      C++
                              
                              
! 'Default'                   Treated the same as C
                              
                              
! 'External'                  Treated the same as C
                              
                              
! 'Fortran'                   Fortran
                              
                              
! 'Intrinsic'                 For support of pragma ‘Import’ with convention Intrinsic, see separate section
                              on Intrinsic Subprograms.
                              
                              
! 'Stdcall'                   Stdcall (used for Windows implementations only).  This convention correspond to
                              the WINAPI (previously called Pascal convention) C/C++ convention under Windows.
                              A routine with this convention cleans the stack before exit.  This pragma cannot
                              be applied to a dispatching call.
                              
                              
! 'DLL'                       Synonym for Stdcall
                              
                              
! 'Win32'                     Synonym for Stdcall
                              
                              
! 'Stubbed'                   Stubbed is a special convention used to indicate that the body of the subprogram
                              will be entirely ignored.  Any call to the subprogram is converted into a raise
                              of the ‘Program_Error’ exception.  If a pragma ‘Import’ specifies convention
                              ‘stubbed’ then no body need be present at all.  This convention is useful during
*************** COBOL                     Ada
*** 14744,14765 ****
                            
  -------------------------------------------------------------------
                            
! ‘Floating’                Float
                            
                            
! ‘Long_Floating’           (Floating) Long_Float
                            
                            
! ‘Binary’                  Integer
                            
                            
! ‘Long_Binary’             Long_Long_Integer
                            
                            
! ‘Decimal_Element’         Character
                            
                            
! ‘COBOL_Character’         Character
                            
  
  For initialization, see the file ‘i-cobol.ads’ in the distributed
--- 14744,14765 ----
                            
  -------------------------------------------------------------------
                            
! 'Floating'                Float
                            
                            
! 'Long_Floating'           (Floating) Long_Float
                            
                            
! 'Binary'                  Integer
                            
                            
! 'Long_Binary'             Long_Long_Integer
                            
                            
! 'Decimal_Element'         Character
                            
                            
! 'COBOL_Character'         Character
                            
  
  For initialization, see the file ‘i-cobol.ads’ in the distributed
*************** If Discard_Names is True for an enumerat
*** 14793,14799 ****
  provides the image of the Pos of the literal, and Value accepts Pos
  values.
  
! If both of the aspects‘‘Discard_Names‘‘ and ‘No_Tagged_Streams’ are true
  for a tagged type, its Expanded_Name and External_Tag values are empty
  strings.  This is useful to avoid exposing entity names at binary level.
  
--- 14793,14799 ----
  provides the image of the Pos of the literal, and Value accepts Pos
  values.
  
! If both of the aspects''Discard_Names'' and ‘No_Tagged_Streams’ are true
  for a tagged type, its Expanded_Name and External_Tag values are empty
  strings.  This is useful to avoid exposing entity names at binary level.
  
*************** The value is 1.
*** 14812,14818 ****
  The result of this attribute is a string that identifies the object or
  component that denotes a given task.  If a variable ‘Var’ has a task
  type, the image for this task will have the form ‘Var_XXXXXXXX’, where
! the suffix ‘XXXXXXXX’ is the hexadecimal representation of the virtual
  address of the corresponding task control block.  If the variable is an
  array of tasks, the image of each task will have the form of an indexed
  component indicating the position of a given task in the array, e.g.,
--- 14812,14818 ----
  The result of this attribute is a string that identifies the object or
  component that denotes a given task.  If a variable ‘Var’ has a task
  type, the image for this task will have the form ‘Var_XXXXXXXX’, where
! the suffix 'XXXXXXXX' is the hexadecimal representation of the virtual
  address of the corresponding task control block.  If the variable is an
  array of tasks, the image of each task will have the form of an indexed
  component indicating the position of a given task in the array, e.g.,
*************** There are no implementation-defined task
*** 14875,14881 ****
  
  The value is 10 milliseconds.
  
!    * “Implementation-defined ‘policy_identifiers’ allowed in a pragma
       ‘Locking_Policy’.  See D.3(4).”
  
  The two implementation defined policies permitted in GNAT are
--- 14875,14881 ----
  
  The value is 10 milliseconds.
  
!    * “Implementation-defined 'policy_identifiers' allowed in a pragma
       ‘Locking_Policy’.  See D.3(4).”
  
  The two implementation defined policies permitted in GNAT are
*************** Named Number             Value
*** 15012,15030 ****
                           
  ----------------------------------------
                           
! ‘Max_Scale’              +18
                           
                           
! ‘Min_Scale’              -18
                           
                           
! ‘Min_Delta’              1.0E-18
                           
                           
! ‘Max_Delta’              1.0E+18
                           
                           
! ‘Max_Decimal_Digits’     18
                           
  
     * “The value of ‘Max_Picture_Length’ in the package
--- 15012,15030 ----
                           
  ----------------------------------------
                           
! 'Max_Scale'              +18
                           
                           
! 'Min_Scale'              -18
                           
                           
! 'Min_Delta'              1.0E-18
                           
                           
! 'Max_Delta'              1.0E+18
                           
                           
! 'Max_Decimal_Digits'     18
                           
  
     * “The value of ‘Max_Picture_Length’ in the package
*************** floating-point format.
*** 15078,15084 ****
  Infinite and NaN values are produced as dictated by the IEEE
  floating-point standard.  Note that on machines that are not fully
  compliant with the IEEE floating-point standard, such as Alpha, the
! ‘-mieee’ compiler flag must be used for achieving IEEE conforming
  behavior (although at the cost of a significant performance penalty), so
  infinite and NaN values are properly generated.
  
--- 15078,15084 ----
  Infinite and NaN values are produced as dictated by the IEEE
  floating-point standard.  Note that on machines that are not fully
  compliant with the IEEE floating-point standard, such as Alpha, the
! '-mieee' compiler flag must be used for achieving IEEE conforming
  behavior (although at the cost of a significant performance penalty), so
  infinite and NaN values are properly generated.
  
*************** floating-point arithmetic.  The input op
*** 15097,15103 ****
  floating-point, the operation is done in floating-point, and the result
  is converted to the target type.
  
!    * “Conditions on a ‘universal_real’ operand of a fixed point
       multiplication or division for which the result shall be in the
       perfect result set.  See G.2.3(22).”
  
--- 15097,15103 ----
  floating-point, the operation is done in floating-point, and the result
  is converted to the target type.
  
!    * “Conditions on a 'universal_real' operand of a fixed point
       multiplication or division for which the result shall be in the
       perfect result set.  See G.2.3(22).”
  
*************** same as specifying 1.
*** 15423,15429 ****
  
  The default alignment values are as follows:
  
!    * ‘Elementary Types’.
  
       For elementary types, the alignment is the minimum of the actual
       size of objects of the type divided by ‘Storage_Unit’, and the
--- 15423,15429 ----
  
  The default alignment values are as follows:
  
!    * 'Elementary Types'.
  
       For elementary types, the alignment is the minimum of the actual
       size of objects of the type divided by ‘Storage_Unit’, and the
*************** The default alignment values are as foll
*** 15438,15444 ****
       may be smaller than 8, in which case objects of type ‘Long_Float’
       will be maximally aligned.
  
!    * ‘Arrays’.
  
       For arrays, the alignment is equal to the alignment of the
       component type for the normal case where no packing or component
--- 15438,15444 ----
       may be smaller than 8, in which case objects of type ‘Long_Float’
       will be maximally aligned.
  
!    * 'Arrays'.
  
       For arrays, the alignment is equal to the alignment of the
       component type for the normal case where no packing or component
*************** The default alignment values are as foll
*** 15452,15458 ****
       packed array of length 31 bits will have an object size of four
       bytes, and an alignment of 4.
  
!    * ‘Records’.
  
       For the normal unpacked case, the alignment of a record is equal to
       the maximum alignment of any of its components.  For tagged
--- 15452,15458 ----
       packed array of length 31 bits will have an object size of four
       bytes, and an alignment of 4.
  
!    * 'Records'.
  
       For the normal unpacked case, the alignment of a record is equal to
       the maximum alignment of any of its components.  For tagged
*************** Then ‘Default_Stack_Size’ can be def
*** 15604,15610 ****
  modified as required.  Any tasks requiring stack sizes different from
  the default can have an appropriate alternative reference in the pragma.
  
! You can also use the ‘-d’ binder switch to modify the default stack
  size.
  
  For access types, the ‘Storage_Size’ clause specifies the maximum space
--- 15604,15610 ----
  modified as required.  Any tasks requiring stack sizes different from
  the default can have an appropriate alternative reference in the pragma.
  
! You can also use the '-d' binder switch to modify the default stack
  size.
  
  For access types, the ‘Storage_Size’ clause specifies the maximum space
*************** The default rules for the value of ‘Ob
*** 15824,15830 ****
  as follows:
  
     * The ‘Object_Size’ for base subtypes reflect the natural hardware
!      size in bits (run the compiler with ‘-gnatS’ to find those values
       for numeric types).  Enumeration types and fixed-point base
       subtypes have 8, 16, 32, or 64 bits for this size, depending on the
       range of values to be stored.
--- 15824,15830 ----
  as follows:
  
     * The ‘Object_Size’ for base subtypes reflect the natural hardware
!      size in bits (run the compiler with '-gnatS' to find those values
       for numeric types).  Enumeration types and fixed-point base
       subtypes have 8, 16, 32, or 64 bits for this size, depending on the
       range of values to be stored.
*************** File: gnat_rm.info,  Node: Pragma Pack f
*** 16344,16351 ****
  ===========================
  
  Pragma ‘Pack’ applied to an array has an effect that depends upon
! whether the component type is ‘packable’.  For a component type to be
! ‘packable’, it must be one of the following cases:
  
     * Any elementary type.
  
--- 16344,16351 ----
  ===========================
  
  Pragma ‘Pack’ applied to an array has an effect that depends upon
! whether the component type is 'packable'.  For a component type to be
! 'packable', it must be one of the following cases:
  
     * Any elementary type.
  
*************** File: gnat_rm.info,  Node: Pragma Pack f
*** 16448,16455 ****
  
  Pragma ‘Pack’ applied to a record will pack the components to reduce
  wasted space from alignment gaps and by reducing the amount of space
! taken by components.  We distinguish between ‘packable’ components and
! ‘non-packable’ components.  Components of the following types are
  considered packable:
  
     * Components of an elementary type are packable unless they are
--- 16448,16455 ----
  
  Pragma ‘Pack’ applied to a record will pack the components to reduce
  wasted space from alignment gaps and by reducing the amount of space
! taken by components.  We distinguish between 'packable' components and
! 'non-packable' components.  Components of the following types are
  considered packable:
  
     * Components of an elementary type are packable unless they are
*************** be in the range:
*** 16671,16677 ****
  
       0 .. System.Max_Binary_Modulus;
  
! A ‘confirming’ representation clause is one in which the values range
  from 0 in sequence, i.e., a clause that confirms the default
  representation for an enumeration type.  Such a confirming
  representation is permitted by these rules, and is specially recognized
--- 16671,16677 ----
  
       0 .. System.Max_Binary_Modulus;
  
! A 'confirming' representation clause is one in which the values range
  from 0 in sequence, i.e., a clause that confirms the default
  representation for an enumeration type.  Such a confirming
  representation is permitted by these rules, and is specially recognized
*************** example) has no effect.
*** 17046,17052 ****
  
  There are four exceptions to this general rule:
  
!    * ‘Convention Fortran and array subtypes’.
  
       If pragma Convention Fortran is specified for an array subtype,
       then in accordance with the implementation advice in section
--- 17046,17052 ----
  
  There are four exceptions to this general rule:
  
!    * 'Convention Fortran and array subtypes'.
  
       If pragma Convention Fortran is specified for an array subtype,
       then in accordance with the implementation advice in section
*************** There are four exceptions to this genera
*** 17054,17060 ****
       a Fortran-compatible column-major manner, instead of the normal
       default row-major order.
  
!    * ‘Convention C and enumeration types’
  
       GNAT normally stores enumeration types in 8, 16, or 32 bits as
       required to accommodate all values of the type.  For example, for
--- 17054,17060 ----
       a Fortran-compatible column-major manner, instead of the normal
       default row-major order.
  
!    * 'Convention C and enumeration types'
  
       GNAT normally stores enumeration types in 8, 16, or 32 bits as
       required to accommodate all values of the type.  For example, for
*************** There are four exceptions to this genera
*** 17079,17085 ****
       this situation.  The warning can be suppressed by giving an
       explicit size clause specifying the desired size.
  
!    * ‘Convention C/Fortran and Boolean types’
  
       In C, the usual convention for boolean values, that is values used
       for conditions, is that zero represents false, and nonzero values
--- 17079,17085 ----
       this situation.  The warning can be suppressed by giving an
       explicit size clause specifying the desired size.
  
!    * 'Convention C/Fortran and Boolean types'
  
       In C, the usual convention for boolean values, that is values used
       for conditions, is that zero represents false, and nonzero values
*************** resulting fields placed?  The section on
*** 17195,17204 ****
  can be used to answer the second question, but it is often easier to
  just see what the compiler does.
  
! For this purpose, GNAT provides the option ‘-gnatR’.  If you compile
! with this option, then the compiler will output information on the
! actual representations chosen, in a format similar to source
! representation clauses.  For example, if we compile the package:
  
       package q is
          type r (x : boolean) is tagged record
--- 17195,17204 ----
  can be used to answer the second question, but it is often easier to
  just see what the compiler does.
  
! For this purpose, GNAT provides the option '-gnatR'. If you compile with
! this option, then the compiler will output information on the actual
! representations chosen, in a format similar to source representation
! clauses.  For example, if we compile the package:
  
       package q is
          type r (x : boolean) is tagged record
*************** representation clauses.  For example, if
*** 17242,17248 ****
          pragma Pack (x2);
       end q;
  
! using the switch ‘-gnatR’ we obtain the following output:
  
       Representation information for unit q
       -------------------------------------
--- 17242,17248 ----
          pragma Pack (x2);
       end q;
  
! using the switch '-gnatR' we obtain the following output:
  
       Representation information for unit q
       -------------------------------------
*************** units are not implemented, as marked by
*** 17346,17402 ****
  Unimplemented_Unit, and in this case the package declaration contains
  comments explaining why the unit is not implemented.
  
! ‘Ada’ ‘(A.2)’
  
       This is a parent package for all the standard library packages.  It
       is usually included implicitly in your program, and itself contains
       no useful data or routines.
  
! ‘Ada.Assertions’ ‘(11.4.2)’
  
       ‘Assertions’ provides the ‘Assert’ subprograms, and also the
       declaration of the ‘Assertion_Error’ exception.
  
! ‘Ada.Asynchronous_Task_Control’ ‘(D.11)’
  
       ‘Asynchronous_Task_Control’ provides low level facilities for task
       synchronization.  It is typically not implemented.  See package
       spec for details.
  
! ‘Ada.Calendar’ ‘(9.6)’
  
       ‘Calendar’ provides time of day access, and routines for
       manipulating times and durations.
  
! ‘Ada.Calendar.Arithmetic’ ‘(9.6.1)’
  
       This package provides additional arithmetic operations for
       ‘Calendar’.
  
! ‘Ada.Calendar.Formatting’ ‘(9.6.1)’
  
       This package provides formatting operations for ‘Calendar’.
  
! ‘Ada.Calendar.Time_Zones’ ‘(9.6.1)’
  
       This package provides additional ‘Calendar’ facilities for handling
       time zones.
  
! ‘Ada.Characters’ ‘(A.3.1)’
  
       This is a dummy parent package that contains no useful entities
  
! ‘Ada.Characters.Conversions’ ‘(A.3.2)’
  
       This package provides character conversion functions.
  
! ‘Ada.Characters.Handling’ ‘(A.3.2)’
  
       This package provides some basic character handling capabilities,
       including classification functions for classes of characters (e.g.,
       test for letters, or digits).
  
! ‘Ada.Characters.Latin_1’ ‘(A.3.3)’
  
       This package includes a complete set of definitions of the
       characters that appear in type CHARACTER. It is useful for writing
--- 17346,17402 ----
  Unimplemented_Unit, and in this case the package declaration contains
  comments explaining why the unit is not implemented.
  
! ‘Ada’ '(A.2)'
  
       This is a parent package for all the standard library packages.  It
       is usually included implicitly in your program, and itself contains
       no useful data or routines.
  
! ‘Ada.Assertions’ '(11.4.2)'
  
       ‘Assertions’ provides the ‘Assert’ subprograms, and also the
       declaration of the ‘Assertion_Error’ exception.
  
! ‘Ada.Asynchronous_Task_Control’ '(D.11)'
  
       ‘Asynchronous_Task_Control’ provides low level facilities for task
       synchronization.  It is typically not implemented.  See package
       spec for details.
  
! ‘Ada.Calendar’ '(9.6)'
  
       ‘Calendar’ provides time of day access, and routines for
       manipulating times and durations.
  
! ‘Ada.Calendar.Arithmetic’ '(9.6.1)'
  
       This package provides additional arithmetic operations for
       ‘Calendar’.
  
! ‘Ada.Calendar.Formatting’ '(9.6.1)'
  
       This package provides formatting operations for ‘Calendar’.
  
! ‘Ada.Calendar.Time_Zones’ '(9.6.1)'
  
       This package provides additional ‘Calendar’ facilities for handling
       time zones.
  
! ‘Ada.Characters’ '(A.3.1)'
  
       This is a dummy parent package that contains no useful entities
  
! ‘Ada.Characters.Conversions’ '(A.3.2)'
  
       This package provides character conversion functions.
  
! ‘Ada.Characters.Handling’ '(A.3.2)'
  
       This package provides some basic character handling capabilities,
       including classification functions for classes of characters (e.g.,
       test for letters, or digits).
  
! ‘Ada.Characters.Latin_1’ '(A.3.3)'
  
       This package includes a complete set of definitions of the
       characters that appear in type CHARACTER. It is useful for writing
*************** comments explaining why the unit is not
*** 17406,17603 ****
       Then your program will print in an understandable manner even if
       your environment does not support these extended characters.
  
! ‘Ada.Command_Line’ ‘(A.15)’
  
       This package provides access to the command line parameters and the
       name of the current program (analogous to the use of ‘argc’ and
       ‘argv’ in C), and also allows the exit status for the program to be
       set in a system-independent manner.
  
! ‘Ada.Complex_Text_IO’ ‘(G.1.3)’
  
       This package provides text input and output of complex numbers.
  
! ‘Ada.Containers’ ‘(A.18.1)’
  
       A top level package providing a few basic definitions used by all
       the following specific child packages that provide specific kinds
       of containers.
  
! ‘Ada.Containers.Bounded_Priority_Queues’ ‘(A.18.31)’
  
! ‘Ada.Containers.Bounded_Synchronized_Queues’ ‘(A.18.29)’
  
! ‘Ada.Containers.Doubly_Linked_Lists’ ‘(A.18.3)’
  
! ‘Ada.Containers.Generic_Array_Sort’ ‘(A.18.26)’
  
! ‘Ada.Containers.Generic_Constrained_Array_Sort’ ‘(A.18.26)’
  
! ‘Ada.Containers.Generic_Sort’ ‘(A.18.26)’
  
! ‘Ada.Containers.Hashed_Maps’ ‘(A.18.5)’
  
! ‘Ada.Containers.Hashed_Sets’ ‘(A.18.8)’
  
! ‘Ada.Containers.Indefinite_Doubly_Linked_Lists’ ‘(A.18.12)’
  
! ‘Ada.Containers.Indefinite_Hashed_Maps’ ‘(A.18.13)’
  
! ‘Ada.Containers.Indefinite_Hashed_Sets’ ‘(A.18.15)’
  
! ‘Ada.Containers.Indefinite_Holders’ ‘(A.18.18)’
  
! ‘Ada.Containers.Indefinite_Multiway_Trees’ ‘(A.18.17)’
  
! ‘Ada.Containers.Indefinite_Ordered_Maps’ ‘(A.18.14)’
  
! ‘Ada.Containers.Indefinite_Ordered_Sets’ ‘(A.18.16)’
  
! ‘Ada.Containers.Indefinite_Vectors’ ‘(A.18.11)’
  
! ‘Ada.Containers.Multiway_Trees’ ‘(A.18.10)’
  
! ‘Ada.Containers.Ordered_Maps’ ‘(A.18.6)’
  
! ‘Ada.Containers.Ordered_Sets’ ‘(A.18.9)’
  
! ‘Ada.Containers.Synchronized_Queue_Interfaces’ ‘(A.18.27)’
  
! ‘Ada.Containers.Unbounded_Priority_Queues’ ‘(A.18.30)’
  
! ‘Ada.Containers.Unbounded_Synchronized_Queues’ ‘(A.18.28)’
  
! ‘Ada.Containers.Vectors’ ‘(A.18.2)’
  
! ‘Ada.Directories’ ‘(A.16)’
  
       This package provides operations on directories.
  
! ‘Ada.Directories.Hierarchical_File_Names’ ‘(A.16.1)’
  
       This package provides additional directory operations handling
       hierarchical file names.
  
! ‘Ada.Directories.Information’ ‘(A.16)’
  
       This is an implementation defined package for additional directory
       operations, which is not implemented in GNAT.
  
! ‘Ada.Decimal’ ‘(F.2)’
  
       This package provides constants describing the range of decimal
       numbers implemented, and also a decimal divide routine (analogous
       to the COBOL verb DIVIDE … GIVING … REMAINDER …)
  
! ‘Ada.Direct_IO’ ‘(A.8.4)’
  
       This package provides input-output using a model of a set of
       records of fixed-length, containing an arbitrary definite Ada type,
       indexed by an integer record number.
  
! ‘Ada.Dispatching’ ‘(D.2.1)’
  
       A parent package containing definitions for task dispatching
       operations.
  
! ‘Ada.Dispatching.EDF’ ‘(D.2.6)’
  
       Not implemented in GNAT.
  
! ‘Ada.Dispatching.Non_Preemptive’ ‘(D.2.4)’
  
       Not implemented in GNAT.
  
! ‘Ada.Dispatching.Round_Robin’ ‘(D.2.5)’
  
       Not implemented in GNAT.
  
! ‘Ada.Dynamic_Priorities’ ‘(D.5)’
  
       This package allows the priorities of a task to be adjusted
       dynamically as the task is running.
  
! ‘Ada.Environment_Variables’ ‘(A.17)’
  
       This package provides facilities for accessing environment
       variables.
  
! ‘Ada.Exceptions’ ‘(11.4.1)’
  
       This package provides additional information on exceptions, and
       also contains facilities for treating exceptions as data objects,
       and raising exceptions with associated messages.
  
! ‘Ada.Execution_Time’ ‘(D.14)’
  
       This package provides CPU clock functionalities.  It is not
       implemented on all targets (see package spec for details).
  
! ‘Ada.Execution_Time.Group_Budgets’ ‘(D.14.2)’
  
       Not implemented in GNAT.
  
! ‘Ada.Execution_Time.Timers’ ‘(D.14.1)’’
  
       Not implemented in GNAT.
  
! ‘Ada.Finalization’ ‘(7.6)’
  
       This package contains the declarations and subprograms to support
       the use of controlled types, providing for automatic initialization
       and finalization (analogous to the constructors and destructors of
       C++).
  
! ‘Ada.Float_Text_IO’ ‘(A.10.9)’
  
       A library level instantiation of Text_IO.Float_IO for type Float.
  
! ‘Ada.Float_Wide_Text_IO’ ‘(A.10.9)’
  
       A library level instantiation of Wide_Text_IO.Float_IO for type
       Float.
  
! ‘Ada.Float_Wide_Wide_Text_IO’ ‘(A.10.9)’
  
       A library level instantiation of Wide_Wide_Text_IO.Float_IO for
       type Float.
  
! ‘Ada.Integer_Text_IO’ ‘(A.10.9)’
  
       A library level instantiation of Text_IO.Integer_IO for type
       Integer.
  
! ‘Ada.Integer_Wide_Text_IO’ ‘(A.10.9)’
  
       A library level instantiation of Wide_Text_IO.Integer_IO for type
       Integer.
  
! ‘Ada.Integer_Wide_Wide_Text_IO’ ‘(A.10.9)’
  
       A library level instantiation of Wide_Wide_Text_IO.Integer_IO for
       type Integer.
  
! ‘Ada.Interrupts’ ‘(C.3.2)’
  
       This package provides facilities for interfacing to interrupts,
       which includes the set of signals or conditions that can be raised
       and recognized as interrupts.
  
! ‘Ada.Interrupts.Names’ ‘(C.3.2)’
  
       This package provides the set of interrupt names (actually signal
       or condition names) that can be handled by GNAT.
  
! ‘Ada.IO_Exceptions’ ‘(A.13)’
  
       This package defines the set of exceptions that can be raised by
       use of the standard IO packages.
  
! ‘Ada.Iterator_Interfaces’ ‘(5.5.1)’
  
       This package provides a generic interface to generalized iterators.
  
! ‘Ada.Locales’ ‘(A.19)’
  
       This package provides declarations providing information (Language
       and Country) about the current locale.
--- 17406,17603 ----
       Then your program will print in an understandable manner even if
       your environment does not support these extended characters.
  
! ‘Ada.Command_Line’ '(A.15)'
  
       This package provides access to the command line parameters and the
       name of the current program (analogous to the use of ‘argc’ and
       ‘argv’ in C), and also allows the exit status for the program to be
       set in a system-independent manner.
  
! ‘Ada.Complex_Text_IO’ '(G.1.3)'
  
       This package provides text input and output of complex numbers.
  
! ‘Ada.Containers’ '(A.18.1)'
  
       A top level package providing a few basic definitions used by all
       the following specific child packages that provide specific kinds
       of containers.
  
! ‘Ada.Containers.Bounded_Priority_Queues’ '(A.18.31)'
  
! ‘Ada.Containers.Bounded_Synchronized_Queues’ '(A.18.29)'
  
! ‘Ada.Containers.Doubly_Linked_Lists’ '(A.18.3)'
  
! ‘Ada.Containers.Generic_Array_Sort’ '(A.18.26)'
  
! ‘Ada.Containers.Generic_Constrained_Array_Sort’ '(A.18.26)'
  
! ‘Ada.Containers.Generic_Sort’ '(A.18.26)'
  
! ‘Ada.Containers.Hashed_Maps’ '(A.18.5)'
  
! ‘Ada.Containers.Hashed_Sets’ '(A.18.8)'
  
! ‘Ada.Containers.Indefinite_Doubly_Linked_Lists’ '(A.18.12)'
  
! ‘Ada.Containers.Indefinite_Hashed_Maps’ '(A.18.13)'
  
! ‘Ada.Containers.Indefinite_Hashed_Sets’ '(A.18.15)'
  
! ‘Ada.Containers.Indefinite_Holders’ '(A.18.18)'
  
! ‘Ada.Containers.Indefinite_Multiway_Trees’ '(A.18.17)'
  
! ‘Ada.Containers.Indefinite_Ordered_Maps’ '(A.18.14)'
  
! ‘Ada.Containers.Indefinite_Ordered_Sets’ '(A.18.16)'
  
! ‘Ada.Containers.Indefinite_Vectors’ '(A.18.11)'
  
! ‘Ada.Containers.Multiway_Trees’ '(A.18.10)'
  
! ‘Ada.Containers.Ordered_Maps’ '(A.18.6)'
  
! ‘Ada.Containers.Ordered_Sets’ '(A.18.9)'
  
! ‘Ada.Containers.Synchronized_Queue_Interfaces’ '(A.18.27)'
  
! ‘Ada.Containers.Unbounded_Priority_Queues’ '(A.18.30)'
  
! ‘Ada.Containers.Unbounded_Synchronized_Queues’ '(A.18.28)'
  
! ‘Ada.Containers.Vectors’ '(A.18.2)'
  
! ‘Ada.Directories’ '(A.16)'
  
       This package provides operations on directories.
  
! ‘Ada.Directories.Hierarchical_File_Names’ '(A.16.1)'
  
       This package provides additional directory operations handling
       hierarchical file names.
  
! ‘Ada.Directories.Information’ '(A.16)'
  
       This is an implementation defined package for additional directory
       operations, which is not implemented in GNAT.
  
! ‘Ada.Decimal’ '(F.2)'
  
       This package provides constants describing the range of decimal
       numbers implemented, and also a decimal divide routine (analogous
       to the COBOL verb DIVIDE … GIVING … REMAINDER …)
  
! ‘Ada.Direct_IO’ '(A.8.4)'
  
       This package provides input-output using a model of a set of
       records of fixed-length, containing an arbitrary definite Ada type,
       indexed by an integer record number.
  
! ‘Ada.Dispatching’ '(D.2.1)'
  
       A parent package containing definitions for task dispatching
       operations.
  
! ‘Ada.Dispatching.EDF’ '(D.2.6)'
  
       Not implemented in GNAT.
  
! ‘Ada.Dispatching.Non_Preemptive’ '(D.2.4)'
  
       Not implemented in GNAT.
  
! ‘Ada.Dispatching.Round_Robin’ '(D.2.5)'
  
       Not implemented in GNAT.
  
! ‘Ada.Dynamic_Priorities’ '(D.5)'
  
       This package allows the priorities of a task to be adjusted
       dynamically as the task is running.
  
! ‘Ada.Environment_Variables’ '(A.17)'
  
       This package provides facilities for accessing environment
       variables.
  
! ‘Ada.Exceptions’ '(11.4.1)'
  
       This package provides additional information on exceptions, and
       also contains facilities for treating exceptions as data objects,
       and raising exceptions with associated messages.
  
! ‘Ada.Execution_Time’ '(D.14)'
  
       This package provides CPU clock functionalities.  It is not
       implemented on all targets (see package spec for details).
  
! ‘Ada.Execution_Time.Group_Budgets’ '(D.14.2)'
  
       Not implemented in GNAT.
  
! ‘Ada.Execution_Time.Timers’ '(D.14.1)’'
  
       Not implemented in GNAT.
  
! ‘Ada.Finalization’ '(7.6)'
  
       This package contains the declarations and subprograms to support
       the use of controlled types, providing for automatic initialization
       and finalization (analogous to the constructors and destructors of
       C++).
  
! ‘Ada.Float_Text_IO’ '(A.10.9)'
  
       A library level instantiation of Text_IO.Float_IO for type Float.
  
! ‘Ada.Float_Wide_Text_IO’ '(A.10.9)'
  
       A library level instantiation of Wide_Text_IO.Float_IO for type
       Float.
  
! ‘Ada.Float_Wide_Wide_Text_IO’ '(A.10.9)'
  
       A library level instantiation of Wide_Wide_Text_IO.Float_IO for
       type Float.
  
! ‘Ada.Integer_Text_IO’ '(A.10.9)'
  
       A library level instantiation of Text_IO.Integer_IO for type
       Integer.
  
! ‘Ada.Integer_Wide_Text_IO’ '(A.10.9)'
  
       A library level instantiation of Wide_Text_IO.Integer_IO for type
       Integer.
  
! ‘Ada.Integer_Wide_Wide_Text_IO’ '(A.10.9)'
  
       A library level instantiation of Wide_Wide_Text_IO.Integer_IO for
       type Integer.
  
! ‘Ada.Interrupts’ '(C.3.2)'
  
       This package provides facilities for interfacing to interrupts,
       which includes the set of signals or conditions that can be raised
       and recognized as interrupts.
  
! ‘Ada.Interrupts.Names’ '(C.3.2)'
  
       This package provides the set of interrupt names (actually signal
       or condition names) that can be handled by GNAT.
  
! ‘Ada.IO_Exceptions’ '(A.13)'
  
       This package defines the set of exceptions that can be raised by
       use of the standard IO packages.
  
! ‘Ada.Iterator_Interfaces’ '(5.5.1)'
  
       This package provides a generic interface to generalized iterators.
  
! ‘Ada.Locales’ '(A.19)'
  
       This package provides declarations providing information (Language
       and Country) about the current locale.
*************** comments explaining why the unit is not
*** 17609,17615 ****
       are defined here, and it is better to use these definitions than
       rolling your own.
  
! ‘Ada.Numerics.Complex_Arrays’ ‘(G.3.2)’
  
       Provides operations on arrays of complex numbers.
  
--- 17609,17615 ----
       are defined here, and it is better to use these definitions than
       rolling your own.
  
! ‘Ada.Numerics.Complex_Arrays’ '(G.3.2)'
  
       Provides operations on arrays of complex numbers.
  
*************** comments explaining why the unit is not
*** 17698,17712 ****
  
            ‘Ada.Numerics.Long_Elementary_Functions’
  
! ‘Ada.Numerics.Generic_Real_Arrays’ ‘(G.3.1)’
  
       Generic operations on arrays of reals
  
! ‘Ada.Numerics.Real_Arrays’ ‘(G.3.1)’
  
       Preinstantiation of Ada.Numerics.Generic_Real_Arrays (Float).
  
! ‘Ada.Real_Time’ ‘(D.8)’
  
       This package provides facilities similar to those of ‘Calendar’,
       but operating with a finer clock suitable for real time control.
--- 17698,17712 ----
  
            ‘Ada.Numerics.Long_Elementary_Functions’
  
! ‘Ada.Numerics.Generic_Real_Arrays’ '(G.3.1)'
  
       Generic operations on arrays of reals
  
! ‘Ada.Numerics.Real_Arrays’ '(G.3.1)'
  
       Preinstantiation of Ada.Numerics.Generic_Real_Arrays (Float).
  
! ‘Ada.Real_Time’ '(D.8)'
  
       This package provides facilities similar to those of ‘Calendar’,
       but operating with a finer clock suitable for real time control.
*************** comments explaining why the unit is not
*** 17715,17743 ****
       external clock on which the GNAT runtime depends is deliberately
       reset by some external event, then such a backward jump may occur.
  
! ‘Ada.Real_Time.Timing_Events’ ‘(D.15)’
  
       Not implemented in GNAT.
  
! ‘Ada.Sequential_IO’ ‘(A.8.1)’
  
       This package provides input-output facilities for sequential files,
       which can contain a sequence of values of a single type, which can
       be any Ada type, including indefinite (unconstrained) types.
  
! ‘Ada.Storage_IO’ ‘(A.9)’
  
       This package provides a facility for mapping arbitrary Ada types to
       and from a storage buffer.  It is primarily intended for the
       creation of new IO packages.
  
! ‘Ada.Streams’ ‘(13.13.1)’
  
       This is a generic package that provides the basic support for the
       concept of streams as used by the stream attributes (‘Input’,
       ‘Output’, ‘Read’ and ‘Write’).
  
! ‘Ada.Streams.Stream_IO’ ‘(A.12.1)’
  
       This package is a specialization of the type ‘Streams’ defined in
       package ‘Streams’ together with a set of operations providing
--- 17715,17743 ----
       external clock on which the GNAT runtime depends is deliberately
       reset by some external event, then such a backward jump may occur.
  
! ‘Ada.Real_Time.Timing_Events’ '(D.15)'
  
       Not implemented in GNAT.
  
! ‘Ada.Sequential_IO’ '(A.8.1)'
  
       This package provides input-output facilities for sequential files,
       which can contain a sequence of values of a single type, which can
       be any Ada type, including indefinite (unconstrained) types.
  
! ‘Ada.Storage_IO’ '(A.9)'
  
       This package provides a facility for mapping arbitrary Ada types to
       and from a storage buffer.  It is primarily intended for the
       creation of new IO packages.
  
! ‘Ada.Streams’ '(13.13.1)'
  
       This is a generic package that provides the basic support for the
       concept of streams as used by the stream attributes (‘Input’,
       ‘Output’, ‘Read’ and ‘Write’).
  
! ‘Ada.Streams.Stream_IO’ '(A.12.1)'
  
       This package is a specialization of the type ‘Streams’ defined in
       package ‘Streams’ together with a set of operations providing
*************** comments explaining why the unit is not
*** 17745,17825 ****
       sequential access to a file which can contain an arbitrary set of
       values of one or more Ada types.
  
! ‘Ada.Strings’ ‘(A.4.1)’
  
       This package provides some basic constants used by the string
       handling packages.
  
! ‘Ada.Strings.Bounded’ ‘(A.4.4)’
  
       This package provides facilities for handling variable length
       strings.  The bounded model requires a maximum length.  It is thus
       somewhat more limited than the unbounded model, but avoids the use
       of dynamic allocation or finalization.
  
! ‘Ada.Strings.Bounded.Equal_Case_Insensitive’ ‘(A.4.10)’
  
       Provides case-insensitive comparisons of bounded strings
  
! ‘Ada.Strings.Bounded.Hash’ ‘(A.4.9)’
  
       This package provides a generic hash function for bounded strings
  
! ‘Ada.Strings.Bounded.Hash_Case_Insensitive’ ‘(A.4.9)’
  
       This package provides a generic hash function for bounded strings
       that converts the string to be hashed to lower case.
  
! ‘Ada.Strings.Bounded.Less_Case_Insensitive’ ‘(A.4.10)’
  
       This package provides a comparison function for bounded strings
       that works in a case insensitive manner by converting to lower case
       before the comparison.
  
! ‘Ada.Strings.Fixed’ ‘(A.4.3)’
  
       This package provides facilities for handling fixed length strings.
  
! ‘Ada.Strings.Fixed.Equal_Case_Insensitive’ ‘(A.4.10)’
  
       This package provides an equality function for fixed strings that
       compares the strings after converting both to lower case.
  
! ‘Ada.Strings.Fixed.Hash_Case_Insensitive’ ‘(A.4.9)’
  
       This package provides a case insensitive hash function for fixed
       strings that converts the string to lower case before computing the
       hash.
  
! ‘Ada.Strings.Fixed.Less_Case_Insensitive’ ‘(A.4.10)’
  
       This package provides a comparison function for fixed strings that
       works in a case insensitive manner by converting to lower case
       before the comparison.
  
! ‘Ada.Strings.Hash’ ‘(A.4.9)’
  
       This package provides a hash function for strings.
  
! ‘Ada.Strings.Hash_Case_Insensitive’ ‘(A.4.9)’
  
       This package provides a hash function for strings that is case
       insensitive.  The string is converted to lower case before
       computing the hash.
  
! ‘Ada.Strings.Less_Case_Insensitive’ ‘(A.4.10)’
  
       This package provides a comparison function for\strings that works
       in a case insensitive manner by converting to lower case before the
       comparison.
  
! ‘Ada.Strings.Maps’ ‘(A.4.2)’
  
       This package provides facilities for handling character mappings
       and arbitrarily defined subsets of characters.  For instance it is
       useful in defining specialized translation tables.
  
! ‘Ada.Strings.Maps.Constants’ ‘(A.4.6)’
  
       This package provides a standard set of predefined mappings and
       predefined character sets.  For example, the standard upper to
--- 17745,17825 ----
       sequential access to a file which can contain an arbitrary set of
       values of one or more Ada types.
  
! ‘Ada.Strings’ '(A.4.1)'
  
       This package provides some basic constants used by the string
       handling packages.
  
! ‘Ada.Strings.Bounded’ '(A.4.4)'
  
       This package provides facilities for handling variable length
       strings.  The bounded model requires a maximum length.  It is thus
       somewhat more limited than the unbounded model, but avoids the use
       of dynamic allocation or finalization.
  
! ‘Ada.Strings.Bounded.Equal_Case_Insensitive’ '(A.4.10)'
  
       Provides case-insensitive comparisons of bounded strings
  
! ‘Ada.Strings.Bounded.Hash’ '(A.4.9)'
  
       This package provides a generic hash function for bounded strings
  
! ‘Ada.Strings.Bounded.Hash_Case_Insensitive’ '(A.4.9)'
  
       This package provides a generic hash function for bounded strings
       that converts the string to be hashed to lower case.
  
! ‘Ada.Strings.Bounded.Less_Case_Insensitive’ '(A.4.10)'
  
       This package provides a comparison function for bounded strings
       that works in a case insensitive manner by converting to lower case
       before the comparison.
  
! ‘Ada.Strings.Fixed’ '(A.4.3)'
  
       This package provides facilities for handling fixed length strings.
  
! ‘Ada.Strings.Fixed.Equal_Case_Insensitive’ '(A.4.10)'
  
       This package provides an equality function for fixed strings that
       compares the strings after converting both to lower case.
  
! ‘Ada.Strings.Fixed.Hash_Case_Insensitive’ '(A.4.9)'
  
       This package provides a case insensitive hash function for fixed
       strings that converts the string to lower case before computing the
       hash.
  
! ‘Ada.Strings.Fixed.Less_Case_Insensitive’ '(A.4.10)'
  
       This package provides a comparison function for fixed strings that
       works in a case insensitive manner by converting to lower case
       before the comparison.
  
! ‘Ada.Strings.Hash’ '(A.4.9)'
  
       This package provides a hash function for strings.
  
! ‘Ada.Strings.Hash_Case_Insensitive’ '(A.4.9)'
  
       This package provides a hash function for strings that is case
       insensitive.  The string is converted to lower case before
       computing the hash.
  
! ‘Ada.Strings.Less_Case_Insensitive’ '(A.4.10)'
  
       This package provides a comparison function for\strings that works
       in a case insensitive manner by converting to lower case before the
       comparison.
  
! ‘Ada.Strings.Maps’ '(A.4.2)'
  
       This package provides facilities for handling character mappings
       and arbitrarily defined subsets of characters.  For instance it is
       useful in defining specialized translation tables.
  
! ‘Ada.Strings.Maps.Constants’ '(A.4.6)'
  
       This package provides a standard set of predefined mappings and
       predefined character sets.  For example, the standard upper to
*************** comments explaining why the unit is not
*** 17829,17914 ****
       with an acute accent, into account.  You should use the mappings in
       this package (rather than adding 32 yourself) to do case mappings.
  
! ‘Ada.Strings.Unbounded’ ‘(A.4.5)’
  
       This package provides facilities for handling variable length
       strings.  The unbounded model allows arbitrary length strings, but
       requires the use of dynamic allocation and finalization.
  
! ‘Ada.Strings.Unbounded.Equal_Case_Insensitive’ ‘(A.4.10)’
  
       Provides case-insensitive comparisons of unbounded strings
  
! ‘Ada.Strings.Unbounded.Hash’ ‘(A.4.9)’
  
       This package provides a generic hash function for unbounded strings
  
! ‘Ada.Strings.Unbounded.Hash_Case_Insensitive’ ‘(A.4.9)’
  
       This package provides a generic hash function for unbounded strings
       that converts the string to be hashed to lower case.
  
! ‘Ada.Strings.Unbounded.Less_Case_Insensitive’ ‘(A.4.10)’
  
       This package provides a comparison function for unbounded strings
       that works in a case insensitive manner by converting to lower case
       before the comparison.
  
! ‘Ada.Strings.UTF_Encoding’ ‘(A.4.11)’
  
       This package provides basic definitions for dealing with
       UTF-encoded strings.
  
! ‘Ada.Strings.UTF_Encoding.Conversions’ ‘(A.4.11)’
  
       This package provides conversion functions for UTF-encoded strings.
  
! ‘Ada.Strings.UTF_Encoding.Strings’ ‘(A.4.11)’
  
! ‘Ada.Strings.UTF_Encoding.Wide_Strings’ ‘(A.4.11)’
  
! ‘Ada.Strings.UTF_Encoding.Wide_Wide_Strings’ ‘(A.4.11)’
  
       These packages provide facilities for handling UTF encodings for
       Strings, Wide_Strings and Wide_Wide_Strings.
  
! ‘Ada.Strings.Wide_Bounded’ ‘(A.4.7)’
  
! ‘Ada.Strings.Wide_Fixed’ ‘(A.4.7)’
  
! ‘Ada.Strings.Wide_Maps’ ‘(A.4.7)’
  
! ‘Ada.Strings.Wide_Unbounded’ ‘(A.4.7)’
  
       These packages provide analogous capabilities to the corresponding
       packages without ‘Wide_’ in the name, but operate with the types
       ‘Wide_String’ and ‘Wide_Character’ instead of ‘String’ and
       ‘Character’.  Versions of all the child packages are available.
  
! ‘Ada.Strings.Wide_Wide_Bounded’ ‘(A.4.7)’
  
! ‘Ada.Strings.Wide_Wide_Fixed’ ‘(A.4.7)’
  
! ‘Ada.Strings.Wide_Wide_Maps’ ‘(A.4.7)’
  
! ‘Ada.Strings.Wide_Wide_Unbounded’ ‘(A.4.7)’
  
       These packages provide analogous capabilities to the corresponding
       packages without ‘Wide_’ in the name, but operate with the types
       ‘Wide_Wide_String’ and ‘Wide_Wide_Character’ instead of ‘String’
       and ‘Character’.
  
! ‘Ada.Synchronous_Barriers’ ‘(D.10.1)’
  
       This package provides facilities for synchronizing tasks at a low
       level with barriers.
  
! ‘Ada.Synchronous_Task_Control’ ‘(D.10)’
  
       This package provides some standard facilities for controlling task
       communication in a synchronous manner.
  
! ‘Ada.Synchronous_Task_Control.EDF’ ‘(D.10)’
  
       Not implemented in GNAT.
  
--- 17829,17914 ----
       with an acute accent, into account.  You should use the mappings in
       this package (rather than adding 32 yourself) to do case mappings.
  
! ‘Ada.Strings.Unbounded’ '(A.4.5)'
  
       This package provides facilities for handling variable length
       strings.  The unbounded model allows arbitrary length strings, but
       requires the use of dynamic allocation and finalization.
  
! ‘Ada.Strings.Unbounded.Equal_Case_Insensitive’ '(A.4.10)'
  
       Provides case-insensitive comparisons of unbounded strings
  
! ‘Ada.Strings.Unbounded.Hash’ '(A.4.9)'
  
       This package provides a generic hash function for unbounded strings
  
! ‘Ada.Strings.Unbounded.Hash_Case_Insensitive’ '(A.4.9)'
  
       This package provides a generic hash function for unbounded strings
       that converts the string to be hashed to lower case.
  
! ‘Ada.Strings.Unbounded.Less_Case_Insensitive’ '(A.4.10)'
  
       This package provides a comparison function for unbounded strings
       that works in a case insensitive manner by converting to lower case
       before the comparison.
  
! ‘Ada.Strings.UTF_Encoding’ '(A.4.11)'
  
       This package provides basic definitions for dealing with
       UTF-encoded strings.
  
! ‘Ada.Strings.UTF_Encoding.Conversions’ '(A.4.11)'
  
       This package provides conversion functions for UTF-encoded strings.
  
! ‘Ada.Strings.UTF_Encoding.Strings’ '(A.4.11)'
  
! ‘Ada.Strings.UTF_Encoding.Wide_Strings’ '(A.4.11)'
  
! ‘Ada.Strings.UTF_Encoding.Wide_Wide_Strings’ '(A.4.11)'
  
       These packages provide facilities for handling UTF encodings for
       Strings, Wide_Strings and Wide_Wide_Strings.
  
! ‘Ada.Strings.Wide_Bounded’ '(A.4.7)'
  
! ‘Ada.Strings.Wide_Fixed’ '(A.4.7)'
  
! ‘Ada.Strings.Wide_Maps’ '(A.4.7)'
  
! ‘Ada.Strings.Wide_Unbounded’ '(A.4.7)'
  
       These packages provide analogous capabilities to the corresponding
       packages without ‘Wide_’ in the name, but operate with the types
       ‘Wide_String’ and ‘Wide_Character’ instead of ‘String’ and
       ‘Character’.  Versions of all the child packages are available.
  
! ‘Ada.Strings.Wide_Wide_Bounded’ '(A.4.7)'
  
! ‘Ada.Strings.Wide_Wide_Fixed’ '(A.4.7)'
  
! ‘Ada.Strings.Wide_Wide_Maps’ '(A.4.7)'
  
! ‘Ada.Strings.Wide_Wide_Unbounded’ '(A.4.7)'
  
       These packages provide analogous capabilities to the corresponding
       packages without ‘Wide_’ in the name, but operate with the types
       ‘Wide_Wide_String’ and ‘Wide_Wide_Character’ instead of ‘String’
       and ‘Character’.
  
! ‘Ada.Synchronous_Barriers’ '(D.10.1)'
  
       This package provides facilities for synchronizing tasks at a low
       level with barriers.
  
! ‘Ada.Synchronous_Task_Control’ '(D.10)'
  
       This package provides some standard facilities for controlling task
       communication in a synchronous manner.
  
! ‘Ada.Synchronous_Task_Control.EDF’ '(D.10)'
  
       Not implemented in GNAT.
  
*************** comments explaining why the unit is not
*** 17917,17937 ****
       This package contains definitions for manipulation of the tags of
       tagged values.
  
! ‘Ada.Tags.Generic_Dispatching_Constructor’ ‘(3.9)’
  
       This package provides a way of constructing tagged class-wide
       values given only the tag value.
  
! ‘Ada.Task_Attributes’ ‘(C.7.2)’
  
       This package provides the capability of associating arbitrary
       task-specific data with separate tasks.
  
! ‘Ada.Task_Identification’ ‘(C.7.1)’
  
       This package provides capabilities for task identification.
  
! ‘Ada.Task_Termination’ ‘(C.7.3)’
  
       This package provides control over task termination.
  
--- 17917,17937 ----
       This package contains definitions for manipulation of the tags of
       tagged values.
  
! ‘Ada.Tags.Generic_Dispatching_Constructor’ '(3.9)'
  
       This package provides a way of constructing tagged class-wide
       values given only the tag value.
  
! ‘Ada.Task_Attributes’ '(C.7.2)'
  
       This package provides the capability of associating arbitrary
       task-specific data with separate tasks.
  
! ‘Ada.Task_Identification’ '(C.7.1)'
  
       This package provides capabilities for task identification.
  
! ‘Ada.Task_Termination’ '(C.7.3)'
  
       This package provides control over task termination.
  
*************** comments explaining why the unit is not
*** 18083,18094 ****
       with pointers to unconstrained objects, since the bounds
       information cannot be handled correctly in this case.
  
! ‘Ada.Unchecked_Deallocation’ ‘(13.11.2)’
  
       This generic package allows explicit freeing of storage previously
       allocated by use of an allocator.
  
! ‘Ada.Wide_Text_IO’ ‘(A.11)’
  
       This package is similar to ‘Ada.Text_IO’, except that the external
       file supports wide character representations, and the internal
--- 18083,18094 ----
       with pointers to unconstrained objects, since the bounds
       information cannot be handled correctly in this case.
  
! ‘Ada.Unchecked_Deallocation’ '(13.11.2)'
  
       This generic package allows explicit freeing of storage previously
       allocated by use of an allocator.
  
! ‘Ada.Wide_Text_IO’ '(A.11)'
  
       This package is similar to ‘Ada.Text_IO’, except that the external
       file supports wide character representations, and the internal
*************** comments explaining why the unit is not
*** 18096,18102 ****
       and ‘String’.  The corresponding set of nested packages and child
       packages are defined.
  
! ‘Ada.Wide_Wide_Text_IO’ ‘(A.11)’
  
       This package is similar to ‘Ada.Text_IO’, except that the external
       file supports wide character representations, and the internal
--- 18096,18102 ----
       and ‘String’.  The corresponding set of nested packages and child
       packages are defined.
  
! ‘Ada.Wide_Wide_Text_IO’ '(A.11)'
  
       This package is similar to ‘Ada.Text_IO’, except that the external
       file supports wide character representations, and the internal
*************** Character      Encoding
*** 18543,18564 ****
                 
  ----------------------------------------
                 
! ‘h’            Hex ESC encoding
                 
                 
! ‘u’            Upper half encoding
                 
                 
! ‘s’            Shift-JIS encoding
                 
                 
! ‘e’            EUC Encoding
                 
                 
! ‘8’            UTF-8 encoding
                 
                 
! ‘b’            Brackets encoding
                 
  
  The encoding methods match those that can be used in a source program,
--- 18543,18564 ----
                 
  ----------------------------------------
                 
! 'h'            Hex ESC encoding
                 
                 
! 'u'            Upper half encoding
                 
                 
! 's'            Shift-JIS encoding
                 
                 
! 'e'            EUC Encoding
                 
                 
! '8'            UTF-8 encoding
                 
                 
! 'b'            Brackets encoding
                 
  
  The encoding methods match those that can be used in a source program,
*************** for which no WCEM parameter is given in
*** 18571,18577 ****
  character encoding specified for the main program (the default being
  brackets encoding if no coding method was specified with -gnatW).
  
! ‘Hex Coding’
  
       In this encoding, a wide character is represented by a five
       character sequence:
--- 18571,18577 ----
  character encoding specified for the main program (the default being
  brackets encoding if no coding method was specified with -gnatW).
  
! 'Hex Coding'
  
       In this encoding, a wide character is represented by a five
       character sequence:
*************** brackets encoding if no coding method wa
*** 18584,18590 ****
       This scheme is compatible with use of the full ‘Wide_Character’
       set.
  
! ‘Upper Half Coding’
  
       The wide character with encoding 16#abcd#, where the upper bit is
       on (i.e., a is in the range 8-F) is represented as two bytes 16#ab#
--- 18584,18590 ----
       This scheme is compatible with use of the full ‘Wide_Character’
       set.
  
! 'Upper Half Coding'
  
       The wide character with encoding 16#abcd#, where the upper bit is
       on (i.e., a is in the range 8-F) is represented as two bytes 16#ab#
*************** brackets encoding if no coding method wa
*** 18593,18599 ****
       method can be also used for shift-JIS or EUC where the internal
       coding matches the external coding.
  
! ‘Shift JIS Coding’
  
       A wide character is represented by a two character sequence 16#ab#
       and 16#cd#, with the restrictions described for upper half encoding
--- 18593,18599 ----
       method can be also used for shift-JIS or EUC where the internal
       coding matches the external coding.
  
! 'Shift JIS Coding'
  
       A wide character is represented by a two character sequence 16#ab#
       and 16#cd#, with the restrictions described for upper half encoding
*************** brackets encoding if no coding method wa
*** 18602,18608 ****
       Shift-JIS conversion.  Only characters defined in the JIS code set
       table can be used with this encoding method.
  
! ‘EUC Coding’
  
       A wide character is represented by a two character sequence 16#ab#
       and 16#cd#, with both characters being in the upper half.  The
--- 18602,18608 ----
       Shift-JIS conversion.  Only characters defined in the JIS code set
       table can be used with this encoding method.
  
! 'EUC Coding'
  
       A wide character is represented by a two character sequence 16#ab#
       and 16#cd#, with both characters being in the upper half.  The
*************** brackets encoding if no coding method wa
*** 18610,18616 ****
       according to the EUC encoding algorithm.  Only characters defined
       in the JIS code set table can be used with this encoding method.
  
! ‘UTF-8 Coding’
  
       A wide character is represented using UCS Transformation Format 8
       (UTF-8) as defined in Annex R of ISO 10646-1/Am.2.  Depending on
--- 18610,18616 ----
       according to the EUC encoding algorithm.  Only characters defined
       in the JIS code set table can be used with this encoding method.
  
! 'UTF-8 Coding'
  
       A wide character is represented using UCS Transformation Format 8
       (UTF-8) as defined in Annex R of ISO 10646-1/Am.2.  Depending on
*************** brackets encoding if no coding method wa
*** 18630,18636 ****
       of four or more bytes length will raise a Constraint_Error, as will
       all invalid UTF-8 sequences.)
  
! ‘Brackets Coding’
  
       In this encoding, a wide character is represented by the following
       eight character sequence:
--- 18630,18636 ----
       of four or more bytes length will raise a Constraint_Error, as will
       all invalid UTF-8 sequences.)
  
! 'Brackets Coding'
  
       In this encoding, a wide character is represented by the following
       eight character sequence:
*************** Character      Encoding
*** 18746,18767 ****
                 
  ----------------------------------------
                 
! ‘h’            Hex ESC encoding
                 
                 
! ‘u’            Upper half encoding
                 
                 
! ‘s’            Shift-JIS encoding
                 
                 
! ‘e’            EUC Encoding
                 
                 
! ‘8’            UTF-8 encoding
                 
                 
! ‘b’            Brackets encoding
                 
  
  The encoding methods match those that can be used in a source program,
--- 18746,18767 ----
                 
  ----------------------------------------
                 
! 'h'            Hex ESC encoding
                 
                 
! 'u'            Upper half encoding
                 
                 
! 's'            Shift-JIS encoding
                 
                 
! 'e'            EUC Encoding
                 
                 
! '8'            UTF-8 encoding
                 
                 
! 'b'            Brackets encoding
                 
  
  The encoding methods match those that can be used in a source program,
*************** for which no WCEM parameter is given in
*** 18774,18780 ****
  character encoding specified for the main program (the default being
  brackets encoding if no coding method was specified with -gnatW).
  
! ‘UTF-8 Coding’
  
       A wide character is represented using UCS Transformation Format 8
       (UTF-8) as defined in Annex R of ISO 10646-1/Am.2.  Depending on
--- 18774,18780 ----
  character encoding specified for the main program (the default being
  brackets encoding if no coding method was specified with -gnatW).
  
! 'UTF-8 Coding'
  
       A wide character is represented using UCS Transformation Format 8
       (UTF-8) as defined in Annex R of ISO 10646-1/Am.2.  Depending on
*************** brackets encoding if no coding method wa
*** 18792,18798 ****
       other wide characters are represented as sequences of upper-half
       characters.
  
! ‘Brackets Coding’
  
       In this encoding, a wide wide character is represented by the
       following eight character sequence if is in wide character range
--- 18792,18798 ----
       other wide characters are represented as sequences of upper-half
       characters.
  
! 'Brackets Coding'
  
       In this encoding, a wide wide character is represented by the
       following eight character sequence if is in wide character range
*************** In the absence of a ‘encoding=xxx’ f
*** 18981,18991 ****
  controlled by the ‘GNAT_CODE_PAGE’ environment variable.  And if not set
  ‘utf8’ is assumed.
  
! ‘CP_ACP’
  
       The current system Windows ANSI code page.
  
! ‘CP_UTF8’
  
       UTF-8 encoding
  
--- 18981,18991 ----
  controlled by the ‘GNAT_CODE_PAGE’ environment variable.  And if not set
  ‘utf8’ is assumed.
  
! 'CP_ACP'
  
       The current system Windows ANSI code page.
  
! 'CP_UTF8'
  
       UTF-8 encoding
  
*************** if not set ‘TEXT’ is assumed.
*** 19005,19023 ****
  
  The possible values are those supported on Windows:
  
! ‘TEXT’
  
       Translated text mode
  
! ‘WTEXT’
  
       Translated unicode encoding
  
! ‘U16TEXT’
  
       Unicode 16-bit encoding
  
! ‘U8TEXT’
  
       Unicode 8-bit encoding
  
--- 19005,19023 ----
  
  The possible values are those supported on Windows:
  
! 'TEXT'
  
       Translated text mode
  
! 'WTEXT'
  
       Translated unicode encoding
  
! 'U16TEXT'
  
       Unicode 16-bit encoding
  
! 'U8TEXT'
  
       Unicode 8-bit encoding
  
*************** shown in the following table:
*** 19036,19042 ****
  
  ----------------------------------------------------------------------------
                                                       
!                                  ‘OPEN’              ‘CREATE’
                                                       
                                                       
  Append_File                      “r+”                “w+”
--- 19036,19042 ----
  
  ----------------------------------------------------------------------------
                                                       
!                                  'OPEN'              'CREATE'
                                                       
                                                       
  Append_File                      “r+”                “w+”
*************** File: gnat_rm.info,  Node: GNAT CRC32 g-
*** 19991,19998 ****
  ==================================
  
  This package implements the CRC-32 algorithm.  For a full description of
! this algorithm see ‘Computation of Cyclic Redundancy Checks via Table
! Look-Up’, ‘Communications of the ACM’, Vol.  31 No.  8, pp.  1008-1013,
  Aug.  1988.  Sarwate, D.V.
  
  
--- 19991,19998 ----
  ==================================
  
  This package implements the CRC-32 algorithm.  For a full description of
! this algorithm see 'Computation of Cyclic Redundancy Checks via Table
! Look-Up', ‘Communications of the ACM’, Vol.  31 No.  8, pp.  1008-1013,
  Aug.  1988.  Sarwate, D.V.
  
  
*************** Ada 95, Ada 2005, and Ada 2012 define a
*** 21255,21284 ****
  Annexes, which are not required in all implementations.  However, as
  described in this chapter, GNAT implements all of these annexes:
  
! ‘Systems Programming (Annex C)’
  
       The Systems Programming Annex is fully implemented.
  
! ‘Real-Time Systems (Annex D)’
  
       The Real-Time Systems Annex is fully implemented.
  
! ‘Distributed Systems (Annex E)’
  
       Stub generation is fully implemented in the GNAT compiler.  In
       addition, a complete compatible PCS is available as part of the
       GLADE system, a separate product.  When the two products are used
       in conjunction, this annex is fully implemented.
  
! ‘Information Systems (Annex F)’
  
       The Information Systems annex is fully implemented.
  
! ‘Numerics (Annex G)’
  
       The Numerics Annex is fully implemented.
  
! ‘Safety and Security / High-Integrity Systems (Annex H)’
  
       The Safety and Security Annex (termed the High-Integrity Systems
       Annex in Ada 2005) is fully implemented.
--- 21255,21284 ----
  Annexes, which are not required in all implementations.  However, as
  described in this chapter, GNAT implements all of these annexes:
  
! 'Systems Programming (Annex C)'
  
       The Systems Programming Annex is fully implemented.
  
! 'Real-Time Systems (Annex D)'
  
       The Real-Time Systems Annex is fully implemented.
  
! 'Distributed Systems (Annex E)'
  
       Stub generation is fully implemented in the GNAT compiler.  In
       addition, a complete compatible PCS is available as part of the
       GLADE system, a separate product.  When the two products are used
       in conjunction, this annex is fully implemented.
  
! 'Information Systems (Annex F)'
  
       The Information Systems annex is fully implemented.
  
! 'Numerics (Annex G)'
  
       The Numerics Annex is fully implemented.
  
! 'Safety and Security / High-Integrity Systems (Annex H)'
  
       The Safety and Security Annex (termed the High-Integrity Systems
       Annex in Ada 2005) is fully implemented.
*************** provided for GNU C’s symbolic names fo
*** 21378,21384 ****
  If there are no input operands, this argument may either be omitted, or
  explicitly given as ‘No_Input_Operands’.  The fourth argument, not
  present in the above example, is a list of register names, called the
! ‘clobber’ argument.  This argument, if given, must be a static string
  expression, and is a space or comma separated list of names of registers
  that must be considered destroyed as a result of the ‘Asm’ call.  If
  this argument is the null string (the default value), then the code
--- 21378,21384 ----
  If there are no input operands, this argument may either be omitted, or
  explicitly given as ‘No_Input_Operands’.  The fourth argument, not
  present in the above example, is a list of register names, called the
! 'clobber' argument.  This argument, if given, must be a static string
  expression, and is a space or comma separated list of names of registers
  that must be considered destroyed as a result of the ‘Asm’ call.  If
  this argument is the null string (the default value), then the code
*************** addition to registers, the special clobb
*** 21387,21393 ****
  described in the GNU C docs are both supported.
  
  The fifth argument, not present in the above example, called the
! ‘volatile’ argument, is by default ‘False’.  It can be set to the
  literal value ‘True’ to indicate to the code generator that all
  optimizations with respect to the instruction specified should be
  suppressed, and in particular an instruction that has outputs will still
--- 21387,21393 ----
  described in the GNU C docs are both supported.
  
  The fifth argument, not present in the above example, called the
! 'volatile' argument, is by default ‘False’.  It can be set to the
  literal value ‘True’ to indicate to the code generator that all
  optimizations with respect to the instruction specified should be
  suppressed, and in particular an instruction that has outputs will still
*************** respecting the scheduling semantics spec
*** 21535,21547 ****
  For instance the Annex D requirement for the ‘FIFO_Within_Priorities’
  scheduling policy states:
  
!      ‘When the active priority of a ready task that is not running
       changes, or the setting of its base priority takes effect, the task
       is removed from the ready queue for its old active priority and is
       added at the tail of the ready queue for its new active priority,
       except in the case where the active priority is lowered due to the
       loss of inherited priority, in which case the task is added at the
!      head of the ready queue for its new active priority.’
  
  While most kernels do put tasks at the end of the priority queue when a
  task changes its priority, (which respects the main
--- 21535,21547 ----
  For instance the Annex D requirement for the ‘FIFO_Within_Priorities’
  scheduling policy states:
  
!      'When the active priority of a ready task that is not running
       changes, or the setting of its base priority takes effect, the task
       is removed from the ready queue for its old active priority and is
       added at the tail of the ready queue for its new active priority,
       except in the case where the active priority is lowered due to the
       loss of inherited priority, in which case the task is added at the
!      head of the ready queue for its new active priority.'
  
  While most kernels do put tasks at the end of the priority queue when a
  task changes its priority, (which respects the main
*************** application using the features in Annex
*** 21607,21613 ****
  However, the implementation approach used by GNAT provides for more
  extensive usage as follows:
  
! ‘Communication between separate programs’
  
       This allows separate programs to access the data in passive
       partitions, using protected objects for synchronization where
--- 21607,21613 ----
  However, the implementation approach used by GNAT provides for more
  extensive usage as follows:
  
! 'Communication between separate programs'
  
       This allows separate programs to access the data in passive
       partitions, using protected objects for synchronization where
*************** extensive usage as follows:
*** 21617,21623 ****
       different endianness) to communicate via the data in a passive
       partition.
  
! ‘Persistence between program runs’
  
       The data in a passive package can persist from one run of a program
       to another, so that a later program sees the final values stored by
--- 21617,21623 ----
       different endianness) to communicate via the data in a passive
       partition.
  
! 'Persistence between program runs'
  
       The data in a passive package can persist from one run of a program
       to another, so that a later program sees the final values stored by
*************** constraint:
*** 21845,21851 ****
  
       Word : Rec;
  
! Such an object is said to be ‘unconstrained’.  The discriminant of the
  object can be modified by a full assignment to the object, as long as it
  preserves the relation between the value of the discriminant, and the
  value of the components that depend on it:
--- 21845,21851 ----
  
       Word : Rec;
  
! Such an object is said to be 'unconstrained'.  The discriminant of the
  object can be modified by a full assignment to the object, as long as it
  preserves the relation between the value of the discriminant, and the
  value of the components that depend on it:
*************** proper approach is to declare an index t
*** 21889,21895 ****
  that unconstrained objects are not too large.
  
  One final wrinkle: if the object is declared to be ‘aliased’, or if it
! is created in the heap by means of an allocator, then it is ‘not’
  unconstrained: it is constrained by the default values of the
  discriminants, and those values cannot be modified by full assignment.
  This is because in the presence of aliasing all views of the object
--- 21889,21895 ----
  that unconstrained objects are not too large.
  
  One final wrinkle: if the object is declared to be ‘aliased’, or if it
! is created in the heap by means of an allocator, then it is 'not'
  unconstrained: it is constrained by the default values of the
  discriminants, and those values cannot be modified by full assignment.
  This is because in the presence of aliasing all views of the object
*************** default).
*** 21935,21949 ****
  
  Strict conformance to the Ada Reference Manual can be achieved by adding
  two compiler options for dynamic checks for access-before-elaboration on
! subprogram calls and generic instantiations (‘-gnatE’), and stack
! overflow checking (‘-fstack-check’).
  
  Note that the result of a floating point arithmetic operation in
  overflow and invalid situations, when the ‘Machine_Overflows’ attribute
  of the result type is ‘False’, is to generate IEEE NaN and infinite
  values.  This is the case for machines compliant with the IEEE
  floating-point standard, but on machines that are not fully compliant
! with this standard, such as Alpha, the ‘-mieee’ compiler flag must be
  used for achieving IEEE confirming behavior (although at the cost of a
  significant performance penalty), so infinite and NaN values are
  properly generated.
--- 21935,21949 ----
  
  Strict conformance to the Ada Reference Manual can be achieved by adding
  two compiler options for dynamic checks for access-before-elaboration on
! subprogram calls and generic instantiations ('-gnatE'), and stack
! overflow checking ('-fstack-check').
  
  Note that the result of a floating point arithmetic operation in
  overflow and invalid situations, when the ‘Machine_Overflows’ attribute
  of the result type is ‘False’, is to generate IEEE NaN and infinite
  values.  This is the case for machines compliant with the IEEE
  floating-point standard, but on machines that are not fully compliant
! with this standard, such as Alpha, the '-mieee' compiler flag must be
  used for achieving IEEE confirming behavior (although at the cost of a
  significant performance penalty), so infinite and NaN values are
  properly generated.
*************** File: gnat_rm.info,  Node: Implementatio
*** 21956,21962 ****
  
  This chapter contains a complete list of Ada 2012 features that have
  been implemented.  Generally, these features are only available if the
! ‘-gnat12’ (Ada 2012 features enabled) option is set, which is the
  default behavior, or if the configuration pragma ‘Ada_2012’ is used.
  
  However, new pragmas, attributes, and restrictions are unconditionally
--- 21956,21962 ----
  
  This chapter contains a complete list of Ada 2012 features that have
  been implemented.  Generally, these features are only available if the
! '-gnat12' (Ada 2012 features enabled) option is set, which is the
  default behavior, or if the configuration pragma ‘Ada_2012’ is used.
  
  However, new pragmas, attributes, and restrictions are unconditionally
*************** the RM, the earliest is used.
*** 21981,21987 ****
  A complete description of the AIs may be found in
  ‘http://www.ada-auth.org/ai05-summary.html’.
  
!    * ‘AI-0176 Quantified expressions (2010-09-29)’
  
       Both universally and existentially quantified expressions are
       implemented.  They use the new syntax for iterators proposed in
--- 21981,21987 ----
  A complete description of the AIs may be found in
  ‘http://www.ada-auth.org/ai05-summary.html’.
  
!    * 'AI-0176 Quantified expressions (2010-09-29)'
  
       Both universally and existentially quantified expressions are
       implemented.  They use the new syntax for iterators proposed in
*************** A complete description of the AIs may be
*** 21989,22005 ****
  
       RM References: 1.01.04 (12) 2.09 (2/2) 4.04 (7) 4.05.09 (0)
  
!    * ‘AI-0079 Allow other_format characters in source (2010-07-10)’
  
!      Wide characters in the unicode category ‘other_format’ are now
       allowed in source programs between tokens, but not within a token
       such as an identifier.
  
       RM References: 2.01 (4/2) 2.02 (7)
  
!    * ‘AI-0091 Do not allow other_format in identifiers (0000-00-00)’
  
!      Wide characters in the unicode category ‘other_format’ are not
       permitted within an identifier, since this can be a security
       problem.  The error message for this case has been improved to be
       more specific, but GNAT has never allowed such characters to appear
--- 21989,22005 ----
  
       RM References: 1.01.04 (12) 2.09 (2/2) 4.04 (7) 4.05.09 (0)
  
!    * 'AI-0079 Allow other_format characters in source (2010-07-10)'
  
!      Wide characters in the unicode category 'other_format' are now
       allowed in source programs between tokens, but not within a token
       such as an identifier.
  
       RM References: 2.01 (4/2) 2.02 (7)
  
!    * 'AI-0091 Do not allow other_format in identifiers (0000-00-00)'
  
!      Wide characters in the unicode category 'other_format' are not
       permitted within an identifier, since this can be a security
       problem.  The error message for this case has been improved to be
       more specific, but GNAT has never allowed such characters to appear
*************** A complete description of the AIs may be
*** 22008,22014 ****
       RM References: 2.03 (3.1/2) 2.03 (4/2) 2.03 (5/2) 2.03 (5.1/2) 2.03
       (5.2/2) 2.03 (5.3/2) 2.09 (2/2)
  
!    * ‘AI-0100 Placement of pragmas (2010-07-01)’
  
       This AI is an earlier version of AI-163.  It simplifies the rules
       for legal placement of pragmas.  In the case of lists that allow
--- 22008,22014 ----
       RM References: 2.03 (3.1/2) 2.03 (4/2) 2.03 (5/2) 2.03 (5.1/2) 2.03
       (5.2/2) 2.03 (5.3/2) 2.09 (2/2)
  
!    * 'AI-0100 Placement of pragmas (2010-07-01)'
  
       This AI is an earlier version of AI-163.  It simplifies the rules
       for legal placement of pragmas.  In the case of lists that allow
*************** A complete description of the AIs may be
*** 22017,22023 ****
  
       RM References: 2.08 (7)
  
!    * ‘AI-0163 Pragmas in place of null (2010-07-01)’
  
       A statement sequence may be composed entirely of pragmas.  It is no
       longer necessary to add a dummy ‘null’ statement to make the
--- 22017,22023 ----
  
       RM References: 2.08 (7)
  
!    * 'AI-0163 Pragmas in place of null (2010-07-01)'
  
       A statement sequence may be composed entirely of pragmas.  It is no
       longer necessary to add a dummy ‘null’ statement to make the
*************** A complete description of the AIs may be
*** 22025,22038 ****
  
       RM References: 2.08 (7) 2.08 (16)
  
!    * ‘AI-0080 ‘View of’ not needed if clear from context (0000-00-00)’
  
       This is an editorial change only, described as non-testable in the
       AI.
  
       RM References: 3.01 (7)
  
!    * ‘AI-0183 Aspect specifications (2010-08-16)’
  
       Aspect specifications have been fully implemented except for pre
       and post- conditions, and type invariants, which have their own
--- 22025,22038 ----
  
       RM References: 2.08 (7) 2.08 (16)
  
!    * 'AI-0080 ‘View of’ not needed if clear from context (0000-00-00)'
  
       This is an editorial change only, described as non-testable in the
       AI.
  
       RM References: 3.01 (7)
  
!    * 'AI-0183 Aspect specifications (2010-08-16)'
  
       Aspect specifications have been fully implemented except for pre
       and post- conditions, and type invariants, which have their own
*************** Supported Aspect
*** 22169,22175 ****
       (2.1/2) 12.06 (2.2/2) 12.07 (2) 13.01 (0.1/2) 13.03 (5/1) 13.03.01
       (0)
  
!    * ‘AI-0128 Inequality is a primitive operation (0000-00-00)’
  
       If an equality operator (“=”) is declared for a type, then the
       implicitly declared inequality operator (“/=”) is a primitive
--- 22169,22175 ----
       (2.1/2) 12.06 (2.2/2) 12.07 (2) 13.01 (0.1/2) 13.03 (5/1) 13.03.01
       (0)
  
!    * 'AI-0128 Inequality is a primitive operation (0000-00-00)'
  
       If an equality operator (“=”) is declared for a type, then the
       implicitly declared inequality operator (“/=”) is a primitive
*************** Supported Aspect
*** 22179,22185 ****
  
       RM References: 3.02.03 (6) 6.06 (6)
  
!    * ‘AI-0003 Qualified expressions as names (2010-07-11)’
  
       In Ada 2012, a qualified expression is considered to be
       syntactically a name, meaning that constructs such as ‘A'(F(X)).B’
--- 22179,22185 ----
  
       RM References: 3.02.03 (6) 6.06 (6)
  
!    * 'AI-0003 Qualified expressions as names (2010-07-11)'
  
       In Ada 2012, a qualified expression is considered to be
       syntactically a name, meaning that constructs such as ‘A'(F(X)).B’
*************** Supported Aspect
*** 22189,22195 ****
       RM References: 3.03 (11) 3.03 (21) 4.01 (2) 4.04 (7) 4.07 (3) 5.04
       (7)
  
!    * ‘AI-0120 Constant instance of protected object (0000-00-00)’
  
       This is an RM editorial change only.  The section that lists
       objects that are constant failed to include the current instance of
--- 22189,22195 ----
       RM References: 3.03 (11) 3.03 (21) 4.01 (2) 4.04 (7) 4.07 (3) 5.04
       (7)
  
!    * 'AI-0120 Constant instance of protected object (0000-00-00)'
  
       This is an RM editorial change only.  The section that lists
       objects that are constant failed to include the current instance of
*************** Supported Aspect
*** 22198,22204 ****
  
       RM References: 3.03 (21)
  
!    * ‘AI-0008 General access to constrained objects (0000-00-00)’
  
       The wording in the RM implied that if you have a general access to
       a constrained object, it could be used to modify the discriminants.
--- 22198,22204 ----
  
       RM References: 3.03 (21)
  
!    * 'AI-0008 General access to constrained objects (0000-00-00)'
  
       The wording in the RM implied that if you have a general access to
       a constrained object, it could be used to modify the discriminants.
*************** Supported Aspect
*** 22208,22221 ****
       RM References: 3.03 (23) 3.10.02 (26/2) 4.01 (9) 6.04.01 (17)
       8.05.01 (5/2)
  
!    * ‘AI-0093 Additional rules use immutably limited (0000-00-00)’
  
       This is an editorial change only, to make more widespread use of
       the Ada 2012 ‘immutably limited’.
  
       RM References: 3.03 (23.4/3)
  
!    * ‘AI-0096 Deriving from formal private types (2010-07-20)’
  
       In general it is illegal for a type derived from a formal limited
       type to be nonlimited.  This AI makes an exception to this rule:
--- 22208,22221 ----
       RM References: 3.03 (23) 3.10.02 (26/2) 4.01 (9) 6.04.01 (17)
       8.05.01 (5/2)
  
!    * 'AI-0093 Additional rules use immutably limited (0000-00-00)'
  
       This is an editorial change only, to make more widespread use of
       the Ada 2012 ‘immutably limited’.
  
       RM References: 3.03 (23.4/3)
  
!    * 'AI-0096 Deriving from formal private types (2010-07-20)'
  
       In general it is illegal for a type derived from a formal limited
       type to be nonlimited.  This AI makes an exception to this rule:
*************** Supported Aspect
*** 22226,22232 ****
  
       RM References: 3.04 (5.1/2) 6.02 (7)
  
!    * ‘AI-0181 Soft hyphen is a non-graphic character (2010-07-23)’
  
       From Ada 2005 on, soft hyphen is considered a non-graphic
       character, which means that it has a special name (‘SOFT_HYPHEN’)
--- 22226,22232 ----
  
       RM References: 3.04 (5.1/2) 6.02 (7)
  
!    * 'AI-0181 Soft hyphen is a non-graphic character (2010-07-23)'
  
       From Ada 2005 on, soft hyphen is considered a non-graphic
       character, which means that it has a special name (‘SOFT_HYPHEN’)
*************** Supported Aspect
*** 22237,22243 ****
  
       RM References: 3.05.02 (2/2) A.01 (35/2) A.03.03 (21)
  
!    * ‘AI-0182 Additional forms for’ ‘Character'Value’ ‘(0000-00-00)’
  
       This AI allows ‘Character'Value’ to accept the string ‘'?'’ where
       ‘?’ is any character including non-graphic control characters.
--- 22237,22243 ----
  
       RM References: 3.05.02 (2/2) A.01 (35/2) A.03.03 (21)
  
!    * 'AI-0182 Additional forms for' ‘Character'Value’ '(0000-00-00)'
  
       This AI allows ‘Character'Value’ to accept the string ‘'?'’ where
       ‘?’ is any character including non-graphic control characters.
*************** Supported Aspect
*** 22248,22254 ****
  
       RM References: 3.05 (56/2)
  
!    * ‘AI-0214 Defaulted discriminants for limited tagged (2010-10-01)’
  
       Ada 2012 relaxes the restriction that forbids discriminants of
       tagged types to have default expressions by allowing them when the
--- 22248,22254 ----
  
       RM References: 3.05 (56/2)
  
!    * 'AI-0214 Defaulted discriminants for limited tagged (2010-10-01)'
  
       Ada 2012 relaxes the restriction that forbids discriminants of
       tagged types to have default expressions by allowing them when the
*************** Supported Aspect
*** 22257,22263 ****
  
       RM References: 3.07 (9.1/2) 3.07.02 (3)
  
!    * ‘AI-0102 Some implicit conversions are illegal (0000-00-00)’
  
       It is illegal to assign an anonymous access constant to an
       anonymous access variable.  The RM did not have a clear rule to
--- 22257,22263 ----
  
       RM References: 3.07 (9.1/2) 3.07.02 (3)
  
!    * 'AI-0102 Some implicit conversions are illegal (0000-00-00)'
  
       It is illegal to assign an anonymous access constant to an
       anonymous access variable.  The RM did not have a clear rule to
*************** Supported Aspect
*** 22266,22272 ****
  
       RM References: 3.07 (16) 3.07.01 (9) 6.04.01 (6) 8.06 (27/2)
  
!    * ‘AI-0158 Generalizing membership tests (2010-09-16)’
  
       This AI extends the syntax of membership tests to simplify complex
       conditions that can be expressed as membership in a subset of
--- 22266,22272 ----
  
       RM References: 3.07 (16) 3.07.01 (9) 6.04.01 (6) 8.06 (27/2)
  
!    * 'AI-0158 Generalizing membership tests (2010-09-16)'
  
       This AI extends the syntax of membership tests to simplify complex
       conditions that can be expressed as membership in a subset of
*************** Supported Aspect
*** 22276,22289 ****
       RM References: 3.08.01 (5) 4.04 (3) 4.05.02 (3) 4.05.02 (5) 4.05.02
       (27)
  
!    * ‘AI-0173 Testing if tags represent abstract types (2010-07-03)’
  
       The function ‘Ada.Tags.Type_Is_Abstract’ returns ‘True’ if invoked
       with the tag of an abstract type, and ‘False’ otherwise.
  
       RM References: 3.09 (7.4/2) 3.09 (12.4/2)
  
!    * ‘AI-0076 function with controlling result (0000-00-00)’
  
       This is an editorial change only.  The RM defines calls with
       controlling results, but uses the term ‘function with controlling
--- 22276,22289 ----
       RM References: 3.08.01 (5) 4.04 (3) 4.05.02 (3) 4.05.02 (5) 4.05.02
       (27)
  
!    * 'AI-0173 Testing if tags represent abstract types (2010-07-03)'
  
       The function ‘Ada.Tags.Type_Is_Abstract’ returns ‘True’ if invoked
       with the tag of an abstract type, and ‘False’ otherwise.
  
       RM References: 3.09 (7.4/2) 3.09 (12.4/2)
  
!    * 'AI-0076 function with controlling result (0000-00-00)'
  
       This is an editorial change only.  The RM defines calls with
       controlling results, but uses the term ‘function with controlling
*************** Supported Aspect
*** 22291,22297 ****
  
       RM References: 3.09.02 (2/2)
  
!    * ‘AI-0126 Dispatching with no declared operation (0000-00-00)’
  
       This AI clarifies dispatching rules, and simply confirms that
       dispatching executes the operation of the parent type when there is
--- 22291,22297 ----
  
       RM References: 3.09.02 (2/2)
  
!    * 'AI-0126 Dispatching with no declared operation (0000-00-00)'
  
       This AI clarifies dispatching rules, and simply confirms that
       dispatching executes the operation of the parent type when there is
*************** Supported Aspect
*** 22300,22306 ****
  
       RM References: 3.09.02 (20/2) 3.09.02 (20.1/2) 3.09.02 (20.2/2)
  
!    * ‘AI-0097 Treatment of abstract null extension (2010-07-19)’
  
       The RM as written implied that in some cases it was possible to
       create an object of an abstract type, by having an abstract
--- 22300,22306 ----
  
       RM References: 3.09.02 (20/2) 3.09.02 (20.1/2) 3.09.02 (20.2/2)
  
!    * 'AI-0097 Treatment of abstract null extension (2010-07-19)'
  
       The RM as written implied that in some cases it was possible to
       create an object of an abstract type, by having an abstract
*************** Supported Aspect
*** 22310,22323 ****
  
       RM References: 3.09.03 (4/2)
  
!    * ‘AI-0203 Extended return cannot be abstract (0000-00-00)’
  
       A return_subtype_indication cannot denote an abstract subtype.
       GNAT has never permitted such usage.
  
       RM References: 3.09.03 (8/3)
  
!    * ‘AI-0198 Inheriting abstract operators (0000-00-00)’
  
       This AI resolves a conflict between two rules involving inherited
       abstract operations and predefined operators.  If a derived numeric
--- 22310,22323 ----
  
       RM References: 3.09.03 (4/2)
  
!    * 'AI-0203 Extended return cannot be abstract (0000-00-00)'
  
       A return_subtype_indication cannot denote an abstract subtype.
       GNAT has never permitted such usage.
  
       RM References: 3.09.03 (8/3)
  
!    * 'AI-0198 Inheriting abstract operators (0000-00-00)'
  
       This AI resolves a conflict between two rules involving inherited
       abstract operations and predefined operators.  If a derived numeric
*************** Supported Aspect
*** 22326,22332 ****
  
       RM References: 3.09.03 (4/3)
  
!    * ‘AI-0073 Functions returning abstract types (2010-07-10)’
  
       This AI covers a number of issues regarding returning abstract
       types.  In particular generic functions cannot have abstract result
--- 22326,22332 ----
  
       RM References: 3.09.03 (4/3)
  
!    * 'AI-0073 Functions returning abstract types (2010-07-10)'
  
       This AI covers a number of issues regarding returning abstract
       types.  In particular generic functions cannot have abstract result
*************** Supported Aspect
*** 22337,22343 ****
  
       RM References: 3.09.03 (8) 3.09.03 (10) 6.05 (8/2)
  
!    * ‘AI-0070 Elaboration of interface types (0000-00-00)’
  
       This is an editorial change only, there are no testable
       consequences short of checking for the absence of generated code
--- 22337,22343 ----
  
       RM References: 3.09.03 (8) 3.09.03 (10) 6.05 (8/2)
  
!    * 'AI-0070 Elaboration of interface types (0000-00-00)'
  
       This is an editorial change only, there are no testable
       consequences short of checking for the absence of generated code
*************** Supported Aspect
*** 22345,22351 ****
  
       RM References: 3.09.04 (18/2)
  
!    * ‘AI-0208 Characteristics of incomplete views (0000-00-00)’
  
       The wording in the Ada 2005 RM concerning characteristics of
       incomplete views was incorrect and implied that some programs
--- 22345,22351 ----
  
       RM References: 3.09.04 (18/2)
  
!    * 'AI-0208 Characteristics of incomplete views (0000-00-00)'
  
       The wording in the Ada 2005 RM concerning characteristics of
       incomplete views was incorrect and implied that some programs
*************** Supported Aspect
*** 22355,22361 ****
  
       RM References: 3.10.01 (2.4/2) 3.10.01 (2.6/2)
  
!    * ‘AI-0162 Incomplete type completed by partial view (2010-09-15)’
  
       Incomplete types are made more useful by allowing them to be
       completed by private types and private extensions.
--- 22355,22361 ----
  
       RM References: 3.10.01 (2.4/2) 3.10.01 (2.6/2)
  
!    * 'AI-0162 Incomplete type completed by partial view (2010-09-15)'
  
       Incomplete types are made more useful by allowing them to be
       completed by private types and private extensions.
*************** Supported Aspect
*** 22363,22369 ****
       RM References: 3.10.01 (2.5/2) 3.10.01 (2.6/2) 3.10.01 (3) 3.10.01
       (4/2)
  
!    * ‘AI-0098 Anonymous subprogram access restrictions (0000-00-00)’
  
       An unintentional omission in the RM implied some inconsistent
       restrictions on the use of anonymous access to subprogram values.
--- 22363,22369 ----
       RM References: 3.10.01 (2.5/2) 3.10.01 (2.6/2) 3.10.01 (3) 3.10.01
       (4/2)
  
!    * 'AI-0098 Anonymous subprogram access restrictions (0000-00-00)'
  
       An unintentional omission in the RM implied some inconsistent
       restrictions on the use of anonymous access to subprogram values.
*************** Supported Aspect
*** 22372,22378 ****
  
       RM References: 3.10.01 (6) 3.10.01 (9.2/2)
  
!    * ‘AI-0199 Aggregate with anonymous access components (2010-07-14)’
  
       A choice list in a record aggregate can include several components
       of (distinct) anonymous access types as long as they have matching
--- 22372,22378 ----
  
       RM References: 3.10.01 (6) 3.10.01 (9.2/2)
  
!    * 'AI-0199 Aggregate with anonymous access components (2010-07-14)'
  
       A choice list in a record aggregate can include several components
       of (distinct) anonymous access types as long as they have matching
*************** Supported Aspect
*** 22380,22386 ****
  
       RM References: 4.03.01 (16)
  
!    * ‘AI-0220 Needed components for aggregates (0000-00-00)’
  
       This AI addresses a wording problem in the RM that appears to
       permit some complex cases of aggregates with nonstatic
--- 22380,22386 ----
  
       RM References: 4.03.01 (16)
  
!    * 'AI-0220 Needed components for aggregates (0000-00-00)'
  
       This AI addresses a wording problem in the RM that appears to
       permit some complex cases of aggregates with nonstatic
*************** Supported Aspect
*** 22388,22394 ****
  
       RM References: 4.03.01 (17)
  
!    * ‘AI-0147 Conditional expressions (2009-03-29)’
  
       Conditional expressions are permitted.  The form of such an
       expression is:
--- 22388,22394 ----
  
       RM References: 4.03.01 (17)
  
!    * 'AI-0147 Conditional expressions (2009-03-29)'
  
       Conditional expressions are permitted.  The form of such an
       expression is:
*************** Supported Aspect
*** 22397,22410 ****
  
       The parentheses can be omitted in contexts where parentheses are
       present anyway, such as subprogram arguments and pragma arguments.
!      If the ‘else’ clause is omitted, ‘else’ ‘True’ is assumed; thus
!      ‘(if A then B)’ is a way to conveniently represent ‘(A implies B)’
       in standard logic.
  
       RM References: 4.03.03 (15) 4.04 (1) 4.04 (7) 4.05.07 (0) 4.07 (2)
       4.07 (3) 4.09 (12) 4.09 (33) 5.03 (3) 5.03 (4) 7.05 (2.1/2)
  
!    * ‘AI-0037 Out-of-range box associations in aggregate (0000-00-00)’
  
       This AI confirms that an association of the form ‘Indx => <>’ in an
       array aggregate must raise ‘Constraint_Error’ if ‘Indx’ is out of
--- 22397,22410 ----
  
       The parentheses can be omitted in contexts where parentheses are
       present anyway, such as subprogram arguments and pragma arguments.
!      If the 'else' clause is omitted, 'else' 'True' is assumed; thus
!      ‘(if A then B)’ is a way to conveniently represent '(A implies B)'
       in standard logic.
  
       RM References: 4.03.03 (15) 4.04 (1) 4.04 (7) 4.05.07 (0) 4.07 (2)
       4.07 (3) 4.09 (12) 4.09 (33) 5.03 (3) 5.03 (4) 7.05 (2.1/2)
  
!    * 'AI-0037 Out-of-range box associations in aggregate (0000-00-00)'
  
       This AI confirms that an association of the form ‘Indx => <>’ in an
       array aggregate must raise ‘Constraint_Error’ if ‘Indx’ is out of
*************** Supported Aspect
*** 22414,22420 ****
  
       RM References: 4.03.03 (29)
  
!    * ‘AI-0123 Composability of equality (2010-04-13)’
  
       Equality of untagged record composes, so that the predefined
       equality for a composite type that includes a component of some
--- 22414,22420 ----
  
       RM References: 4.03.03 (29)
  
!    * 'AI-0123 Composability of equality (2010-04-13)'
  
       Equality of untagged record composes, so that the predefined
       equality for a composite type that includes a component of some
*************** Supported Aspect
*** 22434,22440 ****
       RM References: 4.05.02 (9.7/2) 4.05.02 (14) 4.05.02 (15) 4.05.02
       (24) 8.05.04 (8)
  
!    * ‘AI-0088 The value of exponentiation (0000-00-00)’
  
       This AI clarifies the equivalence rule given for the dynamic
       semantics of exponentiation: the value of the operation can be
--- 22434,22440 ----
       RM References: 4.05.02 (9.7/2) 4.05.02 (14) 4.05.02 (15) 4.05.02
       (24) 8.05.04 (8)
  
!    * 'AI-0088 The value of exponentiation (0000-00-00)'
  
       This AI clarifies the equivalence rule given for the dynamic
       semantics of exponentiation: the value of the operation can be
*************** Supported Aspect
*** 22445,22451 ****
  
       RM References: 4.05.06 (11)
  
!    * ‘AI-0188 Case expressions (2010-01-09)’
  
       Case expressions are permitted.  This allows use of constructs such
       as:
--- 22445,22451 ----
  
       RM References: 4.05.06 (11)
  
!    * 'AI-0188 Case expressions (2010-01-09)'
  
       Case expressions are permitted.  This allows use of constructs such
       as:
*************** Supported Aspect
*** 22454,22468 ****
  
       RM References: 4.05.07 (0) 4.05.08 (0) 4.09 (12) 4.09 (33)
  
!    * ‘AI-0104 Null exclusion and uninitialized allocator (2010-07-15)’
  
       The assignment ‘Ptr := new not null Some_Ptr;’ will raise
       ‘Constraint_Error’ because the default value of the allocated
!      object is ‘null’.  This useless construct is illegal in Ada 2012.
  
       RM References: 4.08 (2)
  
!    * ‘AI-0157 Allocation/Deallocation from empty pool (2010-07-11)’
  
       Allocation and Deallocation from an empty storage pool (i.e.
       allocation or deallocation of a pointer for which a static storage
--- 22454,22468 ----
  
       RM References: 4.05.07 (0) 4.05.08 (0) 4.09 (12) 4.09 (33)
  
!    * 'AI-0104 Null exclusion and uninitialized allocator (2010-07-15)'
  
       The assignment ‘Ptr := new not null Some_Ptr;’ will raise
       ‘Constraint_Error’ because the default value of the allocated
!      object is 'null'.  This useless construct is illegal in Ada 2012.
  
       RM References: 4.08 (2)
  
!    * 'AI-0157 Allocation/Deallocation from empty pool (2010-07-11)'
  
       Allocation and Deallocation from an empty storage pool (i.e.
       allocation or deallocation of a pointer for which a static storage
*************** Supported Aspect
*** 22471,22477 ****
  
       RM References: 4.08 (5.3/2) 13.11.02 (4) 13.11.02 (17)
  
!    * ‘AI-0179 Statement not required after label (2010-04-10)’
  
       It is not necessary to have a statement following a label, so a
       label can appear at the end of a statement sequence without the
--- 22471,22477 ----
  
       RM References: 4.08 (5.3/2) 13.11.02 (4) 13.11.02 (17)
  
!    * 'AI-0179 Statement not required after label (2010-04-10)'
  
       It is not necessary to have a statement following a label, so a
       label can appear at the end of a statement sequence without the
*************** Supported Aspect
*** 22481,22487 ****
  
       RM References: 5.01 (2)
  
!    * ‘AI-0139-2 Syntactic sugar for iterators (2010-09-29)’
  
       The new syntax for iterating over arrays and containers is now
       implemented.  Iteration over containers is for now limited to
--- 22481,22487 ----
  
       RM References: 5.01 (2)
  
!    * 'AI-0139-2 Syntactic sugar for iterators (2010-09-29)'
  
       The new syntax for iterating over arrays and containers is now
       implemented.  Iteration over containers is for now limited to
*************** Supported Aspect
*** 22490,22496 ****
  
       RM References: 5.05
  
!    * ‘AI-0134 Profiles must match for full conformance (0000-00-00)’
  
       For full conformance, the profiles of
       anonymous-access-to-subprogram parameters must match.  GNAT has
--- 22490,22496 ----
  
       RM References: 5.05
  
!    * 'AI-0134 Profiles must match for full conformance (0000-00-00)'
  
       For full conformance, the profiles of
       anonymous-access-to-subprogram parameters must match.  GNAT has
*************** Supported Aspect
*** 22498,22504 ****
  
       RM References: 6.03.01 (18)
  
!    * ‘AI-0207 Mode conformance and access constant (0000-00-00)’
  
       This AI confirms that access_to_constant indication must match for
       mode conformance.  This was implemented in GNAT when the qualifier
--- 22498,22504 ----
  
       RM References: 6.03.01 (18)
  
!    * 'AI-0207 Mode conformance and access constant (0000-00-00)'
  
       This AI confirms that access_to_constant indication must match for
       mode conformance.  This was implemented in GNAT when the qualifier
*************** Supported Aspect
*** 22506,22519 ****
  
       RM References: 6.03.01 (16/2)
  
!    * ‘AI-0046 Null exclusion match for full conformance (2010-07-17)’
  
       For full conformance, in the case of access parameters, the null
       exclusion must match (either both or neither must have ‘not null’).
  
       RM References: 6.03.02 (18)
  
!    * ‘AI-0118 The association of parameter associations (0000-00-00)’
  
       This AI clarifies the rules for named associations in subprogram
       calls and generic instantiations.  The rules have been in place
--- 22506,22519 ----
  
       RM References: 6.03.01 (16/2)
  
!    * 'AI-0046 Null exclusion match for full conformance (2010-07-17)'
  
       For full conformance, in the case of access parameters, the null
       exclusion must match (either both or neither must have ‘not null’).
  
       RM References: 6.03.02 (18)
  
!    * 'AI-0118 The association of parameter associations (0000-00-00)'
  
       This AI clarifies the rules for named associations in subprogram
       calls and generic instantiations.  The rules have been in place
*************** Supported Aspect
*** 22521,22527 ****
  
       RM References: 6.04.01 (2) 12.03 (9)
  
!    * ‘AI-0196 Null exclusion tests for out parameters (0000-00-00)’
  
       Null exclusion checks are not made for ‘out’ parameters when
       evaluating the actual parameters.  GNAT has never generated these
--- 22521,22527 ----
  
       RM References: 6.04.01 (2) 12.03 (9)
  
!    * 'AI-0196 Null exclusion tests for out parameters (0000-00-00)'
  
       Null exclusion checks are not made for ‘out’ parameters when
       evaluating the actual parameters.  GNAT has never generated these
*************** Supported Aspect
*** 22529,22544 ****
  
       RM References: 6.04.01 (13)
  
!    * ‘AI-0015 Constant return objects (0000-00-00)’
  
!      The return object declared in an ‘extended_return_statement’ may be
       declared constant.  This was always intended, and GNAT has always
       allowed it.
  
       RM References: 6.05 (2.1/2) 3.03 (10/2) 3.03 (21) 6.05 (5/2) 6.05
       (5.7/2)
  
!    * ‘AI-0032 Extended return for class-wide functions (0000-00-00)’
  
       If a function returns a class-wide type, the object of an extended
       return statement can be declared with a specific type that is
--- 22529,22544 ----
  
       RM References: 6.04.01 (13)
  
!    * 'AI-0015 Constant return objects (0000-00-00)'
  
!      The return object declared in an 'extended_return_statement' may be
       declared constant.  This was always intended, and GNAT has always
       allowed it.
  
       RM References: 6.05 (2.1/2) 3.03 (10/2) 3.03 (21) 6.05 (5/2) 6.05
       (5.7/2)
  
!    * 'AI-0032 Extended return for class-wide functions (0000-00-00)'
  
       If a function returns a class-wide type, the object of an extended
       return statement can be declared with a specific type that is
*************** Supported Aspect
*** 22550,22556 ****
       RM References: 6.05 (5.2/2) 6.05 (5.3/2) 6.05 (5.6/2) 6.05 (5.8/2)
       6.05 (8/2)
  
!    * ‘AI-0103 Static matching for extended return (2010-07-23)’
  
       If the return subtype of a function is an elementary type or a
       constrained type, the subtype indication in an extended return
--- 22550,22556 ----
       RM References: 6.05 (5.2/2) 6.05 (5.3/2) 6.05 (5.6/2) 6.05 (5.8/2)
       6.05 (8/2)
  
!    * 'AI-0103 Static matching for extended return (2010-07-23)'
  
       If the return subtype of a function is an elementary type or a
       constrained type, the subtype indication in an extended return
*************** Supported Aspect
*** 22558,22564 ****
  
       RM References: 6.05 (5.2/2)
  
!    * ‘AI-0058 Abnormal completion of an extended return (0000-00-00)’
  
       The RM had some incorrect wording implying wrong treatment of
       abnormal completion in an extended return.  GNAT has always
--- 22558,22564 ----
  
       RM References: 6.05 (5.2/2)
  
!    * 'AI-0058 Abnormal completion of an extended return (0000-00-00)'
  
       The RM had some incorrect wording implying wrong treatment of
       abnormal completion in an extended return.  GNAT has always
*************** Supported Aspect
*** 22566,22573 ****
  
       RM References: 6.05 (22/2)
  
!    * ‘AI-0050 Raising Constraint_Error early for function call
!      (0000-00-00)’
  
       The implementation permissions for raising ‘Constraint_Error’ early
       on a function call when it was clear an exception would be raised
--- 22566,22573 ----
  
       RM References: 6.05 (22/2)
  
!    * 'AI-0050 Raising Constraint_Error early for function call
!      (0000-00-00)'
  
       The implementation permissions for raising ‘Constraint_Error’ early
       on a function call when it was clear an exception would be raised
*************** Supported Aspect
*** 22577,22583 ****
  
       RM References: 6.05 (24/2)
  
!    * ‘AI-0125 Nonoverridable operations of an ancestor (2010-09-28)’
  
       In Ada 2012, the declaration of a primitive operation of a type
       extension or private extension can also override an inherited
--- 22577,22583 ----
  
       RM References: 6.05 (24/2)
  
!    * 'AI-0125 Nonoverridable operations of an ancestor (2010-09-28)'
  
       In Ada 2012, the declaration of a primitive operation of a type
       extension or private extension can also override an inherited
*************** Supported Aspect
*** 22585,22598 ****
  
       RM References: 7.03.01 (6) 8.03 (23) 8.03.01 (5/2) 8.03.01 (6/2)
  
!    * ‘AI-0062 Null exclusions and deferred constants (0000-00-00)’
  
       A full constant may have a null exclusion even if its associated
       deferred constant does not.  GNAT has always allowed this.
  
       RM References: 7.04 (6/2) 7.04 (7.1/2)
  
!    * ‘AI-0178 Incomplete views are limited (0000-00-00)’
  
       This AI clarifies the role of incomplete views and plugs an
       omission in the RM. GNAT always correctly restricted the use of
--- 22585,22598 ----
  
       RM References: 7.03.01 (6) 8.03 (23) 8.03.01 (5/2) 8.03.01 (6/2)
  
!    * 'AI-0062 Null exclusions and deferred constants (0000-00-00)'
  
       A full constant may have a null exclusion even if its associated
       deferred constant does not.  GNAT has always allowed this.
  
       RM References: 7.04 (6/2) 7.04 (7.1/2)
  
!    * 'AI-0178 Incomplete views are limited (0000-00-00)'
  
       This AI clarifies the role of incomplete views and plugs an
       omission in the RM. GNAT always correctly restricted the use of
*************** Supported Aspect
*** 22600,22606 ****
  
       RM References: 7.05 (3/2) 7.05 (6/2)
  
!    * ‘AI-0087 Actual for formal nonlimited derived type (2010-07-15)’
  
       The actual for a formal nonlimited derived type cannot be limited.
       In particular, a formal derived type that extends a limited
--- 22600,22606 ----
  
       RM References: 7.05 (3/2) 7.05 (6/2)
  
!    * 'AI-0087 Actual for formal nonlimited derived type (2010-07-15)'
  
       The actual for a formal nonlimited derived type cannot be limited.
       In particular, a formal derived type that extends a limited
*************** Supported Aspect
*** 22609,22615 ****
  
       RM References: 7.05 (5/2) 12.05.01 (5.1/2)
  
!    * ‘AI-0099 Tag determines whether finalization needed (0000-00-00)’
  
       This AI clarifies that ‘needs finalization’ is part of dynamic
       semantics, and therefore depends on the run-time characteristics of
--- 22609,22615 ----
  
       RM References: 7.05 (5/2) 12.05.01 (5.1/2)
  
!    * 'AI-0099 Tag determines whether finalization needed (0000-00-00)'
  
       This AI clarifies that ‘needs finalization’ is part of dynamic
       semantics, and therefore depends on the run-time characteristics of
*************** Supported Aspect
*** 22618,22624 ****
  
       RM References: 7.06.01 (6) 7.06.01 (7) 7.06.01 (8) 7.06.01 (9/2)
  
!    * ‘AI-0064 Redundant finalization rule (0000-00-00)’
  
       This is an editorial change only.  The intended behavior is already
       checked by an existing ACATS test, which GNAT has always executed
--- 22618,22624 ----
  
       RM References: 7.06.01 (6) 7.06.01 (7) 7.06.01 (8) 7.06.01 (9/2)
  
!    * 'AI-0064 Redundant finalization rule (0000-00-00)'
  
       This is an editorial change only.  The intended behavior is already
       checked by an existing ACATS test, which GNAT has always executed
*************** Supported Aspect
*** 22626,22632 ****
  
       RM References: 7.06.01 (17.1/1)
  
!    * ‘AI-0026 Missing rules for Unchecked_Union (2010-07-07)’
  
       Record representation clauses concerning Unchecked_Union types
       cannot mention the discriminant of the type.  The type of a
--- 22626,22632 ----
  
       RM References: 7.06.01 (17.1/1)
  
!    * 'AI-0026 Missing rules for Unchecked_Union (2010-07-07)'
  
       Record representation clauses concerning Unchecked_Union types
       cannot mention the discriminant of the type.  The type of a
*************** Supported Aspect
*** 22639,22652 ****
  
       RM References: 7.06 (9.4/2) B.03.03 (9/2) B.03.03 (10/2)
  
!    * ‘AI-0205 Extended return declares visible name (0000-00-00)’
  
       This AI corrects a simple omission in the RM. Return objects have
       always been visible within an extended return statement.
  
       RM References: 8.03 (17)
  
!    * ‘AI-0042 Overriding versus implemented-by (0000-00-00)’
  
       This AI fixes a wording gap in the RM. An operation of a
       synchronized interface can be implemented by a protected or task
--- 22639,22652 ----
  
       RM References: 7.06 (9.4/2) B.03.03 (9/2) B.03.03 (10/2)
  
!    * 'AI-0205 Extended return declares visible name (0000-00-00)'
  
       This AI corrects a simple omission in the RM. Return objects have
       always been visible within an extended return statement.
  
       RM References: 8.03 (17)
  
!    * 'AI-0042 Overriding versus implemented-by (0000-00-00)'
  
       This AI fixes a wording gap in the RM. An operation of a
       synchronized interface can be implemented by a protected or task
*************** Supported Aspect
*** 22656,22662 ****
  
       RM References: 9.01 (9.2/2) 9.04 (11.1/2)
  
!    * ‘AI-0030 Requeue on synchronized interfaces (2010-07-19)’
  
       Requeue is permitted to a protected, synchronized or task interface
       primitive providing it is known that the overriding operation is an
--- 22656,22662 ----
  
       RM References: 9.01 (9.2/2) 9.04 (11.1/2)
  
!    * 'AI-0030 Requeue on synchronized interfaces (2010-07-19)'
  
       Requeue is permitted to a protected, synchronized or task interface
       primitive providing it is known that the overriding operation is an
*************** Supported Aspect
*** 22669,22675 ****
       RM References: 9.05 (9) 9.05.04 (2) 9.05.04 (3) 9.05.04 (5) 9.05.04
       (6) 9.05.04 (7) 9.05.04 (12)
  
!    * ‘AI-0201 Independence of atomic object components (2010-07-22)’
  
       If an Atomic object has a pragma ‘Pack’ or a ‘Component_Size’
       attribute, then individual components may not be addressable by
--- 22669,22675 ----
       RM References: 9.05 (9) 9.05.04 (2) 9.05.04 (3) 9.05.04 (5) 9.05.04
       (6) 9.05.04 (7) 9.05.04 (12)
  
!    * 'AI-0201 Independence of atomic object components (2010-07-22)'
  
       If an Atomic object has a pragma ‘Pack’ or a ‘Component_Size’
       attribute, then individual components may not be addressable by
*************** Supported Aspect
*** 22683,22689 ****
  
       RM References: 9.10 (1/3) C.06 (22/2) C.06 (23/2)
  
!    * ‘AI-0009 Pragma Independent[_Components] (2010-07-23)’
  
       This AI introduces the new pragmas ‘Independent’ and
       ‘Independent_Components’, which control guaranteeing independence
--- 22683,22689 ----
  
       RM References: 9.10 (1/3) C.06 (22/2) C.06 (23/2)
  
!    * 'AI-0009 Pragma Independent[_Components] (2010-07-23)'
  
       This AI introduces the new pragmas ‘Independent’ and
       ‘Independent_Components’, which control guaranteeing independence
*************** Supported Aspect
*** 22693,22699 ****
       RM References: 9.10 (1) 13.01 (15/1) 13.02 (9) 13.03 (13) C.06 (2)
       C.06 (4) C.06 (6) C.06 (9) C.06 (13) C.06 (14)
  
!    * ‘AI-0072 Task signalling using ‘Terminated (0000-00-00)’
  
       This AI clarifies that task signalling for reading ‘'Terminated’
       only occurs if the result is True.  GNAT semantics has always been
--- 22693,22699 ----
       RM References: 9.10 (1) 13.01 (15/1) 13.02 (9) 13.03 (13) C.06 (2)
       C.06 (4) C.06 (6) C.06 (9) C.06 (13) C.06 (14)
  
!    * 'AI-0072 Task signalling using ‘Terminated (0000-00-00)'
  
       This AI clarifies that task signalling for reading ‘'Terminated’
       only occurs if the result is True.  GNAT semantics has always been
*************** Supported Aspect
*** 22701,22714 ****
  
       RM References: 9.10 (6.1/1)
  
!    * ‘AI-0108 Limited incomplete view and discriminants (0000-00-00)’
  
       This AI confirms that an incomplete type from a limited view does
       not have discriminants.  This has always been the case in GNAT.
  
       RM References: 10.01.01 (12.3/2)
  
!    * ‘AI-0129 Limited views and incomplete types (0000-00-00)’
  
       This AI clarifies the description of limited views: a limited view
       of a package includes only one view of a type that has an
--- 22701,22714 ----
  
       RM References: 9.10 (6.1/1)
  
!    * 'AI-0108 Limited incomplete view and discriminants (0000-00-00)'
  
       This AI confirms that an incomplete type from a limited view does
       not have discriminants.  This has always been the case in GNAT.
  
       RM References: 10.01.01 (12.3/2)
  
!    * 'AI-0129 Limited views and incomplete types (0000-00-00)'
  
       This AI clarifies the description of limited views: a limited view
       of a package includes only one view of a type that has an
*************** Supported Aspect
*** 22719,22725 ****
  
       RM References: 10.01.01 (12.2/2) 10.01.01 (12.3/2)
  
!    * ‘AI-0077 Limited withs and scope of declarations (0000-00-00)’
  
       This AI clarifies that a declaration does not include a context
       clause, and confirms that it is illegal to have a context in which
--- 22719,22725 ----
  
       RM References: 10.01.01 (12.2/2) 10.01.01 (12.3/2)
  
!    * 'AI-0077 Limited withs and scope of declarations (0000-00-00)'
  
       This AI clarifies that a declaration does not include a context
       clause, and confirms that it is illegal to have a context in which
*************** Supported Aspect
*** 22728,22734 ****
  
       RM References: 10.01.02 (12/2) 10.01.02 (21/2) 10.01.02 (22/2)
  
!    * ‘AI-0122 Private with and children of generics (0000-00-00)’
  
       This AI clarifies the visibility of private children of generic
       units within instantiations of a parent.  GNAT has always handled
--- 22728,22734 ----
  
       RM References: 10.01.02 (12/2) 10.01.02 (21/2) 10.01.02 (22/2)
  
!    * 'AI-0122 Private with and children of generics (0000-00-00)'
  
       This AI clarifies the visibility of private children of generic
       units within instantiations of a parent.  GNAT has always handled
*************** Supported Aspect
*** 22736,22742 ****
  
       RM References: 10.01.02 (12/2)
  
!    * ‘AI-0040 Limited with clauses on descendant (0000-00-00)’
  
       This AI confirms that a limited with clause in a child unit cannot
       name an ancestor of the unit.  This has always been checked in
--- 22736,22742 ----
  
       RM References: 10.01.02 (12/2)
  
!    * 'AI-0040 Limited with clauses on descendant (0000-00-00)'
  
       This AI confirms that a limited with clause in a child unit cannot
       name an ancestor of the unit.  This has always been checked in
*************** Supported Aspect
*** 22744,22750 ****
  
       RM References: 10.01.02 (20/2)
  
!    * ‘AI-0132 Placement of library unit pragmas (0000-00-00)’
  
       This AI fills a gap in the description of library unit pragmas.
       The pragma clearly must apply to a library unit, even if it does
--- 22744,22750 ----
  
       RM References: 10.01.02 (20/2)
  
!    * 'AI-0132 Placement of library unit pragmas (0000-00-00)'
  
       This AI fills a gap in the description of library unit pragmas.
       The pragma clearly must apply to a library unit, even if it does
*************** Supported Aspect
*** 22753,22759 ****
  
       RM References: 10.01.05 (7)
  
!    * ‘AI-0034 Categorization of limited views (0000-00-00)’
  
       The RM makes certain limited with clauses illegal because of
       categorization considerations, when the corresponding normal with
--- 22753,22759 ----
  
       RM References: 10.01.05 (7)
  
!    * 'AI-0034 Categorization of limited views (0000-00-00)'
  
       The RM makes certain limited with clauses illegal because of
       categorization considerations, when the corresponding normal with
*************** Supported Aspect
*** 22762,22768 ****
  
       RM References: 10.02.01 (11/1) 10.02.01 (17/2)
  
!    * ‘AI-0035 Inconsistencies with Pure units (0000-00-00)’
  
       This AI remedies some inconsistencies in the legality rules for
       Pure units.  Derived access types are legal in a pure unit (on the
--- 22762,22768 ----
  
       RM References: 10.02.01 (11/1) 10.02.01 (17/2)
  
!    * 'AI-0035 Inconsistencies with Pure units (0000-00-00)'
  
       This AI remedies some inconsistencies in the legality rules for
       Pure units.  Derived access types are legal in a pure unit (on the
*************** Supported Aspect
*** 22774,22780 ****
       RM References: 10.02.01 (15.1/2) 10.02.01 (15.4/2) 10.02.01
       (15.5/2) 10.02.01 (17/2)
  
!    * ‘AI-0219 Pure permissions and limited parameters (2010-05-25)’
  
       This AI refines the rules for the cases with limited parameters
       which do not allow the implementations to omit ‘redundant’.  GNAT
--- 22774,22780 ----
       RM References: 10.02.01 (15.1/2) 10.02.01 (15.4/2) 10.02.01
       (15.5/2) 10.02.01 (17/2)
  
!    * 'AI-0219 Pure permissions and limited parameters (2010-05-25)'
  
       This AI refines the rules for the cases with limited parameters
       which do not allow the implementations to omit ‘redundant’.  GNAT
*************** Supported Aspect
*** 22783,22796 ****
  
       RM References: 10.02.01 (18/2)
  
!    * ‘AI-0043 Rules about raising exceptions (0000-00-00)’
  
       This AI covers various omissions in the RM regarding the raising of
       exceptions.  GNAT has always implemented the intended semantics.
  
       RM References: 11.04.01 (10.1/2) 11 (2)
  
!    * ‘AI-0200 Mismatches in formal package declarations (0000-00-00)’
  
       This AI plugs a gap in the RM which appeared to allow some
       obviously intended illegal instantiations.  GNAT has never allowed
--- 22783,22796 ----
  
       RM References: 10.02.01 (18/2)
  
!    * 'AI-0043 Rules about raising exceptions (0000-00-00)'
  
       This AI covers various omissions in the RM regarding the raising of
       exceptions.  GNAT has always implemented the intended semantics.
  
       RM References: 11.04.01 (10.1/2) 11 (2)
  
!    * 'AI-0200 Mismatches in formal package declarations (0000-00-00)'
  
       This AI plugs a gap in the RM which appeared to allow some
       obviously intended illegal instantiations.  GNAT has never allowed
*************** Supported Aspect
*** 22798,22804 ****
  
       RM References: 12.07 (16)
  
!    * ‘AI-0112 Detection of duplicate pragmas (2010-07-24)’
  
       This AI concerns giving names to various representation aspects,
       but the practical effect is simply to make the use of duplicate
--- 22798,22804 ----
  
       RM References: 12.07 (16)
  
!    * 'AI-0112 Detection of duplicate pragmas (2010-07-24)'
  
       This AI concerns giving names to various representation aspects,
       but the practical effect is simply to make the use of duplicate
*************** Supported Aspect
*** 22808,22814 ****
  
       RM References: 13.01 (8)
  
!    * ‘AI-0106 No representation pragmas on generic formals (0000-00-00)’
  
       The RM appeared to allow representation pragmas on generic formal
       parameters, but this was not intended, and GNAT has never permitted
--- 22808,22814 ----
  
       RM References: 13.01 (8)
  
!    * 'AI-0106 No representation pragmas on generic formals (0000-00-00)'
  
       The RM appeared to allow representation pragmas on generic formal
       parameters, but this was not intended, and GNAT has never permitted
*************** Supported Aspect
*** 22816,22822 ****
  
       RM References: 13.01 (9.1/1)
  
!    * ‘AI-0012 Pack/Component_Size for aliased/atomic (2010-07-15)’
  
       It is now illegal to give an inappropriate component size or a
       pragma ‘Pack’ that attempts to change the component size in the
--- 22816,22822 ----
  
       RM References: 13.01 (9.1/1)
  
!    * 'AI-0012 Pack/Component_Size for aliased/atomic (2010-07-15)'
  
       It is now illegal to give an inappropriate component size or a
       pragma ‘Pack’ that attempts to change the component size in the
*************** Supported Aspect
*** 22826,22841 ****
       RM References: 13.02 (6.1/2) 13.02 (7) C.06 (10) C.06 (11) C.06
       (21)
  
!    * ‘AI-0039 Stream attributes cannot be dynamic (0000-00-00)’
  
       The RM permitted the use of dynamic expressions (such as
!      ‘ptr.all’)‘ for stream attributes, but these were never useful and
       are now illegal.  GNAT has always regarded such expressions as
       illegal.
  
       RM References: 13.03 (4) 13.03 (6) 13.13.02 (38/2)
  
!    * ‘AI-0095 Address of intrinsic subprograms (0000-00-00)’
  
       The prefix of ‘'Address’ cannot statically denote a subprogram with
       convention ‘Intrinsic’.  The use of the ‘Address’ attribute raises
--- 22826,22841 ----
       RM References: 13.02 (6.1/2) 13.02 (7) C.06 (10) C.06 (11) C.06
       (21)
  
!    * 'AI-0039 Stream attributes cannot be dynamic (0000-00-00)'
  
       The RM permitted the use of dynamic expressions (such as
!      ‘ptr.all’)' for stream attributes, but these were never useful and
       are now illegal.  GNAT has always regarded such expressions as
       illegal.
  
       RM References: 13.03 (4) 13.03 (6) 13.13.02 (38/2)
  
!    * 'AI-0095 Address of intrinsic subprograms (0000-00-00)'
  
       The prefix of ‘'Address’ cannot statically denote a subprogram with
       convention ‘Intrinsic’.  The use of the ‘Address’ attribute raises
*************** Supported Aspect
*** 22844,22850 ****
  
       RM References: 13.03 (11/1)
  
!    * ‘AI-0116 Alignment of class-wide objects (0000-00-00)’
  
       This AI requires that the alignment of a class-wide object be no
       greater than the alignment of any type in the class.  GNAT has
--- 22844,22850 ----
  
       RM References: 13.03 (11/1)
  
!    * 'AI-0116 Alignment of class-wide objects (0000-00-00)'
  
       This AI requires that the alignment of a class-wide object be no
       greater than the alignment of any type in the class.  GNAT has
*************** Supported Aspect
*** 22852,22858 ****
  
       RM References: 13.03 (29) 13.11 (16)
  
!    * ‘AI-0146 Type invariants (2009-09-21)’
  
       Type invariants may be specified for private types using the aspect
       notation.  Aspect ‘Type_Invariant’ may be specified for any private
--- 22852,22858 ----
  
       RM References: 13.03 (29) 13.11 (16)
  
!    * 'AI-0146 Type invariants (2009-09-21)'
  
       Type invariants may be specified for private types using the aspect
       notation.  Aspect ‘Type_Invariant’ may be specified for any private
*************** Supported Aspect
*** 22861,22874 ****
       invariant is a boolean expression that is tested for being true in
       the following situations: conversions to the private type, object
       declarations for the private type that are default initialized, and
!      [‘in’] ‘out’ parameters and returned result on return from any
       primitive operation for the type that is visible to a client.  GNAT
       defines the synonyms ‘Invariant’ for ‘Type_Invariant’ and
       ‘Invariant'Class’ for ‘Type_Invariant'Class’.
  
       RM References: 13.03.03 (00)
  
!    * ‘AI-0078 Relax Unchecked_Conversion alignment rules (0000-00-00)’
  
       In Ada 2012, compilers are required to support unchecked conversion
       where the target alignment is a multiple of the source alignment.
--- 22861,22874 ----
       invariant is a boolean expression that is tested for being true in
       the following situations: conversions to the private type, object
       declarations for the private type that are default initialized, and
!      ['in'] 'out' parameters and returned result on return from any
       primitive operation for the type that is visible to a client.  GNAT
       defines the synonyms ‘Invariant’ for ‘Type_Invariant’ and
       ‘Invariant'Class’ for ‘Type_Invariant'Class’.
  
       RM References: 13.03.03 (00)
  
!    * 'AI-0078 Relax Unchecked_Conversion alignment rules (0000-00-00)'
  
       In Ada 2012, compilers are required to support unchecked conversion
       where the target alignment is a multiple of the source alignment.
*************** Supported Aspect
*** 22878,22885 ****
  
       RM References: 13.09 (7)
  
!    * ‘AI-0195 Invalid value handling is implementation defined
!      (2010-07-03)’
  
       The handling of invalid values is now designated to be
       implementation defined.  This is a documentation change only,
--- 22878,22885 ----
  
       RM References: 13.09 (7)
  
!    * 'AI-0195 Invalid value handling is implementation defined
!      (2010-07-03)'
  
       The handling of invalid values is now designated to be
       implementation defined.  This is a documentation change only,
*************** Supported Aspect
*** 22893,22899 ****
  
       RM References: 13.09.01 (10)
  
!    * ‘AI-0193 Alignment of allocators (2010-09-16)’
  
       This AI introduces a new attribute ‘Max_Alignment_For_Allocation’,
       analogous to ‘Max_Size_In_Storage_Elements’, but for alignment
--- 22893,22899 ----
  
       RM References: 13.09.01 (10)
  
!    * 'AI-0193 Alignment of allocators (2010-09-16)'
  
       This AI introduces a new attribute ‘Max_Alignment_For_Allocation’,
       analogous to ‘Max_Size_In_Storage_Elements’, but for alignment
*************** Supported Aspect
*** 22902,22908 ****
       RM References: 13.11 (16) 13.11 (21) 13.11.01 (0) 13.11.01 (1)
       13.11.01 (2) 13.11.01 (3)
  
!    * ‘AI-0177 Parameterized expressions (2010-07-10)’
  
       The new Ada 2012 notion of parameterized expressions is
       implemented.  The form is:
--- 22902,22908 ----
       RM References: 13.11 (16) 13.11 (21) 13.11.01 (0) 13.11.01 (1)
       13.11.01 (2) 13.11.01 (3)
  
!    * 'AI-0177 Parameterized expressions (2010-07-10)'
  
       The new Ada 2012 notion of parameterized expressions is
       implemented.  The form is:
*************** Supported Aspect
*** 22915,22921 ****
  
       RM References: 13.11.01 (3/2)
  
!    * ‘AI-0033 Attach/Interrupt_Handler in generic (2010-07-24)’
  
       Neither of these two pragmas may appear within a generic template,
       because the generic might be instantiated at other than the library
--- 22915,22921 ----
  
       RM References: 13.11.01 (3/2)
  
!    * 'AI-0033 Attach/Interrupt_Handler in generic (2010-07-24)'
  
       Neither of these two pragmas may appear within a generic template,
       because the generic might be instantiated at other than the library
*************** Supported Aspect
*** 22923,22929 ****
  
       RM References: 13.11.02 (16) C.03.01 (7/2) C.03.01 (8/2)
  
!    * ‘AI-0161 Restriction No_Default_Stream_Attributes (2010-09-11)’
  
       A new restriction ‘No_Default_Stream_Attributes’ prevents the use
       of any of the default stream attributes for elementary types.  If
--- 22923,22929 ----
  
       RM References: 13.11.02 (16) C.03.01 (7/2) C.03.01 (8/2)
  
!    * 'AI-0161 Restriction No_Default_Stream_Attributes (2010-09-11)'
  
       A new restriction ‘No_Default_Stream_Attributes’ prevents the use
       of any of the default stream attributes for elementary types.  If
*************** Supported Aspect
*** 22932,22938 ****
  
       RM References: 13.12.01 (4/2) 13.13.02 (40/2) 13.13.02 (52/2)
  
!    * ‘AI-0194 Value of Stream_Size attribute (0000-00-00)’
  
       The ‘Stream_Size’ attribute returns the default number of bits in
       the stream representation of the given type.  This value is not
--- 22932,22938 ----
  
       RM References: 13.12.01 (4/2) 13.13.02 (40/2) 13.13.02 (52/2)
  
!    * 'AI-0194 Value of Stream_Size attribute (0000-00-00)'
  
       The ‘Stream_Size’ attribute returns the default number of bits in
       the stream representation of the given type.  This value is not
*************** Supported Aspect
*** 22941,22954 ****
  
       RM References: 13.13.02 (1.2/2)
  
!    * ‘AI-0109 Redundant check in S’Class’Input (0000-00-00)’
  
       This AI is an editorial change only.  It removes the need for a tag
       check that can never fail.
  
       RM References: 13.13.02 (34/2)
  
!    * ‘AI-0007 Stream read and private scalar types (0000-00-00)’
  
       The RM as written appeared to limit the possibilities of declaring
       read attribute procedures for private scalar types.  This
--- 22941,22954 ----
  
       RM References: 13.13.02 (1.2/2)
  
!    * 'AI-0109 Redundant check in S’Class’Input (0000-00-00)'
  
       This AI is an editorial change only.  It removes the need for a tag
       check that can never fail.
  
       RM References: 13.13.02 (34/2)
  
!    * 'AI-0007 Stream read and private scalar types (0000-00-00)'
  
       The RM as written appeared to limit the possibilities of declaring
       read attribute procedures for private scalar types.  This
*************** Supported Aspect
*** 22956,22962 ****
  
       RM References: 13.13.02 (50/2) 13.13.02 (51/2)
  
!    * ‘AI-0065 Remote access types and external streaming (0000-00-00)’
  
       This AI clarifies the fact that all remote access types support
       external streaming.  This fixes an obvious oversight in the
--- 22956,22962 ----
  
       RM References: 13.13.02 (50/2) 13.13.02 (51/2)
  
!    * 'AI-0065 Remote access types and external streaming (0000-00-00)'
  
       This AI clarifies the fact that all remote access types support
       external streaming.  This fixes an obvious oversight in the
*************** Supported Aspect
*** 22965,22971 ****
  
       RM References: 13.13.02 (52/2)
  
!    * ‘AI-0019 Freezing of primitives for tagged types (0000-00-00)’
  
       The RM suggests that primitive subprograms of a specific tagged
       type are frozen when the tagged type is frozen.  This would be an
--- 22965,22971 ----
  
       RM References: 13.13.02 (52/2)
  
!    * 'AI-0019 Freezing of primitives for tagged types (0000-00-00)'
  
       The RM suggests that primitive subprograms of a specific tagged
       type are frozen when the tagged type is frozen.  This would be an
*************** Supported Aspect
*** 22976,22982 ****
       RM References: 13.14 (2) 13.14 (3/1) 13.14 (8.1/1) 13.14 (10) 13.14
       (14) 13.14 (15.1/2)
  
!    * ‘AI-0017 Freezing and incomplete types (0000-00-00)’
  
       So-called ‘Taft-amendment types’ (i.e., types that are completed in
       package bodies) are not frozen by the occurrence of bodies in the
--- 22976,22982 ----
       RM References: 13.14 (2) 13.14 (3/1) 13.14 (8.1/1) 13.14 (10) 13.14
       (14) 13.14 (15.1/2)
  
!    * 'AI-0017 Freezing and incomplete types (0000-00-00)'
  
       So-called ‘Taft-amendment types’ (i.e., types that are completed in
       package bodies) are not frozen by the occurrence of bodies in the
*************** Supported Aspect
*** 22984,22990 ****
  
       RM References: 13.14 (3/1)
  
!    * ‘AI-0060 Extended definition of remote access types (0000-00-00)’
  
       This AI extends the definition of remote access types to include
       access to limited, synchronized, protected or task class-wide
--- 22984,22990 ----
  
       RM References: 13.14 (3/1)
  
!    * 'AI-0060 Extended definition of remote access types (0000-00-00)'
  
       This AI extends the definition of remote access types to include
       access to limited, synchronized, protected or task class-wide
*************** Supported Aspect
*** 22993,22999 ****
       RM References: A (4) E.02.02 (9/1) E.02.02 (9.2/1) E.02.02 (14/2)
       E.02.02 (18)
  
!    * ‘AI-0114 Classification of letters (0000-00-00)’
  
       The code points 170 (‘FEMININE ORDINAL INDICATOR’), 181 (‘MICRO
       SIGN’), and 186 (‘MASCULINE ORDINAL INDICATOR’) are technically
--- 22993,22999 ----
       RM References: A (4) E.02.02 (9/1) E.02.02 (9.2/1) E.02.02 (14/2)
       E.02.02 (18)
  
!    * 'AI-0114 Classification of letters (0000-00-00)'
  
       The code points 170 (‘FEMININE ORDINAL INDICATOR’), 181 (‘MICRO
       SIGN’), and 186 (‘MASCULINE ORDINAL INDICATOR’) are technically
*************** Supported Aspect
*** 23004,23010 ****
  
       RM References: A.03.02 (59) A.04.06 (7)
  
!    * ‘AI-0185 Ada.Wide_[Wide_]Characters.Handling (2010-07-06)’
  
       Two new packages ‘Ada.Wide_[Wide_]Characters.Handling’ provide
       classification functions for ‘Wide_Character’ and
--- 23004,23010 ----
  
       RM References: A.03.02 (59) A.04.06 (7)
  
!    * 'AI-0185 Ada.Wide_[Wide_]Characters.Handling (2010-07-06)'
  
       Two new packages ‘Ada.Wide_[Wide_]Characters.Handling’ provide
       classification functions for ‘Wide_Character’ and
*************** Supported Aspect
*** 23013,23019 ****
  
       RM References: A.03.05 (0) A.03.06 (0)
  
!    * ‘AI-0031 Add From parameter to Find_Token (2010-07-25)’
  
       A new version of ‘Find_Token’ is added to all relevant string
       packages, with an extra parameter ‘From’.  Instead of starting at
--- 23013,23019 ----
  
       RM References: A.03.05 (0) A.03.06 (0)
  
!    * 'AI-0031 Add From parameter to Find_Token (2010-07-25)'
  
       A new version of ‘Find_Token’ is added to all relevant string
       packages, with an extra parameter ‘From’.  Instead of starting at
*************** Supported Aspect
*** 23026,23032 ****
       RM References: A.04.03 (16) A.04.03 (67) A.04.03 (68/1) A.04.04
       (51) A.04.05 (46)
  
!    * ‘AI-0056 Index on null string returns zero (0000-00-00)’
  
       The wording in the Ada 2005 RM implied an incompatible handling of
       the ‘Index’ functions, resulting in raising an exception instead of
--- 23026,23032 ----
       RM References: A.04.03 (16) A.04.03 (67) A.04.03 (68/1) A.04.04
       (51) A.04.05 (46)
  
!    * 'AI-0056 Index on null string returns zero (0000-00-00)'
  
       The wording in the Ada 2005 RM implied an incompatible handling of
       the ‘Index’ functions, resulting in raising an exception instead of
*************** Supported Aspect
*** 23036,23042 ****
  
       RM References: A.04.03 (56.2/2) A.04.03 (58.5/2)
  
!    * ‘AI-0137 String encoding package (2010-03-25)’
  
       The packages ‘Ada.Strings.UTF_Encoding’, together with its child
       packages, ‘Conversions’, ‘Strings’, ‘Wide_Strings’, and
--- 23036,23042 ----
  
       RM References: A.04.03 (56.2/2) A.04.03 (58.5/2)
  
!    * 'AI-0137 String encoding package (2010-03-25)'
  
       The packages ‘Ada.Strings.UTF_Encoding’, together with its child
       packages, ‘Conversions’, ‘Strings’, ‘Wide_Strings’, and
*************** Supported Aspect
*** 23054,23060 ****
  
       RM References: A.04.11
  
!    * ‘AI-0038 Minor errors in Text_IO (0000-00-00)’
  
       These are minor errors in the description on three points.  The
       intent on all these points has always been clear, and GNAT has
--- 23054,23060 ----
  
       RM References: A.04.11
  
!    * 'AI-0038 Minor errors in Text_IO (0000-00-00)'
  
       These are minor errors in the description on three points.  The
       intent on all these points has always been clear, and GNAT has
*************** Supported Aspect
*** 23063,23069 ****
       RM References: A.10.05 (37) A.10.07 (8/1) A.10.07 (10) A.10.07 (12)
       A.10.08 (10) A.10.08 (24)
  
!    * ‘AI-0044 Restrictions on container instantiations (0000-00-00)’
  
       This AI places restrictions on allowed instantiations of generic
       containers.  These restrictions are not checked by the compiler, so
--- 23063,23069 ----
       RM References: A.10.05 (37) A.10.07 (8/1) A.10.07 (10) A.10.07 (12)
       A.10.08 (10) A.10.08 (24)
  
!    * 'AI-0044 Restrictions on container instantiations (0000-00-00)'
  
       This AI places restrictions on allowed instantiations of generic
       containers.  These restrictions are not checked by the compiler, so
*************** Supported Aspect
*** 23073,23079 ****
       RM References: A.18 (4/2) A.18.02 (231/2) A.18.03 (145/2) A.18.06
       (56/2) A.18.08 (66/2) A.18.09 (79/2) A.18.26 (5/2) A.18.26 (9/2)
  
!    * ‘AI-0127 Adding Locale Capabilities (2010-09-29)’
  
       This package provides an interface for identifying the current
       locale.
--- 23073,23079 ----
       RM References: A.18 (4/2) A.18.02 (231/2) A.18.03 (145/2) A.18.06
       (56/2) A.18.08 (66/2) A.18.09 (79/2) A.18.26 (5/2) A.18.26 (9/2)
  
!    * 'AI-0127 Adding Locale Capabilities (2010-09-29)'
  
       This package provides an interface for identifying the current
       locale.
*************** Supported Aspect
*** 23081,23087 ****
       RM References: A.19 A.19.01 A.19.02 A.19.03 A.19.05 A.19.06 A.19.07
       A.19.08 A.19.09 A.19.10 A.19.11 A.19.12 A.19.13
  
!    * ‘AI-0002 Export C with unconstrained arrays (0000-00-00)’
  
       The compiler is not required to support exporting an Ada subprogram
       with convention C if there are parameters or a return type of an
--- 23081,23087 ----
       RM References: A.19 A.19.01 A.19.02 A.19.03 A.19.05 A.19.06 A.19.07
       A.19.08 A.19.09 A.19.10 A.19.11 A.19.12 A.19.13
  
!    * 'AI-0002 Export C with unconstrained arrays (0000-00-00)'
  
       The compiler is not required to support exporting an Ada subprogram
       with convention C if there are parameters or a return type of an
*************** Supported Aspect
*** 23092,23098 ****
  
       RM References: B.01 (17) B.03 (62) B.03 (71.1/2)
  
!    * ‘AI-0216 No_Task_Hierarchy forbids local tasks (0000-00-00)’
  
       It is clearly the intention that ‘No_Task_Hierarchy’ is intended to
       forbid tasks declared locally within subprograms, or functions
--- 23092,23098 ----
  
       RM References: B.01 (17) B.03 (62) B.03 (71.1/2)
  
!    * 'AI-0216 No_Task_Hierarchy forbids local tasks (0000-00-00)'
  
       It is clearly the intention that ‘No_Task_Hierarchy’ is intended to
       forbid tasks declared locally within subprograms, or functions
*************** Supported Aspect
*** 23103,23126 ****
  
       RM References: D.07 (3/3)
  
!    * ‘AI-0211 No_Relative_Delays forbids Set_Handler use (2010-07-09)’
  
       The restriction ‘No_Relative_Delays’ forbids any calls to the
       subprogram ‘Ada.Real_Time.Timing_Events.Set_Handler’.
  
       RM References: D.07 (5) D.07 (10/2) D.07 (10.4/2) D.07 (10.7/2)
  
!    * ‘AI-0190 pragma Default_Storage_Pool (2010-09-15)’
  
       This AI introduces a new pragma ‘Default_Storage_Pool’, which can
       be used to control storage pools globally.  In particular, you can
!      force every access type that is used for allocation (‘new’) to have
       an explicit storage pool, or you can declare a pool globally to be
       used for all access types that lack an explicit one.
  
       RM References: D.07 (8)
  
!    * ‘AI-0189 No_Allocators_After_Elaboration (2010-01-23)’
  
       This AI introduces a new restriction
       ‘No_Allocators_After_Elaboration’, which says that no dynamic
--- 23103,23126 ----
  
       RM References: D.07 (3/3)
  
!    * 'AI-0211 No_Relative_Delays forbids Set_Handler use (2010-07-09)'
  
       The restriction ‘No_Relative_Delays’ forbids any calls to the
       subprogram ‘Ada.Real_Time.Timing_Events.Set_Handler’.
  
       RM References: D.07 (5) D.07 (10/2) D.07 (10.4/2) D.07 (10.7/2)
  
!    * 'AI-0190 pragma Default_Storage_Pool (2010-09-15)'
  
       This AI introduces a new pragma ‘Default_Storage_Pool’, which can
       be used to control storage pools globally.  In particular, you can
!      force every access type that is used for allocation ('new') to have
       an explicit storage pool, or you can declare a pool globally to be
       used for all access types that lack an explicit one.
  
       RM References: D.07 (8)
  
!    * 'AI-0189 No_Allocators_After_Elaboration (2010-01-23)'
  
       This AI introduces a new restriction
       ‘No_Allocators_After_Elaboration’, which says that no dynamic
*************** Supported Aspect
*** 23132,23138 ****
  
       RM References: D.07 (19.1/2) H.04 (23.3/2)
  
!    * ‘AI-0171 Pragma CPU and Ravenscar Profile (2010-09-24)’
  
       A new package ‘System.Multiprocessors’ is added, together with the
       definition of pragma ‘CPU’ for controlling task affinity.  A new no
--- 23132,23138 ----
  
       RM References: D.07 (19.1/2) H.04 (23.3/2)
  
!    * 'AI-0171 Pragma CPU and Ravenscar Profile (2010-09-24)'
  
       A new package ‘System.Multiprocessors’ is added, together with the
       definition of pragma ‘CPU’ for controlling task affinity.  A new no
*************** Supported Aspect
*** 23142,23148 ****
  
       RM References: D.13.01 (4/2) D.16
  
!    * ‘AI-0210 Correct Timing_Events metric (0000-00-00)’
  
       This is a documentation only issue regarding wording of metric
       requirements, that does not affect the implementation of the
--- 23142,23148 ----
  
       RM References: D.13.01 (4/2) D.16
  
!    * 'AI-0210 Correct Timing_Events metric (0000-00-00)'
  
       This is a documentation only issue regarding wording of metric
       requirements, that does not affect the implementation of the
*************** Supported Aspect
*** 23150,23163 ****
  
       RM References: D.15 (24/2)
  
!    * ‘AI-0206 Remote types packages and preelaborate (2010-07-24)’
  
       Remote types packages are now allowed to depend on preelaborated
       packages.  This was formerly considered illegal.
  
       RM References: E.02.02 (6)
  
!    * ‘AI-0152 Restriction No_Anonymous_Allocators (2010-09-08)’
  
       Restriction ‘No_Anonymous_Allocators’ prevents the use of
       allocators where the type of the returned value is an anonymous
--- 23150,23163 ----
  
       RM References: D.15 (24/2)
  
!    * 'AI-0206 Remote types packages and preelaborate (2010-07-24)'
  
       Remote types packages are now allowed to depend on preelaborated
       packages.  This was formerly considered illegal.
  
       RM References: E.02.02 (6)
  
!    * 'AI-0152 Restriction No_Anonymous_Allocators (2010-09-08)'
  
       Restriction ‘No_Anonymous_Allocators’ prevents the use of
       allocators where the type of the returned value is an anonymous
*************** File: gnat_rm.info,  Node: Legal Ada 83
*** 23864,23870 ****
  Some legal Ada 83 programs are illegal (i.e., they will fail to compile)
  in Ada 95 and later versions of the standard:
  
!    * ‘Character literals’
  
       Some uses of character literals are ambiguous.  Since Ada 95 has
       introduced ‘Wide_Character’ as a new predefined character type,
--- 23864,23870 ----
  Some legal Ada 83 programs are illegal (i.e., they will fail to compile)
  in Ada 95 and later versions of the standard:
  
!    * 'Character literals'
  
       Some uses of character literals are ambiguous.  Since Ada 95 has
       introduced ‘Wide_Character’ as a new predefined character type,
*************** in Ada 95 and later versions of the stan
*** 23879,23892 ****
  
            for Char in Character range 'A' .. 'Z' loop ... end loop;
  
!    * ‘New reserved words’
  
       The identifiers ‘abstract’, ‘aliased’, ‘protected’, ‘requeue’,
       ‘tagged’, and ‘until’ are reserved in Ada 95.  Existing Ada 83 code
       using any of these identifiers must be edited to use some
       alternative name.
  
!    * ‘Freezing rules’
  
       The rules in Ada 95 are slightly different with regard to the point
       at which entities are frozen, and representation pragmas and
--- 23879,23892 ----
  
            for Char in Character range 'A' .. 'Z' loop ... end loop;
  
!    * 'New reserved words'
  
       The identifiers ‘abstract’, ‘aliased’, ‘protected’, ‘requeue’,
       ‘tagged’, and ‘until’ are reserved in Ada 95.  Existing Ada 83 code
       using any of these identifiers must be edited to use some
       alternative name.
  
!    * 'Freezing rules'
  
       The rules in Ada 95 are slightly different with regard to the point
       at which entities are frozen, and representation pragmas and
*************** in Ada 95 and later versions of the stan
*** 23900,23906 ****
       to a subprogram body.  If necessary, a separate subprogram
       declaration must be introduced to which the pragma can be applied.
  
!    * ‘Optional bodies for library packages’
  
       In Ada 83, a package that did not require a package body was
       nevertheless allowed to have one.  This lead to certain surprises
--- 23900,23906 ----
       to a subprogram body.  If necessary, a separate subprogram
       declaration must be introduced to which the pragma can be applied.
  
!    * 'Optional bodies for library packages'
  
       In Ada 83, a package that did not require a package body was
       nevertheless allowed to have one.  This lead to certain surprises
*************** in Ada 95 and later versions of the stan
*** 23918,23924 ****
       spec, since one effect of this pragma is to require the presence of
       a package body.
  
!    * ‘Numeric_Error is the same exception as Constraint_Error’
  
       In Ada 95, the exception ‘Numeric_Error’ is a renaming of
       ‘Constraint_Error’.  This means that it is illegal to have separate
--- 23918,23924 ----
       spec, since one effect of this pragma is to require the presence of
       a package body.
  
!    * 'Numeric_Error is the same exception as Constraint_Error'
  
       In Ada 95, the exception ‘Numeric_Error’ is a renaming of
       ‘Constraint_Error’.  This means that it is illegal to have separate
*************** in Ada 95 and later versions of the stan
*** 23927,23933 ****
       83, a compiler was free to raise ‘Constraint_Error’ in place of
       ‘Numeric_Error’ in all cases).
  
!    * ‘Indefinite subtypes in generics’
  
       In Ada 83, it was permissible to pass an indefinite type (e.g,
       ‘String’) as the actual for a generic formal private type, but then
--- 23927,23933 ----
       83, a compiler was free to raise ‘Constraint_Error’ in place of
       ‘Numeric_Error’ in all cases).
  
!    * 'Indefinite subtypes in generics'
  
       In Ada 83, it was permissible to pass an indefinite type (e.g,
       ‘String’) as the actual for a generic formal private type, but then
*************** File: gnat_rm.info,  Node: More determin
*** 23953,23959 ****
  19.2.2 More deterministic semantics
  -----------------------------------
  
!    * ‘Conversions’
  
       Conversions from real types to integer types round away from 0.  In
       Ada 83 the conversion Integer(2.5) could deliver either 2 or 3 as
--- 23953,23959 ----
  19.2.2 More deterministic semantics
  -----------------------------------
  
!    * 'Conversions'
  
       Conversions from real types to integer types round away from 0.  In
       Ada 83 the conversion Integer(2.5) could deliver either 2 or 3 as
*************** File: gnat_rm.info,  Node: More determin
*** 23965,23971 ****
       that this issue is no worse than already existed in Ada 83 when
       porting code from one vendor to another.
  
!    * ‘Tasking’
  
       The Real-Time Annex introduces a set of policies that define the
       behavior of features that were implementation dependent in Ada 83,
--- 23965,23971 ----
       that this issue is no worse than already existed in Ada 83 when
       porting code from one vendor to another.
  
!    * 'Tasking'
  
       The Real-Time Annex introduces a set of policies that define the
       behavior of features that were implementation dependent in Ada 83,
*************** was not possible in Ada 83.  Fortunately
*** 23983,23989 ****
  one situation that you should be alert to is the change in the
  predefined type ‘Character’ from 7-bit ASCII to 8-bit Latin-1.
  
!    * ‘Range of type ‘‘Character‘‘’
  
       The range of ‘Standard.Character’ is now the full 256 characters of
       Latin-1, whereas in most Ada 83 implementations it was restricted
--- 23983,23989 ----
  one situation that you should be alert to is the change in the
  predefined type ‘Character’ from 7-bit ASCII to 8-bit Latin-1.
  
!    * 'Range of type ''Character'''
  
       The range of ‘Standard.Character’ is now the full 256 characters of
       Latin-1, whereas in most Ada 83 implementations it was restricted
*************** File: gnat_rm.info,  Node: Other languag
*** 24008,24014 ****
  19.2.4 Other language compatibility issues
  ------------------------------------------
  
!    * ‘-gnat83’ switch
  
       All implementations of GNAT provide a switch that causes GNAT to
       operate in Ada 83 mode.  In this mode, some but not all
--- 24008,24014 ----
  19.2.4 Other language compatibility issues
  ------------------------------------------
  
!    * '-gnat83' switch
  
       All implementations of GNAT provide a switch that causes GNAT to
       operate in Ada 83 mode.  In this mode, some but not all
*************** there are a number of incompatibilities.
*** 24042,24054 ****
  for a complete description please see the ‘Annotated Ada 2005 Reference
  Manual’, or section 9.1.1 in ‘Rationale for Ada 2005’.
  
!    * ‘New reserved words.’
  
       The words ‘interface’, ‘overriding’ and ‘synchronized’ are reserved
       in Ada 2005.  A pre-Ada 2005 program that uses any of these as an
       identifier will be illegal.
  
!    * ‘New declarations in predefined packages.’
  
       A number of packages in the predefined environment contain new
       declarations: ‘Ada.Exceptions’, ‘Ada.Real_Time’, ‘Ada.Strings’,
--- 24042,24054 ----
  for a complete description please see the ‘Annotated Ada 2005 Reference
  Manual’, or section 9.1.1 in ‘Rationale for Ada 2005’.
  
!    * 'New reserved words.'
  
       The words ‘interface’, ‘overriding’ and ‘synchronized’ are reserved
       in Ada 2005.  A pre-Ada 2005 program that uses any of these as an
       identifier will be illegal.
  
!    * 'New declarations in predefined packages.'
  
       A number of packages in the predefined environment contain new
       declarations: ‘Ada.Exceptions’, ‘Ada.Real_Time’, ‘Ada.Strings’,
*************** Manual’, or section 9.1.1 in ‘Ration
*** 24059,24083 ****
       program does a ‘with’ and ‘use’ of any of these packages, the new
       declarations may cause name clashes.
  
!    * ‘Access parameters.’
  
       A nondispatching subprogram with an access parameter cannot be
       renamed as a dispatching operation.  This was permitted in Ada 95.
  
!    * ‘Access types, discriminants, and constraints.’
  
       Rule changes in this area have led to some incompatibilities; for
       example, constrained subtypes of some access types are not
       permitted in Ada 2005.
  
!    * ‘Aggregates for limited types.’
  
       The allowance of aggregates for limited types in Ada 2005 raises
       the possibility of ambiguities in legal Ada 95 programs, since
       additional types now need to be considered in expression
       resolution.
  
!    * ‘Fixed-point multiplication and division.’
  
       Certain expressions involving ‘*’ or ‘/’ for a fixed-point type,
       which were legal in Ada 95 and invoked the predefined versions of
--- 24059,24083 ----
       program does a ‘with’ and ‘use’ of any of these packages, the new
       declarations may cause name clashes.
  
!    * 'Access parameters.'
  
       A nondispatching subprogram with an access parameter cannot be
       renamed as a dispatching operation.  This was permitted in Ada 95.
  
!    * 'Access types, discriminants, and constraints.'
  
       Rule changes in this area have led to some incompatibilities; for
       example, constrained subtypes of some access types are not
       permitted in Ada 2005.
  
!    * 'Aggregates for limited types.'
  
       The allowance of aggregates for limited types in Ada 2005 raises
       the possibility of ambiguities in legal Ada 95 programs, since
       additional types now need to be considered in expression
       resolution.
  
!    * 'Fixed-point multiplication and division.'
  
       Certain expressions involving ‘*’ or ‘/’ for a fixed-point type,
       which were legal in Ada 95 and invoked the predefined versions of
*************** Manual’, or section 9.1.1 in ‘Ration
*** 24085,24091 ****
       either by applying a type conversion to the expression, or by
       explicitly invoking the operation from package ‘Standard’.
  
!    * ‘Return-by-reference types.’
  
       The Ada 95 return-by-reference mechanism has been removed.
       Instead, the user can declare a function returning a value from an
--- 24085,24091 ----
       either by applying a type conversion to the expression, or by
       explicitly invoking the operation from package ‘Standard’.
  
!    * 'Return-by-reference types.'
  
       The Ada 95 return-by-reference mechanism has been removed.
       Instead, the user can declare a function returning a value from an
*************** will not encounter access before elabora
*** 24188,24194 ****
  inserting ‘Elaborate’ or ‘Elaborate_All’ pragmas where needed.  However,
  this can lead to the creation of elaboration circularities and a
  resulting rejection of the program by gnatbind.  This issue is
! thoroughly described in the ‘Elaboration Order Handling in GNAT’
  appendix in the ‘GNAT User’s Guide’.  In brief, there are several ways
  to deal with this situation:
  
--- 24188,24194 ----
  inserting ‘Elaborate’ or ‘Elaborate_All’ pragmas where needed.  However,
  this can lead to the creation of elaboration circularities and a
  resulting rejection of the program by gnatbind.  This issue is
! thoroughly described in the 'Elaboration Order Handling in GNAT'
  appendix in the ‘GNAT User’s Guide’.  In brief, there are several ways
  to deal with this situation:
  
*************** to deal with this situation:
*** 24198,24204 ****
     * Constrain the elaboration order by including explicit
       ‘Elaborate_Body’ or ‘Elaborate’ pragmas, and then inhibit the
       generation of implicit ‘Elaborate_All’ pragmas either globally (as
!      an effect of the ‘-gnatE’ switch) or locally (by selectively
       suppressing elaboration checks via pragma
       ‘Suppress(Elaboration_Check)’ when it is safe to do so).
  
--- 24198,24204 ----
     * Constrain the elaboration order by including explicit
       ‘Elaborate_Body’ or ‘Elaborate’ pragmas, and then inhibit the
       generation of implicit ‘Elaborate_All’ pragmas either globally (as
!      an effect of the '-gnatE' switch) or locally (by selectively
       suppressing elaboration checks via pragma
       ‘Suppress(Elaboration_Check)’ when it is safe to do so).
  
*************** not affect porting code to GNAT. (As of
*** 24235,24241 ****
  compiler available for Ada 2005; the following issues may or may not
  arise for Ada 2005 programs when other compilers appear.)
  
!    * ‘Ada 83 Pragmas and Attributes’
  
       Ada 95 compilers are allowed, but not required, to implement the
       missing Ada 83 pragmas and attributes that are no longer defined in
--- 24235,24241 ----
  compiler available for Ada 2005; the following issues may or may not
  arise for Ada 2005 programs when other compilers appear.)
  
!    * 'Ada 83 Pragmas and Attributes'
  
       Ada 95 compilers are allowed, but not required, to implement the
       missing Ada 83 pragmas and attributes that are no longer defined in
*************** arise for Ada 2005 programs when other c
*** 24243,24256 ****
       eliminating this as a compatibility concern, but some other Ada 95
       compilers reject these pragmas and attributes.
  
!    * ‘Specialized Needs Annexes’
  
       GNAT implements the full set of special needs annexes.  At the
       current time, it is the only Ada 95 compiler to do so.  This means
       that programs making use of these features may not be portable to
       other Ada 95 compilation systems.
  
!    * ‘Representation Clauses’
  
       Some other Ada 95 compilers implement only the minimal set of
       representation clauses required by the Ada 95 reference manual.
--- 24243,24256 ----
       eliminating this as a compatibility concern, but some other Ada 95
       compilers reject these pragmas and attributes.
  
!    * 'Specialized Needs Annexes'
  
       GNAT implements the full set of special needs annexes.  At the
       current time, it is the only Ada 95 compiler to do so.  This means
       that programs making use of these features may not be portable to
       other Ada 95 compilation systems.
  
!    * 'Representation Clauses'
  
       Some other Ada 95 compilers implement only the minimal set of
       representation clauses required by the Ada 95 reference manual.
*************** implementation dependent characteristics
*** 24281,24287 ****
  following is a list of the cases most likely to arise in existing Ada 83
  code.
  
!    * ‘Implicit Packing’
  
       Some Ada 83 compilers allowed a Size specification to cause
       implicit packing of an array or record.  This could cause expensive
--- 24281,24287 ----
  following is a list of the cases most likely to arise in existing Ada 83
  code.
  
!    * 'Implicit Packing'
  
       Some Ada 83 compilers allowed a Size specification to cause
       implicit packing of an array or record.  This could cause expensive
*************** code.
*** 24296,24302 ****
       provide the explicit pragma ‘Pack’, or for more fine tuned control,
       provide a Component_Size clause.
  
!    * ‘Meaning of Size Attribute’
  
       The Size attribute in Ada 95 (and Ada 2005) for discrete types is
       defined as the minimal number of bits required to hold values of
--- 24296,24302 ----
       provide the explicit pragma ‘Pack’, or for more fine tuned control,
       provide a Component_Size clause.
  
!    * 'Meaning of Size Attribute'
  
       The Size attribute in Ada 95 (and Ada 2005) for discrete types is
       defined as the minimal number of bits required to hold values of
*************** code.
*** 24309,24315 ****
       can provide a useful way of duplicating the behavior of some Ada 83
       compiler systems.
  
!    * ‘Size of Access Types’
  
       A common assumption in Ada 83 code is that an access type is in
       fact a pointer, and that therefore it will be the same size as a
--- 24309,24315 ----
       can provide a useful way of duplicating the behavior of some Ada 83
       compiler systems.
  
!    * 'Size of Access Types'
  
       A common assumption in Ada 83 code is that an access type is in
       fact a pointer, and that therefore it will be the same size as a
*************** subset of them can sensibly be implement
*** 24360,24371 ****
  in *note Implementation Defined Pragmas: 7. indicates whether or not
  they are applicable to GNAT.
  
!    * ‘Default floating-point representation’
  
       In GNAT, the default floating-point format is IEEE, whereas in HP
       Ada 83, it is VMS format.
  
!    * ‘System’
  
       the package System in GNAT exactly corresponds to the definition in
       the Ada 95 reference manual, which means that it excludes many of
--- 24360,24371 ----
  in *note Implementation Defined Pragmas: 7. indicates whether or not
  they are applicable to GNAT.
  
!    * 'Default floating-point representation'
  
       In GNAT, the default floating-point format is IEEE, whereas in HP
       Ada 83, it is VMS format.
  
!    * 'System'
  
       the package System in GNAT exactly corresponds to the definition in
       the Ada 95 reference manual, which means that it excludes many of
*************** Copyright 2000, 2001, 2002, 2007, 2008 F
*** 24388,24394 ****
  Everyone is permitted to copy and distribute verbatim copies of this
  license document, but changing it is not allowed.
  
! ‘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
--- 24388,24394 ----
  Everyone is permitted to copy and distribute verbatim copies of this
  license document, but changing it is not allowed.
  
! '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
*************** used for any textual work, regardless of
*** 24411,24432 ****
  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
--- 24411,24432 ----
  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
*************** mathematics.)  The relationship could be
*** 24436,24442 ****
  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
--- 24436,24442 ----
  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 Documen
*** 24444,24455 ****
  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
--- 24444,24455 ----
  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
*************** formatters.  A copy made in an otherwise
*** 24460,24466 ****
  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
--- 24460,24466 ----
  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
*************** processing tools are not generally avail
*** 24473,24494 ****
  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
--- 24473,24494 ----
  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
*************** but only as regards disclaiming warranti
*** 24498,24504 ****
  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
--- 24498,24504 ----
  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
*************** number of copies you must also follow th
*** 24513,24519 ****
  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
--- 24513,24519 ----
  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
*************** It is requested, but not required, that
*** 24550,24556 ****
  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
--- 24550,24556 ----
  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
*************** The author(s) and publisher(s) of the Do
*** 24648,24654 ****
  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
--- 24648,24654 ----
  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
*************** likewise combine any sections Entitled 
*** 24672,24678 ****
  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
--- 24672,24678 ----
  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
*************** it individually under this License, prov
*** 24685,24691 ****
  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
--- 24685,24691 ----
  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
*************** that bracket the Document within the agg
*** 24703,24709 ****
  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
--- 24703,24709 ----
  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
*************** If a section in the Document is Entitled
*** 24722,24728 ****
  “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
--- 24722,24728 ----
  “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
*************** this License.  If your rights have been
*** 24749,24755 ****
  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
--- 24749,24755 ----
  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
*************** that a proxy can decide which future ver
*** 24769,24775 ****
  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
--- 24769,24775 ----
  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
*************** The operator of an MMC Site may republis
*** 24797,24803 ****
  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
--- 24797,24803 ----
  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
*************** Index
*** 24836,24847 ****
  [index]
  * Menu:
  
  * -gnat12 option (gcc):                  Implementation of Ada 2012 Features.
                                                               (line    6)
  * -gnatR (gcc):                          Determining the Representations chosen by GNAT.
                                                               (line    6)
- * ___lock file (for shared passive packages): GNAT Implementation of Shared Passive Packages.
-                                                              (line   72)
  * Abort_Signal:                          Attribute Abort_Signal.
                                                               (line    6)
  * Abstract_State:                        Aspect Abstract_State.
--- 24836,24847 ----
  [index]
  * Menu:
  
+ * ___lock file (for shared passive packages): GNAT Implementation of Shared Passive Packages.
+                                                              (line   72)
  * -gnat12 option (gcc):                  Implementation of Ada 2012 Features.
                                                               (line    6)
  * -gnatR (gcc):                          Determining the Representations chosen by GNAT.
                                                               (line    6)
  * Abort_Signal:                          Attribute Abort_Signal.
                                                               (line    6)
  * Abstract_State:                        Aspect Abstract_State.
*************** Index
*** 24873,24878 ****
--- 24873,24880 ----
                                                               (line   79)
  * Ada Extensions:                        Pragma Extensions_Allowed.
                                                               (line    6)
+ * Ada_2012 configuration pragma:         Implementation of Ada 2012 Features.
+                                                              (line    6)
  * Ada.Characters.Handling:               RM A 1 52 Names of Predefined Numeric Types.
                                                               (line   13)
  * Ada.Characters.Latin_9 (a-chlat9.ads): Ada Characters Latin_9 a-chlat9 ads.
*************** Index
*** 24929,24936 ****
                                                               (line    6)
  * Ada.Wide_Wide_Text_IO.Reset_Standard_Files (a-zrstfi.ads): Ada Wide_Wide_Text_IO Reset_Standard_Files a-zrstfi ads.
                                                               (line    6)
- * Ada_2012 configuration pragma:         Implementation of Ada 2012 Features.
-                                                              (line    6)
  * Address:                               RM 13 5 3 7-8 Bit Ordering.
                                                               (line   16)
  * Address <1>:                           RM 13 7 37 Address as Private.
--- 24931,24936 ----
*************** Index
*** 25218,25230 ****
                                                               (line    6)
  * Asm_Output:                            Attribute Asm_Output.
                                                               (line    6)
  * Assertions:                            Pragma Check.       (line    6)
  * Assertions <1>:                        Pragma Check_Policy.
                                                               (line    6)
  * Assertions <2>:                        System Assertions s-assert ads.
                                                               (line    6)
- * Assert_Failure:                        System Assertions s-assert ads.
-                                                              (line    6)
  * Async_Readers:                         Aspect Async_Readers.
                                                               (line    6)
  * Async_Writers:                         Aspect Async_Writers.
--- 25218,25230 ----
                                                               (line    6)
  * Asm_Output:                            Attribute Asm_Output.
                                                               (line    6)
+ * Assert_Failure:                        System Assertions s-assert ads.
+                                                              (line    6)
  * Assertions:                            Pragma Check.       (line    6)
  * Assertions <1>:                        Pragma Check_Policy.
                                                               (line    6)
  * Assertions <2>:                        System Assertions s-assert ads.
                                                               (line    6)
  * Async_Readers:                         Aspect Async_Readers.
                                                               (line    6)
  * Async_Writers:                         Aspect Async_Writers.
*************** Index
*** 25308,25314 ****
                                                               (line    6)
  * CGI (Common Gateway Interface) debugging: GNAT CGI Debug g-cgideb ads.
                                                               (line    6)
! * Character handling (‘‘GNAT.Case_Util‘‘): GNAT Case_Util g-casuti ads.
                                                               (line    6)
  * Character Sets:                        RM 2 8 17-19 Pragmas.
                                                               (line   17)
--- 25308,25314 ----
                                                               (line    6)
  * CGI (Common Gateway Interface) debugging: GNAT CGI Debug g-cgideb ads.
                                                               (line    6)
! * Character handling (''GNAT.Case_Util''): GNAT Case_Util g-casuti ads.
                                                               (line    6)
  * Character Sets:                        RM 2 8 17-19 Pragmas.
                                                               (line   17)
*************** Index
*** 25470,25476 ****
                                                               (line    6)
  * Dump Memory:                           GNAT Memory_Dump g-memdum ads.
                                                               (line    6)
! * Duration’Small:                        RM 3 6 2 11 Multidimensional Arrays.
                                                               (line   14)
  * effect on representation:              Effect of Convention on Representation.
                                                               (line    6)
--- 25470,25476 ----
                                                               (line    6)
  * Dump Memory:                           GNAT Memory_Dump g-memdum ads.
                                                               (line    6)
! * Duration'Small:                        RM 3 6 2 11 Multidimensional Arrays.
                                                               (line   14)
  * effect on representation:              Effect of Convention on Representation.
                                                               (line    6)
*************** Index
*** 25478,25493 ****
                                                               (line    6)
  * Effective_Writes:                      Aspect Effective_Writes.
                                                               (line    6)
- * Elaborated:                            Attribute Elaborated.
-                                                              (line    6)
- * Elaboration control:                   Pragma Elaboration_Checks.
-                                                              (line    6)
  * Elab_Body:                             Attribute Elab_Body.
                                                               (line    6)
  * Elab_Spec:                             Attribute Elab_Spec.
                                                               (line    6)
  * Elab_Subp_Body:                        Attribute Elab_Subp_Body.
                                                               (line    6)
  * Elimination of unused subprograms:     Pragma Eliminate.   (line    6)
  * Emax:                                  Attribute Emax.     (line    6)
  * Enabled:                               Attribute Enabled.  (line    6)
--- 25478,25493 ----
                                                               (line    6)
  * Effective_Writes:                      Aspect Effective_Writes.
                                                               (line    6)
  * Elab_Body:                             Attribute Elab_Body.
                                                               (line    6)
  * Elab_Spec:                             Attribute Elab_Spec.
                                                               (line    6)
  * Elab_Subp_Body:                        Attribute Elab_Subp_Body.
                                                               (line    6)
+ * Elaborated:                            Attribute Elaborated.
+                                                              (line    6)
+ * Elaboration control:                   Pragma Elaboration_Checks.
+                                                              (line    6)
  * Elimination of unused subprograms:     Pragma Eliminate.   (line    6)
  * Emax:                                  Attribute Emax.     (line    6)
  * Enabled:                               Attribute Enabled.  (line    6)
*************** Index
*** 25504,25517 ****
                                                               (line    6)
  * Entry queuing policies:                RM D 3 17 Locking Policies.
                                                               (line   12)
  * enumeration:                           RM 13 3 71-73 Component Size Clauses.
                                                               (line   23)
  * Enumeration representation clauses:    RM 13 3 71-73 Component Size Clauses.
                                                               (line   24)
  * Enumeration values:                    RM 3 5 4 29 Integer Types.
                                                               (line   12)
- * Enum_Rep:                              Attribute Enum_Rep. (line    6)
- * Enum_Val:                              Attribute Enum_Val. (line    6)
  * Environment entries:                   Ada Command_Line Environment a-colien ads.
                                                               (line    6)
  * Epsilon:                               Attribute Epsilon.  (line    6)
--- 25504,25517 ----
                                                               (line    6)
  * Entry queuing policies:                RM D 3 17 Locking Policies.
                                                               (line   12)
+ * Enum_Rep:                              Attribute Enum_Rep. (line    6)
+ * Enum_Val:                              Attribute Enum_Val. (line    6)
  * enumeration:                           RM 13 3 71-73 Component Size Clauses.
                                                               (line   23)
  * Enumeration representation clauses:    RM 13 3 71-73 Component Size Clauses.
                                                               (line   24)
  * Enumeration values:                    RM 3 5 4 29 Integer Types.
                                                               (line   12)
  * Environment entries:                   Ada Command_Line Environment a-colien ads.
                                                               (line    6)
  * Epsilon:                               Attribute Epsilon.  (line    6)
*************** Index
*** 25531,25546 ****
                                                               (line    6)
  * Exception traces:                      GNAT Exception_Traces g-exctra ads.
                                                               (line    6)
! * Exceptions:                            GNAT Exceptions g-except ads.
!                                                              (line    6)
! * exceptions:                            GNAT Exceptions g-except ads.
!                                                              (line    6)
! * Exception_Information’:                Exception_Information.
                                                               (line    6)
  * Exception_Message:                     Pragma Prefix_Exception_Messages.
                                                               (line    6)
  * Exception_Message <1>:                 Exception_Message.  (line    6)
  * Exception_Name:                        Exception_Name.     (line    6)
  * Export:                                RM A 18 Containers. (line   17)
  * Export <1>:                            Address Clauses.    (line  116)
  * extendable:                            GNAT Dynamic_Tables g-dyntab ads.
--- 25531,25546 ----
                                                               (line    6)
  * Exception traces:                      GNAT Exception_Traces g-exctra ads.
                                                               (line    6)
! * Exception_Information':                Exception_Information.
                                                               (line    6)
  * Exception_Message:                     Pragma Prefix_Exception_Messages.
                                                               (line    6)
  * Exception_Message <1>:                 Exception_Message.  (line    6)
  * Exception_Name:                        Exception_Name.     (line    6)
+ * Exceptions:                            GNAT Exceptions g-except ads.
+                                                              (line    6)
+ * exceptions:                            GNAT Exceptions g-except ads.
+                                                              (line    6)
  * Export:                                RM A 18 Containers. (line   17)
  * Export <1>:                            Address Clauses.    (line  116)
  * extendable:                            GNAT Dynamic_Tables g-dyntab ads.
*************** Index
*** 25678,25689 ****
                                                               (line    6)
  * GNAT.Encode_UTF8_String (g-enutst.ads): GNAT Encode_UTF8_String g-enutst ads.
                                                               (line    6)
- * GNAT.Exceptions (g-except.ads):        GNAT Exceptions g-except ads.
-                                                              (line    6)
  * GNAT.Exception_Actions (g-excact.ads): GNAT Exception_Actions g-excact ads.
                                                               (line    6)
  * GNAT.Exception_Traces (g-exctra.ads):  GNAT Exception_Traces g-exctra ads.
                                                               (line    6)
  * GNAT.Expect (g-expect.ads):            GNAT Expect g-expect ads.
                                                               (line    6)
  * GNAT.Expect.TTY (g-exptty.ads):        GNAT Expect TTY g-exptty ads.
--- 25678,25689 ----
                                                               (line    6)
  * GNAT.Encode_UTF8_String (g-enutst.ads): GNAT Encode_UTF8_String g-enutst ads.
                                                               (line    6)
  * GNAT.Exception_Actions (g-excact.ads): GNAT Exception_Actions g-excact ads.
                                                               (line    6)
  * GNAT.Exception_Traces (g-exctra.ads):  GNAT Exception_Traces g-exctra ads.
                                                               (line    6)
+ * GNAT.Exceptions (g-except.ads):        GNAT Exceptions g-except ads.
+                                                              (line    6)
  * GNAT.Expect (g-expect.ads):            GNAT Expect g-expect ads.
                                                               (line    6)
  * GNAT.Expect.TTY (g-exptty.ads):        GNAT Expect TTY g-exptty ads.
*************** Index
*** 25769,25780 ****
  * GNAT.SSE (g-sse.ads):                  GNAT SSE g-sse ads. (line    6)
  * GNAT.SSE.Vector_Types (g-ssvety.ads):  GNAT SSE Vector_Types g-ssvety ads.
                                                               (line    6)
- * GNAT.Strings (g-string.ads):           GNAT Strings g-string ads.
-                                                              (line    6)
  * GNAT.String_Hash (g-strhas.ads):       GNAT String_Hash g-strhas ads.
                                                               (line    6)
  * GNAT.String_Split (g-strspl.ads):      GNAT String_Split g-strspl ads.
                                                               (line    6)
  * GNAT.Table (g-table.ads):              GNAT Table g-table ads.
                                                               (line    6)
  * GNAT.Task_Lock (g-tasloc.ads):         GNAT Task_Lock g-tasloc ads.
--- 25769,25780 ----
  * GNAT.SSE (g-sse.ads):                  GNAT SSE g-sse ads. (line    6)
  * GNAT.SSE.Vector_Types (g-ssvety.ads):  GNAT SSE Vector_Types g-ssvety ads.
                                                               (line    6)
  * GNAT.String_Hash (g-strhas.ads):       GNAT String_Hash g-strhas ads.
                                                               (line    6)
  * GNAT.String_Split (g-strspl.ads):      GNAT String_Split g-strspl ads.
                                                               (line    6)
+ * GNAT.Strings (g-string.ads):           GNAT Strings g-string ads.
+                                                              (line    6)
  * GNAT.Table (g-table.ads):              GNAT Table g-table ads.
                                                               (line    6)
  * GNAT.Task_Lock (g-tasloc.ads):         GNAT Task_Lock g-tasloc ads.
*************** Index
*** 25803,25808 ****
--- 25803,25814 ----
                                                               (line    6)
  * Handling of Records with Holes:        Handling of Records with Holes.
                                                               (line    6)
+ * Has_Access_Values:                     Attribute Has_Access_Values.
+                                                              (line    6)
+ * Has_Discriminants:                     Attribute Has_Discriminants.
+                                                              (line    6)
+ * Has_Tagged_Values:                     Attribute Has_Tagged_Values.
+                                                              (line    6)
  * Hash functions:                        GNAT Perfect_Hash_Generators g-pehage ads.
                                                               (line    6)
  * Hash functions <1>:                    GNAT String_Hash g-strhas ads.
*************** Index
*** 25811,25822 ****
                                                               (line    6)
  * Hash tables <1>:                       GNAT HTable g-htable ads.
                                                               (line    6)
- * Has_Access_Values:                     Attribute Has_Access_Values.
-                                                              (line    6)
- * Has_Discriminants:                     Attribute Has_Discriminants.
-                                                              (line    6)
- * Has_Tagged_Values:                     Attribute Has_Tagged_Values.
-                                                              (line    6)
  * Heap usage:                            RM 13 9 14-17 Unchecked Conversion.
                                                               (line   34)
  * I/O interfacing:                       Interfaces VxWorks IO i-vxwoio ads.
--- 25817,25822 ----
*************** Index
*** 25832,25844 ****
  * implicit:                              RM 13 9 14-17 Unchecked Conversion.
                                                               (line   33)
  * Import:                                Address Clauses.    (line  121)
  * Initialization:                        Pragma Suppress_Initialization.
                                                               (line    6)
  * Initialized:                           Attribute Initialized.
                                                               (line    6)
  * Initializes:                           Aspect Initializes. (line    6)
- * Initial_Condition:                     Aspect Initial_Condition.
-                                                              (line    6)
  * Inline_Always:                         Aspect Inline_Always.
                                                               (line    6)
  * Input/Output facilities:               GNAT IO g-io ads.   (line    6)
--- 25832,25844 ----
  * implicit:                              RM 13 9 14-17 Unchecked Conversion.
                                                               (line   33)
  * Import:                                Address Clauses.    (line  121)
+ * Initial_Condition:                     Aspect Initial_Condition.
+                                                              (line    6)
  * Initialization:                        Pragma Suppress_Initialization.
                                                               (line    6)
  * Initialized:                           Attribute Initialized.
                                                               (line    6)
  * Initializes:                           Aspect Initializes. (line    6)
  * Inline_Always:                         Aspect Inline_Always.
                                                               (line    6)
  * Input/Output facilities:               GNAT IO g-io ads.   (line    6)
*************** Index
*** 25877,25883 ****
                                                               (line    6)
  * Interfacing to VxWorks <1>:            Interfaces VxWorks Int_Connection i-vxinco ads.
                                                               (line    6)
! * Interfacing to VxWorks’ I/O:           Interfaces VxWorks IO i-vxwoio ads.
                                                               (line    6)
  * interfacing with:                      RM B 2 12-13 Package Interfaces.
                                                               (line   21)
--- 25877,25883 ----
                                                               (line    6)
  * Interfacing to VxWorks <1>:            Interfaces VxWorks Int_Connection i-vxinco ads.
                                                               (line    6)
! * Interfacing to VxWorks' I/O:           Interfaces VxWorks IO i-vxwoio ads.
                                                               (line    6)
  * interfacing with:                      RM B 2 12-13 Package Interfaces.
                                                               (line   21)
*************** Index
*** 25885,25890 ****
--- 25885,25896 ----
                                                               (line   57)
  * interfacing with <2>:                  RM B 4 95-98 Interfacing with COBOL.
                                                               (line   27)
+ * Interfacing with ''Text_IO'':          Ada Text_IO C_Streams a-tiocst ads.
+                                                              (line    6)
+ * Interfacing with ''Wide_Text_IO'':     Ada Wide_Text_IO C_Streams a-wtcstr ads.
+                                                              (line    6)
+ * Interfacing with ''Wide_Wide_Text_IO'': Ada Wide_Wide_Text_IO C_Streams a-ztcstr ads.
+                                                              (line    6)
  * Interfacing with C++:                  Pragma CPP_Class.   (line    6)
  * Interfacing with C++ <1>:              Pragma CPP_Constructor.
                                                               (line    6)
*************** Index
*** 25895,25906 ****
                                                               (line    6)
  * Interfacing with Stream_IO:            Ada Streams Stream_IO C_Streams a-ssicst ads.
                                                               (line    6)
- * Interfacing with ‘‘Text_IO‘‘:          Ada Text_IO C_Streams a-tiocst ads.
-                                                              (line    6)
- * Interfacing with ‘‘Wide_Text_IO‘‘:     Ada Wide_Text_IO C_Streams a-wtcstr ads.
-                                                              (line    6)
- * Interfacing with ‘‘Wide_Wide_Text_IO‘‘: Ada Wide_Wide_Text_IO C_Streams a-ztcstr ads.
-                                                              (line    6)
  * Interrupt:                             GNAT Ctrl_C g-ctrl_c ads.
                                                               (line    6)
  * Interrupt support:                     RM C 1 10-16 Access to Machine Operations.
--- 25901,25906 ----
*************** Index
*** 25918,25924 ****
  * Invalid_Value:                         Attribute Invalid_Value.
                                                               (line    6)
  * Invariant:                             Aspect Invariant.   (line    6)
! * Invariant’Class:                       Aspect Invariant’Class.
                                                               (line    6)
  * IO support:                            Ada Strings Unbounded Text_IO a-suteio ads.
                                                               (line    6)
--- 25918,25924 ----
  * Invalid_Value:                         Attribute Invalid_Value.
                                                               (line    6)
  * Invariant:                             Aspect Invariant.   (line    6)
! * Invariant'Class:                       Aspect Invariant’Class.
                                                               (line    6)
  * IO support:                            Ada Strings Unbounded Text_IO a-suteio ads.
                                                               (line    6)
*************** Index
*** 25929,25935 ****
  * Iterable:                              Aspect Iterable.    (line    6)
  * Iterable <1>:                          Attribute Iterable. (line    6)
  * Large:                                 Attribute Large.    (line    6)
- * Latin-1:                               Changed semantics.  (line   12)
  * Latin_1 constants for Wide_Character:  Ada Characters Wide_Latin_1 a-cwila1 ads.
                                                               (line    6)
  * Latin_1 constants for Wide_Wide_Character: Ada Characters Wide_Wide_Latin_1 a-chzla1 ads.
--- 25929,25934 ----
*************** Index
*** 25940,25945 ****
--- 25939,25945 ----
                                                               (line    6)
  * Latin_9 constants for Wide_Wide_Character: Ada Characters Wide_Wide_Latin_9 a-chzla9 ads.
                                                               (line    6)
+ * Latin-1:                               Changed semantics.  (line   12)
  * Library_Level:                         Attribute Library_Level.
                                                               (line    6)
  * License checking:                      Pragma License.     (line    6)
*************** Index
*** 25954,25966 ****
                                                               (line    6)
  * Local storage pool:                    System Pool_Local s-pooloc ads.
                                                               (line    6)
  * Locking:                               GNAT Task_Lock g-tasloc ads.
                                                               (line    6)
  * Locking Policies:                      RM C 7 2 30 The Package Task_Attributes.
                                                               (line   17)
  * Locking using files:                   GNAT Lock_Files g-locfil ads.
                                                               (line    6)
- * Lock_Free:                             Aspect Lock_Free.   (line    6)
  * Loop_Entry:                            Attribute Loop_Entry.
                                                               (line    6)
  * Machine Code insertions:               Machine Code Insertions.
--- 25954,25966 ----
                                                               (line    6)
  * Local storage pool:                    System Pool_Local s-pooloc ads.
                                                               (line    6)
+ * Lock_Free:                             Aspect Lock_Free.   (line    6)
  * Locking:                               GNAT Task_Lock g-tasloc ads.
                                                               (line    6)
  * Locking Policies:                      RM C 7 2 30 The Package Task_Attributes.
                                                               (line   17)
  * Locking using files:                   GNAT Lock_Files g-locfil ads.
                                                               (line    6)
  * Loop_Entry:                            Attribute Loop_Entry.
                                                               (line    6)
  * Machine Code insertions:               Machine Code Insertions.
*************** Index
*** 25978,25988 ****
                                                               (line    6)
  * Mathematical functions:                GNAT Generic_Fast_Math_Functions g-gfmafu ads.
                                                               (line    6)
- * maximum:                               Attribute Maximum_Alignment.
-                                                              (line    6)
- * Maximum_Alignment:                     Attribute Maximum_Alignment.
-                                                              (line    6)
- * Maximum_Alignment attribute:           Alignment Clauses.  (line   21)
  * Max_Asynchronous_Select_Nesting:       Max_Asynchronous_Select_Nesting.
                                                               (line    6)
  * Max_Entry_Queue_Depth:                 Max_Entry_Queue_Length.
--- 25978,25983 ----
*************** Index
*** 25999,26006 ****
                                                               (line    6)
  * Max_Storage_At_Blocking:               Max_Storage_At_Blocking.
                                                               (line    6)
- * Max_Tasks:                             Max_Tasks.          (line    6)
  * Max_Task_Entries:                      Max_Task_Entries.   (line    6)
  * Mechanism_Code:                        Attribute Mechanism_Code.
                                                               (line    6)
  * Memory allocation:                     System Memory s-memory ads.
--- 25994,26006 ----
                                                               (line    6)
  * Max_Storage_At_Blocking:               Max_Storage_At_Blocking.
                                                               (line    6)
  * Max_Task_Entries:                      Max_Task_Entries.   (line    6)
+ * Max_Tasks:                             Max_Tasks.          (line    6)
+ * maximum:                               Attribute Maximum_Alignment.
+                                                              (line    6)
+ * Maximum_Alignment:                     Attribute Maximum_Alignment.
+                                                              (line    6)
+ * Maximum_Alignment attribute:           Alignment Clauses.  (line   21)
  * Mechanism_Code:                        Attribute Mechanism_Code.
                                                               (line    6)
  * Memory allocation:                     System Memory s-memory ads.
*************** Index
*** 26067,26079 ****
  * No_Entry_Queue:                        No_Entry_Queue.     (line    6)
  * No_Enumeration_Maps:                   No_Enumeration_Maps.
                                                               (line    6)
- * No_Exceptions:                         No_Exceptions.      (line    6)
  * No_Exception_Handlers:                 No_Exception_Handlers.
                                                               (line    6)
  * No_Exception_Propagation:              No_Exception_Propagation.
                                                               (line    6)
  * No_Exception_Registration:             No_Exception_Registration.
                                                               (line    6)
  * No_Finalization:                       No_Finalization.    (line    6)
  * No_Fixed_Point:                        No_Fixed_Point.     (line    6)
  * No_Floating_Point:                     No_Floating_Point.  (line    6)
--- 26067,26079 ----
  * No_Entry_Queue:                        No_Entry_Queue.     (line    6)
  * No_Enumeration_Maps:                   No_Enumeration_Maps.
                                                               (line    6)
  * No_Exception_Handlers:                 No_Exception_Handlers.
                                                               (line    6)
  * No_Exception_Propagation:              No_Exception_Propagation.
                                                               (line    6)
  * No_Exception_Registration:             No_Exception_Registration.
                                                               (line    6)
+ * No_Exceptions:                         No_Exceptions.      (line    6)
  * No_Finalization:                       No_Finalization.    (line    6)
  * No_Fixed_Point:                        No_Fixed_Point.     (line    6)
  * No_Floating_Point:                     No_Floating_Point.  (line    6)
*************** Index
*** 26122,26130 ****
                                                               (line    6)
  * No_Obsolescent_Features:               No_Obsolescent_Features.
                                                               (line    6)
- * No_Protected_Types:                    No_Protected_Types. (line    6)
  * No_Protected_Type_Allocators:          No_Protected_Type_Allocators.
                                                               (line    6)
  * No_Recursion:                          No_Recursion.       (line    6)
  * No_Reentrancy:                         No_Reentrancy.      (line    6)
  * No_Relative_Delay:                     No_Relative_Delay.  (line    6)
--- 26122,26130 ----
                                                               (line    6)
  * No_Obsolescent_Features:               No_Obsolescent_Features.
                                                               (line    6)
  * No_Protected_Type_Allocators:          No_Protected_Type_Allocators.
                                                               (line    6)
+ * No_Protected_Types:                    No_Protected_Types. (line    6)
  * No_Recursion:                          No_Recursion.       (line    6)
  * No_Reentrancy:                         No_Reentrancy.      (line    6)
  * No_Relative_Delay:                     No_Relative_Delay.  (line    6)
*************** Index
*** 26135,26168 ****
  * No_Secondary_Stack:                    No_Secondary_Stack. (line    6)
  * No_Select_Statements:                  No_Select_Statements.
                                                               (line    6)
- * No_Specification_of_Aspect:            No_Specification_of_Aspect.
-                                                              (line    6)
  * No_Specific_Termination_Handlers:      No_Specific_Termination_Handlers.
                                                               (line    6)
  * No_Standard_Allocators_After_Elaboration: No_Standard_Allocators_After_Elaboration.
                                                               (line    6)
  * No_Standard_Storage_Pools:             No_Standard_Storage_Pools.
                                                               (line    6)
- * No_Streams:                            No_Streams.         (line    6)
  * No_Stream_Optimizations:               No_Stream_Optimizations.
                                                               (line    6)
  * No_Tagged_Streams:                     Aspect No_Tagged_Streams.
                                                               (line    6)
  * No_Tagged_Type_Registration:           No_Tagged_Type_Registration.
                                                               (line    6)
- * No_Tasking:                            No_Tasking.         (line    6)
  * No_Task_Allocators:                    No_Task_Allocators. (line    6)
  * No_Task_Attributes:                    No_Task_Attributes_Package.
                                                               (line    9)
  * No_Task_Attributes_Package:            No_Task_Attributes_Package.
                                                               (line    6)
- * No_Task_At_Interrupt_Priority:         No_Task_At_Interrupt_Priority.
-                                                              (line    6)
  * No_Task_Hierarchy:                     No_Task_Hierarchy.  (line    6)
  * No_Task_Parts:                         Aspect No_Task_Parts.
                                                               (line    6)
  * No_Task_Termination:                   No_Task_Termination.
                                                               (line    6)
  * No_Terminate_Alternatives:             No_Terminate_Alternatives.
                                                               (line    6)
  * No_Unchecked_Access:                   No_Unchecked_Access.
--- 26135,26168 ----
  * No_Secondary_Stack:                    No_Secondary_Stack. (line    6)
  * No_Select_Statements:                  No_Select_Statements.
                                                               (line    6)
  * No_Specific_Termination_Handlers:      No_Specific_Termination_Handlers.
                                                               (line    6)
+ * No_Specification_of_Aspect:            No_Specification_of_Aspect.
+                                                              (line    6)
  * No_Standard_Allocators_After_Elaboration: No_Standard_Allocators_After_Elaboration.
                                                               (line    6)
  * No_Standard_Storage_Pools:             No_Standard_Storage_Pools.
                                                               (line    6)
  * No_Stream_Optimizations:               No_Stream_Optimizations.
                                                               (line    6)
+ * No_Streams:                            No_Streams.         (line    6)
  * No_Tagged_Streams:                     Aspect No_Tagged_Streams.
                                                               (line    6)
  * No_Tagged_Type_Registration:           No_Tagged_Type_Registration.
                                                               (line    6)
  * No_Task_Allocators:                    No_Task_Allocators. (line    6)
+ * No_Task_At_Interrupt_Priority:         No_Task_At_Interrupt_Priority.
+                                                              (line    6)
  * No_Task_Attributes:                    No_Task_Attributes_Package.
                                                               (line    9)
  * No_Task_Attributes_Package:            No_Task_Attributes_Package.
                                                               (line    6)
  * No_Task_Hierarchy:                     No_Task_Hierarchy.  (line    6)
  * No_Task_Parts:                         Aspect No_Task_Parts.
                                                               (line    6)
  * No_Task_Termination:                   No_Task_Termination.
                                                               (line    6)
+ * No_Tasking:                            No_Tasking.         (line    6)
  * No_Terminate_Alternatives:             No_Terminate_Alternatives.
                                                               (line    6)
  * No_Unchecked_Access:                   No_Unchecked_Access.
*************** Index
*** 26199,26205 ****
  * of objects:                            Value_Size and Object_Size Clauses.
                                                               (line    6)
  * Old:                                   Attribute Old.      (line    6)
! * on ‘‘Address‘‘:                        RM 13 7 37 Address as Private.
                                                               (line   10)
  * Operating System interface:            GNAT OS_Lib g-os_lib ads.
                                                               (line    6)
--- 26199,26205 ----
  * of objects:                            Value_Size and Object_Size Clauses.
                                                               (line    6)
  * Old:                                   Attribute Old.      (line    6)
! * on ''Address'':                        RM 13 7 37 Address as Private.
                                                               (line   10)
  * Operating System interface:            GNAT OS_Lib g-os_lib ads.
                                                               (line    6)
*************** Index
*** 26211,26222 ****
  * ordering <1>:                          Effect of Bit_Order on Byte Ordering.
                                                               (line    6)
  * Overlaying of objects:                 Address Clauses.    (line  170)
  * Package Interfaces:                    RM B 1 39-41 Pragma Export.
                                                               (line   35)
  * Package Task_Attributes:               RM C 5 8 Pragma Discard_Names.
                                                               (line   12)
- * Package ‘‘Interrupts‘‘:                RM C 3 1 20-21 Protected Procedure Handlers.
-                                                              (line   17)
  * Packed Decimal:                        Interfaces Packed_Decimal i-pacdec ads.
                                                               (line    6)
  * Packed types:                          RM 13 1 21-24 Representation Clauses.
--- 26211,26222 ----
  * ordering <1>:                          Effect of Bit_Order on Byte Ordering.
                                                               (line    6)
  * Overlaying of objects:                 Address Clauses.    (line  170)
+ * Package ''Interrupts'':                RM C 3 1 20-21 Protected Procedure Handlers.
+                                                              (line   17)
  * Package Interfaces:                    RM B 1 39-41 Pragma Export.
                                                               (line   35)
  * Package Task_Attributes:               RM C 5 8 Pragma Discard_Names.
                                                               (line   12)
  * Packed Decimal:                        Interfaces Packed_Decimal i-pacdec ads.
                                                               (line    6)
  * Packed types:                          RM 13 1 21-24 Representation Clauses.
*************** Index
*** 26230,26240 ****
                                                               (line    6)
  * Parsing <2>:                           GNAT Bounded_Mailboxes g-boumai ads.
                                                               (line    6)
  * Partition communication subsystem:     RM D 8 47-49 Monotonic Time.
                                                               (line   23)
  * Partition interfacing functions:       System Partition_Interface s-parint ads.
                                                               (line    6)
- * Part_Of:                               Aspect Part_Of.     (line    6)
  * Passed_By_Reference:                   Attribute Passed_By_Reference.
                                                               (line    6)
  * passing:                               Attribute Null_Parameter.
--- 26230,26240 ----
                                                               (line    6)
  * Parsing <2>:                           GNAT Bounded_Mailboxes g-boumai ads.
                                                               (line    6)
+ * Part_Of:                               Aspect Part_Of.     (line    6)
  * Partition communication subsystem:     RM D 8 47-49 Monotonic Time.
                                                               (line   23)
  * Partition interfacing functions:       System Partition_Interface s-parint ads.
                                                               (line    6)
  * Passed_By_Reference:                   Attribute Passed_By_Reference.
                                                               (line    6)
  * passing:                               Attribute Null_Parameter.
*************** Index
*** 26287,26292 ****
--- 26287,26293 ----
  * Pragmas <1>:                           RM 1 1 5 12 Bounded Errors.
                                                               (line   12)
  * Pre:                                   Pragma Pre.         (line    6)
+ * Pre_Class:                             Pragma Pre_Class.   (line    6)
  * Pre-elaboration requirements:          RM C 3 2 25 Package Interrupts.
                                                               (line   14)
  * preconditions:                         Pragma Pre.         (line    6)
*************** Index
*** 26300,26306 ****
                                                               (line   10)
  * Prefix_Exception_Messages:             Pragma Prefix_Exception_Messages.
                                                               (line    6)
- * Pre_Class:                             Pragma Pre_Class.   (line    6)
  * Protected procedure handlers:          RM C 3 28 Interrupt Support.
                                                               (line   14)
  * Pure:                                  GNAT Exceptions g-except ads.
--- 26301,26306 ----
*************** Index
*** 26384,26395 ****
                                                               (line    6)
  * Response file for command line:        Ada Command_Line Response_File a-clrefi ads.
                                                               (line    6)
  * Restrictions:                          Attribute Restriction_Set.
                                                               (line    6)
  * Restrictions definitions:              System Rident s-rident ads.
                                                               (line    6)
- * Restriction_Set:                       Attribute Restriction_Set.
-                                                              (line    6)
  * Result:                                Attribute Result.   (line    6)
  * Return values:                         Attribute Mechanism_Code.
                                                               (line    6)
--- 26384,26395 ----
                                                               (line    6)
  * Response file for command line:        Ada Command_Line Response_File a-clrefi ads.
                                                               (line    6)
+ * Restriction_Set:                       Attribute Restriction_Set.
+                                                              (line    6)
  * Restrictions:                          Attribute Restriction_Set.
                                                               (line    6)
  * Restrictions definitions:              System Rident s-rident ads.
                                                               (line    6)
  * Result:                                Attribute Result.   (line    6)
  * Return values:                         Attribute Mechanism_Code.
                                                               (line    6)
*************** Index
*** 26484,26490 ****
                                                               (line   40)
  * Size for biased representation:        Biased Representation.
                                                               (line    6)
! * Size of ‘‘Address‘‘:                   Attribute Address_Size.
                                                               (line    6)
  * Small:                                 Attribute Small.    (line    6)
  * Small <1>:                             Attribute Small_Denominator.
--- 26484,26490 ----
                                                               (line   40)
  * Size for biased representation:        Biased Representation.
                                                               (line    6)
! * Size of ''Address'':                   Attribute Address_Size.
                                                               (line    6)
  * Small:                                 Attribute Small.    (line    6)
  * Small <1>:                             Attribute Small_Denominator.
*************** Index
*** 26580,26585 ****
--- 26580,26589 ----
  * Subprogram address:                    Attribute Code_Address.
                                                               (line    6)
  * subtypes:                              Alignment Clauses.  (line   87)
+ * Suppress_Debug_Info:                   Aspect Suppress_Debug_Info.
+                                                              (line    6)
+ * Suppress_Initialization:               Aspect Suppress_Initialization.
+                                                              (line    6)
  * Suppressing external name:             Pragma Export_Function.
                                                               (line   59)
  * Suppressing external name <1>:         Pragma Export_Procedure.
*************** Index
*** 26594,26609 ****
                                                               (line   22)
  * Suppression of checks:                 RM 11 4 1 19 Exception Information.
                                                               (line   23)
- * Suppress_Debug_Info:                   Aspect Suppress_Debug_Info.
-                                                              (line    6)
- * Suppress_Initialization:               Aspect Suppress_Initialization.
-                                                              (line    6)
  * synonyms:                              Pragma Convention_Identifier.
                                                               (line    6)
  * synonyms <1>:                          Pragma Rename_Pragma.
                                                               (line    6)
  * System:                                Pragma Extend_System.
                                                               (line    6)
  * System.Address_Image (s-addima.ads):   System Address_Image s-addima ads.
                                                               (line    6)
  * System.Assertions (s-assert.ads):      System Assertions s-assert ads.
--- 26598,26611 ----
                                                               (line   22)
  * Suppression of checks:                 RM 11 4 1 19 Exception Information.
                                                               (line   23)
  * synonyms:                              Pragma Convention_Identifier.
                                                               (line    6)
  * synonyms <1>:                          Pragma Rename_Pragma.
                                                               (line    6)
  * System:                                Pragma Extend_System.
                                                               (line    6)
+ * System_Allocator_Alignment:            Attribute System_Allocator_Alignment.
+                                                              (line    6)
  * System.Address_Image (s-addima.ads):   System Address_Image s-addima ads.
                                                               (line    6)
  * System.Assertions (s-assert.ads):      System Assertions s-assert ads.
*************** Index
*** 26634,26641 ****
                                                               (line    6)
  * System.Wch_Con (s-wchcon.ads):         System Wch_Con s-wchcon ads.
                                                               (line    6)
- * System_Allocator_Alignment:            Attribute System_Allocator_Alignment.
-                                                              (line    6)
  * Table implementation:                  GNAT Dynamic_Tables g-dyntab ads.
                                                               (line    6)
  * Table implementation <1>:              GNAT Table g-table ads.
--- 26636,26641 ----
*************** Index
*** 26650,26662 ****
                                                               (line    6)
  * Task synchronization:                  GNAT Task_Lock g-tasloc ads.
                                                               (line    6)
- * Tasking restrictions:                  RM D 6 9-10 Preemptive Abort.
-                                                              (line   18)
  * Task_Attributes:                       Pragma Thread_Local_Storage.
                                                               (line    6)
  * Task_Attributes <1>:                   RM C 5 8 Pragma Discard_Names.
                                                               (line   11)
  * Test cases:                            Pragma Test_Case.   (line    6)
  * testing for:                           Attribute Has_Access_Values.
                                                               (line    6)
  * testing for <1>:                       Attribute Has_Discriminants.
--- 26650,26663 ----
                                                               (line    6)
  * Task synchronization:                  GNAT Task_Lock g-tasloc ads.
                                                               (line    6)
  * Task_Attributes:                       Pragma Thread_Local_Storage.
                                                               (line    6)
  * Task_Attributes <1>:                   RM C 5 8 Pragma Discard_Names.
                                                               (line   11)
+ * Tasking restrictions:                  RM D 6 9-10 Preemptive Abort.
+                                                              (line   18)
  * Test cases:                            Pragma Test_Case.   (line    6)
+ * Test_Case:                             Aspect Test_Case.   (line    6)
  * testing for:                           Attribute Has_Access_Values.
                                                               (line    6)
  * testing for <1>:                       Attribute Has_Discriminants.
*************** Index
*** 26667,26673 ****
                                                               (line    6)
  * testing for <4>:                       Ada Exceptions Last_Chance_Handler a-elchha ads.
                                                               (line    6)
- * Test_Case:                             Aspect Test_Case.   (line    6)
  * Text_IO:                               Ada Strings Unbounded Text_IO a-suteio ads.
                                                               (line    6)
  * Text_IO <1>:                           Ada Strings Wide_Unbounded Wide_Text_IO a-swuwti ads.
--- 26668,26673 ----
*************** Index
*** 26683,26692 ****
                                                               (line    6)
  * Text_IO resetting standard files:      Ada Text_IO Reset_Standard_Files a-tirsfi ads.
                                                               (line    6)
- * Threads:                               GNAT Threads g-thread ads.
-                                                              (line    6)
  * Thread_Local_Storage:                  Aspect Thread_Local_Storage.
                                                               (line    6)
  * Time:                                  RM D 7 21 Tasking Restrictions.
                                                               (line   14)
  * Time <1>:                              GNAT Calendar Time_IO g-catiio ads.
--- 26683,26692 ----
                                                               (line    6)
  * Text_IO resetting standard files:      Ada Text_IO Reset_Standard_Files a-tirsfi ads.
                                                               (line    6)
  * Thread_Local_Storage:                  Aspect Thread_Local_Storage.
                                                               (line    6)
+ * Threads:                               GNAT Threads g-thread ads.
+                                                              (line    6)
  * Time:                                  RM D 7 21 Tasking Restrictions.
                                                               (line   14)
  * Time <1>:                              GNAT Calendar Time_IO g-catiio ads.
*************** Index
*** 26707,26716 ****
                                                               (line    6)
  * trampoline:                            No_Implicit_Dynamic_Code.
                                                               (line    6)
- * TypeCode:                              Attribute TypeCode. (line    6)
  * Type_Class:                            Attribute Type_Class.
                                                               (line    6)
  * Type_Key:                              Attribute Type_Key. (line    6)
  * typographical:                         Conventions.        (line    6)
  * Typographical conventions:             Conventions.        (line    6)
  * Unbounded_String:                      Text_IO Facilities for Unbounded Strings.
--- 26707,26716 ----
                                                               (line    6)
  * trampoline:                            No_Implicit_Dynamic_Code.
                                                               (line    6)
  * Type_Class:                            Attribute Type_Class.
                                                               (line    6)
  * Type_Key:                              Attribute Type_Key. (line    6)
+ * TypeCode:                              Attribute TypeCode. (line    6)
  * typographical:                         Conventions.        (line    6)
  * Typographical conventions:             Conventions.        (line    6)
  * Unbounded_String:                      Text_IO Facilities for Unbounded Strings.
*************** Tag Table:
*** 26870,29890 ****
  Node: Top326
  Ref: gnat_rm doc554
  Ref: 0554
! Node: About This Guide33140
! Ref: gnat_rm/about_this_guide doc33248
! Ref: 233248
! Ref: gnat_rm/about_this_guide about-this-guide33248
! Ref: 333248
! Ref: gnat_rm/about_this_guide gnat-reference-manual33248
! Ref: 433248
! Ref: gnat_rm/about_this_guide id133248
! Ref: 533248
! Node: What This Reference Manual Contains34642
! Ref: gnat_rm/about_this_guide what-this-reference-manual-contains34751
! Ref: 634751
! Node: Conventions38424
! Ref: gnat_rm/about_this_guide conventions38561
! Ref: 1838561
! Node: Related Information39132
! Ref: gnat_rm/about_this_guide related-information39225
! Ref: 1939225
! Node: Implementation Defined Pragmas40519
! Ref: gnat_rm/implementation_defined_pragmas doc40654
! Ref: 1a40654
! Ref: gnat_rm/implementation_defined_pragmas id140654
! Ref: 1b40654
! Ref: gnat_rm/implementation_defined_pragmas implementation-defined-pragmas40654
! Ref: 740654
! Node: Pragma Abort_Defer46846
! Ref: gnat_rm/implementation_defined_pragmas pragma-abort-defer46962
! Ref: 1c46962
! Node: Pragma Abstract_State47833
! Ref: gnat_rm/implementation_defined_pragmas id247971
! Ref: 1d47971
! Ref: gnat_rm/implementation_defined_pragmas pragma-abstract-state47971
! Ref: 1e47971
! Node: Pragma Ada_8349209
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-8349342
! Ref: 1f49342
! Node: Pragma Ada_9550433
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-9550558
! Ref: 2050558
! Node: Pragma Ada_0551076
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-0551203
! Ref: 2151203
! Node: Pragma Ada_200552229
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-200552356
! Ref: 2252356
! Node: Pragma Ada_1252523
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-1252652
! Ref: 2352652
! Node: Pragma Ada_201253827
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-201253956
! Ref: 2453956
! Node: Pragma Ada_202254123
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-202254275
! Ref: 2554275
! Node: Pragma Aggregate_Individually_Assign55467
! Ref: gnat_rm/implementation_defined_pragmas pragma-aggregate-individually-assign55632
! Ref: 2655632
! Node: Pragma Allow_Integer_Address56039
! Ref: gnat_rm/implementation_defined_pragmas pragma-allow-integer-address56204
! Ref: 2756204
! Node: Pragma Annotate57817
! Ref: gnat_rm/implementation_defined_pragmas id357959
! Ref: 2857959
! Ref: gnat_rm/implementation_defined_pragmas pragma-annotate57959
! Ref: 2957959
! Node: Pragma Assert59407
! Ref: gnat_rm/implementation_defined_pragmas pragma-assert59542
! Ref: 2a59542
! Node: Pragma Assert_And_Cut62052
! Ref: gnat_rm/implementation_defined_pragmas pragma-assert-and-cut62195
! Ref: 2b62195
! Node: Pragma Assertion_Policy63007
! Ref: gnat_rm/implementation_defined_pragmas pragma-assertion-policy63150
! Ref: 2c63150
! Node: Pragma Assume66888
! Ref: gnat_rm/implementation_defined_pragmas pragma-assume67041
! Ref: 2d67041
! Node: Pragma Assume_No_Invalid_Values68020
! Ref: gnat_rm/implementation_defined_pragmas pragma-assume-no-invalid-values68170
! Ref: 2e68170
! Node: Pragma Async_Readers69953
! Ref: gnat_rm/implementation_defined_pragmas id470110
! Ref: 2f70110
! Ref: gnat_rm/implementation_defined_pragmas pragma-async-readers70110
! Ref: 3070110
! Node: Pragma Async_Writers70363
! Ref: gnat_rm/implementation_defined_pragmas id570516
! Ref: 3170516
! Ref: gnat_rm/implementation_defined_pragmas pragma-async-writers70516
! Ref: 3270516
! Node: Pragma Attribute_Definition70769
! Ref: gnat_rm/implementation_defined_pragmas pragma-attribute-definition70923
! Ref: 3370923
! Node: Pragma C_Pass_By_Copy71550
! Ref: gnat_rm/implementation_defined_pragmas pragma-c-pass-by-copy71696
! Ref: 3471696
! Node: Pragma Check72878
! Ref: gnat_rm/implementation_defined_pragmas pragma-check73024
! Ref: 3573024
! Node: Pragma Check_Float_Overflow74282
! Ref: gnat_rm/implementation_defined_pragmas pragma-check-float-overflow74424
! Ref: 3674424
! Node: Pragma Check_Name76483
! Ref: gnat_rm/implementation_defined_pragmas pragma-check-name76632
! Ref: 3776632
! Node: Pragma Check_Policy77752
! Ref: gnat_rm/implementation_defined_pragmas pragma-check-policy77888
! Ref: 3877888
! Node: Pragma Comment80705
! Ref: gnat_rm/implementation_defined_pragmas pragma-comment80844
! Ref: 3980844
! Node: Pragma Common_Object81362
! Ref: gnat_rm/implementation_defined_pragmas pragma-common-object81507
! Ref: 3a81507
! Node: Pragma Compile_Time_Error82390
! Ref: gnat_rm/implementation_defined_pragmas compile-time-error82548
! Ref: 3b82548
! Ref: gnat_rm/implementation_defined_pragmas pragma-compile-time-error82548
! Ref: 3c82548
! Node: Pragma Compile_Time_Warning83618
! Ref: gnat_rm/implementation_defined_pragmas pragma-compile-time-warning83786
! Ref: 3d83786
! Node: Pragma Complete_Representation85027
! Ref: gnat_rm/implementation_defined_pragmas pragma-complete-representation85199
! Ref: 3e85199
! Node: Pragma Complex_Representation85748
! Ref: gnat_rm/implementation_defined_pragmas pragma-complex-representation85919
! Ref: 3f85919
! Node: Pragma Component_Alignment86675
! Ref: gnat_rm/implementation_defined_pragmas pragma-component-alignment86849
! Ref: 4086849
! Node: Pragma Constant_After_Elaboration89583
! Ref: gnat_rm/implementation_defined_pragmas id689749
! Ref: 4189749
! Ref: gnat_rm/implementation_defined_pragmas pragma-constant-after-elaboration89749
! Ref: 4289749
! Node: Pragma Contract_Cases90054
! Ref: gnat_rm/implementation_defined_pragmas id790222
! Ref: 4390222
! Ref: gnat_rm/implementation_defined_pragmas pragma-contract-cases90222
! Ref: 4490222
! Node: Pragma Convention_Identifier93057
! Ref: gnat_rm/implementation_defined_pragmas pragma-convention-identifier93208
! Ref: 4593208
! Node: Pragma CPP_Class94392
! Ref: gnat_rm/implementation_defined_pragmas pragma-cpp-class94544
! Ref: 4694544
! Node: Pragma CPP_Constructor95658
! Ref: gnat_rm/implementation_defined_pragmas pragma-cpp-constructor95800
! Ref: 4895800
! Node: Pragma CPP_Virtual97760
! Ref: gnat_rm/implementation_defined_pragmas pragma-cpp-virtual97903
! Ref: 4997903
! Node: Pragma CPP_Vtable98373
! Ref: gnat_rm/implementation_defined_pragmas pragma-cpp-vtable98504
! Ref: 4a98504
! Node: Pragma CPU98928
! Ref: gnat_rm/implementation_defined_pragmas pragma-cpu99062
! Ref: 4b99062
! Node: Pragma Deadline_Floor99302
! Ref: gnat_rm/implementation_defined_pragmas pragma-deadline-floor99431
! Ref: 4c99431
! Node: Pragma Debug99747
! Ref: gnat_rm/implementation_defined_pragmas pragma-debug99885
! Ref: 4d99885
! Node: Pragma Debug_Policy100841
! Ref: gnat_rm/implementation_defined_pragmas pragma-debug-policy100990
! Ref: 4e100990
! Node: Pragma Default_Initial_Condition101279
! Ref: gnat_rm/implementation_defined_pragmas id8101451
! Ref: 4f101451
! Ref: gnat_rm/implementation_defined_pragmas pragma-default-initial-condition101451
! Ref: 50101451
! Node: Pragma Default_Scalar_Storage_Order101752
! Ref: gnat_rm/implementation_defined_pragmas pragma-default-scalar-storage-order101932
! Ref: 51101932
! Node: Pragma Default_Storage_Pool104232
! Ref: gnat_rm/implementation_defined_pragmas pragma-default-storage-pool104394
! Ref: 52104394
! Node: Pragma Depends104699
! Ref: gnat_rm/implementation_defined_pragmas id9104848
! Ref: 53104848
! Ref: gnat_rm/implementation_defined_pragmas pragma-depends104848
! Ref: 54104848
! Node: Pragma Detect_Blocking105548
! Ref: gnat_rm/implementation_defined_pragmas pragma-detect-blocking105707
! Ref: 55105707
! Node: Pragma Disable_Atomic_Synchronization106096
! Ref: gnat_rm/implementation_defined_pragmas pragma-disable-atomic-synchronization106266
! Ref: 56106266
! Node: Pragma Dispatching_Domain107083
! Ref: gnat_rm/implementation_defined_pragmas pragma-dispatching-domain107253
! Ref: 57107253
! Node: Pragma Effective_Reads107538
! Ref: gnat_rm/implementation_defined_pragmas id10107694
! Ref: 58107694
! Ref: gnat_rm/implementation_defined_pragmas pragma-effective-reads107694
! Ref: 59107694
! Node: Pragma Effective_Writes107955
! Ref: gnat_rm/implementation_defined_pragmas id11108111
! Ref: 5a108111
! Ref: gnat_rm/implementation_defined_pragmas pragma-effective-writes108111
! Ref: 5b108111
! Node: Pragma Elaboration_Checks108376
! Ref: gnat_rm/implementation_defined_pragmas pragma-elaboration-checks108526
! Ref: 5c108526
! Node: Pragma Eliminate109358
! Ref: gnat_rm/implementation_defined_pragmas pragma-eliminate109521
! Ref: 5d109521
! Node: Pragma Enable_Atomic_Synchronization115253
! Ref: gnat_rm/implementation_defined_pragmas pragma-enable-atomic-synchronization115413
! Ref: 5e115413
! Node: Pragma Export_Function116329
! Ref: gnat_rm/implementation_defined_pragmas pragma-export-function116493
! Ref: 5f116493
! Node: Pragma Export_Object118949
! Ref: gnat_rm/implementation_defined_pragmas pragma-export-object119100
! Ref: 60119100
! Node: Pragma Export_Procedure119771
! Ref: gnat_rm/implementation_defined_pragmas pragma-export-procedure119930
! Ref: 61119930
! Node: Pragma Export_Valued_Procedure121428
! Ref: gnat_rm/implementation_defined_pragmas pragma-export-valued-procedure121587
! Ref: 62121587
! Node: Pragma Extend_System123440
! Ref: gnat_rm/implementation_defined_pragmas pragma-extend-system123601
! Ref: 63123601
! Node: Pragma Extensions_Allowed125663
! Ref: gnat_rm/implementation_defined_pragmas pragma-extensions-allowed125819
! Ref: 64125819
! Node: Pragma Extensions_Visible137049
! Ref: gnat_rm/implementation_defined_pragmas id12137200
! Ref: 65137200
! Ref: gnat_rm/implementation_defined_pragmas pragma-extensions-visible137200
! Ref: 66137200
! Node: Pragma External137473
! Ref: gnat_rm/implementation_defined_pragmas pragma-external137626
! Ref: 67137626
! Node: Pragma External_Name_Casing138193
! Ref: gnat_rm/implementation_defined_pragmas pragma-external-name-casing138337
! Ref: 68138337
! Node: Pragma Fast_Math141345
! Ref: gnat_rm/implementation_defined_pragmas pragma-fast-math141496
! Ref: 69141496
! Node: Pragma Favor_Top_Level142369
! Ref: gnat_rm/implementation_defined_pragmas id13142521
! Ref: 6a142521
! Ref: gnat_rm/implementation_defined_pragmas pragma-favor-top-level142521
! Ref: 6b142521
! Node: Pragma Finalize_Storage_Only143194
! Ref: gnat_rm/implementation_defined_pragmas pragma-finalize-storage-only143357
! Ref: 6c143357
! Node: Pragma Float_Representation144119
! Ref: gnat_rm/implementation_defined_pragmas pragma-float-representation144272
! Ref: 6d144272
! Node: Pragma Ghost145127
! Ref: gnat_rm/implementation_defined_pragmas id14145265
! Ref: 6e145265
! Ref: gnat_rm/implementation_defined_pragmas pragma-ghost145265
! Ref: 6f145265
! Node: Pragma Global145484
! Ref: gnat_rm/implementation_defined_pragmas id15145607
! Ref: 70145607
! Ref: gnat_rm/implementation_defined_pragmas pragma-global145607
! Ref: 71145607
! Node: Pragma Ident146154
! Ref: gnat_rm/implementation_defined_pragmas pragma-ident146285
! Ref: 72146285
! Node: Pragma Ignore_Pragma146521
! Ref: gnat_rm/implementation_defined_pragmas pragma-ignore-pragma146668
! Ref: 73146668
! Node: Pragma Implementation_Defined147288
! Ref: gnat_rm/implementation_defined_pragmas pragma-implementation-defined147441
! Ref: 74147441
! Node: Pragma Implemented148153
! Ref: gnat_rm/implementation_defined_pragmas pragma-implemented148309
! Ref: 75148309
! Node: Pragma Implicit_Packing149928
! Ref: gnat_rm/implementation_defined_pragmas pragma-implicit-packing150077
! Ref: 76150077
! Node: Pragma Import_Function151900
! Ref: gnat_rm/implementation_defined_pragmas pragma-import-function152051
! Ref: 77152051
! Node: Pragma Import_Object154164
! Ref: gnat_rm/implementation_defined_pragmas pragma-import-object154315
! Ref: 78154315
! Node: Pragma Import_Procedure155019
! Ref: gnat_rm/implementation_defined_pragmas pragma-import-procedure155178
! Ref: 79155178
! Node: Pragma Import_Valued_Procedure156110
! Ref: gnat_rm/implementation_defined_pragmas pragma-import-valued-procedure156267
! Ref: 7a156267
! Node: Pragma Independent158044
! Ref: gnat_rm/implementation_defined_pragmas pragma-independent158207
! Ref: 7b158207
! Node: Pragma Independent_Components158884
! Ref: gnat_rm/implementation_defined_pragmas pragma-independent-components159041
! Ref: 7c159041
! Node: Pragma Initial_Condition159703
! Ref: gnat_rm/implementation_defined_pragmas id16159867
! Ref: 7d159867
! Ref: gnat_rm/implementation_defined_pragmas pragma-initial-condition159867
! Ref: 7e159867
! Node: Pragma Initialize_Scalars160125
! Ref: gnat_rm/implementation_defined_pragmas pragma-initialize-scalars160278
! Ref: 7f160278
! Node: Pragma Initializes163962
! Ref: gnat_rm/implementation_defined_pragmas id17164111
! Ref: 80164111
! Ref: gnat_rm/implementation_defined_pragmas pragma-initializes164111
! Ref: 81164111
! Node: Pragma Inline_Always164597
! Ref: gnat_rm/implementation_defined_pragmas id18164742
! Ref: 82164742
! Ref: gnat_rm/implementation_defined_pragmas pragma-inline-always164742
! Ref: 83164742
! Node: Pragma Inline_Generic165382
! Ref: gnat_rm/implementation_defined_pragmas pragma-inline-generic165525
! Ref: 84165525
! Node: Pragma Interface165907
! Ref: gnat_rm/implementation_defined_pragmas pragma-interface166051
! Ref: 85166051
! Node: Pragma Interface_Name167024
! Ref: gnat_rm/implementation_defined_pragmas pragma-interface-name167171
! Ref: 86167171
! Node: Pragma Interrupt_Handler167689
! Ref: gnat_rm/implementation_defined_pragmas pragma-interrupt-handler167842
! Ref: 87167842
! Node: Pragma Interrupt_State168098
! Ref: gnat_rm/implementation_defined_pragmas pragma-interrupt-state168246
! Ref: 88168246
! Node: Pragma Invariant171446
! Ref: gnat_rm/implementation_defined_pragmas id19171587
! Ref: 89171587
! Ref: gnat_rm/implementation_defined_pragmas pragma-invariant171587
! Ref: 8a171587
! Node: Pragma Keep_Names173243
! Ref: gnat_rm/implementation_defined_pragmas pragma-keep-names173376
! Ref: 8b173376
! Node: Pragma License173992
! Ref: gnat_rm/implementation_defined_pragmas pragma-license174125
! Ref: 8c174125
! Node: Pragma Link_With177223
! Ref: gnat_rm/implementation_defined_pragmas pragma-link-with177358
! Ref: 8d177358
! Node: Pragma Linker_Alias177999
! Ref: gnat_rm/implementation_defined_pragmas pragma-linker-alias178145
! Ref: 8e178145
! Node: Pragma Linker_Constructor179424
! Ref: gnat_rm/implementation_defined_pragmas pragma-linker-constructor179578
! Ref: 8f179578
! Node: Pragma Linker_Destructor180807
! Ref: gnat_rm/implementation_defined_pragmas pragma-linker-destructor180963
! Ref: 90180963
! Node: Pragma Linker_Section181742
! Ref: gnat_rm/implementation_defined_pragmas id20181889
! Ref: 91181889
! Ref: gnat_rm/implementation_defined_pragmas pragma-linker-section181889
! Ref: 92181889
! Node: Pragma Lock_Free184938
! Ref: gnat_rm/implementation_defined_pragmas id21185082
! Ref: 93185082
! Ref: gnat_rm/implementation_defined_pragmas pragma-lock-free185082
! Ref: 94185082
! Node: Pragma Loop_Invariant186405
! Ref: gnat_rm/implementation_defined_pragmas pragma-loop-invariant186548
! Ref: 95186548
! Node: Pragma Loop_Optimize187740
! Ref: gnat_rm/implementation_defined_pragmas pragma-loop-optimize187886
! Ref: 96187886
! Node: Pragma Loop_Variant189628
! Ref: gnat_rm/implementation_defined_pragmas pragma-loop-variant189777
! Ref: 97189777
! Node: Pragma Machine_Attribute191586
! Ref: gnat_rm/implementation_defined_pragmas pragma-machine-attribute191726
! Ref: 98191726
! Node: Pragma Main192697
! Ref: gnat_rm/implementation_defined_pragmas pragma-main192837
! Ref: 99192837
! Node: Pragma Main_Storage193275
! Ref: gnat_rm/implementation_defined_pragmas pragma-main-storage193414
! Ref: 9a193414
! Node: Pragma Max_Queue_Length193821
! Ref: gnat_rm/implementation_defined_pragmas id22193963
! Ref: 9b193963
! Ref: gnat_rm/implementation_defined_pragmas pragma-max-queue-length193963
! Ref: 9c193963
! Node: Pragma No_Body194389
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-body194529
! Ref: 9d194529
! Node: Pragma No_Caching195312
! Ref: gnat_rm/implementation_defined_pragmas id23195459
! Ref: 9e195459
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-caching195459
! Ref: 9f195459
! Node: Pragma No_Component_Reordering195702
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-component-reordering195865
! Ref: a0195865
! Node: Pragma No_Elaboration_Code_All196525
! Ref: gnat_rm/implementation_defined_pragmas id24196698
! Ref: a1196698
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-elaboration-code-all196698
! Ref: a2196698
! Node: Pragma No_Heap_Finalization197353
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-heap-finalization197512
! Ref: a3197512
! Node: Pragma No_Inline198664
! Ref: gnat_rm/implementation_defined_pragmas id25198809
! Ref: a4198809
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-inline198809
! Ref: a5198809
! Node: Pragma No_Return199324
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-return199467
! Ref: a6199467
! Node: Pragma No_Strict_Aliasing200440
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-strict-aliasing200591
! Ref: a7200591
! Node: Pragma No_Tagged_Streams201317
! Ref: gnat_rm/implementation_defined_pragmas id26201476
! Ref: a8201476
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-tagged-streams201476
! Ref: a9201476
! Node: Pragma Normalize_Scalars203251
! Ref: gnat_rm/implementation_defined_pragmas pragma-normalize-scalars203403
! Ref: aa203403
! Node: Pragma Obsolescent206373
! Ref: gnat_rm/implementation_defined_pragmas id27206526
! Ref: ab206526
! Ref: gnat_rm/implementation_defined_pragmas pragma-obsolescent206526
! Ref: ac206526
! Node: Pragma Optimize_Alignment209981
! Ref: gnat_rm/implementation_defined_pragmas pragma-optimize-alignment210124
! Ref: ad210124
! Node: Pragma Ordered213635
! Ref: gnat_rm/implementation_defined_pragmas pragma-ordered213780
! Ref: ae213780
! Node: Pragma Overflow_Mode216900
! Ref: gnat_rm/implementation_defined_pragmas pragma-overflow-mode217047
! Ref: af217047
! Node: Pragma Overriding_Renamings218385
! Ref: gnat_rm/implementation_defined_pragmas pragma-overriding-renamings218532
! Ref: b0218532
! Node: Pragma Part_Of219194
! Ref: gnat_rm/implementation_defined_pragmas id28219356
! Ref: b1219356
! Ref: gnat_rm/implementation_defined_pragmas pragma-part-of219356
! Ref: b2219356
! Node: Pragma Partition_Elaboration_Policy219602
! Ref: gnat_rm/implementation_defined_pragmas pragma-partition-elaboration-policy219751
! Ref: b3219751
! Node: Pragma Passive220127
! Ref: gnat_rm/implementation_defined_pragmas pragma-passive220283
! Ref: b4220283
! Node: Pragma Persistent_BSS221141
! Ref: gnat_rm/implementation_defined_pragmas id29221273
! Ref: b5221273
! Ref: gnat_rm/implementation_defined_pragmas pragma-persistent-bss221273
! Ref: b6221273
! Node: Pragma Post222469
! Ref: gnat_rm/implementation_defined_pragmas pragma-post222607
! Ref: b7222607
! Node: Pragma Postcondition223122
! Ref: gnat_rm/implementation_defined_pragmas pragma-postcondition223256
! Ref: b8223256
! Node: Pragma Post_Class229004
! Ref: gnat_rm/implementation_defined_pragmas pragma-post-class229137
! Ref: b9229137
! Node: Pragma Pre230194
! Ref: gnat_rm/implementation_defined_pragmas pragma-pre230326
! Ref: ba230326
! Node: Pragma Precondition230836
! Ref: gnat_rm/implementation_defined_pragmas pragma-precondition230967
! Ref: bb230967
! Node: Pragma Predicate232914
! Ref: gnat_rm/implementation_defined_pragmas id30233059
! Ref: bc233059
! Ref: gnat_rm/implementation_defined_pragmas pragma-predicate233059
! Ref: bd233059
! Node: Pragma Predicate_Failure234815
! Ref: gnat_rm/implementation_defined_pragmas pragma-predicate-failure234976
! Ref: be234976
! Node: Pragma Preelaborable_Initialization235333
! Ref: gnat_rm/implementation_defined_pragmas pragma-preelaborable-initialization235510
! Ref: bf235510
! Node: Pragma Prefix_Exception_Messages235828
! Ref: gnat_rm/implementation_defined_pragmas pragma-prefix-exception-messages235997
! Ref: c0235997
! Node: Pragma Pre_Class236918
! Ref: gnat_rm/implementation_defined_pragmas pragma-pre-class237088
! Ref: c1237088
! Node: Pragma Priority_Specific_Dispatching238136
! Ref: gnat_rm/implementation_defined_pragmas pragma-priority-specific-dispatching238288
! Ref: c2238288
! Node: Pragma Profile238887
! Ref: gnat_rm/implementation_defined_pragmas pragma-profile239046
! Ref: c3239046
! Node: Pragma Profile_Warnings245983
! Ref: gnat_rm/implementation_defined_pragmas pragma-profile-warnings246133
! Ref: c4246133
! Node: Pragma Propagate_Exceptions246572
! Ref: gnat_rm/implementation_defined_pragmas pragma-propagate-exceptions246738
! Ref: c5246738
! Node: Pragma Provide_Shift_Operators247136
! Ref: gnat_rm/implementation_defined_pragmas pragma-provide-shift-operators247298
! Ref: c6247298
! Node: Pragma Psect_Object247861
! Ref: gnat_rm/implementation_defined_pragmas pragma-psect-object248016
! Ref: c7248016
! Node: Pragma Pure_Function248369
! Ref: gnat_rm/implementation_defined_pragmas id31248509
! Ref: c8248509
! Ref: gnat_rm/implementation_defined_pragmas pragma-pure-function248509
! Ref: c9248509
! Node: Pragma Rational251555
! Ref: gnat_rm/implementation_defined_pragmas pragma-rational251692
! Ref: ca251692
! Node: Pragma Ravenscar251908
! Ref: gnat_rm/implementation_defined_pragmas pragma-ravenscar252047
! Ref: cb252047
! Node: Pragma Refined_Depends252338
! Ref: gnat_rm/implementation_defined_pragmas id32252483
! Ref: cc252483
! Ref: gnat_rm/implementation_defined_pragmas pragma-refined-depends252483
! Ref: cd252483
! Node: Pragma Refined_Global253217
! Ref: gnat_rm/implementation_defined_pragmas id33253365
! Ref: ce253365
! Ref: gnat_rm/implementation_defined_pragmas pragma-refined-global253365
! Ref: cf253365
! Node: Pragma Refined_Post253946
! Ref: gnat_rm/implementation_defined_pragmas id34254092
! Ref: d0254092
! Ref: gnat_rm/implementation_defined_pragmas pragma-refined-post254092
! Ref: d1254092
! Node: Pragma Refined_State254332
! Ref: gnat_rm/implementation_defined_pragmas id35254481
! Ref: d2254481
! Ref: gnat_rm/implementation_defined_pragmas pragma-refined-state254481
! Ref: d3254481
! Node: Pragma Relative_Deadline255006
! Ref: gnat_rm/implementation_defined_pragmas pragma-relative-deadline255161
! Ref: d4255161
! Node: Pragma Remote_Access_Type255455
! Ref: gnat_rm/implementation_defined_pragmas id36255610
! Ref: d5255610
! Ref: gnat_rm/implementation_defined_pragmas pragma-remote-access-type255610
! Ref: d6255610
! Node: Pragma Rename_Pragma256488
! Ref: gnat_rm/implementation_defined_pragmas pragma-rename-pragma256645
! Ref: d7256645
! Node: Pragma Restricted_Run_Time257808
! Ref: gnat_rm/implementation_defined_pragmas pragma-restricted-run-time257967
! Ref: d8257967
! Node: Pragma Restriction_Warnings258293
! Ref: gnat_rm/implementation_defined_pragmas pragma-restriction-warnings258449
! Ref: d9258449
! Node: Pragma Reviewable259737
! Ref: gnat_rm/implementation_defined_pragmas pragma-reviewable259894
! Ref: da259894
! Node: Pragma Secondary_Stack_Size262490
! Ref: gnat_rm/implementation_defined_pragmas id37262640
! Ref: db262640
! Ref: gnat_rm/implementation_defined_pragmas pragma-secondary-stack-size262640
! Ref: dc262640
! Node: Pragma Share_Generic264116
! Ref: gnat_rm/implementation_defined_pragmas pragma-share-generic264262
! Ref: dd264262
! Node: Pragma Shared264654
! Ref: gnat_rm/implementation_defined_pragmas id38264800
! Ref: de264800
! Ref: gnat_rm/implementation_defined_pragmas pragma-shared264800
! Ref: df264800
! Node: Pragma Short_Circuit_And_Or264955
! Ref: gnat_rm/implementation_defined_pragmas pragma-short-circuit-and-or265105
! Ref: e0265105
! Node: Pragma Short_Descriptors265759
! Ref: gnat_rm/implementation_defined_pragmas pragma-short-descriptors265927
! Ref: e1265927
! Node: Pragma Simple_Storage_Pool_Type266169
! Ref: gnat_rm/implementation_defined_pragmas id39266333
! Ref: e2266333
! Ref: gnat_rm/implementation_defined_pragmas pragma-simple-storage-pool-type266333
! Ref: e3266333
! Node: Pragma Source_File_Name268623
! Ref: gnat_rm/implementation_defined_pragmas id40268794
! Ref: e5268794
! Ref: gnat_rm/implementation_defined_pragmas pragma-source-file-name268794
! Ref: e6268794
! Node: Pragma Source_File_Name_Project272269
! Ref: gnat_rm/implementation_defined_pragmas id41272432
! Ref: e8272432
! Ref: gnat_rm/implementation_defined_pragmas pragma-source-file-name-project272432
! Ref: e7272432
! Node: Pragma Source_Reference273207
! Ref: gnat_rm/implementation_defined_pragmas pragma-source-reference273364
! Ref: e9273364
! Node: Pragma SPARK_Mode274209
! Ref: gnat_rm/implementation_defined_pragmas id42274368
! Ref: ea274368
! Ref: gnat_rm/implementation_defined_pragmas pragma-spark-mode274368
! Ref: eb274368
! Node: Pragma Static_Elaboration_Desired276385
! Ref: gnat_rm/implementation_defined_pragmas pragma-static-elaboration-desired276542
! Ref: ec276542
! Node: Pragma Stream_Convert277552
! Ref: gnat_rm/implementation_defined_pragmas pragma-stream-convert277711
! Ref: ed277711
! Node: Pragma Style_Checks280880
! Ref: gnat_rm/implementation_defined_pragmas pragma-style-checks281021
! Ref: ee281021
! Node: Pragma Subtitle283361
! Ref: gnat_rm/implementation_defined_pragmas pragma-subtitle283496
! Ref: ef283496
! Node: Pragma Suppress283698
! Ref: gnat_rm/implementation_defined_pragmas pragma-suppress283833
! Ref: f0283833
! Node: Pragma Suppress_All286704
! Ref: gnat_rm/implementation_defined_pragmas pragma-suppress-all286850
! Ref: f1286850
! Node: Pragma Suppress_Debug_Info287392
! Ref: gnat_rm/implementation_defined_pragmas id43287558
! Ref: f2287558
! Ref: gnat_rm/implementation_defined_pragmas pragma-suppress-debug-info287558
! Ref: f3287558
! Node: Pragma Suppress_Exception_Locations287890
! Ref: gnat_rm/implementation_defined_pragmas pragma-suppress-exception-locations288067
! Ref: f4288067
! Node: Pragma Suppress_Initialization288998
! Ref: gnat_rm/implementation_defined_pragmas id44289165
! Ref: f5289165
! Ref: gnat_rm/implementation_defined_pragmas pragma-suppress-initialization289165
! Ref: f6289165
! Node: Pragma Task_Name290729
! Ref: gnat_rm/implementation_defined_pragmas pragma-task-name290880
! Ref: f7290880
! Node: Pragma Task_Storage292459
! Ref: gnat_rm/implementation_defined_pragmas pragma-task-storage292596
! Ref: f8292596
! Node: Pragma Test_Case293131
! Ref: gnat_rm/implementation_defined_pragmas id45293279
! Ref: f9293279
! Ref: gnat_rm/implementation_defined_pragmas pragma-test-case293279
! Ref: fa293279
! Node: Pragma Thread_Local_Storage295373
! Ref: gnat_rm/implementation_defined_pragmas id46295519
! Ref: fb295519
! Ref: gnat_rm/implementation_defined_pragmas pragma-thread-local-storage295519
! Ref: fc295519
! Node: Pragma Time_Slice296732
! Ref: gnat_rm/implementation_defined_pragmas pragma-time-slice296874
! Ref: fd296874
! Node: Pragma Title297258
! Ref: gnat_rm/implementation_defined_pragmas pragma-title297394
! Ref: fe297394
! Node: Pragma Type_Invariant298111
! Ref: gnat_rm/implementation_defined_pragmas pragma-type-invariant298257
! Ref: ff298257
! Node: Pragma Type_Invariant_Class298797
! Ref: gnat_rm/implementation_defined_pragmas id47298953
! Ref: 100298953
! Ref: gnat_rm/implementation_defined_pragmas pragma-type-invariant-class298953
! Ref: 101298953
! Node: Pragma Unchecked_Union299868
! Ref: gnat_rm/implementation_defined_pragmas pragma-unchecked-union300032
! Ref: 102300032
! Node: Pragma Unevaluated_Use_Of_Old300598
! Ref: gnat_rm/implementation_defined_pragmas pragma-unevaluated-use-of-old300760
! Ref: 103300760
! Node: Pragma Unimplemented_Unit302687
! Ref: gnat_rm/implementation_defined_pragmas pragma-unimplemented-unit302852
! Ref: 104302852
! Node: Pragma Universal_Aliasing303387
! Ref: gnat_rm/implementation_defined_pragmas id48303540
! Ref: 105303540
! Ref: gnat_rm/implementation_defined_pragmas pragma-universal-aliasing303540
! Ref: 106303540
! Node: Pragma Unmodified304181
! Ref: gnat_rm/implementation_defined_pragmas id49304328
! Ref: 107304328
! Ref: gnat_rm/implementation_defined_pragmas pragma-unmodified304328
! Ref: 108304328
! Node: Pragma Unreferenced305406
! Ref: gnat_rm/implementation_defined_pragmas id50305555
! Ref: 109305555
! Ref: gnat_rm/implementation_defined_pragmas pragma-unreferenced305555
! Ref: 10a305555
! Node: Pragma Unreferenced_Objects308233
! Ref: gnat_rm/implementation_defined_pragmas id51308396
! Ref: 10b308396
! Ref: gnat_rm/implementation_defined_pragmas pragma-unreferenced-objects308396
! Ref: 10c308396
! Node: Pragma Unreserve_All_Interrupts309173
! Ref: gnat_rm/implementation_defined_pragmas pragma-unreserve-all-interrupts309334
! Ref: 10d309334
! Node: Pragma Unsuppress310839
! Ref: gnat_rm/implementation_defined_pragmas pragma-unsuppress310986
! Ref: 10e310986
! Node: Pragma Unused312256
! Ref: gnat_rm/implementation_defined_pragmas id52312392
! Ref: 10f312392
! Ref: gnat_rm/implementation_defined_pragmas pragma-unused312392
! Ref: 110312392
! Node: Pragma Use_VADS_Size313568
! Ref: gnat_rm/implementation_defined_pragmas pragma-use-vads-size313709
! Ref: 111313709
! Node: Pragma Validity_Checks314270
! Ref: gnat_rm/implementation_defined_pragmas pragma-validity-checks314413
! Ref: 112314413
! Node: Pragma Volatile316184
! Ref: gnat_rm/implementation_defined_pragmas id53316334
! Ref: 113316334
! Ref: gnat_rm/implementation_defined_pragmas pragma-volatile316334
! Ref: 114316334
! Node: Pragma Volatile_Full_Access316804
! Ref: gnat_rm/implementation_defined_pragmas id54316956
! Ref: 115316956
! Ref: gnat_rm/implementation_defined_pragmas pragma-volatile-full-access316956
! Ref: 116316956
! Node: Pragma Volatile_Function318024
! Ref: gnat_rm/implementation_defined_pragmas id55318184
! Ref: 117318184
! Ref: gnat_rm/implementation_defined_pragmas pragma-volatile-function318184
! Ref: 118318184
! Node: Pragma Warning_As_Error318455
! Ref: gnat_rm/implementation_defined_pragmas pragma-warning-as-error318603
! Ref: 119318603
! Node: Pragma Warnings321975
! Ref: gnat_rm/implementation_defined_pragmas id56322119
! Ref: 11b322119
! Ref: gnat_rm/implementation_defined_pragmas pragma-warnings322119
! Ref: 11a322119
! Node: Pragma Weak_External329586
! Ref: gnat_rm/implementation_defined_pragmas pragma-weak-external329737
! Ref: 11c329737
! Node: Pragma Wide_Character_Encoding331418
! Ref: gnat_rm/implementation_defined_pragmas pragma-wide-character-encoding331545
! Ref: 11d331545
! Node: Implementation Defined Aspects332677
! Ref: gnat_rm/implementation_defined_aspects doc332829
! Ref: 11e332829
! Ref: gnat_rm/implementation_defined_aspects id1332829
! Ref: 11f332829
! Ref: gnat_rm/implementation_defined_aspects implementation-defined-aspects332829
! Ref: 120332829
! Node: Aspect Abstract_State336045
! Ref: gnat_rm/implementation_defined_aspects aspect-abstract-state336158
! Ref: 121336158
! Node: Aspect Annotate336274
! Ref: gnat_rm/implementation_defined_aspects aspect-annotate336416
! Ref: 122336416
! Node: Aspect Async_Readers336887
! Ref: gnat_rm/implementation_defined_aspects aspect-async-readers337028
! Ref: 123337028
! Node: Aspect Async_Writers337149
! Ref: gnat_rm/implementation_defined_aspects aspect-async-writers337308
! Ref: 124337308
! Node: Aspect Constant_After_Elaboration337429
! Ref: gnat_rm/implementation_defined_aspects aspect-constant-after-elaboration337589
! Ref: 125337589
! Node: Aspect Contract_Cases337741
! Ref: gnat_rm/implementation_defined_aspects aspect-contract-cases337895
! Ref: 126337895
! Node: Aspect Depends338107
! Ref: gnat_rm/implementation_defined_aspects aspect-depends338260
! Ref: 127338260
! Node: Aspect Default_Initial_Condition338355
! Ref: gnat_rm/implementation_defined_aspects aspect-default-initial-condition338503
! Ref: 128338503
! Node: Aspect Dimension338652
! Ref: gnat_rm/implementation_defined_aspects aspect-dimension338809
! Ref: 129338809
! Node: Aspect Dimension_System340029
! Ref: gnat_rm/implementation_defined_aspects aspect-dimension-system340179
! Ref: 12a340179
! Node: Aspect Disable_Controlled342729
! Ref: gnat_rm/implementation_defined_aspects aspect-disable-controlled342885
! Ref: 12b342885
! Node: Aspect Effective_Reads343326
! Ref: gnat_rm/implementation_defined_aspects aspect-effective-reads343482
! Ref: 12c343482
! Node: Aspect Effective_Writes343603
! Ref: gnat_rm/implementation_defined_aspects aspect-effective-writes343759
! Ref: 12d343759
! Node: Aspect Extensions_Visible343883
! Ref: gnat_rm/implementation_defined_aspects aspect-extensions-visible344039
! Ref: 12e344039
! Node: Aspect Favor_Top_Level344169
! Ref: gnat_rm/implementation_defined_aspects aspect-favor-top-level344314
! Ref: 12f344314
! Node: Aspect Ghost344443
! Ref: gnat_rm/implementation_defined_aspects aspect-ghost344576
! Ref: 130344576
! Node: Aspect Global344667
! Ref: gnat_rm/implementation_defined_aspects aspect-global344802
! Ref: 131344802
! Node: Aspect Initial_Condition344896
! Ref: gnat_rm/implementation_defined_aspects aspect-initial-condition345037
! Ref: 132345037
! Node: Aspect Initializes345164
! Ref: gnat_rm/implementation_defined_aspects aspect-initializes345312
! Ref: 133345312
! Node: Aspect Inline_Always345421
! Ref: gnat_rm/implementation_defined_aspects aspect-inline-always345561
! Ref: 134345561
! Node: Aspect Invariant345684
! Ref: gnat_rm/implementation_defined_aspects aspect-invariant345830
! Ref: 135345830
! Node: Aspect Invariant’Class346082
! Ref: gnat_rm/implementation_defined_aspects aspect-invariant-class346223
! Ref: 136346223
! Node: Aspect Iterable346507
! Ref: gnat_rm/implementation_defined_aspects aspect-iterable346653
! Ref: 137346653
! Node: Aspect Linker_Section349260
! Ref: gnat_rm/implementation_defined_aspects aspect-linker-section349398
! Ref: 138349398
! Node: Aspect Lock_Free349516
! Ref: gnat_rm/implementation_defined_aspects aspect-lock-free349662
! Ref: 139349662
! Node: Aspect Max_Queue_Length349773
! Ref: gnat_rm/implementation_defined_aspects aspect-max-queue-length349915
! Ref: 13a349915
! Node: Aspect No_Caching350039
! Ref: gnat_rm/implementation_defined_aspects aspect-no-caching350195
! Ref: 13b350195
! Node: Aspect No_Elaboration_Code_All350309
! Ref: gnat_rm/implementation_defined_aspects aspect-no-elaboration-code-all350458
! Ref: 13c350458
! Node: Aspect No_Inline350623
! Ref: gnat_rm/implementation_defined_aspects aspect-no-inline350779
! Ref: 13d350779
! Node: Aspect No_Tagged_Streams350890
! Ref: gnat_rm/implementation_defined_aspects aspect-no-tagged-streams351036
! Ref: 13e351036
! Node: Aspect No_Task_Parts351265
! Ref: gnat_rm/implementation_defined_aspects aspect-no-task-parts351413
! Ref: 13f351413
! Node: Aspect Object_Size351919
! Ref: gnat_rm/implementation_defined_aspects aspect-object-size352061
! Ref: 140352061
! Node: Aspect Obsolescent352174
! Ref: gnat_rm/implementation_defined_aspects aspect-obsolescent352310
! Ref: 142352310
! Node: Aspect Part_Of352538
! Ref: gnat_rm/implementation_defined_aspects aspect-part-of352677
! Ref: 143352677
! Node: Aspect Persistent_BSS352774
! Ref: gnat_rm/implementation_defined_aspects aspect-persistent-bss352911
! Ref: 144352911
! Node: Aspect Predicate353037
! Ref: gnat_rm/implementation_defined_aspects aspect-predicate353180
! Ref: 145353180
! Node: Aspect Pure_Function353569
! Ref: gnat_rm/implementation_defined_aspects aspect-pure-function353713
! Ref: 146353713
! Node: Aspect Refined_Depends353836
! Ref: gnat_rm/implementation_defined_aspects aspect-refined-depends353985
! Ref: 147353985
! Node: Aspect Refined_Global354106
! Ref: gnat_rm/implementation_defined_aspects aspect-refined-global354254
! Ref: 148354254
! Node: Aspect Refined_Post354372
! Ref: gnat_rm/implementation_defined_aspects aspect-refined-post354518
! Ref: 149354518
! Node: Aspect Refined_State354630
! Ref: gnat_rm/implementation_defined_aspects aspect-refined-state354784
! Ref: 14a354784
! Node: Aspect Relaxed_Initialization354899
! Ref: gnat_rm/implementation_defined_aspects aspect-relaxed-initialization355059
! Ref: 14b355059
! Node: Aspect Remote_Access_Type355227
! Ref: gnat_rm/implementation_defined_aspects aspect-remote-access-type355394
! Ref: 14c355394
! Node: Aspect Secondary_Stack_Size355524
! Ref: gnat_rm/implementation_defined_aspects aspect-secondary-stack-size355689
! Ref: 14d355689
! Node: Aspect Scalar_Storage_Order355825
! Ref: gnat_rm/implementation_defined_aspects aspect-scalar-storage-order355978
! Ref: 14e355978
! Node: Aspect Shared356120
! Ref: gnat_rm/implementation_defined_aspects aspect-shared356272
! Ref: 150356272
! Node: Aspect Simple_Storage_Pool356421
! Ref: gnat_rm/implementation_defined_aspects aspect-simple-storage-pool356577
! Ref: 151356577
! Node: Aspect Simple_Storage_Pool_Type356713
! Ref: gnat_rm/implementation_defined_aspects aspect-simple-storage-pool-type356873
! Ref: 152356873
! Node: Aspect SPARK_Mode357029
! Ref: gnat_rm/implementation_defined_aspects aspect-spark-mode357189
! Ref: 153357189
! Node: Aspect Suppress_Debug_Info357393
! Ref: gnat_rm/implementation_defined_aspects aspect-suppress-debug-info357552
! Ref: 154357552
! Node: Aspect Suppress_Initialization357693
! Ref: gnat_rm/implementation_defined_aspects aspect-suppress-initialization357851
! Ref: 155357851
! Node: Aspect Test_Case358004
! Ref: gnat_rm/implementation_defined_aspects aspect-test-case358163
! Ref: 156358163
! Node: Aspect Thread_Local_Storage358266
! Ref: gnat_rm/implementation_defined_aspects aspect-thread-local-storage358420
! Ref: 157358420
! Node: Aspect Universal_Aliasing358564
! Ref: gnat_rm/implementation_defined_aspects aspect-universal-aliasing358719
! Ref: 158358719
! Node: Aspect Unmodified358858
! Ref: gnat_rm/implementation_defined_aspects aspect-unmodified359005
! Ref: 159359005
! Node: Aspect Unreferenced359120
! Ref: gnat_rm/implementation_defined_aspects aspect-unreferenced359269
! Ref: 15a359269
! Node: Aspect Unreferenced_Objects359554
! Ref: gnat_rm/implementation_defined_aspects aspect-unreferenced-objects359703
! Ref: 15b359703
! Node: Aspect Value_Size359848
! Ref: gnat_rm/implementation_defined_aspects aspect-value-size360005
! Ref: 15c360005
! Node: Aspect Volatile_Full_Access360115
! Ref: gnat_rm/implementation_defined_aspects aspect-volatile-full-access360269
! Ref: 15e360269
! Node: Aspect Volatile_Function360414
! Ref: gnat_rm/implementation_defined_aspects aspect-volatile-function360566
! Ref: 15f360566
! Node: Aspect Warnings360702
! Ref: gnat_rm/implementation_defined_aspects aspect-warnings360818
! Ref: 160360818
! Node: Implementation Defined Attributes361033
! Ref: gnat_rm/implementation_defined_attributes doc361203
! Ref: 161361203
! Ref: gnat_rm/implementation_defined_attributes id1361203
! Ref: 162361203
! Ref: gnat_rm/implementation_defined_attributes implementation-defined-attributes361203
! Ref: 8361203
! Node: Attribute Abort_Signal364395
! Ref: gnat_rm/implementation_defined_attributes attribute-abort-signal364519
! Ref: 163364519
! Node: Attribute Address_Size364954
! Ref: gnat_rm/implementation_defined_attributes attribute-address-size365106
! Ref: 164365106
! Node: Attribute Asm_Input365487
! Ref: gnat_rm/implementation_defined_attributes attribute-asm-input365637
! Ref: 165365637
! Node: Attribute Asm_Output366262
! Ref: gnat_rm/implementation_defined_attributes attribute-asm-output366423
! Ref: 167366423
! Node: Attribute Atomic_Always_Lock_Free367199
! Ref: gnat_rm/implementation_defined_attributes attribute-atomic-always-lock-free367354
! Ref: 168367354
! Node: Attribute Bit367693
! Ref: gnat_rm/implementation_defined_attributes attribute-bit367850
! Ref: 169367850
! Node: Attribute Bit_Position368935
! Ref: gnat_rm/implementation_defined_attributes attribute-bit-position369081
! Ref: 16a369081
! Node: Attribute Code_Address369531
! Ref: gnat_rm/implementation_defined_attributes attribute-code-address369690
! Ref: 16b369690
! Node: Attribute Compiler_Version371024
! Ref: gnat_rm/implementation_defined_attributes attribute-compiler-version371182
! Ref: 16c371182
! Node: Attribute Constrained371452
! Ref: gnat_rm/implementation_defined_attributes attribute-constrained371615
! Ref: 16d371615
! Node: Attribute Default_Bit_Order372089
! Ref: gnat_rm/implementation_defined_attributes attribute-default-bit-order372264
! Ref: 16e372264
! Node: Attribute Default_Scalar_Storage_Order372636
! Ref: gnat_rm/implementation_defined_attributes attribute-default-scalar-storage-order372805
! Ref: 16f372805
! Node: Attribute Deref373226
! Ref: gnat_rm/implementation_defined_attributes attribute-deref373393
! Ref: 170373393
! Node: Attribute Descriptor_Size373823
! Ref: gnat_rm/implementation_defined_attributes attribute-descriptor-size373972
! Ref: 171373972
! Node: Attribute Elaborated374974
! Ref: gnat_rm/implementation_defined_attributes attribute-elaborated375127
! Ref: 172375127
! Node: Attribute Elab_Body375669
! Ref: gnat_rm/implementation_defined_attributes attribute-elab-body375816
! Ref: 173375816
! Node: Attribute Elab_Spec376366
! Ref: gnat_rm/implementation_defined_attributes attribute-elab-spec376517
! Ref: 174376517
! Node: Attribute Elab_Subp_Body377067
! Ref: gnat_rm/implementation_defined_attributes attribute-elab-subp-body377213
! Ref: 175377213
! Node: Attribute Emax377635
! Ref: gnat_rm/implementation_defined_attributes attribute-emax377779
! Ref: 176377779
! Node: Attribute Enabled377983
! Ref: gnat_rm/implementation_defined_attributes attribute-enabled378121
! Ref: 177378121
! Node: Attribute Enum_Rep379243
! Ref: gnat_rm/implementation_defined_attributes attribute-enum-rep379385
! Ref: 178379385
! Node: Attribute Enum_Val380878
! Ref: gnat_rm/implementation_defined_attributes attribute-enum-val381020
! Ref: 179381020
! Node: Attribute Epsilon381746
! Ref: gnat_rm/implementation_defined_attributes attribute-epsilon381889
! Ref: 17a381889
! Node: Attribute Fast_Math382102
! Ref: gnat_rm/implementation_defined_attributes attribute-fast-math382254
! Ref: 17b382254
! Node: Attribute Finalization_Size382476
! Ref: gnat_rm/implementation_defined_attributes attribute-finalization-size382632
! Ref: 17c382632
! Node: Attribute Fixed_Value383246
! Ref: gnat_rm/implementation_defined_attributes attribute-fixed-value383401
! Ref: 17d383401
! Node: Attribute From_Any384103
! Ref: gnat_rm/implementation_defined_attributes attribute-from-any384258
! Ref: 17e384258
! Node: Attribute Has_Access_Values384435
! Ref: gnat_rm/implementation_defined_attributes attribute-has-access-values384596
! Ref: 17f384596
! Node: Attribute Has_Discriminants385122
! Ref: gnat_rm/implementation_defined_attributes attribute-has-discriminants385292
! Ref: 180385292
! Node: Attribute Has_Tagged_Values385733
! Ref: gnat_rm/implementation_defined_attributes attribute-has-tagged-values385889
! Ref: 181385889
! Node: Attribute Img386419
! Ref: gnat_rm/implementation_defined_attributes attribute-img386569
! Ref: 182386569
! Node: Attribute Initialized387236
! Ref: gnat_rm/implementation_defined_attributes attribute-initialized387382
! Ref: 183387382
! Node: Attribute Integer_Value387537
! Ref: gnat_rm/implementation_defined_attributes attribute-integer-value387693
! Ref: 184387693
! Node: Attribute Invalid_Value388457
! Ref: gnat_rm/implementation_defined_attributes attribute-invalid-value388610
! Ref: 185388610
! Node: Attribute Iterable389084
! Ref: gnat_rm/implementation_defined_attributes attribute-iterable389229
! Ref: 186389229
! Node: Attribute Large389310
! Ref: gnat_rm/implementation_defined_attributes attribute-large389455
! Ref: 187389455
! Node: Attribute Library_Level389662
! Ref: gnat_rm/implementation_defined_attributes attribute-library-level389809
! Ref: 188389809
! Node: Attribute Loop_Entry390445
! Ref: gnat_rm/implementation_defined_attributes attribute-loop-entry390599
! Ref: 189390599
! Node: Attribute Machine_Size391845
! Ref: gnat_rm/implementation_defined_attributes attribute-machine-size391994
! Ref: 18a391994
! Node: Attribute Mantissa392194
! Ref: gnat_rm/implementation_defined_attributes attribute-mantissa392350
! Ref: 18b392350
! Node: Attribute Maximum_Alignment392566
! Ref: gnat_rm/implementation_defined_attributes attribute-maximum-alignment392726
! Ref: 18c392726
! Ref: gnat_rm/implementation_defined_attributes id2392726
! Ref: 18d392726
! Node: Attribute Max_Integer_Size393067
! Ref: gnat_rm/implementation_defined_attributes attribute-max-integer-size393233
! Ref: 18e393233
! Node: Attribute Mechanism_Code393480
! Ref: gnat_rm/implementation_defined_attributes attribute-mechanism-code393643
! Ref: 18f393643
! Node: Attribute Null_Parameter394087
! Ref: gnat_rm/implementation_defined_attributes attribute-null-parameter394245
! Ref: 190394245
! Node: Attribute Object_Size394970
! Ref: gnat_rm/implementation_defined_attributes attribute-object-size395117
! Ref: 141395117
! Ref: gnat_rm/implementation_defined_attributes id3395117
! Ref: 191395117
! Node: Attribute Old397349
! Ref: gnat_rm/implementation_defined_attributes attribute-old397501
! Ref: 192397501
! Node: Attribute Passed_By_Reference397959
! Ref: gnat_rm/implementation_defined_attributes attribute-passed-by-reference398112
! Ref: 193398112
! Node: Attribute Pool_Address398526
! Ref: gnat_rm/implementation_defined_attributes attribute-pool-address398688
! Ref: 194398688
! Node: Attribute Range_Length399444
! Ref: gnat_rm/implementation_defined_attributes attribute-range-length399602
! Ref: 195399602
! Node: Attribute Restriction_Set399988
! Ref: gnat_rm/implementation_defined_attributes attribute-restriction-set400140
! Ref: 196400140
! Node: Attribute Result402614
! Ref: gnat_rm/implementation_defined_attributes attribute-result402763
! Ref: 197402763
! Node: Attribute Safe_Emax403165
! Ref: gnat_rm/implementation_defined_attributes attribute-safe-emax403309
! Ref: 198403309
! Node: Attribute Safe_Large403527
! Ref: gnat_rm/implementation_defined_attributes attribute-safe-large403675
! Ref: 199403675
! Node: Attribute Safe_Small403896
! Ref: gnat_rm/implementation_defined_attributes attribute-safe-small404055
! Ref: 19a404055
! Node: Attribute Scalar_Storage_Order404276
! Ref: gnat_rm/implementation_defined_attributes attribute-scalar-storage-order404444
! Ref: 14f404444
! Ref: gnat_rm/implementation_defined_attributes id4404444
! Ref: 19b404444
! Node: Attribute Simple_Storage_Pool410268
! Ref: gnat_rm/implementation_defined_attributes attribute-simple-storage-pool410431
! Ref: e4410431
! Ref: gnat_rm/implementation_defined_attributes id5410431
! Ref: 19c410431
! Node: Attribute Small413064
! Ref: gnat_rm/implementation_defined_attributes attribute-small413224
! Ref: 19d413224
! Node: Attribute Small_Denominator413591
! Ref: gnat_rm/implementation_defined_attributes attribute-small-denominator413747
! Ref: 19e413747
! Node: Attribute Small_Numerator414023
! Ref: gnat_rm/implementation_defined_attributes attribute-small-numerator414186
! Ref: 19f414186
! Node: Attribute Storage_Unit414454
! Ref: gnat_rm/implementation_defined_attributes attribute-storage-unit414609
! Ref: 1a0414609
! Node: Attribute Stub_Type414793
! Ref: gnat_rm/implementation_defined_attributes attribute-stub-type414959
! Ref: 1a1414959
! Node: Attribute System_Allocator_Alignment415914
! Ref: gnat_rm/implementation_defined_attributes attribute-system-allocator-alignment416079
! Ref: 1a2416079
! Node: Attribute Target_Name416555
! Ref: gnat_rm/implementation_defined_attributes attribute-target-name416721
! Ref: 1a3416721
! Node: Attribute To_Address417096
! Ref: gnat_rm/implementation_defined_attributes attribute-to-address417242
! Ref: 1a4417242
! Node: Attribute To_Any418065
! Ref: gnat_rm/implementation_defined_attributes attribute-to-any418210
! Ref: 1a5418210
! Node: Attribute Type_Class418383
! Ref: gnat_rm/implementation_defined_attributes attribute-type-class418526
! Ref: 1a6418526
! Node: Attribute Type_Key419391
! Ref: gnat_rm/implementation_defined_attributes attribute-type-key419536
! Ref: 1a7419536
! Node: Attribute TypeCode419845
! Ref: gnat_rm/implementation_defined_attributes attribute-typecode419999
! Ref: 1a8419999
! Node: Attribute Unconstrained_Array420176
! Ref: gnat_rm/implementation_defined_attributes attribute-unconstrained-array420346
! Ref: 1a9420346
! Node: Attribute Universal_Literal_String420762
! Ref: gnat_rm/implementation_defined_attributes attribute-universal-literal-string420943
! Ref: 1aa420943
! Node: Attribute Unrestricted_Access421635
! Ref: gnat_rm/implementation_defined_attributes attribute-unrestricted-access421803
! Ref: 1ab421803
! Node: Attribute Update428123
! Ref: gnat_rm/implementation_defined_attributes attribute-update428278
! Ref: 1ac428278
! Node: Attribute Valid_Value431109
! Ref: gnat_rm/implementation_defined_attributes attribute-valid-value431258
! Ref: 1ad431258
! Node: Attribute Valid_Scalars431595
! Ref: gnat_rm/implementation_defined_attributes attribute-valid-scalars431747
! Ref: 1ae431747
! Node: Attribute VADS_Size433405
! Ref: gnat_rm/implementation_defined_attributes attribute-vads-size433556
! Ref: 1af433556
! Node: Attribute Value_Size434197
! Ref: gnat_rm/implementation_defined_attributes attribute-value-size434347
! Ref: 15d434347
! Ref: gnat_rm/implementation_defined_attributes id6434347
! Ref: 1b0434347
! Node: Attribute Wchar_T_Size434592
! Ref: gnat_rm/implementation_defined_attributes attribute-wchar-t-size434742
! Ref: 1b1434742
! Node: Attribute Word_Size435046
! Ref: gnat_rm/implementation_defined_attributes attribute-word-size435167
! Ref: 1b2435167
! Node: Standard and Implementation Defined Restrictions435365
! Ref: gnat_rm/standard_and_implementation_defined_restrictions doc435526
! Ref: 1b3435526
! Ref: gnat_rm/standard_and_implementation_defined_restrictions id1435526
! Ref: 1b4435526
! Ref: gnat_rm/standard_and_implementation_defined_restrictions standard-and-implementation-defined-restrictions435526
! Ref: 9435526
! Node: Partition-Wide Restrictions436057
! Ref: gnat_rm/standard_and_implementation_defined_restrictions id2436210
! Ref: 1b5436210
! Ref: gnat_rm/standard_and_implementation_defined_restrictions partition-wide-restrictions436210
! Ref: 1b6436210
! Node: Immediate_Reclamation438551
! Ref: gnat_rm/standard_and_implementation_defined_restrictions immediate-reclamation438677
! Ref: 1b7438677
! Node: Max_Asynchronous_Select_Nesting438990
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-asynchronous-select-nesting439147
! Ref: 1b8439147
! Node: Max_Entry_Queue_Length439480
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-entry-queue-length439637
! Ref: 1b9439637
! Node: Max_Protected_Entries440333
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-protected-entries440482
! Ref: 1ba440482
! Node: Max_Select_Alternatives440767
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-select-alternatives440917
! Ref: 1bb440917
! Node: Max_Storage_At_Blocking441056
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-storage-at-blocking441201
! Ref: 1bc441201
! Node: Max_Task_Entries441459
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-task-entries441590
! Ref: 1bd441590
! Node: Max_Tasks441851
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-tasks441978
! Ref: 1be441978
! Node: No_Abort_Statements442306
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-abort-statements442447
! Ref: 1bf442447
! Node: No_Access_Parameter_Allocators442599
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-access-parameter-allocators442752
! Ref: 1c0442752
! Node: No_Access_Subprograms442974
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-access-subprograms443121
! Ref: 1c1443121
! Node: No_Allocators443293
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-allocators443433
! Ref: 1c2443433
! Node: No_Anonymous_Allocators443574
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-anonymous-allocators443716
! Ref: 1c3443716
! Node: No_Asynchronous_Control443902
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-asynchronous-control444042
! Ref: 1c4444042
! Node: No_Calendar444249
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-calendar444381
! Ref: 1c5444381
! Node: No_Coextensions444529
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-coextensions444663
! Ref: 1c6444663
! Node: No_Default_Initialization444806
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-default-initialization444937
! Ref: 1c7444937
! Node: No_Delay445637
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-delay445766
! Ref: 1c8445766
! Node: No_Dependence445934
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dependence446065
! Ref: 1c9446065
! Node: No_Direct_Boolean_Operators446386
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-direct-boolean-operators446520
! Ref: 1ca446520
! Node: No_Dispatch446920
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dispatch447061
! Ref: 1cb447061
! Node: No_Dispatching_Calls447233
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dispatching-calls447368
! Ref: 1cc447368
! Node: No_Dynamic_Attachment449464
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dynamic-attachment449609
! Ref: 1cd449609
! Node: No_Dynamic_Priorities450152
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dynamic-priorities450311
! Ref: 1ce450311
! Node: No_Entry_Calls_In_Elaboration_Code450450
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-entry-calls-in-elaboration-code450607
! Ref: 1cf450607
! Node: No_Enumeration_Maps450967
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-enumeration-maps451124
! Ref: 1d0451124
! Node: No_Exception_Handlers451350
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-exception-handlers451497
! Ref: 1d1451497
! Node: No_Exception_Propagation452370
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-exception-propagation452523
! Ref: 1d2452523
! Node: No_Exception_Registration453196
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-exception-registration453341
! Ref: 1d3453341
! Node: No_Exceptions453822
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-exceptions453958
! Ref: 1d4453958
! Node: No_Finalization454185
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-finalization454310
! Ref: 1d5454310
! Node: No_Fixed_Point455142
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-fixed-point455271
! Ref: 1d6455271
! Node: No_Floating_Point455434
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-floating-point455572
! Ref: 1d7455572
! Node: No_Implicit_Conditionals455744
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-conditionals455892
! Ref: 1d8455892
! Node: No_Implicit_Dynamic_Code456527
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-dynamic-code456686
! Ref: 1d9456686
! Node: No_Implicit_Heap_Allocations457907
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-heap-allocations458082
! Ref: 1da458082
! Node: No_Implicit_Protected_Object_Allocations458226
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-protected-object-allocations458405
! Ref: 1db458405
! Node: No_Implicit_Task_Allocations458593
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-task-allocations458765
! Ref: 1dc458765
! Node: No_Initialize_Scalars458917
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-initialize-scalars459054
! Ref: 1dd459054
! Node: No_IO459398
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-io459526
! Ref: 1de459526
! Node: No_Local_Allocators459744
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-local-allocators459877
! Ref: 1df459877
! Node: No_Local_Protected_Objects460091
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-local-protected-objects460240
! Ref: 1e0460240
! Node: No_Local_Tagged_Types460423
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-local-tagged-types460575
! Ref: 1e1460575
! Node: No_Local_Timing_Events460741
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-local-timing-events460888
! Ref: 1e2460888
! Node: No_Long_Long_Integers461055
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-long-long-integers461204
! Ref: 1e3461204
! Node: No_Multiple_Elaboration461514
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-multiple-elaboration461663
! Ref: 1e4461663
! Node: No_Nested_Finalization462306
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-nested-finalization462462
! Ref: 1e5462462
! Node: No_Protected_Type_Allocators462603
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-protected-type-allocators462754
! Ref: 1e6462754
! Node: No_Protected_Types462962
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-protected-types463103
! Ref: 1e7463103
! Node: No_Recursion463279
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-recursion463405
! Ref: 1e8463405
! Node: No_Reentrancy463542
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-reentrancy463667
! Ref: 1e9463667
! Node: No_Relative_Delay463812
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-relative-delay463946
! Ref: 1ea463946
! Node: No_Requeue_Statements464174
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-requeue-statements464313
! Ref: 1eb464313
! Node: No_Secondary_Stack464780
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-secondary-stack464922
! Ref: 1ec464922
! Node: No_Select_Statements465327
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-select-statements465480
! Ref: 1ed465480
! Node: No_Specific_Termination_Handlers465685
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-specific-termination-handlers465846
! Ref: 1ee465846
! Node: No_Specification_of_Aspect466046
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-specification-of-aspect466227
! Ref: 1ef466227
! Node: No_Standard_Allocators_After_Elaboration466448
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-standard-allocators-after-elaboration466622
! Ref: 1f0466622
! Node: No_Standard_Storage_Pools466937
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-standard-storage-pools467108
! Ref: 1f1467108
! Node: No_Stream_Optimizations467403
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-stream-optimizations467544
! Ref: 1f2467544
! Node: No_Streams467977
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-streams468120
! Ref: 1f3468120
! Node: No_Tagged_Type_Registration468841
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-tagged-type-registration468979
! Ref: 1f4468979
! Node: No_Task_Allocators469461
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-task-allocators469618
! Ref: 1f5469618
! Node: No_Task_At_Interrupt_Priority469760
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-task-at-interrupt-priority469916
! Ref: 1f6469916
! Node: No_Task_Attributes_Package470218
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-task-attributes-package470373
! Ref: 1f7470373
! Node: No_Task_Hierarchy470845
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-task-hierarchy470990
! Ref: 1f8470990
! Node: No_Task_Termination471137
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-task-termination471266
! Ref: 1f9471266
! Node: No_Tasking471367
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-tasking471504
! Ref: 1fa471504
! Node: No_Terminate_Alternatives471824
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-terminate-alternatives471961
! Ref: 1fb471961
! Node: No_Unchecked_Access472098
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-unchecked-access472248
! Ref: 1fc472248
! Node: No_Unchecked_Conversion472419
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-unchecked-conversion472569
! Ref: 1fd472569
! Node: No_Unchecked_Deallocation472780
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-unchecked-deallocation472927
! Ref: 1fe472927
! Node: No_Use_Of_Entity473145
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-use-of-entity473282
! Ref: 1ff473282
! Node: Pure_Barriers473580
! Ref: gnat_rm/standard_and_implementation_defined_restrictions pure-barriers473707
! Ref: 200473707
! Node: Simple_Barriers474412
! Ref: gnat_rm/standard_and_implementation_defined_restrictions simple-barriers474540
! Ref: 201474540
! Node: Static_Priorities475139
! Ref: gnat_rm/standard_and_implementation_defined_restrictions static-priorities475273
! Ref: 202475273
! Node: Static_Storage_Size475494
! Ref: gnat_rm/standard_and_implementation_defined_restrictions static-storage-size475604
! Ref: 203475604
! Node: Program Unit Level Restrictions475805
! Ref: gnat_rm/standard_and_implementation_defined_restrictions id3475958
! Ref: 204475958
! Ref: gnat_rm/standard_and_implementation_defined_restrictions program-unit-level-restrictions475958
! Ref: 205475958
! Node: No_Elaboration_Code476717
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-elaboration-code476845
! Ref: 206476845
! Node: No_Dynamic_Accessibility_Checks479444
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dynamic-accessibility-checks479605
! Ref: 207479605
! Node: No_Dynamic_Sized_Objects481415
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dynamic-sized-objects481571
! Ref: 208481571
! Node: No_Entry_Queue482293
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-entry-queue482457
! Ref: 209482457
! Node: No_Implementation_Aspect_Specifications482843
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-aspect-specifications483011
! Ref: 20a483011
! Node: No_Implementation_Attributes483305
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-attributes483488
! Ref: 20b483488
! Node: No_Implementation_Identifiers483766
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-identifiers483935
! Ref: 20c483935
! Node: No_Implementation_Pragmas484189
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-pragmas484360
! Ref: 20d484360
! Node: No_Implementation_Restrictions484626
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-restrictions484791
! Ref: 20e484791
! Node: No_Implementation_Units485156
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-units485316
! Ref: 20f485316
! Node: No_Implicit_Aliasing485562
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-aliasing485709
! Ref: 210485709
! Node: No_Implicit_Loops486263
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-loops486410
! Ref: 211486410
! Node: No_Obsolescent_Features487146
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-obsolescent-features487291
! Ref: 212487291
! Node: No_Wide_Characters487498
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-wide-characters487648
! Ref: 213487648
! Node: Static_Dispatch_Tables488012
! Ref: gnat_rm/standard_and_implementation_defined_restrictions static-dispatch-tables488147
! Ref: 214488147
! Node: SPARK_05488346
! Ref: gnat_rm/standard_and_implementation_defined_restrictions spark-05488454
! Ref: 215488454
! Node: Implementation Advice488913
! Ref: gnat_rm/implementation_advice doc489079
! Ref: 216489079
! Ref: gnat_rm/implementation_advice id1489079
! Ref: 217489079
! Ref: gnat_rm/implementation_advice implementation-advice489079
! Ref: a489079
! Node: RM 1 1 3 20 Error Detection494984
! Ref: gnat_rm/implementation_advice rm-1-1-3-20-error-detection495102
! Ref: 218495102
! Node: RM 1 1 3 31 Child Units495447
! Ref: gnat_rm/implementation_advice rm-1-1-3-31-child-units495600
! Ref: 219495600
! Node: RM 1 1 5 12 Bounded Errors495889
! Ref: gnat_rm/implementation_advice rm-1-1-5-12-bounded-errors496032
! Ref: 21a496032
! Node: RM 2 8 16 Pragmas496371
! Ref: gnat_rm/implementation_advice id2496511
! Ref: 21b496511
! Ref: gnat_rm/implementation_advice rm-2-8-16-pragmas496511
! Ref: 21c496511
! Node: RM 2 8 17-19 Pragmas498192
! Ref: gnat_rm/implementation_advice rm-2-8-17-19-pragmas498343
! Ref: 21d498343
! Node: RM 3 5 2 5 Alternative Character Sets498777
! Ref: gnat_rm/implementation_advice rm-3-5-2-5-alternative-character-sets498936
! Ref: 21e498936
! Node: RM 3 5 4 28 Integer Types500093
! Ref: gnat_rm/implementation_advice rm-3-5-4-28-integer-types500257
! Ref: 21f500257
! Node: RM 3 5 4 29 Integer Types500931
! Ref: gnat_rm/implementation_advice rm-3-5-4-29-integer-types501087
! Ref: 220501087
! Node: RM 3 5 5 8 Enumeration Values501405
! Ref: gnat_rm/implementation_advice rm-3-5-5-8-enumeration-values501559
! Ref: 221501559
! Node: RM 3 5 7 17 Float Types502108
! Ref: gnat_rm/implementation_advice rm-3-5-7-17-float-types502272
! Ref: 222502272
! Node: RM 3 6 2 11 Multidimensional Arrays503381
! Ref: gnat_rm/implementation_advice rm-3-6-2-11-multidimensional-arrays503545
! Ref: 223503545
! Node: RM 9 6 30-31 Duration’Small504045
! Ref: gnat_rm/implementation_advice rm-9-6-30-31-duration-small504224
! Ref: 224504224
! Node: RM 10 2 1 12 Consistent Representation504646
! Ref: gnat_rm/implementation_advice rm-10-2-1-12-consistent-representation504824
! Ref: 225504824
! Node: RM 11 4 1 19 Exception Information505614
! Ref: gnat_rm/implementation_advice rm-11-4-1-19-exception-information505795
! Ref: 226505795
! Node: RM 11 5 28 Suppression of Checks506937
! Ref: gnat_rm/implementation_advice rm-11-5-28-suppression-of-checks507116
! Ref: 227507116
! Node: RM 13 1 21-24 Representation Clauses507316
! Ref: gnat_rm/implementation_advice rm-13-1-21-24-representation-clauses507485
! Ref: 228507485
! Node: RM 13 2 6-8 Packed Types508899
! Ref: gnat_rm/implementation_advice rm-13-2-6-8-packed-types509065
! Ref: 229509065
! Node: RM 13 3 14-19 Address Clauses510298
! Ref: gnat_rm/implementation_advice rm-13-3-14-19-address-clauses510459
! Ref: 22a510459
! Node: RM 13 3 29-35 Alignment Clauses511594
! Ref: gnat_rm/implementation_advice rm-13-3-29-35-alignment-clauses511757
! Ref: 22b511757
! Node: RM 13 3 42-43 Size Clauses512958
! Ref: gnat_rm/implementation_advice rm-13-3-42-43-size-clauses513118
! Ref: 22c513118
! Node: RM 13 3 50-56 Size Clauses513583
! Ref: gnat_rm/implementation_advice rm-13-3-50-56-size-clauses513748
! Ref: 22d513748
! Node: RM 13 3 71-73 Component Size Clauses515122
! Ref: gnat_rm/implementation_advice rm-13-3-71-73-component-size-clauses515308
! Ref: 22e515308
! Node: RM 13 4 9-10 Enumeration Representation Clauses516116
! Ref: gnat_rm/implementation_advice rm-13-4-9-10-enumeration-representation-clauses516321
! Ref: 22f516321
! Node: RM 13 5 1 17-22 Record Representation Clauses516743
! Ref: gnat_rm/implementation_advice rm-13-5-1-17-22-record-representation-clauses516948
! Ref: 230516948
! Node: RM 13 5 2 5 Storage Place Attributes518651
! Ref: gnat_rm/implementation_advice rm-13-5-2-5-storage-place-attributes518835
! Ref: 231518835
! Node: RM 13 5 3 7-8 Bit Ordering519447
! Ref: gnat_rm/implementation_advice rm-13-5-3-7-8-bit-ordering519615
! Ref: 232519615
! Node: RM 13 7 37 Address as Private520059
! Ref: gnat_rm/implementation_advice rm-13-7-37-address-as-private520222
! Ref: 233520222
! Node: RM 13 7 1 16 Address Operations520363
! Ref: gnat_rm/implementation_advice rm-13-7-1-16-address-operations520534
! Ref: 234520534
! Node: RM 13 9 14-17 Unchecked Conversion521073
! Ref: gnat_rm/implementation_advice rm-13-9-14-17-unchecked-conversion521249
! Ref: 235521249
! Node: RM 13 11 23-25 Implicit Heap Usage522641
! Ref: gnat_rm/implementation_advice rm-13-11-23-25-implicit-heap-usage522822
! Ref: 236522822
! Node: RM 13 11 2 17 Unchecked Deallocation523841
! Ref: gnat_rm/implementation_advice rm-13-11-2-17-unchecked-deallocation524029
! Ref: 237524029
! Node: RM 13 13 2 1 6 Stream Oriented Attributes524223
! Ref: gnat_rm/implementation_advice rm-13-13-2-1-6-stream-oriented-attributes524420
! Ref: 238524420
! Node: RM A 1 52 Names of Predefined Numeric Types525384
! Ref: gnat_rm/implementation_advice rm-a-1-52-names-of-predefined-numeric-types525580
! Ref: 239525580
! Node: RM A 3 2 49 Ada Characters Handling526018
! Ref: gnat_rm/implementation_advice rm-a-3-2-49-ada-characters-handling526216
! Ref: 23a526216
! Node: RM A 4 4 106 Bounded-Length String Handling526608
! Ref: gnat_rm/implementation_advice rm-a-4-4-106-bounded-length-string-handling526802
! Ref: 23b526802
! Node: RM A 5 2 46-47 Random Number Generation527081
! Ref: gnat_rm/implementation_advice rm-a-5-2-46-47-random-number-generation527266
! Ref: 23c527266
! Node: RM A 10 7 23 Get_Immediate528098
! Ref: gnat_rm/implementation_advice rm-a-10-7-23-get-immediate528258
! Ref: 23d528258
! Node: RM A 18 Containers529110
! Ref: gnat_rm/implementation_advice rm-a-18-containers529257
! Ref: 23e529257
! Node: RM B 1 39-41 Pragma Export529888
! Ref: gnat_rm/implementation_advice rm-b-1-39-41-pragma-export530040
! Ref: 23f530040
! Node: RM B 2 12-13 Package Interfaces531580
! Ref: gnat_rm/implementation_advice rm-b-2-12-13-package-interfaces531745
! Ref: 240531745
! Node: RM B 3 63-71 Interfacing with C532558
! Ref: gnat_rm/implementation_advice rm-b-3-63-71-interfacing-with-c532732
! Ref: 241532732
! Node: RM B 4 95-98 Interfacing with COBOL534667
! Ref: gnat_rm/implementation_advice rm-b-4-95-98-interfacing-with-cobol534847
! Ref: 242534847
! Node: RM B 5 22-26 Interfacing with Fortran535581
! Ref: gnat_rm/implementation_advice rm-b-5-22-26-interfacing-with-fortran535769
! Ref: 243535769
! Node: RM C 1 3-5 Access to Machine Operations536857
! Ref: gnat_rm/implementation_advice rm-c-1-3-5-access-to-machine-operations537051
! Ref: 244537051
! Node: RM C 1 10-16 Access to Machine Operations538027
! Ref: gnat_rm/implementation_advice rm-c-1-10-16-access-to-machine-operations538211
! Ref: 245538211
! Node: RM C 3 28 Interrupt Support539481
! Ref: gnat_rm/implementation_advice rm-c-3-28-interrupt-support539669
! Ref: 246539669
! Node: RM C 3 1 20-21 Protected Procedure Handlers540135
! Ref: gnat_rm/implementation_advice rm-c-3-1-20-21-protected-procedure-handlers540312
! Ref: 247540312
! Node: RM C 3 2 25 Package Interrupts540816
! Ref: gnat_rm/implementation_advice rm-c-3-2-25-package-interrupts541004
! Ref: 248541004
! Node: RM C 4 14 Pre-elaboration Requirements541474
! Ref: gnat_rm/implementation_advice rm-c-4-14-pre-elaboration-requirements541648
! Ref: 249541648
! Node: RM C 5 8 Pragma Discard_Names542088
! Ref: gnat_rm/implementation_advice rm-c-5-8-pragma-discard-names542271
! Ref: 24a542271
! Node: RM C 7 2 30 The Package Task_Attributes542535
! Ref: gnat_rm/implementation_advice rm-c-7-2-30-the-package-task-attributes542706
! Ref: 24b542706
! Node: RM D 3 17 Locking Policies543442
! Ref: gnat_rm/implementation_advice rm-d-3-17-locking-policies543616
! Ref: 24c543616
! Node: RM D 4 16 Entry Queuing Policies543989
! Ref: gnat_rm/implementation_advice rm-d-4-16-entry-queuing-policies544152
! Ref: 24d544152
! Node: RM D 6 9-10 Preemptive Abort544416
! Ref: gnat_rm/implementation_advice rm-d-6-9-10-preemptive-abort544583
! Ref: 24e544583
! Node: RM D 7 21 Tasking Restrictions545157
! Ref: gnat_rm/implementation_advice rm-d-7-21-tasking-restrictions545319
! Ref: 24f545319
! Node: RM D 8 47-49 Monotonic Time545821
! Ref: gnat_rm/implementation_advice rm-d-8-47-49-monotonic-time546001
! Ref: 250546001
! Node: RM E 5 28-29 Partition Communication Subsystem546676
! Ref: gnat_rm/implementation_advice rm-e-5-28-29-partition-communication-subsystem546846
! Ref: 251546846
! Node: RM F 7 COBOL Support547540
! Ref: gnat_rm/implementation_advice rm-f-7-cobol-support547713
! Ref: 252547713
! Node: RM F 1 2 Decimal Radix Support548264
! Ref: gnat_rm/implementation_advice rm-f-1-2-decimal-radix-support548404
! Ref: 253548404
! Node: RM G Numerics548718
! Ref: gnat_rm/implementation_advice rm-g-numerics548866
! Ref: 254548866
! Node: RM G 1 1 56-58 Complex Types549396
! Ref: gnat_rm/implementation_advice rm-g-1-1-56-58-complex-types549554
! Ref: 255549554
! Node: RM G 1 2 49 Complex Elementary Functions552383
! Ref: gnat_rm/implementation_advice rm-g-1-2-49-complex-elementary-functions552561
! Ref: 256552561
! Node: RM G 2 4 19 Accuracy Requirements553294
! Ref: gnat_rm/implementation_advice rm-g-2-4-19-accuracy-requirements553483
! Ref: 257553483
! Node: RM G 2 6 15 Complex Arithmetic Accuracy554098
! Ref: gnat_rm/implementation_advice rm-g-2-6-15-complex-arithmetic-accuracy554294
! Ref: 258554294
! Node: RM H 6 15/2 Pragma Partition_Elaboration_Policy554717
! Ref: gnat_rm/implementation_advice rm-h-6-15-2-pragma-partition-elaboration-policy554871
! Ref: 259554871
! Node: Implementation Defined Characteristics555253
! Ref: gnat_rm/implementation_defined_characteristics doc555392
! Ref: 25a555392
! Ref: gnat_rm/implementation_defined_characteristics id1555392
! Ref: 25b555392
! Ref: gnat_rm/implementation_defined_characteristics implementation-defined-characteristics555392
! Ref: b555392
! Node: Intrinsic Subprograms607273
! Ref: gnat_rm/intrinsic_subprograms doc607425
! Ref: 25d607425
! Ref: gnat_rm/intrinsic_subprograms id1607425
! Ref: 25e607425
! Ref: gnat_rm/intrinsic_subprograms intrinsic-subprograms607425
! Ref: c607425
! Node: Intrinsic Operators608405
! Ref: gnat_rm/intrinsic_subprograms id2608512
! Ref: 25f608512
! Ref: gnat_rm/intrinsic_subprograms intrinsic-operators608512
! Ref: 260608512
! Node: Compilation_ISO_Date609511
! Ref: gnat_rm/intrinsic_subprograms compilation-iso-date609643
! Ref: 261609643
! Ref: gnat_rm/intrinsic_subprograms id3609643
! Ref: 262609643
! Node: Compilation_Date610064
! Ref: gnat_rm/intrinsic_subprograms compilation-date610193
! Ref: 263610193
! Ref: gnat_rm/intrinsic_subprograms id4610193
! Ref: 264610193
! Node: Compilation_Time610313
! Ref: gnat_rm/intrinsic_subprograms compilation-time610438
! Ref: 265610438
! Ref: gnat_rm/intrinsic_subprograms id5610438
! Ref: 266610438
! Node: Enclosing_Entity610845
! Ref: gnat_rm/intrinsic_subprograms enclosing-entity610975
! Ref: 267610975
! Ref: gnat_rm/intrinsic_subprograms id6610975
! Ref: 268610975
! Node: Exception_Information611396
! Ref: gnat_rm/intrinsic_subprograms exception-information611527
! Ref: 269611527
! Ref: gnat_rm/intrinsic_subprograms id7611527
! Ref: 26a611527
! Node: Exception_Message611957
! Ref: gnat_rm/intrinsic_subprograms exception-message612086
! Ref: 26b612086
! Ref: gnat_rm/intrinsic_subprograms id8612086
! Ref: 26c612086
! Node: Exception_Name612490
! Ref: gnat_rm/intrinsic_subprograms exception-name612602
! Ref: 26d612602
! Ref: gnat_rm/intrinsic_subprograms id9612602
! Ref: 26e612602
! Node: File612981
! Ref: gnat_rm/intrinsic_subprograms file613080
! Ref: 26f613080
! Ref: gnat_rm/intrinsic_subprograms id10613080
! Ref: 270613080
! Node: Line613412
! Ref: gnat_rm/intrinsic_subprograms id11613515
! Ref: 271613515
! Ref: gnat_rm/intrinsic_subprograms line613515
! Ref: 272613515
! Node: Shifts and Rotates613858
! Ref: gnat_rm/intrinsic_subprograms id12613972
! Ref: 273613972
! Ref: gnat_rm/intrinsic_subprograms shifts-and-rotates613972
! Ref: 274613972
! Node: Source_Location615210
! Ref: gnat_rm/intrinsic_subprograms id13615311
! Ref: 275615311
! Ref: gnat_rm/intrinsic_subprograms source-location615311
! Ref: 276615311
! Node: Representation Clauses and Pragmas615682
! Ref: gnat_rm/representation_clauses_and_pragmas doc615821
! Ref: 277615821
! Ref: gnat_rm/representation_clauses_and_pragmas id1615821
! Ref: 278615821
! Ref: gnat_rm/representation_clauses_and_pragmas representation-clauses-and-pragmas615821
! Ref: d615821
! Node: Alignment Clauses617007
! Ref: gnat_rm/representation_clauses_and_pragmas alignment-clauses617117
! Ref: 279617117
! Ref: gnat_rm/representation_clauses_and_pragmas id2617117
! Ref: 27a617117
! Node: Size Clauses621563
! Ref: gnat_rm/representation_clauses_and_pragmas id3621702
! Ref: 27b621702
! Ref: gnat_rm/representation_clauses_and_pragmas size-clauses621702
! Ref: 27c621702
! Node: Storage_Size Clauses624486
! Ref: gnat_rm/representation_clauses_and_pragmas id4624638
! Ref: 27d624638
! Ref: gnat_rm/representation_clauses_and_pragmas storage-size-clauses624638
! Ref: 27e624638
! Node: Size of Variant Record Objects627170
! Ref: gnat_rm/representation_clauses_and_pragmas id5627331
! Ref: 27f627331
! Ref: gnat_rm/representation_clauses_and_pragmas size-of-variant-record-objects627331
! Ref: 280627331
! Node: Biased Representation630443
! Ref: gnat_rm/representation_clauses_and_pragmas biased-representation630618
! Ref: 281630618
! Ref: gnat_rm/representation_clauses_and_pragmas id6630618
! Ref: 282630618
! Node: Value_Size and Object_Size Clauses631662
! Ref: gnat_rm/representation_clauses_and_pragmas id7631829
! Ref: 283631829
! Ref: gnat_rm/representation_clauses_and_pragmas value-size-and-object-size-clauses631829
! Ref: 284631829
! Node: Component_Size Clauses641487
! Ref: gnat_rm/representation_clauses_and_pragmas component-size-clauses641650
! Ref: 285641650
! Ref: gnat_rm/representation_clauses_and_pragmas id8641650
! Ref: 286641650
! Node: Bit_Order Clauses643284
! Ref: gnat_rm/representation_clauses_and_pragmas bit-order-clauses643449
! Ref: 287643449
! Ref: gnat_rm/representation_clauses_and_pragmas id9643449
! Ref: 288643449
! Node: Effect of Bit_Order on Byte Ordering646894
! Ref: gnat_rm/representation_clauses_and_pragmas effect-of-bit-order-on-byte-ordering647059
! Ref: 289647059
! Ref: gnat_rm/representation_clauses_and_pragmas id10647059
! Ref: 28a647059
! Node: Pragma Pack for Arrays656514
! Ref: gnat_rm/representation_clauses_and_pragmas id11656685
! Ref: 28b656685
! Ref: gnat_rm/representation_clauses_and_pragmas pragma-pack-for-arrays656685
! Ref: 28c656685
! Node: Pragma Pack for Records661190
! Ref: gnat_rm/representation_clauses_and_pragmas id12661354
! Ref: 28d661354
! Ref: gnat_rm/representation_clauses_and_pragmas pragma-pack-for-records661354
! Ref: 28e661354
! Node: Record Representation Clauses663914
! Ref: gnat_rm/representation_clauses_and_pragmas id13664086
! Ref: 28f664086
! Ref: gnat_rm/representation_clauses_and_pragmas record-representation-clauses664086
! Ref: 290664086
! Node: Handling of Records with Holes666974
! Ref: gnat_rm/representation_clauses_and_pragmas handling-of-records-with-holes667142
! Ref: 291667142
! Ref: gnat_rm/representation_clauses_and_pragmas id14667142
! Ref: 292667142
! Node: Enumeration Clauses669404
! Ref: gnat_rm/representation_clauses_and_pragmas enumeration-clauses669558
! Ref: 293669558
! Ref: gnat_rm/representation_clauses_and_pragmas id15669558
! Ref: 294669558
! Node: Address Clauses670994
! Ref: gnat_rm/representation_clauses_and_pragmas address-clauses671162
! Ref: 295671162
! Ref: gnat_rm/representation_clauses_and_pragmas id16671162
! Ref: 296671162
! Node: Use of Address Clauses for Memory-Mapped I/O682654
! Ref: gnat_rm/representation_clauses_and_pragmas id17682841
! Ref: 297682841
! Ref: gnat_rm/representation_clauses_and_pragmas use-of-address-clauses-for-memory-mapped-i-o682841
! Ref: 298682841
! Node: Effect of Convention on Representation684709
! Ref: gnat_rm/representation_clauses_and_pragmas effect-of-convention-on-representation684919
! Ref: 299684919
! Ref: gnat_rm/representation_clauses_and_pragmas id18684919
! Ref: 29a684919
! Node: Conventions and Anonymous Access Types688044
! Ref: gnat_rm/representation_clauses_and_pragmas conventions-and-anonymous-access-types688256
! Ref: 29b688256
! Ref: gnat_rm/representation_clauses_and_pragmas id19688256
! Ref: 29c688256
! Node: Determining the Representations chosen by GNAT690747
! Ref: gnat_rm/representation_clauses_and_pragmas determining-the-representations-chosen-by-gnat690912
! Ref: 29d690912
! Ref: gnat_rm/representation_clauses_and_pragmas id20690912
! Ref: 29e690912
! Node: Standard Library Routines695511
! Ref: gnat_rm/standard_library_routines doc695663
! Ref: 29f695663
! Ref: gnat_rm/standard_library_routines id1695663
! Ref: 2a0695663
! Ref: gnat_rm/standard_library_routines standard-library-routines695663
! Ref: e695663
! Node: The Implementation of Standard I/O722772
! Ref: gnat_rm/the_implementation_of_standard_i_o doc722906
! Ref: 2a1722906
! Ref: gnat_rm/the_implementation_of_standard_i_o id1722906
! Ref: 2a2722906
! Ref: gnat_rm/the_implementation_of_standard_i_o the-implementation-of-standard-i-o722906
! Ref: f722906
! Node: Standard I/O Packages724956
! Ref: gnat_rm/the_implementation_of_standard_i_o id2725070
! Ref: 2a3725070
! Ref: gnat_rm/the_implementation_of_standard_i_o standard-i-o-packages725070
! Ref: 2a4725070
! Node: FORM Strings726409
! Ref: gnat_rm/the_implementation_of_standard_i_o form-strings726541
! Ref: 2a5726541
! Ref: gnat_rm/the_implementation_of_standard_i_o id3726541
! Ref: 2a6726541
! Node: Direct_IO727155
! Ref: gnat_rm/the_implementation_of_standard_i_o direct-io727279
! Ref: 2a7727279
! Ref: gnat_rm/the_implementation_of_standard_i_o id4727279
! Ref: 2a8727279
! Node: Sequential_IO728056
! Ref: gnat_rm/the_implementation_of_standard_i_o id5728175
! Ref: 2a9728175
! Ref: gnat_rm/the_implementation_of_standard_i_o sequential-io728175
! Ref: 2aa728175
! Node: Text_IO730012
! Ref: gnat_rm/the_implementation_of_standard_i_o id6730134
! Ref: 2ab730134
! Ref: gnat_rm/the_implementation_of_standard_i_o text-io730134
! Ref: 2ac730134
! Node: Stream Pointer Positioning732622
! Ref: gnat_rm/the_implementation_of_standard_i_o id7732739
! Ref: 2ad732739
! Ref: gnat_rm/the_implementation_of_standard_i_o stream-pointer-positioning732739
! Ref: 2ae732739
! Node: Reading and Writing Non-Regular Files734186
! Ref: gnat_rm/the_implementation_of_standard_i_o id8734325
! Ref: 2af734325
! Ref: gnat_rm/the_implementation_of_standard_i_o reading-and-writing-non-regular-files734325
! Ref: 2b0734325
! Node: Get_Immediate736099
! Ref: gnat_rm/the_implementation_of_standard_i_o get-immediate736245
! Ref: 2b1736245
! Ref: gnat_rm/the_implementation_of_standard_i_o id9736245
! Ref: 2b2736245
! Node: Treating Text_IO Files as Streams736938
! Ref: gnat_rm/the_implementation_of_standard_i_o id10737065
! Ref: 2b3737065
! Ref: gnat_rm/the_implementation_of_standard_i_o treating-text-io-files-as-streams737065
! Ref: 2b4737065
! Node: Text_IO Extensions737653
! Ref: gnat_rm/the_implementation_of_standard_i_o id11737807
! Ref: 2b5737807
! Ref: gnat_rm/the_implementation_of_standard_i_o text-io-extensions737807
! Ref: 2b6737807
! Node: Text_IO Facilities for Unbounded Strings738424
! Ref: gnat_rm/the_implementation_of_standard_i_o id12738536
! Ref: 2b7738536
! Ref: gnat_rm/the_implementation_of_standard_i_o text-io-facilities-for-unbounded-strings738536
! Ref: 2b8738536
! Node: Wide_Text_IO740110
! Ref: gnat_rm/the_implementation_of_standard_i_o id13740236
! Ref: 2b9740236
! Ref: gnat_rm/the_implementation_of_standard_i_o wide-text-io740236
! Ref: 2ba740236
! Node: Stream Pointer Positioning<2>747213
! Ref: gnat_rm/the_implementation_of_standard_i_o id14747341
! Ref: 2bb747341
! Ref: gnat_rm/the_implementation_of_standard_i_o stream-pointer-positioning-1747341
! Ref: 2bc747341
! Node: Reading and Writing Non-Regular Files<2>748259
! Ref: gnat_rm/the_implementation_of_standard_i_o id15748387
! Ref: 2bd748387
! Ref: gnat_rm/the_implementation_of_standard_i_o reading-and-writing-non-regular-files-1748387
! Ref: 2be748387
! Node: Wide_Wide_Text_IO748796
! Ref: gnat_rm/the_implementation_of_standard_i_o id16748924
! Ref: 2bf748924
! Ref: gnat_rm/the_implementation_of_standard_i_o wide-wide-text-io748924
! Ref: 2c0748924
! Node: Stream Pointer Positioning<3>752605
! Ref: gnat_rm/the_implementation_of_standard_i_o id17752738
! Ref: 2c1752738
! Ref: gnat_rm/the_implementation_of_standard_i_o stream-pointer-positioning-2752738
! Ref: 2c2752738
! Node: Reading and Writing Non-Regular Files<3>753688
! Ref: gnat_rm/the_implementation_of_standard_i_o id18753821
! Ref: 2c3753821
! Ref: gnat_rm/the_implementation_of_standard_i_o reading-and-writing-non-regular-files-2753821
! Ref: 2c4753821
! Node: Stream_IO754230
! Ref: gnat_rm/the_implementation_of_standard_i_o id19754362
! Ref: 2c5754362
! Ref: gnat_rm/the_implementation_of_standard_i_o stream-io754362
! Ref: 2c6754362
! Node: Text Translation754879
! Ref: gnat_rm/the_implementation_of_standard_i_o id20755006
! Ref: 2c7755006
! Ref: gnat_rm/the_implementation_of_standard_i_o text-translation755006
! Ref: 2c8755006
! Node: Shared Files755806
! Ref: gnat_rm/the_implementation_of_standard_i_o id21755942
! Ref: 2c9755942
! Ref: gnat_rm/the_implementation_of_standard_i_o shared-files755942
! Ref: 2ca755942
! Node: Filenames encoding758688
! Ref: gnat_rm/the_implementation_of_standard_i_o filenames-encoding758829
! Ref: 2cb758829
! Ref: gnat_rm/the_implementation_of_standard_i_o id22758829
! Ref: 2cc758829
! Node: File content encoding759639
! Ref: gnat_rm/the_implementation_of_standard_i_o file-content-encoding759778
! Ref: 2cd759778
! Ref: gnat_rm/the_implementation_of_standard_i_o id23759778
! Ref: 2ce759778
! Node: Open Modes760302
! Ref: gnat_rm/the_implementation_of_standard_i_o id24760446
! Ref: 2cf760446
! Ref: gnat_rm/the_implementation_of_standard_i_o open-modes760446
! Ref: 2d0760446
! Node: Operations on C Streams762440
! Ref: gnat_rm/the_implementation_of_standard_i_o id25762587
! Ref: 2d1762587
! Ref: gnat_rm/the_implementation_of_standard_i_o operations-on-c-streams762587
! Ref: 2d2762587
! Node: Interfacing to C Streams769391
! Ref: gnat_rm/the_implementation_of_standard_i_o id26769519
! Ref: 2d3769519
! Ref: gnat_rm/the_implementation_of_standard_i_o interfacing-to-c-streams769519
! Ref: 2d4769519
! Node: The GNAT Library772831
! Ref: gnat_rm/the_gnat_library doc772970
! Ref: 2d5772970
! Ref: gnat_rm/the_gnat_library id1772970
! Ref: 2d6772970
! Ref: gnat_rm/the_gnat_library the-gnat-library772970
! Ref: 10772970
! Node: Ada Characters Latin_9 a-chlat9 ads785850
! Ref: gnat_rm/the_gnat_library ada-characters-latin-9-a-chlat9-ads785988
! Ref: 2d7785988
! Ref: gnat_rm/the_gnat_library id2785988
! Ref: 2d8785988
! Node: Ada Characters Wide_Latin_1 a-cwila1 ads786398
! Ref: gnat_rm/the_gnat_library ada-characters-wide-latin-1-a-cwila1-ads786585
! Ref: 2d9786585
! Ref: gnat_rm/the_gnat_library id3786585
! Ref: 2da786585
! Node: Ada Characters Wide_Latin_9 a-cwila9 ads787037
! Ref: gnat_rm/the_gnat_library ada-characters-wide-latin-9-a-cwila9-ads787234
! Ref: 2db787234
! Ref: gnat_rm/the_gnat_library id4787234
! Ref: 2dc787234
! Node: Ada Characters Wide_Wide_Latin_1 a-chzla1 ads787688
! Ref: gnat_rm/the_gnat_library ada-characters-wide-wide-latin-1-a-chzla1-ads787890
! Ref: 2dd787890
! Ref: gnat_rm/the_gnat_library id5787890
! Ref: 2de787890
! Node: Ada Characters Wide_Wide_Latin_9 a-chzla9 ads788357
! Ref: gnat_rm/the_gnat_library ada-characters-wide-wide-latin-9-a-chzla9-ads788562
! Ref: 2df788562
! Ref: gnat_rm/the_gnat_library id6788562
! Ref: 2e0788562
! Node: Ada Containers Bounded_Holders a-coboho ads789031
! Ref: gnat_rm/the_gnat_library ada-containers-bounded-holders-a-coboho-ads789232
! Ref: 2e1789232
! Ref: gnat_rm/the_gnat_library id7789232
! Ref: 2e2789232
! Node: Ada Command_Line Environment a-colien ads789465
! Ref: gnat_rm/the_gnat_library ada-command-line-environment-a-colien-ads789657
! Ref: 2e3789657
! Ref: gnat_rm/the_gnat_library id8789657
! Ref: 2e4789657
! Node: Ada Command_Line Remove a-colire ads789907
! Ref: gnat_rm/the_gnat_library ada-command-line-remove-a-colire-ads790099
! Ref: 2e5790099
! Ref: gnat_rm/the_gnat_library id9790099
! Ref: 2e6790099
! Node: Ada Command_Line Response_File a-clrefi ads790472
! Ref: gnat_rm/the_gnat_library ada-command-line-response-file-a-clrefi-ads790659
! Ref: 2e7790659
! Ref: gnat_rm/the_gnat_library id10790659
! Ref: 2e8790659
! Node: Ada Direct_IO C_Streams a-diocst ads791071
! Ref: gnat_rm/the_gnat_library ada-direct-io-c-streams-a-diocst-ads791268
! Ref: 2e9791268
! Ref: gnat_rm/the_gnat_library id11791268
! Ref: 2ea791268
! Node: Ada Exceptions Is_Null_Occurrence a-einuoc ads791619
! Ref: gnat_rm/the_gnat_library ada-exceptions-is-null-occurrence-a-einuoc-ads791820
! Ref: 2eb791820
! Ref: gnat_rm/the_gnat_library id12791820
! Ref: 2ec791820
! Node: Ada Exceptions Last_Chance_Handler a-elchha ads792084
! Ref: gnat_rm/the_gnat_library ada-exceptions-last-chance-handler-a-elchha-ads792286
! Ref: 2ed792286
! Ref: gnat_rm/the_gnat_library id13792286
! Ref: 2ee792286
! Node: Ada Exceptions Traceback a-exctra ads792616
! Ref: gnat_rm/the_gnat_library ada-exceptions-traceback-a-exctra-ads792812
! Ref: 2ef792812
! Ref: gnat_rm/the_gnat_library id14792812
! Ref: 2f0792812
! Node: Ada Sequential_IO C_Streams a-siocst ads793057
! Ref: gnat_rm/the_gnat_library ada-sequential-io-c-streams-a-siocst-ads793250
! Ref: 2f1793250
! Ref: gnat_rm/the_gnat_library id15793250
! Ref: 2f2793250
! Node: Ada Streams Stream_IO C_Streams a-ssicst ads793613
! Ref: gnat_rm/the_gnat_library ada-streams-stream-io-c-streams-a-ssicst-ads793811
! Ref: 2f3793811
! Ref: gnat_rm/the_gnat_library id16793811
! Ref: 2f4793811
! Node: Ada Strings Unbounded Text_IO a-suteio ads794178
! Ref: gnat_rm/the_gnat_library ada-strings-unbounded-text-io-a-suteio-ads794388
! Ref: 2f5794388
! Ref: gnat_rm/the_gnat_library id17794388
! Ref: 2f6794388
! Node: Ada Strings Wide_Unbounded Wide_Text_IO a-swuwti ads794653
! Ref: gnat_rm/the_gnat_library ada-strings-wide-unbounded-wide-text-io-a-swuwti-ads794881
! Ref: 2f7794881
! Ref: gnat_rm/the_gnat_library id18794881
! Ref: 2f8794881
! Node: Ada Strings Wide_Wide_Unbounded Wide_Wide_Text_IO a-szuzti ads795176
! Ref: gnat_rm/the_gnat_library ada-strings-wide-wide-unbounded-wide-wide-text-io-a-szuzti-ads795398
! Ref: 2f9795398
! Ref: gnat_rm/the_gnat_library id19795398
! Ref: 2fa795398
! Node: Ada Task_Initialization a-tasini ads795723
! Ref: gnat_rm/the_gnat_library ada-task-initialization-a-tasini-ads795927
! Ref: 2fb795927
! Ref: gnat_rm/the_gnat_library id20795927
! Ref: 2fc795927
! Node: Ada Text_IO C_Streams a-tiocst ads796296
! Ref: gnat_rm/the_gnat_library ada-text-io-c-streams-a-tiocst-ads796483
! Ref: 2fd796483
! Ref: gnat_rm/the_gnat_library id21796483
! Ref: 2fe796483
! Node: Ada Text_IO Reset_Standard_Files a-tirsfi ads796828
! Ref: gnat_rm/the_gnat_library ada-text-io-reset-standard-files-a-tirsfi-ads797019
! Ref: 2ff797019
! Ref: gnat_rm/the_gnat_library id22797019
! Ref: 300797019
! Node: Ada Wide_Characters Unicode a-wichun ads797438
! Ref: gnat_rm/the_gnat_library ada-wide-characters-unicode-a-wichun-ads797634
! Ref: 301797634
! Ref: gnat_rm/the_gnat_library id23797634
! Ref: 302797634
! Node: Ada Wide_Text_IO C_Streams a-wtcstr ads797868
! Ref: gnat_rm/the_gnat_library ada-wide-text-io-c-streams-a-wtcstr-ads798069
! Ref: 303798069
! Ref: gnat_rm/the_gnat_library id24798069
! Ref: 304798069
! Node: Ada Wide_Text_IO Reset_Standard_Files a-wrstfi ads798429
! Ref: gnat_rm/the_gnat_library ada-wide-text-io-reset-standard-files-a-wrstfi-ads798635
! Ref: 305798635
! Ref: gnat_rm/the_gnat_library id25798635
! Ref: 306798635
! Node: Ada Wide_Wide_Characters Unicode a-zchuni ads799069
! Ref: gnat_rm/the_gnat_library ada-wide-wide-characters-unicode-a-zchuni-ads799280
! Ref: 307799280
! Ref: gnat_rm/the_gnat_library id26799280
! Ref: 308799280
! Node: Ada Wide_Wide_Text_IO C_Streams a-ztcstr ads799529
! Ref: gnat_rm/the_gnat_library ada-wide-wide-text-io-c-streams-a-ztcstr-ads799745
! Ref: 309799745
! Ref: gnat_rm/the_gnat_library id27799745
! Ref: 30a799745
! Node: Ada Wide_Wide_Text_IO Reset_Standard_Files a-zrstfi ads800120
! Ref: gnat_rm/the_gnat_library ada-wide-wide-text-io-reset-standard-files-a-zrstfi-ads800316
! Ref: 30b800316
! Ref: gnat_rm/the_gnat_library id28800316
! Ref: 30c800316
! Node: GNAT Altivec g-altive ads800765
! Ref: gnat_rm/the_gnat_library gnat-altivec-g-altive-ads800954
! Ref: 30d800954
! Ref: gnat_rm/the_gnat_library id29800954
! Ref: 30e800954
! Node: GNAT Altivec Conversions g-altcon ads801185
! Ref: gnat_rm/the_gnat_library gnat-altivec-conversions-g-altcon-ads801362
! Ref: 30f801362
! Ref: gnat_rm/the_gnat_library id30801362
! Ref: 310801362
! Node: GNAT Altivec Vector_Operations g-alveop ads801531
! Ref: gnat_rm/the_gnat_library gnat-altivec-vector-operations-g-alveop-ads801721
! Ref: 311801721
! Ref: gnat_rm/the_gnat_library id31801721
! Ref: 312801721
! Node: GNAT Altivec Vector_Types g-alvety ads802081
! Ref: gnat_rm/the_gnat_library gnat-altivec-vector-types-g-alvety-ads802272
! Ref: 313802272
! Ref: gnat_rm/the_gnat_library id32802272
! Ref: 314802272
! Node: GNAT Altivec Vector_Views g-alvevi ads802477
! Ref: gnat_rm/the_gnat_library gnat-altivec-vector-views-g-alvevi-ads802654
! Ref: 315802654
! Ref: gnat_rm/the_gnat_library id33802654
! Ref: 316802654
! Node: GNAT Array_Split g-arrspl ads803025
! Ref: gnat_rm/the_gnat_library gnat-array-split-g-arrspl-ads803182
! Ref: 317803182
! Ref: gnat_rm/the_gnat_library id34803182
! Ref: 318803182
! Node: GNAT AWK g-awk ads803437
! Ref: gnat_rm/the_gnat_library gnat-awk-g-awk-ads803587
! Ref: 319803587
! Ref: gnat_rm/the_gnat_library id35803587
! Ref: 31a803587
! Node: GNAT Binary_Search g-binsea ads803882
! Ref: gnat_rm/the_gnat_library gnat-binary-search-g-binsea-ads804037
! Ref: 31b804037
! Ref: gnat_rm/the_gnat_library id36804037
! Ref: 31c804037
! Node: GNAT Bind_Environment g-binenv ads804257
! Ref: gnat_rm/the_gnat_library gnat-bind-environment-g-binenv-ads804429
! Ref: 31d804429
! Ref: gnat_rm/the_gnat_library id37804429
! Ref: 31e804429
! Node: GNAT Branch_Prediction g-brapre ads804682
! Ref: gnat_rm/the_gnat_library gnat-branch-prediction-g-brapre-ads804856
! Ref: 31f804856
! Ref: gnat_rm/the_gnat_library id38804856
! Ref: 320804856
! Node: GNAT Bounded_Buffers g-boubuf ads805040
! Ref: gnat_rm/the_gnat_library gnat-bounded-buffers-g-boubuf-ads805215
! Ref: 321805215
! Ref: gnat_rm/the_gnat_library id39805215
! Ref: 322805215
! Node: GNAT Bounded_Mailboxes g-boumai ads805483
! Ref: gnat_rm/the_gnat_library gnat-bounded-mailboxes-g-boumai-ads805652
! Ref: 323805652
! Ref: gnat_rm/the_gnat_library id40805652
! Ref: 324805652
! Node: GNAT Bubble_Sort g-bubsor ads805836
! Ref: gnat_rm/the_gnat_library gnat-bubble-sort-g-bubsor-ads806003
! Ref: 325806003
! Ref: gnat_rm/the_gnat_library id41806003
! Ref: 326806003
! Node: GNAT Bubble_Sort_A g-busora ads806275
! Ref: gnat_rm/the_gnat_library gnat-bubble-sort-a-g-busora-ads806438
! Ref: 327806438
! Ref: gnat_rm/the_gnat_library id42806438
! Ref: 328806438
! Node: GNAT Bubble_Sort_G g-busorg ads806817
! Ref: gnat_rm/the_gnat_library gnat-bubble-sort-g-g-busorg-ads806984
! Ref: 329806984
! Ref: gnat_rm/the_gnat_library id43806984
! Ref: 32a806984
! Node: GNAT Byte_Order_Mark g-byorma ads807328
! Ref: gnat_rm/the_gnat_library gnat-byte-order-mark-g-byorma-ads807495
! Ref: 32b807495
! Ref: gnat_rm/the_gnat_library id44807495
! Ref: 32c807495
! Node: GNAT Byte_Swapping g-bytswa ads807865
! Ref: gnat_rm/the_gnat_library gnat-byte-swapping-g-bytswa-ads808027
! Ref: 32d808027
! Ref: gnat_rm/the_gnat_library id45808027
! Ref: 32e808027
! Node: GNAT Calendar g-calend ads808262
! Ref: gnat_rm/the_gnat_library gnat-calendar-g-calend-ads808425
! Ref: 32f808425
! Ref: gnat_rm/the_gnat_library id46808425
! Ref: 330808425
! Node: GNAT Calendar Time_IO g-catiio ads808762
! Ref: gnat_rm/the_gnat_library gnat-calendar-time-io-g-catiio-ads808916
! Ref: 331808916
! Ref: gnat_rm/the_gnat_library id47808916
! Ref: 332808916
! Node: GNAT CRC32 g-crc32 ads809019
! Ref: gnat_rm/the_gnat_library gnat-crc32-g-crc32-ads809174
! Ref: 333809174
! Ref: gnat_rm/the_gnat_library id48809174
! Ref: 334809174
! Node: GNAT Case_Util g-casuti ads809504
! Ref: gnat_rm/the_gnat_library gnat-case-util-g-casuti-ads809643
! Ref: 335809643
! Ref: gnat_rm/the_gnat_library id49809643
! Ref: 336809643
! Node: GNAT CGI g-cgi ads809886
! Ref: gnat_rm/the_gnat_library gnat-cgi-g-cgi-ads810031
! Ref: 337810031
! Ref: gnat_rm/the_gnat_library id50810031
! Ref: 338810031
! Node: GNAT CGI Cookie g-cgicoo ads810413
! Ref: gnat_rm/the_gnat_library gnat-cgi-cookie-g-cgicoo-ads810558
! Ref: 339810558
! Ref: gnat_rm/the_gnat_library id51810558
! Ref: 33a810558
! Node: GNAT CGI Debug g-cgideb ads810855
! Ref: gnat_rm/the_gnat_library gnat-cgi-debug-g-cgideb-ads811012
! Ref: 33b811012
! Ref: gnat_rm/the_gnat_library id52811012
! Ref: 33c811012
! Node: GNAT Command_Line g-comlin ads811194
! Ref: gnat_rm/the_gnat_library gnat-command-line-g-comlin-ads811357
! Ref: 33d811357
! Ref: gnat_rm/the_gnat_library id53811357
! Ref: 33e811357
! Node: GNAT Compiler_Version g-comver ads811645
! Ref: gnat_rm/the_gnat_library gnat-compiler-version-g-comver-ads811805
! Ref: 33f811805
! Ref: gnat_rm/the_gnat_library id54811805
! Ref: 340811805
! Node: GNAT Ctrl_C g-ctrl_c ads812209
! Ref: gnat_rm/the_gnat_library gnat-ctrl-c-g-ctrl-c-ads812374
! Ref: 341812374
! Ref: gnat_rm/the_gnat_library id55812374
! Ref: 342812374
! Node: GNAT Current_Exception g-curexc ads812520
! Ref: gnat_rm/the_gnat_library gnat-current-exception-g-curexc-ads812680
! Ref: 343812680
! Ref: gnat_rm/the_gnat_library id56812680
! Ref: 344812680
! Node: GNAT Debug_Pools g-debpoo ads813096
! Ref: gnat_rm/the_gnat_library gnat-debug-pools-g-debpoo-ads813265
! Ref: 345813265
! Ref: gnat_rm/the_gnat_library id57813265
! Ref: 346813265
! Node: GNAT Debug_Utilities g-debuti ads813524
! Ref: gnat_rm/the_gnat_library gnat-debug-utilities-g-debuti-ads813689
! Ref: 347813689
! Ref: gnat_rm/the_gnat_library id58813689
! Ref: 348813689
! Node: GNAT Decode_String g-decstr ads813972
! Ref: gnat_rm/the_gnat_library gnat-decode-string-g-decstr-ads814144
! Ref: 349814144
! Ref: gnat_rm/the_gnat_library id59814144
! Ref: 34a814144
! Node: GNAT Decode_UTF8_String g-deutst ads814652
! Ref: gnat_rm/the_gnat_library gnat-decode-utf8-string-g-deutst-ads814829
! Ref: 34b814829
! Ref: gnat_rm/the_gnat_library id60814829
! Ref: 34c814829
! Node: GNAT Directory_Operations g-dirope ads814999
! Ref: gnat_rm/the_gnat_library gnat-directory-operations-g-dirope-ads815193
! Ref: 34d815193
! Ref: gnat_rm/the_gnat_library id61815193
! Ref: 34e815193
! Node: GNAT Directory_Operations Iteration g-diopit ads815467
! Ref: gnat_rm/the_gnat_library gnat-directory-operations-iteration-g-diopit-ads815658
! Ref: 34f815658
! Ref: gnat_rm/the_gnat_library id62815658
! Ref: 350815658
! Node: GNAT Dynamic_HTables g-dynhta ads815899
! Ref: gnat_rm/the_gnat_library gnat-dynamic-htables-g-dynhta-ads816084
! Ref: 351816084
! Ref: gnat_rm/the_gnat_library id63816084
! Ref: 352816084
! Node: GNAT Dynamic_Tables g-dyntab ads816665
! Ref: gnat_rm/the_gnat_library gnat-dynamic-tables-g-dyntab-ads816833
! Ref: 353816833
! Ref: gnat_rm/the_gnat_library id64816833
! Ref: 354816833
! Node: GNAT Encode_String g-encstr ads817316
! Ref: gnat_rm/the_gnat_library gnat-encode-string-g-encstr-ads817487
! Ref: 355817487
! Ref: gnat_rm/the_gnat_library id65817487
! Ref: 356817487
! Node: GNAT Encode_UTF8_String g-enutst ads817866
! Ref: gnat_rm/the_gnat_library gnat-encode-utf8-string-g-enutst-ads818040
! Ref: 357818040
! Ref: gnat_rm/the_gnat_library id66818040
! Ref: 358818040
! Node: GNAT Exception_Actions g-excact ads818210
! Ref: gnat_rm/the_gnat_library gnat-exception-actions-g-excact-ads818387
! Ref: 359818387
! Ref: gnat_rm/the_gnat_library id67818387
! Ref: 35a818387
! Node: GNAT Exception_Traces g-exctra ads818698
! Ref: gnat_rm/the_gnat_library gnat-exception-traces-g-exctra-ads818867
! Ref: 35b818867
! Ref: gnat_rm/the_gnat_library id68818867
! Ref: 35c818867
! Node: GNAT Exceptions g-except ads819058
! Ref: gnat_rm/the_gnat_library gnat-exceptions-g-except-ads819216
! Ref: 35d819216
! Ref: gnat_rm/the_gnat_library id69819216
! Ref: 35e819216
! Node: GNAT Expect g-expect ads819710
! Ref: gnat_rm/the_gnat_library gnat-expect-g-expect-ads819862
! Ref: 35f819862
! Ref: gnat_rm/the_gnat_library id70819862
! Ref: 360819862
! Node: GNAT Expect TTY g-exptty ads820393
! Ref: gnat_rm/the_gnat_library gnat-expect-tty-g-exptty-ads820548
! Ref: 361820548
! Ref: gnat_rm/the_gnat_library id71820548
! Ref: 362820548
! Node: GNAT Float_Control g-flocon ads820856
! Ref: gnat_rm/the_gnat_library gnat-float-control-g-flocon-ads821021
! Ref: 363821021
! Ref: gnat_rm/the_gnat_library id72821021
! Ref: 364821021
! Node: GNAT Formatted_String g-forstr ads821400
! Ref: gnat_rm/the_gnat_library gnat-formatted-string-g-forstr-ads821582
! Ref: 365821582
! Ref: gnat_rm/the_gnat_library id73821582
! Ref: 366821582
! Node: GNAT Generic_Fast_Math_Functions g-gfmafu ads821973
! Ref: gnat_rm/the_gnat_library gnat-generic-fast-math-functions-g-gfmafu-ads822151
! Ref: 367822151
! Ref: gnat_rm/the_gnat_library id74822151
! Ref: 368822151
! Node: GNAT Heap_Sort g-heasor ads822824
! Ref: gnat_rm/the_gnat_library gnat-heap-sort-g-heasor-ads822997
! Ref: 369822997
! Ref: gnat_rm/the_gnat_library id75822997
! Ref: 36a822997
! Node: GNAT Heap_Sort_A g-hesora ads823375
! Ref: gnat_rm/the_gnat_library gnat-heap-sort-a-g-hesora-ads823532
! Ref: 36b823532
! Ref: gnat_rm/the_gnat_library id76823532
! Ref: 36c823532
! Node: GNAT Heap_Sort_G g-hesorg ads824025
! Ref: gnat_rm/the_gnat_library gnat-heap-sort-g-g-hesorg-ads824179
! Ref: 36d824179
! Ref: gnat_rm/the_gnat_library id77824179
! Ref: 36e824179
! Node: GNAT HTable g-htable ads824517
! Ref: gnat_rm/the_gnat_library gnat-htable-g-htable-ads824658
! Ref: 36f824658
! Ref: gnat_rm/the_gnat_library id78824658
! Ref: 370824658
! Node: GNAT IO g-io ads824933
! Ref: gnat_rm/the_gnat_library gnat-io-g-io-ads825069
! Ref: 371825069
! Ref: gnat_rm/the_gnat_library id79825069
! Ref: 372825069
! Node: GNAT IO_Aux g-io_aux ads825378
! Ref: gnat_rm/the_gnat_library gnat-io-aux-g-io-aux-ads825518
! Ref: 373825518
! Ref: gnat_rm/the_gnat_library id80825518
! Ref: 374825518
! Node: GNAT Lock_Files g-locfil ads825744
! Ref: gnat_rm/the_gnat_library gnat-lock-files-g-locfil-ads825906
! Ref: 375825906
! Ref: gnat_rm/the_gnat_library id81825906
! Ref: 376825906
! Node: GNAT MBBS_Discrete_Random g-mbdira ads826111
! Ref: gnat_rm/the_gnat_library gnat-mbbs-discrete-random-g-mbdira-ads826284
! Ref: 377826284
! Ref: gnat_rm/the_gnat_library id82826284
! Ref: 378826284
! Node: GNAT MBBS_Float_Random g-mbflra ads826521
! Ref: gnat_rm/the_gnat_library gnat-mbbs-float-random-g-mbflra-ads826684
! Ref: 379826684
! Ref: gnat_rm/the_gnat_library id83826684
! Ref: 37a826684
! Node: GNAT MD5 g-md5 ads826912
! Ref: gnat_rm/the_gnat_library gnat-md5-g-md5-ads827066
! Ref: 37b827066
! Ref: gnat_rm/the_gnat_library id84827066
! Ref: 37c827066
! Node: GNAT Memory_Dump g-memdum ads827300
! Ref: gnat_rm/the_gnat_library gnat-memory-dump-g-memdum-ads827458
! Ref: 37d827458
! Ref: gnat_rm/the_gnat_library id85827458
! Ref: 37e827458
! Node: GNAT Most_Recent_Exception g-moreex ads827693
! Ref: gnat_rm/the_gnat_library gnat-most-recent-exception-g-moreex-ads827857
! Ref: 37f827857
! Ref: gnat_rm/the_gnat_library id86827857
! Ref: 380827857
! Node: GNAT OS_Lib g-os_lib ads828157
! Ref: gnat_rm/the_gnat_library gnat-os-lib-g-os-lib-ads828333
! Ref: 381828333
! Ref: gnat_rm/the_gnat_library id87828333
! Ref: 382828333
! Node: GNAT Perfect_Hash_Generators g-pehage ads828664
! Ref: gnat_rm/the_gnat_library gnat-perfect-hash-generators-g-pehage-ads828833
! Ref: 383828833
! Ref: gnat_rm/the_gnat_library id88828833
! Ref: 384828833
! Node: GNAT Random_Numbers g-rannum ads829485
! Ref: gnat_rm/the_gnat_library gnat-random-numbers-g-rannum-ads829654
! Ref: 385829654
! Ref: gnat_rm/the_gnat_library id89829654
! Ref: 386829654
! Node: GNAT Regexp g-regexp ads829879
! Ref: gnat_rm/the_gnat_library gnat-regexp-g-regexp-ads830033
! Ref: 25c830033
! Ref: gnat_rm/the_gnat_library id90830033
! Ref: 387830033
! Node: GNAT Registry g-regist ads830389
! Ref: gnat_rm/the_gnat_library gnat-registry-g-regist-ads830535
! Ref: 388830535
! Ref: gnat_rm/the_gnat_library id91830535
! Ref: 389830535
! Node: GNAT Regpat g-regpat ads830889
! Ref: gnat_rm/the_gnat_library gnat-regpat-g-regpat-ads831041
! Ref: 38a831041
! Ref: gnat_rm/the_gnat_library id92831041
! Ref: 38b831041
! Node: GNAT Rewrite_Data g-rewdat ads831330
! Ref: gnat_rm/the_gnat_library gnat-rewrite-data-g-rewdat-ads831494
! Ref: 38c831494
! Ref: gnat_rm/the_gnat_library id93831494
! Ref: 38d831494
! Node: GNAT Secondary_Stack_Info g-sestin ads831858
! Ref: gnat_rm/the_gnat_library gnat-secondary-stack-info-g-sestin-ads832026
! Ref: 38e832026
! Ref: gnat_rm/the_gnat_library id94832026
! Ref: 38f832026
! Node: GNAT Semaphores g-semaph ads832232
! Ref: gnat_rm/the_gnat_library gnat-semaphores-g-semaph-ads832409
! Ref: 390832409
! Ref: gnat_rm/the_gnat_library id95832409
! Ref: 391832409
! Node: GNAT Serial_Communications g-sercom ads832572
! Ref: gnat_rm/the_gnat_library gnat-serial-communications-g-sercom-ads832731
! Ref: 392832731
! Ref: gnat_rm/the_gnat_library id96832731
! Ref: 393832731
! Node: GNAT SHA1 g-sha1 ads832967
! Ref: gnat_rm/the_gnat_library gnat-sha1-g-sha1-ads833122
! Ref: 394833122
! Ref: gnat_rm/the_gnat_library id97833122
! Ref: 395833122
! Node: GNAT SHA224 g-sha224 ads833379
! Ref: gnat_rm/the_gnat_library gnat-sha224-g-sha224-ads833519
! Ref: 396833519
! Ref: gnat_rm/the_gnat_library id98833519
! Ref: 397833519
! Node: GNAT SHA256 g-sha256 ads833775
! Ref: gnat_rm/the_gnat_library gnat-sha256-g-sha256-ads833919
! Ref: 398833919
! Ref: gnat_rm/the_gnat_library id99833919
! Ref: 399833919
! Node: GNAT SHA384 g-sha384 ads834175
! Ref: gnat_rm/the_gnat_library gnat-sha384-g-sha384-ads834319
! Ref: 39a834319
! Ref: gnat_rm/the_gnat_library id100834319
! Ref: 39b834319
! Node: GNAT SHA512 g-sha512 ads834575
! Ref: gnat_rm/the_gnat_library gnat-sha512-g-sha512-ads834720
! Ref: 39c834720
! Ref: gnat_rm/the_gnat_library id101834720
! Ref: 39d834720
! Node: GNAT Signals g-signal ads834978
! Ref: gnat_rm/the_gnat_library gnat-signals-g-signal-ads835124
! Ref: 39e835124
! Ref: gnat_rm/the_gnat_library id102835124
! Ref: 39f835124
! Node: GNAT Sockets g-socket ads835299
! Ref: gnat_rm/the_gnat_library gnat-sockets-g-socket-ads835450
! Ref: 3a0835450
! Ref: gnat_rm/the_gnat_library id103835450
! Ref: 3a1835450
! Node: GNAT Source_Info g-souinf ads835846
! Ref: gnat_rm/the_gnat_library gnat-source-info-g-souinf-ads836006
! Ref: 3a2836006
! Ref: gnat_rm/the_gnat_library id104836006
! Ref: 3a3836006
! Node: GNAT Spelling_Checker g-speche ads836372
! Ref: gnat_rm/the_gnat_library gnat-spelling-checker-g-speche-ads836549
! Ref: 3a4836549
! Ref: gnat_rm/the_gnat_library id105836549
! Ref: 3a5836549
! Node: GNAT Spelling_Checker_Generic g-spchge ads836761
! Ref: gnat_rm/the_gnat_library gnat-spelling-checker-generic-g-spchge-ads836943
! Ref: 3a6836943
! Ref: gnat_rm/the_gnat_library id106836943
! Ref: 3a7836943
! Node: GNAT Spitbol Patterns g-spipat ads837223
! Ref: gnat_rm/the_gnat_library gnat-spitbol-patterns-g-spipat-ads837396
! Ref: 3a8837396
! Ref: gnat_rm/the_gnat_library id107837396
! Ref: 3a9837396
! Node: GNAT Spitbol g-spitbo ads837803
! Ref: gnat_rm/the_gnat_library gnat-spitbol-g-spitbo-ads837973
! Ref: 3aa837973
! Ref: gnat_rm/the_gnat_library id108837973
! Ref: 3ab837973
! Node: GNAT Spitbol Table_Boolean g-sptabo ads838383
! Ref: gnat_rm/the_gnat_library gnat-spitbol-table-boolean-g-sptabo-ads838558
! Ref: 3ac838558
! Ref: gnat_rm/the_gnat_library id109838558
! Ref: 3ad838558
! Node: GNAT Spitbol Table_Integer g-sptain ads838828
! Ref: gnat_rm/the_gnat_library gnat-spitbol-table-integer-g-sptain-ads839017
! Ref: 3ae839017
! Ref: gnat_rm/the_gnat_library id110839017
! Ref: 3af839017
! Node: GNAT Spitbol Table_VString g-sptavs ads839300
! Ref: gnat_rm/the_gnat_library gnat-spitbol-table-vstring-g-sptavs-ads839468
! Ref: 3b0839468
! Ref: gnat_rm/the_gnat_library id111839468
! Ref: 3b1839468
! Node: GNAT SSE g-sse ads839755
! Ref: gnat_rm/the_gnat_library gnat-sse-g-sse-ads839918
! Ref: 3b2839918
! Ref: gnat_rm/the_gnat_library id112839918
! Ref: 3b3839918
! Node: GNAT SSE Vector_Types g-ssvety ads840245
! Ref: gnat_rm/the_gnat_library gnat-sse-vector-types-g-ssvety-ads840398
! Ref: 3b4840398
! Ref: gnat_rm/the_gnat_library id113840398
! Ref: 3b5840398
! Node: GNAT String_Hash g-strhas ads840558
! Ref: gnat_rm/the_gnat_library gnat-string-hash-g-strhas-ads840718
! Ref: 3b6840718
! Ref: gnat_rm/the_gnat_library id114840718
! Ref: 3b7840718
! Node: GNAT Strings g-string ads840940
! Ref: gnat_rm/the_gnat_library gnat-strings-g-string-ads841096
! Ref: 3b8841096
! Ref: gnat_rm/the_gnat_library id115841096
! Ref: 3b9841096
! Node: GNAT String_Split g-strspl ads841311
! Ref: gnat_rm/the_gnat_library gnat-string-split-g-strspl-ads841460
! Ref: 3ba841460
! Ref: gnat_rm/the_gnat_library id116841460
! Ref: 3bb841460
! Node: GNAT Table g-table ads841779
! Ref: gnat_rm/the_gnat_library gnat-table-g-table-ads841930
! Ref: 3bc841930
! Ref: gnat_rm/the_gnat_library id117841930
! Ref: 3bd841930
! Node: GNAT Task_Lock g-tasloc ads842413
! Ref: gnat_rm/the_gnat_library gnat-task-lock-g-tasloc-ads842562
! Ref: 3be842562
! Ref: gnat_rm/the_gnat_library id118842562
! Ref: 3bf842562
! Node: GNAT Time_Stamp g-timsta ads842844
! Ref: gnat_rm/the_gnat_library gnat-time-stamp-g-timsta-ads842996
! Ref: 3c0842996
! Ref: gnat_rm/the_gnat_library id119842996
! Ref: 3c1842996
! Node: GNAT Threads g-thread ads843322
! Ref: gnat_rm/the_gnat_library gnat-threads-g-thread-ads843474
! Ref: 3c2843474
! Ref: gnat_rm/the_gnat_library id120843474
! Ref: 3c3843474
! Node: GNAT Traceback g-traceb ads843830
! Ref: gnat_rm/the_gnat_library gnat-traceback-g-traceb-ads843990
! Ref: 3c4843990
! Ref: gnat_rm/the_gnat_library id121843990
! Ref: 3c5843990
! Node: GNAT Traceback Symbolic g-trasym ads844192
! Ref: gnat_rm/the_gnat_library gnat-traceback-symbolic-g-trasym-ads844351
! Ref: 3c6844351
! Ref: gnat_rm/the_gnat_library id122844351
! Ref: 3c7844351
! Node: GNAT UTF_32 g-utf_32 ads844460
! Ref: gnat_rm/the_gnat_library gnat-utf-32-g-utf-32-ads844633
! Ref: 3c8844633
! Ref: gnat_rm/the_gnat_library id123844633
! Ref: 3c9844633
! Node: GNAT UTF_32_Spelling_Checker g-u3spch ads845197
! Ref: gnat_rm/the_gnat_library gnat-utf-32-spelling-checker-g-u3spch-ads845373
! Ref: 3ca845373
! Ref: gnat_rm/the_gnat_library id124845373
! Ref: 3cb845373
! Node: GNAT Wide_Spelling_Checker g-wispch ads845709
! Ref: gnat_rm/the_gnat_library gnat-wide-spelling-checker-g-wispch-ads845896
! Ref: 3cc845896
! Ref: gnat_rm/the_gnat_library id125845896
! Ref: 3cd845896
! Node: GNAT Wide_String_Split g-wistsp ads846128
! Ref: gnat_rm/the_gnat_library gnat-wide-string-split-g-wistsp-ads846318
! Ref: 3ce846318
! Ref: gnat_rm/the_gnat_library id126846318
! Ref: 3cf846318
! Node: GNAT Wide_Wide_Spelling_Checker g-zspche ads846657
! Ref: gnat_rm/the_gnat_library gnat-wide-wide-spelling-checker-g-zspche-ads846848
! Ref: 3d0846848
! Ref: gnat_rm/the_gnat_library id127846848
! Ref: 3d1846848
! Node: GNAT Wide_Wide_String_Split g-zistsp ads847100
! Ref: gnat_rm/the_gnat_library gnat-wide-wide-string-split-g-zistsp-ads847292
! Ref: 3d2847292
! Ref: gnat_rm/the_gnat_library id128847292
! Ref: 3d3847292
! Node: Interfaces C Extensions i-cexten ads847651
! Ref: gnat_rm/the_gnat_library id129847832
! Ref: 3d4847832
! Ref: gnat_rm/the_gnat_library interfaces-c-extensions-i-cexten-ads847832
! Ref: 3d5847832
! Node: Interfaces C Streams i-cstrea ads848088
! Ref: gnat_rm/the_gnat_library id130848267
! Ref: 3d6848267
! Ref: gnat_rm/the_gnat_library interfaces-c-streams-i-cstrea-ads848267
! Ref: 3d7848267
! Node: Interfaces Packed_Decimal i-pacdec ads848449
! Ref: gnat_rm/the_gnat_library id131848623
! Ref: 3d8848623
! Ref: gnat_rm/the_gnat_library interfaces-packed-decimal-i-pacdec-ads848623
! Ref: 3d9848623
! Node: Interfaces VxWorks i-vxwork ads848874
! Ref: gnat_rm/the_gnat_library id132849061
! Ref: 3da849061
! Ref: gnat_rm/the_gnat_library interfaces-vxworks-i-vxwork-ads849061
! Ref: 3db849061
! Node: Interfaces VxWorks Int_Connection i-vxinco ads849298
! Ref: gnat_rm/the_gnat_library id133849481
! Ref: 3dc849481
! Ref: gnat_rm/the_gnat_library interfaces-vxworks-int-connection-i-vxinco-ads849481
! Ref: 3dd849481
! Node: Interfaces VxWorks IO i-vxwoio ads849741
! Ref: gnat_rm/the_gnat_library id134849926
! Ref: 3de849926
! Ref: gnat_rm/the_gnat_library interfaces-vxworks-io-i-vxwoio-ads849926
! Ref: 3df849926
! Node: System Address_Image s-addima ads850250
! Ref: gnat_rm/the_gnat_library id135850419
! Ref: 3e0850419
! Ref: gnat_rm/the_gnat_library system-address-image-s-addima-ads850419
! Ref: 3e1850419
! Node: System Assertions s-assert ads850651
! Ref: gnat_rm/the_gnat_library id136850821
! Ref: 3e2850821
! Ref: gnat_rm/the_gnat_library system-assertions-s-assert-ads850821
! Ref: 3e3850821
! Node: System Atomic_Counters s-atocou ads851087
! Ref: gnat_rm/the_gnat_library id137851250
! Ref: 3e4851250
! Ref: gnat_rm/the_gnat_library system-atomic-counters-s-atocou-ads851250
! Ref: 3e5851250
! Node: System Memory s-memory ads851696
! Ref: gnat_rm/the_gnat_library id138851864
! Ref: 3e6851864
! Ref: gnat_rm/the_gnat_library system-memory-s-memory-ads851864
! Ref: 3e7851864
! Node: System Multiprocessors s-multip ads852472
! Ref: gnat_rm/the_gnat_library id139852660
! Ref: 3e8852660
! Ref: gnat_rm/the_gnat_library system-multiprocessors-s-multip-ads852660
! Ref: 3e9852660
! Node: System Multiprocessors Dispatching_Domains s-mudido ads852958
! Ref: gnat_rm/the_gnat_library id140853159
! Ref: 3ea853159
! Ref: gnat_rm/the_gnat_library system-multiprocessors-dispatching-domains-s-mudido-ads853159
! Ref: 3eb853159
! Node: System Partition_Interface s-parint ads853497
! Ref: gnat_rm/the_gnat_library id141853694
! Ref: 3ec853694
! Ref: gnat_rm/the_gnat_library system-partition-interface-s-parint-ads853694
! Ref: 3ed853694
! Node: System Pool_Global s-pooglo ads853955
! Ref: gnat_rm/the_gnat_library id142854127
! Ref: 3ee854127
! Ref: gnat_rm/the_gnat_library system-pool-global-s-pooglo-ads854127
! Ref: 3ef854127
! Node: System Pool_Local s-pooloc ads854469
! Ref: gnat_rm/the_gnat_library id143854634
! Ref: 3f0854634
! Ref: gnat_rm/the_gnat_library system-pool-local-s-pooloc-ads854634
! Ref: 3f1854634
! Node: System Restrictions s-restri ads855009
! Ref: gnat_rm/the_gnat_library id144855169
! Ref: 3f2855169
! Ref: gnat_rm/the_gnat_library system-restrictions-s-restri-ads855169
! Ref: 3f3855169
! Node: System Rident s-rident ads855607
! Ref: gnat_rm/the_gnat_library id145855775
! Ref: 3f4855775
! Ref: gnat_rm/the_gnat_library system-rident-s-rident-ads855775
! Ref: 3f5855775
! Node: System Strings Stream_Ops s-ststop ads856174
! Ref: gnat_rm/the_gnat_library id146856344
! Ref: 3f6856344
! Ref: gnat_rm/the_gnat_library system-strings-stream-ops-s-ststop-ads856344
! Ref: 3f7856344
! Node: System Unsigned_Types s-unstyp ads856739
! Ref: gnat_rm/the_gnat_library id147856910
! Ref: 3f8856910
! Ref: gnat_rm/the_gnat_library system-unsigned-types-s-unstyp-ads856910
! Ref: 3f9856910
! Node: System Wch_Cnv s-wchcnv ads857346
! Ref: gnat_rm/the_gnat_library id148857506
! Ref: 3fa857506
! Ref: gnat_rm/the_gnat_library system-wch-cnv-s-wchcnv-ads857506
! Ref: 3fb857506
! Node: System Wch_Con s-wchcon ads857849
! Ref: gnat_rm/the_gnat_library id149857966
! Ref: 3fc857966
! Ref: gnat_rm/the_gnat_library system-wch-con-s-wchcon-ads857966
! Ref: 3fd857966
! Node: Interfacing to Other Languages858252
! Ref: gnat_rm/interfacing_to_other_languages doc858382
! Ref: 3fe858382
! Ref: gnat_rm/interfacing_to_other_languages id1858382
! Ref: 3ff858382
! Ref: gnat_rm/interfacing_to_other_languages interfacing-to-other-languages858382
! Ref: 11858382
! Node: Interfacing to C858734
! Ref: gnat_rm/interfacing_to_other_languages id2858845
! Ref: 400858845
! Ref: gnat_rm/interfacing_to_other_languages interfacing-to-c858845
! Ref: 401858845
! Node: Interfacing to C++861648
! Ref: gnat_rm/interfacing_to_other_languages id3861788
! Ref: 47861788
! Ref: gnat_rm/interfacing_to_other_languages id4861788
! Ref: 402861788
! Node: Interfacing to COBOL863996
! Ref: gnat_rm/interfacing_to_other_languages id5864142
! Ref: 403864142
! Ref: gnat_rm/interfacing_to_other_languages interfacing-to-cobol864142
! Ref: 404864142
! Node: Interfacing to Fortran864286
! Ref: gnat_rm/interfacing_to_other_languages id6864446
! Ref: 405864446
! Ref: gnat_rm/interfacing_to_other_languages interfacing-to-fortran864446
! Ref: 406864446
! Node: Interfacing to non-GNAT Ada code864772
! Ref: gnat_rm/interfacing_to_other_languages id7864903
! Ref: 407864903
! Ref: gnat_rm/interfacing_to_other_languages interfacing-to-non-gnat-ada-code864903
! Ref: 408864903
! Node: Specialized Needs Annexes865930
! Ref: gnat_rm/specialized_needs_annexes doc866083
! Ref: 409866083
! Ref: gnat_rm/specialized_needs_annexes id1866083
! Ref: 40a866083
! Ref: gnat_rm/specialized_needs_annexes specialized-needs-annexes866083
! Ref: 12866083
! Node: Implementation of Specific Ada Features867178
! Ref: gnat_rm/implementation_of_specific_ada_features doc867336
! Ref: 40b867336
! Ref: gnat_rm/implementation_of_specific_ada_features id1867336
! Ref: 40c867336
! Ref: gnat_rm/implementation_of_specific_ada_features implementation-of-specific-ada-features867336
! Ref: 13867336
! Node: Machine Code Insertions867825
! Ref: gnat_rm/implementation_of_specific_ada_features id2867964
! Ref: 40d867964
! Ref: gnat_rm/implementation_of_specific_ada_features machine-code-insertions867964
! Ref: 166867964
! Node: GNAT Implementation of Tasking875390
! Ref: gnat_rm/implementation_of_specific_ada_features gnat-implementation-of-tasking875584
! Ref: 40e875584
! Ref: gnat_rm/implementation_of_specific_ada_features id3875584
! Ref: 40f875584
! Node: Mapping Ada Tasks onto the Underlying Kernel Threads875998
! Ref: gnat_rm/implementation_of_specific_ada_features id4876171
! Ref: 410876171
! Ref: gnat_rm/implementation_of_specific_ada_features mapping-ada-tasks-onto-the-underlying-kernel-threads876171
! Ref: 411876171
! Node: Ensuring Compliance with the Real-Time Annex878327
! Ref: gnat_rm/implementation_of_specific_ada_features ensuring-compliance-with-the-real-time-annex878537
! Ref: 412878537
! Ref: gnat_rm/implementation_of_specific_ada_features id5878537
! Ref: 413878537
! Node: Support for Locking Policies880453
! Ref: gnat_rm/implementation_of_specific_ada_features support-for-locking-policies880602
! Ref: 414880602
! Node: GNAT Implementation of Shared Passive Packages881761
! Ref: gnat_rm/implementation_of_specific_ada_features gnat-implementation-of-shared-passive-packages881968
! Ref: 415881968
! Ref: gnat_rm/implementation_of_specific_ada_features id6881968
! Ref: 416881968
! Node: Code Generation for Array Aggregates885094
! Ref: gnat_rm/implementation_of_specific_ada_features code-generation-for-array-aggregates885331
! Ref: 417885331
! Ref: gnat_rm/implementation_of_specific_ada_features id7885331
! Ref: 418885331
! Node: Static constant aggregates with static bounds886754
! Ref: gnat_rm/implementation_of_specific_ada_features id8886934
! Ref: 419886934
! Ref: gnat_rm/implementation_of_specific_ada_features static-constant-aggregates-with-static-bounds886934
! Ref: 41a886934
! Node: Constant aggregates with unconstrained nominal types888337
! Ref: gnat_rm/implementation_of_specific_ada_features constant-aggregates-with-unconstrained-nominal-types888555
! Ref: 41b888555
! Ref: gnat_rm/implementation_of_specific_ada_features id9888555
! Ref: 41c888555
! Node: Aggregates with static bounds889055
! Ref: gnat_rm/implementation_of_specific_ada_features aggregates-with-static-bounds889260
! Ref: 41d889260
! Ref: gnat_rm/implementation_of_specific_ada_features id10889260
! Ref: 41e889260
! Node: Aggregates with nonstatic bounds889894
! Ref: gnat_rm/implementation_of_specific_ada_features aggregates-with-nonstatic-bounds890082
! Ref: 41f890082
! Ref: gnat_rm/implementation_of_specific_ada_features id11890082
! Ref: 420890082
! Node: Aggregates in assignment statements890490
! Ref: gnat_rm/implementation_of_specific_ada_features aggregates-in-assignment-statements890640
! Ref: 421890640
! Ref: gnat_rm/implementation_of_specific_ada_features id12890640
! Ref: 422890640
! Node: The Size of Discriminated Records with Default Discriminants891898
! Ref: gnat_rm/implementation_of_specific_ada_features id13892121
! Ref: 423892121
! Ref: gnat_rm/implementation_of_specific_ada_features the-size-of-discriminated-records-with-default-discriminants892121
! Ref: 424892121
! Node: Image Values For Nonscalar Types895073
! Ref: gnat_rm/implementation_of_specific_ada_features id14895306
! Ref: 425895306
! Ref: gnat_rm/implementation_of_specific_ada_features image-values-for-nonscalar-types895306
! Ref: 426895306
! Node: Strict Conformance to the Ada Reference Manual896369
! Ref: gnat_rm/implementation_of_specific_ada_features id15896533
! Ref: 427896533
! Ref: gnat_rm/implementation_of_specific_ada_features strict-conformance-to-the-ada-reference-manual896533
! Ref: 428896533
! Node: Implementation of Ada 2012 Features897976
! Ref: gnat_rm/implementation_of_ada_2012_features doc898136
! Ref: 429898136
! Ref: gnat_rm/implementation_of_ada_2012_features id1898136
! Ref: 42a898136
! Ref: gnat_rm/implementation_of_ada_2012_features implementation-of-ada-2012-features898136
! Ref: 14898136
! Node: Security Hardening Features947080
! Ref: gnat_rm/security_hardening_features doc947221
! Ref: 42b947221
! Ref: gnat_rm/security_hardening_features id1947221
! Ref: 42c947221
! Ref: gnat_rm/security_hardening_features security-hardening-features947221
! Ref: 15947221
! Node: Register Scrubbing947587
! Ref: gnat_rm/security_hardening_features register-scrubbing947694
! Ref: 42d947694
! Node: Stack Scrubbing948603
! Ref: gnat_rm/security_hardening_features stack-scrubbing948740
! Ref: 42e948740
! Node: Hardened Conditionals953721
! Ref: gnat_rm/security_hardening_features hardened-conditionals953857
! Ref: 42f953857
! Node: Hardened Booleans956459
! Ref: gnat_rm/security_hardening_features hardened-booleans956603
! Ref: 430956603
! Node: Control Flow Redundancy958481
! Ref: gnat_rm/security_hardening_features control-flow-redundancy958595
! Ref: 431958595
! Node: Obsolescent Features964279
! Ref: gnat_rm/obsolescent_features doc964416
! Ref: 432964416
! Ref: gnat_rm/obsolescent_features id1964416
! Ref: 433964416
! Ref: gnat_rm/obsolescent_features obsolescent-features964416
! Ref: 16964416
! Node: pragma No_Run_Time964880
! Ref: gnat_rm/obsolescent_features id2964981
! Ref: 434964981
! Ref: gnat_rm/obsolescent_features pragma-no-run-time964981
! Ref: 435964981
! Node: pragma Ravenscar965513
! Ref: gnat_rm/obsolescent_features id3965649
! Ref: 436965649
! Ref: gnat_rm/obsolescent_features pragma-ravenscar965649
! Ref: 437965649
! Node: pragma Restricted_Run_Time965865
! Ref: gnat_rm/obsolescent_features id4965999
! Ref: 438965999
! Ref: gnat_rm/obsolescent_features pragma-restricted-run-time965999
! Ref: 439965999
! Node: pragma Task_Info966303
! Ref: gnat_rm/obsolescent_features id5966458
! Ref: 43a966458
! Ref: gnat_rm/obsolescent_features pragma-task-info966458
! Ref: 43b966458
! Node: package System Task_Info s-tasinf ads967323
! Ref: gnat_rm/obsolescent_features package-system-task-info967443
! Ref: 43c967443
! Ref: gnat_rm/obsolescent_features package-system-task-info-s-tasinf-ads967443
! Ref: 43d967443
! Node: Compatibility and Porting Guide967809
! Ref: gnat_rm/compatibility_and_porting_guide doc967949
! Ref: 43e967949
! Ref: gnat_rm/compatibility_and_porting_guide compatibility-and-porting-guide967949
! Ref: 17967949
! Ref: gnat_rm/compatibility_and_porting_guide id1967949
! Ref: 43f967949
! Node: Writing Portable Fixed-Point Declarations968588
! Ref: gnat_rm/compatibility_and_porting_guide id2968732
! Ref: 440968732
! Ref: gnat_rm/compatibility_and_porting_guide writing-portable-fixed-point-declarations968732
! Ref: 441968732
! Node: Compatibility with Ada 83972630
! Ref: gnat_rm/compatibility_and_porting_guide compatibility-with-ada-83972824
! Ref: 442972824
! Ref: gnat_rm/compatibility_and_porting_guide id3972824
! Ref: 443972824
! Node: Legal Ada 83 programs that are illegal in Ada 95973698
! Ref: gnat_rm/compatibility_and_porting_guide id4973846
! Ref: 444973846
! Ref: gnat_rm/compatibility_and_porting_guide legal-ada-83-programs-that-are-illegal-in-ada-95973846
! Ref: 445973846
! Node: More deterministic semantics978428
! Ref: gnat_rm/compatibility_and_porting_guide id5978602
! Ref: 446978602
! Ref: gnat_rm/compatibility_and_porting_guide more-deterministic-semantics978602
! Ref: 447978602
! Node: Changed semantics979538
! Ref: gnat_rm/compatibility_and_porting_guide changed-semantics979699
! Ref: 448979699
! Ref: gnat_rm/compatibility_and_porting_guide id6979699
! Ref: 449979699
! Node: Other language compatibility issues981286
! Ref: gnat_rm/compatibility_and_porting_guide id7981410
! Ref: 44a981410
! Ref: gnat_rm/compatibility_and_porting_guide other-language-compatibility-issues981410
! Ref: 44b981410
! Node: Compatibility between Ada 95 and Ada 2005982707
! Ref: gnat_rm/compatibility_and_porting_guide compatibility-between-ada-95-and-ada-2005982900
! Ref: 44c982900
! Ref: gnat_rm/compatibility_and_porting_guide id8982900
! Ref: 44d982900
! Node: Implementation-dependent characteristics985357
! Ref: gnat_rm/compatibility_and_porting_guide id9985561
! Ref: 44e985561
! Ref: gnat_rm/compatibility_and_porting_guide implementation-dependent-characteristics985561
! Ref: 44f985561
! Node: Implementation-defined pragmas986348
! Ref: gnat_rm/compatibility_and_porting_guide id10986498
! Ref: 450986498
! Ref: gnat_rm/compatibility_and_porting_guide implementation-defined-pragmas986498
! Ref: 451986498
! Node: Implementation-defined attributes987482
! Ref: gnat_rm/compatibility_and_porting_guide id11987650
! Ref: 452987650
! Ref: gnat_rm/compatibility_and_porting_guide implementation-defined-attributes987650
! Ref: 453987650
! Node: Libraries988202
! Ref: gnat_rm/compatibility_and_porting_guide id12988357
! Ref: 454988357
! Ref: gnat_rm/compatibility_and_porting_guide libraries988357
! Ref: 455988357
! Node: Elaboration order989261
! Ref: gnat_rm/compatibility_and_porting_guide elaboration-order989406
! Ref: 456989406
! Ref: gnat_rm/compatibility_and_porting_guide id13989406
! Ref: 457989406
! Node: Target-specific aspects990866
! Ref: gnat_rm/compatibility_and_porting_guide id14990993
! Ref: 458990993
! Ref: gnat_rm/compatibility_and_porting_guide target-specific-aspects990993
! Ref: 459990993
! Node: Compatibility with Other Ada Systems991756
! Ref: gnat_rm/compatibility_and_porting_guide compatibility-with-other-ada-systems991941
! Ref: 45b991941
! Ref: gnat_rm/compatibility_and_porting_guide id15991941
! Ref: 45c991941
! Node: Representation Clauses993497
! Ref: gnat_rm/compatibility_and_porting_guide id16993670
! Ref: 45d993670
! Ref: gnat_rm/compatibility_and_porting_guide representation-clauses993670
! Ref: 45a993670
! Node: Compatibility with HP Ada 83998321
! Ref: gnat_rm/compatibility_and_porting_guide compatibility-with-hp-ada-83998449
! Ref: 45e998449
! Ref: gnat_rm/compatibility_and_porting_guide id17998449
! Ref: 45f998449
! Node: GNU Free Documentation License999335
! Ref: share/gnu_free_documentation_license doc999460
! Ref: 460999460
! Ref: share/gnu_free_documentation_license gnu-fdl999460
! Ref: 1999460
! Ref: share/gnu_free_documentation_license gnu-free-documentation-license999460
! Ref: 461999460
! Node: Index1022918
  
  End Tag Table
  
--- 26870,29890 ----
  Node: Top326
  Ref: gnat_rm doc554
  Ref: 0554
! Node: About This Guide33134
! Ref: gnat_rm/about_this_guide doc33242
! Ref: 233242
! Ref: gnat_rm/about_this_guide about-this-guide33242
! Ref: 333242
! Ref: gnat_rm/about_this_guide gnat-reference-manual33242
! Ref: 433242
! Ref: gnat_rm/about_this_guide id133242
! Ref: 533242
! Node: What This Reference Manual Contains34632
! Ref: gnat_rm/about_this_guide what-this-reference-manual-contains34741
! Ref: 634741
! Node: Conventions38414
! Ref: gnat_rm/about_this_guide conventions38551
! Ref: 1838551
! Node: Related Information39118
! Ref: gnat_rm/about_this_guide related-information39211
! Ref: 1939211
! Node: Implementation Defined Pragmas40505
! Ref: gnat_rm/implementation_defined_pragmas doc40640
! Ref: 1a40640
! Ref: gnat_rm/implementation_defined_pragmas id140640
! Ref: 1b40640
! Ref: gnat_rm/implementation_defined_pragmas implementation-defined-pragmas40640
! Ref: 740640
! Node: Pragma Abort_Defer46832
! Ref: gnat_rm/implementation_defined_pragmas pragma-abort-defer46948
! Ref: 1c46948
! Node: Pragma Abstract_State47819
! Ref: gnat_rm/implementation_defined_pragmas id247957
! Ref: 1d47957
! Ref: gnat_rm/implementation_defined_pragmas pragma-abstract-state47957
! Ref: 1e47957
! Node: Pragma Ada_8349195
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-8349328
! Ref: 1f49328
! Node: Pragma Ada_9550419
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-9550544
! Ref: 2050544
! Node: Pragma Ada_0551062
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-0551189
! Ref: 2151189
! Node: Pragma Ada_200552215
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-200552342
! Ref: 2252342
! Node: Pragma Ada_1252509
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-1252638
! Ref: 2352638
! Node: Pragma Ada_201253813
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-201253942
! Ref: 2453942
! Node: Pragma Ada_202254109
! Ref: gnat_rm/implementation_defined_pragmas pragma-ada-202254261
! Ref: 2554261
! Node: Pragma Aggregate_Individually_Assign55453
! Ref: gnat_rm/implementation_defined_pragmas pragma-aggregate-individually-assign55618
! Ref: 2655618
! Node: Pragma Allow_Integer_Address56025
! Ref: gnat_rm/implementation_defined_pragmas pragma-allow-integer-address56190
! Ref: 2756190
! Node: Pragma Annotate57803
! Ref: gnat_rm/implementation_defined_pragmas id357945
! Ref: 2857945
! Ref: gnat_rm/implementation_defined_pragmas pragma-annotate57945
! Ref: 2957945
! Node: Pragma Assert59393
! Ref: gnat_rm/implementation_defined_pragmas pragma-assert59528
! Ref: 2a59528
! Node: Pragma Assert_And_Cut62034
! Ref: gnat_rm/implementation_defined_pragmas pragma-assert-and-cut62177
! Ref: 2b62177
! Node: Pragma Assertion_Policy62989
! Ref: gnat_rm/implementation_defined_pragmas pragma-assertion-policy63132
! Ref: 2c63132
! Node: Pragma Assume66862
! Ref: gnat_rm/implementation_defined_pragmas pragma-assume67015
! Ref: 2d67015
! Node: Pragma Assume_No_Invalid_Values67994
! Ref: gnat_rm/implementation_defined_pragmas pragma-assume-no-invalid-values68144
! Ref: 2e68144
! Node: Pragma Async_Readers69927
! Ref: gnat_rm/implementation_defined_pragmas id470084
! Ref: 2f70084
! Ref: gnat_rm/implementation_defined_pragmas pragma-async-readers70084
! Ref: 3070084
! Node: Pragma Async_Writers70337
! Ref: gnat_rm/implementation_defined_pragmas id570490
! Ref: 3170490
! Ref: gnat_rm/implementation_defined_pragmas pragma-async-writers70490
! Ref: 3270490
! Node: Pragma Attribute_Definition70743
! Ref: gnat_rm/implementation_defined_pragmas pragma-attribute-definition70897
! Ref: 3370897
! Node: Pragma C_Pass_By_Copy71524
! Ref: gnat_rm/implementation_defined_pragmas pragma-c-pass-by-copy71670
! Ref: 3471670
! Node: Pragma Check72852
! Ref: gnat_rm/implementation_defined_pragmas pragma-check72998
! Ref: 3572998
! Node: Pragma Check_Float_Overflow74252
! Ref: gnat_rm/implementation_defined_pragmas pragma-check-float-overflow74394
! Ref: 3674394
! Node: Pragma Check_Name76445
! Ref: gnat_rm/implementation_defined_pragmas pragma-check-name76594
! Ref: 3776594
! Node: Pragma Check_Policy77714
! Ref: gnat_rm/implementation_defined_pragmas pragma-check-policy77850
! Ref: 3877850
! Node: Pragma Comment80663
! Ref: gnat_rm/implementation_defined_pragmas pragma-comment80802
! Ref: 3980802
! Node: Pragma Common_Object81320
! Ref: gnat_rm/implementation_defined_pragmas pragma-common-object81465
! Ref: 3a81465
! Node: Pragma Compile_Time_Error82348
! Ref: gnat_rm/implementation_defined_pragmas compile-time-error82506
! Ref: 3b82506
! Ref: gnat_rm/implementation_defined_pragmas pragma-compile-time-error82506
! Ref: 3c82506
! Node: Pragma Compile_Time_Warning83576
! Ref: gnat_rm/implementation_defined_pragmas pragma-compile-time-warning83744
! Ref: 3d83744
! Node: Pragma Complete_Representation84977
! Ref: gnat_rm/implementation_defined_pragmas pragma-complete-representation85149
! Ref: 3e85149
! Node: Pragma Complex_Representation85698
! Ref: gnat_rm/implementation_defined_pragmas pragma-complex-representation85869
! Ref: 3f85869
! Node: Pragma Component_Alignment86625
! Ref: gnat_rm/implementation_defined_pragmas pragma-component-alignment86799
! Ref: 4086799
! Node: Pragma Constant_After_Elaboration89517
! Ref: gnat_rm/implementation_defined_pragmas id689683
! Ref: 4189683
! Ref: gnat_rm/implementation_defined_pragmas pragma-constant-after-elaboration89683
! Ref: 4289683
! Node: Pragma Contract_Cases89988
! Ref: gnat_rm/implementation_defined_pragmas id790156
! Ref: 4390156
! Ref: gnat_rm/implementation_defined_pragmas pragma-contract-cases90156
! Ref: 4490156
! Node: Pragma Convention_Identifier92991
! Ref: gnat_rm/implementation_defined_pragmas pragma-convention-identifier93142
! Ref: 4593142
! Node: Pragma CPP_Class94326
! Ref: gnat_rm/implementation_defined_pragmas pragma-cpp-class94478
! Ref: 4694478
! Node: Pragma CPP_Constructor95592
! Ref: gnat_rm/implementation_defined_pragmas pragma-cpp-constructor95734
! Ref: 4895734
! Node: Pragma CPP_Virtual97658
! Ref: gnat_rm/implementation_defined_pragmas pragma-cpp-virtual97801
! Ref: 4997801
! Node: Pragma CPP_Vtable98271
! Ref: gnat_rm/implementation_defined_pragmas pragma-cpp-vtable98402
! Ref: 4a98402
! Node: Pragma CPU98826
! Ref: gnat_rm/implementation_defined_pragmas pragma-cpu98960
! Ref: 4b98960
! Node: Pragma Deadline_Floor99200
! Ref: gnat_rm/implementation_defined_pragmas pragma-deadline-floor99329
! Ref: 4c99329
! Node: Pragma Debug99645
! Ref: gnat_rm/implementation_defined_pragmas pragma-debug99783
! Ref: 4d99783
! Node: Pragma Debug_Policy100735
! Ref: gnat_rm/implementation_defined_pragmas pragma-debug-policy100884
! Ref: 4e100884
! Node: Pragma Default_Initial_Condition101173
! Ref: gnat_rm/implementation_defined_pragmas id8101345
! Ref: 4f101345
! Ref: gnat_rm/implementation_defined_pragmas pragma-default-initial-condition101345
! Ref: 50101345
! Node: Pragma Default_Scalar_Storage_Order101646
! Ref: gnat_rm/implementation_defined_pragmas pragma-default-scalar-storage-order101826
! Ref: 51101826
! Node: Pragma Default_Storage_Pool104118
! Ref: gnat_rm/implementation_defined_pragmas pragma-default-storage-pool104280
! Ref: 52104280
! Node: Pragma Depends104585
! Ref: gnat_rm/implementation_defined_pragmas id9104734
! Ref: 53104734
! Ref: gnat_rm/implementation_defined_pragmas pragma-depends104734
! Ref: 54104734
! Node: Pragma Detect_Blocking105434
! Ref: gnat_rm/implementation_defined_pragmas pragma-detect-blocking105593
! Ref: 55105593
! Node: Pragma Disable_Atomic_Synchronization105982
! Ref: gnat_rm/implementation_defined_pragmas pragma-disable-atomic-synchronization106152
! Ref: 56106152
! Node: Pragma Dispatching_Domain106969
! Ref: gnat_rm/implementation_defined_pragmas pragma-dispatching-domain107139
! Ref: 57107139
! Node: Pragma Effective_Reads107424
! Ref: gnat_rm/implementation_defined_pragmas id10107580
! Ref: 58107580
! Ref: gnat_rm/implementation_defined_pragmas pragma-effective-reads107580
! Ref: 59107580
! Node: Pragma Effective_Writes107841
! Ref: gnat_rm/implementation_defined_pragmas id11107997
! Ref: 5a107997
! Ref: gnat_rm/implementation_defined_pragmas pragma-effective-writes107997
! Ref: 5b107997
! Node: Pragma Elaboration_Checks108262
! Ref: gnat_rm/implementation_defined_pragmas pragma-elaboration-checks108412
! Ref: 5c108412
! Node: Pragma Eliminate109240
! Ref: gnat_rm/implementation_defined_pragmas pragma-eliminate109403
! Ref: 5d109403
! Node: Pragma Enable_Atomic_Synchronization115135
! Ref: gnat_rm/implementation_defined_pragmas pragma-enable-atomic-synchronization115295
! Ref: 5e115295
! Node: Pragma Export_Function116211
! Ref: gnat_rm/implementation_defined_pragmas pragma-export-function116375
! Ref: 5f116375
! Node: Pragma Export_Object118831
! Ref: gnat_rm/implementation_defined_pragmas pragma-export-object118982
! Ref: 60118982
! Node: Pragma Export_Procedure119653
! Ref: gnat_rm/implementation_defined_pragmas pragma-export-procedure119812
! Ref: 61119812
! Node: Pragma Export_Valued_Procedure121310
! Ref: gnat_rm/implementation_defined_pragmas pragma-export-valued-procedure121469
! Ref: 62121469
! Node: Pragma Extend_System123322
! Ref: gnat_rm/implementation_defined_pragmas pragma-extend-system123483
! Ref: 63123483
! Node: Pragma Extensions_Allowed125537
! Ref: gnat_rm/implementation_defined_pragmas pragma-extensions-allowed125693
! Ref: 64125693
! Node: Pragma Extensions_Visible136915
! Ref: gnat_rm/implementation_defined_pragmas id12137066
! Ref: 65137066
! Ref: gnat_rm/implementation_defined_pragmas pragma-extensions-visible137066
! Ref: 66137066
! Node: Pragma External137339
! Ref: gnat_rm/implementation_defined_pragmas pragma-external137492
! Ref: 67137492
! Node: Pragma External_Name_Casing138059
! Ref: gnat_rm/implementation_defined_pragmas pragma-external-name-casing138203
! Ref: 68138203
! Node: Pragma Fast_Math141211
! Ref: gnat_rm/implementation_defined_pragmas pragma-fast-math141362
! Ref: 69141362
! Node: Pragma Favor_Top_Level142231
! Ref: gnat_rm/implementation_defined_pragmas id13142383
! Ref: 6a142383
! Ref: gnat_rm/implementation_defined_pragmas pragma-favor-top-level142383
! Ref: 6b142383
! Node: Pragma Finalize_Storage_Only143056
! Ref: gnat_rm/implementation_defined_pragmas pragma-finalize-storage-only143219
! Ref: 6c143219
! Node: Pragma Float_Representation143981
! Ref: gnat_rm/implementation_defined_pragmas pragma-float-representation144134
! Ref: 6d144134
! Node: Pragma Ghost144989
! Ref: gnat_rm/implementation_defined_pragmas id14145127
! Ref: 6e145127
! Ref: gnat_rm/implementation_defined_pragmas pragma-ghost145127
! Ref: 6f145127
! Node: Pragma Global145346
! Ref: gnat_rm/implementation_defined_pragmas id15145469
! Ref: 70145469
! Ref: gnat_rm/implementation_defined_pragmas pragma-global145469
! Ref: 71145469
! Node: Pragma Ident146016
! Ref: gnat_rm/implementation_defined_pragmas pragma-ident146147
! Ref: 72146147
! Node: Pragma Ignore_Pragma146383
! Ref: gnat_rm/implementation_defined_pragmas pragma-ignore-pragma146530
! Ref: 73146530
! Node: Pragma Implementation_Defined147150
! Ref: gnat_rm/implementation_defined_pragmas pragma-implementation-defined147303
! Ref: 74147303
! Node: Pragma Implemented148015
! Ref: gnat_rm/implementation_defined_pragmas pragma-implemented148171
! Ref: 75148171
! Node: Pragma Implicit_Packing149790
! Ref: gnat_rm/implementation_defined_pragmas pragma-implicit-packing149939
! Ref: 76149939
! Node: Pragma Import_Function151762
! Ref: gnat_rm/implementation_defined_pragmas pragma-import-function151913
! Ref: 77151913
! Node: Pragma Import_Object154026
! Ref: gnat_rm/implementation_defined_pragmas pragma-import-object154177
! Ref: 78154177
! Node: Pragma Import_Procedure154881
! Ref: gnat_rm/implementation_defined_pragmas pragma-import-procedure155040
! Ref: 79155040
! Node: Pragma Import_Valued_Procedure155972
! Ref: gnat_rm/implementation_defined_pragmas pragma-import-valued-procedure156129
! Ref: 7a156129
! Node: Pragma Independent157906
! Ref: gnat_rm/implementation_defined_pragmas pragma-independent158069
! Ref: 7b158069
! Node: Pragma Independent_Components158746
! Ref: gnat_rm/implementation_defined_pragmas pragma-independent-components158903
! Ref: 7c158903
! Node: Pragma Initial_Condition159565
! Ref: gnat_rm/implementation_defined_pragmas id16159729
! Ref: 7d159729
! Ref: gnat_rm/implementation_defined_pragmas pragma-initial-condition159729
! Ref: 7e159729
! Node: Pragma Initialize_Scalars159987
! Ref: gnat_rm/implementation_defined_pragmas pragma-initialize-scalars160140
! Ref: 7f160140
! Node: Pragma Initializes163820
! Ref: gnat_rm/implementation_defined_pragmas id17163969
! Ref: 80163969
! Ref: gnat_rm/implementation_defined_pragmas pragma-initializes163969
! Ref: 81163969
! Node: Pragma Inline_Always164455
! Ref: gnat_rm/implementation_defined_pragmas id18164600
! Ref: 82164600
! Ref: gnat_rm/implementation_defined_pragmas pragma-inline-always164600
! Ref: 83164600
! Node: Pragma Inline_Generic165232
! Ref: gnat_rm/implementation_defined_pragmas pragma-inline-generic165375
! Ref: 84165375
! Node: Pragma Interface165757
! Ref: gnat_rm/implementation_defined_pragmas pragma-interface165901
! Ref: 85165901
! Node: Pragma Interface_Name166874
! Ref: gnat_rm/implementation_defined_pragmas pragma-interface-name167021
! Ref: 86167021
! Node: Pragma Interrupt_Handler167539
! Ref: gnat_rm/implementation_defined_pragmas pragma-interrupt-handler167692
! Ref: 87167692
! Node: Pragma Interrupt_State167948
! Ref: gnat_rm/implementation_defined_pragmas pragma-interrupt-state168096
! Ref: 88168096
! Node: Pragma Invariant171296
! Ref: gnat_rm/implementation_defined_pragmas id19171437
! Ref: 89171437
! Ref: gnat_rm/implementation_defined_pragmas pragma-invariant171437
! Ref: 8a171437
! Node: Pragma Keep_Names173093
! Ref: gnat_rm/implementation_defined_pragmas pragma-keep-names173226
! Ref: 8b173226
! Node: Pragma License173842
! Ref: gnat_rm/implementation_defined_pragmas pragma-license173975
! Ref: 8c173975
! Node: Pragma Link_With177073
! Ref: gnat_rm/implementation_defined_pragmas pragma-link-with177208
! Ref: 8d177208
! Node: Pragma Linker_Alias177849
! Ref: gnat_rm/implementation_defined_pragmas pragma-linker-alias177995
! Ref: 8e177995
! Node: Pragma Linker_Constructor179274
! Ref: gnat_rm/implementation_defined_pragmas pragma-linker-constructor179428
! Ref: 8f179428
! Node: Pragma Linker_Destructor180657
! Ref: gnat_rm/implementation_defined_pragmas pragma-linker-destructor180813
! Ref: 90180813
! Node: Pragma Linker_Section181592
! Ref: gnat_rm/implementation_defined_pragmas id20181739
! Ref: 91181739
! Ref: gnat_rm/implementation_defined_pragmas pragma-linker-section181739
! Ref: 92181739
! Node: Pragma Lock_Free184788
! Ref: gnat_rm/implementation_defined_pragmas id21184932
! Ref: 93184932
! Ref: gnat_rm/implementation_defined_pragmas pragma-lock-free184932
! Ref: 94184932
! Node: Pragma Loop_Invariant186255
! Ref: gnat_rm/implementation_defined_pragmas pragma-loop-invariant186398
! Ref: 95186398
! Node: Pragma Loop_Optimize187590
! Ref: gnat_rm/implementation_defined_pragmas pragma-loop-optimize187736
! Ref: 96187736
! Node: Pragma Loop_Variant189470
! Ref: gnat_rm/implementation_defined_pragmas pragma-loop-variant189619
! Ref: 97189619
! Node: Pragma Machine_Attribute191428
! Ref: gnat_rm/implementation_defined_pragmas pragma-machine-attribute191568
! Ref: 98191568
! Node: Pragma Main192535
! Ref: gnat_rm/implementation_defined_pragmas pragma-main192675
! Ref: 99192675
! Node: Pragma Main_Storage193113
! Ref: gnat_rm/implementation_defined_pragmas pragma-main-storage193252
! Ref: 9a193252
! Node: Pragma Max_Queue_Length193659
! Ref: gnat_rm/implementation_defined_pragmas id22193801
! Ref: 9b193801
! Ref: gnat_rm/implementation_defined_pragmas pragma-max-queue-length193801
! Ref: 9c193801
! Node: Pragma No_Body194227
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-body194367
! Ref: 9d194367
! Node: Pragma No_Caching195150
! Ref: gnat_rm/implementation_defined_pragmas id23195297
! Ref: 9e195297
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-caching195297
! Ref: 9f195297
! Node: Pragma No_Component_Reordering195540
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-component-reordering195703
! Ref: a0195703
! Node: Pragma No_Elaboration_Code_All196363
! Ref: gnat_rm/implementation_defined_pragmas id24196536
! Ref: a1196536
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-elaboration-code-all196536
! Ref: a2196536
! Node: Pragma No_Heap_Finalization197191
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-heap-finalization197350
! Ref: a3197350
! Node: Pragma No_Inline198502
! Ref: gnat_rm/implementation_defined_pragmas id25198647
! Ref: a4198647
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-inline198647
! Ref: a5198647
! Node: Pragma No_Return199154
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-return199297
! Ref: a6199297
! Node: Pragma No_Strict_Aliasing200270
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-strict-aliasing200421
! Ref: a7200421
! Node: Pragma No_Tagged_Streams201147
! Ref: gnat_rm/implementation_defined_pragmas id26201306
! Ref: a8201306
! Ref: gnat_rm/implementation_defined_pragmas pragma-no-tagged-streams201306
! Ref: a9201306
! Node: Pragma Normalize_Scalars203081
! Ref: gnat_rm/implementation_defined_pragmas pragma-normalize-scalars203233
! Ref: aa203233
! Node: Pragma Obsolescent206171
! Ref: gnat_rm/implementation_defined_pragmas id27206324
! Ref: ab206324
! Ref: gnat_rm/implementation_defined_pragmas pragma-obsolescent206324
! Ref: ac206324
! Node: Pragma Optimize_Alignment209779
! Ref: gnat_rm/implementation_defined_pragmas pragma-optimize-alignment209922
! Ref: ad209922
! Node: Pragma Ordered213433
! Ref: gnat_rm/implementation_defined_pragmas pragma-ordered213578
! Ref: ae213578
! Node: Pragma Overflow_Mode216682
! Ref: gnat_rm/implementation_defined_pragmas pragma-overflow-mode216829
! Ref: af216829
! Node: Pragma Overriding_Renamings218167
! Ref: gnat_rm/implementation_defined_pragmas pragma-overriding-renamings218314
! Ref: b0218314
! Node: Pragma Part_Of218976
! Ref: gnat_rm/implementation_defined_pragmas id28219138
! Ref: b1219138
! Ref: gnat_rm/implementation_defined_pragmas pragma-part-of219138
! Ref: b2219138
! Node: Pragma Partition_Elaboration_Policy219384
! Ref: gnat_rm/implementation_defined_pragmas pragma-partition-elaboration-policy219533
! Ref: b3219533
! Node: Pragma Passive219909
! Ref: gnat_rm/implementation_defined_pragmas pragma-passive220065
! Ref: b4220065
! Node: Pragma Persistent_BSS220923
! Ref: gnat_rm/implementation_defined_pragmas id29221055
! Ref: b5221055
! Ref: gnat_rm/implementation_defined_pragmas pragma-persistent-bss221055
! Ref: b6221055
! Node: Pragma Post222251
! Ref: gnat_rm/implementation_defined_pragmas pragma-post222389
! Ref: b7222389
! Node: Pragma Postcondition222904
! Ref: gnat_rm/implementation_defined_pragmas pragma-postcondition223038
! Ref: b8223038
! Node: Pragma Post_Class228782
! Ref: gnat_rm/implementation_defined_pragmas pragma-post-class228915
! Ref: b9228915
! Node: Pragma Pre229972
! Ref: gnat_rm/implementation_defined_pragmas pragma-pre230104
! Ref: ba230104
! Node: Pragma Precondition230614
! Ref: gnat_rm/implementation_defined_pragmas pragma-precondition230745
! Ref: bb230745
! Node: Pragma Predicate232692
! Ref: gnat_rm/implementation_defined_pragmas id30232837
! Ref: bc232837
! Ref: gnat_rm/implementation_defined_pragmas pragma-predicate232837
! Ref: bd232837
! Node: Pragma Predicate_Failure234593
! Ref: gnat_rm/implementation_defined_pragmas pragma-predicate-failure234754
! Ref: be234754
! Node: Pragma Preelaborable_Initialization235111
! Ref: gnat_rm/implementation_defined_pragmas pragma-preelaborable-initialization235288
! Ref: bf235288
! Node: Pragma Prefix_Exception_Messages235606
! Ref: gnat_rm/implementation_defined_pragmas pragma-prefix-exception-messages235775
! Ref: c0235775
! Node: Pragma Pre_Class236696
! Ref: gnat_rm/implementation_defined_pragmas pragma-pre-class236866
! Ref: c1236866
! Node: Pragma Priority_Specific_Dispatching237914
! Ref: gnat_rm/implementation_defined_pragmas pragma-priority-specific-dispatching238066
! Ref: c2238066
! Node: Pragma Profile238665
! Ref: gnat_rm/implementation_defined_pragmas pragma-profile238824
! Ref: c3238824
! Node: Pragma Profile_Warnings245761
! Ref: gnat_rm/implementation_defined_pragmas pragma-profile-warnings245911
! Ref: c4245911
! Node: Pragma Propagate_Exceptions246350
! Ref: gnat_rm/implementation_defined_pragmas pragma-propagate-exceptions246516
! Ref: c5246516
! Node: Pragma Provide_Shift_Operators246914
! Ref: gnat_rm/implementation_defined_pragmas pragma-provide-shift-operators247076
! Ref: c6247076
! Node: Pragma Psect_Object247639
! Ref: gnat_rm/implementation_defined_pragmas pragma-psect-object247794
! Ref: c7247794
! Node: Pragma Pure_Function248147
! Ref: gnat_rm/implementation_defined_pragmas id31248287
! Ref: c8248287
! Ref: gnat_rm/implementation_defined_pragmas pragma-pure-function248287
! Ref: c9248287
! Node: Pragma Rational251333
! Ref: gnat_rm/implementation_defined_pragmas pragma-rational251470
! Ref: ca251470
! Node: Pragma Ravenscar251686
! Ref: gnat_rm/implementation_defined_pragmas pragma-ravenscar251825
! Ref: cb251825
! Node: Pragma Refined_Depends252116
! Ref: gnat_rm/implementation_defined_pragmas id32252261
! Ref: cc252261
! Ref: gnat_rm/implementation_defined_pragmas pragma-refined-depends252261
! Ref: cd252261
! Node: Pragma Refined_Global252995
! Ref: gnat_rm/implementation_defined_pragmas id33253143
! Ref: ce253143
! Ref: gnat_rm/implementation_defined_pragmas pragma-refined-global253143
! Ref: cf253143
! Node: Pragma Refined_Post253724
! Ref: gnat_rm/implementation_defined_pragmas id34253870
! Ref: d0253870
! Ref: gnat_rm/implementation_defined_pragmas pragma-refined-post253870
! Ref: d1253870
! Node: Pragma Refined_State254110
! Ref: gnat_rm/implementation_defined_pragmas id35254259
! Ref: d2254259
! Ref: gnat_rm/implementation_defined_pragmas pragma-refined-state254259
! Ref: d3254259
! Node: Pragma Relative_Deadline254784
! Ref: gnat_rm/implementation_defined_pragmas pragma-relative-deadline254939
! Ref: d4254939
! Node: Pragma Remote_Access_Type255233
! Ref: gnat_rm/implementation_defined_pragmas id36255388
! Ref: d5255388
! Ref: gnat_rm/implementation_defined_pragmas pragma-remote-access-type255388
! Ref: d6255388
! Node: Pragma Rename_Pragma256266
! Ref: gnat_rm/implementation_defined_pragmas pragma-rename-pragma256423
! Ref: d7256423
! Node: Pragma Restricted_Run_Time257586
! Ref: gnat_rm/implementation_defined_pragmas pragma-restricted-run-time257745
! Ref: d8257745
! Node: Pragma Restriction_Warnings258071
! Ref: gnat_rm/implementation_defined_pragmas pragma-restriction-warnings258227
! Ref: d9258227
! Node: Pragma Reviewable259515
! Ref: gnat_rm/implementation_defined_pragmas pragma-reviewable259672
! Ref: da259672
! Node: Pragma Secondary_Stack_Size262196
! Ref: gnat_rm/implementation_defined_pragmas id37262346
! Ref: db262346
! Ref: gnat_rm/implementation_defined_pragmas pragma-secondary-stack-size262346
! Ref: dc262346
! Node: Pragma Share_Generic263822
! Ref: gnat_rm/implementation_defined_pragmas pragma-share-generic263968
! Ref: dd263968
! Node: Pragma Shared264360
! Ref: gnat_rm/implementation_defined_pragmas id38264506
! Ref: de264506
! Ref: gnat_rm/implementation_defined_pragmas pragma-shared264506
! Ref: df264506
! Node: Pragma Short_Circuit_And_Or264661
! Ref: gnat_rm/implementation_defined_pragmas pragma-short-circuit-and-or264811
! Ref: e0264811
! Node: Pragma Short_Descriptors265465
! Ref: gnat_rm/implementation_defined_pragmas pragma-short-descriptors265633
! Ref: e1265633
! Node: Pragma Simple_Storage_Pool_Type265875
! Ref: gnat_rm/implementation_defined_pragmas id39266039
! Ref: e2266039
! Ref: gnat_rm/implementation_defined_pragmas pragma-simple-storage-pool-type266039
! Ref: e3266039
! Node: Pragma Source_File_Name268329
! Ref: gnat_rm/implementation_defined_pragmas id40268500
! Ref: e5268500
! Ref: gnat_rm/implementation_defined_pragmas pragma-source-file-name268500
! Ref: e6268500
! Node: Pragma Source_File_Name_Project271975
! Ref: gnat_rm/implementation_defined_pragmas id41272138
! Ref: e8272138
! Ref: gnat_rm/implementation_defined_pragmas pragma-source-file-name-project272138
! Ref: e7272138
! Node: Pragma Source_Reference272913
! Ref: gnat_rm/implementation_defined_pragmas pragma-source-reference273070
! Ref: e9273070
! Node: Pragma SPARK_Mode273911
! Ref: gnat_rm/implementation_defined_pragmas id42274070
! Ref: ea274070
! Ref: gnat_rm/implementation_defined_pragmas pragma-spark-mode274070
! Ref: eb274070
! Node: Pragma Static_Elaboration_Desired276087
! Ref: gnat_rm/implementation_defined_pragmas pragma-static-elaboration-desired276244
! Ref: ec276244
! Node: Pragma Stream_Convert277254
! Ref: gnat_rm/implementation_defined_pragmas pragma-stream-convert277413
! Ref: ed277413
! Node: Pragma Style_Checks280582
! Ref: gnat_rm/implementation_defined_pragmas pragma-style-checks280723
! Ref: ee280723
! Node: Pragma Subtitle283051
! Ref: gnat_rm/implementation_defined_pragmas pragma-subtitle283186
! Ref: ef283186
! Node: Pragma Suppress283388
! Ref: gnat_rm/implementation_defined_pragmas pragma-suppress283523
! Ref: f0283523
! Node: Pragma Suppress_All286394
! Ref: gnat_rm/implementation_defined_pragmas pragma-suppress-all286540
! Ref: f1286540
! Node: Pragma Suppress_Debug_Info287082
! Ref: gnat_rm/implementation_defined_pragmas id43287248
! Ref: f2287248
! Ref: gnat_rm/implementation_defined_pragmas pragma-suppress-debug-info287248
! Ref: f3287248
! Node: Pragma Suppress_Exception_Locations287580
! Ref: gnat_rm/implementation_defined_pragmas pragma-suppress-exception-locations287757
! Ref: f4287757
! Node: Pragma Suppress_Initialization288688
! Ref: gnat_rm/implementation_defined_pragmas id44288855
! Ref: f5288855
! Ref: gnat_rm/implementation_defined_pragmas pragma-suppress-initialization288855
! Ref: f6288855
! Node: Pragma Task_Name290419
! Ref: gnat_rm/implementation_defined_pragmas pragma-task-name290570
! Ref: f7290570
! Node: Pragma Task_Storage292149
! Ref: gnat_rm/implementation_defined_pragmas pragma-task-storage292286
! Ref: f8292286
! Node: Pragma Test_Case292821
! Ref: gnat_rm/implementation_defined_pragmas id45292969
! Ref: f9292969
! Ref: gnat_rm/implementation_defined_pragmas pragma-test-case292969
! Ref: fa292969
! Node: Pragma Thread_Local_Storage295063
! Ref: gnat_rm/implementation_defined_pragmas id46295209
! Ref: fb295209
! Ref: gnat_rm/implementation_defined_pragmas pragma-thread-local-storage295209
! Ref: fc295209
! Node: Pragma Time_Slice296422
! Ref: gnat_rm/implementation_defined_pragmas pragma-time-slice296564
! Ref: fd296564
! Node: Pragma Title296948
! Ref: gnat_rm/implementation_defined_pragmas pragma-title297084
! Ref: fe297084
! Node: Pragma Type_Invariant297801
! Ref: gnat_rm/implementation_defined_pragmas pragma-type-invariant297947
! Ref: ff297947
! Node: Pragma Type_Invariant_Class298487
! Ref: gnat_rm/implementation_defined_pragmas id47298643
! Ref: 100298643
! Ref: gnat_rm/implementation_defined_pragmas pragma-type-invariant-class298643
! Ref: 101298643
! Node: Pragma Unchecked_Union299558
! Ref: gnat_rm/implementation_defined_pragmas pragma-unchecked-union299722
! Ref: 102299722
! Node: Pragma Unevaluated_Use_Of_Old300288
! Ref: gnat_rm/implementation_defined_pragmas pragma-unevaluated-use-of-old300450
! Ref: 103300450
! Node: Pragma Unimplemented_Unit302377
! Ref: gnat_rm/implementation_defined_pragmas pragma-unimplemented-unit302542
! Ref: 104302542
! Node: Pragma Universal_Aliasing303077
! Ref: gnat_rm/implementation_defined_pragmas id48303230
! Ref: 105303230
! Ref: gnat_rm/implementation_defined_pragmas pragma-universal-aliasing303230
! Ref: 106303230
! Node: Pragma Unmodified303871
! Ref: gnat_rm/implementation_defined_pragmas id49304018
! Ref: 107304018
! Ref: gnat_rm/implementation_defined_pragmas pragma-unmodified304018
! Ref: 108304018
! Node: Pragma Unreferenced305096
! Ref: gnat_rm/implementation_defined_pragmas id50305245
! Ref: 109305245
! Ref: gnat_rm/implementation_defined_pragmas pragma-unreferenced305245
! Ref: 10a305245
! Node: Pragma Unreferenced_Objects307923
! Ref: gnat_rm/implementation_defined_pragmas id51308086
! Ref: 10b308086
! Ref: gnat_rm/implementation_defined_pragmas pragma-unreferenced-objects308086
! Ref: 10c308086
! Node: Pragma Unreserve_All_Interrupts308863
! Ref: gnat_rm/implementation_defined_pragmas pragma-unreserve-all-interrupts309024
! Ref: 10d309024
! Node: Pragma Unsuppress310529
! Ref: gnat_rm/implementation_defined_pragmas pragma-unsuppress310676
! Ref: 10e310676
! Node: Pragma Unused311946
! Ref: gnat_rm/implementation_defined_pragmas id52312082
! Ref: 10f312082
! Ref: gnat_rm/implementation_defined_pragmas pragma-unused312082
! Ref: 110312082
! Node: Pragma Use_VADS_Size313258
! Ref: gnat_rm/implementation_defined_pragmas pragma-use-vads-size313399
! Ref: 111313399
! Node: Pragma Validity_Checks313960
! Ref: gnat_rm/implementation_defined_pragmas pragma-validity-checks314103
! Ref: 112314103
! Node: Pragma Volatile315870
! Ref: gnat_rm/implementation_defined_pragmas id53316020
! Ref: 113316020
! Ref: gnat_rm/implementation_defined_pragmas pragma-volatile316020
! Ref: 114316020
! Node: Pragma Volatile_Full_Access316490
! Ref: gnat_rm/implementation_defined_pragmas id54316642
! Ref: 115316642
! Ref: gnat_rm/implementation_defined_pragmas pragma-volatile-full-access316642
! Ref: 116316642
! Node: Pragma Volatile_Function317710
! Ref: gnat_rm/implementation_defined_pragmas id55317870
! Ref: 117317870
! Ref: gnat_rm/implementation_defined_pragmas pragma-volatile-function317870
! Ref: 118317870
! Node: Pragma Warning_As_Error318141
! Ref: gnat_rm/implementation_defined_pragmas pragma-warning-as-error318289
! Ref: 119318289
! Node: Pragma Warnings321645
! Ref: gnat_rm/implementation_defined_pragmas id56321789
! Ref: 11b321789
! Ref: gnat_rm/implementation_defined_pragmas pragma-warnings321789
! Ref: 11a321789
! Node: Pragma Weak_External329244
! Ref: gnat_rm/implementation_defined_pragmas pragma-weak-external329395
! Ref: 11c329395
! Node: Pragma Wide_Character_Encoding331076
! Ref: gnat_rm/implementation_defined_pragmas pragma-wide-character-encoding331203
! Ref: 11d331203
! Node: Implementation Defined Aspects332335
! Ref: gnat_rm/implementation_defined_aspects doc332487
! Ref: 11e332487
! Ref: gnat_rm/implementation_defined_aspects id1332487
! Ref: 11f332487
! Ref: gnat_rm/implementation_defined_aspects implementation-defined-aspects332487
! Ref: 120332487
! Node: Aspect Abstract_State335703
! Ref: gnat_rm/implementation_defined_aspects aspect-abstract-state335816
! Ref: 121335816
! Node: Aspect Annotate335932
! Ref: gnat_rm/implementation_defined_aspects aspect-annotate336074
! Ref: 122336074
! Node: Aspect Async_Readers336533
! Ref: gnat_rm/implementation_defined_aspects aspect-async-readers336674
! Ref: 123336674
! Node: Aspect Async_Writers336795
! Ref: gnat_rm/implementation_defined_aspects aspect-async-writers336954
! Ref: 124336954
! Node: Aspect Constant_After_Elaboration337075
! Ref: gnat_rm/implementation_defined_aspects aspect-constant-after-elaboration337235
! Ref: 125337235
! Node: Aspect Contract_Cases337387
! Ref: gnat_rm/implementation_defined_aspects aspect-contract-cases337541
! Ref: 126337541
! Node: Aspect Depends337753
! Ref: gnat_rm/implementation_defined_aspects aspect-depends337906
! Ref: 127337906
! Node: Aspect Default_Initial_Condition338001
! Ref: gnat_rm/implementation_defined_aspects aspect-default-initial-condition338149
! Ref: 128338149
! Node: Aspect Dimension338298
! Ref: gnat_rm/implementation_defined_aspects aspect-dimension338455
! Ref: 129338455
! Node: Aspect Dimension_System339675
! Ref: gnat_rm/implementation_defined_aspects aspect-dimension-system339825
! Ref: 12a339825
! Node: Aspect Disable_Controlled342375
! Ref: gnat_rm/implementation_defined_aspects aspect-disable-controlled342531
! Ref: 12b342531
! Node: Aspect Effective_Reads342972
! Ref: gnat_rm/implementation_defined_aspects aspect-effective-reads343128
! Ref: 12c343128
! Node: Aspect Effective_Writes343249
! Ref: gnat_rm/implementation_defined_aspects aspect-effective-writes343405
! Ref: 12d343405
! Node: Aspect Extensions_Visible343529
! Ref: gnat_rm/implementation_defined_aspects aspect-extensions-visible343685
! Ref: 12e343685
! Node: Aspect Favor_Top_Level343815
! Ref: gnat_rm/implementation_defined_aspects aspect-favor-top-level343960
! Ref: 12f343960
! Node: Aspect Ghost344089
! Ref: gnat_rm/implementation_defined_aspects aspect-ghost344222
! Ref: 130344222
! Node: Aspect Global344313
! Ref: gnat_rm/implementation_defined_aspects aspect-global344448
! Ref: 131344448
! Node: Aspect Initial_Condition344542
! Ref: gnat_rm/implementation_defined_aspects aspect-initial-condition344683
! Ref: 132344683
! Node: Aspect Initializes344810
! Ref: gnat_rm/implementation_defined_aspects aspect-initializes344958
! Ref: 133344958
! Node: Aspect Inline_Always345067
! Ref: gnat_rm/implementation_defined_aspects aspect-inline-always345207
! Ref: 134345207
! Node: Aspect Invariant345330
! Ref: gnat_rm/implementation_defined_aspects aspect-invariant345476
! Ref: 135345476
! Node: Aspect Invariant’Class345728
! Ref: gnat_rm/implementation_defined_aspects aspect-invariant-class345869
! Ref: 136345869
! Node: Aspect Iterable346153
! Ref: gnat_rm/implementation_defined_aspects aspect-iterable346299
! Ref: 137346299
! Node: Aspect Linker_Section348906
! Ref: gnat_rm/implementation_defined_aspects aspect-linker-section349044
! Ref: 138349044
! Node: Aspect Lock_Free349162
! Ref: gnat_rm/implementation_defined_aspects aspect-lock-free349308
! Ref: 139349308
! Node: Aspect Max_Queue_Length349419
! Ref: gnat_rm/implementation_defined_aspects aspect-max-queue-length349561
! Ref: 13a349561
! Node: Aspect No_Caching349685
! Ref: gnat_rm/implementation_defined_aspects aspect-no-caching349841
! Ref: 13b349841
! Node: Aspect No_Elaboration_Code_All349955
! Ref: gnat_rm/implementation_defined_aspects aspect-no-elaboration-code-all350104
! Ref: 13c350104
! Node: Aspect No_Inline350269
! Ref: gnat_rm/implementation_defined_aspects aspect-no-inline350425
! Ref: 13d350425
! Node: Aspect No_Tagged_Streams350536
! Ref: gnat_rm/implementation_defined_aspects aspect-no-tagged-streams350682
! Ref: 13e350682
! Node: Aspect No_Task_Parts350911
! Ref: gnat_rm/implementation_defined_aspects aspect-no-task-parts351059
! Ref: 13f351059
! Node: Aspect Object_Size351565
! Ref: gnat_rm/implementation_defined_aspects aspect-object-size351707
! Ref: 140351707
! Node: Aspect Obsolescent351820
! Ref: gnat_rm/implementation_defined_aspects aspect-obsolescent351956
! Ref: 142351956
! Node: Aspect Part_Of352184
! Ref: gnat_rm/implementation_defined_aspects aspect-part-of352323
! Ref: 143352323
! Node: Aspect Persistent_BSS352420
! Ref: gnat_rm/implementation_defined_aspects aspect-persistent-bss352557
! Ref: 144352557
! Node: Aspect Predicate352683
! Ref: gnat_rm/implementation_defined_aspects aspect-predicate352826
! Ref: 145352826
! Node: Aspect Pure_Function353215
! Ref: gnat_rm/implementation_defined_aspects aspect-pure-function353359
! Ref: 146353359
! Node: Aspect Refined_Depends353482
! Ref: gnat_rm/implementation_defined_aspects aspect-refined-depends353631
! Ref: 147353631
! Node: Aspect Refined_Global353752
! Ref: gnat_rm/implementation_defined_aspects aspect-refined-global353900
! Ref: 148353900
! Node: Aspect Refined_Post354018
! Ref: gnat_rm/implementation_defined_aspects aspect-refined-post354164
! Ref: 149354164
! Node: Aspect Refined_State354276
! Ref: gnat_rm/implementation_defined_aspects aspect-refined-state354430
! Ref: 14a354430
! Node: Aspect Relaxed_Initialization354545
! Ref: gnat_rm/implementation_defined_aspects aspect-relaxed-initialization354705
! Ref: 14b354705
! Node: Aspect Remote_Access_Type354873
! Ref: gnat_rm/implementation_defined_aspects aspect-remote-access-type355040
! Ref: 14c355040
! Node: Aspect Secondary_Stack_Size355170
! Ref: gnat_rm/implementation_defined_aspects aspect-secondary-stack-size355335
! Ref: 14d355335
! Node: Aspect Scalar_Storage_Order355471
! Ref: gnat_rm/implementation_defined_aspects aspect-scalar-storage-order355624
! Ref: 14e355624
! Node: Aspect Shared355766
! Ref: gnat_rm/implementation_defined_aspects aspect-shared355918
! Ref: 150355918
! Node: Aspect Simple_Storage_Pool356067
! Ref: gnat_rm/implementation_defined_aspects aspect-simple-storage-pool356223
! Ref: 151356223
! Node: Aspect Simple_Storage_Pool_Type356359
! Ref: gnat_rm/implementation_defined_aspects aspect-simple-storage-pool-type356519
! Ref: 152356519
! Node: Aspect SPARK_Mode356675
! Ref: gnat_rm/implementation_defined_aspects aspect-spark-mode356835
! Ref: 153356835
! Node: Aspect Suppress_Debug_Info357039
! Ref: gnat_rm/implementation_defined_aspects aspect-suppress-debug-info357198
! Ref: 154357198
! Node: Aspect Suppress_Initialization357339
! Ref: gnat_rm/implementation_defined_aspects aspect-suppress-initialization357497
! Ref: 155357497
! Node: Aspect Test_Case357650
! Ref: gnat_rm/implementation_defined_aspects aspect-test-case357809
! Ref: 156357809
! Node: Aspect Thread_Local_Storage357912
! Ref: gnat_rm/implementation_defined_aspects aspect-thread-local-storage358066
! Ref: 157358066
! Node: Aspect Universal_Aliasing358210
! Ref: gnat_rm/implementation_defined_aspects aspect-universal-aliasing358365
! Ref: 158358365
! Node: Aspect Unmodified358504
! Ref: gnat_rm/implementation_defined_aspects aspect-unmodified358651
! Ref: 159358651
! Node: Aspect Unreferenced358766
! Ref: gnat_rm/implementation_defined_aspects aspect-unreferenced358915
! Ref: 15a358915
! Node: Aspect Unreferenced_Objects359200
! Ref: gnat_rm/implementation_defined_aspects aspect-unreferenced-objects359349
! Ref: 15b359349
! Node: Aspect Value_Size359494
! Ref: gnat_rm/implementation_defined_aspects aspect-value-size359651
! Ref: 15c359651
! Node: Aspect Volatile_Full_Access359761
! Ref: gnat_rm/implementation_defined_aspects aspect-volatile-full-access359915
! Ref: 15e359915
! Node: Aspect Volatile_Function360060
! Ref: gnat_rm/implementation_defined_aspects aspect-volatile-function360212
! Ref: 15f360212
! Node: Aspect Warnings360348
! Ref: gnat_rm/implementation_defined_aspects aspect-warnings360464
! Ref: 160360464
! Node: Implementation Defined Attributes360679
! Ref: gnat_rm/implementation_defined_attributes doc360849
! Ref: 161360849
! Ref: gnat_rm/implementation_defined_attributes id1360849
! Ref: 162360849
! Ref: gnat_rm/implementation_defined_attributes implementation-defined-attributes360849
! Ref: 8360849
! Node: Attribute Abort_Signal364041
! Ref: gnat_rm/implementation_defined_attributes attribute-abort-signal364165
! Ref: 163364165
! Node: Attribute Address_Size364600
! Ref: gnat_rm/implementation_defined_attributes attribute-address-size364752
! Ref: 164364752
! Node: Attribute Asm_Input365133
! Ref: gnat_rm/implementation_defined_attributes attribute-asm-input365283
! Ref: 165365283
! Node: Attribute Asm_Output365908
! Ref: gnat_rm/implementation_defined_attributes attribute-asm-output366069
! Ref: 167366069
! Node: Attribute Atomic_Always_Lock_Free366845
! Ref: gnat_rm/implementation_defined_attributes attribute-atomic-always-lock-free367000
! Ref: 168367000
! Node: Attribute Bit367339
! Ref: gnat_rm/implementation_defined_attributes attribute-bit367496
! Ref: 169367496
! Node: Attribute Bit_Position368577
! Ref: gnat_rm/implementation_defined_attributes attribute-bit-position368723
! Ref: 16a368723
! Node: Attribute Code_Address369169
! Ref: gnat_rm/implementation_defined_attributes attribute-code-address369328
! Ref: 16b369328
! Node: Attribute Compiler_Version370662
! Ref: gnat_rm/implementation_defined_attributes attribute-compiler-version370820
! Ref: 16c370820
! Node: Attribute Constrained371090
! Ref: gnat_rm/implementation_defined_attributes attribute-constrained371253
! Ref: 16d371253
! Node: Attribute Default_Bit_Order371727
! Ref: gnat_rm/implementation_defined_attributes attribute-default-bit-order371902
! Ref: 16e371902
! Node: Attribute Default_Scalar_Storage_Order372274
! Ref: gnat_rm/implementation_defined_attributes attribute-default-scalar-storage-order372443
! Ref: 16f372443
! Node: Attribute Deref372864
! Ref: gnat_rm/implementation_defined_attributes attribute-deref373031
! Ref: 170373031
! Node: Attribute Descriptor_Size373461
! Ref: gnat_rm/implementation_defined_attributes attribute-descriptor-size373610
! Ref: 171373610
! Node: Attribute Elaborated374612
! Ref: gnat_rm/implementation_defined_attributes attribute-elaborated374765
! Ref: 172374765
! Node: Attribute Elab_Body375307
! Ref: gnat_rm/implementation_defined_attributes attribute-elab-body375454
! Ref: 173375454
! Node: Attribute Elab_Spec376004
! Ref: gnat_rm/implementation_defined_attributes attribute-elab-spec376155
! Ref: 174376155
! Node: Attribute Elab_Subp_Body376705
! Ref: gnat_rm/implementation_defined_attributes attribute-elab-subp-body376851
! Ref: 175376851
! Node: Attribute Emax377273
! Ref: gnat_rm/implementation_defined_attributes attribute-emax377417
! Ref: 176377417
! Node: Attribute Enabled377621
! Ref: gnat_rm/implementation_defined_attributes attribute-enabled377759
! Ref: 177377759
! Node: Attribute Enum_Rep378881
! Ref: gnat_rm/implementation_defined_attributes attribute-enum-rep379023
! Ref: 178379023
! Node: Attribute Enum_Val380516
! Ref: gnat_rm/implementation_defined_attributes attribute-enum-val380658
! Ref: 179380658
! Node: Attribute Epsilon381384
! Ref: gnat_rm/implementation_defined_attributes attribute-epsilon381527
! Ref: 17a381527
! Node: Attribute Fast_Math381740
! Ref: gnat_rm/implementation_defined_attributes attribute-fast-math381892
! Ref: 17b381892
! Node: Attribute Finalization_Size382114
! Ref: gnat_rm/implementation_defined_attributes attribute-finalization-size382270
! Ref: 17c382270
! Node: Attribute Fixed_Value382880
! Ref: gnat_rm/implementation_defined_attributes attribute-fixed-value383035
! Ref: 17d383035
! Node: Attribute From_Any383737
! Ref: gnat_rm/implementation_defined_attributes attribute-from-any383892
! Ref: 17e383892
! Node: Attribute Has_Access_Values384069
! Ref: gnat_rm/implementation_defined_attributes attribute-has-access-values384230
! Ref: 17f384230
! Node: Attribute Has_Discriminants384756
! Ref: gnat_rm/implementation_defined_attributes attribute-has-discriminants384926
! Ref: 180384926
! Node: Attribute Has_Tagged_Values385367
! Ref: gnat_rm/implementation_defined_attributes attribute-has-tagged-values385523
! Ref: 181385523
! Node: Attribute Img386053
! Ref: gnat_rm/implementation_defined_attributes attribute-img386203
! Ref: 182386203
! Node: Attribute Initialized386870
! Ref: gnat_rm/implementation_defined_attributes attribute-initialized387016
! Ref: 183387016
! Node: Attribute Integer_Value387171
! Ref: gnat_rm/implementation_defined_attributes attribute-integer-value387327
! Ref: 184387327
! Node: Attribute Invalid_Value388091
! Ref: gnat_rm/implementation_defined_attributes attribute-invalid-value388244
! Ref: 185388244
! Node: Attribute Iterable388718
! Ref: gnat_rm/implementation_defined_attributes attribute-iterable388863
! Ref: 186388863
! Node: Attribute Large388944
! Ref: gnat_rm/implementation_defined_attributes attribute-large389089
! Ref: 187389089
! Node: Attribute Library_Level389296
! Ref: gnat_rm/implementation_defined_attributes attribute-library-level389443
! Ref: 188389443
! Node: Attribute Loop_Entry390079
! Ref: gnat_rm/implementation_defined_attributes attribute-loop-entry390233
! Ref: 189390233
! Node: Attribute Machine_Size391479
! Ref: gnat_rm/implementation_defined_attributes attribute-machine-size391628
! Ref: 18a391628
! Node: Attribute Mantissa391828
! Ref: gnat_rm/implementation_defined_attributes attribute-mantissa391984
! Ref: 18b391984
! Node: Attribute Maximum_Alignment392200
! Ref: gnat_rm/implementation_defined_attributes attribute-maximum-alignment392360
! Ref: 18c392360
! Ref: gnat_rm/implementation_defined_attributes id2392360
! Ref: 18d392360
! Node: Attribute Max_Integer_Size392701
! Ref: gnat_rm/implementation_defined_attributes attribute-max-integer-size392867
! Ref: 18e392867
! Node: Attribute Mechanism_Code393114
! Ref: gnat_rm/implementation_defined_attributes attribute-mechanism-code393277
! Ref: 18f393277
! Node: Attribute Null_Parameter393709
! Ref: gnat_rm/implementation_defined_attributes attribute-null-parameter393867
! Ref: 190393867
! Node: Attribute Object_Size394592
! Ref: gnat_rm/implementation_defined_attributes attribute-object-size394739
! Ref: 141394739
! Ref: gnat_rm/implementation_defined_attributes id3394739
! Ref: 191394739
! Node: Attribute Old396971
! Ref: gnat_rm/implementation_defined_attributes attribute-old397123
! Ref: 192397123
! Node: Attribute Passed_By_Reference397581
! Ref: gnat_rm/implementation_defined_attributes attribute-passed-by-reference397734
! Ref: 193397734
! Node: Attribute Pool_Address398148
! Ref: gnat_rm/implementation_defined_attributes attribute-pool-address398310
! Ref: 194398310
! Node: Attribute Range_Length399066
! Ref: gnat_rm/implementation_defined_attributes attribute-range-length399224
! Ref: 195399224
! Node: Attribute Restriction_Set399610
! Ref: gnat_rm/implementation_defined_attributes attribute-restriction-set399762
! Ref: 196399762
! Node: Attribute Result402236
! Ref: gnat_rm/implementation_defined_attributes attribute-result402385
! Ref: 197402385
! Node: Attribute Safe_Emax402787
! Ref: gnat_rm/implementation_defined_attributes attribute-safe-emax402931
! Ref: 198402931
! Node: Attribute Safe_Large403149
! Ref: gnat_rm/implementation_defined_attributes attribute-safe-large403297
! Ref: 199403297
! Node: Attribute Safe_Small403518
! Ref: gnat_rm/implementation_defined_attributes attribute-safe-small403677
! Ref: 19a403677
! Node: Attribute Scalar_Storage_Order403898
! Ref: gnat_rm/implementation_defined_attributes attribute-scalar-storage-order404066
! Ref: 14f404066
! Ref: gnat_rm/implementation_defined_attributes id4404066
! Ref: 19b404066
! Node: Attribute Simple_Storage_Pool409886
! Ref: gnat_rm/implementation_defined_attributes attribute-simple-storage-pool410049
! Ref: e4410049
! Ref: gnat_rm/implementation_defined_attributes id5410049
! Ref: 19c410049
! Node: Attribute Small412666
! Ref: gnat_rm/implementation_defined_attributes attribute-small412826
! Ref: 19d412826
! Node: Attribute Small_Denominator413193
! Ref: gnat_rm/implementation_defined_attributes attribute-small-denominator413349
! Ref: 19e413349
! Node: Attribute Small_Numerator413625
! Ref: gnat_rm/implementation_defined_attributes attribute-small-numerator413788
! Ref: 19f413788
! Node: Attribute Storage_Unit414056
! Ref: gnat_rm/implementation_defined_attributes attribute-storage-unit414211
! Ref: 1a0414211
! Node: Attribute Stub_Type414395
! Ref: gnat_rm/implementation_defined_attributes attribute-stub-type414561
! Ref: 1a1414561
! Node: Attribute System_Allocator_Alignment415516
! Ref: gnat_rm/implementation_defined_attributes attribute-system-allocator-alignment415681
! Ref: 1a2415681
! Node: Attribute Target_Name416157
! Ref: gnat_rm/implementation_defined_attributes attribute-target-name416323
! Ref: 1a3416323
! Node: Attribute To_Address416698
! Ref: gnat_rm/implementation_defined_attributes attribute-to-address416844
! Ref: 1a4416844
! Node: Attribute To_Any417667
! Ref: gnat_rm/implementation_defined_attributes attribute-to-any417812
! Ref: 1a5417812
! Node: Attribute Type_Class417985
! Ref: gnat_rm/implementation_defined_attributes attribute-type-class418128
! Ref: 1a6418128
! Node: Attribute Type_Key418993
! Ref: gnat_rm/implementation_defined_attributes attribute-type-key419138
! Ref: 1a7419138
! Node: Attribute TypeCode419447
! Ref: gnat_rm/implementation_defined_attributes attribute-typecode419601
! Ref: 1a8419601
! Node: Attribute Unconstrained_Array419778
! Ref: gnat_rm/implementation_defined_attributes attribute-unconstrained-array419948
! Ref: 1a9419948
! Node: Attribute Universal_Literal_String420364
! Ref: gnat_rm/implementation_defined_attributes attribute-universal-literal-string420545
! Ref: 1aa420545
! Node: Attribute Unrestricted_Access421237
! Ref: gnat_rm/implementation_defined_attributes attribute-unrestricted-access421405
! Ref: 1ab421405
! Node: Attribute Update427725
! Ref: gnat_rm/implementation_defined_attributes attribute-update427880
! Ref: 1ac427880
! Node: Attribute Valid_Value430711
! Ref: gnat_rm/implementation_defined_attributes attribute-valid-value430860
! Ref: 1ad430860
! Node: Attribute Valid_Scalars431197
! Ref: gnat_rm/implementation_defined_attributes attribute-valid-scalars431349
! Ref: 1ae431349
! Node: Attribute VADS_Size433007
! Ref: gnat_rm/implementation_defined_attributes attribute-vads-size433158
! Ref: 1af433158
! Node: Attribute Value_Size433799
! Ref: gnat_rm/implementation_defined_attributes attribute-value-size433949
! Ref: 15d433949
! Ref: gnat_rm/implementation_defined_attributes id6433949
! Ref: 1b0433949
! Node: Attribute Wchar_T_Size434194
! Ref: gnat_rm/implementation_defined_attributes attribute-wchar-t-size434344
! Ref: 1b1434344
! Node: Attribute Word_Size434648
! Ref: gnat_rm/implementation_defined_attributes attribute-word-size434769
! Ref: 1b2434769
! Node: Standard and Implementation Defined Restrictions434967
! Ref: gnat_rm/standard_and_implementation_defined_restrictions doc435128
! Ref: 1b3435128
! Ref: gnat_rm/standard_and_implementation_defined_restrictions id1435128
! Ref: 1b4435128
! Ref: gnat_rm/standard_and_implementation_defined_restrictions standard-and-implementation-defined-restrictions435128
! Ref: 9435128
! Node: Partition-Wide Restrictions435659
! Ref: gnat_rm/standard_and_implementation_defined_restrictions id2435812
! Ref: 1b5435812
! Ref: gnat_rm/standard_and_implementation_defined_restrictions partition-wide-restrictions435812
! Ref: 1b6435812
! Node: Immediate_Reclamation438153
! Ref: gnat_rm/standard_and_implementation_defined_restrictions immediate-reclamation438279
! Ref: 1b7438279
! Node: Max_Asynchronous_Select_Nesting438592
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-asynchronous-select-nesting438749
! Ref: 1b8438749
! Node: Max_Entry_Queue_Length439082
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-entry-queue-length439239
! Ref: 1b9439239
! Node: Max_Protected_Entries439935
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-protected-entries440084
! Ref: 1ba440084
! Node: Max_Select_Alternatives440369
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-select-alternatives440519
! Ref: 1bb440519
! Node: Max_Storage_At_Blocking440658
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-storage-at-blocking440803
! Ref: 1bc440803
! Node: Max_Task_Entries441061
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-task-entries441192
! Ref: 1bd441192
! Node: Max_Tasks441453
! Ref: gnat_rm/standard_and_implementation_defined_restrictions max-tasks441580
! Ref: 1be441580
! Node: No_Abort_Statements441908
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-abort-statements442049
! Ref: 1bf442049
! Node: No_Access_Parameter_Allocators442201
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-access-parameter-allocators442354
! Ref: 1c0442354
! Node: No_Access_Subprograms442576
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-access-subprograms442723
! Ref: 1c1442723
! Node: No_Allocators442895
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-allocators443035
! Ref: 1c2443035
! Node: No_Anonymous_Allocators443176
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-anonymous-allocators443318
! Ref: 1c3443318
! Node: No_Asynchronous_Control443504
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-asynchronous-control443644
! Ref: 1c4443644
! Node: No_Calendar443851
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-calendar443983
! Ref: 1c5443983
! Node: No_Coextensions444131
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-coextensions444265
! Ref: 1c6444265
! Node: No_Default_Initialization444408
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-default-initialization444539
! Ref: 1c7444539
! Node: No_Delay445239
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-delay445368
! Ref: 1c8445368
! Node: No_Dependence445536
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dependence445667
! Ref: 1c9445667
! Node: No_Direct_Boolean_Operators445988
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-direct-boolean-operators446122
! Ref: 1ca446122
! Node: No_Dispatch446522
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dispatch446663
! Ref: 1cb446663
! Node: No_Dispatching_Calls446835
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dispatching-calls446970
! Ref: 1cc446970
! Node: No_Dynamic_Attachment449066
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dynamic-attachment449211
! Ref: 1cd449211
! Node: No_Dynamic_Priorities449754
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dynamic-priorities449913
! Ref: 1ce449913
! Node: No_Entry_Calls_In_Elaboration_Code450052
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-entry-calls-in-elaboration-code450209
! Ref: 1cf450209
! Node: No_Enumeration_Maps450569
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-enumeration-maps450726
! Ref: 1d0450726
! Node: No_Exception_Handlers450952
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-exception-handlers451099
! Ref: 1d1451099
! Node: No_Exception_Propagation451972
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-exception-propagation452125
! Ref: 1d2452125
! Node: No_Exception_Registration452798
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-exception-registration452943
! Ref: 1d3452943
! Node: No_Exceptions453424
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-exceptions453560
! Ref: 1d4453560
! Node: No_Finalization453787
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-finalization453912
! Ref: 1d5453912
! Node: No_Fixed_Point454744
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-fixed-point454873
! Ref: 1d6454873
! Node: No_Floating_Point455036
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-floating-point455174
! Ref: 1d7455174
! Node: No_Implicit_Conditionals455346
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-conditionals455494
! Ref: 1d8455494
! Node: No_Implicit_Dynamic_Code456129
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-dynamic-code456288
! Ref: 1d9456288
! Node: No_Implicit_Heap_Allocations457509
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-heap-allocations457684
! Ref: 1da457684
! Node: No_Implicit_Protected_Object_Allocations457828
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-protected-object-allocations458007
! Ref: 1db458007
! Node: No_Implicit_Task_Allocations458195
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-task-allocations458367
! Ref: 1dc458367
! Node: No_Initialize_Scalars458519
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-initialize-scalars458656
! Ref: 1dd458656
! Node: No_IO459000
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-io459128
! Ref: 1de459128
! Node: No_Local_Allocators459346
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-local-allocators459479
! Ref: 1df459479
! Node: No_Local_Protected_Objects459693
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-local-protected-objects459842
! Ref: 1e0459842
! Node: No_Local_Tagged_Types460025
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-local-tagged-types460177
! Ref: 1e1460177
! Node: No_Local_Timing_Events460343
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-local-timing-events460490
! Ref: 1e2460490
! Node: No_Long_Long_Integers460657
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-long-long-integers460806
! Ref: 1e3460806
! Node: No_Multiple_Elaboration461116
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-multiple-elaboration461265
! Ref: 1e4461265
! Node: No_Nested_Finalization461908
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-nested-finalization462064
! Ref: 1e5462064
! Node: No_Protected_Type_Allocators462205
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-protected-type-allocators462356
! Ref: 1e6462356
! Node: No_Protected_Types462564
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-protected-types462705
! Ref: 1e7462705
! Node: No_Recursion462881
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-recursion463007
! Ref: 1e8463007
! Node: No_Reentrancy463144
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-reentrancy463269
! Ref: 1e9463269
! Node: No_Relative_Delay463414
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-relative-delay463548
! Ref: 1ea463548
! Node: No_Requeue_Statements463776
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-requeue-statements463915
! Ref: 1eb463915
! Node: No_Secondary_Stack464382
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-secondary-stack464524
! Ref: 1ec464524
! Node: No_Select_Statements464929
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-select-statements465082
! Ref: 1ed465082
! Node: No_Specific_Termination_Handlers465287
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-specific-termination-handlers465448
! Ref: 1ee465448
! Node: No_Specification_of_Aspect465648
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-specification-of-aspect465829
! Ref: 1ef465829
! Node: No_Standard_Allocators_After_Elaboration466050
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-standard-allocators-after-elaboration466224
! Ref: 1f0466224
! Node: No_Standard_Storage_Pools466539
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-standard-storage-pools466710
! Ref: 1f1466710
! Node: No_Stream_Optimizations467005
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-stream-optimizations467146
! Ref: 1f2467146
! Node: No_Streams467579
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-streams467722
! Ref: 1f3467722
! Node: No_Tagged_Type_Registration468443
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-tagged-type-registration468581
! Ref: 1f4468581
! Node: No_Task_Allocators469063
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-task-allocators469220
! Ref: 1f5469220
! Node: No_Task_At_Interrupt_Priority469362
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-task-at-interrupt-priority469518
! Ref: 1f6469518
! Node: No_Task_Attributes_Package469820
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-task-attributes-package469975
! Ref: 1f7469975
! Node: No_Task_Hierarchy470447
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-task-hierarchy470592
! Ref: 1f8470592
! Node: No_Task_Termination470739
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-task-termination470868
! Ref: 1f9470868
! Node: No_Tasking470969
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-tasking471106
! Ref: 1fa471106
! Node: No_Terminate_Alternatives471426
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-terminate-alternatives471563
! Ref: 1fb471563
! Node: No_Unchecked_Access471700
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-unchecked-access471850
! Ref: 1fc471850
! Node: No_Unchecked_Conversion472021
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-unchecked-conversion472171
! Ref: 1fd472171
! Node: No_Unchecked_Deallocation472382
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-unchecked-deallocation472529
! Ref: 1fe472529
! Node: No_Use_Of_Entity472747
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-use-of-entity472884
! Ref: 1ff472884
! Node: Pure_Barriers473182
! Ref: gnat_rm/standard_and_implementation_defined_restrictions pure-barriers473309
! Ref: 200473309
! Node: Simple_Barriers474014
! Ref: gnat_rm/standard_and_implementation_defined_restrictions simple-barriers474142
! Ref: 201474142
! Node: Static_Priorities474741
! Ref: gnat_rm/standard_and_implementation_defined_restrictions static-priorities474875
! Ref: 202474875
! Node: Static_Storage_Size475096
! Ref: gnat_rm/standard_and_implementation_defined_restrictions static-storage-size475206
! Ref: 203475206
! Node: Program Unit Level Restrictions475407
! Ref: gnat_rm/standard_and_implementation_defined_restrictions id3475560
! Ref: 204475560
! Ref: gnat_rm/standard_and_implementation_defined_restrictions program-unit-level-restrictions475560
! Ref: 205475560
! Node: No_Elaboration_Code476319
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-elaboration-code476447
! Ref: 206476447
! Node: No_Dynamic_Accessibility_Checks479046
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dynamic-accessibility-checks479207
! Ref: 207479207
! Node: No_Dynamic_Sized_Objects481017
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-dynamic-sized-objects481173
! Ref: 208481173
! Node: No_Entry_Queue481895
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-entry-queue482059
! Ref: 209482059
! Node: No_Implementation_Aspect_Specifications482445
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-aspect-specifications482613
! Ref: 20a482613
! Node: No_Implementation_Attributes482907
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-attributes483090
! Ref: 20b483090
! Node: No_Implementation_Identifiers483368
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-identifiers483537
! Ref: 20c483537
! Node: No_Implementation_Pragmas483791
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-pragmas483962
! Ref: 20d483962
! Node: No_Implementation_Restrictions484228
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-restrictions484393
! Ref: 20e484393
! Node: No_Implementation_Units484758
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implementation-units484918
! Ref: 20f484918
! Node: No_Implicit_Aliasing485164
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-aliasing485311
! Ref: 210485311
! Node: No_Implicit_Loops485865
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-implicit-loops486012
! Ref: 211486012
! Node: No_Obsolescent_Features486748
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-obsolescent-features486893
! Ref: 212486893
! Node: No_Wide_Characters487100
! Ref: gnat_rm/standard_and_implementation_defined_restrictions no-wide-characters487250
! Ref: 213487250
! Node: Static_Dispatch_Tables487614
! Ref: gnat_rm/standard_and_implementation_defined_restrictions static-dispatch-tables487749
! Ref: 214487749
! Node: SPARK_05487948
! Ref: gnat_rm/standard_and_implementation_defined_restrictions spark-05488056
! Ref: 215488056
! Node: Implementation Advice488515
! Ref: gnat_rm/implementation_advice doc488681
! Ref: 216488681
! Ref: gnat_rm/implementation_advice id1488681
! Ref: 217488681
! Ref: gnat_rm/implementation_advice implementation-advice488681
! Ref: a488681
! Node: RM 1 1 3 20 Error Detection494586
! Ref: gnat_rm/implementation_advice rm-1-1-3-20-error-detection494704
! Ref: 218494704
! Node: RM 1 1 3 31 Child Units495049
! Ref: gnat_rm/implementation_advice rm-1-1-3-31-child-units495202
! Ref: 219495202
! Node: RM 1 1 5 12 Bounded Errors495491
! Ref: gnat_rm/implementation_advice rm-1-1-5-12-bounded-errors495634
! Ref: 21a495634
! Node: RM 2 8 16 Pragmas495973
! Ref: gnat_rm/implementation_advice id2496113
! Ref: 21b496113
! Ref: gnat_rm/implementation_advice rm-2-8-16-pragmas496113
! Ref: 21c496113
! Node: RM 2 8 17-19 Pragmas497754
! Ref: gnat_rm/implementation_advice rm-2-8-17-19-pragmas497905
! Ref: 21d497905
! Node: RM 3 5 2 5 Alternative Character Sets498339
! Ref: gnat_rm/implementation_advice rm-3-5-2-5-alternative-character-sets498498
! Ref: 21e498498
! Node: RM 3 5 4 28 Integer Types499655
! Ref: gnat_rm/implementation_advice rm-3-5-4-28-integer-types499819
! Ref: 21f499819
! Node: RM 3 5 4 29 Integer Types500493
! Ref: gnat_rm/implementation_advice rm-3-5-4-29-integer-types500649
! Ref: 220500649
! Node: RM 3 5 5 8 Enumeration Values500967
! Ref: gnat_rm/implementation_advice rm-3-5-5-8-enumeration-values501121
! Ref: 221501121
! Node: RM 3 5 7 17 Float Types501670
! Ref: gnat_rm/implementation_advice rm-3-5-7-17-float-types501834
! Ref: 222501834
! Node: RM 3 6 2 11 Multidimensional Arrays502943
! Ref: gnat_rm/implementation_advice rm-3-6-2-11-multidimensional-arrays503107
! Ref: 223503107
! Node: RM 9 6 30-31 Duration’Small503603
! Ref: gnat_rm/implementation_advice rm-9-6-30-31-duration-small503782
! Ref: 224503782
! Node: RM 10 2 1 12 Consistent Representation504204
! Ref: gnat_rm/implementation_advice rm-10-2-1-12-consistent-representation504382
! Ref: 225504382
! Node: RM 11 4 1 19 Exception Information505172
! Ref: gnat_rm/implementation_advice rm-11-4-1-19-exception-information505353
! Ref: 226505353
! Node: RM 11 5 28 Suppression of Checks506495
! Ref: gnat_rm/implementation_advice rm-11-5-28-suppression-of-checks506674
! Ref: 227506674
! Node: RM 13 1 21-24 Representation Clauses506874
! Ref: gnat_rm/implementation_advice rm-13-1-21-24-representation-clauses507043
! Ref: 228507043
! Node: RM 13 2 6-8 Packed Types508457
! Ref: gnat_rm/implementation_advice rm-13-2-6-8-packed-types508623
! Ref: 229508623
! Node: RM 13 3 14-19 Address Clauses509852
! Ref: gnat_rm/implementation_advice rm-13-3-14-19-address-clauses510013
! Ref: 22a510013
! Node: RM 13 3 29-35 Alignment Clauses511148
! Ref: gnat_rm/implementation_advice rm-13-3-29-35-alignment-clauses511311
! Ref: 22b511311
! Node: RM 13 3 42-43 Size Clauses512512
! Ref: gnat_rm/implementation_advice rm-13-3-42-43-size-clauses512672
! Ref: 22c512672
! Node: RM 13 3 50-56 Size Clauses513137
! Ref: gnat_rm/implementation_advice rm-13-3-50-56-size-clauses513302
! Ref: 22d513302
! Node: RM 13 3 71-73 Component Size Clauses514676
! Ref: gnat_rm/implementation_advice rm-13-3-71-73-component-size-clauses514862
! Ref: 22e514862
! Node: RM 13 4 9-10 Enumeration Representation Clauses515670
! Ref: gnat_rm/implementation_advice rm-13-4-9-10-enumeration-representation-clauses515875
! Ref: 22f515875
! Node: RM 13 5 1 17-22 Record Representation Clauses516297
! Ref: gnat_rm/implementation_advice rm-13-5-1-17-22-record-representation-clauses516502
! Ref: 230516502
! Node: RM 13 5 2 5 Storage Place Attributes518197
! Ref: gnat_rm/implementation_advice rm-13-5-2-5-storage-place-attributes518381
! Ref: 231518381
! Node: RM 13 5 3 7-8 Bit Ordering518993
! Ref: gnat_rm/implementation_advice rm-13-5-3-7-8-bit-ordering519161
! Ref: 232519161
! Node: RM 13 7 37 Address as Private519605
! Ref: gnat_rm/implementation_advice rm-13-7-37-address-as-private519768
! Ref: 233519768
! Node: RM 13 7 1 16 Address Operations519909
! Ref: gnat_rm/implementation_advice rm-13-7-1-16-address-operations520080
! Ref: 234520080
! Node: RM 13 9 14-17 Unchecked Conversion520619
! Ref: gnat_rm/implementation_advice rm-13-9-14-17-unchecked-conversion520795
! Ref: 235520795
! Node: RM 13 11 23-25 Implicit Heap Usage522187
! Ref: gnat_rm/implementation_advice rm-13-11-23-25-implicit-heap-usage522368
! Ref: 236522368
! Node: RM 13 11 2 17 Unchecked Deallocation523387
! Ref: gnat_rm/implementation_advice rm-13-11-2-17-unchecked-deallocation523575
! Ref: 237523575
! Node: RM 13 13 2 1 6 Stream Oriented Attributes523769
! Ref: gnat_rm/implementation_advice rm-13-13-2-1-6-stream-oriented-attributes523966
! Ref: 238523966
! Node: RM A 1 52 Names of Predefined Numeric Types524930
! Ref: gnat_rm/implementation_advice rm-a-1-52-names-of-predefined-numeric-types525126
! Ref: 239525126
! Node: RM A 3 2 49 Ada Characters Handling525564
! Ref: gnat_rm/implementation_advice rm-a-3-2-49-ada-characters-handling525762
! Ref: 23a525762
! Node: RM A 4 4 106 Bounded-Length String Handling526154
! Ref: gnat_rm/implementation_advice rm-a-4-4-106-bounded-length-string-handling526348
! Ref: 23b526348
! Node: RM A 5 2 46-47 Random Number Generation526627
! Ref: gnat_rm/implementation_advice rm-a-5-2-46-47-random-number-generation526812
! Ref: 23c526812
! Node: RM A 10 7 23 Get_Immediate527644
! Ref: gnat_rm/implementation_advice rm-a-10-7-23-get-immediate527804
! Ref: 23d527804
! Node: RM A 18 Containers528656
! Ref: gnat_rm/implementation_advice rm-a-18-containers528803
! Ref: 23e528803
! Node: RM B 1 39-41 Pragma Export529434
! Ref: gnat_rm/implementation_advice rm-b-1-39-41-pragma-export529586
! Ref: 23f529586
! Node: RM B 2 12-13 Package Interfaces531114
! Ref: gnat_rm/implementation_advice rm-b-2-12-13-package-interfaces531279
! Ref: 240531279
! Node: RM B 3 63-71 Interfacing with C532092
! Ref: gnat_rm/implementation_advice rm-b-3-63-71-interfacing-with-c532266
! Ref: 241532266
! Node: RM B 4 95-98 Interfacing with COBOL534201
! Ref: gnat_rm/implementation_advice rm-b-4-95-98-interfacing-with-cobol534381
! Ref: 242534381
! Node: RM B 5 22-26 Interfacing with Fortran535115
! Ref: gnat_rm/implementation_advice rm-b-5-22-26-interfacing-with-fortran535303
! Ref: 243535303
! Node: RM C 1 3-5 Access to Machine Operations536391
! Ref: gnat_rm/implementation_advice rm-c-1-3-5-access-to-machine-operations536585
! Ref: 244536585
! Node: RM C 1 10-16 Access to Machine Operations537561
! Ref: gnat_rm/implementation_advice rm-c-1-10-16-access-to-machine-operations537745
! Ref: 245537745
! Node: RM C 3 28 Interrupt Support539015
! Ref: gnat_rm/implementation_advice rm-c-3-28-interrupt-support539203
! Ref: 246539203
! Node: RM C 3 1 20-21 Protected Procedure Handlers539669
! Ref: gnat_rm/implementation_advice rm-c-3-1-20-21-protected-procedure-handlers539846
! Ref: 247539846
! Node: RM C 3 2 25 Package Interrupts540350
! Ref: gnat_rm/implementation_advice rm-c-3-2-25-package-interrupts540538
! Ref: 248540538
! Node: RM C 4 14 Pre-elaboration Requirements541008
! Ref: gnat_rm/implementation_advice rm-c-4-14-pre-elaboration-requirements541182
! Ref: 249541182
! Node: RM C 5 8 Pragma Discard_Names541622
! Ref: gnat_rm/implementation_advice rm-c-5-8-pragma-discard-names541805
! Ref: 24a541805
! Node: RM C 7 2 30 The Package Task_Attributes542069
! Ref: gnat_rm/implementation_advice rm-c-7-2-30-the-package-task-attributes542240
! Ref: 24b542240
! Node: RM D 3 17 Locking Policies542976
! Ref: gnat_rm/implementation_advice rm-d-3-17-locking-policies543150
! Ref: 24c543150
! Node: RM D 4 16 Entry Queuing Policies543523
! Ref: gnat_rm/implementation_advice rm-d-4-16-entry-queuing-policies543686
! Ref: 24d543686
! Node: RM D 6 9-10 Preemptive Abort543950
! Ref: gnat_rm/implementation_advice rm-d-6-9-10-preemptive-abort544117
! Ref: 24e544117
! Node: RM D 7 21 Tasking Restrictions544683
! Ref: gnat_rm/implementation_advice rm-d-7-21-tasking-restrictions544845
! Ref: 24f544845
! Node: RM D 8 47-49 Monotonic Time545347
! Ref: gnat_rm/implementation_advice rm-d-8-47-49-monotonic-time545527
! Ref: 250545527
! Node: RM E 5 28-29 Partition Communication Subsystem546202
! Ref: gnat_rm/implementation_advice rm-e-5-28-29-partition-communication-subsystem546372
! Ref: 251546372
! Node: RM F 7 COBOL Support547066
! Ref: gnat_rm/implementation_advice rm-f-7-cobol-support547239
! Ref: 252547239
! Node: RM F 1 2 Decimal Radix Support547790
! Ref: gnat_rm/implementation_advice rm-f-1-2-decimal-radix-support547930
! Ref: 253547930
! Node: RM G Numerics548244
! Ref: gnat_rm/implementation_advice rm-g-numerics548392
! Ref: 254548392
! Node: RM G 1 1 56-58 Complex Types548922
! Ref: gnat_rm/implementation_advice rm-g-1-1-56-58-complex-types549080
! Ref: 255549080
! Node: RM G 1 2 49 Complex Elementary Functions551909
! Ref: gnat_rm/implementation_advice rm-g-1-2-49-complex-elementary-functions552087
! Ref: 256552087
! Node: RM G 2 4 19 Accuracy Requirements552820
! Ref: gnat_rm/implementation_advice rm-g-2-4-19-accuracy-requirements553009
! Ref: 257553009
! Node: RM G 2 6 15 Complex Arithmetic Accuracy553624
! Ref: gnat_rm/implementation_advice rm-g-2-6-15-complex-arithmetic-accuracy553820
! Ref: 258553820
! Node: RM H 6 15/2 Pragma Partition_Elaboration_Policy554243
! Ref: gnat_rm/implementation_advice rm-h-6-15-2-pragma-partition-elaboration-policy554397
! Ref: 259554397
! Node: Implementation Defined Characteristics554779
! Ref: gnat_rm/implementation_defined_characteristics doc554918
! Ref: 25a554918
! Ref: gnat_rm/implementation_defined_characteristics id1554918
! Ref: 25b554918
! Ref: gnat_rm/implementation_defined_characteristics implementation-defined-characteristics554918
! Ref: b554918
! Node: Intrinsic Subprograms606551
! Ref: gnat_rm/intrinsic_subprograms doc606703
! Ref: 25d606703
! Ref: gnat_rm/intrinsic_subprograms id1606703
! Ref: 25e606703
! Ref: gnat_rm/intrinsic_subprograms intrinsic-subprograms606703
! Ref: c606703
! Node: Intrinsic Operators607683
! Ref: gnat_rm/intrinsic_subprograms id2607790
! Ref: 25f607790
! Ref: gnat_rm/intrinsic_subprograms intrinsic-operators607790
! Ref: 260607790
! Node: Compilation_ISO_Date608789
! Ref: gnat_rm/intrinsic_subprograms compilation-iso-date608921
! Ref: 261608921
! Ref: gnat_rm/intrinsic_subprograms id3608921
! Ref: 262608921
! Node: Compilation_Date609342
! Ref: gnat_rm/intrinsic_subprograms compilation-date609471
! Ref: 263609471
! Ref: gnat_rm/intrinsic_subprograms id4609471
! Ref: 264609471
! Node: Compilation_Time609591
! Ref: gnat_rm/intrinsic_subprograms compilation-time609716
! Ref: 265609716
! Ref: gnat_rm/intrinsic_subprograms id5609716
! Ref: 266609716
! Node: Enclosing_Entity610123
! Ref: gnat_rm/intrinsic_subprograms enclosing-entity610253
! Ref: 267610253
! Ref: gnat_rm/intrinsic_subprograms id6610253
! Ref: 268610253
! Node: Exception_Information610674
! Ref: gnat_rm/intrinsic_subprograms exception-information610805
! Ref: 269610805
! Ref: gnat_rm/intrinsic_subprograms id7610805
! Ref: 26a610805
! Node: Exception_Message611235
! Ref: gnat_rm/intrinsic_subprograms exception-message611364
! Ref: 26b611364
! Ref: gnat_rm/intrinsic_subprograms id8611364
! Ref: 26c611364
! Node: Exception_Name611768
! Ref: gnat_rm/intrinsic_subprograms exception-name611880
! Ref: 26d611880
! Ref: gnat_rm/intrinsic_subprograms id9611880
! Ref: 26e611880
! Node: File612259
! Ref: gnat_rm/intrinsic_subprograms file612358
! Ref: 26f612358
! Ref: gnat_rm/intrinsic_subprograms id10612358
! Ref: 270612358
! Node: Line612690
! Ref: gnat_rm/intrinsic_subprograms id11612793
! Ref: 271612793
! Ref: gnat_rm/intrinsic_subprograms line612793
! Ref: 272612793
! Node: Shifts and Rotates613136
! Ref: gnat_rm/intrinsic_subprograms id12613250
! Ref: 273613250
! Ref: gnat_rm/intrinsic_subprograms shifts-and-rotates613250
! Ref: 274613250
! Node: Source_Location614488
! Ref: gnat_rm/intrinsic_subprograms id13614589
! Ref: 275614589
! Ref: gnat_rm/intrinsic_subprograms source-location614589
! Ref: 276614589
! Node: Representation Clauses and Pragmas614960
! Ref: gnat_rm/representation_clauses_and_pragmas doc615099
! Ref: 277615099
! Ref: gnat_rm/representation_clauses_and_pragmas id1615099
! Ref: 278615099
! Ref: gnat_rm/representation_clauses_and_pragmas representation-clauses-and-pragmas615099
! Ref: d615099
! Node: Alignment Clauses616285
! Ref: gnat_rm/representation_clauses_and_pragmas alignment-clauses616395
! Ref: 279616395
! Ref: gnat_rm/representation_clauses_and_pragmas id2616395
! Ref: 27a616395
! Node: Size Clauses620829
! Ref: gnat_rm/representation_clauses_and_pragmas id3620968
! Ref: 27b620968
! Ref: gnat_rm/representation_clauses_and_pragmas size-clauses620968
! Ref: 27c620968
! Node: Storage_Size Clauses623752
! Ref: gnat_rm/representation_clauses_and_pragmas id4623904
! Ref: 27d623904
! Ref: gnat_rm/representation_clauses_and_pragmas storage-size-clauses623904
! Ref: 27e623904
! Node: Size of Variant Record Objects626432
! Ref: gnat_rm/representation_clauses_and_pragmas id5626593
! Ref: 27f626593
! Ref: gnat_rm/representation_clauses_and_pragmas size-of-variant-record-objects626593
! Ref: 280626593
! Node: Biased Representation629705
! Ref: gnat_rm/representation_clauses_and_pragmas biased-representation629880
! Ref: 281629880
! Ref: gnat_rm/representation_clauses_and_pragmas id6629880
! Ref: 282629880
! Node: Value_Size and Object_Size Clauses630924
! Ref: gnat_rm/representation_clauses_and_pragmas id7631091
! Ref: 283631091
! Ref: gnat_rm/representation_clauses_and_pragmas value-size-and-object-size-clauses631091
! Ref: 284631091
! Node: Component_Size Clauses640745
! Ref: gnat_rm/representation_clauses_and_pragmas component-size-clauses640908
! Ref: 285640908
! Ref: gnat_rm/representation_clauses_and_pragmas id8640908
! Ref: 286640908
! Node: Bit_Order Clauses642542
! Ref: gnat_rm/representation_clauses_and_pragmas bit-order-clauses642707
! Ref: 287642707
! Ref: gnat_rm/representation_clauses_and_pragmas id9642707
! Ref: 288642707
! Node: Effect of Bit_Order on Byte Ordering646152
! Ref: gnat_rm/representation_clauses_and_pragmas effect-of-bit-order-on-byte-ordering646317
! Ref: 289646317
! Ref: gnat_rm/representation_clauses_and_pragmas id10646317
! Ref: 28a646317
! Node: Pragma Pack for Arrays655772
! Ref: gnat_rm/representation_clauses_and_pragmas id11655943
! Ref: 28b655943
! Ref: gnat_rm/representation_clauses_and_pragmas pragma-pack-for-arrays655943
! Ref: 28c655943
! Node: Pragma Pack for Records660440
! Ref: gnat_rm/representation_clauses_and_pragmas id12660604
! Ref: 28d660604
! Ref: gnat_rm/representation_clauses_and_pragmas pragma-pack-for-records660604
! Ref: 28e660604
! Node: Record Representation Clauses663156
! Ref: gnat_rm/representation_clauses_and_pragmas id13663328
! Ref: 28f663328
! Ref: gnat_rm/representation_clauses_and_pragmas record-representation-clauses663328
! Ref: 290663328
! Node: Handling of Records with Holes666216
! Ref: gnat_rm/representation_clauses_and_pragmas handling-of-records-with-holes666384
! Ref: 291666384
! Ref: gnat_rm/representation_clauses_and_pragmas id14666384
! Ref: 292666384
! Node: Enumeration Clauses668646
! Ref: gnat_rm/representation_clauses_and_pragmas enumeration-clauses668800
! Ref: 293668800
! Ref: gnat_rm/representation_clauses_and_pragmas id15668800
! Ref: 294668800
! Node: Address Clauses670232
! Ref: gnat_rm/representation_clauses_and_pragmas address-clauses670400
! Ref: 295670400
! Ref: gnat_rm/representation_clauses_and_pragmas id16670400
! Ref: 296670400
! Node: Use of Address Clauses for Memory-Mapped I/O681892
! Ref: gnat_rm/representation_clauses_and_pragmas id17682079
! Ref: 297682079
! Ref: gnat_rm/representation_clauses_and_pragmas use-of-address-clauses-for-memory-mapped-i-o682079
! Ref: 298682079
! Node: Effect of Convention on Representation683947
! Ref: gnat_rm/representation_clauses_and_pragmas effect-of-convention-on-representation684157
! Ref: 299684157
! Ref: gnat_rm/representation_clauses_and_pragmas id18684157
! Ref: 29a684157
! Node: Conventions and Anonymous Access Types687270
! Ref: gnat_rm/representation_clauses_and_pragmas conventions-and-anonymous-access-types687482
! Ref: 29b687482
! Ref: gnat_rm/representation_clauses_and_pragmas id19687482
! Ref: 29c687482
! Node: Determining the Representations chosen by GNAT689973
! Ref: gnat_rm/representation_clauses_and_pragmas determining-the-representations-chosen-by-gnat690138
! Ref: 29d690138
! Ref: gnat_rm/representation_clauses_and_pragmas id20690138
! Ref: 29e690138
! Node: Standard Library Routines694728
! Ref: gnat_rm/standard_library_routines doc694880
! Ref: 29f694880
! Ref: gnat_rm/standard_library_routines id1694880
! Ref: 2a0694880
! Ref: gnat_rm/standard_library_routines standard-library-routines694880
! Ref: e694880
! Node: The Implementation of Standard I/O721525
! Ref: gnat_rm/the_implementation_of_standard_i_o doc721659
! Ref: 2a1721659
! Ref: gnat_rm/the_implementation_of_standard_i_o id1721659
! Ref: 2a2721659
! Ref: gnat_rm/the_implementation_of_standard_i_o the-implementation-of-standard-i-o721659
! Ref: f721659
! Node: Standard I/O Packages723709
! Ref: gnat_rm/the_implementation_of_standard_i_o id2723823
! Ref: 2a3723823
! Ref: gnat_rm/the_implementation_of_standard_i_o standard-i-o-packages723823
! Ref: 2a4723823
! Node: FORM Strings725162
! Ref: gnat_rm/the_implementation_of_standard_i_o form-strings725294
! Ref: 2a5725294
! Ref: gnat_rm/the_implementation_of_standard_i_o id3725294
! Ref: 2a6725294
! Node: Direct_IO725908
! Ref: gnat_rm/the_implementation_of_standard_i_o direct-io726032
! Ref: 2a7726032
! Ref: gnat_rm/the_implementation_of_standard_i_o id4726032
! Ref: 2a8726032
! Node: Sequential_IO726809
! Ref: gnat_rm/the_implementation_of_standard_i_o id5726928
! Ref: 2a9726928
! Ref: gnat_rm/the_implementation_of_standard_i_o sequential-io726928
! Ref: 2aa726928
! Node: Text_IO728765
! Ref: gnat_rm/the_implementation_of_standard_i_o id6728887
! Ref: 2ab728887
! Ref: gnat_rm/the_implementation_of_standard_i_o text-io728887
! Ref: 2ac728887
! Node: Stream Pointer Positioning731375
! Ref: gnat_rm/the_implementation_of_standard_i_o id7731492
! Ref: 2ad731492
! Ref: gnat_rm/the_implementation_of_standard_i_o stream-pointer-positioning731492
! Ref: 2ae731492
! Node: Reading and Writing Non-Regular Files732939
! Ref: gnat_rm/the_implementation_of_standard_i_o id8733078
! Ref: 2af733078
! Ref: gnat_rm/the_implementation_of_standard_i_o reading-and-writing-non-regular-files733078
! Ref: 2b0733078
! Node: Get_Immediate734852
! Ref: gnat_rm/the_implementation_of_standard_i_o get-immediate734998
! Ref: 2b1734998
! Ref: gnat_rm/the_implementation_of_standard_i_o id9734998
! Ref: 2b2734998
! Node: Treating Text_IO Files as Streams735691
! Ref: gnat_rm/the_implementation_of_standard_i_o id10735818
! Ref: 2b3735818
! Ref: gnat_rm/the_implementation_of_standard_i_o treating-text-io-files-as-streams735818
! Ref: 2b4735818
! Node: Text_IO Extensions736406
! Ref: gnat_rm/the_implementation_of_standard_i_o id11736560
! Ref: 2b5736560
! Ref: gnat_rm/the_implementation_of_standard_i_o text-io-extensions736560
! Ref: 2b6736560
! Node: Text_IO Facilities for Unbounded Strings737177
! Ref: gnat_rm/the_implementation_of_standard_i_o id12737289
! Ref: 2b7737289
! Ref: gnat_rm/the_implementation_of_standard_i_o text-io-facilities-for-unbounded-strings737289
! Ref: 2b8737289
! Node: Wide_Text_IO738863
! Ref: gnat_rm/the_implementation_of_standard_i_o id13738989
! Ref: 2b9738989
! Ref: gnat_rm/the_implementation_of_standard_i_o wide-text-io738989
! Ref: 2ba738989
! Node: Stream Pointer Positioning<2>745918
! Ref: gnat_rm/the_implementation_of_standard_i_o id14746046
! Ref: 2bb746046
! Ref: gnat_rm/the_implementation_of_standard_i_o stream-pointer-positioning-1746046
! Ref: 2bc746046
! Node: Reading and Writing Non-Regular Files<2>746964
! Ref: gnat_rm/the_implementation_of_standard_i_o id15747092
! Ref: 2bd747092
! Ref: gnat_rm/the_implementation_of_standard_i_o reading-and-writing-non-regular-files-1747092
! Ref: 2be747092
! Node: Wide_Wide_Text_IO747501
! Ref: gnat_rm/the_implementation_of_standard_i_o id16747629
! Ref: 2bf747629
! Ref: gnat_rm/the_implementation_of_standard_i_o wide-wide-text-io747629
! Ref: 2c0747629
! Node: Stream Pointer Positioning<3>751278
! Ref: gnat_rm/the_implementation_of_standard_i_o id17751411
! Ref: 2c1751411
! Ref: gnat_rm/the_implementation_of_standard_i_o stream-pointer-positioning-2751411
! Ref: 2c2751411
! Node: Reading and Writing Non-Regular Files<3>752361
! Ref: gnat_rm/the_implementation_of_standard_i_o id18752494
! Ref: 2c3752494
! Ref: gnat_rm/the_implementation_of_standard_i_o reading-and-writing-non-regular-files-2752494
! Ref: 2c4752494
! Node: Stream_IO752903
! Ref: gnat_rm/the_implementation_of_standard_i_o id19753035
! Ref: 2c5753035
! Ref: gnat_rm/the_implementation_of_standard_i_o stream-io753035
! Ref: 2c6753035
! Node: Text Translation753552
! Ref: gnat_rm/the_implementation_of_standard_i_o id20753679
! Ref: 2c7753679
! Ref: gnat_rm/the_implementation_of_standard_i_o text-translation753679
! Ref: 2c8753679
! Node: Shared Files754479
! Ref: gnat_rm/the_implementation_of_standard_i_o id21754615
! Ref: 2c9754615
! Ref: gnat_rm/the_implementation_of_standard_i_o shared-files754615
! Ref: 2ca754615
! Node: Filenames encoding757361
! Ref: gnat_rm/the_implementation_of_standard_i_o filenames-encoding757502
! Ref: 2cb757502
! Ref: gnat_rm/the_implementation_of_standard_i_o id22757502
! Ref: 2cc757502
! Node: File content encoding758304
! Ref: gnat_rm/the_implementation_of_standard_i_o file-content-encoding758443
! Ref: 2cd758443
! Ref: gnat_rm/the_implementation_of_standard_i_o id23758443
! Ref: 2ce758443
! Node: Open Modes758951
! Ref: gnat_rm/the_implementation_of_standard_i_o id24759095
! Ref: 2cf759095
! Ref: gnat_rm/the_implementation_of_standard_i_o open-modes759095
! Ref: 2d0759095
! Node: Operations on C Streams761081
! Ref: gnat_rm/the_implementation_of_standard_i_o id25761228
! Ref: 2d1761228
! Ref: gnat_rm/the_implementation_of_standard_i_o operations-on-c-streams761228
! Ref: 2d2761228
! Node: Interfacing to C Streams768032
! Ref: gnat_rm/the_implementation_of_standard_i_o id26768160
! Ref: 2d3768160
! Ref: gnat_rm/the_implementation_of_standard_i_o interfacing-to-c-streams768160
! Ref: 2d4768160
! Node: The GNAT Library771472
! Ref: gnat_rm/the_gnat_library doc771611
! Ref: 2d5771611
! Ref: gnat_rm/the_gnat_library id1771611
! Ref: 2d6771611
! Ref: gnat_rm/the_gnat_library the-gnat-library771611
! Ref: 10771611
! Node: Ada Characters Latin_9 a-chlat9 ads784491
! Ref: gnat_rm/the_gnat_library ada-characters-latin-9-a-chlat9-ads784629
! Ref: 2d7784629
! Ref: gnat_rm/the_gnat_library id2784629
! Ref: 2d8784629
! Node: Ada Characters Wide_Latin_1 a-cwila1 ads785039
! Ref: gnat_rm/the_gnat_library ada-characters-wide-latin-1-a-cwila1-ads785226
! Ref: 2d9785226
! Ref: gnat_rm/the_gnat_library id3785226
! Ref: 2da785226
! Node: Ada Characters Wide_Latin_9 a-cwila9 ads785678
! Ref: gnat_rm/the_gnat_library ada-characters-wide-latin-9-a-cwila9-ads785875
! Ref: 2db785875
! Ref: gnat_rm/the_gnat_library id4785875
! Ref: 2dc785875
! Node: Ada Characters Wide_Wide_Latin_1 a-chzla1 ads786329
! Ref: gnat_rm/the_gnat_library ada-characters-wide-wide-latin-1-a-chzla1-ads786531
! Ref: 2dd786531
! Ref: gnat_rm/the_gnat_library id5786531
! Ref: 2de786531
! Node: Ada Characters Wide_Wide_Latin_9 a-chzla9 ads786998
! Ref: gnat_rm/the_gnat_library ada-characters-wide-wide-latin-9-a-chzla9-ads787203
! Ref: 2df787203
! Ref: gnat_rm/the_gnat_library id6787203
! Ref: 2e0787203
! Node: Ada Containers Bounded_Holders a-coboho ads787672
! Ref: gnat_rm/the_gnat_library ada-containers-bounded-holders-a-coboho-ads787873
! Ref: 2e1787873
! Ref: gnat_rm/the_gnat_library id7787873
! Ref: 2e2787873
! Node: Ada Command_Line Environment a-colien ads788106
! Ref: gnat_rm/the_gnat_library ada-command-line-environment-a-colien-ads788298
! Ref: 2e3788298
! Ref: gnat_rm/the_gnat_library id8788298
! Ref: 2e4788298
! Node: Ada Command_Line Remove a-colire ads788548
! Ref: gnat_rm/the_gnat_library ada-command-line-remove-a-colire-ads788740
! Ref: 2e5788740
! Ref: gnat_rm/the_gnat_library id9788740
! Ref: 2e6788740
! Node: Ada Command_Line Response_File a-clrefi ads789113
! Ref: gnat_rm/the_gnat_library ada-command-line-response-file-a-clrefi-ads789300
! Ref: 2e7789300
! Ref: gnat_rm/the_gnat_library id10789300
! Ref: 2e8789300
! Node: Ada Direct_IO C_Streams a-diocst ads789712
! Ref: gnat_rm/the_gnat_library ada-direct-io-c-streams-a-diocst-ads789909
! Ref: 2e9789909
! Ref: gnat_rm/the_gnat_library id11789909
! Ref: 2ea789909
! Node: Ada Exceptions Is_Null_Occurrence a-einuoc ads790260
! Ref: gnat_rm/the_gnat_library ada-exceptions-is-null-occurrence-a-einuoc-ads790461
! Ref: 2eb790461
! Ref: gnat_rm/the_gnat_library id12790461
! Ref: 2ec790461
! Node: Ada Exceptions Last_Chance_Handler a-elchha ads790725
! Ref: gnat_rm/the_gnat_library ada-exceptions-last-chance-handler-a-elchha-ads790927
! Ref: 2ed790927
! Ref: gnat_rm/the_gnat_library id13790927
! Ref: 2ee790927
! Node: Ada Exceptions Traceback a-exctra ads791257
! Ref: gnat_rm/the_gnat_library ada-exceptions-traceback-a-exctra-ads791453
! Ref: 2ef791453
! Ref: gnat_rm/the_gnat_library id14791453
! Ref: 2f0791453
! Node: Ada Sequential_IO C_Streams a-siocst ads791698
! Ref: gnat_rm/the_gnat_library ada-sequential-io-c-streams-a-siocst-ads791891
! Ref: 2f1791891
! Ref: gnat_rm/the_gnat_library id15791891
! Ref: 2f2791891
! Node: Ada Streams Stream_IO C_Streams a-ssicst ads792254
! Ref: gnat_rm/the_gnat_library ada-streams-stream-io-c-streams-a-ssicst-ads792452
! Ref: 2f3792452
! Ref: gnat_rm/the_gnat_library id16792452
! Ref: 2f4792452
! Node: Ada Strings Unbounded Text_IO a-suteio ads792819
! Ref: gnat_rm/the_gnat_library ada-strings-unbounded-text-io-a-suteio-ads793029
! Ref: 2f5793029
! Ref: gnat_rm/the_gnat_library id17793029
! Ref: 2f6793029
! Node: Ada Strings Wide_Unbounded Wide_Text_IO a-swuwti ads793294
! Ref: gnat_rm/the_gnat_library ada-strings-wide-unbounded-wide-text-io-a-swuwti-ads793522
! Ref: 2f7793522
! Ref: gnat_rm/the_gnat_library id18793522
! Ref: 2f8793522
! Node: Ada Strings Wide_Wide_Unbounded Wide_Wide_Text_IO a-szuzti ads793817
! Ref: gnat_rm/the_gnat_library ada-strings-wide-wide-unbounded-wide-wide-text-io-a-szuzti-ads794039
! Ref: 2f9794039
! Ref: gnat_rm/the_gnat_library id19794039
! Ref: 2fa794039
! Node: Ada Task_Initialization a-tasini ads794364
! Ref: gnat_rm/the_gnat_library ada-task-initialization-a-tasini-ads794568
! Ref: 2fb794568
! Ref: gnat_rm/the_gnat_library id20794568
! Ref: 2fc794568
! Node: Ada Text_IO C_Streams a-tiocst ads794937
! Ref: gnat_rm/the_gnat_library ada-text-io-c-streams-a-tiocst-ads795124
! Ref: 2fd795124
! Ref: gnat_rm/the_gnat_library id21795124
! Ref: 2fe795124
! Node: Ada Text_IO Reset_Standard_Files a-tirsfi ads795469
! Ref: gnat_rm/the_gnat_library ada-text-io-reset-standard-files-a-tirsfi-ads795660
! Ref: 2ff795660
! Ref: gnat_rm/the_gnat_library id22795660
! Ref: 300795660
! Node: Ada Wide_Characters Unicode a-wichun ads796079
! Ref: gnat_rm/the_gnat_library ada-wide-characters-unicode-a-wichun-ads796275
! Ref: 301796275
! Ref: gnat_rm/the_gnat_library id23796275
! Ref: 302796275
! Node: Ada Wide_Text_IO C_Streams a-wtcstr ads796509
! Ref: gnat_rm/the_gnat_library ada-wide-text-io-c-streams-a-wtcstr-ads796710
! Ref: 303796710
! Ref: gnat_rm/the_gnat_library id24796710
! Ref: 304796710
! Node: Ada Wide_Text_IO Reset_Standard_Files a-wrstfi ads797070
! Ref: gnat_rm/the_gnat_library ada-wide-text-io-reset-standard-files-a-wrstfi-ads797276
! Ref: 305797276
! Ref: gnat_rm/the_gnat_library id25797276
! Ref: 306797276
! Node: Ada Wide_Wide_Characters Unicode a-zchuni ads797710
! Ref: gnat_rm/the_gnat_library ada-wide-wide-characters-unicode-a-zchuni-ads797921
! Ref: 307797921
! Ref: gnat_rm/the_gnat_library id26797921
! Ref: 308797921
! Node: Ada Wide_Wide_Text_IO C_Streams a-ztcstr ads798170
! Ref: gnat_rm/the_gnat_library ada-wide-wide-text-io-c-streams-a-ztcstr-ads798386
! Ref: 309798386
! Ref: gnat_rm/the_gnat_library id27798386
! Ref: 30a798386
! Node: Ada Wide_Wide_Text_IO Reset_Standard_Files a-zrstfi ads798761
! Ref: gnat_rm/the_gnat_library ada-wide-wide-text-io-reset-standard-files-a-zrstfi-ads798957
! Ref: 30b798957
! Ref: gnat_rm/the_gnat_library id28798957
! Ref: 30c798957
! Node: GNAT Altivec g-altive ads799406
! Ref: gnat_rm/the_gnat_library gnat-altivec-g-altive-ads799595
! Ref: 30d799595
! Ref: gnat_rm/the_gnat_library id29799595
! Ref: 30e799595
! Node: GNAT Altivec Conversions g-altcon ads799826
! Ref: gnat_rm/the_gnat_library gnat-altivec-conversions-g-altcon-ads800003
! Ref: 30f800003
! Ref: gnat_rm/the_gnat_library id30800003
! Ref: 310800003
! Node: GNAT Altivec Vector_Operations g-alveop ads800172
! Ref: gnat_rm/the_gnat_library gnat-altivec-vector-operations-g-alveop-ads800362
! Ref: 311800362
! Ref: gnat_rm/the_gnat_library id31800362
! Ref: 312800362
! Node: GNAT Altivec Vector_Types g-alvety ads800722
! Ref: gnat_rm/the_gnat_library gnat-altivec-vector-types-g-alvety-ads800913
! Ref: 313800913
! Ref: gnat_rm/the_gnat_library id32800913
! Ref: 314800913
! Node: GNAT Altivec Vector_Views g-alvevi ads801118
! Ref: gnat_rm/the_gnat_library gnat-altivec-vector-views-g-alvevi-ads801295
! Ref: 315801295
! Ref: gnat_rm/the_gnat_library id33801295
! Ref: 316801295
! Node: GNAT Array_Split g-arrspl ads801666
! Ref: gnat_rm/the_gnat_library gnat-array-split-g-arrspl-ads801823
! Ref: 317801823
! Ref: gnat_rm/the_gnat_library id34801823
! Ref: 318801823
! Node: GNAT AWK g-awk ads802078
! Ref: gnat_rm/the_gnat_library gnat-awk-g-awk-ads802228
! Ref: 319802228
! Ref: gnat_rm/the_gnat_library id35802228
! Ref: 31a802228
! Node: GNAT Binary_Search g-binsea ads802523
! Ref: gnat_rm/the_gnat_library gnat-binary-search-g-binsea-ads802678
! Ref: 31b802678
! Ref: gnat_rm/the_gnat_library id36802678
! Ref: 31c802678
! Node: GNAT Bind_Environment g-binenv ads802898
! Ref: gnat_rm/the_gnat_library gnat-bind-environment-g-binenv-ads803070
! Ref: 31d803070
! Ref: gnat_rm/the_gnat_library id37803070
! Ref: 31e803070
! Node: GNAT Branch_Prediction g-brapre ads803323
! Ref: gnat_rm/the_gnat_library gnat-branch-prediction-g-brapre-ads803497
! Ref: 31f803497
! Ref: gnat_rm/the_gnat_library id38803497
! Ref: 320803497
! Node: GNAT Bounded_Buffers g-boubuf ads803681
! Ref: gnat_rm/the_gnat_library gnat-bounded-buffers-g-boubuf-ads803856
! Ref: 321803856
! Ref: gnat_rm/the_gnat_library id39803856
! Ref: 322803856
! Node: GNAT Bounded_Mailboxes g-boumai ads804124
! Ref: gnat_rm/the_gnat_library gnat-bounded-mailboxes-g-boumai-ads804293
! Ref: 323804293
! Ref: gnat_rm/the_gnat_library id40804293
! Ref: 324804293
! Node: GNAT Bubble_Sort g-bubsor ads804477
! Ref: gnat_rm/the_gnat_library gnat-bubble-sort-g-bubsor-ads804644
! Ref: 325804644
! Ref: gnat_rm/the_gnat_library id41804644
! Ref: 326804644
! Node: GNAT Bubble_Sort_A g-busora ads804916
! Ref: gnat_rm/the_gnat_library gnat-bubble-sort-a-g-busora-ads805079
! Ref: 327805079
! Ref: gnat_rm/the_gnat_library id42805079
! Ref: 328805079
! Node: GNAT Bubble_Sort_G g-busorg ads805458
! Ref: gnat_rm/the_gnat_library gnat-bubble-sort-g-g-busorg-ads805625
! Ref: 329805625
! Ref: gnat_rm/the_gnat_library id43805625
! Ref: 32a805625
! Node: GNAT Byte_Order_Mark g-byorma ads805969
! Ref: gnat_rm/the_gnat_library gnat-byte-order-mark-g-byorma-ads806136
! Ref: 32b806136
! Ref: gnat_rm/the_gnat_library id44806136
! Ref: 32c806136
! Node: GNAT Byte_Swapping g-bytswa ads806506
! Ref: gnat_rm/the_gnat_library gnat-byte-swapping-g-bytswa-ads806668
! Ref: 32d806668
! Ref: gnat_rm/the_gnat_library id45806668
! Ref: 32e806668
! Node: GNAT Calendar g-calend ads806903
! Ref: gnat_rm/the_gnat_library gnat-calendar-g-calend-ads807066
! Ref: 32f807066
! Ref: gnat_rm/the_gnat_library id46807066
! Ref: 330807066
! Node: GNAT Calendar Time_IO g-catiio ads807403
! Ref: gnat_rm/the_gnat_library gnat-calendar-time-io-g-catiio-ads807557
! Ref: 331807557
! Ref: gnat_rm/the_gnat_library id47807557
! Ref: 332807557
! Node: GNAT CRC32 g-crc32 ads807660
! Ref: gnat_rm/the_gnat_library gnat-crc32-g-crc32-ads807815
! Ref: 333807815
! Ref: gnat_rm/the_gnat_library id48807815
! Ref: 334807815
! Node: GNAT Case_Util g-casuti ads808141
! Ref: gnat_rm/the_gnat_library gnat-case-util-g-casuti-ads808280
! Ref: 335808280
! Ref: gnat_rm/the_gnat_library id49808280
! Ref: 336808280
! Node: GNAT CGI g-cgi ads808523
! Ref: gnat_rm/the_gnat_library gnat-cgi-g-cgi-ads808668
! Ref: 337808668
! Ref: gnat_rm/the_gnat_library id50808668
! Ref: 338808668
! Node: GNAT CGI Cookie g-cgicoo ads809050
! Ref: gnat_rm/the_gnat_library gnat-cgi-cookie-g-cgicoo-ads809195
! Ref: 339809195
! Ref: gnat_rm/the_gnat_library id51809195
! Ref: 33a809195
! Node: GNAT CGI Debug g-cgideb ads809492
! Ref: gnat_rm/the_gnat_library gnat-cgi-debug-g-cgideb-ads809649
! Ref: 33b809649
! Ref: gnat_rm/the_gnat_library id52809649
! Ref: 33c809649
! Node: GNAT Command_Line g-comlin ads809831
! Ref: gnat_rm/the_gnat_library gnat-command-line-g-comlin-ads809994
! Ref: 33d809994
! Ref: gnat_rm/the_gnat_library id53809994
! Ref: 33e809994
! Node: GNAT Compiler_Version g-comver ads810282
! Ref: gnat_rm/the_gnat_library gnat-compiler-version-g-comver-ads810442
! Ref: 33f810442
! Ref: gnat_rm/the_gnat_library id54810442
! Ref: 340810442
! Node: GNAT Ctrl_C g-ctrl_c ads810846
! Ref: gnat_rm/the_gnat_library gnat-ctrl-c-g-ctrl-c-ads811011
! Ref: 341811011
! Ref: gnat_rm/the_gnat_library id55811011
! Ref: 342811011
! Node: GNAT Current_Exception g-curexc ads811157
! Ref: gnat_rm/the_gnat_library gnat-current-exception-g-curexc-ads811317
! Ref: 343811317
! Ref: gnat_rm/the_gnat_library id56811317
! Ref: 344811317
! Node: GNAT Debug_Pools g-debpoo ads811733
! Ref: gnat_rm/the_gnat_library gnat-debug-pools-g-debpoo-ads811902
! Ref: 345811902
! Ref: gnat_rm/the_gnat_library id57811902
! Ref: 346811902
! Node: GNAT Debug_Utilities g-debuti ads812161
! Ref: gnat_rm/the_gnat_library gnat-debug-utilities-g-debuti-ads812326
! Ref: 347812326
! Ref: gnat_rm/the_gnat_library id58812326
! Ref: 348812326
! Node: GNAT Decode_String g-decstr ads812609
! Ref: gnat_rm/the_gnat_library gnat-decode-string-g-decstr-ads812781
! Ref: 349812781
! Ref: gnat_rm/the_gnat_library id59812781
! Ref: 34a812781
! Node: GNAT Decode_UTF8_String g-deutst ads813289
! Ref: gnat_rm/the_gnat_library gnat-decode-utf8-string-g-deutst-ads813466
! Ref: 34b813466
! Ref: gnat_rm/the_gnat_library id60813466
! Ref: 34c813466
! Node: GNAT Directory_Operations g-dirope ads813636
! Ref: gnat_rm/the_gnat_library gnat-directory-operations-g-dirope-ads813830
! Ref: 34d813830
! Ref: gnat_rm/the_gnat_library id61813830
! Ref: 34e813830
! Node: GNAT Directory_Operations Iteration g-diopit ads814104
! Ref: gnat_rm/the_gnat_library gnat-directory-operations-iteration-g-diopit-ads814295
! Ref: 34f814295
! Ref: gnat_rm/the_gnat_library id62814295
! Ref: 350814295
! Node: GNAT Dynamic_HTables g-dynhta ads814536
! Ref: gnat_rm/the_gnat_library gnat-dynamic-htables-g-dynhta-ads814721
! Ref: 351814721
! Ref: gnat_rm/the_gnat_library id63814721
! Ref: 352814721
! Node: GNAT Dynamic_Tables g-dyntab ads815302
! Ref: gnat_rm/the_gnat_library gnat-dynamic-tables-g-dyntab-ads815470
! Ref: 353815470
! Ref: gnat_rm/the_gnat_library id64815470
! Ref: 354815470
! Node: GNAT Encode_String g-encstr ads815953
! Ref: gnat_rm/the_gnat_library gnat-encode-string-g-encstr-ads816124
! Ref: 355816124
! Ref: gnat_rm/the_gnat_library id65816124
! Ref: 356816124
! Node: GNAT Encode_UTF8_String g-enutst ads816503
! Ref: gnat_rm/the_gnat_library gnat-encode-utf8-string-g-enutst-ads816677
! Ref: 357816677
! Ref: gnat_rm/the_gnat_library id66816677
! Ref: 358816677
! Node: GNAT Exception_Actions g-excact ads816847
! Ref: gnat_rm/the_gnat_library gnat-exception-actions-g-excact-ads817024
! Ref: 359817024
! Ref: gnat_rm/the_gnat_library id67817024
! Ref: 35a817024
! Node: GNAT Exception_Traces g-exctra ads817335
! Ref: gnat_rm/the_gnat_library gnat-exception-traces-g-exctra-ads817504
! Ref: 35b817504
! Ref: gnat_rm/the_gnat_library id68817504
! Ref: 35c817504
! Node: GNAT Exceptions g-except ads817695
! Ref: gnat_rm/the_gnat_library gnat-exceptions-g-except-ads817853
! Ref: 35d817853
! Ref: gnat_rm/the_gnat_library id69817853
! Ref: 35e817853
! Node: GNAT Expect g-expect ads818347
! Ref: gnat_rm/the_gnat_library gnat-expect-g-expect-ads818499
! Ref: 35f818499
! Ref: gnat_rm/the_gnat_library id70818499
! Ref: 360818499
! Node: GNAT Expect TTY g-exptty ads819030
! Ref: gnat_rm/the_gnat_library gnat-expect-tty-g-exptty-ads819185
! Ref: 361819185
! Ref: gnat_rm/the_gnat_library id71819185
! Ref: 362819185
! Node: GNAT Float_Control g-flocon ads819493
! Ref: gnat_rm/the_gnat_library gnat-float-control-g-flocon-ads819658
! Ref: 363819658
! Ref: gnat_rm/the_gnat_library id72819658
! Ref: 364819658
! Node: GNAT Formatted_String g-forstr ads820037
! Ref: gnat_rm/the_gnat_library gnat-formatted-string-g-forstr-ads820219
! Ref: 365820219
! Ref: gnat_rm/the_gnat_library id73820219
! Ref: 366820219
! Node: GNAT Generic_Fast_Math_Functions g-gfmafu ads820610
! Ref: gnat_rm/the_gnat_library gnat-generic-fast-math-functions-g-gfmafu-ads820788
! Ref: 367820788
! Ref: gnat_rm/the_gnat_library id74820788
! Ref: 368820788
! Node: GNAT Heap_Sort g-heasor ads821461
! Ref: gnat_rm/the_gnat_library gnat-heap-sort-g-heasor-ads821634
! Ref: 369821634
! Ref: gnat_rm/the_gnat_library id75821634
! Ref: 36a821634
! Node: GNAT Heap_Sort_A g-hesora ads822012
! Ref: gnat_rm/the_gnat_library gnat-heap-sort-a-g-hesora-ads822169
! Ref: 36b822169
! Ref: gnat_rm/the_gnat_library id76822169
! Ref: 36c822169
! Node: GNAT Heap_Sort_G g-hesorg ads822662
! Ref: gnat_rm/the_gnat_library gnat-heap-sort-g-g-hesorg-ads822816
! Ref: 36d822816
! Ref: gnat_rm/the_gnat_library id77822816
! Ref: 36e822816
! Node: GNAT HTable g-htable ads823154
! Ref: gnat_rm/the_gnat_library gnat-htable-g-htable-ads823295
! Ref: 36f823295
! Ref: gnat_rm/the_gnat_library id78823295
! Ref: 370823295
! Node: GNAT IO g-io ads823570
! Ref: gnat_rm/the_gnat_library gnat-io-g-io-ads823706
! Ref: 371823706
! Ref: gnat_rm/the_gnat_library id79823706
! Ref: 372823706
! Node: GNAT IO_Aux g-io_aux ads824015
! Ref: gnat_rm/the_gnat_library gnat-io-aux-g-io-aux-ads824155
! Ref: 373824155
! Ref: gnat_rm/the_gnat_library id80824155
! Ref: 374824155
! Node: GNAT Lock_Files g-locfil ads824381
! Ref: gnat_rm/the_gnat_library gnat-lock-files-g-locfil-ads824543
! Ref: 375824543
! Ref: gnat_rm/the_gnat_library id81824543
! Ref: 376824543
! Node: GNAT MBBS_Discrete_Random g-mbdira ads824748
! Ref: gnat_rm/the_gnat_library gnat-mbbs-discrete-random-g-mbdira-ads824921
! Ref: 377824921
! Ref: gnat_rm/the_gnat_library id82824921
! Ref: 378824921
! Node: GNAT MBBS_Float_Random g-mbflra ads825158
! Ref: gnat_rm/the_gnat_library gnat-mbbs-float-random-g-mbflra-ads825321
! Ref: 379825321
! Ref: gnat_rm/the_gnat_library id83825321
! Ref: 37a825321
! Node: GNAT MD5 g-md5 ads825549
! Ref: gnat_rm/the_gnat_library gnat-md5-g-md5-ads825703
! Ref: 37b825703
! Ref: gnat_rm/the_gnat_library id84825703
! Ref: 37c825703
! Node: GNAT Memory_Dump g-memdum ads825937
! Ref: gnat_rm/the_gnat_library gnat-memory-dump-g-memdum-ads826095
! Ref: 37d826095
! Ref: gnat_rm/the_gnat_library id85826095
! Ref: 37e826095
! Node: GNAT Most_Recent_Exception g-moreex ads826330
! Ref: gnat_rm/the_gnat_library gnat-most-recent-exception-g-moreex-ads826494
! Ref: 37f826494
! Ref: gnat_rm/the_gnat_library id86826494
! Ref: 380826494
! Node: GNAT OS_Lib g-os_lib ads826794
! Ref: gnat_rm/the_gnat_library gnat-os-lib-g-os-lib-ads826970
! Ref: 381826970
! Ref: gnat_rm/the_gnat_library id87826970
! Ref: 382826970
! Node: GNAT Perfect_Hash_Generators g-pehage ads827301
! Ref: gnat_rm/the_gnat_library gnat-perfect-hash-generators-g-pehage-ads827470
! Ref: 383827470
! Ref: gnat_rm/the_gnat_library id88827470
! Ref: 384827470
! Node: GNAT Random_Numbers g-rannum ads828122
! Ref: gnat_rm/the_gnat_library gnat-random-numbers-g-rannum-ads828291
! Ref: 385828291
! Ref: gnat_rm/the_gnat_library id89828291
! Ref: 386828291
! Node: GNAT Regexp g-regexp ads828516
! Ref: gnat_rm/the_gnat_library gnat-regexp-g-regexp-ads828670
! Ref: 25c828670
! Ref: gnat_rm/the_gnat_library id90828670
! Ref: 387828670
! Node: GNAT Registry g-regist ads829026
! Ref: gnat_rm/the_gnat_library gnat-registry-g-regist-ads829172
! Ref: 388829172
! Ref: gnat_rm/the_gnat_library id91829172
! Ref: 389829172
! Node: GNAT Regpat g-regpat ads829526
! Ref: gnat_rm/the_gnat_library gnat-regpat-g-regpat-ads829678
! Ref: 38a829678
! Ref: gnat_rm/the_gnat_library id92829678
! Ref: 38b829678
! Node: GNAT Rewrite_Data g-rewdat ads829967
! Ref: gnat_rm/the_gnat_library gnat-rewrite-data-g-rewdat-ads830131
! Ref: 38c830131
! Ref: gnat_rm/the_gnat_library id93830131
! Ref: 38d830131
! Node: GNAT Secondary_Stack_Info g-sestin ads830495
! Ref: gnat_rm/the_gnat_library gnat-secondary-stack-info-g-sestin-ads830663
! Ref: 38e830663
! Ref: gnat_rm/the_gnat_library id94830663
! Ref: 38f830663
! Node: GNAT Semaphores g-semaph ads830869
! Ref: gnat_rm/the_gnat_library gnat-semaphores-g-semaph-ads831046
! Ref: 390831046
! Ref: gnat_rm/the_gnat_library id95831046
! Ref: 391831046
! Node: GNAT Serial_Communications g-sercom ads831209
! Ref: gnat_rm/the_gnat_library gnat-serial-communications-g-sercom-ads831368
! Ref: 392831368
! Ref: gnat_rm/the_gnat_library id96831368
! Ref: 393831368
! Node: GNAT SHA1 g-sha1 ads831604
! Ref: gnat_rm/the_gnat_library gnat-sha1-g-sha1-ads831759
! Ref: 394831759
! Ref: gnat_rm/the_gnat_library id97831759
! Ref: 395831759
! Node: GNAT SHA224 g-sha224 ads832016
! Ref: gnat_rm/the_gnat_library gnat-sha224-g-sha224-ads832156
! Ref: 396832156
! Ref: gnat_rm/the_gnat_library id98832156
! Ref: 397832156
! Node: GNAT SHA256 g-sha256 ads832412
! Ref: gnat_rm/the_gnat_library gnat-sha256-g-sha256-ads832556
! Ref: 398832556
! Ref: gnat_rm/the_gnat_library id99832556
! Ref: 399832556
! Node: GNAT SHA384 g-sha384 ads832812
! Ref: gnat_rm/the_gnat_library gnat-sha384-g-sha384-ads832956
! Ref: 39a832956
! Ref: gnat_rm/the_gnat_library id100832956
! Ref: 39b832956
! Node: GNAT SHA512 g-sha512 ads833212
! Ref: gnat_rm/the_gnat_library gnat-sha512-g-sha512-ads833357
! Ref: 39c833357
! Ref: gnat_rm/the_gnat_library id101833357
! Ref: 39d833357
! Node: GNAT Signals g-signal ads833615
! Ref: gnat_rm/the_gnat_library gnat-signals-g-signal-ads833761
! Ref: 39e833761
! Ref: gnat_rm/the_gnat_library id102833761
! Ref: 39f833761
! Node: GNAT Sockets g-socket ads833936
! Ref: gnat_rm/the_gnat_library gnat-sockets-g-socket-ads834087
! Ref: 3a0834087
! Ref: gnat_rm/the_gnat_library id103834087
! Ref: 3a1834087
! Node: GNAT Source_Info g-souinf ads834483
! Ref: gnat_rm/the_gnat_library gnat-source-info-g-souinf-ads834643
! Ref: 3a2834643
! Ref: gnat_rm/the_gnat_library id104834643
! Ref: 3a3834643
! Node: GNAT Spelling_Checker g-speche ads835009
! Ref: gnat_rm/the_gnat_library gnat-spelling-checker-g-speche-ads835186
! Ref: 3a4835186
! Ref: gnat_rm/the_gnat_library id105835186
! Ref: 3a5835186
! Node: GNAT Spelling_Checker_Generic g-spchge ads835398
! Ref: gnat_rm/the_gnat_library gnat-spelling-checker-generic-g-spchge-ads835580
! Ref: 3a6835580
! Ref: gnat_rm/the_gnat_library id106835580
! Ref: 3a7835580
! Node: GNAT Spitbol Patterns g-spipat ads835860
! Ref: gnat_rm/the_gnat_library gnat-spitbol-patterns-g-spipat-ads836033
! Ref: 3a8836033
! Ref: gnat_rm/the_gnat_library id107836033
! Ref: 3a9836033
! Node: GNAT Spitbol g-spitbo ads836440
! Ref: gnat_rm/the_gnat_library gnat-spitbol-g-spitbo-ads836610
! Ref: 3aa836610
! Ref: gnat_rm/the_gnat_library id108836610
! Ref: 3ab836610
! Node: GNAT Spitbol Table_Boolean g-sptabo ads837020
! Ref: gnat_rm/the_gnat_library gnat-spitbol-table-boolean-g-sptabo-ads837195
! Ref: 3ac837195
! Ref: gnat_rm/the_gnat_library id109837195
! Ref: 3ad837195
! Node: GNAT Spitbol Table_Integer g-sptain ads837465
! Ref: gnat_rm/the_gnat_library gnat-spitbol-table-integer-g-sptain-ads837654
! Ref: 3ae837654
! Ref: gnat_rm/the_gnat_library id110837654
! Ref: 3af837654
! Node: GNAT Spitbol Table_VString g-sptavs ads837937
! Ref: gnat_rm/the_gnat_library gnat-spitbol-table-vstring-g-sptavs-ads838105
! Ref: 3b0838105
! Ref: gnat_rm/the_gnat_library id111838105
! Ref: 3b1838105
! Node: GNAT SSE g-sse ads838392
! Ref: gnat_rm/the_gnat_library gnat-sse-g-sse-ads838555
! Ref: 3b2838555
! Ref: gnat_rm/the_gnat_library id112838555
! Ref: 3b3838555
! Node: GNAT SSE Vector_Types g-ssvety ads838882
! Ref: gnat_rm/the_gnat_library gnat-sse-vector-types-g-ssvety-ads839035
! Ref: 3b4839035
! Ref: gnat_rm/the_gnat_library id113839035
! Ref: 3b5839035
! Node: GNAT String_Hash g-strhas ads839195
! Ref: gnat_rm/the_gnat_library gnat-string-hash-g-strhas-ads839355
! Ref: 3b6839355
! Ref: gnat_rm/the_gnat_library id114839355
! Ref: 3b7839355
! Node: GNAT Strings g-string ads839577
! Ref: gnat_rm/the_gnat_library gnat-strings-g-string-ads839733
! Ref: 3b8839733
! Ref: gnat_rm/the_gnat_library id115839733
! Ref: 3b9839733
! Node: GNAT String_Split g-strspl ads839948
! Ref: gnat_rm/the_gnat_library gnat-string-split-g-strspl-ads840097
! Ref: 3ba840097
! Ref: gnat_rm/the_gnat_library id116840097
! Ref: 3bb840097
! Node: GNAT Table g-table ads840416
! Ref: gnat_rm/the_gnat_library gnat-table-g-table-ads840567
! Ref: 3bc840567
! Ref: gnat_rm/the_gnat_library id117840567
! Ref: 3bd840567
! Node: GNAT Task_Lock g-tasloc ads841050
! Ref: gnat_rm/the_gnat_library gnat-task-lock-g-tasloc-ads841199
! Ref: 3be841199
! Ref: gnat_rm/the_gnat_library id118841199
! Ref: 3bf841199
! Node: GNAT Time_Stamp g-timsta ads841481
! Ref: gnat_rm/the_gnat_library gnat-time-stamp-g-timsta-ads841633
! Ref: 3c0841633
! Ref: gnat_rm/the_gnat_library id119841633
! Ref: 3c1841633
! Node: GNAT Threads g-thread ads841959
! Ref: gnat_rm/the_gnat_library gnat-threads-g-thread-ads842111
! Ref: 3c2842111
! Ref: gnat_rm/the_gnat_library id120842111
! Ref: 3c3842111
! Node: GNAT Traceback g-traceb ads842467
! Ref: gnat_rm/the_gnat_library gnat-traceback-g-traceb-ads842627
! Ref: 3c4842627
! Ref: gnat_rm/the_gnat_library id121842627
! Ref: 3c5842627
! Node: GNAT Traceback Symbolic g-trasym ads842829
! Ref: gnat_rm/the_gnat_library gnat-traceback-symbolic-g-trasym-ads842988
! Ref: 3c6842988
! Ref: gnat_rm/the_gnat_library id122842988
! Ref: 3c7842988
! Node: GNAT UTF_32 g-utf_32 ads843097
! Ref: gnat_rm/the_gnat_library gnat-utf-32-g-utf-32-ads843270
! Ref: 3c8843270
! Ref: gnat_rm/the_gnat_library id123843270
! Ref: 3c9843270
! Node: GNAT UTF_32_Spelling_Checker g-u3spch ads843834
! Ref: gnat_rm/the_gnat_library gnat-utf-32-spelling-checker-g-u3spch-ads844010
! Ref: 3ca844010
! Ref: gnat_rm/the_gnat_library id124844010
! Ref: 3cb844010
! Node: GNAT Wide_Spelling_Checker g-wispch ads844346
! Ref: gnat_rm/the_gnat_library gnat-wide-spelling-checker-g-wispch-ads844533
! Ref: 3cc844533
! Ref: gnat_rm/the_gnat_library id125844533
! Ref: 3cd844533
! Node: GNAT Wide_String_Split g-wistsp ads844765
! Ref: gnat_rm/the_gnat_library gnat-wide-string-split-g-wistsp-ads844955
! Ref: 3ce844955
! Ref: gnat_rm/the_gnat_library id126844955
! Ref: 3cf844955
! Node: GNAT Wide_Wide_Spelling_Checker g-zspche ads845294
! Ref: gnat_rm/the_gnat_library gnat-wide-wide-spelling-checker-g-zspche-ads845485
! Ref: 3d0845485
! Ref: gnat_rm/the_gnat_library id127845485
! Ref: 3d1845485
! Node: GNAT Wide_Wide_String_Split g-zistsp ads845737
! Ref: gnat_rm/the_gnat_library gnat-wide-wide-string-split-g-zistsp-ads845929
! Ref: 3d2845929
! Ref: gnat_rm/the_gnat_library id128845929
! Ref: 3d3845929
! Node: Interfaces C Extensions i-cexten ads846288
! Ref: gnat_rm/the_gnat_library id129846469
! Ref: 3d4846469
! Ref: gnat_rm/the_gnat_library interfaces-c-extensions-i-cexten-ads846469
! Ref: 3d5846469
! Node: Interfaces C Streams i-cstrea ads846725
! Ref: gnat_rm/the_gnat_library id130846904
! Ref: 3d6846904
! Ref: gnat_rm/the_gnat_library interfaces-c-streams-i-cstrea-ads846904
! Ref: 3d7846904
! Node: Interfaces Packed_Decimal i-pacdec ads847086
! Ref: gnat_rm/the_gnat_library id131847260
! Ref: 3d8847260
! Ref: gnat_rm/the_gnat_library interfaces-packed-decimal-i-pacdec-ads847260
! Ref: 3d9847260
! Node: Interfaces VxWorks i-vxwork ads847511
! Ref: gnat_rm/the_gnat_library id132847698
! Ref: 3da847698
! Ref: gnat_rm/the_gnat_library interfaces-vxworks-i-vxwork-ads847698
! Ref: 3db847698
! Node: Interfaces VxWorks Int_Connection i-vxinco ads847935
! Ref: gnat_rm/the_gnat_library id133848118
! Ref: 3dc848118
! Ref: gnat_rm/the_gnat_library interfaces-vxworks-int-connection-i-vxinco-ads848118
! Ref: 3dd848118
! Node: Interfaces VxWorks IO i-vxwoio ads848378
! Ref: gnat_rm/the_gnat_library id134848563
! Ref: 3de848563
! Ref: gnat_rm/the_gnat_library interfaces-vxworks-io-i-vxwoio-ads848563
! Ref: 3df848563
! Node: System Address_Image s-addima ads848887
! Ref: gnat_rm/the_gnat_library id135849056
! Ref: 3e0849056
! Ref: gnat_rm/the_gnat_library system-address-image-s-addima-ads849056
! Ref: 3e1849056
! Node: System Assertions s-assert ads849288
! Ref: gnat_rm/the_gnat_library id136849458
! Ref: 3e2849458
! Ref: gnat_rm/the_gnat_library system-assertions-s-assert-ads849458
! Ref: 3e3849458
! Node: System Atomic_Counters s-atocou ads849724
! Ref: gnat_rm/the_gnat_library id137849887
! Ref: 3e4849887
! Ref: gnat_rm/the_gnat_library system-atomic-counters-s-atocou-ads849887
! Ref: 3e5849887
! Node: System Memory s-memory ads850333
! Ref: gnat_rm/the_gnat_library id138850501
! Ref: 3e6850501
! Ref: gnat_rm/the_gnat_library system-memory-s-memory-ads850501
! Ref: 3e7850501
! Node: System Multiprocessors s-multip ads851109
! Ref: gnat_rm/the_gnat_library id139851297
! Ref: 3e8851297
! Ref: gnat_rm/the_gnat_library system-multiprocessors-s-multip-ads851297
! Ref: 3e9851297
! Node: System Multiprocessors Dispatching_Domains s-mudido ads851595
! Ref: gnat_rm/the_gnat_library id140851796
! Ref: 3ea851796
! Ref: gnat_rm/the_gnat_library system-multiprocessors-dispatching-domains-s-mudido-ads851796
! Ref: 3eb851796
! Node: System Partition_Interface s-parint ads852134
! Ref: gnat_rm/the_gnat_library id141852331
! Ref: 3ec852331
! Ref: gnat_rm/the_gnat_library system-partition-interface-s-parint-ads852331
! Ref: 3ed852331
! Node: System Pool_Global s-pooglo ads852592
! Ref: gnat_rm/the_gnat_library id142852764
! Ref: 3ee852764
! Ref: gnat_rm/the_gnat_library system-pool-global-s-pooglo-ads852764
! Ref: 3ef852764
! Node: System Pool_Local s-pooloc ads853106
! Ref: gnat_rm/the_gnat_library id143853271
! Ref: 3f0853271
! Ref: gnat_rm/the_gnat_library system-pool-local-s-pooloc-ads853271
! Ref: 3f1853271
! Node: System Restrictions s-restri ads853646
! Ref: gnat_rm/the_gnat_library id144853806
! Ref: 3f2853806
! Ref: gnat_rm/the_gnat_library system-restrictions-s-restri-ads853806
! Ref: 3f3853806
! Node: System Rident s-rident ads854244
! Ref: gnat_rm/the_gnat_library id145854412
! Ref: 3f4854412
! Ref: gnat_rm/the_gnat_library system-rident-s-rident-ads854412
! Ref: 3f5854412
! Node: System Strings Stream_Ops s-ststop ads854811
! Ref: gnat_rm/the_gnat_library id146854981
! Ref: 3f6854981
! Ref: gnat_rm/the_gnat_library system-strings-stream-ops-s-ststop-ads854981
! Ref: 3f7854981
! Node: System Unsigned_Types s-unstyp ads855376
! Ref: gnat_rm/the_gnat_library id147855547
! Ref: 3f8855547
! Ref: gnat_rm/the_gnat_library system-unsigned-types-s-unstyp-ads855547
! Ref: 3f9855547
! Node: System Wch_Cnv s-wchcnv ads855983
! Ref: gnat_rm/the_gnat_library id148856143
! Ref: 3fa856143
! Ref: gnat_rm/the_gnat_library system-wch-cnv-s-wchcnv-ads856143
! Ref: 3fb856143
! Node: System Wch_Con s-wchcon ads856486
! Ref: gnat_rm/the_gnat_library id149856603
! Ref: 3fc856603
! Ref: gnat_rm/the_gnat_library system-wch-con-s-wchcon-ads856603
! Ref: 3fd856603
! Node: Interfacing to Other Languages856889
! Ref: gnat_rm/interfacing_to_other_languages doc857019
! Ref: 3fe857019
! Ref: gnat_rm/interfacing_to_other_languages id1857019
! Ref: 3ff857019
! Ref: gnat_rm/interfacing_to_other_languages interfacing-to-other-languages857019
! Ref: 11857019
! Node: Interfacing to C857371
! Ref: gnat_rm/interfacing_to_other_languages id2857482
! Ref: 400857482
! Ref: gnat_rm/interfacing_to_other_languages interfacing-to-c857482
! Ref: 401857482
! Node: Interfacing to C++860285
! Ref: gnat_rm/interfacing_to_other_languages id3860425
! Ref: 47860425
! Ref: gnat_rm/interfacing_to_other_languages id4860425
! Ref: 402860425
! Node: Interfacing to COBOL862633
! Ref: gnat_rm/interfacing_to_other_languages id5862779
! Ref: 403862779
! Ref: gnat_rm/interfacing_to_other_languages interfacing-to-cobol862779
! Ref: 404862779
! Node: Interfacing to Fortran862923
! Ref: gnat_rm/interfacing_to_other_languages id6863083
! Ref: 405863083
! Ref: gnat_rm/interfacing_to_other_languages interfacing-to-fortran863083
! Ref: 406863083
! Node: Interfacing to non-GNAT Ada code863409
! Ref: gnat_rm/interfacing_to_other_languages id7863540
! Ref: 407863540
! Ref: gnat_rm/interfacing_to_other_languages interfacing-to-non-gnat-ada-code863540
! Ref: 408863540
! Node: Specialized Needs Annexes864567
! Ref: gnat_rm/specialized_needs_annexes doc864720
! Ref: 409864720
! Ref: gnat_rm/specialized_needs_annexes id1864720
! Ref: 40a864720
! Ref: gnat_rm/specialized_needs_annexes specialized-needs-annexes864720
! Ref: 12864720
! Node: Implementation of Specific Ada Features865791
! Ref: gnat_rm/implementation_of_specific_ada_features doc865949
! Ref: 40b865949
! Ref: gnat_rm/implementation_of_specific_ada_features id1865949
! Ref: 40c865949
! Ref: gnat_rm/implementation_of_specific_ada_features implementation-of-specific-ada-features865949
! Ref: 13865949
! Node: Machine Code Insertions866438
! Ref: gnat_rm/implementation_of_specific_ada_features id2866577
! Ref: 40d866577
! Ref: gnat_rm/implementation_of_specific_ada_features machine-code-insertions866577
! Ref: 166866577
! Node: GNAT Implementation of Tasking873995
! Ref: gnat_rm/implementation_of_specific_ada_features gnat-implementation-of-tasking874189
! Ref: 40e874189
! Ref: gnat_rm/implementation_of_specific_ada_features id3874189
! Ref: 40f874189
! Node: Mapping Ada Tasks onto the Underlying Kernel Threads874603
! Ref: gnat_rm/implementation_of_specific_ada_features id4874776
! Ref: 410874776
! Ref: gnat_rm/implementation_of_specific_ada_features mapping-ada-tasks-onto-the-underlying-kernel-threads874776
! Ref: 411874776
! Node: Ensuring Compliance with the Real-Time Annex876932
! Ref: gnat_rm/implementation_of_specific_ada_features ensuring-compliance-with-the-real-time-annex877142
! Ref: 412877142
! Ref: gnat_rm/implementation_of_specific_ada_features id5877142
! Ref: 413877142
! Node: Support for Locking Policies879054
! Ref: gnat_rm/implementation_of_specific_ada_features support-for-locking-policies879203
! Ref: 414879203
! Node: GNAT Implementation of Shared Passive Packages880362
! Ref: gnat_rm/implementation_of_specific_ada_features gnat-implementation-of-shared-passive-packages880569
! Ref: 415880569
! Ref: gnat_rm/implementation_of_specific_ada_features id6880569
! Ref: 416880569
! Node: Code Generation for Array Aggregates883687
! Ref: gnat_rm/implementation_of_specific_ada_features code-generation-for-array-aggregates883924
! Ref: 417883924
! Ref: gnat_rm/implementation_of_specific_ada_features id7883924
! Ref: 418883924
! Node: Static constant aggregates with static bounds885347
! Ref: gnat_rm/implementation_of_specific_ada_features id8885527
! Ref: 419885527
! Ref: gnat_rm/implementation_of_specific_ada_features static-constant-aggregates-with-static-bounds885527
! Ref: 41a885527
! Node: Constant aggregates with unconstrained nominal types886930
! Ref: gnat_rm/implementation_of_specific_ada_features constant-aggregates-with-unconstrained-nominal-types887148
! Ref: 41b887148
! Ref: gnat_rm/implementation_of_specific_ada_features id9887148
! Ref: 41c887148
! Node: Aggregates with static bounds887648
! Ref: gnat_rm/implementation_of_specific_ada_features aggregates-with-static-bounds887853
! Ref: 41d887853
! Ref: gnat_rm/implementation_of_specific_ada_features id10887853
! Ref: 41e887853
! Node: Aggregates with nonstatic bounds888487
! Ref: gnat_rm/implementation_of_specific_ada_features aggregates-with-nonstatic-bounds888675
! Ref: 41f888675
! Ref: gnat_rm/implementation_of_specific_ada_features id11888675
! Ref: 420888675
! Node: Aggregates in assignment statements889083
! Ref: gnat_rm/implementation_of_specific_ada_features aggregates-in-assignment-statements889233
! Ref: 421889233
! Ref: gnat_rm/implementation_of_specific_ada_features id12889233
! Ref: 422889233
! Node: The Size of Discriminated Records with Default Discriminants890491
! Ref: gnat_rm/implementation_of_specific_ada_features id13890714
! Ref: 423890714
! Ref: gnat_rm/implementation_of_specific_ada_features the-size-of-discriminated-records-with-default-discriminants890714
! Ref: 424890714
! Node: Image Values For Nonscalar Types893658
! Ref: gnat_rm/implementation_of_specific_ada_features id14893891
! Ref: 425893891
! Ref: gnat_rm/implementation_of_specific_ada_features image-values-for-nonscalar-types893891
! Ref: 426893891
! Node: Strict Conformance to the Ada Reference Manual894954
! Ref: gnat_rm/implementation_of_specific_ada_features id15895118
! Ref: 427895118
! Ref: gnat_rm/implementation_of_specific_ada_features strict-conformance-to-the-ada-reference-manual895118
! Ref: 428895118
! Node: Implementation of Ada 2012 Features896549
! Ref: gnat_rm/implementation_of_ada_2012_features doc896709
! Ref: 429896709
! Ref: gnat_rm/implementation_of_ada_2012_features id1896709
! Ref: 42a896709
! Ref: gnat_rm/implementation_of_ada_2012_features implementation-of-ada-2012-features896709
! Ref: 14896709
! Node: Security Hardening Features945155
! Ref: gnat_rm/security_hardening_features doc945296
! Ref: 42b945296
! Ref: gnat_rm/security_hardening_features id1945296
! Ref: 42c945296
! Ref: gnat_rm/security_hardening_features security-hardening-features945296
! Ref: 15945296
! Node: Register Scrubbing945662
! Ref: gnat_rm/security_hardening_features register-scrubbing945769
! Ref: 42d945769
! Node: Stack Scrubbing946678
! Ref: gnat_rm/security_hardening_features stack-scrubbing946815
! Ref: 42e946815
! Node: Hardened Conditionals951796
! Ref: gnat_rm/security_hardening_features hardened-conditionals951932
! Ref: 42f951932
! Node: Hardened Booleans954534
! Ref: gnat_rm/security_hardening_features hardened-booleans954678
! Ref: 430954678
! Node: Control Flow Redundancy956556
! Ref: gnat_rm/security_hardening_features control-flow-redundancy956670
! Ref: 431956670
! Node: Obsolescent Features962354
! Ref: gnat_rm/obsolescent_features doc962491
! Ref: 432962491
! Ref: gnat_rm/obsolescent_features id1962491
! Ref: 433962491
! Ref: gnat_rm/obsolescent_features obsolescent-features962491
! Ref: 16962491
! Node: pragma No_Run_Time962955
! Ref: gnat_rm/obsolescent_features id2963056
! Ref: 434963056
! Ref: gnat_rm/obsolescent_features pragma-no-run-time963056
! Ref: 435963056
! Node: pragma Ravenscar963588
! Ref: gnat_rm/obsolescent_features id3963724
! Ref: 436963724
! Ref: gnat_rm/obsolescent_features pragma-ravenscar963724
! Ref: 437963724
! Node: pragma Restricted_Run_Time963940
! Ref: gnat_rm/obsolescent_features id4964074
! Ref: 438964074
! Ref: gnat_rm/obsolescent_features pragma-restricted-run-time964074
! Ref: 439964074
! Node: pragma Task_Info964378
! Ref: gnat_rm/obsolescent_features id5964533
! Ref: 43a964533
! Ref: gnat_rm/obsolescent_features pragma-task-info964533
! Ref: 43b964533
! Node: package System Task_Info s-tasinf ads965398
! Ref: gnat_rm/obsolescent_features package-system-task-info965518
! Ref: 43c965518
! Ref: gnat_rm/obsolescent_features package-system-task-info-s-tasinf-ads965518
! Ref: 43d965518
! Node: Compatibility and Porting Guide965884
! Ref: gnat_rm/compatibility_and_porting_guide doc966024
! Ref: 43e966024
! Ref: gnat_rm/compatibility_and_porting_guide compatibility-and-porting-guide966024
! Ref: 17966024
! Ref: gnat_rm/compatibility_and_porting_guide id1966024
! Ref: 43f966024
! Node: Writing Portable Fixed-Point Declarations966663
! Ref: gnat_rm/compatibility_and_porting_guide id2966807
! Ref: 440966807
! Ref: gnat_rm/compatibility_and_porting_guide writing-portable-fixed-point-declarations966807
! Ref: 441966807
! Node: Compatibility with Ada 83970705
! Ref: gnat_rm/compatibility_and_porting_guide compatibility-with-ada-83970899
! Ref: 442970899
! Ref: gnat_rm/compatibility_and_porting_guide id3970899
! Ref: 443970899
! Node: Legal Ada 83 programs that are illegal in Ada 95971773
! Ref: gnat_rm/compatibility_and_porting_guide id4971921
! Ref: 444971921
! Ref: gnat_rm/compatibility_and_porting_guide legal-ada-83-programs-that-are-illegal-in-ada-95971921
! Ref: 445971921
! Node: More deterministic semantics976479
! Ref: gnat_rm/compatibility_and_porting_guide id5976653
! Ref: 446976653
! Ref: gnat_rm/compatibility_and_porting_guide more-deterministic-semantics976653
! Ref: 447976653
! Node: Changed semantics977581
! Ref: gnat_rm/compatibility_and_porting_guide changed-semantics977742
! Ref: 448977742
! Ref: gnat_rm/compatibility_and_porting_guide id6977742
! Ref: 449977742
! Node: Other language compatibility issues979317
! Ref: gnat_rm/compatibility_and_porting_guide id7979441
! Ref: 44a979441
! Ref: gnat_rm/compatibility_and_porting_guide other-language-compatibility-issues979441
! Ref: 44b979441
! Node: Compatibility between Ada 95 and Ada 2005980734
! Ref: gnat_rm/compatibility_and_porting_guide compatibility-between-ada-95-and-ada-2005980927
! Ref: 44c980927
! Ref: gnat_rm/compatibility_and_porting_guide id8980927
! Ref: 44d980927
! Node: Implementation-dependent characteristics983356
! Ref: gnat_rm/compatibility_and_porting_guide id9983560
! Ref: 44e983560
! Ref: gnat_rm/compatibility_and_porting_guide implementation-dependent-characteristics983560
! Ref: 44f983560
! Node: Implementation-defined pragmas984347
! Ref: gnat_rm/compatibility_and_porting_guide id10984497
! Ref: 450984497
! Ref: gnat_rm/compatibility_and_porting_guide implementation-defined-pragmas984497
! Ref: 451984497
! Node: Implementation-defined attributes985481
! Ref: gnat_rm/compatibility_and_porting_guide id11985649
! Ref: 452985649
! Ref: gnat_rm/compatibility_and_porting_guide implementation-defined-attributes985649
! Ref: 453985649
! Node: Libraries986201
! Ref: gnat_rm/compatibility_and_porting_guide id12986356
! Ref: 454986356
! Ref: gnat_rm/compatibility_and_porting_guide libraries986356
! Ref: 455986356
! Node: Elaboration order987260
! Ref: gnat_rm/compatibility_and_porting_guide elaboration-order987405
! Ref: 456987405
! Ref: gnat_rm/compatibility_and_porting_guide id13987405
! Ref: 457987405
! Node: Target-specific aspects988857
! Ref: gnat_rm/compatibility_and_porting_guide id14988984
! Ref: 458988984
! Ref: gnat_rm/compatibility_and_porting_guide target-specific-aspects988984
! Ref: 459988984
! Node: Compatibility with Other Ada Systems989747
! Ref: gnat_rm/compatibility_and_porting_guide compatibility-with-other-ada-systems989932
! Ref: 45b989932
! Ref: gnat_rm/compatibility_and_porting_guide id15989932
! Ref: 45c989932
! Node: Representation Clauses991476
! Ref: gnat_rm/compatibility_and_porting_guide id16991649
! Ref: 45d991649
! Ref: gnat_rm/compatibility_and_porting_guide representation-clauses991649
! Ref: 45a991649
! Node: Compatibility with HP Ada 83996288
! Ref: gnat_rm/compatibility_and_porting_guide compatibility-with-hp-ada-83996416
! Ref: 45e996416
! Ref: gnat_rm/compatibility_and_porting_guide id17996416
! Ref: 45f996416
! Node: GNU Free Documentation License997294
! Ref: share/gnu_free_documentation_license doc997419
! Ref: 460997419
! Ref: share/gnu_free_documentation_license gnu-fdl997419
! Ref: 1997419
! Ref: share/gnu_free_documentation_license gnu-free-documentation-license997419
! Ref: 461997419
! Node: Index1020761
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/doc/gnat_ugn.info gcc-13.5.0-RC-20260904/gcc/doc/gnat_ugn.info
*** gcc-13.4.0/gcc/doc/gnat_ugn.info	Thu Jun  5 16:30:23 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gnat_ugn.info	Fri Sep  4 07:57:46 2026
***************
*** 1,7 ****
! This is gnat_ugn.info, produced by makeinfo version 6.8 from
  gnat_ugn.texi.
  
!      GNAT User’s Guide for Native Platforms , Jan 03, 2023
  
       AdaCore
  
--- 1,7 ----
! This is gnat_ugn.info, produced by makeinfo version 7.1 from
  gnat_ugn.texi.
  
!      GNAT User's Guide for Native Platforms , Jan 03, 2023
  
       AdaCore
  
*************** END-INFO-DIR-ENTRY
*** 18,35 ****
  
  File: gnat_ugn.info,  Node: Top,  Next: About This Guide,  Up: (dir)
  
! GNAT User’s Guide for Native Platforms
  **************************************
  
!      GNAT User’s Guide for Native Platforms , Jan 03, 2023
  
       AdaCore
  
       Copyright © 2008-2023, Free Software Foundation
  
! ‘GNAT, The GNU Ada Development Environment’
  
! GCC version 13.4.0
  AdaCore
  
  Permission is granted to copy, distribute and/or modify this document
--- 18,35 ----
  
  File: gnat_ugn.info,  Node: Top,  Next: About This Guide,  Up: (dir)
  
! GNAT User's Guide for Native Platforms
  **************************************
  
!      GNAT User's Guide for Native Platforms , Jan 03, 2023
  
       AdaCore
  
       Copyright © 2008-2023, Free Software Foundation
  
! 'GNAT, The GNU Ada Development Environment'
  
! GCC version 13.4.1
  AdaCore
  
  Permission is granted to copy, distribute and/or modify this document
*************** License: 1.
*** 55,61 ****
  * GNU Free Documentation License::
  * Index::
  
!  — The Detailed Node Listing —
  
  About This Guide
  
--- 55,61 ----
  * GNU Free Documentation License::
  * Index::
  
!  -- The Detailed Node Listing --
  
  About This Guide
  
*************** in this guide:
*** 636,642 ****
  
     * ‘Variables’
  
!    * ‘Emphasis’
  
     * [optional information or parameters]
  
--- 636,642 ----
  
     * ‘Variables’
  
!    * 'Emphasis'
  
     * [optional information or parameters]
  
*************** main program, and the spec and body of a
*** 836,850 ****
  Following the one-unit-per-file rule, place this program in the
  following three separate files:
  
! ‘greetings.ads’
  
       spec of package ‘Greetings’
  
! ‘greetings.adb’
  
       body of package ‘Greetings’
  
! ‘gmain.adb’
  
       body of main program
  
--- 836,850 ----
  Following the one-unit-per-file rule, place this program in the
  following three separate files:
  
! 'greetings.ads'
  
       spec of package ‘Greetings’
  
! 'greetings.adb'
  
       body of package ‘Greetings’
  
! 'gmain.adb'
  
       body of main program
  
*************** is used to represent the end of file.
*** 964,971 ****
  
  Each file contains a single Ada compilation unit, including any pragmas
  associated with the unit.  For example, this means you must place a
! package declaration (a package ‘spec’) and the corresponding body in
! separate files.  An Ada ‘compilation’ (which is a sequence of
  compilation units) is represented using a sequence of files.  Similarly,
  you will place each subunit or child unit in a separate file.
  
--- 964,971 ----
  
  Each file contains a single Ada compilation unit, including any pragmas
  associated with the unit.  For example, this means you must place a
! package declaration (a package 'spec') and the corresponding body in
! separate files.  An Ada 'compilation' (which is a sequence of
  compilation units) is represented using a sequence of files.  Similarly,
  you will place each subunit or child unit in a separate file.
  
*************** File: gnat_ugn.info,  Node: Other 8-Bit
*** 1013,1044 ****
  
  GNAT also supports several other 8-bit coding schemes:
  
! ‘ISO 8859-2 (Latin-2)’
  
       Latin-2 letters allowed in identifiers, with uppercase and
       lowercase equivalence.
  
! ‘ISO 8859-3 (Latin-3)’
  
       Latin-3 letters allowed in identifiers, with uppercase and
       lowercase equivalence.
  
! ‘ISO 8859-4 (Latin-4)’
  
       Latin-4 letters allowed in identifiers, with uppercase and
       lowercase equivalence.
  
! ‘ISO 8859-5 (Cyrillic)’
  
       ISO 8859-5 letters (Cyrillic) allowed in identifiers, with
       uppercase and lowercase equivalence.
  
! ‘ISO 8859-15 (Latin-9)’
  
       ISO 8859-15 (Latin-9) letters allowed in identifiers, with
       uppercase and lowercase equivalence
  
! ‘IBM PC (code page 437)’
  
       This code page is the normal default for PCs in the U.S. It
       corresponds to the original IBM PC character set.  This set has
--- 1013,1044 ----
  
  GNAT also supports several other 8-bit coding schemes:
  
! 'ISO 8859-2 (Latin-2)'
  
       Latin-2 letters allowed in identifiers, with uppercase and
       lowercase equivalence.
  
! 'ISO 8859-3 (Latin-3)'
  
       Latin-3 letters allowed in identifiers, with uppercase and
       lowercase equivalence.
  
! 'ISO 8859-4 (Latin-4)'
  
       Latin-4 letters allowed in identifiers, with uppercase and
       lowercase equivalence.
  
! 'ISO 8859-5 (Cyrillic)'
  
       ISO 8859-5 letters (Cyrillic) allowed in identifiers, with
       uppercase and lowercase equivalence.
  
! 'ISO 8859-15 (Latin-9)'
  
       ISO 8859-15 (Latin-9) letters allowed in identifiers, with
       uppercase and lowercase equivalence
  
! 'IBM PC (code page 437)'
  
       This code page is the normal default for PCs in the U.S. It
       corresponds to the original IBM PC character set.  This set has
*************** GNAT also supports several other 8-bit c
*** 1047,1060 ****
       these letters are allowed in identifiers with uppercase and
       lowercase equivalence.
  
! ‘IBM PC (code page 850)’
  
       This code page is a modification of 437 extended to include all the
       Latin-1 letters, but still not with the usual Latin-1 encoding.  In
       this mode, all these letters are allowed in identifiers with
       uppercase and lowercase equivalence.
  
! ‘Full Upper 8-bit’
  
       Any character in the range 80-FF allowed in identifiers, and all
       are considered distinct.  In other words, there are no uppercase
--- 1047,1060 ----
       these letters are allowed in identifiers with uppercase and
       lowercase equivalence.
  
! 'IBM PC (code page 850)'
  
       This code page is a modification of 437 extended to include all the
       Latin-1 letters, but still not with the usual Latin-1 encoding.  In
       this mode, all these letters are allowed in identifiers with
       uppercase and lowercase equivalence.
  
! 'Full Upper 8-bit'
  
       Any character in the range 80-FF allowed in identifiers, and all
       are considered distinct.  In other words, there are no uppercase
*************** GNAT also supports several other 8-bit c
*** 1063,1069 ****
       character sets (e.g., the typical method of representing Chinese
       characters on the PC).
  
! ‘No Upper-Half’
  
       No upper-half characters in the range 80-FF are allowed in
       identifiers.  This gives Ada 83 compatibility for identifier names.
--- 1063,1069 ----
       character sets (e.g., the typical method of representing Chinese
       characters on the PC).
  
! 'No Upper-Half'
  
       No upper-half characters in the range 80-FF are allowed in
       identifiers.  This gives Ada 83 compatibility for identifier names.
*************** GNAT allows wide character codes to appe
*** 1083,1089 ****
  literals, and also optionally in identifiers, by means of the following
  possible encoding schemes:
  
! ‘Hex Coding’
  
       In this encoding, a wide character is represented by the following
       five character sequence:
--- 1083,1089 ----
  literals, and also optionally in identifiers, by means of the following
  possible encoding schemes:
  
! 'Hex Coding'
  
       In this encoding, a wide character is represented by the following
       five character sequence:
*************** possible encoding schemes:
*** 1095,1101 ****
       A345 is used to represent the wide character with code ‘16#A345#’.
       This scheme is compatible with use of the full Wide_Character set.
  
! ‘Upper-Half Coding’
  
       The wide character with encoding ‘16#abcd#’ where the upper bit is
       on (in other words, ‘a’ is in the range 8-F) is represented as two
--- 1095,1101 ----
       A345 is used to represent the wide character with code ‘16#A345#’.
       This scheme is compatible with use of the full Wide_Character set.
  
! 'Upper-Half Coding'
  
       The wide character with encoding ‘16#abcd#’ where the upper bit is
       on (in other words, ‘a’ is in the range 8-F) is represented as two
*************** possible encoding schemes:
*** 1104,1110 ****
       This method can be also used for shift-JIS or EUC, where the
       internal coding matches the external coding.
  
! ‘Shift JIS Coding’
  
       A wide character is represented by a two-character sequence,
       ‘16#ab#’ and ‘16#cd#’, with the restrictions described for
--- 1104,1110 ----
       This method can be also used for shift-JIS or EUC, where the
       internal coding matches the external coding.
  
! 'Shift JIS Coding'
  
       A wide character is represented by a two-character sequence,
       ‘16#ab#’ and ‘16#cd#’, with the restrictions described for
*************** possible encoding schemes:
*** 1113,1119 ****
       algorithm for Shift-JIS conversion.  Only characters defined in the
       JIS code set table can be used with this encoding method.
  
! ‘EUC Coding’
  
       A wide character is represented by a two-character sequence
       ‘16#ab#’ and ‘16#cd#’, with both characters being in the upper
--- 1113,1119 ----
       algorithm for Shift-JIS conversion.  Only characters defined in the
       JIS code set table can be used with this encoding method.
  
! 'EUC Coding'
  
       A wide character is represented by a two-character sequence
       ‘16#ab#’ and ‘16#cd#’, with both characters being in the upper
*************** possible encoding schemes:
*** 1122,1128 ****
       defined in the JIS code set table can be used with this encoding
       method.
  
! ‘UTF-8 Coding’
  
       A wide character is represented using UCS Transformation Format 8
       (UTF-8) as defined in Annex R of ISO 10646-1/Am.2.  Depending on
--- 1122,1128 ----
       defined in the JIS code set table can be used with this encoding
       method.
  
! 'UTF-8 Coding'
  
       A wide character is represented using UCS Transformation Format 8
       (UTF-8) as defined in Annex R of ISO 10646-1/Am.2.  Depending on
*************** possible encoding schemes:
*** 1141,1147 ****
       6-byte sequences, and in the following section on wide wide
       characters, the use of these sequences is documented).
  
! ‘Brackets Coding’
  
       In this encoding, a wide character is represented by the following
       eight character sequence:
--- 1141,1147 ----
       6-byte sequences, and in the following section on wide wide
       characters, the use of these sequences is documented).
  
! 'Brackets Coding'
  
       In this encoding, a wide character is represented by the following
       eight character sequence:
*************** GNAT allows wide wide character codes to
*** 1174,1180 ****
  literals, and also optionally in identifiers, by means of the following
  possible encoding schemes:
  
! ‘UTF-8 Coding’
  
       A wide character is represented using UCS Transformation Format 8
       (UTF-8) as defined in Annex R of ISO 10646-1/Am.2.  Depending on
--- 1174,1180 ----
  literals, and also optionally in identifiers, by means of the following
  possible encoding schemes:
  
! 'UTF-8 Coding'
  
       A wide character is represented using UCS Transformation Format 8
       (UTF-8) as defined in Annex R of ISO 10646-1/Am.2.  Depending on
*************** possible encoding schemes:
*** 1192,1198 ****
       where the ‘xxx’ bits correspond to the left-padded bits of the
       32-bit character value.
  
! ‘Brackets Coding’
  
       In this encoding, a wide wide character is represented by the
       following ten or twelve byte character sequence:
--- 1192,1198 ----
       where the ‘xxx’ bits correspond to the left-padded bits of the
       32-bit character value.
  
! 'Brackets Coding'
  
       In this encoding, a wide wide character is represented by the
       following ten or twelve byte character sequence:
*************** File: gnat_ugn.info,  Node: Switches for
*** 2077,2083 ****
  ‘-gnat`xxx'’
  
       This passes the given ‘-gnat`xxx'’ switch to ‘gnat’ which is used
!      to parse the given file.  Not all ‘xxx’ options make sense, but for
       example, the use of ‘-gnati2’ allows ‘gnatchop’ to process a source
       file that uses Latin-2 coding for identifiers.
  
--- 2077,2083 ----
  ‘-gnat`xxx'’
  
       This passes the given ‘-gnat`xxx'’ switch to ‘gnat’ which is used
!      to parse the given file.  Not all 'xxx' options make sense, but for
       example, the use of ‘-gnati2’ allows ‘gnatchop’ to process a source
       file that uses Latin-2 coding for identifiers.
  
*************** of restriction.
*** 2301,2307 ****
  
  Restrictions that require partition-wide consistency (like ‘No_Tasking’)
  are recognized wherever they appear and can be freely inherited, e.g.
! from a ‘with’ed unit to the ‘with’ing unit.  This makes sense since the
  binder will in any case insist on seeing consistent use, so any unit not
  conforming to any restrictions that are anywhere in the partition will
  be rejected, and you might as well find that out at compile time rather
--- 2301,2307 ----
  
  Restrictions that require partition-wide consistency (like ‘No_Tasking’)
  are recognized wherever they appear and can be freely inherited, e.g.
! from a 'with'ed unit to the 'with'ing unit.  This makes sense since the
  binder will in any case insist on seeing consistent use, so any unit not
  conforming to any restrictions that are anywhere in the partition will
  be rejected, and you might as well find that out at compile time rather
*************** if changes to the source file require th
*** 2433,2442 ****
  In addition to this basic dependency, a given object may depend on
  additional source files as follows:
  
!    * If a file being compiled ‘with’s a unit ‘X’, the object file
       depends on the file containing the spec of unit ‘X’.  This includes
!      files that are ‘with’ed implicitly either because they are parents
!      of ‘with’ed child units or they are run-time units required by the
       language constructs used in a particular unit.
  
     * If a file being compiled instantiates a library level generic unit,
--- 2433,2442 ----
  In addition to this basic dependency, a given object may depend on
  additional source files as follows:
  
!    * If a file being compiled 'with's a unit ‘X’, the object file
       depends on the file containing the spec of unit ‘X’.  This includes
!      files that are 'with'ed implicitly either because they are parents
!      of 'with'ed child units or they are run-time units required by the
       language constructs used in a particular unit.
  
     * If a file being compiled instantiates a library level generic unit,
*************** additional source files as follows:
*** 2476,2482 ****
       dependencies and recompilation, a body and all its subunits are
       treated as an indivisible whole.
  
!      These rules are applied transitively: if unit ‘A’ ‘with’s unit ‘B’,
       whose elaboration calls an inlined procedure in package ‘C’, the
       object file for unit ‘A’ will depend on the body of ‘C’, in file
       ‘c.adb’.
--- 2476,2482 ----
       dependencies and recompilation, a body and all its subunits are
       treated as an indivisible whole.
  
!      These rules are applied transitively: if unit ‘A’ 'with's unit ‘B’,
       whose elaboration calls an inlined procedure in package ‘C’, the
       object file for unit ‘A’ will depend on the body of ‘C’, in file
       ‘c.adb’.
*************** contained in the ‘ALI’ file.
*** 2526,2532 ****
  
     * Categorization information (e.g., use of pragma ‘Pure’).
  
!    * Information on all ‘with’ed units, including presence of
       ‘Elaborate’ or ‘Elaborate_All’ pragmas.
  
     * Information from any ‘Linker_Options’ pragmas used in the unit
--- 2526,2532 ----
  
     * Categorization information (e.g., use of pragma ‘Pure’).
  
!    * Information on all 'with'ed units, including presence of
       ‘Elaborate’ or ‘Elaborate_All’ pragmas.
  
     * Information from any ‘Linker_Options’ pragmas used in the unit
*************** If no errors are detected, the binder pr
*** 2575,2582 ****
  default, that contains calls to the elaboration procedures of those
  compilation unit that require them, followed by a call to the main
  program.  This Ada program is compiled to generate the object file for
! the main program.  The name of the Ada file is ‘b~xxx’.adb‘ (with the
! corresponding spec ‘b~xxx’.ads‘) where ‘xxx’ is the name of the main
  program unit.
  
  Finally, the linker is used to build the resulting executable program,
--- 2575,2582 ----
  default, that contains calls to the elaboration procedures of those
  compilation unit that require them, followed by a call to the main
  program.  This Ada program is compiled to generate the object file for
! the main program.  The name of the Ada file is ‘b~xxx’.adb' (with the
! corresponding spec ‘b~xxx’.ads') where ‘xxx’ is the name of the main
  program unit.
  
  Finally, the linker is used to build the resulting executable program,
*************** File: gnat_ugn.info,  Node: GNAT and Lib
*** 2592,2598 ****
  This section describes how to build and use libraries with GNAT, and
  also shows how to recompile the GNAT run-time library.  You should be
  familiar with the Project Manager facility (see the
! ‘GNAT_Project_Manager’ chapter of the ‘GPRbuild User’s Guide’) before
  reading this chapter.
  
  * Menu:
--- 2592,2598 ----
  This section describes how to build and use libraries with GNAT, and
  also shows how to recompile the GNAT run-time library.  You should be
  familiar with the Project Manager facility (see the
! 'GNAT_Project_Manager' chapter of the 'GPRbuild User’s Guide') before
  reading this chapter.
  
  * Menu:
*************** documentation purposes.  Alternatively,
*** 2636,2650 ****
  needed by an external user to make use of the library.  That is to say,
  the specs reflecting the library services along with all the units
  needed to compile those specs, which can include generic bodies or any
! body implementing an inlined routine.  In the case of ‘stand-alone
! libraries’ those exposed units are called ‘interface units’ (*note
  Stand-alone Ada Libraries: 6b.).
  
  All compilation units comprising an application, including those in a
  library, need to be elaborated in an order partially defined by Ada’s
  semantics.  GNAT computes the elaboration order from the ‘ALI’ files and
  this is why they constitute a mandatory part of GNAT libraries.
! ‘Stand-alone libraries’ are the exception to this rule because a
  specific library elaboration routine is produced independently of the
  application(s) using the library.
  
--- 2636,2650 ----
  needed by an external user to make use of the library.  That is to say,
  the specs reflecting the library services along with all the units
  needed to compile those specs, which can include generic bodies or any
! body implementing an inlined routine.  In the case of 'stand-alone
! libraries' those exposed units are called 'interface units' (*note
  Stand-alone Ada Libraries: 6b.).
  
  All compilation units comprising an application, including those in a
  library, need to be elaborated in an order partially defined by Ada’s
  semantics.  GNAT computes the elaboration order from the ‘ALI’ files and
  this is why they constitute a mandatory part of GNAT libraries.
! 'Stand-alone libraries' are the exception to this rule because a
  specific library elaboration routine is produced independently of the
  application(s) using the library.
  
*************** File: gnat_ugn.info,  Node: Building a l
*** 2667,2675 ****
  ..........................
  
  The easiest way to build a library is to use the Project Manager, which
! supports a special type of project called a ‘Library Project’ (see the
! ‘Library Projects’ section in the ‘GNAT Project Manager’ chapter of the
! ‘GPRbuild User’s Guide’).
  
  A project is considered a library project, when two project-level
  attributes are defined in it: ‘Library_Name’ and ‘Library_Dir’.  In
--- 2667,2675 ----
  ..........................
  
  The easiest way to build a library is to use the Project Manager, which
! supports a special type of project called a 'Library Project' (see the
! 'Library Projects' section in the 'GNAT Project Manager' chapter of the
! 'GPRbuild User’s Guide').
  
  A project is considered a library project, when two project-level
  attributes are defined in it: ‘Library_Name’ and ‘Library_Dir’.  In
*************** File: gnat_ugn.info,  Node: Installing a
*** 2781,2788 ****
  ............................
  
  If you use project files, library installation is part of the library
! build process (see the ‘Installing a Library with Project Files’ section
! of the ‘GNAT Project Manager’ chapter of the ‘GPRbuild User’s Guide’).
  
  When project files are not an option, it is also possible, but not
  recommended, to install the library so that the sources needed to use
--- 2781,2788 ----
  ............................
  
  If you use project files, library installation is part of the library
! build process (see the 'Installing a Library with Project Files' section
! of the 'GNAT Project Manager' chapter of the 'GPRbuild User’s Guide').
  
  When project files are not an option, it is also possible, but not
  recommended, to install the library so that the sources needed to use
*************** File: gnat_ugn.info,  Node: Using a libr
*** 2832,2838 ****
  
  Once again, the project facility greatly simplifies the use of
  libraries.  In this context, using a library is just a matter of adding
! a ‘with’ clause in the user project.  For instance, to make use of the
  library ‘My_Lib’ shown in examples in earlier sections, you can write:
  
       with "my_lib";
--- 2832,2838 ----
  
  Once again, the project facility greatly simplifies the use of
  libraries.  In this context, using a library is just a matter of adding
! a 'with' clause in the user project.  For instance, to make use of the
  library ‘My_Lib’ shown in examples in earlier sections, you can write:
  
       with "my_lib";
*************** library ‘My_Lib’ shown in examples i
*** 2842,2848 ****
  
  Even if you have a third-party, non-Ada library, you can still use
  GNAT’s Project Manager facility to provide a wrapper for it.  For
! example, the following project, when ‘with’ed by your main project, will
  link with the third-party library ‘liba.a’:
  
       project Liba is
--- 2842,2848 ----
  
  Even if you have a third-party, non-Ada library, you can still use
  GNAT’s Project Manager facility to provide a wrapper for it.  For
! example, the following project, when 'with'ed by your main project, will
  link with the third-party library ‘liba.a’:
  
       project Liba is
*************** File: gnat_ugn.info,  Node: Building a S
*** 2948,2959 ****
  ......................................
  
  GNAT’s Project facility provides a simple way of building and installing
! stand-alone libraries; see the ‘Stand-alone Library Projects’ section in
! the ‘GNAT Project Manager’ chapter of the ‘GPRbuild User’s Guide’.  To
  be a Stand-alone Library Project, in addition to the two attributes that
  make a project a Library Project (‘Library_Name’ and ‘Library_Dir’; see
! the ‘Library Projects’ section in the ‘GNAT Project Manager’ chapter of
! the ‘GPRbuild User’s Guide’), the attribute ‘Library_Interface’ must be
  defined.  For example:
  
       for Library_Dir use "lib_dir";
--- 2948,2959 ----
  ......................................
  
  GNAT’s Project facility provides a simple way of building and installing
! stand-alone libraries; see the 'Stand-alone Library Projects' section in
! the 'GNAT Project Manager' chapter of the 'GPRbuild User’s Guide'.  To
  be a Stand-alone Library Project, in addition to the two attributes that
  make a project a Library Project (‘Library_Name’ and ‘Library_Dir’; see
! the 'Library Projects' section in the 'GNAT Project Manager' chapter of
! the 'GPRbuild User’s Guide'), the attribute ‘Library_Interface’ must be
  defined.  For example:
  
       for Library_Dir use "lib_dir";
*************** like:
*** 3273,3279 ****
  
  The ‘Config’ package exists in multiple forms for the various targets,
  with an appropriate script selecting the version of ‘Config’ needed.
! Then any other unit requiring conditional compilation can do a ‘with’ of
  ‘Config’ to make the constants visible.
  
  
--- 3273,3279 ----
  
  The ‘Config’ package exists in multiple forms for the various targets,
  with an appropriate script selecting the version of ‘Config’ needed.
! Then any other unit requiring conditional compilation can do a 'with' of
  ‘Config’ to make the constants visible.
  
  
*************** File: gnat_ugn.info,  Node: Preprocessin
*** 3596,3602 ****
  3.10.2.1 Preprocessing Symbols
  ..............................
  
! Preprocessing symbols are defined in ‘definition files’ and referenced
  in the sources to be preprocessed.  A preprocessing symbol is an
  identifier, following normal Ada (case-insensitive) rules for its
  syntax, with the restriction that all characters need to be in the ASCII
--- 3596,3602 ----
  3.10.2.1 Preprocessing Symbols
  ..............................
  
! Preprocessing symbols are defined in 'definition files' and referenced
  in the sources to be preprocessed.  A preprocessing symbol is an
  identifier, following normal Ada (case-insensitive) rules for its
  syntax, with the restriction that all characters need to be in the ASCII
*************** To call ‘gnatprep’ use:
*** 3615,3633 ****
  where
  
     * 
!      ‘switches’
  
            is an optional sequence of switches as described in the next
            section.
  
     * 
!      ‘infile’
  
            is the full name of the input file, which is an Ada source
            file containing preprocessor directives.
  
     * 
!      ‘outfile’
  
            is the full name of the output file, which is an Ada source in
            standard Ada form.  When used with GNAT, this file name will
--- 3615,3633 ----
  where
  
     * 
!      'switches'
  
            is an optional sequence of switches as described in the next
            section.
  
     * 
!      'infile'
  
            is the full name of the input file, which is an Ada source
            file containing preprocessor directives.
  
     * 
!      'outfile'
  
            is the full name of the output file, which is an Ada source in
            standard Ada form.  When used with GNAT, this file name will
*************** As noted above, a file to be preprocesse
*** 3878,3888 ****
  which preprocessing lines have been inserted.  However, instead of using
  ‘gnatprep’ to explicitly preprocess a file as a separate step before
  compilation, you can carry out the preprocessing implicitly as part of
! compilation.  Such ‘integrated preprocessing’, which is the common style
  with C, is performed when either or both of the following switches are
  passed to the compiler:
  
!         * ‘-gnatep’, which specifies the ‘preprocessor data file’.  This
            file dictates how the source files will be preprocessed (e.g.,
            which symbol definition files apply to which sources).
  
--- 3878,3888 ----
  which preprocessing lines have been inserted.  However, instead of using
  ‘gnatprep’ to explicitly preprocess a file as a separate step before
  compilation, you can carry out the preprocessing implicitly as part of
! compilation.  Such 'integrated preprocessing', which is the common style
  with C, is performed when either or both of the following switches are
  passed to the compiler:
  
!         * ‘-gnatep’, which specifies the 'preprocessor data file'.  This
            file dictates how the source files will be preprocessed (e.g.,
            which symbol definition files apply to which sources).
  
*************** When using project files:
*** 3901,3907 ****
  
          * the builder switch ‘-x’ should be used if any Ada source is
            compiled with ‘gnatep=’, so that the compiler finds the
!           ‘preprocessor data file’.
  
          * the preprocessing data file and the symbol definition files
            should be located in the source directories of the project.
--- 3901,3907 ----
  
          * the builder switch ‘-x’ should be used if any Ada source is
            compiled with ‘gnatep=’, so that the compiler finds the
!           'preprocessor data file'.
  
          * the preprocessing data file and the symbol definition files
            should be located in the source directories of the project.
*************** that relate to integrated preprocessing.
*** 3929,3940 ****
                    end Compiler;
                 end Prj;
  
!      A preprocessor data file is a text file that contains ‘preprocessor
!      control lines’.  A preprocessor control line directs the
       preprocessing of either a particular source file, or, analogous to
       ‘others’ in Ada, all sources not specified elsewhere in the
       preprocessor data file.  A preprocessor control line can optionally
!      identify a ‘definition file’ that assigns values to preprocessor
       symbols, as well as a list of switches that relate to
       preprocessing.  Empty lines and comments (using Ada syntax) are
       also permitted, with no semantic effect.
--- 3929,3940 ----
                    end Compiler;
                 end Prj;
  
!      A preprocessor data file is a text file that contains 'preprocessor
!      control lines'.  A preprocessor control line directs the
       preprocessing of either a particular source file, or, analogous to
       ‘others’ in Ada, all sources not specified elsewhere in the
       preprocessor data file.  A preprocessor control line can optionally
!      identify a 'definition file' that assigns values to preprocessor
       symbols, as well as a list of switches that relate to
       preprocessing.  Empty lines and comments (using Ada syntax) are
       also permitted, with no semantic effect.
*************** considered:
*** 4512,4518 ****
            $ gnatmake ada_unit -largs file1.o file2.o --LINK=g++
  
     * Using GNAT and G++ from two different GCC installations: If both
!      compilers are on the :envvar‘PATH‘, the previous method may be
       used.  It is important to note that environment variables such as
       ‘C_INCLUDE_PATH’, ‘GCC_EXEC_PREFIX’, ‘BINUTILS_ROOT’, and
       ‘GCC_ROOT’ will affect both compilers at the same time and may make
--- 4512,4518 ----
            $ gnatmake ada_unit -largs file1.o file2.o --LINK=g++
  
     * Using GNAT and G++ from two different GCC installations: If both
!      compilers are on the :envvar'PATH', the previous method may be
       used.  It is important to note that environment variables such as
       ‘C_INCLUDE_PATH’, ‘GCC_EXEC_PREFIX’, ‘BINUTILS_ROOT’, and
       ‘GCC_ROOT’ will affect both compilers at the same time and may make
*************** File: gnat_ugn.info,  Node: Generating B
*** 5203,5209 ****
  ............................................
  
  Generating bindings for C++ headers is done using the same options,
! always with the ‘g++’ compiler.  Note that generating Ada spec from C++
  headers is a much more complex job and support for C++ headers is much
  more limited that support for C headers.  As a result, you will need to
  modify the resulting bindings by hand more extensively when using C++
--- 5203,5209 ----
  ............................................
  
  Generating bindings for C++ headers is done using the same options,
! always with the 'g++' compiler.  Note that generating Ada spec from C++
  headers is a much more complex job and support for C++ headers is much
  more limited that support for C headers.  As a result, you will need to
  modify the resulting bindings by hand more extensively when using C++
*************** headers.
*** 5212,5218 ****
  In this mode, C++ classes will be mapped to Ada tagged types,
  constructors will be mapped using the ‘CPP_Constructor’ pragma, and when
  possible, multiple inheritance of abstract classes will be mapped to Ada
! interfaces (see the ‘Interfacing to C++’ section in the ‘GNAT Reference
  Manual’ for additional information on interfacing to C++).
  
  For example, given the following C++ header file:
--- 5212,5218 ----
  In this mode, C++ classes will be mapped to Ada tagged types,
  constructors will be mapped using the ‘CPP_Constructor’ pragma, and when
  possible, multiple inheritance of abstract classes will be mapped to Ada
! interfaces (see the 'Interfacing to C++' section in the ‘GNAT Reference
  Manual’ for additional information on interfacing to C++).
  
  For example, given the following C++ header file:
*************** File: gnat_ugn.info,  Node: Comparison b
*** 5435,5441 ****
  The GNAT model of compilation is close to the C and C++ models.  You can
  think of Ada specs as corresponding to header files in C. As in C, you
  don’t need to compile specs; they are compiled when they are used.  The
! Ada ‘with’ is similar in effect to the ‘#include’ of a C header.
  
  One notable difference is that, in Ada, you may compile specs separately
  to check them for semantic and syntactic accuracy.  This is not always
--- 5435,5441 ----
  The GNAT model of compilation is close to the C and C++ models.  You can
  think of Ada specs as corresponding to header files in C. As in C, you
  don’t need to compile specs; they are compiled when they are used.  The
! Ada 'with' is similar in effect to the ‘#include’ of a C header.
  
  One notable difference is that, in Ada, you may compile specs separately
  to check them for semantic and syntactic accuracy.  This is not always
*************** source file being compiled, but also fro
*** 5477,5483 ****
  means that the effect of a compilation depends on what has been
  previously compiled.  In particular:
  
!    * When a unit is ‘with’ed, the unit seen by the compiler corresponds
       to the version of the unit most recently compiled into the library.
  
     * Inlining is effective only if the necessary body has already been
--- 5477,5483 ----
  means that the effect of a compilation depends on what has been
  previously compiled.  In particular:
  
!    * When a unit is 'with'ed, the unit seen by the compiler corresponds
       to the version of the unit most recently compiled into the library.
  
     * Inlining is effective only if the necessary body has already been
*************** In GNAT, compiling one unit never affect
*** 5489,5495 ****
  units because the compiler reads only source files.  Only changes to
  source files can affect the results of a compilation.  In particular:
  
!    * When a unit is ‘with’ed, the unit seen by the compiler corresponds
       to the source version of the unit that is currently accessible to
       the compiler.
  
--- 5489,5495 ----
  units because the compiler reads only source files.  Only changes to
  source files can affect the results of a compilation.  In particular:
  
!    * When a unit is 'with'ed, the unit seen by the compiler corresponds
       to the source version of the unit that is currently accessible to
       the compiler.
  
*************** dependencies, they will always be tracke
*** 5653,5660 ****
  ‘gnatmake’.
  
  Note that for advanced forms of project structure, we recommend creating
! a project file as explained in the ‘GNAT_Project_Manager’ chapter in the
! ‘GPRbuild User’s Guide’, and using the ‘gprbuild’ tool which supports
  building with project files and works similarly to ‘gnatmake’.
  
  * Menu:
--- 5653,5660 ----
  ‘gnatmake’.
  
  Note that for advanced forms of project structure, we recommend creating
! a project file as explained in the 'GNAT_Project_Manager' chapter in the
! 'GPRbuild User’s Guide', and using the ‘gprbuild’ tool which supports
  building with project files and works similarly to ‘gnatmake’.
  
  * Menu:
*************** You may specify any of the following swi
*** 5874,5880 ****
       (absolute or relative) by this switch, should already exist,
       otherwise the switch is ineffective.  The specified mapping file
       will be communicated to the compiler.  This switch is not
!      compatible with a project file (-P‘file‘) or with multiple
       compiling processes (-jnnn, when nnn is greater than 1).
  
  ‘-d’
--- 5874,5880 ----
       (absolute or relative) by this switch, should already exist,
       otherwise the switch is ineffective.  The specified mapping file
       will be communicated to the compiler.  This switch is not
!      compatible with a project file (-P'file') or with multiple
       compiling processes (-jnnn, when nnn is greater than 1).
  
  ‘-d’
*************** Source and library search path switches
*** 6198,6208 ****
       a valid run-time is found (‘adainclude’ or ‘ada_source_path’, and
       ‘adalib’ or ‘ada_object_path’ present):
  
!         * ‘/$rts_path’
  
!         * ‘/$rts_path’
  
!         * ‘/rts-$rts_path’
  
          * The selected path is handled like a normal RTS path.
  
--- 6198,6208 ----
       a valid run-time is found (‘adainclude’ or ‘ada_source_path’, and
       ‘adalib’ or ‘ada_object_path’ present):
  
!         * '/$rts_path'
  
!         * '/$rts_path'
  
!         * '/rts-$rts_path'
  
          * The selected path is handled like a normal RTS path.
  
*************** the ‘gnatmake’ command.
*** 6274,6281 ****
  
     * ‘gnatmake’ has been designed to make the use of Ada libraries
       particularly convenient.  Assume you have an Ada library organized
!      as follows: ‘obj-dir’ contains the objects and ALI files for of
!      your Ada compilation units, whereas ‘include-dir’ contains the
       specs of these units, but no bodies.  Then to compile a unit stored
       in ‘main.adb’, which uses this Ada library you would just type:
  
--- 6274,6281 ----
  
     * ‘gnatmake’ has been designed to make the use of Ada libraries
       particularly convenient.  Assume you have an Ada library organized
!      as follows: 'obj-dir' contains the objects and ALI files for of
!      your Ada compilation units, whereas 'include-dir' contains the
       specs of these units, but no bodies.  Then to compile a unit stored
       in ‘main.adb’, which uses this Ada library you would just type:
  
*************** useful to have some basic understanding
*** 6306,6312 ****
  in particular to understand how it uses the results of previous
  compilations without incorrectly depending on them.
  
! First a definition: an object file is considered ‘up to date’ if the
  corresponding ALI file exists and if all the source files listed in the
  dependency section of this ALI file have time stamps matching those in
  the ALI file.  This means that neither the source file itself nor any
--- 6306,6312 ----
  in particular to understand how it uses the results of previous
  compilations without incorrectly depending on them.
  
! First a definition: an object file is considered 'up to date' if the
  corresponding ALI file exists and if all the source files listed in the
  dependency section of this ALI file have time stamps matching those in
  the ALI file.  This means that neither the source file itself nor any
*************** File: gnat_ugn.info,  Node: Examples of
*** 6348,6360 ****
  4.1.6 Examples of ‘gnatmake’ Usage
  ----------------------------------
  
! ‘gnatmake hello.adb’
  
       Compile all files necessary to bind and link the main program
       ‘hello.adb’ (containing unit ‘Hello’) and bind and link the
       resulting object files to generate an executable file ‘hello’.
  
! ‘gnatmake main1 main2 main3’
  
       Compile all files necessary to bind and link the main programs
       ‘main1.adb’ (containing unit ‘Main1’), ‘main2.adb’ (containing unit
--- 6348,6360 ----
  4.1.6 Examples of ‘gnatmake’ Usage
  ----------------------------------
  
! 'gnatmake hello.adb'
  
       Compile all files necessary to bind and link the main program
       ‘hello.adb’ (containing unit ‘Hello’) and bind and link the
       resulting object files to generate an executable file ‘hello’.
  
! 'gnatmake main1 main2 main3'
  
       Compile all files necessary to bind and link the main programs
       ‘main1.adb’ (containing unit ‘Main1’), ‘main2.adb’ (containing unit
*************** File: gnat_ugn.info,  Node: Examples of
*** 6362,6368 ****
       link the resulting object files to generate three executable files
       ‘main1’, ‘main2’ and ‘main3’.
  
! ‘gnatmake -q Main_Unit -cargs -O2 -bargs -l’
  
       Compile all files necessary to bind and link the main program unit
       ‘Main_Unit’ (from file ‘main_unit.adb’).  All compilations will be
--- 6362,6368 ----
       link the resulting object files to generate three executable files
       ‘main1’, ‘main2’ and ‘main3’.
  
! 'gnatmake -q Main_Unit -cargs -O2 -bargs -l'
  
       Compile all files necessary to bind and link the main program unit
       ‘Main_Unit’ (from file ‘main_unit.adb’).  All compilations will be
*************** files:
*** 6406,6412 ****
     * the body file (‘.adb’) for a library level package or generic
       package that has a body
  
! You need ‘not’ compile the following files
  
     * the spec of a library unit which has a body
  
--- 6406,6412 ----
     * the body file (‘.adb’) for a library level package or generic
       package that has a body
  
! You need 'not' compile the following files
  
     * the spec of a library unit which has a body
  
*************** model are as follows:
*** 6576,6582 ****
       into the object file directly.
  
     * When you compile a unit, the source files for the specs of all
!      units that it ‘with’s, all its subunits, and the bodies of any
       generics it instantiates must be available (reachable by the
       search-paths mechanism described above), or you will receive a
       fatal error message.
--- 6576,6582 ----
       into the object file directly.
  
     * When you compile a unit, the source files for the specs of all
!      units that it 'with's, all its subunits, and the bodies of any
       generics it instantiates must be available (reachable by the
       search-paths mechanism described above), or you will receive a
       fatal error message.
*************** File: gnat_ugn.info,  Node: Alphabetical
*** 7355,7367 ****
       Digit     Interpretation
                 
                 
!      ‘1’       All intermediate overflows checked against base type (‘STRICT’)
                 
                 
!      ‘2’       Minimize intermediate overflows (‘MINIMIZED’)
                 
                 
!      ‘3’       Eliminate intermediate overflows (‘ELIMINATED’)
                 
  
       If only one digit appears, then it applies to all cases; if two
--- 7355,7367 ----
       Digit     Interpretation
                 
                 
!      '1'       All intermediate overflows checked against base type (‘STRICT’)
                 
                 
!      '2'       Minimize intermediate overflows (‘MINIMIZED’)
                 
                 
!      '3'       Eliminate intermediate overflows (‘ELIMINATED’)
                 
  
       If only one digit appears, then it applies to all cases; if two
*************** File: gnat_ugn.info,  Node: Alphabetical
*** 7511,7535 ****
  
       ‘n’ controls the optimization level:
  
!      ‘n’         Effect
                   
                   
!      ‘0’         No optimization, the default setting if no ‘-O’ appears
                   
                   
!      ‘1’         Normal optimization, the default if you specify ‘-O’ without an operand.
                   A good compromise between code quality and compilation time.
                   
                   
!      ‘2’         Extensive optimization, may improve execution time, possibly at the cost
                   of substantially increased compilation time.
                   
                   
!      ‘3’         Same as ‘-O2’, and also includes inline expansion for small subprograms in
                   the same unit.
                   
                   
!      ‘s’         Optimize space usage
                   
  
       See also *note Optimization Levels: ed.
--- 7511,7535 ----
  
       ‘n’ controls the optimization level:
  
!      'n'         Effect
                   
                   
!      '0'         No optimization, the default setting if no ‘-O’ appears
                   
                   
!      '1'         Normal optimization, the default if you specify ‘-O’ without an operand.
                   A good compromise between code quality and compilation time.
                   
                   
!      '2'         Extensive optimization, may improve execution time, possibly at the cost
                   of substantially increased compilation time.
                   
                   
!      '3'         Same as ‘-O2’, and also includes inline expansion for small subprograms in
                   the same unit.
                   
                   
!      's'         Optimize space usage
                   
  
       See also *note Optimization Levels: ed.
*************** warnings that are generated.
*** 7913,7919 ****
  
     * Violations of style rules if style checking is enabled
  
!    * Unused ‘with’ clauses
  
     * ‘Bit_Order’ usage that does not have any effect
  
--- 7913,7919 ----
  
     * Violations of style rules if style checking is enabled
  
!    * Unused 'with' clauses
  
     * ‘Bit_Order’ usage that does not have any effect
  
*************** warnings that are generated.
*** 7923,7929 ****
  
     * Declaration that is likely to cause storage error
  
!    * Internal GNAT unit ‘with’ed by application unit
  
     * Values known to be out of range at compile time
  
--- 7923,7929 ----
  
     * Declaration that is likely to cause storage error
  
!    * Internal GNAT unit 'with'ed by application unit
  
     * Values known to be out of range at compile time
  
*************** using the GNAT pragma Warnings (see the
*** 7960,7966 ****
  
  ‘-gnatwa’
  
!      ‘Activate most optional warnings.’
  
       This switch activates most optional warning messages.  See the
       remaining list in this section for details on optional warning
--- 7960,7966 ----
  
  ‘-gnatwa’
  
!      'Activate most optional warnings.'
  
       This switch activates most optional warning messages.  See the
       remaining list in this section for details on optional warning
*************** using the GNAT pragma Warnings (see the
*** 8009,8015 ****
  
  ‘-gnatwA’
  
!      ‘Suppress all optional errors.’
  
       This switch suppresses all optional warning messages, see remaining
       list in this section for details on optional warning messages that
--- 8009,8015 ----
  
  ‘-gnatwA’
  
!      'Suppress all optional errors.'
  
       This switch suppresses all optional warning messages, see remaining
       list in this section for details on optional warning messages that
*************** using the GNAT pragma Warnings (see the
*** 8025,8031 ****
  
  ‘-gnatw.a’
  
!      ‘Activate warnings on failing assertions.’
  
       This switch activates warnings for assertions where the compiler
       can tell at compile time that the assertion will fail.  Note that
--- 8025,8031 ----
  
  ‘-gnatw.a’
  
!      'Activate warnings on failing assertions.'
  
       This switch activates warnings for assertions where the compiler
       can tell at compile time that the assertion will fail.  Note that
*************** using the GNAT pragma Warnings (see the
*** 8034,8047 ****
  
  ‘-gnatw.A’
  
!      ‘Suppress warnings on failing assertions.’
  
       This switch suppresses warnings for assertions where the compiler
       can tell at compile time that the assertion will fail.
  
  ‘-gnatw_a’
  
!      ‘Activate warnings on anonymous allocators.’
  
       This switch activates warnings for allocators of anonymous access
       types, which can involve run-time accessibility checks and lead to
--- 8034,8047 ----
  
  ‘-gnatw.A’
  
!      'Suppress warnings on failing assertions.'
  
       This switch suppresses warnings for assertions where the compiler
       can tell at compile time that the assertion will fail.
  
  ‘-gnatw_a’
  
!      'Activate warnings on anonymous allocators.'
  
       This switch activates warnings for allocators of anonymous access
       types, which can involve run-time accessibility checks and lead to
*************** using the GNAT pragma Warnings (see the
*** 8050,8063 ****
  
  ‘-gnatw_A’
  
!      ‘Supress warnings on anonymous allocators.’
  
       This switch suppresses warnings for anonymous access type
       allocators.
  
  ‘-gnatwb’
  
!      ‘Activate warnings on bad fixed values.’
  
       This switch activates warnings for static fixed-point expressions
       whose value is not an exact multiple of Small.  Such values are
--- 8050,8063 ----
  
  ‘-gnatw_A’
  
!      'Supress warnings on anonymous allocators.'
  
       This switch suppresses warnings for anonymous access type
       allocators.
  
  ‘-gnatwb’
  
!      'Activate warnings on bad fixed values.'
  
       This switch activates warnings for static fixed-point expressions
       whose value is not an exact multiple of Small.  Such values are
*************** using the GNAT pragma Warnings (see the
*** 8070,8083 ****
  
  ‘-gnatwB’
  
!      ‘Suppress warnings on bad fixed values.’
  
       This switch suppresses warnings for static fixed-point expressions
       whose value is not an exact multiple of Small.
  
  ‘-gnatw.b’
  
!      ‘Activate warnings on biased representation.’
  
       This switch activates warnings when a size clause, value size
       clause, component clause, or component size clause forces the use
--- 8070,8083 ----
  
  ‘-gnatwB’
  
!      'Suppress warnings on bad fixed values.'
  
       This switch suppresses warnings for static fixed-point expressions
       whose value is not an exact multiple of Small.
  
  ‘-gnatw.b’
  
!      'Activate warnings on biased representation.'
  
       This switch activates warnings when a size clause, value size
       clause, component clause, or component size clause forces the use
*************** using the GNAT pragma Warnings (see the
*** 8087,8100 ****
  
  ‘-gnatw.B’
  
!      ‘Suppress warnings on biased representation.’
  
       This switch suppresses warnings for representation clauses that
       force the use of biased representation.
  
  ‘-gnatwc’
  
!      ‘Activate warnings on conditionals.’
  
       This switch activates warnings for conditional expressions used in
       tests that are known to be True or False at compile time.  The
--- 8087,8100 ----
  
  ‘-gnatw.B’
  
!      'Suppress warnings on biased representation.'
  
       This switch suppresses warnings for representation clauses that
       force the use of biased representation.
  
  ‘-gnatwc’
  
!      'Activate warnings on conditionals.'
  
       This switch activates warnings for conditional expressions used in
       tests that are known to be True or False at compile time.  The
*************** using the GNAT pragma Warnings (see the
*** 8121,8134 ****
  
  ‘-gnatwC’
  
!      ‘Suppress warnings on conditionals.’
  
       This switch suppresses warnings for conditional expressions used in
       tests that are known to be True or False at compile time.
  
  ‘-gnatw.c’
  
!      ‘Activate warnings on missing component clauses.’
  
       This switch activates warnings for record components where a record
       representation clause is present and has component clauses for the
--- 8121,8134 ----
  
  ‘-gnatwC’
  
!      'Suppress warnings on conditionals.'
  
       This switch suppresses warnings for conditional expressions used in
       tests that are known to be True or False at compile time.
  
  ‘-gnatw.c’
  
!      'Activate warnings on missing component clauses.'
  
       This switch activates warnings for record components where a record
       representation clause is present and has component clauses for the
*************** using the GNAT pragma Warnings (see the
*** 8137,8150 ****
  
  ‘-gnatw.C’
  
!      ‘Suppress warnings on missing component clauses.’
  
       This switch suppresses warnings for record components that are
       missing a component clause in the situation described above.
  
  ‘-gnatw_c’
  
!      ‘Activate warnings on unknown condition in Compile_Time_Warning.’
  
       This switch activates warnings on a pragma Compile_Time_Warning or
       Compile_Time_Error whose condition has a value that is not known at
--- 8137,8150 ----
  
  ‘-gnatw.C’
  
!      'Suppress warnings on missing component clauses.'
  
       This switch suppresses warnings for record components that are
       missing a component clause in the situation described above.
  
  ‘-gnatw_c’
  
!      'Activate warnings on unknown condition in Compile_Time_Warning.'
  
       This switch activates warnings on a pragma Compile_Time_Warning or
       Compile_Time_Error whose condition has a value that is not known at
*************** using the GNAT pragma Warnings (see the
*** 8152,8158 ****
  
  ‘-gnatw_C’
  
!      ‘Suppress warnings on unknown condition in Compile_Time_Warning.’
  
       This switch supresses warnings on a pragma Compile_Time_Warning or
       Compile_Time_Error whose condition has a value that is not known at
--- 8152,8158 ----
  
  ‘-gnatw_C’
  
!      'Suppress warnings on unknown condition in Compile_Time_Warning.'
  
       This switch supresses warnings on a pragma Compile_Time_Warning or
       Compile_Time_Error whose condition has a value that is not known at
*************** using the GNAT pragma Warnings (see the
*** 8160,8166 ****
  
  ‘-gnatwd’
  
!      ‘Activate warnings on implicit dereferencing.’
  
       If this switch is set, then the use of a prefix of an access type
       in an indexed component, slice, or selected component without an
--- 8160,8166 ----
  
  ‘-gnatwd’
  
!      'Activate warnings on implicit dereferencing.'
  
       If this switch is set, then the use of a prefix of an access type
       in an indexed component, slice, or selected component without an
*************** using the GNAT pragma Warnings (see the
*** 8172,8216 ****
  
  ‘-gnatwD’
  
!      ‘Suppress warnings on implicit dereferencing.’
  
       This switch suppresses warnings for implicit dereferences in
       indexed components, slices, and selected components.
  
  ‘-gnatw.d’
  
!      ‘Activate tagging of warning and info messages.’
  
       If this switch is set, then warning messages are tagged, with one
       of the following strings:
  
!              - ‘[-gnatw?]’ Used to tag warnings controlled by the switch
!                ‘-gnatwx’ where x is a letter a-z.
  
!              - ‘[-gnatw.?]’ Used to tag warnings controlled by the
                 switch ‘-gnatw.x’ where x is a letter a-z.
  
!              - ‘[-gnatel]’ Used to tag elaboration information (info)
                 messages generated when the static model of elaboration
                 is used and the ‘-gnatel’ switch is set.
  
!              - ‘[restriction warning]’ Used to tag warning messages for
                 restriction violations, activated by use of the pragma
                 ‘Restriction_Warnings’.
  
!              - ‘[warning-as-error]’ Used to tag warning messages that
                 have been converted to error messages by use of the
                 pragma Warning_As_Error.  Note that such warnings are
                 prefixed by the string “error: ” rather than “warning: “.
  
!              - ‘[enabled by default]’ Used to tag all other warnings
                 that are always given by default, unless warnings are
!                completely suppressed using pragma ‘Warnings(Off)’ or the
                 switch ‘-gnatws’.
  
  ‘-gnatw.D’
  
!      ‘Deactivate tagging of warning and info messages messages.’
  
       If this switch is set, then warning messages return to the default
       mode in which warnings and info messages are not tagged as
--- 8172,8216 ----
  
  ‘-gnatwD’
  
!      'Suppress warnings on implicit dereferencing.'
  
       This switch suppresses warnings for implicit dereferences in
       indexed components, slices, and selected components.
  
  ‘-gnatw.d’
  
!      'Activate tagging of warning and info messages.'
  
       If this switch is set, then warning messages are tagged, with one
       of the following strings:
  
!              - '[-gnatw?]'  Used to tag warnings controlled by the
!                switch ‘-gnatwx’ where x is a letter a-z.
  
!              - '[-gnatw.?]'  Used to tag warnings controlled by the
                 switch ‘-gnatw.x’ where x is a letter a-z.
  
!              - '[-gnatel]' Used to tag elaboration information (info)
                 messages generated when the static model of elaboration
                 is used and the ‘-gnatel’ switch is set.
  
!              - '[restriction warning]' Used to tag warning messages for
                 restriction violations, activated by use of the pragma
                 ‘Restriction_Warnings’.
  
!              - '[warning-as-error]' Used to tag warning messages that
                 have been converted to error messages by use of the
                 pragma Warning_As_Error.  Note that such warnings are
                 prefixed by the string “error: ” rather than “warning: “.
  
!              - '[enabled by default]' Used to tag all other warnings
                 that are always given by default, unless warnings are
!                completely suppressed using pragma 'Warnings(Off)' or the
                 switch ‘-gnatws’.
  
  ‘-gnatw.D’
  
!      'Deactivate tagging of warning and info messages messages.'
  
       If this switch is set, then warning messages return to the default
       mode in which warnings and info messages are not tagged as
*************** using the GNAT pragma Warnings (see the
*** 8218,8224 ****
  
  ‘-gnatwe’
  
!      ‘Treat warnings and style checks as errors.’
  
       This switch causes warning messages and style check messages to be
       treated as errors.  The warning string still appears, but the
--- 8218,8224 ----
  
  ‘-gnatwe’
  
!      'Treat warnings and style checks as errors.'
  
       This switch causes warning messages and style check messages to be
       treated as errors.  The warning string still appears, but the
*************** using the GNAT pragma Warnings (see the
*** 8230,8236 ****
  
  ‘-gnatw.e’
  
!      ‘Activate every optional warning.’
  
       This switch activates all optional warnings, including those which
       are not activated by ‘-gnatwa’.  The use of this switch is not
--- 8230,8236 ----
  
  ‘-gnatw.e’
  
!      'Activate every optional warning.'
  
       This switch activates all optional warnings, including those which
       are not activated by ‘-gnatwa’.  The use of this switch is not
*************** using the GNAT pragma Warnings (see the
*** 8243,8256 ****
  
  ‘-gnatwE’
  
!      ‘Treat all run-time exception warnings as errors.’
  
       This switch causes warning messages regarding errors that will be
       raised during run-time execution to be treated as errors.
  
  ‘-gnatwf’
  
!      ‘Activate warnings on unreferenced formals.’
  
       This switch causes a warning to be generated if a formal parameter
       is not referenced in the body of the subprogram.  This warning can
--- 8243,8256 ----
  
  ‘-gnatwE’
  
!      'Treat all run-time exception warnings as errors.'
  
       This switch causes warning messages regarding errors that will be
       raised during run-time execution to be treated as errors.
  
  ‘-gnatwf’
  
!      'Activate warnings on unreferenced formals.'
  
       This switch causes a warning to be generated if a formal parameter
       is not referenced in the body of the subprogram.  This warning can
*************** using the GNAT pragma Warnings (see the
*** 8259,8265 ****
  
  ‘-gnatwF’
  
!      ‘Suppress warnings on unreferenced formals.’
  
       This switch suppresses warnings for unreferenced formal parameters.
       Note that the combination ‘-gnatwu’ followed by ‘-gnatwF’ has the
--- 8259,8265 ----
  
  ‘-gnatwF’
  
!      'Suppress warnings on unreferenced formals.'
  
       This switch suppresses warnings for unreferenced formal parameters.
       Note that the combination ‘-gnatwu’ followed by ‘-gnatwF’ has the
*************** using the GNAT pragma Warnings (see the
*** 8268,8274 ****
  
  ‘-gnatwg’
  
!      ‘Activate warnings on unrecognized pragmas.’
  
       This switch causes a warning to be generated if an unrecognized
       pragma is encountered.  Apart from issuing this warning, the pragma
--- 8268,8274 ----
  
  ‘-gnatwg’
  
!      'Activate warnings on unrecognized pragmas.'
  
       This switch causes a warning to be generated if an unrecognized
       pragma is encountered.  Apart from issuing this warning, the pragma
*************** using the GNAT pragma Warnings (see the
*** 8278,8290 ****
  
  ‘-gnatwG’
  
!      ‘Suppress warnings on unrecognized pragmas.’
  
       This switch suppresses warnings for unrecognized pragmas.
  
  ‘-gnatw.g’
  
!      ‘Warnings used for GNAT sources.’
  
       This switch sets the warning categories that are used by the
       standard GNAT style.  Currently this is equivalent to
--- 8278,8290 ----
  
  ‘-gnatwG’
  
!      'Suppress warnings on unrecognized pragmas.'
  
       This switch suppresses warnings for unrecognized pragmas.
  
  ‘-gnatw.g’
  
!      'Warnings used for GNAT sources.'
  
       This switch sets the warning categories that are used by the
       standard GNAT style.  Currently this is equivalent to
*************** using the GNAT pragma Warnings (see the
*** 8293,8299 ****
  
  ‘-gnatwh’
  
!      ‘Activate warnings on hiding.’
  
       This switch activates warnings on hiding declarations that are
       considered potentially confusing.  Not all cases of hiding cause
--- 8293,8299 ----
  
  ‘-gnatwh’
  
!      'Activate warnings on hiding.'
  
       This switch activates warnings on hiding declarations that are
       considered potentially confusing.  Not all cases of hiding cause
*************** using the GNAT pragma Warnings (see the
*** 8303,8315 ****
  
  ‘-gnatwH’
  
!      ‘Suppress warnings on hiding.’
  
       This switch suppresses warnings on hiding declarations.
  
  ‘-gnatw.h’
  
!      ‘Activate warnings on holes/gaps in records.’
  
       This switch activates warnings on component clauses in record
       representation clauses that leave holes (gaps) in the record
--- 8303,8315 ----
  
  ‘-gnatwH’
  
!      'Suppress warnings on hiding.'
  
       This switch suppresses warnings on hiding declarations.
  
  ‘-gnatw.h’
  
!      'Activate warnings on holes/gaps in records.'
  
       This switch activates warnings on component clauses in record
       representation clauses that leave holes (gaps) in the record
*************** using the GNAT pragma Warnings (see the
*** 8323,8329 ****
  
  ‘-gnatw.H’
  
!      ‘Suppress warnings on holes/gaps in records.’
  
       This switch suppresses warnings on component clauses in record
       representation clauses that leave holes (haps) in the record
--- 8323,8329 ----
  
  ‘-gnatw.H’
  
!      'Suppress warnings on holes/gaps in records.'
  
       This switch suppresses warnings on component clauses in record
       representation clauses that leave holes (haps) in the record
*************** using the GNAT pragma Warnings (see the
*** 8331,8356 ****
  
  ‘-gnatwi’
  
!      ‘Activate warnings on implementation units.’
  
!      This switch activates warnings for a ‘with’ of an internal GNAT
       implementation unit, defined as any unit from the ‘Ada’,
       ‘Interfaces’, ‘GNAT’, or ‘System’ hierarchies that is not
       documented in either the Ada Reference Manual or the GNAT
       Programmer’s Reference Manual.  Such units are intended only for
!      internal implementation purposes and should not be ‘with’ed by user
       programs.  The default is that such warnings are generated
  
  ‘-gnatwI’
  
!      ‘Disable warnings on implementation units.’
  
!      This switch disables warnings for a ‘with’ of an internal GNAT
       implementation unit.
  
  ‘-gnatw.i’
  
!      ‘Activate warnings on overlapping actuals.’
  
       This switch enables a warning on statically detectable overlapping
       actuals in a subprogram call, when one of the actuals is an in-out
--- 8331,8356 ----
  
  ‘-gnatwi’
  
!      'Activate warnings on implementation units.'
  
!      This switch activates warnings for a 'with' of an internal GNAT
       implementation unit, defined as any unit from the ‘Ada’,
       ‘Interfaces’, ‘GNAT’, or ‘System’ hierarchies that is not
       documented in either the Ada Reference Manual or the GNAT
       Programmer’s Reference Manual.  Such units are intended only for
!      internal implementation purposes and should not be 'with'ed by user
       programs.  The default is that such warnings are generated
  
  ‘-gnatwI’
  
!      'Disable warnings on implementation units.'
  
!      This switch disables warnings for a 'with' of an internal GNAT
       implementation unit.
  
  ‘-gnatw.i’
  
!      'Activate warnings on overlapping actuals.'
  
       This switch enables a warning on statically detectable overlapping
       actuals in a subprogram call, when one of the actuals is an in-out
*************** using the GNAT pragma Warnings (see the
*** 8359,8371 ****
  
  ‘-gnatw.I’
  
!      ‘Disable warnings on overlapping actuals.’
  
       This switch disables warnings on overlapping actuals in a call.
  
  ‘-gnatwj’
  
!      ‘Activate warnings on obsolescent features (Annex J).’
  
       If this warning option is activated, then warnings are generated
       for calls to subprograms marked with ‘pragma Obsolescent’ and for
--- 8359,8371 ----
  
  ‘-gnatw.I’
  
!      'Disable warnings on overlapping actuals.'
  
       This switch disables warnings on overlapping actuals in a call.
  
  ‘-gnatwj’
  
!      'Activate warnings on obsolescent features (Annex J).'
  
       If this warning option is activated, then warnings are generated
       for calls to subprograms marked with ‘pragma Obsolescent’ and for
*************** using the GNAT pragma Warnings (see the
*** 8390,8416 ****
  
  ‘-gnatwJ’
  
!      ‘Suppress warnings on obsolescent features (Annex J).’
  
       This switch disables warnings on use of obsolescent features.
  
  ‘-gnatw.j’
  
!      ‘Activate warnings on late declarations of tagged type primitives.’
  
       This switch activates warnings on visible primitives added to a
       tagged type after deriving a private extension from it.
  
  ‘-gnatw.J’
  
!      ‘Suppress warnings on late declarations of tagged type primitives.’
  
       This switch suppresses warnings on visible primitives added to a
       tagged type after deriving a private extension from it.
  
  ‘-gnatwk’
  
!      ‘Activate warnings on variables that could be constants.’
  
       This switch activates warnings for variables that are initialized
       but never modified, and then could be declared constants.  The
--- 8390,8416 ----
  
  ‘-gnatwJ’
  
!      'Suppress warnings on obsolescent features (Annex J).'
  
       This switch disables warnings on use of obsolescent features.
  
  ‘-gnatw.j’
  
!      'Activate warnings on late declarations of tagged type primitives.'
  
       This switch activates warnings on visible primitives added to a
       tagged type after deriving a private extension from it.
  
  ‘-gnatw.J’
  
!      'Suppress warnings on late declarations of tagged type primitives.'
  
       This switch suppresses warnings on visible primitives added to a
       tagged type after deriving a private extension from it.
  
  ‘-gnatwk’
  
!      'Activate warnings on variables that could be constants.'
  
       This switch activates warnings for variables that are initialized
       but never modified, and then could be declared constants.  The
*************** using the GNAT pragma Warnings (see the
*** 8418,8431 ****
  
  ‘-gnatwK’
  
!      ‘Suppress warnings on variables that could be constants.’
  
       This switch disables warnings on variables that could be declared
       constants.
  
  ‘-gnatw.k’
  
!      ‘Activate warnings on redefinition of names in standard.’
  
       This switch activates warnings for declarations that declare a name
       that is defined in package Standard.  Such declarations can be
--- 8418,8431 ----
  
  ‘-gnatwK’
  
!      'Suppress warnings on variables that could be constants.'
  
       This switch disables warnings on variables that could be declared
       constants.
  
  ‘-gnatw.k’
  
!      'Activate warnings on redefinition of names in standard.'
  
       This switch activates warnings for declarations that declare a name
       that is defined in package Standard.  Such declarations can be
*************** using the GNAT pragma Warnings (see the
*** 8436,8449 ****
  
  ‘-gnatw.K’
  
!      ‘Suppress warnings on redefinition of names in standard.’
  
       This switch disables warnings for declarations that declare a name
       that is defined in package Standard.
  
  ‘-gnatwl’
  
!      ‘Activate warnings for elaboration pragmas.’
  
       This switch activates warnings for possible elaboration problems,
       including suspicious use of ‘Elaborate’ pragmas, when using the
--- 8436,8449 ----
  
  ‘-gnatw.K’
  
!      'Suppress warnings on redefinition of names in standard.'
  
       This switch disables warnings for declarations that declare a name
       that is defined in package Standard.
  
  ‘-gnatwl’
  
!      'Activate warnings for elaboration pragmas.'
  
       This switch activates warnings for possible elaboration problems,
       including suspicious use of ‘Elaborate’ pragmas, when using the
*************** using the GNAT pragma Warnings (see the
*** 8454,8466 ****
  
  ‘-gnatwL’
  
!      ‘Suppress warnings for elaboration pragmas.’
  
       This switch suppresses warnings for possible elaboration problems.
  
  ‘-gnatw.l’
  
!      ‘List inherited aspects.’
  
       This switch causes the compiler to list inherited invariants,
       preconditions, and postconditions from Type_Invariant’Class,
--- 8454,8466 ----
  
  ‘-gnatwL’
  
!      'Suppress warnings for elaboration pragmas.'
  
       This switch suppresses warnings for possible elaboration problems.
  
  ‘-gnatw.l’
  
!      'List inherited aspects.'
  
       This switch causes the compiler to list inherited invariants,
       preconditions, and postconditions from Type_Invariant’Class,
*************** using the GNAT pragma Warnings (see the
*** 8469,8481 ****
  
  ‘-gnatw.L’
  
!      ‘Suppress listing of inherited aspects.’
  
       This switch suppresses listing of inherited aspects.
  
  ‘-gnatwm’
  
!      ‘Activate warnings on modified but unreferenced variables.’
  
       This switch activates warnings for variables that are assigned
       (using an initialization value or with one or more assignment
--- 8469,8481 ----
  
  ‘-gnatw.L’
  
!      'Suppress listing of inherited aspects.'
  
       This switch suppresses listing of inherited aspects.
  
  ‘-gnatwm’
  
!      'Activate warnings on modified but unreferenced variables.'
  
       This switch activates warnings for variables that are assigned
       (using an initialization value or with one or more assignment
*************** using the GNAT pragma Warnings (see the
*** 8486,8499 ****
  
  ‘-gnatwM’
  
!      ‘Disable warnings on modified but unreferenced variables.’
  
       This switch disables warnings for variables that are assigned or
       initialized, but never read.
  
  ‘-gnatw.m’
  
!      ‘Activate warnings on suspicious modulus values.’
  
       This switch activates warnings for modulus values that seem
       suspicious.  The cases caught are where the size is the same as the
--- 8486,8499 ----
  
  ‘-gnatwM’
  
!      'Disable warnings on modified but unreferenced variables.'
  
       This switch disables warnings for variables that are assigned or
       initialized, but never read.
  
  ‘-gnatw.m’
  
!      'Activate warnings on suspicious modulus values.'
  
       This switch activates warnings for modulus values that seem
       suspicious.  The cases caught are where the size is the same as the
*************** using the GNAT pragma Warnings (see the
*** 8508,8520 ****
  
  ‘-gnatw.M’
  
!      ‘Disable warnings on suspicious modulus values.’
  
       This switch disables warnings for suspicious modulus values.
  
  ‘-gnatwn’
  
!      ‘Set normal warnings mode.’
  
       This switch sets normal warning mode, in which enabled warnings are
       issued and treated as warnings rather than errors.  This is the
--- 8508,8520 ----
  
  ‘-gnatw.M’
  
!      'Disable warnings on suspicious modulus values.'
  
       This switch disables warnings for suspicious modulus values.
  
  ‘-gnatwn’
  
!      'Set normal warnings mode.'
  
       This switch sets normal warning mode, in which enabled warnings are
       issued and treated as warnings rather than errors.  This is the
*************** using the GNAT pragma Warnings (see the
*** 8525,8531 ****
  
  ‘-gnatw.n’
  
!      ‘Activate warnings on atomic synchronization.’
  
       This switch actives warnings when an access to an atomic variable
       requires the generation of atomic synchronization code.  These
--- 8525,8531 ----
  
  ‘-gnatw.n’
  
!      'Activate warnings on atomic synchronization.'
  
       This switch actives warnings when an access to an atomic variable
       requires the generation of atomic synchronization code.  These
*************** using the GNAT pragma Warnings (see the
*** 8533,8546 ****
  
  ‘-gnatw.N’
  
!      ‘Suppress warnings on atomic synchronization.’
  
       This switch suppresses warnings when an access to an atomic
       variable requires the generation of atomic synchronization code.
  
  ‘-gnatwo’
  
!      ‘Activate warnings on address clause overlays.’
  
       This switch activates warnings for possibly unintended
       initialization effects of defining address clauses that cause one
--- 8533,8546 ----
  
  ‘-gnatw.N’
  
!      'Suppress warnings on atomic synchronization.'
  
       This switch suppresses warnings when an access to an atomic
       variable requires the generation of atomic synchronization code.
  
  ‘-gnatwo’
  
!      'Activate warnings on address clause overlays.'
  
       This switch activates warnings for possibly unintended
       initialization effects of defining address clauses that cause one
*************** using the GNAT pragma Warnings (see the
*** 8549,8555 ****
  
  ‘-gnatwO’
  
!      ‘Suppress warnings on address clause overlays.’
  
       This switch suppresses warnings on possibly unintended
       initialization effects of defining address clauses that cause one
--- 8549,8555 ----
  
  ‘-gnatwO’
  
!      'Suppress warnings on address clause overlays.'
  
       This switch suppresses warnings on possibly unintended
       initialization effects of defining address clauses that cause one
*************** using the GNAT pragma Warnings (see the
*** 8557,8563 ****
  
  ‘-gnatw.o’
  
!      ‘Activate warnings on modified but unreferenced out parameters.’
  
       This switch activates warnings for variables that are modified by
       using them as actuals for a call to a procedure with an out mode
--- 8557,8563 ----
  
  ‘-gnatw.o’
  
!      'Activate warnings on modified but unreferenced out parameters.'
  
       This switch activates warnings for variables that are modified by
       using them as actuals for a call to a procedure with an out mode
*************** using the GNAT pragma Warnings (see the
*** 8571,8577 ****
  
  ‘-gnatw.O’
  
!      ‘Disable warnings on modified but unreferenced out parameters.’
  
       This switch suppresses warnings for variables that are modified by
       using them as actuals for a call to a procedure with an out mode
--- 8571,8577 ----
  
  ‘-gnatw.O’
  
!      'Disable warnings on modified but unreferenced out parameters.'
  
       This switch suppresses warnings for variables that are modified by
       using them as actuals for a call to a procedure with an out mode
*************** using the GNAT pragma Warnings (see the
*** 8579,8585 ****
  
  ‘-gnatwp’
  
!      ‘Activate warnings on ineffective pragma Inlines.’
  
       This switch activates warnings for failure of front end inlining
       (activated by ‘-gnatN’) to inline a particular call.  There are
--- 8579,8585 ----
  
  ‘-gnatwp’
  
!      'Activate warnings on ineffective pragma Inlines.'
  
       This switch activates warnings for failure of front end inlining
       (activated by ‘-gnatN’) to inline a particular call.  There are
*************** using the GNAT pragma Warnings (see the
*** 8591,8597 ****
  
  ‘-gnatwP’
  
!      ‘Suppress warnings on ineffective pragma Inlines.’
  
       This switch suppresses warnings on ineffective pragma Inlines.  If
       the inlining mechanism cannot inline a call, it will simply ignore
--- 8591,8597 ----
  
  ‘-gnatwP’
  
!      'Suppress warnings on ineffective pragma Inlines.'
  
       This switch suppresses warnings on ineffective pragma Inlines.  If
       the inlining mechanism cannot inline a call, it will simply ignore
*************** using the GNAT pragma Warnings (see the
*** 8599,8605 ****
  
  ‘-gnatw.p’
  
!      ‘Activate warnings on parameter ordering.’
  
       This switch activates warnings for cases of suspicious parameter
       ordering when the list of arguments are all simple identifiers that
--- 8599,8605 ----
  
  ‘-gnatw.p’
  
!      'Activate warnings on parameter ordering.'
  
       This switch activates warnings for cases of suspicious parameter
       ordering when the list of arguments are all simple identifiers that
*************** using the GNAT pragma Warnings (see the
*** 8611,8624 ****
  
  ‘-gnatw.P’
  
!      ‘Suppress warnings on parameter ordering.’
  
       This switch suppresses warnings on cases of suspicious parameter
       ordering.
  
  ‘-gnatw_p’
  
!      ‘Activate warnings for pedantic checks.’
  
       This switch activates warnings for the failure of certain pedantic
       checks.  The only case currently supported is a check that the
--- 8611,8624 ----
  
  ‘-gnatw.P’
  
!      'Suppress warnings on parameter ordering.'
  
       This switch suppresses warnings on cases of suspicious parameter
       ordering.
  
  ‘-gnatw_p’
  
!      'Activate warnings for pedantic checks.'
  
       This switch activates warnings for the failure of certain pedantic
       checks.  The only case currently supported is a check that the
*************** using the GNAT pragma Warnings (see the
*** 8629,8641 ****
  
  ‘-gnatw_P’
  
!      ‘Suppress warnings for pedantic checks.’
  
       This switch suppresses warnings on violations of pedantic checks.
  
  ‘-gnatwq’
  
!      ‘Activate warnings on questionable missing parentheses.’
  
       This switch activates warnings for cases where parentheses are not
       used and the result is potential ambiguity from a readers point of
--- 8629,8641 ----
  
  ‘-gnatw_P’
  
!      'Suppress warnings for pedantic checks.'
  
       This switch suppresses warnings on violations of pedantic checks.
  
  ‘-gnatwq’
  
!      'Activate warnings on questionable missing parentheses.'
  
       This switch activates warnings for cases where parentheses are not
       used and the result is potential ambiguity from a readers point of
*************** using the GNAT pragma Warnings (see the
*** 8649,8662 ****
  
  ‘-gnatwQ’
  
!      ‘Suppress warnings on questionable missing parentheses.’
  
       This switch suppresses warnings for cases where the association is
       not clear and the use of parentheses is preferred.
  
  ‘-gnatw.q’
  
!      ‘Activate warnings on questionable layout of record types.’
  
       This switch activates warnings for cases where the default layout
       of a record type, that is to say the layout of its components in
--- 8649,8662 ----
  
  ‘-gnatwQ’
  
!      'Suppress warnings on questionable missing parentheses.'
  
       This switch suppresses warnings for cases where the association is
       not clear and the use of parentheses is preferred.
  
  ‘-gnatw.q’
  
!      'Activate warnings on questionable layout of record types.'
  
       This switch activates warnings for cases where the default layout
       of a record type, that is to say the layout of its components in
*************** using the GNAT pragma Warnings (see the
*** 8697,8710 ****
  
  ‘-gnatw.Q’
  
!      ‘Suppress warnings on questionable layout of record types.’
  
       This switch suppresses warnings for cases where the default layout
       of a record type would very likely cause inefficiencies.
  
  ‘-gnatw_q’
  
!      ‘Activate warnings for ignored equality operators.’
  
       This switch activates warnings for a user-defined “=” function that
       does not compose (i.e.  is ignored for a predefined “=” for a
--- 8697,8710 ----
  
  ‘-gnatw.Q’
  
!      'Suppress warnings on questionable layout of record types.'
  
       This switch suppresses warnings for cases where the default layout
       of a record type would very likely cause inefficiencies.
  
  ‘-gnatw_q’
  
!      'Activate warnings for ignored equality operators.'
  
       This switch activates warnings for a user-defined “=” function that
       does not compose (i.e.  is ignored for a predefined “=” for a
*************** using the GNAT pragma Warnings (see the
*** 8718,8728 ****
  
  ‘-gnatw_Q’
  
!      ‘Suppress warnings for ignored equality operators.’
  
  ‘-gnatwr’
  
!      ‘Activate warnings on redundant constructs.’
  
       This switch activates warnings for redundant constructs.  The
       following is the current list of constructs regarded as redundant:
--- 8718,8728 ----
  
  ‘-gnatw_Q’
  
!      'Suppress warnings for ignored equality operators.'
  
  ‘-gnatwr’
  
!      'Activate warnings on redundant constructs.'
  
       This switch activates warnings for redundant constructs.  The
       following is the current list of constructs regarded as redundant:
*************** using the GNAT pragma Warnings (see the
*** 8753,8765 ****
  
  ‘-gnatwR’
  
!      ‘Suppress warnings on redundant constructs.’
  
       This switch suppresses warnings for redundant constructs.
  
  ‘-gnatw.r’
  
!      ‘Activate warnings for object renaming function.’
  
       This switch activates warnings for an object renaming that renames
       a function call, which is equivalent to a constant declaration (as
--- 8753,8765 ----
  
  ‘-gnatwR’
  
!      'Suppress warnings on redundant constructs.'
  
       This switch suppresses warnings for redundant constructs.
  
  ‘-gnatw.r’
  
!      'Activate warnings for object renaming function.'
  
       This switch activates warnings for an object renaming that renames
       a function call, which is equivalent to a constant declaration (as
*************** using the GNAT pragma Warnings (see the
*** 8768,8780 ****
  
  ‘-gnatw.R’
  
!      ‘Suppress warnings for object renaming function.’
  
       This switch suppresses warnings for object renaming function.
  
  ‘-gnatw_r’
  
!      ‘Activate warnings for out-of-order record representation clauses.’
  
       This switch activates warnings for record representation clauses,
       if the order of component declarations, component clauses, and
--- 8768,8780 ----
  
  ‘-gnatw.R’
  
!      'Suppress warnings for object renaming function.'
  
       This switch suppresses warnings for object renaming function.
  
  ‘-gnatw_r’
  
!      'Activate warnings for out-of-order record representation clauses.'
  
       This switch activates warnings for record representation clauses,
       if the order of component declarations, component clauses, and
*************** using the GNAT pragma Warnings (see the
*** 8783,8793 ****
  
  ‘-gnatw_R’
  
!      ‘Suppress warnings for out-of-order record representation clauses.’
  
  ‘-gnatws’
  
!      ‘Suppress all warnings.’
  
       This switch completely suppresses the output of all warning
       messages from the GNAT front end, including both warnings that can
--- 8783,8793 ----
  
  ‘-gnatw_R’
  
!      'Suppress warnings for out-of-order record representation clauses.'
  
  ‘-gnatws’
  
!      'Suppress all warnings.'
  
       This switch completely suppresses the output of all warning
       messages from the GNAT front end, including both warnings that can
*************** using the GNAT pragma Warnings (see the
*** 8803,8809 ****
  
  ‘-gnatw.s’
  
!      ‘Activate warnings on overridden size clauses.’
  
       This switch activates warnings on component clauses in record
       representation clauses where the length given overrides that
--- 8803,8809 ----
  
  ‘-gnatw.s’
  
!      'Activate warnings on overridden size clauses.'
  
       This switch activates warnings on component clauses in record
       representation clauses where the length given overrides that
*************** using the GNAT pragma Warnings (see the
*** 8814,8820 ****
  
  ‘-gnatw.S’
  
!      ‘Suppress warnings on overridden size clauses.’
  
       This switch suppresses warnings on component clauses in record
       representation clauses that override size clauses, and similar
--- 8814,8820 ----
  
  ‘-gnatw.S’
  
!      'Suppress warnings on overridden size clauses.'
  
       This switch suppresses warnings on component clauses in record
       representation clauses that override size clauses, and similar
*************** using the GNAT pragma Warnings (see the
*** 8822,8828 ****
  
  ‘-gnatwt’
  
!      ‘Activate warnings for tracking of deleted conditional code.’
  
       This switch activates warnings for tracking of code in conditionals
       (IF and CASE statements) that is detected to be dead code which
--- 8822,8828 ----
  
  ‘-gnatwt’
  
!      'Activate warnings for tracking of deleted conditional code.'
  
       This switch activates warnings for tracking of code in conditionals
       (IF and CASE statements) that is detected to be dead code which
*************** using the GNAT pragma Warnings (see the
*** 8832,8845 ****
  
  ‘-gnatwT’
  
!      ‘Suppress warnings for tracking of deleted conditional code.’
  
       This switch suppresses warnings for tracking of deleted conditional
       code.
  
  ‘-gnatw.t’
  
!      ‘Activate warnings on suspicious contracts.’
  
       This switch activates warnings on suspicious contracts.  This
       includes warnings on suspicious postconditions (whether a pragma
--- 8832,8845 ----
  
  ‘-gnatwT’
  
!      'Suppress warnings for tracking of deleted conditional code.'
  
       This switch suppresses warnings for tracking of deleted conditional
       code.
  
  ‘-gnatw.t’
  
!      'Activate warnings on suspicious contracts.'
  
       This switch activates warnings on suspicious contracts.  This
       includes warnings on suspicious postconditions (whether a pragma
*************** using the GNAT pragma Warnings (see the
*** 8857,8888 ****
  
  ‘-gnatw.T’
  
!      ‘Suppress warnings on suspicious contracts.’
  
       This switch suppresses warnings on suspicious contracts.
  
  ‘-gnatwu’
  
!      ‘Activate warnings on unused entities.’
  
       This switch activates warnings to be generated for entities that
!      are declared but not referenced, and for units that are ‘with’ed
       and not referenced.  In the case of packages, a warning is also
       generated if no entities in the package are referenced.  This means
       that if a with’ed package is referenced but the only references are
       in ‘use’ clauses or ‘renames’ declarations, a warning is still
       generated.  A warning is also generated for a generic package that
!      is ‘with’ed but never instantiated.  In the case where a package or
!      subprogram body is compiled, and there is a ‘with’ on the
       corresponding spec that is only referenced in the body, a warning
!      is also generated, noting that the ‘with’ can be moved to the body.
       The default is that such warnings are not generated.  This switch
       also activates warnings on unreferenced formals (it includes the
       effect of ‘-gnatwf’).
  
  ‘-gnatwU’
  
!      ‘Suppress warnings on unused entities.’
  
       This switch suppresses warnings for unused entities and packages.
       It also turns off warnings on unreferenced formals (and thus
--- 8857,8888 ----
  
  ‘-gnatw.T’
  
!      'Suppress warnings on suspicious contracts.'
  
       This switch suppresses warnings on suspicious contracts.
  
  ‘-gnatwu’
  
!      'Activate warnings on unused entities.'
  
       This switch activates warnings to be generated for entities that
!      are declared but not referenced, and for units that are 'with'ed
       and not referenced.  In the case of packages, a warning is also
       generated if no entities in the package are referenced.  This means
       that if a with’ed package is referenced but the only references are
       in ‘use’ clauses or ‘renames’ declarations, a warning is still
       generated.  A warning is also generated for a generic package that
!      is 'with'ed but never instantiated.  In the case where a package or
!      subprogram body is compiled, and there is a 'with' on the
       corresponding spec that is only referenced in the body, a warning
!      is also generated, noting that the 'with' can be moved to the body.
       The default is that such warnings are not generated.  This switch
       also activates warnings on unreferenced formals (it includes the
       effect of ‘-gnatwf’).
  
  ‘-gnatwU’
  
!      'Suppress warnings on unused entities.'
  
       This switch suppresses warnings for unused entities and packages.
       It also turns off warnings on unreferenced formals (and thus
*************** using the GNAT pragma Warnings (see the
*** 8890,8902 ****
  
  ‘-gnatw.u’
  
!      ‘Activate warnings on unordered enumeration types.’
  
       This switch causes enumeration types to be considered as
       conceptually unordered, unless an explicit pragma ‘Ordered’ is
       given for the type.  The effect is to generate warnings in clients
       that use explicit comparisons or subranges, since these constructs
!      both treat objects of the type as ordered.  (A ‘client’ is defined
       as a unit that is other than the unit in which the type is
       declared, or its body or subunits.)  Please refer to the
       description of pragma ‘Ordered’ in the ‘GNAT Reference Manual’ for
--- 8890,8902 ----
  
  ‘-gnatw.u’
  
!      'Activate warnings on unordered enumeration types.'
  
       This switch causes enumeration types to be considered as
       conceptually unordered, unless an explicit pragma ‘Ordered’ is
       given for the type.  The effect is to generate warnings in clients
       that use explicit comparisons or subranges, since these constructs
!      both treat objects of the type as ordered.  (A 'client' is defined
       as a unit that is other than the unit in which the type is
       declared, or its body or subunits.)  Please refer to the
       description of pragma ‘Ordered’ in the ‘GNAT Reference Manual’ for
*************** using the GNAT pragma Warnings (see the
*** 8905,8911 ****
  
  ‘-gnatw.U’
  
!      ‘Deactivate warnings on unordered enumeration types.’
  
       This switch causes all enumeration types to be considered as
       ordered, so that no warnings are given for comparisons or subranges
--- 8905,8911 ----
  
  ‘-gnatw.U’
  
!      'Deactivate warnings on unordered enumeration types.'
  
       This switch causes all enumeration types to be considered as
       ordered, so that no warnings are given for comparisons or subranges
*************** using the GNAT pragma Warnings (see the
*** 8913,8919 ****
  
  ‘-gnatwv’
  
!      ‘Activate warnings on unassigned variables.’
  
       This switch activates warnings for access to variables which may
       not be properly initialized.  The default is that such warnings are
--- 8913,8919 ----
  
  ‘-gnatwv’
  
!      'Activate warnings on unassigned variables.'
  
       This switch activates warnings for access to variables which may
       not be properly initialized.  The default is that such warnings are
*************** using the GNAT pragma Warnings (see the
*** 8926,8939 ****
  
  ‘-gnatwV’
  
!      ‘Suppress warnings on unassigned variables.’
  
       This switch suppresses warnings for access to variables which may
       not be properly initialized.
  
  ‘-gnatw.v’
  
!      ‘Activate info messages for non-default bit order.’
  
       This switch activates messages (labeled “info”, they are not
       warnings, just informational messages) about the effects of
--- 8926,8939 ----
  
  ‘-gnatwV’
  
!      'Suppress warnings on unassigned variables.'
  
       This switch suppresses warnings for access to variables which may
       not be properly initialized.
  
  ‘-gnatw.v’
  
!      'Activate info messages for non-default bit order.'
  
       This switch activates messages (labeled “info”, they are not
       warnings, just informational messages) about the effects of
*************** using the GNAT pragma Warnings (see the
*** 8945,8951 ****
  
  ‘-gnatw.V’
  
!      ‘Suppress info messages for non-default bit order.’
  
       This switch suppresses information messages for the effects of
       specifying non-default bit order on record components with
--- 8945,8951 ----
  
  ‘-gnatw.V’
  
!      'Suppress info messages for non-default bit order.'
  
       This switch suppresses information messages for the effects of
       specifying non-default bit order on record components with
*************** using the GNAT pragma Warnings (see the
*** 8953,8959 ****
  
  ‘-gnatww’
  
!      ‘Activate warnings on wrong low bound assumption.’
  
       This switch activates warnings for indexing an unconstrained string
       parameter with a literal or S’Length.  This is a case where the
--- 8953,8959 ----
  
  ‘-gnatww’
  
!      'Activate warnings on wrong low bound assumption.'
  
       This switch activates warnings for indexing an unconstrained string
       parameter with a literal or S’Length.  This is a case where the
*************** using the GNAT pragma Warnings (see the
*** 8963,8969 ****
  
  ‘-gnatwW’
  
!      ‘Suppress warnings on wrong low bound assumption.’
  
       This switch suppresses warnings for indexing an unconstrained
       string parameter with a literal or S’Length.  Note that this
--- 8963,8969 ----
  
  ‘-gnatwW’
  
!      'Suppress warnings on wrong low bound assumption.'
  
       This switch suppresses warnings for indexing an unconstrained
       string parameter with a literal or S’Length.  Note that this
*************** using the GNAT pragma Warnings (see the
*** 8977,8983 ****
  
  ‘-gnatw.w’
  
!      ‘Activate warnings on Warnings Off pragmas.’
  
       This switch activates warnings for use of ‘pragma Warnings (Off,
       entity)’ where either the pragma is entirely useless (because it
--- 8977,8983 ----
  
  ‘-gnatw.w’
  
!      'Activate warnings on Warnings Off pragmas.'
  
       This switch activates warnings for use of ‘pragma Warnings (Off,
       entity)’ where either the pragma is entirely useless (because it
*************** using the GNAT pragma Warnings (see the
*** 8990,9003 ****
  
  ‘-gnatw.W’
  
!      ‘Suppress warnings on unnecessary Warnings Off pragmas.’
  
       This switch suppresses warnings for use of ‘pragma Warnings (Off,
       ...)’.
  
  ‘-gnatwx’
  
!      ‘Activate warnings on Export/Import pragmas.’
  
       This switch activates warnings on Export/Import pragmas when the
       compiler detects a possible conflict between the Ada and foreign
--- 8990,9003 ----
  
  ‘-gnatw.W’
  
!      'Suppress warnings on unnecessary Warnings Off pragmas.'
  
       This switch suppresses warnings for use of ‘pragma Warnings (Off,
       ...)’.
  
  ‘-gnatwx’
  
!      'Activate warnings on Export/Import pragmas.'
  
       This switch activates warnings on Export/Import pragmas when the
       compiler detects a possible conflict between the Ada and foreign
*************** using the GNAT pragma Warnings (see the
*** 9008,9014 ****
  
  ‘-gnatwX’
  
!      ‘Suppress warnings on Export/Import pragmas.’
  
       This switch suppresses warnings on Export/Import pragmas.  The
       sense of this is that you are telling the compiler that you know
--- 9008,9014 ----
  
  ‘-gnatwX’
  
!      'Suppress warnings on Export/Import pragmas.'
  
       This switch suppresses warnings on Export/Import pragmas.  The
       sense of this is that you are telling the compiler that you know
*************** using the GNAT pragma Warnings (see the
*** 9017,9023 ****
  
  ‘-gnatw.x’
  
!      ‘Activate warnings for No_Exception_Propagation mode.’
  
       This switch activates warnings for exception usage when pragma
       Restrictions (No_Exception_Propagation) is in effect.  Warnings are
--- 9017,9023 ----
  
  ‘-gnatw.x’
  
!      'Activate warnings for No_Exception_Propagation mode.'
  
       This switch activates warnings for exception usage when pragma
       Restrictions (No_Exception_Propagation) is in effect.  Warnings are
*************** using the GNAT pragma Warnings (see the
*** 9028,9041 ****
  
  ‘-gnatw.X’
  
!      ‘Disable warnings for No_Exception_Propagation mode.’
  
       This switch disables warnings for exception usage when pragma
       Restrictions (No_Exception_Propagation) is in effect.
  
  ‘-gnatwy’
  
!      ‘Activate warnings for Ada compatibility issues.’
  
       For the most part, newer versions of Ada are upwards compatible
       with older versions.  For example, Ada 2005 programs will almost
--- 9028,9041 ----
  
  ‘-gnatw.X’
  
!      'Disable warnings for No_Exception_Propagation mode.'
  
       This switch disables warnings for exception usage when pragma
       Restrictions (No_Exception_Propagation) is in effect.
  
  ‘-gnatwy’
  
!      'Activate warnings for Ada compatibility issues.'
  
       For the most part, newer versions of Ada are upwards compatible
       with older versions.  For example, Ada 2005 programs will almost
*************** using the GNAT pragma Warnings (see the
*** 9048,9061 ****
  
  ‘-gnatwY’
  
!      ‘Disable warnings for Ada compatibility issues.’
  
       This switch suppresses the warnings intended to help in identifying
       incompatibilities between Ada language versions.
  
  ‘-gnatw.y’
  
!      ‘Activate information messages for why package spec needs body.’
  
       There are a number of cases in which a package spec needs a body.
       For example, the use of pragma Elaborate_Body, or the declaration
--- 9048,9061 ----
  
  ‘-gnatwY’
  
!      'Disable warnings for Ada compatibility issues.'
  
       This switch suppresses the warnings intended to help in identifying
       incompatibilities between Ada language versions.
  
  ‘-gnatw.y’
  
!      'Activate information messages for why package spec needs body.'
  
       There are a number of cases in which a package spec needs a body.
       For example, the use of pragma Elaborate_Body, or the declaration
*************** using the GNAT pragma Warnings (see the
*** 9067,9080 ****
  
  ‘-gnatw.Y’
  
!      ‘Disable information messages for why package spec needs body.’
  
       This switch suppresses the output of information messages showing
       why a package specification needs a body.
  
  ‘-gnatwz’
  
!      ‘Activate warnings on unchecked conversions.’
  
       This switch activates warnings for unchecked conversions where the
       types are known at compile time to have different sizes.  The
--- 9067,9080 ----
  
  ‘-gnatw.Y’
  
!      'Disable information messages for why package spec needs body.'
  
       This switch suppresses the output of information messages showing
       why a package specification needs a body.
  
  ‘-gnatwz’
  
!      'Activate warnings on unchecked conversions.'
  
       This switch activates warnings for unchecked conversions where the
       types are known at compile time to have different sizes.  The
*************** using the GNAT pragma Warnings (see the
*** 9083,9089 ****
  
  ‘-gnatwZ’
  
!      ‘Suppress warnings on unchecked conversions.’
  
       This switch suppresses warnings for unchecked conversions where the
       types are known at compile time to have different sizes or
--- 9083,9089 ----
  
  ‘-gnatwZ’
  
!      'Suppress warnings on unchecked conversions.'
  
       This switch suppresses warnings for unchecked conversions where the
       types are known at compile time to have different sizes or
*************** using the GNAT pragma Warnings (see the
*** 9091,9097 ****
  
  ‘-gnatw.z’
  
!      ‘Activate warnings for size not a multiple of alignment.’
  
       This switch activates warnings for cases of array and record types
       with specified ‘Size’ and ‘Alignment’ attributes where the size is
--- 9091,9097 ----
  
  ‘-gnatw.z’
  
!      'Activate warnings for size not a multiple of alignment.'
  
       This switch activates warnings for cases of array and record types
       with specified ‘Size’ and ‘Alignment’ attributes where the size is
*************** using the GNAT pragma Warnings (see the
*** 9101,9107 ****
  
  ‘-gnatw.Z’
  
!      ‘Suppress warnings for size not a multiple of alignment.’
  
       This switch suppresses warnings for cases of array and record types
       with specified ‘Size’ and ‘Alignment’ attributes where the size is
--- 9101,9107 ----
  
  ‘-gnatw.Z’
  
!      'Suppress warnings for size not a multiple of alignment.'
  
       This switch suppresses warnings for cases of array and record types
       with specified ‘Size’ and ‘Alignment’ attributes where the size is
*************** default checks required by Ada as descri
*** 9385,9405 ****
  
  ‘-gnatVa’
  
!      ‘All validity checks.’
  
       All validity checks are turned on.  That is, ‘-gnatVa’ is
       equivalent to ‘gnatVcdefimoprst’.
  
  ‘-gnatVc’
  
!      ‘Validity checks for copies.’
  
       The right-hand side of assignments, and the (explicit) initializing
       values of object declarations are validity checked.
  
  ‘-gnatVd’
  
!      ‘Default (RM) validity checks.’
  
       Some validity checks are required by Ada (see RM 13.9.1 (9-11));
       these (and only these) validity checks are enabled by default.  For
--- 9385,9405 ----
  
  ‘-gnatVa’
  
!      'All validity checks.'
  
       All validity checks are turned on.  That is, ‘-gnatVa’ is
       equivalent to ‘gnatVcdefimoprst’.
  
  ‘-gnatVc’
  
!      'Validity checks for copies.'
  
       The right-hand side of assignments, and the (explicit) initializing
       values of object declarations are validity checked.
  
  ‘-gnatVd’
  
!      'Default (RM) validity checks.'
  
       Some validity checks are required by Ada (see RM 13.9.1 (9-11));
       these (and only these) validity checks are enabled by default.  For
*************** default checks required by Ada as descri
*** 9419,9425 ****
  
  ‘-gnatVe’
  
!      ‘Validity checks for scalar components.’
  
       In the absence of this switch, assignments to scalar components of
       enclosing record or array objects are not validity checked, even if
--- 9419,9425 ----
  
  ‘-gnatVe’
  
!      'Validity checks for scalar components.'
  
       In the absence of this switch, assignments to scalar components of
       enclosing record or array objects are not validity checked, even if
*************** default checks required by Ada as descri
*** 9429,9435 ****
  
  ‘-gnatVf’
  
!      ‘Validity checks for floating-point values.’
  
       Specifying this switch enables validity checking for floating-point
       values in the same contexts where validity checking is enabled for
--- 9429,9435 ----
  
  ‘-gnatVf’
  
!      'Validity checks for floating-point values.'
  
       Specifying this switch enables validity checking for floating-point
       values in the same contexts where validity checking is enabled for
*************** default checks required by Ada as descri
*** 9450,9463 ****
  
  ‘-gnatVi’
  
!      ‘Validity checks for ‘‘in‘‘ mode parameters.’
  
       Arguments for parameters of mode ‘in’ are validity checked in
       function and procedure calls at the point of call.
  
  ‘-gnatVm’
  
!      ‘Validity checks for ‘‘in out‘‘ mode parameters.’
  
       Arguments for parameters of mode ‘in out’ are validity checked in
       procedure calls at the point of call.  The ‘'m'’ here stands for
--- 9450,9463 ----
  
  ‘-gnatVi’
  
!      'Validity checks for ''in'' mode parameters.'
  
       Arguments for parameters of mode ‘in’ are validity checked in
       function and procedure calls at the point of call.
  
  ‘-gnatVm’
  
!      'Validity checks for ''in out'' mode parameters.'
  
       Arguments for parameters of mode ‘in out’ are validity checked in
       procedure calls at the point of call.  The ‘'m'’ here stands for
*************** default checks required by Ada as descri
*** 9469,9475 ****
  
  ‘-gnatVn’
  
!      ‘No validity checks.’
  
       This switch turns off all validity checking, including the default
       checking for case statements and left hand side subscripts.  Note
--- 9469,9475 ----
  
  ‘-gnatVn’
  
!      'No validity checks.'
  
       This switch turns off all validity checking, including the default
       checking for case statements and left hand side subscripts.  Note
*************** default checks required by Ada as descri
*** 9479,9485 ****
  
  ‘-gnatVo’
  
!      ‘Validity checks for operator and attribute operands.’
  
       Scalar arguments for predefined operators and for attributes are
       validity checked.  This includes all operators in package
--- 9479,9485 ----
  
  ‘-gnatVo’
  
!      'Validity checks for operator and attribute operands.'
  
       Scalar arguments for predefined operators and for attributes are
       validity checked.  This includes all operators in package
*************** default checks required by Ada as descri
*** 9492,9498 ****
  
  ‘-gnatVp’
  
!      ‘Validity checks for parameters.’
  
       This controls the treatment of formal parameters within a
       subprogram (as opposed to ‘-gnatVi’ and ‘-gnatVm’, which control
--- 9492,9498 ----
  
  ‘-gnatVp’
  
!      'Validity checks for parameters.'
  
       This controls the treatment of formal parameters within a
       subprogram (as opposed to ‘-gnatVi’ and ‘-gnatVm’, which control
*************** default checks required by Ada as descri
*** 9508,9521 ****
  
  ‘-gnatVr’
  
!      ‘Validity checks for function returns.’
  
       The expression in simple ‘return’ statements in functions is
       validity checked.
  
  ‘-gnatVs’
  
!      ‘Validity checks for subscripts.’
  
       All subscript expressions are checked for validity, whatever
       context they occur in (in default mode some subscripts are not
--- 9508,9521 ----
  
  ‘-gnatVr’
  
!      'Validity checks for function returns.'
  
       The expression in simple ‘return’ statements in functions is
       validity checked.
  
  ‘-gnatVs’
  
!      'Validity checks for subscripts.'
  
       All subscript expressions are checked for validity, whatever
       context they occur in (in default mode some subscripts are not
*************** default checks required by Ada as descri
*** 9524,9530 ****
  
  ‘-gnatVt’
  
!      ‘Validity checks for tests.’
  
       Expressions used as conditions in ‘if’, ‘while’ or ‘exit’
       statements are checked, as well as guard expressions in entry
--- 9524,9530 ----
  
  ‘-gnatVt’
  
!      'Validity checks for tests.'
  
       Expressions used as conditions in ‘if’, ‘while’ or ‘exit’
       statements are checked, as well as guard expressions in entry
*************** defined:
*** 9579,9585 ****
  
  ‘-gnaty0’
  
!      ‘Specify indentation level.’
  
       If a digit from 1-9 appears in the string after ‘-gnaty’ then
       proper indentation is checked, with the digit indicating the
--- 9579,9585 ----
  
  ‘-gnaty0’
  
!      'Specify indentation level.'
  
       If a digit from 1-9 appears in the string after ‘-gnaty’ then
       proper indentation is checked, with the digit indicating the
*************** defined:
*** 9605,9611 ****
  
  ‘-gnatya’
  
!      ‘Check attribute casing.’
  
       Attribute names, including the case of keywords such as ‘digits’
       used as attributes names, must be written in mixed case, that is,
--- 9605,9611 ----
  
  ‘-gnatya’
  
!      'Check attribute casing.'
  
       Attribute names, including the case of keywords such as ‘digits’
       used as attributes names, must be written in mixed case, that is,
*************** defined:
*** 9614,9620 ****
  
  ‘-gnatyA’
  
!      ‘Use of array index numbers in array attributes.’
  
       When using the array attributes First, Last, Range, or Length, the
       index number must be omitted for one-dimensional arrays and is
--- 9614,9620 ----
  
  ‘-gnatyA’
  
!      'Use of array index numbers in array attributes.'
  
       When using the array attributes First, Last, Range, or Length, the
       index number must be omitted for one-dimensional arrays and is
*************** defined:
*** 9622,9628 ****
  
  ‘-gnatyb’
  
!      ‘Blanks not allowed at statement end.’
  
       Trailing blanks are not allowed at the end of statements.  The
       purpose of this rule, together with h (no horizontal tabs), is to
--- 9622,9628 ----
  
  ‘-gnatyb’
  
!      'Blanks not allowed at statement end.'
  
       Trailing blanks are not allowed at the end of statements.  The
       purpose of this rule, together with h (no horizontal tabs), is to
*************** defined:
*** 9631,9637 ****
  
  ‘-gnatyB’
  
!      ‘Check Boolean operators.’
  
       The use of AND/OR operators is not permitted except in the cases of
       modular operands, array operands, and simple stand-alone boolean
--- 9631,9637 ----
  
  ‘-gnatyB’
  
!      'Check Boolean operators.'
  
       The use of AND/OR operators is not permitted except in the cases of
       modular operands, array operands, and simple stand-alone boolean
*************** defined:
*** 9640,9646 ****
  
  ‘-gnatyc’
  
!      ‘Check comments, double space.’
  
       Comments must meet the following set of rules:
  
--- 9640,9646 ----
  
  ‘-gnatyc’
  
!      'Check comments, double space.'
  
       Comments must meet the following set of rules:
  
*************** defined:
*** 9683,9703 ****
  
  ‘-gnatyC’
  
!      ‘Check comments, single space.’
  
       This is identical to ‘c’ except that only one space is required
       following the ‘--’ of a comment instead of two.
  
  ‘-gnatyd’
  
!      ‘Check no DOS line terminators present.’
  
       All lines must be terminated by a single ASCII.LF character (in
       particular the DOS line terminator sequence CR/LF is not allowed).
  
  ‘-gnatyD’
  
!      ‘Check declared identifiers in mixed case.’
  
       Declared identifiers must be in mixed case, as in
       This_Is_An_Identifier.  Use -gnatyr in addition to ensure that
--- 9683,9703 ----
  
  ‘-gnatyC’
  
!      'Check comments, single space.'
  
       This is identical to ‘c’ except that only one space is required
       following the ‘--’ of a comment instead of two.
  
  ‘-gnatyd’
  
!      'Check no DOS line terminators present.'
  
       All lines must be terminated by a single ASCII.LF character (in
       particular the DOS line terminator sequence CR/LF is not allowed).
  
  ‘-gnatyD’
  
!      'Check declared identifiers in mixed case.'
  
       Declared identifiers must be in mixed case, as in
       This_Is_An_Identifier.  Use -gnatyr in addition to ensure that
*************** defined:
*** 9705,9725 ****
  
  ‘-gnatye’
  
!      ‘Check end/exit labels.’
  
       Optional labels on ‘end’ statements ending subprograms and on
       ‘exit’ statements exiting named loops, are required to be present.
  
  ‘-gnatyf’
  
!      ‘No form feeds or vertical tabs.’
  
       Neither form feeds nor vertical tab characters are permitted in the
       source text.
  
  ‘-gnatyg’
  
!      ‘GNAT style mode.’
  
       The set of style check switches is set to match that used by the
       GNAT sources.  This may be useful when developing code that is
--- 9705,9725 ----
  
  ‘-gnatye’
  
!      'Check end/exit labels.'
  
       Optional labels on ‘end’ statements ending subprograms and on
       ‘exit’ statements exiting named loops, are required to be present.
  
  ‘-gnatyf’
  
!      'No form feeds or vertical tabs.'
  
       Neither form feeds nor vertical tab characters are permitted in the
       source text.
  
  ‘-gnatyg’
  
!      'GNAT style mode.'
  
       The set of style check switches is set to match that used by the
       GNAT sources.  This may be useful when developing code that is
*************** defined:
*** 9729,9735 ****
  
  ‘-gnatyh’
  
!      ‘No horizontal tabs.’
  
       Horizontal tab characters are not permitted in the source text.
       Together with the b (no blanks at end of line) check, this enforces
--- 9729,9735 ----
  
  ‘-gnatyh’
  
!      'No horizontal tabs.'
  
       Horizontal tab characters are not permitted in the source text.
       Together with the b (no blanks at end of line) check, this enforces
*************** defined:
*** 9737,9743 ****
  
  ‘-gnatyi’
  
!      ‘Check if-then layout.’
  
       The keyword ‘then’ must appear either on the same line as
       corresponding ‘if’, or on a line on its own, lined up under the
--- 9737,9743 ----
  
  ‘-gnatyi’
  
!      'Check if-then layout.'
  
       The keyword ‘then’ must appear either on the same line as
       corresponding ‘if’, or on a line on its own, lined up under the
*************** defined:
*** 9745,9758 ****
  
  ‘-gnatyI’
  
!      ‘check mode IN keywords.’
  
       Mode ‘in’ (the default mode) is not allowed to be given explicitly.
       ‘in out’ is fine, but not ‘in’ on its own.
  
  ‘-gnatyk’
  
!      ‘Check keyword casing.’
  
       All keywords must be in lower case (with the exception of keywords
       such as ‘digits’ used as attribute names to which this check does
--- 9745,9758 ----
  
  ‘-gnatyI’
  
!      'check mode IN keywords.'
  
       Mode ‘in’ (the default mode) is not allowed to be given explicitly.
       ‘in out’ is fine, but not ‘in’ on its own.
  
  ‘-gnatyk’
  
!      'Check keyword casing.'
  
       All keywords must be in lower case (with the exception of keywords
       such as ‘digits’ used as attribute names to which this check does
*************** defined:
*** 9761,9767 ****
  
  ‘-gnatyl’
  
!      ‘Check layout.’
  
       Layout of statement and declaration constructs must follow the
       recommendations in the Ada Reference Manual, as indicated by the
--- 9761,9767 ----
  
  ‘-gnatyl’
  
!      'Check layout.'
  
       Layout of statement and declaration constructs must follow the
       recommendations in the Ada Reference Manual, as indicated by the
*************** defined:
*** 9826,9840 ****
  
  ‘-gnatyL’
  
!      ‘Set maximum nesting level.’
  
       The maximum level of nesting of constructs (including subprograms,
       loops, blocks, packages, and conditionals) may not exceed the given
!      value ‘nnn’.  A value of zero disconnects this style check.
  
  ‘-gnatym’
  
!      ‘Check maximum line length.’
  
       The length of source lines must not exceed 79 characters, including
       any trailing blanks.  The value of 79 allows convenient display on
--- 9826,9840 ----
  
  ‘-gnatyL’
  
!      'Set maximum nesting level.'
  
       The maximum level of nesting of constructs (including subprograms,
       loops, blocks, packages, and conditionals) may not exceed the given
!      value 'nnn'.  A value of zero disconnects this style check.
  
  ‘-gnatym’
  
!      'Check maximum line length.'
  
       The length of source lines must not exceed 79 characters, including
       any trailing blanks.  The value of 79 allows convenient display on
*************** defined:
*** 9847,9855 ****
  
  ‘-gnatyM’
  
!      ‘Set maximum line length.’
  
!      The length of lines must not exceed the given value ‘nnn’.  The
       maximum value that can be specified is 32767.  If neither style
       option for setting the line length is used, then the default is
       255.  This also controls the maximum length of lexical elements,
--- 9847,9855 ----
  
  ‘-gnatyM’
  
!      'Set maximum line length.'
  
!      The length of lines must not exceed the given value 'nnn'.  The
       maximum value that can be specified is 32767.  If neither style
       option for setting the line length is used, then the default is
       255.  This also controls the maximum length of lexical elements,
*************** defined:
*** 9857,9863 ****
  
  ‘-gnatyn’
  
!      ‘Check casing of entities in Standard.’
  
       Any identifier from Standard must be cased to match the
       presentation in the Ada Reference Manual (for example, ‘Integer’
--- 9857,9863 ----
  
  ‘-gnatyn’
  
!      'Check casing of entities in Standard.'
  
       Any identifier from Standard must be cased to match the
       presentation in the Ada Reference Manual (for example, ‘Integer’
*************** defined:
*** 9865,9877 ****
  
  ‘-gnatyN’
  
!      ‘Turn off all style checks.’
  
       All style check options are turned off.
  
  ‘-gnatyo’
  
!      ‘Check order of subprogram bodies.’
  
       All subprogram bodies in a given scope (e.g., a package body) must
       be in alphabetical order.  The ordering rule uses normal Ada rules
--- 9865,9877 ----
  
  ‘-gnatyN’
  
!      'Turn off all style checks.'
  
       All style check options are turned off.
  
  ‘-gnatyo’
  
!      'Check order of subprogram bodies.'
  
       All subprogram bodies in a given scope (e.g., a package body) must
       be in alphabetical order.  The ordering rule uses normal Ada rules
*************** defined:
*** 9881,9887 ****
  
  ‘-gnatyO’
  
!      ‘Check that overriding subprograms are explicitly marked as such.’
  
       This applies to all subprograms of a derived type that override a
       primitive operation of the type, for both tagged and untagged
--- 9881,9887 ----
  
  ‘-gnatyO’
  
!      'Check that overriding subprograms are explicitly marked as such.'
  
       This applies to all subprograms of a derived type that override a
       primitive operation of the type, for both tagged and untagged
*************** defined:
*** 9893,9899 ****
  
  ‘-gnatyp’
  
!      ‘Check pragma casing.’
  
       Pragma names must be written in mixed case, that is, the initial
       letter and any letter following an underscore must be uppercase.
--- 9893,9899 ----
  
  ‘-gnatyp’
  
!      'Check pragma casing.'
  
       Pragma names must be written in mixed case, that is, the initial
       letter and any letter following an underscore must be uppercase.
*************** defined:
*** 9902,9908 ****
  
  ‘-gnatyr’
  
!      ‘Check references.’
  
       All identifier references must be cased in the same way as the
       corresponding declaration.  No specific casing style is imposed on
--- 9902,9908 ----
  
  ‘-gnatyr’
  
!      'Check references.'
  
       All identifier references must be cased in the same way as the
       corresponding declaration.  No specific casing style is imposed on
*************** defined:
*** 9911,9917 ****
  
  ‘-gnatys’
  
!      ‘Check separate specs.’
  
       Separate declarations (‘specs’) are required for subprograms (a
       body is not allowed to serve as its own declaration).  The only
--- 9911,9917 ----
  
  ‘-gnatys’
  
!      'Check separate specs.'
  
       Separate declarations (‘specs’) are required for subprograms (a
       body is not allowed to serve as its own declaration).  The only
*************** defined:
*** 9921,9927 ****
  
  ‘-gnatyS’
  
!      ‘Check no statements after then/else.’
  
       No statements are allowed on the same line as a ‘then’ or ‘else’
       keyword following the keyword in an ‘if’ statement.  ‘or else’ and
--- 9921,9927 ----
  
  ‘-gnatyS’
  
!      'Check no statements after then/else.'
  
       No statements are allowed on the same line as a ‘then’ or ‘else’
       keyword following the keyword in an ‘if’ statement.  ‘or else’ and
*************** defined:
*** 9930,9936 ****
  
  ‘-gnatyt’
  
!      ‘Check token spacing.’
  
       The following token spacing rules are enforced:
  
--- 9930,9936 ----
  
  ‘-gnatyt’
  
!      'Check token spacing.'
  
       The following token spacing rules are enforced:
  
*************** defined:
*** 9976,9982 ****
  
  ‘-gnatyu’
  
!      ‘Check unnecessary blank lines.’
  
       Unnecessary blank lines are not allowed.  A blank line is
       considered unnecessary if it appears at the end of the file, or if
--- 9976,9982 ----
  
  ‘-gnatyu’
  
!      'Check unnecessary blank lines.'
  
       Unnecessary blank lines are not allowed.  A blank line is
       considered unnecessary if it appears at the end of the file, or if
*************** defined:
*** 9984,9990 ****
  
  ‘-gnatyx’
  
!      ‘Check extra parentheses.’
  
       Unnecessary extra level of parentheses (C-style) are not allowed
       around conditions in ‘if’ statements, ‘while’ statements and ‘exit’
--- 9984,9990 ----
  
  ‘-gnatyx’
  
!      'Check extra parentheses.'
  
       Unnecessary extra level of parentheses (C-style) are not allowed
       around conditions in ‘if’ statements, ‘while’ statements and ‘exit’
*************** defined:
*** 9992,9998 ****
  
  ‘-gnatyy’
  
!      ‘Set all standard style check options.’
  
       This is equivalent to ‘gnaty3aAbcefhiklmnprst’, that is all
       checking options enabled with the exception of ‘-gnatyB’,
--- 9992,9998 ----
  
  ‘-gnatyy’
  
!      'Set all standard style check options.'
  
       This is equivalent to ‘gnaty3aAbcefhiklmnprst’, that is all
       checking options enabled with the exception of ‘-gnatyB’,
*************** defined:
*** 10001,10019 ****
  
  ‘-gnaty-’
  
!      ‘Remove style check options.’
  
       This causes any subsequent options in the string to act as
       canceling the corresponding style check option.  To cancel maximum
       nesting level control, use the ‘L’ parameter without any integer
!      value after that, because any digit following ‘-’ in the parameter
       string of the ‘-gnaty’ option will be treated as canceling the
       indentation check.  The same is true for the ‘M’ parameter.  ‘y’
!      and ‘N’ parameters are not allowed after ‘-’.
  
  ‘-gnaty+’
  
!      ‘Enable style check options.’
  
       This causes any subsequent options in the string to enable the
       corresponding style check option.  That is, it cancels the effect
--- 10001,10019 ----
  
  ‘-gnaty-’
  
!      'Remove style check options.'
  
       This causes any subsequent options in the string to act as
       canceling the corresponding style check option.  To cancel maximum
       nesting level control, use the ‘L’ parameter without any integer
!      value after that, because any digit following '-' in the parameter
       string of the ‘-gnaty’ option will be treated as canceling the
       indentation check.  The same is true for the ‘M’ parameter.  ‘y’
!      and ‘N’ parameters are not allowed after '-'.
  
  ‘-gnaty+’
  
!      'Enable style check options.'
  
       This causes any subsequent options in the string to enable the
       corresponding style check option.  That is, it cancels the effect
*************** default behavior.
*** 10115,10127 ****
       Overflow checks are always enabled by this switch.  The argument
       controls the mode, using the codes
  
!      ‘1 = STRICT’
  
            In STRICT mode, intermediate operations are always done using
            the base type, and overflow checking ensures that the result
            is within the base type range.
  
!      ‘2 = MINIMIZED’
  
            In MINIMIZED mode, overflows in intermediate operations are
            avoided where possible by using a larger integer type for the
--- 10115,10127 ----
       Overflow checks are always enabled by this switch.  The argument
       controls the mode, using the codes
  
!      '1 = STRICT'
  
            In STRICT mode, intermediate operations are always done using
            the base type, and overflow checking ensures that the result
            is within the base type range.
  
!      '2 = MINIMIZED'
  
            In MINIMIZED mode, overflows in intermediate operations are
            avoided where possible by using a larger integer type for the
*************** default behavior.
*** 10129,10135 ****
            checking ensures that the result fits in this larger integer
            type.
  
!      ‘3 = ELIMINATED’
  
            In ELIMINATED mode, overflows in intermediate operations are
            avoided by using multi-precision arithmetic.  In this case,
--- 10129,10135 ----
            checking ensures that the result fits in this larger integer
            type.
  
!      '3 = ELIMINATED'
  
            In ELIMINATED mode, overflows in intermediate operations are
            avoided by using multi-precision arithmetic.  In this case,
*************** File: gnat_ugn.info,  Node: Using gcc fo
*** 10220,10226 ****
       Otherwise, the output is simply the error messages, if any.  No
       object file or ALI file is generated by a syntax-only compilation.
       Also, no units other than the one specified are accessed.  For
!      example, if a unit ‘X’ ‘with’s a unit ‘Y’, compiling unit ‘X’ in
       syntax check only mode does not access the source file containing
       unit ‘Y’.
  
--- 10220,10226 ----
       Otherwise, the output is simply the error messages, if any.  No
       object file or ALI file is generated by a syntax-only compilation.
       Also, no units other than the one specified are accessed.  For
!      example, if a unit ‘X’ 'with's a unit ‘Y’, compiling unit ‘X’ in
       syntax check only mode does not access the source file containing
       unit ‘Y’.
  
*************** mode, or indicate Ada 83 compatibility m
*** 10297,10303 ****
       and Ada 2005 are upwardly compatible with Ada 83.  Thus a correct
       Ada 83 program is usually also a correct program in these later
       versions of the language standard.  For further information please
!      refer to the ‘Compatibility and Porting Guide’ chapter in the ‘GNAT
       Reference Manual’.
  
  ‘-gnat95’ (Ada 95 mode)
--- 10297,10303 ----
       and Ada 2005 are upwardly compatible with Ada 83.  Thus a correct
       Ada 83 program is usually also a correct program in these later
       versions of the language standard.  For further information please
!      refer to the 'Compatibility and Porting Guide' chapter in the ‘GNAT
       Reference Manual’.
  
  ‘-gnat95’ (Ada 95 mode)
*************** File: gnat_ugn.info,  Node: Character Se
*** 10367,10403 ****
       identifiers.  ‘c’ is a single character indicating the character
       set, as follows:
  
!      ‘1’            ISO 8859-1 (Latin-1) identifiers
                      
                      
!      ‘2’            ISO 8859-2 (Latin-2) letters allowed in identifiers
                      
                      
!      ‘3’            ISO 8859-3 (Latin-3) letters allowed in identifiers
                      
                      
!      ‘4’            ISO 8859-4 (Latin-4) letters allowed in identifiers
                      
                      
!      ‘5’            ISO 8859-5 (Cyrillic) letters allowed in identifiers
                      
                      
!      ‘9’            ISO 8859-15 (Latin-9) letters allowed in identifiers
                      
                      
!      ‘p’            IBM PC letters (code page 437) allowed in identifiers
                      
                      
!      ‘8’            IBM PC letters (code page 850) allowed in identifiers
                      
                      
!      ‘f’            Full upper-half codes allowed in identifiers
                      
                      
!      ‘n’            No upper-half codes allowed in identifiers
                      
                      
!      ‘w’            Wide-character codes (that is, codes greater than 255)
                      allowed in identifiers
                      
  
--- 10367,10403 ----
       identifiers.  ‘c’ is a single character indicating the character
       set, as follows:
  
!      '1'            ISO 8859-1 (Latin-1) identifiers
                      
                      
!      '2'            ISO 8859-2 (Latin-2) letters allowed in identifiers
                      
                      
!      '3'            ISO 8859-3 (Latin-3) letters allowed in identifiers
                      
                      
!      '4'            ISO 8859-4 (Latin-4) letters allowed in identifiers
                      
                      
!      '5'            ISO 8859-5 (Cyrillic) letters allowed in identifiers
                      
                      
!      '9'            ISO 8859-15 (Latin-9) letters allowed in identifiers
                      
                      
!      'p'            IBM PC letters (code page 437) allowed in identifiers
                      
                      
!      '8'            IBM PC letters (code page 850) allowed in identifiers
                      
                      
!      'f'            Full upper-half codes allowed in identifiers
                      
                      
!      'n'            No upper-half codes allowed in identifiers
                      
                      
!      'w'            Wide-character codes (that is, codes greater than 255)
                      allowed in identifiers
                      
  
*************** File: gnat_ugn.info,  Node: Character Se
*** 10409,10430 ****
       Specify the method of encoding for wide characters.  ‘e’ is one of
       the following:
  
!      ‘h’            Hex encoding (brackets coding also recognized)
                      
                      
!      ‘u’            Upper half encoding (brackets encoding also recognized)
                      
                      
!      ‘s’            Shift/JIS encoding (brackets encoding also recognized)
                      
                      
!      ‘e’            EUC encoding (brackets encoding also recognized)
                      
                      
!      ‘8’            UTF-8 encoding (brackets encoding also recognized)
                      
                      
!      ‘b’            Brackets encoding only (default value)
                      
  
       For full details on these encoding methods see *note Wide_Character
--- 10409,10430 ----
       Specify the method of encoding for wide characters.  ‘e’ is one of
       the following:
  
!      'h'            Hex encoding (brackets coding also recognized)
                      
                      
!      'u'            Upper half encoding (brackets encoding also recognized)
                      
                      
!      's'            Shift/JIS encoding (brackets encoding also recognized)
                      
                      
!      'e'            EUC encoding (brackets encoding also recognized)
                      
                      
!      '8'            UTF-8 encoding (brackets encoding also recognized)
                      
                      
!      'b'            Brackets encoding only (default value)
                      
  
       For full details on these encoding methods see *note Wide_Character
*************** File: gnat_ugn.info,  Node: Auxiliary Ou
*** 10558,10573 ****
       status and allows an integrated development environment to better
       react to a compilation failure.  Those exit status are:
  
!      ‘5’            There was an error in at least one source file.
                      
                      
!      ‘3’            At least one source file did not generate an object file.
                      
                      
!      ‘2’            The compiler died unexpectedly (internal error for example).
                      
                      
!      ‘0’            An object file has been generated for every source file.
                      
  
  
--- 10558,10573 ----
       status and allows an integrated development environment to better
       react to a compilation failure.  Those exit status are:
  
!      '5'            There was an error in at least one source file.
                      
                      
!      '3'            At least one source file did not generate an object file.
                      
                      
!      '2'            The compiler died unexpectedly (internal error for example).
                      
                      
!      '0'            An object file has been generated for every source file.
                      
  
  
*************** presented in subsequent sections.
*** 11297,11303 ****
  
       Generate a binder file suitable for space-constrained applications.
       When active, binder-generated objects not required for program
!      operation are no longer generated.  ‘Warning:’ this option comes
       with the following limitations:
  
          * Starting the program’s execution in the debugger will cause it
--- 11297,11303 ----
  
       Generate a binder file suitable for space-constrained applications.
       When active, binder-generated objects not required for program
!      operation are no longer generated.  'Warning:' this option comes
       with the following limitations:
  
          * Starting the program’s execution in the debugger will cause it
*************** presented in subsequent sections.
*** 11328,11334 ****
  
  ‘-o `file'’
  
!      Name the output file ‘file’ (default is ‘b~`xxx’.adb‘).  Note that
       if this option is used, then linking must be done manually,
       gnatlink cannot be used.
  
--- 11328,11334 ----
  
  ‘-o `file'’
  
!      Name the output file ‘file’ (default is ‘b~`xxx’.adb').  Note that
       if this option is used, then linking must be done manually,
       gnatlink cannot be used.
  
*************** generated by the binder.
*** 11741,11747 ****
  ‘-o `file'’
  
       Set name of output file to ‘file’ instead of the normal
!      ‘b~`mainprog’.adb‘ default.  Note that ‘file’ denote the Ada binder
       generated body filename.  Note that if this option is used, then
       linking must be done manually.  It is not possible to use gnatlink
       in this case, since it cannot locate the binder file.
--- 11741,11747 ----
  ‘-o `file'’
  
       Set name of output file to ‘file’ instead of the normal
!      ‘b~`mainprog’.adb' default.  Note that ‘file’ denote the Ada binder
       generated body filename.  Note that if this option is used, then
       linking must be done manually.  It is not possible to use gnatlink
       in this case, since it cannot locate the binder file.
*************** containing the following callable routin
*** 11823,11829 ****
  If the ‘-n’ switch is given, more than one ALI file may appear on the
  command line for ‘gnatbind’.  The normal ‘closure’ calculation is
  performed for each of the specified units.  Calculating the closure
! means finding out the set of units involved by tracing ‘with’
  references.  The reason it is necessary to be able to specify more than
  one ALI file is that a given program may invoke two or more quite
  separate groups of Ada units.
--- 11823,11829 ----
  If the ‘-n’ switch is given, more than one ALI file may appear on the
  command line for ‘gnatbind’.  The normal ‘closure’ calculation is
  performed for each of the specified units.  Calculating the closure
! means finding out the set of units involved by tracing 'with'
  references.  The reason it is necessary to be able to specify more than
  one ALI file is that a given program may invoke two or more quite
  separate groups of Ada units.
*************** correctly, the two variables
*** 11879,11886 ****
  
  are declared in one of the GNAT library routines.  These variables must
  be set from the actual ‘argc’ and ‘argv’ values passed to the main
! program.  With no ‘n’ present, ‘gnatbind’ generates the C main program
! to automatically set these variables.  If the ‘n’ switch is used, there
  is no automatic way to set these variables.  If they are not set, the
  procedures in ‘Ada.Command_Line’ will not be available, and any attempt
  to use them will raise ‘Constraint_Error’.  If command line access is
--- 11879,11886 ----
  
  are declared in one of the GNAT library routines.  These variables must
  be set from the actual ‘argc’ and ‘argv’ values passed to the main
! program.  With no 'n' present, ‘gnatbind’ generates the C main program
! to automatically set these variables.  If the 'n' switch is used, there
  is no automatic way to set these variables.  If they are not set, the
  procedures in ‘Ada.Command_Line’ will not be available, and any attempt
  to use them will raise ‘Constraint_Error’.  If command line access is
*************** contained in object file ‘demo1.o’ i
*** 12662,12689 ****
  compilation of demo1 has been modified (DIF). Each source file has a
  status qualifier which can be:
  
! ‘OK (unchanged)’
  
       The version of the source file used for the compilation of the
       specified unit corresponds exactly to the actual source file.
  
! ‘MOK (slightly modified)’
  
       The version of the source file used for the compilation of the
       specified unit differs from the actual source file but not enough
       to require recompilation.  If you use gnatmake with the option ‘-m’
       (minimal recompilation), a file marked MOK will not be recompiled.
  
! ‘DIF (modified)’
  
       No version of the source found on the path corresponds to the
       source used to build this object.
  
! ‘??? (file not found)’
  
       No source file was found for this unit.
  
! ‘HID (hidden, unchanged version not first on PATH)’
  
       The version of the source that corresponds exactly to the source
       used for compilation has been found on the path but it is hidden by
--- 12662,12689 ----
  compilation of demo1 has been modified (DIF). Each source file has a
  status qualifier which can be:
  
! 'OK (unchanged)'
  
       The version of the source file used for the compilation of the
       specified unit corresponds exactly to the actual source file.
  
! 'MOK (slightly modified)'
  
       The version of the source file used for the compilation of the
       specified unit differs from the actual source file but not enough
       to require recompilation.  If you use gnatmake with the option ‘-m’
       (minimal recompilation), a file marked MOK will not be recompiled.
  
! 'DIF (modified)'
  
       No version of the source found on the path corresponds to the
       source used to build this object.
  
! '??? (file not found)'
  
       No source file was found for this unit.
  
! 'HID (hidden, unchanged version not first on PATH)'
  
       The version of the source that corresponds exactly to the source
       used for compilation has been found on the path but it is hidden by
*************** File: gnat_ugn.info,  Node: Switches for
*** 12761,12783 ****
       format giving as much as information possible on each requested
       units, including special characteristics such as:
  
!         * ‘Preelaborable’: The unit is preelaborable in the Ada sense.
  
!         * ‘No_Elab_Code’: No elaboration code has been produced by the
            compiler for this unit.
  
!         * ‘Pure’: The unit is pure in the Ada sense.
  
!         * ‘Elaborate_Body’: The unit contains a pragma Elaborate_Body.
  
!         * ‘Remote_Types’: The unit contains a pragma Remote_Types.
  
!         * ‘Shared_Passive’: The unit contains a pragma Shared_Passive.
  
!         * ‘Predefined’: This unit is part of the predefined environment
            and cannot be modified by the user.
  
!         * ‘Remote_Call_Interface’: The unit contains a pragma
            Remote_Call_Interface.
  
  
--- 12761,12783 ----
       format giving as much as information possible on each requested
       units, including special characteristics such as:
  
!         * 'Preelaborable': The unit is preelaborable in the Ada sense.
  
!         * 'No_Elab_Code': No elaboration code has been produced by the
            compiler for this unit.
  
!         * 'Pure': The unit is pure in the Ada sense.
  
!         * 'Elaborate_Body': The unit contains a pragma Elaborate_Body.
  
!         * 'Remote_Types': The unit contains a pragma Remote_Types.
  
!         * 'Shared_Passive': The unit contains a pragma Shared_Passive.
  
!         * 'Predefined': This unit is part of the predefined environment
            and cannot be modified by the user.
  
!         * 'Remote_Call_Interface': The unit contains a pragma
            Remote_Call_Interface.
  
  
*************** File: gnat_ugn.info,  Node: Introduction
*** 13012,13018 ****
  
  ‘GDB’ contains a large repertoire of commands.  See ‘Debugging with GDB’
  for extensive documentation on the use of these commands, together with
! examples of their use.  Furthermore, the command ‘help’ invoked from
  within GDB activates a simple help facility which summarizes the
  available commands and their options.  In this section we summarize a
  few of the most commonly used commands to give an idea of what ‘GDB’ is
--- 13012,13018 ----
  
  ‘GDB’ contains a large repertoire of commands.  See ‘Debugging with GDB’
  for extensive documentation on the use of these commands, together with
! examples of their use.  Furthermore, the command 'help' invoked from
  within GDB activates a simple help facility which summarizes the
  available commands and their options.  In this section we summarize a
  few of the most commonly used commands to give an idea of what ‘GDB’ is
*************** you read through the following section.
*** 13023,13029 ****
     * 
       ‘set args ARGUMENTS’
  
!           The ‘arguments’ list above is a list of arguments to be passed
            to the program on a subsequent run command, just as though the
            arguments had been entered on a normal invocation of the
            program.  The ‘set args’ command is not needed if the program
--- 13023,13029 ----
     * 
       ‘set args ARGUMENTS’
  
!           The 'arguments' list above is a list of arguments to be passed
            to the program on a subsequent run command, just as though the
            arguments had been entered on a normal invocation of the
            program.  The ‘set args’ command is not needed if the program
*************** you read through the following section.
*** 13043,13049 ****
  
            The breakpoint command sets a breakpoint, that is to say a
            point at which execution will halt and ‘GDB’ will await
!           further commands.  ‘location’ is either a line number within a
            file, given in the format ‘file:linenumber’, or it is the name
            of a subprogram.  If you request that a breakpoint be set on a
            subprogram that is overloaded, a prompt will ask you to
--- 13043,13049 ----
  
            The breakpoint command sets a breakpoint, that is to say a
            point at which execution will halt and ‘GDB’ will await
!           further commands.  'location' is either a line number within a
            file, given in the format ‘file:linenumber’, or it is the name
            of a subprogram.  If you request that a breakpoint be set on a
            subprogram that is overloaded, a prompt will ask you to
*************** procedure that prints the elements in th
*** 13242,13248 ****
  
  File: gnat_ugn.info,  Node: Using the next Command in a Function,  Next: Stopping When Ada Exceptions Are Raised,  Prev: Calling User-Defined Subprograms,  Up: Running and Debugging Ada Programs
  
! 6.1.6 Using the ‘next’ Command in a Function
  --------------------------------------------
  
  When you use the ‘next’ command in a function, the current source
--- 13242,13248 ----
  
  File: gnat_ugn.info,  Node: Using the next Command in a Function,  Next: Stopping When Ada Exceptions Are Raised,  Prev: Calling User-Defined Subprograms,  Up: Running and Debugging Ada Programs
  
! 6.1.6 Using the 'next' Command in a Function
  --------------------------------------------
  
  When you use the ‘next’ command in a function, the current source
*************** program raises selected exceptions.
*** 13282,13288 ****
       ‘catch exception NAME’
  
            Set a catchpoint that stops execution whenever (any task in
!           the) program raises the exception ‘name’.
  
     * 
       ‘catch exception unhandled’
--- 13282,13288 ----
       ‘catch exception NAME’
  
            Set a catchpoint that stops execution whenever (any task in
!           the) program raises the exception 'name'.
  
     * 
       ‘catch exception unhandled’
*************** program raises selected exceptions.
*** 13296,13303 ****
  
            The ‘info exceptions’ command permits the user to examine all
            defined exceptions within Ada programs.  With a regular
!           expression, ‘regexp’, as argument, prints out only those
!           exceptions whose name matches ‘regexp’.
  
  
  File: gnat_ugn.info,  Node: Ada Tasks,  Next: Debugging Generic Units,  Prev: Stopping When Ada Exceptions Are Raised,  Up: Running and Debugging Ada Programs
--- 13296,13303 ----
  
            The ‘info exceptions’ command permits the user to examine all
            defined exceptions within Ada programs.  With a regular
!           expression, 'regexp', as argument, prints out only those
!           exceptions whose name matches 'regexp'.
  
  
  File: gnat_ugn.info,  Node: Ada Tasks,  Next: Debugging Generic Units,  Prev: Stopping When Ada Exceptions Are Raised,  Up: Running and Debugging Ada Programs
*************** File: gnat_ugn.info,  Node: Ada Tasks,
*** 13325,13344 ****
            the task ID that is used to refer to tasks in the following
            commands.
  
!    * ‘break’ ‘linespec’ ‘task’ ‘taskid’, ‘break’ ‘linespec’ ‘task’
!      ‘taskid’ ‘if’ …
  
            These commands are like the ‘break ... thread ...’.
!           ‘linespec’ specifies source lines.
  
            Use the qualifier ‘task TASKID’ with a breakpoint command to
            specify that you only want ‘GDB’ to stop the program when a
!           particular Ada task reaches this breakpoint.  ‘taskid’ is one
            of the numeric task identifiers assigned by ‘GDB’, shown in
            the first column of the ‘info tasks’ display.
  
            If you do not specify ‘task TASKID’ when you set a breakpoint,
!           the breakpoint applies to ‘all’ tasks of your program.
  
            You can use the ‘task’ qualifier on conditional breakpoints as
            well; in this case, place ‘task TASKID’ before the breakpoint
--- 13325,13344 ----
            the task ID that is used to refer to tasks in the following
            commands.
  
!    * ‘break’ 'linespec' ‘task’ 'taskid', ‘break’ 'linespec' ‘task’
!      'taskid' ‘if’ …
  
            These commands are like the ‘break ... thread ...’.
!           'linespec' specifies source lines.
  
            Use the qualifier ‘task TASKID’ with a breakpoint command to
            specify that you only want ‘GDB’ to stop the program when a
!           particular Ada task reaches this breakpoint.  'taskid' is one
            of the numeric task identifiers assigned by ‘GDB’, shown in
            the first column of the ‘info tasks’ display.
  
            If you do not specify ‘task TASKID’ when you set a breakpoint,
!           the breakpoint applies to 'all' tasks of your program.
  
            You can use the ‘task’ qualifier on conditional breakpoints as
            well; in this case, place ‘task TASKID’ before the breakpoint
*************** File: gnat_ugn.info,  Node: Ada Tasks,
*** 13347,13353 ****
     * ‘task TASKNO’
  
            This command allows switching to the task referred by
!           ‘taskno’.  In particular, this allows browsing of the
            backtrace of the specified task.  It is advisable to switch
            back to the original task before continuing execution
            otherwise the scheduling of the program may be perturbed.
--- 13347,13353 ----
     * ‘task TASKNO’
  
            This command allows switching to the task referred by
!           'taskno'.  In particular, this allows browsing of the
            backtrace of the specified task.  It is advisable to switch
            back to the original task before continuing execution
            otherwise the scheduling of the program may be perturbed.
*************** It is also possible to use gdbserver to
*** 13446,13453 ****
  program, in which case the execution of that program is simply suspended
  until the connection between the debugger and gdbserver is established.
  
! For more information on how to use gdbserver, see the ‘Using the
! gdbserver Program’ section in ‘Debugging with GDB’. GNAT provides
  support for gdbserver on x86-linux, x86-windows and x86_64-linux.
  
  
--- 13446,13453 ----
  program, in which case the execution of that program is simply suspended
  until the connection between the debugger and gdbserver is established.
  
! For more information on how to use gdbserver, see the 'Using the
! gdbserver Program' section in ‘Debugging with GDB’. GNAT provides
  support for gdbserver on x86-linux, x86-windows and x86_64-linux.
  
  
*************** File: gnat_ugn.info,  Node: Stack Traceb
*** 13587,13593 ****
  Traceback is a mechanism to display the sequence of subprogram calls
  that leads to a specified execution point in a program.  Often (but not
  always) the execution point is an instruction at which an exception has
! been raised.  This mechanism is also known as ‘stack unwinding’ because
  it obtains its information by scanning the run-time stack and recovering
  the activation records of all active subprograms.  Stack unwinding is
  one of the most important tools for program debugging.
--- 13587,13593 ----
  Traceback is a mechanism to display the sequence of subprogram calls
  that leads to a specified execution point in a program.  Often (but not
  always) the execution point is an instruction at which an exception has
! been raised.  This mechanism is also known as 'stack unwinding' because
  it obtains its information by scanning the run-time stack and recovering
  the activation records of all active subprograms.  Stack unwinding is
  one of the most important tools for program debugging.
*************** invoked with its ‘/r’ option:
*** 14051,14057 ****
            $1 = (
              tree => (...
  
! Finer control of pretty-printers is also possible: see GDB’s online
  documentation(2) for more information.
  
     ---------- Footnotes ----------
--- 14051,14057 ----
            $1 = (
              tree => (...
  
! Finer control of pretty-printers is also possible: see GDB's online
  documentation(2) for more information.
  
     ---------- Footnotes ----------
*************** experiment to find the best level for yo
*** 14445,14459 ****
  
  Since the precise set of optimizations done at each level will vary from
  release to release (and sometime from target to target), it is best to
! think of the optimization settings in general terms.  See the ‘Options
! That Control Optimization’ section in ‘Using the GNU Compiler Collection
  (GCC)’ for details about the ‘-O’ settings and a number of ‘-f’ options
  that individually enable or disable specific optimizations.
  
  Unlike some other compilation systems, ‘gcc’ has been tested extensively
  at all optimization levels.  There are some bugs which appear only with
  optimization turned on, but there have also been bugs which show up only
! in ‘unoptimized’ code.  Selecting a lower level of optimization does not
  improve the reliability of the code generator, which in practice is
  highly reliable at all optimization levels.
  
--- 14445,14459 ----
  
  Since the precise set of optimizations done at each level will vary from
  release to release (and sometime from target to target), it is best to
! think of the optimization settings in general terms.  See the 'Options
! That Control Optimization' section in ‘Using the GNU Compiler Collection
  (GCC)’ for details about the ‘-O’ settings and a number of ‘-f’ options
  that individually enable or disable specific optimizations.
  
  Unlike some other compilation systems, ‘gcc’ has been tested extensively
  at all optimization levels.  There are some bugs which appear only with
  optimization turned on, but there have also been bugs which show up only
! in 'unoptimized' code.  Selecting a lower level of optimization does not
  improve the reliability of the code generator, which in practice is
  highly reliable at all optimization levels.
  
*************** invalidate some of the debugging data.
*** 14487,14505 ****
  certain anomalous situations that may arise while debugging optimized
  code.  These are the most common cases:
  
!    * ‘The ‘hopping Program Counter’:’ Repeated ‘step’ or ‘next’ commands
       show the PC bouncing back and forth in the code.  This may result
       from any of the following optimizations:
  
!         - ‘Common subexpression elimination:’ using a single instance of
            code for a quantity that the source computes several times.
            As a result you may not be able to stop on what looks like a
            statement.
  
!         - ‘Invariant code motion:’ moving an expression that does not
            change within a loop, to the beginning of the loop.
  
!         - ‘Instruction scheduling:’ moving instructions so as to overlap
            loads and stores (typically) with other code, or in general to
            move computations of values closer to their uses.  Often this
            causes you to pass an assignment statement without the
--- 14487,14505 ----
  certain anomalous situations that may arise while debugging optimized
  code.  These are the most common cases:
  
!    * 'The ‘hopping Program Counter’:' Repeated ‘step’ or ‘next’ commands
       show the PC bouncing back and forth in the code.  This may result
       from any of the following optimizations:
  
!         - 'Common subexpression elimination:' using a single instance of
            code for a quantity that the source computes several times.
            As a result you may not be able to stop on what looks like a
            statement.
  
!         - 'Invariant code motion:' moving an expression that does not
            change within a loop, to the beginning of the loop.
  
!         - 'Instruction scheduling:' moving instructions so as to overlap
            loads and stores (typically) with other code, or in general to
            move computations of values closer to their uses.  Often this
            causes you to pass an assignment statement without the
*************** code.  These are the most common cases:
*** 14508,14522 ****
            breakpoint on a line of code and then stepping over it may,
            therefore, not always cause all the expected side-effects.
  
!    * ‘The ‘big leap’:’ More commonly known as ‘cross-jumping’, in which
       two identical pieces of code are merged and the program counter
       suddenly jumps to a statement that is not supposed to be executed,
       simply because it (and the code following) translates to the same
!      thing as the code that ‘was’ supposed to be executed.  This effect
       is typically seen in sequences that end in a jump, such as a
       ‘goto’, a ‘return’, or a ‘break’ in a C ‘switch’ statement.
  
!    * ‘The ‘roving variable’:’ The symptom is an unexpected value in a
       variable.  There are various reasons for this effect:
  
          - In a subprogram prologue, a parameter may not yet have been
--- 14508,14522 ----
            breakpoint on a line of code and then stepping over it may,
            therefore, not always cause all the expected side-effects.
  
!    * 'The ‘big leap’:' More commonly known as 'cross-jumping', in which
       two identical pieces of code are merged and the program counter
       suddenly jumps to a statement that is not supposed to be executed,
       simply because it (and the code following) translates to the same
!      thing as the code that 'was' supposed to be executed.  This effect
       is typically seen in sequences that end in a jump, such as a
       ‘goto’, a ‘return’, or a ‘break’ in a C ‘switch’ statement.
  
!    * 'The ‘roving variable’:' The symptom is an unexpected value in a
       variable.  There are various reasons for this effect:
  
          - In a subprogram prologue, a parameter may not yet have been
*************** code.  These are the most common cases:
*** 14544,14550 ****
       those other values); or re-running the code and stopping a little
       earlier (perhaps before the call) and stepping to better see how
       the variable obtained the value in question; or continuing to step
!      ‘from’ the point of the strange value to see if code motion had
       simply moved the variable’s assignments later.
  
  In light of such anomalies, a recommended technique is to use ‘-O0’
--- 14544,14550 ----
       those other values); or re-running the code and stopping a little
       earlier (perhaps before the call) and stepping to better see how
       the variable obtained the value in question; or continuing to step
!      'from' the point of the strange value to see if code motion had
       simply moved the variable’s assignments later.
  
  In light of such anomalies, a recommended technique is to use ‘-O0’
*************** following conditions are met:
*** 14575,14581 ****
       from within it; the subprogram is small and optimization level
       ‘-O2’ is specified; optimization level ‘-O3’ is specified.
  
! Calls to subprograms in ‘with’ed units are normally not inlined.  To
  achieve actual inlining (that is, replacement of the call by the code in
  the body of the subprogram), the following conditions must all be true:
  
--- 14575,14581 ----
       from within it; the subprogram is small and optimization level
       ‘-O2’ is specified; optimization level ‘-O3’ is specified.
  
! Calls to subprograms in 'with'ed units are normally not inlined.  To
  achieve actual inlining (that is, replacement of the call by the code in
  the body of the subprogram), the following conditions must all be true:
  
*************** Examples of switches in this category ar
*** 14832,14838 ****
  various target-specific ‘-m’ options (in particular, it has been
  observed that ‘-march=xxx’ can significantly improve performance on
  appropriate machines).  For full details of these switches, see the
! ‘Submodel Options’ section in the ‘Hardware Models and Configurations’
  chapter of ‘Using the GNU Compiler Collection (GCC)’.
  
  
--- 14832,14838 ----
  various target-specific ‘-m’ options (in particular, it has been
  observed that ‘-march=xxx’ can significantly improve performance on
  appropriate machines).  For full details of these switches, see the
! 'Submodel Options' section in the 'Hardware Models and Configurations'
  chapter of ‘Using the GNU Compiler Collection (GCC)’.
  
  
*************** If ‘Text_IO’ must be used, note that
*** 15207,15213 ****
  output and standard error files is unbuffered (this provides better
  behavior when output statements are used for debugging, or if the
  progress of a program is observed by tracking the output, e.g.  by using
! the Unix ‘tail -f’ command to watch redirected output).
  
  If you are generating large volumes of output with ‘Text_IO’ and
  performance is an important factor, use a designated file instead of the
--- 15207,15213 ----
  output and standard error files is unbuffered (this provides better
  behavior when output statements are used for debugging, or if the
  progress of a program is observed by tracking the output, e.g.  by using
! the Unix 'tail -f' command to watch redirected output).
  
  If you are generating large volumes of output with ‘Text_IO’ and
  performance is an important factor, use a designated file instead of the
*************** outside assertions.
*** 15463,15469 ****
  
  The three modes are:
  
!    * ‘Use base type for intermediate operations’ (‘STRICT’)
  
       In this mode, all intermediate results for predefined arithmetic
       operators are computed using the base type, and the result must be
--- 15463,15469 ----
  
  The three modes are:
  
!    * 'Use base type for intermediate operations' (‘STRICT’)
  
       In this mode, all intermediate results for predefined arithmetic
       operators are computed using the base type, and the result must be
*************** The three modes are:
*** 15472,15478 ****
       execution is erroneous (if overflow checks are suppressed).  This
       is the normal default mode.
  
!    * ‘Most intermediate overflows avoided’ (‘MINIMIZED’)
  
       In this mode, the compiler attempts to avoid intermediate overflows
       by using a larger integer type, typically ‘Long_Long_Integer’, as
--- 15472,15478 ----
       execution is erroneous (if overflow checks are suppressed).  This
       is the normal default mode.
  
!    * 'Most intermediate overflows avoided' (‘MINIMIZED’)
  
       In this mode, the compiler attempts to avoid intermediate overflows
       by using a larger integer type, typically ‘Long_Long_Integer’, as
*************** The three modes are:
*** 15498,15508 ****
       final result is in range and the precondition is True (from a
       mathematical point of view).  In such a case, operating in this
       mode, an overflow occurs for the intermediate computation (which is
!      why this mode says ‘most’ intermediate overflows are avoided).  In
       this case, an exception is raised if overflow checks are enabled,
       and the execution is erroneous if overflow checks are suppressed.
  
!    * ‘All intermediate overflows avoided’ (‘ELIMINATED’)
  
       In this mode, the compiler avoids all intermediate overflows by
       using arbitrary precision arithmetic as required.  In this mode,
--- 15498,15508 ----
       final result is in range and the precondition is True (from a
       mathematical point of view).  In such a case, operating in this
       mode, an overflow occurs for the intermediate computation (which is
!      why this mode says 'most' intermediate overflows are avoided).  In
       this case, an exception is raised if overflow checks are enabled,
       and the execution is erroneous if overflow checks are suppressed.
  
!    * 'All intermediate overflows avoided' (‘ELIMINATED’)
  
       In this mode, the compiler avoids all intermediate overflows by
       using arbitrary precision arithmetic as required.  In this mode,
*************** from version 7.0.1 of GNAT onwards.  The
*** 15713,15720 ****
  ‘Dimension_System’ allows you to define a system of units; the aspect
  ‘Dimension’ then allows the user to declare dimensioned quantities
  within a given system.  (These aspects are described in the
! ‘Implementation Defined Aspects’ chapter of the ‘GNAT Reference
! Manual’).
  
  The major advantage of this model is that it does not require the
  declaration of multiple operators for all possible combinations of
--- 15713,15720 ----
  ‘Dimension_System’ allows you to define a system of units; the aspect
  ‘Dimension’ then allows the user to declare dimensioned quantities
  within a given system.  (These aspects are described in the
! 'Implementation Defined Aspects' chapter of the 'GNAT Reference
! Manual').
  
  The major advantage of this model is that it does not require the
  declaration of multiple operators for all possible combinations of
*************** then the output includes:
*** 15843,15857 ****
  
            Final velocity: 98.10 m.s**(-1)
  
! The type ‘Mks_Type’ is said to be a ‘dimensionable type’ since it has a
  ‘Dimension_System’ aspect, and the subtypes ‘Length’, ‘Mass’, etc., are
! said to be ‘dimensioned subtypes’ since each one has a ‘Dimension’
  aspect.
  
  The ‘Dimension’ aspect of a dimensioned subtype ‘S’ defines a mapping
  from the base type’s Unit_Names to integer (or, more generally,
! rational) values.  This mapping is the ‘dimension vector’ (also referred
! to as the ‘dimensionality’) for that subtype, denoted by ‘DV(S)’, and
  thus for each object of that subtype.  Intuitively, the value specified
  for each ‘Unit_Name’ is the exponent associated with that unit; a zero
  value means that the unit is not used.  For example:
--- 15843,15857 ----
  
            Final velocity: 98.10 m.s**(-1)
  
! The type ‘Mks_Type’ is said to be a 'dimensionable type' since it has a
  ‘Dimension_System’ aspect, and the subtypes ‘Length’, ‘Mass’, etc., are
! said to be 'dimensioned subtypes' since each one has a ‘Dimension’
  aspect.
  
  The ‘Dimension’ aspect of a dimensioned subtype ‘S’ defines a mapping
  from the base type’s Unit_Names to integer (or, more generally,
! rational) values.  This mapping is the 'dimension vector' (also referred
! to as the 'dimensionality') for that subtype, denoted by ‘DV(S)’, and
  thus for each object of that subtype.  Intuitively, the value specified
  for each ‘Unit_Name’ is the exponent associated with that unit; a zero
  value means that the unit is not used.  For example:
*************** dimension vectors of its components, wit
*** 15872,15897 ****
  checks that help prevent mismatches such as using an ‘Acceleration’
  where a ‘Length’ is required.
  
! The dimension vector of the result of an arithmetic expression ‘expr’,
  or ‘DV(EXPR)’, is defined as follows, assuming conventional mathematical
  definitions for the vector operations that are used:
  
!    * If ‘expr’ is of the type ‘universal_real’, or is not of a
!      dimensioned subtype, then ‘expr’ is dimensionless; ‘DV(EXPR)’ is
       the empty vector.
  
!    * ‘DV(OP EXPR)’, where ‘op’ is a unary operator, is ‘DV(EXPR)’
  
!    * ‘DV(EXPR1 OP EXPR2)’ where ‘op’ is “+” or “-” is ‘DV(EXPR1)’
       provided that ‘DV(EXPR1)’ = ‘DV(EXPR2)’.  If this condition is not
       met then the construct is illegal.
  
     * ‘DV(EXPR1 * EXPR2)’ is ‘DV(EXPR1)’ + ‘DV(EXPR2)’, and ‘DV(EXPR1 /
       EXPR2)’ = ‘DV(EXPR1)’ - ‘DV(EXPR2)’.  In this context if one of the
!      ‘expr’s is dimensionless then its empty dimension vector is treated
       as ‘(others => 0)’.
  
!    * ‘DV(EXPR ** POWER)’ is ‘power’ * ‘DV(EXPR)’, provided that ‘power’
       is a static rational value.  If this condition is not met then the
       construct is illegal.
  
--- 15872,15897 ----
  checks that help prevent mismatches such as using an ‘Acceleration’
  where a ‘Length’ is required.
  
! The dimension vector of the result of an arithmetic expression 'expr',
  or ‘DV(EXPR)’, is defined as follows, assuming conventional mathematical
  definitions for the vector operations that are used:
  
!    * If 'expr' is of the type 'universal_real', or is not of a
!      dimensioned subtype, then 'expr' is dimensionless; ‘DV(EXPR)’ is
       the empty vector.
  
!    * ‘DV(OP EXPR)’, where 'op' is a unary operator, is ‘DV(EXPR)’
  
!    * ‘DV(EXPR1 OP EXPR2)’ where 'op' is “+” or “-” is ‘DV(EXPR1)’
       provided that ‘DV(EXPR1)’ = ‘DV(EXPR2)’.  If this condition is not
       met then the construct is illegal.
  
     * ‘DV(EXPR1 * EXPR2)’ is ‘DV(EXPR1)’ + ‘DV(EXPR2)’, and ‘DV(EXPR1 /
       EXPR2)’ = ‘DV(EXPR1)’ - ‘DV(EXPR2)’.  In this context if one of the
!      'expr's is dimensionless then its empty dimension vector is treated
       as ‘(others => 0)’.
  
!    * ‘DV(EXPR ** POWER)’ is 'power' * ‘DV(EXPR)’, provided that 'power'
       is a static rational value.  If this condition is not met then the
       construct is illegal.
  
*************** The dimension vector of a type conversio
*** 15921,15928 ****
  follows, based on the nature of ‘T’:
  
     * If ‘T’ is a dimensioned subtype then ‘DV(T(EXPR))’ is ‘DV(T)’
!      provided that either ‘expr’ is dimensionless or ‘DV(T)’ =
!      ‘DV(EXPR)’.  The conversion is illegal if ‘expr’ is dimensioned and
       ‘DV(EXPR)’ /= ‘DV(T)’.  Note that vector equality does not require
       that the corresponding Unit_Names be the same.
  
--- 15921,15928 ----
  follows, based on the nature of ‘T’:
  
     * If ‘T’ is a dimensioned subtype then ‘DV(T(EXPR))’ is ‘DV(T)’
!      provided that either 'expr' is dimensionless or ‘DV(T)’ =
!      ‘DV(EXPR)’.  The conversion is illegal if 'expr' is dimensioned and
       ‘DV(EXPR)’ /= ‘DV(T)’.  Note that vector equality does not require
       that the corresponding Unit_Names be the same.
  
*************** follows, based on the nature of ‘T’:
*** 15934,15942 ****
       suitable conversion factor) but cannot be converted, for example,
       to a mass in pounds.
  
!    * If ‘T’ is the base type for ‘expr’ (and the dimensionless root type
       of the dimension system), then ‘DV(T(EXPR))’ is ‘DV(expr)’.  Thus,
!      if ‘expr’ is of a dimensioned subtype of ‘T’, the conversion may be
       regarded as a “view conversion” that preserves dimensionality.
  
       This rule makes it possible to write generic code that can be
--- 15934,15942 ----
       suitable conversion factor) but cannot be converted, for example,
       to a mass in pounds.
  
!    * If ‘T’ is the base type for 'expr' (and the dimensionless root type
       of the dimension system), then ‘DV(T(EXPR))’ is ‘DV(expr)’.  Thus,
!      if 'expr' is of a dimensioned subtype of ‘T’, the conversion may be
       regarded as a “view conversion” that preserves dimensionality.
  
       This rule makes it possible to write generic code that can be
*************** displayed in four columns:
*** 16083,16095 ****
  
  where:
  
!    * ‘Index’ is a number associated with each task.
  
!    * ‘Task Name’ is the name of the task analyzed.
  
!    * ‘Stack Size’ is the maximum size for the stack.
  
!    * ‘Stack Usage’ is the measure done by the stack analyzer.  In order
       to prevent overflow, the stack is not entirely analyzed, and it’s
       not possible to know exactly how much has actually been used.
  
--- 16083,16095 ----
  
  where:
  
!    * 'Index' is a number associated with each task.
  
!    * 'Task Name' is the name of the task analyzed.
  
!    * 'Stack Size' is the maximum size for the stack.
  
!    * 'Stack Usage' is the measure done by the stack analyzer.  In order
       to prevent overflow, the stack is not entirely analyzed, and it’s
       not possible to know exactly how much has actually been used.
  
*************** the underlying operating system.
*** 16350,16359 ****
  
  For exception handling, either or both of two models are supplied:
  
!    * ‘Zero-Cost Exceptions’ (“ZCX”), which uses binder-generated tables
       that are interrogated at run time to locate a handler.
  
!    * ‘setjmp / longjmp’ (‘SJLJ’), which uses dynamically-set data to
       establish the set of handlers
  
  Most programs should experience a substantial speed improvement by being
--- 16350,16359 ----
  
  For exception handling, either or both of two models are supplied:
  
!    * 'Zero-Cost Exceptions' (“ZCX”), which uses binder-generated tables
       that are interrogated at run time to locate a handler.
  
!    * 'setjmp / longjmp' (‘SJLJ’), which uses dynamically-set data to
       establish the set of handlers
  
  Most programs should experience a substantial speed improvement by being
*************** and contain a complete source and binary
*** 16419,16425 ****
  description below explains the differences between the different
  libraries in terms of their thread support.
  
! The default run-time library (when GNAT is installed) is ‘rts-native’.
  This default run-time is selected by the means of soft links.  For
  example on x86-linux:
  
--- 16419,16425 ----
  description below explains the differences between the different
  libraries in terms of their thread support.
  
! The default run-time library (when GNAT is installed) is 'rts-native'.
  This default run-time is selected by the means of soft links.  For
  example on x86-linux:
  
*************** example on x86-linux:
*** 16441,16447 ****
                     Run-Time Library Directory Structure
          (Upper-case names and dotted/dashed arrows represent soft links)
  
! If the ‘rts-sjlj’ library is to be selected on a permanent basis, these
  soft links can be modified with the following commands:
  
            $ cd $target
--- 16441,16447 ----
                     Run-Time Library Directory Structure
          (Upper-case names and dotted/dashed arrows represent soft links)
  
! If the 'rts-sjlj' library is to be selected on a permanent basis, these
  soft links can be modified with the following commands:
  
            $ cd $target
*************** suffix) has the following structure:
*** 17220,17235 ****
               ``symbol2``
               ...
  
! ‘LIBRARY name’
  
       This section, which is optional, gives the name of the DLL.
  
! ‘DESCRIPTION string’
  
       This section, which is optional, gives a description string that
       will be embedded in the import library.
  
! ‘EXPORTS’
  
       This section gives the list of exported symbols (procedures,
       functions or variables).  For instance in the case of ‘API.dll’ the
--- 17220,17235 ----
               ``symbol2``
               ...
  
! 'LIBRARY name'
  
       This section, which is optional, gives the name of the DLL.
  
! 'DESCRIPTION string'
  
       This section, which is optional, gives a description string that
       will be embedded in the import library.
  
! 'EXPORTS'
  
       This section gives the list of exported symbols (procedures,
       functions or variables).  For instance in the case of ‘API.dll’ the
*************** File: gnat_ugn.info,  Node: Building DLL
*** 17320,17327 ****
  ..............................................
  
  There is nothing specific to Windows in the build process.  See the
! ‘Library Projects’ section in the ‘GNAT Project Manager’ chapter of the
! ‘GPRbuild User’s Guide’.
  
  Due to a system limitation, it is not possible under Windows to create
  threads when inside the ‘DllMain’ routine which is used for
--- 17320,17327 ----
  ..............................................
  
  There is nothing specific to Windows in the build process.  See the
! 'Library Projects' section in the 'GNAT Project Manager' chapter of the
! 'GPRbuild User’s Guide'.
  
  Due to a system limitation, it is not possible under Windows to create
  threads when inside the ‘DllMain’ routine which is used for
*************** as non-Ada applications are as follows:
*** 17427,17435 ****
  Note that a relocatable DLL stripped using the ‘strip’ binutils tool
  will not be relocatable anymore.  To build a DLL without debug
  information pass ‘-largs -s’ to ‘gnatdll’.  This restriction does not
! apply to a DLL built using a Library Project.  See the ‘Library
! Projects’ section in the ‘GNAT Project Manager’ chapter of the ‘GPRbuild
! User’s Guide’.
  
  * Menu:
  
--- 17427,17435 ----
  Note that a relocatable DLL stripped using the ‘strip’ binutils tool
  will not be relocatable anymore.  To build a DLL without debug
  information pass ‘-largs -s’ to ‘gnatdll’.  This restriction does not
! apply to a DLL built using a Library Project.  See the 'Library
! Projects' section in the 'GNAT Project Manager' chapter of the 'GPRbuild
! User’s Guide'.
  
  * Menu:
  
*************** switch).  Here are the step-by-step inst
*** 18114,18120 ****
            (gdb) start
  
       This step is required to be able to set a breakpoint inside the
!      DLL. As long as the program is not run, the DLL is not loaded.
       This has the consequence that the DLL debugging information is also
       not loaded, so it is not possible to set a breakpoint in the DLL.
  
--- 18114,18120 ----
            (gdb) start
  
       This step is required to be able to set a breakpoint inside the
!      DLL.  As long as the program is not run, the DLL is not loaded.
       This has the consequence that the DLL debugging information is also
       not loaded, so it is not possible to set a breakpoint in the DLL.
  
*************** in the code of the DLL to meet this crit
*** 18208,18214 ****
  
            $ main
  
!    * Use the Windows ‘Task Manager’ to find the process ID. Let’s say
       that the process PID for ‘main.exe’ is 208.
  
     * Launch gdb.
--- 18208,18214 ----
  
            $ main
  
!    * Use the Windows 'Task Manager' to find the process ID. Let’s say
       that the process PID for ‘main.exe’ is 208.
  
     * Launch gdb.
*************** File: gnat_ugn.info,  Node: Setting Stac
*** 18245,18251 ****
  It is possible to specify the program stack size at link time.  On
  modern versions of Windows, starting with XP, this is mostly useful to
  set the size of the main stack (environment task).  The other task
! stacks are set with pragma Storage_Size or with the ‘gnatbind -d’
  command.
  
  Since older versions of Windows (2000, NT4, etc.)  do not allow setting
--- 18245,18251 ----
  It is possible to specify the program stack size at link time.  On
  modern versions of Windows, starting with XP, this is mostly useful to
  set the size of the main stack (environment task).  The other task
! stacks are set with pragma Storage_Size or with the 'gnatbind -d'
  command.
  
  Since older versions of Windows (2000, NT4, etc.)  do not allow setting
*************** File: gnat_ugn.info,  Node: Example of B
*** 18429,18435 ****
  *******************************
  
  This Appendix displays the source code for the output file generated by
! ‘gnatbind’ for a simple ‘Hello World’ program.  Comments have been added
  for clarification purposes.
  
       --  The package is called Ada_Main unless this name is actually used
--- 18429,18435 ----
  *******************************
  
  This Appendix displays the source code for the output file generated by
! 'gnatbind' for a simple ‘Hello World’ program.  Comments have been added
  for clarification purposes.
  
       --  The package is called Ada_Main unless this name is actually used
*************** File: gnat_ugn.info,  Node: Elaboration
*** 19195,19208 ****
  9.1 Elaboration Code
  ====================
  
! Ada defines the term ‘execution’ as the process by which a construct
  achieves its run-time effect.  This process is also referred to as
! ‘elaboration’ for declarations and ‘evaluation’ for expressions.
  
  The execution model in Ada allows for certain sections of an Ada program
  to be executed prior to execution of the program itself, primarily with
  the intent of initializing data.  These sections are referred to as
! ‘elaboration code’.  Elaboration code is executed as follows:
  
     * All partitions of an Ada program are executed in parallel with one
       another, possibly in a separate address space, and possibly on a
--- 19195,19208 ----
  9.1 Elaboration Code
  ====================
  
! Ada defines the term 'execution' as the process by which a construct
  achieves its run-time effect.  This process is also referred to as
! 'elaboration' for declarations and 'evaluation' for expressions.
  
  The execution model in Ada allows for certain sections of an Ada program
  to be executed prior to execution of the program itself, primarily with
  the intent of initializing data.  These sections are referred to as
! 'elaboration code'.  Elaboration code is executed as follows:
  
     * All partitions of an Ada program are executed in parallel with one
       another, possibly in a separate address space, and possibly on a
*************** the intent of initializing data.  These
*** 19213,19219 ****
  
     * The environment task executes all elaboration code (if available)
       for all units within that partition.  This code is said to be
!      executed at ‘elaboration time’.
  
     * The environment task executes the Ada program (if available) for
       that partition.
--- 19213,19219 ----
  
     * The environment task executes all elaboration code (if available)
       for all units within that partition.  This code is said to be
!      executed at 'elaboration time'.
  
     * The environment task executes the Ada program (if available) for
       that partition.
*************** the intent of initializing data.  These
*** 19221,19235 ****
  In addition to the Ada terminology, this appendix defines the following
  terms:
  
!    * ‘Invocation’
  
       The act of calling a subprogram, instantiating a generic, or
       activating a task.
  
!    * ‘Scenario’
  
       A construct that is elaborated or invoked by elaboration code is
!      referred to as an ‘elaboration scenario’ or simply a ‘scenario’.
       GNAT recognizes the following scenarios:
  
          - ‘'Access’ of entries, operators, and subprograms
--- 19221,19235 ----
  In addition to the Ada terminology, this appendix defines the following
  terms:
  
!    * 'Invocation'
  
       The act of calling a subprogram, instantiating a generic, or
       activating a task.
  
!    * 'Scenario'
  
       A construct that is elaborated or invoked by elaboration code is
!      referred to as an 'elaboration scenario' or simply a 'scenario'.
       GNAT recognizes the following scenarios:
  
          - ‘'Access’ of entries, operators, and subprograms
*************** terms:
*** 19240,19249 ****
  
          - Instantiations of generic templates
  
!    * ‘Target’
  
!      A construct elaborated by a scenario is referred to as ‘elaboration
!      target’ or simply ‘target’.  GNAT recognizes the following targets:
  
          - For ‘'Access’ of entries, operators, and subprograms, the
            target is the entry, operator, or subprogram being aliased.
--- 19240,19249 ----
  
          - Instantiations of generic templates
  
!    * 'Target'
  
!      A construct elaborated by a scenario is referred to as 'elaboration
!      target' or simply 'target'.  GNAT recognizes the following targets:
  
          - For ‘'Access’ of entries, operators, and subprograms, the
            target is the entry, operator, or subprogram being aliased.
*************** terms:
*** 19258,19264 ****
  
  Elaboration code may appear in two distinct contexts:
  
!    * ‘Library level’
  
       A scenario appears at the library level when it is encapsulated by
       a package [body] compilation unit, ignoring any other package
--- 19258,19264 ----
  
  Elaboration code may appear in two distinct contexts:
  
!    * 'Library level'
  
       A scenario appears at the library level when it is encapsulated by
       a package [body] compilation unit, ignoring any other package
*************** Elaboration code may appear in two disti
*** 19280,19286 ****
       ‘Server.Func’ will be invoked when the spec of unit ‘Client’ is
       elaborated.
  
!    * ‘Package body statements’
  
       A scenario appears within the statement sequence of a package body
       when it is bounded by the region starting from the ‘begin’ keyword
--- 19280,19286 ----
       ‘Server.Func’ will be invoked when the spec of unit ‘Client’ is
       elaborated.
  
!    * 'Package body statements'
  
       A scenario appears within the statement sequence of a package body
       when it is bounded by the region starting from the ‘begin’ keyword
*************** File: gnat_ugn.info,  Node: Elaboration
*** 19308,19314 ****
  =====================
  
  The sequence by which the elaboration code of all units within a
! partition is executed is referred to as ‘elaboration order’.
  
  Within a single unit, elaboration code is executed in sequential order.
  
--- 19308,19314 ----
  =====================
  
  The sequence by which the elaboration code of all units within a
! partition is executed is referred to as 'elaboration order'.
  
  Within a single unit, elaboration code is executed in sequential order.
  
*************** is as follows:
*** 19344,19350 ****
  The elaboration order of all units within a partition depends on the
  following factors:
  
!    * ‘with’ed units
  
     * parent units
  
--- 19344,19350 ----
  The elaboration order of all units within a partition depends on the
  following factors:
  
!    * 'with'ed units
  
     * parent units
  
*************** structure.
*** 19381,19387 ****
            procedure Main is begin null; end Main;
  
  The following elaboration order exhibits a fundamental problem referred
! to as ‘access-before-elaboration’ or simply ‘ABE’.
  
            spec of Server
            spec of Client
--- 19381,19387 ----
            procedure Main is begin null; end Main;
  
  The following elaboration order exhibits a fundamental problem referred
! to as 'access-before-elaboration' or simply 'ABE'.
  
            spec of Server
            spec of Client
*************** can be successfully elaborated.
*** 19412,19418 ****
  Ada states that a total elaboration order must exist, but it does not
  define what this order is.  A compiler is thus tasked with choosing a
  suitable elaboration order which satisfies the dependencies imposed by
! ‘with’ clauses, unit categorization, elaboration-control pragmas, and
  invocations performed in elaboration code.  Ideally an order that avoids
  ABE problems should be chosen, however a compiler may not always find
  such an order due to complications with respect to control and data
--- 19412,19418 ----
  Ada states that a total elaboration order must exist, but it does not
  define what this order is.  A compiler is thus tasked with choosing a
  suitable elaboration order which satisfies the dependencies imposed by
! 'with' clauses, unit categorization, elaboration-control pragmas, and
  invocations performed in elaboration code.  Ideally an order that avoids
  ABE problems should be chosen, however a compiler may not always find
  such an order due to complications with respect to control and data
*************** File: gnat_ugn.info,  Node: Checking the
*** 19427,19469 ****
  To avoid placing the entire elaboration-order burden on the programmer,
  Ada provides three lines of defense:
  
!    * ‘Static semantics’
  
       Static semantic rules restrict the possible choice of elaboration
!      order.  For instance, if unit Client ‘with’s unit Server, then the
       spec of Server is always elaborated prior to Client.  The same
       principle applies to child units - the spec of a parent unit is
       always elaborated prior to the child unit.
  
!    * ‘Dynamic semantics’
  
       Dynamic checks are performed at run time, to ensure that a target
       is elaborated prior to a scenario that invokes it, thus avoiding
       ABE problems.  A failed run-time check raises exception
       ‘Program_Error’.  The following restrictions apply:
  
!         - ‘Restrictions on calls’
  
            An entry, operator, or subprogram can be called from
            elaboration code only when the corresponding body has been
            elaborated.
  
!         - ‘Restrictions on instantiations’
  
            A generic unit can be instantiated by elaboration code only
            when the corresponding body has been elaborated.
  
!         - ‘Restrictions on task activation’
  
            A task can be activated by elaboration code only when the body
            of the associated task type has been elaborated.
  
       The restrictions above can be summarized by the following rule:
  
!      ‘If a target has a body, then this body must be elaborated prior to
!      the scenario that invokes the target.’
  
!    * ‘Elaboration control’
  
       Pragmas are provided for the programmer to specify the desired
       elaboration order.
--- 19427,19469 ----
  To avoid placing the entire elaboration-order burden on the programmer,
  Ada provides three lines of defense:
  
!    * 'Static semantics'
  
       Static semantic rules restrict the possible choice of elaboration
!      order.  For instance, if unit Client 'with's unit Server, then the
       spec of Server is always elaborated prior to Client.  The same
       principle applies to child units - the spec of a parent unit is
       always elaborated prior to the child unit.
  
!    * 'Dynamic semantics'
  
       Dynamic checks are performed at run time, to ensure that a target
       is elaborated prior to a scenario that invokes it, thus avoiding
       ABE problems.  A failed run-time check raises exception
       ‘Program_Error’.  The following restrictions apply:
  
!         - 'Restrictions on calls'
  
            An entry, operator, or subprogram can be called from
            elaboration code only when the corresponding body has been
            elaborated.
  
!         - 'Restrictions on instantiations'
  
            A generic unit can be instantiated by elaboration code only
            when the corresponding body has been elaborated.
  
!         - 'Restrictions on task activation'
  
            A task can be activated by elaboration code only when the body
            of the associated task type has been elaborated.
  
       The restrictions above can be summarized by the following rule:
  
!      'If a target has a body, then this body must be elaborated prior to
!      the scenario that invokes the target.'
  
!    * 'Elaboration control'
  
       Pragmas are provided for the programmer to specify the desired
       elaboration order.
*************** Ada provides several idioms and pragmas
*** 19478,19484 ****
  specifying the desired elaboration order and avoiding ABE problems
  altogether.
  
!    * ‘Packages without a body’
  
       A library package which does not require a completing body does not
       suffer from ABE problems.
--- 19478,19484 ----
  specifying the desired elaboration order and avoiding ABE problems
  altogether.
  
!    * 'Packages without a body'
  
       A library package which does not require a completing body does not
       suffer from ABE problems.
*************** altogether.
*** 19496,19513 ****
       in a body.  As a result, generic ‘Pack.Containers’ can be
       instantiated without encountering any ABE problems.
  
!    * ‘pragma Pure’
  
       Pragma ‘Pure’ places sufficient restrictions on a unit to guarantee
       that no scenario within the unit can result in an ABE problem.
  
!    * ‘pragma Preelaborate’
  
       Pragma ‘Preelaborate’ is slightly less restrictive than pragma
       ‘Pure’, but still strong enough to prevent ABE problems within a
       unit.
  
!    * ‘pragma Elaborate_Body’
  
       Pragma ‘Elaborate_Body’ requires that the body of a unit is
       elaborated immediately after its spec.  This restriction guarantees
--- 19496,19513 ----
       in a body.  As a result, generic ‘Pack.Containers’ can be
       instantiated without encountering any ABE problems.
  
!    * 'pragma Pure'
  
       Pragma ‘Pure’ places sufficient restrictions on a unit to guarantee
       that no scenario within the unit can result in an ABE problem.
  
!    * 'pragma Preelaborate'
  
       Pragma ‘Preelaborate’ is slightly less restrictive than pragma
       ‘Pure’, but still strong enough to prevent ABE problems within a
       unit.
  
!    * 'pragma Elaborate_Body'
  
       Pragma ‘Elaborate_Body’ requires that the body of a unit is
       elaborated immediately after its spec.  This restriction guarantees
*************** altogether.
*** 19541,19547 ****
            spec of Client
  
       because the spec of ‘Server’ must be elaborated prior to ‘Client’
!      by virtue of the ‘with’ clause, and in addition the body of
       ‘Server’ must be elaborated immediately after the spec of ‘Server’.
  
       Removing pragma ‘Elaborate_Body’ could result in the following
--- 19541,19547 ----
            spec of Client
  
       because the spec of ‘Server’ must be elaborated prior to ‘Client’
!      by virtue of the 'with' clause, and in addition the body of
       ‘Server’ must be elaborated immediately after the spec of ‘Server’.
  
       Removing pragma ‘Elaborate_Body’ could result in the following
*************** There are however situations where ‘Pu
*** 19564,19573 ****
  pragmas for use by client units to help ensure the elaboration safety of
  server units they depend on.
  
!    * ‘pragma Elaborate (Unit)’
  
       Pragma ‘Elaborate’ can be placed in the context clauses of a unit,
!      after a ‘with’ clause.  It guarantees that both the spec and body
       of its argument will be elaborated prior to the unit with the
       pragma.  Note that other unrelated units may be elaborated in
       between the spec and the body.
--- 19564,19573 ----
  pragmas for use by client units to help ensure the elaboration safety of
  server units they depend on.
  
!    * 'pragma Elaborate (Unit)'
  
       Pragma ‘Elaborate’ can be placed in the context clauses of a unit,
!      after a 'with' clause.  It guarantees that both the spec and body
       of its argument will be elaborated prior to the unit with the
       pragma.  Note that other unrelated units may be elaborated in
       between the spec and the body.
*************** server units they depend on.
*** 19606,19617 ****
       where ‘Client’ invokes ‘Server.Func’, but the body of ‘Server.Func’
       has not been elaborated yet.
  
!    * ‘pragma Elaborate_All (Unit)’
  
       Pragma ‘Elaborate_All’ is placed in the context clauses of a unit,
!      after a ‘with’ clause.  It guarantees that both the spec and body
       of its argument will be elaborated prior to the unit with the
!      pragma, as well as all units ‘with’ed by the spec and body of the
       argument, recursively.  Note that other unrelated units may be
       elaborated in between the spec and the body.
  
--- 19606,19617 ----
       where ‘Client’ invokes ‘Server.Func’, but the body of ‘Server.Func’
       has not been elaborated yet.
  
!    * 'pragma Elaborate_All (Unit)'
  
       Pragma ‘Elaborate_All’ is placed in the context clauses of a unit,
!      after a 'with' clause.  It guarantees that both the spec and body
       of its argument will be elaborated prior to the unit with the
!      pragma, as well as all units 'with'ed by the spec and body of the
       argument, recursively.  Note that other unrelated units may be
       elaborated in between the spec and the body.
  
*************** server units they depend on.
*** 19683,19707 ****
  
  All pragmas shown above can be summarized by the following rule:
  
! ‘If a client unit elaborates a server target directly or indirectly,
  then if the server unit requires a body and does not have pragma Pure,
  Preelaborate, or Elaborate_Body, then the client unit should have pragma
! Elaborate or Elaborate_All for the server unit.’
  
  If the rule outlined above is not followed, then a program may fall in
  one of the following states:
  
!    * ‘No elaboration order exists’
  
       In this case a compiler must diagnose the situation, and refuse to
       build an executable program.
  
!    * ‘One or more incorrect elaboration orders exist’
  
       In this case a compiler can build an executable program, but
       ‘Program_Error’ will be raised when the program is run.
  
!    * ‘Several elaboration orders exist, some correct, some incorrect’
  
       In this case the programmer has not controlled the elaboration
       order.  As a result, a compiler may or may not pick one of the
--- 19683,19707 ----
  
  All pragmas shown above can be summarized by the following rule:
  
! 'If a client unit elaborates a server target directly or indirectly,
  then if the server unit requires a body and does not have pragma Pure,
  Preelaborate, or Elaborate_Body, then the client unit should have pragma
! Elaborate or Elaborate_All for the server unit.'
  
  If the rule outlined above is not followed, then a program may fall in
  one of the following states:
  
!    * 'No elaboration order exists'
  
       In this case a compiler must diagnose the situation, and refuse to
       build an executable program.
  
!    * 'One or more incorrect elaboration orders exist'
  
       In this case a compiler can build an executable program, but
       ‘Program_Error’ will be raised when the program is run.
  
!    * 'Several elaboration orders exist, some correct, some incorrect'
  
       In this case the programmer has not controlled the elaboration
       order.  As a result, a compiler may or may not pick one of the
*************** one of the following states:
*** 19710,19716 ****
       because the program may fail on another compiler, or even another
       version of the same compiler.
  
!    * ‘One or more correct orders exist’
  
       In this case a compiler can build an executable program, and the
       program is run successfully.  This state may be guaranteed by
--- 19710,19716 ----
       because the program may fail on another compiler, or even another
       version of the same compiler.
  
!    * 'One or more correct orders exist'
  
       In this case a compiler can build an executable program, and the
       program is run successfully.  This state may be guaranteed by
*************** In addition to Ada semantics and rules s
*** 19732,19738 ****
  offers three elaboration models to aid the programmer with specifying
  the correct elaboration order and to diagnose elaboration problems.
  
!    * ‘Dynamic elaboration model’
  
       This is the most permissive of the three elaboration models and
       emulates the behavior specified by the Ada Reference Manual.  When
--- 19732,19738 ----
  offers three elaboration models to aid the programmer with specifying
  the correct elaboration order and to diagnose elaboration problems.
  
!    * 'Dynamic elaboration model'
  
       This is the most permissive of the three elaboration models and
       emulates the behavior specified by the Ada Reference Manual.  When
*************** the correct elaboration order and to dia
*** 19750,19756 ****
       generates run-time checks for all external targets and for all
       scenarios that may exhibit ABE problems.
  
!      The elaboration order is obtained by honoring all ‘with’ clauses,
       purity and preelaborability of units, and elaboration-control
       pragmas.  The dynamic model attempts to take all invocations in
       elaboration code into account.  If an invocation leads to a
--- 19750,19756 ----
       generates run-time checks for all external targets and for all
       scenarios that may exhibit ABE problems.
  
!      The elaboration order is obtained by honoring all 'with' clauses,
       purity and preelaborability of units, and elaboration-control
       pragmas.  The dynamic model attempts to take all invocations in
       elaboration code into account.  If an invocation leads to a
*************** the correct elaboration order and to dia
*** 19760,19766 ****
  
       The dynamic model is enabled with compiler switch ‘-gnatE’.
  
!    * ‘Static elaboration model’
  
       This is the middle ground of the three models.  When the static
       model is in effect, GNAT makes the following assumptions:
--- 19760,19766 ----
  
       The dynamic model is enabled with compiler switch ‘-gnatE’.
  
!    * 'Static elaboration model'
  
       This is the middle ground of the three models.  When the static
       model is in effect, GNAT makes the following assumptions:
*************** the correct elaboration order and to dia
*** 19777,19783 ****
       generates run-time checks for all external targets and for all
       scenarios that may exhibit ABE problems.
  
!      The elaboration order is obtained by honoring all ‘with’ clauses,
       purity and preelaborability of units, presence of
       elaboration-control pragmas, and all invocations in elaboration
       code.  An order obtained using the static model is guaranteed to be
--- 19777,19783 ----
       generates run-time checks for all external targets and for all
       scenarios that may exhibit ABE problems.
  
!      The elaboration order is obtained by honoring all 'with' clauses,
       purity and preelaborability of units, presence of
       elaboration-control pragmas, and all invocations in elaboration
       code.  An order obtained using the static model is guaranteed to be
*************** the correct elaboration order and to dia
*** 19786,19792 ****
  
       The static model is the default model in GNAT.
  
!    * ‘SPARK elaboration model’
  
       This is the most conservative of the three models and enforces the
       SPARK rules of elaboration as defined in the SPARK Reference
--- 19786,19792 ----
  
       The static model is the default model in GNAT.
  
!    * 'SPARK elaboration model'
  
       This is the most conservative of the three models and enforces the
       SPARK rules of elaboration as defined in the SPARK Reference
*************** the correct elaboration order and to dia
*** 19796,19802 ****
  
       The SPARK model is enabled with compiler switch ‘-gnatd.v’.
  
!    * ‘Legacy elaboration models’
  
       In addition to the three elaboration models outlined above, GNAT
       provides the following legacy models:
--- 19796,19802 ----
  
       The SPARK model is enabled with compiler switch ‘-gnatd.v’.
  
!    * 'Legacy elaboration models'
  
       In addition to the three elaboration models outlined above, GNAT
       provides the following legacy models:
*************** File: gnat_ugn.info,  Node: Mixing Elabo
*** 19823,19829 ****
  It is possible to mix units compiled with a different elaboration model,
  however the following rules must be observed:
  
!    * A client unit compiled with the dynamic model can only ‘with’ a
       server unit that meets at least one of the following criteria:
  
          - The server unit is compiled with the dynamic model.
--- 19823,19829 ----
  It is possible to mix units compiled with a different elaboration model,
  however the following rules must be observed:
  
!    * A client unit compiled with the dynamic model can only 'with' a
       server unit that meets at least one of the following criteria:
  
          - The server unit is compiled with the dynamic model.
*************** not be invoked due conditional execution
*** 19861,19868 ****
  suppressed selectively with ‘pragma Warnings (Off)’ or globally with
  compiler switch ‘-gnatwL’.
  
! A ‘guaranteed ABE’ arises when the body of a target is not elaborated
! early enough, and causes ‘all’ scenarios that directly invoke the target
  to fail.
  
            package body Guaranteed_ABE is
--- 19861,19868 ----
  suppressed selectively with ‘pragma Warnings (Off)’ or globally with
  compiler switch ‘-gnatwL’.
  
! A 'guaranteed ABE' arises when the body of a target is not elaborated
! early enough, and causes 'all' scenarios that directly invoke the target
  to fail.
  
            package body Guaranteed_ABE is
*************** following diagnostic:
*** 19886,19893 ****
               >>> warning: cannot call "ABE" before body seen
               >>> warning: Program_Error will be raised at run time
  
! A ‘conditional ABE’ arises when the body of a target is not elaborated
! early enough, and causes ‘some’ scenarios that directly invoke the
  target to fail.
  
             1. package body Conditional_ABE is
--- 19886,19893 ----
               >>> warning: cannot call "ABE" before body seen
               >>> warning: Program_Error will be raised at run time
  
! A 'conditional ABE' arises when the body of a target is not elaborated
! early enough, and causes 'some' scenarios that directly invoke the
  target to fail.
  
             1. package body Conditional_ABE is
*************** File: gnat_ugn.info,  Node: Elaboration
*** 19964,19973 ****
  9.9 Elaboration Circularities
  =============================
  
! An ‘elaboration circularity’ occurs whenever the elaboration of a set of
  units enters a deadlocked state, where each unit is waiting for another
  unit to be elaborated.  This situation may be the result of improper use
! of ‘with’ clauses, elaboration-control pragmas, or invocations in
  elaboration code.
  
  The following example exhibits an elaboration circularity.
--- 19964,19973 ----
  9.9 Elaboration Circularities
  =============================
  
! An 'elaboration circularity' occurs whenever the elaboration of a set of
  units enters a deadlocked state, where each unit is waiting for another
  unit to be elaborated.  This situation may be the result of improper use
! of 'with' clauses, elaboration-control pragmas, or invocations in
  elaboration code.
  
  The following example exhibits an elaboration circularity.
*************** especially in the case of complex legacy
*** 20054,20060 ****
  When faced with an elaboration circularity, the programmer should also
  consider the tactics given in the suggestions section of the circularity
  diagnostic.  Depending on the units involved in the circularity, their
! ‘with’ clauses, purity, preelaborability, presence of
  elaboration-control pragmas and invocations at elaboration time, the
  binder may suggest one or more of the following tactics to eliminate the
  circularity:
--- 20054,20060 ----
  When faced with an elaboration circularity, the programmer should also
  consider the tactics given in the suggestions section of the circularity
  diagnostic.  Depending on the units involved in the circularity, their
! 'with' clauses, purity, preelaborability, presence of
  elaboration-control pragmas and invocations at elaboration time, the
  binder may suggest one or more of the following tactics to eliminate the
  circularity:
*************** circularity:
*** 20090,20096 ****
  
          - The removal of the pragma will not eliminate the semantic
            effects of the pragma.  In other words, the argument of the
!           pragma along with its ‘with’ closure will still be elaborated
            prior to the unit containing the pragma.
  
          - The removal of the pragma will enable the successful ordering
--- 20090,20096 ----
  
          - The removal of the pragma will not eliminate the semantic
            effects of the pragma.  In other words, the argument of the
!           pragma along with its 'with' closure will still be elaborated
            prior to the unit containing the pragma.
  
          - The removal of the pragma will enable the successful ordering
*************** consequently the elaboration order chose
*** 20265,20282 ****
       supplementary information depending on the elaboration model in
       effect.
  
!         - ‘Dynamic model’
  
            GNAT will indicate missing ‘Elaborate’ and ‘Elaborate_All’
            pragmas for all library-level scenarios within the partition.
  
!         - ‘Static model’
  
            GNAT will indicate all scenarios invoked during elaboration.
            In addition, it will provide detailed traceback when an
            implicit ‘Elaborate’ or ‘Elaborate_All’ pragma is generated.
  
!         - ‘SPARK model’
  
            GNAT will indicate how an elaboration requirement is met by
            the context of a unit.  This diagnostic requires compiler
--- 20265,20282 ----
       supplementary information depending on the elaboration model in
       effect.
  
!         - 'Dynamic model'
  
            GNAT will indicate missing ‘Elaborate’ and ‘Elaborate_All’
            pragmas for all library-level scenarios within the partition.
  
!         - 'Static model'
  
            GNAT will indicate all scenarios invoked during elaboration.
            In addition, it will provide detailed traceback when an
            implicit ‘Elaborate’ or ‘Elaborate_All’ pragma is generated.
  
!         - 'SPARK model'
  
            GNAT will indicate how an elaboration requirement is met by
            the context of a unit.  This diagnostic requires compiler
*************** out the differences from the Intel conve
*** 20614,20656 ****
  ‘gas’ (an ‘as’ macro pre-processor) documentation for further
  information.
  
!      ‘Register names’ 
!           gcc / ‘as’: Prefix with ‘%’; for example ‘%eax’ 
!           Intel: No extra punctuation; for example ‘eax’ 
  
!      ‘Immediate operand’ 
!           gcc / ‘as’: Prefix with ‘$’; for example ‘$4’ 
!           Intel: No extra punctuation; for example ‘4’ 
  
!      ‘Address’ 
!           gcc / ‘as’: Prefix with ‘$’; for example ‘$loc’ 
!           Intel: No extra punctuation; for example ‘loc’ 
  
!      ‘Memory contents’ 
!           gcc / ‘as’: No extra punctuation; for example ‘loc’ 
!           Intel: Square brackets; for example ‘[loc]’ 
  
!      ‘Register contents’ 
!           gcc / ‘as’: Parentheses; for example ‘(%eax)’ 
!           Intel: Square brackets; for example ‘[eax]’ 
  
!      ‘Hexadecimal numbers’ 
!           gcc / ‘as’: Leading ‘0x’ (C language syntax); for example ‘0xA0’ 
!           Intel: Trailing ‘h’; for example ‘A0h’ 
  
!      ‘Operand size’ 
!           gcc / ‘as’: Explicit in op code; for example ‘movw’ to move a 16-bit word 
!           Intel: Implicit, deduced by assembler; for example ‘mov’ 
  
!      ‘Instruction repetition’ 
!           gcc / ‘as’: Split into two lines; for example 
!                ‘rep’ 
!                ‘stosl’ 
!           Intel: Keep on one line; for example ‘rep stosl’ 
  
!      ‘Order of operands’ 
!           gcc / ‘as’: Source first; for example ‘movw $4, %eax’ 
!           Intel: Destination first; for example ‘mov eax, 4’ 
  
  
  File: gnat_ugn.info,  Node: A Simple Example of Inline Assembler,  Next: Output Variables in Inline Assembler,  Prev: Basic Assembler Syntax,  Up: Inline Assembler
--- 20614,20656 ----
  ‘gas’ (an ‘as’ macro pre-processor) documentation for further
  information.
  
!      'Register names'
!           gcc / ‘as’: Prefix with ‘%’; for example ‘%eax’
!           Intel: No extra punctuation; for example ‘eax’
  
!      'Immediate operand'
!           gcc / ‘as’: Prefix with ‘$’; for example ‘$4’
!           Intel: No extra punctuation; for example ‘4’
  
!      'Address'
!           gcc / ‘as’: Prefix with ‘$’; for example ‘$loc’
!           Intel: No extra punctuation; for example ‘loc’
  
!      'Memory contents'
!           gcc / ‘as’: No extra punctuation; for example ‘loc’
!           Intel: Square brackets; for example ‘[loc]’
  
!      'Register contents'
!           gcc / ‘as’: Parentheses; for example ‘(%eax)’
!           Intel: Square brackets; for example ‘[eax]’
  
!      'Hexadecimal numbers'
!           gcc / ‘as’: Leading ‘0x’ (C language syntax); for example ‘0xA0’
!           Intel: Trailing ‘h’; for example ‘A0h’
  
!      'Operand size'
!           gcc / ‘as’: Explicit in op code; for example ‘movw’ to move a 16-bit word
!           Intel: Implicit, deduced by assembler; for example ‘mov’
  
!      'Instruction repetition'
!           gcc / ‘as’: Split into two lines; for example
!                ‘rep’
!                ‘stosl’
!           Intel: Keep on one line; for example ‘rep stosl’
  
!      'Order of operands'
!           gcc / ‘as’: Source first; for example ‘movw $4, %eax’
!           Intel: Destination first; for example ‘mov eax, 4’
  
  
  File: gnat_ugn.info,  Node: A Simple Example of Inline Assembler,  Next: Output Variables in Inline Assembler,  Prev: Basic Assembler Syntax,  Up: Inline Assembler
*************** Inline Assembler facility.
*** 20670,20676 ****
            end Nothing;
  
  ‘Asm’ is a procedure declared in package ‘System.Machine_Code’; here it
! takes one parameter, a ‘template string’ that must be a static
  expression and that will form the generated instruction.  ‘Asm’ may be
  regarded as a compile-time procedure that parses the template string and
  additional parameters (none here), from which it generates a sequence of
--- 20670,20676 ----
            end Nothing;
  
  ‘Asm’ is a procedure declared in package ‘System.Machine_Code’; here it
! takes one parameter, a 'template string' that must be a static
  expression and that will form the generated instruction.  ‘Asm’ may be
  regarded as a compile-time procedure that parses the template string and
  additional parameters (none here), from which it generates a sequence of
*************** allowing the optimizer to choose whateve
*** 20859,20898 ****
  There are a fairly large number of constraints, but the ones that are
  most useful (for the Intel x86 processor) are the following:
  
!      ‘=’        output constraint
                  
                  
!      ‘g’        global (i.e., can be stored anywhere)
                  
                  
!      ‘m’        in memory
                  
                  
!      ‘I’        a constant
                  
                  
!      ‘a’        use eax
                  
                  
!      ‘b’        use ebx
                  
                  
!      ‘c’        use ecx
                  
                  
!      ‘d’        use edx
                  
                  
!      ‘S’        use esi
                  
                  
!      ‘D’        use edi
                  
                  
!      ‘r’        use one of eax, ebx, ecx or edx
                  
                  
!      ‘q’        use one of eax, ebx, ecx, edx, esi or edi
                  
  
  The full set of constraints is described in the gcc and ‘as’
--- 20859,20898 ----
  There are a fairly large number of constraints, but the ones that are
  most useful (for the Intel x86 processor) are the following:
  
!      '='        output constraint
                  
                  
!      'g'        global (i.e., can be stored anywhere)
                  
                  
!      'm'        in memory
                  
                  
!      'I'        a constant
                  
                  
!      'a'        use eax
                  
                  
!      'b'        use ebx
                  
                  
!      'c'        use ecx
                  
                  
!      'd'        use edx
                  
                  
!      'S'        use esi
                  
                  
!      'D'        use edi
                  
                  
!      'r'        use one of eax, ebx, ecx or edx
                  
                  
!      'q'        use one of eax, ebx, ecx, edx, esi or edi
                  
  
  The full set of constraints is described in the gcc and ‘as’
*************** documentation; note that it is possible
*** 20900,20906 ****
  in one constraint string.
  
  You specify the association of an output variable with an assembler
! operand through the ‘%N’ notation, where ‘n’ is a non-negative integer.
  Thus in
  
            Asm ("pushfl"          & LF & HT & -- push flags on stack
--- 20900,20906 ----
  in one constraint string.
  
  You specify the association of an output variable with an assembler
! operand through the ‘%N’ notation, where 'n' is a non-negative integer.
  Thus in
  
            Asm ("pushfl"          & LF & HT & -- push flags on stack
*************** identify the registers that will be used
*** 21156,21162 ****
                 Clobber => "ebx");
  
  The Clobber parameter is a static string expression specifying the
! register(s) you are using.  Note that register names are ‘not’ prefixed
  by a percent sign.  Also, if more than one register is used then their
  names are separated by commas; e.g., ‘"eax, ebx"’
  
--- 21156,21162 ----
                 Clobber => "ebx");
  
  The Clobber parameter is a static string expression specifying the
! register(s) you are using.  Note that register names are 'not' prefixed
  by a percent sign.  Also, if more than one register is used then their
  names are separated by commas; e.g., ‘"eax, ebx"’
  
*************** Copyright 2000, 2001, 2002, 2007, 2008 F
*** 21210,21216 ****
  Everyone is permitted to copy and distribute verbatim copies of this
  license document, but changing it is not allowed.
  
! ‘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
--- 21210,21216 ----
  Everyone is permitted to copy and distribute verbatim copies of this
  license document, but changing it is not allowed.
  
! '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
*************** used for any textual work, regardless of
*** 21233,21254 ****
  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
--- 21233,21254 ----
  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
*************** mathematics.)  The relationship could be
*** 21258,21264 ****
  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
--- 21258,21264 ----
  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 Documen
*** 21266,21277 ****
  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
--- 21266,21277 ----
  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
*************** formatters.  A copy made in an otherwise
*** 21282,21288 ****
  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
--- 21282,21288 ----
  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
*************** processing tools are not generally avail
*** 21295,21316 ****
  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
--- 21295,21316 ----
  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
*************** but only as regards disclaiming warranti
*** 21320,21326 ****
  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
--- 21320,21326 ----
  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
*************** number of copies you must also follow th
*** 21335,21341 ****
  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
--- 21335,21341 ----
  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
*************** It is requested, but not required, that
*** 21372,21378 ****
  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
--- 21372,21378 ----
  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
*************** The author(s) and publisher(s) of the Do
*** 21470,21476 ****
  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
--- 21470,21476 ----
  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
*************** likewise combine any sections Entitled 
*** 21494,21500 ****
  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
--- 21494,21500 ----
  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
*************** it individually under this License, prov
*** 21507,21513 ****
  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
--- 21507,21513 ----
  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
*************** that bracket the Document within the agg
*** 21525,21531 ****
  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
--- 21525,21531 ----
  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
*************** If a section in the Document is Entitled
*** 21544,21550 ****
  “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
--- 21544,21550 ----
  “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
*************** this License.  If your rights have been
*** 21571,21577 ****
  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
--- 21571,21577 ----
  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
*************** that a proxy can decide which future ver
*** 21591,21597 ****
  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
--- 21591,21597 ----
  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
*************** The operator of an MMC Site may republis
*** 21619,21625 ****
  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
--- 21619,21625 ----
  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
*************** Index
*** 21658,21663 ****
--- 21658,21665 ----
  [index]
  * Menu:
  
+ * __gnat_malloc:                         Switches for gnatbind.
+                                                              (line  137)
  * -a (gnatbind):                         Switches for gnatbind.
                                                               (line   19)
  * -A (gnatbind):                         Switches for gnatbind.
*************** Index
*** 21691,21697 ****
                                                               (line  458)
  * -aP (gnatls):                          Switches for gnatls.
                                                               (line   55)
! * –as (dlltool):                         Using gnatdll.      (line  227)
  * -b (gcc):                              Alphabetical List of All Switches.
                                                               (line    6)
  * -B (gcc):                              Alphabetical List of All Switches.
--- 21693,21699 ----
                                                               (line  458)
  * -aP (gnatls):                          Switches for gnatls.
                                                               (line   55)
! * -as (dlltool):                         Using gnatdll.      (line  227)
  * -b (gcc):                              Alphabetical List of All Switches.
                                                               (line    6)
  * -B (gcc):                              Alphabetical List of All Switches.
*************** Index
*** 21710,21716 ****
  * -bargs (gnatdll):                      Using gnatdll.      (line   35)
  * -bargs (gnatmake):                     Mode Switches for gnatmake.
                                                               (line   19)
! * –base-file (dlltool):                  Using gnatdll.      (line  189)
  * -C (gcc):                              Switches.           (line   21)
  * -c (gcc):                              Alphabetical List of All Switches.
                                                               (line   21)
--- 21712,21718 ----
  * -bargs (gnatdll):                      Using gnatdll.      (line   35)
  * -bargs (gnatmake):                     Mode Switches for gnatmake.
                                                               (line   19)
! * -base-file (dlltool):                  Using gnatdll.      (line  189)
  * -C (gcc):                              Switches.           (line   21)
  * -c (gcc):                              Alphabetical List of All Switches.
                                                               (line   21)
*************** Index
*** 21735,21741 ****
                                                               (line  170)
  * -cargs (gnatmake):                     Mode Switches for gnatmake.
                                                               (line   13)
! * –create-missing-dirs (gnatmake):       Switches for gnatmake.
                                                               (line   72)
  * -D (gnatbind):                         Switches for gnatbind.
                                                               (line   58)
--- 21737,21743 ----
                                                               (line  170)
  * -cargs (gnatmake):                     Mode Switches for gnatmake.
                                                               (line   13)
! * -create-missing-dirs (gnatmake):       Switches for gnatmake.
                                                               (line   72)
  * -D (gnatbind):                         Switches for gnatbind.
                                                               (line   58)
*************** Index
*** 21754,21762 ****
                                                               (line   59)
  * -D (gnatprep):                         Switches for gnatprep.
                                                               (line   40)
! * –def (dlltool):                        Using gnatdll.      (line  194)
! * –demangle (gprof):                     Running gprof.      (line   24)
! * –dllname (dlltool):                    Using gnatdll.      (line  198)
  * -dnn[k|m] (gnatbind):                  Switches for gnatbind.
                                                               (line   46)
  * -e (gnatbind):                         Switches for gnatbind.
--- 21756,21764 ----
                                                               (line   59)
  * -D (gnatprep):                         Switches for gnatprep.
                                                               (line   40)
! * -def (dlltool):                        Using gnatdll.      (line  194)
! * -demangle (gprof):                     Running gprof.      (line   24)
! * -dllname (dlltool):                    Using gnatdll.      (line  198)
  * -dnn[k|m] (gnatbind):                  Switches for gnatbind.
                                                               (line   46)
  * -e (gnatbind):                         Switches for gnatbind.
*************** Index
*** 21858,21868 ****
                                                               (line   27)
  * -g (gnatmake):                         Switches for gnatmake.
                                                               (line  240)
! * –GCC= (gnatchop):                      Switches for gnatchop.
                                                               (line   98)
! * –GCC=compiler_name (gnatlink):         Switches for gnatlink.
                                                               (line   80)
! * –GCC=compiler_name (gnatmake):         Switches for gnatmake.
                                                               (line   24)
  * -gnat-p (gcc):                         Alphabetical List of All Switches.
                                                               (line  752)
--- 21860,21870 ----
                                                               (line   27)
  * -g (gnatmake):                         Switches for gnatmake.
                                                               (line  240)
! * -GCC= (gnatchop):                      Switches for gnatchop.
                                                               (line   98)
! * -GCC=compiler_name (gnatlink):         Switches for gnatlink.
                                                               (line   80)
! * -GCC=compiler_name (gnatmake):         Switches for gnatmake.
                                                               (line   24)
  * -gnat-p (gcc):                         Alphabetical List of All Switches.
                                                               (line  752)
*************** Index
*** 21909,21915 ****
                                                               (line  209)
  * -gnatb (gcc) <1>:                      Output and Error Message Control.
                                                               (line  101)
! * –GNATBIND=binder_name (gnatmake):      Switches for gnatmake.
                                                               (line   40)
  * -gnatc (gcc):                          Alphabetical List of All Switches.
                                                               (line  214)
--- 21911,21917 ----
                                                               (line  209)
  * -gnatb (gcc) <1>:                      Output and Error Message Control.
                                                               (line  101)
! * -GNATBIND=binder_name (gnatmake):      Switches for gnatmake.
                                                               (line   40)
  * -gnatc (gcc):                          Alphabetical List of All Switches.
                                                               (line  214)
*************** Index
*** 21921,21930 ****
                                                               (line  235)
  * -gnatd (gcc) <1>:                      Debugging Control.  (line    6)
  * -gnatD (gcc):                          Debugging Control.  (line  142)
- * -gnatdc switch:                        GNAT Abnormal Termination or Failure to Terminate.
-                                                              (line   33)
  * -gnatD[nn] (gcc):                      Alphabetical List of All Switches.
                                                               (line  245)
  * -gnatE (gcc):                          Alphabetical List of All Switches.
                                                               (line  558)
  * -gnatE (gcc) <1>:                      Run-Time Checks.    (line  129)
--- 21923,21932 ----
                                                               (line  235)
  * -gnatd (gcc) <1>:                      Debugging Control.  (line    6)
  * -gnatD (gcc):                          Debugging Control.  (line  142)
  * -gnatD[nn] (gcc):                      Alphabetical List of All Switches.
                                                               (line  245)
+ * -gnatdc switch:                        GNAT Abnormal Termination or Failure to Terminate.
+                                                              (line   33)
  * -gnatE (gcc):                          Alphabetical List of All Switches.
                                                               (line  558)
  * -gnatE (gcc) <1>:                      Run-Time Checks.    (line  129)
*************** Index
*** 22031,22037 ****
  * -gnatL (gcc) <2>:                      Debugging Control.  (line  163)
  * -gnatl=fname (gcc):                    Output and Error Message Control.
                                                               (line   84)
! * –GNATLINK=linker_name (gnatmake):      Switches for gnatmake.
                                                               (line   51)
  * -gnatm (gcc):                          Alphabetical List of All Switches.
                                                               (line  666)
--- 22033,22039 ----
  * -gnatL (gcc) <2>:                      Debugging Control.  (line  163)
  * -gnatl=fname (gcc):                    Output and Error Message Control.
                                                               (line   84)
! * -GNATLINK=linker_name (gnatmake):      Switches for gnatmake.
                                                               (line   51)
  * -gnatm (gcc):                          Alphabetical List of All Switches.
                                                               (line  666)
*************** Index
*** 22052,22059 ****
  * -gnato (gcc):                          Controlling Run-Time Checks.
                                                               (line   11)
  * -gnato (gcc) <1>:                      Default Settings.   (line   17)
- * -gnato0 (gcc):                         Alphabetical List of All Switches.
-                                                              (line  697)
  * -gnato? (gcc):                         Specifying the Desired Mode.
                                                               (line   52)
  * -gnato?? (gcc):                        Alphabetical List of All Switches.
--- 22054,22059 ----
*************** Index
*** 22061,22066 ****
--- 22061,22068 ----
  * -gnato?? (gcc) <1>:                    Run-Time Checks.    (line   64)
  * -gnato?? (gcc) <2>:                    Specifying the Desired Mode.
                                                               (line   52)
+ * -gnato0 (gcc):                         Alphabetical List of All Switches.
+                                                              (line  697)
  * -gnatp (gcc):                          Alphabetical List of All Switches.
                                                               (line  746)
  * -gnatp (gcc) <1>:                      Run-Time Checks.    (line   12)
*************** Index
*** 22122,22127 ****
--- 22124,22149 ----
                                                               (line  811)
  * -gnatW (gcc) <1>:                      Character Set Control.
                                                               (line   51)
+ * -gnatw_a:                              Warning Message Control.
+                                                              (line  215)
+ * -gnatw_A:                              Warning Message Control.
+                                                              (line  224)
+ * -gnatw_c (gcc):                        Warning Message Control.
+                                                              (line  318)
+ * -gnatw_C (gcc):                        Warning Message Control.
+                                                              (line  326)
+ * -gnatw_p (gcc):                        Warning Message Control.
+                                                              (line  792)
+ * -gnatw_P (gcc):                        Warning Message Control.
+                                                              (line  803)
+ * -gnatw_q (gcc):                        Warning Message Control.
+                                                              (line  878)
+ * -gnatw_Q (gcc):                        Warning Message Control.
+                                                              (line  892)
+ * -gnatw_r (gcc):                        Warning Message Control.
+                                                              (line  948)
+ * -gnatw_R (gcc):                        Warning Message Control.
+                                                              (line  957)
  * -gnatw.a (gcc):                        Warning Message Control.
                                                               (line  199)
  * -gnatw.A (gcc):                        Warning Message Control.
*************** Index
*** 22320,22345 ****
                                                               (line 1248)
  * -gnatwZ (gcc):                         Warning Message Control.
                                                               (line 1257)
- * -gnatw_a:                              Warning Message Control.
-                                                              (line  215)
- * -gnatw_A:                              Warning Message Control.
-                                                              (line  224)
- * -gnatw_c (gcc):                        Warning Message Control.
-                                                              (line  318)
- * -gnatw_C (gcc):                        Warning Message Control.
-                                                              (line  326)
- * -gnatw_p (gcc):                        Warning Message Control.
-                                                              (line  792)
- * -gnatw_P (gcc):                        Warning Message Control.
-                                                              (line  803)
- * -gnatw_q (gcc):                        Warning Message Control.
-                                                              (line  878)
- * -gnatw_Q (gcc):                        Warning Message Control.
-                                                              (line  892)
- * -gnatw_r (gcc):                        Warning Message Control.
-                                                              (line  948)
- * -gnatw_R (gcc):                        Warning Message Control.
-                                                              (line  957)
  * -gnatx (gcc):                          Alphabetical List of All Switches.
                                                               (line  815)
  * -gnatX (gcc):                          Alphabetical List of All Switches.
--- 22342,22347 ----
*************** Index
*** 22354,22361 ****
  * -gnaty (gcc):                          Alphabetical List of All Switches.
                                                               (line  827)
  * -gnaty (gcc) <1>:                      Style Checking.     (line    6)
- * -gnaty+ (gcc):                         Style Checking.     (line  459)
  * -gnaty- (gcc):                         Style Checking.     (line  447)
  * -gnatya (gcc):                         Style Checking.     (line   51)
  * -gnatyA (gcc):                         Style Checking.     (line   60)
  * -gnatyb (gcc):                         Style Checking.     (line   68)
--- 22356,22364 ----
  * -gnaty (gcc):                          Alphabetical List of All Switches.
                                                               (line  827)
  * -gnaty (gcc) <1>:                      Style Checking.     (line    6)
  * -gnaty- (gcc):                         Style Checking.     (line  447)
+ * -gnaty[0-9] (gcc):                     Style Checking.     (line   25)
+ * -gnaty+ (gcc):                         Style Checking.     (line  459)
  * -gnatya (gcc):                         Style Checking.     (line   51)
  * -gnatyA (gcc):                         Style Checking.     (line   60)
  * -gnatyb (gcc):                         Style Checking.     (line   68)
*************** Index
*** 22387,22393 ****
  * -gnatyu (gcc):                         Style Checking.     (line  422)
  * -gnatyx (gcc):                         Style Checking.     (line  430)
  * -gnatyy (gcc):                         Style Checking.     (line  438)
- * -gnaty[0-9] (gcc):                     Style Checking.     (line   25)
  * -gnatz (gcc):                          Alphabetical List of All Switches.
                                                               (line  831)
  * -h (gnatbind):                         Switches for gnatbind.
--- 22390,22395 ----
*************** Index
*** 22406,22427 ****
                                                               (line  131)
  * -H64 (gnatbind):                       Switches for gnatbind.
                                                               (line  137)
! * –help (dlltool):                       Using gnatdll.      (line  209)
! * –help (gnatbind):                      Switches for gnatbind.
                                                               (line   14)
! * –help (gnatchop):                      Switches for gnatchop.
                                                               (line   13)
! * –help (gnatclean):                     Switches for gnatclean.
                                                               (line   13)
! * –help (gnatlink):                      Switches for gnatlink.
                                                               (line   13)
! * –help (gnatls):                        Switches for gnatls.
                                                               (line   13)
! * –help (gnatmake):                      Switches for gnatmake.
                                                               (line   13)
! * –help (gnatname):                      Switches for gnatname.
                                                               (line   15)
! * –help (gnatprep):                      Switches for gnatprep.
                                                               (line   11)
  * -I (gcc):                              Alphabetical List of All Switches.
                                                               (line  836)
--- 22408,22429 ----
                                                               (line  131)
  * -H64 (gnatbind):                       Switches for gnatbind.
                                                               (line  137)
! * -help (dlltool):                       Using gnatdll.      (line  209)
! * -help (gnatbind):                      Switches for gnatbind.
                                                               (line   14)
! * -help (gnatchop):                      Switches for gnatchop.
                                                               (line   13)
! * -help (gnatclean):                     Switches for gnatclean.
                                                               (line   13)
! * -help (gnatlink):                      Switches for gnatlink.
                                                               (line   13)
! * -help (gnatls):                        Switches for gnatls.
                                                               (line   13)
! * -help (gnatmake):                      Switches for gnatmake.
                                                               (line   13)
! * -help (gnatname):                      Switches for gnatname.
                                                               (line   15)
! * -help (gnatprep):                      Switches for gnatprep.
                                                               (line   11)
  * -I (gcc):                              Alphabetical List of All Switches.
                                                               (line  836)
*************** Index
*** 22474,22480 ****
  * -largs (gnatdll):                      Using gnatdll.      (line   99)
  * -largs (gnatmake):                     Mode Switches for gnatmake.
                                                               (line   25)
! * –LINK= (gnatlink):                     Switches for gnatlink.
                                                               (line  101)
  * -M (gnatbind):                         Switches for gnatbind.
                                                               (line  176)
--- 22476,22482 ----
  * -largs (gnatdll):                      Using gnatdll.      (line   99)
  * -largs (gnatmake):                     Mode Switches for gnatmake.
                                                               (line   25)
! * -LINK= (gnatlink):                     Switches for gnatlink.
                                                               (line  101)
  * -M (gnatbind):                         Switches for gnatbind.
                                                               (line  176)
*************** Index
*** 22543,22550 ****
                                                               (line   31)
  * -o (gnatmake):                         Switches for gnatmake.
                                                               (line  337)
! * –output-exp (dlltool):                 Using gnatdll.      (line  213)
! * –output-lib (dlltool):                 Using gnatdll.      (line  219)
  * -p (gnatbind):                         Switches for gnatbind.
                                                               (line  234)
  * -P (gnatbind):                         Switches for gnatbind.
--- 22545,22552 ----
                                                               (line   31)
  * -o (gnatmake):                         Switches for gnatmake.
                                                               (line  337)
! * -output-exp (dlltool):                 Using gnatdll.      (line  213)
! * -output-lib (dlltool):                 Using gnatdll.      (line  219)
  * -p (gnatbind):                         Switches for gnatbind.
                                                               (line  234)
  * -P (gnatbind):                         Switches for gnatbind.
*************** Index
*** 22587,22605 ****
                                                               (line   46)
  * -Ra (gnatbind):                        Switches for gnatbind.
                                                               (line  247)
! * –RTS (gcc):                            Alphabetical List of All Switches.
                                                               (line  898)
! * –RTS (gnatbind):                       Switches for gnatbind.
                                                               (line  218)
! * –RTS (gnatls):                         Switches for gnatls.
                                                               (line   59)
! * –RTS (gnatmake):                       Switches for gnatmake.
                                                               (line  493)
! * –RTS option:                           Specifying a Run-Time Library.
                                                               (line   53)
! * –RTS=sjlj (gnatmake):                  Exception Handling Control.
                                                               (line   29)
! * –RTS=zcx (gnatmake):                   Exception Handling Control.
                                                               (line   40)
  * -S (gcc):                              Alphabetical List of All Switches.
                                                               (line  904)
--- 22589,22607 ----
                                                               (line   46)
  * -Ra (gnatbind):                        Switches for gnatbind.
                                                               (line  247)
! * -RTS (gcc):                            Alphabetical List of All Switches.
                                                               (line  898)
! * -RTS (gnatbind):                       Switches for gnatbind.
                                                               (line  218)
! * -RTS (gnatls):                         Switches for gnatls.
                                                               (line   59)
! * -RTS (gnatmake):                       Switches for gnatmake.
                                                               (line  493)
! * -RTS option:                           Specifying a Run-Time Library.
                                                               (line   53)
! * -RTS=sjlj (gnatmake):                  Exception Handling Control.
                                                               (line   29)
! * -RTS=zcx (gnatmake):                   Exception Handling Control.
                                                               (line   40)
  * -S (gcc):                              Alphabetical List of All Switches.
                                                               (line  904)
*************** Index
*** 22639,22644 ****
--- 22641,22650 ----
                                                               (line  374)
  * -u (gnatprep):                         Switches for gnatprep.
                                                               (line   72)
+ * -v -v (gnatlink):                      Switches for gnatlink.
+                                                              (line   48)
+ * -v -v (gnatname):                      Switches for gnatname.
+                                                              (line  109)
  * -v (dlltool):                          Using gnatdll.      (line  223)
  * -v (gcc):                              Alphabetical List of All Switches.
                                                               (line  917)
*************** Index
*** 22665,22689 ****
                                                               (line  101)
  * -v (gnatprep):                         Switches for gnatprep.
                                                               (line   79)
! * -v -v (gnatlink):                      Switches for gnatlink.
!                                                              (line   48)
! * -v -v (gnatname):                      Switches for gnatname.
!                                                              (line  109)
! * –version (gnatbind):                   Switches for gnatbind.
                                                               (line    9)
! * –version (gnatchop):                   Switches for gnatchop.
                                                               (line    8)
! * –version (gnatclean):                  Switches for gnatclean.
                                                               (line    8)
! * –version (gnatlink):                   Switches for gnatlink.
                                                               (line    8)
! * –version (gnatls):                     Switches for gnatls.
                                                               (line    8)
! * –version (gnatmake):                   Switches for gnatmake.
                                                               (line    8)
! * –version (gnatname):                   Switches for gnatname.
                                                               (line   10)
! * –version (gnatprep):                   Switches for gnatprep.
                                                               (line    6)
  * -vl (gnatmake):                        Switches for gnatmake.
                                                               (line  387)
--- 22671,22691 ----
                                                               (line  101)
  * -v (gnatprep):                         Switches for gnatprep.
                                                               (line   79)
! * -version (gnatbind):                   Switches for gnatbind.
                                                               (line    9)
! * -version (gnatchop):                   Switches for gnatchop.
                                                               (line    8)
! * -version (gnatclean):                  Switches for gnatclean.
                                                               (line    8)
! * -version (gnatlink):                   Switches for gnatlink.
                                                               (line    8)
! * -version (gnatls):                     Switches for gnatls.
                                                               (line    8)
! * -version (gnatmake):                   Switches for gnatmake.
                                                               (line    8)
! * -version (gnatname):                   Switches for gnatname.
                                                               (line   10)
! * -version (gnatprep):                   Switches for gnatprep.
                                                               (line    6)
  * -vl (gnatmake):                        Switches for gnatmake.
                                                               (line  387)
*************** Index
*** 22741,22748 ****
                                                               (line   12)
  * -z (gnatmake):                         Switches for gnatmake.
                                                               (line  423)
- * __gnat_malloc:                         Switches for gnatbind.
-                                                              (line  137)
  * Abnormal Termination or Failure to Terminate: Remote Debugging with gdbserver.
                                                               (line   46)
  * Access before elaboration:             Run-Time Checks.    (line    6)
--- 22743,22748 ----
*************** Index
*** 22781,22791 ****
                                                               (line   80)
  * Ada Library Information files:         The Ada Library Information Files.
                                                               (line    6)
- * Ada.Characters.Latin_1:                Latin-1.            (line   13)
- * adafinal:                              Binding with Non-Ada Main Programs.
-                                                              (line   38)
- * adainit:                               Binding with Non-Ada Main Programs.
-                                                              (line   22)
  * ADA_INCLUDE_PATH:                      Using a library.    (line   54)
  * ADA_INCLUDE_PATH <1>:                  Search Paths and the Run-Time Library RTL.
                                                               (line   28)
--- 22781,22786 ----
*************** Index
*** 22810,22815 ****
--- 22805,22815 ----
                                                               (line   23)
  * ADA_PROJECT_PATH:                      Installing a library.
                                                               (line    6)
+ * Ada.Characters.Latin_1:                Latin-1.            (line   13)
+ * adafinal:                              Binding with Non-Ada Main Programs.
+                                                              (line   38)
+ * adainit:                               Binding with Non-Ada Main Programs.
+                                                              (line   22)
  * Address Clauses:                       Warning Message Control.
                                                               (line  714)
  * ALI files:                             The Ada Library Information Files.
*************** Index
*** 22885,22890 ****
--- 22885,22892 ----
                                                               (line    6)
  * C varargs function:                    Calling Conventions.
                                                               (line   64)
+ * C_INCLUDE_PATH:                        Linking a Mixed C++ & Ada Program.
+                                                              (line   28)
  * C++:                                   Calling Conventions.
                                                               (line   89)
  * C++ headers (binding generation):      Generating Ada Bindings for C and C++ headers.
*************** Index
*** 22974,22981 ****
  * CR:                                    Source Representation.
                                                               (line    6)
  * Cyrillic:                              Other 8-Bit Codes.  (line   23)
- * C_INCLUDE_PATH:                        Linking a Mixed C++ & Ada Program.
-                                                              (line   28)
  * Deactivated code:                      Warning Message Control.
                                                               (line  996)
  * Debug:                                 Debugging and Assertion Control.
--- 22976,22981 ----
*************** Index
*** 23010,23025 ****
                                                               (line  153)
  * Dimension Vector (for a dimensioned subtype): Performing Dimensionality Analysis in GNAT.
                                                               (line  153)
  * Dimensionable type:                    Performing Dimensionality Analysis in GNAT.
                                                               (line  148)
  * Dimensionality analysis:               Performing Dimensionality Analysis in GNAT.
                                                               (line    6)
  * Dimensioned subtype:                   Performing Dimensionality Analysis in GNAT.
                                                               (line  148)
- * Dimension_System aspect:               Performing Dimensionality Analysis in GNAT.
-                                                              (line   13)
- * Dimension_System aspect <1>:           Performing Dimensionality Analysis in GNAT.
-                                                              (line  153)
  * Division by zero:                      Run-Time Checks.    (line    6)
  * division by zero:                      Run-Time Checks.    (line    6)
  * DLL:                                   Calling Conventions.
--- 23010,23025 ----
                                                               (line  153)
  * Dimension Vector (for a dimensioned subtype): Performing Dimensionality Analysis in GNAT.
                                                               (line  153)
+ * Dimension_System aspect:               Performing Dimensionality Analysis in GNAT.
+                                                              (line   13)
+ * Dimension_System aspect <1>:           Performing Dimensionality Analysis in GNAT.
+                                                              (line  153)
  * Dimensionable type:                    Performing Dimensionality Analysis in GNAT.
                                                               (line  148)
  * Dimensionality analysis:               Performing Dimensionality Analysis in GNAT.
                                                               (line    6)
  * Dimensioned subtype:                   Performing Dimensionality Analysis in GNAT.
                                                               (line  148)
  * Division by zero:                      Run-Time Checks.    (line    6)
  * division by zero:                      Run-Time Checks.    (line    6)
  * DLL:                                   Calling Conventions.
*************** Index
*** 23147,23152 ****
--- 23147,23158 ----
                                                               (line   10)
  * GNAT Run-Time Library:                 Rebuilding the GNAT Run-Time Library.
                                                               (line    6)
+ * gnat_argc:                             Command-Line Access.
+                                                              (line   13)
+ * gnat_argv:                             Command-Line Access.
+                                                              (line   13)
+ * GNAT_INIT_SCALARS:                     Switches for gnatbind.
+                                                              (line  300)
  * gnat.adc:                              Using Other File Names.
                                                               (line   35)
  * gnat.adc <1>:                          The Configuration Pragmas Files.
*************** Index
*** 23172,23190 ****
  * gnatprep:                              Preprocessing.      (line   17)
  * gnatprep <1>:                          Preprocessing with gnatprep.
                                                               (line    6)
- * gnat_argc:                             Command-Line Access.
-                                                              (line   13)
- * gnat_argv:                             Command-Line Access.
-                                                              (line   13)
- * GNAT_INIT_SCALARS:                     Switches for gnatbind.
-                                                              (line  300)
  * GNU make:                              Using the GNU make Utility.
                                                               (line    6)
  * GNU/Linux:                             Choosing the Scheduling Policy.
                                                               (line   38)
- * gprof:                                 Profiling.          (line    9)
  * GPR_PROJECT_PATH:                      Installing a library.
                                                               (line    6)
  * Hiding of Declarations:                Warning Message Control.
                                                               (line  471)
  * HT:                                    Source Representation.
--- 23178,23190 ----
  * gnatprep:                              Preprocessing.      (line   17)
  * gnatprep <1>:                          Preprocessing with gnatprep.
                                                               (line    6)
  * GNU make:                              Using the GNU make Utility.
                                                               (line    6)
  * GNU/Linux:                             Choosing the Scheduling Policy.
                                                               (line   38)
  * GPR_PROJECT_PATH:                      Installing a library.
                                                               (line    6)
+ * gprof:                                 Profiling.          (line    9)
  * Hiding of Declarations:                Warning Message Control.
                                                               (line  471)
  * HT:                                    Source Representation.
*************** Index
*** 23276,23284 ****
                                                               (line  211)
  * No information messages for why package spec needs body: Warning Message Control.
                                                               (line 1241)
- * non-symbolic:                          Stack Traceback.    (line   21)
  * No_Strict_Aliasing:                    Optimization and Strict Aliasing.
                                                               (line    6)
  * obsolescent:                           Warning Message Control.
                                                               (line  543)
  * Obsolescent features:                  Warning Message Control.
--- 23276,23284 ----
                                                               (line  211)
  * No information messages for why package spec needs body: Warning Message Control.
                                                               (line 1241)
  * No_Strict_Aliasing:                    Optimization and Strict Aliasing.
                                                               (line    6)
+ * non-symbolic:                          Stack Traceback.    (line   21)
  * obsolescent:                           Warning Message Control.
                                                               (line  543)
  * Obsolescent features:                  Warning Message Control.
*************** Index
*** 23554,23560 ****
  * Validity Checking:                     Validity Checking.  (line    6)
  * varargs function interfaces:           Calling Conventions.
                                                               (line   64)
! * Version skew (avoided by ‘‘gnatmake‘‘): Running a Simple Ada Program.
                                                               (line   58)
  * Volatile parameter:                    The Volatile Parameter.
                                                               (line    6)
--- 23554,23560 ----
  * Validity Checking:                     Validity Checking.  (line    6)
  * varargs function interfaces:           Calling Conventions.
                                                               (line   64)
! * Version skew (avoided by ''gnatmake''): Running a Simple Ada Program.
                                                               (line   58)
  * Volatile parameter:                    The Volatile Parameter.
                                                               (line    6)
*************** Index
*** 23607,25071 ****
                                                               (line   40)
  * Zero-Cost Exceptions:                  Run-Time Libraries. (line   13)
  
!                                                              
  
  
  
  Tag Table:
! Node: Top350
! Ref: gnat_ugn doc634
! Ref: 0634
! Node: About This Guide12144
! Ref: gnat_ugn/about_this_guide doc12248
! Ref: 212248
! Ref: gnat_ugn/about_this_guide about-this-guide12248
! Ref: 312248
! Ref: gnat_ugn/about_this_guide gnat-user-s-guide-for-native-platforms12248
! Ref: 412248
! Ref: gnat_ugn/about_this_guide id112248
! Ref: 512248
! Node: What This Guide Contains13073
! Ref: gnat_ugn/about_this_guide what-this-guide-contains13207
! Ref: 713207
! Node: What You Should Know before Reading This Guide14643
! Ref: gnat_ugn/about_this_guide what-you-should-know-before-reading-this-guide14805
! Ref: 1114805
! Node: Related Information15157
! Ref: gnat_ugn/about_this_guide related-information15306
! Ref: 1215306
! Node: Conventions16192
! Ref: gnat_ugn/about_this_guide conventions16286
! Ref: 1316286
! Node: Getting Started with GNAT17110
! Ref: gnat_ugn/getting_started_with_gnat doc17237
! Ref: 1417237
! Ref: gnat_ugn/getting_started_with_gnat getting-started-with-gnat17237
! Ref: 817237
! Ref: gnat_ugn/getting_started_with_gnat id117237
! Ref: 1517237
! Node: System Requirements17883
! Ref: gnat_ugn/getting_started_with_gnat id217987
! Ref: 1617987
! Ref: gnat_ugn/getting_started_with_gnat system-requirements17987
! Ref: 1717987
! Node: Running GNAT19434
! Ref: gnat_ugn/getting_started_with_gnat id319575
! Ref: 1819575
! Ref: gnat_ugn/getting_started_with_gnat running-gnat19575
! Ref: 1919575
! Node: Running a Simple Ada Program20073
! Ref: gnat_ugn/getting_started_with_gnat id420232
! Ref: 1a20232
! Ref: gnat_ugn/getting_started_with_gnat running-a-simple-ada-program20232
! Ref: 1b20232
! Node: Running a Program with Multiple Units23209
! Ref: gnat_ugn/getting_started_with_gnat id523347
! Ref: 1e23347
! Ref: gnat_ugn/getting_started_with_gnat running-a-program-with-multiple-units23347
! Ref: 1f23347
! Node: The GNAT Compilation Model24956
! Ref: gnat_ugn/the_gnat_compilation_model doc25105
! Ref: 2025105
! Ref: gnat_ugn/the_gnat_compilation_model id125105
! Ref: 2125105
! Ref: gnat_ugn/the_gnat_compilation_model the-gnat-compilation-model25105
! Ref: 925105
! Node: Source Representation26523
! Ref: gnat_ugn/the_gnat_compilation_model id226649
! Ref: 2f26649
! Ref: gnat_ugn/the_gnat_compilation_model source-representation26649
! Ref: 2226649
! Node: Foreign Language Representation29113
! Ref: gnat_ugn/the_gnat_compilation_model foreign-language-representation29280
! Ref: 2329280
! Ref: gnat_ugn/the_gnat_compilation_model id329280
! Ref: 3029280
! Node: Latin-129653
! Ref: gnat_ugn/the_gnat_compilation_model id429756
! Ref: 3229756
! Ref: gnat_ugn/the_gnat_compilation_model latin-129756
! Ref: 3329756
! Node: Other 8-Bit Codes30544
! Ref: gnat_ugn/the_gnat_compilation_model id530680
! Ref: 3430680
! Ref: gnat_ugn/the_gnat_compilation_model other-8-bit-codes30680
! Ref: 3530680
! Node: Wide_Character Encodings32903
! Ref: gnat_ugn/the_gnat_compilation_model id633061
! Ref: 3633061
! Ref: gnat_ugn/the_gnat_compilation_model wide-character-encodings33061
! Ref: 3733061
! Node: Wide_Wide_Character Encodings36901
! Ref: gnat_ugn/the_gnat_compilation_model id737033
! Ref: 3837033
! Ref: gnat_ugn/the_gnat_compilation_model wide-wide-character-encodings37033
! Ref: 3937033
! Node: File Naming Topics and Utilities38761
! Ref: gnat_ugn/the_gnat_compilation_model file-naming-topics-and-utilities38928
! Ref: 2438928
! Ref: gnat_ugn/the_gnat_compilation_model id838928
! Ref: 3a38928
! Node: File Naming Rules39437
! Ref: gnat_ugn/the_gnat_compilation_model file-naming-rules39556
! Ref: 3b39556
! Ref: gnat_ugn/the_gnat_compilation_model id939556
! Ref: 3c39556
! Node: Using Other File Names43087
! Ref: gnat_ugn/the_gnat_compilation_model id1043246
! Ref: 3e43246
! Ref: gnat_ugn/the_gnat_compilation_model using-other-file-names43246
! Ref: 1c43246
! Node: Alternative File Naming Schemes45494
! Ref: gnat_ugn/the_gnat_compilation_model alternative-file-naming-schemes45692
! Ref: 4045692
! Ref: gnat_ugn/the_gnat_compilation_model id1145692
! Ref: 4145692
! Node: Handling Arbitrary File Naming Conventions with gnatname50834
! Ref: gnat_ugn/the_gnat_compilation_model handling-arbitrary-file-naming-conventions-with-gnatname51041
! Ref: 4251041
! Ref: gnat_ugn/the_gnat_compilation_model id1251041
! Ref: 4351041
! Node: Arbitrary File Naming Conventions51302
! Ref: gnat_ugn/the_gnat_compilation_model arbitrary-file-naming-conventions51455
! Ref: 4451455
! Ref: gnat_ugn/the_gnat_compilation_model id1351455
! Ref: 4551455
! Node: Running gnatname52595
! Ref: gnat_ugn/the_gnat_compilation_model id1452778
! Ref: 4652778
! Ref: gnat_ugn/the_gnat_compilation_model running-gnatname52778
! Ref: 4752778
! Node: Switches for gnatname54644
! Ref: gnat_ugn/the_gnat_compilation_model id1554820
! Ref: 4854820
! Ref: gnat_ugn/the_gnat_compilation_model switches-for-gnatname54820
! Ref: 4954820
! Node: Examples of gnatname Usage59618
! Ref: gnat_ugn/the_gnat_compilation_model examples-of-gnatname-usage59769
! Ref: 4a59769
! Ref: gnat_ugn/the_gnat_compilation_model id1659769
! Ref: 4b59769
! Node: File Name Krunching with gnatkr60464
! Ref: gnat_ugn/the_gnat_compilation_model file-name-krunching-with-gnatkr60668
! Ref: 4c60668
! Ref: gnat_ugn/the_gnat_compilation_model id1760668
! Ref: 4d60668
! Node: About gnatkr61129
! Ref: gnat_ugn/the_gnat_compilation_model about-gnatkr61232
! Ref: 4e61232
! Ref: gnat_ugn/the_gnat_compilation_model id1861232
! Ref: 4f61232
! Node: Using gnatkr62213
! Ref: gnat_ugn/the_gnat_compilation_model id1962341
! Ref: 5062341
! Ref: gnat_ugn/the_gnat_compilation_model using-gnatkr62341
! Ref: 3d62341
! Node: Krunching Method63865
! Ref: gnat_ugn/the_gnat_compilation_model id2064005
! Ref: 5164005
! Ref: gnat_ugn/the_gnat_compilation_model krunching-method64005
! Ref: 5264005
! Node: Examples of gnatkr Usage67493
! Ref: gnat_ugn/the_gnat_compilation_model examples-of-gnatkr-usage67612
! Ref: 5367612
! Ref: gnat_ugn/the_gnat_compilation_model id2167612
! Ref: 5467612
! Node: Renaming Files with gnatchop68059
! Ref: gnat_ugn/the_gnat_compilation_model id2268198
! Ref: 5568198
! Ref: gnat_ugn/the_gnat_compilation_model renaming-files-with-gnatchop68198
! Ref: 1d68198
! Node: Handling Files with Multiple Units68663
! Ref: gnat_ugn/the_gnat_compilation_model handling-files-with-multiple-units68811
! Ref: 5668811
! Ref: gnat_ugn/the_gnat_compilation_model id2368811
! Ref: 5768811
! Node: Operating gnatchop in Compilation Mode70047
! Ref: gnat_ugn/the_gnat_compilation_model id2470229
! Ref: 5870229
! Ref: gnat_ugn/the_gnat_compilation_model operating-gnatchop-in-compilation-mode70229
! Ref: 5970229
! Node: Command Line for gnatchop73377
! Ref: gnat_ugn/the_gnat_compilation_model command-line-for-gnatchop73546
! Ref: 5a73546
! Ref: gnat_ugn/the_gnat_compilation_model id2573546
! Ref: 5b73546
! Node: Switches for gnatchop75367
! Ref: gnat_ugn/the_gnat_compilation_model id2675524
! Ref: 5c75524
! Ref: gnat_ugn/the_gnat_compilation_model switches-for-gnatchop75524
! Ref: 5d75524
! Node: Examples of gnatchop Usage79547
! Ref: gnat_ugn/the_gnat_compilation_model examples-of-gnatchop-usage79670
! Ref: 5e79670
! Ref: gnat_ugn/the_gnat_compilation_model id2779670
! Ref: 5f79670
! Node: Configuration Pragmas80910
! Ref: gnat_ugn/the_gnat_compilation_model configuration-pragmas81069
! Ref: 2581069
! Ref: gnat_ugn/the_gnat_compilation_model id2881069
! Ref: 6081069
! Node: Handling of Configuration Pragmas83314
! Ref: gnat_ugn/the_gnat_compilation_model handling-of-configuration-pragmas83447
! Ref: 3f83447
! Ref: gnat_ugn/the_gnat_compilation_model id2983447
! Ref: 6183447
! Node: The Configuration Pragmas Files85420
! Ref: gnat_ugn/the_gnat_compilation_model id3085553
! Ref: 6285553
! Ref: gnat_ugn/the_gnat_compilation_model the-configuration-pragmas-files85553
! Ref: 6385553
! Node: Generating Object Files87749
! Ref: gnat_ugn/the_gnat_compilation_model generating-object-files87895
! Ref: 2687895
! Ref: gnat_ugn/the_gnat_compilation_model id3187895
! Ref: 6487895
! Node: Source Dependencies90469
! Ref: gnat_ugn/the_gnat_compilation_model id3290627
! Ref: 6590627
! Ref: gnat_ugn/the_gnat_compilation_model source-dependencies90627
! Ref: 2790627
! Node: The Ada Library Information Files94323
! Ref: gnat_ugn/the_gnat_compilation_model id3394480
! Ref: 6694480
! Ref: gnat_ugn/the_gnat_compilation_model the-ada-library-information-files94480
! Ref: 2894480
! Node: Binding an Ada Program96501
! Ref: gnat_ugn/the_gnat_compilation_model binding-an-ada-program96657
! Ref: 2996657
! Ref: gnat_ugn/the_gnat_compilation_model id3496657
! Ref: 6796657
! Node: GNAT and Libraries98359
! Ref: gnat_ugn/the_gnat_compilation_model gnat-and-libraries98505
! Ref: 2a98505
! Ref: gnat_ugn/the_gnat_compilation_model id3598505
! Ref: 6898505
! Node: Introduction to Libraries in GNAT98991
! Ref: gnat_ugn/the_gnat_compilation_model id3699111
! Ref: 6999111
! Ref: gnat_ugn/the_gnat_compilation_model introduction-to-libraries-in-gnat99111
! Ref: 6a99111
! Node: General Ada Libraries101256
! Ref: gnat_ugn/the_gnat_compilation_model general-ada-libraries101410
! Ref: 6c101410
! Ref: gnat_ugn/the_gnat_compilation_model id37101410
! Ref: 6d101410
! Node: Building a library101545
! Ref: gnat_ugn/the_gnat_compilation_model building-a-library101652
! Ref: 6e101652
! Ref: gnat_ugn/the_gnat_compilation_model id38101652
! Ref: 6f101652
! Node: Installing a library105536
! Ref: gnat_ugn/the_gnat_compilation_model id39105667
! Ref: 71105667
! Ref: gnat_ugn/the_gnat_compilation_model installing-a-library105667
! Ref: 72105667
! Node: Using a library108184
! Ref: gnat_ugn/the_gnat_compilation_model id40108288
! Ref: 74108288
! Ref: gnat_ugn/the_gnat_compilation_model using-a-library108288
! Ref: 75108288
! Node: Stand-alone Ada Libraries110866
! Ref: gnat_ugn/the_gnat_compilation_model id41111023
! Ref: 77111023
! Ref: gnat_ugn/the_gnat_compilation_model stand-alone-ada-libraries111023
! Ref: 6b111023
! Node: Introduction to Stand-alone Libraries111284
! Ref: gnat_ugn/the_gnat_compilation_model id42111424
! Ref: 78111424
! Ref: gnat_ugn/the_gnat_compilation_model introduction-to-stand-alone-libraries111424
! Ref: 79111424
! Node: Building a Stand-alone Library113046
! Ref: gnat_ugn/the_gnat_compilation_model building-a-stand-alone-library113257
! Ref: 7a113257
! Ref: gnat_ugn/the_gnat_compilation_model id43113257
! Ref: 7b113257
! Node: Creating a Stand-alone Library to be used in a non-Ada context118115
! Ref: gnat_ugn/the_gnat_compilation_model creating-a-stand-alone-library-to-be-used-in-a-non-ada-context118326
! Ref: 7c118326
! Ref: gnat_ugn/the_gnat_compilation_model id44118326
! Ref: 7d118326
! Node: Restrictions in Stand-alone Libraries121107
! Ref: gnat_ugn/the_gnat_compilation_model id45121279
! Ref: 7e121279
! Ref: gnat_ugn/the_gnat_compilation_model restrictions-in-stand-alone-libraries121279
! Ref: 7f121279
! Node: Rebuilding the GNAT Run-Time Library122602
! Ref: gnat_ugn/the_gnat_compilation_model id46122729
! Ref: 80122729
! Ref: gnat_ugn/the_gnat_compilation_model rebuilding-the-gnat-run-time-library122729
! Ref: 81122729
! Node: Conditional Compilation123571
! Ref: gnat_ugn/the_gnat_compilation_model conditional-compilation123721
! Ref: 2b123721
! Ref: gnat_ugn/the_gnat_compilation_model id47123721
! Ref: 82123721
! Node: Modeling Conditional Compilation in Ada124027
! Ref: gnat_ugn/the_gnat_compilation_model id48124164
! Ref: 83124164
! Ref: gnat_ugn/the_gnat_compilation_model modeling-conditional-compilation-in-ada124164
! Ref: 84124164
! Node: Use of Boolean Constants125724
! Ref: gnat_ugn/the_gnat_compilation_model id49125861
! Ref: 85125861
! Ref: gnat_ugn/the_gnat_compilation_model use-of-boolean-constants125861
! Ref: 86125861
! Node: Debugging - A Special Case127174
! Ref: gnat_ugn/the_gnat_compilation_model debugging-a-special-case127349
! Ref: 87127349
! Ref: gnat_ugn/the_gnat_compilation_model id50127349
! Ref: 88127349
! Node: Conditionalizing Declarations130856
! Ref: gnat_ugn/the_gnat_compilation_model conditionalizing-declarations131041
! Ref: 89131041
! Ref: gnat_ugn/the_gnat_compilation_model id51131041
! Ref: 8a131041
! Node: Use of Alternative Implementations132769
! Ref: gnat_ugn/the_gnat_compilation_model id52132941
! Ref: 8b132941
! Ref: gnat_ugn/the_gnat_compilation_model use-of-alternative-implementations132941
! Ref: 8c132941
! Node: Preprocessing137137
! Ref: gnat_ugn/the_gnat_compilation_model id53137271
! Ref: 8d137271
! Ref: gnat_ugn/the_gnat_compilation_model preprocessing137271
! Ref: 8e137271
! Node: Preprocessing with gnatprep138953
! Ref: gnat_ugn/the_gnat_compilation_model id54139123
! Ref: 91139123
! Ref: gnat_ugn/the_gnat_compilation_model preprocessing-with-gnatprep139123
! Ref: 8f139123
! Node: Preprocessing Symbols139642
! Ref: gnat_ugn/the_gnat_compilation_model id55139752
! Ref: 92139752
! Ref: gnat_ugn/the_gnat_compilation_model preprocessing-symbols139752
! Ref: 93139752
! Node: Using gnatprep140122
! Ref: gnat_ugn/the_gnat_compilation_model id56140262
! Ref: 94140262
! Ref: gnat_ugn/the_gnat_compilation_model using-gnatprep140262
! Ref: 95140262
! Node: Switches for gnatprep141172
! Ref: gnat_ugn/the_gnat_compilation_model id57141315
! Ref: 96141315
! Ref: gnat_ugn/the_gnat_compilation_model switches-for-gnatprep141315
! Ref: 97141315
! Node: Form of Definitions File144430
! Ref: gnat_ugn/the_gnat_compilation_model form-of-definitions-file144590
! Ref: 98144590
! Ref: gnat_ugn/the_gnat_compilation_model id58144590
! Ref: 99144590
! Node: Form of Input Text for gnatprep145152
! Ref: gnat_ugn/the_gnat_compilation_model form-of-input-text-for-gnatprep145282
! Ref: 9a145282
! Ref: gnat_ugn/the_gnat_compilation_model id59145282
! Ref: 9b145282
! Node: Integrated Preprocessing149845
! Ref: gnat_ugn/the_gnat_compilation_model id60149967
! Ref: 9c149967
! Ref: gnat_ugn/the_gnat_compilation_model integrated-preprocessing149967
! Ref: 90149967
! Node: Mixed Language Programming158359
! Ref: gnat_ugn/the_gnat_compilation_model id61158524
! Ref: 9d158524
! Ref: gnat_ugn/the_gnat_compilation_model mixed-language-programming158524
! Ref: 2c158524
! Node: Interfacing to C158892
! Ref: gnat_ugn/the_gnat_compilation_model id62159001
! Ref: 9e159001
! Ref: gnat_ugn/the_gnat_compilation_model interfacing-to-c159001
! Ref: 9f159001
! Node: Calling Conventions164211
! Ref: gnat_ugn/the_gnat_compilation_model calling-conventions164364
! Ref: a1164364
! Ref: gnat_ugn/the_gnat_compilation_model id63164364
! Ref: a2164364
! Node: Building Mixed Ada and C++ Programs172186
! Ref: gnat_ugn/the_gnat_compilation_model building-mixed-ada-and-c-programs172368
! Ref: a3172368
! Ref: gnat_ugn/the_gnat_compilation_model id64172368
! Ref: a4172368
! Node: Interfacing to C++172847
! Ref: gnat_ugn/the_gnat_compilation_model id65172981
! Ref: a5172981
! Ref: gnat_ugn/the_gnat_compilation_model id66172981
! Ref: a6172981
! Node: Linking a Mixed C++ & Ada Program174094
! Ref: gnat_ugn/the_gnat_compilation_model linking-a-mixed-c-ada-program174253
! Ref: a8174253
! Ref: gnat_ugn/the_gnat_compilation_model linking-a-mixed-c-and-ada-program174253
! Ref: a9174253
! Node: A Simple Example178291
! Ref: gnat_ugn/the_gnat_compilation_model a-simple-example178465
! Ref: aa178465
! Ref: gnat_ugn/the_gnat_compilation_model id67178465
! Ref: ab178465
! Node: Interfacing with C++ constructors181184
! Ref: gnat_ugn/the_gnat_compilation_model id68181364
! Ref: ac181364
! Ref: gnat_ugn/the_gnat_compilation_model interfacing-with-c-constructors181364
! Ref: ad181364
! Node: Interfacing with C++ at the Class Level188103
! Ref: gnat_ugn/the_gnat_compilation_model id69188258
! Ref: af188258
! Ref: gnat_ugn/the_gnat_compilation_model interfacing-with-c-at-the-class-level188258
! Ref: ae188258
! Node: Generating Ada Bindings for C and C++ headers196955
! Ref: gnat_ugn/the_gnat_compilation_model generating-ada-bindings-for-c-and-c-headers197161
! Ref: a7197161
! Ref: gnat_ugn/the_gnat_compilation_model id70197161
! Ref: b0197161
! Node: Running the Binding Generator198448
! Ref: gnat_ugn/the_gnat_compilation_model id71198605
! Ref: b1198605
! Ref: gnat_ugn/the_gnat_compilation_model running-the-binding-generator198605
! Ref: b2198605
! Node: Generating Bindings for C++ Headers201184
! Ref: gnat_ugn/the_gnat_compilation_model generating-bindings-for-c-headers201358
! Ref: b3201358
! Ref: gnat_ugn/the_gnat_compilation_model id72201358
! Ref: b4201358
! Node: Switches204287
! Ref: gnat_ugn/the_gnat_compilation_model switches204423
! Ref: b5204423
! Ref: gnat_ugn/the_gnat_compilation_model switches-for-ada-binding-generation204423
! Ref: b6204423
! Node: Generating C Headers for Ada Specifications204994
! Ref: gnat_ugn/the_gnat_compilation_model generating-c-headers-for-ada-specifications205156
! Ref: b7205156
! Ref: gnat_ugn/the_gnat_compilation_model id73205156
! Ref: b8205156
! Node: Running the C Header Generator205659
! Ref: gnat_ugn/the_gnat_compilation_model running-the-c-header-generator205771
! Ref: b9205771
! Node: GNAT and Other Compilation Models207551
! Ref: gnat_ugn/the_gnat_compilation_model gnat-and-other-compilation-models207729
! Ref: 2d207729
! Ref: gnat_ugn/the_gnat_compilation_model id74207729
! Ref: ba207729
! Node: Comparison between GNAT and C/C++ Compilation Models208163
! Ref: gnat_ugn/the_gnat_compilation_model comparison-between-gnat-and-c-c-compilation-models208355
! Ref: bb208355
! Ref: gnat_ugn/the_gnat_compilation_model id75208355
! Ref: bc208355
! Node: Comparison between GNAT and Conventional Ada Library Models209880
! Ref: gnat_ugn/the_gnat_compilation_model comparison-between-gnat-and-conventional-ada-library-models210072
! Ref: bd210072
! Ref: gnat_ugn/the_gnat_compilation_model id76210072
! Ref: be210072
! Node: Using GNAT Files with External Tools212459
! Ref: gnat_ugn/the_gnat_compilation_model id77212602
! Ref: bf212602
! Ref: gnat_ugn/the_gnat_compilation_model using-gnat-files-with-external-tools212602
! Ref: 2e212602
! Node: Using Other Utility Programs with GNAT212898
! Ref: gnat_ugn/the_gnat_compilation_model id78213061
! Ref: c0213061
! Ref: gnat_ugn/the_gnat_compilation_model using-other-utility-programs-with-gnat213061
! Ref: c1213061
! Node: The External Symbol Naming Scheme of GNAT213620
! Ref: gnat_ugn/the_gnat_compilation_model id79213783
! Ref: c2213783
! Ref: gnat_ugn/the_gnat_compilation_model the-external-symbol-naming-scheme-of-gnat213783
! Ref: c3213783
! Node: Building Executable Programs with GNAT215693
! Ref: gnat_ugn/building_executable_programs_with_gnat doc215838
! Ref: c4215838
! Ref: gnat_ugn/building_executable_programs_with_gnat building-executable-programs-with-gnat215838
! Ref: a215838
! Ref: gnat_ugn/building_executable_programs_with_gnat id1215838
! Ref: c5215838
! Node: Building with gnatmake216753
! Ref: gnat_ugn/building_executable_programs_with_gnat building-with-gnatmake216879
! Ref: ca216879
! Ref: gnat_ugn/building_executable_programs_with_gnat the-gnat-make-program-gnatmake216879
! Ref: c6216879
! Node: Running gnatmake218508
! Ref: gnat_ugn/building_executable_programs_with_gnat id2218615
! Ref: cb218615
! Ref: gnat_ugn/building_executable_programs_with_gnat running-gnatmake218615
! Ref: cc218615
! Node: Switches for gnatmake220089
! Ref: gnat_ugn/building_executable_programs_with_gnat id3220231
! Ref: cd220231
! Ref: gnat_ugn/building_executable_programs_with_gnat switches-for-gnatmake220231
! Ref: ce220231
! Node: Mode Switches for gnatmake241581
! Ref: gnat_ugn/building_executable_programs_with_gnat id4241732
! Ref: d0241732
! Ref: gnat_ugn/building_executable_programs_with_gnat mode-switches-for-gnatmake241732
! Ref: d1241732
! Node: Notes on the Command Line243027
! Ref: gnat_ugn/building_executable_programs_with_gnat id5243175
! Ref: d2243175
! Ref: gnat_ugn/building_executable_programs_with_gnat notes-on-the-command-line243175
! Ref: d3243175
! Node: How gnatmake Works245660
! Ref: gnat_ugn/building_executable_programs_with_gnat how-gnatmake-works245808
! Ref: d4245808
! Ref: gnat_ugn/building_executable_programs_with_gnat id6245808
! Ref: d5245808
! Node: Examples of gnatmake Usage248163
! Ref: gnat_ugn/building_executable_programs_with_gnat examples-of-gnatmake-usage248277
! Ref: d6248277
! Ref: gnat_ugn/building_executable_programs_with_gnat id7248277
! Ref: d7248277
! Node: Compiling with gcc249372
! Ref: gnat_ugn/building_executable_programs_with_gnat compiling-with-gcc249524
! Ref: c7249524
! Ref: gnat_ugn/building_executable_programs_with_gnat id8249524
! Ref: d8249524
! Node: Compiling Programs249925
! Ref: gnat_ugn/building_executable_programs_with_gnat compiling-programs250050
! Ref: d9250050
! Ref: gnat_ugn/building_executable_programs_with_gnat id9250050
! Ref: da250050
! Node: Search Paths and the Run-Time Library RTL253497
! Ref: gnat_ugn/building_executable_programs_with_gnat id10253658
! Ref: dc253658
! Ref: gnat_ugn/building_executable_programs_with_gnat search-paths-and-the-run-time-library-rtl253658
! Ref: 73253658
! Node: Order of Compilation Issues257091
! Ref: gnat_ugn/building_executable_programs_with_gnat id11257242
! Ref: dd257242
! Ref: gnat_ugn/building_executable_programs_with_gnat order-of-compilation-issues257242
! Ref: de257242
! Node: Examples258815
! Ref: gnat_ugn/building_executable_programs_with_gnat examples258916
! Ref: df258916
! Ref: gnat_ugn/building_executable_programs_with_gnat id12258916
! Ref: e0258916
! Node: Compiler Switches259398
! Ref: gnat_ugn/building_executable_programs_with_gnat compiler-switches259543
! Ref: e1259543
! Ref: gnat_ugn/building_executable_programs_with_gnat switches-for-gcc259543
! Ref: db259543
! Node: Alphabetical List of All Switches260697
! Ref: gnat_ugn/building_executable_programs_with_gnat alphabetical-list-of-all-switches260827
! Ref: e2260827
! Ref: gnat_ugn/building_executable_programs_with_gnat id13260827
! Ref: e3260827
! Node: Output and Error Message Control297403
! Ref: gnat_ugn/building_executable_programs_with_gnat id14297565
! Ref: ee297565
! Ref: gnat_ugn/building_executable_programs_with_gnat output-and-error-message-control297565
! Ref: ef297565
! Node: Warning Message Control305641
! Ref: gnat_ugn/building_executable_programs_with_gnat id15305801
! Ref: f0305801
! Ref: gnat_ugn/building_executable_programs_with_gnat warning-message-control305801
! Ref: eb305801
! Node: Debugging and Assertion Control356975
! Ref: gnat_ugn/building_executable_programs_with_gnat debugging-and-assertion-control357120
! Ref: f1357120
! Ref: gnat_ugn/building_executable_programs_with_gnat id16357120
! Ref: f2357120
! Node: Validity Checking360567
! Ref: gnat_ugn/building_executable_programs_with_gnat id17360703
! Ref: f3360703
! Ref: gnat_ugn/building_executable_programs_with_gnat validity-checking360703
! Ref: e7360703
! Node: Style Checking370795
! Ref: gnat_ugn/building_executable_programs_with_gnat id18370915
! Ref: f4370915
! Ref: gnat_ugn/building_executable_programs_with_gnat style-checking370915
! Ref: ec370915
! Node: Run-Time Checks388664
! Ref: gnat_ugn/building_executable_programs_with_gnat id19388796
! Ref: f5388796
! Ref: gnat_ugn/building_executable_programs_with_gnat run-time-checks388796
! Ref: ea388796
! Node: Using gcc for Syntax Checking395505
! Ref: gnat_ugn/building_executable_programs_with_gnat id20395654
! Ref: f6395654
! Ref: gnat_ugn/building_executable_programs_with_gnat using-gcc-for-syntax-checking395654
! Ref: f7395654
! Node: Using gcc for Semantic Checking397344
! Ref: gnat_ugn/building_executable_programs_with_gnat id21397513
! Ref: f8397513
! Ref: gnat_ugn/building_executable_programs_with_gnat using-gcc-for-semantic-checking397513
! Ref: f9397513
! Node: Compiling Different Versions of Ada398871
! Ref: gnat_ugn/building_executable_programs_with_gnat compiling-different-versions-of-ada399032
! Ref: 6399032
! Ref: gnat_ugn/building_executable_programs_with_gnat id22399032
! Ref: fa399032
! Node: Character Set Control403297
! Ref: gnat_ugn/building_executable_programs_with_gnat character-set-control403446
! Ref: 31403446
! Ref: gnat_ugn/building_executable_programs_with_gnat id23403446
! Ref: fb403446
! Node: File Naming Control408832
! Ref: gnat_ugn/building_executable_programs_with_gnat file-naming-control408973
! Ref: fc408973
! Ref: gnat_ugn/building_executable_programs_with_gnat id24408973
! Ref: fd408973
! Node: Subprogram Inlining Control409381
! Ref: gnat_ugn/building_executable_programs_with_gnat id25409525
! Ref: fe409525
! Ref: gnat_ugn/building_executable_programs_with_gnat subprogram-inlining-control409525
! Ref: ff409525
! Node: Auxiliary Output Control411402
! Ref: gnat_ugn/building_executable_programs_with_gnat auxiliary-output-control411544
! Ref: 101411544
! Ref: gnat_ugn/building_executable_programs_with_gnat id26411544
! Ref: 102411544
! Node: Debugging Control412721
! Ref: gnat_ugn/building_executable_programs_with_gnat debugging-control412862
! Ref: 103412862
! Ref: gnat_ugn/building_executable_programs_with_gnat id27412862
! Ref: 104412862
! Node: Exception Handling Control424716
! Ref: gnat_ugn/building_executable_programs_with_gnat exception-handling-control424863
! Ref: 105424863
! Ref: gnat_ugn/building_executable_programs_with_gnat id28424863
! Ref: 106424863
! Node: Units to Sources Mapping Files427540
! Ref: gnat_ugn/building_executable_programs_with_gnat id29427693
! Ref: 107427693
! Ref: gnat_ugn/building_executable_programs_with_gnat units-to-sources-mapping-files427693
! Ref: e8427693
! Node: Code Generation Control429632
! Ref: gnat_ugn/building_executable_programs_with_gnat code-generation-control429750
! Ref: 108429750
! Ref: gnat_ugn/building_executable_programs_with_gnat id30429750
! Ref: 109429750
! Node: Linker Switches430922
! Ref: gnat_ugn/building_executable_programs_with_gnat id31431070
! Ref: 10a431070
! Ref: gnat_ugn/building_executable_programs_with_gnat linker-switches431070
! Ref: 10b431070
! Node: Binding with gnatbind431432
! Ref: gnat_ugn/building_executable_programs_with_gnat binding-with-gnatbind431584
! Ref: c8431584
! Ref: gnat_ugn/building_executable_programs_with_gnat id32431584
! Ref: 10c431584
! Node: Running gnatbind433108
! Ref: gnat_ugn/building_executable_programs_with_gnat id33433214
! Ref: 10d433214
! Ref: gnat_ugn/building_executable_programs_with_gnat running-gnatbind433214
! Ref: 10e433214
! Node: Switches for gnatbind436246
! Ref: gnat_ugn/building_executable_programs_with_gnat id34436380
! Ref: 10f436380
! Ref: gnat_ugn/building_executable_programs_with_gnat switches-for-gnatbind436380
! Ref: 110436380
! Node: Consistency-Checking Modes449727
! Ref: gnat_ugn/building_executable_programs_with_gnat consistency-checking-modes449850
! Ref: 114449850
! Ref: gnat_ugn/building_executable_programs_with_gnat id35449850
! Ref: 115449850
! Node: Binder Error Message Control451669
! Ref: gnat_ugn/building_executable_programs_with_gnat binder-error-message-control451820
! Ref: 116451820
! Ref: gnat_ugn/building_executable_programs_with_gnat id36451820
! Ref: 117451820
! Node: Elaboration Control454064
! Ref: gnat_ugn/building_executable_programs_with_gnat elaboration-control454203
! Ref: 111454203
! Ref: gnat_ugn/building_executable_programs_with_gnat id37454203
! Ref: 118454203
! Node: Output Control457505
! Ref: gnat_ugn/building_executable_programs_with_gnat id38457642
! Ref: 119457642
! Ref: gnat_ugn/building_executable_programs_with_gnat output-control457642
! Ref: 11a457642
! Node: Dynamic Allocation Control459639
! Ref: gnat_ugn/building_executable_programs_with_gnat dynamic-allocation-control459791
! Ref: 112459791
! Ref: gnat_ugn/building_executable_programs_with_gnat id39459791
! Ref: 11b459791
! Node: Binding with Non-Ada Main Programs460412
! Ref: gnat_ugn/building_executable_programs_with_gnat binding-with-non-ada-main-programs460590
! Ref: a0460590
! Ref: gnat_ugn/building_executable_programs_with_gnat id40460590
! Ref: 11c460590
! Node: Binding Programs with No Main Subprogram463604
! Ref: gnat_ugn/building_executable_programs_with_gnat binding-programs-with-no-main-subprogram463747
! Ref: 11d463747
! Ref: gnat_ugn/building_executable_programs_with_gnat id41463747
! Ref: 11e463747
! Node: Command-Line Access464615
! Ref: gnat_ugn/building_executable_programs_with_gnat command-line-access464758
! Ref: 11f464758
! Ref: gnat_ugn/building_executable_programs_with_gnat id42464758
! Ref: 120464758
! Node: Search Paths for gnatbind465676
! Ref: gnat_ugn/building_executable_programs_with_gnat id43465824
! Ref: 121465824
! Ref: gnat_ugn/building_executable_programs_with_gnat search-paths-for-gnatbind465824
! Ref: 76465824
! Node: Examples of gnatbind Usage468641
! Ref: gnat_ugn/building_executable_programs_with_gnat examples-of-gnatbind-usage468761
! Ref: 122468761
! Ref: gnat_ugn/building_executable_programs_with_gnat id44468761
! Ref: 123468761
! Node: Linking with gnatlink469609
! Ref: gnat_ugn/building_executable_programs_with_gnat id45469772
! Ref: 124469772
! Ref: gnat_ugn/building_executable_programs_with_gnat linking-with-gnatlink469772
! Ref: c9469772
! Node: Running gnatlink470308
! Ref: gnat_ugn/building_executable_programs_with_gnat id46470414
! Ref: 125470414
! Ref: gnat_ugn/building_executable_programs_with_gnat running-gnatlink470414
! Ref: 126470414
! Node: Switches for gnatlink472886
! Ref: gnat_ugn/building_executable_programs_with_gnat id47472992
! Ref: 129472992
! Ref: gnat_ugn/building_executable_programs_with_gnat switches-for-gnatlink472992
! Ref: 12a472992
! Node: Using the GNU make Utility477702
! Ref: gnat_ugn/building_executable_programs_with_gnat id48477835
! Ref: 12b477835
! Ref: gnat_ugn/building_executable_programs_with_gnat using-the-gnu-make-utility477835
! Ref: 70477835
! Node: Using gnatmake in a Makefile478523
! Ref: gnat_ugn/building_executable_programs_with_gnat id49478669
! Ref: 12c478669
! Ref: gnat_ugn/building_executable_programs_with_gnat using-gnatmake-in-a-makefile478669
! Ref: 12d478669
! Node: Automatically Creating a List of Directories482697
! Ref: gnat_ugn/building_executable_programs_with_gnat automatically-creating-a-list-of-directories482888
! Ref: 12e482888
! Ref: gnat_ugn/building_executable_programs_with_gnat id50482888
! Ref: 12f482888
! Node: Generating the Command Line Switches485843
! Ref: gnat_ugn/building_executable_programs_with_gnat generating-the-command-line-switches486043
! Ref: 130486043
! Ref: gnat_ugn/building_executable_programs_with_gnat id51486043
! Ref: 131486043
! Node: Overcoming Command Line Length Limits486821
! Ref: gnat_ugn/building_executable_programs_with_gnat id52486968
! Ref: 132486968
! Ref: gnat_ugn/building_executable_programs_with_gnat overcoming-command-line-length-limits486968
! Ref: 133486968
! Node: GNAT Utility Programs489273
! Ref: gnat_ugn/gnat_utility_programs doc489418
! Ref: 134489418
! Ref: gnat_ugn/gnat_utility_programs gnat-utility-programs489418
! Ref: b489418
! Ref: gnat_ugn/gnat_utility_programs id1489418
! Ref: 135489418
! Node: The File Cleanup Utility gnatclean489985
! Ref: gnat_ugn/gnat_utility_programs id2490119
! Ref: 138490119
! Ref: gnat_ugn/gnat_utility_programs the-file-cleanup-utility-gnatclean490119
! Ref: 136490119
! Node: Running gnatclean490530
! Ref: gnat_ugn/gnat_utility_programs id3490651
! Ref: 139490651
! Ref: gnat_ugn/gnat_utility_programs running-gnatclean490651
! Ref: 13a490651
! Node: Switches for gnatclean491300
! Ref: gnat_ugn/gnat_utility_programs id4491421
! Ref: 13b491421
! Ref: gnat_ugn/gnat_utility_programs switches-for-gnatclean491421
! Ref: 13c491421
! Node: The GNAT Library Browser gnatls494561
! Ref: gnat_ugn/gnat_utility_programs id5494695
! Ref: 13d494695
! Ref: gnat_ugn/gnat_utility_programs the-gnat-library-browser-gnatls494695
! Ref: 137494695
! Node: Running gnatls495101
! Ref: gnat_ugn/gnat_utility_programs id6495213
! Ref: 13e495213
! Ref: gnat_ugn/gnat_utility_programs running-gnatls495213
! Ref: 13f495213
! Node: Switches for gnatls497722
! Ref: gnat_ugn/gnat_utility_programs id7497866
! Ref: 140497866
! Ref: gnat_ugn/gnat_utility_programs switches-for-gnatls497866
! Ref: 141497866
! Node: Example of gnatls Usage500324
! Ref: gnat_ugn/gnat_utility_programs example-of-gnatls-usage500445
! Ref: 142500445
! Ref: gnat_ugn/gnat_utility_programs id8500445
! Ref: 143500445
! Node: GNAT and Program Execution502848
! Ref: gnat_ugn/gnat_and_program_execution doc502984
! Ref: 144502984
! Ref: gnat_ugn/gnat_and_program_execution gnat-and-program-execution502984
! Ref: c502984
! Ref: gnat_ugn/gnat_and_program_execution id1502984
! Ref: 145502984
! Node: Running and Debugging Ada Programs503628
! Ref: gnat_ugn/gnat_and_program_execution id2503745
! Ref: 146503745
! Ref: gnat_ugn/gnat_and_program_execution running-and-debugging-ada-programs503745
! Ref: 14d503745
! Node: The GNAT Debugger GDB505115
! Ref: gnat_ugn/gnat_and_program_execution id3505229
! Ref: 14e505229
! Ref: gnat_ugn/gnat_and_program_execution the-gnat-debugger-gdb505229
! Ref: 14f505229
! Node: Running GDB508294
! Ref: gnat_ugn/gnat_and_program_execution id4508445
! Ref: 150508445
! Ref: gnat_ugn/gnat_and_program_execution running-gdb508445
! Ref: 151508445
! Node: Introduction to GDB Commands509238
! Ref: gnat_ugn/gnat_and_program_execution id5509389
! Ref: 152509389
! Ref: gnat_ugn/gnat_and_program_execution introduction-to-gdb-commands509389
! Ref: 153509389
! Node: Using Ada Expressions515345
! Ref: gnat_ugn/gnat_and_program_execution id6515517
! Ref: 154515517
! Ref: gnat_ugn/gnat_and_program_execution using-ada-expressions515517
! Ref: 155515517
! Node: Calling User-Defined Subprograms516632
! Ref: gnat_ugn/gnat_and_program_execution calling-user-defined-subprograms516812
! Ref: 156516812
! Ref: gnat_ugn/gnat_and_program_execution id7516812
! Ref: 157516812
! Node: Using the next Command in a Function519579
! Ref: gnat_ugn/gnat_and_program_execution id8519777
! Ref: 158519777
! Ref: gnat_ugn/gnat_and_program_execution using-the-next-command-in-a-function519777
! Ref: 159519777
! Node: Stopping When Ada Exceptions Are Raised520805
! Ref: gnat_ugn/gnat_and_program_execution id9520980
! Ref: 15a520980
! Ref: gnat_ugn/gnat_and_program_execution stopping-when-ada-exceptions-are-raised520980
! Ref: 15b520980
! Node: Ada Tasks522023
! Ref: gnat_ugn/gnat_and_program_execution ada-tasks522185
! Ref: 15c522185
! Ref: gnat_ugn/gnat_and_program_execution id10522185
! Ref: 15d522185
! Node: Debugging Generic Units524429
! Ref: gnat_ugn/gnat_and_program_execution debugging-generic-units524583
! Ref: 15e524583
! Ref: gnat_ugn/gnat_and_program_execution id11524583
! Ref: 15f524583
! Node: Remote Debugging with gdbserver525901
! Ref: gnat_ugn/gnat_and_program_execution id12526095
! Ref: 160526095
! Ref: gnat_ugn/gnat_and_program_execution remote-debugging-with-gdbserver526095
! Ref: 161526095
! Node: GNAT Abnormal Termination or Failure to Terminate528031
! Ref: gnat_ugn/gnat_and_program_execution gnat-abnormal-termination-or-failure-to-terminate528242
! Ref: 162528242
! Ref: gnat_ugn/gnat_and_program_execution id13528242
! Ref: 163528242
! Node: Naming Conventions for GNAT Source Files530721
! Ref: gnat_ugn/gnat_and_program_execution id14530939
! Ref: 164530939
! Ref: gnat_ugn/gnat_and_program_execution naming-conventions-for-gnat-source-files530939
! Ref: 165530939
! Node: Getting Internal Debugging Information533414
! Ref: gnat_ugn/gnat_and_program_execution getting-internal-debugging-information533598
! Ref: 166533598
! Ref: gnat_ugn/gnat_and_program_execution id15533598
! Ref: 167533598
! Node: Stack Traceback534632
! Ref: gnat_ugn/gnat_and_program_execution id16534812
! Ref: 168534812
! Ref: gnat_ugn/gnat_and_program_execution stack-traceback534812
! Ref: 169534812
! Node: Non-Symbolic Traceback535733
! Ref: gnat_ugn/gnat_and_program_execution id17535836
! Ref: 16a535836
! Ref: gnat_ugn/gnat_and_program_execution non-symbolic-traceback535836
! Ref: 16b535836
! Node: Symbolic Traceback545043
! Ref: gnat_ugn/gnat_and_program_execution id18545146
! Ref: 16c545146
! Ref: gnat_ugn/gnat_and_program_execution symbolic-traceback545146
! Ref: 16d545146
! Node: Pretty-Printers for the GNAT runtime548220
! Ref: gnat_ugn/gnat_and_program_execution id19548353
! Ref: 16e548353
! Ref: gnat_ugn/gnat_and_program_execution pretty-printers-for-the-gnat-runtime548353
! Ref: 16f548353
! Ref: Pretty-Printers for the GNAT runtime-Footnote-1550994
! Ref: Pretty-Printers for the GNAT runtime-Footnote-2551082
! Node: Profiling551166
! Ref: gnat_ugn/gnat_and_program_execution id20551313
! Ref: 170551313
! Ref: gnat_ugn/gnat_and_program_execution profiling551313
! Ref: 147551313
! Node: Profiling an Ada Program with gprof551474
! Ref: gnat_ugn/gnat_and_program_execution id21551557
! Ref: 171551557
! Ref: gnat_ugn/gnat_and_program_execution profiling-an-ada-program-with-gprof551557
! Ref: 172551557
! Node: Compilation for profiling552774
! Ref: gnat_ugn/gnat_and_program_execution compilation-for-profiling552899
! Ref: 173552899
! Ref: gnat_ugn/gnat_and_program_execution id22552899
! Ref: 174552899
! Node: Program execution553683
! Ref: gnat_ugn/gnat_and_program_execution id23553830
! Ref: 175553830
! Ref: gnat_ugn/gnat_and_program_execution program-execution553830
! Ref: 176553830
! Node: Running gprof554322
! Ref: gnat_ugn/gnat_and_program_execution id24554479
! Ref: 177554479
! Ref: gnat_ugn/gnat_and_program_execution running-gprof554479
! Ref: 178554479
! Node: Interpretation of profiling results557187
! Ref: gnat_ugn/gnat_and_program_execution id25557318
! Ref: 179557318
! Ref: gnat_ugn/gnat_and_program_execution interpretation-of-profiling-results557318
! Ref: 17a557318
! Node: Improving Performance557993
! Ref: gnat_ugn/gnat_and_program_execution id26558137
! Ref: 148558137
! Ref: gnat_ugn/gnat_and_program_execution improving-performance558137
! Ref: 17b558137
! Node: Performance Considerations558647
! Ref: gnat_ugn/gnat_and_program_execution id27558761
! Ref: 17c558761
! Ref: gnat_ugn/gnat_and_program_execution performance-considerations558761
! Ref: 17d558761
! Node: Controlling Run-Time Checks559930
! Ref: gnat_ugn/gnat_and_program_execution controlling-run-time-checks560050
! Ref: 17e560050
! Ref: gnat_ugn/gnat_and_program_execution id28560050
! Ref: 17f560050
! Node: Use of Restrictions561608
! Ref: gnat_ugn/gnat_and_program_execution id29561756
! Ref: 180561756
! Ref: gnat_ugn/gnat_and_program_execution use-of-restrictions561756
! Ref: 181561756
! Node: Optimization Levels563114
! Ref: gnat_ugn/gnat_and_program_execution id30563259
! Ref: 182563259
! Ref: gnat_ugn/gnat_and_program_execution optimization-levels563259
! Ref: ed563259
! Node: Debugging Optimized Code567126
! Ref: gnat_ugn/gnat_and_program_execution debugging-optimized-code567275
! Ref: 183567275
! Ref: gnat_ugn/gnat_and_program_execution id31567275
! Ref: 184567275
! Node: Inlining of Subprograms572227
! Ref: gnat_ugn/gnat_and_program_execution id32572382
! Ref: 185572382
! Ref: gnat_ugn/gnat_and_program_execution inlining-of-subprograms572382
! Ref: 100572382
! Node: Floating Point Operations577066
! Ref: gnat_ugn/gnat_and_program_execution floating-point-operations577219
! Ref: 186577219
! Ref: gnat_ugn/gnat_and_program_execution id33577219
! Ref: 187577219
! Node: Vectorization of loops579402
! Ref: gnat_ugn/gnat_and_program_execution id34579559
! Ref: 188579559
! Ref: gnat_ugn/gnat_and_program_execution vectorization-of-loops579559
! Ref: 189579559
! Node: Other Optimization Switches584187
! Ref: gnat_ugn/gnat_and_program_execution id35584351
! Ref: 18a584351
! Ref: gnat_ugn/gnat_and_program_execution other-optimization-switches584351
! Ref: 18b584351
! Node: Optimization and Strict Aliasing585056
! Ref: gnat_ugn/gnat_and_program_execution id36585232
! Ref: 18c585232
! Ref: gnat_ugn/gnat_and_program_execution optimization-and-strict-aliasing585232
! Ref: e4585232
! Node: Aliased Variables and Optimization594263
! Ref: gnat_ugn/gnat_and_program_execution aliased-variables-and-optimization594445
! Ref: 18d594445
! Ref: gnat_ugn/gnat_and_program_execution id37594445
! Ref: 18e594445
! Node: Atomic Variables and Optimization596437
! Ref: gnat_ugn/gnat_and_program_execution atomic-variables-and-optimization596612
! Ref: 18f596612
! Ref: gnat_ugn/gnat_and_program_execution id38596612
! Ref: 190596612
! Node: Passive Task Optimization599212
! Ref: gnat_ugn/gnat_and_program_execution id39599344
! Ref: 191599344
! Ref: gnat_ugn/gnat_and_program_execution passive-task-optimization599344
! Ref: 192599344
! Node: Text_IO Suggestions601319
! Ref: gnat_ugn/gnat_and_program_execution id40601510
! Ref: 193601510
! Ref: gnat_ugn/gnat_and_program_execution text-io-suggestions601510
! Ref: 194601510
! Node: Reducing Size of Executables with Unused Subprogram/Data Elimination602450
! Ref: gnat_ugn/gnat_and_program_execution id41602606
! Ref: 195602606
! Ref: gnat_ugn/gnat_and_program_execution reducing-size-of-executables-with-unused-subprogram-data-elimination602606
! Ref: 196602606
! Node: About unused subprogram/data elimination603026
! Ref: gnat_ugn/gnat_and_program_execution about-unused-subprogram-data-elimination603201
! Ref: 197603201
! Ref: gnat_ugn/gnat_and_program_execution id42603201
! Ref: 198603201
! Node: Compilation options603842
! Ref: gnat_ugn/gnat_and_program_execution compilation-options604071
! Ref: 199604071
! Ref: gnat_ugn/gnat_and_program_execution id43604071
! Ref: 19a604071
! Node: Example of unused subprogram/data elimination605460
! Ref: gnat_ugn/gnat_and_program_execution example-of-unused-subprogram-data-elimination605640
! Ref: 19b605640
! Ref: gnat_ugn/gnat_and_program_execution id44605640
! Ref: 19c605640
! Node: Overflow Check Handling in GNAT607112
! Ref: gnat_ugn/gnat_and_program_execution id45607289
! Ref: 149607289
! Ref: gnat_ugn/gnat_and_program_execution overflow-check-handling-in-gnat607289
! Ref: 19d607289
! Node: Background607572
! Ref: gnat_ugn/gnat_and_program_execution background607692
! Ref: 19e607692
! Ref: gnat_ugn/gnat_and_program_execution id46607692
! Ref: 19f607692
! Node: Management of Overflows in GNAT611365
! Ref: gnat_ugn/gnat_and_program_execution id47611521
! Ref: 1a0611521
! Ref: gnat_ugn/gnat_and_program_execution management-of-overflows-in-gnat611521
! Ref: 1a1611521
! Node: Specifying the Desired Mode616537
! Ref: gnat_ugn/gnat_and_program_execution id48616699
! Ref: 1a2616699
! Ref: gnat_ugn/gnat_and_program_execution specifying-the-desired-mode616699
! Ref: e9616699
! Node: Default Settings619813
! Ref: gnat_ugn/gnat_and_program_execution default-settings619964
! Ref: 1a3619964
! Ref: gnat_ugn/gnat_and_program_execution id49619964
! Ref: 1a4619964
! Node: Implementation Notes620858
! Ref: gnat_ugn/gnat_and_program_execution id50620973
! Ref: 1a5620973
! Ref: gnat_ugn/gnat_and_program_execution implementation-notes620973
! Ref: 1a6620973
! Node: Performing Dimensionality Analysis in GNAT623115
! Ref: gnat_ugn/gnat_and_program_execution id51623295
! Ref: 14a623295
! Ref: gnat_ugn/gnat_and_program_execution performing-dimensionality-analysis-in-gnat623295
! Ref: 1a7623295
! Node: Stack Related Facilities634400
! Ref: gnat_ugn/gnat_and_program_execution id52634573
! Ref: 14b634573
! Ref: gnat_ugn/gnat_and_program_execution stack-related-facilities634573
! Ref: 1a8634573
! Node: Stack Overflow Checking634897
! Ref: gnat_ugn/gnat_and_program_execution id53635019
! Ref: 1a9635019
! Ref: gnat_ugn/gnat_and_program_execution stack-overflow-checking635019
! Ref: e5635019
! Node: Static Stack Usage Analysis636659
! Ref: gnat_ugn/gnat_and_program_execution id54636818
! Ref: 1aa636818
! Ref: gnat_ugn/gnat_and_program_execution static-stack-usage-analysis636818
! Ref: e6636818
! Node: Dynamic Stack Usage Analysis638217
! Ref: gnat_ugn/gnat_and_program_execution dynamic-stack-usage-analysis638344
! Ref: 113638344
! Ref: gnat_ugn/gnat_and_program_execution id55638344
! Ref: 1ab638344
! Node: Memory Management Issues640289
! Ref: gnat_ugn/gnat_and_program_execution id56640411
! Ref: 14c640411
! Ref: gnat_ugn/gnat_and_program_execution memory-management-issues640411
! Ref: 1ac640411
! Node: Some Useful Memory Pools640767
! Ref: gnat_ugn/gnat_and_program_execution id57640891
! Ref: 1ad640891
! Ref: gnat_ugn/gnat_and_program_execution some-useful-memory-pools640891
! Ref: 1ae640891
! Node: The GNAT Debug Pool Facility643548
! Ref: gnat_ugn/gnat_and_program_execution id58643672
! Ref: 1af643672
! Ref: gnat_ugn/gnat_and_program_execution the-gnat-debug-pool-facility643672
! Ref: 1b0643672
! Node: Platform-Specific Information648689
! Ref: gnat_ugn/platform_specific_information doc648833
! Ref: 1b1648833
! Ref: gnat_ugn/platform_specific_information id1648833
! Ref: 1b2648833
! Ref: gnat_ugn/platform_specific_information platform-specific-information648833
! Ref: d648833
! Node: Run-Time Libraries649232
! Ref: gnat_ugn/platform_specific_information id2649356
! Ref: 1b3649356
! Ref: gnat_ugn/platform_specific_information run-time-libraries649356
! Ref: 1b4649356
! Node: Summary of Run-Time Configurations650648
! Ref: gnat_ugn/platform_specific_information id3650739
! Ref: 1b5650739
! Ref: gnat_ugn/platform_specific_information summary-of-run-time-configurations650739
! Ref: 1b6650739
! Node: Specifying a Run-Time Library652052
! Ref: gnat_ugn/platform_specific_information id4652201
! Ref: 1b7652201
! Ref: gnat_ugn/platform_specific_information specifying-a-run-time-library652201
! Ref: 1b8652201
! Ref: gnat_ugn/platform_specific_information choosing-the-scheduling-policy654505
! Ref: 1b9654505
! Node: Choosing the Scheduling Policy654552
! Ref: gnat_ugn/platform_specific_information id5654650
! Ref: 1ba654650
! Node: GNU/Linux Topics656134
! Ref: gnat_ugn/platform_specific_information gnu-linux-topics656289
! Ref: 1bb656289
! Ref: gnat_ugn/platform_specific_information id6656289
! Ref: 1bc656289
! Node: Required Packages on GNU/Linux656478
! Ref: gnat_ugn/platform_specific_information id7656595
! Ref: 1bd656595
! Ref: gnat_ugn/platform_specific_information required-packages-on-gnu-linux656595
! Ref: 1be656595
! Node: A GNU/Linux Debug Quirk657345
! Ref: gnat_ugn/platform_specific_information a-gnu-linux-debug-quirk657462
! Ref: 1bf657462
! Ref: gnat_ugn/platform_specific_information id8657462
! Ref: 1c0657462
! Node: Microsoft Windows Topics658213
! Ref: gnat_ugn/platform_specific_information id9658352
! Ref: 1c1658352
! Ref: gnat_ugn/platform_specific_information microsoft-windows-topics658352
! Ref: 1c2658352
! Node: Using GNAT on Windows658773
! Ref: gnat_ugn/platform_specific_information id10658902
! Ref: 1c3658902
! Ref: gnat_ugn/platform_specific_information using-gnat-on-windows658902
! Ref: 1c4658902
! Node: Using a network installation of GNAT661721
! Ref: gnat_ugn/platform_specific_information id11661889
! Ref: 1c5661889
! Ref: gnat_ugn/platform_specific_information using-a-network-installation-of-gnat661889
! Ref: 1c6661889
! Node: CONSOLE and WINDOWS subsystems662790
! Ref: gnat_ugn/platform_specific_information console-and-windows-subsystems662952
! Ref: 1c7662952
! Ref: gnat_ugn/platform_specific_information id12662952
! Ref: 1c8662952
! Node: Temporary Files663465
! Ref: gnat_ugn/platform_specific_information id13663632
! Ref: 1c9663632
! Ref: gnat_ugn/platform_specific_information temporary-files663632
! Ref: 1ca663632
! Node: Disabling Command Line Argument Expansion664308
! Ref: gnat_ugn/platform_specific_information disabling-command-line-argument-expansion664468
! Ref: 1cb664468
! Node: Windows Socket Timeouts666090
! Ref: gnat_ugn/platform_specific_information windows-socket-timeouts666272
! Ref: 1cc666272
! Node: Mixed-Language Programming on Windows668498
! Ref: gnat_ugn/platform_specific_information id14668663
! Ref: 1cd668663
! Ref: gnat_ugn/platform_specific_information mixed-language-programming-on-windows668663
! Ref: 1ce668663
! Node: Windows Calling Conventions671210
! Ref: gnat_ugn/platform_specific_information id15671365
! Ref: 1d1671365
! Ref: gnat_ugn/platform_specific_information windows-calling-conventions671365
! Ref: 1d2671365
! Node: C Calling Convention672295
! Ref: gnat_ugn/platform_specific_information c-calling-convention672416
! Ref: 1d3672416
! Ref: gnat_ugn/platform_specific_information id16672416
! Ref: 1d4672416
! Node: Stdcall Calling Convention673896
! Ref: gnat_ugn/platform_specific_information id17674050
! Ref: 1d6674050
! Ref: gnat_ugn/platform_specific_information stdcall-calling-convention674050
! Ref: 1d5674050
! Node: Win32 Calling Convention676839
! Ref: gnat_ugn/platform_specific_information id18676995
! Ref: 1d7676995
! Ref: gnat_ugn/platform_specific_information win32-calling-convention676995
! Ref: 1d8676995
! Node: DLL Calling Convention677188
! Ref: gnat_ugn/platform_specific_information dll-calling-convention677309
! Ref: 1d9677309
! Ref: gnat_ugn/platform_specific_information id19677309
! Ref: 1da677309
! Node: Introduction to Dynamic Link Libraries DLLs677498
! Ref: gnat_ugn/platform_specific_information id20677682
! Ref: 1db677682
! Ref: gnat_ugn/platform_specific_information introduction-to-dynamic-link-libraries-dlls677682
! Ref: 1dc677682
! Node: Using DLLs with GNAT681079
! Ref: gnat_ugn/platform_specific_information id21681273
! Ref: 1de681273
! Ref: gnat_ugn/platform_specific_information using-dlls-with-gnat681273
! Ref: 1cf681273
! Node: Creating an Ada Spec for the DLL Services683263
! Ref: gnat_ugn/platform_specific_information creating-an-ada-spec-for-the-dll-services683398
! Ref: 1df683398
! Ref: gnat_ugn/platform_specific_information id22683398
! Ref: 1e0683398
! Node: Creating an Import Library684362
! Ref: gnat_ugn/platform_specific_information creating-an-import-library684497
! Ref: 1e1684497
! Ref: gnat_ugn/platform_specific_information id23684497
! Ref: 1e2684497
! Ref: gnat_ugn/platform_specific_information the-definition-file684923
! Ref: 1dd684923
! Ref: gnat_ugn/platform_specific_information create-def-file-automatically686232
! Ref: 1e3686232
! Ref: gnat_ugn/platform_specific_information gnat-style-import-library687386
! Ref: 1e4687386
! Ref: gnat_ugn/platform_specific_information msvs-style-import-library688316
! Ref: 1e6688316
! Node: Building DLLs with GNAT Project files689037
! Ref: gnat_ugn/platform_specific_information building-dlls-with-gnat-project-files689211
! Ref: 1d0689211
! Ref: gnat_ugn/platform_specific_information id24689211
! Ref: 1e7689211
! Node: Building DLLs with GNAT689722
! Ref: gnat_ugn/platform_specific_information building-dlls-with-gnat689902
! Ref: 1e8689902
! Ref: gnat_ugn/platform_specific_information id25689902
! Ref: 1e9689902
! Node: Building DLLs with gnatdll691810
! Ref: gnat_ugn/platform_specific_information building-dlls-with-gnatdll691978
! Ref: 1ea691978
! Ref: gnat_ugn/platform_specific_information id26691978
! Ref: 1eb691978
! Node: Limitations When Using Ada DLLs from Ada694475
! Ref: gnat_ugn/platform_specific_information limitations-when-using-ada-dlls-from-ada694611
! Ref: 1ef694611
! Node: Exporting Ada Entities695522
! Ref: gnat_ugn/platform_specific_information exporting-ada-entities695691
! Ref: 1ec695691
! Ref: gnat_ugn/platform_specific_information id27695691
! Ref: 1f0695691
! Node: Ada DLLs and Elaboration698580
! Ref: gnat_ugn/platform_specific_information ada-dlls-and-elaboration698700
! Ref: 1ed698700
! Ref: gnat_ugn/platform_specific_information id28698700
! Ref: 1f2698700
! Node: Ada DLLs and Finalization700138
! Ref: gnat_ugn/platform_specific_information ada-dlls-and-finalization700311
! Ref: 1ee700311
! Ref: gnat_ugn/platform_specific_information id29700311
! Ref: 1f3700311
! Node: Creating a Spec for Ada DLLs700982
! Ref: gnat_ugn/platform_specific_information creating-a-spec-for-ada-dlls701155
! Ref: 1f4701155
! Ref: gnat_ugn/platform_specific_information id30701155
! Ref: 1f5701155
! Node: Creating the Definition File702564
! Ref: gnat_ugn/platform_specific_information creating-the-definition-file702681
! Ref: 1f1702681
! Ref: gnat_ugn/platform_specific_information id31702681
! Ref: 1f6702681
! Node: Using gnatdll703439
! Ref: gnat_ugn/platform_specific_information id32703556
! Ref: 1f7703556
! Ref: gnat_ugn/platform_specific_information using-gnatdll703556
! Ref: 1e5703556
! Ref: gnat_ugn/platform_specific_information using-dlltool710092
! Ref: 1f8710092
! Node: GNAT and Windows Resources711459
! Ref: gnat_ugn/platform_specific_information gnat-and-windows-resources711664
! Ref: 1f9711664
! Ref: gnat_ugn/platform_specific_information id33711664
! Ref: 1fa711664
! Node: Building Resources713560
! Ref: gnat_ugn/platform_specific_information building-resources713671
! Ref: 1fb713671
! Ref: gnat_ugn/platform_specific_information id34713671
! Ref: 1fc713671
! Node: Compiling Resources714249
! Ref: gnat_ugn/platform_specific_information compiling-resources714384
! Ref: 1fd714384
! Ref: gnat_ugn/platform_specific_information id35714384
! Ref: 1fe714384
! Node: Using Resources715324
! Ref: gnat_ugn/platform_specific_information id36715432
! Ref: 1ff715432
! Ref: gnat_ugn/platform_specific_information using-resources715432
! Ref: 200715432
! Node: Using GNAT DLLs from Microsoft Visual Studio Applications715726
! Ref: gnat_ugn/platform_specific_information using-gnat-dll-from-msvs715918
! Ref: 201715918
! Ref: gnat_ugn/platform_specific_information using-gnat-dlls-from-microsoft-visual-studio-applications715918
! Ref: 202715918
! Node: Debugging a DLL717480
! Ref: gnat_ugn/platform_specific_information debugging-a-dll717678
! Ref: 203717678
! Ref: gnat_ugn/platform_specific_information id37717678
! Ref: 204717678
! Node: Program and DLL Both Built with GCC/GNAT718542
! Ref: gnat_ugn/platform_specific_information id38718705
! Ref: 205718705
! Ref: gnat_ugn/platform_specific_information program-and-dll-both-built-with-gcc-gnat718705
! Ref: 206718705
! Node: Program Built with Foreign Tools and DLL Built with GCC/GNAT720033
! Ref: gnat_ugn/platform_specific_information id39720196
! Ref: 207720196
! Ref: gnat_ugn/platform_specific_information program-built-with-foreign-tools-and-dll-built-with-gcc-gnat720196
! Ref: 208720196
! Node: Setting Stack Size from gnatlink723602
! Ref: gnat_ugn/platform_specific_information id40723774
! Ref: 209723774
! Ref: gnat_ugn/platform_specific_information setting-stack-size-from-gnatlink723774
! Ref: 127723774
! Node: Setting Heap Size from gnatlink724991
! Ref: gnat_ugn/platform_specific_information id41725139
! Ref: 20a725139
! Ref: gnat_ugn/platform_specific_information setting-heap-size-from-gnatlink725139
! Ref: 128725139
! Node: Windows Specific Add-Ons725826
! Ref: gnat_ugn/platform_specific_information win32-specific-addons725959
! Ref: 20b725959
! Ref: gnat_ugn/platform_specific_information windows-specific-add-ons725959
! Ref: 20c725959
! Node: Win32Ada726110
! Ref: gnat_ugn/platform_specific_information id42726196
! Ref: 20d726196
! Ref: gnat_ugn/platform_specific_information win32ada726196
! Ref: 20e726196
! Node: wPOSIX726793
! Ref: gnat_ugn/platform_specific_information id43726879
! Ref: 20f726879
! Ref: gnat_ugn/platform_specific_information wposix726879
! Ref: 210726879
! Node: Mac OS Topics727563
! Ref: gnat_ugn/platform_specific_information id44727677
! Ref: 211727677
! Ref: gnat_ugn/platform_specific_information mac-os-topics727677
! Ref: 212727677
! Node: Codesigning the Debugger727830
! Ref: gnat_ugn/platform_specific_information codesigning-the-debugger727906
! Ref: 213727906
! Node: Example of Binder Output File729889
! Ref: gnat_ugn/example_of_binder_output doc730041
! Ref: 214730041
! Ref: gnat_ugn/example_of_binder_output example-of-binder-output-file730041
! Ref: e730041
! Ref: gnat_ugn/example_of_binder_output id1730041
! Ref: 215730041
! Node: Elaboration Order Handling in GNAT761128
! Ref: gnat_ugn/elaboration_order_handling_in_gnat doc761267
! Ref: 216761267
! Ref: gnat_ugn/elaboration_order_handling_in_gnat elaboration-order-handling-in-gnat761267
! Ref: f761267
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id1761267
! Ref: 217761267
! Node: Elaboration Code762021
! Ref: gnat_ugn/elaboration_order_handling_in_gnat elaboration-code762136
! Ref: 218762136
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id2762136
! Ref: 219762136
! Node: Elaboration Order766025
! Ref: gnat_ugn/elaboration_order_handling_in_gnat elaboration-order766179
! Ref: 21a766179
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id3766179
! Ref: 21b766179
! Node: Checking the Elaboration Order769841
! Ref: gnat_ugn/elaboration_order_handling_in_gnat checking-the-elaboration-order770019
! Ref: 21c770019
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id4770019
! Ref: 21d770019
! Node: Controlling the Elaboration Order in Ada771727
! Ref: gnat_ugn/elaboration_order_handling_in_gnat controlling-the-elaboration-order-in-ada771929
! Ref: 21e771929
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id5771929
! Ref: 21f771929
! Node: Controlling the Elaboration Order in GNAT780551
! Ref: gnat_ugn/elaboration_order_handling_in_gnat controlling-the-elaboration-order-in-gnat780748
! Ref: 220780748
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id6780748
! Ref: 221780748
! Node: Mixing Elaboration Models784603
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id7784775
! Ref: 222784775
! Ref: gnat_ugn/elaboration_order_handling_in_gnat mixing-elaboration-models784775
! Ref: 223784775
! Node: ABE Diagnostics785792
! Ref: gnat_ugn/elaboration_order_handling_in_gnat abe-diagnostics785940
! Ref: 224785940
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id8785940
! Ref: 225785940
! Node: SPARK Diagnostics789474
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id9789622
! Ref: 226789622
! Ref: gnat_ugn/elaboration_order_handling_in_gnat spark-diagnostics789622
! Ref: 227789622
! Node: Elaboration Circularities790393
! Ref: gnat_ugn/elaboration_order_handling_in_gnat elaboration-circularities790561
! Ref: 228790561
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id10790561
! Ref: 229790561
! Node: Resolving Elaboration Circularities792816
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id11793004
! Ref: 22a793004
! Ref: gnat_ugn/elaboration_order_handling_in_gnat resolving-elaboration-circularities793004
! Ref: 22b793004
! Node: Elaboration-related Compiler Switches800537
! Ref: gnat_ugn/elaboration_order_handling_in_gnat elaboration-related-compiler-switches800745
! Ref: 22c800745
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id12800745
! Ref: 22d800745
! Node: Summary of Procedures for Elaboration Control805586
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id13805798
! Ref: 22e805798
! Ref: gnat_ugn/elaboration_order_handling_in_gnat summary-of-procedures-for-elaboration-control805798
! Ref: 22f805798
! Node: Inspecting the Chosen Elaboration Order807649
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id14807815
! Ref: 230807815
! Ref: gnat_ugn/elaboration_order_handling_in_gnat inspecting-the-chosen-elaboration-order807815
! Ref: 231807815
! Node: Inline Assembler812430
! Ref: gnat_ugn/inline_assembler doc812570
! Ref: 232812570
! Ref: gnat_ugn/inline_assembler id1812570
! Ref: 233812570
! Ref: gnat_ugn/inline_assembler inline-assembler812570
! Ref: 10812570
! Node: Basic Assembler Syntax814113
! Ref: gnat_ugn/inline_assembler basic-assembler-syntax814235
! Ref: 234814235
! Ref: gnat_ugn/inline_assembler id2814235
! Ref: 235814235
! Node: A Simple Example of Inline Assembler816286
! Ref: gnat_ugn/inline_assembler a-simple-example-of-inline-assembler816453
! Ref: 236816453
! Ref: gnat_ugn/inline_assembler id3816453
! Ref: 237816453
! Node: Output Variables in Inline Assembler819762
! Ref: gnat_ugn/inline_assembler id4819942
! Ref: 238819942
! Ref: gnat_ugn/inline_assembler output-variables-in-inline-assembler819942
! Ref: 239819942
! Node: Input Variables in Inline Assembler828078
! Ref: gnat_ugn/inline_assembler id5828252
! Ref: 23a828252
! Ref: gnat_ugn/inline_assembler input-variables-in-inline-assembler828252
! Ref: 23b828252
! Node: Inlining Inline Assembler Code830640
! Ref: gnat_ugn/inline_assembler id6830801
! Ref: 23c830801
! Ref: gnat_ugn/inline_assembler inlining-inline-assembler-code830801
! Ref: 23d830801
! Node: Other Asm Functionality832700
! Ref: gnat_ugn/inline_assembler id7832817
! Ref: 23e832817
! Ref: gnat_ugn/inline_assembler other-asm-functionality832817
! Ref: 23f832817
! Node: The Clobber Parameter833131
! Ref: gnat_ugn/inline_assembler id8833245
! Ref: 240833245
! Ref: gnat_ugn/inline_assembler the-clobber-parameter833245
! Ref: 241833245
! Node: The Volatile Parameter835220
! Ref: gnat_ugn/inline_assembler id9835334
! Ref: 242835334
! Ref: gnat_ugn/inline_assembler the-volatile-parameter835334
! Ref: 243835334
! Node: GNU Free Documentation License836490
! Ref: share/gnu_free_documentation_license doc836601
! Ref: 244836601
! Ref: share/gnu_free_documentation_license gnu-fdl836601
! Ref: 1836601
! Ref: share/gnu_free_documentation_license gnu-free-documentation-license836601
! Ref: 245836601
! Node: Index860059
! Ref: gnat_ugn/gnat_utility_programs switches-related-to-project-files999731
! Ref: cf999761
  
  End Tag Table
  
--- 23607,25071 ----
                                                               (line   40)
  * Zero-Cost Exceptions:                  Run-Time Libraries. (line   13)
  
!    
  
  
  
  Tag Table:
! Node: Top348
! Ref: gnat_ugn doc628
! Ref: 0628
! Node: About This Guide12132
! Ref: gnat_ugn/about_this_guide doc12236
! Ref: 212236
! Ref: gnat_ugn/about_this_guide about-this-guide12236
! Ref: 312236
! Ref: gnat_ugn/about_this_guide gnat-user-s-guide-for-native-platforms12236
! Ref: 412236
! Ref: gnat_ugn/about_this_guide id112236
! Ref: 512236
! Node: What This Guide Contains13061
! Ref: gnat_ugn/about_this_guide what-this-guide-contains13195
! Ref: 713195
! Node: What You Should Know before Reading This Guide14631
! Ref: gnat_ugn/about_this_guide what-you-should-know-before-reading-this-guide14793
! Ref: 1114793
! Node: Related Information15145
! Ref: gnat_ugn/about_this_guide related-information15294
! Ref: 1215294
! Node: Conventions16180
! Ref: gnat_ugn/about_this_guide conventions16274
! Ref: 1316274
! Node: Getting Started with GNAT17094
! Ref: gnat_ugn/getting_started_with_gnat doc17221
! Ref: 1417221
! Ref: gnat_ugn/getting_started_with_gnat getting-started-with-gnat17221
! Ref: 817221
! Ref: gnat_ugn/getting_started_with_gnat id117221
! Ref: 1517221
! Node: System Requirements17867
! Ref: gnat_ugn/getting_started_with_gnat id217971
! Ref: 1617971
! Ref: gnat_ugn/getting_started_with_gnat system-requirements17971
! Ref: 1717971
! Node: Running GNAT19418
! Ref: gnat_ugn/getting_started_with_gnat id319559
! Ref: 1819559
! Ref: gnat_ugn/getting_started_with_gnat running-gnat19559
! Ref: 1919559
! Node: Running a Simple Ada Program20057
! Ref: gnat_ugn/getting_started_with_gnat id420216
! Ref: 1a20216
! Ref: gnat_ugn/getting_started_with_gnat running-a-simple-ada-program20216
! Ref: 1b20216
! Node: Running a Program with Multiple Units23193
! Ref: gnat_ugn/getting_started_with_gnat id523331
! Ref: 1e23331
! Ref: gnat_ugn/getting_started_with_gnat running-a-program-with-multiple-units23331
! Ref: 1f23331
! Node: The GNAT Compilation Model24928
! Ref: gnat_ugn/the_gnat_compilation_model doc25077
! Ref: 2025077
! Ref: gnat_ugn/the_gnat_compilation_model id125077
! Ref: 2125077
! Ref: gnat_ugn/the_gnat_compilation_model the-gnat-compilation-model25077
! Ref: 925077
! Node: Source Representation26495
! Ref: gnat_ugn/the_gnat_compilation_model id226621
! Ref: 2f26621
! Ref: gnat_ugn/the_gnat_compilation_model source-representation26621
! Ref: 2226621
! Node: Foreign Language Representation29077
! Ref: gnat_ugn/the_gnat_compilation_model foreign-language-representation29244
! Ref: 2329244
! Ref: gnat_ugn/the_gnat_compilation_model id329244
! Ref: 3029244
! Node: Latin-129617
! Ref: gnat_ugn/the_gnat_compilation_model id429720
! Ref: 3229720
! Ref: gnat_ugn/the_gnat_compilation_model latin-129720
! Ref: 3329720
! Node: Other 8-Bit Codes30508
! Ref: gnat_ugn/the_gnat_compilation_model id530644
! Ref: 3430644
! Ref: gnat_ugn/the_gnat_compilation_model other-8-bit-codes30644
! Ref: 3530644
! Node: Wide_Character Encodings32831
! Ref: gnat_ugn/the_gnat_compilation_model id632989
! Ref: 3632989
! Ref: gnat_ugn/the_gnat_compilation_model wide-character-encodings32989
! Ref: 3732989
! Node: Wide_Wide_Character Encodings36805
! Ref: gnat_ugn/the_gnat_compilation_model id736937
! Ref: 3836937
! Ref: gnat_ugn/the_gnat_compilation_model wide-wide-character-encodings36937
! Ref: 3936937
! Node: File Naming Topics and Utilities38657
! Ref: gnat_ugn/the_gnat_compilation_model file-naming-topics-and-utilities38824
! Ref: 2438824
! Ref: gnat_ugn/the_gnat_compilation_model id838824
! Ref: 3a38824
! Node: File Naming Rules39333
! Ref: gnat_ugn/the_gnat_compilation_model file-naming-rules39452
! Ref: 3b39452
! Ref: gnat_ugn/the_gnat_compilation_model id939452
! Ref: 3c39452
! Node: Using Other File Names42983
! Ref: gnat_ugn/the_gnat_compilation_model id1043142
! Ref: 3e43142
! Ref: gnat_ugn/the_gnat_compilation_model using-other-file-names43142
! Ref: 1c43142
! Node: Alternative File Naming Schemes45390
! Ref: gnat_ugn/the_gnat_compilation_model alternative-file-naming-schemes45588
! Ref: 4045588
! Ref: gnat_ugn/the_gnat_compilation_model id1145588
! Ref: 4145588
! Node: Handling Arbitrary File Naming Conventions with gnatname50730
! Ref: gnat_ugn/the_gnat_compilation_model handling-arbitrary-file-naming-conventions-with-gnatname50937
! Ref: 4250937
! Ref: gnat_ugn/the_gnat_compilation_model id1250937
! Ref: 4350937
! Node: Arbitrary File Naming Conventions51198
! Ref: gnat_ugn/the_gnat_compilation_model arbitrary-file-naming-conventions51351
! Ref: 4451351
! Ref: gnat_ugn/the_gnat_compilation_model id1351351
! Ref: 4551351
! Node: Running gnatname52491
! Ref: gnat_ugn/the_gnat_compilation_model id1452674
! Ref: 4652674
! Ref: gnat_ugn/the_gnat_compilation_model running-gnatname52674
! Ref: 4752674
! Node: Switches for gnatname54540
! Ref: gnat_ugn/the_gnat_compilation_model id1554716
! Ref: 4854716
! Ref: gnat_ugn/the_gnat_compilation_model switches-for-gnatname54716
! Ref: 4954716
! Node: Examples of gnatname Usage59514
! Ref: gnat_ugn/the_gnat_compilation_model examples-of-gnatname-usage59665
! Ref: 4a59665
! Ref: gnat_ugn/the_gnat_compilation_model id1659665
! Ref: 4b59665
! Node: File Name Krunching with gnatkr60360
! Ref: gnat_ugn/the_gnat_compilation_model file-name-krunching-with-gnatkr60564
! Ref: 4c60564
! Ref: gnat_ugn/the_gnat_compilation_model id1760564
! Ref: 4d60564
! Node: About gnatkr61025
! Ref: gnat_ugn/the_gnat_compilation_model about-gnatkr61128
! Ref: 4e61128
! Ref: gnat_ugn/the_gnat_compilation_model id1861128
! Ref: 4f61128
! Node: Using gnatkr62109
! Ref: gnat_ugn/the_gnat_compilation_model id1962237
! Ref: 5062237
! Ref: gnat_ugn/the_gnat_compilation_model using-gnatkr62237
! Ref: 3d62237
! Node: Krunching Method63761
! Ref: gnat_ugn/the_gnat_compilation_model id2063901
! Ref: 5163901
! Ref: gnat_ugn/the_gnat_compilation_model krunching-method63901
! Ref: 5263901
! Node: Examples of gnatkr Usage67389
! Ref: gnat_ugn/the_gnat_compilation_model examples-of-gnatkr-usage67508
! Ref: 5367508
! Ref: gnat_ugn/the_gnat_compilation_model id2167508
! Ref: 5467508
! Node: Renaming Files with gnatchop67955
! Ref: gnat_ugn/the_gnat_compilation_model id2268094
! Ref: 5568094
! Ref: gnat_ugn/the_gnat_compilation_model renaming-files-with-gnatchop68094
! Ref: 1d68094
! Node: Handling Files with Multiple Units68559
! Ref: gnat_ugn/the_gnat_compilation_model handling-files-with-multiple-units68707
! Ref: 5668707
! Ref: gnat_ugn/the_gnat_compilation_model id2368707
! Ref: 5768707
! Node: Operating gnatchop in Compilation Mode69943
! Ref: gnat_ugn/the_gnat_compilation_model id2470125
! Ref: 5870125
! Ref: gnat_ugn/the_gnat_compilation_model operating-gnatchop-in-compilation-mode70125
! Ref: 5970125
! Node: Command Line for gnatchop73273
! Ref: gnat_ugn/the_gnat_compilation_model command-line-for-gnatchop73442
! Ref: 5a73442
! Ref: gnat_ugn/the_gnat_compilation_model id2573442
! Ref: 5b73442
! Node: Switches for gnatchop75263
! Ref: gnat_ugn/the_gnat_compilation_model id2675420
! Ref: 5c75420
! Ref: gnat_ugn/the_gnat_compilation_model switches-for-gnatchop75420
! Ref: 5d75420
! Node: Examples of gnatchop Usage79439
! Ref: gnat_ugn/the_gnat_compilation_model examples-of-gnatchop-usage79562
! Ref: 5e79562
! Ref: gnat_ugn/the_gnat_compilation_model id2779562
! Ref: 5f79562
! Node: Configuration Pragmas80802
! Ref: gnat_ugn/the_gnat_compilation_model configuration-pragmas80961
! Ref: 2580961
! Ref: gnat_ugn/the_gnat_compilation_model id2880961
! Ref: 6080961
! Node: Handling of Configuration Pragmas83206
! Ref: gnat_ugn/the_gnat_compilation_model handling-of-configuration-pragmas83339
! Ref: 3f83339
! Ref: gnat_ugn/the_gnat_compilation_model id2983339
! Ref: 6183339
! Node: The Configuration Pragmas Files85304
! Ref: gnat_ugn/the_gnat_compilation_model id3085437
! Ref: 6285437
! Ref: gnat_ugn/the_gnat_compilation_model the-configuration-pragmas-files85437
! Ref: 6385437
! Node: Generating Object Files87633
! Ref: gnat_ugn/the_gnat_compilation_model generating-object-files87779
! Ref: 2687779
! Ref: gnat_ugn/the_gnat_compilation_model id3187779
! Ref: 6487779
! Node: Source Dependencies90353
! Ref: gnat_ugn/the_gnat_compilation_model id3290511
! Ref: 6590511
! Ref: gnat_ugn/the_gnat_compilation_model source-dependencies90511
! Ref: 2790511
! Node: The Ada Library Information Files94191
! Ref: gnat_ugn/the_gnat_compilation_model id3394348
! Ref: 6694348
! Ref: gnat_ugn/the_gnat_compilation_model the-ada-library-information-files94348
! Ref: 2894348
! Node: Binding an Ada Program96365
! Ref: gnat_ugn/the_gnat_compilation_model binding-an-ada-program96521
! Ref: 2996521
! Ref: gnat_ugn/the_gnat_compilation_model id3496521
! Ref: 6796521
! Node: GNAT and Libraries98219
! Ref: gnat_ugn/the_gnat_compilation_model gnat-and-libraries98365
! Ref: 2a98365
! Ref: gnat_ugn/the_gnat_compilation_model id3598365
! Ref: 6898365
! Node: Introduction to Libraries in GNAT98843
! Ref: gnat_ugn/the_gnat_compilation_model id3698963
! Ref: 6998963
! Ref: gnat_ugn/the_gnat_compilation_model introduction-to-libraries-in-gnat98963
! Ref: 6a98963
! Node: General Ada Libraries101096
! Ref: gnat_ugn/the_gnat_compilation_model general-ada-libraries101250
! Ref: 6c101250
! Ref: gnat_ugn/the_gnat_compilation_model id37101250
! Ref: 6d101250
! Node: Building a library101385
! Ref: gnat_ugn/the_gnat_compilation_model building-a-library101492
! Ref: 6e101492
! Ref: gnat_ugn/the_gnat_compilation_model id38101492
! Ref: 6f101492
! Node: Installing a library105360
! Ref: gnat_ugn/the_gnat_compilation_model id39105491
! Ref: 71105491
! Ref: gnat_ugn/the_gnat_compilation_model installing-a-library105491
! Ref: 72105491
! Node: Using a library107996
! Ref: gnat_ugn/the_gnat_compilation_model id40108100
! Ref: 74108100
! Ref: gnat_ugn/the_gnat_compilation_model using-a-library108100
! Ref: 75108100
! Node: Stand-alone Ada Libraries110670
! Ref: gnat_ugn/the_gnat_compilation_model id41110827
! Ref: 77110827
! Ref: gnat_ugn/the_gnat_compilation_model stand-alone-ada-libraries110827
! Ref: 6b110827
! Node: Introduction to Stand-alone Libraries111088
! Ref: gnat_ugn/the_gnat_compilation_model id42111228
! Ref: 78111228
! Ref: gnat_ugn/the_gnat_compilation_model introduction-to-stand-alone-libraries111228
! Ref: 79111228
! Node: Building a Stand-alone Library112850
! Ref: gnat_ugn/the_gnat_compilation_model building-a-stand-alone-library113061
! Ref: 7a113061
! Ref: gnat_ugn/the_gnat_compilation_model id43113061
! Ref: 7b113061
! Node: Creating a Stand-alone Library to be used in a non-Ada context117895
! Ref: gnat_ugn/the_gnat_compilation_model creating-a-stand-alone-library-to-be-used-in-a-non-ada-context118106
! Ref: 7c118106
! Ref: gnat_ugn/the_gnat_compilation_model id44118106
! Ref: 7d118106
! Node: Restrictions in Stand-alone Libraries120887
! Ref: gnat_ugn/the_gnat_compilation_model id45121059
! Ref: 7e121059
! Ref: gnat_ugn/the_gnat_compilation_model restrictions-in-stand-alone-libraries121059
! Ref: 7f121059
! Node: Rebuilding the GNAT Run-Time Library122382
! Ref: gnat_ugn/the_gnat_compilation_model id46122509
! Ref: 80122509
! Ref: gnat_ugn/the_gnat_compilation_model rebuilding-the-gnat-run-time-library122509
! Ref: 81122509
! Node: Conditional Compilation123351
! Ref: gnat_ugn/the_gnat_compilation_model conditional-compilation123501
! Ref: 2b123501
! Ref: gnat_ugn/the_gnat_compilation_model id47123501
! Ref: 82123501
! Node: Modeling Conditional Compilation in Ada123807
! Ref: gnat_ugn/the_gnat_compilation_model id48123944
! Ref: 83123944
! Ref: gnat_ugn/the_gnat_compilation_model modeling-conditional-compilation-in-ada123944
! Ref: 84123944
! Node: Use of Boolean Constants125504
! Ref: gnat_ugn/the_gnat_compilation_model id49125641
! Ref: 85125641
! Ref: gnat_ugn/the_gnat_compilation_model use-of-boolean-constants125641
! Ref: 86125641
! Node: Debugging - A Special Case126950
! Ref: gnat_ugn/the_gnat_compilation_model debugging-a-special-case127125
! Ref: 87127125
! Ref: gnat_ugn/the_gnat_compilation_model id50127125
! Ref: 88127125
! Node: Conditionalizing Declarations130632
! Ref: gnat_ugn/the_gnat_compilation_model conditionalizing-declarations130817
! Ref: 89130817
! Ref: gnat_ugn/the_gnat_compilation_model id51130817
! Ref: 8a130817
! Node: Use of Alternative Implementations132545
! Ref: gnat_ugn/the_gnat_compilation_model id52132717
! Ref: 8b132717
! Ref: gnat_ugn/the_gnat_compilation_model use-of-alternative-implementations132717
! Ref: 8c132717
! Node: Preprocessing136913
! Ref: gnat_ugn/the_gnat_compilation_model id53137047
! Ref: 8d137047
! Ref: gnat_ugn/the_gnat_compilation_model preprocessing137047
! Ref: 8e137047
! Node: Preprocessing with gnatprep138729
! Ref: gnat_ugn/the_gnat_compilation_model id54138899
! Ref: 91138899
! Ref: gnat_ugn/the_gnat_compilation_model preprocessing-with-gnatprep138899
! Ref: 8f138899
! Node: Preprocessing Symbols139418
! Ref: gnat_ugn/the_gnat_compilation_model id55139528
! Ref: 92139528
! Ref: gnat_ugn/the_gnat_compilation_model preprocessing-symbols139528
! Ref: 93139528
! Node: Using gnatprep139894
! Ref: gnat_ugn/the_gnat_compilation_model id56140034
! Ref: 94140034
! Ref: gnat_ugn/the_gnat_compilation_model using-gnatprep140034
! Ref: 95140034
! Node: Switches for gnatprep140932
! Ref: gnat_ugn/the_gnat_compilation_model id57141075
! Ref: 96141075
! Ref: gnat_ugn/the_gnat_compilation_model switches-for-gnatprep141075
! Ref: 97141075
! Node: Form of Definitions File144190
! Ref: gnat_ugn/the_gnat_compilation_model form-of-definitions-file144350
! Ref: 98144350
! Ref: gnat_ugn/the_gnat_compilation_model id58144350
! Ref: 99144350
! Node: Form of Input Text for gnatprep144912
! Ref: gnat_ugn/the_gnat_compilation_model form-of-input-text-for-gnatprep145042
! Ref: 9a145042
! Ref: gnat_ugn/the_gnat_compilation_model id59145042
! Ref: 9b145042
! Node: Integrated Preprocessing149605
! Ref: gnat_ugn/the_gnat_compilation_model id60149727
! Ref: 9c149727
! Ref: gnat_ugn/the_gnat_compilation_model integrated-preprocessing149727
! Ref: 90149727
! Node: Mixed Language Programming158099
! Ref: gnat_ugn/the_gnat_compilation_model id61158264
! Ref: 9d158264
! Ref: gnat_ugn/the_gnat_compilation_model mixed-language-programming158264
! Ref: 2c158264
! Node: Interfacing to C158632
! Ref: gnat_ugn/the_gnat_compilation_model id62158741
! Ref: 9e158741
! Ref: gnat_ugn/the_gnat_compilation_model interfacing-to-c158741
! Ref: 9f158741
! Node: Calling Conventions163951
! Ref: gnat_ugn/the_gnat_compilation_model calling-conventions164104
! Ref: a1164104
! Ref: gnat_ugn/the_gnat_compilation_model id63164104
! Ref: a2164104
! Node: Building Mixed Ada and C++ Programs171926
! Ref: gnat_ugn/the_gnat_compilation_model building-mixed-ada-and-c-programs172108
! Ref: a3172108
! Ref: gnat_ugn/the_gnat_compilation_model id64172108
! Ref: a4172108
! Node: Interfacing to C++172587
! Ref: gnat_ugn/the_gnat_compilation_model id65172721
! Ref: a5172721
! Ref: gnat_ugn/the_gnat_compilation_model id66172721
! Ref: a6172721
! Node: Linking a Mixed C++ & Ada Program173834
! Ref: gnat_ugn/the_gnat_compilation_model linking-a-mixed-c-ada-program173993
! Ref: a8173993
! Ref: gnat_ugn/the_gnat_compilation_model linking-a-mixed-c-and-ada-program173993
! Ref: a9173993
! Node: A Simple Example178027
! Ref: gnat_ugn/the_gnat_compilation_model a-simple-example178201
! Ref: aa178201
! Ref: gnat_ugn/the_gnat_compilation_model id67178201
! Ref: ab178201
! Node: Interfacing with C++ constructors180920
! Ref: gnat_ugn/the_gnat_compilation_model id68181100
! Ref: ac181100
! Ref: gnat_ugn/the_gnat_compilation_model interfacing-with-c-constructors181100
! Ref: ad181100
! Node: Interfacing with C++ at the Class Level187839
! Ref: gnat_ugn/the_gnat_compilation_model id69187994
! Ref: af187994
! Ref: gnat_ugn/the_gnat_compilation_model interfacing-with-c-at-the-class-level187994
! Ref: ae187994
! Node: Generating Ada Bindings for C and C++ headers196691
! Ref: gnat_ugn/the_gnat_compilation_model generating-ada-bindings-for-c-and-c-headers196897
! Ref: a7196897
! Ref: gnat_ugn/the_gnat_compilation_model id70196897
! Ref: b0196897
! Node: Running the Binding Generator198184
! Ref: gnat_ugn/the_gnat_compilation_model id71198341
! Ref: b1198341
! Ref: gnat_ugn/the_gnat_compilation_model running-the-binding-generator198341
! Ref: b2198341
! Node: Generating Bindings for C++ Headers200920
! Ref: gnat_ugn/the_gnat_compilation_model generating-bindings-for-c-headers201094
! Ref: b3201094
! Ref: gnat_ugn/the_gnat_compilation_model id72201094
! Ref: b4201094
! Node: Switches204015
! Ref: gnat_ugn/the_gnat_compilation_model switches204151
! Ref: b5204151
! Ref: gnat_ugn/the_gnat_compilation_model switches-for-ada-binding-generation204151
! Ref: b6204151
! Node: Generating C Headers for Ada Specifications204722
! Ref: gnat_ugn/the_gnat_compilation_model generating-c-headers-for-ada-specifications204884
! Ref: b7204884
! Ref: gnat_ugn/the_gnat_compilation_model id73204884
! Ref: b8204884
! Node: Running the C Header Generator205387
! Ref: gnat_ugn/the_gnat_compilation_model running-the-c-header-generator205499
! Ref: b9205499
! Node: GNAT and Other Compilation Models207279
! Ref: gnat_ugn/the_gnat_compilation_model gnat-and-other-compilation-models207457
! Ref: 2d207457
! Ref: gnat_ugn/the_gnat_compilation_model id74207457
! Ref: ba207457
! Node: Comparison between GNAT and C/C++ Compilation Models207891
! Ref: gnat_ugn/the_gnat_compilation_model comparison-between-gnat-and-c-c-compilation-models208083
! Ref: bb208083
! Ref: gnat_ugn/the_gnat_compilation_model id75208083
! Ref: bc208083
! Node: Comparison between GNAT and Conventional Ada Library Models209604
! Ref: gnat_ugn/the_gnat_compilation_model comparison-between-gnat-and-conventional-ada-library-models209796
! Ref: bd209796
! Ref: gnat_ugn/the_gnat_compilation_model id76209796
! Ref: be209796
! Node: Using GNAT Files with External Tools212175
! Ref: gnat_ugn/the_gnat_compilation_model id77212318
! Ref: bf212318
! Ref: gnat_ugn/the_gnat_compilation_model using-gnat-files-with-external-tools212318
! Ref: 2e212318
! Node: Using Other Utility Programs with GNAT212614
! Ref: gnat_ugn/the_gnat_compilation_model id78212777
! Ref: c0212777
! Ref: gnat_ugn/the_gnat_compilation_model using-other-utility-programs-with-gnat212777
! Ref: c1212777
! Node: The External Symbol Naming Scheme of GNAT213336
! Ref: gnat_ugn/the_gnat_compilation_model id79213499
! Ref: c2213499
! Ref: gnat_ugn/the_gnat_compilation_model the-external-symbol-naming-scheme-of-gnat213499
! Ref: c3213499
! Node: Building Executable Programs with GNAT215409
! Ref: gnat_ugn/building_executable_programs_with_gnat doc215554
! Ref: c4215554
! Ref: gnat_ugn/building_executable_programs_with_gnat building-executable-programs-with-gnat215554
! Ref: a215554
! Ref: gnat_ugn/building_executable_programs_with_gnat id1215554
! Ref: c5215554
! Node: Building with gnatmake216469
! Ref: gnat_ugn/building_executable_programs_with_gnat building-with-gnatmake216595
! Ref: ca216595
! Ref: gnat_ugn/building_executable_programs_with_gnat the-gnat-make-program-gnatmake216595
! Ref: c6216595
! Node: Running gnatmake218216
! Ref: gnat_ugn/building_executable_programs_with_gnat id2218323
! Ref: cb218323
! Ref: gnat_ugn/building_executable_programs_with_gnat running-gnatmake218323
! Ref: cc218323
! Node: Switches for gnatmake219797
! Ref: gnat_ugn/building_executable_programs_with_gnat id3219939
! Ref: cd219939
! Ref: gnat_ugn/building_executable_programs_with_gnat switches-for-gnatmake219939
! Ref: ce219939
! Node: Mode Switches for gnatmake241273
! Ref: gnat_ugn/building_executable_programs_with_gnat id4241424
! Ref: d0241424
! Ref: gnat_ugn/building_executable_programs_with_gnat mode-switches-for-gnatmake241424
! Ref: d1241424
! Node: Notes on the Command Line242719
! Ref: gnat_ugn/building_executable_programs_with_gnat id5242867
! Ref: d2242867
! Ref: gnat_ugn/building_executable_programs_with_gnat notes-on-the-command-line242867
! Ref: d3242867
! Node: How gnatmake Works245344
! Ref: gnat_ugn/building_executable_programs_with_gnat how-gnatmake-works245492
! Ref: d4245492
! Ref: gnat_ugn/building_executable_programs_with_gnat id6245492
! Ref: d5245492
! Node: Examples of gnatmake Usage247843
! Ref: gnat_ugn/building_executable_programs_with_gnat examples-of-gnatmake-usage247957
! Ref: d6247957
! Ref: gnat_ugn/building_executable_programs_with_gnat id7247957
! Ref: d7247957
! Node: Compiling with gcc249040
! Ref: gnat_ugn/building_executable_programs_with_gnat compiling-with-gcc249192
! Ref: c7249192
! Ref: gnat_ugn/building_executable_programs_with_gnat id8249192
! Ref: d8249192
! Node: Compiling Programs249593
! Ref: gnat_ugn/building_executable_programs_with_gnat compiling-programs249718
! Ref: d9249718
! Ref: gnat_ugn/building_executable_programs_with_gnat id9249718
! Ref: da249718
! Node: Search Paths and the Run-Time Library RTL253161
! Ref: gnat_ugn/building_executable_programs_with_gnat id10253322
! Ref: dc253322
! Ref: gnat_ugn/building_executable_programs_with_gnat search-paths-and-the-run-time-library-rtl253322
! Ref: 73253322
! Node: Order of Compilation Issues256755
! Ref: gnat_ugn/building_executable_programs_with_gnat id11256906
! Ref: dd256906
! Ref: gnat_ugn/building_executable_programs_with_gnat order-of-compilation-issues256906
! Ref: de256906
! Node: Examples258475
! Ref: gnat_ugn/building_executable_programs_with_gnat examples258576
! Ref: df258576
! Ref: gnat_ugn/building_executable_programs_with_gnat id12258576
! Ref: e0258576
! Node: Compiler Switches259058
! Ref: gnat_ugn/building_executable_programs_with_gnat compiler-switches259203
! Ref: e1259203
! Ref: gnat_ugn/building_executable_programs_with_gnat switches-for-gcc259203
! Ref: db259203
! Node: Alphabetical List of All Switches260357
! Ref: gnat_ugn/building_executable_programs_with_gnat alphabetical-list-of-all-switches260487
! Ref: e2260487
! Ref: gnat_ugn/building_executable_programs_with_gnat id13260487
! Ref: e3260487
! Node: Output and Error Message Control297027
! Ref: gnat_ugn/building_executable_programs_with_gnat id14297189
! Ref: ee297189
! Ref: gnat_ugn/building_executable_programs_with_gnat output-and-error-message-control297189
! Ref: ef297189
! Node: Warning Message Control305265
! Ref: gnat_ugn/building_executable_programs_with_gnat id15305425
! Ref: f0305425
! Ref: gnat_ugn/building_executable_programs_with_gnat warning-message-control305425
! Ref: eb305425
! Node: Debugging and Assertion Control356101
! Ref: gnat_ugn/building_executable_programs_with_gnat debugging-and-assertion-control356246
! Ref: f1356246
! Ref: gnat_ugn/building_executable_programs_with_gnat id16356246
! Ref: f2356246
! Node: Validity Checking359693
! Ref: gnat_ugn/building_executable_programs_with_gnat id17359829
! Ref: f3359829
! Ref: gnat_ugn/building_executable_programs_with_gnat validity-checking359829
! Ref: e7359829
! Node: Style Checking369853
! Ref: gnat_ugn/building_executable_programs_with_gnat id18369973
! Ref: f4369973
! Ref: gnat_ugn/building_executable_programs_with_gnat style-checking369973
! Ref: ec369973
! Node: Run-Time Checks387570
! Ref: gnat_ugn/building_executable_programs_with_gnat id19387702
! Ref: f5387702
! Ref: gnat_ugn/building_executable_programs_with_gnat run-time-checks387702
! Ref: ea387702
! Node: Using gcc for Syntax Checking394399
! Ref: gnat_ugn/building_executable_programs_with_gnat id20394548
! Ref: f6394548
! Ref: gnat_ugn/building_executable_programs_with_gnat using-gcc-for-syntax-checking394548
! Ref: f7394548
! Node: Using gcc for Semantic Checking396234
! Ref: gnat_ugn/building_executable_programs_with_gnat id21396403
! Ref: f8396403
! Ref: gnat_ugn/building_executable_programs_with_gnat using-gcc-for-semantic-checking396403
! Ref: f9396403
! Node: Compiling Different Versions of Ada397761
! Ref: gnat_ugn/building_executable_programs_with_gnat compiling-different-versions-of-ada397922
! Ref: 6397922
! Ref: gnat_ugn/building_executable_programs_with_gnat id22397922
! Ref: fa397922
! Node: Character Set Control402183
! Ref: gnat_ugn/building_executable_programs_with_gnat character-set-control402332
! Ref: 31402332
! Ref: gnat_ugn/building_executable_programs_with_gnat id23402332
! Ref: fb402332
! Node: File Naming Control407650
! Ref: gnat_ugn/building_executable_programs_with_gnat file-naming-control407791
! Ref: fc407791
! Ref: gnat_ugn/building_executable_programs_with_gnat id24407791
! Ref: fd407791
! Node: Subprogram Inlining Control408199
! Ref: gnat_ugn/building_executable_programs_with_gnat id25408343
! Ref: fe408343
! Ref: gnat_ugn/building_executable_programs_with_gnat subprogram-inlining-control408343
! Ref: ff408343
! Node: Auxiliary Output Control410220
! Ref: gnat_ugn/building_executable_programs_with_gnat auxiliary-output-control410362
! Ref: 101410362
! Ref: gnat_ugn/building_executable_programs_with_gnat id26410362
! Ref: 102410362
! Node: Debugging Control411523
! Ref: gnat_ugn/building_executable_programs_with_gnat debugging-control411664
! Ref: 103411664
! Ref: gnat_ugn/building_executable_programs_with_gnat id27411664
! Ref: 104411664
! Node: Exception Handling Control423518
! Ref: gnat_ugn/building_executable_programs_with_gnat exception-handling-control423665
! Ref: 105423665
! Ref: gnat_ugn/building_executable_programs_with_gnat id28423665
! Ref: 106423665
! Node: Units to Sources Mapping Files426342
! Ref: gnat_ugn/building_executable_programs_with_gnat id29426495
! Ref: 107426495
! Ref: gnat_ugn/building_executable_programs_with_gnat units-to-sources-mapping-files426495
! Ref: e8426495
! Node: Code Generation Control428434
! Ref: gnat_ugn/building_executable_programs_with_gnat code-generation-control428552
! Ref: 108428552
! Ref: gnat_ugn/building_executable_programs_with_gnat id30428552
! Ref: 109428552
! Node: Linker Switches429724
! Ref: gnat_ugn/building_executable_programs_with_gnat id31429872
! Ref: 10a429872
! Ref: gnat_ugn/building_executable_programs_with_gnat linker-switches429872
! Ref: 10b429872
! Node: Binding with gnatbind430234
! Ref: gnat_ugn/building_executable_programs_with_gnat binding-with-gnatbind430386
! Ref: c8430386
! Ref: gnat_ugn/building_executable_programs_with_gnat id32430386
! Ref: 10c430386
! Node: Running gnatbind431910
! Ref: gnat_ugn/building_executable_programs_with_gnat id33432016
! Ref: 10d432016
! Ref: gnat_ugn/building_executable_programs_with_gnat running-gnatbind432016
! Ref: 10e432016
! Node: Switches for gnatbind435048
! Ref: gnat_ugn/building_executable_programs_with_gnat id34435182
! Ref: 10f435182
! Ref: gnat_ugn/building_executable_programs_with_gnat switches-for-gnatbind435182
! Ref: 110435182
! Node: Consistency-Checking Modes448523
! Ref: gnat_ugn/building_executable_programs_with_gnat consistency-checking-modes448646
! Ref: 114448646
! Ref: gnat_ugn/building_executable_programs_with_gnat id35448646
! Ref: 115448646
! Node: Binder Error Message Control450465
! Ref: gnat_ugn/building_executable_programs_with_gnat binder-error-message-control450616
! Ref: 116450616
! Ref: gnat_ugn/building_executable_programs_with_gnat id36450616
! Ref: 117450616
! Node: Elaboration Control452860
! Ref: gnat_ugn/building_executable_programs_with_gnat elaboration-control452999
! Ref: 111452999
! Ref: gnat_ugn/building_executable_programs_with_gnat id37452999
! Ref: 118452999
! Node: Output Control456301
! Ref: gnat_ugn/building_executable_programs_with_gnat id38456438
! Ref: 119456438
! Ref: gnat_ugn/building_executable_programs_with_gnat output-control456438
! Ref: 11a456438
! Node: Dynamic Allocation Control458433
! Ref: gnat_ugn/building_executable_programs_with_gnat dynamic-allocation-control458585
! Ref: 112458585
! Ref: gnat_ugn/building_executable_programs_with_gnat id39458585
! Ref: 11b458585
! Node: Binding with Non-Ada Main Programs459206
! Ref: gnat_ugn/building_executable_programs_with_gnat binding-with-non-ada-main-programs459384
! Ref: a0459384
! Ref: gnat_ugn/building_executable_programs_with_gnat id40459384
! Ref: 11c459384
! Node: Binding Programs with No Main Subprogram462394
! Ref: gnat_ugn/building_executable_programs_with_gnat binding-programs-with-no-main-subprogram462537
! Ref: 11d462537
! Ref: gnat_ugn/building_executable_programs_with_gnat id41462537
! Ref: 11e462537
! Node: Command-Line Access463405
! Ref: gnat_ugn/building_executable_programs_with_gnat command-line-access463548
! Ref: 11f463548
! Ref: gnat_ugn/building_executable_programs_with_gnat id42463548
! Ref: 120463548
! Node: Search Paths for gnatbind464458
! Ref: gnat_ugn/building_executable_programs_with_gnat id43464606
! Ref: 121464606
! Ref: gnat_ugn/building_executable_programs_with_gnat search-paths-for-gnatbind464606
! Ref: 76464606
! Node: Examples of gnatbind Usage467423
! Ref: gnat_ugn/building_executable_programs_with_gnat examples-of-gnatbind-usage467543
! Ref: 122467543
! Ref: gnat_ugn/building_executable_programs_with_gnat id44467543
! Ref: 123467543
! Node: Linking with gnatlink468391
! Ref: gnat_ugn/building_executable_programs_with_gnat id45468554
! Ref: 124468554
! Ref: gnat_ugn/building_executable_programs_with_gnat linking-with-gnatlink468554
! Ref: c9468554
! Node: Running gnatlink469090
! Ref: gnat_ugn/building_executable_programs_with_gnat id46469196
! Ref: 125469196
! Ref: gnat_ugn/building_executable_programs_with_gnat running-gnatlink469196
! Ref: 126469196
! Node: Switches for gnatlink471668
! Ref: gnat_ugn/building_executable_programs_with_gnat id47471774
! Ref: 129471774
! Ref: gnat_ugn/building_executable_programs_with_gnat switches-for-gnatlink471774
! Ref: 12a471774
! Node: Using the GNU make Utility476484
! Ref: gnat_ugn/building_executable_programs_with_gnat id48476617
! Ref: 12b476617
! Ref: gnat_ugn/building_executable_programs_with_gnat using-the-gnu-make-utility476617
! Ref: 70476617
! Node: Using gnatmake in a Makefile477305
! Ref: gnat_ugn/building_executable_programs_with_gnat id49477451
! Ref: 12c477451
! Ref: gnat_ugn/building_executable_programs_with_gnat using-gnatmake-in-a-makefile477451
! Ref: 12d477451
! Node: Automatically Creating a List of Directories481479
! Ref: gnat_ugn/building_executable_programs_with_gnat automatically-creating-a-list-of-directories481670
! Ref: 12e481670
! Ref: gnat_ugn/building_executable_programs_with_gnat id50481670
! Ref: 12f481670
! Node: Generating the Command Line Switches484625
! Ref: gnat_ugn/building_executable_programs_with_gnat generating-the-command-line-switches484825
! Ref: 130484825
! Ref: gnat_ugn/building_executable_programs_with_gnat id51484825
! Ref: 131484825
! Node: Overcoming Command Line Length Limits485603
! Ref: gnat_ugn/building_executable_programs_with_gnat id52485750
! Ref: 132485750
! Ref: gnat_ugn/building_executable_programs_with_gnat overcoming-command-line-length-limits485750
! Ref: 133485750
! Node: GNAT Utility Programs488055
! Ref: gnat_ugn/gnat_utility_programs doc488200
! Ref: 134488200
! Ref: gnat_ugn/gnat_utility_programs gnat-utility-programs488200
! Ref: b488200
! Ref: gnat_ugn/gnat_utility_programs id1488200
! Ref: 135488200
! Node: The File Cleanup Utility gnatclean488767
! Ref: gnat_ugn/gnat_utility_programs id2488901
! Ref: 138488901
! Ref: gnat_ugn/gnat_utility_programs the-file-cleanup-utility-gnatclean488901
! Ref: 136488901
! Node: Running gnatclean489312
! Ref: gnat_ugn/gnat_utility_programs id3489433
! Ref: 139489433
! Ref: gnat_ugn/gnat_utility_programs running-gnatclean489433
! Ref: 13a489433
! Node: Switches for gnatclean490082
! Ref: gnat_ugn/gnat_utility_programs id4490203
! Ref: 13b490203
! Ref: gnat_ugn/gnat_utility_programs switches-for-gnatclean490203
! Ref: 13c490203
! Node: The GNAT Library Browser gnatls493343
! Ref: gnat_ugn/gnat_utility_programs id5493477
! Ref: 13d493477
! Ref: gnat_ugn/gnat_utility_programs the-gnat-library-browser-gnatls493477
! Ref: 137493477
! Node: Running gnatls493883
! Ref: gnat_ugn/gnat_utility_programs id6493995
! Ref: 13e493995
! Ref: gnat_ugn/gnat_utility_programs running-gnatls493995
! Ref: 13f493995
! Node: Switches for gnatls496484
! Ref: gnat_ugn/gnat_utility_programs id7496628
! Ref: 140496628
! Ref: gnat_ugn/gnat_utility_programs switches-for-gnatls496628
! Ref: 141496628
! Node: Example of gnatls Usage499054
! Ref: gnat_ugn/gnat_utility_programs example-of-gnatls-usage499175
! Ref: 142499175
! Ref: gnat_ugn/gnat_utility_programs id8499175
! Ref: 143499175
! Node: GNAT and Program Execution501578
! Ref: gnat_ugn/gnat_and_program_execution doc501714
! Ref: 144501714
! Ref: gnat_ugn/gnat_and_program_execution gnat-and-program-execution501714
! Ref: c501714
! Ref: gnat_ugn/gnat_and_program_execution id1501714
! Ref: 145501714
! Node: Running and Debugging Ada Programs502358
! Ref: gnat_ugn/gnat_and_program_execution id2502475
! Ref: 146502475
! Ref: gnat_ugn/gnat_and_program_execution running-and-debugging-ada-programs502475
! Ref: 14d502475
! Node: The GNAT Debugger GDB503845
! Ref: gnat_ugn/gnat_and_program_execution id3503959
! Ref: 14e503959
! Ref: gnat_ugn/gnat_and_program_execution the-gnat-debugger-gdb503959
! Ref: 14f503959
! Node: Running GDB507024
! Ref: gnat_ugn/gnat_and_program_execution id4507175
! Ref: 150507175
! Ref: gnat_ugn/gnat_and_program_execution running-gdb507175
! Ref: 151507175
! Node: Introduction to GDB Commands507968
! Ref: gnat_ugn/gnat_and_program_execution id5508119
! Ref: 152508119
! Ref: gnat_ugn/gnat_and_program_execution introduction-to-gdb-commands508119
! Ref: 153508119
! Node: Using Ada Expressions514063
! Ref: gnat_ugn/gnat_and_program_execution id6514235
! Ref: 154514235
! Ref: gnat_ugn/gnat_and_program_execution using-ada-expressions514235
! Ref: 155514235
! Node: Calling User-Defined Subprograms515350
! Ref: gnat_ugn/gnat_and_program_execution calling-user-defined-subprograms515530
! Ref: 156515530
! Ref: gnat_ugn/gnat_and_program_execution id7515530
! Ref: 157515530
! Node: Using the next Command in a Function518297
! Ref: gnat_ugn/gnat_and_program_execution id8518495
! Ref: 158518495
! Ref: gnat_ugn/gnat_and_program_execution using-the-next-command-in-a-function518495
! Ref: 159518495
! Node: Stopping When Ada Exceptions Are Raised519519
! Ref: gnat_ugn/gnat_and_program_execution id9519694
! Ref: 15a519694
! Ref: gnat_ugn/gnat_and_program_execution stopping-when-ada-exceptions-are-raised519694
! Ref: 15b519694
! Node: Ada Tasks520725
! Ref: gnat_ugn/gnat_and_program_execution ada-tasks520887
! Ref: 15c520887
! Ref: gnat_ugn/gnat_and_program_execution id10520887
! Ref: 15d520887
! Node: Debugging Generic Units523099
! Ref: gnat_ugn/gnat_and_program_execution debugging-generic-units523253
! Ref: 15e523253
! Ref: gnat_ugn/gnat_and_program_execution id11523253
! Ref: 15f523253
! Node: Remote Debugging with gdbserver524571
! Ref: gnat_ugn/gnat_and_program_execution id12524765
! Ref: 160524765
! Ref: gnat_ugn/gnat_and_program_execution remote-debugging-with-gdbserver524765
! Ref: 161524765
! Node: GNAT Abnormal Termination or Failure to Terminate526697
! Ref: gnat_ugn/gnat_and_program_execution gnat-abnormal-termination-or-failure-to-terminate526908
! Ref: 162526908
! Ref: gnat_ugn/gnat_and_program_execution id13526908
! Ref: 163526908
! Node: Naming Conventions for GNAT Source Files529387
! Ref: gnat_ugn/gnat_and_program_execution id14529605
! Ref: 164529605
! Ref: gnat_ugn/gnat_and_program_execution naming-conventions-for-gnat-source-files529605
! Ref: 165529605
! Node: Getting Internal Debugging Information532080
! Ref: gnat_ugn/gnat_and_program_execution getting-internal-debugging-information532264
! Ref: 166532264
! Ref: gnat_ugn/gnat_and_program_execution id15532264
! Ref: 167532264
! Node: Stack Traceback533298
! Ref: gnat_ugn/gnat_and_program_execution id16533478
! Ref: 168533478
! Ref: gnat_ugn/gnat_and_program_execution stack-traceback533478
! Ref: 169533478
! Node: Non-Symbolic Traceback534395
! Ref: gnat_ugn/gnat_and_program_execution id17534498
! Ref: 16a534498
! Ref: gnat_ugn/gnat_and_program_execution non-symbolic-traceback534498
! Ref: 16b534498
! Node: Symbolic Traceback543705
! Ref: gnat_ugn/gnat_and_program_execution id18543808
! Ref: 16c543808
! Ref: gnat_ugn/gnat_and_program_execution symbolic-traceback543808
! Ref: 16d543808
! Node: Pretty-Printers for the GNAT runtime546882
! Ref: gnat_ugn/gnat_and_program_execution id19547015
! Ref: 16e547015
! Ref: gnat_ugn/gnat_and_program_execution pretty-printers-for-the-gnat-runtime547015
! Ref: 16f547015
! Ref: Pretty-Printers for the GNAT runtime-Footnote-1549654
! Ref: Pretty-Printers for the GNAT runtime-Footnote-2549742
! Node: Profiling549826
! Ref: gnat_ugn/gnat_and_program_execution id20549973
! Ref: 170549973
! Ref: gnat_ugn/gnat_and_program_execution profiling549973
! Ref: 147549973
! Node: Profiling an Ada Program with gprof550134
! Ref: gnat_ugn/gnat_and_program_execution id21550217
! Ref: 171550217
! Ref: gnat_ugn/gnat_and_program_execution profiling-an-ada-program-with-gprof550217
! Ref: 172550217
! Node: Compilation for profiling551434
! Ref: gnat_ugn/gnat_and_program_execution compilation-for-profiling551559
! Ref: 173551559
! Ref: gnat_ugn/gnat_and_program_execution id22551559
! Ref: 174551559
! Node: Program execution552343
! Ref: gnat_ugn/gnat_and_program_execution id23552490
! Ref: 175552490
! Ref: gnat_ugn/gnat_and_program_execution program-execution552490
! Ref: 176552490
! Node: Running gprof552982
! Ref: gnat_ugn/gnat_and_program_execution id24553139
! Ref: 177553139
! Ref: gnat_ugn/gnat_and_program_execution running-gprof553139
! Ref: 178553139
! Node: Interpretation of profiling results555847
! Ref: gnat_ugn/gnat_and_program_execution id25555978
! Ref: 179555978
! Ref: gnat_ugn/gnat_and_program_execution interpretation-of-profiling-results555978
! Ref: 17a555978
! Node: Improving Performance556653
! Ref: gnat_ugn/gnat_and_program_execution id26556797
! Ref: 148556797
! Ref: gnat_ugn/gnat_and_program_execution improving-performance556797
! Ref: 17b556797
! Node: Performance Considerations557307
! Ref: gnat_ugn/gnat_and_program_execution id27557421
! Ref: 17c557421
! Ref: gnat_ugn/gnat_and_program_execution performance-considerations557421
! Ref: 17d557421
! Node: Controlling Run-Time Checks558590
! Ref: gnat_ugn/gnat_and_program_execution controlling-run-time-checks558710
! Ref: 17e558710
! Ref: gnat_ugn/gnat_and_program_execution id28558710
! Ref: 17f558710
! Node: Use of Restrictions560268
! Ref: gnat_ugn/gnat_and_program_execution id29560416
! Ref: 180560416
! Ref: gnat_ugn/gnat_and_program_execution use-of-restrictions560416
! Ref: 181560416
! Node: Optimization Levels561774
! Ref: gnat_ugn/gnat_and_program_execution id30561919
! Ref: 182561919
! Ref: gnat_ugn/gnat_and_program_execution optimization-levels561919
! Ref: ed561919
! Node: Debugging Optimized Code565778
! Ref: gnat_ugn/gnat_and_program_execution debugging-optimized-code565927
! Ref: 183565927
! Ref: gnat_ugn/gnat_and_program_execution id31565927
! Ref: 184565927
! Node: Inlining of Subprograms570843
! Ref: gnat_ugn/gnat_and_program_execution id32570998
! Ref: 185570998
! Ref: gnat_ugn/gnat_and_program_execution inlining-of-subprograms570998
! Ref: 100570998
! Node: Floating Point Operations575678
! Ref: gnat_ugn/gnat_and_program_execution floating-point-operations575831
! Ref: 186575831
! Ref: gnat_ugn/gnat_and_program_execution id33575831
! Ref: 187575831
! Node: Vectorization of loops578014
! Ref: gnat_ugn/gnat_and_program_execution id34578171
! Ref: 188578171
! Ref: gnat_ugn/gnat_and_program_execution vectorization-of-loops578171
! Ref: 189578171
! Node: Other Optimization Switches582799
! Ref: gnat_ugn/gnat_and_program_execution id35582963
! Ref: 18a582963
! Ref: gnat_ugn/gnat_and_program_execution other-optimization-switches582963
! Ref: 18b582963
! Node: Optimization and Strict Aliasing583660
! Ref: gnat_ugn/gnat_and_program_execution id36583836
! Ref: 18c583836
! Ref: gnat_ugn/gnat_and_program_execution optimization-and-strict-aliasing583836
! Ref: e4583836
! Node: Aliased Variables and Optimization592867
! Ref: gnat_ugn/gnat_and_program_execution aliased-variables-and-optimization593049
! Ref: 18d593049
! Ref: gnat_ugn/gnat_and_program_execution id37593049
! Ref: 18e593049
! Node: Atomic Variables and Optimization595041
! Ref: gnat_ugn/gnat_and_program_execution atomic-variables-and-optimization595216
! Ref: 18f595216
! Ref: gnat_ugn/gnat_and_program_execution id38595216
! Ref: 190595216
! Node: Passive Task Optimization597816
! Ref: gnat_ugn/gnat_and_program_execution id39597948
! Ref: 191597948
! Ref: gnat_ugn/gnat_and_program_execution passive-task-optimization597948
! Ref: 192597948
! Node: Text_IO Suggestions599923
! Ref: gnat_ugn/gnat_and_program_execution id40600114
! Ref: 193600114
! Ref: gnat_ugn/gnat_and_program_execution text-io-suggestions600114
! Ref: 194600114
! Node: Reducing Size of Executables with Unused Subprogram/Data Elimination601050
! Ref: gnat_ugn/gnat_and_program_execution id41601206
! Ref: 195601206
! Ref: gnat_ugn/gnat_and_program_execution reducing-size-of-executables-with-unused-subprogram-data-elimination601206
! Ref: 196601206
! Node: About unused subprogram/data elimination601626
! Ref: gnat_ugn/gnat_and_program_execution about-unused-subprogram-data-elimination601801
! Ref: 197601801
! Ref: gnat_ugn/gnat_and_program_execution id42601801
! Ref: 198601801
! Node: Compilation options602442
! Ref: gnat_ugn/gnat_and_program_execution compilation-options602671
! Ref: 199602671
! Ref: gnat_ugn/gnat_and_program_execution id43602671
! Ref: 19a602671
! Node: Example of unused subprogram/data elimination604060
! Ref: gnat_ugn/gnat_and_program_execution example-of-unused-subprogram-data-elimination604240
! Ref: 19b604240
! Ref: gnat_ugn/gnat_and_program_execution id44604240
! Ref: 19c604240
! Node: Overflow Check Handling in GNAT605712
! Ref: gnat_ugn/gnat_and_program_execution id45605889
! Ref: 149605889
! Ref: gnat_ugn/gnat_and_program_execution overflow-check-handling-in-gnat605889
! Ref: 19d605889
! Node: Background606172
! Ref: gnat_ugn/gnat_and_program_execution background606292
! Ref: 19e606292
! Ref: gnat_ugn/gnat_and_program_execution id46606292
! Ref: 19f606292
! Node: Management of Overflows in GNAT609965
! Ref: gnat_ugn/gnat_and_program_execution id47610121
! Ref: 1a0610121
! Ref: gnat_ugn/gnat_and_program_execution management-of-overflows-in-gnat610121
! Ref: 1a1610121
! Node: Specifying the Desired Mode615121
! Ref: gnat_ugn/gnat_and_program_execution id48615283
! Ref: 1a2615283
! Ref: gnat_ugn/gnat_and_program_execution specifying-the-desired-mode615283
! Ref: e9615283
! Node: Default Settings618397
! Ref: gnat_ugn/gnat_and_program_execution default-settings618548
! Ref: 1a3618548
! Ref: gnat_ugn/gnat_and_program_execution id49618548
! Ref: 1a4618548
! Node: Implementation Notes619442
! Ref: gnat_ugn/gnat_and_program_execution id50619557
! Ref: 1a5619557
! Ref: gnat_ugn/gnat_and_program_execution implementation-notes619557
! Ref: 1a6619557
! Node: Performing Dimensionality Analysis in GNAT621699
! Ref: gnat_ugn/gnat_and_program_execution id51621879
! Ref: 14a621879
! Ref: gnat_ugn/gnat_and_program_execution performing-dimensionality-analysis-in-gnat621879
! Ref: 1a7621879
! Node: Stack Related Facilities632908
! Ref: gnat_ugn/gnat_and_program_execution id52633081
! Ref: 14b633081
! Ref: gnat_ugn/gnat_and_program_execution stack-related-facilities633081
! Ref: 1a8633081
! Node: Stack Overflow Checking633405
! Ref: gnat_ugn/gnat_and_program_execution id53633527
! Ref: 1a9633527
! Ref: gnat_ugn/gnat_and_program_execution stack-overflow-checking633527
! Ref: e5633527
! Node: Static Stack Usage Analysis635167
! Ref: gnat_ugn/gnat_and_program_execution id54635326
! Ref: 1aa635326
! Ref: gnat_ugn/gnat_and_program_execution static-stack-usage-analysis635326
! Ref: e6635326
! Node: Dynamic Stack Usage Analysis636725
! Ref: gnat_ugn/gnat_and_program_execution dynamic-stack-usage-analysis636852
! Ref: 113636852
! Ref: gnat_ugn/gnat_and_program_execution id55636852
! Ref: 1ab636852
! Node: Memory Management Issues638781
! Ref: gnat_ugn/gnat_and_program_execution id56638903
! Ref: 14c638903
! Ref: gnat_ugn/gnat_and_program_execution memory-management-issues638903
! Ref: 1ac638903
! Node: Some Useful Memory Pools639259
! Ref: gnat_ugn/gnat_and_program_execution id57639383
! Ref: 1ad639383
! Ref: gnat_ugn/gnat_and_program_execution some-useful-memory-pools639383
! Ref: 1ae639383
! Node: The GNAT Debug Pool Facility642040
! Ref: gnat_ugn/gnat_and_program_execution id58642164
! Ref: 1af642164
! Ref: gnat_ugn/gnat_and_program_execution the-gnat-debug-pool-facility642164
! Ref: 1b0642164
! Node: Platform-Specific Information647181
! Ref: gnat_ugn/platform_specific_information doc647325
! Ref: 1b1647325
! Ref: gnat_ugn/platform_specific_information id1647325
! Ref: 1b2647325
! Ref: gnat_ugn/platform_specific_information platform-specific-information647325
! Ref: d647325
! Node: Run-Time Libraries647724
! Ref: gnat_ugn/platform_specific_information id2647848
! Ref: 1b3647848
! Ref: gnat_ugn/platform_specific_information run-time-libraries647848
! Ref: 1b4647848
! Node: Summary of Run-Time Configurations649132
! Ref: gnat_ugn/platform_specific_information id3649223
! Ref: 1b5649223
! Ref: gnat_ugn/platform_specific_information summary-of-run-time-configurations649223
! Ref: 1b6649223
! Node: Specifying a Run-Time Library650536
! Ref: gnat_ugn/platform_specific_information id4650685
! Ref: 1b7650685
! Ref: gnat_ugn/platform_specific_information specifying-a-run-time-library650685
! Ref: 1b8650685
! Ref: gnat_ugn/platform_specific_information choosing-the-scheduling-policy652981
! Ref: 1b9652981
! Node: Choosing the Scheduling Policy653028
! Ref: gnat_ugn/platform_specific_information id5653126
! Ref: 1ba653126
! Node: GNU/Linux Topics654610
! Ref: gnat_ugn/platform_specific_information gnu-linux-topics654765
! Ref: 1bb654765
! Ref: gnat_ugn/platform_specific_information id6654765
! Ref: 1bc654765
! Node: Required Packages on GNU/Linux654954
! Ref: gnat_ugn/platform_specific_information id7655071
! Ref: 1bd655071
! Ref: gnat_ugn/platform_specific_information required-packages-on-gnu-linux655071
! Ref: 1be655071
! Node: A GNU/Linux Debug Quirk655821
! Ref: gnat_ugn/platform_specific_information a-gnu-linux-debug-quirk655938
! Ref: 1bf655938
! Ref: gnat_ugn/platform_specific_information id8655938
! Ref: 1c0655938
! Node: Microsoft Windows Topics656689
! Ref: gnat_ugn/platform_specific_information id9656828
! Ref: 1c1656828
! Ref: gnat_ugn/platform_specific_information microsoft-windows-topics656828
! Ref: 1c2656828
! Node: Using GNAT on Windows657249
! Ref: gnat_ugn/platform_specific_information id10657378
! Ref: 1c3657378
! Ref: gnat_ugn/platform_specific_information using-gnat-on-windows657378
! Ref: 1c4657378
! Node: Using a network installation of GNAT660197
! Ref: gnat_ugn/platform_specific_information id11660365
! Ref: 1c5660365
! Ref: gnat_ugn/platform_specific_information using-a-network-installation-of-gnat660365
! Ref: 1c6660365
! Node: CONSOLE and WINDOWS subsystems661266
! Ref: gnat_ugn/platform_specific_information console-and-windows-subsystems661428
! Ref: 1c7661428
! Ref: gnat_ugn/platform_specific_information id12661428
! Ref: 1c8661428
! Node: Temporary Files661941
! Ref: gnat_ugn/platform_specific_information id13662108
! Ref: 1c9662108
! Ref: gnat_ugn/platform_specific_information temporary-files662108
! Ref: 1ca662108
! Node: Disabling Command Line Argument Expansion662784
! Ref: gnat_ugn/platform_specific_information disabling-command-line-argument-expansion662944
! Ref: 1cb662944
! Node: Windows Socket Timeouts664566
! Ref: gnat_ugn/platform_specific_information windows-socket-timeouts664748
! Ref: 1cc664748
! Node: Mixed-Language Programming on Windows666974
! Ref: gnat_ugn/platform_specific_information id14667139
! Ref: 1cd667139
! Ref: gnat_ugn/platform_specific_information mixed-language-programming-on-windows667139
! Ref: 1ce667139
! Node: Windows Calling Conventions669686
! Ref: gnat_ugn/platform_specific_information id15669841
! Ref: 1d1669841
! Ref: gnat_ugn/platform_specific_information windows-calling-conventions669841
! Ref: 1d2669841
! Node: C Calling Convention670771
! Ref: gnat_ugn/platform_specific_information c-calling-convention670892
! Ref: 1d3670892
! Ref: gnat_ugn/platform_specific_information id16670892
! Ref: 1d4670892
! Node: Stdcall Calling Convention672372
! Ref: gnat_ugn/platform_specific_information id17672526
! Ref: 1d6672526
! Ref: gnat_ugn/platform_specific_information stdcall-calling-convention672526
! Ref: 1d5672526
! Node: Win32 Calling Convention675315
! Ref: gnat_ugn/platform_specific_information id18675471
! Ref: 1d7675471
! Ref: gnat_ugn/platform_specific_information win32-calling-convention675471
! Ref: 1d8675471
! Node: DLL Calling Convention675664
! Ref: gnat_ugn/platform_specific_information dll-calling-convention675785
! Ref: 1d9675785
! Ref: gnat_ugn/platform_specific_information id19675785
! Ref: 1da675785
! Node: Introduction to Dynamic Link Libraries DLLs675974
! Ref: gnat_ugn/platform_specific_information id20676158
! Ref: 1db676158
! Ref: gnat_ugn/platform_specific_information introduction-to-dynamic-link-libraries-dlls676158
! Ref: 1dc676158
! Node: Using DLLs with GNAT679555
! Ref: gnat_ugn/platform_specific_information id21679749
! Ref: 1de679749
! Ref: gnat_ugn/platform_specific_information using-dlls-with-gnat679749
! Ref: 1cf679749
! Node: Creating an Ada Spec for the DLL Services681739
! Ref: gnat_ugn/platform_specific_information creating-an-ada-spec-for-the-dll-services681874
! Ref: 1df681874
! Ref: gnat_ugn/platform_specific_information id22681874
! Ref: 1e0681874
! Node: Creating an Import Library682838
! Ref: gnat_ugn/platform_specific_information creating-an-import-library682973
! Ref: 1e1682973
! Ref: gnat_ugn/platform_specific_information id23682973
! Ref: 1e2682973
! Ref: gnat_ugn/platform_specific_information the-definition-file683399
! Ref: 1dd683399
! Ref: gnat_ugn/platform_specific_information create-def-file-automatically684696
! Ref: 1e3684696
! Ref: gnat_ugn/platform_specific_information gnat-style-import-library685850
! Ref: 1e4685850
! Ref: gnat_ugn/platform_specific_information msvs-style-import-library686780
! Ref: 1e6686780
! Node: Building DLLs with GNAT Project files687501
! Ref: gnat_ugn/platform_specific_information building-dlls-with-gnat-project-files687675
! Ref: 1d0687675
! Ref: gnat_ugn/platform_specific_information id24687675
! Ref: 1e7687675
! Node: Building DLLs with GNAT688174
! Ref: gnat_ugn/platform_specific_information building-dlls-with-gnat688354
! Ref: 1e8688354
! Ref: gnat_ugn/platform_specific_information id25688354
! Ref: 1e9688354
! Node: Building DLLs with gnatdll690262
! Ref: gnat_ugn/platform_specific_information building-dlls-with-gnatdll690430
! Ref: 1ea690430
! Ref: gnat_ugn/platform_specific_information id26690430
! Ref: 1eb690430
! Node: Limitations When Using Ada DLLs from Ada692915
! Ref: gnat_ugn/platform_specific_information limitations-when-using-ada-dlls-from-ada693051
! Ref: 1ef693051
! Node: Exporting Ada Entities693962
! Ref: gnat_ugn/platform_specific_information exporting-ada-entities694131
! Ref: 1ec694131
! Ref: gnat_ugn/platform_specific_information id27694131
! Ref: 1f0694131
! Node: Ada DLLs and Elaboration697020
! Ref: gnat_ugn/platform_specific_information ada-dlls-and-elaboration697140
! Ref: 1ed697140
! Ref: gnat_ugn/platform_specific_information id28697140
! Ref: 1f2697140
! Node: Ada DLLs and Finalization698578
! Ref: gnat_ugn/platform_specific_information ada-dlls-and-finalization698751
! Ref: 1ee698751
! Ref: gnat_ugn/platform_specific_information id29698751
! Ref: 1f3698751
! Node: Creating a Spec for Ada DLLs699422
! Ref: gnat_ugn/platform_specific_information creating-a-spec-for-ada-dlls699595
! Ref: 1f4699595
! Ref: gnat_ugn/platform_specific_information id30699595
! Ref: 1f5699595
! Node: Creating the Definition File701004
! Ref: gnat_ugn/platform_specific_information creating-the-definition-file701121
! Ref: 1f1701121
! Ref: gnat_ugn/platform_specific_information id31701121
! Ref: 1f6701121
! Node: Using gnatdll701879
! Ref: gnat_ugn/platform_specific_information id32701996
! Ref: 1f7701996
! Ref: gnat_ugn/platform_specific_information using-gnatdll701996
! Ref: 1e5701996
! Ref: gnat_ugn/platform_specific_information using-dlltool708532
! Ref: 1f8708532
! Node: GNAT and Windows Resources709899
! Ref: gnat_ugn/platform_specific_information gnat-and-windows-resources710104
! Ref: 1f9710104
! Ref: gnat_ugn/platform_specific_information id33710104
! Ref: 1fa710104
! Node: Building Resources712000
! Ref: gnat_ugn/platform_specific_information building-resources712111
! Ref: 1fb712111
! Ref: gnat_ugn/platform_specific_information id34712111
! Ref: 1fc712111
! Node: Compiling Resources712689
! Ref: gnat_ugn/platform_specific_information compiling-resources712824
! Ref: 1fd712824
! Ref: gnat_ugn/platform_specific_information id35712824
! Ref: 1fe712824
! Node: Using Resources713764
! Ref: gnat_ugn/platform_specific_information id36713872
! Ref: 1ff713872
! Ref: gnat_ugn/platform_specific_information using-resources713872
! Ref: 200713872
! Node: Using GNAT DLLs from Microsoft Visual Studio Applications714166
! Ref: gnat_ugn/platform_specific_information using-gnat-dll-from-msvs714358
! Ref: 201714358
! Ref: gnat_ugn/platform_specific_information using-gnat-dlls-from-microsoft-visual-studio-applications714358
! Ref: 202714358
! Node: Debugging a DLL715920
! Ref: gnat_ugn/platform_specific_information debugging-a-dll716118
! Ref: 203716118
! Ref: gnat_ugn/platform_specific_information id37716118
! Ref: 204716118
! Node: Program and DLL Both Built with GCC/GNAT716982
! Ref: gnat_ugn/platform_specific_information id38717145
! Ref: 205717145
! Ref: gnat_ugn/platform_specific_information program-and-dll-both-built-with-gcc-gnat717145
! Ref: 206717145
! Node: Program Built with Foreign Tools and DLL Built with GCC/GNAT718474
! Ref: gnat_ugn/platform_specific_information id39718637
! Ref: 207718637
! Ref: gnat_ugn/platform_specific_information program-built-with-foreign-tools-and-dll-built-with-gcc-gnat718637
! Ref: 208718637
! Node: Setting Stack Size from gnatlink722039
! Ref: gnat_ugn/platform_specific_information id40722211
! Ref: 209722211
! Ref: gnat_ugn/platform_specific_information setting-stack-size-from-gnatlink722211
! Ref: 127722211
! Node: Setting Heap Size from gnatlink723424
! Ref: gnat_ugn/platform_specific_information id41723572
! Ref: 20a723572
! Ref: gnat_ugn/platform_specific_information setting-heap-size-from-gnatlink723572
! Ref: 128723572
! Node: Windows Specific Add-Ons724259
! Ref: gnat_ugn/platform_specific_information win32-specific-addons724392
! Ref: 20b724392
! Ref: gnat_ugn/platform_specific_information windows-specific-add-ons724392
! Ref: 20c724392
! Node: Win32Ada724543
! Ref: gnat_ugn/platform_specific_information id42724629
! Ref: 20d724629
! Ref: gnat_ugn/platform_specific_information win32ada724629
! Ref: 20e724629
! Node: wPOSIX725226
! Ref: gnat_ugn/platform_specific_information id43725312
! Ref: 20f725312
! Ref: gnat_ugn/platform_specific_information wposix725312
! Ref: 210725312
! Node: Mac OS Topics725996
! Ref: gnat_ugn/platform_specific_information id44726110
! Ref: 211726110
! Ref: gnat_ugn/platform_specific_information mac-os-topics726110
! Ref: 212726110
! Node: Codesigning the Debugger726263
! Ref: gnat_ugn/platform_specific_information codesigning-the-debugger726339
! Ref: 213726339
! Node: Example of Binder Output File728322
! Ref: gnat_ugn/example_of_binder_output doc728474
! Ref: 214728474
! Ref: gnat_ugn/example_of_binder_output example-of-binder-output-file728474
! Ref: e728474
! Ref: gnat_ugn/example_of_binder_output id1728474
! Ref: 215728474
! Node: Elaboration Order Handling in GNAT759557
! Ref: gnat_ugn/elaboration_order_handling_in_gnat doc759696
! Ref: 216759696
! Ref: gnat_ugn/elaboration_order_handling_in_gnat elaboration-order-handling-in-gnat759696
! Ref: f759696
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id1759696
! Ref: 217759696
! Node: Elaboration Code760450
! Ref: gnat_ugn/elaboration_order_handling_in_gnat elaboration-code760565
! Ref: 218760565
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id2760565
! Ref: 219760565
! Node: Elaboration Order764398
! Ref: gnat_ugn/elaboration_order_handling_in_gnat elaboration-order764552
! Ref: 21a764552
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id3764552
! Ref: 21b764552
! Node: Checking the Elaboration Order768194
! Ref: gnat_ugn/elaboration_order_handling_in_gnat checking-the-elaboration-order768372
! Ref: 21c768372
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id4768372
! Ref: 21d768372
! Node: Controlling the Elaboration Order in Ada770048
! Ref: gnat_ugn/elaboration_order_handling_in_gnat controlling-the-elaboration-order-in-ada770250
! Ref: 21e770250
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id5770250
! Ref: 21f770250
! Node: Controlling the Elaboration Order in GNAT778812
! Ref: gnat_ugn/elaboration_order_handling_in_gnat controlling-the-elaboration-order-in-gnat779009
! Ref: 220779009
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id6779009
! Ref: 221779009
! Node: Mixing Elaboration Models782840
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id7783012
! Ref: 222783012
! Ref: gnat_ugn/elaboration_order_handling_in_gnat mixing-elaboration-models783012
! Ref: 223783012
! Node: ABE Diagnostics784025
! Ref: gnat_ugn/elaboration_order_handling_in_gnat abe-diagnostics784173
! Ref: 224784173
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id8784173
! Ref: 225784173
! Node: SPARK Diagnostics787691
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id9787839
! Ref: 226787839
! Ref: gnat_ugn/elaboration_order_handling_in_gnat spark-diagnostics787839
! Ref: 227787839
! Node: Elaboration Circularities788610
! Ref: gnat_ugn/elaboration_order_handling_in_gnat elaboration-circularities788778
! Ref: 228788778
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id10788778
! Ref: 229788778
! Node: Resolving Elaboration Circularities791025
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id11791213
! Ref: 22a791213
! Ref: gnat_ugn/elaboration_order_handling_in_gnat resolving-elaboration-circularities791213
! Ref: 22b791213
! Node: Elaboration-related Compiler Switches798738
! Ref: gnat_ugn/elaboration_order_handling_in_gnat elaboration-related-compiler-switches798946
! Ref: 22c798946
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id12798946
! Ref: 22d798946
! Node: Summary of Procedures for Elaboration Control803775
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id13803987
! Ref: 22e803987
! Ref: gnat_ugn/elaboration_order_handling_in_gnat summary-of-procedures-for-elaboration-control803987
! Ref: 22f803987
! Node: Inspecting the Chosen Elaboration Order805838
! Ref: gnat_ugn/elaboration_order_handling_in_gnat id14806004
! Ref: 230806004
! Ref: gnat_ugn/elaboration_order_handling_in_gnat inspecting-the-chosen-elaboration-order806004
! Ref: 231806004
! Node: Inline Assembler810619
! Ref: gnat_ugn/inline_assembler doc810759
! Ref: 232810759
! Ref: gnat_ugn/inline_assembler id1810759
! Ref: 233810759
! Ref: gnat_ugn/inline_assembler inline-assembler810759
! Ref: 10810759
! Node: Basic Assembler Syntax812302
! Ref: gnat_ugn/inline_assembler basic-assembler-syntax812424
! Ref: 234812424
! Ref: gnat_ugn/inline_assembler id2812424
! Ref: 235812424
! Node: A Simple Example of Inline Assembler814410
! Ref: gnat_ugn/inline_assembler a-simple-example-of-inline-assembler814577
! Ref: 236814577
! Ref: gnat_ugn/inline_assembler id3814577
! Ref: 237814577
! Node: Output Variables in Inline Assembler817882
! Ref: gnat_ugn/inline_assembler id4818062
! Ref: 238818062
! Ref: gnat_ugn/inline_assembler output-variables-in-inline-assembler818062
! Ref: 239818062
! Node: Input Variables in Inline Assembler826146
! Ref: gnat_ugn/inline_assembler id5826320
! Ref: 23a826320
! Ref: gnat_ugn/inline_assembler input-variables-in-inline-assembler826320
! Ref: 23b826320
! Node: Inlining Inline Assembler Code828708
! Ref: gnat_ugn/inline_assembler id6828869
! Ref: 23c828869
! Ref: gnat_ugn/inline_assembler inlining-inline-assembler-code828869
! Ref: 23d828869
! Node: Other Asm Functionality830768
! Ref: gnat_ugn/inline_assembler id7830885
! Ref: 23e830885
! Ref: gnat_ugn/inline_assembler other-asm-functionality830885
! Ref: 23f830885
! Node: The Clobber Parameter831199
! Ref: gnat_ugn/inline_assembler id8831313
! Ref: 240831313
! Ref: gnat_ugn/inline_assembler the-clobber-parameter831313
! Ref: 241831313
! Node: The Volatile Parameter833284
! Ref: gnat_ugn/inline_assembler id9833398
! Ref: 242833398
! Ref: gnat_ugn/inline_assembler the-volatile-parameter833398
! Ref: 243833398
! Node: GNU Free Documentation License834554
! Ref: share/gnu_free_documentation_license doc834665
! Ref: 244834665
! Ref: share/gnu_free_documentation_license gnu-fdl834665
! Ref: 1834665
! Ref: share/gnu_free_documentation_license gnu-free-documentation-license834665
! Ref: 245834665
! Node: Index858007
! Ref: gnat_ugn/gnat_utility_programs switches-related-to-project-files997595
! Ref: cf997596
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/doc/gpl.7 gcc-13.5.0-RC-20260904/gcc/doc/gpl.7
*** gcc-13.4.0/gcc/doc/gpl.7	Thu Jun  5 16:06:29 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/gpl.7	Fri Sep  4 07:36:30 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,148 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "GPL 7"
! .TH GPL 7 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  gpl \- GNU General Public License
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
! .SS "\s-1GNU\s0 General Public License"
  .IX Subsection "GNU General Public License"
  .SS "Version 3, 29 June 2007"
  .IX Subsection "Version 3, 29 June 2007"
--- 53,73 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "GPL 7"
! .TH GPL 7 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  gpl \- GNU General Public License
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
! .SS "GNU General Public License"
  .IX Subsection "GNU General Public License"
  .SS "Version 3, 29 June 2007"
  .IX Subsection "Version 3, 29 June 2007"
*************** gpl \- GNU General Public License
*** 152,168 ****
  \&        Everyone is permitted to copy and distribute verbatim copies of this
  \&        license document, but changing it is not allowed.
  .Ve
! .SS "Preamble"
  .IX Subsection "Preamble"
! The \s-1GNU\s0 General Public License is a free, copyleft license for
  software and other kinds of works.
  .PP
  The licenses for most software and other practical works are designed
  to take away your freedom to share and change the works.  By contrast,
! the \s-1GNU\s0 General Public License is intended to guarantee your freedom
! to share and change all versions of a program\*(--to make sure it remains
  free software for all its users.  We, the Free Software Foundation,
! use the \s-1GNU\s0 General Public License for most of our software; it
  applies also to any other work released this way by its authors.  You
  can apply it to your programs, too.
  .PP
--- 77,93 ----
  \&        Everyone is permitted to copy and distribute verbatim copies of this
  \&        license document, but changing it is not allowed.
  .Ve
! .SS Preamble
  .IX Subsection "Preamble"
! The GNU General Public License is a free, copyleft license for
  software and other kinds of works.
  .PP
  The licenses for most software and other practical works are designed
  to take away your freedom to share and change the works.  By contrast,
! the 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.
  .PP
*************** freedoms that you received.  You must ma
*** 185,255 ****
  receive or can get the source code.  And you must show them these
  terms so they know their rights.
  .PP
! Developers that use the \s-1GNU GPL\s0 protect your rights with two steps:
  (1) assert copyright on the software, and (2) offer you this License
  giving you legal permission to copy, distribute and/or modify it.
  .PP
! For the developers' and authors' protection, the \s-1GPL\s0 clearly explains
! that there is no warranty for this free software.  For both users' and
! authors' sake, the \s-1GPL\s0 requires that modified versions be marked as
  changed, so that their problems will not be attributed erroneously to
  authors of previous versions.
  .PP
  Some devices are designed to deny users access to install or run
  modified versions of the software inside them, although the
  manufacturer can do so.  This is fundamentally incompatible with the
! aim of protecting users' freedom to change the software.  The
  systematic pattern of such abuse occurs in the area of products for
  individuals to use, which is precisely where it is most unacceptable.
! Therefore, we have designed this version of the \s-1GPL\s0 to prohibit the
  practice for those products.  If such problems arise substantially in
  other domains, we stand ready to extend this provision to those
! domains in future versions of the \s-1GPL,\s0 as needed to protect the
  freedom of users.
  .PP
  Finally, every program is threatened constantly by software patents.
  States should not allow patents to restrict development and use of
! software on general-purpose computers, but in those that do, we wish
  to avoid the special danger that patents applied to a free program
! could make it effectively proprietary.  To prevent this, the \s-1GPL\s0
! assures that patents cannot be used to render the program non-free.
  .PP
  The precise terms and conditions for copying, distribution and
  modification follow.
! .SS "\s-1TERMS AND CONDITIONS\s0"
  .IX Subsection "TERMS AND CONDITIONS"
  .IP "0. Definitions." 4
  .IX Item "0. Definitions."
! \&\*(L"This License\*(R" refers to version 3 of the \s-1GNU\s0 General Public License.
  .Sp
! \&\*(L"Copyright\*(R" also means copyright-like laws that apply to other kinds
  of works, such as semiconductor masks.
  .Sp
! \&\*(L"The Program\*(R" refers to any copyrightable work licensed under this
! License.  Each licensee is addressed as \*(L"you\*(R".  \*(L"Licensees\*(R" and
! \&\*(L"recipients\*(R" may be individuals or organizations.
  .Sp
! To \*(L"modify\*(R" a work means to copy from or adapt all or part of the work
  in a fashion requiring copyright permission, other than the making of
! an exact copy.  The resulting work is called a \*(L"modified version\*(R" of
! the earlier work or a work \*(L"based on\*(R" the earlier work.
  .Sp
! A \*(L"covered work\*(R" means either the unmodified Program or a work based
  on the Program.
  .Sp
! To \*(L"propagate\*(R" a work means to do anything with it that, without
  permission, would make you directly or secondarily liable for
  infringement under applicable copyright law, except executing it on a
  computer or modifying a private copy.  Propagation includes copying,
  distribution (with or without modification), making available to the
  public, and in some countries other activities as well.
  .Sp
! To \*(L"convey\*(R" a work means any kind of propagation that enables other
  parties to make or receive copies.  Mere interaction with a user
  through a computer network, with no transfer of a copy, is not
  conveying.
  .Sp
! An interactive user interface displays \*(L"Appropriate Legal Notices\*(R" to
  the extent that it includes a convenient and prominently visible
  feature that (1) displays an appropriate copyright notice, and (2)
  tells the user that there is no warranty for the work (except to the
--- 110,180 ----
  receive or can get the source code.  And you must show them these
  terms so they know their rights.
  .PP
! 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.
  .PP
! For the developers\*(Aq and authors\*(Aq protection, the GPL clearly explains
! that there is no warranty for this free software.  For both users\*(Aq and
! authors\*(Aq 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.
  .PP
  Some devices are designed to deny users access to install or run
  modified versions of the software inside them, although the
  manufacturer can do so.  This is fundamentally incompatible with the
! aim of protecting users\*(Aq 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.
  .PP
  Finally, every program is threatened constantly by software patents.
  States should not allow patents to restrict development and use of
! software on general\-purpose computers, but in those that do, we wish
  to avoid the special danger that patents applied to a free program
! could make it effectively proprietary.  To prevent this, the GPL
! assures that patents cannot be used to render the program non\-free.
  .PP
  The precise terms and conditions for copying, distribution and
  modification follow.
! .SS "TERMS AND CONDITIONS"
  .IX Subsection "TERMS AND CONDITIONS"
  .IP "0. Definitions." 4
  .IX Item "0. Definitions."
! "This License" refers to version 3 of the GNU General Public License.
  .Sp
! "Copyright" also means copyright\-like laws that apply to other kinds
  of works, such as semiconductor masks.
  .Sp
! "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.
  .Sp
! 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.
  .Sp
! A "covered work" means either the unmodified Program or a work based
  on the Program.
  .Sp
! 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.
  .Sp
! 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.
  .Sp
! 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
*************** the interface presents a list of user co
*** 259,289 ****
  menu, a prominent item in the list meets this criterion.
  .IP "1. Source Code." 4
  .IX Item "1. Source Code."
! The \*(L"source code\*(R" for a work means the preferred form of the work for
! making modifications to it.  \*(L"Object code\*(R" means any non-source form
  of a work.
  .Sp
! A \*(L"Standard Interface\*(R" means an interface that either is an official
  standard defined by a recognized standards body, or, in the case of
  interfaces specified for a particular programming language, one that
  is widely used among developers working in that language.
  .Sp
! The \*(L"System Libraries\*(R" of an executable work include anything, other
  than the work as a whole, that (a) is included in the normal form of
  packaging a Major Component, but which is not part of that Major
  Component, and (b) serves only to enable use of the work with that
  Major Component, or to implement a Standard Interface for which an
  implementation is available to the public in source code form.  A
! \&\*(L"Major Component\*(R", in this context, means a major essential component
  (kernel, window system, and so on) of the specific operating system
  (if any) on which the executable work runs, or a compiler used to
  produce the work, or an object code interpreter used to run it.
  .Sp
! The \*(L"Corresponding Source\*(R" for a work in object code form means all
  the source code needed to generate, install, and (for an executable
  work) run the object code and to modify the work, including scripts to
! control those activities.  However, it does not include the work's
! System Libraries, or general-purpose tools or generally available free
  programs which are used unmodified in performing those activities but
  which are not part of the work.  For example, Corresponding Source
  includes interface definition files associated with source files for
--- 184,214 ----
  menu, a prominent item in the list meets this criterion.
  .IP "1. Source Code." 4
  .IX Item "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.
  .Sp
! 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.
  .Sp
! 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.
  .Sp
! 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\*(Aqs
! 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
*************** copyrighted material outside their relat
*** 321,331 ****
  Conveying under any other circumstances is permitted solely under the
  conditions stated below.  Sublicensing is not allowed; section 10
  makes it unnecessary.
! .IP "3. Protecting Users' Legal Rights From Anti-Circumvention Law." 4
  .IX Item "3. Protecting Users' Legal Rights From Anti-Circumvention Law."
  No covered work shall be deemed part of an effective technological
  measure under any applicable law fulfilling obligations under article
! 11 of the \s-1WIPO\s0 copyright treaty adopted on 20 December 1996, or
  similar laws prohibiting or restricting circumvention of such
  measures.
  .Sp
--- 246,256 ----
  Conveying under any other circumstances is permitted solely under the
  conditions stated below.  Sublicensing is not allowed; section 10
  makes it unnecessary.
! .IP "3. Protecting Users\*(Aq Legal Rights From Anti\-Circumvention Law." 4
  .IX Item "3. Protecting Users' Legal Rights From Anti-Circumvention Law."
  No covered work shall be deemed part of an effective technological
  measure under any applicable law fulfilling obligations under article
! 11 of the WIPO copyright treaty adopted on 20 December 1996, or
  similar laws prohibiting or restricting circumvention of such
  measures.
  .Sp
*************** circumvention of technological measures
*** 334,348 ****
  circumvention is effected by exercising rights under this License with
  respect to the covered work, and you disclaim any intention to limit
  operation or modification of the work as a means of enforcing, against
! the work's users, your or third parties' legal rights to forbid
  circumvention of technological measures.
  .IP "4. Conveying Verbatim Copies." 4
  .IX Item "4. Conveying Verbatim Copies."
! You may convey verbatim copies of the Program's source code as you
  receive it, in any medium, provided that you conspicuously and
  appropriately publish on each copy an appropriate copyright notice;
  keep intact all notices stating that this License and any
! non-permissive terms added in accord with section 7 apply to the code;
  keep intact all notices of the absence of any warranty; and give all
  recipients a copy of this License along with the Program.
  .Sp
--- 259,273 ----
  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\*(Aqs users, your or third parties\*(Aq legal rights to forbid
  circumvention of technological measures.
  .IP "4. Conveying Verbatim Copies." 4
  .IX Item "4. Conveying Verbatim Copies."
! You may convey verbatim copies of the Program\*(Aqs source code as you
  receive it, in any medium, provided that you conspicuously and
  appropriately publish on each copy an appropriate copyright notice;
  keep intact all notices stating that this License and any
! non\-permissive terms added in accord with section 7 apply to the code;
  keep intact all notices of the absence of any warranty; and give all
  recipients a copy of this License along with the Program.
  .Sp
*************** produce it from the Program, in the form
*** 355,371 ****
  terms of section 4, provided that you also meet all of these
  conditions:
  .RS 4
! .IP "a." 4
  .IX Item "a."
  The work must carry prominent notices stating that you modified it,
  and giving a relevant date.
! .IP "b." 4
  .IX Item "b."
  The work must carry prominent notices stating that it is released
  under this License and any conditions added under section 7.  This
! requirement modifies the requirement in section 4 to \*(L"keep intact all
! notices\*(R".
! .IP "c." 4
  .IX Item "c."
  You must license the entire work, as a whole, under this License to
  anyone who comes into possession of a copy.  This License will
--- 280,296 ----
  terms of section 4, provided that you also meet all of these
  conditions:
  .RS 4
! .IP a. 4
  .IX Item "a."
  The work must carry prominent notices stating that you modified it,
  and giving a relevant date.
! .IP b. 4
  .IX Item "b."
  The work must carry prominent notices stating that it is released
  under this License and any conditions added under section 7.  This
! requirement modifies the requirement in section 4 to "keep intact all
! notices".
! .IP c. 4
  .IX Item "c."
  You must license the entire work, as a whole, under this License to
  anyone who comes into possession of a copy.  This License will
*************** to the whole of the work, and all its pa
*** 374,380 ****
  are packaged.  This License gives no permission to license the work in
  any other way, but it does not invalidate such permission if you have
  separately received it.
! .IP "d." 4
  .IX Item "d."
  If the work has interactive user interfaces, each must display
  Appropriate Legal Notices; however, if the Program has interactive
--- 299,305 ----
  are packaged.  This License gives no permission to license the work in
  any other way, but it does not invalidate such permission if you have
  separately received it.
! .IP d. 4
  .IX Item "d."
  If the work has interactive user interfaces, each must display
  Appropriate Legal Notices; however, if the Program has interactive
*************** A compilation of a covered work with oth
*** 387,412 ****
  works, which are not by their nature extensions of the covered work,
  and which are not combined with it such as to form a larger program,
  in or on a volume of a storage or distribution medium, is called an
! \&\*(L"aggregate\*(R" if the compilation and its resulting copyright are not
! used to limit the access or legal rights of the compilation's users
  beyond what the individual works permit.  Inclusion of a covered work
  in an aggregate does not cause this License to apply to the other
  parts of the aggregate.
  .RE
! .IP "6. Conveying Non-Source Forms." 4
  .IX Item "6. Conveying Non-Source Forms."
  You may convey a covered work in object code form under the terms of
! sections 4 and 5, provided that you also convey the machine-readable
  Corresponding Source under the terms of this License, in one of these
  ways:
  .RS 4
! .IP "a." 4
  .IX Item "a."
  Convey the object code in, or embodied in, a physical product
  (including a physical distribution medium), accompanied by the
  Corresponding Source fixed on a durable physical medium customarily
  used for software interchange.
! .IP "b." 4
  .IX Item "b."
  Convey the object code in, or embodied in, a physical product
  (including a physical distribution medium), accompanied by a written
--- 312,337 ----
  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\*(Aqs users
  beyond what the individual works permit.  Inclusion of a covered work
  in an aggregate does not cause this License to apply to the other
  parts of the aggregate.
  .RE
! .IP "6. Conveying Non\-Source Forms." 4
  .IX Item "6. Conveying Non-Source Forms."
  You may convey a covered work in object code form under the terms of
! sections 4 and 5, provided that you also convey the machine\-readable
  Corresponding Source under the terms of this License, in one of these
  ways:
  .RS 4
! .IP a. 4
  .IX Item "a."
  Convey the object code in, or embodied in, a physical product
  (including a physical distribution medium), accompanied by the
  Corresponding Source fixed on a durable physical medium customarily
  used for software interchange.
! .IP b. 4
  .IX Item "b."
  Convey the object code in, or embodied in, a physical product
  (including a physical distribution medium), accompanied by a written
*************** covered by this License, on a durable ph
*** 418,431 ****
  for software interchange, for a price no more than your reasonable
  cost of physically performing this conveying of source, or (2) access
  to copy the Corresponding Source from a network server at no charge.
! .IP "c." 4
  .IX Item "c."
  Convey individual copies of the object code with a copy of the written
  offer to provide the Corresponding Source.  This alternative is
  allowed only occasionally and noncommercially, and only if you
  received the object code with such an offer, in accord with subsection
  6b.
! .IP "d." 4
  .IX Item "d."
  Convey the object code by offering access from a designated place
  (gratis or for a charge), and offer equivalent access to the
--- 343,356 ----
  for software interchange, for a price no more than your reasonable
  cost of physically performing this conveying of source, or (2) access
  to copy the Corresponding Source from a network server at no charge.
! .IP c. 4
  .IX Item "c."
  Convey individual copies of the object code with a copy of the written
  offer to provide the Corresponding Source.  This alternative is
  allowed only occasionally and noncommercially, and only if you
  received the object code with such an offer, in accord with subsection
  6b.
! .IP d. 4
  .IX Item "d."
  Convey the object code by offering access from a designated place
  (gratis or for a charge), and offer equivalent access to the
*************** next to the object code saying where to
*** 439,447 ****
  Regardless of what server hosts the Corresponding Source, you remain
  obligated to ensure that it is available for as long as needed to
  satisfy these requirements.
! .IP "e." 4
  .IX Item "e."
! Convey the object code using peer-to-peer transmission, provided you
  inform other peers where the object code and Corresponding Source of
  the work are being offered to the general public at no charge under
  subsection 6d.
--- 364,372 ----
  Regardless of what server hosts the Corresponding Source, you remain
  obligated to ensure that it is available for as long as needed to
  satisfy these requirements.
! .IP e. 4
  .IX Item "e."
! Convey the object code using peer\-to\-peer transmission, provided you
  inform other peers where the object code and Corresponding Source of
  the work are being offered to the general public at no charge under
  subsection 6d.
*************** A separable portion of the object code,
*** 452,472 ****
  from the Corresponding Source as a System Library, need not be
  included in conveying the object code work.
  .Sp
! A \*(L"User Product\*(R" is either (1) a \*(L"consumer product\*(R", which means any
  tangible personal property which is normally used for personal,
  family, or household purposes, or (2) anything designed or sold for
  incorporation into a dwelling.  In determining whether a product is a
  consumer product, doubtful cases shall be resolved in favor of
  coverage.  For a particular product received by a particular user,
! \&\*(L"normally used\*(R" refers to a typical or common use of that class of
  product, regardless of the status of the particular user or of the way
  in which the particular user actually uses, or expects or is expected
  to use, the product.  A product is a consumer product regardless of
  whether the product has substantial commercial, industrial or
! non-consumer uses, unless such uses represent the only significant
  mode of use of the product.
  .Sp
! \&\*(L"Installation Information\*(R" for a User Product means any methods,
  procedures, authorization keys, or other information required to
  install and execute modified versions of a covered work in that User
  Product from a modified version of its Corresponding Source.  The
--- 377,397 ----
  from the Corresponding Source as a System Library, need not be
  included in conveying the object code work.
  .Sp
! 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.
  .Sp
! "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
*************** Corresponding Source conveyed under this
*** 483,489 ****
  by the Installation Information.  But this requirement does not apply
  if neither you nor any third party retains the ability to install
  modified object code on the User Product (for example, the work has
! been installed in \s-1ROM\s0).
  .Sp
  The requirement to provide Installation Information does not include a
  requirement to continue to provide support service, warranty, or
--- 408,414 ----
  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).
  .Sp
  The requirement to provide Installation Information does not include a
  requirement to continue to provide support service, warranty, or
*************** unpacking, reading or copying.
*** 502,508 ****
  .RE
  .IP "7. Additional Terms." 4
  .IX Item "7. Additional Terms."
! \&\*(L"Additional permissions\*(R" are terms that supplement the terms of this
  License by making exceptions from one or more of its conditions.
  Additional permissions that are applicable to the entire Program shall
  be treated as though they were included in this License, to the extent
--- 427,433 ----
  .RE
  .IP "7. Additional Terms." 4
  .IX Item "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
*************** Notwithstanding any other provision of t
*** 522,550 ****
  add to a covered work, you may (if authorized by the copyright holders
  of that material) supplement the terms of this License with terms:
  .RS 4
! .IP "a." 4
  .IX Item "a."
  Disclaiming warranty or limiting liability differently from the terms
  of sections 15 and 16 of this License; or
! .IP "b." 4
  .IX Item "b."
  Requiring preservation of specified reasonable legal notices or author
  attributions in that material or in the Appropriate Legal Notices
  displayed by works containing it; or
! .IP "c." 4
  .IX Item "c."
  Prohibiting misrepresentation of the origin of that material, or
  requiring that modified versions of such material be marked in
  reasonable ways as different from the original version; or
! .IP "d." 4
  .IX Item "d."
  Limiting the use for publicity purposes of names of licensors or
  authors of the material; or
! .IP "e." 4
  .IX Item "e."
  Declining to grant rights under trademark law for use of some trade
  names, trademarks, or service marks; or
! .IP "f." 4
  .IX Item "f."
  Requiring indemnification of licensors and authors of that material by
  anyone who conveys the material (or modified versions of it) with
--- 447,475 ----
  add to a covered work, you may (if authorized by the copyright holders
  of that material) supplement the terms of this License with terms:
  .RS 4
! .IP a. 4
  .IX Item "a."
  Disclaiming warranty or limiting liability differently from the terms
  of sections 15 and 16 of this License; or
! .IP b. 4
  .IX Item "b."
  Requiring preservation of specified reasonable legal notices or author
  attributions in that material or in the Appropriate Legal Notices
  displayed by works containing it; or
! .IP c. 4
  .IX Item "c."
  Prohibiting misrepresentation of the origin of that material, or
  requiring that modified versions of such material be marked in
  reasonable ways as different from the original version; or
! .IP d. 4
  .IX Item "d."
  Limiting the use for publicity purposes of names of licensors or
  authors of the material; or
! .IP e. 4
  .IX Item "e."
  Declining to grant rights under trademark law for use of some trade
  names, trademarks, or service marks; or
! .IP f. 4
  .IX Item "f."
  Requiring indemnification of licensors and authors of that material by
  anyone who conveys the material (or modified versions of it) with
*************** licensors and authors.
*** 554,561 ****
  .RE
  .RS 4
  .Sp
! All other non-permissive additional terms are considered \*(L"further
! restrictions\*(R" within the meaning of section 10.  If the Program as you
  received it, or any part of it, contains a notice stating that it is
  governed by this License along with a term that is a further
  restriction, you may remove that term.  If a license document contains
--- 479,486 ----
  .RE
  .RS 4
  .Sp
! 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
*************** must place, in the relevant source files
*** 569,575 ****
  additional terms that apply to those files, or a notice indicating
  where to find the applicable terms.
  .Sp
! Additional terms, permissive or non-permissive, may be stated in the
  form of a separately written license, or stated as exceptions; the
  above requirements apply either way.
  .RE
--- 494,500 ----
  additional terms that apply to those files, or a notice indicating
  where to find the applicable terms.
  .Sp
! Additional terms, permissive or non\-permissive, may be stated in the
  form of a separately written license, or stated as exceptions; the
  above requirements apply either way.
  .RE
*************** material under section 10.
*** 604,610 ****
  .IX Item "9. Acceptance Not Required for Having Copies."
  You are not required to accept this License in order to receive or run
  a copy of the Program.  Ancillary propagation of a covered work
! occurring solely as a consequence of using peer-to-peer transmission
  to receive a copy likewise does not require acceptance.  However,
  nothing other than this License grants you permission to propagate or
  modify any covered work.  These actions infringe copyright if you do
--- 529,535 ----
  .IX Item "9. Acceptance Not Required for Having Copies."
  You are not required to accept this License in order to receive or run
  a copy of the Program.  Ancillary propagation of a covered work
! occurring solely as a consequence of using peer\-to\-peer transmission
  to receive a copy likewise does not require acceptance.  However,
  nothing other than this License grants you permission to propagate or
  modify any covered work.  These actions infringe copyright if you do
*************** receives a license from the original lic
*** 617,628 ****
  propagate that work, subject to this License.  You are not responsible
  for enforcing compliance by third parties with this License.
  .Sp
! An \*(L"entity transaction\*(R" is a transaction transferring control of an
  organization, or substantially all assets of one, or subdividing an
  organization, or merging organizations.  If propagation of a covered
  work results from an entity transaction, each party to that
  transaction who receives a copy of the work also receives whatever
! licenses to the work the party's predecessor in interest had or could
  give under the previous paragraph, plus a right to possession of the
  Corresponding Source of the work from the predecessor in interest, if
  the predecessor has it or can get it with reasonable efforts.
--- 542,553 ----
  propagate that work, subject to this License.  You are not responsible
  for enforcing compliance by third parties with this License.
  .Sp
! 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\*(Aqs 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 restricti
*** 631,664 ****
  rights granted or affirmed under this License.  For example, you may
  not impose a license fee, royalty, or other charge for exercise of
  rights granted under this License, and you may not initiate litigation
! (including a cross-claim or counterclaim in a lawsuit) alleging that
  any patent claim is infringed by making, using, selling, offering for
  sale, or importing the Program or any portion of it.
  .IP "11. Patents." 4
  .IX Item "11. Patents."
! A \*(L"contributor\*(R" is a copyright holder who authorizes use under this
  License of the Program or a work on which the Program is based.  The
! work thus licensed is called the contributor's \*(L"contributor version\*(R".
  .Sp
! A contributor's \*(L"essential patent claims\*(R" are all patent claims owned
  or controlled by the contributor, whether already acquired or
  hereafter acquired, that would be infringed by some manner, permitted
  by this License, of making, using, or selling its contributor version,
  but do not include claims that would be infringed only as a
  consequence of further modification of the contributor version.  For
! purposes of this definition, \*(L"control\*(R" includes the right to grant
  patent sublicenses in a manner consistent with the requirements of
  this License.
  .Sp
! Each contributor grants you a non-exclusive, worldwide, royalty-free
! patent license under the contributor's essential patent claims, to
  make, use, sell, offer for sale, import and otherwise run, modify and
  propagate the contents of its contributor version.
  .Sp
! In the following three paragraphs, a \*(L"patent license\*(R" is any express
  agreement or commitment, however denominated, not to enforce a patent
  (such as an express permission to practice a patent or covenant not to
! sue for patent infringement).  To \*(L"grant\*(R" such a patent license to a
  party means to make such an agreement or commitment not to enforce a
  patent against the party.
  .Sp
--- 556,589 ----
  rights granted or affirmed under this License.  For example, you may
  not impose a license fee, royalty, or other charge for exercise of
  rights granted under this License, and you may not initiate litigation
! (including a cross\-claim or counterclaim in a lawsuit) alleging that
  any patent claim is infringed by making, using, selling, offering for
  sale, or importing the Program or any portion of it.
  .IP "11. Patents." 4
  .IX Item "11. Patents."
! A "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\*(Aqs "contributor version".
  .Sp
! A contributor\*(Aqs "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.
  .Sp
! Each contributor grants you a non\-exclusive, worldwide, royalty\-free
! patent license under the contributor\*(Aqs essential patent claims, to
  make, use, sell, offer for sale, import and otherwise run, modify and
  propagate the contents of its contributor version.
  .Sp
! In the following three paragraphs, a "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.
  .Sp
*************** then you must either (1) cause the Corre
*** 670,678 ****
  available, or (2) arrange to deprive yourself of the benefit of the
  patent license for this particular work, or (3) arrange, in a manner
  consistent with the requirements of this License, to extend the patent
! license to downstream recipients.  \*(L"Knowingly relying\*(R" means you have
  actual knowledge that, but for the patent license, your conveying the
! covered work in a country, or your recipient's use of the covered work
  in a country, would infringe one or more identifiable patents in that
  country that you have reason to believe are valid.
  .Sp
--- 595,603 ----
  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\*(Aqs use of the covered work
  in a country, would infringe one or more identifiable patents in that
  country that you have reason to believe are valid.
  .Sp
*************** or convey a specific copy of the covered
*** 684,692 ****
  you grant is automatically extended to all recipients of the covered
  work and works based on it.
  .Sp
! A patent license is \*(L"discriminatory\*(R" if it does not include within the
  scope of its coverage, prohibits the exercise of, or is conditioned on
! the non-exercise of one or more of the rights that are specifically
  granted under this License.  You may not convey a covered work if you
  are a party to an arrangement with a third party that is in the
  business of distributing software, under which you make payment to the
--- 609,617 ----
  you grant is automatically extended to all recipients of the covered
  work and works based on it.
  .Sp
! 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
*************** license was granted, prior to 28 March 2
*** 702,708 ****
  Nothing in this License shall be construed as excluding or limiting
  any implied license or other defenses to infringement that may
  otherwise be available to you under applicable patent law.
! .IP "12. No Surrender of Others' Freedom." 4
  .IX Item "12. No Surrender of Others' Freedom."
  If conditions are imposed on you (whether by court order, agreement or
  otherwise) that contradict the conditions of this License, they do not
--- 627,633 ----
  Nothing in this License shall be construed as excluding or limiting
  any implied license or other defenses to infringement that may
  otherwise be available to you under applicable patent law.
! .IP "12. No Surrender of Others\*(Aq Freedom." 4
  .IX Item "12. No Surrender of Others' Freedom."
  If conditions are imposed on you (whether by court order, agreement or
  otherwise) that contradict the conditions of this License, they do not
*************** to terms that obligate you to collect a
*** 714,747 ****
  from those to whom you convey the Program, the only way you could
  satisfy both those terms and this License would be to refrain entirely
  from conveying the Program.
! .IP "13. Use with the \s-1GNU\s0 Affero General Public License." 4
  .IX Item "13. Use with the GNU Affero General Public License."
  Notwithstanding any other provision of this License, you have
  permission to link or combine any covered work with a work licensed
! under version 3 of the \s-1GNU\s0 Affero General Public License into a single
  combined work, and to convey the resulting work.  The terms of this
  License will continue to apply to the part which is the covered work,
! but the special requirements of the \s-1GNU\s0 Affero General Public License,
  section 13, concerning interaction through a network will apply to the
  combination as such.
  .IP "14. Revised Versions of this License." 4
  .IX Item "14. Revised Versions of this License."
  The Free Software Foundation may publish revised and/or new versions
! of the \s-1GNU\s0 General Public License from time to time.  Such new
  versions will be similar in spirit to the present version, but may
  differ in detail to address new problems or concerns.
  .Sp
  Each version is given a distinguishing version number.  If the Program
! specifies that a certain numbered version of the \s-1GNU\s0 General Public
! License \*(L"or any later version\*(R" applies to it, you have the option of
  following the terms and conditions either of that numbered version or
  of any later version published by the Free Software Foundation.  If
! the Program does not specify a version number of the \s-1GNU\s0 General
  Public License, you may choose any version ever published by the Free
  Software Foundation.
  .Sp
  If the Program specifies that a proxy can decide which future versions
! of the \s-1GNU\s0 General Public License can be used, that proxy's public
  statement of acceptance of a version permanently authorizes you to
  choose that version for the Program.
  .Sp
--- 639,672 ----
  from those to whom you convey the Program, the only way you could
  satisfy both those terms and this License would be to refrain entirely
  from conveying the Program.
! .IP "13. Use with the GNU Affero General Public License." 4
  .IX Item "13. Use with the GNU Affero General Public License."
  Notwithstanding any other provision of this License, you have
  permission to link or combine any covered work with a work licensed
! under version 3 of the 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.
  .IP "14. Revised Versions of this License." 4
  .IX Item "14. Revised Versions of this License."
  The Free Software Foundation may publish revised and/or new versions
! of the 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.
  .Sp
  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.
  .Sp
  If the Program specifies that a proxy can decide which future versions
! of the GNU General Public License can be used, that proxy\*(Aqs public
  statement of acceptance of a version permanently authorizes you to
  choose that version for the Program.
  .Sp
*************** author or copyright holder as a result o
*** 751,776 ****
  later version.
  .IP "15. Disclaimer of Warranty." 4
  .IX Item "15. Disclaimer of Warranty."
! \&\s-1THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
! APPLICABLE LAW.\s0  \s-1EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
! HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM \*(L"AS IS\*(R" WITHOUT
  WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
! A PARTICULAR PURPOSE.\s0  \s-1THE ENTIRE RISK AS TO THE QUALITY AND
! PERFORMANCE OF THE PROGRAM IS WITH YOU.\s0  \s-1SHOULD THE PROGRAM PROVE
  DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
! CORRECTION.\s0
  .IP "16. Limitation of Liability." 4
  .IX Item "16. Limitation of Liability."
! \&\s-1IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
  WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR
  CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
  INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
! ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM\s0 (\s-1INCLUDING BUT
  NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR
  LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM
! TO OPERATE WITH ANY OTHER PROGRAMS\s0), \s-1EVEN IF SUCH HOLDER OR OTHER
! PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.\s0
  .IP "17. Interpretation of Sections 15 and 16." 4
  .IX Item "17. Interpretation of Sections 15 and 16."
  If the disclaimer of warranty and limitation of liability provided
--- 676,701 ----
  later version.
  .IP "15. Disclaimer of Warranty." 4
  .IX Item "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.
  .IP "16. Limitation of Liability." 4
  .IX Item "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.
  .IP "17. Interpretation of Sections 15 and 16." 4
  .IX Item "17. Interpretation of Sections 15 and 16."
  If the disclaimer of warranty and limitation of liability provided
*************** reviewing courts shall apply local law t
*** 779,785 ****
  an absolute waiver of all civil liability in connection with the
  Program, unless a warranty or assumption of liability accompanies a
  copy of the Program in return for a fee.
! .SS "\s-1END OF TERMS AND CONDITIONS\s0"
  .IX Subsection "END OF TERMS AND CONDITIONS"
  .SS "How to Apply These Terms to Your New Programs"
  .IX Subsection "How to Apply These Terms to Your New Programs"
--- 704,710 ----
  an absolute waiver of all civil liability in connection with the
  Program, unless a warranty or assumption of liability accompanies a
  copy of the Program in return for a fee.
! .SS "END OF TERMS AND CONDITIONS"
  .IX Subsection "END OF TERMS AND CONDITIONS"
  .SS "How to Apply These Terms to Your New Programs"
  .IX Subsection "How to Apply These Terms to Your New Programs"
*************** terms.
*** 791,797 ****
  To do so, attach the following notices to the program.  It is safest
  to attach them to the start of each source file to most effectively
  state the exclusion of warranty; and each file should have at least
! the \*(L"copyright\*(R" line and a pointer to where the full notice is found.
  .PP
  .Vb 2
  \&          
--- 716,722 ----
  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.
  .PP
  .Vb 2
  \&          
*************** notice like this when it starts in an in
*** 825,848 ****
  .PP
  The hypothetical commands \fBshow w\fR and \fBshow c\fR should show
  the appropriate parts of the General Public License.  Of course, your
! program's commands might be different; for a \s-1GUI\s0 interface, you would
! use an \*(L"about box\*(R".
  .PP
  You should also get your employer (if you work as a programmer) or school,
! if any, to sign a \*(L"copyright disclaimer\*(R" for the program, if necessary.
! For more information on this, and how to apply and follow the \s-1GNU GPL,\s0 see
  <\fBhttps://www.gnu.org/licenses/\fR>.
  .PP
! The \s-1GNU\s0 General Public License does not permit incorporating your
  program into proprietary programs.  If your program is a subroutine
  library, you may consider it more useful to permit linking proprietary
  applications with the library.  If this is what you want to do, use
! the \s-1GNU\s0 Lesser General Public License instead of this License.  But
  first, please read <\fBhttps://www.gnu.org/licenses/why\-not\-lgpl.html\fR>.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
  \&\fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7).
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 2007 Free Software Foundation, Inc.
  .PP
--- 750,773 ----
  .PP
  The hypothetical commands \fBshow w\fR and \fBshow c\fR should show
  the appropriate parts of the General Public License.  Of course, your
! program\*(Aqs commands might be different; for a GUI interface, you would
! use an "about box".
  .PP
  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
  <\fBhttps://www.gnu.org/licenses/\fR>.
  .PP
! 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 <\fBhttps://www.gnu.org/licenses/why\-not\-lgpl.html\fR>.
  .SH "SEE ALSO"
  .IX Header "SEE ALSO"
  \&\fBgfdl\fR\|(7), \fBfsf\-funding\fR\|(7).
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 2007 Free Software Foundation, Inc.
  .PP
diff -Nrcpad gcc-13.4.0/gcc/doc/install.texi gcc-13.5.0-RC-20260904/gcc/doc/install.texi
*** gcc-13.4.0/gcc/doc/install.texi	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/install.texi	Fri Sep  4 07:35:08 2026
*************** Same as @uref{#with-as,,@option{--with-a
*** 1152,1158 ****
  but for the debug linker (only used on Darwin platforms so far).
  
  @item --with-tls=@var{dialect}
! Specify the default TLS dialect, for systems were there is a choice.
  For ARM targets, possible values for @var{dialect} are @code{gnu} or
  @code{gnu2}, which select between the original GNU dialect and the GNU TLS
  descriptor-based dialect.
--- 1152,1158 ----
  but for the debug linker (only used on Darwin platforms so far).
  
  @item --with-tls=@var{dialect}
! Specify the default TLS dialect, for systems where there is a choice.
  For ARM targets, possible values for @var{dialect} are @code{gnu} or
  @code{gnu2}, which select between the original GNU dialect and the GNU TLS
  descriptor-based dialect.
diff -Nrcpad gcc-13.4.0/gcc/doc/invoke.texi gcc-13.5.0-RC-20260904/gcc/doc/invoke.texi
*** gcc-13.4.0/gcc/doc/invoke.texi	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/invoke.texi	Fri Sep  4 07:35:08 2026
*************** the next @option{-x} option.  Possible v
*** 1632,1644 ****
  @smallexample
  c  c-header  cpp-output
  c++  c++-header  c++-system-header c++-user-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
  d
! f77  f77-cpp-input f95  f95-cpp-input
  go
  @end smallexample
  
  @item -x none
--- 1632,1648 ----
  @smallexample
  c  c-header  cpp-output
  c++  c++-header  c++-system-header c++-user-header c++-cpp-output
! objective-c  objective-c-header  objective-c-cpp-output  objc-cpp-output
! objective-c++  objective-c++-header  objective-c++-cpp-output
! objc++-cpp-output
  assembler  assembler-with-cpp
! ada  adascil  adawhy
  d
! f77  f77-cpp-input  f95  f95-cpp-input
  go
+ modula-2  modula-2-cpp-output
+ rust
+ lto
  @end smallexample
  
  @item -x none
*************** VPCLMULQDQ, AVX512BITALG, RDPID and AVX5
*** 32565,32575 ****
  @item alderlake
  @itemx raptorlake
  @itemx meteorlake
! Intel Alder Lake/Raptor Lake/Meteor Lake CPU with 64-bit extensions, MOVBE, MMX,
! SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL, RDRND,
! XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX, GFNI-SSE, CLWB,
! MOVDIRI, MOVDIR64B, CLDEMOTE, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C, FMA,
! LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL and
  AVX-VNNI instruction set support.
  
  @item sapphirerapids
--- 32569,32579 ----
  @item alderlake
  @itemx raptorlake
  @itemx meteorlake
! Intel Alder Lake/Raptor Lake/Meteor Lake CPU with 64-bit extensions, MOVBE,
! MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PREFETCHW, PCLMUL,
! RDRND, XSAVE, XSAVEC, XSAVES, XSAVEOPT, FSGSBASE, PTWRITE, RDPID, SGX,
! GFNI-SSE, CLWB, MOVDIRI, MOVDIR64B, WAITPKG, ADCX, AVX, AVX2, BMI, BMI2, F16C,
! FMA, LZCNT, PCONFIG, PKU, VAES, VPCLMULQDQ, SERIALIZE, HRESET, KL, WIDEKL and
  AVX-VNNI instruction set support.
  
  @item sapphirerapids
diff -Nrcpad gcc-13.4.0/gcc/doc/lto-dump.1 gcc-13.5.0-RC-20260904/gcc/doc/lto-dump.1
*** gcc-13.4.0/gcc/doc/lto-dump.1	Thu Jun  5 16:06:29 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/lto-dump.1	Fri Sep  4 07:36:30 2026
***************
*** 1,4 ****
! .\" Automatically generated by Pod::Man 4.14 (Pod::Simple 3.43)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
--- 1,5 ----
! .\" -*- mode: troff; coding: utf-8 -*-
! .\" Automatically generated by Pod::Man v6.0.2 (Pod::Simple 3.45)
  .\"
  .\" Standard preamble:
  .\" ========================================================================
***************
*** 15,43 ****
  .ft R
  .fi
  ..
! .\" Set up some character translations and predefined strings.  \*(-- will
! .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
! .\" double quote, and \*(R" will give a right double quote.  \*(C+ will
! .\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
! .\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
! .\" nothing in troff, for use with C<>.
! .tr \(*W-
! .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
  .ie n \{\
- .    ds -- \(*W-
- .    ds PI pi
- .    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
- .    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
- .    ds L" ""
- .    ds R" ""
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
- .    ds -- \|\(em\|
- .    ds PI \(*p
- .    ds L" ``
- .    ds R" ''
  .    ds C`
  .    ds C'
  'br\}
--- 16,27 ----
  .ft R
  .fi
  ..
! .\" \*(C` and \*(C' are quotes in nroff, nothing in troff, for use with C<>.
  .ie n \{\
  .    ds C` ""
  .    ds C' ""
  'br\}
  .el\{\
  .    ds C`
  .    ds C'
  'br\}
***************
*** 69,148 ****
  .\}
  .rr rF
  .\"
! .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
! .\" Fear.  Run.  Save yourself.  No user-serviceable parts.
! .    \" fudge factors for nroff and troff
! .if n \{\
! .    ds #H 0
! .    ds #V .8m
! .    ds #F .3m
! .    ds #[ \f1
! .    ds #] \fP
! .\}
! .if t \{\
! .    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
! .    ds #V .6m
! .    ds #F 0
! .    ds #[ \&
! .    ds #] \&
! .\}
! .    \" simple accents for nroff and troff
! .if n \{\
! .    ds ' \&
! .    ds ` \&
! .    ds ^ \&
! .    ds , \&
! .    ds ~ ~
! .    ds /
! .\}
! .if t \{\
! .    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
! .    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
! .    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
! .    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
! .    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
! .    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
! .\}
! .    \" troff and (daisy-wheel) nroff accents
! .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
! .ds 8 \h'\*(#H'\(*b\h'-\*(#H'
! .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
! .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
! .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
! .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
! .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
! .ds ae a\h'-(\w'a'u*4/10)'e
! .ds Ae A\h'-(\w'A'u*4/10)'E
! .    \" corrections for vroff
! .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
! .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
! .    \" for low resolution devices (crt and lpr)
! .if \n(.H>23 .if \n(.V>19 \
! \{\
! .    ds : e
! .    ds 8 ss
! .    ds o a
! .    ds d- d\h'-1'\(ga
! .    ds D- D\h'-1'\(hy
! .    ds th \o'bp'
! .    ds Th \o'LP'
! .    ds ae ae
! .    ds Ae AE
! .\}
! .rm #[ #] #H #V #F C
  .\" ========================================================================
  .\"
  .IX Title "LTO-DUMP 1"
! .TH LTO-DUMP 1 "2025-06-05" "gcc-13.4.0" "GNU"
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH "NAME"
  lto\-dump \- Tool for dumping LTO object files
! .SH "SYNOPSIS"
  .IX Header "SYNOPSIS"
! lto-dump [\fB\-list\fR]
       [\fB\-demangle\fR]
       [\fB\-defined\-only\fR]
       [\fB\-print\-value\fR]
--- 53,73 ----
  .\}
  .rr rF
  .\"
! .\" Required to disable full justification in groff 1.23.0.
! .if n .ds AD l
  .\" ========================================================================
  .\"
  .IX Title "LTO-DUMP 1"
! .TH LTO-DUMP 1 2026-09-04 gcc-13.4.1 GNU
  .\" For nroff, turn off justification.  Always turn off hyphenation; it makes
  .\" way too many mistakes in technical documents.
  .if n .ad l
  .nh
! .SH NAME
  lto\-dump \- Tool for dumping LTO object files
! .SH SYNOPSIS
  .IX Header "SYNOPSIS"
! lto\-dump [\fB\-list\fR]
       [\fB\-demangle\fR]
       [\fB\-defined\-only\fR]
       [\fB\-print\-value\fR]
*************** lto-dump [\fB\-list\fR]
*** 157,236 ****
       [\fB\-gimple\-stats\fR]
       [\fB\-dump\-level=\fR]
       [\fB\-dump\-body=\fR]
!      [\fB\-help\fR] \fIlto-dump\fR
! .SH "DESCRIPTION"
  .IX Header "DESCRIPTION"
! \&\fBlto-dump\fR is a tool you can use in conjunction with \s-1GCC\s0 to
  dump link time optimization object files.
! .SH "OPTIONS"
  .IX Header "OPTIONS"
! .IP "\fB\-list\fR" 4
  .IX Item "-list"
  Dumps list of details of functions and variables.
! .IP "\fB\-demangle\fR" 4
  .IX Item "-demangle"
  Dump the demangled output.
! .IP "\fB\-defined\-only\fR" 4
  .IX Item "-defined-only"
  Dump only the defined symbols.
! .IP "\fB\-print\-value\fR" 4
  .IX Item "-print-value"
  Dump initial values of the variables.
! .IP "\fB\-name\-sort\fR" 4
  .IX Item "-name-sort"
  Sort the symbols alphabetically.
! .IP "\fB\-size\-sort\fR" 4
  .IX Item "-size-sort"
  Sort the symbols according to size.
! .IP "\fB\-reverse\-sort\fR" 4
  .IX Item "-reverse-sort"
  Dump the symbols in reverse order.
! .IP "\fB\-no\-sort\fR" 4
  .IX Item "-no-sort"
  Dump the symbols in order of occurrence.
! .IP "\fB\-symbol=\fR" 4
  .IX Item "-symbol="
  Dump the details of specific symbol.
! .IP "\fB\-objects\fR" 4
  .IX Item "-objects"
! Dump the details of \s-1LTO\s0 objects.
! .IP "\fB\-type\-stats\fR" 4
  .IX Item "-type-stats"
  Dump the statistics of tree types.
! .IP "\fB\-tree\-stats\fR" 4
  .IX Item "-tree-stats"
  Dump the statistics of trees.
! .IP "\fB\-gimple\-stats\fR" 4
  .IX Item "-gimple-stats"
  Dump the statistics of gimple statements.
! .IP "\fB\-dump\-level=\fR" 4
  .IX Item "-dump-level="
  For deciding the optimization level of body.
! .IP "\fB\-dump\-body=\fR" 4
  .IX Item "-dump-body="
  Dump the specific gimple body.
! .IP "\fB\-help\fR" 4
  .IX Item "-help"
  Display the dump tool help.
! .SH "COPYRIGHT"
  .IX Header "COPYRIGHT"
  Copyright (c) 2017\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
! Free Software\*(R", the Front-Cover texts being (a) (see below), and with
! the Back-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The \s-1FSF\s0's Front-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The \s-1FSF\s0's Back-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
--- 82,161 ----
       [\fB\-gimple\-stats\fR]
       [\fB\-dump\-level=\fR]
       [\fB\-dump\-body=\fR]
!      [\fB\-help\fR] \fIlto\-dump\fR
! .SH DESCRIPTION
  .IX Header "DESCRIPTION"
! \&\fBlto\-dump\fR is a tool you can use in conjunction with GCC to
  dump link time optimization object files.
! .SH OPTIONS
  .IX Header "OPTIONS"
! .IP \fB\-list\fR 4
  .IX Item "-list"
  Dumps list of details of functions and variables.
! .IP \fB\-demangle\fR 4
  .IX Item "-demangle"
  Dump the demangled output.
! .IP \fB\-defined\-only\fR 4
  .IX Item "-defined-only"
  Dump only the defined symbols.
! .IP \fB\-print\-value\fR 4
  .IX Item "-print-value"
  Dump initial values of the variables.
! .IP \fB\-name\-sort\fR 4
  .IX Item "-name-sort"
  Sort the symbols alphabetically.
! .IP \fB\-size\-sort\fR 4
  .IX Item "-size-sort"
  Sort the symbols according to size.
! .IP \fB\-reverse\-sort\fR 4
  .IX Item "-reverse-sort"
  Dump the symbols in reverse order.
! .IP \fB\-no\-sort\fR 4
  .IX Item "-no-sort"
  Dump the symbols in order of occurrence.
! .IP \fB\-symbol=\fR 4
  .IX Item "-symbol="
  Dump the details of specific symbol.
! .IP \fB\-objects\fR 4
  .IX Item "-objects"
! Dump the details of LTO objects.
! .IP \fB\-type\-stats\fR 4
  .IX Item "-type-stats"
  Dump the statistics of tree types.
! .IP \fB\-tree\-stats\fR 4
  .IX Item "-tree-stats"
  Dump the statistics of trees.
! .IP \fB\-gimple\-stats\fR 4
  .IX Item "-gimple-stats"
  Dump the statistics of gimple statements.
! .IP \fB\-dump\-level=\fR 4
  .IX Item "-dump-level="
  For deciding the optimization level of body.
! .IP \fB\-dump\-body=\fR 4
  .IX Item "-dump-body="
  Dump the specific gimple body.
! .IP \fB\-help\fR 4
  .IX Item "-help"
  Display the dump tool help.
! .SH COPYRIGHT
  .IX Header "COPYRIGHT"
  Copyright (c) 2017\-2023 Free Software Foundation, Inc.
  .PP
  Permission is granted to copy, distribute and/or modify this document
! under the terms of the GNU Free Documentation License, Version 1.3 or
  any later version published by the Free Software Foundation; with the
! Invariant Sections being "GNU General Public License" and "Funding
! Free Software", the Front\-Cover texts being (a) (see below), and with
! the Back\-Cover Texts being (b) (see below).  A copy of the license is
  included in the \fBgfdl\fR\|(7) man page.
  .PP
! (a) The FSF\*(Aqs Front\-Cover Text is:
  .PP
  .Vb 1
  \&     A GNU Manual
  .Ve
  .PP
! (b) The FSF\*(Aqs Back\-Cover Text is:
  .PP
  .Vb 3
  \&     You have freedom to copy and modify this GNU Manual, like GNU
diff -Nrcpad gcc-13.4.0/gcc/doc/m2.info gcc-13.5.0-RC-20260904/gcc/doc/m2.info
*** gcc-13.4.0/gcc/doc/m2.info	Thu Jun  5 16:25:59 2025
--- gcc-13.5.0-RC-20260904/gcc/doc/m2.info	Fri Sep  4 07:54:02 2026
***************
*** 1,6 ****
! This is m2.info, produced by makeinfo version 6.8 from gm2.texi.
  
! Copyright (C) 1999-2023 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
--- 1,6 ----
! This is m2.info, produced by makeinfo version 7.1 from gm2.texi.
  
! Copyright © 1999-2023 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
*************** START-INFO-DIR-ENTRY
*** 14,20 ****
  END-INFO-DIR-ENTRY
  
  
!    Copyright (C) 1999-2023 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
--- 14,20 ----
  END-INFO-DIR-ENTRY
  
  
!    Copyright © 1999-2023 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
*************** available and access to assembly program
*** 115,123 ****
  syntax as that used by GCC.
  
     The gm2 driver allows third party libraries to be installed alongside
! gm2 libraries.  For example if the user specifies library 'foo' using
! '-flibs=foo' the driver will check the standard GCC install directory
! for a sub directory 'foo' containing the library contents.  The library
  module search path is altered accordingly for compile and link.
  
  
--- 115,123 ----
  syntax as that used by GCC.
  
     The gm2 driver allows third party libraries to be installed alongside
! gm2 libraries.  For example if the user specifies library ‘foo’ using
! ‘-flibs=foo’ the driver will check the standard GCC install directory
! for a sub directory ‘foo’ containing the library contents.  The library
  module search path is altered accordingly for compile and link.
  
  
*************** File: m2.info,  Node: Features,  Prev: D
*** 134,176 ****
  1.4 GNU Modula-2 Features
  =========================
  
!    * the compiler currently complies with Programming in Modula-2
       Edition 2, 3, 4 and ISO Modula-2.  Users can switch on specific
!      language features by using: '-fpim', '-fpim2', '-fpim3', '-fpim4'
!      or '-fiso'.
  
!    * the option '-fswig' will automatically create a swig interface file
       which corresponds to the definition module of the file being
       compiled.
  
!    * exception handling is compatible with C++ and swig.  Modula-2 code
       can be used with C or C++ code.
  
!    * Python can call GNU Modula-2 modules via swig.
  
!    * shared libraries can be built.
  
!    * fixed sized types are now available from 'SYSTEM'.
  
!    * variables can be declared at addresses.
  
!    * much better dwarf-2 debugging support and when used with 'gdb' the
!      programmer can display 'RECORD's, 'ARRAY's, 'SET's, subranges and
       constant char literals in Modula-2 syntax.
  
!    * supports sets of any ordinal size (memory permitting).
  
!    * easy interface to C, and varargs can be passed to C routines.
  
!    * many Logitech libraries have been implemented and can be accessed
!      via: '-flibs=m2log,m2pim,m2iso'.
  
!    * coroutines have been implemented in the PIM style and these are
       accessible from SYSTEM. A number of supporting libraries (executive
       and file descriptor mapping to interrupt vector libraries are
!      available through the '-flibs=m2iso,m2pim' switch).
  
!    * can be built as a cross compiler (for embedded microprocessors such
       as the AVR and the ARM).
  
  
--- 134,176 ----
  1.4 GNU Modula-2 Features
  =========================
  
!    • the compiler currently complies with Programming in Modula-2
       Edition 2, 3, 4 and ISO Modula-2.  Users can switch on specific
!      language features by using: ‘-fpim’, ‘-fpim2’, ‘-fpim3’, ‘-fpim4’
!      or ‘-fiso’.
  
!    • the option ‘-fswig’ will automatically create a swig interface file
       which corresponds to the definition module of the file being
       compiled.
  
!    • exception handling is compatible with C++ and swig.  Modula-2 code
       can be used with C or C++ code.
  
!    • Python can call GNU Modula-2 modules via swig.
  
!    • shared libraries can be built.
  
!    • fixed sized types are now available from ‘SYSTEM’.
  
!    • variables can be declared at addresses.
  
!    • much better dwarf-2 debugging support and when used with ‘gdb’ the
!      programmer can display ‘RECORD’s, ‘ARRAY’s, ‘SET’s, subranges and
       constant char literals in Modula-2 syntax.
  
!    • supports sets of any ordinal size (memory permitting).
  
!    • easy interface to C, and varargs can be passed to C routines.
  
!    • many Logitech libraries have been implemented and can be accessed
!      via: ‘-flibs=m2log,m2pim,m2iso’.
  
!    • coroutines have been implemented in the PIM style and these are
       accessible from SYSTEM. A number of supporting libraries (executive
       and file descriptor mapping to interrupt vector libraries are
!      available through the ‘-flibs=m2iso,m2pim’ switch).
  
!    • can be built as a cross compiler (for embedded microprocessors such
       as the AVR and the ARM).
  
  
*************** File: m2.info,  Node: Example usage,  Ne
*** 221,235 ****
  2.1 Example compile and link
  ============================
  
! The 'gm2' command is the GNU compiler for the Modula-2 language and
! supports many of the same options as 'gcc'.  *Note Option Summary:
  (gcc)Option Summary.  This manual only documents the options specific to
! 'gm2'.
  
     This section describes how to compile and link a simple hello world
  program.  It provides a few examples of using the different options
  mentioned in *note (gm2)Compiler options::.  Assuming that you have a
! file called 'hello.mod' in your current directory which contains:
  
       MODULE hello ;
  
--- 221,235 ----
  2.1 Example compile and link
  ============================
  
! The ‘gm2’ command is the GNU compiler for the Modula-2 language and
! supports many of the same options as ‘gcc’.  *Note Option Summary:
  (gcc)Option Summary.  This manual only documents the options specific to
! ‘gm2’.
  
     This section describes how to compile and link a simple hello world
  program.  It provides a few examples of using the different options
  mentioned in *note (gm2)Compiler options::.  Assuming that you have a
! file called ‘hello.mod’ in your current directory which contains:
  
       MODULE hello ;
  
*************** file called 'hello.mod' in your current
*** 239,261 ****
          WriteString ('hello world') ; WriteLn
       END hello.
  
!    You can compile and link it by: 'gm2 -g hello.mod'.  The result will
! be an 'a.out' file created in your directory.
  
     You can split this command into two steps if you prefer.  The compile
! step can be achieved by: 'gm2 -g -c -fscaffold-main hello.mod' and the
! link via: 'gm2 -g hello.o'.
  
     (1)
  
     ---------- Footnotes ----------
  
!    (1) To see all the compile actions taken by 'gm2' users can also add
! the '-v' flag at the command line, for example:
  
!    'gm2 -v -g -I. hello.mod'
  
!    This displays the sub processes initiated by 'gm2' which can be
  useful when trouble shooting.
  
  
--- 239,261 ----
          WriteString ('hello world') ; WriteLn
       END hello.
  
!    You can compile and link it by: ‘gm2 -g hello.mod’.  The result will
! be an ‘a.out’ file created in your directory.
  
     You can split this command into two steps if you prefer.  The compile
! step can be achieved by: ‘gm2 -g -c -fscaffold-main hello.mod’ and the
! link via: ‘gm2 -g hello.o’.
  
     (1)
  
     ---------- Footnotes ----------
  
!    (1) To see all the compile actions taken by ‘gm2’ users can also add
! the ‘-v’ flag at the command line, for example:
  
!    ‘gm2 -v -g -I. hello.mod’
  
!    This displays the sub processes initiated by ‘gm2’ which can be
  useful when trouble shooting.
  
  
*************** generic flags details *Note (gcc)Invokin
*** 271,367 ****
  of compilation is done.  The following kinds of input file names are
  supported:
  
! 'FILE.mod'
!      Modula-2 implementation or program source files.  See the '-fmod='
       option if you wish to compile a project which uses a different
       source file extension.
! 'FILE.def'
       Modula-2 definition module source files.  Definition modules are
       not compiled separately, in GNU Modula-2 definition modules are
       parsed as required when program or implementation modules are
!      compiled.  See the '-fdef=' option if you wish to compile a project
       which uses a different source file extension.
  
!    You can specify more than one input file on the 'gm2' command line,
  
! '-g'
!      create debugging information so that debuggers such as 'gdb' can
       inspect and control executable.
  
! '-I'
       used to specify the search path for definition and implementation
!      modules.  An example is: 'gm2 -g -c -I.:../../libs foo.mod'.  If
       this option is not specified then the default path is added which
       consists of the current directory followed by the appropriate
       language dialect library directories.
  
! '-fauto-init'
       turns on auto initialization of pointers to NIL. Whenever a block
       is created all pointers declared within this scope will have their
       addresses assigned to NIL.
  
! '-fbounds'
!      turns on run time subrange, array index and indirection via 'NIL'
       pointer checking.
  
! '-fcase'
!      turns on compile time checking to check whether a 'CASE' statement
!      requires an 'ELSE' clause when on was not specified.
  
! '-fcpp'
!      preprocess the source with 'cpp -lang-asm -traditional-cpp' For
       further details about these options *Note (cpp)Invocation::.  If
!      '-fcpp' is supplied then all definition modules and implementation
!      modules which are parsed will be prepossessed by 'cpp'.
  
! '-fdebug-builtins'
       call a real function, rather than the builtin equivalent.  This can
       be useful for debugging parameter values to a builtin function as
       it allows users to single step code into a real function.
  
! '-fdef='
       recognize the specified suffix as a definition module filename.
!      The default implementation and module filename suffix is '.def'.
       If this option is used GNU Modula-2 will still fall back to this
       default if a requested definition module is not found.
  
! '-fdump-system-exports'
       display all inbuilt system items.  This is an internal command line
       option.
  
! '-fexceptions'
       turn on exception handling code.  By default this option is on.
!      Exception handling can be disabled by '-fno-exceptions' and no
       references are made to the run time exception libraries.
  
! '-fextended-opaque'
       allows opaque types to be implemented as any type.  This is a GNU
       Modula-2 extension and it requires that the implementation module
       defining the opaque type is available so that it can be resolved
       when compiling the module which imports the opaque type.
  
! '-ffloatvalue'
       turns on run time checking to check whether a floating point number
       is about to exceed range.
  
! '-fgen-module-list=filename'
       attempt to find all modules when linking and generate a module
!      list.  If the 'filename' is '-' then the contents are not written
       and only used to force the linking of all module ctors.  This
!      option cannot be used if '-fuse-list=' is enabled.
  
! '-findex'
       generate code to check whether array index values are out of
!      bounds.  Array index checking can be disabled via '-fno-index'.
  
! '-fiso'
       turn on ISO standard features.  Currently this enables the ISO
!      'SYSTEM' module and alters the default library search path so that
       the ISO libraries are searched before the PIM libraries.  It also
!      effects the behavior of 'DIV' and 'MOD' operators.  *Note
       (gm2)Dialect::.
  
! '-flibs='
       modifies the default library search path.  The libraries supplied
       are: m2pim, m2iso, m2min, m2log and m2cor.  These map onto the
       Programming in Modula-2 base libraries, ISO standard libraries,
--- 271,367 ----
  of compilation is done.  The following kinds of input file names are
  supported:
  
! ‘FILE.mod’
!      Modula-2 implementation or program source files.  See the ‘-fmod=’
       option if you wish to compile a project which uses a different
       source file extension.
! ‘FILE.def’
       Modula-2 definition module source files.  Definition modules are
       not compiled separately, in GNU Modula-2 definition modules are
       parsed as required when program or implementation modules are
!      compiled.  See the ‘-fdef=’ option if you wish to compile a project
       which uses a different source file extension.
  
!    You can specify more than one input file on the ‘gm2’ command line,
  
! ‘-g’
!      create debugging information so that debuggers such as ‘gdb’ can
       inspect and control executable.
  
! ‘-I’
       used to specify the search path for definition and implementation
!      modules.  An example is: ‘gm2 -g -c -I.:../../libs foo.mod’.  If
       this option is not specified then the default path is added which
       consists of the current directory followed by the appropriate
       language dialect library directories.
  
! ‘-fauto-init’
       turns on auto initialization of pointers to NIL. Whenever a block
       is created all pointers declared within this scope will have their
       addresses assigned to NIL.
  
! ‘-fbounds’
!      turns on run time subrange, array index and indirection via ‘NIL’
       pointer checking.
  
! ‘-fcase’
!      turns on compile time checking to check whether a ‘CASE’ statement
!      requires an ‘ELSE’ clause when on was not specified.
  
! ‘-fcpp’
!      preprocess the source with ‘cpp -lang-asm -traditional-cpp’ For
       further details about these options *Note (cpp)Invocation::.  If
!      ‘-fcpp’ is supplied then all definition modules and implementation
!      modules which are parsed will be prepossessed by ‘cpp’.
  
! ‘-fdebug-builtins’
       call a real function, rather than the builtin equivalent.  This can
       be useful for debugging parameter values to a builtin function as
       it allows users to single step code into a real function.
  
! ‘-fdef=’
       recognize the specified suffix as a definition module filename.
!      The default implementation and module filename suffix is ‘.def’.
       If this option is used GNU Modula-2 will still fall back to this
       default if a requested definition module is not found.
  
! ‘-fdump-system-exports’
       display all inbuilt system items.  This is an internal command line
       option.
  
! ‘-fexceptions’
       turn on exception handling code.  By default this option is on.
!      Exception handling can be disabled by ‘-fno-exceptions’ and no
       references are made to the run time exception libraries.
  
! ‘-fextended-opaque’
       allows opaque types to be implemented as any type.  This is a GNU
       Modula-2 extension and it requires that the implementation module
       defining the opaque type is available so that it can be resolved
       when compiling the module which imports the opaque type.
  
! ‘-ffloatvalue’
       turns on run time checking to check whether a floating point number
       is about to exceed range.
  
! ‘-fgen-module-list=filename’
       attempt to find all modules when linking and generate a module
!      list.  If the ‘filename’ is ‘-’ then the contents are not written
       and only used to force the linking of all module ctors.  This
!      option cannot be used if ‘-fuse-list=’ is enabled.
  
! ‘-findex’
       generate code to check whether array index values are out of
!      bounds.  Array index checking can be disabled via ‘-fno-index’.
  
! ‘-fiso’
       turn on ISO standard features.  Currently this enables the ISO
!      ‘SYSTEM’ module and alters the default library search path so that
       the ISO libraries are searched before the PIM libraries.  It also
!      effects the behavior of ‘DIV’ and ‘MOD’ operators.  *Note
       (gm2)Dialect::.
  
! ‘-flibs=’
       modifies the default library search path.  The libraries supplied
       are: m2pim, m2iso, m2min, m2log and m2cor.  These map onto the
       Programming in Modula-2 base libraries, ISO standard libraries,
*************** supported:
*** 372,539 ****
       -flibs=m2iso if you also specify -fpim, -fpim2, -fpim3, -fpim4 or
       -fiso.  Unless you are using -flibs=m2min you should include m2pim
       as the they provide the base modules which all other dialects
!      utilize.  The option '-fno-libs=-' disables the 'gm2' driver from
       modifying the search and library paths.
  
! '-static-libgm2'
       On systems that provide the m2 runtimes as both shared and static
       libraries, this option forces the use of the static version.
  
! '-fm2-g'
       improve the debugging experience for new programmers at the expense
!      of generating 'nop' instructions if necessary to ensure single
       stepping precision over all code related keywords.  An example of
!      this is in termination of a list of nested 'IF' statements where
!      multiple 'END' keywords are mapped onto a sequence of 'nop'
       instructions.
  
! '-fm2-lower-case'
       render keywords in error messages using lower case.
  
! '-fm2-pathname='
       specify the module mangled prefix name for all modules in the
       following include paths.
  
! '-fm2-pathnameI'
       for internal use only: used by the driver to copy the user facing
       -I option.
  
! '-fm2-plugin'
       insert plugin to identify run time errors at compile time (default
       on).
  
! '-fm2-prefix='
       specify the module mangled prefix name.  All exported symbols from
       a definition module will have the prefix name.
  
! '-fm2-statistics'
       generates quadruple information: number of quadruples generated,
       number of quadruples remaining after optimization and number of
       source lines compiled.
  
! '-fm2-strict-type'
       experimental flag to turn on the new strict type checker.
  
! '-fm2-whole-program'
       compile all implementation modules and program module at once.
       Notice that you need to take care if you are compiling different
       dialect modules (particularly with the negative operands to
!      modulus).  But this option, when coupled together with '-O3', can
       deliver huge performance improvements.
  
! '-fmod='
       recognize the specified suffix as implementation and module
       filenames.  The default implementation and module filename suffix
!      is '.mod'.  If this option is used GNU Modula-2 will still fall
       back to this default if it needs to read an implementation module
       and the specified suffixed filename does not exist.
  
! '-fnil'
!      generate code to detect accessing data through a 'NIL' value
!      pointer.  Dereferencing checking through a 'NIL' pointer can be
!      disabled by '-fno-nil'.
  
! '-fpim'
       turn on PIM standard features.  Currently this enables the PIM
!      'SYSTEM' module and determines which identifiers are pervasive
!      (declared in the base module).  If no other '-fpim[234]' switch is
       used then division and modulus operators behave as defined in PIM4.
       *Note (gm2)Dialect::.
  
! '-fpim2'
!      turn on PIM-2 standard features.  Currently this removes 'SIZE'
       from being a pervasive identifier (declared in the base module).
!      It places 'SIZE' in the 'SYSTEM' module.  It also effects the
!      behavior of 'DIV' and 'MOD' operators.  *Note (gm2)Dialect::.
  
! '-fpim3'
       turn on PIM-3 standard features.  Currently this only effects the
!      behavior of 'DIV' and 'MOD' operators.  *Note (gm2)Dialect::.
  
! '-fpim4'
       turn on PIM-4 standard features.  Currently this only effects the
!      behavior of 'DIV' and 'MOD' operators.  *Note (gm2)Dialect::.
  
! '-fpositive-mod-floor-div'
!      forces the 'DIV' and 'MOD' operators to behave as defined by PIM4.
       All modulus results are positive and the results from the division
       are rounded to the floor.  *Note (gm2)Dialect::.
  
! '-fpthread'
       link against the pthread library.  By default this option is on.
!      It can be disabled by '-fno-pthread'.  GNU Modula-2 uses the GCC
       pthread libraries to implement coroutines (see the SYSTEM
       implementation module).
  
! '-frange'
       generate code to check the assignment range, return value range set
       range and constructor range.  Range checking can be disabled via
!      '-fno-range'.
  
! '-freturn'
!      generate code to check that functions always exit with a 'RETURN'
       and do not fall out at the end.  Return checking can be disabled
!      via '-fno-return'.
  
! '-fruntime-modules='
       specify, using a comma separated list, the run time modules and
       their order.  These modules will initialized first before any other
       modules in the application dependency.  By default the run time
!      modules list is set to 'm2iso:RTentity,m2iso:Storage,m2iso:SYSTEM,'
!      'm2iso:M2RTS,m2iso:RTExceptions,m2iso:IOLink'.  Note that these
       modules will only be linked into your executable if they are
       required.  Adding a long list of dependent modules will not effect
       the size of the executable it merely states the initialization
       order should they be required.
  
! '-fscaffold-dynamic'
!      the option ensures that 'gm2' will generate a dynamic scaffold
       infrastructure when compiling implementation and program modules.
!      By default this option is on.  Use '-fno-scaffold-dynamic' to turn
!      it off or select '-fno-scaffold-static'.
  
! '-fscaffold-c'
       generate a C source scaffold for the current module being compiled.
  
! '-fscaffold-c++'
       generate a C++ source scaffold for the current module being
       compiled.
  
! '-fscaffold-main'
!      force the generation of the 'main' function.  This is not necessary
!      if the '-c' is omitted.
  
! '-fscaffold-static'
!      the option ensures that 'gm2' will generate a static scaffold
       within the program module.  The static scaffold consists of
       sequences of calls to all dependent module initialization and
       finalization procedures.  The static scaffold is useful for
       debugging and single stepping the initialization blocks of
       implementation modules.
  
! '-fshared'
       generate a shared library from the module.
  
! '-fsoft-check-all'
       turns on all run time checks.  This is the same as invoking GNU
!      Modula-2 using the command options '-fnil' '-frange' '-findex'
!      '-fwholevalue' '-fwholediv' '-fcase' '-freturn'.
  
! '-fsources'
       displays the path to the source of each module.  This option can be
       used at compile time to check the correct definition module is
       being used.
  
! '-fswig'
       generate a swig interface file.
  
! '-funbounded-by-reference'
       enable optimization of unbounded parameters by attempting to pass
!      non 'VAR' unbounded parameters by reference.  This optimization
       avoids the implicit copy inside the callee procedure.  GNU Modula-2
       will only allow unbounded parameters to be passed by reference if,
       inside the callee procedure, they are not written to, no address is
!      calculated on the array and it is not passed as a 'VAR' parameter.
       Note that it is possible to write code to break this optimization,
       therefore this option should be used carefully.  For example it
       would be possible to take the address of an array, pass the address
--- 372,539 ----
       -flibs=m2iso if you also specify -fpim, -fpim2, -fpim3, -fpim4 or
       -fiso.  Unless you are using -flibs=m2min you should include m2pim
       as the they provide the base modules which all other dialects
!      utilize.  The option ‘-fno-libs=-’ disables the ‘gm2’ driver from
       modifying the search and library paths.
  
! ‘-static-libgm2’
       On systems that provide the m2 runtimes as both shared and static
       libraries, this option forces the use of the static version.
  
! ‘-fm2-g’
       improve the debugging experience for new programmers at the expense
!      of generating ‘nop’ instructions if necessary to ensure single
       stepping precision over all code related keywords.  An example of
!      this is in termination of a list of nested ‘IF’ statements where
!      multiple ‘END’ keywords are mapped onto a sequence of ‘nop’
       instructions.
  
! ‘-fm2-lower-case’
       render keywords in error messages using lower case.
  
! ‘-fm2-pathname=’
       specify the module mangled prefix name for all modules in the
       following include paths.
  
! ‘-fm2-pathnameI’
       for internal use only: used by the driver to copy the user facing
       -I option.
  
! ‘-fm2-plugin’
       insert plugin to identify run time errors at compile time (default
       on).
  
! ‘-fm2-prefix=’
       specify the module mangled prefix name.  All exported symbols from
       a definition module will have the prefix name.
  
! ‘-fm2-statistics’
       generates quadruple information: number of quadruples generated,
       number of quadruples remaining after optimization and number of
       source lines compiled.
  
! ‘-fm2-strict-type’
       experimental flag to turn on the new strict type checker.
  
! ‘-fm2-whole-program’
       compile all implementation modules and program module at once.
       Notice that you need to take care if you are compiling different
       dialect modules (particularly with the negative operands to
!      modulus).  But this option, when coupled together with ‘-O3’, can
       deliver huge performance improvements.
  
! ‘-fmod=’
       recognize the specified suffix as implementation and module
       filenames.  The default implementation and module filename suffix
!      is ‘.mod’.  If this option is used GNU Modula-2 will still fall
       back to this default if it needs to read an implementation module
       and the specified suffixed filename does not exist.
  
! ‘-fnil’
!      generate code to detect accessing data through a ‘NIL’ value
!      pointer.  Dereferencing checking through a ‘NIL’ pointer can be
!      disabled by ‘-fno-nil’.
  
! ‘-fpim’
       turn on PIM standard features.  Currently this enables the PIM
!      ‘SYSTEM’ module and determines which identifiers are pervasive
!      (declared in the base module).  If no other ‘-fpim[234]’ switch is
       used then division and modulus operators behave as defined in PIM4.
       *Note (gm2)Dialect::.
  
! ‘-fpim2’
!      turn on PIM-2 standard features.  Currently this removes ‘SIZE’
       from being a pervasive identifier (declared in the base module).
!      It places ‘SIZE’ in the ‘SYSTEM’ module.  It also effects the
!      behavior of ‘DIV’ and ‘MOD’ operators.  *Note (gm2)Dialect::.
  
! ‘-fpim3’
       turn on PIM-3 standard features.  Currently this only effects the
!      behavior of ‘DIV’ and ‘MOD’ operators.  *Note (gm2)Dialect::.
  
! ‘-fpim4’
       turn on PIM-4 standard features.  Currently this only effects the
!      behavior of ‘DIV’ and ‘MOD’ operators.  *Note (gm2)Dialect::.
  
! ‘-fpositive-mod-floor-div’
!      forces the ‘DIV’ and ‘MOD’ operators to behave as defined by PIM4.
       All modulus results are positive and the results from the division
       are rounded to the floor.  *Note (gm2)Dialect::.
  
! ‘-fpthread’
       link against the pthread library.  By default this option is on.
!      It can be disabled by ‘-fno-pthread’.  GNU Modula-2 uses the GCC
       pthread libraries to implement coroutines (see the SYSTEM
       implementation module).
  
! ‘-frange’
       generate code to check the assignment range, return value range set
       range and constructor range.  Range checking can be disabled via
!      ‘-fno-range’.
  
! ‘-freturn’
!      generate code to check that functions always exit with a ‘RETURN’
       and do not fall out at the end.  Return checking can be disabled
!      via ‘-fno-return’.
  
! ‘-fruntime-modules=’
       specify, using a comma separated list, the run time modules and
       their order.  These modules will initialized first before any other
       modules in the application dependency.  By default the run time
!      modules list is set to ‘m2iso:RTentity,m2iso:Storage,m2iso:SYSTEM,’
!      ‘m2iso:M2RTS,m2iso:RTExceptions,m2iso:IOLink’.  Note that these
       modules will only be linked into your executable if they are
       required.  Adding a long list of dependent modules will not effect
       the size of the executable it merely states the initialization
       order should they be required.
  
! ‘-fscaffold-dynamic’
!      the option ensures that ‘gm2’ will generate a dynamic scaffold
       infrastructure when compiling implementation and program modules.
!      By default this option is on.  Use ‘-fno-scaffold-dynamic’ to turn
!      it off or select ‘-fno-scaffold-static’.
  
! ‘-fscaffold-c’
       generate a C source scaffold for the current module being compiled.
  
! ‘-fscaffold-c++’
       generate a C++ source scaffold for the current module being
       compiled.
  
! ‘-fscaffold-main’
!      force the generation of the ‘main’ function.  This is not necessary
!      if the ‘-c’ is omitted.
  
! ‘-fscaffold-static’
!      the option ensures that ‘gm2’ will generate a static scaffold
       within the program module.  The static scaffold consists of
       sequences of calls to all dependent module initialization and
       finalization procedures.  The static scaffold is useful for
       debugging and single stepping the initialization blocks of
       implementation modules.
  
! ‘-fshared’
       generate a shared library from the module.
  
! ‘-fsoft-check-all’
       turns on all run time checks.  This is the same as invoking GNU
!      Modula-2 using the command options ‘-fnil’ ‘-frange’ ‘-findex’
!      ‘-fwholevalue’ ‘-fwholediv’ ‘-fcase’ ‘-freturn’.
  
! ‘-fsources’
       displays the path to the source of each module.  This option can be
       used at compile time to check the correct definition module is
       being used.
  
! ‘-fswig’
       generate a swig interface file.
  
! ‘-funbounded-by-reference’
       enable optimization of unbounded parameters by attempting to pass
!      non ‘VAR’ unbounded parameters by reference.  This optimization
       avoids the implicit copy inside the callee procedure.  GNU Modula-2
       will only allow unbounded parameters to be passed by reference if,
       inside the callee procedure, they are not written to, no address is
!      calculated on the array and it is not passed as a ‘VAR’ parameter.
       Note that it is possible to write code to break this optimization,
       therefore this option should be used carefully.  For example it
       would be possible to take the address of an array, pass the address
*************** supported:
*** 541,582 ****
       and write to the location using the address parameter.
  
       Due to the dangerous nature of this option it is not enabled when
!      the '-O' option is specified.
  
! '-fuse-list=filename'
!      if '-fscaffold-static' is enabled then use the file 'filename' for
       the initialization order of modules.  Whereas if
!      '-fscaffold-dynamic' is enabled then use this file to force linking
       of all module ctors.  This option cannot be used if
!      '-fgen-module-list=' is enabled.
  
! '-fwholediv'
       generate code to detect whole number division by zero or modulus by
       zero.
  
! '-fwholevalue'
       generate code to detect whole number overflow and underflow.
  
! '-Wcase-enum'
!      generate a warning if a 'CASE' statement selects on an enumerated
!      type expression and the statement is missing one or more 'CASE'
!      labels.  No warning is issued if the 'CASE' statement has a default
!      'ELSE' clause.  The option '-Wall' will turn on this flag.
  
! '-Wuninit-variable-checking'
       issue a warning if a variable is used before it is initialized.
       The checking only occurs in the first basic block in each
       procedure.  It does not check parameters, array types or set types.
  
! '-Wuninit-variable-checking=all,known,cond'
       issue a warning if a variable is used before it is initialized.
       The checking will only occur in the first basic block in each
!      procedure if 'known' is specified.  If 'cond' or 'all' is specified
       then checking continues into conditional branches of the flow
       graph.  All checking will stop when a procedure call is invoked or
!      the top of a loop is encountered.  The option '-Wall' will turn on
!      this flag with '-Wuninit-variable-checking=known'.  The
!      '-Wuninit-variable-checking=all' will increase compile time.
  
  
  File: m2.info,  Node: Linking,  Next: Elementary data types,  Prev: Compiler options,  Up: Using
--- 541,582 ----
       and write to the location using the address parameter.
  
       Due to the dangerous nature of this option it is not enabled when
!      the ‘-O’ option is specified.
  
! ‘-fuse-list=filename’
!      if ‘-fscaffold-static’ is enabled then use the file ‘filename’ for
       the initialization order of modules.  Whereas if
!      ‘-fscaffold-dynamic’ is enabled then use this file to force linking
       of all module ctors.  This option cannot be used if
!      ‘-fgen-module-list=’ is enabled.
  
! ‘-fwholediv’
       generate code to detect whole number division by zero or modulus by
       zero.
  
! ‘-fwholevalue’
       generate code to detect whole number overflow and underflow.
  
! ‘-Wcase-enum’
!      generate a warning if a ‘CASE’ statement selects on an enumerated
!      type expression and the statement is missing one or more ‘CASE’
!      labels.  No warning is issued if the ‘CASE’ statement has a default
!      ‘ELSE’ clause.  The option ‘-Wall’ will turn on this flag.
  
! ‘-Wuninit-variable-checking’
       issue a warning if a variable is used before it is initialized.
       The checking only occurs in the first basic block in each
       procedure.  It does not check parameters, array types or set types.
  
! ‘-Wuninit-variable-checking=all,known,cond’
       issue a warning if a variable is used before it is initialized.
       The checking will only occur in the first basic block in each
!      procedure if ‘known’ is specified.  If ‘cond’ or ‘all’ is specified
       then checking continues into conditional branches of the flow
       graph.  All checking will stop when a procedure call is invoked or
!      the top of a loop is encountered.  The option ‘-Wall’ will turn on
!      this flag with ‘-Wuninit-variable-checking=known’.  The
!      ‘-Wuninit-variable-checking=all’ will increase compile time.
  
  
  File: m2.info,  Node: Linking,  Next: Elementary data types,  Prev: Compiler options,  Up: Using
*************** File: m2.info,  Node: Linking,  Next: El
*** 584,604 ****
  This section describes the linking related options.  There are three
  linking strategies available which are dynamic scaffold, static scaffold
  and user defined.  The dynamic scaffold is enabled by default and each
! module will register itself to the run time 'M2RTS' via a constructor.
! The static scaffold mechanism will invoke each modules '_init' and
! '_finish' function in turn via a sequence of calls from within 'main'.
  Lastly the user defined strategy can be implemented by turning off the
! dynamic and static options via '-fno-scaffold-dynamic' and
! '-fno-scaffold-static'.
  
     In the simple test below:
  
       $ gm2 hello.mod
  
!    the driver will add the options '-fscaffold-dynamic' and
! '-fgen-module-list=-' which generate a list of application modules and
! also creates the 'main' function with calls to 'M2RTS'.  It can be
! useful to add the option '-fsources' which displays the source files as
  they are parsed and summarizes whether the source file is required for
  compilation or linking.
  
--- 584,604 ----
  This section describes the linking related options.  There are three
  linking strategies available which are dynamic scaffold, static scaffold
  and user defined.  The dynamic scaffold is enabled by default and each
! module will register itself to the run time ‘M2RTS’ via a constructor.
! The static scaffold mechanism will invoke each modules ‘_init’ and
! ‘_finish’ function in turn via a sequence of calls from within ‘main’.
  Lastly the user defined strategy can be implemented by turning off the
! dynamic and static options via ‘-fno-scaffold-dynamic’ and
! ‘-fno-scaffold-static’.
  
     In the simple test below:
  
       $ gm2 hello.mod
  
!    the driver will add the options ‘-fscaffold-dynamic’ and
! ‘-fgen-module-list=-’ which generate a list of application modules and
! also creates the ‘main’ function with calls to ‘M2RTS’.  It can be
! useful to add the option ‘-fsources’ which displays the source files as
  they are parsed and summarizes whether the source file is required for
  compilation or linking.
  
*************** then you could use these steps:
*** 608,617 ****
       $ gm2 -c -fscaffold-main hello.mod
       $ gm2 hello.o
  
!    The '-fscaffold-main' informs the compiler to generate the 'main'
  function and scaffold.  You can enable the environment variable
! 'GCC_M2LINK_RTFLAG' to trace the construction and destruction of the
! application.  The values for 'GCC_M2LINK_RTFLAG' are shown in the table
  below:
  
       value   | meaning
--- 608,617 ----
       $ gm2 -c -fscaffold-main hello.mod
       $ gm2 hello.o
  
!    The ‘-fscaffold-main’ informs the compiler to generate the ‘main’
  function and scaffold.  You can enable the environment variable
! ‘GCC_M2LINK_RTFLAG’ to trace the construction and destruction of the
! application.  The values for ‘GCC_M2LINK_RTFLAG’ are shown in the table
  below:
  
       value   | meaning
*************** below:
*** 631,638 ****
     One of the advantages of the dynamic scaffold is that the driver
  behaves in a similar way to the other front end drivers.  For example
  consider a small project consisting of 4 definition implementation
! modules ('a.def', 'a.mod', 'b.def', 'b.mod', 'c.def', 'c.mod', 'd.def',
! 'd.mod') and a program module 'program.mod'.
  
     To link this project we could:
  
--- 631,638 ----
     One of the advantages of the dynamic scaffold is that the driver
  behaves in a similar way to the other front end drivers.  For example
  consider a small project consisting of 4 definition implementation
! modules (‘a.def’, ‘a.mod’, ‘b.def’, ‘b.mod’, ‘c.def’, ‘c.mod’, ‘d.def’,
! ‘d.mod’) and a program module ‘program.mod’.
  
     To link this project we could:
  
*************** order in which the corresponding separat
*** 648,655 ****
  of their import lists.
  
     However, if required, you can override this using
! '-fruntime-modules=a,b,c,d' for example which forces the initialization
! sequence to 'a', 'b', 'c' and 'd'.
  
  
  File: m2.info,  Node: Elementary data types,  Next: Standard procedures,  Prev: Linking,  Up: Using
--- 648,655 ----
  of their import lists.
  
     However, if required, you can override this using
! ‘-fruntime-modules=a,b,c,d’ for example which forces the initialization
! sequence to ‘a’, ‘b’, ‘c’ and ‘d’.
  
  
  File: m2.info,  Node: Elementary data types,  Next: Standard procedures,  Prev: Linking,  Up: Using
*************** This section describes the elementary da
*** 661,670 ****
  Modula-2.  It also describes the relationship between these data types
  and the equivalent C data types.
  
!    The following data types are supported: 'INTEGER', 'LONGINT',
! 'SHORTINT', 'CARDINAL', 'LONGCARD', 'SHORTCARD', 'BOOLEAN', 'REAL',
! 'LONGREAL', 'SHORTREAL', 'COMPLEX', 'LONGCOMPLEX', 'SHORTCOMPLEX' and
! 'CHAR'.
  
     An equivalence table is given below:
  
--- 661,670 ----
  Modula-2.  It also describes the relationship between these data types
  and the equivalent C data types.
  
!    The following data types are supported: ‘INTEGER’, ‘LONGINT’,
! ‘SHORTINT’, ‘CARDINAL’, ‘LONGCARD’, ‘SHORTCARD’, ‘BOOLEAN’, ‘REAL’,
! ‘LONGREAL’, ‘SHORTREAL’, ‘COMPLEX’, ‘LONGCOMPLEX’, ‘SHORTCOMPLEX’ and
! ‘CHAR’.
  
     An equivalence table is given below:
  
*************** and the equivalent C data types.
*** 686,692 ****
       LONGCOMPLEX               complex long double
  
     Note that GNU Modula-2 also supports fixed sized data types which are
! exported from the 'SYSTEM' module.  *Note (gm2)The PIM system module::.
  *Note (gm2)The ISO system module::.
  
  
--- 686,692 ----
       LONGCOMPLEX               complex long double
  
     Note that GNU Modula-2 also supports fixed sized data types which are
! exported from the ‘SYSTEM’ module.  *Note (gm2)The PIM system module::.
  *Note (gm2)The ISO system module::.
  
  
*************** visible.
*** 702,712 ****
  -------------------------------------------------------------
  
  The following procedures are implemented and conform with Programming in
! Modula-2 and ISO Modula-2: 'NEW', 'DISPOSE', 'INC', 'DEC', 'INCL',
! 'EXCL' and 'HALT'.  The standard functions are: 'ABS', 'CAP', 'CHR',
! 'FLOAT', 'HIGH', 'LFLOAT', 'LTRUNC', 'MIN', 'MAX', 'ODD', 'SFLOAT',
! 'STRUNC' 'TRUNC' and 'VAL'.  All these functions and procedures (except
! 'HALT', 'NEW', 'DISPOSE' and, under non constant conditions, 'LENGTH')
  generate in-line code for efficiency.
  
  
--- 702,712 ----
  -------------------------------------------------------------
  
  The following procedures are implemented and conform with Programming in
! Modula-2 and ISO Modula-2: ‘NEW’, ‘DISPOSE’, ‘INC’, ‘DEC’, ‘INCL’,
! ‘EXCL’ and ‘HALT’.  The standard functions are: ‘ABS’, ‘CAP’, ‘CHR’,
! ‘FLOAT’, ‘HIGH’, ‘LFLOAT’, ‘LTRUNC’, ‘MIN’, ‘MAX’, ‘ODD’, ‘SFLOAT’,
! ‘STRUNC’ ‘TRUNC’ and ‘VAL’.  All these functions and procedures (except
! ‘HALT’, ‘NEW’, ‘DISPOSE’ and, under non constant conditions, ‘LENGTH’)
  generate in-line code for efficiency.
  
  
*************** generate in-line code for efficiency.
*** 953,959 ****
  2.4.2 ISO specific standard procedures and functions
  ----------------------------------------------------
  
! The standard function 'LENGTH' is specific to ISO Modula-2 and is
  defined as:
  
  
--- 953,959 ----
  2.4.2 ISO specific standard procedures and functions
  ----------------------------------------------------
  
! The standard function ‘LENGTH’ is specific to ISO Modula-2 and is
  defined as:
  
  
*************** defined as:
*** 980,988 ****
  
       PROCEDURE LENGTH (a: ARRAY OF CHAR) : CARDINAL ;
  
!    This function is evaluated at compile time, providing that string 'a'
! is a constant.  If 'a' cannot be evaluated then a call is made to
! 'M2RTS.Length'.
  
  
       (*
--- 980,988 ----
  
       PROCEDURE LENGTH (a: ARRAY OF CHAR) : CARDINAL ;
  
!    This function is evaluated at compile time, providing that string ‘a’
! is a constant.  If ‘a’ cannot be evaluated then a call is made to
! ‘M2RTS.Length’.
  
  
       (*
*************** File: m2.info,  Node: High procedure fun
*** 1008,1029 ****
  ===========================================
  
  This section describes the behavior of the standard procedure function
! 'HIGH' and it includes a table of parameters with the expected return
  result.  The standard procedure function will return the last accessible
! indice of an 'ARRAY'.  If the parameter to 'HIGH' is a static array then
! the result will be a 'CARDINAL' value matching the upper bound in the
! 'ARRAY' declaration.
  
     The section also describes the behavior of a string literal actual
! parameter and how it relates to 'HIGH'.  The PIM2, PIM3, PIM4 and ISO
! standard is silent on the issue of whether a 'nul' is present in an
! 'ARRAY' 'OF' 'CHAR' actual parameter.
  
!    If the first parameter to 'HIGH' is an unbounded 'ARRAY' the return
! value from 'HIGH' will be the last accessible element in the array.  If
  a constant string literal is passed as an actual parameter then it will
! be 'nul' terminated.  The table and example code below describe the
! effect of passing an actual parameter and the expected 'HIGH' value.
  
       MODULE example1 ;
  
--- 1008,1029 ----
  ===========================================
  
  This section describes the behavior of the standard procedure function
! ‘HIGH’ and it includes a table of parameters with the expected return
  result.  The standard procedure function will return the last accessible
! indice of an ‘ARRAY’.  If the parameter to ‘HIGH’ is a static array then
! the result will be a ‘CARDINAL’ value matching the upper bound in the
! ‘ARRAY’ declaration.
  
     The section also describes the behavior of a string literal actual
! parameter and how it relates to ‘HIGH’.  The PIM2, PIM3, PIM4 and ISO
! standard is silent on the issue of whether a ‘nul’ is present in an
! ‘ARRAY’ ‘OF’ ‘CHAR’ actual parameter.
  
!    If the first parameter to ‘HIGH’ is an unbounded ‘ARRAY’ the return
! value from ‘HIGH’ will be the last accessible element in the array.  If
  a constant string literal is passed as an actual parameter then it will
! be ‘nul’ terminated.  The table and example code below describe the
! effect of passing an actual parameter and the expected ‘HIGH’ value.
  
       MODULE example1 ;
  
*************** effect of passing an actual parameter an
*** 1051,1060 ****
        '12'            | 2        | TRUE
        '123'           | 3        | TRUE
  
!    A constant string literal will be passed to an 'ARRAY' 'OF' 'CHAR'
! with an appended 'nul' 'CHAR'.  Thus if the constant string literal ''''
  is passed as an actual parameter (in example1) then the result from
! 'HIGH(a)' will be '0'.
  
       MODULE example2 ;
  
--- 1051,1060 ----
        '12'            | 2        | TRUE
        '123'           | 3        | TRUE
  
!    A constant string literal will be passed to an ‘ARRAY’ ‘OF’ ‘CHAR’
! with an appended ‘nul’ ‘CHAR’.  Thus if the constant string literal ‘''’
  is passed as an actual parameter (in example1) then the result from
! ‘HIGH(a)’ will be ‘0’.
  
       MODULE example2 ;
  
*************** Modula-2 language as defined in ISO/IEC
*** 1109,1127 ****
  programming languages - part 1: Modula-2 Language, ISO/IEC 10514-1
  (1996) (ISO).
  
!    The command line switches '-fpim2', '-fpim3', '-fpim4' and '-fiso'
  can be used to force mutually exclusive features.  However by default
  the compiler will not aggressively fail if a non mutually exclusive
  feature is used from another dialect.  For example it is possible to
! specify '-fpim2' and still utilize 'DEFINITION' 'MODULES' which have no
  export list.
  
     Some dialect differences will force a compile time error, for example
! in PIM2 the user must 'IMPORT' 'SIZE' from the module 'SYSTEM', whereas
! in PIM3 and PIM4 'SIZE' is a pervasive function.  Thus compiling PIM4
! source code with the '-fpim2' switch will cause a compile time error.
! This can be fixed quickly with an additional 'IMPORT' or alternatively
! by compiling with the '-fpim4' switch.
  
     However there are some very important differences between the
  dialects which are mutually exclusive and therefore it is vital that
--- 1109,1127 ----
  programming languages - part 1: Modula-2 Language, ISO/IEC 10514-1
  (1996) (ISO).
  
!    The command line switches ‘-fpim2’, ‘-fpim3’, ‘-fpim4’ and ‘-fiso’
  can be used to force mutually exclusive features.  However by default
  the compiler will not aggressively fail if a non mutually exclusive
  feature is used from another dialect.  For example it is possible to
! specify ‘-fpim2’ and still utilize ‘DEFINITION’ ‘MODULES’ which have no
  export list.
  
     Some dialect differences will force a compile time error, for example
! in PIM2 the user must ‘IMPORT’ ‘SIZE’ from the module ‘SYSTEM’, whereas
! in PIM3 and PIM4 ‘SIZE’ is a pervasive function.  Thus compiling PIM4
! source code with the ‘-fpim2’ switch will cause a compile time error.
! This can be fixed quickly with an additional ‘IMPORT’ or alternatively
! by compiling with the ‘-fpim4’ switch.
  
     However there are some very important differences between the
  dialects which are mutually exclusive and therefore it is vital that
*************** used.
*** 1132,1138 ****
  ---------------------------------------------
  
  The most dangerous set of mutually exclusive features found in the four
! dialects supported by GNU Modula-2 are the 'INTEGER' division, remainder
  and modulus arithmetic operators.  It is important to note that the same
  source code can be compiled to give different run time results depending
  upon these switches!  The reference manual for the various dialects of
--- 1132,1138 ----
  ---------------------------------------------
  
  The most dangerous set of mutually exclusive features found in the four
! dialects supported by GNU Modula-2 are the ‘INTEGER’ division, remainder
  and modulus arithmetic operators.  It is important to note that the same
  source code can be compiled to give different run time results depending
  upon these switches!  The reference manual for the various dialects of
*************** File: m2.info,  Node: Exceptions,  Next:
*** 1164,1188 ****
  
  This section describes how exceptions are implemented in GNU Modula-2
  and how command line switches affect their behavior.  The option
! '-fsoft-check-all' enables all software checking of nil dereferences,
  division by zero etc.  Additional code is produced to check these
  conditions and exception handlers are invoked if the conditions prevail.
  
!    Without '-fsoft-check-all' these exceptions will be caught by
  hardware (assuming the hardware support exists) and a signal handler is
! invoked.  The signal handler will in turn 'THROW' an exception which
  will be caught by the appropriate Modula-2 handler.  However the action
  of throwing an exception from within a signal handler is implementation
  defined (according to the C++ documentation).  For example on the x86_64
  architecture this works whereas on the i686 architecture it does not.
  Therefore to ensure portability it is recommended to use
! '-fsoft-check-all'.
  
     (1)
  
     ---------- Footnotes ----------
  
!    (1) '-fsoft-check-all' can be effectively combined with '-O2' to
  semantically analyze source code for possible run time errors at compile
  time.
  
--- 1164,1188 ----
  
  This section describes how exceptions are implemented in GNU Modula-2
  and how command line switches affect their behavior.  The option
! ‘-fsoft-check-all’ enables all software checking of nil dereferences,
  division by zero etc.  Additional code is produced to check these
  conditions and exception handlers are invoked if the conditions prevail.
  
!    Without ‘-fsoft-check-all’ these exceptions will be caught by
  hardware (assuming the hardware support exists) and a signal handler is
! invoked.  The signal handler will in turn ‘THROW’ an exception which
  will be caught by the appropriate Modula-2 handler.  However the action
  of throwing an exception from within a signal handler is implementation
  defined (according to the C++ documentation).  For example on the x86_64
  architecture this works whereas on the i686 architecture it does not.
  Therefore to ensure portability it is recommended to use
! ‘-fsoft-check-all’.
  
     (1)
  
     ---------- Footnotes ----------
  
!    (1) ‘-fsoft-check-all’ can be effectively combined with ‘-O2’ to
  semantically analyze source code for possible run time errors at compile
  time.
  
*************** Consider the following program:
*** 1213,1219 ****
       END assignvalue.
  
     here we see that the programmer has overlooked that the return value
! from 'bad' will cause an overflow to 'foo'.  If we compile the code with
  the following options:
  
       $ gm2 -g -fsoft-check-all -O2 -c assignvalue.mod
--- 1213,1219 ----
       END assignvalue.
  
     here we see that the programmer has overlooked that the return value
! from ‘bad’ will cause an overflow to ‘foo’.  If we compile the code with
  the following options:
  
       $ gm2 -g -fsoft-check-all -O2 -c assignvalue.mod
*************** the following options:
*** 1222,1233 ****
  
     The gm2 semantic plugin is automatically run and will generate a
  warning message for every exception call which is known as reachable.
! It is highly advised to run the optimizer ('-O2' or '-O3') with
! '-fsoft-check-all' so that the compiler is able to run the optimizer and
  perform variable and flow analysis before the semantic plugin is
  invoked.
  
!    The '-Wuninit-variable-checking' can be used to identify
  uninitialized variables within the first basic block in a procedure.
  The checking is limited to variables so long as they are not an array or
  set or a variant record or var parameter.
--- 1222,1233 ----
  
     The gm2 semantic plugin is automatically run and will generate a
  warning message for every exception call which is known as reachable.
! It is highly advised to run the optimizer (‘-O2’ or ‘-O3’) with
! ‘-fsoft-check-all’ so that the compiler is able to run the optimizer and
  perform variable and flow analysis before the semantic plugin is
  invoked.
  
!    The ‘-Wuninit-variable-checking’ can be used to identify
  uninitialized variables within the first basic block in a procedure.
  The checking is limited to variables so long as they are not an array or
  set or a variant record or var parameter.
*************** uninitialized.
*** 1294,1300 ****
       END testwithnoptr.
  
     The following example detects a record is uninitialized via a pointer
! variable in a 'WITH' block.
  
       $ gm2 -g -c -Wuninit-variable-checking testwithnoptr.mod
       testwithnoptr.mod:21:8: warning: In procedure ‘test’: attempting to
--- 1294,1300 ----
       END testwithnoptr.
  
     The following example detects a record is uninitialized via a pointer
! variable in a ‘WITH’ block.
  
       $ gm2 -g -c -Wuninit-variable-checking testwithnoptr.mod
       testwithnoptr.mod:21:8: warning: In procedure ‘test’: attempting to
*************** File: m2.info,  Node: Extensions,  Next:
*** 1344,1361 ****
  
  This section introduces the GNU Modula-2 language extensions.  The GNU
  Modula-2 compiler allows abstract data types to be any type, not just
! restricted to a pointer type providing the '-fextended-opaque' option is
  supplied *Note (gm2)Compiler options::.
  
     Declarations can be made in any order, whether they are types,
  constants, procedures, nested modules or variables.
  
!    GNU Modula-2 also allows programmers to interface to 'C' and assembly
  language.
  
!    GNU Modula-2 provides support for the special tokens '__LINE__',
! '__FILE__', '__FUNCTION__' and '__DATE__'.  Support for these tokens
! will occur even if the '-fcpp' option is not supplied.  A table of these
  identifiers and their data type and values is given below:
  
       Scope       GNU Modula-2 token      Data type and example value
--- 1344,1361 ----
  
  This section introduces the GNU Modula-2 language extensions.  The GNU
  Modula-2 compiler allows abstract data types to be any type, not just
! restricted to a pointer type providing the ‘-fextended-opaque’ option is
  supplied *Note (gm2)Compiler options::.
  
     Declarations can be made in any order, whether they are types,
  constants, procedures, nested modules or variables.
  
!    GNU Modula-2 also allows programmers to interface to ‘C’ and assembly
  language.
  
!    GNU Modula-2 provides support for the special tokens ‘__LINE__’,
! ‘__FILE__’, ‘__FUNCTION__’ and ‘__DATE__’.  Support for these tokens
! will occur even if the ‘-fcpp’ option is not supplied.  A table of these
  identifiers and their data type and values is given below:
  
       Scope       GNU Modula-2 token      Data type and example value
*************** identifiers and their data type and valu
*** 1392,1405 ****
                                           is 1.
  
  
!    The preprocessor 'cpp' can be invoked via the '-fcpp' command line
! option.  This in turn invokes 'cpp' with the following arguments
! '-traditional -lang-asm'.  These options preserve comments and all
! quotations.  'gm2' treats a '#' character in the first column as a
  preprocessor directive.
  
!    For example here is a module which calls 'FatalError' via the macro
! 'ERROR'.
  
       MODULE cpp ;
  
--- 1392,1405 ----
                                           is 1.
  
  
!    The preprocessor ‘cpp’ can be invoked via the ‘-fcpp’ command line
! option.  This in turn invokes ‘cpp’ with the following arguments
! ‘-traditional -lang-asm’.  These options preserve comments and all
! quotations.  ‘gm2’ treats a ‘#’ character in the first column as a
  preprocessor directive.
  
!    For example here is a module which calls ‘FatalError’ via the macro
! ‘ERROR’.
  
       MODULE cpp ;
  
*************** preprocessor directive.
*** 1428,1438 ****
       END cpp.
  
     Another use for the C preprocessor in Modula-2 might be to turn on
! debugging code.  For example the library module 'FormatStrings.mod' uses
! procedures from 'DynamicStrings.mod' and to track down memory leaks it
  was useful to track the source file and line where each string was
! created.  Here is a section of 'FormatStrings.mod' which shows how the
! debugging code was enabled and disabled by adding '-fcpp' to the command
  line.
  
       FROM DynamicStrings IMPORT String, InitString, InitStringChar, Mark,
--- 1428,1438 ----
       END cpp.
  
     Another use for the C preprocessor in Modula-2 might be to turn on
! debugging code.  For example the library module ‘FormatStrings.mod’ uses
! procedures from ‘DynamicStrings.mod’ and to track down memory leaks it
  was useful to track the source file and line where each string was
! created.  Here is a section of ‘FormatStrings.mod’ which shows how the
! debugging code was enabled and disabled by adding ‘-fcpp’ to the command
  line.
  
       FROM DynamicStrings IMPORT String, InitString, InitStringChar, Mark,
*************** line.
*** 1483,1491 ****
          RETURN s
       END Sprintf1 ;
  
!    It is worth noting that the overhead of this code once '-fcpp' is not
  present and -O2 is used will be zero since the local empty procedures
! 'DSdbEnter' and 'DSdbExit' will be thrown away by the optimization
  passes of the GCC backend.
  
  2.9.1 Optional procedure parameter
--- 1483,1491 ----
          RETURN s
       END Sprintf1 ;
  
!    It is worth noting that the overhead of this code once ‘-fcpp’ is not
  present and -O2 is used will be zero since the local empty procedures
! ‘DSdbEnter’ and ‘DSdbExit’ will be thrown away by the optimization
  passes of the GCC backend.
  
  2.9.1 Optional procedure parameter
*************** passes of the GCC backend.
*** 1493,1501 ****
  
  GNU Modula-2 allows the last parameter to a procedure or function
  parameter to be optional.  For example in the ISO library
! 'COROUTINES.def' the procedure 'NEWCOROUTINE' is defined as having an
! optional fifth argument ('initProtection') which, if absent, is
! automatically replaced by 'NIL'.
  
       PROCEDURE NEWCOROUTINE (procBody: PROC; workspace: SYSTEM.ADDRESS;
                               size: CARDINAL; VAR cr: COROUTINE;
--- 1493,1501 ----
  
  GNU Modula-2 allows the last parameter to a procedure or function
  parameter to be optional.  For example in the ISO library
! ‘COROUTINES.def’ the procedure ‘NEWCOROUTINE’ is defined as having an
! optional fifth argument (‘initProtection’) which, if absent, is
! automatically replaced by ‘NIL’.
  
       PROCEDURE NEWCOROUTINE (procBody: PROC; workspace: SYSTEM.ADDRESS;
                               size: CARDINAL; VAR cr: COROUTINE;
*************** automatically replaced by 'NIL'.
*** 1511,1517 ****
            which specifies the initial protection level of the coroutine.
         *)
  
!    The implementation module 'COROUTINES.mod' implements this procedure
  using the following syntax:
  
       PROCEDURE NEWCOROUTINE (procBody: PROC; workspace: SYSTEM.ADDRESS;
--- 1511,1517 ----
            which specifies the initial protection level of the coroutine.
         *)
  
!    The implementation module ‘COROUTINES.mod’ implements this procedure
  using the following syntax:
  
       PROCEDURE NEWCOROUTINE (procBody: PROC; workspace: SYSTEM.ADDRESS;
*************** using the following syntax:
*** 1522,1529 ****
       END NEWCOROUTINE ;
  
     Note that it is illegal for this declaration to contain an
! initializer value for 'initProtection'.  However it is necessary to
! surround this parameter with the brackets '[' and ']'.  This serves to
  remind the programmer that the last parameter was declared as optional
  in the definition module.
  
--- 1522,1529 ----
       END NEWCOROUTINE ;
  
     Note that it is illegal for this declaration to contain an
! initializer value for ‘initProtection’.  However it is necessary to
! surround this parameter with the brackets ‘[’ and ‘]’.  This serves to
  remind the programmer that the last parameter was declared as optional
  in the definition module.
  
*************** in which case the initializer is mandato
*** 1532,1538 ****
  program module.
  
     GNU Modula-2 also provides additional fixed sized data types which
! are all exported from the 'SYSTEM' module.  *Note (gm2)The PIM system
  module::.  *Note (gm2)The ISO system module::.
  
  
--- 1532,1538 ----
  program module.
  
     GNU Modula-2 also provides additional fixed sized data types which
! are all exported from the ‘SYSTEM’ module.  *Note (gm2)The PIM system
  module::.  *Note (gm2)The ISO system module::.
  
  
*************** PIM type compatibility see Programming i
*** 1611,1617 ****
  Modula-2 restricts the types of expressions to the same type.
  Expression compatibility is a symmetric relation.
  
!    For example two sub expressions of 'INTEGER' and 'CARDINAL' are not
  expression compatible
  ( and ISO Modula-2).
  
--- 1611,1617 ----
  Modula-2 restricts the types of expressions to the same type.
  Expression compatibility is a symmetric relation.
  
!    For example two sub expressions of ‘INTEGER’ and ‘CARDINAL’ are not
  expression compatible
  ( and ISO Modula-2).
  
*************** data types (imported from SYSTEM).
*** 1622,1655 ****
  -------------------------------
  
  This section discusses the assignment issues surrounding assignment
! compatibility of elementary types ('INTEGER', 'CARDINAL', 'REAL' and
! 'CHAR' for example).  The information here is found in more detail in
  the Modula-2 ISO standard BS ISO/IEC 10514-1:1996 page 122.
  
     Assignment compatibility exists between the same sized elementary
  types.
  
     Same type family of different sizes are also compatible as long as
! the 'MAX('type')' and 'MIN('type')' is known.  So for example this
! includes the 'INTEGER' family, 'CARDINAL' family and the 'REAL' family.
  
     The reason for this is that when the assignment is performed the
  compiler will check to see that the expression (on the right of the
! ':=') lies within the range of the designator type (on the left hand
! side of the ':=').  Thus these ordinal types can be assignment
! compatible.  However it does mean that 'WORD32' is not compatible with
! 'WORD16' as 'WORD32' does not have a minimum or maximum value and
  therefore cannot be checked.  The compiler does not know which of the
! two bytes from 'WORD32' should be copied into 'WORD16' and which two
! should be ignored.  Currently the types 'BITSET8', 'BITSET16' and
! 'BITSET32' are assignment incompatible.  However this restriction maybe
  lifted when further run time checking is achieved.
  
!    Modula-2 does allow 'INTEGER' to be assignment compatible with 'WORD'
! as they are the same size.  Likewise GNU Modula-2 allows 'INTEGER16' to
! be compatible with 'WORD16' and the same for the other fixed sized types
! and their sized equivalent in either 'WORD'n, 'BYTE' or 'LOC' types.
! However it prohibits assignment between 'WORD' and 'WORD32' even though
  on many systems these sizes will be the same.  The reasoning behind this
  rule is that the extended fixed sized types are meant to be used by
  applications requiring fixed sized data types and it is more portable to
--- 1622,1655 ----
  -------------------------------
  
  This section discusses the assignment issues surrounding assignment
! compatibility of elementary types (‘INTEGER’, ‘CARDINAL’, ‘REAL’ and
! ‘CHAR’ for example).  The information here is found in more detail in
  the Modula-2 ISO standard BS ISO/IEC 10514-1:1996 page 122.
  
     Assignment compatibility exists between the same sized elementary
  types.
  
     Same type family of different sizes are also compatible as long as
! the ‘MAX(’type‘)’ and ‘MIN(’type‘)’ is known.  So for example this
! includes the ‘INTEGER’ family, ‘CARDINAL’ family and the ‘REAL’ family.
  
     The reason for this is that when the assignment is performed the
  compiler will check to see that the expression (on the right of the
! ‘:=’) lies within the range of the designator type (on the left hand
! side of the ‘:=’).  Thus these ordinal types can be assignment
! compatible.  However it does mean that ‘WORD32’ is not compatible with
! ‘WORD16’ as ‘WORD32’ does not have a minimum or maximum value and
  therefore cannot be checked.  The compiler does not know which of the
! two bytes from ‘WORD32’ should be copied into ‘WORD16’ and which two
! should be ignored.  Currently the types ‘BITSET8’, ‘BITSET16’ and
! ‘BITSET32’ are assignment incompatible.  However this restriction maybe
  lifted when further run time checking is achieved.
  
!    Modula-2 does allow ‘INTEGER’ to be assignment compatible with ‘WORD’
! as they are the same size.  Likewise GNU Modula-2 allows ‘INTEGER16’ to
! be compatible with ‘WORD16’ and the same for the other fixed sized types
! and their sized equivalent in either ‘WORD’n, ‘BYTE’ or ‘LOC’ types.
! However it prohibits assignment between ‘WORD’ and ‘WORD32’ even though
  on many systems these sizes will be the same.  The reasoning behind this
  rule is that the extended fixed sized types are meant to be used by
  applications requiring fixed sized data types and it is more portable to
*************** exceed the type range will result in a c
*** 1668,1680 ****
  ------------------------------
  
  Parameter compatibility is divided into two areas, pass by value and
! pass by reference ('VAR').  In the case of pass by value the rules are
  exactly the same as assignment.  However in the second case, pass by
  reference, the actual parameter and formal parameter must be the same
! size and family.  Furthermore 'INTEGER' and 'CARDINAL's are not treated
  as compatible in the pass by reference case.
  
!    The types 'BYTE', 'LOC', 'WORD' and 'WORD'n derivatives are
  assignment and parameter compatible with any data type of the same size.
  
  
--- 1668,1680 ----
  ------------------------------
  
  Parameter compatibility is divided into two areas, pass by value and
! pass by reference (‘VAR’).  In the case of pass by value the rules are
  exactly the same as assignment.  However in the second case, pass by
  reference, the actual parameter and formal parameter must be the same
! size and family.  Furthermore ‘INTEGER’ and ‘CARDINAL’s are not treated
  as compatible in the pass by reference case.
  
!    The types ‘BYTE’, ‘LOC’, ‘WORD’ and ‘WORD’n derivatives are
  assignment and parameter compatible with any data type of the same size.
  
  
*************** File: m2.info,  Node: Unbounded by refer
*** 1686,1692 ****
  This section documents a GNU Modula-2 compiler switch which implements a
  language optimization surrounding the implementation of unbounded
  arrays.  In GNU Modula-2 the unbounded array is implemented by utilizing
! an internal structure 'struct {dataType *address, unsigned int high}'.
  So given the Modula-2 procedure declaration:
  
       PROCEDURE foo (VAR a: ARRAY OF dataType) ;
--- 1686,1692 ----
  This section documents a GNU Modula-2 compiler switch which implements a
  language optimization surrounding the implementation of unbounded
  arrays.  In GNU Modula-2 the unbounded array is implemented by utilizing
! an internal structure ‘struct {dataType *address, unsigned int high}’.
  So given the Modula-2 procedure declaration:
  
       PROCEDURE foo (VAR a: ARRAY OF dataType) ;
*************** So given the Modula-2 procedure declarat
*** 1694,1700 ****
          IF a[2]= (* etc *)
       END foo ;
  
!    it is translated into GCC 'tree's, which can be represented in their
  C form thus:
  
       void foo (struct {dataType *address, unsigned int high} a)
--- 1694,1700 ----
          IF a[2]= (* etc *)
       END foo ;
  
!    it is translated into GCC ‘tree’s, which can be represented in their
  C form thus:
  
       void foo (struct {dataType *address, unsigned int high} a)
*************** C form thus:
*** 1702,1708 ****
          if (a.address[2] == /* etc */
       }
  
!    Whereas if the procedure 'foo' was declared as:
  
       PROCEDURE foo (a: ARRAY OF dataType) ;
       BEGIN
--- 1702,1708 ----
          if (a.address[2] == /* etc */
       }
  
!    Whereas if the procedure ‘foo’ was declared as:
  
       PROCEDURE foo (a: ARRAY OF dataType) ;
       BEGIN
*************** C form thus:
*** 1710,1716 ****
       END foo ;
  
     then it is implemented by being translated into the following GCC
! 'tree's, which can be represented in their C form thus:
  
       void foo (struct {dataType *address, unsigned int high} a)
       {
--- 1710,1716 ----
       END foo ;
  
     then it is implemented by being translated into the following GCC
! ‘tree’s, which can be represented in their C form thus:
  
       void foo (struct {dataType *address, unsigned int high} a)
       {
*************** C form thus:
*** 1723,1739 ****
  
     This implementation works, but it makes a copy of each non VAR
  unbounded array when a procedure is entered.  If the unbounded array is
! not changed during procedure 'foo' then this implementation will be very
! inefficient.  In effect Modula-2 lacks the 'REF' keyword of Ada.
  Consequently the programmer maybe tempted to sacrifice semantic clarity
! for greater efficiency by declaring the parameter using the 'VAR'
! keyword in place of 'REF'.
  
!    The '-funbounded-by-reference' switch instructs the compiler to check
  and see if the programmer is modifying the content of any unbounded
  array.  If it is modified then a copy will be made upon entry into the
  procedure.  Conversely if the content is only read and never modified
! then this non 'VAR' unbounded array is a candidate for being passed by
  reference.  It is only a candidate as it is still possible that passing
  this parameter by reference could alter the meaning of the source code.
  For example consider the following case:
--- 1723,1739 ----
  
     This implementation works, but it makes a copy of each non VAR
  unbounded array when a procedure is entered.  If the unbounded array is
! not changed during procedure ‘foo’ then this implementation will be very
! inefficient.  In effect Modula-2 lacks the ‘REF’ keyword of Ada.
  Consequently the programmer maybe tempted to sacrifice semantic clarity
! for greater efficiency by declaring the parameter using the ‘VAR’
! keyword in place of ‘REF’.
  
!    The ‘-funbounded-by-reference’ switch instructs the compiler to check
  and see if the programmer is modifying the content of any unbounded
  array.  If it is modified then a copy will be made upon entry into the
  procedure.  Conversely if the content is only read and never modified
! then this non ‘VAR’ unbounded array is a candidate for being passed by
  reference.  It is only a candidate as it is still possible that passing
  this parameter by reference could alter the meaning of the source code.
  For example consider the following case:
*************** For example consider the following case:
*** 1751,1768 ****
          StrConCat(a, a, a)
       END foo ;
  
!    In the code above we see that the same parameter, 'a', is being
! passed three times to 'StrConCat'.  Clearly even though parameters 'b'
! and 'c' are never modified it would be incorrect to implement them as
  pass by reference.  Therefore the compiler checks to see if any non
! 'VAR' parameter is type compatible with any 'VAR' parameter and if so it
  generates run time procedure entry checks to determine whether the
! contents of parameters 'b' or 'c' matches the contents of 'a'.  If a
! match is detected then a copy is made and the 'address' in the unbounded
! 'struct'ure is modified.
  
     The compiler will check the address range of each candidate against
! the address range of any 'VAR' parameter, providing they are type
  compatible.  For example consider:
  
       PROCEDURE foo (a: ARRAY OF BYTE; VAR f: REAL) ;
--- 1751,1768 ----
          StrConCat(a, a, a)
       END foo ;
  
!    In the code above we see that the same parameter, ‘a’, is being
! passed three times to ‘StrConCat’.  Clearly even though parameters ‘b’
! and ‘c’ are never modified it would be incorrect to implement them as
  pass by reference.  Therefore the compiler checks to see if any non
! ‘VAR’ parameter is type compatible with any ‘VAR’ parameter and if so it
  generates run time procedure entry checks to determine whether the
! contents of parameters ‘b’ or ‘c’ matches the contents of ‘a’.  If a
! match is detected then a copy is made and the ‘address’ in the unbounded
! ‘struct’ure is modified.
  
     The compiler will check the address range of each candidate against
! the address range of any ‘VAR’ parameter, providing they are type
  compatible.  For example consider:
  
       PROCEDURE foo (a: ARRAY OF BYTE; VAR f: REAL) ;
*************** compatible.  For example consider:
*** 1780,1788 ****
          foo(r, r)
       END bar ;
  
!    Here we see that although parameter, 'a', is a candidate for the
  passing by reference, it would be incorrect to use this transformation.
! Thus the compiler detects that parameters, 'a' and 'f' are type
  compatible and will produce run time checking code to test whether the
  address range of their respective contents intersect.
  
--- 1780,1788 ----
          foo(r, r)
       END bar ;
  
!    Here we see that although parameter, ‘a’, is a candidate for the
  passing by reference, it would be incorrect to use this transformation.
! Thus the compiler detects that parameters, ‘a’ and ‘f’ are type
  compatible and will produce run time checking code to test whether the
  address range of their respective contents intersect.
  
*************** File: m2.info,  Node: Building a shared
*** 1793,1801 ****
  ==============================
  
  This section describes building a tiny shared library implemented in
! Modula-2 and built with 'libtool'.  Suppose a project consists of two
  definition modules and two implementation modules and a program module
! 'a.def', 'a.mod', 'b.def', 'b.mod' and 'c.mod'.  The first step is to
  compile the modules using position independent code.  This can be
  achieved by the following three commands:
  
--- 1793,1801 ----
  ==============================
  
  This section describes building a tiny shared library implemented in
! Modula-2 and built with ‘libtool’.  Suppose a project consists of two
  definition modules and two implementation modules and a program module
! ‘a.def’, ‘a.mod’, ‘b.def’, ‘b.mod’ and ‘c.mod’.  The first step is to
  compile the modules using position independent code.  This can be
  achieved by the following three commands:
  
*************** also must compile the scaffold.
*** 1812,1825 ****
       gm2 -c -g -fmakeinit -fshared c.mod
       libtool --tag=CC --mode=compile g++ -g -c c_m2.cpp -o c_m2.lo
  
!    The third step is to link all these '.lo' files.
  
       libtool --mode=link gcc -g c_m2.lo a.lo b.lo c.lo \
               -L$(prefix)/lib64 \
               -rpath `pwd` -lgm2 -lstdc++ -lm -o libabc.la
  
!    At this point the shared library 'libabc.so' will have been created
! inside the directory '.libs'.
  
  
  File: m2.info,  Node: Interface for Python,  Next: Producing a Python module,  Prev: Building a shared library,  Up: Using
--- 1812,1825 ----
       gm2 -c -g -fmakeinit -fshared c.mod
       libtool --tag=CC --mode=compile g++ -g -c c_m2.cpp -o c_m2.lo
  
!    The third step is to link all these ‘.lo’ files.
  
       libtool --mode=link gcc -g c_m2.lo a.lo b.lo c.lo \
               -L$(prefix)/lib64 \
               -rpath `pwd` -lgm2 -lstdc++ -lm -o libabc.la
  
!    At this point the shared library ‘libabc.so’ will have been created
! inside the directory ‘.libs’.
  
  
  File: m2.info,  Node: Interface for Python,  Next: Producing a Python module,  Prev: Building a shared library,  Up: Using
*************** to generate all the necessary wrapping t
*** 1835,1846 ****
  language may access the implementation module.
  
     Here is an example of how you might call upon the services of the
! Modula-2 library module 'NumberIO' from Python3.
  
     The following commands can be used to generate the Python3 module:
  
!      export src='directory to the sources'
!      export prefix='directory to where the compiler is installed'
       gm2 -I${src} -c -g -fswig ${src}/../../../gm2-libs/NumberIO.mod
       gm2 -I${src} -c -g -fmakelist ${src}/../../../gm2-libs/NumberIO.mod
  
--- 1835,1846 ----
  language may access the implementation module.
  
     Here is an example of how you might call upon the services of the
! Modula-2 library module ‘NumberIO’ from Python3.
  
     The following commands can be used to generate the Python3 module:
  
!      export src=‘directory to the sources’
!      export prefix=‘directory to where the compiler is installed’
       gm2 -I${src} -c -g -fswig ${src}/../../../gm2-libs/NumberIO.mod
       gm2 -I${src} -c -g -fmakelist ${src}/../../../gm2-libs/NumberIO.mod
  
*************** Modula-2 library module 'NumberIO' from
*** 1866,1879 ****
       cp .libs/libNumberIO.so _NumberIO.so
  
     The first four commands, generate the swig interface file
! 'NumberIO.i' and python wrap files 'NumberIO_wrap.cxx' and
! 'NumberIO.py'.  The next three 'libtool' commnads compile the C++ and
! Modula-2 source code into '.lo' objects.  The last 'libtool' command
! links all the '.lo' files into a '.la' file and includes all shared
  library dependencies.
  
     Now it is possible to run the following Python script (called
! 'testnum.py'):
  
       import NumberIO
  
--- 1866,1879 ----
       cp .libs/libNumberIO.so _NumberIO.so
  
     The first four commands, generate the swig interface file
! ‘NumberIO.i’ and python wrap files ‘NumberIO_wrap.cxx’ and
! ‘NumberIO.py’.  The next three ‘libtool’ commnads compile the C++ and
! Modula-2 source code into ‘.lo’ objects.  The last ‘libtool’ command
! links all the ‘.lo’ files into a ‘.la’ file and includes all shared
  library dependencies.
  
     Now it is possible to run the following Python script (called
! ‘testnum.py’):
  
       import NumberIO
  
*************** library dependencies.
*** 1885,1901 ****
       1234 x 2 = 2468
  
     *Note (gm2)Producing a Python module:: for another example which uses
! the 'UNQUALIFIED' keyword to reduce the module name clutter from the
  viewport of Python3.
  
  2.13.1 Limitations of automatic generated of Swig files
  -------------------------------------------------------
  
  This section discusses the limitations of automatically generating swig
! files.  From the previous example we see that the module 'NumberIO' had
! a swig interface file 'NumberIO.i' automatically generated by the
  compiler.  If we consider three of the procedure definitions in
! 'NumberIO.def' we can see the success and limitations of the automatic
  interface generation.
  
       PROCEDURE StrToHex (a: ARRAY OF CHAR; VAR x: CARDINAL) ;
--- 1885,1901 ----
       1234 x 2 = 2468
  
     *Note (gm2)Producing a Python module:: for another example which uses
! the ‘UNQUALIFIED’ keyword to reduce the module name clutter from the
  viewport of Python3.
  
  2.13.1 Limitations of automatic generated of Swig files
  -------------------------------------------------------
  
  This section discusses the limitations of automatically generating swig
! files.  From the previous example we see that the module ‘NumberIO’ had
! a swig interface file ‘NumberIO.i’ automatically generated by the
  compiler.  If we consider three of the procedure definitions in
! ‘NumberIO.def’ we can see the success and limitations of the automatic
  interface generation.
  
       PROCEDURE StrToHex (a: ARRAY OF CHAR; VAR x: CARDINAL) ;
*************** interface generation.
*** 1913,1929 ****
       extern void NumberIO_ReadInt (int *x);
       /*  parameters: x is unknown */
  
!    In the case of 'StrToHex' it can be seen that the compiler detects
  that the last parameter is an output.  It explicitly tells swig this by
! using the parameter name 'OUTPUT' and in the following comment it
  informs the user that it knows this to be an output parameter.  In the
! second procedure 'StrToInt' it marks the final parameter as an output,
! but it tells the user that this is only a guess.  Finally in 'ReadInt'
! it informs the user that it does not know whether the parameter, 'x', is
  an output, input or an inout parameter.
  
!    The compiler decides whether to mark a parameter as either: 'INPUT',
! 'OUTPUT' or 'INOUT' if it is read before written or visa versa in the
  first basic block.  At this point it will write output that the
  parameter is known.  If it is not read or written in the first basic
  block then subsequent basic blocks are searched and the result is
--- 1913,1929 ----
       extern void NumberIO_ReadInt (int *x);
       /*  parameters: x is unknown */
  
!    In the case of ‘StrToHex’ it can be seen that the compiler detects
  that the last parameter is an output.  It explicitly tells swig this by
! using the parameter name ‘OUTPUT’ and in the following comment it
  informs the user that it knows this to be an output parameter.  In the
! second procedure ‘StrToInt’ it marks the final parameter as an output,
! but it tells the user that this is only a guess.  Finally in ‘ReadInt’
! it informs the user that it does not know whether the parameter, ‘x’, is
  an output, input or an inout parameter.
  
!    The compiler decides whether to mark a parameter as either: ‘INPUT’,
! ‘OUTPUT’ or ‘INOUT’ if it is read before written or visa versa in the
  first basic block.  At this point it will write output that the
  parameter is known.  If it is not read or written in the first basic
  block then subsequent basic blocks are searched and the result is
*************** useful despite these limitations.
*** 1936,1942 ****
     In conclusion it would be wise to check all parameters in any
  automatically generated swig interface file.  Furthermore you can force
  the automatic mechanism to generate correct interface files by reading
! or writing to the 'VAR' parameter in the first basic block of a
  procedure.
  
  
--- 1936,1942 ----
     In conclusion it would be wise to check all parameters in any
  automatically generated swig interface file.  Furthermore you can force
  the automatic mechanism to generate correct interface files by reading
! or writing to the ‘VAR’ parameter in the first basic block of a
  procedure.
  
  
*************** initialize your application in Python.
*** 1954,1960 ****
  next event simulation.  The Python module needs to have a clear API
  which should be placed in a single definition module.  Furthermore the
  API should only use fundamental pervasive data types and strings.  Below
! the API is contained in the file 'twoDsim.def':
  
       DEFINITION MODULE twoDsim ;
  
--- 1954,1960 ----
  next event simulation.  The Python module needs to have a clear API
  which should be placed in a single definition module.  Furthermore the
  API should only use fundamental pervasive data types and strings.  Below
! the API is contained in the file ‘twoDsim.def’:
  
       DEFINITION MODULE twoDsim ;
  
*************** the API is contained in the file 'twoDsi
*** 2061,2070 ****
  
       END twoDsim.
  
!    The keyword 'UNQUALIFIED' can be used to ensure that the compiler
! will provide externally accessible functions 'gravity', 'box', 'poly3',
! 'poly5', 'poly6', 'mass', 'fix', 'circle', 'pivot', 'velocity', 'accel',
! 'fps', 'replayRate', 'simulateFor' rather than name mangled
  alternatives.  Hence in our Python3 application we could write:
  
       #!/usr/bin/env python3
--- 2061,2070 ----
  
       END twoDsim.
  
!    The keyword ‘UNQUALIFIED’ can be used to ensure that the compiler
! will provide externally accessible functions ‘gravity’, ‘box’, ‘poly3’,
! ‘poly5’, ‘poly6’, ‘mass’, ‘fix’, ‘circle’, ‘pivot’, ‘velocity’, ‘accel’,
! ‘fps’, ‘replayRate’, ‘simulateFor’ rather than name mangled
  alternatives.  Hence in our Python3 application we could write:
  
       #!/usr/bin/env python3
*************** alternatives.  Hence in our Python3 appl
*** 2089,2103 ****
           print ("exception raised")
  
     which accesses the various functions defined and implemented by the
! module 'twoDsim'.  The Modula-2 source code is compiled via:
  
       $ gm2 -g -fiso -c -fswig twoDsim.mod
       $ gm2 -g -fiso -c -fmakelist twoDsim.mod
       $ gm2 -g -fiso -c -fmakeinit twoDsim.mod
  
!    The first command both compiles the source file creating 'twoDsim.o'
! and produces a swig interface file 'swig.i'.  We now use 'swig' and
! 'g++' to produce and compile the interface wrappers:
  
       $ libtool --mode=compile g++ -g -c twoDsim_m2.cpp -o twoDsim_m2.lo
       $ swig -c++ -python3 twoDsim.i
--- 2089,2103 ----
           print ("exception raised")
  
     which accesses the various functions defined and implemented by the
! module ‘twoDsim’.  The Modula-2 source code is compiled via:
  
       $ gm2 -g -fiso -c -fswig twoDsim.mod
       $ gm2 -g -fiso -c -fmakelist twoDsim.mod
       $ gm2 -g -fiso -c -fmakeinit twoDsim.mod
  
!    The first command both compiles the source file creating ‘twoDsim.o’
! and produces a swig interface file ‘swig.i’.  We now use ‘swig’ and
! ‘g++’ to produce and compile the interface wrappers:
  
       $ libtool --mode=compile g++ -g -c twoDsim_m2.cpp -o twoDsim_m2.lo
       $ swig -c++ -python3 twoDsim.i
*************** and produces a swig interface file 'swig
*** 2116,2122 ****
          -rpath `pwd` -lgm2 -lstdc++ -lm -o libtwoDsim.la
       cp .libs/libtwoDsim.so _twoDsim.so
  
!    The library name must start with '_' to comply with the Python3
  module naming scheme.
  
  
--- 2116,2122 ----
          -rpath `pwd` -lgm2 -lstdc++ -lm -o libtwoDsim.la
       cp .libs/libtwoDsim.so _twoDsim.so
  
!    The library name must start with ‘_’ to comply with the Python3
  module naming scheme.
  
  
*************** File: m2.info,  Node: Interface to C,  N
*** 2128,2142 ****
  The GNU Modula-2 compiler tries to use the C calling convention wherever
  possible however some parameters have no C equivalent and thus a
  language specific method is used.  For example unbounded arrays are
! passed as a 'struct {void *address, unsigned int high}' and the contents
  of these arrays are copied by callee functions when they are declared as
! non 'VAR' parameters.  The 'VAR' equivalent unbounded array parameters
! need no copy, but still use the 'struct' representation.
  
     The recommended method of interfacing GNU Modula-2 to C is by telling
  the definition module that the implementation is in the C language.
! This is achieved by using the tokens 'DEFINITION MODULE FOR "C"'.  Here
! is an example 'libprintf.def'.
  
       DEFINITION MODULE FOR "C" libprintf ;
  
--- 2128,2142 ----
  The GNU Modula-2 compiler tries to use the C calling convention wherever
  possible however some parameters have no C equivalent and thus a
  language specific method is used.  For example unbounded arrays are
! passed as a ‘struct {void *address, unsigned int high}’ and the contents
  of these arrays are copied by callee functions when they are declared as
! non ‘VAR’ parameters.  The ‘VAR’ equivalent unbounded array parameters
! need no copy, but still use the ‘struct’ representation.
  
     The recommended method of interfacing GNU Modula-2 to C is by telling
  the definition module that the implementation is in the C language.
! This is achieved by using the tokens ‘DEFINITION MODULE FOR "C"’.  Here
! is an example ‘libprintf.def’.
  
       DEFINITION MODULE FOR "C" libprintf ;
  
*************** is an example 'libprintf.def'.
*** 2146,2161 ****
  
       END libprintf.
  
!    the 'UNQUALIFIED' keyword in the definition module informs GNU
  Modula-2 not to prefix the module name to exported references in the
  object file.
  
!    The 'printf' declaration states that the first parameter semantically
! matches 'ARRAY OF CHAR' but since the module is for the C language it
! will be mapped onto 'char *'.  The token '...' indicates a variable
  number of arguments (varargs) and all parameters passed here are mapped
  onto their C equivalents.  Arrays and constant strings are passed as
! pointers.  Lastly '[ INTEGER ]' states that the caller can ignore the
  function return result if desired.
  
     The hello world program can be rewritten as:
--- 2146,2161 ----
  
       END libprintf.
  
!    the ‘UNQUALIFIED’ keyword in the definition module informs GNU
  Modula-2 not to prefix the module name to exported references in the
  object file.
  
!    The ‘printf’ declaration states that the first parameter semantically
! matches ‘ARRAY OF CHAR’ but since the module is for the C language it
! will be mapped onto ‘char *’.  The token ‘...’ indicates a variable
  number of arguments (varargs) and all parameters passed here are mapped
  onto their C equivalents.  Arrays and constant strings are passed as
! pointers.  Lastly ‘[ INTEGER ]’ states that the caller can ignore the
  function return result if desired.
  
     The hello world program can be rewritten as:
*************** function return result if desired.
*** 2170,2181 ****
  
     and it can be compiled by:
  
!    'gm2 -g hello.mod -lc'
  
!    In reality the '-lc' is redundant as libc is always included in the
  linking process.  It is shown here to emphasize that the C library or
! object file containing 'printf' must be present.  The search path for
! modules can be changed by using '-I'.
  
     If a procedure function is declared using varargs then some parameter
  values are converted.  The table below summarizes the default
--- 2170,2181 ----
  
     and it can be compiled by:
  
!    ‘gm2 -g hello.mod -lc’
  
!    In reality the ‘-lc’ is redundant as libc is always included in the
  linking process.  It is shown here to emphasize that the C library or
! object file containing ‘printf’ must be present.  The search path for
! modules can be changed by using ‘-I’.
  
     If a procedure function is declared using varargs then some parameter
  values are converted.  The table below summarizes the default
*************** conversions and default types used.
*** 2190,2198 ****
       a: ARRAY [0..5] OF CHAR|  ADR (a)             |   char *
       3.14                   |  none                |   long double
  
!    If you wish to pass 'int' values then you should explicitly convert
  the constants using one of the conversion mechanisms.  For example:
! 'INTEGER(10)' or 'VAL(INTEGER, 10)' or 'CAST(INTEGER, 10)'.
  
  
  File: m2.info,  Node: Assembly language,  Next: Alignment,  Prev: Interface to C,  Up: Using
--- 2190,2198 ----
       a: ARRAY [0..5] OF CHAR|  ADR (a)             |   char *
       3.14                   |  none                |   long double
  
!    If you wish to pass ‘int’ values then you should explicitly convert
  the constants using one of the conversion mechanisms.  For example:
! ‘INTEGER(10)’ or ‘VAL(INTEGER, 10)’ or ‘CAST(INTEGER, 10)’.
  
  
  File: m2.info,  Node: Assembly language,  Next: Alignment,  Prev: Interface to C,  Up: Using
*************** File: m2.info,  Node: Assembly language,
*** 2201,2211 ****
  ===================================
  
  The interface for GNU Modula-2 to assembly language is almost identical
! to GNU C. The only alterations are that the keywords 'asm' and
! 'volatile' are in capitals, following the Modula-2 convention.
  
     A simple, but highly non optimal, example is given below.  Here we
! want to add the two 'CARDINAL's 'foo' and 'bar' together and return the
  result.  The target processor is assumed to be executing the x86_64
  instruction set.
  
--- 2201,2211 ----
  ===================================
  
  The interface for GNU Modula-2 to assembly language is almost identical
! to GNU C. The only alterations are that the keywords ‘asm’ and
! ‘volatile’ are in capitals, following the Modula-2 convention.
  
     A simple, but highly non optimal, example is given below.  Here we
! want to add the two ‘CARDINAL’s ‘foo’ and ‘bar’ together and return the
  result.  The target processor is assumed to be executing the x86_64
  instruction set.
  
*************** File: m2.info,  Node: Alignment,  Next:
*** 2253,2260 ****
  ========================
  
  GNU Modula-2 allows you to specify alignment for types and variables.
! The syntax for alignment is to use the ISO pragma directives '<*'
! 'bytealignment (' expression ')' and '*>'.  These directives can be used
  after type and variable declarations.
  
     The ebnf of the alignment production is:
--- 2253,2260 ----
  ========================
  
  GNU Modula-2 allows you to specify alignment for types and variables.
! The syntax for alignment is to use the ISO pragma directives ‘<*’
! ‘bytealignment (’ expression ‘)’ and ‘*>’.  These directives can be used
  after type and variable declarations.
  
     The ebnf of the alignment production is:
*************** after type and variable declarations.
*** 2263,2271 ****
       ByteAlignment := '<*' AttributeExpression '*>' =:
       AlignmentExpression := "(" ConstExpression ")" =:
  
!    The 'Alignment' ebnf statement may be used during construction of
  types, records, record fields, arrays, pointers and variables.  Below is
! an example of aligning a type so that the variable 'bar' is aligned on a
  1024 address.
  
       MODULE align ;
--- 2263,2271 ----
       ByteAlignment := '<*' AttributeExpression '*>' =:
       AlignmentExpression := "(" ConstExpression ")" =:
  
!    The ‘Alignment’ ebnf statement may be used during construction of
  types, records, record fields, arrays, pointers and variables.  Below is
! an example of aligning a type so that the variable ‘bar’ is aligned on a
  1024 address.
  
       MODULE align ;
*************** an example of aligning a type so that th
*** 2308,2314 ****
          END
       END align4.
  
!    In example 'align5' record field 'y' is aligned on a 1024 byte
  boundary.
  
       MODULE align5 ;
--- 2308,2314 ----
          END
       END align4.
  
!    In example ‘align5’ record field ‘y’ is aligned on a 1024 byte
  boundary.
  
       MODULE align5 ;
*************** boundary.
*** 2332,2339 ****
          END
       END align5.
  
!    In the example below module 'align6' declares 'foo' as an array of
! 256 'INTEGER's.  The array 'foo' is aligned on a 1024 byte boundary.
  
       MODULE align6 ;
  
--- 2332,2339 ----
          END
       END align5.
  
!    In the example below module ‘align6’ declares ‘foo’ as an array of
! 256 ‘INTEGER’s.  The array ‘foo’ is aligned on a 1024 byte boundary.
  
       MODULE align6 ;
  
*************** File: m2.info,  Node: Packed,  Next: Bui
*** 2361,2368 ****
  2.18 Packing data types
  =======================
  
! The pragma '<* bytealignment(0) *>' can be used to specify that the
! fields within a 'RECORD' are to be packed.  Currently this only applies
  to fields which are declared as subranges, ordinal types and enumerated
  types.  Here is an example of how two subranges might be packed into a
  byte.
--- 2361,2368 ----
  2.18 Packing data types
  =======================
  
! The pragma ‘<* bytealignment(0) *>’ can be used to specify that the
! fields within a ‘RECORD’ are to be packed.  Currently this only applies
  to fields which are declared as subranges, ordinal types and enumerated
  types.  Here is an example of how two subranges might be packed into a
  byte.
*************** byte.
*** 2378,2390 ****
                     y: bits3i ;
                 END ;
  
!    Notice that the user has specified that in between fields 'x' and 'y'
  there are two bits unused.
  
     Now the user wishes to create a record with byte numbers zero and one
! occupied and then an 'INTEGER32' field which is four byte aligned.  In
  this case byte numbers two and three will be unused.  The pragma
! 'bytealignment' can be issued at the start of the record indicating the
  default alignment for the whole record and this can be overridden by
  individual fields if necessary.
  
--- 2378,2390 ----
                     y: bits3i ;
                 END ;
  
!    Notice that the user has specified that in between fields ‘x’ and ‘y’
  there are two bits unused.
  
     Now the user wishes to create a record with byte numbers zero and one
! occupied and then an ‘INTEGER32’ field which is four byte aligned.  In
  this case byte numbers two and three will be unused.  The pragma
! ‘bytealignment’ can be issued at the start of the record indicating the
  default alignment for the whole record and this can be overridden by
  individual fields if necessary.
  
*************** individual fields if necessary.
*** 2395,2401 ****
                END ;
  
     In the following example the user has specified that a record has two
! fields 'p' and 'q' but that there are three bytes unused between these
  fields.
  
          header = RECORD
--- 2395,2401 ----
                END ;
  
     In the following example the user has specified that a record has two
! fields ‘p’ and ‘q’ but that there are three bytes unused between these
  fields.
  
          header = RECORD
*************** fields.
*** 2405,2414 ****
                      q: byte ;
                   END ;
  
!    The pragma '<* bytesunused(x) *>' can only be used if the current
! field is on a byte boundary.  There is also a 'SYSTEM' pseudo procedure
! function 'TBITSIZE(T)' which returns the minimum number of bits
! necessary to represent type 'T'.
  
     Another example of packing record bit fields is given below:
  
--- 2405,2414 ----
                      q: byte ;
                   END ;
  
!    The pragma ‘<* bytesunused(x) *>’ can only be used if the current
! field is on a byte boundary.  There is also a ‘SYSTEM’ pseudo procedure
! function ‘TBITSIZE(T)’ which returns the minimum number of bits
! necessary to represent type ‘T’.
  
     Another example of packing record bit fields is given below:
  
*************** File: m2.info,  Node: Built-ins,  Next:
*** 2454,2467 ****
  
  This section describes the built-in constants and functions defined in
  GNU Modula-2.  The following compiler constants can be accessed using
! the '__ATTRIBUTE__' '__BUILTIN__' keywords.  These are not part of the
  Modula-2 language and they may differ depending upon the target
  architecture but they provide a method whereby common libraries can
  interface to a different underlying architecture.
  
!    The built-in constants are: 'BITS_PER_UNIT', 'BITS_PER_WORD',
! 'BITS_PER_CHAR' and 'UNITS_PER_WORD'.  They are integrated into GNU
! Modula-2 by an extension to the 'ConstFactor' rule:
  
       ConstFactor := ConstQualidentOrSet | Number | ConstString |
                      "(" ConstExpression ")" | "NOT" ConstFactor |
--- 2454,2467 ----
  
  This section describes the built-in constants and functions defined in
  GNU Modula-2.  The following compiler constants can be accessed using
! the ‘__ATTRIBUTE__’ ‘__BUILTIN__’ keywords.  These are not part of the
  Modula-2 language and they may differ depending upon the target
  architecture but they provide a method whereby common libraries can
  interface to a different underlying architecture.
  
!    The built-in constants are: ‘BITS_PER_UNIT’, ‘BITS_PER_WORD’,
! ‘BITS_PER_CHAR’ and ‘UNITS_PER_WORD’.  They are integrated into GNU
! Modula-2 by an extension to the ‘ConstFactor’ rule:
  
       ConstFactor := ConstQualidentOrSet | Number | ConstString |
                      "(" ConstExpression ")" | "NOT" ConstFactor |
*************** Modula-2 by an extension to the 'ConstFa
*** 2469,2507 ****
  
       ConstAttribute := "__ATTRIBUTE__" "__BUILTIN__" "(" "(" Ident ")" ")" =:
  
!    Here is an example taken from the ISO library 'SYSTEM.def':
  
       CONST
          BITSPERLOC    = __ATTRIBUTE__ __BUILTIN__ ((BITS_PER_UNIT)) ;
          LOCSPERWORD   = __ATTRIBUTE__ __BUILTIN__ ((UNITS_PER_WORD)) ;
  
     Built-in functions are transparent to the end user.  All built-in
! functions are declared in 'DEFINITION MODULE's and are imported as and
  when required.  Built-in functions are declared in definition modules by
! using the '__BUILTIN__' keyword.  Here is a section of the ISO library
! 'LongMath.def' which demonstrates this feature.
  
       PROCEDURE __BUILTIN__ sqrt (x: LONGREAL): LONGREAL;
         (* Returns the square root of x *)
  
!    This indicates that the function 'sqrt' will be implemented using the
  gcc built-in maths library.  If gcc cannot utilize the built-in function
! (for example if the programmer requested the address of 'sqrt') then
  code is generated to call the alternative function implemented in the
! 'IMPLEMENTATION' 'MODULE'.
  
!    Sometimes a function exported from the 'DEFINITION' 'MODULE' will
  have a different name from the built-in function within gcc.  In such
  cases the mapping between the GNU Modula-2 function name and the gcc
! name is expressed using the keywords '__ATTRIBUTE__' '__BUILTIN__'
! '((Ident))'.  For example the function 'sqrt' in 'LongMath.def' maps
! onto the gcc built-in function 'sqrtl' and this is expressed as:
  
       PROCEDURE __ATTRIBUTE__ __BUILTIN__ ((sqrtl)) sqrt
                                           (x: LONGREAL) : LONGREAL;
         (* Returns the positive square root of x *)
  
!    The following module 'Builtins.def' enumerates the list of built-in
  functions which can be accessed in GNU Modula-2.  It also serves to
  define the parameter and return value for each function:
  
--- 2469,2507 ----
  
       ConstAttribute := "__ATTRIBUTE__" "__BUILTIN__" "(" "(" Ident ")" ")" =:
  
!    Here is an example taken from the ISO library ‘SYSTEM.def’:
  
       CONST
          BITSPERLOC    = __ATTRIBUTE__ __BUILTIN__ ((BITS_PER_UNIT)) ;
          LOCSPERWORD   = __ATTRIBUTE__ __BUILTIN__ ((UNITS_PER_WORD)) ;
  
     Built-in functions are transparent to the end user.  All built-in
! functions are declared in ‘DEFINITION MODULE’s and are imported as and
  when required.  Built-in functions are declared in definition modules by
! using the ‘__BUILTIN__’ keyword.  Here is a section of the ISO library
! ‘LongMath.def’ which demonstrates this feature.
  
       PROCEDURE __BUILTIN__ sqrt (x: LONGREAL): LONGREAL;
         (* Returns the square root of x *)
  
!    This indicates that the function ‘sqrt’ will be implemented using the
  gcc built-in maths library.  If gcc cannot utilize the built-in function
! (for example if the programmer requested the address of ‘sqrt’) then
  code is generated to call the alternative function implemented in the
! ‘IMPLEMENTATION’ ‘MODULE’.
  
!    Sometimes a function exported from the ‘DEFINITION’ ‘MODULE’ will
  have a different name from the built-in function within gcc.  In such
  cases the mapping between the GNU Modula-2 function name and the gcc
! name is expressed using the keywords ‘__ATTRIBUTE__’ ‘__BUILTIN__’
! ‘((Ident))’.  For example the function ‘sqrt’ in ‘LongMath.def’ maps
! onto the gcc built-in function ‘sqrtl’ and this is expressed as:
  
       PROCEDURE __ATTRIBUTE__ __BUILTIN__ ((sqrtl)) sqrt
                                           (x: LONGREAL) : LONGREAL;
         (* Returns the positive square root of x *)
  
!    The following module ‘Builtins.def’ enumerates the list of built-in
  functions which can be accessed in GNU Modula-2.  It also serves to
  define the parameter and return value for each function:
  
*************** in-line code if optimization flags are p
*** 2716,2722 ****
  advised to utilize the same functions from more generic libraries.  The
  built-in mechanism will be applied to these generic libraries where
  appropriate.  Note for the mathematical routines to be in-lined you need
! to specify the '-ffast-math -O' options.
  
  
  File: m2.info,  Node: The PIM system module,  Next: The ISO system module,  Prev: Built-ins,  Up: Using
--- 2716,2722 ----
  advised to utilize the same functions from more generic libraries.  The
  built-in mechanism will be applied to these generic libraries where
  appropriate.  Note for the mathematical routines to be in-lined you need
! to specify the ‘-ffast-math -O’ options.
  
  
  File: m2.info,  Node: The PIM system module,  Next: The ISO system module,  Prev: Built-ins,  Up: Using
*************** File: m2.info,  Node: The PIM system mod
*** 2928,2949 ****
       END SYSTEM.
  
     The different dialects of Modula-2 PIM-[234] and ISO Modula-2 declare
! the function 'SIZE' in different places.  PIM-[34] and ISO Modula-2
! declare 'SIZE' as a pervasive function (declared in the base module).
! PIM-2 defined 'SIZE' in the 'SYSTEM' module (as shown above).
  
     GNU Modula-2 allows users to specify the dialect of Modula-2 by using
! the '-fiso' and '-fpim2' command line switches.
  
!    The data types 'CSIZE_T' and 'CSSIZE_T' are also exported from the
! 'SYSTEM' module.  The type 'CSIZE_T' is unsigned and is mapped onto the
! target C data type 'size_t' whereas the type 'CSSIZE_T' is mapped onto
! the signed C data type 'ssize_t'.
  
     It is anticipated that these should only be used to provide cross
  platform definition modules for C libraries.
  
!    There are also a variety of fixed sized 'INTEGER' and 'CARDINAL'
  types.  The variety of the fixed sized types will depend upon the target
  architecture.
  
--- 2928,2949 ----
       END SYSTEM.
  
     The different dialects of Modula-2 PIM-[234] and ISO Modula-2 declare
! the function ‘SIZE’ in different places.  PIM-[34] and ISO Modula-2
! declare ‘SIZE’ as a pervasive function (declared in the base module).
! PIM-2 defined ‘SIZE’ in the ‘SYSTEM’ module (as shown above).
  
     GNU Modula-2 allows users to specify the dialect of Modula-2 by using
! the ‘-fiso’ and ‘-fpim2’ command line switches.
  
!    The data types ‘CSIZE_T’ and ‘CSSIZE_T’ are also exported from the
! ‘SYSTEM’ module.  The type ‘CSIZE_T’ is unsigned and is mapped onto the
! target C data type ‘size_t’ whereas the type ‘CSSIZE_T’ is mapped onto
! the signed C data type ‘ssize_t’.
  
     It is anticipated that these should only be used to provide cross
  platform definition modules for C libraries.
  
!    There are also a variety of fixed sized ‘INTEGER’ and ‘CARDINAL’
  types.  The variety of the fixed sized types will depend upon the target
  architecture.
  
*************** File: m2.info,  Node: The ISO system mod
*** 3209,3223 ****
  
       END SYSTEM.
  
!    The data types 'CSIZE_T' and 'CSSIZE_T' are also exported from the
! 'SYSTEM' module.  The type 'CSIZE_T' is unsigned and is mapped onto the
! target C data type 'size_t' whereas the type 'CSSIZE_T' is mapped onto
! the signed C data type 'ssize_t'.
  
     It is anticipated that these should only be used to provide cross
  platform definition modules for C libraries.
  
!    There are also a variety of fixed sized 'INTEGER' and 'CARDINAL'
  types.  The variety of the fixed sized types will depend upon the target
  architecture.
  
--- 3209,3223 ----
  
       END SYSTEM.
  
!    The data types ‘CSIZE_T’ and ‘CSSIZE_T’ are also exported from the
! ‘SYSTEM’ module.  The type ‘CSIZE_T’ is unsigned and is mapped onto the
! target C data type ‘size_t’ whereas the type ‘CSSIZE_T’ is mapped onto
! the signed C data type ‘ssize_t’.
  
     It is anticipated that these should only be used to provide cross
  platform definition modules for C libraries.
  
!    There are also a variety of fixed sized ‘INTEGER’ and ‘CARDINAL’
  types.  The variety of the fixed sized types will depend upon the target
  architecture.
  
*************** run using:
*** 3266,3274 ****
  
     Finally the results of the testsuite can be emailed to the
  gcc-testresults (https://gcc.gnu.org/lists.html) list using the
! 'test_summary' script found in the gcc source tree:
  
!      $ 'directory to the sources'/contrib/test_summary
  
  
  File: m2.info,  Node: Limitations,  Next: Objectives,  Prev: Regression tests,  Up: Using
--- 3266,3274 ----
  
     Finally the results of the testsuite can be emailed to the
  gcc-testresults (https://gcc.gnu.org/lists.html) list using the
! ‘test_summary’ script found in the gcc source tree:
  
!      $ ‘directory to the sources’/contrib/test_summary
  
  
  File: m2.info,  Node: Limitations,  Next: Objectives,  Prev: Regression tests,  Up: Using
*************** File: m2.info,  Node: Objectives,  Next:
*** 3286,3302 ****
  2.26 Objectives
  ===============
  
!    * The intention of GNU Modula-2 is to provide a production Modula-2
       front end to GCC.
  
!    * It should support all Niklaus Wirth PIM Dialects [234] and also ISO
       Modula-2 including a re-implementation of all the ISO modules.
  
!    * There should be an easy interface to C.
  
!    * Exploit the features of GCC.
  
!    * Listen to the requests of the users.
  
  
  File: m2.info,  Node: FAQ,  Next: Community,  Prev: Objectives,  Up: Using
--- 3286,3302 ----
  2.26 Objectives
  ===============
  
!    • The intention of GNU Modula-2 is to provide a production Modula-2
       front end to GCC.
  
!    • It should support all Niklaus Wirth PIM Dialects [234] and also ISO
       Modula-2 including a re-implementation of all the ISO modules.
  
!    • There should be an easy interface to C.
  
!    • Exploit the features of GCC.
  
!    • Listen to the requests of the users.
  
  
  File: m2.info,  Node: FAQ,  Next: Community,  Prev: Objectives,  Up: Using
*************** GNU General Public License
*** 3362,3368 ****
  
                          Version 3, 29 June 2007
  
!      Copyright (C) 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
--- 3362,3368 ----
  
                          Version 3, 29 June 2007
  
!      Copyright © 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
*************** mail.
*** 4049,4059 ****
  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".
--- 4049,4059 ----
  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".
*************** modules originally came from the M2F com
*** 4598,4607 ****
  and extended.  They provide a basic interface to the underlying
  operating system via libc.  They also include a number of libraries to
  allow access to compiler built-ins.  Perhaps the largest difference to
! PIM and ISO libraries is the 'DynamicString' module which declares the
! type 'String'.  The heavy use of this opaque data type results in a
! number of equivalent modules that can either handle 'ARRAY OF CHAR' or
! 'String'.
  
     These modules have been extensively tested and are used throughout
  building the GNU Modula-2 compiler.
--- 4598,4607 ----
  and extended.  They provide a basic interface to the underlying
  operating system via libc.  They also include a number of libraries to
  allow access to compiler built-ins.  Perhaps the largest difference to
! PIM and ISO libraries is the ‘DynamicString’ module which declares the
! type ‘String’.  The heavy use of this opaque data type results in a
! number of equivalent modules that can either handle ‘ARRAY OF CHAR’ or
! ‘String’.
  
     These modules have been extensively tested and are used throughout
  building the GNU Modula-2 compiler.
*************** File: m2.info,  Node: PIM coroutine supp
*** 11744,11751 ****
  4.3 PIM coroutine support
  =========================
  
! This directory contains a PIM 'SYSTEM' containing the 'PROCESS'
! primitives built on top of 'gthread's.
  * Menu:
  
  * gm2-libs-coroutines/Executive::Executive.def
--- 11744,11751 ----
  4.3 PIM coroutine support
  =========================
  
! This directory contains a PIM ‘SYSTEM’ containing the ‘PROCESS’
! primitives built on top of ‘gthread’s.
  * Menu:
  
  * gm2-libs-coroutines/Executive::Executive.def
*************** File: m2.info,  Node: M2 ISO Libraries,
*** 12311,12359 ****
  
  This directory contains the ISO definition modules and some
  corresponding implementation modules.  The definition files:
! 'ChanConsts.def', 'CharClass.def', 'ComplexMath.def',
! 'ConvStringLong.def', 'ConvStringReal.def', 'ConvTypes.def',
! 'COROUTINES.def', 'EXCEPTIONS.def', 'GeneralUserExceptions.def',
! 'IOChan.def', 'IOConsts.def', 'IOLink.def', 'IOLink.def',
! 'IOResult.def', 'LongComplexMath.def', 'LongConv.def', 'LongIO.def',
! 'LongMath.def', 'LongStr.def', 'LowLong.def', 'LowReal.def',
! 'M2EXCEPTION.def', 'Processes.def', 'ProgramArgs.def', 'RawIO.def',
! 'RealConv.def', 'RealIO.def', 'RealMath.def', 'RealStr.def',
! 'RndFile.def', 'Semaphores.def', 'SeqFile.def', 'SIOResult.def',
! 'SLongIO.def', 'SRawIO.def', 'SRealIO.def', 'StdChans.def',
! 'STextIO.def', 'Storage.def', 'StreamFile.def', 'Strings.def',
! 'SWholeIO.def', 'SysClock.def', 'SYSTEM.def', 'TERMINATION.def',
! 'TextIO.def', 'WholeConv.def', 'WholeIO.def' and 'WholeStr.def' were
  defined by the International Standard Information technology -
  programming languages BS ISO/IEC 10514-1:1996E Part 1: Modula-2, Base
  Language.
  
!    The Copyright to the definition files 'ChanConsts.def',
! 'CharClass.def', 'ComplexMath.def', 'ConvStringLong.def',
! 'ConvStringReal.def', 'ConvTypes.def', 'COROUTINES.def',
! 'EXCEPTIONS.def', 'GeneralUserExceptions.def', 'IOChan.def',
! 'IOConsts.def', 'IOLink.def', 'IOLink.def', 'IOResult.def',
! 'LongComplexMath.def', 'LongConv.def', 'LongIO.def', 'LongMath.def',
! 'LongStr.def', 'LowLong.def', 'LowReal.def', 'M2EXCEPTION.def',
! 'Processes.def', 'ProgramArgs.def', 'RawIO.def', 'RealConv.def',
! 'RealIO.def', 'RealMath.def', 'RealStr.def', 'RndFile.def',
! 'Semaphores.def', 'SeqFile.def', 'SIOResult.def', 'SLongIO.def',
! 'SRawIO.def', 'SRealIO.def', 'StdChans.def', 'STextIO.def',
! 'Storage.def', 'StreamFile.def', 'Strings.def', 'SWholeIO.def',
! 'SysClock.def', 'SYSTEM.def', 'TERMINATION.def', 'TextIO.def',
! 'WholeConv.def', 'WholeIO.def' and 'WholeStr.def' belong to ISO/IEC
  (International Organization for Standardization and International
  Electrotechnical Commission).  The licence allows them to be distributed
  with the compiler (as described on page 707 of the Information
  technology - Programming languages Part 1: Modula-2, Base Language.  BS
  ISO/IEC 10514-1:1996).
  
!    All implementation modules and 'ClientSocket.def', 'LongWholeIO.def',
! 'M2RTS.def', 'MemStream.def', 'pth.def', 'RandomNumber.def',
! 'RTdata.def', 'RTentity.def', 'RTfio.def', 'RTio.def',
! 'ShortComplexMath.def', 'ShortIO.def', 'ShortWholeIO.def',
! 'SimpleCipher.def', 'SLongWholeIO.def', 'SShortIO.def',
! 'SShortWholeIO.def', 'StringChan.def' and 'wraptime.def' are Copyright
  of the FSF and are held under the GPLv3 with runtime exceptions.
  
     Under Section 7 of GPL version 3, you are granted additional
--- 12311,12359 ----
  
  This directory contains the ISO definition modules and some
  corresponding implementation modules.  The definition files:
! ‘ChanConsts.def’, ‘CharClass.def’, ‘ComplexMath.def’,
! ‘ConvStringLong.def’, ‘ConvStringReal.def’, ‘ConvTypes.def’,
! ‘COROUTINES.def’, ‘EXCEPTIONS.def’, ‘GeneralUserExceptions.def’,
! ‘IOChan.def’, ‘IOConsts.def’, ‘IOLink.def’, ‘IOLink.def’,
! ‘IOResult.def’, ‘LongComplexMath.def’, ‘LongConv.def’, ‘LongIO.def’,
! ‘LongMath.def’, ‘LongStr.def’, ‘LowLong.def’, ‘LowReal.def’,
! ‘M2EXCEPTION.def’, ‘Processes.def’, ‘ProgramArgs.def’, ‘RawIO.def’,
! ‘RealConv.def’, ‘RealIO.def’, ‘RealMath.def’, ‘RealStr.def’,
! ‘RndFile.def’, ‘Semaphores.def’, ‘SeqFile.def’, ‘SIOResult.def’,
! ‘SLongIO.def’, ‘SRawIO.def’, ‘SRealIO.def’, ‘StdChans.def’,
! ‘STextIO.def’, ‘Storage.def’, ‘StreamFile.def’, ‘Strings.def’,
! ‘SWholeIO.def’, ‘SysClock.def’, ‘SYSTEM.def’, ‘TERMINATION.def’,
! ‘TextIO.def’, ‘WholeConv.def’, ‘WholeIO.def’ and ‘WholeStr.def’ were
  defined by the International Standard Information technology -
  programming languages BS ISO/IEC 10514-1:1996E Part 1: Modula-2, Base
  Language.
  
!    The Copyright to the definition files ‘ChanConsts.def’,
! ‘CharClass.def’, ‘ComplexMath.def’, ‘ConvStringLong.def’,
! ‘ConvStringReal.def’, ‘ConvTypes.def’, ‘COROUTINES.def’,
! ‘EXCEPTIONS.def’, ‘GeneralUserExceptions.def’, ‘IOChan.def’,
! ‘IOConsts.def’, ‘IOLink.def’, ‘IOLink.def’, ‘IOResult.def’,
! ‘LongComplexMath.def’, ‘LongConv.def’, ‘LongIO.def’, ‘LongMath.def’,
! ‘LongStr.def’, ‘LowLong.def’, ‘LowReal.def’, ‘M2EXCEPTION.def’,
! ‘Processes.def’, ‘ProgramArgs.def’, ‘RawIO.def’, ‘RealConv.def’,
! ‘RealIO.def’, ‘RealMath.def’, ‘RealStr.def’, ‘RndFile.def’,
! ‘Semaphores.def’, ‘SeqFile.def’, ‘SIOResult.def’, ‘SLongIO.def’,
! ‘SRawIO.def’, ‘SRealIO.def’, ‘StdChans.def’, ‘STextIO.def’,
! ‘Storage.def’, ‘StreamFile.def’, ‘Strings.def’, ‘SWholeIO.def’,
! ‘SysClock.def’, ‘SYSTEM.def’, ‘TERMINATION.def’, ‘TextIO.def’,
! ‘WholeConv.def’, ‘WholeIO.def’ and ‘WholeStr.def’ belong to ISO/IEC
  (International Organization for Standardization and International
  Electrotechnical Commission).  The licence allows them to be distributed
  with the compiler (as described on page 707 of the Information
  technology - Programming languages Part 1: Modula-2, Base Language.  BS
  ISO/IEC 10514-1:1996).
  
!    All implementation modules and ‘ClientSocket.def’, ‘LongWholeIO.def’,
! ‘M2RTS.def’, ‘MemStream.def’, ‘pth.def’, ‘RandomNumber.def’,
! ‘RTdata.def’, ‘RTentity.def’, ‘RTfio.def’, ‘RTio.def’,
! ‘ShortComplexMath.def’, ‘ShortIO.def’, ‘ShortWholeIO.def’,
! ‘SimpleCipher.def’, ‘SLongWholeIO.def’, ‘SShortIO.def’,
! ‘SShortWholeIO.def’, ‘StringChan.def’ and ‘wraptime.def’ are Copyright
  of the FSF and are held under the GPLv3 with runtime exceptions.
  
     Under Section 7 of GPL version 3, you are granted additional
*************** the files COPYING3 and COPYING.RUNTIME r
*** 12366,12374 ****
  .
  
     Notice that GNU Modula-2 contains additional libraries for
! input/output of 'SHORTREAL', 'SHORTCARD', 'SHORTINT', 'LONGCARD',
! 'LONGINT' data types.  It also provides a 'RandomNumber', 'SimpleCipher'
! and 'ClientSocket' modules as well as low level modules which allow the
  IO libraries to coexist with their PIM counterparts.
  * Menu:
  
--- 12366,12374 ----
  .
  
     Notice that GNU Modula-2 contains additional libraries for
! input/output of ‘SHORTREAL’, ‘SHORTCARD’, ‘SHORTINT’, ‘LONGCARD’,
! ‘LONGINT’ data types.  It also provides a ‘RandomNumber’, ‘SimpleCipher’
! and ‘ClientSocket’ modules as well as low level modules which allow the
  IO libraries to coexist with their PIM counterparts.
  * Menu:
  
*************** File: m2.info,  Node: Indices,  Prev: Li
*** 17900,17905 ****
--- 17900,17907 ----
  * alloca:                                Built-ins.           (line 196)
  * alloca <1>:                            gm2-libs/Builtins.   (line 143)
  * alloca <2>:                            gm2-libs/cbuiltin.   (line  49)
+ * alloca_trace:                          Built-ins.           (line 260)
+ * alloca_trace <1>:                      gm2-libs/Builtins.   (line 207)
  * ALLOCATE:                              gm2-libs/Storage.    (line  19)
  * ALLOCATE <1>:                          gm2-libs/SysStorage. (line  21)
  * ALLOCATE <2>:                          gm2-libs-iso/Storage.
*************** File: m2.info,  Node: Indices,  Prev: Li
*** 17907,17914 ****
  * AllocateDeviceId:                      gm2-libs-iso/IOLink. (line  18)
  * AllocateSource:                        gm2-libs-iso/EXCEPTIONS.
                                                                (line  18)
- * alloca_trace:                          Built-ins.           (line 260)
- * alloca_trace <1>:                      gm2-libs/Builtins.   (line 207)
  * Append:                                gm2-libs-iso/Strings.
                                                                (line  55)
  * arccos:                                gm2-libs-iso/ComplexMath.
--- 17909,17914 ----
*************** File: m2.info,  Node: Indices,  Prev: Li
*** 18992,19001 ****
                                                                (line  50)
  * GetOpt:                                gm2-libs/GetOpt.     (line  25)
  * getopt:                                gm2-libs/cgetopt.    (line  30)
- * GetOptLong:                            gm2-libs/GetOpt.     (line  88)
- * GetOptLongOnly:                        gm2-libs/GetOpt.     (line  98)
  * getopt_long:                           gm2-libs/cgetopt.    (line  43)
  * getopt_long_only:                      gm2-libs/cgetopt.    (line  51)
  * getpid:                                gm2-libs/libc.       (line 172)
  * GetPos:                                gm2-libs-log/FileSystem.
                                                                (line 226)
--- 18992,19001 ----
                                                                (line  50)
  * GetOpt:                                gm2-libs/GetOpt.     (line  25)
  * getopt:                                gm2-libs/cgetopt.    (line  30)
  * getopt_long:                           gm2-libs/cgetopt.    (line  43)
  * getopt_long_only:                      gm2-libs/cgetopt.    (line  51)
+ * GetOptLong:                            gm2-libs/GetOpt.     (line  88)
+ * GetOptLongOnly:                        gm2-libs/GetOpt.     (line  98)
  * getpid:                                gm2-libs/libc.       (line 172)
  * GetPos:                                gm2-libs-log/FileSystem.
                                                                (line 226)
*************** File: m2.info,  Node: Indices,  Prev: Li
*** 19651,19663 ****
                                                                (line  25)
  * nModes (const) <2>:                    gm2-libs-iso/LowShort.
                                                                (line  25)
  * NoException:                           gm2-libs/M2RTS.      (line 175)
  * NoException <1>:                       gm2-libs-iso/M2RTS.  (line 183)
  * NonVarFPSection (ebnf):                EBNF.                (line 415)
  * NoReturnException:                     gm2-libs/M2RTS.      (line 166)
  * NoReturnException <1>:                 gm2-libs-iso/M2RTS.  (line 174)
  * NormalPart (ebnf):                     EBNF.                (line 376)
- * no_argument (const):                   gm2-libs/GetOpt.     (line  12)
  * np (const):                            gm2-libs/ASCII.      (line  24)
  * nul (const):                           gm2-libs/ASCII.      (line  21)
  * NullChan:                              gm2-libs-iso/StdChans.
--- 19651,19663 ----
                                                                (line  25)
  * nModes (const) <2>:                    gm2-libs-iso/LowShort.
                                                                (line  25)
+ * no_argument (const):                   gm2-libs/GetOpt.     (line  12)
  * NoException:                           gm2-libs/M2RTS.      (line 175)
  * NoException <1>:                       gm2-libs-iso/M2RTS.  (line 183)
  * NonVarFPSection (ebnf):                EBNF.                (line 415)
  * NoReturnException:                     gm2-libs/M2RTS.      (line 166)
  * NoReturnException <1>:                 gm2-libs-iso/M2RTS.  (line 174)
  * NormalPart (ebnf):                     EBNF.                (line 376)
  * np (const):                            gm2-libs/ASCII.      (line  24)
  * nul (const):                           gm2-libs/ASCII.      (line  21)
  * NullChan:                              gm2-libs-iso/StdChans.
*************** File: m2.info,  Node: Indices,  Prev: Li
*** 20153,20162 ****
  * Resume:                                gm2-libs-coroutines/Executive.
                                                                (line  46)
  * RetryStatement (ebnf):                 EBNF.                (line 286)
- * ReturnException:                       gm2-libs/M2RTS.      (line 153)
- * ReturnException <1>:                   gm2-libs-iso/M2RTS.  (line 161)
  * return_address:                        Built-ins.           (line 253)
  * return_address <1>:                    gm2-libs/Builtins.   (line 200)
  * Rewrite:                               gm2-libs-iso/MemStream.
                                                                (line  75)
  * Rewrite <1>:                           gm2-libs-iso/SeqFile.
--- 20153,20162 ----
  * Resume:                                gm2-libs-coroutines/Executive.
                                                                (line  46)
  * RetryStatement (ebnf):                 EBNF.                (line 286)
  * return_address:                        Built-ins.           (line 253)
  * return_address <1>:                    gm2-libs/Builtins.   (line 200)
+ * ReturnException:                       gm2-libs/M2RTS.      (line 153)
+ * ReturnException <1>:                   gm2-libs-iso/M2RTS.  (line 161)
  * Rewrite:                               gm2-libs-iso/MemStream.
                                                                (line  75)
  * Rewrite <1>:                           gm2-libs-iso/SeqFile.
*************** File: m2.info,  Node: Indices,  Prev: Li
*** 20768,20773 ****
--- 20768,20774 ----
  * TicksPerSecond (const):                gm2-libs-coroutines/TimerHandler.
                                                                (line  16)
  * time:                                  gm2-libs/libc.       (line 379)
+ * time_t (type):                         gm2-libs/libc.       (line  30)
  * timeb (type):                          gm2-libs/libc.       (line  47)
  * timespec (type):                       gm2-libs-iso/wrapclock.
                                                                (line  11)
*************** File: m2.info,  Node: Indices,  Prev: Li
*** 20782,20788 ****
                                                                (line  23)
  * timezone (type):                       gm2-libs-iso/wraptime.
                                                                (line  19)
- * time_t (type):                         gm2-libs/libc.       (line  30)
  * tm (type):                             gm2-libs/libc.       (line  33)
  * tm (type) <1>:                         gm2-libs-iso/wraptime.
                                                                (line  20)
--- 20783,20788 ----
*************** File: m2.info,  Node: Indices,  Prev: Li
*** 21132,21350 ****
  
  
  Tag Table:
! Node: Top1081
! Node: Overview1561
! Node: What is GNU Modula-21919
! Ref: What is GNU Modula-2-Footnote-12392
! Node: Why use GNU Modula-22962
! Node: Development4536
! Node: Features4782
! Node: Using6388
! Node: Example usage8280
! Ref: Example usage-Footnote-19399
! Node: Compiler options9648
! Node: Linking23118
! Node: Elementary data types26135
! Node: Standard procedures27580
! Node: High procedure function36306
! Node: Dialect39199
! Node: Exceptions42549
! Ref: Exceptions-Footnote-143658
! Node: Semantic checking43806
! Node: Extensions47754
! Node: Type compatibility55595
! Node: Unbounded by reference61938
! Node: Building a shared library65909
! Node: Interface for Python67359
! Node: Producing a Python module72430
! Node: Interface to C77432
! Node: Assembly language80494
! Node: Alignment82531
! Node: Packed85018
! Node: Built-ins87691
! Node: The PIM system module100118
! Node: The ISO system module108556
! Node: Release map118970
! Node: Documentation119517
! Node: Regression tests119777
! Node: Limitations120592
! Node: Objectives120911
! Node: FAQ121385
! Node: Community121826
! Node: Other languages122174
! Node: License122417
! Node: Copying123331
! Node: Contributing160853
! Node: EBNF161557
! Node: Libraries176172
! Node: Base libraries176600
! Node: gm2-libs/ASCII179312
! Node: gm2-libs/Args180405
! Node: gm2-libs/Assertion181001
! Node: gm2-libs/Break181412
! Node: gm2-libs/Builtins181618
! Node: gm2-libs/COROUTINES191069
! Node: gm2-libs/CmdArgs191446
! Node: gm2-libs/Debug192147
! Node: gm2-libs/DynamicStrings193003
! Node: gm2-libs/Environment202914
! Node: gm2-libs/FIO203924
! Node: gm2-libs/FormatStrings213169
! Node: gm2-libs/FpuIO214835
! Node: gm2-libs/GetOpt216253
! Node: gm2-libs/IO219726
! Node: gm2-libs/Indexing221457
! Node: gm2-libs/LMathLib0224004
! Node: gm2-libs/LegacyReal224775
! Node: gm2-libs/M2Dependent225050
! Node: gm2-libs/M2EXCEPTION226468
! Node: gm2-libs/M2RTS227718
! Node: gm2-libs/MathLib0235426
! Node: gm2-libs/MemUtils236127
! Node: gm2-libs/NumberIO236728
! Node: gm2-libs/OptLib238615
! Node: gm2-libs/PushBackInput240513
! Node: gm2-libs/RTExceptions243127
! Node: gm2-libs/RTint247774
! Node: gm2-libs/SArgs250705
! Node: gm2-libs/SCmdArgs251465
! Node: gm2-libs/SEnvironment252196
! Node: gm2-libs/SFIO253186
! Node: gm2-libs/SMathLib0255451
! Node: gm2-libs/SYSTEM256229
! Node: gm2-libs/Scan263748
! Node: gm2-libs/Selective265634
! Node: gm2-libs/StdIO267529
! Node: gm2-libs/Storage269363
! Node: gm2-libs/StrCase270615
! Node: gm2-libs/StrIO271845
! Node: gm2-libs/StrLib272620
! Node: gm2-libs/StringConvert274241
! Node: gm2-libs/SysExceptions285538
! Node: gm2-libs/SysStorage286522
! Node: gm2-libs/TimeString288220
! Node: gm2-libs/UnixArgs288639
! Node: gm2-libs/cbuiltin289065
! Node: gm2-libs/cgetopt297254
! Node: gm2-libs/cxxabi300037
! Node: gm2-libs/dtoa300590
! Node: gm2-libs/errno301672
! Node: gm2-libs/gdbif302090
! Node: gm2-libs/ldtoa303083
! Node: gm2-libs/libc304230
! Node: gm2-libs/libm316100
! Node: gm2-libs/sckt319084
! Node: gm2-libs/termios322882
! Node: gm2-libs/wrapc327897
! Node: PIM and Logitech 3.0 Compatible330385
! Node: gm2-libs-log/BitBlockOps333143
! Node: gm2-libs-log/BitByteOps337045
! Node: gm2-libs-log/BitWordOps339935
! Node: gm2-libs-log/BlockOps342781
! Node: gm2-libs-log/Break344954
! Node: gm2-libs-log/CardinalIO345965
! Node: gm2-libs-log/Conversions349783
! Node: gm2-libs-log/DebugPMD351166
! Node: gm2-libs-log/DebugTrace351428
! Node: gm2-libs-log/Delay351692
! Node: gm2-libs-log/Display352111
! Node: gm2-libs-log/ErrorCode352640
! Node: gm2-libs-log/FileSystem353516
! Node: gm2-libs-log/FloatingUtilities360166
! Node: gm2-libs-log/InOut361917
! Node: gm2-libs-log/Keyboard366263
! Node: gm2-libs-log/LongIO366922
! Node: gm2-libs-log/NumberConversion367374
! Node: gm2-libs-log/Random367705
! Node: gm2-libs-log/RealConversions369081
! Node: gm2-libs-log/RealInOut373962
! Node: gm2-libs-log/Strings376717
! Node: gm2-libs-log/Termbase378516
! Node: gm2-libs-log/Terminal381062
! Node: gm2-libs-log/TimeDate382578
! Node: PIM coroutine support384538
! Node: gm2-libs-coroutines/Executive385026
! Node: gm2-libs-coroutines/KeyBoardLEDs388677
! Node: gm2-libs-coroutines/SYSTEM389642
! Node: gm2-libs-coroutines/TimerHandler400137
! Node: M2 ISO Libraries402560
! Node: gm2-libs-iso/COROUTINES409152
! Node: gm2-libs-iso/ChanConsts413001
! Node: gm2-libs-iso/CharClass416352
! Node: gm2-libs-iso/ClientSocket417423
! Node: gm2-libs-iso/ComplexMath418528
! Node: gm2-libs-iso/ConvStringLong420853
! Node: gm2-libs-iso/ConvStringReal422173
! Node: gm2-libs-iso/ConvTypes423479
! Node: gm2-libs-iso/EXCEPTIONS424858
! Node: gm2-libs-iso/ErrnoCategory427017
! Node: gm2-libs-iso/GeneralUserExceptions428487
! Node: gm2-libs-iso/IOChan429684
! Node: gm2-libs-iso/IOConsts437172
! Node: gm2-libs-iso/IOLink437949
! Node: gm2-libs-iso/IOResult443772
! Node: gm2-libs-iso/LongComplexMath444804
! Node: gm2-libs-iso/LongConv447117
! Node: gm2-libs-iso/LongIO449294
! Node: gm2-libs-iso/LongMath451766
! Node: gm2-libs-iso/LongStr453625
! Node: gm2-libs-iso/LongWholeIO456211
! Node: gm2-libs-iso/LowLong458066
! Node: gm2-libs-iso/LowReal461640
! Node: gm2-libs-iso/LowShort465037
! Node: gm2-libs-iso/M2EXCEPTION468658
! Node: gm2-libs-iso/M2RTS469876
! Node: gm2-libs-iso/MemStream477676
! Node: gm2-libs-iso/Preemptive480948
! Node: gm2-libs-iso/Processes481449
! Node: gm2-libs-iso/ProgramArgs487264
! Node: gm2-libs-iso/RTco488333
! Node: gm2-libs-iso/RTdata490007
! Node: gm2-libs-iso/RTentity491294
! Node: gm2-libs-iso/RTfio492407
! Node: gm2-libs-iso/RTgen495033
! Node: gm2-libs-iso/RTgenif497998
! Node: gm2-libs-iso/RTio501978
! Node: gm2-libs-iso/RandomNumber503626
! Node: gm2-libs-iso/RawIO506045
! Node: gm2-libs-iso/RealConv506942
! Node: gm2-libs-iso/RealIO509055
! Node: gm2-libs-iso/RealMath511501
! Node: gm2-libs-iso/RealStr513275
! Node: gm2-libs-iso/RndFile515828
! Node: gm2-libs-iso/SIOResult520586
! Node: gm2-libs-iso/SLongIO521614
! Node: gm2-libs-iso/SLongWholeIO524038
! Node: gm2-libs-iso/SRawIO525848
! Node: gm2-libs-iso/SRealIO526732
! Node: gm2-libs-iso/SShortIO529044
! Node: gm2-libs-iso/SShortWholeIO531478
! Node: gm2-libs-iso/STextIO533299
! Node: gm2-libs-iso/SWholeIO535699
! Node: gm2-libs-iso/SYSTEM537489
! Node: gm2-libs-iso/Semaphores547405
! Node: gm2-libs-iso/SeqFile549020
! Node: gm2-libs-iso/ShortComplexMath553572
! Node: gm2-libs-iso/ShortIO555921
! Node: gm2-libs-iso/ShortWholeIO558415
! Node: gm2-libs-iso/SimpleCipher560284
! Node: gm2-libs-iso/StdChans561274
! Node: gm2-libs-iso/Storage563271
! Node: gm2-libs-iso/StreamFile565357
! Node: gm2-libs-iso/StringChan567417
! Node: gm2-libs-iso/Strings568632
! Node: gm2-libs-iso/SysClock576112
! Node: gm2-libs-iso/TERMINATION577915
! Node: gm2-libs-iso/TermFile578528
! Node: gm2-libs-iso/TextIO580823
! Node: gm2-libs-iso/TextUtil583451
! Node: gm2-libs-iso/WholeConv584092
! Node: gm2-libs-iso/WholeIO586622
! Node: gm2-libs-iso/WholeStr588460
! Node: gm2-libs-iso/wrapclock590251
! Node: gm2-libs-iso/wrapsock593868
! Node: gm2-libs-iso/wraptime596462
! Node: Indices600835
  
  End Tag Table
  
--- 21132,21350 ----
  
  
  Tag Table:
! Node: Top1079
! Node: Overview1559
! Node: What is GNU Modula-21917
! Ref: What is GNU Modula-2-Footnote-12390
! Node: Why use GNU Modula-22960
! Node: Development4546
! Node: Features4792
! Node: Using6476
! Node: Example usage8368
! Ref: Example usage-Footnote-19519
! Node: Compiler options9784
! Node: Linking23798
! Node: Elementary data types26931
! Node: Standard procedures28436
! Node: High procedure function37278
! Node: Dialect40263
! Node: Exceptions43673
! Ref: Exceptions-Footnote-144798
! Node: Semantic checking44954
! Node: Extensions48930
! Node: Type compatibility56895
! Node: Unbounded by reference63394
! Node: Building a shared library67465
! Node: Interface for Python68951
! Node: Producing a Python module74122
! Node: Interface to C79212
! Node: Assembly language82354
! Node: Alignment84411
! Node: Packed86946
! Node: Built-ins89667
! Node: The PIM system module102194
! Node: The ISO system module110692
! Node: Release map121142
! Node: Documentation121689
! Node: Regression tests121949
! Node: Limitations122772
! Node: Objectives123091
! Node: FAQ123575
! Node: Community124016
! Node: Other languages124364
! Node: License124607
! Node: Copying125521
! Node: Contributing163058
! Node: EBNF163762
! Node: Libraries178377
! Node: Base libraries178805
! Node: gm2-libs/ASCII181533
! Node: gm2-libs/Args182626
! Node: gm2-libs/Assertion183222
! Node: gm2-libs/Break183633
! Node: gm2-libs/Builtins183839
! Node: gm2-libs/COROUTINES193290
! Node: gm2-libs/CmdArgs193667
! Node: gm2-libs/Debug194368
! Node: gm2-libs/DynamicStrings195224
! Node: gm2-libs/Environment205135
! Node: gm2-libs/FIO206145
! Node: gm2-libs/FormatStrings215390
! Node: gm2-libs/FpuIO217056
! Node: gm2-libs/GetOpt218474
! Node: gm2-libs/IO221947
! Node: gm2-libs/Indexing223678
! Node: gm2-libs/LMathLib0226225
! Node: gm2-libs/LegacyReal226996
! Node: gm2-libs/M2Dependent227271
! Node: gm2-libs/M2EXCEPTION228689
! Node: gm2-libs/M2RTS229939
! Node: gm2-libs/MathLib0237647
! Node: gm2-libs/MemUtils238348
! Node: gm2-libs/NumberIO238949
! Node: gm2-libs/OptLib240836
! Node: gm2-libs/PushBackInput242734
! Node: gm2-libs/RTExceptions245348
! Node: gm2-libs/RTint249995
! Node: gm2-libs/SArgs252926
! Node: gm2-libs/SCmdArgs253686
! Node: gm2-libs/SEnvironment254417
! Node: gm2-libs/SFIO255407
! Node: gm2-libs/SMathLib0257672
! Node: gm2-libs/SYSTEM258450
! Node: gm2-libs/Scan265969
! Node: gm2-libs/Selective267855
! Node: gm2-libs/StdIO269750
! Node: gm2-libs/Storage271584
! Node: gm2-libs/StrCase272836
! Node: gm2-libs/StrIO274066
! Node: gm2-libs/StrLib274841
! Node: gm2-libs/StringConvert276462
! Node: gm2-libs/SysExceptions287759
! Node: gm2-libs/SysStorage288743
! Node: gm2-libs/TimeString290441
! Node: gm2-libs/UnixArgs290860
! Node: gm2-libs/cbuiltin291286
! Node: gm2-libs/cgetopt299475
! Node: gm2-libs/cxxabi302258
! Node: gm2-libs/dtoa302811
! Node: gm2-libs/errno303893
! Node: gm2-libs/gdbif304311
! Node: gm2-libs/ldtoa305304
! Node: gm2-libs/libc306451
! Node: gm2-libs/libm318321
! Node: gm2-libs/sckt321305
! Node: gm2-libs/termios325103
! Node: gm2-libs/wrapc330118
! Node: PIM and Logitech 3.0 Compatible332606
! Node: gm2-libs-log/BitBlockOps335364
! Node: gm2-libs-log/BitByteOps339266
! Node: gm2-libs-log/BitWordOps342156
! Node: gm2-libs-log/BlockOps345002
! Node: gm2-libs-log/Break347175
! Node: gm2-libs-log/CardinalIO348186
! Node: gm2-libs-log/Conversions352004
! Node: gm2-libs-log/DebugPMD353387
! Node: gm2-libs-log/DebugTrace353649
! Node: gm2-libs-log/Delay353913
! Node: gm2-libs-log/Display354332
! Node: gm2-libs-log/ErrorCode354861
! Node: gm2-libs-log/FileSystem355737
! Node: gm2-libs-log/FloatingUtilities362387
! Node: gm2-libs-log/InOut364138
! Node: gm2-libs-log/Keyboard368484
! Node: gm2-libs-log/LongIO369143
! Node: gm2-libs-log/NumberConversion369595
! Node: gm2-libs-log/Random369926
! Node: gm2-libs-log/RealConversions371302
! Node: gm2-libs-log/RealInOut376183
! Node: gm2-libs-log/Strings378938
! Node: gm2-libs-log/Termbase380737
! Node: gm2-libs-log/Terminal383283
! Node: gm2-libs-log/TimeDate384799
! Node: PIM coroutine support386759
! Node: gm2-libs-coroutines/Executive387259
! Node: gm2-libs-coroutines/KeyBoardLEDs390910
! Node: gm2-libs-coroutines/SYSTEM391875
! Node: gm2-libs-coroutines/TimerHandler402370
! Node: M2 ISO Libraries404793
! Node: gm2-libs-iso/COROUTINES411885
! Node: gm2-libs-iso/ChanConsts415734
! Node: gm2-libs-iso/CharClass419085
! Node: gm2-libs-iso/ClientSocket420156
! Node: gm2-libs-iso/ComplexMath421261
! Node: gm2-libs-iso/ConvStringLong423586
! Node: gm2-libs-iso/ConvStringReal424906
! Node: gm2-libs-iso/ConvTypes426212
! Node: gm2-libs-iso/EXCEPTIONS427591
! Node: gm2-libs-iso/ErrnoCategory429750
! Node: gm2-libs-iso/GeneralUserExceptions431220
! Node: gm2-libs-iso/IOChan432417
! Node: gm2-libs-iso/IOConsts439905
! Node: gm2-libs-iso/IOLink440682
! Node: gm2-libs-iso/IOResult446505
! Node: gm2-libs-iso/LongComplexMath447537
! Node: gm2-libs-iso/LongConv449850
! Node: gm2-libs-iso/LongIO452027
! Node: gm2-libs-iso/LongMath454499
! Node: gm2-libs-iso/LongStr456358
! Node: gm2-libs-iso/LongWholeIO458944
! Node: gm2-libs-iso/LowLong460799
! Node: gm2-libs-iso/LowReal464373
! Node: gm2-libs-iso/LowShort467770
! Node: gm2-libs-iso/M2EXCEPTION471391
! Node: gm2-libs-iso/M2RTS472609
! Node: gm2-libs-iso/MemStream480409
! Node: gm2-libs-iso/Preemptive483681
! Node: gm2-libs-iso/Processes484182
! Node: gm2-libs-iso/ProgramArgs489997
! Node: gm2-libs-iso/RTco491066
! Node: gm2-libs-iso/RTdata492740
! Node: gm2-libs-iso/RTentity494027
! Node: gm2-libs-iso/RTfio495140
! Node: gm2-libs-iso/RTgen497766
! Node: gm2-libs-iso/RTgenif500731
! Node: gm2-libs-iso/RTio504711
! Node: gm2-libs-iso/RandomNumber506359
! Node: gm2-libs-iso/RawIO508778
! Node: gm2-libs-iso/RealConv509675
! Node: gm2-libs-iso/RealIO511788
! Node: gm2-libs-iso/RealMath514234
! Node: gm2-libs-iso/RealStr516008
! Node: gm2-libs-iso/RndFile518561
! Node: gm2-libs-iso/SIOResult523319
! Node: gm2-libs-iso/SLongIO524347
! Node: gm2-libs-iso/SLongWholeIO526771
! Node: gm2-libs-iso/SRawIO528581
! Node: gm2-libs-iso/SRealIO529465
! Node: gm2-libs-iso/SShortIO531777
! Node: gm2-libs-iso/SShortWholeIO534211
! Node: gm2-libs-iso/STextIO536032
! Node: gm2-libs-iso/SWholeIO538432
! Node: gm2-libs-iso/SYSTEM540222
! Node: gm2-libs-iso/Semaphores550138
! Node: gm2-libs-iso/SeqFile551753
! Node: gm2-libs-iso/ShortComplexMath556305
! Node: gm2-libs-iso/ShortIO558654
! Node: gm2-libs-iso/ShortWholeIO561148
! Node: gm2-libs-iso/SimpleCipher563017
! Node: gm2-libs-iso/StdChans564007
! Node: gm2-libs-iso/Storage566004
! Node: gm2-libs-iso/StreamFile568090
! Node: gm2-libs-iso/StringChan570150
! Node: gm2-libs-iso/Strings571365
! Node: gm2-libs-iso/SysClock578845
! Node: gm2-libs-iso/TERMINATION580648
! Node: gm2-libs-iso/TermFile581261
! Node: gm2-libs-iso/TextIO583556
! Node: gm2-libs-iso/TextUtil586184
! Node: gm2-libs-iso/WholeConv586825
! Node: gm2-libs-iso/WholeIO589355
! Node: gm2-libs-iso/WholeStr591193
! Node: gm2-libs-iso/wrapclock592984
! Node: gm2-libs-iso/wrapsock596601
! Node: gm2-libs-iso/wraptime599195
! Node: Indices603568
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/dse.cc gcc-13.5.0-RC-20260904/gcc/dse.cc
*** gcc-13.4.0/gcc/dse.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/dse.cc	Fri Sep  4 07:35:08 2026
*************** canon_address (rtx mem,
*** 1186,1192 ****
        address = strip_offset_and_add (address, offset);
  
        if (ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (mem))
! 	  && const_or_frame_p (address))
  	{
  	  group_info *group = get_group_info (address);
  
--- 1186,1195 ----
        address = strip_offset_and_add (address, offset);
  
        if (ADDR_SPACE_GENERIC_P (MEM_ADDR_SPACE (mem))
! 	  && const_or_frame_p (address)
! 	  /* Literal addresses can alias any base, avoid creating a
! 	     group for them.  */
! 	  && ! CONST_SCALAR_INT_P (address))
  	{
  	  group_info *group = get_group_info (address);
  
diff -Nrcpad gcc-13.4.0/gcc/dwarf2out.cc gcc-13.5.0-RC-20260904/gcc/dwarf2out.cc
*** gcc-13.4.0/gcc/dwarf2out.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/dwarf2out.cc	Fri Sep  4 07:35:08 2026
*************** equate_type_number_to_die (tree type, dw
*** 5944,5950 ****
  static dw_die_ref maybe_create_die_with_external_ref (tree);
  struct GTY(()) sym_off_pair 
  {
!   const char * GTY((skip)) sym;
    unsigned HOST_WIDE_INT off;
  };
  static GTY(()) hash_map *external_die_map;
--- 5944,5950 ----
  static dw_die_ref maybe_create_die_with_external_ref (tree);
  struct GTY(()) sym_off_pair 
  {
!   const char *sym;
    unsigned HOST_WIDE_INT off;
  };
  static GTY(()) hash_map *external_die_map;
diff -Nrcpad gcc-13.4.0/gcc/expmed.cc gcc-13.5.0-RC-20260904/gcc/expmed.cc
*** gcc-13.4.0/gcc/expmed.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/expmed.cc	Fri Sep  4 07:35:08 2026
*************** make_tree (tree type, rtx x)
*** 5357,5362 ****
--- 5357,5365 ----
        t = wide_int_to_tree (type, rtx_mode_t (x, TYPE_MODE (type)));
        return t;
  
+     case CONST_POLY_INT:
+       return wide_int_to_tree (type, const_poly_int_value (x));
+ 
      case CONST_DOUBLE:
        STATIC_ASSERT (HOST_BITS_PER_WIDE_INT * 2 <= MAX_BITSIZE_MODE_ANY_INT);
        if (TARGET_SUPPORTS_WIDE_INT == 0 && GET_MODE (x) == VOIDmode)
*************** make_tree (tree type, rtx x)
*** 5448,5456 ****
        /* fall through.  */
  
      default:
-       if (CONST_POLY_INT_P (x))
- 	return wide_int_to_tree (t, const_poly_int_value (x));
- 
        t = build_decl (RTL_LOCATION (x), VAR_DECL, NULL_TREE, type);
  
        /* If TYPE is a POINTER_TYPE, we might need to convert X from
--- 5451,5456 ----
diff -Nrcpad gcc-13.4.0/gcc/fold-const.cc gcc-13.5.0-RC-20260904/gcc/fold-const.cc
*** gcc-13.4.0/gcc/fold-const.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fold-const.cc	Fri Sep  4 07:35:08 2026
*************** fold_binary_loc (location_t loc, enum tr
*** 11694,11710 ****
  	    {
  	      tree rtype = TREE_TYPE (TREE_TYPE (arg0));
  	      if (real_onep (TREE_IMAGPART (arg1)))
! 		return
! 		  fold_build2_loc (loc, COMPLEX_EXPR, type,
! 			       negate_expr (fold_build1_loc (loc, IMAGPART_EXPR,
! 							     rtype, arg0)),
! 			       fold_build1_loc (loc, REALPART_EXPR, rtype, arg0));
  	      else if (real_minus_onep (TREE_IMAGPART (arg1)))
! 		return
! 		  fold_build2_loc (loc, COMPLEX_EXPR, type,
! 			       fold_build1_loc (loc, IMAGPART_EXPR, rtype, arg0),
! 			       negate_expr (fold_build1_loc (loc, REALPART_EXPR,
! 							     rtype, arg0)));
  	    }
  
  	  /* Optimize z * conj(z) for floating point complex numbers.
--- 11694,11722 ----
  	    {
  	      tree rtype = TREE_TYPE (TREE_TYPE (arg0));
  	      if (real_onep (TREE_IMAGPART (arg1)))
! 		{
! 		  if (TREE_CODE (arg0) != COMPLEX_EXPR)
! 		    arg0 = save_expr (arg0);
! 		  tree iarg0 = fold_build1_loc (loc, IMAGPART_EXPR,
! 						rtype, arg0);
! 		  tree rarg0 = fold_build1_loc (loc, REALPART_EXPR,
! 						rtype, arg0);
! 		  return fold_build2_loc (loc, COMPLEX_EXPR, type,
! 					  negate_expr (iarg0),
! 					  rarg0);
! 		}
  	      else if (real_minus_onep (TREE_IMAGPART (arg1)))
! 		{
! 		  if (TREE_CODE (arg0) != COMPLEX_EXPR)
! 		    arg0 = save_expr (arg0);
! 		  tree iarg0 = fold_build1_loc (loc, IMAGPART_EXPR,
! 						rtype, arg0);
! 		  tree rarg0 = fold_build1_loc (loc, REALPART_EXPR,
! 						rtype, arg0);
! 		  return fold_build2_loc (loc, COMPLEX_EXPR, type,
! 					  iarg0,
! 					  negate_expr (rarg0));
! 		}
  	    }
  
  	  /* Optimize z * conj(z) for floating point complex numbers.
diff -Nrcpad gcc-13.4.0/gcc/fortran/ChangeLog gcc-13.5.0-RC-20260904/gcc/fortran/ChangeLog
*** gcc-13.4.0/gcc/fortran/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/ChangeLog	Fri Sep  4 07:35:08 2026
***************
*** 1,3 ****
--- 1,302 ----
+ 2026-08-05  Jerry DeLisle  
+ 
+ 	Backported from master:
+ 	2026-07-28  Jerry DeLisle  
+ 
+ 	PR fortran/125866
+ 	* expr.cc (is_CFI_desc): Add check for proc_name.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-27  Jakub Jelinek  
+ 
+ 	PR fortran/126303
+ 	* frontend-passes.cc (inner_loop_may_be_skipped): If inner loop iterator
+ 	is not integral, return true.
+ 
+ 2026-07-20  Mikael Morin  
+ 
+ 	Backported from master:
+ 	2026-07-03  Mikael Morin  
+ 
+ 	PR fortran/97592
+ 	PR fortran/125998
+ 	* trans-array.cc (gfc_conv_array_parameter): Always create a new
+ 	descriptor.  Copy lbound and ubound from the original descriptor
+ 	using matching dimension indexes.  Recalculate stride and
+ 	offset.
+ 
+ 2026-07-09  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-09  Christopher Albert  
+ 
+ 	PR fortran/103367
+ 	* trans-array.cc (gfc_conv_array_initializer): Emit an error for
+ 	invalid residual initializer expressions before returning a safe
+ 	empty constructor.
+ 
+ 2026-07-09  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-07  Christopher Albert  
+ 
+ 	PR fortran/103367
+ 	* trans-array.cc (gfc_conv_array_initializer): Return empty
+ 	constructor for unexpected expression types after parameter
+ 	substitution.
+ 
+ 2026-07-09  Jerry DeLisle  
+ 
+ 	Backported from master:
+ 	2026-07-07  Jerry DeLisle  
+ 
+ 	PR fortran/103367
+ 	* expr.cc (simplify_const_ref): Hoist the call to
+ 	remove_subobject_ref up a level.
+ 	* primary.cc (gfc_match_rvalue): Don't copy the value expr
+ 	if the type is an EXPR_VARIABLE.
+ 	* trans-array.cc (gfc_conv_array_initializer): Only copy the expr
+ 	value if it does not have a ref.
+ 
+ 2026-05-21  Thomas Koenig  
+ 
+ 	Backported from master:
+ 	2026-05-20  Thomas Koenig  
+ 
+ 	PR fortran/106546
+ 	* frontend-passes.cc (create_var): Set attr->automatic on
+ 	new symbol.
+ 	(create_do_loop): Likewise on iteration variable.
+ 
+ 2026-05-20  Thomas Koenig  
+ 
+ 	Backported from master:
+ 	2026-05-19  Thomas Koenig  
+ 
+ 	PR fortran/115260
+ 	* trans-expr.cc (gfc_conv_subref_array_arg): Pass false to
+ 	dealloc argument of gfc_trans_scalar_assign if we are
+ 	converting a g77-style argument.
+ 
+ 2026-05-14  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-08  Christopher Albert  
+ 
+ 	PR fortran/96986
+ 	* resolve.cc (resolve_global_procedure): Move entry symbol
+ 	lookup outside the resolved != -1 block.
+ 
+ 2026-05-13  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-10  Christopher Albert  
+ 
+ 	PR fortran/94978
+ 	* frontend-passes.cc (evaluate_loop_bound): New helper.
+ 	(inner_loop_may_be_skipped): New helper.
+ 	(do_subscript): Skip outer-loop bound warnings when nested inner loops
+ 	may be zero-trip for the substituted bound.
+ 
+ 2026-05-13  Paul Thomas  
+ 
+ 	Backported from master:
+ 	2026-03-16  Paul Thomas  
+ 		    Steve Kargl  
+ 
+ 	PR fortran/93832
+ 	* array.cc (resolve_array_bound): Emit error and return false
+ 	if bound expression is derived type or class.
+ 	* primary.cc (gfc_convert_to_structure_constructor): Do not
+ 	dereference NULL in character component test. Define 'shorter'
+ 	and use it help cure one of several whitespace issues.
+ 
+ 2026-05-13  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-11  Christopher Albert  
+ 
+ 	PR fortran/93814
+ 	* trans-decl.cc (build_entry_thunks): Create local result buffer
+ 	and length temporaries for bind(c) CHARACTER entry thunks when the
+ 	master returns by reference but the thunk returns by value.
+ 
+ 2026-05-13  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-08  Paul Thomas  
+ 
+ 	PR fortran/93715
+ 	* trans-decl.cc (gfc_trans_deferred_vars): Skip auto array
+ 	allocation for scalar coarrays.
+ 
+ 2026-05-09  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-07  Paul Thomas  
+ 
+ 	PR fortran/107425
+ 	* trans-decl.cc (gfc_finish_var_decl): Check for
+ 	omp_affinity_iterators namespace before FL_LABEL BLOCK check.
+ 	Only route actual iterator variables through add_decl_as_local;
+ 	add other variables to the enclosing function.
+ 
+ 2026-05-09  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-06  Christopher Albert  
+ 
+ 	PR fortran/79524
+ 	PR fortran/79524
+ 	* decl.cc (discard_pending_charlens): New helper.
+ 	(add_init_expr_to_sym): Drop statement-local charlens when
+ 	rejecting variable-length parameter arrays.
+ 	(variable_decl, do_parm, enumerator_decl): Save the current
+ 	namespace charlen list before parsing declarations with
+ 	initializers.
+ 	(match_procedure_decl): Adjust call to add_init_expr_to_sym.
+ 
+ 2026-04-17  Paul Thomas  
+ 
+ 	Backported from master:
+ 	2026-03-27  Paul Thomas  
+ 
+ 	PR fortran/102619
+ 	* trans-expr.cc (gfc_get_interface_mapping_array): Add argument
+ 	'assumed_rank_formal', which if true returns the descriptor in
+ 	'ifm'.
+ 	(gfc_add_interface_mapping): Detect an assumed rank formal arg
+ 	of a non-intrinsic function to set 'assumed_rank_formal' and
+ 	pass the descriptor to gfc_get_interface_mapping_array.
+ 
+ 2026-04-14  Harald Anlauf  
+ 
+ 	Backported from master:
+ 	2025-09-11  Harald Anlauf  
+ 
+ 	PR fortran/121616
+ 	* primary.cc (gfc_variable_attr): Properly set dimension attribute
+ 	from a component ref.
+ 
+ 2026-04-13  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-03-30  Christopher Albert  
+ 
+ 	* scanner.cc (skip_free_oacc_sentinel): Clear openmp_flag only for
+ 	fresh OpenACC directive lines.
+ 	(skip_free_omp_sentinel): Clear openacc_flag only for fresh OpenMP
+ 	directive lines.
+ 
+ 2026-04-13  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-13  Christopher Albert  
+ 
+ 	PR fortran/95879
+ 	PR fortran/95879
+ 	* parse.cc (fixup_st_func_formals): New function to update
+ 	statement function formal argument lists referencing a symbol
+ 	about to be freed.
+ 	(gfc_fixup_sibling_symbols): Call fixup_st_func_formals before
+ 	gfc_release_symbol.
+ 
+ 2026-04-02  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-02  Christopher Albert  
+ 
+ 	PR fortran/102596
+ 	* trans-openmp.cc (gfc_omp_clause_default_ctor): Only require an
+ 	outer reference when the constructor path actually uses it.
+ 
+ 2026-04-02  Paul Thomas  
+ 
+ 	Backported from master:
+ 	2026-04-02  Paul Thomas  
+ 
+ 	PR fortran/120286
+ 	* trans-openmp.cc (gfc_is_class_pointer_type): New helper.
+ 	(gfc_omp_clause_copy_ctor): Unwrap saved descriptors before
+ 	deciding whether privatization should preserve only pointer
+ 	association.  Handle scalar class pointers on that path too.
+ 	(gfc_omp_clause_dtor): Likewise.
+ 
+ 2026-03-30  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-03-11  Christopher Albert  
+ 
+ 	PR fortran/95338
+ 	* trans-types.cc (gfc_get_entry_result_type): New helper to use the
+ 	ABI return type for mixed ENTRY union fields.
+ 	(gfc_get_mixed_entry_union): Use it for each entry result field.
+ 
+ 2026-03-30  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-03-12  Christopher Albert  
+ 
+ 	PR fortran/106946
+ 	* decl.cc (gfc_match_data_decl): Remove CLASS components added by a
+ 	failed declaration in a derived type, and guard symtree deletion.
+ 	* gfortran.h (gfc_free_component, gfc_delete_symtree): Declare.
+ 	* symbol.cc (gfc_free_component): New function.
+ 	(free_components): Use it.
+ 	(gfc_delete_symtree): Make non-static.
+ 
+ 2026-03-29  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-03-13  Christopher Albert  
+ 
+ 	PR fortran/102459
+ 	* trans-openmp.cc (gfc_trans_omp_clauses): Choose the scalar
+ 	reference path from the full expression rank rather than the first
+ 	array reference.
+ 	(gfc_trans_omp_depobj): Likewise.
+ 
+ 2026-03-29  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-03-12  Christopher Albert  
+ 
+ 	PR fortran/82721
+ 	* decl.cc (discard_pending_charlen): New helper.
+ 	(build_sym): Discard unattached CHARACTER length nodes when
+ 	gfc_add_type rejects the declaration.
+ 
+ 2026-03-28  Paul Thomas  
+ 
+ 	Backported from master:
+ 	2026-03-28  Paul Thomas  
+ 
+ 	PR fortran/84245
+ 	* match.cc (gfc_match_select_type): Free the temporary namespace
+ 	only on MATCH_NO. Return immediately on MATCH_ERROR.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-12  Jakub Jelinek  
+ 
+ 	PR fortran/124450
+ 	* trans-io.cc (transfer_expr): If code is NULL, call
+ 	transfer_array_component with NULL where argument rather than
+ 	&code->loc.
+ 
+ 2025-10-05  Harald Anlauf  
+ 
+ 	Backported from master:
+ 	2025-09-03  Harald Anlauf  
+ 
+ 	PR fortran/121263
+ 	* trans-intrinsic.cc (gfc_conv_intrinsic_transfer): For an
+ 	unlimited polymorphic SOURCE to TRANSFER use saved descriptor
+ 	if possible.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/gcc/fortran/array.cc gcc-13.5.0-RC-20260904/gcc/fortran/array.cc
*** gcc-13.4.0/gcc/fortran/array.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/array.cc	Fri Sep  4 07:35:08 2026
*************** resolve_array_bound (gfc_expr *e, int ch
*** 382,387 ****
--- 382,394 ----
    if (e == NULL)
      return true;
  
+   if (e->ts.type == BT_DERIVED || e->ts.type == BT_CLASS)
+     {
+       gfc_error ("Derived type or class expression for array bound at %L",
+ 		 &e->where);
+       return false;
+     }
+ 
    if (!gfc_resolve_expr (e)
        || !gfc_specification_expr (e))
      return false;
diff -Nrcpad gcc-13.4.0/gcc/fortran/decl.cc gcc-13.5.0-RC-20260904/gcc/fortran/decl.cc
*** gcc-13.4.0/gcc/fortran/decl.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/decl.cc	Fri Sep  4 07:35:08 2026
*************** static gfc_expr *saved_kind_expr = NULL;
*** 116,121 ****
--- 116,156 ----
  static gfc_actual_arglist *decl_type_param_list;
  static gfc_actual_arglist *type_param_spec_list;
  
+ /* Drop an unattached gfc_charlen node from the current namespace.  This is
+    used when declaration processing created a length node for a symbol that is
+    rejected before the node is attached to any surviving symbol.  */
+ static void
+ discard_pending_charlen (gfc_charlen *cl)
+ {
+   if (!cl || !gfc_current_ns || gfc_current_ns->cl_list != cl)
+     return;
+ 
+   gfc_current_ns->cl_list = cl->next;
+   gfc_free_expr (cl->length);
+   free (cl);
+ }
+ 
+ /* Drop the charlen nodes created while matching a declaration that is about
+    to be rejected.  Callers must clear any surviving owners before using this
+    helper, so only the statement-local nodes remain on the namespace list.  */
+ 
+ static void
+ discard_pending_charlens (gfc_charlen *saved_cl)
+ {
+   if (!gfc_current_ns)
+     return;
+ 
+   while (gfc_current_ns->cl_list != saved_cl)
+     {
+       gfc_charlen *cl = gfc_current_ns->cl_list;
+ 
+       gcc_assert (cl);
+       gfc_current_ns->cl_list = cl->next;
+       gfc_free_expr (cl->length);
+       free (cl);
+     }
+ }
+ 
  /********************* DATA statement subroutines *********************/
  
  static bool in_match_data = false;
*************** build_sym (const char *name, int elem, g
*** 1772,1778 ****
        && (sym->attr.implicit_type == 0
  	  || !gfc_compare_types (&sym->ts, ¤t_ts))
        && !gfc_add_type (sym, ¤t_ts, var_locus))
!     return false;
  
    if (sym->ts.type == BT_CHARACTER)
      {
--- 1807,1826 ----
        && (sym->attr.implicit_type == 0
  	  || !gfc_compare_types (&sym->ts, ¤t_ts))
        && !gfc_add_type (sym, ¤t_ts, var_locus))
!     {
!       /* Duplicate-type rejection can leave a fresh CHARACTER length node on
! 	 the namespace list before it is attached to any surviving symbol.
! 	 Drop only that unattached node; shared constant charlen nodes are
! 	 already reachable from earlier declarations.  PR82721.  */
!       if (current_ts.type == BT_CHARACTER && cl && elem == 1)
! 	{
! 	  discard_pending_charlen (cl);
! 	  gfc_clear_ts (¤t_ts);
! 	}
!       else if (current_ts.type == BT_CHARACTER && cl && cl != current_ts.u.cl)
! 	discard_pending_charlen (cl);
!       return false;
!     }
  
    if (sym->ts.type == BT_CHARACTER)
      {
*************** fix_initializer_charlen (gfc_typespec *t
*** 2006,2012 ****
     expression to a symbol.  */
  
  static bool
! add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus)
  {
    symbol_attribute attr;
    gfc_symbol *sym;
--- 2054,2061 ----
     expression to a symbol.  */
  
  static bool
! add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus,
! 		      gfc_charlen *saved_cl_list)
  {
    symbol_attribute attr;
    gfc_symbol *sym;
*************** add_init_expr_to_sym (const char *name,
*** 2094,2099 ****
--- 2143,2158 ----
  					 "at %L "
  					 "with variable length elements",
  					 &sym->declared_at);
+ 
+ 			      /* This rejection path can leave several
+ 				 declaration-local charlens on cl_list,
+ 				 including the replacement symbol charlen and
+ 				 the array-constructor typespec charlen.
+ 				 Clear the surviving owners first, then drop
+ 				 only the nodes created by this declaration.  */
+ 			      sym->ts.u.cl = NULL;
+ 			      init->ts.u.cl = NULL;
+ 			      discard_pending_charlens (saved_cl_list);
  			      return false;
  			    }
  			  clen = mpz_get_si (length->value.integer);
*************** variable_decl (int elem)
*** 2610,2615 ****
--- 2669,2675 ----
    gfc_array_spec *as;
    gfc_array_spec *cp_as; /* Extra copy for Cray Pointees.  */
    gfc_charlen *cl;
+   gfc_charlen *saved_cl_list;
    bool cl_deferred;
    locus var_locus;
    match m;
*************** variable_decl (int elem)
*** 2620,2625 ****
--- 2680,2686 ----
    initializer = NULL;
    as = NULL;
    cp_as = NULL;
+   saved_cl_list = gfc_current_ns->cl_list;
  
    /* When we get here, we've just matched a list of attributes and
       maybe a type and a double colon.  The next thing we expect to see
*************** variable_decl (int elem)
*** 3158,3164 ****
       NULL here, because we sometimes also need to check if a
       declaration *must* have an initialization expression.  */
    if (!gfc_comp_struct (gfc_current_state ()))
!     t = add_init_expr_to_sym (name, &initializer, &var_locus);
    else
      {
        if (current_ts.type == BT_DERIVED
--- 3219,3226 ----
       NULL here, because we sometimes also need to check if a
       declaration *must* have an initialization expression.  */
    if (!gfc_comp_struct (gfc_current_state ()))
!     t = add_init_expr_to_sym (name, &initializer, &var_locus,
! 			      saved_cl_list);
    else
      {
        if (current_ts.type == BT_DERIVED
*************** gfc_match_data_decl (void)
*** 6276,6287 ****
--- 6338,6365 ----
    gfc_symbol *sym;
    match m;
    int elem;
+   gfc_component *comp_tail = NULL;
  
    type_param_spec_list = NULL;
    decl_type_param_list = NULL;
  
    num_idents_on_line = 0;
  
+   /* Record the last component before we start, so that we can roll back
+      any components added during this statement on error.  PR106946.
+      Must be set before any 'goto cleanup' with m == MATCH_ERROR.  */
+   if (gfc_comp_struct (gfc_current_state ()))
+     {
+       gfc_symbol *block = gfc_current_block ();
+       if (block)
+ 	{
+ 	  comp_tail = block->components;
+ 	  if (comp_tail)
+ 	    while (comp_tail->next)
+ 	      comp_tail = comp_tail->next;
+ 	}
+     }
+ 
    m = gfc_match_decl_type_spec (¤t_ts, 0);
    if (m != MATCH_YES)
      return m;
*************** ok:
*** 6401,6406 ****
--- 6479,6527 ----
    gfc_free_data_all (gfc_current_ns);
  
  cleanup:
+   /* If we failed inside a derived type definition, remove any CLASS
+      components that were added during this failed statement.  For CLASS
+      components, gfc_build_class_symbol creates an extra container symbol in
+      the namespace outside the normal undo machinery.  When reject_statement
+      later calls gfc_undo_symbols, the declaration state is rolled back but
+      that helper symbol survives and leaves the component dangling.  Ordinary
+      components do not create that extra helper symbol, so leave them in
+      place for the usual follow-up diagnostics.  PR106946.  */
+   if (m == MATCH_ERROR && gfc_comp_struct (gfc_current_state ()))
+     {
+       gfc_symbol *block = gfc_current_block ();
+       if (block)
+ 	{
+ 	  gfc_component **prev;
+ 	  if (comp_tail)
+ 	    prev = &comp_tail->next;
+ 	  else
+ 	    prev = &block->components;
+ 
+ 	  while (*prev)
+ 	    {
+ 	      gfc_component *c = *prev;
+ 	      if (c->ts.type == BT_CLASS && c->ts.u.derived
+ 		  && c->ts.u.derived->attr.is_class)
+ 		{
+ 		  /* Unlink this CLASS component.  */
+ 		  *prev = c->next;
+ 
+ 		  /* Remove the CLASS container from the namespace.  */
+ 		  gfc_symbol *fclass = c->ts.u.derived;
+ 		  if (gfc_find_symtree (fclass->ns->sym_root, fclass->name))
+ 		    gfc_delete_symtree (&fclass->ns->sym_root, fclass->name);
+ 		  gfc_release_symbol (fclass);
+ 
+ 		  /* Free the component structure.  */
+ 		  gfc_free_component (c);
+ 		}
+ 	      else
+ 		prev = &c->next;
+ 	    }
+ 	}
+     }
+ 
    if (saved_kind_expr)
      gfc_free_expr (saved_kind_expr);
    if (type_param_spec_list)
*************** match_procedure_decl (void)
*** 7204,7210 ****
  	  if (m != MATCH_YES)
  	    goto cleanup;
  
! 	  if (!add_init_expr_to_sym (sym->name, &initializer, &gfc_current_locus))
  	    goto cleanup;
  
  	}
--- 7325,7333 ----
  	  if (m != MATCH_YES)
  	    goto cleanup;
  
! 	  if (!add_init_expr_to_sym (sym->name, &initializer,
! 				     &gfc_current_locus,
! 				     gfc_current_ns->cl_list))
  	    goto cleanup;
  
  	}
*************** do_parm (void)
*** 9434,9442 ****
--- 9557,9568 ----
  {
    gfc_symbol *sym;
    gfc_expr *init;
+   gfc_charlen *saved_cl_list;
    match m;
    bool t;
  
+   saved_cl_list = gfc_current_ns->cl_list;
+ 
    m = gfc_match_symbol (&sym, 0);
    if (m == MATCH_NO)
      gfc_error ("Expected variable name at %C in PARAMETER statement");
*************** do_parm (void)
*** 9477,9483 ****
        goto cleanup;
      }
  
!   t = add_init_expr_to_sym (sym->name, &init, &gfc_current_locus);
    return (t) ? MATCH_YES : MATCH_ERROR;
  
  cleanup:
--- 9603,9610 ----
        goto cleanup;
      }
  
!   t = add_init_expr_to_sym (sym->name, &init, &gfc_current_locus,
! 			    saved_cl_list);
    return (t) ? MATCH_YES : MATCH_ERROR;
  
  cleanup:
*************** enumerator_decl (void)
*** 10888,10893 ****
--- 11015,11021 ----
    char name[GFC_MAX_SYMBOL_LEN + 1];
    gfc_expr *initializer;
    gfc_array_spec *as = NULL;
+   gfc_charlen *saved_cl_list;
    gfc_symbol *sym;
    locus var_locus;
    match m;
*************** enumerator_decl (void)
*** 10895,10900 ****
--- 11023,11029 ----
    locus old_locus;
  
    initializer = NULL;
+   saved_cl_list = gfc_current_ns->cl_list;
    old_locus = gfc_current_locus;
  
    /* When we get here, we've just matched a list of attributes and
*************** enumerator_decl (void)
*** 10951,10957 ****
       to be parsed.  add_init_expr_to_sym() zeros initializer, so we
       use last_initializer below.  */
    last_initializer = initializer;
!   t = add_init_expr_to_sym (name, &initializer, &var_locus);
  
    /* Maintain enumerator history.  */
    gfc_find_symbol (name, NULL, 0, &sym);
--- 11080,11087 ----
       to be parsed.  add_init_expr_to_sym() zeros initializer, so we
       use last_initializer below.  */
    last_initializer = initializer;
!   t = add_init_expr_to_sym (name, &initializer, &var_locus,
! 			    saved_cl_list);
  
    /* Maintain enumerator history.  */
    gfc_find_symbol (name, NULL, 0, &sym);
diff -Nrcpad gcc-13.4.0/gcc/fortran/expr.cc gcc-13.5.0-RC-20260904/gcc/fortran/expr.cc
*** gcc-13.4.0/gcc/fortran/expr.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/expr.cc	Fri Sep  4 07:35:08 2026
*************** is_CFI_desc (gfc_symbol *sym, gfc_expr *
*** 1120,1126 ****
        && e && e->expr_type == EXPR_VARIABLE)
      sym = e->symtree->n.sym;
  
!   if (sym && sym->attr.dummy
        && sym->ns->proc_name->attr.is_bind_c
        && (sym->attr.pointer
  	  || sym->attr.allocatable
--- 1120,1126 ----
        && e && e->expr_type == EXPR_VARIABLE)
      sym = e->symtree->n.sym;
  
!   if (sym && sym->attr.dummy && sym->ns && sym->ns->proc_name
        && sym->ns->proc_name->attr.is_bind_c
        && (sym->attr.pointer
  	  || sym->attr.allocatable
*************** simplify_const_ref (gfc_expr *p)
*** 1939,1954 ****
        switch (p->ref->type)
  	{
  	case REF_ARRAY:
! 	  switch (p->ref->u.ar.type)
  	    {
! 	    case AR_ELEMENT:
! 	      /* , parameter :: x() = scalar_expr
! 		 will generate this.  */
! 	      if (p->expr_type != EXPR_ARRAY)
  		{
! 		  remove_subobject_ref (p, NULL);
! 		  break;
  		}
  	      if (!find_array_element (p->value.constructor, &p->ref->u.ar, &cons))
  		return false;
  
--- 1939,1964 ----
        switch (p->ref->type)
  	{
  	case REF_ARRAY:
! 	  /* , parameter :: x() = scalar_expr
! 	     will generate this.  */
! 	  if (p->expr_type != EXPR_ARRAY)
  	    {
! 	      if (p->ref->u.ar.type == AR_ELEMENT)
  		{
! 		  int dim;
! 		  for (dim = 0; dim < p->ref->u.ar.dimen; dim++)
! 		    if (!p->ref->u.ar.start[dim]
! 			|| p->ref->u.ar.start[dim]->expr_type != EXPR_CONSTANT)
! 		      return true;
  		}
+ 
+ 	      remove_subobject_ref (p, NULL);
+ 	      break;
+ 	    }
+ 
+ 	  switch (p->ref->u.ar.type)
+ 	    {
+ 	    case AR_ELEMENT:
  	      if (!find_array_element (p->value.constructor, &p->ref->u.ar, &cons))
  		return false;
  
diff -Nrcpad gcc-13.4.0/gcc/fortran/frontend-passes.cc gcc-13.5.0-RC-20260904/gcc/fortran/frontend-passes.cc
*** gcc-13.4.0/gcc/fortran/frontend-passes.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/frontend-passes.cc	Fri Sep  4 07:35:08 2026
*************** create_var (gfc_expr * e, const char *vn
*** 846,851 ****
--- 846,852 ----
    symbol->attr.referenced = 1;
    symbol->attr.dimension = e->rank > 0;
    symbol->attr.fe_temp = 1;
+   symbol->attr.automatic = 1;
    gfc_commit_symbol (symbol);
  
    result = gfc_get_expr ();
*************** insert_index (gfc_expr *e, gfc_symbol *s
*** 2784,2789 ****
--- 2785,2853 ----
  
  }
  
+ static bool
+ evaluate_loop_bound (gfc_expr *e, gfc_symbol *sym, mpz_t val, mpz_t ret)
+ {
+   if (e->expr_type == EXPR_CONSTANT)
+     {
+       mpz_init_set (ret, e->value.integer);
+       return true;
+     }
+ 
+   return insert_index (e, sym, val, ret);
+ }
+ 
+ /* Return true if any loop nested inside LOOP_INDEX is not provably entered
+    after substituting OUTER_VAL for OUTER_SYM.  In that case the guarded array
+    reference may never be evaluated, so do not warn from the outer loop alone.  */
+ 
+ static bool
+ inner_loop_may_be_skipped (int loop_index, gfc_symbol *outer_sym, mpz_t outer_val)
+ {
+   int k;
+   do_t *lp;
+ 
+   FOR_EACH_VEC_ELT_FROM (doloop_list, k, lp, loop_index + 1)
+     {
+       gfc_code *loop = lp->c;
+       int sgn, cmp;
+       mpz_t do_start, do_end, do_step;
+ 
+       if (loop == NULL || loop->ext.iterator == NULL || loop->ext.iterator->var == NULL)
+ 	return true;
+ 
+       if (loop->ext.iterator->var->symtree->n.sym->ts.type != BT_INTEGER)
+ 	return true;
+ 
+       if (!evaluate_loop_bound (loop->ext.iterator->step, outer_sym, outer_val, do_step))
+ 	return true;
+ 
+       sgn = mpz_cmp_ui (do_step, 0);
+       if (sgn == 0)
+ 	{
+ 	  mpz_clear (do_step);
+ 	  return true;
+ 	}
+ 
+       if (!evaluate_loop_bound (loop->ext.iterator->start, outer_sym, outer_val, do_start)
+ 	  || !evaluate_loop_bound (loop->ext.iterator->end, outer_sym, outer_val, do_end))
+ 	{
+ 	  mpz_clear (do_step);
+ 	  return true;
+ 	}
+ 
+       cmp = mpz_cmp (do_end, do_start);
+       mpz_clear (do_start);
+       mpz_clear (do_end);
+       mpz_clear (do_step);
+ 
+       if ((sgn > 0 && cmp < 0) || (sgn < 0 && cmp > 0))
+ 	return true;
+     }
+ 
+   return false;
+ }
+ 
  /* Check array subscripts for possible out-of-bounds accesses in DO
     loops with constant bounds.  */
  
*************** do_subscript (gfc_expr **e)
*** 2918,2927 ****
  		  mpz_clear (rem);
  		}
  
  	      for (i = 0; i< ar->dimen; i++)
  		{
  		  mpz_t val;
! 		  if (ar->dimen_type[i] == DIMEN_ELEMENT && have_do_start
  		      && insert_index (ar->start[i], do_sym, do_start, val))
  		    {
  		      if (ar->as->lower[i]
--- 2982,2996 ----
  		  mpz_clear (rem);
  		}
  
+ 	      bool skip_start = have_do_start
+ 				&& inner_loop_may_be_skipped (j, do_sym, do_start);
+ 	      bool skip_end = have_do_end
+ 			      && inner_loop_may_be_skipped (j, do_sym, do_end);
+ 
  	      for (i = 0; i< ar->dimen; i++)
  		{
  		  mpz_t val;
! 		  if (ar->dimen_type[i] == DIMEN_ELEMENT && have_do_start && !skip_start
  		      && insert_index (ar->start[i], do_sym, do_start, val))
  		    {
  		      if (ar->as->lower[i]
*************** do_subscript (gfc_expr **e)
*** 2947,2953 ****
  		      mpz_clear (val);
  		    }
  
! 		  if (ar->dimen_type[i] == DIMEN_ELEMENT && have_do_end
  		      && insert_index (ar->start[i], do_sym, do_end, val))
  		    {
  		      if (ar->as->lower[i]
--- 3016,3022 ----
  		      mpz_clear (val);
  		    }
  
! 		  if (ar->dimen_type[i] == DIMEN_ELEMENT && have_do_end && !skip_end
  		      && insert_index (ar->start[i], do_sym, do_end, val))
  		    {
  		      if (ar->as->lower[i]
*************** create_do_loop (gfc_expr *start, gfc_exp
*** 3781,3786 ****
--- 3850,3856 ----
    symbol->attr.referenced = 1;
    symbol->attr.dimension = 0;
    symbol->attr.fe_temp = 1;
+   symbol->attr.automatic = 1;
    gfc_commit_symbol (symbol);
  
    i = gfc_get_expr ();
diff -Nrcpad gcc-13.4.0/gcc/fortran/gfortran.h gcc-13.5.0-RC-20260904/gcc/fortran/gfortran.h
*** gcc-13.4.0/gcc/fortran/gfortran.h	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/gfortran.h	Fri Sep  4 07:35:08 2026
*************** bool gfc_missing_attr (symbol_attribute
*** 3470,3475 ****
--- 3470,3476 ----
  bool gfc_copy_attr (symbol_attribute *, symbol_attribute *, locus *);
  int gfc_copy_dummy_sym (gfc_symbol **, gfc_symbol *, int);
  bool gfc_add_component (gfc_symbol *, const char *, gfc_component **);
+ void gfc_free_component (gfc_component *);
  gfc_symbol *gfc_use_derived (gfc_symbol *);
  gfc_component *gfc_find_component (gfc_symbol *, const char *, bool, bool,
                                     gfc_ref **);
*************** bool gfc_reference_st_label (gfc_st_labe
*** 3481,3486 ****
--- 3482,3488 ----
  
  gfc_namespace *gfc_get_namespace (gfc_namespace *, int);
  gfc_symtree *gfc_new_symtree (gfc_symtree **, const char *);
+ void gfc_delete_symtree (gfc_symtree **, const char *);
  gfc_symtree *gfc_find_symtree (gfc_symtree *, const char *);
  void gfc_delete_symtree (gfc_symtree **, const char *);
  gfc_symtree *gfc_get_unique_symtree (gfc_namespace *);
diff -Nrcpad gcc-13.4.0/gcc/fortran/gfortran.info gcc-13.5.0-RC-20260904/gcc/fortran/gfortran.info
*** gcc-13.4.0/gcc/fortran/gfortran.info	Thu Jun  5 16:30:32 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/gfortran.info	Fri Sep  4 07:57:50 2026
***************
*** 1,7 ****
! This is gfortran.info, produced by makeinfo version 6.8 from
  gfortran.texi.
  
! Copyright (C) 1999-2023 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
--- 1,7 ----
! This is gfortran.info, produced by makeinfo version 7.1 from
  gfortran.texi.
  
! Copyright © 1999-2023 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
*************** START-INFO-DIR-ENTRY
*** 26,37 ****
  END-INFO-DIR-ENTRY
  
     This file documents the use and the internals of the GNU Fortran
! compiler, ('gfortran').
  
     Published by the Free Software Foundation 51 Franklin Street, Fifth
  Floor Boston, MA 02110-1301 USA
  
!    Copyright (C) 1999-2023 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
--- 26,37 ----
  END-INFO-DIR-ENTRY
  
     This file documents the use and the internals of the GNU Fortran
! compiler, (‘gfortran’).
  
     Published by the Free Software Foundation 51 Franklin Street, Fifth
  Floor Boston, MA 02110-1301 USA
  
!    Copyright © 1999-2023 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
*************** File: gfortran.info,  Node: Top,  Next:
*** 57,64 ****
  Introduction
  ************
  
! This manual documents the use of 'gfortran', the GNU Fortran compiler.
! You can find in this manual how to invoke 'gfortran', as well as its
  features and incompatibilities.
  
  * Menu:
--- 57,64 ----
  Introduction
  ************
  
! This manual documents the use of ‘gfortran’, the GNU Fortran compiler.
! You can find in this manual how to invoke ‘gfortran’, as well as its
  features and incompatibilities.
  
  * Menu:
*************** features and incompatibilities.
*** 66,72 ****
  * Introduction::
  
  Part I: Invoking GNU Fortran
! * Invoking GNU Fortran:: Command options supported by 'gfortran'.
  * Runtime::              Influencing runtime behavior with environment variables.
  
  Part II: Language Reference
--- 66,72 ----
  * Introduction::
  
  Part I: Invoking GNU Fortran
! * Invoking GNU Fortran:: Command options supported by ‘gfortran’.
  * Runtime::              Influencing runtime behavior with environment variables.
  
  Part II: Language Reference
*************** File: gfortran.info,  Node: About GNU Fo
*** 104,113 ****
  1.1 About GNU Fortran
  =====================
  
! The GNU Fortran compiler is the successor to 'g77', the Fortran 77 front
  end included in GCC prior to version 4 (released in 2005).  While it is
! backward-compatible with most 'g77' extensions and command-line options,
! 'gfortran' is a completely new implemention designed to support more
  modern dialects of Fortran.  GNU Fortran implements the Fortran 77, 90
  and 95 standards completely, most of the Fortran 2003 and 2008
  standards, and some features from the 2018 standard.  It also implements
--- 104,113 ----
  1.1 About GNU Fortran
  =====================
  
! The GNU Fortran compiler is the successor to ‘g77’, the Fortran 77 front
  end included in GCC prior to version 4 (released in 2005).  While it is
! backward-compatible with most ‘g77’ extensions and command-line options,
! ‘gfortran’ is a completely new implemention designed to support more
  modern dialects of Fortran.  GNU Fortran implements the Fortran 77, 90
  and 95 standards completely, most of the Fortran 2003 and 2008
  standards, and some features from the 2018 standard.  It also implements
*************** see .
  
     Deferred-length character strings of Fortran 2003 supports part of
! the features of 'ISO_VARYING_STRING' and should be considered as
  replacement.  (Namely, allocatable or pointers of the type
! 'character(len=:)'.)
  
     Part 3 of the Fortran 95 standard (ISO/IEC 1539-3:1998) defines
  Conditional Compilation, which is not widely used and not directly
--- 288,296 ----
  .
  
     Deferred-length character strings of Fortran 2003 supports part of
! the features of ‘ISO_VARYING_STRING’ and should be considered as
  replacement.  (Namely, allocatable or pointers of the type
! ‘character(len=:)’.)
  
     Part 3 of the Fortran 95 standard (ISO/IEC 1539-3:1998) defines
  Conditional Compilation, which is not widely used and not directly
*************** the wiki (https://gcc.gnu.org/wiki/Fortr
*** 319,329 ****
  information about the current implementation status.  In particular, the
  following are not yet supported:
  
!    * 'DO CONCURRENT' and 'FORALL' do not recognize a type-spec in the
       loop header.
  
!    * The change to permit any constant expression in subscripts and
!      nested implied-do limits in a 'DATA' statement has not been
       implemented.
  
  
--- 319,329 ----
  information about the current implementation status.  In particular, the
  following are not yet supported:
  
!    • ‘DO CONCURRENT’ and ‘FORALL’ do not recognize a type-spec in the
       loop header.
  
!    • The change to permit any constant expression in subscripts and
!      nested implied-do limits in a ‘DATA’ statement has not been
       implemented.
  
  
*************** Fortran 2018 (ISO/IEC 1539:2018) is the
*** 336,370 ****
  Fortran language standard.  GNU Fortran implements some of the new
  features of this standard:
  
!    * All Fortran 2018 features derived from ISO/IEC TS 29113:2012,
       "Further Interoperability of Fortran with C", are supported by GNU
       Fortran.  This includes assumed-type and assumed-rank objects and
!      the 'SELECT RANK' construct as well as the parts relating to
!      'BIND(C)' functions.  See also *note Further Interoperability of
       Fortran with C::.
  
!    * GNU Fortran supports a subset of features derived from ISO/IEC TS
       18508:2015, "Additional Parallel Features in Fortran":
  
!         * The new atomic ADD, CAS, FETCH and ADD/OR/XOR, OR and XOR
            intrinsics.
  
!         * The 'CO_MIN' and 'CO_MAX' and 'SUM' reduction intrinsics, and
!           the 'CO_BROADCAST' and 'CO_REDUCE' intrinsic, except that
            those do not support polymorphic types or types with
            allocatable, pointer or polymorphic components.
  
!         * Events ('EVENT POST', 'EVENT WAIT', 'EVENT_QUERY').
  
!         * Failed images ('FAIL IMAGE', 'IMAGE_STATUS', 'FAILED_IMAGES',
!           'STOPPED_IMAGES').
  
!    * An 'ERROR STOP' statement is permitted in a 'PURE' procedure.
  
!    * GNU Fortran supports the 'IMPLICIT NONE' statement with an
!      'implicit-none-spec-list'.
  
!    * The behavior of the 'INQUIRE' statement with the 'RECL=' specifier
       now conforms to Fortran 2018.
  
  
--- 336,370 ----
  Fortran language standard.  GNU Fortran implements some of the new
  features of this standard:
  
!    • All Fortran 2018 features derived from ISO/IEC TS 29113:2012,
       "Further Interoperability of Fortran with C", are supported by GNU
       Fortran.  This includes assumed-type and assumed-rank objects and
!      the ‘SELECT RANK’ construct as well as the parts relating to
!      ‘BIND(C)’ functions.  See also *note Further Interoperability of
       Fortran with C::.
  
!    • GNU Fortran supports a subset of features derived from ISO/IEC TS
       18508:2015, "Additional Parallel Features in Fortran":
  
!         • The new atomic ADD, CAS, FETCH and ADD/OR/XOR, OR and XOR
            intrinsics.
  
!         • The ‘CO_MIN’ and ‘CO_MAX’ and ‘SUM’ reduction intrinsics, and
!           the ‘CO_BROADCAST’ and ‘CO_REDUCE’ intrinsic, except that
            those do not support polymorphic types or types with
            allocatable, pointer or polymorphic components.
  
!         • Events (‘EVENT POST’, ‘EVENT WAIT’, ‘EVENT_QUERY’).
  
!         • Failed images (‘FAIL IMAGE’, ‘IMAGE_STATUS’, ‘FAILED_IMAGES’,
!           ‘STOPPED_IMAGES’).
  
!    • An ‘ERROR STOP’ statement is permitted in a ‘PURE’ procedure.
  
!    • GNU Fortran supports the ‘IMPLICIT NONE’ statement with an
!      ‘implicit-none-spec-list’.
  
!    • The behavior of the ‘INQUIRE’ statement with the ‘RECL=’ specifier
       now conforms to Fortran 2018.
  
  
*************** File: gfortran.info,  Node: Invoking GNU
*** 373,397 ****
  2 GNU Fortran Command Options
  *****************************
  
! The 'gfortran' command supports all the options supported by the 'gcc'
  command.  Only options specific to GNU Fortran are documented here.
  
     *Note GCC Command Options: (gcc)Invoking GCC, for information on the
! non-Fortran-specific aspects of the 'gcc' command (and, therefore, the
! 'gfortran' command).
  
!    All GCC and GNU Fortran options are accepted both by 'gfortran' and
! by 'gcc' (as well as any other drivers built at the same time, such as
! 'g++'), since adding GNU Fortran to the GCC distribution enables
  acceptance of GNU Fortran options by all of the relevant drivers.
  
     In some cases, options have 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.
  
  * Menu:
  
! * Option Summary::      Brief list of all 'gfortran' options,
                          without explanations.
  * Fortran Dialect Options::  Controlling the variant of Fortran language
                               compiled.
--- 373,397 ----
  2 GNU Fortran Command Options
  *****************************
  
! The ‘gfortran’ command supports all the options supported by the ‘gcc’
  command.  Only options specific to GNU Fortran are documented here.
  
     *Note GCC Command Options: (gcc)Invoking GCC, for information on the
! non-Fortran-specific aspects of the ‘gcc’ command (and, therefore, the
! ‘gfortran’ command).
  
!    All GCC and GNU Fortran options are accepted both by ‘gfortran’ and
! by ‘gcc’ (as well as any other drivers built at the same time, such as
! ‘g++’), since adding GNU Fortran to the GCC distribution enables
  acceptance of GNU Fortran options by all of the relevant drivers.
  
     In some cases, options have 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.
  
  * Menu:
  
! * Option Summary::      Brief list of all ‘gfortran’ options,
                          without explanations.
  * Fortran Dialect Options::  Controlling the variant of Fortran language
                               compiled.
*************** these two forms, whichever one is not th
*** 405,411 ****
                          and register usage.
  * Interoperability Options::  Options for interoperability with other
                                languages.
! * Environment Variables:: Environment variables that affect 'gfortran'.
  
  
  File: gfortran.info,  Node: Option Summary,  Next: Fortran Dialect Options,  Up: Invoking GNU Fortran
--- 405,411 ----
                          and register usage.
  * Interoperability Options::  Options for interoperability with other
                                languages.
! * Environment Variables:: Environment variables that affect ‘gfortran’.
  
  
  File: gfortran.info,  Node: Option Summary,  Next: Fortran Dialect Options,  Up: Invoking GNU Fortran
*************** File: gfortran.info,  Node: Fortran Dial
*** 513,807 ****
  The following options control the details of the Fortran dialect
  accepted by the compiler:
  
! '-ffree-form'
! '-ffixed-form'
       Specify the layout used by the source file.  The free form layout
       was introduced in Fortran 90.  Fixed form was traditionally used in
       older Fortran programs.  When neither option is specified, the
       source form is determined by the file extension.
  
! '-fall-intrinsics'
       This option causes all intrinsic procedures (including the
       GNU-specific extensions) to be accepted.  This can be useful with
!      '-std=' to force standard-compliance but get access to the full
!      range of intrinsics available with 'gfortran'.  As a consequence,
!      '-Wintrinsics-std' will be ignored and no user-defined procedure
       with the same name as any intrinsic will be called except when it
!      is explicitly declared 'EXTERNAL'.
  
! '-fallow-argument-mismatch'
       Some code contains calls to external procedures with mismatches
       between the calls and the procedure definition, or with mismatches
       between different calls.  Such code is non-conforming, and will
       usually be flagged with an error.  This options degrades the error
       to a warning, which can only be disabled by disabling all warnings
!      via '-w'.  Only a single occurrence per argument is flagged by this
!      warning.  '-fallow-argument-mismatch' is implied by '-std=legacy'.
  
       Using this option is _strongly_ discouraged.  It is possible to
       provide standard-conforming code which allows different types of
!      arguments by using an explicit interface and 'TYPE(*)'.
  
! '-fallow-invalid-boz'
       A BOZ literal constant can occur in a limited number of contexts in
       standard conforming Fortran.  This option degrades an error
       condition to a warning, and allows a BOZ literal constant to appear
       where the Fortran standard would otherwise prohibit its use.
  
! '-fd-lines-as-code'
! '-fd-lines-as-comments'
!      Enable special treatment for lines beginning with 'd' or 'D' in
!      fixed form sources.  If the '-fd-lines-as-code' option is given
       they are treated as if the first column contained a blank.  If the
!      '-fd-lines-as-comments' option is given, they are treated as
       comment lines.
  
! '-fdec'
       DEC compatibility mode.  Enables extensions and other features that
       mimic the default behavior of older compilers (such as DEC). These
       features are non-standard and should be avoided at all costs.  For
       details on GNU Fortran's implementation of these extensions see the
       full documentation.
  
!      Other flags enabled by this switch are: '-fdollar-ok'
!      '-fcray-pointer' '-fdec-char-conversions' '-fdec-structure'
!      '-fdec-intrinsic-ints' '-fdec-static' '-fdec-math' '-fdec-include'
!      '-fdec-blank-format-item' '-fdec-format-defaults'
  
!      If '-fd-lines-as-code'/'-fd-lines-as-comments' are unset, then
!      '-fdec' also sets '-fd-lines-as-comments'.
  
! '-fdec-char-conversions'
!      Enable the use of character literals in assignments and 'DATA'
       statements for non-character variables.
  
! '-fdec-structure'
!      Enable DEC 'STRUCTURE' and 'RECORD' as well as 'UNION', 'MAP', and
       dot ('.')  as a member separator (in addition to '%').  This is
       provided for compatibility only; Fortran 90 derived types should be
       used instead where possible.
  
! '-fdec-intrinsic-ints'
       Enable B/I/J/K kind variants of existing integer functions (e.g.
       BIAND, IIAND, JIAND, etc...).  For a complete list of intrinsics
       see the full documentation.
  
! '-fdec-math'
       Enable legacy math intrinsics such as COTAN and degree-valued
       trigonometric functions (e.g.  TAND, ATAND, etc...)  for
       compatability with older code.
  
! '-fdec-static'
       Enable DEC-style STATIC and AUTOMATIC attributes to explicitly
       specify the storage of variables and other objects.
  
! '-fdec-include'
       Enable parsing of INCLUDE as a statement in addition to parsing it
       as INCLUDE line.  When parsed as INCLUDE statement, INCLUDE does
       not have to be on a single line and can use line continuations.
  
! '-fdec-format-defaults'
       Enable format specifiers F, G and I to be used without width
       specifiers, default widths will be used instead.
  
! '-fdec-blank-format-item'
       Enable a blank format item at the end of a format specification
       i.e.  nothing following the final comma.
  
! '-fdollar-ok'
!      Allow '$' as a valid non-first character in a symbol name.  Symbols
!      that start with '$' are rejected since it is unclear which rules to
       apply to implicit typing as different vendors implement different
!      rules.  Using '$' in 'IMPLICIT' statements is also rejected.
  
! '-fbackslash'
       Change the interpretation of backslashes in string literals from a
       single backslash character to "C-style" escape characters.  The
!      following combinations are expanded '\a', '\b', '\f', '\n', '\r',
!      '\t', '\v', '\\', and '\0' to the ASCII characters alert,
       backspace, form feed, newline, carriage return, horizontal tab,
       vertical tab, backslash, and NUL, respectively.  Additionally,
!      '\x'NN, '\u'NNNN and '\U'NNNNNNNN (where each N is a hexadecimal
       digit) are translated into the Unicode characters corresponding to
       the specified code points.  All other combinations of a character
       preceded by \ are unexpanded.
  
! '-fmodule-private'
!      Set the default accessibility of module entities to 'PRIVATE'.
       Use-associated entities will not be accessible unless they are
!      explicitly declared as 'PUBLIC'.
  
! '-ffixed-line-length-N'
       Set column after which characters are ignored in typical fixed-form
!      lines in the source file, and, unless '-fno-pad-source', through
       which spaces are assumed (as if padded to that length) after the
       ends of short fixed-form lines.
  
       Popular values for N include 72 (the standard and the default), 80
       (card image), and 132 (corresponding to "extended-source" options
!      in some popular compilers).  N may also be 'none', meaning that the
       entire line is meaningful and that continued character constants
       never have implicit spaces appended to them to fill out the line.
!      '-ffixed-line-length-0' means the same thing as
!      '-ffixed-line-length-none'.
  
! '-fno-pad-source'
       By default fixed-form lines have spaces assumed (as if padded to
       that length) after the ends of short fixed-form lines.  This is not
!      done either if '-ffixed-line-length-0', '-ffixed-line-length-none'
!      or if '-fno-pad-source' option is used.  With any of those options
       continued character constants never have implicit spaces appended
       to them to fill out the line.
  
! '-ffree-line-length-N'
       Set column after which characters are ignored in typical free-form
       lines in the source file.  The default value is 132.  N may be
!      'none', meaning that the entire line is meaningful.
!      '-ffree-line-length-0' means the same thing as
!      '-ffree-line-length-none'.
  
! '-fmax-identifier-length=N'
       Specify the maximum allowed identifier length.  Typical values are
       31 (Fortran 95) and 63 (Fortran 2003 and later).
  
! '-fimplicit-none'
       Specify that no implicit typing is allowed, unless overridden by
!      explicit 'IMPLICIT' statements.  This is the equivalent of adding
!      'implicit none' to the start of every procedure.
  
! '-fcray-pointer'
       Enable the Cray pointer extension, which provides C-like pointer
       functionality.
  
! '-fopenacc'
!      Enable the OpenACC extensions.  This includes OpenACC '!$acc'
!      directives in free form and 'c$acc', '*$acc' and '!$acc' directives
!      in fixed form, '!$' conditional compilation sentinels in free form
!      and 'c$', '*$' and '!$' sentinels in fixed form, and when linking
       arranges for the OpenACC runtime library to be linked in.
  
! '-fopenmp'
!      Enable the OpenMP extensions.  This includes OpenMP '!$omp'
!      directives in free form and 'c$omp', '*$omp' and '!$omp' directives
!      in fixed form, '!$' conditional compilation sentinels in free form
!      and 'c$', '*$' and '!$' sentinels in fixed form, and when linking
       arranges for the OpenMP runtime library to be linked in.  The
!      option '-fopenmp' implies '-frecursive'.
  
! '-fno-range-check'
       Disable range checking on results of simplification of constant
       expressions during compilation.  For example, GNU Fortran will give
!      an error at compile time when simplifying 'a = 1. / 0'.  With this
!      option, no error will be given and 'a' will be assigned the value
!      '+Infinity'.  If an expression evaluates to a value outside of the
!      relevant range of ['-HUGE()':'HUGE()'], then the expression will be
!      replaced by '-Inf' or '+Inf' as appropriate.  Similarly, 'DATA
!      i/Z'FFFFFFFF'/' will result in an integer overflow on most systems,
!      but with '-fno-range-check' the value will "wrap around" and 'i'
       will be initialized to -1 instead.
  
! '-fdefault-integer-8'
       Set the default integer and logical types to an 8 byte wide type.
!      This option also affects the kind of integer constants like '42'.
!      Unlike '-finteger-4-integer-8', it does not promote variables with
       explicit kind declaration.
  
! '-fdefault-real-8'
       Set the default real type to an 8 byte wide type.  This option also
!      affects the kind of non-double real constants like '1.0'.  This
!      option promotes the default width of 'DOUBLE PRECISION' and double
!      real constants like '1.d0' to 16 bytes if possible.  If
!      '-fdefault-double-8' is given along with 'fdefault-real-8', 'DOUBLE
!      PRECISION' and double real constants are not promoted.  Unlike
!      '-freal-4-real-8', 'fdefault-real-8' does not promote variables
       with explicit kind declarations.
  
! '-fdefault-real-10'
       Set the default real type to an 10 byte wide type.  This option
!      also affects the kind of non-double real constants like '1.0'.
!      This option promotes the default width of 'DOUBLE PRECISION' and
!      double real constants like '1.d0' to 16 bytes if possible.  If
!      '-fdefault-double-8' is given along with 'fdefault-real-10',
!      'DOUBLE PRECISION' and double real constants are not promoted.
!      Unlike '-freal-4-real-10', 'fdefault-real-10' does not promote
       variables with explicit kind declarations.
  
! '-fdefault-real-16'
       Set the default real type to an 16 byte wide type.  This option
!      also affects the kind of non-double real constants like '1.0'.
!      This option promotes the default width of 'DOUBLE PRECISION' and
!      double real constants like '1.d0' to 16 bytes if possible.  If
!      '-fdefault-double-8' is given along with 'fdefault-real-16',
!      'DOUBLE PRECISION' and double real constants are not promoted.
!      Unlike '-freal-4-real-16', 'fdefault-real-16' does not promote
       variables with explicit kind declarations.
  
! '-fdefault-double-8'
!      Set the 'DOUBLE PRECISION' type and double real constants like
!      '1.d0' to an 8 byte wide type.  Do nothing if this is already the
!      default.  This option prevents '-fdefault-real-8',
!      '-fdefault-real-10', and '-fdefault-real-16', from promoting
!      'DOUBLE PRECISION' and double real constants like '1.d0' to 16
       bytes.
  
! '-finteger-4-integer-8'
!      Promote all 'INTEGER(KIND=4)' entities to an 'INTEGER(KIND=8)'
!      entities.  If 'KIND=8' is unavailable, then an error will be
       issued.  This option should be used with care and may not be
       suitable for your codes.  Areas of possible concern include calls
!      to external procedures, alignment in 'EQUIVALENCE' and/or 'COMMON',
       generic interfaces, BOZ literal constant conversion, and I/O.
       Inspection of the intermediate representation of the translated
!      Fortran code, produced by '-fdump-tree-original', is suggested.
  
! '-freal-4-real-8'
! '-freal-4-real-10'
! '-freal-4-real-16'
! '-freal-8-real-4'
! '-freal-8-real-10'
! '-freal-8-real-16'
!      Promote all 'REAL(KIND=M)' entities to 'REAL(KIND=N)' entities.  If
!      'REAL(KIND=N)' is unavailable, then an error will be issued.  The
!      '-freal-4-' flags also affect the default real kind and the
!      '-freal-8-' flags also the double-precision real kind.  All other
       real-kind types are unaffected by this option.  The promotion is
       also applied to real literal constants of default and
       double-precision kind and a specified kind number of 4 or 8,
!      respectively.  However, '-fdefault-real-8', '-fdefault-real-10',
!      '-fdefault-real-10', and '-fdefault-double-8' take precedence for
       the default and double-precision real kinds, both for real literal
       constants and for declarations without a kind number.  Note that
!      for 'REAL(KIND=KIND(1.0))' the literal may get promoted and then
       the result may get promoted again.  These options should be used
       with care and may not be suitable for your codes.  Areas of
       possible concern include calls to external procedures, alignment in
!      'EQUIVALENCE' and/or 'COMMON', generic interfaces, BOZ literal
       constant conversion, and I/O and calls to intrinsic procedures when
!      passing a value to the 'kind=' dummy argument.  Inspection of the
       intermediate representation of the translated Fortran code,
!      produced by '-fdump-fortran-original' or '-fdump-tree-original', is
       suggested.
  
! '-std=STD'
       Specify the standard to which the program is expected to conform,
!      which may be one of 'f95', 'f2003', 'f2008', 'f2018', 'gnu', or
!      'legacy'.  The default value for STD is 'gnu', which specifies a
       superset of the latest Fortran standard that includes all of the
       extensions supported by GNU Fortran, although warnings will be
       given for obsolete extensions not recommended for use in new code.
!      The 'legacy' value is equivalent but without the warnings for
       obsolete extensions, and may be useful for old non-standard
!      programs.  The 'f95', 'f2003', 'f2008', and 'f2018' values specify
       strict conformance to the Fortran 95, Fortran 2003, Fortran 2008
       and Fortran 2018 standards, respectively; errors are given for all
       extensions beyond the relevant language standard, and warnings are
       given for the Fortran 77 features that are permitted but
       obsolescent in later standards.  The deprecated option
!      '-std=f2008ts' acts as an alias for '-std=f2018'.  It is only
       present for backwards compatibility with earlier gfortran versions
       and should not be used any more.
  
! '-ftest-forall-temp'
       Enhance test coverage by forcing most forall assignments to use
       temporary.
  
--- 513,807 ----
  The following options control the details of the Fortran dialect
  accepted by the compiler:
  
! ‘-ffree-form’
! ‘-ffixed-form’
       Specify the layout used by the source file.  The free form layout
       was introduced in Fortran 90.  Fixed form was traditionally used in
       older Fortran programs.  When neither option is specified, the
       source form is determined by the file extension.
  
! ‘-fall-intrinsics’
       This option causes all intrinsic procedures (including the
       GNU-specific extensions) to be accepted.  This can be useful with
!      ‘-std=’ to force standard-compliance but get access to the full
!      range of intrinsics available with ‘gfortran’.  As a consequence,
!      ‘-Wintrinsics-std’ will be ignored and no user-defined procedure
       with the same name as any intrinsic will be called except when it
!      is explicitly declared ‘EXTERNAL’.
  
! ‘-fallow-argument-mismatch’
       Some code contains calls to external procedures with mismatches
       between the calls and the procedure definition, or with mismatches
       between different calls.  Such code is non-conforming, and will
       usually be flagged with an error.  This options degrades the error
       to a warning, which can only be disabled by disabling all warnings
!      via ‘-w’.  Only a single occurrence per argument is flagged by this
!      warning.  ‘-fallow-argument-mismatch’ is implied by ‘-std=legacy’.
  
       Using this option is _strongly_ discouraged.  It is possible to
       provide standard-conforming code which allows different types of
!      arguments by using an explicit interface and ‘TYPE(*)’.
  
! ‘-fallow-invalid-boz’
       A BOZ literal constant can occur in a limited number of contexts in
       standard conforming Fortran.  This option degrades an error
       condition to a warning, and allows a BOZ literal constant to appear
       where the Fortran standard would otherwise prohibit its use.
  
! ‘-fd-lines-as-code’
! ‘-fd-lines-as-comments’
!      Enable special treatment for lines beginning with ‘d’ or ‘D’ in
!      fixed form sources.  If the ‘-fd-lines-as-code’ option is given
       they are treated as if the first column contained a blank.  If the
!      ‘-fd-lines-as-comments’ option is given, they are treated as
       comment lines.
  
! ‘-fdec’
       DEC compatibility mode.  Enables extensions and other features that
       mimic the default behavior of older compilers (such as DEC). These
       features are non-standard and should be avoided at all costs.  For
       details on GNU Fortran's implementation of these extensions see the
       full documentation.
  
!      Other flags enabled by this switch are: ‘-fdollar-ok’
!      ‘-fcray-pointer’ ‘-fdec-char-conversions’ ‘-fdec-structure’
!      ‘-fdec-intrinsic-ints’ ‘-fdec-static’ ‘-fdec-math’ ‘-fdec-include’
!      ‘-fdec-blank-format-item’ ‘-fdec-format-defaults’
  
!      If ‘-fd-lines-as-code’/‘-fd-lines-as-comments’ are unset, then
!      ‘-fdec’ also sets ‘-fd-lines-as-comments’.
  
! ‘-fdec-char-conversions’
!      Enable the use of character literals in assignments and ‘DATA’
       statements for non-character variables.
  
! ‘-fdec-structure’
!      Enable DEC ‘STRUCTURE’ and ‘RECORD’ as well as ‘UNION’, ‘MAP’, and
       dot ('.')  as a member separator (in addition to '%').  This is
       provided for compatibility only; Fortran 90 derived types should be
       used instead where possible.
  
! ‘-fdec-intrinsic-ints’
       Enable B/I/J/K kind variants of existing integer functions (e.g.
       BIAND, IIAND, JIAND, etc...).  For a complete list of intrinsics
       see the full documentation.
  
! ‘-fdec-math’
       Enable legacy math intrinsics such as COTAN and degree-valued
       trigonometric functions (e.g.  TAND, ATAND, etc...)  for
       compatability with older code.
  
! ‘-fdec-static’
       Enable DEC-style STATIC and AUTOMATIC attributes to explicitly
       specify the storage of variables and other objects.
  
! ‘-fdec-include’
       Enable parsing of INCLUDE as a statement in addition to parsing it
       as INCLUDE line.  When parsed as INCLUDE statement, INCLUDE does
       not have to be on a single line and can use line continuations.
  
! ‘-fdec-format-defaults’
       Enable format specifiers F, G and I to be used without width
       specifiers, default widths will be used instead.
  
! ‘-fdec-blank-format-item’
       Enable a blank format item at the end of a format specification
       i.e.  nothing following the final comma.
  
! ‘-fdollar-ok’
!      Allow ‘$’ as a valid non-first character in a symbol name.  Symbols
!      that start with ‘$’ are rejected since it is unclear which rules to
       apply to implicit typing as different vendors implement different
!      rules.  Using ‘$’ in ‘IMPLICIT’ statements is also rejected.
  
! ‘-fbackslash’
       Change the interpretation of backslashes in string literals from a
       single backslash character to "C-style" escape characters.  The
!      following combinations are expanded ‘\a’, ‘\b’, ‘\f’, ‘\n’, ‘\r’,
!      ‘\t’, ‘\v’, ‘\\’, and ‘\0’ to the ASCII characters alert,
       backspace, form feed, newline, carriage return, horizontal tab,
       vertical tab, backslash, and NUL, respectively.  Additionally,
!      ‘\x’NN, ‘\u’NNNN and ‘\U’NNNNNNNN (where each N is a hexadecimal
       digit) are translated into the Unicode characters corresponding to
       the specified code points.  All other combinations of a character
       preceded by \ are unexpanded.
  
! ‘-fmodule-private’
!      Set the default accessibility of module entities to ‘PRIVATE’.
       Use-associated entities will not be accessible unless they are
!      explicitly declared as ‘PUBLIC’.
  
! ‘-ffixed-line-length-N’
       Set column after which characters are ignored in typical fixed-form
!      lines in the source file, and, unless ‘-fno-pad-source’, through
       which spaces are assumed (as if padded to that length) after the
       ends of short fixed-form lines.
  
       Popular values for N include 72 (the standard and the default), 80
       (card image), and 132 (corresponding to "extended-source" options
!      in some popular compilers).  N may also be ‘none’, meaning that the
       entire line is meaningful and that continued character constants
       never have implicit spaces appended to them to fill out the line.
!      ‘-ffixed-line-length-0’ means the same thing as
!      ‘-ffixed-line-length-none’.
  
! ‘-fno-pad-source’
       By default fixed-form lines have spaces assumed (as if padded to
       that length) after the ends of short fixed-form lines.  This is not
!      done either if ‘-ffixed-line-length-0’, ‘-ffixed-line-length-none’
!      or if ‘-fno-pad-source’ option is used.  With any of those options
       continued character constants never have implicit spaces appended
       to them to fill out the line.
  
! ‘-ffree-line-length-N’
       Set column after which characters are ignored in typical free-form
       lines in the source file.  The default value is 132.  N may be
!      ‘none’, meaning that the entire line is meaningful.
!      ‘-ffree-line-length-0’ means the same thing as
!      ‘-ffree-line-length-none’.
  
! ‘-fmax-identifier-length=N’
       Specify the maximum allowed identifier length.  Typical values are
       31 (Fortran 95) and 63 (Fortran 2003 and later).
  
! ‘-fimplicit-none’
       Specify that no implicit typing is allowed, unless overridden by
!      explicit ‘IMPLICIT’ statements.  This is the equivalent of adding
!      ‘implicit none’ to the start of every procedure.
  
! ‘-fcray-pointer’
       Enable the Cray pointer extension, which provides C-like pointer
       functionality.
  
! ‘-fopenacc’
!      Enable the OpenACC extensions.  This includes OpenACC ‘!$acc’
!      directives in free form and ‘c$acc’, ‘*$acc’ and ‘!$acc’ directives
!      in fixed form, ‘!$’ conditional compilation sentinels in free form
!      and ‘c$’, ‘*$’ and ‘!$’ sentinels in fixed form, and when linking
       arranges for the OpenACC runtime library to be linked in.
  
! ‘-fopenmp’
!      Enable the OpenMP extensions.  This includes OpenMP ‘!$omp’
!      directives in free form and ‘c$omp’, ‘*$omp’ and ‘!$omp’ directives
!      in fixed form, ‘!$’ conditional compilation sentinels in free form
!      and ‘c$’, ‘*$’ and ‘!$’ sentinels in fixed form, and when linking
       arranges for the OpenMP runtime library to be linked in.  The
!      option ‘-fopenmp’ implies ‘-frecursive’.
  
! ‘-fno-range-check’
       Disable range checking on results of simplification of constant
       expressions during compilation.  For example, GNU Fortran will give
!      an error at compile time when simplifying ‘a = 1. / 0’.  With this
!      option, no error will be given and ‘a’ will be assigned the value
!      ‘+Infinity’.  If an expression evaluates to a value outside of the
!      relevant range of [‘-HUGE()’:‘HUGE()’], then the expression will be
!      replaced by ‘-Inf’ or ‘+Inf’ as appropriate.  Similarly, ‘DATA
!      i/Z'FFFFFFFF'/’ will result in an integer overflow on most systems,
!      but with ‘-fno-range-check’ the value will "wrap around" and ‘i’
       will be initialized to -1 instead.
  
! ‘-fdefault-integer-8’
       Set the default integer and logical types to an 8 byte wide type.
!      This option also affects the kind of integer constants like ‘42’.
!      Unlike ‘-finteger-4-integer-8’, it does not promote variables with
       explicit kind declaration.
  
! ‘-fdefault-real-8’
       Set the default real type to an 8 byte wide type.  This option also
!      affects the kind of non-double real constants like ‘1.0’.  This
!      option promotes the default width of ‘DOUBLE PRECISION’ and double
!      real constants like ‘1.d0’ to 16 bytes if possible.  If
!      ‘-fdefault-double-8’ is given along with ‘fdefault-real-8’, ‘DOUBLE
!      PRECISION’ and double real constants are not promoted.  Unlike
!      ‘-freal-4-real-8’, ‘fdefault-real-8’ does not promote variables
       with explicit kind declarations.
  
! ‘-fdefault-real-10’
       Set the default real type to an 10 byte wide type.  This option
!      also affects the kind of non-double real constants like ‘1.0’.
!      This option promotes the default width of ‘DOUBLE PRECISION’ and
!      double real constants like ‘1.d0’ to 16 bytes if possible.  If
!      ‘-fdefault-double-8’ is given along with ‘fdefault-real-10’,
!      ‘DOUBLE PRECISION’ and double real constants are not promoted.
!      Unlike ‘-freal-4-real-10’, ‘fdefault-real-10’ does not promote
       variables with explicit kind declarations.
  
! ‘-fdefault-real-16’
       Set the default real type to an 16 byte wide type.  This option
!      also affects the kind of non-double real constants like ‘1.0’.
!      This option promotes the default width of ‘DOUBLE PRECISION’ and
!      double real constants like ‘1.d0’ to 16 bytes if possible.  If
!      ‘-fdefault-double-8’ is given along with ‘fdefault-real-16’,
!      ‘DOUBLE PRECISION’ and double real constants are not promoted.
!      Unlike ‘-freal-4-real-16’, ‘fdefault-real-16’ does not promote
       variables with explicit kind declarations.
  
! ‘-fdefault-double-8’
!      Set the ‘DOUBLE PRECISION’ type and double real constants like
!      ‘1.d0’ to an 8 byte wide type.  Do nothing if this is already the
!      default.  This option prevents ‘-fdefault-real-8’,
!      ‘-fdefault-real-10’, and ‘-fdefault-real-16’, from promoting
!      ‘DOUBLE PRECISION’ and double real constants like ‘1.d0’ to 16
       bytes.
  
! ‘-finteger-4-integer-8’
!      Promote all ‘INTEGER(KIND=4)’ entities to an ‘INTEGER(KIND=8)’
!      entities.  If ‘KIND=8’ is unavailable, then an error will be
       issued.  This option should be used with care and may not be
       suitable for your codes.  Areas of possible concern include calls
!      to external procedures, alignment in ‘EQUIVALENCE’ and/or ‘COMMON’,
       generic interfaces, BOZ literal constant conversion, and I/O.
       Inspection of the intermediate representation of the translated
!      Fortran code, produced by ‘-fdump-tree-original’, is suggested.
  
! ‘-freal-4-real-8’
! ‘-freal-4-real-10’
! ‘-freal-4-real-16’
! ‘-freal-8-real-4’
! ‘-freal-8-real-10’
! ‘-freal-8-real-16’
!      Promote all ‘REAL(KIND=M)’ entities to ‘REAL(KIND=N)’ entities.  If
!      ‘REAL(KIND=N)’ is unavailable, then an error will be issued.  The
!      ‘-freal-4-’ flags also affect the default real kind and the
!      ‘-freal-8-’ flags also the double-precision real kind.  All other
       real-kind types are unaffected by this option.  The promotion is
       also applied to real literal constants of default and
       double-precision kind and a specified kind number of 4 or 8,
!      respectively.  However, ‘-fdefault-real-8’, ‘-fdefault-real-10’,
!      ‘-fdefault-real-10’, and ‘-fdefault-double-8’ take precedence for
       the default and double-precision real kinds, both for real literal
       constants and for declarations without a kind number.  Note that
!      for ‘REAL(KIND=KIND(1.0))’ the literal may get promoted and then
       the result may get promoted again.  These options should be used
       with care and may not be suitable for your codes.  Areas of
       possible concern include calls to external procedures, alignment in
!      ‘EQUIVALENCE’ and/or ‘COMMON’, generic interfaces, BOZ literal
       constant conversion, and I/O and calls to intrinsic procedures when
!      passing a value to the ‘kind=’ dummy argument.  Inspection of the
       intermediate representation of the translated Fortran code,
!      produced by ‘-fdump-fortran-original’ or ‘-fdump-tree-original’, is
       suggested.
  
! ‘-std=STD’
       Specify the standard to which the program is expected to conform,
!      which may be one of ‘f95’, ‘f2003’, ‘f2008’, ‘f2018’, ‘gnu’, or
!      ‘legacy’.  The default value for STD is ‘gnu’, which specifies a
       superset of the latest Fortran standard that includes all of the
       extensions supported by GNU Fortran, although warnings will be
       given for obsolete extensions not recommended for use in new code.
!      The ‘legacy’ value is equivalent but without the warnings for
       obsolete extensions, and may be useful for old non-standard
!      programs.  The ‘f95’, ‘f2003’, ‘f2008’, and ‘f2018’ values specify
       strict conformance to the Fortran 95, Fortran 2003, Fortran 2008
       and Fortran 2018 standards, respectively; errors are given for all
       extensions beyond the relevant language standard, and warnings are
       given for the Fortran 77 features that are permitted but
       obsolescent in later standards.  The deprecated option
!      ‘-std=f2008ts’ acts as an alias for ‘-std=f2018’.  It is only
       present for backwards compatibility with earlier gfortran versions
       and should not be used any more.
  
! ‘-ftest-forall-temp’
       Enhance test coverage by forcing most forall assignments to use
       temporary.
  
*************** code through a C preprocessor (CPP; some
*** 816,843 ****
  preprocessor, FPP) to allow for conditional compilation.  In the case of
  GNU Fortran, this is the GNU C Preprocessor in the traditional mode.  On
  systems with case-preserving file names, the preprocessor is
! automatically invoked if the filename extension is '.F', '.FOR', '.FTN',
! '.fpp', '.FPP', '.F90', '.F95', '.F03' or '.F08'.  To manually invoke
! the preprocessor on any file, use '-cpp', to disable preprocessing on
! files where the preprocessor is run automatically, use '-nocpp'.
  
     If a preprocessed file includes another file with the Fortran
! 'INCLUDE' statement, the included file is not preprocessed.  To
  preprocess included files, use the equivalent preprocessor statement
! '#include'.
  
!    If GNU Fortran invokes the preprocessor, '__GFORTRAN__' is defined.
! The macros '__GNUC__', '__GNUC_MINOR__' and '__GNUC_PATCHLEVEL__' can be
  used to determine the version of the compiler.  See *note Overview:
  (cpp)Top. for details.
  
!    GNU Fortran supports a number of 'INTEGER' and 'REAL' kind types in
  additional to the kind types required by the Fortran standard.  The
  availability of any given kind type is architecture dependent.  The
  following pre-defined preprocessor macros can be used to conditionally
! include code for these additional kind types: '__GFC_INT_1__',
! '__GFC_INT_2__', '__GFC_INT_8__', '__GFC_INT_16__', '__GFC_REAL_10__',
! and '__GFC_REAL_16__'.
  
     While CPP is the de-facto standard for preprocessing Fortran code,
  Part 3 of the Fortran 95 standard (ISO/IEC 1539-3:1998) defines
--- 816,843 ----
  preprocessor, FPP) to allow for conditional compilation.  In the case of
  GNU Fortran, this is the GNU C Preprocessor in the traditional mode.  On
  systems with case-preserving file names, the preprocessor is
! automatically invoked if the filename extension is ‘.F’, ‘.FOR’, ‘.FTN’,
! ‘.fpp’, ‘.FPP’, ‘.F90’, ‘.F95’, ‘.F03’ or ‘.F08’.  To manually invoke
! the preprocessor on any file, use ‘-cpp’, to disable preprocessing on
! files where the preprocessor is run automatically, use ‘-nocpp’.
  
     If a preprocessed file includes another file with the Fortran
! ‘INCLUDE’ statement, the included file is not preprocessed.  To
  preprocess included files, use the equivalent preprocessor statement
! ‘#include’.
  
!    If GNU Fortran invokes the preprocessor, ‘__GFORTRAN__’ is defined.
! The macros ‘__GNUC__’, ‘__GNUC_MINOR__’ and ‘__GNUC_PATCHLEVEL__’ can be
  used to determine the version of the compiler.  See *note Overview:
  (cpp)Top. for details.
  
!    GNU Fortran supports a number of ‘INTEGER’ and ‘REAL’ kind types in
  additional to the kind types required by the Fortran standard.  The
  availability of any given kind type is architecture dependent.  The
  following pre-defined preprocessor macros can be used to conditionally
! include code for these additional kind types: ‘__GFC_INT_1__’,
! ‘__GFC_INT_2__’, ‘__GFC_INT_8__’, ‘__GFC_INT_16__’, ‘__GFC_REAL_10__’,
! and ‘__GFC_REAL_16__’.
  
     While CPP is the de-facto standard for preprocessing Fortran code,
  Part 3 of the Fortran 95 standard (ISO/IEC 1539-3:1998) defines
*************** preprocess such files (', 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'.
  
! '-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'.
  
! '-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.
  
! '-undef'
       Do not predefine any system-specific or GCC-specific macros.  The
       standard predefined macros remain defined.
  
! '-APREDICATE=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.
  
! '-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 ''#''.
  
       Warning: this currently handles C-Style comments only.  The
       preprocessor does not yet recognize Fortran-style comments.
  
! '-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.
  
       Warning: this currently handles C- and C++-Style comments only.
       The preprocessor does not yet recognize Fortran-style comments.
  
! '-DNAME'
!      Predefine name as a macro, with definition '1'.
  
! '-DNAME=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.
  
--- 901,998 ----
       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.
  
! ‘-idirafter DIR’
       Search DIR for include 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’.
  
! ‘-imultilib DIR’
       Use DIR as a subdirectory of the directory containing
       target-specific C++ headers.
  
! ‘-iprefix PREFIX’
!      Specify PREFIX as the prefix for subsequent ‘-iwithprefix’ options.
       If the PREFIX represents a directory, you should include the final
!      ‘'/'’.
  
! ‘-isysroot DIR’
!      This option is like the ‘--sysroot’ option, but applies only to
!      header files.  See the ‘--sysroot’ option for more information.
  
! ‘-iquote DIR’
!      Search DIR only for header files requested with ‘#include "file"’;
!      they are not searched for ‘#include ’, 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’.
  
! ‘-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’.
  
! ‘-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.
  
! ‘-undef’
       Do not predefine any system-specific or GCC-specific macros.  The
       standard predefined macros remain defined.
  
! ‘-APREDICATE=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.
  
! ‘-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 ‘'#'’.
  
       Warning: this currently handles C-Style comments only.  The
       preprocessor does not yet recognize Fortran-style comments.
  
! ‘-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.
  
       Warning: this currently handles C- and C++-Style comments only.
       The preprocessor does not yet recognize Fortran-style comments.
  
! ‘-DNAME’
!      Predefine name as a macro, with definition ‘1’.
  
! ‘-DNAME=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.
  
*************** preprocess such files ('
  
!      'none'
            Disable coarray support; using coarray declarations and
            image-control statements will produce a compile-time error.
            (Default)
  
!      'single'
!           Single-image mode, i.e.  'num_images()' is always one.
  
!      'lib'
            Library-based coarray parallelization; a suitable GNU Fortran
            coarray library needs to be linked.
  
! '-fcheck='
  
       Enable the generation of run-time checks; the argument shall be a
       comma-delimited list of the following keywords.  Prefixing a check
!      with 'no-' disables it if it was activated by a previous
       specification.
  
!      'all'
!           Enable all run-time test of '-fcheck'.
  
!      'array-temps'
            Warns at run time when for passing an actual argument a
            temporary array had to be generated.  The information
            generated by this warning is sometimes useful in optimization,
--- 1661,1700 ----
       names with underscores to avoid naming collisions with external
       names.
  
!      This option has no effect if ‘-fno-underscoring’ is in effect.  It
!      is implied by the ‘-ff2c’ option.
  
!      Otherwise, with this option, an external name such as ‘MAX_COUNT’
       is implemented as a reference to the link-time external symbol
!      ‘max_count__’, instead of ‘max_count_’.  This is required for
!      compatibility with ‘g77’ and ‘f2c’, and is implied by use of the
!      ‘-ff2c’ option.
  
! ‘-fcoarray=’
  
!      ‘none’
            Disable coarray support; using coarray declarations and
            image-control statements will produce a compile-time error.
            (Default)
  
!      ‘single’
!           Single-image mode, i.e.  ‘num_images()’ is always one.
  
!      ‘lib’
            Library-based coarray parallelization; a suitable GNU Fortran
            coarray library needs to be linked.
  
! ‘-fcheck=’
  
       Enable the generation of run-time checks; the argument shall be a
       comma-delimited list of the following keywords.  Prefixing a check
!      with ‘no-’ disables it if it was activated by a previous
       specification.
  
!      ‘all’
!           Enable all run-time test of ‘-fcheck’.
  
!      ‘array-temps’
            Warns at run time when for passing an actual argument a
            temporary array had to be generated.  The information
            generated by this warning is sometimes useful in optimization,
*************** the other form by either removing 'no-'
*** 1702,1712 ****
  
            Note: The warning is only printed once per location.
  
!      'bits'
            Enable generation of run-time checks for invalid arguments to
            the bit manipulation intrinsics.
  
!      'bounds'
            Enable generation of run-time checks for array subscripts and
            against the declared minimum and maximum values.  It also
            checks array indices for assumed and deferred shape arrays
--- 1702,1712 ----
  
            Note: The warning is only printed once per location.
  
!      ‘bits’
            Enable generation of run-time checks for invalid arguments to
            the bit manipulation intrinsics.
  
!      ‘bounds’
            Enable generation of run-time checks for array subscripts and
            against the declared minimum and maximum values.  It also
            checks array indices for assumed and deferred shape arrays
*************** the other form by either removing 'no-'
*** 1714,1755 ****
            string lengths are equal for character array constructors
            without an explicit typespec.
  
!           Some checks require that '-fcheck=bounds' is set for the
            compilation of the main program.
  
            Note: In the future this may also include other forms of
            checking, e.g., checking substring references.
  
!      'do'
            Enable generation of run-time checks for invalid modification
            of loop iteration variables.
  
!      'mem'
            Enable generation of run-time checks for memory allocation.
            Note: This option does not affect explicit allocations using
!           the 'ALLOCATE' statement, which will be always checked.
  
!      'pointer'
            Enable generation of run-time checks for pointers and
            allocatables.
  
!      'recursion'
            Enable generation of run-time checks for recursively called
            subroutines and functions which are not marked as recursive.
!           See also '-frecursive'.  Note: This check does not work for
            OpenMP programs and is disabled if used together with
!           '-frecursive' and '-fopenmp'.
  
!      Example: Assuming you have a file 'foo.f90', the command
              gfortran -fcheck=all,no-array-temps foo.f90
       will compile the file with all checks enabled as specified above
       except warnings for generated array temporaries.
  
! '-fbounds-check'
!      Deprecated alias for '-fcheck=bounds'.
  
! '-ftail-call-workaround'
! '-ftail-call-workaround=N'
       Some C interfaces to Fortran codes violate the gfortran ABI by
       omitting the hidden character length arguments as described in
       *Note Argument passing conventions::.  This can lead to crashes
--- 1714,1755 ----
            string lengths are equal for character array constructors
            without an explicit typespec.
  
!           Some checks require that ‘-fcheck=bounds’ is set for the
            compilation of the main program.
  
            Note: In the future this may also include other forms of
            checking, e.g., checking substring references.
  
!      ‘do’
            Enable generation of run-time checks for invalid modification
            of loop iteration variables.
  
!      ‘mem’
            Enable generation of run-time checks for memory allocation.
            Note: This option does not affect explicit allocations using
!           the ‘ALLOCATE’ statement, which will be always checked.
  
!      ‘pointer’
            Enable generation of run-time checks for pointers and
            allocatables.
  
!      ‘recursion’
            Enable generation of run-time checks for recursively called
            subroutines and functions which are not marked as recursive.
!           See also ‘-frecursive’.  Note: This check does not work for
            OpenMP programs and is disabled if used together with
!           ‘-frecursive’ and ‘-fopenmp’.
  
!      Example: Assuming you have a file ‘foo.f90’, the command
              gfortran -fcheck=all,no-array-temps foo.f90
       will compile the file with all checks enabled as specified above
       except warnings for generated array temporaries.
  
! ‘-fbounds-check’
!      Deprecated alias for ‘-fcheck=bounds’.
  
! ‘-ftail-call-workaround’
! ‘-ftail-call-workaround=N’
       Some C interfaces to Fortran codes violate the gfortran ABI by
       omitting the hidden character length arguments as described in
       *Note Argument passing conventions::.  This can lead to crashes
*************** the other form by either removing 'no-'
*** 1757,1788 ****
  
       To provide a workaround for existing binary packages, this option
       disables tail call optimization for gfortran procedures with
!      character arguments.  With '-ftail-call-workaround=2' tail call
       optimization is disabled in all gfortran procedures with character
!      arguments, with '-ftail-call-workaround=1' or equivalent
!      '-ftail-call-workaround' only in gfortran procedures with character
       arguments that call implicitly prototyped procedures.
  
       Using this option can lead to problems including crashes due to
       insufficient stack space.
  
       It is _very strongly_ recommended to fix the code in question.  The
!      '-fc-prototypes-external' option can be used to generate prototypes
       which conform to gfortran's ABI, for inclusion in the source code.
  
       Support for this option will likely be withdrawn in a future
       release of gfortran.
  
!      The negative form, '-fno-tail-call-workaround' or equivalent
!      '-ftail-call-workaround=0', can be used to disable this option.
  
!      Default is currently '-ftail-call-workaround', this will change in
       future releases.
  
! '-fcheck-array-temporaries'
!      Deprecated alias for '-fcheck=array-temps'.
  
! '-fmax-array-constructor=N'
       This option can be used to increase the upper limit permitted in
       array constructors.  The code below requires this option to expand
       the array at compile time.
--- 1757,1788 ----
  
       To provide a workaround for existing binary packages, this option
       disables tail call optimization for gfortran procedures with
!      character arguments.  With ‘-ftail-call-workaround=2’ tail call
       optimization is disabled in all gfortran procedures with character
!      arguments, with ‘-ftail-call-workaround=1’ or equivalent
!      ‘-ftail-call-workaround’ only in gfortran procedures with character
       arguments that call implicitly prototyped procedures.
  
       Using this option can lead to problems including crashes due to
       insufficient stack space.
  
       It is _very strongly_ recommended to fix the code in question.  The
!      ‘-fc-prototypes-external’ option can be used to generate prototypes
       which conform to gfortran's ABI, for inclusion in the source code.
  
       Support for this option will likely be withdrawn in a future
       release of gfortran.
  
!      The negative form, ‘-fno-tail-call-workaround’ or equivalent
!      ‘-ftail-call-workaround=0’, can be used to disable this option.
  
!      Default is currently ‘-ftail-call-workaround’, this will change in
       future releases.
  
! ‘-fcheck-array-temporaries’
!      Deprecated alias for ‘-fcheck=array-temps’.
  
! ‘-fmax-array-constructor=N’
       This option can be used to increase the upper limit permitted in
       array constructors.  The code below requires this option to expand
       the array at compile time.
*************** the other form by either removing 'no-'
*** 1800,1811 ****
  
       The default value for N is 65535.
  
! '-fmax-stack-var-size=N'
       This option specifies the size in bytes of the largest array that
       will be put on the stack; if the size is exceeded static memory is
       used (except in procedures marked as RECURSIVE). Use the option
!      '-frecursive' to allow for recursive procedures which do not have a
!      RECURSIVE attribute or for parallel programs.  Use '-fno-automatic'
       to never use the stack.
  
       This option currently only affects local arrays declared with
--- 1800,1811 ----
  
       The default value for N is 65535.
  
! ‘-fmax-stack-var-size=N’
       This option specifies the size in bytes of the largest array that
       will be put on the stack; if the size is exceeded static memory is
       used (except in procedures marked as RECURSIVE). Use the option
!      ‘-frecursive’ to allow for recursive procedures which do not have a
!      RECURSIVE attribute or for parallel programs.  Use ‘-fno-automatic’
       to never use the stack.
  
       This option currently only affects local arrays declared with
*************** the other form by either removing 'no-'
*** 1814,1834 ****
  
       The default value for N is 65536.
  
! '-fstack-arrays'
       Adding this option will make the Fortran compiler put all arrays of
       unknown size and array temporaries onto stack memory.  If your
       program uses very large local arrays it is possible that you will
       have to extend your runtime limits for stack memory on some
       operating systems.  This flag is enabled by default at optimization
!      level '-Ofast' unless '-fmax-stack-var-size' is specified.
  
! '-fpack-derived'
       This option tells GNU Fortran to pack derived type members as
       closely as possible.  Code compiled with this option is likely to
       be incompatible with code compiled without this option, and may
       execute slower.
  
! '-frepack-arrays'
       In some circumstances GNU Fortran may pass assumed shape array
       sections via a descriptor describing a noncontiguous area of
       memory.  This option adds code to the function prologue to repack
--- 1814,1834 ----
  
       The default value for N is 65536.
  
! ‘-fstack-arrays’
       Adding this option will make the Fortran compiler put all arrays of
       unknown size and array temporaries onto stack memory.  If your
       program uses very large local arrays it is possible that you will
       have to extend your runtime limits for stack memory on some
       operating systems.  This flag is enabled by default at optimization
!      level ‘-Ofast’ unless ‘-fmax-stack-var-size’ is specified.
  
! ‘-fpack-derived’
       This option tells GNU Fortran to pack derived type members as
       closely as possible.  Code compiled with this option is likely to
       be incompatible with code compiled without this option, and may
       execute slower.
  
! ‘-frepack-arrays’
       In some circumstances GNU Fortran may pass assumed shape array
       sections via a descriptor describing a noncontiguous area of
       memory.  This option adds code to the function prologue to repack
*************** the other form by either removing 'no-'
*** 1838,1855 ****
       introduce significant overhead to the function call, especially
       when the passed data is noncontiguous.
  
! '-fshort-enums'
       This option is provided for interoperability with C code that was
!      compiled with the '-fshort-enums' option.  It will make GNU Fortran
!      choose the smallest 'INTEGER' kind a given enumerator set will fit
       in, and give all its enumerators this kind.
  
! '-finline-arg-packing'
       When passing an assumed-shape argument of a procedure as actual
       argument to an assumed-size or explicit size or as argument to a
       procedure that does not have an explicit interface, the argument
       may have to be packed, that is put into contiguous memory.  An
!      example is the call to 'foo' in
              subroutine foo(a)
                 real, dimension(*) :: a
              end subroutine foo
--- 1838,1855 ----
       introduce significant overhead to the function call, especially
       when the passed data is noncontiguous.
  
! ‘-fshort-enums’
       This option is provided for interoperability with C code that was
!      compiled with the ‘-fshort-enums’ option.  It will make GNU Fortran
!      choose the smallest ‘INTEGER’ kind a given enumerator set will fit
       in, and give all its enumerators this kind.
  
! ‘-finline-arg-packing’
       When passing an assumed-shape argument of a procedure as actual
       argument to an assumed-size or explicit size or as argument to a
       procedure that does not have an explicit interface, the argument
       may have to be packed, that is put into contiguous memory.  An
!      example is the call to ‘foo’ in
              subroutine foo(a)
                 real, dimension(*) :: a
              end subroutine foo
*************** the other form by either removing 'no-'
*** 1858,2010 ****
                 call foo(b)
              end subroutine bar
  
!      When '-finline-arg-packing' is in effect, this packing will be
       performed by inline code.  This allows for more optimization while
       increasing code size.
  
!      '-finline-arg-packing' is implied by any of the '-O' options except
!      when optimizing for size via '-Os'.  If the code contains a very
       large number of argument that have to be packed, code size and also
       compilation time may become excessive.  If that is the case, it may
       be better to disable this option.  Instances of packing can be
!      found by using '-Warray-temporaries'.
  
! '-fexternal-blas'
!      This option will make 'gfortran' generate calls to BLAS functions
!      for some matrix operations like 'MATMUL', instead of using our own
       algorithms, if the size of the matrices involved is larger than a
!      given limit (see '-fblas-matmul-limit').  This may be profitable if
       an optimized vendor BLAS library is available.  The BLAS library
       will have to be specified at link time.
  
! '-fblas-matmul-limit=N'
!      Only significant when '-fexternal-blas' is in effect.  Matrix
       multiplication of matrices with size larger than (or equal to) N
       will be performed by calls to BLAS functions, while others will be
!      handled by 'gfortran' internal algorithms.  If the matrices
       involved are not square, the size comparison is performed using the
       geometric mean of the dimensions of the argument and result
       matrices.
  
       The default value for N is 30.
  
! '-finline-matmul-limit=N'
!      When front-end optimization is active, some calls to the 'MATMUL'
       intrinsic function will be inlined.  This may result in code size
       increase if the size of the matrix cannot be determined at compile
       time, as code for both cases is generated.  Setting
!      '-finline-matmul-limit=0' will disable inlining in all cases.
       Setting this option with a value of N will produce inline code for
       matrices with size up to N.  If the matrices involved are not
       square, the size comparison is performed using the geometric mean
       of the dimensions of the argument and result matrices.
  
!      The default value for N is 30.  The '-fblas-matmul-limit' can be
       used to change this value.
  
! '-frecursive'
       Allow indirect recursion by forcing all local arrays to be
       allocated on the stack.  This flag cannot be used together with
!      '-fmax-stack-var-size=' or '-fno-automatic'.
  
! '-finit-local-zero'
! '-finit-derived'
! '-finit-integer=N'
! '-finit-real='
! '-finit-logical='
! '-finit-character=N'
!      The '-finit-local-zero' option instructs the compiler to initialize
!      local 'INTEGER', 'REAL', and 'COMPLEX' variables to zero, 'LOGICAL'
!      variables to false, and 'CHARACTER' variables to a string of null
       bytes.  Finer-grained initialization options are provided by the
!      '-finit-integer=N', '-finit-real=' (which
!      also initializes the real and imaginary parts of local 'COMPLEX'
!      variables), '-finit-logical=', and '-finit-character=N'
       (where N is an ASCII character value) options.
  
!      With '-finit-derived', components of derived type variables will be
       initialized according to these flags.  Components whose type is not
!      covered by an explicit '-finit-*' flag will be treated as described
!      above with '-finit-local-zero'.
  
       These options do not initialize
!         * objects with the POINTER attribute
!         * allocatable arrays
!         * variables that appear in an 'EQUIVALENCE' statement.
       (These limitations may be removed in future releases).
  
!      Note that the '-finit-real=nan' option initializes 'REAL' and
!      'COMPLEX' variables with a quiet NaN. For a signalling NaN use
!      '-finit-real=snan'; note, however, that compile-time optimizations
       may convert them into quiet NaN and that trapping needs to be
!      enabled (e.g.  via '-ffpe-trap').
  
!      The '-finit-integer' option will parse the value into an integer of
!      type 'INTEGER(kind=C_LONG)' on the host.  Said value is then
       assigned to the integer variables in the Fortran code, which might
       result in wraparound if the value is too large for the kind.
  
!      Finally, note that enabling any of the '-finit-*' options will
!      silence warnings that would have been emitted by '-Wuninitialized'
       for the affected local variables.
  
! '-falign-commons'
!      By default, 'gfortran' enforces proper alignment of all variables
!      in a 'COMMON' block by padding them as needed.  On certain
       platforms this is mandatory, on others it increases performance.
!      If a 'COMMON' block is not declared with consistent data types
       everywhere, this padding can cause trouble, and
!      '-fno-align-commons' can be used to disable automatic alignment.
       The same form of this option should be used for all files that
!      share a 'COMMON' block.  To avoid potential alignment issues in
!      'COMMON' blocks, it is recommended to order objects from largest to
       smallest.
  
! '-fno-protect-parens'
       By default the parentheses in expression are honored for all
       optimization levels such that the compiler does not do any
!      re-association.  Using '-fno-protect-parens' allows the compiler to
!      reorder 'REAL' and 'COMPLEX' expressions to produce faster code.
!      Note that for the re-association optimization '-fno-signed-zeros'
!      and '-fno-trapping-math' need to be in effect.  The parentheses
!      protection is enabled by default, unless '-Ofast' is given.
  
! '-frealloc-lhs'
       An allocatable left-hand side of an intrinsic assignment is
       automatically (re)allocated if it is either unallocated or has a
       different shape.  The option is enabled by default except when
!      '-std=f95' is given.  See also '-Wrealloc-lhs'.
  
! '-faggressive-function-elimination'
       Functions with identical argument lists are eliminated within
!      statements, regardless of whether these functions are marked 'PURE'
       or not.  For example, in
              a = f(b,c) + f(b,c)
!      there will only be a single call to 'f'.  This option only works if
!      '-ffrontend-optimize' is in effect.
  
! '-ffrontend-optimize'
       This option performs front-end optimization, based on manipulating
!      parts the Fortran parse tree.  Enabled by default by any '-O'
!      option except '-O0' and '-Og'.  Optimizations enabled by this
       option include:
!         * inlining calls to 'MATMUL',
!         * elimination of identical function calls within expressions,
!         * removing unnecessary calls to 'TRIM' in comparisons and
            assignments,
!         * replacing 'TRIM(a)' with 'a(1:LEN_TRIM(a))' and
!         * short-circuiting of logical operators ('.AND.' and '.OR.').
!      It can be deselected by specifying '-fno-frontend-optimize'.
  
! '-ffrontend-loop-interchange'
       Attempt to interchange loops in the Fortran front end where
!      profitable.  Enabled by default by any '-O' option.  At the moment,
!      this option only affects 'FORALL' and 'DO CONCURRENT' statements
       with several forall triplets.
  
     *Note Options for Code Generation Conventions: (gcc)Code Gen Options,
! for information on more options offered by the GBE shared by 'gfortran',
! 'gcc', and other GNU compilers.
  
  
  File: gfortran.info,  Node: Interoperability Options,  Next: Environment Variables,  Prev: Code Gen Options,  Up: Invoking GNU Fortran
--- 1858,2010 ----
                 call foo(b)
              end subroutine bar
  
!      When ‘-finline-arg-packing’ is in effect, this packing will be
       performed by inline code.  This allows for more optimization while
       increasing code size.
  
!      ‘-finline-arg-packing’ is implied by any of the ‘-O’ options except
!      when optimizing for size via ‘-Os’.  If the code contains a very
       large number of argument that have to be packed, code size and also
       compilation time may become excessive.  If that is the case, it may
       be better to disable this option.  Instances of packing can be
!      found by using ‘-Warray-temporaries’.
  
! ‘-fexternal-blas’
!      This option will make ‘gfortran’ generate calls to BLAS functions
!      for some matrix operations like ‘MATMUL’, instead of using our own
       algorithms, if the size of the matrices involved is larger than a
!      given limit (see ‘-fblas-matmul-limit’).  This may be profitable if
       an optimized vendor BLAS library is available.  The BLAS library
       will have to be specified at link time.
  
! ‘-fblas-matmul-limit=N’
!      Only significant when ‘-fexternal-blas’ is in effect.  Matrix
       multiplication of matrices with size larger than (or equal to) N
       will be performed by calls to BLAS functions, while others will be
!      handled by ‘gfortran’ internal algorithms.  If the matrices
       involved are not square, the size comparison is performed using the
       geometric mean of the dimensions of the argument and result
       matrices.
  
       The default value for N is 30.
  
! ‘-finline-matmul-limit=N’
!      When front-end optimization is active, some calls to the ‘MATMUL’
       intrinsic function will be inlined.  This may result in code size
       increase if the size of the matrix cannot be determined at compile
       time, as code for both cases is generated.  Setting
!      ‘-finline-matmul-limit=0’ will disable inlining in all cases.
       Setting this option with a value of N will produce inline code for
       matrices with size up to N.  If the matrices involved are not
       square, the size comparison is performed using the geometric mean
       of the dimensions of the argument and result matrices.
  
!      The default value for N is 30.  The ‘-fblas-matmul-limit’ can be
       used to change this value.
  
! ‘-frecursive’
       Allow indirect recursion by forcing all local arrays to be
       allocated on the stack.  This flag cannot be used together with
!      ‘-fmax-stack-var-size=’ or ‘-fno-automatic’.
  
! ‘-finit-local-zero’
! ‘-finit-derived’
! ‘-finit-integer=N’
! ‘-finit-real=’
! ‘-finit-logical=’
! ‘-finit-character=N’
!      The ‘-finit-local-zero’ option instructs the compiler to initialize
!      local ‘INTEGER’, ‘REAL’, and ‘COMPLEX’ variables to zero, ‘LOGICAL’
!      variables to false, and ‘CHARACTER’ variables to a string of null
       bytes.  Finer-grained initialization options are provided by the
!      ‘-finit-integer=N’, ‘-finit-real=’ (which
!      also initializes the real and imaginary parts of local ‘COMPLEX’
!      variables), ‘-finit-logical=’, and ‘-finit-character=N’
       (where N is an ASCII character value) options.
  
!      With ‘-finit-derived’, components of derived type variables will be
       initialized according to these flags.  Components whose type is not
!      covered by an explicit ‘-finit-*’ flag will be treated as described
!      above with ‘-finit-local-zero’.
  
       These options do not initialize
!         • objects with the POINTER attribute
!         • allocatable arrays
!         • variables that appear in an ‘EQUIVALENCE’ statement.
       (These limitations may be removed in future releases).
  
!      Note that the ‘-finit-real=nan’ option initializes ‘REAL’ and
!      ‘COMPLEX’ variables with a quiet NaN. For a signalling NaN use
!      ‘-finit-real=snan’; note, however, that compile-time optimizations
       may convert them into quiet NaN and that trapping needs to be
!      enabled (e.g.  via ‘-ffpe-trap’).
  
!      The ‘-finit-integer’ option will parse the value into an integer of
!      type ‘INTEGER(kind=C_LONG)’ on the host.  Said value is then
       assigned to the integer variables in the Fortran code, which might
       result in wraparound if the value is too large for the kind.
  
!      Finally, note that enabling any of the ‘-finit-*’ options will
!      silence warnings that would have been emitted by ‘-Wuninitialized’
       for the affected local variables.
  
! ‘-falign-commons’
!      By default, ‘gfortran’ enforces proper alignment of all variables
!      in a ‘COMMON’ block by padding them as needed.  On certain
       platforms this is mandatory, on others it increases performance.
!      If a ‘COMMON’ block is not declared with consistent data types
       everywhere, this padding can cause trouble, and
!      ‘-fno-align-commons’ can be used to disable automatic alignment.
       The same form of this option should be used for all files that
!      share a ‘COMMON’ block.  To avoid potential alignment issues in
!      ‘COMMON’ blocks, it is recommended to order objects from largest to
       smallest.
  
! ‘-fno-protect-parens’
       By default the parentheses in expression are honored for all
       optimization levels such that the compiler does not do any
!      re-association.  Using ‘-fno-protect-parens’ allows the compiler to
!      reorder ‘REAL’ and ‘COMPLEX’ expressions to produce faster code.
!      Note that for the re-association optimization ‘-fno-signed-zeros’
!      and ‘-fno-trapping-math’ need to be in effect.  The parentheses
!      protection is enabled by default, unless ‘-Ofast’ is given.
  
! ‘-frealloc-lhs’
       An allocatable left-hand side of an intrinsic assignment is
       automatically (re)allocated if it is either unallocated or has a
       different shape.  The option is enabled by default except when
!      ‘-std=f95’ is given.  See also ‘-Wrealloc-lhs’.
  
! ‘-faggressive-function-elimination’
       Functions with identical argument lists are eliminated within
!      statements, regardless of whether these functions are marked ‘PURE’
       or not.  For example, in
              a = f(b,c) + f(b,c)
!      there will only be a single call to ‘f’.  This option only works if
!      ‘-ffrontend-optimize’ is in effect.
  
! ‘-ffrontend-optimize’
       This option performs front-end optimization, based on manipulating
!      parts the Fortran parse tree.  Enabled by default by any ‘-O’
!      option except ‘-O0’ and ‘-Og’.  Optimizations enabled by this
       option include:
!         • inlining calls to ‘MATMUL’,
!         • elimination of identical function calls within expressions,
!         • removing unnecessary calls to ‘TRIM’ in comparisons and
            assignments,
!         • replacing ‘TRIM(a)’ with ‘a(1:LEN_TRIM(a))’ and
!         • short-circuiting of logical operators (‘.AND.’ and ‘.OR.’).
!      It can be deselected by specifying ‘-fno-frontend-optimize’.
  
! ‘-ffrontend-loop-interchange’
       Attempt to interchange loops in the Fortran front end where
!      profitable.  Enabled by default by any ‘-O’ option.  At the moment,
!      this option only affects ‘FORALL’ and ‘DO CONCURRENT’ statements
       with several forall triplets.
  
     *Note Options for Code Generation Conventions: (gcc)Code Gen Options,
! for information on more options offered by the GBE shared by ‘gfortran’,
! ‘gcc’, and other GNU compilers.
  
  
  File: gfortran.info,  Node: Interoperability Options,  Next: Environment Variables,  Prev: Code Gen Options,  Up: Invoking GNU Fortran
*************** File: gfortran.info,  Node: Interoperabi
*** 2013,2066 ****
  ======================================================
  
  -fc-prototypes
!      This option will generate C prototypes from 'BIND(C)' variable
       declarations, types and procedure interfaces and writes them to
!      standard output.  'ENUM' is not yet supported.
  
       The generated prototypes may need inclusion of an appropriate
!      header, such as '' or ''.  For types which are
!      not specified using the appropriate kind from the 'iso_c_binding'
       module, a warning is added as a comment to the code.
  
!      For function pointers, a pointer to a function returning 'int'
       without an explicit argument list is generated.
  
       Example of use:
            $ gfortran -fc-prototypes -fsyntax-only foo.f90 > foo.h
       where the C code intended for interoperating with the Fortran code
!      then uses '#include "foo.h"'.
  
  -fc-prototypes-external
       This option will generate C prototypes from external functions and
       subroutines and write them to standard output.  This may be useful
       for making sure that C bindings to Fortran code are correct.  This
!      option does not generate prototypes for 'BIND(C)' procedures, use
!      '-fc-prototypes' for that.
  
       The generated prototypes may need inclusion of an appropriate
!      header, such as '' or ''.
  
       This is primarily meant for legacy code to ensure that existing C
!      bindings match what 'gfortran' emits.  The generated C prototypes
       should be correct for the current version of the compiler, but may
!      not match what other compilers or earlier versions of 'gfortran'
!      need.  For new developments, use of the 'BIND(C)' features is
       recommended.
  
       Example of use:
            $ gfortran -fc-prototypes-external -fsyntax-only foo.f > foo.h
       where the C code intended for interoperating with the Fortran code
!      then uses '#include "foo.h"'.
  
  
  File: gfortran.info,  Node: Environment Variables,  Prev: Interoperability Options,  Up: Invoking GNU Fortran
  
! 2.11 Environment variables affecting 'gfortran'
  ===============================================
  
! The 'gfortran' compiler currently does not make use of any environment
  variables to control its operation above and beyond those that affect
! the operation of 'gcc'.
  
     *Note Environment Variables Affecting GCC: (gcc)Environment
  Variables, for information on environment variables.
--- 2013,2066 ----
  ======================================================
  
  -fc-prototypes
!      This option will generate C prototypes from ‘BIND(C)’ variable
       declarations, types and procedure interfaces and writes them to
!      standard output.  ‘ENUM’ is not yet supported.
  
       The generated prototypes may need inclusion of an appropriate
!      header, such as ‘’ or ‘’.  For types which are
!      not specified using the appropriate kind from the ‘iso_c_binding’
       module, a warning is added as a comment to the code.
  
!      For function pointers, a pointer to a function returning ‘int’
       without an explicit argument list is generated.
  
       Example of use:
            $ gfortran -fc-prototypes -fsyntax-only foo.f90 > foo.h
       where the C code intended for interoperating with the Fortran code
!      then uses ‘#include "foo.h"’.
  
  -fc-prototypes-external
       This option will generate C prototypes from external functions and
       subroutines and write them to standard output.  This may be useful
       for making sure that C bindings to Fortran code are correct.  This
!      option does not generate prototypes for ‘BIND(C)’ procedures, use
!      ‘-fc-prototypes’ for that.
  
       The generated prototypes may need inclusion of an appropriate
!      header, such as ‘’ or ‘’.
  
       This is primarily meant for legacy code to ensure that existing C
!      bindings match what ‘gfortran’ emits.  The generated C prototypes
       should be correct for the current version of the compiler, but may
!      not match what other compilers or earlier versions of ‘gfortran’
!      need.  For new developments, use of the ‘BIND(C)’ features is
       recommended.
  
       Example of use:
            $ gfortran -fc-prototypes-external -fsyntax-only foo.f > foo.h
       where the C code intended for interoperating with the Fortran code
!      then uses ‘#include "foo.h"’.
  
  
  File: gfortran.info,  Node: Environment Variables,  Prev: Interoperability Options,  Up: Invoking GNU Fortran
  
! 2.11 Environment variables affecting ‘gfortran’
  ===============================================
  
! The ‘gfortran’ compiler currently does not make use of any environment
  variables to control its operation above and beyond those that affect
! the operation of ‘gcc’.
  
     *Note Environment Variables Affecting GCC: (gcc)Environment
  Variables, for information on environment variables.
*************** File: gfortran.info,  Node: Runtime,  Ne
*** 2074,2080 ****
  3 Runtime: Influencing runtime behavior with environment variables
  ******************************************************************
  
! The behavior of the 'gfortran' can be influenced by environment
  variables.
  
     Malformed environment variables are silently ignored.
--- 2074,2080 ----
  3 Runtime: Influencing runtime behavior with environment variables
  ******************************************************************
  
! The behavior of the ‘gfortran’ can be influenced by environment
  variables.
  
     Malformed environment variables are silently ignored.
*************** variables.
*** 2098,2123 ****
  
  File: gfortran.info,  Node: TMPDIR,  Next: GFORTRAN_STDIN_UNIT,  Up: Runtime
  
! 3.1 'TMPDIR'--Directory for scratch files
  =========================================
  
! When opening a file with 'STATUS='SCRATCH'', GNU Fortran tries to create
  the file in one of the potential directories by testing each directory
  in the order below.
  
!   1. The environment variable 'TMPDIR', if it exists.
  
!   2. On the MinGW target, the directory returned by the 'GetTempPath'
!      function.  Alternatively, on the Cygwin target, the 'TMP' and
!      'TEMP' environment variables, if they exist, in that order.
  
!   3. The 'P_tmpdir' macro if it is defined, otherwise the directory
!      '/tmp'.
  
  
  File: gfortran.info,  Node: GFORTRAN_STDIN_UNIT,  Next: GFORTRAN_STDOUT_UNIT,  Prev: TMPDIR,  Up: Runtime
  
! 3.2 'GFORTRAN_STDIN_UNIT'--Unit number for standard input
  =========================================================
  
  This environment variable can be used to select the unit number
--- 2098,2123 ----
  
  File: gfortran.info,  Node: TMPDIR,  Next: GFORTRAN_STDIN_UNIT,  Up: Runtime
  
! 3.1 ‘TMPDIR’--Directory for scratch files
  =========================================
  
! When opening a file with ‘STATUS='SCRATCH'’, GNU Fortran tries to create
  the file in one of the potential directories by testing each directory
  in the order below.
  
!   1. The environment variable ‘TMPDIR’, if it exists.
  
!   2. On the MinGW target, the directory returned by the ‘GetTempPath’
!      function.  Alternatively, on the Cygwin target, the ‘TMP’ and
!      ‘TEMP’ environment variables, if they exist, in that order.
  
!   3. The ‘P_tmpdir’ macro if it is defined, otherwise the directory
!      ‘/tmp’.
  
  
  File: gfortran.info,  Node: GFORTRAN_STDIN_UNIT,  Next: GFORTRAN_STDOUT_UNIT,  Prev: TMPDIR,  Up: Runtime
  
! 3.2 ‘GFORTRAN_STDIN_UNIT’--Unit number for standard input
  =========================================================
  
  This environment variable can be used to select the unit number
*************** default value is 5.
*** 2127,2133 ****
  
  File: gfortran.info,  Node: GFORTRAN_STDOUT_UNIT,  Next: GFORTRAN_STDERR_UNIT,  Prev: GFORTRAN_STDIN_UNIT,  Up: Runtime
  
! 3.3 'GFORTRAN_STDOUT_UNIT'--Unit number for standard output
  ===========================================================
  
  This environment variable can be used to select the unit number
--- 2127,2133 ----
  
  File: gfortran.info,  Node: GFORTRAN_STDOUT_UNIT,  Next: GFORTRAN_STDERR_UNIT,  Prev: GFORTRAN_STDIN_UNIT,  Up: Runtime
  
! 3.3 ‘GFORTRAN_STDOUT_UNIT’--Unit number for standard output
  ===========================================================
  
  This environment variable can be used to select the unit number
*************** default value is 6.
*** 2137,2143 ****
  
  File: gfortran.info,  Node: GFORTRAN_STDERR_UNIT,  Next: GFORTRAN_UNBUFFERED_ALL,  Prev: GFORTRAN_STDOUT_UNIT,  Up: Runtime
  
! 3.4 'GFORTRAN_STDERR_UNIT'--Unit number for standard error
  ==========================================================
  
  This environment variable can be used to select the unit number
--- 2137,2143 ----
  
  File: gfortran.info,  Node: GFORTRAN_STDERR_UNIT,  Next: GFORTRAN_UNBUFFERED_ALL,  Prev: GFORTRAN_STDOUT_UNIT,  Up: Runtime
  
! 3.4 ‘GFORTRAN_STDERR_UNIT’--Unit number for standard error
  ==========================================================
  
  This environment variable can be used to select the unit number
*************** default value is 0.
*** 2147,2198 ****
  
  File: gfortran.info,  Node: GFORTRAN_UNBUFFERED_ALL,  Next: GFORTRAN_UNBUFFERED_PRECONNECTED,  Prev: GFORTRAN_STDERR_UNIT,  Up: Runtime
  
! 3.5 'GFORTRAN_UNBUFFERED_ALL'--Do not buffer I/O on all units
  =============================================================
  
  This environment variable controls whether all I/O is unbuffered.  If
! the first letter is 'y', 'Y' or '1', all I/O is unbuffered.  This will
  slow down small sequential reads and writes.  If the first letter is
! 'n', 'N' or '0', I/O is buffered.  This is the default.
  
  
  File: gfortran.info,  Node: GFORTRAN_UNBUFFERED_PRECONNECTED,  Next: GFORTRAN_SHOW_LOCUS,  Prev: GFORTRAN_UNBUFFERED_ALL,  Up: Runtime
  
! 3.6 'GFORTRAN_UNBUFFERED_PRECONNECTED'--Do not buffer I/O on preconnected units
  ===============================================================================
  
! The environment variable named 'GFORTRAN_UNBUFFERED_PRECONNECTED'
  controls whether I/O on a preconnected unit (i.e. STDOUT or STDERR) is
! unbuffered.  If the first letter is 'y', 'Y' or '1', I/O is unbuffered.
  This will slow down small sequential reads and writes.  If the first
! letter is 'n', 'N' or '0', I/O is buffered.  This is the default.
  
  
  File: gfortran.info,  Node: GFORTRAN_SHOW_LOCUS,  Next: GFORTRAN_OPTIONAL_PLUS,  Prev: GFORTRAN_UNBUFFERED_PRECONNECTED,  Up: Runtime
  
! 3.7 'GFORTRAN_SHOW_LOCUS'--Show location for runtime errors
  ===========================================================
  
! If the first letter is 'y', 'Y' or '1', filename and line numbers for
! runtime errors are printed.  If the first letter is 'n', 'N' or '0', do
  not print filename and line numbers for runtime errors.  The default is
  to print the location.
  
  
  File: gfortran.info,  Node: GFORTRAN_OPTIONAL_PLUS,  Next: GFORTRAN_LIST_SEPARATOR,  Prev: GFORTRAN_SHOW_LOCUS,  Up: Runtime
  
! 3.8 'GFORTRAN_OPTIONAL_PLUS'--Print leading + where permitted
  =============================================================
  
! If the first letter is 'y', 'Y' or '1', a plus sign is printed where
! permitted by the Fortran standard.  If the first letter is 'n', 'N' or
! '0', a plus sign is not printed in most cases.  Default is not to print
  plus signs.
  
  
  File: gfortran.info,  Node: GFORTRAN_LIST_SEPARATOR,  Next: GFORTRAN_CONVERT_UNIT,  Prev: GFORTRAN_OPTIONAL_PLUS,  Up: Runtime
  
! 3.9 'GFORTRAN_LIST_SEPARATOR'--Separator for list output
  ========================================================
  
  This environment variable specifies the separator when writing
--- 2147,2198 ----
  
  File: gfortran.info,  Node: GFORTRAN_UNBUFFERED_ALL,  Next: GFORTRAN_UNBUFFERED_PRECONNECTED,  Prev: GFORTRAN_STDERR_UNIT,  Up: Runtime
  
! 3.5 ‘GFORTRAN_UNBUFFERED_ALL’--Do not buffer I/O on all units
  =============================================================
  
  This environment variable controls whether all I/O is unbuffered.  If
! the first letter is ‘y’, ‘Y’ or ‘1’, all I/O is unbuffered.  This will
  slow down small sequential reads and writes.  If the first letter is
! ‘n’, ‘N’ or ‘0’, I/O is buffered.  This is the default.
  
  
  File: gfortran.info,  Node: GFORTRAN_UNBUFFERED_PRECONNECTED,  Next: GFORTRAN_SHOW_LOCUS,  Prev: GFORTRAN_UNBUFFERED_ALL,  Up: Runtime
  
! 3.6 ‘GFORTRAN_UNBUFFERED_PRECONNECTED’--Do not buffer I/O on preconnected units
  ===============================================================================
  
! The environment variable named ‘GFORTRAN_UNBUFFERED_PRECONNECTED’
  controls whether I/O on a preconnected unit (i.e. STDOUT or STDERR) is
! unbuffered.  If the first letter is ‘y’, ‘Y’ or ‘1’, I/O is unbuffered.
  This will slow down small sequential reads and writes.  If the first
! letter is ‘n’, ‘N’ or ‘0’, I/O is buffered.  This is the default.
  
  
  File: gfortran.info,  Node: GFORTRAN_SHOW_LOCUS,  Next: GFORTRAN_OPTIONAL_PLUS,  Prev: GFORTRAN_UNBUFFERED_PRECONNECTED,  Up: Runtime
  
! 3.7 ‘GFORTRAN_SHOW_LOCUS’--Show location for runtime errors
  ===========================================================
  
! If the first letter is ‘y’, ‘Y’ or ‘1’, filename and line numbers for
! runtime errors are printed.  If the first letter is ‘n’, ‘N’ or ‘0’, do
  not print filename and line numbers for runtime errors.  The default is
  to print the location.
  
  
  File: gfortran.info,  Node: GFORTRAN_OPTIONAL_PLUS,  Next: GFORTRAN_LIST_SEPARATOR,  Prev: GFORTRAN_SHOW_LOCUS,  Up: Runtime
  
! 3.8 ‘GFORTRAN_OPTIONAL_PLUS’--Print leading + where permitted
  =============================================================
  
! If the first letter is ‘y’, ‘Y’ or ‘1’, a plus sign is printed where
! permitted by the Fortran standard.  If the first letter is ‘n’, ‘N’ or
! ‘0’, a plus sign is not printed in most cases.  Default is not to print
  plus signs.
  
  
  File: gfortran.info,  Node: GFORTRAN_LIST_SEPARATOR,  Next: GFORTRAN_CONVERT_UNIT,  Prev: GFORTRAN_OPTIONAL_PLUS,  Up: Runtime
  
! 3.9 ‘GFORTRAN_LIST_SEPARATOR’--Separator for list output
  ========================================================
  
  This environment variable specifies the separator when writing
*************** list-directed output.  It may contain an
*** 2200,2217 ****
  one comma.  If you specify this on the command line, be sure to quote
  spaces, as in
       $ GFORTRAN_LIST_SEPARATOR='  ,  ' ./a.out
!    when 'a.out' is the compiled Fortran program that you want to run.
  Default is a single space.
  
  
  File: gfortran.info,  Node: GFORTRAN_CONVERT_UNIT,  Next: GFORTRAN_ERROR_BACKTRACE,  Prev: GFORTRAN_LIST_SEPARATOR,  Up: Runtime
  
! 3.10 'GFORTRAN_CONVERT_UNIT'--Set conversion for unformatted I/O
  ================================================================
  
! By setting the 'GFORTRAN_CONVERT_UNIT' variable, it is possible to
  change the representation of data for unformatted files.  The syntax for
! the 'GFORTRAN_CONVERT_UNIT' variable for most systems is:
       GFORTRAN_CONVERT_UNIT: mode | mode ';' exception | exception ;
       mode: 'native' | 'swap' | 'big_endian' | 'little_endian' ;
       exception: mode ':' unit_list | unit_list ;
--- 2200,2217 ----
  one comma.  If you specify this on the command line, be sure to quote
  spaces, as in
       $ GFORTRAN_LIST_SEPARATOR='  ,  ' ./a.out
!    when ‘a.out’ is the compiled Fortran program that you want to run.
  Default is a single space.
  
  
  File: gfortran.info,  Node: GFORTRAN_CONVERT_UNIT,  Next: GFORTRAN_ERROR_BACKTRACE,  Prev: GFORTRAN_LIST_SEPARATOR,  Up: Runtime
  
! 3.10 ‘GFORTRAN_CONVERT_UNIT’--Set conversion for unformatted I/O
  ================================================================
  
! By setting the ‘GFORTRAN_CONVERT_UNIT’ variable, it is possible to
  change the representation of data for unformatted files.  The syntax for
! the ‘GFORTRAN_CONVERT_UNIT’ variable for most systems is:
       GFORTRAN_CONVERT_UNIT: mode | mode ';' exception | exception ;
       mode: 'native' | 'swap' | 'big_endian' | 'little_endian' ;
       exception: mode ':' unit_list | unit_list ;
*************** the 'GFORTRAN_CONVERT_UNIT' variable for
*** 2221,2256 ****
  of optional exceptions, which are separated by semicolons from the
  preceding default and each other.  Each exception consists of a format
  and a comma-separated list of units.  Valid values for the modes are the
! same as for the 'CONVERT' specifier:
  
!      'NATIVE' Use the native format.  This is the default.
!      'SWAP' Swap between little- and big-endian.
!      'LITTLE_ENDIAN' Use the little-endian format for unformatted files.
!      'BIG_ENDIAN' Use the big-endian format for unformatted files.
!    For POWER systems which support '-mabi=ieeelongdouble', there are
  additional options, which can be combined with the others with commas.
  Those are
!      'R16_IEEE' Use IEEE 128-bit format for 'REAL(KIND=16)'.
!      'R16_IBM' Use IBM 'long double' format for 'REAL(KIND=16)'.
!    A missing mode for an exception is taken to mean 'BIG_ENDIAN'.
! Examples of values for 'GFORTRAN_CONVERT_UNIT' are:
!      ''big_endian'' Do all unformatted I/O in big_endian mode.
!      ''little_endian;native:10-20,25'' Do all unformatted I/O in
       little_endian mode, except for units 10 to 20 and 25, which are in
       native format.
!      ''10-20'' Units 10 to 20 are big-endian, the rest is native.
!      ''big_endian,r16_ibm'' Do all unformatted I/O in big-endian mode
!      and use IBM long double for output of 'REAL(KIND=16)' values.
  
     Setting the environment variables should be done on the command line
! or via the 'export' command for 'sh'-compatible shells and via 'setenv'
! for 'csh'-compatible shells.
  
!    Example for 'sh':
       $ gfortran foo.f90
       $ GFORTRAN_CONVERT_UNIT='big_endian;native:10-20' ./a.out
  
!    Example code for 'csh':
       % gfortran foo.f90
       % setenv GFORTRAN_CONVERT_UNIT 'big_endian;native:10-20'
       % ./a.out
--- 2221,2256 ----
  of optional exceptions, which are separated by semicolons from the
  preceding default and each other.  Each exception consists of a format
  and a comma-separated list of units.  Valid values for the modes are the
! same as for the ‘CONVERT’ specifier:
  
!      ‘NATIVE’ Use the native format.  This is the default.
!      ‘SWAP’ Swap between little- and big-endian.
!      ‘LITTLE_ENDIAN’ Use the little-endian format for unformatted files.
!      ‘BIG_ENDIAN’ Use the big-endian format for unformatted files.
!    For POWER systems which support ‘-mabi=ieeelongdouble’, there are
  additional options, which can be combined with the others with commas.
  Those are
!      ‘R16_IEEE’ Use IEEE 128-bit format for ‘REAL(KIND=16)’.
!      ‘R16_IBM’ Use IBM ‘long double’ format for ‘REAL(KIND=16)’.
!    A missing mode for an exception is taken to mean ‘BIG_ENDIAN’.
! Examples of values for ‘GFORTRAN_CONVERT_UNIT’ are:
!      ‘'big_endian'’ Do all unformatted I/O in big_endian mode.
!      ‘'little_endian;native:10-20,25'’ Do all unformatted I/O in
       little_endian mode, except for units 10 to 20 and 25, which are in
       native format.
!      ‘'10-20'’ Units 10 to 20 are big-endian, the rest is native.
!      ‘'big_endian,r16_ibm'’ Do all unformatted I/O in big-endian mode
!      and use IBM long double for output of ‘REAL(KIND=16)’ values.
  
     Setting the environment variables should be done on the command line
! or via the ‘export’ command for ‘sh’-compatible shells and via ‘setenv’
! for ‘csh’-compatible shells.
  
!    Example for ‘sh’:
       $ gfortran foo.f90
       $ GFORTRAN_CONVERT_UNIT='big_endian;native:10-20' ./a.out
  
!    Example code for ‘csh’:
       % gfortran foo.f90
       % setenv GFORTRAN_CONVERT_UNIT 'big_endian;native:10-20'
       % ./a.out
*************** you, it is best if you use this only for
*** 2262,2268 ****
     *Note CONVERT specifier::, for an alternative way to specify the data
  representation for unformatted files.  *Note Runtime Options::, for
  setting a default data representation for the whole program.  The
! 'CONVERT' specifier overrides the '-fconvert' compile options.
  
     _Note that the values specified via the GFORTRAN_CONVERT_UNIT
  environment variable will override the CONVERT specifier in the open
--- 2262,2268 ----
     *Note CONVERT specifier::, for an alternative way to specify the data
  representation for unformatted files.  *Note Runtime Options::, for
  setting a default data representation for the whole program.  The
! ‘CONVERT’ specifier overrides the ‘-fconvert’ compile options.
  
     _Note that the values specified via the GFORTRAN_CONVERT_UNIT
  environment variable will override the CONVERT specifier in the open
*************** not have the source code of their progra
*** 2272,2303 ****
  
  File: gfortran.info,  Node: GFORTRAN_ERROR_BACKTRACE,  Next: GFORTRAN_FORMATTED_BUFFER_SIZE,  Prev: GFORTRAN_CONVERT_UNIT,  Up: Runtime
  
! 3.11 'GFORTRAN_ERROR_BACKTRACE'--Show backtrace on run-time errors
  ==================================================================
  
! If the 'GFORTRAN_ERROR_BACKTRACE' variable is set to 'y', 'Y' or '1'
  (only the first letter is relevant) then a backtrace is printed when a
  serious run-time error occurs.  To disable the backtracing, set the
! variable to 'n', 'N', '0'.  Default is to print a backtrace unless the
! '-fno-backtrace' compile option was used.
  
  
  File: gfortran.info,  Node: GFORTRAN_FORMATTED_BUFFER_SIZE,  Next: GFORTRAN_UNFORMATTED_BUFFER_SIZE,  Prev: GFORTRAN_ERROR_BACKTRACE,  Up: Runtime
  
! 3.12 'GFORTRAN_FORMATTED_BUFFER_SIZE'--Set buffer size for formatted I/O
  ========================================================================
  
! The 'GFORTRAN_FORMATTED_BUFFER_SIZE' environment variable specifies
  buffer size in bytes to be used for formatted output.  The default value
  is 8192.
  
  
  File: gfortran.info,  Node: GFORTRAN_UNFORMATTED_BUFFER_SIZE,  Prev: GFORTRAN_FORMATTED_BUFFER_SIZE,  Up: Runtime
  
! 3.13 'GFORTRAN_UNFORMATTED_BUFFER_SIZE'--Set buffer size for unformatted I/O
  ============================================================================
  
! The 'GFORTRAN_UNFORMATTED_BUFFER_SIZE' environment variable specifies
  buffer size in bytes to be used for unformatted output.  The default
  value is 131072.
  
--- 2272,2303 ----
  
  File: gfortran.info,  Node: GFORTRAN_ERROR_BACKTRACE,  Next: GFORTRAN_FORMATTED_BUFFER_SIZE,  Prev: GFORTRAN_CONVERT_UNIT,  Up: Runtime
  
! 3.11 ‘GFORTRAN_ERROR_BACKTRACE’--Show backtrace on run-time errors
  ==================================================================
  
! If the ‘GFORTRAN_ERROR_BACKTRACE’ variable is set to ‘y’, ‘Y’ or ‘1’
  (only the first letter is relevant) then a backtrace is printed when a
  serious run-time error occurs.  To disable the backtracing, set the
! variable to ‘n’, ‘N’, ‘0’.  Default is to print a backtrace unless the
! ‘-fno-backtrace’ compile option was used.
  
  
  File: gfortran.info,  Node: GFORTRAN_FORMATTED_BUFFER_SIZE,  Next: GFORTRAN_UNFORMATTED_BUFFER_SIZE,  Prev: GFORTRAN_ERROR_BACKTRACE,  Up: Runtime
  
! 3.12 ‘GFORTRAN_FORMATTED_BUFFER_SIZE’--Set buffer size for formatted I/O
  ========================================================================
  
! The ‘GFORTRAN_FORMATTED_BUFFER_SIZE’ environment variable specifies
  buffer size in bytes to be used for formatted output.  The default value
  is 8192.
  
  
  File: gfortran.info,  Node: GFORTRAN_UNFORMATTED_BUFFER_SIZE,  Prev: GFORTRAN_FORMATTED_BUFFER_SIZE,  Up: Runtime
  
! 3.13 ‘GFORTRAN_UNFORMATTED_BUFFER_SIZE’--Set buffer size for unformatted I/O
  ============================================================================
  
! The ‘GFORTRAN_UNFORMATTED_BUFFER_SIZE’ environment variable specifies
  buffer size in bytes to be used for unformatted output.  The default
  value is 131072.
  
*************** File: gfortran.info,  Node: KIND Type Pa
*** 2331,2371 ****
  4.1 KIND Type Parameters
  ========================
  
! The 'KIND' type parameters supported by GNU Fortran for the primitive
  data types are:
  
! 'INTEGER'
       1, 2, 4, 8*, 16*, default: 4**
  
! 'LOGICAL'
       1, 2, 4, 8*, 16*, default: 4**
  
! 'REAL'
       4, 8, 10*, 16*, default: 4***
  
! 'COMPLEX'
       4, 8, 10*, 16*, default: 4***
  
! 'DOUBLE PRECISION'
       4, 8, 10*, 16*, default: 8***
  
! 'CHARACTER'
       1, 4, default: 1
  
  * not available on all systems
! ** unless '-fdefault-integer-8' is used
! *** unless '-fdefault-real-8' is used (see *note Fortran Dialect
  Options::)
  
! The 'KIND' value matches the storage size in bytes, except for 'COMPLEX'
  where the storage size is twice as much (or both real and imaginary part
  are a real value of the given size).  It is recommended to use the *note
  SELECTED_CHAR_KIND::, *note SELECTED_INT_KIND:: and *note
! SELECTED_REAL_KIND:: intrinsics or the 'INT8', 'INT16', 'INT32',
! 'INT64', 'REAL32', 'REAL64', and 'REAL128' parameters of the
! 'ISO_FORTRAN_ENV' module instead of the concrete values.  The available
! kind parameters can be found in the constant arrays 'CHARACTER_KINDS',
! 'INTEGER_KINDS', 'LOGICAL_KINDS' and 'REAL_KINDS' in the *note
  ISO_FORTRAN_ENV:: module.  For C interoperability, the kind parameters
  of the *note ISO_C_BINDING:: module should be used.
  
--- 2331,2371 ----
  4.1 KIND Type Parameters
  ========================
  
! The ‘KIND’ type parameters supported by GNU Fortran for the primitive
  data types are:
  
! ‘INTEGER’
       1, 2, 4, 8*, 16*, default: 4**
  
! ‘LOGICAL’
       1, 2, 4, 8*, 16*, default: 4**
  
! ‘REAL’
       4, 8, 10*, 16*, default: 4***
  
! ‘COMPLEX’
       4, 8, 10*, 16*, default: 4***
  
! ‘DOUBLE PRECISION’
       4, 8, 10*, 16*, default: 8***
  
! ‘CHARACTER’
       1, 4, default: 1
  
  * not available on all systems
! ** unless ‘-fdefault-integer-8’ is used
! *** unless ‘-fdefault-real-8’ is used (see *note Fortran Dialect
  Options::)
  
! The ‘KIND’ value matches the storage size in bytes, except for ‘COMPLEX’
  where the storage size is twice as much (or both real and imaginary part
  are a real value of the given size).  It is recommended to use the *note
  SELECTED_CHAR_KIND::, *note SELECTED_INT_KIND:: and *note
! SELECTED_REAL_KIND:: intrinsics or the ‘INT8’, ‘INT16’, ‘INT32’,
! ‘INT64’, ‘REAL32’, ‘REAL64’, and ‘REAL128’ parameters of the
! ‘ISO_FORTRAN_ENV’ module instead of the concrete values.  The available
! kind parameters can be found in the constant arrays ‘CHARACTER_KINDS’,
! ‘INTEGER_KINDS’, ‘LOGICAL_KINDS’ and ‘REAL_KINDS’ in the *note
  ISO_FORTRAN_ENV:: module.  For C interoperability, the kind parameters
  of the *note ISO_C_BINDING:: module should be used.
  
*************** File: gfortran.info,  Node: Internal rep
*** 2375,2388 ****
  4.2 Internal representation of LOGICAL variables
  ================================================
  
! The Fortran standard does not specify how variables of 'LOGICAL' type
! are represented, beyond requiring that 'LOGICAL' variables of default
! kind have the same storage size as default 'INTEGER' and 'REAL'
  variables.  The GNU Fortran internal representation is as follows.
  
!    A 'LOGICAL(KIND=N)' variable is represented as an 'INTEGER(KIND=N)'
! variable, however, with only two permissible values: '1' for '.TRUE.'
! and '0' for '.FALSE.'.  Any other integer value results in undefined
  behavior.
  
     See also *note Argument passing conventions:: and *note
--- 2375,2388 ----
  4.2 Internal representation of LOGICAL variables
  ================================================
  
! The Fortran standard does not specify how variables of ‘LOGICAL’ type
! are represented, beyond requiring that ‘LOGICAL’ variables of default
! kind have the same storage size as default ‘INTEGER’ and ‘REAL’
  variables.  The GNU Fortran internal representation is as follows.
  
!    A ‘LOGICAL(KIND=N)’ variable is represented as an ‘INTEGER(KIND=N)’
! variable, however, with only two permissible values: ‘1’ for ‘.TRUE.’
! and ‘0’ for ‘.FALSE.’.  Any other integer value results in undefined
  behavior.
  
     See also *note Argument passing conventions:: and *note
*************** File: gfortran.info,  Node: Evaluation o
*** 2396,2407 ****
  
  The Fortran standard does not require the compiler to evaluate all parts
  of an expression, if they do not contribute to the final result.  For
! logical expressions with '.AND.' or '.OR.' operators, in particular, GNU
  Fortran will optimize out function calls (even to impure functions) if
  the result of the expression can be established without them.  However,
  since not all compilers do that, and such an optimization can
  potentially modify the program flow and subsequent results, GNU Fortran
! throws warnings for such situations with the '-Wfunction-elimination'
  flag.
  
  
--- 2396,2407 ----
  
  The Fortran standard does not require the compiler to evaluate all parts
  of an expression, if they do not contribute to the final result.  For
! logical expressions with ‘.AND.’ or ‘.OR.’ operators, in particular, GNU
  Fortran will optimize out function calls (even to impure functions) if
  the result of the expression can be established without them.  However,
  since not all compilers do that, and such an optimization can
  potentially modify the program flow and subsequent results, GNU Fortran
! throws warnings for such situations with the ‘-Wfunction-elimination’
  flag.
  
  
*************** File: gfortran.info,  Node: MAX and MIN
*** 2410,2423 ****
  4.4 MAX and MIN intrinsics with REAL NaN arguments
  ==================================================
  
! The Fortran standard does not specify what the result of the 'MAX' and
! 'MIN' intrinsics are if one of the arguments is a 'NaN'.  Accordingly,
  the GNU Fortran compiler does not specify that either, as this allows
  for faster and more compact code to be generated.  If the programmer
  wishes to take some specific action in case one of the arguments is a
! 'NaN', it is necessary to explicitly test the arguments before calling
! 'MAX' or 'MIN', e.g.  with the 'IEEE_IS_NAN' function from the intrinsic
! module 'IEEE_ARITHMETIC'.
  
  
  File: gfortran.info,  Node: Thread-safety of the runtime library,  Next: Data consistency and durability,  Prev: MAX and MIN intrinsics with REAL NaN arguments,  Up: Compiler Characteristics
--- 2410,2423 ----
  4.4 MAX and MIN intrinsics with REAL NaN arguments
  ==================================================
  
! The Fortran standard does not specify what the result of the ‘MAX’ and
! ‘MIN’ intrinsics are if one of the arguments is a ‘NaN’.  Accordingly,
  the GNU Fortran compiler does not specify that either, as this allows
  for faster and more compact code to be generated.  If the programmer
  wishes to take some specific action in case one of the arguments is a
! ‘NaN’, it is necessary to explicitly test the arguments before calling
! ‘MAX’ or ‘MIN’, e.g.  with the ‘IEEE_IS_NAN’ function from the intrinsic
! module ‘IEEE_ARITHMETIC’.
  
  
  File: gfortran.info,  Node: Thread-safety of the runtime library,  Next: Data consistency and durability,  Prev: MAX and MIN intrinsics with REAL NaN arguments,  Up: Compiler Characteristics
*************** File: gfortran.info,  Node: Thread-safet
*** 2426,2447 ****
  ========================================
  
  GNU Fortran can be used in programs with multiple threads, e.g. by using
! OpenMP, by calling OS thread handling functions via the 'ISO_C_BINDING'
  facility, or by GNU Fortran compiled library code being called from a
  multi-threaded program.
  
!    The GNU Fortran runtime library, ('libgfortran'), supports being
  called concurrently from multiple threads with the following exceptions.
  
!    During library initialization, the C 'getenv' function is used, which
! need not be thread-safe.  Similarly, the 'getenv' function is used to
! implement the 'GET_ENVIRONMENT_VARIABLE' and 'GETENV' intrinsics.  It is
  the responsibility of the user to ensure that the environment is not
  being updated concurrently when any of these actions are taking place.
  
!    The 'EXECUTE_COMMAND_LINE' and 'SYSTEM' intrinsics are implemented
! with the 'system' function, which need not be thread-safe.  It is the
! responsibility of the user to ensure that 'system' is not called
  concurrently.
  
     For platforms not supporting thread-safe POSIX functions, further
--- 2426,2447 ----
  ========================================
  
  GNU Fortran can be used in programs with multiple threads, e.g. by using
! OpenMP, by calling OS thread handling functions via the ‘ISO_C_BINDING’
  facility, or by GNU Fortran compiled library code being called from a
  multi-threaded program.
  
!    The GNU Fortran runtime library, (‘libgfortran’), supports being
  called concurrently from multiple threads with the following exceptions.
  
!    During library initialization, the C ‘getenv’ function is used, which
! need not be thread-safe.  Similarly, the ‘getenv’ function is used to
! implement the ‘GET_ENVIRONMENT_VARIABLE’ and ‘GETENV’ intrinsics.  It is
  the responsibility of the user to ensure that the environment is not
  being updated concurrently when any of these actions are taking place.
  
!    The ‘EXECUTE_COMMAND_LINE’ and ‘SYSTEM’ intrinsics are implemented
! with the ‘system’ function, which need not be thread-safe.  It is the
! responsibility of the user to ensure that ‘system’ is not called
  concurrently.
  
     For platforms not supporting thread-safe POSIX functions, further
*************** functionality might not be thread-safe.
*** 2449,2464 ****
  documentation for your operating system.
  
     The GNU Fortran runtime library uses various C library functions that
! depend on the locale, such as 'strtod' and 'snprintf'.  In order to work
  correctly in locale-aware programs that set the locale using
! 'setlocale', the locale is reset to the default "C" locale while
! executing a formatted 'READ' or 'WRITE' statement.  On targets
  supporting the POSIX 2008 per-thread locale functions (e.g.
! 'newlocale', 'uselocale', 'freelocale'), these are used and thus the
! global locale set using 'setlocale' or the per-thread locales in other
  threads are not affected.  However, on targets lacking this
  functionality, the global LC_NUMERIC locale is set to "C" during the
! formatted I/O. Thus, on such targets it's not safe to call 'setlocale'
  concurrently from another thread while a Fortran formatted I/O operation
  is in progress.  Also, other threads doing something dependent on the
  LC_NUMERIC locale might not work correctly if a formatted I/O operation
--- 2449,2464 ----
  documentation for your operating system.
  
     The GNU Fortran runtime library uses various C library functions that
! depend on the locale, such as ‘strtod’ and ‘snprintf’.  In order to work
  correctly in locale-aware programs that set the locale using
! ‘setlocale’, the locale is reset to the default "C" locale while
! executing a formatted ‘READ’ or ‘WRITE’ statement.  On targets
  supporting the POSIX 2008 per-thread locale functions (e.g.
! ‘newlocale’, ‘uselocale’, ‘freelocale’), these are used and thus the
! global locale set using ‘setlocale’ or the per-thread locales in other
  threads are not affected.  However, on targets lacking this
  functionality, the global LC_NUMERIC locale is set to "C" during the
! formatted I/O. Thus, on such targets it's not safe to call ‘setlocale’
  concurrently from another thread while a Fortran formatted I/O operation
  is in progress.  Also, other threads doing something dependent on the
  LC_NUMERIC locale might not work correctly if a formatted I/O operation
*************** and durability issues when doing I/O.
*** 2475,2485 ****
  
     With respect to durability, GNU Fortran makes no effort to ensure
  that data is committed to stable storage.  If this is required, the GNU
! Fortran programmer can use the intrinsic 'FNUM' to retrieve the low
  level file descriptor corresponding to an open Fortran unit.  Then,
! using e.g.  the 'ISO_C_BINDING' feature, one can call the underlying
! system call to flush dirty data to stable storage, such as 'fsync' on
! POSIX, '_commit' on MingW, or 'fcntl(fd, F_FULLSYNC, 0)' on Mac OS X.
  The following example shows how to call fsync:
  
         ! Declare the interface for POSIX fsync function
--- 2475,2485 ----
  
     With respect to durability, GNU Fortran makes no effort to ensure
  that data is committed to stable storage.  If this is required, the GNU
! Fortran programmer can use the intrinsic ‘FNUM’ to retrieve the low
  level file descriptor corresponding to an open Fortran unit.  Then,
! using e.g.  the ‘ISO_C_BINDING’ feature, one can call the underlying
! system call to flush dirty data to stable storage, such as ‘fsync’ on
! POSIX, ‘_commit’ on MingW, or ‘fcntl(fd, F_FULLSYNC, 0)’ on Mac OS X.
  The following example shows how to call fsync:
  
         ! Declare the interface for POSIX fsync function
*************** The following example shows how to call
*** 2511,2528 ****
     With respect to consistency, for regular files GNU Fortran uses
  buffered I/O in order to improve performance.  This buffer is flushed
  automatically when full and in some other situations, e.g.  when closing
! a unit.  It can also be explicitly flushed with the 'FLUSH' statement.
! Also, the buffering can be turned off with the 'GFORTRAN_UNBUFFERED_ALL'
! and 'GFORTRAN_UNBUFFERED_PRECONNECTED' environment variables.  Special
  files, such as terminals and pipes, are always unbuffered.  Sometimes,
  however, further things may need to be done in order to allow other
  processes to see data that GNU Fortran has written, as follows.
  
     The Windows platform supports a relaxed metadata consistency model,
  where file metadata is written to the directory lazily.  This means
! that, for instance, the 'dir' command can show a stale size for a file.
  One can force a directory metadata update by closing the unit, or by
! calling '_commit' on the file descriptor.  Note, though, that '_commit'
  will force all dirty data to stable storage, which is often a very slow
  operation.
  
--- 2511,2528 ----
     With respect to consistency, for regular files GNU Fortran uses
  buffered I/O in order to improve performance.  This buffer is flushed
  automatically when full and in some other situations, e.g.  when closing
! a unit.  It can also be explicitly flushed with the ‘FLUSH’ statement.
! Also, the buffering can be turned off with the ‘GFORTRAN_UNBUFFERED_ALL’
! and ‘GFORTRAN_UNBUFFERED_PRECONNECTED’ environment variables.  Special
  files, such as terminals and pipes, are always unbuffered.  Sometimes,
  however, further things may need to be done in order to allow other
  processes to see data that GNU Fortran has written, as follows.
  
     The Windows platform supports a relaxed metadata consistency model,
  where file metadata is written to the directory lazily.  This means
! that, for instance, the ‘dir’ command can show a stale size for a file.
  One can force a directory metadata update by closing the unit, or by
! calling ‘_commit’ on the file descriptor.  Note, though, that ‘_commit’
  will force all dirty data to stable storage, which is often a very slow
  operation.
  
*************** operation.
*** 2530,2537 ****
  called open-to-close consistency.  Closing a file forces dirty data and
  metadata to be flushed to the server, and opening a file forces the
  client to contact the server in order to revalidate cached data.
! 'fsync' will also force a flush of dirty data and metadata to the
! server.  Similar to 'open' and 'close', acquiring and releasing 'fcntl'
  file locks, if the server supports them, will also force cache
  validation and flushing dirty data and metadata.
  
--- 2530,2537 ----
  called open-to-close consistency.  Closing a file forces dirty data and
  metadata to be flushed to the server, and opening a file forces the
  client to contact the server in order to revalidate cached data.
! ‘fsync’ will also force a flush of dirty data and metadata to the
! server.  Similar to ‘open’ and ‘close’, acquiring and releasing ‘fcntl’
  file locks, if the server supports them, will also force cache
  validation and flushing dirty data and metadata.
  
*************** File: gfortran.info,  Node: Files opened
*** 2541,2553 ****
  4.7 Files opened without an explicit ACTION= specifier
  ======================================================
  
! The Fortran standard says that if an 'OPEN' statement is executed
! without an explicit 'ACTION=' specifier, the default value is processor
  dependent.  GNU Fortran behaves as follows:
  
!   1. Attempt to open the file with 'ACTION='READWRITE''
!   2. If that fails, try to open with 'ACTION='READ''
!   3. If that fails, try to open with 'ACTION='WRITE''
    4. If that fails, generate an error
  
  
--- 2541,2553 ----
  4.7 Files opened without an explicit ACTION= specifier
  ======================================================
  
! The Fortran standard says that if an ‘OPEN’ statement is executed
! without an explicit ‘ACTION=’ specifier, the default value is processor
  dependent.  GNU Fortran behaves as follows:
  
!   1. Attempt to open the file with ‘ACTION='READWRITE'’
!   2. If that fails, try to open with ‘ACTION='READ'’
!   3. If that fails, try to open with ‘ACTION='WRITE'’
    4. If that fails, generate an error
  
  
*************** File: gfortran.info,  Node: File operati
*** 2559,2576 ****
  This section documents the behavior of GNU Fortran for file operations
  on symbolic links, on systems that support them.
  
!    * Results of INQUIRE statements of the "inquire by file" form will
       relate to the target of the symbolic link.  For example,
!      'INQUIRE(FILE="foo",EXIST=ex)' will set EX to .TRUE. if FOO is a
       symbolic link pointing to an existing file, and .FALSE. if FOO
       points to an non-existing file ("dangling" symbolic link).
  
!    * Using the 'OPEN' statement with a 'STATUS="NEW"' specifier on a
       symbolic link will result in an error condition, whether the
       symbolic link points to an existing target or is dangling.
  
!    * If a symbolic link was connected, using the 'CLOSE' statement with
!      a 'STATUS="DELETE"' specifier will cause the symbolic link itself
       to be deleted, not its target.
  
  
--- 2559,2576 ----
  This section documents the behavior of GNU Fortran for file operations
  on symbolic links, on systems that support them.
  
!    • Results of INQUIRE statements of the "inquire by file" form will
       relate to the target of the symbolic link.  For example,
!      ‘INQUIRE(FILE="foo",EXIST=ex)’ will set EX to .TRUE. if FOO is a
       symbolic link pointing to an existing file, and .FALSE. if FOO
       points to an non-existing file ("dangling" symbolic link).
  
!    • Using the ‘OPEN’ statement with a ‘STATUS="NEW"’ specifier on a
       symbolic link will result in an error condition, whether the
       symbolic link points to an existing target or is dangling.
  
!    • If a symbolic link was connected, using the ‘CLOSE’ statement with
!      a ‘STATUS="DELETE"’ specifier will cause the symbolic link itself
       to be deleted, not its target.
  
  
*************** markers.  Each logical record consists o
*** 2585,2601 ****
     Each subrecord consists of a leading record marker, the data written
  by the user program, and a trailing record marker.  The record markers
  are four-byte integers by default, and eight-byte integers if the
! '-fmax-subrecord-length=8' option (which exists for backwards
  compability only) is in effect.
  
     The representation of the record markers is that of unformatted files
! given with the '-fconvert' option, the *note CONVERT specifier:: in an
  open statement or the *note GFORTRAN_CONVERT_UNIT:: environment
  variable.
  
     The maximum number of bytes of user data in a subrecord is 2147483639
  (2 GiB - 9) for a four-byte record marker.  This limit can be lowered
! with the '-fmax-subrecord-length' option, although this is rarely
  useful.  If the length of a logical record exceeds this limit, the data
  is distributed among several subrecords.
  
--- 2585,2601 ----
     Each subrecord consists of a leading record marker, the data written
  by the user program, and a trailing record marker.  The record markers
  are four-byte integers by default, and eight-byte integers if the
! ‘-fmax-subrecord-length=8’ option (which exists for backwards
  compability only) is in effect.
  
     The representation of the record markers is that of unformatted files
! given with the ‘-fconvert’ option, the *note CONVERT specifier:: in an
  open statement or the *note GFORTRAN_CONVERT_UNIT:: environment
  variable.
  
     The maximum number of bytes of user data in a subrecord is 2147483639
  (2 GiB - 9) for a four-byte record marker.  This limit can be lowered
! with the ‘-fmax-subrecord-length’ option, although this is rarely
  useful.  If the length of a logical record exceeds this limit, the data
  is distributed among several subrecords.
  
*************** variables, such as AIX, I/O is also perf
*** 2641,2648 ****
  
     On some systems, such as Darwin or Solaris, the POSIX thread library
  is always linked in, so asynchronous I/O is always performed.  On other
! sytems, such as Linux, it is necessary to specify '-pthread',
! '-lpthread' or '-fopenmp' during the linking step.
  
  
  File: gfortran.info,  Node: Behavior on integer overflow,  Prev: Asynchronous I/O,  Up: Compiler Characteristics
--- 2641,2648 ----
  
     On some systems, such as Darwin or Solaris, the POSIX thread library
  is always linked in, so asynchronous I/O is always performed.  On other
! sytems, such as Linux, it is necessary to specify ‘-pthread’,
! ‘-lpthread’ or ‘-fopenmp’ during the linking step.
  
  
  File: gfortran.info,  Node: Behavior on integer overflow,  Prev: Asynchronous I/O,  Up: Compiler Characteristics
*************** Integer overflow is prohibited by the Fo
*** 2654,2665 ****
  gfortran on integer overflow is undefined by default.  Traditional code,
  like linear congruential pseudo-random number generators in old programs
  that rely on specific, non-standard behavior may generate unexpected
! results.  The '-fsanitize=undefined' option can be used to detect such
  code at runtime.
  
!    It is recommended to use the intrinsic subroutine 'RANDOM_NUMBER' for
  random number generators or, if the old behavior is desired, to use the
! '-fwrapv' option.  Note that this option can impact performance.
  
  
  File: gfortran.info,  Node: Extensions,  Next: Mixed-Language Programming,  Prev: Compiler Characteristics,  Up: Top
--- 2654,2665 ----
  gfortran on integer overflow is undefined by default.  Traditional code,
  like linear congruential pseudo-random number generators in old programs
  that rely on specific, non-standard behavior may generate unexpected
! results.  The ‘-fsanitize=undefined’ option can be used to detect such
  code at runtime.
  
!    It is recommended to use the intrinsic subroutine ‘RANDOM_NUMBER’ for
  random number generators or, if the old behavior is desired, to use the
! ‘-fwrapv’ option.  Note that this option can impact performance.
  
  
  File: gfortran.info,  Node: Extensions,  Next: Mixed-Language Programming,  Prev: Compiler Characteristics,  Up: Top
*************** This chapter contains information on the
*** 2690,2702 ****
  are currently two categories of GNU Fortran extensions, those that
  provide functionality beyond that provided by any standard, and those
  that are supported by GNU Fortran purely for backward compatibility with
! legacy compilers.  By default, '-std=gnu' allows the compiler to accept
  both types of extensions, but to warn about the use of the latter.
! Specifying either '-std=f95', '-std=f2003', '-std=f2008', or
! '-std=f2018' disables both types of extensions, and '-std=legacy' allows
! both without warning.  The special compile flag '-fdec' enables
  additional compatibility extensions along with those enabled by
! '-std=legacy'.
  
  * Menu:
  
--- 2690,2702 ----
  are currently two categories of GNU Fortran extensions, those that
  provide functionality beyond that provided by any standard, and those
  that are supported by GNU Fortran purely for backward compatibility with
! legacy compilers.  By default, ‘-std=gnu’ allows the compiler to accept
  both types of extensions, but to warn about the use of the latter.
! Specifying either ‘-std=f95’, ‘-std=f2003’, ‘-std=f2008’, or
! ‘-std=f2018’ disables both types of extensions, and ‘-std=legacy’ allows
! both without warning.  The special compile flag ‘-fdec’ enables
  additional compatibility extensions along with those enabled by
! ‘-std=legacy’.
  
  * Menu:
  
*************** File: gfortran.info,  Node: Old-style ki
*** 2744,2760 ****
  GNU Fortran allows old-style kind specifications in declarations.  These
  look like:
             TYPESPEC*size x,y,z
! where 'TYPESPEC' is a basic type ('INTEGER', 'REAL', etc.), and where
! 'size' is a byte count corresponding to the storage size of a valid kind
! for that type.  (For 'COMPLEX' variables, 'size' is the total size of
! the real and imaginary parts.)  The statement then declares 'x', 'y' and
! 'z' to be of type 'TYPESPEC' with the appropriate kind.  This is
  equivalent to the standard-conforming declaration
             TYPESPEC(k) x,y,z
! where 'k' is the kind parameter suitable for the intended precision.  As
! kind parameters are implementation-dependent, use the 'KIND',
! 'SELECTED_INT_KIND' and 'SELECTED_REAL_KIND' intrinsics to retrieve the
! correct value, for instance 'REAL*8 x' can be replaced by:
       INTEGER, PARAMETER :: dbl = KIND(1.0d0)
       REAL(KIND=dbl) :: x
  
--- 2744,2760 ----
  GNU Fortran allows old-style kind specifications in declarations.  These
  look like:
             TYPESPEC*size x,y,z
! where ‘TYPESPEC’ is a basic type (‘INTEGER’, ‘REAL’, etc.), and where
! ‘size’ is a byte count corresponding to the storage size of a valid kind
! for that type.  (For ‘COMPLEX’ variables, ‘size’ is the total size of
! the real and imaginary parts.)  The statement then declares ‘x’, ‘y’ and
! ‘z’ to be of type ‘TYPESPEC’ with the appropriate kind.  This is
  equivalent to the standard-conforming declaration
             TYPESPEC(k) x,y,z
! where ‘k’ is the kind parameter suitable for the intended precision.  As
! kind parameters are implementation-dependent, use the ‘KIND’,
! ‘SELECTED_INT_KIND’ and ‘SELECTED_REAL_KIND’ intrinsics to retrieve the
! correct value, for instance ‘REAL*8 x’ can be replaced by:
       INTEGER, PARAMETER :: dbl = KIND(1.0d0)
       REAL(KIND=dbl) :: x
  
*************** File: gfortran.info,  Node: Old-style va
*** 2767,2778 ****
  GNU Fortran allows old-style initialization of variables of the form:
             INTEGER i/1/,j/2/
             REAL x(2,2) /3*0.,1./
!    The syntax for the initializers is as for the 'DATA' statement, but
! unlike in a 'DATA' statement, an initializer only applies to the
  variable immediately preceding the initialization.  In other words,
! something like 'INTEGER I,J/2,3/' is not valid.  This style of
  initialization is only allowed in declarations without double colons
! ('::'); the double colons were introduced in Fortran 90, which also
  introduced a standard syntax for initializing variables in type
  declarations.
  
--- 2767,2778 ----
  GNU Fortran allows old-style initialization of variables of the form:
             INTEGER i/1/,j/2/
             REAL x(2,2) /3*0.,1./
!    The syntax for the initializers is as for the ‘DATA’ statement, but
! unlike in a ‘DATA’ statement, an initializer only applies to the
  variable immediately preceding the initialization.  In other words,
! something like ‘INTEGER I,J/2,3/’ is not valid.  This style of
  initialization is only allowed in declarations without double colons
! (‘::’); the double colons were introduced in Fortran 90, which also
  introduced a standard syntax for initializing variables in type
  declarations.
  
*************** are:
*** 2787,2793 ****
             DATA i/1/, j/2/, x/3*0.,1./
  
     Note that variables which are explicitly initialized in declarations
! or in 'DATA' statements automatically acquire the 'SAVE' attribute.
  
  
  File: gfortran.info,  Node: Extensions to namelist,  Next: X format descriptor without count field,  Prev: Old-style variable initialization,  Up: Extensions implemented in GNU Fortran
--- 2787,2793 ----
             DATA i/1/, j/2/, x/3*0.,1./
  
     Note that variables which are explicitly initialized in declarations
! or in ‘DATA’ statements automatically acquire the ‘SAVE’ attribute.
  
  
  File: gfortran.info,  Node: Extensions to namelist,  Next: X format descriptor without count field,  Prev: Old-style variable initialization,  Up: Extensions implemented in GNU Fortran
*************** types.  The output from a namelist write
*** 2801,2817 ****
  read.  The output has all names in upper case and indentation to column
  1 after the namelist name.  Two extensions are permitted:
  
!    Old-style use of '$' instead of '&'
       $MYNML
        X(:)%Y(2) = 1.0 2.0 3.0
        CH(1:4) = "abcd"
       $END
  
!    It should be noted that the default terminator is '/' rather than
! '&END'.
  
     Querying of the namelist when inputting from stdin.  After at least
! one space, entering '?' sends to stdout the namelist name and the names
  of the variables in the namelist:
        ?
  
--- 2801,2817 ----
  read.  The output has all names in upper case and indentation to column
  1 after the namelist name.  Two extensions are permitted:
  
!    Old-style use of ‘$’ instead of ‘&’
       $MYNML
        X(:)%Y(2) = 1.0 2.0 3.0
        CH(1:4) = "abcd"
       $END
  
!    It should be noted that the default terminator is ‘/’ rather than
! ‘&END’.
  
     Querying of the namelist when inputting from stdin.  After at least
! one space, entering ‘?’ sends to stdout the namelist name and the names
  of the variables in the namelist:
        ?
  
*************** of the variables in the namelist:
*** 2821,2828 ****
        ch
       &end
  
!    Entering '=?' outputs the namelist to stdout, as if 'WRITE(*,NML =
! mynml)' had been called:
       =?
  
       &MYNML
--- 2821,2828 ----
        ch
       &end
  
!    Entering ‘=?’ outputs the namelist to stdout, as if ‘WRITE(*,NML =
! mynml)’ had been called:
       =?
  
       &MYNML
*************** mynml)' had been called:
*** 2832,2840 ****
        CH=abcd,  /
  
     To aid this dialog, when input is from stdin, errors send their
! messages to stderr and execution continues, even if 'IOSTAT' is set.
  
!    'PRINT' namelist is permitted.  This causes an error if '-std=f95' is
  used.
       PROGRAM test_print
         REAL, dimension (4)  ::  x = (/1.0, 2.0, 3.0, 4.0/)
--- 2832,2840 ----
        CH=abcd,  /
  
     To aid this dialog, when input is from stdin, errors send their
! messages to stderr and execution continues, even if ‘IOSTAT’ is set.
  
!    ‘PRINT’ namelist is permitted.  This causes an error if ‘-std=f95’ is
  used.
       PROGRAM test_print
         REAL, dimension (4)  ::  x = (/1.0, 2.0, 3.0, 4.0/)
*************** used.
*** 2843,2856 ****
       END PROGRAM test_print
  
     Expanded namelist reads are permitted.  This causes an error if
! '-std=f95' is used.  In the following example, the first element of the
  array will be given the value 0.00 and the two succeeding elements will
  be given the values 1.00 and 2.00.
       &MYNML
         X(1,1) = 0.00 , 1.00 , 2.00
       /
  
!    When writing a namelist, if no 'DELIM=' is specified, by default a
  double quote is used to delimit character strings.  If -std=F95, F2003,
  or F2008, etc, the delim status is set to 'none'.  Defaulting to quotes
  ensures that namelists with character strings can be subsequently read
--- 2843,2856 ----
       END PROGRAM test_print
  
     Expanded namelist reads are permitted.  This causes an error if
! ‘-std=f95’ is used.  In the following example, the first element of the
  array will be given the value 0.00 and the two succeeding elements will
  be given the values 1.00 and 2.00.
       &MYNML
         X(1,1) = 0.00 , 1.00 , 2.00
       /
  
!    When writing a namelist, if no ‘DELIM=’ is specified, by default a
  double quote is used to delimit character strings.  If -std=F95, F2003,
  or F2008, etc, the delim status is set to 'none'.  Defaulting to quotes
  ensures that namelists with character strings can be subsequently read
*************** back in accurately.
*** 2859,2869 ****
  
  File: gfortran.info,  Node: X format descriptor without count field,  Next: Commas in FORMAT specifications,  Prev: Extensions to namelist,  Up: Extensions implemented in GNU Fortran
  
! 5.1.4 'X' format descriptor without count field
  -----------------------------------------------
  
! To support legacy codes, GNU Fortran permits the count field of the 'X'
! edit descriptor in 'FORMAT' statements to be omitted.  When omitted, the
  count is implicitly assumed to be one.
  
              PRINT 10, 2, 3
--- 2859,2869 ----
  
  File: gfortran.info,  Node: X format descriptor without count field,  Next: Commas in FORMAT specifications,  Prev: Extensions to namelist,  Up: Extensions implemented in GNU Fortran
  
! 5.1.4 ‘X’ format descriptor without count field
  -----------------------------------------------
  
! To support legacy codes, GNU Fortran permits the count field of the ‘X’
! edit descriptor in ‘FORMAT’ statements to be omitted.  When omitted, the
  count is implicitly assumed to be one.
  
              PRINT 10, 2, 3
*************** count is implicitly assumed to be one.
*** 2872,2884 ****
  
  File: gfortran.info,  Node: Commas in FORMAT specifications,  Next: Missing period in FORMAT specifications,  Prev: X format descriptor without count field,  Up: Extensions implemented in GNU Fortran
  
! 5.1.5 Commas in 'FORMAT' specifications
  ---------------------------------------
  
  To support legacy codes, GNU Fortran allows the comma separator to be
  omitted immediately before and after character string edit descriptors
! in 'FORMAT' statements.  A comma with no following format decriptor is
! permited if the '-fdec-blank-format-item' is given on the command line.
  This is considered non-conforming code and is discouraged.
  
              PRINT 10, 2, 3
--- 2872,2884 ----
  
  File: gfortran.info,  Node: Commas in FORMAT specifications,  Next: Missing period in FORMAT specifications,  Prev: X format descriptor without count field,  Up: Extensions implemented in GNU Fortran
  
! 5.1.5 Commas in ‘FORMAT’ specifications
  ---------------------------------------
  
  To support legacy codes, GNU Fortran allows the comma separator to be
  omitted immediately before and after character string edit descriptors
! in ‘FORMAT’ statements.  A comma with no following format decriptor is
! permited if the ‘-fdec-blank-format-item’ is given on the command line.
  This is considered non-conforming code and is discouraged.
  
              PRINT 10, 2, 3
*************** This is considered non-conforming code a
*** 2887,2899 ****
       20     FORMAT (I3, I3,)
  
  
! File: gfortran.info,  Node: Missing period in FORMAT specifications,  Next: Default widths for F, G and I format descriptors,  Prev: Commas in FORMAT specifications,  Up: Extensions implemented in GNU Fortran
  
! 5.1.6 Missing period in 'FORMAT' specifications
  -----------------------------------------------
  
  To support legacy codes, GNU Fortran allows missing periods in format
! specifications if and only if '-std=legacy' is given on the command
  line.  This is considered non-conforming code and is discouraged.
  
              REAL :: value
--- 2887,2899 ----
       20     FORMAT (I3, I3,)
  
  
! File: gfortran.info,  Node: Missing period in FORMAT specifications,  Next: Default widths for F, G and I format descriptors,  Prev: Commas in FORMAT specifications,  Up: Extensions implemented in GNU Fortran
  
! 5.1.6 Missing period in ‘FORMAT’ specifications
  -----------------------------------------------
  
  To support legacy codes, GNU Fortran allows missing periods in format
! specifications if and only if ‘-std=legacy’ is given on the command
  line.  This is considered non-conforming code and is discouraged.
  
              REAL :: value
*************** line.  This is considered non-conforming
*** 2901,2913 ****
       10     FORMAT ('F4')
  
  
! File: gfortran.info,  Node: Default widths for F, G and I format descriptors,  Next: I/O item lists,  Prev: Missing period in FORMAT specifications,  Up: Extensions implemented in GNU Fortran
  
! 5.1.7 Default widths for 'F', 'G' and 'I' format descriptors
  ------------------------------------------------------------
  
  To support legacy codes, GNU Fortran allows width to be omitted from
! format specifications if and only if '-fdec-format-defaults' is given on
  the command line.  Default widths will be used.  This is considered
  non-conforming code and is discouraged.
  
--- 2901,2913 ----
       10     FORMAT ('F4')
  
  
! File: gfortran.info,  Node: Default widths for F, G and I format descriptors,  Next: I/O item lists,  Prev: Missing period in FORMAT specifications,  Up: Extensions implemented in GNU Fortran
  
! 5.1.7 Default widths for ‘F’, ‘G’ and ‘I’ format descriptors
  ------------------------------------------------------------
  
  To support legacy codes, GNU Fortran allows width to be omitted from
! format specifications if and only if ‘-fdec-format-defaults’ is given on
  the command line.  Default widths will be used.  This is considered
  non-conforming code and is discouraged.
  
*************** non-conforming code and is discouraged.
*** 2917,2943 ****
       10     FORMAT ('F, G, I')
  
  
! File: gfortran.info,  Node: I/O item lists,  Next: Q exponent-letter,  Prev: Default widths for F, G and I format descriptors,  Up: Extensions implemented in GNU Fortran
  
  5.1.8 I/O item lists
  --------------------
  
  To support legacy codes, GNU Fortran allows the input item list of the
! 'READ' statement, and the output item lists of the 'WRITE' and 'PRINT'
  statements, to start with a comma.
  
  
  File: gfortran.info,  Node: Q exponent-letter,  Next: BOZ literal constants,  Prev: I/O item lists,  Up: Extensions implemented in GNU Fortran
  
! 5.1.9 'Q' exponent-letter
  -------------------------
  
  GNU Fortran accepts real literal constants with an exponent-letter of
! 'Q', for example, '1.23Q45'.  The constant is interpreted as a
! 'REAL(16)' entity on targets that support this type.  If the target does
! not support 'REAL(16)' but has a 'REAL(10)' type, then the
! real-literal-constant will be interpreted as a 'REAL(10)' entity.  In
! the absence of 'REAL(16)' and 'REAL(10)', an error will occur.
  
  
  File: gfortran.info,  Node: BOZ literal constants,  Next: Real array indices,  Prev: Q exponent-letter,  Up: Extensions implemented in GNU Fortran
--- 2917,2943 ----
       10     FORMAT ('F, G, I')
  
  
! File: gfortran.info,  Node: I/O item lists,  Next: Q exponent-letter,  Prev: Default widths for F, G and I format descriptors,  Up: Extensions implemented in GNU Fortran
  
  5.1.8 I/O item lists
  --------------------
  
  To support legacy codes, GNU Fortran allows the input item list of the
! ‘READ’ statement, and the output item lists of the ‘WRITE’ and ‘PRINT’
  statements, to start with a comma.
  
  
  File: gfortran.info,  Node: Q exponent-letter,  Next: BOZ literal constants,  Prev: I/O item lists,  Up: Extensions implemented in GNU Fortran
  
! 5.1.9 ‘Q’ exponent-letter
  -------------------------
  
  GNU Fortran accepts real literal constants with an exponent-letter of
! ‘Q’, for example, ‘1.23Q45’.  The constant is interpreted as a
! ‘REAL(16)’ entity on targets that support this type.  If the target does
! not support ‘REAL(16)’ but has a ‘REAL(10)’ type, then the
! real-literal-constant will be interpreted as a ‘REAL(10)’ entity.  In
! the absence of ‘REAL(16)’ and ‘REAL(10)’, an error will occur.
  
  
  File: gfortran.info,  Node: BOZ literal constants,  Next: Real array indices,  Prev: Q exponent-letter,  Up: Extensions implemented in GNU Fortran
*************** File: gfortran.info,  Node: BOZ literal
*** 2945,2973 ****
  5.1.10 BOZ literal constants
  ----------------------------
  
! Besides decimal constants, Fortran also supports binary ('b'), octal
! ('o') and hexadecimal ('z') integer constants.  The syntax is: 'prefix
! quote digits quote', where the prefix is either 'b', 'o' or 'z', quote
! is either ''' or '"' and the digits are '0' or '1' for binary, between
! '0' and '7' for octal, and between '0' and 'F' for hexadecimal.
! (Example: 'b'01011101''.)
  
     Up to Fortran 95, BOZ literal constants were only allowed to
  initialize integer variables in DATA statements.  Since Fortran 2003 BOZ
! literal constants are also allowed as actual arguments to the 'REAL',
! 'DBLE', 'INT' and 'CMPLX' intrinsic functions.  The BOZ literal constant
  is simply a string of bits, which is padded or truncated as needed,
  during conversion to a numeric type.  The Fortran standard states that
  the treatment of the sign bit is processor dependent.  Gfortran
  interprets the sign bit as a user would expect.
  
     As a deprecated extension, GNU Fortran allows hexadecimal BOZ literal
! constants to be specified using the 'X' prefix.  That the BOZ literal
  constant can also be specified by adding a suffix to the string, for
! example, 'Z'ABC'' and ''ABC'X' are equivalent.  Additionally, as
! extension, BOZ literals are permitted in some contexts outside of 'DATA'
  and the intrinsic functions listed in the Fortran standard.  Use
! '-fallow-invalid-boz' to enable the extension.
  
  
  File: gfortran.info,  Node: Real array indices,  Next: Unary operators,  Prev: BOZ literal constants,  Up: Extensions implemented in GNU Fortran
--- 2945,2973 ----
  5.1.10 BOZ literal constants
  ----------------------------
  
! Besides decimal constants, Fortran also supports binary (‘b’), octal
! (‘o’) and hexadecimal (‘z’) integer constants.  The syntax is: ‘prefix
! quote digits quote’, where the prefix is either ‘b’, ‘o’ or ‘z’, quote
! is either ‘'’ or ‘"’ and the digits are ‘0’ or ‘1’ for binary, between
! ‘0’ and ‘7’ for octal, and between ‘0’ and ‘F’ for hexadecimal.
! (Example: ‘b'01011101'’.)
  
     Up to Fortran 95, BOZ literal constants were only allowed to
  initialize integer variables in DATA statements.  Since Fortran 2003 BOZ
! literal constants are also allowed as actual arguments to the ‘REAL’,
! ‘DBLE’, ‘INT’ and ‘CMPLX’ intrinsic functions.  The BOZ literal constant
  is simply a string of bits, which is padded or truncated as needed,
  during conversion to a numeric type.  The Fortran standard states that
  the treatment of the sign bit is processor dependent.  Gfortran
  interprets the sign bit as a user would expect.
  
     As a deprecated extension, GNU Fortran allows hexadecimal BOZ literal
! constants to be specified using the ‘X’ prefix.  That the BOZ literal
  constant can also be specified by adding a suffix to the string, for
! example, ‘Z'ABC'’ and ‘'ABC'X’ are equivalent.  Additionally, as
! extension, BOZ literals are permitted in some contexts outside of ‘DATA’
  and the intrinsic functions listed in the Fortran standard.  Use
! ‘-fallow-invalid-boz’ to enable the extension.
  
  
  File: gfortran.info,  Node: Real array indices,  Next: Unary operators,  Prev: BOZ literal constants,  Up: Extensions implemented in GNU Fortran
*************** File: gfortran.info,  Node: Real array i
*** 2975,2981 ****
  5.1.11 Real array indices
  -------------------------
  
! As an extension, GNU Fortran allows the use of 'REAL' expressions or
  variables as array indices.
  
  
--- 2975,2981 ----
  5.1.11 Real array indices
  -------------------------
  
! As an extension, GNU Fortran allows the use of ‘REAL’ expressions or
  variables as array indices.
  
  
*************** the need for parenthesis.
*** 2993,3016 ****
  
  File: gfortran.info,  Node: Implicitly convert LOGICAL and INTEGER values,  Next: Hollerith constants support,  Prev: Unary operators,  Up: Extensions implemented in GNU Fortran
  
! 5.1.13 Implicitly convert 'LOGICAL' and 'INTEGER' values
  --------------------------------------------------------
  
  As an extension for backwards compatibility with other compilers, GNU
! Fortran allows the implicit conversion of 'LOGICAL' values to 'INTEGER'
! values and vice versa.  When converting from a 'LOGICAL' to an
! 'INTEGER', '.FALSE.' is interpreted as zero, and '.TRUE.' is interpreted
! as one.  When converting from 'INTEGER' to 'LOGICAL', the value zero is
! interpreted as '.FALSE.' and any nonzero value is interpreted as
! '.TRUE.'.
  
               LOGICAL :: l
               l = 1
               INTEGER :: i
               i = .TRUE.
  
!    However, there is no implicit conversion of 'INTEGER' values in
! 'if'-statements, nor of 'LOGICAL' or 'INTEGER' values in I/O operations.
  
  
  File: gfortran.info,  Node: Hollerith constants support,  Next: Character conversion,  Prev: Implicitly convert LOGICAL and INTEGER values,  Up: Extensions implemented in GNU Fortran
--- 2993,3016 ----
  
  File: gfortran.info,  Node: Implicitly convert LOGICAL and INTEGER values,  Next: Hollerith constants support,  Prev: Unary operators,  Up: Extensions implemented in GNU Fortran
  
! 5.1.13 Implicitly convert ‘LOGICAL’ and ‘INTEGER’ values
  --------------------------------------------------------
  
  As an extension for backwards compatibility with other compilers, GNU
! Fortran allows the implicit conversion of ‘LOGICAL’ values to ‘INTEGER’
! values and vice versa.  When converting from a ‘LOGICAL’ to an
! ‘INTEGER’, ‘.FALSE.’ is interpreted as zero, and ‘.TRUE.’ is interpreted
! as one.  When converting from ‘INTEGER’ to ‘LOGICAL’, the value zero is
! interpreted as ‘.FALSE.’ and any nonzero value is interpreted as
! ‘.TRUE.’.
  
               LOGICAL :: l
               l = 1
               INTEGER :: i
               i = .TRUE.
  
!    However, there is no implicit conversion of ‘INTEGER’ values in
! ‘if’-statements, nor of ‘LOGICAL’ or ‘INTEGER’ values in I/O operations.
  
  
  File: gfortran.info,  Node: Hollerith constants support,  Next: Character conversion,  Prev: Implicitly convert LOGICAL and INTEGER values,  Up: Extensions implemented in GNU Fortran
*************** File: gfortran.info,  Node: Hollerith co
*** 3018,3029 ****
  5.1.14 Hollerith constants support
  ----------------------------------
  
! GNU Fortran supports Hollerith constants in assignments, 'DATA'
  statements, function and subroutine arguments.  A Hollerith constant is
  written as a string of characters preceded by an integer constant
! indicating the character count, and the letter 'H' or 'h', and stored in
! bytewise fashion in a numeric ('INTEGER', 'REAL', or 'COMPLEX'),
! 'LOGICAL' or 'CHARACTER' variable.  The constant will be padded with
  spaces or truncated to fit the size of the variable in which it is
  stored.
  
--- 3018,3029 ----
  5.1.14 Hollerith constants support
  ----------------------------------
  
! GNU Fortran supports Hollerith constants in assignments, ‘DATA’
  statements, function and subroutine arguments.  A Hollerith constant is
  written as a string of characters preceded by an integer constant
! indicating the character count, and the letter ‘H’ or ‘h’, and stored in
! bytewise fashion in a numeric (‘INTEGER’, ‘REAL’, or ‘COMPLEX’),
! ‘LOGICAL’ or ‘CHARACTER’ variable.  The constant will be padded with
  spaces or truncated to fit the size of the variable in which it is
  stored.
  
*************** stored.
*** 3042,3057 ****
  
     In general, Hollerith constants were used to provide a rudimentary
  facility for handling character strings in early Fortran compilers,
! prior to the introduction of 'CHARACTER' variables in Fortran 77; in
  those cases, the standard-compliant equivalent is to convert the program
  to use proper character strings.  On occasion, there may be a case where
  the intent is specifically to initialize a numeric variable with a given
  byte sequence.  In these cases, the same result can be obtained by using
! the 'TRANSFER' statement, as in this example.
             integer(kind=4) :: a
             a = transfer ("abcd", a)     ! equivalent to: a = 4Habcd
  
!    The use of the '-fdec' option extends support of Hollerith constants
  to comparisons:
             integer*4 a
             a = 4hABCD
--- 3042,3057 ----
  
     In general, Hollerith constants were used to provide a rudimentary
  facility for handling character strings in early Fortran compilers,
! prior to the introduction of ‘CHARACTER’ variables in Fortran 77; in
  those cases, the standard-compliant equivalent is to convert the program
  to use proper character strings.  On occasion, there may be a case where
  the intent is specifically to initialize a numeric variable with a given
  byte sequence.  In these cases, the same result can be obtained by using
! the ‘TRANSFER’ statement, as in this example.
             integer(kind=4) :: a
             a = transfer ("abcd", a)     ! equivalent to: a = 4Habcd
  
!    The use of the ‘-fdec’ option extends support of Hollerith constants
  to comparisons:
             integer*4 a
             a = 4hABCD
*************** to comparisons:
*** 3059,3066 ****
               write(*,*) "no match"
             end if
  
!    Supported types are numeric ('INTEGER', 'REAL', or 'COMPLEX'), and
! 'CHARACTER'.
  
  
  File: gfortran.info,  Node: Character conversion,  Next: Cray pointers,  Prev: Hollerith constants support,  Up: Extensions implemented in GNU Fortran
--- 3059,3066 ----
               write(*,*) "no match"
             end if
  
!    Supported types are numeric (‘INTEGER’, ‘REAL’, or ‘COMPLEX’), and
! ‘CHARACTER’.
  
  
  File: gfortran.info,  Node: Character conversion,  Next: Cray pointers,  Prev: Hollerith constants support,  Up: Extensions implemented in GNU Fortran
*************** File: gfortran.info,  Node: Character co
*** 3071,3080 ****
  Allowing character literals to be used in a similar way to Hollerith
  constants is a non-standard extension.  This feature is enabled using
  -fdec-char-conversions and only applies to character literals of
! 'kind=1'.
  
!    Character literals can be used in 'DATA' statements and assignments
! with numeric ('INTEGER', 'REAL', or 'COMPLEX') or 'LOGICAL' variables.
  Like Hollerith constants they are copied byte-wise fashion.  The
  constant will be padded with spaces or truncated to fit the size of the
  variable in which it is stored.
--- 3071,3080 ----
  Allowing character literals to be used in a similar way to Hollerith
  constants is a non-standard extension.  This feature is enabled using
  -fdec-char-conversions and only applies to character literals of
! ‘kind=1’.
  
!    Character literals can be used in ‘DATA’ statements and assignments
! with numeric (‘INTEGER’, ‘REAL’, or ‘COMPLEX’) or ‘LOGICAL’ variables.
  Like Hollerith constants they are copied byte-wise fashion.  The
  constant will be padded with spaces or truncated to fit the size of the
  variable in which it is stored.
*************** variables: an integer "pointer" that hol
*** 3105,3111 ****
  The pointee may be an array or scalar.  If an assumed-size array is
  permitted within the scoping unit, a pointee can be an assumed-size
  array.  That is, the last dimension may be left unspecified by using a
! '*' in place of a value.  A pointee cannot be an assumed shape array.
  No space is allocated for the pointee.
  
     The pointee may have its type declared before or after the pointer
--- 3105,3111 ----
  The pointee may be an array or scalar.  If an assumed-size array is
  permitted within the scoping unit, a pointee can be an assumed-size
  array.  That is, the last dimension may be left unspecified by using a
! ‘*’ in place of a value.  A pointee cannot be an assumed shape array.
  No space is allocated for the pointee.
  
     The pointee may have its type declared before or after the pointer
*************** pointer in order to increment it.  Consi
*** 3132,3153 ****
               pointer (ipt, pointee)
               ipt = loc (target)
               ipt = ipt + 1
!    The last statement does not set 'ipt' to the address of 'target(1)',
! as it would in C pointer arithmetic.  Adding '1' to 'ipt' just adds one
! byte to the address stored in 'ipt'.
  
     Any expression involving the pointee will be translated to use the
  value stored in the pointer as the base address.
  
     To get the address of elements, this extension provides an intrinsic
! function 'LOC()'.  The 'LOC()' function is equivalent to the '&'
  operator in C, except the address is cast to an integer type:
               real ar(10)
               pointer(ipt, arpte(10))
               real arpte
               ipt = loc(ar)  ! Makes arpte is an alias for ar
               arpte(1) = 1.0 ! Sets ar(1) to 1.0
!    The pointer can also be set by a call to the 'MALLOC' intrinsic (see
  *note MALLOC::).
  
     Cray pointees often are used to alias an existing variable.  For
--- 3132,3153 ----
               pointer (ipt, pointee)
               ipt = loc (target)
               ipt = ipt + 1
!    The last statement does not set ‘ipt’ to the address of ‘target(1)’,
! as it would in C pointer arithmetic.  Adding ‘1’ to ‘ipt’ just adds one
! byte to the address stored in ‘ipt’.
  
     Any expression involving the pointee will be translated to use the
  value stored in the pointer as the base address.
  
     To get the address of elements, this extension provides an intrinsic
! function ‘LOC()’.  The ‘LOC()’ function is equivalent to the ‘&’
  operator in C, except the address is cast to an integer type:
               real ar(10)
               pointer(ipt, arpte(10))
               real arpte
               ipt = loc(ar)  ! Makes arpte is an alias for ar
               arpte(1) = 1.0 ! Sets ar(1) to 1.0
!    The pointer can also be set by a call to the ‘MALLOC’ intrinsic (see
  *note MALLOC::).
  
     Cray pointees often are used to alias an existing variable.  For
*************** example:
*** 3156,3164 ****
               integer iarr(10)
               pointer (ipt, iarr)
               ipt = loc(target)
!    As long as 'ipt' remains unchanged, 'iarr' is now an alias for
! 'target'.  The optimizer, however, will not detect this aliasing, so it
! is unsafe to use 'iarr' and 'target' simultaneously.  Using a pointee in
  any way that violates the Fortran aliasing rules or assumptions is
  illegal.  It is the user's responsibility to avoid doing this; the
  compiler works under the assumption that no such aliasing occurs.
--- 3156,3164 ----
               integer iarr(10)
               pointer (ipt, iarr)
               ipt = loc(target)
!    As long as ‘ipt’ remains unchanged, ‘iarr’ is now an alias for
! ‘target’.  The optimizer, however, will not detect this aliasing, so it
! is unsafe to use ‘iarr’ and ‘target’ simultaneously.  Using a pointee in
  any way that violates the Fortran aliasing rules or assumptions is
  illegal.  It is the user's responsibility to avoid doing this; the
  compiler works under the assumption that no such aliasing occurs.
*************** pointers will "incorrectly" optimize cod
*** 3174,3182 ****
  
     There are a number of restrictions on the attributes that can be
  applied to Cray pointers and pointees.  Pointees may not have the
! 'ALLOCATABLE', 'INTENT', 'OPTIONAL', 'DUMMY', 'TARGET', 'INTRINSIC', or
! 'POINTER' attributes.  Pointers may not have the 'DIMENSION', 'POINTER',
! 'TARGET', 'ALLOCATABLE', 'EXTERNAL', or 'INTRINSIC' attributes, nor may
  they be function results.  Pointees may not occur in more than one
  pointer statement.  A pointee cannot be a pointer.  Pointees cannot
  occur in equivalence, common, or data statements.
--- 3174,3182 ----
  
     There are a number of restrictions on the attributes that can be
  applied to Cray pointers and pointees.  Pointees may not have the
! ‘ALLOCATABLE’, ‘INTENT’, ‘OPTIONAL’, ‘DUMMY’, ‘TARGET’, ‘INTRINSIC’, or
! ‘POINTER’ attributes.  Pointers may not have the ‘DIMENSION’, ‘POINTER’,
! ‘TARGET’, ‘ALLOCATABLE’, ‘EXTERNAL’, or ‘INTRINSIC’ attributes, nor may
  they be function results.  Pointees may not occur in more than one
  pointer statement.  A pointee cannot be a pointer.  Pointees cannot
  occur in equivalence, common, or data statements.
*************** change the base address of the array tha
*** 3203,3245 ****
  
  File: gfortran.info,  Node: CONVERT specifier,  Next: OpenMP,  Prev: Cray pointers,  Up: Extensions implemented in GNU Fortran
  
! 5.1.17 'CONVERT' specifier
  --------------------------
  
  GNU Fortran allows the conversion of unformatted data between little-
  and big-endian representation to facilitate moving of data between
! different systems.  The conversion can be indicated with the 'CONVERT'
! specifier on the 'OPEN' statement.  *Note GFORTRAN_CONVERT_UNIT::, for
  an alternative way of specifying the data format via an environment
  variable.
  
!    Valid values for 'CONVERT' on most systems are:
!      'CONVERT='NATIVE'' Use the native format.  This is the default.
!      'CONVERT='SWAP'' Swap between little- and big-endian.
!      'CONVERT='LITTLE_ENDIAN'' Use the little-endian representation for
       unformatted files.
!      'CONVERT='BIG_ENDIAN'' Use the big-endian representation for
       unformatted files.
!    On POWER systems which support '-mabi=ieeelongdouble', there are
  additional options, which can be combined with the others with commas.
  Those are
!      'CONVERT='R16_IEEE'' Use IEEE 128-bit format for 'REAL(KIND=16)'.
!      'CONVERT='R16_IBM'' Use IBM 'long double' format for
!      real'REAL(KIND=16)'.
  
     Using the option could look like this:
         open(file='big.dat',form='unformatted',access='sequential', &
              convert='big_endian')
  
     The value of the conversion can be queried by using
! 'INQUIRE(CONVERT=ch)'.  The values returned are ''BIG_ENDIAN'' and
! ''LITTLE_ENDIAN''.
  
!    'CONVERT' works between big- and little-endian for 'INTEGER' values
! of all supported kinds and for 'REAL' on IEEE systems of kinds 4 and 8.
  Conversion between different "extended double" types on different
  architectures such as m68k and x86_64, which GNU Fortran supports as
! 'REAL(KIND=10)' and 'REAL(KIND=16)', will probably not work.
  
     _Note that the values specified via the GFORTRAN_CONVERT_UNIT
  environment variable will override the CONVERT specifier in the open
--- 3203,3245 ----
  
  File: gfortran.info,  Node: CONVERT specifier,  Next: OpenMP,  Prev: Cray pointers,  Up: Extensions implemented in GNU Fortran
  
! 5.1.17 ‘CONVERT’ specifier
  --------------------------
  
  GNU Fortran allows the conversion of unformatted data between little-
  and big-endian representation to facilitate moving of data between
! different systems.  The conversion can be indicated with the ‘CONVERT’
! specifier on the ‘OPEN’ statement.  *Note GFORTRAN_CONVERT_UNIT::, for
  an alternative way of specifying the data format via an environment
  variable.
  
!    Valid values for ‘CONVERT’ on most systems are:
!      ‘CONVERT='NATIVE'’ Use the native format.  This is the default.
!      ‘CONVERT='SWAP'’ Swap between little- and big-endian.
!      ‘CONVERT='LITTLE_ENDIAN'’ Use the little-endian representation for
       unformatted files.
!      ‘CONVERT='BIG_ENDIAN'’ Use the big-endian representation for
       unformatted files.
!    On POWER systems which support ‘-mabi=ieeelongdouble’, there are
  additional options, which can be combined with the others with commas.
  Those are
!      ‘CONVERT='R16_IEEE'’ Use IEEE 128-bit format for ‘REAL(KIND=16)’.
!      ‘CONVERT='R16_IBM'’ Use IBM ‘long double’ format for
!      real‘REAL(KIND=16)’.
  
     Using the option could look like this:
         open(file='big.dat',form='unformatted',access='sequential', &
              convert='big_endian')
  
     The value of the conversion can be queried by using
! ‘INQUIRE(CONVERT=ch)’.  The values returned are ‘'BIG_ENDIAN'’ and
! ‘'LITTLE_ENDIAN'’.
  
!    ‘CONVERT’ works between big- and little-endian for ‘INTEGER’ values
! of all supported kinds and for ‘REAL’ on IEEE systems of kinds 4 and 8.
  Conversion between different "extended double" types on different
  architectures such as m68k and x86_64, which GNU Fortran supports as
! ‘REAL(KIND=10)’ and ‘REAL(KIND=16)’, will probably not work.
  
     _Note that the values specified via the GFORTRAN_CONVERT_UNIT
  environment variable will override the CONVERT specifier in the open
*************** run-time behavior.
*** 3266,3282 ****
     GNU Fortran strives to be compatible to the OpenMP Application
  Program Interface v4.5 (https://openmp.org/specifications/).
  
!    To enable the processing of the OpenMP directive '!$omp' in free-form
! source code; the 'c$omp', '*$omp' and '!$omp' directives in fixed form;
! the '!$' conditional compilation sentinels in free form; and the 'c$',
! '*$' and '!$' sentinels in fixed form, 'gfortran' needs to be invoked
! with the '-fopenmp'.  This also arranges for automatic linking of the
  GNU Offloading and Multi Processing Runtime Library *note libgomp:
  (libgomp)Top.
  
     The OpenMP Fortran runtime library routines are provided both in a
! form of a Fortran 90 module named 'omp_lib' and in a form of a Fortran
! 'include' file named 'omp_lib.h'.
  
     An example of a parallelized loop taken from Appendix A.1 of the
  OpenMP Application Program Interface v2.5:
--- 3266,3282 ----
     GNU Fortran strives to be compatible to the OpenMP Application
  Program Interface v4.5 (https://openmp.org/specifications/).
  
!    To enable the processing of the OpenMP directive ‘!$omp’ in free-form
! source code; the ‘c$omp’, ‘*$omp’ and ‘!$omp’ directives in fixed form;
! the ‘!$’ conditional compilation sentinels in free form; and the ‘c$’,
! ‘*$’ and ‘!$’ sentinels in fixed form, ‘gfortran’ needs to be invoked
! with the ‘-fopenmp’.  This also arranges for automatic linking of the
  GNU Offloading and Multi Processing Runtime Library *note libgomp:
  (libgomp)Top.
  
     The OpenMP Fortran runtime library routines are provided both in a
! form of a Fortran 90 module named ‘omp_lib’ and in a form of a Fortran
! ‘include’ file named ‘omp_lib.h’.
  
     An example of a parallelized loop taken from Appendix A.1 of the
  OpenMP Application Program Interface v2.5:
*************** OpenMP Application Program Interface v2.
*** 3291,3307 ****
       END SUBROUTINE A1
  
     Please note:
!    * '-fopenmp' implies '-frecursive', i.e., all local arrays will be
       allocated on the stack.  When porting existing code to OpenMP, this
       may lead to surprising results, especially to segmentation faults
       if the stacksize is limited.
  
!    * On glibc-based systems, OpenMP enabled applications cannot be
       statically linked due to limitations of the underlying
       pthreads-implementation.  It might be possible to get a working
!      solution if '-Wl,--whole-archive -lpthread -Wl,--no-whole-archive'
       is added to the command line.  However, this is not supported by
!      'gcc' and thus not recommended.
  
  
  File: gfortran.info,  Node: OpenACC,  Next: Argument list functions,  Prev: OpenMP,  Up: Extensions implemented in GNU Fortran
--- 3291,3307 ----
       END SUBROUTINE A1
  
     Please note:
!    • ‘-fopenmp’ implies ‘-frecursive’, i.e., all local arrays will be
       allocated on the stack.  When porting existing code to OpenMP, this
       may lead to surprising results, especially to segmentation faults
       if the stacksize is limited.
  
!    • On glibc-based systems, OpenMP enabled applications cannot be
       statically linked due to limitations of the underlying
       pthreads-implementation.  It might be possible to get a working
!      solution if ‘-Wl,--whole-archive -lpthread -Wl,--no-whole-archive’
       is added to the command line.  However, this is not supported by
!      ‘gcc’ and thus not recommended.
  
  
  File: gfortran.info,  Node: OpenACC,  Next: Argument list functions,  Prev: OpenMP,  Up: Extensions implemented in GNU Fortran
*************** influence run-time behavior.
*** 3317,3341 ****
     GNU Fortran strives to be compatible to the OpenACC Application
  Programming Interface v2.6 (https://www.openacc.org/).
  
!    To enable the processing of the OpenACC directive '!$acc' in
! free-form source code; the 'c$acc', '*$acc' and '!$acc' directives in
! fixed form; the '!$' conditional compilation sentinels in free form; and
! the 'c$', '*$' and '!$' sentinels in fixed form, 'gfortran' needs to be
! invoked with the '-fopenacc'.  This also arranges for automatic linking
  of the GNU Offloading and Multi Processing Runtime Library *note
  libgomp: (libgomp)Top.
  
     The OpenACC Fortran runtime library routines are provided both in a
! form of a Fortran 90 module named 'openacc' and in a form of a Fortran
! 'include' file named 'openacc_lib.h'.
  
  
  File: gfortran.info,  Node: Argument list functions,  Next: Read/Write after EOF marker,  Prev: OpenACC,  Up: Extensions implemented in GNU Fortran
  
! 5.1.20 Argument list functions '%VAL', '%REF' and '%LOC'
  --------------------------------------------------------
  
! GNU Fortran supports argument list functions '%VAL', '%REF' and '%LOC'
  statements, for backward compatibility with g77.  It is recommended that
  these should be used only for code that is accessing facilities outside
  of GNU Fortran, such as operating system or windowing facilities.  It is
--- 3317,3341 ----
     GNU Fortran strives to be compatible to the OpenACC Application
  Programming Interface v2.6 (https://www.openacc.org/).
  
!    To enable the processing of the OpenACC directive ‘!$acc’ in
! free-form source code; the ‘c$acc’, ‘*$acc’ and ‘!$acc’ directives in
! fixed form; the ‘!$’ conditional compilation sentinels in free form; and
! the ‘c$’, ‘*$’ and ‘!$’ sentinels in fixed form, ‘gfortran’ needs to be
! invoked with the ‘-fopenacc’.  This also arranges for automatic linking
  of the GNU Offloading and Multi Processing Runtime Library *note
  libgomp: (libgomp)Top.
  
     The OpenACC Fortran runtime library routines are provided both in a
! form of a Fortran 90 module named ‘openacc’ and in a form of a Fortran
! ‘include’ file named ‘openacc_lib.h’.
  
  
  File: gfortran.info,  Node: Argument list functions,  Next: Read/Write after EOF marker,  Prev: OpenACC,  Up: Extensions implemented in GNU Fortran
  
! 5.1.20 Argument list functions ‘%VAL’, ‘%REF’ and ‘%LOC’
  --------------------------------------------------------
  
! GNU Fortran supports argument list functions ‘%VAL’, ‘%REF’ and ‘%LOC’
  statements, for backward compatibility with g77.  It is recommended that
  these should be used only for code that is accessing facilities outside
  of GNU Fortran, such as operating system or windowing facilities.  It is
*************** use by the program as a whole, but are t
*** 3346,3355 ****
  should be thoroughly tested each time they are rebuilt using a new
  compiler or version of a compiler.
  
!    '%VAL' passes a scalar argument by value, '%REF' passes it by
! reference and '%LOC' passes its memory location.  Since gfortran already
! passes scalar arguments by reference, '%REF' is in effect a do-nothing.
! '%LOC' has the same effect as a Fortran pointer.
  
     An example of passing an argument by value to a C subroutine foo.:
       C
--- 3346,3355 ----
  should be thoroughly tested each time they are rebuilt using a new
  compiler or version of a compiler.
  
!    ‘%VAL’ passes a scalar argument by value, ‘%REF’ passes it by
! reference and ‘%LOC’ passes its memory location.  Since gfortran already
! passes scalar arguments by reference, ‘%REF’ is in effect a do-nothing.
! ‘%LOC’ has the same effect as a Fortran pointer.
  
     An example of passing an argument by value to a C subroutine foo.:
       C
*************** passes scalar arguments by reference, '%
*** 3364,3370 ****
     For details refer to the g77 manual
  .
  
!    Also, 'c_by_val.f' and its partner 'c_by_val.c' of the GNU Fortran
  testsuite are worth a look.
  
  
--- 3364,3370 ----
     For details refer to the g77 manual
  .
  
!    Also, ‘c_by_val.f’ and its partner ‘c_by_val.c’ of the GNU Fortran
  testsuite are worth a look.
  
  
*************** File: gfortran.info,  Node: Read/Write a
*** 3373,3402 ****
  5.1.21 Read/Write after EOF marker
  ----------------------------------
  
! Some legacy codes rely on allowing 'READ' or 'WRITE' after the EOF file
  marker in order to find the end of a file.  GNU Fortran normally rejects
  these codes with a run-time error message and suggests the user consider
! 'BACKSPACE' or 'REWIND' to properly position the file before the EOF
  marker.  As an extension, the run-time error may be disabled using
  -std=legacy.
  
  
  File: gfortran.info,  Node: STRUCTURE and RECORD,  Next: UNION and MAP,  Prev: Read/Write after EOF marker,  Up: Extensions implemented in GNU Fortran
  
! 5.1.22 'STRUCTURE' and 'RECORD'
  -------------------------------
  
  Record structures are a pre-Fortran-90 vendor extension to create
  user-defined aggregate data types.  Support for record structures in GNU
! Fortran can be enabled with the '-fdec-structure' compile flag.  If you
  have a choice, you should instead use Fortran 90's "derived types",
  which have a different syntax.
  
     In many cases, record structures can easily be converted to derived
! types.  To convert, replace 'STRUCTURE /'STRUCTURE-NAME'/' by 'TYPE'
! TYPE-NAME.  Additionally, replace 'RECORD /'STRUCTURE-NAME'/' by
! 'TYPE('TYPE-NAME')'.  Finally, in the component access, replace the
! period ('.') by the percent sign ('%').
  
     Here is an example of code using the non portable record structure
  syntax:
--- 3373,3402 ----
  5.1.21 Read/Write after EOF marker
  ----------------------------------
  
! Some legacy codes rely on allowing ‘READ’ or ‘WRITE’ after the EOF file
  marker in order to find the end of a file.  GNU Fortran normally rejects
  these codes with a run-time error message and suggests the user consider
! ‘BACKSPACE’ or ‘REWIND’ to properly position the file before the EOF
  marker.  As an extension, the run-time error may be disabled using
  -std=legacy.
  
  
  File: gfortran.info,  Node: STRUCTURE and RECORD,  Next: UNION and MAP,  Prev: Read/Write after EOF marker,  Up: Extensions implemented in GNU Fortran
  
! 5.1.22 ‘STRUCTURE’ and ‘RECORD’
  -------------------------------
  
  Record structures are a pre-Fortran-90 vendor extension to create
  user-defined aggregate data types.  Support for record structures in GNU
! Fortran can be enabled with the ‘-fdec-structure’ compile flag.  If you
  have a choice, you should instead use Fortran 90's "derived types",
  which have a different syntax.
  
     In many cases, record structures can easily be converted to derived
! types.  To convert, replace ‘STRUCTURE /’STRUCTURE-NAME‘/’ by ‘TYPE’
! TYPE-NAME.  Additionally, replace ‘RECORD /’STRUCTURE-NAME‘/’ by
! ‘TYPE(’TYPE-NAME‘)’.  Finally, in the component access, replace the
! period (‘.’) by the percent sign (‘%’).
  
     Here is an example of code using the non portable record structure
  syntax:
*************** This code can easily be rewritten in the
*** 3454,3463 ****
  GNU Fortran implements STRUCTURES like derived types with the following
  rules and exceptions:
  
!    * Structures act like derived types with the 'SEQUENCE' attribute.
       Otherwise they may contain no specifiers.
  
!    * Structures may contain a special field with the name '%FILL'.  This
       will create an anonymous component which cannot be accessed but
       occupies space just as if a component of the same type was declared
       in its place, useful for alignment purposes.  As an example, the
--- 3454,3463 ----
  GNU Fortran implements STRUCTURES like derived types with the following
  rules and exceptions:
  
!    • Structures act like derived types with the ‘SEQUENCE’ attribute.
       Otherwise they may contain no specifiers.
  
!    • Structures may contain a special field with the name ‘%FILL’.  This
       will create an anonymous component which cannot be accessed but
       occupies space just as if a component of the same type was declared
       in its place, useful for alignment purposes.  As an example, the
*************** rules and exceptions:
*** 3469,3475 ****
              character(4) end
            end structure
  
!    * Structures may share names with other symbols.  For example, the
       following is invalid for derived types, but valid for structures:
  
            structure /header/
--- 3469,3475 ----
              character(4) end
            end structure
  
!    • Structures may share names with other symbols.  For example, the
       following is invalid for derived types, but valid for structures:
  
            structure /header/
*************** rules and exceptions:
*** 3477,3483 ****
            end structure
            record /header/ header
  
!    * Structure types may be declared nested within another parent
       structure.  The syntax is:
            structure /type-name/
                ...
--- 3477,3483 ----
            end structure
            record /header/ header
  
!    • Structure types may be declared nested within another parent
       structure.  The syntax is:
            structure /type-name/
                ...
*************** rules and exceptions:
*** 3510,3541 ****
              character(10) memo
            end structure
  
!    * Structures may contain 'UNION' blocks.  For more detail see the
       section on *note UNION and MAP::.
  
!    * Structures support old-style initialization of components, like
       those described in *note Old-style variable initialization::.  For
       array initializers, an initializer may contain a repeat
!      specification of the form ' *
!      '.  The value of the integer indicates the
       number of times to repeat the constant initializer when expanding
       the initializer list.
  
  
  File: gfortran.info,  Node: UNION and MAP,  Next: Type variants for integer intrinsics,  Prev: STRUCTURE and RECORD,  Up: Extensions implemented in GNU Fortran
  
! 5.1.23 'UNION' and 'MAP'
  ------------------------
  
  Unions are an old vendor extension which were commonly used with the
! non-standard *note STRUCTURE and RECORD:: extensions.  Use of 'UNION'
! and 'MAP' is automatically enabled with '-fdec-structure'.
  
!    A 'UNION' declaration occurs within a structure; within the
! definition of each union is a number of 'MAP' blocks.  Each 'MAP' shares
  storage with its sibling maps (in the same union), and the size of the
  union is the size of the largest map within it, just as with unions in
! C. The major difference is that component references do not indicate
  which union or map the component is in (the compiler gets to figure that
  out).
  
--- 3510,3541 ----
              character(10) memo
            end structure
  
!    • Structures may contain ‘UNION’ blocks.  For more detail see the
       section on *note UNION and MAP::.
  
!    • Structures support old-style initialization of components, like
       those described in *note Old-style variable initialization::.  For
       array initializers, an initializer may contain a repeat
!      specification of the form ‘ *
!      ’.  The value of the integer indicates the
       number of times to repeat the constant initializer when expanding
       the initializer list.
  
  
  File: gfortran.info,  Node: UNION and MAP,  Next: Type variants for integer intrinsics,  Prev: STRUCTURE and RECORD,  Up: Extensions implemented in GNU Fortran
  
! 5.1.23 ‘UNION’ and ‘MAP’
  ------------------------
  
  Unions are an old vendor extension which were commonly used with the
! non-standard *note STRUCTURE and RECORD:: extensions.  Use of ‘UNION’
! and ‘MAP’ is automatically enabled with ‘-fdec-structure’.
  
!    A ‘UNION’ declaration occurs within a structure; within the
! definition of each union is a number of ‘MAP’ blocks.  Each ‘MAP’ shares
  storage with its sibling maps (in the same union), and the size of the
  union is the size of the largest map within it, just as with unions in
! C.  The major difference is that component references do not indicate
  which union or map the component is in (the compiler gets to figure that
  out).
  
*************** each are:
*** 3642,3648 ****
       J - INTEGER(kind=4)
       K - INTEGER(kind=8)
  
!    GNU Fortran supports these with the flag '-fdec-intrinsic-ints'.
  Intrinsics for which prefixed versions are available and in what form
  are noted in *note Intrinsic Procedures::.  The complete list of
  supported intrinsics is here:
--- 3642,3648 ----
       J - INTEGER(kind=4)
       K - INTEGER(kind=8)
  
!    GNU Fortran supports these with the flag ‘-fdec-intrinsic-ints’.
  Intrinsics for which prefixed versions are available and in what form
  are noted in *note Intrinsic Procedures::.  The complete list of
  supported intrinsics is here:
*************** supported intrinsics is here:
*** 3650,3690 ****
  Intrinsic      B              I              J              K
                                                              
  ---------------------------------------------------------------------------
! '*note ABS::'  'BABS'         'IIABS'        'JIABS'        'KIABS'
! '*note BTEST::''BBTEST'       'BITEST'       'BJTEST'       'BKTEST'
! '*note IAND::' 'BIAND'        'IIAND'        'JIAND'        'KIAND'
! '*note IBCLR::''BBCLR'        'IIBCLR'       'JIBCLR'       'KIBCLR'
! '*note IBITS::''BBITS'        'IIBITS'       'JIBITS'       'KIBITS'
! '*note IBSET::''BBSET'        'IIBSET'       'JIBSET'       'KIBSET'
! '*note IEOR::' 'BIEOR'        'IIEOR'        'JIEOR'        'KIEOR'
! '*note IOR::'  'BIOR'         'IIOR'         'JIOR'         'KIOR'
! '*note ISHFT::''BSHFT'        'IISHFT'       'JISHFT'       'KISHFT'
! '*note ISHFTC::''BSHFTC'      'IISHFTC'      'JISHFTC'      'KISHFTC'
! '*note MOD::'  'BMOD'         'IMOD'         'JMOD'         'KMOD'
! '*note NOT::'  'BNOT'         'INOT'         'JNOT'         'KNOT'
! '*note REAL::' '--'           'FLOATI'       'FLOATJ'       'FLOATK'
  
  
  File: gfortran.info,  Node: AUTOMATIC and STATIC attributes,  Next: Extended math intrinsics,  Prev: Type variants for integer intrinsics,  Up: Extensions implemented in GNU Fortran
  
! 5.1.25 'AUTOMATIC' and 'STATIC' attributes
  ------------------------------------------
  
! With '-fdec-static' GNU Fortran supports the DEC extended attributes
! 'STATIC' and 'AUTOMATIC' to provide explicit specification of entity
! storage.  These follow the syntax of the Fortran standard 'SAVE'
  attribute.
  
!    'STATIC' is exactly equivalent to 'SAVE', and specifies that an
! entity should be allocated in static memory.  As an example, 'STATIC'
  local variables will retain their values across multiple calls to a
  function.
  
!    Entities marked 'AUTOMATIC' will be stack automatic whenever
! possible.  'AUTOMATIC' is the default for local variables smaller than
! '-fmax-stack-var-size', unless '-fno-automatic' is given.  This
! attribute overrides '-fno-automatic', '-fmax-stack-var-size', and
! blanket 'SAVE' statements.
  
     Examples:
  
--- 3650,3690 ----
  Intrinsic      B              I              J              K
                                                              
  ---------------------------------------------------------------------------
! ‘*note ABS::’  ‘BABS’         ‘IIABS’        ‘JIABS’        ‘KIABS’
! ‘*note BTEST::’‘BBTEST’       ‘BITEST’       ‘BJTEST’       ‘BKTEST’
! ‘*note IAND::’ ‘BIAND’        ‘IIAND’        ‘JIAND’        ‘KIAND’
! ‘*note IBCLR::’‘BBCLR’        ‘IIBCLR’       ‘JIBCLR’       ‘KIBCLR’
! ‘*note IBITS::’‘BBITS’        ‘IIBITS’       ‘JIBITS’       ‘KIBITS’
! ‘*note IBSET::’‘BBSET’        ‘IIBSET’       ‘JIBSET’       ‘KIBSET’
! ‘*note IEOR::’ ‘BIEOR’        ‘IIEOR’        ‘JIEOR’        ‘KIEOR’
! ‘*note IOR::’  ‘BIOR’         ‘IIOR’         ‘JIOR’         ‘KIOR’
! ‘*note ISHFT::’‘BSHFT’        ‘IISHFT’       ‘JISHFT’       ‘KISHFT’
! ‘*note ISHFTC::’‘BSHFTC’      ‘IISHFTC’      ‘JISHFTC’      ‘KISHFTC’
! ‘*note MOD::’  ‘BMOD’         ‘IMOD’         ‘JMOD’         ‘KMOD’
! ‘*note NOT::’  ‘BNOT’         ‘INOT’         ‘JNOT’         ‘KNOT’
! ‘*note REAL::’ ‘--’           ‘FLOATI’       ‘FLOATJ’       ‘FLOATK’
  
  
  File: gfortran.info,  Node: AUTOMATIC and STATIC attributes,  Next: Extended math intrinsics,  Prev: Type variants for integer intrinsics,  Up: Extensions implemented in GNU Fortran
  
! 5.1.25 ‘AUTOMATIC’ and ‘STATIC’ attributes
  ------------------------------------------
  
! With ‘-fdec-static’ GNU Fortran supports the DEC extended attributes
! ‘STATIC’ and ‘AUTOMATIC’ to provide explicit specification of entity
! storage.  These follow the syntax of the Fortran standard ‘SAVE’
  attribute.
  
!    ‘STATIC’ is exactly equivalent to ‘SAVE’, and specifies that an
! entity should be allocated in static memory.  As an example, ‘STATIC’
  local variables will retain their values across multiple calls to a
  function.
  
!    Entities marked ‘AUTOMATIC’ will be stack automatic whenever
! possible.  ‘AUTOMATIC’ is the default for local variables smaller than
! ‘-fmax-stack-var-size’, unless ‘-fno-automatic’ is given.  This
! attribute overrides ‘-fno-automatic’, ‘-fmax-stack-var-size’, and
! blanket ‘SAVE’ statements.
  
     Examples:
  
*************** File: gfortran.info,  Node: Extended mat
*** 3716,3742 ****
  -------------------------------
  
  GNU Fortran supports an extended list of mathematical intrinsics with
! the compile flag '-fdec-math' for compatability with legacy code.  These
  intrinsics are described fully in *note Intrinsic Procedures:: where it
  is noted that they are extensions and should be avoided whenever
  possible.
  
!    Specifically, '-fdec-math' enables the *note COTAN:: intrinsic, and
  trigonometric intrinsics which accept or produce values in degrees
  instead of radians.  Here is a summary of the new intrinsics:
  
  Radians                              Degrees
  --------------------------------------------------------------------------
! '*note ACOS::'                       '*note ACOSD::'*
! '*note ASIN::'                       '*note ASIND::'*
! '*note ATAN::'                       '*note ATAND::'*
! '*note ATAN2::'                      '*note ATAN2D::'*
! '*note COS::'                        '*note COSD::'*
! '*note COTAN::'*                     '*note COTAND::'*
! '*note SIN::'                        '*note SIND::'*
! '*note TAN::'                        '*note TAND::'*
  
!    * Enabled with '-fdec-math'.
  
     For advanced users, it may be important to know the implementation of
  these functions.  They are simply wrappers around the standard radian
--- 3716,3742 ----
  -------------------------------
  
  GNU Fortran supports an extended list of mathematical intrinsics with
! the compile flag ‘-fdec-math’ for compatability with legacy code.  These
  intrinsics are described fully in *note Intrinsic Procedures:: where it
  is noted that they are extensions and should be avoided whenever
  possible.
  
!    Specifically, ‘-fdec-math’ enables the *note COTAN:: intrinsic, and
  trigonometric intrinsics which accept or produce values in degrees
  instead of radians.  Here is a summary of the new intrinsics:
  
  Radians                              Degrees
  --------------------------------------------------------------------------
! ‘*note ACOS::’                       ‘*note ACOSD::’*
! ‘*note ASIN::’                       ‘*note ASIND::’*
! ‘*note ATAN::’                       ‘*note ATAND::’*
! ‘*note ATAN2::’                      ‘*note ATAN2D::’*
! ‘*note COS::’                        ‘*note COSD::’*
! ‘*note COTAN::’*                     ‘*note COTAND::’*
! ‘*note SIN::’                        ‘*note SIND::’*
! ‘*note TAN::’                        ‘*note TAND::’*
  
!    * Enabled with ‘-fdec-math’.
  
     For advanced users, it may be important to know the implementation of
  these functions.  They are simply wrappers around the standard radian
*************** File: gfortran.info,  Node: TYPE as an a
*** 3764,3771 ****
  5.1.28 TYPE as an alias for PRINT
  ---------------------------------
  
! For compatibility, GNU Fortran will interpret 'TYPE' statements as
! 'PRINT' statements with the flag '-fdec'.  With this flag asserted, the
  following two examples are equivalent:
  
       TYPE *, 'hello world'
--- 3764,3771 ----
  5.1.28 TYPE as an alias for PRINT
  ---------------------------------
  
! For compatibility, GNU Fortran will interpret ‘TYPE’ statements as
! ‘PRINT’ statements with the flag ‘-fdec’.  With this flag asserted, the
  following two examples are equivalent:
  
       TYPE *, 'hello world'
*************** File: gfortran.info,  Node: %LOC as an r
*** 3778,3787 ****
  5.1.29 %LOC as an rvalue
  ------------------------
  
! Normally '%LOC' is allowed only in parameter lists.  However the
! intrinsic function 'LOC' does the same thing, and is usable as the
  right-hand-side of assignments.  For compatibility, GNU Fortran supports
! the use of '%LOC' as an alias for the builtin 'LOC' with '-std=legacy'.
  With this feature enabled the following two examples are equivalent:
  
       integer :: i, l
--- 3778,3787 ----
  5.1.29 %LOC as an rvalue
  ------------------------
  
! Normally ‘%LOC’ is allowed only in parameter lists.  However the
! intrinsic function ‘LOC’ does the same thing, and is usable as the
  right-hand-side of assignments.  For compatibility, GNU Fortran supports
! the use of ‘%LOC’ as an alias for the builtin ‘LOC’ with ‘-std=legacy’.
  With this feature enabled the following two examples are equivalent:
  
       integer :: i, l
*************** File: gfortran.info,  Node: .XOR. operat
*** 3797,3804 ****
  5.1.30 .XOR. operator
  ---------------------
  
! GNU Fortran supports '.XOR.' as a logical operator with '-std=legacy'
! for compatibility with legacy code.  '.XOR.' is equivalent to '.NEQV.'.
  That is, the output is true if and only if the inputs differ.
  
  
--- 3797,3804 ----
  5.1.30 .XOR. operator
  ---------------------
  
! GNU Fortran supports ‘.XOR.’ as a logical operator with ‘-std=legacy’
! for compatibility with legacy code.  ‘.XOR.’ is equivalent to ‘.NEQV.’.
  That is, the output is true if and only if the inputs differ.
  
  
*************** File: gfortran.info,  Node: Bitwise logi
*** 3807,3813 ****
  5.1.31 Bitwise logical operators
  --------------------------------
  
! With '-fdec', GNU Fortran relaxes the type constraints on logical
  operators to allow integer operands, and performs the corresponding
  bitwise operation instead.  This flag is for compatibility only, and
  should be avoided in new code.  Consider:
--- 3807,3813 ----
  5.1.31 Bitwise logical operators
  --------------------------------
  
! With ‘-fdec’, GNU Fortran relaxes the type constraints on logical
  operators to allow integer operands, and performs the corresponding
  bitwise operation instead.  This flag is for compatibility only, and
  should be avoided in new code.  Consider:
*************** should be avoided in new code.  Consider
*** 3817,3841 ****
         j = z'cc'
         print *, i .AND. j
  
!    In this example, compiled with '-fdec', GNU Fortran will replace the
! '.AND.' operation with a call to the intrinsic '*note IAND::' function,
! yielding the bitwise-and of 'i' and 'j'.
  
     Note that this conversion will occur if at least one operand is of
  integral type.  As a result, a logical operand will be converted to an
  integer when the other operand is an integer in a logical operation.  In
! this case, '.TRUE.' is converted to '1' and '.FALSE.' to '0'.
  
     Here is the mapping of logical operator to bitwise intrinsic used
! with '-fdec':
  
  Operator           Intrinsic          Bitwise operation
  ---------------------------------------------------------------------------
! '.NOT.'            '*note NOT::'      complement
! '.AND.'            '*note IAND::'     intersection
! '.OR.'             '*note IOR::'      union
! '.NEQV.'           '*note IEOR::'     exclusive or
! '.EQV.'            '*note NOT::(*note IEOR::)'complement of exclusive or
  
  
  File: gfortran.info,  Node: Extended I/O specifiers,  Next: Legacy PARAMETER statements,  Prev: Bitwise logical operators,  Up: Extensions implemented in GNU Fortran
--- 3817,3841 ----
         j = z'cc'
         print *, i .AND. j
  
!    In this example, compiled with ‘-fdec’, GNU Fortran will replace the
! ‘.AND.’ operation with a call to the intrinsic ‘*note IAND::’ function,
! yielding the bitwise-and of ‘i’ and ‘j’.
  
     Note that this conversion will occur if at least one operand is of
  integral type.  As a result, a logical operand will be converted to an
  integer when the other operand is an integer in a logical operation.  In
! this case, ‘.TRUE.’ is converted to ‘1’ and ‘.FALSE.’ to ‘0’.
  
     Here is the mapping of logical operator to bitwise intrinsic used
! with ‘-fdec’:
  
  Operator           Intrinsic          Bitwise operation
  ---------------------------------------------------------------------------
! ‘.NOT.’            ‘*note NOT::’      complement
! ‘.AND.’            ‘*note IAND::’     intersection
! ‘.OR.’             ‘*note IOR::’      union
! ‘.NEQV.’           ‘*note IEOR::’     exclusive or
! ‘.EQV.’            ‘*note NOT::(*note IEOR::)’complement of exclusive or
  
  
  File: gfortran.info,  Node: Extended I/O specifiers,  Next: Legacy PARAMETER statements,  Prev: Bitwise logical operators,  Up: Extensions implemented in GNU Fortran
*************** File: gfortran.info,  Node: Extended I/O
*** 3844,3858 ****
  ------------------------------
  
  GNU Fortran supports the additional legacy I/O specifiers
! 'CARRIAGECONTROL', 'READONLY', and 'SHARE' with the compile flag
! '-fdec', for compatibility.
  
! 'CARRIAGECONTROL'
!      The 'CARRIAGECONTROL' specifier allows a user to control line
       termination settings between output records for an I/O unit.  The
       specifier has no meaning for readonly files.  When
!      'CARRAIGECONTROL' is specified upon opening a unit for formatted
!      writing, the exact 'CARRIAGECONTROL' setting determines what
       characters to write between output records.  The syntax is:
  
            OPEN(..., CARRIAGECONTROL=cc)
--- 3844,3858 ----
  ------------------------------
  
  GNU Fortran supports the additional legacy I/O specifiers
! ‘CARRIAGECONTROL’, ‘READONLY’, and ‘SHARE’ with the compile flag
! ‘-fdec’, for compatibility.
  
! ‘CARRIAGECONTROL’
!      The ‘CARRIAGECONTROL’ specifier allows a user to control line
       termination settings between output records for an I/O unit.  The
       specifier has no meaning for readonly files.  When
!      ‘CARRAIGECONTROL’ is specified upon opening a unit for formatted
!      writing, the exact ‘CARRIAGECONTROL’ setting determines what
       characters to write between output records.  The syntax is:
  
            OPEN(..., CARRIAGECONTROL=cc)
*************** GNU Fortran supports the additional lega
*** 3860,3900 ****
       Where _cc_ is a character expression that evaluates to one of the
       following values:
  
!      ''LIST''       One line feed between records (default)
!      ''FORTRAN''    Legacy interpretation of the first character (see below)
!      ''NONE''       No separator between records
  
!      With 'CARRIAGECONTROL='FORTRAN'', when a record is written, the
       first character of the input record is not written, and instead
       determines the output record separator as follows:
  
       Leading character      Meaning                Output separating
                                                     character(s)
       ----------------------------------------------------------------------------
!      ''+''                  Overprinting           Carriage return only
!      ''-''                  New line               Line feed and carriage
                                                     return
!      ''0''                  Skip line              Two line feeds and carriage
                                                     return
!      ''1''                  New page               Form feed and carriage
                                                     return
!      ''$''                  Prompting              Line feed (no carriage
                                                     return)
!      'CHAR(0)'              Overprinting (no       None
                              advance)
  
! 'READONLY'
!      The 'READONLY' specifier may be given upon opening a unit, and is
!      equivalent to specifying 'ACTION='READ'', except that the file may
!      not be deleted on close (i.e.  'CLOSE' with 'STATUS="DELETE"').
       The syntax is:
  
            OPEN(..., READONLY)
  
! 'SHARE'
!      The 'SHARE' specifier allows system-level locking on a unit upon
       opening it for controlled access from multiple processes/threads.
!      The 'SHARE' specifier has several forms:
  
            OPEN(..., SHARE=sh)
            OPEN(..., SHARED)
--- 3860,3900 ----
       Where _cc_ is a character expression that evaluates to one of the
       following values:
  
!      ‘'LIST'’       One line feed between records (default)
!      ‘'FORTRAN'’    Legacy interpretation of the first character (see below)
!      ‘'NONE'’       No separator between records
  
!      With ‘CARRIAGECONTROL='FORTRAN'’, when a record is written, the
       first character of the input record is not written, and instead
       determines the output record separator as follows:
  
       Leading character      Meaning                Output separating
                                                     character(s)
       ----------------------------------------------------------------------------
!      ‘'+'’                  Overprinting           Carriage return only
!      ‘'-'’                  New line               Line feed and carriage
                                                     return
!      ‘'0'’                  Skip line              Two line feeds and carriage
                                                     return
!      ‘'1'’                  New page               Form feed and carriage
                                                     return
!      ‘'$'’                  Prompting              Line feed (no carriage
                                                     return)
!      ‘CHAR(0)’              Overprinting (no       None
                              advance)
  
! ‘READONLY’
!      The ‘READONLY’ specifier may be given upon opening a unit, and is
!      equivalent to specifying ‘ACTION='READ'’, except that the file may
!      not be deleted on close (i.e.  ‘CLOSE’ with ‘STATUS="DELETE"’).
       The syntax is:
  
            OPEN(..., READONLY)
  
! ‘SHARE’
!      The ‘SHARE’ specifier allows system-level locking on a unit upon
       opening it for controlled access from multiple processes/threads.
!      The ‘SHARE’ specifier has several forms:
  
            OPEN(..., SHARE=sh)
            OPEN(..., SHARED)
*************** GNU Fortran supports the additional lega
*** 3906,3922 ****
  
       Explicit form          Short form             Meaning
       ----------------------------------------------------------------------------
!      'SHARE='DENYRW''       'NOSHARED'             Exclusive (write) lock
!      'SHARE='DENYNONE''     'SHARED'               Shared (read) lock
  
       In general only one process may hold an exclusive (write) lock for
       a given file at a time, whereas many processes may hold shared
       (read) locks for the same file.
  
       The behavior of locking may vary with your operating system.  On
!      POSIX systems, locking is implemented with 'fcntl'.  Consult your
       corresponding operating system's manual pages for further details.
!      Locking via 'SHARE=' is not supported on other systems.
  
  
  File: gfortran.info,  Node: Legacy PARAMETER statements,  Next: Default exponents,  Prev: Extended I/O specifiers,  Up: Extensions implemented in GNU Fortran
--- 3906,3922 ----
  
       Explicit form          Short form             Meaning
       ----------------------------------------------------------------------------
!      ‘SHARE='DENYRW'’       ‘NOSHARED’             Exclusive (write) lock
!      ‘SHARE='DENYNONE'’     ‘SHARED’               Shared (read) lock
  
       In general only one process may hold an exclusive (write) lock for
       a given file at a time, whereas many processes may hold shared
       (read) locks for the same file.
  
       The behavior of locking may vary with your operating system.  On
!      POSIX systems, locking is implemented with ‘fcntl’.  Consult your
       corresponding operating system's manual pages for further details.
!      Locking via ‘SHARE=’ is not supported on other systems.
  
  
  File: gfortran.info,  Node: Legacy PARAMETER statements,  Next: Default exponents,  Prev: Extended I/O specifiers,  Up: Extensions implemented in GNU Fortran
*************** File: gfortran.info,  Node: Legacy PARAM
*** 3925,3933 ****
  ----------------------------------
  
  For compatibility, GNU Fortran supports legacy PARAMETER statements
! without parentheses with '-std=legacy'.  A warning is emitted if used
! with '-std=gnu', and an error is acknowledged with a real Fortran
! standard flag ('-std=f95', etc...).  These statements take the following
  form:
  
       implicit real (E)
--- 3925,3933 ----
  ----------------------------------
  
  For compatibility, GNU Fortran supports legacy PARAMETER statements
! without parentheses with ‘-std=legacy’.  A warning is emitted if used
! with ‘-std=gnu’, and an error is acknowledged with a real Fortran
! standard flag (‘-std=f95’, etc...).  These statements take the following
  form:
  
       implicit real (E)
*************** File: gfortran.info,  Node: Default expo
*** 3942,3949 ****
  ------------------------
  
  For compatibility, GNU Fortran supports a default exponent of zero in
! real constants with '-fdec'.  For example, '9e' would be interpreted as
! '9e0', rather than an error.
  
  
  File: gfortran.info,  Node: Extensions not implemented in GNU Fortran,  Prev: Extensions implemented in GNU Fortran,  Up: Extensions
--- 3942,3949 ----
  ------------------------
  
  For compatibility, GNU Fortran supports a default exponent of zero in
! real constants with ‘-fdec’.  For example, ‘9e’ would be interpreted as
! ‘9e0’, rather than an error.
  
  
  File: gfortran.info,  Node: Extensions not implemented in GNU Fortran,  Prev: Extensions implemented in GNU Fortran,  Up: Extensions
*************** make code that uses them running with th
*** 3972,3983 ****
  
  File: gfortran.info,  Node: ENCODE and DECODE statements,  Next: Variable FORMAT expressions,  Up: Extensions not implemented in GNU Fortran
  
! 5.2.1 'ENCODE' and 'DECODE' statements
  --------------------------------------
  
! GNU Fortran does not support the 'ENCODE' and 'DECODE' statements.
! These statements are best replaced by 'READ' and 'WRITE' statements
! involving internal files ('CHARACTER' variables and arrays), which have
  been part of the Fortran standard since Fortran 77.  For example,
  replace a code fragment like
  
--- 3972,3983 ----
  
  File: gfortran.info,  Node: ENCODE and DECODE statements,  Next: Variable FORMAT expressions,  Up: Extensions not implemented in GNU Fortran
  
! 5.2.1 ‘ENCODE’ and ‘DECODE’ statements
  --------------------------------------
  
! GNU Fortran does not support the ‘ENCODE’ and ‘DECODE’ statements.
! These statements are best replaced by ‘READ’ and ‘WRITE’ statements
! involving internal files (‘CHARACTER’ variables and arrays), which have
  been part of the Fortran standard since Fortran 77.  For example,
  replace a code fragment like
  
*************** with the following:
*** 4014,4024 ****
  
  File: gfortran.info,  Node: Variable FORMAT expressions,  Next: Alternate complex function syntax,  Prev: ENCODE and DECODE statements,  Up: Extensions not implemented in GNU Fortran
  
! 5.2.2 Variable 'FORMAT' expressions
  -----------------------------------
  
! A variable 'FORMAT' expression is format statement which includes angle
! brackets enclosing a Fortran expression: 'FORMAT(I)'.  GNU Fortran
  does not support this legacy extension.  The effect of variable format
  expressions can be reproduced by using the more powerful (and standard)
  combination of internal output and string formats.  For example, replace
--- 4014,4024 ----
  
  File: gfortran.info,  Node: Variable FORMAT expressions,  Next: Alternate complex function syntax,  Prev: ENCODE and DECODE statements,  Up: Extensions not implemented in GNU Fortran
  
! 5.2.2 Variable ‘FORMAT’ expressions
  -----------------------------------
  
! A variable ‘FORMAT’ expression is format statement which includes angle
! brackets enclosing a Fortran expression: ‘FORMAT(I)’.  GNU Fortran
  does not support this legacy extension.  The effect of variable format
  expressions can be reproduced by using the more powerful (and standard)
  combination of internal output and string formats.  For example, replace
*************** File: gfortran.info,  Node: Alternate co
*** 4053,4106 ****
  5.2.3 Alternate complex function syntax
  ---------------------------------------
  
! Some Fortran compilers, including 'g77', let the user declare complex
! functions with the syntax 'COMPLEX FUNCTION name*16()', as well as
! 'COMPLEX*16 FUNCTION name()'.  Both are non-standard, legacy extensions.
! 'gfortran' accepts the latter form, which is more common, but not the
  former.
  
  
  File: gfortran.info,  Node: Volatile COMMON blocks,  Next: OPEN( ... NAME=),  Prev: Alternate complex function syntax,  Up: Extensions not implemented in GNU Fortran
  
! 5.2.4 Volatile 'COMMON' blocks
  ------------------------------
  
! Some Fortran compilers, including 'g77', let the user declare 'COMMON'
! with the 'VOLATILE' attribute.  This is invalid standard Fortran syntax
! and is not supported by 'gfortran'.  Note that 'gfortran' accepts
! 'VOLATILE' variables in 'COMMON' blocks since revision 4.3.
  
  
  File: gfortran.info,  Node: OPEN( ... NAME=),  Next: Q edit descriptor,  Prev: Volatile COMMON blocks,  Up: Extensions not implemented in GNU Fortran
  
! 5.2.5 'OPEN( ... NAME=)'
  ------------------------
  
! Some Fortran compilers, including 'g77', let the user declare 'OPEN( ...
! NAME=)'.  This is invalid standard Fortran syntax and is not supported
! by 'gfortran'.  'OPEN( ... NAME=)' should be replaced with 'OPEN( ...
! FILE=)'.
  
  
  File: gfortran.info,  Node: Q edit descriptor,  Prev: OPEN( ... NAME=),  Up: Extensions not implemented in GNU Fortran
  
! 5.2.6 'Q' edit descriptor
  -------------------------
  
! Some Fortran compilers provide the 'Q' edit descriptor, which transfers
  the number of characters left within an input record into an integer
  variable.
  
!    A direct replacement of the 'Q' edit descriptor is not available in
! 'gfortran'.  How to replicate its functionality using
  standard-conforming code depends on what the intent of the original code
  is.
  
!    Options to replace 'Q' may be to read the whole line into a character
  variable and then counting the number of non-blank characters left using
! 'LEN_TRIM'.  Another method may be to use formatted stream, read the
! data up to the position where the 'Q' descriptor occurred, use 'INQUIRE'
! to get the file position, count the characters up to the next 'NEW_LINE'
  and then start reading from the position marked previously.
  
  
--- 4053,4106 ----
  5.2.3 Alternate complex function syntax
  ---------------------------------------
  
! Some Fortran compilers, including ‘g77’, let the user declare complex
! functions with the syntax ‘COMPLEX FUNCTION name*16()’, as well as
! ‘COMPLEX*16 FUNCTION name()’.  Both are non-standard, legacy extensions.
! ‘gfortran’ accepts the latter form, which is more common, but not the
  former.
  
  
  File: gfortran.info,  Node: Volatile COMMON blocks,  Next: OPEN( ... NAME=),  Prev: Alternate complex function syntax,  Up: Extensions not implemented in GNU Fortran
  
! 5.2.4 Volatile ‘COMMON’ blocks
  ------------------------------
  
! Some Fortran compilers, including ‘g77’, let the user declare ‘COMMON’
! with the ‘VOLATILE’ attribute.  This is invalid standard Fortran syntax
! and is not supported by ‘gfortran’.  Note that ‘gfortran’ accepts
! ‘VOLATILE’ variables in ‘COMMON’ blocks since revision 4.3.
  
  
  File: gfortran.info,  Node: OPEN( ... NAME=),  Next: Q edit descriptor,  Prev: Volatile COMMON blocks,  Up: Extensions not implemented in GNU Fortran
  
! 5.2.5 ‘OPEN( ... NAME=)’
  ------------------------
  
! Some Fortran compilers, including ‘g77’, let the user declare ‘OPEN( ...
! NAME=)’.  This is invalid standard Fortran syntax and is not supported
! by ‘gfortran’.  ‘OPEN( ... NAME=)’ should be replaced with ‘OPEN( ...
! FILE=)’.
  
  
  File: gfortran.info,  Node: Q edit descriptor,  Prev: OPEN( ... NAME=),  Up: Extensions not implemented in GNU Fortran
  
! 5.2.6 ‘Q’ edit descriptor
  -------------------------
  
! Some Fortran compilers provide the ‘Q’ edit descriptor, which transfers
  the number of characters left within an input record into an integer
  variable.
  
!    A direct replacement of the ‘Q’ edit descriptor is not available in
! ‘gfortran’.  How to replicate its functionality using
  standard-conforming code depends on what the intent of the original code
  is.
  
!    Options to replace ‘Q’ may be to read the whole line into a character
  variable and then counting the number of non-blank characters left using
! ‘LEN_TRIM’.  Another method may be to use formatted stream, read the
! data up to the position where the ‘Q’ descriptor occurred, use ‘INQUIRE’
! to get the file position, count the characters up to the next ‘NEW_LINE’
  and then start reading from the position marked previously.
  
  
*************** cases, use of the C Binding features of
*** 4122,4135 ****
  standards is sufficient.
  
     For example, it is possible to mix Fortran code with C++ code as well
! as C, if you declare the interface functions as 'extern "C"' on the C++
! side and 'BIND(C)' on the Fortran side, and follow the rules for
  interoperability with C. Note that you cannot manipulate C++ class
  objects in Fortran or vice versa except as opaque pointers.
  
!    You can use the 'gfortran' command to link both Fortran and
! non-Fortran code into the same program, or you can use 'gcc' or 'g++' if
! you also add an explicit '-lgfortran' option to link with the Fortran
  library.  If your main program is written in C or some other language
  instead of Fortran, see *note Non-Fortran Main Program::, below.
  
--- 4122,4135 ----
  standards is sufficient.
  
     For example, it is possible to mix Fortran code with C++ code as well
! as C, if you declare the interface functions as ‘extern "C"’ on the C++
! side and ‘BIND(C)’ on the Fortran side, and follow the rules for
  interoperability with C. Note that you cannot manipulate C++ class
  objects in Fortran or vice versa except as opaque pointers.
  
!    You can use the ‘gfortran’ command to link both Fortran and
! non-Fortran code into the same program, or you can use ‘gcc’ or ‘g++’ if
! you also add an explicit ‘-lgfortran’ option to link with the Fortran
  library.  If your main program is written in C or some other language
  instead of Fortran, see *note Non-Fortran Main Program::, below.
  
*************** File: gfortran.info,  Node: Interoperabi
*** 4150,4156 ****
  
  Since Fortran 2003 (ISO/IEC 1539-1:2004(E)) there is a standardized way
  to generate procedure and derived-type declarations and global variables
! that are interoperable with C (ISO/IEC 9899:1999).  The 'BIND(C)'
  attribute has been added to inform the compiler that a symbol shall be
  interoperable with C; also, some constraints are added.  Note, however,
  that not all C features have a Fortran equivalent or vice versa.  For
--- 4150,4156 ----
  
  Since Fortran 2003 (ISO/IEC 1539-1:2004(E)) there is a standardized way
  to generate procedure and derived-type declarations and global variables
! that are interoperable with C (ISO/IEC 9899:1999).  The ‘BIND(C)’
  attribute has been added to inform the compiler that a symbol shall be
  interoperable with C; also, some constraints are added.  Note, however,
  that not all C features have a Fortran equivalent or vice versa.  For
*************** number of arguments have an equivalent i
*** 4159,4168 ****
  
     Note that array dimensions are reversely ordered in C and that arrays
  in C always start with index 0 while in Fortran they start by default
! with 1.  Thus, an array declaration 'A(n,m)' in Fortran matches
! 'A[m][n]' in C and accessing the element 'A(i,j)' matches 'A[j-1][i-1]'.
! The element following 'A(i,j)' (C: 'A[j-1][i-1]'; assuming i < n) in
! memory is 'A(i+1,j)' (C: 'A[j-1][i]').
  
  
  File: gfortran.info,  Node: Intrinsic Types,  Next: Derived Types and struct,  Up: Interoperability with C
--- 4159,4168 ----
  
     Note that array dimensions are reversely ordered in C and that arrays
  in C always start with index 0 while in Fortran they start by default
! with 1.  Thus, an array declaration ‘A(n,m)’ in Fortran matches
! ‘A[m][n]’ in C and accessing the element ‘A(i,j)’ matches ‘A[j-1][i-1]’.
! The element following ‘A(i,j)’ (C: ‘A[j-1][i-1]’; assuming i < n) in
! memory is ‘A(i+1,j)’ (C: ‘A[j-1][i]’).
  
  
  File: gfortran.info,  Node: Intrinsic Types,  Next: Derived Types and struct,  Up: Interoperability with C
*************** File: gfortran.info,  Node: Intrinsic Ty
*** 4172,4189 ****
  
  In order to ensure that exactly the same variable type and kind is used
  in C and Fortran, you should use the named constants for kind parameters
! that are defined in the 'ISO_C_BINDING' intrinsic module.  That module
  contains named constants of character type representing the escaped
  special characters in C, such as newline.  For a list of the constants,
  see *note ISO_C_BINDING::.
  
     For logical types, please note that the Fortran standard only
! guarantees interoperability between C99's '_Bool' and Fortran's
! 'C_Bool'-kind logicals and C99 defines that 'true' has the value 1 and
! 'false' the value 0.  Using any other integer value with GNU Fortran's
! 'LOGICAL' (with any kind parameter) gives an undefined result.  (Passing
! other integer values than 0 and 1 to GCC's '_Bool' is also undefined,
! unless the integer is explicitly or implicitly casted to '_Bool'.)
  
  
  File: gfortran.info,  Node: Derived Types and struct,  Next: Interoperable Global Variables,  Prev: Intrinsic Types,  Up: Interoperability with C
--- 4172,4189 ----
  
  In order to ensure that exactly the same variable type and kind is used
  in C and Fortran, you should use the named constants for kind parameters
! that are defined in the ‘ISO_C_BINDING’ intrinsic module.  That module
  contains named constants of character type representing the escaped
  special characters in C, such as newline.  For a list of the constants,
  see *note ISO_C_BINDING::.
  
     For logical types, please note that the Fortran standard only
! guarantees interoperability between C99's ‘_Bool’ and Fortran's
! ‘C_Bool’-kind logicals and C99 defines that ‘true’ has the value 1 and
! ‘false’ the value 0.  Using any other integer value with GNU Fortran's
! ‘LOGICAL’ (with any kind parameter) gives an undefined result.  (Passing
! other integer values than 0 and 1 to GCC's ‘_Bool’ is also undefined,
! unless the integer is explicitly or implicitly casted to ‘_Bool’.)
  
  
  File: gfortran.info,  Node: Derived Types and struct,  Next: Interoperable Global Variables,  Prev: Intrinsic Types,  Up: Interoperability with C
*************** File: gfortran.info,  Node: Derived Type
*** 4191,4197 ****
  6.1.2 Derived Types and struct
  ------------------------------
  
! For compatibility of derived types with 'struct', use the 'BIND(C)'
  attribute in the type declaration.  For instance, the following type
  declaration
  
--- 4191,4197 ----
  6.1.2 Derived Types and struct
  ------------------------------
  
! For compatibility of derived types with ‘struct’, use the ‘BIND(C)’
  attribute in the type declaration.  For instance, the following type
  declaration
  
*************** declaration
*** 4204,4210 ****
          CHARACTER(KIND=C_CHAR) :: str(5)
        END TYPE
  
! matches the following 'struct' declaration in C
  
        struct {
          int i1, i2;
--- 4204,4210 ----
          CHARACTER(KIND=C_CHAR) :: str(5)
        END TYPE
  
! matches the following ‘struct’ declaration in C
  
        struct {
          int i1, i2;
*************** matches the following 'struct' declarati
*** 4216,4224 ****
        } myType;
  
     Derived types with the C binding attribute shall not have the
! 'sequence' attribute, type parameters, the 'extends' attribute, nor
  type-bound procedures.  Every component must be of interoperable type
! and kind and may not have the 'pointer' or 'allocatable' attribute.  The
  names of the components are irrelevant for interoperability.
  
     As there exist no direct Fortran equivalents, neither unions nor
--- 4216,4224 ----
        } myType;
  
     Derived types with the C binding attribute shall not have the
! ‘sequence’ attribute, type parameters, the ‘extends’ attribute, nor
  type-bound procedures.  Every component must be of interoperable type
! and kind and may not have the ‘pointer’ or ‘allocatable’ attribute.  The
  names of the components are irrelevant for interoperability.
  
     As there exist no direct Fortran equivalents, neither unions nor
*************** File: gfortran.info,  Node: Interoperabl
*** 4233,4240 ****
  
  Variables can be made accessible from C using the C binding attribute,
  optionally together with specifying a binding name.  Those variables
! have to be declared in the declaration part of a 'MODULE', be of
! interoperable type, and have neither the 'pointer' nor the 'allocatable'
  attribute.
  
         MODULE m
--- 4233,4240 ----
  
  Variables can be made accessible from C using the C binding attribute,
  optionally together with specifying a binding name.  Those variables
! have to be declared in the declaration part of a ‘MODULE’, be of
! interoperable type, and have neither the ‘pointer’ nor the ‘allocatable’
  attribute.
  
         MODULE m
*************** attribute.
*** 4244,4256 ****
           type(myType), bind(C) :: tp
         END MODULE
  
!    Here, '_MyProject_flags' is the case-sensitive name of the variable
! as seen from C programs while 'global_flag' is the case-insensitive name
  as seen from Fortran.  If no binding name is specified, as for TP, the C
  binding name is the (lowercase) Fortran binding name.  If a binding name
  is specified, only a single variable may be after the double colon.
  Note of warning: You cannot use a global variable to access ERRNO of the
! C library as the C standard allows it to be a macro.  Use the 'IERRNO'
  intrinsic (GNU extension) instead.
  
  
--- 4244,4256 ----
           type(myType), bind(C) :: tp
         END MODULE
  
!    Here, ‘_MyProject_flags’ is the case-sensitive name of the variable
! as seen from C programs while ‘global_flag’ is the case-insensitive name
  as seen from Fortran.  If no binding name is specified, as for TP, the C
  binding name is the (lowercase) Fortran binding name.  If a binding name
  is specified, only a single variable may be after the double colon.
  Note of warning: You cannot use a global variable to access ERRNO of the
! C library as the C standard allows it to be a macro.  Use the ‘IERRNO’
  intrinsic (GNU extension) instead.
  
  
*************** File: gfortran.info,  Node: Interoperabl
*** 4259,4272 ****
  6.1.4 Interoperable Subroutines and Functions
  ---------------------------------------------
  
! Subroutines and functions have to have the 'BIND(C)' attribute to be
  compatible with C. The dummy argument declaration is relatively
  straightforward.  However, one needs to be careful because C uses
  call-by-value by default while Fortran behaves usually similar to
  call-by-reference.  Furthermore, strings and pointers are handled
  differently.
  
!    To pass a variable by value, use the 'VALUE' attribute.  Thus, the
  following C prototype
  
       int func(int i, int *j)
--- 4259,4272 ----
  6.1.4 Interoperable Subroutines and Functions
  ---------------------------------------------
  
! Subroutines and functions have to have the ‘BIND(C)’ attribute to be
  compatible with C. The dummy argument declaration is relatively
  straightforward.  However, one needs to be careful because C uses
  call-by-value by default while Fortran behaves usually similar to
  call-by-reference.  Furthermore, strings and pointers are handled
  differently.
  
!    To pass a variable by value, use the ‘VALUE’ attribute.  Thus, the
  following C prototype
  
       int func(int i, int *j)
*************** matches the Fortran declaration
*** 4278,4290 ****
           integer(c_int), VALUE :: i
           integer(c_int) :: j
  
!    Note that pointer arguments also frequently need the 'VALUE'
  attribute, see *note Working with C Pointers::.
  
     Strings are handled quite differently in C and Fortran.  In C a
! string is a 'NUL'-terminated array of characters while in Fortran each
  string has a length associated with it and is thus not terminated (by
! e.g.  'NUL').  For example, if you want to use the following C function,
  
         #include 
         void print_C(char *string) /* equivalent: char string[]  */
--- 4278,4290 ----
           integer(c_int), VALUE :: i
           integer(c_int) :: j
  
!    Note that pointer arguments also frequently need the ‘VALUE’
  attribute, see *note Working with C Pointers::.
  
     Strings are handled quite differently in C and Fortran.  In C a
! string is a ‘NUL’-terminated array of characters while in Fortran each
  string has a length associated with it and is thus not terminated (by
! e.g.  ‘NUL’).  For example, if you want to use the following C function,
  
         #include 
         void print_C(char *string) /* equivalent: char string[]  */
*************** to print "Hello World" from Fortran, you
*** 4303,4322 ****
         end interface
         call print_c(C_CHAR_"Hello World"//C_NULL_CHAR)
  
!    As the example shows, you need to ensure that the string is 'NUL'
! terminated.  Additionally, the dummy argument STRING of 'print_C' is a
! length-one assumed-size array; using 'character(len=*)' is not allowed.
! The example above uses 'c_char_"Hello World"' to ensure the string
  literal has the right type; typically the default character kind and
! 'c_char' are the same and thus '"Hello World"' is equivalent.  However,
  the standard does not guarantee this.
  
     The use of strings is now further illustrated using the C library
! function 'strncpy', whose prototype is
  
         char *strncpy(char *restrict s1, const char *restrict s2, size_t n);
  
! The function 'strncpy' copies at most N characters from string S2 to S1
  and returns S1.  In the following example, we ignore the return value:
  
         use iso_c_binding
--- 4303,4322 ----
         end interface
         call print_c(C_CHAR_"Hello World"//C_NULL_CHAR)
  
!    As the example shows, you need to ensure that the string is ‘NUL’
! terminated.  Additionally, the dummy argument STRING of ‘print_C’ is a
! length-one assumed-size array; using ‘character(len=*)’ is not allowed.
! The example above uses ‘c_char_"Hello World"’ to ensure the string
  literal has the right type; typically the default character kind and
! ‘c_char’ are the same and thus ‘"Hello World"’ is equivalent.  However,
  the standard does not guarantee this.
  
     The use of strings is now further illustrated using the C library
! function ‘strncpy’, whose prototype is
  
         char *strncpy(char *restrict s1, const char *restrict s2, size_t n);
  
! The function ‘strncpy’ copies at most N characters from string S2 to S1
  and returns S1.  In the following example, we ignore the return value:
  
         use iso_c_binding
*************** File: gfortran.info,  Node: Working with
*** 4348,4357 ****
  -----------------------------
  
  C pointers are represented in Fortran via the special opaque derived
! type 'type(c_ptr)' (with private components).  C pointers are distinct
! from Fortran objects with the 'POINTER' attribute.  Thus one needs to
  use intrinsic conversion procedures to convert from or to C pointers.
! For some applications, using an assumed type ('TYPE(*)') can be an
  alternative to a C pointer, and you can also use library routines to
  access Fortran pointers from C. See *note Further Interoperability of
  Fortran with C::.
--- 4348,4357 ----
  -----------------------------
  
  C pointers are represented in Fortran via the special opaque derived
! type ‘type(c_ptr)’ (with private components).  C pointers are distinct
! from Fortran objects with the ‘POINTER’ attribute.  Thus one needs to
  use intrinsic conversion procedures to convert from or to C pointers.
! For some applications, using an assumed type (‘TYPE(*)’) can be an
  alternative to a C pointer, and you can also use library routines to
  access Fortran pointers from C. See *note Further Interoperability of
  Fortran with C::.
*************** Fortran with C::.
*** 4369,4384 ****
         call c_f_pointer(cptr2, ps)
         call c_f_pointer(cptr2, pa, shape=[7])
  
!    When converting C to Fortran arrays, the one-dimensional 'SHAPE'
  argument has to be passed.
  
     If a pointer is a dummy argument of an interoperable procedure, it
! usually has to be declared using the 'VALUE' attribute.  'void*' matches
! 'TYPE(C_PTR), VALUE', while 'TYPE(C_PTR)' alone matches 'void**'.
  
     Procedure pointers are handled analogously to pointers; the C type is
! 'TYPE(C_FUNPTR)' and the intrinsic conversion procedures are
! 'C_F_PROCPOINTER' and 'C_FUNLOC'.
  
     Let us consider two examples of actually passing a procedure pointer
  from C to Fortran and vice versa.  Note that these examples are also
--- 4369,4384 ----
         call c_f_pointer(cptr2, ps)
         call c_f_pointer(cptr2, pa, shape=[7])
  
!    When converting C to Fortran arrays, the one-dimensional ‘SHAPE’
  argument has to be passed.
  
     If a pointer is a dummy argument of an interoperable procedure, it
! usually has to be declared using the ‘VALUE’ attribute.  ‘void*’ matches
! ‘TYPE(C_PTR), VALUE’, while ‘TYPE(C_PTR)’ alone matches ‘void**’.
  
     Procedure pointers are handled analogously to pointers; the C type is
! ‘TYPE(C_FUNPTR)’ and the intrinsic conversion procedures are
! ‘C_F_PROCPOINTER’ and ‘C_FUNLOC’.
  
     Let us consider two examples of actually passing a procedure pointer
  from C to Fortran and vice versa.  Note that these examples are also
*************** First, consider this code in C:
*** 4402,4410 ****
         get_values (&print_it);
       }
  
!    A matching implementation for 'get_values' in Fortran, that correctly
  receives the procedure pointer from C and is able to call it, is given
! in the following 'MODULE':
  
       MODULE m
         IMPLICIT NONE
--- 4402,4410 ----
         get_values (&print_it);
       }
  
!    A matching implementation for ‘get_values’ in Fortran, that correctly
  receives the procedure pointer from C and is able to call it, is given
! in the following ‘MODULE’:
  
       MODULE m
         IMPLICIT NONE
*************** GNU Fortran implements the Technical Spe
*** 4497,4513 ****
  29113:2012, which extends the interoperability support of Fortran 2003
  and Fortran 2008 and is now part of the 2018 Fortran standard.  Besides
  removing some restrictions and constraints, the Technical Specification
! adds assumed-type ('TYPE(*)') and assumed-rank ('DIMENSION(..)')
  variables and allows for interoperability of assumed-shape,
  assumed-rank, and deferred-shape arrays, as well as allocatables and
! pointers.  Objects of these types are passed to 'BIND(C)' functions as
  descriptors with a standard interface, declared in the header file
! ''.
  
     Note: Currently, GNU Fortran does not use internally the array
  descriptor (dope vector) as specified in the Technical Specification,
  but uses an array descriptor with different fields in functions without
! the 'BIND(C)' attribute.  Arguments to functions marked 'BIND(C)' are
  converted to the specified form.  If you need to access GNU Fortran's
  internal array descriptor, you can use the Chasm Language
  Interoperability Tools, .
--- 4497,4513 ----
  29113:2012, which extends the interoperability support of Fortran 2003
  and Fortran 2008 and is now part of the 2018 Fortran standard.  Besides
  removing some restrictions and constraints, the Technical Specification
! adds assumed-type (‘TYPE(*)’) and assumed-rank (‘DIMENSION(..)’)
  variables and allows for interoperability of assumed-shape,
  assumed-rank, and deferred-shape arrays, as well as allocatables and
! pointers.  Objects of these types are passed to ‘BIND(C)’ functions as
  descriptors with a standard interface, declared in the header file
! ‘’.
  
     Note: Currently, GNU Fortran does not use internally the array
  descriptor (dope vector) as specified in the Technical Specification,
  but uses an array descriptor with different fields in functions without
! the ‘BIND(C)’ attribute.  Arguments to functions marked ‘BIND(C)’ are
  converted to the specified form.  If you need to access GNU Fortran's
  internal array descriptor, you can use the Chasm Language
  Interoperability Tools, .
*************** on the processor; see *note C Extensions
*** 4544,4552 ****
     For procedures and procedure pointers, the following attributes can
  be used to change the calling convention:
  
!    * 'CDECL' - standard C calling convention
!    * 'STDCALL' - convention where the called procedure pops the stack
!    * 'FASTCALL' - part of the arguments are passed via registers instead
       using the stack
  
     Besides changing the calling convention, the attributes also
--- 4544,4552 ----
     For procedures and procedure pointers, the following attributes can
  be used to change the calling convention:
  
!    • ‘CDECL’ - standard C calling convention
!    • ‘STDCALL’ - convention where the called procedure pops the stack
!    • ‘FASTCALL’ - part of the arguments are passed via registers instead
       using the stack
  
     Besides changing the calling convention, the attributes also
*************** the stack.  When assigning a procedure t
*** 4556,4592 ****
  should use the same calling convention.
  
     On some systems, procedures and global variables (module variables
! and 'COMMON' blocks) need special handling to be accessible when they
  are in a shared library.  The following attributes are available:
  
!    * 'DLLEXPORT' - provide a global pointer to a pointer in the DLL
!    * 'DLLIMPORT' - reference the function or variable using a global
       pointer
  
!    For dummy arguments, the 'NO_ARG_CHECK' attribute can be used; in
! other compilers, it is also known as 'IGNORE_TKR'.  For dummy arguments
  with this attribute actual arguments of any type and kind (similar to
! 'TYPE(*)'), scalars and arrays of any rank (no equivalent in Fortran
! standard) are accepted.  As with 'TYPE(*)', the argument is unlimited
  polymorphic and no type information is available.  Additionally, the
! argument may only be passed to dummy arguments with the 'NO_ARG_CHECK'
! attribute and as argument to the 'PRESENT' intrinsic function and to
! 'C_LOC' of the 'ISO_C_BINDING' module.
  
!    Variables with 'NO_ARG_CHECK' attribute shall be of assumed-type
! ('TYPE(*)'; recommended) or of type 'INTEGER', 'LOGICAL', 'REAL' or
! 'COMPLEX'.  They shall not have the 'ALLOCATE', 'CODIMENSION',
! 'INTENT(OUT)', 'POINTER' or 'VALUE' attribute; furthermore, they shall
! be either scalar or of assumed-size ('dimension(*)').  As 'TYPE(*)', the
! 'NO_ARG_CHECK' attribute requires an explicit interface.
  
!    * 'NO_ARG_CHECK' - disable the type, kind and rank checking
!    * 'DEPRECATED' - print a warning when using a such-tagged deprecated
       procedure, variable or parameter; the warning can be suppressed
!      with '-Wno-deprecated-declarations'.
!    * 'NOINLINE' - prevent inlining given function.
!    * 'NORETURN' - add a hint that a given function cannot return.
!    * 'WEAK' - emit the declaration of an external symbol as a weak
       symbol rather than a global.  This is primarily useful in defining
       library functions that can be overridden in user code, though it
       can also be used with non-function declarations.  The overriding
--- 4556,4592 ----
  should use the same calling convention.
  
     On some systems, procedures and global variables (module variables
! and ‘COMMON’ blocks) need special handling to be accessible when they
  are in a shared library.  The following attributes are available:
  
!    • ‘DLLEXPORT’ - provide a global pointer to a pointer in the DLL
!    • ‘DLLIMPORT’ - reference the function or variable using a global
       pointer
  
!    For dummy arguments, the ‘NO_ARG_CHECK’ attribute can be used; in
! other compilers, it is also known as ‘IGNORE_TKR’.  For dummy arguments
  with this attribute actual arguments of any type and kind (similar to
! ‘TYPE(*)’), scalars and arrays of any rank (no equivalent in Fortran
! standard) are accepted.  As with ‘TYPE(*)’, the argument is unlimited
  polymorphic and no type information is available.  Additionally, the
! argument may only be passed to dummy arguments with the ‘NO_ARG_CHECK’
! attribute and as argument to the ‘PRESENT’ intrinsic function and to
! ‘C_LOC’ of the ‘ISO_C_BINDING’ module.
  
!    Variables with ‘NO_ARG_CHECK’ attribute shall be of assumed-type
! (‘TYPE(*)’; recommended) or of type ‘INTEGER’, ‘LOGICAL’, ‘REAL’ or
! ‘COMPLEX’.  They shall not have the ‘ALLOCATE’, ‘CODIMENSION’,
! ‘INTENT(OUT)’, ‘POINTER’ or ‘VALUE’ attribute; furthermore, they shall
! be either scalar or of assumed-size (‘dimension(*)’).  As ‘TYPE(*)’, the
! ‘NO_ARG_CHECK’ attribute requires an explicit interface.
  
!    • ‘NO_ARG_CHECK’ - disable the type, kind and rank checking
!    • ‘DEPRECATED’ - print a warning when using a such-tagged deprecated
       procedure, variable or parameter; the warning can be suppressed
!      with ‘-Wno-deprecated-declarations’.
!    • ‘NOINLINE’ - prevent inlining given function.
!    • ‘NORETURN’ - add a hint that a given function cannot return.
!    • ‘WEAK’ - emit the declaration of an external symbol as a weak
       symbol rather than a global.  This is primarily useful in defining
       library functions that can be overridden in user code, though it
       can also be used with non-function declarations.  The overriding
*************** be either scalar or of assumed-size ('di
*** 4594,4603 ****
  
     The attributes are specified using the syntax
  
!    '!GCC$ ATTRIBUTES' ATTRIBUTE-LIST '::' VARIABLE-LIST
  
     where in free-form source code only whitespace is allowed before
! '!GCC$' and in fixed-form source code '!GCC$', 'cGCC$' or '*GCC$' shall
  start in the first column.
  
     For procedures, the compiler directives shall be placed into the body
--- 4594,4603 ----
  
     The attributes are specified using the syntax
  
!    ‘!GCC$ ATTRIBUTES’ ATTRIBUTE-LIST ‘::’ VARIABLE-LIST
  
     where in free-form source code only whitespace is allowed before
! ‘!GCC$’ and in fixed-form source code ‘!GCC$’, ‘cGCC$’ or ‘*GCC$’ shall
  start in the first column.
  
     For procedures, the compiler directives shall be placed into the body
*************** File: gfortran.info,  Node: UNROLL direc
*** 4612,4621 ****
  
  The syntax of the directive is
  
!    '!GCC$ unroll N'
  
     You can use this directive to control how many times a loop should be
! unrolled.  It must be placed immediately before a 'DO' loop and applies
  only to the loop that follows.  N is an integer constant specifying the
  unrolling factor.  The values of 0 and 1 block any unrolling of the
  loop.
--- 4612,4621 ----
  
  The syntax of the directive is
  
!    ‘!GCC$ unroll N’
  
     You can use this directive to control how many times a loop should be
! unrolled.  It must be placed immediately before a ‘DO’ loop and applies
  only to the loop that follows.  N is an integer constant specifying the
  unrolling factor.  The values of 0 and 1 block any unrolling of the
  loop.
*************** File: gfortran.info,  Node: BUILTIN dire
*** 4628,4639 ****
  
  The syntax of the directive is
  
!    '!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')'
  
     You can use this directive to define which middle-end built-ins
! provide vector implementations.  'B' is name of the middle-end built-in.
! 'FLAGS' are optional and must be either "(inbranch)" or "(notinbranch)".
! 'IF' statement is optional and is used to filter multilib ABIs for the
  built-in that should be vectorized.  Example usage:
  
       !GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
--- 4628,4639 ----
  
  The syntax of the directive is
  
!    ‘!GCC$ BUILTIN (B) attributes simd FLAGS IF('target')’
  
     You can use this directive to define which middle-end built-ins
! provide vector implementations.  ‘B’ is name of the middle-end built-in.
! ‘FLAGS’ are optional and must be either "(inbranch)" or "(notinbranch)".
! ‘IF’ statement is optional and is used to filter multilib ABIs for the
  built-in that should be vectorized.  Example usage:
  
       !GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
*************** File: gfortran.info,  Node: IVDEP direct
*** 4650,4659 ****
  
  The syntax of the directive is
  
!    '!GCC$ ivdep'
  
     This directive tells the compiler to ignore vector dependencies in
! the following loop.  It must be placed immediately before a 'DO' loop
  and applies only to the loop that follows.
  
     Sometimes the compiler may not have sufficient information to decide
--- 4650,4659 ----
  
  The syntax of the directive is
  
!    ‘!GCC$ ivdep’
  
     This directive tells the compiler to ignore vector dependencies in
! the following loop.  It must be placed immediately before a ‘DO’ loop
  and applies only to the loop that follows.
  
     Sometimes the compiler may not have sufficient information to decide
*************** File: gfortran.info,  Node: VECTOR direc
*** 4673,4682 ****
  
  The syntax of the directive is
  
!    '!GCC$ vector'
  
     This directive tells the compiler to vectorize the following loop.
! It must be placed immediately before a 'DO' loop and applies only to the
  loop that follows.
  
  
--- 4673,4682 ----
  
  The syntax of the directive is
  
!    ‘!GCC$ vector’
  
     This directive tells the compiler to vectorize the following loop.
! It must be placed immediately before a ‘DO’ loop and applies only to the
  loop that follows.
  
  
*************** File: gfortran.info,  Node: NOVECTOR dir
*** 4687,4696 ****
  
  The syntax of the directive is
  
!    '!GCC$ novector'
  
     This directive tells the compiler to not vectorize the following
! loop.  It must be placed immediately before a 'DO' loop and applies only
  to the loop that follows.
  
  
--- 4687,4696 ----
  
  The syntax of the directive is
  
!    ‘!GCC$ novector’
  
     This directive tells the compiler to not vectorize the following
! loop.  It must be placed immediately before a ‘DO’ loop and applies only
  to the loop that follows.
  
  
*************** you do not need to know or use the infor
*** 4713,4738 ****
  it is about the internal structure of GNU Fortran, it may also change in
  GCC minor releases.
  
!    When you compile a 'PROGRAM' with GNU Fortran, a function with the
! name 'main' (in the symbol table of the object file) is generated, which
  initializes the libgfortran library and then calls the actual program
! which uses the name 'MAIN__', for historic reasons.  If you link GNU
  Fortran compiled procedures to, e.g., a C or C++ program or to a Fortran
  program compiled by a different compiler, the libgfortran library is not
  initialized and thus a few intrinsic procedures do not work properly,
  e.g.  those for obtaining the command-line arguments.
  
!    Therefore, if your 'PROGRAM' is not compiled with GNU Fortran and the
  GNU Fortran compiled procedures require intrinsics relying on the
  library initialization, you need to initialize the library yourself.
! Using the default options, gfortran calls '_gfortran_set_args' and
! '_gfortran_set_options'.  The initialization of the former is needed if
  the called procedures access the command line (and for backtracing); the
  latter sets some flags based on the standard chosen or to enable
  backtracing.  In typical programs, it is not necessary to call any
  initialization function.
  
!    If your 'PROGRAM' is compiled with GNU Fortran, you shall not call
  any of the following functions.  The libgfortran initialization
  functions are shown in C syntax but using C bindings they are also
  accessible from Fortran.
--- 4713,4738 ----
  it is about the internal structure of GNU Fortran, it may also change in
  GCC minor releases.
  
!    When you compile a ‘PROGRAM’ with GNU Fortran, a function with the
! name ‘main’ (in the symbol table of the object file) is generated, which
  initializes the libgfortran library and then calls the actual program
! which uses the name ‘MAIN__’, for historic reasons.  If you link GNU
  Fortran compiled procedures to, e.g., a C or C++ program or to a Fortran
  program compiled by a different compiler, the libgfortran library is not
  initialized and thus a few intrinsic procedures do not work properly,
  e.g.  those for obtaining the command-line arguments.
  
!    Therefore, if your ‘PROGRAM’ is not compiled with GNU Fortran and the
  GNU Fortran compiled procedures require intrinsics relying on the
  library initialization, you need to initialize the library yourself.
! Using the default options, gfortran calls ‘_gfortran_set_args’ and
! ‘_gfortran_set_options’.  The initialization of the former is needed if
  the called procedures access the command line (and for backtracing); the
  latter sets some flags based on the standard chosen or to enable
  backtracing.  In typical programs, it is not necessary to call any
  initialization function.
  
!    If your ‘PROGRAM’ is compiled with GNU Fortran, you shall not call
  any of the following functions.  The libgfortran initialization
  functions are shown in C syntax but using C bindings they are also
  accessible from Fortran.
*************** accessible from Fortran.
*** 4740,4756 ****
  
  File: gfortran.info,  Node: _gfortran_set_args,  Next: _gfortran_set_options,  Up: Non-Fortran Main Program
  
! 6.3.1 '_gfortran_set_args' -- Save command-line arguments
  ---------------------------------------------------------
  
  _Description_:
!      '_gfortran_set_args' saves the command-line arguments; this
       initialization is required if any of the command-line intrinsics is
       called.  Additionally, it shall be called if backtracing is enabled
!      (see '_gfortran_set_options').
  
  _Syntax_:
!      'void _gfortran_set_args (int argc, char *argv[])'
  
  _Arguments_:
       ARGC        number of command line argument strings
--- 4740,4756 ----
  
  File: gfortran.info,  Node: _gfortran_set_args,  Next: _gfortran_set_options,  Up: Non-Fortran Main Program
  
! 6.3.1 ‘_gfortran_set_args’ -- Save command-line arguments
  ---------------------------------------------------------
  
  _Description_:
!      ‘_gfortran_set_args’ saves the command-line arguments; this
       initialization is required if any of the command-line intrinsics is
       called.  Additionally, it shall be called if backtracing is enabled
!      (see ‘_gfortran_set_options’).
  
  _Syntax_:
!      ‘void _gfortran_set_args (int argc, char *argv[])’
  
  _Arguments_:
       ARGC        number of command line argument strings
*************** _Example_:
*** 4768,4778 ****
  
  File: gfortran.info,  Node: _gfortran_set_options,  Next: _gfortran_set_convert,  Prev: _gfortran_set_args,  Up: Non-Fortran Main Program
  
! 6.3.2 '_gfortran_set_options' -- Set library option flags
  ---------------------------------------------------------
  
  _Description_:
!      '_gfortran_set_options' sets several flags related to the Fortran
       standard to be used, whether backtracing should be enabled and
       whether range checks should be performed.  The syntax allows for
       upward compatibility since the number of passed flags is specified;
--- 4768,4778 ----
  
  File: gfortran.info,  Node: _gfortran_set_options,  Next: _gfortran_set_convert,  Prev: _gfortran_set_args,  Up: Non-Fortran Main Program
  
! 6.3.2 ‘_gfortran_set_options’ -- Set library option flags
  ---------------------------------------------------------
  
  _Description_:
!      ‘_gfortran_set_options’ sets several flags related to the Fortran
       standard to be used, whether backtracing should be enabled and
       whether range checks should be performed.  The syntax allows for
       upward compatibility since the number of passed flags is specified;
*************** _Description_:
*** 4781,4787 ****
       used.
  
  _Syntax_:
!      'void _gfortran_set_options (int num, int options[])'
  
  _Arguments_:
       NUM         number of options passed
--- 4781,4787 ----
       used.
  
  _Syntax_:
!      ‘void _gfortran_set_options (int num, int options[])’
  
  _Arguments_:
       NUM         number of options passed
*************** _option flag list_:
*** 4791,4813 ****
       OPTION[0]   Allowed standard; can give run-time errors if
                   e.g.  an input-output edit descriptor is invalid
                   in a given standard.  Possible values are
!                  (bitwise or-ed) 'GFC_STD_F77' (1),
!                  'GFC_STD_F95_OBS' (2), 'GFC_STD_F95_DEL' (4),
!                  'GFC_STD_F95' (8), 'GFC_STD_F2003' (16),
!                  'GFC_STD_GNU' (32), 'GFC_STD_LEGACY' (64),
!                  'GFC_STD_F2008' (128), 'GFC_STD_F2008_OBS'
!                  (256), 'GFC_STD_F2008_TS' (512), 'GFC_STD_F2018'
!                  (1024), 'GFC_STD_F2018_OBS' (2048), and
!                  'GFC_STD=F2018_DEL' (4096).  Default:
!                  'GFC_STD_F95_OBS | GFC_STD_F95_DEL | GFC_STD_F95
                   | GFC_STD_F2003 | GFC_STD_F2008 |
                   GFC_STD_F2008_TS | GFC_STD_F2008_OBS |
                   GFC_STD_F77 | GFC_STD_F2018 | GFC_STD_F2018_OBS
                   | GFC_STD_F2018_DEL | GFC_STD_GNU |
!                  GFC_STD_LEGACY'.
       OPTION[1]   Standard-warning flag; prints a warning to
!                  standard error.  Default: 'GFC_STD_F95_DEL |
!                  GFC_STD_LEGACY'.
       OPTION[2]   If non zero, enable pedantic checking.  Default:
                   off.
       OPTION[3]   Unused.
--- 4791,4813 ----
       OPTION[0]   Allowed standard; can give run-time errors if
                   e.g.  an input-output edit descriptor is invalid
                   in a given standard.  Possible values are
!                  (bitwise or-ed) ‘GFC_STD_F77’ (1),
!                  ‘GFC_STD_F95_OBS’ (2), ‘GFC_STD_F95_DEL’ (4),
!                  ‘GFC_STD_F95’ (8), ‘GFC_STD_F2003’ (16),
!                  ‘GFC_STD_GNU’ (32), ‘GFC_STD_LEGACY’ (64),
!                  ‘GFC_STD_F2008’ (128), ‘GFC_STD_F2008_OBS’
!                  (256), ‘GFC_STD_F2008_TS’ (512), ‘GFC_STD_F2018’
!                  (1024), ‘GFC_STD_F2018_OBS’ (2048), and
!                  ‘GFC_STD=F2018_DEL’ (4096).  Default:
!                  ‘GFC_STD_F95_OBS | GFC_STD_F95_DEL | GFC_STD_F95
                   | GFC_STD_F2003 | GFC_STD_F2008 |
                   GFC_STD_F2008_TS | GFC_STD_F2008_OBS |
                   GFC_STD_F77 | GFC_STD_F2018 | GFC_STD_F2018_OBS
                   | GFC_STD_F2018_DEL | GFC_STD_GNU |
!                  GFC_STD_LEGACY’.
       OPTION[1]   Standard-warning flag; prints a warning to
!                  standard error.  Default: ‘GFC_STD_F95_DEL |
!                  GFC_STD_LEGACY’.
       OPTION[2]   If non zero, enable pedantic checking.  Default:
                   off.
       OPTION[3]   Unused.
*************** _option flag list_:
*** 4815,4821 ****
                   errors.  Default: off.  (Default in the
                   compiler: on.)  Note: Installs a signal handler
                   and requires command-line initialization using
!                  '_gfortran_set_args'.
       OPTION[5]   If non zero, supports signed zeros.  Default:
                   enabled.
       OPTION[6]   Enables run-time checking.  Possible values are
--- 4815,4821 ----
                   errors.  Default: off.  (Default in the
                   compiler: on.)  Note: Installs a signal handler
                   and requires command-line initialization using
!                  ‘_gfortran_set_args’.
       OPTION[5]   If non zero, supports signed zeros.  Default:
                   enabled.
       OPTION[6]   Enables run-time checking.  Possible values are
*************** _option flag list_:
*** 4825,4840 ****
                   GFC_RTCHECK_POINTER (16), GFC_RTCHECK_MEM (32),
                   GFC_RTCHECK_BITS (64).  Default: disabled.
       OPTION[7]   Unused.
!      OPTION[8]   Show a warning when invoking 'STOP' and 'ERROR
!                  STOP' if a floating-point exception occurred.
                   Possible values are (bitwise or-ed)
!                  'GFC_FPE_INVALID' (1), 'GFC_FPE_DENORMAL' (2),
!                  'GFC_FPE_ZERO' (4), 'GFC_FPE_OVERFLOW' (8),
!                  'GFC_FPE_UNDERFLOW' (16), 'GFC_FPE_INEXACT'
                   (32).  Default: None (0).  (Default in the
!                  compiler: 'GFC_FPE_INVALID | GFC_FPE_DENORMAL |
                   GFC_FPE_ZERO | GFC_FPE_OVERFLOW |
!                  GFC_FPE_UNDERFLOW'.)
  
  _Example_:
              /* Use gfortran 4.9 default options.  */
--- 4825,4840 ----
                   GFC_RTCHECK_POINTER (16), GFC_RTCHECK_MEM (32),
                   GFC_RTCHECK_BITS (64).  Default: disabled.
       OPTION[7]   Unused.
!      OPTION[8]   Show a warning when invoking ‘STOP’ and ‘ERROR
!                  STOP’ if a floating-point exception occurred.
                   Possible values are (bitwise or-ed)
!                  ‘GFC_FPE_INVALID’ (1), ‘GFC_FPE_DENORMAL’ (2),
!                  ‘GFC_FPE_ZERO’ (4), ‘GFC_FPE_OVERFLOW’ (8),
!                  ‘GFC_FPE_UNDERFLOW’ (16), ‘GFC_FPE_INEXACT’
                   (32).  Default: None (0).  (Default in the
!                  compiler: ‘GFC_FPE_INVALID | GFC_FPE_DENORMAL |
                   GFC_FPE_ZERO | GFC_FPE_OVERFLOW |
!                  GFC_FPE_UNDERFLOW’.)
  
  _Example_:
              /* Use gfortran 4.9 default options.  */
*************** _Example_:
*** 4844,4858 ****
  
  File: gfortran.info,  Node: _gfortran_set_convert,  Next: _gfortran_set_record_marker,  Prev: _gfortran_set_options,  Up: Non-Fortran Main Program
  
! 6.3.3 '_gfortran_set_convert' -- Set endian conversion
  ------------------------------------------------------
  
  _Description_:
!      '_gfortran_set_convert' set the representation of data for
       unformatted files.
  
  _Syntax_:
!      'void _gfortran_set_convert (int conv)'
  
  _Arguments_:
       CONV        Endian conversion, possible values:
--- 4844,4858 ----
  
  File: gfortran.info,  Node: _gfortran_set_convert,  Next: _gfortran_set_record_marker,  Prev: _gfortran_set_options,  Up: Non-Fortran Main Program
  
! 6.3.3 ‘_gfortran_set_convert’ -- Set endian conversion
  ------------------------------------------------------
  
  _Description_:
!      ‘_gfortran_set_convert’ set the representation of data for
       unformatted files.
  
  _Syntax_:
!      ‘void _gfortran_set_convert (int conv)’
  
  _Arguments_:
       CONV        Endian conversion, possible values:
*************** _Example_:
*** 4872,4886 ****
  
  File: gfortran.info,  Node: _gfortran_set_record_marker,  Next: _gfortran_set_fpe,  Prev: _gfortran_set_convert,  Up: Non-Fortran Main Program
  
! 6.3.4 '_gfortran_set_record_marker' -- Set length of record markers
  -------------------------------------------------------------------
  
  _Description_:
!      '_gfortran_set_record_marker' sets the length of record markers for
       unformatted files.
  
  _Syntax_:
!      'void _gfortran_set_record_marker (int val)'
  
  _Arguments_:
       VAL         Length of the record marker; valid values are 4
--- 4872,4886 ----
  
  File: gfortran.info,  Node: _gfortran_set_record_marker,  Next: _gfortran_set_fpe,  Prev: _gfortran_set_convert,  Up: Non-Fortran Main Program
  
! 6.3.4 ‘_gfortran_set_record_marker’ -- Set length of record markers
  -------------------------------------------------------------------
  
  _Description_:
!      ‘_gfortran_set_record_marker’ sets the length of record markers for
       unformatted files.
  
  _Syntax_:
!      ‘void _gfortran_set_record_marker (int val)’
  
  _Arguments_:
       VAL         Length of the record marker; valid values are 4
*************** _Example_:
*** 4898,4920 ****
  
  File: gfortran.info,  Node: _gfortran_set_fpe,  Next: _gfortran_set_max_subrecord_length,  Prev: _gfortran_set_record_marker,  Up: Non-Fortran Main Program
  
! 6.3.5 '_gfortran_set_fpe' -- Enable floating point exception traps
  ------------------------------------------------------------------
  
  _Description_:
!      '_gfortran_set_fpe' enables floating point exception traps for the
       specified exceptions.  On most systems, this will result in a
       SIGFPE signal being sent and the program being aborted.
  
  _Syntax_:
!      'void _gfortran_set_fpe (int val)'
  
  _Arguments_:
       OPTION[0]   IEEE exceptions.  Possible values are (bitwise
                   or-ed) zero (0, default) no trapping,
!                  'GFC_FPE_INVALID' (1), 'GFC_FPE_DENORMAL' (2),
!                  'GFC_FPE_ZERO' (4), 'GFC_FPE_OVERFLOW' (8),
!                  'GFC_FPE_UNDERFLOW' (16), and 'GFC_FPE_INEXACT'
                   (32).
  
  _Example_:
--- 4898,4920 ----
  
  File: gfortran.info,  Node: _gfortran_set_fpe,  Next: _gfortran_set_max_subrecord_length,  Prev: _gfortran_set_record_marker,  Up: Non-Fortran Main Program
  
! 6.3.5 ‘_gfortran_set_fpe’ -- Enable floating point exception traps
  ------------------------------------------------------------------
  
  _Description_:
!      ‘_gfortran_set_fpe’ enables floating point exception traps for the
       specified exceptions.  On most systems, this will result in a
       SIGFPE signal being sent and the program being aborted.
  
  _Syntax_:
!      ‘void _gfortran_set_fpe (int val)’
  
  _Arguments_:
       OPTION[0]   IEEE exceptions.  Possible values are (bitwise
                   or-ed) zero (0, default) no trapping,
!                  ‘GFC_FPE_INVALID’ (1), ‘GFC_FPE_DENORMAL’ (2),
!                  ‘GFC_FPE_ZERO’ (4), ‘GFC_FPE_OVERFLOW’ (8),
!                  ‘GFC_FPE_UNDERFLOW’ (16), and ‘GFC_FPE_INEXACT’
                   (32).
  
  _Example_:
*************** _Example_:
*** 4930,4945 ****
  
  File: gfortran.info,  Node: _gfortran_set_max_subrecord_length,  Prev: _gfortran_set_fpe,  Up: Non-Fortran Main Program
  
! 6.3.6 '_gfortran_set_max_subrecord_length' -- Set subrecord length
  ------------------------------------------------------------------
  
  _Description_:
!      '_gfortran_set_max_subrecord_length' set the maximum length for a
       subrecord.  This option only makes sense for testing and debugging
       of unformatted I/O.
  
  _Syntax_:
!      'void _gfortran_set_max_subrecord_length (int val)'
  
  _Arguments_:
       VAL         the maximum length for a subrecord; the maximum
--- 4930,4945 ----
  
  File: gfortran.info,  Node: _gfortran_set_max_subrecord_length,  Prev: _gfortran_set_fpe,  Up: Non-Fortran Main Program
  
! 6.3.6 ‘_gfortran_set_max_subrecord_length’ -- Set subrecord length
  ------------------------------------------------------------------
  
  _Description_:
!      ‘_gfortran_set_max_subrecord_length’ set the maximum length for a
       subrecord.  This option only makes sense for testing and debugging
       of unformatted I/O.
  
  _Syntax_:
!      ‘void _gfortran_set_max_subrecord_length (int val)’
  
  _Arguments_:
       VAL         the maximum length for a subrecord; the maximum
*************** File: gfortran.info,  Node: Naming conve
*** 4980,5006 ****
  ------------------------
  
  According the Fortran standard, valid Fortran names consist of a letter
! between 'A' to 'Z', 'a' to 'z', digits '0', '1' to '9' and underscores
! ('_') with the restriction that names may only start with a letter.  As
! vendor extension, the dollar sign ('$') is additionally permitted with
! the option '-fdollar-ok', but not as first character and only if the
  target system supports it.
  
     By default, the procedure name is the lower-cased Fortran name with
! an appended underscore ('_'); using '-fno-underscoring' no underscore is
! appended while '-fsecond-underscore' appends two underscores.  Depending
  on the target system and the calling convention, the procedure might be
! additionally dressed; for instance, on 32bit Windows with 'stdcall', an
! at-sign '@' followed by an integer number is appended.  For the changing
  the calling convention, see *note GNU Fortran Compiler Directives::.
  
     For common blocks, the same convention is used, i.e.  by default an
  underscore is appended to the lower-cased Fortran name.  Blank commons
! have the name '__BLNK__'.
  
     For procedures and variables declared in the specification space of a
! module, the name is formed by '__', followed by the lower-cased module
! name, '_MOD_', and the lower-cased Fortran name.  Note that no
  underscore is appended.
  
  
--- 4980,5006 ----
  ------------------------
  
  According the Fortran standard, valid Fortran names consist of a letter
! between ‘A’ to ‘Z’, ‘a’ to ‘z’, digits ‘0’, ‘1’ to ‘9’ and underscores
! (‘_’) with the restriction that names may only start with a letter.  As
! vendor extension, the dollar sign (‘$’) is additionally permitted with
! the option ‘-fdollar-ok’, but not as first character and only if the
  target system supports it.
  
     By default, the procedure name is the lower-cased Fortran name with
! an appended underscore (‘_’); using ‘-fno-underscoring’ no underscore is
! appended while ‘-fsecond-underscore’ appends two underscores.  Depending
  on the target system and the calling convention, the procedure might be
! additionally dressed; for instance, on 32bit Windows with ‘stdcall’, an
! at-sign ‘@’ followed by an integer number is appended.  For the changing
  the calling convention, see *note GNU Fortran Compiler Directives::.
  
     For common blocks, the same convention is used, i.e.  by default an
  underscore is appended to the lower-cased Fortran name.  Blank commons
! have the name ‘__BLNK__’.
  
     For procedures and variables declared in the specification space of a
! module, the name is formed by ‘__’, followed by the lower-cased module
! name, ‘_MOD_’, and the lower-cased Fortran name.  Note that no
  underscore is appended.
  
  
*************** File: gfortran.info,  Node: Argument pas
*** 5009,5028 ****
  6.4.2 Argument passing conventions
  ----------------------------------
  
! Subroutines do not return a value (matching C99's 'void') while
  functions either return a value as specified in the platform ABI or the
  result variable is passed as hidden argument to the function and no
  result is returned.  A hidden result variable is used when the result
! variable is an array or of type 'CHARACTER'.
  
     Arguments are passed according to the platform ABI. In particular,
  complex arguments might not be compatible to a struct with two real
  components for the real and imaginary part.  The argument passing
! matches the one of C99's '_Complex'.  Functions with scalar complex
  result variables return their value and do not use a by-reference
! argument.  Note that with the '-ff2c' option, the argument passing is
  modified and no longer completely matches the platform ABI. Some other
! Fortran compilers use 'f2c' semantic by default; this might cause
  problems with interoperablility.
  
     GNU Fortran passes most arguments by reference, i.e.  by passing a
--- 5009,5028 ----
  6.4.2 Argument passing conventions
  ----------------------------------
  
! Subroutines do not return a value (matching C99's ‘void’) while
  functions either return a value as specified in the platform ABI or the
  result variable is passed as hidden argument to the function and no
  result is returned.  A hidden result variable is used when the result
! variable is an array or of type ‘CHARACTER’.
  
     Arguments are passed according to the platform ABI. In particular,
  complex arguments might not be compatible to a struct with two real
  components for the real and imaginary part.  The argument passing
! matches the one of C99's ‘_Complex’.  Functions with scalar complex
  result variables return their value and do not use a by-reference
! argument.  Note that with the ‘-ff2c’ option, the argument passing is
  modified and no longer completely matches the platform ABI. Some other
! Fortran compilers use ‘f2c’ semantic by default; this might cause
  problems with interoperablility.
  
     GNU Fortran passes most arguments by reference, i.e.  by passing a
*************** pointer to the data.  Note that the comp
*** 5030,5062 ****
  variable into which the actual argument has been copied, if required
  semantically (copy-in/copy-out).
  
!    For arguments with 'ALLOCATABLE' and 'POINTER' attribute (including
  procedure pointers), a pointer to the pointer is passed such that the
  pointer address can be modified in the procedure.
  
!    For dummy arguments with the 'VALUE' attribute: Scalar arguments of
! the type 'INTEGER', 'LOGICAL', 'REAL' and 'COMPLEX' are passed by value
  according to the platform ABI. (As vendor extension and not recommended,
! using '%VAL()' in the call to a procedure has the same effect.)  For
! 'TYPE(C_PTR)' and procedure pointers, the pointer itself is passed such
  that it can be modified without affecting the caller.
  
!    For Boolean ('LOGICAL') arguments, please note that GCC expects only
! the integer value 0 and 1.  If a GNU Fortran 'LOGICAL' variable contains
  another integer value, the result is undefined.  As some other Fortran
! compilers use -1 for '.TRUE.', extra care has to be taken - such as
! passing the value as 'INTEGER'.  (The same value restriction also
  applies to other front ends of GCC, e.g.  to GCC's C99 compiler for
! '_Bool' or GCC's Ada compiler for 'Boolean'.)
  
!    For arguments of 'CHARACTER' type, the character length is passed as
  a hidden argument at the end of the argument list, except when the
! corresponding dummy argument is declared as 'TYPE(*)'.  For
  deferred-length strings, the value is passed by reference, otherwise by
! value.  The character length has the C type 'size_t' (or
! 'INTEGER(kind=C_SIZE_T)' in Fortran).  Note that this is different to
  older versions of the GNU Fortran compiler, where the type of the hidden
! character length argument was a C 'int'.  In order to retain
  compatibility with older versions, one can e.g.  for the following
  Fortran procedure
  
--- 5030,5062 ----
  variable into which the actual argument has been copied, if required
  semantically (copy-in/copy-out).
  
!    For arguments with ‘ALLOCATABLE’ and ‘POINTER’ attribute (including
  procedure pointers), a pointer to the pointer is passed such that the
  pointer address can be modified in the procedure.
  
!    For dummy arguments with the ‘VALUE’ attribute: Scalar arguments of
! the type ‘INTEGER’, ‘LOGICAL’, ‘REAL’ and ‘COMPLEX’ are passed by value
  according to the platform ABI. (As vendor extension and not recommended,
! using ‘%VAL()’ in the call to a procedure has the same effect.)  For
! ‘TYPE(C_PTR)’ and procedure pointers, the pointer itself is passed such
  that it can be modified without affecting the caller.
  
!    For Boolean (‘LOGICAL’) arguments, please note that GCC expects only
! the integer value 0 and 1.  If a GNU Fortran ‘LOGICAL’ variable contains
  another integer value, the result is undefined.  As some other Fortran
! compilers use -1 for ‘.TRUE.’, extra care has to be taken - such as
! passing the value as ‘INTEGER’.  (The same value restriction also
  applies to other front ends of GCC, e.g.  to GCC's C99 compiler for
! ‘_Bool’ or GCC's Ada compiler for ‘Boolean’.)
  
!    For arguments of ‘CHARACTER’ type, the character length is passed as
  a hidden argument at the end of the argument list, except when the
! corresponding dummy argument is declared as ‘TYPE(*)’.  For
  deferred-length strings, the value is passed by reference, otherwise by
! value.  The character length has the C type ‘size_t’ (or
! ‘INTEGER(kind=C_SIZE_T)’ in Fortran).  Note that this is different to
  older versions of the GNU Fortran compiler, where the type of the hidden
! character length argument was a C ‘int’.  In order to retain
  compatibility with older versions, one can e.g.  for the following
  Fortran procedure
  
*************** Fortran procedure
*** 5079,5115 ****
     In order to avoid such compiler-specific details, for new code it is
  instead recommended to use the ISO_C_BINDING feature.
  
!    Note with C binding, 'CHARACTER(len=1)' result variables are returned
  according to the platform ABI and no hidden length argument is used for
! dummy arguments; with 'VALUE', those variables are passed by value.
  
!    For 'OPTIONAL' dummy arguments, an absent argument is denoted by a
  NULL pointer, except for scalar dummy arguments of intrinsic type which
! have the 'VALUE' attribute.  For those, a hidden Boolean argument
! ('logical(kind=C_bool),value') is used to indicate whether the argument
  is present.
  
     Arguments which are assumed-shape, assumed-rank or deferred-rank
! arrays or, with '-fcoarray=lib', allocatable scalar coarrays use an
  array descriptor.  All other arrays pass the address of the first
! element of the array.  With '-fcoarray=lib', the token and the offset
  belonging to nonallocatable coarrays dummy arguments are passed as
  hidden argument along the character length hidden arguments.  The token
  is an opaque pointer identifying the coarray and the offset is a
! passed-by-value integer of kind 'C_PTRDIFF_T', denoting the byte offset
  between the base address of the coarray and the passed scalar or first
  element of the passed array.
  
     The arguments are passed in the following order
!    * Result variable, when the function result is passed by reference
!    * Character length of the function result, if it is a of type
!      'CHARACTER' and no C binding is used
!    * The arguments in the order in which they appear in the Fortran
       declaration
!    * The present status for optional arguments with value attribute,
       which are internally passed by value
!    * The character length and/or coarray token and offset for the first
!      argument which is a 'CHARACTER' or a nonallocatable coarray dummy
       argument, followed by the hidden arguments of the next dummy
       argument of such a type
  
--- 5079,5115 ----
     In order to avoid such compiler-specific details, for new code it is
  instead recommended to use the ISO_C_BINDING feature.
  
!    Note with C binding, ‘CHARACTER(len=1)’ result variables are returned
  according to the platform ABI and no hidden length argument is used for
! dummy arguments; with ‘VALUE’, those variables are passed by value.
  
!    For ‘OPTIONAL’ dummy arguments, an absent argument is denoted by a
  NULL pointer, except for scalar dummy arguments of intrinsic type which
! have the ‘VALUE’ attribute.  For those, a hidden Boolean argument
! (‘logical(kind=C_bool),value’) is used to indicate whether the argument
  is present.
  
     Arguments which are assumed-shape, assumed-rank or deferred-rank
! arrays or, with ‘-fcoarray=lib’, allocatable scalar coarrays use an
  array descriptor.  All other arrays pass the address of the first
! element of the array.  With ‘-fcoarray=lib’, the token and the offset
  belonging to nonallocatable coarrays dummy arguments are passed as
  hidden argument along the character length hidden arguments.  The token
  is an opaque pointer identifying the coarray and the offset is a
! passed-by-value integer of kind ‘C_PTRDIFF_T’, denoting the byte offset
  between the base address of the coarray and the passed scalar or first
  element of the passed array.
  
     The arguments are passed in the following order
!    • Result variable, when the function result is passed by reference
!    • Character length of the function result, if it is a of type
!      ‘CHARACTER’ and no C binding is used
!    • The arguments in the order in which they appear in the Fortran
       declaration
!    • The present status for optional arguments with value attribute,
       which are internally passed by value
!    • The character length and/or coarray token and offset for the first
!      argument which is a ‘CHARACTER’ or a nonallocatable coarray dummy
       argument, followed by the hidden arguments of the next dummy
       argument of such a type
  
*************** File: gfortran.info,  Node: Type and enu
*** 5141,5156 ****
  
  File: gfortran.info,  Node: caf_token_t,  Next: caf_register_t,  Up: Type and enum ABI Documentation
  
! 7.1.1 'caf_token_t'
  -------------------
  
! Typedef of type 'void *' on the compiler side.  Can be any data type on
  the library side.
  
  
  File: gfortran.info,  Node: caf_register_t,  Next: caf_deregister_t,  Prev: caf_token_t,  Up: Type and enum ABI Documentation
  
! 7.1.2 'caf_register_t'
  ----------------------
  
  Indicates which kind of coarray variable should be registered.
--- 5141,5156 ----
  
  File: gfortran.info,  Node: caf_token_t,  Next: caf_register_t,  Up: Type and enum ABI Documentation
  
! 7.1.1 ‘caf_token_t’
  -------------------
  
! Typedef of type ‘void *’ on the compiler side.  Can be any data type on
  the library side.
  
  
  File: gfortran.info,  Node: caf_register_t,  Next: caf_deregister_t,  Prev: caf_token_t,  Up: Type and enum ABI Documentation
  
! 7.1.2 ‘caf_register_t’
  ----------------------
  
  Indicates which kind of coarray variable should be registered.
*************** typedef enum caf_register_t {
*** 5168,5188 ****
  }
  caf_register_t;
  
!    The values 'CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY' and
! 'CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY' are for allocatable components
  in derived type coarrays only.  The first one sets up the token without
  allocating memory for allocatable component.  The latter one only
  allocates the memory for an allocatable component in a derived type
  coarray.  The token needs to be setup previously by the REGISTER_ONLY.
  This allows to have allocatable components un-allocated on some images.
  The status whether an allocatable component is allocated on a remote
! image can be queried by '_caf_is_present' which used internally by the
! 'ALLOCATED' intrinsic.
  
  
  File: gfortran.info,  Node: caf_deregister_t,  Next: caf_reference_t,  Prev: caf_register_t,  Up: Type and enum ABI Documentation
  
! 7.1.3 'caf_deregister_t'
  ------------------------
  
  typedef enum caf_deregister_t {
--- 5168,5188 ----
  }
  caf_register_t;
  
!    The values ‘CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY’ and
! ‘CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY’ are for allocatable components
  in derived type coarrays only.  The first one sets up the token without
  allocating memory for allocatable component.  The latter one only
  allocates the memory for an allocatable component in a derived type
  coarray.  The token needs to be setup previously by the REGISTER_ONLY.
  This allows to have allocatable components un-allocated on some images.
  The status whether an allocatable component is allocated on a remote
! image can be queried by ‘_caf_is_present’ which used internally by the
! ‘ALLOCATED’ intrinsic.
  
  
  File: gfortran.info,  Node: caf_deregister_t,  Next: caf_reference_t,  Prev: caf_register_t,  Up: Type and enum ABI Documentation
  
! 7.1.3 ‘caf_deregister_t’
  ------------------------
  
  typedef enum caf_deregister_t {
*************** typedef enum caf_deregister_t {
*** 5192,5211 ****
  caf_deregister_t;
  
     Allows to specifiy the type of deregistration of a coarray object.
! The 'CAF_DEREGTYPE_COARRAY_DEALLOCATE_ONLY' flag is only allowed for
  allocatable components in derived type coarrays.
  
  
  File: gfortran.info,  Node: caf_reference_t,  Next: caf_team_t,  Prev: caf_deregister_t,  Up: Type and enum ABI Documentation
  
! 7.1.4 'caf_reference_t'
  -----------------------
  
  The structure used for implementing arbitrary reference chains.  A
! 'CAF_REFERENCE_T' allows to specify a component reference or any kind of
  array reference of any rank supported by gfortran.  For array references
  all kinds as known by the compiler/Fortran standard are supported
! indicated by a 'MODE'.
  
  typedef enum caf_ref_type_t {
    /* Reference a component of a derived type, either regular one or an
--- 5192,5211 ----
  caf_deregister_t;
  
     Allows to specifiy the type of deregistration of a coarray object.
! The ‘CAF_DEREGTYPE_COARRAY_DEALLOCATE_ONLY’ flag is only allowed for
  allocatable components in derived type coarrays.
  
  
  File: gfortran.info,  Node: caf_reference_t,  Next: caf_team_t,  Prev: caf_deregister_t,  Up: Type and enum ABI Documentation
  
! 7.1.4 ‘caf_reference_t’
  -----------------------
  
  The structure used for implementing arbitrary reference chains.  A
! ‘CAF_REFERENCE_T’ allows to specify a component reference or any kind of
  array reference of any rank supported by gfortran.  For array references
  all kinds as known by the compiler/Fortran standard are supported
! indicated by a ‘MODE’.
  
  typedef enum caf_ref_type_t {
    /* Reference a component of a derived type, either regular one or an
*************** typedef struct caf_reference_t {
*** 5287,5310 ****
  } caf_reference_t;
  
     The references make up a single linked list of reference operations.
! The 'NEXT' member links to the next reference or NULL to indicate the
  end of the chain.  Component and array refs can be arbitrarily mixed as
  long as they comply to the Fortran standard.
  
!    _NOTES_ The member 'STATIC_ARRAY_TYPE' is used only when the 'TYPE'
! is 'CAF_REF_STATIC_ARRAY'.  The member gives the type of the data
  referenced.  Because no array descriptor is available for a
  descriptor-less array and type conversion still needs to take place the
  type is transported here.
  
!    At the moment 'CAF_ARR_REF_VECTOR' is not implemented in the front
  end for descriptor-less arrays.  The library caf_single has untested
  support for it.
  
  
  File: gfortran.info,  Node: caf_team_t,  Prev: caf_reference_t,  Up: Type and enum ABI Documentation
  
! 7.1.5 'caf_team_t'
  ------------------
  
  Opaque pointer to represent a team-handle.  This type is a stand-in for
--- 5287,5310 ----
  } caf_reference_t;
  
     The references make up a single linked list of reference operations.
! The ‘NEXT’ member links to the next reference or NULL to indicate the
  end of the chain.  Component and array refs can be arbitrarily mixed as
  long as they comply to the Fortran standard.
  
!    _NOTES_ The member ‘STATIC_ARRAY_TYPE’ is used only when the ‘TYPE’
! is ‘CAF_REF_STATIC_ARRAY’.  The member gives the type of the data
  referenced.  Because no array descriptor is available for a
  descriptor-less array and type conversion still needs to take place the
  type is transported here.
  
!    At the moment ‘CAF_ARR_REF_VECTOR’ is not implemented in the front
  end for descriptor-less arrays.  The library caf_single has untested
  support for it.
  
  
  File: gfortran.info,  Node: caf_team_t,  Prev: caf_reference_t,  Up: Type and enum ABI Documentation
  
! 7.1.5 ‘caf_team_t’
  ------------------
  
  Opaque pointer to represent a team-handle.  This type is a stand-in for
*************** File: gfortran.info,  Node: Function ABI
*** 5359,5383 ****
  
  File: gfortran.info,  Node: _gfortran_caf_init,  Next: _gfortran_caf_finish,  Up: Function ABI Documentation
  
! 7.2.1 '_gfortran_caf_init' -- Initialiation function
  ----------------------------------------------------
  
  _Description_:
       This function is called at startup of the program before the
       Fortran main program, if the latter has been compiled with
!      '-fcoarray=lib'.  It takes as arguments the command-line arguments
!      of the program.  It is permitted to pass two 'NULL' pointers as
!      argument; if non-'NULL', the library is permitted to modify the
       arguments.
  
  _Syntax_:
!      'void _gfortran_caf_init (int *argc, char ***argv)'
  
  _Arguments_:
       ARGC        intent(inout) An integer pointer with the number
!                  of arguments passed to the program or 'NULL'.
       ARGV        intent(inout) A pointer to an array of strings
!                  with the command-line arguments or 'NULL'.
  
  _NOTES_
       The function is modelled after the initialization function of the
--- 5359,5383 ----
  
  File: gfortran.info,  Node: _gfortran_caf_init,  Next: _gfortran_caf_finish,  Up: Function ABI Documentation
  
! 7.2.1 ‘_gfortran_caf_init’ -- Initialiation function
  ----------------------------------------------------
  
  _Description_:
       This function is called at startup of the program before the
       Fortran main program, if the latter has been compiled with
!      ‘-fcoarray=lib’.  It takes as arguments the command-line arguments
!      of the program.  It is permitted to pass two ‘NULL’ pointers as
!      argument; if non-‘NULL’, the library is permitted to modify the
       arguments.
  
  _Syntax_:
!      ‘void _gfortran_caf_init (int *argc, char ***argv)’
  
  _Arguments_:
       ARGC        intent(inout) An integer pointer with the number
!                  of arguments passed to the program or ‘NULL’.
       ARGV        intent(inout) A pointer to an array of strings
!                  with the command-line arguments or ‘NULL’.
  
  _NOTES_
       The function is modelled after the initialization function of the
*************** _NOTES_
*** 5391,5405 ****
  
  File: gfortran.info,  Node: _gfortran_caf_finish,  Next: _gfortran_caf_this_image,  Prev: _gfortran_caf_init,  Up: Function ABI Documentation
  
! 7.2.2 '_gfortran_caf_finish' -- Finalization function
  -----------------------------------------------------
  
  _Description_:
       This function is called at the end of the Fortran main program, if
!      it has been compiled with the '-fcoarray=lib' option.
  
  _Syntax_:
!      'void _gfortran_caf_finish (void)'
  
  _NOTES_
       For non-Fortran programs, it is recommended to call the function at
--- 5391,5405 ----
  
  File: gfortran.info,  Node: _gfortran_caf_finish,  Next: _gfortran_caf_this_image,  Prev: _gfortran_caf_init,  Up: Function ABI Documentation
  
! 7.2.2 ‘_gfortran_caf_finish’ -- Finalization function
  -----------------------------------------------------
  
  _Description_:
       This function is called at the end of the Fortran main program, if
!      it has been compiled with the ‘-fcoarray=lib’ option.
  
  _Syntax_:
!      ‘void _gfortran_caf_finish (void)’
  
  _NOTES_
       For non-Fortran programs, it is recommended to call the function at
*************** _NOTES_
*** 5413,5419 ****
  
  File: gfortran.info,  Node: _gfortran_caf_this_image,  Next: _gfortran_caf_num_images,  Prev: _gfortran_caf_finish,  Up: Function ABI Documentation
  
! 7.2.3 '_gfortran_caf_this_image' -- Querying the image number
  -------------------------------------------------------------
  
  _Description_:
--- 5413,5419 ----
  
  File: gfortran.info,  Node: _gfortran_caf_this_image,  Next: _gfortran_caf_num_images,  Prev: _gfortran_caf_finish,  Up: Function ABI Documentation
  
! 7.2.3 ‘_gfortran_caf_this_image’ -- Querying the image number
  -------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5421,5441 ****
       number.
  
  _Syntax_:
!      'int _gfortran_caf_this_image (int distance)'
  
  _Arguments_:
!      DISTANCE    As specified for the 'this_image' intrinsic in
                   TS18508.  Shall be a non-negative number.
  
  _NOTES_
!      If the Fortran intrinsic 'this_image' is invoked without an
       argument, which is the only permitted form in Fortran 2008, GCC
!      passes '0' as first argument.
  
  
  File: gfortran.info,  Node: _gfortran_caf_num_images,  Next: _gfortran_caf_image_status,  Prev: _gfortran_caf_this_image,  Up: Function ABI Documentation
  
! 7.2.4 '_gfortran_caf_num_images' -- Querying the maximal number of images
  -------------------------------------------------------------------------
  
  _Description_:
--- 5421,5441 ----
       number.
  
  _Syntax_:
!      ‘int _gfortran_caf_this_image (int distance)’
  
  _Arguments_:
!      DISTANCE    As specified for the ‘this_image’ intrinsic in
                   TS18508.  Shall be a non-negative number.
  
  _NOTES_
!      If the Fortran intrinsic ‘this_image’ is invoked without an
       argument, which is the only permitted form in Fortran 2008, GCC
!      passes ‘0’ as first argument.
  
  
  File: gfortran.info,  Node: _gfortran_caf_num_images,  Next: _gfortran_caf_image_status,  Prev: _gfortran_caf_this_image,  Up: Function ABI Documentation
  
! 7.2.4 ‘_gfortran_caf_num_images’ -- Querying the maximal number of images
  -------------------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5447,5453 ****
       returns the number of failed images.
  
  _Syntax_:
!      'int _gfortran_caf_num_images(int distance, int failed)'
  
  _Arguments_:
       DISTANCE    the distance from this image to the ancestor.
--- 5447,5453 ----
       returns the number of failed images.
  
  _Syntax_:
!      ‘int _gfortran_caf_num_images(int distance, int failed)’
  
  _Arguments_:
       DISTANCE    the distance from this image to the ancestor.
*************** _Arguments_:
*** 5456,5480 ****
  
  _NOTES_
       This function follows TS18508.  If the num_image intrinsic has no
!      arguments, then the compiler passes 'distance=0' and 'failed=-1' to
       the function.
  
  
  File: gfortran.info,  Node: _gfortran_caf_image_status,  Next: _gfortran_caf_failed_images,  Prev: _gfortran_caf_num_images,  Up: Function ABI Documentation
  
! 7.2.5 '_gfortran_caf_image_status' -- Query the status of an image
  ------------------------------------------------------------------
  
  _Description_:
       Get the status of the image given by the id IMAGE of the team given
       by TEAM.  Valid results are zero, for image is ok,
!      'STAT_STOPPED_IMAGE' from the ISO_FORTRAN_ENV module to indicate
!      that the image has been stopped and 'STAT_FAILED_IMAGE' also from
!      ISO_FORTRAN_ENV to indicate that the image has executed a 'FAIL
!      IMAGE' statement.
  
  _Syntax_:
!      'int _gfortran_caf_image_status (int image, caf_team_t * team)'
  
  _Arguments_:
       IMAGE       the positive scalar id of the image in the
--- 5456,5480 ----
  
  _NOTES_
       This function follows TS18508.  If the num_image intrinsic has no
!      arguments, then the compiler passes ‘distance=0’ and ‘failed=-1’ to
       the function.
  
  
  File: gfortran.info,  Node: _gfortran_caf_image_status,  Next: _gfortran_caf_failed_images,  Prev: _gfortran_caf_num_images,  Up: Function ABI Documentation
  
! 7.2.5 ‘_gfortran_caf_image_status’ -- Query the status of an image
  ------------------------------------------------------------------
  
  _Description_:
       Get the status of the image given by the id IMAGE of the team given
       by TEAM.  Valid results are zero, for image is ok,
!      ‘STAT_STOPPED_IMAGE’ from the ISO_FORTRAN_ENV module to indicate
!      that the image has been stopped and ‘STAT_FAILED_IMAGE’ also from
!      ISO_FORTRAN_ENV to indicate that the image has executed a ‘FAIL
!      IMAGE’ statement.
  
  _Syntax_:
!      ‘int _gfortran_caf_image_status (int image, caf_team_t * team)’
  
  _Arguments_:
       IMAGE       the positive scalar id of the image in the
*************** _NOTES_
*** 5490,5496 ****
  
  File: gfortran.info,  Node: _gfortran_caf_failed_images,  Next: _gfortran_caf_stopped_images,  Prev: _gfortran_caf_image_status,  Up: Function ABI Documentation
  
! 7.2.6 '_gfortran_caf_failed_images' -- Get an array of the indexes of the failed images
  ---------------------------------------------------------------------------------------
  
  _Description_:
--- 5490,5496 ----
  
  File: gfortran.info,  Node: _gfortran_caf_failed_images,  Next: _gfortran_caf_stopped_images,  Prev: _gfortran_caf_image_status,  Up: Function ABI Documentation
  
! 7.2.6 ‘_gfortran_caf_failed_images’ -- Get an array of the indexes of the failed images
  ---------------------------------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5502,5508 ****
       images have failed.
  
  _Syntax_:
!      'int _gfortran_caf_failed_images (caf_team_t * team, int * kind)'
  
  _Arguments_:
       TEAM        optional; team on the which the inquiry is to be
--- 5502,5508 ----
       images have failed.
  
  _Syntax_:
!      ‘int _gfortran_caf_failed_images (caf_team_t * team, int * kind)’
  
  _Arguments_:
       TEAM        optional; team on the which the inquiry is to be
*************** _NOTES_
*** 5518,5524 ****
  
  File: gfortran.info,  Node: _gfortran_caf_stopped_images,  Next: _gfortran_caf_register,  Prev: _gfortran_caf_failed_images,  Up: Function ABI Documentation
  
! 7.2.7 '_gfortran_caf_stopped_images' -- Get an array of the indexes of the stopped images
  -----------------------------------------------------------------------------------------
  
  _Description_:
--- 5518,5524 ----
  
  File: gfortran.info,  Node: _gfortran_caf_stopped_images,  Next: _gfortran_caf_register,  Prev: _gfortran_caf_failed_images,  Up: Function ABI Documentation
  
! 7.2.7 ‘_gfortran_caf_stopped_images’ -- Get an array of the indexes of the stopped images
  -----------------------------------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5530,5536 ****
       when no images have failed.
  
  _Syntax_:
!      'int _gfortran_caf_stopped_images (caf_team_t * team, int * kind)'
  
  _Arguments_:
       TEAM        optional; team on the which the inquiry is to be
--- 5530,5536 ----
       when no images have failed.
  
  _Syntax_:
!      ‘int _gfortran_caf_stopped_images (caf_team_t * team, int * kind)’
  
  _Arguments_:
       TEAM        optional; team on the which the inquiry is to be
*************** _NOTES_
*** 5546,5590 ****
  
  File: gfortran.info,  Node: _gfortran_caf_register,  Next: _gfortran_caf_deregister,  Prev: _gfortran_caf_stopped_images,  Up: Function ABI Documentation
  
! 7.2.8 '_gfortran_caf_register' -- Registering coarrays
  ------------------------------------------------------
  
  _Description_:
       Registers memory for a coarray and creates a token to identify the
!      coarray.  The routine is called for both coarrays with 'SAVE'
!      attribute and using an explicit 'ALLOCATE' statement.  If an error
!      occurs and STAT is a 'NULL' pointer, the function shall abort with
       printing an error message and starting the error termination.  If
       no error occurs and STAT is present, it shall be set to zero.
!      Otherwise, it shall be set to a positive value and, if not-'NULL',
       ERRMSG shall be set to a string describing the failure.  The
!      routine shall register the memory provided in the 'DATA'-component
!      of the array descriptor DESC, when that component is non-'NULL',
       else it shall allocate sufficient memory and provide a pointer to
!      it in the 'DATA'-component of DESC.  The array descriptor has rank
       zero, when a scalar object is to be registered and the array
       descriptor may be invalid after the call to
!      '_gfortran_caf_register'.  When an array is to be allocated the
       descriptor persists.
  
!      For 'CAF_REGTYPE_COARRAY_STATIC' and 'CAF_REGTYPE_COARRAY_ALLOC',
       the passed size is the byte size requested.  For
!      'CAF_REGTYPE_LOCK_STATIC', 'CAF_REGTYPE_LOCK_ALLOC' and
!      'CAF_REGTYPE_CRITICAL' it is the array size or one for a scalar.
  
!      When 'CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY' is used, then only a
       token for an allocatable or pointer component is created.  The
!      'SIZE' parameter is not used then.  On the contrary when
!      'CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY' is specified, then the
       TOKEN needs to be registered by a previous call with regtype
!      'CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY' and either the memory
       specified in the DESC's data-ptr is registered or allocate when the
!      data-ptr is 'NULL'.
  
  _Syntax_:
!      'void caf_register (size_t size, caf_register_t type, caf_token_t
       *token, gfc_descriptor_t *desc, int *stat, char *errmsg, size_t
!      errmsg_len)'
  
  _Arguments_:
       SIZE        For normal coarrays, the byte size of the
--- 5546,5590 ----
  
  File: gfortran.info,  Node: _gfortran_caf_register,  Next: _gfortran_caf_deregister,  Prev: _gfortran_caf_stopped_images,  Up: Function ABI Documentation
  
! 7.2.8 ‘_gfortran_caf_register’ -- Registering coarrays
  ------------------------------------------------------
  
  _Description_:
       Registers memory for a coarray and creates a token to identify the
!      coarray.  The routine is called for both coarrays with ‘SAVE’
!      attribute and using an explicit ‘ALLOCATE’ statement.  If an error
!      occurs and STAT is a ‘NULL’ pointer, the function shall abort with
       printing an error message and starting the error termination.  If
       no error occurs and STAT is present, it shall be set to zero.
!      Otherwise, it shall be set to a positive value and, if not-‘NULL’,
       ERRMSG shall be set to a string describing the failure.  The
!      routine shall register the memory provided in the ‘DATA’-component
!      of the array descriptor DESC, when that component is non-‘NULL’,
       else it shall allocate sufficient memory and provide a pointer to
!      it in the ‘DATA’-component of DESC.  The array descriptor has rank
       zero, when a scalar object is to be registered and the array
       descriptor may be invalid after the call to
!      ‘_gfortran_caf_register’.  When an array is to be allocated the
       descriptor persists.
  
!      For ‘CAF_REGTYPE_COARRAY_STATIC’ and ‘CAF_REGTYPE_COARRAY_ALLOC’,
       the passed size is the byte size requested.  For
!      ‘CAF_REGTYPE_LOCK_STATIC’, ‘CAF_REGTYPE_LOCK_ALLOC’ and
!      ‘CAF_REGTYPE_CRITICAL’ it is the array size or one for a scalar.
  
!      When ‘CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY’ is used, then only a
       token for an allocatable or pointer component is created.  The
!      ‘SIZE’ parameter is not used then.  On the contrary when
!      ‘CAF_REGTYPE_COARRAY_ALLOC_ALLOCATE_ONLY’ is specified, then the
       TOKEN needs to be registered by a previous call with regtype
!      ‘CAF_REGTYPE_COARRAY_ALLOC_REGISTER_ONLY’ and either the memory
       specified in the DESC's data-ptr is registered or allocate when the
!      data-ptr is ‘NULL’.
  
  _Syntax_:
!      ‘void caf_register (size_t size, caf_register_t type, caf_token_t
       *token, gfc_descriptor_t *desc, int *stat, char *errmsg, size_t
!      errmsg_len)’
  
  _Arguments_:
       SIZE        For normal coarrays, the byte size of the
*************** _Arguments_:
*** 5595,5603 ****
                   coarray.
       DESC        intent(inout) The (pseudo) array descriptor.
       STAT        intent(out) For allocatable coarrays, stores the
!                  STAT=; may be 'NULL'
       ERRMSG      intent(out) When an error occurs, this will be
!                  set to an error message; may be 'NULL'
       ERRMSG_LEN  the buffer size of errmsg.
  
  _NOTES_
--- 5595,5603 ----
                   coarray.
       DESC        intent(inout) The (pseudo) array descriptor.
       STAT        intent(out) For allocatable coarrays, stores the
!                  STAT=; may be ‘NULL’
       ERRMSG      intent(out) When an error occurs, this will be
!                  set to an error message; may be ‘NULL’
       ERRMSG_LEN  the buffer size of errmsg.
  
  _NOTES_
*************** _NOTES_
*** 5616,5622 ****
       allocation status.  Note that for critical blocks, the locking is
       only required on one image; in the locking statement, the processor
       shall always pass an image index of one for critical-block lock
!      variables ('CAF_REGTYPE_CRITICAL').  For lock types and
       critical-block variables, the initial value shall be unlocked (or,
       respectively, not in critical section) such as the value false; for
       event types, the initial state should be no event, e.g.  zero.
--- 5616,5622 ----
       allocation status.  Note that for critical blocks, the locking is
       only required on one image; in the locking statement, the processor
       shall always pass an image index of one for critical-block lock
!      variables (‘CAF_REGTYPE_CRITICAL’).  For lock types and
       critical-block variables, the initial value shall be unlocked (or,
       respectively, not in critical section) such as the value false; for
       event types, the initial state should be no event, e.g.  zero.
*************** _NOTES_
*** 5624,5630 ****
  
  File: gfortran.info,  Node: _gfortran_caf_deregister,  Next: _gfortran_caf_is_present,  Prev: _gfortran_caf_register,  Up: Function ABI Documentation
  
! 7.2.9 '_gfortran_caf_deregister' -- Deregistering coarrays
  ----------------------------------------------------------
  
  _Description_:
--- 5624,5630 ----
  
  File: gfortran.info,  Node: _gfortran_caf_deregister,  Next: _gfortran_caf_is_present,  Prev: _gfortran_caf_register,  Up: Function ABI Documentation
  
! 7.2.9 ‘_gfortran_caf_deregister’ -- Deregistering coarrays
  ----------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5633,5648 ****
       case of an error, this function shall fail with an error message,
       unless the STAT variable is not null.  The library is only expected
       to free memory it allocated itself during a call to
!      '_gfortran_caf_register'.
  
  _Syntax_:
!      'void caf_deregister (caf_token_t *token, caf_deregister_t type,
!      int *stat, char *errmsg, size_t errmsg_len)'
  
  _Arguments_:
       TOKEN       the token to free.
       TYPE        the type of action to take for the coarray.  A
!                  'CAF_DEREGTYPE_COARRAY_DEALLOCATE_ONLY' is
                   allowed only for allocatable or pointer
                   components of derived type coarrays.  The action
                   only deallocates the local memory without
--- 5633,5648 ----
       case of an error, this function shall fail with an error message,
       unless the STAT variable is not null.  The library is only expected
       to free memory it allocated itself during a call to
!      ‘_gfortran_caf_register’.
  
  _Syntax_:
!      ‘void caf_deregister (caf_token_t *token, caf_deregister_t type,
!      int *stat, char *errmsg, size_t errmsg_len)’
  
  _Arguments_:
       TOKEN       the token to free.
       TYPE        the type of action to take for the coarray.  A
!                  ‘CAF_DEREGTYPE_COARRAY_DEALLOCATE_ONLY’ is
                   allowed only for allocatable or pointer
                   components of derived type coarrays.  The action
                   only deallocates the local memory without
*************** _NOTES_
*** 5660,5666 ****
  
  File: gfortran.info,  Node: _gfortran_caf_is_present,  Next: _gfortran_caf_send,  Prev: _gfortran_caf_deregister,  Up: Function ABI Documentation
  
! 7.2.10 '_gfortran_caf_is_present' -- Query whether an allocatable or pointer component in a derived type coarray is allocated
  -----------------------------------------------------------------------------------------------------------------------------
  
  _Description_:
--- 5660,5666 ----
  
  File: gfortran.info,  Node: _gfortran_caf_is_present,  Next: _gfortran_caf_send,  Prev: _gfortran_caf_deregister,  Up: Function ABI Documentation
  
! 7.2.10 ‘_gfortran_caf_is_present’ -- Query whether an allocatable or pointer component in a derived type coarray is allocated
  -----------------------------------------------------------------------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5668,5675 ****
       in a derived type coarray is allocated on a remote image.
  
  _Syntax_:
!      'void _gfortran_caf_is_present (caf_token_t token, int image_index,
!      gfc_reference_t *ref)'
  
  _Arguments_:
       TOKEN       An opaque pointer identifying the coarray.
--- 5668,5675 ----
       in a derived type coarray is allocated on a remote image.
  
  _Syntax_:
!      ‘void _gfortran_caf_is_present (caf_token_t token, int image_index,
!      gfc_reference_t *ref)’
  
  _Arguments_:
       TOKEN       An opaque pointer identifying the coarray.
*************** _Arguments_:
*** 5683,5689 ****
  
  File: gfortran.info,  Node: _gfortran_caf_send,  Next: _gfortran_caf_get,  Prev: _gfortran_caf_is_present,  Up: Function ABI Documentation
  
! 7.2.11 '_gfortran_caf_send' -- Sending data from a local image to a remote image
  --------------------------------------------------------------------------------
  
  _Description_:
--- 5683,5689 ----
  
  File: gfortran.info,  Node: _gfortran_caf_send,  Next: _gfortran_caf_get,  Prev: _gfortran_caf_is_present,  Up: Function ABI Documentation
  
! 7.2.11 ‘_gfortran_caf_send’ -- Sending data from a local image to a remote image
  --------------------------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5691,5700 ****
       local to a remote image identified by the image_index.
  
  _Syntax_:
!      'void _gfortran_caf_send (caf_token_t token, size_t offset, int
       image_index, gfc_descriptor_t *dest, caf_vector_t *dst_vector,
       gfc_descriptor_t *src, int dst_kind, int src_kind, bool
!      may_require_tmp, int *stat)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 5691,5700 ----
       local to a remote image identified by the image_index.
  
  _Syntax_:
!      ‘void _gfortran_caf_send (caf_token_t token, size_t offset, int
       image_index, gfc_descriptor_t *dest, caf_vector_t *dst_vector,
       gfc_descriptor_t *src, int dst_kind, int src_kind, bool
!      may_require_tmp, int *stat)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _Arguments_:
*** 5705,5711 ****
       IMAGE_INDEX intent(in) The ID of the remote image; must be a
                   positive number.
       DEST        intent(in) Array descriptor for the remote image
!                  for the bounds and the size.  The 'base_addr'
                   shall not be accessed.
       DST_VECTOR  intent(in) If not NULL, it contains the vector
                   subscript of the destination array; the values
--- 5705,5711 ----
       IMAGE_INDEX intent(in) The ID of the remote image; must be a
                   positive number.
       DEST        intent(in) Array descriptor for the remote image
!                  for the bounds and the size.  The ‘base_addr’
                   shall not be accessed.
       DST_VECTOR  intent(in) If not NULL, it contains the vector
                   subscript of the destination array; the values
*************** _Arguments_:
*** 5715,5727 ****
                   to be transferred to the remote image
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is 'false' when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is 'true'.
       STAT        intent(out) when non-NULL give the result of the
                   operation, i.e., zero on success and non-zero on
                   error.  When NULL and an error occurs, then an
--- 5715,5727 ----
                   to be transferred to the remote image
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is ‘false’ when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is ‘true’.
       STAT        intent(out) when non-NULL give the result of the
                   operation, i.e., zero on success and non-zero on
                   error.  When NULL and an error occurs, then an
*************** _NOTES_
*** 5732,5742 ****
       It is permitted to have IMAGE_INDEX equal the current image; the
       memory of the send-to and the send-from might (partially) overlap
       in that case.  The implementation has to take care that it handles
!      this case, e.g.  using 'memmove' which handles (partially)
       overlapping memory.  If MAY_REQUIRE_TMP is true, the library might
       additionally create a temporary variable, unless additional checks
       show that this is not required (e.g.  because walking backward is
!      possible or because both arrays are contiguous and 'memmove' takes
       care of overlap issues).
  
       Note that the assignment of a scalar to an array is permitted.  In
--- 5732,5742 ----
       It is permitted to have IMAGE_INDEX equal the current image; the
       memory of the send-to and the send-from might (partially) overlap
       in that case.  The implementation has to take care that it handles
!      this case, e.g.  using ‘memmove’ which handles (partially)
       overlapping memory.  If MAY_REQUIRE_TMP is true, the library might
       additionally create a temporary variable, unless additional checks
       show that this is not required (e.g.  because walking backward is
!      possible or because both arrays are contiguous and ‘memmove’ takes
       care of overlap issues).
  
       Note that the assignment of a scalar to an array is permitted.  In
*************** _NOTES_
*** 5746,5752 ****
  
  File: gfortran.info,  Node: _gfortran_caf_get,  Next: _gfortran_caf_sendget,  Prev: _gfortran_caf_send,  Up: Function ABI Documentation
  
! 7.2.12 '_gfortran_caf_get' -- Getting data from a remote image
  --------------------------------------------------------------
  
  _Description_:
--- 5746,5752 ----
  
  File: gfortran.info,  Node: _gfortran_caf_get,  Next: _gfortran_caf_sendget,  Prev: _gfortran_caf_send,  Up: Function ABI Documentation
  
! 7.2.12 ‘_gfortran_caf_get’ -- Getting data from a remote image
  --------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5754,5763 ****
       image identified by the image_index.
  
  _Syntax_:
!      'void _gfortran_caf_get (caf_token_t token, size_t offset, int
       image_index, gfc_descriptor_t *src, caf_vector_t *src_vector,
       gfc_descriptor_t *dest, int src_kind, int dst_kind, bool
!      may_require_tmp, int *stat)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 5754,5763 ----
       image identified by the image_index.
  
  _Syntax_:
!      ‘void _gfortran_caf_get (caf_token_t token, size_t offset, int
       image_index, gfc_descriptor_t *src, caf_vector_t *src_vector,
       gfc_descriptor_t *dest, int src_kind, int dst_kind, bool
!      may_require_tmp, int *stat)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _Arguments_:
*** 5771,5777 ****
                   to store the data retrieved from the remote
                   image
       SRC         intent(in) Array descriptor for the remote image
!                  for the bounds and the size.  The 'base_addr'
                   shall not be accessed.
       SRC_VECTOR  intent(in) If not NULL, it contains the vector
                   subscript of the source array; the values are
--- 5771,5777 ----
                   to store the data retrieved from the remote
                   image
       SRC         intent(in) Array descriptor for the remote image
!                  for the bounds and the size.  The ‘base_addr’
                   shall not be accessed.
       SRC_VECTOR  intent(in) If not NULL, it contains the vector
                   subscript of the source array; the values are
*************** _Arguments_:
*** 5779,5791 ****
                   argument.
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is 'false' when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is 'true'.
       STAT        intent(out) When non-NULL give the result of the
                   operation, i.e., zero on success and non-zero on
                   error.  When NULL and an error occurs, then an
--- 5779,5791 ----
                   argument.
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is ‘false’ when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is ‘true’.
       STAT        intent(out) When non-NULL give the result of the
                   operation, i.e., zero on success and non-zero on
                   error.  When NULL and an error occurs, then an
*************** _NOTES_
*** 5796,5806 ****
       It is permitted to have IMAGE_INDEX equal the current image; the
       memory of the send-to and the send-from might (partially) overlap
       in that case.  The implementation has to take care that it handles
!      this case, e.g.  using 'memmove' which handles (partially)
       overlapping memory.  If MAY_REQUIRE_TMP is true, the library might
       additionally create a temporary variable, unless additional checks
       show that this is not required (e.g.  because walking backward is
!      possible or because both arrays are contiguous and 'memmove' takes
       care of overlap issues).
  
       Note that the library has to handle numeric-type conversion and for
--- 5796,5806 ----
       It is permitted to have IMAGE_INDEX equal the current image; the
       memory of the send-to and the send-from might (partially) overlap
       in that case.  The implementation has to take care that it handles
!      this case, e.g.  using ‘memmove’ which handles (partially)
       overlapping memory.  If MAY_REQUIRE_TMP is true, the library might
       additionally create a temporary variable, unless additional checks
       show that this is not required (e.g.  because walking backward is
!      possible or because both arrays are contiguous and ‘memmove’ takes
       care of overlap issues).
  
       Note that the library has to handle numeric-type conversion and for
*************** _NOTES_
*** 5809,5815 ****
  
  File: gfortran.info,  Node: _gfortran_caf_sendget,  Next: _gfortran_caf_send_by_ref,  Prev: _gfortran_caf_get,  Up: Function ABI Documentation
  
! 7.2.13 '_gfortran_caf_sendget' -- Sending data between remote images
  --------------------------------------------------------------------
  
  _Description_:
--- 5809,5815 ----
  
  File: gfortran.info,  Node: _gfortran_caf_sendget,  Next: _gfortran_caf_send_by_ref,  Prev: _gfortran_caf_get,  Up: Function ABI Documentation
  
! 7.2.13 ‘_gfortran_caf_sendget’ -- Sending data between remote images
  --------------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5818,5829 ****
       identified by the DST_IMAGE_INDEX.
  
  _Syntax_:
!      'void _gfortran_caf_sendget (caf_token_t dst_token, size_t
       dst_offset, int dst_image_index, gfc_descriptor_t *dest,
       caf_vector_t *dst_vector, caf_token_t src_token, size_t src_offset,
       int src_image_index, gfc_descriptor_t *src, caf_vector_t
       *src_vector, int dst_kind, int src_kind, bool may_require_tmp, int
!      *stat)'
  
  _Arguments_:
       DST_TOKEN   intent(in) An opaque pointer identifying the
--- 5818,5829 ----
       identified by the DST_IMAGE_INDEX.
  
  _Syntax_:
!      ‘void _gfortran_caf_sendget (caf_token_t dst_token, size_t
       dst_offset, int dst_image_index, gfc_descriptor_t *dest,
       caf_vector_t *dst_vector, caf_token_t src_token, size_t src_offset,
       int src_image_index, gfc_descriptor_t *src, caf_vector_t
       *src_vector, int dst_kind, int src_kind, bool may_require_tmp, int
!      *stat)’
  
  _Arguments_:
       DST_TOKEN   intent(in) An opaque pointer identifying the
*************** _Arguments_:
*** 5835,5841 ****
                   image; must be a positive number.
       DEST        intent(in) Array descriptor for the destination
                   remote image for the bounds and the size.  The
!                  'base_addr' shall not be accessed.
       DST_VECTOR  intent(int) If not NULL, it contains the vector
                   subscript of the destination array; the values
                   are relative to the dimension triplet of the
--- 5835,5841 ----
                   image; must be a positive number.
       DEST        intent(in) Array descriptor for the destination
                   remote image for the bounds and the size.  The
!                  ‘base_addr’ shall not be accessed.
       DST_VECTOR  intent(int) If not NULL, it contains the vector
                   subscript of the destination array; the values
                   are relative to the dimension triplet of the
*************** _Arguments_:
*** 5853,5865 ****
                   to be transferred to the remote image
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is 'false' when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is 'true'.
       STAT        intent(out) when non-NULL give the result of the
                   operation, i.e., zero on success and non-zero on
                   error.  When NULL and an error occurs, then an
--- 5853,5865 ----
                   to be transferred to the remote image
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is ‘false’ when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is ‘true’.
       STAT        intent(out) when non-NULL give the result of the
                   operation, i.e., zero on success and non-zero on
                   error.  When NULL and an error occurs, then an
*************** _NOTES_
*** 5871,5881 ****
       SRC_IMAGE_INDEX and DST_IMAGE_INDEX; the memory of the send-to and
       the send-from might (partially) overlap in that case.  The
       implementation has to take care that it handles this case, e.g.
!      using 'memmove' which handles (partially) overlapping memory.  If
       MAY_REQUIRE_TMP is true, the library might additionally create a
       temporary variable, unless additional checks show that this is not
       required (e.g.  because walking backward is possible or because
!      both arrays are contiguous and 'memmove' takes care of overlap
       issues).
  
       Note that the assignment of a scalar to an array is permitted.  In
--- 5871,5881 ----
       SRC_IMAGE_INDEX and DST_IMAGE_INDEX; the memory of the send-to and
       the send-from might (partially) overlap in that case.  The
       implementation has to take care that it handles this case, e.g.
!      using ‘memmove’ which handles (partially) overlapping memory.  If
       MAY_REQUIRE_TMP is true, the library might additionally create a
       temporary variable, unless additional checks show that this is not
       required (e.g.  because walking backward is possible or because
!      both arrays are contiguous and ‘memmove’ takes care of overlap
       issues).
  
       Note that the assignment of a scalar to an array is permitted.  In
*************** _NOTES_
*** 5885,5891 ****
  
  File: gfortran.info,  Node: _gfortran_caf_send_by_ref,  Next: _gfortran_caf_get_by_ref,  Prev: _gfortran_caf_sendget,  Up: Function ABI Documentation
  
! 7.2.14 '_gfortran_caf_send_by_ref' -- Sending data from a local image to a remote image with enhanced referencing options
  -------------------------------------------------------------------------------------------------------------------------
  
  _Description_:
--- 5885,5891 ----
  
  File: gfortran.info,  Node: _gfortran_caf_send_by_ref,  Next: _gfortran_caf_get_by_ref,  Prev: _gfortran_caf_sendget,  Up: Function ABI Documentation
  
! 7.2.14 ‘_gfortran_caf_send_by_ref’ -- Sending data from a local image to a remote image with enhanced referencing options
  -------------------------------------------------------------------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5893,5902 ****
       local to a remote image identified by the IMAGE_INDEX.
  
  _Syntax_:
!      'void _gfortran_caf_send_by_ref (caf_token_t token, int
       image_index, gfc_descriptor_t *src, caf_reference_t *refs, int
       dst_kind, int src_kind, bool may_require_tmp, bool
!      dst_reallocatable, int *stat, int dst_type)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 5893,5902 ----
       local to a remote image identified by the IMAGE_INDEX.
  
  _Syntax_:
!      ‘void _gfortran_caf_send_by_ref (caf_token_t token, int
       image_index, gfc_descriptor_t *src, caf_reference_t *refs, int
       dst_kind, int src_kind, bool may_require_tmp, bool
!      dst_reallocatable, int *stat, int dst_type)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _Arguments_:
*** 5910,5929 ****
                   at least one entry.
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is 'false' when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is 'true'.
       DST_REALLOCATABLEintent(in) Set when the destination is of
                   allocatable or pointer type and the refs will
                   allow reallocation, i.e., the ref is a full
                   array or component ref.
!      STAT        intent(out) When non-'NULL' give the result of
                   the operation, i.e., zero on success and
!                  non-zero on error.  When 'NULL' and an error
                   occurs, then an error message is printed and the
                   program is terminated.
       DST_TYPE    intent(in) Give the type of the destination.
--- 5910,5929 ----
                   at least one entry.
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is ‘false’ when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is ‘true’.
       DST_REALLOCATABLEintent(in) Set when the destination is of
                   allocatable or pointer type and the refs will
                   allow reallocation, i.e., the ref is a full
                   array or component ref.
!      STAT        intent(out) When non-‘NULL’ give the result of
                   the operation, i.e., zero on success and
!                  non-zero on error.  When ‘NULL’ and an error
                   occurs, then an error message is printed and the
                   program is terminated.
       DST_TYPE    intent(in) Give the type of the destination.
*************** _NOTES_
*** 5935,5945 ****
       It is permitted to have IMAGE_INDEX equal the current image; the
       memory of the send-to and the send-from might (partially) overlap
       in that case.  The implementation has to take care that it handles
!      this case, e.g.  using 'memmove' which handles (partially)
       overlapping memory.  If MAY_REQUIRE_TMP is true, the library might
       additionally create a temporary variable, unless additional checks
       show that this is not required (e.g.  because walking backward is
!      possible or because both arrays are contiguous and 'memmove' takes
       care of overlap issues).
  
       Note that the assignment of a scalar to an array is permitted.  In
--- 5935,5945 ----
       It is permitted to have IMAGE_INDEX equal the current image; the
       memory of the send-to and the send-from might (partially) overlap
       in that case.  The implementation has to take care that it handles
!      this case, e.g.  using ‘memmove’ which handles (partially)
       overlapping memory.  If MAY_REQUIRE_TMP is true, the library might
       additionally create a temporary variable, unless additional checks
       show that this is not required (e.g.  because walking backward is
!      possible or because both arrays are contiguous and ‘memmove’ takes
       care of overlap issues).
  
       Note that the assignment of a scalar to an array is permitted.  In
*************** _NOTES_
*** 5954,5960 ****
  
  File: gfortran.info,  Node: _gfortran_caf_get_by_ref,  Next: _gfortran_caf_sendget_by_ref,  Prev: _gfortran_caf_send_by_ref,  Up: Function ABI Documentation
  
! 7.2.15 '_gfortran_caf_get_by_ref' -- Getting data from a remote image using enhanced references
  -----------------------------------------------------------------------------------------------
  
  _Description_:
--- 5954,5960 ----
  
  File: gfortran.info,  Node: _gfortran_caf_get_by_ref,  Next: _gfortran_caf_sendget_by_ref,  Prev: _gfortran_caf_send_by_ref,  Up: Function ABI Documentation
  
! 7.2.15 ‘_gfortran_caf_get_by_ref’ -- Getting data from a remote image using enhanced references
  -----------------------------------------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 5962,5971 ****
       remote image identified by the IMAGE_INDEX.
  
  _Syntax_:
!      'void _gfortran_caf_get_by_ref (caf_token_t token, int image_index,
       caf_reference_t *refs, gfc_descriptor_t *dst, int dst_kind, int
       src_kind, bool may_require_tmp, bool dst_reallocatable, int *stat,
!      int src_type)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 5962,5971 ----
       remote image identified by the IMAGE_INDEX.
  
  _Syntax_:
!      ‘void _gfortran_caf_get_by_ref (caf_token_t token, int image_index,
       caf_reference_t *refs, gfc_descriptor_t *dst, int dst_kind, int
       src_kind, bool may_require_tmp, bool dst_reallocatable, int *stat,
!      int src_type)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _Arguments_:
*** 5980,5999 ****
                   DST_REALLOCATABLE allows it.
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is 'false' when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is 'true'.
       DST_REALLOCATABLEintent(in) Set when DST is of allocatable or
                   pointer type and its refs allow reallocation,
                   i.e., the full array or a component is
                   referenced.
!      STAT        intent(out) When non-'NULL' give the result of
                   the operation, i.e., zero on success and
!                  non-zero on error.  When 'NULL' and an error
                   occurs, then an error message is printed and the
                   program is terminated.
       SRC_TYPE    intent(in) Give the type of the source.  When
--- 5980,5999 ----
                   DST_REALLOCATABLE allows it.
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is ‘false’ when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is ‘true’.
       DST_REALLOCATABLEintent(in) Set when DST is of allocatable or
                   pointer type and its refs allow reallocation,
                   i.e., the full array or a component is
                   referenced.
!      STAT        intent(out) When non-‘NULL’ give the result of
                   the operation, i.e., zero on success and
!                  non-zero on error.  When ‘NULL’ and an error
                   occurs, then an error message is printed and the
                   program is terminated.
       SRC_TYPE    intent(in) Give the type of the source.  When
*************** _Arguments_:
*** 6002,6015 ****
                   not known, but provided here.
  
  _NOTES_
!      It is permitted to have 'image_index' equal the current image; the
       memory of the send-to and the send-from might (partially) overlap
       in that case.  The implementation has to take care that it handles
!      this case, e.g.  using 'memmove' which handles (partially)
       overlapping memory.  If MAY_REQUIRE_TMP is true, the library might
       additionally create a temporary variable, unless additional checks
       show that this is not required (e.g.  because walking backward is
!      possible or because both arrays are contiguous and 'memmove' takes
       care of overlap issues).
  
       Note that the library has to handle numeric-type conversion and for
--- 6002,6015 ----
                   not known, but provided here.
  
  _NOTES_
!      It is permitted to have ‘image_index’ equal the current image; the
       memory of the send-to and the send-from might (partially) overlap
       in that case.  The implementation has to take care that it handles
!      this case, e.g.  using ‘memmove’ which handles (partially)
       overlapping memory.  If MAY_REQUIRE_TMP is true, the library might
       additionally create a temporary variable, unless additional checks
       show that this is not required (e.g.  because walking backward is
!      possible or because both arrays are contiguous and ‘memmove’ takes
       care of overlap issues).
  
       Note that the library has to handle numeric-type conversion and for
*************** _NOTES_
*** 6023,6029 ****
  
  File: gfortran.info,  Node: _gfortran_caf_sendget_by_ref,  Next: _gfortran_caf_lock,  Prev: _gfortran_caf_get_by_ref,  Up: Function ABI Documentation
  
! 7.2.16 '_gfortran_caf_sendget_by_ref' -- Sending data between remote images using enhanced references on both sides
  -------------------------------------------------------------------------------------------------------------------
  
  _Description_:
--- 6023,6029 ----
  
  File: gfortran.info,  Node: _gfortran_caf_sendget_by_ref,  Next: _gfortran_caf_lock,  Prev: _gfortran_caf_get_by_ref,  Up: Function ABI Documentation
  
! 7.2.16 ‘_gfortran_caf_sendget_by_ref’ -- Sending data between remote images using enhanced references on both sides
  -------------------------------------------------------------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6032,6042 ****
       identified by the DST_IMAGE_INDEX.
  
  _Syntax_:
!      'void _gfortran_caf_sendget_by_ref (caf_token_t dst_token, int
       dst_image_index, caf_reference_t *dst_refs, caf_token_t src_token,
       int src_image_index, caf_reference_t *src_refs, int dst_kind, int
       src_kind, bool may_require_tmp, int *dst_stat, int *src_stat, int
!      dst_type, int src_type)'
  
  _Arguments_:
       DST_TOKEN   intent(in) An opaque pointer identifying the
--- 6032,6042 ----
       identified by the DST_IMAGE_INDEX.
  
  _Syntax_:
!      ‘void _gfortran_caf_sendget_by_ref (caf_token_t dst_token, int
       dst_image_index, caf_reference_t *dst_refs, caf_token_t src_token,
       int src_image_index, caf_reference_t *src_refs, int dst_kind, int
       src_kind, bool may_require_tmp, int *dst_stat, int *src_stat, int
!      dst_type, int src_type)’
  
  _Arguments_:
       DST_TOKEN   intent(in) An opaque pointer identifying the
*************** _Arguments_:
*** 6054,6074 ****
                   structure to get the data.
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is 'false' when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is 'true'.
!      DST_STAT    intent(out) when non-'NULL' give the result of
                   the send-operation, i.e., zero on success and
!                  non-zero on error.  When 'NULL' and an error
                   occurs, then an error message is printed and the
                   program is terminated.
!      SRC_STAT    intent(out) When non-'NULL' give the result of
                   the get-operation, i.e., zero on success and
!                  non-zero on error.  When 'NULL' and an error
                   occurs, then an error message is printed and the
                   program is terminated.
       DST_TYPE    intent(in) Give the type of the destination.
--- 6054,6074 ----
                   structure to get the data.
       DST_KIND    intent(in) Kind of the destination argument
       SRC_KIND    intent(in) Kind of the source argument
!      MAY_REQUIRE_TMPintent(in) The variable is ‘false’ when it is
                   known at compile time that the DEST and SRC
                   either cannot overlap or overlap (fully or
                   partially) such that walking SRC and DEST in
                   element wise element order (honoring the stride
                   value) will not lead to wrong results.
!                  Otherwise, the value is ‘true’.
!      DST_STAT    intent(out) when non-‘NULL’ give the result of
                   the send-operation, i.e., zero on success and
!                  non-zero on error.  When ‘NULL’ and an error
                   occurs, then an error message is printed and the
                   program is terminated.
!      SRC_STAT    intent(out) When non-‘NULL’ give the result of
                   the get-operation, i.e., zero on success and
!                  non-zero on error.  When ‘NULL’ and an error
                   occurs, then an error message is printed and the
                   program is terminated.
       DST_TYPE    intent(in) Give the type of the destination.
*************** _NOTES_
*** 6085,6095 ****
       SRC_IMAGE_INDEX and DST_IMAGE_INDEX; the memory of the send-to and
       the send-from might (partially) overlap in that case.  The
       implementation has to take care that it handles this case, e.g.
!      using 'memmove' which handles (partially) overlapping memory.  If
       MAY_REQUIRE_TMP is true, the library might additionally create a
       temporary variable, unless additional checks show that this is not
       required (e.g.  because walking backward is possible or because
!      both arrays are contiguous and 'memmove' takes care of overlap
       issues).
  
       Note that the assignment of a scalar to an array is permitted.  In
--- 6085,6095 ----
       SRC_IMAGE_INDEX and DST_IMAGE_INDEX; the memory of the send-to and
       the send-from might (partially) overlap in that case.  The
       implementation has to take care that it handles this case, e.g.
!      using ‘memmove’ which handles (partially) overlapping memory.  If
       MAY_REQUIRE_TMP is true, the library might additionally create a
       temporary variable, unless additional checks show that this is not
       required (e.g.  because walking backward is possible or because
!      both arrays are contiguous and ‘memmove’ takes care of overlap
       issues).
  
       Note that the assignment of a scalar to an array is permitted.  In
*************** _NOTES_
*** 6104,6125 ****
  
  File: gfortran.info,  Node: _gfortran_caf_lock,  Next: _gfortran_caf_unlock,  Prev: _gfortran_caf_sendget_by_ref,  Up: Function ABI Documentation
  
! 7.2.17 '_gfortran_caf_lock' -- Locking a lock variable
  ------------------------------------------------------
  
  _Description_:
       Acquire a lock on the given image on a scalar locking variable or
       for the given array element for an array-valued variable.  If the
!      ACQUIRED_LOCK is 'NULL', the function returns after having obtained
!      the lock.  If it is non-'NULL', then ACQUIRED_LOCK is assigned the
       value true (one) when the lock could be obtained and false (zero)
       otherwise.  Locking a lock variable which has already been locked
       by the same image is an error.
  
  _Syntax_:
!      'void _gfortran_caf_lock (caf_token_t token, size_t index, int
       image_index, int *acquired_lock, int *stat, char *errmsg, size_t
!      errmsg_len)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 6104,6125 ----
  
  File: gfortran.info,  Node: _gfortran_caf_lock,  Next: _gfortran_caf_unlock,  Prev: _gfortran_caf_sendget_by_ref,  Up: Function ABI Documentation
  
! 7.2.17 ‘_gfortran_caf_lock’ -- Locking a lock variable
  ------------------------------------------------------
  
  _Description_:
       Acquire a lock on the given image on a scalar locking variable or
       for the given array element for an array-valued variable.  If the
!      ACQUIRED_LOCK is ‘NULL’, the function returns after having obtained
!      the lock.  If it is non-‘NULL’, then ACQUIRED_LOCK is assigned the
       value true (one) when the lock could be obtained and false (zero)
       otherwise.  Locking a lock variable which has already been locked
       by the same image is an error.
  
  _Syntax_:
!      ‘void _gfortran_caf_lock (caf_token_t token, size_t index, int
       image_index, int *acquired_lock, int *stat, char *errmsg, size_t
!      errmsg_len)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _NOTES_
*** 6144,6150 ****
  
  File: gfortran.info,  Node: _gfortran_caf_unlock,  Next: _gfortran_caf_event_post,  Prev: _gfortran_caf_lock,  Up: Function ABI Documentation
  
! 7.2.18 '_gfortran_caf_lock' -- Unlocking a lock variable
  --------------------------------------------------------
  
  _Description_:
--- 6144,6150 ----
  
  File: gfortran.info,  Node: _gfortran_caf_unlock,  Next: _gfortran_caf_event_post,  Prev: _gfortran_caf_lock,  Up: Function ABI Documentation
  
! 7.2.18 ‘_gfortran_caf_lock’ -- Unlocking a lock variable
  --------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6154,6161 ****
       different image is an error.
  
  _Syntax_:
!      'void _gfortran_caf_unlock (caf_token_t token, size_t index, int
!      image_index, int *stat, char *errmsg, size_t errmsg_len)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 6154,6161 ----
       different image is an error.
  
  _Syntax_:
!      ‘void _gfortran_caf_unlock (caf_token_t token, size_t index, int
!      image_index, int *stat, char *errmsg, size_t errmsg_len)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _NOTES_
*** 6179,6193 ****
  
  File: gfortran.info,  Node: _gfortran_caf_event_post,  Next: _gfortran_caf_event_wait,  Prev: _gfortran_caf_unlock,  Up: Function ABI Documentation
  
! 7.2.19 '_gfortran_caf_event_post' -- Post an event
  --------------------------------------------------
  
  _Description_:
       Increment the event count of the specified event variable.
  
  _Syntax_:
!      'void _gfortran_caf_event_post (caf_token_t token, size_t index,
!      int image_index, int *stat, char *errmsg, size_t errmsg_len)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 6179,6193 ----
  
  File: gfortran.info,  Node: _gfortran_caf_event_post,  Next: _gfortran_caf_event_wait,  Prev: _gfortran_caf_unlock,  Up: Function ABI Documentation
  
! 7.2.19 ‘_gfortran_caf_event_post’ -- Post an event
  --------------------------------------------------
  
  _Description_:
       Increment the event count of the specified event variable.
  
  _Syntax_:
!      ‘void _gfortran_caf_event_post (caf_token_t token, size_t index,
!      int image_index, int *stat, char *errmsg, size_t errmsg_len)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _NOTES_
*** 6207,6218 ****
       variable.  The statement is an image-control statement but does not
       imply sync memory.  Still, all preceeding push communications of
       this image to the specified remote image have to be completed
!      before 'event_wait' on the remote image returns.
  
  
  File: gfortran.info,  Node: _gfortran_caf_event_wait,  Next: _gfortran_caf_event_query,  Prev: _gfortran_caf_event_post,  Up: Function ABI Documentation
  
! 7.2.20 '_gfortran_caf_event_wait' -- Wait that an event occurred
  ----------------------------------------------------------------
  
  _Description_:
--- 6207,6218 ----
       variable.  The statement is an image-control statement but does not
       imply sync memory.  Still, all preceeding push communications of
       this image to the specified remote image have to be completed
!      before ‘event_wait’ on the remote image returns.
  
  
  File: gfortran.info,  Node: _gfortran_caf_event_wait,  Next: _gfortran_caf_event_query,  Prev: _gfortran_caf_event_post,  Up: Function ABI Documentation
  
! 7.2.20 ‘_gfortran_caf_event_wait’ -- Wait that an event occurred
  ----------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6221,6228 ****
       amount and return.
  
  _Syntax_:
!      'void _gfortran_caf_event_wait (caf_token_t token, size_t index,
!      int until_count, int *stat, char *errmsg, size_t errmsg_len)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 6221,6228 ----
       amount and return.
  
  _Syntax_:
!      ‘void _gfortran_caf_event_wait (caf_token_t token, size_t index,
!      int until_count, int *stat, char *errmsg, size_t errmsg_len)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _NOTES_
*** 6250,6270 ****
  
       The statement is an image-control statement but does not imply sync
       memory.  Still, all preceeding push communications of this image to
!      the specified remote image have to be completed before 'event_wait'
       on the remote image returns.
  
  
  File: gfortran.info,  Node: _gfortran_caf_event_query,  Next: _gfortran_caf_sync_all,  Prev: _gfortran_caf_event_wait,  Up: Function ABI Documentation
  
! 7.2.21 '_gfortran_caf_event_query' -- Query event count
  -------------------------------------------------------
  
  _Description_:
       Return the event count of the specified event variable.
  
  _Syntax_:
!      'void _gfortran_caf_event_query (caf_token_t token, size_t index,
!      int image_index, int *count, int *stat)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 6250,6270 ----
  
       The statement is an image-control statement but does not imply sync
       memory.  Still, all preceeding push communications of this image to
!      the specified remote image have to be completed before ‘event_wait’
       on the remote image returns.
  
  
  File: gfortran.info,  Node: _gfortran_caf_event_query,  Next: _gfortran_caf_sync_all,  Prev: _gfortran_caf_event_wait,  Up: Function ABI Documentation
  
! 7.2.21 ‘_gfortran_caf_event_query’ -- Query event count
  -------------------------------------------------------
  
  _Description_:
       Return the event count of the specified event variable.
  
  _Syntax_:
!      ‘void _gfortran_caf_event_query (caf_token_t token, size_t index,
!      int image_index, int *count, int *stat)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _Arguments_:
*** 6280,6286 ****
  
  _NOTES_
       The typical use is to check the local event variable to only call
!      'event_wait' when the data is available.  However, a coindexed
       variable is permitted; there is no ordering or synchronization
       implied.  It acts like an atomic fetch of the value of the event
       variable.
--- 6280,6286 ----
  
  _NOTES_
       The typical use is to check the local event variable to only call
!      ‘event_wait’ when the data is available.  However, a coindexed
       variable is permitted; there is no ordering or synchronization
       implied.  It acts like an atomic fetch of the value of the event
       variable.
*************** _NOTES_
*** 6288,6294 ****
  
  File: gfortran.info,  Node: _gfortran_caf_sync_all,  Next: _gfortran_caf_sync_images,  Prev: _gfortran_caf_event_query,  Up: Function ABI Documentation
  
! 7.2.22 '_gfortran_caf_sync_all' -- All-image barrier
  ----------------------------------------------------
  
  _Description_:
--- 6288,6294 ----
  
  File: gfortran.info,  Node: _gfortran_caf_sync_all,  Next: _gfortran_caf_sync_images,  Prev: _gfortran_caf_event_query,  Up: Function ABI Documentation
  
! 7.2.22 ‘_gfortran_caf_sync_all’ -- All-image barrier
  ----------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6298,6305 ****
       pending data transfers of previous segment have completed.
  
  _Syntax_:
!      'void _gfortran_caf_sync_all (int *stat, char *errmsg, size_t
!      errmsg_len)'
  
  _Arguments_:
       STAT        intent(out) Stores the status STAT= and may be
--- 6298,6305 ----
       pending data transfers of previous segment have completed.
  
  _Syntax_:
!      ‘void _gfortran_caf_sync_all (int *stat, char *errmsg, size_t
!      errmsg_len)’
  
  _Arguments_:
       STAT        intent(out) Stores the status STAT= and may be
*************** _Arguments_:
*** 6311,6337 ****
  
  File: gfortran.info,  Node: _gfortran_caf_sync_images,  Next: _gfortran_caf_sync_memory,  Prev: _gfortran_caf_sync_all,  Up: Function ABI Documentation
  
! 7.2.23 '_gfortran_caf_sync_images' -- Barrier for selected images
  -----------------------------------------------------------------
  
  _Description_:
       Synchronization between the specified images; the program only
       continues on a given image after this function has been called on
       all images specified for that image.  Note that one image can wait
!      for all other images in the current team (e.g.  via 'sync
!      images(*)') while those only wait for that specific image.
!      Additionally, 'sync images' ensures that all pending data transfers
       of previous segments have completed.
  
  _Syntax_:
!      'void _gfortran_caf_sync_images (int count, int images[], int
!      *stat, char *errmsg, size_t errmsg_len)'
  
  _Arguments_:
       COUNT       intent(in) The number of images which are
                   provided in the next argument.  For a zero-sized
!                  array, the value is zero.  For 'sync images
!                  (*)', the value is -1.
       IMAGES      intent(in) An array with the images provided by
                   the user.  If COUNT is zero, a NULL pointer is
                   passed.
--- 6311,6337 ----
  
  File: gfortran.info,  Node: _gfortran_caf_sync_images,  Next: _gfortran_caf_sync_memory,  Prev: _gfortran_caf_sync_all,  Up: Function ABI Documentation
  
! 7.2.23 ‘_gfortran_caf_sync_images’ -- Barrier for selected images
  -----------------------------------------------------------------
  
  _Description_:
       Synchronization between the specified images; the program only
       continues on a given image after this function has been called on
       all images specified for that image.  Note that one image can wait
!      for all other images in the current team (e.g.  via ‘sync
!      images(*)’) while those only wait for that specific image.
!      Additionally, ‘sync images’ ensures that all pending data transfers
       of previous segments have completed.
  
  _Syntax_:
!      ‘void _gfortran_caf_sync_images (int count, int images[], int
!      *stat, char *errmsg, size_t errmsg_len)’
  
  _Arguments_:
       COUNT       intent(in) The number of images which are
                   provided in the next argument.  For a zero-sized
!                  array, the value is zero.  For ‘sync images
!                  (*)’, the value is -1.
       IMAGES      intent(in) An array with the images provided by
                   the user.  If COUNT is zero, a NULL pointer is
                   passed.
*************** _Arguments_:
*** 6344,6350 ****
  
  File: gfortran.info,  Node: _gfortran_caf_sync_memory,  Next: _gfortran_caf_error_stop,  Prev: _gfortran_caf_sync_images,  Up: Function ABI Documentation
  
! 7.2.24 '_gfortran_caf_sync_memory' -- Wait for completion of segment-memory operations
  --------------------------------------------------------------------------------------
  
  _Description_:
--- 6344,6350 ----
  
  File: gfortran.info,  Node: _gfortran_caf_sync_memory,  Next: _gfortran_caf_error_stop,  Prev: _gfortran_caf_sync_images,  Up: Function ABI Documentation
  
! 7.2.24 ‘_gfortran_caf_sync_memory’ -- Wait for completion of segment-memory operations
  --------------------------------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6353,6360 ****
       completed.
  
  _Syntax_:
!      'void _gfortran_caf_sync_memory (int *stat, char *errmsg, size_t
!      errmsg_len)'
  
  _Arguments_:
       STAT        intent(out) Stores the status STAT= and may be
--- 6353,6360 ----
       completed.
  
  _Syntax_:
!      ‘void _gfortran_caf_sync_memory (int *stat, char *errmsg, size_t
!      errmsg_len)’
  
  _Arguments_:
       STAT        intent(out) Stores the status STAT= and may be
*************** _Arguments_:
*** 6364,6384 ****
       ERRMSG_LEN  intent(in) the buffer size of errmsg
  
  _NOTE_ A simple implementation could be
!      '__asm__ __volatile__ ("":::"memory")' to prevent code movements.
  
  
  File: gfortran.info,  Node: _gfortran_caf_error_stop,  Next: _gfortran_caf_error_stop_str,  Prev: _gfortran_caf_sync_memory,  Up: Function ABI Documentation
  
! 7.2.25 '_gfortran_caf_error_stop' -- Error termination with exit code
  ---------------------------------------------------------------------
  
  _Description_:
!      Invoked for an 'ERROR STOP' statement which has an integer
       argument.  The function should terminate the program with the
       specified exit code.
  
  _Syntax_:
!      'void _gfortran_caf_error_stop (int error)'
  
  _Arguments_:
       ERROR       intent(in) The exit status to be used.
--- 6364,6384 ----
       ERRMSG_LEN  intent(in) the buffer size of errmsg
  
  _NOTE_ A simple implementation could be
!      ‘__asm__ __volatile__ ("":::"memory")’ to prevent code movements.
  
  
  File: gfortran.info,  Node: _gfortran_caf_error_stop,  Next: _gfortran_caf_error_stop_str,  Prev: _gfortran_caf_sync_memory,  Up: Function ABI Documentation
  
! 7.2.25 ‘_gfortran_caf_error_stop’ -- Error termination with exit code
  ---------------------------------------------------------------------
  
  _Description_:
!      Invoked for an ‘ERROR STOP’ statement which has an integer
       argument.  The function should terminate the program with the
       specified exit code.
  
  _Syntax_:
!      ‘void _gfortran_caf_error_stop (int error)’
  
  _Arguments_:
       ERROR       intent(in) The exit status to be used.
*************** _Arguments_:
*** 6386,6401 ****
  
  File: gfortran.info,  Node: _gfortran_caf_error_stop_str,  Next: _gfortran_caf_fail_image,  Prev: _gfortran_caf_error_stop,  Up: Function ABI Documentation
  
! 7.2.26 '_gfortran_caf_error_stop_str' -- Error termination with string
  ----------------------------------------------------------------------
  
  _Description_:
!      Invoked for an 'ERROR STOP' statement which has a string as
       argument.  The function should terminate the program with a
       nonzero-exit code.
  
  _Syntax_:
!      'void _gfortran_caf_error_stop (const char *string, size_t len)'
  
  _Arguments_:
       STRING      intent(in) the error message (not zero
--- 6386,6401 ----
  
  File: gfortran.info,  Node: _gfortran_caf_error_stop_str,  Next: _gfortran_caf_fail_image,  Prev: _gfortran_caf_error_stop,  Up: Function ABI Documentation
  
! 7.2.26 ‘_gfortran_caf_error_stop_str’ -- Error termination with string
  ----------------------------------------------------------------------
  
  _Description_:
!      Invoked for an ‘ERROR STOP’ statement which has a string as
       argument.  The function should terminate the program with a
       nonzero-exit code.
  
  _Syntax_:
!      ‘void _gfortran_caf_error_stop (const char *string, size_t len)’
  
  _Arguments_:
       STRING      intent(in) the error message (not zero
*************** _Arguments_:
*** 6405,6419 ****
  
  File: gfortran.info,  Node: _gfortran_caf_fail_image,  Next: _gfortran_caf_atomic_define,  Prev: _gfortran_caf_error_stop_str,  Up: Function ABI Documentation
  
! 7.2.27 '_gfortran_caf_fail_image' -- Mark the image failed and end its execution
  --------------------------------------------------------------------------------
  
  _Description_:
!      Invoked for an 'FAIL IMAGE' statement.  The function should
       terminate the current image.
  
  _Syntax_:
!      'void _gfortran_caf_fail_image ()'
  
  _NOTES_
       This function follows TS18508.
--- 6405,6419 ----
  
  File: gfortran.info,  Node: _gfortran_caf_fail_image,  Next: _gfortran_caf_atomic_define,  Prev: _gfortran_caf_error_stop_str,  Up: Function ABI Documentation
  
! 7.2.27 ‘_gfortran_caf_fail_image’ -- Mark the image failed and end its execution
  --------------------------------------------------------------------------------
  
  _Description_:
!      Invoked for an ‘FAIL IMAGE’ statement.  The function should
       terminate the current image.
  
  _Syntax_:
!      ‘void _gfortran_caf_fail_image ()’
  
  _NOTES_
       This function follows TS18508.
*************** _NOTES_
*** 6421,6436 ****
  
  File: gfortran.info,  Node: _gfortran_caf_atomic_define,  Next: _gfortran_caf_atomic_ref,  Prev: _gfortran_caf_fail_image,  Up: Function ABI Documentation
  
! 7.2.28 '_gfortran_caf_atomic_define' -- Atomic variable assignment
  ------------------------------------------------------------------
  
  _Description_:
       Assign atomically a value to an integer or logical variable.
  
  _Syntax_:
!      'void _gfortran_caf_atomic_define (caf_token_t token, size_t
       offset, int image_index, void *value, int *stat, int type, int
!      kind)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 6421,6436 ----
  
  File: gfortran.info,  Node: _gfortran_caf_atomic_define,  Next: _gfortran_caf_atomic_ref,  Prev: _gfortran_caf_fail_image,  Up: Function ABI Documentation
  
! 7.2.28 ‘_gfortran_caf_atomic_define’ -- Atomic variable assignment
  ------------------------------------------------------------------
  
  _Description_:
       Assign atomically a value to an integer or logical variable.
  
  _Syntax_:
!      ‘void _gfortran_caf_atomic_define (caf_token_t token, size_t
       offset, int image_index, void *value, int *stat, int type, int
!      kind)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _Arguments_:
*** 6445,6458 ****
                   reference
       STAT        intent(out) Stores the status STAT= and may be
                   NULL.
!      TYPE        intent(in) The data type, i.e.  'BT_INTEGER' (1)
!                  or 'BT_LOGICAL' (2).
!      KIND        intent(in) The kind value (only 4; always 'int')
  
  
  File: gfortran.info,  Node: _gfortran_caf_atomic_ref,  Next: _gfortran_caf_atomic_cas,  Prev: _gfortran_caf_atomic_define,  Up: Function ABI Documentation
  
! 7.2.29 '_gfortran_caf_atomic_ref' -- Atomic variable reference
  --------------------------------------------------------------
  
  _Description_:
--- 6445,6458 ----
                   reference
       STAT        intent(out) Stores the status STAT= and may be
                   NULL.
!      TYPE        intent(in) The data type, i.e.  ‘BT_INTEGER’ (1)
!                  or ‘BT_LOGICAL’ (2).
!      KIND        intent(in) The kind value (only 4; always ‘int’)
  
  
  File: gfortran.info,  Node: _gfortran_caf_atomic_ref,  Next: _gfortran_caf_atomic_cas,  Prev: _gfortran_caf_atomic_define,  Up: Function ABI Documentation
  
! 7.2.29 ‘_gfortran_caf_atomic_ref’ -- Atomic variable reference
  --------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6460,6467 ****
       variable.
  
  _Syntax_:
!      'void _gfortran_caf_atomic_ref (caf_token_t token, size_t offset,
!      int image_index, void *value, int *stat, int type, int kind)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 6460,6467 ----
       variable.
  
  _Syntax_:
!      ‘void _gfortran_caf_atomic_ref (caf_token_t token, size_t offset,
!      int image_index, void *value, int *stat, int type, int kind)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _Arguments_:
*** 6476,6489 ****
                   referenced variable.
       STAT        intent(out) Stores the status STAT= and may be
                   NULL.
!      TYPE        the data type, i.e.  'BT_INTEGER' (1) or
!                  'BT_LOGICAL' (2).
!      KIND        The kind value (only 4; always 'int')
  
  
  File: gfortran.info,  Node: _gfortran_caf_atomic_cas,  Next: _gfortran_caf_atomic_op,  Prev: _gfortran_caf_atomic_ref,  Up: Function ABI Documentation
  
! 7.2.30 '_gfortran_caf_atomic_cas' -- Atomic compare and swap
  ------------------------------------------------------------
  
  _Description_:
--- 6476,6489 ----
                   referenced variable.
       STAT        intent(out) Stores the status STAT= and may be
                   NULL.
!      TYPE        the data type, i.e.  ‘BT_INTEGER’ (1) or
!                  ‘BT_LOGICAL’ (2).
!      KIND        The kind value (only 4; always ‘int’)
  
  
  File: gfortran.info,  Node: _gfortran_caf_atomic_cas,  Next: _gfortran_caf_atomic_op,  Prev: _gfortran_caf_atomic_ref,  Up: Function ABI Documentation
  
! 7.2.30 ‘_gfortran_caf_atomic_cas’ -- Atomic compare and swap
  ------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6492,6500 ****
       the latter has the value specified by the passed condition value.
  
  _Syntax_:
!      'void _gfortran_caf_atomic_cas (caf_token_t token, size_t offset,
       int image_index, void *old, void *compare, void *new_val, int
!      *stat, int type, int kind)'
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
--- 6492,6500 ----
       the latter has the value specified by the passed condition value.
  
  _Syntax_:
!      ‘void _gfortran_caf_atomic_cas (caf_token_t token, size_t offset,
       int image_index, void *old, void *compare, void *new_val, int
!      *stat, int type, int kind)’
  
  _Arguments_:
       TOKEN       intent(in) An opaque pointer identifying the
*************** _Arguments_:
*** 6510,6547 ****
       COMPARE     intent(in) The value used for comparision.
       NEW_VAL     intent(in) The new value for the atomic
                   variable, assigned to the atomic variable, if
!                  'compare' equals the value of the atomic
                   variable.
       STAT        intent(out) Stores the status STAT= and may be
                   NULL.
!      TYPE        intent(in) the data type, i.e.  'BT_INTEGER' (1)
!                  or 'BT_LOGICAL' (2).
!      KIND        intent(in) The kind value (only 4; always 'int')
  
  
  File: gfortran.info,  Node: _gfortran_caf_atomic_op,  Next: _gfortran_caf_co_broadcast,  Prev: _gfortran_caf_atomic_cas,  Up: Function ABI Documentation
  
! 7.2.31 '_gfortran_caf_atomic_op' -- Atomic operation
  ----------------------------------------------------
  
  _Description_:
       Apply an operation atomically to an atomic integer or logical
       variable.  After the operation, OLD contains the value just before
       the operation, which, respectively, adds (GFC_CAF_ATOMIC_ADD)
!      atomically the 'value' to the atomic integer variable or does a
       bitwise AND, OR or exclusive OR between the atomic variable and
       VALUE; the result is then stored in the atomic variable.
  
  _Syntax_:
!      'void _gfortran_caf_atomic_op (int op, caf_token_t token, size_t
       offset, int image_index, void *value, void *old, int *stat, int
!      type, int kind)'
  
  _Arguments_:
       OP          intent(in) the operation to be performed;
!                  possible values 'GFC_CAF_ATOMIC_ADD' (1),
!                  'GFC_CAF_ATOMIC_AND' (2), 'GFC_CAF_ATOMIC_OR'
!                  (3), 'GFC_CAF_ATOMIC_XOR' (4).
       TOKEN       intent(in) An opaque pointer identifying the
                   coarray.
       OFFSET      intent(in) By which amount of bytes the actual
--- 6510,6547 ----
       COMPARE     intent(in) The value used for comparision.
       NEW_VAL     intent(in) The new value for the atomic
                   variable, assigned to the atomic variable, if
!                  ‘compare’ equals the value of the atomic
                   variable.
       STAT        intent(out) Stores the status STAT= and may be
                   NULL.
!      TYPE        intent(in) the data type, i.e.  ‘BT_INTEGER’ (1)
!                  or ‘BT_LOGICAL’ (2).
!      KIND        intent(in) The kind value (only 4; always ‘int’)
  
  
  File: gfortran.info,  Node: _gfortran_caf_atomic_op,  Next: _gfortran_caf_co_broadcast,  Prev: _gfortran_caf_atomic_cas,  Up: Function ABI Documentation
  
! 7.2.31 ‘_gfortran_caf_atomic_op’ -- Atomic operation
  ----------------------------------------------------
  
  _Description_:
       Apply an operation atomically to an atomic integer or logical
       variable.  After the operation, OLD contains the value just before
       the operation, which, respectively, adds (GFC_CAF_ATOMIC_ADD)
!      atomically the ‘value’ to the atomic integer variable or does a
       bitwise AND, OR or exclusive OR between the atomic variable and
       VALUE; the result is then stored in the atomic variable.
  
  _Syntax_:
!      ‘void _gfortran_caf_atomic_op (int op, caf_token_t token, size_t
       offset, int image_index, void *value, void *old, int *stat, int
!      type, int kind)’
  
  _Arguments_:
       OP          intent(in) the operation to be performed;
!                  possible values ‘GFC_CAF_ATOMIC_ADD’ (1),
!                  ‘GFC_CAF_ATOMIC_AND’ (2), ‘GFC_CAF_ATOMIC_OR’
!                  (3), ‘GFC_CAF_ATOMIC_XOR’ (4).
       TOKEN       intent(in) An opaque pointer identifying the
                   coarray.
       OFFSET      intent(in) By which amount of bytes the actual
*************** _Arguments_:
*** 6554,6571 ****
                   had just before the atomic operation.
       VAL         intent(in) The new value for the atomic
                   variable, assigned to the atomic variable, if
!                  'compare' equals the value of the atomic
                   variable.
       STAT        intent(out) Stores the status STAT= and may be
                   NULL.
!      TYPE        intent(in) the data type, i.e.  'BT_INTEGER' (1)
!                  or 'BT_LOGICAL' (2)
!      KIND        intent(in) the kind value (only 4; always 'int')
  
  
  File: gfortran.info,  Node: _gfortran_caf_co_broadcast,  Next: _gfortran_caf_co_max,  Prev: _gfortran_caf_atomic_op,  Up: Function ABI Documentation
  
! 7.2.32 '_gfortran_caf_co_broadcast' -- Sending data to all images
  -----------------------------------------------------------------
  
  _Description_:
--- 6554,6571 ----
                   had just before the atomic operation.
       VAL         intent(in) The new value for the atomic
                   variable, assigned to the atomic variable, if
!                  ‘compare’ equals the value of the atomic
                   variable.
       STAT        intent(out) Stores the status STAT= and may be
                   NULL.
!      TYPE        intent(in) the data type, i.e.  ‘BT_INTEGER’ (1)
!                  or ‘BT_LOGICAL’ (2)
!      KIND        intent(in) the kind value (only 4; always ‘int’)
  
  
  File: gfortran.info,  Node: _gfortran_caf_co_broadcast,  Next: _gfortran_caf_co_max,  Prev: _gfortran_caf_atomic_op,  Up: Function ABI Documentation
  
! 7.2.32 ‘_gfortran_caf_co_broadcast’ -- Sending data to all images
  -----------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6573,6580 ****
       team.  Has to be called collectively.
  
  _Syntax_:
!      'void _gfortran_caf_co_broadcast (gfc_descriptor_t *a, int
!      source_image, int *stat, char *errmsg, size_t errmsg_len)'
  
  _Arguments_:
       A           intent(inout) An array descriptor with the data
--- 6573,6580 ----
       team.  Has to be called collectively.
  
  _Syntax_:
!      ‘void _gfortran_caf_co_broadcast (gfc_descriptor_t *a, int
!      source_image, int *stat, char *errmsg, size_t errmsg_len)’
  
  _Arguments_:
       A           intent(inout) An array descriptor with the data
*************** _Arguments_:
*** 6591,6597 ****
  
  File: gfortran.info,  Node: _gfortran_caf_co_max,  Next: _gfortran_caf_co_min,  Prev: _gfortran_caf_co_broadcast,  Up: Function ABI Documentation
  
! 7.2.33 '_gfortran_caf_co_max' -- Collective maximum reduction
  -------------------------------------------------------------
  
  _Description_:
--- 6591,6597 ----
  
  File: gfortran.info,  Node: _gfortran_caf_co_max,  Next: _gfortran_caf_co_min,  Prev: _gfortran_caf_co_broadcast,  Up: Function ABI Documentation
  
! 7.2.33 ‘_gfortran_caf_co_max’ -- Collective maximum reduction
  -------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6602,6609 ****
       and character strings.
  
  _Syntax_:
!      'void _gfortran_caf_co_max (gfc_descriptor_t *a, int result_image,
!      int *stat, char *errmsg, int a_len, size_t errmsg_len)'
  
  _Arguments_:
       A           intent(inout) An array descriptor for the data
--- 6602,6609 ----
       and character strings.
  
  _Syntax_:
!      ‘void _gfortran_caf_co_max (gfc_descriptor_t *a, int result_image,
!      int *stat, char *errmsg, int a_len, size_t errmsg_len)’
  
  _Arguments_:
       A           intent(inout) An array descriptor for the data
*************** _NOTES_
*** 6627,6633 ****
  
  File: gfortran.info,  Node: _gfortran_caf_co_min,  Next: _gfortran_caf_co_sum,  Prev: _gfortran_caf_co_max,  Up: Function ABI Documentation
  
! 7.2.34 '_gfortran_caf_co_min' -- Collective minimum reduction
  -------------------------------------------------------------
  
  _Description_:
--- 6627,6633 ----
  
  File: gfortran.info,  Node: _gfortran_caf_co_min,  Next: _gfortran_caf_co_sum,  Prev: _gfortran_caf_co_max,  Up: Function ABI Documentation
  
! 7.2.34 ‘_gfortran_caf_co_min’ -- Collective minimum reduction
  -------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6638,6645 ****
       and character strings.
  
  _Syntax_:
!      'void _gfortran_caf_co_min (gfc_descriptor_t *a, int result_image,
!      int *stat, char *errmsg, int a_len, size_t errmsg_len)'
  
  _Arguments_:
       A           intent(inout) An array descriptor for the data
--- 6638,6645 ----
       and character strings.
  
  _Syntax_:
!      ‘void _gfortran_caf_co_min (gfc_descriptor_t *a, int result_image,
!      int *stat, char *errmsg, int a_len, size_t errmsg_len)’
  
  _Arguments_:
       A           intent(inout) An array descriptor for the data
*************** _NOTES_
*** 6663,6669 ****
  
  File: gfortran.info,  Node: _gfortran_caf_co_sum,  Next: _gfortran_caf_co_reduce,  Prev: _gfortran_caf_co_min,  Up: Function ABI Documentation
  
! 7.2.35 '_gfortran_caf_co_sum' -- Collective summing reduction
  -------------------------------------------------------------
  
  _Description_:
--- 6663,6669 ----
  
  File: gfortran.info,  Node: _gfortran_caf_co_sum,  Next: _gfortran_caf_co_reduce,  Prev: _gfortran_caf_co_min,  Up: Function ABI Documentation
  
! 7.2.35 ‘_gfortran_caf_co_sum’ -- Collective summing reduction
  -------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6674,6681 ****
       values only.
  
  _Syntax_:
!      'void _gfortran_caf_co_sum (gfc_descriptor_t *a, int result_image,
!      int *stat, char *errmsg, size_t errmsg_len)'
  
  _Arguments_:
       A           intent(inout) An array descriptor with the data
--- 6674,6681 ----
       values only.
  
  _Syntax_:
!      ‘void _gfortran_caf_co_sum (gfc_descriptor_t *a, int result_image,
!      int *stat, char *errmsg, size_t errmsg_len)’
  
  _Arguments_:
       A           intent(inout) An array descriptor with the data
*************** _NOTES_
*** 6698,6704 ****
  
  File: gfortran.info,  Node: _gfortran_caf_co_reduce,  Prev: _gfortran_caf_co_sum,  Up: Function ABI Documentation
  
! 7.2.36 '_gfortran_caf_co_reduce' -- Generic collective reduction
  ----------------------------------------------------------------
  
  _Description_:
--- 6698,6704 ----
  
  File: gfortran.info,  Node: _gfortran_caf_co_reduce,  Prev: _gfortran_caf_co_sum,  Up: Function ABI Documentation
  
! 7.2.36 ‘_gfortran_caf_co_reduce’ -- Generic collective reduction
  ----------------------------------------------------------------
  
  _Description_:
*************** _Description_:
*** 6709,6725 ****
       mathematically commutative and associative operation.
  
       The OPR_FLAGS denote the following; the values are bitwise ored.
!      'GFC_CAF_BYREF' (1) if the result should be returned by reference;
!      'GFC_CAF_HIDDENLEN' (2) whether the result and argument string
!      lengths shall be specified as hidden arguments; 'GFC_CAF_ARG_VALUE'
       (4) whether the arguments shall be passed by value,
!      'GFC_CAF_ARG_DESC' (8) whether the arguments shall be passed by
       descriptor.
  
  _Syntax_:
!      'void _gfortran_caf_co_reduce (gfc_descriptor_t *a, void * (*opr)
       (void *, void *), int opr_flags, int result_image, int *stat, char
!      *errmsg, int a_len, size_t errmsg_len)'
  
  _Arguments_:
       A           intent(inout) An array descriptor with the data
--- 6709,6725 ----
       mathematically commutative and associative operation.
  
       The OPR_FLAGS denote the following; the values are bitwise ored.
!      ‘GFC_CAF_BYREF’ (1) if the result should be returned by reference;
!      ‘GFC_CAF_HIDDENLEN’ (2) whether the result and argument string
!      lengths shall be specified as hidden arguments; ‘GFC_CAF_ARG_VALUE’
       (4) whether the arguments shall be passed by value,
!      ‘GFC_CAF_ARG_DESC’ (8) whether the arguments shall be passed by
       descriptor.
  
  _Syntax_:
!      ‘void _gfortran_caf_co_reduce (gfc_descriptor_t *a, void * (*opr)
       (void *, void *), int opr_flags, int result_image, int *stat, char
!      *errmsg, int a_len, size_t errmsg_len)’
  
  _Arguments_:
       A           intent(inout) An array descriptor with the data
*************** File: gfortran.info,  Node: Intrinsic Pr
*** 6760,7047 ****
  * Menu:
  
  * Introduction:         Introduction to Intrinsics
! * 'ABORT':         ABORT,     Abort the program
! * 'ABS':           ABS,       Absolute value
! * 'ACCESS':        ACCESS,    Checks file access modes
! * 'ACHAR':         ACHAR,     Character in ASCII collating sequence
! * 'ACOS':          ACOS,      Arccosine function
! * 'ACOSD':         ACOSD,     Arccosine function, degrees
! * 'ACOSH':         ACOSH,     Inverse hyperbolic cosine function
! * 'ADJUSTL':       ADJUSTL,   Left adjust a string
! * 'ADJUSTR':       ADJUSTR,   Right adjust a string
! * 'AIMAG':         AIMAG,     Imaginary part of complex number
! * 'AINT':          AINT,      Truncate to a whole number
! * 'ALARM':         ALARM,     Set an alarm clock
! * 'ALL':           ALL,       Determine if all values are true
! * 'ALLOCATED':     ALLOCATED, Status of allocatable entity
! * 'AND':           AND,       Bitwise logical AND
! * 'ANINT':         ANINT,     Nearest whole number
! * 'ANY':           ANY,       Determine if any values are true
! * 'ASIN':          ASIN,      Arcsine function
! * 'ASIND':         ASIND,     Arcsine function, degrees
! * 'ASINH':         ASINH,     Inverse hyperbolic sine function
! * 'ASSOCIATED':    ASSOCIATED, Status of a pointer or pointer/target pair
! * 'ATAN':          ATAN,      Arctangent function
! * 'ATAND':         ATAND,     Arctangent function, degrees
! * 'ATAN2':         ATAN2,     Arctangent function
! * 'ATAN2D':        ATAN2D,    Arctangent function, degrees
! * 'ATANH':         ATANH,     Inverse hyperbolic tangent function
! * 'ATOMIC_ADD':    ATOMIC_ADD, Atomic ADD operation
! * 'ATOMIC_AND':    ATOMIC_AND, Atomic bitwise AND operation
! * 'ATOMIC_CAS':    ATOMIC_CAS, Atomic compare and swap
! * 'ATOMIC_DEFINE': ATOMIC_DEFINE, Setting a variable atomically
! * 'ATOMIC_FETCH_ADD': ATOMIC_FETCH_ADD, Atomic ADD operation with prior fetch
! * 'ATOMIC_FETCH_AND': ATOMIC_FETCH_AND, Atomic bitwise AND operation with prior fetch
! * 'ATOMIC_FETCH_OR': ATOMIC_FETCH_OR, Atomic bitwise OR operation with prior fetch
! * 'ATOMIC_FETCH_XOR': ATOMIC_FETCH_XOR, Atomic bitwise XOR operation with prior fetch
! * 'ATOMIC_OR':     ATOMIC_OR, Atomic bitwise OR operation
! * 'ATOMIC_REF':    ATOMIC_REF, Obtaining the value of a variable atomically
! * 'ATOMIC_XOR':    ATOMIC_XOR, Atomic bitwise OR operation
! * 'BACKTRACE':     BACKTRACE, Show a backtrace
! * 'BESSEL_J0':     BESSEL_J0, Bessel function of the first kind of order 0
! * 'BESSEL_J1':     BESSEL_J1, Bessel function of the first kind of order 1
! * 'BESSEL_JN':     BESSEL_JN, Bessel function of the first kind
! * 'BESSEL_Y0':     BESSEL_Y0, Bessel function of the second kind of order 0
! * 'BESSEL_Y1':     BESSEL_Y1, Bessel function of the second kind of order 1
! * 'BESSEL_YN':     BESSEL_YN, Bessel function of the second kind
! * 'BGE':           BGE,       Bitwise greater than or equal to
! * 'BGT':           BGT,       Bitwise greater than
! * 'BIT_SIZE':      BIT_SIZE,  Bit size inquiry function
! * 'BLE':           BLE,       Bitwise less than or equal to
! * 'BLT':           BLT,       Bitwise less than
! * 'BTEST':         BTEST,     Bit test function
! * 'C_ASSOCIATED':  C_ASSOCIATED, Status of a C pointer
! * 'C_F_POINTER':   C_F_POINTER, Convert C into Fortran pointer
! * 'C_F_PROCPOINTER': C_F_PROCPOINTER, Convert C into Fortran procedure pointer
! * 'C_FUNLOC':      C_FUNLOC,  Obtain the C address of a procedure
! * 'C_LOC':         C_LOC,     Obtain the C address of an object
! * 'C_SIZEOF':      C_SIZEOF,  Size in bytes of an expression
! * 'CEILING':       CEILING,   Integer ceiling function
! * 'CHAR':          CHAR,      Integer-to-character conversion function
! * 'CHDIR':         CHDIR,     Change working directory
! * 'CHMOD':         CHMOD,     Change access permissions of files
! * 'CMPLX':         CMPLX,     Complex conversion function
! * 'CO_BROADCAST':  CO_BROADCAST, Copy a value to all images the current set of images
! * 'CO_MAX':        CO_MAX,    Maximal value on the current set of images
! * 'CO_MIN':        CO_MIN,    Minimal value on the current set of images
! * 'CO_REDUCE':     CO_REDUCE, Reduction of values on the current set of images
! * 'CO_SUM':        CO_SUM,    Sum of values on the current set of images
! * 'COMMAND_ARGUMENT_COUNT': COMMAND_ARGUMENT_COUNT, Get number of command line arguments
! * 'COMPILER_OPTIONS': COMPILER_OPTIONS, Options passed to the compiler
! * 'COMPILER_VERSION': COMPILER_VERSION, Compiler version string
! * 'COMPLEX':       COMPLEX,   Complex conversion function
! * 'CONJG':         CONJG,     Complex conjugate function
! * 'COS':           COS,       Cosine function
! * 'COSD':          COSD,      Cosine function, degrees
! * 'COSH':          COSH,      Hyperbolic cosine function
! * 'COTAN':         COTAN,     Cotangent function
! * 'COTAND':        COTAND,    Cotangent function, degrees
! * 'COUNT':         COUNT,     Count occurrences of TRUE in an array
! * 'CPU_TIME':      CPU_TIME,  CPU time subroutine
! * 'CSHIFT':        CSHIFT,    Circular shift elements of an array
! * 'CTIME':         CTIME,     Subroutine (or function) to convert a time into a string
! * 'DATE_AND_TIME': DATE_AND_TIME, Date and time subroutine
! * 'DBLE':          DBLE,      Double precision conversion function
! * 'DCMPLX':        DCMPLX,    Double complex conversion function
! * 'DIGITS':        DIGITS,    Significant digits function
! * 'DIM':           DIM,       Positive difference
! * 'DOT_PRODUCT':   DOT_PRODUCT, Dot product function
! * 'DPROD':         DPROD,     Double product function
! * 'DREAL':         DREAL,     Double real part function
! * 'DSHIFTL':       DSHIFTL,   Combined left shift
! * 'DSHIFTR':       DSHIFTR,   Combined right shift
! * 'DTIME':         DTIME,     Execution time subroutine (or function)
! * 'EOSHIFT':       EOSHIFT,   End-off shift elements of an array
! * 'EPSILON':       EPSILON,   Epsilon function
! * 'ERF':           ERF,       Error function
! * 'ERFC':          ERFC,      Complementary error function
! * 'ERFC_SCALED':   ERFC_SCALED, Exponentially-scaled complementary error function
! * 'ETIME':         ETIME,     Execution time subroutine (or function)
! * 'EVENT_QUERY': EVENT_QUERY, Query whether a coarray event has occurred
! * 'EXECUTE_COMMAND_LINE': EXECUTE_COMMAND_LINE, Execute a shell command
! * 'EXIT':          EXIT,      Exit the program with status.
! * 'EXP':           EXP,       Exponential function
! * 'EXPONENT':      EXPONENT,  Exponent function
! * 'EXTENDS_TYPE_OF': EXTENDS_TYPE_OF,  Query dynamic type for extension
! * 'FDATE':         FDATE,     Subroutine (or function) to get the current time as a string
! * 'FGET':          FGET,      Read a single character in stream mode from stdin
! * 'FGETC':         FGETC,     Read a single character in stream mode
! * 'FINDLOC':       FINDLOC,   Search an array for a value
! * 'FLOOR':         FLOOR,     Integer floor function
! * 'FLUSH':         FLUSH,     Flush I/O unit(s)
! * 'FNUM':          FNUM,      File number function
! * 'FPUT':          FPUT,      Write a single character in stream mode to stdout
! * 'FPUTC':         FPUTC,     Write a single character in stream mode
! * 'FRACTION':      FRACTION,  Fractional part of the model representation
! * 'FREE':          FREE,      Memory de-allocation subroutine
! * 'FSEEK':         FSEEK,     Low level file positioning subroutine
! * 'FSTAT':         FSTAT,     Get file status
! * 'FTELL':         FTELL,     Current stream position
! * 'GAMMA':         GAMMA,     Gamma function
! * 'GERROR':        GERROR,    Get last system error message
! * 'GETARG':        GETARG,    Get command line arguments
! * 'GET_COMMAND':   GET_COMMAND, Get the entire command line
! * 'GET_COMMAND_ARGUMENT': GET_COMMAND_ARGUMENT, Get command line arguments
! * 'GETCWD':        GETCWD,    Get current working directory
! * 'GETENV':        GETENV,    Get an environmental variable
! * 'GET_ENVIRONMENT_VARIABLE': GET_ENVIRONMENT_VARIABLE, Get an environmental variable
! * 'GETGID':        GETGID,    Group ID function
! * 'GETLOG':        GETLOG,    Get login name
! * 'GETPID':        GETPID,    Process ID function
! * 'GETUID':        GETUID,    User ID function
! * 'GMTIME':        GMTIME,    Convert time to GMT info
! * 'HOSTNM':        HOSTNM,    Get system host name
! * 'HUGE':          HUGE,      Largest number of a kind
! * 'HYPOT':         HYPOT,     Euclidean distance function
! * 'IACHAR':        IACHAR,    Code in ASCII collating sequence
! * 'IALL':          IALL,      Bitwise AND of array elements
! * 'IAND':          IAND,      Bitwise logical and
! * 'IANY':          IANY,      Bitwise OR of array elements
! * 'IARGC':         IARGC,     Get the number of command line arguments
! * 'IBCLR':         IBCLR,     Clear bit
! * 'IBITS':         IBITS,     Bit extraction
! * 'IBSET':         IBSET,     Set bit
! * 'ICHAR':         ICHAR,     Character-to-integer conversion function
! * 'IDATE':         IDATE,     Current local time (day/month/year)
! * 'IEOR':          IEOR,      Bitwise logical exclusive or
! * 'IERRNO':        IERRNO,    Function to get the last system error number
! * 'IMAGE_INDEX':   IMAGE_INDEX, Cosubscript to image index conversion
! * 'INDEX':         INDEX intrinsic, Position of a substring within a string
! * 'INT':           INT,       Convert to integer type
! * 'INT2':          INT2,      Convert to 16-bit integer type
! * 'INT8':          INT8,      Convert to 64-bit integer type
! * 'IOR':           IOR,       Bitwise logical or
! * 'IPARITY':       IPARITY,   Bitwise XOR of array elements
! * 'IRAND':         IRAND,     Integer pseudo-random number
! * 'IS_CONTIGUOUS':  IS_CONTIGUOUS, Test whether an array is contiguous
! * 'IS_IOSTAT_END':  IS_IOSTAT_END, Test for end-of-file value
! * 'IS_IOSTAT_EOR':  IS_IOSTAT_EOR, Test for end-of-record value
! * 'ISATTY':        ISATTY,    Whether a unit is a terminal device
! * 'ISHFT':         ISHFT,     Shift bits
! * 'ISHFTC':        ISHFTC,    Shift bits circularly
! * 'ISNAN':         ISNAN,     Tests for a NaN
! * 'ITIME':         ITIME,     Current local time (hour/minutes/seconds)
! * 'KILL':          KILL,      Send a signal to a process
! * 'KIND':          KIND,      Kind of an entity
! * 'LBOUND':        LBOUND,    Lower dimension bounds of an array
! * 'LCOBOUND':      LCOBOUND,  Lower codimension bounds of an array
! * 'LEADZ':         LEADZ,     Number of leading zero bits of an integer
! * 'LEN':           LEN,       Length of a character entity
! * 'LEN_TRIM':      LEN_TRIM,  Length of a character entity without trailing blank characters
! * 'LGE':           LGE,       Lexical greater than or equal
! * 'LGT':           LGT,       Lexical greater than
! * 'LINK':          LINK,      Create a hard link
! * 'LLE':           LLE,       Lexical less than or equal
! * 'LLT':           LLT,       Lexical less than
! * 'LNBLNK':        LNBLNK,    Index of the last non-blank character in a string
! * 'LOC':           LOC,       Returns the address of a variable
! * 'LOG':           LOG,       Logarithm function
! * 'LOG10':         LOG10,     Base 10 logarithm function
! * 'LOG_GAMMA':     LOG_GAMMA, Logarithm of the Gamma function
! * 'LOGICAL':       LOGICAL,   Convert to logical type
! * 'LSHIFT':        LSHIFT,    Left shift bits
! * 'LSTAT':         LSTAT,     Get file status
! * 'LTIME':         LTIME,     Convert time to local time info
! * 'MALLOC':        MALLOC,    Dynamic memory allocation function
! * 'MASKL':         MASKL,     Left justified mask
! * 'MASKR':         MASKR,     Right justified mask
! * 'MATMUL':        MATMUL,    matrix multiplication
! * 'MAX':           MAX,       Maximum value of an argument list
! * 'MAXEXPONENT':   MAXEXPONENT, Maximum exponent of a real kind
! * 'MAXLOC':        MAXLOC,    Location of the maximum value within an array
! * 'MAXVAL':        MAXVAL,    Maximum value of an array
! * 'MCLOCK':        MCLOCK,    Time function
! * 'MCLOCK8':       MCLOCK8,   Time function (64-bit)
! * 'MERGE':         MERGE,     Merge arrays
! * 'MERGE_BITS':    MERGE_BITS, Merge of bits under mask
! * 'MIN':           MIN,       Minimum value of an argument list
! * 'MINEXPONENT':   MINEXPONENT, Minimum exponent of a real kind
! * 'MINLOC':        MINLOC,    Location of the minimum value within an array
! * 'MINVAL':        MINVAL,    Minimum value of an array
! * 'MOD':           MOD,       Remainder function
! * 'MODULO':        MODULO,    Modulo function
! * 'MOVE_ALLOC':    MOVE_ALLOC, Move allocation from one object to another
! * 'MVBITS':        MVBITS,    Move bits from one integer to another
! * 'NEAREST':       NEAREST,   Nearest representable number
! * 'NEW_LINE':      NEW_LINE,  New line character
! * 'NINT':          NINT,      Nearest whole number
! * 'NORM2':         NORM2,     Euclidean vector norm
! * 'NOT':           NOT,       Logical negation
! * 'NULL':          NULL,      Function that returns an disassociated pointer
! * 'NUM_IMAGES':    NUM_IMAGES, Number of images
! * 'OR':            OR,        Bitwise logical OR
! * 'PACK':          PACK,      Pack an array into an array of rank one
! * 'PARITY':        PARITY,    Reduction with exclusive OR
! * 'PERROR':        PERROR,    Print system error message
! * 'POPCNT':        POPCNT,    Number of bits set
! * 'POPPAR':        POPPAR,    Parity of the number of bits set
! * 'PRECISION':     PRECISION, Decimal precision of a real kind
! * 'PRESENT':       PRESENT,   Determine whether an optional dummy argument is specified
! * 'PRODUCT':       PRODUCT,   Product of array elements
! * 'RADIX':         RADIX,     Base of a data model
! * 'RAN':           RAN,       Real pseudo-random number
! * 'RAND':          RAND,      Real pseudo-random number
! * 'RANDOM_INIT':   RANDOM_INIT, Initialize pseudo-random number generator
! * 'RANDOM_NUMBER': RANDOM_NUMBER, Pseudo-random number
! * 'RANDOM_SEED':   RANDOM_SEED, Initialize a pseudo-random number sequence
! * 'RANGE':         RANGE,     Decimal exponent range
! * 'RANK' :         RANK,      Rank of a data object
! * 'REAL':          REAL,      Convert to real type
! * 'RENAME':        RENAME,    Rename a file
! * 'REPEAT':        REPEAT,    Repeated string concatenation
! * 'RESHAPE':       RESHAPE,   Function to reshape an array
! * 'RRSPACING':     RRSPACING, Reciprocal of the relative spacing
! * 'RSHIFT':        RSHIFT,    Right shift bits
! * 'SAME_TYPE_AS':  SAME_TYPE_AS,  Query dynamic types for equality
! * 'SCALE':         SCALE,     Scale a real value
! * 'SCAN':          SCAN,      Scan a string for the presence of a set of characters
! * 'SECNDS':        SECNDS,    Time function
! * 'SECOND':        SECOND,    CPU time function
! * 'SELECTED_CHAR_KIND': SELECTED_CHAR_KIND,  Choose character kind
! * 'SELECTED_INT_KIND': SELECTED_INT_KIND,  Choose integer kind
! * 'SELECTED_REAL_KIND': SELECTED_REAL_KIND,  Choose real kind
! * 'SET_EXPONENT':  SET_EXPONENT, Set the exponent of the model
! * 'SHAPE':         SHAPE,     Determine the shape of an array
! * 'SHIFTA':        SHIFTA,    Right shift with fill
! * 'SHIFTL':        SHIFTL,    Left shift
! * 'SHIFTR':        SHIFTR,    Right shift
! * 'SIGN':          SIGN,      Sign copying function
! * 'SIGNAL':        SIGNAL,    Signal handling subroutine (or function)
! * 'SIN':           SIN,       Sine function
! * 'SIND':          SIND,      Sine function, degrees
! * 'SINH':          SINH,      Hyperbolic sine function
! * 'SIZE':          SIZE,      Function to determine the size of an array
! * 'SIZEOF':        SIZEOF,    Determine the size in bytes of an expression
! * 'SLEEP':         SLEEP,     Sleep for the specified number of seconds
! * 'SPACING':       SPACING,   Smallest distance between two numbers of a given type
! * 'SPREAD':        SPREAD,    Add a dimension to an array
! * 'SQRT':          SQRT,      Square-root function
! * 'SRAND':         SRAND,     Reinitialize the random number generator
! * 'STAT':          STAT,      Get file status
! * 'STORAGE_SIZE':  STORAGE_SIZE, Storage size in bits
! * 'SUM':           SUM,       Sum of array elements
! * 'SYMLNK':        SYMLNK,    Create a symbolic link
! * 'SYSTEM':        SYSTEM,    Execute a shell command
! * 'SYSTEM_CLOCK':  SYSTEM_CLOCK, Time function
! * 'TAN':           TAN,       Tangent function
! * 'TAND':          TAND,      Tangent function, degrees
! * 'TANH':          TANH,      Hyperbolic tangent function
! * 'THIS_IMAGE':    THIS_IMAGE, Cosubscript index of this image
! * 'TIME':          TIME,      Time function
! * 'TIME8':         TIME8,     Time function (64-bit)
! * 'TINY':          TINY,      Smallest positive number of a real kind
! * 'TRAILZ':        TRAILZ,    Number of trailing zero bits of an integer
! * 'TRANSFER':      TRANSFER,  Transfer bit patterns
! * 'TRANSPOSE':     TRANSPOSE, Transpose an array of rank two
! * 'TRIM':          TRIM,      Remove trailing blank characters of a string
! * 'TTYNAM':        TTYNAM,    Get the name of a terminal device
! * 'UBOUND':        UBOUND,    Upper dimension bounds of an array
! * 'UCOBOUND':      UCOBOUND,  Upper codimension bounds of an array
! * 'UMASK':         UMASK,     Set the file creation mask
! * 'UNLINK':        UNLINK,    Remove a file from the file system
! * 'UNPACK':        UNPACK,    Unpack an array of rank one into an array
! * 'VERIFY':        VERIFY,    Scan a string for the absence of a set of characters
! * 'XOR':           XOR,       Bitwise logical exclusive or
  
  
  File: gfortran.info,  Node: Introduction to Intrinsics,  Next: ABORT,  Up: Intrinsic Procedures
--- 6760,7047 ----
  * Menu:
  
  * Introduction:         Introduction to Intrinsics
! * ‘ABORT’:         ABORT,     Abort the program
! * ‘ABS’:           ABS,       Absolute value
! * ‘ACCESS’:        ACCESS,    Checks file access modes
! * ‘ACHAR’:         ACHAR,     Character in ASCII collating sequence
! * ‘ACOS’:          ACOS,      Arccosine function
! * ‘ACOSD’:         ACOSD,     Arccosine function, degrees
! * ‘ACOSH’:         ACOSH,     Inverse hyperbolic cosine function
! * ‘ADJUSTL’:       ADJUSTL,   Left adjust a string
! * ‘ADJUSTR’:       ADJUSTR,   Right adjust a string
! * ‘AIMAG’:         AIMAG,     Imaginary part of complex number
! * ‘AINT’:          AINT,      Truncate to a whole number
! * ‘ALARM’:         ALARM,     Set an alarm clock
! * ‘ALL’:           ALL,       Determine if all values are true
! * ‘ALLOCATED’:     ALLOCATED, Status of allocatable entity
! * ‘AND’:           AND,       Bitwise logical AND
! * ‘ANINT’:         ANINT,     Nearest whole number
! * ‘ANY’:           ANY,       Determine if any values are true
! * ‘ASIN’:          ASIN,      Arcsine function
! * ‘ASIND’:         ASIND,     Arcsine function, degrees
! * ‘ASINH’:         ASINH,     Inverse hyperbolic sine function
! * ‘ASSOCIATED’:    ASSOCIATED, Status of a pointer or pointer/target pair
! * ‘ATAN’:          ATAN,      Arctangent function
! * ‘ATAND’:         ATAND,     Arctangent function, degrees
! * ‘ATAN2’:         ATAN2,     Arctangent function
! * ‘ATAN2D’:        ATAN2D,    Arctangent function, degrees
! * ‘ATANH’:         ATANH,     Inverse hyperbolic tangent function
! * ‘ATOMIC_ADD’:    ATOMIC_ADD, Atomic ADD operation
! * ‘ATOMIC_AND’:    ATOMIC_AND, Atomic bitwise AND operation
! * ‘ATOMIC_CAS’:    ATOMIC_CAS, Atomic compare and swap
! * ‘ATOMIC_DEFINE’: ATOMIC_DEFINE, Setting a variable atomically
! * ‘ATOMIC_FETCH_ADD’: ATOMIC_FETCH_ADD, Atomic ADD operation with prior fetch
! * ‘ATOMIC_FETCH_AND’: ATOMIC_FETCH_AND, Atomic bitwise AND operation with prior fetch
! * ‘ATOMIC_FETCH_OR’: ATOMIC_FETCH_OR, Atomic bitwise OR operation with prior fetch
! * ‘ATOMIC_FETCH_XOR’: ATOMIC_FETCH_XOR, Atomic bitwise XOR operation with prior fetch
! * ‘ATOMIC_OR’:     ATOMIC_OR, Atomic bitwise OR operation
! * ‘ATOMIC_REF’:    ATOMIC_REF, Obtaining the value of a variable atomically
! * ‘ATOMIC_XOR’:    ATOMIC_XOR, Atomic bitwise OR operation
! * ‘BACKTRACE’:     BACKTRACE, Show a backtrace
! * ‘BESSEL_J0’:     BESSEL_J0, Bessel function of the first kind of order 0
! * ‘BESSEL_J1’:     BESSEL_J1, Bessel function of the first kind of order 1
! * ‘BESSEL_JN’:     BESSEL_JN, Bessel function of the first kind
! * ‘BESSEL_Y0’:     BESSEL_Y0, Bessel function of the second kind of order 0
! * ‘BESSEL_Y1’:     BESSEL_Y1, Bessel function of the second kind of order 1
! * ‘BESSEL_YN’:     BESSEL_YN, Bessel function of the second kind
! * ‘BGE’:           BGE,       Bitwise greater than or equal to
! * ‘BGT’:           BGT,       Bitwise greater than
! * ‘BIT_SIZE’:      BIT_SIZE,  Bit size inquiry function
! * ‘BLE’:           BLE,       Bitwise less than or equal to
! * ‘BLT’:           BLT,       Bitwise less than
! * ‘BTEST’:         BTEST,     Bit test function
! * ‘C_ASSOCIATED’:  C_ASSOCIATED, Status of a C pointer
! * ‘C_F_POINTER’:   C_F_POINTER, Convert C into Fortran pointer
! * ‘C_F_PROCPOINTER’: C_F_PROCPOINTER, Convert C into Fortran procedure pointer
! * ‘C_FUNLOC’:      C_FUNLOC,  Obtain the C address of a procedure
! * ‘C_LOC’:         C_LOC,     Obtain the C address of an object
! * ‘C_SIZEOF’:      C_SIZEOF,  Size in bytes of an expression
! * ‘CEILING’:       CEILING,   Integer ceiling function
! * ‘CHAR’:          CHAR,      Integer-to-character conversion function
! * ‘CHDIR’:         CHDIR,     Change working directory
! * ‘CHMOD’:         CHMOD,     Change access permissions of files
! * ‘CMPLX’:         CMPLX,     Complex conversion function
! * ‘CO_BROADCAST’:  CO_BROADCAST, Copy a value to all images the current set of images
! * ‘CO_MAX’:        CO_MAX,    Maximal value on the current set of images
! * ‘CO_MIN’:        CO_MIN,    Minimal value on the current set of images
! * ‘CO_REDUCE’:     CO_REDUCE, Reduction of values on the current set of images
! * ‘CO_SUM’:        CO_SUM,    Sum of values on the current set of images
! * ‘COMMAND_ARGUMENT_COUNT’: COMMAND_ARGUMENT_COUNT, Get number of command line arguments
! * ‘COMPILER_OPTIONS’: COMPILER_OPTIONS, Options passed to the compiler
! * ‘COMPILER_VERSION’: COMPILER_VERSION, Compiler version string
! * ‘COMPLEX’:       COMPLEX,   Complex conversion function
! * ‘CONJG’:         CONJG,     Complex conjugate function
! * ‘COS’:           COS,       Cosine function
! * ‘COSD’:          COSD,      Cosine function, degrees
! * ‘COSH’:          COSH,      Hyperbolic cosine function
! * ‘COTAN’:         COTAN,     Cotangent function
! * ‘COTAND’:        COTAND,    Cotangent function, degrees
! * ‘COUNT’:         COUNT,     Count occurrences of TRUE in an array
! * ‘CPU_TIME’:      CPU_TIME,  CPU time subroutine
! * ‘CSHIFT’:        CSHIFT,    Circular shift elements of an array
! * ‘CTIME’:         CTIME,     Subroutine (or function) to convert a time into a string
! * ‘DATE_AND_TIME’: DATE_AND_TIME, Date and time subroutine
! * ‘DBLE’:          DBLE,      Double precision conversion function
! * ‘DCMPLX’:        DCMPLX,    Double complex conversion function
! * ‘DIGITS’:        DIGITS,    Significant digits function
! * ‘DIM’:           DIM,       Positive difference
! * ‘DOT_PRODUCT’:   DOT_PRODUCT, Dot product function
! * ‘DPROD’:         DPROD,     Double product function
! * ‘DREAL’:         DREAL,     Double real part function
! * ‘DSHIFTL’:       DSHIFTL,   Combined left shift
! * ‘DSHIFTR’:       DSHIFTR,   Combined right shift
! * ‘DTIME’:         DTIME,     Execution time subroutine (or function)
! * ‘EOSHIFT’:       EOSHIFT,   End-off shift elements of an array
! * ‘EPSILON’:       EPSILON,   Epsilon function
! * ‘ERF’:           ERF,       Error function
! * ‘ERFC’:          ERFC,      Complementary error function
! * ‘ERFC_SCALED’:   ERFC_SCALED, Exponentially-scaled complementary error function
! * ‘ETIME’:         ETIME,     Execution time subroutine (or function)
! * ‘EVENT_QUERY’: EVENT_QUERY, Query whether a coarray event has occurred
! * ‘EXECUTE_COMMAND_LINE’: EXECUTE_COMMAND_LINE, Execute a shell command
! * ‘EXIT’:          EXIT,      Exit the program with status.
! * ‘EXP’:           EXP,       Exponential function
! * ‘EXPONENT’:      EXPONENT,  Exponent function
! * ‘EXTENDS_TYPE_OF’: EXTENDS_TYPE_OF,  Query dynamic type for extension
! * ‘FDATE’:         FDATE,     Subroutine (or function) to get the current time as a string
! * ‘FGET’:          FGET,      Read a single character in stream mode from stdin
! * ‘FGETC’:         FGETC,     Read a single character in stream mode
! * ‘FINDLOC’:       FINDLOC,   Search an array for a value
! * ‘FLOOR’:         FLOOR,     Integer floor function
! * ‘FLUSH’:         FLUSH,     Flush I/O unit(s)
! * ‘FNUM’:          FNUM,      File number function
! * ‘FPUT’:          FPUT,      Write a single character in stream mode to stdout
! * ‘FPUTC’:         FPUTC,     Write a single character in stream mode
! * ‘FRACTION’:      FRACTION,  Fractional part of the model representation
! * ‘FREE’:          FREE,      Memory de-allocation subroutine
! * ‘FSEEK’:         FSEEK,     Low level file positioning subroutine
! * ‘FSTAT’:         FSTAT,     Get file status
! * ‘FTELL’:         FTELL,     Current stream position
! * ‘GAMMA’:         GAMMA,     Gamma function
! * ‘GERROR’:        GERROR,    Get last system error message
! * ‘GETARG’:        GETARG,    Get command line arguments
! * ‘GET_COMMAND’:   GET_COMMAND, Get the entire command line
! * ‘GET_COMMAND_ARGUMENT’: GET_COMMAND_ARGUMENT, Get command line arguments
! * ‘GETCWD’:        GETCWD,    Get current working directory
! * ‘GETENV’:        GETENV,    Get an environmental variable
! * ‘GET_ENVIRONMENT_VARIABLE’: GET_ENVIRONMENT_VARIABLE, Get an environmental variable
! * ‘GETGID’:        GETGID,    Group ID function
! * ‘GETLOG’:        GETLOG,    Get login name
! * ‘GETPID’:        GETPID,    Process ID function
! * ‘GETUID’:        GETUID,    User ID function
! * ‘GMTIME’:        GMTIME,    Convert time to GMT info
! * ‘HOSTNM’:        HOSTNM,    Get system host name
! * ‘HUGE’:          HUGE,      Largest number of a kind
! * ‘HYPOT’:         HYPOT,     Euclidean distance function
! * ‘IACHAR’:        IACHAR,    Code in ASCII collating sequence
! * ‘IALL’:          IALL,      Bitwise AND of array elements
! * ‘IAND’:          IAND,      Bitwise logical and
! * ‘IANY’:          IANY,      Bitwise OR of array elements
! * ‘IARGC’:         IARGC,     Get the number of command line arguments
! * ‘IBCLR’:         IBCLR,     Clear bit
! * ‘IBITS’:         IBITS,     Bit extraction
! * ‘IBSET’:         IBSET,     Set bit
! * ‘ICHAR’:         ICHAR,     Character-to-integer conversion function
! * ‘IDATE’:         IDATE,     Current local time (day/month/year)
! * ‘IEOR’:          IEOR,      Bitwise logical exclusive or
! * ‘IERRNO’:        IERRNO,    Function to get the last system error number
! * ‘IMAGE_INDEX’:   IMAGE_INDEX, Cosubscript to image index conversion
! * ‘INDEX’:         INDEX intrinsic, Position of a substring within a string
! * ‘INT’:           INT,       Convert to integer type
! * ‘INT2’:          INT2,      Convert to 16-bit integer type
! * ‘INT8’:          INT8,      Convert to 64-bit integer type
! * ‘IOR’:           IOR,       Bitwise logical or
! * ‘IPARITY’:       IPARITY,   Bitwise XOR of array elements
! * ‘IRAND’:         IRAND,     Integer pseudo-random number
! * ‘IS_CONTIGUOUS’:  IS_CONTIGUOUS, Test whether an array is contiguous
! * ‘IS_IOSTAT_END’:  IS_IOSTAT_END, Test for end-of-file value
! * ‘IS_IOSTAT_EOR’:  IS_IOSTAT_EOR, Test for end-of-record value
! * ‘ISATTY’:        ISATTY,    Whether a unit is a terminal device
! * ‘ISHFT’:         ISHFT,     Shift bits
! * ‘ISHFTC’:        ISHFTC,    Shift bits circularly
! * ‘ISNAN’:         ISNAN,     Tests for a NaN
! * ‘ITIME’:         ITIME,     Current local time (hour/minutes/seconds)
! * ‘KILL’:          KILL,      Send a signal to a process
! * ‘KIND’:          KIND,      Kind of an entity
! * ‘LBOUND’:        LBOUND,    Lower dimension bounds of an array
! * ‘LCOBOUND’:      LCOBOUND,  Lower codimension bounds of an array
! * ‘LEADZ’:         LEADZ,     Number of leading zero bits of an integer
! * ‘LEN’:           LEN,       Length of a character entity
! * ‘LEN_TRIM’:      LEN_TRIM,  Length of a character entity without trailing blank characters
! * ‘LGE’:           LGE,       Lexical greater than or equal
! * ‘LGT’:           LGT,       Lexical greater than
! * ‘LINK’:          LINK,      Create a hard link
! * ‘LLE’:           LLE,       Lexical less than or equal
! * ‘LLT’:           LLT,       Lexical less than
! * ‘LNBLNK’:        LNBLNK,    Index of the last non-blank character in a string
! * ‘LOC’:           LOC,       Returns the address of a variable
! * ‘LOG’:           LOG,       Logarithm function
! * ‘LOG10’:         LOG10,     Base 10 logarithm function
! * ‘LOG_GAMMA’:     LOG_GAMMA, Logarithm of the Gamma function
! * ‘LOGICAL’:       LOGICAL,   Convert to logical type
! * ‘LSHIFT’:        LSHIFT,    Left shift bits
! * ‘LSTAT’:         LSTAT,     Get file status
! * ‘LTIME’:         LTIME,     Convert time to local time info
! * ‘MALLOC’:        MALLOC,    Dynamic memory allocation function
! * ‘MASKL’:         MASKL,     Left justified mask
! * ‘MASKR’:         MASKR,     Right justified mask
! * ‘MATMUL’:        MATMUL,    matrix multiplication
! * ‘MAX’:           MAX,       Maximum value of an argument list
! * ‘MAXEXPONENT’:   MAXEXPONENT, Maximum exponent of a real kind
! * ‘MAXLOC’:        MAXLOC,    Location of the maximum value within an array
! * ‘MAXVAL’:        MAXVAL,    Maximum value of an array
! * ‘MCLOCK’:        MCLOCK,    Time function
! * ‘MCLOCK8’:       MCLOCK8,   Time function (64-bit)
! * ‘MERGE’:         MERGE,     Merge arrays
! * ‘MERGE_BITS’:    MERGE_BITS, Merge of bits under mask
! * ‘MIN’:           MIN,       Minimum value of an argument list
! * ‘MINEXPONENT’:   MINEXPONENT, Minimum exponent of a real kind
! * ‘MINLOC’:        MINLOC,    Location of the minimum value within an array
! * ‘MINVAL’:        MINVAL,    Minimum value of an array
! * ‘MOD’:           MOD,       Remainder function
! * ‘MODULO’:        MODULO,    Modulo function
! * ‘MOVE_ALLOC’:    MOVE_ALLOC, Move allocation from one object to another
! * ‘MVBITS’:        MVBITS,    Move bits from one integer to another
! * ‘NEAREST’:       NEAREST,   Nearest representable number
! * ‘NEW_LINE’:      NEW_LINE,  New line character
! * ‘NINT’:          NINT,      Nearest whole number
! * ‘NORM2’:         NORM2,     Euclidean vector norm
! * ‘NOT’:           NOT,       Logical negation
! * ‘NULL’:          NULL,      Function that returns an disassociated pointer
! * ‘NUM_IMAGES’:    NUM_IMAGES, Number of images
! * ‘OR’:            OR,        Bitwise logical OR
! * ‘PACK’:          PACK,      Pack an array into an array of rank one
! * ‘PARITY’:        PARITY,    Reduction with exclusive OR
! * ‘PERROR’:        PERROR,    Print system error message
! * ‘POPCNT’:        POPCNT,    Number of bits set
! * ‘POPPAR’:        POPPAR,    Parity of the number of bits set
! * ‘PRECISION’:     PRECISION, Decimal precision of a real kind
! * ‘PRESENT’:       PRESENT,   Determine whether an optional dummy argument is specified
! * ‘PRODUCT’:       PRODUCT,   Product of array elements
! * ‘RADIX’:         RADIX,     Base of a data model
! * ‘RAN’:           RAN,       Real pseudo-random number
! * ‘RAND’:          RAND,      Real pseudo-random number
! * ‘RANDOM_INIT’:   RANDOM_INIT, Initialize pseudo-random number generator
! * ‘RANDOM_NUMBER’: RANDOM_NUMBER, Pseudo-random number
! * ‘RANDOM_SEED’:   RANDOM_SEED, Initialize a pseudo-random number sequence
! * ‘RANGE’:         RANGE,     Decimal exponent range
! * ‘RANK’ :         RANK,      Rank of a data object
! * ‘REAL’:          REAL,      Convert to real type
! * ‘RENAME’:        RENAME,    Rename a file
! * ‘REPEAT’:        REPEAT,    Repeated string concatenation
! * ‘RESHAPE’:       RESHAPE,   Function to reshape an array
! * ‘RRSPACING’:     RRSPACING, Reciprocal of the relative spacing
! * ‘RSHIFT’:        RSHIFT,    Right shift bits
! * ‘SAME_TYPE_AS’:  SAME_TYPE_AS,  Query dynamic types for equality
! * ‘SCALE’:         SCALE,     Scale a real value
! * ‘SCAN’:          SCAN,      Scan a string for the presence of a set of characters
! * ‘SECNDS’:        SECNDS,    Time function
! * ‘SECOND’:        SECOND,    CPU time function
! * ‘SELECTED_CHAR_KIND’: SELECTED_CHAR_KIND,  Choose character kind
! * ‘SELECTED_INT_KIND’: SELECTED_INT_KIND,  Choose integer kind
! * ‘SELECTED_REAL_KIND’: SELECTED_REAL_KIND,  Choose real kind
! * ‘SET_EXPONENT’:  SET_EXPONENT, Set the exponent of the model
! * ‘SHAPE’:         SHAPE,     Determine the shape of an array
! * ‘SHIFTA’:        SHIFTA,    Right shift with fill
! * ‘SHIFTL’:        SHIFTL,    Left shift
! * ‘SHIFTR’:        SHIFTR,    Right shift
! * ‘SIGN’:          SIGN,      Sign copying function
! * ‘SIGNAL’:        SIGNAL,    Signal handling subroutine (or function)
! * ‘SIN’:           SIN,       Sine function
! * ‘SIND’:          SIND,      Sine function, degrees
! * ‘SINH’:          SINH,      Hyperbolic sine function
! * ‘SIZE’:          SIZE,      Function to determine the size of an array
! * ‘SIZEOF’:        SIZEOF,    Determine the size in bytes of an expression
! * ‘SLEEP’:         SLEEP,     Sleep for the specified number of seconds
! * ‘SPACING’:       SPACING,   Smallest distance between two numbers of a given type
! * ‘SPREAD’:        SPREAD,    Add a dimension to an array
! * ‘SQRT’:          SQRT,      Square-root function
! * ‘SRAND’:         SRAND,     Reinitialize the random number generator
! * ‘STAT’:          STAT,      Get file status
! * ‘STORAGE_SIZE’:  STORAGE_SIZE, Storage size in bits
! * ‘SUM’:           SUM,       Sum of array elements
! * ‘SYMLNK’:        SYMLNK,    Create a symbolic link
! * ‘SYSTEM’:        SYSTEM,    Execute a shell command
! * ‘SYSTEM_CLOCK’:  SYSTEM_CLOCK, Time function
! * ‘TAN’:           TAN,       Tangent function
! * ‘TAND’:          TAND,      Tangent function, degrees
! * ‘TANH’:          TANH,      Hyperbolic tangent function
! * ‘THIS_IMAGE’:    THIS_IMAGE, Cosubscript index of this image
! * ‘TIME’:          TIME,      Time function
! * ‘TIME8’:         TIME8,     Time function (64-bit)
! * ‘TINY’:          TINY,      Smallest positive number of a real kind
! * ‘TRAILZ’:        TRAILZ,    Number of trailing zero bits of an integer
! * ‘TRANSFER’:      TRANSFER,  Transfer bit patterns
! * ‘TRANSPOSE’:     TRANSPOSE, Transpose an array of rank two
! * ‘TRIM’:          TRIM,      Remove trailing blank characters of a string
! * ‘TTYNAM’:        TTYNAM,    Get the name of a terminal device
! * ‘UBOUND’:        UBOUND,    Upper dimension bounds of an array
! * ‘UCOBOUND’:      UCOBOUND,  Upper codimension bounds of an array
! * ‘UMASK’:         UMASK,     Set the file creation mask
! * ‘UNLINK’:        UNLINK,    Remove a file from the file system
! * ‘UNPACK’:        UNPACK,    Unpack an array of rank one into an array
! * ‘VERIFY’:        VERIFY,    Scan a string for the absence of a set of characters
! * ‘XOR’:           XOR,       Bitwise logical exclusive or
  
  
  File: gfortran.info,  Node: Introduction to Intrinsics,  Next: ABORT,  Up: Intrinsic Procedures
*************** intrinsic procedures for backwards compa
*** 7055,7084 ****
  between a description here and a description in the Fortran standards is
  unintentional, and the standard(s) should be considered authoritative.
  
!    The enumeration of the 'KIND' type parameter is processor defined in
  the Fortran 95 standard.  GNU Fortran defines the default integer type
! and default real type by 'INTEGER(KIND=4)' and 'REAL(KIND=4)',
  respectively.  The standard mandates that both data types shall have
  another kind, which have more precision.  On typical target
! architectures supported by 'gfortran', this kind type parameter is
! 'KIND=8'.  Hence, 'REAL(KIND=8)' and 'DOUBLE PRECISION' are equivalent.
  In the description of generic intrinsic procedures, the kind type
! parameter will be specified by 'KIND=*', and in the description of
  specific names for an intrinsic procedure the kind type parameter will
! be explicitly given (e.g., 'REAL(KIND=4)' or 'REAL(KIND=8)').  Finally,
! for brevity the optional 'KIND=' syntax will be omitted.
  
     Many of the intrinsic procedures take one or more optional arguments.
  This document follows the convention used in the Fortran 95 standard,
  and denotes such arguments by square brackets.
  
!    GNU Fortran offers the '-std=' command-line option, which can be used
  to restrict the set of intrinsic procedures to a given standard.  By
! default, 'gfortran' sets the '-std=gnu' option, and so all intrinsic
  procedures described here are accepted.  There is one caveat.  For a
! select group of intrinsic procedures, 'g77' implemented both a function
! and a subroutine.  Both classes have been implemented in 'gfortran' for
! backwards compatibility with 'g77'.  It is noted here that these
  functions and subroutines cannot be intermixed in a given subprogram.
  In the descriptions that follow, the applicable standard for each
  intrinsic procedure is noted.
--- 7055,7084 ----
  between a description here and a description in the Fortran standards is
  unintentional, and the standard(s) should be considered authoritative.
  
!    The enumeration of the ‘KIND’ type parameter is processor defined in
  the Fortran 95 standard.  GNU Fortran defines the default integer type
! and default real type by ‘INTEGER(KIND=4)’ and ‘REAL(KIND=4)’,
  respectively.  The standard mandates that both data types shall have
  another kind, which have more precision.  On typical target
! architectures supported by ‘gfortran’, this kind type parameter is
! ‘KIND=8’.  Hence, ‘REAL(KIND=8)’ and ‘DOUBLE PRECISION’ are equivalent.
  In the description of generic intrinsic procedures, the kind type
! parameter will be specified by ‘KIND=*’, and in the description of
  specific names for an intrinsic procedure the kind type parameter will
! be explicitly given (e.g., ‘REAL(KIND=4)’ or ‘REAL(KIND=8)’).  Finally,
! for brevity the optional ‘KIND=’ syntax will be omitted.
  
     Many of the intrinsic procedures take one or more optional arguments.
  This document follows the convention used in the Fortran 95 standard,
  and denotes such arguments by square brackets.
  
!    GNU Fortran offers the ‘-std=’ command-line option, which can be used
  to restrict the set of intrinsic procedures to a given standard.  By
! default, ‘gfortran’ sets the ‘-std=gnu’ option, and so all intrinsic
  procedures described here are accepted.  There is one caveat.  For a
! select group of intrinsic procedures, ‘g77’ implemented both a function
! and a subroutine.  Both classes have been implemented in ‘gfortran’ for
! backwards compatibility with ‘g77’.  It is noted here that these
  functions and subroutines cannot be intermixed in a given subprogram.
  In the descriptions that follow, the applicable standard for each
  intrinsic procedure is noted.
*************** intrinsic procedure is noted.
*** 7086,7098 ****
  
  File: gfortran.info,  Node: ABORT,  Next: ABS,  Prev: Introduction to Intrinsics,  Up: Intrinsic Procedures
  
! 8.2 'ABORT' -- Abort the program
  ================================
  
  _Description_:
!      'ABORT' causes immediate termination of the program.  On operating
!      systems that support a core dump, 'ABORT' will produce a core dump.
!      It will also print a backtrace, unless '-fno-backtrace' is given.
  
  _Standard_:
       GNU extension
--- 7086,7098 ----
  
  File: gfortran.info,  Node: ABORT,  Next: ABS,  Prev: Introduction to Intrinsics,  Up: Intrinsic Procedures
  
! 8.2 ‘ABORT’ -- Abort the program
  ================================
  
  _Description_:
!      ‘ABORT’ causes immediate termination of the program.  On operating
!      systems that support a core dump, ‘ABORT’ will produce a core dump.
!      It will also print a backtrace, unless ‘-fno-backtrace’ is given.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 7101,7107 ****
       Subroutine
  
  _Syntax_:
!      'CALL ABORT'
  
  _Return value_:
       Does not return.
--- 7101,7107 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL ABORT’
  
  _Return value_:
       Does not return.
*************** _See also_:
*** 7120,7130 ****
  
  File: gfortran.info,  Node: ABS,  Next: ACCESS,  Prev: ABORT,  Up: Intrinsic Procedures
  
! 8.3 'ABS' -- Absolute value
  ===========================
  
  _Description_:
!      'ABS(A)' computes the absolute value of 'A'.
  
  _Standard_:
       Fortran 77 and later, has overloads that are GNU extensions
--- 7120,7130 ----
  
  File: gfortran.info,  Node: ABS,  Next: ACCESS,  Prev: ABORT,  Up: Intrinsic Procedures
  
! 8.3 ‘ABS’ -- Absolute value
  ===========================
  
  _Description_:
!      ‘ABS(A)’ computes the absolute value of ‘A’.
  
  _Standard_:
       Fortran 77 and later, has overloads that are GNU extensions
*************** _Class_:
*** 7133,7147 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ABS(A)'
  
  _Arguments_:
!      A           The type of the argument shall be an 'INTEGER',
!                  'REAL', or 'COMPLEX'.
  
  _Return value_:
       The return value is of the same type and kind as the argument
!      except the return value is 'REAL' for a 'COMPLEX' argument.
  
  _Example_:
            program test_abs
--- 7133,7147 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ABS(A)’
  
  _Arguments_:
!      A           The type of the argument shall be an ‘INTEGER’,
!                  ‘REAL’, or ‘COMPLEX’.
  
  _Return value_:
       The return value is of the same type and kind as the argument
!      except the return value is ‘REAL’ for a ‘COMPLEX’ argument.
  
  _Example_:
            program test_abs
*************** _Example_:
*** 7156,7182 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ABS(A)'       'REAL(4) A'       'REAL(4)'      Fortran 77 and later
!      'CABS(A)'      'COMPLEX(4) A'    'REAL(4)'      Fortran 77 and later
!      'DABS(A)'      'REAL(8) A'       'REAL(8)'      Fortran 77 and later
!      'IABS(A)'      'INTEGER(4) A'    'INTEGER(4)'   Fortran 77 and later
!      'BABS(A)'      'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'IIABS(A)'     'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JIABS(A)'     'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KIABS(A)'     'INTEGER(8) A'    'INTEGER(8)'   GNU extension
!      'ZABS(A)'      'COMPLEX(8) A'    'REAL(8)'      GNU extension
!      'CDABS(A)'     'COMPLEX(8) A'    'REAL(8)'      GNU extension
  
  
  File: gfortran.info,  Node: ACCESS,  Next: ACHAR,  Prev: ABS,  Up: Intrinsic Procedures
  
! 8.4 'ACCESS' -- Checks file access modes
  ========================================
  
  _Description_:
!      'ACCESS(NAME, MODE)' checks whether the file NAME exists, is
       readable, writable or executable.  Except for the executable check,
!      'ACCESS' can be replaced by Fortran 95's 'INQUIRE'.
  
  _Standard_:
       GNU extension
--- 7156,7182 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ABS(A)’       ‘REAL(4) A’       ‘REAL(4)’      Fortran 77 and later
!      ‘CABS(A)’      ‘COMPLEX(4) A’    ‘REAL(4)’      Fortran 77 and later
!      ‘DABS(A)’      ‘REAL(8) A’       ‘REAL(8)’      Fortran 77 and later
!      ‘IABS(A)’      ‘INTEGER(4) A’    ‘INTEGER(4)’   Fortran 77 and later
!      ‘BABS(A)’      ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘IIABS(A)’     ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JIABS(A)’     ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KIABS(A)’     ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
!      ‘ZABS(A)’      ‘COMPLEX(8) A’    ‘REAL(8)’      GNU extension
!      ‘CDABS(A)’     ‘COMPLEX(8) A’    ‘REAL(8)’      GNU extension
  
  
  File: gfortran.info,  Node: ACCESS,  Next: ACHAR,  Prev: ABS,  Up: Intrinsic Procedures
  
! 8.4 ‘ACCESS’ -- Checks file access modes
  ========================================
  
  _Description_:
!      ‘ACCESS(NAME, MODE)’ checks whether the file NAME exists, is
       readable, writable or executable.  Except for the executable check,
!      ‘ACCESS’ can be replaced by Fortran 95's ‘INQUIRE’.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 7185,7207 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = ACCESS(NAME, MODE)'
  
  _Arguments_:
!      NAME        Scalar 'CHARACTER' of default kind with the file
                   name.  Trailing blank are ignored unless the
!                  character 'achar(0)' is present, then all
!                  characters up to and excluding 'achar(0)' are
                   used as file name.
!      MODE        Scalar 'CHARACTER' of default kind with the file
!                  access mode, may be any concatenation of '"r"'
!                  (readable), '"w"' (writable) and '"x"'
!                  (executable), or '" "' to check for existence.
  
  _Return value_:
!      Returns a scalar 'INTEGER', which is '0' if the file is accessible
       in the given mode; otherwise or if an invalid argument has been
!      given for 'MODE' the value '1' is returned.
  
  _Example_:
            program access_test
--- 7185,7207 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = ACCESS(NAME, MODE)’
  
  _Arguments_:
!      NAME        Scalar ‘CHARACTER’ of default kind with the file
                   name.  Trailing blank are ignored unless the
!                  character ‘achar(0)’ is present, then all
!                  characters up to and excluding ‘achar(0)’ are
                   used as file name.
!      MODE        Scalar ‘CHARACTER’ of default kind with the file
!                  access mode, may be any concatenation of ‘"r"’
!                  (readable), ‘"w"’ (writable) and ‘"x"’
!                  (executable), or ‘" "’ to check for existence.
  
  _Return value_:
!      Returns a scalar ‘INTEGER’, which is ‘0’ if the file is accessible
       in the given mode; otherwise or if an invalid argument has been
!      given for ‘MODE’ the value ‘1’ is returned.
  
  _Example_:
            program access_test
*************** _Example_:
*** 7219,7229 ****
  
  File: gfortran.info,  Node: ACHAR,  Next: ACOS,  Prev: ACCESS,  Up: Intrinsic Procedures
  
! 8.5 'ACHAR' -- Character in ASCII collating sequence
  ====================================================
  
  _Description_:
!      'ACHAR(I)' returns the character located at position 'I' in the
       ASCII collating sequence.
  
  _Standard_:
--- 7219,7229 ----
  
  File: gfortran.info,  Node: ACHAR,  Next: ACOS,  Prev: ACCESS,  Up: Intrinsic Procedures
  
! 8.5 ‘ACHAR’ -- Character in ASCII collating sequence
  ====================================================
  
  _Description_:
!      ‘ACHAR(I)’ returns the character located at position ‘I’ in the
       ASCII collating sequence.
  
  _Standard_:
*************** _Class_:
*** 7233,7248 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ACHAR(I [, KIND])'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'CHARACTER' with a length of one.  If
       the KIND argument is present, the return value is of the specified
       kind and of the default kind otherwise.
  
--- 7233,7248 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ACHAR(I [, KIND])’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘CHARACTER’ with a length of one.  If
       the KIND argument is present, the return value is of the specified
       kind and of the default kind otherwise.
  
*************** _See also_:
*** 7264,7274 ****
  
  File: gfortran.info,  Node: ACOS,  Next: ACOSD,  Prev: ACHAR,  Up: Intrinsic Procedures
  
! 8.6 'ACOS' -- Arccosine function
  ================================
  
  _Description_:
!      'ACOS(X)' computes the arccosine of X (inverse of 'COS(X)').
  
  _Standard_:
       Fortran 77 and later, for a complex argument Fortran 2008 or later
--- 7264,7274 ----
  
  File: gfortran.info,  Node: ACOS,  Next: ACOSD,  Prev: ACHAR,  Up: Intrinsic Procedures
  
! 8.6 ‘ACOS’ -- Arccosine function
  ================================
  
  _Description_:
!      ‘ACOS(X)’ computes the arccosine of X (inverse of ‘COS(X)’).
  
  _Standard_:
       Fortran 77 and later, for a complex argument Fortran 2008 or later
*************** _Class_:
*** 7277,7288 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ACOS(X)'
  
  _Arguments_:
!      X           The type shall either be 'REAL' with a magnitude
                   that is less than or equal to one - or the type
!                  shall be 'COMPLEX'.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
--- 7277,7288 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ACOS(X)’
  
  _Arguments_:
!      X           The type shall either be ‘REAL’ with a magnitude
                   that is less than or equal to one - or the type
!                  shall be ‘COMPLEX’.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
*************** _Example_:
*** 7298,7305 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ACOS(X)'      'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DACOS(X)'     'REAL(8) X'       'REAL(8)'      Fortran 77 and later
  
  _See also_:
       Inverse function:
--- 7298,7305 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ACOS(X)’      ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DACOS(X)’     ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 7310,7338 ****
  
  File: gfortran.info,  Node: ACOSD,  Next: ACOSH,  Prev: ACOS,  Up: Intrinsic Procedures
  
! 8.7 'ACOSD' -- Arccosine function, degrees
  ==========================================
  
  _Description_:
!      'ACOSD(X)' computes the arccosine of X in degrees (inverse of
!      'COSD(X)').
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with '-fdec-math'
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      'RESULT = ACOSD(X)'
  
  _Arguments_:
!      X           The type shall either be 'REAL' with a magnitude
                   that is less than or equal to one - or the type
!                  shall be 'COMPLEX'.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
--- 7310,7338 ----
  
  File: gfortran.info,  Node: ACOSD,  Next: ACOSH,  Prev: ACOS,  Up: Intrinsic Procedures
  
! 8.7 ‘ACOSD’ -- Arccosine function, degrees
  ==========================================
  
  _Description_:
!      ‘ACOSD(X)’ computes the arccosine of X in degrees (inverse of
!      ‘COSD(X)’).
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with ‘-fdec-math’
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ACOSD(X)’
  
  _Arguments_:
!      X           The type shall either be ‘REAL’ with a magnitude
                   that is less than or equal to one - or the type
!                  shall be ‘COMPLEX’.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
*************** _Example_:
*** 7348,7355 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ACOSD(X)'     'REAL(4) X'       'REAL(4)'      GNU extension
!      'DACOSD(X)'    'REAL(8) X'       'REAL(8)'      GNU extension
  
  _See also_:
       Inverse function:
--- 7348,7355 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ACOSD(X)’     ‘REAL(4) X’       ‘REAL(4)’      GNU extension
!      ‘DACOSD(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 7360,7370 ****
  
  File: gfortran.info,  Node: ACOSH,  Next: ADJUSTL,  Prev: ACOSD,  Up: Intrinsic Procedures
  
! 8.8 'ACOSH' -- Inverse hyperbolic cosine function
  =================================================
  
  _Description_:
!      'ACOSH(X)' computes the inverse hyperbolic cosine of X.
  
  _Standard_:
       Fortran 2008 and later
--- 7360,7370 ----
  
  File: gfortran.info,  Node: ACOSH,  Next: ADJUSTL,  Prev: ACOSD,  Up: Intrinsic Procedures
  
! 8.8 ‘ACOSH’ -- Inverse hyperbolic cosine function
  =================================================
  
  _Description_:
!      ‘ACOSH(X)’ computes the inverse hyperbolic cosine of X.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 7373,7382 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ACOSH(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has the same type and kind as X.  If X is complex,
--- 7373,7382 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ACOSH(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has the same type and kind as X.  If X is complex,
*************** _Example_:
*** 7392,7398 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DACOSH(X)'    'REAL(8) X'       'REAL(8)'      GNU extension
  
  _See also_:
       Inverse function:
--- 7392,7398 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DACOSH(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 7401,7411 ****
  
  File: gfortran.info,  Node: ADJUSTL,  Next: ADJUSTR,  Prev: ACOSH,  Up: Intrinsic Procedures
  
! 8.9 'ADJUSTL' -- Left adjust a string
  =====================================
  
  _Description_:
!      'ADJUSTL(STRING)' will left adjust a string by removing leading
       spaces.  Spaces are inserted at the end of the string as needed.
  
  _Standard_:
--- 7401,7411 ----
  
  File: gfortran.info,  Node: ADJUSTL,  Next: ADJUSTR,  Prev: ACOSH,  Up: Intrinsic Procedures
  
! 8.9 ‘ADJUSTL’ -- Left adjust a string
  =====================================
  
  _Description_:
!      ‘ADJUSTL(STRING)’ will left adjust a string by removing leading
       spaces.  Spaces are inserted at the end of the string as needed.
  
  _Standard_:
*************** _Class_:
*** 7415,7427 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ADJUSTL(STRING)'
  
  _Arguments_:
!      STRING      The type shall be 'CHARACTER'.
  
  _Return value_:
!      The return value is of type 'CHARACTER' and of the same kind as
       STRING where leading spaces are removed and the same number of
       spaces are inserted on the end of STRING.
  
--- 7415,7427 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ADJUSTL(STRING)’
  
  _Arguments_:
!      STRING      The type shall be ‘CHARACTER’.
  
  _Return value_:
!      The return value is of type ‘CHARACTER’ and of the same kind as
       STRING where leading spaces are removed and the same number of
       spaces are inserted on the end of STRING.
  
*************** _See also_:
*** 7439,7449 ****
  
  File: gfortran.info,  Node: ADJUSTR,  Next: AIMAG,  Prev: ADJUSTL,  Up: Intrinsic Procedures
  
! 8.10 'ADJUSTR' -- Right adjust a string
  =======================================
  
  _Description_:
!      'ADJUSTR(STRING)' will right adjust a string by removing trailing
       spaces.  Spaces are inserted at the start of the string as needed.
  
  _Standard_:
--- 7439,7449 ----
  
  File: gfortran.info,  Node: ADJUSTR,  Next: AIMAG,  Prev: ADJUSTL,  Up: Intrinsic Procedures
  
! 8.10 ‘ADJUSTR’ -- Right adjust a string
  =======================================
  
  _Description_:
!      ‘ADJUSTR(STRING)’ will right adjust a string by removing trailing
       spaces.  Spaces are inserted at the start of the string as needed.
  
  _Standard_:
*************** _Class_:
*** 7453,7465 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ADJUSTR(STRING)'
  
  _Arguments_:
!      STR         The type shall be 'CHARACTER'.
  
  _Return value_:
!      The return value is of type 'CHARACTER' and of the same kind as
       STRING where trailing spaces are removed and the same number of
       spaces are inserted at the start of STRING.
  
--- 7453,7465 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ADJUSTR(STRING)’
  
  _Arguments_:
!      STR         The type shall be ‘CHARACTER’.
  
  _Return value_:
!      The return value is of type ‘CHARACTER’ and of the same kind as
       STRING where trailing spaces are removed and the same number of
       spaces are inserted at the start of STRING.
  
*************** _See also_:
*** 7477,7489 ****
  
  File: gfortran.info,  Node: AIMAG,  Next: AINT,  Prev: ADJUSTR,  Up: Intrinsic Procedures
  
! 8.11 'AIMAG' -- Imaginary part of complex number
  ================================================
  
  _Description_:
!      'AIMAG(Z)' yields the imaginary part of complex argument 'Z'.  The
!      'IMAG(Z)' and 'IMAGPART(Z)' intrinsic functions are provided for
!      compatibility with 'g77', and their use in new code is strongly
       discouraged.
  
  _Standard_:
--- 7477,7489 ----
  
  File: gfortran.info,  Node: AIMAG,  Next: AINT,  Prev: ADJUSTR,  Up: Intrinsic Procedures
  
! 8.11 ‘AIMAG’ -- Imaginary part of complex number
  ================================================
  
  _Description_:
!      ‘AIMAG(Z)’ yields the imaginary part of complex argument ‘Z’.  The
!      ‘IMAG(Z)’ and ‘IMAGPART(Z)’ intrinsic functions are provided for
!      compatibility with ‘g77’, and their use in new code is strongly
       discouraged.
  
  _Standard_:
*************** _Class_:
*** 7493,7505 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = AIMAG(Z)'
  
  _Arguments_:
!      Z           The type of the argument shall be 'COMPLEX'.
  
  _Return value_:
!      The return value is of type 'REAL' with the kind type parameter of
       the argument.
  
  _Example_:
--- 7493,7505 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = AIMAG(Z)’
  
  _Arguments_:
!      Z           The type of the argument shall be ‘COMPLEX’.
  
  _Return value_:
!      The return value is of type ‘REAL’ with the kind type parameter of
       the argument.
  
  _Example_:
*************** _Example_:
*** 7514,7532 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'AIMAG(Z)'     'COMPLEX Z'       'REAL'         Fortran 77 and later
!      'DIMAG(Z)'     'COMPLEX(8) Z'    'REAL(8)'      GNU extension
!      'IMAG(Z)'      'COMPLEX Z'       'REAL'         GNU extension
!      'IMAGPART(Z)'  'COMPLEX Z'       'REAL'         GNU extension
  
  
  File: gfortran.info,  Node: AINT,  Next: ALARM,  Prev: AIMAG,  Up: Intrinsic Procedures
  
! 8.12 'AINT' -- Truncate to a whole number
  =========================================
  
  _Description_:
!      'AINT(A [, KIND])' truncates its argument to a whole number.
  
  _Standard_:
       Fortran 77 and later
--- 7514,7532 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘AIMAG(Z)’     ‘COMPLEX Z’       ‘REAL’         Fortran 77 and later
!      ‘DIMAG(Z)’     ‘COMPLEX(8) Z’    ‘REAL(8)’      GNU extension
!      ‘IMAG(Z)’      ‘COMPLEX Z’       ‘REAL’         GNU extension
!      ‘IMAGPART(Z)’  ‘COMPLEX Z’       ‘REAL’         GNU extension
  
  
  File: gfortran.info,  Node: AINT,  Next: ALARM,  Prev: AIMAG,  Up: Intrinsic Procedures
  
! 8.12 ‘AINT’ -- Truncate to a whole number
  =========================================
  
  _Description_:
!      ‘AINT(A [, KIND])’ truncates its argument to a whole number.
  
  _Standard_:
       Fortran 77 and later
*************** _Class_:
*** 7535,7553 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = AINT(A [, KIND])'
  
  _Arguments_:
!      A           The type of the argument shall be 'REAL'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'REAL' with the kind type parameter of
       the argument if the optional KIND is absent; otherwise, the kind
       type parameter will be given by KIND.  If the magnitude of X is
!      less than one, 'AINT(X)' returns zero.  If the magnitude is equal
       to or greater than one then it returns the largest whole number
       that does not exceed its magnitude.  The sign is the same as the
       sign of X.
--- 7535,7553 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = AINT(A [, KIND])’
  
  _Arguments_:
!      A           The type of the argument shall be ‘REAL’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘REAL’ with the kind type parameter of
       the argument if the optional KIND is absent; otherwise, the kind
       type parameter will be given by KIND.  If the magnitude of X is
!      less than one, ‘AINT(X)’ returns zero.  If the magnitude is equal
       to or greater than one then it returns the largest whole number
       that does not exceed its magnitude.  The sign is the same as the
       sign of X.
*************** _Example_:
*** 7565,7583 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'AINT(A)'      'REAL(4) A'       'REAL(4)'      Fortran 77 and later
!      'DINT(A)'      'REAL(8) A'       'REAL(8)'      Fortran 77 and later
  
  
  File: gfortran.info,  Node: ALARM,  Next: ALL,  Prev: AINT,  Up: Intrinsic Procedures
  
! 8.13 'ALARM' -- Execute a routine after a given delay
  =====================================================
  
  _Description_:
!      'ALARM(SECONDS, HANDLER [, STATUS])' causes external subroutine
!      HANDLER to be executed after a delay of SECONDS by using 'alarm(2)'
!      to set up a signal and 'signal(2)' to catch it.  If STATUS is
       supplied, it will be returned with the number of seconds remaining
       until any previously scheduled alarm was due to be delivered, or
       zero if there was no previously scheduled alarm.
--- 7565,7583 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘AINT(A)’      ‘REAL(4) A’       ‘REAL(4)’      Fortran 77 and later
!      ‘DINT(A)’      ‘REAL(8) A’       ‘REAL(8)’      Fortran 77 and later
  
  
  File: gfortran.info,  Node: ALARM,  Next: ALL,  Prev: AINT,  Up: Intrinsic Procedures
  
! 8.13 ‘ALARM’ -- Execute a routine after a given delay
  =====================================================
  
  _Description_:
!      ‘ALARM(SECONDS, HANDLER [, STATUS])’ causes external subroutine
!      HANDLER to be executed after a delay of SECONDS by using ‘alarm(2)’
!      to set up a signal and ‘signal(2)’ to catch it.  If STATUS is
       supplied, it will be returned with the number of seconds remaining
       until any previously scheduled alarm was due to be delivered, or
       zero if there was no previously scheduled alarm.
*************** _Class_:
*** 7589,7607 ****
       Subroutine
  
  _Syntax_:
!      'CALL ALARM(SECONDS, HANDLER [, STATUS])'
  
  _Arguments_:
       SECONDS     The type of the argument shall be a scalar
!                  'INTEGER'.  It is 'INTENT(IN)'.
!      HANDLER     Signal handler ('INTEGER FUNCTION' or
!                  'SUBROUTINE') or dummy/global 'INTEGER' scalar.
!                  The scalar values may be either 'SIG_IGN=1' to
!                  ignore the alarm generated or 'SIG_DFL=0' to set
!                  the default action.  It is 'INTENT(IN)'.
       STATUS      (Optional) STATUS shall be a scalar variable of
!                  the default 'INTEGER' kind.  It is
!                  'INTENT(OUT)'.
  
  _Example_:
            program test_alarm
--- 7589,7607 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL ALARM(SECONDS, HANDLER [, STATUS])’
  
  _Arguments_:
       SECONDS     The type of the argument shall be a scalar
!                  ‘INTEGER’.  It is ‘INTENT(IN)’.
!      HANDLER     Signal handler (‘INTEGER FUNCTION’ or
!                  ‘SUBROUTINE’) or dummy/global ‘INTEGER’ scalar.
!                  The scalar values may be either ‘SIG_IGN=1’ to
!                  ignore the alarm generated or ‘SIG_DFL=0’ to set
!                  the default action.  It is ‘INTENT(IN)’.
       STATUS      (Optional) STATUS shall be a scalar variable of
!                  the default ‘INTEGER’ kind.  It is
!                  ‘INTENT(OUT)’.
  
  _Example_:
            program test_alarm
*************** _Example_:
*** 7617,7627 ****
  
  File: gfortran.info,  Node: ALL,  Next: ALLOCATED,  Prev: ALARM,  Up: Intrinsic Procedures
  
! 8.14 'ALL' -- All values in MASK along DIM are true
  ===================================================
  
  _Description_:
!      'ALL(MASK [, DIM])' determines if all the values are true in MASK
       in the array along dimension DIM.
  
  _Standard_:
--- 7617,7627 ----
  
  File: gfortran.info,  Node: ALL,  Next: ALLOCATED,  Prev: ALARM,  Up: Intrinsic Procedures
  
! 8.14 ‘ALL’ -- All values in MASK along DIM are true
  ===================================================
  
  _Description_:
!      ‘ALL(MASK [, DIM])’ determines if all the values are true in MASK
       in the array along dimension DIM.
  
  _Standard_:
*************** _Class_:
*** 7631,7659 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = ALL(MASK [, DIM])'
  
  _Arguments_:
!      MASK        The type of the argument shall be 'LOGICAL' and
                   it shall not be scalar.
       DIM         (Optional) DIM shall be a scalar integer with a
                   value that lies between one and the rank of
                   MASK.
  
  _Return value_:
!      'ALL(MASK)' returns a scalar value of type 'LOGICAL' where the kind
       type parameter is the same as the kind type parameter of MASK.  If
!      DIM is present, then 'ALL(MASK, DIM)' returns an array with the
       rank of MASK minus 1.  The shape is determined from the shape of
       MASK where the DIM dimension is elided.
  
       (A)
!           'ALL(MASK)' is true if all elements of MASK are true.  It also
            is true if MASK has zero size; otherwise, it is false.
       (B)
!           If the rank of MASK is one, then 'ALL(MASK,DIM)' is equivalent
!           to 'ALL(MASK)'.  If the rank is greater than one, then
!           'ALL(MASK,DIM)' is determined by applying 'ALL' to the array
            sections.
  
  _Example_:
--- 7631,7659 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = ALL(MASK [, DIM])’
  
  _Arguments_:
!      MASK        The type of the argument shall be ‘LOGICAL’ and
                   it shall not be scalar.
       DIM         (Optional) DIM shall be a scalar integer with a
                   value that lies between one and the rank of
                   MASK.
  
  _Return value_:
!      ‘ALL(MASK)’ returns a scalar value of type ‘LOGICAL’ where the kind
       type parameter is the same as the kind type parameter of MASK.  If
!      DIM is present, then ‘ALL(MASK, DIM)’ returns an array with the
       rank of MASK minus 1.  The shape is determined from the shape of
       MASK where the DIM dimension is elided.
  
       (A)
!           ‘ALL(MASK)’ is true if all elements of MASK are true.  It also
            is true if MASK has zero size; otherwise, it is false.
       (B)
!           If the rank of MASK is one, then ‘ALL(MASK,DIM)’ is equivalent
!           to ‘ALL(MASK)’.  If the rank is greater than one, then
!           ‘ALL(MASK,DIM)’ is determined by applying ‘ALL’ to the array
            sections.
  
  _Example_:
*************** _Example_:
*** 7676,7707 ****
  
  File: gfortran.info,  Node: ALLOCATED,  Next: AND,  Prev: ALL,  Up: Intrinsic Procedures
  
! 8.15 'ALLOCATED' -- Status of an allocatable entity
  ===================================================
  
  _Description_:
!      'ALLOCATED(ARRAY)' and 'ALLOCATED(SCALAR)' check the allocation
       status of ARRAY and SCALAR, respectively.
  
  _Standard_:
!      Fortran 90 and later.  Note, the 'SCALAR=' keyword and allocatable
       scalar entities are available in Fortran 2003 and later.
  
  _Class_:
       Inquiry function
  
  _Syntax_:
!      'RESULT = ALLOCATED(ARRAY)'
!      'RESULT = ALLOCATED(SCALAR)'
  
  _Arguments_:
!      ARRAY       The argument shall be an 'ALLOCATABLE' array.
!      SCALAR      The argument shall be an 'ALLOCATABLE' scalar.
  
  _Return value_:
!      The return value is a scalar 'LOGICAL' with the default logical
       kind type parameter.  If the argument is allocated, then the result
!      is '.TRUE.'; otherwise, it returns '.FALSE.'
  
  _Example_:
            program test_allocated
--- 7676,7707 ----
  
  File: gfortran.info,  Node: ALLOCATED,  Next: AND,  Prev: ALL,  Up: Intrinsic Procedures
  
! 8.15 ‘ALLOCATED’ -- Status of an allocatable entity
  ===================================================
  
  _Description_:
!      ‘ALLOCATED(ARRAY)’ and ‘ALLOCATED(SCALAR)’ check the allocation
       status of ARRAY and SCALAR, respectively.
  
  _Standard_:
!      Fortran 90 and later.  Note, the ‘SCALAR=’ keyword and allocatable
       scalar entities are available in Fortran 2003 and later.
  
  _Class_:
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = ALLOCATED(ARRAY)’
!      ‘RESULT = ALLOCATED(SCALAR)’
  
  _Arguments_:
!      ARRAY       The argument shall be an ‘ALLOCATABLE’ array.
!      SCALAR      The argument shall be an ‘ALLOCATABLE’ scalar.
  
  _Return value_:
!      The return value is a scalar ‘LOGICAL’ with the default logical
       kind type parameter.  If the argument is allocated, then the result
!      is ‘.TRUE.’; otherwise, it returns ‘.FALSE.’
  
  _Example_:
            program test_allocated
*************** _Example_:
*** 7713,7723 ****
  
  File: gfortran.info,  Node: AND,  Next: ANINT,  Prev: ALLOCATED,  Up: Intrinsic Procedures
  
! 8.16 'AND' -- Bitwise logical AND
  =================================
  
  _Description_:
!      Bitwise logical 'AND'.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  For integer arguments, programmers should consider
--- 7713,7723 ----
  
  File: gfortran.info,  Node: AND,  Next: ANINT,  Prev: ALLOCATED,  Up: Intrinsic Procedures
  
! 8.16 ‘AND’ -- Bitwise logical AND
  =================================
  
  _Description_:
!      Bitwise logical ‘AND’.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  For integer arguments, programmers should consider
*************** _Class_:
*** 7731,7753 ****
       Function
  
  _Syntax_:
!      'RESULT = AND(I, J)'
  
  _Arguments_:
!      I           The type shall be either a scalar 'INTEGER' type
!                  or a scalar 'LOGICAL' type or a
                   boz-literal-constant.
       J           The type shall be the same as the type of I or a
                   boz-literal-constant.  I and J shall not both be
                   boz-literal-constants.  If either I or J is a
                   boz-literal-constant, then the other argument
!                  must be a scalar 'INTEGER'.
  
  _Return value_:
!      The return type is either a scalar 'INTEGER' or a scalar 'LOGICAL'.
       If the kind type parameters differ, then the smaller kind type is
       implicitly converted to larger kind, and the return has the larger
!      kind.  A boz-literal-constant is converted to an 'INTEGER' with the
       kind type parameter of the other argument as-if a call to *note
       INT:: occurred.
  
--- 7731,7753 ----
       Function
  
  _Syntax_:
!      ‘RESULT = AND(I, J)’
  
  _Arguments_:
!      I           The type shall be either a scalar ‘INTEGER’ type
!                  or a scalar ‘LOGICAL’ type or a
                   boz-literal-constant.
       J           The type shall be the same as the type of I or a
                   boz-literal-constant.  I and J shall not both be
                   boz-literal-constants.  If either I or J is a
                   boz-literal-constant, then the other argument
!                  must be a scalar ‘INTEGER’.
  
  _Return value_:
!      The return type is either a scalar ‘INTEGER’ or a scalar ‘LOGICAL’.
       If the kind type parameters differ, then the smaller kind type is
       implicitly converted to larger kind, and the return has the larger
!      kind.  A boz-literal-constant is converted to an ‘INTEGER’ with the
       kind type parameter of the other argument as-if a call to *note
       INT:: occurred.
  
*************** _See also_:
*** 7768,7778 ****
  
  File: gfortran.info,  Node: ANINT,  Next: ANY,  Prev: AND,  Up: Intrinsic Procedures
  
! 8.17 'ANINT' -- Nearest whole number
  ====================================
  
  _Description_:
!      'ANINT(A [, KIND])' rounds its argument to the nearest whole
       number.
  
  _Standard_:
--- 7768,7778 ----
  
  File: gfortran.info,  Node: ANINT,  Next: ANY,  Prev: AND,  Up: Intrinsic Procedures
  
! 8.17 ‘ANINT’ -- Nearest whole number
  ====================================
  
  _Description_:
!      ‘ANINT(A [, KIND])’ rounds its argument to the nearest whole
       number.
  
  _Standard_:
*************** _Class_:
*** 7782,7792 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ANINT(A [, KIND])'
  
  _Arguments_:
!      A           The type of the argument shall be 'REAL'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
--- 7782,7792 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ANINT(A [, KIND])’
  
  _Arguments_:
!      A           The type of the argument shall be ‘REAL’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
*************** _Return value_:
*** 7794,7801 ****
       The return value is of type real with the kind type parameter of
       the argument if the optional KIND is absent; otherwise, the kind
       type parameter will be given by KIND.  If A is greater than zero,
!      'ANINT(A)' returns 'AINT(X+0.5)'.  If A is less than or equal to
!      zero then it returns 'AINT(X-0.5)'.
  
  _Example_:
            program test_anint
--- 7794,7801 ----
       The return value is of type real with the kind type parameter of
       the argument if the optional KIND is absent; otherwise, the kind
       type parameter will be given by KIND.  If A is greater than zero,
!      ‘ANINT(A)’ returns ‘AINT(X+0.5)’.  If A is less than or equal to
!      zero then it returns ‘AINT(X-0.5)’.
  
  _Example_:
            program test_anint
*************** _Example_:
*** 7810,7827 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ANINT(A)'     'REAL(4) A'       'REAL(4)'      Fortran 77 and later
!      'DNINT(A)'     'REAL(8) A'       'REAL(8)'      Fortran 77 and later
  
  
  File: gfortran.info,  Node: ANY,  Next: ASIN,  Prev: ANINT,  Up: Intrinsic Procedures
  
! 8.18 'ANY' -- Any value in MASK along DIM is true
  =================================================
  
  _Description_:
!      'ANY(MASK [, DIM])' determines if any of the values in the logical
!      array MASK along dimension DIM are '.TRUE.'.
  
  _Standard_:
       Fortran 90 and later
--- 7810,7827 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ANINT(A)’     ‘REAL(4) A’       ‘REAL(4)’      Fortran 77 and later
!      ‘DNINT(A)’     ‘REAL(8) A’       ‘REAL(8)’      Fortran 77 and later
  
  
  File: gfortran.info,  Node: ANY,  Next: ASIN,  Prev: ANINT,  Up: Intrinsic Procedures
  
! 8.18 ‘ANY’ -- Any value in MASK along DIM is true
  =================================================
  
  _Description_:
!      ‘ANY(MASK [, DIM])’ determines if any of the values in the logical
!      array MASK along dimension DIM are ‘.TRUE.’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 7830,7858 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = ANY(MASK [, DIM])'
  
  _Arguments_:
!      MASK        The type of the argument shall be 'LOGICAL' and
                   it shall not be scalar.
       DIM         (Optional) DIM shall be a scalar integer with a
                   value that lies between one and the rank of
                   MASK.
  
  _Return value_:
!      'ANY(MASK)' returns a scalar value of type 'LOGICAL' where the kind
       type parameter is the same as the kind type parameter of MASK.  If
!      DIM is present, then 'ANY(MASK, DIM)' returns an array with the
       rank of MASK minus 1.  The shape is determined from the shape of
       MASK where the DIM dimension is elided.
  
       (A)
!           'ANY(MASK)' is true if any element of MASK is true; otherwise,
            it is false.  It also is false if MASK has zero size.
       (B)
!           If the rank of MASK is one, then 'ANY(MASK,DIM)' is equivalent
!           to 'ANY(MASK)'.  If the rank is greater than one, then
!           'ANY(MASK,DIM)' is determined by applying 'ANY' to the array
            sections.
  
  _Example_:
--- 7830,7858 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = ANY(MASK [, DIM])’
  
  _Arguments_:
!      MASK        The type of the argument shall be ‘LOGICAL’ and
                   it shall not be scalar.
       DIM         (Optional) DIM shall be a scalar integer with a
                   value that lies between one and the rank of
                   MASK.
  
  _Return value_:
!      ‘ANY(MASK)’ returns a scalar value of type ‘LOGICAL’ where the kind
       type parameter is the same as the kind type parameter of MASK.  If
!      DIM is present, then ‘ANY(MASK, DIM)’ returns an array with the
       rank of MASK minus 1.  The shape is determined from the shape of
       MASK where the DIM dimension is elided.
  
       (A)
!           ‘ANY(MASK)’ is true if any element of MASK is true; otherwise,
            it is false.  It also is false if MASK has zero size.
       (B)
!           If the rank of MASK is one, then ‘ANY(MASK,DIM)’ is equivalent
!           to ‘ANY(MASK)’.  If the rank is greater than one, then
!           ‘ANY(MASK,DIM)’ is determined by applying ‘ANY’ to the array
            sections.
  
  _Example_:
*************** _Example_:
*** 7875,7885 ****
  
  File: gfortran.info,  Node: ASIN,  Next: ASIND,  Prev: ANY,  Up: Intrinsic Procedures
  
! 8.19 'ASIN' -- Arcsine function
  ===============================
  
  _Description_:
!      'ASIN(X)' computes the arcsine of its X (inverse of 'SIN(X)').
  
  _Standard_:
       Fortran 77 and later, for a complex argument Fortran 2008 or later
--- 7875,7885 ----
  
  File: gfortran.info,  Node: ASIN,  Next: ASIND,  Prev: ANY,  Up: Intrinsic Procedures
  
! 8.19 ‘ASIN’ -- Arcsine function
  ===============================
  
  _Description_:
!      ‘ASIN(X)’ computes the arcsine of its X (inverse of ‘SIN(X)’).
  
  _Standard_:
       Fortran 77 and later, for a complex argument Fortran 2008 or later
*************** _Class_:
*** 7888,7899 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ASIN(X)'
  
  _Arguments_:
!      X           The type shall be either 'REAL' and a magnitude
                   that is less than or equal to one - or be
!                  'COMPLEX'.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
--- 7888,7899 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ASIN(X)’
  
  _Arguments_:
!      X           The type shall be either ‘REAL’ and a magnitude
                   that is less than or equal to one - or be
!                  ‘COMPLEX’.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
*************** _Example_:
*** 7909,7916 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ASIN(X)'      'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DASIN(X)'     'REAL(8) X'       'REAL(8)'      Fortran 77 and later
  
  _See also_:
       Inverse function:
--- 7909,7916 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ASIN(X)’      ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DASIN(X)’     ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 7921,7949 ****
  
  File: gfortran.info,  Node: ASIND,  Next: ASINH,  Prev: ASIN,  Up: Intrinsic Procedures
  
! 8.20 'ASIND' -- Arcsine function, degrees
  =========================================
  
  _Description_:
!      'ASIND(X)' computes the arcsine of its X in degrees (inverse of
!      'SIND(X)').
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with '-fdec-math'.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      'RESULT = ASIND(X)'
  
  _Arguments_:
!      X           The type shall be either 'REAL' and a magnitude
                   that is less than or equal to one - or be
!                  'COMPLEX'.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
--- 7921,7949 ----
  
  File: gfortran.info,  Node: ASIND,  Next: ASINH,  Prev: ASIN,  Up: Intrinsic Procedures
  
! 8.20 ‘ASIND’ -- Arcsine function, degrees
  =========================================
  
  _Description_:
!      ‘ASIND(X)’ computes the arcsine of its X in degrees (inverse of
!      ‘SIND(X)’).
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with ‘-fdec-math’.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ASIND(X)’
  
  _Arguments_:
!      X           The type shall be either ‘REAL’ and a magnitude
                   that is less than or equal to one - or be
!                  ‘COMPLEX’.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
*************** _Example_:
*** 7959,7966 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ASIND(X)'     'REAL(4) X'       'REAL(4)'      GNU extension
!      'DASIND(X)'    'REAL(8) X'       'REAL(8)'      GNU extension
  
  _See also_:
       Inverse function:
--- 7959,7966 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ASIND(X)’     ‘REAL(4) X’       ‘REAL(4)’      GNU extension
!      ‘DASIND(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 7971,7981 ****
  
  File: gfortran.info,  Node: ASINH,  Next: ASSOCIATED,  Prev: ASIND,  Up: Intrinsic Procedures
  
! 8.21 'ASINH' -- Inverse hyperbolic sine function
  ================================================
  
  _Description_:
!      'ASINH(X)' computes the inverse hyperbolic sine of X.
  
  _Standard_:
       Fortran 2008 and later
--- 7971,7981 ----
  
  File: gfortran.info,  Node: ASINH,  Next: ASSOCIATED,  Prev: ASIND,  Up: Intrinsic Procedures
  
! 8.21 ‘ASINH’ -- Inverse hyperbolic sine function
  ================================================
  
  _Description_:
!      ‘ASINH(X)’ computes the inverse hyperbolic sine of X.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 7984,7993 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ASINH(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value is of the same type and kind as X.  If X is
--- 7984,7993 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ASINH(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value is of the same type and kind as X.  If X is
*************** _Example_:
*** 8003,8009 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DASINH(X)'    'REAL(8) X'       'REAL(8)'      GNU extension.
  
  _See also_:
       Inverse function:
--- 8003,8009 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DASINH(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension.
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 8012,8022 ****
  
  File: gfortran.info,  Node: ASSOCIATED,  Next: ATAN,  Prev: ASINH,  Up: Intrinsic Procedures
  
! 8.22 'ASSOCIATED' -- Status of a pointer or pointer/target pair
  ===============================================================
  
  _Description_:
!      'ASSOCIATED(POINTER [, TARGET])' determines the status of the
       pointer POINTER or if POINTER is associated with the target TARGET.
  
  _Standard_:
--- 8012,8022 ----
  
  File: gfortran.info,  Node: ASSOCIATED,  Next: ATAN,  Prev: ASINH,  Up: Intrinsic Procedures
  
! 8.22 ‘ASSOCIATED’ -- Status of a pointer or pointer/target pair
  ===============================================================
  
  _Description_:
!      ‘ASSOCIATED(POINTER [, TARGET])’ determines the status of the
       pointer POINTER or if POINTER is associated with the target TARGET.
  
  _Standard_:
*************** _Class_:
*** 8026,8035 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = ASSOCIATED(POINTER [, TARGET])'
  
  _Arguments_:
!      POINTER     POINTER shall have the 'POINTER' attribute and
                   it can be of any type.
       TARGET      (Optional) TARGET shall be a pointer or a
                   target.  It must have the same type, kind type
--- 8026,8035 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = ASSOCIATED(POINTER [, TARGET])’
  
  _Arguments_:
!      POINTER     POINTER shall have the ‘POINTER’ attribute and
                   it can be of any type.
       TARGET      (Optional) TARGET shall be a pointer or a
                   target.  It must have the same type, kind type
*************** _Arguments_:
*** 8038,8047 ****
       undefined.
  
  _Return value_:
!      'ASSOCIATED(POINTER)' returns a scalar value of type 'LOGICAL(4)'.
       There are several cases:
       (A) When the optional TARGET is not present then
!           'ASSOCIATED(POINTER)' is true if POINTER is associated with a
            target; otherwise, it returns false.
       (B) If TARGET is present and a scalar target, the result is true if
            TARGET is not a zero-sized storage sequence and the target
--- 8038,8047 ----
       undefined.
  
  _Return value_:
!      ‘ASSOCIATED(POINTER)’ returns a scalar value of type ‘LOGICAL(4)’.
       There are several cases:
       (A) When the optional TARGET is not present then
!           ‘ASSOCIATED(POINTER)’ is true if POINTER is associated with a
            target; otherwise, it returns false.
       (B) If TARGET is present and a scalar target, the result is true if
            TARGET is not a zero-sized storage sequence and the target
*************** _See also_:
*** 8082,8092 ****
  
  File: gfortran.info,  Node: ATAN,  Next: ATAND,  Prev: ASSOCIATED,  Up: Intrinsic Procedures
  
! 8.23 'ATAN' -- Arctangent function
  ==================================
  
  _Description_:
!      'ATAN(X)' computes the arctangent of X.
  
  _Standard_:
       Fortran 77 and later, for a complex argument and for two arguments
--- 8082,8092 ----
  
  File: gfortran.info,  Node: ATAN,  Next: ATAND,  Prev: ASSOCIATED,  Up: Intrinsic Procedures
  
! 8.23 ‘ATAN’ -- Arctangent function
  ==================================
  
  _Description_:
!      ‘ATAN(X)’ computes the arctangent of X.
  
  _Standard_:
       Fortran 77 and later, for a complex argument and for two arguments
*************** _Class_:
*** 8096,8113 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ATAN(X)'
!      'RESULT = ATAN(Y, X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'; if Y is
                   present, X shall be REAL.
       Y           The type and kind type parameter shall be the
                   same as X.
  
  _Return value_:
       The return value is of the same type and kind as X.  If Y is
!      present, the result is identical to 'ATAN2(Y,X)'.  Otherwise, it
       the arcus tangent of X, where the real part of the result is in
       radians and lies in the range -\pi/2 \leq \Re \atan(x) \leq \pi/2.
  
--- 8096,8113 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ATAN(X)’
!      ‘RESULT = ATAN(Y, X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’; if Y is
                   present, X shall be REAL.
       Y           The type and kind type parameter shall be the
                   same as X.
  
  _Return value_:
       The return value is of the same type and kind as X.  If Y is
!      present, the result is identical to ‘ATAN2(Y,X)’.  Otherwise, it
       the arcus tangent of X, where the real part of the result is in
       radians and lies in the range -\pi/2 \leq \Re \atan(x) \leq \pi/2.
  
*************** _Example_:
*** 8120,8127 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ATAN(X)'      'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DATAN(X)'     'REAL(8) X'       'REAL(8)'      Fortran 77 and later
  
  _See also_:
       Inverse function:
--- 8120,8127 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ATAN(X)’      ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DATAN(X)’     ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 8132,8166 ****
  
  File: gfortran.info,  Node: ATAND,  Next: ATAN2,  Prev: ATAN,  Up: Intrinsic Procedures
  
! 8.24 'ATAND' -- Arctangent function, degrees
  ============================================
  
  _Description_:
!      'ATAND(X)' computes the arctangent of X in degrees (inverse of
       *note TAND::).
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with '-fdec-math'.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      'RESULT = ATAND(X)'
!      'RESULT = ATAND(Y, X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'; if Y is
                   present, X shall be REAL.
       Y           The type and kind type parameter shall be the
                   same as X.
  
  _Return value_:
       The return value is of the same type and kind as X.  If Y is
!      present, the result is identical to 'ATAND2(Y,X)'.  Otherwise, it
       is the arcus tangent of X, where the real part of the result is in
       degrees and lies in the range -90 \leq \Re \atand(x) \leq 90.
  
--- 8132,8166 ----
  
  File: gfortran.info,  Node: ATAND,  Next: ATAN2,  Prev: ATAN,  Up: Intrinsic Procedures
  
! 8.24 ‘ATAND’ -- Arctangent function, degrees
  ============================================
  
  _Description_:
!      ‘ATAND(X)’ computes the arctangent of X in degrees (inverse of
       *note TAND::).
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with ‘-fdec-math’.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ATAND(X)’
!      ‘RESULT = ATAND(Y, X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’; if Y is
                   present, X shall be REAL.
       Y           The type and kind type parameter shall be the
                   same as X.
  
  _Return value_:
       The return value is of the same type and kind as X.  If Y is
!      present, the result is identical to ‘ATAND2(Y,X)’.  Otherwise, it
       is the arcus tangent of X, where the real part of the result is in
       degrees and lies in the range -90 \leq \Re \atand(x) \leq 90.
  
*************** _Example_:
*** 8173,8180 ****
  _Specific names_:
       Name              Argument          Return type    Standard
       --------------------------------------------------------------------------
!      'ATAND(X)'        'REAL(4) X'       'REAL(4)'      GNU extension
!      'DATAND(X)'       'REAL(8) X'       'REAL(8)'      GNU extension
  
  _See also_:
       Inverse function:
--- 8173,8180 ----
  _Specific names_:
       Name              Argument          Return type    Standard
       --------------------------------------------------------------------------
!      ‘ATAND(X)’        ‘REAL(4) X’       ‘REAL(4)’      GNU extension
!      ‘DATAND(X)’       ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 8185,8195 ****
  
  File: gfortran.info,  Node: ATAN2,  Next: ATAN2D,  Prev: ATAND,  Up: Intrinsic Procedures
  
! 8.25 'ATAN2' -- Arctangent function
  ===================================
  
  _Description_:
!      'ATAN2(Y, X)' computes the principal value of the argument function
       of the complex number X + i Y. This function can be used to
       transform from Cartesian into polar coordinates and allows to
       determine the angle in the correct quadrant.
--- 8185,8195 ----
  
  File: gfortran.info,  Node: ATAN2,  Next: ATAN2D,  Prev: ATAND,  Up: Intrinsic Procedures
  
! 8.25 ‘ATAN2’ -- Arctangent function
  ===================================
  
  _Description_:
!      ‘ATAN2(Y, X)’ computes the principal value of the argument function
       of the complex number X + i Y. This function can be used to
       transform from Cartesian into polar coordinates and allows to
       determine the angle in the correct quadrant.
*************** _Class_:
*** 8201,8210 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ATAN2(Y, X)'
  
  _Arguments_:
!      Y           The type shall be 'REAL'.
       X           The type and kind type parameter shall be the
                   same as Y.  If Y is zero, then X must be
                   nonzero.
--- 8201,8210 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ATAN2(Y, X)’
  
  _Arguments_:
!      Y           The type shall be ‘REAL’.
       X           The type and kind type parameter shall be the
                   same as Y.  If Y is zero, then X must be
                   nonzero.
*************** _Example_:
*** 8228,8235 ****
  _Specific names_:
       Name             Argument         Return type    Standard
       -------------------------------------------------------------------------
!      'ATAN2(X, Y)'    'REAL(4) X, Y'   'REAL(4)'      Fortran 77 and later
!      'DATAN2(X, Y)'   'REAL(8) X, Y'   'REAL(8)'      Fortran 77 and later
  
  _See also_:
       Alias:
--- 8228,8235 ----
  _Specific names_:
       Name             Argument         Return type    Standard
       -------------------------------------------------------------------------
!      ‘ATAN2(X, Y)’    ‘REAL(4) X, Y’   ‘REAL(4)’      Fortran 77 and later
!      ‘DATAN2(X, Y)’   ‘REAL(8) X, Y’   ‘REAL(8)’      Fortran 77 and later
  
  _See also_:
       Alias:
*************** _See also_:
*** 8240,8250 ****
  
  File: gfortran.info,  Node: ATAN2D,  Next: ATANH,  Prev: ATAN2,  Up: Intrinsic Procedures
  
! 8.26 'ATAN2D' -- Arctangent function, degrees
  =============================================
  
  _Description_:
!      'ATAN2D(Y, X)' computes the principal value of the argument
       function of the complex number X + i Y in degrees.  This function
       can be used to transform from Cartesian into polar coordinates and
       allows to determine the angle in the correct quadrant.
--- 8240,8250 ----
  
  File: gfortran.info,  Node: ATAN2D,  Next: ATANH,  Prev: ATAN2,  Up: Intrinsic Procedures
  
! 8.26 ‘ATAN2D’ -- Arctangent function, degrees
  =============================================
  
  _Description_:
!      ‘ATAN2D(Y, X)’ computes the principal value of the argument
       function of the complex number X + i Y in degrees.  This function
       can be used to transform from Cartesian into polar coordinates and
       allows to determine the angle in the correct quadrant.
*************** _Description_:
*** 8253,8268 ****
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with '-fdec-math'.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      'RESULT = ATAN2D(Y, X)'
  
  _Arguments_:
!      Y           The type shall be 'REAL'.
       X           The type and kind type parameter shall be the
                   same as Y.  If Y is zero, then X must be
                   nonzero.
--- 8253,8268 ----
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with ‘-fdec-math’.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ATAN2D(Y, X)’
  
  _Arguments_:
!      Y           The type shall be ‘REAL’.
       X           The type and kind type parameter shall be the
                   same as Y.  If Y is zero, then X must be
                   nonzero.
*************** _Example_:
*** 8286,8293 ****
  _Specific names_:
       Name              Argument          Return type    Standard
       --------------------------------------------------------------------------
!      'ATAN2D(X, Y)'    'REAL(4) X, Y'    'REAL(4)'      GNU extension
!      'DATAN2D(X, Y)'   'REAL(8) X, Y'    'REAL(8)'      GNU extension
  
  _See also_:
       Alias:
--- 8286,8293 ----
  _Specific names_:
       Name              Argument          Return type    Standard
       --------------------------------------------------------------------------
!      ‘ATAN2D(X, Y)’    ‘REAL(4) X, Y’    ‘REAL(4)’      GNU extension
!      ‘DATAN2D(X, Y)’   ‘REAL(8) X, Y’    ‘REAL(8)’      GNU extension
  
  _See also_:
       Alias:
*************** _See also_:
*** 8298,8308 ****
  
  File: gfortran.info,  Node: ATANH,  Next: ATOMIC_ADD,  Prev: ATAN2D,  Up: Intrinsic Procedures
  
! 8.27 'ATANH' -- Inverse hyperbolic tangent function
  ===================================================
  
  _Description_:
!      'ATANH(X)' computes the inverse hyperbolic tangent of X.
  
  _Standard_:
       Fortran 2008 and later
--- 8298,8308 ----
  
  File: gfortran.info,  Node: ATANH,  Next: ATOMIC_ADD,  Prev: ATAN2D,  Up: Intrinsic Procedures
  
! 8.27 ‘ATANH’ -- Inverse hyperbolic tangent function
  ===================================================
  
  _Description_:
!      ‘ATANH(X)’ computes the inverse hyperbolic tangent of X.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 8311,8320 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ATANH(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X.  If X is complex, the
--- 8311,8320 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ATANH(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X.  If X is complex, the
*************** _Example_:
*** 8330,8336 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DATANH(X)'    'REAL(8) X'       'REAL(8)'      GNU extension
  
  _See also_:
       Inverse function:
--- 8330,8336 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DATANH(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 8339,8356 ****
  
  File: gfortran.info,  Node: ATOMIC_ADD,  Next: ATOMIC_AND,  Prev: ATANH,  Up: Intrinsic Procedures
  
! 8.28 'ATOMIC_ADD' -- Atomic ADD operation
  =========================================
  
  _Description_:
!      'ATOMIC_ADD(ATOM, VALUE)' atomically adds the value of VALUE to the
       variable ATOM.  When STAT is present and the invocation was
       successful, it is assigned the value 0.  If it is present and the
       invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of 'ISO_FORTRAN_ENV''s
!      'STAT_STOPPED_IMAGE' and if the remote image has failed, the value
!      'STAT_FAILED_IMAGE'.
  
  _Standard_:
       TS 18508 or later
--- 8339,8356 ----
  
  File: gfortran.info,  Node: ATOMIC_ADD,  Next: ATOMIC_AND,  Prev: ATANH,  Up: Intrinsic Procedures
  
! 8.28 ‘ATOMIC_ADD’ -- Atomic ADD operation
  =========================================
  
  _Description_:
!      ‘ATOMIC_ADD(ATOM, VALUE)’ atomically adds the value of VALUE to the
       variable ATOM.  When STAT is present and the invocation was
       successful, it is assigned the value 0.  If it is present and the
       invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of ‘ISO_FORTRAN_ENV’'s
!      ‘STAT_STOPPED_IMAGE’ and if the remote image has failed, the value
!      ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       TS 18508 or later
*************** _Class_:
*** 8359,8369 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_ADD (ATOM, VALUE [, STAT])'
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with 'ATOMIC_INT_KIND' kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
--- 8359,8369 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_ADD (ATOM, VALUE [, STAT])’
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with ‘ATOMIC_INT_KIND’ kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
*************** _See also_:
*** 8387,8404 ****
  
  File: gfortran.info,  Node: ATOMIC_AND,  Next: ATOMIC_CAS,  Prev: ATOMIC_ADD,  Up: Intrinsic Procedures
  
! 8.29 'ATOMIC_AND' -- Atomic bitwise AND operation
  =================================================
  
  _Description_:
!      'ATOMIC_AND(ATOM, VALUE)' atomically defines ATOM with the bitwise
       AND between the values of ATOM and VALUE.  When STAT is present and
       the invocation was successful, it is assigned the value 0.  If it
       is present and the invocation has failed, it is assigned a positive
       value; in particular, for a coindexed ATOM, if the remote image has
!      stopped, it is assigned the value of 'ISO_FORTRAN_ENV''s
!      'STAT_STOPPED_IMAGE' and if the remote image has failed, the value
!      'STAT_FAILED_IMAGE'.
  
  _Standard_:
       TS 18508 or later
--- 8387,8404 ----
  
  File: gfortran.info,  Node: ATOMIC_AND,  Next: ATOMIC_CAS,  Prev: ATOMIC_ADD,  Up: Intrinsic Procedures
  
! 8.29 ‘ATOMIC_AND’ -- Atomic bitwise AND operation
  =================================================
  
  _Description_:
!      ‘ATOMIC_AND(ATOM, VALUE)’ atomically defines ATOM with the bitwise
       AND between the values of ATOM and VALUE.  When STAT is present and
       the invocation was successful, it is assigned the value 0.  If it
       is present and the invocation has failed, it is assigned a positive
       value; in particular, for a coindexed ATOM, if the remote image has
!      stopped, it is assigned the value of ‘ISO_FORTRAN_ENV’'s
!      ‘STAT_STOPPED_IMAGE’ and if the remote image has failed, the value
!      ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       TS 18508 or later
*************** _Class_:
*** 8407,8417 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_AND (ATOM, VALUE [, STAT])'
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with 'ATOMIC_INT_KIND' kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
--- 8407,8417 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_AND (ATOM, VALUE [, STAT])’
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with ‘ATOMIC_INT_KIND’ kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
*************** _See also_:
*** 8435,8454 ****
  
  File: gfortran.info,  Node: ATOMIC_CAS,  Next: ATOMIC_DEFINE,  Prev: ATOMIC_AND,  Up: Intrinsic Procedures
  
! 8.30 'ATOMIC_CAS' -- Atomic compare and swap
  ============================================
  
  _Description_:
!      'ATOMIC_CAS' compares the variable ATOM with the value of COMPARE;
       if the value is the same, ATOM is set to the value of NEW.
       Additionally, OLD is set to the value of ATOM that was used for the
       comparison.  When STAT is present and the invocation was
       successful, it is assigned the value 0.  If it is present and the
       invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of 'ISO_FORTRAN_ENV''s
!      'STAT_STOPPED_IMAGE' and if the remote image has failed, the value
!      'STAT_FAILED_IMAGE'.
  
  _Standard_:
       TS 18508 or later
--- 8435,8454 ----
  
  File: gfortran.info,  Node: ATOMIC_CAS,  Next: ATOMIC_DEFINE,  Prev: ATOMIC_AND,  Up: Intrinsic Procedures
  
! 8.30 ‘ATOMIC_CAS’ -- Atomic compare and swap
  ============================================
  
  _Description_:
!      ‘ATOMIC_CAS’ compares the variable ATOM with the value of COMPARE;
       if the value is the same, ATOM is set to the value of NEW.
       Additionally, OLD is set to the value of ATOM that was used for the
       comparison.  When STAT is present and the invocation was
       successful, it is assigned the value 0.  If it is present and the
       invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of ‘ISO_FORTRAN_ENV’'s
!      ‘STAT_STOPPED_IMAGE’ and if the remote image has failed, the value
!      ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       TS 18508 or later
*************** _Class_:
*** 8457,8468 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_CAS (ATOM, OLD, COMPARE, NEW [, STAT])'
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of either
!                  integer type with 'ATOMIC_INT_KIND' kind or
!                  logical type with 'ATOMIC_LOGICAL_KIND' kind.
       OLD         Scalar of the same type and kind as ATOM.
       COMPARE     Scalar variable of the same type and kind as
                   ATOM.
--- 8457,8468 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_CAS (ATOM, OLD, COMPARE, NEW [, STAT])’
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of either
!                  integer type with ‘ATOMIC_INT_KIND’ kind or
!                  logical type with ‘ATOMIC_LOGICAL_KIND’ kind.
       OLD         Scalar of the same type and kind as ATOM.
       COMPARE     Scalar variable of the same type and kind as
                   ATOM.
*************** _See also_:
*** 8486,8503 ****
  
  File: gfortran.info,  Node: ATOMIC_DEFINE,  Next: ATOMIC_FETCH_ADD,  Prev: ATOMIC_CAS,  Up: Intrinsic Procedures
  
! 8.31 'ATOMIC_DEFINE' -- Setting a variable atomically
  =====================================================
  
  _Description_:
!      'ATOMIC_DEFINE(ATOM, VALUE)' defines the variable ATOM with the
       value VALUE atomically.  When STAT is present and the invocation
       was successful, it is assigned the value 0.  If it is present and
       the invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of 'ISO_FORTRAN_ENV''s
!      'STAT_STOPPED_IMAGE' and if the remote image has failed, the value
!      'STAT_FAILED_IMAGE'.
  
  _Standard_:
       Fortran 2008 and later; with STAT, TS 18508 or later
--- 8486,8503 ----
  
  File: gfortran.info,  Node: ATOMIC_DEFINE,  Next: ATOMIC_FETCH_ADD,  Prev: ATOMIC_CAS,  Up: Intrinsic Procedures
  
! 8.31 ‘ATOMIC_DEFINE’ -- Setting a variable atomically
  =====================================================
  
  _Description_:
!      ‘ATOMIC_DEFINE(ATOM, VALUE)’ defines the variable ATOM with the
       value VALUE atomically.  When STAT is present and the invocation
       was successful, it is assigned the value 0.  If it is present and
       the invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of ‘ISO_FORTRAN_ENV’'s
!      ‘STAT_STOPPED_IMAGE’ and if the remote image has failed, the value
!      ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       Fortran 2008 and later; with STAT, TS 18508 or later
*************** _Class_:
*** 8506,8517 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_DEFINE (ATOM, VALUE [, STAT])'
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of either
!                  integer type with 'ATOMIC_INT_KIND' kind or
!                  logical type with 'ATOMIC_LOGICAL_KIND' kind.
                   
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
--- 8506,8517 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_DEFINE (ATOM, VALUE [, STAT])’
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of either
!                  integer type with ‘ATOMIC_INT_KIND’ kind or
!                  logical type with ‘ATOMIC_LOGICAL_KIND’ kind.
                   
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
*************** _See also_:
*** 8537,8554 ****
  
  File: gfortran.info,  Node: ATOMIC_FETCH_ADD,  Next: ATOMIC_FETCH_AND,  Prev: ATOMIC_DEFINE,  Up: Intrinsic Procedures
  
! 8.32 'ATOMIC_FETCH_ADD' -- Atomic ADD operation with prior fetch
  ================================================================
  
  _Description_:
!      'ATOMIC_FETCH_ADD(ATOM, VALUE, OLD)' atomically stores the value of
       ATOM in OLD and adds the value of VALUE to the variable ATOM.  When
       STAT is present and the invocation was successful, it is assigned
       the value 0.  If it is present and the invocation has failed, it is
       assigned a positive value; in particular, for a coindexed ATOM, if
       the remote image has stopped, it is assigned the value of
!      'ISO_FORTRAN_ENV''s 'STAT_STOPPED_IMAGE' and if the remote image
!      has failed, the value 'STAT_FAILED_IMAGE'.
  
  _Standard_:
       TS 18508 or later
--- 8537,8554 ----
  
  File: gfortran.info,  Node: ATOMIC_FETCH_ADD,  Next: ATOMIC_FETCH_AND,  Prev: ATOMIC_DEFINE,  Up: Intrinsic Procedures
  
! 8.32 ‘ATOMIC_FETCH_ADD’ -- Atomic ADD operation with prior fetch
  ================================================================
  
  _Description_:
!      ‘ATOMIC_FETCH_ADD(ATOM, VALUE, OLD)’ atomically stores the value of
       ATOM in OLD and adds the value of VALUE to the variable ATOM.  When
       STAT is present and the invocation was successful, it is assigned
       the value 0.  If it is present and the invocation has failed, it is
       assigned a positive value; in particular, for a coindexed ATOM, if
       the remote image has stopped, it is assigned the value of
!      ‘ISO_FORTRAN_ENV’'s ‘STAT_STOPPED_IMAGE’ and if the remote image
!      has failed, the value ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       TS 18508 or later
*************** _Class_:
*** 8557,8568 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_FETCH_ADD (ATOM, VALUE, old [, STAT])'
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with 'ATOMIC_INT_KIND' kind.
!                  'ATOMIC_LOGICAL_KIND' kind.
                   
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
--- 8557,8568 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_FETCH_ADD (ATOM, VALUE, old [, STAT])’
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with ‘ATOMIC_INT_KIND’ kind.
!                  ‘ATOMIC_LOGICAL_KIND’ kind.
                   
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
*************** _See also_:
*** 8588,8606 ****
  
  File: gfortran.info,  Node: ATOMIC_FETCH_AND,  Next: ATOMIC_FETCH_OR,  Prev: ATOMIC_FETCH_ADD,  Up: Intrinsic Procedures
  
! 8.33 'ATOMIC_FETCH_AND' -- Atomic bitwise AND operation with prior fetch
  ========================================================================
  
  _Description_:
!      'ATOMIC_AND(ATOM, VALUE)' atomically stores the value of ATOM in
       OLD and defines ATOM with the bitwise AND between the values of
       ATOM and VALUE.  When STAT is present and the invocation was
       successful, it is assigned the value 0.  If it is present and the
       invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of 'ISO_FORTRAN_ENV''s
!      'STAT_STOPPED_IMAGE' and if the remote image has failed, the value
!      'STAT_FAILED_IMAGE'.
  
  _Standard_:
       TS 18508 or later
--- 8588,8606 ----
  
  File: gfortran.info,  Node: ATOMIC_FETCH_AND,  Next: ATOMIC_FETCH_OR,  Prev: ATOMIC_FETCH_ADD,  Up: Intrinsic Procedures
  
! 8.33 ‘ATOMIC_FETCH_AND’ -- Atomic bitwise AND operation with prior fetch
  ========================================================================
  
  _Description_:
!      ‘ATOMIC_AND(ATOM, VALUE)’ atomically stores the value of ATOM in
       OLD and defines ATOM with the bitwise AND between the values of
       ATOM and VALUE.  When STAT is present and the invocation was
       successful, it is assigned the value 0.  If it is present and the
       invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of ‘ISO_FORTRAN_ENV’'s
!      ‘STAT_STOPPED_IMAGE’ and if the remote image has failed, the value
!      ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       TS 18508 or later
*************** _Class_:
*** 8609,8619 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_FETCH_AND (ATOM, VALUE, OLD [, STAT])'
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with 'ATOMIC_INT_KIND' kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
--- 8609,8619 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_FETCH_AND (ATOM, VALUE, OLD [, STAT])’
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with ‘ATOMIC_INT_KIND’ kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
*************** _See also_:
*** 8638,8655 ****
  
  File: gfortran.info,  Node: ATOMIC_FETCH_OR,  Next: ATOMIC_FETCH_XOR,  Prev: ATOMIC_FETCH_AND,  Up: Intrinsic Procedures
  
! 8.34 'ATOMIC_FETCH_OR' -- Atomic bitwise OR operation with prior fetch
  ======================================================================
  
  _Description_:
!      'ATOMIC_OR(ATOM, VALUE)' atomically stores the value of ATOM in OLD
       and defines ATOM with the bitwise OR between the values of ATOM and
       VALUE.  When STAT is present and the invocation was successful, it
       is assigned the value 0.  If it is present and the invocation has
       failed, it is assigned a positive value; in particular, for a
       coindexed ATOM, if the remote image has stopped, it is assigned the
!      value of 'ISO_FORTRAN_ENV''s 'STAT_STOPPED_IMAGE' and if the remote
!      image has failed, the value 'STAT_FAILED_IMAGE'.
  
  _Standard_:
       TS 18508 or later
--- 8638,8655 ----
  
  File: gfortran.info,  Node: ATOMIC_FETCH_OR,  Next: ATOMIC_FETCH_XOR,  Prev: ATOMIC_FETCH_AND,  Up: Intrinsic Procedures
  
! 8.34 ‘ATOMIC_FETCH_OR’ -- Atomic bitwise OR operation with prior fetch
  ======================================================================
  
  _Description_:
!      ‘ATOMIC_OR(ATOM, VALUE)’ atomically stores the value of ATOM in OLD
       and defines ATOM with the bitwise OR between the values of ATOM and
       VALUE.  When STAT is present and the invocation was successful, it
       is assigned the value 0.  If it is present and the invocation has
       failed, it is assigned a positive value; in particular, for a
       coindexed ATOM, if the remote image has stopped, it is assigned the
!      value of ‘ISO_FORTRAN_ENV’'s ‘STAT_STOPPED_IMAGE’ and if the remote
!      image has failed, the value ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       TS 18508 or later
*************** _Class_:
*** 8658,8668 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_FETCH_OR (ATOM, VALUE, OLD [, STAT])'
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with 'ATOMIC_INT_KIND' kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
--- 8658,8668 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_FETCH_OR (ATOM, VALUE, OLD [, STAT])’
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with ‘ATOMIC_INT_KIND’ kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
*************** _See also_:
*** 8687,8705 ****
  
  File: gfortran.info,  Node: ATOMIC_FETCH_XOR,  Next: ATOMIC_OR,  Prev: ATOMIC_FETCH_OR,  Up: Intrinsic Procedures
  
! 8.35 'ATOMIC_FETCH_XOR' -- Atomic bitwise XOR operation with prior fetch
  ========================================================================
  
  _Description_:
!      'ATOMIC_XOR(ATOM, VALUE)' atomically stores the value of ATOM in
       OLD and defines ATOM with the bitwise XOR between the values of
       ATOM and VALUE.  When STAT is present and the invocation was
       successful, it is assigned the value 0.  If it is present and the
       invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of 'ISO_FORTRAN_ENV''s
!      'STAT_STOPPED_IMAGE' and if the remote image has failed, the value
!      'STAT_FAILED_IMAGE'.
  
  _Standard_:
       TS 18508 or later
--- 8687,8705 ----
  
  File: gfortran.info,  Node: ATOMIC_FETCH_XOR,  Next: ATOMIC_OR,  Prev: ATOMIC_FETCH_OR,  Up: Intrinsic Procedures
  
! 8.35 ‘ATOMIC_FETCH_XOR’ -- Atomic bitwise XOR operation with prior fetch
  ========================================================================
  
  _Description_:
!      ‘ATOMIC_XOR(ATOM, VALUE)’ atomically stores the value of ATOM in
       OLD and defines ATOM with the bitwise XOR between the values of
       ATOM and VALUE.  When STAT is present and the invocation was
       successful, it is assigned the value 0.  If it is present and the
       invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of ‘ISO_FORTRAN_ENV’'s
!      ‘STAT_STOPPED_IMAGE’ and if the remote image has failed, the value
!      ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       TS 18508 or later
*************** _Class_:
*** 8708,8718 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_FETCH_XOR (ATOM, VALUE, OLD [, STAT])'
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with 'ATOMIC_INT_KIND' kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
--- 8708,8718 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_FETCH_XOR (ATOM, VALUE, OLD [, STAT])’
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with ‘ATOMIC_INT_KIND’ kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
*************** _See also_:
*** 8737,8754 ****
  
  File: gfortran.info,  Node: ATOMIC_OR,  Next: ATOMIC_REF,  Prev: ATOMIC_FETCH_XOR,  Up: Intrinsic Procedures
  
! 8.36 'ATOMIC_OR' -- Atomic bitwise OR operation
  ===============================================
  
  _Description_:
!      'ATOMIC_OR(ATOM, VALUE)' atomically defines ATOM with the bitwise
       AND between the values of ATOM and VALUE.  When STAT is present and
       the invocation was successful, it is assigned the value 0.  If it
       is present and the invocation has failed, it is assigned a positive
       value; in particular, for a coindexed ATOM, if the remote image has
!      stopped, it is assigned the value of 'ISO_FORTRAN_ENV''s
!      'STAT_STOPPED_IMAGE' and if the remote image has failed, the value
!      'STAT_FAILED_IMAGE'.
  
  _Standard_:
       TS 18508 or later
--- 8737,8754 ----
  
  File: gfortran.info,  Node: ATOMIC_OR,  Next: ATOMIC_REF,  Prev: ATOMIC_FETCH_XOR,  Up: Intrinsic Procedures
  
! 8.36 ‘ATOMIC_OR’ -- Atomic bitwise OR operation
  ===============================================
  
  _Description_:
!      ‘ATOMIC_OR(ATOM, VALUE)’ atomically defines ATOM with the bitwise
       AND between the values of ATOM and VALUE.  When STAT is present and
       the invocation was successful, it is assigned the value 0.  If it
       is present and the invocation has failed, it is assigned a positive
       value; in particular, for a coindexed ATOM, if the remote image has
!      stopped, it is assigned the value of ‘ISO_FORTRAN_ENV’'s
!      ‘STAT_STOPPED_IMAGE’ and if the remote image has failed, the value
!      ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       TS 18508 or later
*************** _Class_:
*** 8757,8767 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_OR (ATOM, VALUE [, STAT])'
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with 'ATOMIC_INT_KIND' kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
--- 8757,8767 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_OR (ATOM, VALUE [, STAT])’
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with ‘ATOMIC_INT_KIND’ kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
*************** _See also_:
*** 8785,8802 ****
  
  File: gfortran.info,  Node: ATOMIC_REF,  Next: ATOMIC_XOR,  Prev: ATOMIC_OR,  Up: Intrinsic Procedures
  
! 8.37 'ATOMIC_REF' -- Obtaining the value of a variable atomically
  =================================================================
  
  _Description_:
!      'ATOMIC_DEFINE(ATOM, VALUE)' atomically assigns the value of the
       variable ATOM to VALUE.  When STAT is present and the invocation
       was successful, it is assigned the value 0.  If it is present and
       the invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of 'ISO_FORTRAN_ENV''s
!      'STAT_STOPPED_IMAGE' and if the remote image has failed, the value
!      'STAT_FAILED_IMAGE'.
  
  _Standard_:
       Fortran 2008 and later; with STAT, TS 18508 or later
--- 8785,8802 ----
  
  File: gfortran.info,  Node: ATOMIC_REF,  Next: ATOMIC_XOR,  Prev: ATOMIC_OR,  Up: Intrinsic Procedures
  
! 8.37 ‘ATOMIC_REF’ -- Obtaining the value of a variable atomically
  =================================================================
  
  _Description_:
!      ‘ATOMIC_DEFINE(ATOM, VALUE)’ atomically assigns the value of the
       variable ATOM to VALUE.  When STAT is present and the invocation
       was successful, it is assigned the value 0.  If it is present and
       the invocation has failed, it is assigned a positive value; in
       particular, for a coindexed ATOM, if the remote image has stopped,
!      it is assigned the value of ‘ISO_FORTRAN_ENV’'s
!      ‘STAT_STOPPED_IMAGE’ and if the remote image has failed, the value
!      ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       Fortran 2008 and later; with STAT, TS 18508 or later
*************** _Class_:
*** 8805,8819 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_REF(VALUE, ATOM [, STAT])'
  
  _Arguments_:
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
       ATOM        Scalar coarray or coindexed variable of either
!                  integer type with 'ATOMIC_INT_KIND' kind or
!                  logical type with 'ATOMIC_LOGICAL_KIND' kind.
       STAT        (optional) Scalar default-kind integer variable.
  
  _Example_:
--- 8805,8819 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_REF(VALUE, ATOM [, STAT])’
  
  _Arguments_:
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
       ATOM        Scalar coarray or coindexed variable of either
!                  integer type with ‘ATOMIC_INT_KIND’ kind or
!                  logical type with ‘ATOMIC_LOGICAL_KIND’ kind.
       STAT        (optional) Scalar default-kind integer variable.
  
  _Example_:
*************** _See also_:
*** 8841,8858 ****
  
  File: gfortran.info,  Node: ATOMIC_XOR,  Next: BACKTRACE,  Prev: ATOMIC_REF,  Up: Intrinsic Procedures
  
! 8.38 'ATOMIC_XOR' -- Atomic bitwise OR operation
  ================================================
  
  _Description_:
!      'ATOMIC_AND(ATOM, VALUE)' atomically defines ATOM with the bitwise
       XOR between the values of ATOM and VALUE.  When STAT is present and
       the invocation was successful, it is assigned the value 0.  If it
       is present and the invocation has failed, it is assigned a positive
       value; in particular, for a coindexed ATOM, if the remote image has
!      stopped, it is assigned the value of 'ISO_FORTRAN_ENV''s
!      'STAT_STOPPED_IMAGE' and if the remote image has failed, the value
!      'STAT_FAILED_IMAGE'.
  
  _Standard_:
       TS 18508 or later
--- 8841,8858 ----
  
  File: gfortran.info,  Node: ATOMIC_XOR,  Next: BACKTRACE,  Prev: ATOMIC_REF,  Up: Intrinsic Procedures
  
! 8.38 ‘ATOMIC_XOR’ -- Atomic bitwise OR operation
  ================================================
  
  _Description_:
!      ‘ATOMIC_AND(ATOM, VALUE)’ atomically defines ATOM with the bitwise
       XOR between the values of ATOM and VALUE.  When STAT is present and
       the invocation was successful, it is assigned the value 0.  If it
       is present and the invocation has failed, it is assigned a positive
       value; in particular, for a coindexed ATOM, if the remote image has
!      stopped, it is assigned the value of ‘ISO_FORTRAN_ENV’'s
!      ‘STAT_STOPPED_IMAGE’ and if the remote image has failed, the value
!      ‘STAT_FAILED_IMAGE’.
  
  _Standard_:
       TS 18508 or later
*************** _Class_:
*** 8861,8871 ****
       Atomic subroutine
  
  _Syntax_:
!      'CALL ATOMIC_XOR (ATOM, VALUE [, STAT])'
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with 'ATOMIC_INT_KIND' kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
--- 8861,8871 ----
       Atomic subroutine
  
  _Syntax_:
!      ‘CALL ATOMIC_XOR (ATOM, VALUE [, STAT])’
  
  _Arguments_:
       ATOM        Scalar coarray or coindexed variable of integer
!                  type with ‘ATOMIC_INT_KIND’ kind.
       VALUE       Scalar of the same type as ATOM.  If the kind is
                   different, the value is converted to the kind of
                   ATOM.
*************** _See also_:
*** 8889,8902 ****
  
  File: gfortran.info,  Node: BACKTRACE,  Next: BESSEL_J0,  Prev: ATOMIC_XOR,  Up: Intrinsic Procedures
  
! 8.39 'BACKTRACE' -- Show a backtrace
  ====================================
  
  _Description_:
!      'BACKTRACE' shows a backtrace at an arbitrary place in user code.
       Program execution continues normally afterwards.  The backtrace
!      information is printed to the unit corresponding to 'ERROR_UNIT' in
!      'ISO_FORTRAN_ENV'.
  
  _Standard_:
       GNU extension
--- 8889,8902 ----
  
  File: gfortran.info,  Node: BACKTRACE,  Next: BESSEL_J0,  Prev: ATOMIC_XOR,  Up: Intrinsic Procedures
  
! 8.39 ‘BACKTRACE’ -- Show a backtrace
  ====================================
  
  _Description_:
!      ‘BACKTRACE’ shows a backtrace at an arbitrary place in user code.
       Program execution continues normally afterwards.  The backtrace
!      information is printed to the unit corresponding to ‘ERROR_UNIT’ in
!      ‘ISO_FORTRAN_ENV’.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 8905,8911 ****
       Subroutine
  
  _Syntax_:
!      'CALL BACKTRACE'
  
  _Arguments_:
       None
--- 8905,8911 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL BACKTRACE’
  
  _Arguments_:
       None
*************** _See also_:
*** 8916,8927 ****
  
  File: gfortran.info,  Node: BESSEL_J0,  Next: BESSEL_J1,  Prev: BACKTRACE,  Up: Intrinsic Procedures
  
! 8.40 'BESSEL_J0' -- Bessel function of the first kind of order 0
  ================================================================
  
  _Description_:
!      'BESSEL_J0(X)' computes the Bessel function of the first kind of
!      order 0 of X.  This function is available under the name 'BESJ0' as
       a GNU extension.
  
  _Standard_:
--- 8916,8927 ----
  
  File: gfortran.info,  Node: BESSEL_J0,  Next: BESSEL_J1,  Prev: BACKTRACE,  Up: Intrinsic Procedures
  
! 8.40 ‘BESSEL_J0’ -- Bessel function of the first kind of order 0
  ================================================================
  
  _Description_:
!      ‘BESSEL_J0(X)’ computes the Bessel function of the first kind of
!      order 0 of X.  This function is available under the name ‘BESJ0’ as
       a GNU extension.
  
  _Standard_:
*************** _Class_:
*** 8931,8943 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = BESSEL_J0(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
  
  _Return value_:
!      The return value is of type 'REAL' and lies in the range -
       0.4027... \leq Bessel (0,x) \leq 1.  It has the same kind as X.
  
  _Example_:
--- 8931,8943 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = BESSEL_J0(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘REAL’ and lies in the range -
       0.4027... \leq Bessel (0,x) \leq 1.  It has the same kind as X.
  
  _Example_:
*************** _Example_:
*** 8949,8965 ****
  _Specific names_:
       Name            Argument         Return type    Standard
       -------------------------------------------------------------------------
!      'DBESJ0(X)'     'REAL(8) X'      'REAL(8)'      GNU extension
  
  
  File: gfortran.info,  Node: BESSEL_J1,  Next: BESSEL_JN,  Prev: BESSEL_J0,  Up: Intrinsic Procedures
  
! 8.41 'BESSEL_J1' -- Bessel function of the first kind of order 1
  ================================================================
  
  _Description_:
!      'BESSEL_J1(X)' computes the Bessel function of the first kind of
!      order 1 of X.  This function is available under the name 'BESJ1' as
       a GNU extension.
  
  _Standard_:
--- 8949,8965 ----
  _Specific names_:
       Name            Argument         Return type    Standard
       -------------------------------------------------------------------------
!      ‘DBESJ0(X)’     ‘REAL(8) X’      ‘REAL(8)’      GNU extension
  
  
  File: gfortran.info,  Node: BESSEL_J1,  Next: BESSEL_JN,  Prev: BESSEL_J0,  Up: Intrinsic Procedures
  
! 8.41 ‘BESSEL_J1’ -- Bessel function of the first kind of order 1
  ================================================================
  
  _Description_:
!      ‘BESSEL_J1(X)’ computes the Bessel function of the first kind of
!      order 1 of X.  This function is available under the name ‘BESJ1’ as
       a GNU extension.
  
  _Standard_:
*************** _Class_:
*** 8969,8981 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = BESSEL_J1(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
  
  _Return value_:
!      The return value is of type 'REAL' and lies in the range -
       0.5818... \leq Bessel (0,x) \leq 0.5818 .  It has the same kind as
       X.
  
--- 8969,8981 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = BESSEL_J1(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘REAL’ and lies in the range -
       0.5818... \leq Bessel (0,x) \leq 0.5818 .  It has the same kind as
       X.
  
*************** _Example_:
*** 8988,9008 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DBESJ1(X)'    'REAL(8) X'       'REAL(8)'      GNU extension
  
  
  File: gfortran.info,  Node: BESSEL_JN,  Next: BESSEL_Y0,  Prev: BESSEL_J1,  Up: Intrinsic Procedures
  
! 8.42 'BESSEL_JN' -- Bessel function of the first kind
  =====================================================
  
  _Description_:
!      'BESSEL_JN(N, X)' computes the Bessel function of the first kind of
!      order N of X.  This function is available under the name 'BESJN' as
       a GNU extension.  If N and X are arrays, their ranks and shapes
       shall conform.
  
!      'BESSEL_JN(N1, N2, X)' returns an array with the Bessel functions
       of the first kind of the orders N1 to N2.
  
  _Standard_:
--- 8988,9008 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DBESJ1(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  
  File: gfortran.info,  Node: BESSEL_JN,  Next: BESSEL_Y0,  Prev: BESSEL_J1,  Up: Intrinsic Procedures
  
! 8.42 ‘BESSEL_JN’ -- Bessel function of the first kind
  =====================================================
  
  _Description_:
!      ‘BESSEL_JN(N, X)’ computes the Bessel function of the first kind of
!      order N of X.  This function is available under the name ‘BESJN’ as
       a GNU extension.  If N and X are arrays, their ranks and shapes
       shall conform.
  
!      ‘BESSEL_JN(N1, N2, X)’ returns an array with the Bessel functions
       of the first kind of the orders N1 to N2.
  
  _Standard_:
*************** _Standard_:
*** 9010,9032 ****
  
  _Class_:
       Elemental function, except for the transformational function
!      'BESSEL_JN(N1, N2, X)'
  
  _Syntax_:
!      'RESULT = BESSEL_JN(N, X)'
!      'RESULT = BESSEL_JN(N1, N2, X)'
  
  _Arguments_:
!      N           Shall be a scalar or an array of type 'INTEGER'.
       N1          Shall be a non-negative scalar of type
!                  'INTEGER'.
       N2          Shall be a non-negative scalar of type
!                  'INTEGER'.
!      X           Shall be a scalar or an array of type 'REAL';
!                  for 'BESSEL_JN(N1, N2, X)' it shall be scalar.
  
  _Return value_:
!      The return value is a scalar of type 'REAL'.  It has the same kind
       as X.
  
  _Note_:
--- 9010,9032 ----
  
  _Class_:
       Elemental function, except for the transformational function
!      ‘BESSEL_JN(N1, N2, X)’
  
  _Syntax_:
!      ‘RESULT = BESSEL_JN(N, X)’
!      ‘RESULT = BESSEL_JN(N1, N2, X)’
  
  _Arguments_:
!      N           Shall be a scalar or an array of type ‘INTEGER’.
       N1          Shall be a non-negative scalar of type
!                  ‘INTEGER’.
       N2          Shall be a non-negative scalar of type
!                  ‘INTEGER’.
!      X           Shall be a scalar or an array of type ‘REAL’;
!                  for ‘BESSEL_JN(N1, N2, X)’ it shall be scalar.
  
  _Return value_:
!      The return value is a scalar of type ‘REAL’.  It has the same kind
       as X.
  
  _Note_:
*************** _Example_:
*** 9043,9060 ****
  _Specific names_:
       Name             Argument         Return type    Standard
       -------------------------------------------------------------------------
!      'DBESJN(N, X)'   'INTEGER N'      'REAL(8)'      GNU extension
!                       'REAL(8) X'
  
  
  File: gfortran.info,  Node: BESSEL_Y0,  Next: BESSEL_Y1,  Prev: BESSEL_JN,  Up: Intrinsic Procedures
  
! 8.43 'BESSEL_Y0' -- Bessel function of the second kind of order 0
  =================================================================
  
  _Description_:
!      'BESSEL_Y0(X)' computes the Bessel function of the second kind of
!      order 0 of X.  This function is available under the name 'BESY0' as
       a GNU extension.
  
  _Standard_:
--- 9043,9060 ----
  _Specific names_:
       Name             Argument         Return type    Standard
       -------------------------------------------------------------------------
!      ‘DBESJN(N, X)’   ‘INTEGER N’      ‘REAL(8)’      GNU extension
!                       ‘REAL(8) X’
  
  
  File: gfortran.info,  Node: BESSEL_Y0,  Next: BESSEL_Y1,  Prev: BESSEL_JN,  Up: Intrinsic Procedures
  
! 8.43 ‘BESSEL_Y0’ -- Bessel function of the second kind of order 0
  =================================================================
  
  _Description_:
!      ‘BESSEL_Y0(X)’ computes the Bessel function of the second kind of
!      order 0 of X.  This function is available under the name ‘BESY0’ as
       a GNU extension.
  
  _Standard_:
*************** _Class_:
*** 9064,9076 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = BESSEL_Y0(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
  
  _Return value_:
!      The return value is of type 'REAL'.  It has the same kind as X.
  
  _Example_:
            program test_besy0
--- 9064,9076 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = BESSEL_Y0(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘REAL’.  It has the same kind as X.
  
  _Example_:
            program test_besy0
*************** _Example_:
*** 9081,9097 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DBESY0(X)'    'REAL(8) X'       'REAL(8)'      GNU extension
  
  
  File: gfortran.info,  Node: BESSEL_Y1,  Next: BESSEL_YN,  Prev: BESSEL_Y0,  Up: Intrinsic Procedures
  
! 8.44 'BESSEL_Y1' -- Bessel function of the second kind of order 1
  =================================================================
  
  _Description_:
!      'BESSEL_Y1(X)' computes the Bessel function of the second kind of
!      order 1 of X.  This function is available under the name 'BESY1' as
       a GNU extension.
  
  _Standard_:
--- 9081,9097 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DBESY0(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  
  File: gfortran.info,  Node: BESSEL_Y1,  Next: BESSEL_YN,  Prev: BESSEL_Y0,  Up: Intrinsic Procedures
  
! 8.44 ‘BESSEL_Y1’ -- Bessel function of the second kind of order 1
  =================================================================
  
  _Description_:
!      ‘BESSEL_Y1(X)’ computes the Bessel function of the second kind of
!      order 1 of X.  This function is available under the name ‘BESY1’ as
       a GNU extension.
  
  _Standard_:
*************** _Class_:
*** 9101,9113 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = BESSEL_Y1(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
  
  _Return value_:
!      The return value is of type 'REAL'.  It has the same kind as X.
  
  _Example_:
            program test_besy1
--- 9101,9113 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = BESSEL_Y1(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘REAL’.  It has the same kind as X.
  
  _Example_:
            program test_besy1
*************** _Example_:
*** 9118,9138 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DBESY1(X)'    'REAL(8) X'       'REAL(8)'      GNU extension
  
  
  File: gfortran.info,  Node: BESSEL_YN,  Next: BGE,  Prev: BESSEL_Y1,  Up: Intrinsic Procedures
  
! 8.45 'BESSEL_YN' -- Bessel function of the second kind
  ======================================================
  
  _Description_:
!      'BESSEL_YN(N, X)' computes the Bessel function of the second kind
!      of order N of X.  This function is available under the name 'BESYN'
       as a GNU extension.  If N and X are arrays, their ranks and shapes
       shall conform.
  
!      'BESSEL_YN(N1, N2, X)' returns an array with the Bessel functions
       of the first kind of the orders N1 to N2.
  
  _Standard_:
--- 9118,9138 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DBESY1(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  
  File: gfortran.info,  Node: BESSEL_YN,  Next: BGE,  Prev: BESSEL_Y1,  Up: Intrinsic Procedures
  
! 8.45 ‘BESSEL_YN’ -- Bessel function of the second kind
  ======================================================
  
  _Description_:
!      ‘BESSEL_YN(N, X)’ computes the Bessel function of the second kind
!      of order N of X.  This function is available under the name ‘BESYN’
       as a GNU extension.  If N and X are arrays, their ranks and shapes
       shall conform.
  
!      ‘BESSEL_YN(N1, N2, X)’ returns an array with the Bessel functions
       of the first kind of the orders N1 to N2.
  
  _Standard_:
*************** _Standard_:
*** 9140,9163 ****
  
  _Class_:
       Elemental function, except for the transformational function
!      'BESSEL_YN(N1, N2, X)'
  
  _Syntax_:
!      'RESULT = BESSEL_YN(N, X)'
!      'RESULT = BESSEL_YN(N1, N2, X)'
  
  _Arguments_:
!      N           Shall be a scalar or an array of type 'INTEGER'
                   .
       N1          Shall be a non-negative scalar of type
!                  'INTEGER'.
       N2          Shall be a non-negative scalar of type
!                  'INTEGER'.
!      X           Shall be a scalar or an array of type 'REAL';
!                  for 'BESSEL_YN(N1, N2, X)' it shall be scalar.
  
  _Return value_:
!      The return value is a scalar of type 'REAL'.  It has the same kind
       as X.
  
  _Note_:
--- 9140,9163 ----
  
  _Class_:
       Elemental function, except for the transformational function
!      ‘BESSEL_YN(N1, N2, X)’
  
  _Syntax_:
!      ‘RESULT = BESSEL_YN(N, X)’
!      ‘RESULT = BESSEL_YN(N1, N2, X)’
  
  _Arguments_:
!      N           Shall be a scalar or an array of type ‘INTEGER’
                   .
       N1          Shall be a non-negative scalar of type
!                  ‘INTEGER’.
       N2          Shall be a non-negative scalar of type
!                  ‘INTEGER’.
!      X           Shall be a scalar or an array of type ‘REAL’;
!                  for ‘BESSEL_YN(N1, N2, X)’ it shall be scalar.
  
  _Return value_:
!      The return value is a scalar of type ‘REAL’.  It has the same kind
       as X.
  
  _Note_:
*************** _Example_:
*** 9174,9186 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DBESYN(N,X)'  'INTEGER N'       'REAL(8)'      GNU extension
!                     'REAL(8) X'
  
  
  File: gfortran.info,  Node: BGE,  Next: BGT,  Prev: BESSEL_YN,  Up: Intrinsic Procedures
  
! 8.46 'BGE' -- Bitwise greater than or equal to
  ==============================================
  
  _Description_:
--- 9174,9186 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DBESYN(N,X)’  ‘INTEGER N’       ‘REAL(8)’      GNU extension
!                     ‘REAL(8) X’
  
  
  File: gfortran.info,  Node: BGE,  Next: BGT,  Prev: BESSEL_YN,  Up: Intrinsic Procedures
  
! 8.46 ‘BGE’ -- Bitwise greater than or equal to
  ==============================================
  
  _Description_:
*************** _Class_:
*** 9194,9208 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = BGE(I, J)'
  
  _Arguments_:
!      I           Shall be of 'INTEGER' type.
!      J           Shall be of 'INTEGER' type, and of the same kind
                   as I.
  
  _Return value_:
!      The return value is of type 'LOGICAL' and of the default kind.
  
  _See also_:
       *note BGT::,
--- 9194,9208 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = BGE(I, J)’
  
  _Arguments_:
!      I           Shall be of ‘INTEGER’ type.
!      J           Shall be of ‘INTEGER’ type, and of the same kind
                   as I.
  
  _Return value_:
!      The return value is of type ‘LOGICAL’ and of the default kind.
  
  _See also_:
       *note BGT::,
*************** _See also_:
*** 9212,9218 ****
  
  File: gfortran.info,  Node: BGT,  Next: BIT_SIZE,  Prev: BGE,  Up: Intrinsic Procedures
  
! 8.47 'BGT' -- Bitwise greater than
  ==================================
  
  _Description_:
--- 9212,9218 ----
  
  File: gfortran.info,  Node: BGT,  Next: BIT_SIZE,  Prev: BGE,  Up: Intrinsic Procedures
  
! 8.47 ‘BGT’ -- Bitwise greater than
  ==================================
  
  _Description_:
*************** _Class_:
*** 9225,9239 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = BGT(I, J)'
  
  _Arguments_:
!      I           Shall be of 'INTEGER' type.
!      J           Shall be of 'INTEGER' type, and of the same kind
                   as I.
  
  _Return value_:
!      The return value is of type 'LOGICAL' and of the default kind.
  
  _See also_:
       *note BGE::,
--- 9225,9239 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = BGT(I, J)’
  
  _Arguments_:
!      I           Shall be of ‘INTEGER’ type.
!      J           Shall be of ‘INTEGER’ type, and of the same kind
                   as I.
  
  _Return value_:
!      The return value is of type ‘LOGICAL’ and of the default kind.
  
  _See also_:
       *note BGE::,
*************** _See also_:
*** 9243,9255 ****
  
  File: gfortran.info,  Node: BIT_SIZE,  Next: BLE,  Prev: BGT,  Up: Intrinsic Procedures
  
! 8.48 'BIT_SIZE' -- Bit size inquiry function
  ============================================
  
  _Description_:
!      'BIT_SIZE(I)' returns the number of bits (integer precision plus
       sign bit) represented by the type of I.  The result of
!      'BIT_SIZE(I)' is independent of the actual value of I.
  
  _Standard_:
       Fortran 90 and later
--- 9243,9255 ----
  
  File: gfortran.info,  Node: BIT_SIZE,  Next: BLE,  Prev: BGT,  Up: Intrinsic Procedures
  
! 8.48 ‘BIT_SIZE’ -- Bit size inquiry function
  ============================================
  
  _Description_:
!      ‘BIT_SIZE(I)’ returns the number of bits (integer precision plus
       sign bit) represented by the type of I.  The result of
!      ‘BIT_SIZE(I)’ is independent of the actual value of I.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 9258,9270 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = BIT_SIZE(I)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER'
  
  _Example_:
            program test_bit_size
--- 9258,9270 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = BIT_SIZE(I)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’
  
  _Example_:
            program test_bit_size
*************** _Example_:
*** 9277,9283 ****
  
  File: gfortran.info,  Node: BLE,  Next: BLT,  Prev: BIT_SIZE,  Up: Intrinsic Procedures
  
! 8.49 'BLE' -- Bitwise less than or equal to
  ===========================================
  
  _Description_:
--- 9277,9283 ----
  
  File: gfortran.info,  Node: BLE,  Next: BLT,  Prev: BIT_SIZE,  Up: Intrinsic Procedures
  
! 8.49 ‘BLE’ -- Bitwise less than or equal to
  ===========================================
  
  _Description_:
*************** _Class_:
*** 9291,9305 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = BLE(I, J)'
  
  _Arguments_:
!      I           Shall be of 'INTEGER' type.
!      J           Shall be of 'INTEGER' type, and of the same kind
                   as I.
  
  _Return value_:
!      The return value is of type 'LOGICAL' and of the default kind.
  
  _See also_:
       *note BGT::,
--- 9291,9305 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = BLE(I, J)’
  
  _Arguments_:
!      I           Shall be of ‘INTEGER’ type.
!      J           Shall be of ‘INTEGER’ type, and of the same kind
                   as I.
  
  _Return value_:
!      The return value is of type ‘LOGICAL’ and of the default kind.
  
  _See also_:
       *note BGT::,
*************** _See also_:
*** 9309,9315 ****
  
  File: gfortran.info,  Node: BLT,  Next: BTEST,  Prev: BLE,  Up: Intrinsic Procedures
  
! 8.50 'BLT' -- Bitwise less than
  ===============================
  
  _Description_:
--- 9309,9315 ----
  
  File: gfortran.info,  Node: BLT,  Next: BTEST,  Prev: BLE,  Up: Intrinsic Procedures
  
! 8.50 ‘BLT’ -- Bitwise less than
  ===============================
  
  _Description_:
*************** _Class_:
*** 9322,9336 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = BLT(I, J)'
  
  _Arguments_:
!      I           Shall be of 'INTEGER' type.
!      J           Shall be of 'INTEGER' type, and of the same kind
                   as I.
  
  _Return value_:
!      The return value is of type 'LOGICAL' and of the default kind.
  
  _See also_:
       *note BGE::,
--- 9322,9336 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = BLT(I, J)’
  
  _Arguments_:
!      I           Shall be of ‘INTEGER’ type.
!      J           Shall be of ‘INTEGER’ type, and of the same kind
                   as I.
  
  _Return value_:
!      The return value is of type ‘LOGICAL’ and of the default kind.
  
  _See also_:
       *note BGE::,
*************** _See also_:
*** 9340,9350 ****
  
  File: gfortran.info,  Node: BTEST,  Next: C_ASSOCIATED,  Prev: BLT,  Up: Intrinsic Procedures
  
! 8.51 'BTEST' -- Bit test function
  =================================
  
  _Description_:
!      'BTEST(I,POS)' returns logical '.TRUE.' if the bit at POS in I is
       set.  The counting of the bits starts at 0.
  
  _Standard_:
--- 9340,9350 ----
  
  File: gfortran.info,  Node: BTEST,  Next: C_ASSOCIATED,  Prev: BLT,  Up: Intrinsic Procedures
  
! 8.51 ‘BTEST’ -- Bit test function
  =================================
  
  _Description_:
!      ‘BTEST(I,POS)’ returns logical ‘.TRUE.’ if the bit at POS in I is
       set.  The counting of the bits starts at 0.
  
  _Standard_:
*************** _Class_:
*** 9354,9367 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = BTEST(I, POS)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      POS         The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'LOGICAL'
  
  _Example_:
            program test_btest
--- 9354,9367 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = BTEST(I, POS)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      POS         The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘LOGICAL’
  
  _Example_:
            program test_btest
*************** _Example_:
*** 9377,9396 ****
  _Specific names_:
       Name            Argument             Return type   Standard
       --------------------------------------------------------------------------
!      'BTEST(I,POS)'  'INTEGER I,POS'      'LOGICAL'     Fortran 95 and later
!      'BBTEST(I,POS)' 'INTEGER(1) I,POS'   'LOGICAL(1)'  GNU extension
!      'BITEST(I,POS)' 'INTEGER(2) I,POS'   'LOGICAL(2)'  GNU extension
!      'BJTEST(I,POS)' 'INTEGER(4) I,POS'   'LOGICAL(4)'  GNU extension
!      'BKTEST(I,POS)' 'INTEGER(8) I,POS'   'LOGICAL(8)'  GNU extension
  
  
  File: gfortran.info,  Node: C_ASSOCIATED,  Next: C_F_POINTER,  Prev: BTEST,  Up: Intrinsic Procedures
  
! 8.52 'C_ASSOCIATED' -- Status of a C pointer
  ============================================
  
  _Description_:
!      'C_ASSOCIATED(c_ptr_1[, c_ptr_2])' determines the status of the C
       pointer C_PTR_1 or if C_PTR_1 is associated with the target
       C_PTR_2.
  
--- 9377,9396 ----
  _Specific names_:
       Name            Argument             Return type   Standard
       --------------------------------------------------------------------------
!      ‘BTEST(I,POS)’  ‘INTEGER I,POS’      ‘LOGICAL’     Fortran 95 and later
!      ‘BBTEST(I,POS)’ ‘INTEGER(1) I,POS’   ‘LOGICAL(1)’  GNU extension
!      ‘BITEST(I,POS)’ ‘INTEGER(2) I,POS’   ‘LOGICAL(2)’  GNU extension
!      ‘BJTEST(I,POS)’ ‘INTEGER(4) I,POS’   ‘LOGICAL(4)’  GNU extension
!      ‘BKTEST(I,POS)’ ‘INTEGER(8) I,POS’   ‘LOGICAL(8)’  GNU extension
  
  
  File: gfortran.info,  Node: C_ASSOCIATED,  Next: C_F_POINTER,  Prev: BTEST,  Up: Intrinsic Procedures
  
! 8.52 ‘C_ASSOCIATED’ -- Status of a C pointer
  ============================================
  
  _Description_:
!      ‘C_ASSOCIATED(c_ptr_1[, c_ptr_2])’ determines the status of the C
       pointer C_PTR_1 or if C_PTR_1 is associated with the target
       C_PTR_2.
  
*************** _Class_:
*** 9401,9414 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = C_ASSOCIATED(c_ptr_1[, c_ptr_2])'
  
  _Arguments_:
!      C_PTR_1     Scalar of the type 'C_PTR' or 'C_FUNPTR'.
       C_PTR_2     (Optional) Scalar of the same type as C_PTR_1.
  
  _Return value_:
!      The return value is of type 'LOGICAL'; it is '.false.' if either
       C_PTR_1 is a C NULL pointer or if C_PTR1 and C_PTR_2 point to
       different addresses.
  
--- 9401,9414 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = C_ASSOCIATED(c_ptr_1[, c_ptr_2])’
  
  _Arguments_:
!      C_PTR_1     Scalar of the type ‘C_PTR’ or ‘C_FUNPTR’.
       C_PTR_2     (Optional) Scalar of the same type as C_PTR_1.
  
  _Return value_:
!      The return value is of type ‘LOGICAL’; it is ‘.false.’ if either
       C_PTR_1 is a C NULL pointer or if C_PTR1 and C_PTR_2 point to
       different addresses.
  
*************** _See also_:
*** 9429,9439 ****
  
  File: gfortran.info,  Node: C_F_POINTER,  Next: C_F_PROCPOINTER,  Prev: C_ASSOCIATED,  Up: Intrinsic Procedures
  
! 8.53 'C_F_POINTER' -- Convert C into Fortran pointer
  ====================================================
  
  _Description_:
!      'C_F_POINTER(CPTR, FPTR[, SHAPE])' assigns the target of the C
       pointer CPTR to the Fortran pointer FPTR and specifies its shape.
  
  _Standard_:
--- 9429,9439 ----
  
  File: gfortran.info,  Node: C_F_POINTER,  Next: C_F_PROCPOINTER,  Prev: C_ASSOCIATED,  Up: Intrinsic Procedures
  
! 8.53 ‘C_F_POINTER’ -- Convert C into Fortran pointer
  ====================================================
  
  _Description_:
!      ‘C_F_POINTER(CPTR, FPTR[, SHAPE])’ assigns the target of the C
       pointer CPTR to the Fortran pointer FPTR and specifies its shape.
  
  _Standard_:
*************** _Class_:
*** 9443,9456 ****
       Subroutine
  
  _Syntax_:
!      'CALL C_F_POINTER(CPTR, FPTR[, SHAPE])'
  
  _Arguments_:
!      CPTR        scalar of the type 'C_PTR'.  It is 'INTENT(IN)'.
       FPTR        pointer interoperable with CPTR.  It is
!                  'INTENT(OUT)'.
!      SHAPE       (Optional) Rank-one array of type 'INTEGER' with
!                  'INTENT(IN)'.  It shall be present if and only
                   if FPTR is an array.  The size must be equal to
                   the rank of FPTR.
  
--- 9443,9456 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL C_F_POINTER(CPTR, FPTR[, SHAPE])’
  
  _Arguments_:
!      CPTR        scalar of the type ‘C_PTR’.  It is ‘INTENT(IN)’.
       FPTR        pointer interoperable with CPTR.  It is
!                  ‘INTENT(OUT)’.
!      SHAPE       (Optional) Rank-one array of type ‘INTEGER’ with
!                  ‘INTENT(IN)’.  It shall be present if and only
                   if FPTR is an array.  The size must be equal to
                   the rank of FPTR.
  
*************** _See also_:
*** 9477,9487 ****
  
  File: gfortran.info,  Node: C_F_PROCPOINTER,  Next: C_FUNLOC,  Prev: C_F_POINTER,  Up: Intrinsic Procedures
  
! 8.54 'C_F_PROCPOINTER' -- Convert C into Fortran procedure pointer
  ==================================================================
  
  _Description_:
!      'C_F_PROCPOINTER(CPTR, FPTR)' Assign the target of the C function
       pointer CPTR to the Fortran procedure pointer FPTR.
  
  _Standard_:
--- 9477,9487 ----
  
  File: gfortran.info,  Node: C_F_PROCPOINTER,  Next: C_FUNLOC,  Prev: C_F_POINTER,  Up: Intrinsic Procedures
  
! 8.54 ‘C_F_PROCPOINTER’ -- Convert C into Fortran procedure pointer
  ==================================================================
  
  _Description_:
!      ‘C_F_PROCPOINTER(CPTR, FPTR)’ Assign the target of the C function
       pointer CPTR to the Fortran procedure pointer FPTR.
  
  _Standard_:
*************** _Class_:
*** 9491,9503 ****
       Subroutine
  
  _Syntax_:
!      'CALL C_F_PROCPOINTER(cptr, fptr)'
  
  _Arguments_:
!      CPTR        scalar of the type 'C_FUNPTR'.  It is
!                  'INTENT(IN)'.
       FPTR        procedure pointer interoperable with CPTR.  It
!                  is 'INTENT(OUT)'.
  
  _Example_:
            program main
--- 9491,9503 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL C_F_PROCPOINTER(cptr, fptr)’
  
  _Arguments_:
!      CPTR        scalar of the type ‘C_FUNPTR’.  It is
!                  ‘INTENT(IN)’.
       FPTR        procedure pointer interoperable with CPTR.  It
!                  is ‘INTENT(OUT)’.
  
  _Example_:
            program main
*************** _See also_:
*** 9529,9539 ****
  
  File: gfortran.info,  Node: C_FUNLOC,  Next: C_LOC,  Prev: C_F_PROCPOINTER,  Up: Intrinsic Procedures
  
! 8.55 'C_FUNLOC' -- Obtain the C address of a procedure
  ======================================================
  
  _Description_:
!      'C_FUNLOC(x)' determines the C address of the argument.
  
  _Standard_:
       Fortran 2003 and later
--- 9529,9539 ----
  
  File: gfortran.info,  Node: C_FUNLOC,  Next: C_LOC,  Prev: C_F_PROCPOINTER,  Up: Intrinsic Procedures
  
! 8.55 ‘C_FUNLOC’ -- Obtain the C address of a procedure
  ======================================================
  
  _Description_:
!      ‘C_FUNLOC(x)’ determines the C address of the argument.
  
  _Standard_:
       Fortran 2003 and later
*************** _Class_:
*** 9542,9555 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = C_FUNLOC(x)'
  
  _Arguments_:
       X           Interoperable function or pointer to such
                   function.
  
  _Return value_:
!      The return value is of type 'C_FUNPTR' and contains the C address
       of the argument.
  
  _Example_:
--- 9542,9555 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = C_FUNLOC(x)’
  
  _Arguments_:
       X           Interoperable function or pointer to such
                   function.
  
  _Return value_:
!      The return value is of type ‘C_FUNPTR’ and contains the C address
       of the argument.
  
  _Example_:
*************** _See also_:
*** 9584,9594 ****
  
  File: gfortran.info,  Node: C_LOC,  Next: C_SIZEOF,  Prev: C_FUNLOC,  Up: Intrinsic Procedures
  
! 8.56 'C_LOC' -- Obtain the C address of an object
  =================================================
  
  _Description_:
!      'C_LOC(X)' determines the C address of the argument.
  
  _Standard_:
       Fortran 2003 and later
--- 9584,9594 ----
  
  File: gfortran.info,  Node: C_LOC,  Next: C_SIZEOF,  Prev: C_FUNLOC,  Up: Intrinsic Procedures
  
! 8.56 ‘C_LOC’ -- Obtain the C address of an object
  =================================================
  
  _Description_:
!      ‘C_LOC(X)’ determines the C address of the argument.
  
  _Standard_:
       Fortran 2003 and later
*************** _Class_:
*** 9597,9603 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = C_LOC(X)'
  
  _Arguments_:
       X       Shall have either the POINTER or TARGET attribute.
--- 9597,9603 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = C_LOC(X)’
  
  _Arguments_:
       X       Shall have either the POINTER or TARGET attribute.
*************** _Arguments_:
*** 9608,9614 ****
               
  
  _Return value_:
!      The return value is of type 'C_PTR' and contains the C address of
       the argument.
  
  _Example_:
--- 9608,9614 ----
               
  
  _Return value_:
!      The return value is of type ‘C_PTR’ and contains the C address of
       the argument.
  
  _Example_:
*************** _See also_:
*** 9630,9650 ****
  
  File: gfortran.info,  Node: C_SIZEOF,  Next: CEILING,  Prev: C_LOC,  Up: Intrinsic Procedures
  
! 8.57 'C_SIZEOF' -- Size in bytes of an expression
  =================================================
  
  _Description_:
!      'C_SIZEOF(X)' calculates the number of bytes of storage the
!      expression 'X' occupies.
  
  _Standard_:
       Fortran 2008
  
  _Class_:
!      Inquiry function of the module 'ISO_C_BINDING'
  
  _Syntax_:
!      'N = C_SIZEOF(X)'
  
  _Arguments_:
       X           The argument shall be an interoperable data
--- 9630,9650 ----
  
  File: gfortran.info,  Node: C_SIZEOF,  Next: CEILING,  Prev: C_LOC,  Up: Intrinsic Procedures
  
! 8.57 ‘C_SIZEOF’ -- Size in bytes of an expression
  =================================================
  
  _Description_:
!      ‘C_SIZEOF(X)’ calculates the number of bytes of storage the
!      expression ‘X’ occupies.
  
  _Standard_:
       Fortran 2008
  
  _Class_:
!      Inquiry function of the module ‘ISO_C_BINDING’
  
  _Syntax_:
!      ‘N = C_SIZEOF(X)’
  
  _Arguments_:
       X           The argument shall be an interoperable data
*************** _Arguments_:
*** 9652,9662 ****
  
  _Return value_:
       The return value is of type integer and of the system-dependent
!      kind 'C_SIZE_T' (from the 'ISO_C_BINDING' module).  Its value is
       the number of bytes occupied by the argument.  If the argument has
!      the 'POINTER' attribute, the number of bytes of the storage area
       pointed to is returned.  If the argument is of a derived type with
!      'POINTER' or 'ALLOCATABLE' components, the return value does not
       account for the sizes of the data pointed to by these components.
  
  _Example_:
--- 9652,9662 ----
  
  _Return value_:
       The return value is of type integer and of the system-dependent
!      kind ‘C_SIZE_T’ (from the ‘ISO_C_BINDING’ module).  Its value is
       the number of bytes occupied by the argument.  If the argument has
!      the ‘POINTER’ attribute, the number of bytes of the storage area
       pointed to is returned.  If the argument is of a derived type with
!      ‘POINTER’ or ‘ALLOCATABLE’ components, the return value does not
       account for the sizes of the data pointed to by these components.
  
  _Example_:
*************** _Example_:
*** 9665,9672 ****
               real(c_float) :: r, s(5)
               print *, (c_sizeof(s)/c_sizeof(r) == 5)
               end
!      The example will print 'T' unless you are using a platform where
!      default 'REAL' variables are unusually padded.
  
  _See also_:
       *note SIZEOF::,
--- 9665,9672 ----
               real(c_float) :: r, s(5)
               print *, (c_sizeof(s)/c_sizeof(r) == 5)
               end
!      The example will print ‘T’ unless you are using a platform where
!      default ‘REAL’ variables are unusually padded.
  
  _See also_:
       *note SIZEOF::,
*************** _See also_:
*** 9675,9685 ****
  
  File: gfortran.info,  Node: CEILING,  Next: CHAR,  Prev: C_SIZEOF,  Up: Intrinsic Procedures
  
! 8.58 'CEILING' -- Integer ceiling function
  ==========================================
  
  _Description_:
!      'CEILING(A)' returns the least integer greater than or equal to A.
  
  _Standard_:
       Fortran 95 and later
--- 9675,9685 ----
  
  File: gfortran.info,  Node: CEILING,  Next: CHAR,  Prev: C_SIZEOF,  Up: Intrinsic Procedures
  
! 8.58 ‘CEILING’ -- Integer ceiling function
  ==========================================
  
  _Description_:
!      ‘CEILING(A)’ returns the least integer greater than or equal to A.
  
  _Standard_:
       Fortran 95 and later
*************** _Class_:
*** 9688,9704 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = CEILING(A [, KIND])'
  
  _Arguments_:
!      A           The type shall be 'REAL'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER(KIND)' if KIND is present and
!      a default-kind 'INTEGER' otherwise.
  
  _Example_:
            program test_ceiling
--- 9688,9704 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = CEILING(A [, KIND])’
  
  _Arguments_:
!      A           The type shall be ‘REAL’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER(KIND)’ if KIND is present and
!      a default-kind ‘INTEGER’ otherwise.
  
  _Example_:
            program test_ceiling
*************** _See also_:
*** 9715,9725 ****
  
  File: gfortran.info,  Node: CHAR,  Next: CHDIR,  Prev: CEILING,  Up: Intrinsic Procedures
  
! 8.59 'CHAR' -- Character conversion function
  ============================================
  
  _Description_:
!      'CHAR(I [, KIND])' returns the character represented by the integer
       I.
  
  _Standard_:
--- 9715,9725 ----
  
  File: gfortran.info,  Node: CHAR,  Next: CHDIR,  Prev: CEILING,  Up: Intrinsic Procedures
  
! 8.59 ‘CHAR’ -- Character conversion function
  ============================================
  
  _Description_:
!      ‘CHAR(I [, KIND])’ returns the character represented by the integer
       I.
  
  _Standard_:
*************** _Class_:
*** 9729,9744 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = CHAR(I [, KIND])'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'CHARACTER(1)'
  
  _Example_:
            program test_char
--- 9729,9744 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = CHAR(I [, KIND])’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘CHARACTER(1)’
  
  _Example_:
            program test_char
*************** _Example_:
*** 9751,9757 ****
  _Specific names_:
       Name           Argument       Return type        Standard
       --------------------------------------------------------------------------
!      'CHAR(I)'      'INTEGER I'    'CHARACTER(LEN=1)' Fortran 77 and later
  
  _Note_:
       See *note ICHAR:: for a discussion of converting between numerical
--- 9751,9757 ----
  _Specific names_:
       Name           Argument       Return type        Standard
       --------------------------------------------------------------------------
!      ‘CHAR(I)’      ‘INTEGER I’    ‘CHARACTER(LEN=1)’ Fortran 77 and later
  
  _Note_:
       See *note ICHAR:: for a discussion of converting between numerical
*************** _See also_:
*** 9765,9771 ****
  
  File: gfortran.info,  Node: CHDIR,  Next: CHMOD,  Prev: CHAR,  Up: Intrinsic Procedures
  
! 8.60 'CHDIR' -- Change working directory
  ========================================
  
  _Description_:
--- 9765,9771 ----
  
  File: gfortran.info,  Node: CHDIR,  Next: CHMOD,  Prev: CHAR,  Up: Intrinsic Procedures
  
! 8.60 ‘CHDIR’ -- Change working directory
  ========================================
  
  _Description_:
*************** _Class_:
*** 9781,9794 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL CHDIR(NAME [, STATUS])'
!      'STATUS = CHDIR(NAME)'
  
  _Arguments_:
!      NAME        The type shall be 'CHARACTER' of default kind
                   and shall specify a valid path within the file
                   system.
!      STATUS      (Optional) 'INTEGER' status flag of the default
                   kind.  Returns 0 on success, and a system
                   specific and nonzero error code otherwise.
  
--- 9781,9794 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL CHDIR(NAME [, STATUS])’
!      ‘STATUS = CHDIR(NAME)’
  
  _Arguments_:
!      NAME        The type shall be ‘CHARACTER’ of default kind
                   and shall specify a valid path within the file
                   system.
!      STATUS      (Optional) ‘INTEGER’ status flag of the default
                   kind.  Returns 0 on success, and a system
                   specific and nonzero error code otherwise.
  
*************** _See also_:
*** 9808,9818 ****
  
  File: gfortran.info,  Node: CHMOD,  Next: CMPLX,  Prev: CHDIR,  Up: Intrinsic Procedures
  
! 8.61 'CHMOD' -- Change access permissions of files
  ==================================================
  
  _Description_:
!      'CHMOD' changes the permissions of a file.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 9808,9818 ----
  
  File: gfortran.info,  Node: CHMOD,  Next: CMPLX,  Prev: CHDIR,  Up: Intrinsic Procedures
  
! 8.61 ‘CHMOD’ -- Change access permissions of files
  ==================================================
  
  _Description_:
!      ‘CHMOD’ changes the permissions of a file.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 9824,9863 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL CHMOD(NAME, MODE[, STATUS])'
!      'STATUS = CHMOD(NAME, MODE)'
  
  _Arguments_:
  
!      NAME        Scalar 'CHARACTER' of default kind with the file
                   name.  Trailing blanks are ignored unless the
!                  character 'achar(0)' is present, then all
!                  characters up to and excluding 'achar(0)' are
                   used as the file name.
                   
!      MODE        Scalar 'CHARACTER' of default kind giving the
                   file permission.  MODE uses the same syntax as
!                  the 'chmod' utility as defined by the POSIX
                   standard.  The argument shall either be a string
                   of a nonnegative octal number or a symbolic
                   mode.
                   
!      STATUS      (optional) scalar 'INTEGER', which is '0' on
                   success and nonzero otherwise.
  
  _Return value_:
!      In either syntax, STATUS is set to '0' on success and nonzero
       otherwise.
  
  _Example_:
!      'CHMOD' as subroutine
            program chmod_test
              implicit none
              integer :: status
              call chmod('test.dat','u+x',status)
              print *, 'Status: ', status
            end program chmod_test
!      'CHMOD' as function:
            program chmod_test
              implicit none
              integer :: status
--- 9824,9863 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL CHMOD(NAME, MODE[, STATUS])’
!      ‘STATUS = CHMOD(NAME, MODE)’
  
  _Arguments_:
  
!      NAME        Scalar ‘CHARACTER’ of default kind with the file
                   name.  Trailing blanks are ignored unless the
!                  character ‘achar(0)’ is present, then all
!                  characters up to and excluding ‘achar(0)’ are
                   used as the file name.
                   
!      MODE        Scalar ‘CHARACTER’ of default kind giving the
                   file permission.  MODE uses the same syntax as
!                  the ‘chmod’ utility as defined by the POSIX
                   standard.  The argument shall either be a string
                   of a nonnegative octal number or a symbolic
                   mode.
                   
!      STATUS      (optional) scalar ‘INTEGER’, which is ‘0’ on
                   success and nonzero otherwise.
  
  _Return value_:
!      In either syntax, STATUS is set to ‘0’ on success and nonzero
       otherwise.
  
  _Example_:
!      ‘CHMOD’ as subroutine
            program chmod_test
              implicit none
              integer :: status
              call chmod('test.dat','u+x',status)
              print *, 'Status: ', status
            end program chmod_test
!      ‘CHMOD’ as function:
            program chmod_test
              implicit none
              integer :: status
*************** _Example_:
*** 9868,9878 ****
  
  File: gfortran.info,  Node: CMPLX,  Next: CO_BROADCAST,  Prev: CHMOD,  Up: Intrinsic Procedures
  
! 8.62 'CMPLX' -- Complex conversion function
  ===========================================
  
  _Description_:
!      'CMPLX(X [, Y [, KIND]])' returns a complex number where X is
       converted to the real component.  If Y is present it is converted
       to the imaginary component.  If Y is not present then the imaginary
       component is set to 0.0.  If X is complex then Y must not be
--- 9868,9878 ----
  
  File: gfortran.info,  Node: CMPLX,  Next: CO_BROADCAST,  Prev: CHMOD,  Up: Intrinsic Procedures
  
! 8.62 ‘CMPLX’ -- Complex conversion function
  ===========================================
  
  _Description_:
!      ‘CMPLX(X [, Y [, KIND]])’ returns a complex number where X is
       converted to the real component.  If Y is present it is converted
       to the imaginary component.  If Y is not present then the imaginary
       component is set to 0.0.  If X is complex then Y must not be
*************** _Class_:
*** 9885,9904 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = CMPLX(X [, Y [, KIND]])'
  
  _Arguments_:
!      X           The type may be 'INTEGER', 'REAL', or 'COMPLEX'.
!      Y           (Optional; only allowed if X is not 'COMPLEX'.)
!                  May be 'INTEGER' or 'REAL'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of 'COMPLEX' type, with a kind equal to KIND if
       it is specified.  If KIND is not specified, the result is of the
!      default 'COMPLEX' kind, regardless of the kinds of X and Y.
  
  _Example_:
            program test_cmplx
--- 9885,9904 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = CMPLX(X [, Y [, KIND]])’
  
  _Arguments_:
!      X           The type may be ‘INTEGER’, ‘REAL’, or ‘COMPLEX’.
!      Y           (Optional; only allowed if X is not ‘COMPLEX’.)
!                  May be ‘INTEGER’ or ‘REAL’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of ‘COMPLEX’ type, with a kind equal to KIND if
       it is specified.  If KIND is not specified, the result is of the
!      default ‘COMPLEX’ kind, regardless of the kinds of X and Y.
  
  _Example_:
            program test_cmplx
*************** _See also_:
*** 9915,9926 ****
  
  File: gfortran.info,  Node: CO_BROADCAST,  Next: CO_MAX,  Prev: CMPLX,  Up: Intrinsic Procedures
  
! 8.63 'CO_BROADCAST' -- Copy a value to all images the current set of images
  ===========================================================================
  
  _Description_:
!      'CO_BROADCAST' copies the value of argument A on the image with
!      image index 'SOURCE_IMAGE' to all images in the current team.  A
       becomes defined as if by intrinsic assignment.  If the execution
       was successful and STAT is present, it is assigned the value zero.
       If the execution failed, STAT gets assigned a nonzero value and, if
--- 9915,9926 ----
  
  File: gfortran.info,  Node: CO_BROADCAST,  Next: CO_MAX,  Prev: CMPLX,  Up: Intrinsic Procedures
  
! 8.63 ‘CO_BROADCAST’ -- Copy a value to all images the current set of images
  ===========================================================================
  
  _Description_:
!      ‘CO_BROADCAST’ copies the value of argument A on the image with
!      image index ‘SOURCE_IMAGE’ to all images in the current team.  A
       becomes defined as if by intrinsic assignment.  If the execution
       was successful and STAT is present, it is assigned the value zero.
       If the execution failed, STAT gets assigned a nonzero value and, if
*************** _Class_:
*** 9934,9940 ****
       Collective subroutine
  
  _Syntax_:
!      'CALL CO_BROADCAST(A, SOURCE_IMAGE [, STAT, ERRMSG])'
  
  _Arguments_:
       A              INTENT(INOUT) argument; shall have the same
--- 9934,9940 ----
       Collective subroutine
  
  _Syntax_:
!      ‘CALL CO_BROADCAST(A, SOURCE_IMAGE [, STAT, ERRMSG])’
  
  _Arguments_:
       A              INTENT(INOUT) argument; shall have the same
*************** _See also_:
*** 9967,9977 ****
  
  File: gfortran.info,  Node: CO_MAX,  Next: CO_MIN,  Prev: CO_BROADCAST,  Up: Intrinsic Procedures
  
! 8.64 'CO_MAX' -- Maximal value on the current set of images
  ===========================================================
  
  _Description_:
!      'CO_MAX' determines element-wise the maximal value of A on all
       images of the current team.  If RESULT_IMAGE is present, the
       maximum values are returned in A on the specified image only and
       the value of A on the other images become undefined.  If
--- 9967,9977 ----
  
  File: gfortran.info,  Node: CO_MAX,  Next: CO_MIN,  Prev: CO_BROADCAST,  Up: Intrinsic Procedures
  
! 8.64 ‘CO_MAX’ -- Maximal value on the current set of images
  ===========================================================
  
  _Description_:
!      ‘CO_MAX’ determines element-wise the maximal value of A on all
       images of the current team.  If RESULT_IMAGE is present, the
       maximum values are returned in A on the specified image only and
       the value of A on the other images become undefined.  If
*************** _Class_:
*** 9988,9994 ****
       Collective subroutine
  
  _Syntax_:
!      'CALL CO_MAX(A [, RESULT_IMAGE, STAT, ERRMSG])'
  
  _Arguments_:
       A              shall be an integer, real or character
--- 9988,9994 ----
       Collective subroutine
  
  _Syntax_:
!      ‘CALL CO_MAX(A [, RESULT_IMAGE, STAT, ERRMSG])’
  
  _Arguments_:
       A              shall be an integer, real or character
*************** _See also_:
*** 10020,10030 ****
  
  File: gfortran.info,  Node: CO_MIN,  Next: CO_REDUCE,  Prev: CO_MAX,  Up: Intrinsic Procedures
  
! 8.65 'CO_MIN' -- Minimal value on the current set of images
  ===========================================================
  
  _Description_:
!      'CO_MIN' determines element-wise the minimal value of A on all
       images of the current team.  If RESULT_IMAGE is present, the
       minimal values are returned in A on the specified image only and
       the value of A on the other images become undefined.  If
--- 10020,10030 ----
  
  File: gfortran.info,  Node: CO_MIN,  Next: CO_REDUCE,  Prev: CO_MAX,  Up: Intrinsic Procedures
  
! 8.65 ‘CO_MIN’ -- Minimal value on the current set of images
  ===========================================================
  
  _Description_:
!      ‘CO_MIN’ determines element-wise the minimal value of A on all
       images of the current team.  If RESULT_IMAGE is present, the
       minimal values are returned in A on the specified image only and
       the value of A on the other images become undefined.  If
*************** _Class_:
*** 10041,10047 ****
       Collective subroutine
  
  _Syntax_:
!      'CALL CO_MIN(A [, RESULT_IMAGE, STAT, ERRMSG])'
  
  _Arguments_:
       A              shall be an integer, real or character
--- 10041,10047 ----
       Collective subroutine
  
  _Syntax_:
!      ‘CALL CO_MIN(A [, RESULT_IMAGE, STAT, ERRMSG])’
  
  _Arguments_:
       A              shall be an integer, real or character
*************** _See also_:
*** 10073,10083 ****
  
  File: gfortran.info,  Node: CO_REDUCE,  Next: CO_SUM,  Prev: CO_MIN,  Up: Intrinsic Procedures
  
! 8.66 'CO_REDUCE' -- Reduction of values on the current set of images
  ====================================================================
  
  _Description_:
!      'CO_REDUCE' determines element-wise the reduction of the value of A
       on all images of the current team.  The pure function passed as
       OPERATION is used to pairwise reduce the values of A by passing
       either the value of A of different images or the result values of
--- 10073,10083 ----
  
  File: gfortran.info,  Node: CO_REDUCE,  Next: CO_SUM,  Prev: CO_MIN,  Up: Intrinsic Procedures
  
! 8.66 ‘CO_REDUCE’ -- Reduction of values on the current set of images
  ====================================================================
  
  _Description_:
!      ‘CO_REDUCE’ determines element-wise the reduction of the value of A
       on all images of the current team.  The pure function passed as
       OPERATION is used to pairwise reduce the values of A by passing
       either the value of A of different images or the result values of
*************** _Class_:
*** 10098,10107 ****
       Collective subroutine
  
  _Syntax_:
!      'CALL CO_REDUCE(A, OPERATION, [, RESULT_IMAGE, STAT, ERRMSG])'
  
  _Arguments_:
!      A              is an 'INTENT(INOUT)' argument and shall be
                      nonpolymorphic.  If it is allocatable, it
                      shall be allocated; if it is a pointer, it
                      shall be associated.  A shall have the same
--- 10098,10107 ----
       Collective subroutine
  
  _Syntax_:
!      ‘CALL CO_REDUCE(A, OPERATION, [, RESULT_IMAGE, STAT, ERRMSG])’
  
  _Arguments_:
!      A              is an ‘INTENT(INOUT)’ argument and shall be
                      nonpolymorphic.  If it is allocatable, it
                      shall be allocated; if it is a pointer, it
                      shall be associated.  A shall have the same
*************** _See also_:
*** 10156,10166 ****
  
  File: gfortran.info,  Node: CO_SUM,  Next: COMMAND_ARGUMENT_COUNT,  Prev: CO_REDUCE,  Up: Intrinsic Procedures
  
! 8.67 'CO_SUM' -- Sum of values on the current set of images
  ===========================================================
  
  _Description_:
!      'CO_SUM' sums up the values of each element of A on all images of
       the current team.  If RESULT_IMAGE is present, the summed-up values
       are returned in A on the specified image only and the value of A on
       the other images become undefined.  If RESULT_IMAGE is not present,
--- 10156,10166 ----
  
  File: gfortran.info,  Node: CO_SUM,  Next: COMMAND_ARGUMENT_COUNT,  Prev: CO_REDUCE,  Up: Intrinsic Procedures
  
! 8.67 ‘CO_SUM’ -- Sum of values on the current set of images
  ===========================================================
  
  _Description_:
!      ‘CO_SUM’ sums up the values of each element of A on all images of
       the current team.  If RESULT_IMAGE is present, the summed-up values
       are returned in A on the specified image only and the value of A on
       the other images become undefined.  If RESULT_IMAGE is not present,
*************** _Class_:
*** 10177,10183 ****
       Collective subroutine
  
  _Syntax_:
!      'CALL CO_SUM(A [, RESULT_IMAGE, STAT, ERRMSG])'
  
  _Arguments_:
       A              shall be an integer, real or complex
--- 10177,10183 ----
       Collective subroutine
  
  _Syntax_:
!      ‘CALL CO_SUM(A [, RESULT_IMAGE, STAT, ERRMSG])’
  
  _Arguments_:
       A              shall be an integer, real or complex
*************** _See also_:
*** 10210,10220 ****
  
  File: gfortran.info,  Node: COMMAND_ARGUMENT_COUNT,  Next: COMPILER_OPTIONS,  Prev: CO_SUM,  Up: Intrinsic Procedures
  
! 8.68 'COMMAND_ARGUMENT_COUNT' -- Get number of command line arguments
  =====================================================================
  
  _Description_:
!      'COMMAND_ARGUMENT_COUNT' returns the number of arguments passed on
       the command line when the containing program was invoked.
  
  _Standard_:
--- 10210,10220 ----
  
  File: gfortran.info,  Node: COMMAND_ARGUMENT_COUNT,  Next: COMPILER_OPTIONS,  Prev: CO_SUM,  Up: Intrinsic Procedures
  
! 8.68 ‘COMMAND_ARGUMENT_COUNT’ -- Get number of command line arguments
  =====================================================================
  
  _Description_:
!      ‘COMMAND_ARGUMENT_COUNT’ returns the number of arguments passed on
       the command line when the containing program was invoked.
  
  _Standard_:
*************** _Class_:
*** 10224,10236 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = COMMAND_ARGUMENT_COUNT()'
  
  _Arguments_:
       None
  
  _Return value_:
!      The return value is an 'INTEGER' of default kind.
  
  _Example_:
            program test_command_argument_count
--- 10224,10236 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = COMMAND_ARGUMENT_COUNT()’
  
  _Arguments_:
       None
  
  _Return value_:
!      The return value is an ‘INTEGER’ of default kind.
  
  _Example_:
            program test_command_argument_count
*************** _See also_:
*** 10246,10266 ****
  
  File: gfortran.info,  Node: COMPILER_OPTIONS,  Next: COMPILER_VERSION,  Prev: COMMAND_ARGUMENT_COUNT,  Up: Intrinsic Procedures
  
! 8.69 'COMPILER_OPTIONS' -- Options passed to the compiler
  =========================================================
  
  _Description_:
!      'COMPILER_OPTIONS' returns a string with the options used for
       compiling.
  
  _Standard_:
       Fortran 2008
  
  _Class_:
!      Inquiry function of the module 'ISO_FORTRAN_ENV'
  
  _Syntax_:
!      'STR = COMPILER_OPTIONS()'
  
  _Arguments_:
       None
--- 10246,10266 ----
  
  File: gfortran.info,  Node: COMPILER_OPTIONS,  Next: COMPILER_VERSION,  Prev: COMMAND_ARGUMENT_COUNT,  Up: Intrinsic Procedures
  
! 8.69 ‘COMPILER_OPTIONS’ -- Options passed to the compiler
  =========================================================
  
  _Description_:
!      ‘COMPILER_OPTIONS’ returns a string with the options used for
       compiling.
  
  _Standard_:
       Fortran 2008
  
  _Class_:
!      Inquiry function of the module ‘ISO_FORTRAN_ENV’
  
  _Syntax_:
!      ‘STR = COMPILER_OPTIONS()’
  
  _Arguments_:
       None
*************** _Arguments_:
*** 10268,10274 ****
  _Return value_:
       The return value is a default-kind string with system-dependent
       length.  It contains the compiler flags used to compile the file,
!      which called the 'COMPILER_OPTIONS' intrinsic.
  
  _Example_:
               use iso_fortran_env
--- 10268,10274 ----
  _Return value_:
       The return value is a default-kind string with system-dependent
       length.  It contains the compiler flags used to compile the file,
!      which called the ‘COMPILER_OPTIONS’ intrinsic.
  
  _Example_:
               use iso_fortran_env
*************** _See also_:
*** 10284,10304 ****
  
  File: gfortran.info,  Node: COMPILER_VERSION,  Next: COMPLEX,  Prev: COMPILER_OPTIONS,  Up: Intrinsic Procedures
  
! 8.70 'COMPILER_VERSION' -- Compiler version string
  ==================================================
  
  _Description_:
!      'COMPILER_VERSION' returns a string with the name and the version
       of the compiler.
  
  _Standard_:
       Fortran 2008
  
  _Class_:
!      Inquiry function of the module 'ISO_FORTRAN_ENV'
  
  _Syntax_:
!      'STR = COMPILER_VERSION()'
  
  _Arguments_:
       None
--- 10284,10304 ----
  
  File: gfortran.info,  Node: COMPILER_VERSION,  Next: COMPLEX,  Prev: COMPILER_OPTIONS,  Up: Intrinsic Procedures
  
! 8.70 ‘COMPILER_VERSION’ -- Compiler version string
  ==================================================
  
  _Description_:
!      ‘COMPILER_VERSION’ returns a string with the name and the version
       of the compiler.
  
  _Standard_:
       Fortran 2008
  
  _Class_:
!      Inquiry function of the module ‘ISO_FORTRAN_ENV’
  
  _Syntax_:
!      ‘STR = COMPILER_VERSION()’
  
  _Arguments_:
       None
*************** _See also_:
*** 10322,10332 ****
  
  File: gfortran.info,  Node: COMPLEX,  Next: CONJG,  Prev: COMPILER_VERSION,  Up: Intrinsic Procedures
  
! 8.71 'COMPLEX' -- Complex conversion function
  =============================================
  
  _Description_:
!      'COMPLEX(X, Y)' returns a complex number where X is converted to
       the real component and Y is converted to the imaginary component.
  
  _Standard_:
--- 10322,10332 ----
  
  File: gfortran.info,  Node: COMPLEX,  Next: CONJG,  Prev: COMPILER_VERSION,  Up: Intrinsic Procedures
  
! 8.71 ‘COMPLEX’ -- Complex conversion function
  =============================================
  
  _Description_:
!      ‘COMPLEX(X, Y)’ returns a complex number where X is converted to
       the real component and Y is converted to the imaginary component.
  
  _Standard_:
*************** _Class_:
*** 10336,10354 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = COMPLEX(X, Y)'
  
  _Arguments_:
!      X           The type may be 'INTEGER' or 'REAL'.
!      Y           The type may be 'INTEGER' or 'REAL'.
  
  _Return value_:
!      If X and Y are both of 'INTEGER' type, then the return value is of
!      default 'COMPLEX' type.
  
!      If X and Y are of 'REAL' type, or one is of 'REAL' type and one is
!      of 'INTEGER' type, then the return value is of 'COMPLEX' type with
!      a kind equal to that of the 'REAL' argument with the highest
       precision.
  
  _Example_:
--- 10336,10354 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = COMPLEX(X, Y)’
  
  _Arguments_:
!      X           The type may be ‘INTEGER’ or ‘REAL’.
!      Y           The type may be ‘INTEGER’ or ‘REAL’.
  
  _Return value_:
!      If X and Y are both of ‘INTEGER’ type, then the return value is of
!      default ‘COMPLEX’ type.
  
!      If X and Y are of ‘REAL’ type, or one is of ‘REAL’ type and one is
!      of ‘INTEGER’ type, then the return value is of ‘COMPLEX’ type with
!      a kind equal to that of the ‘REAL’ argument with the highest
       precision.
  
  _Example_:
*************** _See also_:
*** 10364,10375 ****
  
  File: gfortran.info,  Node: CONJG,  Next: COS,  Prev: COMPLEX,  Up: Intrinsic Procedures
  
! 8.72 'CONJG' -- Complex conjugate function
  ==========================================
  
  _Description_:
!      'CONJG(Z)' returns the conjugate of Z.  If Z is '(x, y)' then the
!      result is '(x, -y)'
  
  _Standard_:
       Fortran 77 and later, has an overload that is a GNU extension
--- 10364,10375 ----
  
  File: gfortran.info,  Node: CONJG,  Next: COS,  Prev: COMPLEX,  Up: Intrinsic Procedures
  
! 8.72 ‘CONJG’ -- Complex conjugate function
  ==========================================
  
  _Description_:
!      ‘CONJG(Z)’ returns the conjugate of Z.  If Z is ‘(x, y)’ then the
!      result is ‘(x, -y)’
  
  _Standard_:
       Fortran 77 and later, has an overload that is a GNU extension
*************** _Class_:
*** 10378,10390 ****
       Elemental function
  
  _Syntax_:
!      'Z = CONJG(Z)'
  
  _Arguments_:
!      Z           The type shall be 'COMPLEX'.
  
  _Return value_:
!      The return value is of type 'COMPLEX'.
  
  _Example_:
            program test_conjg
--- 10378,10390 ----
       Elemental function
  
  _Syntax_:
!      ‘Z = CONJG(Z)’
  
  _Arguments_:
!      Z           The type shall be ‘COMPLEX’.
  
  _Return value_:
!      The return value is of type ‘COMPLEX’.
  
  _Example_:
            program test_conjg
*************** _Example_:
*** 10399,10414 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DCONJG(Z)'    'COMPLEX(8) Z'    'COMPLEX(8)'   GNU extension
  
  
  File: gfortran.info,  Node: COS,  Next: COSD,  Prev: CONJG,  Up: Intrinsic Procedures
  
! 8.73 'COS' -- Cosine function
  =============================
  
  _Description_:
!      'COS(X)' computes the cosine of X.
  
  _Standard_:
       Fortran 77 and later, has overloads that are GNU extensions
--- 10399,10414 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DCONJG(Z)’    ‘COMPLEX(8) Z’    ‘COMPLEX(8)’   GNU extension
  
  
  File: gfortran.info,  Node: COS,  Next: COSD,  Prev: CONJG,  Up: Intrinsic Procedures
  
! 8.73 ‘COS’ -- Cosine function
  =============================
  
  _Description_:
!      ‘COS(X)’ computes the cosine of X.
  
  _Standard_:
       Fortran 77 and later, has overloads that are GNU extensions
*************** _Class_:
*** 10417,10430 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = COS(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
!      of the result is in radians.  If X is of the type 'REAL', the
       return value lies in the range -1 \leq \cos (x) \leq 1.
  
  _Example_:
--- 10417,10430 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = COS(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
!      of the result is in radians.  If X is of the type ‘REAL’, the
       return value lies in the range -1 \leq \cos (x) \leq 1.
  
  _Example_:
*************** _Example_:
*** 10436,10446 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'COS(X)'       'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DCOS(X)'      'REAL(8) X'       'REAL(8)'      Fortran 77 and later
!      'CCOS(X)'      'COMPLEX(4) X'    'COMPLEX(4)'   Fortran 77 and later
!      'ZCOS(X)'      'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
!      'CDCOS(X)'     'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
  
  _See also_:
       Inverse function:
--- 10436,10446 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘COS(X)’       ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DCOS(X)’      ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
!      ‘CCOS(X)’      ‘COMPLEX(4) X’    ‘COMPLEX(4)’   Fortran 77 and later
!      ‘ZCOS(X)’      ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
!      ‘CDCOS(X)’     ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 10451,10480 ****
  
  File: gfortran.info,  Node: COSD,  Next: COSH,  Prev: COS,  Up: Intrinsic Procedures
  
! 8.74 'COSD' -- Cosine function, degrees
  =======================================
  
  _Description_:
!      'COSD(X)' computes the cosine of X in degrees.
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with '-fdec-math'.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      'RESULT = COSD(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
!      of the result is in degrees.  If X is of the type 'REAL', the
       return value lies in the range -1 \leq \cosd (x) \leq 1.
  
  _Example_:
--- 10451,10480 ----
  
  File: gfortran.info,  Node: COSD,  Next: COSH,  Prev: COS,  Up: Intrinsic Procedures
  
! 8.74 ‘COSD’ -- Cosine function, degrees
  =======================================
  
  _Description_:
!      ‘COSD(X)’ computes the cosine of X in degrees.
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with ‘-fdec-math’.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      ‘RESULT = COSD(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real part
!      of the result is in degrees.  If X is of the type ‘REAL’, the
       return value lies in the range -1 \leq \cosd (x) \leq 1.
  
  _Example_:
*************** _Example_:
*** 10486,10496 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'COSD(X)'      'REAL(4) X'       'REAL(4)'      GNU extension
!      'DCOSD(X)'     'REAL(8) X'       'REAL(8)'      GNU extension
!      'CCOSD(X)'     'COMPLEX(4) X'    'COMPLEX(4)'   GNU extension
!      'ZCOSD(X)'     'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
!      'CDCOSD(X)'    'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
  
  _See also_:
       Inverse function:
--- 10486,10496 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘COSD(X)’      ‘REAL(4) X’       ‘REAL(4)’      GNU extension
!      ‘DCOSD(X)’     ‘REAL(8) X’       ‘REAL(8)’      GNU extension
!      ‘CCOSD(X)’     ‘COMPLEX(4) X’    ‘COMPLEX(4)’   GNU extension
!      ‘ZCOSD(X)’     ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
!      ‘CDCOSD(X)’    ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 10501,10511 ****
  
  File: gfortran.info,  Node: COSH,  Next: COTAN,  Prev: COSD,  Up: Intrinsic Procedures
  
! 8.75 'COSH' -- Hyperbolic cosine function
  =========================================
  
  _Description_:
!      'COSH(X)' computes the hyperbolic cosine of X.
  
  _Standard_:
       Fortran 77 and later, for a complex argument Fortran 2008 or later
--- 10501,10511 ----
  
  File: gfortran.info,  Node: COSH,  Next: COTAN,  Prev: COSD,  Up: Intrinsic Procedures
  
! 8.75 ‘COSH’ -- Hyperbolic cosine function
  =========================================
  
  _Description_:
!      ‘COSH(X)’ computes the hyperbolic cosine of X.
  
  _Standard_:
       Fortran 77 and later, for a complex argument Fortran 2008 or later
*************** _Class_:
*** 10514,10527 ****
       Elemental function
  
  _Syntax_:
!      'X = COSH(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X.  If X is complex, the
!      imaginary part of the result is in radians.  If X is 'REAL', the
       return value has a lower bound of one, \cosh (x) \geq 1.
  
  _Example_:
--- 10514,10527 ----
       Elemental function
  
  _Syntax_:
!      ‘X = COSH(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X.  If X is complex, the
!      imaginary part of the result is in radians.  If X is ‘REAL’, the
       return value has a lower bound of one, \cosh (x) \geq 1.
  
  _Example_:
*************** _Example_:
*** 10533,10540 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'COSH(X)'      'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DCOSH(X)'     'REAL(8) X'       'REAL(8)'      Fortran 77 and later
  
  _See also_:
       Inverse function:
--- 10533,10540 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘COSH(X)’      ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DCOSH(X)’     ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 10543,10569 ****
  
  File: gfortran.info,  Node: COTAN,  Next: COTAND,  Prev: COSH,  Up: Intrinsic Procedures
  
! 8.76 'COTAN' -- Cotangent function
  ==================================
  
  _Description_:
!      'COTAN(X)' computes the cotangent of X.  Equivalent to 'COS(x)'
!      divided by 'SIN(x)', or '1 / TAN(x)'.
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with '-fdec-math'.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      'RESULT = COTAN(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X, and its value is in
--- 10543,10569 ----
  
  File: gfortran.info,  Node: COTAN,  Next: COTAND,  Prev: COSH,  Up: Intrinsic Procedures
  
! 8.76 ‘COTAN’ -- Cotangent function
  ==================================
  
  _Description_:
!      ‘COTAN(X)’ computes the cotangent of X.  Equivalent to ‘COS(x)’
!      divided by ‘SIN(x)’, or ‘1 / TAN(x)’.
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with ‘-fdec-math’.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      ‘RESULT = COTAN(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X, and its value is in
*************** _Example_:
*** 10578,10585 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'COTAN(X)'     'REAL(4) X'       'REAL(4)'      GNU extension
!      'DCOTAN(X)'    'REAL(8) X'       'REAL(8)'      GNU extension
  
  _See also_:
       Converse function:
--- 10578,10585 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘COTAN(X)’     ‘REAL(4) X’       ‘REAL(4)’      GNU extension
!      ‘DCOTAN(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  _See also_:
       Converse function:
*************** _See also_:
*** 10590,10604 ****
  
  File: gfortran.info,  Node: COTAND,  Next: COUNT,  Prev: COTAN,  Up: Intrinsic Procedures
  
! 8.77 'COTAND' -- Cotangent function, degrees
  ============================================
  
  _Description_:
!      'COTAND(X)' computes the cotangent of X in degrees.  Equivalent to
!      'COSD(x)' divided by 'SIND(x)', or '1 / TAND(x)'.
  
  _Standard_:
!      GNU extension, enabled with '-fdec-math'.
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
--- 10590,10604 ----
  
  File: gfortran.info,  Node: COTAND,  Next: COUNT,  Prev: COTAN,  Up: Intrinsic Procedures
  
! 8.77 ‘COTAND’ -- Cotangent function, degrees
  ============================================
  
  _Description_:
!      ‘COTAND(X)’ computes the cotangent of X in degrees.  Equivalent to
!      ‘COSD(x)’ divided by ‘SIND(x)’, or ‘1 / TAND(x)’.
  
  _Standard_:
!      GNU extension, enabled with ‘-fdec-math’.
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
*************** _Class_:
*** 10607,10616 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = COTAND(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X, and its value is in
--- 10607,10616 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = COTAND(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X, and its value is in
*************** _Example_:
*** 10625,10632 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'COTAND(X)'    'REAL(4) X'       'REAL(4)'      GNU extension
!      'DCOTAND(X)'   'REAL(8) X'       'REAL(8)'      GNU extension
  
  _See also_:
       Converse function:
--- 10625,10632 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘COTAND(X)’    ‘REAL(4) X’       ‘REAL(4)’      GNU extension
!      ‘DCOTAND(X)’   ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  _See also_:
       Converse function:
*************** _See also_:
*** 10637,10652 ****
  
  File: gfortran.info,  Node: COUNT,  Next: CPU_TIME,  Prev: COTAND,  Up: Intrinsic Procedures
  
! 8.78 'COUNT' -- Count function
  ==============================
  
  _Description_:
  
!      Counts the number of '.TRUE.' elements in a logical MASK, or, if
       the DIM argument is supplied, counts the number of elements along
       each row of the array in the DIM direction.  If the array has zero
!      size, or all of the elements of MASK are '.FALSE.', then the result
!      is '0'.
  
  _Standard_:
       Fortran 90 and later, with KIND argument Fortran 2003 and later
--- 10637,10652 ----
  
  File: gfortran.info,  Node: COUNT,  Next: CPU_TIME,  Prev: COTAND,  Up: Intrinsic Procedures
  
! 8.78 ‘COUNT’ -- Count function
  ==============================
  
  _Description_:
  
!      Counts the number of ‘.TRUE.’ elements in a logical MASK, or, if
       the DIM argument is supplied, counts the number of elements along
       each row of the array in the DIM direction.  If the array has zero
!      size, or all of the elements of MASK are ‘.FALSE.’, then the result
!      is ‘0’.
  
  _Standard_:
       Fortran 90 and later, with KIND argument Fortran 2003 and later
*************** _Class_:
*** 10655,10671 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = COUNT(MASK [, DIM, KIND])'
  
  _Arguments_:
!      MASK        The type shall be 'LOGICAL'.
!      DIM         (Optional) The type shall be 'INTEGER'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.  If DIM is
       present, the result is an array with a rank one less than the rank
       of ARRAY, and a size corresponding to the shape of ARRAY with the
--- 10655,10671 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = COUNT(MASK [, DIM, KIND])’
  
  _Arguments_:
!      MASK        The type shall be ‘LOGICAL’.
!      DIM         (Optional) The type shall be ‘INTEGER’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.  If DIM is
       present, the result is an array with a rank one less than the rank
       of ARRAY, and a size corresponding to the shape of ARRAY with the
*************** _Example_:
*** 10697,10716 ****
  
  File: gfortran.info,  Node: CPU_TIME,  Next: CSHIFT,  Prev: COUNT,  Up: Intrinsic Procedures
  
! 8.79 'CPU_TIME' -- CPU elapsed time in seconds
  ==============================================
  
  _Description_:
!      Returns a 'REAL' value representing the elapsed CPU time in
       seconds.  This is useful for testing segments of code to determine
       execution time.
  
       If a time source is available, time will be reported with
       microsecond resolution.  If no time source is available, TIME is
!      set to '-1.0'.
  
       Note that TIME may contain a, system dependent, arbitrary offset
!      and may not start with '0.0'.  For 'CPU_TIME', the absolute value
       is meaningless, only differences between subsequent calls to this
       subroutine, as shown in the example below, should be used.
  
--- 10697,10716 ----
  
  File: gfortran.info,  Node: CPU_TIME,  Next: CSHIFT,  Prev: COUNT,  Up: Intrinsic Procedures
  
! 8.79 ‘CPU_TIME’ -- CPU elapsed time in seconds
  ==============================================
  
  _Description_:
!      Returns a ‘REAL’ value representing the elapsed CPU time in
       seconds.  This is useful for testing segments of code to determine
       execution time.
  
       If a time source is available, time will be reported with
       microsecond resolution.  If no time source is available, TIME is
!      set to ‘-1.0’.
  
       Note that TIME may contain a, system dependent, arbitrary offset
!      and may not start with ‘0.0’.  For ‘CPU_TIME’, the absolute value
       is meaningless, only differences between subsequent calls to this
       subroutine, as shown in the example below, should be used.
  
*************** _Class_:
*** 10721,10730 ****
       Subroutine
  
  _Syntax_:
!      'CALL CPU_TIME(TIME)'
  
  _Arguments_:
!      TIME        The type shall be 'REAL' with 'INTENT(OUT)'.
  
  _Return value_:
       None
--- 10721,10730 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL CPU_TIME(TIME)’
  
  _Arguments_:
!      TIME        The type shall be ‘REAL’ with ‘INTENT(OUT)’.
  
  _Return value_:
       None
*************** _See also_:
*** 10745,10757 ****
  
  File: gfortran.info,  Node: CSHIFT,  Next: CTIME,  Prev: CPU_TIME,  Up: Intrinsic Procedures
  
! 8.80 'CSHIFT' -- Circular shift elements of an array
  ====================================================
  
  _Description_:
!      'CSHIFT(ARRAY, SHIFT [, DIM])' performs a circular shift on
       elements of ARRAY along the dimension of DIM.  If DIM is omitted it
!      is taken to be '1'.  DIM is a scalar of type 'INTEGER' in the range
       of 1 \leq DIM \leq n) where n is the rank of ARRAY.  If the rank of
       ARRAY is one, then all elements of ARRAY are shifted by SHIFT
       places.  If rank is greater than one, then all complete rank one
--- 10745,10757 ----
  
  File: gfortran.info,  Node: CSHIFT,  Next: CTIME,  Prev: CPU_TIME,  Up: Intrinsic Procedures
  
! 8.80 ‘CSHIFT’ -- Circular shift elements of an array
  ====================================================
  
  _Description_:
!      ‘CSHIFT(ARRAY, SHIFT [, DIM])’ performs a circular shift on
       elements of ARRAY along the dimension of DIM.  If DIM is omitted it
!      is taken to be ‘1’.  DIM is a scalar of type ‘INTEGER’ in the range
       of 1 \leq DIM \leq n) where n is the rank of ARRAY.  If the rank of
       ARRAY is one, then all elements of ARRAY are shifted by SHIFT
       places.  If rank is greater than one, then all complete rank one
*************** _Class_:
*** 10766,10777 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = CSHIFT(ARRAY, SHIFT [, DIM])'
  
  _Arguments_:
       ARRAY       Shall be an array of any type.
!      SHIFT       The type shall be 'INTEGER'.
!      DIM         The type shall be 'INTEGER'.
  
  _Return value_:
       Returns an array of same type and rank as the ARRAY argument.
--- 10766,10777 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = CSHIFT(ARRAY, SHIFT [, DIM])’
  
  _Arguments_:
       ARRAY       Shall be an array of any type.
!      SHIFT       The type shall be ‘INTEGER’.
!      DIM         The type shall be ‘INTEGER’.
  
  _Return value_:
       Returns an array of same type and rank as the ARRAY argument.
*************** _Example_:
*** 10793,10805 ****
  
  File: gfortran.info,  Node: CTIME,  Next: DATE_AND_TIME,  Prev: CSHIFT,  Up: Intrinsic Procedures
  
! 8.81 'CTIME' -- Convert a time into a string
  ============================================
  
  _Description_:
!      'CTIME' converts a system time value, such as returned by *note
!      TIME8::, to a string.  The output will be of the form 'Sat Aug 19
!      18:13:14 1995'.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 10793,10805 ----
  
  File: gfortran.info,  Node: CTIME,  Next: DATE_AND_TIME,  Prev: CSHIFT,  Up: Intrinsic Procedures
  
! 8.81 ‘CTIME’ -- Convert a time into a string
  ============================================
  
  _Description_:
!      ‘CTIME’ converts a system time value, such as returned by *note
!      TIME8::, to a string.  The output will be of the form ‘Sat Aug 19
!      18:13:14 1995’.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 10811,10823 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL CTIME(TIME, RESULT)'.
!      'RESULT = CTIME(TIME)'.
  
  _Arguments_:
!      TIME        The type shall be of type 'INTEGER'.
!      RESULT      The type shall be of type 'CHARACTER' and of
!                  default kind.  It is an 'INTENT(OUT)' argument.
                   If the length of this variable is too short for
                   the time and date string to fit completely, it
                   will be blank on procedure return.
--- 10811,10823 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL CTIME(TIME, RESULT)’.
!      ‘RESULT = CTIME(TIME)’.
  
  _Arguments_:
!      TIME        The type shall be of type ‘INTEGER’.
!      RESULT      The type shall be of type ‘CHARACTER’ and of
!                  default kind.  It is an ‘INTENT(OUT)’ argument.
                   If the length of this variable is too short for
                   the time and date string to fit completely, it
                   will be blank on procedure return.
*************** _See Also_:
*** 10847,10873 ****
  
  File: gfortran.info,  Node: DATE_AND_TIME,  Next: DBLE,  Prev: CTIME,  Up: Intrinsic Procedures
  
! 8.82 'DATE_AND_TIME' -- Date and time subroutine
  ================================================
  
  _Description_:
!      'DATE_AND_TIME(DATE, TIME, ZONE, VALUES)' gets the corresponding
       date and time information from the real-time system clock.  DATE is
!      'INTENT(OUT)' and has form ccyymmdd.  TIME is 'INTENT(OUT)' and has
!      form hhmmss.sss.  ZONE is 'INTENT(OUT)' and has form (+-)hhmm,
       representing the difference with respect to Coordinated Universal
       Time (UTC). Unavailable time and date parameters return blanks.
  
!      VALUES is 'INTENT(OUT)' and provides the following:
  
!      'VALUE(1)': The year
!      'VALUE(2)': The month
!      'VALUE(3)': The day of the month
!      'VALUE(4)': Time difference with UTC in minutes
!      'VALUE(5)': The hour of the day
!      'VALUE(6)': The minutes of the hour
!      'VALUE(7)': The seconds of the minute
!      'VALUE(8)': The milliseconds of the second
  
  _Standard_:
       Fortran 90 and later
--- 10847,10873 ----
  
  File: gfortran.info,  Node: DATE_AND_TIME,  Next: DBLE,  Prev: CTIME,  Up: Intrinsic Procedures
  
! 8.82 ‘DATE_AND_TIME’ -- Date and time subroutine
  ================================================
  
  _Description_:
!      ‘DATE_AND_TIME(DATE, TIME, ZONE, VALUES)’ gets the corresponding
       date and time information from the real-time system clock.  DATE is
!      ‘INTENT(OUT)’ and has form ccyymmdd.  TIME is ‘INTENT(OUT)’ and has
!      form hhmmss.sss.  ZONE is ‘INTENT(OUT)’ and has form (+-)hhmm,
       representing the difference with respect to Coordinated Universal
       Time (UTC). Unavailable time and date parameters return blanks.
  
!      VALUES is ‘INTENT(OUT)’ and provides the following:
  
!      ‘VALUE(1)’: The year
!      ‘VALUE(2)’: The month
!      ‘VALUE(3)’: The day of the month
!      ‘VALUE(4)’: Time difference with UTC in minutes
!      ‘VALUE(5)’: The hour of the day
!      ‘VALUE(6)’: The minutes of the hour
!      ‘VALUE(7)’: The seconds of the minute
!      ‘VALUE(8)’: The milliseconds of the second
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 10876,10891 ****
       Subroutine
  
  _Syntax_:
!      'CALL DATE_AND_TIME([DATE, TIME, ZONE, VALUES])'
  
  _Arguments_:
!      DATE        (Optional) The type shall be 'CHARACTER(LEN=8)'
                   or larger, and of default kind.
!      TIME        (Optional) The type shall be 'CHARACTER(LEN=10)'
                   or larger, and of default kind.
!      ZONE        (Optional) The type shall be 'CHARACTER(LEN=5)'
                   or larger, and of default kind.
!      VALUES      (Optional) The type shall be 'INTEGER(8)'.
  
  _Return value_:
       None
--- 10876,10891 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL DATE_AND_TIME([DATE, TIME, ZONE, VALUES])’
  
  _Arguments_:
!      DATE        (Optional) The type shall be ‘CHARACTER(LEN=8)’
                   or larger, and of default kind.
!      TIME        (Optional) The type shall be ‘CHARACTER(LEN=10)’
                   or larger, and of default kind.
!      ZONE        (Optional) The type shall be ‘CHARACTER(LEN=5)’
                   or larger, and of default kind.
!      VALUES      (Optional) The type shall be ‘INTEGER(8)’.
  
  _Return value_:
       None
*************** _See also_:
*** 10912,10922 ****
  
  File: gfortran.info,  Node: DBLE,  Next: DCMPLX,  Prev: DATE_AND_TIME,  Up: Intrinsic Procedures
  
! 8.83 'DBLE' -- Double conversion function
  =========================================
  
  _Description_:
!      'DBLE(A)' Converts A to double precision real type.
  
  _Standard_:
       Fortran 77 and later
--- 10912,10922 ----
  
  File: gfortran.info,  Node: DBLE,  Next: DCMPLX,  Prev: DATE_AND_TIME,  Up: Intrinsic Procedures
  
! 8.83 ‘DBLE’ -- Double conversion function
  =========================================
  
  _Description_:
!      ‘DBLE(A)’ Converts A to double precision real type.
  
  _Standard_:
       Fortran 77 and later
*************** _Class_:
*** 10925,10935 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = DBLE(A)'
  
  _Arguments_:
!      A           The type shall be 'INTEGER', 'REAL', or
!                  'COMPLEX'.
  
  _Return value_:
       The return value is of type double precision real.
--- 10925,10935 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = DBLE(A)’
  
  _Arguments_:
!      A           The type shall be ‘INTEGER’, ‘REAL’, or
!                  ‘COMPLEX’.
  
  _Return value_:
       The return value is of type double precision real.
*************** _See also_:
*** 10948,10958 ****
  
  File: gfortran.info,  Node: DCMPLX,  Next: DIGITS,  Prev: DBLE,  Up: Intrinsic Procedures
  
! 8.84 'DCMPLX' -- Double complex conversion function
  ===================================================
  
  _Description_:
!      'DCMPLX(X [,Y])' returns a double complex number where X is
       converted to the real component.  If Y is present it is converted
       to the imaginary component.  If Y is not present then the imaginary
       component is set to 0.0.  If X is complex then Y must not be
--- 10948,10958 ----
  
  File: gfortran.info,  Node: DCMPLX,  Next: DIGITS,  Prev: DBLE,  Up: Intrinsic Procedures
  
! 8.84 ‘DCMPLX’ -- Double complex conversion function
  ===================================================
  
  _Description_:
!      ‘DCMPLX(X [,Y])’ returns a double complex number where X is
       converted to the real component.  If Y is present it is converted
       to the imaginary component.  If Y is not present then the imaginary
       component is set to 0.0.  If X is complex then Y must not be
*************** _Class_:
*** 10965,10979 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = DCMPLX(X [, Y])'
  
  _Arguments_:
!      X           The type may be 'INTEGER', 'REAL', or 'COMPLEX'.
!      Y           (Optional if X is not 'COMPLEX'.)  May be
!                  'INTEGER' or 'REAL'.
  
  _Return value_:
!      The return value is of type 'COMPLEX(8)'
  
  _Example_:
            program test_dcmplx
--- 10965,10979 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = DCMPLX(X [, Y])’
  
  _Arguments_:
!      X           The type may be ‘INTEGER’, ‘REAL’, or ‘COMPLEX’.
!      Y           (Optional if X is not ‘COMPLEX’.)  May be
!                  ‘INTEGER’ or ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘COMPLEX(8)’
  
  _Example_:
            program test_dcmplx
*************** _Example_:
*** 10990,11000 ****
  
  File: gfortran.info,  Node: DIGITS,  Next: DIM,  Prev: DCMPLX,  Up: Intrinsic Procedures
  
! 8.85 'DIGITS' -- Significant binary digits function
  ===================================================
  
  _Description_:
!      'DIGITS(X)' returns the number of significant binary digits of the
       internal model representation of X.  For example, on a system using
       a 32-bit floating point representation, a default real number would
       likely return 24.
--- 10990,11000 ----
  
  File: gfortran.info,  Node: DIGITS,  Next: DIM,  Prev: DCMPLX,  Up: Intrinsic Procedures
  
! 8.85 ‘DIGITS’ -- Significant binary digits function
  ===================================================
  
  _Description_:
!      ‘DIGITS(X)’ returns the number of significant binary digits of the
       internal model representation of X.  For example, on a system using
       a 32-bit floating point representation, a default real number would
       likely return 24.
*************** _Class_:
*** 11006,11018 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = DIGITS(X)'
  
  _Arguments_:
!      X           The type may be 'INTEGER' or 'REAL'.
  
  _Return value_:
!      The return value is of type 'INTEGER'.
  
  _Example_:
            program test_digits
--- 11006,11018 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = DIGITS(X)’
  
  _Arguments_:
!      X           The type may be ‘INTEGER’ or ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’.
  
  _Example_:
            program test_digits
*************** _Example_:
*** 11027,11037 ****
  
  File: gfortran.info,  Node: DIM,  Next: DOT_PRODUCT,  Prev: DIGITS,  Up: Intrinsic Procedures
  
! 8.86 'DIM' -- Positive difference
  =================================
  
  _Description_:
!      'DIM(X,Y)' returns the difference 'X-Y' if the result is positive;
       otherwise returns zero.
  
  _Standard_:
--- 11027,11037 ----
  
  File: gfortran.info,  Node: DIM,  Next: DOT_PRODUCT,  Prev: DIGITS,  Up: Intrinsic Procedures
  
! 8.86 ‘DIM’ -- Positive difference
  =================================
  
  _Description_:
!      ‘DIM(X,Y)’ returns the difference ‘X-Y’ if the result is positive;
       otherwise returns zero.
  
  _Standard_:
*************** _Class_:
*** 11041,11056 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = DIM(X, Y)'
  
  _Arguments_:
!      X           The type shall be 'INTEGER' or 'REAL'
       Y           The type shall be the same type and kind as X.
                   (As a GNU extension, arguments of different
                   kinds are permitted.)
  
  _Return value_:
!      The return value is of type 'INTEGER' or 'REAL'.  (As a GNU
       extension, kind is the largest kind of the actual arguments.)
  
  _Example_:
--- 11041,11056 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = DIM(X, Y)’
  
  _Arguments_:
!      X           The type shall be ‘INTEGER’ or ‘REAL’
       Y           The type shall be the same type and kind as X.
                   (As a GNU extension, arguments of different
                   kinds are permitted.)
  
  _Return value_:
!      The return value is of type ‘INTEGER’ or ‘REAL’.  (As a GNU
       extension, kind is the largest kind of the actual arguments.)
  
  _Example_:
*************** _Example_:
*** 11066,11089 ****
  _Specific names_:
       Name           Argument            Return type    Standard
       -------------------------------------------------------------------------
!      'DIM(X,Y)'     'REAL(4) X, Y'      'REAL(4)'      Fortran 77 and later
!      'IDIM(X,Y)'    'INTEGER(4) X, Y'   'INTEGER(4)'   Fortran 77 and later
!      'DDIM(X,Y)'    'REAL(8) X, Y'      'REAL(8)'      Fortran 77 and later
  
  
  File: gfortran.info,  Node: DOT_PRODUCT,  Next: DPROD,  Prev: DIM,  Up: Intrinsic Procedures
  
! 8.87 'DOT_PRODUCT' -- Dot product function
  ==========================================
  
  _Description_:
!      'DOT_PRODUCT(VECTOR_A, VECTOR_B)' computes the dot product
       multiplication of two vectors VECTOR_A and VECTOR_B.  The two
       vectors may be either numeric or logical and must be arrays of rank
!      one and of equal size.  If the vectors are 'INTEGER' or 'REAL', the
!      result is 'SUM(VECTOR_A*VECTOR_B)'.  If the vectors are 'COMPLEX',
!      the result is 'SUM(CONJG(VECTOR_A)*VECTOR_B)'.  If the vectors are
!      'LOGICAL', the result is 'ANY(VECTOR_A .AND. VECTOR_B)'.
  
  _Standard_:
       Fortran 90 and later
--- 11066,11089 ----
  _Specific names_:
       Name           Argument            Return type    Standard
       -------------------------------------------------------------------------
!      ‘DIM(X,Y)’     ‘REAL(4) X, Y’      ‘REAL(4)’      Fortran 77 and later
!      ‘IDIM(X,Y)’    ‘INTEGER(4) X, Y’   ‘INTEGER(4)’   Fortran 77 and later
!      ‘DDIM(X,Y)’    ‘REAL(8) X, Y’      ‘REAL(8)’      Fortran 77 and later
  
  
  File: gfortran.info,  Node: DOT_PRODUCT,  Next: DPROD,  Prev: DIM,  Up: Intrinsic Procedures
  
! 8.87 ‘DOT_PRODUCT’ -- Dot product function
  ==========================================
  
  _Description_:
!      ‘DOT_PRODUCT(VECTOR_A, VECTOR_B)’ computes the dot product
       multiplication of two vectors VECTOR_A and VECTOR_B.  The two
       vectors may be either numeric or logical and must be arrays of rank
!      one and of equal size.  If the vectors are ‘INTEGER’ or ‘REAL’, the
!      result is ‘SUM(VECTOR_A*VECTOR_B)’.  If the vectors are ‘COMPLEX’,
!      the result is ‘SUM(CONJG(VECTOR_A)*VECTOR_B)’.  If the vectors are
!      ‘LOGICAL’, the result is ‘ANY(VECTOR_A .AND. VECTOR_B)’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 11092,11109 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = DOT_PRODUCT(VECTOR_A, VECTOR_B)'
  
  _Arguments_:
!      VECTOR_A    The type shall be numeric or 'LOGICAL', rank 1.
       VECTOR_B    The type shall be numeric if VECTOR_A is of
!                  numeric type or 'LOGICAL' if VECTOR_A is of type
!                  'LOGICAL'.  VECTOR_B shall be a rank-one array.
  
  _Return value_:
       If the arguments are numeric, the return value is a scalar of
!      numeric type, 'INTEGER', 'REAL', or 'COMPLEX'.  If the arguments
!      are 'LOGICAL', the return value is '.TRUE.' or '.FALSE.'.
  
  _Example_:
            program test_dot_prod
--- 11092,11109 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = DOT_PRODUCT(VECTOR_A, VECTOR_B)’
  
  _Arguments_:
!      VECTOR_A    The type shall be numeric or ‘LOGICAL’, rank 1.
       VECTOR_B    The type shall be numeric if VECTOR_A is of
!                  numeric type or ‘LOGICAL’ if VECTOR_A is of type
!                  ‘LOGICAL’.  VECTOR_B shall be a rank-one array.
  
  _Return value_:
       If the arguments are numeric, the return value is a scalar of
!      numeric type, ‘INTEGER’, ‘REAL’, or ‘COMPLEX’.  If the arguments
!      are ‘LOGICAL’, the return value is ‘.TRUE.’ or ‘.FALSE.’.
  
  _Example_:
            program test_dot_prod
*************** _Example_:
*** 11120,11130 ****
  
  File: gfortran.info,  Node: DPROD,  Next: DREAL,  Prev: DOT_PRODUCT,  Up: Intrinsic Procedures
  
! 8.88 'DPROD' -- Double product function
  =======================================
  
  _Description_:
!      'DPROD(X,Y)' returns the product 'X*Y'.
  
  _Standard_:
       Fortran 77 and later
--- 11120,11130 ----
  
  File: gfortran.info,  Node: DPROD,  Next: DREAL,  Prev: DOT_PRODUCT,  Up: Intrinsic Procedures
  
! 8.88 ‘DPROD’ -- Double product function
  =======================================
  
  _Description_:
!      ‘DPROD(X,Y)’ returns the product ‘X*Y’.
  
  _Standard_:
       Fortran 77 and later
*************** _Class_:
*** 11133,11146 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = DPROD(X, Y)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
!      Y           The type shall be 'REAL'.
  
  _Return value_:
!      The return value is of type 'REAL(8)'.
  
  _Example_:
            program test_dprod
--- 11133,11146 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = DPROD(X, Y)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
!      Y           The type shall be ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘REAL(8)’.
  
  _Example_:
            program test_dprod
*************** _Example_:
*** 11154,11169 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DPROD(X,Y)'   'REAL(4) X, Y'    'REAL(8)'      Fortran 77 and later
  
  
  File: gfortran.info,  Node: DREAL,  Next: DSHIFTL,  Prev: DPROD,  Up: Intrinsic Procedures
  
! 8.89 'DREAL' -- Double real part function
  =========================================
  
  _Description_:
!      'DREAL(Z)' returns the real part of complex variable Z.
  
  _Standard_:
       GNU extension
--- 11154,11169 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DPROD(X,Y)’   ‘REAL(4) X, Y’    ‘REAL(8)’      Fortran 77 and later
  
  
  File: gfortran.info,  Node: DREAL,  Next: DSHIFTL,  Prev: DPROD,  Up: Intrinsic Procedures
  
! 8.89 ‘DREAL’ -- Double real part function
  =========================================
  
  _Description_:
!      ‘DREAL(Z)’ returns the real part of complex variable Z.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 11172,11184 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = DREAL(A)'
  
  _Arguments_:
!      A           The type shall be 'COMPLEX(8)'.
  
  _Return value_:
!      The return value is of type 'REAL(8)'.
  
  _Example_:
            program test_dreal
--- 11172,11184 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = DREAL(A)’
  
  _Arguments_:
!      A           The type shall be ‘COMPLEX(8)’.
  
  _Return value_:
!      The return value is of type ‘REAL(8)’.
  
  _Example_:
            program test_dreal
*************** _See also_:
*** 11192,11202 ****
  
  File: gfortran.info,  Node: DSHIFTL,  Next: DSHIFTR,  Prev: DREAL,  Up: Intrinsic Procedures
  
! 8.90 'DSHIFTL' -- Combined left shift
  =====================================
  
  _Description_:
!      'DSHIFTL(I, J, SHIFT)' combines bits of I and J.  The rightmost
       SHIFT bits of the result are the leftmost SHIFT bits of J, and the
       remaining bits are the rightmost bits of I.
  
--- 11192,11202 ----
  
  File: gfortran.info,  Node: DSHIFTL,  Next: DSHIFTR,  Prev: DREAL,  Up: Intrinsic Procedures
  
! 8.90 ‘DSHIFTL’ -- Combined left shift
  =====================================
  
  _Description_:
!      ‘DSHIFTL(I, J, SHIFT)’ combines bits of I and J.  The rightmost
       SHIFT bits of the result are the leftmost SHIFT bits of J, and the
       remaining bits are the rightmost bits of I.
  
*************** _Class_:
*** 11207,11229 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = DSHIFTL(I, J, SHIFT)'
  
  _Arguments_:
!      I           Shall be of type 'INTEGER' or a BOZ constant.
!      J           Shall be of type 'INTEGER' or a BOZ constant.
                   If both I and J have integer type, then they
                   shall have the same kind type parameter.  I and
                   J shall not both be BOZ constants.
!      SHIFT       Shall be of type 'INTEGER'.  It shall be
                   nonnegative.  If I is not a BOZ constant, then
                   SHIFT shall be less than or equal to
!                  'BIT_SIZE(I)'; otherwise, SHIFT shall be less
!                  than or equal to 'BIT_SIZE(J)'.
  
  _Return value_:
       If either I or J is a BOZ constant, it is first converted as if by
!      the intrinsic function 'INT' to an integer type with the kind type
       parameter of the other.
  
  _See also_:
--- 11207,11229 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = DSHIFTL(I, J, SHIFT)’
  
  _Arguments_:
!      I           Shall be of type ‘INTEGER’ or a BOZ constant.
!      J           Shall be of type ‘INTEGER’ or a BOZ constant.
                   If both I and J have integer type, then they
                   shall have the same kind type parameter.  I and
                   J shall not both be BOZ constants.
!      SHIFT       Shall be of type ‘INTEGER’.  It shall be
                   nonnegative.  If I is not a BOZ constant, then
                   SHIFT shall be less than or equal to
!                  ‘BIT_SIZE(I)’; otherwise, SHIFT shall be less
!                  than or equal to ‘BIT_SIZE(J)’.
  
  _Return value_:
       If either I or J is a BOZ constant, it is first converted as if by
!      the intrinsic function ‘INT’ to an integer type with the kind type
       parameter of the other.
  
  _See also_:
*************** _See also_:
*** 11232,11242 ****
  
  File: gfortran.info,  Node: DSHIFTR,  Next: DTIME,  Prev: DSHIFTL,  Up: Intrinsic Procedures
  
! 8.91 'DSHIFTR' -- Combined right shift
  ======================================
  
  _Description_:
!      'DSHIFTR(I, J, SHIFT)' combines bits of I and J.  The leftmost
       SHIFT bits of the result are the rightmost SHIFT bits of I, and the
       remaining bits are the leftmost bits of J.
  
--- 11232,11242 ----
  
  File: gfortran.info,  Node: DSHIFTR,  Next: DTIME,  Prev: DSHIFTL,  Up: Intrinsic Procedures
  
! 8.91 ‘DSHIFTR’ -- Combined right shift
  ======================================
  
  _Description_:
!      ‘DSHIFTR(I, J, SHIFT)’ combines bits of I and J.  The leftmost
       SHIFT bits of the result are the rightmost SHIFT bits of I, and the
       remaining bits are the leftmost bits of J.
  
*************** _Class_:
*** 11247,11269 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = DSHIFTR(I, J, SHIFT)'
  
  _Arguments_:
!      I           Shall be of type 'INTEGER' or a BOZ constant.
!      J           Shall be of type 'INTEGER' or a BOZ constant.
                   If both I and J have integer type, then they
                   shall have the same kind type parameter.  I and
                   J shall not both be BOZ constants.
!      SHIFT       Shall be of type 'INTEGER'.  It shall be
                   nonnegative.  If I is not a BOZ constant, then
                   SHIFT shall be less than or equal to
!                  'BIT_SIZE(I)'; otherwise, SHIFT shall be less
!                  than or equal to 'BIT_SIZE(J)'.
  
  _Return value_:
       If either I or J is a BOZ constant, it is first converted as if by
!      the intrinsic function 'INT' to an integer type with the kind type
       parameter of the other.
  
  _See also_:
--- 11247,11269 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = DSHIFTR(I, J, SHIFT)’
  
  _Arguments_:
!      I           Shall be of type ‘INTEGER’ or a BOZ constant.
!      J           Shall be of type ‘INTEGER’ or a BOZ constant.
                   If both I and J have integer type, then they
                   shall have the same kind type parameter.  I and
                   J shall not both be BOZ constants.
!      SHIFT       Shall be of type ‘INTEGER’.  It shall be
                   nonnegative.  If I is not a BOZ constant, then
                   SHIFT shall be less than or equal to
!                  ‘BIT_SIZE(I)’; otherwise, SHIFT shall be less
!                  than or equal to ‘BIT_SIZE(J)’.
  
  _Return value_:
       If either I or J is a BOZ constant, it is first converted as if by
!      the intrinsic function ‘INT’ to an integer type with the kind type
       parameter of the other.
  
  _See also_:
*************** _See also_:
*** 11272,11288 ****
  
  File: gfortran.info,  Node: DTIME,  Next: EOSHIFT,  Prev: DSHIFTR,  Up: Intrinsic Procedures
  
! 8.92 'DTIME' -- Execution time subroutine (or function)
  =======================================================
  
  _Description_:
!      'DTIME(VALUES, TIME)' initially returns the number of seconds of
       runtime since the start of the process's execution in TIME.  VALUES
!      returns the user and system components of this time in 'VALUES(1)'
!      and 'VALUES(2)' respectively.  TIME is equal to 'VALUES(1) +
!      VALUES(2)'.
  
!      Subsequent invocations of 'DTIME' return values accumulated since
       the previous invocation.
  
       On some systems, the underlying timings are represented using types
--- 11272,11288 ----
  
  File: gfortran.info,  Node: DTIME,  Next: EOSHIFT,  Prev: DSHIFTR,  Up: Intrinsic Procedures
  
! 8.92 ‘DTIME’ -- Execution time subroutine (or function)
  =======================================================
  
  _Description_:
!      ‘DTIME(VALUES, TIME)’ initially returns the number of seconds of
       runtime since the start of the process's execution in TIME.  VALUES
!      returns the user and system components of this time in ‘VALUES(1)’
!      and ‘VALUES(2)’ respectively.  TIME is equal to ‘VALUES(1) +
!      VALUES(2)’.
  
!      Subsequent invocations of ‘DTIME’ return values accumulated since
       the previous invocation.
  
       On some systems, the underlying timings are represented using types
*************** _Description_:
*** 11293,11311 ****
  
       Please note, that this implementation is thread safe if used within
       OpenMP directives, i.e., its state will be consistent while called
!      from multiple threads.  However, if 'DTIME' is called from multiple
       threads, the result is still the time since the last invocation.
       This may not give the intended results.  If possible, use
!      'CPU_TIME' instead.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      VALUES and TIME are 'INTENT(OUT)' and provide the following:
  
!      'VALUES(1)':User time in seconds.
!      'VALUES(2)':System time in seconds.
!      'TIME':     Run time since start in seconds.
  
  _Standard_:
       GNU extension
--- 11293,11311 ----
  
       Please note, that this implementation is thread safe if used within
       OpenMP directives, i.e., its state will be consistent while called
!      from multiple threads.  However, if ‘DTIME’ is called from multiple
       threads, the result is still the time since the last invocation.
       This may not give the intended results.  If possible, use
!      ‘CPU_TIME’ instead.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      VALUES and TIME are ‘INTENT(OUT)’ and provide the following:
  
!      ‘VALUES(1)’:User time in seconds.
!      ‘VALUES(2)’:System time in seconds.
!      ‘TIME’:     Run time since start in seconds.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 11314,11325 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL DTIME(VALUES, TIME)'.
!      'TIME = DTIME(VALUES)', (not recommended).
  
  _Arguments_:
!      VALUES      The type shall be 'REAL(4), DIMENSION(2)'.
!      TIME        The type shall be 'REAL(4)'.
  
  _Return value_:
       Elapsed time in seconds since the last invocation or since the
--- 11314,11325 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL DTIME(VALUES, TIME)’.
!      ‘TIME = DTIME(VALUES)’, (not recommended).
  
  _Arguments_:
!      VALUES      The type shall be ‘REAL(4), DIMENSION(2)’.
!      TIME        The type shall be ‘REAL(4)’.
  
  _Return value_:
       Elapsed time in seconds since the last invocation or since the
*************** _See also_:
*** 11349,11361 ****
  
  File: gfortran.info,  Node: EOSHIFT,  Next: EPSILON,  Prev: DTIME,  Up: Intrinsic Procedures
  
! 8.93 'EOSHIFT' -- End-off shift elements of an array
  ====================================================
  
  _Description_:
!      'EOSHIFT(ARRAY, SHIFT[, BOUNDARY, DIM])' performs an end-off shift
       on elements of ARRAY along the dimension of DIM.  If DIM is omitted
!      it is taken to be '1'.  DIM is a scalar of type 'INTEGER' in the
       range of 1 \leq DIM \leq n) where n is the rank of ARRAY.  If the
       rank of ARRAY is one, then all elements of ARRAY are shifted by
       SHIFT places.  If rank is greater than one, then all complete rank
--- 11349,11361 ----
  
  File: gfortran.info,  Node: EOSHIFT,  Next: EPSILON,  Prev: DTIME,  Up: Intrinsic Procedures
  
! 8.93 ‘EOSHIFT’ -- End-off shift elements of an array
  ====================================================
  
  _Description_:
!      ‘EOSHIFT(ARRAY, SHIFT[, BOUNDARY, DIM])’ performs an end-off shift
       on elements of ARRAY along the dimension of DIM.  If DIM is omitted
!      it is taken to be ‘1’.  DIM is a scalar of type ‘INTEGER’ in the
       range of 1 \leq DIM \leq n) where n is the rank of ARRAY.  If the
       rank of ARRAY is one, then all elements of ARRAY are shifted by
       SHIFT places.  If rank is greater than one, then all complete rank
*************** _Description_:
*** 11369,11375 ****
       _Array      _Boundary Value_
       Type_
       Numeric     0 of the type and kind of ARRAY.
!      Logical     '.FALSE.'.
       Character(LEN)LEN blanks.
  
  _Standard_:
--- 11369,11375 ----
       _Array      _Boundary Value_
       Type_
       Numeric     0 of the type and kind of ARRAY.
!      Logical     ‘.FALSE.’.
       Character(LEN)LEN blanks.
  
  _Standard_:
*************** _Class_:
*** 11379,11391 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = EOSHIFT(ARRAY, SHIFT [, BOUNDARY, DIM])'
  
  _Arguments_:
       ARRAY       May be any type, not scalar.
!      SHIFT       The type shall be 'INTEGER'.
       BOUNDARY    Same type as ARRAY.
!      DIM         The type shall be 'INTEGER'.
  
  _Return value_:
       Returns an array of same type and rank as the ARRAY argument.
--- 11379,11391 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = EOSHIFT(ARRAY, SHIFT [, BOUNDARY, DIM])’
  
  _Arguments_:
       ARRAY       May be any type, not scalar.
!      SHIFT       The type shall be ‘INTEGER’.
       BOUNDARY    Same type as ARRAY.
!      DIM         The type shall be ‘INTEGER’.
  
  _Return value_:
       Returns an array of same type and rank as the ARRAY argument.
*************** _Example_:
*** 11407,11417 ****
  
  File: gfortran.info,  Node: EPSILON,  Next: ERF,  Prev: EOSHIFT,  Up: Intrinsic Procedures
  
! 8.94 'EPSILON' -- Epsilon function
  ==================================
  
  _Description_:
!      'EPSILON(X)' returns the smallest number E of the same kind as X
       such that 1 + E > 1.
  
  _Standard_:
--- 11407,11417 ----
  
  File: gfortran.info,  Node: EPSILON,  Next: ERF,  Prev: EOSHIFT,  Up: Intrinsic Procedures
  
! 8.94 ‘EPSILON’ -- Epsilon function
  ==================================
  
  _Description_:
!      ‘EPSILON(X)’ returns the smallest number E of the same kind as X
       such that 1 + E > 1.
  
  _Standard_:
*************** _Class_:
*** 11421,11430 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = EPSILON(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
  
  _Return value_:
       The return value is of same type as the argument.
--- 11421,11430 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = EPSILON(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
  
  _Return value_:
       The return value is of same type as the argument.
*************** _Example_:
*** 11440,11450 ****
  
  File: gfortran.info,  Node: ERF,  Next: ERFC,  Prev: EPSILON,  Up: Intrinsic Procedures
  
! 8.95 'ERF' -- Error function
  ============================
  
  _Description_:
!      'ERF(X)' computes the error function of X.
  
  _Standard_:
       Fortran 2008 and later
--- 11440,11450 ----
  
  File: gfortran.info,  Node: ERF,  Next: ERFC,  Prev: EPSILON,  Up: Intrinsic Procedures
  
! 8.95 ‘ERF’ -- Error function
  ============================
  
  _Description_:
!      ‘ERF(X)’ computes the error function of X.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 11453,11465 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ERF(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
  
  _Return value_:
!      The return value is of type 'REAL', of the same kind as X and lies
       in the range -1 \leq erf (x) \leq 1 .
  
  _Example_:
--- 11453,11465 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ERF(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘REAL’, of the same kind as X and lies
       in the range -1 \leq erf (x) \leq 1 .
  
  _Example_:
*************** _Example_:
*** 11471,11486 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DERF(X)'      'REAL(8) X'       'REAL(8)'      GNU extension
  
  
  File: gfortran.info,  Node: ERFC,  Next: ERFC_SCALED,  Prev: ERF,  Up: Intrinsic Procedures
  
! 8.96 'ERFC' -- Error function
  =============================
  
  _Description_:
!      'ERFC(X)' computes the complementary error function of X.
  
  _Standard_:
       Fortran 2008 and later
--- 11471,11486 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DERF(X)’      ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  
  File: gfortran.info,  Node: ERFC,  Next: ERFC_SCALED,  Prev: ERF,  Up: Intrinsic Procedures
  
! 8.96 ‘ERFC’ -- Error function
  =============================
  
  _Description_:
!      ‘ERFC(X)’ computes the complementary error function of X.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 11489,11501 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ERFC(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
  
  _Return value_:
!      The return value is of type 'REAL' and of the same kind as X.  It
       lies in the range 0 \leq erfc (x) \leq 2 .
  
  _Example_:
--- 11489,11501 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ERFC(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘REAL’ and of the same kind as X.  It
       lies in the range 0 \leq erfc (x) \leq 2 .
  
  _Example_:
*************** _Example_:
*** 11507,11522 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DERFC(X)'     'REAL(8) X'       'REAL(8)'      GNU extension
  
  
  File: gfortran.info,  Node: ERFC_SCALED,  Next: ETIME,  Prev: ERFC,  Up: Intrinsic Procedures
  
! 8.97 'ERFC_SCALED' -- Error function
  ====================================
  
  _Description_:
!      'ERFC_SCALED(X)' computes the exponentially-scaled complementary
       error function of X.
  
  _Standard_:
--- 11507,11522 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DERFC(X)’     ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  
  File: gfortran.info,  Node: ERFC_SCALED,  Next: ETIME,  Prev: ERFC,  Up: Intrinsic Procedures
  
! 8.97 ‘ERFC_SCALED’ -- Error function
  ====================================
  
  _Description_:
!      ‘ERFC_SCALED(X)’ computes the exponentially-scaled complementary
       error function of X.
  
  _Standard_:
*************** _Class_:
*** 11526,11538 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ERFC_SCALED(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
  
  _Return value_:
!      The return value is of type 'REAL' and of the same kind as X.
  
  _Example_:
            program test_erfc_scaled
--- 11526,11538 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ERFC_SCALED(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘REAL’ and of the same kind as X.
  
  _Example_:
            program test_erfc_scaled
*************** _Example_:
*** 11543,11557 ****
  
  File: gfortran.info,  Node: ETIME,  Next: EVENT_QUERY,  Prev: ERFC_SCALED,  Up: Intrinsic Procedures
  
! 8.98 'ETIME' -- Execution time subroutine (or function)
  =======================================================
  
  _Description_:
!      'ETIME(VALUES, TIME)' returns the number of seconds of runtime
       since the start of the process's execution in TIME.  VALUES returns
!      the user and system components of this time in 'VALUES(1)' and
!      'VALUES(2)' respectively.  TIME is equal to 'VALUES(1) +
!      VALUES(2)'.
  
       On some systems, the underlying timings are represented using types
       with sufficiently small limits that overflows (wrap around) are
--- 11543,11557 ----
  
  File: gfortran.info,  Node: ETIME,  Next: EVENT_QUERY,  Prev: ERFC_SCALED,  Up: Intrinsic Procedures
  
! 8.98 ‘ETIME’ -- Execution time subroutine (or function)
  =======================================================
  
  _Description_:
!      ‘ETIME(VALUES, TIME)’ returns the number of seconds of runtime
       since the start of the process's execution in TIME.  VALUES returns
!      the user and system components of this time in ‘VALUES(1)’ and
!      ‘VALUES(2)’ respectively.  TIME is equal to ‘VALUES(1) +
!      VALUES(2)’.
  
       On some systems, the underlying timings are represented using types
       with sufficiently small limits that overflows (wrap around) are
*************** _Description_:
*** 11562,11572 ****
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      VALUES and TIME are 'INTENT(OUT)' and provide the following:
  
!      'VALUES(1)':User time in seconds.
!      'VALUES(2)':System time in seconds.
!      'TIME':     Run time since start in seconds.
  
  _Standard_:
       GNU extension
--- 11562,11572 ----
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      VALUES and TIME are ‘INTENT(OUT)’ and provide the following:
  
!      ‘VALUES(1)’:User time in seconds.
!      ‘VALUES(2)’:System time in seconds.
!      ‘TIME’:     Run time since start in seconds.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 11575,11586 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL ETIME(VALUES, TIME)'.
!      'TIME = ETIME(VALUES)', (not recommended).
  
  _Arguments_:
!      VALUES      The type shall be 'REAL(4), DIMENSION(2)'.
!      TIME        The type shall be 'REAL(4)'.
  
  _Return value_:
       Elapsed time in seconds since the start of program execution.
--- 11575,11586 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL ETIME(VALUES, TIME)’.
!      ‘TIME = ETIME(VALUES)’, (not recommended).
  
  _Arguments_:
!      VALUES      The type shall be ‘REAL(4), DIMENSION(2)’.
!      TIME        The type shall be ‘REAL(4)’.
  
  _Return value_:
       Elapsed time in seconds since the start of program execution.
*************** _See also_:
*** 11609,11621 ****
  
  File: gfortran.info,  Node: EVENT_QUERY,  Next: EXECUTE_COMMAND_LINE,  Prev: ETIME,  Up: Intrinsic Procedures
  
! 8.99 'EVENT_QUERY' -- Query whether a coarray event has occurred
  ================================================================
  
  _Description_:
!      'EVENT_QUERY' assignes the number of events to COUNT which have
       been posted to the EVENT variable and not yet been removed by
!      calling 'EVENT WAIT'.  When STAT is present and the invocation was
       successful, it is assigned the value 0.  If it is present and the
       invocation has failed, it is assigned a positive value and COUNT is
       assigned the value -1.
--- 11609,11621 ----
  
  File: gfortran.info,  Node: EVENT_QUERY,  Next: EXECUTE_COMMAND_LINE,  Prev: ETIME,  Up: Intrinsic Procedures
  
! 8.99 ‘EVENT_QUERY’ -- Query whether a coarray event has occurred
  ================================================================
  
  _Description_:
!      ‘EVENT_QUERY’ assignes the number of events to COUNT which have
       been posted to the EVENT variable and not yet been removed by
!      calling ‘EVENT WAIT’.  When STAT is present and the invocation was
       successful, it is assigned the value 0.  If it is present and the
       invocation has failed, it is assigned a positive value and COUNT is
       assigned the value -1.
*************** _Class_:
*** 11627,11637 ****
       subroutine
  
  _Syntax_:
!      'CALL EVENT_QUERY (EVENT, COUNT [, STAT])'
  
  _Arguments_:
!      EVENT       (intent(IN)) Scalar of type 'EVENT_TYPE',
!                  defined in 'ISO_FORTRAN_ENV'; shall not be
                   coindexed.
       COUNT       (intent(out))Scalar integer with at least the
                   precision of default integer.
--- 11627,11637 ----
       subroutine
  
  _Syntax_:
!      ‘CALL EVENT_QUERY (EVENT, COUNT [, STAT])’
  
  _Arguments_:
!      EVENT       (intent(IN)) Scalar of type ‘EVENT_TYPE’,
!                  defined in ‘ISO_FORTRAN_ENV’; shall not be
                   coindexed.
       COUNT       (intent(out))Scalar integer with at least the
                   precision of default integer.
*************** _Example_:
*** 11654,11687 ****
  
  File: gfortran.info,  Node: EXECUTE_COMMAND_LINE,  Next: EXIT,  Prev: EVENT_QUERY,  Up: Intrinsic Procedures
  
! 8.100 'EXECUTE_COMMAND_LINE' -- Execute a shell command
  =======================================================
  
  _Description_:
!      'EXECUTE_COMMAND_LINE' runs a shell command, synchronously or
       asynchronously.
  
!      The 'COMMAND' argument is passed to the shell and executed (The
!      shell is 'sh' on Unix systems, and 'cmd.exe' on Windows.).  If
!      'WAIT' is present and has the value false, the execution of the
       command is asynchronous if the system supports it; otherwise, the
!      command is executed synchronously using the C library's 'system'
       call.
  
       The three last arguments allow the user to get status information.
!      After synchronous execution, 'EXITSTAT' contains the integer exit
!      code of the command, as returned by 'system'.  'CMDSTAT' is set to
       zero if the command line was executed (whatever its exit status
!      was).  'CMDMSG' is assigned an error message if an error has
       occurred.
  
!      Note that the 'system' function need not be thread-safe.  It is the
!      responsibility of the user to ensure that 'system' is not called
       concurrently.
  
       For asynchronous execution on supported targets, the POSIX
!      'posix_spawn' or 'fork' functions are used.  Also, a signal handler
!      for the 'SIGCHLD' signal is installed.
  
  _Standard_:
       Fortran 2008 and later
--- 11654,11687 ----
  
  File: gfortran.info,  Node: EXECUTE_COMMAND_LINE,  Next: EXIT,  Prev: EVENT_QUERY,  Up: Intrinsic Procedures
  
! 8.100 ‘EXECUTE_COMMAND_LINE’ -- Execute a shell command
  =======================================================
  
  _Description_:
!      ‘EXECUTE_COMMAND_LINE’ runs a shell command, synchronously or
       asynchronously.
  
!      The ‘COMMAND’ argument is passed to the shell and executed (The
!      shell is ‘sh’ on Unix systems, and ‘cmd.exe’ on Windows.).  If
!      ‘WAIT’ is present and has the value false, the execution of the
       command is asynchronous if the system supports it; otherwise, the
!      command is executed synchronously using the C library's ‘system’
       call.
  
       The three last arguments allow the user to get status information.
!      After synchronous execution, ‘EXITSTAT’ contains the integer exit
!      code of the command, as returned by ‘system’.  ‘CMDSTAT’ is set to
       zero if the command line was executed (whatever its exit status
!      was).  ‘CMDMSG’ is assigned an error message if an error has
       occurred.
  
!      Note that the ‘system’ function need not be thread-safe.  It is the
!      responsibility of the user to ensure that ‘system’ is not called
       concurrently.
  
       For asynchronous execution on supported targets, the POSIX
!      ‘posix_spawn’ or ‘fork’ functions are used.  Also, a signal handler
!      for the ‘SIGCHLD’ signal is installed.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 11690,11706 ****
       Subroutine
  
  _Syntax_:
!      'CALL EXECUTE_COMMAND_LINE(COMMAND [, WAIT, EXITSTAT, CMDSTAT,
!      CMDMSG ])'
  
  _Arguments_:
!      COMMAND     Shall be a default 'CHARACTER' scalar.
!      WAIT        (Optional) Shall be a default 'LOGICAL' scalar.
!      EXITSTAT    (Optional) Shall be an 'INTEGER' of the default
                   kind.
!      CMDSTAT     (Optional) Shall be an 'INTEGER' of the default
                   kind.
!      CMDMSG      (Optional) Shall be an 'CHARACTER' scalar of the
                   default kind.
  
  _Example_:
--- 11690,11706 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL EXECUTE_COMMAND_LINE(COMMAND [, WAIT, EXITSTAT, CMDSTAT,
!      CMDMSG ])’
  
  _Arguments_:
!      COMMAND     Shall be a default ‘CHARACTER’ scalar.
!      WAIT        (Optional) Shall be a default ‘LOGICAL’ scalar.
!      EXITSTAT    (Optional) Shall be an ‘INTEGER’ of the default
                   kind.
!      CMDSTAT     (Optional) Shall be an ‘INTEGER’ of the default
                   kind.
!      CMDMSG      (Optional) Shall be an ‘CHARACTER’ scalar of the
                   default kind.
  
  _Example_:
*************** _Example_:
*** 11717,11723 ****
  
  _Note_:
  
!      Because this intrinsic is implemented in terms of the 'system'
       function call, its behavior with respect to signaling is processor
       dependent.  In particular, on POSIX-compliant systems, the SIGINT
       and SIGQUIT signals will be ignored, and the SIGCHLD will be
--- 11717,11723 ----
  
  _Note_:
  
!      Because this intrinsic is implemented in terms of the ‘system’
       function call, its behavior with respect to signaling is processor
       dependent.  In particular, on POSIX-compliant systems, the SIGINT
       and SIGQUIT signals will be ignored, and the SIGCHLD will be
*************** _See also_:
*** 11730,11740 ****
  
  File: gfortran.info,  Node: EXIT,  Next: EXP,  Prev: EXECUTE_COMMAND_LINE,  Up: Intrinsic Procedures
  
! 8.101 'EXIT' -- Exit the program with status.
  =============================================
  
  _Description_:
!      'EXIT' causes immediate termination of the program with status.  If
       status is omitted it returns the canonical _success_ for the
       system.  All Fortran I/O units are closed.
  
--- 11730,11740 ----
  
  File: gfortran.info,  Node: EXIT,  Next: EXP,  Prev: EXECUTE_COMMAND_LINE,  Up: Intrinsic Procedures
  
! 8.101 ‘EXIT’ -- Exit the program with status.
  =============================================
  
  _Description_:
!      ‘EXIT’ causes immediate termination of the program with status.  If
       status is omitted it returns the canonical _success_ for the
       system.  All Fortran I/O units are closed.
  
*************** _Class_:
*** 11745,11757 ****
       Subroutine
  
  _Syntax_:
!      'CALL EXIT([STATUS])'
  
  _Arguments_:
!      STATUS      Shall be an 'INTEGER' of the default kind.
  
  _Return value_:
!      'STATUS' is passed to the parent process on exit.
  
  _Example_:
            program test_exit
--- 11745,11757 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL EXIT([STATUS])’
  
  _Arguments_:
!      STATUS      Shall be an ‘INTEGER’ of the default kind.
  
  _Return value_:
!      ‘STATUS’ is passed to the parent process on exit.
  
  _Example_:
            program test_exit
*************** _See also_:
*** 11767,11777 ****
  
  File: gfortran.info,  Node: EXP,  Next: EXPONENT,  Prev: EXIT,  Up: Intrinsic Procedures
  
! 8.102 'EXP' -- Exponential function
  ===================================
  
  _Description_:
!      'EXP(X)' computes the base e exponential of X.
  
  _Standard_:
       Fortran 77 and later, has overloads that are GNU extensions
--- 11767,11777 ----
  
  File: gfortran.info,  Node: EXP,  Next: EXPONENT,  Prev: EXIT,  Up: Intrinsic Procedures
  
! 8.102 ‘EXP’ -- Exponential function
  ===================================
  
  _Description_:
!      ‘EXP(X)’ computes the base e exponential of X.
  
  _Standard_:
       Fortran 77 and later, has overloads that are GNU extensions
*************** _Class_:
*** 11780,11789 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = EXP(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X.
--- 11780,11789 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = EXP(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X.
*************** _Example_:
*** 11797,11816 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'EXP(X)'       'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DEXP(X)'      'REAL(8) X'       'REAL(8)'      Fortran 77 and later
!      'CEXP(X)'      'COMPLEX(4) X'    'COMPLEX(4)'   Fortran 77 and later
!      'ZEXP(X)'      'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
!      'CDEXP(X)'     'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
  
  
  File: gfortran.info,  Node: EXPONENT,  Next: EXTENDS_TYPE_OF,  Prev: EXP,  Up: Intrinsic Procedures
  
! 8.103 'EXPONENT' -- Exponent function
  =====================================
  
  _Description_:
!      'EXPONENT(X)' returns the value of the exponent part of X.  If X is
       zero the value returned is zero.
  
  _Standard_:
--- 11797,11816 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘EXP(X)’       ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DEXP(X)’      ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
!      ‘CEXP(X)’      ‘COMPLEX(4) X’    ‘COMPLEX(4)’   Fortran 77 and later
!      ‘ZEXP(X)’      ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
!      ‘CDEXP(X)’     ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
  
  
  File: gfortran.info,  Node: EXPONENT,  Next: EXTENDS_TYPE_OF,  Prev: EXP,  Up: Intrinsic Procedures
  
! 8.103 ‘EXPONENT’ -- Exponent function
  =====================================
  
  _Description_:
!      ‘EXPONENT(X)’ returns the value of the exponent part of X.  If X is
       zero the value returned is zero.
  
  _Standard_:
*************** _Class_:
*** 11820,11832 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = EXPONENT(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
  
  _Return value_:
!      The return value is of type default 'INTEGER'.
  
  _Example_:
            program test_exponent
--- 11820,11832 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = EXPONENT(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
  
  _Return value_:
!      The return value is of type default ‘INTEGER’.
  
  _Example_:
            program test_exponent
*************** _Example_:
*** 11840,11846 ****
  
  File: gfortran.info,  Node: EXTENDS_TYPE_OF,  Next: FDATE,  Prev: EXPONENT,  Up: Intrinsic Procedures
  
! 8.104 'EXTENDS_TYPE_OF' -- Query dynamic type for extension
  ===========================================================
  
  _Description_:
--- 11840,11846 ----
  
  File: gfortran.info,  Node: EXTENDS_TYPE_OF,  Next: FDATE,  Prev: EXPONENT,  Up: Intrinsic Procedures
  
! 8.104 ‘EXTENDS_TYPE_OF’ -- Query dynamic type for extension
  ===========================================================
  
  _Description_:
*************** _Class_:
*** 11853,11859 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = EXTENDS_TYPE_OF(A, MOLD)'
  
  _Arguments_:
       A           Shall be an object of extensible declared type
--- 11853,11859 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = EXTENDS_TYPE_OF(A, MOLD)’
  
  _Arguments_:
       A           Shall be an object of extensible declared type
*************** _See also_:
*** 11872,11884 ****
  
  File: gfortran.info,  Node: FDATE,  Next: FGET,  Prev: EXTENDS_TYPE_OF,  Up: Intrinsic Procedures
  
! 8.105 'FDATE' -- Get the current time as a string
  =================================================
  
  _Description_:
!      'FDATE(DATE)' returns the current date (using the same format as
!      *note CTIME::) in DATE.  It is equivalent to 'CALL CTIME(DATE,
!      TIME())'.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 11872,11884 ----
  
  File: gfortran.info,  Node: FDATE,  Next: FGET,  Prev: EXTENDS_TYPE_OF,  Up: Intrinsic Procedures
  
! 8.105 ‘FDATE’ -- Get the current time as a string
  =================================================
  
  _Description_:
!      ‘FDATE(DATE)’ returns the current date (using the same format as
!      *note CTIME::) in DATE.  It is equivalent to ‘CALL CTIME(DATE,
!      TIME())’.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 11890,11901 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL FDATE(DATE)'.
!      'DATE = FDATE()'.
  
  _Arguments_:
!      DATE        The type shall be of type 'CHARACTER' of the
!                  default kind.  It is an 'INTENT(OUT)' argument.
                   If the length of this variable is too short for
                   the date and time string to fit completely, it
                   will be blank on procedure return.
--- 11890,11901 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL FDATE(DATE)’.
!      ‘DATE = FDATE()’.
  
  _Arguments_:
!      DATE        The type shall be of type ‘CHARACTER’ of the
!                  default kind.  It is an ‘INTENT(OUT)’ argument.
                   If the length of this variable is too short for
                   the date and time string to fit completely, it
                   will be blank on procedure return.
*************** _See also_:
*** 11923,11929 ****
  
  File: gfortran.info,  Node: FGET,  Next: FGETC,  Prev: FDATE,  Up: Intrinsic Procedures
  
! 8.106 'FGET' -- Read a single character in stream mode from stdin
  =================================================================
  
  _Description_:
--- 11923,11929 ----
  
  File: gfortran.info,  Node: FGET,  Next: FGETC,  Prev: FDATE,  Up: Intrinsic Procedures
  
! 8.106 ‘FGET’ -- Read a single character in stream mode from stdin
  =================================================================
  
  _Description_:
*************** _Description_:
*** 11935,11942 ****
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      Note that the 'FGET' intrinsic is provided for backwards
!      compatibility with 'g77'.  GNU Fortran provides the Fortran 2003
       Stream facility.  Programmers should consider the use of new stream
       IO feature in new code for future portability.  See also *note
       Fortran 2003 status::.
--- 11935,11942 ----
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      Note that the ‘FGET’ intrinsic is provided for backwards
!      compatibility with ‘g77’.  GNU Fortran provides the Fortran 2003
       Stream facility.  Programmers should consider the use of new stream
       IO feature in new code for future portability.  See also *note
       Fortran 2003 status::.
*************** _Class_:
*** 11948,11960 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL FGET(C [, STATUS])'
!      'STATUS = FGET(C)'
  
  _Arguments_:
!      C           The type shall be 'CHARACTER' and of default
                   kind.
!      STATUS      (Optional) status flag of type 'INTEGER'.
                   Returns 0 on success, -1 on end-of-file, and a
                   system specific positive error code otherwise.
  
--- 11948,11960 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL FGET(C [, STATUS])’
!      ‘STATUS = FGET(C)’
  
  _Arguments_:
!      C           The type shall be ‘CHARACTER’ and of default
                   kind.
!      STATUS      (Optional) status flag of type ‘INTEGER’.
                   Returns 0 on success, -1 on end-of-file, and a
                   system specific positive error code otherwise.
  
*************** _See also_:
*** 11981,11987 ****
  
  File: gfortran.info,  Node: FGETC,  Next: FINDLOC,  Prev: FGET,  Up: Intrinsic Procedures
  
! 8.107 'FGETC' -- Read a single character in stream mode
  =======================================================
  
  _Description_:
--- 11981,11987 ----
  
  File: gfortran.info,  Node: FGETC,  Next: FINDLOC,  Prev: FGET,  Up: Intrinsic Procedures
  
! 8.107 ‘FGETC’ -- Read a single character in stream mode
  =======================================================
  
  _Description_:
*************** _Description_:
*** 11993,12000 ****
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      Note that the 'FGET' intrinsic is provided for backwards
!      compatibility with 'g77'.  GNU Fortran provides the Fortran 2003
       Stream facility.  Programmers should consider the use of new stream
       IO feature in new code for future portability.  See also *note
       Fortran 2003 status::.
--- 11993,12000 ----
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      Note that the ‘FGET’ intrinsic is provided for backwards
!      compatibility with ‘g77’.  GNU Fortran provides the Fortran 2003
       Stream facility.  Programmers should consider the use of new stream
       IO feature in new code for future portability.  See also *note
       Fortran 2003 status::.
*************** _Class_:
*** 12006,12019 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL FGETC(UNIT, C [, STATUS])'
!      'STATUS = FGETC(UNIT, C)'
  
  _Arguments_:
!      UNIT        The type shall be 'INTEGER'.
!      C           The type shall be 'CHARACTER' and of default
                   kind.
!      STATUS      (Optional) status flag of type 'INTEGER'.
                   Returns 0 on success, -1 on end-of-file and a
                   system specific positive error code otherwise.
  
--- 12006,12019 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL FGETC(UNIT, C [, STATUS])’
!      ‘STATUS = FGETC(UNIT, C)’
  
  _Arguments_:
!      UNIT        The type shall be ‘INTEGER’.
!      C           The type shall be ‘CHARACTER’ and of default
                   kind.
!      STATUS      (Optional) status flag of type ‘INTEGER’.
                   Returns 0 on success, -1 on end-of-file and a
                   system specific positive error code otherwise.
  
*************** _See also_:
*** 12039,12045 ****
  
  File: gfortran.info,  Node: FINDLOC,  Next: FLOOR,  Prev: FGETC,  Up: Intrinsic Procedures
  
! 8.108 'FINDLOC' -- Search an array for a value
  ==============================================
  
  _Description_:
--- 12039,12045 ----
  
  File: gfortran.info,  Node: FINDLOC,  Next: FLOOR,  Prev: FGETC,  Up: Intrinsic Procedures
  
! 8.108 ‘FINDLOC’ -- Search an array for a value
  ==============================================
  
  _Description_:
*************** _Description_:
*** 12047,12059 ****
       given in the VALUE argument, or, if the DIM argument is supplied,
       determines the locations of the elements equal to the VALUE
       argument element along each row of the array in the DIM direction.
!      If MASK is present, only the elements for which MASK is '.TRUE.'
       are considered.  If more than one element in the array has the
       value VALUE, the location returned is that of the first such
       element in array element order if the BACK is not present or if it
!      is '.FALSE.'.  If BACK is true, the location returned is that of
       the last such element.  If the array has zero size, or all of the
!      elements of MASK are '.FALSE.', then the result is an array of
       zeroes.  Similarly, if DIM is supplied and all of the elements of
       MASK along a given row are zero, the result value for that row is
       zero.
--- 12047,12059 ----
       given in the VALUE argument, or, if the DIM argument is supplied,
       determines the locations of the elements equal to the VALUE
       argument element along each row of the array in the DIM direction.
!      If MASK is present, only the elements for which MASK is ‘.TRUE.’
       are considered.  If more than one element in the array has the
       value VALUE, the location returned is that of the first such
       element in array element order if the BACK is not present or if it
!      is ‘.FALSE.’.  If BACK is true, the location returned is that of
       the last such element.  If the array has zero size, or all of the
!      elements of MASK are ‘.FALSE.’, then the result is an array of
       zeroes.  Similarly, if DIM is supplied and all of the elements of
       MASK along a given row are zero, the result value for that row is
       zero.
*************** _Class_:
*** 12065,12089 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = FINDLOC(ARRAY, VALUE, DIM [, MASK] [,KIND]
!      [,BACK])'
!      'RESULT = FINDLOC(ARRAY, VALUE, [, MASK] [,KIND]
!      [,BACK])'
  
  _Arguments_:
       ARRAY       Shall be an array of intrinsic type.
       VALUE       A scalar of intrinsic type which is in type
                   conformance with ARRAY.
!      DIM         (Optional) Shall be a scalar of type 'INTEGER',
                   with a value between one and the rank of ARRAY,
                   inclusive.  It may not be an optional dummy
                   argument.
!      MASK        (Optional) Shall be of type 'LOGICAL', and
                   conformable with ARRAY.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
!      BACK        (Optional) A scalar of type 'LOGICAL'.
  
  _Return value_:
       If DIM is absent, the result is a rank-one array with a length
--- 12065,12089 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = FINDLOC(ARRAY, VALUE, DIM [, MASK] [,KIND]
!      [,BACK])’
!      ‘RESULT = FINDLOC(ARRAY, VALUE, [, MASK] [,KIND]
!      [,BACK])’
  
  _Arguments_:
       ARRAY       Shall be an array of intrinsic type.
       VALUE       A scalar of intrinsic type which is in type
                   conformance with ARRAY.
!      DIM         (Optional) Shall be a scalar of type ‘INTEGER’,
                   with a value between one and the rank of ARRAY,
                   inclusive.  It may not be an optional dummy
                   argument.
!      MASK        (Optional) Shall be of type ‘LOGICAL’, and
                   conformable with ARRAY.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
!      BACK        (Optional) A scalar of type ‘LOGICAL’.
  
  _Return value_:
       If DIM is absent, the result is a rank-one array with a length
*************** _See also_:
*** 12101,12111 ****
  
  File: gfortran.info,  Node: FLOOR,  Next: FLUSH,  Prev: FINDLOC,  Up: Intrinsic Procedures
  
! 8.109 'FLOOR' -- Integer floor function
  =======================================
  
  _Description_:
!      'FLOOR(A)' returns the greatest integer less than or equal to A.
  
  _Standard_:
       Fortran 95 and later
--- 12101,12111 ----
  
  File: gfortran.info,  Node: FLOOR,  Next: FLUSH,  Prev: FINDLOC,  Up: Intrinsic Procedures
  
! 8.109 ‘FLOOR’ -- Integer floor function
  =======================================
  
  _Description_:
!      ‘FLOOR(A)’ returns the greatest integer less than or equal to A.
  
  _Standard_:
       Fortran 95 and later
*************** _Class_:
*** 12114,12130 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = FLOOR(A [, KIND])'
  
  _Arguments_:
!      A           The type shall be 'REAL'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER(KIND)' if KIND is present and
!      of default-kind 'INTEGER' otherwise.
  
  _Example_:
            program test_floor
--- 12114,12130 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = FLOOR(A [, KIND])’
  
  _Arguments_:
!      A           The type shall be ‘REAL’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER(KIND)’ if KIND is present and
!      of default-kind ‘INTEGER’ otherwise.
  
  _Example_:
            program test_floor
*************** _See also_:
*** 12141,12147 ****
  
  File: gfortran.info,  Node: FLUSH,  Next: FNUM,  Prev: FLOOR,  Up: Intrinsic Procedures
  
! 8.110 'FLUSH' -- Flush I/O unit(s)
  ==================================
  
  _Description_:
--- 12141,12147 ----
  
  File: gfortran.info,  Node: FLUSH,  Next: FNUM,  Prev: FLOOR,  Up: Intrinsic Procedures
  
! 8.110 ‘FLUSH’ -- Flush I/O unit(s)
  ==================================
  
  _Description_:
*************** _Class_:
*** 12156,12179 ****
       Subroutine
  
  _Syntax_:
!      'CALL FLUSH(UNIT)'
  
  _Arguments_:
!      UNIT        (Optional) The type shall be 'INTEGER'.
  
  _Note_:
!      Beginning with the Fortran 2003 standard, there is a 'FLUSH'
!      statement that should be preferred over the 'FLUSH' intrinsic.
  
!      The 'FLUSH' intrinsic and the Fortran 2003 'FLUSH' statement have
       identical effect: they flush the runtime library's I/O buffer so
       that the data becomes visible to other processes.  This does not
       guarantee that the data is committed to disk.
  
       On POSIX systems, you can request that all data is transferred to
!      the storage device by calling the 'fsync' function, with the POSIX
       file descriptor of the I/O unit as argument (retrieved with GNU
!      intrinsic 'FNUM').  The following example shows how:
  
              ! Declare the interface for POSIX fsync function
              interface
--- 12156,12179 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL FLUSH(UNIT)’
  
  _Arguments_:
!      UNIT        (Optional) The type shall be ‘INTEGER’.
  
  _Note_:
!      Beginning with the Fortran 2003 standard, there is a ‘FLUSH’
!      statement that should be preferred over the ‘FLUSH’ intrinsic.
  
!      The ‘FLUSH’ intrinsic and the Fortran 2003 ‘FLUSH’ statement have
       identical effect: they flush the runtime library's I/O buffer so
       that the data becomes visible to other processes.  This does not
       guarantee that the data is committed to disk.
  
       On POSIX systems, you can request that all data is transferred to
!      the storage device by calling the ‘fsync’ function, with the POSIX
       file descriptor of the I/O unit as argument (retrieved with GNU
!      intrinsic ‘FNUM’).  The following example shows how:
  
              ! Declare the interface for POSIX fsync function
              interface
*************** _Note_:
*** 12204,12215 ****
  
  File: gfortran.info,  Node: FNUM,  Next: FPUT,  Prev: FLUSH,  Up: Intrinsic Procedures
  
! 8.111 'FNUM' -- File number function
  ====================================
  
  _Description_:
!      'FNUM(UNIT)' returns the POSIX file descriptor number corresponding
!      to the open Fortran I/O unit 'UNIT'.
  
  _Standard_:
       GNU extension
--- 12204,12215 ----
  
  File: gfortran.info,  Node: FNUM,  Next: FPUT,  Prev: FLUSH,  Up: Intrinsic Procedures
  
! 8.111 ‘FNUM’ -- File number function
  ====================================
  
  _Description_:
!      ‘FNUM(UNIT)’ returns the POSIX file descriptor number corresponding
!      to the open Fortran I/O unit ‘UNIT’.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 12218,12230 ****
       Function
  
  _Syntax_:
!      'RESULT = FNUM(UNIT)'
  
  _Arguments_:
!      UNIT        The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER'
  
  _Example_:
            program test_fnum
--- 12218,12230 ----
       Function
  
  _Syntax_:
!      ‘RESULT = FNUM(UNIT)’
  
  _Arguments_:
!      UNIT        The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’
  
  _Example_:
            program test_fnum
*************** _Example_:
*** 12238,12244 ****
  
  File: gfortran.info,  Node: FPUT,  Next: FPUTC,  Prev: FNUM,  Up: Intrinsic Procedures
  
! 8.112 'FPUT' -- Write a single character in stream mode to stdout
  =================================================================
  
  _Description_:
--- 12238,12244 ----
  
  File: gfortran.info,  Node: FPUT,  Next: FPUTC,  Prev: FNUM,  Up: Intrinsic Procedures
  
! 8.112 ‘FPUT’ -- Write a single character in stream mode to stdout
  =================================================================
  
  _Description_:
*************** _Description_:
*** 12250,12257 ****
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      Note that the 'FGET' intrinsic is provided for backwards
!      compatibility with 'g77'.  GNU Fortran provides the Fortran 2003
       Stream facility.  Programmers should consider the use of new stream
       IO feature in new code for future portability.  See also *note
       Fortran 2003 status::.
--- 12250,12257 ----
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      Note that the ‘FGET’ intrinsic is provided for backwards
!      compatibility with ‘g77’.  GNU Fortran provides the Fortran 2003
       Stream facility.  Programmers should consider the use of new stream
       IO feature in new code for future portability.  See also *note
       Fortran 2003 status::.
*************** _Class_:
*** 12263,12275 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL FPUT(C [, STATUS])'
!      'STATUS = FPUT(C)'
  
  _Arguments_:
!      C           The type shall be 'CHARACTER' and of default
                   kind.
!      STATUS      (Optional) status flag of type 'INTEGER'.
                   Returns 0 on success, -1 on end-of-file and a
                   system specific positive error code otherwise.
  
--- 12263,12275 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL FPUT(C [, STATUS])’
!      ‘STATUS = FPUT(C)’
  
  _Arguments_:
!      C           The type shall be ‘CHARACTER’ and of default
                   kind.
!      STATUS      (Optional) status flag of type ‘INTEGER’.
                   Returns 0 on success, -1 on end-of-file and a
                   system specific positive error code otherwise.
  
*************** _See also_:
*** 12290,12296 ****
  
  File: gfortran.info,  Node: FPUTC,  Next: FRACTION,  Prev: FPUT,  Up: Intrinsic Procedures
  
! 8.113 'FPUTC' -- Write a single character in stream mode
  ========================================================
  
  _Description_:
--- 12290,12296 ----
  
  File: gfortran.info,  Node: FPUTC,  Next: FRACTION,  Prev: FPUT,  Up: Intrinsic Procedures
  
! 8.113 ‘FPUTC’ -- Write a single character in stream mode
  ========================================================
  
  _Description_:
*************** _Description_:
*** 12302,12309 ****
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      Note that the 'FGET' intrinsic is provided for backwards
!      compatibility with 'g77'.  GNU Fortran provides the Fortran 2003
       Stream facility.  Programmers should consider the use of new stream
       IO feature in new code for future portability.  See also *note
       Fortran 2003 status::.
--- 12302,12309 ----
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      Note that the ‘FGET’ intrinsic is provided for backwards
!      compatibility with ‘g77’.  GNU Fortran provides the Fortran 2003
       Stream facility.  Programmers should consider the use of new stream
       IO feature in new code for future portability.  See also *note
       Fortran 2003 status::.
*************** _Class_:
*** 12315,12328 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL FPUTC(UNIT, C [, STATUS])'
!      'STATUS = FPUTC(UNIT, C)'
  
  _Arguments_:
!      UNIT        The type shall be 'INTEGER'.
!      C           The type shall be 'CHARACTER' and of default
                   kind.
!      STATUS      (Optional) status flag of type 'INTEGER'.
                   Returns 0 on success, -1 on end-of-file and a
                   system specific positive error code otherwise.
  
--- 12315,12328 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL FPUTC(UNIT, C [, STATUS])’
!      ‘STATUS = FPUTC(UNIT, C)’
  
  _Arguments_:
!      UNIT        The type shall be ‘INTEGER’.
!      C           The type shall be ‘CHARACTER’ and of default
                   kind.
!      STATUS      (Optional) status flag of type ‘INTEGER’.
                   Returns 0 on success, -1 on end-of-file and a
                   system specific positive error code otherwise.
  
*************** _See also_:
*** 12346,12357 ****
  
  File: gfortran.info,  Node: FRACTION,  Next: FREE,  Prev: FPUTC,  Up: Intrinsic Procedures
  
! 8.114 'FRACTION' -- Fractional part of the model representation
  ===============================================================
  
  _Description_:
!      'FRACTION(X)' returns the fractional part of the model
!      representation of 'X'.
  
  _Standard_:
       Fortran 90 and later
--- 12346,12357 ----
  
  File: gfortran.info,  Node: FRACTION,  Next: FREE,  Prev: FPUTC,  Up: Intrinsic Procedures
  
! 8.114 ‘FRACTION’ -- Fractional part of the model representation
  ===============================================================
  
  _Description_:
!      ‘FRACTION(X)’ returns the fractional part of the model
!      representation of ‘X’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 12360,12374 ****
       Elemental function
  
  _Syntax_:
!      'Y = FRACTION(X)'
  
  _Arguments_:
!      X           The type of the argument shall be a 'REAL'.
  
  _Return value_:
       The return value is of the same type and kind as the argument.  The
!      fractional part of the model representation of 'X' is returned; it
!      is 'X * RADIX(X)**(-EXPONENT(X))'.
  
  _Example_:
            program test_fraction
--- 12360,12374 ----
       Elemental function
  
  _Syntax_:
!      ‘Y = FRACTION(X)’
  
  _Arguments_:
!      X           The type of the argument shall be a ‘REAL’.
  
  _Return value_:
       The return value is of the same type and kind as the argument.  The
!      fractional part of the model representation of ‘X’ is returned; it
!      is ‘X * RADIX(X)**(-EXPONENT(X))’.
  
  _Example_:
            program test_fraction
*************** _Example_:
*** 12380,12394 ****
  
  File: gfortran.info,  Node: FREE,  Next: FSEEK,  Prev: FRACTION,  Up: Intrinsic Procedures
  
! 8.115 'FREE' -- Frees memory
  ============================
  
  _Description_:
!      Frees memory previously allocated by 'MALLOC'.  The 'FREE'
       intrinsic is an extension intended to be used with Cray pointers,
       and is provided in GNU Fortran to allow user to compile legacy
       code.  For new code using Fortran 95 pointers, the memory
!      de-allocation intrinsic is 'DEALLOCATE'.
  
  _Standard_:
       GNU extension
--- 12380,12394 ----
  
  File: gfortran.info,  Node: FREE,  Next: FSEEK,  Prev: FRACTION,  Up: Intrinsic Procedures
  
! 8.115 ‘FREE’ -- Frees memory
  ============================
  
  _Description_:
!      Frees memory previously allocated by ‘MALLOC’.  The ‘FREE’
       intrinsic is an extension intended to be used with Cray pointers,
       and is provided in GNU Fortran to allow user to compile legacy
       code.  For new code using Fortran 95 pointers, the memory
!      de-allocation intrinsic is ‘DEALLOCATE’.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 12397,12406 ****
       Subroutine
  
  _Syntax_:
!      'CALL FREE(PTR)'
  
  _Arguments_:
!      PTR         The type shall be 'INTEGER'.  It represents the
                   location of the memory that should be
                   de-allocated.
  
--- 12397,12406 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL FREE(PTR)’
  
  _Arguments_:
!      PTR         The type shall be ‘INTEGER’.  It represents the
                   location of the memory that should be
                   de-allocated.
  
*************** _Return value_:
*** 12408,12414 ****
       None
  
  _Example_:
!      See 'MALLOC' for an example.
  
  _See also_:
       *note MALLOC::
--- 12408,12414 ----
       None
  
  _Example_:
!      See ‘MALLOC’ for an example.
  
  _See also_:
       *note MALLOC::
*************** _See also_:
*** 12416,12434 ****
  
  File: gfortran.info,  Node: FSEEK,  Next: FSTAT,  Prev: FREE,  Up: Intrinsic Procedures
  
! 8.116 'FSEEK' -- Low level file positioning subroutine
  ======================================================
  
  _Description_:
       Moves UNIT to the specified OFFSET.  If WHENCE is set to 0, the
!      OFFSET is taken as an absolute value 'SEEK_SET', if set to 1,
!      OFFSET is taken to be relative to the current position 'SEEK_CUR',
!      and if set to 2 relative to the end of the file 'SEEK_END'.  On
       error, STATUS is set to a nonzero value.  If STATUS the seek fails
       silently.
  
       This intrinsic routine is not fully backwards compatible with
!      'g77'.  In 'g77', the 'FSEEK' takes a statement label instead of a
       STATUS variable.  If FSEEK is used in old code, change
              CALL FSEEK(UNIT, OFFSET, WHENCE, *label)
       to
--- 12416,12434 ----
  
  File: gfortran.info,  Node: FSEEK,  Next: FSTAT,  Prev: FREE,  Up: Intrinsic Procedures
  
! 8.116 ‘FSEEK’ -- Low level file positioning subroutine
  ======================================================
  
  _Description_:
       Moves UNIT to the specified OFFSET.  If WHENCE is set to 0, the
!      OFFSET is taken as an absolute value ‘SEEK_SET’, if set to 1,
!      OFFSET is taken to be relative to the current position ‘SEEK_CUR’,
!      and if set to 2 relative to the end of the file ‘SEEK_END’.  On
       error, STATUS is set to a nonzero value.  If STATUS the seek fails
       silently.
  
       This intrinsic routine is not fully backwards compatible with
!      ‘g77’.  In ‘g77’, the ‘FSEEK’ takes a statement label instead of a
       STATUS variable.  If FSEEK is used in old code, change
              CALL FSEEK(UNIT, OFFSET, WHENCE, *label)
       to
*************** _Class_:
*** 12448,12462 ****
       Subroutine
  
  _Syntax_:
!      'CALL FSEEK(UNIT, OFFSET, WHENCE[, STATUS])'
  
  _Arguments_:
!      UNIT        Shall be a scalar of type 'INTEGER'.
!      OFFSET      Shall be a scalar of type 'INTEGER'.
!      WHENCE      Shall be a scalar of type 'INTEGER'.  Its value
                   shall be either 0, 1 or 2.
       STATUS      (Optional) shall be a scalar of type
!                  'INTEGER(4)'.
  
  _Example_:
            PROGRAM test_fseek
--- 12448,12462 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL FSEEK(UNIT, OFFSET, WHENCE[, STATUS])’
  
  _Arguments_:
!      UNIT        Shall be a scalar of type ‘INTEGER’.
!      OFFSET      Shall be a scalar of type ‘INTEGER’.
!      WHENCE      Shall be a scalar of type ‘INTEGER’.  Its value
                   shall be either 0, 1 or 2.
       STATUS      (Optional) shall be a scalar of type
!                  ‘INTEGER(4)’.
  
  _Example_:
            PROGRAM test_fseek
*************** _See also_:
*** 12486,12499 ****
  
  File: gfortran.info,  Node: FSTAT,  Next: FTELL,  Prev: FSEEK,  Up: Intrinsic Procedures
  
! 8.117 'FSTAT' -- Get file status
  ================================
  
  _Description_:
!      'FSTAT' is identical to *note STAT::, except that information about
       an already opened file is obtained.
  
!      The elements in 'VALUES' are the same as described by *note STAT::.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 12486,12499 ----
  
  File: gfortran.info,  Node: FSTAT,  Next: FTELL,  Prev: FSEEK,  Up: Intrinsic Procedures
  
! 8.117 ‘FSTAT’ -- Get file status
  ================================
  
  _Description_:
!      ‘FSTAT’ is identical to *note STAT::, except that information about
       an already opened file is obtained.
  
!      The elements in ‘VALUES’ are the same as described by *note STAT::.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 12505,12517 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL FSTAT(UNIT, VALUES [, STATUS])'
!      'STATUS = FSTAT(UNIT, VALUES)'
  
  _Arguments_:
!      UNIT        An open I/O unit number of type 'INTEGER'.
!      VALUES      The type shall be 'INTEGER(4), DIMENSION(13)'.
!      STATUS      (Optional) status flag of type 'INTEGER(4)'.
                   Returns 0 on success and a system specific error
                   code otherwise.
  
--- 12505,12517 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL FSTAT(UNIT, VALUES [, STATUS])’
!      ‘STATUS = FSTAT(UNIT, VALUES)’
  
  _Arguments_:
!      UNIT        An open I/O unit number of type ‘INTEGER’.
!      VALUES      The type shall be ‘INTEGER(4), DIMENSION(13)’.
!      STATUS      (Optional) status flag of type ‘INTEGER(4)’.
                   Returns 0 on success and a system specific error
                   code otherwise.
  
*************** _See also_:
*** 12527,12533 ****
  
  File: gfortran.info,  Node: FTELL,  Next: GAMMA,  Prev: FSTAT,  Up: Intrinsic Procedures
  
! 8.118 'FTELL' -- Current stream position
  ========================================
  
  _Description_:
--- 12527,12533 ----
  
  File: gfortran.info,  Node: FTELL,  Next: GAMMA,  Prev: FSTAT,  Up: Intrinsic Procedures
  
! 8.118 ‘FTELL’ -- Current stream position
  ========================================
  
  _Description_:
*************** _Class_:
*** 12543,12554 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL FTELL(UNIT, OFFSET)'
!      'OFFSET = FTELL(UNIT)'
  
  _Arguments_:
!      OFFSET      Shall of type 'INTEGER'.
!      UNIT        Shall of type 'INTEGER'.
  
  _Return value_:
       In either syntax, OFFSET is set to the current offset of unit
--- 12543,12554 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL FTELL(UNIT, OFFSET)’
!      ‘OFFSET = FTELL(UNIT)’
  
  _Arguments_:
!      OFFSET      Shall of type ‘INTEGER’.
!      UNIT        Shall of type ‘INTEGER’.
  
  _Return value_:
       In either syntax, OFFSET is set to the current offset of unit
*************** _See also_:
*** 12568,12578 ****
  
  File: gfortran.info,  Node: GAMMA,  Next: GERROR,  Prev: FTELL,  Up: Intrinsic Procedures
  
! 8.119 'GAMMA' -- Gamma function
  ===============================
  
  _Description_:
!      'GAMMA(X)' computes Gamma (\Gamma) of X.  For positive, integer
       values of X the Gamma function simplifies to the factorial function
       \Gamma(x)=(x-1)!.
  
--- 12568,12578 ----
  
  File: gfortran.info,  Node: GAMMA,  Next: GERROR,  Prev: FTELL,  Up: Intrinsic Procedures
  
! 8.119 ‘GAMMA’ -- Gamma function
  ===============================
  
  _Description_:
!      ‘GAMMA(X)’ computes Gamma (\Gamma) of X.  For positive, integer
       values of X the Gamma function simplifies to the factorial function
       \Gamma(x)=(x-1)!.
  
*************** _Class_:
*** 12583,12596 ****
       Elemental function
  
  _Syntax_:
!      'X = GAMMA(X)'
  
  _Arguments_:
!      X           Shall be of type 'REAL' and neither zero nor a
                   negative integer.
  
  _Return value_:
!      The return value is of type 'REAL' of the same kind as X.
  
  _Example_:
            program test_gamma
--- 12583,12596 ----
       Elemental function
  
  _Syntax_:
!      ‘X = GAMMA(X)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’ and neither zero nor a
                   negative integer.
  
  _Return value_:
!      The return value is of type ‘REAL’ of the same kind as X.
  
  _Example_:
            program test_gamma
*************** _Example_:
*** 12601,12607 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DGAMMA(X)'    'REAL(8) X'       'REAL(8)'      GNU extension
  
  _See also_:
       Logarithm of the Gamma function:
--- 12601,12607 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DGAMMA(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  _See also_:
       Logarithm of the Gamma function:
*************** _See also_:
*** 12610,12621 ****
  
  File: gfortran.info,  Node: GERROR,  Next: GETARG,  Prev: GAMMA,  Up: Intrinsic Procedures
  
! 8.120 'GERROR' -- Get last system error message
  ===============================================
  
  _Description_:
       Returns the system error message corresponding to the last system
!      error.  This resembles the functionality of 'strerror(3)' in C.
  
  _Standard_:
       GNU extension
--- 12610,12621 ----
  
  File: gfortran.info,  Node: GERROR,  Next: GETARG,  Prev: GAMMA,  Up: Intrinsic Procedures
  
! 8.120 ‘GERROR’ -- Get last system error message
  ===============================================
  
  _Description_:
       Returns the system error message corresponding to the last system
!      error.  This resembles the functionality of ‘strerror(3)’ in C.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 12624,12633 ****
       Subroutine
  
  _Syntax_:
!      'CALL GERROR(RESULT)'
  
  _Arguments_:
!      RESULT      Shall be of type 'CHARACTER' and of default
                   kind.
  
  _Example_:
--- 12624,12633 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL GERROR(RESULT)’
  
  _Arguments_:
!      RESULT      Shall be of type ‘CHARACTER’ and of default
                   kind.
  
  _Example_:
*************** _See also_:
*** 12644,12650 ****
  
  File: gfortran.info,  Node: GETARG,  Next: GET_COMMAND,  Prev: GERROR,  Up: Intrinsic Procedures
  
! 8.121 'GETARG' -- Get command line arguments
  ============================================
  
  _Description_:
--- 12644,12650 ----
  
  File: gfortran.info,  Node: GETARG,  Next: GET_COMMAND,  Prev: GERROR,  Up: Intrinsic Procedures
  
! 8.121 ‘GETARG’ -- Get command line arguments
  ============================================
  
  _Description_:
*************** _Class_:
*** 12663,12678 ****
       Subroutine
  
  _Syntax_:
!      'CALL GETARG(POS, VALUE)'
  
  _Arguments_:
!      POS         Shall be of type 'INTEGER' and not wider than
                   the default integer kind; POS \geq 0
!      VALUE       Shall be of type 'CHARACTER' and of default
                   kind.
  
  _Return value_:
!      After 'GETARG' returns, the VALUE argument holds the POSth command
       line argument.  If VALUE cannot hold the argument, it is truncated
       to fit the length of VALUE.  If there are less than POS arguments
       specified at the command line, VALUE will be filled with blanks.
--- 12663,12678 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL GETARG(POS, VALUE)’
  
  _Arguments_:
!      POS         Shall be of type ‘INTEGER’ and not wider than
                   the default integer kind; POS \geq 0
!      VALUE       Shall be of type ‘CHARACTER’ and of default
                   kind.
  
  _Return value_:
!      After ‘GETARG’ returns, the VALUE argument holds the POSth command
       line argument.  If VALUE cannot hold the argument, it is truncated
       to fit the length of VALUE.  If there are less than POS arguments
       specified at the command line, VALUE will be filled with blanks.
*************** _See also_:
*** 12701,12707 ****
  
  File: gfortran.info,  Node: GET_COMMAND,  Next: GET_COMMAND_ARGUMENT,  Prev: GETARG,  Up: Intrinsic Procedures
  
! 8.122 'GET_COMMAND' -- Get the entire command line
  ==================================================
  
  _Description_:
--- 12701,12707 ----
  
  File: gfortran.info,  Node: GET_COMMAND,  Next: GET_COMMAND_ARGUMENT,  Prev: GETARG,  Up: Intrinsic Procedures
  
! 8.122 ‘GET_COMMAND’ -- Get the entire command line
  ==================================================
  
  _Description_:
*************** _Class_:
*** 12715,12728 ****
       Subroutine
  
  _Syntax_:
!      'CALL GET_COMMAND([COMMAND, LENGTH, STATUS])'
  
  _Arguments_:
!      COMMAND     (Optional) shall be of type 'CHARACTER' and of
                   default kind.
!      LENGTH      (Optional) Shall be of type 'INTEGER' and of
                   default kind.
!      STATUS      (Optional) Shall be of type 'INTEGER' and of
                   default kind.
  
  _Return value_:
--- 12715,12728 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL GET_COMMAND([COMMAND, LENGTH, STATUS])’
  
  _Arguments_:
!      COMMAND     (Optional) shall be of type ‘CHARACTER’ and of
                   default kind.
!      LENGTH      (Optional) Shall be of type ‘INTEGER’ and of
                   default kind.
!      STATUS      (Optional) Shall be of type ‘INTEGER’ and of
                   default kind.
  
  _Return value_:
*************** _See also_:
*** 12747,12753 ****
  
  File: gfortran.info,  Node: GET_COMMAND_ARGUMENT,  Next: GETCWD,  Prev: GET_COMMAND,  Up: Intrinsic Procedures
  
! 8.123 'GET_COMMAND_ARGUMENT' -- Get command line arguments
  ==========================================================
  
  _Description_:
--- 12747,12753 ----
  
  File: gfortran.info,  Node: GET_COMMAND_ARGUMENT,  Next: GETCWD,  Prev: GET_COMMAND,  Up: Intrinsic Procedures
  
! 8.123 ‘GET_COMMAND_ARGUMENT’ -- Get command line arguments
  ==========================================================
  
  _Description_:
*************** _Class_:
*** 12761,12780 ****
       Subroutine
  
  _Syntax_:
!      'CALL GET_COMMAND_ARGUMENT(NUMBER [, VALUE, LENGTH, STATUS])'
  
  _Arguments_:
!      NUMBER      Shall be a scalar of type 'INTEGER' and of
                   default kind, NUMBER \geq 0
!      VALUE       (Optional) Shall be a scalar of type 'CHARACTER'
                   and of default kind.
!      LENGTH      (Optional) Shall be a scalar of type 'INTEGER'
                   and of default kind.
!      STATUS      (Optional) Shall be a scalar of type 'INTEGER'
                   and of default kind.
  
  _Return value_:
!      After 'GET_COMMAND_ARGUMENT' returns, the VALUE argument holds the
       NUMBER-th command line argument.  If VALUE cannot hold the
       argument, it is truncated to fit the length of VALUE.  If there are
       less than NUMBER arguments specified at the command line, VALUE
--- 12761,12780 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL GET_COMMAND_ARGUMENT(NUMBER [, VALUE, LENGTH, STATUS])’
  
  _Arguments_:
!      NUMBER      Shall be a scalar of type ‘INTEGER’ and of
                   default kind, NUMBER \geq 0
!      VALUE       (Optional) Shall be a scalar of type ‘CHARACTER’
                   and of default kind.
!      LENGTH      (Optional) Shall be a scalar of type ‘INTEGER’
                   and of default kind.
!      STATUS      (Optional) Shall be a scalar of type ‘INTEGER’
                   and of default kind.
  
  _Return value_:
!      After ‘GET_COMMAND_ARGUMENT’ returns, the VALUE argument holds the
       NUMBER-th command line argument.  If VALUE cannot hold the
       argument, it is truncated to fit the length of VALUE.  If there are
       less than NUMBER arguments specified at the command line, VALUE
*************** _See also_:
*** 12807,12813 ****
  
  File: gfortran.info,  Node: GETCWD,  Next: GETENV,  Prev: GET_COMMAND_ARGUMENT,  Up: Intrinsic Procedures
  
! 8.124 'GETCWD' -- Get current working directory
  ===============================================
  
  _Description_:
--- 12807,12813 ----
  
  File: gfortran.info,  Node: GETCWD,  Next: GETENV,  Prev: GET_COMMAND_ARGUMENT,  Up: Intrinsic Procedures
  
! 8.124 ‘GETCWD’ -- Get current working directory
  ===============================================
  
  _Description_:
*************** _Class_:
*** 12823,12833 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL GETCWD(C [, STATUS])'
!      'STATUS = GETCWD(C)'
  
  _Arguments_:
!      C           The type shall be 'CHARACTER' and of default
                   kind.
       STATUS      (Optional) status flag.  Returns 0 on success, a
                   system specific and nonzero error code
--- 12823,12833 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL GETCWD(C [, STATUS])’
!      ‘STATUS = GETCWD(C)’
  
  _Arguments_:
!      C           The type shall be ‘CHARACTER’ and of default
                   kind.
       STATUS      (Optional) status flag.  Returns 0 on success, a
                   system specific and nonzero error code
*************** _See also_:
*** 12846,12852 ****
  
  File: gfortran.info,  Node: GETENV,  Next: GET_ENVIRONMENT_VARIABLE,  Prev: GETCWD,  Up: Intrinsic Procedures
  
! 8.125 'GETENV' -- Get an environmental variable
  ===============================================
  
  _Description_:
--- 12846,12852 ----
  
  File: gfortran.info,  Node: GETENV,  Next: GET_ENVIRONMENT_VARIABLE,  Prev: GETCWD,  Up: Intrinsic Procedures
  
! 8.125 ‘GETENV’ -- Get an environmental variable
  ===============================================
  
  _Description_:
*************** _Description_:
*** 12857,12865 ****
       of the *note GET_ENVIRONMENT_VARIABLE:: intrinsic defined by the
       Fortran 2003 standard.
  
!      Note that 'GETENV' need not be thread-safe.  It is the
       responsibility of the user to ensure that the environment is not
!      being updated concurrently with a call to the 'GETENV' intrinsic.
  
  _Standard_:
       GNU extension
--- 12857,12865 ----
       of the *note GET_ENVIRONMENT_VARIABLE:: intrinsic defined by the
       Fortran 2003 standard.
  
!      Note that ‘GETENV’ need not be thread-safe.  It is the
       responsibility of the user to ensure that the environment is not
!      being updated concurrently with a call to the ‘GETENV’ intrinsic.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 12868,12879 ****
       Subroutine
  
  _Syntax_:
!      'CALL GETENV(NAME, VALUE)'
  
  _Arguments_:
!      NAME        Shall be of type 'CHARACTER' and of default
                   kind.
!      VALUE       Shall be of type 'CHARACTER' and of default
                   kind.
  
  _Return value_:
--- 12868,12879 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL GETENV(NAME, VALUE)’
  
  _Arguments_:
!      NAME        Shall be of type ‘CHARACTER’ and of default
                   kind.
!      VALUE       Shall be of type ‘CHARACTER’ and of default
                   kind.
  
  _Return value_:
*************** _See also_:
*** 12894,12909 ****
  
  File: gfortran.info,  Node: GET_ENVIRONMENT_VARIABLE,  Next: GETGID,  Prev: GETENV,  Up: Intrinsic Procedures
  
! 8.126 'GET_ENVIRONMENT_VARIABLE' -- Get an environmental variable
  =================================================================
  
  _Description_:
       Get the VALUE of the environmental variable NAME.
  
!      Note that 'GET_ENVIRONMENT_VARIABLE' need not be thread-safe.  It
       is the responsibility of the user to ensure that the environment is
       not being updated concurrently with a call to the
!      'GET_ENVIRONMENT_VARIABLE' intrinsic.
  
  _Standard_:
       Fortran 2003 and later
--- 12894,12909 ----
  
  File: gfortran.info,  Node: GET_ENVIRONMENT_VARIABLE,  Next: GETGID,  Prev: GETENV,  Up: Intrinsic Procedures
  
! 8.126 ‘GET_ENVIRONMENT_VARIABLE’ -- Get an environmental variable
  =================================================================
  
  _Description_:
       Get the VALUE of the environmental variable NAME.
  
!      Note that ‘GET_ENVIRONMENT_VARIABLE’ need not be thread-safe.  It
       is the responsibility of the user to ensure that the environment is
       not being updated concurrently with a call to the
!      ‘GET_ENVIRONMENT_VARIABLE’ intrinsic.
  
  _Standard_:
       Fortran 2003 and later
*************** _Class_:
*** 12912,12930 ****
       Subroutine
  
  _Syntax_:
!      'CALL GET_ENVIRONMENT_VARIABLE(NAME[, VALUE, LENGTH, STATUS,
!      TRIM_NAME)'
  
  _Arguments_:
!      NAME        Shall be a scalar of type 'CHARACTER' and of
                   default kind.
!      VALUE       (Optional) Shall be a scalar of type 'CHARACTER'
                   and of default kind.
!      LENGTH      (Optional) Shall be a scalar of type 'INTEGER'
                   and of default kind.
!      STATUS      (Optional) Shall be a scalar of type 'INTEGER'
                   and of default kind.
!      TRIM_NAME   (Optional) Shall be a scalar of type 'LOGICAL'
                   and of default kind.
  
  _Return value_:
--- 12912,12930 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL GET_ENVIRONMENT_VARIABLE(NAME[, VALUE, LENGTH, STATUS,
!      TRIM_NAME)’
  
  _Arguments_:
!      NAME        Shall be a scalar of type ‘CHARACTER’ and of
                   default kind.
!      VALUE       (Optional) Shall be a scalar of type ‘CHARACTER’
                   and of default kind.
!      LENGTH      (Optional) Shall be a scalar of type ‘INTEGER’
                   and of default kind.
!      STATUS      (Optional) Shall be a scalar of type ‘INTEGER’
                   and of default kind.
!      TRIM_NAME   (Optional) Shall be a scalar of type ‘LOGICAL’
                   and of default kind.
  
  _Return value_:
*************** _Return value_:
*** 12936,12942 ****
       variable; it is 1 if the environment variable does not exist and 2
       if the processor does not support environment variables; in all
       other cases STATUS is zero.  If TRIM_NAME is present with the value
!      '.FALSE.', the trailing blanks in NAME are significant; otherwise
       they are not part of the environment variable name.
  
  _Example_:
--- 12936,12942 ----
       variable; it is 1 if the environment variable does not exist and 2
       if the processor does not support environment variables; in all
       other cases STATUS is zero.  If TRIM_NAME is present with the value
!      ‘.FALSE.’, the trailing blanks in NAME are significant; otherwise
       they are not part of the environment variable name.
  
  _Example_:
*************** _Example_:
*** 12949,12955 ****
  
  File: gfortran.info,  Node: GETGID,  Next: GETLOG,  Prev: GET_ENVIRONMENT_VARIABLE,  Up: Intrinsic Procedures
  
! 8.127 'GETGID' -- Group ID function
  ===================================
  
  _Description_:
--- 12949,12955 ----
  
  File: gfortran.info,  Node: GETGID,  Next: GETLOG,  Prev: GET_ENVIRONMENT_VARIABLE,  Up: Intrinsic Procedures
  
! 8.127 ‘GETGID’ -- Group ID function
  ===================================
  
  _Description_:
*************** _Class_:
*** 12962,12974 ****
       Function
  
  _Syntax_:
!      'RESULT = GETGID()'
  
  _Return value_:
!      The return value of 'GETGID' is an 'INTEGER' of the default kind.
  
  _Example_:
!      See 'GETPID' for an example.
  
  _See also_:
       *note GETPID::,
--- 12962,12974 ----
       Function
  
  _Syntax_:
!      ‘RESULT = GETGID()’
  
  _Return value_:
!      The return value of ‘GETGID’ is an ‘INTEGER’ of the default kind.
  
  _Example_:
!      See ‘GETPID’ for an example.
  
  _See also_:
       *note GETPID::,
*************** _See also_:
*** 12977,12983 ****
  
  File: gfortran.info,  Node: GETLOG,  Next: GETPID,  Prev: GETGID,  Up: Intrinsic Procedures
  
! 8.128 'GETLOG' -- Get login name
  ================================
  
  _Description_:
--- 12977,12983 ----
  
  File: gfortran.info,  Node: GETLOG,  Next: GETPID,  Prev: GETGID,  Up: Intrinsic Procedures
  
! 8.128 ‘GETLOG’ -- Get login name
  ================================
  
  _Description_:
*************** _Class_:
*** 12990,13005 ****
       Subroutine
  
  _Syntax_:
!      'CALL GETLOG(C)'
  
  _Arguments_:
!      C           Shall be of type 'CHARACTER' and of default
                   kind.
  
  _Return value_:
       Stores the current user name in C.  (On systems where POSIX
!      functions 'geteuid' and 'getpwuid' are not available, and the
!      'getlogin' function is not implemented either, this will return a
       blank string.)
  
  _Example_:
--- 12990,13005 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL GETLOG(C)’
  
  _Arguments_:
!      C           Shall be of type ‘CHARACTER’ and of default
                   kind.
  
  _Return value_:
       Stores the current user name in C.  (On systems where POSIX
!      functions ‘geteuid’ and ‘getpwuid’ are not available, and the
!      ‘getlogin’ function is not implemented either, this will return a
       blank string.)
  
  _Example_:
*************** _See also_:
*** 13015,13021 ****
  
  File: gfortran.info,  Node: GETPID,  Next: GETUID,  Prev: GETLOG,  Up: Intrinsic Procedures
  
! 8.129 'GETPID' -- Process ID function
  =====================================
  
  _Description_:
--- 13015,13021 ----
  
  File: gfortran.info,  Node: GETPID,  Next: GETUID,  Prev: GETLOG,  Up: Intrinsic Procedures
  
! 8.129 ‘GETPID’ -- Process ID function
  =====================================
  
  _Description_:
*************** _Class_:
*** 13028,13037 ****
       Function
  
  _Syntax_:
!      'RESULT = GETPID()'
  
  _Return value_:
!      The return value of 'GETPID' is an 'INTEGER' of the default kind.
  
  _Example_:
            program info
--- 13028,13037 ----
       Function
  
  _Syntax_:
!      ‘RESULT = GETPID()’
  
  _Return value_:
!      The return value of ‘GETPID’ is an ‘INTEGER’ of the default kind.
  
  _Example_:
            program info
*************** _See also_:
*** 13047,13053 ****
  
  File: gfortran.info,  Node: GETUID,  Next: GMTIME,  Prev: GETPID,  Up: Intrinsic Procedures
  
! 8.130 'GETUID' -- User ID function
  ==================================
  
  _Description_:
--- 13047,13053 ----
  
  File: gfortran.info,  Node: GETUID,  Next: GMTIME,  Prev: GETPID,  Up: Intrinsic Procedures
  
! 8.130 ‘GETUID’ -- User ID function
  ==================================
  
  _Description_:
*************** _Class_:
*** 13060,13072 ****
       Function
  
  _Syntax_:
!      'RESULT = GETUID()'
  
  _Return value_:
!      The return value of 'GETUID' is an 'INTEGER' of the default kind.
  
  _Example_:
!      See 'GETPID' for an example.
  
  _See also_:
       *note GETPID::,
--- 13060,13072 ----
       Function
  
  _Syntax_:
!      ‘RESULT = GETUID()’
  
  _Return value_:
!      The return value of ‘GETUID’ is an ‘INTEGER’ of the default kind.
  
  _Example_:
!      See ‘GETPID’ for an example.
  
  _See also_:
       *note GETPID::,
*************** _See also_:
*** 13075,13088 ****
  
  File: gfortran.info,  Node: GMTIME,  Next: HOSTNM,  Prev: GETUID,  Up: Intrinsic Procedures
  
! 8.131 'GMTIME' -- Convert time to GMT info
  ==========================================
  
  _Description_:
       Given a system time value TIME (as provided by the *note TIME::
       intrinsic), fills VALUES with values extracted from it appropriate
       to the UTC time zone (Universal Coordinated Time, also known in
!      some countries as GMT, Greenwich Mean Time), using 'gmtime(3)'.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  In new code, programmers should consider the use
--- 13075,13088 ----
  
  File: gfortran.info,  Node: GMTIME,  Next: HOSTNM,  Prev: GETUID,  Up: Intrinsic Procedures
  
! 8.131 ‘GMTIME’ -- Convert time to GMT info
  ==========================================
  
  _Description_:
       Given a system time value TIME (as provided by the *note TIME::
       intrinsic), fills VALUES with values extracted from it appropriate
       to the UTC time zone (Universal Coordinated Time, also known in
!      some countries as GMT, Greenwich Mean Time), using ‘gmtime(3)’.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  In new code, programmers should consider the use
*************** _Class_:
*** 13096,13108 ****
       Subroutine
  
  _Syntax_:
!      'CALL GMTIME(TIME, VALUES)'
  
  _Arguments_:
!      TIME        An 'INTEGER' scalar expression corresponding to
!                  a system time, with 'INTENT(IN)'.
!      VALUES      A default 'INTEGER' array with 9 elements, with
!                  'INTENT(OUT)'.
  
  _Return value_:
       The elements of VALUES are assigned as follows:
--- 13096,13108 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL GMTIME(TIME, VALUES)’
  
  _Arguments_:
!      TIME        An ‘INTEGER’ scalar expression corresponding to
!                  a system time, with ‘INTENT(IN)’.
!      VALUES      A default ‘INTEGER’ array with 9 elements, with
!                  ‘INTENT(OUT)’.
  
  _Return value_:
       The elements of VALUES are assigned as follows:
*************** _See also_:
*** 13129,13135 ****
  
  File: gfortran.info,  Node: HOSTNM,  Next: HUGE,  Prev: GMTIME,  Up: Intrinsic Procedures
  
! 8.132 'HOSTNM' -- Get system host name
  ======================================
  
  _Description_:
--- 13129,13135 ----
  
  File: gfortran.info,  Node: HOSTNM,  Next: HUGE,  Prev: GMTIME,  Up: Intrinsic Procedures
  
! 8.132 ‘HOSTNM’ -- Get system host name
  ======================================
  
  _Description_:
*************** _Class_:
*** 13146,13157 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL HOSTNM(C [, STATUS])'
!      'STATUS = HOSTNM(NAME)'
  
  _Arguments_:
!      C           Shall of type 'CHARACTER' and of default kind.
!      STATUS      (Optional) status flag of type 'INTEGER'.
                   Returns 0 on success, or a system specific error
                   code otherwise.
  
--- 13146,13157 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL HOSTNM(C [, STATUS])’
!      ‘STATUS = HOSTNM(NAME)’
  
  _Arguments_:
!      C           Shall of type ‘CHARACTER’ and of default kind.
!      STATUS      (Optional) status flag of type ‘INTEGER’.
                   Returns 0 on success, or a system specific error
                   code otherwise.
  
*************** _Return value_:
*** 13162,13173 ****
  
  File: gfortran.info,  Node: HUGE,  Next: HYPOT,  Prev: HOSTNM,  Up: Intrinsic Procedures
  
! 8.133 'HUGE' -- Largest number of a kind
  ========================================
  
  _Description_:
!      'HUGE(X)' returns the largest number that is not an infinity in the
!      model of the type of 'X'.
  
  _Standard_:
       Fortran 90 and later
--- 13162,13173 ----
  
  File: gfortran.info,  Node: HUGE,  Next: HYPOT,  Prev: HOSTNM,  Up: Intrinsic Procedures
  
! 8.133 ‘HUGE’ -- Largest number of a kind
  ========================================
  
  _Description_:
!      ‘HUGE(X)’ returns the largest number that is not an infinity in the
!      model of the type of ‘X’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 13176,13185 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = HUGE(X)'
  
  _Arguments_:
!      X           Shall be of type 'REAL' or 'INTEGER'.
  
  _Return value_:
       The return value is of the same type and kind as X
--- 13176,13185 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = HUGE(X)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’ or ‘INTEGER’.
  
  _Return value_:
       The return value is of the same type and kind as X
*************** _Example_:
*** 13193,13203 ****
  
  File: gfortran.info,  Node: HYPOT,  Next: IACHAR,  Prev: HUGE,  Up: Intrinsic Procedures
  
! 8.134 'HYPOT' -- Euclidean distance function
  ============================================
  
  _Description_:
!      'HYPOT(X,Y)' is the Euclidean distance function.  It is equal to
       \sqrt{X^2 + Y^2}, without undue underflow or overflow.
  
  _Standard_:
--- 13193,13203 ----
  
  File: gfortran.info,  Node: HYPOT,  Next: IACHAR,  Prev: HUGE,  Up: Intrinsic Procedures
  
! 8.134 ‘HYPOT’ -- Euclidean distance function
  ============================================
  
  _Description_:
!      ‘HYPOT(X,Y)’ is the Euclidean distance function.  It is equal to
       \sqrt{X^2 + Y^2}, without undue underflow or overflow.
  
  _Standard_:
*************** _Class_:
*** 13207,13216 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = HYPOT(X, Y)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
       Y           The type and kind type parameter shall be the
                   same as X.
  
--- 13207,13216 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = HYPOT(X, Y)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
       Y           The type and kind type parameter shall be the
                   same as X.
  
*************** _Example_:
*** 13226,13237 ****
  
  File: gfortran.info,  Node: IACHAR,  Next: IALL,  Prev: HYPOT,  Up: Intrinsic Procedures
  
! 8.135 'IACHAR' -- Code in ASCII collating sequence
  ==================================================
  
  _Description_:
!      'IACHAR(C)' returns the code for the ASCII character in the first
!      character position of 'C'.
  
  _Standard_:
       Fortran 95 and later, with KIND argument Fortran 2003 and later
--- 13226,13237 ----
  
  File: gfortran.info,  Node: IACHAR,  Next: IALL,  Prev: HYPOT,  Up: Intrinsic Procedures
  
! 8.135 ‘IACHAR’ -- Code in ASCII collating sequence
  ==================================================
  
  _Description_:
!      ‘IACHAR(C)’ returns the code for the ASCII character in the first
!      character position of ‘C’.
  
  _Standard_:
       Fortran 95 and later, with KIND argument Fortran 2003 and later
*************** _Class_:
*** 13240,13255 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = IACHAR(C [, KIND])'
  
  _Arguments_:
!      C           Shall be a scalar 'CHARACTER', with 'INTENT(IN)'
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Example_:
--- 13240,13255 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = IACHAR(C [, KIND])’
  
  _Arguments_:
!      C           Shall be a scalar ‘CHARACTER’, with ‘INTENT(IN)’
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Example_:
*************** _See also_:
*** 13270,13281 ****
  
  File: gfortran.info,  Node: IALL,  Next: IAND,  Prev: IACHAR,  Up: Intrinsic Procedures
  
! 8.136 'IALL' -- Bitwise AND of array elements
  =============================================
  
  _Description_:
       Reduces with bitwise AND the elements of ARRAY along dimension DIM
!      if the corresponding element in MASK is 'TRUE'.
  
  _Standard_:
       Fortran 2008 and later
--- 13270,13281 ----
  
  File: gfortran.info,  Node: IALL,  Next: IAND,  Prev: IACHAR,  Up: Intrinsic Procedures
  
! 8.136 ‘IALL’ -- Bitwise AND of array elements
  =============================================
  
  _Description_:
       Reduces with bitwise AND the elements of ARRAY along dimension DIM
!      if the corresponding element in MASK is ‘TRUE’.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 13284,13298 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = IALL(ARRAY[, MASK])'
!      'RESULT = IALL(ARRAY, DIM[, MASK])'
  
  _Arguments_:
!      ARRAY       Shall be an array of type 'INTEGER'
!      DIM         (Optional) shall be a scalar of type 'INTEGER'
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
!      MASK        (Optional) shall be of type 'LOGICAL' and either
                   be a scalar or an array of the same shape as
                   ARRAY.
  
--- 13284,13298 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = IALL(ARRAY[, MASK])’
!      ‘RESULT = IALL(ARRAY, DIM[, MASK])’
  
  _Arguments_:
!      ARRAY       Shall be an array of type ‘INTEGER’
!      DIM         (Optional) shall be a scalar of type ‘INTEGER’
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
!      MASK        (Optional) shall be of type ‘LOGICAL’ and either
                   be a scalar or an array of the same shape as
                   ARRAY.
  
*************** _See also_:
*** 13323,13333 ****
  
  File: gfortran.info,  Node: IAND,  Next: IANY,  Prev: IALL,  Up: Intrinsic Procedures
  
! 8.137 'IAND' -- Bitwise logical and
  ===================================
  
  _Description_:
!      Bitwise logical 'AND'.
  
  _Standard_:
       Fortran 90 and later, with boz-literal-constant Fortran 2008 and
--- 13323,13333 ----
  
  File: gfortran.info,  Node: IAND,  Next: IANY,  Prev: IALL,  Up: Intrinsic Procedures
  
! 8.137 ‘IAND’ -- Bitwise logical and
  ===================================
  
  _Description_:
!      Bitwise logical ‘AND’.
  
  _Standard_:
       Fortran 90 and later, with boz-literal-constant Fortran 2008 and
*************** _Class_:
*** 13337,13354 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = IAND(I, J)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER' or a
                   boz-literal-constant.
!      J           The type shall be 'INTEGER' with the same kind
                   type parameter as I or a boz-literal-constant.
                   I and J shall not both be boz-literal-constants.
  
  _Return value_:
!      The return type is 'INTEGER' with the kind type parameter of the
!      arguments.  A boz-literal-constant is converted to an 'INTEGER'
       with the kind type parameter of the other argument as-if a call to
       *note INT:: occurred.
  
--- 13337,13354 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = IAND(I, J)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’ or a
                   boz-literal-constant.
!      J           The type shall be ‘INTEGER’ with the same kind
                   type parameter as I or a boz-literal-constant.
                   I and J shall not both be boz-literal-constants.
  
  _Return value_:
!      The return type is ‘INTEGER’ with the kind type parameter of the
!      arguments.  A boz-literal-constant is converted to an ‘INTEGER’
       with the kind type parameter of the other argument as-if a call to
       *note INT:: occurred.
  
*************** _Example_:
*** 13362,13372 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'IAND(A)'      'INTEGER A'       'INTEGER'      Fortran 90 and later
!      'BIAND(A)'     'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'IIAND(A)'     'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JIAND(A)'     'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KIAND(A)'     'INTEGER(8) A'    'INTEGER(8)'   GNU extension
  
  _See also_:
       *note IOR::,
--- 13362,13372 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘IAND(A)’      ‘INTEGER A’       ‘INTEGER’      Fortran 90 and later
!      ‘BIAND(A)’     ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘IIAND(A)’     ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JIAND(A)’     ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KIAND(A)’     ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note IOR::,
*************** _See also_:
*** 13379,13390 ****
  
  File: gfortran.info,  Node: IANY,  Next: IARGC,  Prev: IAND,  Up: Intrinsic Procedures
  
! 8.138 'IANY' -- Bitwise OR of array elements
  ============================================
  
  _Description_:
       Reduces with bitwise OR (inclusive or) the elements of ARRAY along
!      dimension DIM if the corresponding element in MASK is 'TRUE'.
  
  _Standard_:
       Fortran 2008 and later
--- 13379,13390 ----
  
  File: gfortran.info,  Node: IANY,  Next: IARGC,  Prev: IAND,  Up: Intrinsic Procedures
  
! 8.138 ‘IANY’ -- Bitwise OR of array elements
  ============================================
  
  _Description_:
       Reduces with bitwise OR (inclusive or) the elements of ARRAY along
!      dimension DIM if the corresponding element in MASK is ‘TRUE’.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 13393,13407 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = IANY(ARRAY[, MASK])'
!      'RESULT = IANY(ARRAY, DIM[, MASK])'
  
  _Arguments_:
!      ARRAY       Shall be an array of type 'INTEGER'
!      DIM         (Optional) shall be a scalar of type 'INTEGER'
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
!      MASK        (Optional) shall be of type 'LOGICAL' and either
                   be a scalar or an array of the same shape as
                   ARRAY.
  
--- 13393,13407 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = IANY(ARRAY[, MASK])’
!      ‘RESULT = IANY(ARRAY, DIM[, MASK])’
  
  _Arguments_:
!      ARRAY       Shall be an array of type ‘INTEGER’
!      DIM         (Optional) shall be a scalar of type ‘INTEGER’
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
!      MASK        (Optional) shall be of type ‘LOGICAL’ and either
                   be a scalar or an array of the same shape as
                   ARRAY.
  
*************** _See also_:
*** 13432,13442 ****
  
  File: gfortran.info,  Node: IARGC,  Next: IBCLR,  Prev: IANY,  Up: Intrinsic Procedures
  
! 8.139 'IARGC' -- Get the number of command line arguments
  =========================================================
  
  _Description_:
!      'IARGC' returns the number of arguments passed on the command line
       when the containing program was invoked.
  
       This intrinsic routine is provided for backwards compatibility with
--- 13432,13442 ----
  
  File: gfortran.info,  Node: IARGC,  Next: IBCLR,  Prev: IANY,  Up: Intrinsic Procedures
  
! 8.139 ‘IARGC’ -- Get the number of command line arguments
  =========================================================
  
  _Description_:
!      ‘IARGC’ returns the number of arguments passed on the command line
       when the containing program was invoked.
  
       This intrinsic routine is provided for backwards compatibility with
*************** _Class_:
*** 13451,13463 ****
       Function
  
  _Syntax_:
!      'RESULT = IARGC()'
  
  _Arguments_:
       None
  
  _Return value_:
!      The number of command line arguments, type 'INTEGER(4)'.
  
  _Example_:
       See *note GETARG::
--- 13451,13463 ----
       Function
  
  _Syntax_:
!      ‘RESULT = IARGC()’
  
  _Arguments_:
       None
  
  _Return value_:
!      The number of command line arguments, type ‘INTEGER(4)’.
  
  _Example_:
       See *note GETARG::
*************** _See also_:
*** 13473,13483 ****
  
  File: gfortran.info,  Node: IBCLR,  Next: IBITS,  Prev: IARGC,  Up: Intrinsic Procedures
  
! 8.140 'IBCLR' -- Clear bit
  ==========================
  
  _Description_:
!      'IBCLR' returns the value of I with the bit at position POS set to
       zero.
  
  _Standard_:
--- 13473,13483 ----
  
  File: gfortran.info,  Node: IBCLR,  Next: IBITS,  Prev: IARGC,  Up: Intrinsic Procedures
  
! 8.140 ‘IBCLR’ -- Clear bit
  ==========================
  
  _Description_:
!      ‘IBCLR’ returns the value of I with the bit at position POS set to
       zero.
  
  _Standard_:
*************** _Class_:
*** 13487,13509 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = IBCLR(I, POS)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      POS         The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the same kind as I.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'IBCLR(A)'     'INTEGER A'       'INTEGER'      Fortran 90 and later
!      'BBCLR(A)'     'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'IIBCLR(A)'    'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JIBCLR(A)'    'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KIBCLR(A)'    'INTEGER(8) A'    'INTEGER(8)'   GNU extension
  
  _See also_:
       *note IBITS::,
--- 13487,13509 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = IBCLR(I, POS)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      POS         The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the same kind as I.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘IBCLR(A)’     ‘INTEGER A’       ‘INTEGER’      Fortran 90 and later
!      ‘BBCLR(A)’     ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘IIBCLR(A)’    ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JIBCLR(A)’    ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KIBCLR(A)’    ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note IBITS::,
*************** _See also_:
*** 13516,13529 ****
  
  File: gfortran.info,  Node: IBITS,  Next: IBSET,  Prev: IBCLR,  Up: Intrinsic Procedures
  
! 8.141 'IBITS' -- Bit extraction
  ===============================
  
  _Description_:
!      'IBITS' extracts a field of length LEN from I, starting from bit
       position POS and extending left for LEN bits.  The result is
       right-justified and the remaining bits are zeroed.  The value of
!      'POS+LEN' must be less than or equal to the value 'BIT_SIZE(I)'.
  
  _Standard_:
       Fortran 90 and later, has overloads that are GNU extensions
--- 13516,13529 ----
  
  File: gfortran.info,  Node: IBITS,  Next: IBSET,  Prev: IBCLR,  Up: Intrinsic Procedures
  
! 8.141 ‘IBITS’ -- Bit extraction
  ===============================
  
  _Description_:
!      ‘IBITS’ extracts a field of length LEN from I, starting from bit
       position POS and extending left for LEN bits.  The result is
       right-justified and the remaining bits are zeroed.  The value of
!      ‘POS+LEN’ must be less than or equal to the value ‘BIT_SIZE(I)’.
  
  _Standard_:
       Fortran 90 and later, has overloads that are GNU extensions
*************** _Class_:
*** 13532,13555 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = IBITS(I, POS, LEN)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      POS         The type shall be 'INTEGER'.
!      LEN         The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the same kind as I.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'IBITS(A)'     'INTEGER A'       'INTEGER'      Fortran 90 and later
!      'BBITS(A)'     'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'IIBITS(A)'    'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JIBITS(A)'    'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KIBITS(A)'    'INTEGER(8) A'    'INTEGER(8)'   GNU extension
  
  _See also_:
       *note BIT_SIZE::,
--- 13532,13555 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = IBITS(I, POS, LEN)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      POS         The type shall be ‘INTEGER’.
!      LEN         The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the same kind as I.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘IBITS(A)’     ‘INTEGER A’       ‘INTEGER’      Fortran 90 and later
!      ‘BBITS(A)’     ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘IIBITS(A)’    ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JIBITS(A)’    ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KIBITS(A)’    ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note BIT_SIZE::,
*************** _See also_:
*** 13562,13572 ****
  
  File: gfortran.info,  Node: IBSET,  Next: ICHAR,  Prev: IBITS,  Up: Intrinsic Procedures
  
! 8.142 'IBSET' -- Set bit
  ========================
  
  _Description_:
!      'IBSET' returns the value of I with the bit at position POS set to
       one.
  
  _Standard_:
--- 13562,13572 ----
  
  File: gfortran.info,  Node: IBSET,  Next: ICHAR,  Prev: IBITS,  Up: Intrinsic Procedures
  
! 8.142 ‘IBSET’ -- Set bit
  ========================
  
  _Description_:
!      ‘IBSET’ returns the value of I with the bit at position POS set to
       one.
  
  _Standard_:
*************** _Class_:
*** 13576,13598 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = IBSET(I, POS)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      POS         The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the same kind as I.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'IBSET(A)'     'INTEGER A'       'INTEGER'      Fortran 90 and later
!      'BBSET(A)'     'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'IIBSET(A)'    'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JIBSET(A)'    'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KIBSET(A)'    'INTEGER(8) A'    'INTEGER(8)'   GNU extension
  
  _See also_:
       *note IBCLR::,
--- 13576,13598 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = IBSET(I, POS)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      POS         The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the same kind as I.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘IBSET(A)’     ‘INTEGER A’       ‘INTEGER’      Fortran 90 and later
!      ‘BBSET(A)’     ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘IIBSET(A)’    ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JIBSET(A)’    ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KIBSET(A)’    ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note IBCLR::,
*************** _See also_:
*** 13605,13616 ****
  
  File: gfortran.info,  Node: ICHAR,  Next: IDATE,  Prev: IBSET,  Up: Intrinsic Procedures
  
! 8.143 'ICHAR' -- Character-to-integer conversion function
  =========================================================
  
  _Description_:
!      'ICHAR(C)' returns the code for the character in the first
!      character position of 'C' in the system's native character set.
       The correspondence between characters and their codes is not
       necessarily the same across different GNU Fortran implementations.
  
--- 13605,13616 ----
  
  File: gfortran.info,  Node: ICHAR,  Next: IDATE,  Prev: IBSET,  Up: Intrinsic Procedures
  
! 8.143 ‘ICHAR’ -- Character-to-integer conversion function
  =========================================================
  
  _Description_:
!      ‘ICHAR(C)’ returns the code for the character in the first
!      character position of ‘C’ in the system's native character set.
       The correspondence between characters and their codes is not
       necessarily the same across different GNU Fortran implementations.
  
*************** _Class_:
*** 13621,13636 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ICHAR(C [, KIND])'
  
  _Arguments_:
!      C           Shall be a scalar 'CHARACTER', with 'INTENT(IN)'
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Example_:
--- 13621,13636 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ICHAR(C [, KIND])’
  
  _Arguments_:
!      C           Shall be a scalar ‘CHARACTER’, with ‘INTENT(IN)’
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Example_:
*************** _Example_:
*** 13642,13653 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ICHAR(C)'     'CHARACTER C'     'INTEGER(4)'   Fortran 77 and later
  
  _Note_:
       No intrinsic exists to convert between a numeric value and a
       formatted character string representation - for instance, given the
!      'CHARACTER' value ''154'', obtaining an 'INTEGER' or 'REAL' value
       with the value 154, or vice versa.  Instead, this functionality is
       provided by internal-file I/O, as in the following example:
            program read_val
--- 13642,13653 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ICHAR(C)’     ‘CHARACTER C’     ‘INTEGER(4)’   Fortran 77 and later
  
  _Note_:
       No intrinsic exists to convert between a numeric value and a
       formatted character string representation - for instance, given the
!      ‘CHARACTER’ value ‘'154'’, obtaining an ‘INTEGER’ or ‘REAL’ value
       with the value 154, or vice versa.  Instead, this functionality is
       provided by internal-file I/O, as in the following example:
            program read_val
*************** _See also_:
*** 13672,13682 ****
  
  File: gfortran.info,  Node: IDATE,  Next: IEOR,  Prev: ICHAR,  Up: Intrinsic Procedures
  
! 8.144 'IDATE' -- Get current local time subroutine (day/month/year)
  ===================================================================
  
  _Description_:
!      'IDATE(VALUES)' Fills VALUES with the numerical values at the
       current local time.  The day (in the range 1-31), month (in the
       range 1-12), and year appear in elements 1, 2, and 3 of VALUES,
       respectively.  The year has four significant digits.
--- 13672,13682 ----
  
  File: gfortran.info,  Node: IDATE,  Next: IEOR,  Prev: ICHAR,  Up: Intrinsic Procedures
  
! 8.144 ‘IDATE’ -- Get current local time subroutine (day/month/year)
  ===================================================================
  
  _Description_:
!      ‘IDATE(VALUES)’ Fills VALUES with the numerical values at the
       current local time.  The day (in the range 1-31), month (in the
       range 1-12), and year appear in elements 1, 2, and 3 of VALUES,
       respectively.  The year has four significant digits.
*************** _Class_:
*** 13693,13702 ****
       Subroutine
  
  _Syntax_:
!      'CALL IDATE(VALUES)'
  
  _Arguments_:
!      VALUES      The type shall be 'INTEGER, DIMENSION(3)' and
                   the kind shall be the default integer kind.
  
  _Return value_:
--- 13693,13702 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL IDATE(VALUES)’
  
  _Arguments_:
!      VALUES      The type shall be ‘INTEGER, DIMENSION(3)’ and
                   the kind shall be the default integer kind.
  
  _Return value_:
*************** _See also_:
*** 13717,13727 ****
  
  File: gfortran.info,  Node: IEOR,  Next: IERRNO,  Prev: IDATE,  Up: Intrinsic Procedures
  
! 8.145 'IEOR' -- Bitwise logical exclusive or
  ============================================
  
  _Description_:
!      'IEOR' returns the bitwise Boolean exclusive-OR of I and J.
  
  _Standard_:
       Fortran 90 and later, with boz-literal-constant Fortran 2008 and
--- 13717,13727 ----
  
  File: gfortran.info,  Node: IEOR,  Next: IERRNO,  Prev: IDATE,  Up: Intrinsic Procedures
  
! 8.145 ‘IEOR’ -- Bitwise logical exclusive or
  ============================================
  
  _Description_:
!      ‘IEOR’ returns the bitwise Boolean exclusive-OR of I and J.
  
  _Standard_:
       Fortran 90 and later, with boz-literal-constant Fortran 2008 and
*************** _Class_:
*** 13731,13759 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = IEOR(I, J)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER' or a
                   boz-literal-constant.
!      J           The type shall be 'INTEGER' with the same kind
                   type parameter as I or a boz-literal-constant.
                   I and J shall not both be boz-literal-constants.
  
  _Return value_:
!      The return type is 'INTEGER' with the kind type parameter of the
!      arguments.  A boz-literal-constant is converted to an 'INTEGER'
       with the kind type parameter of the other argument as-if a call to
       *note INT:: occurred.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'IEOR(A)'      'INTEGER A'       'INTEGER'      Fortran 90 and later
!      'BIEOR(A)'     'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'IIEOR(A)'     'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JIEOR(A)'     'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KIEOR(A)'     'INTEGER(8) A'    'INTEGER(8)'   GNU extension
  
  _See also_:
       *note IOR::,
--- 13731,13759 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = IEOR(I, J)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’ or a
                   boz-literal-constant.
!      J           The type shall be ‘INTEGER’ with the same kind
                   type parameter as I or a boz-literal-constant.
                   I and J shall not both be boz-literal-constants.
  
  _Return value_:
!      The return type is ‘INTEGER’ with the kind type parameter of the
!      arguments.  A boz-literal-constant is converted to an ‘INTEGER’
       with the kind type parameter of the other argument as-if a call to
       *note INT:: occurred.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘IEOR(A)’      ‘INTEGER A’       ‘INTEGER’      Fortran 90 and later
!      ‘BIEOR(A)’     ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘IIEOR(A)’     ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JIEOR(A)’     ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KIEOR(A)’     ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note IOR::,
*************** _See also_:
*** 13766,13776 ****
  
  File: gfortran.info,  Node: IERRNO,  Next: IMAGE_INDEX,  Prev: IEOR,  Up: Intrinsic Procedures
  
! 8.146 'IERRNO' -- Get the last system error number
  ==================================================
  
  _Description_:
!      Returns the last system error number, as given by the C 'errno'
       variable.
  
  _Standard_:
--- 13766,13776 ----
  
  File: gfortran.info,  Node: IERRNO,  Next: IMAGE_INDEX,  Prev: IEOR,  Up: Intrinsic Procedures
  
! 8.146 ‘IERRNO’ -- Get the last system error number
  ==================================================
  
  _Description_:
!      Returns the last system error number, as given by the C ‘errno’
       variable.
  
  _Standard_:
*************** _Class_:
*** 13780,13792 ****
       Function
  
  _Syntax_:
!      'RESULT = IERRNO()'
  
  _Arguments_:
       None
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the default integer
       kind.
  
  _See also_:
--- 13780,13792 ----
       Function
  
  _Syntax_:
!      ‘RESULT = IERRNO()’
  
  _Arguments_:
       None
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the default integer
       kind.
  
  _See also_:
*************** _See also_:
*** 13795,13801 ****
  
  File: gfortran.info,  Node: IMAGE_INDEX,  Next: INDEX intrinsic,  Prev: IERRNO,  Up: Intrinsic Procedures
  
! 8.147 'IMAGE_INDEX' -- Function that converts a cosubscript to an image index
  =============================================================================
  
  _Description_:
--- 13795,13801 ----
  
  File: gfortran.info,  Node: IMAGE_INDEX,  Next: INDEX intrinsic,  Prev: IERRNO,  Up: Intrinsic Procedures
  
! 8.147 ‘IMAGE_INDEX’ -- Function that converts a cosubscript to an image index
  =============================================================================
  
  _Description_:
*************** _Class_:
*** 13808,13814 ****
       Inquiry function.
  
  _Syntax_:
!      'RESULT = IMAGE_INDEX(COARRAY, SUB)'
  
  _Arguments_:
       COARRAY     Coarray of any type.
--- 13808,13814 ----
       Inquiry function.
  
  _Syntax_:
!      ‘RESULT = IMAGE_INDEX(COARRAY, SUB)’
  
  _Arguments_:
       COARRAY     Coarray of any type.
*************** _See also_:
*** 13832,13838 ****
  
  File: gfortran.info,  Node: INDEX intrinsic,  Next: INT,  Prev: IMAGE_INDEX,  Up: Intrinsic Procedures
  
! 8.148 'INDEX' -- Position of a substring within a string
  ========================================================
  
  _Description_:
--- 13832,13838 ----
  
  File: gfortran.info,  Node: INDEX intrinsic,  Next: INT,  Prev: IMAGE_INDEX,  Up: Intrinsic Procedures
  
! 8.148 ‘INDEX’ -- Position of a substring within a string
  ========================================================
  
  _Description_:
*************** _Class_:
*** 13849,13874 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = INDEX(STRING, SUBSTRING [, BACK [, KIND]])'
  
  _Arguments_:
!      STRING      Shall be a scalar 'CHARACTER', with 'INTENT(IN)'
!      SUBSTRING   Shall be a scalar 'CHARACTER', with 'INTENT(IN)'
!      BACK        (Optional) Shall be a scalar 'LOGICAL', with
!                  'INTENT(IN)'
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Specific names_:
       Name                      Argument    Return       Standard
                                             type
       --------------------------------------------------------------------------
!      'INDEX(STRING,SUBSTRING)' 'CHARACTER' 'INTEGER(4)' Fortran 77 and later
  
  _See also_:
       *note SCAN::,
--- 13849,13874 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = INDEX(STRING, SUBSTRING [, BACK [, KIND]])’
  
  _Arguments_:
!      STRING      Shall be a scalar ‘CHARACTER’, with ‘INTENT(IN)’
!      SUBSTRING   Shall be a scalar ‘CHARACTER’, with ‘INTENT(IN)’
!      BACK        (Optional) Shall be a scalar ‘LOGICAL’, with
!                  ‘INTENT(IN)’
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Specific names_:
       Name                      Argument    Return       Standard
                                             type
       --------------------------------------------------------------------------
!      ‘INDEX(STRING,SUBSTRING)’ ‘CHARACTER’ ‘INTEGER(4)’ Fortran 77 and later
  
  _See also_:
       *note SCAN::,
*************** _See also_:
*** 13877,13883 ****
  
  File: gfortran.info,  Node: INT,  Next: INT2,  Prev: INDEX intrinsic,  Up: Intrinsic Procedures
  
! 8.149 'INT' -- Convert to integer type
  ======================================
  
  _Description_:
--- 13877,13883 ----
  
  File: gfortran.info,  Node: INT,  Next: INT2,  Prev: INDEX intrinsic,  Up: Intrinsic Procedures
  
! 8.149 ‘INT’ -- Convert to integer type
  ======================================
  
  _Description_:
*************** _Class_:
*** 13891,13918 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = INT(A [, KIND))'
  
  _Arguments_:
!      A           Shall be of type 'INTEGER', 'REAL', or 'COMPLEX'
                   or a boz-literal-constant.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      These functions return a 'INTEGER' variable or array under the
       following rules:
  
       (A)
!           If A is of type 'INTEGER', 'INT(A) = A'
       (B)
!           If A is of type 'REAL' and |A| < 1, 'INT(A)' equals '0'.  If
!           |A| \geq 1, then 'INT(A)' is the integer whose magnitude is
            the largest integer that does not exceed the magnitude of A
            and whose sign is the same as the sign of A.
       (C)
!           If A is of type 'COMPLEX', rule B is applied to the real part
            of A.
  
  _Example_:
--- 13891,13918 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = INT(A [, KIND))’
  
  _Arguments_:
!      A           Shall be of type ‘INTEGER’, ‘REAL’, or ‘COMPLEX’
                   or a boz-literal-constant.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      These functions return a ‘INTEGER’ variable or array under the
       following rules:
  
       (A)
!           If A is of type ‘INTEGER’, ‘INT(A) = A’
       (B)
!           If A is of type ‘REAL’ and |A| < 1, ‘INT(A)’ equals ‘0’.  If
!           |A| \geq 1, then ‘INT(A)’ is the integer whose magnitude is
            the largest integer that does not exceed the magnitude of A
            and whose sign is the same as the sign of A.
       (C)
!           If A is of type ‘COMPLEX’, rule B is applied to the real part
            of A.
  
  _Example_:
*************** _Example_:
*** 13926,13944 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'INT(A)'       'REAL(4) A'       'INTEGER'      Fortran 77 and later
!      'IFIX(A)'      'REAL(4) A'       'INTEGER'      Fortran 77 and later
!      'IDINT(A)'     'REAL(8) A'       'INTEGER'      Fortran 77 and later
  
  
  File: gfortran.info,  Node: INT2,  Next: INT8,  Prev: INT,  Up: Intrinsic Procedures
  
! 8.150 'INT2' -- Convert to 16-bit integer type
  ==============================================
  
  _Description_:
!      Convert to a 'KIND=2' integer type.  This is equivalent to the
!      standard 'INT' intrinsic with an optional argument of 'KIND=2', and
       is only included for backwards compatibility.
  
  _Standard_:
--- 13926,13944 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘INT(A)’       ‘REAL(4) A’       ‘INTEGER’      Fortran 77 and later
!      ‘IFIX(A)’      ‘REAL(4) A’       ‘INTEGER’      Fortran 77 and later
!      ‘IDINT(A)’     ‘REAL(8) A’       ‘INTEGER’      Fortran 77 and later
  
  
  File: gfortran.info,  Node: INT2,  Next: INT8,  Prev: INT,  Up: Intrinsic Procedures
  
! 8.150 ‘INT2’ -- Convert to 16-bit integer type
  ==============================================
  
  _Description_:
!      Convert to a ‘KIND=2’ integer type.  This is equivalent to the
!      standard ‘INT’ intrinsic with an optional argument of ‘KIND=2’, and
       is only included for backwards compatibility.
  
  _Standard_:
*************** _Class_:
*** 13948,13961 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = INT2(A)'
  
  _Arguments_:
!      A           Shall be of type 'INTEGER', 'REAL', or
!                  'COMPLEX'.
  
  _Return value_:
!      The return value is a 'INTEGER(2)' variable.
  
  _See also_:
       *note INT::,
--- 13948,13961 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = INT2(A)’
  
  _Arguments_:
!      A           Shall be of type ‘INTEGER’, ‘REAL’, or
!                  ‘COMPLEX’.
  
  _Return value_:
!      The return value is a ‘INTEGER(2)’ variable.
  
  _See also_:
       *note INT::,
*************** _See also_:
*** 13964,13975 ****
  
  File: gfortran.info,  Node: INT8,  Next: IOR,  Prev: INT2,  Up: Intrinsic Procedures
  
! 8.151 'INT8' -- Convert to 64-bit integer type
  ==============================================
  
  _Description_:
!      Convert to a 'KIND=8' integer type.  This is equivalent to the
!      standard 'INT' intrinsic with an optional argument of 'KIND=8', and
       is only included for backwards compatibility.
  
  _Standard_:
--- 13964,13975 ----
  
  File: gfortran.info,  Node: INT8,  Next: IOR,  Prev: INT2,  Up: Intrinsic Procedures
  
! 8.151 ‘INT8’ -- Convert to 64-bit integer type
  ==============================================
  
  _Description_:
!      Convert to a ‘KIND=8’ integer type.  This is equivalent to the
!      standard ‘INT’ intrinsic with an optional argument of ‘KIND=8’, and
       is only included for backwards compatibility.
  
  _Standard_:
*************** _Class_:
*** 13979,13992 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = INT8(A)'
  
  _Arguments_:
!      A           Shall be of type 'INTEGER', 'REAL', or
!                  'COMPLEX'.
  
  _Return value_:
!      The return value is a 'INTEGER(8)' variable.
  
  _See also_:
       *note INT::,
--- 13979,13992 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = INT8(A)’
  
  _Arguments_:
!      A           Shall be of type ‘INTEGER’, ‘REAL’, or
!                  ‘COMPLEX’.
  
  _Return value_:
!      The return value is a ‘INTEGER(8)’ variable.
  
  _See also_:
       *note INT::,
*************** _See also_:
*** 13995,14005 ****
  
  File: gfortran.info,  Node: IOR,  Next: IPARITY,  Prev: INT8,  Up: Intrinsic Procedures
  
! 8.152 'IOR' -- Bitwise logical or
  =================================
  
  _Description_:
!      'IOR' returns the bitwise Boolean inclusive-OR of I and J.
  
  _Standard_:
       Fortran 90 and later, with boz-literal-constant Fortran 2008 and
--- 13995,14005 ----
  
  File: gfortran.info,  Node: IOR,  Next: IPARITY,  Prev: INT8,  Up: Intrinsic Procedures
  
! 8.152 ‘IOR’ -- Bitwise logical or
  =================================
  
  _Description_:
!      ‘IOR’ returns the bitwise Boolean inclusive-OR of I and J.
  
  _Standard_:
       Fortran 90 and later, with boz-literal-constant Fortran 2008 and
*************** _Class_:
*** 14009,14037 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = IOR(I, J)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER' or a
                   boz-literal-constant.
!      J           The type shall be 'INTEGER' with the same kind
                   type parameter as I or a boz-literal-constant.
                   I and J shall not both be boz-literal-constants.
  
  _Return value_:
!      The return type is 'INTEGER' with the kind type parameter of the
!      arguments.  A boz-literal-constant is converted to an 'INTEGER'
       with the kind type parameter of the other argument as-if a call to
       *note INT:: occurred.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'IOR(A)'       'INTEGER A'       'INTEGER'      Fortran 90 and later
!      'BIOR(A)'      'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'IIOR(A)'      'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JIOR(A)'      'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KIOR(A)'      'INTEGER(8) A'    'INTEGER(8)'   GNU extension
  
  _See also_:
       *note IEOR::,
--- 14009,14037 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = IOR(I, J)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’ or a
                   boz-literal-constant.
!      J           The type shall be ‘INTEGER’ with the same kind
                   type parameter as I or a boz-literal-constant.
                   I and J shall not both be boz-literal-constants.
  
  _Return value_:
!      The return type is ‘INTEGER’ with the kind type parameter of the
!      arguments.  A boz-literal-constant is converted to an ‘INTEGER’
       with the kind type parameter of the other argument as-if a call to
       *note INT:: occurred.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘IOR(A)’       ‘INTEGER A’       ‘INTEGER’      Fortran 90 and later
!      ‘BIOR(A)’      ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘IIOR(A)’      ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JIOR(A)’      ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KIOR(A)’      ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note IEOR::,
*************** _See also_:
*** 14044,14055 ****
  
  File: gfortran.info,  Node: IPARITY,  Next: IRAND,  Prev: IOR,  Up: Intrinsic Procedures
  
! 8.153 'IPARITY' -- Bitwise XOR of array elements
  ================================================
  
  _Description_:
       Reduces with bitwise XOR (exclusive or) the elements of ARRAY along
!      dimension DIM if the corresponding element in MASK is 'TRUE'.
  
  _Standard_:
       Fortran 2008 and later
--- 14044,14055 ----
  
  File: gfortran.info,  Node: IPARITY,  Next: IRAND,  Prev: IOR,  Up: Intrinsic Procedures
  
! 8.153 ‘IPARITY’ -- Bitwise XOR of array elements
  ================================================
  
  _Description_:
       Reduces with bitwise XOR (exclusive or) the elements of ARRAY along
!      dimension DIM if the corresponding element in MASK is ‘TRUE’.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 14058,14072 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = IPARITY(ARRAY[, MASK])'
!      'RESULT = IPARITY(ARRAY, DIM[, MASK])'
  
  _Arguments_:
!      ARRAY       Shall be an array of type 'INTEGER'
!      DIM         (Optional) shall be a scalar of type 'INTEGER'
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
!      MASK        (Optional) shall be of type 'LOGICAL' and either
                   be a scalar or an array of the same shape as
                   ARRAY.
  
--- 14058,14072 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = IPARITY(ARRAY[, MASK])’
!      ‘RESULT = IPARITY(ARRAY, DIM[, MASK])’
  
  _Arguments_:
!      ARRAY       Shall be an array of type ‘INTEGER’
!      DIM         (Optional) shall be a scalar of type ‘INTEGER’
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
!      MASK        (Optional) shall be of type ‘LOGICAL’ and either
                   be a scalar or an array of the same shape as
                   ARRAY.
  
*************** _See also_:
*** 14098,14117 ****
  
  File: gfortran.info,  Node: IRAND,  Next: IS_CONTIGUOUS,  Prev: IPARITY,  Up: Intrinsic Procedures
  
! 8.154 'IRAND' -- Integer pseudo-random number
  =============================================
  
  _Description_:
!      'IRAND(FLAG)' returns a pseudo-random number from a uniform
       distribution between 0 and a system-dependent limit (which is in
       most cases 2147483647).  If FLAG is 0, the next number in the
       current sequence is returned; if FLAG is 1, the generator is
!      restarted by 'CALL SRAND(0)'; if FLAG has any other value, it is
!      used as a new seed with 'SRAND'.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  It implements a simple modulo generator as
!      provided by 'g77'.  For new code, one should consider the use of
       *note RANDOM_NUMBER:: as it implements a superior algorithm.
  
  _Standard_:
--- 14098,14117 ----
  
  File: gfortran.info,  Node: IRAND,  Next: IS_CONTIGUOUS,  Prev: IPARITY,  Up: Intrinsic Procedures
  
! 8.154 ‘IRAND’ -- Integer pseudo-random number
  =============================================
  
  _Description_:
!      ‘IRAND(FLAG)’ returns a pseudo-random number from a uniform
       distribution between 0 and a system-dependent limit (which is in
       most cases 2147483647).  If FLAG is 0, the next number in the
       current sequence is returned; if FLAG is 1, the generator is
!      restarted by ‘CALL SRAND(0)’; if FLAG has any other value, it is
!      used as a new seed with ‘SRAND’.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  It implements a simple modulo generator as
!      provided by ‘g77’.  For new code, one should consider the use of
       *note RANDOM_NUMBER:: as it implements a superior algorithm.
  
  _Standard_:
*************** _Class_:
*** 14121,14133 ****
       Function
  
  _Syntax_:
!      'RESULT = IRAND(I)'
  
  _Arguments_:
!      I           Shall be a scalar 'INTEGER' of kind 4.
  
  _Return value_:
!      The return value is of 'INTEGER(kind=4)' type.
  
  _Example_:
            program test_irand
--- 14121,14133 ----
       Function
  
  _Syntax_:
!      ‘RESULT = IRAND(I)’
  
  _Arguments_:
!      I           Shall be a scalar ‘INTEGER’ of kind 4.
  
  _Return value_:
!      The return value is of ‘INTEGER(kind=4)’ type.
  
  _Example_:
            program test_irand
*************** _Example_:
*** 14141,14151 ****
  
  File: gfortran.info,  Node: IS_CONTIGUOUS,  Next: IS_IOSTAT_END,  Prev: IRAND,  Up: Intrinsic Procedures
  
! 8.155 'IS_CONTIGUOUS' -- Test whether an array is contiguous
  ============================================================
  
  _Description_:
!      'IS_CONTIGUOUS' tests whether an array is contiguous.
  
  _Standard_:
       Fortran 2008 and later
--- 14141,14151 ----
  
  File: gfortran.info,  Node: IS_CONTIGUOUS,  Next: IS_IOSTAT_END,  Prev: IRAND,  Up: Intrinsic Procedures
  
! 8.155 ‘IS_CONTIGUOUS’ -- Test whether an array is contiguous
  ============================================================
  
  _Description_:
!      ‘IS_CONTIGUOUS’ tests whether an array is contiguous.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 14154,14166 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = IS_CONTIGUOUS(ARRAY)'
  
  _Arguments_:
       ARRAY       Shall be an array of any type.
  
  _Return value_:
!      Returns a 'LOGICAL' of the default kind, which '.TRUE.' if ARRAY is
       contiguous and false otherwise.
  
  _Example_:
--- 14154,14166 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = IS_CONTIGUOUS(ARRAY)’
  
  _Arguments_:
       ARRAY       Shall be an array of any type.
  
  _Return value_:
!      Returns a ‘LOGICAL’ of the default kind, which ‘.TRUE.’ if ARRAY is
       contiguous and false otherwise.
  
  _Example_:
*************** _Example_:
*** 14183,14196 ****
  
  File: gfortran.info,  Node: IS_IOSTAT_END,  Next: IS_IOSTAT_EOR,  Prev: IS_CONTIGUOUS,  Up: Intrinsic Procedures
  
! 8.156 'IS_IOSTAT_END' -- Test for end-of-file value
  ===================================================
  
  _Description_:
!      'IS_IOSTAT_END' tests whether an variable has the value of the I/O
       status "end of file".  The function is equivalent to comparing the
!      variable with the 'IOSTAT_END' parameter of the intrinsic module
!      'ISO_FORTRAN_ENV'.
  
  _Standard_:
       Fortran 2003 and later
--- 14183,14196 ----
  
  File: gfortran.info,  Node: IS_IOSTAT_END,  Next: IS_IOSTAT_EOR,  Prev: IS_CONTIGUOUS,  Up: Intrinsic Procedures
  
! 8.156 ‘IS_IOSTAT_END’ -- Test for end-of-file value
  ===================================================
  
  _Description_:
!      ‘IS_IOSTAT_END’ tests whether an variable has the value of the I/O
       status "end of file".  The function is equivalent to comparing the
!      variable with the ‘IOSTAT_END’ parameter of the intrinsic module
!      ‘ISO_FORTRAN_ENV’.
  
  _Standard_:
       Fortran 2003 and later
*************** _Class_:
*** 14199,14213 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = IS_IOSTAT_END(I)'
  
  _Arguments_:
!      I           Shall be of the type 'INTEGER'.
  
  _Return value_:
!      Returns a 'LOGICAL' of the default kind, which '.TRUE.' if I has
!      the value which indicates an end of file condition for 'IOSTAT='
!      specifiers, and is '.FALSE.' otherwise.
  
  _Example_:
            PROGRAM iostat
--- 14199,14213 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = IS_IOSTAT_END(I)’
  
  _Arguments_:
!      I           Shall be of the type ‘INTEGER’.
  
  _Return value_:
!      Returns a ‘LOGICAL’ of the default kind, which ‘.TRUE.’ if I has
!      the value which indicates an end of file condition for ‘IOSTAT=’
!      specifiers, and is ‘.FALSE.’ otherwise.
  
  _Example_:
            PROGRAM iostat
*************** _Example_:
*** 14221,14234 ****
  
  File: gfortran.info,  Node: IS_IOSTAT_EOR,  Next: ISATTY,  Prev: IS_IOSTAT_END,  Up: Intrinsic Procedures
  
! 8.157 'IS_IOSTAT_EOR' -- Test for end-of-record value
  =====================================================
  
  _Description_:
!      'IS_IOSTAT_EOR' tests whether an variable has the value of the I/O
       status "end of record".  The function is equivalent to comparing
!      the variable with the 'IOSTAT_EOR' parameter of the intrinsic
!      module 'ISO_FORTRAN_ENV'.
  
  _Standard_:
       Fortran 2003 and later
--- 14221,14234 ----
  
  File: gfortran.info,  Node: IS_IOSTAT_EOR,  Next: ISATTY,  Prev: IS_IOSTAT_END,  Up: Intrinsic Procedures
  
! 8.157 ‘IS_IOSTAT_EOR’ -- Test for end-of-record value
  =====================================================
  
  _Description_:
!      ‘IS_IOSTAT_EOR’ tests whether an variable has the value of the I/O
       status "end of record".  The function is equivalent to comparing
!      the variable with the ‘IOSTAT_EOR’ parameter of the intrinsic
!      module ‘ISO_FORTRAN_ENV’.
  
  _Standard_:
       Fortran 2003 and later
*************** _Class_:
*** 14237,14251 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = IS_IOSTAT_EOR(I)'
  
  _Arguments_:
!      I           Shall be of the type 'INTEGER'.
  
  _Return value_:
!      Returns a 'LOGICAL' of the default kind, which '.TRUE.' if I has
!      the value which indicates an end of file condition for 'IOSTAT='
!      specifiers, and is '.FALSE.' otherwise.
  
  _Example_:
            PROGRAM iostat
--- 14237,14251 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = IS_IOSTAT_EOR(I)’
  
  _Arguments_:
!      I           Shall be of the type ‘INTEGER’.
  
  _Return value_:
!      Returns a ‘LOGICAL’ of the default kind, which ‘.TRUE.’ if I has
!      the value which indicates an end of file condition for ‘IOSTAT=’
!      specifiers, and is ‘.FALSE.’ otherwise.
  
  _Example_:
            PROGRAM iostat
*************** _Example_:
*** 14259,14265 ****
  
  File: gfortran.info,  Node: ISATTY,  Next: ISHFT,  Prev: IS_IOSTAT_EOR,  Up: Intrinsic Procedures
  
! 8.158 'ISATTY' -- Whether a unit is a terminal device
  =====================================================
  
  _Description_:
--- 14259,14265 ----
  
  File: gfortran.info,  Node: ISATTY,  Next: ISHFT,  Prev: IS_IOSTAT_EOR,  Up: Intrinsic Procedures
  
! 8.158 ‘ISATTY’ -- Whether a unit is a terminal device
  =====================================================
  
  _Description_:
*************** _Class_:
*** 14272,14285 ****
       Function
  
  _Syntax_:
!      'RESULT = ISATTY(UNIT)'
  
  _Arguments_:
!      UNIT        Shall be a scalar 'INTEGER'.
  
  _Return value_:
!      Returns '.TRUE.' if the UNIT is connected to a terminal device,
!      '.FALSE.' otherwise.
  
  _Example_:
            PROGRAM test_isatty
--- 14272,14285 ----
       Function
  
  _Syntax_:
!      ‘RESULT = ISATTY(UNIT)’
  
  _Arguments_:
!      UNIT        Shall be a scalar ‘INTEGER’.
  
  _Return value_:
!      Returns ‘.TRUE.’ if the UNIT is connected to a terminal device,
!      ‘.FALSE.’ otherwise.
  
  _Example_:
            PROGRAM test_isatty
*************** _See also_:
*** 14294,14308 ****
  
  File: gfortran.info,  Node: ISHFT,  Next: ISHFTC,  Prev: ISATTY,  Up: Intrinsic Procedures
  
! 8.159 'ISHFT' -- Shift bits
  ===========================
  
  _Description_:
!      'ISHFT' returns a value corresponding to I with all of the bits
       shifted SHIFT places.  A value of SHIFT greater than zero
       corresponds to a left shift, a value of zero corresponds to no
       shift, and a value less than zero corresponds to a right shift.  If
!      the absolute value of SHIFT is greater than 'BIT_SIZE(I)', the
       value is undefined.  Bits shifted out from the left end or right
       end are lost; zeros are shifted in from the opposite end.
  
--- 14294,14308 ----
  
  File: gfortran.info,  Node: ISHFT,  Next: ISHFTC,  Prev: ISATTY,  Up: Intrinsic Procedures
  
! 8.159 ‘ISHFT’ -- Shift bits
  ===========================
  
  _Description_:
!      ‘ISHFT’ returns a value corresponding to I with all of the bits
       shifted SHIFT places.  A value of SHIFT greater than zero
       corresponds to a left shift, a value of zero corresponds to no
       shift, and a value less than zero corresponds to a right shift.  If
!      the absolute value of SHIFT is greater than ‘BIT_SIZE(I)’, the
       value is undefined.  Bits shifted out from the left end or right
       end are lost; zeros are shifted in from the opposite end.
  
*************** _Class_:
*** 14313,14335 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ISHFT(I, SHIFT)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      SHIFT       The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the same kind as I.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ISHFT(A)'     'INTEGER A'       'INTEGER'      Fortran 90 and later
!      'BSHFT(A)'     'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'IISHFT(A)'    'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JISHFT(A)'    'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KISHFT(A)'    'INTEGER(8) A'    'INTEGER(8)'   GNU extension
  
  _See also_:
       *note ISHFTC::
--- 14313,14335 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ISHFT(I, SHIFT)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      SHIFT       The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the same kind as I.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ISHFT(A)’     ‘INTEGER A’       ‘INTEGER’      Fortran 90 and later
!      ‘BSHFT(A)’     ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘IISHFT(A)’    ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JISHFT(A)’    ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KISHFT(A)’    ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note ISHFTC::
*************** _See also_:
*** 14337,14354 ****
  
  File: gfortran.info,  Node: ISHFTC,  Next: ISNAN,  Prev: ISHFT,  Up: Intrinsic Procedures
  
! 8.160 'ISHFTC' -- Shift bits circularly
  =======================================
  
  _Description_:
!      'ISHFTC' returns a value corresponding to I with the rightmost SIZE
       bits shifted circularly SHIFT places; that is, bits shifted out one
       end are shifted into the opposite end.  A value of SHIFT greater
       than zero corresponds to a left shift, a value of zero corresponds
       to no shift, and a value less than zero corresponds to a right
       shift.  The absolute value of SHIFT must be less than SIZE.  If the
       SIZE argument is omitted, it is taken to be equivalent to
!      'BIT_SIZE(I)'.
  
  _Standard_:
       Fortran 90 and later, has overloads that are GNU extensions
--- 14337,14354 ----
  
  File: gfortran.info,  Node: ISHFTC,  Next: ISNAN,  Prev: ISHFT,  Up: Intrinsic Procedures
  
! 8.160 ‘ISHFTC’ -- Shift bits circularly
  =======================================
  
  _Description_:
!      ‘ISHFTC’ returns a value corresponding to I with the rightmost SIZE
       bits shifted circularly SHIFT places; that is, bits shifted out one
       end are shifted into the opposite end.  A value of SHIFT greater
       than zero corresponds to a left shift, a value of zero corresponds
       to no shift, and a value less than zero corresponds to a right
       shift.  The absolute value of SHIFT must be less than SIZE.  If the
       SIZE argument is omitted, it is taken to be equivalent to
!      ‘BIT_SIZE(I)’.
  
  _Standard_:
       Fortran 90 and later, has overloads that are GNU extensions
*************** _Class_:
*** 14357,14382 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = ISHFTC(I, SHIFT [, SIZE])'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      SHIFT       The type shall be 'INTEGER'.
!      SIZE        (Optional) The type shall be 'INTEGER'; the
                   value must be greater than zero and less than or
!                  equal to 'BIT_SIZE(I)'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the same kind as I.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ISHFTC(A)'    'INTEGER A'       'INTEGER'      Fortran 90 and later
!      'BSHFTC(A)'    'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'IISHFTC(A)'   'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JISHFTC(A)'   'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KISHFTC(A)'   'INTEGER(8) A'    'INTEGER(8)'   GNU extension
  
  _See also_:
       *note ISHFT::
--- 14357,14382 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = ISHFTC(I, SHIFT [, SIZE])’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      SHIFT       The type shall be ‘INTEGER’.
!      SIZE        (Optional) The type shall be ‘INTEGER’; the
                   value must be greater than zero and less than or
!                  equal to ‘BIT_SIZE(I)’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the same kind as I.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ISHFTC(A)’    ‘INTEGER A’       ‘INTEGER’      Fortran 90 and later
!      ‘BSHFTC(A)’    ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘IISHFTC(A)’   ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JISHFTC(A)’   ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KISHFTC(A)’   ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note ISHFT::
*************** _See also_:
*** 14384,14394 ****
  
  File: gfortran.info,  Node: ISNAN,  Next: ITIME,  Prev: ISHFTC,  Up: Intrinsic Procedures
  
! 8.161 'ISNAN' -- Test for a NaN
  ===============================
  
  _Description_:
!      'ISNAN' tests whether a floating-point value is an IEEE
       Not-a-Number (NaN).
  _Standard_:
       GNU extension
--- 14384,14394 ----
  
  File: gfortran.info,  Node: ISNAN,  Next: ITIME,  Prev: ISHFTC,  Up: Intrinsic Procedures
  
! 8.161 ‘ISNAN’ -- Test for a NaN
  ===============================
  
  _Description_:
!      ‘ISNAN’ tests whether a floating-point value is an IEEE
       Not-a-Number (NaN).
  _Standard_:
       GNU extension
*************** _Class_:
*** 14397,14411 ****
       Elemental function
  
  _Syntax_:
!      'ISNAN(X)'
  
  _Arguments_:
!      X           Variable of the type 'REAL'.
                   
  
  _Return value_:
!      Returns a default-kind 'LOGICAL'.  The returned value is 'TRUE' if
!      X is a NaN and 'FALSE' otherwise.
  
  _Example_:
            program test_nan
--- 14397,14411 ----
       Elemental function
  
  _Syntax_:
!      ‘ISNAN(X)’
  
  _Arguments_:
!      X           Variable of the type ‘REAL’.
                   
  
  _Return value_:
!      Returns a default-kind ‘LOGICAL’.  The returned value is ‘TRUE’ if
!      X is a NaN and ‘FALSE’ otherwise.
  
  _Example_:
            program test_nan
*************** _Example_:
*** 14419,14429 ****
  
  File: gfortran.info,  Node: ITIME,  Next: KILL,  Prev: ISNAN,  Up: Intrinsic Procedures
  
! 8.162 'ITIME' -- Get current local time subroutine (hour/minutes/seconds)
  =========================================================================
  
  _Description_:
!      'ITIME(VALUES)' Fills VALUES with the numerical values at the
       current local time.  The hour (in the range 1-24), minute (in the
       range 1-60), and seconds (in the range 1-60) appear in elements 1,
       2, and 3 of VALUES, respectively.
--- 14419,14429 ----
  
  File: gfortran.info,  Node: ITIME,  Next: KILL,  Prev: ISNAN,  Up: Intrinsic Procedures
  
! 8.162 ‘ITIME’ -- Get current local time subroutine (hour/minutes/seconds)
  =========================================================================
  
  _Description_:
!      ‘ITIME(VALUES)’ Fills VALUES with the numerical values at the
       current local time.  The hour (in the range 1-24), minute (in the
       range 1-60), and seconds (in the range 1-60) appear in elements 1,
       2, and 3 of VALUES, respectively.
*************** _Class_:
*** 14440,14449 ****
       Subroutine
  
  _Syntax_:
!      'CALL ITIME(VALUES)'
  
  _Arguments_:
!      VALUES      The type shall be 'INTEGER, DIMENSION(3)' and
                   the kind shall be the default integer kind.
  
  _Return value_:
--- 14440,14449 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL ITIME(VALUES)’
  
  _Arguments_:
!      VALUES      The type shall be ‘INTEGER, DIMENSION(3)’ and
                   the kind shall be the default integer kind.
  
  _Return value_:
*************** _See also_:
*** 14464,14475 ****
  
  File: gfortran.info,  Node: KILL,  Next: KIND,  Prev: ITIME,  Up: Intrinsic Procedures
  
! 8.163 'KILL' -- Send a signal to a process
  ==========================================
  
  _Description_:
       Sends the signal specified by SIG to the process PID.  See
!      'kill(2)'.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 14464,14475 ----
  
  File: gfortran.info,  Node: KILL,  Next: KIND,  Prev: ITIME,  Up: Intrinsic Procedures
  
! 8.163 ‘KILL’ -- Send a signal to a process
  ==========================================
  
  _Description_:
       Sends the signal specified by SIG to the process PID.  See
!      ‘kill(2)’.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 14483,14499 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL KILL(PID, SIG [, STATUS])'
!      'STATUS = KILL(PID, SIG)'
  
  _Arguments_:
!      PID         Shall be a scalar 'INTEGER' with 'INTENT(IN)'.
!      SIG         Shall be a scalar 'INTEGER' with 'INTENT(IN)'.
       STATUS      [Subroutine](Optional) Shall be a scalar
!                  'INTEGER'.  Returns 0 on success; otherwise a
                   system-specific error code is returned.
       STATUS      [Function] The kind type parameter is that of
!                  'pid'.  Returns 0 on success; otherwise a
                   system-specific error code is returned.
  
  _See also_:
--- 14483,14499 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL KILL(PID, SIG [, STATUS])’
!      ‘STATUS = KILL(PID, SIG)’
  
  _Arguments_:
!      PID         Shall be a scalar ‘INTEGER’ with ‘INTENT(IN)’.
!      SIG         Shall be a scalar ‘INTEGER’ with ‘INTENT(IN)’.
       STATUS      [Subroutine](Optional) Shall be a scalar
!                  ‘INTEGER’.  Returns 0 on success; otherwise a
                   system-specific error code is returned.
       STATUS      [Function] The kind type parameter is that of
!                  ‘pid’.  Returns 0 on success; otherwise a
                   system-specific error code is returned.
  
  _See also_:
*************** _See also_:
*** 14503,14513 ****
  
  File: gfortran.info,  Node: KIND,  Next: LBOUND,  Prev: KILL,  Up: Intrinsic Procedures
  
! 8.164 'KIND' -- Kind of an entity
  =================================
  
  _Description_:
!      'KIND(X)' returns the kind value of the entity X.
  
  _Standard_:
       Fortran 95 and later
--- 14503,14513 ----
  
  File: gfortran.info,  Node: KIND,  Next: LBOUND,  Prev: KILL,  Up: Intrinsic Procedures
  
! 8.164 ‘KIND’ -- Kind of an entity
  =================================
  
  _Description_:
!      ‘KIND(X)’ returns the kind value of the entity X.
  
  _Standard_:
       Fortran 95 and later
*************** _Class_:
*** 14516,14530 ****
       Inquiry function
  
  _Syntax_:
!      'K = KIND(X)'
  
  _Arguments_:
!      X           Shall be of type 'LOGICAL', 'INTEGER', 'REAL',
!                  'COMPLEX' or 'CHARACTER'.  It may be scalar or
                   array valued.
  
  _Return value_:
!      The return value is a scalar of type 'INTEGER' and of the default
       integer kind.
  
  _Example_:
--- 14516,14530 ----
       Inquiry function
  
  _Syntax_:
!      ‘K = KIND(X)’
  
  _Arguments_:
!      X           Shall be of type ‘LOGICAL’, ‘INTEGER’, ‘REAL’,
!                  ‘COMPLEX’ or ‘CHARACTER’.  It may be scalar or
                   array valued.
  
  _Return value_:
!      The return value is a scalar of type ‘INTEGER’ and of the default
       integer kind.
  
  _Example_:
*************** _Example_:
*** 14539,14545 ****
  
  File: gfortran.info,  Node: LBOUND,  Next: LCOBOUND,  Prev: KIND,  Up: Intrinsic Procedures
  
! 8.165 'LBOUND' -- Lower dimension bounds of an array
  ====================================================
  
  _Description_:
--- 14539,14545 ----
  
  File: gfortran.info,  Node: LBOUND,  Next: LCOBOUND,  Prev: KIND,  Up: Intrinsic Procedures
  
! 8.165 ‘LBOUND’ -- Lower dimension bounds of an array
  ====================================================
  
  _Description_:
*************** _Class_:
*** 14552,14568 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = LBOUND(ARRAY [, DIM [, KIND]])'
  
  _Arguments_:
       ARRAY       Shall be an array, of any type.
!      DIM         (Optional) Shall be a scalar 'INTEGER'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.  If DIM is
       absent, the result is an array of the lower bounds of ARRAY.  If
       DIM is present, the result is a scalar corresponding to the lower
--- 14552,14568 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = LBOUND(ARRAY [, DIM [, KIND]])’
  
  _Arguments_:
       ARRAY       Shall be an array, of any type.
!      DIM         (Optional) Shall be a scalar ‘INTEGER’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.  If DIM is
       absent, the result is an array of the lower bounds of ARRAY.  If
       DIM is present, the result is a scalar corresponding to the lower
*************** _See also_:
*** 14578,14584 ****
  
  File: gfortran.info,  Node: LCOBOUND,  Next: LEADZ,  Prev: LBOUND,  Up: Intrinsic Procedures
  
! 8.166 'LCOBOUND' -- Lower codimension bounds of an array
  ========================================================
  
  _Description_:
--- 14578,14584 ----
  
  File: gfortran.info,  Node: LCOBOUND,  Next: LEADZ,  Prev: LBOUND,  Up: Intrinsic Procedures
  
! 8.166 ‘LCOBOUND’ -- Lower codimension bounds of an array
  ========================================================
  
  _Description_:
*************** _Class_:
*** 14591,14607 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = LCOBOUND(COARRAY [, DIM [, KIND]])'
  
  _Arguments_:
       ARRAY       Shall be an coarray, of any type.
!      DIM         (Optional) Shall be a scalar 'INTEGER'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.  If DIM is
       absent, the result is an array of the lower cobounds of COARRAY.
       If DIM is present, the result is a scalar corresponding to the
--- 14591,14607 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = LCOBOUND(COARRAY [, DIM [, KIND]])’
  
  _Arguments_:
       ARRAY       Shall be an coarray, of any type.
!      DIM         (Optional) Shall be a scalar ‘INTEGER’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.  If DIM is
       absent, the result is an array of the lower cobounds of COARRAY.
       If DIM is present, the result is a scalar corresponding to the
*************** _See also_:
*** 14614,14624 ****
  
  File: gfortran.info,  Node: LEADZ,  Next: LEN,  Prev: LCOBOUND,  Up: Intrinsic Procedures
  
! 8.167 'LEADZ' -- Number of leading zero bits of an integer
  ==========================================================
  
  _Description_:
!      'LEADZ' returns the number of leading zero bits of an integer.
  
  _Standard_:
       Fortran 2008 and later
--- 14614,14624 ----
  
  File: gfortran.info,  Node: LEADZ,  Next: LEN,  Prev: LCOBOUND,  Up: Intrinsic Procedures
  
! 8.167 ‘LEADZ’ -- Number of leading zero bits of an integer
  ==========================================================
  
  _Description_:
!      ‘LEADZ’ returns the number of leading zero bits of an integer.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 14627,14640 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LEADZ(I)'
  
  _Arguments_:
!      I           Shall be of type 'INTEGER'.
  
  _Return value_:
!      The type of the return value is the default 'INTEGER'.  If all the
!      bits of 'I' are zero, the result value is 'BIT_SIZE(I)'.
  
  _Example_:
            PROGRAM test_leadz
--- 14627,14640 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LEADZ(I)’
  
  _Arguments_:
!      I           Shall be of type ‘INTEGER’.
  
  _Return value_:
!      The type of the return value is the default ‘INTEGER’.  If all the
!      bits of ‘I’ are zero, the result value is ‘BIT_SIZE(I)’.
  
  _Example_:
            PROGRAM test_leadz
*************** _See also_:
*** 14651,14657 ****
  
  File: gfortran.info,  Node: LEN,  Next: LEN_TRIM,  Prev: LEADZ,  Up: Intrinsic Procedures
  
! 8.168 'LEN' -- Length of a character entity
  ===========================================
  
  _Description_:
--- 14651,14657 ----
  
  File: gfortran.info,  Node: LEN,  Next: LEN_TRIM,  Prev: LEADZ,  Up: Intrinsic Procedures
  
! 8.168 ‘LEN’ -- Length of a character entity
  ===========================================
  
  _Description_:
*************** _Class_:
*** 14667,14689 ****
       Inquiry function
  
  _Syntax_:
!      'L = LEN(STRING [, KIND])'
  
  _Arguments_:
!      STRING      Shall be a scalar or array of type 'CHARACTER',
!                  with 'INTENT(IN)'
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'LEN(STRING)'  'CHARACTER'       'INTEGER'      Fortran 77 and later
  
  _See also_:
       *note LEN_TRIM::,
--- 14667,14689 ----
       Inquiry function
  
  _Syntax_:
!      ‘L = LEN(STRING [, KIND])’
  
  _Arguments_:
!      STRING      Shall be a scalar or array of type ‘CHARACTER’,
!                  with ‘INTENT(IN)’
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘LEN(STRING)’  ‘CHARACTER’       ‘INTEGER’      Fortran 77 and later
  
  _See also_:
       *note LEN_TRIM::,
*************** _See also_:
*** 14693,14699 ****
  
  File: gfortran.info,  Node: LEN_TRIM,  Next: LGE,  Prev: LEN,  Up: Intrinsic Procedures
  
! 8.169 'LEN_TRIM' -- Length of a character entity without trailing blank characters
  ==================================================================================
  
  _Description_:
--- 14693,14699 ----
  
  File: gfortran.info,  Node: LEN_TRIM,  Next: LGE,  Prev: LEN,  Up: Intrinsic Procedures
  
! 8.169 ‘LEN_TRIM’ -- Length of a character entity without trailing blank characters
  ==================================================================================
  
  _Description_:
*************** _Class_:
*** 14707,14723 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LEN_TRIM(STRING [, KIND])'
  
  _Arguments_:
!      STRING      Shall be a scalar of type 'CHARACTER', with
!                  'INTENT(IN)'
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _See also_:
--- 14707,14723 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LEN_TRIM(STRING [, KIND])’
  
  _Arguments_:
!      STRING      Shall be a scalar of type ‘CHARACTER’, with
!                  ‘INTENT(IN)’
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _See also_:
*************** _See also_:
*** 14728,14734 ****
  
  File: gfortran.info,  Node: LGE,  Next: LGT,  Prev: LEN_TRIM,  Up: Intrinsic Procedures
  
! 8.170 'LGE' -- Lexical greater than or equal
  ============================================
  
  _Description_:
--- 14728,14734 ----
  
  File: gfortran.info,  Node: LGE,  Next: LGT,  Prev: LEN_TRIM,  Up: Intrinsic Procedures
  
! 8.170 ‘LGE’ -- Lexical greater than or equal
  ============================================
  
  _Description_:
*************** _Description_:
*** 14738,14746 ****
       same length, the shorter is compared as if spaces were appended to
       it to form a value that has the same length as the longer.
  
!      In general, the lexical comparison intrinsics 'LGE', 'LGT', 'LLE',
!      and 'LLT' differ from the corresponding intrinsic operators '.GE.',
!      '.GT.', '.LE.', and '.LT.', in that the latter use the processor's
       character ordering (which is not ASCII on some targets), whereas
       the former always use the ASCII ordering.
  
--- 14738,14746 ----
       same length, the shorter is compared as if spaces were appended to
       it to form a value that has the same length as the longer.
  
!      In general, the lexical comparison intrinsics ‘LGE’, ‘LGT’, ‘LLE’,
!      and ‘LLT’ differ from the corresponding intrinsic operators ‘.GE.’,
!      ‘.GT.’, ‘.LE.’, and ‘.LT.’, in that the latter use the processor's
       character ordering (which is not ASCII on some targets), whereas
       the former always use the ASCII ordering.
  
*************** _Class_:
*** 14751,14771 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LGE(STRING_A, STRING_B)'
  
  _Arguments_:
!      STRING_A    Shall be of default 'CHARACTER' type.
!      STRING_B    Shall be of default 'CHARACTER' type.
  
  _Return value_:
!      Returns '.TRUE.' if 'STRING_A >= STRING_B', and '.FALSE.'
       otherwise, based on the ASCII ordering.
  
  _Specific names_:
       Name                     Argument     Return       Standard
                                             type
       --------------------------------------------------------------------------
!      'LGE(STRING_A,STRING_B)' 'CHARACTER'  'LOGICAL'    Fortran 77 and later
  
  _See also_:
       *note LGT::,
--- 14751,14771 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LGE(STRING_A, STRING_B)’
  
  _Arguments_:
!      STRING_A    Shall be of default ‘CHARACTER’ type.
!      STRING_B    Shall be of default ‘CHARACTER’ type.
  
  _Return value_:
!      Returns ‘.TRUE.’ if ‘STRING_A >= STRING_B’, and ‘.FALSE.’
       otherwise, based on the ASCII ordering.
  
  _Specific names_:
       Name                     Argument     Return       Standard
                                             type
       --------------------------------------------------------------------------
!      ‘LGE(STRING_A,STRING_B)’ ‘CHARACTER’  ‘LOGICAL’    Fortran 77 and later
  
  _See also_:
       *note LGT::,
*************** _See also_:
*** 14775,14781 ****
  
  File: gfortran.info,  Node: LGT,  Next: LINK,  Prev: LGE,  Up: Intrinsic Procedures
  
! 8.171 'LGT' -- Lexical greater than
  ===================================
  
  _Description_:
--- 14775,14781 ----
  
  File: gfortran.info,  Node: LGT,  Next: LINK,  Prev: LGE,  Up: Intrinsic Procedures
  
! 8.171 ‘LGT’ -- Lexical greater than
  ===================================
  
  _Description_:
*************** _Description_:
*** 14785,14793 ****
       length, the shorter is compared as if spaces were appended to it to
       form a value that has the same length as the longer.
  
!      In general, the lexical comparison intrinsics 'LGE', 'LGT', 'LLE',
!      and 'LLT' differ from the corresponding intrinsic operators '.GE.',
!      '.GT.', '.LE.', and '.LT.', in that the latter use the processor's
       character ordering (which is not ASCII on some targets), whereas
       the former always use the ASCII ordering.
  
--- 14785,14793 ----
       length, the shorter is compared as if spaces were appended to it to
       form a value that has the same length as the longer.
  
!      In general, the lexical comparison intrinsics ‘LGE’, ‘LGT’, ‘LLE’,
!      and ‘LLT’ differ from the corresponding intrinsic operators ‘.GE.’,
!      ‘.GT.’, ‘.LE.’, and ‘.LT.’, in that the latter use the processor's
       character ordering (which is not ASCII on some targets), whereas
       the former always use the ASCII ordering.
  
*************** _Class_:
*** 14798,14818 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LGT(STRING_A, STRING_B)'
  
  _Arguments_:
!      STRING_A    Shall be of default 'CHARACTER' type.
!      STRING_B    Shall be of default 'CHARACTER' type.
  
  _Return value_:
!      Returns '.TRUE.' if 'STRING_A > STRING_B', and '.FALSE.' otherwise,
       based on the ASCII ordering.
  
  _Specific names_:
       Name                     Argument     Return       Standard
                                             type
       --------------------------------------------------------------------------
!      'LGT(STRING_A,STRING_B)' 'CHARACTER'  'LOGICAL'    Fortran 77 and later
  
  _See also_:
       *note LGE::,
--- 14798,14818 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LGT(STRING_A, STRING_B)’
  
  _Arguments_:
!      STRING_A    Shall be of default ‘CHARACTER’ type.
!      STRING_B    Shall be of default ‘CHARACTER’ type.
  
  _Return value_:
!      Returns ‘.TRUE.’ if ‘STRING_A > STRING_B’, and ‘.FALSE.’ otherwise,
       based on the ASCII ordering.
  
  _Specific names_:
       Name                     Argument     Return       Standard
                                             type
       --------------------------------------------------------------------------
!      ‘LGT(STRING_A,STRING_B)’ ‘CHARACTER’  ‘LOGICAL’    Fortran 77 and later
  
  _See also_:
       *note LGE::,
*************** _See also_:
*** 14822,14836 ****
  
  File: gfortran.info,  Node: LINK,  Next: LLE,  Prev: LGT,  Up: Intrinsic Procedures
  
! 8.172 'LINK' -- Create a hard link
  ==================================
  
  _Description_:
       Makes a (hard) link from file PATH1 to PATH2.  A null character
!      ('CHAR(0)') can be used to mark the end of the names in PATH1 and
       PATH2; otherwise, trailing blanks in the file names are ignored.
       If the STATUS argument is supplied, it contains 0 on success or a
!      nonzero error code upon return; see 'link(2)'.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 14822,14836 ----
  
  File: gfortran.info,  Node: LINK,  Next: LLE,  Prev: LGT,  Up: Intrinsic Procedures
  
! 8.172 ‘LINK’ -- Create a hard link
  ==================================
  
  _Description_:
       Makes a (hard) link from file PATH1 to PATH2.  A null character
!      (‘CHAR(0)’) can be used to mark the end of the names in PATH1 and
       PATH2; otherwise, trailing blanks in the file names are ignored.
       If the STATUS argument is supplied, it contains 0 on success or a
!      nonzero error code upon return; see ‘link(2)’.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 14842,14854 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL LINK(PATH1, PATH2 [, STATUS])'
!      'STATUS = LINK(PATH1, PATH2)'
  
  _Arguments_:
!      PATH1       Shall be of default 'CHARACTER' type.
!      PATH2       Shall be of default 'CHARACTER' type.
!      STATUS      (Optional) Shall be of default 'INTEGER' type.
  
  _See also_:
       *note SYMLNK::,
--- 14842,14854 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL LINK(PATH1, PATH2 [, STATUS])’
!      ‘STATUS = LINK(PATH1, PATH2)’
  
  _Arguments_:
!      PATH1       Shall be of default ‘CHARACTER’ type.
!      PATH2       Shall be of default ‘CHARACTER’ type.
!      STATUS      (Optional) Shall be of default ‘INTEGER’ type.
  
  _See also_:
       *note SYMLNK::,
*************** _See also_:
*** 14857,14863 ****
  
  File: gfortran.info,  Node: LLE,  Next: LLT,  Prev: LINK,  Up: Intrinsic Procedures
  
! 8.173 'LLE' -- Lexical less than or equal
  =========================================
  
  _Description_:
--- 14857,14863 ----
  
  File: gfortran.info,  Node: LLE,  Next: LLT,  Prev: LINK,  Up: Intrinsic Procedures
  
! 8.173 ‘LLE’ -- Lexical less than or equal
  =========================================
  
  _Description_:
*************** _Description_:
*** 14867,14875 ****
       same length, the shorter is compared as if spaces were appended to
       it to form a value that has the same length as the longer.
  
!      In general, the lexical comparison intrinsics 'LGE', 'LGT', 'LLE',
!      and 'LLT' differ from the corresponding intrinsic operators '.GE.',
!      '.GT.', '.LE.', and '.LT.', in that the latter use the processor's
       character ordering (which is not ASCII on some targets), whereas
       the former always use the ASCII ordering.
  
--- 14867,14875 ----
       same length, the shorter is compared as if spaces were appended to
       it to form a value that has the same length as the longer.
  
!      In general, the lexical comparison intrinsics ‘LGE’, ‘LGT’, ‘LLE’,
!      and ‘LLT’ differ from the corresponding intrinsic operators ‘.GE.’,
!      ‘.GT.’, ‘.LE.’, and ‘.LT.’, in that the latter use the processor's
       character ordering (which is not ASCII on some targets), whereas
       the former always use the ASCII ordering.
  
*************** _Class_:
*** 14880,14900 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LLE(STRING_A, STRING_B)'
  
  _Arguments_:
!      STRING_A    Shall be of default 'CHARACTER' type.
!      STRING_B    Shall be of default 'CHARACTER' type.
  
  _Return value_:
!      Returns '.TRUE.' if 'STRING_A <= STRING_B', and '.FALSE.'
       otherwise, based on the ASCII ordering.
  
  _Specific names_:
       Name                     Argument     Return       Standard
                                             type
       --------------------------------------------------------------------------
!      'LLE(STRING_A,STRING_B)' 'CHARACTER'  'LOGICAL'    Fortran 77 and later
  
  _See also_:
       *note LGE::,
--- 14880,14900 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LLE(STRING_A, STRING_B)’
  
  _Arguments_:
!      STRING_A    Shall be of default ‘CHARACTER’ type.
!      STRING_B    Shall be of default ‘CHARACTER’ type.
  
  _Return value_:
!      Returns ‘.TRUE.’ if ‘STRING_A <= STRING_B’, and ‘.FALSE.’
       otherwise, based on the ASCII ordering.
  
  _Specific names_:
       Name                     Argument     Return       Standard
                                             type
       --------------------------------------------------------------------------
!      ‘LLE(STRING_A,STRING_B)’ ‘CHARACTER’  ‘LOGICAL’    Fortran 77 and later
  
  _See also_:
       *note LGE::,
*************** _See also_:
*** 14904,14910 ****
  
  File: gfortran.info,  Node: LLT,  Next: LNBLNK,  Prev: LLE,  Up: Intrinsic Procedures
  
! 8.174 'LLT' -- Lexical less than
  ================================
  
  _Description_:
--- 14904,14910 ----
  
  File: gfortran.info,  Node: LLT,  Next: LNBLNK,  Prev: LLE,  Up: Intrinsic Procedures
  
! 8.174 ‘LLT’ -- Lexical less than
  ================================
  
  _Description_:
*************** _Description_:
*** 14914,14922 ****
       length, the shorter is compared as if spaces were appended to it to
       form a value that has the same length as the longer.
  
!      In general, the lexical comparison intrinsics 'LGE', 'LGT', 'LLE',
!      and 'LLT' differ from the corresponding intrinsic operators '.GE.',
!      '.GT.', '.LE.', and '.LT.', in that the latter use the processor's
       character ordering (which is not ASCII on some targets), whereas
       the former always use the ASCII ordering.
  
--- 14914,14922 ----
       length, the shorter is compared as if spaces were appended to it to
       form a value that has the same length as the longer.
  
!      In general, the lexical comparison intrinsics ‘LGE’, ‘LGT’, ‘LLE’,
!      and ‘LLT’ differ from the corresponding intrinsic operators ‘.GE.’,
!      ‘.GT.’, ‘.LE.’, and ‘.LT.’, in that the latter use the processor's
       character ordering (which is not ASCII on some targets), whereas
       the former always use the ASCII ordering.
  
*************** _Class_:
*** 14927,14947 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LLT(STRING_A, STRING_B)'
  
  _Arguments_:
!      STRING_A    Shall be of default 'CHARACTER' type.
!      STRING_B    Shall be of default 'CHARACTER' type.
  
  _Return value_:
!      Returns '.TRUE.' if 'STRING_A < STRING_B', and '.FALSE.' otherwise,
       based on the ASCII ordering.
  
  _Specific names_:
       Name                     Argument     Return       Standard
                                             type
       --------------------------------------------------------------------------
!      'LLT(STRING_A,STRING_B)' 'CHARACTER'  'LOGICAL'    Fortran 77 and later
  
  _See also_:
       *note LGE::,
--- 14927,14947 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LLT(STRING_A, STRING_B)’
  
  _Arguments_:
!      STRING_A    Shall be of default ‘CHARACTER’ type.
!      STRING_B    Shall be of default ‘CHARACTER’ type.
  
  _Return value_:
!      Returns ‘.TRUE.’ if ‘STRING_A < STRING_B’, and ‘.FALSE.’ otherwise,
       based on the ASCII ordering.
  
  _Specific names_:
       Name                     Argument     Return       Standard
                                             type
       --------------------------------------------------------------------------
!      ‘LLT(STRING_A,STRING_B)’ ‘CHARACTER’  ‘LOGICAL’    Fortran 77 and later
  
  _See also_:
       *note LGE::,
*************** _See also_:
*** 14951,14962 ****
  
  File: gfortran.info,  Node: LNBLNK,  Next: LOC,  Prev: LLT,  Up: Intrinsic Procedures
  
! 8.175 'LNBLNK' -- Index of the last non-blank character in a string
  ===================================================================
  
  _Description_:
       Returns the length of a character string, ignoring any trailing
!      blanks.  This is identical to the standard 'LEN_TRIM' intrinsic,
       and is only included for backwards compatibility.
  
  _Standard_:
--- 14951,14962 ----
  
  File: gfortran.info,  Node: LNBLNK,  Next: LOC,  Prev: LLT,  Up: Intrinsic Procedures
  
! 8.175 ‘LNBLNK’ -- Index of the last non-blank character in a string
  ===================================================================
  
  _Description_:
       Returns the length of a character string, ignoring any trailing
!      blanks.  This is identical to the standard ‘LEN_TRIM’ intrinsic,
       and is only included for backwards compatibility.
  
  _Standard_:
*************** _Class_:
*** 14966,14979 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LNBLNK(STRING)'
  
  _Arguments_:
!      STRING      Shall be a scalar of type 'CHARACTER', with
!                  'INTENT(IN)'
  
  _Return value_:
!      The return value is of 'INTEGER(kind=4)' type.
  
  _See also_:
       *note INDEX intrinsic::,
--- 14966,14979 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LNBLNK(STRING)’
  
  _Arguments_:
!      STRING      Shall be a scalar of type ‘CHARACTER’, with
!                  ‘INTENT(IN)’
  
  _Return value_:
!      The return value is of ‘INTEGER(kind=4)’ type.
  
  _See also_:
       *note INDEX intrinsic::,
*************** _See also_:
*** 14982,14992 ****
  
  File: gfortran.info,  Node: LOC,  Next: LOG,  Prev: LNBLNK,  Up: Intrinsic Procedures
  
! 8.176 'LOC' -- Returns the address of a variable
  ================================================
  
  _Description_:
!      'LOC(X)' returns the address of X as an integer.
  
  _Standard_:
       GNU extension
--- 14982,14992 ----
  
  File: gfortran.info,  Node: LOC,  Next: LOG,  Prev: LNBLNK,  Up: Intrinsic Procedures
  
! 8.176 ‘LOC’ -- Returns the address of a variable
  ================================================
  
  _Description_:
!      ‘LOC(X)’ returns the address of X as an integer.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 14995,15007 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = LOC(X)'
  
  _Arguments_:
       X           Variable of any type.
  
  _Return value_:
!      The return value is of type 'INTEGER', with a 'KIND' corresponding
       to the size (in bytes) of a memory address on the target machine.
  
  _Example_:
--- 14995,15007 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = LOC(X)’
  
  _Arguments_:
       X           Variable of any type.
  
  _Return value_:
!      The return value is of type ‘INTEGER’, with a ‘KIND’ corresponding
       to the size (in bytes) of a memory address on the target machine.
  
  _Example_:
*************** _Example_:
*** 15015,15025 ****
  
  File: gfortran.info,  Node: LOG,  Next: LOG10,  Prev: LOC,  Up: Intrinsic Procedures
  
! 8.177 'LOG' -- Natural logarithm function
  =========================================
  
  _Description_:
!      'LOG(X)' computes the natural logarithm of X, i.e.  the logarithm
       to the base e.
  
  _Standard_:
--- 15015,15025 ----
  
  File: gfortran.info,  Node: LOG,  Next: LOG10,  Prev: LOC,  Up: Intrinsic Procedures
  
! 8.177 ‘LOG’ -- Natural logarithm function
  =========================================
  
  _Description_:
!      ‘LOG(X)’ computes the natural logarithm of X, i.e.  the logarithm
       to the base e.
  
  _Standard_:
*************** _Class_:
*** 15029,15042 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LOG(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
!      The return value is of type 'REAL' or 'COMPLEX'.  The kind type
!      parameter is the same as X.  If X is 'COMPLEX', the imaginary part
       \omega is in the range -\pi < \omega \leq \pi.
  
  _Example_:
--- 15029,15042 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LOG(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
!      The return value is of type ‘REAL’ or ‘COMPLEX’.  The kind type
!      parameter is the same as X.  If X is ‘COMPLEX’, the imaginary part
       \omega is in the range -\pi < \omega \leq \pi.
  
  _Example_:
*************** _Example_:
*** 15050,15069 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ALOG(X)'      'REAL(4) X'       'REAL(4)'      Fortran 77 or later
!      'DLOG(X)'      'REAL(8) X'       'REAL(8)'      Fortran 77 or later
!      'CLOG(X)'      'COMPLEX(4) X'    'COMPLEX(4)'   Fortran 77 or later
!      'ZLOG(X)'      'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
!      'CDLOG(X)'     'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
  
  
  File: gfortran.info,  Node: LOG10,  Next: LOG_GAMMA,  Prev: LOG,  Up: Intrinsic Procedures
  
! 8.178 'LOG10' -- Base 10 logarithm function
  ===========================================
  
  _Description_:
!      'LOG10(X)' computes the base 10 logarithm of X.
  
  _Standard_:
       Fortran 77 and later
--- 15050,15069 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ALOG(X)’      ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 or later
!      ‘DLOG(X)’      ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 or later
!      ‘CLOG(X)’      ‘COMPLEX(4) X’    ‘COMPLEX(4)’   Fortran 77 or later
!      ‘ZLOG(X)’      ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
!      ‘CDLOG(X)’     ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
  
  
  File: gfortran.info,  Node: LOG10,  Next: LOG_GAMMA,  Prev: LOG,  Up: Intrinsic Procedures
  
! 8.178 ‘LOG10’ -- Base 10 logarithm function
  ===========================================
  
  _Description_:
!      ‘LOG10(X)’ computes the base 10 logarithm of X.
  
  _Standard_:
       Fortran 77 and later
*************** _Class_:
*** 15072,15084 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LOG10(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL'.
  
  _Return value_:
!      The return value is of type 'REAL' or 'COMPLEX'.  The kind type
       parameter is the same as X.
  
  _Example_:
--- 15072,15084 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LOG10(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘REAL’ or ‘COMPLEX’.  The kind type
       parameter is the same as X.
  
  _Example_:
*************** _Example_:
*** 15090,15106 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'ALOG10(X)'    'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DLOG10(X)'    'REAL(8) X'       'REAL(8)'      Fortran 77 and later
  
  
  File: gfortran.info,  Node: LOG_GAMMA,  Next: LOGICAL,  Prev: LOG10,  Up: Intrinsic Procedures
  
! 8.179 'LOG_GAMMA' -- Logarithm of the Gamma function
  ====================================================
  
  _Description_:
!      'LOG_GAMMA(X)' computes the natural logarithm of the absolute value
       of the Gamma (\Gamma) function.
  
  _Standard_:
--- 15090,15106 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘ALOG10(X)’    ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DLOG10(X)’    ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
  
  
  File: gfortran.info,  Node: LOG_GAMMA,  Next: LOGICAL,  Prev: LOG10,  Up: Intrinsic Procedures
  
! 8.179 ‘LOG_GAMMA’ -- Logarithm of the Gamma function
  ====================================================
  
  _Description_:
!      ‘LOG_GAMMA(X)’ computes the natural logarithm of the absolute value
       of the Gamma (\Gamma) function.
  
  _Standard_:
*************** _Class_:
*** 15110,15123 ****
       Elemental function
  
  _Syntax_:
!      'X = LOG_GAMMA(X)'
  
  _Arguments_:
!      X           Shall be of type 'REAL' and neither zero nor a
                   negative integer.
  
  _Return value_:
!      The return value is of type 'REAL' of the same kind as X.
  
  _Example_:
            program test_log_gamma
--- 15110,15123 ----
       Elemental function
  
  _Syntax_:
!      ‘X = LOG_GAMMA(X)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’ and neither zero nor a
                   negative integer.
  
  _Return value_:
!      The return value is of type ‘REAL’ of the same kind as X.
  
  _Example_:
            program test_log_gamma
*************** _Example_:
*** 15128,15136 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'LGAMMA(X)'    'REAL(4) X'       'REAL(4)'      GNU extension
!      'ALGAMA(X)'    'REAL(4) X'       'REAL(4)'      GNU extension
!      'DLGAMA(X)'    'REAL(8) X'       'REAL(8)'      GNU extension
  
  _See also_:
       Gamma function:
--- 15128,15136 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘LGAMMA(X)’    ‘REAL(4) X’       ‘REAL(4)’      GNU extension
!      ‘ALGAMA(X)’    ‘REAL(4) X’       ‘REAL(4)’      GNU extension
!      ‘DLGAMA(X)’    ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  _See also_:
       Gamma function:
*************** _See also_:
*** 15139,15149 ****
  
  File: gfortran.info,  Node: LOGICAL,  Next: LSHIFT,  Prev: LOG_GAMMA,  Up: Intrinsic Procedures
  
! 8.180 'LOGICAL' -- Convert to logical type
  ==========================================
  
  _Description_:
!      Converts one kind of 'LOGICAL' variable to another.
  
  _Standard_:
       Fortran 90 and later
--- 15139,15149 ----
  
  File: gfortran.info,  Node: LOGICAL,  Next: LSHIFT,  Prev: LOG_GAMMA,  Up: Intrinsic Procedures
  
! 8.180 ‘LOGICAL’ -- Convert to logical type
  ==========================================
  
  _Description_:
!      Converts one kind of ‘LOGICAL’ variable to another.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 15152,15167 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LOGICAL(L [, KIND])'
  
  _Arguments_:
!      L           The type shall be 'LOGICAL'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is a 'LOGICAL' value equal to L, with a kind
       corresponding to KIND, or of the default logical kind if KIND is
       not given.
  
--- 15152,15167 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LOGICAL(L [, KIND])’
  
  _Arguments_:
!      L           The type shall be ‘LOGICAL’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is a ‘LOGICAL’ value equal to L, with a kind
       corresponding to KIND, or of the default logical kind if KIND is
       not given.
  
*************** _See also_:
*** 15173,15190 ****
  
  File: gfortran.info,  Node: LSHIFT,  Next: LSTAT,  Prev: LOGICAL,  Up: Intrinsic Procedures
  
! 8.181 'LSHIFT' -- Left shift bits
  =================================
  
  _Description_:
!      'LSHIFT' returns a value corresponding to I with all of the bits
       shifted left by SHIFT places.  SHIFT shall be nonnegative and less
!      than or equal to 'BIT_SIZE(I)', otherwise the result value is
       undefined.  Bits shifted out from the left end are lost; zeros are
       shifted in from the opposite end.
  
!      This function has been superseded by the 'ISHFT' intrinsic, which
!      is standard in Fortran 95 and later, and the 'SHIFTL' intrinsic,
       which is standard in Fortran 2008 and later.
  
  _Standard_:
--- 15173,15190 ----
  
  File: gfortran.info,  Node: LSHIFT,  Next: LSTAT,  Prev: LOGICAL,  Up: Intrinsic Procedures
  
! 8.181 ‘LSHIFT’ -- Left shift bits
  =================================
  
  _Description_:
!      ‘LSHIFT’ returns a value corresponding to I with all of the bits
       shifted left by SHIFT places.  SHIFT shall be nonnegative and less
!      than or equal to ‘BIT_SIZE(I)’, otherwise the result value is
       undefined.  Bits shifted out from the left end are lost; zeros are
       shifted in from the opposite end.
  
!      This function has been superseded by the ‘ISHFT’ intrinsic, which
!      is standard in Fortran 95 and later, and the ‘SHIFTL’ intrinsic,
       which is standard in Fortran 2008 and later.
  
  _Standard_:
*************** _Class_:
*** 15194,15207 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = LSHIFT(I, SHIFT)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      SHIFT       The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the same kind as I.
  
  _See also_:
       *note ISHFT::,
--- 15194,15207 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = LSHIFT(I, SHIFT)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      SHIFT       The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the same kind as I.
  
  _See also_:
       *note ISHFT::,
*************** _See also_:
*** 15214,15228 ****
  
  File: gfortran.info,  Node: LSTAT,  Next: LTIME,  Prev: LSHIFT,  Up: Intrinsic Procedures
  
! 8.182 'LSTAT' -- Get file status
  ================================
  
  _Description_:
!      'LSTAT' is identical to *note STAT::, except that if path is a
       symbolic link, then the link itself is statted, not the file that
       it refers to.
  
!      The elements in 'VALUES' are the same as described by *note STAT::.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 15214,15228 ----
  
  File: gfortran.info,  Node: LSTAT,  Next: LTIME,  Prev: LSHIFT,  Up: Intrinsic Procedures
  
! 8.182 ‘LSTAT’ -- Get file status
  ================================
  
  _Description_:
!      ‘LSTAT’ is identical to *note STAT::, except that if path is a
       symbolic link, then the link itself is statted, not the file that
       it refers to.
  
!      The elements in ‘VALUES’ are the same as described by *note STAT::.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 15234,15247 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL LSTAT(NAME, VALUES [, STATUS])'
!      'STATUS = LSTAT(NAME, VALUES)'
  
  _Arguments_:
!      NAME        The type shall be 'CHARACTER' of the default
                   kind, a valid path within the file system.
!      VALUES      The type shall be 'INTEGER(4), DIMENSION(13)'.
!      STATUS      (Optional) status flag of type 'INTEGER(4)'.
                   Returns 0 on success and a system specific error
                   code otherwise.
  
--- 15234,15247 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL LSTAT(NAME, VALUES [, STATUS])’
!      ‘STATUS = LSTAT(NAME, VALUES)’
  
  _Arguments_:
!      NAME        The type shall be ‘CHARACTER’ of the default
                   kind, a valid path within the file system.
!      VALUES      The type shall be ‘INTEGER(4), DIMENSION(13)’.
!      STATUS      (Optional) status flag of type ‘INTEGER(4)’.
                   Returns 0 on success and a system specific error
                   code otherwise.
  
*************** _See also_:
*** 15257,15269 ****
  
  File: gfortran.info,  Node: LTIME,  Next: MALLOC,  Prev: LSTAT,  Up: Intrinsic Procedures
  
! 8.183 'LTIME' -- Convert time to local time info
  ================================================
  
  _Description_:
       Given a system time value TIME (as provided by the *note TIME::
       intrinsic), fills VALUES with values extracted from it appropriate
!      to the local time zone using 'localtime(3)'.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  In new code, programmers should consider the use
--- 15257,15269 ----
  
  File: gfortran.info,  Node: LTIME,  Next: MALLOC,  Prev: LSTAT,  Up: Intrinsic Procedures
  
! 8.183 ‘LTIME’ -- Convert time to local time info
  ================================================
  
  _Description_:
       Given a system time value TIME (as provided by the *note TIME::
       intrinsic), fills VALUES with values extracted from it appropriate
!      to the local time zone using ‘localtime(3)’.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  In new code, programmers should consider the use
*************** _Class_:
*** 15277,15289 ****
       Subroutine
  
  _Syntax_:
!      'CALL LTIME(TIME, VALUES)'
  
  _Arguments_:
!      TIME        An 'INTEGER' scalar expression corresponding to
!                  a system time, with 'INTENT(IN)'.
!      VALUES      A default 'INTEGER' array with 9 elements, with
!                  'INTENT(OUT)'.
  
  _Return value_:
       The elements of VALUES are assigned as follows:
--- 15277,15289 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL LTIME(TIME, VALUES)’
  
  _Arguments_:
!      TIME        An ‘INTEGER’ scalar expression corresponding to
!                  a system time, with ‘INTENT(IN)’.
!      VALUES      A default ‘INTEGER’ array with 9 elements, with
!                  ‘INTENT(OUT)’.
  
  _Return value_:
       The elements of VALUES are assigned as follows:
*************** _See also_:
*** 15310,15325 ****
  
  File: gfortran.info,  Node: MALLOC,  Next: MASKL,  Prev: LTIME,  Up: Intrinsic Procedures
  
! 8.184 'MALLOC' -- Allocate dynamic memory
  =========================================
  
  _Description_:
!      'MALLOC(SIZE)' allocates SIZE bytes of dynamic memory and returns
!      the address of the allocated memory.  The 'MALLOC' intrinsic is an
       extension intended to be used with Cray pointers, and is provided
       in GNU Fortran to allow the user to compile legacy code.  For new
       code using Fortran 95 pointers, the memory allocation intrinsic is
!      'ALLOCATE'.
  
  _Standard_:
       GNU extension
--- 15310,15325 ----
  
  File: gfortran.info,  Node: MALLOC,  Next: MASKL,  Prev: LTIME,  Up: Intrinsic Procedures
  
! 8.184 ‘MALLOC’ -- Allocate dynamic memory
  =========================================
  
  _Description_:
!      ‘MALLOC(SIZE)’ allocates SIZE bytes of dynamic memory and returns
!      the address of the allocated memory.  The ‘MALLOC’ intrinsic is an
       extension intended to be used with Cray pointers, and is provided
       in GNU Fortran to allow the user to compile legacy code.  For new
       code using Fortran 95 pointers, the memory allocation intrinsic is
!      ‘ALLOCATE’.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 15328,15345 ****
       Function
  
  _Syntax_:
!      'PTR = MALLOC(SIZE)'
  
  _Arguments_:
!      SIZE        The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER(K)', with K such that
!      variables of type 'INTEGER(K)' have the same size as C pointers
!      ('sizeof(void *)').
  
  _Example_:
!      The following example demonstrates the use of 'MALLOC' and 'FREE'
       with Cray pointers.
  
            program test_malloc
--- 15328,15345 ----
       Function
  
  _Syntax_:
!      ‘PTR = MALLOC(SIZE)’
  
  _Arguments_:
!      SIZE        The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER(K)’, with K such that
!      variables of type ‘INTEGER(K)’ have the same size as C pointers
!      (‘sizeof(void *)’).
  
  _Example_:
!      The following example demonstrates the use of ‘MALLOC’ and ‘FREE’
       with Cray pointers.
  
            program test_malloc
*************** _See also_:
*** 15366,15376 ****
  
  File: gfortran.info,  Node: MASKL,  Next: MASKR,  Prev: MALLOC,  Up: Intrinsic Procedures
  
! 8.185 'MASKL' -- Left justified mask
  ====================================
  
  _Description_:
!      'MASKL(I[, KIND])' has its leftmost I bits set to 1, and the
       remaining bits set to 0.
  
  _Standard_:
--- 15366,15376 ----
  
  File: gfortran.info,  Node: MASKL,  Next: MASKR,  Prev: MALLOC,  Up: Intrinsic Procedures
  
! 8.185 ‘MASKL’ -- Left justified mask
  ====================================
  
  _Description_:
!      ‘MASKL(I[, KIND])’ has its leftmost I bits set to 1, and the
       remaining bits set to 0.
  
  _Standard_:
*************** _Class_:
*** 15380,15394 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = MASKL(I[, KIND])'
  
  _Arguments_:
!      I           Shall be of type 'INTEGER'.
       KIND        Shall be a scalar constant expression of type
!                  'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER'.  If KIND is present, it
       specifies the kind value of the return type; otherwise, it is of
       the default integer kind.
  
--- 15380,15394 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = MASKL(I[, KIND])’
  
  _Arguments_:
!      I           Shall be of type ‘INTEGER’.
       KIND        Shall be a scalar constant expression of type
!                  ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’.  If KIND is present, it
       specifies the kind value of the return type; otherwise, it is of
       the default integer kind.
  
*************** _See also_:
*** 15398,15408 ****
  
  File: gfortran.info,  Node: MASKR,  Next: MATMUL,  Prev: MASKL,  Up: Intrinsic Procedures
  
! 8.186 'MASKR' -- Right justified mask
  =====================================
  
  _Description_:
!      'MASKL(I[, KIND])' has its rightmost I bits set to 1, and the
       remaining bits set to 0.
  
  _Standard_:
--- 15398,15408 ----
  
  File: gfortran.info,  Node: MASKR,  Next: MATMUL,  Prev: MASKL,  Up: Intrinsic Procedures
  
! 8.186 ‘MASKR’ -- Right justified mask
  =====================================
  
  _Description_:
!      ‘MASKL(I[, KIND])’ has its rightmost I bits set to 1, and the
       remaining bits set to 0.
  
  _Standard_:
*************** _Class_:
*** 15412,15426 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = MASKR(I[, KIND])'
  
  _Arguments_:
!      I           Shall be of type 'INTEGER'.
       KIND        Shall be a scalar constant expression of type
!                  'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER'.  If KIND is present, it
       specifies the kind value of the return type; otherwise, it is of
       the default integer kind.
  
--- 15412,15426 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = MASKR(I[, KIND])’
  
  _Arguments_:
!      I           Shall be of type ‘INTEGER’.
       KIND        Shall be a scalar constant expression of type
!                  ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’.  If KIND is present, it
       specifies the kind value of the return type; otherwise, it is of
       the default integer kind.
  
*************** _See also_:
*** 15430,15436 ****
  
  File: gfortran.info,  Node: MATMUL,  Next: MAX,  Prev: MASKR,  Up: Intrinsic Procedures
  
! 8.187 'MATMUL' -- matrix multiplication
  =======================================
  
  _Description_:
--- 15430,15436 ----
  
  File: gfortran.info,  Node: MATMUL,  Next: MAX,  Prev: MASKR,  Up: Intrinsic Procedures
  
! 8.187 ‘MATMUL’ -- matrix multiplication
  =======================================
  
  _Description_:
*************** _Class_:
*** 15443,15456 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = MATMUL(MATRIX_A, MATRIX_B)'
  
  _Arguments_:
!      MATRIX_A    An array of 'INTEGER', 'REAL', 'COMPLEX', or
!                  'LOGICAL' type, with a rank of one or two.
!      MATRIX_B    An array of 'INTEGER', 'REAL', or 'COMPLEX' type
                   if MATRIX_A is of a numeric type; otherwise, an
!                  array of 'LOGICAL' type.  The rank shall be one
                   or two, and the first (or only) dimension of
                   MATRIX_B shall be equal to the last (or only)
                   dimension of MATRIX_A.  MATRIX_A and MATRIX_B
--- 15443,15456 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = MATMUL(MATRIX_A, MATRIX_B)’
  
  _Arguments_:
!      MATRIX_A    An array of ‘INTEGER’, ‘REAL’, ‘COMPLEX’, or
!                  ‘LOGICAL’ type, with a rank of one or two.
!      MATRIX_B    An array of ‘INTEGER’, ‘REAL’, or ‘COMPLEX’ type
                   if MATRIX_A is of a numeric type; otherwise, an
!                  array of ‘LOGICAL’ type.  The rank shall be one
                   or two, and the first (or only) dimension of
                   MATRIX_B shall be equal to the last (or only)
                   dimension of MATRIX_A.  MATRIX_A and MATRIX_B
*************** _Arguments_:
*** 15459,15470 ****
  _Return value_:
       The matrix product of MATRIX_A and MATRIX_B.  The type and kind of
       the result follow the usual type and kind promotion rules, as for
!      the '*' or '.AND.' operators.
  
  
  File: gfortran.info,  Node: MAX,  Next: MAXEXPONENT,  Prev: MATMUL,  Up: Intrinsic Procedures
  
! 8.188 'MAX' -- Maximum value of an argument list
  ================================================
  
  _Description_:
--- 15459,15470 ----
  _Return value_:
       The matrix product of MATRIX_A and MATRIX_B.  The type and kind of
       the result follow the usual type and kind promotion rules, as for
!      the ‘*’ or ‘.AND.’ operators.
  
  
  File: gfortran.info,  Node: MAX,  Next: MAXEXPONENT,  Prev: MATMUL,  Up: Intrinsic Procedures
  
! 8.188 ‘MAX’ -- Maximum value of an argument list
  ================================================
  
  _Description_:
*************** _Class_:
*** 15477,15486 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = MAX(A1, A2 [, A3 [, ...]])'
  
  _Arguments_:
!      A1          The type shall be 'INTEGER' or 'REAL'.
       A2, A3,     An expression of the same type and kind as A1.
       ...         (As a GNU extension, arguments of different
                   kinds are permitted.)
--- 15477,15486 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = MAX(A1, A2 [, A3 [, ...]])’
  
  _Arguments_:
!      A1          The type shall be ‘INTEGER’ or ‘REAL’.
       A2, A3,     An expression of the same type and kind as A1.
       ...         (As a GNU extension, arguments of different
                   kinds are permitted.)
*************** _Return value_:
*** 15492,15502 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'MAX0(A1)'     'INTEGER(4) A1'   'INTEGER(4)'   Fortran 77 and later
!      'AMAX0(A1)'    'INTEGER(4) A1'   'REAL(MAX(X))' Fortran 77 and later
!      'MAX1(A1)'     'REAL A1'         'INT(MAX(X))'  Fortran 77 and later
!      'AMAX1(A1)'    'REAL(4) A1'      'REAL(4)'      Fortran 77 and later
!      'DMAX1(A1)'    'REAL(8) A1'      'REAL(8)'      Fortran 77 and later
  
  _See also_:
       *note MAXLOC::
--- 15492,15502 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘MAX0(A1)’     ‘INTEGER(4) A1’   ‘INTEGER(4)’   Fortran 77 and later
!      ‘AMAX0(A1)’    ‘INTEGER(4) A1’   ‘REAL(MAX(X))’ Fortran 77 and later
!      ‘MAX1(A1)’     ‘REAL A1’         ‘INT(MAX(X))’  Fortran 77 and later
!      ‘AMAX1(A1)’    ‘REAL(4) A1’      ‘REAL(4)’      Fortran 77 and later
!      ‘DMAX1(A1)’    ‘REAL(8) A1’      ‘REAL(8)’      Fortran 77 and later
  
  _See also_:
       *note MAXLOC::
*************** _See also_:
*** 15506,15517 ****
  
  File: gfortran.info,  Node: MAXEXPONENT,  Next: MAXLOC,  Prev: MAX,  Up: Intrinsic Procedures
  
! 8.189 'MAXEXPONENT' -- Maximum exponent of a real kind
  ======================================================
  
  _Description_:
!      'MAXEXPONENT(X)' returns the maximum exponent in the model of the
!      type of 'X'.
  
  _Standard_:
       Fortran 90 and later
--- 15506,15517 ----
  
  File: gfortran.info,  Node: MAXEXPONENT,  Next: MAXLOC,  Prev: MAX,  Up: Intrinsic Procedures
  
! 8.189 ‘MAXEXPONENT’ -- Maximum exponent of a real kind
  ======================================================
  
  _Description_:
!      ‘MAXEXPONENT(X)’ returns the maximum exponent in the model of the
!      type of ‘X’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 15520,15532 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = MAXEXPONENT(X)'
  
  _Arguments_:
!      X           Shall be of type 'REAL'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the default integer
       kind.
  
  _Example_:
--- 15520,15532 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = MAXEXPONENT(X)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the default integer
       kind.
  
  _Example_:
*************** _Example_:
*** 15541,15547 ****
  
  File: gfortran.info,  Node: MAXLOC,  Next: MAXVAL,  Prev: MAXEXPONENT,  Up: Intrinsic Procedures
  
! 8.190 'MAXLOC' -- Location of the maximum value within an array
  ===============================================================
  
  _Description_:
--- 15541,15547 ----
  
  File: gfortran.info,  Node: MAXLOC,  Next: MAXVAL,  Prev: MAXEXPONENT,  Up: Intrinsic Procedures
  
! 8.190 ‘MAXLOC’ -- Location of the maximum value within an array
  ===============================================================
  
  _Description_:
*************** _Description_:
*** 15549,15566 ****
       maximum value, or, if the DIM argument is supplied, determines the
       locations of the maximum element along each row of the array in the
       DIM direction.  If MASK is present, only the elements for which
!      MASK is '.TRUE.' are considered.  If more than one element in the
       array has the maximum value, the location returned is that of the
       first such element in array element order if the BACK is not
       present, or is false; if BACK is true, the location returned is
       that of the last such element.  If the array has zero size, or all
!      of the elements of MASK are '.FALSE.', then the result is an array
       of zeroes.  Similarly, if DIM is supplied and all of the elements
       of MASK along a given row are zero, the result value for that row
       is zero.
  
  _Standard_:
!      Fortran 95 and later; ARRAY of 'CHARACTER' and the KIND argument
       are available in Fortran 2003 and later.  The BACK argument is
       available in Fortran 2008 and later.
  
--- 15549,15566 ----
       maximum value, or, if the DIM argument is supplied, determines the
       locations of the maximum element along each row of the array in the
       DIM direction.  If MASK is present, only the elements for which
!      MASK is ‘.TRUE.’ are considered.  If more than one element in the
       array has the maximum value, the location returned is that of the
       first such element in array element order if the BACK is not
       present, or is false; if BACK is true, the location returned is
       that of the last such element.  If the array has zero size, or all
!      of the elements of MASK are ‘.FALSE.’, then the result is an array
       of zeroes.  Similarly, if DIM is supplied and all of the elements
       of MASK along a given row are zero, the result value for that row
       is zero.
  
  _Standard_:
!      Fortran 95 and later; ARRAY of ‘CHARACTER’ and the KIND argument
       are available in Fortran 2003 and later.  The BACK argument is
       available in Fortran 2008 and later.
  
*************** _Class_:
*** 15568,15588 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = MAXLOC(ARRAY, DIM [, MASK] [,KIND] [,BACK])'
!      'RESULT = MAXLOC(ARRAY [, MASK] [,KIND] [,BACK])'
  
  _Arguments_:
!      ARRAY       Shall be an array of type 'INTEGER' or 'REAL'.
!      DIM         (Optional) Shall be a scalar of type 'INTEGER',
                   with a value between one and the rank of ARRAY,
                   inclusive.  It may not be an optional dummy
                   argument.
!      MASK        Shall be of type 'LOGICAL', and conformable with
                   ARRAY.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
!      BACK        (Optional) A scalar of type 'LOGICAL'.
  
  _Return value_:
       If DIM is absent, the result is a rank-one array with a length
--- 15568,15588 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = MAXLOC(ARRAY, DIM [, MASK] [,KIND] [,BACK])’
!      ‘RESULT = MAXLOC(ARRAY [, MASK] [,KIND] [,BACK])’
  
  _Arguments_:
!      ARRAY       Shall be an array of type ‘INTEGER’ or ‘REAL’.
!      DIM         (Optional) Shall be a scalar of type ‘INTEGER’,
                   with a value between one and the rank of ARRAY,
                   inclusive.  It may not be an optional dummy
                   argument.
!      MASK        Shall be of type ‘LOGICAL’, and conformable with
                   ARRAY.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
!      BACK        (Optional) A scalar of type ‘LOGICAL’.
  
  _Return value_:
       If DIM is absent, the result is a rank-one array with a length
*************** _See also_:
*** 15601,15616 ****
  
  File: gfortran.info,  Node: MAXVAL,  Next: MCLOCK,  Prev: MAXLOC,  Up: Intrinsic Procedures
  
! 8.191 'MAXVAL' -- Maximum value of an array
  ===========================================
  
  _Description_:
       Determines the maximum value of the elements in an array value, or,
       if the DIM argument is supplied, determines the maximum value along
       each row of the array in the DIM direction.  If MASK is present,
!      only the elements for which MASK is '.TRUE.' are considered.  If
       the array has zero size, or all of the elements of MASK are
!      '.FALSE.', then the result is '-HUGE(ARRAY)' if ARRAY is numeric,
       or a string of nulls if ARRAY is of character type.
  
  _Standard_:
--- 15601,15616 ----
  
  File: gfortran.info,  Node: MAXVAL,  Next: MCLOCK,  Prev: MAXLOC,  Up: Intrinsic Procedures
  
! 8.191 ‘MAXVAL’ -- Maximum value of an array
  ===========================================
  
  _Description_:
       Determines the maximum value of the elements in an array value, or,
       if the DIM argument is supplied, determines the maximum value along
       each row of the array in the DIM direction.  If MASK is present,
!      only the elements for which MASK is ‘.TRUE.’ are considered.  If
       the array has zero size, or all of the elements of MASK are
!      ‘.FALSE.’, then the result is ‘-HUGE(ARRAY)’ if ARRAY is numeric,
       or a string of nulls if ARRAY is of character type.
  
  _Standard_:
*************** _Class_:
*** 15620,15635 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = MAXVAL(ARRAY, DIM [, MASK])'
!      'RESULT = MAXVAL(ARRAY [, MASK])'
  
  _Arguments_:
!      ARRAY       Shall be an array of type 'INTEGER' or 'REAL'.
!      DIM         (Optional) Shall be a scalar of type 'INTEGER',
                   with a value between one and the rank of ARRAY,
                   inclusive.  It may not be an optional dummy
                   argument.
!      MASK        (Optional) Shall be of type 'LOGICAL', and
                   conformable with ARRAY.
  
  _Return value_:
--- 15620,15635 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = MAXVAL(ARRAY, DIM [, MASK])’
!      ‘RESULT = MAXVAL(ARRAY [, MASK])’
  
  _Arguments_:
!      ARRAY       Shall be an array of type ‘INTEGER’ or ‘REAL’.
!      DIM         (Optional) Shall be a scalar of type ‘INTEGER’,
                   with a value between one and the rank of ARRAY,
                   inclusive.  It may not be an optional dummy
                   argument.
!      MASK        (Optional) Shall be of type ‘LOGICAL’, and
                   conformable with ARRAY.
  
  _Return value_:
*************** _See also_:
*** 15646,15660 ****
  
  File: gfortran.info,  Node: MCLOCK,  Next: MCLOCK8,  Prev: MAXVAL,  Up: Intrinsic Procedures
  
! 8.192 'MCLOCK' -- Time function
  ===============================
  
  _Description_:
       Returns the number of clock ticks since the start of the process,
!      based on the function 'clock(3)' in the C standard library.
  
       This intrinsic is not fully portable, such as to systems with
!      32-bit 'INTEGER' types but supporting times wider than 32 bits.
       Therefore, the values returned by this intrinsic might be, or
       become, negative, or numerically less than previous values, during
       a single run of the compiled program.
--- 15646,15660 ----
  
  File: gfortran.info,  Node: MCLOCK,  Next: MCLOCK8,  Prev: MAXVAL,  Up: Intrinsic Procedures
  
! 8.192 ‘MCLOCK’ -- Time function
  ===============================
  
  _Description_:
       Returns the number of clock ticks since the start of the process,
!      based on the function ‘clock(3)’ in the C standard library.
  
       This intrinsic is not fully portable, such as to systems with
!      32-bit ‘INTEGER’ types but supporting times wider than 32 bits.
       Therefore, the values returned by this intrinsic might be, or
       become, negative, or numerically less than previous values, during
       a single run of the compiled program.
*************** _Class_:
*** 15666,15677 ****
       Function
  
  _Syntax_:
!      'RESULT = MCLOCK()'
  
  _Return value_:
!      The return value is a scalar of type 'INTEGER(4)', equal to the
!      number of clock ticks since the start of the process, or '-1' if
!      the system does not support 'clock(3)'.
  
  _See also_:
       *note CTIME::,
--- 15666,15677 ----
       Function
  
  _Syntax_:
!      ‘RESULT = MCLOCK()’
  
  _Return value_:
!      The return value is a scalar of type ‘INTEGER(4)’, equal to the
!      number of clock ticks since the start of the process, or ‘-1’ if
!      the system does not support ‘clock(3)’.
  
  _See also_:
       *note CTIME::,
*************** _See also_:
*** 15683,15699 ****
  
  File: gfortran.info,  Node: MCLOCK8,  Next: MERGE,  Prev: MCLOCK,  Up: Intrinsic Procedures
  
! 8.193 'MCLOCK8' -- Time function (64-bit)
  =========================================
  
  _Description_:
       Returns the number of clock ticks since the start of the process,
!      based on the function 'clock(3)' in the C standard library.
  
       _Warning:_ this intrinsic does not increase the range of the timing
!      values over that returned by 'clock(3)'.  On a system with a 32-bit
!      'clock(3)', 'MCLOCK8' will return a 32-bit value, even though it is
!      converted to a 64-bit 'INTEGER(8)' value.  That means overflows of
       the 32-bit value can still occur.  Therefore, the values returned
       by this intrinsic might be or become negative or numerically less
       than previous values during a single run of the compiled program.
--- 15683,15699 ----
  
  File: gfortran.info,  Node: MCLOCK8,  Next: MERGE,  Prev: MCLOCK,  Up: Intrinsic Procedures
  
! 8.193 ‘MCLOCK8’ -- Time function (64-bit)
  =========================================
  
  _Description_:
       Returns the number of clock ticks since the start of the process,
!      based on the function ‘clock(3)’ in the C standard library.
  
       _Warning:_ this intrinsic does not increase the range of the timing
!      values over that returned by ‘clock(3)’.  On a system with a 32-bit
!      ‘clock(3)’, ‘MCLOCK8’ will return a 32-bit value, even though it is
!      converted to a 64-bit ‘INTEGER(8)’ value.  That means overflows of
       the 32-bit value can still occur.  Therefore, the values returned
       by this intrinsic might be or become negative or numerically less
       than previous values during a single run of the compiled program.
*************** _Class_:
*** 15705,15716 ****
       Function
  
  _Syntax_:
!      'RESULT = MCLOCK8()'
  
  _Return value_:
!      The return value is a scalar of type 'INTEGER(8)', equal to the
!      number of clock ticks since the start of the process, or '-1' if
!      the system does not support 'clock(3)'.
  
  _See also_:
       *note CTIME::,
--- 15705,15716 ----
       Function
  
  _Syntax_:
!      ‘RESULT = MCLOCK8()’
  
  _Return value_:
!      The return value is a scalar of type ‘INTEGER(8)’, equal to the
!      number of clock ticks since the start of the process, or ‘-1’ if
!      the system does not support ‘clock(3)’.
  
  _See also_:
       *note CTIME::,
*************** _See also_:
*** 15722,15734 ****
  
  File: gfortran.info,  Node: MERGE,  Next: MERGE_BITS,  Prev: MCLOCK8,  Up: Intrinsic Procedures
  
! 8.194 'MERGE' -- Merge variables
  ================================
  
  _Description_:
       Select values from two arrays according to a logical mask.  The
!      result is equal to TSOURCE if MASK is '.TRUE.', or equal to FSOURCE
!      if it is '.FALSE.'.
  
  _Standard_:
       Fortran 90 and later
--- 15722,15734 ----
  
  File: gfortran.info,  Node: MERGE,  Next: MERGE_BITS,  Prev: MCLOCK8,  Up: Intrinsic Procedures
  
! 8.194 ‘MERGE’ -- Merge variables
  ================================
  
  _Description_:
       Select values from two arrays according to a logical mask.  The
!      result is equal to TSOURCE if MASK is ‘.TRUE.’, or equal to FSOURCE
!      if it is ‘.FALSE.’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 15737,15749 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = MERGE(TSOURCE, FSOURCE, MASK)'
  
  _Arguments_:
       TSOURCE     May be of any type.
       FSOURCE     Shall be of the same type and type parameters as
                   TSOURCE.
!      MASK        Shall be of type 'LOGICAL'.
  
  _Return value_:
       The result is of the same type and type parameters as TSOURCE.
--- 15737,15749 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = MERGE(TSOURCE, FSOURCE, MASK)’
  
  _Arguments_:
       TSOURCE     May be of any type.
       FSOURCE     Shall be of the same type and type parameters as
                   TSOURCE.
!      MASK        Shall be of type ‘LOGICAL’.
  
  _Return value_:
       The result is of the same type and type parameters as TSOURCE.
*************** _Return value_:
*** 15751,15761 ****
  
  File: gfortran.info,  Node: MERGE_BITS,  Next: MIN,  Prev: MERGE,  Up: Intrinsic Procedures
  
! 8.195 'MERGE_BITS' -- Merge of bits under mask
  ==============================================
  
  _Description_:
!      'MERGE_BITS(I, J, MASK)' merges the bits of I and J as determined
       by the mask.  The i-th bit of the result is equal to the i-th bit
       of I if the i-th bit of MASK is 1; it is equal to the i-th bit of J
       otherwise.
--- 15751,15761 ----
  
  File: gfortran.info,  Node: MERGE_BITS,  Next: MIN,  Prev: MERGE,  Up: Intrinsic Procedures
  
! 8.195 ‘MERGE_BITS’ -- Merge of bits under mask
  ==============================================
  
  _Description_:
!      ‘MERGE_BITS(I, J, MASK)’ merges the bits of I and J as determined
       by the mask.  The i-th bit of the result is equal to the i-th bit
       of I if the i-th bit of MASK is 1; it is equal to the i-th bit of J
       otherwise.
*************** _Class_:
*** 15767,15781 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = MERGE_BITS(I, J, MASK)'
  
  _Arguments_:
!      I           Shall be of type 'INTEGER' or a
                   boz-literal-constant.
!      J           Shall be of type 'INTEGER' with the same kind
                   type parameter as I or a boz-literal-constant.
                   I and J shall not both be boz-literal-constants.
!      MASK        Shall be of type 'INTEGER' or a
                   boz-literal-constant and of the same kind as I.
  
  _Return value_:
--- 15767,15781 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = MERGE_BITS(I, J, MASK)’
  
  _Arguments_:
!      I           Shall be of type ‘INTEGER’ or a
                   boz-literal-constant.
!      J           Shall be of type ‘INTEGER’ with the same kind
                   type parameter as I or a boz-literal-constant.
                   I and J shall not both be boz-literal-constants.
!      MASK        Shall be of type ‘INTEGER’ or a
                   boz-literal-constant and of the same kind as I.
  
  _Return value_:
*************** _Return value_:
*** 15784,15790 ****
  
  File: gfortran.info,  Node: MIN,  Next: MINEXPONENT,  Prev: MERGE_BITS,  Up: Intrinsic Procedures
  
! 8.196 'MIN' -- Minimum value of an argument list
  ================================================
  
  _Description_:
--- 15784,15790 ----
  
  File: gfortran.info,  Node: MIN,  Next: MINEXPONENT,  Prev: MERGE_BITS,  Up: Intrinsic Procedures
  
! 8.196 ‘MIN’ -- Minimum value of an argument list
  ================================================
  
  _Description_:
*************** _Class_:
*** 15797,15806 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = MIN(A1, A2 [, A3, ...])'
  
  _Arguments_:
!      A1          The type shall be 'INTEGER' or 'REAL'.
       A2, A3,     An expression of the same type and kind as A1.
       ...         (As a GNU extension, arguments of different
                   kinds are permitted.)
--- 15797,15806 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = MIN(A1, A2 [, A3, ...])’
  
  _Arguments_:
!      A1          The type shall be ‘INTEGER’ or ‘REAL’.
       A2, A3,     An expression of the same type and kind as A1.
       ...         (As a GNU extension, arguments of different
                   kinds are permitted.)
*************** _Return value_:
*** 15812,15822 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'MIN0(A1)'     'INTEGER(4) A1'   'INTEGER(4)'   Fortran 77 and later
!      'AMIN0(A1)'    'INTEGER(4) A1'   'REAL(4)'      Fortran 77 and later
!      'MIN1(A1)'     'REAL A1'         'INTEGER(4)'   Fortran 77 and later
!      'AMIN1(A1)'    'REAL(4) A1'      'REAL(4)'      Fortran 77 and later
!      'DMIN1(A1)'    'REAL(8) A1'      'REAL(8)'      Fortran 77 and later
  
  _See also_:
       *note MAX::,
--- 15812,15822 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘MIN0(A1)’     ‘INTEGER(4) A1’   ‘INTEGER(4)’   Fortran 77 and later
!      ‘AMIN0(A1)’    ‘INTEGER(4) A1’   ‘REAL(4)’      Fortran 77 and later
!      ‘MIN1(A1)’     ‘REAL A1’         ‘INTEGER(4)’   Fortran 77 and later
!      ‘AMIN1(A1)’    ‘REAL(4) A1’      ‘REAL(4)’      Fortran 77 and later
!      ‘DMIN1(A1)’    ‘REAL(8) A1’      ‘REAL(8)’      Fortran 77 and later
  
  _See also_:
       *note MAX::,
*************** _See also_:
*** 15826,15837 ****
  
  File: gfortran.info,  Node: MINEXPONENT,  Next: MINLOC,  Prev: MIN,  Up: Intrinsic Procedures
  
! 8.197 'MINEXPONENT' -- Minimum exponent of a real kind
  ======================================================
  
  _Description_:
!      'MINEXPONENT(X)' returns the minimum exponent in the model of the
!      type of 'X'.
  
  _Standard_:
       Fortran 90 and later
--- 15826,15837 ----
  
  File: gfortran.info,  Node: MINEXPONENT,  Next: MINLOC,  Prev: MIN,  Up: Intrinsic Procedures
  
! 8.197 ‘MINEXPONENT’ -- Minimum exponent of a real kind
  ======================================================
  
  _Description_:
!      ‘MINEXPONENT(X)’ returns the minimum exponent in the model of the
!      type of ‘X’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 15840,15861 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = MINEXPONENT(X)'
  
  _Arguments_:
!      X           Shall be of type 'REAL'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the default integer
       kind.
  
  _Example_:
!      See 'MAXEXPONENT' for an example.
  
  
  File: gfortran.info,  Node: MINLOC,  Next: MINVAL,  Prev: MINEXPONENT,  Up: Intrinsic Procedures
  
! 8.198 'MINLOC' -- Location of the minimum value within an array
  ===============================================================
  
  _Description_:
--- 15840,15861 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = MINEXPONENT(X)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the default integer
       kind.
  
  _Example_:
!      See ‘MAXEXPONENT’ for an example.
  
  
  File: gfortran.info,  Node: MINLOC,  Next: MINVAL,  Prev: MINEXPONENT,  Up: Intrinsic Procedures
  
! 8.198 ‘MINLOC’ -- Location of the minimum value within an array
  ===============================================================
  
  _Description_:
*************** _Description_:
*** 15863,15880 ****
       minimum value, or, if the DIM argument is supplied, determines the
       locations of the minimum element along each row of the array in the
       DIM direction.  If MASK is present, only the elements for which
!      MASK is '.TRUE.' are considered.  If more than one element in the
       array has the minimum value, the location returned is that of the
       first such element in array element order if the BACK is not
       present, or is false; if BACK is true, the location returned is
       that of the last such element.  If the array has zero size, or all
!      of the elements of MASK are '.FALSE.', then the result is an array
       of zeroes.  Similarly, if DIM is supplied and all of the elements
       of MASK along a given row are zero, the result value for that row
       is zero.
  
  _Standard_:
!      Fortran 90 and later; ARRAY of 'CHARACTER' and the KIND argument
       are available in Fortran 2003 and later.  The BACK argument is
       available in Fortran 2008 and later.
  
--- 15863,15880 ----
       minimum value, or, if the DIM argument is supplied, determines the
       locations of the minimum element along each row of the array in the
       DIM direction.  If MASK is present, only the elements for which
!      MASK is ‘.TRUE.’ are considered.  If more than one element in the
       array has the minimum value, the location returned is that of the
       first such element in array element order if the BACK is not
       present, or is false; if BACK is true, the location returned is
       that of the last such element.  If the array has zero size, or all
!      of the elements of MASK are ‘.FALSE.’, then the result is an array
       of zeroes.  Similarly, if DIM is supplied and all of the elements
       of MASK along a given row are zero, the result value for that row
       is zero.
  
  _Standard_:
!      Fortran 90 and later; ARRAY of ‘CHARACTER’ and the KIND argument
       are available in Fortran 2003 and later.  The BACK argument is
       available in Fortran 2008 and later.
  
*************** _Class_:
*** 15882,15903 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = MINLOC(ARRAY, DIM [, MASK] [,KIND] [,BACK])'
!      'RESULT = MINLOC(ARRAY [, MASK], [,KIND] [,BACK])'
  
  _Arguments_:
!      ARRAY       Shall be an array of type 'INTEGER', 'REAL' or
!                  'CHARACTER'.
!      DIM         (Optional) Shall be a scalar of type 'INTEGER',
                   with a value between one and the rank of ARRAY,
                   inclusive.  It may not be an optional dummy
                   argument.
!      MASK        Shall be of type 'LOGICAL', and conformable with
                   ARRAY.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
!      BACK        (Optional) A scalar of type 'LOGICAL'.
  
  _Return value_:
       If DIM is absent, the result is a rank-one array with a length
--- 15882,15903 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = MINLOC(ARRAY, DIM [, MASK] [,KIND] [,BACK])’
!      ‘RESULT = MINLOC(ARRAY [, MASK], [,KIND] [,BACK])’
  
  _Arguments_:
!      ARRAY       Shall be an array of type ‘INTEGER’, ‘REAL’ or
!                  ‘CHARACTER’.
!      DIM         (Optional) Shall be a scalar of type ‘INTEGER’,
                   with a value between one and the rank of ARRAY,
                   inclusive.  It may not be an optional dummy
                   argument.
!      MASK        Shall be of type ‘LOGICAL’, and conformable with
                   ARRAY.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
!      BACK        (Optional) A scalar of type ‘LOGICAL’.
  
  _Return value_:
       If DIM is absent, the result is a rank-one array with a length
*************** _See also_:
*** 15916,15932 ****
  
  File: gfortran.info,  Node: MINVAL,  Next: MOD,  Prev: MINLOC,  Up: Intrinsic Procedures
  
! 8.199 'MINVAL' -- Minimum value of an array
  ===========================================
  
  _Description_:
       Determines the minimum value of the elements in an array value, or,
       if the DIM argument is supplied, determines the minimum value along
       each row of the array in the DIM direction.  If MASK is present,
!      only the elements for which MASK is '.TRUE.' are considered.  If
       the array has zero size, or all of the elements of MASK are
!      '.FALSE.', then the result is 'HUGE(ARRAY)' if ARRAY is numeric, or
!      a string of 'CHAR(255)' characters if ARRAY is of character type.
  
  _Standard_:
       Fortran 90 and later
--- 15916,15932 ----
  
  File: gfortran.info,  Node: MINVAL,  Next: MOD,  Prev: MINLOC,  Up: Intrinsic Procedures
  
! 8.199 ‘MINVAL’ -- Minimum value of an array
  ===========================================
  
  _Description_:
       Determines the minimum value of the elements in an array value, or,
       if the DIM argument is supplied, determines the minimum value along
       each row of the array in the DIM direction.  If MASK is present,
!      only the elements for which MASK is ‘.TRUE.’ are considered.  If
       the array has zero size, or all of the elements of MASK are
!      ‘.FALSE.’, then the result is ‘HUGE(ARRAY)’ if ARRAY is numeric, or
!      a string of ‘CHAR(255)’ characters if ARRAY is of character type.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 15935,15950 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = MINVAL(ARRAY, DIM [, MASK])'
!      'RESULT = MINVAL(ARRAY [, MASK])'
  
  _Arguments_:
!      ARRAY       Shall be an array of type 'INTEGER' or 'REAL'.
!      DIM         (Optional) Shall be a scalar of type 'INTEGER',
                   with a value between one and the rank of ARRAY,
                   inclusive.  It may not be an optional dummy
                   argument.
!      MASK        Shall be of type 'LOGICAL', and conformable with
                   ARRAY.
  
  _Return value_:
--- 15935,15950 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = MINVAL(ARRAY, DIM [, MASK])’
!      ‘RESULT = MINVAL(ARRAY [, MASK])’
  
  _Arguments_:
!      ARRAY       Shall be an array of type ‘INTEGER’ or ‘REAL’.
!      DIM         (Optional) Shall be a scalar of type ‘INTEGER’,
                   with a value between one and the rank of ARRAY,
                   inclusive.  It may not be an optional dummy
                   argument.
!      MASK        Shall be of type ‘LOGICAL’, and conformable with
                   ARRAY.
  
  _Return value_:
*************** _See also_:
*** 15961,15971 ****
  
  File: gfortran.info,  Node: MOD,  Next: MODULO,  Prev: MINVAL,  Up: Intrinsic Procedures
  
! 8.200 'MOD' -- Remainder function
  =================================
  
  _Description_:
!      'MOD(A,P)' computes the remainder of the division of A by P.
  
  _Standard_:
       Fortran 77 and later, has overloads that are GNU extensions
--- 15961,15971 ----
  
  File: gfortran.info,  Node: MOD,  Next: MODULO,  Prev: MINVAL,  Up: Intrinsic Procedures
  
! 8.200 ‘MOD’ -- Remainder function
  =================================
  
  _Description_:
!      ‘MOD(A,P)’ computes the remainder of the division of A by P.
  
  _Standard_:
       Fortran 77 and later, has overloads that are GNU extensions
*************** _Class_:
*** 15974,15989 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = MOD(A, P)'
  
  _Arguments_:
!      A           Shall be a scalar of type 'INTEGER' or 'REAL'.
       P           Shall be a scalar of the same type and kind as A
                   and not equal to zero.  (As a GNU extension,
                   arguments of different kinds are permitted.)
  
  _Return value_:
!      The return value is the result of 'A - (INT(A/P) * P)'.  The type
       and kind of the return value is the same as that of the arguments.
       The returned value has the same sign as A and a magnitude less than
       the magnitude of P. (As a GNU extension, kind is the largest kind
--- 15974,15989 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = MOD(A, P)’
  
  _Arguments_:
!      A           Shall be a scalar of type ‘INTEGER’ or ‘REAL’.
       P           Shall be a scalar of the same type and kind as A
                   and not equal to zero.  (As a GNU extension,
                   arguments of different kinds are permitted.)
  
  _Return value_:
!      The return value is the result of ‘A - (INT(A/P) * P)’.  The type
       and kind of the return value is the same as that of the arguments.
       The returned value has the same sign as A and a magnitude less than
       the magnitude of P. (As a GNU extension, kind is the largest kind
*************** _Example_:
*** 16010,16022 ****
  _Specific names_:
       Name           Arguments          Return type    Standard
       ------------------------------------------------------------------------
!      'MOD(A,P)'     'INTEGER A,P'      'INTEGER'      Fortran 77 and later
!      'AMOD(A,P)'    'REAL(4) A,P'      'REAL(4)'      Fortran 77 and later
!      'DMOD(A,P)'    'REAL(8) A,P'      'REAL(8)'      Fortran 77 and later
!      'BMOD(A,P)'    'INTEGER(1) A,P'   'INTEGER(1)'   GNU extension
!      'IMOD(A,P)'    'INTEGER(2) A,P'   'INTEGER(2)'   GNU extension
!      'JMOD(A,P)'    'INTEGER(4) A,P'   'INTEGER(4)'   GNU extension
!      'KMOD(A,P)'    'INTEGER(8) A,P'   'INTEGER(8)'   GNU extension
  
  _See also_:
       *note MODULO::
--- 16010,16022 ----
  _Specific names_:
       Name           Arguments          Return type    Standard
       ------------------------------------------------------------------------
!      ‘MOD(A,P)’     ‘INTEGER A,P’      ‘INTEGER’      Fortran 77 and later
!      ‘AMOD(A,P)’    ‘REAL(4) A,P’      ‘REAL(4)’      Fortran 77 and later
!      ‘DMOD(A,P)’    ‘REAL(8) A,P’      ‘REAL(8)’      Fortran 77 and later
!      ‘BMOD(A,P)’    ‘INTEGER(1) A,P’   ‘INTEGER(1)’   GNU extension
!      ‘IMOD(A,P)’    ‘INTEGER(2) A,P’   ‘INTEGER(2)’   GNU extension
!      ‘JMOD(A,P)’    ‘INTEGER(4) A,P’   ‘INTEGER(4)’   GNU extension
!      ‘KMOD(A,P)’    ‘INTEGER(8) A,P’   ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note MODULO::
*************** _See also_:
*** 16024,16034 ****
  
  File: gfortran.info,  Node: MODULO,  Next: MOVE_ALLOC,  Prev: MOD,  Up: Intrinsic Procedures
  
! 8.201 'MODULO' -- Modulo function
  =================================
  
  _Description_:
!      'MODULO(A,P)' computes the A modulo P.
  
  _Standard_:
       Fortran 95 and later
--- 16024,16034 ----
  
  File: gfortran.info,  Node: MODULO,  Next: MOVE_ALLOC,  Prev: MOD,  Up: Intrinsic Procedures
  
! 8.201 ‘MODULO’ -- Modulo function
  =================================
  
  _Description_:
!      ‘MODULO(A,P)’ computes the A modulo P.
  
  _Standard_:
       Fortran 95 and later
*************** _Class_:
*** 16037,16046 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = MODULO(A, P)'
  
  _Arguments_:
!      A           Shall be a scalar of type 'INTEGER' or 'REAL'.
       P           Shall be a scalar of the same type and kind as
                   A.  It shall not be zero.  (As a GNU extension,
                   arguments of different kinds are permitted.)
--- 16037,16046 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = MODULO(A, P)’
  
  _Arguments_:
!      A           Shall be a scalar of type ‘INTEGER’ or ‘REAL’.
       P           Shall be a scalar of the same type and kind as
                   A.  It shall not be zero.  (As a GNU extension,
                   arguments of different kinds are permitted.)
*************** _Arguments_:
*** 16048,16058 ****
  _Return value_:
       The type and kind of the result are those of the arguments.  (As a
       GNU extension, kind is the largest kind of the actual arguments.)
!      If A and P are of type 'INTEGER':
!           'MODULO(A,P)' has the value R such that 'A=Q*P+R', where Q is
            an integer and R is between 0 (inclusive) and P (exclusive).
!      If A and P are of type 'REAL':
!           'MODULO(A,P)' has the value of 'A - FLOOR (A / P) * P'.
       The returned value has the same sign as P and a magnitude less than
       the magnitude of P.
  
--- 16048,16058 ----
  _Return value_:
       The type and kind of the result are those of the arguments.  (As a
       GNU extension, kind is the largest kind of the actual arguments.)
!      If A and P are of type ‘INTEGER’:
!           ‘MODULO(A,P)’ has the value R such that ‘A=Q*P+R’, where Q is
            an integer and R is between 0 (inclusive) and P (exclusive).
!      If A and P are of type ‘REAL’:
!           ‘MODULO(A,P)’ has the value of ‘A - FLOOR (A / P) * P’.
       The returned value has the same sign as P and a magnitude less than
       the magnitude of P.
  
*************** _See also_:
*** 16074,16084 ****
  
  File: gfortran.info,  Node: MOVE_ALLOC,  Next: MVBITS,  Prev: MODULO,  Up: Intrinsic Procedures
  
! 8.202 'MOVE_ALLOC' -- Move allocation from one object to another
  ================================================================
  
  _Description_:
!      'MOVE_ALLOC(FROM, TO)' moves the allocation from FROM to TO.  FROM
       will become deallocated in the process.
  
  _Standard_:
--- 16074,16084 ----
  
  File: gfortran.info,  Node: MOVE_ALLOC,  Next: MVBITS,  Prev: MODULO,  Up: Intrinsic Procedures
  
! 8.202 ‘MOVE_ALLOC’ -- Move allocation from one object to another
  ================================================================
  
  _Description_:
!      ‘MOVE_ALLOC(FROM, TO)’ moves the allocation from FROM to TO.  FROM
       will become deallocated in the process.
  
  _Standard_:
*************** _Class_:
*** 16088,16099 ****
       Pure subroutine
  
  _Syntax_:
!      'CALL MOVE_ALLOC(FROM, TO)'
  
  _Arguments_:
!      FROM        'ALLOCATABLE', 'INTENT(INOUT)', may be of any
                   type and kind.
!      TO          'ALLOCATABLE', 'INTENT(OUT)', shall be of the
                   same type, kind and rank as FROM.
  
  _Return value_:
--- 16088,16099 ----
       Pure subroutine
  
  _Syntax_:
!      ‘CALL MOVE_ALLOC(FROM, TO)’
  
  _Arguments_:
!      FROM        ‘ALLOCATABLE’, ‘INTENT(INOUT)’, may be of any
                   type and kind.
!      TO          ‘ALLOCATABLE’, ‘INTENT(OUT)’, shall be of the
                   same type, kind and rank as FROM.
  
  _Return value_:
*************** _Example_:
*** 16113,16127 ****
  
  File: gfortran.info,  Node: MVBITS,  Next: NEAREST,  Prev: MOVE_ALLOC,  Up: Intrinsic Procedures
  
! 8.203 'MVBITS' -- Move bits from one integer to another
  =======================================================
  
  _Description_:
!      Moves LEN bits from positions FROMPOS through 'FROMPOS+LEN-1' of
!      FROM to positions TOPOS through 'TOPOS+LEN-1' of TO.  The portion
       of argument TO not affected by the movement of bits is unchanged.
!      The values of 'FROMPOS+LEN-1' and 'TOPOS+LEN-1' must be less than
!      'BIT_SIZE(FROM)'.
  
  _Standard_:
       Fortran 90 and later, has overloads that are GNU extensions
--- 16113,16127 ----
  
  File: gfortran.info,  Node: MVBITS,  Next: NEAREST,  Prev: MOVE_ALLOC,  Up: Intrinsic Procedures
  
! 8.203 ‘MVBITS’ -- Move bits from one integer to another
  =======================================================
  
  _Description_:
!      Moves LEN bits from positions FROMPOS through ‘FROMPOS+LEN-1’ of
!      FROM to positions TOPOS through ‘TOPOS+LEN-1’ of TO.  The portion
       of argument TO not affected by the movement of bits is unchanged.
!      The values of ‘FROMPOS+LEN-1’ and ‘TOPOS+LEN-1’ must be less than
!      ‘BIT_SIZE(FROM)’.
  
  _Standard_:
       Fortran 90 and later, has overloads that are GNU extensions
*************** _Class_:
*** 16130,16153 ****
       Elemental subroutine
  
  _Syntax_:
!      'CALL MVBITS(FROM, FROMPOS, LEN, TO, TOPOS)'
  
  _Arguments_:
!      FROM        The type shall be 'INTEGER'.
!      FROMPOS     The type shall be 'INTEGER'.
!      LEN         The type shall be 'INTEGER'.
!      TO          The type shall be 'INTEGER', of the same kind as
                   FROM.
!      TOPOS       The type shall be 'INTEGER'.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'MVBITS(A)'    'INTEGER A'       'INTEGER'      Fortran 90 and later
!      'BMVBITS(A)'   'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'IMVBITS(A)'   'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JMVBITS(A)'   'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KMVBITS(A)'   'INTEGER(8) A'    'INTEGER(8)'   GNU extension
  
  _See also_:
       *note IBCLR::,
--- 16130,16153 ----
       Elemental subroutine
  
  _Syntax_:
!      ‘CALL MVBITS(FROM, FROMPOS, LEN, TO, TOPOS)’
  
  _Arguments_:
!      FROM        The type shall be ‘INTEGER’.
!      FROMPOS     The type shall be ‘INTEGER’.
!      LEN         The type shall be ‘INTEGER’.
!      TO          The type shall be ‘INTEGER’, of the same kind as
                   FROM.
!      TOPOS       The type shall be ‘INTEGER’.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘MVBITS(A)’    ‘INTEGER A’       ‘INTEGER’      Fortran 90 and later
!      ‘BMVBITS(A)’   ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘IMVBITS(A)’   ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JMVBITS(A)’   ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KMVBITS(A)’   ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note IBCLR::,
*************** _See also_:
*** 16160,16171 ****
  
  File: gfortran.info,  Node: NEAREST,  Next: NEW_LINE,  Prev: MVBITS,  Up: Intrinsic Procedures
  
! 8.204 'NEAREST' -- Nearest representable number
  ===============================================
  
  _Description_:
!      'NEAREST(X, S)' returns the processor-representable number nearest
!      to 'X' in the direction indicated by the sign of 'S'.
  
  _Standard_:
       Fortran 90 and later
--- 16160,16171 ----
  
  File: gfortran.info,  Node: NEAREST,  Next: NEW_LINE,  Prev: MVBITS,  Up: Intrinsic Procedures
  
! 8.204 ‘NEAREST’ -- Nearest representable number
  ===============================================
  
  _Description_:
!      ‘NEAREST(X, S)’ returns the processor-representable number nearest
!      to ‘X’ in the direction indicated by the sign of ‘S’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 16174,16190 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = NEAREST(X, S)'
  
  _Arguments_:
!      X           Shall be of type 'REAL'.
!      S           Shall be of type 'REAL' and not equal to zero.
  
  _Return value_:
!      The return value is of the same type as 'X'.  If 'S' is positive,
!      'NEAREST' returns the processor-representable number greater than
!      'X' and nearest to it.  If 'S' is negative, 'NEAREST' returns the
!      processor-representable number smaller than 'X' and nearest to it.
  
  _Example_:
            program test_nearest
--- 16174,16190 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = NEAREST(X, S)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’.
!      S           Shall be of type ‘REAL’ and not equal to zero.
  
  _Return value_:
!      The return value is of the same type as ‘X’.  If ‘S’ is positive,
!      ‘NEAREST’ returns the processor-representable number greater than
!      ‘X’ and nearest to it.  If ‘S’ is negative, ‘NEAREST’ returns the
!      processor-representable number smaller than ‘X’ and nearest to it.
  
  _Example_:
            program test_nearest
*************** _Example_:
*** 16197,16207 ****
  
  File: gfortran.info,  Node: NEW_LINE,  Next: NINT,  Prev: NEAREST,  Up: Intrinsic Procedures
  
! 8.205 'NEW_LINE' -- New line character
  ======================================
  
  _Description_:
!      'NEW_LINE(C)' returns the new-line character.
  
  _Standard_:
       Fortran 2003 and later
--- 16197,16207 ----
  
  File: gfortran.info,  Node: NEW_LINE,  Next: NINT,  Prev: NEAREST,  Up: Intrinsic Procedures
  
! 8.205 ‘NEW_LINE’ -- New line character
  ======================================
  
  _Description_:
!      ‘NEW_LINE(C)’ returns the new-line character.
  
  _Standard_:
       Fortran 2003 and later
*************** _Class_:
*** 16210,16220 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = NEW_LINE(C)'
  
  _Arguments_:
       C           The argument shall be a scalar or array of the
!                  type 'CHARACTER'.
  
  _Return value_:
       Returns a CHARACTER scalar of length one with the new-line
--- 16210,16220 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = NEW_LINE(C)’
  
  _Arguments_:
       C           The argument shall be a scalar or array of the
!                  type ‘CHARACTER’.
  
  _Return value_:
       Returns a CHARACTER scalar of length one with the new-line
*************** _Example_:
*** 16229,16239 ****
  
  File: gfortran.info,  Node: NINT,  Next: NORM2,  Prev: NEW_LINE,  Up: Intrinsic Procedures
  
! 8.206 'NINT' -- Nearest whole number
  ====================================
  
  _Description_:
!      'NINT(A)' rounds its argument to the nearest whole number.
  
  _Standard_:
       Fortran 77 and later, with KIND argument Fortran 90 and later
--- 16229,16239 ----
  
  File: gfortran.info,  Node: NINT,  Next: NORM2,  Prev: NEW_LINE,  Up: Intrinsic Procedures
  
! 8.206 ‘NINT’ -- Nearest whole number
  ====================================
  
  _Description_:
!      ‘NINT(A)’ rounds its argument to the nearest whole number.
  
  _Standard_:
       Fortran 77 and later, with KIND argument Fortran 90 and later
*************** _Class_:
*** 16242,16259 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = NINT(A [, KIND])'
  
  _Arguments_:
!      A           The type of the argument shall be 'REAL'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
       Returns A with the fractional portion of its magnitude eliminated
       by rounding to the nearest whole number and with its sign
!      preserved, converted to an 'INTEGER' of the default kind.
  
  _Example_:
            program test_nint
--- 16242,16259 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = NINT(A [, KIND])’
  
  _Arguments_:
!      A           The type of the argument shall be ‘REAL’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
       Returns A with the fractional portion of its magnitude eliminated
       by rounding to the nearest whole number and with its sign
!      preserved, converted to an ‘INTEGER’ of the default kind.
  
  _Example_:
            program test_nint
*************** _Example_:
*** 16267,16274 ****
  _Specific names_:
       Name           Argument          Return Type    Standard
       -------------------------------------------------------------------------
!      'NINT(A)'      'REAL(4) A'       'INTEGER'      Fortran 77 and later
!      'IDNINT(A)'    'REAL(8) A'       'INTEGER'      Fortran 77 and later
  
  _See also_:
       *note CEILING::,
--- 16267,16274 ----
  _Specific names_:
       Name           Argument          Return Type    Standard
       -------------------------------------------------------------------------
!      ‘NINT(A)’      ‘REAL(4) A’       ‘INTEGER’      Fortran 77 and later
!      ‘IDNINT(A)’    ‘REAL(8) A’       ‘INTEGER’      Fortran 77 and later
  
  _See also_:
       *note CEILING::,
*************** _See also_:
*** 16277,16283 ****
  
  File: gfortran.info,  Node: NORM2,  Next: NOT,  Prev: NINT,  Up: Intrinsic Procedures
  
! 8.207 'NORM2' -- Euclidean vector norms
  =======================================
  
  _Description_:
--- 16277,16283 ----
  
  File: gfortran.info,  Node: NORM2,  Next: NOT,  Prev: NINT,  Up: Intrinsic Procedures
  
! 8.207 ‘NORM2’ -- Euclidean vector norms
  =======================================
  
  _Description_:
*************** _Class_:
*** 16291,16301 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = NORM2(ARRAY[, DIM])'
  
  _Arguments_:
!      ARRAY       Shall be an array of type 'REAL'
!      DIM         (Optional) shall be a scalar of type 'INTEGER'
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
  
--- 16291,16301 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = NORM2(ARRAY[, DIM])’
  
  _Arguments_:
!      ARRAY       Shall be an array of type ‘REAL’
!      DIM         (Optional) shall be a scalar of type ‘INTEGER’
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
  
*************** _Example_:
*** 16316,16326 ****
  
  File: gfortran.info,  Node: NOT,  Next: NULL,  Prev: NORM2,  Up: Intrinsic Procedures
  
! 8.208 'NOT' -- Logical negation
  ===============================
  
  _Description_:
!      'NOT' returns the bitwise Boolean inverse of I.
  
  _Standard_:
       Fortran 90 and later, has overloads that are GNU extensions
--- 16316,16326 ----
  
  File: gfortran.info,  Node: NOT,  Next: NULL,  Prev: NORM2,  Up: Intrinsic Procedures
  
! 8.208 ‘NOT’ -- Logical negation
  ===============================
  
  _Description_:
!      ‘NOT’ returns the bitwise Boolean inverse of I.
  
  _Standard_:
       Fortran 90 and later, has overloads that are GNU extensions
*************** _Class_:
*** 16329,16350 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = NOT(I)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
  
  _Return value_:
!      The return type is 'INTEGER', of the same kind as the argument.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'NOT(A)'       'INTEGER A'       'INTEGER'      Fortran 95 and later
!      'BNOT(A)'      'INTEGER(1) A'    'INTEGER(1)'   GNU extension
!      'INOT(A)'      'INTEGER(2) A'    'INTEGER(2)'   GNU extension
!      'JNOT(A)'      'INTEGER(4) A'    'INTEGER(4)'   GNU extension
!      'KNOT(A)'      'INTEGER(8) A'    'INTEGER(8)'   GNU extension
  
  _See also_:
       *note IAND::,
--- 16329,16350 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = NOT(I)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return type is ‘INTEGER’, of the same kind as the argument.
  
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘NOT(A)’       ‘INTEGER A’       ‘INTEGER’      Fortran 95 and later
!      ‘BNOT(A)’      ‘INTEGER(1) A’    ‘INTEGER(1)’   GNU extension
!      ‘INOT(A)’      ‘INTEGER(2) A’    ‘INTEGER(2)’   GNU extension
!      ‘JNOT(A)’      ‘INTEGER(4) A’    ‘INTEGER(4)’   GNU extension
!      ‘KNOT(A)’      ‘INTEGER(8) A’    ‘INTEGER(8)’   GNU extension
  
  _See also_:
       *note IAND::,
*************** _See also_:
*** 16357,16363 ****
  
  File: gfortran.info,  Node: NULL,  Next: NUM_IMAGES,  Prev: NOT,  Up: Intrinsic Procedures
  
! 8.209 'NULL' -- Function that returns an disassociated pointer
  ==============================================================
  
  _Description_:
--- 16357,16363 ----
  
  File: gfortran.info,  Node: NULL,  Next: NUM_IMAGES,  Prev: NOT,  Up: Intrinsic Procedures
  
! 8.209 ‘NULL’ -- Function that returns an disassociated pointer
  ==============================================================
  
  _Description_:
*************** _Class_:
*** 16376,16382 ****
       Transformational function
  
  _Syntax_:
!      'PTR => NULL([MOLD])'
  
  _Arguments_:
       MOLD        (Optional) shall be a pointer of any association
--- 16376,16382 ----
       Transformational function
  
  _Syntax_:
!      ‘PTR => NULL([MOLD])’
  
  _Arguments_:
       MOLD        (Optional) shall be a pointer of any association
*************** _See also_:
*** 16394,16400 ****
  
  File: gfortran.info,  Node: NUM_IMAGES,  Next: OR,  Prev: NULL,  Up: Intrinsic Procedures
  
! 8.210 'NUM_IMAGES' -- Function that returns the number of images
  ================================================================
  
  _Description_:
--- 16394,16400 ----
  
  File: gfortran.info,  Node: NUM_IMAGES,  Next: OR,  Prev: NULL,  Up: Intrinsic Procedures
  
! 8.210 ‘NUM_IMAGES’ -- Function that returns the number of images
  ================================================================
  
  _Description_:
*************** _Class_:
*** 16408,16414 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = NUM_IMAGES(DISTANCE, FAILED)'
  
  _Arguments_:
       DISTANCE    (optional, intent(in)) Nonnegative scalar
--- 16408,16414 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = NUM_IMAGES(DISTANCE, FAILED)’
  
  _Arguments_:
       DISTANCE    (optional, intent(in)) Nonnegative scalar
*************** _Return value_:
*** 16423,16429 ****
       distance of DISTANCE from the invoking team.  If DISTANCE is larger
       than the distance to the initial team, the number of images of the
       initial team is returned.  If FAILED is not present the total
!      number of images is returned; if it has the value '.TRUE.', the
       number of failed images is returned, otherwise, the number of
       images which do have not the failed status.
  
--- 16423,16429 ----
       distance of DISTANCE from the invoking team.  If DISTANCE is larger
       than the distance to the initial team, the number of images of the
       initial team is returned.  If FAILED is not present the total
!      number of images is returned; if it has the value ‘.TRUE.’, the
       number of failed images is returned, otherwise, the number of
       images which do have not the failed status.
  
*************** _See also_:
*** 16445,16455 ****
  
  File: gfortran.info,  Node: OR,  Next: PACK,  Prev: NUM_IMAGES,  Up: Intrinsic Procedures
  
! 8.211 'OR' -- Bitwise logical OR
  ================================
  
  _Description_:
!      Bitwise logical 'OR'.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  For integer arguments, programmers should consider
--- 16445,16455 ----
  
  File: gfortran.info,  Node: OR,  Next: PACK,  Prev: NUM_IMAGES,  Up: Intrinsic Procedures
  
! 8.211 ‘OR’ -- Bitwise logical OR
  ================================
  
  _Description_:
!      Bitwise logical ‘OR’.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  For integer arguments, programmers should consider
*************** _Class_:
*** 16463,16485 ****
       Function
  
  _Syntax_:
!      'RESULT = OR(I, J)'
  
  _Arguments_:
!      I           The type shall be either a scalar 'INTEGER' type
!                  or a scalar 'LOGICAL' type or a
                   boz-literal-constant.
       J           The type shall be the same as the type of I or a
                   boz-literal-constant.  I and J shall not both be
                   boz-literal-constants.  If either I and J is a
                   boz-literal-constant, then the other argument
!                  must be a scalar 'INTEGER'.
  
  _Return value_:
!      The return type is either a scalar 'INTEGER' or a scalar 'LOGICAL'.
       If the kind type parameters differ, then the smaller kind type is
       implicitly converted to larger kind, and the return has the larger
!      kind.  A boz-literal-constant is converted to an 'INTEGER' with the
       kind type parameter of the other argument as-if a call to *note
       INT:: occurred.
  
--- 16463,16485 ----
       Function
  
  _Syntax_:
!      ‘RESULT = OR(I, J)’
  
  _Arguments_:
!      I           The type shall be either a scalar ‘INTEGER’ type
!                  or a scalar ‘LOGICAL’ type or a
                   boz-literal-constant.
       J           The type shall be the same as the type of I or a
                   boz-literal-constant.  I and J shall not both be
                   boz-literal-constants.  If either I and J is a
                   boz-literal-constant, then the other argument
!                  must be a scalar ‘INTEGER’.
  
  _Return value_:
!      The return type is either a scalar ‘INTEGER’ or a scalar ‘LOGICAL’.
       If the kind type parameters differ, then the smaller kind type is
       implicitly converted to larger kind, and the return has the larger
!      kind.  A boz-literal-constant is converted to an ‘INTEGER’ with the
       kind type parameter of the other argument as-if a call to *note
       INT:: occurred.
  
*************** _See also_:
*** 16500,16513 ****
  
  File: gfortran.info,  Node: PACK,  Next: PARITY,  Prev: OR,  Up: Intrinsic Procedures
  
! 8.212 'PACK' -- Pack an array into an array of rank one
  =======================================================
  
  _Description_:
       Stores the elements of ARRAY in an array of rank one.
  
       The beginning of the resulting array is made up of elements whose
!      MASK equals 'TRUE'.  Afterwards, positions are filled with elements
       taken from VECTOR.
  
  _Standard_:
--- 16500,16513 ----
  
  File: gfortran.info,  Node: PACK,  Next: PARITY,  Prev: OR,  Up: Intrinsic Procedures
  
! 8.212 ‘PACK’ -- Pack an array into an array of rank one
  =======================================================
  
  _Description_:
       Stores the elements of ARRAY in an array of rank one.
  
       The beginning of the resulting array is made up of elements whose
!      MASK equals ‘TRUE’.  Afterwards, positions are filled with elements
       taken from VECTOR.
  
  _Standard_:
*************** _Class_:
*** 16517,16529 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = PACK(ARRAY, MASK[,VECTOR])'
  
  _Arguments_:
       ARRAY       Shall be an array of any type.
!      MASK        Shall be an array of type 'LOGICAL' and of the
                   same size as ARRAY.  Alternatively, it may be a
!                  'LOGICAL' scalar.
       VECTOR      (Optional) shall be an array of the same type as
                   ARRAY and of rank one.  If present, the number
                   of elements in VECTOR shall be equal to or
--- 16517,16529 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = PACK(ARRAY, MASK[,VECTOR])’
  
  _Arguments_:
       ARRAY       Shall be an array of any type.
!      MASK        Shall be an array of type ‘LOGICAL’ and of the
                   same size as ARRAY.  Alternatively, it may be a
!                  ‘LOGICAL’ scalar.
       VECTOR      (Optional) shall be an array of the same type as
                   ARRAY and of rank one.  If present, the number
                   of elements in VECTOR shall be equal to or
*************** _Arguments_:
*** 16535,16541 ****
  _Return value_:
       The result is an array of rank one and the same type as that of
       ARRAY.  If VECTOR is present, the result size is that of VECTOR,
!      the number of 'TRUE' values in MASK otherwise.
  
  _Example_:
       Gathering nonzero elements from an array:
--- 16535,16541 ----
  _Return value_:
       The result is an array of rank one and the same type as that of
       ARRAY.  If VECTOR is present, the result size is that of VECTOR,
!      the number of ‘TRUE’ values in MASK otherwise.
  
  _Example_:
       Gathering nonzero elements from an array:
*************** _See also_:
*** 16560,16570 ****
  
  File: gfortran.info,  Node: PARITY,  Next: PERROR,  Prev: PACK,  Up: Intrinsic Procedures
  
! 8.213 'PARITY' -- Reduction with exclusive OR
  =============================================
  
  _Description_:
!      Calculates the parity, i.e.  the reduction using '.XOR.', of MASK
       along dimension DIM.
  
  _Standard_:
--- 16560,16570 ----
  
  File: gfortran.info,  Node: PARITY,  Next: PERROR,  Prev: PACK,  Up: Intrinsic Procedures
  
! 8.213 ‘PARITY’ -- Reduction with exclusive OR
  =============================================
  
  _Description_:
!      Calculates the parity, i.e.  the reduction using ‘.XOR.’, of MASK
       along dimension DIM.
  
  _Standard_:
*************** _Class_:
*** 16574,16584 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = PARITY(MASK[, DIM])'
  
  _Arguments_:
!      MASK        Shall be an array of type 'LOGICAL'
!      DIM         (Optional) shall be a scalar of type 'INTEGER'
                   with a value in the range from 1 to n, where n
                   equals the rank of MASK.
  
--- 16574,16584 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = PARITY(MASK[, DIM])’
  
  _Arguments_:
!      MASK        Shall be an array of type ‘LOGICAL’
!      DIM         (Optional) shall be a scalar of type ‘INTEGER’
                   with a value in the range from 1 to n, where n
                   equals the rank of MASK.
  
*************** _Return value_:
*** 16586,16592 ****
       The result is of the same type as MASK.
  
       If DIM is absent, a scalar with the parity of all elements in MASK
!      is returned, i.e.  true if an odd number of elements is '.true.'
       and false otherwise.  If DIM is present, an array of rank n-1,
       where n equals the rank of ARRAY, and a shape similar to that of
       MASK with dimension DIM dropped is returned.
--- 16586,16592 ----
       The result is of the same type as MASK.
  
       If DIM is absent, a scalar with the parity of all elements in MASK
!      is returned, i.e.  true if an odd number of elements is ‘.true.’
       and false otherwise.  If DIM is present, an array of rank n-1,
       where n equals the rank of ARRAY, and a shape similar to that of
       MASK with dimension DIM dropped is returned.
*************** _Example_:
*** 16600,16612 ****
  
  File: gfortran.info,  Node: PERROR,  Next: POPCNT,  Prev: PARITY,  Up: Intrinsic Procedures
  
! 8.214 'PERROR' -- Print system error message
  ============================================
  
  _Description_:
!      Prints (on the C 'stderr' stream) a newline-terminated error
       message corresponding to the last system error.  This is prefixed
!      by STRING, a colon and a space.  See 'perror(3)'.
  
  _Standard_:
       GNU extension
--- 16600,16612 ----
  
  File: gfortran.info,  Node: PERROR,  Next: POPCNT,  Prev: PARITY,  Up: Intrinsic Procedures
  
! 8.214 ‘PERROR’ -- Print system error message
  ============================================
  
  _Description_:
!      Prints (on the C ‘stderr’ stream) a newline-terminated error
       message corresponding to the last system error.  This is prefixed
!      by STRING, a colon and a space.  See ‘perror(3)’.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 16615,16624 ****
       Subroutine
  
  _Syntax_:
!      'CALL PERROR(STRING)'
  
  _Arguments_:
!      STRING      A scalar of type 'CHARACTER' and of the default
                   kind.
  
  _See also_:
--- 16615,16624 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL PERROR(STRING)’
  
  _Arguments_:
!      STRING      A scalar of type ‘CHARACTER’ and of the default
                   kind.
  
  _See also_:
*************** _See also_:
*** 16627,16638 ****
  
  File: gfortran.info,  Node: POPCNT,  Next: POPPAR,  Prev: PERROR,  Up: Intrinsic Procedures
  
! 8.215 'POPCNT' -- Number of bits set
  ====================================
  
  _Description_:
!      'POPCNT(I)' returns the number of bits set ('1' bits) in the binary
!      representation of 'I'.
  
  _Standard_:
       Fortran 2008 and later
--- 16627,16638 ----
  
  File: gfortran.info,  Node: POPCNT,  Next: POPPAR,  Prev: PERROR,  Up: Intrinsic Procedures
  
! 8.215 ‘POPCNT’ -- Number of bits set
  ====================================
  
  _Description_:
!      ‘POPCNT(I)’ returns the number of bits set ('1' bits) in the binary
!      representation of ‘I’.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 16641,16653 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = POPCNT(I)'
  
  _Arguments_:
!      I           Shall be of type 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the default integer
       kind.
  
  _Example_:
--- 16641,16653 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = POPCNT(I)’
  
  _Arguments_:
!      I           Shall be of type ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the default integer
       kind.
  
  _Example_:
*************** _See also_:
*** 16664,16676 ****
  
  File: gfortran.info,  Node: POPPAR,  Next: PRECISION,  Prev: POPCNT,  Up: Intrinsic Procedures
  
! 8.216 'POPPAR' -- Parity of the number of bits set
  ==================================================
  
  _Description_:
!      'POPPAR(I)' returns parity of the integer 'I', i.e.  the parity of
       the number of bits set ('1' bits) in the binary representation of
!      'I'.  It is equal to 0 if 'I' has an even number of bits set, and 1
       for an odd number of '1' bits.
  
  _Standard_:
--- 16664,16676 ----
  
  File: gfortran.info,  Node: POPPAR,  Next: PRECISION,  Prev: POPCNT,  Up: Intrinsic Procedures
  
! 8.216 ‘POPPAR’ -- Parity of the number of bits set
  ==================================================
  
  _Description_:
!      ‘POPPAR(I)’ returns parity of the integer ‘I’, i.e.  the parity of
       the number of bits set ('1' bits) in the binary representation of
!      ‘I’.  It is equal to 0 if ‘I’ has an even number of bits set, and 1
       for an odd number of '1' bits.
  
  _Standard_:
*************** _Class_:
*** 16680,16692 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = POPPAR(I)'
  
  _Arguments_:
!      I           Shall be of type 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the default integer
       kind.
  
  _Example_:
--- 16680,16692 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = POPPAR(I)’
  
  _Arguments_:
!      I           Shall be of type ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the default integer
       kind.
  
  _Example_:
*************** _See also_:
*** 16703,16714 ****
  
  File: gfortran.info,  Node: PRECISION,  Next: PRESENT,  Prev: POPPAR,  Up: Intrinsic Procedures
  
! 8.217 'PRECISION' -- Decimal precision of a real kind
  =====================================================
  
  _Description_:
!      'PRECISION(X)' returns the decimal precision in the model of the
!      type of 'X'.
  
  _Standard_:
       Fortran 90 and later
--- 16703,16714 ----
  
  File: gfortran.info,  Node: PRECISION,  Next: PRESENT,  Prev: POPPAR,  Up: Intrinsic Procedures
  
! 8.217 ‘PRECISION’ -- Decimal precision of a real kind
  =====================================================
  
  _Description_:
!      ‘PRECISION(X)’ returns the decimal precision in the model of the
!      type of ‘X’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 16717,16730 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = PRECISION(X)'
  
  _Arguments_:
!      X           Shall be of type 'REAL' or 'COMPLEX'.  It may be
                   scalar or valued.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the default integer
       kind.
  
  _Example_:
--- 16717,16730 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = PRECISION(X)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’ or ‘COMPLEX’.  It may be
                   scalar or valued.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the default integer
       kind.
  
  _Example_:
*************** _See also_:
*** 16742,16748 ****
  
  File: gfortran.info,  Node: PRESENT,  Next: PRODUCT,  Prev: PRECISION,  Up: Intrinsic Procedures
  
! 8.218 'PRESENT' -- Determine whether an optional dummy argument is specified
  ============================================================================
  
  _Description_:
--- 16742,16748 ----
  
  File: gfortran.info,  Node: PRESENT,  Next: PRODUCT,  Prev: PRECISION,  Up: Intrinsic Procedures
  
! 8.218 ‘PRESENT’ -- Determine whether an optional dummy argument is specified
  ============================================================================
  
  _Description_:
*************** _Class_:
*** 16755,16761 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = PRESENT(A)'
  
  _Arguments_:
       A           May be of any type and may be a pointer, scalar
--- 16755,16761 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = PRESENT(A)’
  
  _Arguments_:
       A           May be of any type and may be a pointer, scalar
*************** _Arguments_:
*** 16765,16772 ****
                   function.
  
  _Return value_:
!      Returns either 'TRUE' if the optional argument A is present, or
!      'FALSE' otherwise.
  
  _Example_:
            PROGRAM test_present
--- 16765,16772 ----
                   function.
  
  _Return value_:
!      Returns either ‘TRUE’ if the optional argument A is present, or
!      ‘FALSE’ otherwise.
  
  _Example_:
            PROGRAM test_present
*************** _Example_:
*** 16781,16792 ****
  
  File: gfortran.info,  Node: PRODUCT,  Next: RADIX,  Prev: PRESENT,  Up: Intrinsic Procedures
  
! 8.219 'PRODUCT' -- Product of array elements
  ============================================
  
  _Description_:
       Multiplies the elements of ARRAY along dimension DIM if the
!      corresponding element in MASK is 'TRUE'.
  
  _Standard_:
       Fortran 90 and later
--- 16781,16792 ----
  
  File: gfortran.info,  Node: PRODUCT,  Next: RADIX,  Prev: PRESENT,  Up: Intrinsic Procedures
  
! 8.219 ‘PRODUCT’ -- Product of array elements
  ============================================
  
  _Description_:
       Multiplies the elements of ARRAY along dimension DIM if the
!      corresponding element in MASK is ‘TRUE’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 16795,16810 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = PRODUCT(ARRAY[, MASK])'
!      'RESULT = PRODUCT(ARRAY, DIM[, MASK])'
  
  _Arguments_:
!      ARRAY       Shall be an array of type 'INTEGER', 'REAL' or
!                  'COMPLEX'.
!      DIM         (Optional) shall be a scalar of type 'INTEGER'
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
!      MASK        (Optional) shall be of type 'LOGICAL' and either
                   be a scalar or an array of the same shape as
                   ARRAY.
  
--- 16795,16810 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = PRODUCT(ARRAY[, MASK])’
!      ‘RESULT = PRODUCT(ARRAY, DIM[, MASK])’
  
  _Arguments_:
!      ARRAY       Shall be an array of type ‘INTEGER’, ‘REAL’ or
!                  ‘COMPLEX’.
!      DIM         (Optional) shall be a scalar of type ‘INTEGER’
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
!      MASK        (Optional) shall be of type ‘LOGICAL’ and either
                   be a scalar or an array of the same shape as
                   ARRAY.
  
*************** _See also_:
*** 16829,16839 ****
  
  File: gfortran.info,  Node: RADIX,  Next: RAN,  Prev: PRODUCT,  Up: Intrinsic Procedures
  
! 8.220 'RADIX' -- Base of a model number
  =======================================
  
  _Description_:
!      'RADIX(X)' returns the base of the model representing the entity X.
  
  _Standard_:
       Fortran 90 and later
--- 16829,16839 ----
  
  File: gfortran.info,  Node: RADIX,  Next: RAN,  Prev: PRODUCT,  Up: Intrinsic Procedures
  
! 8.220 ‘RADIX’ -- Base of a model number
  =======================================
  
  _Description_:
!      ‘RADIX(X)’ returns the base of the model representing the entity X.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 16842,16854 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = RADIX(X)'
  
  _Arguments_:
!      X           Shall be of type 'INTEGER' or 'REAL'
  
  _Return value_:
!      The return value is a scalar of type 'INTEGER' and of the default
       integer kind.
  
  _Example_:
--- 16842,16854 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = RADIX(X)’
  
  _Arguments_:
!      X           Shall be of type ‘INTEGER’ or ‘REAL’
  
  _Return value_:
!      The return value is a scalar of type ‘INTEGER’ and of the default
       integer kind.
  
  _Example_:
*************** _See also_:
*** 16862,16873 ****
  
  File: gfortran.info,  Node: RAN,  Next: RAND,  Prev: RADIX,  Up: Intrinsic Procedures
  
! 8.221 'RAN' -- Real pseudo-random number
  ========================================
  
  _Description_:
!      For compatibility with HP FORTRAN 77/iX, the 'RAN' intrinsic is
!      provided as an alias for 'RAND'.  See *note RAND:: for complete
       documentation.
  
  _Standard_:
--- 16862,16873 ----
  
  File: gfortran.info,  Node: RAN,  Next: RAND,  Prev: RADIX,  Up: Intrinsic Procedures
  
! 8.221 ‘RAN’ -- Real pseudo-random number
  ========================================
  
  _Description_:
!      For compatibility with HP FORTRAN 77/iX, the ‘RAN’ intrinsic is
!      provided as an alias for ‘RAND’.  See *note RAND:: for complete
       documentation.
  
  _Standard_:
*************** _See also_:
*** 16883,16901 ****
  
  File: gfortran.info,  Node: RAND,  Next: RANDOM_INIT,  Prev: RAN,  Up: Intrinsic Procedures
  
! 8.222 'RAND' -- Real pseudo-random number
  =========================================
  
  _Description_:
!      'RAND(FLAG)' returns a pseudo-random number from a uniform
       distribution between 0 and 1.  If FLAG is 0, the next number in the
       current sequence is returned; if FLAG is 1, the generator is
!      restarted by 'CALL SRAND(0)'; if FLAG has any other value, it is
!      used as a new seed with 'SRAND'.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  It implements a simple modulo generator as
!      provided by 'g77'.  For new code, one should consider the use of
       *note RANDOM_NUMBER:: as it implements a superior algorithm.
  
  _Standard_:
--- 16883,16901 ----
  
  File: gfortran.info,  Node: RAND,  Next: RANDOM_INIT,  Prev: RAN,  Up: Intrinsic Procedures
  
! 8.222 ‘RAND’ -- Real pseudo-random number
  =========================================
  
  _Description_:
!      ‘RAND(FLAG)’ returns a pseudo-random number from a uniform
       distribution between 0 and 1.  If FLAG is 0, the next number in the
       current sequence is returned; if FLAG is 1, the generator is
!      restarted by ‘CALL SRAND(0)’; if FLAG has any other value, it is
!      used as a new seed with ‘SRAND’.
  
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  It implements a simple modulo generator as
!      provided by ‘g77’.  For new code, one should consider the use of
       *note RANDOM_NUMBER:: as it implements a superior algorithm.
  
  _Standard_:
*************** _Class_:
*** 16905,16917 ****
       Function
  
  _Syntax_:
!      'RESULT = RAND(I)'
  
  _Arguments_:
!      I           Shall be a scalar 'INTEGER' of kind 4.
  
  _Return value_:
!      The return value is of 'REAL' type and the default kind.
  
  _Example_:
            program test_rand
--- 16905,16917 ----
       Function
  
  _Syntax_:
!      ‘RESULT = RAND(I)’
  
  _Arguments_:
!      I           Shall be a scalar ‘INTEGER’ of kind 4.
  
  _Return value_:
!      The return value is of ‘REAL’ type and the default kind.
  
  _Example_:
            program test_rand
*************** _See also_:
*** 16929,16940 ****
  
  File: gfortran.info,  Node: RANDOM_INIT,  Next: RANDOM_NUMBER,  Prev: RAND,  Up: Intrinsic Procedures
  
! 8.223 'RANDOM_INIT' -- Initialize a pseudo-random number generator
  ==================================================================
  
  _Description_:
       Initializes the state of the pseudorandom number generator used by
!      'RANDOM_NUMBER'.
  
  _Standard_:
       Fortran 2018
--- 16929,16940 ----
  
  File: gfortran.info,  Node: RANDOM_INIT,  Next: RANDOM_NUMBER,  Prev: RAND,  Up: Intrinsic Procedures
  
! 8.223 ‘RANDOM_INIT’ -- Initialize a pseudo-random number generator
  ==================================================================
  
  _Description_:
       Initializes the state of the pseudorandom number generator used by
!      ‘RANDOM_NUMBER’.
  
  _Standard_:
       Fortran 2018
*************** _Class_:
*** 16943,16968 ****
       Subroutine
  
  _Syntax_:
!      'CALL RANDOM_INIT(REPEATABLE, IMAGE_DISTINCT)'
  
  _Arguments_:
!      REPEATABLE         Shall be a scalar with a 'LOGICAL' type, and it
!                         is 'INTENT(IN)'.  If it is '.true.', the seed is
                          set to a processor-dependent value that is the
!                         same each time 'RANDOM_INIT' is called from the
                          same image.  The term "same image" means a
                          single instance of program execution.  The
                          sequence of random numbers is different for
                          repeated execution of the program.  If it is
!                         '.false.', the seed is set to a
                          processor-dependent value.
!      IMAGE_DISTINCT     Shall be a scalar with a 'LOGICAL' type, and it
!                         is 'INTENT(IN)'.  If it is '.true.', the seed is
                          set to a processor-dependent value that is
                          distinct from th seed set by a call to
!                         'RANDOM_INIT' in another image.  If it is
!                         '.false.', the seed is set to a value that does
!                         depend which image called 'RANDOM_INIT'.
  
  _Example_:
            program test_random_seed
--- 16943,16968 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL RANDOM_INIT(REPEATABLE, IMAGE_DISTINCT)’
  
  _Arguments_:
!      REPEATABLE         Shall be a scalar with a ‘LOGICAL’ type, and it
!                         is ‘INTENT(IN)’.  If it is ‘.true.’, the seed is
                          set to a processor-dependent value that is the
!                         same each time ‘RANDOM_INIT’ is called from the
                          same image.  The term "same image" means a
                          single instance of program execution.  The
                          sequence of random numbers is different for
                          repeated execution of the program.  If it is
!                         ‘.false.’, the seed is set to a
                          processor-dependent value.
!      IMAGE_DISTINCT     Shall be a scalar with a ‘LOGICAL’ type, and it
!                         is ‘INTENT(IN)’.  If it is ‘.true.’, the seed is
                          set to a processor-dependent value that is
                          distinct from th seed set by a call to
!                         ‘RANDOM_INIT’ in another image.  If it is
!                         ‘.false.’, the seed is set to a value that does
!                         depend which image called ‘RANDOM_INIT’.
  
  _Example_:
            program test_random_seed
*************** _See also_:
*** 16983,16989 ****
  
  File: gfortran.info,  Node: RANDOM_NUMBER,  Next: RANDOM_SEED,  Prev: RANDOM_INIT,  Up: Intrinsic Procedures
  
! 8.224 'RANDOM_NUMBER' -- Pseudo-random number
  =============================================
  
  _Description_:
--- 16983,16989 ----
  
  File: gfortran.info,  Node: RANDOM_NUMBER,  Next: RANDOM_SEED,  Prev: RANDOM_INIT,  Up: Intrinsic Procedures
  
! 8.224 ‘RANDOM_NUMBER’ -- Pseudo-random number
  =============================================
  
  _Description_:
*************** _Description_:
*** 16998,17004 ****
       Note that in a multi-threaded program (e.g.  using OpenMP
       directives), each thread will have its own random number state.
       For details of the seeding procedure, see the documentation for the
!      'RANDOM_SEED' intrinsic.
  
  _Standard_:
       Fortran 90 and later
--- 16998,17004 ----
       Note that in a multi-threaded program (e.g.  using OpenMP
       directives), each thread will have its own random number state.
       For details of the seeding procedure, see the documentation for the
!      ‘RANDOM_SEED’ intrinsic.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 17007,17016 ****
       Subroutine
  
  _Syntax_:
!      'CALL RANDOM_NUMBER(HARVEST)'
  
  _Arguments_:
!      HARVEST     Shall be a scalar or an array of type 'REAL'.
  
  _Example_:
            program test_random_number
--- 17007,17016 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL RANDOM_NUMBER(HARVEST)’
  
  _Arguments_:
!      HARVEST     Shall be a scalar or an array of type ‘REAL’.
  
  _Example_:
            program test_random_number
*************** _See also_:
*** 17025,17050 ****
  
  File: gfortran.info,  Node: RANDOM_SEED,  Next: RANGE,  Prev: RANDOM_NUMBER,  Up: Intrinsic Procedures
  
! 8.225 'RANDOM_SEED' -- Initialize a pseudo-random number sequence
  =================================================================
  
  _Description_:
       Restarts or queries the state of the pseudorandom number generator
!      used by 'RANDOM_NUMBER'.
  
!      If 'RANDOM_SEED' is called without arguments, it is seeded with
       random data retrieved from the operating system.
  
       As an extension to the Fortran standard, the GFortran
!      'RANDOM_NUMBER' supports multiple threads.  Each thread in a
!      multi-threaded program has its own seed.  When 'RANDOM_SEED' is
       called either without arguments or with the PUT argument, the given
       seed is copied into a master seed as well as the seed of the
!      current thread.  When a new thread uses 'RANDOM_NUMBER' for the
       first time, the seed is copied from the master seed, and forwarded
       N * 2^{128} steps to guarantee that the random stream does not
       alias any other stream in the system, where N is the number of
!      threads that have used 'RANDOM_NUMBER' so far during the program
       execution.
  
  _Standard_:
--- 17025,17050 ----
  
  File: gfortran.info,  Node: RANDOM_SEED,  Next: RANGE,  Prev: RANDOM_NUMBER,  Up: Intrinsic Procedures
  
! 8.225 ‘RANDOM_SEED’ -- Initialize a pseudo-random number sequence
  =================================================================
  
  _Description_:
       Restarts or queries the state of the pseudorandom number generator
!      used by ‘RANDOM_NUMBER’.
  
!      If ‘RANDOM_SEED’ is called without arguments, it is seeded with
       random data retrieved from the operating system.
  
       As an extension to the Fortran standard, the GFortran
!      ‘RANDOM_NUMBER’ supports multiple threads.  Each thread in a
!      multi-threaded program has its own seed.  When ‘RANDOM_SEED’ is
       called either without arguments or with the PUT argument, the given
       seed is copied into a master seed as well as the seed of the
!      current thread.  When a new thread uses ‘RANDOM_NUMBER’ for the
       first time, the seed is copied from the master seed, and forwarded
       N * 2^{128} steps to guarantee that the random stream does not
       alias any other stream in the system, where N is the number of
!      threads that have used ‘RANDOM_NUMBER’ so far during the program
       execution.
  
  _Standard_:
*************** _Class_:
*** 17054,17073 ****
       Subroutine
  
  _Syntax_:
!      'CALL RANDOM_SEED([SIZE, PUT, GET])'
  
  _Arguments_:
       SIZE        (Optional) Shall be a scalar and of type default
!                  'INTEGER', with 'INTENT(OUT)'.  It specifies the
                   minimum size of the arrays used with the PUT and
                   GET arguments.
       PUT         (Optional) Shall be an array of type default
!                  'INTEGER' and rank one.  It is 'INTENT(IN)' and
                   the size of the array must be larger than or
                   equal to the number returned by the SIZE
                   argument.
       GET         (Optional) Shall be an array of type default
!                  'INTEGER' and rank one.  It is 'INTENT(OUT)' and
                   the size of the array must be larger than or
                   equal to the number returned by the SIZE
                   argument.
--- 17054,17073 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL RANDOM_SEED([SIZE, PUT, GET])’
  
  _Arguments_:
       SIZE        (Optional) Shall be a scalar and of type default
!                  ‘INTEGER’, with ‘INTENT(OUT)’.  It specifies the
                   minimum size of the arrays used with the PUT and
                   GET arguments.
       PUT         (Optional) Shall be an array of type default
!                  ‘INTEGER’ and rank one.  It is ‘INTENT(IN)’ and
                   the size of the array must be larger than or
                   equal to the number returned by the SIZE
                   argument.
       GET         (Optional) Shall be an array of type default
!                  ‘INTEGER’ and rank one.  It is ‘INTENT(OUT)’ and
                   the size of the array must be larger than or
                   equal to the number returned by the SIZE
                   argument.
*************** _See also_:
*** 17091,17102 ****
  
  File: gfortran.info,  Node: RANGE,  Next: RANK,  Prev: RANDOM_SEED,  Up: Intrinsic Procedures
  
! 8.226 'RANGE' -- Decimal exponent range
  =======================================
  
  _Description_:
!      'RANGE(X)' returns the decimal exponent range in the model of the
!      type of 'X'.
  
  _Standard_:
       Fortran 90 and later
--- 17091,17102 ----
  
  File: gfortran.info,  Node: RANGE,  Next: RANK,  Prev: RANDOM_SEED,  Up: Intrinsic Procedures
  
! 8.226 ‘RANGE’ -- Decimal exponent range
  =======================================
  
  _Description_:
!      ‘RANGE(X)’ returns the decimal exponent range in the model of the
!      type of ‘X’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 17105,17121 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = RANGE(X)'
  
  _Arguments_:
!      X           Shall be of type 'INTEGER', 'REAL' or 'COMPLEX'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the default integer
       kind.
  
  _Example_:
!      See 'PRECISION' for an example.
  _See also_:
       *note SELECTED_REAL_KIND::,
       *note PRECISION::
--- 17105,17121 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = RANGE(X)’
  
  _Arguments_:
!      X           Shall be of type ‘INTEGER’, ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the default integer
       kind.
  
  _Example_:
!      See ‘PRECISION’ for an example.
  _See also_:
       *note SELECTED_REAL_KIND::,
       *note PRECISION::
*************** _See also_:
*** 17123,17133 ****
  
  File: gfortran.info,  Node: RANK,  Next: REAL,  Prev: RANGE,  Up: Intrinsic Procedures
  
! 8.227 'RANK' -- Rank of a data object
  =====================================
  
  _Description_:
!      'RANK(A)' returns the rank of a scalar or array data object.
  
  _Standard_:
       Technical Specification (TS) 29113
--- 17123,17133 ----
  
  File: gfortran.info,  Node: RANK,  Next: REAL,  Prev: RANGE,  Up: Intrinsic Procedures
  
! 8.227 ‘RANK’ -- Rank of a data object
  =====================================
  
  _Description_:
!      ‘RANK(A)’ returns the rank of a scalar or array data object.
  
  _Standard_:
       Technical Specification (TS) 29113
*************** _Class_:
*** 17136,17148 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = RANK(A)'
  
  _Arguments_:
       A           can be of any type
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the default integer
       kind.  For arrays, their rank is returned; for scalars zero is
       returned.
  
--- 17136,17148 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = RANK(A)’
  
  _Arguments_:
       A           can be of any type
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the default integer
       kind.  For arrays, their rank is returned; for scalars zero is
       returned.
  
*************** _Example_:
*** 17157,17168 ****
  
  File: gfortran.info,  Node: REAL,  Next: RENAME,  Prev: RANK,  Up: Intrinsic Procedures
  
! 8.228 'REAL' -- Convert to real type
  ====================================
  
  _Description_:
!      'REAL(A [, KIND])' converts its argument A to a real type.  The
!      'REALPART' function is provided for compatibility with 'g77', and
       its use is strongly discouraged.
  
  _Standard_:
--- 17157,17168 ----
  
  File: gfortran.info,  Node: REAL,  Next: RENAME,  Prev: RANK,  Up: Intrinsic Procedures
  
! 8.228 ‘REAL’ -- Convert to real type
  ====================================
  
  _Description_:
!      ‘REAL(A [, KIND])’ converts its argument A to a real type.  The
!      ‘REALPART’ function is provided for compatibility with ‘g77’, and
       its use is strongly discouraged.
  
  _Standard_:
*************** _Class_:
*** 17173,17199 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = REAL(A [, KIND])'
!      'RESULT = REALPART(Z)'
  
  _Arguments_:
!      A           Shall be 'INTEGER', 'REAL', or 'COMPLEX'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      These functions return a 'REAL' variable or array under the
       following rules:
  
       (A)
!           'REAL(A)' is converted to a default real type if A is an
            integer or real variable.
       (B)
!           'REAL(A)' is converted to a real type with the kind type
            parameter of A if A is a complex variable.
       (C)
!           'REAL(A, KIND)' is converted to a real type with kind type
            parameter KIND if A is a complex, integer, or real variable.
  
  _Example_:
--- 17173,17199 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = REAL(A [, KIND])’
!      ‘RESULT = REALPART(Z)’
  
  _Arguments_:
!      A           Shall be ‘INTEGER’, ‘REAL’, or ‘COMPLEX’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      These functions return a ‘REAL’ variable or array under the
       following rules:
  
       (A)
!           ‘REAL(A)’ is converted to a default real type if A is an
            integer or real variable.
       (B)
!           ‘REAL(A)’ is converted to a real type with the kind type
            parameter of A if A is a complex variable.
       (C)
!           ‘REAL(A, KIND)’ is converted to a real type with kind type
            parameter KIND if A is a complex, integer, or real variable.
  
  _Example_:
*************** _Example_:
*** 17205,17216 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'FLOAT(A)'     'INTEGER(4)'      'REAL(4)'      Fortran 77 and later
!      'DFLOAT(A)'    'INTEGER(4)'      'REAL(8)'      GNU extension
!      'FLOATI(A)'    'INTEGER(2)'      'REAL(4)'      GNU extension (-fdec)
!      'FLOATJ(A)'    'INTEGER(4)'      'REAL(4)'      GNU extension (-fdec)
!      'FLOATK(A)'    'INTEGER(8)'      'REAL(4)'      GNU extension (-fdec)
!      'SNGL(A)'      'REAL(8)'         'REAL(4)'      Fortran 77 and later
  
  _See also_:
       *note DBLE::
--- 17205,17216 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘FLOAT(A)’     ‘INTEGER(4)’      ‘REAL(4)’      Fortran 77 and later
!      ‘DFLOAT(A)’    ‘INTEGER(4)’      ‘REAL(8)’      GNU extension
!      ‘FLOATI(A)’    ‘INTEGER(2)’      ‘REAL(4)’      GNU extension (-fdec)
!      ‘FLOATJ(A)’    ‘INTEGER(4)’      ‘REAL(4)’      GNU extension (-fdec)
!      ‘FLOATK(A)’    ‘INTEGER(8)’      ‘REAL(4)’      GNU extension (-fdec)
!      ‘SNGL(A)’      ‘REAL(8)’         ‘REAL(4)’      Fortran 77 and later
  
  _See also_:
       *note DBLE::
*************** _See also_:
*** 17218,17232 ****
  
  File: gfortran.info,  Node: RENAME,  Next: REPEAT,  Prev: REAL,  Up: Intrinsic Procedures
  
! 8.229 'RENAME' -- Rename a file
  ===============================
  
  _Description_:
       Renames a file from file PATH1 to PATH2.  A null character
!      ('CHAR(0)') can be used to mark the end of the names in PATH1 and
       PATH2; otherwise, trailing blanks in the file names are ignored.
       If the STATUS argument is supplied, it contains 0 on success or a
!      nonzero error code upon return; see 'rename(2)'.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 17218,17232 ----
  
  File: gfortran.info,  Node: RENAME,  Next: REPEAT,  Prev: REAL,  Up: Intrinsic Procedures
  
! 8.229 ‘RENAME’ -- Rename a file
  ===============================
  
  _Description_:
       Renames a file from file PATH1 to PATH2.  A null character
!      (‘CHAR(0)’) can be used to mark the end of the names in PATH1 and
       PATH2; otherwise, trailing blanks in the file names are ignored.
       If the STATUS argument is supplied, it contains 0 on success or a
!      nonzero error code upon return; see ‘rename(2)’.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 17238,17250 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL RENAME(PATH1, PATH2 [, STATUS])'
!      'STATUS = RENAME(PATH1, PATH2)'
  
  _Arguments_:
!      PATH1       Shall be of default 'CHARACTER' type.
!      PATH2       Shall be of default 'CHARACTER' type.
!      STATUS      (Optional) Shall be of default 'INTEGER' type.
  
  _See also_:
       *note LINK::
--- 17238,17250 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL RENAME(PATH1, PATH2 [, STATUS])’
!      ‘STATUS = RENAME(PATH1, PATH2)’
  
  _Arguments_:
!      PATH1       Shall be of default ‘CHARACTER’ type.
!      PATH2       Shall be of default ‘CHARACTER’ type.
!      STATUS      (Optional) Shall be of default ‘INTEGER’ type.
  
  _See also_:
       *note LINK::
*************** _See also_:
*** 17252,17258 ****
  
  File: gfortran.info,  Node: REPEAT,  Next: RESHAPE,  Prev: RENAME,  Up: Intrinsic Procedures
  
! 8.230 'REPEAT' -- Repeated string concatenation
  ===============================================
  
  _Description_:
--- 17252,17258 ----
  
  File: gfortran.info,  Node: REPEAT,  Next: RESHAPE,  Prev: RENAME,  Up: Intrinsic Procedures
  
! 8.230 ‘REPEAT’ -- Repeated string concatenation
  ===============================================
  
  _Description_:
*************** _Class_:
*** 17265,17278 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = REPEAT(STRING, NCOPIES)'
  
  _Arguments_:
!      STRING      Shall be scalar and of type 'CHARACTER'.
!      NCOPIES     Shall be scalar and of type 'INTEGER'.
  
  _Return value_:
!      A new scalar of type 'CHARACTER' built up from NCOPIES copies of
       STRING.
  
  _Example_:
--- 17265,17278 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = REPEAT(STRING, NCOPIES)’
  
  _Arguments_:
!      STRING      Shall be scalar and of type ‘CHARACTER’.
!      NCOPIES     Shall be scalar and of type ‘INTEGER’.
  
  _Return value_:
!      A new scalar of type ‘CHARACTER’ built up from NCOPIES copies of
       STRING.
  
  _Example_:
*************** _Example_:
*** 17283,17289 ****
  
  File: gfortran.info,  Node: RESHAPE,  Next: RRSPACING,  Prev: REPEAT,  Up: Intrinsic Procedures
  
! 8.231 'RESHAPE' -- Function to reshape an array
  ===============================================
  
  _Description_:
--- 17283,17289 ----
  
  File: gfortran.info,  Node: RESHAPE,  Next: RRSPACING,  Prev: REPEAT,  Up: Intrinsic Procedures
  
! 8.231 ‘RESHAPE’ -- Function to reshape an array
  ===============================================
  
  _Description_:
*************** _Class_:
*** 17298,17312 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = RESHAPE(SOURCE, SHAPE[, PAD, ORDER])'
  
  _Arguments_:
       SOURCE      Shall be an array of any type.
!      SHAPE       Shall be of type 'INTEGER' and an array of rank
                   one.  Its values must be positive or zero.
       PAD         (Optional) shall be an array of the same type as
                   SOURCE.
!      ORDER       (Optional) shall be of type 'INTEGER' and an
                   array of the same shape as SHAPE.  Its values
                   shall be a permutation of the numbers from 1 to
                   n, where n is the size of SHAPE.  If ORDER is
--- 17298,17312 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = RESHAPE(SOURCE, SHAPE[, PAD, ORDER])’
  
  _Arguments_:
       SOURCE      Shall be an array of any type.
!      SHAPE       Shall be of type ‘INTEGER’ and an array of rank
                   one.  Its values must be positive or zero.
       PAD         (Optional) shall be an array of the same type as
                   SOURCE.
!      ORDER       (Optional) shall be of type ‘INTEGER’ and an
                   array of the same shape as SHAPE.  Its values
                   shall be a permutation of the numbers from 1 to
                   n, where n is the size of SHAPE.  If ORDER is
*************** _See also_:
*** 17328,17338 ****
  
  File: gfortran.info,  Node: RRSPACING,  Next: RSHIFT,  Prev: RESHAPE,  Up: Intrinsic Procedures
  
! 8.232 'RRSPACING' -- Reciprocal of the relative spacing
  =======================================================
  
  _Description_:
!      'RRSPACING(X)' returns the reciprocal of the relative spacing of
       model numbers near X.
  
  _Standard_:
--- 17328,17338 ----
  
  File: gfortran.info,  Node: RRSPACING,  Next: RSHIFT,  Prev: RESHAPE,  Up: Intrinsic Procedures
  
! 8.232 ‘RRSPACING’ -- Reciprocal of the relative spacing
  =======================================================
  
  _Description_:
!      ‘RRSPACING(X)’ returns the reciprocal of the relative spacing of
       model numbers near X.
  
  _Standard_:
*************** _Class_:
*** 17342,17356 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = RRSPACING(X)'
  
  _Arguments_:
!      X           Shall be of type 'REAL'.
  
  _Return value_:
       The return value is of the same type and kind as X.  The value
!      returned is equal to 'ABS(FRACTION(X)) *
!      FLOAT(RADIX(X))**DIGITS(X)'.
  
  _See also_:
       *note SPACING::
--- 17342,17356 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = RRSPACING(X)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’.
  
  _Return value_:
       The return value is of the same type and kind as X.  The value
!      returned is equal to ‘ABS(FRACTION(X)) *
!      FLOAT(RADIX(X))**DIGITS(X)’.
  
  _See also_:
       *note SPACING::
*************** _See also_:
*** 17358,17376 ****
  
  File: gfortran.info,  Node: RSHIFT,  Next: SAME_TYPE_AS,  Prev: RRSPACING,  Up: Intrinsic Procedures
  
! 8.233 'RSHIFT' -- Right shift bits
  ==================================
  
  _Description_:
!      'RSHIFT' returns a value corresponding to I with all of the bits
       shifted right by SHIFT places.  SHIFT shall be nonnegative and less
!      than or equal to 'BIT_SIZE(I)', otherwise the result value is
       undefined.  Bits shifted out from the right end are lost.  The fill
       is arithmetic: the bits shifted in from the left end are equal to
       the leftmost bit, which in two's complement representation is the
       sign bit.
  
!      This function has been superseded by the 'SHIFTA' intrinsic, which
       is standard in Fortran 2008 and later.
  
  _Standard_:
--- 17358,17376 ----
  
  File: gfortran.info,  Node: RSHIFT,  Next: SAME_TYPE_AS,  Prev: RRSPACING,  Up: Intrinsic Procedures
  
! 8.233 ‘RSHIFT’ -- Right shift bits
  ==================================
  
  _Description_:
!      ‘RSHIFT’ returns a value corresponding to I with all of the bits
       shifted right by SHIFT places.  SHIFT shall be nonnegative and less
!      than or equal to ‘BIT_SIZE(I)’, otherwise the result value is
       undefined.  Bits shifted out from the right end are lost.  The fill
       is arithmetic: the bits shifted in from the left end are equal to
       the leftmost bit, which in two's complement representation is the
       sign bit.
  
!      This function has been superseded by the ‘SHIFTA’ intrinsic, which
       is standard in Fortran 2008 and later.
  
  _Standard_:
*************** _Class_:
*** 17380,17393 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = RSHIFT(I, SHIFT)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      SHIFT       The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the same kind as I.
  
  _See also_:
       *note ISHFT::,
--- 17380,17393 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = RSHIFT(I, SHIFT)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      SHIFT       The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the same kind as I.
  
  _See also_:
       *note ISHFT::,
*************** _See also_:
*** 17400,17406 ****
  
  File: gfortran.info,  Node: SAME_TYPE_AS,  Next: SCALE,  Prev: RSHIFT,  Up: Intrinsic Procedures
  
! 8.234 'SAME_TYPE_AS' -- Query dynamic types for equality
  ========================================================
  
  _Description_:
--- 17400,17406 ----
  
  File: gfortran.info,  Node: SAME_TYPE_AS,  Next: SCALE,  Prev: RSHIFT,  Up: Intrinsic Procedures
  
! 8.234 ‘SAME_TYPE_AS’ -- Query dynamic types for equality
  ========================================================
  
  _Description_:
*************** _Class_:
*** 17413,17419 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = SAME_TYPE_AS(A, B)'
  
  _Arguments_:
       A           Shall be an object of extensible declared type
--- 17413,17419 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = SAME_TYPE_AS(A, B)’
  
  _Arguments_:
       A           Shall be an object of extensible declared type
*************** _See also_:
*** 17432,17442 ****
  
  File: gfortran.info,  Node: SCALE,  Next: SCAN,  Prev: SAME_TYPE_AS,  Up: Intrinsic Procedures
  
! 8.235 'SCALE' -- Scale a real value
  ===================================
  
  _Description_:
!      'SCALE(X,I)' returns 'X * RADIX(X)**I'.
  
  _Standard_:
       Fortran 90 and later
--- 17432,17442 ----
  
  File: gfortran.info,  Node: SCALE,  Next: SCAN,  Prev: SAME_TYPE_AS,  Up: Intrinsic Procedures
  
! 8.235 ‘SCALE’ -- Scale a real value
  ===================================
  
  _Description_:
!      ‘SCALE(X,I)’ returns ‘X * RADIX(X)**I’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 17445,17459 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SCALE(X, I)'
  
  _Arguments_:
!      X           The type of the argument shall be a 'REAL'.
!      I           The type of the argument shall be a 'INTEGER'.
  
  _Return value_:
       The return value is of the same type and kind as X.  Its value is
!      'X * RADIX(X)**I'.
  
  _Example_:
            program test_scale
--- 17445,17459 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SCALE(X, I)’
  
  _Arguments_:
!      X           The type of the argument shall be a ‘REAL’.
!      I           The type of the argument shall be a ‘INTEGER’.
  
  _Return value_:
       The return value is of the same type and kind as X.  Its value is
!      ‘X * RADIX(X)**I’.
  
  _Example_:
            program test_scale
*************** _Example_:
*** 17465,17479 ****
  
  File: gfortran.info,  Node: SCAN,  Next: SECNDS,  Prev: SCALE,  Up: Intrinsic Procedures
  
! 8.236 'SCAN' -- Scan a string for the presence of a set of characters
  =====================================================================
  
  _Description_:
       Scans a STRING for any of the characters in a SET of characters.
  
!      If BACK is either absent or equals 'FALSE', this function returns
       the position of the leftmost character of STRING that is in SET.
!      If BACK equals 'TRUE', the rightmost position is returned.  If no
       character of SET is found in STRING, the result is zero.
  
  _Standard_:
--- 17465,17479 ----
  
  File: gfortran.info,  Node: SCAN,  Next: SECNDS,  Prev: SCALE,  Up: Intrinsic Procedures
  
! 8.236 ‘SCAN’ -- Scan a string for the presence of a set of characters
  =====================================================================
  
  _Description_:
       Scans a STRING for any of the characters in a SET of characters.
  
!      If BACK is either absent or equals ‘FALSE’, this function returns
       the position of the leftmost character of STRING that is in SET.
!      If BACK equals ‘TRUE’, the rightmost position is returned.  If no
       character of SET is found in STRING, the result is zero.
  
  _Standard_:
*************** _Class_:
*** 17483,17500 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SCAN(STRING, SET[, BACK [, KIND]])'
  
  _Arguments_:
!      STRING      Shall be of type 'CHARACTER'.
!      SET         Shall be of type 'CHARACTER'.
!      BACK        (Optional) shall be of type 'LOGICAL'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Example_:
--- 17483,17500 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SCAN(STRING, SET[, BACK [, KIND]])’
  
  _Arguments_:
!      STRING      Shall be of type ‘CHARACTER’.
!      SET         Shall be of type ‘CHARACTER’.
!      BACK        (Optional) shall be of type ‘LOGICAL’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Example_:
*************** _See also_:
*** 17511,17521 ****
  
  File: gfortran.info,  Node: SECNDS,  Next: SECOND,  Prev: SCAN,  Up: Intrinsic Procedures
  
! 8.237 'SECNDS' -- Time function
  ===============================
  
  _Description_:
!      'SECNDS(X)' gets the time in seconds from the real-time system
       clock.  X is a reference time, also in seconds.  If this is zero,
       the time in seconds from midnight is returned.  This function is
       non-standard and its use is discouraged.
--- 17511,17521 ----
  
  File: gfortran.info,  Node: SECNDS,  Next: SECOND,  Prev: SCAN,  Up: Intrinsic Procedures
  
! 8.237 ‘SECNDS’ -- Time function
  ===============================
  
  _Description_:
!      ‘SECNDS(X)’ gets the time in seconds from the real-time system
       clock.  X is a reference time, also in seconds.  If this is zero,
       the time in seconds from midnight is returned.  This function is
       non-standard and its use is discouraged.
*************** _Class_:
*** 17527,17537 ****
       Function
  
  _Syntax_:
!      'RESULT = SECNDS (X)'
  
  _Arguments_:
!      T           Shall be of type 'REAL(4)'.
!      X           Shall be of type 'REAL(4)'.
  
  _Return value_:
       None
--- 17527,17537 ----
       Function
  
  _Syntax_:
!      ‘RESULT = SECNDS (X)’
  
  _Arguments_:
!      T           Shall be of type ‘REAL(4)’.
!      X           Shall be of type ‘REAL(4)’.
  
  _Return value_:
       None
*************** _Example_:
*** 17551,17563 ****
  
  File: gfortran.info,  Node: SECOND,  Next: SELECTED_CHAR_KIND,  Prev: SECNDS,  Up: Intrinsic Procedures
  
! 8.238 'SECOND' -- CPU time function
  ===================================
  
  _Description_:
!      Returns a 'REAL(4)' value representing the elapsed CPU time in
       seconds.  This provides the same functionality as the standard
!      'CPU_TIME' intrinsic, and is only included for backwards
       compatibility.
  
       This intrinsic is provided in both subroutine and function forms;
--- 17551,17563 ----
  
  File: gfortran.info,  Node: SECOND,  Next: SELECTED_CHAR_KIND,  Prev: SECNDS,  Up: Intrinsic Procedures
  
! 8.238 ‘SECOND’ -- CPU time function
  ===================================
  
  _Description_:
!      Returns a ‘REAL(4)’ value representing the elapsed CPU time in
       seconds.  This provides the same functionality as the standard
!      ‘CPU_TIME’ intrinsic, and is only included for backwards
       compatibility.
  
       This intrinsic is provided in both subroutine and function forms;
*************** _Class_:
*** 17570,17580 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL SECOND(TIME)'
!      'TIME = SECOND()'
  
  _Arguments_:
!      TIME        Shall be of type 'REAL(4)'.
  
  _Return value_:
       In either syntax, TIME is set to the process's current runtime in
--- 17570,17580 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL SECOND(TIME)’
!      ‘TIME = SECOND()’
  
  _Arguments_:
!      TIME        Shall be of type ‘REAL(4)’.
  
  _Return value_:
       In either syntax, TIME is set to the process's current runtime in
*************** _See also_:
*** 17586,17597 ****
  
  File: gfortran.info,  Node: SELECTED_CHAR_KIND,  Next: SELECTED_INT_KIND,  Prev: SECOND,  Up: Intrinsic Procedures
  
! 8.239 'SELECTED_CHAR_KIND' -- Choose character kind
  ===================================================
  
  _Description_:
  
!      'SELECTED_CHAR_KIND(NAME)' returns the kind value for the character
       set named NAME, if a character set with such a name is supported,
       or -1 otherwise.  Currently, supported character sets include
       "ASCII" and "DEFAULT", which are equivalent, and "ISO_10646"
--- 17586,17597 ----
  
  File: gfortran.info,  Node: SELECTED_CHAR_KIND,  Next: SELECTED_INT_KIND,  Prev: SECOND,  Up: Intrinsic Procedures
  
! 8.239 ‘SELECTED_CHAR_KIND’ -- Choose character kind
  ===================================================
  
  _Description_:
  
!      ‘SELECTED_CHAR_KIND(NAME)’ returns the kind value for the character
       set named NAME, if a character set with such a name is supported,
       or -1 otherwise.  Currently, supported character sets include
       "ASCII" and "DEFAULT", which are equivalent, and "ISO_10646"
*************** _Class_:
*** 17605,17611 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = SELECTED_CHAR_KIND(NAME)'
  
  _Arguments_:
       NAME        Shall be a scalar and of the default character
--- 17605,17611 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = SELECTED_CHAR_KIND(NAME)’
  
  _Arguments_:
       NAME        Shall be a scalar and of the default character
*************** _Example_:
*** 17635,17648 ****
  
  File: gfortran.info,  Node: SELECTED_INT_KIND,  Next: SELECTED_REAL_KIND,  Prev: SELECTED_CHAR_KIND,  Up: Intrinsic Procedures
  
! 8.240 'SELECTED_INT_KIND' -- Choose integer kind
  ================================================
  
  _Description_:
!      'SELECTED_INT_KIND(R)' return the kind value of the smallest
       integer type that can represent all values ranging from -10^R
       (exclusive) to 10^R (exclusive).  If there is no integer kind that
!      accommodates this range, 'SELECTED_INT_KIND' returns -1.
  
  _Standard_:
       Fortran 90 and later
--- 17635,17648 ----
  
  File: gfortran.info,  Node: SELECTED_INT_KIND,  Next: SELECTED_REAL_KIND,  Prev: SELECTED_CHAR_KIND,  Up: Intrinsic Procedures
  
! 8.240 ‘SELECTED_INT_KIND’ -- Choose integer kind
  ================================================
  
  _Description_:
!      ‘SELECTED_INT_KIND(R)’ return the kind value of the smallest
       integer type that can represent all values ranging from -10^R
       (exclusive) to 10^R (exclusive).  If there is no integer kind that
!      accommodates this range, ‘SELECTED_INT_KIND’ returns -1.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 17651,17660 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = SELECTED_INT_KIND(R)'
  
  _Arguments_:
!      R           Shall be a scalar and of type 'INTEGER'.
  
  _Example_:
            program large_integers
--- 17651,17660 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = SELECTED_INT_KIND(R)’
  
  _Arguments_:
!      R           Shall be a scalar and of type ‘INTEGER’.
  
  _Example_:
            program large_integers
*************** _Example_:
*** 17673,17726 ****
  
  File: gfortran.info,  Node: SELECTED_REAL_KIND,  Next: SET_EXPONENT,  Prev: SELECTED_INT_KIND,  Up: Intrinsic Procedures
  
! 8.241 'SELECTED_REAL_KIND' -- Choose real kind
  ==============================================
  
  _Description_:
!      'SELECTED_REAL_KIND(P,R)' returns the kind value of a real data
!      type with decimal precision of at least 'P' digits, exponent range
!      of at least 'R', and with a radix of 'RADIX'.
  
  _Standard_:
!      Fortran 90 and later, with 'RADIX' Fortran 2008 or later
  
  _Class_:
       Transformational function
  
  _Syntax_:
!      'RESULT = SELECTED_REAL_KIND([P, R, RADIX])'
  
  _Arguments_:
       P           (Optional) shall be a scalar and of type
!                  'INTEGER'.
       R           (Optional) shall be a scalar and of type
!                  'INTEGER'.
       RADIX       (Optional) shall be a scalar and of type
!                  'INTEGER'.
       Before Fortran 2008, at least one of the arguments R or P shall be
       present; since Fortran 2008, they are assumed to be zero if absent.
  
  _Return value_:
  
!      'SELECTED_REAL_KIND' returns the value of the kind type parameter
!      of a real data type with decimal precision of at least 'P' digits,
!      a decimal exponent range of at least 'R', and with the requested
!      'RADIX'.  If the 'RADIX' parameter is absent, real kinds with any
       radix can be returned.  If more than one real data type meet the
       criteria, the kind of the data type with the smallest decimal
       precision is returned.  If no real data type matches the criteria,
       the result is
       -1 if the processor does not support a real data type with a
!           precision greater than or equal to 'P', but the 'R' and
!           'RADIX' requirements can be fulfilled
       -2 if the processor does not support a real type with an exponent
!           range greater than or equal to 'R', but 'P' and 'RADIX' are
            fulfillable
!      -3 if 'RADIX' but not 'P' and 'R' requirements
            are fulfillable
!      -4 if 'RADIX' and either 'P' or 'R' requirements
            are fulfillable
!      -5 if there is no real type with the given 'RADIX'
  
  _Example_:
            program real_kinds
--- 17673,17726 ----
  
  File: gfortran.info,  Node: SELECTED_REAL_KIND,  Next: SET_EXPONENT,  Prev: SELECTED_INT_KIND,  Up: Intrinsic Procedures
  
! 8.241 ‘SELECTED_REAL_KIND’ -- Choose real kind
  ==============================================
  
  _Description_:
!      ‘SELECTED_REAL_KIND(P,R)’ returns the kind value of a real data
!      type with decimal precision of at least ‘P’ digits, exponent range
!      of at least ‘R’, and with a radix of ‘RADIX’.
  
  _Standard_:
!      Fortran 90 and later, with ‘RADIX’ Fortran 2008 or later
  
  _Class_:
       Transformational function
  
  _Syntax_:
!      ‘RESULT = SELECTED_REAL_KIND([P, R, RADIX])’
  
  _Arguments_:
       P           (Optional) shall be a scalar and of type
!                  ‘INTEGER’.
       R           (Optional) shall be a scalar and of type
!                  ‘INTEGER’.
       RADIX       (Optional) shall be a scalar and of type
!                  ‘INTEGER’.
       Before Fortran 2008, at least one of the arguments R or P shall be
       present; since Fortran 2008, they are assumed to be zero if absent.
  
  _Return value_:
  
!      ‘SELECTED_REAL_KIND’ returns the value of the kind type parameter
!      of a real data type with decimal precision of at least ‘P’ digits,
!      a decimal exponent range of at least ‘R’, and with the requested
!      ‘RADIX’.  If the ‘RADIX’ parameter is absent, real kinds with any
       radix can be returned.  If more than one real data type meet the
       criteria, the kind of the data type with the smallest decimal
       precision is returned.  If no real data type matches the criteria,
       the result is
       -1 if the processor does not support a real data type with a
!           precision greater than or equal to ‘P’, but the ‘R’ and
!           ‘RADIX’ requirements can be fulfilled
       -2 if the processor does not support a real type with an exponent
!           range greater than or equal to ‘R’, but ‘P’ and ‘RADIX’ are
            fulfillable
!      -3 if ‘RADIX’ but not ‘P’ and ‘R’ requirements
            are fulfillable
!      -4 if ‘RADIX’ and either ‘P’ or ‘R’ requirements
            are fulfillable
!      -5 if there is no real type with the given ‘RADIX’
  
  _Example_:
            program real_kinds
*************** _See also_:
*** 17743,17753 ****
  
  File: gfortran.info,  Node: SET_EXPONENT,  Next: SHAPE,  Prev: SELECTED_REAL_KIND,  Up: Intrinsic Procedures
  
! 8.242 'SET_EXPONENT' -- Set the exponent of the model
  =====================================================
  
  _Description_:
!      'SET_EXPONENT(X, I)' returns the real number whose fractional part
       is that of X and whose exponent part is I.
  
  _Standard_:
--- 17743,17753 ----
  
  File: gfortran.info,  Node: SET_EXPONENT,  Next: SHAPE,  Prev: SELECTED_REAL_KIND,  Up: Intrinsic Procedures
  
! 8.242 ‘SET_EXPONENT’ -- Set the exponent of the model
  =====================================================
  
  _Description_:
!      ‘SET_EXPONENT(X, I)’ returns the real number whose fractional part
       is that of X and whose exponent part is I.
  
  _Standard_:
*************** _Class_:
*** 17757,17772 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SET_EXPONENT(X, I)'
  
  _Arguments_:
!      X           Shall be of type 'REAL'.
!      I           Shall be of type 'INTEGER'.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real
       number whose fractional part is that of X and whose exponent part
!      if I is returned; it is 'FRACTION(X) * RADIX(X)**I'.
  
  _Example_:
            PROGRAM test_setexp
--- 17757,17772 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SET_EXPONENT(X, I)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’.
!      I           Shall be of type ‘INTEGER’.
  
  _Return value_:
       The return value is of the same type and kind as X.  The real
       number whose fractional part is that of X and whose exponent part
!      if I is returned; it is ‘FRACTION(X) * RADIX(X)**I’.
  
  _Example_:
            PROGRAM test_setexp
*************** _Example_:
*** 17778,17784 ****
  
  File: gfortran.info,  Node: SHAPE,  Next: SHIFTA,  Prev: SET_EXPONENT,  Up: Intrinsic Procedures
  
! 8.243 'SHAPE' -- Determine the shape of an array
  ================================================
  
  _Description_:
--- 17778,17784 ----
  
  File: gfortran.info,  Node: SHAPE,  Next: SHIFTA,  Prev: SET_EXPONENT,  Up: Intrinsic Procedures
  
! 8.243 ‘SHAPE’ -- Determine the shape of an array
  ================================================
  
  _Description_:
*************** _Class_:
*** 17791,17808 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = SHAPE(SOURCE [, KIND])'
  
  _Arguments_:
       SOURCE      Shall be an array or scalar of any type.  If
                   SOURCE is a pointer it must be associated and
                   allocatable arrays must be allocated.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      An 'INTEGER' array of rank one with as many elements as SOURCE has
       dimensions.  The elements of the resulting array correspond to the
       extend of SOURCE along the respective dimensions.  If SOURCE is a
       scalar, the result is the rank one array of size zero.  If KIND is
--- 17791,17808 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = SHAPE(SOURCE [, KIND])’
  
  _Arguments_:
       SOURCE      Shall be an array or scalar of any type.  If
                   SOURCE is a pointer it must be associated and
                   allocatable arrays must be allocated.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      An ‘INTEGER’ array of rank one with as many elements as SOURCE has
       dimensions.  The elements of the resulting array correspond to the
       extend of SOURCE along the respective dimensions.  If SOURCE is a
       scalar, the result is the rank one array of size zero.  If KIND is
*************** _See also_:
*** 17823,17835 ****
  
  File: gfortran.info,  Node: SHIFTA,  Next: SHIFTL,  Prev: SHAPE,  Up: Intrinsic Procedures
  
! 8.244 'SHIFTA' -- Right shift with fill
  =======================================
  
  _Description_:
!      'SHIFTA' returns a value corresponding to I with all of the bits
       shifted right by SHIFT places.  SHIFT that be nonnegative and less
!      than or equal to 'BIT_SIZE(I)', otherwise the result value is
       undefined.  Bits shifted out from the right end are lost.  The fill
       is arithmetic: the bits shifted in from the left end are equal to
       the leftmost bit, which in two's complement representation is the
--- 17823,17835 ----
  
  File: gfortran.info,  Node: SHIFTA,  Next: SHIFTL,  Prev: SHAPE,  Up: Intrinsic Procedures
  
! 8.244 ‘SHIFTA’ -- Right shift with fill
  =======================================
  
  _Description_:
!      ‘SHIFTA’ returns a value corresponding to I with all of the bits
       shifted right by SHIFT places.  SHIFT that be nonnegative and less
!      than or equal to ‘BIT_SIZE(I)’, otherwise the result value is
       undefined.  Bits shifted out from the right end are lost.  The fill
       is arithmetic: the bits shifted in from the left end are equal to
       the leftmost bit, which in two's complement representation is the
*************** _Class_:
*** 17842,17855 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SHIFTA(I, SHIFT)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      SHIFT       The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the same kind as I.
  
  _See also_:
       *note SHIFTL::,
--- 17842,17855 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SHIFTA(I, SHIFT)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      SHIFT       The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the same kind as I.
  
  _See also_:
       *note SHIFTL::,
*************** _See also_:
*** 17858,17870 ****
  
  File: gfortran.info,  Node: SHIFTL,  Next: SHIFTR,  Prev: SHIFTA,  Up: Intrinsic Procedures
  
! 8.245 'SHIFTL' -- Left shift
  ============================
  
  _Description_:
!      'SHIFTL' returns a value corresponding to I with all of the bits
       shifted left by SHIFT places.  SHIFT shall be nonnegative and less
!      than or equal to 'BIT_SIZE(I)', otherwise the result value is
       undefined.  Bits shifted out from the left end are lost, and bits
       shifted in from the right end are set to 0.
  
--- 17858,17870 ----
  
  File: gfortran.info,  Node: SHIFTL,  Next: SHIFTR,  Prev: SHIFTA,  Up: Intrinsic Procedures
  
! 8.245 ‘SHIFTL’ -- Left shift
  ============================
  
  _Description_:
!      ‘SHIFTL’ returns a value corresponding to I with all of the bits
       shifted left by SHIFT places.  SHIFT shall be nonnegative and less
!      than or equal to ‘BIT_SIZE(I)’, otherwise the result value is
       undefined.  Bits shifted out from the left end are lost, and bits
       shifted in from the right end are set to 0.
  
*************** _Class_:
*** 17875,17888 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SHIFTL(I, SHIFT)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      SHIFT       The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the same kind as I.
  
  _See also_:
       *note SHIFTA::,
--- 17875,17888 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SHIFTL(I, SHIFT)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      SHIFT       The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the same kind as I.
  
  _See also_:
       *note SHIFTA::,
*************** _See also_:
*** 17891,17903 ****
  
  File: gfortran.info,  Node: SHIFTR,  Next: SIGN,  Prev: SHIFTL,  Up: Intrinsic Procedures
  
! 8.246 'SHIFTR' -- Right shift
  =============================
  
  _Description_:
!      'SHIFTR' returns a value corresponding to I with all of the bits
       shifted right by SHIFT places.  SHIFT shall be nonnegative and less
!      than or equal to 'BIT_SIZE(I)', otherwise the result value is
       undefined.  Bits shifted out from the right end are lost, and bits
       shifted in from the left end are set to 0.
  
--- 17891,17903 ----
  
  File: gfortran.info,  Node: SHIFTR,  Next: SIGN,  Prev: SHIFTL,  Up: Intrinsic Procedures
  
! 8.246 ‘SHIFTR’ -- Right shift
  =============================
  
  _Description_:
!      ‘SHIFTR’ returns a value corresponding to I with all of the bits
       shifted right by SHIFT places.  SHIFT shall be nonnegative and less
!      than or equal to ‘BIT_SIZE(I)’, otherwise the result value is
       undefined.  Bits shifted out from the right end are lost, and bits
       shifted in from the left end are set to 0.
  
*************** _Class_:
*** 17908,17921 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SHIFTR(I, SHIFT)'
  
  _Arguments_:
!      I           The type shall be 'INTEGER'.
!      SHIFT       The type shall be 'INTEGER'.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of the same kind as I.
  
  _See also_:
       *note SHIFTA::,
--- 17908,17921 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SHIFTR(I, SHIFT)’
  
  _Arguments_:
!      I           The type shall be ‘INTEGER’.
!      SHIFT       The type shall be ‘INTEGER’.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of the same kind as I.
  
  _See also_:
       *note SHIFTA::,
*************** _See also_:
*** 17924,17934 ****
  
  File: gfortran.info,  Node: SIGN,  Next: SIGNAL,  Prev: SHIFTR,  Up: Intrinsic Procedures
  
! 8.247 'SIGN' -- Sign copying function
  =====================================
  
  _Description_:
!      'SIGN(A,B)' returns the value of A with the sign of B.
  
  _Standard_:
       Fortran 77 and later
--- 17924,17934 ----
  
  File: gfortran.info,  Node: SIGN,  Next: SIGNAL,  Prev: SHIFTR,  Up: Intrinsic Procedures
  
! 8.247 ‘SIGN’ -- Sign copying function
  =====================================
  
  _Description_:
!      ‘SIGN(A,B)’ returns the value of A with the sign of B.
  
  _Standard_:
       Fortran 77 and later
*************** _Class_:
*** 17937,17951 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SIGN(A, B)'
  
  _Arguments_:
!      A           Shall be of type 'INTEGER' or 'REAL'
       B           Shall be of the same type and kind as A.
  
  _Return value_:
       The kind of the return value is that of A and B.  If B \ge 0 then
!      the result is 'ABS(A)', else it is '-ABS(A)'.
  
  _Example_:
            program test_sign
--- 17937,17951 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SIGN(A, B)’
  
  _Arguments_:
!      A           Shall be of type ‘INTEGER’ or ‘REAL’
       B           Shall be of the same type and kind as A.
  
  _Return value_:
       The kind of the return value is that of A and B.  If B \ge 0 then
!      the result is ‘ABS(A)’, else it is ‘-ABS(A)’.
  
  _Example_:
            program test_sign
*************** _Example_:
*** 17961,17985 ****
  _Specific names_:
       Name           Arguments           Return type    Standard
       -------------------------------------------------------------------------
!      'SIGN(A,B)'    'REAL(4) A, B'      'REAL(4)'      Fortran 77 and later
!      'ISIGN(A,B)'   'INTEGER(4) A, B'   'INTEGER(4)'   Fortran 77 and later
!      'DSIGN(A,B)'   'REAL(8) A, B'      'REAL(8)'      Fortran 77 and later
  
  
  File: gfortran.info,  Node: SIGNAL,  Next: SIN,  Prev: SIGN,  Up: Intrinsic Procedures
  
! 8.248 'SIGNAL' -- Signal handling subroutine (or function)
  ==========================================================
  
  _Description_:
!      'SIGNAL(NUMBER, HANDLER [, STATUS])' causes external subroutine
       HANDLER to be executed with a single integer argument when signal
       NUMBER occurs.  If HANDLER is an integer, it can be used to turn
       off handling of signal NUMBER or revert to its default action.  See
!      'signal(2)'.
  
!      If 'SIGNAL' is called as a subroutine and the STATUS argument is
!      supplied, it is set to the value returned by 'signal(2)'.
  
  _Standard_:
       GNU extension
--- 17961,17985 ----
  _Specific names_:
       Name           Arguments           Return type    Standard
       -------------------------------------------------------------------------
!      ‘SIGN(A,B)’    ‘REAL(4) A, B’      ‘REAL(4)’      Fortran 77 and later
!      ‘ISIGN(A,B)’   ‘INTEGER(4) A, B’   ‘INTEGER(4)’   Fortran 77 and later
!      ‘DSIGN(A,B)’   ‘REAL(8) A, B’      ‘REAL(8)’      Fortran 77 and later
  
  
  File: gfortran.info,  Node: SIGNAL,  Next: SIN,  Prev: SIGN,  Up: Intrinsic Procedures
  
! 8.248 ‘SIGNAL’ -- Signal handling subroutine (or function)
  ==========================================================
  
  _Description_:
!      ‘SIGNAL(NUMBER, HANDLER [, STATUS])’ causes external subroutine
       HANDLER to be executed with a single integer argument when signal
       NUMBER occurs.  If HANDLER is an integer, it can be used to turn
       off handling of signal NUMBER or revert to its default action.  See
!      ‘signal(2)’.
  
!      If ‘SIGNAL’ is called as a subroutine and the STATUS argument is
!      supplied, it is set to the value returned by ‘signal(2)’.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 17988,18006 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL SIGNAL(NUMBER, HANDLER [, STATUS])'
!      'STATUS = SIGNAL(NUMBER, HANDLER)'
  
  _Arguments_:
!      NUMBER      Shall be a scalar integer, with 'INTENT(IN)'
!      HANDLER     Signal handler ('INTEGER FUNCTION' or
!                  'SUBROUTINE') or dummy/global 'INTEGER' scalar.
!                  'INTEGER'.  It is 'INTENT(IN)'.
       STATUS      (Optional) STATUS shall be a scalar integer.  It
!                  has 'INTENT(OUT)'.
  
  _Return value_:
!      The 'SIGNAL' function returns the value returned by 'signal(2)'.
  
  _Example_:
            program test_signal
--- 17988,18006 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL SIGNAL(NUMBER, HANDLER [, STATUS])’
!      ‘STATUS = SIGNAL(NUMBER, HANDLER)’
  
  _Arguments_:
!      NUMBER      Shall be a scalar integer, with ‘INTENT(IN)’
!      HANDLER     Signal handler (‘INTEGER FUNCTION’ or
!                  ‘SUBROUTINE’) or dummy/global ‘INTEGER’ scalar.
!                  ‘INTEGER’.  It is ‘INTENT(IN)’.
       STATUS      (Optional) STATUS shall be a scalar integer.  It
!                  has ‘INTENT(OUT)’.
  
  _Return value_:
!      The ‘SIGNAL’ function returns the value returned by ‘signal(2)’.
  
  _Example_:
            program test_signal
*************** _Example_:
*** 18016,18026 ****
  
  File: gfortran.info,  Node: SIN,  Next: SIND,  Prev: SIGNAL,  Up: Intrinsic Procedures
  
! 8.249 'SIN' -- Sine function
  ============================
  
  _Description_:
!      'SIN(X)' computes the sine of X.
  
  _Standard_:
       Fortran 77 and later
--- 18016,18026 ----
  
  File: gfortran.info,  Node: SIN,  Next: SIND,  Prev: SIGNAL,  Up: Intrinsic Procedures
  
! 8.249 ‘SIN’ -- Sine function
  ============================
  
  _Description_:
!      ‘SIN(X)’ computes the sine of X.
  
  _Standard_:
       Fortran 77 and later
*************** _Class_:
*** 18029,18038 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SIN(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X.
--- 18029,18038 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SIN(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X.
*************** _Example_:
*** 18046,18056 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'SIN(X)'       'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DSIN(X)'      'REAL(8) X'       'REAL(8)'      Fortran 77 and later
!      'CSIN(X)'      'COMPLEX(4) X'    'COMPLEX(4)'   Fortran 77 and later
!      'ZSIN(X)'      'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
!      'CDSIN(X)'     'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
  
  _See also_:
       Inverse function:
--- 18046,18056 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘SIN(X)’       ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DSIN(X)’      ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
!      ‘CSIN(X)’      ‘COMPLEX(4) X’    ‘COMPLEX(4)’   Fortran 77 and later
!      ‘ZSIN(X)’      ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
!      ‘CDSIN(X)’     ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 18061,18086 ****
  
  File: gfortran.info,  Node: SIND,  Next: SINH,  Prev: SIN,  Up: Intrinsic Procedures
  
! 8.250 'SIND' -- Sine function, degrees
  ======================================
  
  _Description_:
!      'SIND(X)' computes the sine of X in degrees.
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with '-fdec-math'.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      'RESULT = SIND(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X, and its value is in
--- 18061,18086 ----
  
  File: gfortran.info,  Node: SIND,  Next: SINH,  Prev: SIN,  Up: Intrinsic Procedures
  
! 8.250 ‘SIND’ -- Sine function, degrees
  ======================================
  
  _Description_:
!      ‘SIND(X)’ computes the sine of X in degrees.
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with ‘-fdec-math’.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SIND(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X, and its value is in
*************** _Example_:
*** 18095,18105 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'SIND(X)'      'REAL(4) X'       'REAL(4)'      GNU extension
!      'DSIND(X)'     'REAL(8) X'       'REAL(8)'      GNU extension
!      'CSIND(X)'     'COMPLEX(4) X'    'COMPLEX(4)'   GNU extension
!      'ZSIND(X)'     'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
!      'CDSIND(X)'    'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
  
  _See also_:
       Inverse function:
--- 18095,18105 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘SIND(X)’      ‘REAL(4) X’       ‘REAL(4)’      GNU extension
!      ‘DSIND(X)’     ‘REAL(8) X’       ‘REAL(8)’      GNU extension
!      ‘CSIND(X)’     ‘COMPLEX(4) X’    ‘COMPLEX(4)’   GNU extension
!      ‘ZSIND(X)’     ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
!      ‘CDSIND(X)’    ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 18110,18120 ****
  
  File: gfortran.info,  Node: SINH,  Next: SIZE,  Prev: SIND,  Up: Intrinsic Procedures
  
! 8.251 'SINH' -- Hyperbolic sine function
  ========================================
  
  _Description_:
!      'SINH(X)' computes the hyperbolic sine of X.
  
  _Standard_:
       Fortran 90 and later, for a complex argument Fortran 2008 or later,
--- 18110,18120 ----
  
  File: gfortran.info,  Node: SINH,  Next: SIZE,  Prev: SIND,  Up: Intrinsic Procedures
  
! 8.251 ‘SINH’ -- Hyperbolic sine function
  ========================================
  
  _Description_:
!      ‘SINH(X)’ computes the hyperbolic sine of X.
  
  _Standard_:
       Fortran 90 and later, for a complex argument Fortran 2008 or later,
*************** _Class_:
*** 18124,18133 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SINH(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X.
--- 18124,18133 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SINH(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X.
*************** _Example_:
*** 18141,18147 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'DSINH(X)'     'REAL(8) X'       'REAL(8)'      Fortran 90 and later
  
  _See also_:
       *note ASINH::
--- 18141,18147 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘DSINH(X)’     ‘REAL(8) X’       ‘REAL(8)’      Fortran 90 and later
  
  _See also_:
       *note ASINH::
*************** _See also_:
*** 18149,18155 ****
  
  File: gfortran.info,  Node: SIZE,  Next: SIZEOF,  Prev: SINH,  Up: Intrinsic Procedures
  
! 8.252 'SIZE' -- Determine the size of an array
  ==============================================
  
  _Description_:
--- 18149,18155 ----
  
  File: gfortran.info,  Node: SIZE,  Next: SIZEOF,  Prev: SINH,  Up: Intrinsic Procedures
  
! 8.252 ‘SIZE’ -- Determine the size of an array
  ==============================================
  
  _Description_:
*************** _Class_:
*** 18163,18183 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = SIZE(ARRAY[, DIM [, KIND]])'
  
  _Arguments_:
       ARRAY       Shall be an array of any type.  If ARRAY is a
                   pointer it must be associated and allocatable
                   arrays must be allocated.
!      DIM         (Optional) shall be a scalar of type 'INTEGER'
                   and its value shall be in the range from 1 to n,
                   where n equals the rank of ARRAY.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Example_:
--- 18163,18183 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = SIZE(ARRAY[, DIM [, KIND]])’
  
  _Arguments_:
       ARRAY       Shall be an array of any type.  If ARRAY is a
                   pointer it must be associated and allocatable
                   arrays must be allocated.
!      DIM         (Optional) shall be a scalar of type ‘INTEGER’
                   and its value shall be in the range from 1 to n,
                   where n equals the rank of ARRAY.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Example_:
*************** _See also_:
*** 18192,18203 ****
  
  File: gfortran.info,  Node: SIZEOF,  Next: SLEEP,  Prev: SIZE,  Up: Intrinsic Procedures
  
! 8.253 'SIZEOF' -- Size in bytes of an expression
  ================================================
  
  _Description_:
!      'SIZEOF(X)' calculates the number of bytes of storage the
!      expression 'X' occupies.
  
  _Standard_:
       GNU extension
--- 18192,18203 ----
  
  File: gfortran.info,  Node: SIZEOF,  Next: SLEEP,  Prev: SIZE,  Up: Intrinsic Procedures
  
! 8.253 ‘SIZEOF’ -- Size in bytes of an expression
  ================================================
  
  _Description_:
!      ‘SIZEOF(X)’ calculates the number of bytes of storage the
!      expression ‘X’ occupies.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 18206,18212 ****
       Inquiry function
  
  _Syntax_:
!      'N = SIZEOF(X)'
  
  _Arguments_:
       X           The argument shall be of any type, rank or
--- 18206,18212 ----
       Inquiry function
  
  _Syntax_:
!      ‘N = SIZEOF(X)’
  
  _Arguments_:
       X           The argument shall be of any type, rank or
*************** _Return value_:
*** 18216,18224 ****
       The return value is of type integer and of the system-dependent
       kind C_SIZE_T (from the ISO_C_BINDING module).  Its value is the
       number of bytes occupied by the argument.  If the argument has the
!      'POINTER' attribute, the number of bytes of the storage area
       pointed to is returned.  If the argument is of a derived type with
!      'POINTER' or 'ALLOCATABLE' components, the return value does not
       account for the sizes of the data pointed to by these components.
       If the argument is polymorphic, the size according to the dynamic
       type is returned.  The argument may not be a procedure or procedure
--- 18216,18224 ----
       The return value is of type integer and of the system-dependent
       kind C_SIZE_T (from the ISO_C_BINDING module).  Its value is the
       number of bytes occupied by the argument.  If the argument has the
!      ‘POINTER’ attribute, the number of bytes of the storage area
       pointed to is returned.  If the argument is of a derived type with
!      ‘POINTER’ or ‘ALLOCATABLE’ components, the return value does not
       account for the sizes of the data pointed to by these components.
       If the argument is polymorphic, the size according to the dynamic
       type is returned.  The argument may not be a procedure or procedure
*************** _Example_:
*** 18231,18238 ****
               real :: r, s(5)
               print *, (sizeof(s)/sizeof(r) == 5)
               end
!      The example will print '.TRUE.' unless you are using a platform
!      where default 'REAL' variables are unusually padded.
  
  _See also_:
       *note C_SIZEOF::,
--- 18231,18238 ----
               real :: r, s(5)
               print *, (sizeof(s)/sizeof(r) == 5)
               end
!      The example will print ‘.TRUE.’ unless you are using a platform
!      where default ‘REAL’ variables are unusually padded.
  
  _See also_:
       *note C_SIZEOF::,
*************** _See also_:
*** 18241,18247 ****
  
  File: gfortran.info,  Node: SLEEP,  Next: SPACING,  Prev: SIZEOF,  Up: Intrinsic Procedures
  
! 8.254 'SLEEP' -- Sleep for the specified number of seconds
  ==========================================================
  
  _Description_:
--- 18241,18247 ----
  
  File: gfortran.info,  Node: SLEEP,  Next: SPACING,  Prev: SIZEOF,  Up: Intrinsic Procedures
  
! 8.254 ‘SLEEP’ -- Sleep for the specified number of seconds
  ==========================================================
  
  _Description_:
*************** _Class_:
*** 18255,18264 ****
       Subroutine
  
  _Syntax_:
!      'CALL SLEEP(SECONDS)'
  
  _Arguments_:
!      SECONDS     The type shall be of default 'INTEGER'.
  
  _Example_:
            program test_sleep
--- 18255,18264 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL SLEEP(SECONDS)’
  
  _Arguments_:
!      SECONDS     The type shall be of default ‘INTEGER’.
  
  _Example_:
            program test_sleep
*************** _Example_:
*** 18268,18274 ****
  
  File: gfortran.info,  Node: SPACING,  Next: SPREAD,  Prev: SLEEP,  Up: Intrinsic Procedures
  
! 8.255 'SPACING' -- Smallest distance between two numbers of a given type
  ========================================================================
  
  _Description_:
--- 18268,18274 ----
  
  File: gfortran.info,  Node: SPACING,  Next: SPREAD,  Prev: SLEEP,  Up: Intrinsic Procedures
  
! 8.255 ‘SPACING’ -- Smallest distance between two numbers of a given type
  ========================================================================
  
  _Description_:
*************** _Class_:
*** 18282,18291 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SPACING(X)'
  
  _Arguments_:
!      X           Shall be of type 'REAL'.
  
  _Return value_:
       The result is of the same type as the input argument X.
--- 18282,18291 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SPACING(X)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’.
  
  _Return value_:
       The result is of the same type as the input argument X.
*************** _See also_:
*** 18305,18311 ****
  
  File: gfortran.info,  Node: SPREAD,  Next: SQRT,  Prev: SPACING,  Up: Intrinsic Procedures
  
! 8.256 'SPREAD' -- Add a dimension to an array
  =============================================
  
  _Description_:
--- 18305,18311 ----
  
  File: gfortran.info,  Node: SPREAD,  Next: SQRT,  Prev: SPACING,  Up: Intrinsic Procedures
  
! 8.256 ‘SPREAD’ -- Add a dimension to an array
  =============================================
  
  _Description_:
*************** _Class_:
*** 18319,18333 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = SPREAD(SOURCE, DIM, NCOPIES)'
  
  _Arguments_:
       SOURCE      Shall be a scalar or an array of any type and a
                   rank less than seven.
!      DIM         Shall be a scalar of type 'INTEGER' with a value
                   in the range from 1 to n+1, where n equals the
                   rank of SOURCE.
!      NCOPIES     Shall be a scalar of type 'INTEGER'.
  
  _Return value_:
       The result is an array of the same type as SOURCE and has rank n+1
--- 18319,18333 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = SPREAD(SOURCE, DIM, NCOPIES)’
  
  _Arguments_:
       SOURCE      Shall be a scalar or an array of any type and a
                   rank less than seven.
!      DIM         Shall be a scalar of type ‘INTEGER’ with a value
                   in the range from 1 to n+1, where n equals the
                   rank of SOURCE.
!      NCOPIES     Shall be a scalar of type ‘INTEGER’.
  
  _Return value_:
       The result is an array of the same type as SOURCE and has rank n+1
*************** _See also_:
*** 18346,18356 ****
  
  File: gfortran.info,  Node: SQRT,  Next: SRAND,  Prev: SPREAD,  Up: Intrinsic Procedures
  
! 8.257 'SQRT' -- Square-root function
  ====================================
  
  _Description_:
!      'SQRT(X)' computes the square root of X.
  
  _Standard_:
       Fortran 77 and later
--- 18346,18356 ----
  
  File: gfortran.info,  Node: SQRT,  Next: SRAND,  Prev: SPREAD,  Up: Intrinsic Procedures
  
! 8.257 ‘SQRT’ -- Square-root function
  ====================================
  
  _Description_:
!      ‘SQRT(X)’ computes the square root of X.
  
  _Standard_:
       Fortran 77 and later
*************** _Class_:
*** 18359,18371 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = SQRT(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
!      The return value is of type 'REAL' or 'COMPLEX'.  The kind type
       parameter is the same as X.
  
  _Example_:
--- 18359,18371 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = SQRT(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
!      The return value is of type ‘REAL’ or ‘COMPLEX’.  The kind type
       parameter is the same as X.
  
  _Example_:
*************** _Example_:
*** 18379,18399 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'SQRT(X)'      'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DSQRT(X)'     'REAL(8) X'       'REAL(8)'      Fortran 77 and later
!      'CSQRT(X)'     'COMPLEX(4) X'    'COMPLEX(4)'   Fortran 77 and later
!      'ZSQRT(X)'     'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
!      'CDSQRT(X)'    'COMPLEX(8) X'    'COMPLEX(8)'   GNU extension
  
  
  File: gfortran.info,  Node: SRAND,  Next: STAT,  Prev: SQRT,  Up: Intrinsic Procedures
  
! 8.258 'SRAND' -- Reinitialize the random number generator
  =========================================================
  
  _Description_:
!      'SRAND' reinitializes the pseudo-random number generator called by
!      'RAND' and 'IRAND'.  The new seed used by the generator is
       specified by the required argument SEED.
  
  _Standard_:
--- 18379,18399 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘SQRT(X)’      ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DSQRT(X)’     ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
!      ‘CSQRT(X)’     ‘COMPLEX(4) X’    ‘COMPLEX(4)’   Fortran 77 and later
!      ‘ZSQRT(X)’     ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
!      ‘CDSQRT(X)’    ‘COMPLEX(8) X’    ‘COMPLEX(8)’   GNU extension
  
  
  File: gfortran.info,  Node: SRAND,  Next: STAT,  Prev: SQRT,  Up: Intrinsic Procedures
  
! 8.258 ‘SRAND’ -- Reinitialize the random number generator
  =========================================================
  
  _Description_:
!      ‘SRAND’ reinitializes the pseudo-random number generator called by
!      ‘RAND’ and ‘IRAND’.  The new seed used by the generator is
       specified by the required argument SEED.
  
  _Standard_:
*************** _Class_:
*** 18403,18428 ****
       Subroutine
  
  _Syntax_:
!      'CALL SRAND(SEED)'
  
  _Arguments_:
!      SEED        Shall be a scalar 'INTEGER(kind=4)'.
  
  _Return value_:
       Does not return anything.
  
  _Example_:
!      See 'RAND' and 'IRAND' for examples.
  
  _Notes_:
       The Fortran standard specifies the intrinsic subroutines
!      'RANDOM_SEED' to initialize the pseudo-random number generator and
!      'RANDOM_NUMBER' to generate pseudo-random numbers.  These
       subroutines should be used in new codes.
  
       Please note that in GNU Fortran, these two sets of intrinsics
!      ('RAND', 'IRAND' and 'SRAND' on the one hand, 'RANDOM_NUMBER' and
!      'RANDOM_SEED' on the other hand) access two independent
       pseudo-random number generators.
  
  _See also_:
--- 18403,18428 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL SRAND(SEED)’
  
  _Arguments_:
!      SEED        Shall be a scalar ‘INTEGER(kind=4)’.
  
  _Return value_:
       Does not return anything.
  
  _Example_:
!      See ‘RAND’ and ‘IRAND’ for examples.
  
  _Notes_:
       The Fortran standard specifies the intrinsic subroutines
!      ‘RANDOM_SEED’ to initialize the pseudo-random number generator and
!      ‘RANDOM_NUMBER’ to generate pseudo-random numbers.  These
       subroutines should be used in new codes.
  
       Please note that in GNU Fortran, these two sets of intrinsics
!      (‘RAND’, ‘IRAND’ and ‘SRAND’ on the one hand, ‘RANDOM_NUMBER’ and
!      ‘RANDOM_SEED’ on the other hand) access two independent
       pseudo-random number generators.
  
  _See also_:
*************** _See also_:
*** 18433,18439 ****
  
  File: gfortran.info,  Node: STAT,  Next: STORAGE_SIZE,  Prev: SRAND,  Up: Intrinsic Procedures
  
! 8.259 'STAT' -- Get file status
  ===============================
  
  _Description_:
--- 18433,18439 ----
  
  File: gfortran.info,  Node: STAT,  Next: STORAGE_SIZE,  Prev: SRAND,  Up: Intrinsic Procedures
  
! 8.259 ‘STAT’ -- Get file status
  ===============================
  
  _Description_:
*************** _Description_:
*** 18441,18461 ****
       required on the file itself, but execute (search) permission is
       required on all of the directories in path that lead to the file.
  
!      The elements that are obtained and stored in the array 'VALUES':
!      'VALUES(1)' Device ID
!      'VALUES(2)' Inode number
!      'VALUES(3)' File mode
!      'VALUES(4)' Number of links
!      'VALUES(5)' Owner's uid
!      'VALUES(6)' Owner's gid
!      'VALUES(7)' ID of device containing directory entry for file
                   (0 if not available)
!      'VALUES(8)' File size (bytes)
!      'VALUES(9)' Last access time
!      'VALUES(10)'Last modification time
!      'VALUES(11)'Last file status change time
!      'VALUES(12)'Preferred I/O block size (-1 if not available)
!      'VALUES(13)'Number of blocks allocated (-1 if not available)
  
       Not all these elements are relevant on all systems.  If an element
       is not relevant, it is returned as 0.
--- 18441,18461 ----
       required on the file itself, but execute (search) permission is
       required on all of the directories in path that lead to the file.
  
!      The elements that are obtained and stored in the array ‘VALUES’:
!      ‘VALUES(1)’ Device ID
!      ‘VALUES(2)’ Inode number
!      ‘VALUES(3)’ File mode
!      ‘VALUES(4)’ Number of links
!      ‘VALUES(5)’ Owner's uid
!      ‘VALUES(6)’ Owner's gid
!      ‘VALUES(7)’ ID of device containing directory entry for file
                   (0 if not available)
!      ‘VALUES(8)’ File size (bytes)
!      ‘VALUES(9)’ Last access time
!      ‘VALUES(10)’Last modification time
!      ‘VALUES(11)’Last file status change time
!      ‘VALUES(12)’Preferred I/O block size (-1 if not available)
!      ‘VALUES(13)’Number of blocks allocated (-1 if not available)
  
       Not all these elements are relevant on all systems.  If an element
       is not relevant, it is returned as 0.
*************** _Class_:
*** 18470,18483 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL STAT(NAME, VALUES [, STATUS])'
!      'STATUS = STAT(NAME, VALUES)'
  
  _Arguments_:
!      NAME        The type shall be 'CHARACTER', of the default
                   kind and a valid path within the file system.
!      VALUES      The type shall be 'INTEGER(4), DIMENSION(13)'.
!      STATUS      (Optional) status flag of type 'INTEGER(4)'.
                   Returns 0 on success and a system specific error
                   code otherwise.
  
--- 18470,18483 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL STAT(NAME, VALUES [, STATUS])’
!      ‘STATUS = STAT(NAME, VALUES)’
  
  _Arguments_:
!      NAME        The type shall be ‘CHARACTER’, of the default
                   kind and a valid path within the file system.
!      VALUES      The type shall be ‘INTEGER(4), DIMENSION(13)’.
!      STATUS      (Optional) status flag of type ‘INTEGER(4)’.
                   Returns 0 on success and a system specific error
                   code otherwise.
  
*************** _See also_:
*** 18514,18520 ****
  
  File: gfortran.info,  Node: STORAGE_SIZE,  Next: SUM,  Prev: STAT,  Up: Intrinsic Procedures
  
! 8.260 'STORAGE_SIZE' -- Storage size in bits
  ============================================
  
  _Description_:
--- 18514,18520 ----
  
  File: gfortran.info,  Node: STORAGE_SIZE,  Next: SUM,  Prev: STAT,  Up: Intrinsic Procedures
  
! 8.260 ‘STORAGE_SIZE’ -- Storage size in bits
  ============================================
  
  _Description_:
*************** _Standard_:
*** 18524,18530 ****
  _Class_:
       Inquiry function
  _Syntax_:
!      'RESULT = STORAGE_SIZE(A [, KIND])'
  
  _Arguments_:
       A           Shall be a scalar or array of any type.
--- 18524,18530 ----
  _Class_:
       Inquiry function
  _Syntax_:
!      ‘RESULT = STORAGE_SIZE(A [, KIND])’
  
  _Arguments_:
       A           Shall be a scalar or array of any type.
*************** _See also_:
*** 18544,18555 ****
  
  File: gfortran.info,  Node: SUM,  Next: SYMLNK,  Prev: STORAGE_SIZE,  Up: Intrinsic Procedures
  
! 8.261 'SUM' -- Sum of array elements
  ====================================
  
  _Description_:
       Adds the elements of ARRAY along dimension DIM if the corresponding
!      element in MASK is 'TRUE'.
  
  _Standard_:
       Fortran 90 and later
--- 18544,18555 ----
  
  File: gfortran.info,  Node: SUM,  Next: SYMLNK,  Prev: STORAGE_SIZE,  Up: Intrinsic Procedures
  
! 8.261 ‘SUM’ -- Sum of array elements
  ====================================
  
  _Description_:
       Adds the elements of ARRAY along dimension DIM if the corresponding
!      element in MASK is ‘TRUE’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 18558,18573 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = SUM(ARRAY[, MASK])'
!      'RESULT = SUM(ARRAY, DIM[, MASK])'
  
  _Arguments_:
!      ARRAY       Shall be an array of type 'INTEGER', 'REAL' or
!                  'COMPLEX'.
!      DIM         (Optional) shall be a scalar of type 'INTEGER'
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
!      MASK        (Optional) shall be of type 'LOGICAL' and either
                   be a scalar or an array of the same shape as
                   ARRAY.
  
--- 18558,18573 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = SUM(ARRAY[, MASK])’
!      ‘RESULT = SUM(ARRAY, DIM[, MASK])’
  
  _Arguments_:
!      ARRAY       Shall be an array of type ‘INTEGER’, ‘REAL’ or
!                  ‘COMPLEX’.
!      DIM         (Optional) shall be a scalar of type ‘INTEGER’
                   with a value in the range from 1 to n, where n
                   equals the rank of ARRAY.
!      MASK        (Optional) shall be of type ‘LOGICAL’ and either
                   be a scalar or an array of the same shape as
                   ARRAY.
  
*************** _See also_:
*** 18592,18607 ****
  
  File: gfortran.info,  Node: SYMLNK,  Next: SYSTEM,  Prev: SUM,  Up: Intrinsic Procedures
  
! 8.262 'SYMLNK' -- Create a symbolic link
  ========================================
  
  _Description_:
       Makes a symbolic link from file PATH1 to PATH2.  A null character
!      ('CHAR(0)') can be used to mark the end of the names in PATH1 and
       PATH2; otherwise, trailing blanks in the file names are ignored.
       If the STATUS argument is supplied, it contains 0 on success or a
!      nonzero error code upon return; see 'symlink(2)'.  If the system
!      does not supply 'symlink(2)', 'ENOSYS' is returned.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 18592,18607 ----
  
  File: gfortran.info,  Node: SYMLNK,  Next: SYSTEM,  Prev: SUM,  Up: Intrinsic Procedures
  
! 8.262 ‘SYMLNK’ -- Create a symbolic link
  ========================================
  
  _Description_:
       Makes a symbolic link from file PATH1 to PATH2.  A null character
!      (‘CHAR(0)’) can be used to mark the end of the names in PATH1 and
       PATH2; otherwise, trailing blanks in the file names are ignored.
       If the STATUS argument is supplied, it contains 0 on success or a
!      nonzero error code upon return; see ‘symlink(2)’.  If the system
!      does not supply ‘symlink(2)’, ‘ENOSYS’ is returned.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 18613,18625 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL SYMLNK(PATH1, PATH2 [, STATUS])'
!      'STATUS = SYMLNK(PATH1, PATH2)'
  
  _Arguments_:
!      PATH1       Shall be of default 'CHARACTER' type.
!      PATH2       Shall be of default 'CHARACTER' type.
!      STATUS      (Optional) Shall be of default 'INTEGER' type.
  
  _See also_:
       *note LINK::,
--- 18613,18625 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL SYMLNK(PATH1, PATH2 [, STATUS])’
!      ‘STATUS = SYMLNK(PATH1, PATH2)’
  
  _Arguments_:
!      PATH1       Shall be of default ‘CHARACTER’ type.
!      PATH2       Shall be of default ‘CHARACTER’ type.
!      STATUS      (Optional) Shall be of default ‘INTEGER’ type.
  
  _See also_:
       *note LINK::,
*************** _See also_:
*** 18628,18648 ****
  
  File: gfortran.info,  Node: SYSTEM,  Next: SYSTEM_CLOCK,  Prev: SYMLNK,  Up: Intrinsic Procedures
  
! 8.263 'SYSTEM' -- Execute a shell command
  =========================================
  
  _Description_:
!      Passes the command COMMAND to a shell (see 'system(3)').  If
       argument STATUS is present, it contains the value returned by
!      'system(3)', which is presumably 0 if the shell command succeeded.
       Note that which shell is used to invoke the command is
       system-dependent and environment-dependent.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      Note that the 'system' function need not be thread-safe.  It is the
!      responsibility of the user to ensure that 'system' is not called
       concurrently.
  
  _Standard_:
--- 18628,18648 ----
  
  File: gfortran.info,  Node: SYSTEM,  Next: SYSTEM_CLOCK,  Prev: SYMLNK,  Up: Intrinsic Procedures
  
! 8.263 ‘SYSTEM’ -- Execute a shell command
  =========================================
  
  _Description_:
!      Passes the command COMMAND to a shell (see ‘system(3)’).  If
       argument STATUS is present, it contains the value returned by
!      ‘system(3)’, which is presumably 0 if the shell command succeeded.
       Note that which shell is used to invoke the command is
       system-dependent and environment-dependent.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
  
!      Note that the ‘system’ function need not be thread-safe.  It is the
!      responsibility of the user to ensure that ‘system’ is not called
       concurrently.
  
  _Standard_:
*************** _Class_:
*** 18652,18663 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL SYSTEM(COMMAND [, STATUS])'
!      'STATUS = SYSTEM(COMMAND)'
  
  _Arguments_:
!      COMMAND     Shall be of default 'CHARACTER' type.
!      STATUS      (Optional) Shall be of default 'INTEGER' type.
  
  _See also_:
       *note EXECUTE_COMMAND_LINE::, which is part of the Fortran 2008
--- 18652,18663 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL SYSTEM(COMMAND [, STATUS])’
!      ‘STATUS = SYSTEM(COMMAND)’
  
  _Arguments_:
!      COMMAND     Shall be of default ‘CHARACTER’ type.
!      STATUS      (Optional) Shall be of default ‘INTEGER’ type.
  
  _See also_:
       *note EXECUTE_COMMAND_LINE::, which is part of the Fortran 2008
*************** _See also_:
*** 18666,18672 ****
  
  File: gfortran.info,  Node: SYSTEM_CLOCK,  Next: TAN,  Prev: SYSTEM,  Up: Intrinsic Procedures
  
! 8.264 'SYSTEM_CLOCK' -- Time function
  =====================================
  
  _Description_:
--- 18666,18672 ----
  
  File: gfortran.info,  Node: SYSTEM_CLOCK,  Next: TAN,  Prev: SYSTEM,  Up: Intrinsic Procedures
  
! 8.264 ‘SYSTEM_CLOCK’ -- Time function
  =====================================
  
  _Description_:
*************** _Description_:
*** 18683,18706 ****
       kinds), COUNT represents milliseconds, while for KIND=8 arguments
       (and larger integer kinds), COUNT typically represents micro- or
       nanoseconds depending on resolution of the underlying platform
!      clock.  COUNT_MAX usually equals 'HUGE(COUNT_MAX)'.  Note that the
       millisecond resolution of the KIND=4 version implies that the COUNT
       will wrap around in roughly 25 days.  In order to avoid issues with
       the wrap around and for more precise timing, please use the KIND=8
       version.
  
       If there is no clock, or querying the clock fails, COUNT is set to
!      '-HUGE(COUNT)', and COUNT_RATE and COUNT_MAX are set to zero.
  
       When running on a platform using the GNU C library (glibc) version
       2.16 or older, or a derivative thereof, the high resolution
       monotonic clock is available only when linking with the RT library.
!      This can be done explicitly by adding the '-lrt' flag when linking
       the application, but is also done implicitly when using OpenMP.
  
       On the Windows platform, the version with KIND=4 arguments uses the
!      'GetTickCount' function, whereas the KIND=8 version uses
!      'QueryPerformanceCounter' and 'QueryPerformanceCounterFrequency'.
       For more information, and potential caveats, please see the
       platform documentation.
  
--- 18683,18706 ----
       kinds), COUNT represents milliseconds, while for KIND=8 arguments
       (and larger integer kinds), COUNT typically represents micro- or
       nanoseconds depending on resolution of the underlying platform
!      clock.  COUNT_MAX usually equals ‘HUGE(COUNT_MAX)’.  Note that the
       millisecond resolution of the KIND=4 version implies that the COUNT
       will wrap around in roughly 25 days.  In order to avoid issues with
       the wrap around and for more precise timing, please use the KIND=8
       version.
  
       If there is no clock, or querying the clock fails, COUNT is set to
!      ‘-HUGE(COUNT)’, and COUNT_RATE and COUNT_MAX are set to zero.
  
       When running on a platform using the GNU C library (glibc) version
       2.16 or older, or a derivative thereof, the high resolution
       monotonic clock is available only when linking with the RT library.
!      This can be done explicitly by adding the ‘-lrt’ flag when linking
       the application, but is also done implicitly when using OpenMP.
  
       On the Windows platform, the version with KIND=4 arguments uses the
!      ‘GetTickCount’ function, whereas the KIND=8 version uses
!      ‘QueryPerformanceCounter’ and ‘QueryPerformanceCounterFrequency’.
       For more information, and potential caveats, please see the
       platform documentation.
  
*************** _Class_:
*** 18711,18725 ****
       Subroutine
  
  _Syntax_:
!      'CALL SYSTEM_CLOCK([COUNT, COUNT_RATE, COUNT_MAX])'
  
  _Arguments_:
       COUNT          (Optional) shall be a scalar of type
!                     'INTEGER' with 'INTENT(OUT)'.
       COUNT_RATE     (Optional) shall be a scalar of type
!                     'INTEGER' or 'REAL', with 'INTENT(OUT)'.
       COUNT_MAX      (Optional) shall be a scalar of type
!                     'INTEGER' with 'INTENT(OUT)'.
  
  _Example_:
            PROGRAM test_system_clock
--- 18711,18725 ----
       Subroutine
  
  _Syntax_:
!      ‘CALL SYSTEM_CLOCK([COUNT, COUNT_RATE, COUNT_MAX])’
  
  _Arguments_:
       COUNT          (Optional) shall be a scalar of type
!                     ‘INTEGER’ with ‘INTENT(OUT)’.
       COUNT_RATE     (Optional) shall be a scalar of type
!                     ‘INTEGER’ or ‘REAL’, with ‘INTENT(OUT)’.
       COUNT_MAX      (Optional) shall be a scalar of type
!                     ‘INTEGER’ with ‘INTENT(OUT)’.
  
  _Example_:
            PROGRAM test_system_clock
*************** _See also_:
*** 18735,18745 ****
  
  File: gfortran.info,  Node: TAN,  Next: TAND,  Prev: SYSTEM_CLOCK,  Up: Intrinsic Procedures
  
! 8.265 'TAN' -- Tangent function
  ===============================
  
  _Description_:
!      'TAN(X)' computes the tangent of X.
  
  _Standard_:
       Fortran 77 and later, for a complex argument Fortran 2008 or later
--- 18735,18745 ----
  
  File: gfortran.info,  Node: TAN,  Next: TAND,  Prev: SYSTEM_CLOCK,  Up: Intrinsic Procedures
  
! 8.265 ‘TAN’ -- Tangent function
  ===============================
  
  _Description_:
!      ‘TAN(X)’ computes the tangent of X.
  
  _Standard_:
       Fortran 77 and later, for a complex argument Fortran 2008 or later
*************** _Class_:
*** 18748,18757 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = TAN(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X, and its value is in
--- 18748,18757 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = TAN(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X, and its value is in
*************** _Example_:
*** 18766,18773 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'TAN(X)'       'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DTAN(X)'      'REAL(8) X'       'REAL(8)'      Fortran 77 and later
  
  _See also_:
       Inverse function:
--- 18766,18773 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘TAN(X)’       ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DTAN(X)’      ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 18778,18803 ****
  
  File: gfortran.info,  Node: TAND,  Next: TANH,  Prev: TAN,  Up: Intrinsic Procedures
  
! 8.266 'TAND' -- Tangent function, degrees
  =========================================
  
  _Description_:
!      'TAND(X)' computes the tangent of X in degrees.
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with '-fdec-math'.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      'RESULT = TAND(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X, and its value is in
--- 18778,18803 ----
  
  File: gfortran.info,  Node: TAND,  Next: TANH,  Prev: TAN,  Up: Intrinsic Procedures
  
! 8.266 ‘TAND’ -- Tangent function, degrees
  =========================================
  
  _Description_:
!      ‘TAND(X)’ computes the tangent of X in degrees.
  
       This function is for compatibility only and should be avoided in
       favor of standard constructs wherever possible.
  
  _Standard_:
!      GNU extension, enabled with ‘-fdec-math’.
  
  _Class_:
       Elemental function
  
  _Syntax_:
!      ‘RESULT = TAND(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X, and its value is in
*************** _Example_:
*** 18812,18819 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'TAND(X)'      'REAL(4) X'       'REAL(4)'      GNU extension
!      'DTAND(X)'     'REAL(8) X'       'REAL(8)'      GNU extension
  
  _See also_:
       Inverse function:
--- 18812,18819 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘TAND(X)’      ‘REAL(4) X’       ‘REAL(4)’      GNU extension
!      ‘DTAND(X)’     ‘REAL(8) X’       ‘REAL(8)’      GNU extension
  
  _See also_:
       Inverse function:
*************** _See also_:
*** 18824,18834 ****
  
  File: gfortran.info,  Node: TANH,  Next: THIS_IMAGE,  Prev: TAND,  Up: Intrinsic Procedures
  
! 8.267 'TANH' -- Hyperbolic tangent function
  ===========================================
  
  _Description_:
!      'TANH(X)' computes the hyperbolic tangent of X.
  
  _Standard_:
       Fortran 77 and later, for a complex argument Fortran 2008 or later
--- 18824,18834 ----
  
  File: gfortran.info,  Node: TANH,  Next: THIS_IMAGE,  Prev: TAND,  Up: Intrinsic Procedures
  
! 8.267 ‘TANH’ -- Hyperbolic tangent function
  ===========================================
  
  _Description_:
!      ‘TANH(X)’ computes the hyperbolic tangent of X.
  
  _Standard_:
       Fortran 77 and later, for a complex argument Fortran 2008 or later
*************** _Class_:
*** 18837,18850 ****
       Elemental function
  
  _Syntax_:
!      'X = TANH(X)'
  
  _Arguments_:
!      X           The type shall be 'REAL' or 'COMPLEX'.
  
  _Return value_:
       The return value has same type and kind as X.  If X is complex, the
!      imaginary part of the result is in radians.  If X is 'REAL', the
       return value lies in the range - 1 \leq tanh(x) \leq 1 .
  
  _Example_:
--- 18837,18850 ----
       Elemental function
  
  _Syntax_:
!      ‘X = TANH(X)’
  
  _Arguments_:
!      X           The type shall be ‘REAL’ or ‘COMPLEX’.
  
  _Return value_:
       The return value has same type and kind as X.  If X is complex, the
!      imaginary part of the result is in radians.  If X is ‘REAL’, the
       return value lies in the range - 1 \leq tanh(x) \leq 1 .
  
  _Example_:
*************** _Example_:
*** 18856,18863 ****
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      'TANH(X)'      'REAL(4) X'       'REAL(4)'      Fortran 77 and later
!      'DTANH(X)'     'REAL(8) X'       'REAL(8)'      Fortran 77 and later
  
  _See also_:
       *note ATANH::
--- 18856,18863 ----
  _Specific names_:
       Name           Argument          Return type    Standard
       -------------------------------------------------------------------------
!      ‘TANH(X)’      ‘REAL(4) X’       ‘REAL(4)’      Fortran 77 and later
!      ‘DTANH(X)’     ‘REAL(8) X’       ‘REAL(8)’      Fortran 77 and later
  
  _See also_:
       *note ATANH::
*************** _See also_:
*** 18865,18871 ****
  
  File: gfortran.info,  Node: THIS_IMAGE,  Next: TIME,  Prev: TANH,  Up: Intrinsic Procedures
  
! 8.268 'THIS_IMAGE' -- Function that returns the cosubscript index of this image
  ===============================================================================
  
  _Description_:
--- 18865,18871 ----
  
  File: gfortran.info,  Node: THIS_IMAGE,  Next: TIME,  Prev: TANH,  Up: Intrinsic Procedures
  
! 8.268 ‘THIS_IMAGE’ -- Function that returns the cosubscript index of this image
  ===============================================================================
  
  _Description_:
*************** _Class_:
*** 18879,18887 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = THIS_IMAGE()'
!      'RESULT = THIS_IMAGE(DISTANCE)'
!      'RESULT = THIS_IMAGE(COARRAY [, DIM])'
  
  _Arguments_:
       DISTANCE    (optional, intent(in)) Nonnegative scalar
--- 18879,18887 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = THIS_IMAGE()’
!      ‘RESULT = THIS_IMAGE(DISTANCE)’
!      ‘RESULT = THIS_IMAGE(COARRAY [, DIM])’
  
  _Arguments_:
       DISTANCE    (optional, intent(in)) Nonnegative scalar
*************** _Return value_:
*** 18904,18910 ****
       rank-1 array with corank elements is returned, containing the
       cosubscripts for COARRAY specifying the invoking image.  If DIM is
       present, a scalar is returned, with the value of the DIM element of
!      'THIS_IMAGE(COARRAY)'.
  
  _Example_:
            INTEGER :: value[*]
--- 18904,18910 ----
       rank-1 array with corank elements is returned, containing the
       cosubscripts for COARRAY specifying the invoking image.  If DIM is
       present, a scalar is returned, with the value of the DIM element of
!      ‘THIS_IMAGE(COARRAY)’.
  
  _Example_:
            INTEGER :: value[*]
*************** _See also_:
*** 18928,18944 ****
  
  File: gfortran.info,  Node: TIME,  Next: TIME8,  Prev: THIS_IMAGE,  Up: Intrinsic Procedures
  
! 8.269 'TIME' -- Time function
  =============================
  
  _Description_:
       Returns the current time encoded as an integer (in the manner of
!      the function 'time(3)' in the C standard library).  This value is
       suitable for passing to *note CTIME::, *note GMTIME::, and *note
       LTIME::.
  
       This intrinsic is not fully portable, such as to systems with
!      32-bit 'INTEGER' types but supporting times wider than 32 bits.
       Therefore, the values returned by this intrinsic might be, or
       become, negative, or numerically less than previous values, during
       a single run of the compiled program.
--- 18928,18944 ----
  
  File: gfortran.info,  Node: TIME,  Next: TIME8,  Prev: THIS_IMAGE,  Up: Intrinsic Procedures
  
! 8.269 ‘TIME’ -- Time function
  =============================
  
  _Description_:
       Returns the current time encoded as an integer (in the manner of
!      the function ‘time(3)’ in the C standard library).  This value is
       suitable for passing to *note CTIME::, *note GMTIME::, and *note
       LTIME::.
  
       This intrinsic is not fully portable, such as to systems with
!      32-bit ‘INTEGER’ types but supporting times wider than 32 bits.
       Therefore, the values returned by this intrinsic might be, or
       become, negative, or numerically less than previous values, during
       a single run of the compiled program.
*************** _Class_:
*** 18954,18963 ****
       Function
  
  _Syntax_:
!      'RESULT = TIME()'
  
  _Return value_:
!      The return value is a scalar of type 'INTEGER(4)'.
  
  _See also_:
       *note DATE_AND_TIME::,
--- 18954,18963 ----
       Function
  
  _Syntax_:
!      ‘RESULT = TIME()’
  
  _Return value_:
!      The return value is a scalar of type ‘INTEGER(4)’.
  
  _See also_:
       *note DATE_AND_TIME::,
*************** _See also_:
*** 18970,18988 ****
  
  File: gfortran.info,  Node: TIME8,  Next: TINY,  Prev: TIME,  Up: Intrinsic Procedures
  
! 8.270 'TIME8' -- Time function (64-bit)
  =======================================
  
  _Description_:
       Returns the current time encoded as an integer (in the manner of
!      the function 'time(3)' in the C standard library).  This value is
       suitable for passing to *note CTIME::, *note GMTIME::, and *note
       LTIME::.
  
       _Warning:_ this intrinsic does not increase the range of the timing
!      values over that returned by 'time(3)'.  On a system with a 32-bit
!      'time(3)', 'TIME8' will return a 32-bit value, even though it is
!      converted to a 64-bit 'INTEGER(8)' value.  That means overflows of
       the 32-bit value can still occur.  Therefore, the values returned
       by this intrinsic might be or become negative or numerically less
       than previous values during a single run of the compiled program.
--- 18970,18988 ----
  
  File: gfortran.info,  Node: TIME8,  Next: TINY,  Prev: TIME,  Up: Intrinsic Procedures
  
! 8.270 ‘TIME8’ -- Time function (64-bit)
  =======================================
  
  _Description_:
       Returns the current time encoded as an integer (in the manner of
!      the function ‘time(3)’ in the C standard library).  This value is
       suitable for passing to *note CTIME::, *note GMTIME::, and *note
       LTIME::.
  
       _Warning:_ this intrinsic does not increase the range of the timing
!      values over that returned by ‘time(3)’.  On a system with a 32-bit
!      ‘time(3)’, ‘TIME8’ will return a 32-bit value, even though it is
!      converted to a 64-bit ‘INTEGER(8)’ value.  That means overflows of
       the 32-bit value can still occur.  Therefore, the values returned
       by this intrinsic might be or become negative or numerically less
       than previous values during a single run of the compiled program.
*************** _Class_:
*** 18994,19003 ****
       Function
  
  _Syntax_:
!      'RESULT = TIME8()'
  
  _Return value_:
!      The return value is a scalar of type 'INTEGER(8)'.
  
  _See also_:
       *note DATE_AND_TIME::,
--- 18994,19003 ----
       Function
  
  _Syntax_:
!      ‘RESULT = TIME8()’
  
  _Return value_:
!      The return value is a scalar of type ‘INTEGER(8)’.
  
  _See also_:
       *note DATE_AND_TIME::,
*************** _See also_:
*** 19010,19021 ****
  
  File: gfortran.info,  Node: TINY,  Next: TRAILZ,  Prev: TIME8,  Up: Intrinsic Procedures
  
! 8.271 'TINY' -- Smallest positive number of a real kind
  =======================================================
  
  _Description_:
!      'TINY(X)' returns the smallest positive (non zero) number in the
!      model of the type of 'X'.
  
  _Standard_:
       Fortran 90 and later
--- 19010,19021 ----
  
  File: gfortran.info,  Node: TINY,  Next: TRAILZ,  Prev: TIME8,  Up: Intrinsic Procedures
  
! 8.271 ‘TINY’ -- Smallest positive number of a real kind
  =======================================================
  
  _Description_:
!      ‘TINY(X)’ returns the smallest positive (non zero) number in the
!      model of the type of ‘X’.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 19024,19048 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = TINY(X)'
  
  _Arguments_:
!      X           Shall be of type 'REAL'.
  
  _Return value_:
       The return value is of the same type and kind as X
  
  _Example_:
!      See 'HUGE' for an example.
  
  
  File: gfortran.info,  Node: TRAILZ,  Next: TRANSFER,  Prev: TINY,  Up: Intrinsic Procedures
  
! 8.272 'TRAILZ' -- Number of trailing zero bits of an integer
  ============================================================
  
  _Description_:
!      'TRAILZ' returns the number of trailing zero bits of an integer.
  
  _Standard_:
       Fortran 2008 and later
--- 19024,19048 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = TINY(X)’
  
  _Arguments_:
!      X           Shall be of type ‘REAL’.
  
  _Return value_:
       The return value is of the same type and kind as X
  
  _Example_:
!      See ‘HUGE’ for an example.
  
  
  File: gfortran.info,  Node: TRAILZ,  Next: TRANSFER,  Prev: TINY,  Up: Intrinsic Procedures
  
! 8.272 ‘TRAILZ’ -- Number of trailing zero bits of an integer
  ============================================================
  
  _Description_:
!      ‘TRAILZ’ returns the number of trailing zero bits of an integer.
  
  _Standard_:
       Fortran 2008 and later
*************** _Class_:
*** 19051,19064 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = TRAILZ(I)'
  
  _Arguments_:
!      I           Shall be of type 'INTEGER'.
  
  _Return value_:
!      The type of the return value is the default 'INTEGER'.  If all the
!      bits of 'I' are zero, the result value is 'BIT_SIZE(I)'.
  
  _Example_:
            PROGRAM test_trailz
--- 19051,19064 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = TRAILZ(I)’
  
  _Arguments_:
!      I           Shall be of type ‘INTEGER’.
  
  _Return value_:
!      The type of the return value is the default ‘INTEGER’.  If all the
!      bits of ‘I’ are zero, the result value is ‘BIT_SIZE(I)’.
  
  _Example_:
            PROGRAM test_trailz
*************** _See also_:
*** 19074,19080 ****
  
  File: gfortran.info,  Node: TRANSFER,  Next: TRANSPOSE,  Prev: TRAILZ,  Up: Intrinsic Procedures
  
! 8.273 'TRANSFER' -- Transfer bit patterns
  =========================================
  
  _Description_:
--- 19074,19080 ----
  
  File: gfortran.info,  Node: TRANSFER,  Next: TRANSPOSE,  Prev: TRAILZ,  Up: Intrinsic Procedures
  
! 8.273 ‘TRANSFER’ -- Transfer bit patterns
  =========================================
  
  _Description_:
*************** _Class_:
*** 19092,19103 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = TRANSFER(SOURCE, MOLD[, SIZE])'
  
  _Arguments_:
       SOURCE      Shall be a scalar or an array of any type.
       MOLD        Shall be a scalar or an array of any type.
!      SIZE        (Optional) shall be a scalar of type 'INTEGER'.
  
  _Return value_:
       The result has the same type as MOLD, with the bit level
--- 19092,19103 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = TRANSFER(SOURCE, MOLD[, SIZE])’
  
  _Arguments_:
       SOURCE      Shall be a scalar or an array of any type.
       MOLD        Shall be a scalar or an array of any type.
!      SIZE        (Optional) shall be a scalar of type ‘INTEGER’.
  
  _Return value_:
       The result has the same type as MOLD, with the bit level
*************** _Return value_:
*** 19116,19123 ****
       valid representation of a variable of the same type as MOLD, the
       results are undefined, and subsequent operations on the result
       cannot be guaranteed to produce sensible behavior.  For example, it
!      is possible to create 'LOGICAL' variables for which 'VAR' and
!      '.NOT.VAR' both appear to be true.
  
  _Example_:
            PROGRAM test_transfer
--- 19116,19123 ----
       valid representation of a variable of the same type as MOLD, the
       results are undefined, and subsequent operations on the result
       cannot be guaranteed to produce sensible behavior.  For example, it
!      is possible to create ‘LOGICAL’ variables for which ‘VAR’ and
!      ‘.NOT.VAR’ both appear to be true.
  
  _Example_:
            PROGRAM test_transfer
*************** _Example_:
*** 19128,19139 ****
  
  File: gfortran.info,  Node: TRANSPOSE,  Next: TRIM,  Prev: TRANSFER,  Up: Intrinsic Procedures
  
! 8.274 'TRANSPOSE' -- Transpose an array of rank two
  ===================================================
  
  _Description_:
       Transpose an array of rank two.  Element (i, j) of the result has
!      the value 'MATRIX(j, i)', for all i, j.
  
  _Standard_:
       Fortran 90 and later
--- 19128,19139 ----
  
  File: gfortran.info,  Node: TRANSPOSE,  Next: TRIM,  Prev: TRANSFER,  Up: Intrinsic Procedures
  
! 8.274 ‘TRANSPOSE’ -- Transpose an array of rank two
  ===================================================
  
  _Description_:
       Transpose an array of rank two.  Element (i, j) of the result has
!      the value ‘MATRIX(j, i)’, for all i, j.
  
  _Standard_:
       Fortran 90 and later
*************** _Class_:
*** 19142,19161 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = TRANSPOSE(MATRIX)'
  
  _Arguments_:
       MATRIX      Shall be an array of any type and have a rank of
                   two.
  
  _Return value_:
!      The result has the same type as MATRIX, and has shape '(/ m, n /)'
!      if MATRIX has shape '(/ n, m /)'.
  
  
  File: gfortran.info,  Node: TRIM,  Next: TTYNAM,  Prev: TRANSPOSE,  Up: Intrinsic Procedures
  
! 8.275 'TRIM' -- Remove trailing blank characters of a string
  ============================================================
  
  _Description_:
--- 19142,19161 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = TRANSPOSE(MATRIX)’
  
  _Arguments_:
       MATRIX      Shall be an array of any type and have a rank of
                   two.
  
  _Return value_:
!      The result has the same type as MATRIX, and has shape ‘(/ m, n /)’
!      if MATRIX has shape ‘(/ n, m /)’.
  
  
  File: gfortran.info,  Node: TRIM,  Next: TTYNAM,  Prev: TRANSPOSE,  Up: Intrinsic Procedures
  
! 8.275 ‘TRIM’ -- Remove trailing blank characters of a string
  ============================================================
  
  _Description_:
*************** _Class_:
*** 19168,19180 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = TRIM(STRING)'
  
  _Arguments_:
!      STRING      Shall be a scalar of type 'CHARACTER'.
  
  _Return value_:
!      A scalar of type 'CHARACTER' which length is that of STRING less
       the number of trailing blanks.
  
  _Example_:
--- 19168,19180 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = TRIM(STRING)’
  
  _Arguments_:
!      STRING      Shall be a scalar of type ‘CHARACTER’.
  
  _Return value_:
!      A scalar of type ‘CHARACTER’ which length is that of STRING less
       the number of trailing blanks.
  
  _Example_:
*************** _See also_:
*** 19190,19201 ****
  
  File: gfortran.info,  Node: TTYNAM,  Next: UBOUND,  Prev: TRIM,  Up: Intrinsic Procedures
  
! 8.276 'TTYNAM' -- Get the name of a terminal device
  ===================================================
  
  _Description_:
       Get the name of a terminal device.  For more information, see
!      'ttyname(3)'.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 19190,19201 ----
  
  File: gfortran.info,  Node: TTYNAM,  Next: UBOUND,  Prev: TRIM,  Up: Intrinsic Procedures
  
! 8.276 ‘TTYNAM’ -- Get the name of a terminal device
  ===================================================
  
  _Description_:
       Get the name of a terminal device.  For more information, see
!      ‘ttyname(3)’.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 19207,19218 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL TTYNAM(UNIT, NAME)'
!      'NAME = TTYNAM(UNIT)'
  
  _Arguments_:
!      UNIT        Shall be a scalar 'INTEGER'.
!      NAME        Shall be of type 'CHARACTER'.
  
  _Example_:
            PROGRAM test_ttynam
--- 19207,19218 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL TTYNAM(UNIT, NAME)’
!      ‘NAME = TTYNAM(UNIT)’
  
  _Arguments_:
!      UNIT        Shall be a scalar ‘INTEGER’.
!      NAME        Shall be of type ‘CHARACTER’.
  
  _Example_:
            PROGRAM test_ttynam
*************** _See also_:
*** 19228,19234 ****
  
  File: gfortran.info,  Node: UBOUND,  Next: UCOBOUND,  Prev: TTYNAM,  Up: Intrinsic Procedures
  
! 8.277 'UBOUND' -- Upper dimension bounds of an array
  ====================================================
  
  _Description_:
--- 19228,19234 ----
  
  File: gfortran.info,  Node: UBOUND,  Next: UCOBOUND,  Prev: TTYNAM,  Up: Intrinsic Procedures
  
! 8.277 ‘UBOUND’ -- Upper dimension bounds of an array
  ====================================================
  
  _Description_:
*************** _Class_:
*** 19241,19257 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = UBOUND(ARRAY [, DIM [, KIND]])'
  
  _Arguments_:
       ARRAY       Shall be an array, of any type.
!      DIM         (Optional) Shall be a scalar 'INTEGER'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.  If DIM is
       absent, the result is an array of the upper bounds of ARRAY.  If
       DIM is present, the result is a scalar corresponding to the upper
--- 19241,19257 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = UBOUND(ARRAY [, DIM [, KIND]])’
  
  _Arguments_:
       ARRAY       Shall be an array, of any type.
!      DIM         (Optional) Shall be a scalar ‘INTEGER’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.  If DIM is
       absent, the result is an array of the upper bounds of ARRAY.  If
       DIM is present, the result is a scalar corresponding to the upper
*************** _See also_:
*** 19267,19273 ****
  
  File: gfortran.info,  Node: UCOBOUND,  Next: UMASK,  Prev: UBOUND,  Up: Intrinsic Procedures
  
! 8.278 'UCOBOUND' -- Upper codimension bounds of an array
  ========================================================
  
  _Description_:
--- 19267,19273 ----
  
  File: gfortran.info,  Node: UCOBOUND,  Next: UMASK,  Prev: UBOUND,  Up: Intrinsic Procedures
  
! 8.278 ‘UCOBOUND’ -- Upper codimension bounds of an array
  ========================================================
  
  _Description_:
*************** _Class_:
*** 19280,19296 ****
       Inquiry function
  
  _Syntax_:
!      'RESULT = UCOBOUND(COARRAY [, DIM [, KIND]])'
  
  _Arguments_:
       ARRAY       Shall be an coarray, of any type.
!      DIM         (Optional) Shall be a scalar 'INTEGER'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.  If DIM is
       absent, the result is an array of the lower cobounds of COARRAY.
       If DIM is present, the result is a scalar corresponding to the
--- 19280,19296 ----
       Inquiry function
  
  _Syntax_:
!      ‘RESULT = UCOBOUND(COARRAY [, DIM [, KIND]])’
  
  _Arguments_:
       ARRAY       Shall be an coarray, of any type.
!      DIM         (Optional) Shall be a scalar ‘INTEGER’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.  If DIM is
       absent, the result is an array of the lower cobounds of COARRAY.
       If DIM is present, the result is a scalar corresponding to the
*************** _See also_:
*** 19303,19315 ****
  
  File: gfortran.info,  Node: UMASK,  Next: UNLINK,  Prev: UCOBOUND,  Up: Intrinsic Procedures
  
! 8.279 'UMASK' -- Set the file creation mask
  ===========================================
  
  _Description_:
       Sets the file creation mask to MASK.  If called as a function, it
       returns the old value.  If called as a subroutine and argument OLD
!      if it is supplied, it is set to the old value.  See 'umask(2)'.
  
  _Standard_:
       GNU extension
--- 19303,19315 ----
  
  File: gfortran.info,  Node: UMASK,  Next: UNLINK,  Prev: UCOBOUND,  Up: Intrinsic Procedures
  
! 8.279 ‘UMASK’ -- Set the file creation mask
  ===========================================
  
  _Description_:
       Sets the file creation mask to MASK.  If called as a function, it
       returns the old value.  If called as a subroutine and argument OLD
!      if it is supplied, it is set to the old value.  See ‘umask(2)’.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 19318,19342 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL UMASK(MASK [, OLD])'
!      'OLD = UMASK(MASK)'
  
  _Arguments_:
!      MASK        Shall be a scalar of type 'INTEGER'.
!      OLD         (Optional) Shall be a scalar of type 'INTEGER'.
  
  
  File: gfortran.info,  Node: UNLINK,  Next: UNPACK,  Prev: UMASK,  Up: Intrinsic Procedures
  
! 8.280 'UNLINK' -- Remove a file from the file system
  ====================================================
  
  _Description_:
!      Unlinks the file PATH.  A null character ('CHAR(0)') can be used to
       mark the end of the name in PATH; otherwise, trailing blanks in the
       file name are ignored.  If the STATUS argument is supplied, it
       contains 0 on success or a nonzero error code upon return; see
!      'unlink(2)'.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
--- 19318,19342 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL UMASK(MASK [, OLD])’
!      ‘OLD = UMASK(MASK)’
  
  _Arguments_:
!      MASK        Shall be a scalar of type ‘INTEGER’.
!      OLD         (Optional) Shall be a scalar of type ‘INTEGER’.
  
  
  File: gfortran.info,  Node: UNLINK,  Next: UNPACK,  Prev: UMASK,  Up: Intrinsic Procedures
  
! 8.280 ‘UNLINK’ -- Remove a file from the file system
  ====================================================
  
  _Description_:
!      Unlinks the file PATH.  A null character (‘CHAR(0)’) can be used to
       mark the end of the name in PATH; otherwise, trailing blanks in the
       file name are ignored.  If the STATUS argument is supplied, it
       contains 0 on success or a nonzero error code upon return; see
!      ‘unlink(2)’.
  
       This intrinsic is provided in both subroutine and function forms;
       however, only one form can be used in any given program unit.
*************** _Class_:
*** 19348,19359 ****
       Subroutine, function
  
  _Syntax_:
!      'CALL UNLINK(PATH [, STATUS])'
!      'STATUS = UNLINK(PATH)'
  
  _Arguments_:
!      PATH        Shall be of default 'CHARACTER' type.
!      STATUS      (Optional) Shall be of default 'INTEGER' type.
  
  _See also_:
       *note LINK::,
--- 19348,19359 ----
       Subroutine, function
  
  _Syntax_:
!      ‘CALL UNLINK(PATH [, STATUS])’
!      ‘STATUS = UNLINK(PATH)’
  
  _Arguments_:
!      PATH        Shall be of default ‘CHARACTER’ type.
!      STATUS      (Optional) Shall be of default ‘INTEGER’ type.
  
  _See also_:
       *note LINK::,
*************** _See also_:
*** 19362,19368 ****
  
  File: gfortran.info,  Node: UNPACK,  Next: VERIFY,  Prev: UNLINK,  Up: Intrinsic Procedures
  
! 8.281 'UNPACK' -- Unpack an array of rank one into an array
  ===========================================================
  
  _Description_:
--- 19362,19368 ----
  
  File: gfortran.info,  Node: UNPACK,  Next: VERIFY,  Prev: UNLINK,  Up: Intrinsic Procedures
  
! 8.281 ‘UNPACK’ -- Unpack an array of rank one into an array
  ===========================================================
  
  _Description_:
*************** _Class_:
*** 19375,19392 ****
       Transformational function
  
  _Syntax_:
!      'RESULT = UNPACK(VECTOR, MASK, FIELD)'
  
  _Arguments_:
       VECTOR      Shall be an array of any type and rank one.  It
                   shall have at least as many elements as MASK has
!                  'TRUE' values.
!      MASK        Shall be an array of type 'LOGICAL'.
       FIELD       Shall be of the same type as VECTOR and have the
                   same shape as MASK.
  
  _Return value_:
!      The resulting array corresponds to FIELD with 'TRUE' elements of
       MASK replaced by values from VECTOR in array element order.
  
  _Example_:
--- 19375,19392 ----
       Transformational function
  
  _Syntax_:
!      ‘RESULT = UNPACK(VECTOR, MASK, FIELD)’
  
  _Arguments_:
       VECTOR      Shall be an array of any type and rank one.  It
                   shall have at least as many elements as MASK has
!                  ‘TRUE’ values.
!      MASK        Shall be an array of type ‘LOGICAL’.
       FIELD       Shall be of the same type as VECTOR and have the
                   same shape as MASK.
  
  _Return value_:
!      The resulting array corresponds to FIELD with ‘TRUE’ elements of
       MASK replaced by values from VECTOR in array element order.
  
  _Example_:
*************** _See also_:
*** 19406,19421 ****
  
  File: gfortran.info,  Node: VERIFY,  Next: XOR,  Prev: UNPACK,  Up: Intrinsic Procedures
  
! 8.282 'VERIFY' -- Scan a string for characters not a given set
  ==============================================================
  
  _Description_:
       Verifies that all the characters in STRING belong to the set of
       characters in SET.
  
!      If BACK is either absent or equals 'FALSE', this function returns
       the position of the leftmost character of STRING that is not in
!      SET.  If BACK equals 'TRUE', the rightmost position is returned.
       If all characters of STRING are found in SET, the result is zero.
  
  _Standard_:
--- 19406,19421 ----
  
  File: gfortran.info,  Node: VERIFY,  Next: XOR,  Prev: UNPACK,  Up: Intrinsic Procedures
  
! 8.282 ‘VERIFY’ -- Scan a string for characters not a given set
  ==============================================================
  
  _Description_:
       Verifies that all the characters in STRING belong to the set of
       characters in SET.
  
!      If BACK is either absent or equals ‘FALSE’, this function returns
       the position of the leftmost character of STRING that is not in
!      SET.  If BACK equals ‘TRUE’, the rightmost position is returned.
       If all characters of STRING are found in SET, the result is zero.
  
  _Standard_:
*************** _Class_:
*** 19425,19442 ****
       Elemental function
  
  _Syntax_:
!      'RESULT = VERIFY(STRING, SET[, BACK [, KIND]])'
  
  _Arguments_:
!      STRING      Shall be of type 'CHARACTER'.
!      SET         Shall be of type 'CHARACTER'.
!      BACK        (Optional) shall be of type 'LOGICAL'.
!      KIND        (Optional) A scalar 'INTEGER' constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type 'INTEGER' and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Example_:
--- 19425,19442 ----
       Elemental function
  
  _Syntax_:
!      ‘RESULT = VERIFY(STRING, SET[, BACK [, KIND]])’
  
  _Arguments_:
!      STRING      Shall be of type ‘CHARACTER’.
!      SET         Shall be of type ‘CHARACTER’.
!      BACK        (Optional) shall be of type ‘LOGICAL’.
!      KIND        (Optional) A scalar ‘INTEGER’ constant
                   expression indicating the kind parameter of the
                   result.
  
  _Return value_:
!      The return value is of type ‘INTEGER’ and of kind KIND.  If KIND is
       absent, the return value is of default integer kind.
  
  _Example_:
*************** _See also_:
*** 19455,19461 ****
  
  File: gfortran.info,  Node: XOR,  Prev: VERIFY,  Up: Intrinsic Procedures
  
! 8.283 'XOR' -- Bitwise logical exclusive OR
  ===========================================
  
  _Description_:
--- 19455,19461 ----
  
  File: gfortran.info,  Node: XOR,  Prev: VERIFY,  Up: Intrinsic Procedures
  
! 8.283 ‘XOR’ -- Bitwise logical exclusive OR
  ===========================================
  
  _Description_:
*************** _Description_:
*** 19464,19470 ****
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  For integer arguments, programmers should consider
       the use of the *note IEOR:: intrinsic and for logical arguments the
!      '.NEQV.' operator, which are both defined by the Fortran standard.
  
  _Standard_:
       GNU extension
--- 19464,19470 ----
       This intrinsic routine is provided for backwards compatibility with
       GNU Fortran 77.  For integer arguments, programmers should consider
       the use of the *note IEOR:: intrinsic and for logical arguments the
!      ‘.NEQV.’ operator, which are both defined by the Fortran standard.
  
  _Standard_:
       GNU extension
*************** _Class_:
*** 19473,19495 ****
       Function
  
  _Syntax_:
!      'RESULT = XOR(I, J)'
  
  _Arguments_:
!      I           The type shall be either a scalar 'INTEGER' type
!                  or a scalar 'LOGICAL' type or a
                   boz-literal-constant.
       J           The type shall be the same as the type of I or a
                   boz-literal-constant.  I and J shall not both be
                   boz-literal-constants.  If either I and J is a
                   boz-literal-constant, then the other argument
!                  must be a scalar 'INTEGER'.
  
  _Return value_:
!      The return type is either a scalar 'INTEGER' or a scalar 'LOGICAL'.
       If the kind type parameters differ, then the smaller kind type is
       implicitly converted to larger kind, and the return has the larger
!      kind.  A boz-literal-constant is converted to an 'INTEGER' with the
       kind type parameter of the other argument as-if a call to *note
       INT:: occurred.
  
--- 19473,19495 ----
       Function
  
  _Syntax_:
!      ‘RESULT = XOR(I, J)’
  
  _Arguments_:
!      I           The type shall be either a scalar ‘INTEGER’ type
!                  or a scalar ‘LOGICAL’ type or a
                   boz-literal-constant.
       J           The type shall be the same as the type of I or a
                   boz-literal-constant.  I and J shall not both be
                   boz-literal-constants.  If either I and J is a
                   boz-literal-constant, then the other argument
!                  must be a scalar ‘INTEGER’.
  
  _Return value_:
!      The return type is either a scalar ‘INTEGER’ or a scalar ‘LOGICAL’.
       If the kind type parameters differ, then the smaller kind type is
       implicitly converted to larger kind, and the return has the larger
!      kind.  A boz-literal-constant is converted to an ‘INTEGER’ with the
       kind type parameter of the other argument as-if a call to *note
       INT:: occurred.
  
*************** File: gfortran.info,  Node: Intrinsic Mo
*** 19524,19644 ****
  
  File: gfortran.info,  Node: ISO_FORTRAN_ENV,  Next: ISO_C_BINDING,  Up: Intrinsic Modules
  
! 9.1 'ISO_FORTRAN_ENV'
  =====================
  
  _Standard_:
       Fortran 2003 and later, except when otherwise noted
  
!    The 'ISO_FORTRAN_ENV' module provides the following scalar
  default-integer named constants:
  
! 'ATOMIC_INT_KIND':
       Default-kind integer constant to be used as kind parameter when
       defining integer variables used in atomic operations.  (Fortran
       2008 or later.)
  
! 'ATOMIC_LOGICAL_KIND':
       Default-kind integer constant to be used as kind parameter when
       defining logical variables used in atomic operations.  (Fortran
       2008 or later.)
  
! 'CHARACTER_KINDS':
       Default-kind integer constant array of rank one containing the
!      supported kind parameters of the 'CHARACTER' type.  (Fortran 2008
       or later.)
  
! 'CHARACTER_STORAGE_SIZE':
       Size in bits of the character storage unit.
  
! 'ERROR_UNIT':
       Identifies the preconnected unit used for error reporting.
  
! 'FILE_STORAGE_SIZE':
       Size in bits of the file-storage unit.
  
! 'INPUT_UNIT':
!      Identifies the preconnected unit identified by the asterisk ('*')
!      in 'READ' statement.
  
! 'INT8', 'INT16', 'INT32', 'INT64':
       Kind type parameters to specify an INTEGER type with a storage size
       of 16, 32, and 64 bits.  It is negative if a target platform does
       not support the particular kind.  (Fortran 2008 or later.)
  
! 'INTEGER_KINDS':
       Default-kind integer constant array of rank one containing the
!      supported kind parameters of the 'INTEGER' type.  (Fortran 2008 or
       later.)
  
! 'IOSTAT_END':
!      The value assigned to the variable passed to the 'IOSTAT='
       specifier of an input/output statement if an end-of-file condition
       occurred.
  
! 'IOSTAT_EOR':
!      The value assigned to the variable passed to the 'IOSTAT='
       specifier of an input/output statement if an end-of-record
       condition occurred.
  
! 'IOSTAT_INQUIRE_INTERNAL_UNIT':
!      Scalar default-integer constant, used by 'INQUIRE' for the
!      'IOSTAT=' specifier to denote an that a unit number identifies an
       internal unit.  (Fortran 2008 or later.)
  
! 'NUMERIC_STORAGE_SIZE':
       The size in bits of the numeric storage unit.
  
! 'LOGICAL_KINDS':
       Default-kind integer constant array of rank one containing the
!      supported kind parameters of the 'LOGICAL' type.  (Fortran 2008 or
       later.)
  
! 'OUTPUT_UNIT':
!      Identifies the preconnected unit identified by the asterisk ('*')
!      in 'WRITE' statement.
  
! 'REAL32', 'REAL64', 'REAL128':
       Kind type parameters to specify a REAL type with a storage size of
       32, 64, and 128 bits.  It is negative if a target platform does not
       support the particular kind.  (Fortran 2008 or later.)
  
! 'REAL_KINDS':
       Default-kind integer constant array of rank one containing the
!      supported kind parameters of the 'REAL' type.  (Fortran 2008 or
       later.)
  
! 'STAT_LOCKED':
       Scalar default-integer constant used as STAT= return value by
!      'LOCK' to denote that the lock variable is locked by the executing
       image.  (Fortran 2008 or later.)
  
! 'STAT_LOCKED_OTHER_IMAGE':
       Scalar default-integer constant used as STAT= return value by
!      'UNLOCK' to denote that the lock variable is locked by another
       image.  (Fortran 2008 or later.)
  
! 'STAT_STOPPED_IMAGE':
       Positive, scalar default-integer constant used as STAT= return
       value if the argument in the statement requires synchronisation
       with an image, which has initiated the termination of the
       execution.  (Fortran 2008 or later.)
  
! 'STAT_FAILED_IMAGE':
       Positive, scalar default-integer constant used as STAT= return
       value if the argument in the statement requires communication with
       an image, which has is in the failed state.  (TS 18508 or later.)
  
! 'STAT_UNLOCKED':
       Scalar default-integer constant used as STAT= return value by
!      'UNLOCK' to denote that the lock variable is unlocked.  (Fortran
       2008 or later.)
  
     The module provides the following derived type:
  
! 'LOCK_TYPE':
!      Derived type with private components to be use with the 'LOCK' and
!      'UNLOCK' statement.  A variable of its type has to be always
       declared as coarray and may not appear in a variable-definition
       context.  (Fortran 2008 or later.)
  
--- 19524,19644 ----
  
  File: gfortran.info,  Node: ISO_FORTRAN_ENV,  Next: ISO_C_BINDING,  Up: Intrinsic Modules
  
! 9.1 ‘ISO_FORTRAN_ENV’
  =====================
  
  _Standard_:
       Fortran 2003 and later, except when otherwise noted
  
!    The ‘ISO_FORTRAN_ENV’ module provides the following scalar
  default-integer named constants:
  
! ‘ATOMIC_INT_KIND’:
       Default-kind integer constant to be used as kind parameter when
       defining integer variables used in atomic operations.  (Fortran
       2008 or later.)
  
! ‘ATOMIC_LOGICAL_KIND’:
       Default-kind integer constant to be used as kind parameter when
       defining logical variables used in atomic operations.  (Fortran
       2008 or later.)
  
! ‘CHARACTER_KINDS’:
       Default-kind integer constant array of rank one containing the
!      supported kind parameters of the ‘CHARACTER’ type.  (Fortran 2008
       or later.)
  
! ‘CHARACTER_STORAGE_SIZE’:
       Size in bits of the character storage unit.
  
! ‘ERROR_UNIT’:
       Identifies the preconnected unit used for error reporting.
  
! ‘FILE_STORAGE_SIZE’:
       Size in bits of the file-storage unit.
  
! ‘INPUT_UNIT’:
!      Identifies the preconnected unit identified by the asterisk (‘*’)
!      in ‘READ’ statement.
  
! ‘INT8’, ‘INT16’, ‘INT32’, ‘INT64’:
       Kind type parameters to specify an INTEGER type with a storage size
       of 16, 32, and 64 bits.  It is negative if a target platform does
       not support the particular kind.  (Fortran 2008 or later.)
  
! ‘INTEGER_KINDS’:
       Default-kind integer constant array of rank one containing the
!      supported kind parameters of the ‘INTEGER’ type.  (Fortran 2008 or
       later.)
  
! ‘IOSTAT_END’:
!      The value assigned to the variable passed to the ‘IOSTAT=’
       specifier of an input/output statement if an end-of-file condition
       occurred.
  
! ‘IOSTAT_EOR’:
!      The value assigned to the variable passed to the ‘IOSTAT=’
       specifier of an input/output statement if an end-of-record
       condition occurred.
  
! ‘IOSTAT_INQUIRE_INTERNAL_UNIT’:
!      Scalar default-integer constant, used by ‘INQUIRE’ for the
!      ‘IOSTAT=’ specifier to denote an that a unit number identifies an
       internal unit.  (Fortran 2008 or later.)
  
! ‘NUMERIC_STORAGE_SIZE’:
       The size in bits of the numeric storage unit.
  
! ‘LOGICAL_KINDS’:
       Default-kind integer constant array of rank one containing the
!      supported kind parameters of the ‘LOGICAL’ type.  (Fortran 2008 or
       later.)
  
! ‘OUTPUT_UNIT’:
!      Identifies the preconnected unit identified by the asterisk (‘*’)
!      in ‘WRITE’ statement.
  
! ‘REAL32’, ‘REAL64’, ‘REAL128’:
       Kind type parameters to specify a REAL type with a storage size of
       32, 64, and 128 bits.  It is negative if a target platform does not
       support the particular kind.  (Fortran 2008 or later.)
  
! ‘REAL_KINDS’:
       Default-kind integer constant array of rank one containing the
!      supported kind parameters of the ‘REAL’ type.  (Fortran 2008 or
       later.)
  
! ‘STAT_LOCKED’:
       Scalar default-integer constant used as STAT= return value by
!      ‘LOCK’ to denote that the lock variable is locked by the executing
       image.  (Fortran 2008 or later.)
  
! ‘STAT_LOCKED_OTHER_IMAGE’:
       Scalar default-integer constant used as STAT= return value by
!      ‘UNLOCK’ to denote that the lock variable is locked by another
       image.  (Fortran 2008 or later.)
  
! ‘STAT_STOPPED_IMAGE’:
       Positive, scalar default-integer constant used as STAT= return
       value if the argument in the statement requires synchronisation
       with an image, which has initiated the termination of the
       execution.  (Fortran 2008 or later.)
  
! ‘STAT_FAILED_IMAGE’:
       Positive, scalar default-integer constant used as STAT= return
       value if the argument in the statement requires communication with
       an image, which has is in the failed state.  (TS 18508 or later.)
  
! ‘STAT_UNLOCKED’:
       Scalar default-integer constant used as STAT= return value by
!      ‘UNLOCK’ to denote that the lock variable is unlocked.  (Fortran
       2008 or later.)
  
     The module provides the following derived type:
  
! ‘LOCK_TYPE’:
!      Derived type with private components to be use with the ‘LOCK’ and
!      ‘UNLOCK’ statement.  A variable of its type has to be always
       declared as coarray and may not appear in a variable-definition
       context.  (Fortran 2008 or later.)
  
*************** COMPILER_OPTIONS:: and *note COMPILER_VE
*** 19648,19654 ****
  
  File: gfortran.info,  Node: ISO_C_BINDING,  Next: IEEE modules,  Prev: ISO_FORTRAN_ENV,  Up: Intrinsic Modules
  
! 9.2 'ISO_C_BINDING'
  ===================
  
  _Standard_:
--- 19648,19654 ----
  
  File: gfortran.info,  Node: ISO_C_BINDING,  Next: IEEE modules,  Prev: ISO_FORTRAN_ENV,  Up: Intrinsic Modules
  
! 9.2 ‘ISO_C_BINDING’
  ===================
  
  _Standard_:
*************** _Standard_:
*** 19658,19772 ****
  definition can be found in the section Intrinsic Procedures of this
  manual.
  
! 'C_ASSOCIATED'
! 'C_F_POINTER'
! 'C_F_PROCPOINTER'
! 'C_FUNLOC'
! 'C_LOC'
! 'C_SIZEOF'
  
!    The 'ISO_C_BINDING' module provides the following named constants of
  type default integer, which can be used as KIND type parameters.
  
     In addition to the integer named constants required by the Fortran
! 2003 standard and 'C_PTRDIFF_T' of TS 29113, GNU Fortran provides as an
  extension named constants for the 128-bit integer types supported by the
! C compiler: 'C_INT128_T, C_INT_LEAST128_T, C_INT_FAST128_T'.
! Furthermore, if '_Float128' is supported in C, the named constants
! 'C_FLOAT128' and 'C_FLOAT128_COMPLEX' are defined.
  
  Fortran Type   Named constant          C type                   Extension
  ----------------------------------------------------------------------------
! 'INTEGER'      'C_INT'                 'int'
! 'INTEGER'      'C_SHORT'               'short int'
! 'INTEGER'      'C_LONG'                'long int'
! 'INTEGER'      'C_LONG_LONG'           'long long int'
! 'INTEGER'      'C_SIGNED_CHAR'         'signed
!                                        char'/'unsigned char'
! 'INTEGER'      'C_SIZE_T'              'size_t'
! 'INTEGER'      'C_INT8_T'              'int8_t'
! 'INTEGER'      'C_INT16_T'             'int16_t'
! 'INTEGER'      'C_INT32_T'             'int32_t'
! 'INTEGER'      'C_INT64_T'             'int64_t'
! 'INTEGER'      'C_INT128_T'            'int128_t'               Ext.
! 'INTEGER'      'C_INT_LEAST8_T'        'int_least8_t'
! 'INTEGER'      'C_INT_LEAST16_T'       'int_least16_t'
! 'INTEGER'      'C_INT_LEAST32_T'       'int_least32_t'
! 'INTEGER'      'C_INT_LEAST64_T'       'int_least64_t'
! 'INTEGER'      'C_INT_LEAST128_T'      'int_least128_t'         Ext.
! 'INTEGER'      'C_INT_FAST8_T'         'int_fast8_t'
! 'INTEGER'      'C_INT_FAST16_T'        'int_fast16_t'
! 'INTEGER'      'C_INT_FAST32_T'        'int_fast32_t'
! 'INTEGER'      'C_INT_FAST64_T'        'int_fast64_t'
! 'INTEGER'      'C_INT_FAST128_T'       'int_fast128_t'          Ext.
! 'INTEGER'      'C_INTMAX_T'            'intmax_t'
! 'INTEGER'      'C_INTPTR_T'            'intptr_t'
! 'INTEGER'      'C_PTRDIFF_T'           'ptrdiff_t'              TS 29113
! 'REAL'         'C_FLOAT'               'float'
! 'REAL'         'C_DOUBLE'              'double'
! 'REAL'         'C_LONG_DOUBLE'         'long double'
! 'REAL'         'C_FLOAT128'            '_Float128'              Ext.
! 'COMPLEX'      'C_FLOAT_COMPLEX'       'float _Complex'
! 'COMPLEX'      'C_DOUBLE_COMPLEX'      'double _Complex'
! 'COMPLEX'      'C_LONG_DOUBLE_COMPLEX' 'long double _Complex'
! 'COMPLEX'      'C_FLOAT128_COMPLEX'    '_Float128 _Complex'     Ext.
! 'LOGICAL'      'C_BOOL'                '_Bool'
! 'CHARACTER'    'C_CHAR'                'char'
  
     Additionally, the following parameters of type
! 'CHARACTER(KIND=C_CHAR)' are defined.
  
  Name           C definition                     Value
  ------------------------------------------------------------
! 'C_NULL_CHAR'  null character                   ''\0''
! 'C_ALERT'      alert                            ''\a''
! 'C_BACKSPACE'  backspace                        ''\b''
! 'C_FORM_FEED'  form feed                        ''\f''
! 'C_NEW_LINE'   new line                         ''\n''
! 'C_CARRIAGE_RETURN'carriage return              ''\r''
! 'C_HORIZONTAL_TAB'horizontal tab                ''\t''
! 'C_VERTICAL_TAB'vertical tab                    ''\v''
  
     Moreover, the following two named constants are defined:
  
  Name           Type
  --------------------------------------------------------------------------
! 'C_NULL_PTR'   'C_PTR'
! 'C_NULL_FUNPTR''C_FUNPTR'
  
!    Both are equivalent to the value 'NULL' in C.
  
  
  File: gfortran.info,  Node: IEEE modules,  Next: OpenMP Modules OMP_LIB and OMP_LIB_KINDS,  Prev: ISO_C_BINDING,  Up: Intrinsic Modules
  
! 9.3 IEEE modules: 'IEEE_EXCEPTIONS', 'IEEE_ARITHMETIC', and 'IEEE_FEATURES'
  ===========================================================================
  
  _Standard_:
       Fortran 2003 and later
  
!    The 'IEEE_EXCEPTIONS', 'IEEE_ARITHMETIC', and 'IEEE_FEATURES'
  intrinsic modules provide support for exceptions and IEEE arithmetic, as
  defined in Fortran 2003 and later standards, and the IEC 60559:1989
  standard (_Binary floating-point arithmetic for microprocessor
  systems_).  These modules are only provided on the following supported
  platforms:
  
!    * i386 and x86_64 processors
!    * platforms which use the GNU C Library (glibc)
!    * platforms with support for SysV/386 routines for floating point
       interface (including Solaris and BSDs)
!    * platforms with the AIX OS
  
     For full compliance with the Fortran standards, code using the
! 'IEEE_EXCEPTIONS' or 'IEEE_ARITHMETIC' modules should be compiled with
! the following options: '-fno-unsafe-math-optimizations -frounding-math
! -fsignaling-nans'.
  
  
  File: gfortran.info,  Node: OpenMP Modules OMP_LIB and OMP_LIB_KINDS,  Next: OpenACC Module OPENACC,  Prev: IEEE modules,  Up: Intrinsic Modules
  
! 9.4 OpenMP Modules 'OMP_LIB' and 'OMP_LIB_KINDS'
  ================================================
  
  _Standard_:
--- 19658,19772 ----
  definition can be found in the section Intrinsic Procedures of this
  manual.
  
! ‘C_ASSOCIATED’
! ‘C_F_POINTER’
! ‘C_F_PROCPOINTER’
! ‘C_FUNLOC’
! ‘C_LOC’
! ‘C_SIZEOF’
  
!    The ‘ISO_C_BINDING’ module provides the following named constants of
  type default integer, which can be used as KIND type parameters.
  
     In addition to the integer named constants required by the Fortran
! 2003 standard and ‘C_PTRDIFF_T’ of TS 29113, GNU Fortran provides as an
  extension named constants for the 128-bit integer types supported by the
! C compiler: ‘C_INT128_T, C_INT_LEAST128_T, C_INT_FAST128_T’.
! Furthermore, if ‘_Float128’ is supported in C, the named constants
! ‘C_FLOAT128’ and ‘C_FLOAT128_COMPLEX’ are defined.
  
  Fortran Type   Named constant          C type                   Extension
  ----------------------------------------------------------------------------
! ‘INTEGER’      ‘C_INT’                 ‘int’
! ‘INTEGER’      ‘C_SHORT’               ‘short int’
! ‘INTEGER’      ‘C_LONG’                ‘long int’
! ‘INTEGER’      ‘C_LONG_LONG’           ‘long long int’
! ‘INTEGER’      ‘C_SIGNED_CHAR’         ‘signed
!                                        char’/‘unsigned char’
! ‘INTEGER’      ‘C_SIZE_T’              ‘size_t’
! ‘INTEGER’      ‘C_INT8_T’              ‘int8_t’
! ‘INTEGER’      ‘C_INT16_T’             ‘int16_t’
! ‘INTEGER’      ‘C_INT32_T’             ‘int32_t’
! ‘INTEGER’      ‘C_INT64_T’             ‘int64_t’
! ‘INTEGER’      ‘C_INT128_T’            ‘int128_t’               Ext.
! ‘INTEGER’      ‘C_INT_LEAST8_T’        ‘int_least8_t’
! ‘INTEGER’      ‘C_INT_LEAST16_T’       ‘int_least16_t’
! ‘INTEGER’      ‘C_INT_LEAST32_T’       ‘int_least32_t’
! ‘INTEGER’      ‘C_INT_LEAST64_T’       ‘int_least64_t’
! ‘INTEGER’      ‘C_INT_LEAST128_T’      ‘int_least128_t’         Ext.
! ‘INTEGER’      ‘C_INT_FAST8_T’         ‘int_fast8_t’
! ‘INTEGER’      ‘C_INT_FAST16_T’        ‘int_fast16_t’
! ‘INTEGER’      ‘C_INT_FAST32_T’        ‘int_fast32_t’
! ‘INTEGER’      ‘C_INT_FAST64_T’        ‘int_fast64_t’
! ‘INTEGER’      ‘C_INT_FAST128_T’       ‘int_fast128_t’          Ext.
! ‘INTEGER’      ‘C_INTMAX_T’            ‘intmax_t’
! ‘INTEGER’      ‘C_INTPTR_T’            ‘intptr_t’
! ‘INTEGER’      ‘C_PTRDIFF_T’           ‘ptrdiff_t’              TS 29113
! ‘REAL’         ‘C_FLOAT’               ‘float’
! ‘REAL’         ‘C_DOUBLE’              ‘double’
! ‘REAL’         ‘C_LONG_DOUBLE’         ‘long double’
! ‘REAL’         ‘C_FLOAT128’            ‘_Float128’              Ext.
! ‘COMPLEX’      ‘C_FLOAT_COMPLEX’       ‘float _Complex’
! ‘COMPLEX’      ‘C_DOUBLE_COMPLEX’      ‘double _Complex’
! ‘COMPLEX’      ‘C_LONG_DOUBLE_COMPLEX’ ‘long double _Complex’
! ‘COMPLEX’      ‘C_FLOAT128_COMPLEX’    ‘_Float128 _Complex’     Ext.
! ‘LOGICAL’      ‘C_BOOL’                ‘_Bool’
! ‘CHARACTER’    ‘C_CHAR’                ‘char’
  
     Additionally, the following parameters of type
! ‘CHARACTER(KIND=C_CHAR)’ are defined.
  
  Name           C definition                     Value
  ------------------------------------------------------------
! ‘C_NULL_CHAR’  null character                   ‘'\0'’
! ‘C_ALERT’      alert                            ‘'\a'’
! ‘C_BACKSPACE’  backspace                        ‘'\b'’
! ‘C_FORM_FEED’  form feed                        ‘'\f'’
! ‘C_NEW_LINE’   new line                         ‘'\n'’
! ‘C_CARRIAGE_RETURN’carriage return              ‘'\r'’
! ‘C_HORIZONTAL_TAB’horizontal tab                ‘'\t'’
! ‘C_VERTICAL_TAB’vertical tab                    ‘'\v'’
  
     Moreover, the following two named constants are defined:
  
  Name           Type
  --------------------------------------------------------------------------
! ‘C_NULL_PTR’   ‘C_PTR’
! ‘C_NULL_FUNPTR’‘C_FUNPTR’
  
!    Both are equivalent to the value ‘NULL’ in C.
  
  
  File: gfortran.info,  Node: IEEE modules,  Next: OpenMP Modules OMP_LIB and OMP_LIB_KINDS,  Prev: ISO_C_BINDING,  Up: Intrinsic Modules
  
! 9.3 IEEE modules: ‘IEEE_EXCEPTIONS’, ‘IEEE_ARITHMETIC’, and ‘IEEE_FEATURES’
  ===========================================================================
  
  _Standard_:
       Fortran 2003 and later
  
!    The ‘IEEE_EXCEPTIONS’, ‘IEEE_ARITHMETIC’, and ‘IEEE_FEATURES’
  intrinsic modules provide support for exceptions and IEEE arithmetic, as
  defined in Fortran 2003 and later standards, and the IEC 60559:1989
  standard (_Binary floating-point arithmetic for microprocessor
  systems_).  These modules are only provided on the following supported
  platforms:
  
!    • i386 and x86_64 processors
!    • platforms which use the GNU C Library (glibc)
!    • platforms with support for SysV/386 routines for floating point
       interface (including Solaris and BSDs)
!    • platforms with the AIX OS
  
     For full compliance with the Fortran standards, code using the
! ‘IEEE_EXCEPTIONS’ or ‘IEEE_ARITHMETIC’ modules should be compiled with
! the following options: ‘-fno-unsafe-math-optimizations -frounding-math
! -fsignaling-nans’.
  
  
  File: gfortran.info,  Node: OpenMP Modules OMP_LIB and OMP_LIB_KINDS,  Next: OpenACC Module OPENACC,  Prev: IEEE modules,  Up: Intrinsic Modules
  
! 9.4 OpenMP Modules ‘OMP_LIB’ and ‘OMP_LIB_KINDS’
  ================================================
  
  _Standard_:
*************** _Standard_:
*** 19775,19783 ****
       Program Interface v5.1 (partially supported).
  
     The OpenMP Fortran runtime library routines are provided both in a
! form of two Fortran modules, named 'OMP_LIB' and 'OMP_LIB_KINDS', and in
! a form of a Fortran 'include' file named 'omp_lib.h'.  The procedures
! provided by 'OMP_LIB' can be found in the *note Introduction:
  (libgomp)Top. manual, the named constants defined in the modules are
  listed below.
  
--- 19775,19783 ----
       Program Interface v5.1 (partially supported).
  
     The OpenMP Fortran runtime library routines are provided both in a
! form of two Fortran modules, named ‘OMP_LIB’ and ‘OMP_LIB_KINDS’, and in
! a form of a Fortran ‘include’ file named ‘omp_lib.h’.  The procedures
! provided by ‘OMP_LIB’ can be found in the *note Introduction:
  (libgomp)Top. manual, the named constants defined in the modules are
  listed below.
  
*************** v4.5 (https://www.openmp.org/wp-content/
*** 19786,19934 ****
  OpenMP Application Program Interface v5.0
  (https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf).
  
!    'OMP_LIB_KINDS' provides the following scalar default-integer named
  constants:
  
! 'omp_allocator_handle_kind'
! 'omp_alloctrait_key_kind'
! 'omp_alloctrait_val_kind'
! 'omp_depend_kind'
! 'omp_lock_kind'
! 'omp_lock_hint_kind'
! 'omp_nest_lock_kind'
! 'omp_pause_resource_kind'
! 'omp_memspace_handle_kind'
! 'omp_proc_bind_kind'
! 'omp_sched_kind'
! 'omp_sync_hint_kind'
  
!    'OMP_LIB' provides the scalar default-integer named constant
! 'openmp_version' with a value of the form YYYYMM, where 'yyyy' is the
  year and MM the month of the OpenMP version; for OpenMP v4.5 the value
! is '201511'.
  
     The following derived type:
  
! 'omp_alloctrait'
  
     The following scalar integer named constants of the kind
! 'omp_sched_kind':
  
! 'omp_sched_static'
! 'omp_sched_dynamic'
! 'omp_sched_guided'
! 'omp_sched_auto'
  
     And the following scalar integer named constants of the kind
! 'omp_proc_bind_kind':
  
! 'omp_proc_bind_false'
! 'omp_proc_bind_true'
! 'omp_proc_bind_primary'
! 'omp_proc_bind_master'
! 'omp_proc_bind_close'
! 'omp_proc_bind_spread'
  
     The following scalar integer named constants are of the kind
! 'omp_lock_hint_kind':
  
! 'omp_lock_hint_none'
! 'omp_lock_hint_uncontended'
! 'omp_lock_hint_contended'
! 'omp_lock_hint_nonspeculative'
! 'omp_lock_hint_speculative'
! 'omp_sync_hint_none'
! 'omp_sync_hint_uncontended'
! 'omp_sync_hint_contended'
! 'omp_sync_hint_nonspeculative'
! 'omp_sync_hint_speculative'
  
     And the following two scalar integer named constants are of the kind
! 'omp_pause_resource_kind':
  
! 'omp_pause_soft'
! 'omp_pause_hard'
  
     The following scalar integer named constants are of the kind
! 'omp_alloctrait_key_kind':
  
! 'omp_atk_sync_hint'
! 'omp_atk_alignment'
! 'omp_atk_access'
! 'omp_atk_pool_size'
! 'omp_atk_fallback'
! 'omp_atk_fb_data'
! 'omp_atk_pinned'
! 'omp_atk_partition'
  
     The following scalar integer named constants are of the kind
! 'omp_alloctrait_val_kind':
  
!      'omp_alloctrait_key_kind':
! 'omp_atv_default'
! 'omp_atv_false'
! 'omp_atv_true'
! 'omp_atv_contended'
! 'omp_atv_uncontended'
! 'omp_atv_serialized'
! 'omp_atv_sequential'
! 'omp_atv_private'
! 'omp_atv_all'
! 'omp_atv_thread'
! 'omp_atv_pteam'
! 'omp_atv_cgroup'
! 'omp_atv_default_mem_fb'
! 'omp_atv_null_fb'
! 'omp_atv_abort_fb'
! 'omp_atv_allocator_fb'
! 'omp_atv_environment'
! 'omp_atv_nearest'
! 'omp_atv_blocked'
  
     The following scalar integer named constants are of the kind
! 'omp_allocator_handle_kind':
  
! 'omp_null_allocator'
! 'omp_default_mem_alloc'
! 'omp_large_cap_mem_alloc'
! 'omp_const_mem_alloc'
! 'omp_high_bw_mem_alloc'
! 'omp_low_lat_mem_alloc'
! 'omp_cgroup_mem_alloc'
! 'omp_pteam_mem_alloc'
! 'omp_thread_mem_alloc'
  
     The following scalar integer named constants are of the kind
! 'omp_memspace_handle_kind':
  
! 'omp_default_mem_space'
! 'omp_large_cap_mem_space'
! 'omp_const_mem_space'
! 'omp_high_bw_mem_space'
! 'omp_low_lat_mem_space'
  
  
  File: gfortran.info,  Node: OpenACC Module OPENACC,  Prev: OpenMP Modules OMP_LIB and OMP_LIB_KINDS,  Up: Intrinsic Modules
  
! 9.5 OpenACC Module 'OPENACC'
  ============================
  
  _Standard_:
       OpenACC Application Programming Interface v2.6
  
     The OpenACC Fortran runtime library routines are provided both in a
! form of a Fortran 90 module, named 'OPENACC', and in form of a Fortran
! 'include' file named 'openacc_lib.h'.  The procedures provided by
! 'OPENACC' can be found in the *note Introduction: (libgomp)Top. manual,
  the named constants defined in the modules are listed below.
  
     For details refer to the actual OpenACC Application Programming
  Interface v2.6 (https://www.openacc.org/).
  
!    'OPENACC' provides the scalar default-integer named constant
! 'openacc_version' with a value of the form YYYYMM, where 'yyyy' is the
  year and MM the month of the OpenACC version; for OpenACC v2.6 the value
! is '201711'.
  
  
  File: gfortran.info,  Node: Contributing,  Next: Copying,  Prev: Intrinsic Modules,  Up: Top
--- 19786,19934 ----
  OpenMP Application Program Interface v5.0
  (https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf).
  
!    ‘OMP_LIB_KINDS’ provides the following scalar default-integer named
  constants:
  
! ‘omp_allocator_handle_kind’
! ‘omp_alloctrait_key_kind’
! ‘omp_alloctrait_val_kind’
! ‘omp_depend_kind’
! ‘omp_lock_kind’
! ‘omp_lock_hint_kind’
! ‘omp_nest_lock_kind’
! ‘omp_pause_resource_kind’
! ‘omp_memspace_handle_kind’
! ‘omp_proc_bind_kind’
! ‘omp_sched_kind’
! ‘omp_sync_hint_kind’
  
!    ‘OMP_LIB’ provides the scalar default-integer named constant
! ‘openmp_version’ with a value of the form YYYYMM, where ‘yyyy’ is the
  year and MM the month of the OpenMP version; for OpenMP v4.5 the value
! is ‘201511’.
  
     The following derived type:
  
! ‘omp_alloctrait’
  
     The following scalar integer named constants of the kind
! ‘omp_sched_kind’:
  
! ‘omp_sched_static’
! ‘omp_sched_dynamic’
! ‘omp_sched_guided’
! ‘omp_sched_auto’
  
     And the following scalar integer named constants of the kind
! ‘omp_proc_bind_kind’:
  
! ‘omp_proc_bind_false’
! ‘omp_proc_bind_true’
! ‘omp_proc_bind_primary’
! ‘omp_proc_bind_master’
! ‘omp_proc_bind_close’
! ‘omp_proc_bind_spread’
  
     The following scalar integer named constants are of the kind
! ‘omp_lock_hint_kind’:
  
! ‘omp_lock_hint_none’
! ‘omp_lock_hint_uncontended’
! ‘omp_lock_hint_contended’
! ‘omp_lock_hint_nonspeculative’
! ‘omp_lock_hint_speculative’
! ‘omp_sync_hint_none’
! ‘omp_sync_hint_uncontended’
! ‘omp_sync_hint_contended’
! ‘omp_sync_hint_nonspeculative’
! ‘omp_sync_hint_speculative’
  
     And the following two scalar integer named constants are of the kind
! ‘omp_pause_resource_kind’:
  
! ‘omp_pause_soft’
! ‘omp_pause_hard’
  
     The following scalar integer named constants are of the kind
! ‘omp_alloctrait_key_kind’:
  
! ‘omp_atk_sync_hint’
! ‘omp_atk_alignment’
! ‘omp_atk_access’
! ‘omp_atk_pool_size’
! ‘omp_atk_fallback’
! ‘omp_atk_fb_data’
! ‘omp_atk_pinned’
! ‘omp_atk_partition’
  
     The following scalar integer named constants are of the kind
! ‘omp_alloctrait_val_kind’:
  
!      ‘omp_alloctrait_key_kind’:
! ‘omp_atv_default’
! ‘omp_atv_false’
! ‘omp_atv_true’
! ‘omp_atv_contended’
! ‘omp_atv_uncontended’
! ‘omp_atv_serialized’
! ‘omp_atv_sequential’
! ‘omp_atv_private’
! ‘omp_atv_all’
! ‘omp_atv_thread’
! ‘omp_atv_pteam’
! ‘omp_atv_cgroup’
! ‘omp_atv_default_mem_fb’
! ‘omp_atv_null_fb’
! ‘omp_atv_abort_fb’
! ‘omp_atv_allocator_fb’
! ‘omp_atv_environment’
! ‘omp_atv_nearest’
! ‘omp_atv_blocked’
  
     The following scalar integer named constants are of the kind
! ‘omp_allocator_handle_kind’:
  
! ‘omp_null_allocator’
! ‘omp_default_mem_alloc’
! ‘omp_large_cap_mem_alloc’
! ‘omp_const_mem_alloc’
! ‘omp_high_bw_mem_alloc’
! ‘omp_low_lat_mem_alloc’
! ‘omp_cgroup_mem_alloc’
! ‘omp_pteam_mem_alloc’
! ‘omp_thread_mem_alloc’
  
     The following scalar integer named constants are of the kind
! ‘omp_memspace_handle_kind’:
  
! ‘omp_default_mem_space’
! ‘omp_large_cap_mem_space’
! ‘omp_const_mem_space’
! ‘omp_high_bw_mem_space’
! ‘omp_low_lat_mem_space’
  
  
  File: gfortran.info,  Node: OpenACC Module OPENACC,  Prev: OpenMP Modules OMP_LIB and OMP_LIB_KINDS,  Up: Intrinsic Modules
  
! 9.5 OpenACC Module ‘OPENACC’
  ============================
  
  _Standard_:
       OpenACC Application Programming Interface v2.6
  
     The OpenACC Fortran runtime library routines are provided both in a
! form of a Fortran 90 module, named ‘OPENACC’, and in form of a Fortran
! ‘include’ file named ‘openacc_lib.h’.  The procedures provided by
! ‘OPENACC’ can be found in the *note Introduction: (libgomp)Top. manual,
  the named constants defined in the modules are listed below.
  
     For details refer to the actual OpenACC Application Programming
  Interface v2.6 (https://www.openacc.org/).
  
!    ‘OPENACC’ provides the scalar default-integer named constant
! ‘openacc_version’ with a value of the form YYYYMM, where ‘yyyy’ is the
  year and MM the month of the OpenACC version; for OpenACC v2.6 the value
! is ‘201711’.
  
  
  File: gfortran.info,  Node: Contributing,  Next: Copying,  Prev: Intrinsic Modules,  Up: Top
*************** with GCC was written by _Paul Brook_.
*** 19966,20015 ****
     The following individuals have contributed code and/or ideas and
  significant help to the GNU Fortran project (in alphabetical order):
  
!    - Janne Blomqvist
!    - Steven Bosscher
!    - Paul Brook
!    - Tobias Burnus
!    - François-Xavier Coudert
!    - Bud Davis
!    - Jerry DeLisle
!    - Erik Edelmann
!    - Bernhard Fischer
!    - Daniel Franke
!    - Richard Guenther
!    - Richard Henderson
!    - Katherine Holcomb
!    - Jakub Jelinek
!    - Niels Kristian Bech Jensen
!    - Steven Johnson
!    - Steven G. Kargl
!    - Thomas Koenig
!    - Asher Langton
!    - H. J. Lu
!    - Toon Moene
!    - Brooks Moses
!    - Andrew Pinski
!    - Tim Prince
!    - Christopher D. Rickett
!    - Richard Sandiford
!    - Tobias Schlüter
!    - Roger Sayle
!    - Paul Thomas
!    - Andy Vaught
!    - Feng Wang
!    - Janus Weil
!    - Daniel Kraft
  
     The following people have contributed bug reports, smaller or larger
  patches, and much needed feedback and encouragement for the GNU Fortran
  project:
  
!    - Bill Clodius
!    - Dominique d'Humières
!    - Kate Hedstrom
!    - Erik Schnetter
!    - Gerhard Steinmetz
!    - Joost VandeVondele
  
     Many other individuals have helped debug, test and improve the GNU
  Fortran compiler over the past few years, and we welcome you to do the
--- 19966,20015 ----
     The following individuals have contributed code and/or ideas and
  significant help to the GNU Fortran project (in alphabetical order):
  
!    − Janne Blomqvist
!    − Steven Bosscher
!    − Paul Brook
!    − Tobias Burnus
!    − François-Xavier Coudert
!    − Bud Davis
!    − Jerry DeLisle
!    − Erik Edelmann
!    − Bernhard Fischer
!    − Daniel Franke
!    − Richard Guenther
!    − Richard Henderson
!    − Katherine Holcomb
!    − Jakub Jelinek
!    − Niels Kristian Bech Jensen
!    − Steven Johnson
!    − Steven G. Kargl
!    − Thomas Koenig
!    − Asher Langton
!    − H. J. Lu
!    − Toon Moene
!    − Brooks Moses
!    − Andrew Pinski
!    − Tim Prince
!    − Christopher D. Rickett
!    − Richard Sandiford
!    − Tobias Schlüter
!    − Roger Sayle
!    − Paul Thomas
!    − Andy Vaught
!    − Feng Wang
!    − Janus Weil
!    − Daniel Kraft
  
     The following people have contributed bug reports, smaller or larger
  patches, and much needed feedback and encouragement for the GNU Fortran
  project:
  
!    − Bill Clodius
!    − Dominique d'Humières
!    − Kate Hedstrom
!    − Erik Schnetter
!    − Gerhard Steinmetz
!    − Joost VandeVondele
  
     Many other individuals have helped debug, test and improve the GNU
  Fortran compiler over the past few years, and we welcome you to do the
*************** GNU General Public License
*** 20052,20058 ****
  
                          Version 3, 29 June 2007
  
!      Copyright (C) 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
--- 20052,20058 ----
  
                          Version 3, 29 June 2007
  
!      Copyright © 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
*************** mail.
*** 20739,20749 ****
  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".
--- 20739,20749 ----
  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".
*************** GNU Free Documentation License
*** 20768,20774 ****
  
                       Version 1.3, 3 November 2008
  
!      Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
--- 20768,20774 ----
  
                       Version 1.3, 3 November 2008
  
!      Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
*************** GNU Free Documentation License
*** 20777,20783 ****
    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
--- 20777,20783 ----
    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
*************** more; major new features or packages con
*** 21288,21294 ****
  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.
  
--- 21288,21294 ----
  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 © 1994 Free Software Foundation, Inc.
       Verbatim copying and redistribution of this section is permitted
       without royalty; alteration is not permitted.
  
*************** File: gfortran.info,  Node: Option Index
*** 21298,21305 ****
  Option Index
  ************
  
! 'gfortran''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.
--- 21298,21305 ----
  Option Index
  ************
  
! ‘gfortran’'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.
*************** Keyword Index
*** 21583,21598 ****
  [index]
  * Menu:
  
- * $:                                     Fortran Dialect Options.
-                                                               (line 104)
- * %LOC:                                  Argument list functions.
-                                                               (line   6)
- * %REF:                                  Argument list functions.
-                                                               (line   6)
- * %VAL:                                  Argument list functions.
-                                                               (line   6)
- * &:                                     Error and Warning Options.
-                                                               (line  87)
  * _gfortran_set_args:                    _gfortran_set_args.  (line   6)
  * _gfortran_set_convert:                 _gfortran_set_convert.
                                                                (line   6)
--- 21583,21588 ----
*************** Keyword Index
*** 21603,21608 ****
--- 21593,21608 ----
                                                                (line   6)
  * _gfortran_set_record_marker:           _gfortran_set_record_marker.
                                                                (line   6)
+ * &:                                     Error and Warning Options.
+                                                               (line  87)
+ * %LOC:                                  Argument list functions.
+                                                               (line   6)
+ * %REF:                                  Argument list functions.
+                                                               (line   6)
+ * %VAL:                                  Argument list functions.
+                                                               (line   6)
+ * $:                                     Fortran Dialect Options.
+                                                               (line 104)
  * ABORT:                                 ABORT.               (line   6)
  * ABS:                                   ABS.                 (line   6)
  * absolute value:                        ABS.                 (line   6)
*************** Keyword Index
*** 21784,21789 ****
--- 21784,21790 ----
  * binary representation <1>:             POPPAR.              (line   6)
  * BIOR:                                  IOR.                 (line   6)
  * bit intrinsics checking:               Code Gen Options.    (line 143)
+ * BIT_SIZE:                              BIT_SIZE.            (line   6)
  * BITEST:                                BTEST.               (line   6)
  * bits set:                              POPCNT.              (line   6)
  * bits, AND of array elements:           IALL.                (line   6)
*************** Keyword Index
*** 21818,21824 ****
  * bitwise logical not:                   NOT.                 (line   6)
  * bitwise logical or:                    IOR.                 (line   6)
  * bitwise logical or <1>:                OR.                  (line   6)
- * BIT_SIZE:                              BIT_SIZE.            (line   6)
  * BJTEST:                                BTEST.               (line   6)
  * BKTEST:                                BTEST.               (line   6)
  * BLE:                                   BLE.                 (line   6)
--- 21819,21824 ----
*************** Keyword Index
*** 21843,21848 ****
--- 21843,21854 ----
                                                                (line   6)
  * C variable interoperability:           Interoperable Global Variables.
                                                                (line   6)
+ * C_ASSOCIATED:                          C_ASSOCIATED.        (line   6)
+ * C_F_POINTER:                           C_F_POINTER.         (line   6)
+ * C_F_PROCPOINTER:                       C_F_PROCPOINTER.     (line   6)
+ * C_FUNLOC:                              C_FUNLOC.            (line   6)
+ * C_LOC:                                 C_LOC.               (line   6)
+ * C_SIZEOF:                              C_SIZEOF.            (line   6)
  * CABS:                                  ABS.                 (line   6)
  * calling convention:                    Code Gen Options.    (line  27)
  * CARRIAGECONTROL:                       Extended I/O specifiers.
*************** Keyword Index
*** 21874,21884 ****
  * clock ticks <2>:                       SYSTEM_CLOCK.        (line   6)
  * CLOG:                                  LOG.                 (line   6)
  * CMPLX:                                 CMPLX.               (line   6)
! * coarray, IMAGE_INDEX:                  IMAGE_INDEX.         (line   6)
! * coarray, lower bound:                  LCOBOUND.            (line   6)
! * coarray, NUM_IMAGES:                   NUM_IMAGES.          (line   6)
! * coarray, THIS_IMAGE:                   THIS_IMAGE.          (line   6)
! * coarray, upper bound:                  UCOBOUND.            (line   6)
  * Coarray, _gfortran_caf_atomic_cas:     _gfortran_caf_atomic_cas.
                                                                (line   6)
  * Coarray, _gfortran_caf_atomic_define:  _gfortran_caf_atomic_define.
--- 21880,21890 ----
  * clock ticks <2>:                       SYSTEM_CLOCK.        (line   6)
  * CLOG:                                  LOG.                 (line   6)
  * CMPLX:                                 CMPLX.               (line   6)
! * CO_BROADCAST:                          CO_BROADCAST.        (line   6)
! * CO_MAX:                                CO_MAX.              (line   6)
! * CO_MIN:                                CO_MIN.              (line   6)
! * CO_REDUCE:                             CO_REDUCE.           (line   6)
! * CO_SUM:                                CO_SUM.              (line   6)
  * Coarray, _gfortran_caf_atomic_cas:     _gfortran_caf_atomic_cas.
                                                                (line   6)
  * Coarray, _gfortran_caf_atomic_define:  _gfortran_caf_atomic_define.
*************** Keyword Index
*** 21909,21918 ****
                                                                (line   6)
  * Coarray, _gfortran_caf_event_wait:     _gfortran_caf_event_wait.
                                                                (line   6)
- * Coarray, _gfortran_caf_failed_images:  _gfortran_caf_failed_images.
-                                                               (line   6)
  * Coarray, _gfortran_caf_fail_image:     _gfortran_caf_fail_image.
                                                                (line   6)
  * Coarray, _gfortran_caf_finish:         _gfortran_caf_finish.
                                                                (line   6)
  * Coarray, _gfortran_caf_get:            _gfortran_caf_get.   (line   6)
--- 21915,21924 ----
                                                                (line   6)
  * Coarray, _gfortran_caf_event_wait:     _gfortran_caf_event_wait.
                                                                (line   6)
  * Coarray, _gfortran_caf_fail_image:     _gfortran_caf_fail_image.
                                                                (line   6)
+ * Coarray, _gfortran_caf_failed_images:  _gfortran_caf_failed_images.
+                                                               (line   6)
  * Coarray, _gfortran_caf_finish:         _gfortran_caf_finish.
                                                                (line   6)
  * Coarray, _gfortran_caf_get:            _gfortran_caf_get.   (line   6)
*************** Keyword Index
*** 21929,21940 ****
  * Coarray, _gfortran_caf_register:       _gfortran_caf_register.
                                                                (line   6)
  * Coarray, _gfortran_caf_send:           _gfortran_caf_send.  (line   6)
  * Coarray, _gfortran_caf_sendget:        _gfortran_caf_sendget.
                                                                (line   6)
  * Coarray, _gfortran_caf_sendget_by_ref: _gfortran_caf_sendget_by_ref.
                                                                (line   6)
- * Coarray, _gfortran_caf_send_by_ref:    _gfortran_caf_send_by_ref.
-                                                               (line   6)
  * Coarray, _gfortran_caf_stopped_images: _gfortran_caf_stopped_images.
                                                                (line   6)
  * Coarray, _gfortran_caf_sync_all:       _gfortran_caf_sync_all.
--- 21935,21946 ----
  * Coarray, _gfortran_caf_register:       _gfortran_caf_register.
                                                                (line   6)
  * Coarray, _gfortran_caf_send:           _gfortran_caf_send.  (line   6)
+ * Coarray, _gfortran_caf_send_by_ref:    _gfortran_caf_send_by_ref.
+                                                               (line   6)
  * Coarray, _gfortran_caf_sendget:        _gfortran_caf_sendget.
                                                                (line   6)
  * Coarray, _gfortran_caf_sendget_by_ref: _gfortran_caf_sendget_by_ref.
                                                                (line   6)
  * Coarray, _gfortran_caf_stopped_images: _gfortran_caf_stopped_images.
                                                                (line   6)
  * Coarray, _gfortran_caf_sync_all:       _gfortran_caf_sync_all.
*************** Keyword Index
*** 21947,21952 ****
--- 21953,21963 ----
                                                                (line   6)
  * Coarray, _gfortran_caf_unlock:         _gfortran_caf_unlock.
                                                                (line   6)
+ * coarray, IMAGE_INDEX:                  IMAGE_INDEX.         (line   6)
+ * coarray, lower bound:                  LCOBOUND.            (line   6)
+ * coarray, NUM_IMAGES:                   NUM_IMAGES.          (line   6)
+ * coarray, THIS_IMAGE:                   THIS_IMAGE.          (line   6)
+ * coarray, upper bound:                  UCOBOUND.            (line   6)
  * coarrays:                              Code Gen Options.    (line 129)
  * Coarrays:                              Coarray Programming. (line   6)
  * code generation, conventions:          Code Gen Options.    (line   6)
*************** Keyword Index
*** 21961,21966 ****
--- 21972,21979 ----
                                                                (line   6)
  * command options:                       Invoking GNU Fortran.
                                                                (line   6)
+ * COMMAND_ARGUMENT_COUNT:                COMMAND_ARGUMENT_COUNT.
+                                                               (line   6)
  * command-line arguments:                COMMAND_ARGUMENT_COUNT.
                                                                (line   6)
  * command-line arguments <1>:            GETARG.              (line   6)
*************** Keyword Index
*** 21971,21984 ****
  * command-line arguments, number of:     COMMAND_ARGUMENT_COUNT.
                                                                (line   6)
  * command-line arguments, number of <1>: IARGC.               (line   6)
- * COMMAND_ARGUMENT_COUNT:                COMMAND_ARGUMENT_COUNT.
-                                                               (line   6)
  * COMMON:                                Volatile COMMON blocks.
                                                                (line   6)
  * compiler flags inquiry function:       COMPILER_OPTIONS.    (line   6)
- * compiler, name and version:            COMPILER_VERSION.    (line   6)
  * COMPILER_OPTIONS:                      COMPILER_OPTIONS.    (line   6)
  * COMPILER_VERSION:                      COMPILER_VERSION.    (line   6)
  * COMPLEX:                               COMPLEX.             (line   6)
  * complex conjugate:                     CONJG.               (line   6)
  * Complex function:                      Alternate complex function syntax.
--- 21984,21995 ----
  * command-line arguments, number of:     COMMAND_ARGUMENT_COUNT.
                                                                (line   6)
  * command-line arguments, number of <1>: IARGC.               (line   6)
  * COMMON:                                Volatile COMMON blocks.
                                                                (line   6)
  * compiler flags inquiry function:       COMPILER_OPTIONS.    (line   6)
  * COMPILER_OPTIONS:                      COMPILER_OPTIONS.    (line   6)
  * COMPILER_VERSION:                      COMPILER_VERSION.    (line   6)
+ * compiler, name and version:            COMPILER_VERSION.    (line   6)
  * COMPLEX:                               COMPLEX.             (line   6)
  * complex conjugate:                     CONJG.               (line   6)
  * Complex function:                      Alternate complex function syntax.
*************** Keyword Index
*** 22036,22046 ****
  * cotangent:                             COTAN.               (line   6)
  * cotangent, degrees:                    COTAND.              (line   6)
  * COUNT:                                 COUNT.               (line   6)
- * CO_BROADCAST:                          CO_BROADCAST.        (line   6)
- * CO_MAX:                                CO_MAX.              (line   6)
- * CO_MIN:                                CO_MIN.              (line   6)
- * CO_REDUCE:                             CO_REDUCE.           (line   6)
- * CO_SUM:                                CO_SUM.              (line   6)
  * CPP:                                   Preprocessing Options.
                                                                (line   6)
  * CPU_TIME:                              CPU_TIME.            (line   6)
--- 22047,22052 ----
*************** Keyword Index
*** 22058,22069 ****
  * current time <2>:                      ITIME.               (line   6)
  * current time <3>:                      TIME.                (line   6)
  * current time <4>:                      TIME8.               (line   6)
- * C_ASSOCIATED:                          C_ASSOCIATED.        (line   6)
- * C_FUNLOC:                              C_FUNLOC.            (line   6)
- * C_F_POINTER:                           C_F_POINTER.         (line   6)
- * C_F_PROCPOINTER:                       C_F_PROCPOINTER.     (line   6)
- * C_LOC:                                 C_LOC.               (line   6)
- * C_SIZEOF:                              C_SIZEOF.            (line   6)
  * DABS:                                  ABS.                 (line   6)
  * DACOS:                                 ACOS.                (line   6)
  * DACOSD:                                ACOSD.               (line   6)
--- 22064,22069 ----
*************** Keyword Index
*** 22076,22085 ****
  * DATAN2D:                               ATAN2D.              (line   6)
  * DATAND:                                ATAND.               (line   6)
  * DATANH:                                ATANH.               (line   6)
  * date, current:                         DATE_AND_TIME.       (line   6)
  * date, current <1>:                     FDATE.               (line   6)
  * date, current <2>:                     IDATE.               (line   6)
- * DATE_AND_TIME:                         DATE_AND_TIME.       (line   6)
  * DBESJ0:                                BESSEL_J0.           (line   6)
  * DBESJ1:                                BESSEL_J1.           (line   6)
  * DBESJN:                                BESSEL_JN.           (line   6)
--- 22076,22085 ----
  * DATAN2D:                               ATAN2D.              (line   6)
  * DATAND:                                ATAND.               (line   6)
  * DATANH:                                ATANH.               (line   6)
+ * DATE_AND_TIME:                         DATE_AND_TIME.       (line   6)
  * date, current:                         DATE_AND_TIME.       (line   6)
  * date, current <1>:                     FDATE.               (line   6)
  * date, current <2>:                     IDATE.               (line   6)
  * DBESJ0:                                BESSEL_J0.           (line   6)
  * DBESJ1:                                BESSEL_J1.           (line   6)
  * DBESJN:                                BESSEL_JN.           (line   6)
*************** Keyword Index
*** 22183,22190 ****
  * ETIME:                                 ETIME.               (line   6)
  * Euclidean distance:                    HYPOT.               (line   6)
  * Euclidean vector norm:                 NORM2.               (line   6)
- * Events, EVENT_QUERY:                   EVENT_QUERY.         (line   6)
  * EVENT_QUERY:                           EVENT_QUERY.         (line   6)
  * EXECUTE_COMMAND_LINE:                  EXECUTE_COMMAND_LINE.
                                                                (line   6)
  * EXIT:                                  EXIT.                (line   6)
--- 22183,22190 ----
  * ETIME:                                 ETIME.               (line   6)
  * Euclidean distance:                    HYPOT.               (line   6)
  * Euclidean vector norm:                 NORM2.               (line   6)
  * EVENT_QUERY:                           EVENT_QUERY.         (line   6)
+ * Events, EVENT_QUERY:                   EVENT_QUERY.         (line   6)
  * EXECUTE_COMMAND_LINE:                  EXECUTE_COMMAND_LINE.
                                                                (line   6)
  * EXIT:                                  EXIT.                (line   6)
*************** Keyword Index
*** 22295,22300 ****
--- 22295,22305 ----
  * Generating C prototypes from Fortran BIND(C) enteties: Interoperability Options.
                                                                (line   6)
  * GERROR:                                GERROR.              (line   6)
+ * GET_COMMAND:                           GET_COMMAND.         (line   6)
+ * GET_COMMAND_ARGUMENT:                  GET_COMMAND_ARGUMENT.
+                                                               (line   6)
+ * GET_ENVIRONMENT_VARIABLE:              GET_ENVIRONMENT_VARIABLE.
+                                                               (line   6)
  * GETARG:                                GETARG.              (line   6)
  * GETCWD:                                GETCWD.              (line   6)
  * GETENV:                                GETENV.              (line   6)
*************** Keyword Index
*** 22302,22312 ****
  * GETLOG:                                GETLOG.              (line   6)
  * GETPID:                                GETPID.              (line   6)
  * GETUID:                                GETUID.              (line   6)
- * GET_COMMAND:                           GET_COMMAND.         (line   6)
- * GET_COMMAND_ARGUMENT:                  GET_COMMAND_ARGUMENT.
-                                                               (line   6)
- * GET_ENVIRONMENT_VARIABLE:              GET_ENVIRONMENT_VARIABLE.
-                                                               (line   6)
  * GMTIME:                                GMTIME.              (line   6)
  * GNU Compiler Collection:               GNU Fortran and GCC. (line   6)
  * GNU Fortran command options:           Invoking GNU Fortran.
--- 22307,22312 ----
*************** Keyword Index
*** 22356,22365 ****
  * IISHFT:                                ISHFT.               (line   6)
  * IISHFTC:                               ISHFTC.              (line   6)
  * IMAG:                                  AIMAG.               (line   6)
  * images, cosubscript to image index conversion: IMAGE_INDEX. (line   6)
  * images, index of this image:           THIS_IMAGE.          (line   6)
  * images, number of:                     NUM_IMAGES.          (line   6)
- * IMAGE_INDEX:                           IMAGE_INDEX.         (line   6)
  * IMAGPART:                              AIMAG.               (line   6)
  * IMOD:                                  MOD.                 (line   6)
  * IMVBITS:                               MVBITS.              (line   6)
--- 22356,22365 ----
  * IISHFT:                                ISHFT.               (line   6)
  * IISHFTC:                               ISHFTC.              (line   6)
  * IMAG:                                  AIMAG.               (line   6)
+ * IMAGE_INDEX:                           IMAGE_INDEX.         (line   6)
  * images, cosubscript to image index conversion: IMAGE_INDEX. (line   6)
  * images, index of this image:           THIS_IMAGE.          (line   6)
  * images, number of:                     NUM_IMAGES.          (line   6)
  * IMAGPART:                              AIMAG.               (line   6)
  * IMOD:                                  MOD.                 (line   6)
  * IMVBITS:                               MVBITS.              (line   6)
*************** Keyword Index
*** 22408,22421 ****
  * IOSTAT, end of record:                 IS_IOSTAT_EOR.       (line   6)
  * IPARITY:                               IPARITY.             (line   6)
  * IRAND:                                 IRAND.               (line   6)
  * ISATTY:                                ISATTY.              (line   6)
  * ISHFT:                                 ISHFT.               (line   6)
  * ISHFTC:                                ISHFTC.              (line   6)
  * ISIGN:                                 SIGN.                (line   6)
  * ISNAN:                                 ISNAN.               (line   6)
- * IS_IOSTAT_END:                         IS_IOSTAT_END.       (line   6)
- * IS_IOSTAT_EOR:                         IS_CONTIGUOUS.       (line   6)
- * IS_IOSTAT_EOR <1>:                     IS_IOSTAT_EOR.       (line   6)
  * ITIME:                                 ITIME.               (line   6)
  * JIABS:                                 ABS.                 (line   6)
  * JIAND:                                 IAND.                (line   6)
--- 22408,22421 ----
  * IOSTAT, end of record:                 IS_IOSTAT_EOR.       (line   6)
  * IPARITY:                               IPARITY.             (line   6)
  * IRAND:                                 IRAND.               (line   6)
+ * IS_IOSTAT_END:                         IS_IOSTAT_END.       (line   6)
+ * IS_IOSTAT_EOR:                         IS_CONTIGUOUS.       (line   6)
+ * IS_IOSTAT_EOR <1>:                     IS_IOSTAT_EOR.       (line   6)
  * ISATTY:                                ISATTY.              (line   6)
  * ISHFT:                                 ISHFT.               (line   6)
  * ISHFTC:                                ISHFTC.              (line   6)
  * ISIGN:                                 SIGN.                (line   6)
  * ISNAN:                                 ISNAN.               (line   6)
  * ITIME:                                 ITIME.               (line   6)
  * JIABS:                                 ABS.                 (line   6)
  * JIAND:                                 IAND.                (line   6)
*************** Keyword Index
*** 22490,22495 ****
--- 22490,22496 ----
  * LOC <1>:                               LOC.                 (line   6)
  * location of a variable in memory:      LOC.                 (line   6)
  * LOG:                                   LOG.                 (line   6)
+ * LOG_GAMMA:                             LOG_GAMMA.           (line   6)
  * LOG10:                                 LOG10.               (line   6)
  * logarithm function:                    LOG.                 (line   6)
  * logarithm function with base 10:       LOG10.               (line   6)
*************** Keyword Index
*** 22507,22513 ****
  * logical, variable representation:      Internal representation of LOGICAL variables.
                                                                (line   6)
  * login name:                            GETLOG.              (line   6)
- * LOG_GAMMA:                             LOG_GAMMA.           (line   6)
  * loop interchange, Fortran:             Code Gen Options.    (line 455)
  * loop interchange, warning:             Error and Warning Options.
                                                                (line 129)
--- 22508,22513 ----
*************** Keyword Index
*** 22574,22586 ****
  * moving allocation:                     MOVE_ALLOC.          (line   6)
  * multiply array elements:               PRODUCT.             (line   6)
  * MVBITS:                                MVBITS.              (line   6)
! * NAME:                                  OPEN( ... NAME=).    (line   6)
  * Namelist:                              Extensions to namelist.
                                                                (line   6)
  * natural logarithm function:            LOG.                 (line   6)
  * NEAREST:                               NEAREST.             (line   6)
- * newline:                               NEW_LINE.            (line   6)
  * NEW_LINE:                              NEW_LINE.            (line   6)
  * NINT:                                  NINT.                (line   6)
  * norm, Euclidean:                       NORM2.               (line   6)
  * NORM2:                                 NORM2.               (line   6)
--- 22574,22586 ----
  * moving allocation:                     MOVE_ALLOC.          (line   6)
  * multiply array elements:               PRODUCT.             (line   6)
  * MVBITS:                                MVBITS.              (line   6)
! * NAME:                                  OPEN( ... NAME=).    (line   6)
  * Namelist:                              Extensions to namelist.
                                                                (line   6)
  * natural logarithm function:            LOG.                 (line   6)
  * NEAREST:                               NEAREST.             (line   6)
  * NEW_LINE:                              NEW_LINE.            (line   6)
+ * newline:                               NEW_LINE.            (line   6)
  * NINT:                                  NINT.                (line   6)
  * norm, Euclidean:                       NORM2.               (line   6)
  * NORM2:                                 NORM2.               (line   6)
*************** Keyword Index
*** 22598,22604 ****
                                                                (line 176)
  * OpenMP <1>:                            OpenMP.              (line   6)
  * operators, unary:                      Unary operators.     (line   6)
! * operators, xor:                        .XOR. operator.      (line   6)
  * options inquiry function:              COMPILER_OPTIONS.    (line   6)
  * options, code generation:              Code Gen Options.    (line   6)
  * options, debugging:                    Debugging Options.   (line   6)
--- 22598,22604 ----
                                                                (line 176)
  * OpenMP <1>:                            OpenMP.              (line   6)
  * operators, unary:                      Unary operators.     (line   6)
! * operators, xor:                        .XOR. operator.      (line   6)
  * options inquiry function:              COMPILER_OPTIONS.    (line   6)
  * options, code generation:              Code Gen Options.    (line   6)
  * options, debugging:                    Debugging Options.   (line   6)
*************** Keyword Index
*** 22880,22885 ****
--- 22880,22886 ----
  * syntax checking:                       Error and Warning Options.
                                                                (line  32)
  * SYSTEM:                                SYSTEM.              (line   6)
+ * SYSTEM_CLOCK:                          SYSTEM_CLOCK.        (line   6)
  * system, error handling:                GERROR.              (line   6)
  * system, error handling <1>:            IERRNO.              (line   6)
  * system, error handling <2>:            PERROR.              (line   6)
*************** Keyword Index
*** 22896,22902 ****
  * system, user ID:                       GETUID.              (line   6)
  * system, working directory:             CHDIR.               (line   6)
  * system, working directory <1>:         GETCWD.              (line   6)
- * SYSTEM_CLOCK:                          SYSTEM_CLOCK.        (line   6)
  * tabulators:                            Error and Warning Options.
                                                                (line 192)
  * TAN:                                   TAN.                 (line   6)
--- 22897,22902 ----
*************** Keyword Index
*** 23072,23534 ****
  
  
  Tag Table:
! Node: Top1950
! Node: Introduction3270
! Node: About GNU Fortran3617
! Node: GNU Fortran and GCC8601
! Node: Standards10678
! Node: Fortran 95 status12471
! Node: Fortran 2003 status13445
! Node: Fortran 2008 status13895
! Node: Fortran 2018 status14553
! Node: Invoking GNU Fortran16156
! Node: Option Summary17990
! Node: Fortran Dialect Options22205
! Node: Preprocessing Options36944
! Node: Error and Warning Options46942
! Node: Debugging Options59096
! Node: Directory Options64299
! Node: Link Options65734
! Node: Runtime Options66865
! Node: Code Gen Options69121
! Node: Interoperability Options90219
! Node: Environment Variables92294
! Node: Runtime92907
! Node: TMPDIR94078
! Node: GFORTRAN_STDIN_UNIT94748
! Node: GFORTRAN_STDOUT_UNIT95130
! Node: GFORTRAN_STDERR_UNIT95531
! Node: GFORTRAN_UNBUFFERED_ALL95933
! Node: GFORTRAN_UNBUFFERED_PRECONNECTED96464
! Node: GFORTRAN_SHOW_LOCUS97108
! Node: GFORTRAN_OPTIONAL_PLUS97604
! Node: GFORTRAN_LIST_SEPARATOR98082
! Node: GFORTRAN_CONVERT_UNIT98690
! Node: GFORTRAN_ERROR_BACKTRACE101975
! Node: GFORTRAN_FORMATTED_BUFFER_SIZE102571
! Node: GFORTRAN_UNFORMATTED_BUFFER_SIZE103019
! Node: Compiler Characteristics103448
! Node: KIND Type Parameters104247
! Node: Internal representation of LOGICAL variables105675
! Node: Evaluation of logical expressions106532
! Node: MAX and MIN intrinsics with REAL NaN arguments107383
! Node: Thread-safety of the runtime library108204
! Node: Data consistency and durability110609
! Node: Files opened without an explicit ACTION= specifier113722
! Node: File operations on symbolic links114413
! Node: File format of unformatted sequential files115533
! Node: Asynchronous I/O117907
! Node: Behavior on integer overflow118644
! Node: Extensions119417
! Node: Extensions implemented in GNU Fortran120022
! Node: Old-style kind specifications121996
! Node: Old-style variable initialization123098
! Node: Extensions to namelist124410
! Node: X format descriptor without count field126713
! Node: Commas in FORMAT specifications127240
! Node: Missing period in FORMAT specifications127991
! Node: Default widths for F, G and I format descriptors128587
! Node: I/O item lists129292
! Node: Q exponent-letter129686
! Node: BOZ literal constants130284
! Node: Real array indices131861
! Node: Unary operators132160
! Node: Implicitly convert LOGICAL and INTEGER values132574
! Node: Hollerith constants support133533
! Node: Character conversion135757
! Node: Cray pointers136651
! Node: CONVERT specifier142152
! Node: OpenMP144467
! Node: OpenACC146716
! Node: Argument list functions147857
! Node: Read/Write after EOF marker149500
! Node: STRUCTURE and RECORD150103
! Node: UNION and MAP155190
! Node: Type variants for integer intrinsics158158
! Node: AUTOMATIC and STATIC attributes160053
! Node: Extended math intrinsics161587
! Node: Form feed as whitespace163383
! Node: TYPE as an alias for PRINT163929
! Node: %LOC as an rvalue164394
! Node: .XOR. operator165041
! Node: Bitwise logical operators165441
! Node: Extended I/O specifiers166942
! Node: Legacy PARAMETER statements170662
! Node: Default exponents171267
! Node: Extensions not implemented in GNU Fortran171619
! Node: ENCODE and DECODE statements172586
! Node: Variable FORMAT expressions173917
! Node: Alternate complex function syntax175022
! Node: Volatile COMMON blocks175572
! Node: OPEN( ... NAME=)176074
! Node: Q edit descriptor176502
! Node: Mixed-Language Programming177454
! Node: Interoperability with C178687
! Node: Intrinsic Types180022
! Node: Derived Types and struct181043
! Node: Interoperable Global Variables182385
! Node: Interoperable Subroutines and Functions183660
! Node: Working with C Pointers187151
! Node: Further Interoperability of Fortran with C191816
! Node: GNU Fortran Compiler Directives193160
! Node: ATTRIBUTES directive193536
! Node: UNROLL directive197359
! Node: BUILTIN directive197892
! Node: IVDEP directive198734
! Node: VECTOR directive199553
! Node: NOVECTOR directive199951
! Node: Non-Fortran Main Program200336
! Node: _gfortran_set_args202524
! Node: _gfortran_set_options203462
! Node: _gfortran_set_convert207130
! Node: _gfortran_set_record_marker207998
! Node: _gfortran_set_fpe208808
! Node: _gfortran_set_max_subrecord_length210006
! Node: Naming and argument-passing conventions210929
! Node: Naming conventions211648
! Node: Argument passing conventions213120
! Node: Coarray Programming218458
! Node: Type and enum ABI Documentation218705
! Node: caf_token_t219003
! Node: caf_register_t219239
! Node: caf_deregister_t220450
! Node: caf_reference_t220952
! Node: caf_team_t225277
! Node: Function ABI Documentation225576
! Node: _gfortran_caf_init228026
! Node: _gfortran_caf_finish229452
! Node: _gfortran_caf_this_image230391
! Node: _gfortran_caf_num_images231146
! Node: _gfortran_caf_image_status232257
! Node: _gfortran_caf_failed_images233377
! Node: _gfortran_caf_stopped_images234547
! Node: _gfortran_caf_register235720
! Node: _gfortran_caf_deregister239901
! Node: _gfortran_caf_is_present241507
! Node: _gfortran_caf_send242586
! Node: _gfortran_caf_get245776
! Node: _gfortran_caf_sendget248857
! Node: _gfortran_caf_send_by_ref252768
! Node: _gfortran_caf_get_by_ref256377
! Node: _gfortran_caf_sendget_by_ref259896
! Node: _gfortran_caf_lock264192
! Node: _gfortran_caf_unlock265981
! Node: _gfortran_caf_event_post267462
! Node: _gfortran_caf_event_wait268911
! Node: _gfortran_caf_event_query271018
! Node: _gfortran_caf_sync_all272349
! Node: _gfortran_caf_sync_images273277
! Node: _gfortran_caf_sync_memory274812
! Node: _gfortran_caf_error_stop275804
! Node: _gfortran_caf_error_stop_str276408
! Node: _gfortran_caf_fail_image277113
! Node: _gfortran_caf_atomic_define277649
! Node: _gfortran_caf_atomic_ref278964
! Node: _gfortran_caf_atomic_cas280268
! Node: _gfortran_caf_atomic_op282029
! Node: _gfortran_caf_co_broadcast284131
! Node: _gfortran_caf_co_max285236
! Node: _gfortran_caf_co_min286862
! Node: _gfortran_caf_co_sum288482
! Node: _gfortran_caf_co_reduce290022
! Node: Intrinsic Procedures292666
! Node: Introduction to Intrinsics309870
! Node: ABORT312064
! Node: ABS312819
! Node: ACCESS314543
! Node: ACHAR316444
! Node: ACOS317658
! Node: ACOSD318947
! Node: ACOSH320362
! Node: ADJUSTL321448
! Node: ADJUSTR322395
! Node: AIMAG323350
! Node: AINT324800
! Node: ALARM326394
! Node: ALL328026
! Node: ALLOCATED329950
! Node: AND331089
! Node: ANINT332829
! Node: ANY334314
! Node: ASIN336240
! Node: ASIND337518
! Node: ASINH338919
! Node: ASSOCIATED340015
! Node: ATAN343026
! Node: ATAND344502
! Node: ATAN2346108
! Node: ATAN2D347977
! Node: ATANH350018
! Node: ATOMIC_ADD351114
! Node: ATOMIC_AND352663
! Node: ATOMIC_CAS354266
! Node: ATOMIC_DEFINE356135
! Node: ATOMIC_FETCH_ADD357874
! Node: ATOMIC_FETCH_AND359691
! Node: ATOMIC_FETCH_OR361496
! Node: ATOMIC_FETCH_XOR363288
! Node: ATOMIC_OR365086
! Node: ATOMIC_REF366686
! Node: ATOMIC_XOR368602
! Node: BACKTRACE370202
! Node: BESSEL_J0370782
! Node: BESSEL_J1371883
! Node: BESSEL_JN372985
! Node: BESSEL_Y0374890
! Node: BESSEL_Y1375930
! Node: BESSEL_YN376970
! Node: BGE378886
! Node: BGT379588
! Node: BIT_SIZE380248
! Node: BLE381070
! Node: BLT381762
! Node: BTEST382410
! Node: C_ASSOCIATED383855
! Node: C_F_POINTER385071
! Node: C_F_PROCPOINTER386511
! Node: C_FUNLOC388023
! Node: C_LOC389404
! Node: C_SIZEOF390693
! Node: CEILING392106
! Node: CHAR393119
! Node: CHDIR394433
! Node: CHMOD395607
! Node: CMPLX397522
! Node: CO_BROADCAST398965
! Node: CO_MAX400792
! Node: CO_MIN402700
! Node: CO_REDUCE404594
! Node: CO_SUM408170
! Node: COMMAND_ARGUMENT_COUNT410151
! Node: COMPILER_OPTIONS411073
! Node: COMPILER_VERSION412103
! Node: COMPLEX413071
! Node: CONJG414210
! Node: COS415266
! Node: COSD416637
! Node: COSH418129
! Node: COTAN419305
! Node: COTAND420547
! Node: COUNT421829
! Node: CPU_TIME423854
! Node: CSHIFT425216
! Node: CTIME426876
! Node: DATE_AND_TIME428399
! Node: DBLE430620
! Node: DCMPLX431415
! Node: DIGITS432597
! Node: DIM433564
! Node: DOT_PRODUCT434972
! Node: DPROD436615
! Node: DREAL437577
! Node: DSHIFTL438243
! Node: DSHIFTR439576
! Node: DTIME440910
! Node: EOSHIFT443616
! Node: EPSILON445689
! Node: ERF446416
! Node: ERFC447282
! Node: ERFC_SCALED448177
! Node: ETIME448870
! Node: EVENT_QUERY451040
! Node: EXECUTE_COMMAND_LINE452629
! Node: EXIT455409
! Node: EXP456292
! Node: EXPONENT457446
! Node: EXTENDS_TYPE_OF458210
! Node: FDATE459068
! Node: FGET460559
! Node: FGETC462396
! Node: FINDLOC464216
! Node: FLOOR466815
! Node: FLUSH467811
! Node: FNUM469690
! Node: FPUT470415
! Node: FPUTC472059
! Node: FRACTION473850
! Node: FREE474754
! Node: FSEEK475597
! Node: FSTAT477903
! Node: FTELL479004
! Node: GAMMA479986
! Node: GERROR481066
! Node: GETARG481819
! Node: GET_COMMAND483558
! Node: GET_COMMAND_ARGUMENT484937
! Node: GETCWD486989
! Node: GETENV487969
! Node: GET_ENVIRONMENT_VARIABLE489401
! Node: GETGID491564
! Node: GETLOG492106
! Node: GETPID492964
! Node: GETUID493699
! Node: GMTIME494220
! Node: HOSTNM495995
! Node: HUGE496916
! Node: HYPOT497638
! Node: IACHAR498464
! Node: IALL499642
! Node: IAND501137
! Node: IANY502894
! Node: IARGC504398
! Node: IBCLR505432
! Node: IBITS506655
! Node: IBSET508134
! Node: ICHAR509352
! Node: IDATE511567
! Node: IEOR512867
! Node: IERRNO514517
! Node: IMAGE_INDEX515065
! Node: INDEX intrinsic516092
! Node: INT517713
! Node: INT2519495
! Node: INT8520201
! Node: IOR520907
! Node: IPARITY522533
! Node: IRAND524096
! Node: IS_CONTIGUOUS525455
! Node: IS_IOSTAT_END526621
! Node: IS_IOSTAT_EOR527728
! Node: ISATTY528857
! Node: ISHFT529638
! Node: ISHFTC531162
! Node: ISNAN532924
! Node: ITIME533691
! Node: KILL534989
! Node: KIND536130
! Node: LBOUND537028
! Node: LCOBOUND538371
! Node: LEADZ539511
! Node: LEN540387
! Node: LEN_TRIM541728
! Node: LGE542726
! Node: LGT544339
! Node: LINK545917
! Node: LLE546961
! Node: LLT548561
! Node: LNBLNK550132
! Node: LOC550915
! Node: LOG551647
! Node: LOG10553083
! Node: LOG_GAMMA554061
! Node: LOGICAL555259
! Node: LSHIFT556083
! Node: LSTAT557215
! Node: LTIME558429
! Node: MALLOC560126
! Node: MASKL561588
! Node: MASKR562355
! Node: MATMUL563125
! Node: MAX564285
! Node: MAXEXPONENT565677
! Node: MAXLOC566494
! Node: MAXVAL569112
! Node: MCLOCK570759
! Node: MCLOCK8571797
! Node: MERGE573042
! Node: MERGE_BITS573794
! Node: MIN574833
! Node: MINEXPONENT576228
! Node: MINLOC576859
! Node: MINVAL579508
! Node: MOD581157
! Node: MODULO583342
! Node: MOVE_ALLOC584807
! Node: MVBITS585840
! Node: NEAREST587467
! Node: NEW_LINE588567
! Node: NINT589340
! Node: NORM2590754
! Node: NOT591893
! Node: NULL593038
! Node: NUM_IMAGES593946
! Node: OR595652
! Node: PACK597380
! Node: PARITY599424
! Node: PERROR600645
! Node: POPCNT601270
! Node: POPPAR602151
! Node: PRECISION603214
! Node: PRESENT604151
! Node: PRODUCT605263
! Node: RADIX606797
! Node: RAN607608
! Node: RAND608069
! Node: RANDOM_INIT609407
! Node: RANDOM_NUMBER611483
! Node: RANDOM_SEED612740
! Node: RANGE615215
! Node: RANK615900
! Node: REAL616681
! Node: RENAME618760
! Node: REPEAT619782
! Node: RESHAPE620510
! Node: RRSPACING621977
! Node: RSHIFT622670
! Node: SAME_TYPE_AS623858
! Node: SCALE624690
! Node: SCAN625471
! Node: SECNDS627034
! Node: SECOND628126
! Node: SELECTED_CHAR_KIND629002
! Node: SELECTED_INT_KIND630597
! Node: SELECTED_REAL_KIND631774
! Node: SET_EXPONENT634460
! Node: SHAPE635447
! Node: SHIFTA636876
! Node: SHIFTL637872
! Node: SHIFTR638737
! Node: SIGN639603
! Node: SIGNAL640894
! Node: SIN642400
! Node: SIND643580
! Node: SINH644952
! Node: SIZE645905
! Node: SIZEOF647229
! Node: SLEEP648889
! Node: SPACING649450
! Node: SPREAD650464
! Node: SQRT651615
! Node: SRAND652848
! Node: STAT654092
! Node: STORAGE_SIZE657274
! Node: SUM658158
! Node: SYMLNK659650
! Node: SYSTEM660790
! Node: SYSTEM_CLOCK662045
! Node: TAN664898
! Node: TAND665972
! Node: TANH667159
! Node: THIS_IMAGE668322
! Node: TIME670627
! Node: TIME8671818
! Node: TINY673037
! Node: TRAILZ673638
! Node: TRANSFER674471
! Node: TRANSPOSE676507
! Node: TRIM677197
! Node: TTYNAM678060
! Node: UBOUND678976
! Node: UCOBOUND680371
! Node: UMASK681513
! Node: UNLINK682195
! Node: UNPACK683180
! Node: VERIFY684480
! Node: XOR686214
! Node: Intrinsic Modules688029
! Node: ISO_FORTRAN_ENV688316
! Node: ISO_C_BINDING692717
! Node: IEEE modules696662
! Node: OpenMP Modules OMP_LIB and OMP_LIB_KINDS697803
! Node: OpenACC Module OPENACC701609
! Node: Contributing702535
! Node: Contributors703365
! Node: Projects705019
! Node: Copying706197
! Node: GNU Free Documentation License743748
! Node: Funding768877
! Node: Option Index771403
! Node: Keyword Index790537
  
  End Tag Table
  
--- 23072,23534 ----
  
  
  Tag Table:
! Node: Top1952
! Node: Introduction3284
! Node: About GNU Fortran3631
! Node: GNU Fortran and GCC8739
! Node: Standards10940
! Node: Fortran 95 status12737
! Node: Fortran 2003 status13719
! Node: Fortran 2008 status14169
! Node: Fortran 2018 status14843
! Node: Invoking GNU Fortran16544
! Node: Option Summary18422
! Node: Fortran Dialect Options22637
! Node: Preprocessing Options38172
! Node: Error and Warning Options48602
! Node: Debugging Options61324
! Node: Directory Options66695
! Node: Link Options68206
! Node: Runtime Options69365
! Node: Code Gen Options71709
! Node: Interoperability Options93595
! Node: Environment Variables95730
! Node: Runtime96355
! Node: TMPDIR97530
! Node: GFORTRAN_STDIN_UNIT98232
! Node: GFORTRAN_STDOUT_UNIT98618
! Node: GFORTRAN_STDERR_UNIT99023
! Node: GFORTRAN_UNBUFFERED_ALL99429
! Node: GFORTRAN_UNBUFFERED_PRECONNECTED99988
! Node: GFORTRAN_SHOW_LOCUS100664
! Node: GFORTRAN_OPTIONAL_PLUS101188
! Node: GFORTRAN_LIST_SEPARATOR101694
! Node: GFORTRAN_CONVERT_UNIT102310
! Node: GFORTRAN_ERROR_BACKTRACE105711
! Node: GFORTRAN_FORMATTED_BUFFER_SIZE106343
! Node: GFORTRAN_UNFORMATTED_BUFFER_SIZE106799
! Node: Compiler Characteristics107236
! Node: KIND Type Parameters108035
! Node: Internal representation of LOGICAL variables109555
! Node: Evaluation of logical expressions110452
! Node: MAX and MIN intrinsics with REAL NaN arguments111315
! Node: Thread-safety of the runtime library112168
! Node: Data consistency and durability114653
! Node: Files opened without an explicit ACTION= specifier117826
! Node: File operations on symbolic links118537
! Node: File format of unformatted sequential files119683
! Node: Asynchronous I/O122069
! Node: Behavior on integer overflow122818
! Node: Extensions123603
! Node: Extensions implemented in GNU Fortran124208
! Node: Old-style kind specifications126214
! Node: Old-style variable initialization127376
! Node: Extensions to namelist128712
! Node: X format descriptor without count field131063
! Node: Commas in FORMAT specifications131602
! Node: Missing period in FORMAT specifications132365
! Node: Default widths for F, G and I format descriptors132971
! Node: I/O item lists133694
! Node: Q exponent-letter134102
! Node: BOZ literal constants134736
! Node: Real array indices136413
! Node: Unary operators136716
! Node: Implicitly convert LOGICAL and INTEGER values137130
! Node: Hollerith constants support138153
! Node: Character conversion140437
! Node: Cray pointers141355
! Node: CONVERT specifier146968
! Node: OpenMP149371
! Node: OpenACC151692
! Node: Argument list functions152885
! Node: Read/Write after EOF marker154580
! Node: STRUCTURE and RECORD155199
! Node: UNION and MAP160362
! Node: Type variants for integer intrinsics163363
! Node: AUTOMATIC and STATIC attributes165522
! Node: Extended math intrinsics167120
! Node: Form feed as whitespace168992
! Node: TYPE as an alias for PRINT169538
! Node: %LOC as an rvalue170015
! Node: .XOR. operator170682
! Node: Bitwise logical operators171098
! Node: Extended I/O specifiers172683
! Node: Legacy PARAMETER statements176531
! Node: Default exponents177148
! Node: Extensions not implemented in GNU Fortran177512
! Node: ENCODE and DECODE statements178479
! Node: Variable FORMAT expressions179838
! Node: Alternate complex function syntax180955
! Node: Volatile COMMON blocks181521
! Node: OPEN( ... NAME=)182055
! Node: Q edit descriptor182507
! Node: Mixed-Language Programming183495
! Node: Interoperability with C184752
! Node: Intrinsic Types186123
! Node: Derived Types and struct187176
! Node: Interoperable Global Variables188546
! Node: Interoperable Subroutines and Functions189845
! Node: Working with C Pointers193388
! Node: Further Interoperability of Fortran with C198109
! Node: GNU Fortran Compiler Directives199477
! Node: ATTRIBUTES directive199853
! Node: UNROLL directive203856
! Node: BUILTIN directive204397
! Node: IVDEP directive205255
! Node: VECTOR directive206082
! Node: NOVECTOR directive206488
! Node: Non-Fortran Main Program206881
! Node: _gfortran_set_args209097
! Node: _gfortran_set_options210051
! Node: _gfortran_set_convert213831
! Node: _gfortran_set_record_marker214711
! Node: _gfortran_set_fpe215533
! Node: _gfortran_set_max_subrecord_length216767
! Node: Naming and argument-passing conventions217702
! Node: Naming conventions218421
! Node: Argument passing conventions219965
! Node: Coarray Programming225453
! Node: Type and enum ABI Documentation225700
! Node: caf_token_t225998
! Node: caf_register_t226242
! Node: caf_deregister_t227473
! Node: caf_reference_t227983
! Node: caf_team_t232340
! Node: Function ABI Documentation232643
! Node: _gfortran_caf_init235093
! Node: _gfortran_caf_finish236547
! Node: _gfortran_caf_this_image237498
! Node: _gfortran_caf_num_images238273
! Node: _gfortran_caf_image_status239400
! Node: _gfortran_caf_failed_images240540
! Node: _gfortran_caf_stopped_images241718
! Node: _gfortran_caf_register242899
! Node: _gfortran_caf_deregister247172
! Node: _gfortran_caf_is_present248794
! Node: _gfortran_caf_send249881
! Node: _gfortran_caf_get253099
! Node: _gfortran_caf_sendget256208
! Node: _gfortran_caf_send_by_ref260147
! Node: _gfortran_caf_get_by_ref263788
! Node: _gfortran_caf_sendget_by_ref267343
! Node: _gfortran_caf_lock271679
! Node: _gfortran_caf_unlock273484
! Node: _gfortran_caf_event_post274973
! Node: _gfortran_caf_event_wait276434
! Node: _gfortran_caf_event_query278553
! Node: _gfortran_caf_sync_all279896
! Node: _gfortran_caf_sync_images280832
! Node: _gfortran_caf_sync_memory282387
! Node: _gfortran_caf_error_stop283391
! Node: _gfortran_caf_error_stop_str284007
! Node: _gfortran_caf_fail_image284724
! Node: _gfortran_caf_atomic_define285272
! Node: _gfortran_caf_atomic_ref286607
! Node: _gfortran_caf_atomic_cas287931
! Node: _gfortran_caf_atomic_op289716
! Node: _gfortran_caf_co_broadcast291862
! Node: _gfortran_caf_co_max292975
! Node: _gfortran_caf_co_min294609
! Node: _gfortran_caf_co_sum296237
! Node: _gfortran_caf_co_reduce297785
! Node: Intrinsic Procedures300453
! Node: Introduction to Intrinsics318785
! Node: ABORT321047
! Node: ABS321822
! Node: ACCESS323702
! Node: ACHAR325671
! Node: ACOS326913
! Node: ACOSD328250
! Node: ACOSH329717
! Node: ADJUSTL330835
! Node: ADJUSTR331802
! Node: AIMAG332777
! Node: AINT334311
! Node: ALARM335957
! Node: ALL337649
! Node: ALLOCATED339621
! Node: AND340804
! Node: ANINT342580
! Node: ANY344121
! Node: ASIN346099
! Node: ASIND347425
! Node: ASINH348878
! Node: ASSOCIATED350006
! Node: ATAN353045
! Node: ATAND354573
! Node: ATAN2356235
! Node: ATAN2D358144
! Node: ATANH360229
! Node: ATOMIC_ADD361357
! Node: ATOMIC_AND362934
! Node: ATOMIC_CAS364565
! Node: ATOMIC_DEFINE366466
! Node: ATOMIC_FETCH_ADD368237
! Node: ATOMIC_FETCH_AND370086
! Node: ATOMIC_FETCH_OR371919
! Node: ATOMIC_FETCH_XOR373739
! Node: ATOMIC_OR375565
! Node: ATOMIC_REF377193
! Node: ATOMIC_XOR379141
! Node: BACKTRACE380769
! Node: BESSEL_J0381369
! Node: BESSEL_J1382506
! Node: BESSEL_JN383644
! Node: BESSEL_Y0385617
! Node: BESSEL_Y1386693
! Node: BESSEL_YN387769
! Node: BGE389753
! Node: BGT390475
! Node: BIT_SIZE391155
! Node: BLE392001
! Node: BLT392713
! Node: BTEST393381
! Node: C_ASSOCIATED394914
! Node: C_F_POINTER396158
! Node: C_F_PROCPOINTER397630
! Node: C_FUNLOC399166
! Node: C_LOC400563
! Node: C_SIZEOF401868
! Node: CEILING403329
! Node: CHAR404370
! Node: CHDIR405720
! Node: CHMOD406914
! Node: CMPLX408885
! Node: CO_BROADCAST410376
! Node: CO_MAX412219
! Node: CO_MIN414139
! Node: CO_REDUCE416045
! Node: CO_SUM419637
! Node: COMMAND_ARGUMENT_COUNT421630
! Node: COMPILER_OPTIONS422568
! Node: COMPILER_VERSION423618
! Node: COMPLEX424602
! Node: CONJG425797
! Node: COS426893
! Node: COSD428348
! Node: COSH429928
! Node: COTAN431152
! Node: COTAND432454
! Node: COUNT433796
! Node: CPU_TIME435857
! Node: CSHIFT437251
! Node: CTIME438939
! Node: DATE_AND_TIME440494
! Node: DBLE442791
! Node: DCMPLX443610
! Node: DIGITS444832
! Node: DIM445823
! Node: DOT_PRODUCT447299
! Node: DPROD449018
! Node: DREAL450020
! Node: DSHIFTL450706
! Node: DSHIFTR452075
! Node: DTIME453445
! Node: EOSHIFT456215
! Node: EPSILON458320
! Node: ERF459063
! Node: ERFC459961
! Node: ERFC_SCALED460888
! Node: ETIME461601
! Node: EVENT_QUERY463823
! Node: EXECUTE_COMMAND_LINE465436
! Node: EXIT468308
! Node: EXP469211
! Node: EXPONENT470445
! Node: EXTENDS_TYPE_OF471229
! Node: FDATE472095
! Node: FGET473614
! Node: FGETC475479
! Node: FINDLOC477331
! Node: FLOOR479970
! Node: FLUSH480994
! Node: FNUM482909
! Node: FPUT483658
! Node: FPUTC485330
! Node: FRACTION487153
! Node: FREE488085
! Node: FSEEK488956
! Node: FSTAT491310
! Node: FTELL492443
! Node: GAMMA493445
! Node: GERROR494557
! Node: GETARG495326
! Node: GET_COMMAND497085
! Node: GET_COMMAND_ARGUMENT498484
! Node: GETCWD500564
! Node: GETENV501560
! Node: GET_ENVIRONMENT_VARIABLE503016
! Node: GETGID505219
! Node: GETLOG505781
! Node: GETPID506663
! Node: GETUID507414
! Node: GMTIME507955
! Node: HOSTNM509758
! Node: HUGE510699
! Node: HYPOT511445
! Node: IACHAR512287
! Node: IALL513497
! Node: IAND515020
! Node: IANY516865
! Node: IARGC518397
! Node: IBCLR519447
! Node: IBITS520754
! Node: IBSET522329
! Node: ICHAR523631
! Node: IDATE525906
! Node: IEOR527222
! Node: IERRNO528960
! Node: IMAGE_INDEX529524
! Node: INDEX intrinsic530559
! Node: INT532232
! Node: INT2534106
! Node: INT8534848
! Node: IOR535590
! Node: IPARITY537304
! Node: IRAND538895
! Node: IS_CONTIGUOUS540286
! Node: IS_IOSTAT_END541472
! Node: IS_IOSTAT_EOR542619
! Node: ISATTY543788
! Node: ISHFT544589
! Node: ISHFTC546201
! Node: ISNAN548059
! Node: ITIME548854
! Node: KILL550168
! Node: KIND551349
! Node: LBOUND552283
! Node: LCOBOUND553646
! Node: LEADZ554806
! Node: LEN555710
! Node: LEN_TRIM557087
! Node: LGE558109
! Node: LGT559794
! Node: LINK561444
! Node: LLE562520
! Node: LLT564192
! Node: LNBLNK565835
! Node: LOC566642
! Node: LOG567394
! Node: LOG10568922
! Node: LOG_GAMMA569948
! Node: LOGICAL571202
! Node: LSHIFT572050
! Node: LSTAT573218
! Node: LTIME574464
! Node: MALLOC576189
! Node: MASKL577695
! Node: MASKR578486
! Node: MATMUL579280
! Node: MAX580488
! Node: MAXEXPONENT581956
! Node: MAXLOC582797
! Node: MAXVAL585463
! Node: MCLOCK587150
! Node: MCLOCK8588216
! Node: MERGE589501
! Node: MERGE_BITS590273
! Node: MIN591336
! Node: MINEXPONENT592807
! Node: MINLOC593466
! Node: MINVAL596167
! Node: MOD597860
! Node: MODULO600153
! Node: MOVE_ALLOC601662
! Node: MVBITS602723
! Node: NEAREST604458
! Node: NEW_LINE605614
! Node: NINT606403
! Node: NORM2607865
! Node: NOT609020
! Node: NULL610245
! Node: NUM_IMAGES611161
! Node: OR612879
! Node: PACK614643
! Node: PARITY616711
! Node: PERROR617956
! Node: POPCNT618601
! Node: POPPAR619506
! Node: PRECISION620601
! Node: PRESENT621566
! Node: PRODUCT622694
! Node: RADIX624264
! Node: RAN625099
! Node: RAND625572
! Node: RANDOM_INIT626942
! Node: RANDOM_NUMBER629074
! Node: RANDOM_SEED630347
! Node: RANGE632878
! Node: RANK633599
! Node: REAL634396
! Node: RENAME636603
! Node: REPEAT637657
! Node: RESHAPE638405
! Node: RRSPACING639888
! Node: RSHIFT640601
! Node: SAME_TYPE_AS641821
! Node: SCALE642661
! Node: SCAN643470
! Node: SECNDS645069
! Node: SECOND646181
! Node: SELECTED_CHAR_KIND647081
! Node: SELECTED_INT_KIND648688
! Node: SELECTED_REAL_KIND649885
! Node: SET_EXPONENT652683
! Node: SHAPE653694
! Node: SHIFTA655139
! Node: SHIFTL656163
! Node: SHIFTR657056
! Node: SIGN657950
! Node: SIGNAL659305
! Node: SIN660875
! Node: SIND662135
! Node: SINH663591
! Node: SIZE664576
! Node: SIZEOF665920
! Node: SLEEP667616
! Node: SPACING668189
! Node: SPREAD669215
! Node: SQRT670382
! Node: SRAND671703
! Node: STAT673007
! Node: STORAGE_SIZE676269
! Node: SUM677161
! Node: SYMLNK678689
! Node: SYSTEM679869
! Node: SYSTEM_CLOCK681160
! Node: TAN684073
! Node: TAND685191
! Node: TANH686426
! Node: THIS_IMAGE687637
! Node: TIME689962
! Node: TIME8691173
! Node: TINY692424
! Node: TRAILZ693049
! Node: TRANSFER693910
! Node: TRANSPOSE695970
! Node: TRIM696680
! Node: TTYNAM697559
! Node: UBOUND698499
! Node: UCOBOUND699914
! Node: UMASK701076
! Node: UNLINK701782
! Node: UNPACK702795
! Node: VERIFY704115
! Node: XOR705885
! Node: Intrinsic Modules707736
! Node: ISO_FORTRAN_ENV708023
! Node: ISO_C_BINDING712612
! Node: IEEE modules717109
! Node: OpenMP Modules OMP_LIB and OMP_LIB_KINDS718294
! Node: OpenACC Module OPENACC722488
! Node: Contributing723450
! Node: Contributors724280
! Node: Projects726012
! Node: Copying727190
! Node: GNU Free Documentation License764756
! Node: Funding789888
! Node: Option Index792413
! Node: Keyword Index811559
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/gcc/fortran/match.cc gcc-13.5.0-RC-20260904/gcc/fortran/match.cc
*** gcc-13.4.0/gcc/fortran/match.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/match.cc	Fri Sep  4 07:35:08 2026
*************** gfc_match_select_type (void)
*** 6574,6585 ****
    else
      {
        m = gfc_match (" %e ", &expr1);
!       if (m != MATCH_YES)
  	{
  	  std::swap (ns, gfc_current_ns);
  	  gfc_free_namespace (ns);
  	  return m;
  	}
      }
  
    m = gfc_match (" )%t");
--- 6574,6590 ----
    else
      {
        m = gfc_match (" %e ", &expr1);
!       if (m == MATCH_NO)
  	{
  	  std::swap (ns, gfc_current_ns);
  	  gfc_free_namespace (ns);
  	  return m;
  	}
+       /* On MATCH_ERROR, the temporary block namespace may already contain
+ 	 broken state from the failed expression match.  Avoid freeing it
+ 	 through the normal rollback path.  */
+       else if (m == MATCH_ERROR)
+ 	return m;
      }
  
    m = gfc_match (" )%t");
diff -Nrcpad gcc-13.4.0/gcc/fortran/parse.cc gcc-13.5.0-RC-20260904/gcc/fortran/parse.cc
*** gcc-13.4.0/gcc/fortran/parse.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/parse.cc	Fri Sep  4 07:35:08 2026
*************** parse_executable (gfc_statement st)
*** 6033,6038 ****
--- 6033,6060 ----
  }
  
  
+ /* Update statement function formal argument lists that reference OLD_SYM
+    to point to NEW_SYM instead.  This prevents use-after-free when
+    gfc_fixup_sibling_symbols replaces and frees a symbol that is also
+    used as a statement function dummy argument (PR95879).  */
+ 
+ static void
+ fixup_st_func_formals (gfc_symtree *st, gfc_symbol *old_sym,
+ 		       gfc_symbol *new_sym)
+ {
+   if (st == NULL)
+     return;
+ 
+   fixup_st_func_formals (st->left, old_sym, new_sym);
+   fixup_st_func_formals (st->right, old_sym, new_sym);
+ 
+   if (st->n.sym && st->n.sym->attr.proc == PROC_ST_FUNCTION)
+     for (gfc_formal_arglist *fa = st->n.sym->formal; fa; fa = fa->next)
+       if (fa->sym == old_sym)
+ 	fa->sym = new_sym;
+ }
+ 
+ 
  /* Fix the symbols for sibling functions.  These are incorrectly added to
     the child namespace as the parser didn't know about this procedure.  */
  
*************** gfc_fixup_sibling_symbols (gfc_symbol *s
*** 6084,6089 ****
--- 6106,6116 ----
  	  st->n.sym = sym;
  	  sym->refs++;
  
+ 	  /* Update statement function formal argument lists that still
+ 	     reference old_sym before releasing it (PR95879).  */
+ 	  fixup_st_func_formals (ns->sym_root, old_sym, sym);
+ 
+ 
  	  gfc_release_symbol (old_sym);
  	}
  
diff -Nrcpad gcc-13.4.0/gcc/fortran/primary.cc gcc-13.5.0-RC-20260904/gcc/fortran/primary.cc
*** gcc-13.4.0/gcc/fortran/primary.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/primary.cc	Fri Sep  4 07:35:08 2026
*************** gfc_variable_attr (gfc_expr *expr, gfc_t
*** 2750,2761 ****
--- 2750,2763 ----
  
  	if (comp->ts.type == BT_CLASS)
  	  {
+ 	    dimension = CLASS_DATA (comp)->attr.dimension;
  	    codimension = CLASS_DATA (comp)->attr.codimension;
  	    pointer = CLASS_DATA (comp)->attr.class_pointer;
  	    allocatable = CLASS_DATA (comp)->attr.allocatable;
  	  }
  	else
  	  {
+ 	    dimension = comp->attr.dimension;
  	    codimension = comp->attr.codimension;
  	    if (expr->ts.type == BT_CLASS && strcmp (comp->name, "_data") == 0)
  	      pointer = comp->attr.class_pointer;
*************** gfc_convert_to_structure_constructor (gf
*** 3230,3235 ****
--- 3232,3238 ----
  	  && this_comp->ts.u.cl && this_comp->ts.u.cl->length
  	  && this_comp->ts.u.cl->length->expr_type == EXPR_CONSTANT
  	  && this_comp->ts.u.cl->length->ts.type == BT_INTEGER
+ 	  && actual->expr
  	  && actual->expr->ts.type == BT_CHARACTER
  	  && actual->expr->expr_type == EXPR_CONSTANT)
  	{
*************** gfc_convert_to_structure_constructor (gf
*** 3294,3320 ****
  	  goto cleanup;
  	}
  
!           /* If not explicitly a parent constructor, gather up the components
!              and build one.  */
!           if (comp && comp == sym->components
!                 && sym->attr.extension
! 		&& comp_tail->val
!                 && (!gfc_bt_struct (comp_tail->val->ts.type)
!                       ||
!                     comp_tail->val->ts.u.derived != this_comp->ts.u.derived))
!             {
!               bool m;
  	      gfc_actual_arglist *arg_null = NULL;
  
  	      actual->expr = comp_tail->val;
  	      comp_tail->val = NULL;
  
!               m = gfc_convert_to_structure_constructor (NULL,
! 					comp->ts.u.derived, &comp_tail->val,
! 					comp->ts.u.derived->attr.zero_comp
! 					  ? &arg_null : &actual, true);
!               if (!m)
!                 goto cleanup;
  
  	      if (comp->ts.u.derived->attr.zero_comp)
  		{
--- 3297,3323 ----
  	  goto cleanup;
  	}
  
! 	  /* If not explicitly a parent constructor, gather up the components
! 	     and build one.  */
! 	  if (comp && comp == sym->components
! 	      && sym->attr.extension
! 	      && comp_tail->val
! 	      && (!gfc_bt_struct (comp_tail->val->ts.type)
! 		  || comp_tail->val->ts.u.derived != this_comp->ts.u.derived))
! 	    {
! 	      bool m;
  	      gfc_actual_arglist *arg_null = NULL;
  
  	      actual->expr = comp_tail->val;
  	      comp_tail->val = NULL;
+ #define shorter gfc_convert_to_structure_constructor
+ 	      m = shorter (NULL, comp->ts.u.derived, &comp_tail->val,
+ 			   comp->ts.u.derived->attr.zero_comp ? &arg_null :
+ 								&actual, true);
+ #undef shorter
  
! 	      if (!m)
! 		goto cleanup;
  
  	      if (comp->ts.u.derived->attr.zero_comp)
  		{
*************** gfc_match_rvalue (gfc_expr **result)
*** 3624,3630 ****
  	 end up here.  Unfortunately, sym->value->expr_type is set to
  	 EXPR_CONSTANT, and so the if () branch would be followed without
  	 the !sym->as check.  */
!       if (sym->value && sym->value->expr_type != EXPR_ARRAY && !sym->as)
  	e = gfc_copy_expr (sym->value);
        else
  	{
--- 3627,3634 ----
  	 end up here.  Unfortunately, sym->value->expr_type is set to
  	 EXPR_CONSTANT, and so the if () branch would be followed without
  	 the !sym->as check.  */
!       if (sym->value && sym->value->expr_type != EXPR_ARRAY
! 	  && sym->value->expr_type != EXPR_VARIABLE && !sym->as)
  	e = gfc_copy_expr (sym->value);
        else
  	{
diff -Nrcpad gcc-13.4.0/gcc/fortran/resolve.cc gcc-13.5.0-RC-20260904/gcc/fortran/resolve.cc
*** gcc-13.4.0/gcc/fortran/resolve.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/resolve.cc	Fri Sep  4 07:35:08 2026
*************** resolve_global_procedure (gfc_symbol *sy
*** 2694,2710 ****
  	  /* This can happen if a binding name has been specified.  */
  	  if (gsym->binding_label && gsym->sym_name != def_sym->name)
  	    gfc_find_symbol (gsym->sym_name, gsym->ns, 0, &def_sym);
  
! 	  if (def_sym->attr.entry_master || def_sym->attr.entry)
! 	    {
! 	      gfc_entry_list *entry;
! 	      for (entry = gsym->ns->entries; entry; entry = entry->next)
! 		if (strcmp (entry->sym->name, sym->name) == 0)
! 		  {
! 		    def_sym = entry->sym;
! 		    break;
! 		  }
! 	    }
  	}
  
        if (sym->attr.function && !gfc_compare_types (&sym->ts, &def_sym->ts))
--- 2694,2715 ----
  	  /* This can happen if a binding name has been specified.  */
  	  if (gsym->binding_label && gsym->sym_name != def_sym->name)
  	    gfc_find_symbol (gsym->sym_name, gsym->ns, 0, &def_sym);
+ 	}
  
!       /* Look up the specific entry symbol so that interface checks use
! 	 the entry's own formal argument list, not the entry master's.
! 	 This must run even when resolved == -1 (recursive resolution in
! 	 progress), because def_sym starts as the namespace proc_name
! 	 which is the entry master with the combined formals.  */
!       if (def_sym->attr.entry_master || def_sym->attr.entry)
! 	{
! 	  gfc_entry_list *entry;
! 	  for (entry = gsym->ns->entries; entry; entry = entry->next)
! 	    if (strcmp (entry->sym->name, sym->name) == 0)
! 	      {
! 		def_sym = entry->sym;
! 		break;
! 	      }
  	}
  
        if (sym->attr.function && !gfc_compare_types (&sym->ts, &def_sym->ts))
diff -Nrcpad gcc-13.4.0/gcc/fortran/scanner.cc gcc-13.5.0-RC-20260904/gcc/fortran/scanner.cc
*** gcc-13.4.0/gcc/fortran/scanner.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/scanner.cc	Fri Sep  4 07:35:08 2026
*************** skip_free_oacc_sentinel (locus start, lo
*** 776,781 ****
--- 776,783 ----
        if ((c = next_char ()) == ' ' || c == '\t'
  	  || continue_flag)
  	{
+ 	  if (!continue_flag && (c == ' ' || c == '\t'))
+ 	    openmp_flag = 0;
  	  while (gfc_is_whitespace (c))
  	    c = next_char ();
  	  if (c != '\n' && c != '!')
*************** skip_free_omp_sentinel (locus start, loc
*** 816,821 ****
--- 818,825 ----
        if ((c = next_char ()) == ' ' || c == '\t'
  	  || continue_flag)
  	{
+ 	  if (!continue_flag && (c == ' ' || c == '\t'))
+ 	    openacc_flag = 0;
  	  while (gfc_is_whitespace (c))
  	    c = next_char ();
  	  if (c != '\n' && c != '!')
diff -Nrcpad gcc-13.4.0/gcc/fortran/symbol.cc gcc-13.5.0-RC-20260904/gcc/fortran/symbol.cc
*** gcc-13.4.0/gcc/fortran/symbol.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/symbol.cc	Fri Sep  4 07:35:08 2026
*************** gfc_find_component (gfc_symbol *sym, con
*** 2600,2605 ****
--- 2600,2620 ----
  /* Given a symbol, free all of the component structures and everything
     they point to.  */
  
+ void
+ gfc_free_component (gfc_component *p)
+ {
+   gfc_free_array_spec (p->as);
+   gfc_free_expr (p->initializer);
+   if (p->kind_expr)
+     gfc_free_expr (p->kind_expr);
+   if (p->param_list)
+     gfc_free_actual_arglist (p->param_list);
+   free (p->tb);
+   p->tb = NULL;
+   free (p);
+ }
+ 
+ 
  static void
  free_components (gfc_component *p)
  {
*************** free_components (gfc_component *p)
*** 2608,2623 ****
    for (; p; p = q)
      {
        q = p->next;
! 
!       gfc_free_array_spec (p->as);
!       gfc_free_expr (p->initializer);
!       if (p->kind_expr)
! 	gfc_free_expr (p->kind_expr);
!       if (p->param_list)
! 	gfc_free_actual_arglist (p->param_list);
!       free (p->tb);
!       p->tb = NULL;
!       free (p);
      }
  }
  
--- 2623,2629 ----
    for (; p; p = q)
      {
        q = p->next;
!       gfc_free_component (p);
      }
  }
  
diff -Nrcpad gcc-13.4.0/gcc/fortran/trans-array.cc gcc-13.5.0-RC-20260904/gcc/fortran/trans-array.cc
*** gcc-13.4.0/gcc/fortran/trans-array.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/trans-array.cc	Fri Sep  4 07:35:08 2026
*************** gfc_conv_array_initializer (tree type, g
*** 6378,6386 ****
  
    if (expr->expr_type == EXPR_VARIABLE
        && expr->symtree->n.sym->attr.flavor == FL_PARAMETER
!       && expr->symtree->n.sym->value)
      expr = expr->symtree->n.sym->value;
  
    switch (expr->expr_type)
      {
      case EXPR_CONSTANT:
--- 6378,6400 ----
  
    if (expr->expr_type == EXPR_VARIABLE
        && expr->symtree->n.sym->attr.flavor == FL_PARAMETER
!       && expr->symtree->n.sym->value
!       && !expr->ref)
      expr = expr->symtree->n.sym->value;
  
+   /* After parameter substitution the expression should be a constant, array
+      constructor, structure constructor, or NULL.  Anything else is invalid
+      and must not ICE later in lowering.  */
+   if (expr->expr_type != EXPR_CONSTANT
+       && expr->expr_type != EXPR_STRUCTURE
+       && expr->expr_type != EXPR_ARRAY
+       && expr->expr_type != EXPR_NULL)
+     {
+       gfc_error ("Array initializer at %L does not reduce to a constant "
+ 		 "expression", &expr->where);
+       return build_constructor (type, NULL);
+     }
+ 
    switch (expr->expr_type)
      {
      case EXPR_CONSTANT:
*************** gfc_conv_array_parameter (gfc_se * se, g
*** 8665,8713 ****
  	{
  	  tmp = build_fold_indirect_ref_loc (input_location, desc);
  
! 	  gfc_ss * ss = gfc_walk_expr (expr);
! 	  if (!transposed_dims (ss))
! 	    gfc_conv_descriptor_data_set (&se->pre, tmp, ptr);
! 	  else
  	    {
! 	      tree old_field, new_field;
  
! 	      /* The original descriptor has transposed dims so we can't reuse
! 		 it directly; we have to create a new one.  */
! 	      tree old_desc = tmp;
! 	      tree new_desc = gfc_create_var (TREE_TYPE (old_desc), "arg_desc");
  
! 	      old_field = gfc_conv_descriptor_dtype (old_desc);
! 	      new_field = gfc_conv_descriptor_dtype (new_desc);
! 	      gfc_add_modify (&se->pre, new_field, old_field);
  
! 	      old_field = gfc_conv_descriptor_offset (old_desc);
! 	      new_field = gfc_conv_descriptor_offset (new_desc);
! 	      gfc_add_modify (&se->pre, new_field, old_field);
  
! 	      for (int i = 0; i < expr->rank; i++)
! 		{
! 		  old_field = gfc_conv_descriptor_dimension (old_desc,
! 			gfc_rank_cst[get_array_ref_dim_for_loop_dim (ss, i)]);
! 		  new_field = gfc_conv_descriptor_dimension (new_desc,
! 			gfc_rank_cst[i]);
! 		  gfc_add_modify (&se->pre, new_field, old_field);
! 		}
  
! 	      if (flag_coarray == GFC_FCOARRAY_LIB
! 		  && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (old_desc))
! 		  && GFC_TYPE_ARRAY_AKIND (TREE_TYPE (old_desc))
! 		     == GFC_ARRAY_ALLOCATABLE)
! 		{
! 		  old_field = gfc_conv_descriptor_token (old_desc);
! 		  new_field = gfc_conv_descriptor_token (new_desc);
! 		  gfc_add_modify (&se->pre, new_field, old_field);
! 		}
  
! 	      gfc_conv_descriptor_data_set (&se->pre, new_desc, ptr);
! 	      se->expr = gfc_build_addr_expr (NULL_TREE, new_desc);
  	    }
! 	  gfc_free_ss (ss);
  	}
  
        if (gfc_option.rtcheck & GFC_RTCHECK_ARRAY_TEMPS)
--- 8679,8753 ----
  	{
  	  tmp = build_fold_indirect_ref_loc (input_location, desc);
  
! 	  /* The original descriptor may have transposed dims so we
! 	     can't reuse it directly; we have to create a new one.  */
! 	  tree old_field, new_field;
! 
! 	  tree old_desc = tmp;
! 	  tree new_desc = gfc_create_var (TREE_TYPE (old_desc), "arg_desc");
! 
! 	  tree offset = gfc_index_zero_node;
! 
! 	  tree stride = gfc_index_one_node;
! 
! 	  for (int i = 0; i < expr->rank; i++)
  	    {
! 	      tree dim = gfc_rank_cst[i];
  
! 	      tree lbound = gfc_conv_descriptor_lbound_get (old_desc,
! 							    dim);
! 	      lbound = gfc_evaluate_now (lbound, &se->pre);
! 	      gfc_conv_descriptor_lbound_set (&se->pre, new_desc, dim,
! 					      lbound);
  
! 	      tree ubound = gfc_conv_descriptor_ubound_get (old_desc,
! 							    dim);
! 	      ubound = gfc_evaluate_now (ubound, &se->pre);
! 	      gfc_conv_descriptor_ubound_set (&se->pre, new_desc, dim,
! 					      ubound);
  
! 	      gfc_conv_descriptor_stride_set (&se->pre, new_desc, dim,
! 					      stride);
  
! 	      tree tmp = fold_build2_loc (input_location, MULT_EXPR,
! 					  gfc_array_index_type,
! 					  stride, lbound);
! 	      offset = fold_build2_loc (input_location, MINUS_EXPR,
! 					gfc_array_index_type,
! 					offset, tmp);
! 	      offset = gfc_evaluate_now (offset, &se->pre);
  
! 	      /* Now calculate the stride for next dimension, unless the
! 		 current dimension is the last one.  */
! 	      if (i == expr->rank - 1)
! 		break;
  
! 	      tmp = fold_build2_loc (input_location, MINUS_EXPR,
! 				     gfc_array_index_type,
! 				     lbound, gfc_index_one_node);
! 	      tree extent = fold_build2_loc (input_location, MINUS_EXPR,
! 					     gfc_array_index_type,
! 					     ubound, tmp);
! 	      stride = fold_build2_loc (input_location, MULT_EXPR,
! 					gfc_array_index_type,
! 					stride, extent);
! 	      stride = gfc_evaluate_now (stride, &se->pre);
  	    }
! 
! 	  gfc_conv_descriptor_offset_set (&se->pre, new_desc, offset);
! 
! 	  if (flag_coarray == GFC_FCOARRAY_LIB
! 	      && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (old_desc))
! 	      && GFC_TYPE_ARRAY_AKIND (TREE_TYPE (old_desc))
! 		 == GFC_ARRAY_ALLOCATABLE)
! 	    {
! 	      old_field = gfc_conv_descriptor_token (old_desc);
! 	      new_field = gfc_conv_descriptor_token (new_desc);
! 	      gfc_add_modify (&se->pre, new_field, old_field);
! 	    }
! 
! 	  gfc_conv_descriptor_data_set (&se->pre, new_desc, ptr);
! 	  se->expr = gfc_build_addr_expr (NULL_TREE, new_desc);
  	}
  
        if (gfc_option.rtcheck & GFC_RTCHECK_ARRAY_TEMPS)
diff -Nrcpad gcc-13.4.0/gcc/fortran/trans-decl.cc gcc-13.5.0-RC-20260904/gcc/fortran/trans-decl.cc
*** gcc-13.4.0/gcc/fortran/trans-decl.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/trans-decl.cc	Fri Sep  4 07:35:08 2026
*************** gfc_finish_var_decl (tree decl, gfc_symb
*** 643,655 ****
  	  && (sym->ns->proc_name->backend_decl == current_function_decl
  	      || sym->result == sym))
  	gfc_add_decl_to_function (decl);
        else if (sym->ns->proc_name
  	       && sym->ns->proc_name->attr.flavor == FL_LABEL)
  	/* This is a BLOCK construct.  */
  	add_decl_as_local (decl);
-       else if (sym->ns->omp_affinity_iterators)
- 	/* This is a block-local iterator.  */
- 	add_decl_as_local (decl);
        else
  	gfc_add_decl_to_parent_function (decl);
      }
--- 643,668 ----
  	  && (sym->ns->proc_name->backend_decl == current_function_decl
  	      || sym->result == sym))
  	gfc_add_decl_to_function (decl);
+       else if (sym->ns->omp_affinity_iterators)
+ 	{
+ 	  /* Iterator variables are block-local; other variables in the
+ 	     iterator namespace (e.g. implicitly typed host-associated
+ 	     ones used in locator expressions) belong in the enclosing
+ 	     function.  */
+ 	  gfc_symbol *iter;
+ 	  for (iter = sym->ns->omp_affinity_iterators; iter;
+ 	       iter = iter->tlink)
+ 	    if (iter == sym)
+ 	      break;
+ 	  if (iter)
+ 	    add_decl_as_local (decl);
+ 	  else
+ 	    gfc_add_decl_to_function (decl);
+ 	}
        else if (sym->ns->proc_name
  	       && sym->ns->proc_name->attr.flavor == FL_LABEL)
  	/* This is a BLOCK construct.  */
  	add_decl_as_local (decl);
        else
  	gfc_add_decl_to_parent_function (decl);
      }
*************** build_entry_thunks (gfc_namespace * ns,
*** 2975,2989 ****
        tmp = build_int_cst (gfc_array_index_type, el->id);
        vec_safe_push (args, tmp);
  
!       if (thunk_sym->attr.function)
  	{
! 	  if (gfc_return_by_reference (ns->proc_name))
  	    {
  	      tree ref = DECL_ARGUMENTS (current_function_decl);
  	      vec_safe_push (args, ref);
  	      if (ns->proc_name->ts.type == BT_CHARACTER)
  		vec_safe_push (args, DECL_CHAIN (ref));
  	    }
  	}
  
        for (formal = gfc_sym_get_dummy_args (ns->proc_name); formal;
--- 2988,3047 ----
        tmp = build_int_cst (gfc_array_index_type, el->id);
        vec_safe_push (args, tmp);
  
!       /* When the master returns by reference, pass the result reference
! 	 and (for CHARACTER) the string length to the master call.  If the
! 	 thunk itself also returns by reference these are forwarded from
! 	 its own argument list; otherwise (bind(c) CHARACTER entry) we
! 	 create local temporaries and load the value after the call.  */
!       tree result_ref = NULL_TREE;
!       if (thunk_sym->attr.function
! 	  && gfc_return_by_reference (ns->proc_name))
  	{
! 	  if (gfc_return_by_reference (thunk_sym))
  	    {
  	      tree ref = DECL_ARGUMENTS (current_function_decl);
  	      vec_safe_push (args, ref);
  	      if (ns->proc_name->ts.type == BT_CHARACTER)
  		vec_safe_push (args, DECL_CHAIN (ref));
  	    }
+ 	  else
+ 	    {
+ 	      /* The thunk is bind(c) and returns CHARACTER by value, but
+ 		 the master returns by reference.  Create a local buffer
+ 		 and length to pass to the master call.  */
+ 	      tree chartype = gfc_get_char_type (thunk_sym->ts.kind);
+ 	      tree len;
+ 
+ 	      if (thunk_sym->ts.u.cl && thunk_sym->ts.u.cl->length)
+ 		{
+ 		  gfc_se se;
+ 		  gfc_init_se (&se, NULL);
+ 		  gfc_conv_expr (&se, thunk_sym->ts.u.cl->length);
+ 		  gfc_add_block_to_block (&body, &se.pre);
+ 		  len = se.expr;
+ 		  gfc_add_block_to_block (&body, &se.post);
+ 		}
+ 	      else
+ 		len = build_int_cst (gfc_charlen_type_node, 1);
+ 
+ 	      result_ref = build_decl (input_location, VAR_DECL,
+ 				       get_identifier ("__entry_result"),
+ 				       build_array_type (chartype,
+ 					 build_range_type (gfc_array_index_type,
+ 					   gfc_index_one_node,
+ 					   fold_convert (gfc_array_index_type,
+ 							 len))));
+ 	      DECL_ARTIFICIAL (result_ref) = 1;
+ 	      TREE_USED (result_ref) = 1;
+ 	      DECL_CONTEXT (result_ref) = current_function_decl;
+ 	      layout_decl (result_ref, 0);
+ 	      pushdecl (result_ref);
+ 
+ 	      vec_safe_push (args,
+ 			     build_fold_addr_expr_loc (input_location,
+ 						       result_ref));
+ 	      vec_safe_push (args, len);
+ 	    }
  	}
  
        for (formal = gfc_sym_get_dummy_args (ns->proc_name); formal;
*************** build_entry_thunks (gfc_namespace * ns,
*** 3030,3036 ****
        vec_safe_splice (args, string_args);
        tmp = ns->proc_name->backend_decl;
        tmp = build_call_expr_loc_vec (input_location, tmp, args);
!       if (ns->proc_name->attr.mixed_entry_master)
  	{
  	  tree union_decl, field;
  	  tree master_type = TREE_TYPE (ns->proc_name->backend_decl);
--- 3088,3111 ----
        vec_safe_splice (args, string_args);
        tmp = ns->proc_name->backend_decl;
        tmp = build_call_expr_loc_vec (input_location, tmp, args);
!       if (result_ref != NULL_TREE)
! 	{
! 	  /* The master returns by reference (void) but the bind(c) thunk
! 	     returns CHARACTER by value.  Execute the master call, then
! 	     load the first character from the local buffer.  */
! 	  gfc_add_expr_to_block (&body, tmp);
! 	  tmp = build4_loc (input_location, ARRAY_REF,
! 			    TREE_TYPE (TREE_TYPE (result_ref)),
! 			    result_ref, gfc_index_one_node,
! 			    NULL_TREE, NULL_TREE);
! 	  tmp = fold_convert (TREE_TYPE (DECL_RESULT (current_function_decl)),
! 			      tmp);
! 	  tmp = fold_build2_loc (input_location, MODIFY_EXPR,
! 			     TREE_TYPE (DECL_RESULT (current_function_decl)),
! 			     DECL_RESULT (current_function_decl), tmp);
! 	  tmp = build1_v (RETURN_EXPR, tmp);
! 	}
!       else if (ns->proc_name->attr.mixed_entry_master)
  	{
  	  tree union_decl, field;
  	  tree master_type = TREE_TYPE (ns->proc_name->backend_decl);
*************** gfc_trans_deferred_vars (gfc_symbol * pr
*** 4811,4816 ****
--- 4886,4896 ----
  					NULL_TREE);
  		  continue;
  		}
+ 	      else if (sym->attr.codimension && !sym->attr.dimension)
+ 		{
+ 		  /* Scalar coarrays do not need array allocation.  */
+ 		  continue;
+ 		}
  	      else
  		{
  		  gfc_save_backend_locus (&loc);
diff -Nrcpad gcc-13.4.0/gcc/fortran/trans-expr.cc gcc-13.5.0-RC-20260904/gcc/fortran/trans-expr.cc
*** gcc-13.4.0/gcc/fortran/trans-expr.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/trans-expr.cc	Fri Sep  4 07:35:08 2026
*************** gfc_get_interface_mapping_charlen (gfc_i
*** 4378,4390 ****
  
  /* A subroutine of gfc_add_interface_mapping.  Return a descriptorless
     array variable that can be used as the actual argument for dummy
!    argument SYM.  Add any initialization code to BLOCK.  PACKED is as
!    for gfc_get_nodesc_array_type and DATA points to the first element
!    in the passed array.  */
  
  static tree
  gfc_get_interface_mapping_array (stmtblock_t * block, gfc_symbol * sym,
! 				 gfc_packed packed, tree data, tree len)
  {
    tree type;
    tree var;
--- 4378,4392 ----
  
  /* A subroutine of gfc_add_interface_mapping.  Return a descriptorless
     array variable that can be used as the actual argument for dummy
!    argument SYM, except in the case of assumed rank dummies of
!    non-intrinsic functions where the descriptor must be passed. Add any
!    initialization code to BLOCK. PACKED is as for gfc_get_nodesc_array_type
!    and DATA points to the first element in the passed array.  */
  
  static tree
  gfc_get_interface_mapping_array (stmtblock_t * block, gfc_symbol * sym,
! 				 gfc_packed packed, tree data, tree len,
! 				 bool assumed_rank_formal)
  {
    tree type;
    tree var;
*************** gfc_get_interface_mapping_array (stmtblo
*** 4393,4399 ****
      type = gfc_get_character_type_len (sym->ts.kind, len);
    else
      type = gfc_typenode_for_spec (&sym->ts);
!   type = gfc_get_nodesc_array_type (type, sym->as, packed,
  				    !sym->attr.target && !sym->attr.pointer
  				    && !sym->attr.proc_pointer);
  
--- 4395,4405 ----
      type = gfc_get_character_type_len (sym->ts.kind, len);
    else
      type = gfc_typenode_for_spec (&sym->ts);
! 
!   if (assumed_rank_formal)
!     type = TREE_TYPE (data);
!   else
!     type = gfc_get_nodesc_array_type (type, sym->as, packed,
  				    !sym->attr.target && !sym->attr.pointer
  				    && !sym->attr.proc_pointer);
  
*************** gfc_add_interface_mapping (gfc_interface
*** 4566,4580 ****
    else if (POINTER_TYPE_P (TREE_TYPE (se->expr))
  	   && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (TREE_TYPE (se->expr))))
      {
        /* Get the actual argument's descriptor.  */
        desc = build_fold_indirect_ref_loc (input_location,
  				      se->expr);
  
        /* Create the replacement variable.  */
!       tmp = gfc_conv_descriptor_data_get (desc);
        value = gfc_get_interface_mapping_array (&se->pre, sym,
  					       PACKED_NO, tmp,
! 					       se->string_length);
  
        /* Use DESC to work out the upper bounds, strides and offset.  */
        gfc_set_interface_mapping_bounds (&se->pre, TREE_TYPE (value), desc);
--- 4572,4598 ----
    else if (POINTER_TYPE_P (TREE_TYPE (se->expr))
  	   && GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (TREE_TYPE (se->expr))))
      {
+       bool assumed_rank_formal = false;
+ 
        /* Get the actual argument's descriptor.  */
        desc = build_fold_indirect_ref_loc (input_location,
  				      se->expr);
  
        /* Create the replacement variable.  */
!       if (sym->as && sym->as->type == AS_ASSUMED_RANK
! 	  && !(sym->ns && sym->ns->proc_name
! 	       && sym->ns->proc_name->attr.proc == PROC_INTRINSIC))
! 	{
! 	  assumed_rank_formal = true;
! 	  tmp = desc;
! 	}
!       else
! 	tmp = gfc_conv_descriptor_data_get (desc);
! 
        value = gfc_get_interface_mapping_array (&se->pre, sym,
  					       PACKED_NO, tmp,
! 					       se->string_length,
! 					       assumed_rank_formal);
  
        /* Use DESC to work out the upper bounds, strides and offset.  */
        gfc_set_interface_mapping_bounds (&se->pre, TREE_TYPE (value), desc);
*************** gfc_add_interface_mapping (gfc_interface
*** 4583,4589 ****
      /* Otherwise we have a packed array.  */
      value = gfc_get_interface_mapping_array (&se->pre, sym,
  					     PACKED_FULL, se->expr,
! 					     se->string_length);
  
    new_sym->backend_decl = value;
  }
--- 4601,4608 ----
      /* Otherwise we have a packed array.  */
      value = gfc_get_interface_mapping_array (&se->pre, sym,
  					     PACKED_FULL, se->expr,
! 					     se->string_length,
! 					     false);
  
    new_sym->backend_decl = value;
  }
*************** gfc_conv_subref_array_arg (gfc_se *se, g
*** 5178,5184 ****
  
    gcc_assert (lse.ss == gfc_ss_terminator);
  
!   tmp = gfc_trans_scalar_assign (&lse, &rse, expr->ts, false, true);
    gfc_add_expr_to_block (&body, tmp);
  
    /* Generate the copying loops.  */
--- 5197,5205 ----
  
    gcc_assert (lse.ss == gfc_ss_terminator);
  
!   /* Do not do deallocations when we are looking at a g77-style argument.  */
! 
!   tmp = gfc_trans_scalar_assign (&lse, &rse, expr->ts, false, !g77);
    gfc_add_expr_to_block (&body, tmp);
  
    /* Generate the copying loops.  */
diff -Nrcpad gcc-13.4.0/gcc/fortran/trans-intrinsic.cc gcc-13.5.0-RC-20260904/gcc/fortran/trans-intrinsic.cc
*** gcc-13.4.0/gcc/fortran/trans-intrinsic.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/trans-intrinsic.cc	Fri Sep  4 07:35:08 2026
*************** gfc_conv_intrinsic_transfer (gfc_se * se
*** 8513,8519 ****
  				       argse.string_length);
        else if (arg->expr->ts.type == BT_CLASS)
  	{
! 	  class_ref = TREE_OPERAND (argse.expr, 0);
  	  tmp = gfc_class_vtab_size_get (class_ref);
  	  if (UNLIMITED_POLY (arg->expr))
  	    tmp = gfc_resize_class_size_with_len (&argse.pre, class_ref, tmp);
--- 8513,8524 ----
  				       argse.string_length);
        else if (arg->expr->ts.type == BT_CLASS)
  	{
! 	  if (UNLIMITED_POLY (source_expr)
! 	      && DECL_LANG_SPECIFIC (source_expr->symtree->n.sym->backend_decl))
! 	    class_ref = GFC_DECL_SAVED_DESCRIPTOR
! 	      (source_expr->symtree->n.sym->backend_decl);
! 	  else
! 	    class_ref = TREE_OPERAND (argse.expr, 0);
  	  tmp = gfc_class_vtab_size_get (class_ref);
  	  if (UNLIMITED_POLY (arg->expr))
  	    tmp = gfc_resize_class_size_with_len (&argse.pre, class_ref, tmp);
diff -Nrcpad gcc-13.4.0/gcc/fortran/trans-io.cc gcc-13.5.0-RC-20260904/gcc/fortran/trans-io.cc
*** gcc-13.4.0/gcc/fortran/trans-io.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/trans-io.cc	Fri Sep  4 07:35:08 2026
*************** transfer_expr (gfc_se * se, gfc_typespec
*** 2493,2499 ****
  
  		  if (c->attr.dimension)
  		    {
! 		      tmp = transfer_array_component (tmp, c, & code->loc);
  		      gfc_add_expr_to_block (&se->pre, tmp);
  		    }
  		  else
--- 2493,2501 ----
  
  		  if (c->attr.dimension)
  		    {
! 		      tmp = transfer_array_component (tmp, c,
! 						      code ? &code->loc
! 						      : NULL);
  		      gfc_add_expr_to_block (&se->pre, tmp);
  		    }
  		  else
diff -Nrcpad gcc-13.4.0/gcc/fortran/trans-openmp.cc gcc-13.5.0-RC-20260904/gcc/fortran/trans-openmp.cc
*** gcc-13.4.0/gcc/fortran/trans-openmp.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/trans-openmp.cc	Fri Sep  4 07:35:08 2026
*************** gfc_has_alloc_comps (tree type, tree dec
*** 405,410 ****
--- 405,434 ----
    return false;
  }
  
+ /* Return true if TYPE is a class container for a POINTER entity.  */
+ 
+ static bool
+ gfc_is_class_pointer_type (tree type)
+ {
+   tree name;
+   const char *s;
+ 
+   if (POINTER_TYPE_P (type))
+     type = TREE_TYPE (type);
+ 
+   if (!GFC_CLASS_TYPE_P (type))
+     return false;
+ 
+   name = TYPE_NAME (type);
+   if (name && TREE_CODE (name) == TYPE_DECL)
+     name = DECL_NAME (name);
+   if (!name)
+     return false;
+ 
+   s = IDENTIFIER_POINTER (name);
+   return startswith (s, "__class_") && s[strlen (s) - 1] == 'p';
+ }
+ 
  /* Return true if TYPE is polymorphic but not with pointer attribute.  */
  
  static bool
*************** gfc_omp_clause_default_ctor (tree clause
*** 754,760 ****
        return NULL_TREE;
      }
  
!   gcc_assert (outer != NULL_TREE);
  
    /* Allocatable arrays and scalars in PRIVATE clauses need to be set to
       "not currently allocated" allocation status if outer
--- 778,786 ----
        return NULL_TREE;
      }
  
!   gcc_assert (outer != NULL_TREE
! 	      || (!GFC_DESCRIPTOR_TYPE_P (type)
! 		  && !gfc_has_alloc_comps (type, OMP_CLAUSE_DECL (clause))));
  
    /* Allocatable arrays and scalars in PRIVATE clauses need to be set to
       "not currently allocated" allocation status if outer
*************** gfc_omp_clause_copy_ctor (tree clause, t
*** 844,865 ****
  {
    tree type = TREE_TYPE (dest), ptr, size, call;
    tree decl_type = TREE_TYPE (OMP_CLAUSE_DECL (clause));
    tree cond, then_b, else_b;
    stmtblock_t block, cond_block;
  
    gcc_assert (OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_FIRSTPRIVATE
  	      || OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_LINEAR);
  
!   /* Privatize pointer, only; cf. gfc_omp_predetermined_sharing. */
!   if (DECL_P (OMP_CLAUSE_DECL (clause))
!       && GFC_DECL_ASSOCIATE_VAR_P (OMP_CLAUSE_DECL (clause)))
!     return build2 (MODIFY_EXPR, TREE_TYPE (dest), dest, src);
  
!   if (DECL_ARTIFICIAL (OMP_CLAUSE_DECL (clause))
!       && DECL_LANG_SPECIFIC (OMP_CLAUSE_DECL (clause))
!       && GFC_DECL_SAVED_DESCRIPTOR (OMP_CLAUSE_DECL (clause)))
!     decl_type
!       = TREE_TYPE (GFC_DECL_SAVED_DESCRIPTOR (OMP_CLAUSE_DECL (clause)));
  
    if (gfc_is_polymorphic_nonptr (decl_type))
      {
--- 870,898 ----
  {
    tree type = TREE_TYPE (dest), ptr, size, call;
    tree decl_type = TREE_TYPE (OMP_CLAUSE_DECL (clause));
+   tree orig_decl = OMP_CLAUSE_DECL (clause);
    tree cond, then_b, else_b;
    stmtblock_t block, cond_block;
  
    gcc_assert (OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_FIRSTPRIVATE
  	      || OMP_CLAUSE_CODE (clause) == OMP_CLAUSE_LINEAR);
  
!   if (DECL_ARTIFICIAL (orig_decl)
!       && DECL_LANG_SPECIFIC (orig_decl)
!       && GFC_DECL_SAVED_DESCRIPTOR (orig_decl))
!     {
!       orig_decl = GFC_DECL_SAVED_DESCRIPTOR (orig_decl);
!       decl_type = TREE_TYPE (orig_decl);
!     }
  
!   /* Privatize pointer association only; cf. gfc_omp_predetermined_sharing.
!      This includes scalar class pointers, whose tree type is still the class
!      record even though the Fortran entity has POINTER semantics.  */
!   if (DECL_P (orig_decl)
!       && (GFC_DECL_ASSOCIATE_VAR_P (orig_decl)
! 	  || GFC_DECL_GET_SCALAR_POINTER (orig_decl)
! 	  || gfc_is_class_pointer_type (decl_type)))
!     return build2 (MODIFY_EXPR, TREE_TYPE (dest), dest, src);
  
    if (gfc_is_polymorphic_nonptr (decl_type))
      {
*************** gfc_omp_clause_dtor (tree clause, tree d
*** 1367,1383 ****
  {
    tree type = TREE_TYPE (decl), tem;
    tree decl_type = TREE_TYPE (OMP_CLAUSE_DECL (clause));
  
!   /* Only pointer was privatized; cf. gfc_omp_clause_copy_ctor. */
!   if (DECL_P (OMP_CLAUSE_DECL (clause))
!       && GFC_DECL_ASSOCIATE_VAR_P (OMP_CLAUSE_DECL (clause)))
      return NULL_TREE;
  
-   if (DECL_ARTIFICIAL (OMP_CLAUSE_DECL (clause))
-       && DECL_LANG_SPECIFIC (OMP_CLAUSE_DECL (clause))
-       && GFC_DECL_SAVED_DESCRIPTOR (OMP_CLAUSE_DECL (clause)))
-     decl_type
- 	= TREE_TYPE (GFC_DECL_SAVED_DESCRIPTOR (OMP_CLAUSE_DECL (clause)));
    if (gfc_is_polymorphic_nonptr (decl_type))
      {
        if (POINTER_TYPE_P (decl_type))
--- 1400,1423 ----
  {
    tree type = TREE_TYPE (decl), tem;
    tree decl_type = TREE_TYPE (OMP_CLAUSE_DECL (clause));
+   tree orig_decl = OMP_CLAUSE_DECL (clause);
  
!   if (DECL_ARTIFICIAL (orig_decl)
!       && DECL_LANG_SPECIFIC (orig_decl)
!       && GFC_DECL_SAVED_DESCRIPTOR (orig_decl))
!     {
!       orig_decl = GFC_DECL_SAVED_DESCRIPTOR (orig_decl);
!       decl_type = TREE_TYPE (orig_decl);
!     }
! 
!   /* Only pointer association was privatized; cf. gfc_omp_clause_copy_ctr.
!      Scalar class pointers must not finalize or free their targets here.  */
!   if (DECL_P (orig_decl)
!       && (GFC_DECL_ASSOCIATE_VAR_P (orig_decl)
! 	  || GFC_DECL_GET_SCALAR_POINTER (orig_decl)
! 	  || gfc_is_class_pointer_type (decl_type)))
      return NULL_TREE;
  
    if (gfc_is_polymorphic_nonptr (decl_type))
      {
        if (POINTER_TYPE_P (decl_type))
*************** gfc_trans_omp_clauses (stmtblock_t *bloc
*** 2961,2967 ****
  		{
  		  tree ptr;
  		  gfc_init_se (&se, NULL);
! 		  if (n->expr->ref->u.ar.type == AR_ELEMENT)
  		    {
  		      gfc_conv_expr_reference (&se, n->expr);
  		      ptr = se.expr;
--- 3001,3011 ----
  		{
  		  tree ptr;
  		  gfc_init_se (&se, NULL);
! 		  /* The first ref can be an element selection on the base
! 		     object while the full expression still denotes an array,
! 		     e.g. x(j)%a.  Pick the lowering path from the overall
! 		     expression rank, not from the first REF_ARRAY.  */
! 		  if (n->expr->rank == 0)
  		    {
  		      gfc_conv_expr_reference (&se, n->expr);
  		      ptr = se.expr;
*************** gfc_trans_omp_depobj (gfc_code *code)
*** 5809,5815 ****
        else if (n->expr && n->expr->ref->u.ar.type != AR_FULL)
  	{
  	  gfc_init_se (&se, NULL);
! 	  if (n->expr->ref->u.ar.type == AR_ELEMENT)
  	    {
  	      gfc_conv_expr_reference (&se, n->expr);
  	      var = se.expr;
--- 5853,5859 ----
        else if (n->expr && n->expr->ref->u.ar.type != AR_FULL)
  	{
  	  gfc_init_se (&se, NULL);
! 	  if (n->expr->rank == 0)
  	    {
  	      gfc_conv_expr_reference (&se, n->expr);
  	      var = se.expr;
diff -Nrcpad gcc-13.4.0/gcc/fortran/trans-types.cc gcc-13.5.0-RC-20260904/gcc/fortran/trans-types.cc
*** gcc-13.4.0/gcc/fortran/trans-types.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fortran/trans-types.cc	Fri Sep  4 07:35:08 2026
*************** along with GCC; see the file COPYING3.
*** 39,45 ****
  #include "dwarf2out.h"	/* For struct array_descr_info.  */
  #include "attribs.h"
  #include "alias.h"
! 
  
  #if (GFC_MAX_DIMENSIONS < 10)
  #define GFC_RANK_DIGITS 1
--- 39,45 ----
  #include "dwarf2out.h"	/* For struct array_descr_info.  */
  #include "attribs.h"
  #include "alias.h"
! 
  
  #if (GFC_MAX_DIMENSIONS < 10)
  #define GFC_RANK_DIGITS 1
*************** gfc_get_pchar_type (int kind)
*** 1111,1117 ****
    return index < 0 ? 0 : gfc_pcharacter_types[index];
  }
  
! 
  /* Create a character type with the given kind and length.  */
  
  tree
--- 1111,1117 ----
    return index < 0 ? 0 : gfc_pcharacter_types[index];
  }
  
! 
  /* Create a character type with the given kind and length.  */
  
  tree
*************** gfc_get_character_type (int kind, gfc_ch
*** 1147,1153 ****
  
    return gfc_get_character_type_len (kind, len);
  }
! 
  /* Convert a basic type.  This will be an array for character types.  */
  
  tree
--- 1147,1153 ----
  
    return gfc_get_character_type_len (kind, len);
  }
! 
  /* Convert a basic type.  This will be an array for character types.  */
  
  tree
*************** gfc_typenode_for_spec (gfc_typespec * sp
*** 1243,1249 ****
      }
    return basetype;
  }
! 
  /* Build an INT_CST for constant expressions, otherwise return NULL_TREE.  */
  
  static tree
--- 1243,1249 ----
      }
    return basetype;
  }
! 
  /* Build an INT_CST for constant expressions, otherwise return NULL_TREE.  */
  
  static tree
*************** gfc_conv_array_bound (gfc_expr * expr)
*** 1256,1262 ****
    /* Otherwise return NULL.  */
    return NULL_TREE;
  }
! 
  /* Return the type of an element of the array.  Note that scalar coarrays
     are special.  In particular, for GFC_ARRAY_TYPE_P, the original argument
     (with POINTER_TYPE stripped) is returned.  */
--- 1256,1262 ----
    /* Otherwise return NULL.  */
    return NULL_TREE;
  }
! 
  /* Return the type of an element of the array.  Note that scalar coarrays
     are special.  In particular, for GFC_ARRAY_TYPE_P, the original argument
     (with POINTER_TYPE stripped) is returned.  */
*************** gfc_get_element_type (tree type)
*** 1296,1302 ****
  
    return element;
  }
! 
  /* Build an array.  This function is called from gfc_sym_type().
     Actually returns array descriptor type.
  
--- 1296,1302 ----
  
    return element;
  }
! 
  /* Build an array.  This function is called from gfc_sym_type().
     Actually returns array descriptor type.
  
*************** gfc_build_array_type (tree type, gfc_arr
*** 1468,1474 ****
  				    corank, lbound, ubound, 0, akind,
  				    restricted);
  }
! 
  /* Returns the struct descriptor_dimension type.  */
  
  static tree
--- 1468,1474 ----
  				    corank, lbound, ubound, 0, akind,
  				    restricted);
  }
! 
  /* Returns the struct descriptor_dimension type.  */
  
  static tree
*************** gfc_get_array_type_bounds (tree etype, i
*** 2092,2098 ****
  
    return fat_type;
  }
! 
  /* Build a pointer type. This function is called from gfc_sym_type().  */
  
  static tree
--- 2092,2098 ----
  
    return fat_type;
  }
! 
  /* Build a pointer type. This function is called from gfc_sym_type().  */
  
  static tree
*************** gfc_nonrestricted_type (tree t)
*** 2267,2273 ****
    return ret;
  }
  
! 
  /* Return the type for a symbol.  Special handling is required for character
     types to get the correct level of indirection.
     For functions return the return type.
--- 2267,2273 ----
    return ret;
  }
  
! 
  /* Return the type for a symbol.  Special handling is required for character
     types to get the correct level of indirection.
     For functions return the return type.
*************** gfc_sym_type (gfc_symbol * sym, bool is_
*** 2391,2397 ****
  
    return (type);
  }
! 
  /* Layout and output debug info for a record type.  */
  
  void
--- 2391,2397 ----
  
    return (type);
  }
! 
  /* Layout and output debug info for a record type.  */
  
  void
*************** gfc_finish_type (tree type)
*** 2406,2412 ****
    rest_of_type_compilation (type, 1);
    rest_of_decl_compilation (decl, 1, 0);
  }
! 
  /* Add a field of given NAME and TYPE to the context of a UNION_TYPE
     or RECORD_TYPE pointed to by CONTEXT.  The new field is chained
     to the end of the field list pointed to by *CHAIN.
--- 2406,2412 ----
    rest_of_type_compilation (type, 1);
    rest_of_decl_compilation (decl, 1, 0);
  }
! 
  /* Add a field of given NAME and TYPE to the context of a UNION_TYPE
     or RECORD_TYPE pointed to by CONTEXT.  The new field is chained
     to the end of the field list pointed to by *CHAIN.
*************** gfc_return_by_reference (gfc_symbol * sy
*** 2970,2976 ****
  
    return 0;
  }
! 
  static tree
  gfc_get_mixed_entry_union (gfc_namespace *ns)
  {
--- 2970,2997 ----
  
    return 0;
  }
! 
! static tree
! gfc_get_entry_result_type (gfc_symbol *sym)
! {
!   tree type;
! 
!   type = gfc_sym_type (sym->result);
! 
!   /* Mixed ENTRY master unions must use the ABI return type of each entry.
!      Under -ff2c, default REAL entries return C double even though their
!      Fortran result symbol remains default REAL.  */
!   if (flag_f2c
!       && sym->ts.type == BT_REAL
!       && sym->ts.kind == gfc_default_real_kind
!       && !sym->attr.pointer
!       && !sym->attr.allocatable
!       && !sym->attr.always_explicit)
!     type = gfc_get_real_type (gfc_default_double_kind);
! 
!   return type;
! }
! 
  static tree
  gfc_get_mixed_entry_union (gfc_namespace *ns)
  {
*************** gfc_get_mixed_entry_union (gfc_namespace
*** 2999,3005 ****
        if (el == el2)
  	gfc_add_field_to_struct_1 (type,
  				   get_identifier (el->sym->result->name),
! 				   gfc_sym_type (el->sym->result), &chain);
      }
  
    /* Finish off the type.  */
--- 3020,3027 ----
        if (el == el2)
  	gfc_add_field_to_struct_1 (type,
  				   get_identifier (el->sym->result->name),
! 				   gfc_get_entry_result_type (el->sym),
! 				   &chain);
      }
  
    /* Finish off the type.  */
*************** gfc_get_mixed_entry_union (gfc_namespace
*** 3007,3013 ****
    TYPE_DECL_SUPPRESS_DEBUG (TYPE_STUB_DECL (type)) = 1;
    return type;
  }
! 
  /* Create a "fn spec" based on the formal arguments;
     cf. create_function_arglist.  */
  
--- 3029,3035 ----
    TYPE_DECL_SUPPRESS_DEBUG (TYPE_STUB_DECL (type)) = 1;
    return type;
  }
! 
  /* Create a "fn spec" based on the formal arguments;
     cf. create_function_arglist.  */
  
*************** arg_type_list_done:
*** 3328,3334 ****
  
    return type;
  }
! 
  /* Language hooks for middle-end access to type nodes.  */
  
  /* Return an integer type with BITS bits of precision,
--- 3350,3356 ----
  
    return type;
  }
! 
  /* Language hooks for middle-end access to type nodes.  */
  
  /* Return an integer type with BITS bits of precision,
diff -Nrcpad gcc-13.4.0/gcc/fwprop.cc gcc-13.5.0-RC-20260904/gcc/fwprop.cc
*** gcc-13.4.0/gcc/fwprop.cc	Thu Jun  5 16:02:58 2025
--- gcc-13.5.0-RC-20260904/gcc/fwprop.cc	Fri Sep  4 07:35:08 2026
*************** forward_propagate_into (use_info *use, b
*** 837,842 ****
--- 837,856 ----
    if (def_insn->is_artificial ())
      return false;
  
+   /* Do not propagate asms.  The only kind of propagation that would
+      succeed is propagation into a register move.  Such a propagation
+      is neutral if the destination of the move is a pseudo and unnecessarily
+      restricts the register allocator if the destination of the move is
+      a hard register.
+ 
+      Furthermore, unlike for a normal instruction, we cannot take a SET from an
+      asm and try dropping the CLOBBERs.  The recog process does not (and should
+      not try to) second-guess whether what the user wrote can be changed and
+      so it has to assume that any asm given to it is a fair reflection of
+      what the user wrote.  */
+   if (def_insn->is_asm ())
+     return false;
+ 
    rtx_insn *def_rtl = def_insn->rtl ();
    if (!NONJUMP_INSN_P (def_rtl))
      return false;
diff -Nrcpad gcc-13.4.0/gcc/gengtype-lex.cc gcc-13.5.0-RC-20260904/gcc/gengtype-lex.cc
*** gcc-13.4.0/gcc/gengtype-lex.cc	Thu Jun  5 16:06:28 2025
--- gcc-13.5.0-RC-20260904/gcc/gengtype-lex.cc	Fri Sep  4 07:36:30 2026
*************** int yy_flex_debug = 0;
*** 1188,1194 ****
  #define YY_MORE_ADJ 0
  #define YY_RESTORE_YY_MORE_OFFSET
  char *yytext;
! #line 1 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  /* -*- indented-text -*- */
  /* Process source files and output type information.
     Copyright (C) 2002-2023 Free Software Foundation, Inc.
--- 1188,1194 ----
  #define YY_MORE_ADJ 0
  #define YY_RESTORE_YY_MORE_OFFSET
  char *yytext;
! #line 1 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  /* -*- indented-text -*- */
  /* Process source files and output type information.
     Copyright (C) 2002-2023 Free Software Foundation, Inc.
*************** You should have received a copy of the G
*** 1209,1215 ****
  along with GCC; see the file COPYING3.  If not see
  .  */
  #define YY_NO_INPUT 1
! #line 24 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  #ifdef HOST_GENERATOR_FILE
  #include "config.h"
  #define GENERATOR_FILE 1
--- 1209,1215 ----
  along with GCC; see the file COPYING3.  If not see
  .  */
  #define YY_NO_INPUT 1
! #line 24 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  #ifdef HOST_GENERATOR_FILE
  #include "config.h"
  #define GENERATOR_FILE 1
*************** update_lineno (const char *l, size_t len
*** 1238,1244 ****
  }
  
  #line 1235 "gengtype-lex.cc"
! #line 59 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
      /* Include '::' in identifiers to capture C++ scope qualifiers.  */
  
  #line 1239 "gengtype-lex.cc"
--- 1238,1244 ----
  }
  
  #line 1235 "gengtype-lex.cc"
! #line 59 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
      /* Include '::' in identifiers to capture C++ scope qualifiers.  */
  
  #line 1239 "gengtype-lex.cc"
*************** YY_DECL
*** 1462,1468 ****
  		}
  
  	{
! #line 67 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  
    /* Do this on entry to yylex():  */
    *yylval = 0;
--- 1462,1468 ----
  		}
  
  	{
! #line 67 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  
    /* Do this on entry to yylex():  */
    *yylval = 0;
*************** YY_LINENO_REWIND_TO(yy_cp - 1);
*** 1534,1540 ****
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 78 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return TYPEDEF;
--- 1534,1540 ----
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 78 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return TYPEDEF;
*************** YY_LINENO_REWIND_TO(yy_cp - 1);
*** 1547,1553 ****
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 82 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return STRUCT;
--- 1547,1553 ----
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 82 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return STRUCT;
*************** YY_LINENO_REWIND_TO(yy_cp - 1);
*** 1560,1566 ****
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 86 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return UNION;
--- 1560,1566 ----
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 86 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return UNION;
*************** YY_LINENO_REWIND_TO(yy_cp - 1);
*** 1573,1579 ****
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 90 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return STRUCT;
--- 1573,1579 ----
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 90 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return STRUCT;
*************** YY_LINENO_REWIND_TO(yy_cp - 1);
*** 1586,1592 ****
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 94 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return EXTERN;
--- 1586,1592 ----
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 94 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return EXTERN;
*************** YY_LINENO_REWIND_TO(yy_cp - 1);
*** 1599,1605 ****
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 98 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return STATIC;
--- 1599,1605 ----
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 98 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    BEGIN(in_struct);
    return STATIC;
*************** YY_RULE_SETUP
*** 1610,1634 ****
  
  case 7:
  YY_RULE_SETUP
! #line 106 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { BEGIN(in_struct_comment); }
  	YY_BREAK
  case 8:
  /* rule 8 can match eol */
  YY_RULE_SETUP
! #line 107 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { lexer_line.line++; }
  	YY_BREAK
  case 9:
  /* rule 9 can match eol */
  YY_RULE_SETUP
! #line 109 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { update_lineno (yytext, yyleng); }
  	YY_BREAK
  case 10:
  /* rule 10 can match eol */
  YY_RULE_SETUP
! #line 110 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { lexer_line.line++; }
  	YY_BREAK
  case 11:
--- 1610,1634 ----
  
  case 7:
  YY_RULE_SETUP
! #line 106 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { BEGIN(in_struct_comment); }
  	YY_BREAK
  case 8:
  /* rule 8 can match eol */
  YY_RULE_SETUP
! #line 107 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { lexer_line.line++; }
  	YY_BREAK
  case 9:
  /* rule 9 can match eol */
  YY_RULE_SETUP
! #line 109 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { update_lineno (yytext, yyleng); }
  	YY_BREAK
  case 10:
  /* rule 10 can match eol */
  YY_RULE_SETUP
! #line 110 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { lexer_line.line++; }
  	YY_BREAK
  case 11:
*************** YY_LINENO_REWIND_TO(yy_bp + 5);
*** 1638,1644 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 5;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 112 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  /* don't care */
  	YY_BREAK
  case 12:
--- 1638,1644 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 5;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 112 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  /* don't care */
  	YY_BREAK
  case 12:
*************** case 12:
*** 1647,1663 ****
  YY_LINENO_REWIND_TO(yy_cp - 1);
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
! #line 114 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  case 13:
  /* rule 13 can match eol */
! #line 115 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  case 14:
  /* rule 14 can match eol */
! #line 116 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  case 15:
  /* rule 15 can match eol */
  YY_RULE_SETUP
! #line 116 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
      *yylval = XDUPVAR (const char, yytext, yyleng, yyleng + 1);
      return IGNORABLE_CXX_KEYWORD;
--- 1647,1663 ----
  YY_LINENO_REWIND_TO(yy_cp - 1);
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
! #line 114 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  case 13:
  /* rule 13 can match eol */
! #line 115 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  case 14:
  /* rule 14 can match eol */
! #line 116 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  case 15:
  /* rule 15 can match eol */
  YY_RULE_SETUP
! #line 116 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
      *yylval = XDUPVAR (const char, yytext, yyleng, yyleng + 1);
      return IGNORABLE_CXX_KEYWORD;
*************** YY_LINENO_REWIND_TO(yy_bp + 3);
*** 1670,1676 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 3;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 120 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return GTY_TOKEN; }
  	YY_BREAK
  case 17:
--- 1670,1676 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 3;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 120 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return GTY_TOKEN; }
  	YY_BREAK
  case 17:
*************** YY_LINENO_REWIND_TO(yy_bp + 5);
*** 1680,1686 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 5;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 121 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return UNION; }
  	YY_BREAK
  case 18:
--- 1680,1686 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 5;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 121 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return UNION; }
  	YY_BREAK
  case 18:
*************** YY_LINENO_REWIND_TO(yy_bp + 6);
*** 1690,1696 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 6;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 122 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return STRUCT; }
  	YY_BREAK
  case 19:
--- 1690,1696 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 6;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 122 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return STRUCT; }
  	YY_BREAK
  case 19:
*************** YY_LINENO_REWIND_TO(yy_bp + 5);
*** 1700,1706 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 5;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 123 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return STRUCT; }
  	YY_BREAK
  case 20:
--- 1700,1706 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 5;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 123 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return STRUCT; }
  	YY_BREAK
  case 20:
*************** YY_LINENO_REWIND_TO(yy_bp + 7);
*** 1710,1716 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 7;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 124 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return TYPEDEF; }
  	YY_BREAK
  case 21:
--- 1710,1716 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 7;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 124 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return TYPEDEF; }
  	YY_BREAK
  case 21:
*************** YY_LINENO_REWIND_TO(yy_bp + 4);
*** 1720,1726 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 4;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 125 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return ENUM; }
  	YY_BREAK
  case 22:
--- 1720,1726 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 4;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 125 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return ENUM; }
  	YY_BREAK
  case 22:
*************** YY_LINENO_REWIND_TO(yy_bp + 9);
*** 1730,1736 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 9;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 126 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return PTR_ALIAS; }
  	YY_BREAK
  case 23:
--- 1730,1736 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 9;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 126 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return PTR_ALIAS; }
  	YY_BREAK
  case 23:
*************** YY_LINENO_REWIND_TO(yy_bp + 10);
*** 1740,1746 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 10;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 127 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return NESTED_PTR; }
  	YY_BREAK
  case 24:
--- 1740,1746 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 10;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 127 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return NESTED_PTR; }
  	YY_BREAK
  case 24:
*************** YY_LINENO_REWIND_TO(yy_bp + 4);
*** 1750,1761 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 4;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 128 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return USER_GTY; }
  	YY_BREAK
  case 25:
  YY_RULE_SETUP
! #line 129 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    *yylval = XDUPVAR (const char, yytext, yyleng, yyleng+1);
    return NUM;
--- 1750,1761 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 4;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 128 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return USER_GTY; }
  	YY_BREAK
  case 25:
  YY_RULE_SETUP
! #line 129 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    *yylval = XDUPVAR (const char, yytext, yyleng, yyleng+1);
    return NUM;
*************** case 26:
*** 1767,1777 ****
  YY_LINENO_REWIND_TO(yy_cp - 1);
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
! #line 135 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  case 27:
  /* rule 27 can match eol */
  YY_RULE_SETUP
! #line 135 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    size_t len;
  
--- 1767,1777 ----
  YY_LINENO_REWIND_TO(yy_cp - 1);
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
! #line 135 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  case 27:
  /* rule 27 can match eol */
  YY_RULE_SETUP
! #line 135 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    size_t len;
  
*************** YY_LINENO_REWIND_TO(yy_cp - 1);
*** 1790,1796 ****
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 146 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    *yylval = XDUPVAR (const char, yytext, yyleng, yyleng+1);
    return ID;
--- 1790,1796 ----
  (yy_c_buf_p) = yy_cp -= 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 146 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    *yylval = XDUPVAR (const char, yytext, yyleng, yyleng+1);
    return ID;
*************** YY_RULE_SETUP
*** 1799,1805 ****
  case 29:
  /* rule 29 can match eol */
  YY_RULE_SETUP
! #line 151 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    *yylval = XDUPVAR (const char, yytext+1, yyleng-2, yyleng-1);
    return STRING;
--- 1799,1805 ----
  case 29:
  /* rule 29 can match eol */
  YY_RULE_SETUP
! #line 151 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    *yylval = XDUPVAR (const char, yytext+1, yyleng-2, yyleng-1);
    return STRING;
*************** YY_RULE_SETUP
*** 1809,1815 ****
  case 30:
  /* rule 30 can match eol */
  YY_RULE_SETUP
! #line 156 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    *yylval = XDUPVAR (const char, yytext+1, yyleng-2, yyleng-1);
    return ARRAY;
--- 1809,1815 ----
  case 30:
  /* rule 30 can match eol */
  YY_RULE_SETUP
! #line 156 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    *yylval = XDUPVAR (const char, yytext+1, yyleng-2, yyleng-1);
    return ARRAY;
*************** YY_RULE_SETUP
*** 1818,1824 ****
  case 31:
  /* rule 31 can match eol */
  YY_RULE_SETUP
! #line 160 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    *yylval = XDUPVAR (const char, yytext+1, yyleng-2, yyleng);
    return CHAR;
--- 1818,1824 ----
  case 31:
  /* rule 31 can match eol */
  YY_RULE_SETUP
! #line 160 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    *yylval = XDUPVAR (const char, yytext+1, yyleng-2, yyleng);
    return CHAR;
*************** YY_RULE_SETUP
*** 1826,1849 ****
  	YY_BREAK
  case 32:
  YY_RULE_SETUP
! #line 165 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return ELLIPSIS; }
  	YY_BREAK
  case 33:
  YY_RULE_SETUP
! #line 166 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { return yytext[0]; }
  	YY_BREAK
  /* ignore pp-directives */
  case 34:
  /* rule 34 can match eol */
  YY_RULE_SETUP
! #line 169 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {lexer_line.line++;}
  	YY_BREAK
  case 35:
  YY_RULE_SETUP
! #line 171 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    error_at_line (&lexer_line, "unexpected character `%s'", yytext);
  }
--- 1826,1849 ----
  	YY_BREAK
  case 32:
  YY_RULE_SETUP
! #line 165 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return ELLIPSIS; }
  	YY_BREAK
  case 33:
  YY_RULE_SETUP
! #line 166 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { return yytext[0]; }
  	YY_BREAK
  /* ignore pp-directives */
  case 34:
  /* rule 34 can match eol */
  YY_RULE_SETUP
! #line 169 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {lexer_line.line++;}
  	YY_BREAK
  case 35:
  YY_RULE_SETUP
! #line 171 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    error_at_line (&lexer_line, "unexpected character `%s'", yytext);
  }
*************** YY_RULE_SETUP
*** 1851,1886 ****
  
  case 36:
  YY_RULE_SETUP
! #line 176 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { BEGIN(in_comment); }
  	YY_BREAK
  case 37:
  /* rule 37 can match eol */
  YY_RULE_SETUP
! #line 177 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { lexer_line.line++; }
  	YY_BREAK
  case 38:
  /* rule 38 can match eol */
  YY_RULE_SETUP
! #line 178 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { lexer_line.line++; }
  	YY_BREAK
  case 39:
! #line 180 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  case 40:
  /* rule 40 can match eol */
! #line 181 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  case 41:
  /* rule 41 can match eol */
  YY_RULE_SETUP
! #line 181 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  /* do nothing */
  	YY_BREAK
  case 42:
  /* rule 42 can match eol */
  YY_RULE_SETUP
! #line 182 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { update_lineno (yytext, yyleng); }
  	YY_BREAK
  case 43:
--- 1851,1886 ----
  
  case 36:
  YY_RULE_SETUP
! #line 176 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { BEGIN(in_comment); }
  	YY_BREAK
  case 37:
  /* rule 37 can match eol */
  YY_RULE_SETUP
! #line 177 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { lexer_line.line++; }
  	YY_BREAK
  case 38:
  /* rule 38 can match eol */
  YY_RULE_SETUP
! #line 178 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { lexer_line.line++; }
  	YY_BREAK
  case 39:
! #line 180 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  case 40:
  /* rule 40 can match eol */
! #line 181 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  case 41:
  /* rule 41 can match eol */
  YY_RULE_SETUP
! #line 181 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  /* do nothing */
  	YY_BREAK
  case 42:
  /* rule 42 can match eol */
  YY_RULE_SETUP
! #line 182 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { update_lineno (yytext, yyleng); }
  	YY_BREAK
  case 43:
*************** YY_LINENO_REWIND_TO(yy_bp + 1);
*** 1890,1910 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 183 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  /* do nothing */
  	YY_BREAK
  
  case 44:
  /* rule 44 can match eol */
  YY_RULE_SETUP
! #line 186 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { lexer_line.line++; }
  	YY_BREAK
  case 45:
! #line 188 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  case 46:
  YY_RULE_SETUP
! #line 188 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  /* do nothing */
  	YY_BREAK
  case 47:
--- 1890,1910 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 183 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  /* do nothing */
  	YY_BREAK
  
  case 44:
  /* rule 44 can match eol */
  YY_RULE_SETUP
! #line 186 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { lexer_line.line++; }
  	YY_BREAK
  case 45:
! #line 188 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  case 46:
  YY_RULE_SETUP
! #line 188 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  /* do nothing */
  	YY_BREAK
  case 47:
*************** YY_LINENO_REWIND_TO(yy_bp + 1);
*** 1914,1938 ****
  (yy_c_buf_p) = yy_cp = yy_bp + 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 189 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  /* do nothing */
  	YY_BREAK
  
  case 48:
  YY_RULE_SETUP
! #line 192 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { BEGIN(INITIAL); } 
  	YY_BREAK
  case 49:
  YY_RULE_SETUP
! #line 193 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  { BEGIN(in_struct); }
  	YY_BREAK
  case 50:
! #line 196 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  case 51:
  YY_RULE_SETUP
! #line 196 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  {
    error_at_line (&lexer_line, 
  		 "unterminated comment or string; unexpected EOF");
--- 1914,1938 ----
  (yy_c_buf_p) = yy_cp = yy_bp + 1;
  YY_DO_BEFORE_ACTION; /* set up yytext again */
  YY_RULE_SETUP
! #line 189 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  /* do nothing */
  	YY_BREAK
  
  case 48:
  YY_RULE_SETUP
! #line 192 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { BEGIN(INITIAL); } 
  	YY_BREAK
  case 49:
  YY_RULE_SETUP
! #line 193 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  { BEGIN(in_struct); }
  	YY_BREAK
  case 50:
! #line 196 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  case 51:
  YY_RULE_SETUP
! #line 196 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  {
    error_at_line (&lexer_line, 
  		 "unterminated comment or string; unexpected EOF");
*************** YY_RULE_SETUP
*** 1941,1952 ****
  case 52:
  /* rule 52 can match eol */
  YY_RULE_SETUP
! #line 201 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  /* do nothing */
  	YY_BREAK
  case 53:
  YY_RULE_SETUP
! #line 203 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  YY_FATAL_ERROR( "flex scanner jammed" );
  	YY_BREAK
  #line 1947 "gengtype-lex.cc"
--- 1941,1952 ----
  case 52:
  /* rule 52 can match eol */
  YY_RULE_SETUP
! #line 201 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  /* do nothing */
  	YY_BREAK
  case 53:
  YY_RULE_SETUP
! #line 203 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  YY_FATAL_ERROR( "flex scanner jammed" );
  	YY_BREAK
  #line 1947 "gengtype-lex.cc"
*************** void yyfree (void * ptr )
*** 2924,2930 ****
  
  #define YYTABLES_NAME "yytables"
  
! #line 203 "/d/gcc-13.4.0/gcc-13.4.0/gcc/gengtype-lex.l"
  
  
  void
--- 2924,2930 ----
  
  #define YYTABLES_NAME "yytables"
  
! #line 203 "/home/rguenther/src/releases/gcc-13.5.0-RC-20260904/gcc-13.5.0-RC-20260904/gcc/gengtype-lex.l"
  
  
  void
diff -Nrcpad gcc-13.4.0/gcc/gimple-fold.cc gcc-13.5.0-RC-20260904/gcc/gimple-fold.cc
*** gcc-13.4.0/gcc/gimple-fold.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/gimple-fold.cc	Fri Sep  4 07:35:08 2026
*************** fold_const_aggregate_ref_1 (tree t, tree
*** 8339,8357 ****
        base = get_ref_base_and_extent (t, &offset, &size, &max_size, &reverse);
        ctor = get_base_constructor (base, &offset, valueize);
  
        /* Empty constructor.  Always fold to 0.  */
        if (ctor == error_mark_node)
  	return build_zero_cst (TREE_TYPE (t));
!       /* We do not know precise address.  */
        if (!known_size_p (max_size) || maybe_ne (max_size, size))
  	return NULL_TREE;
-       /* We cannot determine ctor.  */
-       if (!ctor)
- 	return NULL_TREE;
- 
        /* Out of bound array access.  Value is undefined, but don't fold.  */
        if (maybe_lt (offset, 0))
  	return NULL_TREE;
  
        tem = fold_ctor_reference (TREE_TYPE (t), ctor, offset, size, base);
        if (tem)
--- 8339,8359 ----
        base = get_ref_base_and_extent (t, &offset, &size, &max_size, &reverse);
        ctor = get_base_constructor (base, &offset, valueize);
  
+       /* We cannot determine ctor.  */
+       if (!ctor)
+ 	return NULL_TREE;
        /* Empty constructor.  Always fold to 0.  */
        if (ctor == error_mark_node)
  	return build_zero_cst (TREE_TYPE (t));
!       /* We do not know precise access.  */
        if (!known_size_p (max_size) || maybe_ne (max_size, size))
  	return NULL_TREE;
        /* Out of bound array access.  Value is undefined, but don't fold.  */
        if (maybe_lt (offset, 0))
  	return NULL_TREE;
+       /* Access with reverse storage order.  */
+       if (reverse)
+ 	return NULL_TREE;
  
        tem = fold_ctor_reference (TREE_TYPE (t), ctor, offset, size, base);
        if (tem)
*************** fold_const_aggregate_ref_1 (tree t, tree
*** 8371,8377 ****
  	      && offset.is_constant (&coffset)
  	      && (coffset % BITS_PER_UNIT != 0
  		  || csize % BITS_PER_UNIT != 0)
- 	      && !reverse
  	      && BYTES_BIG_ENDIAN == WORDS_BIG_ENDIAN)
  	    {
  	      poly_int64 bitoffset;
--- 8373,8378 ----
diff -Nrcpad gcc-13.4.0/gcc/gimple-isel.cc gcc-13.5.0-RC-20260904/gcc/gimple-isel.cc
*** gcc-13.4.0/gcc/gimple-isel.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/gimple-isel.cc	Fri Sep  4 07:35:08 2026
*************** gimple_expand_vec_set_expr (struct funct
*** 69,81 ****
  
    tree val = gimple_assign_rhs1 (stmt);
    tree op0 = TREE_OPERAND (lhs, 0);
!   if (TREE_CODE (op0) == VIEW_CONVERT_EXPR && DECL_P (TREE_OPERAND (op0, 0))
        && VECTOR_TYPE_P (TREE_TYPE (TREE_OPERAND (op0, 0)))
!       && TYPE_MODE (TREE_TYPE (lhs))
! 	   == TYPE_MODE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (op0, 0)))))
      {
        tree pos = TREE_OPERAND (lhs, 1);
        tree view_op0 = TREE_OPERAND (op0, 0);
        machine_mode outermode = TYPE_MODE (TREE_TYPE (view_op0));
        if ((auto_var_in_fn_p (view_op0, fun->decl)
  	   || (VAR_P (view_op0) && DECL_HARD_REGISTER (view_op0)))
--- 69,95 ----
  
    tree val = gimple_assign_rhs1 (stmt);
    tree op0 = TREE_OPERAND (lhs, 0);
!   if (TREE_CODE (op0) == VIEW_CONVERT_EXPR
!       && DECL_P (TREE_OPERAND (op0, 0))
        && VECTOR_TYPE_P (TREE_TYPE (TREE_OPERAND (op0, 0)))
!       && (TYPE_MODE (TREE_TYPE (lhs))
! 	  == TYPE_MODE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (op0, 0))))))
      {
        tree pos = TREE_OPERAND (lhs, 1);
        tree view_op0 = TREE_OPERAND (op0, 0);
+ 
+       // if index is a constant, then check the bounds
+       poly_uint64 idx_poly;
+       if (poly_int_tree_p (pos, &idx_poly))
+ 	{
+ 	  poly_uint64 nelts = TYPE_VECTOR_SUBPARTS (TREE_TYPE (view_op0));
+ 	  if (known_ge (idx_poly, nelts))
+ 	    return false;
+ 	}
+       else if (poly_int_tree_p (pos))
+ 	// if idx doesn't fit into poly_uint64, but is constant, it
+ 	// must be out of bounds
+ 	return false;
        machine_mode outermode = TYPE_MODE (TREE_TYPE (view_op0));
        if ((auto_var_in_fn_p (view_op0, fun->decl)
  	   || (VAR_P (view_op0) && DECL_HARD_REGISTER (view_op0)))
diff -Nrcpad gcc-13.4.0/gcc/gimple-range-fold.cc gcc-13.5.0-RC-20260904/gcc/gimple-range-fold.cc
*** gcc-13.4.0/gcc/gimple-range-fold.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/gimple-range-fold.cc	Fri Sep  4 07:35:08 2026
*************** fold_using_range::relation_fold_and_or (
*** 1064,1070 ****
      return;
  
    if (reverse_op2)
!     relation2 = relation_negate (relation2);
  
    // x && y is false if the relation intersection of the true cases is NULL.
    if (is_and && relation_intersect (relation1, relation2) == VREL_UNDEFINED)
--- 1064,1070 ----
      return;
  
    if (reverse_op2)
!     relation2 = relation_swap (relation2);
  
    // x && y is false if the relation intersection of the true cases is NULL.
    if (is_and && relation_intersect (relation1, relation2) == VREL_UNDEFINED)
diff -Nrcpad gcc-13.4.0/gcc/gimple-range-op.cc gcc-13.5.0-RC-20260904/gcc/gimple-range-op.cc
*** gcc-13.4.0/gcc/gimple-range-op.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/gimple-range-op.cc	Fri Sep  4 07:35:08 2026
*************** gimple_range_op_handler::maybe_builtin_c
*** 857,862 ****
--- 857,864 ----
    switch (func)
      {
      case CFN_BUILT_IN_CONSTANT_P:
+       if (gimple_call_num_args (call) != 1)
+ 	return;
        m_op1 = gimple_call_arg (call, 0);
        m_valid = true;
        if (irange::supports_p (TREE_TYPE (m_op1)))
*************** gimple_range_op_handler::maybe_builtin_c
*** 868,873 ****
--- 870,877 ----
        break;
  
      CASE_FLT_FN (CFN_BUILT_IN_SIGNBIT):
+       if (gimple_call_num_args (call) != 1)
+ 	return;
        m_op1 = gimple_call_arg (call, 0);
        m_float = &op_cfn_signbit;
        m_valid = true;
diff -Nrcpad gcc-13.4.0/gcc/gimple-ssa-isolate-paths.cc gcc-13.5.0-RC-20260904/gcc/gimple-ssa-isolate-paths.cc
*** gcc-13.4.0/gcc/gimple-ssa-isolate-paths.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/gimple-ssa-isolate-paths.cc	Fri Sep  4 07:35:08 2026
*************** handle_return_addr_local_phi_arg (basic_
*** 641,647 ****
        if (!return_stmt)
  	continue;
  
!       if (gimple_return_retval (return_stmt) != lhs)
  	continue;
  
        /* Add an entry for the return statement and the locations
--- 641,648 ----
        if (!return_stmt)
  	continue;
  
!       if (gimple_return_retval (return_stmt) != lhs
! 	  || !dominated_by_p (CDI_DOMINATORS, gimple_bb (use_stmt), bb))
  	continue;
  
        /* Add an entry for the return statement and the locations
*************** find_implicit_erroneous_behavior (void)
*** 715,738 ****
   	 is then dereferenced within BB.  This is somewhat overly
  	 conservative, but probably catches most of the interesting
  	 cases.   */
        for (si = gsi_start_phis (bb); !gsi_end_p (si); gsi_next (&si))
  	{
  	  gphi *phi = si.phi ();
  	  tree lhs = gimple_phi_result (phi);
  
- 	  /* Initial number of PHI arguments.  The result may change
- 	     from one iteration of the loop below to the next in
- 	     response to changes to the CFG but only the initial
- 	     value is stored below for use by diagnostics.  */
- 	  unsigned nargs = gimple_phi_num_args (phi);
- 
  	  /* PHI produces a pointer result.  See if any of the PHI's
  	     arguments are NULL.
  
  	     When we remove an edge, we want to reprocess the current
  	     index since the argument at that index will have been
  	     removed, hence the ugly way we update I for each iteration.  */
- 	  basic_block duplicate = NULL;
  	  for (unsigned i = 0, next_i = 0;
  	       i < gimple_phi_num_args (phi); i = next_i)
  	    {
--- 716,733 ----
   	 is then dereferenced within BB.  This is somewhat overly
  	 conservative, but probably catches most of the interesting
  	 cases.   */
+       basic_block duplicate = NULL;
        for (si = gsi_start_phis (bb); !gsi_end_p (si); gsi_next (&si))
  	{
  	  gphi *phi = si.phi ();
  	  tree lhs = gimple_phi_result (phi);
  
  	  /* PHI produces a pointer result.  See if any of the PHI's
  	     arguments are NULL.
  
  	     When we remove an edge, we want to reprocess the current
  	     index since the argument at that index will have been
  	     removed, hence the ugly way we update I for each iteration.  */
  	  for (unsigned i = 0, next_i = 0;
  	       i < gimple_phi_num_args (phi); i = next_i)
  	    {
*************** find_implicit_erroneous_behavior (void)
*** 742,756 ****
  	      /* Advance the argument index unless a path involving
  		 the current argument has been isolated.  */
  	      next_i = i + 1;
- 	      bool isolated = false;
- 	      duplicate = handle_return_addr_local_phi_arg (bb, duplicate, lhs,
- 							    arg, e, locmap,
- 							    nargs, &isolated);
- 	      if (isolated)
- 		{
- 		  cfg_altered = true;
- 		  next_i = i;
- 		}
  
  	      if (!integer_zerop (arg))
  		continue;
--- 737,742 ----
*************** find_implicit_erroneous_behavior (void)
*** 788,793 ****
--- 774,821 ----
  		}
  	    }
  	}
+ 
+       /* Then look for a PHI which have addresses of locals that
+ 	 are then returned.  */
+       duplicate = NULL;
+       for (si = gsi_start_phis (bb); !gsi_end_p (si); gsi_next (&si))
+ 	{
+ 	  gphi *phi = si.phi ();
+ 	  tree lhs = gimple_phi_result (phi);
+ 
+ 	  /* Initial number of PHI arguments.  The result may change
+ 	     from one iteration of the loop below to the next in
+ 	     response to changes to the CFG but only the initial
+ 	     value is stored below for use by diagnostics.  */
+ 	  unsigned nargs = gimple_phi_num_args (phi);
+ 
+ 	  /* PHI produces a pointer result.  See if any of the PHI's
+ 	     arguments are NULL.
+ 
+ 	     When we remove an edge, we want to reprocess the current
+ 	     index since the argument at that index will have been
+ 	     removed, hence the ugly way we update I for each iteration.  */
+ 	  for (unsigned i = 0, next_i = 0;
+ 	       i < gimple_phi_num_args (phi); i = next_i)
+ 	    {
+ 	      tree arg = gimple_phi_arg_def (phi, i);
+ 	      edge e = gimple_phi_arg_edge (phi, i);
+ 
+ 	      /* Advance the argument index unless a path involving
+ 		 the current argument has been isolated.  */
+ 	      next_i = i + 1;
+ 	      bool isolated = false;
+ 	      duplicate = handle_return_addr_local_phi_arg (bb, duplicate, lhs,
+ 							    arg, e, locmap,
+ 							    nargs, &isolated);
+ 	      if (isolated)
+ 		{
+ 		  cfg_altered = true;
+ 		  next_i = i;
+ 		}
+ 	    }
+ 	}
+ 
      }
  
    diag_returned_locals (false, locmap);
diff -Nrcpad gcc-13.4.0/gcc/gimplify-me.cc gcc-13.5.0-RC-20260904/gcc/gimplify-me.cc
*** gcc-13.4.0/gcc/gimplify-me.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/gimplify-me.cc	Fri Sep  4 07:35:08 2026
*************** gimple_regimplify_operands (gimple *stmt
*** 232,240 ****
  	  else if (i == 2
  		   && gimple_assign_single_p (stmt)
  		   && num_ops == 2)
! 	    gimplify_expr (&op, &pre, NULL,
! 			   rhs_predicate_for (gimple_assign_lhs (stmt)),
! 			   fb_rvalue);
  	  else if (i == 2 && is_gimple_call (stmt))
  	    {
  	      if (TREE_CODE (op) == FUNCTION_DECL)
--- 232,244 ----
  	  else if (i == 2
  		   && gimple_assign_single_p (stmt)
  		   && num_ops == 2)
! 	    {
! 	      if (gimple_clobber_p (stmt))
! 		continue;
! 	      gimplify_expr (&op, &pre, NULL,
! 			     rhs_predicate_for (gimple_assign_lhs (stmt)),
! 			     fb_rvalue);
! 	    }
  	  else if (i == 2 && is_gimple_call (stmt))
  	    {
  	      if (TREE_CODE (op) == FUNCTION_DECL)
*************** gimple_regimplify_operands (gimple *stmt
*** 253,260 ****
  	{
  	  bool need_temp = false;
  
! 	  if (gimple_assign_single_p (stmt)
! 	      && num_ops == 2)
  	    gimplify_expr (gimple_assign_rhs1_ptr (stmt), &pre, NULL,
  			   rhs_predicate_for (gimple_assign_lhs (stmt)),
  			   fb_rvalue);
--- 257,265 ----
  	{
  	  bool need_temp = false;
  
! 	  if (gimple_clobber_p (stmt))
! 	    ;
! 	  else if (gimple_assign_single_p (stmt) && num_ops == 2)
  	    gimplify_expr (gimple_assign_rhs1_ptr (stmt), &pre, NULL,
  			   rhs_predicate_for (gimple_assign_lhs (stmt)),
  			   fb_rvalue);
diff -Nrcpad gcc-13.4.0/gcc/gimplify.cc gcc-13.5.0-RC-20260904/gcc/gimplify.cc
*** gcc-13.4.0/gcc/gimplify.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/gimplify.cc	Fri Sep  4 07:35:08 2026
*************** gimplify_call_expr (tree *expr_p, gimple
*** 3599,3604 ****
--- 3599,3624 ----
  	  *expr_p = NULL_TREE;
  	  return GS_ALL_DONE;
  	}
+       else if (ifn == IFN_UBSAN_BOUNDS
+ 	       && nargs == 3
+ 	       && integer_onep (CALL_EXPR_ARG (*expr_p, 0)))
+ 	{
+ 	  /* If first argument is one, add TYPE_MAX_VALUE (TYPE_DOMAIN (t))
+ 	     to 3rd argument and change first argument to 0.  This is
+ 	     done by ubsan_instrument_bounds so that we can use the
+ 	     max value from gimplify_type_sizes here instead of original
+ 	     expression for VLAs.  */
+ 	  tree type = TREE_TYPE (CALL_EXPR_ARG (*expr_p, 0));
+ 	  CALL_EXPR_ARG (*expr_p, 0) = build_int_cst (type, 0);
+ 	  gcc_assert (TREE_CODE (type) == POINTER_TYPE);
+ 	  type = TREE_TYPE (type);
+ 	  gcc_assert (TREE_CODE (type) == ARRAY_TYPE);
+ 	  tree maxv = TYPE_MAX_VALUE (TYPE_DOMAIN (type));
+ 	  gcc_assert (maxv);
+ 	  tree arg3 = CALL_EXPR_ARG (*expr_p, 2);
+ 	  CALL_EXPR_ARG (*expr_p, 2)
+ 	    = fold_build2 (PLUS_EXPR, TREE_TYPE (arg3), maxv, arg3);
+ 	}
  
        for (i = 0; i < nargs; i++)
  	{
diff -Nrcpad gcc-13.4.0/gcc/glimits.h gcc-13.5.0-RC-20260904/gcc/glimits.h
*** gcc-13.4.0/gcc/glimits.h	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/glimits.h	Fri Sep  4 07:35:08 2026
*************** see the files COPYING3 and COPYING.RUNTI
*** 157,163 ****
  # undef BOOL_WIDTH
  # define BOOL_WIDTH 1
  
! # define __STDC_VERSION_LIMITS_H__	202311L
  #endif
  
  #endif /* _LIMITS_H___ */
--- 157,165 ----
  # undef BOOL_WIDTH
  # define BOOL_WIDTH 1
  
! # ifndef __STDC_VERSION_LIMITS_H__
! #  define __STDC_VERSION_LIMITS_H__	202311L
! # endif
  #endif
  
  #endif /* _LIMITS_H___ */
diff -Nrcpad gcc-13.4.0/gcc/ifcvt.cc gcc-13.5.0-RC-20260904/gcc/ifcvt.cc
*** gcc-13.4.0/gcc/ifcvt.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/ifcvt.cc	Fri Sep  4 07:35:08 2026
*************** find_if_header (basic_block test_bb, int
*** 4738,4744 ****
        && cond_exec_find_if_block (&ce_info))
      goto success;
  
!   if (targetm.have_trap ()
        && optab_handler (ctrap_optab, word_mode) != CODE_FOR_nothing
        && find_cond_trap (test_bb, then_edge, else_edge))
      goto success;
--- 4738,4744 ----
        && cond_exec_find_if_block (&ce_info))
      goto success;
  
!   if (!reload_completed && targetm.have_trap ()
        && optab_handler (ctrap_optab, word_mode) != CODE_FOR_nothing
        && find_cond_trap (test_bb, then_edge, else_edge))
      goto success;
diff -Nrcpad gcc-13.4.0/gcc/ipa-cp.cc gcc-13.5.0-RC-20260904/gcc/ipa-cp.cc
*** gcc-13.4.0/gcc/ipa-cp.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/ipa-cp.cc	Fri Sep  4 07:35:08 2026
*************** initialize_node_lattices (struct cgraph_
*** 1575,1584 ****
        int caller_count = 0;
        node->call_for_symbol_thunks_and_aliases (count_callers, &caller_count,
  						true);
-       gcc_checking_assert (caller_count > 0);
        if (caller_count == 1)
  	node->call_for_symbol_thunks_and_aliases (set_single_call_flag,
  						  NULL, true);
      }
    else
      {
--- 1575,1588 ----
        int caller_count = 0;
        node->call_for_symbol_thunks_and_aliases (count_callers, &caller_count,
  						true);
        if (caller_count == 1)
  	node->call_for_symbol_thunks_and_aliases (set_single_call_flag,
  						  NULL, true);
+       else if (caller_count == 0)
+ 	{
+ 	  gcc_checking_assert (!opt_for_fn (node->decl, flag_toplevel_reorder));
+ 	  variable = true;
+ 	}
      }
    else
      {
*************** self_recursive_pass_through_p (cgraph_ed
*** 5476,5484 ****
  			       bool simple = true)
  {
    enum availability availability;
!   if (cs->caller == cs->callee->function_symbol (&availability)
        && availability > AVAIL_INTERPOSABLE
-       && jfunc->type == IPA_JF_PASS_THROUGH
        && (!simple || ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
        && ipa_get_jf_pass_through_formal_id (jfunc) == i
        && ipa_node_params_sum->get (cs->caller)
--- 5480,5488 ----
  			       bool simple = true)
  {
    enum availability availability;
!   if (jfunc->type == IPA_JF_PASS_THROUGH
!       && cs->caller == cs->callee->function_symbol (&availability)
        && availability > AVAIL_INTERPOSABLE
        && (!simple || ipa_get_jf_pass_through_operation (jfunc) == NOP_EXPR)
        && ipa_get_jf_pass_through_formal_id (jfunc) == i
        && ipa_node_params_sum->get (cs->caller)
*************** self_recursive_pass_through_p (cgraph_ed
*** 5487,5492 ****
--- 5491,5515 ----
    return false;
  }
  
+ /* Return true if JFUNC, which describes the i-th parameter of call CS, is an
+    ancestor function with zero offset to itself when the cgraph_node involved
+    is not an IPA-CP clone.  */
+ 
+ static bool
+ self_recursive_ancestor_p (cgraph_edge *cs, ipa_jump_func *jfunc, int i)
+ {
+   enum availability availability;
+   if (jfunc->type == IPA_JF_ANCESTOR
+       && cs->caller == cs->callee->function_symbol (&availability)
+       && availability > AVAIL_INTERPOSABLE
+       && ipa_get_jf_ancestor_offset (jfunc) == 0
+       && ipa_get_jf_ancestor_formal_id (jfunc) == i
+       && ipa_node_params_sum->get (cs->caller)
+       && !ipa_node_params_sum->get (cs->caller)->ipcp_orig_node)
+     return true;
+   return false;
+ }
+ 
  /* Return true if JFUNC, which describes a part of an aggregate represented or
     pointed to by the i-th parameter of call CS, is a pass-through function to
     itself when the cgraph_node involved is not an IPA-CP clone..  When
*************** find_more_scalar_values_for_callers_subs
*** 5570,5575 ****
--- 5593,5600 ----
  				ipa_get_jf_pass_through_operand (jump_func),
  				type);
  	    }
+ 	  else if (self_recursive_ancestor_p (cs, jump_func, i))
+ 	    continue;
  	  else
  	    t = ipa_value_from_jfunc (ipa_node_params_sum->get (cs->caller),
  				      jump_func, type);
*************** push_agg_values_for_index_from_edge (str
*** 5735,5741 ****
  	      && !src_plats->aggs_bottom
  	      && (agg_jf_preserved || !src_plats->aggs_by_ref))
  	    {
! 	      if (interim && self_recursive_pass_through_p (cs, jfunc, index))
  		{
  		  interim->push_adjusted_values (src_idx, index, unit_delta,
  						 res);
--- 5760,5767 ----
  	      && !src_plats->aggs_bottom
  	      && (agg_jf_preserved || !src_plats->aggs_by_ref))
  	    {
! 	      if (interim && (self_recursive_pass_through_p (cs, jfunc, index)
! 			      || self_recursive_ancestor_p (cs, jfunc, index)))
  		{
  		  interim->push_adjusted_values (src_idx, index, unit_delta,
  						 res);
diff -Nrcpad gcc-13.4.0/gcc/ipa-modref.cc gcc-13.5.0-RC-20260904/gcc/ipa-modref.cc
*** gcc-13.4.0/gcc/ipa-modref.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/ipa-modref.cc	Fri Sep  4 07:35:08 2026
*************** ipa_merge_modref_summary_after_inlining
*** 5272,5288 ****
  				      : NULL;
    class modref_summary_lto *callee_info_lto
  		 = summaries_lto ? summaries_lto->get (edge->callee) : NULL;
    int flags = flags_from_decl_or_type (edge->callee->decl);
!   /* Combine in outer flags.  */
!   cgraph_node *n;
!   for (n = edge->caller; n->inlined_to; n = n->callers->caller)
!     flags |= flags_from_decl_or_type (n->decl);
!   flags |= flags_from_decl_or_type (n->decl);
!   bool ignore_stores = ignore_stores_p (edge->caller->decl, flags);
  
    if (!callee_info && to_info)
      {
!       if (!(flags & (ECF_CONST | ECF_PURE | ECF_NOVOPS)))
  	to_info->loads->collapse ();
        if (!ignore_stores)
  	to_info->stores->collapse ();
--- 5272,5321 ----
  				      : NULL;
    class modref_summary_lto *callee_info_lto
  		 = summaries_lto ? summaries_lto->get (edge->callee) : NULL;
+ 
+   /* Compute effective ECF_CONST, ECF_PURE, ECF_NOVOPS,
+      ECF_LOOPING_CONST_OR_PURE and ignore_stores of the inlined function from
+      the point of view of caller of the function it is transitively inlined to.
+ 
+      Consider inline chain A->B->C, where (edge is the edge B->C).
+      ECF_CONST, ECF_PURE_ECF, ECF_NOVOPS and ignore_stores is the strongest
+      flag seen on the inline path.
+ 
+      ECF_LOOPING_CONST_OR_PURE is bit special since, for example if C
+      is ECF_CONST | ECF_LOOPING_CONST_OR_PURE and B is ECF_PURE, then outcome
+      is ECF_CONST and !ECF_LOOPING_CONST_OR_PURE.
+ 
+      Flags are later used to avoid merging info about side-effects of C which
+      are invisible to to the caller of A.  For example, it is possible for
+      const function to have local array and call non-const functions modifying
+      it.  */
+ 
    int flags = flags_from_decl_or_type (edge->callee->decl);
!   bool ignore_stores = ignore_stores_p (edge->callee->decl, flags);
! 
!   for (cgraph_node *n = edge->caller; n;
!        n = n->inlined_to ? n->callers->caller : NULL)
!     {
!       int f = flags_from_decl_or_type (n->decl);
! 
!       ignore_stores |= ignore_stores_p (n->decl, f);
!       /* If we see first CONST/PURE flag in the chain, take its
! 	 ECF_LOOPING_CONST_OR_PURE  */
!       if (!(flags & (ECF_CONST | ECF_PURE)) && (f & (ECF_CONST | ECF_PURE)))
! 	flags |= (f & ECF_LOOPING_CONST_OR_PURE);
!       /* If we already have ECF_CONST or ECF_PURE flag
! 	 just improve ECF_LOOPING_CONST_OR_PURE if possible.  */
!       else if ((flags & (ECF_CONST | ECF_PURE))
! 	       && (flags & ECF_LOOPING_CONST_OR_PURE)
! 	       && (f & (ECF_CONST | ECF_PURE))
! 	       && !(f & ECF_LOOPING_CONST_OR_PURE))
! 	flags &= ECF_LOOPING_CONST_OR_PURE;
!       flags |= f & (ECF_CONST | ECF_PURE | ECF_NOVOPS);
!     }
  
    if (!callee_info && to_info)
      {
!       if (!(flags & (ECF_CONST | ECF_NOVOPS)))
  	to_info->loads->collapse ();
        if (!ignore_stores)
  	to_info->stores->collapse ();
diff -Nrcpad gcc-13.4.0/gcc/ipa-param-manipulation.cc gcc-13.5.0-RC-20260904/gcc/ipa-param-manipulation.cc
*** gcc-13.4.0/gcc/ipa-param-manipulation.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/ipa-param-manipulation.cc	Fri Sep  4 07:35:08 2026
*************** ipa_param_body_adjustments::prepare_debu
*** 1307,1314 ****
  	}
  
        gcc_assert (TREE_CODE (value) == SSA_NAME);
!       tree *d = m_dead_ssa_debug_equiv.get (value);
!       m_dead_ssa_debug_equiv.put (dead_ssa, *d);
        return true;
      }
  
--- 1307,1314 ----
  	}
  
        gcc_assert (TREE_CODE (value) == SSA_NAME);
!       tree d = *m_dead_ssa_debug_equiv.get (value);
!       m_dead_ssa_debug_equiv.put (dead_ssa, d);
        return true;
      }
  
diff -Nrcpad gcc-13.4.0/gcc/ira.cc gcc-13.5.0-RC-20260904/gcc/ira.cc
*** gcc-13.4.0/gcc/ira.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/ira.cc	Fri Sep  4 07:35:08 2026
*************** combine_and_move_insns (void)
*** 3901,3906 ****
--- 3901,3907 ----
  	continue;
  
        rtx_insn *use_insn = 0;
+       bool multiple_insns = false;
        for (df_ref use = DF_REG_USE_CHAIN (regno);
  	   use;
  	   use = DF_REF_NEXT_REG (use))
*************** combine_and_move_insns (void)
*** 3908,3918 ****
  	  {
  	    if (DEBUG_INSN_P (DF_REF_INSN (use)))
  	      continue;
! 	    gcc_assert (!use_insn);
  	    use_insn = DF_REF_INSN (use);
  	  }
        gcc_assert (use_insn);
  
        /* Don't substitute into jumps.  indirect_jump_optimize does
  	 this for anything we are prepared to handle.  */
        if (JUMP_P (use_insn))
--- 3909,3928 ----
  	  {
  	    if (DEBUG_INSN_P (DF_REF_INSN (use)))
  	      continue;
! 	    if (use_insn && DF_REF_INSN (use) != use_insn)
! 	      {
! 		multiple_insns = true;
! 		break;
! 	      }
  	    use_insn = DF_REF_INSN (use);
  	  }
        gcc_assert (use_insn);
  
+       /* If a register is used by more than one insn, we cannot trivially move
+ 	 or delete the definition anymore.  */
+       if (multiple_insns)
+ 	continue;
+ 
        /* Don't substitute into jumps.  indirect_jump_optimize does
  	 this for anything we are prepared to handle.  */
        if (JUMP_P (use_insn))
diff -Nrcpad gcc-13.4.0/gcc/lra-constraints.cc gcc-13.5.0-RC-20260904/gcc/lra-constraints.cc
*** gcc-13.4.0/gcc/lra-constraints.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/lra-constraints.cc	Fri Sep  4 07:35:08 2026
*************** get_equiv (rtx x)
*** 518,523 ****
--- 518,524 ----
    rtx res;
  
    if (! REG_P (x) || (regno = REGNO (x)) < FIRST_PSEUDO_REGISTER
+       || regno >= ira_reg_equiv_len
        || ! ira_reg_equiv[regno].defined_p
        || ! ira_reg_equiv[regno].profitable_p
        || lra_get_regno_hard_regno (regno) >= 0)
diff -Nrcpad gcc-13.4.0/gcc/lra-remat.cc gcc-13.5.0-RC-20260904/gcc/lra-remat.cc
*** gcc-13.4.0/gcc/lra-remat.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/lra-remat.cc	Fri Sep  4 07:35:08 2026
*************** typedef const struct cand *const_cand_t;
*** 81,88 ****
  
  /* Insn candidates for rematerialization.  The candidate insn should
     have the following properies:
!    o no any memory (as access to memory is non-profitable)
     o no INOUT regs (it means no non-paradoxical subreg of output reg)
     o one output spilled pseudo (or reload pseudo of a spilled pseudo)
     o all other pseudos are with assigned hard regs.  */
  struct cand
--- 81,90 ----
  
  /* Insn candidates for rematerialization.  The candidate insn should
     have the following properies:
!    o no any memory (as access to memory is non-profitable) or
!      div/mod operations (as they are usually more expensive than loads)
     o no INOUT regs (it means no non-paradoxical subreg of output reg)
+    o no multiple output pseudos
     o one output spilled pseudo (or reload pseudo of a spilled pseudo)
     o all other pseudos are with assigned hard regs.  */
  struct cand
*************** finish_cand_table (void)
*** 249,260 ****
  
  
  
! /* Return true if X contains memory or some UNSPEC.  We cannot just
!    check insn operands as memory or unspec might be not an operand
!    itself but contain an operand.  Insn with memory access is not
!    profitable for rematerialization.  Rematerialization of UNSPEC
!    might result in wrong code generation as the UNPEC effect is
!    unknown (e.g. generating a label).  */
  static bool
  bad_for_rematerialization_p (rtx x)
  {
--- 251,262 ----
  
  
  
! /* Return true if X contains memory, some UNSPEC, or expensive operations.  We
!    cannot just check insn operands as memory or unspec might be not an operand
!    itself but contain an operand.  Insns with memory access or expensive ones
!    are not profitable for rematerialization.  Rematerialization of UNSPEC might
!    result in wrong code generation as the UNPEC effect is unknown
!    (e.g. generating a label).  */
  static bool
  bad_for_rematerialization_p (rtx x)
  {
*************** bad_for_rematerialization_p (rtx x)
*** 262,268 ****
    const char *fmt;
    enum rtx_code code;
  
!   if (MEM_P (x) || GET_CODE (x) == UNSPEC || GET_CODE (x) == UNSPEC_VOLATILE)
      return true;
    code = GET_CODE (x);
    fmt = GET_RTX_FORMAT (code);
--- 264,274 ----
    const char *fmt;
    enum rtx_code code;
  
!   if (MEM_P (x) || GET_CODE (x) == UNSPEC || GET_CODE (x) == UNSPEC_VOLATILE
!       /* Usually the following operations are expensive and does not worth to
! 	 rematerialize: */
!       || GET_CODE(x) == DIV || GET_CODE(x) == UDIV
!       || GET_CODE(x) == MOD || GET_CODE(x) == UMOD)
      return true;
    code = GET_CODE (x);
    fmt = GET_RTX_FORMAT (code);
*************** operand_to_remat (rtx_insn *insn)
*** 308,315 ****
  	 cannot know sp offset at a rematerialization place.  */
        if (reg->regno == STACK_POINTER_REGNUM && frame_pointer_needed)
  	return -1;
!       else if (reg->type == OP_OUT && ! reg->subreg_p
! 	       && find_regno_note (insn, REG_UNUSED, reg->regno) == NULL)
  	{
  	  /* We permits only one spilled reg.  */
  	  if (found_reg != NULL)
--- 314,320 ----
  	 cannot know sp offset at a rematerialization place.  */
        if (reg->regno == STACK_POINTER_REGNUM && frame_pointer_needed)
  	return -1;
!       else if (reg->type == OP_OUT)
  	{
  	  /* We permits only one spilled reg.  */
  	  if (found_reg != NULL)
diff -Nrcpad gcc-13.4.0/gcc/lto/ChangeLog gcc-13.5.0-RC-20260904/gcc/lto/ChangeLog
*** gcc-13.4.0/gcc/lto/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/gcc/lto/ChangeLog	Fri Sep  4 07:35:08 2026
***************
*** 1,3 ****
--- 1,12 ----
+ 2026-02-26  Michal Jires  
+ 
+ 	Backported from master:
+ 	2026-01-11  Michal Jires  
+ 
+ 	PR lto/121588
+ 	* lto-symtab.cc (lto_symtab_merge_symbols): Set body_removed
+ 	for symbols resolved outside of IR.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/gcc/lto/lto-symtab.cc gcc-13.5.0-RC-20260904/gcc/lto/lto-symtab.cc
*** gcc-13.4.0/gcc/lto/lto-symtab.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/lto/lto-symtab.cc	Fri Sep  4 07:35:08 2026
*************** lto_symtab_merge_symbols (void)
*** 1040,1045 ****
--- 1040,1046 ----
  		      node->analyzed = node->definition = false;
  		      node->remove_all_references ();
  		    }
+ 		  node->body_removed = true;
  		}
  	      DECL_EXTERNAL (node->decl) = 1;
  	    }
diff -Nrcpad gcc-13.4.0/gcc/match.pd gcc-13.5.0-RC-20260904/gcc/match.pd
*** gcc-13.4.0/gcc/match.pd	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/match.pd	Fri Sep  4 07:35:08 2026
*************** DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
*** 2501,2507 ****
  #if GENERIC
  (simplify
    (pointer_plus (convert:s (pointer_plus:s @0 @1)) @3)
!   (convert:type (pointer_plus @0 (plus @1 @3))))
  #endif
  
  /* Pattern match
--- 2501,2507 ----
  #if GENERIC
  (simplify
    (pointer_plus (convert:s (pointer_plus:s @0 @1)) @3)
!   (pointer_plus (convert:type @0) (plus @1 @3)))
  #endif
  
  /* Pattern match
*************** DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
*** 6439,6445 ****
     (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
      (convert (gt @0 (trunc_div! { TYPE_MAX_VALUE (TREE_TYPE (@0)); } @1)))
      (if (TYPE_MIN_VALUE (TREE_TYPE (@0)))
!      (if (integer_minus_onep (@1))
        (convert (eq @0 { TYPE_MIN_VALUE (TREE_TYPE (@0)); }))
        (with
         {
--- 6439,6445 ----
     (if (TYPE_UNSIGNED (TREE_TYPE (@0)))
      (convert (gt @0 (trunc_div! { TYPE_MAX_VALUE (TREE_TYPE (@0)); } @1)))
      (if (TYPE_MIN_VALUE (TREE_TYPE (@0)))
!      (if (!TYPE_UNSIGNED (TREE_TYPE (@1)) && integer_minus_onep (@1))
        (convert (eq @0 { TYPE_MIN_VALUE (TREE_TYPE (@0)); }))
        (with
         {
*************** and,
*** 7934,7946 ****
     (with { tree op_type = TREE_TYPE (@3); }
      (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type)
          && is_truth_type_for (op_type, TREE_TYPE (@0)))
!      (cond_op @0 @1 @2))))
   (simplify
    (vec_cond @0 @1 (view_convert? (uncond_op@3 @2)))
     (with { tree op_type = TREE_TYPE (@3); }
      (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type)
          && is_truth_type_for (op_type, TREE_TYPE (@0)))
!      (cond_op (bit_not @0) @2 @1)))))
  
  /* Simplify:
  
--- 7934,7946 ----
     (with { tree op_type = TREE_TYPE (@3); }
      (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type)
          && is_truth_type_for (op_type, TREE_TYPE (@0)))
!      (cond_op @0 (view_convert @1) @2))))
   (simplify
    (vec_cond @0 @1 (view_convert? (uncond_op@3 @2)))
     (with { tree op_type = TREE_TYPE (@3); }
      (if (vectorized_internal_fn_supported_p (as_internal_fn (cond_op), op_type)
          && is_truth_type_for (op_type, TREE_TYPE (@0)))
!      (cond_op (bit_not @0) (view_convert @2) @1)))))
  
  /* Simplify:
  
*************** and,
*** 8121,8126 ****
--- 8121,8127 ----
  			 ? gimple_assign_rhs1 (SSA_NAME_DEF_STMT (@0)) : @0);
  	    tree elt = ctor_single_nonzero_element (ctor); }
        (if (elt
+ 	   && types_match (type, TREE_TYPE (elt))
  	   && !HONOR_SNANS (type)
  	   && !HONOR_SIGNED_ZEROS (type))
  	{ elt; }))))
*************** and,
*** 8527,8529 ****
--- 8528,8535 ----
        }
        (if (full_perm_p)
  	(vec_perm (op@3 @0 @1) @3 @2))))))
+ 
+ /* Strip nop-conversions __builtin_constant_p arguments.  */
+ (simplify
+  (BUILT_IN_CONSTANT_P (nop_convert@1 @0))
+  (BUILT_IN_CONSTANT_P @0))
diff -Nrcpad gcc-13.4.0/gcc/omp-expand.cc gcc-13.5.0-RC-20260904/gcc/omp-expand.cc
*** gcc-13.4.0/gcc/omp-expand.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/omp-expand.cc	Fri Sep  4 07:35:08 2026
*************** expand_omp_for_init_counts (struct omp_f
*** 1860,1865 ****
--- 1860,1866 ----
  	}
      }
    bool rect_count_seen = false;
+   bool init_n2 = SSA_VAR_P (fd->loop.n2) && zero_iter1_bb;
    for (i = 0; i < (fd->ordered ? fd->ordered : fd->collapse); i++)
      {
        tree itype = TREE_TYPE (fd->loops[i].v);
*************** expand_omp_for_init_counts (struct omp_f
*** 1884,1889 ****
--- 1885,1905 ----
  	{
  	  gcond *cond_stmt;
  	  tree n1, n2;
+ 	  if (init_n2 && i < fd->collapse && !rect_count_seen)
+ 	    {
+ 	      /* When called with non-NULL zero_iter1_bb, we won't clear
+ 		 fd->loop.n2 in the if (zero_iter_bb == NULL) code below
+ 		 and if it is prior to storing fd->loop.n2 where
+ 		 rect_count_seen is set, it could be used uninitialized.
+ 		 As zero_iter1_bb in that case can be reached also if there
+ 		 are non-zero iterations, the clearing can't be emitted
+ 		 to the zero_iter1_bb, but needs to be done before the
+ 		 condition.  */
+ 	      gassign *assign_stmt
+ 		= gimple_build_assign (fd->loop.n2, build_zero_cst (type));
+ 	      gsi_insert_before (gsi, assign_stmt, GSI_SAME_STMT);
+ 	      init_n2 = false;
+ 	    }
  	  n1 = fold_convert (itype, unshare_expr (fd->loops[i].n1));
  	  n1 = force_gimple_operand_gsi (gsi, n1, true, NULL_TREE,
  					 true, GSI_SAME_STMT);
*************** extract_omp_for_update_vars (struct omp_
*** 3248,3254 ****
  	  if (DECL_P (v) && TREE_ADDRESSABLE (v))
  	    v = force_gimple_operand_gsi (&gsi, v, true, NULL_TREE,
  					  false, GSI_CONTINUE_LINKING);
! 	  t = fold_build2 (fd->loops[i].cond_code, boolean_type_node, v, t);
  	  stmt = gimple_build_cond_empty (t);
  	  gsi_insert_after (&gsi, stmt, GSI_CONTINUE_LINKING);
  	  if (walk_tree (gimple_cond_lhs_ptr (as_a  (stmt)),
--- 3264,3270 ----
  	  if (DECL_P (v) && TREE_ADDRESSABLE (v))
  	    v = force_gimple_operand_gsi (&gsi, v, true, NULL_TREE,
  					  false, GSI_CONTINUE_LINKING);
! 	  t = build2 (fd->loops[i].cond_code, boolean_type_node, v, t);
  	  stmt = gimple_build_cond_empty (t);
  	  gsi_insert_after (&gsi, stmt, GSI_CONTINUE_LINKING);
  	  if (walk_tree (gimple_cond_lhs_ptr (as_a  (stmt)),
diff -Nrcpad gcc-13.4.0/gcc/omp-low.cc gcc-13.5.0-RC-20260904/gcc/omp-low.cc
*** gcc-13.4.0/gcc/omp-low.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/omp-low.cc	Fri Sep  4 07:35:08 2026
*************** lower_omp_regimplify_operands_p (tree *t
*** 14352,14357 ****
--- 14352,14359 ----
        lower_omp_regimplify_operands_data *ldata
  	= (lower_omp_regimplify_operands_data *) wi->info;
        tree o = maybe_lookup_decl (t, ldata->ctx);
+       if (o == NULL_TREE)
+ 	o = maybe_lookup_decl_in_outer_ctx (t, ldata->ctx);
        if (o != t)
  	{
  	  ldata->decls->safe_push (DECL_VALUE_EXPR (*tp));
*************** diagnose_sb_2 (gimple_stmt_iterator *gsi
*** 15002,15007 ****
--- 15004,15022 ----
  	    n = splay_tree_lookup (all_labels, (splay_tree_key) lab);
  	    if (n && diagnose_sb_0 (gsi_p, context, (gimple *) n->value))
  	      break;
+ 	  }
+       }
+       break;
+ 
+     case GIMPLE_ASM:
+       {
+ 	gasm *asm_stmt = as_a  (stmt);
+ 	for (unsigned i = 0; i < gimple_asm_nlabels (asm_stmt); ++i)
+ 	  {
+ 	    tree lab = TREE_VALUE (gimple_asm_label_op (asm_stmt, i));
+ 	    n = splay_tree_lookup (all_labels, (splay_tree_key) lab);
+ 	    if (n && diagnose_sb_0 (gsi_p, context, (gimple *) n->value))
+ 	      break;
  	  }
        }
        break;
diff -Nrcpad gcc-13.4.0/gcc/optabs.cc gcc-13.5.0-RC-20260904/gcc/optabs.cc
*** gcc-13.4.0/gcc/optabs.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/optabs.cc	Fri Sep  4 07:35:08 2026
*************** avoid_expensive_constant (machine_mode m
*** 1353,1360 ****
  static rtx
  expand_binop_directly (enum insn_code icode, machine_mode mode, optab binoptab,
  		       rtx op0, rtx op1,
! 		       rtx target, int unsignedp, enum optab_methods methods,
! 		       rtx_insn *last)
  {
    machine_mode xmode0 = insn_data[(int) icode].operand[1].mode;
    machine_mode xmode1 = insn_data[(int) icode].operand[2].mode;
--- 1353,1359 ----
  static rtx
  expand_binop_directly (enum insn_code icode, machine_mode mode, optab binoptab,
  		       rtx op0, rtx op1,
! 		       rtx target, int unsignedp, enum optab_methods methods)
  {
    machine_mode xmode0 = insn_data[(int) icode].operand[1].mode;
    machine_mode xmode1 = insn_data[(int) icode].operand[2].mode;
*************** expand_binop_directly (enum insn_code ic
*** 1364,1369 ****
--- 1363,1369 ----
    rtx_insn *pat;
    rtx xop0 = op0, xop1 = op1;
    bool canonicalize_op1 = false;
+   rtx_insn *last = get_last_insn ();
  
    /* If it is a commutative operator and the modes would match
       if we would swap the operands, we can save the conversions.  */
*************** expand_binop_directly (enum insn_code ic
*** 1428,1437 ****
        tmp_mode = insn_data[(int) icode].operand[0].mode;
        if (VECTOR_MODE_P (mode)
  	  && maybe_ne (GET_MODE_NUNITS (tmp_mode), 2 * GET_MODE_NUNITS (mode)))
! 	{
! 	  delete_insns_since (last);
! 	  return NULL_RTX;
! 	}
      }
    else
      tmp_mode = mode;
--- 1428,1434 ----
        tmp_mode = insn_data[(int) icode].operand[0].mode;
        if (VECTOR_MODE_P (mode)
  	  && maybe_ne (GET_MODE_NUNITS (tmp_mode), 2 * GET_MODE_NUNITS (mode)))
! 	return NULL_RTX;
      }
    else
      tmp_mode = mode;
*************** expand_binop_directly (enum insn_code ic
*** 1451,1464 ****
  			       ops[1].value, ops[2].value, mode0))
  	{
  	  delete_insns_since (last);
! 	  return expand_binop (mode, binoptab, op0, op1, NULL_RTX,
! 			       unsignedp, methods);
  	}
  
        emit_insn (pat);
        return ops[0].value;
      }
!   delete_insns_since (last);
    return NULL_RTX;
  }
  
--- 1448,1461 ----
  			       ops[1].value, ops[2].value, mode0))
  	{
  	  delete_insns_since (last);
! 	  return expand_binop_directly (icode, mode, binoptab, op0, op1,
! 					NULL_RTX, unsignedp, methods);
  	}
  
        emit_insn (pat);
        return ops[0].value;
      }
! 
    return NULL_RTX;
  }
  
*************** expand_binop (machine_mode mode, optab b
*** 1527,1535 ****
        if (icode != CODE_FOR_nothing)
  	{
  	  temp = expand_binop_directly (icode, mode, binoptab, op0, op1,
! 					target, unsignedp, methods, last);
  	  if (temp)
  	    return temp;
  	}
      }
  
--- 1524,1533 ----
        if (icode != CODE_FOR_nothing)
  	{
  	  temp = expand_binop_directly (icode, mode, binoptab, op0, op1,
! 					target, unsignedp, methods);
  	  if (temp)
  	    return temp;
+ 	  delete_insns_since (last);
  	}
      }
  
*************** expand_binop (machine_mode mode, optab b
*** 1555,1563 ****
  			       NULL_RTX, unsignedp, OPTAB_DIRECT);
  
        temp = expand_binop_directly (icode, int_mode, otheroptab, op0, newop1,
! 				    target, unsignedp, methods, last);
        if (temp)
  	return temp;
      }
  
    /* If this is a multiply, see if we can do a widening operation that
--- 1553,1562 ----
  			       NULL_RTX, unsignedp, OPTAB_DIRECT);
  
        temp = expand_binop_directly (icode, int_mode, otheroptab, op0, newop1,
! 				    target, unsignedp, methods);
        if (temp)
  	return temp;
+       delete_insns_since (last);
      }
  
    /* If this is a multiply, see if we can do a widening operation that
*************** expand_binop (machine_mode mode, optab b
*** 1621,1629 ****
  	  if (vop1)
  	    {
  	      temp = expand_binop_directly (icode, mode, otheroptab, op0, vop1,
! 					    target, unsignedp, methods, last);
  	      if (temp)
  		return temp;
  	    }
  	}
      }
--- 1620,1629 ----
  	  if (vop1)
  	    {
  	      temp = expand_binop_directly (icode, mode, otheroptab, op0, vop1,
! 					    target, unsignedp, methods);
  	      if (temp)
  		return temp;
+ 	      delete_insns_since (last);
  	    }
  	}
      }
diff -Nrcpad gcc-13.4.0/gcc/po/be.gmo gcc-13.5.0-RC-20260904/gcc/po/be.gmo
*** gcc-13.4.0/gcc/po/be.gmo	Thu Jun  5 16:21:55 2025
--- gcc-13.5.0-RC-20260904/gcc/po/be.gmo	Fri Sep  4 07:50:35 2026
*************** Last-Translator: Ales Nyakhaychyk 
  Language: be
  MIME-Version: 1.0
! Content-Type: text/plain; charset=utf-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  
--- 19,25 ----
  Language-Team: Belarusian 
  Language: be
  MIME-Version: 1.0
! Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  
diff -Nrcpad gcc-13.4.0/gcc/po/el.gmo gcc-13.5.0-RC-20260904/gcc/po/el.gmo
*** gcc-13.4.0/gcc/po/el.gmo	Thu Jun  5 16:21:55 2025
--- gcc-13.5.0-RC-20260904/gcc/po/el.gmo	Fri Sep  4 07:50:35 2026
*************** Last-Translator: Simos Xenitellis 
  Language: el
  MIME-Version: 1.0
! Content-Type: text/plain; charset=utf-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  
--- 30,36 ----
  Language-Team: Greek 
  Language: el
  MIME-Version: 1.0
! Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  
diff -Nrcpad gcc-13.4.0/gcc/po/id.gmo gcc-13.5.0-RC-20260904/gcc/po/id.gmo
*** gcc-13.4.0/gcc/po/id.gmo	Thu Jun  5 16:21:55 2025
--- gcc-13.5.0-RC-20260904/gcc/po/id.gmo	Fri Sep  4 07:50:35 2026
*************** F%F 4F!UFwF3
*** 30,75 ****
  X8XEX dX$X#X.XXY-3YaYwY/YCY5Y"0Z/SZ+Z3Z"Z&['-[(U[~[2[&[#["\(6\"_\5\'\+\3]4@]u]*]-]0]'^4C^,x^'^&^(^9_4W_(_E_)_1%`&W`:~`*`!`a/"aRaYa5oa,a<ab3,b7`b1b4b:b5:c)pccccAc@)d9jd&dd%d6
e3De!xeDe/e=f!Mf3of<ff)g+*g%Vg%|ggggg%h(7h-`h6hh(hi$+i+Pi"|i-i,ii'j!?jaj1}j7jLjL4k*kJkBk.:l il.lOlB	mKLmJmKmK/nJ{nKn5o7Ho9o9oDoD9p@~p	pp<pq-%q.SqBq(q)q1r<Jr/r/r7r)s(Isrs's's	sst."tQt"nttt
t7t.u@u>VuNuMu32vfv6v<v5v70w-hw+w-w*w1xMx`x}xJx%x&y&2y YyzyAyyyz$z9zXzuz,zz2z${98{-r{{{D{=|#O|Cs|<|I|%>}'d} }$}-}4~+5~a~~~!~7~10K)|9$# )J!Z"|*&5:E=/-<Y8B&^$3ރ++("Tw
  	)+Ȅ8'-4U$(ʅ"/F!]*),)=:5x4))
-7"e*+߈-'#)K&u5'҉-(En9!݊'''9O3;/2)3\3/Č33(\)|$@ˍ$!1Sl(Z+"Fi8$ԏ.(((Q4z97=!/_4.đ.4".W.,999V:9˓:9@9zWWd!y.-$.<(k1'Ɩ+:-Z(<()Rk6/)%Y7G@$@@e@$:Navțޛ"6IZtȜۜ93-%a(F++#+O+{,,Ԟ4X6Alџ5>;t192k<2  2A(tE3F'^*!ϣ6R(/{ (("G*j)ȥ7&*#Q/u88ަ.3F-z&'ϧFC>=8OI0d/ũD۩1 ,R08H(2$[/50"*'MuF(Ӭ)/&6VAEϭ 46k4ݮ/#!Ce')ů!"$&G n/ܰ41$f6<.3'b%Ҳ+9G4.)*>?P~9ϴ#	.-2\;˵&1	0;'l-G¶/
  .:4i&+ŷ0"+: f/1Ҹ!,&<S0!# D=dCD+6K7B,/'\6+!50#f Aʽ(	5'?&g*ʾ*8 "Y|<25%)[%"  
! -+"Y!|%% :WoA-C1q%.:*6M%b,NQJVIEaD-UrD 
W.1(" '-H-v6###/&Ho"/HBc)VQ'Ryc80Wiai#A))	73*k4VS"/v7L(+&T7{Yx
,6dOO--2+.0Z _:*G:r+F$ 3E2y/25PEA2<K29F*<6g'?;<B$!P4`L61,=C#0@-JE=7.?5Hu,nAZ3F71O80/?,[@">-+2YX4#7E[MF"-i G).*RY9XH[)@0/@pY34R%l#A>(W.!''I!%k !-?B \}p76V*4L-:7hK@:-h+/#;B<1.24)^0~,!/8./gU?7-5e0O;]XZT_fy7@6x*'&43[+AL&i2-('4Bw%/.	!8&Z'!19Vu5.#/BSA2#+4O-'!	+/Eu<'%%EHLU^#|'T*DH,/)-*(X%&%%"&='d#!+1>p%'.9*-d&':#=@D~:8!7-Y;! "')9Q*JG	 I	)j		-		+	&
! V7
! 
! 2
! )
! &./"^A(#!>`"o#)
! 
! 
! ,
0

! P

! [

! f

! q

! |
&
!


! 


! 

! 
! 
! !)
! KV@Z+e.;8)(,R/,.A+M.y5371<i4<E4-z6H6()_.?(:-cG-/?7BwUp/NZE[<'';.Lj:@+3%_/+O:16l76?AR:=>
3L=2CE5:{H55I$\DP6J : & $ 6!@?!H!H!G"Z"ay"6"&#:9#t#a#<#?2$^r$1$+%E/%Eu%%4%T&8]&J&&&$'B-'Ip'J';(A(`(w(A(;(6)H))e)
! ))6)2)@*#T*Ix*G*@
! +BK+1+;+#+7 ,"X,S{,@,4-GE-L-1->.=K.'.1.C.8'/"`/?/</B06C0Uz050v1l}121G2Le22H2!3:3FW373>3T4/j44D4C4<A5%~5)5+5s5Bn6X6W
! 7sb7H7[87{8/8:8N9m9,9'9D9"::G::+;$C;h;-;&;0;(
<6<V<"v<4<-<#<" =.C=1r=$=4="=*!>DL>=><>=?*J?Lu?D?L@CT@F@>@AAF`AEAPAG>BCB/B-B*(C:SC*C2C*C.D.FD]uD1DE E29E0lE0E<E;FRGFBFFhF(dGAGGGSHYHjH#{H/H6HII,PI4}I-I!I%J)(J/RJJJ#JJJK".KQK$qK0K)K-KL84L"mL-LLLL LM(M;M*TM"M
M#MMM5
! N'@N6hN"N9N9N86O&oOUO"O7P3GPN{P6P>Q;@Q=|Q3Q:Q))R>SRcRMRFDSMS.S6TE?TT$Uh:UjUV?V+_V,V/V;VA$WQfW]WKX;bX,XUX6!YAXY8Y4Y+Z&4ZG[Z+ZZJZ.9[Ah[+[5[\B,\Ko\?\.\C*]Cn]*]1]C^S^.r^^;^U^*P_>{_M_.`-7`*e`K`K`R(aO{a/a;a17b;ib"b*b9b9-c'gcMc;c&dT@dOd8dee=WfLfIfI,g.vg2g$g(g#&hJh2h%iY=i%i3i"i/jBDj0j1j.j8k!Rktkk3k9k3lK@l5l3lAl18mGjmGmGm6Bn!yn&nKn_ono0o,oho7QpBpKpDq(]q%q0q/q=
r-Kr3yr r.rr,s%Isos$s?s,s+t*Gt.rt?t>t? u>`u9u3u6
vDDvAv9vwO"w<rwAw7w:)xNdxNx,y!/y<Qy,y1y1y0zJPz*z+zNzA{a{/{/{={2|3R|H|7|.}.6} e}L}%}}2~8F~~8~~(~REpNA4G*|0؀'B!b0Uʁ4 Ul@3߂P"d97%;.[<=DŽ?3E8yB+;!=]<C؆	&=>.|$.ЇICI=.>WW::E%2kIV/?Bo)P܋;-Ci68J<#Y4T:XfLOC]S>Y%.7Ay%&4=V&u'#Ē(a(sJ7K1C}2;"0S0_06ٕ++</h/HȖ:ILKDi'45Ƙ13N0p'$!L>n;8$"4G6|015/LJ|Eǜ0
,>Bk/(ޝ4'<8d,,ʞ-.%(T%}'*˟B09-j0)ɠ/*#-N(|*6С((0"Y*|"Bʢ?
'MuGYɣ=#0a$/+&4:%o+*mZH8"1D֧[;[*%4D!y81ԩ73>7r-2ت"(K2]7ȫ35+Q}-4ɬMML#8;3 /=,;j==1"=T4)ǰ'f2Ʊ{ksf߲LF4ȳ1)'=;e30մ)#0=T?2ҵG5M8432%9X93̷%"&+I
u4+'O=\/(ʹ"-=D=AY%\2-»?0*A:l6/޼D9S:KȽG\{&#(
-
! J2U'W$%-&Sz5%bWNVB@7RZ+'49:n(*-*Xj}$*6+,2X2422&2Y22(1#Mq9	-%D9j.?"167h%-3'F2n7B3Bv(7-3H6|#1*&2Q2@<5@SY=+>i>?P'Wx,&4$2Y,5aDQ;;C<RE8LI[,4-j5@H*9I],W6fBR"3VCm9M_9;F/JL84>2D9w.3AVEs1;!'"I6l7/%"1H7z(.$
! 0/&`?,'!*>&i2BB4`=:TAc*)*.4Y611"@c0|1B$"?G@Y+"+N-z(9,&2S:%#%=1$o9W/&%V1|MO?L&/$,&5/\)2'4*._99<5V*.9 8/;hC5*&(Q;z3;/&0V8I+
! o6';5
! 5@4v%&'/ 3P7:R@JA.)4&6[01c8yHHd{64C#I>m?'+B@%('$(Max
($+),Vv%377Q*220cJ<.#Hl!HOEFG88
<F-)-".P0-.)
7U"b8'4:A|=+0B_ q,""*M*eDM#CU"k!@FZ804.5(<^E.n	/	0	H	)
! 39
! .m
! 
! *
! :
! <!:^2H;Q+o--
;
A
 N
o
!
"

%
!$-,RC90..!]"0-=5*s?@AaG}:7B81{((2(2&[***3C7;{+;F%f7'Op<WKAQ^R1E1w)5'%HM'+*/:E&+<*-G8u"!/$#4HG}.
! 0'A&iE)/0/E/u:9/5J**6H
 (V / = > M,!cz!%!%"X*""""("1"#O*#z##!#?#:$3A$/u$5$@$K%Kh%1%-%3&H&&Z&%&&&'&3&=*'$h'*'Y'0(GC("(6(7(:).X)))7)7)9!*C[*A*E*A'+Ai+C+@+0,5J,6,*,!,4-E9-@-9-C->.^.u.:.,./.!/;?/#{/&/+/./!0;0"Z0.}000001101F1\1r11111112"282N2d2z22222223+3A3W3m333333342"4U4h4&4!434;4&:5#a5555;58
! 6:C6/~616$6$7*7#F7*j7#7787 8B38v8%8+8,8#9.99-h9A929*:#6:)Z:6:`: ;=;Z;l;*;;););)<)E<)o<)<)<)<)=)A=)k="=*=&=%
! > 0>"Q>t>>>>">	?(?G?f?'?'?,?8@6;@"r@1@@@%A))A)SA2}A@AA$B34BhBDBB'BECORC.C+C1C*/D+ZD#D.D"D<D(9E:bE?EEQE"OFarFHF3G.QG9G;G2G7)H7aH5HCHQIWeI)I*IDJ3WJ-J J0JHKVTK$KKK.K%(L$NL$sL'L$L+L-M/?M-oM%M?M4N/8N/hN2N&NN$
! OH/O7xO.O"OP#P$5PZP9tPP(P'P)Q>Q>PQ"QQHQ2RVDR,R)R5R)(SRSpS'SS&SS&T+AT)mT4T<T'	U$1UVU"bU4U4U@U-0V-^VIV;V[WLnWHW<XHAX+X4X9X/%Y3UY1YY#YAY19ZkZ(Z1Z.Z/[E[X[s[[[4[[)\"0\S\`\
r\5\\(\\(]0>]"o]T])]^3-^-a^,^^*^/_91_"k__U`$g` `8`U`;cYc8Wdd*d0d3d,2e5_e"e e?ef8f@Qf[fBf51g,gg9g<g-h59h7oh2hhHh4Ci%xi8i2i-
! j@8j.yj,j9j9k#Ik-mk8k:k7l>Gl6l.l-l+m;Fm=m8mEm*?n8jn1n<n4o(Go#po:o	oo7o)-pIWp&p6pFpOFqOq<q7#r-[rr%rr@rA%s=gs%s"s0sMtAmt(tEt5uNTuuHu9v.Ev8tv2v$v.w4wHw!eww%w*w1w;)xex*xx,x5x(2y6[y;yy/y&z!Az@cz2zMzM%{.s{b{@|2F|%y|6|X|L/}U|}U}U(~T~~U~T)B~D<GCNNڀH)	r|@Ɂ7܁9MN35Ђ3C:4~6<+'+S(**ӄ	&-B'p'߅
<
5JL]U?7!͇<>,7k87܈89M+-#H40}+$ڊ " MC̋20Q:/܌E3R#IB*OMzHȎZ,l,#Ə(2=F/#ؐ-GC66‘8I22|1$$%;a/|7?D$Bi-.ڔE	O@ҕW)k)4%/.J y
! 4ė6<02m8٘+3%'Y/Gϙ*1)\-+F?'>gF-<$X-}.ڜ<#1+U77("3=-q ;۞"7:.rE;C#*g-:;77;o=,62MG+Ȣ,!?Y-s_)+J%h7%Ƥ5+".N@}HFPN6>֦45J>554+B`BLF3FzFEENaaXp$84##*G%r-&Ƭ#,>5^+< *;fA5M-GPGJ56Ȱ66H[mɱܱ';Ugxʲ޲57L0"Pس4)4^44ȴ4*2C]TIt@/D*8920(c4.G?WV0!.A$pBXغ@1r'#/ٻ 	$*9O)2ѼA1F.x7:߽3.N1}))پ5P9OIڿH$Ym%;0)ZSvA17>:vZ/-<9j77&,+ST3+$5P9NN&^4!9#:AY'- $-70e'3#%I$f)5<-[IK;_5#&'Em<:5-N!|Ld	Kn-:>#Ob"1;;C34N674nA.3:H!3(47AV')=!(@J/*+'F:GU!BA4M,7(d8-!C;)&B02c-p(!*	+4A`$ :0C6t*$!5!W,y!+-"Bew	kcIPvo &
  XLv+;	rmWh			8}JKyx	7X	d	u{&j#%}	qL{	 n
  o%l	
  XJQ
--- 30,74 ----
  X8XEX dX$X#X.XXY-3YaYwY/YCY5Y"0Z/SZ+Z3Z"Z&['-[(U[~[2[&[#["\(6\"_\5\'\+\3]4@]u]*]-]0]'^4C^,x^'^&^(^9_4W_(_E_)_1%`&W`:~`*`!`a/"aRaYa5oa,a<ab3,b7`b1b4b:b5:c)pccccAc@)d9jd&dd%d6
e3De!xeDe/e=f!Mf3of<ff)g+*g%Vg%|ggggg%h(7h-`h6hh(hi$+i+Pi"|i-i,ii'j!?jaj1}j7jLjL4k*kJkBk.:l il.lOlB	mKLmJmKmK/nJ{nKn5o7Ho9o9oDoD9p@~p	pp<pq-%q.SqBq(q)q1r<Jr/r/r7r)s(Isrs's's	sst."tQt"nttt
t7t.u@u>VuNuMu32vfv6v<v5v70w-hw+w-w*w1xMx`x}xJx%x&y&2y YyzyAyyyz$z9zXzuz,zz2z${98{-r{{{D{=|#O|Cs|<|I|%>}'d} }$}-}4~+5~a~~~!~7~10K)|9$# )J!Z"|*&5:E=/-<Y8B&^$3ރ++("Tw
  	)+Ȅ8'-4U$(ʅ"/F!]*),)=:5x4))
-7"e*+߈-'#)K&u5'҉-(En9!݊'''9O3;/2)3\3/Č33(\)|$@ˍ$!1Sl(Z+"Fi8$ԏ.(((Q4z97=!/_4.đ.4".W.,999V:9˓:9@9zWWd!y.-$.<(k1'Ɩ+:-Z(<()Rk6/)%Y7G@$@@e@$:Navțޛ"6IZtȜۜ93-%a(F++#+O+{,,Ԟ4X6Alџ5>;t192k<2  2A(tE3F'^*!ϣ6R(/{ (("G*j)ȥ7&*#Q/u88ަ.3F-z&'ϧFC>=8OI0d/ũD۩1 ,R08H(2$[/50"*'MuF(Ӭ)/&6VAEϭ 46k4ݮ/#!Ce')ů!"$&G n/ܰ41$f6<.3'b%Ҳ+9G4.)*>?P~9ϴ#	.-2\;˵&1	0;'l-G¶/
  .:4i&+ŷ0"+: f/1Ҹ!,&<S0!# D=dCD+6K7B,/'\6+!50#f Aʽ(	5'?&g*ʾ*8 "Y|<25%)[%"  
! -+"Y!|%% :Wo<->1l%.:%1H%],NQJQIEaD(UmD W)1(" "-C-q6##*&Cj"/HB^)VQ"Rtc8+WdaiA))7.*f4VS/q7L(&&O7vYx,6dOJ--2+)0U _:*B:m+F$3@2t/25
! P@A2<F29F*76b'?;<=$z!P4`G61,=>#|0@-J@=7.?0Hp,nAU3F71J8|0/?,V@">-&2TX4#2EVMF-d G).%RT9XHV)@0
! /;kY34M%g#A>(R.{!''I%f !-?= Wxp76Q*4L-57cK@:(c+{/#;B71z.24$Y0y,!/8)/bU?7(5`0O;]SZT_ay7;6s*'&/3V+AL&d2-('4=r%/.!3&U'|!19Qp5.#*BNA2#&4J-'!&/@p<'%%@CGPY#w'T*DC,/)-%(S%|&%%"&8'_#!+
19k%'.9%-_&':#=;Dy:8!2-T;! "'$9L*JG D	)e		-		+	&
! V2
! 
! 2
! )
! &.*"YA|(#!9["j#)
! 
! 
! ,+

! K

! V

! a

! l

! w
&
!


! 


! 

! 
! 
! !$
! FQ@U+`.;8)#,M/z,.A+H.t537,<d4<E/-u6H6#)Z.?(5-^G-/?2BrUp/|NZEV<'';)Le:@+.%Z/+O:,6g76?
AM:=>3G={2CE0:vH50D$W|DP6E :| & $ 6!@:!H{!H!G
"U"at"6"&
#:4#o#a#<#?-$^m$1$+$E*%Ep%%4%T&8X&J&&&$'B('Ik'J';(<([(r(A(;(6)C))`)
! ))6)2)@*#O*Is*G*@+BF+1+;+#+7,"S,Sv,@,4-G@-L-1->.=F.'.1.C.8"/"[/?~/</B/6>0Uu050v1lx121G2L`22H2!353FR373>3T4/e44D4C4<<5%y5)5+5s5Bi6X6W7s]7H7[87v8/8:8N9h9,9'9D9::G::+;$>;c;-;&;0;(<1<Q<"q<4<-<#<"=.>=1m=$=4="=*>DG>=><>=?*E?Lp?D?L@CO@F@>@AAF[AEAPAG9BCB/B-B*#C:NC*C2C*C.D.AD]pD1DE E24E0gE0E<E;FRBFBFFhF(_GAGGGSHTHeH#vH/H6HII,KI4xI-I!I%I)#J/MJ}JJ#JJJK")KLK$lK0K)K-KL8/L"hL-LLLL LM#M6M*OM"zM
M#MMM5N';N6cN"N9N9N81O&jOUO"O7
! P3BPNvP6P>P;;Q=wQ3Q:Q)$R>NRcRMRF?SMS.S6TE:TT$Uh5UjU	V?V+ZV,V/V;VAWQaW]WKX;]X,XUX6YASY8Y4Y+Z&/ZGVZ+ZZJZ.4[Ac[+[5[\B'\Kj\?\.\C%]Ci]*]1]C
! ^N^.m^^;^U^*K_>v_M_.`-2`*``K`K`R#aOva/a;a12b;db"b*b9b9(c'bcMc;c&dT;dOd8dee=RfLfIfI'g.qg2g$g(g#!hEh2h%iY8i%i3i"i/jB?j0j1j.j8k!Mkokk3k9k3lK;l5l3lAl13mGemGmGm6=n!tn&nKn_	oio0o,oho7LpBpKpDq(Xq%q0q/q=r-Fr3tr r.rr,s%Dsjs$s?s,s+t*Bt.mt?t>t?u>[u9u3u6vD?vAv9vwOw<mwAw7w:$xN_xNx,x!*y<Ly,y1y1y0zJKz*z+zNz<{\{/|{/{={2|3M|H|7|.}.1} `}L}%}}2~8A~z~8~~(~REkNA4B*w0Ӏ'B!]0UŁ4Pg|@3ڂP"_97%;.V<=„?3@8tB+;=X<Cӆ	!=9.w$.ˇICD=.>WR::E 2fIV/:Bj)P׋;(Cd68ߌJ7#Y4T5XfLJC]ۏS9Y%.
7<t%&4ޑ=Q&p'#(a(nJ7K,Cx2;"+N0Z06ԕ++7/c/HÖ:IGKDݗi"4513I0}p'!G>i;8$4B6w01ߛ5/GJwEœ0,9Bf/(ٝ4'78_,,Ş-. (O%x'*ƟB04-e0)Ġ/*-I(w*6ˡ((+"T*w"BŢ?'HpG|Yģ=0\$/+&45%j+*mUH3"|1Dѧ[6[*%4?!t81ϩ7397m-2Ӫ"#F2X7ë35+Lx-4ĬMMG#8;. ۮ/=';e==߯1=O4)°'f2{ܱ{knfڲLA4ó1ܳ)'8;`30д)#+=O?2͵G5H8~432 9S93Ƿ%"!+D
p4~+'߸O=W/(Ź"-=?=}AY%W}2-?+*<:g6/ټD	9N:KýGWv&#(߾(
! E2P'W$%(&Nu5%bWIVB;7MZ+'44:i(*-%Sex$*6+'2S2422!2T22(1#Hl9	-%?9e.?"117c%-3
'A2i7B.Bq(7-3C6w#1*!2L2@<0@NY	=&>d>?P"Ws,&42T,5aDL;;C	<ME8L	IV,4-j0@H%9D]~,W	6aBR".QCh9M_4;F/JG84>2?9r.3AQEn1;!""D6g7/%1C7u(.$0*&[?,'!*9&d2BB4[=:T	A^*)*)4T611	";^0w1B$?B@Y++I-u(9,!2N:%#%=,$j9W/!%Q1wMO?G&/$,&0/W)2'4%.Z99<5Q*.98*;cC5*!(L;u3;/!0Q8I+o1';55;4q%&'/3K7:R@EA.)4!6V01c8tHH_v64C#D>h?'+B;%~('$#H\s
($+)'Qq%377L*22+^{J<.#Cg!HOEAG88<A-~)-.K0z-.)2P"]8"/:<w=+0=Z l,""%H*`DM>P"f!@FZ304.5#<YE.n	/z	0	H	$
! 34
! .h
! 
! *
! :
! <:Y2H;L+j--
;
<
 I
j
!
"

%
!$(,MCz90.)!X"z0-=0*n?@A\Gx:7B31v((2(-&V*}**3C2;v+;F%a7'Op7WKAL^R1@1r)5' HH'+*/:@&{+<%-B8p"!/$4CGx.
! 0'<&dE)/+/@/p:9/5E*{*6H (Q /z = > M'!cu!%!%!X%""~""("1"#O%#u##!#?#:$3<$/p$5$@$K%Kc%1%-%3&C&&U&%|&&&'&3&=%'$c'*'Y'0
(G>("(6(7(:).S)))7)7)9*CV*A*E*A"+Ad+C+@++,5E,6{,*,!,4,E4-@z-9-C-9.Y.p.:.,./.!/;:/#v/&/+/./060"U0.x0000001+1A1W1m11111112232I2_2u22222223&3<3R3h3~333333424P4c4&|4!434;4&55#\5555;586:>6/y616$6$7%7#A7*e7#7787 
8B.8q8%8+8,8#9.49-c9A929*:#1:)U:6:`: ;8;U;g;*z;;););)<)@<)j<)<)<)<)=)<=)f="=*=&=%> +>"L>o>>>>">?#?B?a?'?'?,?8?66@"m@1@@@%@)$A)NA2xA@AA$
! B3/BcBDBB'BECOMC.C+C1C**D+UD#D.D"D<D(4E:]E?EEQE"JFamFHF3G.LG9{G;G2G7$H7\H5HCHQIW`I)I*ID
J3RJ-J J0JHKVOK$KKK.K%#L$IL$nL'L$L+L-M/:M-jM%M?M4M/3N/cN2N&NN$OH*O7sO.O"OO#P$0PUP9oPP(P'P)Q9Q>KQ"QQHQ2RV?R,R)R5R)#SMSkS'SS&SS&T+cYc8Rdd*d0d3d,-e5Ze"e e?ef3f@Lf[fBf5,g,bg9g<g-h54h7jh2hhHh4>i%si8i2i-j@3j.tj,j9j9
! k#Dk-hk8k:k7
! l>Bl6l.l-l+m;Am=}m8mEm*:n8en1n<n4
o(Bo#ko:o	oo7o)(pIRp&p6pFpOAqOq<q7r-Vrr%rr@rA s=bs%s"s0sMtAht(tEt5uNOuuHu9v.@v8ov2v$v.w/wCw!`ww%w*w1w;$x`x*xx,x5x(-y6Vy;yy/y&z!NNՀH$	mw@ā7ׁ9MI35˂3C54y6<+"+N(z**΄	!-='k'څ
<5E{L]܆U:7!ȇ<>'7f87׈89H+-܉#H/0x+$Պ "M>Nj܋-0L}:/׌E3M#IB*JMuHÎZ,g,#(2=A/#Ӑ-G>668I-2w1$ܒ$%6\/w7?ߓDBd-.ՔEJ@͕W)f)4%/.E t
! 46<+2h8Ԙ+3 'T/|Gʙ*,)W-+Fۚ?">bF-<$S-x.՜<#,+P7|7("38-l ;֞"75.mE;C*b-:;72;j=,62HG{+â,:T-n_)&E%c7%5+.I@xHFPI6>Ѧ45E>{554&B[BLF.FuFEEIaaSk$84#*B%m-&#,95Y+< *6azA5H-~GPGE56ð61CVh|ıױ"6PbsŲٲ57G0"Pӳ4$4Y44ô4*-CXTIt;/D%892+(^4.۸G
! ?RV0!.<$kBXӺ@,m'#/Ի $%9J)2̼A1A.s7:ڽ3.I1x))Ծ5P4OIտHYh%;0$USqA179:qZ/-79e77&'+NzT3+5K9NN
! &Y4!9#5AT'- $
-20`'3# D$a)5<-VIK;Z5#&'@h~<:5-I!wLdKi-:>O]"1;;>3z4N624iA.3:C!~3(42AQ')=!#@E/*+'
F5G|U!B<4M,2(_8-!C6)z&B0-^-k(!*+/A[$ :0>6o*$!0!R,t!+-"=`r	kcIPvo &
  XLv+;	rmWh			8}JKyx	7X	d	u{&j#%}	qL{	 n
  o%l	
  XJQ
*************** Last-Translator: Arif E. Nugroho 
  Language: id
  MIME-Version: 1.0
! Content-Type: text/plain; charset=ISO-8859-1
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  
--- 402,408 ----
  Language-Team: Indonesian 
  Language: id
  MIME-Version: 1.0
! Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  
diff -Nrcpad gcc-13.4.0/gcc/pointer-query.cc gcc-13.5.0-RC-20260904/gcc/pointer-query.cc
*** gcc-13.4.0/gcc/pointer-query.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/pointer-query.cc	Fri Sep  4 07:35:08 2026
*************** get_offset_range (tree x, gimple *stmt,
*** 74,80 ****
      x = TREE_OPERAND (x, 0);
  
    tree type = TREE_TYPE (x);
!   if (!INTEGRAL_TYPE_P (type) && !POINTER_TYPE_P (type))
      return false;
  
     if (TREE_CODE (x) != INTEGER_CST
--- 74,85 ----
      x = TREE_OPERAND (x, 0);
  
    tree type = TREE_TYPE (x);
!   if ((!INTEGRAL_TYPE_P (type)
!        /* ???  We get along without caring about overflow by using
! 	  offset_int, but that falls apart when indexes are bigger
! 	  than pointer differences.  */
!        || TYPE_PRECISION (type) > TYPE_PRECISION (ptrdiff_type_node))
!       && !POINTER_TYPE_P (type))
      return false;
  
     if (TREE_CODE (x) != INTEGER_CST
diff -Nrcpad gcc-13.4.0/gcc/postreload.cc gcc-13.5.0-RC-20260904/gcc/postreload.cc
*** gcc-13.4.0/gcc/postreload.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/postreload.cc	Fri Sep  4 07:35:08 2026
*************** move2add_use_add3_insn (scalar_int_mode
*** 1894,1899 ****
--- 1894,1972 ----
    return changed;
  }
  
+ /* Perform any invalidations necessary for INSN.  */
+ 
+ static void
+ reload_cse_move2add_invalidate (rtx_insn *insn)
+ {
+   for (rtx note = REG_NOTES (insn); note; note = XEXP (note, 1))
+     {
+       if (REG_NOTE_KIND (note) == REG_INC
+ 	  && REG_P (XEXP (note, 0)))
+ 	{
+ 	  /* Reset the information about this register.  */
+ 	  int regno = REGNO (XEXP (note, 0));
+ 	  if (regno < FIRST_PSEUDO_REGISTER)
+ 	    {
+ 	      move2add_record_mode (XEXP (note, 0));
+ 	      reg_mode[regno] = VOIDmode;
+ 	    }
+ 	}
+     }
+ 
+   /* There are no REG_INC notes for SP autoinc.  */
+   subrtx_var_iterator::array_type array;
+   FOR_EACH_SUBRTX_VAR (iter, array, PATTERN (insn), NONCONST)
+     {
+       rtx mem = *iter;
+       if (mem
+ 	  && MEM_P (mem)
+ 	  && GET_RTX_CLASS (GET_CODE (XEXP (mem, 0))) == RTX_AUTOINC)
+ 	{
+ 	  if (XEXP (XEXP (mem, 0), 0) == stack_pointer_rtx)
+ 	    reg_mode[STACK_POINTER_REGNUM] = VOIDmode;
+ 	}
+     }
+ 
+   note_stores (insn, move2add_note_store, insn);
+ 
+   /* If INSN is a conditional branch, we try to extract an
+      implicit set out of it.  */
+   if (any_condjump_p (insn))
+     {
+       rtx cnd = fis_get_condition (insn);
+ 
+       if (cnd != NULL_RTX
+ 	  && GET_CODE (cnd) == NE
+ 	  && REG_P (XEXP (cnd, 0))
+ 	  && !reg_set_p (XEXP (cnd, 0), insn)
+ 	  /* The following two checks, which are also in
+ 	     move2add_note_store, are intended to reduce the
+ 	     number of calls to gen_rtx_SET to avoid memory
+ 	     allocation if possible.  */
+ 	  && SCALAR_INT_MODE_P (GET_MODE (XEXP (cnd, 0)))
+ 	  && REG_NREGS (XEXP (cnd, 0)) == 1
+ 	  && CONST_INT_P (XEXP (cnd, 1)))
+ 	{
+ 	  rtx implicit_set = gen_rtx_SET (XEXP (cnd, 0), XEXP (cnd, 1));
+ 	  move2add_note_store (SET_DEST (implicit_set), implicit_set, insn);
+ 	}
+     }
+ 
+   /* If this is a CALL_INSN, all call used registers are stored with
+      unknown values.  */
+   if (CALL_P (insn))
+     {
+       function_abi callee_abi = insn_callee_abi (insn);
+       for (int i = FIRST_PSEUDO_REGISTER - 1; i >= 0; i--)
+ 	if (reg_mode[i] != VOIDmode
+ 	    && reg_mode[i] != BLKmode
+ 	    && callee_abi.clobbers_reg_p (reg_mode[i], i))
+ 	    /* Reset the information about this register.  */
+ 	  reg_mode[i] = VOIDmode;
+     }
+ }
+ 
  /* Convert move insns with constant inputs to additions if they are cheaper.
     Return true if any changes were made.  */
  static bool
*************** reload_cse_move2add (rtx_insn *first)
*** 1916,1922 ****
    move2add_luid = 2;
    for (insn = first; insn; insn = NEXT_INSN (insn), move2add_luid++)
      {
!       rtx pat, note;
  
        if (LABEL_P (insn))
  	{
--- 1989,1995 ----
    move2add_luid = 2;
    for (insn = first; insn; insn = NEXT_INSN (insn), move2add_luid++)
      {
!       rtx pat;
  
        if (LABEL_P (insn))
  	{
*************** reload_cse_move2add (rtx_insn *first)
*** 2034,2039 ****
--- 2107,2118 ----
  			delete_insn (insn);
  		      changed |= success;
  		      insn = next;
+ 		      /* Make sure to perform any invalidations related to
+ 			 NEXT/INSN since we're going to bypass the normal
+ 			 flow with the continue below.
+ 
+ 			 Do this before recording the new mode/offset.  */
+ 		      reload_cse_move2add_invalidate (insn);
  		      move2add_record_mode (reg);
  		      reg_offset[regno]
  			= trunc_int_for_mode (added_offset + base_offset,
*************** reload_cse_move2add (rtx_insn *first)
*** 2087,2160 ****
  	      continue;
  	    }
  	}
! 
!       for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
! 	{
! 	  if (REG_NOTE_KIND (note) == REG_INC
! 	      && REG_P (XEXP (note, 0)))
! 	    {
! 	      /* Reset the information about this register.  */
! 	      int regno = REGNO (XEXP (note, 0));
! 	      if (regno < FIRST_PSEUDO_REGISTER)
! 		{
! 		  move2add_record_mode (XEXP (note, 0));
! 		  reg_mode[regno] = VOIDmode;
! 		}
! 	    }
! 	}
! 
!       /* There are no REG_INC notes for SP autoinc.  */
!       subrtx_var_iterator::array_type array;
!       FOR_EACH_SUBRTX_VAR (iter, array, PATTERN (insn), NONCONST)
! 	{
! 	  rtx mem = *iter;
! 	  if (mem
! 	      && MEM_P (mem)
! 	      && GET_RTX_CLASS (GET_CODE (XEXP (mem, 0))) == RTX_AUTOINC)
! 	    {
! 	      if (XEXP (XEXP (mem, 0), 0) == stack_pointer_rtx)
! 		reg_mode[STACK_POINTER_REGNUM] = VOIDmode;
! 	    }
! 	}
! 
!       note_stores (insn, move2add_note_store, insn);
! 
!       /* If INSN is a conditional branch, we try to extract an
! 	 implicit set out of it.  */
!       if (any_condjump_p (insn))
! 	{
! 	  rtx cnd = fis_get_condition (insn);
! 
! 	  if (cnd != NULL_RTX
! 	      && GET_CODE (cnd) == NE
! 	      && REG_P (XEXP (cnd, 0))
! 	      && !reg_set_p (XEXP (cnd, 0), insn)
! 	      /* The following two checks, which are also in
! 		 move2add_note_store, are intended to reduce the
! 		 number of calls to gen_rtx_SET to avoid memory
! 		 allocation if possible.  */
! 	      && SCALAR_INT_MODE_P (GET_MODE (XEXP (cnd, 0)))
! 	      && REG_NREGS (XEXP (cnd, 0)) == 1
! 	      && CONST_INT_P (XEXP (cnd, 1)))
! 	    {
! 	      rtx implicit_set =
! 		gen_rtx_SET (XEXP (cnd, 0), XEXP (cnd, 1));
! 	      move2add_note_store (SET_DEST (implicit_set), implicit_set, insn);
! 	    }
! 	}
! 
!       /* If this is a CALL_INSN, all call used registers are stored with
! 	 unknown values.  */
!       if (CALL_P (insn))
! 	{
! 	  function_abi callee_abi = insn_callee_abi (insn);
! 	  for (i = FIRST_PSEUDO_REGISTER - 1; i >= 0; i--)
! 	    if (reg_mode[i] != VOIDmode
! 		&& reg_mode[i] != BLKmode
! 		&& callee_abi.clobbers_reg_p (reg_mode[i], i))
! 	      /* Reset the information about this register.  */
! 	      reg_mode[i] = VOIDmode;
! 	}
      }
    return changed;
  }
--- 2166,2172 ----
  	      continue;
  	    }
  	}
!       reload_cse_move2add_invalidate (insn);
      }
    return changed;
  }
diff -Nrcpad gcc-13.4.0/gcc/range-op-float.cc gcc-13.5.0-RC-20260904/gcc/range-op-float.cc
*** gcc-13.4.0/gcc/range-op-float.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/range-op-float.cc	Fri Sep  4 07:35:08 2026
*************** float_widen_lhs_range (tree type, const
*** 2341,2347 ****
      return ret;
    REAL_VALUE_TYPE lb = lhs.lower_bound ();
    REAL_VALUE_TYPE ub = lhs.upper_bound ();
!   if (real_isfinite (&lb))
      {
        frange_nextafter (TYPE_MODE (type), lb, dconstninf);
        if (real_isinf (&lb))
--- 2341,2347 ----
      return ret;
    REAL_VALUE_TYPE lb = lhs.lower_bound ();
    REAL_VALUE_TYPE ub = lhs.upper_bound ();
!   if (real_isfinite (&lb) || !real_isneg (&lb))
      {
        frange_nextafter (TYPE_MODE (type), lb, dconstninf);
        if (real_isinf (&lb))
*************** float_widen_lhs_range (tree type, const
*** 2355,2361 ****
  	  lb = dconstm1;
  	  SET_REAL_EXP (&lb, FLOAT_MODE_FORMAT (TYPE_MODE (type))->emax + 1);
  	}
!       if (!flag_rounding_math && !MODE_COMPOSITE_P (TYPE_MODE (type)))
  	{
  	  /* If not -frounding-math nor IBM double double, actually widen
  	     just by 0.5ulp rather than 1ulp.  */
--- 2355,2363 ----
  	  lb = dconstm1;
  	  SET_REAL_EXP (&lb, FLOAT_MODE_FORMAT (TYPE_MODE (type))->emax + 1);
  	}
!       if (!flag_rounding_math
! 	  && !MODE_COMPOSITE_P (TYPE_MODE (type))
! 	  && real_isfinite (&lhs.lower_bound ()))
  	{
  	  /* If not -frounding-math nor IBM double double, actually widen
  	     just by 0.5ulp rather than 1ulp.  */
*************** float_widen_lhs_range (tree type, const
*** 2364,2370 ****
  	  real_arithmetic (&lb, RDIV_EXPR, &tem, &dconst2);
  	}
      }
!   if (real_isfinite (&ub))
      {
        frange_nextafter (TYPE_MODE (type), ub, dconstinf);
        if (real_isinf (&ub))
--- 2366,2372 ----
  	  real_arithmetic (&lb, RDIV_EXPR, &tem, &dconst2);
  	}
      }
!   if (real_isfinite (&ub) || real_isneg (&ub))
      {
        frange_nextafter (TYPE_MODE (type), ub, dconstinf);
        if (real_isinf (&ub))
*************** float_widen_lhs_range (tree type, const
*** 2373,2379 ****
  	  ub = dconst1;
  	  SET_REAL_EXP (&ub, FLOAT_MODE_FORMAT (TYPE_MODE (type))->emax + 1);
  	}
!       if (!flag_rounding_math && !MODE_COMPOSITE_P (TYPE_MODE (type)))
  	{
  	  /* If not -frounding-math nor IBM double double, actually widen
  	     just by 0.5ulp rather than 1ulp.  */
--- 2375,2383 ----
  	  ub = dconst1;
  	  SET_REAL_EXP (&ub, FLOAT_MODE_FORMAT (TYPE_MODE (type))->emax + 1);
  	}
!       if (!flag_rounding_math
! 	  && !MODE_COMPOSITE_P (TYPE_MODE (type))
! 	  && real_isfinite (&lhs.upper_bound ()))
  	{
  	  /* If not -frounding-math nor IBM double double, actually widen
  	     just by 0.5ulp rather than 1ulp.  */
diff -Nrcpad gcc-13.4.0/gcc/stmt.cc gcc-13.5.0-RC-20260904/gcc/stmt.cc
*** gcc-13.4.0/gcc/stmt.cc	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/stmt.cc	Fri Sep  4 07:35:08 2026
*************** parse_input_constraint (const char **con
*** 332,337 ****
--- 332,338 ----
  
    /* Make sure constraint has neither `=', `+', nor '&'.  */
  
+ repeat:
    for (j = 0; j < c_len; j += CONSTRAINT_LEN (constraint[j], constraint+j))
      switch (constraint[j])
        {
*************** parse_input_constraint (const char **con
*** 389,400 ****
  	      constraint = constraints[match];
  	      *constraint_p = constraint;
  	      c_len = strlen (constraint);
! 	      j = 0;
! 	      /* ??? At the end of the loop, we will skip the first part of
! 		 the matched constraint.  This assumes not only that the
! 		 other constraint is an output constraint, but also that
! 		 the '=' or '+' come first.  */
! 	      break;
  	    }
  	  else
  	    j = end - constraint;
--- 390,396 ----
  	      constraint = constraints[match];
  	      *constraint_p = constraint;
  	      c_len = strlen (constraint);
! 	      goto repeat;
  	    }
  	  else
  	    j = end - constraint;
diff -Nrcpad gcc-13.4.0/gcc/system.h gcc-13.5.0-RC-20260904/gcc/system.h
*** gcc-13.4.0/gcc/system.h	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/system.h	Fri Sep  4 07:35:08 2026
*************** extern int fprintf_unlocked (FILE *, con
*** 222,227 ****
--- 222,236 ----
  #ifdef INCLUDE_FUNCTIONAL
  # include 
  #endif
+ #ifdef INCLUDE_SSTREAM
+ # include 
+ #endif
+ /* Some of the headers included by  can use "abort" within a
+    namespace, e.g. "_VSTD::abort();", which fails after we use the
+    preprocessor to redefine "abort" as "fancy_abort" below.  */
+ #ifdef INCLUDE_MEMORY
+ # include 
+ #endif
  # include 
  # include 
  # include 
*************** extern int vsnprintf (char *, size_t, co
*** 736,757 ****
  #define LIKELY(x) (__builtin_expect ((x), 1))
  #define UNLIKELY(x) (__builtin_expect ((x), 0))
  
- /* Some of the headers included by  can use "abort" within a
-    namespace, e.g. "_VSTD::abort();", which fails after we use the
-    preprocessor to redefine "abort" as "fancy_abort" below.  */
- 
- #ifdef INCLUDE_MEMORY
- # include 
- #endif
- 
  #ifdef INCLUDE_MUTEX
  # include 
  #endif
  
- #ifdef INCLUDE_SSTREAM
- # include 
- #endif
- 
  #ifdef INCLUDE_MALLOC_H
  #if defined(HAVE_MALLINFO) || defined(HAVE_MALLINFO2)
  #include 
--- 745,754 ----
diff -Nrcpad gcc-13.4.0/gcc/testsuite/ChangeLog gcc-13.5.0-RC-20260904/gcc/testsuite/ChangeLog
*** gcc-13.4.0/gcc/testsuite/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/ChangeLog	Fri Sep  4 07:35:08 2026
***************
*** 1,3 ****
--- 1,1804 ----
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-08-14  Patrick Palka  
+ 
+ 	PR c++/126483
+ 	* g++.dg/cpp2a/is-constant-evaluated16.C: New test.
+ 
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-07-25  Patrick Palka  
+ 
+ 	PR c++/126280
+ 	* g++.dg/template/fn-ptr6.C: New test.
+ 
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-04-07  Patrick Palka  
+ 
+ 	PR c++/123529
+ 	PR c++/98930
+ 	* g++.dg/cpp1z/nontype9.C: New test.
+ 
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-02-17  Patrick Palka  
+ 
+ 	PR c++/121822
+ 	* g++.dg/cpp2a/concepts-decltype6.C: New test.
+ 
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2025-09-20  Patrick Palka  
+ 
+ 	PR c++/121981
+ 	* g++.dg/cpp2a/concepts-placeholder15.C: New test.
+ 
+ 2026-09-03  Francois-Xavier Coudert  
+ 
+ 	Backported from master:
+ 	2025-07-14  François-Xavier Coudert  
+ 
+ 	* gcc.dg/darwin-minversion-link.c: Account for macOS 26.
+ 
+ 2026-08-29  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2026-08-29  Georg-Johann Lay  
+ 
+ 	PR middle-end/127098
+ 	* gcc.target/avr/torture/pr127098.c: New test.
+ 
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-06  Jakub Jelinek  
+ 
+ 	PR preprocessor/125048
+ 	* c-c++-common/cpp/va-opt-11.c: New test.
+ 
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-04  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126464
+ 	* gcc.dg/pr126464.c: Guard uses of 1e300 with
+ 	__DBL_MAX_10_EXP__ >= 301 and uses of 1e4000L with
+ 	__LDBL_MAX_10_EXP__ >= 4001.
+ 
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-04  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126601
+ 	* gcc.dg/tree-ssa/pr126601.c: New test.
+ 
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-04  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126564
+ 	* gcc.dg/torture/pr126564.c: New test.
+ 
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-03  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126547
+ 	* gcc.dg/torture/pr126547.c: New test.
+ 
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-03  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126576
+ 	* gcc.dg/torture/pr126576.c: New test.
+ 
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-03  Jakub Jelinek  
+ 
+ 	PR target/126484
+ 	* g++.target/mips/pr126484.C: New test.
+ 
+ 2026-08-20  Marek Polacek  
+ 
+ 	Backported from master:
+ 	2025-03-07  Marek Polacek  
+ 
+ 	PR c++/118775
+ 	* g++.dg/cpp2a/constexpr-new24.C: New test.
+ 	* g++.dg/cpp2a/constexpr-new25.C: New test.
+ 
+ 2026-08-20  Marek Polacek  
+ 
+ 	PR c++/116379
+ 	* g++.dg/cpp1y/decltype-auto9.C: New test.
+ 
+ 2026-08-20  Marek Polacek  
+ 
+ 	Backported from master:
+ 	2025-05-14  Marek Polacek  
+ 
+ 	PR c++/116960
+ 	PR c++/119303
+ 	* g++.dg/cpp2a/lambda-uneval26.C: New test.
+ 	* g++.dg/warn/undefined2.C: New test.
+ 
+ 2026-08-19  Alice Carlotti  
+ 
+ 	PR target/124629
+ 	* gcc.target/aarch64/cpunative/info_36: New test file.
+ 	* gcc.target/aarch64/cpunative/native_cpu_36.c: New test.
+ 
+ 2026-08-14  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-02-17  Richard Biener  
+ 
+ 	PR tree-optimization/124130
+ 	* g++.dg/torture/pr124130.C: New testcase.
+ 
+ 2026-08-05  Jerry DeLisle  
+ 
+ 	Backported from master:
+ 	2026-07-28  Jerry DeLisle  
+ 
+ 	PR fortran/125866
+ 	* gfortran.dg/pr125866.f90: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-31  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126464
+ 	* gcc.dg/torture/pr126464.c: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-30  Jakub Jelinek  
+ 
+ 	PR tree-optimization/126464
+ 	* gcc.dg/pr126464.c: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-29  Jakub Jelinek  
+ 
+ 	PR target/126446
+ 	* gcc.target/i386/avx2-pr126446.c: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-27  Jakub Jelinek  
+ 
+ 	PR fortran/126303
+ 	* gfortran.dg/pr126303.f: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-14  Jakub Jelinek  
+ 		    H.J. Lu  
+ 
+ 	PR tree-optimization/120201
+ 	* g++.dg/asan/pr120201-1.C: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-05  Jakub Jelinek  
+ 
+ 	* g++.dg/opt/20260703-1.C: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-06-12  Jakub Jelinek  
+ 
+ 	PR c++/125674
+ 	* g++.dg/template/bitfield5.C: New test.
+ 	* g++.dg/template/bitfield6.C: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-06-06  Jakub Jelinek  
+ 
+ 	PR target/125611
+ 	* gcc.target/i386/ssse3-pr125611.c: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-05-01  Jakub Jelinek  
+ 
+ 	PR tree-optimization/125079
+ 	* gcc.dg/strlenopt-97.c: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-04-21  Jakub Jelinek  
+ 
+ 	PR testsuite/124682
+ 	* gcc.dg/torture/builtin-math-6.c (TESTIT_COMPLEX_R2_ISZ): Define.
+ 	(TESTIT_COMPLEX_R2_ALLNEG): Use TESTIT_COMPLEX_R2_ISZ instead of
+ 	TESTIT_COMPLEX_R2.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-04-15  Jakub Jelinek  
+ 
+ 	* go.test/go-test.exp (errchk): Use -translation binary instead of
+ 	-encoding binary for TCL 9 compatibility.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-04-15  Jakub Jelinek  
+ 
+ 	PR c++/124850
+ 	* g++.dg/other/anon-union8.C: New test.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-26  Jakub Jelinek  
+ 
+ 	* lib/mike-gcc.exp (postbase): Use switch instead of case for
+ 	TCL 9 compatibility.
+ 	* lib/mike-g++.exp (postbase): Likewise.
+ 
+ 2026-07-28  Haochen Jiang  
+ 
+ 	Backported from master:
+ 	2026-07-28  Haochen Jiang  
+ 
+ 	PR target/126429
+ 	* gcc.target/i386/pr126429-1.c: New test.
+ 
+ 2026-07-20  Mikael Morin  
+ 
+ 	Backported from master:
+ 	2026-07-03  Mikael Morin  
+ 
+ 	PR fortran/97592
+ 	PR fortran/125998
+ 	* gfortran.dg/contiguous_17.f90: New test.
+ 
+ 2026-07-09  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-09  Christopher Albert  
+ 
+ 	PR fortran/103367
+ 	* gfortran.dg/pr103367.f90: Expect a constant-expression error and
+ 	prune the legacy-extension warning.
+ 
+ 2026-07-09  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-07  Christopher Albert  
+ 
+ 	PR fortran/103367
+ 	* gfortran.dg/pr103367.f90: New test.
+ 
+ 2026-07-09  Jerry DeLisle  
+ 
+ 	Backported from master:
+ 	2026-07-07  Jerry DeLisle  
+ 
+ 	PR fortran/103367
+ 	* gfortran.dg/pr103367_2.f90: New test.
+ 	* gfortran.dg/pr103367_3.f90: New test.
+ 	* gfortran.dg/pr103367_4.f90: New test.
+ 
+ 2026-07-09  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2026-05-12  Martin Jambor  
+ 
+ 	PR tree-optimization/124151
+ 	* gcc.dg/tree-ssa/pr124151.c: New test.
+ 
+ 2026-07-05  Oleg Endo  
+ 
+ 	PR target/67459
+ 	PR target/122948
+ 	* gcc.target/sh/pr122948.c: New test.
+ 
+ 2026-07-03  Stefan Schulze Frielinghaus  
+ 
+ 	PR rtl-optimization/125173
+ 	* gcc.dg/pr125173-1.c: Remove option
+ 	-fno-fuse-ops-with-volatile-access.
+ 
+ 2026-07-01  Stefan Schulze Frielinghaus  
+ 
+ 	Backported from master:
+ 	2026-06-26  Stefan Schulze Frielinghaus  
+ 
+ 	PR target/125972
+ 	* gcc.target/s390/pr125972.c: New test.
+ 
+ 2026-06-30  Stefan Schulze Frielinghaus  
+ 
+ 	Backported from master:
+ 	2026-06-12  Stefan Schulze Frielinghaus  
+ 
+ 	PR rtl-optimization/125173
+ 	* gcc.dg/pr125173-1.c: New test.
+ 
+ 2026-06-29  Alex Coplan  
+ 
+ 	Backported from master:
+ 	2026-06-23  Alex Coplan  
+ 
+ 	PR target/125818
+ 	* gcc.target/aarch64/torture/pr125818.c: New test.
+ 
+ 2026-06-17  Andrew Pinski  
+ 
+ 	* gcc.dg/torture/pr125774-1.c: Start with dom
+ 	rather than dom2.
+ 
+ 2026-06-17  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-06-14  Andrew Pinski  
+ 
+ 	PR tree-optimization/125774
+ 	* gcc.dg/torture/pr125774-1.c: New test.
+ 
+ 2026-06-17  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-05-04  Andrew Pinski  
+ 
+ 	PR c++/65271
+ 	* g++.dg/cpp0x/rv-decl1.C: New test.
+ 
+ 2026-06-17  Alex Coplan  
+ 
+ 	Backported from master:
+ 	2026-06-09  Alex Coplan  
+ 
+ 	PR middle-end/125621
+ 	* gcc.target/aarch64/torture/pr125621.c: New test.
+ 
+ 2026-06-16  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-04-27  Richard Biener  
+ 
+ 	PR tree-optimization/125025
+ 	* gcc.dg/torture/pr125025.c: New testcase.
+ 
+ 2026-06-16  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-04-14  Richard Biener  
+ 
+ 	PR tree-optimization/124868
+ 	* gcc.dg/torture/pr124868.c: New testcase.
+ 
+ 2026-06-16  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-02-17  Richard Biener  
+ 
+ 	PR tree-optimization/124132
+ 	* gcc.dg/torture/pr124132.c: New testcase.
+ 
+ 2026-06-16  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-02-03  Richard Biener  
+ 
+ 	PR ipa/123416
+ 	* gcc.dg/torture/pr123416.c: New testcase.
+ 
+ 2026-06-16  Jan Hubicka  
+ 
+ 	Backported from master:
+ 	2026-03-10  Jan Hubicka  
+ 		    Andrew Pinski  
+ 
+ 	PR tree-optimization/120987
+ 	* g++.dg/torture/pr120987-1.C: New test.
+ 
+ 2026-06-11  Xi Ruoyao  
+ 
+ 	Backported from master:
+ 	2026-05-08  Xi Ruoyao  
+ 
+ 	PR target/125049
+ 	* gcc.target/loongarch/pr125049.c: New test.
+ 
+ 2026-06-10  Richard Biener  
+ 
+ 	PR tree-optimization/111387
+ 	* gcc.dg/torture/pr111387.c: New testcase.
+ 
+ 2026-06-10  Eric Botcazou  
+ 
+ 	* gnat.dg/bigint1.adb: New  test.
+ 
+ 2026-05-27  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2026-04-15  Martin Jambor  
+ 
+ 	PR tree-optimization/122976
+ 	* gcc.dg/tree-ssa/pr122976.c: New test.
+ 
+ 2026-05-25  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2026-05-25  Georg-Johann Lay  
+ 
+ 	PR target/125409
+ 	* gcc.target/avr/torture/pr125409.h: New file.
+ 	* gcc.target/avr/torture/pr125409-fx24-ssk.c: New test.
+ 	* gcc.target/avr/torture/pr125409-fx24-ssr.c: New test.
+ 	* gcc.target/avr/torture/pr125409-fx24-suk.c: New test.
+ 	* gcc.target/avr/torture/pr125409-fx24-sur.c: New test.
+ 	* gcc.target/avr/torture/pr125409-fx24-usk.c: New test.
+ 	* gcc.target/avr/torture/pr125409-fx24-usr.c: New test.
+ 	* gcc.target/avr/torture/pr125409-fx24-uuk.c: New test.
+ 	* gcc.target/avr/torture/pr125409-fx24-uur.c: New test.
+ 
+ 2026-05-21  Thomas Koenig  
+ 
+ 	Backported from master:
+ 	2026-05-20  Thomas Koenig  
+ 
+ 	PR fortran/106546
+ 	* gfortran.dg/inline_matmul_27.f90: New test.
+ 
+ 2026-05-20  Thomas Koenig  
+ 
+ 	Backported from master:
+ 	2026-05-19  Thomas Koenig  
+ 
+ 	PR fortran/115260
+ 	* gfortran.dg/pr115260.f90: New test.
+ 
+ 2026-05-14  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-08  Christopher Albert  
+ 
+ 	PR fortran/96986
+ 	* gfortran.dg/pr96986.f90: New test.
+ 
+ 2026-05-13  Jason Merrill  
+ 
+ 	Backported from master:
+ 	2025-08-21  Jason Merrill  
+ 
+ 	PR c++/120757
+ 	* g++.dg/cpp1y/auto-fn66.C: New test.
+ 
+ 2026-05-13  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-10  Christopher Albert  
+ 
+ 	PR fortran/94978
+ 	* gfortran.dg/pr94978.f90: New test.
+ 
+ 2026-05-13  Paul Thomas  
+ 
+ 	Backported from master:
+ 	2026-03-16  Paul Thomas  
+ 		    Steve Kargl  
+ 
+ 	PR fortran/93832
+ 	* gfortran.dg/pr93832.f90: New test.
+ 
+ 2026-05-13  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-11  Christopher Albert  
+ 
+ 	PR fortran/93814
+ 	* gfortran.dg/pr93814.f90: New test.
+ 
+ 2026-05-13  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-08  Paul Thomas  
+ 
+ 	PR fortran/93715
+ 	* gfortran.dg/pr93715.f90: New test.
+ 
+ 2026-05-09  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-07  Paul Thomas  
+ 
+ 	PR fortran/107425
+ 	* gfortran.dg/gomp/pr107425.f90: New test.
+ 
+ 2026-05-09  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-06  Christopher Albert  
+ 
+ 	PR fortran/79524
+ 	PR fortran/79524
+ 	* gfortran.dg/pr79524.f90: New test.
+ 
+ 2026-05-05  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-05-05  Iain Buclaw  
+ 
+ 	PR d/125089
+ 	* gdc.dg/pr125089.d: New test.
+ 
+ 2026-04-30  Richard Earnshaw  
+ 
+ 	Backported from master:
+ 	2026-04-22  Richard Earnshaw  
+ 
+ 	PR target/124933
+ 	* lib/target-supports.exp (v8_1m_main_fp_hard): New arm
+ 	architecture variant.
+ 	* gcc.target/arm/pr124933.c: New test.
+ 	* gcc.target/arm/armv8_2-fp16-move-1.c: Update expected output.
+ 
+ 2026-04-21  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-03  Christopher Albert  
+ 
+ 	PR fortran/98203
+ 	PR fortran/98203
+ 	* gfortran.dg/gomp/pr98203.f90: New test.
+ 
+ 2026-04-19  Paul Thomas  
+ 
+ 	PR fortran/106946
+ 	* gfortran.dg/pr106946.f90: Removed.
+ 
+ 2026-04-17  Paul Thomas  
+ 
+ 	Backported from master:
+ 	2026-03-27  Paul Thomas  
+ 
+ 	PR fortran/102619
+ 	* gfortran.dg/pr102619.f90: New test.
+ 
+ 2026-04-16  Harald Anlauf  
+ 
+ 	PR fortran/121616
+ 	* gfortran.dg/alloc_comp_assign_17.f90: Removed.
+ 
+ 2026-04-14  Harald Anlauf  
+ 
+ 	Backported from master:
+ 	2025-09-11  Harald Anlauf  
+ 
+ 	PR fortran/121616
+ 	* gfortran.dg/alloc_comp_assign_17.f90: New test.
+ 
+ 2026-04-13  Richard Earnshaw  
+ 
+ 	Backported from master:
+ 	2026-03-11  Richard Earnshaw  
+ 
+ 	PR target/123271
+ 	* gcc.target/arm/pr123271.c: New test.
+ 
+ 2026-04-13  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-03-30  Christopher Albert  
+ 
+ 	* gfortran.dg/goacc/omp-108382.f90: New test.
+ 
+ 2026-04-13  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-13  Christopher Albert  
+ 
+ 	PR fortran/95879
+ 	PR fortran/95879
+ 	* gfortran.dg/pr95879.f90: New test.
+ 
+ 2026-04-09  Richard Biener  
+ 
+ 	Revert:
+ 	2026-04-09  Richard Biener  
+ 
+ 	PR ipa/116296
+ 	* gcc.dg/torture/pr116296.c: New testcase.
+ 
+ 2026-04-09  Xi Ruoyao  
+ 
+ 	Backported from master:
+ 	2026-04-09  Xi Ruoyao  
+ 
+ 	PR target/105192
+ 	* gcc.c-torture/compile/pr105192.c: New test.
+ 
+ 2026-04-08  Christophe Lyon  
+ 
+ 	Backported from master:
+ 	2026-04-02  Christophe Lyon  
+ 
+ 	PR target/124705
+ 	* gcc.dg/tree-ssa/gen-vect-26.c: Disable loop peeling check for
+ 	arm*-*-.
+ 	* gcc.dg/tree-ssa/gen-vect-28.c: Likewise.
+ 
+ 2026-04-08  Torbjörn SVENSSON  
+ 
+ 	Backported from master:
+ 	2026-04-01  Torbjörn SVENSSON  
+ 
+ 	PR target/124705
+ 	* gcc.dg/tree-ssa/gen-vect-26.c: Disable loop peeling check for
+ 	arm-none-eabi.
+ 	* gcc.dg/tree-ssa/gen-vect-28.c: Likewise.
+ 
+ 2026-04-02  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-04-02  Christopher Albert  
+ 
+ 	PR fortran/102596
+ 	* gfortran.dg/pr102596.f90: New test.
+ 
+ 2026-03-31  Eric Botcazou  
+ 
+ 	* gnat.dg/opt107.adb: New test.
+ 	* gnat.dg/opt107_pkg.ads: New helper.
+ 
+ 2026-03-31  Torbjörn SVENSSON  
+ 
+ 	Backported from master:
+ 	2026-03-31  Torbjörn SVENSSON  
+ 
+ 	PR target/124712
+ 	* gcc.dg/vect/vect-fmax-2.c: Changed effective target vect_float
+ 	to vect_double.
+ 	* gcc.dg/vect/vect-fmax-3.c: Likewise.
+ 	* gcc.dg/vect/vect-fmin-2.c: Likewise.
+ 	* gcc.dg/vect/vect-fmin-3.c: Likewise.
+ 
+ 2026-03-30  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2025-09-03  Patrick Palka  
+ 
+ 	PR c++/97740
+ 	* g++.dg/cpp0x/constexpr-97740a.C: New test.
+ 	* g++.dg/cpp0x/constexpr-97740b.C: New test.
+ 
+ 2026-03-30  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-03-11  Christopher Albert  
+ 
+ 	PR fortran/95338
+ 	* gfortran.dg/pr95338.f90: New test.
+ 
+ 2026-03-30  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-03-12  Christopher Albert  
+ 
+ 	PR fortran/106946
+ 	* gfortran.dg/pr106946.f90: Cover allocatable and pointer CLASS
+ 	declarations, including a valid component followed by a bad one.
+ 
+ 2026-03-29  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-03-13  Christopher Albert  
+ 
+ 	PR fortran/102459
+ 	* gfortran.dg/pr102459.f90: New test.
+ 
+ 2026-03-29  Christopher Albert  
+ 
+ 	Backported from master:
+ 	2026-03-12  Christopher Albert  
+ 
+ 	PR fortran/82721
+ 	* gfortran.dg/pr82721.f90: New test.
+ 
+ 2026-03-28  Paul Thomas  
+ 
+ 	Backported from master:
+ 	2026-03-28  Paul Thomas  
+ 
+ 	* gfortran.dg/pr84245.f90: New test.
+ 
+ 2026-03-27  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2026-02-20  Martin Jambor  
+ 
+ 	PR ipa/122856
+ 	* g++.dg/ipa/pr122856.C: New test.
+ 
+ 2026-03-23  Eric Botcazou  
+ 
+ 	* gnat.dg/generic_inst20.ads, gnat.dg/generic_inst20.adb: New test.
+ 	* gnat.dg/generic_inst20-sub.adb: New helper.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-17  Jakub Jelinek  
+ 
+ 	PR c++/124489
+ 	* g++.dg/cpp0x/pr124489.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-12  Jakub Jelinek  
+ 
+ 	PR fortran/124450
+ 	* gfortran.dg/pr124450.f90: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-06  Jakub Jelinek  
+ 
+ 	PR target/122000
+ 	* gcc.c-torture/execute/pr122000.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-06  Jakub Jelinek  
+ 
+ 	PR tree-optimization/124135
+ 	* g++.dg/torture/pr124135-1.C: New test.
+ 	* g++.dg/torture/pr124135-2.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-06  Jakub Jelinek  
+ 
+ 	PR tree-optimization/124358
+ 	* gcc.c-torture/execute/pr124358.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-05  Jakub Jelinek  
+ 
+ 	PR target/124366
+ 	* gcc.target/i386/cet-pr124366.c: New test.
+ 
+ 2026-03-22  liuhongt  
+ 
+ 	Backported from master:
+ 	2026-03-04  liuhongt  
+ 
+ 	PR target/124335
+ 	* gcc.target/i386/avx512fp16-pr124335.c: Require target
+ 	avx512fp16 instead of avx512bw.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-03  Jakub Jelinek  
+ 
+ 	PR target/124315
+ 	* gcc.target/i386/avx512f-pr124315.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-03  Jakub Jelinek  
+ 
+ 	PR target/124335
+ 	* gcc.target/i386/avx512fp16-pr124335.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-02  Jakub Jelinek  
+ 
+ 	PR tree-optimization/124288
+ 	* gcc.dg/torture/vec-cvt-1.c (FLTTEST): Use comma expression
+ 	to store into {flt,dbl}m{in,ax} and read from it again for
+ 	comparison.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-18  Jakub Jelinek  
+ 
+ 	PR c/123365
+ 	* gcc.c-torture/compile/pr123365.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-18  Jakub Jelinek  
+ 
+ 	PR target/124138
+ 	* gcc.dg/pr124138.c: New test.
+ 	* gcc.target/i386/avx512f-pr124138-1.c: New test.
+ 	* gcc.target/i386/avx512f-pr124138-2.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-17  Jakub Jelinek  
+ 
+ 	PR c++/120685
+ 	* g++.dg/cpp23/auto-fncast19.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-11  Jakub Jelinek  
+ 
+ 	PR middle-end/124056
+ 	* gcc.target/i386/pr124056.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-11  Jakub Jelinek  
+ 
+ 	PR rtl-optimization/116600
+ 	PR middle-end/123386
+ 	* gcc.c-torture/compile/pr116600.c: New test.
+ 	* gcc.c-torture/compile/pr123386.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-09  Jakub Jelinek  
+ 
+ 	PR c++/123889
+ 	* g++.dg/cpp0x/constexpr-123889.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-06  Jakub Jelinek  
+ 
+ 	PR c/101312
+ 	* gcc.dg/pr101312-1.c: New test.
+ 	* gcc.dg/pr101312-2.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-05  Jakub Jelinek  
+ 
+ 	PR c/123882
+ 	* gcc.dg/pr123882.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-02-04  Jakub Jelinek  
+ 
+ 	PR c++/123818
+ 	* g++.dg/cpp0x/pr123818.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-30  Jakub Jelinek  
+ 
+ 	PR tree-optimization/123864
+ 	* gcc.c-torture/execute/pr123864.c: New test.
+ 	* gcc.dg/torture/pr123864.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-30  Jakub Jelinek  
+ 
+ 	PR middle-end/123876
+ 	* gcc.dg/gomp/pr123876.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-30  Jakub Jelinek  
+ 
+ 	PR preprocessor/123273
+ 	* c-c++-common/cpp/dir-only-10.c: New test.
+ 	* c-c++-common/cpp/dir-only-11.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-27  Jakub Jelinek  
+ 
+ 	PR c++/123578
+ 	* g++.dg/cpp2a/pr123578.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-23  Jakub Jelinek  
+ 
+ 	PR middle-end/123703
+ 	* gcc.c-torture/compile/pr123703.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-17  Jakub Jelinek  
+ 
+ 	PR tree-optimization/123513
+ 	* g++.dg/warn/Wmismatched-new-delete-10.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-14  Jakub Jelinek  
+ 
+ 	PR target/120250
+ 	* gcc.c-torture/compile/pr120250.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-10  Jakub Jelinek  
+ 
+ 	PR tree-optimization/123431
+ 	* gcc.dg/pr123431.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-08  Jakub Jelinek  
+ 
+ 	PR middle-end/111817
+ 	* c-c++-common/pr111817.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-12-20  Jakub Jelinek  
+ 
+ 	PR target/123217
+ 	* gcc.target/i386/keylocker-pr123217.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-12-19  Jakub Jelinek  
+ 
+ 	PR c++/91388
+ 	* g++.dg/cpp1z/static_assert1.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-12-19  Jakub Jelinek  
+ 
+ 	PR c++/122772
+ 	* g++.dg/cpp1z/eval-order14.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-12-19  Jakub Jelinek  
+ 
+ 	PR c++/122834
+ 	* g++.dg/dfp/pr122834-1.C: New test.
+ 	* g++.dg/dfp/pr122834-2.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-25  Jakub Jelinek  
+ 
+ 	PR middle-end/120052
+ 	* c-c++-common/gomp/pr120052.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-25  Jakub Jelinek  
+ 
+ 	PR middle-end/120564
+ 	* c-c++-common/gomp/pr120564.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-21  Jakub Jelinek  
+ 
+ 	PR c++/121445
+ 	* g++.dg/cpp1y/constexpr-121445.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-20  Jakub Jelinek  
+ 
+ 	PR c++/120876
+ 	* g++.dg/parse/crash81.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	PR tree-optimization/122394
+ 	* g++.dg/opt/pr122394.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-10-04  Jakub Jelinek  
+ 
+ 	PR tree-optimization/122104
+ 	* gcc.target/i386/pr122104.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-09-18  Jakub Jelinek  
+ 
+ 	PR c++/121977
+ 	* g++.dg/gomp/pr121977.C: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-09-05  Jakub Jelinek  
+ 
+ 	PR testsuite/118567
+ 	* gcc.target/powerpc/vsx-vectorize-9.c: New test.
+ 	* gcc.target/powerpc/vsx-vectorize-10.c: New test.
+ 	* gcc.target/powerpc/vsx-vectorize-11.c: New test.
+ 	* gcc.target/powerpc/vsx-vectorize-12.c: New test.
+ 	* gcc.target/powerpc/vsx-vectorize-13.c: New test.
+ 	* gcc.target/powerpc/vsx-vectorize-14.c: New test.
+ 	* gcc.target/powerpc/vsx-vectorize-15.c: New test.
+ 	* gcc.target/powerpc/vsx-vectorize-16.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-09-05  Jakub Jelinek  
+ 
+ 	PR testsuite/118567
+ 	* gcc.target/powerpc/vsx-vectorize-1.c: Remove includes, checking
+ 	part of main1 and main.
+ 	* gcc.target/powerpc/vsx-vectorize-2.c: Remove includes, replace
+ 	bar definition with declaration, remove main.
+ 	* gcc.target/powerpc/vsx-vectorize-3.c: Likewise.
+ 	* gcc.target/powerpc/vsx-vectorize-4.c: Likewise.
+ 	* gcc.target/powerpc/vsx-vectorize-5.c: Likewise.
+ 	* gcc.target/powerpc/vsx-vectorize-6.c: Likewise.
+ 	* gcc.target/powerpc/vsx-vectorize-7.c: Likewise.
+ 	* gcc.target/powerpc/vsx-vectorize-8.c: Likewise.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-08-25  Jakub Jelinek  
+ 
+ 	PR middle-end/121453
+ 	* gcc.dg/gomp/pr121453.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-07-11  Jakub Jelinek  
+ 
+ 	PR c++/120954
+ 	* c-c++-common/Warray-bounds-11.c: New test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-07-04  Jakub Jelinek  
+ 
+ 	PR c/120837
+ 	* gcc.dg/ubsan/pr120837.c: New test.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-07  Richard Biener  
+ 
+ 	PR testsuite/123353
+ 	PR c/123156
+ 	* gcc.dg/torture/builtin-shufflevector-pr123156.c: Require le.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-12-18  Richard Biener  
+ 
+ 	PR c/123156
+ 	* gcc.dg/torture/builtin-shufflevector-pr123156.c: New testcase.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-09-08  Richard Biener  
+ 
+ 	PR tree-optimization/107997
+ 	PR tree-optimization/121844
+ 	* gcc.dg/torture/pr121844.c: New testcase.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-05-09  Richard Biener  
+ 
+ 	PR rtl-optimization/120182
+ 	* gcc.dg/torture/pr120182.c: New testcase.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-03-31  Richard Biener  
+ 
+ 	PR tree-optimization/119532
+ 	* gcc.dg/torture/pr119532.c: New testcase.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-30  Richard Biener  
+ 
+ 	PR tree-optimization/109410
+ 	* gcc.dg/pr109410-2.c: New testcase.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-19  Richard Biener  
+ 
+ 	PR tree-optimization/123602
+ 	* g++.dg/torture/pr123603.C: New testcase.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-08-05  Richard Biener  
+ 
+ 	PR tree-optimization/121370
+ 	* gcc.dg/torture/pr121370.c: New testcase.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-03-16  Richard Biener  
+ 
+ 	PR tree-optimization/120341
+ 	* gcc.dg/torture/pr120341-1.c: New testcase.
+ 	* gcc.dg/torture/pr120341-2.c: Likewise.
+ 
+ 2026-03-20  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2024-08-22  Andrew Pinski  
+ 		    Richard Biener   
+ 
+ 	PR middle-end/116454
+ 	* gcc.dg/torture/pr116454-1.c: New test.
+ 	* gcc.dg/torture/pr116454-2.c: New test.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-27  Richard Biener  
+ 
+ 	PR ipa/116296
+ 	* gcc.dg/torture/pr116296.c: New testcase.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-28  Richard Biener  
+ 
+ 	PR ipa/111036
+ 	* gcc.dg/torture/pr111036.c: New testcase.
+ 
+ 2026-03-20  Richard Biener  
+ 
+ 	Backported from master:
+ 	2026-01-28  Richard Biener  
+ 
+ 	PR tree-optimization/110043
+ 	* gcc.dg/torture/pr110043.c: New testcase.
+ 
+ 2026-03-14  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-02-12  Andrew Pinski  
+ 
+ 	PR c/105555
+ 	* gcc.dg/complex-10.c: New test.
+ 
+ 2026-03-14  Andrew Pinski  
+ 
+ 	Backported from master:
+ 	2026-01-18  Andrew Pinski  
+ 
+ 	PR tree-optimization/123645
+ 	* gcc.dg/torture/pr123645-1.c: New test.
+ 	* gcc.dg/torture/pr123645-2.c: New test.
+ 
+ 2026-03-13  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-01-30  Patrick Palka  
+ 
+ 	PR c++/123845
+ 	PR libstdc++/114865
+ 	* g++.dg/cpp0x/constexpr-ex3.C: Adjust C++11 non-empty
+ 	constexpr constructor dg-error to a dg-warning.  Expect
+ 	a follow-up missing member initializer diagnostic in C++11 mode.
+ 	* g++.dg/cpp2a/constexpr-try1.C: Expect a follow-up
+ 	compound-statement in constexpr function diagnostic in C++11
+ 	mode.
+ 	* g++.dg/cpp2a/constexpr-try2.C: Likewise.  Adjust C++11
+ 	non-empty constexpr constructor dg-error to a dg-warning.
+ 	* g++.dg/cpp2a/constexpr-try3.C:  Adjust C++11 non-empty
+ 	constexpr constructor dg-error to a dg-warning.
+ 	* g++.dg/cpp0x/constexpr-ctor23.C: New test.
+ 
+ 2026-03-13  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-01-27  Patrick Palka  
+ 
+ 	PR c++/123676
+ 	* g++.dg/cpp2a/concepts-decltype5.C: New test.
+ 
+ 2026-03-12  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-01-27  Patrick Palka  
+ 
+ 	PR c++/122494
+ 	PR c++/123814
+ 	* g++.dg/cpp2a/concepts-pr122494.C: New test.
+ 	* g++.dg/cpp2a/concepts-pr123814.C: New test.
+ 
+ 2026-03-09  Kalvis Duckmanton  
+ 
+ 	Backported from master:
+ 	2026-02-14  Kalvis Duckmanton  
+ 
+ 	PR target/112400
+ 	* g++.dg/torture/pr112400.C: New file.
+ 
+ 2026-03-04  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2026-02-09  Martin Jambor  
+ 
+ 	PR tree-optimization/117217
+ 	* g++.dg/torture/pr117217-1.C: New test.
+ 	* g++.dg/torture/pr117217-2.C: Likewise.
+ 
+ 2026-03-04  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2026-02-06  Martin Jambor  
+ 
+ 	PR ipa/106260
+ 	* g++.dg/ipa/pr106260.C: New test.
+ 
+ 2026-03-02  Tamar Christina  
+ 
+ 	Backported from master:
+ 	2026-02-25  Tamar Christina  
+ 
+ 	PR target/124236
+ 	* lib/target-supports.exp
+ 	(check_effective_target_arm_v8_3a_complex_neon_hw): Fix default value.
+ 
+ 2026-02-28  Eric Botcazou  
+ 
+ 	* gnat.dg/specs/unchecked_union3.ads: New test.
+ 
+ 2026-02-26  Michal Jires  
+ 
+ 	Backported from master:
+ 	2026-01-11  Michal Jires  
+ 
+ 	PR lto/121588
+ 	* gcc.dg/lto/attr-weakref-2_0.c: New test.
+ 	* gcc.dg/lto/attr-weakref-2_1.c: New test.
+ 
+ 2026-02-25  Eric Botcazou  
+ 
+ 	* gnat.dg/protected_deref1.adb: New test.
+ 
+ 2026-02-08  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-02-08  Iain Buclaw  
+ 
+ 	PR d/124026
+ 	* gdc.dg/pr124026.d: New test.
+ 
+ 2026-02-05  Hongyu Wang  
+ 
+ 	Backported from master:
+ 	2026-01-28  Hongyu Wang  
+ 
+ 	PR target/123779
+ 	* g++.target/i386/pr123779.C: New test.
+ 
+ 2026-01-30  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-30  Iain Buclaw  
+ 
+ 	PR d/123264
+ 	* gdc.dg/pr123264.d: New test.
+ 
+ 2026-01-29  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-29  Iain Buclaw  
+ 
+ 	PR d/123407
+ 	* gdc.dg/pr123407a.d: New test.
+ 	* gdc.dg/pr123407b.d: New test.
+ 
+ 2026-01-29  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-29  Iain Buclaw  
+ 
+ 	PR d/123046
+ 	* gdc.dg/pr123046.d: New test.
+ 
+ 2026-01-29  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-29  Iain Buclaw  
+ 
+ 	PR d/123349
+ 	* gdc.dg/driver_debuglib.d: New test.
+ 	* gdc.dg/driver_defaultlib.d: New test.
+ 
+ 2026-01-28  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2025-04-15  Iain Buclaw  
+ 
+ 	PR d/119799
+ 	* gdc.dg/torture/pr119799.d: New test.
+ 	* gdc.dg/torture/imports/pr119799c.c: New test.
+ 
+ 2026-01-28  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-28  Iain Buclaw  
+ 
+ 	PR d/123419
+ 	* gdc.dg/pr123419.d: New test.
+ 
+ 2026-01-28  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-28  Iain Buclaw  
+ 
+ 	PR d/123798
+ 	* gdc.dg/pr123798.d: New test.
+ 
+ 2026-01-28  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-28  Iain Buclaw  
+ 
+ 	PR d/121477
+ 	* gdc.dg/pr121477.d: New test.
+ 
+ 2026-01-28  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-28  Iain Buclaw  
+ 
+ 	PR d/123422
+ 	* gdc.dg/torture/pr123422.d: New test.
+ 
+ 2026-01-27  Iain Buclaw  
+ 
+ 	Backported from master:
+ 	2026-01-27  Iain Buclaw  
+ 
+ 	PR d/120096
+ 	* gdc.dg/torture/pr120096.d: New test.
+ 
+ 2026-01-23  Avinash Jayakar  
+ 
+ 	PR target/119130
+ 	* gcc.target/powerpc/builtins-1-p9-runnable.c: Use same expected
+ 	results for both endian format.
+ 
+ 2026-01-16  Vladimir N. Makarov  
+ 
+ 	PR rtl-optimization/123121
+ 	* gcc.target/i386/pr123121.c: New.
+ 
+ 2026-01-06  Avinash Jayakar  
+ 
+ 	PR tree-optimization/122126
+ 	* gcc.dg/pr122126_vextr.c: New test.
+ 	* gcc.dg/pr122126_vset.c: New test.
+ 
+ 2025-12-01  Avinash Jayakar  
+ 
+ 	Revert:
+ 	2025-12-01  Avinash Jayakar  
+ 
+ 	PR tree-optimization/122126
+ 	* gcc.dg/pr122126_vextr.c: New test.
+ 	* gcc.dg/pr122126_vset.c: New test.
+ 
+ 2025-11-28  Avinash Jayakar  
+ 
+ 	PR tree-optimization/122126
+ 	* gcc.dg/pr122126_vextr.c: New test.
+ 	* gcc.dg/pr122126_vset.c: New test.
+ 
+ 2025-11-27  Richard Earnshaw  
+ 
+ 	Backported from master:
+ 	2025-11-26  Richard Earnshaw  
+ 
+ 	PR target/122867
+ 	* gcc.target/arm/cbz-range.c: New test.
+ 
+ 2025-11-18  Richard Biener  
+ 	    Alex Coplan  
+ 
+ 	PR tree-optimization/112469
+ 	PR tree-optimization/122724
+ 	* gcc.target/aarch64/sve/pr122724.c: New test.
+ 
+ 2025-11-13  Hu, Lin1  
+ 
+ 	Backported from master:
+ 	2025-11-13  Hu, Lin1  
+ 
+ 	PR target/122446
+ 	* gcc.target/i386/amxbf16-asmintel-1.c: Modify dg-final to check intel
+ 	form.
+ 	* gcc.target/i386/amxcomplex-asmintel-1.c: Ditto.
+ 	* gcc.target/i386/amxfp16-asmintel-1.c: Ditto.
+ 	* gcc.target/i386/amxint8-asmintel-1.c: Ditto.
+ 	* gcc.target/i386/amxtile-asmintel-1.c: Ditto.
+ 	* g++.target/i386/pr122446-1.C: New test.
+ 	* g++.target/i386/pr122446-amxbf16.C: Ditto.
+ 	* g++.target/i386/pr122446-amxcomplex.C: Ditto.
+ 	* g++.target/i386/pr122446-amxfp16.C: Ditto.
+ 	* g++.target/i386/pr122446-amxint8.C: Ditto.
+ 	* g++.target/i386/pr122446-amxtile.C: Ditto.
+ 
+ 2025-11-07  Christophe Lyon  
+ 
+ 	PR target/122223
+ 	* gcc.target/arm/mve/intrinsics/pr122223.c: New test.
+ 	(cherry picked from commits
+ 	81e226440381cc3e033df7e58cc7793c9b4b4e25 and
+ 	a52888dc71924afb6cd187b0e5f18d2be4c68a07)
+ 
+ 2025-10-31  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-09-11  Richard Biener  
+ 
+ 	PR tree-optimization/121870
+ 	* g++.dg/torture/pr121870.C: New testcase.
+ 
+ 2025-10-31  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-10-14  Richard Biener  
+ 
+ 	PR tree-optimization/121256
+ 	* gcc.dg/vect/vect-recurr-pr121256.c: New testcase.
+ 	* gcc.dg/vect/vect-recurr-pr121256-2.c: Likewise.
+ 
+ 2025-10-31  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-10-14  Richard Biener  
+ 		    Richard Sandiford   
+ 
+ 	PR tree-optimization/121059
+ 	* gcc.dg/vect/pr121059.c: New testcase.
+ 
+ 2025-10-31  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-07-04  Richard Biener  
+ 
+ 	PR tree-optimization/120944
+ 	* gcc.dg/torture/pr120944.c: New testcase.
+ 
+ 2025-10-31  Tamar Christina  
+ 
+ 	Backported from master:
+ 	2025-07-07  Tamar Christina  
+ 
+ 	PR tree-optimization/120817
+ 	* gcc.dg/vect/pr120817.c: Add SVE HW check.
+ 
+ 2025-10-31  Richard Biener  
+ 
+ 	Backported from master:
+ 	2025-07-07  Richard Biener  
+ 
+ 	PR tree-optimization/120817
+ 	* gcc.dg/vect/pr120817.c: New testcase.
+ 
+ 2025-10-20  Eric Botcazou  
+ 
+ 	* gnat.dg/renaming18.adb: New test.
+ 
+ 2025-10-16  Alex Coplan  
+ 
+ 	Backported from master:
+ 	2025-09-15  Alex Coplan  
+ 
+ 	PR tree-optimization/121772
+ 	* gcc.target/aarch64/torture/pr121772.c: New test.
+ 
+ 2025-10-05  Harald Anlauf  
+ 
+ 	Backported from master:
+ 	2025-09-03  Harald Anlauf  
+ 
+ 	PR fortran/121263
+ 	* gfortran.dg/transfer_class_5.f90: New test.
+ 
+ 2025-10-03  Jeff Law  
+ 
+ 	Backported from master:
+ 	2023-06-12  Jeff Law  
+ 
+ 	PR rtl-optimization/101188
+ 	* gcc.c-torture/execute/pr101188.c: New test
+ 
+ 2025-09-18  hongtao.liu  
+ 
+ 	Backported from master:
+ 	2025-09-18  hongtao.liu  
+ 
+ 	* gcc.target/i386/pieces-memcpy-18.c: Use -mtune=znver5
+ 	instead of -mtune=sapphirerapids.
+ 	* gcc.target/i386/pieces-memcpy-21.c: Ditto.
+ 	* gcc.target/i386/pieces-memset-46.c: Ditto.
+ 	* gcc.target/i386/pieces-memset-49.c: Ditto.
+ 
+ 2025-09-17  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2025-08-20  Martin Jambor  
+ 
+ 	PR tree-optimization/119085
+ 	* gcc.dg/tree-ssa/pr119085.c: New test.
+ 
+ 2025-09-17  Martin Jambor  
+ 
+ 	Backported from master:
+ 	2025-09-17  Martin Jambor  
+ 
+ 	PR tree-optimization/117423
+ 	* gcc.dg/tree-ssa/pr117423.c: New test.
+ 
+ 2025-09-15  Matthias Kretz  
+ 
+ 	Backported from master:
+ 	2025-09-09  Matthias Kretz  
+ 
+ 	PR c++/121801
+ 	* g++.dg/abi/pr121801.C: New test.
+ 
+ 2025-08-30  liuhongt  
+ 
+ 	Revert:
+ 	2025-08-30  liuhongt  
+ 
+ 	* gcc.target/i386/pr120691.c: New test.
+ 
+ 2025-08-29  liuhongt  
+ 
+ 	Backported from master:
+ 	2025-08-29  liuhongt  
+ 
+ 	* gcc.target/i386/pr120691.c: New test.
+ 
+ 2025-08-18  Richard Sandiford  
+ 
+ 	Backported from master:
+ 	2025-08-18  Richard Sandiford  
+ 
+ 	PR target/121118
+ 	* gcc.target/aarch64/sve/acle/general/pr121118_1.c: New test.
+ 
+ 2025-08-18  Richard Sandiford  
+ 
+ 	Backported from master:
+ 	2025-08-12  Richard Sandiford  
+ 
+ 	PR rtl-optimization/121253
+ 	* gcc.target/aarch64/pr121253.c: New test.
+ 
+ 2025-08-15  Pengfei Li  
+ 
+ 	PR target/121449
+ 	* g++.target/aarch64/sve/pr121449.C: New test.
+ 
+ 2025-08-14  Richard Sandiford  
+ 
+ 	Backported from master:
+ 	2025-08-14  Richard Sandiford  
+ 
+ 	PR target/121294
+ 	* gcc.target/aarch64/sve/acle/general/rev_2.c: New test.
+ 
+ 2025-08-14  Richard Sandiford  
+ 
+ 	Backported from master:
+ 	2025-08-14  Richard Sandiford  
+ 
+ 	PR target/121294
+ 	* gcc.target/aarch64/sve/acle/general/perm_2.c: New test.
+ 	* gcc.target/aarch64/sve/acle/general/perm_3.c: Likewise.
+ 	* gcc.target/aarch64/sve/acle/general/perm_4.c: Likewise.
+ 	* gcc.target/aarch64/sve/acle/general/perm_5.c: Likewise.
+ 	* gcc.target/aarch64/sve/acle/general/perm_6.c: Likewise.
+ 	* gcc.target/aarch64/sve/acle/general/perm_7.c: Likewise.
+ 
+ 2025-08-14  H.J. Lu  
+ 
+ 	Backported from master:
+ 	2025-07-29  H.J. Lu  
+ 
+ 	PR target/121208
+ 	* gcc.target/i386/pr121208-1a.c (dg-options): Add
+ 	-mno-sse -mno-mmx -mno-80387.
+ 	* gcc.target/i386/pr121208-1b.c (dg-options): Likewise.
+ 
+ 2025-08-14  H.J. Lu  
+ 
+ 	Backported from master:
+ 	2025-07-28  H.J. Lu  
+ 
+ 	PR target/121208
+ 	* gcc.target/i386/pr121208-1a.c: New test.
+ 	* gcc.target/i386/pr121208-1b.c: Likewise.
+ 	* gcc.target/i386/pr121208-2a.c: Likewise.
+ 	* gcc.target/i386/pr121208-2b.c: Likewise.
+ 	* gcc.target/i386/pr121208-3a.c: Likewise.
+ 	* gcc.target/i386/pr121208-3b.c: Likewise.
+ 
+ 2025-08-08  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2025-08-04  Patrick Palka  
+ 
+ 	PR c++/120620
+ 	* g++.dg/cpp2a/constexpr-dynamic19.C: New test.
+ 	* g++.dg/cpp2a/constexpr-dynamic1a.C: New test.
+ 
+ 2025-07-31  Jeevitha  
+ 
+ 	Backported from master:
+ 	2025-07-24  Jeevitha Palanisamy  
+ 
+ 	PR testsuite/119382
+ 	* gcc.target/powerpc/vsx-builtin-7.c: Add '-fno-ipa-icf' to dg-options.
+ 
+ 2025-07-31  H.J. Lu  
+ 
+ 	Backported from master:
+ 	2025-07-30  H.J. Lu  
+ 
+ 	PR target/120427
+ 	* gcc.target/i386/pr120427-5.c: New test.
+ 
+ 2025-07-29  H.J. Lu  
+ 
+ 	Backported from master:
+ 	2025-06-19  H.J. Lu  
+ 
+ 	PR target/120427
+ 	* gcc.target/i386/cold-attribute-4.c: Compile with -Oz.
+ 	* gcc.target/i386/pr120427-1.c: New test.
+ 	* gcc.target/i386/pr120427-2.c: Likewise.
+ 	* gcc.target/i386/pr120427-3.c: Likewise.
+ 	* gcc.target/i386/pr120427-4.c: Likewise.
+ 
+ 2025-07-17  H.J. Lu  
+ 
+ 	Backported from master:
+ 	2025-07-03  H.J. Lu  
+ 
+ 	PR target/120908
+ 	* gcc.target/i386/pr120908.c: New test.
+ 
+ 2025-07-03  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-07-03  Jakub Jelinek  
+ 
+ 	PR c++/120940
+ 	* g++.dg/parse/pr120940.C: New test.
+ 	* g++.dg/warn/Wduplicated-branches9.C: New test.
+ 
+ 2025-07-03  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-07-01  Jakub Jelinek  
+ 
+ 	PR c++/120471
+ 	* g++.dg/ubsan/pr120471.C: New test.
+ 	* g++.dg/parse/pr120471.C: New test.
+ 
+ 2025-06-27  Eric Botcazou  
+ 
+ 	* gnat.dg/sso20.adb: New test.
+ 
+ 2025-06-13  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2025-06-12  Georg-Johann Lay  
+ 
+ 	PR middle-end/117811
+ 	PR testsuite/52641
+ 	* gcc.dg/torture/pr117811.c: Fix for int < 32 bit.
+ 
+ 2025-06-13  Richard Earnshaw  
+ 
+ 	Backported from master:
+ 	2025-03-25  Richard Earnshaw  
+ 
+ 	PR middle-end/117811
+ 	* gcc.dg/torture/pr117811.c: New test.
+ 
+ 2025-06-05  Jason Merrill  
+ 
+ 	PR c++/120123
+ 	* g++.dg/cpp2a/concepts-lambda24.C: New test.
+ 
+ 2025-06-05  Eric Botcazou  
+ 
+ 	* gnat.dg/specs/opt7.ads: New test.
+ 	* gnat.dg/specs/opt7_pkg.ads: New helper.
+ 	* gnat.dg/specs/opt7_pkg.adb: Likewise.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/gcc/testsuite/c-c++-common/Warray-bounds-11.c gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/Warray-bounds-11.c
*** gcc-13.4.0/gcc/testsuite/c-c++-common/Warray-bounds-11.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/Warray-bounds-11.c	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,21 ----
+ /* PR c++/120954 */
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -Warray-bounds=2" } */
+ 
+ static const int a[32] = { 11, 12, 13, 14, 15 };
+ static const int b[32] = { 21, 22, 23, 24, 25 };
+ static const int c[32] = { 31, 32, 33, 34, 35 };
+ static const int d[32] = { 111, 112, 113, 114, 115 };
+ static const int e[32] = { 121, 122, 123, 124, 125 };
+ static const int f[32] = { 131, 132, 133, 134, 135 };
+ 
+ int
+ foo (int x, int y)
+ {
+   int r = 0;
+   if (x >= 0 && x < 32)
+     r = (y >= 4 ? (y >= 0x65 ? a : b ) : c)[x];
+   else if (x >= 0x100 && x < 0x120)
+     r = (y >= 4 ? (y >= 0x65 ? d : e ) : f)[x - 0x100];
+   return r;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/c-c++-common/cpp/dir-only-10.c gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/cpp/dir-only-10.c
*** gcc-13.4.0/gcc/testsuite/c-c++-common/cpp/dir-only-10.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/cpp/dir-only-10.c	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,5 ----
+ /* PR preprocessor/123273 */
+ /* { dg-do preprocess } */
+ /* { dg-options -fdirectives-only } */
+ 
+ /* *\/""" */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/c-c++-common/cpp/dir-only-11.c gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/cpp/dir-only-11.c
*** gcc-13.4.0/gcc/testsuite/c-c++-common/cpp/dir-only-11.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/cpp/dir-only-11.c	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,6 ----
+ /* PR preprocessor/123273 */
+ /* { dg-do preprocess } */
+ /* { dg-options -fdirectives-only } */
+ 
+ /* *\\
+ /""" */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/c-c++-common/cpp/va-opt-11.c gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/cpp/va-opt-11.c
*** gcc-13.4.0/gcc/testsuite/c-c++-common/cpp/va-opt-11.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/cpp/va-opt-11.c	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,13 ----
+ /* PR preprocessor/125048 */
+ /* { dg-do preprocess } */
+ /* { dg-options "-std=c2x" { target c } } */
+ /* { dg-options "-std=c++20" { target c++ } } */
+ 
+ #define A(...)B(B(B(B(__VA_ARGS__##__VA_OPT__()))))
+ #define B(...)C(C(C(C(__VA_ARGS__##__VA_OPT__()))))
+ #define C(...)D(D(D(D(__VA_ARGS__##__VA_OPT__()))))
+ #define D(...)E(E(E(E(__VA_ARGS__##__VA_OPT__()))))
+ #define E(...)__VA_ARGS__
+ #define F
+ A(F)
+ /* { dg-final { scan-file va-opt-11.i "D\\\(D\\\(D\\\(C\\\(C\\\(C\\\(B\\\(B\\\(B\\\(\\\)\\\)\\\)\\\)\\\)\\\)\\\)\\\)\\\)" } } */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/c-c++-common/gomp/pr120052.c gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/gomp/pr120052.c
*** gcc-13.4.0/gcc/testsuite/c-c++-common/gomp/pr120052.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/gomp/pr120052.c	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,32 ----
+ /* PR middle-end/120052 */
+ /* { dg-do compile } */
+ /* { dg-additional-options "-fsanitize=undefined" } */
+ 
+ void
+ foo (unsigned long s, long indx)
+ {
+   long counts[2][s];
+   #pragma omp parallel
+   #pragma omp masked
+   for (int i = 0; i < 2; i++)
+     counts[2][indx] = 1;
+ }
+ 
+ void
+ bar (unsigned long s, long indx)
+ {
+   long counts[2][s];
+   #pragma omp parallel shared(counts)
+   #pragma omp masked
+   for (int i = 0; i < 2; i++)
+     counts[2][indx] = 1;
+ }
+ 
+ void
+ baz (unsigned long s, long indx)
+ {
+   long counts[2][s];
+   #pragma omp parallel private(counts)
+   for (int i = 0; i < 2; i++)
+     counts[2][indx] = 1;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/c-c++-common/gomp/pr120564.c gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/gomp/pr120564.c
*** gcc-13.4.0/gcc/testsuite/c-c++-common/gomp/pr120564.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/gomp/pr120564.c	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,15 ----
+ /* PR middle-end/120564 */
+ /* { dg-do compile } */
+ 
+ void bar (unsigned long long, unsigned long long, unsigned long long);
+ 
+ void
+ foo (void)
+ {
+   unsigned long long v1, v2, v3;
+ #pragma omp parallel for schedule(static, 32) collapse(3)
+   for (v1 = 0; v1 < 20; v1 += 2)
+     for (v2 = __LONG_LONG_MAX__; v2 > __LONG_LONG_MAX__; v2 -= 3)
+       for (v3 = 10; v3 > 0; v3--)
+ 	bar (v1, v2, v3);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/c-c++-common/pr111817.c gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/pr111817.c
*** gcc-13.4.0/gcc/testsuite/c-c++-common/pr111817.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/c-c++-common/pr111817.c	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,9 ----
+ /* PR middle-end/111817 */
+ /* { dg-do compile } */
+ 
+ int
+ foo (int x, int y)
+ {
+   asm ("" : "\n=g" (x) : "0" (y));	/* { dg-warning "output constraint '=' for operand 0 is not at the beginning" } */
+   return x;				/* { dg-error "invalid punctuation '\\\\x\[0-9a-zA-Z]*' in constraint" "" { target *-*-* } .-1 } */
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/abi/pr121801.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/abi/pr121801.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/abi/pr121801.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/abi/pr121801.C	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,13 ----
+ // PR c++/121801
+ // { dg-do compile { target { c++20 && float16 } } }
+ // { dg-add-options float16 }
+ 
+ template<_Float16 T> void f() {}
+ 
+ void uses() {
+   f<_Float16(1)>();
+   f<_Float16(2)>();
+ }
+ 
+ // { dg-final { scan-assembler "_Z1fILDF16_3c00EEvv" } }
+ // { dg-final { scan-assembler "_Z1fILDF16_4000EEvv" } }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/asan/pr120201-1.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/asan/pr120201-1.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/asan/pr120201-1.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/asan/pr120201-1.C	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,42 ----
+ // { dg-do run }
+ // { dg-options "-O3 -std=c++23 -fsanitize=address" }
+ 
+ using size_t = decltype (sizeof 0);
+ 
+ float* shaderLightData;
+ 
+ using ShaderShadowTransform = float[4z * 4z * 6z];
+ using Transform = float[4 * 4];
+ 
+ __attribute__ ((noipa))
+ #if defined(__i386__) || defined(__x86_64__)
+ __attribute__ ((target ("arch=x86-64-v4")))
+ #endif
+ static void
+ do_test (void)
+ {
+   int lightCount = 3;
+   ShaderShadowTransform* shaderShadowData = new ShaderShadowTransform[lightCount];
+   for (int index = 0; index < lightCount; index++)
+     {
+       Transform transforms[6];
+ 
+       const size_t matSize = 4z * 4z;
+       float* transformBlockStart = shaderShadowData[index];
+       for (int face = 0; face < 6; face++)
+ 	__builtin_memcpy(transformBlockStart + (matSize * face),
+ 			 &transforms[face][0], matSize * sizeof(float));
+   }
+ 
+   delete [] shaderShadowData;
+ }
+ 
+ int
+ main (void)
+ {
+ #if defined(__i386__) || defined(__x86_64__)
+   if (__builtin_cpu_supports ("x86-64-v4"))
+ #endif
+     do_test ();
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/constexpr-123889.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/constexpr-123889.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/constexpr-123889.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/constexpr-123889.C	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,14 ----
+ // PR c++/123889
+ // { dg-do compile { target c++11 } }
+ 
+ template 
+ constexpr int func (T) {
+ // { dg-message "'constexpr int func\\\(T\\\) \\\[with T = int\\\]' is not usable as a 'constexpr' function because:" "" { target c++11_only } .-1 }
+ // { dg-error "body of 'constexpr' function 'constexpr int func\\\(T\\\) \\\[with T = int\\\]' not a return-statement" "" { target c++11_only } .-2 }
+   return 1;
+   return 2;
+ }
+ 
+ static_assert (func (1) == 1, "");
+ // { dg-error "non-constant condition for static assertion" "" { target c++11_only } .-1 }
+ // { dg-error "'constexpr int func\\\(T\\\) \\\[with T = int\\\]' called in a constant expression" "" { target c++11_only } .-2 }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/constexpr-97740a.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/constexpr-97740a.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/constexpr-97740a.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/constexpr-97740a.C	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,18 ----
+ // PR c++/97740
+ // { dg-do compile { target c++11 } }
+ 
+ struct A {
+   constexpr const int* get() const { return &m; }
+ private:
+   int m;
+ } a;
+ 
+ struct B { const int* p; };
+ 
+ template
+ void f() {
+   constexpr B x = {a.get()}; // { dg-bogus "private" }
+   constexpr B y = {&a.m};    // { dg-error "private" }
+ }
+ 
+ template void f();
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/constexpr-97740b.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/constexpr-97740b.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/constexpr-97740b.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/constexpr-97740b.C	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,20 ----
+ // PR c++/97740
+ // { dg-do compile { target c++14 } }
+ 
+ struct A {
+   constexpr const int* get() const { return &m; }
+ private:
+   int m;
+ } a;
+ 
+ struct B { const int* p; };
+ 
+ template
+ void f() {
+   [] (auto) {
+     constexpr B x = {arg->get()}; // { dg-bogus "private" }
+     constexpr B y = {&arg->m};    // { dg-error "private" }
+   }(0);
+ }
+ 
+ template void f<&a>();
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor23.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor23.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor23.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/constexpr-ctor23.C	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,26 ----
+ // Verify we diagnose and accept, as an extension, a non-empty constexpr
+ // constructor body in C++11 mode.
+ // PR c++/123845
+ // { dg-do compile { target c++11_only } }
+ // { dg-options "" }
+ 
+ constexpr int negate(int n) { return -n; }
+ 
+ struct A {
+   int m;
+   constexpr A() : m(42) {
+     ++m;
+     m = negate(m);
+   } // { dg-warning "does not have empty body \[-Wc++14-extensions\]" }
+ };
+ static_assert(A().m == -43, "");
+ 
+ template
+ struct B {
+   int m;
+   constexpr B() : m(42) {
+     ++m;
+     m = negate(m);
+   } // { dg-warning "does not have empty body \[-Wc++14-extensions\]" }
+ };
+ static_assert(B().m == -43, "");
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/constexpr-ex3.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/constexpr-ex3.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/constexpr-ex3.C	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/constexpr-ex3.C	Fri Sep  4 07:35:08 2026
***************
*** 6,12 ****
  struct A
  {
    int i;
!   constexpr A(int _i) { i = _i; } // { dg-error "empty body|A::i" "" { target c++17_down } }
  };
  
  template 
--- 6,13 ----
  struct A
  {
    int i;
!   constexpr A(int _i) { i = _i; } // { dg-warning "empty body" "" { target c++11_only } }
! 				  // { dg-error "'A::i' must be init" "" { target c++17_down } .-1 }
  };
  
  template 
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/pr123818.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/pr123818.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/pr123818.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/pr123818.C	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,24 ----
+ // PR c++/123818
+ // { dg-do run { target c++11 } }
+ 
+ struct A { A (int x) : a (x) {} int a; };
+ struct B { A b; };
+ 
+ int
+ foo (B x = B { 42 })
+ {
+     return x.b.a;
+ }
+ 
+ int
+ bar (B x = B { 43 })
+ {
+     return x.b.a;
+ }
+ 
+ int
+ main ()
+ {
+   if (foo () != bar () - 1)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/pr124489.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/pr124489.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/pr124489.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/pr124489.C	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,9 ----
+ // PR c++/124489
+ // { dg-do compile { target c++11 } }
+ 
+ void
+ g ()
+ {
+   constexpr decltype(nullptr) dm = nullptr; // { dg-message ".constexpr std::nullptr_t dm. previously declared here" }
+   constexpr decltype(nullptr) dm = nullptr; // { dg-error "redeclaration of .constexpr std::nullptr_t dm." }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/rv-decl1.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/rv-decl1.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp0x/rv-decl1.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp0x/rv-decl1.C	Fri Sep  4 07:35:08 2026
***************
*** 0 ****
--- 1,7 ----
+ // PR c++/65271
+ // { dg-do compile { target c++11 } }
+ 
+ struct {} && m0 = {};
+ union  {} && m1 = {};
+ class  {} && m2 = {};
+ enum   {} && m3 = {};
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp1y/auto-fn66.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1y/auto-fn66.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp1y/auto-fn66.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1y/auto-fn66.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,20 ----
+ // PR c++/120757
+ // { dg-do compile { target c++14 } }
+ 
+ template  struct A
+ {
+   auto foo() {}
+ };
+ 
+ auto bar(void (A::*)()) {}
+ 
+ template  auto baz()
+ {
+   bar(&A::foo);
+ }
+ 
+ int main()
+ {
+   baz<0>();
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp1y/constexpr-121445.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1y/constexpr-121445.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp1y/constexpr-121445.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1y/constexpr-121445.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,19 ----
+ // PR c++/121445
+ // { dg-do compile { target c++14 } }
+ 
+ struct D {
+   const char *d;
+   const char *foo () { return ""; };			// { dg-message "declared here" "" { target c++20_down } }
+   constexpr D () : d (foo ()) {}			// { dg-error "call to non-'constexpr' function 'const char\\\* D::foo\\\(\\\)'" "" { target c++20_down } }
+   constexpr D &operator= (const char *) { return *this; }
+ };
+ struct S {
+   constexpr S ()
+   {
+     struct A { D a; };
+     struct B { A b; };
+     struct C { B c; };
+     C d {};
+     d.c.b.a = "";
+   }
+ };
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp1y/decltype-auto9.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1y/decltype-auto9.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp1y/decltype-auto9.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1y/decltype-auto9.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,15 ----
+ // PR c++/116379
+ // { dg-do compile { target c++14 } }
+ 
+ template
+ struct X {
+   T val;
+   decltype(auto) value() { return (val); }
+ };
+ 
+ int main() {
+   int i = 0;
+   X x{ static_cast(i) };
+   using type = decltype(x.value());
+   using type = int&;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp1z/eval-order14.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1z/eval-order14.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp1z/eval-order14.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1z/eval-order14.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,114 ----
+ // PR c++/122772
+ // { dg-do run }
+ 
+ struct S { int y : 7; } s;
+ struct T { int x; int z : 7; } t;
+ int cnt, mode;
+ 
+ int
+ foo ()
+ {
+ #if __cplusplus >= 201703L
+   if (cnt != 1 + (mode & 1))
+     __builtin_abort ();
+ #endif
+   ++cnt;
+   return 2;
+ }
+ 
+ int
+ bar ()
+ {
+ #if __cplusplus >= 201703L
+   if (cnt != 0)
+     __builtin_abort ();
+ #endif
+   ++cnt;
+   return 40;
+ }
+ 
+ S &
+ baz ()
+ {
+ #if __cplusplus >= 201703L
+   if (cnt != 2 + (mode & 1))
+     __builtin_abort ();
+ #endif
+   if (mode & 2)
+     __builtin_abort ();
+   ++cnt;
+   return s;
+ }
+ 
+ T &
+ qux ()
+ {
+ #if __cplusplus >= 201703L
+   if (cnt != 2 + (mode & 1))
+     __builtin_abort ();
+ #endif
+   if ((mode & 2) == 0)
+     __builtin_abort ();
+   ++cnt;
+   return t;
+ }
+ 
+ bool
+ fred (bool x)
+ {
+ #if __cplusplus >= 201703L
+   if (cnt != 1)
+     __builtin_abort ();
+ #endif
+   ++cnt;
+   return x;
+ }
+ 
+ void
+ plugh (bool b)
+ {
+   S x;
+   x.y = 5;
+   mode = 0;
+   cnt = 0;
+   (x.y = foo ()) += bar ();
+   if (cnt != 2 || x.y != 42)
+     __builtin_abort ();
+   x.y = 5;
+   cnt = 0;
+   (baz ().y = foo ()) += bar ();
+   if (cnt != 3 || s.y != 42)
+     __builtin_abort ();
+   s.y = 5;
+   mode = (b ? 0 : 2);
+   cnt = 0;
+   (b ? (baz ().y = foo ()) : (qux ().z = foo ())) += bar ();
+   if (cnt != 3 || (b ? (s.y != 42) : (t.z != 42)))
+     __builtin_abort ();
+   s.y = 5;
+   t.z = 5;
+   mode |= 1;
+   cnt = 0;
+   (fred (b) ? (baz ().y = foo ()) : (qux ().z = foo ())) += bar ();
+   if (cnt != 4 || (b ? (s.y != 42) : (t.z != 42)))
+     __builtin_abort ();
+   s.y = 5;
+   t.z = 5;
+   mode = 0;
+   cnt = 0;
+   ++x.y += bar ();
+   if (cnt != 1 || x.y != 46)
+     __builtin_abort ();
+   cnt = 0;
+   x.y = 9;
+   --x.y += bar ();
+   if (cnt != 1 || x.y != 48)
+     __builtin_abort ();
+ }
+ 
+ int
+ main ()
+ {
+   plugh (false);
+   plugh (true);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp1z/nontype9.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1z/nontype9.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp1z/nontype9.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1z/nontype9.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,16 ----
+ // PR c++/123529
+ // { dg-do compile { target c++17 } }
+ 
+ template
+ void f();
+ 
+ template
+ struct A {
+   static void g() {
+     static int i;
+     f<&i>();
+   }
+ };
+ 
+ template struct A;
+ template struct A;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp1z/static_assert1.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1z/static_assert1.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp1z/static_assert1.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp1z/static_assert1.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,17 ----
+ // PR c++/91388
+ // Make sure we don't emit -Wreturn-type in functions with failed static_asserts.
+ // { dg-do compile { target c++17 } }
+ 
+ template 
+ int
+ foo ()
+ {
+   if constexpr (N <= 42)
+     return N;
+   else
+     static_assert (false, "too high N");	// { dg-error "too high N" }
+ }						// { dg-bogus "no return statement in function returning non-void" }
+ 
+ int a = foo <0> ();
+ int b = foo <42> ();
+ int c = foo <100> ();
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp23/auto-fncast19.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp23/auto-fncast19.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp23/auto-fncast19.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp23/auto-fncast19.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,12 ----
+ // PR c++/120685
+ // { dg-do compile { target c++11 } }
+ // { dg-options "" }
+ 
+ template 
+ void foo (decltype (auto (T ())) x) {}	// { dg-warning "'auto\\\(x\\\)' only available with" "" { target c++20_down } }
+ 
+ int
+ main ()
+ {
+   foo  (1);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-decltype5.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-decltype5.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-decltype5.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-decltype5.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,10 ----
+ // PR c++/123676
+ // { dg-do compile { target c++20 } }
+ 
+ template
+ concept C = true;
+ 
+ template
+ auto f() -> decltype(C) {
+   return true;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-decltype6.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-decltype6.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-decltype6.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-decltype6.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,16 ----
+ // PR c++/121822
+ // { dg-do compile { target c++20 } }
+ 
+ template
+ using void_t = void;
+ 
+ template
+ concept Derived = requires { typename T::derived_type; };
+ 
+ template
+ struct Wrapper;
+ 
+ template
+ struct Wrapper))>> { };
+ 
+ Wrapper x;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-lambda24.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-lambda24.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-lambda24.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-lambda24.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,13 ----
+ // PR c++/120123
+ // { dg-do compile { target c++20 } }
+ 
+ struct H {
+     void member(int) {}
+     void call() {
+         [this]() {
+             [this](const auto& v)
+                 requires requires { /*this->*/member(v); }
+             { return member(v); }(0);
+         };
+     }
+ };
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder15.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder15.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder15.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder15.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,17 ----
+ // PR c++/121981
+ // { dg-do compile { target c++20 } }
+ 
+ template
+ concept C = requires { V; };
+ 
+ template
+ concept D = C;
+ 
+ template auto W>
+ struct A { };
+ 
+ template T>
+ struct B { };
+ 
+ A<0, 1> a;
+ B<0, int> b;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-pr122494.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-pr122494.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-pr122494.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-pr122494.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,24 ----
+ // PR c++/122494
+ // { dg-do compile { target c++20 } }
+ 
+ template
+ concept C = false;
+ 
+ template requires (!C)
+ struct A {
+   static constexpr unsigned v = 0;
+ };
+ 
+ template
+ struct B {
+   static constexpr unsigned v = A::v;
+ 
+   constexpr static bool f() {
+     return [](auto) {
+       if (v == 0) { }
+       return true;
+     }(0);
+   }
+ };
+ 
+ static_assert(B::f());
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-pr123814.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-pr123814.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/concepts-pr123814.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/concepts-pr123814.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,34 ----
+ // PR c++/123814
+ // { dg-do compile { target c++20 } }
+ // { dg-additional-options "-Wall --param ggc-min-expand=0 --param ggc-min-heapsize=0" }
+ 
+ namespace std {
+   struct source_location {
+     struct __impl {
+       const char *_M_file_name;
+       const char *_M_function_name;
+       unsigned _M_line;
+       unsigned _M_column;
+     };
+     static void current(const __impl* = __builtin_source_location());
+   };
+ } // namespace std
+ 
+ template  concept same_as = true;
+ 
+ template 
+ concept one_of = (same_as || ...);
+ 
+ template  T> constexpr int buffer_size_for_int = 0;
+ template <> constexpr int buffer_size_for_int = 1;
+ 
+ template  using Basic_Characters = int;
+ 
+ template 
+ Basic_Characters> to_characters() {
+   std::source_location::current();
+ } // { dg-warning "return statement" }
+ 
+ void go() {
+   to_characters();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic19.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic19.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic19.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic19.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,10 ----
+ // PR c++/120620
+ // { dg-do compile }
+ 
+ #include 
+ 
+ struct A* a;
+ 
+ void f() {
+   void* const p = abi::__dynamic_cast(&a, 0, 0, 42);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic1a.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic1a.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic1a.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-dynamic1a.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,6 ----
+ // Test that including , whence the actual abi:__dynamic_cast
+ // is declared, doesn't affect our constexpr dynamic_cast handling.
+ // { dg-do compile { target c++20 } }
+ 
+ #include 
+ #include "constexpr-dynamic1.C"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-new24.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,25 ----
+ // PR c++/118775
+ // { dg-do compile { target c++20 } }
+ 
+ int a;
+ 
+ constexpr char *
+ f1 ()
+ {
+   constexpr auto p = new char[(long int) &a]; // { dg-error "conversion from pointer" }
+   return p;
+ }
+ 
+ constexpr char *
+ f2 ()
+ {
+   auto p = new char[(long int) &a];  // { dg-error "conversion from pointer" }
+   return p;
+ }
+ 
+ void
+ g ()
+ {
+   auto r1 = f2 ();
+   constexpr auto r2 = f2 (); // { dg-message "in .constexpr. expansion" }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-new25.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,27 ----
+ // PR c++/118775
+ // { dg-do compile { target c++20 } }
+ 
+ namespace std {
+ struct __uniq_ptr_impl {
+   constexpr __uniq_ptr_impl(char *) {}
+ };
+ template  struct unique_ptr {
+   __uniq_ptr_impl _M_t;
+   constexpr ~unique_ptr() {}
+ };
+ template  struct _MakeUniq;
+ template  struct _MakeUniq<_Tp[]> {
+   typedef unique_ptr<_Tp[]> __array;
+ };
+ template  using __unique_ptr_array_t = _MakeUniq<_Tp>::__array;
+ constexpr __unique_ptr_array_t make_unique(long __num) {
+   return unique_ptr(new char[__num]);
+ }
+ } // namespace std
+ int a;
+ int
+ main ()
+ {
+   std::unique_ptr p = std::make_unique((long)&a);
+   constexpr std::unique_ptr p2 = std::make_unique((long)&a); // { dg-error "conversion" }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-try1.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-try1.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-try1.C	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-try1.C	Fri Sep  4 07:35:09 2026
*************** struct S {
*** 32,37 ****
--- 32,38 ----
      } catch (int) {	// { dg-error "compound-statement in 'constexpr' function" "" { target c++11_only } }
      }			// { dg-error "compound-statement in 'constexpr' function" "" { target c++11_only } .-2 }
    } catch (...) {	// { dg-error "'constexpr' constructor does not have empty body" "" { target c++11_only } }
+ 		        // { dg-error "compound-statement in 'constexpr' function" "" { target c++11_only } .-1 }
    }
    int m;
  };
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-try2.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-try2.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-try2.C	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-try2.C	Fri Sep  4 07:35:09 2026
*************** struct S {
*** 32,38 ****
      try {		// { dg-warning "'try' in 'constexpr' function only available with" "" { target c++17_down } }
      } catch (int) {	// { dg-warning "compound-statement in 'constexpr' function" "" { target c++11_only } }
      }			// { dg-warning "compound-statement in 'constexpr' function" "" { target c++11_only } .-2 }
!   } catch (...) {	// { dg-error "'constexpr' constructor does not have empty body" "" { target c++11_only } }
    }
    int m;
  };
--- 32,39 ----
      try {		// { dg-warning "'try' in 'constexpr' function only available with" "" { target c++17_down } }
      } catch (int) {	// { dg-warning "compound-statement in 'constexpr' function" "" { target c++11_only } }
      }			// { dg-warning "compound-statement in 'constexpr' function" "" { target c++11_only } .-2 }
!   } catch (...) {	// { dg-warning "'constexpr' constructor does not have empty body" "" { target c++11_only } }
! 			// { dg-warning "compound-statement in 'constexpr' function" "" { target c++11_only } .-1 }
    }
    int m;
  };
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-try3.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-try3.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/constexpr-try3.C	Thu Jun  5 16:02:59 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/constexpr-try3.C	Fri Sep  4 07:35:09 2026
*************** struct S {
*** 31,37 ****
      try {		// { dg-warning "'try' in 'constexpr' function only available with" "" { target c++17_down } }
      } catch (int) {
      }
!   } catch (...) {	// { dg-error "'constexpr' constructor does not have empty body" "" { target c++11_only } }
    }
    int m;
  };
--- 31,37 ----
      try {		// { dg-warning "'try' in 'constexpr' function only available with" "" { target c++17_down } }
      } catch (int) {
      }
!   } catch (...) {	// { dg-warning "'constexpr' constructor does not have empty body" "" { target c++11_only } }
    }
    int m;
  };
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated16.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated16.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated16.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated16.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,20 ----
+ // PR c++/126483
+ // { dg-do compile { target c++17 } }
+ 
+ struct A {
+   int m;
+   constexpr A(int n) : m(__builtin_is_constant_evaluated() ? 42 : n) { }
+ };
+ 
+ constexpr auto v = [] {
+   A a = 0;
+   return a.m;
+ };
+ static_assert(v() == 42);
+ 
+ template
+ constexpr auto vt = [] {
+   A a = 0;
+   return a.m;
+ };
+ static_assert(vt() == 42);
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/lambda-uneval26.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,10 ----
+ // PR c++/116960
+ // { dg-do compile { target c++20 } }
+ 
+ template
+ using Foo = decltype([](auto) { return 0; }(0));
+ 
+ template
+ Foo<[] {}> foo() {}   // { dg-warning "no return statement" }
+ 
+ auto t = foo();
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/pr123578.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/pr123578.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/cpp2a/pr123578.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/cpp2a/pr123578.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,9 ----
+ // PR c++/123578
+ // { dg-do compile { target c++20 } }
+ // { dg-options "-fdump-tree-all" }
+ 
+ namespace {
+   template 
+   struct A { A (decltype ([] { return 0; } ())) {} };
+   A  b = 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/dfp/pr122834-1.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/dfp/pr122834-1.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/dfp/pr122834-1.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/dfp/pr122834-1.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,17 ----
+ // PR c++/122834
+ // { dg-do compile { target { c++11 && float128 } } }
+ // { dg-options "" }
+ // { dg-add-options float128 }
+ 
+ typedef decltype (0.0DL) A;
+ typedef _Float128 B;
+ void bar (A);			// { dg-message "initializing argument 1 of" }
+ 
+ void
+ foo (B x)
+ {
+   bar (x);			// { dg-warning "with unordered conversion rank" }
+ }
+ 
+ auto a = 0.0DL + 1.0F128;	// { dg-error "invalid operands to binary \\\+" }
+ auto b = 1.0F128 + 0.0DL;	// { dg-error "invalid operands to binary \\\+" }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/dfp/pr122834-2.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/dfp/pr122834-2.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/dfp/pr122834-2.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/dfp/pr122834-2.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,19 ----
+ // PR c++/122834
+ // { dg-do compile { target { c++11 && float16 } } }
+ // { dg-options "" }
+ // { dg-add-options float16 }
+ 
+ typedef decltype (0.0DL) A;
+ typedef _Float16 B;
+ void bar (A);
+ 
+ void
+ foo (B x)
+ {
+   bar (x);
+ }
+ 
+ auto a = 0.0DL + 1.0F16;
+ auto b = 1.0F16 + 0.0DL;
+ static_assert (__is_same_as (decltype (0.0DL + 1.0F16), decltype (0.0DL)));
+ static_assert (__is_same_as (decltype (1.0F16 + 0.0DL), decltype (0.0DL)));
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/gomp/pr121977.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/gomp/pr121977.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/gomp/pr121977.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/gomp/pr121977.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,17 ----
+ // PR c++/121977
+ // { dg-do compile }
+ // { dg-additional-options "-ftrivial-auto-var-init=zero" }
+ 
+ struct T { T () {}; virtual ~T () {}; int t; };
+ struct S : virtual public T { int a; void foo (); };
+ 
+ void
+ S::foo ()
+ {
+ #pragma omp parallel
+   {
+     #pragma omp taskloop firstprivate (a, t) lastprivate (t)
+     for (int i = 0; i < a; i++)
+       t++;
+   }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/ipa/pr106260.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/ipa/pr106260.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/ipa/pr106260.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/ipa/pr106260.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,64 ----
+ // { dg-do compile }
+ // { dg-options "-O2 -std=gnu++14 -fwhole-program -fno-unit-at-a-time" }
+ 
+ struct A;
+ template 
+ struct Q { Q (T); };
+ template
+ struct U {
+   ~U () { m1 (nullptr); }
+   D m2 ();
+   T *u;
+   void m1 (T *) { m2 () (u); }
+ };
+ struct F { F (int *); };
+ template 
+ using W = Q;
+ int a, b;
+ void fn1 (void *);
+ template 
+ void
+ fn2 (T *x)
+ {
+   if (x)
+     x->~T();
+   fn1 (x);
+ }
+ template 
+ struct C {
+   void operator() (T *x) { fn2 (x); }
+ };
+ struct D;
+ template  >
+ using V = U;
+ struct A {
+   A (int *);
+ };
+ struct S;
+ struct G {
+   V m3 ();
+ };
+ struct S {
+   int e;
+   virtual ~S () {}
+ };
+ template
+ struct H {
+   H (int, T x, int) : h(x) {}
+   G g;
+   void m4 () { g.m3 (); }
+   T h;
+ };
+ struct I {
+   I(A, W);
+ };
+ void
+ test ()
+ {
+   A c (&b);
+   W d (&b);
+   I e (c, d);
+   H f (0, e, a);
+   f.m4 ();
+ }
+ 
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/ipa/pr122856.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/ipa/pr122856.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/ipa/pr122856.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/ipa/pr122856.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,26 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O3 -std=gnu++11" } */
+ 
+ template 
+ class Base {
+ public:
+     virtual int get();
+     virtual ~Base() = default;
+ };
+ 
+ template 
+ class Derived : public Base {
+ public:
+     int get() override { return Base::get(); }
+ };
+ 
+ template 
+ int Base::get() {
+ 
+     return static_cast*>(this)->get();
+ }
+ 
+ int main() {
+     Derived d;
+     return d.get();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/opt/20260703-1.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/opt/20260703-1.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/opt/20260703-1.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/opt/20260703-1.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,46 ----
+ // This started to be miscompiled with r15-579 or in a larger
+ // test with r15-3956 and got fixed with r17-2039.
+ // DSE would optimize away the store of 42.
+ // { dg-do run { target c++11 } }
+ // { dg-options "-O2" }
+ 
+ struct B { };
+ 
+ void *volatile g;
+ 
+ template 
+ struct D { T foo (void) const { return (T) g; } };
+ 
+ struct G : public B
+ {
+   virtual B *bar (int);
+   struct H : public B { H () : h (42) {} int h; };
+   struct I : public B {};
+   D  g;
+ };
+ 
+ struct H : public G { virtual B *bar (int) { return nullptr; } };
+ 
+ B *
+ G::bar (int x)
+ {
+   if (x == 0)
+     return new H ();
+   I *y = g.foo ();
+   return y;
+ }
+ 
+ [[gnu::noipa]] B *
+ baz (G *x, int y)
+ {
+   return x->bar (y);
+ }
+ 
+ int
+ main ()
+ {
+   G g;
+   G::H *h = (G::H *) baz (&g, 0);
+   if (h->h != 42)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/opt/pr122394.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/opt/pr122394.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/opt/pr122394.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/opt/pr122394.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,20 ----
+ // PR tree-optimization/122394
+ // { dg-do compile { target c++23 } }
+ // { dg-options "-O1 -g" }
+ 
+ #include 
+ 
+ struct A {
+   friend auto operator<=> (A, A) = default;
+   double a;
+ };
+ void foo ();
+ A b, c;
+ 
+ void
+ bar ()
+ {
+   bool d = c >= b;
+   if (d)
+     foo ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/other/anon-union8.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/other/anon-union8.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/other/anon-union8.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/other/anon-union8.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,11 ----
+ // PR c++/124850
+ // { dg-do compile }
+ 
+ static union { int i; };
+ int &r = i;
+ 
+ int
+ foo ()
+ {
+   return r;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/parse/crash81.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/parse/crash81.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/parse/crash81.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/parse/crash81.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,14 ----
+ // PR c++/120876
+ // { dg-do compile { target c++11 } }
+ 
+ template 
+ struct S {
+   static bool foo (decltype (bar (T {})));	// { dg-error "'bar' was not declared in this scope; did you mean 'baz'\\\?" }
+   static constexpr bool s = foo (0);
+ };
+ 
+ void
+ baz ()
+ {
+   S ::s;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/parse/pr120471.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/parse/pr120471.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/parse/pr120471.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/parse/pr120471.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,42 ----
+ // PR c++/120471
+ // { dg-do compile }
+ 
+ extern int a1[], a2[], a3[], a4[];
+ 
+ int corge (int);
+ 
+ int
+ foo (int p)
+ {
+   return (p ? a1 : a2)[1];
+ }
+ 
+ int
+ bar (int p, int q)
+ {
+   return (p ? a1 : a2)[q];
+ }
+ 
+ int
+ garply (int p, int q)
+ {
+   return (p ? a1 : a2)[corge (q)];
+ }
+ 
+ int
+ baz (int p, int q)
+ {
+   return (p ? q ? a1 : a2 : q ? a3 : a4)[1];
+ }
+ 
+ int
+ qux (int p, int q, int r)
+ {
+   return (p ? q ? a1 : a2 : q ? a3 : a4)[r];
+ }
+ 
+ int
+ fred (int p, int q, int r)
+ {
+   return (p ? q ? a1 : a2 : q ? a3 : a4)[corge (r)];
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/parse/pr120940.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/parse/pr120940.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/parse/pr120940.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/parse/pr120940.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,18 ----
+ // PR c++/120940
+ // { dg-do run }
+ 
+ int a[8] = { 1, 2, 3, 4, 5, 6, 7, 8 };
+ int b[8] = { 9, 10, 11, 12, 13, 14, 15, 16 };
+ 
+ __attribute__((noipa)) int
+ foo (int x, int y)
+ {
+   return (x ? a : b)[y];
+ }
+ 
+ int
+ main ()
+ {
+   if (foo (1, 4) != 5 || foo (0, 6) != 15)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/template/bitfield5.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/template/bitfield5.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/template/bitfield5.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/template/bitfield5.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,16 ----
+ // PR c++/125674
+ // { dg-do compile { target c++20 } }
+ 
+ struct A { int a : 1.; };	// { dg-error "width of bit-field 'a' has non-integral type 'double'" }
+ template 
+ struct B { int b : 1.; };	// { dg-error "width of bit-field 'b' has non-integral type 'double'" }
+ template 
+ struct C { T c : 1.; };		// { dg-error "width of bit-field 'c' has non-integral type 'double'" }
+ template 
+ struct D { int d : N; };	// { dg-error "width of bit-field 'D::d' has non-integral type 'double'" }
+ template 
+ struct E { T e : N; };		// { dg-error "width of bit-field 'E::e' has non-integral type 'double'" }
+ B  b;
+ C  c;
+ D <1.> d;
+ E  e;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/template/bitfield6.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/template/bitfield6.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/template/bitfield6.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/template/bitfield6.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,9 ----
+ // PR c++/125674
+ // { dg-do compile }
+ 
+ template 
+ struct A {
+   int f ();
+   int i : f;	// { dg-error "width of bit-field 'A::i' has non-integral type ''" }
+ };
+ A a;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/template/fn-ptr6.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/template/fn-ptr6.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/template/fn-ptr6.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/template/fn-ptr6.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,26 ----
+ // PR c++/126280
+ // A version of fn-ptr3a.C where the template parameter is a pack.
+ // { dg-do compile { target c++11 } }
+ 
+ template
+ void f(T) { T::fail; } // { dg-error "fail" }
+ 
+ template
+ struct A {
+   // P not called
+ };
+ 
+ template
+ void wrap() {
+   // P not called
+ }
+ 
+ template
+ void g() {
+   A a; // { dg-message "required from" }
+   wrap(); // { dg-message "required from" }
+ }
+ 
+ int main() {
+   g<0>();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr112400.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr112400.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr112400.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr112400.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,114 ----
+ /* { dg-do compile } */
+ /* { dg-options "-Wno-return-type" } */
+ 
+ typedef struct a *b;
+ template  c e(d);
+ enum f { g, h, i };
+ enum j { k, l, m, aa };
+ struct a {
+   f ab;
+ };
+ struct af {
+ } n;
+ struct ah;
+ class al;
+ b q;
+ void r(a *);
+ struct o : af {};
+ struct p : o {};
+ struct ag : p {};
+ j s(af *);
+ b t();
+ f fn4();
+ unsigned fn5(ag *);
+ b u(ag *, unsigned);
+ af *v(b(b), b);
+ static bool w(al *, af *, b(b), b aw, b *ax, j) {
+   r(ax[2]);
+   if (aw)
+     return false;
+ }
+ ag *ay;
+ void x(al *at, b as(b), b bb, b bc) {
+   switch (bb->ab)
+   case i:
+     if (af *bd = v(as, bb))
+       if (e(bd))
+ 	switch (fn4())
+ 	case h: {
+ 	  b be;
+ 	  switch (be->ab)
+ 	  case i:
+ 	    if (af *bf = v(as, be))
+ 	      if (e(bf))
+ 		if (ag *bg = e(bf))
+ 		  switch (s(bg)) {
+ 		  case k:
+ 		    if (fn5(bg) == 1) {
+ 		      b bh = u(bg, 0);
+ 		      bh = t();
+ 		      switch (bc->ab)
+ 		      case g: {
+ 			b ax[]{be, bh, bc};
+ 			w(at, &n, as, q, ax, k);
+ 		      }
+ 		    }
+ 		    break;
+ 		  case l:
+ 		    if (fn5(bg) == 1) {
+ 		      b bh = u(bg, 0);
+ 		      bh = t();
+ 		      switch (bc->ab)
+ 		      case g: {
+ 			b ax[]{be, bh, bc};
+ 			w(at, &n, as, q, ax, l);
+ 		      }
+ 		    }
+ 		  }
+ 	}
+ 	  else switch (s(ay)) {
+ 	  case k:
+ 	    if (fn5(ay) == 1) {
+ 	      b be = u(ay, 0);
+ 	      be = t();
+ 	      switch (bc->ab)
+ 	      case g: {
+ 		b ax[]{bb, be, bc};
+ 		w(at, &n, as, q, ax, k);
+ 	      }
+ 	    }
+ 	    break;
+ 	  case l:
+ 	    if (fn5(ay) == 1) {
+ 	      b be = u(ay, 0);
+ 	      be = t();
+ 	      switch (bc->ab)
+ 	      case g: {
+ 		b ax[]{bb, be, bc};
+ 		w(at, &n, as, q, ax, l);
+ 	      }
+ 	    }
+ 	    break;
+ 	  case m:
+ 	    if (fn5(ay) == 1) {
+ 	      b be = u(ay, 0);
+ 	      be = t();
+ 	      switch (bc->ab)
+ 	      case g: {
+ 		b ax[]{bb, be, bc};
+ 		w(at, &n, as, q, ax, m);
+ 	      }
+ 	    }
+ 	    break;
+ 	  case aa:
+ 	    if (fn5(ay) == 1) {
+ 	      b be = u(ay, 0);
+ 	      be = t();
+ 	      switch (bc->ab)
+ 	      case g: {
+ 		b ax[]{bb, be, bc};
+ 		w(at, &n, as, q, ax, aa);
+ 	      }
+ 	    }
+ 	  }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr117217-1.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr117217-1.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr117217-1.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr117217-1.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,24 ----
+ struct [[gnu::packed]] A {
+   int i;
+   bool b;
+ };
+ 
+ struct [[gnu::packed]] B {
+   int i;
+   bool b : 1;
+ };
+ 
+ struct E {
+   union Data {
+     A a;
+     B b;
+     Data(const B &b) : b(b) {}
+   } data;
+ };
+ 
+ extern B copy;
+ 
+ int main() {
+   E e{{B()}};
+   copy = e.data.b; // NEEDED FOR ICE
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr117217-2.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr117217-2.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr117217-2.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr117217-2.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,24 ----
+ struct a {
+   int b;
+   long c;
+   long d;
+   bool f;
+ };
+ struct g {
+   int b;
+   long c;
+   long d;
+   bool : 1;
+ } h;
+ struct l {
+   union i {
+     a j;
+     g k;
+     i(g m) : k(m) {}
+   } data;
+ };
+ int main() {
+   l e{g()};
+   h = e.data.k;
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr120987-1.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr120987-1.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr120987-1.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr120987-1.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,56 ----
+ // { dg-do run { target c++11 } }
+ // PR tree-optimization/120987
+ 
+ #include 
+ #include 
+ #include 
+ 
+ #define ERROR_STRING  "012345678901234567"
+ 
+ struct gdb_exception
+ {
+   gdb_exception (const char *s)
+     : message (std::make_shared (s))
+   {}
+ 
+   explicit gdb_exception (gdb_exception &&other) noexcept
+     : message (std::move (other.message))
+   {
+     volatile int a = 1;
+     if (a != 1)
+       abort ();
+   }
+   
+ 
+   std::shared_ptr message;
+ };
+ 
+ void __attribute__((noinline, noclone))
+ throw_exception (gdb_exception &&exception)
+ {
+   throw gdb_exception (std::move (exception));
+ }
+ 
+ static void __attribute__((noinline, noclone))
+ parse_linespec (void)
+ {
+   struct gdb_exception file_exception (ERROR_STRING);
+   throw_exception (std::move (file_exception));
+ }
+ 
+ int
+ main (void)
+ {
+   try
+     {
+       parse_linespec ();
+     }
+   catch (const gdb_exception &e)
+     {
+       if (*e.message != ERROR_STRING)
+         __builtin_abort();
+       return 0;
+     }
+ 
+   __builtin_abort();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr121870.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr121870.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr121870.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr121870.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,20 ----
+ __attribute__((noreturn)) void f1(void)
+ {
+     while(true) {}
+ }
+ static void (*fptr)(void) = f1;
+ struct s1
+ {
+     ~s1() {
+         fptr();
+     }
+     void DoInner() {
+         fptr();
+     }
+ };
+ 
+ void f()
+ {
+     s1 xxx;
+     xxx.DoInner();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr123603.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr123603.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr123603.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr123603.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,20 ----
+ // { dg-do compile }
+ 
+ void _setjmp();
+ void a() __attribute__((__noreturn__));
+ struct b {
+   b(int c) {
+     if (c)
+       a();
+   }
+   ~b();
+ };
+ int d;
+ void l(long);
+ void e() {
+   b a(d);
+   for (int f = 0; f < 10 ; ++f) {
+     l(f - 1);
+     _setjmp();
+   }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr124130.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr124130.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr124130.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr124130.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,15 ----
+ // { dg-do compile }
+ 
+ void __sigsetjmp_cancel() __attribute__((__returns_twice__));
+ struct basic_ostream {
+   basic_ostream &operator<<(basic_ostream &__pf(basic_ostream &)) {
+     return __pf(*this);
+   }
+ } cerr;
+ extern "C" void _exit(int);
+ enum { Exit_Internal_Error };
+ basic_ostream &report_error(basic_ostream &) { _exit(Exit_Internal_Error); }
+ void thread_pool_thread_main() {
+   __sigsetjmp_cancel();
+   cerr << report_error;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr124135-1.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr124135-1.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr124135-1.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr124135-1.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,20 ----
+ // PR tree-optimization/124135
+ // { dg-do compile }
+ 
+ void foo (char, long double *, int);
+ int qux (int);
+ 
+ long double
+ bar (int x)
+ {
+   long double a;
+   if (x)
+     foo (0, &a, qux (42));
+   return a;
+ }
+ 
+ void
+ baz (int x)
+ {
+   bar (x);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr124135-2.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr124135-2.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/torture/pr124135-2.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/torture/pr124135-2.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,27 ----
+ // PR tree-optimization/124135
+ // { dg-do compile }
+ 
+ #ifdef __SIZEOF_FLOAT128__
+ void foo (char, __float128 *, int);
+ int qux (int);
+ 
+ __float128
+ bar (int x)
+ {
+   __float128 a;
+   if (x)
+     foo (0, &a, qux (42));
+   return a;
+ }
+ 
+ void
+ baz (int x)
+ {
+   bar (x);
+ }
+ #else
+ void
+ baz ()
+ {
+ }
+ #endif
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/ubsan/pr120471.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/ubsan/pr120471.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/ubsan/pr120471.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/ubsan/pr120471.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,21 ----
+ // PR c++/120471
+ // { dg-do run }
+ // { dg-options "-fsanitize=undefined" }
+ 
+ volatile int b[1], a[1];
+ 
+ void
+ foo (int x)
+ {
+   volatile int c = 21;
+   volatile int v = (x % 2 ? b : a)[c % 3];
+   if (v != 0)
+     __builtin_abort ();
+ }
+ 
+ int
+ main ()
+ {
+   foo (1);
+   foo (2);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/warn/Wduplicated-branches9.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/warn/Wduplicated-branches9.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/warn/Wduplicated-branches9.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/warn/Wduplicated-branches9.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,11 ----
+ // PR c++/120940
+ // { dg-do compile }
+ // { dg-options "-Wduplicated-branches" }
+ 
+ static char a[16][8], b[16][8];
+ 
+ char *
+ foo (int x, int y)
+ {
+   return (x ? a : b)[y];
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/warn/Wmismatched-new-delete-10.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/warn/Wmismatched-new-delete-10.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/warn/Wmismatched-new-delete-10.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/warn/Wmismatched-new-delete-10.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,25 ----
+ // PR tree-optimization/123513
+ // { dg-do compile }
+ // { dg-options "-Wmismatched-new-delete" }
+ 
+ typedef __SIZE_TYPE__ size_t;
+ 
+ template 
+ class A {};
+ struct B { B (); };
+ 
+ template 
+ void *operator new (size_t, A  &);
+ 
+ template 
+ void operator delete (void *, A  &);
+ 
+ void
+ foo (B *, A <1024> &);
+ 
+ void
+ bar ()
+ {
+   A <1024> a;
+   foo (new (a) B (), a);	// { dg-bogus "called on pointer returned from a mismatched allocation function" }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.dg/warn/undefined2.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/warn/undefined2.C
*** gcc-13.4.0/gcc/testsuite/g++.dg/warn/undefined2.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.dg/warn/undefined2.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,14 ----
+ // PR c++/119303
+ 
+ template  struct c {
+   enum { d = 4 };
+ };
+ template  struct e {
+   typedef void g;
+ };
+ template 
+ inline typename e::d>::g bar(_Tp); // { dg-warning "used but never defined" }
+ 
+ int x;
+ 
+ void foo() { bar(x); }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.target/aarch64/sve/pr121449.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/aarch64/sve/pr121449.C
*** gcc-13.4.0/gcc/testsuite/g++.target/aarch64/sve/pr121449.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/aarch64/sve/pr121449.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,44 ----
+ /* PR target/121449 */
+ /* { dg-do assemble { target aarch64_asm_sve_ok } } */
+ /* { dg-options "-O3 -save-temps" } */
+ 
+ struct example;
+ 
+ struct array {
+   unsigned length();
+   example *operator[](unsigned i) {
+     example **data = reinterpret_cast(this);
+     return data[i];
+   }
+ };
+ 
+ struct example {
+   int a[16];
+   bool is_even;
+   int version;
+   int count() { return is_even ? 2 : 1; }
+   void fun1(int, long);
+   void fun2(unsigned, unsigned);
+   void process(array &, array &);
+ };
+ 
+ bool found;
+ 
+ void example::process(array &a, array &b) {
+   for (unsigned i = 1; a.length(); i++) {
+     long total = 0;
+     for (unsigned k = 0; k <= i; k++) {
+       total += a[k]->count();
+     }
+     for (unsigned j = 0; j < i; j++) {
+       int major = b[j]->version;
+       if (found)
+         major += i;
+       fun1(i + 1, total);
+       fun2(j, major);
+     }
+   }
+ }
+ 
+ /* { dg-final { scan-assembler-not {\tld1b\t(z[0-9]+)\.d, p[0-7]/z, \[(z[0-9]+)\.d, #64\]} } } */
+ 
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-1.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-1.C
*** gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-1.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-1.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,17 ----
+ /* { dg-do compile { target { ! ia32 } } } */
+ /* { dg-options "-mamx-tile -mamx-int8 -O0" } */
+ /* { dg-final { scan-assembler "tdpbssd\[ \\t]+\[^\n\]*%tmm2+\[^\n\]*%tmm1+\[^\n\]*%tmm0" } } */
+ 
+ #include 
+ 
+ template 
+ struct dpbssd
+ {
+   void operator()() { _tile_dpbssd(hello, crazy, gcc); }
+ };
+ 
+ void f()
+ {
+   dpbssd<0, 1, 2>()();
+ }
+ 
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-amxbf16.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-amxbf16.C
*** gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-amxbf16.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-amxbf16.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,16 ----
+ /* { dg-do compile { target { ! ia32 } } } */
+ /* { dg-options "-mamx-tile -mamx-bf16 -O0" } */
+ /* { dg-final { scan-assembler "tdpbf16ps\[ \\t]+%tmm2,\[ \\t\]*%tmm1,\[ \\t\]*%tmm0" } } */
+ 
+ #include 
+ 
+ template 
+ struct dpbf16ps
+ {
+   void operator()() { _tile_dpbf16ps(dst, src1, src2); }
+ };
+ 
+ void test_amx_bf16()
+ {
+   dpbf16ps<0, 1, 2>()();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-amxcomplex.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-amxcomplex.C
*** gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-amxcomplex.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-amxcomplex.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,24 ----
+ /* { dg-do compile { target { ! ia32 } } } */
+ /* { dg-options "-mamx-tile -mamx-complex -O0" } */
+ /* { dg-final { scan-assembler "tcmmimfp16ps\[ \\t]+%tmm2,\[ \\t\]*%tmm1,\[ \\t\]*%tmm0" } } */
+ /* { dg-final { scan-assembler "tcmmrlfp16ps\[ \\t]+%tmm5,\[ \\t\]*%tmm4,\[ \\t\]*%tmm3" } } */
+ 
+ #include 
+ 
+ template 
+ struct cmmimfp16ps
+ {
+   void operator()() { _tile_cmmimfp16ps(dst, src1, src2); }
+ };
+ 
+ template 
+ struct cmmrlfp16ps
+ {
+   void operator()() { _tile_cmmrlfp16ps(dst, src1, src2); }
+ };
+ 
+ void test_amx_complex()
+ {
+   cmmimfp16ps<0, 1, 2>()();
+   cmmrlfp16ps<3, 4, 5>()();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-amxfp16.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-amxfp16.C
*** gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-amxfp16.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-amxfp16.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,16 ----
+ /* { dg-do compile { target { ! ia32 } } } */
+ /* { dg-options "-mamx-tile -mamx-fp16 -O0" } */
+ /* { dg-final { scan-assembler "tdpfp16ps\[ \\t]+%tmm2,\[ \\t\]*%tmm1,\[ \\t\]*%tmm0" } } */
+ 
+ #include 
+ 
+ template 
+ struct dpfp16ps
+ {
+   void operator()() { _tile_dpfp16ps(dst, src1, src2); }
+ };
+ 
+ void test_amx_fp16()
+ {
+   dpfp16ps<0, 1, 2>()();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-amxint8.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-amxint8.C
*** gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-amxint8.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-amxint8.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,40 ----
+ /* { dg-do compile { target { ! ia32 } } } */
+ /* { dg-options "-mamx-tile -mamx-int8 -O0" } */
+ /* { dg-final { scan-assembler "tdpbssd\[ \\t]+%tmm2,\[ \\t\]*%tmm1,\[ \\t\]*%tmm0" } } */
+ /* { dg-final { scan-assembler "tdpbsud\[ \\t]+%tmm5,\[ \\t\]*%tmm4,\[ \\t\]*%tmm3" } } */
+ /* { dg-final { scan-assembler "tdpbusd\[ \\t]+%tmm2,\[ \\t\]*%tmm1,\[ \\t\]*%tmm6" } } */
+ /* { dg-final { scan-assembler "tdpbuud\[ \\t]+%tmm1,\[ \\t\]*%tmm0,\[ \\t\]*%tmm7" } } */
+ 
+ #include 
+ 
+ template 
+ struct dpbssd
+ {
+   void operator()() { _tile_dpbssd(dst, src1, src2); }
+ };
+ 
+ template 
+ struct dpbsud
+ {
+   void operator()() { _tile_dpbsud(dst, src1, src2); }
+ };
+ 
+ template 
+ struct dpbusd
+ {
+   void operator()() { _tile_dpbusd(dst, src1, src2); }
+ };
+ 
+ template 
+ struct dpbuud
+ {
+   void operator()() { _tile_dpbuud(dst, src1, src2); }
+ };
+ 
+ void test_amx_int8()
+ {
+   dpbssd<0, 1, 2>()();
+   dpbsud<3, 4, 5>()();
+   dpbusd<6, 1, 2>()();
+   dpbuud<7, 0, 1>()();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-amxtile.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-amxtile.C
*** gcc-13.4.0/gcc/testsuite/g++.target/i386/pr122446-amxtile.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr122446-amxtile.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,50 ----
+ /* { dg-do compile { target { ! ia32 } } } */
+ /* { dg-options "-mamx-tile -O0" } */
+ /* { dg-final { scan-assembler "tileloadd\[ \\t]+\[^\n\]*,\[ \\t\]*%tmm0" } } */
+ /* { dg-final { scan-assembler "tilestored\[ \\t]+%tmm1," } } */
+ /* { dg-final { scan-assembler "tilezero\[ \\t]+%tmm3" } } */
+ /* { dg-final { scan-assembler "tileloaddt1\[ \\t]+\[^\n\]*,\[ \\t\]*%tmm2" } } */
+ 
+ #include 
+ 
+ template 
+ struct tile_loadd_test
+ {
+   void operator()(const void* base, int stride)
+   {
+     _tile_loadd(tmm_num, base, stride);
+   }
+ };
+ 
+ template 
+ struct tile_stored_test
+ {
+   void operator()(void* base, int stride)
+   {
+     _tile_stored(tmm_num, base, stride);
+   }
+ };
+ 
+ template 
+ struct tile_zero_test
+ {
+   void operator()() { _tile_zero(tmm_num); }
+ };
+ 
+ template 
+ struct tile_stream_loadd_test
+ {
+   void operator()(const void* base, int stride)
+   {
+     _tile_stream_loadd(tmm_num, base, stride);
+   }
+ };
+ 
+ void test_amx_tile()
+ {
+   char buf[1024];
+   tile_loadd_test<0>()(buf, 64);
+   tile_stored_test<1>()(buf, 64);
+   tile_stream_loadd_test<2>()(buf, 64);
+   tile_zero_test<3>()();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.target/i386/pr123779.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr123779.C
*** gcc-13.4.0/gcc/testsuite/g++.target/i386/pr123779.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/i386/pr123779.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,56 ----
+ /* PR target/123779 */
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -mavx512vl -mavx512bw" } */
+ 
+ typedef char __v16qi __attribute__((__vector_size__(16)));
+ typedef short __v8hi __attribute__((__vector_size__(16)));
+ typedef int __v4si __attribute__((__vector_size__(16)));
+ typedef long long __v2di __attribute__((__vector_size__(16)));
+ 
+ typedef int __v8si __attribute__((__vector_size__(32)));
+ typedef long long __v4di __attribute__((__vector_size__(32)));
+ typedef long long __v8di __attribute__((__vector_size__(64)));
+ typedef unsigned char __mmask8;
+ 
+ long long g_mem;
+ 
+ #define MAKE_TEST_BLEND(NAME, DEST_T, SRC_INIT_T, PMOV_INPUT_CAST_T, \
+ 			PMOV_FUNC, BLEND_FUNC, BLEND_CAST_T, LOAD_VAL_TYPE, ...) \
+     DEST_T dest_##NAME, mask_src1_##NAME, mask_src2_##NAME, mask_##NAME, res_##NAME; \
+     void test_##NAME() \
+       { \
+         mask_##NAME = mask_src1_##NAME < mask_src2_##NAME; \
+         LOAD_VAL_TYPE val = (LOAD_VAL_TYPE)g_mem; \
+         SRC_INIT_T src_vec = { __VA_ARGS__ }; \
+         DEST_T extended = (DEST_T)PMOV_FUNC ((PMOV_INPUT_CAST_T)src_vec); \
+         res_##NAME = (DEST_T)BLEND_FUNC ( \
+             (BLEND_CAST_T)dest_##NAME, \
+             (BLEND_CAST_T)extended, \
+             (BLEND_CAST_T)mask_##NAME); \
+       }
+ 
+ #define MAKE_TEST_MASK(NAME, DEST_T, SRC_INIT_T, PMOV_INPUT_CAST_T, \
+ 		       PMOV_MASK_FUNC, LOAD_VAL_TYPE, ...) \
+     DEST_T dest_##NAME, res_##NAME; \
+     __mmask8 mask_##NAME; \
+     void test_##NAME() \
+       { \
+ 	LOAD_VAL_TYPE val = (LOAD_VAL_TYPE) g_mem; \
+ 	SRC_INIT_T src_vec = { __VA_ARGS__ }; \
+ 	res_##NAME = PMOV_MASK_FUNC ((PMOV_INPUT_CAST_T)src_vec, \
+ 				     dest_##NAME, \
+ 				     mask_##NAME);\
+       }  
+ 
+ 
+ MAKE_TEST_BLEND(v8qi_v8hi, __v8hi, __v2di, __v16qi, __builtin_ia32_pmovzxbw128, __builtin_ia32_pblendvb128, __v16qi, long long, val, 0)
+ MAKE_TEST_BLEND(v4qi_v4si, __v4si, __v4si, __v16qi, __builtin_ia32_pmovzxbd128, __builtin_ia32_pblendvb128, __v16qi, int, val, 0, 0, 0)
+ MAKE_TEST_BLEND(v4hi_v4si, __v4si, __v2di, __v8hi, __builtin_ia32_pmovzxwd128, __builtin_ia32_pblendvb128, __v16qi, long long, val, 0)
+ MAKE_TEST_BLEND(v2hi_v2di, __v2di, __v4si, __v8hi, __builtin_ia32_pmovzxwq128, __builtin_ia32_pblendvb128, __v16qi, int, val, 0, 0, 0)
+ MAKE_TEST_BLEND(v2si_v2di, __v2di, __v2di, __v4si, __builtin_ia32_pmovzxdq128, __builtin_ia32_pblendvb128, __v16qi, long long, val, 0)
+ 
+ 
+ MAKE_TEST_MASK(v8qi_v8si, __v8si, __v2di, __v16qi, __builtin_ia32_pmovzxbd256_mask, long long, val, 0)
+ MAKE_TEST_MASK(v4qi_v4di, __v4di, __v4si, __v16qi, __builtin_ia32_pmovzxbq256_mask, int, val, 0, 0, 0)
+ MAKE_TEST_MASK(v4hi_v4di, __v4di, __v2di, __v8hi, __builtin_ia32_pmovzxwq256_mask, long long, val, 0)
+ MAKE_TEST_MASK(v8qi_v8di, __v8di, __v2di, __v16qi, __builtin_ia32_pmovzxbq512_mask, long long, val, 0)
diff -Nrcpad gcc-13.4.0/gcc/testsuite/g++.target/mips/pr126484.C gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/mips/pr126484.C
*** gcc-13.4.0/gcc/testsuite/g++.target/mips/pr126484.C	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/g++.target/mips/pr126484.C	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,8 ----
+ // PR target/126484
+ // { dg-do compile }
+ 
+ int
+ foo ()
+ {
+   return __builtin_mips_get_fcsr ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr105192.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr105192.c
*** gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr105192.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr105192.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,9 ----
+ /* { dg-additional-options "-fno-if-conversion -fharden-compares" } */
+ 
+ int a, b;
+ 
+ void
+ foo (void)
+ {
+   b = a % 0 > 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr116600.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr116600.c
*** gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr116600.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr116600.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,24 ----
+ /* PR rtl-optimization/116600 */
+ 
+ int a, b;
+ int foo ();
+ 
+ int
+ bar ()
+ {
+   int c = ({ int d = 0, e = foo ();
+ 	     b = __builtin_expect (e, 1); if (b) ; else d = 4; d; });
+   if (c)
+     return c;
+   foo ();
+   if (a)
+     __asm__ goto ("" : : : : l);
+ l:
+   return 0;
+ }
+ 
+ void
+ baz ()
+ {
+   bar ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr120250.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr120250.c
*** gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr120250.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr120250.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,38 ----
+ /* PR target/120250 */
+ 
+ int a = 5, b = 7, c, *d;
+ void *l;
+ void foo (const char *s);
+ void bar (void);
+ void qux (const char *, int);
+ 
+ int
+ baz (int *d, int a, int b)
+ {
+   int c = 0;
+   for (int i = 0; i < a; ++i)
+     for (int j = 0; j < b; ++j)
+       c += d[i * b + j];
+   return c;
+ }
+ 
+ int
+ main ()
+ {
+   d = __builtin_malloc (a * b * sizeof (int));
+   if (!d)
+     {
+       foo ("foo");
+       __builtin_exit (1);
+     }
+   for (int i = 0; i < a; ++i)
+     for (int j = 0; j < b; ++j)
+       d[i * b + j] = i * b + j;
+   l = (void *) &bar;
+   goto *l;
+ bar:
+   c = baz (d, a, b);
+   qux ("bar", c);
+   __builtin_free (d);
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr123365.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr123365.c
*** gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr123365.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr123365.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,7 ----
+ /* PR c/123365 */
+ 
+ void
+ foo ()
+ {
+   __asm__ volatile ("" : "+r" ((long long[]) { 0 }));
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr123386.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr123386.c
*** gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr123386.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr123386.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,25 ----
+ /* PR middle-end/123386 */
+ 
+ char *a;
+ int b;
+ 
+ void
+ foo (char *)
+ {
+   if (b)
+     __builtin_abort ();
+ }
+ 
+ void
+ bar (char *c)
+ {
+   __asm__ goto ("" : : : : d);
+   foo (a);
+   __asm__ goto ("" : : : : d);
+   if (c)
+     bar (a);
+   __asm__ goto ("" : : : : d);
+ d:
+   if (b)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr123703.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr123703.c
*** gcc-13.4.0/gcc/testsuite/gcc.c-torture/compile/pr123703.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/compile/pr123703.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,10 ----
+ /* PR middle-end/123703 */
+ 
+ struct S { int a; };
+ struct S abs (int);
+ 
+ struct S
+ bar (int j)
+ {
+   return abs (j);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.c-torture/execute/pr101188.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/execute/pr101188.c
*** gcc-13.4.0/gcc/testsuite/gcc.c-torture/execute/pr101188.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/execute/pr101188.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,61 ----
+ /* { dg-require-effective-target indirect_calls } */
+ typedef __UINT8_TYPE__ uint8_t;
+ typedef __UINT16_TYPE__ uint16_t;
+ 
+ typedef uint8_t (*fn1)(void *a);
+ typedef void (*fn2)(void *a, int *arg);
+ 
+ struct S
+ {
+     uint8_t buffer[64];
+     uint16_t n;
+     fn2 f2;
+     void *a;
+     fn1 f1;
+ };
+ 
+ volatile uint16_t x;
+ 
+ void __attribute__((__noinline__,__noclone__))
+ foo (uint16_t n)
+ {
+   x = n;
+ }
+ 
+ void __attribute__((__noinline__,__noclone__))
+ testfn (struct S *self)
+ {
+     int arg;
+ 
+     foo (self->n);
+     self->n++;
+     self->f2 (self->a, &arg);
+     self->buffer[0] = self->f1 (self->a);
+ }
+ 
+ static unsigned char myfn2_called = 0;
+ 
+ static void
+ myfn2 (void *a, int *arg)
+ {
+   myfn2_called = 1;
+ }
+ 
+ static uint8_t
+ myfn1 (void *a)
+ {
+   return 0;
+ }
+ 
+ int main (void)
+ {
+   struct S s;
+   s.n = 0;
+   s.f2 = myfn2;
+   s.f1 = myfn1;
+   testfn (&s);
+   if (myfn2_called != 1)
+     __builtin_abort();
+   return 0;
+ }
+ 
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.c-torture/execute/pr122000.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/execute/pr122000.c
*** gcc-13.4.0/gcc/testsuite/gcc.c-torture/execute/pr122000.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/execute/pr122000.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,14 ----
+ /* PR target/122000 */
+ 
+ char c = 1;
+ __attribute__((aligned (sizeof (unsigned long long)))) unsigned long long ll;
+ 
+ int
+ main ()
+ {
+ #if defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8) && __SIZEOF_LONG_LONG__ == 8 && __CHAR_BIT__ == 8
+   unsigned long long x = __sync_add_and_fetch (&ll, c + 0xfedcba9876543210ULL);
+   if (x != 0xfedcba9876543211ULL)
+     __builtin_abort ();
+ #endif
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.c-torture/execute/pr123864.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/execute/pr123864.c
*** gcc-13.4.0/gcc/testsuite/gcc.c-torture/execute/pr123864.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/execute/pr123864.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,24 ----
+ /* PR tree-optimization/123864 */
+ 
+ [[gnu::noipa]] static int
+ foo (long long x)
+ {
+   return __builtin_mul_overflow_p (x, ~0U, x);
+ }
+ 
+ int
+ main ()
+ {
+   if (foo (0))
+     __builtin_abort ();
+ #if __SIZEOF_INT__ == 4 && __SIZEOF_LONG_LONG__ == 8 && __CHAR_BIT__ == 8
+   if (foo (__INT_MAX__ + 1LL))
+     __builtin_abort ();
+   if (!foo (__INT_MAX__ + 2LL))
+     __builtin_abort ();
+   if (foo (-__INT_MAX__ - 1LL))
+     __builtin_abort ();
+   if (!foo (-__INT_MAX__ - 2LL))
+     __builtin_abort ();
+ #endif
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.c-torture/execute/pr124358.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/execute/pr124358.c
*** gcc-13.4.0/gcc/testsuite/gcc.c-torture/execute/pr124358.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.c-torture/execute/pr124358.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,19 ----
+ /* PR tree-optimization/124358 */
+ 
+ [[gnu::noipa]] void
+ foo (int d)
+ {
+   static int u = 11;
+   if (d != u++)
+     __builtin_abort ();
+ }
+ 
+ int
+ main ()
+ {
+   int a[1][4] = { 11, 12, 13, 14 };
+   int (*p)[4] = a;
+   for (int i = 0; i < 1; i++)
+     for (int j = 0; j < 4; j++)
+       foo (*(*(p + i) + j));
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/complex-10.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/complex-10.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/complex-10.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/complex-10.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,16 ----
+ /* { dg-do compile } */
+ /* { dg-options "" } */
+ 
+ /* PR c/105555 */
+ 
+ struct C {
+   __complex int i;
+ };
+ struct C p[10];
+ int *foo1(void) {
+   return &__real(p->i);
+ }
+ 
+ int *foo2(void) {
+   return &__imag(p->i);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/darwin-minversion-link.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/darwin-minversion-link.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/darwin-minversion-link.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/darwin-minversion-link.c	Fri Sep  4 07:35:09 2026
***************
*** 19,24 ****
--- 19,26 ----
  /* { dg-additional-options "-mmacosx-version-min=012.000.00 -DCHECK=120000" { target *-*-darwin21* } } */
  /* { dg-additional-options "-mmacosx-version-min=013.000.00 -DCHECK=130000" { target *-*-darwin22* } } */
  /* { dg-additional-options "-mmacosx-version-min=014.000.00 -DCHECK=140000" { target *-*-darwin23* } } */
+ /* { dg-additional-options "-mmacosx-version-min=015.000.00 -DCHECK=150000" { target *-*-darwin24* } } */
+ /* { dg-additional-options "-mmacosx-version-min=026.000.00 -DCHECK=260000" { target *-*-darwin25* } } */
  
  int
  main ()
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/gomp/pr121453.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/gomp/pr121453.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/gomp/pr121453.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/gomp/pr121453.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,18 ----
+ /* PR middle-end/121453 */
+ /* { dg-do compile } */
+ /* { dg-options "-fopenmp -O2 -Wuninitialized" } */
+ 
+ void bar (int, int, int);
+ int v[40][40][40];
+ 
+ void
+ foo (int x, int y, int z)
+ {
+   int i, j, k;
+ #pragma omp parallel for simd collapse(3)
+   for (k = 1; k <= z; ++k)
+     for (j = 2; j <= y - 1; ++j)
+       for (i = 1; i <= x; ++i)
+ 	v[i][j][k] = 0;
+   bar (i, j, k);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/gomp/pr123876.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/gomp/pr123876.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/gomp/pr123876.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/gomp/pr123876.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,69 ----
+ /* PR middle-end/123876 */
+ 
+ void
+ foo ()
+ {
+ lab:
+ #pragma omp simd
+   for (int i = 0; i < 4; i++)
+     asm goto ("" : : : : lab);			/* { dg-error "invalid branch to/from OpenMP structured block" } */
+ #pragma omp for
+   for (int i = 0; i < 4; i++)
+    asm goto ("" : : : : lab);			/* { dg-error "invalid branch to/from OpenMP structured block" } */
+ #pragma omp parallel
+   asm goto ("" : : : : lab);			/* { dg-error "invalid branch to/from OpenMP structured block" } */
+ }
+ 
+ void
+ bar ()
+ {
+ lab3:
+ #pragma omp simd
+   for (int i = 0; i < 4; i++)
+     {
+     lab1:
+     lab2:
+       asm goto ("" : : : : lab1, lab2, lab3);	/* { dg-error "invalid branch to/from OpenMP structured block" } */
+     }
+ #pragma omp for
+   for (int i = 0; i < 4; i++)
+     {
+     lab4:
+     lab5:
+       asm goto ("" : : : : lab4, lab5, lab3);	/* { dg-error "invalid branch to/from OpenMP structured block" } */
+     }
+ #pragma omp parallel
+   {
+   lab6:
+   lab7:
+     asm goto ("" : : : : lab6, lab7, lab3);	/* { dg-error "invalid branch to/from OpenMP structured block" } */
+   }
+ }
+ 
+ void
+ baz ()
+ {
+ #pragma omp simd
+   for (int i = 0; i < 4; i++)
+     {
+     lab1:
+     lab2:
+       asm goto ("" : : : : lab1, lab2, lab3);
+     lab3:;
+     }
+ #pragma omp for
+   for (int i = 0; i < 4; i++)
+     {
+     lab4:
+     lab5:
+       asm goto ("" : : : : lab4, lab5, lab6);
+     lab6:;
+     }
+ #pragma omp parallel
+   {
+   lab7:
+   lab8:
+     asm goto ("" : : : : lab7, lab8, lab9);
+   lab9:;
+   }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/lto/attr-weakref-2_0.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/lto/attr-weakref-2_0.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/lto/attr-weakref-2_0.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/lto/attr-weakref-2_0.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,11 ----
+ /* { dg-lto-do link } */
+ /* { dg-lto-options {{-O2 -flto}} } */
+ 
+ #define __weak __attribute__((__weak__))
+ void __weak other() {}
+ void __weak fn() {}
+ 
+ int main() {
+   fn();
+   other();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/lto/attr-weakref-2_1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/lto/attr-weakref-2_1.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/lto/attr-weakref-2_1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/lto/attr-weakref-2_1.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,3 ----
+ /* { dg-options {{-fno-lto}} } */
+ 
+ void fn() {}
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/pr101312-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr101312-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/pr101312-1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr101312-1.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,4 ----
+ /* PR c/101312 */
+ /* { dg-do compile } */
+ 
+ volatile int a[1] __attribute__((may_alias));
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/pr101312-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr101312-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/pr101312-2.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr101312-2.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,5 ----
+ /* PR c/101312 */
+ /* { dg-do compile } */
+ /* { dg-options "-g" } */
+ 
+ volatile int a[1] __attribute__((may_alias));
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/pr109410-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr109410-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/pr109410-2.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr109410-2.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,5 ----
+ /* PR tree-optimization/109410 */
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -g" } */
+ 
+ #include "pr109410.c"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/pr122126_vextr.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr122126_vextr.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/pr122126_vextr.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr122126_vextr.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,9 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O2" } */
+ /* { dg-additional-options "-mavx2" { target avx2 } } */
+ 
+ #define vect16 __attribute__((vector_size(16)))
+ void ub_set() {
+   volatile vect16 unsigned BS_VAR_0;
+   unsigned a = BS_VAR_0[12];
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/pr122126_vset.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr122126_vset.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/pr122126_vset.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr122126_vset.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,9 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O2" } */
+ /* { dg-additional-options "-mavx2" { target avx2 } } */
+ 
+ #define vect16 __attribute__((vector_size(16)))
+ void ub_set() {
+   volatile vect16 unsigned BS_VAR_0;
+   BS_VAR_0[12] = 4;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/pr123431.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr123431.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/pr123431.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr123431.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,19 ----
+ /* PR tree-optimization/123431 */
+ /* { dg-do compile } */
+ /* { dg-options "-O2" } */
+ 
+ extern void foo (int);
+ 
+ extern inline __attribute__((always_inline)) void
+ bar (int x, ...)
+ {
+   if (__builtin_constant_p (__builtin_va_arg_pack ()))
+     foo (x);
+ }
+ 
+ void
+ baz (int x)
+ {
+   bar (1, 2);
+   bar (3, x);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/pr123882.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr123882.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/pr123882.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr123882.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,7 ----
+ /* PR c/123882 */
+ /* { dg-do compile } */
+ /* { dg-options "-std=c2x" } */
+ 
+ typedef int T;
+ void foo (unsigned long, T[]);
+ void foo (unsigned long x, T[restrict x]);
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/pr124138.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr124138.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/pr124138.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr124138.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,20 ----
+ /* PR target/124138 */
+ /* { dg-do run } */
+ /* { dg-options "-Wno-psabi" } */
+ 
+ typedef __attribute__((__vector_size__ (8 * sizeof (unsigned long long)))) unsigned long long V;
+ 
+ [[gnu::noipa]] V
+ foo (V x)
+ {
+   return __builtin_shuffle (x, (V) { 0, 1, 2, 5, 4, 5, 6, 7 });
+ }
+ 
+ int
+ main ()
+ {
+   V x = foo ((V) { 1, 2, 3, 4, 5, 6, 7, 8 });
+   if (x[0] != 1 || x[1] != 2 || x[2] != 3 || x[3] != 6
+       || x[4] != 5 || x[5] != 6 || x[6] != 7 || x[7] != 8)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/pr125173-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr125173-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/pr125173-1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr125173-1.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,17 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O1 -fno-forward-propagate --param=max-cse-insns=0" } */
+ 
+ int a;
+ volatile short b;
+ 
+ struct
+ {
+   char c;
+   int d;
+ } s;
+ 
+ void
+ foo ()
+ {
+   __asm__ ("":"+m" (b), "+m" (s.d), "+m" (a));
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/pr126464.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr126464.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/pr126464.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/pr126464.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,65 ----
+ /* PR tree-optimization/126464 */
+ /* { dg-do run } */
+ /* { dg-options "-O2" } */
+ /* { dg-add-options ieee } */
+ /* { dg-skip-if "not IEEE float" { "pdp11-*-*" } } */
+ 
+ [[gnu::noipa]] double
+ foo (double x)
+ {
+   float y = (float) x;
+ 
+   if (y == -__builtin_inff ())
+     return x * 0.5;
+   return y;
+ }
+ 
+ [[gnu::noipa]] long double
+ bar (long double x)
+ {
+   double y = (double) x;
+ 
+   if (y == __builtin_inf ())
+     return x * 0.5L;
+   return y;
+ }
+ 
+ [[gnu::noipa]] double
+ baz (double x)
+ {
+   float y = (float) x;
+ 
+   if (y == __builtin_inff ())
+     return x * 0.5;
+   return y;
+ }
+ 
+ [[gnu::noipa]] long double
+ qux (long double x)
+ {
+   double y = (double) x;
+ 
+   if (y == -__builtin_inf ())
+     return x * 0.5L;
+   return y;
+ }
+ 
+ int
+ main ()
+ {
+ #if __DBL_MAX_10_EXP__ >= 301
+   if (!__builtin_isinf ((double) 1e300)
+       && __builtin_isinf ((float) 1e300)
+       && (foo (-1e300) != -5e299
+ 	  || baz (1e300) != 5e299))
+     __builtin_abort ();
+ #endif
+ 
+ #if __LDBL_MAX_10_EXP__ >= 4001
+   if (!__builtin_isinf ((long double) 1e4000L)
+       && __builtin_isinf ((double) 1e4000L)
+       && (bar (1e4000L) != 5e3999L
+ 	  || qux (-1e4000L) != -5e3999L))
+     __builtin_abort ();
+ #endif
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/strlenopt-97.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/strlenopt-97.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/strlenopt-97.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/strlenopt-97.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,33 ----
+ /* PR tree-optimization/125079 */
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -fdump-tree-strlen1" } */
+ /* { dg-final { scan-tree-dump-times "__builtin___strcpy_chk \\\(" 1 "strlen1" } } */
+ /* { dg-final { scan-tree-dump-not "__builtin___strcpy_chk \\\(\[^\n\r]*, 64\\\)" "strlen1" } } */
+ /* { dg-final { scan-tree-dump-times "__builtin___stpcpy_chk \\\(" 1 "strlen1" } } */
+ /* { dg-final { scan-tree-dump-not "__builtin___stpcpy_chk \\\(\[^\n\r]*, 128\\\)" "strlen1" } } */
+ 
+ typedef __SIZE_TYPE__ size_t;
+ void foo (char *, int);
+ char *stpcpy (char *, const char *);
+ 
+ size_t
+ bar (char *r)
+ {
+   char buf[64];
+   foo (buf, 0);
+   size_t ret = __builtin_strlen (buf);
+   __builtin___strcat_chk (buf, r, 64);
+   foo (buf, 1);
+   return ret;
+ }
+ 
+ size_t
+ baz (char *r)
+ {
+   char buf[128];
+   foo (buf, 2);
+   __builtin___strcat_chk (buf, r, 128);
+   size_t ret = __builtin_strlen (buf);
+   foo (buf, 3);
+   return ret;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/builtin-math-6.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/builtin-math-6.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/builtin-math-6.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/builtin-math-6.c	Fri Sep  4 07:35:09 2026
*************** extern void link_error(int, int);
*** 155,180 ****
      link_error(__LINE__, VAL_NUM); \
    } while (0)
  
! /* For complex numbers, call the TESTIT_COMPLEX_R2 macro for all
     combinations of neg and conj.  */
  #define TESTIT_COMPLEX_R2_ALLNEG(FUNC, ARG0, ARG1, RES1, RES2, RES3, RES4, RES5,\
   RES6, RES7, RES8, RES9, RES10, RES11, RES12, RES13, RES14, RES15, RES16) do{ \
!   TESTIT_COMPLEX_R2(1, FUNC, (_Complex float)(ARG0),(_Complex float)(ARG1), RES1);\
!   TESTIT_COMPLEX_R2(2, FUNC, (_Complex float)(ARG0),CONJ(ARG1), RES2); \
!   TESTIT_COMPLEX_R2(3, FUNC, (_Complex float)(ARG0),-(_Complex float)(ARG1), RES3); \
!   TESTIT_COMPLEX_R2(4, FUNC, (_Complex float)(ARG0),-CONJ(ARG1), RES4); \
!   TESTIT_COMPLEX_R2(5, FUNC, -(_Complex float)(ARG0),(_Complex float)(ARG1), RES5); \
!   TESTIT_COMPLEX_R2(6, FUNC, -(_Complex float)(ARG0),CONJ(ARG1), RES6); \
!   TESTIT_COMPLEX_R2(7, FUNC, -(_Complex float)(ARG0),-(_Complex float)(ARG1), RES7); \
!   TESTIT_COMPLEX_R2(8, FUNC, -(_Complex float)(ARG0),-CONJ(ARG1), RES8); \
!   TESTIT_COMPLEX_R2(9, FUNC, CONJ(ARG0),(_Complex float)(ARG1), RES9); \
!   TESTIT_COMPLEX_R2(10, FUNC, CONJ(ARG0),CONJ(ARG1), RES10); \
!   TESTIT_COMPLEX_R2(11, FUNC, CONJ(ARG0),-(_Complex float)(ARG1), RES11); \
!   TESTIT_COMPLEX_R2(12, FUNC, CONJ(ARG0),-CONJ(ARG1), RES12); \
!   TESTIT_COMPLEX_R2(13, FUNC, -CONJ(ARG0),(_Complex float)(ARG1), RES13); \
!   TESTIT_COMPLEX_R2(14, FUNC, -CONJ(ARG0),CONJ(ARG1), RES14); \
!   TESTIT_COMPLEX_R2(15, FUNC, -CONJ(ARG0),-(_Complex float)(ARG1), RES15); \
!   TESTIT_COMPLEX_R2(16, FUNC, -CONJ(ARG0),-CONJ(ARG1), RES16); \
  } while (0)
  
  int main (void)
--- 155,201 ----
      link_error(__LINE__, VAL_NUM); \
    } while (0)
  
! /* Similar to TESTIT_COMPLEX_R2, but doesn't check sign of imag part
!    if imag part is zero.  MPC between 1.3.1 and 1.4.0 changed the
!    handling of it.  */
! #define TESTIT_COMPLEX_R2_ISZ(VAL_NUM, FUNC, ARG0, ARG1, RES) do { \
!   if (COMPLEX_DIFF1PCT_F (__builtin_##FUNC##f(ARG0, ARG1), (RES)) \
!       || CKSGN_F (__real__ (__builtin_##FUNC##f(ARG0, ARG1)), __real__ (RES)) \
!       || (__imag__ (RES) != 0 \
! 	  && CKSGN_F (__imag__ (__builtin_##FUNC##f(ARG0, ARG1)), __imag__ (RES)))) \
!     link_error(__LINE__, VAL_NUM); \
!   if (COMPLEX_DIFF1PCT (__builtin_##FUNC(ARG0, ARG1), (RES)) \
!       || CKSGN (__real__ (__builtin_##FUNC(ARG0, ARG1)), __real__ (RES)) \
!       || (__imag__ (RES) != 0 \
! 	  && CKSGN (__imag__ (__builtin_##FUNC(ARG0, ARG1)), __imag__ (RES)))) \
!     link_error(__LINE__, VAL_NUM); \
!   if (COMPLEX_DIFF1PCT_L (__builtin_##FUNC##l(ARG0, ARG1), (RES)) \
!       || CKSGN_L (__real__ (__builtin_##FUNC##l(ARG0, ARG1)), __real__ (RES)) \
!       || (__imag__ (RES) != 0 \
! 	  && CKSGN_L (__imag__ (__builtin_##FUNC##l(ARG0, ARG1)), __imag__ (RES)))) \
!     link_error(__LINE__, VAL_NUM); \
!   } while (0)
! 
! /* For complex numbers, call the TESTIT_COMPLEX_R2_ISZ macro for all
     combinations of neg and conj.  */
  #define TESTIT_COMPLEX_R2_ALLNEG(FUNC, ARG0, ARG1, RES1, RES2, RES3, RES4, RES5,\
   RES6, RES7, RES8, RES9, RES10, RES11, RES12, RES13, RES14, RES15, RES16) do{ \
!   TESTIT_COMPLEX_R2_ISZ(1, FUNC, (_Complex float)(ARG0),(_Complex float)(ARG1), RES1);\
!   TESTIT_COMPLEX_R2_ISZ(2, FUNC, (_Complex float)(ARG0),CONJ(ARG1), RES2); \
!   TESTIT_COMPLEX_R2_ISZ(3, FUNC, (_Complex float)(ARG0),-(_Complex float)(ARG1), RES3); \
!   TESTIT_COMPLEX_R2_ISZ(4, FUNC, (_Complex float)(ARG0),-CONJ(ARG1), RES4); \
!   TESTIT_COMPLEX_R2_ISZ(5, FUNC, -(_Complex float)(ARG0),(_Complex float)(ARG1), RES5); \
!   TESTIT_COMPLEX_R2_ISZ(6, FUNC, -(_Complex float)(ARG0),CONJ(ARG1), RES6); \
!   TESTIT_COMPLEX_R2_ISZ(7, FUNC, -(_Complex float)(ARG0),-(_Complex float)(ARG1), RES7); \
!   TESTIT_COMPLEX_R2_ISZ(8, FUNC, -(_Complex float)(ARG0),-CONJ(ARG1), RES8); \
!   TESTIT_COMPLEX_R2_ISZ(9, FUNC, CONJ(ARG0),(_Complex float)(ARG1), RES9); \
!   TESTIT_COMPLEX_R2_ISZ(10, FUNC, CONJ(ARG0),CONJ(ARG1), RES10); \
!   TESTIT_COMPLEX_R2_ISZ(11, FUNC, CONJ(ARG0),-(_Complex float)(ARG1), RES11); \
!   TESTIT_COMPLEX_R2_ISZ(12, FUNC, CONJ(ARG0),-CONJ(ARG1), RES12); \
!   TESTIT_COMPLEX_R2_ISZ(13, FUNC, -CONJ(ARG0),(_Complex float)(ARG1), RES13); \
!   TESTIT_COMPLEX_R2_ISZ(14, FUNC, -CONJ(ARG0),CONJ(ARG1), RES14); \
!   TESTIT_COMPLEX_R2_ISZ(15, FUNC, -CONJ(ARG0),-(_Complex float)(ARG1), RES15); \
!   TESTIT_COMPLEX_R2_ISZ(16, FUNC, -CONJ(ARG0),-CONJ(ARG1), RES16); \
  } while (0)
  
  int main (void)
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/builtin-shufflevector-pr123156.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/builtin-shufflevector-pr123156.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/builtin-shufflevector-pr123156.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/builtin-shufflevector-pr123156.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,40 ----
+ /* { dg-do run { target le } } */
+ 
+ #include 
+ 
+ #define BS_VEC(type, num) type __attribute__((vector_size(num * sizeof(type))))
+ #define BITCAST(T, F, arg)                                                     \
+     ((union {                                                                  \
+         F src;                                                                 \
+         T dst;                                                                 \
+     })arg)                                                                     \
+         .dst
+ 
+ uint64_t func_1()
+ {
+     BS_VEC(uint64_t, 32) BS_VAR_0;
+     BS_VAR_0 = BITCAST(
+         BS_VEC(uint64_t, 32), BS_VEC(uint8_t, 256),
+         __builtin_shufflevector(
+             (BS_VEC(uint8_t, 2)){ 2 }, (BS_VEC(uint8_t, 2)){}, 1, 0, 2, 2, 2, 3,
+             1, 2, 3, 1, 3, 3, 2, 1, 3, 0, 2, 2, 1, 2, 1, 3, 1, 1, 0, 0, 2, 0, 3,
+             2, 2, 0, 1, 3, 1, 2, 0, 2, 0, 3, 0, 0, 2, 0, 2, 1, 3, 2, 3, 2, 1, 1,
+             2, 3, 3, 3, 3, 0, 1, 2, 3, 2, 0, 2, 2, 2, 0, 3, 3, 3, 1, 3, 0, 0, 2,
+             3, 1, 1, 2, 2, 1, 2, 0, 0, 3, 2, 2, 3, 2, 2, 3, 2, 0, 2, 2, 0, 2, 1,
+             3, 1, 0, 2, 1, 3, 2, 1, 0, 2, 3, 0, 1, 3, 2, 1, 3, 1, 1, 3, 2, 2, 0,
+             3, 2, 2, 0, 3, 0, 3, 2, 3, 1, 3, 2, 3, 3, 2, 2, 0, 0, 0, 2, 1, 3, 1,
+             2, 2, 3, 0, 1, 3, 1, 1, 2, 0, 1, 2, 1, 2, 0, 2, 0, 2, 3, 3, 3, 1, 2,
+             0, 3, 1, 2, 0, 1, 0, 3, 0, 0, 3, 2, 2, 0, 3, 1, 2, 0, 1, 1, 3, 0, 1,
+             3, 1, 3, 2, 1, 3, 1, 2, 1, 1, 0, 1, 3, 3, 2, 3, 2, 2, 0, 2, 2, 2, 1,
+             1, 0, 3, 1, 3, 0, 3, 0, 0, 1, 3, 3, 1, 2, 1, 1, 3, 1, 0, 2, 1, 3, 2,
+             1, 3, 2, 2, 2, 3, 2, 0, 1, 3, 3, 3, 0, 0, 0, 1, 3, 2, 2, 1));
+     return BS_VAR_0[0];
+ }
+ 
+ int main()
+ {
+     uint64_t BS_CHECKSUM = func_1();
+     if (BS_CHECKSUM != 0x0000000000000200ull)
+       __builtin_abort ();
+     return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr110043.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr110043.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr110043.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr110043.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,9 ----
+ /* { dg-do compile } */
+ /* { dg-require-effective-target int128 } */
+ 
+ __int128 g_116_1;
+ extern char g_521[][8];
+ void func_24() {
+   for (; g_116_1 >= 0;)
+     g_521[g_116_1][g_116_1] &= 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr111036.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr111036.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr111036.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr111036.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,24 ----
+ /* { dg-do run } */
+ 
+ #include 
+ 
+ __attribute__((aligned(32))) static struct
+ {
+   unsigned long long available_cmd_ids_per_core[2];
+ } _rl2c_cmd_id_data;
+ 
+ static inline void __attribute__((always_inline))
+ foo (void *base, size_t length)
+ {
+   unsigned long int p = (unsigned long int) base;
+   if (__builtin_constant_p(p) && (p & 31) == 0) { exit (0); } 
+   else if (__builtin_constant_p(length)) { exit (0); } 
+   else { exit (0); }
+ }
+ 
+ int main(int argc, char **argv)
+ {
+   foo(&_rl2c_cmd_id_data, sizeof(*(&_rl2c_cmd_id_data)));
+   return 0;
+ }
+ 
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr111387.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr111387.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr111387.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr111387.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,34 ----
+ /* { dg-do compile } */
+ /* { dg-additional-options "-ftree-vectorize -fno-vect-cost-model" } */
+ 
+ struct {
+   unsigned a;
+   unsigned b;
+ } c;
+ int d, e, f, g, h;
+ int main()
+ {
+   if (c.b && g && g > 7)
+     goto i;
+  j:
+   if (c.a) {
+     int k = 0;
+     unsigned l = c.b;
+     if (0) {
+     m:
+       k = l = c.b;
+     }
+     c.a = k;
+     c.b = l;
+   }
+   if (0) {
+   i:
+     goto m;
+   }
+   if (d)
+     goto j;
+   for (f = 5; f; f--)
+     if (h)
+       e = 0;
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr116454-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr116454-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr116454-1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr116454-1.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,16 ----
+ /* { dg-do run } */
+ /* { dg-additional-options "-ffast-math" } */
+ 
+ static int t = 0;
+ _Complex float f()
+ {
+         t++;
+         return 0;
+ }
+ int main() {
+ 	t = 0;
+ 	/* Would cause f() to be incorrectly invoked twice. */
+ 	f() * 1j;
+ 	if (t != 1)
+           __builtin_abort();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr116454-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr116454-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr116454-2.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr116454-2.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,12 ----
+ /* { dg-do run } */
+ /* { dg-additional-options "-ffast-math" } */
+ _Complex float arr[2];
+ 
+ int main() {
+   _Complex float *ptr;
+   ptr = arr;
+   *++ptr * 1j; 
+   /* ptr should only increment once, not twice. */
+   if (ptr != arr + 1)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr117811.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr117811.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr117811.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr117811.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,32 ----
+ /* { dg-do run } */
+ 
+ #include 
+ 
+ typedef int v4 __attribute__((vector_size (4 * sizeof (int))));
+ 
+ void __attribute__((noclone,noinline)) do_shift (v4 *vec, int shift)
+ {
+   v4 t = *vec;
+ 
+   if (shift > 0)
+   {
+     t = t >> shift;
+   }
+ 
+   *vec = t;
+ }
+ 
+ int main ()
+ {
+ #if __SIZEOF_INT__ >= 4
+   v4 vec =  {0x1000000, 0x2000, 0x300, 0x40};
+   v4 vec2 = {0x100000,  0x200,  0x30,  0x4};
+ #else
+   v4 vec =  {0x4000, 0x2000, 0x300, 0x40};
+   v4 vec2 = {0x400,  0x200,  0x30,  0x4};
+ #endif
+   do_shift (&vec, 4);
+   if (memcmp (&vec, &vec2, sizeof (v4)) != 0)
+     __builtin_abort ();
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr119532.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr119532.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr119532.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr119532.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,14 ----
+ /* { dg-do compile } */
+ /* { dg-require-effective-target fixed_point } */
+ 
+ extern _Fract sinuhk_deg (unsigned short _Accum);
+ 
+ _Fract cosuhk_deg (unsigned short _Accum deg)
+ {
+   unsigned short _Accum _90_deg = 90uhk;
+   __asm ("" : "+r" (_90_deg));
+ 
+   return deg <= _90_deg
+     ? sinuhk_deg (_90_deg - deg)
+     : -sinuhk_deg (deg - _90_deg);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr120182.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr120182.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr120182.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr120182.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,42 ----
+ /* { dg-do run { target { { *-*-linux* *-*-gnu* *-*-uclinux* } && mmap } } } */
+ 
+ #include 
+ #include 
+ #include 
+ 
+ struct S
+ {
+   struct S *next;
+ };
+ 
+ static void __attribute__((noipa))
+ allocate(void *addr, unsigned long long size)
+ {
+   void *ptr = mmap((void *)addr, size,
+ 		   PROT_READ | PROT_WRITE,
+ 		   MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED_NOREPLACE,
+ 		   -1, 0);
+   if(ptr != addr)
+     exit(0);
+ }
+ 
+ int main (void)
+ {
+   int size = 0x8000;
+   char *ptr = (char *)0x288000ull;
+   allocate((void *)ptr, size);
+ 
+   struct S *s1 = (struct S *)ptr;
+   struct S *s2 = (struct S *)256;
+   for (int i = 0; i < 3; i++)
+     {
+       for(char *addr = (char *)s1; addr < (char *)s1 + sizeof(*s1); ++addr)
+ 	*addr = 0;
+ 
+       if(s1->next)
+ 	s1->next = s1->next->next = s2;
+       else
+ 	s1->next = s2;
+     }
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr120341-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr120341-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr120341-1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr120341-1.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,11 ----
+ /* { dg-do run } */
+ /* { dg-additional-options "-fallow-store-data-races" } */
+ 
+ char a, *b;
+ int main()
+ {
+   b = "0";
+   if (a)
+     b[0]++;
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr120341-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr120341-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr120341-2.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr120341-2.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,13 ----
+ /* { dg-do run } */
+ /* { dg-additional-options "-fallow-store-data-races" } */
+ 
+ char a, *b;
+ int main()
+ {
+   while (a)
+     {
+       b = "0";
+       b[0]++;
+     }
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr120944.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr120944.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr120944.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr120944.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,34 ----
+ /* { dg-skip-if "" { *-*-* } { "-flto" } { "" } } */
+ /* { dg-additional-options "-fdump-tree-optimized" } */
+ 
+ #include 
+ 
+ typedef union {
+   int u32;
+   struct
+   {
+      int A:1;
+      int B:2;
+      int C:3;
+   };
+ } u_t;
+ 
+ typedef union {
+    volatile int u[3];
+    volatile struct {
+         u_t a;
+         int b;
+         int c;
+    };
+ } DATA;
+ 
+ void foo (volatile DATA *d)
+ {
+      d->a.u32 = ~0;
+      u_t u = d->a;
+      int v = u.A;
+      if (v)
+         abort();
+ }
+ 
+ /* { dg-final { scan-tree-dump-times "if \\\(" 1 "optimized" } } */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr121370.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr121370.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr121370.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr121370.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,25 ----
+ /* { dg-do run } */
+ /* { dg-require-effective-target int32plus } */
+ 
+ int a;
+ int main()
+ {
+   int c = -2147483647;
+   int d = -2147483647;
+   int e = 2147483647;
+   if (0)
+   f:
+     e = d + e - 2;
+ g:
+   if (d - c - e > 0) {
+     a = -c;
+     if (a + d) {
+       d = 1;
+       goto g;
+     }
+     return 0;
+   }
+   if (e)
+     goto f;
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr121844.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr121844.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr121844.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr121844.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,16 ----
+ /* { dg-do compile } */
+ 
+ typedef unsigned long a;
+ int b[] = {};
+ int **c;
+ short d(a *e, int f)
+ {
+   *c = &f;
+   for (;;)
+     asm goto("" : : : : g);
+   for (; f; f--) {
+     asm goto("" : : : : g);
+   g:
+     *e ^= b[f + 1];
+   }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr123416.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr123416.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr123416.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr123416.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,28 ----
+ /* { dg-do run } */
+ /* { dg-additional-options "-fno-strict-aliasing" } */
+ 
+ struct a {
+   int b;
+ } c;
+ 
+ int d;
+ 
+ static struct a
+ g()
+ {
+   int a[2], b, f = 0;
+   for (; f < 2; f++)
+     a[f] = 1;
+   b = a[0];
+   if (b)
+     return c;
+ }
+ int main()
+ {
+   c.b = 1;
+   struct a e = g();
+   c = g();
+   if (!c.b || !e.b)
+     __builtin_abort();
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr123645-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr123645-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr123645-1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr123645-1.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,24 ----
+ /* { dg-do run } */
+ 
+ /* PR tree-optimization/123645 */
+ /* Phi-opt was transforming f into __builtin_popcount which was incorrect. */
+ 
+ __attribute__((noinline))
+ int f(unsigned a)
+ {
+   return a < 1 ? __builtin_popcount(a) : 0;
+ }
+ 
+ int main()
+ {
+   if (f(1) != 0)
+     __builtin_abort();
+   if (f(0) != 0)
+     __builtin_abort();
+   if (f(2) != 0)
+     __builtin_abort();
+   if (f(3) != 0)
+     __builtin_abort();
+   if (f(-1) != 0)
+     __builtin_abort();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr123645-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr123645-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr123645-2.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr123645-2.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,24 ----
+ /* { dg-do run } */
+ 
+ /* PR tree-optimization/123645 */
+ /* Phi-opt was transforming f into __builtin_bswap which was incorrect. */
+ 
+ __attribute__((noinline))
+ int f(unsigned a)
+ {
+   return a < 1 ? __builtin_bswap32(a) : 0;
+ }
+ 
+ int main()
+ {
+   if (f(1) != 0)
+     __builtin_abort();
+   if (f(0) != 0)
+     __builtin_abort();
+   if (f(2) != 0)
+     __builtin_abort();
+   if (f(3) != 0)
+     __builtin_abort();
+   if (f(-1) != 0)
+     __builtin_abort();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr123864.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr123864.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr123864.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr123864.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,28 ----
+ /* PR tree-optimization/123864 */
+ /* { dg-do run { target int128 } } */
+ 
+ int u, v, x;
+ 
+ [[gnu::noipa]] static void
+ foo ()
+ {
+   __int128 c = (__int128) 0xa5ee4bc88ULL << 64;
+   long long b = 0x207b8a7f7LL;
+   int a = 4;
+   long long y;
+   __builtin_add_overflow (a, v, &y);
+   c *= y;
+   
+   unsigned z;
+   if (__builtin_add_overflow (b, u, &z))
+     z = 0xffffffffU;
+   x = __builtin_mul_overflow_p (z, c, c);
+ }
+ 
+ int
+ main ()
+ {
+   foo ();
+   if (!x)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr124132.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr124132.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr124132.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr124132.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,16 ----
+ /* { dg-do compile } */
+ /* { dg-additional-options "-w" } */
+ 
+ char slow_mul1_dst1, code_some_shards___gf_mulc__0, code_some_shards_lim;
+ long slow_mul1_dst_max;
+ long long code_some_shards_pos;
+ void code_some_shards()
+ {
+   char *dst = &slow_mul1_dst1;
+   for (; dst < &code_some_shards_lim; dst++)
+     {
+       if (code_some_shards_pos < slow_mul1_dst_max)
+         *dst = code_some_shards___gf_mulc__0;
+       code_some_shards_pos += 1;
+     }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr124868.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr124868.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr124868.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr124868.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,24 ----
+ /* { dg-do run } */
+ /* { dg-skip-if "" { *-*-* } { "-O0" } } */
+ /* { dg-additional-options "-fisolate-erroneous-paths-dereference" } */
+ 
+ int a;
+ static void __attribute__((noipa)) c(int b) {}
+ static int * __attribute__((noipa))
+ d()
+ {
+   int g = 0, *h = &g;
+   if (a)
+     {
+       int **i = &h;
+       *i = 0;
+     }
+   c(*h);
+   return h; /* { dg-warning "address of local variable" } */
+ }
+ int
+ main()
+ {
+   d();
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr125025.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr125025.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr125025.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr125025.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,20 ----
+ /* { dg-do compile } */
+ /* { dg-additional-options "-fsanitize=undefined" } */
+ 
+ void f2(signed char a0)
+ {
+   signed char v4;
+   _Bool c7;
+   signed char v8 = 91;
+   v4 = v8 + v8;
+   v8 = 15 - 50;
+   a0 = v8 * v4;
+   v8 = v4 - a0;
+ lbl_br10:
+   c7 = a0 <= 0;
+   if (c7)
+     return;
+   v4 = v8 - 24;
+   a0 = a0 + v4;
+   goto lbl_br10;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr125774-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr125774-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr125774-1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr125774-1.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,48 ----
+ /* { dg-do run } */
+ /* { dg-additional-options "-fgimple -fdump-tree-optimized" } */
+ /* { dg-skip-if "" { *-*-* } { "-fno-fat-lto-objects" } { "" } } */
+ /* PR tree-optimization/125774 */
+ 
+ __attribute__((noipa))
+ _Bool __GIMPLE (ssa,startwith("dom"))
+ f (int a, int b)
+ {
+   _Bool _3;
+   _Bool _4;
+   _Bool _5;
+ 
+   __BB(2):
+   _3 = a_1(D) > b_2(D);
+   _4 = b_2(D) > a_1(D);
+   _5 = _3 | _4;
+   return _5;
+ }
+ 
+ __attribute__((noipa))
+ _Bool __GIMPLE (ssa,startwith("dom"))
+ f1 (int a, int b)
+ {
+   _Bool _3;
+   _Bool _4;
+   _Bool _5;
+ 
+   __BB(2):
+   _3 = a_1(D) > b_2(D);
+   _4 = a_1(D) < b_2(D);
+   _5 = _3 | _4;
+   return _5;
+ }
+ 
+ int main()
+ {
+   int a = 10, b = 10;
+   if (f(a,b))
+     __builtin_abort();
+   if (f1(a,b))
+     __builtin_abort();
+   return 0;
+ }
+ 
+ /* { dg-final { scan-tree-dump-not "return 1" "optimized" } } */
+ /* Both functions should be optimized to `a_1 != b_2`. */
+ /* { dg-final { scan-tree-dump-times "a_1.D. != b_2.D." 2 "optimized" { target __OPTIMIZE__ } } } */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr126464.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr126464.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr126464.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr126464.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,28 ----
+ /* PR tree-optimization/126464 */
+ /* { dg-do run } */
+ 
+ #if __DBL_MANT_DIG__ == 53 && __DBL_MAX_10_EXP__ == 308 \
+     && __DBL_HAS_INFINITY__ && __FLT_EVAL_METHOD__ == 0
+ [[gnu::noipa]] double
+ foo (double x, double y)
+ {
+   if (y >= -1e304 && y <= -1e300)
+     {
+       if (x + y == -__builtin_inf ())
+ 	return x * 0.5;
+     }
+   return x;
+ }
+ #endif
+ 
+ int
+ main ()
+ {
+ #if __DBL_MANT_DIG__ == 53 && __DBL_MAX_10_EXP__ == 308 \
+     && __DBL_HAS_INFINITY__ && __FLT_EVAL_METHOD__ == 0
+   if (foo (-__builtin_inf (), -1e303) != -__builtin_inf ())
+     __builtin_abort ();
+   if (foo (-1.797693134862e308, -1e303) != -1.797693134862e308 / 2.0)
+     __builtin_abort ();
+ #endif
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr126547.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr126547.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr126547.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr126547.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,31 ----
+ /* PR tree-optimization/126547 */
+ /* { dg-do run } */
+ 
+ #if __LDBL_HAS_INFINITY__
+ [[gnu::noipa]] static int
+ foo (long double a1, long double a2)
+ {
+   if (a1 >= 1.0 && a1 <= 8.0)
+     {
+       long double d = a1 / a2;
+       int n = 0;
+       if (d >= __builtin_infl ())
+ 	n += 1;
+       if (a2 > 0.0L)
+ 	n += 2;
+       return n;
+     }
+   else
+     return -1;
+ }
+ #endif
+ 
+ int
+ main ()
+ {
+ #if __LDBL_HAS_INFINITY__
+   if (__builtin_isinf (1.0 / __LDBL_DENORM_MIN__)
+       && foo (1.0, __LDBL_DENORM_MIN__) != 3)
+     __builtin_abort ();
+ #endif
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr126564.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr126564.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr126564.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr126564.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,25 ----
+ /* PR tree-optimization/126564 */
+ /* { dg-do run } */
+ 
+ __attribute__((noipa)) int
+ foo (int x, int y)
+ {
+   int c = 2;
+   if (x == y)
+     c = 0;
+   else if (x < y)
+     c = -1;
+   else if (x <= y)
+     c = 1;
+   return c == 1;
+ }
+ 
+ int
+ main ()
+ {
+   int i, j;
+   for (i = -3; i <= 3; i++)
+     for (j = -3; j <= 3; j++)
+       if (foo (i, j) != 0)
+ 	__builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr126576.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr126576.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/pr126576.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/pr126576.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,43 ----
+ /* PR tree-optimization/126576 */
+ /* { dg-do run } */
+ 
+ #if __DBL_MANT_DIG__ == 53 && __DBL_MAX_10_EXP__ == 308 \
+     && __DBL_HAS_INFINITY__ && __FLT_EVAL_METHOD__ == 0
+ int v;
+ 
+ [[gnu::noipa]] void
+ bar (int x)
+ {
+   v |= x;
+ }
+ 
+ [[gnu::noipa]] double
+ foo (double x)
+ {
+   double a = x * x;
+   if (__builtin_isinf (a) && !__builtin_isinf (x))
+     bar (1);
+   double b = a * 3.0;
+   if (__builtin_isinf (b) && !__builtin_isinf (a))
+     bar (2);
+   return b;
+ }
+ #endif
+ 
+ int
+ main ()
+ {
+ #if __DBL_MANT_DIG__ == 53 && __DBL_MAX_10_EXP__ == 308 \
+     && __DBL_HAS_INFINITY__ && __FLT_EVAL_METHOD__ == 0
+   foo (1e154);
+   if (v != 2)
+     __builtin_abort ();
+   v = 0;
+   foo (1e152);
+   if (v != 0)
+     __builtin_abort ();
+   foo (1e155);
+   if (v != 1)
+     __builtin_abort ();
+ #endif    
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/torture/vec-cvt-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/vec-cvt-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/torture/vec-cvt-1.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/torture/vec-cvt-1.c	Fri Sep  4 07:35:09 2026
*************** flttointtest##intt (void)						\
*** 55,76 ****
    else									\
      {									\
        vf2 = fltmin = min - 1.0f;					\
!       for (vf = 1.0f; (fltmin = vf2 + vf) == vf2; vf = vf * 2.0f)	\
  	;								\
      }									\
    vf2 = fltmax = max + 1.0f;						\
!   for (vf = 1.0f; (fltmax = vf2 - vf) == vf2; vf = vf * 2.0f)		\
      ;									\
    if (min == 0)								\
      dblmin = 0.0;							\
    else									\
      {									\
        vd2 = dblmin = min - 1.0;						\
!       for (vd = 1.0; (dblmin = vd2 + vd) == vd2; vd = vd * 2.0)		\
  	;								\
      }									\
    vd2 = dblmax = max + 1.0;						\
!   for (vd = 1.0; (dblmax = vd2 - vd) == vd2; vd = vd * 2.0)		\
      ;									\
    for (i = 0; i < N; i++)						\
      {									\
--- 55,76 ----
    else									\
      {									\
        vf2 = fltmin = min - 1.0f;					\
!       for (vf = 1.0f; fltmin = vf2 + vf, fltmin == vf2; vf = vf * 2.0f)	\
  	;								\
      }									\
    vf2 = fltmax = max + 1.0f;						\
!   for (vf = 1.0f; fltmax = vf2 - vf, fltmax == vf2; vf = vf * 2.0f)	\
      ;									\
    if (min == 0)								\
      dblmin = 0.0;							\
    else									\
      {									\
        vd2 = dblmin = min - 1.0;						\
!       for (vd = 1.0; dblmin = vd2 + vd, dblmin == vd2; vd = vd * 2.0)	\
  	;								\
      }									\
    vd2 = dblmax = max + 1.0;						\
!   for (vd = 1.0; dblmax = vd2 - vd, dblmax == vd2; vd = vd * 2.0)	\
      ;									\
    for (i = 0; i < N; i++)						\
      {									\
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-26.c	Fri Sep  4 07:35:09 2026
*************** int main ()
*** 31,35 ****
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { ! { avr-*-* pru-*-* } } } } } */
  /* IBM Z does not require special alignment for vectorization.  */
! /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" { target { ! { avr-*-* pru-*-* s390*-*-* } } } } } */
! /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { target { ! { avr-*-* pru-*-* s390*-*-* } } } } } */
--- 31,35 ----
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { ! { avr-*-* pru-*-* } } } } } */
  /* IBM Z does not require special alignment for vectorization.  */
! /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" { target { ! { arm*-*-* avr-*-* pru-*-* s390*-*-* } } } } } */
! /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { target { ! { arm*-*-* avr-*-* pru-*-* s390*-*-* } } } } } */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/gen-vect-28.c	Fri Sep  4 07:35:09 2026
*************** int main (void)
*** 39,43 ****
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { ! { avr-*-* pru-*-* } } } } } */
  /* IBM Z does not require special alignment for vectorization.  */
! /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" { target { ! { avr-*-* pru-*-* s390*-*-* } } } } } */
! /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { target { ! { avr-*-* pru-*-* s390*-*-* } } } } } */
--- 39,43 ----
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target { ! { avr-*-* pru-*-* } } } } } */
  /* IBM Z does not require special alignment for vectorization.  */
! /* { dg-final { scan-tree-dump-times "Vectorizing an unaligned access" 0 "vect" { target { ! { arm*-*-* avr-*-* pru-*-* s390*-*-* } } } } } */
! /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" { target { ! { arm*-*-* avr-*-* pru-*-* s390*-*-* } } } } } */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/pr117423.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/pr117423.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/pr117423.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/pr117423.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,49 ----
+ /* { dg-do run } */
+ /* { dg-options "-O1" } */
+ 
+ struct s4 {
+     int _0;
+ };
+ struct s1 {
+     unsigned char _4;
+     long _1;
+ };
+ struct s2 {
+     union {
+         struct s3 {
+             unsigned char _1;
+             struct s4 _0;
+         } var_0;
+         struct s1 var_1;
+     } DATA;
+ };
+ int f1(int arg0) { return arg0 > 12345; }
+ __attribute__((noinline))
+ struct s4 f2(int arg0) {
+     struct s4 rv = {arg0};
+     return rv;
+ }
+ struct s2 f3(int arg0) {
+     struct s2 rv;
+     struct s1 var6 = {0};
+     struct s4 var7;
+     if (f1(arg0)) {
+         rv.DATA.var_1 = var6;
+         return rv;
+     } else {
+         rv.DATA.var_0._1 = 2;
+         var7 = f2(arg0);
+         rv.DATA.var_0._0 = var7;
+         return rv;
+     }
+ }
+ int main() {
+   if (f3(12345).DATA.var_0._0._0 == 12345)
+     ;
+   else
+     __builtin_abort();
+   if (f3(12344).DATA.var_0._0._0 == 12344)
+     ;
+   else
+     __builtin_abort();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/pr119085.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/pr119085.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/pr119085.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/pr119085.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,37 ----
+ /* { dg-do run } */
+ /* { dg-options "-O1" } */
+ 
+ struct with_hole {
+   int x;
+   long y;
+ };
+ struct without_hole {
+   int x;
+   int y;
+ };
+ union u {
+   struct with_hole with_hole;
+   struct without_hole without_hole;
+ };
+ 
+ void __attribute__((noinline))
+ test (union u *up, union u u)
+ {
+   union u u2;
+   volatile int f = 0;
+   u2 = u;
+   if (f)
+     u2.with_hole = u.with_hole;
+   *up = u2;
+ }
+ 
+ int main(void)
+ {
+   union u u;
+   union u u2;
+   u2.without_hole.y = -1;
+   test (&u, u2);
+   if (u.without_hole.y != -1)
+     __builtin_abort ();
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/pr122976.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/pr122976.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/pr122976.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/pr122976.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,105 ----
+ /* { dg-do run } */
+ /* { dg-options "-O2" } */
+ 
+ typedef unsigned long NI;
+ 
+ struct inner_t_Content
+ {
+   int x[8], y[16];
+   char a[10], b[20], c[30];
+ };
+ 
+ struct inner_t {
+   NI len;
+   struct inner_t_Content* p;
+ };
+ 
+ struct outer_t {
+   struct inner_t bytes;
+   NI position;
+ };
+ 
+ struct localo_t {
+   struct outer_t fo;
+   char stuff[222];
+ };
+ 
+ struct alien_t {
+   NI Field0;
+   struct inner_t Field1;
+ };
+ 
+ static struct inner_t_Content gic;
+ struct inner_t gis;
+ struct outer_t gos;
+ volatile int vgi;
+ 
+ int __attribute__((noipa))
+ get_int (void)
+ {
+   return 0;
+ }
+ 
+ struct inner_t __attribute__((noipa))
+ get_inner_t ()
+ {
+   struct inner_t v = {0, (void *)0};
+   return v;
+ }
+ 
+ void __attribute__((noipa))
+ use_inner_t (struct inner_t v)
+ {
+   gis = v;
+ }
+ 
+ void __attribute__((noipa))
+ init (void)
+ {
+   gos.bytes.len = 15;
+   gos.bytes.p = &gic;
+ }
+ 
+ void __attribute__((noipa))
+ check (void)
+ {
+   if (gis.p != &gic)
+     __builtin_abort ();
+ }
+ 
+ static void foo (int m, struct outer_t *a)
+ {
+   struct inner_t lis;
+ 
+   if (m == 20)
+       ((struct alien_t *) a)->Field1.len = 0;
+   if (m == 21)
+     lis = get_inner_t ();
+   else
+     lis = a->bytes;
+ 
+   vgi = get_int ();
+   if (m < 1)
+     use_inner_t (lis);
+   if (get_int ())
+     vgi = ((struct alien_t *) a)->Field1.len;
+ 
+ }
+ 
+ void bar (struct outer_t pos)
+ {
+   struct localo_t los;
+   los.fo = pos;
+   los.fo.bytes.len = get_int ();
+   foo (get_int (), &los.fo);
+   gos = los.fo;
+ }
+ 
+ int main (int argc, char **argv)
+ {
+   init ();
+   for (int i = 0; i <= get_int (); i++)
+     bar (gos);
+   check ();
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/pr124151.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,31 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O1" } */
+ 
+ typedef struct {
+   _Bool : 1;
+ } Http2Identifier;
+ typedef struct {
+   _Bool is_end;
+   Http2Identifier identifier;
+ } Http2DataFrame;
+ typedef struct {
+   Http2Identifier identifier;
+   _Bool end_headers;
+ } Http2ContinuationFrame;
+ typedef struct {
+   union {
+     Http2DataFrame data;
+     Http2ContinuationFrame continuation;
+   };
+ } Http2Frame;
+ typedef struct {
+   Http2Identifier stream_identifier;
+ } Http2RawHeader;
+ Http2RawHeader parse_http2_continuation_frame_http2_raw_header;
+ Http2Frame gh2f;
+ void http2_send_and_receive_preface() {
+   Http2ContinuationFrame continuation_frame = {
+       parse_http2_continuation_frame_http2_raw_header.stream_identifier, 0};
+   Http2Frame frame = {.continuation = continuation_frame};
+   gh2f = frame;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/pr126601.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/pr126601.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/tree-ssa/pr126601.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/tree-ssa/pr126601.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,29 ----
+ /* PR tree-optimization/126601 */
+ /* { dg-do compile } */
+ /* { dg-options "-Os" } */
+ 
+ volatile int c[16];
+ 
+ [[gnu::noipa]] int
+ foo (unsigned x, unsigned y)
+ {
+   unsigned r = x * y;
+   int t = 0;
+   if (c[0]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[1]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[2]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[3]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[4]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[5]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[6]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[7]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[8]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[9]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[10]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[11]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[12]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[13]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[14]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   if (c[15]) { int u = 0; if (x != 0) u = (r / x != y); t += u; }
+   return t;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/ubsan/pr120837.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/ubsan/pr120837.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/ubsan/pr120837.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/ubsan/pr120837.c	Fri Sep  4 07:35:09 2026
***************
*** 0 ****
--- 1,32 ----
+ /* PR c/120837 */
+ /* { dg-do run } */
+ /* { dg-options "-O1 -fsanitize=undefined -fno-sanitize-recover=undefined" } */
+ 
+ [[gnu::noipa]] void
+ bar (void **x, void **y)
+ {
+   x[0] = 0;
+   x[1] = 0;
+   x[2] = 0;
+   y[0] = 0;
+   y[1] = 0;
+   y[2] = 0;
+   y[3] = 0;
+   y[4] = 0;
+ }
+ 
+ [[gnu::noipa]] void *
+ foo (int x, int y)
+ {
+   void *a[3];
+   void *b[5];
+   bar (a, b);
+   return (x > y ? b : a)[y - 1];
+ }
+ 
+ int
+ main ()
+ {
+   if (foo (2, 1) != 0)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/vect/pr120817.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/pr120817.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/vect/pr120817.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/pr120817.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,41 ----
+ /* { dg-additional-options "-O1" } */
+ /* { dg-require-effective-target aarch64_sve_hw { target aarch64*-*-* } } */
+ /* { dg-additional-options "-march=armv8-a+sve -mtune=neoverse-n2" { target aarch64*-*-* } } */
+ 
+ #include "tree-vect.h"
+ 
+ typedef struct {
+     int _M_current;
+ } __normal_iterator;
+ 
+ typedef struct {
+     char _M_elems[5];
+ } array_5;
+ 
+ __normal_iterator __trans_tmp_1 = {-5};
+ 
+ __attribute__((noipa))
+ array_5 copySourceIntoTarget() {
+     array_5 target;
+     char* target_it = target._M_elems;
+ 
+     while (__trans_tmp_1._M_current != 0) {
+         *target_it = 1;
+         __trans_tmp_1._M_current++;
+         target_it++;
+     }
+ 
+     return target;
+ }
+ 
+ int main ()
+ {
+   check_vect ();
+ 
+   array_5 res = copySourceIntoTarget();
+ 
+ #pragma GCC novector
+   for (int i = 0; i < 5; i++)
+     if (res._M_elems[i] != 1)
+       __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/vect/pr121059.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/pr121059.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/vect/pr121059.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/pr121059.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,24 ----
+ /* { dg-do compile } */
+ /* { dg-additional-options "-O3 --param vect-partial-vector-usage=1" } */
+ /* { dg-additional-options "-march=x86-64-v4" { target avx512f } } */
+ 
+ typedef struct {
+   long left, right, top, bottom;
+ } MngBox;
+ typedef struct {
+   MngBox object_clip[6];
+   char exists[256], frozen[];
+ } MngReadInfo;
+ MngReadInfo mng_info;
+ 
+ long ReadMNGImage_i;
+ 
+ void ReadMNGImage(int ReadMNGImage_i)
+ {
+   for (; ReadMNGImage_i < 256; ReadMNGImage_i++)
+     if (mng_info.exists[ReadMNGImage_i] && mng_info.frozen[ReadMNGImage_i])
+       mng_info.object_clip[ReadMNGImage_i].left =
+           mng_info.object_clip[ReadMNGImage_i].right =
+               mng_info.object_clip[ReadMNGImage_i].top =
+                   mng_info.object_clip[ReadMNGImage_i].bottom = 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-fmax-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-fmax-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-fmax-2.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-fmax-2.c	Fri Sep  4 07:35:10 2026
***************
*** 1,4 ****
! /* { dg-require-effective-target vect_float } */
  
  #define TYPE double
  #define FN __builtin_fmax
--- 1,4 ----
! /* { dg-require-effective-target vect_double } */
  
  #define TYPE double
  #define FN __builtin_fmax
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-fmax-3.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-fmax-3.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-fmax-3.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-fmax-3.c	Fri Sep  4 07:35:10 2026
***************
*** 1,4 ****
! /* { dg-require-effective-target vect_float } */
  
  #include "tree-vect.h"
  
--- 1,4 ----
! /* { dg-require-effective-target vect_double } */
  
  #include "tree-vect.h"
  
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-fmin-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-fmin-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-fmin-2.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-fmin-2.c	Fri Sep  4 07:35:10 2026
***************
*** 1,4 ****
! /* { dg-require-effective-target vect_float } */
  
  #ifndef TYPE
  #define TYPE double
--- 1,4 ----
! /* { dg-require-effective-target vect_double } */
  
  #ifndef TYPE
  #define TYPE double
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-fmin-3.c	Fri Sep  4 07:35:10 2026
***************
*** 1,4 ****
! /* { dg-require-effective-target vect_float } */
  
  #include "tree-vect.h"
  
--- 1,4 ----
! /* { dg-require-effective-target vect_double } */
  
  #include "tree-vect.h"
  
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-recurr-pr121256-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-recurr-pr121256-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-recurr-pr121256-2.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-recurr-pr121256-2.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,49 ----
+ /* { dg-additional-options "-mavx2" { target avx2_runtime } } */
+ 
+ #include "tree-vect.h"
+ 
+ #define B 0
+ #define G 1
+ #define R 2
+ 
+ int red = 153;
+ int green = 66;
+ int blue = 187;
+ 
+ static void __attribute__((noipa))
+ sub_left_prediction_bgr32(int *restrict dst, int *restrict src)
+ {
+   for (int i = 0; i < 8; i++) {
+     int rt = src[i * 3 + R];
+     int gt = src[i * 3 + G];
+     int bt = src[i * 3 + B];
+ 
+     dst[i * 3 + R] = rt - red;
+     dst[i * 3 + G] = gt - green;
+     dst[i * 3 + B] = bt - blue;
+ 
+     red = rt;
+     green = gt;
+     blue = bt;
+   }
+ }
+ 
+ int main()
+ {
+   int dst[8*3];
+   int src[8*3] = { 160, 73, 194, 17, 33, 99, 0, 12, 283, 87, 73, 11,
+ 		   9, 7, 1, 23, 19, 13, 77, 233, 97, 78, 2, 5 };
+   int dst2[8*3] = {-27, 7, 41, -143, -40, -95, -17, -21, 184, 87, 61,
+       -272, -78, -66, -10, 14, 12, 12, 54, 214, 84, 1, -231, -92};
+ 
+   check_vect ();
+ 
+   sub_left_prediction_bgr32(dst, src);
+ 
+ #pragma GCC novector
+   for (int i = 0; i < 8*3; ++i)
+     if (dst[i] != dst2[i])
+       __builtin_abort();
+ 
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-recurr-pr121256.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-recurr-pr121256.c
*** gcc-13.4.0/gcc/testsuite/gcc.dg/vect/vect-recurr-pr121256.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.dg/vect/vect-recurr-pr121256.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,54 ----
+ /* { dg-additional-options "-mavx2" { target avx2_runtime } } */
+ 
+ #include 
+ #include 
+ #include 
+ #include "tree-vect.h"
+ 
+ #define B 0
+ #define G 1
+ #define R 2
+ #define A 3
+ 
+ int red = 153;
+ int green = 66;
+ int blue = 187;
+ int alpha = 255;
+ 
+ static void __attribute__((noipa))
+ sub_left_prediction_bgr32(uint8_t *restrict dst, uint8_t *restrict src, int w)
+ {
+   for (int i = 0; i < 8; i++) {
+     int rt = src[i * 4 + R];
+     int gt = src[i * 4 + G];
+     int bt = src[i * 4 + B];
+     int at = src[i * 4 + A];
+ 
+     dst[i * 4 + R] = rt - red;
+     dst[i * 4 + G] = gt - green;
+     dst[i * 4 + B] = bt - blue;
+     dst[i * 4 + A] = at - alpha;
+ 
+     red = rt;
+     green = gt;
+     blue = bt;
+     alpha = at;
+   }
+ }
+ 
+ int main()
+ {
+   check_vect ();
+ 
+   uint8_t *dst = calloc(36, sizeof(uint8_t));
+   uint8_t *src = calloc(36, sizeof(uint8_t));
+ 
+   src[R] = 160;
+   src[G] = 73;
+   src[B] = 194;
+   src[A] = 255;
+ 
+   sub_left_prediction_bgr32(dst, src, 33);
+   if (dst[R] != 7 || dst[B] != 7 || dst[A] != 0)
+     __builtin_abort();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/cpunative/info_36 gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/cpunative/info_36
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/cpunative/info_36	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/cpunative/info_36	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,9 ----
+ processor	: 0
+ BogoMIPS	: 100.00
+ Features	: fp asimd evtstrm aes pmull sha1 sha2 crc32 asimddp sve sve2 fphp asimdhp fcma
+ CPU implementer	: 0x41
+ CPU architecture: 8
+ CPU variant	: 0x0
+ CPU part	: 0xd08
+ CPU revision	: 2
+ 
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_36.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_36.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_36.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_36.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,10 ----
+ /* { dg-do compile { target { { aarch64*-*-linux*} && native } } } */
+ /* { dg-set-compiler-env-var GCC_CPUINFO "$srcdir/gcc.target/aarch64/cpunative/info_36" } */
+ /* { dg-additional-options "-march=native -mtune=cortex-a34" } */
+ 
+ int main()
+ {
+   return 0;
+ }
+ 
+ /* { dg-final { scan-assembler {\.arch armv8-a\+dotprod\+crc\+crypto\+sve2\n} } } */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/pr121253.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/pr121253.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/pr121253.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/pr121253.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,16 ----
+ /* { dg-options "-O" } */
+ 
+ struct s128 {
+     long a, b;
+ };
+ 
+ struct s128 foo(void) {
+     struct s128 ret;
+     asm("mov %0, #0 \n\t"
+         "mov %R0, #0 \n\t"
+         "mov x0, #12345"
+         : "=r" (ret) : : "x0");
+     return ret;
+ }
+ 
+ /* { dg-final { scan-assembler-not {mov x0, #0} } } */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_2.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_2.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_2.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,96 ----
+ /* { dg-options "-O2" } */
+ /* { dg-final { check-function-bodies "**" "" } } */
+ 
+ #include 
+ 
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+ 
+ /*
+ ** test1:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	trn1	p0\.h, p[0-3]\.h, \1\.h
+ **	ret
+ */
+ svbool_t
+ test1 ()
+ {
+   return svtrn1_b16 (svptrue_b8 (), svptrue_b16 ());
+ }
+ 
+ /*
+ ** test2:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	trn1	p0\.h, \1\.h, p[0-3]\.h
+ **	ret
+ */
+ svbool_t
+ test2 ()
+ {
+   return svtrn1_b16 (svptrue_b16 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test3:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	trn1	p0\.s, p[0-3]\.s, \1\.s
+ **	ret
+ */
+ svbool_t
+ test3 ()
+ {
+   return svtrn1_b32 (svptrue_b8 (), svptrue_b32 ());
+ }
+ 
+ /*
+ ** test4:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	trn1	p0\.s, \1\.s, p[0-3]\.s
+ **	ret
+ */
+ svbool_t
+ test4 ()
+ {
+   return svtrn1_b32 (svptrue_b32 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test5:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	trn1	p0\.d, p[0-3]\.d, \1\.d
+ **	ret
+ */
+ svbool_t
+ test5 ()
+ {
+   return svtrn1_b64 (svptrue_b8 (), svptrue_b64 ());
+ }
+ 
+ /*
+ ** test6:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	trn1	p0\.d, \1\.d, p[0-3]\.d
+ **	ret
+ */
+ svbool_t
+ test6 ()
+ {
+   return svtrn1_b64 (svptrue_b64 (), svptrue_b8 ());
+ }
+ 
+ #ifdef __cplusplus
+ }
+ #endif
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_3.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_3.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_3.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_3.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,96 ----
+ /* { dg-options "-O2" } */
+ /* { dg-final { check-function-bodies "**" "" } } */
+ 
+ #include 
+ 
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+ 
+ /*
+ ** test1:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	trn2	p0\.h, p[0-3]\.h, \1\.h
+ **	ret
+ */
+ svbool_t
+ test1 ()
+ {
+   return svtrn2_b16 (svptrue_b8 (), svptrue_b16 ());
+ }
+ 
+ /*
+ ** test2:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	trn2	p0\.h, \1\.h, p[0-3]\.h
+ **	ret
+ */
+ svbool_t
+ test2 ()
+ {
+   return svtrn2_b16 (svptrue_b16 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test3:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	trn2	p0\.s, p[0-3]\.s, \1\.s
+ **	ret
+ */
+ svbool_t
+ test3 ()
+ {
+   return svtrn2_b32 (svptrue_b8 (), svptrue_b32 ());
+ }
+ 
+ /*
+ ** test4:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	trn2	p0\.s, \1\.s, p[0-3]\.s
+ **	ret
+ */
+ svbool_t
+ test4 ()
+ {
+   return svtrn2_b32 (svptrue_b32 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test5:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	trn2	p0\.d, p[0-3]\.d, \1\.d
+ **	ret
+ */
+ svbool_t
+ test5 ()
+ {
+   return svtrn2_b64 (svptrue_b8 (), svptrue_b64 ());
+ }
+ 
+ /*
+ ** test6:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	trn2	p0\.d, \1\.d, p[0-3]\.d
+ **	ret
+ */
+ svbool_t
+ test6 ()
+ {
+   return svtrn2_b64 (svptrue_b64 (), svptrue_b8 ());
+ }
+ 
+ #ifdef __cplusplus
+ }
+ #endif
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_4.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_4.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_4.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_4.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,96 ----
+ /* { dg-options "-O2" } */
+ /* { dg-final { check-function-bodies "**" "" } } */
+ 
+ #include 
+ 
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+ 
+ /*
+ ** test1:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	zip1	p0\.h, p[0-3]\.h, \1\.h
+ **	ret
+ */
+ svbool_t
+ test1 ()
+ {
+   return svzip1_b16 (svptrue_b8 (), svptrue_b16 ());
+ }
+ 
+ /*
+ ** test2:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	zip1	p0\.h, \1\.h, p[0-3]\.h
+ **	ret
+ */
+ svbool_t
+ test2 ()
+ {
+   return svzip1_b16 (svptrue_b16 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test3:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	zip1	p0\.s, p[0-3]\.s, \1\.s
+ **	ret
+ */
+ svbool_t
+ test3 ()
+ {
+   return svzip1_b32 (svptrue_b8 (), svptrue_b32 ());
+ }
+ 
+ /*
+ ** test4:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	zip1	p0\.s, \1\.s, p[0-3]\.s
+ **	ret
+ */
+ svbool_t
+ test4 ()
+ {
+   return svzip1_b32 (svptrue_b32 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test5:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	zip1	p0\.d, p[0-3]\.d, \1\.d
+ **	ret
+ */
+ svbool_t
+ test5 ()
+ {
+   return svzip1_b64 (svptrue_b8 (), svptrue_b64 ());
+ }
+ 
+ /*
+ ** test6:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	zip1	p0\.d, \1\.d, p[0-3]\.d
+ **	ret
+ */
+ svbool_t
+ test6 ()
+ {
+   return svzip1_b64 (svptrue_b64 (), svptrue_b8 ());
+ }
+ 
+ #ifdef __cplusplus
+ }
+ #endif
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_5.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_5.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_5.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_5.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,96 ----
+ /* { dg-options "-O2" } */
+ /* { dg-final { check-function-bodies "**" "" } } */
+ 
+ #include 
+ 
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+ 
+ /*
+ ** test1:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	zip2	p0\.h, p[0-3]\.h, \1\.h
+ **	ret
+ */
+ svbool_t
+ test1 ()
+ {
+   return svzip2_b16 (svptrue_b8 (), svptrue_b16 ());
+ }
+ 
+ /*
+ ** test2:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	zip2	p0\.h, \1\.h, p[0-3]\.h
+ **	ret
+ */
+ svbool_t
+ test2 ()
+ {
+   return svzip2_b16 (svptrue_b16 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test3:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	zip2	p0\.s, p[0-3]\.s, \1\.s
+ **	ret
+ */
+ svbool_t
+ test3 ()
+ {
+   return svzip2_b32 (svptrue_b8 (), svptrue_b32 ());
+ }
+ 
+ /*
+ ** test4:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	zip2	p0\.s, \1\.s, p[0-3]\.s
+ **	ret
+ */
+ svbool_t
+ test4 ()
+ {
+   return svzip2_b32 (svptrue_b32 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test5:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	zip2	p0\.d, p[0-3]\.d, \1\.d
+ **	ret
+ */
+ svbool_t
+ test5 ()
+ {
+   return svzip2_b64 (svptrue_b8 (), svptrue_b64 ());
+ }
+ 
+ /*
+ ** test6:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	zip2	p0\.d, \1\.d, p[0-3]\.d
+ **	ret
+ */
+ svbool_t
+ test6 ()
+ {
+   return svzip2_b64 (svptrue_b64 (), svptrue_b8 ());
+ }
+ 
+ #ifdef __cplusplus
+ }
+ #endif
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_6.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_6.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_6.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_6.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,96 ----
+ /* { dg-options "-O2" } */
+ /* { dg-final { check-function-bodies "**" "" } } */
+ 
+ #include 
+ 
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+ 
+ /*
+ ** test1:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	uzp1	p0\.h, p[0-3]\.h, \1\.h
+ **	ret
+ */
+ svbool_t
+ test1 ()
+ {
+   return svuzp1_b16 (svptrue_b8 (), svptrue_b16 ());
+ }
+ 
+ /*
+ ** test2:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	uzp1	p0\.h, \1\.h, p[0-3]\.h
+ **	ret
+ */
+ svbool_t
+ test2 ()
+ {
+   return svuzp1_b16 (svptrue_b16 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test3:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	uzp1	p0\.s, p[0-3]\.s, \1\.s
+ **	ret
+ */
+ svbool_t
+ test3 ()
+ {
+   return svuzp1_b32 (svptrue_b8 (), svptrue_b32 ());
+ }
+ 
+ /*
+ ** test4:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	uzp1	p0\.s, \1\.s, p[0-3]\.s
+ **	ret
+ */
+ svbool_t
+ test4 ()
+ {
+   return svuzp1_b32 (svptrue_b32 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test5:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	uzp1	p0\.d, p[0-3]\.d, \1\.d
+ **	ret
+ */
+ svbool_t
+ test5 ()
+ {
+   return svuzp1_b64 (svptrue_b8 (), svptrue_b64 ());
+ }
+ 
+ /*
+ ** test6:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	uzp1	p0\.d, \1\.d, p[0-3]\.d
+ **	ret
+ */
+ svbool_t
+ test6 ()
+ {
+   return svuzp1_b64 (svptrue_b64 (), svptrue_b8 ());
+ }
+ 
+ #ifdef __cplusplus
+ }
+ #endif
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_7.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_7.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_7.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/perm_7.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,96 ----
+ /* { dg-options "-O2" } */
+ /* { dg-final { check-function-bodies "**" "" } } */
+ 
+ #include 
+ 
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+ 
+ /*
+ ** test1:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	uzp2	p0\.h, p[0-3]\.h, \1\.h
+ **	ret
+ */
+ svbool_t
+ test1 ()
+ {
+   return svuzp2_b16 (svptrue_b8 (), svptrue_b16 ());
+ }
+ 
+ /*
+ ** test2:
+ **	...
+ **	ptrue	(p[0-3])\.h, all
+ **	...
+ **	uzp2	p0\.h, \1\.h, p[0-3]\.h
+ **	ret
+ */
+ svbool_t
+ test2 ()
+ {
+   return svuzp2_b16 (svptrue_b16 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test3:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	uzp2	p0\.s, p[0-3]\.s, \1\.s
+ **	ret
+ */
+ svbool_t
+ test3 ()
+ {
+   return svuzp2_b32 (svptrue_b8 (), svptrue_b32 ());
+ }
+ 
+ /*
+ ** test4:
+ **	...
+ **	ptrue	(p[0-3])\.s, all
+ **	...
+ **	uzp2	p0\.s, \1\.s, p[0-3]\.s
+ **	ret
+ */
+ svbool_t
+ test4 ()
+ {
+   return svuzp2_b32 (svptrue_b32 (), svptrue_b8 ());
+ }
+ 
+ /*
+ ** test5:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	uzp2	p0\.d, p[0-3]\.d, \1\.d
+ **	ret
+ */
+ svbool_t
+ test5 ()
+ {
+   return svuzp2_b64 (svptrue_b8 (), svptrue_b64 ());
+ }
+ 
+ /*
+ ** test6:
+ **	...
+ **	ptrue	(p[0-3])\.d, all
+ **	...
+ **	uzp2	p0\.d, \1\.d, p[0-3]\.d
+ **	ret
+ */
+ svbool_t
+ test6 ()
+ {
+   return svuzp2_b64 (svptrue_b64 (), svptrue_b8 ());
+ }
+ 
+ #ifdef __cplusplus
+ }
+ #endif
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr121118_1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr121118_1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr121118_1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/pr121118_1.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,16 ----
+ /* { dg-options "-O2 -msve-vector-bits=512" } */
+ 
+ typedef __SVBool_t fixed_bool __attribute__((arm_sve_vector_bits(512)));
+ 
+ #define TEST_CONST(NAME, CONST)						\
+   fixed_bool								\
+   NAME ()								\
+   {									\
+     union { unsigned long long i; fixed_bool pg; } u = { CONST };	\
+     return u.pg;							\
+   }
+ 
+ TEST_CONST (test1, 0x02aaaaaaaa)
+ TEST_CONST (test2, 0x0155555557)
+ TEST_CONST (test3, 0x0013333333333333ULL)
+ TEST_CONST (test4, 0x0011111111111113ULL)
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/rev_2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/rev_2.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/acle/general/rev_2.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/acle/general/rev_2.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,27 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O2" } */
+ 
+ #include 
+ 
+ svbool_t test1()
+ {
+   return svrev_b16 (svptrue_b16 ());
+ }
+ 
+ svbool_t test2()
+ {
+   return svrev_b32 (svptrue_b32 ());
+ }
+ 
+ svbool_t test3()
+ {
+   return svrev_b64 (svptrue_b64 ());
+ }
+ 
+ /* { dg-final { scan-assembler {\tptrue\tp[0-7]\.h} } } */
+ /* { dg-final { scan-assembler {\tptrue\tp[0-7]\.s} } } */
+ /* { dg-final { scan-assembler {\tptrue\tp[0-7]\.d} } } */
+ /* { dg-final { scan-assembler-not {\tptrue\tp[0-7]\.b} } } */
+ /* { dg-final { scan-assembler {\trev\tp0\.h} } } */
+ /* { dg-final { scan-assembler {\trev\tp0\.s} } } */
+ /* { dg-final { scan-assembler {\trev\tp0\.d} } } */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/pr122724.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/pr122724.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/sve/pr122724.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/sve/pr122724.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,13 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O2" } */
+ _Float16 in[128];
+ short out[128];
+ void foo(void) {
+   for (int i = 0; i < 128; i++) {
+     _Float16 x = in[i];
+     _Float16 y = x ? -x : 0.0;
+     short dst;
+     __builtin_memcpy (&dst, &y, sizeof(dst));
+     out[i] = dst;
+   }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/torture/pr121772.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/torture/pr121772.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/torture/pr121772.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/torture/pr121772.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,6 ----
+ /* { dg-do compile } */
+ /* { dg-options "-fchecking" } */
+ #include 
+ int16_t f(int16x4_t b) {
+   return vaddvq_s16(vcombine_s16(b, vdup_n_s16 (0)));
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/torture/pr125621.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/torture/pr125621.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/torture/pr125621.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/torture/pr125621.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,7 ----
+ /* { dg-do compile } */
+ /* { dg-options "-march=armv8.2-a+sve -fsanitize=undefined" } */
+ #include 
+ 
+ long foo(long x) {
+   return (long)svcntd() * x;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/torture/pr125818.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/torture/pr125818.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/aarch64/torture/pr125818.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/aarch64/torture/pr125818.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,6 ----
+ /* { dg-do compile } */
+ /* { dg-additional-options "-march=armv8.2-a+sve" } */
+ #include 
+ void f(svfloat32x2_t *tp, const svfloat32x2_t *tuple, const svfloat32_t *vp) {
+   *tp = svset2_f32(*tuple, 0, *vp);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/arm/armv8_2-fp16-move-1.c	Fri Sep  4 07:35:10 2026
***************
*** 8,14 ****
  /*
  **test_load_1:
  **	...
! **	vld1.16	{d[0-9]+\[[0-9]+\]}, \[r[0-9]+\]
  **	...
  */
  __fp16
--- 8,14 ----
  /*
  **test_load_1:
  **	...
! **	vldr.16	s[0-9]+, \[r[0-9]+\]
  **	...
  */
  __fp16
*************** test_load_1 (__fp16* a)
*** 20,26 ****
  /*
  **test_load_2:
  **	...
! **	vld1.16	{d[0-9]+\[[0-9]+\]}, \[r[0-9]+\]
  **	...
  */
  __fp16
--- 20,26 ----
  /*
  **test_load_2:
  **	...
! **	vldr.16	s[0-9]+, \[r[0-9]+\]
  **	...
  */
  __fp16
*************** test_load_2 (__fp16* a, int i)
*** 32,38 ****
  /*
  **test_store_1:
  **	...
! **	vst1.16	{d[0-9]+\[[0-9]+\]}, \[r[0-9]+\]
  **	...
  */
  void
--- 32,38 ----
  /*
  **test_store_1:
  **	...
! **	vstr.16	s[0-9]+, \[r[0-9]+\]
  **	...
  */
  void
*************** test_store_1 (__fp16* a, __fp16 b)
*** 44,50 ****
  /*
  **test_store_2:
  **	...
! **	vst1.16	{d[0-9]+\[[0-9]+\]}, \[r[0-9]+\]
  **	...
  */
  void
--- 44,50 ----
  /*
  **test_store_2:
  **	...
! **	vstr.16	s[0-9]+, \[r[0-9]+\]
  **	...
  */
  void
*************** test_store_2 (__fp16* a, int i, __fp16 b
*** 56,64 ****
  /*
  **test_load_store_1:
  **	...
! **	vld1.16	{d[0-9]+\[[0-9]+\]}, \[r[0-9]+\]
  **	...
! **	vst1.16	{d[0-9]+\[[0-9]+\]}, \[r[0-9]+\]
  **	...
  */
  __fp16
--- 56,64 ----
  /*
  **test_load_store_1:
  **	...
! **	vldr.16	s[0-9]+, \[r[0-9]+\]
  **	...
! **	vstr.16	s[0-9]+, \[r[0-9]+\]
  **	...
  */
  __fp16
*************** test_load_store_1 (__fp16* a, int i, __f
*** 70,78 ****
  /*
  **test_load_store_2:
  **	...
! **	vld1.16	{d[0-9]+\[[0-9]+\]}, \[r[0-9]+\]
  **	...
! **	vst1.16	{d[0-9]+\[[0-9]+\]}, \[r[0-9]+\]
  **	...
  */
  __fp16
--- 70,78 ----
  /*
  **test_load_store_2:
  **	...
! **	vldr.16	s[0-9]+, \[r[0-9]+\, #4]
  **	...
! **	vstr.16	s[0-9]+, \[r[0-9]+\]
  **	...
  */
  __fp16
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/arm/cbz-range.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/arm/cbz-range.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/arm/cbz-range.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/arm/cbz-range.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,114 ----
+ /* { dg-do assemble } */
+ /* { dg-require-effective-target arm_arch_v7a_ok } */
+ /* { dg-options "-O -mthumb" } */
+ /* { dg-add-options arm_arch_v7a } */
+ 
+ #define f "movw r0, #0;movw r0, #0;movw r0, #0;"
+ #define f2 f f
+ #define f4 f2 f2
+ #define f8 f4 f4
+ #define f16 f8 f8
+ #define f32 f16 f16
+ #define f64 f32 f32
+ #define f128 f64 f64
+ #define f256 f128 f128
+ #define f512 f256 f256
+ #define f1024 f512 f512
+ #define f2048 f1024 f1024
+ #define f4096 f2048 f2048
+ #define f8192 f4096 f4096
+ #define f16384 f8192 f8192
+ #define f32768 f16384 f16384
+ #define f65536 f32768 f32768
+ #define f131072 f65536 f65536
+ int a;
+ 
+ int cbz1(int g)
+ {
+   if (g)
+     asm(f8);
+   return a;
+ }
+ 
+ int cbz2(int g)
+ {
+   asm ("": "+h"(g));
+   if (g)
+     asm(f8);
+   return a;
+ }
+ 
+ int cbz3(int g)
+ {
+   if (g)
+     asm(f16);
+   return a;
+ }
+ 
+ int cbz4(int g)
+ {
+   asm ("": "+h"(g));
+   if (g)
+     asm(f16);
+   return a;
+ }
+ 
+ int cbz5(int g)
+ {
+   if (g)
+     asm(f131072);
+   return a;
+ }
+ 
+ int cbz6(int g)
+ {
+   asm ("": "+h"(g));
+   if (g)
+     asm(f131072);
+   return a;
+ }
+ 
+ int cbnz1(int g)
+ {
+   if (!g)
+     asm(f8);
+   return a;
+ }
+ 
+ int cbnz2(int g)
+ {
+   asm ("": "+h"(g));
+   if (!g)
+     asm(f8);
+   return a;
+ }
+ 
+ int cbnz3(int g)
+ {
+   if (!g)
+     asm(f16);
+   return a;
+ }
+ 
+ int cbnz4(int g)
+ {
+   asm ("": "+h"(g));
+   if (!g)
+     asm(f16);
+   return a;
+ }
+ 
+ int cbnz5(int g)
+ {
+   if (!g)
+     asm(f131072);
+   return a;
+ }
+ 
+ int cbnz6(int g)
+ {
+   asm ("": "+h"(g));
+   if (!g)
+     asm(f131072);
+   return a;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/arm/mve/intrinsics/pr122223.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/arm/mve/intrinsics/pr122223.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/arm/mve/intrinsics/pr122223.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/arm/mve/intrinsics/pr122223.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,31 ----
+ /* { dg-require-effective-target arm_v8_1m_mve_fp_ok } */
+ /* { dg-add-options arm_v8_1m_mve_fp } */
+ /* { dg-additional-options "-O2" } */
+ /* { dg-final { check-function-bodies "**" "" } } */
+ 
+ /* PR target/122223.  */
+ 
+ #include 
+ 
+ #ifdef __cplusplus
+ extern "C" {
+ #endif
+ 
+ /*
+ **foo:
+ **	...
+ **	vmov.f32	(q[0-9]+), #0.0  @ v4sf
+ **	...
+ **	vbic	q[0-9]+, q[0-9]+, \1
+ **	...
+ */
+ float32x4_t foo() {
+   float32x4_t a = vdupq_n_f32(1.0f); /* 0x3f800000 */
+   float32x4_t b = vbicq_f32(a, a);   /* 0x3f800000 & ~0x3f800000 => 0x00000000 */
+   float32x4_t c = vbicq_f32(a, b);   /* 0x3f800000 & ~0x00000000 => 0x3f800000 */
+   return c;
+ }
+ 
+ #ifdef __cplusplus
+ }
+ #endif
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/arm/pr123271.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/arm/pr123271.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/arm/pr123271.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/arm/pr123271.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,20 ----
+ /* { dg-options "-O2 -ftrapv" } */
+ /* { dg-final { check-function-bodies "**" "" "" } } */
+ 
+ int sub(int a, int b)
+ {
+   return a - b;
+ }
+ 
+ /*
+ ** sub:
+ ** ...
+ ** (
+ **	bl	__subvsi3
+ ** |
+    Not generated yet, but would be equally acceptable.
+ **	subs	r0, r0, r1
+ **	bv[sc]	.*
+ ** )
+ ** ...
+ */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/arm/pr124933.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/arm/pr124933.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/arm/pr124933.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/arm/pr124933.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,17 ----
+ /* { dg-require-effective-target arm_arch_v8_1m_main_fp_hard_ok } */
+ /* { dg-add-options arm_arch_v8_1m_main_fp_hard } */
+ /* { dg-additional-options "-O2 -mfp16-format=ieee" } */
+ /* { dg-do assemble } */
+ 
+ __fp16 f;
+ __fp16 g;
+ 
+ void __attribute__((noinline,noclone)) h (__fp16 x)
+ {
+   g = x;
+ }
+ 
+ void __attribute__((noinline,noclone)) i ()
+ {
+   h (f);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-ssk.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-ssk.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-ssk.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-ssk.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,8 ----
+ /* { dg-do link { target { ! avr_tiny } } } */
+ /* { dg-additional-options "-std=gnu99 -Wno-pedantic" } */
+ 
+ #define TT __int24
+ #define UU signed
+ #define FX _Accum
+ 
+ #include "pr125409.h"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-ssr.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-ssr.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-ssr.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-ssr.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,8 ----
+ /* { dg-do link { target { ! avr_tiny } } } */
+ /* { dg-additional-options "-std=gnu99 -Wno-pedantic" } */
+ 
+ #define TT __int24
+ #define UU signed
+ #define FX _Fract
+ 
+ #include "pr125409.h"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-suk.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-suk.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-suk.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-suk.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,8 ----
+ /* { dg-do link { target { ! avr_tiny } } } */
+ /* { dg-additional-options "-std=gnu99 -Wno-pedantic" } */
+ 
+ #define TT __int24
+ #define UU unsigned
+ #define FX _Accum
+ 
+ #include "pr125409.h"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-sur.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-sur.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-sur.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-sur.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,8 ----
+ /* { dg-do link { target { ! avr_tiny } } } */
+ /* { dg-additional-options "-std=gnu99 -Wno-pedantic" } */
+ 
+ #define TT __int24
+ #define UU unsigned
+ #define FX _Fract
+ 
+ #include "pr125409.h"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-usk.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-usk.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-usk.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-usk.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,8 ----
+ /* { dg-do link { target { ! avr_tiny } } } */
+ /* { dg-additional-options "-std=gnu99 -Wno-pedantic" } */
+ 
+ #define TT __uint24
+ #define UU signed
+ #define FX _Accum
+ 
+ #include "pr125409.h"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-usr.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-usr.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-usr.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-usr.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,8 ----
+ /* { dg-do link { target { ! avr_tiny } } } */
+ /* { dg-additional-options "-std=gnu99 -Wno-pedantic" } */
+ 
+ #define TT __uint24
+ #define UU signed
+ #define FX _Fract
+ 
+ #include "pr125409.h"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-uuk.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-uuk.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-uuk.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-uuk.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,8 ----
+ /* { dg-do link { target { ! avr_tiny } } } */
+ /* { dg-additional-options "-std=gnu99 -Wno-pedantic" } */
+ 
+ #define TT __uint24
+ #define UU unsigned
+ #define FX _Accum
+ 
+ #include "pr125409.h"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-uur.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-uur.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-uur.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409-fx24-uur.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,8 ----
+ /* { dg-do link { target { ! avr_tiny } } } */
+ /* { dg-additional-options "-std=gnu99 -Wno-pedantic" } */
+ 
+ #define TT __uint24
+ #define UU unsigned
+ #define FX _Fract
+ 
+ #include "pr125409.h"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409.h gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409.h
*** gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr125409.h	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr125409.h	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,16 ----
+ UU FX fx_fun (TT x) { return x; }
+ TT fun_fx (UU FX x) { return x; }
+ 
+ short UU FX hfx_fun (TT x) { return x; }
+ TT fun_hfx (UU short FX x) { return x; }
+ 
+ long UU FX lfx_fun (TT x) { return x; }
+ TT fun_lfx (UU long FX x) { return x; }
+ 
+ long long UU FX llfx_fun (TT x) { return x; }
+ TT fun_llfx (UU long long FX x) { return x; }
+ 
+ int main (void)
+ {
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr127098.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr127098.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/avr/torture/pr127098.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/avr/torture/pr127098.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,21 ----
+ /* { dg-do run } */
+ 
+ #define NI __attribute((noipa))
+ 
+ typedef char U __attribute__ ((vector_size (16)));
+ 
+ NI void fun (long i, U u)
+ {
+   (void) i;
+   if (u[0] != 1)
+     __builtin_abort ();
+ }
+ 
+ U u = { 1 };
+ 
+ int main (void)
+ {
+   fun (0, u);
+ 
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/amxbf16-asmintel-1.c	Fri Sep  4 07:35:10 2026
***************
*** 1,7 ****
  /* { dg-do compile { target { ! ia32 } } } */
  /* { dg-require-effective-target masm_intel } */
  /* { dg-options "-O2 -mamx-bf16 -masm=intel" } */
! /* { dg-final { scan-assembler "tdpbf16ps\[ \\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3"  } } */
  #include 
  
  void TEST ()
--- 1,7 ----
  /* { dg-do compile { target { ! ia32 } } } */
  /* { dg-require-effective-target masm_intel } */
  /* { dg-options "-O2 -mamx-bf16 -masm=intel" } */
! /* { dg-final { scan-assembler "tdpbf16ps\[ \\t]+\[^\n%\]*tmm1+\[^\n%\]*tmm2+\[^\n%\]*tmm3"  } } */
  #include 
  
  void TEST ()
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/amxcomplex-asmintel-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/amxcomplex-asmintel-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/amxcomplex-asmintel-1.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/amxcomplex-asmintel-1.c	Fri Sep  4 07:35:10 2026
***************
*** 1,8 ****
  /* { dg-do compile { target { ! ia32 } } } */
  /* { dg-require-effective-target masm_intel } */
  /* { dg-options "-O2 -mamx-complex -masm=intel" } */
! /* { dg-final { scan-assembler "tcmmimfp16ps\[ \\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3"  } } */
! /* { dg-final { scan-assembler "tcmmrlfp16ps\[ \\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3"  } } */
  #include 
  
  void TEST()
--- 1,8 ----
  /* { dg-do compile { target { ! ia32 } } } */
  /* { dg-require-effective-target masm_intel } */
  /* { dg-options "-O2 -mamx-complex -masm=intel" } */
! /* { dg-final { scan-assembler "tcmmimfp16ps\[ \\t]+\[^\n%\]*tmm1+\[^\n%\]*tmm2+\[^\n%\]*tmm3"  } } */
! /* { dg-final { scan-assembler "tcmmrlfp16ps\[ \\t]+\[^\n%\]*tmm1+\[^\n%\]*tmm2+\[^\n%\]*tmm3"  } } */
  #include 
  
  void TEST()
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/amxfp16-asmintel-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/amxfp16-asmintel-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/amxfp16-asmintel-1.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/amxfp16-asmintel-1.c	Fri Sep  4 07:35:10 2026
***************
*** 1,7 ****
  /* { dg-do compile { target { ! ia32 } } } */
  /* { dg-require-effective-target masm_intel } */
  /* { dg-options "-O2 -mamx-fp16 -masm=intel" } */
! /* { dg-final { scan-assembler "tdpfp16ps\[ \\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3"  } } */
  #include 
  
  void TEST ()
--- 1,7 ----
  /* { dg-do compile { target { ! ia32 } } } */
  /* { dg-require-effective-target masm_intel } */
  /* { dg-options "-O2 -mamx-fp16 -masm=intel" } */
! /* { dg-final { scan-assembler "tdpfp16ps\[ \\t]+\[^\n%\]*tmm1+\[^\n%\]*tmm2+\[^\n%\]*tmm3"  } } */
  #include 
  
  void TEST ()
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/amxint8-asmintel-1.c	Fri Sep  4 07:35:10 2026
***************
*** 1,10 ****
  /* { dg-do compile { target { ! ia32 } } } */
  /* { dg-require-effective-target masm_intel } */
  /* { dg-options "-O2 -mamx-int8 -masm=intel" } */
! /* { dg-final { scan-assembler "tdpbssd\[ \\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3"  } } */
! /* { dg-final { scan-assembler "tdpbsud\[ \\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3"  } } *
! /* { dg-final { scan-assembler "tdpbusd\[ \\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3"  } } */
! /* { dg-final { scan-assembler "tdpbuud\[ \\t]+\[^\n\]*%tmm1+\[^\n\]*%tmm2+\[^\n\]*%tmm3"  } } */
  #include 
  
  void TEST ()
--- 1,10 ----
  /* { dg-do compile { target { ! ia32 } } } */
  /* { dg-require-effective-target masm_intel } */
  /* { dg-options "-O2 -mamx-int8 -masm=intel" } */
! /* { dg-final { scan-assembler "tdpbssd\[ \\t]+\[^\n%\]*tmm1+\[^\n%\]*tmm2+\[^\n%\]*tmm3"  } } */
! /* { dg-final { scan-assembler "tdpbsud\[ \\t]+\[^\n%\]*tmm1+\[^\n%\]*tmm2+\[^\n%\]*tmm3"  } } */
! /* { dg-final { scan-assembler "tdpbusd\[ \\t]+\[^\n%\]*tmm1+\[^\n%\]*tmm2+\[^\n%\]*tmm3"  } } */
! /* { dg-final { scan-assembler "tdpbuud\[ \\t]+\[^\n%\]*tmm1+\[^\n%\]*tmm2+\[^\n%\]*tmm3"  } } */
  #include 
  
  void TEST ()
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c	Thu Jun  5 16:03:00 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/amxtile-asmintel-1.c	Fri Sep  4 07:35:10 2026
***************
*** 4,13 ****
  /* { dg-final { scan-assembler "ldtilecfg\[ \\t]"  } } */
  /* { dg-final { scan-assembler "sttilecfg\[ \\t]"  } } */
  /* { dg-final { scan-assembler "tilerelease"  } } */
! /* { dg-final { scan-assembler "tileloadd\[ \\t]%tmm\[0-9\]"  } } */
! /* { dg-final { scan-assembler "tileloaddt1\[ \\t]%tmm\[0-9\]"  } } */
! /* { dg-final { scan-assembler "tilestored\[ \\t]\[^\n\]+\[^\n\]*%tmm\[0-9\]"  } } */
! /* { dg-final { scan-assembler "tilezero\[ \\t]+\[^\n\]*%tmm\[0-9\]"  } } */
  #include 
  
  extern int a[];
--- 4,13 ----
  /* { dg-final { scan-assembler "ldtilecfg\[ \\t]"  } } */
  /* { dg-final { scan-assembler "sttilecfg\[ \\t]"  } } */
  /* { dg-final { scan-assembler "tilerelease"  } } */
! /* { dg-final { scan-assembler "tileloadd\[ \\t]tmm\[0-9\]"  } } */
! /* { dg-final { scan-assembler "tileloaddt1\[ \\t]tmm\[0-9\]"  } } */
! /* { dg-final { scan-assembler "tilestored\[ \\t]\[^\n\]+\[^\n\]*tmm\[0-9\]"  } } */
! /* { dg-final { scan-assembler "tilezero\[ \\t]+\[^\n%\]*tmm\[0-9\]"  } } */
  #include 
  
  extern int a[];
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/avx2-pr126446.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/avx2-pr126446.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/avx2-pr126446.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/avx2-pr126446.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,14 ----
+ /* PR target/126446 */
+ /* { dg-do compile } */
+ /* { dg-options "-O1 -mavx2" } */
+ 
+ typedef signed char V __attribute__((vector_size (16)));
+ 
+ signed char
+ foo ()
+ {
+   V b = {};
+   long long c = ~2878966870562407444LL;
+   b[c] = 1;
+   return b[0];
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/avx512f-pr124138-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/avx512f-pr124138-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/avx512f-pr124138-1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/avx512f-pr124138-1.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,24 ----
+ /* PR target/124138 */
+ /* { dg-do run } */
+ /* { dg-options "-mavx512f" } */
+ /* { dg-require-effective-target avx512f } */
+ 
+ #define AVX512F
+ #include "avx512f-helper.h"
+ 
+ typedef __attribute__((__vector_size__ (64))) unsigned long long V;
+ 
+ [[gnu::noipa]] V
+ foo (V x)
+ {
+   return __builtin_shuffle (x, (V) { 0, 1, 2, 5, 4, 5, 6, 7 });
+ }
+ 
+ void
+ TEST ()
+ {
+   V x = foo ((V) { 1, 2, 3, 4, 5, 6, 7, 8 });
+   if (x[0] != 1 || x[1] != 2 || x[2] != 3 || x[3] != 6
+       || x[4] != 5 || x[5] != 6 || x[6] != 7 || x[7] != 8)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/avx512f-pr124138-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/avx512f-pr124138-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/avx512f-pr124138-2.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/avx512f-pr124138-2.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,25 ----
+ /* PR target/124138 */
+ /* { dg-do run } */
+ /* { dg-options "-mavx512f" } */
+ /* { dg-require-effective-target avx512f } */
+ 
+ #define AVX512F
+ #include "avx512f-helper.h"
+ 
+ typedef __attribute__((__vector_size__ (64))) unsigned long long V;
+ typedef __attribute__((__vector_size__ (64))) double W;
+ 
+ [[gnu::noipa]] W
+ foo (W x)
+ {
+   return __builtin_shuffle (x, (V) { 0, 1, 2, 5, 4, 5, 6, 7 });
+ }
+ 
+ void
+ TEST ()
+ {
+   W x = foo ((W) { 1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5 });
+   if (x[0] != 1.5 || x[1] != 2.5 || x[2] != 3.5 || x[3] != 6.5
+       || x[4] != 5.5 || x[5] != 6.5 || x[6] != 7.5 || x[7] != 8.5)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/avx512f-pr124315.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/avx512f-pr124315.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/avx512f-pr124315.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/avx512f-pr124315.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,33 ----
+ /* PR target/124315 */
+ /* { dg-do compile { target masm_intel } } */
+ /* { dg-options "-O2 -mavx512f -masm=intel" } */
+ /* { dg-final { scan-assembler "\tvfmadd231sd\txmm0{k\[0-7]}, xmm1, xmm2, {ru-sae}" } } */
+ /* { dg-final { scan-assembler "\tvfmsub231sd\txmm0{k\[0-7]}, xmm1, xmm2, {ru-sae}" } } */
+ /* { dg-final { scan-assembler "\tvfnmadd231sd\txmm0{k\[0-7]}, xmm1, xmm2, {ru-sae}" } } */
+ /* { dg-final { scan-assembler "\tvfnmsub231sd\txmm0{k\[0-7]}, xmm1, xmm2, {ru-sae}" } } */
+ 
+ #include 
+ 
+ __m128d
+ foo (__m128d b, __m128d w, __m128d a,  __mmask8 u)
+ {
+   return _mm_mask3_fmadd_round_sd (w, a, b, u, _MM_FROUND_TO_POS_INF | _MM_FROUND_NO_EXC);
+ }
+ 
+ __m128d
+ bar (__m128d b, __m128d w, __m128d a, __mmask8 u)
+ {
+   return _mm_mask3_fmsub_round_sd (w, a, b, u, _MM_FROUND_TO_POS_INF | _MM_FROUND_NO_EXC);
+ }
+ 
+ __m128d
+ baz (__m128d b, __m128d w, __m128d a,  __mmask8 u)
+ {
+   return _mm_mask3_fnmadd_round_sd (w, a, b, u, _MM_FROUND_TO_POS_INF | _MM_FROUND_NO_EXC);
+ }
+ 
+ __m128d
+ qux (__m128d b, __m128d w, __m128d a,  __mmask8 u)
+ {
+   return _mm_mask3_fnmsub_round_sd (w, a, b, u, _MM_FROUND_TO_POS_INF | _MM_FROUND_NO_EXC);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/avx512fp16-pr124335.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/avx512fp16-pr124335.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/avx512fp16-pr124335.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/avx512fp16-pr124335.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,13 ----
+ /* PR target/124335 */
+ /* { dg-do assemble } */
+ /* { dg-require-effective-target masm_intel } */
+ /* { dg-options "-mavx512fp16 -masm=intel" } */
+ /* { dg-require-effective-target avx512fp16 } */
+ 
+ #include 
+ 
+ __m128h
+ foo (_Float16 const *x, __mmask8 y)
+ {
+   return _mm_maskz_load_sh (y, x);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/cet-pr124366.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/cet-pr124366.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/cet-pr124366.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/cet-pr124366.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,31 ----
+ /* PR target/124366 */
+ /* { dg-do assemble { target { cet && masm_intel } } } */
+ /* { dg-options "-O2 -mshstk -masm=intel" } */
+ 
+ #include 
+ 
+ void
+ wrssd (unsigned int x, void *y)
+ {
+   _wrssd (x, y);
+ }
+ 
+ void
+ wrussd (unsigned int x, void *y)
+ {
+   _wrussd (x, y);
+ }
+ 
+ #ifdef __x86_64__
+ void
+ wrssq (unsigned long long x, void *y)
+ {
+   _wrssq (x, y);
+ }
+ 
+ void
+ wrussq (unsigned long long x, void *y)
+ {
+   _wrussq (x, y);
+ }
+ #endif
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/cold-attribute-4.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/cold-attribute-4.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/cold-attribute-4.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/cold-attribute-4.c	Fri Sep  4 07:35:10 2026
***************
*** 1,5 ****
  /* { dg-do compile } */
! /* { dg-options "-O2" } */
  #include 
  
  int
--- 1,5 ----
  /* { dg-do compile } */
! /* { dg-options "-Oz" } */
  #include 
  
  int
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/keylocker-pr123217.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/keylocker-pr123217.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/keylocker-pr123217.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/keylocker-pr123217.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,13 ----
+ /* PR target/123217 */
+ /* { dg-do compile } */
+ /* { dg-options "-mkl -O0" } */
+ 
+ __attribute__((__vector_size__(16))) long long v, w;
+ 
+ unsigned
+ foo (void *p, void *q)
+ {
+   unsigned x = __builtin_ia32_encodekey128_u32 (0U, v, p);
+   unsigned y = __builtin_ia32_encodekey256_u32 (0U, v, w, q);
+   return x + y;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pieces-memcpy-18.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pieces-memcpy-18.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pieces-memcpy-18.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pieces-memcpy-18.c	Fri Sep  4 07:35:10 2026
***************
*** 1,5 ****
  /* { dg-do compile } */
! /* { dg-options "-O2 -march=sapphirerapids" } */
  
  extern char *dst, *src;
  
--- 1,5 ----
  /* { dg-do compile } */
! /* { dg-options "-O2 -march=znver5" } */
  
  extern char *dst, *src;
  
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pieces-memcpy-21.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pieces-memcpy-21.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pieces-memcpy-21.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pieces-memcpy-21.c	Fri Sep  4 07:35:10 2026
***************
*** 1,5 ****
  /* { dg-do compile } */
! /* { dg-options "-O2 -mtune=sapphirerapids -march=x86-64 -mavx2" } */
  
  extern char *dst, *src;
  
--- 1,5 ----
  /* { dg-do compile } */
! /* { dg-options "-O2 -mtune=znver5 -march=x86-64 -mavx2" } */
  
  extern char *dst, *src;
  
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pieces-memset-46.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pieces-memset-46.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pieces-memset-46.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pieces-memset-46.c	Fri Sep  4 07:35:10 2026
***************
*** 1,5 ****
  /* { dg-do compile } */
! /* { dg-options "-O2 -march=sapphirerapids" } */
  
  extern char *dst;
  
--- 1,5 ----
  /* { dg-do compile } */
! /* { dg-options "-O2 -march=znver5" } */
  
  extern char *dst;
  
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pieces-memset-49.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pieces-memset-49.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pieces-memset-49.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pieces-memset-49.c	Fri Sep  4 07:35:10 2026
***************
*** 1,5 ****
  /* { dg-do compile } */
! /* { dg-options "-O2 -mtune=sapphirerapids -march=x86-64 -mavx2" } */
  
  extern char *dst;
  
--- 1,5 ----
  /* { dg-do compile } */
! /* { dg-options "-O2 -mtune=znver5 -march=x86-64 -mavx2" } */
  
  extern char *dst;
  
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120427-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120427-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120427-1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120427-1.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,28 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -mtune=sapphirerapids" } */
+ /* { dg-final { scan-assembler-not "and\[lq\]?\[\\t \]+\\\$0, \[0-9\]*\\(" } } */
+ 
+ struct __pthread_mutex_s
+ {
+   int __lock;
+   unsigned int __count;
+   int __owner;
+   unsigned int __nusers;
+   int __kind;
+   short __spins;
+   short __elision;
+   void *p[2];
+ };
+ typedef union
+ {
+   struct __pthread_mutex_s __data;
+   char __size[40];
+   long int __align;
+ } pthread_mutex_t;
+ typedef struct { pthread_mutex_t mutex; } __rtld_lock_recursive_t;
+ void
+ foo (__rtld_lock_recursive_t *lock, int i)
+ {
+   lock[i] = (__rtld_lock_recursive_t) {{ { 0, 0, 0, 0, 1,
+       0, 0, { ((void *)0) , ((void *)0) } } }};
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120427-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120427-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120427-2.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120427-2.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,28 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -mtune=sapphirerapids" } */
+ /* { dg-final { scan-assembler-not "or\[lq\]?\[\\t \]+\\\$-1, \[0-9\]*\\(" } } */
+ 
+ struct __pthread_mutex_s
+ {
+   int __lock;
+   unsigned int __count;
+   int __owner;
+   unsigned int __nusers;
+   int __kind;
+   short __spins;
+   short __elision;
+   void *p[2];
+ };
+ typedef union
+ {
+   struct __pthread_mutex_s __data;
+   char __size[40];
+   long int __align;
+ } pthread_mutex_t;
+ typedef struct { pthread_mutex_t mutex; } __rtld_lock_recursive_t;
+ void
+ foo (__rtld_lock_recursive_t *lock, int i)
+ {
+   lock[i] = (__rtld_lock_recursive_t) {{ { -1, -1, -1, -1, 1,
+       -1, -1, { ((void *)-1) , ((void *)-1) } } }};
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120427-3.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120427-3.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120427-3.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120427-3.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,45 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O2" } */
+ 
+ typedef int SItype __attribute__ ((mode (SI)));
+ typedef unsigned int USItype __attribute__ ((mode (SI)));
+ typedef unsigned int UDItype __attribute__ ((mode (DI)));
+ typedef UDItype __attribute__ ((__may_alias__)) bar_t;
+ 
+ static inline __attribute__((__always_inline__)) SItype
+ bar (const bar_t **p, SItype prec)
+ {
+   bar_t mslimb = 0;
+   SItype i = 20;
+   SItype n = ((USItype) prec) % 4;
+   if (n)
+     {
+       prec -= n;
+       if (prec == 0)
+ 	return 1;
+       mslimb = (*p)[i];
+     }
+   while (mslimb == 0)
+     {
+       prec -= 4;
+       if (prec == 0)
+ 	return 1;
+       --i;
+       mslimb = (*p)[i];
+     }
+   return prec;
+ }
+ UDItype
+ foo (const bar_t *i, SItype iprec)
+ {
+   iprec = bar (&i, iprec);
+   USItype aiprec = iprec < 0 ? -iprec : iprec;
+   bar_t msb = *i;
+   UDItype mantissa = 0;
+   if (aiprec % 4)
+     msb &= ((bar_t) 1 << aiprec) - 1;
+   if (aiprec >= 54)
+     mantissa = (UDItype) msb << 32;
+ 
+   return (mantissa ^ (UDItype) 0x20000000000000);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120427-4.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120427-4.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120427-4.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120427-4.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,6 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O2" } */
+ 
+ #include "cold-attribute-4.c"
+ 
+ /* { dg-final { scan-assembler "movl" } } */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120427-5.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120427-5.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120427-5.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120427-5.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,10 ----
+ /* { dg-do compile { target { ! ia32 } } } */
+ /* { dg-options "-Oz" } */
+ 
+ long long
+ func1 (void)
+ {
+   return -1;
+ }
+ /* { dg-final { scan-assembler-times "pushq\[ \\t\]+\\\$-1" 1 } } */
+ /* { dg-final { scan-assembler-times "popq\[ \\t\]+%rax" 1 } } */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120908.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120908.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr120908.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr120908.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,16 ----
+ /* { dg-do compile { target { lp64 && fpic } } } */
+ /* { dg-options "-O2 -fpic -mtls-dialect=gnu -mcmodel=large" } */
+ 
+ extern __thread long bar1;
+ long *
+ foo1 (void)
+ {
+   return &bar1;
+ }
+ 
+ static __thread long bar2;
+ long *
+ foo2 (void)
+ {
+   return &bar2;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-1a.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-1a.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-1a.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-1a.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,15 ----
+ /* { dg-do compile { target *-*-linux* } } */
+ /* { dg-options "-O2 -fPIC -mno-sse -mno-mmx -mno-80387 -mtls-dialect=gnu" } */
+ 
+ extern __thread int bar;
+ extern void func (void);
+ 
+ __attribute__((no_caller_saved_registers))
+ void
+ foo (int error)
+ {
+   bar = 1; /* { dg-error -mtls-dialect=gnu2 } */
+   if (error == 0)
+     func ();
+   bar = 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-1b.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-1b.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-1b.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-1b.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,4 ----
+ /* { dg-do compile { target *-*-linux* } } */
+ /* { dg-options "-O2 -fPIC -mno-sse -mno-mmx -mno-80387 -mtls-dialect=gnu2" } */
+ 
+ #include "pr121208-1a.c"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-2a.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-2a.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-2a.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-2a.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,17 ----
+ /* { dg-do compile { target *-*-linux* } } */
+ /* { dg-options "-O2 -fPIC -mtls-dialect=gnu" } */
+ 
+ typedef unsigned int uword_t __attribute__ ((mode (__word__)));
+ extern __thread int bar;
+ extern void func (void);
+ 
+ __attribute__((target("general-regs-only")))
+ __attribute__((interrupt))
+ void
+ foo (void *frame, uword_t error)
+ {
+   bar = 1; /* { dg-error -mtls-dialect=gnu2 } */
+   if (error == 0)
+     func ();
+   bar = 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-2b.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-2b.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-2b.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-2b.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,4 ----
+ /* { dg-do compile { target *-*-linux* } } */
+ /* { dg-options "-O2 -fPIC -mtls-dialect=gnu2" } */
+ 
+ #include "pr121208-2a.c"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-3a.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-3a.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-3a.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-3a.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,17 ----
+ /* { dg-do compile { target *-*-linux* } } */
+ /* { dg-options "-O2 -fPIC -mtls-dialect=gnu" } */
+ 
+ typedef unsigned int uword_t __attribute__ ((mode (__word__)));
+ extern __thread int bar;
+ extern void func (void);
+ 
+ __attribute__((target("general-regs-only")))
+ __attribute__((interrupt))
+ void
+ foo (void *frame)
+ {
+   bar = 1; /* { dg-error -mtls-dialect=gnu2 } */
+   if (frame == 0)
+     func ();
+   bar = 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-3b.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-3b.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr121208-3b.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr121208-3b.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,4 ----
+ /* { dg-do compile { target *-*-linux* } } */
+ /* { dg-options "-O2 -fPIC -mtls-dialect=gnu2" } */
+ 
+ #include "pr121208-3a.c"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr122104.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr122104.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr122104.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr122104.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,12 ----
+ /* PR tree-optimization/122104 */
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -fdump-tree-widening_mul-alias" } */
+ /* { dg-final { scan-tree-dump "\\.MUL_OVERFLOW" "widening_mul" } } */
+ /* { dg-final { scan-tree-dump-not "# RANGE \\\[irange\\\] unsigned int \\\[1, " "widening_mul" } } */
+ 
+ int
+ foo (int x)
+ {
+   int r = (unsigned) x * 35;
+   return x && ((unsigned) r / x) != 35U;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr123121.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr123121.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr123121.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr123121.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,57 ----
+ /* { dg-do run } */
+ /* { dg-require-effective-target lp64 } */
+ /* { dg-options "-O3 -fno-ipa-cp -fschedule-insns" } */
+ 
+ int a[256], d, e, f, g, h, j, v[] = {0, -6, 0};;
+ unsigned c;
+ unsigned k(int l, unsigned m) { return (l & 6777215) ^ a[(l ^ m) & 55]; }
+ int n(int l, int m[]) {
+   int i = 0;
+   for (; i < l; ++i) {
+     e = c >> 8 ^ a[m[i] & 255];
+     d = e;
+     d = k(d, m[i] >> 8 & 255);
+     d = k(d, m[i] >> 6);
+     f = (d & 6777215) ^ a[d & 5];
+     c = f;
+   }
+   return f;
+ }
+ int o() {
+   n(8, (int[]){g});
+   return n(6, (int[]){h});
+ }
+ int p(int l, int m[], int q, int r) {
+   int s = r = j + 1;
+   s = -(4 % q - 1);
+   if (r)
+     goto t;
+  ad:
+   l = 6 - l;
+   if (l)
+     goto ae;
+  t:
+   m[0] = s;
+   j = r;
+   goto af;
+  ae:
+   if (o())
+     goto ad;
+  af:
+   r = -s - m[1] - 8;
+   s = 1 % m[0] - s;
+   m[1] = 1 / r;
+   int a[] = {l, m[0], m[1], m[2], q, r, r, s};
+   return n(8, a);
+ }
+ int main() {
+   for (int i = 0; i < 256; i++) {
+     unsigned b = i;
+     if (i & 1)
+       b = b >> 1 ^ 3988292384;
+     a[i] = b;
+   }
+   if (p(1, v, 5, 0) / 100000)
+     p(1, 0, 5, 0);
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr124056.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr124056.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr124056.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr124056.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,61 ----
+ /* PR middle-end/124056 */
+ /* { dg-do run } */
+ /* { dg-options "-O2 -masm=att" } */
+ 
+ int v;
+ 
+ [[gnu::noipa]] void
+ foo (void)
+ {
+   v = 42;
+ }
+ 
+ [[gnu::noipa]] void
+ bar (void)
+ {
+   v = 43;
+ }
+ 
+ [[gnu::noipa]] int
+ baz (void)
+ {
+   _Bool err;
+   __asm goto ("movl %1, %%ecx\n\t"
+ 	       "test %%ecx, %%ecx\n\t"
+ 	       "js 1f\n\t"
+ 	       "jmp %l[lab]\n\t"
+ 	    "1: cmpl $-1, %%ecx"
+ 	       : "=@ccz" (err) : "m" (v) : "ecx" : lab);
+   if (err)
+     {
+       bar ();
+       return -1;
+     }
+   return 0;
+ 
+  lab:
+   if (err)
+     {
+       foo ();
+       return -2;
+     }
+ 
+   return 1;
+ }
+ 
+ int
+ main ()
+ {
+   v = 0;
+   if (baz () != -2 || v != 42)
+     __builtin_abort ();
+   v = 1;
+   if (baz () != 1 || v != 1)
+     __builtin_abort ();
+   v = -1;
+   if (baz () != -1 || v != 43)
+     __builtin_abort ();
+   v = -2;
+   if (baz () != 0 || v != -2)
+     __builtin_abort ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr126429-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr126429-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/pr126429-1.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/pr126429-1.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,15 ----
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -mavx512bf16 -mavx512dq" } */
+ /* { dg-final { scan-assembler-not "kmovb" } } */
+ 
+ #include 
+ 
+ __m512 dp16ps_mask (__m512 src, __mmask16 k, __m512bh a, __m512bh b)
+ {
+   return _mm512_mask_dpbf16_ps (src, k, a, b);
+ }
+ 
+ __m512 dp16ps_maskz (__mmask16 k, __m512 src, __m512bh a, __m512bh b)
+ {
+   return _mm512_maskz_dpbf16_ps (k, src, a, b);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/i386/ssse3-pr125611.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/ssse3-pr125611.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/i386/ssse3-pr125611.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/i386/ssse3-pr125611.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,12 ----
+ /* PR target/125611 */
+ /* { dg-do compile } */
+ /* { dg-options "-O2 -mssse3 -mno-sse4.1" } */
+ 
+ typedef __attribute__((__vector_size__(16))) short V;
+ struct __attribute__((__packed__)) { V v[4]; } *u;
+ 
+ void
+ foo (void)
+ {
+   u->v[2] &= __builtin_ia32_pmulhrsw128 (u->v[0], u->v[1]);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/loongarch/pr125049.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/loongarch/pr125049.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/loongarch/pr125049.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/loongarch/pr125049.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,50 ----
+ /* PR 125049: ensure stack canary and its address are not leaked.  */
+ /* { dg-options "-O2 -fstack-protector-strong -ffixed-r30 -ffixed-r31" } */
+ /* { dg-do run } */
+ /* { dg-require-effective-target fstack_protector } */
+ 
+ extern long __stack_chk_guard;
+ register long s7 asm ("s7"), *s8 asm ("s8");
+ 
+ [[gnu::zero_call_used_regs ("all"), gnu::noipa]] void
+ init_test (void)
+ {
+   s7 = __stack_chk_guard;
+   s8 = &__stack_chk_guard;
+ }
+ 
+ [[gnu::always_inline]] static inline void
+ check_reg (void)
+ {
+ #pragma GCC unroll 30
+   for (int i = 4; i < 30; i++)
+     asm goto (
+       "beq $r%0,$s7,%l[error]\n\t"
+       "beq $r%0,$s8,%l[error]\n\t"
+       :
+       : "i" (i)
+       :
+       : error
+     );
+   return;
+ error:
+   __builtin_trap ();
+ }
+ 
+ [[gnu::noipa]] void
+ test (void)
+ {
+   char buf[256];
+   asm ("":"+m"(buf));
+ 
+   check_reg ();
+ }
+ 
+ int
+ main (void)
+ {
+   init_test ();
+   test ();
+ 
+   check_reg ();
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/builtins-1-p9-runnable.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/builtins-1-p9-runnable.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/builtins-1-p9-runnable.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/builtins-1-p9-runnable.c	Fri Sep  4 07:35:10 2026
*************** int main() {
*** 16,28 ****
    vfb = (vector float){10.0, -2.0, 70.0, 999.0 };
  
    /* Expected results.  */
- #ifdef __BIG_ENDIAN__
-   vexpected = (vector unsigned short) { 0x4900, 0xc000, 0x5460, 0x63ce,
- 					0x3666, 0x3e66, 0x4d00, 0x563e };
- #else
    vexpected = (vector unsigned short) { 0x3666, 0x3e66, 0x4d00, 0x563e,
  					0x4900, 0xc000, 0x5460, 0x63ce };
- #endif
  
  /*
       vresult = vec_pack_to_short_fp32 (vfa, vfb);
--- 16,23 ----
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-builtin-7.c	Fri Sep  4 07:35:10 2026
***************
*** 1,7 ****
  /* { dg-do compile { target { powerpc*-*-* } } } */
  /* { dg-skip-if "" { powerpc*-*-darwin* } } */
  /* { dg-require-effective-target powerpc_vsx_ok } */
! /* { dg-options "-O2 -mdejagnu-cpu=power7 -fno-inline-functions" } */
  
  /* Test simple extract/insert/slat operations.  Make sure all types are
     supported with various options.  */
--- 1,15 ----
  /* { dg-do compile { target { powerpc*-*-* } } } */
  /* { dg-skip-if "" { powerpc*-*-darwin* } } */
  /* { dg-require-effective-target powerpc_vsx_ok } */
! /* { dg-options "-O2 -mdejagnu-cpu=power7 -fno-inline-functions -fno-ipa-icf" } */
! 
! /* PR testsuite/119382
!    Note: Added -fno-ipa-icf to disable Interprocedural Identical Code
!    Folding (ICF). Without this, insert_di_0_v2 is merged with insert_di_0
!    due to improved alias analysis introduced in commit r15-7961-gdc47161c1f32c3.
!    This results in the compiler replacing insert_di_0_v2 with a tail call to
!    insert_di_0, altering expected test behavior. Disabling ICF ensures correct
!    execution of the test.  */
  
  /* Test simple extract/insert/slat operations.  Make sure all types are
     supported with various options.  */
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-1.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-1.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-1.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-1.c	Fri Sep  4 07:35:10 2026
***************
*** 4,11 ****
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-align-1.c.  */
- #include 
- #include 
  
  /* Compile time known misalignment. Cannot use loop peeling to align
     the store.  */
--- 4,9 ----
*************** main1 (struct foo * __restrict__ p)
*** 28,50 ****
      {
        p->y[i] = x[i];
      }
- 
-   /* check results:  */
-   for (i = 0; i < N; i++)
-     {
-       if (p->y[i] != x[i])
- 	abort ();
-     }
-   return 0;
- }
- 
- 
- int main (void)
- {
-   int i;
-   struct foo *p = malloc (2*sizeof (struct foo));
-   
-   main1 (p);
    return 0;
  }
  
--- 26,31 ----
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-10.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-10.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-10.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-10.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,39 ----
+ /* { dg-do run } */
+ /* { dg-options "-O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
+ 
+ /* Taken from vect/vect-95.c.  */
+ #include 
+ #include 
+ 
+ #include "vsx-vectorize-2.c"
+ 
+ __attribute__ ((noinline))
+ void bar (float *pd, float *pa, float *pb, float *pc) 
+ {
+   int i;
+ 
+   /* check results:  */
+   for (i = 0; i < N; i++)
+     {
+       if (pa[i] != (pb[i] * pc[i]))
+ 	abort ();
+       if (pd[i] != 5.0)
+ 	abort ();
+     }
+ 
+   return;
+ }
+ 
+ int main (void)
+ {
+   int i;
+   float a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   float d[N+1] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   float b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
+   float c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
+ 
+   main1 (N,&d[1],a,b,c);
+   main1 (N-2,&d[1],a,b,c);
+ 
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-11.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-11.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-11.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-11.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,36 ----
+ /* { dg-do run } */
+ /* { dg-options "-O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
+ 
+ /* Taken from vect/vect-95.c.  */
+ #include 
+ #include 
+ 
+ #include "vsx-vectorize-3.c"
+ 
+ __attribute__ ((noinline))
+ void bar (short *pa, short *pb, short *pc) 
+ {
+   int i;
+ 
+   /* check results:  */
+   for (i = 0; i < N; i++)
+     {
+       if (pa[i] != (pb[i] * pc[i]))
+ 	abort ();
+     }
+ 
+   return;
+ }
+ 
+ int main (void)
+ {
+   int i;
+   short a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   short b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
+   short c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
+ 
+   main1 (N,a,b,c);
+   main1 (N-2,a,b,c);
+ 
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-12.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-12.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-12.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-12.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,36 ----
+ /* { dg-do run } */
+ /* { dg-options "-O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
+ 
+ /* Taken from vect/vect-95.c.  */
+ #include 
+ #include 
+ 
+ #include "vsx-vectorize-4.c"
+ 
+ __attribute__ ((noinline))
+ void bar (double *pa, double *pb, double *pc) 
+ {
+   int i;
+ 
+   /* check results:  */
+   for (i = 0; i < N; i++)
+     {
+       if (pa[i] != (pb[i] * pc[i]))
+ 	abort ();
+     }
+ 
+   return;
+ }
+ 
+ int main (void)
+ {
+   int i;
+   double a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   double b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
+   double c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
+ 
+   main1 (N,a,b,c);
+   main1 (N-2,a,b,c);
+ 
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-13.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-13.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-13.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-13.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,36 ----
+ /* { dg-do run } */
+ /* { dg-options "-O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
+ 
+ /* Taken from vect/vect-95.c.  */
+ #include 
+ #include 
+ 
+ #include "vsx-vectorize-5.c"
+ 
+ __attribute__ ((noinline))
+ void bar (char *pa, char *pb, char *pc) 
+ {
+   int i;
+ 
+   /* check results:  */
+   for (i = 0; i < N; i++)
+     {
+       if (pa[i] != (pb[i] + pc[i]))
+ 	abort ();
+     }
+ 
+   return;
+ }
+ 
+ int main (void)
+ {
+   int i;
+   char a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   char b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
+   char c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
+ 
+   main1 (N,a,b,c);
+   main1 (N-2,a,b,c);
+ 
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-14.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-14.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-14.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-14.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,39 ----
+ /* { dg-do run } */
+ /* { dg-options "-O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
+ 
+ /* Taken from vect/vect-95.c.  */
+ #include 
+ #include 
+ 
+ #include "vsx-vectorize-6.c"
+ 
+ __attribute__ ((noinline))
+ void bar (double *pd, double *pa, double *pb, double *pc) 
+ {
+   int i;
+ 
+   /* check results:  */
+   for (i = 0; i < N; i++)
+     {
+       if (pa[i] != (pb[i] * pc[i]))
+ 	abort ();
+       if (pd[i] != 5.0)
+ 	abort ();
+     }
+ 
+   return;
+ }
+ 
+ int main (void)
+ {
+   int i;
+   double a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   double d[N+1] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   double b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
+   double c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
+ 
+   main1 (N,&d[1],a,b,c);
+   main1 (N-2,&d[1],a,b,c);
+ 
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-15.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-15.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-15.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-15.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,39 ----
+ /* { dg-do run } */
+ /* { dg-options "-O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
+ 
+ /* Taken from vect/vect-95.c.  */
+ #include 
+ #include 
+ 
+ #include "vsx-vectorize-7.c"
+ 
+ __attribute__ ((noinline))
+ void bar (int *pd, int *pa, int *pb, int *pc) 
+ {
+   int i;
+ 
+   /* check results:  */
+   for (i = 0; i < N; i++)
+     {
+       if (pa[i] != (pb[i] * pc[i]))
+ 	abort ();
+       if (pd[i] != 5.0)
+ 	abort ();
+     }
+ 
+   return;
+ }
+ 
+ int main (void)
+ {
+   int i;
+   int a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   int d[N+1] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   int b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
+   int c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
+ 
+   main1 (N,&d[1],a,b,c);
+   main1 (N-2,&d[1],a,b,c);
+ 
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-16.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-16.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-16.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-16.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,39 ----
+ /* { dg-do run } */
+ /* { dg-options "-O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
+ 
+ /* Taken from vect/vect-95.c.  */
+ #include 
+ #include 
+ 
+ #include "vsx-vectorize-8.c"
+ 
+ __attribute__ ((noinline))
+ void bar (short *pd, short *pa, short *pb, short *pc) 
+ {
+   int i;
+ 
+   /* check results:  */
+   for (i = 0; i < N; i++)
+     {
+       if (pa[i] != (pb[i] * pc[i]))
+ 	abort ();
+       if (pd[i] != 5.0)
+ 	abort ();
+     }
+ 
+   return;
+ }
+ 
+ int main (void)
+ {
+   int i;
+   short a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   short d[N+1] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
+   short b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
+   short c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
+ 
+   main1 (N,&d[1],a,b,c);
+   main1 (N-2,&d[1],a,b,c);
+ 
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-2.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-2.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-2.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-2.c	Fri Sep  4 07:35:10 2026
***************
*** 4,31 ****
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
- #include 
- #include 
  
  #define N 256
  
! __attribute__ ((noinline))
! void bar (float *pd, float *pa, float *pb, float *pc) 
! {
!   int i;
! 
!   /* check results:  */
!   for (i = 0; i < N; i++)
!     {
!       if (pa[i] != (pb[i] * pc[i]))
! 	abort ();
!       if (pd[i] != 5.0)
! 	abort ();
!     }
! 
!   return;
! }
! 
  
  __attribute__ ((noinline)) int
  main1 (int n, float * __restrict__ pd, float * __restrict__ pa, float * __restrict__ pb, float * __restrict__ pc)
--- 4,13 ----
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
  
  #define N 256
  
! void bar (float *pd, float *pa, float *pb, float *pc);
  
  __attribute__ ((noinline)) int
  main1 (int n, float * __restrict__ pd, float * __restrict__ pa, float * __restrict__ pb, float * __restrict__ pc)
*************** main1 (int n, float * __restrict__ pd, f
*** 42,61 ****
  
    return 0;
  }
- 
- int main (void)
- {
-   int i;
-   float a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   float d[N+1] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   float b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
-   float c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
- 
-   main1 (N,&d[1],a,b,c);
-   main1 (N-2,&d[1],a,b,c);
- 
-   return 0;
- }
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
  /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 0 "vect" {xfail { {! vect_hw_misalign } || powerpc*-*-* } } } } */
--- 24,29 ----
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-3.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-3.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-3.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-3.c	Fri Sep  4 07:35:10 2026
***************
*** 4,29 ****
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
- #include 
- #include 
  
  #define N 256
  
! __attribute__ ((noinline))
! void bar (short *pa, short *pb, short *pc) 
! {
!   int i;
! 
!   /* check results:  */
!   for (i = 0; i < N; i++)
!     {
!       if (pa[i] != (pb[i] * pc[i]))
! 	abort ();
!     }
! 
!   return;
! }
! 
  
  __attribute__ ((noinline)) int
  main1 (int n, short * __restrict__ pa, short * __restrict__ pb, short * __restrict__ pc)
--- 4,13 ----
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
  
  #define N 256
  
! void bar (short *pa, short *pb, short *pc);
  
  __attribute__ ((noinline)) int
  main1 (int n, short * __restrict__ pa, short * __restrict__ pb, short * __restrict__ pc)
*************** main1 (int n, short * __restrict__ pa, s
*** 39,57 ****
  
    return 0;
  }
- 
- int main (void)
- {
-   int i;
-   short a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   short b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
-   short c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
- 
-   main1 (N,a,b,c);
-   main1 (N-2,a,b,c);
- 
-   return 0;
- }
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
  /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" } } */
--- 23,28 ----
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-4.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-4.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-4.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-4.c	Fri Sep  4 07:35:10 2026
***************
*** 4,29 ****
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
- #include 
- #include 
  
  #define N 256
  
! __attribute__ ((noinline))
! void bar (double *pa, double *pb, double *pc) 
! {
!   int i;
! 
!   /* check results:  */
!   for (i = 0; i < N; i++)
!     {
!       if (pa[i] != (pb[i] * pc[i]))
! 	abort ();
!     }
! 
!   return;
! }
! 
  
  __attribute__ ((noinline)) int
  main1 (int n, double * __restrict__ pa, double * __restrict__ pb, double * __restrict__ pc)
--- 4,13 ----
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
  
  #define N 256
  
! void bar (double *pa, double *pb, double *pc);
  
  __attribute__ ((noinline)) int
  main1 (int n, double * __restrict__ pa, double * __restrict__ pb, double * __restrict__ pc)
*************** main1 (int n, double * __restrict__ pa,
*** 39,57 ****
  
    return 0;
  }
- 
- int main (void)
- {
-   int i;
-   double a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   double b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
-   double c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
- 
-   main1 (N,a,b,c);
-   main1 (N-2,a,b,c);
- 
-   return 0;
- }
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
  /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 0 "vect" { xfail { {! vect_hw_misalign } || powerpc*-*-* } } } } */
--- 23,28 ----
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-5.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-5.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-5.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-5.c	Fri Sep  4 07:35:10 2026
***************
*** 4,29 ****
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
- #include 
- #include 
  
  #define N 256
  
! __attribute__ ((noinline))
! void bar (char *pa, char *pb, char *pc) 
! {
!   int i;
! 
!   /* check results:  */
!   for (i = 0; i < N; i++)
!     {
!       if (pa[i] != (pb[i] + pc[i]))
! 	abort ();
!     }
! 
!   return;
! }
! 
  
  __attribute__ ((noinline)) int
  main1 (int n, char * __restrict__ pa, char * __restrict__ pb, char * __restrict__ pc)
--- 4,13 ----
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
  
  #define N 256
  
! void bar (char *pa, char *pb, char *pc);
  
  __attribute__ ((noinline)) int
  main1 (int n, char * __restrict__ pa, char * __restrict__ pb, char * __restrict__ pc)
*************** main1 (int n, char * __restrict__ pa, ch
*** 39,57 ****
  
    return 0;
  }
- 
- int main (void)
- {
-   int i;
-   char a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   char b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
-   char c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
- 
-   main1 (N,a,b,c);
-   main1 (N-2,a,b,c);
- 
-   return 0;
- }
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
  /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 1 "vect" } } */
--- 23,28 ----
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-6.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-6.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-6.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-6.c	Fri Sep  4 07:35:10 2026
***************
*** 4,31 ****
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
- #include 
- #include 
  
  #define N 256
  
! __attribute__ ((noinline))
! void bar (double *pd, double *pa, double *pb, double *pc) 
! {
!   int i;
! 
!   /* check results:  */
!   for (i = 0; i < N; i++)
!     {
!       if (pa[i] != (pb[i] * pc[i]))
! 	abort ();
!       if (pd[i] != 5.0)
! 	abort ();
!     }
! 
!   return;
! }
! 
  
  __attribute__ ((noinline)) int
  main1 (int n, double * __restrict__ pd, double * __restrict__ pa, double * __restrict__ pb, double * __restrict__ pc)
--- 4,13 ----
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
  
  #define N 256
  
! void bar (double *pd, double *pa, double *pb, double *pc);
  
  __attribute__ ((noinline)) int
  main1 (int n, double * __restrict__ pd, double * __restrict__ pa, double * __restrict__ pb, double * __restrict__ pc)
*************** main1 (int n, double * __restrict__ pd,
*** 42,61 ****
  
    return 0;
  }
- 
- int main (void)
- {
-   int i;
-   double a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   double d[N+1] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   double b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
-   double c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
- 
-   main1 (N,&d[1],a,b,c);
-   main1 (N-2,&d[1],a,b,c);
- 
-   return 0;
- }
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
  /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 0 "vect" { xfail { {! vect_hw_misalign } || powerpc*-*-* } } } } */
--- 24,29 ----
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-7.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-7.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-7.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-7.c	Fri Sep  4 07:35:10 2026
***************
*** 4,31 ****
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
- #include 
- #include 
  
  #define N 256
  
! __attribute__ ((noinline))
! void bar (int *pd, int *pa, int *pb, int *pc) 
! {
!   int i;
! 
!   /* check results:  */
!   for (i = 0; i < N; i++)
!     {
!       if (pa[i] != (pb[i] * pc[i]))
! 	abort ();
!       if (pd[i] != 5.0)
! 	abort ();
!     }
! 
!   return;
! }
! 
  
  __attribute__ ((noinline)) int
  main1 (int n, int * __restrict__ pd, int * __restrict__ pa, int * __restrict__ pb, int * __restrict__ pc)
--- 4,13 ----
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
  
  #define N 256
  
! void bar (int *pd, int *pa, int *pb, int *pc);
  
  __attribute__ ((noinline)) int
  main1 (int n, int * __restrict__ pd, int * __restrict__ pa, int * __restrict__ pb, int * __restrict__ pc)
*************** main1 (int n, int * __restrict__ pd, int
*** 42,61 ****
  
    return 0;
  }
- 
- int main (void)
- {
-   int i;
-   int a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   int d[N+1] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   int b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
-   int c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
- 
-   main1 (N,&d[1],a,b,c);
-   main1 (N-2,&d[1],a,b,c);
- 
-   return 0;
- }
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
  /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 0 "vect" {xfail { {! vect_hw_misalign } || powerpc*-*-* } } } } */
--- 24,29 ----
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-8.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-8.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-8.c	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-8.c	Fri Sep  4 07:35:10 2026
***************
*** 4,31 ****
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
- #include 
- #include 
  
  #define N 256
  
! __attribute__ ((noinline))
! void bar (short *pd, short *pa, short *pb, short *pc) 
! {
!   int i;
! 
!   /* check results:  */
!   for (i = 0; i < N; i++)
!     {
!       if (pa[i] != (pb[i] * pc[i]))
! 	abort ();
!       if (pd[i] != 5.0)
! 	abort ();
!     }
! 
!   return;
! }
! 
  
  __attribute__ ((noinline)) int
  main1 (int n, short * __restrict__ pd, short * __restrict__ pa, short * __restrict__ pb, short * __restrict__ pc)
--- 4,13 ----
  /* { dg-options "-mdejagnu-cpu=power7 -O2 -ftree-vectorize -fno-vect-cost-model -fdump-tree-vect-details" } */
  
  /* Taken from vect/vect-95.c.  */
  
  #define N 256
  
! void bar (short *pd, short *pa, short *pb, short *pc);
  
  __attribute__ ((noinline)) int
  main1 (int n, short * __restrict__ pd, short * __restrict__ pa, short * __restrict__ pb, short * __restrict__ pc)
*************** main1 (int n, short * __restrict__ pd, s
*** 42,61 ****
  
    return 0;
  }
- 
- int main (void)
- {
-   int i;
-   short a[N] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   short d[N+1] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
-   short b[N] = {0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57};
-   short c[N] = {0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19};
- 
-   main1 (N,&d[1],a,b,c);
-   main1 (N-2,&d[1],a,b,c);
- 
-   return 0;
- }
  
  /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
  /* { dg-final { scan-tree-dump-times "Alignment of access forced using peeling" 0 "vect" } } */
--- 24,29 ----
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-9.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-9.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-9.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/powerpc/vsx-vectorize-9.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,24 ----
+ /* { dg-do run } */
+ /* { dg-options "-O2 -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fdump-tree-vect-details" } */
+ 
+ /* Taken from vect/vect-align-1.c.  */
+ #include 
+ #include 
+ 
+ #include "vsx-vectorize-1.c"
+ 
+ int main (void)
+ {
+   int i;
+   struct foo *p = malloc (2*sizeof (struct foo));
+   
+   main1 (p);
+ 
+   /* check results:  */
+   for (i = 0; i < N; i++)
+     {
+       if (p->y[i] != x[i])
+ 	abort ();
+     }
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/s390/pr125972.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/s390/pr125972.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/s390/pr125972.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/s390/pr125972.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,20 ----
+ /* { dg-do compile { target int128 } } */
+ /* { dg-options "-march=z16 -O3" } */
+ 
+ int a, b, c;
+ long d, e;
+ int *f;
+ __int128 g;
+ void h() {
+   g = 0;
+   for (; g <= 33; ++g) {
+     int *i = &c;
+     *i = d - a;
+     if (*i) {
+       c = 0;
+       for (; c <= 8; ++c)
+         f = &b;
+     } else
+       ++e;
+   }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gcc.target/sh/pr122948.c gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/sh/pr122948.c
*** gcc-13.4.0/gcc/testsuite/gcc.target/sh/pr122948.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gcc.target/sh/pr122948.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,67 ----
+ /* Verify that the T bit (carry/borrow) set expression of the subc insn is
+    correct.  */
+ /* { dg-do run } */
+ /* { dg-options "-O1" } */
+ 
+ extern void abort (void);
+ 
+ __attribute__ ((noipa)) unsigned int
+ foo (unsigned int a, unsigned int b)
+ {
+   if (b - a - 1 <= b)
+     a = 0;
+   return a;
+ }
+ 
+ __attribute__ ((noipa)) unsigned int
+ bar (unsigned int a, unsigned int b)
+ {
+   return (b - a - 1) > b;
+ }
+ 
+ __attribute__ ((noipa)) unsigned int
+ baz (unsigned int a, unsigned int b)
+ {
+   return (a + b + 1) <= a;
+ }
+ 
+ int
+ main (void)
+ {
+   if (foo (0xffffffff, 0x4e92c833) != 0)
+     abort ();
+ 
+   if (bar (0xffffffff, 0x4e92c833) != 0)
+     abort ();
+ 
+   /* b - a - 1 wraps (borrow) whenever a + 1 > b (unsigned).  */
+   if (bar (5, 3) != 1)
+     abort ();
+ 
+   if (bar (0, 0) != 1)
+     abort ();
+ 
+   if (bar (0, 5) != 0)
+     abort ();
+ 
+   /* addc carry-out: (a + b + 1) <= a.  */
+   /* 0xffffffff + 0 + 1 wraps to 0.  */
+   if (baz (0xffffffff, 0) != 1)
+     abort ();
+ 
+   if (baz (0xffffffff, 0xffffffff) != 1)
+     abort ();
+ 
+   /* wraps to 0.  */
+   if (baz (0xfffffffe, 1) != 1)
+     abort ();
+ 
+   /* 1 <= 0 is false.  */
+   if (baz (0, 0) != 0)
+     abort ();
+ 
+   if (baz (1, 2) != 0)
+     abort ();
+ 
+   return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/driver_debuglib.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/driver_debuglib.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/driver_debuglib.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/driver_debuglib.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,2 ----
+ // { dg-do compile }
+ // { dg-additional-options "-debuglib=a -debuglib=b" }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/driver_defaultlib.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/driver_defaultlib.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/driver_defaultlib.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/driver_defaultlib.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,2 ----
+ // { dg-do compile }
+ // { dg-additional-options "-defaultlib=a -defaultlib=b" }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/pr121477.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr121477.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/pr121477.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr121477.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,12 ----
+ // { dg-do compile }
+ // { dg-additional-options "-fpreview=bitfields" }
+ struct S121477
+ {
+     int x : 4;
+ }
+ 
+ void f121477(S121477 s)
+ {
+     asm {"%0" :: "m" (s.x); } // { dg-error "cannot take address of bit-field" }
+     asm {"%0" : "=m" (s.x); } // { dg-error "cannot take address of bit-field" }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/pr123046.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123046.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/pr123046.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123046.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,10 ----
+ // { dg-do compile }
+ ulong pure_hashOf(const ref typeof(*null) key)
+ {
+     return hashOf(key);
+ }
+ 
+ ulong hashOf(const typeof(*null) val)
+ {
+     return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/pr123264.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123264.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/pr123264.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123264.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,8 ----
+ // { dg-do compile }
+ // { dg-options "-fdump-tree-original" }
+ struct S123264
+ {
+     void infinite(const S123264) { }
+     auto fn = &infinite;
+ }
+ // { dg-final { scan-tree-dump "const struct S123264" "original" } }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/pr123407a.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123407a.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/pr123407a.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123407a.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,4 ----
+ // { dg-do compile }
+ module pr123407;
+ pragma(mangle, "ice") int fun();
+ pragma(mangle, "ice") int var; // { dg-error "matches conflicting symbols" }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/pr123407b.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123407b.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/pr123407b.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123407b.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,4 ----
+ // { dg-do compile }
+ module pr123407;
+ int fun();
+ extern(C) int _D8pr1234073funFZi; // { dg-error "matches conflicting symbols" }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/pr123419.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123419.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/pr123419.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123419.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,9 ----
+ // { dg-do compile }
+ struct S123419 {}
+ 
+ void t123419(T)(T _) {}
+ 
+ void f123419()
+ {
+     t123419(__traits(initSymbol, S123419));
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/pr123798.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123798.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/pr123798.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr123798.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,14 ----
+ // { dg-do compile }
+ // { dg-additional-options "-fpreview=bitfields" }
+ class C123798
+ {
+     int a : 4;
+     long b : 8;
+ }
+ 
+ struct S123798
+ {
+     int a = 1;
+     int b : 4;
+     long c : 8;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/pr124026.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr124026.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/pr124026.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr124026.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,21 ----
+ // { dg-do compile }
+ struct UDA
+ {
+     int delegate() foo;
+ }
+ 
+ static UDA getUDA(alias S)()
+ {
+     return __traits(getAttributes, S)[0];
+ }
+ 
+ struct S124026
+ {
+     @UDA({ return 42; }) int a;
+ }
+ 
+ void f124026()
+ {
+     S124026 m;
+     enum uda = getUDA!(m.a);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/pr125089.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr125089.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/pr125089.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/pr125089.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,20 ----
+ // { dg-do compile }
+ struct R125089
+ {
+     S125089.T st;
+ }
+ 
+ struct S125089
+ {
+     struct T
+     {
+         void* v;
+         ~this() {}
+     }
+ 
+     T t;
+     this(R125089 r)
+     {
+         this.t = r.st;
+     }
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/torture/imports/pr119799c.c gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/torture/imports/pr119799c.c
*** gcc-13.4.0/gcc/testsuite/gdc.dg/torture/imports/pr119799c.c	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/torture/imports/pr119799c.c	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,4 ----
+ inline void fn119799()
+ {
+     static struct {} s119799;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/torture/pr119799.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/torture/pr119799.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/torture/pr119799.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/torture/pr119799.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,9 ----
+ // { dg-do compile }
+ // { dg-additional-files "imports/pr119799c.c" }
+ // { dg-additional-options "-I[srcdir]" }
+ import imports.pr119799c;
+ 
+ void test()
+ {
+     fn119799;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/torture/pr120096.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/torture/pr120096.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/torture/pr120096.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/torture/pr120096.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,18 ----
+ // { dg-do run }
+ // { dg-additional-options "-fpreview=dip1000" }
+ // { dg-skip-if "needs gcc/config.d" { ! d_runtime } }
+ struct S
+ {
+     this(int p) nothrow @nogc @safe
+     { f = p; }
+     int f;
+ }
+ 
+ int main() nothrow @nogc @safe
+ {
+     scope S[] sa = [S(1), S(2)];
+ 
+     assert(sa[0].f == 1);
+     assert(sa[1].f == 2);
+     return 0;
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gdc.dg/torture/pr123422.d gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/torture/pr123422.d
*** gcc-13.4.0/gcc/testsuite/gdc.dg/torture/pr123422.d	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gdc.dg/torture/pr123422.d	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,25 ----
+ // { dg-do run }
+ // { dg-skip-if "needs gcc/config.d" { ! d_runtime } }
+ struct S123422
+ {
+     S123422* ptr;
+     this(int) { ptr = &this; }
+     this(ref inout S123422) { ptr = &this; }
+ }
+ 
+ struct V123422
+ {
+     S123422 s;
+     this(int) { s = S123422(1); }
+ }
+ 
+ S123422 foo()
+ {
+     return V123422(1).s;
+ }
+ 
+ void main()
+ {
+     S123422 s = foo();
+     assert(&s == s.ptr);
+ }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/contiguous_17.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/contiguous_17.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/contiguous_17.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/contiguous_17.f90	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,229 ----
+ ! { dg-do run }
+ !
+ ! PR fortran/125998
+ ! Check the correct passing of a transposed array to an assumed-shape dummy
+ ! having the contiguous and target attributes.
+ !
+ ! Original testcase from Federico Perini 
+ 
+ subroutine original
+     real(8) :: a(3,4)
+     integer :: dims(2)           
+     character(48) :: iomsg  
+     call show(transpose(a),dims)
+     if (any(dims/=shape(transpose(a)))) then 
+         write(iomsg,1) 'invalid a^T dims',dims, &
+                        ' should be',shape(transpose(a))
+         error stop iomsg
+     endif
+     1 format(*(a,' [',i0,',',i0,']'))
+ 
+ contains
+ 
+     subroutine show(x,dims)
+         ! "3 4" with `contiguous` (BUG); "4 3" without
+         real(8), intent(in), target, contiguous :: x(:,:)
+         integer, intent(out) :: dims(2)    
+         dims = [size(x,1),size(x,2)]
+     end 
+ 
+ end
+ 
+ module m
+     implicit none
+     private
+     public :: check_all
+ 
+ contains
+ 
+     subroutine abort_different(lx,x,ly,y,code)
+         character(*), intent(in) :: lx, ly
+         integer, intent(in) :: x(..), y(..), code
+         write(6,'(a," /= ",a)') lx, ly
+         select rank(x)
+             rank(1)
+                 write(6,3) lx
+                 write(6,*) x
+             rank(2)
+                 write(6,3) lx
+                 write(6,*) x
+             rank default
+         end select
+         select rank(y)
+             rank(1)
+                 write(6,3) ly
+                 write(6,*) y
+             rank(2)
+                 write(6,3) ly
+                 write(6,*) y
+             rank default
+         end select
+         error stop code
+       3 format(a,":")
+     end subroutine
+ 
+     subroutine check_target(x,expected,num_error)
+         integer, intent(in), target, contiguous :: x(:,:)
+         integer, intent(in) :: num_error, expected(:,:)
+         if (any(shape(x) /= shape(expected))) then
+             call abort_different( &
+                     "shape(x)",shape(x), &
+                     "shape(expected)",shape(expected), &
+                     num_error*10+1 &
+             )
+         end if
+         if (any(x /= expected)) then
+             call abort_different("x",x,"expected",expected,num_error*10+2)
+         end if
+         if (x(2,2) /= expected(2,2)) then
+             call abort_different( &
+                 "x(2,2)",x(2,2), &
+                 "expected(2,2)",expected(2,2), &
+                 num_error*10+3 &
+             )
+         end if
+     end 
+ 
+     subroutine check_non_target(x,expected,num_error)
+         integer, intent(in), contiguous :: x(:,:)
+         integer, intent(in) :: num_error, expected(:,:)
+         if (any(shape(x) /= shape(expected))) then
+             call abort_different( &
+                     "shape(x)",shape(x), &
+                     "shape(expected)",shape(expected), &
+                     num_error*10+1 &
+             )
+         end if
+         if (any(x /= expected)) then
+             call abort_different("x",x,"expected",expected,num_error*10+2)
+         end if
+         if (x(2,2) /= expected(2,2)) then
+             call abort_different( &
+                 "x(2,2)",x(2,2), &
+                 "expected(2,2)",expected(2,2), &
+                 num_error*10+3 &
+             )
+         end if
+     end 
+ 
+     subroutine wrapper_target(x,expected,num_error)
+         integer, intent(in), target :: x(:,:)
+         integer, intent(in) :: expected(:,:)
+         integer, intent(in) :: num_error
+         call check_target(x,expected,num_error)
+     end subroutine
+ 
+     subroutine wrapper_non_target(x,expected,num_error)
+         integer, intent(in) :: x(:,:), expected(:,:)
+         integer, intent(in) :: num_error
+         call check_non_target(x,expected,num_error)
+     end subroutine
+ 
+     subroutine wrapper_transpose_target(x,expected,num_error)
+         integer, intent(in), target :: x(:,:)
+         integer, intent(in) :: expected(:,:)
+         integer, intent(in) :: num_error
+         call check_target(transpose(x),expected,num_error)
+     end subroutine
+ 
+     subroutine wrapper_transpose_non_target(x,expected,num_error)
+         integer, intent(in) :: x(:,:), expected(:,:)
+         integer, intent(in) :: num_error
+         call check_non_target(transpose(x),expected,num_error)
+     end subroutine
+ 
+     subroutine check_all
+         integer :: a(3,4)
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call check_target( &
+                 transpose(a), &
+                 reshape([0,2,8,34,1,3,13,55,1,5,21,89],[4,3]), &
+                 1 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call check_non_target( &
+                 transpose(a), &
+                 reshape([0,2,8,34,1,3,13,55,1,5,21,89],[4,3]), &
+                 2 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call wrapper_target( &
+                 transpose(a), &
+                 reshape([0,2,8,34,1,3,13,55,1,5,21,89],[4,3]), &
+                 3 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call wrapper_non_target( &
+                 transpose(a), &
+                 reshape([0,2,8,34,1,3,13,55,1,5,21,89],[4,3]), &
+                 4 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call wrapper_transpose_target( &
+                 a, &
+                 reshape([0,2,8,34,1,3,13,55,1,5,21,89],[4,3]), &
+                 5 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call wrapper_transpose_non_target( &
+                 a, &
+                 reshape([0,2,8,34,1,3,13,55,1,5,21,89],[4,3]), &
+                 6 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call wrapper_transpose_target( &
+                 transpose(a), &
+                 reshape([0,1,1,2,3,5,8,13,21,34,55,89],[3,4]), &
+                 7 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call wrapper_transpose_non_target( &
+                 transpose(a), &
+                 reshape([0,1,1,2,3,5,8,13,21,34,55,89],[3,4]), &
+                 8 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call check_target( &
+                 a(::2,::2), &
+                 reshape([0,1,8,21],[2,2]), &
+                 9 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call check_non_target( &
+                 a(::2,::2), &
+                 reshape([0,1,8,21],[2,2]), &
+                 10 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call wrapper_target( &
+                 a(::2,::2), &
+                 reshape([0,1,8,21],[2,2]), &
+                 11 &
+         )
+ 
+         a = reshape([0,1,1,2,3,5,8,13,21,34,55,89],shape(a))
+         call wrapper_non_target( &
+                 a(::2,::2), &
+                 reshape([0,1,8,21],[2,2]), &
+                 12 &
+         )
+ 
+     end subroutine
+ 
+ end module
+ 
+ use m
+ call original
+ call check_all
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/goacc/omp-108382.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/goacc/omp-108382.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/goacc/omp-108382.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/goacc/omp-108382.f90	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,22 ----
+ ! { dg-do compile }
+ ! { dg-additional-options "-fopenmp" }
+ 
+ module m_108382_a
+   implicit none
+   integer :: x, y
+ 
+ !$acc declare copyin(x, &
+ !$acc   y)
+ !$omp declare target(x, &
+ !$omp   y)
+ end module m_108382_a
+ 
+ module m_108382_b
+   implicit none
+   integer :: x, y
+ 
+ !$omp declare target(x, &
+ !$omp   y)
+ !$acc declare copyin(x, &
+ !$acc   y)
+ end module m_108382_b
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/gomp/pr107425.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/gomp/pr107425.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/gomp/pr107425.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/gomp/pr107425.f90	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,11 ----
+ ! { dg-do compile }
+ ! { dg-options "-fopenmp" }
+ !
+ ! PR fortran/107425
+ ! ICE in gimplify_var_or_parm_decl when an implicitly typed variable
+ ! is used as a subscript in an iterator depend clause.
+ 
+ program p
+    integer :: x(8)
+    !$omp taskwait depend(iterator(i=1:8), in:x(j))
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/gomp/pr98203.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/gomp/pr98203.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/gomp/pr98203.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/gomp/pr98203.f90	Fri Sep  4 07:35:10 2026
***************
*** 0 ****
--- 1,14 ----
+ ! { dg-do compile }
+ ! PR fortran/98203
+ ! Contributed by G. Steinmetz 
+ !
+ ! ICE in gfc_trans_omp_do with collapse(2) and non-unit stride.
+ 
+ subroutine s
+   integer :: i, j
+   !$omp parallel do collapse(2)
+   do i = 1, 10, 2
+     do j = 1, 10
+     end do
+   end do
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/inline_matmul_27.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/inline_matmul_27.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/inline_matmul_27.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/inline_matmul_27.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,63 ----
+ ! { dg-do run }
+ ! { dg-options "-O2 -fcheck=bounds -fno-automatic" }
+ ! PR fortran/106546 - FE temporaries have to be automatic
+ ! Original test case by Solomon Gibbs
+ 
+ subroutine do_multiply()
+   implicit none
+   
+   integer :: rank
+   real(8) :: draw
+ 
+   real(8) :: x1(6), x2(6)
+   real(8), allocatable :: K(:,:), J(:,:), z(:)
+ 
+   character(len=300) :: out
+   ! Randomly select rank of operation 0 ... 6
+   call random_number(draw)
+   if (draw .lt. 1/7.0d0) then
+      rank = 0
+   elseif (draw .lt. 2/7.0d0) then
+      rank = 1
+   elseif (draw .lt. 3/7.0d0) then
+      rank = 2
+   elseif (draw .lt. 4/7.0d0) then
+      rank = 3
+   elseif (draw .lt. 5/7.0d0) then
+      rank = 4
+   elseif (draw .lt. 6/7.0d0) then
+      rank = 5
+   else
+      rank = 6
+   endif
+ 
+   allocate(K(rank, 6))
+   allocate(J(rank, rank))
+   allocate(z(rank))
+ 
+   call random_number(x1)
+   call random_number(x2)
+   call random_number(K)
+   call random_number(J)
+   call random_number(z)
+ 
+   ! multiply allocatables using array temporaries
+   ! Problem occurs here
+   z = matmul(J, matmul(K, x2 - x1))
+ 
+   ! Output z to prevent optimizer elimination
+   write (out,*) rank," ",z
+ 
+   deallocate(z, J, K)
+   
+ end subroutine do_multiply
+   
+ program bogus
+   implicit none
+ 
+   integer :: i
+   do i=1,100
+      call do_multiply()
+   end do
+   
+ end program bogus
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr102459.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr102459.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr102459.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr102459.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,15 ----
+ ! { dg-do compile }
+ ! { dg-additional-options "-fopenmp" }
+ 
+ program p
+   type t
+     integer :: a(2)
+   end type
+   type(t) :: x(8)
+ 
+   !$omp task depend (iterator(j=1:8), out:x(j)%a)
+   !$omp end task
+ 
+   !$omp task depend (iterator(j=1:8), out:x(j)%a(1))
+   !$omp end task
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr102596.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr102596.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr102596.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr102596.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,13 ----
+ ! { dg-do compile }
+ ! { dg-additional-options "-fopenmp" }
+ 
+ program p
+   integer, allocatable :: r
+ 
+   allocate (r)
+   r = 0
+ 
+   !$omp target parallel reduction(task, +:r)
+   r = r + 1
+   !$omp end target parallel
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr102619.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr102619.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr102619.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr102619.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,23 ----
+ ! { dg-do run }
+ !
+ ! Test the fix for PR102619.
+ !
+ ! Contributed by Gerhard Steinmetz  
+ !
+ program p
+   implicit none
+   real :: w(2,3)
+   real, allocatable :: y(:)
+   y = h(w)                        ! Caused an ICE
+   if (size (y) /= product (shape (w))) stop 1
+   if (any (int (y) /= [1,2,3,4,5,6])) stop 2
+   deallocate (y)
+ contains
+   function h(x) result (g)
+     real :: x(..)
+     real :: g(product(shape(x)))
+     integer :: i
+     if (any (shape (x) /= shape (w))) stop 3
+     g = [(real(i),i=1,size(g))]
+   end
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr103367.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr103367.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr103367.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr103367.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,15 ----
+ ! { dg-do compile }
+ !
+ ! PR fortran/103367
+ ! Invalid initialization expressions must not ICE if they survive
+ ! semantic checking and reach array initializer lowering.
+ 
+ program p
+   type t
+     integer :: a(1,2) = 3
+   end type
+   type(t), parameter :: x(1) = t(4)
+   integer :: y(1,2) = (x(b)%a) ! { dg-error "does not reduce to a constant expression" }
+   print *, y
+ end
+ ! { dg-prune-output "Legacy Extension: REAL array index" }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr103367_2.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr103367_2.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr103367_2.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr103367_2.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,37 ----
+ ! { dg-do compile }
+ subroutine s1
+   type t
+     integer :: a(1,2) = 3
+   end type
+   type(t), parameter :: x(1) = t(4)
+   integer, parameter :: y(1,2) = (x(1)%a(m,1)) ! { dg-error "does not reduce to a constant expression" }
+   print *, y
+ end
+ 
+ subroutine s2
+   type t
+     integer :: a(2) = 3!
+   end type
+   type(t), parameter :: x(1) = t(4)
+   integer, parameter :: y = x(1)%a(m) ! { dg-error "non-constant initialization expression" }
+   print *, y
+ end
+ 
+ subroutine s3
+   type t
+     integer :: a(1,2) = 3
+   end type
+   type(t), parameter :: x(1) = t(4)
+   integer, parameter :: y(1,2) = (x(b)%a) ! { dg-error "does not reduce to a constant expression" }
+   print *, y
+ end
+ 
+ subroutine s4
+   type t
+     integer :: a(1,2) = 3
+   end type
+   type(t), parameter :: x(1) = t(4)
+   integer :: y(1,2) = x(b)%a ! { dg-error "does not reduce to a constant expression" }
+   print *, y
+ end
+ ! { dg-prune-output "Legacy Extension: REAL array index" }
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr103367_3.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr103367_3.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr103367_3.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr103367_3.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,11 ----
+ ! { dg-do run }
+ ! PR103367 Test case from the PR, previously segfaulted.
+ program p
+   type t
+      integer :: a(1,2) = 3
+   end type
+   type(t), parameter :: x(1) = t(4)
+   integer, parameter :: y(2) = x(1)%a(1,:)
+   if (any (y /= [4, 4])) stop 1
+ end
+ 
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr103367_4.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr103367_4.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr103367_4.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr103367_4.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,14 ----
+ ! { dg-do run }
+ ! PR103367, this test previously
+ ! Test case from the PR segfaulted at compile time.
+ program p
+   type inner
+     integer :: n = 3
+   end type
+   type outer
+     type(inner) :: a(2) = inner(1)
+   end type
+   type(outer), parameter :: x(1) = outer(inner(4))
+   integer, parameter :: y(2) = x(1)%a%n
+   if (any (y /= [4, 4])) stop 1
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr115260.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr115260.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr115260.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr115260.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,35 ----
+ ! { dg-do run }
+ ! PR 115260 - this got corrupted output.
+ ! Original test case by Steve Mullerworth
+ 
+ program usegnufields
+   implicit none
+   type :: field_type
+     real,    allocatable :: data(:)
+     integer, allocatable :: idata(:)
+   end type field_type
+   type :: fieldholder
+     type(field_type) :: fieldset(2,4)
+   end type fieldholder
+   type(fieldholder) :: myfields
+ 
+   allocate(myfields%fieldset(2,1)%data(3))
+   allocate(myfields%fieldset(2,1)%idata(3))
+   myfields%fieldset(2,1)%data =1.0
+   myfields%fieldset(2,1)%idata=2
+ 
+   call setfields (myfields%fieldset(2,1:4))
+ !  print *,'After calling setfields with fieldset(2,1:4)'
+ !  print *,myfields%fieldset(2,1)%data
+ !  print *,myfields%fieldset(2,1)%idata
+   if (any (myfields%fieldset(2,1)%data  /= 1.0)) stop 1
+   if (any (myfields%fieldset(2,1)%idata /= 2  )) stop 2
+ 
+ contains
+   subroutine setfields (fieldset)
+     type(field_type), intent(inout) :: fieldset(1:4) ! corruption with -O
+ !    print *,'In setfields:'
+ !    print *,fieldset(1)%data
+ !    print *,fieldset(1)%idata
+   end subroutine setfields
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr124450.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr124450.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr124450.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr124450.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,14 ----
+ ! PR fortran/124450
+ ! { dg-do compile }
+ 
+   type ta
+     integer(kind=4) :: a(1)
+     integer(kind=4) :: b(1)
+   end type ta
+   type tb
+     type(ta) :: c(1) = ta(1, 2)
+   end type tb
+   type(tb) :: e = tb(ta(3, 4))
+ 
+   print *, e
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr125866.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr125866.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr125866.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr125866.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,28 ----
+ ! { dg-do compile }
+ !  ICE: a module procedure with an allocatable, intent(out)
+ !  derived-type array dummy. Reduced from the original in the PR
+ 
+ module m
+   interface
+     module subroutine s (a)
+       integer, allocatable, intent(out) :: a
+     end subroutine
+   end interface
+ end module
+ 
+ submodule (m) sm1
+ contains
+   module subroutine s (a)
+     integer, allocatable, intent(out) :: a
+     allocate (a, source = 7)
+   end subroutine
+ end submodule
+ 
+ submodule (m:sm1) sm2
+ contains
+   subroutine caller
+     integer, allocatable :: b
+     call s (b)
+     if (b /= 7) stop 1
+   end subroutine
+ end submodule
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr126303.f gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr126303.f
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr126303.f	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr126303.f	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,9 ----
+ ! PR fortran/126303
+ ! { dg-do compile }
+ ! { dg-options "-std=legacy" }
+       COMMON FOO(8)
+       DO 10 M=1,8
+         DO 10 T=0D0,1D0
+           FOO(M)=1
+    10 CONTINUE
+       END
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr79524.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr79524.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr79524.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr79524.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,9 ----
+ ! { dg-do compile }
+ ! { dg-set-target-env-var MALLOC_PERTURB_ "165" }
+ ! PR fortran/79524
+ ! Reject parameter arrays with variable-length CHARACTER elements without
+ ! leaving the temporary charlen from the failed declaration on cl_list.
+ program p
+   character(*), parameter :: z(2) = [character(n) :: 'x', 'y'] ! { dg-error "Cannot initialize parameter array" }
+   character(*), parameter :: w(2) = [character(n+1) :: 'a', 'b'] ! { dg-error "Cannot initialize parameter array" }
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr82721.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr82721.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr82721.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr82721.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,9 ----
+ ! { dg-do compile }
+ ! { dg-set-target-env-var MALLOC_PERTURB_ "165" }
+ ! PR fortran/82721
+ ! Reject a duplicate declaration without leaving the CHARACTER length
+ ! expression from the failed statement on the namespace charlen list.
+ 
+ integer :: b
+ character(len(c)) :: b  ! { dg-error "already has basic type of INTEGER" }
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr84245.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr84245.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr84245.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr84245.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,7 ----
+ ! { dg-do compile }
+ ! { dg-options "-w" }
+ 
+ program p
+   select type (x%a) ! { dg-error "Unexpected '%'.*nonderived-type variable 'x'" }
+   end select        ! { dg-error "Expecting END PROGRAM statement" }
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr93715.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr93715.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr93715.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr93715.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,11 ----
+ ! { dg-do compile }
+ ! { dg-options "-fcoarray=single" }
+ !
+ ! PR fortran/93715
+ ! A scalar coarray used in asynchronous I/O caused an ICE in
+ ! gfc_trans_auto_array_allocation.
+ 
+ program p
+    integer :: a, b[*]
+    read (1, *, asynchronous='yes') a, b
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr93814.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr93814.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr93814.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr93814.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,99 ----
+ ! { dg-do run }
+ !
+ ! PR fortran/93814 - ICE in build_entry_thunks with CHARACTER ENTRY
+ ! and bind(c).
+ !
+ ! Verify that CHARACTER function results with ENTRY and bind(c) compile
+ ! and execute correctly, covering all combinations of bind(c) on the
+ ! function and its entries.
+ 
+ ! Both function and entry have bind(c).
+ function f1() bind(c)
+   character :: f1, g1
+   f1 = "a"
+   return
+   entry g1() bind(c)
+   g1 = "b"
+ end
+ 
+ ! Only function has bind(c), entry does not.
+ function f2() bind(c)
+   character(1) :: f2, g2
+   f2 = "c"
+   return
+   entry g2()
+   g2 = "d"
+ end function
+ 
+ ! Only entry has bind(c), function does not.
+ function f3()
+   character(1) :: f3, g3
+   f3 = "e"
+   return
+   entry g3() bind(c)
+   g3 = "f"
+ end function
+ 
+ ! Neither function nor entry have bind(c) (baseline).
+ function f4()
+   character :: f4, g4
+   f4 = "g"
+   return
+   entry g4()
+   g4 = "h"
+ end
+ 
+ ! Integer with bind(c) (should still work).
+ function f5() bind(c)
+   integer :: f5, g5
+   f5 = 42
+   return
+   entry g5() bind(c)
+   g5 = 84
+ end
+ 
+ program p
+   interface
+     function f1() bind(c)
+       character :: f1
+     end
+     function g1() bind(c)
+       character :: g1
+     end
+     function f2() bind(c)
+       character(1) :: f2
+     end
+     function g2()
+       character(1) :: g2
+     end
+     function f3()
+       character(1) :: f3
+     end
+     function g3() bind(c)
+       character(1) :: g3
+     end
+     function f4()
+       character :: f4
+     end
+     function g4()
+       character :: g4
+     end
+     function f5() bind(c)
+       integer :: f5
+     end
+     function g5() bind(c)
+       integer :: g5
+     end
+   end interface
+ 
+   if (f1() /= "a") stop 1
+   if (g1() /= "b") stop 2
+   if (f2() /= "c") stop 3
+   if (g2() /= "d") stop 4
+   if (f3() /= "e") stop 5
+   if (g3() /= "f") stop 6
+   if (f4() /= "g") stop 7
+   if (g4() /= "h") stop 8
+   if (f5() /= 42)  stop 9
+   if (g5() /= 84)  stop 10
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr93832.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr93832.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr93832.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr93832.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,37 ----
+ module m
+ contains
+    subroutine comment0
+       type t
+          character :: a
+          integer :: b
+          integer :: c(t(1))            ! { dg-error "No initializer for component .b." }
+       end type
+       type(t) :: z = t('a', 2, [3])    ! { dg-error "Bad array spec of component .c." }
+    end
+ 
+    subroutine comment3a
+       type t
+          character :: a
+          integer :: b
+          integer :: c(t(1, "rubbish")) ! { dg-error "No initializer for component .c." }
+       end type
+       type(t) :: z = t('a', 2, [3])    ! { dg-error "Bad array spec of component .c." }
+    end
+ 
+    subroutine comment3b
+       type t
+          character :: a
+          integer :: b
+          integer :: c(t(1, "rubbish", [7])) ! { dg-error "Derived type or class expression" }
+       end type
+       type(t) :: z = t('a', 2, [3])    ! { dg-error "Bad array spec of component .c." }
+    end
+ 
+    subroutine comment9
+       type t
+          character :: a
+          integer :: b(t(1))            ! { dg-error "No initializer for component .b." }
+       end type
+       type(t) :: x = t('a', 2)
+    end
+ end module
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr94978.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr94978.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr94978.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr94978.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,24 ----
+ ! { dg-do compile }
+ ! { dg-options "-Wdo-subscript" }
+ 
+ implicit none
+ 
+ integer(4) :: i, j
+ integer(4) :: pascal(0:8, 0:8)
+ 
+ do i = 0, 8
+   pascal(i, 0) = 1
+   do j = 1, i - 1
+     pascal(i, j) = pascal(i - 1, j) + pascal(i - 1, j - 1) ! { dg-bogus "Array reference at \\(1\\) out of bounds" }
+   end do
+   do j = i, 8
+     pascal(i, j) = 0
+   end do
+   pascal(i, i) = 1
+ end do
+ 
+ do i = 0, 8
+   print '(9I4)', pascal(i, :)
+ end do
+ 
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr95338.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr95338.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr95338.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr95338.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,27 ----
+ ! { dg-do run }
+ ! { dg-additional-options "-O1 -ff2c" }
+ !
+ ! PR fortran/95338 - mixed ENTRY results with -ff2c must use the ABI
+ ! return type in the master union.
+ 
+ module m
+ contains
+   function f(x)
+     integer :: x
+     integer :: f
+     real :: g
+ 
+     f = x
+     return
+ 
+     entry g(x)
+     g = x
+   end
+ end
+ 
+ program p
+   use m
+ 
+   if (f(1) /= 1) stop 1
+   if (g(1) /= 1.0) stop 2
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr95879.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr95879.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr95879.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr95879.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,30 ----
+ ! { dg-do compile }
+ ! { dg-options "-std=f2018" }
+ ! PR fortran/95879
+ ! Contributed by G. Steinmetz 
+ !
+ ! Use-after-free in gfc_resolve_formal_arglist when a contained subroutine
+ ! has a statement function whose dummy argument name matches a symbol
+ ! replaced by gfc_fixup_sibling_symbols.
+ 
+ module m1
+ contains
+    integer function f(x) bind(c)
+       use iso_c_binding
+    contains
+       subroutine s
+          c_funloc(f) = x  ! { dg-warning "Obsolescent feature: Statement function" }
+       end
+    end
+ end
+ 
+ module m2
+ contains
+    integer function f(x)
+       use iso_c_binding
+    contains
+       subroutine s
+          c_funloc(f) = x  ! { dg-warning "Obsolescent feature: Statement function" }
+       end
+    end
+ end
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/pr96986.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr96986.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/pr96986.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/pr96986.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,25 ----
+ ! { dg-do compile }
+ ! { dg-options "-std=legacy" }
+ !
+ ! PR fortran/96986
+ ! Calling an ENTRY with no volatile arguments incorrectly required an
+ ! explicit interface because the volatile attribute from a sibling ENTRY
+ ! was checked against the master procedure's combined formal list.
+ 
+ subroutine volatile_test ()
+   implicit none
+   integer, volatile :: va
+ 
+   entry fun_a()
+   return
+ 
+   entry fun_b(va)
+     call fun_c()
+   return
+ end subroutine volatile_test
+ 
+ subroutine fun_c ()
+   implicit none
+   call fun_a()  ! Must not require explicit interface
+   return
+ end subroutine fun_c
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gfortran.dg/transfer_class_5.f90 gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/transfer_class_5.f90
*** gcc-13.4.0/gcc/testsuite/gfortran.dg/transfer_class_5.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gfortran.dg/transfer_class_5.f90	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,53 ----
+ ! { dg-do run }
+ ! PR fortran/121263 - fix TRANSFER with rank 1 unlimited polymorhpic
+ !
+ ! Based on original testcase by Chris Cox.
+ 
+ module stdlib_hashmap_wrappers
+   implicit none
+ contains
+   subroutine set_rank_one_key_int( key, value )
+     integer, allocatable, intent(inout) :: key(:)
+     class(*), intent(in)                :: value(:)
+     key = transfer( value, key )
+   end subroutine
+ 
+   subroutine set_rank_one_key_cx ( key, value )
+     complex, allocatable, intent(inout) :: key(:)
+     class(*), intent(in)                :: value(:)
+     key = transfer( value, key )
+   end subroutine
+ 
+   subroutine set_first_key_int   ( key, value )
+     integer, intent(inout) :: key
+     class(*), intent(in)   :: value(:)
+     key = transfer( value(1), key )
+   end subroutine
+ end module
+ 
+ program p
+   use stdlib_hashmap_wrappers
+   implicit none
+   integer, allocatable :: a(:), b(:)
+   complex, allocatable :: c(:), d(:)
+   class(*),allocatable :: z(:)
+   integer :: m
+   a = [1, 2, 3, 4, 5]
+   c = cmplx (a, -a)
+   call set_rank_one_key_int (b, a)
+   call set_rank_one_key_cx  (d, c)
+   call set_first_key_int    (m, a)
+ ! print *, b
+ ! print *, d
+   if (size (a) /= size (b)) stop 1
+   if (any  (a  /=       b)) stop 2
+   if (size (c) /= size (d)) stop 3
+   if (any  (c  /=       d)) stop 4
+   if (m /= 1) stop 5
+   deallocate (d)
+   z = c
+   d = transfer (z, d)
+   if (size (c) /= size (d)) stop 6
+   if (any  (c  /=       d)) stop 7
+   deallocate (a, b, c, d, z)
+ end program p
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/bigint1.adb gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/bigint1.adb
*** gcc-13.4.0/gcc/testsuite/gnat.dg/bigint1.adb	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/bigint1.adb	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,27 ----
+ -- { dg-do run }
+ -- { dg-options "-gnat2022 -gnata" }
+ 
+ with Ada.Numerics.Big_Numbers.Big_Integers;
+ use Ada.Numerics.Big_Numbers.Big_Integers;
+ 
+ procedure Bigint1 is
+ 
+   Minus_One   : constant Big_Integer := To_Big_Integer (-1);
+   Minus_Two   : constant Big_Integer := To_Big_Integer (-2);
+   Minus_Three : constant Big_Integer := To_Big_Integer (-3);
+ 
+ begin
+ 
+   pragma Assert (Minus_One ** 1 = Minus_One);
+   pragma Assert (Minus_One ** 2 = To_Big_Integer (1));
+   pragma Assert (Minus_One ** 3 = Minus_One);
+ 
+   pragma Assert (Minus_Two ** 1 = Minus_Two);
+   pragma Assert (Minus_Two ** 2 = To_Big_Integer (4));
+   pragma Assert (Minus_Two ** 3 = To_Big_Integer (-8));
+ 
+   pragma Assert (Minus_Three ** 1 = Minus_Three);
+   pragma Assert (Minus_Three ** 2 = To_Big_Integer (9));
+   pragma Assert (Minus_Three ** 3 = To_Big_Integer (-27));
+ 
+ end;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/generic_inst20-sub.adb gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/generic_inst20-sub.adb
*** gcc-13.4.0/gcc/testsuite/gnat.dg/generic_inst20-sub.adb	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/generic_inst20-sub.adb	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,14 ----
+ -- { dg-excess-errors "cannot generate code" }
+ 
+ separate (Generic_Inst20)
+ 
+ package body Sub is
+    function F return Boolean is
+    begin
+       return True;
+    end F;
+    generic
+    package G is
+    end G;
+    package I is new G;
+ end Sub;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/generic_inst20.adb gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/generic_inst20.adb
*** gcc-13.4.0/gcc/testsuite/gnat.dg/generic_inst20.adb	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/generic_inst20.adb	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,5 ----
+ -- { dg-do compile }
+ 
+ package body Generic_Inst20 is
+    package body Sub is separate;
+ end Generic_Inst20;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/generic_inst20.ads gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/generic_inst20.ads
*** gcc-13.4.0/gcc/testsuite/gnat.dg/generic_inst20.ads	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/generic_inst20.ads	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,6 ----
+ package Generic_Inst20 is
+    pragma Elaborate_Body;
+    package Sub is
+       function F return Boolean;
+    end Sub;
+ end Generic_Inst20;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/opt107.adb gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/opt107.adb
*** gcc-13.4.0/gcc/testsuite/gnat.dg/opt107.adb	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/opt107.adb	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,27 ----
+ -- { dg-do compile }
+ -- { dg-options "-O" }
+ 
+ with Opt107_Pkg; use Opt107_Pkg;
+ 
+ function Opt107 return Rec is
+    R : Rec;
+ begin
+    R.W1A := B_A_7;
+    R.W1B := 0;
+    R.W1C := C_A;
+    R.W1D := (Spare => 0,
+              D_A => 0,
+              D_B => 0,
+              D_C => 0,
+              D_D => 0);
+    R.W2B := (Spare => 0,
+              E_A => 0,
+              E_B => 0,
+              E_C => 0,
+              E_D => 0,
+              E_E => 0,
+              E_F => 0,
+              E_G => 0,
+              E_H => 0);
+    return R;
+ end;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/opt107_pkg.ads gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/opt107_pkg.ads
*** gcc-13.4.0/gcc/testsuite/gnat.dg/opt107_pkg.ads	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/opt107_pkg.ads	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,156 ----
+ with System;
+ with Unchecked_Conversion;
+ 
+ package Opt107_Pkg is
+ 
+    Word_Size : constant := 32;
+    type Word_Type is mod 2 ** Word_Size;
+    for Word_Type'Size use Word_Size;
+ 
+    Word : constant := Word_Size / System.Storage_Unit;
+ 
+    Halfword_Size : constant := Word_Size / 2;
+    
+    type Halfword_Type is range 0 .. 2 ** Halfword_Size - 1;
+    for Halfword_Type'Size use Halfword_Size;
+ 
+    type One_Bit_Type is mod 2 ** 1;
+    for One_Bit_Type'Size use 1;
+    
+    type Four_Bit_Type is mod 2 ** 4;
+    for Four_Bit_Type'Size use 4;
+ 
+    type Seven_Bit_Type is mod 2 ** 7;
+    for Seven_Bit_Type'Size use 7;
+ 
+    type Eight_Bit_Type is mod 2 ** 8;
+    for Eight_Bit_Type'Size use 8;
+ 
+    type Twelve_Bit_Type is mod 2 ** 12;
+    for Twelve_Bit_Type'Size use 12;
+    
+    type Thirty_One_Bit_Type is mod 2 ** 31;
+    for Thirty_One_Bit_Type'Size use 31;
+ 
+    type W0_Type is record
+       A : Eight_Bit_Type;
+       B : Eight_Bit_Type;
+       C : Halfword_Type;
+    end record;
+ 
+    for W0_Type use record
+       A at Word * 0 range 24 .. 31;
+       B at Word * 0 range 16 .. 23;
+       C at Word * 0 range 0 .. 15;
+    end record;
+    for W0_Type'Size use Word_Size;
+ 
+    type A_Type is (A0, A1);
+    for A_Type use (A0 => 0, A1 => 1);
+    for A_Type'Size use 1;
+    
+    type B_Type is (B_A_1,
+                    B_A_2,
+                    B_A_3,
+                    B_A_4,
+                    B_A_5,
+                    B_A_6,
+                    B_A_7,
+                    B_A_8,
+                    B_B_1,
+                    B_B_2,
+                    B_B_3,
+                    B_B_4,
+                    B_B_5,
+                    B_B_6,
+                    B_B_7,
+                    B_B_8);
+ 
+    for B_Type use (B_A_1 => 8#00#,
+                    B_A_2 => 8#01#,
+                    B_A_3 => 8#02#,
+                    B_A_4 => 8#03#,
+                    B_A_5 => 8#04#,
+                    B_A_6 => 8#05#,
+                    B_A_7 => 8#06#,
+                    B_A_8 => 8#07#,
+                    B_B_1 => 8#10#,
+                    B_B_2 => 8#11#,
+                    B_B_3 => 8#12#,
+                    B_B_4 => 8#13#,
+                    B_B_5 => 8#14#,
+                    B_B_6 => 8#15#,
+                    B_B_7 => 8#16#,
+                    B_B_8 => 8#17#);
+    for B_Type'Size use 8;
+    
+    type C_Type is (C_A, C_B);
+    for C_Type use (C_A => 0, C_B => 2);
+    for C_Type'Size use 4;
+    
+    type D_Type is record
+       Spare : Twelve_Bit_Type;
+       D_A : One_Bit_Type;
+       D_B : One_Bit_Type;
+       D_C : One_Bit_Type;
+       D_D : One_Bit_Type;
+    end record;
+ 
+    for D_Type use record
+       Spare at 0 range 4 .. 15;
+       D_A at 0 range 3 .. 3;
+       D_B at 0 range 2 .. 2;
+       D_C at 0 range 1 .. 1;
+       D_D at 0 range 0 .. 0;
+    end record;
+    for D_Type'Size use Halfword_Size;
+ 
+    type E_Type is record
+       Spare : Seven_Bit_Type;
+       E_A : One_Bit_Type;
+       E_B : One_Bit_Type;
+       E_C : One_Bit_Type;
+       E_D : One_Bit_Type;
+       E_E : One_Bit_Type;
+       E_F : One_Bit_Type;
+       E_G : One_Bit_Type;
+       E_H : One_Bit_Type;
+    end record;
+ 
+    for E_Type use record
+       Spare at 0 range 8 .. 14;
+       E_A at 0 range 7 .. 7;
+       E_B at 0 range 6 .. 6;
+       E_C at 0 range 5 .. 5;
+       E_D at 0 range 4 .. 4;
+       E_E at 0 range 3 .. 3;
+       E_F at 0 range 2 .. 2;
+       E_G at 0 range 1 .. 1;
+       E_H at 0 range 0 .. 0;
+    end record;
+    for E_Type'Size use 15;
+ 
+    type Rec is record
+       W0 : W0_Type;
+       W1A : B_Type;
+       W1B : Four_Bit_Type;
+       W1C : C_Type;
+       W1D : D_Type;
+       W2A : A_Type;
+       W2B : E_Type;
+       W2C : Halfword_Type;
+    end record;
+ 
+    for Rec use record
+       W0  at Word * 0 range  0 .. 31;
+       W1A at Word * 1 range 24 .. 31;
+       W1B at Word * 1 range 20 .. 23;
+       W1C at Word * 1 range 16 .. 19;
+       W1D at Word * 1 range  0 .. 15;
+       W2A at Word * 2 range 31 .. 31;
+       W2B at Word * 2 range 16 .. 30;
+       W2C at Word * 2 range  0 .. 15;
+    end record;
+    for Rec'Size use 6 * Halfword_Size;
+ 
+ end Opt107_Pkg;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/protected_deref1.adb gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/protected_deref1.adb
*** gcc-13.4.0/gcc/testsuite/gnat.dg/protected_deref1.adb	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/protected_deref1.adb	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,32 ----
+ -- { dg-do run }
+ 
+ with Ada.Text_IO;
+ 
+ procedure Protected_Deref1 is
+ 
+    protected type Fallback_Hit_Counter_Type is
+       procedure Handler;
+    end Fallback_Hit_Counter_Type;
+ 
+    protected body Fallback_Hit_Counter_Type is
+       procedure Handler is
+       begin
+          Ada.Text_IO.Put_Line ("Test");
+       end Handler;
+    end Fallback_Hit_Counter_Type;
+ 
+    Fallback_Hit_Counter : access Fallback_Hit_Counter_Type :=
+      new Fallback_Hit_Counter_Type;
+ 
+    type X is access protected procedure;
+ 
+    A : X := Fallback_Hit_Counter.all.Handler'Access;
+    B : X := Fallback_Hit_Counter.Handler'Access;
+ 
+ begin
+    A.all;
+    B.all;
+    if A /= B then
+       raise Program_Error;
+    end if;
+ end;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/renaming18.adb gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/renaming18.adb
*** gcc-13.4.0/gcc/testsuite/gnat.dg/renaming18.adb	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/renaming18.adb	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,24 ----
+ -- { dg-do compile }
+ -- { dg-options "-gnatwu" }
+ 
+ procedure Renaming18 is
+ 
+   type T is record
+     Item : Integer;
+   end record;
+ 
+   A_T : T;
+   Item : Integer renames A_T.Item;
+ 
+   type VFA_T is record
+     Item : Integer;
+   end record
+   with Volatile_Full_Access;
+ 
+   A_VFA_T : VFA_T;
+   VFA_Item : Integer renames A_VFA_T.Item; -- { dg-bogus "is not referenced" }
+ 
+ begin
+   Item := 42;
+   VFA_Item := 42;
+ end;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/specs/opt7.ads gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/specs/opt7.ads
*** gcc-13.4.0/gcc/testsuite/gnat.dg/specs/opt7.ads	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/specs/opt7.ads	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,15 ----
+ -- { dg-do compile }
+ -- { dg-options "-O2 -gnatn" }
+ 
+ with Opt7_Pkg; use Opt7_Pkg;
+ 
+ package Opt7 is
+ 
+   type Rec is record
+     E : Enum;
+   end record;
+ 
+   function Image (R : Rec) return String is
+     (if R.E = A then Image (R.E) else "");
+ 
+ end Opt7;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/specs/opt7_pkg.adb gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/specs/opt7_pkg.adb
*** gcc-13.4.0/gcc/testsuite/gnat.dg/specs/opt7_pkg.adb	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/specs/opt7_pkg.adb	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,15 ----
+ package body Opt7_Pkg is
+ 
+   type Constant_String_Access is access constant String;
+ 
+   type Enum_Name is array (Enum) of Constant_String_Access;
+ 
+   Enum_Name_Table : constant Enum_Name :=
+     (A => new String'("A"), B => new String'("B"));
+ 
+   function Image (E : Enum) return String is
+   begin
+     return Enum_Name_Table (E).all;
+   end Image;
+ 
+ end Opt7_Pkg;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/specs/opt7_pkg.ads gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/specs/opt7_pkg.ads
*** gcc-13.4.0/gcc/testsuite/gnat.dg/specs/opt7_pkg.ads	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/specs/opt7_pkg.ads	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,9 ----
+ -- { dg-excess-errors "no code generated" }
+ 
+ package Opt7_Pkg is
+ 
+   type Enum is (A, B);
+ 
+   function Image (E : Enum) return String with Inline;
+ 
+ end Opt7_Pkg;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/specs/unchecked_union3.ads gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/specs/unchecked_union3.ads
*** gcc-13.4.0/gcc/testsuite/gnat.dg/specs/unchecked_union3.ads	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/specs/unchecked_union3.ads	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,80 ----
+ -- { dg-do compile }
+ 
+ with Interfaces;
+ 
+ package Unchecked_Union3 is
+ 
+    type T_CAN_ID is mod 2**29 with
+       Default_Value => 0,
+       Size          => 29;
+ 
+    type T_Node_ID is mod 2**7 with
+       Size          => 7,
+       Default_Value => 0;
+ 
+    type T_Message_Type_ID is new Interfaces.Unsigned_16;
+ 
+    type T_Service_Type_ID is new Interfaces.Unsigned_8;
+ 
+    type T_Priority is mod 2**5 with
+       Size          => 5,
+       Default_Value => 0;
+ 
+    type T_Format_Selector is
+      (CAN_Fields,
+       DroneCAN_Fields);
+ 
+    type T_Frame_Selector is
+      (Message_Frame,
+       Anonymous_Frame,
+       Service_Frame);
+ 
+    type Unsigned_2 is mod 2**2 with
+       Size          => 2,
+       Default_Value => 0;
+ 
+    type Unsigned_14 is mod 2**14 with
+       Size          => 14,
+       Default_Value => 0;
+ 
+    type T_Header (Format_Selector : T_Format_Selector := DroneCAN_Fields;
+       Frame_Selector              : T_Frame_Selector  := Message_Frame) is record
+       case Format_Selector is
+          when CAN_Fields =>
+             CAN_ID : T_CAN_ID;
+ 
+          when DroneCAN_Fields =>
+             Source_Node_ID      : T_Node_ID;
+             Service_Not_Message : Boolean := False;
+             Priority            : T_Priority;
+ 
+             case Frame_Selector is
+                when Message_Frame =>
+                   Message_Type_ID : T_Message_Type_ID;
+                when Anonymous_Frame =>
+                   Message_Type_ID_Lower_Bits : Unsigned_2;
+                   Discriminator              : Unsigned_14;
+                when Service_Frame =>
+                   Destination_Node_ID  : T_Node_ID;
+                   Request_Not_Response : Boolean := False;
+                   Service_Type_ID      : T_Service_Type_ID;
+             end case;
+       end case;
+    end record with
+       Unchecked_Union,
+       Size => 29;
+ 
+    for T_Header use record
+       CAN_ID                     at 0 range  0 .. 28;
+       Source_Node_ID             at 0 range  0 ..  6;
+       Service_Not_Message        at 0 range  7 ..  7;
+       Priority                   at 0 range 24 .. 28;
+       Message_Type_ID            at 0 range  8 .. 23;
+       Message_Type_ID_Lower_Bits at 0 range  8 ..  9;
+       Discriminator              at 0 range 10 .. 23;
+       Destination_Node_ID        at 0 range  8 .. 14;
+       Request_Not_Response       at 0 range 15 .. 15;
+       Service_Type_ID            at 0 range 16 .. 23;
+    end record;
+ 
+ end Unchecked_Union3;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/gnat.dg/sso20.adb gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/sso20.adb
*** gcc-13.4.0/gcc/testsuite/gnat.dg/sso20.adb	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/gcc/testsuite/gnat.dg/sso20.adb	Fri Sep  4 07:35:11 2026
***************
*** 0 ****
--- 1,29 ----
+ --  { dg-do run }
+ --  { dg-options "-O" }
+ 
+ with Ada.Unchecked_Conversion;
+ with Interfaces;  use Interfaces;
+ with System;      use System;
+ 
+ procedure SSO20 is
+ 
+   type Bytes_Ref is array (1 .. 4) of Unsigned_8
+     with Convention => Ada_Pass_By_Reference;
+ 
+   type U32_BE is record
+     Value : Unsigned_32;
+   end record
+     with
+       Pack,
+       Bit_Order            => High_Order_First,
+       Scalar_Storage_Order => High_Order_First;
+ 
+   function Conv is new Ada.Unchecked_Conversion (Bytes_Ref, U32_BE);
+ 
+   function Value (B : Bytes_Ref) return Unsigned_32 is (Conv (B).Value);
+ 
+ begin
+   if Value ((16#11#, 16#22#, 16#33#, 16#44#)) /= 16#11223344# then
+      raise Program_Error;
+   end if;
+ end;
diff -Nrcpad gcc-13.4.0/gcc/testsuite/go.test/go-test.exp gcc-13.5.0-RC-20260904/gcc/testsuite/go.test/go-test.exp
*** gcc-13.4.0/gcc/testsuite/go.test/go-test.exp	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/go.test/go-test.exp	Fri Sep  4 07:35:11 2026
*************** proc errchk { test opts } {
*** 82,90 ****
  	set filename "errchk-$filename"
      }
      set fdin [open $test r]
!     fconfigure $fdin -encoding binary
      set fdout [open $filename w]
!     fconfigure $fdout -encoding binary
      while { [gets $fdin copy_line] >= 0 } {
  	if [string match "*////*" $copy_line] {
  	    puts $fdout $copy_line
--- 82,90 ----
  	set filename "errchk-$filename"
      }
      set fdin [open $test r]
!     fconfigure $fdin -translation binary
      set fdout [open $filename w]
!     fconfigure $fdout -translation binary
      while { [gets $fdin copy_line] >= 0 } {
  	if [string match "*////*" $copy_line] {
  	    puts $fdout $copy_line
diff -Nrcpad gcc-13.4.0/gcc/testsuite/lib/mike-g++.exp gcc-13.5.0-RC-20260904/gcc/testsuite/lib/mike-g++.exp
*** gcc-13.4.0/gcc/testsuite/lib/mike-g++.exp	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/lib/mike-g++.exp	Fri Sep  4 07:35:11 2026
*************** proc postbase  { src_code run groups arg
*** 101,107 ****
  
      set compile_type "none"
  
!     case $actions {
  	compile
  	{
  	    set compile_type "assembly"
--- 101,107 ----
  
      set compile_type "none"
  
!     switch $actions {
  	compile
  	{
  	    set compile_type "assembly"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/lib/mike-gcc.exp gcc-13.5.0-RC-20260904/gcc/testsuite/lib/mike-gcc.exp
*** gcc-13.4.0/gcc/testsuite/lib/mike-gcc.exp	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/lib/mike-gcc.exp	Fri Sep  4 07:35:11 2026
*************** proc postbase  { src_code run groups arg
*** 105,111 ****
  
      set compile_type "none"
  
!     case $actions {
  	compile
  	{
  	    set compile_type "assembly"
--- 105,111 ----
  
      set compile_type "none"
  
!     switch $actions {
  	compile
  	{
  	    set compile_type "assembly"
diff -Nrcpad gcc-13.4.0/gcc/testsuite/lib/target-supports.exp gcc-13.5.0-RC-20260904/gcc/testsuite/lib/target-supports.exp
*** gcc-13.4.0/gcc/testsuite/lib/target-supports.exp	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/testsuite/lib/target-supports.exp	Fri Sep  4 07:35:11 2026
*************** foreach { armfunc armflag armdefs } {
*** 5059,5064 ****
--- 5059,5065 ----
  	v8_1m_main "-march=armv8.1-m.main -mthumb" __ARM_ARCH_8M_MAIN__
  	v8_1m_main_pacbti "-march=armv8.1-m.main+pacbti+fp -mthumb"
  		"__ARM_ARCH_8M_MAIN__ && __ARM_FEATURE_BTI && __ARM_FEATURE_PAUTH"
+ 	v8_1m_main_fp_hard "-march=armv8.1-m.main+pacbti+fp -mthumb -mfpu=auto -mfloat-abi=hard" "__ARM_ARCH_8M_MAIN__ && (__ARM_FP & 2)"
  	v9a "-march=armv9-a" __ARM_ARCH_9A__ } {
      eval [string map [list FUNC $armfunc FLAG $armflag DEFS $armdefs ] {
  	proc check_effective_target_arm_arch_FUNC_ok { } {
*************** proc add_options_for_arm_v8_3a_fp16_comp
*** 11930,11936 ****
  
  proc check_effective_target_arm_v8_3a_complex_neon_hw { } {
      if { ![check_effective_target_arm_v8_3a_complex_neon_ok] } {
!         return 1;
      }
      return [check_runtime arm_v8_3a_complex_neon_hw_available {
          #include "arm_neon.h"
--- 11931,11937 ----
  
  proc check_effective_target_arm_v8_3a_complex_neon_hw { } {
      if { ![check_effective_target_arm_v8_3a_complex_neon_ok] } {
! 	return 0;
      }
      return [check_runtime arm_v8_3a_complex_neon_hw_available {
          #include "arm_neon.h"
diff -Nrcpad gcc-13.4.0/gcc/tree-inline.cc gcc-13.5.0-RC-20260904/gcc/tree-inline.cc
*** gcc-13.4.0/gcc/tree-inline.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-inline.cc	Fri Sep  4 07:35:11 2026
*************** copy_edges_for_bb (basic_block bb, profi
*** 2683,2688 ****
--- 2683,2691 ----
  	      make_single_succ_edge (copy_stmt_bb, abnormal_goto_dest,
  				     EDGE_ABNORMAL);
  	      gimple_call_set_ctrl_altering (copy_stmt, true);
+ 	      if (is_a  (copy_stmt)
+ 		  && (gimple_call_flags (copy_stmt) & ECF_NORETURN))
+ 		fixup_noreturn_call (copy_stmt);
  	    }
  	}
  
*************** copy_debug_stmts (copy_body_data *id)
*** 3293,3299 ****
      return;
  
    for (gdebug *stmt : id->debug_stmts)
!     copy_debug_stmt (stmt, id);
  
    id->debug_stmts.release ();
  }
--- 3296,3304 ----
      return;
  
    for (gdebug *stmt : id->debug_stmts)
!     /* But avoid re-processing debug stmts that have been elided.  */
!     if (gimple_bb (stmt))
!       copy_debug_stmt (stmt, id);
  
    id->debug_stmts.release ();
  }
*************** expand_call_inline (basic_block bb, gimp
*** 5186,5192 ****
    if (use_retvar && gimple_call_lhs (stmt))
      {
        gimple *old_stmt = stmt;
!       stmt = gimple_build_assign (gimple_call_lhs (stmt), use_retvar);
        gimple_set_location (stmt, gimple_location (old_stmt));
        gsi_replace (&stmt_gsi, stmt, false);
        maybe_clean_or_replace_eh_stmt (old_stmt, stmt);
--- 5191,5210 ----
    if (use_retvar && gimple_call_lhs (stmt))
      {
        gimple *old_stmt = stmt;
!       tree lhs = gimple_call_lhs (stmt);
!       if (!is_gimple_reg (lhs)
! 	  && !is_gimple_reg (use_retvar)
! 	  && is_gimple_reg_type (TREE_TYPE (lhs)))
! 	{
! 	  /* If both lhs and use_retvar aren't gimple regs, yet have
! 	     gimple reg type, copy through a temporary SSA_NAME.  */
! 	  gimple *g = gimple_build_assign (make_ssa_name (TREE_TYPE (lhs)),
! 					   use_retvar);
! 	  gimple_set_location (g, gimple_location (old_stmt));
! 	  gsi_insert_before (&stmt_gsi, g, GSI_SAME_STMT);
! 	  use_retvar = gimple_assign_lhs (g);
! 	}
!       stmt = gimple_build_assign (lhs, use_retvar);
        gimple_set_location (stmt, gimple_location (old_stmt));
        gsi_replace (&stmt_gsi, stmt, false);
        maybe_clean_or_replace_eh_stmt (old_stmt, stmt);
diff -Nrcpad gcc-13.4.0/gcc/tree-object-size.cc gcc-13.5.0-RC-20260904/gcc/tree-object-size.cc
*** gcc-13.4.0/gcc/tree-object-size.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-object-size.cc	Fri Sep  4 07:35:11 2026
*************** object_sizes_set_temp (struct object_siz
*** 330,338 ****
    tree val = object_sizes_get (osi, varno);
  
    if (size_initval_p (val, osi->object_size_type))
!     object_sizes_set (osi, varno,
! 		      make_ssa_name (sizetype),
! 		      make_ssa_name (sizetype));
  }
  
  /* Initialize OFFSET_LIMIT variable.  */
--- 330,340 ----
    tree val = object_sizes_get (osi, varno);
  
    if (size_initval_p (val, osi->object_size_type))
!     {
!       val = make_ssa_name (sizetype);
!       tree wholeval = make_ssa_name (sizetype);
!       object_sizes_set (osi, varno, val, wholeval);
!     }
  }
  
  /* Initialize OFFSET_LIMIT variable.  */
diff -Nrcpad gcc-13.4.0/gcc/tree-scalar-evolution.cc gcc-13.5.0-RC-20260904/gcc/tree-scalar-evolution.cc
*** gcc-13.4.0/gcc/tree-scalar-evolution.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-scalar-evolution.cc	Fri Sep  4 07:35:11 2026
*************** scev_dfs::add_to_evolution_1 (tree chrec
*** 669,674 ****
--- 669,685 ----
  	  to_add = chrec_convert (type, to_add, at_stmt);
  	  right = chrec_convert_rhs (type, right, at_stmt);
  	  right = chrec_fold_plus (chrec_type (right), right, to_add);
+ 	  /* When we have an evolution in a non-wrapping type and
+ 	     in the process of accumulating CHREC_RIGHT there was
+ 	     overflow this indicates in the association that happened
+ 	     in building the CHREC clearly involved UB.  Avoid this.
+ 	     In building a CHREC we basically turn (a + INCR1) + INCR2
+ 	     into a + (INCR1 + INCR2) which is not always valid.
+ 	     Note this check only catches few invalid cases.  */
+ 	  if ((INTEGRAL_TYPE_P (type) && ! TYPE_OVERFLOW_WRAPS (type))
+ 	      && TREE_CODE (right) == INTEGER_CST
+ 	      && TREE_OVERFLOW (right))
+ 	    return chrec_dont_know;
  	  return build_polynomial_chrec (var, left, right);
  	}
        else
diff -Nrcpad gcc-13.4.0/gcc/tree-sra.cc gcc-13.5.0-RC-20260904/gcc/tree-sra.cc
*** gcc-13.4.0/gcc/tree-sra.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-sra.cc	Fri Sep  4 07:35:11 2026
*************** build_debug_ref_for_model (location_t lo
*** 1928,1943 ****
  }
  
  /* Construct a memory reference consisting of component_refs and array_refs to
!    a part of an aggregate *RES (which is of type TYPE).  The requested part
!    should have type EXP_TYPE at be the given OFFSET.  This function might not
!    succeed, it returns true when it does and only then *RES points to something
!    meaningful.  This function should be used only to build expressions that we
!    might need to present to user (e.g. in warnings).  In all other situations,
     build_ref_for_model or build_ref_for_offset should be used instead.  */
  
  static bool
  build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,
! 				    tree exp_type)
  {
    while (1)
      {
--- 1928,1947 ----
  }
  
  /* Construct a memory reference consisting of component_refs and array_refs to
!    a part of an aggregate *RES which is of type TYPE.  The requested part
!    should have type EXP_TYPE at the given OFFSET.  CUR_SIZE must be the size of
!    *RES unless it is known that *RES alone cannot be the result.  This function
!    might not succeed, it returns true when it does and only then *RES points to
!    something meaningful.
! 
!    This function should be used only to build expressions that we might need to
!    present to user (e.g. in warnings).  In all other situations,
     build_ref_for_model or build_ref_for_offset should be used instead.  */
  
  static bool
  build_user_friendly_ref_for_offset (tree *res, tree type, HOST_WIDE_INT offset,
! 				    HOST_WIDE_INT cur_size, tree exp_type,
! 				    HOST_WIDE_INT exp_size)
  {
    while (1)
      {
*************** build_user_friendly_ref_for_offset (tree
*** 1945,1951 ****
        tree tr_size, index, minidx;
        HOST_WIDE_INT el_size;
  
!       if (offset == 0 && exp_type
  	  && types_compatible_p (exp_type, type))
  	return true;
  
--- 1949,1956 ----
        tree tr_size, index, minidx;
        HOST_WIDE_INT el_size;
  
!       if (offset == 0
! 	  && cur_size == exp_size
  	  && types_compatible_p (exp_type, type))
  	return true;
  
*************** build_user_friendly_ref_for_offset (tree
*** 1983,1989 ****
  			     NULL_TREE);
  	      expr_ptr = &expr;
  	      if (build_user_friendly_ref_for_offset (expr_ptr, TREE_TYPE (fld),
! 						      offset - pos, exp_type))
  		{
  		  *res = expr;
  		  return true;
--- 1988,1995 ----
  			     NULL_TREE);
  	      expr_ptr = &expr;
  	      if (build_user_friendly_ref_for_offset (expr_ptr, TREE_TYPE (fld),
! 						      offset - pos, size,
! 						      exp_type, exp_size))
  		{
  		  *res = expr;
  		  return true;
*************** build_user_friendly_ref_for_offset (tree
*** 2006,2022 ****
  	  *res = build4 (ARRAY_REF, TREE_TYPE (type), *res, index,
  			 NULL_TREE, NULL_TREE);
  	  offset = offset % el_size;
  	  type = TREE_TYPE (type);
  	  break;
  
  	default:
! 	  if (offset != 0)
! 	    return false;
! 
! 	  if (exp_type)
! 	    return false;
! 	  else
! 	    return true;
  	}
      }
  }
--- 2012,2023 ----
  	  *res = build4 (ARRAY_REF, TREE_TYPE (type), *res, index,
  			 NULL_TREE, NULL_TREE);
  	  offset = offset % el_size;
+ 	  cur_size = el_size;
  	  type = TREE_TYPE (type);
  	  break;
  
  	default:
! 	  return false;
  	}
      }
  }
*************** path_comparable_for_same_access (tree ex
*** 2154,2159 ****
--- 2155,2165 ----
      {
        if (!zerop (TREE_OPERAND (expr, 1)))
  	return false;
+       gcc_assert (TREE_CODE (TREE_OPERAND (expr, 0)) == ADDR_EXPR
+ 		  && DECL_P (TREE_OPERAND (TREE_OPERAND (expr, 0), 0)));
+       if (TYPE_MAIN_VARIANT (TREE_TYPE (expr))
+ 	  != TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (TREE_OPERAND (expr, 0), 0))))
+ 	return false;
      }
    else
      gcc_assert (DECL_P (expr));
*************** sort_and_splice_var_accesses (tree var)
*** 2302,2307 ****
--- 2308,2319 ----
  		}
  	      unscalarizable_region = true;
  	    }
+ 	  /* If there the same place is accessed with two incompatible
+ 	     aggregate types, trying to base total scalarization on either of
+ 	     them can be wrong.  */
+ 	  if (!first_scalar && !types_compatible_p (access->type, ac2->type))
+ 	    bitmap_set_bit (cannot_scalarize_away_bitmap,
+ 			    DECL_UID (access->base));
  
  	  if (grp_same_access_path
  	      && (!ac2->grp_same_access_path
*************** analyze_access_subtree (struct access *r
*** 2687,2693 ****
  
    for (child = root->first_child; child; child = child->next_sibling)
      {
!       hole |= covered_to < child->offset;
        sth_created |= analyze_access_subtree (child, root,
  					     allow_replacements && !scalar,
  					     totally);
--- 2699,2708 ----
  
    for (child = root->first_child; child; child = child->next_sibling)
      {
!       if (totally)
! 	covered_to = child->offset;
!       else
! 	hole |= covered_to < child->offset;
        sth_created |= analyze_access_subtree (child, root,
  					     allow_replacements && !scalar,
  					     totally);
*************** analyze_access_subtree (struct access *r
*** 2697,2702 ****
--- 2712,2719 ----
  	covered_to += child->size;
        else
  	hole = true;
+       if (totally && !hole)
+ 	covered_to = limit;
      }
  
    if (allow_replacements && scalar && !root->first_child
*************** analyze_access_subtree (struct access *r
*** 2765,2771 ****
  	root->grp_total_scalarization = 0;
      }
  
!   if (!hole || totally)
      root->grp_covered = 1;
    else if (root->grp_write || comes_initialized_p (root->base))
      root->grp_unscalarized_data = 1; /* not covered and written to */
--- 2782,2788 ----
  	root->grp_total_scalarization = 0;
      }
  
!   if (!hole)
      root->grp_covered = 1;
    else if (root->grp_write || comes_initialized_p (root->base))
      root->grp_unscalarized_data = 1; /* not covered and written to */
*************** create_artificial_child_access (struct a
*** 2836,2842 ****
    struct access *access = access_pool.allocate ();
    memset (access, 0, sizeof (struct access));
    if (!build_user_friendly_ref_for_offset (&expr, TREE_TYPE (expr), new_offset,
! 					   model->type))
      {
        access->grp_no_warning = true;
        expr = build_ref_for_model (EXPR_LOCATION (parent->base), parent->base,
--- 2853,2860 ----
    struct access *access = access_pool.allocate ();
    memset (access, 0, sizeof (struct access));
    if (!build_user_friendly_ref_for_offset (&expr, TREE_TYPE (expr), new_offset,
! 					   parent->size, model->type,
! 					   model->size))
      {
        access->grp_no_warning = true;
        expr = build_ref_for_model (EXPR_LOCATION (parent->base), parent->base,
*************** propagate_subaccesses_from_rhs (struct a
*** 2975,2982 ****
  	  tree t = lacc->base;
  
  	  lacc->type = racc->type;
  	  if (build_user_friendly_ref_for_offset (&t, TREE_TYPE (t),
! 						  lacc->offset, racc->type))
  	    {
  	      lacc->expr = t;
  	      lacc->grp_same_access_path = true;
--- 2993,3003 ----
  	  tree t = lacc->base;
  
  	  lacc->type = racc->type;
+ 	  /* We know racc and lacc are of different types so can pass -1 as
+ 	     cur_size.  */
  	  if (build_user_friendly_ref_for_offset (&t, TREE_TYPE (t),
! 						  lacc->offset, -1,
! 						  racc->type, racc->size))
  	    {
  	      lacc->expr = t;
  	      lacc->grp_same_access_path = true;
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-alias.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-alias.cc
*** gcc-13.4.0/gcc/tree-ssa-alias.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-alias.cc	Fri Sep  4 07:35:11 2026
*************** ptr_deref_may_alias_decl_p (tree ptr, tr
*** 295,300 ****
--- 295,305 ----
    if (!may_be_aliased (decl))
      return false;
  
+   /* From here we require a SSA name pointer.  Anything else aliases.  */
+   if (TREE_CODE (ptr) != SSA_NAME
+       || !POINTER_TYPE_P (TREE_TYPE (ptr)))
+     return true;
+ 
    /* If we do not have useful points-to information for this pointer
       we cannot disambiguate anything else.  */
    pi = SSA_NAME_PTR_INFO (ptr);
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-dse.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-dse.cc
*** gcc-13.4.0/gcc/tree-ssa-dse.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-dse.cc	Fri Sep  4 07:35:11 2026
*************** initialize_ao_ref_for_dse (gimple *stmt,
*** 169,177 ****
  	     can provide a may-def variant.  */
  	  if (may_def_ok)
  	    {
! 	      ao_ref_init_from_ptr_and_size
! 		  (write, gimple_call_arg (stmt, 0),
! 		   TYPE_SIZE_UNIT (TREE_TYPE (gimple_call_arg (stmt, 3))));
  	      return true;
  	    }
  	  break;
--- 169,178 ----
  	     can provide a may-def variant.  */
  	  if (may_def_ok)
  	    {
! 	      ao_ref_init_from_ptr_and_range (
! 		  write, gimple_call_arg (stmt, 0), true, 0, -1,
! 		  tree_to_poly_int64 (TYPE_SIZE (
! 		    TREE_TYPE (gimple_call_arg (stmt, 3)))));
  	      return true;
  	    }
  	  break;
*************** compute_trims (ao_ref *ref, sbitmap live
*** 409,416 ****
       the bitmap extends through ref->max_size, so we know that in the original
       bitmap bits 0 .. ref->max_size were true.  But we need to check that this
       covers the bytes of REF exactly.  */
!   const unsigned int align = known_alignment (ref->offset);
!   if ((align > 0 && align < BITS_PER_UNIT)
        || !known_eq (ref->size, ref->max_size))
      return;
  
--- 410,419 ----
       the bitmap extends through ref->max_size, so we know that in the original
       bitmap bits 0 .. ref->max_size were true.  But we need to check that this
       covers the bytes of REF exactly.  */
!   const unsigned int offset_align = known_alignment (ref->offset);
!   const unsigned int size_align = known_alignment (ref->size);
!   if ((offset_align > 0 && offset_align < BITS_PER_UNIT)
!       || (size_align > 0 && size_align < BITS_PER_UNIT)
        || !known_eq (ref->size, ref->max_size))
      return;
  
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-loop-im.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-loop-im.cc
*** gcc-13.4.0/gcc/tree-ssa-loop-im.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-loop-im.cc	Fri Sep  4 07:35:11 2026
*************** can_sm_ref_p (class loop *loop, im_mem_r
*** 3180,3186 ****
       explicitly.  */
    base = get_base_address (ref->mem.ref);
    if ((tree_could_trap_p (ref->mem.ref)
!        || (DECL_P (base) && TREE_READONLY (base)))
        /* ???  We can at least use false here, allowing loads?  We
  	 are forcing conditional stores if the ref is not always
  	 stored to later anyway.  So this would only guard
--- 3180,3187 ----
       explicitly.  */
    base = get_base_address (ref->mem.ref);
    if ((tree_could_trap_p (ref->mem.ref)
!        || (DECL_P (base) && TREE_READONLY (base))
!        || TREE_CODE (base) == STRING_CST)
        /* ???  We can at least use false here, allowing loads?  We
  	 are forcing conditional stores if the ref is not always
  	 stored to later anyway.  So this would only guard
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-loop-ivopts.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-loop-ivopts.cc
*** gcc-13.4.0/gcc/tree-ssa-loop-ivopts.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-loop-ivopts.cc	Fri Sep  4 07:35:11 2026
*************** add_candidate_1 (struct ivopts_data *dat
*** 3233,3238 ****
--- 3233,3244 ----
  static bool
  allow_ip_end_pos_p (class loop *loop)
  {
+   /* Do not allow IP_END when creating the IV would need to split the
+      latch edge as that makes all IP_NORMAL invalid.  */
+   auto pos = gsi_last_bb (ip_end_pos (loop));
+   if (!gsi_end_p (pos) && stmt_ends_bb_p (gsi_stmt (pos)))
+     return false;
+ 
    if (!ip_normal_pos (loop))
      return true;
  
*************** create_new_iv (struct ivopts_data *data,
*** 7237,7248 ****
      case IP_END:
        incr_pos = gsi_last_bb (ip_end_pos (data->current_loop));
        after = true;
!       if (!gsi_end_p (incr_pos) && stmt_ends_bb_p (gsi_stmt (incr_pos)))
! 	{
! 	  edge e = find_edge (gsi_bb (incr_pos), data->current_loop->header);
! 	  incr_pos = gsi_after_labels (split_edge (e));
! 	  after = false;
! 	}
        break;
  
      case IP_AFTER_USE:
--- 7243,7249 ----
      case IP_END:
        incr_pos = gsi_last_bb (ip_end_pos (data->current_loop));
        after = true;
!       gcc_assert (gsi_end_p (incr_pos) || !stmt_ends_bb_p (gsi_stmt (incr_pos)));
        break;
  
      case IP_AFTER_USE:
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-loop-niter.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-loop-niter.cc
*** gcc-13.4.0/gcc/tree-ssa-loop-niter.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-loop-niter.cc	Fri Sep  4 07:35:11 2026
*************** number_of_iterations_ne (class loop *loo
*** 996,1003 ****
       if BNDS->below in the result is nonnegative.  */
    if (tree_int_cst_sign_bit (iv->step))
      {
!       s = fold_convert (niter_type,
! 			fold_build1 (NEGATE_EXPR, type, iv->step));
        c = fold_build2 (MINUS_EXPR, niter_type,
  		       fold_convert (niter_type, iv->base),
  		       fold_convert (niter_type, final));
--- 996,1003 ----
       if BNDS->below in the result is nonnegative.  */
    if (tree_int_cst_sign_bit (iv->step))
      {
!       s = fold_build1 (NEGATE_EXPR, niter_type,
! 		       fold_convert (niter_type, iv->step));
        c = fold_build2 (MINUS_EXPR, niter_type,
  		       fold_convert (niter_type, iv->base),
  		       fold_convert (niter_type, final));
*************** number_of_iterations_lt (class loop *loo
*** 1646,1653 ****
    if (integer_nonzerop (iv0->step))
      step = fold_convert (niter_type, iv0->step);
    else
!     step = fold_convert (niter_type,
! 			 fold_build1 (NEGATE_EXPR, type, iv1->step));
  
    /* If we can determine the final value of the control iv exactly, we can
       transform the condition to != comparison.  In particular, this will be
--- 1646,1653 ----
    if (integer_nonzerop (iv0->step))
      step = fold_convert (niter_type, iv0->step);
    else
!     step = fold_build1 (NEGATE_EXPR, niter_type,
! 			fold_convert (niter_type, iv1->step));
  
    /* If we can determine the final value of the control iv exactly, we can
       transform the condition to != comparison.  In particular, this will be
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-loop-split.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-loop-split.cc
*** gcc-13.4.0/gcc/tree-ssa-loop-split.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-loop-split.cc	Fri Sep  4 07:35:11 2026
*************** compute_new_first_bound (gimple_seq *stm
*** 419,439 ****
    tree end = force_gimple_operand (niter->bound, &stmts2,
  					true, NULL_TREE);
    gimple_seq_add_seq_without_update (stmts, stmts2);
!   if (POINTER_TYPE_P (TREE_TYPE (enddiff)))
!     {
!       tree tem = gimple_convert (stmts, sizetype, enddiff);
!       tem = gimple_build (stmts, NEGATE_EXPR, sizetype, tem);
!       enddiff = gimple_build (stmts, POINTER_PLUS_EXPR,
! 			      TREE_TYPE (enddiff),
! 			      end, tem);
!     }
    else
      enddiff = gimple_build (stmts, MINUS_EXPR, TREE_TYPE (enddiff),
  			    end, enddiff);
  
    /* Compute guard_init + (end-beg).  */
    tree newbound;
-   enddiff = gimple_convert (stmts, TREE_TYPE (guard_init), enddiff);
    if (POINTER_TYPE_P (TREE_TYPE (guard_init)))
      {
        enddiff = gimple_convert (stmts, sizetype, enddiff);
--- 419,433 ----
    tree end = force_gimple_operand (niter->bound, &stmts2,
  					true, NULL_TREE);
    gimple_seq_add_seq_without_update (stmts, stmts2);
!   if (POINTER_TYPE_P (TREE_TYPE (controlbase)))
!     enddiff = gimple_build (stmts, POINTER_DIFF_EXPR,
! 			    ssizetype, end, enddiff);
    else
      enddiff = gimple_build (stmts, MINUS_EXPR, TREE_TYPE (enddiff),
  			    end, enddiff);
  
    /* Compute guard_init + (end-beg).  */
    tree newbound;
    if (POINTER_TYPE_P (TREE_TYPE (guard_init)))
      {
        enddiff = gimple_convert (stmts, sizetype, enddiff);
*************** compute_new_first_bound (gimple_seq *stm
*** 442,449 ****
  			       guard_init, enddiff);
      }
    else
!     newbound = gimple_build (stmts, PLUS_EXPR, TREE_TYPE (guard_init),
! 			     guard_init, enddiff);
  
    /* Depending on the direction of the IVs the new bound for the first
       loop is the minimum or maximum of old bound and border.
--- 436,446 ----
  			       guard_init, enddiff);
      }
    else
!     {
!       enddiff = gimple_convert (stmts, TREE_TYPE (guard_init), enddiff);
!       newbound = gimple_build (stmts, PLUS_EXPR, TREE_TYPE (guard_init),
! 			       guard_init, enddiff);
!     }
  
    /* Depending on the direction of the IVs the new bound for the first
       loop is the minimum or maximum of old bound and border.
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-loop-unswitch.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-loop-unswitch.cc
*** gcc-13.4.0/gcc/tree-ssa-loop-unswitch.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-loop-unswitch.cc	Fri Sep  4 07:35:11 2026
*************** hoist_guard (class loop *loop, edge guar
*** 1510,1516 ****
  
    if (skip_count > e->count ())
      {
!       fprintf (dump_file, "  Capping count; expect profile inconsistency\n");
        skip_count = e->count ();
      }
    if (dump_enabled_p ())
--- 1510,1517 ----
  
    if (skip_count > e->count ())
      {
!       if (dump_file && (dump_flags & TDF_DETAILS))
! 	fprintf (dump_file, "  Capping count; expect profile inconsistency\n");
        skip_count = e->count ();
      }
    if (dump_enabled_p ())
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-math-opts.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-math-opts.cc
*** gcc-13.4.0/gcc/tree-ssa-math-opts.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-math-opts.cc	Fri Sep  4 07:35:11 2026
*************** convert_plusminus_to_widen (gimple_stmt_
*** 2974,2979 ****
--- 2974,2984 ----
    if (to_mode == from_mode)
      return false;
  
+   /* For fixed point types, the mode classes could be different
+      so reject that case. */
+   if (GET_MODE_CLASS (from_mode) != GET_MODE_CLASS (to_mode))
+     return false;
+ 
    from_unsigned1 = TYPE_UNSIGNED (type1);
    from_unsigned2 = TYPE_UNSIGNED (type2);
    optype = type1;
*************** maybe_optimize_guarding_check (vecflags
! 	       & ((cmp2 == LT_EXPR || cmp2 == LE_EXPR)
! 		  ? EDGE_TRUE_VALUE : EDGE_FALSE_VALUE)) != 0)
! 	     != ((e1->flags
! 		  & ((cmp1 == LT_EXPR || cmp1 == LE_EXPR)
! 		     ? EDGE_TRUE_VALUE : EDGE_FALSE_VALUE)) != 0)))
  	return false;
        if (!single_pred_p (cond2_bb) || !cond_only_block_p (cond2_bb))
  	return false;
--- 2766,2774 ----
  	 or the comparisons are the same and operands not swapped,
  	 or the true and false edges are swapped, it is not.  */
        if ((lhs2 == lhs1)
! 	  ^ ((cmp2 == LT_EXPR || cmp2 == LE_EXPR)
! 	     != (cmp1 == LT_EXPR || cmp1 == LE_EXPR))
! 	  ^ ((cond2_phi_edge->flags & EDGE_FALSE_VALUE) != 0))
  	return false;
        if (!single_pred_p (cond2_bb) || !cond_only_block_p (cond2_bb))
  	return false;
*************** spaceship_replacement (basic_block cond_
*** 2966,2975 ****
  	    {
  	      if (has_cast_debug_uses)
  		{
! 		  tree temp3 = make_node (DEBUG_EXPR_DECL);
! 		  DECL_ARTIFICIAL (temp3) = 1;
! 		  TREE_TYPE (temp3) = TREE_TYPE (orig_use_lhs);
! 		  SET_DECL_MODE (temp3, TYPE_MODE (type));
  		  t = fold_convert (TREE_TYPE (temp3), temp2);
  		  g = gimple_build_debug_bind (temp3, t, phi);
  		  gsi_insert_before (&gsi, g, GSI_SAME_STMT);
--- 2963,2970 ----
  	    {
  	      if (has_cast_debug_uses)
  		{
! 		  tree temp3
! 		    = build_debug_expr_decl (TREE_TYPE (orig_use_lhs));
  		  t = fold_convert (TREE_TYPE (temp3), temp2);
  		  g = gimple_build_debug_bind (temp3, t, phi);
  		  gsi_insert_before (&gsi, g, GSI_SAME_STMT);
*************** cond_removal_in_builtin_zero_pattern (ba
*** 3149,3164 ****
        || arg != gimple_cond_lhs (cond))
      return false;
  
!   /* Canonicalize.  */
!   if ((e2->flags & EDGE_TRUE_VALUE
!        && gimple_cond_code (cond) == NE_EXPR)
!       || (e1->flags & EDGE_TRUE_VALUE
! 	  && gimple_cond_code (cond) == EQ_EXPR))
      {
        std::swap (arg0, arg1);
-       std::swap (e1, e2);
      }
  
    /* Check PHI arguments.  */
    if (lhs != arg0
        || TREE_CODE (arg1) != INTEGER_CST
--- 3144,3179 ----
        || arg != gimple_cond_lhs (cond))
      return false;
  
!   edge true_edge, false_edge;
!   /* We need to know which is the true edge and which is the false
!      edge so that we know when to invert the condition below.  */
!   extract_true_false_edges_from_block (cond_bb, &true_edge, &false_edge);
! 
!   /* Forward the edges over the middle basic block.  */
!   if (true_edge->dest == middle_bb)
!     true_edge = EDGE_SUCC (true_edge->dest, 0);
!   if (false_edge->dest == middle_bb)
!     false_edge = EDGE_SUCC (false_edge->dest, 0);
! 
!   /* Canonicalize the args with respect to the edges,
!      arg0 is from the true edge and arg1 is from the
!      false edge.
!      That is `cond ? arg0 : arg1`.*/
!   if (true_edge == e1)
!     gcc_assert (false_edge == e2);
!   else
      {
+       gcc_assert (false_edge == e1);
+       gcc_assert (true_edge == e2);
        std::swap (arg0, arg1);
      }
  
+   /* Canonicalize the args such that we get:
+      `arg != 0 ? arg0 : arg1`. So swap arg0/arg1
+      around if cond was an equals.  */
+   if (gimple_cond_code (cond) == EQ_EXPR)
+     std::swap (arg0, arg1);
+ 
    /* Check PHI arguments.  */
    if (lhs != arg0
        || TREE_CODE (arg1) != INTEGER_CST
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-pre.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-pre.cc
*** gcc-13.4.0/gcc/tree-ssa-pre.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-pre.cc	Fri Sep  4 07:35:11 2026
*************** find_or_generate_expression (basic_block
*** 2788,2794 ****
    if (leader)
      {
        if (leader->kind == NAME)
! 	return PRE_EXPR_NAME (leader);
        else if (leader->kind == CONSTANT)
  	return PRE_EXPR_CONSTANT (leader);
  
--- 2788,2799 ----
    if (leader)
      {
        if (leader->kind == NAME)
! 	{
! 	  tree name = PRE_EXPR_NAME (leader);
! 	  if (SSA_NAME_OCCURS_IN_ABNORMAL_PHI (name))
! 	    return NULL_TREE;
! 	  return name;
! 	}
        else if (leader->kind == CONSTANT)
  	return PRE_EXPR_CONSTANT (leader);
  
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-propagate.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-propagate.cc
*** gcc-13.4.0/gcc/tree-ssa-propagate.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-propagate.cc	Fri Sep  4 07:35:11 2026
*************** substitute_and_fold_engine::substitute_a
*** 1006,1011 ****
--- 1006,1013 ----
    while (!walker.stmts_to_fixup.is_empty ())
      {
        gimple *stmt = walker.stmts_to_fixup.pop ();
+       if (!gimple_bb (stmt))
+ 	continue;
        if (dump_file && dump_flags & TDF_DETAILS)
  	{
  	  fprintf (dump_file, "Fixing up noreturn call ");
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-reassoc.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-reassoc.cc
*** gcc-13.4.0/gcc/tree-ssa-reassoc.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-reassoc.cc	Fri Sep  4 07:35:11 2026
*************** build_and_add_sum (tree type, tree op1,
*** 1564,1570 ****
    if ((!op1def || gimple_nop_p (op1def))
        && (!op2def || gimple_nop_p (op2def)))
      {
!       gsi = gsi_after_labels (single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun)));
        if (!gsi_end_p (gsi)
  	  && is_gimple_call (gsi_stmt (gsi))
  	  && (gimple_call_flags (gsi_stmt (gsi)) & ECF_RETURNS_TWICE))
--- 1564,1571 ----
    if ((!op1def || gimple_nop_p (op1def))
        && (!op2def || gimple_nop_p (op2def)))
      {
!       gsi = gsi_start_nondebug_after_labels_bb
! 		(single_succ (ENTRY_BLOCK_PTR_FOR_FN (cfun)));
        if (!gsi_end_p (gsi)
  	  && is_gimple_call (gsi_stmt (gsi))
  	  && (gimple_call_flags (gsi_stmt (gsi)) & ECF_RETURNS_TWICE))
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-sccvn.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-sccvn.cc
*** gcc-13.4.0/gcc/tree-ssa-sccvn.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-sccvn.cc	Fri Sep  4 07:35:11 2026
*************** fully_constant_vn_reference_p (vn_refere
*** 1576,1581 ****
--- 1576,1583 ----
  	      ++i;
  	      break;
  	    }
+ 	  if (operands[i].reverse)
+ 	    return NULL_TREE;
  	  if (known_eq (operands[i].off, -1))
  	    return NULL_TREE;
  	  off += operands[i].off;
*************** vn_reference_lookup_3 (ao_ref *ref, tree
*** 2756,2762 ****
           we find a VN result with exactly the same value as the
  	 possible clobber.  In this case we can ignore the clobber
  	 and return the found value.  */
!       if (is_gimple_reg_type (TREE_TYPE (lhs))
  	  && types_compatible_p (TREE_TYPE (lhs), vr->type)
  	  && (ref->ref || data->orig_ref.ref)
  	  && !data->mask
--- 2758,2765 ----
           we find a VN result with exactly the same value as the
  	 possible clobber.  In this case we can ignore the clobber
  	 and return the found value.  */
!       if (!gimple_has_volatile_ops (def_stmt)
! 	  && is_gimple_reg_type (TREE_TYPE (lhs))
  	  && types_compatible_p (TREE_TYPE (lhs), vr->type)
  	  && (ref->ref || data->orig_ref.ref)
  	  && !data->mask
*************** vn_reference_lookup_3 (ao_ref *ref, tree
*** 3034,3040 ****
    else if (is_gimple_reg_type (vr->type)
  	   && gimple_assign_single_p (def_stmt)
  	   && gimple_assign_rhs_code (def_stmt) == CONSTRUCTOR
! 	   && CONSTRUCTOR_NELTS (gimple_assign_rhs1 (def_stmt)) == 0)
      {
        tree base2;
        poly_int64 offset2, size2, maxsize2;
--- 3037,3044 ----
    else if (is_gimple_reg_type (vr->type)
  	   && gimple_assign_single_p (def_stmt)
  	   && gimple_assign_rhs_code (def_stmt) == CONSTRUCTOR
! 	   && CONSTRUCTOR_NELTS (gimple_assign_rhs1 (def_stmt)) == 0
! 	   && !TREE_THIS_VOLATILE (gimple_assign_lhs (def_stmt)))
      {
        tree base2;
        poly_int64 offset2, size2, maxsize2;
*************** vn_reference_lookup_3 (ao_ref *ref, tree
*** 3090,3095 ****
--- 3094,3100 ----
  	   && !reverse_storage_order_for_component_p (vr->operands)
  	   && !contains_storage_order_barrier_p (vr->operands)
  	   && gimple_assign_single_p (def_stmt)
+ 	   && !TREE_THIS_VOLATILE (gimple_assign_lhs (def_stmt))
  	   && CHAR_BIT == 8
  	   && BITS_PER_UNIT == 8
  	   && BYTES_BIG_ENDIAN == WORDS_BIG_ENDIAN
*************** vn_reference_lookup_3 (ao_ref *ref, tree
*** 3243,3248 ****
--- 3248,3254 ----
  	   && !reverse_storage_order_for_component_p (vr->operands)
  	   && !contains_storage_order_barrier_p (vr->operands)
  	   && gimple_assign_single_p (def_stmt)
+ 	   && !TREE_THIS_VOLATILE (gimple_assign_lhs (def_stmt))
  	   && TREE_CODE (gimple_assign_rhs1 (def_stmt)) == SSA_NAME)
      {
        tree lhs = gimple_assign_lhs (def_stmt);
*************** vn_reference_lookup_3 (ao_ref *ref, tree
*** 3451,3456 ****
--- 3457,3463 ----
       the copy kills ref.  */
    else if (data->vn_walk_kind == VN_WALKREWRITE
  	   && gimple_assign_single_p (def_stmt)
+ 	   && !gimple_has_volatile_ops (def_stmt)
  	   && (DECL_P (gimple_assign_rhs1 (def_stmt))
  	       || TREE_CODE (gimple_assign_rhs1 (def_stmt)) == MEM_REF
  	       || handled_component_p (gimple_assign_rhs1 (def_stmt))))
diff -Nrcpad gcc-13.4.0/gcc/tree-ssa-strlen.cc gcc-13.5.0-RC-20260904/gcc/tree-ssa-strlen.cc
*** gcc-13.4.0/gcc/tree-ssa-strlen.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-ssa-strlen.cc	Fri Sep  4 07:35:11 2026
*************** get_string_length (strinfo *si)
*** 848,854 ****
       attempt to compute the length from the call statement.  */
    if (si->stmt)
      {
!       gimple *stmt = si->stmt, *lenstmt;
        tree callee, lhs, fn, tem;
        location_t loc;
        gimple_stmt_iterator gsi;
--- 848,854 ----
       attempt to compute the length from the call statement.  */
    if (si->stmt)
      {
!       gimple *stmt = si->stmt, *lenstmt = NULL, *g;
        tree callee, lhs, fn, tem;
        location_t loc;
        gimple_stmt_iterator gsi;
*************** get_string_length (strinfo *si)
*** 883,893 ****
                lhs = force_gimple_operand_gsi (&gsi, lhs, true, NULL_TREE,
                                                true, GSI_SAME_STMT);
              }
! 	  lenstmt = gimple_build_assign
  			(make_ssa_name (TREE_TYPE (gimple_call_arg (stmt, 0))),
  			 POINTER_PLUS_EXPR,tem, lhs);
! 	  gsi_insert_before (&gsi, lenstmt, GSI_SAME_STMT);
! 	  gimple_call_set_arg (stmt, 0, gimple_assign_lhs (lenstmt));
  	  lhs = NULL_TREE;
  	  /* FALLTHRU */
  	case BUILT_IN_STRCPY:
--- 883,893 ----
                lhs = force_gimple_operand_gsi (&gsi, lhs, true, NULL_TREE,
                                                true, GSI_SAME_STMT);
              }
! 	  g = gimple_build_assign
  			(make_ssa_name (TREE_TYPE (gimple_call_arg (stmt, 0))),
  			 POINTER_PLUS_EXPR,tem, lhs);
! 	  gsi_insert_before (&gsi, g, GSI_SAME_STMT);
! 	  gimple_call_set_arg (stmt, 0, gimple_assign_lhs (g));
  	  lhs = NULL_TREE;
  	  /* FALLTHRU */
  	case BUILT_IN_STRCPY:
*************** get_string_length (strinfo *si)
*** 906,911 ****
--- 906,922 ----
  	  gimple_call_set_fndecl (stmt, fn);
  	  lhs = make_ssa_name (TREE_TYPE (TREE_TYPE (fn)), stmt);
  	  gimple_call_set_lhs (stmt, lhs);
+ 	  if (DECL_FUNCTION_CODE (callee) == BUILT_IN_STRCAT_CHK)
+ 	    {
+ 	      tree objsz = gimple_call_lhs (lenstmt);
+ 	      gimple *g
+ 		= gimple_build_assign (make_ssa_name (TREE_TYPE (objsz)),
+ 				       MINUS_EXPR, gimple_call_arg (stmt, 2),
+ 				       objsz);
+ 	      gimple_set_location (g, gimple_location (stmt));
+ 	      gsi_insert_before (&gsi, g, GSI_SAME_STMT);
+ 	      gimple_call_set_arg (stmt, 2, gimple_assign_lhs (g));
+ 	    }
  	  update_stmt (stmt);
  	  if (dump_file && (dump_flags & TDF_DETAILS) != 0)
  	    {
*************** strlen_pass::handle_builtin_memcmp ()
*** 4020,4027 ****
  	  tree ptrtype = build_pointer_type_for_mode (char_type_node,
  						      ptr_mode, true);
  	  off = build_int_cst (ptrtype, 0);
! 	  arg1 = build2_loc (loc, MEM_REF, type, arg1, off);
! 	  arg2 = build2_loc (loc, MEM_REF, type, arg2, off);
  	  tree tem1 = fold_const_aggregate_ref (arg1);
  	  if (tem1)
  	    arg1 = tem1;
--- 4031,4046 ----
  	  tree ptrtype = build_pointer_type_for_mode (char_type_node,
  						      ptr_mode, true);
  	  off = build_int_cst (ptrtype, 0);
! 
! 	  /* Create unaligned types if needed. */
! 	  tree type1 = type, type2 = type;
! 	  if (TYPE_ALIGN (type1) > align1)
! 	    type1 = build_aligned_type (type1, align1);
! 	  if (TYPE_ALIGN (type2) > align2)
! 	    type2 = build_aligned_type (type2, align2);
! 
! 	  arg1 = build2_loc (loc, MEM_REF, type1, arg1, off);
! 	  arg2 = build2_loc (loc, MEM_REF, type2, arg2, off);
  	  tree tem1 = fold_const_aggregate_ref (arg1);
  	  if (tem1)
  	    arg1 = tem1;
diff -Nrcpad gcc-13.4.0/gcc/tree-tailcall.cc gcc-13.5.0-RC-20260904/gcc/tree-tailcall.cc
*** gcc-13.4.0/gcc/tree-tailcall.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-tailcall.cc	Fri Sep  4 07:35:11 2026
*************** process_assignment (gassign *stmt,
*** 329,334 ****
--- 329,338 ----
      if (FLOAT_TYPE_P (TREE_TYPE (DECL_RESULT (current_function_decl))))
        return FAIL;
  
+   /* We at least cannot build -1 for all fixed point types.  */
+   if (FIXED_POINT_TYPE_P (TREE_TYPE (DECL_RESULT (current_function_decl))))
+     return FAIL;
+ 
    if (rhs_class == GIMPLE_UNARY_RHS
        && op0 == *ass_var)
      ;
diff -Nrcpad gcc-13.4.0/gcc/tree-vect-data-refs.cc gcc-13.5.0-RC-20260904/gcc/tree-vect-data-refs.cc
*** gcc-13.4.0/gcc/tree-vect-data-refs.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-vect-data-refs.cc	Fri Sep  4 07:35:11 2026
*************** vect_can_force_dr_alignment_p (const_tre
*** 6726,6732 ****
      return false;
  
    if (decl_in_symtab_p (decl)
!       && !symtab_node::get (decl)->can_increase_alignment_p ())
      return false;
  
    if (TREE_STATIC (decl))
--- 6726,6733 ----
      return false;
  
    if (decl_in_symtab_p (decl)
!       && (!symtab_node::get (decl)
! 	  || !symtab_node::get (decl)->can_increase_alignment_p ()))
      return false;
  
    if (TREE_STATIC (decl))
diff -Nrcpad gcc-13.4.0/gcc/tree-vect-loop.cc gcc-13.5.0-RC-20260904/gcc/tree-vect-loop.cc
*** gcc-13.4.0/gcc/tree-vect-loop.cc	Thu Jun  5 16:03:01 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-vect-loop.cc	Fri Sep  4 07:35:11 2026
*************** vectorizable_recurr (loop_vec_info loop_
*** 8444,8449 ****
--- 8444,8479 ----
        return false;
      }
  
+   /* We need to be able to build a { ..., a, b } init vector with
+      dist number of distinct trailing values.  Always possible
+      when dist == 1 or when nunits is constant or when the initializations
+      are uniform.  */
+   tree uniform_initval = NULL_TREE;
+   edge pe = loop_preheader_edge (LOOP_VINFO_LOOP (loop_vinfo));
+   if (slp_node)
+     for (stmt_vec_info s : SLP_TREE_SCALAR_STMTS (slp_node))
+       {
+ 	gphi *phi = as_a  (s->stmt);
+ 	if (! uniform_initval)
+ 	  uniform_initval = PHI_ARG_DEF_FROM_EDGE (phi, pe);
+ 	else if (! operand_equal_p (uniform_initval,
+ 				    PHI_ARG_DEF_FROM_EDGE (phi, pe)))
+ 	  {
+ 	    uniform_initval = NULL_TREE;
+ 	    break;
+ 	  }
+       }
+   else
+     uniform_initval = PHI_ARG_DEF_FROM_EDGE (phi, pe);
+   if (!uniform_initval && !nunits.is_constant ())
+     {
+       if (dump_enabled_p ())
+ 	dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+ 			 "cannot build initialization vector for "
+ 			 "first order recurrence\n");
+       return false;
+     }
+ 
    /* First-order recurrence autovectorization needs to handle permutation
       with indices = [nunits-1, nunits, nunits+1, ...].  */
    vec_perm_builder sel (nunits, 1, 3);
*************** vectorizable_recurr (loop_vec_info loop_
*** 8490,8510 ****
        return true;
      }
  
!   edge pe = loop_preheader_edge (LOOP_VINFO_LOOP (loop_vinfo));
!   basic_block bb = gimple_bb (phi);
!   tree preheader = PHI_ARG_DEF_FROM_EDGE (phi, pe);
!   if (!useless_type_conversion_p (TREE_TYPE (vectype), TREE_TYPE (preheader)))
      {
!       gimple_seq stmts = NULL;
!       preheader = gimple_convert (&stmts, TREE_TYPE (vectype), preheader);
!       gsi_insert_seq_on_edge_immediate (pe, stmts);
      }
!   tree vec_init = build_vector_from_val (vectype, preheader);
    vec_init = vect_init_vector (loop_vinfo, stmt_info, vec_init, vectype, NULL);
  
    /* Create the vectorized first-order PHI node.  */
    tree vec_dest = vect_get_new_vect_var (vectype,
  					 vect_simple_var, "vec_recur_");
    gphi *new_phi = create_phi_node (vec_dest, bb);
    add_phi_arg (new_phi, vec_init, pe, UNKNOWN_LOCATION);
  
--- 8520,8557 ----
        return true;
      }
  
!   tree vec_init;
!   if (! uniform_initval)
      {
!       vec *v = NULL;
!       vec_alloc (v, nunits.to_constant ());
!       for (unsigned i = 0; i < nunits.to_constant () - dist; ++i)
! 	CONSTRUCTOR_APPEND_ELT (v, NULL_TREE,
! 				build_zero_cst (TREE_TYPE (vectype)));
!       for (stmt_vec_info s : SLP_TREE_SCALAR_STMTS (slp_node))
! 	{
! 	  gphi *phi = as_a  (s->stmt);
! 	  tree preheader = PHI_ARG_DEF_FROM_EDGE (phi, pe);
! 	  if (!useless_type_conversion_p (TREE_TYPE (vectype),
! 					  TREE_TYPE (preheader)))
! 	    {
! 	      gimple_seq stmts = NULL;
! 	      preheader = gimple_convert (&stmts,
! 					  TREE_TYPE (vectype), preheader);
! 	      gsi_insert_seq_on_edge_immediate (pe, stmts);
! 	    }
! 	  CONSTRUCTOR_APPEND_ELT (v, NULL_TREE, preheader);
! 	}
!       vec_init = build_constructor (vectype, v);
      }
!   else
!     vec_init = uniform_initval;
    vec_init = vect_init_vector (loop_vinfo, stmt_info, vec_init, vectype, NULL);
  
    /* Create the vectorized first-order PHI node.  */
    tree vec_dest = vect_get_new_vect_var (vectype,
  					 vect_simple_var, "vec_recur_");
+   basic_block bb = gimple_bb (phi);
    gphi *new_phi = create_phi_node (vec_dest, bb);
    add_phi_arg (new_phi, vec_init, pe, UNKNOWN_LOCATION);
  
diff -Nrcpad gcc-13.4.0/gcc/tree-vect-slp.cc gcc-13.5.0-RC-20260904/gcc/tree-vect-slp.cc
*** gcc-13.4.0/gcc/tree-vect-slp.cc	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-vect-slp.cc	Fri Sep  4 07:35:11 2026
*************** vect_get_and_check_slp_defs (vec_info *v
*** 594,602 ****
  	{
  	  oprnd = gimple_arg (stmt_info->stmt, opno);
  	  if (gphi *stmt = dyn_cast  (stmt_info->stmt))
! 	    backedge = dominated_by_p (CDI_DOMINATORS,
! 				       gimple_phi_arg_edge (stmt, opno)->src,
! 				       gimple_bb (stmt_info->stmt));
  	}
        if (TREE_CODE (oprnd) == VIEW_CONVERT_EXPR)
  	oprnd = TREE_OPERAND (oprnd, 0);
--- 594,606 ----
  	{
  	  oprnd = gimple_arg (stmt_info->stmt, opno);
  	  if (gphi *stmt = dyn_cast  (stmt_info->stmt))
! 	    {
! 	      edge e = gimple_phi_arg_edge (stmt, opno);
! 	      backedge = (is_a  (vinfo)
! 			  ? e->flags & EDGE_DFS_BACK
! 			  : dominated_by_p (CDI_DOMINATORS, e->src,
! 					    gimple_bb (stmt_info->stmt)));
! 	    }
  	}
        if (TREE_CODE (oprnd) == VIEW_CONVERT_EXPR)
  	oprnd = TREE_OPERAND (oprnd, 0);
*************** vect_slp_function (function *fun)
*** 7678,7683 ****
--- 7682,7688 ----
    bool r = false;
    int *rpo = XNEWVEC (int, n_basic_blocks_for_fn (fun));
    unsigned n = pre_and_rev_post_order_compute_fn (fun, NULL, rpo, false);
+   mark_dfs_back_edges (fun);
  
    /* For the moment split the function into pieces to avoid making
       the iteration on the vector mode moot.  Split at points we know
diff -Nrcpad gcc-13.4.0/gcc/tree-vect-stmts.cc gcc-13.5.0-RC-20260904/gcc/tree-vect-stmts.cc
*** gcc-13.4.0/gcc/tree-vect-stmts.cc	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/gcc/tree-vect-stmts.cc	Fri Sep  4 07:35:11 2026
*************** vectorizable_operation (vec_info *vinfo,
*** 6170,6176 ****
    poly_uint64 nunits_in;
    poly_uint64 nunits_out;
    tree vectype_out;
!   int ncopies, vec_num;
    int i;
    vec vec_oprnds0 = vNULL;
    vec vec_oprnds1 = vNULL;
--- 6170,6177 ----
    poly_uint64 nunits_in;
    poly_uint64 nunits_out;
    tree vectype_out;
!   unsigned int ncopies;
!   unsigned vec_num;
    int i;
    vec vec_oprnds0 = vNULL;
    vec vec_oprnds1 = vNULL;
*************** vectorizable_operation (vec_info *vinfo,
*** 6626,6633 ****
  	      && code == BIT_AND_EXPR
  	      && VECTOR_BOOLEAN_TYPE_P (vectype))
  	    {
! 	      if (loop_vinfo->scalar_cond_masked_set.contains ({ op0,
! 								 ncopies}))
  		{
  		  mask = vect_get_loop_mask (gsi, masks, vec_num * ncopies,
  					     vectype, i);
--- 6627,6634 ----
  	      && code == BIT_AND_EXPR
  	      && VECTOR_BOOLEAN_TYPE_P (vectype))
  	    {
! 	      if (loop_vinfo->scalar_cond_masked_set.contains
! 						   ({ op0, vec_num * ncopies}))
  		{
  		  mask = vect_get_loop_mask (gsi, masks, vec_num * ncopies,
  					     vectype, i);
*************** vectorizable_operation (vec_info *vinfo,
*** 6636,6643 ****
  					   vop0, gsi);
  		}
  
! 	      if (loop_vinfo->scalar_cond_masked_set.contains ({ op1,
! 								 ncopies }))
  		{
  		  mask = vect_get_loop_mask (gsi, masks, vec_num * ncopies,
  					     vectype, i);
--- 6637,6644 ----
  					   vop0, gsi);
  		}
  
! 	      if (loop_vinfo->scalar_cond_masked_set.contains
! 						  ({ op1, vec_num * ncopies }))
  		{
  		  mask = vect_get_loop_mask (gsi, masks, vec_num * ncopies,
  					     vectype, i);
diff -Nrcpad gcc-13.4.0/gcc/tree.cc gcc-13.5.0-RC-20260904/gcc/tree.cc
*** gcc-13.4.0/gcc/tree.cc	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/gcc/tree.cc	Fri Sep  4 07:35:11 2026
*************** simple_cst_equal (const_tree t1, const_t
*** 6564,6576 ****
  	vec *v2 = CONSTRUCTOR_ELTS (t2);
  
  	if (vec_safe_length (v1) != vec_safe_length (v2))
! 	  return false;
  
          for (idx = 0; idx < vec_safe_length (v1); ++idx)
! 	  /* ??? Should we handle also fields here? */
! 	  if (!simple_cst_equal ((*v1)[idx].value, (*v2)[idx].value))
! 	    return false;
! 	return true;
        }
  
      case SAVE_EXPR:
--- 6564,6590 ----
  	vec *v2 = CONSTRUCTOR_ELTS (t2);
  
  	if (vec_safe_length (v1) != vec_safe_length (v2))
! 	  return 0;
  
          for (idx = 0; idx < vec_safe_length (v1); ++idx)
! 	  {
! 	    if ((*v1)[idx].index
! 		&& TREE_CODE ((*v1)[idx].index) == FIELD_DECL)
! 	      {
! 		if ((*v1)[idx].index != (*v2)[idx].index)
! 		  return 0;
! 	      }
! 	    else
! 	      {
! 		cmp = simple_cst_equal ((*v1)[idx].index, (*v2)[idx].index);
! 		if (cmp <= 0)
! 		  return cmp;
! 	      }
! 	    cmp = simple_cst_equal ((*v1)[idx].value, (*v2)[idx].value);
! 	    if (cmp <= 0)
! 	      return cmp;
! 	  }
! 	return 1;
        }
  
      case SAVE_EXPR:
*************** verify_type (const_tree t)
*** 14017,14026 ****
      }
    if (TYPE_MAIN_VARIANT (t) == t && ct && TYPE_MAIN_VARIANT (ct) != ct)
     {
!       error ("% of main variant is not main variant");
!       debug_tree (ct);
!       debug_tree (TYPE_MAIN_VARIANT (ct));
!       error_found = true;
     }
  
  
--- 14031,14055 ----
      }
    if (TYPE_MAIN_VARIANT (t) == t && ct && TYPE_MAIN_VARIANT (ct) != ct)
     {
!      /* This can happen when build_type_attribute_variant is called on
! 	C/C++ arrays of qualified types.  volatile int[2] is unqualified
! 	ARRAY_TYPE with volatile int element type.
! 	TYPE_CANONICAL (volatile int) is itself and so is
! 	TYPE_CANONICAL (volatile int[2]).  build_type_attribute_qual_variant
! 	creates a distinct type copy (so TYPE_MAIN_VARIANT is itself) and sets
! 	its TYPE_CANONICAL to the unqualified ARRAY_TYPE (so volatile int[2]).
! 	But this is not the TYPE_MAIN_VARIANT, which is int[2].  So, just
! 	verify that TYPE_MAIN_VARIANT (ct) is already the final type we
! 	need.  */
!       tree mvc = TYPE_MAIN_VARIANT (ct);
!       if (TYPE_CANONICAL (mvc) != mvc)
! 	{
! 	  error ("main variant of % of main variant is not"
! 		 " its own %");
! 	  debug_tree (ct);
! 	  debug_tree (TYPE_MAIN_VARIANT (ct));
! 	  error_found = true;
! 	}
     }
  
  
*************** valid_new_delete_pair_p (tree new_asm, t
*** 14868,14873 ****
--- 14897,14909 ----
    if ((new_name[2] != 'w' || delete_name[2] != 'l')
        && (new_name[2] != 'a' || delete_name[2] != 'a'))
      return false;
+   if (new_name[3] == 'I' || delete_name[3] == 'I')
+     {
+       /* When ::operator new or ::operator delete are function templates,
+ 	 return uncertain mismatch, we need demangler in that case.  */
+       *pcertain = false;
+       return false;
+     }
    /* 'j', 'm' and 'y' correspond to size_t.  */
    if (new_name[3] != 'j' && new_name[3] != 'm' && new_name[3] != 'y')
      return false;
diff -Nrcpad gcc-13.4.0/gcc/var-tracking.cc gcc-13.5.0-RC-20260904/gcc/var-tracking.cc
*** gcc-13.4.0/gcc/var-tracking.cc	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/gcc/var-tracking.cc	Fri Sep  4 07:35:11 2026
*************** val_store (dataflow_set *set, rtx val, r
*** 2529,2535 ****
  	  struct elt_loc_list *l;
  	  for (l = v->locs; l; l = l->next)
  	    {
! 	      fprintf (dump_file, "\n%i: ", INSN_UID (l->setting_insn));
  	      print_inline_rtx (dump_file, l->loc, 0);
  	    }
  	}
--- 2529,2536 ----
  	  struct elt_loc_list *l;
  	  for (l = v->locs; l; l = l->next)
  	    {
! 	      fprintf (dump_file, "\n%i: ",
! 		       l->setting_insn ? INSN_UID (l->setting_insn) : -1);
  	      print_inline_rtx (dump_file, l->loc, 0);
  	    }
  	}
diff -Nrcpad gcc-13.4.0/libcody/ChangeLog gcc-13.5.0-RC-20260904/libcody/ChangeLog
*** gcc-13.4.0/libcody/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/libcody/ChangeLog	Fri Sep  4 07:35:11 2026
***************
*** 1,3 ****
--- 1,20 ----
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-11-21  Jakub Jelinek  
+ 
+ 	* cody.hh (S2C): For __cpp_char8_t >= 201811 use char8_t instead of
+ 	char in argument type.
+ 	(MessageBuffer::Space): Revert 2025-11-15 change.
+ 	(MessageBuffer::Append): For __cpp_char8_t >= 201811 add overload
+ 	with char8_t const * type of first argument.
+ 	(Packet::Packet): Similarly for first argument.
+ 	* client.cc (CommunicationError, Client::ProcessResponse,
+ 	Client::Connect, ConnectResponse, PathnameResponse, OKResponse,
+ 	IncludeTranslateResponse): Cast u8 string literals to (const char *)
+ 	where needed.
+ 	* server.cc (Server::ProcessRequests, ConnectRequest): Likewise.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/libcody/client.cc gcc-13.5.0-RC-20260904/libcody/client.cc
*** gcc-13.4.0/libcody/client.cc	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libcody/client.cc	Fri Sep  4 07:35:11 2026
*************** int Client::CommunicateWithServer ()
*** 97,103 ****
  
  static Packet CommunicationError (int err)
  {
!   std::string e {u8"communication error:"};
    e.append (strerror (err));
  
    return Packet (Client::PC_ERROR, std::move (e));
--- 97,103 ----
  
  static Packet CommunicationError (int err)
  {
!   std::string e {(const char *) u8"communication error:"};
    e.append (strerror (err));
  
    return Packet (Client::PC_ERROR, std::move (e));
*************** Packet Client::ProcessResponse (std::vec
*** 110,142 ****
      {
        if (e == EINVAL)
  	{
! 	  std::string msg (u8"malformed string '");
  	  msg.append (words[0]);
! 	  msg.append (u8"'");
  	  return Packet (Client::PC_ERROR, std::move (msg));
  	}
        else
! 	return Packet (Client::PC_ERROR, u8"missing response");
      }
  
    Assert (!words.empty ());
!   if (words[0] == u8"ERROR")
      return Packet (Client::PC_ERROR,
! 		   words.size () == 2 ? words[1]: u8"malformed error response");
  
    if (isLast && !read.IsAtEnd ())
      return Packet (Client::PC_ERROR,
! 		   std::string (u8"unexpected extra response"));
  
    Assert (code < Detail::RC_HWM);
    Packet result (responseTable[code] (words));
    result.SetRequest (code);
    if (result.GetCode () == Client::PC_ERROR && result.GetString ().empty ())
      {
!       std::string msg {u8"malformed response '"};
  
        read.LexedLine (msg);
!       msg.append (u8"'");
        result.GetString () = std::move (msg);
      }
    else if (result.GetCode () == Client::PC_CONNECT)
--- 110,143 ----
      {
        if (e == EINVAL)
  	{
! 	  std::string msg ((const char *) u8"malformed string '");
  	  msg.append (words[0]);
! 	  msg.append ((const char *) u8"'");
  	  return Packet (Client::PC_ERROR, std::move (msg));
  	}
        else
! 	return Packet (Client::PC_ERROR, (const char *) u8"missing response");
      }
  
    Assert (!words.empty ());
!   if (words[0] == (const char *) u8"ERROR")
      return Packet (Client::PC_ERROR,
! 		   words.size () == 2 ? words[1]
! 		   : (const char *) u8"malformed error response");
  
    if (isLast && !read.IsAtEnd ())
      return Packet (Client::PC_ERROR,
! 		   std::string ((const char *) u8"unexpected extra response"));
  
    Assert (code < Detail::RC_HWM);
    Packet result (responseTable[code] (words));
    result.SetRequest (code);
    if (result.GetCode () == Client::PC_ERROR && result.GetString ().empty ())
      {
!       std::string msg {(const char *) u8"malformed response '"};
  
        read.LexedLine (msg);
!       msg.append ((const char *) u8"'");
        result.GetString () = std::move (msg);
      }
    else if (result.GetCode () == Client::PC_CONNECT)
*************** Packet Client::Connect (char const *agen
*** 199,205 ****
  			  size_t alen, size_t ilen)
  {
    write.BeginLine ();
!   write.AppendWord (u8"HELLO");
    write.AppendInteger (Version);
    write.AppendWord (agent, true, alen);
    write.AppendWord (ident, true, ilen);
--- 200,206 ----
  			  size_t alen, size_t ilen)
  {
    write.BeginLine ();
!   write.AppendWord ((const char *) u8"HELLO");
    write.AppendInteger (Version);
    write.AppendWord (agent, true, alen);
    write.AppendWord (ident, true, ilen);
*************** Packet Client::Connect (char const *agen
*** 211,217 ****
  // HELLO $version $agent [$flags]
  Packet ConnectResponse (std::vector &words)
  {
!   if (words[0] == u8"HELLO" && (words.size () == 3 || words.size () == 4))
      {
        char *eptr;
        unsigned long val = strtoul (words[1].c_str (), &eptr, 10);
--- 212,219 ----
  // HELLO $version $agent [$flags]
  Packet ConnectResponse (std::vector &words)
  {
!   if (words[0] == (const char *) u8"HELLO"
!       && (words.size () == 3 || words.size () == 4))
      {
        char *eptr;
        unsigned long val = strtoul (words[1].c_str (), &eptr, 10);
*************** Packet Client::ModuleRepo ()
*** 247,253 ****
  // PATHNAME $dir | ERROR
  Packet PathnameResponse (std::vector &words)
  {
!   if (words[0] == u8"PATHNAME" && words.size () == 2)
      return Packet (Client::PC_PATHNAME, std::move (words[1]));
  
    return Packet (Client::PC_ERROR, u8"");
--- 249,255 ----
  // PATHNAME $dir | ERROR
  Packet PathnameResponse (std::vector &words)
  {
!   if (words[0] == (const char *) u8"PATHNAME" && words.size () == 2)
      return Packet (Client::PC_PATHNAME, std::move (words[1]));
  
    return Packet (Client::PC_ERROR, u8"");
*************** Packet PathnameResponse (std::vector &words)
  {
!   if (words[0] == u8"OK")
      return Packet (Client::PC_OK);
    else
      return Packet (Client::PC_ERROR,
--- 258,264 ----
  // OK or ERROR
  Packet OKResponse (std::vector &words)
  {
!   if (words[0] == (const char *) u8"OK")
      return Packet (Client::PC_OK);
    else
      return Packet (Client::PC_ERROR,
*************** Packet Client::IncludeTranslate (char co
*** 319,329 ****
  // PATHNAME $cmifile
  Packet IncludeTranslateResponse (std::vector &words)
  {
!   if (words[0] == u8"BOOL" && words.size () == 2)
      {
!       if (words[1] == u8"FALSE")
! 	return Packet (Client::PC_BOOL, 0);
!       else if (words[1] == u8"TRUE")
  	return Packet (Client::PC_BOOL, 1);
        else
  	return Packet (Client::PC_ERROR, u8"");
--- 321,331 ----
  // PATHNAME $cmifile
  Packet IncludeTranslateResponse (std::vector &words)
  {
!   if (words[0] == (const char *) u8"BOOL" && words.size () == 2)
      {
!       if (words[1] == (const char *) u8"FALSE")
! 	return Packet (Client::PC_BOOL);
!       else if (words[1] == (const char *) u8"TRUE")
  	return Packet (Client::PC_BOOL, 1);
        else
  	return Packet (Client::PC_ERROR, u8"");
diff -Nrcpad gcc-13.4.0/libcody/cody.hh gcc-13.5.0-RC-20260904/libcody/cody.hh
*** gcc-13.4.0/libcody/cody.hh	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libcody/cody.hh	Fri Sep  4 07:35:11 2026
*************** namespace Detail  {
*** 47,58 ****
--- 47,67 ----
  
  // C++11 doesn't have utf8 character literals :(
  
+ #if __cpp_char8_t >= 201811
+ template
+ constexpr char S2C (char8_t const (&s)[I])
+ {
+   static_assert (I == 2, "only single octet strings may be converted");
+   return s[0];
+ }
+ #else
  template
  constexpr char S2C (char const (&s)[I])
  {
    static_assert (I == 2, "only single octet strings may be converted");
    return s[0];
  }
+ #endif
  
  /// Internal buffering class.  Used to concatenate outgoing messages
  /// and Lex incoming ones.
*************** public:
*** 123,128 ****
--- 132,144 ----
        Space ();
      Append (str, maybe_quote, len);
    }
+ #if __cpp_char8_t >= 201811
+   void AppendWord (char8_t const *str, bool maybe_quote = false,
+ 		   size_t len = ~size_t (0))
+   {
+     AppendWord ((const char *) str, maybe_quote, len);
+   }
+ #endif
    /// Add a word as with AppendWord
    /// @param str the string to append
    /// @param maybe_quote string might need quoting, as for Append
*************** public:
*** 264,269 ****
--- 280,291 ----
      : string (s), cat (STRING), code (c)
    {
    }
+ #if __cpp_char8_t >= 201811
+   Packet (unsigned c, const char8_t *s)
+     : string ((const char *) s), cat (STRING), code (c)
+   {
+   }
+ #endif
    Packet (unsigned c, std::vector &&v)
      : vector (std::move (v)), cat (VECTOR), code (c)
    {
diff -Nrcpad gcc-13.4.0/libcody/server.cc gcc-13.5.0-RC-20260904/libcody/server.cc
*** gcc-13.4.0/libcody/server.cc	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libcody/server.cc	Fri Sep  4 07:35:11 2026
*************** static RequestPair
*** 36,47 ****
    const requestTable[Detail::RC_HWM] =
    {
      // Same order as enum RequestCode
!     RequestPair {u8"HELLO", nullptr},
!     RequestPair {u8"MODULE-REPO", ModuleRepoRequest},
!     RequestPair {u8"MODULE-EXPORT", ModuleExportRequest},
!     RequestPair {u8"MODULE-IMPORT", ModuleImportRequest},
!     RequestPair {u8"MODULE-COMPILED", ModuleCompiledRequest},
!     RequestPair {u8"INCLUDE-TRANSLATE", IncludeTranslateRequest},
    };
  }
  
--- 36,47 ----
    const requestTable[Detail::RC_HWM] =
    {
      // Same order as enum RequestCode
!     RequestPair {(const char *) u8"HELLO", nullptr},
!     RequestPair {(const char *) u8"MODULE-REPO", ModuleRepoRequest},
!     RequestPair {(const char *) u8"MODULE-EXPORT", ModuleExportRequest},
!     RequestPair {(const char *) u8"MODULE-IMPORT", ModuleImportRequest},
!     RequestPair {(const char *) u8"MODULE-COMPILED", ModuleCompiledRequest},
!     RequestPair {(const char *) u8"INCLUDE-TRANSLATE", IncludeTranslateRequest},
    };
  }
  
*************** void Server::ProcessRequests (void)
*** 135,155 ****
  	  std::string msg;
  
  	  if (err > 0)
! 	    msg = u8"error processing '";
  	  else if (ix >= Detail::RC_HWM)
! 	    msg = u8"unrecognized '";
  	  else if (IsConnected () && ix == Detail::RC_CONNECT)
! 	    msg = u8"already connected '";
  	  else if (!IsConnected () && ix != Detail::RC_CONNECT)
! 	    msg = u8"not connected '";
  	  else
! 	    msg = u8"malformed '";
  
  	  read.LexedLine (msg);
! 	  msg.append (u8"'");
  	  if (err > 0)
  	    {
! 	      msg.append (u8" ");
  	      msg.append (strerror (err));
  	    }
  	  resolver->ErrorResponse (this, std::move (msg));
--- 135,155 ----
  	  std::string msg;
  
  	  if (err > 0)
! 	    msg = (const char *) u8"error processing '";
  	  else if (ix >= Detail::RC_HWM)
! 	    msg = (const char *) u8"unrecognized '";
  	  else if (IsConnected () && ix == Detail::RC_CONNECT)
! 	    msg = (const char *) u8"already connected '";
  	  else if (!IsConnected () && ix != Detail::RC_CONNECT)
! 	    msg = (const char *) u8"not connected '";
  	  else
! 	    msg = (const char *) u8"malformed '";
  
  	  read.LexedLine (msg);
! 	  msg.append ((const char *) u8"'");
  	  if (err > 0)
  	    {
! 	      msg.append ((const char *) u8" ");
  	      msg.append (strerror (err));
  	    }
  	  resolver->ErrorResponse (this, std::move (msg));
*************** Resolver *ConnectRequest (Server *s, Res
*** 176,182 ****
      return nullptr;
  
    if (words.size () == 3)
!     words.emplace_back (u8"");
    unsigned version = ParseUnsigned (words[1]);
    if (version == ~0u)
      return nullptr;
--- 176,182 ----
      return nullptr;
  
    if (words.size () == 3)
!     words.emplace_back ((const char *) u8"");
    unsigned version = ParseUnsigned (words[1]);
    if (version == ~0u)
      return nullptr;
diff -Nrcpad gcc-13.4.0/libcpp/ChangeLog gcc-13.5.0-RC-20260904/libcpp/ChangeLog
*** gcc-13.4.0/libcpp/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/libcpp/ChangeLog	Fri Sep  4 07:35:11 2026
***************
*** 1,3 ****
--- 1,40 ----
+ 2026-08-27  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-08-06  Jakub Jelinek  
+ 
+ 	PR preprocessor/125048
+ 	* macro.cc (replace_args): Remember the position of map
+ 	in the pfile->line_table->info_macro.maps array and if vostate
+ 	is DROP, recompute map pointer as expand_arg call could have
+ 	reallocated the pfile->line_table->info_macro.maps array.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-13  Jakub Jelinek  
+ 
+ 	PR preprocessor/105412
+ 	* files.cc (_cpp_stack_file): Call deps_add_dep even on
+ 	empty file path.
+ 	* mkdeps.cc (class mkdeps): Add first_phony_dep member.
+ 	(mkdeps::mkdeps ()): Initialize it to 1.
+ 	(deps_add_dep): When called first with "" argument, decrease
+ 	d->first_phony_dep to 0.
+ 	(make_write): For -MP iterate from d->first_phony_dep
+ 	rather than 1.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-01-30  Jakub Jelinek  
+ 
+ 	PR preprocessor/123273
+ 	* lex.cc (cpp_directive_only_process): Only go to done_comment
+ 	for '/' if star is true and esc is false.  When seeing '\\' with
+ 	esc set to true, clear esc as well as star instead of keeping esc
+ 	set.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/libcpp/files.cc gcc-13.5.0-RC-20260904/libcpp/files.cc
*** gcc-13.4.0/libcpp/files.cc	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libcpp/files.cc	Fri Sep  4 07:35:11 2026
*************** _cpp_stack_file (cpp_reader *pfile, _cpp
*** 956,962 ****
        /* Add the file to the dependencies on its first inclusion.  */
        if (CPP_OPTION (pfile, deps.style) > (sysp != 0)
  	  && !file->stack_count
- 	  && file->path[0]
  	  && !(pfile->main_file == file
  	       && CPP_OPTION (pfile, deps.ignore_main_file)))
  	deps_add_dep (pfile->deps, file->path);
--- 956,961 ----
diff -Nrcpad gcc-13.4.0/libcpp/lex.cc gcc-13.5.0-RC-20260904/libcpp/lex.cc
*** gcc-13.4.0/libcpp/lex.cc	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libcpp/lex.cc	Fri Sep  4 07:35:11 2026
*************** cpp_directive_only_process (cpp_reader *
*** 5312,5318 ****
  		    switch (c)
  		      {
  		      case '\\':
! 			esc = true;
  			break;
  
  		      case '\r':
--- 5312,5324 ----
  		    switch (c)
  		      {
  		      case '\\':
! 			if (esc)
! 			  {
! 			    star = false;
! 			    esc = false;
! 			  }
! 			else
! 			  esc = true;
  			break;
  
  		      case '\r':
*************** cpp_directive_only_process (cpp_reader *
*** 5343,5349 ****
  			break;
  
  		      case '/':
! 			if (star)
  			  goto done_comment;
  			/* FALLTHROUGH  */
  
--- 5349,5355 ----
  			break;
  
  		      case '/':
! 			if (star && !esc)
  			  goto done_comment;
  			/* FALLTHROUGH  */
  
diff -Nrcpad gcc-13.4.0/libcpp/macro.cc gcc-13.5.0-RC-20260904/libcpp/macro.cc
*** gcc-13.4.0/libcpp/macro.cc	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libcpp/macro.cc	Fri Sep  4 07:35:11 2026
*************** replace_args (cpp_reader *pfile, cpp_has
*** 1898,1903 ****
--- 1898,1904 ----
    location_t *virt_locs = NULL;
    unsigned int exp_count;
    const line_map_macro *map = NULL;
+   size_t map_idx = 0;
    int track_macro_exp;
  
    /* First, fully macro-expand arguments, calculating the number of
*************** replace_args (cpp_reader *pfile, cpp_has
*** 2008,2013 ****
--- 2009,2015 ----
        map = linemap_enter_macro (pfile->line_table, node,
  				 expansion_point_loc,
  				 num_macro_tokens);
+       map_idx = map - pfile->line_table->info_macro.maps;
      }
    i = 0;
    vaopt_state vaopt_tracker (pfile, macro->variadic, &args[macro->paramc - 1]);
*************** replace_args (cpp_reader *pfile, cpp_has
*** 2129,2134 ****
--- 2131,2141 ----
  					 NULL, 0);
  		}
  	    }
+ 	  else if (vostate == vaopt_state::DROP && map)
+ 	    /* For the DROP case vaopt_tracker.update (src) can call
+ 	       expand_arg and that can reallocate the maps, so need to
+ 	       update the map pointer.  */
+ 	    map = pfile->line_table->info_macro.maps + map_idx;
  	  continue;
  	}
  
diff -Nrcpad gcc-13.4.0/libcpp/mkdeps.cc gcc-13.5.0-RC-20260904/libcpp/mkdeps.cc
*** gcc-13.4.0/libcpp/mkdeps.cc	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libcpp/mkdeps.cc	Fri Sep  4 07:35:11 2026
*************** public:
*** 81,87 ****
    };
  
    mkdeps ()
!     : module_name (NULL), cmi_name (NULL), is_header_unit (false), quote_lwm (0)
    {
    }
    ~mkdeps ()
--- 81,88 ----
    };
  
    mkdeps ()
!     : module_name (NULL), cmi_name (NULL), is_header_unit (false),
!       quote_lwm (0), first_phony_dep (1)
    {
    }
    ~mkdeps ()
*************** public:
*** 111,116 ****
--- 112,118 ----
    const char *cmi_name;
    bool is_header_unit;
    unsigned short quote_lwm;
+   unsigned int first_phony_dep;
  };
  
  /* Apply Make quoting to STR, TRAIL.  Note that it's not possible to
*************** deps_add_default_target (class mkdeps *d
*** 291,301 ****
  void
  deps_add_dep (class mkdeps *d, const char *t)
  {
!   gcc_assert (*t);
! 
!   t = apply_vpath (d, t);
  
!   d->deps.push (xstrdup (t));
  }
  
  void
--- 293,309 ----
  void
  deps_add_dep (class mkdeps *d, const char *t)
  {
!   if (*t)
!     {
!       t = apply_vpath (d, t);
  
!       d->deps.push (xstrdup (t));
!     }
!   /* When called first with "", remember we should
!      emit for -MP all dependencies rather than just
!      second and following dependency.  See PR105412.  */
!   else if (d->deps.size () == 0)
!     d->first_phony_dep = 0;
  }
  
  void
*************** make_write (const cpp_reader *pfile, FIL
*** 405,411 ****
        make_write_vec (d->deps, fp, column, colmax);
        fputs ("\n", fp);
        if (CPP_OPTION (pfile, deps.phony_targets))
! 	for (unsigned i = 1; i < d->deps.size (); i++)
  	  fprintf (fp, "%s:\n", munge (d->deps[i]));
      }
  
--- 413,419 ----
        make_write_vec (d->deps, fp, column, colmax);
        fputs ("\n", fp);
        if (CPP_OPTION (pfile, deps.phony_targets))
! 	for (unsigned i = d->first_phony_dep; i < d->deps.size (); i++)
  	  fprintf (fp, "%s:\n", munge (d->deps[i]));
      }
  
diff -Nrcpad gcc-13.4.0/libcpp/po/be.gmo gcc-13.5.0-RC-20260904/libcpp/po/be.gmo
*** gcc-13.4.0/libcpp/po/be.gmo	Thu Jun  5 16:21:33 2025
--- gcc-13.5.0-RC-20260904/libcpp/po/be.gmo	Fri Sep  4 07:50:20 2026
*************** Last-Translator: Ales Nyakhaychyk 
  Language: be
  MIME-Version: 1.0
! Content-Type: text/plain; charset=utf-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  %s - гэта блёчная прылада%s - вельмі вялікіпустая сімвальная канстантапрапушчан завяршаючы сімвал %cмнагасімвальная сімвальная канстантанезавершаныя каментарыі
\ No newline at end of file
--- 5,11 ----
  Language-Team: Belarusian 
  Language: be
  MIME-Version: 1.0
! Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  %s - гэта блёчная прылада%s - вельмі вялікіпустая сімвальная канстантапрапушчан завяршаючы сімвал %cмнагасімвальная сімвальная канстантанезавершаныя каментарыі
\ No newline at end of file
diff -Nrcpad gcc-13.4.0/libcpp/po/ca.gmo gcc-13.5.0-RC-20260904/libcpp/po/ca.gmo
*** gcc-13.4.0/libcpp/po/ca.gmo	Thu Jun  5 16:21:33 2025
--- gcc-13.5.0-RC-20260904/libcpp/po/ca.gmo	Fri Sep  4 07:50:20 2026
***************
*** 1,8 ****
  	&*
?+
k



$



  $/#T x2',A]m6t'$5(.Ws.0-:,Vg+0+Ht$,D0'Xt( 990(j /)&55%k!".#;<Z$,E4 z
! '+(0<*m+$##)*M*x)13/9c)H'h"5)$&'Ks&"7)9WwS8 *'8R($$'+&R3m211 48 /m ) - ' -!K!/i!!C!6!7$"\"q".""&"("%# <# ]#|~#($,$%DQ%!%%%%,%&;&R&b&'s&&&)&8&&3'&Z'''''H'.('H(;p(*(#((2)AH)5)J);*}G*(*:*5)+_+6{+0+I+3-,a,z,3,0,,7-DP----.--.'@.@h.).%.'.#!/3E/y/ /E//0/,0\0:w0B0+0
! !13,12`11.1.1.
! 2692,p22/2)2.33B3'v333C3;4KR4+444 5#5%>5!d505,55:6-=62k6166,6%7??7/7!7&7$7`82~8858<8++92W949;9?9;::[:3:2:2:80;-i;-;*;(;*<D<9a<<K<B==I===9==&>1*>&\>%>'>d;rq	+0A8-H*B9'oPDnju%}
  #L"hJz57$Cwv/kZbSIy6Eel(s3N?!mc~xRM4>[G
=Q]@:VTW`\.Y|O&K,X1ig) pF{_a^<fU2t"%s" after # is not a positive integer"%s" after #line is not a positive integer"%s" cannot be used as a macro name as it is an operator in C++"%s" is not a valid filename"%s" re-asserted"%s" redefined"/*" within comment#%s expects "FILENAME" or #%s is a GCC extension#else after #else#else without #if#endif without #if#include_next in primary source file#pragma %s %s is already registered#pragma %s is already registered#pragma once in main file#pragma system_header ignored outside include file%.*s is not a valid universal character%s in preprocessing directive%s is a block device%s is shorter than expected%s is too large%s: %s%s: not used because `%.*s' defined as `%s' not `%.*s'%s: not used because `%.*s' not defined%s: not used because `%s' is defined'##' cannot appear at either end of a macro expansion'#' is not followed by a macro parameter'$' in identifier or number'?' without following ':'("%s" is an alternative token for "%s" in C++)(this will be reported only once per input file)C++ style comments are not allowed in ISO C90CPP arithmetic must be at least as precise as a target intCPP half-integer narrower than CPP characterCPP on this host cannot handle wide character constants over %lu bits, but the target requires %lu bitsISO C does not permit named variadic macrosISO C99 requires whitespace after the macro nameMultiple include guards may be useful for:
  NULL directory in find_file\x used with no following hex digits_Pragma takes a parenthesized string literal__VA_ARGS__ can only appear in the expansion of a C99 variadic macroanonymous variadic macros were introduced in C99assertion without predicateattempt to use poisoned "%s"backslash and newline separated by spacebackslash-newline at end of filecannot find source file %scharacter 0x%lx is not in the basic source character set
  character 0x%lx is not unibyte in execution character setcharacter constant too long for its typecomma operator in operand of #ifconversion from %s to %s not supported by iconvconverting UCN to execution character setconverting UCN to source character setconverting escape sequence to execution character setconverting to execution character setcould not determine date and timecppchar_t must be an unsigned typecurrent file is older than %sdetected recursion whilst expanding macro "%s"division by zero in #ifduplicate macro parameter "%s"embedding a directive within macro arguments is not portableempty character constantempty filename in #%sextra tokens at end of #%s directivefailure to convert %s to %sfloating constant in preprocessor expressionfunction-like macro "%s" must be used with arguments in traditional Chex escape sequence out of rangeiconv_openimaginary constants are a GCC extensionimaginary number in preprocessor expressionimpossible operator '%u'incomplete universal character name %.*sinteger constant is so large that it is unsignedinteger constant is too large for its typeinteger overflow in preprocessor expressioninvalid #pragma GCC poison directiveinvalid built-in macro "%s"invalid flag "%s" in line directiveinvalid preprocessing directive #%sinvalid string literal, ignoring final '\'invalid suffix "%.*s" on floating constantinvalid suffix "%.*s" on integer constantline number out of rangemacro "%s" is not usedmacro "%s" passed %u arguments, but takes just %umacro "%s" requires %u arguments, but only %u givenmacro argument "%s" would be stringified in traditional Cmacro names must be identifiersmissing '(' after predicatemissing '(' in expressionmissing ')' after "defined"missing ')' in expressionmissing ')' to complete answermissing terminating > charactermissing whitespace after the macro namemulti-character character constantmulti-line commentno iconv implementation, cannot convert from %s to %sno include path in which to search for %sno macro name given in #%s directivenon-ISO-standard escape sequence, '\%c'null character(s) ignorednull character(s) preserved in literaloctal escape sequence out of rangeone or more PCH files were found, but they were invalidoperator "defined" requires an identifierpoisoning existing macro "%s"predicate must be an identifierpredicate's answer is emptypreprocessor arithmetic has maximum precision of %lu bits; target requires %lu bitsregistering "%s" as both a pragma and a pragma namespacestdoutstyle of line directive is a GCC extensionsuggest hiding #%s from traditional C with an indented #suggest not using #elif in traditional Csyntax error in macro parameter listtarget char is less than 8 bits widetarget int is narrower than target chartarget wchar_t is narrower than target charthe conditional began herethe left operand of "%s" changes sign when promotedthe meaning of '\%c' is different in traditional Cthe meaning of '\a' is different in traditional Cthe meaning of '\x' is different in traditional Cthe right operand of "%s" changes sign when promotedthis is the location of the previous definitionthis use of "defined" may not be portabletraditional C ignores #%s with the # indentedtraditional C rejects the "%.*s" suffixtraditional C rejects the unary plus operatortrigraph ??%c converted to %ctrigraph ??%c ignored, use -trigraphs to enableundefining "%s"universal character %.*s is not valid at the start of an identifieruniversal character %.*s is not valid in an identifieruniversal character names are only valid in C++ and C99unspellable token %sunterminated #%sunterminated argument list invoking macro "%s"unterminated commentuse -Winvalid-pch for more informationuse of C99 hexadecimal floating constantuse of C99 long long integer constantwhile reading precompiled headerwhile writing precompiled headerProject-Id-Version: cpplib-4.0.1
--- 1,7 ----
  	&*
?+
k



$



  $/#T x2',A]m6t'$5(.Ws.0-:,Vg+0+Ht$,D0'Xt( 990(j /)&55%k!".#;<Z$,E4 z
! '+(0<*m+$##)*M*x)13/9c)H'h"5)$&'Ks&"7)9WwS8 *'8R($$'+&R3m211 48 /m ) - ' -!K!/i!!C!6!7$"\"q".""&"("%# <# ]#w~#*$.!%FP%#%%%%,%"&@&X&h&'y&&&)&9'):'&d'''''J'0)()Z(<(,(#()3-)Ca)6)K)>(*g*(*;+9N++8+1+K,4[,,,4,1,.-:J-H-.--/./M.(}.D.+.%/'=/%e/3//!/G/B0]0/w00;0C0-B1
! p16{131101002/a272-2213*F3/q343(334D44=y4K4+5/5L5!h55%5#515/"6R6;r6.62657F7-c7'7B7/7!,8&N8%u8d829398:9<s9+9495:=G:A:!:;:4%;3Z;3;9;1;..<*]<(<+<<9<4=NT=E=A=+>E>9V>>(>2>'?&+?(R?d;rq	+0A8-H*B9'oPDnju%}
  #L"hJz57$Cwv/kZbSIy6Eel(s3N?!mc~xRM4>[G
=Q]@:VTW`\.Y|O&K,X1ig) pF{_a^<fU2t"%s" after # is not a positive integer"%s" after #line is not a positive integer"%s" cannot be used as a macro name as it is an operator in C++"%s" is not a valid filename"%s" re-asserted"%s" redefined"/*" within comment#%s expects "FILENAME" or #%s is a GCC extension#else after #else#else without #if#endif without #if#include_next in primary source file#pragma %s %s is already registered#pragma %s is already registered#pragma once in main file#pragma system_header ignored outside include file%.*s is not a valid universal character%s in preprocessing directive%s is a block device%s is shorter than expected%s is too large%s: %s%s: not used because `%.*s' defined as `%s' not `%.*s'%s: not used because `%.*s' not defined%s: not used because `%s' is defined'##' cannot appear at either end of a macro expansion'#' is not followed by a macro parameter'$' in identifier or number'?' without following ':'("%s" is an alternative token for "%s" in C++)(this will be reported only once per input file)C++ style comments are not allowed in ISO C90CPP arithmetic must be at least as precise as a target intCPP half-integer narrower than CPP characterCPP on this host cannot handle wide character constants over %lu bits, but the target requires %lu bitsISO C does not permit named variadic macrosISO C99 requires whitespace after the macro nameMultiple include guards may be useful for:
  NULL directory in find_file\x used with no following hex digits_Pragma takes a parenthesized string literal__VA_ARGS__ can only appear in the expansion of a C99 variadic macroanonymous variadic macros were introduced in C99assertion without predicateattempt to use poisoned "%s"backslash and newline separated by spacebackslash-newline at end of filecannot find source file %scharacter 0x%lx is not in the basic source character set
  character 0x%lx is not unibyte in execution character setcharacter constant too long for its typecomma operator in operand of #ifconversion from %s to %s not supported by iconvconverting UCN to execution character setconverting UCN to source character setconverting escape sequence to execution character setconverting to execution character setcould not determine date and timecppchar_t must be an unsigned typecurrent file is older than %sdetected recursion whilst expanding macro "%s"division by zero in #ifduplicate macro parameter "%s"embedding a directive within macro arguments is not portableempty character constantempty filename in #%sextra tokens at end of #%s directivefailure to convert %s to %sfloating constant in preprocessor expressionfunction-like macro "%s" must be used with arguments in traditional Chex escape sequence out of rangeiconv_openimaginary constants are a GCC extensionimaginary number in preprocessor expressionimpossible operator '%u'incomplete universal character name %.*sinteger constant is so large that it is unsignedinteger constant is too large for its typeinteger overflow in preprocessor expressioninvalid #pragma GCC poison directiveinvalid built-in macro "%s"invalid flag "%s" in line directiveinvalid preprocessing directive #%sinvalid string literal, ignoring final '\'invalid suffix "%.*s" on floating constantinvalid suffix "%.*s" on integer constantline number out of rangemacro "%s" is not usedmacro "%s" passed %u arguments, but takes just %umacro "%s" requires %u arguments, but only %u givenmacro argument "%s" would be stringified in traditional Cmacro names must be identifiersmissing '(' after predicatemissing '(' in expressionmissing ')' after "defined"missing ')' in expressionmissing ')' to complete answermissing terminating > charactermissing whitespace after the macro namemulti-character character constantmulti-line commentno iconv implementation, cannot convert from %s to %sno include path in which to search for %sno macro name given in #%s directivenon-ISO-standard escape sequence, '\%c'null character(s) ignorednull character(s) preserved in literaloctal escape sequence out of rangeone or more PCH files were found, but they were invalidoperator "defined" requires an identifierpoisoning existing macro "%s"predicate must be an identifierpredicate's answer is emptypreprocessor arithmetic has maximum precision of %lu bits; target requires %lu bitsregistering "%s" as both a pragma and a pragma namespacestdoutstyle of line directive is a GCC extensionsuggest hiding #%s from traditional C with an indented #suggest not using #elif in traditional Csyntax error in macro parameter listtarget char is less than 8 bits widetarget int is narrower than target chartarget wchar_t is narrower than target charthe conditional began herethe left operand of "%s" changes sign when promotedthe meaning of '\%c' is different in traditional Cthe meaning of '\a' is different in traditional Cthe meaning of '\x' is different in traditional Cthe right operand of "%s" changes sign when promotedthis is the location of the previous definitionthis use of "defined" may not be portabletraditional C ignores #%s with the # indentedtraditional C rejects the "%.*s" suffixtraditional C rejects the unary plus operatortrigraph ??%c converted to %ctrigraph ??%c ignored, use -trigraphs to enableundefining "%s"universal character %.*s is not valid at the start of an identifieruniversal character %.*s is not valid in an identifieruniversal character names are only valid in C++ and C99unspellable token %sunterminated #%sunterminated argument list invoking macro "%s"unterminated commentuse -Winvalid-pch for more informationuse of C99 hexadecimal floating constantuse of C99 long long integer constantwhile reading precompiled headerwhile writing precompiled headerProject-Id-Version: cpplib-4.0.1
*************** Last-Translator: Mateu Gilles 
  Language: ca
  MIME-Version: 1.0
! Content-Type: text/plain; charset=ISO-8859-1
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
! "%s" desprs de # no s un enter positiu"%s" desprs de #line no s un enter positiuno es pot usar "%s" com un nom de macro perqu s un operador en C++"%s" no s un nom de fitxer vlid"%s" reafirmat"%s" re-definit"/*" dintre d'un comentari#%s espera "NOM_DE_FITXER" o #%s s una extenci del GCC#else desprs de #else#else sense #if#endif sense #if#include_next en el fitxer font primarija s'ha desat #pragma %s %sja s'ha desat #pragma %s#pragma una vegada en el fitxer principal#pragma system_header ignorat fora del fitxer d'inclusi%.*s no s un carcter universal vlid%s en una directiva de preprocessament%s s un dispositiu de blocs%s s ms curt qu'esperat%s s massa gran%s: %s%s: no utilitzat perqu "%.*s" est definit com a "%s" i no com a "%.*s"%s: no utilitzat perqu "%.*s" no est definit%s: no utilitzat perqu "%s" s definit"##" no pot apareixer en o al final d'una expansi de macro"#" no s seguit per un parmetre de macro"$" en un identificador o un nombre "?" sense el ":" segent("%s" s un element alternatiu per a  "%s" en C++)(aix es reportar solament una vegada per cada fitxer d'entrada)els comentaris d'estil C++ no sn permesos en ISO C90l'aritmtica de CPP ha de ser almenys tan precisa com un int de l'objectiuel half-integer de CPP s ms estret que el carcter de CPPCPP no pot manejar constants de carcter amples ms enll de %lu bits en aquest ordinador, per l'objectiu requereix %lu bitsISO C no permet macros variadic nomenatsISO C99 requereix espais en blanc desprs del nom de macroMltiples gurdies d'inclusi poden ser tils per a:
! directori NULL en find_filees va usar \x sense dgits hexadecimales a continuaci_Pragma pren una cadena literal entre parntesis__VA_ARGS__ solament pot aparixer en l'expansi d'una macro variadic C99els macros variadic annims es van introduir en C99afirmaci sense predicatintent d'usar "%s" enverinatbarra invertida i fi de lnia separats per un espaibarra invertida i nova lnia al final del fitxerno es pot trobar la font %sel carcter 0x%lx no s en el joc de carcters de base
! el carcter 0x%lx no s mono octet en el joc de carcters d'execuciconstant de carcter massa gran pel seu tipusoperador coma en operant de #ificonv no dona suport a la conversi de %s a %sconvertint UCN al joc de carcters d'execuciconvertint UCN al joc font de carctersconvertint una seqncia d'escapa al joc de carcters d'execuciconvertint al joc de carcters d'execucino es pot determinar la data i l'horacppchar_t ha de ser d'un tipus unsignedel fitxer actual s ms vell que %swhilst recursiu detectat en expandint la macro "%s"divisi per zero en #ifparmetre de macro "%s" duplicatl'incrustaci d'una directiva entre arguments de macro no s portableconstant de carter buidanom de fitxer buit en #%selements superflus al final de la directiva #%sfallada convertint %s a %sconstant de coma flotant en l'expressi del preprocessadorla funci de macro "%s" s'ha d'usar amb arguments en C tradicionalseqncia d'escapa hexadecimal fora de rangiconv_openles constants imaginries sn una extensi d'el GCCnombre imaginari en l'expressi del preprocessadoroperador "%u" impossibleel nom de carcter universal %.*s s incompletla constant entera s tan gran que s unsignedla constant entera s massa gran pel seu tipusdesbordament d'enter en l'expressi del preprocessadordirectiva #pragma de GCC enverinada invlidamacro interna "%s" invlidaindicador "%s" invlid en la directiva de lniadirectiva de preprocessament #%s invlidacadena literal invlida, s'ignora el "\" finalsufix "%.*s" invlid en la constant de coma flotantsufix "%.*s" invlid en constant enteranombre de lnia fora de rangno s'usa la macro "%s"la macro "%s" va rebre %u arguments, per en va prendre solament %ula macro "%s" requereix %u arguments, per noms %u passatsl'argument de macro "%s" hauria de ser convertit en cadena en C traditionalels noms de macro han de ser identificadorsfalta "(" abans del predicat"(" faltant en l'expressi")" faltant desprs de "defined"")" faltant en l'expressifalta ")" per a completar la respostafalta el carcter de terminaci >espais en blanc faltant desprs del nom de macroconstant de carcter amb mltiples carcterscomentari en mltiples lniescap implementaci de iconv, no es pot convertir de %s a %sno hi ha ruta d'inclusi en la qual cercar %sno es va donar un nom de macro en la directiva #%sseqncia d'escapa que no s estndard ISO, "\%c"carter(es) nul(s) ignoratscarcter(es) nul(s) preservats en la literalseqncia d'escapa octal fora de rangun o ms fitxers PCH varen ser trobats, per varen ser invlidsl'operador "defined" requereix un identificadorenverinant la macro existent "%s"el predicat ha de ser un identificadorel predicat de la resposta est buitl'aritmtica del preprocesador t una precisi mxima de %lu bits; l'objectiu requereix %lu bitsdesant "%s" com a pragma i espai de noms de pragmastdoutla directiva d'estil de lnia s una extenci del GCCes suggereix ocultar #%s del C tradicional amb el # indentates suggereix no usar #elif en C tradicionalerror sintctic en la llista de parmetre de macroel char de l'objectiu t menys de 8 bits d'ampliariael int de l'objectiu s ms estret qu'el char de l'objectiuel wchar_t de l'objectiu s ms estret qu'el char de l'objectiuel condicional va comenar aqul'operant esquera de "%s" canvia el signe quan s promogutel significat de "\%c" s diferent en C tradicionalel significat de "\a" s diferent en C tradicionalel significat de "\x" s diferent en C tradicionall'operant dreta de "%s" canvia el signe quan s promogutaquesta s la ubicaci de la definici prviaaquest s de "defined" podria no ser portableC tradicional ignora #%s amb el # indentatel C tradicional rebutja el sufix "%.*s"C tradicional rebutja l'operador unari mstrigraph ??%c convertit a %cs'ignora el trigraph ??%c, usi -trigraphs per permetre-hoesborrant la definici de "%s"el nom de carcter universal  %.*s no s vlid a l'inici d'un identificadorel nom de carcter universal  %.*s no s vlid en un identificadorels noms de carcter universals noms sn vlids en C++ i C99Element %s impronunciable#%s sense acabarllista d'arguments sense acabar a l'invocar la macro "%s"comentari sense acabarusi -Winvalid-pch per a ms informacis d'una constant de coma flotant hexadecimal C99s d'una constant entera long long C99mentre llegint capalera precompiladamentre escrivint capalera precompilada
\ No newline at end of file
--- 11,19 ----
  Language-Team: Catalan 
  Language: ca
  MIME-Version: 1.0
! Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
! "%s" desprès de # no és un enter positiu"%s" desprès de #line no és un enter positiuno es pot usar "%s" com un nom de macro perquè és un operador en C++"%s" no és un nom de fitxer vàlid"%s" reafirmat"%s" re-definit"/*" dintre d'un comentari#%s espera "NOM_DE_FITXER" o #%s és una extenció del GCC#else després de #else#else sense #if#endif sense #if#include_next en el fitxer font primarija s'ha desat #pragma %s %sja s'ha desat #pragma %s#pragma una vegada en el fitxer principal#pragma system_header ignorat fora del fitxer d'inclusió%.*s no és un caràcter universal vàlid%s en una directiva de preprocessament%s és un dispositiu de blocs%s és més curt qu'esperat%s és massa gran%s: %s%s: no utilitzat perquè "%.*s" està definit com a "%s" i no com a "%.*s"%s: no utilitzat perquè "%.*s" no està definit%s: no utilitzat perquè "%s" és definit"##" no pot apareixer en o al final d'una expansió de macro"#" no és seguit per un paràmetre de macro"$" en un identificador o un nombre "?" sense el ":" següent("%s" és un element alternatiu per a  "%s" en C++)(això es reportarà solament una vegada per cada fitxer d'entrada)els comentaris d'estil C++ no són permesos en ISO C90l'aritmètica de CPP ha de ser almenys tan precisa com un int de l'objectiuel half-integer de CPP és més estret que el caràcter de CPPCPP no pot manejar constants de caràcter amples més enllà de %lu bits en aquest ordinador, però l'objectiu requereix %lu bitsISO C no permet macros variadic nomenatsISO C99 requereix espais en blanc després del nom de macroMúltiples guàrdies d'inclusió poden ser útils per a:
! directori NULL en find_filees va usar \x sense dígits hexadecimales a continuació_Pragma pren una cadena literal entre parèntesis__VA_ARGS__ solament pot aparèixer en l'expansió d'una macro variadic C99els macros variadic anònims es van introduir en C99afirmació sense predicatintent d'usar "%s" enverinatbarra invertida i fi de línia separats per un espaibarra invertida i nova línia al final del fitxerno es pot trobar la font %sel caràcter 0x%lx no és en el joc de caràcters de base
! el caràcter 0x%lx no és mono octet en el joc de caràcters d'execucióconstant de caràcter massa gran pel seu tipusoperador coma en operant de #ificonv no dona suport a la conversió de %s a %sconvertint UCN al joc de caràcters d'execucióconvertint UCN al joc font de caràctersconvertint una seqüència d'escapa al joc de caràcters d'execucióconvertint al joc de caràcters d'execucióno es pot determinar la data i l'horacppchar_t ha de ser d'un tipus unsignedel fitxer actual és més vell que %swhilst recursiu detectat en expandint la macro "%s"divisió per zero en #ifparàmetre de macro "%s" duplicatl'incrustació d'una directiva entre arguments de macro no és portableconstant de caràter buidanom de fitxer buit en #%selements superflus al final de la directiva #%sfallada convertint %s a %sconstant de coma flotant en l'expressió del preprocessadorla funció de macro "%s" s'ha d'usar amb arguments en C tradicionalseqüència d'escapa hexadecimal fora de rangiconv_openles constants imaginàries són una extensió d'el GCCnombre imaginari en l'expressió del preprocessadoroperador "%u" impossibleel nom de caràcter universal %.*s és incompletla constant entera és tan gran que és unsignedla constant entera és massa gran pel seu tipusdesbordament d'enter en l'expressió del preprocessadordirectiva #pragma de GCC enverinada invàlidamacro interna "%s" invàlidaindicador "%s" invàlid en la directiva de líniadirectiva de preprocessament #%s invàlidacadena literal invàlida, s'ignora el "\" finalsufix "%.*s" invàlid en la constant de coma flotantsufix "%.*s" invàlid en constant enteranombre de línia fora de rangno s'usa la macro "%s"la macro "%s" va rebre %u arguments, però en va prendre solament %ula macro "%s" requereix %u arguments, però només %u passatsl'argument de macro "%s" hauria de ser convertit en cadena en C traditionalels noms de macro han de ser identificadorsfalta "(" abans del predicat"(" faltant en l'expressió")" faltant després de "defined"")" faltant en l'expressiófalta ")" per a completar la respostafalta el caràcter de terminació >espais en blanc faltant després del nom de macroconstant de caràcter amb múltiples caràcterscomentari en múltiples líniescap implementació de iconv, no es pot convertir de %s a %sno hi ha ruta d'inclusió en la qual cercar %sno es va donar un nom de macro en la directiva #%sseqüència d'escapa que no és estàndard ISO, "\%c"caràter(es) nul(s) ignoratscaràcter(es) nul(s) preservats en la literalseqüència d'escapa octal fora de rangun o més fitxers PCH varen ser trobats, però varen ser invàlidsl'operador "defined" requereix un identificadorenverinant la macro existent "%s"el predicat ha de ser un identificadorel predicat de la resposta està buitl'aritmètica del preprocesador té una precisió màxima de %lu bits; l'objectiu requereix %lu bitsdesant "%s" com a pragma i espai de noms de pragmastdoutla directiva d'estil de línia és una extenció del GCCes suggereix ocultar #%s del C tradicional amb el # indentates suggereix no usar #elif en C tradicionalerror sintàctic en la llista de paràmetre de macroel char de l'objectiu té menys de 8 bits d'ampliariael int de l'objectiu és més estret qu'el char de l'objectiuel wchar_t de l'objectiu és més estret qu'el char de l'objectiuel condicional va començar aquíl'operant esquera de "%s" canvia el signe quan és promogutel significat de "\%c" és diferent en C tradicionalel significat de "\a" és diferent en C tradicionalel significat de "\x" és diferent en C tradicionall'operant dreta de "%s" canvia el signe quan és promogutaquesta és la ubicació de la definició prèviaaquest ùs de "defined" podria no ser portableC tradicional ignora #%s amb el # indentatel C tradicional rebutja el sufix "%.*s"C tradicional rebutja l'operador unari méstrigraph ??%c convertit a %cs'ignora el trigraph ??%c, usi -trigraphs per permetre-hoesborrant la definició de "%s"el nom de caràcter universal  %.*s no és vàlid a l'inici d'un identificadorel nom de caràcter universal  %.*s no és vàlid en un identificadorels noms de caràcter universals nomès són vàlids en C++ i C99Element %s impronunciable#%s sense acabarllista d'arguments sense acabar a l'invocar la macro "%s"comentari sense acabarusi -Winvalid-pch per a més informacióús d'una constant de coma flotant hexadecimal C99ús d'una constant entera long long C99mentre llegint capçalera precompiladamentre escrivint capçalera precompilada
\ No newline at end of file
diff -Nrcpad gcc-13.4.0/libcpp/po/el.gmo gcc-13.5.0-RC-20260904/libcpp/po/el.gmo
*** gcc-13.4.0/libcpp/po/el.gmo	Thu Jun  5 16:21:33 2025
--- gcc-13.5.0-RC-20260904/libcpp/po/el.gmo	Fri Sep  4 07:50:20 2026
***************
*** 1,11 ****
! Dl }DY\(c#else after #else%s%s: %smissing terminating %c characterProject-Id-Version: gcc 3.2
  Report-Msgid-Bugs-To: https://gcc.gnu.org/bugs/
  PO-Revision-Date: 2002-08-18 15:46+0100
  Last-Translator: Simos Xenitellis 
  Language-Team: Greek 
  Language: el
  MIME-Version: 1.0
! Content-Type: text/plain; charset=iso-8859-7
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
! #else   #else%s%s: %s    %c
\ No newline at end of file
--- 1,11 ----
! Dl x?[^Je#else after #else%s%s: %smissing terminating %c characterProject-Id-Version: gcc 3.2
  Report-Msgid-Bugs-To: https://gcc.gnu.org/bugs/
  PO-Revision-Date: 2002-08-18 15:46+0100
  Last-Translator: Simos Xenitellis 
  Language-Team: Greek 
  Language: el
  MIME-Version: 1.0
! Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
! #else μετά από #else%s%s: %sέχει παραληφθεί τερματικός χαρακτήρας %c
\ No newline at end of file
diff -Nrcpad gcc-13.4.0/libcpp/po/eo.gmo gcc-13.5.0-RC-20260904/libcpp/po/eo.gmo
*** gcc-13.4.0/libcpp/po/eo.gmo	Thu Jun  5 16:21:33 2025
--- gcc-13.5.0-RC-20260904/libcpp/po/eo.gmo	Fri Sep  4 07:50:20 2026
*************** Last-Translator: Felipe Castro 
  Language: eo
  MIME-Version: 1.0
! Content-Type: text/plain; charset=utf-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  X-Generator: Poedit 2.4.2
--- 13,19 ----
  Language-Team: Esperanto 
  Language: eo
  MIME-Version: 1.0
! Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  X-Generator: Poedit 2.4.2
diff -Nrcpad gcc-13.4.0/libcpp/po/id.gmo gcc-13.5.0-RC-20260904/libcpp/po/id.gmo
*** gcc-13.4.0/libcpp/po/id.gmo	Thu Jun  5 16:21:33 2025
--- gcc-13.5.0-RC-20260904/libcpp/po/id.gmo	Fri Sep  4 07:50:20 2026
***************
*** 1,6 ****
  \ &!*H?s$)!@bt$# 2'Px{6''@$h-5(6.P0-:,gF+0++W$s,<DG\0r%(! Jk99( #/D)t&5%!!"C"f.<
Jc$y),E W
! x1'+	("0K*|+$#$2W.s#)#**?)j813/9c )  H i ' "  5 )!$G!'l!!&!"!7!)0"Z"x""S".#87#<p#$#D#$*$-I$8w$($$$$$'#%+K%w%3%2%1%1+&4]&/&)&-&''-B'p'/'''"'C(6L(7(((().)N)c)&{)() ) )
*++/+`,(v,,,,+,-6"-Y-m-}-----!-5./M.}... ...I.*B/5m/-/4/?0/F0v00:080/ 1GP121r1.>21m2,2/2 2.34L3?3L34%40=4n4%494&405(?5&h5658505%060V6%6!616!7(#7'L7+t7!7/778C.8r88'8808, 9LM9)9
! 9<9.:*;:f:*:1:-:+
;9;(R;&{;';;6;+</K<%{<1<2<2=A9=!{==;=<=71>(i>>>>>#>#?@?\?!|??@?E?6:@(q@@$@+@EA6KA!A-AAYA5DBBzBFB,CO1CC2C8CJC6?D)vD(D'D+DE78E+pE*E*E8E*+F4VF3F&F)FG=+GiGG-GHGAH6WH&H&HHH7IHIaI2I3I!I!	J:	>,3d{+xbu;\O[^q|S-*'B`J
  $%1QcX~wsHZjNai7k )LDv/p?REt]FPK}o69g_5VAn!
TIW0Mf"YG=r(y&zC4.h<ml2@e8U#"%s" after # is not a positive integer"%s" after #line is not a positive integer"%s" cannot be used as a macro name as it is an operator in C++"%s" is not a valid filename"%s" re-asserted"%s" redefined"/*" within comment#%s expects "FILENAME" or #%s is a GCC extension#%s is a deprecated GCC extension#else after #else#else without #if#endif without #if#include_next in primary source file#pragma %s %s is already registered#pragma %s is already registered#pragma once in main file#pragma system_header ignored outside include file%.*s is not a valid universal character%s%s in preprocessing directive%s is a block device%s is shorter than expected%s is too large%s: %s%s: not used because `%.*s' defined as `%s' not `%.*s'%s: not used because `%.*s' is poisoned%s: not used because `%.*s' not defined%s: not used because `%s' is defined%s: not used because `__COUNTER__' is invalid'##' cannot appear at either end of a macro expansion'#' is not followed by a macro parameter'$' in identifier or number'?' without following ':'("%s" is an alternative token for "%s" in C++)(this will be reported only once per input file)C++ style comments are not allowed in ISO C90CPP arithmetic must be at least as precise as a target intCPP half-integer narrower than CPP characterCPP on this host cannot handle wide character constants over %lu bits, but the target requires %lu bitsISO C does not permit named variadic macrosISO C99 requires whitespace after the macro nameIn _cpp_valid_ucn but not a UCNMultiple include guards may be useful for:
  NULL directory in find_file\x used with no following hex digits_Pragma takes a parenthesized string literal__COUNTER__ expanded inside directive with -fdirectives-only__VA_ARGS__ can only appear in the expansion of a C99 variadic macro`%.*s' is not in NFC`%.*s' is not in NFKCanonymous variadic macros were introduced in C99assertion without predicateassertions are a GCC extensionassertions are a deprecated extensionattempt to use poisoned "%s"backslash and newline separated by spacebackslash-newline at end of filecannot find source file %scharacter 0x%lx is not in the basic source character set
  character 0x%lx is not unibyte in execution character setcharacter constant too long for its typecomma operator in operand of #ifconversion from %s to %s not supported by iconvconverting UCN to execution character setconverting UCN to source character setconverting escape sequence to execution character setconverting to execution character setcould not determine date and timecould not determine file timestampcppchar_t must be an unsigned typecurrent file is older than %sdetected recursion whilst expanding macro "%s"division by zero in #ifduplicate macro parameter "%s"embedding a directive within macro arguments is not portableempty character constantempty filename in #%sextra tokens at end of #%s directivefailure to convert %s to %sfixed-point constants are a GCC extensionfloating constant in preprocessor expressionfunction-like macro "%s" must be used with arguments in traditional Chex escape sequence out of rangeiconv_openidentifier "%s" is a special operator name in C++imaginary constants are a GCC extensionimaginary number in preprocessor expressionimpossible operator '%u'incomplete universal character name %.*sinteger constant is so large that it is unsignedinteger constant is too large for its typeinteger overflow in preprocessor expressioninvalid #%s directiveinvalid #pragma GCC poison directiveinvalid #pragma pop_macro directiveinvalid #pragma push_macro directiveinvalid built-in macro "%s"invalid character '%c' in raw string delimiterinvalid flag "%s" in line directiveinvalid prefix "0b" for floating constantinvalid preprocessing directive #%sinvalid string literal, ignoring final '\'invalid suffix "%.*s" on floating constantinvalid suffix "%.*s" on integer constantinvalid suffix "%.*s" with hexadecimal floating constantline number out of rangemacro "%s" is not usedmacro "%s" passed %u arguments, but takes just %umacro "%s" requires %u arguments, but only %u givenmacro argument "%s" would be stringified in traditional Cmacro names must be identifiersmissing '(' after predicatemissing '(' in expressionmissing ')' after "defined"missing ')' in expressionmissing ')' to complete answermissing terminating %c charactermissing terminating > charactermissing whitespace after the macro namemulti-character character constantmulti-line commentno iconv implementation, cannot convert from %s to %sno include path in which to search for %sno macro name given in #%s directivenon-ISO-standard escape sequence, '\%c'null character(s) ignorednull character(s) preserved in literaloctal escape sequence out of rangeone or more PCH files were found, but they were invalidoperator "defined" requires an identifierpoisoning existing macro "%s"predicate must be an identifierpredicate's answer is emptypreprocessor arithmetic has maximum precision of %lu bits; target requires %lu bitsraw string delimiter longer than 16 charactersregistering "%s" as both a pragma and a pragma namespaceregistering pragma "%s" with name expansion and no namespaceregistering pragma with NULL handlerregistering pragmas in namespace "%s" with mismatched name expansionstdoutstyle of line directive is a GCC extensionsuffix for double constant is a GCC extensionsuggest hiding #%s from traditional C with an indented #suggest not using #elif in traditional Csyntax error in macro parameter listtarget char is less than 8 bits widetarget int is narrower than target chartarget wchar_t is narrower than target charthe conditional began herethe left operand of "%s" changes sign when promotedthe meaning of '\%c' is different in traditional Cthe meaning of '\a' is different in traditional Cthe meaning of '\x' is different in traditional Cthe right operand of "%s" changes sign when promotedthis is the location of the previous definitionthis use of "defined" may not be portabletraditional C ignores #%s with the # indentedtraditional C rejects the "%.*s" suffixtraditional C rejects the unary plus operatortrigraph ??%c converted to %ctrigraph ??%c ignored, use -trigraphs to enableunbalanced stack in %sundefining "%s"unexpected end of file after #lineuniversal character %.*s is not valid at the start of an identifieruniversal character %.*s is not valid in an identifieruniversal character names are only valid in C++ and C99unknown escape sequence: '\%c'unknown escape sequence: '\%s'unspellable token %sunterminated #%sunterminated argument list invoking macro "%s"unterminated commentunterminated raw stringuse -Winvalid-pch for more informationuse of C99 hexadecimal floating constantwhile reading precompiled headerwhile writing precompiled headerProject-Id-Version: cpplib 4.5-b20100204
--- 1,7 ----
  \ &!*H?s$)!@bt$# 2'Px{6''@$h-5(6.P0-:,gF+0++W$s,<DG\0r%(! Jk99( #/D)t&5%!!"C"f.<
Jc$y),E W
! x1'+	("0K*|+$#$2W.s#)#**?)j813/9c )  H i ' "  5 )!$G!'l!!&!"!7!)0"Z"x""S".#87#<p#$#D#$*$-I$8w$($$$$$'#%+K%w%3%2%1%1+&4]&/&)&-&''-B'p'/'''"'C(6L(7(((().)N)c)&{)() ) )
*++/+`,(q,,,,+,,6-T-h-x-----!-5./H.x.{.. ...I.*=/5h/-/4/?0/A0q00:080/1GK121r1.921h2,2/2 2.34G3?|3L3	4 4084i4%494&40	5(:5&c5658505%+60Q6%6!616!6(7'G7+o7!7/77
! 8C)8m88'8808,9LH9)9
! 9<9.:*6:a:*}:1:-:+;4;(M;&v;';;6;+</F<%v<1<2<2=A4=!v==;=<=7,>(d>>>>>#>?;?W?!w??@?E?65@(l@@$@+@EA6FA!}A-AAYA5?BBuBFB,BO,C|C2C8CJC6:D)qD(D'D+DE73E+kE*E*E8E*&F4QF3F&F)FG=&GdGG-GHGAH6RH&H&HHH7ICI\I2{I3I!I!J:	>,3d{+xbu;\O[^q|S-*'B`J
  $%1QcX~wsHZjNai7k )LDv/p?REt]FPK}o69g_5VAn!
TIW0Mf"YG=r(y&zC4.h<ml2@e8U#"%s" after # is not a positive integer"%s" after #line is not a positive integer"%s" cannot be used as a macro name as it is an operator in C++"%s" is not a valid filename"%s" re-asserted"%s" redefined"/*" within comment#%s expects "FILENAME" or #%s is a GCC extension#%s is a deprecated GCC extension#else after #else#else without #if#endif without #if#include_next in primary source file#pragma %s %s is already registered#pragma %s is already registered#pragma once in main file#pragma system_header ignored outside include file%.*s is not a valid universal character%s%s in preprocessing directive%s is a block device%s is shorter than expected%s is too large%s: %s%s: not used because `%.*s' defined as `%s' not `%.*s'%s: not used because `%.*s' is poisoned%s: not used because `%.*s' not defined%s: not used because `%s' is defined%s: not used because `__COUNTER__' is invalid'##' cannot appear at either end of a macro expansion'#' is not followed by a macro parameter'$' in identifier or number'?' without following ':'("%s" is an alternative token for "%s" in C++)(this will be reported only once per input file)C++ style comments are not allowed in ISO C90CPP arithmetic must be at least as precise as a target intCPP half-integer narrower than CPP characterCPP on this host cannot handle wide character constants over %lu bits, but the target requires %lu bitsISO C does not permit named variadic macrosISO C99 requires whitespace after the macro nameIn _cpp_valid_ucn but not a UCNMultiple include guards may be useful for:
  NULL directory in find_file\x used with no following hex digits_Pragma takes a parenthesized string literal__COUNTER__ expanded inside directive with -fdirectives-only__VA_ARGS__ can only appear in the expansion of a C99 variadic macro`%.*s' is not in NFC`%.*s' is not in NFKCanonymous variadic macros were introduced in C99assertion without predicateassertions are a GCC extensionassertions are a deprecated extensionattempt to use poisoned "%s"backslash and newline separated by spacebackslash-newline at end of filecannot find source file %scharacter 0x%lx is not in the basic source character set
  character 0x%lx is not unibyte in execution character setcharacter constant too long for its typecomma operator in operand of #ifconversion from %s to %s not supported by iconvconverting UCN to execution character setconverting UCN to source character setconverting escape sequence to execution character setconverting to execution character setcould not determine date and timecould not determine file timestampcppchar_t must be an unsigned typecurrent file is older than %sdetected recursion whilst expanding macro "%s"division by zero in #ifduplicate macro parameter "%s"embedding a directive within macro arguments is not portableempty character constantempty filename in #%sextra tokens at end of #%s directivefailure to convert %s to %sfixed-point constants are a GCC extensionfloating constant in preprocessor expressionfunction-like macro "%s" must be used with arguments in traditional Chex escape sequence out of rangeiconv_openidentifier "%s" is a special operator name in C++imaginary constants are a GCC extensionimaginary number in preprocessor expressionimpossible operator '%u'incomplete universal character name %.*sinteger constant is so large that it is unsignedinteger constant is too large for its typeinteger overflow in preprocessor expressioninvalid #%s directiveinvalid #pragma GCC poison directiveinvalid #pragma pop_macro directiveinvalid #pragma push_macro directiveinvalid built-in macro "%s"invalid character '%c' in raw string delimiterinvalid flag "%s" in line directiveinvalid prefix "0b" for floating constantinvalid preprocessing directive #%sinvalid string literal, ignoring final '\'invalid suffix "%.*s" on floating constantinvalid suffix "%.*s" on integer constantinvalid suffix "%.*s" with hexadecimal floating constantline number out of rangemacro "%s" is not usedmacro "%s" passed %u arguments, but takes just %umacro "%s" requires %u arguments, but only %u givenmacro argument "%s" would be stringified in traditional Cmacro names must be identifiersmissing '(' after predicatemissing '(' in expressionmissing ')' after "defined"missing ')' in expressionmissing ')' to complete answermissing terminating %c charactermissing terminating > charactermissing whitespace after the macro namemulti-character character constantmulti-line commentno iconv implementation, cannot convert from %s to %sno include path in which to search for %sno macro name given in #%s directivenon-ISO-standard escape sequence, '\%c'null character(s) ignorednull character(s) preserved in literaloctal escape sequence out of rangeone or more PCH files were found, but they were invalidoperator "defined" requires an identifierpoisoning existing macro "%s"predicate must be an identifierpredicate's answer is emptypreprocessor arithmetic has maximum precision of %lu bits; target requires %lu bitsraw string delimiter longer than 16 charactersregistering "%s" as both a pragma and a pragma namespaceregistering pragma "%s" with name expansion and no namespaceregistering pragma with NULL handlerregistering pragmas in namespace "%s" with mismatched name expansionstdoutstyle of line directive is a GCC extensionsuffix for double constant is a GCC extensionsuggest hiding #%s from traditional C with an indented #suggest not using #elif in traditional Csyntax error in macro parameter listtarget char is less than 8 bits widetarget int is narrower than target chartarget wchar_t is narrower than target charthe conditional began herethe left operand of "%s" changes sign when promotedthe meaning of '\%c' is different in traditional Cthe meaning of '\a' is different in traditional Cthe meaning of '\x' is different in traditional Cthe right operand of "%s" changes sign when promotedthis is the location of the previous definitionthis use of "defined" may not be portabletraditional C ignores #%s with the # indentedtraditional C rejects the "%.*s" suffixtraditional C rejects the unary plus operatortrigraph ??%c converted to %ctrigraph ??%c ignored, use -trigraphs to enableunbalanced stack in %sundefining "%s"unexpected end of file after #lineuniversal character %.*s is not valid at the start of an identifieruniversal character %.*s is not valid in an identifieruniversal character names are only valid in C++ and C99unknown escape sequence: '\%c'unknown escape sequence: '\%s'unspellable token %sunterminated #%sunterminated argument list invoking macro "%s"unterminated commentunterminated raw stringuse -Winvalid-pch for more informationuse of C99 hexadecimal floating constantwhile reading precompiled headerwhile writing precompiled headerProject-Id-Version: cpplib 4.5-b20100204
*************** Last-Translator: Arif E. Nugroho 
  Language: id
  MIME-Version: 1.0
! Content-Type: text/plain; charset=ISO-8859-1
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  "%s" setelah # bukan sebuah integer positif"%s" setelah #line bukan sebuah integer positif"%s" tidak dapat digunakan sebagai sebuah nama makro karena ini adalah sebuah operator dalam C++"%s" bukan sebuah nama berkas yang valid"%s" re-asserted"%s" redefinisi"/*" di dalam komentar#%s diduga "NAMA BERKAS" atau #%s adalah sebuah ekstensi GCC#%s adalah sebuah ekstensi GCC yang sudah ditinggalkan#else setelah #else#else tanpa #if#endif tanpa #if#include_next dalam berkas kode program utama#pragma %s %s telah terdaftar#pragma %s telah terdaftar#pragma sekali dalam berkas utama#pragma system_header diabaikan diluar berkas include%.*s bukan sebuah karakter universal yang valid%s%s dalam direktif preprosesing%s adalah sebuah perangkat blok%s lebih pendek dari yang diduga%s terlalu besar%s: %s%s: tidak digunakan karena `%.*s' didefinisikan sebagai `%s' bukan `%.*s'%s: tidak digunakan karena `%.*s' teracuni%s: tidak digunakan karena `%.*s' tidak didefinisikan%s: tidak digunakan karena `%s' didefinisikan%s: tidak digunakan karena `__COUNTER__' tidak valid'##' tidak dapat muncul baik diakhir dari sebuah ekspansi makro'#' tidak diikuti dengan sebuah parameter makro'$' dalam identifier atau angka'?' tanpa diikuti ':'("%s" adalah sebuah tanda alternatif untuk "%s" dalam C++)(ini hanya akan dilaporkan sekali setiap berkas masukan)komentar gaya C++ tidak diijinkan dalam ISO C90aritmetik CPP harus paling tidak sama tepatnya dengan sebuah target intCPP integer-setengah lebih kecil dari karakter CPPCPP di host ini tidak dapat menangani konstanta karakter lebar diatas %lu bits, tetapi target membutuhkan %lu bitsISO C tidak mengijinkan makro variadik bernamaISO C99 membutuhkan whitespace setelah nama makroDalam _cpp_valid_ucn tetapi bukan sebuah UCNMultiple include guards mungkin berguna untuk:
--- 11,17 ----
  Language-Team: Indonesian 
  Language: id
  MIME-Version: 1.0
! Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  "%s" setelah # bukan sebuah integer positif"%s" setelah #line bukan sebuah integer positif"%s" tidak dapat digunakan sebagai sebuah nama makro karena ini adalah sebuah operator dalam C++"%s" bukan sebuah nama berkas yang valid"%s" re-asserted"%s" redefinisi"/*" di dalam komentar#%s diduga "NAMA BERKAS" atau #%s adalah sebuah ekstensi GCC#%s adalah sebuah ekstensi GCC yang sudah ditinggalkan#else setelah #else#else tanpa #if#endif tanpa #if#include_next dalam berkas kode program utama#pragma %s %s telah terdaftar#pragma %s telah terdaftar#pragma sekali dalam berkas utama#pragma system_header diabaikan diluar berkas include%.*s bukan sebuah karakter universal yang valid%s%s dalam direktif preprosesing%s adalah sebuah perangkat blok%s lebih pendek dari yang diduga%s terlalu besar%s: %s%s: tidak digunakan karena `%.*s' didefinisikan sebagai `%s' bukan `%.*s'%s: tidak digunakan karena `%.*s' teracuni%s: tidak digunakan karena `%.*s' tidak didefinisikan%s: tidak digunakan karena `%s' didefinisikan%s: tidak digunakan karena `__COUNTER__' tidak valid'##' tidak dapat muncul baik diakhir dari sebuah ekspansi makro'#' tidak diikuti dengan sebuah parameter makro'$' dalam identifier atau angka'?' tanpa diikuti ':'("%s" adalah sebuah tanda alternatif untuk "%s" dalam C++)(ini hanya akan dilaporkan sekali setiap berkas masukan)komentar gaya C++ tidak diijinkan dalam ISO C90aritmetik CPP harus paling tidak sama tepatnya dengan sebuah target intCPP integer-setengah lebih kecil dari karakter CPPCPP di host ini tidak dapat menangani konstanta karakter lebar diatas %lu bits, tetapi target membutuhkan %lu bitsISO C tidak mengijinkan makro variadik bernamaISO C99 membutuhkan whitespace setelah nama makroDalam _cpp_valid_ucn tetapi bukan sebuah UCNMultiple include guards mungkin berguna untuk:
diff -Nrcpad gcc-13.4.0/libcpp/po/zh_CN.gmo gcc-13.5.0-RC-20260904/libcpp/po/zh_CN.gmo
*** gcc-13.4.0/libcpp/po/zh_CN.gmo	Thu Jun  5 16:21:33 2025
--- gcc-13.5.0-RC-20260904/libcpp/po/zh_CN.gmo	Fri Sep  4 07:50:20 2026
*************** Last-Translator: Meng Jie 
  Language: zh_CN
  MIME-Version: 1.0
! Content-Type: text/plain; charset=utf-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  X-Poedit-Language: Chinese
--- 11,17 ----
  Language-Team: Chinese (simplified) 
  Language: zh_CN
  MIME-Version: 1.0
! Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  X-Bugs: Report translation errors to the Language-Team address.
  X-Poedit-Language: Chinese
diff -Nrcpad gcc-13.4.0/libffi/doc/libffi.info gcc-13.5.0-RC-20260904/libffi/doc/libffi.info
*** gcc-13.4.0/libffi/doc/libffi.info	Thu Jun  5 16:30:35 2025
--- gcc-13.5.0-RC-20260904/libffi/doc/libffi.info	Fri Sep  4 07:57:53 2026
***************
*** 1,9 ****
! This is libffi.info, produced by makeinfo version 6.8 from libffi.texi.
  
  This manual is for libffi, a portable foreign function interface
  library.
  
!    Copyright (C) 2008-2019, 2021 Anthony Green and Red Hat, Inc.
  
     Permission is hereby granted, free of charge, to any person obtaining
  a copy of this software and associated documentation files (the
--- 1,9 ----
! This is libffi.info, produced by makeinfo version 7.1 from libffi.texi.
  
  This manual is for libffi, a portable foreign function interface
  library.
  
!    Copyright © 2008-2019, 2021 Anthony Green and Red Hat, Inc.
  
     Permission is hereby granted, free of charge, to any person obtaining
  a copy of this software and associated documentation files (the
*************** libffi
*** 38,44 ****
  This manual is for libffi, a portable foreign function interface
  library.
  
!    Copyright (C) 2008-2019, 2021 Anthony Green and Red Hat, Inc.
  
     Permission is hereby granted, free of charge, to any person obtaining
  a copy of this software and associated documentation files (the
--- 38,44 ----
  This manual is for libffi, a portable foreign function interface
  library.
  
!    Copyright © 2008-2019, 2021 Anthony Green and Red Hat, Inc.
  
     Permission is hereby granted, free of charge, to any person obtaining
  a copy of this software and associated documentation files (the
*************** File: libffi.info,  Node: Introduction,
*** 75,103 ****
  
  Compilers for high level languages generate code that follow certain
  conventions.  These conventions are necessary, in part, for separate
! compilation to work.  One such convention is the "calling convention".
  The calling convention is a set of assumptions made by the compiler
  about where function arguments will be found on entry to a function.  A
  calling convention also specifies where the return value for a function
! is found.  The calling convention is also sometimes called the "ABI" or
! "Application Binary Interface".
  
     Some programs may not know at the time of compilation what arguments
  are to be passed to a function.  For instance, an interpreter may be
  told at run-time about the number and types of arguments used to call a
! given function.  'Libffi' can be used in such programs to provide a
  bridge from the interpreter program to compiled code.
  
!    The 'libffi' library provides a portable, high level programming
  interface to various calling conventions.  This allows a programmer to
  call any function specified by a call interface description at run time.
  
     FFI stands for Foreign Function Interface.  A foreign function
  interface is the popular name for the interface that allows code written
! in one language to call code written in another language.  The 'libffi'
  library really only provides the lowest, machine dependent layer of a
  fully featured foreign function interface.  A layer must exist above
! 'libffi' that handles type conversions for values passed between the two
  languages.
  
  
--- 75,103 ----
  
  Compilers for high level languages generate code that follow certain
  conventions.  These conventions are necessary, in part, for separate
! compilation to work.  One such convention is the “calling convention”.
  The calling convention is a set of assumptions made by the compiler
  about where function arguments will be found on entry to a function.  A
  calling convention also specifies where the return value for a function
! is found.  The calling convention is also sometimes called the “ABI” or
! “Application Binary Interface”.
  
     Some programs may not know at the time of compilation what arguments
  are to be passed to a function.  For instance, an interpreter may be
  told at run-time about the number and types of arguments used to call a
! given function.  ‘Libffi’ can be used in such programs to provide a
  bridge from the interpreter program to compiled code.
  
!    The ‘libffi’ library provides a portable, high level programming
  interface to various calling conventions.  This allows a programmer to
  call any function specified by a call interface description at run time.
  
     FFI stands for Foreign Function Interface.  A foreign function
  interface is the popular name for the interface that allows code written
! in one language to call code written in another language.  The ‘libffi’
  library really only provides the lowest, machine dependent layer of a
  fully featured foreign function interface.  A layer must exist above
! ‘libffi’ that handles type conversions for values passed between the two
  languages.
  
  
*************** File: libffi.info,  Node: The Basics,  N
*** 122,166 ****
  2.1 The Basics
  ==============
  
! 'Libffi' assumes that you have a pointer to the function you wish to
  call and that you know the number and types of arguments to pass it, as
  well as the return type of the function.
  
!    The first thing you must do is create an 'ffi_cif' object that
  matches the signature of the function you wish to call.  This is a
  separate step because it is common to make multiple calls using a single
! 'ffi_cif'.  The "cif" in 'ffi_cif' stands for Call InterFace.  To
! prepare a call interface object, use the function 'ffi_prep_cif'.
  
   -- Function: ffi_status ffi_prep_cif (ffi_cif *CIF, ffi_abi ABI,
            unsigned int NARGS, ffi_type *RTYPE, ffi_type **ARGTYPES)
       This initializes CIF according to the given parameters.
  
!      ABI is the ABI to use; normally 'FFI_DEFAULT_ABI' is what you want.
       *note Multiple ABIs:: for more information.
  
       NARGS is the number of arguments that this function accepts.
  
!      RTYPE is a pointer to an 'ffi_type' structure that describes the
       return type of the function.  *Note Types::.
  
!      ARGTYPES is a vector of 'ffi_type' pointers.  ARGTYPES must have
       NARGS elements.  If NARGS is 0, this argument is ignored.
  
!      'ffi_prep_cif' returns a 'libffi' status code, of type
!      'ffi_status'.  This will be either 'FFI_OK' if everything worked
!      properly; 'FFI_BAD_TYPEDEF' if one of the 'ffi_type' objects is
!      incorrect; or 'FFI_BAD_ABI' if the ABI parameter is invalid.
  
     If the function being called is variadic (varargs) then
! 'ffi_prep_cif_var' must be used instead of 'ffi_prep_cif'.
  
   -- Function: ffi_status ffi_prep_cif_var (ffi_cif *CIF, ffi_abi ABI,
            unsigned int NFIXEDARGS, unsigned int NTOTALARGS, ffi_type
            *RTYPE, ffi_type **ARGTYPES)
       This initializes CIF according to the given parameters for a call
       to a variadic function.  In general its operation is the same as
!      for 'ffi_prep_cif' except that:
  
       NFIXEDARGS is the number of fixed arguments, prior to any variadic
       arguments.  It must be greater than zero.
--- 122,166 ----
  2.1 The Basics
  ==============
  
! ‘Libffi’ assumes that you have a pointer to the function you wish to
  call and that you know the number and types of arguments to pass it, as
  well as the return type of the function.
  
!    The first thing you must do is create an ‘ffi_cif’ object that
  matches the signature of the function you wish to call.  This is a
  separate step because it is common to make multiple calls using a single
! ‘ffi_cif’.  The “cif” in ‘ffi_cif’ stands for Call InterFace.  To
! prepare a call interface object, use the function ‘ffi_prep_cif’.
  
   -- Function: ffi_status ffi_prep_cif (ffi_cif *CIF, ffi_abi ABI,
            unsigned int NARGS, ffi_type *RTYPE, ffi_type **ARGTYPES)
       This initializes CIF according to the given parameters.
  
!      ABI is the ABI to use; normally ‘FFI_DEFAULT_ABI’ is what you want.
       *note Multiple ABIs:: for more information.
  
       NARGS is the number of arguments that this function accepts.
  
!      RTYPE is a pointer to an ‘ffi_type’ structure that describes the
       return type of the function.  *Note Types::.
  
!      ARGTYPES is a vector of ‘ffi_type’ pointers.  ARGTYPES must have
       NARGS elements.  If NARGS is 0, this argument is ignored.
  
!      ‘ffi_prep_cif’ returns a ‘libffi’ status code, of type
!      ‘ffi_status’.  This will be either ‘FFI_OK’ if everything worked
!      properly; ‘FFI_BAD_TYPEDEF’ if one of the ‘ffi_type’ objects is
!      incorrect; or ‘FFI_BAD_ABI’ if the ABI parameter is invalid.
  
     If the function being called is variadic (varargs) then
! ‘ffi_prep_cif_var’ must be used instead of ‘ffi_prep_cif’.
  
   -- Function: ffi_status ffi_prep_cif_var (ffi_cif *CIF, ffi_abi ABI,
            unsigned int NFIXEDARGS, unsigned int NTOTALARGS, ffi_type
            *RTYPE, ffi_type **ARGTYPES)
       This initializes CIF according to the given parameters for a call
       to a variadic function.  In general its operation is the same as
!      for ‘ffi_prep_cif’ except that:
  
       NFIXEDARGS is the number of fixed arguments, prior to any variadic
       arguments.  It must be greater than zero.
*************** prepare a call interface object, use the
*** 168,216 ****
       NTOTALARGS the total number of arguments, including variadic and
       fixed arguments.  ARGTYPES must have this many elements.
  
!      'ffi_prep_cif_var' will return 'FFI_BAD_ARGTYPE' if any of the
!      variable argument types are 'ffi_type_float' (promote to
!      'ffi_type_double' first), or any integer type small than an int
       (promote to an int-sized type first).
  
       Note that, different cif's must be prepped for calls to the same
       function when different numbers of arguments are passed.
  
!      Also note that a call to 'ffi_prep_cif_var' with
       NFIXEDARGS=NOTOTALARGS is NOT equivalent to a call to
!      'ffi_prep_cif'.
  
!    Note that the resulting 'ffi_cif' holds pointers to all the
! 'ffi_type' objects that were used during initialization.  You must
  ensure that these type objects have a lifetime at least as long as that
! of the 'ffi_cif'.
  
!    To call a function using an initialized 'ffi_cif', use the 'ffi_call'
  function:
  
   -- Function: void ffi_call (ffi_cif *CIF, void *FN, void *RVALUE, void
            **AVALUES)
       This calls the function FN according to the description given in
!      CIF.  CIF must have already been prepared using 'ffi_prep_cif'.
  
       RVALUE is a pointer to a chunk of memory that will hold the result
       of the function call.  This must be large enough to hold the
       result, no smaller than the system register size (generally 32 or
       64 bits), and must be suitably aligned; it is the caller's
       responsibility to ensure this.  If CIF declares that the function
!      returns 'void' (using 'ffi_type_void'), then RVALUE is ignored.
  
!      In most situations, 'libffi' will handle promotion according to the
       ABI. However, for historical reasons, there is a special case with
       return values that must be handled by your code.  In particular,
!      for integral (not 'struct') types that are narrower than the system
!      register size, the return value will be widened by 'libffi'.
!      'libffi' provides a type, 'ffi_arg', that can be used as the return
       type.  For example, if the CIF was defined with a return type of
!      'char', 'libffi' will try to store a full 'ffi_arg' into the return
       value.
  
!      AVALUES is a vector of 'void *' pointers that point to the memory
       locations holding the argument values for a call.  If CIF declares
       that the function has no arguments (i.e., NARGS was 0), then
       AVALUES is ignored.  Note that argument values may be modified by
--- 168,216 ----
       NTOTALARGS the total number of arguments, including variadic and
       fixed arguments.  ARGTYPES must have this many elements.
  
!      ‘ffi_prep_cif_var’ will return ‘FFI_BAD_ARGTYPE’ if any of the
!      variable argument types are ‘ffi_type_float’ (promote to
!      ‘ffi_type_double’ first), or any integer type small than an int
       (promote to an int-sized type first).
  
       Note that, different cif's must be prepped for calls to the same
       function when different numbers of arguments are passed.
  
!      Also note that a call to ‘ffi_prep_cif_var’ with
       NFIXEDARGS=NOTOTALARGS is NOT equivalent to a call to
!      ‘ffi_prep_cif’.
  
!    Note that the resulting ‘ffi_cif’ holds pointers to all the
! ‘ffi_type’ objects that were used during initialization.  You must
  ensure that these type objects have a lifetime at least as long as that
! of the ‘ffi_cif’.
  
!    To call a function using an initialized ‘ffi_cif’, use the ‘ffi_call’
  function:
  
   -- Function: void ffi_call (ffi_cif *CIF, void *FN, void *RVALUE, void
            **AVALUES)
       This calls the function FN according to the description given in
!      CIF.  CIF must have already been prepared using ‘ffi_prep_cif’.
  
       RVALUE is a pointer to a chunk of memory that will hold the result
       of the function call.  This must be large enough to hold the
       result, no smaller than the system register size (generally 32 or
       64 bits), and must be suitably aligned; it is the caller's
       responsibility to ensure this.  If CIF declares that the function
!      returns ‘void’ (using ‘ffi_type_void’), then RVALUE is ignored.
  
!      In most situations, ‘libffi’ will handle promotion according to the
       ABI. However, for historical reasons, there is a special case with
       return values that must be handled by your code.  In particular,
!      for integral (not ‘struct’) types that are narrower than the system
!      register size, the return value will be widened by ‘libffi’.
!      ‘libffi’ provides a type, ‘ffi_arg’, that can be used as the return
       type.  For example, if the CIF was defined with a return type of
!      ‘char’, ‘libffi’ will try to store a full ‘ffi_arg’ into the return
       value.
  
!      AVALUES is a vector of ‘void *’ pointers that point to the memory
       locations holding the argument values for a call.  If CIF declares
       that the function has no arguments (i.e., NARGS was 0), then
       AVALUES is ignored.  Note that argument values may be modified by
*************** function:
*** 219,228 ****
  
       Note that while the return value must be register-sized, arguments
       should exactly match their declared type.  For example, if an
!      argument is a 'short', then the entry in AVALUES should point to an
!      object declared as 'short'; but if the return type is 'short', then
       RVALUE should point to an object declared as a larger type -
!      usually 'ffi_arg'.
  
  
  File: libffi.info,  Node: Simple Example,  Next: Types,  Prev: The Basics,  Up: Using libffi
--- 219,228 ----
  
       Note that while the return value must be register-sized, arguments
       should exactly match their declared type.  For example, if an
!      argument is a ‘short’, then the entry in AVALUES should point to an
!      object declared as ‘short’; but if the return type is ‘short’, then
       RVALUE should point to an object declared as a larger type -
!      usually ‘ffi_arg’.
  
  
  File: libffi.info,  Node: Simple Example,  Next: Types,  Prev: The Basics,  Up: Using libffi
*************** File: libffi.info,  Node: Simple Example
*** 230,236 ****
  2.2 Simple Example
  ==================
  
! Here is a trivial example that calls 'puts' a few times.
  
       #include 
       #include 
--- 230,236 ----
  2.2 Simple Example
  ==================
  
! Here is a trivial example that calls ‘puts’ a few times.
  
       #include 
       #include 
*************** File: libffi.info,  Node: Primitive Type
*** 287,377 ****
  2.3.1 Primitive Types
  ---------------------
  
! 'Libffi' provides a number of built-in type descriptors that can be used
  to describe argument and return types:
  
! 'ffi_type_void'
!      The type 'void'.  This cannot be used for argument types, only for
       return values.
  
! 'ffi_type_uint8'
       An unsigned, 8-bit integer type.
  
! 'ffi_type_sint8'
       A signed, 8-bit integer type.
  
! 'ffi_type_uint16'
       An unsigned, 16-bit integer type.
  
! 'ffi_type_sint16'
       A signed, 16-bit integer type.
  
! 'ffi_type_uint32'
       An unsigned, 32-bit integer type.
  
! 'ffi_type_sint32'
       A signed, 32-bit integer type.
  
! 'ffi_type_uint64'
       An unsigned, 64-bit integer type.
  
! 'ffi_type_sint64'
       A signed, 64-bit integer type.
  
! 'ffi_type_float'
!      The C 'float' type.
  
! 'ffi_type_double'
!      The C 'double' type.
  
! 'ffi_type_uchar'
!      The C 'unsigned char' type.
  
! 'ffi_type_schar'
!      The C 'signed char' type.  (Note that there is not an exact
!      equivalent to the C 'char' type in 'libffi'; ordinarily you should
!      either use 'ffi_type_schar' or 'ffi_type_uchar' depending on
!      whether 'char' is signed.)
  
! 'ffi_type_ushort'
!      The C 'unsigned short' type.
  
! 'ffi_type_sshort'
!      The C 'short' type.
  
! 'ffi_type_uint'
!      The C 'unsigned int' type.
  
! 'ffi_type_sint'
!      The C 'int' type.
  
! 'ffi_type_ulong'
!      The C 'unsigned long' type.
  
! 'ffi_type_slong'
!      The C 'long' type.
  
! 'ffi_type_longdouble'
!      On platforms that have a C 'long double' type, this is defined.  On
       other platforms, it is not.
  
! 'ffi_type_pointer'
!      A generic 'void *' pointer.  You should use this for all pointers,
       regardless of their real type.
  
! 'ffi_type_complex_float'
!      The C '_Complex float' type.
  
! 'ffi_type_complex_double'
!      The C '_Complex double' type.
  
! 'ffi_type_complex_longdouble'
!      The C '_Complex long double' type.  On platforms that have a C
!      'long double' type, this is defined.  On other platforms, it is
       not.
  
!    Each of these is of type 'ffi_type', so you must take the address
! when passing to 'ffi_prep_cif'.
  
  
  File: libffi.info,  Node: Structures,  Next: Size and Alignment,  Prev: Primitive Types,  Up: Types
--- 287,377 ----
  2.3.1 Primitive Types
  ---------------------
  
! ‘Libffi’ provides a number of built-in type descriptors that can be used
  to describe argument and return types:
  
! ‘ffi_type_void’
!      The type ‘void’.  This cannot be used for argument types, only for
       return values.
  
! ‘ffi_type_uint8’
       An unsigned, 8-bit integer type.
  
! ‘ffi_type_sint8’
       A signed, 8-bit integer type.
  
! ‘ffi_type_uint16’
       An unsigned, 16-bit integer type.
  
! ‘ffi_type_sint16’
       A signed, 16-bit integer type.
  
! ‘ffi_type_uint32’
       An unsigned, 32-bit integer type.
  
! ‘ffi_type_sint32’
       A signed, 32-bit integer type.
  
! ‘ffi_type_uint64’
       An unsigned, 64-bit integer type.
  
! ‘ffi_type_sint64’
       A signed, 64-bit integer type.
  
! ‘ffi_type_float’
!      The C ‘float’ type.
  
! ‘ffi_type_double’
!      The C ‘double’ type.
  
! ‘ffi_type_uchar’
!      The C ‘unsigned char’ type.
  
! ‘ffi_type_schar’
!      The C ‘signed char’ type.  (Note that there is not an exact
!      equivalent to the C ‘char’ type in ‘libffi’; ordinarily you should
!      either use ‘ffi_type_schar’ or ‘ffi_type_uchar’ depending on
!      whether ‘char’ is signed.)
  
! ‘ffi_type_ushort’
!      The C ‘unsigned short’ type.
  
! ‘ffi_type_sshort’
!      The C ‘short’ type.
  
! ‘ffi_type_uint’
!      The C ‘unsigned int’ type.
  
! ‘ffi_type_sint’
!      The C ‘int’ type.
  
! ‘ffi_type_ulong’
!      The C ‘unsigned long’ type.
  
! ‘ffi_type_slong’
!      The C ‘long’ type.
  
! ‘ffi_type_longdouble’
!      On platforms that have a C ‘long double’ type, this is defined.  On
       other platforms, it is not.
  
! ‘ffi_type_pointer’
!      A generic ‘void *’ pointer.  You should use this for all pointers,
       regardless of their real type.
  
! ‘ffi_type_complex_float’
!      The C ‘_Complex float’ type.
  
! ‘ffi_type_complex_double’
!      The C ‘_Complex double’ type.
  
! ‘ffi_type_complex_longdouble’
!      The C ‘_Complex long double’ type.  On platforms that have a C
!      ‘long double’ type, this is defined.  On other platforms, it is
       not.
  
!    Each of these is of type ‘ffi_type’, so you must take the address
! when passing to ‘ffi_prep_cif’.
  
  
  File: libffi.info,  Node: Structures,  Next: Size and Alignment,  Prev: Primitive Types,  Up: Types
*************** File: libffi.info,  Node: Structures,  N
*** 379,408 ****
  2.3.2 Structures
  ----------------
  
! 'libffi' is perfectly happy passing structures back and forth.  You must
! first describe the structure to 'libffi' by creating a new 'ffi_type'
  object for it.
  
   -- Data type: ffi_type
!      The 'ffi_type' has the following members:
!      'size_t size'
!           This is set by 'libffi'; you should initialize it to zero.
  
!      'unsigned short alignment'
!           This is set by 'libffi'; you should initialize it to zero.
  
!      'unsigned short type'
!           For a structure, this should be set to 'FFI_TYPE_STRUCT'.
  
!      'ffi_type **elements'
!           This is a 'NULL'-terminated array of pointers to 'ffi_type'
            objects.  There is one element per field of the struct.
  
!           Note that 'libffi' has no special support for bit-fields.  You
            must manage these manually.
  
!    The 'size' and 'alignment' fields will be filled in by 'ffi_prep_cif'
! or 'ffi_prep_cif_var', as needed.
  
  
  File: libffi.info,  Node: Size and Alignment,  Next: Arrays Unions Enums,  Prev: Structures,  Up: Types
--- 379,408 ----
  2.3.2 Structures
  ----------------
  
! ‘libffi’ is perfectly happy passing structures back and forth.  You must
! first describe the structure to ‘libffi’ by creating a new ‘ffi_type’
  object for it.
  
   -- Data type: ffi_type
!      The ‘ffi_type’ has the following members:
!      ‘size_t size’
!           This is set by ‘libffi’; you should initialize it to zero.
  
!      ‘unsigned short alignment’
!           This is set by ‘libffi’; you should initialize it to zero.
  
!      ‘unsigned short type’
!           For a structure, this should be set to ‘FFI_TYPE_STRUCT’.
  
!      ‘ffi_type **elements’
!           This is a ‘NULL’-terminated array of pointers to ‘ffi_type’
            objects.  There is one element per field of the struct.
  
!           Note that ‘libffi’ has no special support for bit-fields.  You
            must manage these manually.
  
!    The ‘size’ and ‘alignment’ fields will be filled in by ‘ffi_prep_cif’
! or ‘ffi_prep_cif_var’, as needed.
  
  
  File: libffi.info,  Node: Size and Alignment,  Next: Arrays Unions Enums,  Prev: Structures,  Up: Types
*************** File: libffi.info,  Node: Size and Align
*** 410,433 ****
  2.3.3 Size and Alignment
  ------------------------
  
! 'libffi' will set the 'size' and 'alignment' fields of an 'ffi_type'
  object for you.  It does so using its knowledge of the ABI.
  
     You might expect that you can simply read these fields for a type
! that has been laid out by 'libffi'.  However, there are some caveats.
  
!    * The size or alignment of some of the built-in types may vary
       depending on the chosen ABI.
  
!    * The size and alignment of a new structure type will not be set by
!      'libffi' until it has been passed to 'ffi_prep_cif' or
!      'ffi_get_struct_offsets'.
  
!    * A structure type cannot be shared across ABIs.  Instead each ABI
       needs its own copy of the structure type.
  
     So, before examining these fields, it is safest to pass the
! 'ffi_type' object to 'ffi_prep_cif' or 'ffi_get_struct_offsets' first.
  This function will do all the needed setup.
  
       ffi_type *desired_type;
--- 410,433 ----
  2.3.3 Size and Alignment
  ------------------------
  
! ‘libffi’ will set the ‘size’ and ‘alignment’ fields of an ‘ffi_type’
  object for you.  It does so using its knowledge of the ABI.
  
     You might expect that you can simply read these fields for a type
! that has been laid out by ‘libffi’.  However, there are some caveats.
  
!    • The size or alignment of some of the built-in types may vary
       depending on the chosen ABI.
  
!    • The size and alignment of a new structure type will not be set by
!      ‘libffi’ until it has been passed to ‘ffi_prep_cif’ or
!      ‘ffi_get_struct_offsets’.
  
!    • A structure type cannot be shared across ABIs.  Instead each ABI
       needs its own copy of the structure type.
  
     So, before examining these fields, it is safest to pass the
! ‘ffi_type’ object to ‘ffi_prep_cif’ or ‘ffi_get_struct_offsets’ first.
  This function will do all the needed setup.
  
       ffi_type *desired_type;
*************** This function will do all the needed set
*** 440,446 ****
           unsigned short alignment = desired_type->alignment;
         }
  
!    'libffi' also provides a way to get the offsets of the members of a
  structure.
  
   -- Function: ffi_status ffi_get_struct_offsets (ffi_abi abi, ffi_type
--- 440,446 ----
           unsigned short alignment = desired_type->alignment;
         }
  
!    ‘libffi’ also provides a way to get the offsets of the members of a
  structure.
  
   -- Function: ffi_status ffi_get_struct_offsets (ffi_abi abi, ffi_type
*************** structure.
*** 451,464 ****
  
       OFFSETS is an out parameter.  The caller is responsible for
       providing enough space for all the results to be written - one
!      element per element type in STRUCT_TYPE.  If OFFSETS is 'NULL',
       then the type will be laid out but not otherwise modified.  This
       can be useful for accessing the type's size or layout, as mentioned
       above.
  
!      This function returns 'FFI_OK' on success; 'FFI_BAD_ABI' if ABI is
!      invalid; or 'FFI_BAD_TYPEDEF' if STRUCT_TYPE is invalid in some
!      way.  Note that only 'FFI_STRUCT' types are valid here.
  
  
  File: libffi.info,  Node: Arrays Unions Enums,  Next: Type Example,  Prev: Size and Alignment,  Up: Types
--- 451,464 ----
  
       OFFSETS is an out parameter.  The caller is responsible for
       providing enough space for all the results to be written - one
!      element per element type in STRUCT_TYPE.  If OFFSETS is ‘NULL’,
       then the type will be laid out but not otherwise modified.  This
       can be useful for accessing the type's size or layout, as mentioned
       above.
  
!      This function returns ‘FFI_OK’ on success; ‘FFI_BAD_ABI’ if ABI is
!      invalid; or ‘FFI_BAD_TYPEDEF’ if STRUCT_TYPE is invalid in some
!      way.  Note that only ‘FFI_STRUCT’ types are valid here.
  
  
  File: libffi.info,  Node: Arrays Unions Enums,  Next: Type Example,  Prev: Size and Alignment,  Up: Types
*************** File: libffi.info,  Node: Arrays Unions
*** 469,479 ****
  2.3.4.1 Arrays
  ..............
  
! 'libffi' does not have direct support for arrays or unions.  However,
  they can be emulated using structures.
  
!    To emulate an array, simply create an 'ffi_type' using
! 'FFI_TYPE_STRUCT' with as many members as there are elements in the
  array.
  
       ffi_type array_type;
--- 469,479 ----
  2.3.4.1 Arrays
  ..............
  
! ‘libffi’ does not have direct support for arrays or unions.  However,
  they can be emulated using structures.
  
!    To emulate an array, simply create an ‘ffi_type’ using
! ‘FFI_TYPE_STRUCT’ with as many members as there are elements in the
  array.
  
       ffi_type array_type;
*************** array.
*** 491,506 ****
  
     Note that arrays cannot be passed or returned by value in C -
  structure types created like this should only be used to refer to
! members of real 'FFI_TYPE_STRUCT' objects.
  
     However, a phony array type like this will not cause any errors from
! 'libffi' if you use it as an argument or return type.  This may be
  confusing.
  
  2.3.4.2 Unions
  ..............
  
! A union can also be emulated using 'FFI_TYPE_STRUCT'.  In this case,
  however, you must make sure that the size and alignment match the real
  requirements of the union.
  
--- 491,506 ----
  
     Note that arrays cannot be passed or returned by value in C -
  structure types created like this should only be used to refer to
! members of real ‘FFI_TYPE_STRUCT’ objects.
  
     However, a phony array type like this will not cause any errors from
! ‘libffi’ if you use it as an argument or return type.  This may be
  confusing.
  
  2.3.4.2 Unions
  ..............
  
! A union can also be emulated using ‘FFI_TYPE_STRUCT’.  In this case,
  however, you must make sure that the size and alignment match the real
  requirements of the union.
  
*************** requirements of the union.
*** 508,514 ****
  out.  Then, give the new structure type a single element; the size of
  the largest element; and the largest alignment seen as well.
  
!    This example uses the 'ffi_prep_cif' trick to ensure that each
  element type is laid out.
  
       ffi_abi desired_abi;
--- 508,514 ----
  out.  Then, give the new structure type a single element; the size of
  the largest element; and the largest alignment seen as well.
  
!    This example uses the ‘ffi_prep_cif’ trick to ensure that each
  element type is laid out.
  
       ffi_abi desired_abi;
*************** element type is laid out.
*** 542,552 ****
  2.3.4.3 Enumerations
  ....................
  
! 'libffi' does not have any special support for C 'enum's.  Although any
! given 'enum' is implemented using a specific underlying integral type,
! exactly which type will be used cannot be determined by 'libffi' - it
  may depend on the values in the enumeration or on compiler flags such as
! '-fshort-enums'.  *Note (gcc)Structures unions enumerations and
  bit-fields implementation::, for more information about how GCC handles
  enumerations.
  
--- 542,552 ----
  2.3.4.3 Enumerations
  ....................
  
! ‘libffi’ does not have any special support for C ‘enum’s.  Although any
! given ‘enum’ is implemented using a specific underlying integral type,
! exactly which type will be used cannot be determined by ‘libffi’ - it
  may depend on the values in the enumeration or on compiler flags such as
! ‘-fshort-enums’.  *Note (gcc)Structures unions enumerations and
  bit-fields implementation::, for more information about how GCC handles
  enumerations.
  
*************** File: libffi.info,  Node: Type Example,
*** 556,563 ****
  2.3.5 Type Example
  ------------------
  
! The following example initializes a 'ffi_type' object representing the
! 'tm' struct from Linux's 'time.h'.
  
     Here is how the struct is defined:
  
--- 556,563 ----
  2.3.5 Type Example
  ------------------
  
! The following example initializes a ‘ffi_type’ object representing the
! ‘tm’ struct from Linux's ‘time.h’.
  
     Here is how the struct is defined:
  
*************** The following example initializes a 'ffi
*** 576,582 ****
           __const char *__tm_zone__;
       };
  
!    Here is the corresponding code to describe this struct to 'libffi':
  
           {
             ffi_type tm_type;
--- 576,582 ----
           __const char *__tm_zone__;
       };
  
!    Here is the corresponding code to describe this struct to ‘libffi’:
  
           {
             ffi_type tm_type;
*************** File: libffi.info,  Node: Complex,  Next
*** 604,641 ****
  2.3.6 Complex Types
  -------------------
  
! 'libffi' supports the complex types defined by the C99 standard
! ('_Complex float', '_Complex double' and '_Complex long double' with the
! built-in type descriptors 'ffi_type_complex_float',
! 'ffi_type_complex_double' and 'ffi_type_complex_longdouble'.
  
!    Custom complex types like '_Complex int' can also be used.  An
! 'ffi_type' object has to be defined to describe the complex type to
! 'libffi'.
  
   -- Data type: ffi_type
!      'size_t size'
            This must be manually set to the size of the complex type.
  
!      'unsigned short alignment'
            This must be manually set to the alignment of the complex
            type.
  
!      'unsigned short type'
!           For a complex type, this must be set to 'FFI_TYPE_COMPLEX'.
  
!      'ffi_type **elements'
  
!           This is a 'NULL'-terminated array of pointers to 'ffi_type'
!           objects.  The first element is set to the 'ffi_type' of the
            complex's base type.  The second element must be set to
!           'NULL'.
  
     The section *note Complex Type Example:: shows a way to determine the
! 'size' and 'alignment' members in a platform independent way.
  
!    For platforms that have no complex support in 'libffi' yet, the
! functions 'ffi_prep_cif' and 'ffi_prep_args' abort the program if they
  encounter a complex type.
  
  
--- 604,641 ----
  2.3.6 Complex Types
  -------------------
  
! ‘libffi’ supports the complex types defined by the C99 standard
! (‘_Complex float’, ‘_Complex double’ and ‘_Complex long double’ with the
! built-in type descriptors ‘ffi_type_complex_float’,
! ‘ffi_type_complex_double’ and ‘ffi_type_complex_longdouble’.
  
!    Custom complex types like ‘_Complex int’ can also be used.  An
! ‘ffi_type’ object has to be defined to describe the complex type to
! ‘libffi’.
  
   -- Data type: ffi_type
!      ‘size_t size’
            This must be manually set to the size of the complex type.
  
!      ‘unsigned short alignment’
            This must be manually set to the alignment of the complex
            type.
  
!      ‘unsigned short type’
!           For a complex type, this must be set to ‘FFI_TYPE_COMPLEX’.
  
!      ‘ffi_type **elements’
  
!           This is a ‘NULL’-terminated array of pointers to ‘ffi_type’
!           objects.  The first element is set to the ‘ffi_type’ of the
            complex's base type.  The second element must be set to
!           ‘NULL’.
  
     The section *note Complex Type Example:: shows a way to determine the
! ‘size’ and ‘alignment’ members in a platform independent way.
  
!    For platforms that have no complex support in ‘libffi’ yet, the
! functions ‘ffi_prep_cif’ and ‘ffi_prep_args’ abort the program if they
  encounter a complex type.
  
  
*************** File: libffi.info,  Node: Multiple ABIs,
*** 732,740 ****
  =================
  
  A given platform may provide multiple different ABIs at once.  For
! instance, the x86 platform has both 'stdcall' and 'fastcall' functions.
  
!    'libffi' provides some support for this.  However, this is
  necessarily platform-specific.
  
  
--- 732,740 ----
  =================
  
  A given platform may provide multiple different ABIs at once.  For
! instance, the x86 platform has both ‘stdcall’ and ‘fastcall’ functions.
  
!    ‘libffi’ provides some support for this.  However, this is
  necessarily platform-specific.
  
  
*************** File: libffi.info,  Node: The Closure AP
*** 743,755 ****
  2.5 The Closure API
  ===================
  
! 'libffi' also provides a way to write a generic function - a function
  that can accept and decode any combination of arguments.  This can be
  useful when writing an interpreter, or to provide wrappers for arbitrary
  functions.
  
!    This facility is called the "closure API". Closures are not supported
! on all platforms; you can check the 'FFI_CLOSURES' define to determine
  whether they are supported on the current platform.
  
     Because closures work by assembling a tiny function at runtime, they
--- 743,755 ----
  2.5 The Closure API
  ===================
  
! ‘libffi’ also provides a way to write a generic function - a function
  that can accept and decode any combination of arguments.  This can be
  useful when writing an interpreter, or to provide wrappers for arbitrary
  functions.
  
!    This facility is called the “closure API”. Closures are not supported
! on all platforms; you can check the ‘FFI_CLOSURES’ define to determine
  whether they are supported on the current platform.
  
     Because closures work by assembling a tiny function at runtime, they
*************** Memory management for closures is handle
*** 761,788 ****
       pointer to the writable address, and sets *CODE to the
       corresponding executable address.
  
!      SIZE should be sufficient to hold a 'ffi_closure' object.
  
   -- Function: void ffi_closure_free (void *WRITABLE)
!      Free memory allocated using 'ffi_closure_alloc'.  The argument is
       the writable address that was returned.
  
     Once you have allocated the memory for a closure, you must construct
! a 'ffi_cif' describing the function call.  Finally you can prepare the
  closure function:
  
   -- Function: ffi_status ffi_prep_closure_loc (ffi_closure *CLOSURE,
            ffi_cif *CIF, void (*FUN) (ffi_cif *CIF, void *RET, void
            **ARGS, void *USER_DATA), void *USER_DATA, void *CODELOC)
       Prepare a closure function.  The arguments to
!      'ffi_prep_closure_loc' are:
  
       CLOSURE
!           The address of a 'ffi_closure' object; this is the writable
!           address returned by 'ffi_closure_alloc'.
  
       CIF
!           The 'ffi_cif' describing the function parameters.  Note that
            this object, and the types to which it refers, must be kept
            alive until the closure itself is freed.
  
--- 761,788 ----
       pointer to the writable address, and sets *CODE to the
       corresponding executable address.
  
!      SIZE should be sufficient to hold a ‘ffi_closure’ object.
  
   -- Function: void ffi_closure_free (void *WRITABLE)
!      Free memory allocated using ‘ffi_closure_alloc’.  The argument is
       the writable address that was returned.
  
     Once you have allocated the memory for a closure, you must construct
! a ‘ffi_cif’ describing the function call.  Finally you can prepare the
  closure function:
  
   -- Function: ffi_status ffi_prep_closure_loc (ffi_closure *CLOSURE,
            ffi_cif *CIF, void (*FUN) (ffi_cif *CIF, void *RET, void
            **ARGS, void *USER_DATA), void *USER_DATA, void *CODELOC)
       Prepare a closure function.  The arguments to
!      ‘ffi_prep_closure_loc’ are:
  
       CLOSURE
!           The address of a ‘ffi_closure’ object; this is the writable
!           address returned by ‘ffi_closure_alloc’.
  
       CIF
!           The ‘ffi_cif’ describing the function parameters.  Note that
            this object, and the types to which it refers, must be kept
            alive until the closure itself is freed.
  
*************** closure function:
*** 791,819 ****
            closure function.
  
       CODELOC
!           The executable address returned by 'ffi_closure_alloc'.
  
       FUN
            The function which will be called when the closure is invoked.
            It is called with the arguments:
  
            CIF
!                The 'ffi_cif' passed to 'ffi_prep_closure_loc'.
  
            RET
                 A pointer to the memory used for the function's return
                 value.
  
!                If the function is declared as returning 'void', then
                 this value is garbage and should not be used.
  
                 Otherwise, FUN must fill the object to which this points,
                 following the same special promotion behavior as
!                'ffi_call'.  That is, in most cases, RET points to an
                 object of exactly the size of the type specified when CIF
                 was constructed.  However, integral types narrower than
                 the system register size are widened.  In these cases
!                your program may assume that RET points to an 'ffi_arg'
                 object.
  
            ARGS
--- 791,819 ----
            closure function.
  
       CODELOC
!           The executable address returned by ‘ffi_closure_alloc’.
  
       FUN
            The function which will be called when the closure is invoked.
            It is called with the arguments:
  
            CIF
!                The ‘ffi_cif’ passed to ‘ffi_prep_closure_loc’.
  
            RET
                 A pointer to the memory used for the function's return
                 value.
  
!                If the function is declared as returning ‘void’, then
                 this value is garbage and should not be used.
  
                 Otherwise, FUN must fill the object to which this points,
                 following the same special promotion behavior as
!                ‘ffi_call’.  That is, in most cases, RET points to an
                 object of exactly the size of the type specified when CIF
                 was constructed.  However, integral types narrower than
                 the system register size are widened.  In these cases
!                your program may assume that RET points to an ‘ffi_arg’
                 object.
  
            ARGS
*************** closure function:
*** 822,836 ****
  
            USER_DATA
                 The same USER_DATA that was passed to
!                'ffi_prep_closure_loc'.
  
!      'ffi_prep_closure_loc' will return 'FFI_OK' if everything went ok,
!      and one of the other 'ffi_status' values on error.
  
!      After calling 'ffi_prep_closure_loc', you can cast CODELOC to the
       appropriate pointer-to-function type.
  
!    You may see old code referring to 'ffi_prep_closure'.  This function
  is deprecated, as it cannot handle the need for separate writable and
  executable addresses.
  
--- 822,836 ----
  
            USER_DATA
                 The same USER_DATA that was passed to
!                ‘ffi_prep_closure_loc’.
  
!      ‘ffi_prep_closure_loc’ will return ‘FFI_OK’ if everything went ok,
!      and one of the other ‘ffi_status’ values on error.
  
!      After calling ‘ffi_prep_closure_loc’, you can cast CODELOC to the
       appropriate pointer-to-function type.
  
!    You may see old code referring to ‘ffi_prep_closure’.  This function
  is deprecated, as it cannot handle the need for separate writable and
  executable addresses.
  
*************** File: libffi.info,  Node: Closure Exampl
*** 840,847 ****
  2.6 Closure Example
  ===================
  
! A trivial example that creates a new 'puts' by binding 'fputs' with
! 'stdout'.
  
       #include 
       #include 
--- 840,847 ----
  2.6 Closure Example
  ===================
  
! A trivial example that creates a new ‘puts’ by binding ‘fputs’ with
! ‘stdout’.
  
       #include 
       #include 
*************** File: libffi.info,  Node: Thread Safety,
*** 899,919 ****
  2.7 Thread Safety
  =================
  
! 'libffi' is not completely thread-safe.  However, many parts are, and if
  you follow some simple rules, you can use it safely in a multi-threaded
  program.
  
!    * 'ffi_prep_cif' may modify the 'ffi_type' objects passed to it.  It
       is best to ensure that only a single thread prepares a given
!      'ffi_cif' at a time.
  
!    * On some platforms, 'ffi_prep_cif' may modify the size and alignment
       of some types, depending on the chosen ABI. On these platforms, if
       you switch between ABIs, you must ensure that there is only one
!      call to 'ffi_prep_cif' at a time.
  
       Currently the only affected platform is PowerPC and the only
!      affected type is 'long double'.
  
  
  File: libffi.info,  Node: Memory Usage,  Next: Missing Features,  Prev: Using libffi,  Up: Top
--- 899,919 ----
  2.7 Thread Safety
  =================
  
! ‘libffi’ is not completely thread-safe.  However, many parts are, and if
  you follow some simple rules, you can use it safely in a multi-threaded
  program.
  
!    • ‘ffi_prep_cif’ may modify the ‘ffi_type’ objects passed to it.  It
       is best to ensure that only a single thread prepares a given
!      ‘ffi_cif’ at a time.
  
!    • On some platforms, ‘ffi_prep_cif’ may modify the size and alignment
       of some types, depending on the chosen ABI. On these platforms, if
       you switch between ABIs, you must ensure that there is only one
!      call to ‘ffi_prep_cif’ at a time.
  
       Currently the only affected platform is PowerPC and the only
!      affected type is ‘long double’.
  
  
  File: libffi.info,  Node: Memory Usage,  Next: Missing Features,  Prev: Using libffi,  Up: Top
*************** File: libffi.info,  Node: Memory Usage,
*** 921,956 ****
  3 Memory Usage
  **************
  
! Note that memory allocated by 'ffi_closure_alloc' and freed by
! 'ffi_closure_free' does not come from the same general pool of memory
! that 'malloc' and 'free' use.  To accomodate security settings, 'libffi'
  may aquire memory, for example, by mapping temporary files into multiple
  places in the address space (once to write out the closure, a second to
  execute it).  The search follows this list, using the first that works:
  
!    * A anonymous mapping (i.e.  not file-backed)
  
!    * 'memfd_create()', if the kernel supports it.
  
!    * A file created in the directory referenced by the environment
!      variable 'LIBFFI_TMPDIR'.
  
!    * Likewise for the environment variable 'TMPDIR'.
  
!    * A file created in '/tmp'.
  
!    * A file created in '/var/tmp'.
  
!    * A file created in '/dev/shm'.
  
!    * A file created in the user's home directory ('$HOME').
  
!    * A file created in any directory listed in '/etc/mtab'.
  
!    * A file created in any directory listed in '/proc/mounts'.
  
     If security settings prohibit using any of these for closures,
! 'ffi_closure_alloc' will fail.
  
  
  File: libffi.info,  Node: Missing Features,  Next: Index,  Prev: Memory Usage,  Up: Top
--- 921,956 ----
  3 Memory Usage
  **************
  
! Note that memory allocated by ‘ffi_closure_alloc’ and freed by
! ‘ffi_closure_free’ does not come from the same general pool of memory
! that ‘malloc’ and ‘free’ use.  To accomodate security settings, ‘libffi’
  may aquire memory, for example, by mapping temporary files into multiple
  places in the address space (once to write out the closure, a second to
  execute it).  The search follows this list, using the first that works:
  
!    • A anonymous mapping (i.e.  not file-backed)
  
!    • ‘memfd_create()’, if the kernel supports it.
  
!    • A file created in the directory referenced by the environment
!      variable ‘LIBFFI_TMPDIR’.
  
!    • Likewise for the environment variable ‘TMPDIR’.
  
!    • A file created in ‘/tmp’.
  
!    • A file created in ‘/var/tmp’.
  
!    • A file created in ‘/dev/shm’.
  
!    • A file created in the user's home directory (‘$HOME’).
  
!    • A file created in any directory listed in ‘/etc/mtab’.
  
!    • A file created in any directory listed in ‘/proc/mounts’.
  
     If security settings prohibit using any of these for closures,
! ‘ffi_closure_alloc’ will fail.
  
  
  File: libffi.info,  Node: Missing Features,  Next: Index,  Prev: Memory Usage,  Up: Top
*************** File: libffi.info,  Node: Missing Featur
*** 958,973 ****
  4 Missing Features
  ******************
  
! 'libffi' is missing a few features.  We welcome patches to add support
  for these.
  
!    * Variadic closures.
  
!    * There is no support for bit fields in structures.
  
!    * The "raw" API is undocumented.
  
!    * The Go API is undocumented.
  
  
  File: libffi.info,  Node: Index,  Prev: Missing Features,  Up: Top
--- 958,973 ----
  4 Missing Features
  ******************
  
! ‘libffi’ is missing a few features.  We welcome patches to add support
  for these.
  
!    • Variadic closures.
  
!    • There is no support for bit fields in structures.
  
!    • The "raw" API is undocumented.
  
!    • The Go API is undocumented.
  
  
  File: libffi.info,  Node: Index,  Prev: Missing Features,  Up: Top
*************** Index
*** 986,994 ****
  * closures:                              The Closure API.      (line 13)
  * FFI:                                   Introduction.         (line 31)
  * ffi_call:                              The Basics.           (line 72)
- * FFI_CLOSURES:                          The Closure API.      (line 13)
  * ffi_closure_alloc:                     The Closure API.      (line 19)
  * ffi_closure_free:                      The Closure API.      (line 26)
  * ffi_get_struct_offsets:                Size and Alignment.   (line 39)
  * ffi_prep_cif:                          The Basics.           (line 16)
  * ffi_prep_cif_var:                      The Basics.           (line 39)
--- 986,994 ----
  * closures:                              The Closure API.      (line 13)
  * FFI:                                   Introduction.         (line 31)
  * ffi_call:                              The Basics.           (line 72)
  * ffi_closure_alloc:                     The Closure API.      (line 19)
  * ffi_closure_free:                      The Closure API.      (line 26)
+ * FFI_CLOSURES:                          The Closure API.      (line 13)
  * ffi_get_struct_offsets:                Size and Alignment.   (line 39)
  * ffi_prep_cif:                          The Basics.           (line 16)
  * ffi_prep_cif_var:                      The Basics.           (line 39)
*************** Index
*** 1033,1058 ****
  
  
  Tag Table:
! Node: Top1394
! Node: Introduction2923
! Node: Using libffi4555
! Node: The Basics5084
! Node: Simple Example10191
! Node: Types11222
! Node: Primitive Types11733
! Node: Structures13854
! Node: Size and Alignment14893
! Node: Arrays Unions Enums17090
! Node: Type Example20019
! Node: Complex21310
! Node: Complex Type Example22728
! Node: Multiple ABIs25780
! Node: The Closure API26151
! Node: Closure Example29977
! Node: Thread Safety31609
! Node: Memory Usage32410
! Node: Missing Features33605
! Node: Index33970
  
  End Tag Table
  
--- 1033,1058 ----
  
  
  Tag Table:
! Node: Top1393
! Node: Introduction2921
! Node: Using libffi4581
! Node: The Basics5110
! Node: Simple Example10401
! Node: Types11436
! Node: Primitive Types11947
! Node: Structures14264
! Node: Size and Alignment15375
! Node: Arrays Unions Enums17646
! Node: Type Example20623
! Node: Complex21930
! Node: Complex Type Example23444
! Node: Multiple ABIs26496
! Node: The Closure API26879
! Node: Closure Example30793
! Node: Thread Safety32437
! Node: Memory Usage33270
! Node: Missing Features34545
! Node: Index34922
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/libgcc/config/avr/libf7/ChangeLog gcc-13.5.0-RC-20260904/libgcc/config/avr/libf7/ChangeLog
*** gcc-13.4.0/libgcc/config/avr/libf7/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/libgcc/config/avr/libf7/ChangeLog	Fri Sep  4 07:35:11 2026
***************
*** 1,3 ****
--- 1,12 ----
+ 2026-08-24  Georg-Johann Lay  
+ 
+ 	Backported from master:
+ 	2026-08-24  Georg-Johann Lay  
+ 
+ 	PR target/127024
+ 	* libf7-asm.sx (to_integer): Don't skip XJMP
+ 	if __AVR_ERRATA_SKIP_JMP_CALL__.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/libgcc/config/avr/libf7/libf7-asm.sx gcc-13.5.0-RC-20260904/libgcc/config/avr/libf7/libf7-asm.sx
*** gcc-13.4.0/libgcc/config/avr/libf7/libf7-asm.sx	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libgcc/config/avr/libf7/libf7-asm.sx	Fri Sep  4 07:35:11 2026
*************** DEFUN to_integer
*** 602,613 ****
      brmi    .Lsaturate.T    ;   > INTxx_MAX  =>  saturate
  
      brtc 9f                 ;   >= 0         =>  return
      sbrc    Mask,   5
-     .global __negdi2
      XJMP    __negdi2
      sbrc    Mask,   4
-     .global __negsi2
      XJMP    __negsi2
      neg     C6
      neg     C5
      sbci    C6,     0
--- 602,622 ----
      brmi    .Lsaturate.T    ;   > INTxx_MAX  =>  saturate
  
      brtc 9f                 ;   >= 0         =>  return
+ #ifdef __AVR_ERRATA_SKIP_JMP_CALL__
+     ;; Some cores have a problem skipping 2-word instructions.
+     sbrs    Mask,   5
+     rjmp    0f
+     XJMP    __negdi2
+ 0:  sbrs    Mask,   4
+     rjmp    1f
+     XJMP    __negsi2
+ 1:
+ #else
      sbrc    Mask,   5
      XJMP    __negdi2
      sbrc    Mask,   4
      XJMP    __negsi2
+ #endif /* __AVR_ERRATA_SKIP_JMP_CALL__ */
      neg     C6
      neg     C5
      sbci    C6,     0
diff -Nrcpad gcc-13.4.0/libgcc/config/libbid/ChangeLog gcc-13.5.0-RC-20260904/libgcc/config/libbid/ChangeLog
*** gcc-13.4.0/libgcc/config/libbid/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/libgcc/config/libbid/ChangeLog	Fri Sep  4 07:35:11 2026
***************
*** 1,3 ****
--- 1,29 ----
+ 2025-08-30  liuhongt  
+ 
+ 	Revert:
+ 	2025-08-29  liuhongt  
+ 
+ 	PR target/120691
+ 	* bid128_div.c: Fix _Decimal128 arithmetic error under
+ 	FE_UPWARD.
+ 	* bid128_rem.c: Ditto.
+ 	* bid128_sqrt.c: Ditto.
+ 	* bid64_div.c (bid64_div): Ditto.
+ 	* bid64_sqrt.c (bid64_sqrt): Ditto.
+ 
+ 2025-08-29  liuhongt  
+ 
+ 	Backported from master:
+ 	2025-08-29  liuhongt  
+ 
+ 	PR target/120691
+ 	* bid128_div.c: Fix _Decimal128 arithmetic error under
+ 	FE_UPWARD.
+ 	* bid128_rem.c: Ditto.
+ 	* bid128_sqrt.c: Ditto.
+ 	* bid64_div.c (bid64_div): Ditto.
+ 	* bid64_sqrt.c (bid64_sqrt): Ditto.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/libgomp/ChangeLog gcc-13.5.0-RC-20260904/libgomp/ChangeLog
*** gcc-13.4.0/libgomp/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/libgomp/ChangeLog	Fri Sep  4 07:35:11 2026
***************
*** 1,3 ****
--- 1,17 ----
+ 2026-04-02  Paul Thomas  
+ 
+ 	Backported from master:
+ 	2026-04-02  Paul Thomas  
+ 
+ 	* testsuite/libgomp.fortran/pr120286.f90: New test.
+ 
+ 2026-03-22  Frank Scheiner  
+ 
+ 	Backported from master:
+ 	2025-11-25  Frank Scheiner  
+ 
+ 	* affinity-fmt.c: Make char *q a pointer to a const char.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/libgomp/affinity-fmt.c gcc-13.5.0-RC-20260904/libgomp/affinity-fmt.c
*** gcc-13.4.0/libgomp/affinity-fmt.c	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libgomp/affinity-fmt.c	Fri Sep  4 07:35:11 2026
*************** gomp_display_affinity (char *buffer, siz
*** 327,333 ****
  	      }
  	  if (c == '{')
  	    {
! 	      char *q = strchr (p + 1, '}');
  	      if (q)
  		gomp_fatal ("unsupported long type name '%.*s' in affinity "
  			    "format", (int) (q - (p + 1)), p + 1);
--- 327,333 ----
  	      }
  	  if (c == '{')
  	    {
! 	      const char *q = strchr (p + 1, '}');
  	      if (q)
  		gomp_fatal ("unsupported long type name '%.*s' in affinity "
  			    "format", (int) (q - (p + 1)), p + 1);
diff -Nrcpad gcc-13.4.0/libgomp/libgomp.info gcc-13.5.0-RC-20260904/libgomp/libgomp.info
*** gcc-13.4.0/libgomp/libgomp.info	Thu Jun  5 16:26:31 2025
--- gcc-13.5.0-RC-20260904/libgomp/libgomp.info	Fri Sep  4 07:54:15 2026
***************
*** 1,7 ****
! This is libgomp.info, produced by makeinfo version 6.8 from
  libgomp.texi.
  
! Copyright (C) 2006-2023 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
--- 1,7 ----
! This is libgomp.info, produced by makeinfo version 7.1 from
  libgomp.texi.
  
! Copyright © 2006-2023 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
*************** C/C++ and Fortran.
*** 33,39 ****
     Published by the Free Software Foundation 51 Franklin Street, Fifth
  Floor Boston, MA 02110-1301 USA
  
!    Copyright (C) 2006-2023 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
--- 33,39 ----
     Published by the Free Software Foundation 51 Franklin Street, Fifth
  Floor Boston, MA 02110-1301 USA
  
!    Copyright © 2006-2023 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
*************** File: libgomp.info,  Node: Enabling Open
*** 114,123 ****
  *****************
  
  To activate the OpenMP extensions for C/C++ and Fortran, the
! compile-time flag '-fopenmp' must be specified.  This enables the OpenMP
! directive '#pragma omp' in C/C++ and '!$omp' directives in free form,
! 'c$omp', '*$omp' and '!$omp' directives in fixed form, '!$' conditional
! compilation sentinels in free form and 'c$', '*$' and '!$' sentinels in
  fixed form, for Fortran.  The flag also arranges for automatic linking
  of the OpenMP runtime library (*note Runtime Library Routines::).
  
--- 114,123 ----
  *****************
  
  To activate the OpenMP extensions for C/C++ and Fortran, the
! compile-time flag ‘-fopenmp’ must be specified.  This enables the OpenMP
! directive ‘#pragma omp’ in C/C++ and ‘!$omp’ directives in free form,
! ‘c$omp’, ‘*$omp’ and ‘!$omp’ directives in fixed form, ‘!$’ conditional
! compilation sentinels in free form and ‘c$’, ‘*$’ and ‘!$’ sentinels in
  fixed form, for Fortran.  The flag also arranges for automatic linking
  of the OpenMP runtime library (*note Runtime Library Routines::).
  
*************** File: libgomp.info,  Node: OpenMP Implem
*** 139,147 ****
  * OpenMP 5.2:: Feature completion status to 5.2 specification
  * OpenMP Technical Report 11:: Feature completion status to first 6.0 preview
  
! The '_OPENMP' preprocessor macro and Fortran's 'openmp_version'
! parameter, provided by 'omp_lib.h' and the 'omp_lib' module, have the
! value '201511' (i.e.  OpenMP 4.5).
  
  
  File: libgomp.info,  Node: OpenMP 4.5,  Next: OpenMP 5.0,  Up: OpenMP Implementation Status
--- 139,147 ----
  * OpenMP 5.2:: Feature completion status to 5.2 specification
  * OpenMP Technical Report 11:: Feature completion status to first 6.0 preview
  
! The ‘_OPENMP’ preprocessor macro and Fortran's ‘openmp_version’
! parameter, provided by ‘omp_lib.h’ and the ‘omp_lib’ module, have the
! value ‘201511’ (i.e.  OpenMP 4.5).
  
  
  File: libgomp.info,  Node: OpenMP 4.5,  Next: OpenMP 5.0,  Up: OpenMP Implementation Status
*************** Array shaping
*** 166,245 ****
  Array sections with non-unit strides in C   N
  and C++
  Iterators                                   Y
! 'metadirective' directive                   N
! 'declare variant' directive                 P       _simd_ traits
                                                      not handled
                                                      correctly
  _target-offload-var_ ICV and                Y
! 'OMP_TARGET_OFFLOAD' env variable
  Nested-parallel changes to                  Y
  _max-active-levels-var_ ICV
! 'requires' directive                        P       complete but no
                                                      non-host devices
                                                      provides
!                                                     'unified_address'
                                                      or
!                                                     'unified_shared_memory'
! 'teams' construct outside an enclosing      Y
  target region
  Non-rectangular loop nests                  P       Full support for
                                                      C/C++, partial
                                                      for Fortran
! '!=' as relational-op in canonical loop     Y
  form for C/C++
! 'nonmonotonic' as default loop schedule     Y
  modifier for worksharing-loop constructs
  Collapse of associated loops that are       N
  imperfectly nested loops
! Clauses 'if', 'nontemporal' and             Y
! 'order(concurrent)' in 'simd' construct
! 'atomic' constructs in 'simd'               Y
! 'loop' construct                            Y
! 'order(concurrent)' clause                  Y
! 'scan' directive and 'in_scan' modifier     Y
! for the 'reduction' clause
! 'in_reduction' clause on 'task'             Y
  constructs
! 'in_reduction' clause on 'target'           P       'nowait' only
  constructs                                          stub
! 'task_reduction' clause with 'taskgroup'    Y
! 'task' modifier to 'reduction' clause       Y
! 'affinity' clause to 'task' construct       Y       Stub only
! 'detach' clause to 'task' construct         Y
! 'omp_fulfill_event' runtime routine         Y
! 'reduction' and 'in_reduction' clauses on   Y
! 'taskloop' and 'taskloop simd' constructs
! 'taskloop' construct cancelable by          Y
! 'cancel' construct
! 'mutexinoutset' _dependence-type_ for       Y
! 'depend' clause
  Predefined memory spaces, memory            Y       Some are only
  allocators, allocator traits                        stubs
  Memory management routines                  Y
! 'allocate' directive                        N
! 'allocate' clause                           P       Initial support
! 'use_device_addr' clause on 'target data'   Y
! 'ancestor' modifier on 'device' clause      Y
  Implicit declare target directive           Y
! Discontiguous array section with 'target    N
! update' construct
! C/C++'s lvalue expressions in 'to',         N
! 'from' and 'map' clauses
! C/C++'s lvalue expressions in 'depend'      Y
  clauses
! Nested 'declare target' directive           Y
! Combined 'master' constructs                Y
! 'depend' clause on 'taskwait'               Y
! Weak memory ordering clauses on 'atomic'    Y
! and 'flush' construct
! 'hint' clause on the 'atomic' construct     Y       Stub only
! 'depobj' construct and depend objects       Y
  Lock hints were renamed to                  Y
  synchronization hints
! 'conditional' modifier to 'lastprivate'     Y
  clause
  Map-order clarifications                    P
! 'close' _map-type-modifier_                 Y
  Mapping C/C++ pointer variables and to      P
  assign the address of device memory
  mapped by an array section
--- 166,245 ----
  Array sections with non-unit strides in C   N
  and C++
  Iterators                                   Y
! ‘metadirective’ directive                   N
! ‘declare variant’ directive                 P       _simd_ traits
                                                      not handled
                                                      correctly
  _target-offload-var_ ICV and                Y
! ‘OMP_TARGET_OFFLOAD’ env variable
  Nested-parallel changes to                  Y
  _max-active-levels-var_ ICV
! ‘requires’ directive                        P       complete but no
                                                      non-host devices
                                                      provides
!                                                     ‘unified_address’
                                                      or
!                                                     ‘unified_shared_memory’
! ‘teams’ construct outside an enclosing      Y
  target region
  Non-rectangular loop nests                  P       Full support for
                                                      C/C++, partial
                                                      for Fortran
! ‘!=’ as relational-op in canonical loop     Y
  form for C/C++
! ‘nonmonotonic’ as default loop schedule     Y
  modifier for worksharing-loop constructs
  Collapse of associated loops that are       N
  imperfectly nested loops
! Clauses ‘if’, ‘nontemporal’ and             Y
! ‘order(concurrent)’ in ‘simd’ construct
! ‘atomic’ constructs in ‘simd’               Y
! ‘loop’ construct                            Y
! ‘order(concurrent)’ clause                  Y
! ‘scan’ directive and ‘in_scan’ modifier     Y
! for the ‘reduction’ clause
! ‘in_reduction’ clause on ‘task’             Y
  constructs
! ‘in_reduction’ clause on ‘target’           P       ‘nowait’ only
  constructs                                          stub
! ‘task_reduction’ clause with ‘taskgroup’    Y
! ‘task’ modifier to ‘reduction’ clause       Y
! ‘affinity’ clause to ‘task’ construct       Y       Stub only
! ‘detach’ clause to ‘task’ construct         Y
! ‘omp_fulfill_event’ runtime routine         Y
! ‘reduction’ and ‘in_reduction’ clauses on   Y
! ‘taskloop’ and ‘taskloop simd’ constructs
! ‘taskloop’ construct cancelable by          Y
! ‘cancel’ construct
! ‘mutexinoutset’ _dependence-type_ for       Y
! ‘depend’ clause
  Predefined memory spaces, memory            Y       Some are only
  allocators, allocator traits                        stubs
  Memory management routines                  Y
! ‘allocate’ directive                        N
! ‘allocate’ clause                           P       Initial support
! ‘use_device_addr’ clause on ‘target data’   Y
! ‘ancestor’ modifier on ‘device’ clause      Y
  Implicit declare target directive           Y
! Discontiguous array section with ‘target    N
! update’ construct
! C/C++'s lvalue expressions in ‘to’,         N
! ‘from’ and ‘map’ clauses
! C/C++'s lvalue expressions in ‘depend’      Y
  clauses
! Nested ‘declare target’ directive           Y
! Combined ‘master’ constructs                Y
! ‘depend’ clause on ‘taskwait’               Y
! Weak memory ordering clauses on ‘atomic’    Y
! and ‘flush’ construct
! ‘hint’ clause on the ‘atomic’ construct     Y       Stub only
! ‘depobj’ construct and depend objects       Y
  Lock hints were renamed to                  Y
  synchronization hints
! ‘conditional’ modifier to ‘lastprivate’     Y
  clause
  Map-order clarifications                    P
! ‘close’ _map-type-modifier_                 Y
  Mapping C/C++ pointer variables and to      P
  assign the address of device memory
  mapped by an array section
*************** Mapping of Fortran pointer and
*** 247,261 ****
  allocatable variables, including pointer            with allocatable
  and allocatable components of variables             components
                                                      unsupported
! 'defaultmap' extensions                     Y
! 'declare mapper' directive                  N
! 'omp_get_supported_active_levels' routine   Y
  Runtime routines and environment            Y
  variables to display runtime thread
  affinity information
! 'omp_pause_resource' and                    Y
! 'omp_pause_resource_all' runtime routines
! 'omp_get_device_num' runtime routine        Y
  OMPT interface                              N
  OMPD interface                              N
  
--- 247,261 ----
  allocatable variables, including pointer            with allocatable
  and allocatable components of variables             components
                                                      unsupported
! ‘defaultmap’ extensions                     Y
! ‘declare mapper’ directive                  N
! ‘omp_get_supported_active_levels’ routine   Y
  Runtime routines and environment            Y
  variables to display runtime thread
  affinity information
! ‘omp_pause_resource’ and                    Y
! ‘omp_pause_resource_all’ runtime routines
! ‘omp_get_device_num’ runtime routine        Y
  OMPT interface                              N
  OMPD interface                              N
  
*************** Description
*** 279,357 ****
  -----------------------------------------------------------------------
  OpenMP directive as C++ attribute           Y
  specifiers
! 'omp_all_memory' reserved locator           Y
  _target_device trait_ in OpenMP Context     N
! 'target_device' selector set in context     N
  selectors
! C/C++'s 'declare variant' directive:        N
  elision support of preprocessed code
! 'declare variant': new clauses              N
! 'adjust_args' and 'append_args'
! 'dispatch' construct                        N
  device-specific ICV settings with           Y
  environment variables
! 'assume' and 'assumes' directives           Y
! 'nothing' directive                         Y
! 'error' directive                           Y
! 'masked' construct                          Y
! 'scope' directive                           Y
  Loop transformation constructs              N
! 'strict' modifier in the 'grainsize' and    Y
! 'num_tasks' clauses of the 'taskloop'
  construct
! 'align' clause in 'allocate' directive      N
! 'align' modifier in 'allocate' clause       Y
! 'thread_limit' clause to 'target'           Y
  construct
! 'has_device_addr' clause to 'target'        Y
  construct
! Iterators in 'target update' motion         N
! clauses and 'map' clauses
  Indirect calls to the device version of a   N
! procedure or function in 'target' regions
! 'interop' directive                         N
! 'omp_interop_t' object support in runtime   N
  routines
! 'nowait' clause in 'taskwait' directive     Y
! Extensions to the 'atomic' directive        Y
! 'seq_cst' clause on a 'flush' construct     Y
! 'inoutset' argument to the 'depend'         Y
  clause
! 'private' and 'firstprivate' argument to    Y
! 'default' clause in C and C++
! 'present' argument to 'defaultmap' clause   N
! 'omp_set_num_teams',                        Y
! 'omp_set_teams_thread_limit',
! 'omp_get_max_teams',
! 'omp_get_teams_thread_limit' runtime
  routines
! 'omp_target_is_accessible' runtime          Y
  routine
! 'omp_target_memcpy_async' and               Y
! 'omp_target_memcpy_rect_async' runtime
  routines
! 'omp_get_mapped_ptr' runtime routine        Y
! 'omp_calloc', 'omp_realloc',                Y
! 'omp_aligned_alloc' and
! 'omp_aligned_calloc' runtime routines
! 'omp_alloctrait_key_t' enum:                Y
! 'omp_atv_serialized' added,
! 'omp_atv_default' changed
! 'omp_display_env' runtime routine           Y
! 'ompt_scope_endpoint_t' enum:               N
! 'ompt_scope_beginend'
! 'ompt_sync_region_t' enum additions         N
! 'ompt_state_t' enum:                        N
! 'ompt_state_wait_barrier_implementation'
! and 'ompt_state_wait_barrier_teams'
! 'ompt_callback_target_data_op_emi_t',       N
! 'ompt_callback_target_emi_t',
! 'ompt_callback_target_map_emi_t' and
! 'ompt_callback_target_submit_emi_t'
! 'ompt_callback_error_t' type                N
! 'OMP_PLACES' syntax extensions              Y
! 'OMP_NUM_TEAMS' and                         Y
! 'OMP_TEAMS_THREAD_LIMIT' environment
  variables
  
  Other new OpenMP 5.1 features
--- 279,357 ----
  -----------------------------------------------------------------------
  OpenMP directive as C++ attribute           Y
  specifiers
! ‘omp_all_memory’ reserved locator           Y
  _target_device trait_ in OpenMP Context     N
! ‘target_device’ selector set in context     N
  selectors
! C/C++'s ‘declare variant’ directive:        N
  elision support of preprocessed code
! ‘declare variant’: new clauses              N
! ‘adjust_args’ and ‘append_args’
! ‘dispatch’ construct                        N
  device-specific ICV settings with           Y
  environment variables
! ‘assume’ and ‘assumes’ directives           Y
! ‘nothing’ directive                         Y
! ‘error’ directive                           Y
! ‘masked’ construct                          Y
! ‘scope’ directive                           Y
  Loop transformation constructs              N
! ‘strict’ modifier in the ‘grainsize’ and    Y
! ‘num_tasks’ clauses of the ‘taskloop’
  construct
! ‘align’ clause in ‘allocate’ directive      N
! ‘align’ modifier in ‘allocate’ clause       Y
! ‘thread_limit’ clause to ‘target’           Y
  construct
! ‘has_device_addr’ clause to ‘target’        Y
  construct
! Iterators in ‘target update’ motion         N
! clauses and ‘map’ clauses
  Indirect calls to the device version of a   N
! procedure or function in ‘target’ regions
! ‘interop’ directive                         N
! ‘omp_interop_t’ object support in runtime   N
  routines
! ‘nowait’ clause in ‘taskwait’ directive     Y
! Extensions to the ‘atomic’ directive        Y
! ‘seq_cst’ clause on a ‘flush’ construct     Y
! ‘inoutset’ argument to the ‘depend’         Y
  clause
! ‘private’ and ‘firstprivate’ argument to    Y
! ‘default’ clause in C and C++
! ‘present’ argument to ‘defaultmap’ clause   N
! ‘omp_set_num_teams’,                        Y
! ‘omp_set_teams_thread_limit’,
! ‘omp_get_max_teams’,
! ‘omp_get_teams_thread_limit’ runtime
  routines
! ‘omp_target_is_accessible’ runtime          Y
  routine
! ‘omp_target_memcpy_async’ and               Y
! ‘omp_target_memcpy_rect_async’ runtime
  routines
! ‘omp_get_mapped_ptr’ runtime routine        Y
! ‘omp_calloc’, ‘omp_realloc’,                Y
! ‘omp_aligned_alloc’ and
! ‘omp_aligned_calloc’ runtime routines
! ‘omp_alloctrait_key_t’ enum:                Y
! ‘omp_atv_serialized’ added,
! ‘omp_atv_default’ changed
! ‘omp_display_env’ runtime routine           Y
! ‘ompt_scope_endpoint_t’ enum:               N
! ‘ompt_scope_beginend’
! ‘ompt_sync_region_t’ enum additions         N
! ‘ompt_state_t’ enum:                        N
! ‘ompt_state_wait_barrier_implementation’
! and ‘ompt_state_wait_barrier_teams’
! ‘ompt_callback_target_data_op_emi_t’,       N
! ‘ompt_callback_target_emi_t’,
! ‘ompt_callback_target_map_emi_t’ and
! ‘ompt_callback_target_submit_emi_t’
! ‘ompt_callback_error_t’ type                N
! ‘OMP_PLACES’ syntax extensions              Y
! ‘OMP_NUM_TEAMS’ and                         Y
! ‘OMP_TEAMS_THREAD_LIMIT’ environment
  variables
  
  Other new OpenMP 5.1 features
*************** Support of strictly structured blocks in
*** 363,383 ****
  Fortran
  Support of structured block sequences in    Y
  C/C++
! 'unconstrained' and 'reproducible'          Y
! modifiers on 'order' clause
! Support 'begin/end declare target' syntax   Y
  in C/C++
  Pointer predetermined firstprivate          N
  getting initialized to address of
  matching mapped list item per 5.1, Sect.
  2.21.7.2
  For Fortran, diagnose placing declarative   N
! before/between 'USE', 'IMPORT', and
! 'IMPLICIT' as invalid
  Optional comma between directive and        Y
! clause in the '#pragma' form
! 'indirect' clause in 'declare target'       N
! 'device_type(nohost)'/'device_type(host)'   N
  for variables
  
  
--- 363,383 ----
  Fortran
  Support of structured block sequences in    Y
  C/C++
! ‘unconstrained’ and ‘reproducible’          Y
! modifiers on ‘order’ clause
! Support ‘begin/end declare target’ syntax   Y
  in C/C++
  Pointer predetermined firstprivate          N
  getting initialized to address of
  matching mapped list item per 5.1, Sect.
  2.21.7.2
  For Fortran, diagnose placing declarative   N
! before/between ‘USE’, ‘IMPORT’, and
! ‘IMPLICIT’ as invalid
  Optional comma between directive and        Y
! clause in the ‘#pragma’ form
! ‘indirect’ clause in ‘declare target’       N
! ‘device_type(nohost)’/‘device_type(host)’   N
  for variables
  
  
*************** New features listed in Appendix B of the
*** 391,450 ****
  
  Description                                 Status  Comments
  -----------------------------------------------------------------------
! 'omp_in_explicit_task' routine and          Y
  _explicit-task-var_ ICV
! 'omp'/'ompx'/'omx' sentinels and            N/A     warning for
! 'omp_'/'ompx_' namespaces                           'ompx/omx'
                                                      sentinels(1)
! Clauses on 'end' directive can be on        Y
  directive
! Deprecation of no-argument 'destroy'        N
! clause on 'depobj'
! 'linear' clause syntax changes and 'step'   Y
  modifier
  Deprecation of minus operator for           N
  reductions
! Deprecation of separating 'map' modifiers   N
  without comma
! 'declare mapper' with iterator and          N
! 'present' modifiers
  If a matching mapped list item is not       N
  found in the data environment, the
  pointer retains its original value
! New 'enter' clause as alias for 'to' on     Y
  declare target directive
! Deprecation of 'to' clause on declare       N
  target directive
  Extended list of directives permitted in    N
  Fortran pure procedures
! New 'allocators' directive for Fortran      N
! Deprecation of 'allocate' directive for     N
  Fortran allocatables/pointers
! Optional paired 'end' directive with        N
! 'dispatch'
! New 'memspace' and 'traits' modifiers for   N
! 'uses_allocators'
  Deprecation of traits array following the   N
  allocator_handle expression in
! 'uses_allocators'
! New 'otherwise' clause as alias for         N
! 'default' on metadirectives
! Deprecation of 'default' clause on          N
  metadirectives
! Deprecation of delimited form of 'declare   N
! target'
  Reproducible semantics changed for          N
! 'order(concurrent)'
! 'allocate' and 'firstprivate' clauses on    Y
! 'scope'
! 'ompt_callback_work'                        N
! Default map-type for the 'map' clause in    Y
! 'target enter/exit data'
! New 'doacross' clause as alias for          Y
! 'depend' with 'source'/'sink' modifier
! Deprecation of 'depend' with                N
! 'source'/'sink' modifier
! 'omp_cur_iteration' keyword                 Y
  
  Other new OpenMP 5.2 features
  -----------------------------
--- 391,450 ----
  
  Description                                 Status  Comments
  -----------------------------------------------------------------------
! ‘omp_in_explicit_task’ routine and          Y
  _explicit-task-var_ ICV
! ‘omp’/‘ompx’/‘omx’ sentinels and            N/A     warning for
! ‘omp_’/‘ompx_’ namespaces                           ‘ompx/omx’
                                                      sentinels(1)
! Clauses on ‘end’ directive can be on        Y
  directive
! Deprecation of no-argument ‘destroy’        N
! clause on ‘depobj’
! ‘linear’ clause syntax changes and ‘step’   Y
  modifier
  Deprecation of minus operator for           N
  reductions
! Deprecation of separating ‘map’ modifiers   N
  without comma
! ‘declare mapper’ with iterator and          N
! ‘present’ modifiers
  If a matching mapped list item is not       N
  found in the data environment, the
  pointer retains its original value
! New ‘enter’ clause as alias for ‘to’ on     Y
  declare target directive
! Deprecation of ‘to’ clause on declare       N
  target directive
  Extended list of directives permitted in    N
  Fortran pure procedures
! New ‘allocators’ directive for Fortran      N
! Deprecation of ‘allocate’ directive for     N
  Fortran allocatables/pointers
! Optional paired ‘end’ directive with        N
! ‘dispatch’
! New ‘memspace’ and ‘traits’ modifiers for   N
! ‘uses_allocators’
  Deprecation of traits array following the   N
  allocator_handle expression in
! ‘uses_allocators’
! New ‘otherwise’ clause as alias for         N
! ‘default’ on metadirectives
! Deprecation of ‘default’ clause on          N
  metadirectives
! Deprecation of delimited form of ‘declare   N
! target’
  Reproducible semantics changed for          N
! ‘order(concurrent)’
! ‘allocate’ and ‘firstprivate’ clauses on    Y
! ‘scope’
! ‘ompt_callback_work’                        N
! Default map-type for the ‘map’ clause in    Y
! ‘target enter/exit data’
! New ‘doacross’ clause as alias for          Y
! ‘depend’ with ‘source’/‘sink’ modifier
! Deprecation of ‘depend’ with                N
! ‘source’/‘sink’ modifier
! ‘omp_cur_iteration’ keyword                 Y
  
  Other new OpenMP 5.2 features
  -----------------------------
*************** Description
*** 454,474 ****
  For Fortran, optional comma between         N
  directive and clause
  Conforming device numbers and               Y
! 'omp_initial_device' and
! 'omp_invalid_device' enum/PARAMETER
  Initial value of _default-device-var_ ICV   N
! with 'OMP_TARGET_OFFLOAD=mandatory'
  _interop_types_ in any position of the      N
! modifier list for the 'init' clause of
! the 'interop' construct
  
     ---------- Footnotes ----------
  
!    (1) The 'ompx' sentinel as C/C++ pragma and C++ attributes are warned
! for with '-Wunknown-pragmas' (implied by '-Wall') and '-Wattributes'
  (enabled by default), respectively; for Fortran free-source code, there
! is a warning enabled by default and, for fixed-source code, the 'omx'
! sentinel is warned for with with '-Wsurprising' (enabled by '-Wall').
  Unknown clauses are always rejected with an error.
  
  
--- 454,474 ----
  For Fortran, optional comma between         N
  directive and clause
  Conforming device numbers and               Y
! ‘omp_initial_device’ and
! ‘omp_invalid_device’ enum/PARAMETER
  Initial value of _default-device-var_ ICV   N
! with ‘OMP_TARGET_OFFLOAD=mandatory’
  _interop_types_ in any position of the      N
! modifier list for the ‘init’ clause of
! the ‘interop’ construct
  
     ---------- Footnotes ----------
  
!    (1) The ‘ompx’ sentinel as C/C++ pragma and C++ attributes are warned
! for with ‘-Wunknown-pragmas’ (implied by ‘-Wall’) and ‘-Wattributes’
  (enabled by default), respectively; for Fortran free-source code, there
! is a warning enabled by default and, for fixed-source code, the ‘omx’
! sentinel is warned for with with ‘-Wsurprising’ (enabled by ‘-Wall’).
  Unknown clauses are always rejected with an error.
  
  
*************** New features listed in Appendix B of the
*** 484,499 ****
  
  Features deprecated in versions 5.2, 5.1    N/A     Backward
  and 5.0 were removed                                compatibility
! The 'decl' attribute was added to the C++   N
  attribute syntax
! '_ALL' suffix to the device-scope           P       Host device
  environment variables                               number wrongly
                                                      accepted
  For Fortran, _locator list_ can be also     N
  function reference with data pointer
  result
  Ref-count change for                        N
! 'use_device_ptr'/'use_device_addr'
  Implicit reduction identifiers of C++       N
  classes
  Change of the _map-type_ property from      N
--- 484,499 ----
  
  Features deprecated in versions 5.2, 5.1    N/A     Backward
  and 5.0 were removed                                compatibility
! The ‘decl’ attribute was added to the C++   N
  attribute syntax
! ‘_ALL’ suffix to the device-scope           P       Host device
  environment variables                               number wrongly
                                                      accepted
  For Fortran, _locator list_ can be also     N
  function reference with data pointer
  result
  Ref-count change for                        N
! ‘use_device_ptr’/‘use_device_addr’
  Implicit reduction identifiers of C++       N
  classes
  Change of the _map-type_ property from      N
*************** Concept of _assumed-size arrays_ in C an
*** 502,549 ****
  C++
  Mapping of _assumed-size arrays_ in C,      N
  C++ and Fortran
! 'groupprivate' directive                    N
! 'local' clause to declare target            N
  directive
! 'part_size' allocator trait                 N
! 'pin_device', 'preferred_device' and        N
! 'target_access' allocator traits
! 'access' allocator trait changes            N
! Extension of 'interop' operation of         N
! 'append_args', allowing all modifiers of
! the 'init' clause
! 'interop' clause to 'dispatch'              N
! 'apply' code to loop-transforming           N
  constructs
! 'omp_curr_progress_width' identifier        N
! 'safesync' clause to the 'parallel'         N
  construct
! 'omp_get_max_progress_width' runtime        N
  routine
! 'strict' modifier keyword to                N
! 'num_threads'
! 'memscope' clause to 'atomic' and 'flush'   N
  Routines for obtaining memory               N
  spaces/allocators for shared/device
  memory
! 'omp_get_memspace_num_resources' routine    N
! 'omp_get_submemspace' routine               N
! 'ompt_get_buffer_limits' OMPT routine       N
! Extension of 'OMP_DEFAULT_DEVICE' and new   N
! 'OMP_AVAILABLE_DEVICES' environment vars
  Supporting increments with abstract names   N
! in 'OMP_PLACES'
  
  Other new TR 11 features
  ------------------------
  
  Relaxed Fortran restrictions to the         N
! 'aligned' clause
  Mapping lambda captures                     N
  For Fortran, atomic compare with storing    N
  the comparison result
! 'aligned' clause changes for 'simd' and     N
! 'declare simd'
  
  
  File: libgomp.info,  Node: Runtime Library Routines,  Next: Environment Variables,  Prev: OpenMP Implementation Status,  Up: Top
--- 502,549 ----
  C++
  Mapping of _assumed-size arrays_ in C,      N
  C++ and Fortran
! ‘groupprivate’ directive                    N
! ‘local’ clause to declare target            N
  directive
! ‘part_size’ allocator trait                 N
! ‘pin_device’, ‘preferred_device’ and        N
! ‘target_access’ allocator traits
! ‘access’ allocator trait changes            N
! Extension of ‘interop’ operation of         N
! ‘append_args’, allowing all modifiers of
! the ‘init’ clause
! ‘interop’ clause to ‘dispatch’              N
! ‘apply’ code to loop-transforming           N
  constructs
! ‘omp_curr_progress_width’ identifier        N
! ‘safesync’ clause to the ‘parallel’         N
  construct
! ‘omp_get_max_progress_width’ runtime        N
  routine
! ‘strict’ modifier keyword to                N
! ‘num_threads’
! ‘memscope’ clause to ‘atomic’ and ‘flush’   N
  Routines for obtaining memory               N
  spaces/allocators for shared/device
  memory
! ‘omp_get_memspace_num_resources’ routine    N
! ‘omp_get_submemspace’ routine               N
! ‘ompt_get_buffer_limits’ OMPT routine       N
! Extension of ‘OMP_DEFAULT_DEVICE’ and new   N
! ‘OMP_AVAILABLE_DEVICES’ environment vars
  Supporting increments with abstract names   N
! in ‘OMP_PLACES’
  
  Other new TR 11 features
  ------------------------
  
  Relaxed Fortran restrictions to the         N
! ‘aligned’ clause
  Mapping lambda captures                     N
  For Fortran, atomic compare with storing    N
  the comparison result
! ‘aligned’ clause changes for ‘simd’ and     N
! ‘declare simd’
  
  
  File: libgomp.info,  Node: Runtime Library Routines,  Next: Environment Variables,  Prev: OpenMP Implementation Status,  Up: Top
*************** Support for event objects.
*** 622,628 ****
  
  File: libgomp.info,  Node: omp_get_active_level,  Next: omp_get_ancestor_thread_num,  Up: Runtime Library Routines
  
! 3.1 'omp_get_active_level' - Number of parallel regions
  =======================================================
  
  _Description_:
--- 622,628 ----
  
  File: libgomp.info,  Node: omp_get_active_level,  Next: omp_get_ancestor_thread_num,  Up: Runtime Library Routines
  
! 3.1 ‘omp_get_active_level’ - Number of parallel regions
  =======================================================
  
  _Description_:
*************** _Description_:
*** 630,639 ****
       blocks, which enclose the calling call.
  
  _C/C++_
!      _Prototype_:   'int omp_get_active_level(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_active_level()'
  
  _See also_:
       *note omp_get_level::, *note omp_get_max_active_levels::, *note
--- 630,639 ----
       blocks, which enclose the calling call.
  
  _C/C++_
!      _Prototype_:   ‘int omp_get_active_level(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_active_level()’
  
  _See also_:
       *note omp_get_level::, *note omp_get_max_active_levels::, *note
*************** _Reference_:
*** 645,665 ****
  
  File: libgomp.info,  Node: omp_get_ancestor_thread_num,  Next: omp_get_cancellation,  Prev: omp_get_active_level,  Up: Runtime Library Routines
  
! 3.2 'omp_get_ancestor_thread_num' - Ancestor thread ID
  ======================================================
  
  _Description_:
       This function returns the thread identification number for the
       given nesting level of the current thread.  For values of LEVEL
!      outside zero to 'omp_get_level' -1 is returned; if LEVEL is
!      'omp_get_level' the result is identical to 'omp_get_thread_num'.
  
  _C/C++_
!      _Prototype_:   'int omp_get_ancestor_thread_num(int level);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_ancestor_thread_num(level)'
!                     'integer level'
  
  _See also_:
       *note omp_get_level::, *note omp_get_thread_num::, *note
--- 645,665 ----
  
  File: libgomp.info,  Node: omp_get_ancestor_thread_num,  Next: omp_get_cancellation,  Prev: omp_get_active_level,  Up: Runtime Library Routines
  
! 3.2 ‘omp_get_ancestor_thread_num’ - Ancestor thread ID
  ======================================================
  
  _Description_:
       This function returns the thread identification number for the
       given nesting level of the current thread.  For values of LEVEL
!      outside zero to ‘omp_get_level’ -1 is returned; if LEVEL is
!      ‘omp_get_level’ the result is identical to ‘omp_get_thread_num’.
  
  _C/C++_
!      _Prototype_:   ‘int omp_get_ancestor_thread_num(int level);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_ancestor_thread_num(level)’
!                     ‘integer level’
  
  _See also_:
       *note omp_get_level::, *note omp_get_thread_num::, *note
*************** _Reference_:
*** 671,690 ****
  
  File: libgomp.info,  Node: omp_get_cancellation,  Next: omp_get_default_device,  Prev: omp_get_ancestor_thread_num,  Up: Runtime Library Routines
  
! 3.3 'omp_get_cancellation' - Whether cancellation support is enabled
  ====================================================================
  
  _Description_:
!      This function returns 'true' if cancellation is activated, 'false'
!      otherwise.  Here, 'true' and 'false' represent their
!      language-specific counterparts.  Unless 'OMP_CANCELLATION' is set
       true, cancellations are deactivated.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_cancellation(void);'
  
  _Fortran_:
!      _Interface_:   'logical function omp_get_cancellation()'
  
  _See also_:
       *note OMP_CANCELLATION::
--- 671,690 ----
  
  File: libgomp.info,  Node: omp_get_cancellation,  Next: omp_get_default_device,  Prev: omp_get_ancestor_thread_num,  Up: Runtime Library Routines
  
! 3.3 ‘omp_get_cancellation’ - Whether cancellation support is enabled
  ====================================================================
  
  _Description_:
!      This function returns ‘true’ if cancellation is activated, ‘false’
!      otherwise.  Here, ‘true’ and ‘false’ represent their
!      language-specific counterparts.  Unless ‘OMP_CANCELLATION’ is set
       true, cancellations are deactivated.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_cancellation(void);’
  
  _Fortran_:
!      _Interface_:   ‘logical function omp_get_cancellation()’
  
  _See also_:
       *note OMP_CANCELLATION::
*************** _Reference_:
*** 695,711 ****
  
  File: libgomp.info,  Node: omp_get_default_device,  Next: omp_get_device_num,  Prev: omp_get_cancellation,  Up: Runtime Library Routines
  
! 3.4 'omp_get_default_device' - Get the default device for target regions
  ========================================================================
  
  _Description_:
       Get the default device for target regions without device clause.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_default_device(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_default_device()'
  
  _See also_:
       *note OMP_DEFAULT_DEVICE::, *note omp_set_default_device::
--- 695,711 ----
  
  File: libgomp.info,  Node: omp_get_default_device,  Next: omp_get_device_num,  Prev: omp_get_cancellation,  Up: Runtime Library Routines
  
! 3.4 ‘omp_get_default_device’ - Get the default device for target regions
  ========================================================================
  
  _Description_:
       Get the default device for target regions without device clause.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_default_device(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_default_device()’
  
  _See also_:
       *note OMP_DEFAULT_DEVICE::, *note omp_set_default_device::
*************** _Reference_:
*** 716,735 ****
  
  File: libgomp.info,  Node: omp_get_device_num,  Next: omp_get_dynamic,  Prev: omp_get_default_device,  Up: Runtime Library Routines
  
! 3.5 'omp_get_device_num' - Return device number of current device
  =================================================================
  
  _Description_:
       This function returns a device number that represents the device
       that the current thread is executing on.  For OpenMP 5.0, this must
!      be equal to the value returned by the 'omp_get_initial_device'
       function when called from the host.
  
  _C/C++_
!      _Prototype_:   'int omp_get_device_num(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_device_num()'
  
  _See also_:
       *note omp_get_initial_device::
--- 716,735 ----
  
  File: libgomp.info,  Node: omp_get_device_num,  Next: omp_get_dynamic,  Prev: omp_get_default_device,  Up: Runtime Library Routines
  
! 3.5 ‘omp_get_device_num’ - Return device number of current device
  =================================================================
  
  _Description_:
       This function returns a device number that represents the device
       that the current thread is executing on.  For OpenMP 5.0, this must
!      be equal to the value returned by the ‘omp_get_initial_device’
       function when called from the host.
  
  _C/C++_
!      _Prototype_:   ‘int omp_get_device_num(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_device_num()’
  
  _See also_:
       *note omp_get_initial_device::
*************** _Reference_:
*** 740,762 ****
  
  File: libgomp.info,  Node: omp_get_dynamic,  Next: omp_get_initial_device,  Prev: omp_get_device_num,  Up: Runtime Library Routines
  
! 3.6 'omp_get_dynamic' - Dynamic teams setting
  =============================================
  
  _Description_:
!      This function returns 'true' if enabled, 'false' otherwise.  Here,
!      'true' and 'false' represent their language-specific counterparts.
  
       The dynamic team setting may be initialized at startup by the
!      'OMP_DYNAMIC' environment variable or at runtime using
!      'omp_set_dynamic'.  If undefined, dynamic adjustment is disabled by
       default.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_dynamic(void);'
  
  _Fortran_:
!      _Interface_:   'logical function omp_get_dynamic()'
  
  _See also_:
       *note omp_set_dynamic::, *note OMP_DYNAMIC::
--- 740,762 ----
  
  File: libgomp.info,  Node: omp_get_dynamic,  Next: omp_get_initial_device,  Prev: omp_get_device_num,  Up: Runtime Library Routines
  
! 3.6 ‘omp_get_dynamic’ - Dynamic teams setting
  =============================================
  
  _Description_:
!      This function returns ‘true’ if enabled, ‘false’ otherwise.  Here,
!      ‘true’ and ‘false’ represent their language-specific counterparts.
  
       The dynamic team setting may be initialized at startup by the
!      ‘OMP_DYNAMIC’ environment variable or at runtime using
!      ‘omp_set_dynamic’.  If undefined, dynamic adjustment is disabled by
       default.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_dynamic(void);’
  
  _Fortran_:
!      _Interface_:   ‘logical function omp_get_dynamic()’
  
  _See also_:
       *note omp_set_dynamic::, *note OMP_DYNAMIC::
*************** _Reference_:
*** 767,785 ****
  
  File: libgomp.info,  Node: omp_get_initial_device,  Next: omp_get_level,  Prev: omp_get_dynamic,  Up: Runtime Library Routines
  
! 3.7 'omp_get_initial_device' - Return device number of initial device
  =====================================================================
  
  _Description_:
       This function returns a device number that represents the host
       device.  For OpenMP 5.1, this must be equal to the value returned
!      by the 'omp_get_num_devices' function.
  
  _C/C++_
!      _Prototype_:   'int omp_get_initial_device(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_initial_device()'
  
  _See also_:
       *note omp_get_num_devices::
--- 767,785 ----
  
  File: libgomp.info,  Node: omp_get_initial_device,  Next: omp_get_level,  Prev: omp_get_dynamic,  Up: Runtime Library Routines
  
! 3.7 ‘omp_get_initial_device’ - Return device number of initial device
  =====================================================================
  
  _Description_:
       This function returns a device number that represents the host
       device.  For OpenMP 5.1, this must be equal to the value returned
!      by the ‘omp_get_num_devices’ function.
  
  _C/C++_
!      _Prototype_:   ‘int omp_get_initial_device(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_initial_device()’
  
  _See also_:
       *note omp_get_num_devices::
*************** _Reference_:
*** 790,796 ****
  
  File: libgomp.info,  Node: omp_get_level,  Next: omp_get_max_active_levels,  Prev: omp_get_initial_device,  Up: Runtime Library Routines
  
! 3.8 'omp_get_level' - Obtain the current nesting level
  ======================================================
  
  _Description_:
--- 790,796 ----
  
  File: libgomp.info,  Node: omp_get_level,  Next: omp_get_max_active_levels,  Prev: omp_get_initial_device,  Up: Runtime Library Routines
  
! 3.8 ‘omp_get_level’ - Obtain the current nesting level
  ======================================================
  
  _Description_:
*************** _Description_:
*** 798,807 ****
       which enclose the calling call.
  
  _C/C++_
!      _Prototype_:   'int omp_get_level(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_level()'
  
  _See also_:
       *note omp_get_active_level::
--- 798,807 ----
       which enclose the calling call.
  
  _C/C++_
!      _Prototype_:   ‘int omp_get_level(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_level()’
  
  _See also_:
       *note omp_get_active_level::
*************** _Reference_:
*** 812,818 ****
  
  File: libgomp.info,  Node: omp_get_max_active_levels,  Next: omp_get_max_task_priority,  Prev: omp_get_level,  Up: Runtime Library Routines
  
! 3.9 'omp_get_max_active_levels' - Current maximum number of active regions
  ==========================================================================
  
  _Description_:
--- 812,818 ----
  
  File: libgomp.info,  Node: omp_get_max_active_levels,  Next: omp_get_max_task_priority,  Prev: omp_get_level,  Up: Runtime Library Routines
  
! 3.9 ‘omp_get_max_active_levels’ - Current maximum number of active regions
  ==========================================================================
  
  _Description_:
*************** _Description_:
*** 820,829 ****
       parallel regions.
  
  _C/C++_
!      _Prototype_:   'int omp_get_max_active_levels(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_max_active_levels()'
  
  _See also_:
       *note omp_set_max_active_levels::, *note omp_get_active_level::
--- 820,829 ----
       parallel regions.
  
  _C/C++_
!      _Prototype_:   ‘int omp_get_max_active_levels(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_max_active_levels()’
  
  _See also_:
       *note omp_set_max_active_levels::, *note omp_get_active_level::
*************** _Reference_:
*** 834,840 ****
  
  File: libgomp.info,  Node: omp_get_max_task_priority,  Next: omp_get_max_teams,  Prev: omp_get_max_active_levels,  Up: Runtime Library Routines
  
! 3.10 'omp_get_max_task_priority' - Maximum priority value
  =========================================================
  
  that can be set for tasks.
--- 834,840 ----
  
  File: libgomp.info,  Node: omp_get_max_task_priority,  Next: omp_get_max_teams,  Prev: omp_get_max_active_levels,  Up: Runtime Library Routines
  
! 3.10 ‘omp_get_max_task_priority’ - Maximum priority value
  =========================================================
  
  that can be set for tasks.
*************** _Description_:
*** 843,852 ****
       tasks.
  
  _C/C++_
!      _Prototype_:   'int omp_get_max_task_priority(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_max_task_priority()'
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.29.
--- 843,852 ----
       tasks.
  
  _C/C++_
!      _Prototype_:   ‘int omp_get_max_task_priority(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_max_task_priority()’
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.29.
*************** _Reference_:
*** 854,871 ****
  
  File: libgomp.info,  Node: omp_get_max_teams,  Next: omp_get_max_threads,  Prev: omp_get_max_task_priority,  Up: Runtime Library Routines
  
! 3.11 'omp_get_max_teams' - Maximum number of teams of teams region
  ==================================================================
  
  _Description_:
       Return the maximum number of teams used for the teams region that
!      does not use the clause 'num_teams'.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_max_teams(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_max_teams()'
  
  _See also_:
       *note omp_set_num_teams::, *note omp_get_num_teams::
--- 854,871 ----
  
  File: libgomp.info,  Node: omp_get_max_teams,  Next: omp_get_max_threads,  Prev: omp_get_max_task_priority,  Up: Runtime Library Routines
  
! 3.11 ‘omp_get_max_teams’ - Maximum number of teams of teams region
  ==================================================================
  
  _Description_:
       Return the maximum number of teams used for the teams region that
!      does not use the clause ‘num_teams’.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_max_teams(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_max_teams()’
  
  _See also_:
       *note omp_set_num_teams::, *note omp_get_num_teams::
*************** _Reference_:
*** 876,893 ****
  
  File: libgomp.info,  Node: omp_get_max_threads,  Next: omp_get_nested,  Prev: omp_get_max_teams,  Up: Runtime Library Routines
  
! 3.12 'omp_get_max_threads' - Maximum number of threads of parallel region
  =========================================================================
  
  _Description_:
       Return the maximum number of threads used for the current parallel
!      region that does not use the clause 'num_threads'.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_max_threads(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_max_threads()'
  
  _See also_:
       *note omp_set_num_threads::, *note omp_set_dynamic::, *note
--- 876,893 ----
  
  File: libgomp.info,  Node: omp_get_max_threads,  Next: omp_get_nested,  Prev: omp_get_max_teams,  Up: Runtime Library Routines
  
! 3.12 ‘omp_get_max_threads’ - Maximum number of threads of parallel region
  =========================================================================
  
  _Description_:
       Return the maximum number of threads used for the current parallel
!      region that does not use the clause ‘num_threads’.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_max_threads(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_max_threads()’
  
  _See also_:
       *note omp_set_num_threads::, *note omp_set_dynamic::, *note
*************** _Reference_:
*** 899,932 ****
  
  File: libgomp.info,  Node: omp_get_nested,  Next: omp_get_num_devices,  Prev: omp_get_max_threads,  Up: Runtime Library Routines
  
! 3.13 'omp_get_nested' - Nested parallel regions
  ===============================================
  
  _Description_:
!      This function returns 'true' if nested parallel regions are
!      enabled, 'false' otherwise.  Here, 'true' and 'false' represent
       their language-specific counterparts.
  
       The state of nested parallel regions at startup depends on several
!      environment variables.  If 'OMP_MAX_ACTIVE_LEVELS' is defined and
       is set to greater than one, then nested parallel regions will be
!      enabled.  If not defined, then the value of the 'OMP_NESTED'
       environment variable will be followed if defined.  If neither are
!      defined, then if either 'OMP_NUM_THREADS' or 'OMP_PROC_BIND' are
       defined with a list of more than one value, then nested parallel
       regions are enabled.  If none of these are defined, then nested
       parallel regions are disabled by default.
  
       Nested parallel regions can be enabled or disabled at runtime using
!      'omp_set_nested', or by setting the maximum number of nested
!      regions with 'omp_set_max_active_levels' to one to disable, or
       above one to enable.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_nested(void);'
  
  _Fortran_:
!      _Interface_:   'logical function omp_get_nested()'
  
  _See also_:
       *note omp_set_max_active_levels::, *note omp_set_nested::, *note
--- 899,932 ----
  
  File: libgomp.info,  Node: omp_get_nested,  Next: omp_get_num_devices,  Prev: omp_get_max_threads,  Up: Runtime Library Routines
  
! 3.13 ‘omp_get_nested’ - Nested parallel regions
  ===============================================
  
  _Description_:
!      This function returns ‘true’ if nested parallel regions are
!      enabled, ‘false’ otherwise.  Here, ‘true’ and ‘false’ represent
       their language-specific counterparts.
  
       The state of nested parallel regions at startup depends on several
!      environment variables.  If ‘OMP_MAX_ACTIVE_LEVELS’ is defined and
       is set to greater than one, then nested parallel regions will be
!      enabled.  If not defined, then the value of the ‘OMP_NESTED’
       environment variable will be followed if defined.  If neither are
!      defined, then if either ‘OMP_NUM_THREADS’ or ‘OMP_PROC_BIND’ are
       defined with a list of more than one value, then nested parallel
       regions are enabled.  If none of these are defined, then nested
       parallel regions are disabled by default.
  
       Nested parallel regions can be enabled or disabled at runtime using
!      ‘omp_set_nested’, or by setting the maximum number of nested
!      regions with ‘omp_set_max_active_levels’ to one to disable, or
       above one to enable.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_nested(void);’
  
  _Fortran_:
!      _Interface_:   ‘logical function omp_get_nested()’
  
  _See also_:
       *note omp_set_max_active_levels::, *note omp_set_nested::, *note
*************** _Reference_:
*** 938,954 ****
  
  File: libgomp.info,  Node: omp_get_num_devices,  Next: omp_get_num_procs,  Prev: omp_get_nested,  Up: Runtime Library Routines
  
! 3.14 'omp_get_num_devices' - Number of target devices
  =====================================================
  
  _Description_:
       Returns the number of target devices.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_num_devices(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_num_devices()'
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.31.
--- 938,954 ----
  
  File: libgomp.info,  Node: omp_get_num_devices,  Next: omp_get_num_procs,  Prev: omp_get_nested,  Up: Runtime Library Routines
  
! 3.14 ‘omp_get_num_devices’ - Number of target devices
  =====================================================
  
  _Description_:
       Returns the number of target devices.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_num_devices(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_num_devices()’
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.31.
*************** _Reference_:
*** 956,972 ****
  
  File: libgomp.info,  Node: omp_get_num_procs,  Next: omp_get_num_teams,  Prev: omp_get_num_devices,  Up: Runtime Library Routines
  
! 3.15 'omp_get_num_procs' - Number of processors online
  ======================================================
  
  _Description_:
       Returns the number of processors online on that device.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_num_procs(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_num_procs()'
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.5.
--- 956,972 ----
  
  File: libgomp.info,  Node: omp_get_num_procs,  Next: omp_get_num_teams,  Prev: omp_get_num_devices,  Up: Runtime Library Routines
  
! 3.15 ‘omp_get_num_procs’ - Number of processors online
  ======================================================
  
  _Description_:
       Returns the number of processors online on that device.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_num_procs(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_num_procs()’
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.5.
*************** _Reference_:
*** 974,990 ****
  
  File: libgomp.info,  Node: omp_get_num_teams,  Next: omp_get_num_threads,  Prev: omp_get_num_procs,  Up: Runtime Library Routines
  
! 3.16 'omp_get_num_teams' - Number of teams
  ==========================================
  
  _Description_:
       Returns the number of teams in the current team region.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_num_teams(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_num_teams()'
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.32.
--- 974,990 ----
  
  File: libgomp.info,  Node: omp_get_num_teams,  Next: omp_get_num_threads,  Prev: omp_get_num_procs,  Up: Runtime Library Routines
  
! 3.16 ‘omp_get_num_teams’ - Number of teams
  ==========================================
  
  _Description_:
       Returns the number of teams in the current team region.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_num_teams(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_num_teams()’
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.32.
*************** _Reference_:
*** 992,1016 ****
  
  File: libgomp.info,  Node: omp_get_num_threads,  Next: omp_get_proc_bind,  Prev: omp_get_num_teams,  Up: Runtime Library Routines
  
! 3.17 'omp_get_num_threads' - Size of the active team
  ====================================================
  
  _Description_:
       Returns the number of threads in the current team.  In a sequential
!      section of the program 'omp_get_num_threads' returns 1.
  
       The default team size may be initialized at startup by the
!      'OMP_NUM_THREADS' environment variable.  At runtime, the size of
!      the current team may be set either by the 'NUM_THREADS' clause or
!      by 'omp_set_num_threads'.  If none of the above were used to define
!      a specific value and 'OMP_DYNAMIC' is disabled, one thread per CPU
       online is used.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_num_threads(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_num_threads()'
  
  _See also_:
       *note omp_get_max_threads::, *note omp_set_num_threads::, *note
--- 992,1016 ----
  
  File: libgomp.info,  Node: omp_get_num_threads,  Next: omp_get_proc_bind,  Prev: omp_get_num_teams,  Up: Runtime Library Routines
  
! 3.17 ‘omp_get_num_threads’ - Size of the active team
  ====================================================
  
  _Description_:
       Returns the number of threads in the current team.  In a sequential
!      section of the program ‘omp_get_num_threads’ returns 1.
  
       The default team size may be initialized at startup by the
!      ‘OMP_NUM_THREADS’ environment variable.  At runtime, the size of
!      the current team may be set either by the ‘NUM_THREADS’ clause or
!      by ‘omp_set_num_threads’.  If none of the above were used to define
!      a specific value and ‘OMP_DYNAMIC’ is disabled, one thread per CPU
       online is used.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_num_threads(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_num_threads()’
  
  _See also_:
       *note omp_get_max_threads::, *note omp_set_num_threads::, *note
*************** _Reference_:
*** 1022,1044 ****
  
  File: libgomp.info,  Node: omp_get_proc_bind,  Next: omp_get_schedule,  Prev: omp_get_num_threads,  Up: Runtime Library Routines
  
! 3.18 'omp_get_proc_bind' - Whether threads may be moved between CPUs
  ====================================================================
  
  _Description_:
       This functions returns the currently active thread affinity policy,
!      which is set via 'OMP_PROC_BIND'.  Possible values are
!      'omp_proc_bind_false', 'omp_proc_bind_true',
!      'omp_proc_bind_primary', 'omp_proc_bind_master',
!      'omp_proc_bind_close' and 'omp_proc_bind_spread', where
!      'omp_proc_bind_master' is an alias for 'omp_proc_bind_primary'.
  
  _C/C++_:
!      _Prototype_:   'omp_proc_bind_t omp_get_proc_bind(void);'
  
  _Fortran_:
!      _Interface_:   'integer(kind=omp_proc_bind_kind) function
!                     omp_get_proc_bind()'
  
  _See also_:
       *note OMP_PROC_BIND::, *note OMP_PLACES::, *note
--- 1022,1044 ----
  
  File: libgomp.info,  Node: omp_get_proc_bind,  Next: omp_get_schedule,  Prev: omp_get_num_threads,  Up: Runtime Library Routines
  
! 3.18 ‘omp_get_proc_bind’ - Whether threads may be moved between CPUs
  ====================================================================
  
  _Description_:
       This functions returns the currently active thread affinity policy,
!      which is set via ‘OMP_PROC_BIND’.  Possible values are
!      ‘omp_proc_bind_false’, ‘omp_proc_bind_true’,
!      ‘omp_proc_bind_primary’, ‘omp_proc_bind_master’,
!      ‘omp_proc_bind_close’ and ‘omp_proc_bind_spread’, where
!      ‘omp_proc_bind_master’ is an alias for ‘omp_proc_bind_primary’.
  
  _C/C++_:
!      _Prototype_:   ‘omp_proc_bind_t omp_get_proc_bind(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer(kind=omp_proc_bind_kind) function
!                     omp_get_proc_bind()’
  
  _See also_:
       *note OMP_PROC_BIND::, *note OMP_PLACES::, *note
*************** _Reference_:
*** 1050,1072 ****
  
  File: libgomp.info,  Node: omp_get_schedule,  Next: omp_get_supported_active_levels,  Prev: omp_get_proc_bind,  Up: Runtime Library Routines
  
! 3.19 'omp_get_schedule' - Obtain the runtime scheduling method
  ==============================================================
  
  _Description_:
       Obtain the runtime scheduling method.  The KIND argument will be
!      set to the value 'omp_sched_static', 'omp_sched_dynamic',
!      'omp_sched_guided' or 'omp_sched_auto'.  The second argument,
       CHUNK_SIZE, is set to the chunk size.
  
  _C/C++_
!      _Prototype_:   'void omp_get_schedule(omp_sched_t *kind, int
!                     *chunk_size);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_get_schedule(kind, chunk_size)'
!                     'integer(kind=omp_sched_kind) kind'
!                     'integer chunk_size'
  
  _See also_:
       *note omp_set_schedule::, *note OMP_SCHEDULE::
--- 1050,1072 ----
  
  File: libgomp.info,  Node: omp_get_schedule,  Next: omp_get_supported_active_levels,  Prev: omp_get_proc_bind,  Up: Runtime Library Routines
  
! 3.19 ‘omp_get_schedule’ - Obtain the runtime scheduling method
  ==============================================================
  
  _Description_:
       Obtain the runtime scheduling method.  The KIND argument will be
!      set to the value ‘omp_sched_static’, ‘omp_sched_dynamic’,
!      ‘omp_sched_guided’ or ‘omp_sched_auto’.  The second argument,
       CHUNK_SIZE, is set to the chunk size.
  
  _C/C++_
!      _Prototype_:   ‘void omp_get_schedule(omp_sched_t *kind, int
!                     *chunk_size);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_get_schedule(kind, chunk_size)’
!                     ‘integer(kind=omp_sched_kind) kind’
!                     ‘integer chunk_size’
  
  _See also_:
       *note omp_set_schedule::, *note OMP_SCHEDULE::
*************** _Reference_:
*** 1077,1083 ****
  
  File: libgomp.info,  Node: omp_get_supported_active_levels,  Next: omp_get_team_num,  Prev: omp_get_schedule,  Up: Runtime Library Routines
  
! 3.20 'omp_get_supported_active_levels' - Maximum number of active regions supported
  ===================================================================================
  
  _Description_:
--- 1077,1083 ----
  
  File: libgomp.info,  Node: omp_get_supported_active_levels,  Next: omp_get_team_num,  Prev: omp_get_schedule,  Up: Runtime Library Routines
  
! 3.20 ‘omp_get_supported_active_levels’ - Maximum number of active regions supported
  ===================================================================================
  
  _Description_:
*************** _Description_:
*** 1085,1094 ****
       regions supported by this implementation.
  
  _C/C++_
!      _Prototype_:   'int omp_get_supported_active_levels(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_supported_active_levels()'
  
  _See also_:
       *note omp_get_max_active_levels::, *note
--- 1085,1094 ----
       regions supported by this implementation.
  
  _C/C++_
!      _Prototype_:   ‘int omp_get_supported_active_levels(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_supported_active_levels()’
  
  _See also_:
       *note omp_get_max_active_levels::, *note
*************** _Reference_:
*** 1100,1116 ****
  
  File: libgomp.info,  Node: omp_get_team_num,  Next: omp_get_team_size,  Prev: omp_get_supported_active_levels,  Up: Runtime Library Routines
  
! 3.21 'omp_get_team_num' - Get team number
  =========================================
  
  _Description_:
       Returns the team number of the calling thread.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_team_num(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_team_num()'
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.33.
--- 1100,1116 ----
  
  File: libgomp.info,  Node: omp_get_team_num,  Next: omp_get_team_size,  Prev: omp_get_supported_active_levels,  Up: Runtime Library Routines
  
! 3.21 ‘omp_get_team_num’ - Get team number
  =========================================
  
  _Description_:
       Returns the team number of the calling thread.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_team_num(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_team_num()’
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.33.
*************** _Reference_:
*** 1118,1139 ****
  
  File: libgomp.info,  Node: omp_get_team_size,  Next: omp_get_teams_thread_limit,  Prev: omp_get_team_num,  Up: Runtime Library Routines
  
! 3.22 'omp_get_team_size' - Number of threads in a team
  ======================================================
  
  _Description_:
       This function returns the number of threads in a thread team to
       which either the current thread or its ancestor belongs.  For
!      values of LEVEL outside zero to 'omp_get_level', -1 is returned; if
!      LEVEL is zero, 1 is returned, and for 'omp_get_level', the result
!      is identical to 'omp_get_num_threads'.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_team_size(int level);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_team_size(level)'
!                     'integer level'
  
  _See also_:
       *note omp_get_num_threads::, *note omp_get_level::, *note
--- 1118,1139 ----
  
  File: libgomp.info,  Node: omp_get_team_size,  Next: omp_get_teams_thread_limit,  Prev: omp_get_team_num,  Up: Runtime Library Routines
  
! 3.22 ‘omp_get_team_size’ - Number of threads in a team
  ======================================================
  
  _Description_:
       This function returns the number of threads in a thread team to
       which either the current thread or its ancestor belongs.  For
!      values of LEVEL outside zero to ‘omp_get_level’, -1 is returned; if
!      LEVEL is zero, 1 is returned, and for ‘omp_get_level’, the result
!      is identical to ‘omp_get_num_threads’.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_team_size(int level);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_team_size(level)’
!                     ‘integer level’
  
  _See also_:
       *note omp_get_num_threads::, *note omp_get_level::, *note
*************** _Reference_:
*** 1145,1151 ****
  
  File: libgomp.info,  Node: omp_get_teams_thread_limit,  Next: omp_get_thread_limit,  Prev: omp_get_team_size,  Up: Runtime Library Routines
  
! 3.23 'omp_get_teams_thread_limit' - Maximum number of threads imposed by teams
  ==============================================================================
  
  _Description_:
--- 1145,1151 ----
  
  File: libgomp.info,  Node: omp_get_teams_thread_limit,  Next: omp_get_thread_limit,  Prev: omp_get_team_size,  Up: Runtime Library Routines
  
! 3.23 ‘omp_get_teams_thread_limit’ - Maximum number of threads imposed by teams
  ==============================================================================
  
  _Description_:
*************** _Description_:
*** 1153,1162 ****
       participate in each team created by a teams construct.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_teams_thread_limit(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_teams_thread_limit()'
  
  _See also_:
       *note omp_set_teams_thread_limit::, *note OMP_TEAMS_THREAD_LIMIT::
--- 1153,1162 ----
       participate in each team created by a teams construct.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_teams_thread_limit(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_teams_thread_limit()’
  
  _See also_:
       *note omp_set_teams_thread_limit::, *note OMP_TEAMS_THREAD_LIMIT::
*************** _Reference_:
*** 1167,1183 ****
  
  File: libgomp.info,  Node: omp_get_thread_limit,  Next: omp_get_thread_num,  Prev: omp_get_teams_thread_limit,  Up: Runtime Library Routines
  
! 3.24 'omp_get_thread_limit' - Maximum number of threads
  =======================================================
  
  _Description_:
       Return the maximum number of threads of the program.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_thread_limit(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_thread_limit()'
  
  _See also_:
       *note omp_get_max_threads::, *note OMP_THREAD_LIMIT::
--- 1167,1183 ----
  
  File: libgomp.info,  Node: omp_get_thread_limit,  Next: omp_get_thread_num,  Prev: omp_get_teams_thread_limit,  Up: Runtime Library Routines
  
! 3.24 ‘omp_get_thread_limit’ - Maximum number of threads
  =======================================================
  
  _Description_:
       Return the maximum number of threads of the program.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_thread_limit(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_thread_limit()’
  
  _See also_:
       *note omp_get_max_threads::, *note OMP_THREAD_LIMIT::
*************** _Reference_:
*** 1188,1208 ****
  
  File: libgomp.info,  Node: omp_get_thread_num,  Next: omp_in_parallel,  Prev: omp_get_thread_limit,  Up: Runtime Library Routines
  
! 3.25 'omp_get_thread_num' - Current thread ID
  =============================================
  
  _Description_:
       Returns a unique thread identification number within the current
!      team.  In a sequential parts of the program, 'omp_get_thread_num'
       always returns 0.  In parallel regions the return value varies from
!      0 to 'omp_get_num_threads'-1 inclusive.  The return value of the
       primary thread of a team is always 0.
  
  _C/C++_:
!      _Prototype_:   'int omp_get_thread_num(void);'
  
  _Fortran_:
!      _Interface_:   'integer function omp_get_thread_num()'
  
  _See also_:
       *note omp_get_num_threads::, *note omp_get_ancestor_thread_num::
--- 1188,1208 ----
  
  File: libgomp.info,  Node: omp_get_thread_num,  Next: omp_in_parallel,  Prev: omp_get_thread_limit,  Up: Runtime Library Routines
  
! 3.25 ‘omp_get_thread_num’ - Current thread ID
  =============================================
  
  _Description_:
       Returns a unique thread identification number within the current
!      team.  In a sequential parts of the program, ‘omp_get_thread_num’
       always returns 0.  In parallel regions the return value varies from
!      0 to ‘omp_get_num_threads’-1 inclusive.  The return value of the
       primary thread of a team is always 0.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_get_thread_num(void);’
  
  _Fortran_:
!      _Interface_:   ‘integer function omp_get_thread_num()’
  
  _See also_:
       *note omp_get_num_threads::, *note omp_get_ancestor_thread_num::
*************** _Reference_:
*** 1213,1231 ****
  
  File: libgomp.info,  Node: omp_in_parallel,  Next: omp_in_final,  Prev: omp_get_thread_num,  Up: Runtime Library Routines
  
! 3.26 'omp_in_parallel' - Whether a parallel region is active
  ============================================================
  
  _Description_:
!      This function returns 'true' if currently running in parallel,
!      'false' otherwise.  Here, 'true' and 'false' represent their
       language-specific counterparts.
  
  _C/C++_:
!      _Prototype_:   'int omp_in_parallel(void);'
  
  _Fortran_:
!      _Interface_:   'logical function omp_in_parallel()'
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.6.
--- 1213,1231 ----
  
  File: libgomp.info,  Node: omp_in_parallel,  Next: omp_in_final,  Prev: omp_get_thread_num,  Up: Runtime Library Routines
  
! 3.26 ‘omp_in_parallel’ - Whether a parallel region is active
  ============================================================
  
  _Description_:
!      This function returns ‘true’ if currently running in parallel,
!      ‘false’ otherwise.  Here, ‘true’ and ‘false’ represent their
       language-specific counterparts.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_in_parallel(void);’
  
  _Fortran_:
!      _Interface_:   ‘logical function omp_in_parallel()’
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.6.
*************** _Reference_:
*** 1233,1251 ****
  
  File: libgomp.info,  Node: omp_in_final,  Next: omp_is_initial_device,  Prev: omp_in_parallel,  Up: Runtime Library Routines
  
! 3.27 'omp_in_final' - Whether in final or included task region
  ==============================================================
  
  _Description_:
!      This function returns 'true' if currently running in a final or
!      included task region, 'false' otherwise.  Here, 'true' and 'false'
       represent their language-specific counterparts.
  
  _C/C++_:
!      _Prototype_:   'int omp_in_final(void);'
  
  _Fortran_:
!      _Interface_:   'logical function omp_in_final()'
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.21.
--- 1233,1251 ----
  
  File: libgomp.info,  Node: omp_in_final,  Next: omp_is_initial_device,  Prev: omp_in_parallel,  Up: Runtime Library Routines
  
! 3.27 ‘omp_in_final’ - Whether in final or included task region
  ==============================================================
  
  _Description_:
!      This function returns ‘true’ if currently running in a final or
!      included task region, ‘false’ otherwise.  Here, ‘true’ and ‘false’
       represent their language-specific counterparts.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_in_final(void);’
  
  _Fortran_:
!      _Interface_:   ‘logical function omp_in_final()’
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.21.
*************** _Reference_:
*** 1253,1271 ****
  
  File: libgomp.info,  Node: omp_is_initial_device,  Next: omp_set_default_device,  Prev: omp_in_final,  Up: Runtime Library Routines
  
! 3.28 'omp_is_initial_device' - Whether executing on the host device
  ===================================================================
  
  _Description_:
!      This function returns 'true' if currently running on the host
!      device, 'false' otherwise.  Here, 'true' and 'false' represent
       their language-specific counterparts.
  
  _C/C++_:
!      _Prototype_:   'int omp_is_initial_device(void);'
  
  _Fortran_:
!      _Interface_:   'logical function omp_is_initial_device()'
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.34.
--- 1253,1271 ----
  
  File: libgomp.info,  Node: omp_is_initial_device,  Next: omp_set_default_device,  Prev: omp_in_final,  Up: Runtime Library Routines
  
! 3.28 ‘omp_is_initial_device’ - Whether executing on the host device
  ===================================================================
  
  _Description_:
!      This function returns ‘true’ if currently running on the host
!      device, ‘false’ otherwise.  Here, ‘true’ and ‘false’ represent
       their language-specific counterparts.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_is_initial_device(void);’
  
  _Fortran_:
!      _Interface_:   ‘logical function omp_is_initial_device()’
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 3.2.34.
*************** _Reference_:
*** 1273,1279 ****
  
  File: libgomp.info,  Node: omp_set_default_device,  Next: omp_set_dynamic,  Prev: omp_is_initial_device,  Up: Runtime Library Routines
  
! 3.29 'omp_set_default_device' - Set the default device for target regions
  =========================================================================
  
  _Description_:
--- 1273,1279 ----
  
  File: libgomp.info,  Node: omp_set_default_device,  Next: omp_set_dynamic,  Prev: omp_is_initial_device,  Up: Runtime Library Routines
  
! 3.29 ‘omp_set_default_device’ - Set the default device for target regions
  =========================================================================
  
  _Description_:
*************** _Description_:
*** 1281,1291 ****
       The argument shall be a nonnegative device number.
  
  _C/C++_:
!      _Prototype_:   'void omp_set_default_device(int device_num);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_set_default_device(device_num)'
!                     'integer device_num'
  
  _See also_:
       *note OMP_DEFAULT_DEVICE::, *note omp_get_default_device::
--- 1281,1291 ----
       The argument shall be a nonnegative device number.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_set_default_device(int device_num);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_set_default_device(device_num)’
!                     ‘integer device_num’
  
  _See also_:
       *note OMP_DEFAULT_DEVICE::, *note omp_get_default_device::
*************** _Reference_:
*** 1296,1316 ****
  
  File: libgomp.info,  Node: omp_set_dynamic,  Next: omp_set_max_active_levels,  Prev: omp_set_default_device,  Up: Runtime Library Routines
  
! 3.30 'omp_set_dynamic' - Enable/disable dynamic teams
  =====================================================
  
  _Description_:
       Enable or disable the dynamic adjustment of the number of threads
       within a team.  The function takes the language-specific equivalent
!      of 'true' and 'false', where 'true' enables dynamic adjustment of
!      team sizes and 'false' disables it.
  
  _C/C++_:
!      _Prototype_:   'void omp_set_dynamic(int dynamic_threads);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_set_dynamic(dynamic_threads)'
!                     'logical, intent(in) :: dynamic_threads'
  
  _See also_:
       *note OMP_DYNAMIC::, *note omp_get_dynamic::
--- 1296,1316 ----
  
  File: libgomp.info,  Node: omp_set_dynamic,  Next: omp_set_max_active_levels,  Prev: omp_set_default_device,  Up: Runtime Library Routines
  
! 3.30 ‘omp_set_dynamic’ - Enable/disable dynamic teams
  =====================================================
  
  _Description_:
       Enable or disable the dynamic adjustment of the number of threads
       within a team.  The function takes the language-specific equivalent
!      of ‘true’ and ‘false’, where ‘true’ enables dynamic adjustment of
!      team sizes and ‘false’ disables it.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_set_dynamic(int dynamic_threads);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_set_dynamic(dynamic_threads)’
!                     ‘logical, intent(in) :: dynamic_threads’
  
  _See also_:
       *note OMP_DYNAMIC::, *note omp_get_dynamic::
*************** _Reference_:
*** 1321,1340 ****
  
  File: libgomp.info,  Node: omp_set_max_active_levels,  Next: omp_set_nested,  Prev: omp_set_dynamic,  Up: Runtime Library Routines
  
! 3.31 'omp_set_max_active_levels' - Limits the number of active parallel regions
  ===============================================================================
  
  _Description_:
       This function limits the maximum allowed number of nested, active
       parallel regions.  MAX_LEVELS must be less or equal to the value
!      returned by 'omp_get_supported_active_levels'.
  
  _C/C++_
!      _Prototype_:   'void omp_set_max_active_levels(int max_levels);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_set_max_active_levels(max_levels)'
!                     'integer max_levels'
  
  _See also_:
       *note omp_get_max_active_levels::, *note omp_get_active_level::,
--- 1321,1340 ----
  
  File: libgomp.info,  Node: omp_set_max_active_levels,  Next: omp_set_nested,  Prev: omp_set_dynamic,  Up: Runtime Library Routines
  
! 3.31 ‘omp_set_max_active_levels’ - Limits the number of active parallel regions
  ===============================================================================
  
  _Description_:
       This function limits the maximum allowed number of nested, active
       parallel regions.  MAX_LEVELS must be less or equal to the value
!      returned by ‘omp_get_supported_active_levels’.
  
  _C/C++_
!      _Prototype_:   ‘void omp_set_max_active_levels(int max_levels);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_set_max_active_levels(max_levels)’
!                     ‘integer max_levels’
  
  _See also_:
       *note omp_get_max_active_levels::, *note omp_get_active_level::,
*************** _Reference_:
*** 1346,1359 ****
  
  File: libgomp.info,  Node: omp_set_nested,  Next: omp_set_num_teams,  Prev: omp_set_max_active_levels,  Up: Runtime Library Routines
  
! 3.32 'omp_set_nested' - Enable/disable nested parallel regions
  ==============================================================
  
  _Description_:
       Enable or disable nested parallel regions, i.e., whether team
       members are allowed to create new teams.  The function takes the
!      language-specific equivalent of 'true' and 'false', where 'true'
!      enables dynamic adjustment of team sizes and 'false' disables it.
  
       Enabling nested parallel regions will also set the maximum number
       of active nested regions to the maximum supported.  Disabling
--- 1346,1359 ----
  
  File: libgomp.info,  Node: omp_set_nested,  Next: omp_set_num_teams,  Prev: omp_set_max_active_levels,  Up: Runtime Library Routines
  
! 3.32 ‘omp_set_nested’ - Enable/disable nested parallel regions
  ==============================================================
  
  _Description_:
       Enable or disable nested parallel regions, i.e., whether team
       members are allowed to create new teams.  The function takes the
!      language-specific equivalent of ‘true’ and ‘false’, where ‘true’
!      enables dynamic adjustment of team sizes and ‘false’ disables it.
  
       Enabling nested parallel regions will also set the maximum number
       of active nested regions to the maximum supported.  Disabling
*************** _Description_:
*** 1361,1371 ****
       nested regions to one.
  
  _C/C++_:
!      _Prototype_:   'void omp_set_nested(int nested);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_set_nested(nested)'
!                     'logical, intent(in) :: nested'
  
  _See also_:
       *note omp_get_nested::, *note omp_set_max_active_levels::, *note
--- 1361,1371 ----
       nested regions to one.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_set_nested(int nested);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_set_nested(nested)’
!                     ‘logical, intent(in) :: nested’
  
  _See also_:
       *note omp_get_nested::, *note omp_set_max_active_levels::, *note
*************** _Reference_:
*** 1377,1396 ****
  
  File: libgomp.info,  Node: omp_set_num_teams,  Next: omp_set_num_threads,  Prev: omp_set_nested,  Up: Runtime Library Routines
  
! 3.33 'omp_set_num_teams' - Set upper teams limit for teams construct
  ====================================================================
  
  _Description_:
       Specifies the upper bound for number of teams created by the teams
!      construct which does not specify a 'num_teams' clause.  The
!      argument of 'omp_set_num_teams' shall be a positive integer.
  
  _C/C++_:
!      _Prototype_:   'void omp_set_num_teams(int num_teams);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_set_num_teams(num_teams)'
!                     'integer, intent(in) :: num_teams'
  
  _See also_:
       *note OMP_NUM_TEAMS::, *note omp_get_num_teams::, *note
--- 1377,1396 ----
  
  File: libgomp.info,  Node: omp_set_num_teams,  Next: omp_set_num_threads,  Prev: omp_set_nested,  Up: Runtime Library Routines
  
! 3.33 ‘omp_set_num_teams’ - Set upper teams limit for teams construct
  ====================================================================
  
  _Description_:
       Specifies the upper bound for number of teams created by the teams
!      construct which does not specify a ‘num_teams’ clause.  The
!      argument of ‘omp_set_num_teams’ shall be a positive integer.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_set_num_teams(int num_teams);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_set_num_teams(num_teams)’
!                     ‘integer, intent(in) :: num_teams’
  
  _See also_:
       *note OMP_NUM_TEAMS::, *note omp_get_num_teams::, *note
*************** _Reference_:
*** 1402,1421 ****
  
  File: libgomp.info,  Node: omp_set_num_threads,  Next: omp_set_schedule,  Prev: omp_set_num_teams,  Up: Runtime Library Routines
  
! 3.34 'omp_set_num_threads' - Set upper team size limit
  ======================================================
  
  _Description_:
       Specifies the number of threads used by default in subsequent
!      parallel sections, if those do not specify a 'num_threads' clause.
!      The argument of 'omp_set_num_threads' shall be a positive integer.
  
  _C/C++_:
!      _Prototype_:   'void omp_set_num_threads(int num_threads);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_set_num_threads(num_threads)'
!                     'integer, intent(in) :: num_threads'
  
  _See also_:
       *note OMP_NUM_THREADS::, *note omp_get_num_threads::, *note
--- 1402,1421 ----
  
  File: libgomp.info,  Node: omp_set_num_threads,  Next: omp_set_schedule,  Prev: omp_set_num_teams,  Up: Runtime Library Routines
  
! 3.34 ‘omp_set_num_threads’ - Set upper team size limit
  ======================================================
  
  _Description_:
       Specifies the number of threads used by default in subsequent
!      parallel sections, if those do not specify a ‘num_threads’ clause.
!      The argument of ‘omp_set_num_threads’ shall be a positive integer.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_set_num_threads(int num_threads);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_set_num_threads(num_threads)’
!                     ‘integer, intent(in) :: num_threads’
  
  _See also_:
       *note OMP_NUM_THREADS::, *note omp_get_num_threads::, *note
*************** _Reference_:
*** 1427,1451 ****
  
  File: libgomp.info,  Node: omp_set_schedule,  Next: omp_set_teams_thread_limit,  Prev: omp_set_num_threads,  Up: Runtime Library Routines
  
! 3.35 'omp_set_schedule' - Set the runtime scheduling method
  ===========================================================
  
  _Description_:
       Sets the runtime scheduling method.  The KIND argument can have the
!      value 'omp_sched_static', 'omp_sched_dynamic', 'omp_sched_guided'
!      or 'omp_sched_auto'.  Except for 'omp_sched_auto', the chunk size
       is set to the value of CHUNK_SIZE if positive, or to the default
!      value if zero or negative.  For 'omp_sched_auto' the CHUNK_SIZE
       argument is ignored.
  
  _C/C++_
!      _Prototype_:   'void omp_set_schedule(omp_sched_t kind, int
!                     chunk_size);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_set_schedule(kind, chunk_size)'
!                     'integer(kind=omp_sched_kind) kind'
!                     'integer chunk_size'
  
  _See also_:
       *note omp_get_schedule:: *note OMP_SCHEDULE::
--- 1427,1451 ----
  
  File: libgomp.info,  Node: omp_set_schedule,  Next: omp_set_teams_thread_limit,  Prev: omp_set_num_threads,  Up: Runtime Library Routines
  
! 3.35 ‘omp_set_schedule’ - Set the runtime scheduling method
  ===========================================================
  
  _Description_:
       Sets the runtime scheduling method.  The KIND argument can have the
!      value ‘omp_sched_static’, ‘omp_sched_dynamic’, ‘omp_sched_guided’
!      or ‘omp_sched_auto’.  Except for ‘omp_sched_auto’, the chunk size
       is set to the value of CHUNK_SIZE if positive, or to the default
!      value if zero or negative.  For ‘omp_sched_auto’ the CHUNK_SIZE
       argument is ignored.
  
  _C/C++_
!      _Prototype_:   ‘void omp_set_schedule(omp_sched_t kind, int
!                     chunk_size);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_set_schedule(kind, chunk_size)’
!                     ‘integer(kind=omp_sched_kind) kind’
!                     ‘integer chunk_size’
  
  _See also_:
       *note omp_get_schedule:: *note OMP_SCHEDULE::
*************** _Reference_:
*** 1456,1476 ****
  
  File: libgomp.info,  Node: omp_set_teams_thread_limit,  Next: omp_init_lock,  Prev: omp_set_schedule,  Up: Runtime Library Routines
  
! 3.36 'omp_set_teams_thread_limit' - Set upper thread limit for teams construct
  ==============================================================================
  
  _Description_:
       Specifies the upper bound for number of threads that will be
       available for each team created by the teams construct which does
!      not specify a 'thread_limit' clause.  The argument of
!      'omp_set_teams_thread_limit' shall be a positive integer.
  
  _C/C++_:
!      _Prototype_:   'void omp_set_teams_thread_limit(int thread_limit);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_set_teams_thread_limit(thread_limit)'
!                     'integer, intent(in) :: thread_limit'
  
  _See also_:
       *note OMP_TEAMS_THREAD_LIMIT::, *note omp_get_teams_thread_limit::,
--- 1456,1476 ----
  
  File: libgomp.info,  Node: omp_set_teams_thread_limit,  Next: omp_init_lock,  Prev: omp_set_schedule,  Up: Runtime Library Routines
  
! 3.36 ‘omp_set_teams_thread_limit’ - Set upper thread limit for teams construct
  ==============================================================================
  
  _Description_:
       Specifies the upper bound for number of threads that will be
       available for each team created by the teams construct which does
!      not specify a ‘thread_limit’ clause.  The argument of
!      ‘omp_set_teams_thread_limit’ shall be a positive integer.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_set_teams_thread_limit(int thread_limit);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_set_teams_thread_limit(thread_limit)’
!                     ‘integer, intent(in) :: thread_limit’
  
  _See also_:
       *note OMP_TEAMS_THREAD_LIMIT::, *note omp_get_teams_thread_limit::,
*************** _Reference_:
*** 1482,1488 ****
  
  File: libgomp.info,  Node: omp_init_lock,  Next: omp_set_lock,  Prev: omp_set_teams_thread_limit,  Up: Runtime Library Routines
  
! 3.37 'omp_init_lock' - Initialize simple lock
  =============================================
  
  _Description_:
--- 1482,1488 ----
  
  File: libgomp.info,  Node: omp_init_lock,  Next: omp_set_lock,  Prev: omp_set_teams_thread_limit,  Up: Runtime Library Routines
  
! 3.37 ‘omp_init_lock’ - Initialize simple lock
  =============================================
  
  _Description_:
*************** _Description_:
*** 1490,1500 ****
       unlocked state.
  
  _C/C++_:
!      _Prototype_:   'void omp_init_lock(omp_lock_t *lock);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_init_lock(svar)'
!                     'integer(omp_lock_kind), intent(out) :: svar'
  
  _See also_:
       *note omp_destroy_lock::
--- 1490,1500 ----
       unlocked state.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_init_lock(omp_lock_t *lock);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_init_lock(svar)’
!                     ‘integer(omp_lock_kind), intent(out) :: svar’
  
  _See also_:
       *note omp_destroy_lock::
*************** _Reference_:
*** 1505,1525 ****
  
  File: libgomp.info,  Node: omp_set_lock,  Next: omp_test_lock,  Prev: omp_init_lock,  Up: Runtime Library Routines
  
! 3.38 'omp_set_lock' - Wait for and set simple lock
  ==================================================
  
  _Description_:
       Before setting a simple lock, the lock variable must be initialized
!      by 'omp_init_lock'.  The calling thread is blocked until the lock
       is available.  If the lock is already held by the current thread, a
       deadlock occurs.
  
  _C/C++_:
!      _Prototype_:   'void omp_set_lock(omp_lock_t *lock);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_set_lock(svar)'
!                     'integer(omp_lock_kind), intent(inout) :: svar'
  
  _See also_:
       *note omp_init_lock::, *note omp_test_lock::, *note
--- 1505,1525 ----
  
  File: libgomp.info,  Node: omp_set_lock,  Next: omp_test_lock,  Prev: omp_init_lock,  Up: Runtime Library Routines
  
! 3.38 ‘omp_set_lock’ - Wait for and set simple lock
  ==================================================
  
  _Description_:
       Before setting a simple lock, the lock variable must be initialized
!      by ‘omp_init_lock’.  The calling thread is blocked until the lock
       is available.  If the lock is already held by the current thread, a
       deadlock occurs.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_set_lock(omp_lock_t *lock);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_set_lock(svar)’
!                     ‘integer(omp_lock_kind), intent(inout) :: svar’
  
  _See also_:
       *note omp_init_lock::, *note omp_test_lock::, *note
*************** _Reference_:
*** 1531,1552 ****
  
  File: libgomp.info,  Node: omp_test_lock,  Next: omp_unset_lock,  Prev: omp_set_lock,  Up: Runtime Library Routines
  
! 3.39 'omp_test_lock' - Test and set simple lock if available
  ============================================================
  
  _Description_:
       Before setting a simple lock, the lock variable must be initialized
!      by 'omp_init_lock'.  Contrary to 'omp_set_lock', 'omp_test_lock'
       does not block if the lock is not available.  This function returns
!      'true' upon success, 'false' otherwise.  Here, 'true' and 'false'
       represent their language-specific counterparts.
  
  _C/C++_:
!      _Prototype_:   'int omp_test_lock(omp_lock_t *lock);'
  
  _Fortran_:
!      _Interface_:   'logical function omp_test_lock(svar)'
!                     'integer(omp_lock_kind), intent(inout) :: svar'
  
  _See also_:
       *note omp_init_lock::, *note omp_set_lock::, *note omp_set_lock::
--- 1531,1552 ----
  
  File: libgomp.info,  Node: omp_test_lock,  Next: omp_unset_lock,  Prev: omp_set_lock,  Up: Runtime Library Routines
  
! 3.39 ‘omp_test_lock’ - Test and set simple lock if available
  ============================================================
  
  _Description_:
       Before setting a simple lock, the lock variable must be initialized
!      by ‘omp_init_lock’.  Contrary to ‘omp_set_lock’, ‘omp_test_lock’
       does not block if the lock is not available.  This function returns
!      ‘true’ upon success, ‘false’ otherwise.  Here, ‘true’ and ‘false’
       represent their language-specific counterparts.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_test_lock(omp_lock_t *lock);’
  
  _Fortran_:
!      _Interface_:   ‘logical function omp_test_lock(svar)’
!                     ‘integer(omp_lock_kind), intent(inout) :: svar’
  
  _See also_:
       *note omp_init_lock::, *note omp_set_lock::, *note omp_set_lock::
*************** _Reference_:
*** 1557,1579 ****
  
  File: libgomp.info,  Node: omp_unset_lock,  Next: omp_destroy_lock,  Prev: omp_test_lock,  Up: Runtime Library Routines
  
! 3.40 'omp_unset_lock' - Unset simple lock
  =========================================
  
  _Description_:
       A simple lock about to be unset must have been locked by
!      'omp_set_lock' or 'omp_test_lock' before.  In addition, the lock
!      must be held by the thread calling 'omp_unset_lock'.  Then, the
       lock becomes unlocked.  If one or more threads attempted to set the
       lock before, one of them is chosen to, again, set the lock to
       itself.
  
  _C/C++_:
!      _Prototype_:   'void omp_unset_lock(omp_lock_t *lock);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_unset_lock(svar)'
!                     'integer(omp_lock_kind), intent(inout) :: svar'
  
  _See also_:
       *note omp_set_lock::, *note omp_test_lock::
--- 1557,1579 ----
  
  File: libgomp.info,  Node: omp_unset_lock,  Next: omp_destroy_lock,  Prev: omp_test_lock,  Up: Runtime Library Routines
  
! 3.40 ‘omp_unset_lock’ - Unset simple lock
  =========================================
  
  _Description_:
       A simple lock about to be unset must have been locked by
!      ‘omp_set_lock’ or ‘omp_test_lock’ before.  In addition, the lock
!      must be held by the thread calling ‘omp_unset_lock’.  Then, the
       lock becomes unlocked.  If one or more threads attempted to set the
       lock before, one of them is chosen to, again, set the lock to
       itself.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_unset_lock(omp_lock_t *lock);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_unset_lock(svar)’
!                     ‘integer(omp_lock_kind), intent(inout) :: svar’
  
  _See also_:
       *note omp_set_lock::, *note omp_test_lock::
*************** _Reference_:
*** 1584,1590 ****
  
  File: libgomp.info,  Node: omp_destroy_lock,  Next: omp_init_nest_lock,  Prev: omp_unset_lock,  Up: Runtime Library Routines
  
! 3.41 'omp_destroy_lock' - Destroy simple lock
  =============================================
  
  _Description_:
--- 1584,1590 ----
  
  File: libgomp.info,  Node: omp_destroy_lock,  Next: omp_init_nest_lock,  Prev: omp_unset_lock,  Up: Runtime Library Routines
  
! 3.41 ‘omp_destroy_lock’ - Destroy simple lock
  =============================================
  
  _Description_:
*************** _Description_:
*** 1592,1602 ****
       must be in the unlocked state.
  
  _C/C++_:
!      _Prototype_:   'void omp_destroy_lock(omp_lock_t *lock);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_destroy_lock(svar)'
!                     'integer(omp_lock_kind), intent(inout) :: svar'
  
  _See also_:
       *note omp_init_lock::
--- 1592,1602 ----
       must be in the unlocked state.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_destroy_lock(omp_lock_t *lock);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_destroy_lock(svar)’
!                     ‘integer(omp_lock_kind), intent(inout) :: svar’
  
  _See also_:
       *note omp_init_lock::
*************** _Reference_:
*** 1607,1613 ****
  
  File: libgomp.info,  Node: omp_init_nest_lock,  Next: omp_set_nest_lock,  Prev: omp_destroy_lock,  Up: Runtime Library Routines
  
! 3.42 'omp_init_nest_lock' - Initialize nested lock
  ==================================================
  
  _Description_:
--- 1607,1613 ----
  
  File: libgomp.info,  Node: omp_init_nest_lock,  Next: omp_set_nest_lock,  Prev: omp_destroy_lock,  Up: Runtime Library Routines
  
! 3.42 ‘omp_init_nest_lock’ - Initialize nested lock
  ==================================================
  
  _Description_:
*************** _Description_:
*** 1615,1625 ****
       unlocked state and the nesting count is set to zero.
  
  _C/C++_:
!      _Prototype_:   'void omp_init_nest_lock(omp_nest_lock_t *lock);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_init_nest_lock(nvar)'
!                     'integer(omp_nest_lock_kind), intent(out) :: nvar'
  
  _See also_:
       *note omp_destroy_nest_lock::
--- 1615,1625 ----
       unlocked state and the nesting count is set to zero.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_init_nest_lock(omp_nest_lock_t *lock);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_init_nest_lock(nvar)’
!                     ‘integer(omp_nest_lock_kind), intent(out) :: nvar’
  
  _See also_:
       *note omp_destroy_nest_lock::
*************** _Reference_:
*** 1630,1650 ****
  
  File: libgomp.info,  Node: omp_set_nest_lock,  Next: omp_test_nest_lock,  Prev: omp_init_nest_lock,  Up: Runtime Library Routines
  
! 3.43 'omp_set_nest_lock' - Wait for and set nested lock
  =======================================================
  
  _Description_:
       Before setting a nested lock, the lock variable must be initialized
!      by 'omp_init_nest_lock'.  The calling thread is blocked until the
       lock is available.  If the lock is already held by the current
       thread, the nesting count for the lock is incremented.
  
  _C/C++_:
!      _Prototype_:   'void omp_set_nest_lock(omp_nest_lock_t *lock);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_set_nest_lock(nvar)'
!                     'integer(omp_nest_lock_kind), intent(inout) :: nvar'
  
  _See also_:
       *note omp_init_nest_lock::, *note omp_unset_nest_lock::
--- 1630,1650 ----
  
  File: libgomp.info,  Node: omp_set_nest_lock,  Next: omp_test_nest_lock,  Prev: omp_init_nest_lock,  Up: Runtime Library Routines
  
! 3.43 ‘omp_set_nest_lock’ - Wait for and set nested lock
  =======================================================
  
  _Description_:
       Before setting a nested lock, the lock variable must be initialized
!      by ‘omp_init_nest_lock’.  The calling thread is blocked until the
       lock is available.  If the lock is already held by the current
       thread, the nesting count for the lock is incremented.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_set_nest_lock(omp_nest_lock_t *lock);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_set_nest_lock(nvar)’
!                     ‘integer(omp_nest_lock_kind), intent(inout) :: nvar’
  
  _See also_:
       *note omp_init_nest_lock::, *note omp_unset_nest_lock::
*************** _Reference_:
*** 1655,1676 ****
  
  File: libgomp.info,  Node: omp_test_nest_lock,  Next: omp_unset_nest_lock,  Prev: omp_set_nest_lock,  Up: Runtime Library Routines
  
! 3.44 'omp_test_nest_lock' - Test and set nested lock if available
  =================================================================
  
  _Description_:
       Before setting a nested lock, the lock variable must be initialized
!      by 'omp_init_nest_lock'.  Contrary to 'omp_set_nest_lock',
!      'omp_test_nest_lock' does not block if the lock is not available.
       If the lock is already held by the current thread, the new nesting
       count is returned.  Otherwise, the return value equals zero.
  
  _C/C++_:
!      _Prototype_:   'int omp_test_nest_lock(omp_nest_lock_t *lock);'
  
  _Fortran_:
!      _Interface_:   'logical function omp_test_nest_lock(nvar)'
!                     'integer(omp_nest_lock_kind), intent(inout) :: nvar'
  
  _See also_:
       *note omp_init_lock::, *note omp_set_lock::, *note omp_set_lock::
--- 1655,1676 ----
  
  File: libgomp.info,  Node: omp_test_nest_lock,  Next: omp_unset_nest_lock,  Prev: omp_set_nest_lock,  Up: Runtime Library Routines
  
! 3.44 ‘omp_test_nest_lock’ - Test and set nested lock if available
  =================================================================
  
  _Description_:
       Before setting a nested lock, the lock variable must be initialized
!      by ‘omp_init_nest_lock’.  Contrary to ‘omp_set_nest_lock’,
!      ‘omp_test_nest_lock’ does not block if the lock is not available.
       If the lock is already held by the current thread, the new nesting
       count is returned.  Otherwise, the return value equals zero.
  
  _C/C++_:
!      _Prototype_:   ‘int omp_test_nest_lock(omp_nest_lock_t *lock);’
  
  _Fortran_:
!      _Interface_:   ‘logical function omp_test_nest_lock(nvar)’
!                     ‘integer(omp_nest_lock_kind), intent(inout) :: nvar’
  
  _See also_:
       *note omp_init_lock::, *note omp_set_lock::, *note omp_set_lock::
*************** _Reference_:
*** 1681,1704 ****
  
  File: libgomp.info,  Node: omp_unset_nest_lock,  Next: omp_destroy_nest_lock,  Prev: omp_test_nest_lock,  Up: Runtime Library Routines
  
! 3.45 'omp_unset_nest_lock' - Unset nested lock
  ==============================================
  
  _Description_:
       A nested lock about to be unset must have been locked by
!      'omp_set_nested_lock' or 'omp_test_nested_lock' before.  In
       addition, the lock must be held by the thread calling
!      'omp_unset_nested_lock'.  If the nesting count drops to zero, the
       lock becomes unlocked.  If one ore more threads attempted to set
       the lock before, one of them is chosen to, again, set the lock to
       itself.
  
  _C/C++_:
!      _Prototype_:   'void omp_unset_nest_lock(omp_nest_lock_t *lock);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_unset_nest_lock(nvar)'
!                     'integer(omp_nest_lock_kind), intent(inout) :: nvar'
  
  _See also_:
       *note omp_set_nest_lock::
--- 1681,1704 ----
  
  File: libgomp.info,  Node: omp_unset_nest_lock,  Next: omp_destroy_nest_lock,  Prev: omp_test_nest_lock,  Up: Runtime Library Routines
  
! 3.45 ‘omp_unset_nest_lock’ - Unset nested lock
  ==============================================
  
  _Description_:
       A nested lock about to be unset must have been locked by
!      ‘omp_set_nested_lock’ or ‘omp_test_nested_lock’ before.  In
       addition, the lock must be held by the thread calling
!      ‘omp_unset_nested_lock’.  If the nesting count drops to zero, the
       lock becomes unlocked.  If one ore more threads attempted to set
       the lock before, one of them is chosen to, again, set the lock to
       itself.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_unset_nest_lock(omp_nest_lock_t *lock);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_unset_nest_lock(nvar)’
!                     ‘integer(omp_nest_lock_kind), intent(inout) :: nvar’
  
  _See also_:
       *note omp_set_nest_lock::
*************** _Reference_:
*** 1709,1715 ****
  
  File: libgomp.info,  Node: omp_destroy_nest_lock,  Next: omp_get_wtick,  Prev: omp_unset_nest_lock,  Up: Runtime Library Routines
  
! 3.46 'omp_destroy_nest_lock' - Destroy nested lock
  ==================================================
  
  _Description_:
--- 1709,1715 ----
  
  File: libgomp.info,  Node: omp_destroy_nest_lock,  Next: omp_get_wtick,  Prev: omp_unset_nest_lock,  Up: Runtime Library Routines
  
! 3.46 ‘omp_destroy_nest_lock’ - Destroy nested lock
  ==================================================
  
  _Description_:
*************** _Description_:
*** 1718,1728 ****
       zero.
  
  _C/C++_:
!      _Prototype_:   'void omp_destroy_nest_lock(omp_nest_lock_t *);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_destroy_nest_lock(nvar)'
!                     'integer(omp_nest_lock_kind), intent(inout) :: nvar'
  
  _See also_:
       *note omp_init_lock::
--- 1718,1728 ----
       zero.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_destroy_nest_lock(omp_nest_lock_t *);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_destroy_nest_lock(nvar)’
!                     ‘integer(omp_nest_lock_kind), intent(inout) :: nvar’
  
  _See also_:
       *note omp_init_lock::
*************** _Reference_:
*** 1733,1739 ****
  
  File: libgomp.info,  Node: omp_get_wtick,  Next: omp_get_wtime,  Prev: omp_destroy_nest_lock,  Up: Runtime Library Routines
  
! 3.47 'omp_get_wtick' - Get timer precision
  ==========================================
  
  _Description_:
--- 1733,1739 ----
  
  File: libgomp.info,  Node: omp_get_wtick,  Next: omp_get_wtime,  Prev: omp_destroy_nest_lock,  Up: Runtime Library Routines
  
! 3.47 ‘omp_get_wtick’ - Get timer precision
  ==========================================
  
  _Description_:
*************** _Description_:
*** 1741,1750 ****
       successive clock ticks.
  
  _C/C++_:
!      _Prototype_:   'double omp_get_wtick(void);'
  
  _Fortran_:
!      _Interface_:   'double precision function omp_get_wtick()'
  
  _See also_:
       *note omp_get_wtime::
--- 1741,1750 ----
       successive clock ticks.
  
  _C/C++_:
!      _Prototype_:   ‘double omp_get_wtick(void);’
  
  _Fortran_:
!      _Interface_:   ‘double precision function omp_get_wtick()’
  
  _See also_:
       *note omp_get_wtime::
*************** _Reference_:
*** 1755,1761 ****
  
  File: libgomp.info,  Node: omp_get_wtime,  Next: omp_fulfill_event,  Prev: omp_get_wtick,  Up: Runtime Library Routines
  
! 3.48 'omp_get_wtime' - Elapsed wall clock time
  ==============================================
  
  _Description_:
--- 1755,1761 ----
  
  File: libgomp.info,  Node: omp_get_wtime,  Next: omp_fulfill_event,  Prev: omp_get_wtick,  Up: Runtime Library Routines
  
! 3.48 ‘omp_get_wtime’ - Elapsed wall clock time
  ==============================================
  
  _Description_:
*************** _Description_:
*** 1766,1775 ****
       execution of the program.
  
  _C/C++_:
!      _Prototype_:   'double omp_get_wtime(void);'
  
  _Fortran_:
!      _Interface_:   'double precision function omp_get_wtime()'
  
  _See also_:
       *note omp_get_wtick::
--- 1766,1775 ----
       execution of the program.
  
  _C/C++_:
!      _Prototype_:   ‘double omp_get_wtime(void);’
  
  _Fortran_:
!      _Interface_:   ‘double precision function omp_get_wtime()’
  
  _See also_:
       *note omp_get_wtick::
*************** _Reference_:
*** 1780,1786 ****
  
  File: libgomp.info,  Node: omp_fulfill_event,  Prev: omp_get_wtime,  Up: Runtime Library Routines
  
! 3.49 'omp_fulfill_event' - Fulfill and destroy an OpenMP event
  ==============================================================
  
  _Description_:
--- 1780,1786 ----
  
  File: libgomp.info,  Node: omp_fulfill_event,  Prev: omp_get_wtime,  Up: Runtime Library Routines
  
! 3.49 ‘omp_fulfill_event’ - Fulfill and destroy an OpenMP event
  ==============================================================
  
  _Description_:
*************** _Description_:
*** 1789,1805 ****
       clauses on task constructs - the effect of fulfilling the event is
       to allow the task to complete.
  
!      The result of calling 'omp_fulfill_event' with an event handle
       other than that generated by a detach clause is undefined.  Calling
       it with an event handle that has already been fulfilled is also
       undefined.
  
  _C/C++_:
!      _Prototype_:   'void omp_fulfill_event(omp_event_handle_t event);'
  
  _Fortran_:
!      _Interface_:   'subroutine omp_fulfill_event(event)'
!                     'integer (kind=omp_event_handle_kind) :: event'
  
  _Reference_:
       OpenMP specification v5.0 (https://www.openmp.org), Section 3.5.1.
--- 1789,1805 ----
       clauses on task constructs - the effect of fulfilling the event is
       to allow the task to complete.
  
!      The result of calling ‘omp_fulfill_event’ with an event handle
       other than that generated by a detach clause is undefined.  Calling
       it with an event handle that has already been fulfilled is also
       undefined.
  
  _C/C++_:
!      _Prototype_:   ‘void omp_fulfill_event(omp_event_handle_t event);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine omp_fulfill_event(event)’
!                     ‘integer (kind=omp_event_handle_kind) :: event’
  
  _Reference_:
       OpenMP specification v5.0 (https://www.openmp.org), Section 3.5.1.
*************** File: libgomp.info,  Node: Environment V
*** 1810,1818 ****
  4 OpenMP Environment Variables
  ******************************
  
! The environment variables which beginning with 'OMP_' are defined by
  section 4 of the OpenMP specification in version 4.5, while those
! beginning with 'GOMP_' are GNU extensions.
  
  * Menu:
  
--- 1810,1818 ----
  4 OpenMP Environment Variables
  ******************************
  
! The environment variables which beginning with ‘OMP_’ are defined by
  section 4 of the OpenMP specification in version 4.5, while those
! beginning with ‘GOMP_’ are GNU extensions.
  
  * Menu:
  
*************** beginning with 'GOMP_' are GNU extension
*** 1842,1853 ****
  
  File: libgomp.info,  Node: OMP_CANCELLATION,  Next: OMP_DISPLAY_ENV,  Up: Environment Variables
  
! 4.1 'OMP_CANCELLATION' - Set whether cancellation is activated
  ==============================================================
  
  _Description_:
!      If set to 'TRUE', the cancellation is activated.  If set to 'FALSE'
!      or if unset, cancellation is disabled and the 'cancel' construct is
       ignored.
  
  _See also_:
--- 1842,1853 ----
  
  File: libgomp.info,  Node: OMP_CANCELLATION,  Next: OMP_DISPLAY_ENV,  Up: Environment Variables
  
! 4.1 ‘OMP_CANCELLATION’ - Set whether cancellation is activated
  ==============================================================
  
  _Description_:
!      If set to ‘TRUE’, the cancellation is activated.  If set to ‘FALSE’
!      or if unset, cancellation is disabled and the ‘cancel’ construct is
       ignored.
  
  _See also_:
*************** _Reference_:
*** 1859,1873 ****
  
  File: libgomp.info,  Node: OMP_DISPLAY_ENV,  Next: OMP_DEFAULT_DEVICE,  Prev: OMP_CANCELLATION,  Up: Environment Variables
  
! 4.2 'OMP_DISPLAY_ENV' - Show OpenMP version and environment variables
  =====================================================================
  
  _Description_:
!      If set to 'TRUE', the OpenMP version number and the values
       associated with the OpenMP environment variables are printed to
!      'stderr'.  If set to 'VERBOSE', it additionally shows the value of
       the environment variables which are GNU extensions.  If undefined
!      or set to 'FALSE', this information will not be shown.
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 4.12
--- 1859,1873 ----
  
  File: libgomp.info,  Node: OMP_DISPLAY_ENV,  Next: OMP_DEFAULT_DEVICE,  Prev: OMP_CANCELLATION,  Up: Environment Variables
  
! 4.2 ‘OMP_DISPLAY_ENV’ - Show OpenMP version and environment variables
  =====================================================================
  
  _Description_:
!      If set to ‘TRUE’, the OpenMP version number and the values
       associated with the OpenMP environment variables are printed to
!      ‘stderr’.  If set to ‘VERBOSE’, it additionally shows the value of
       the environment variables which are GNU extensions.  If undefined
!      or set to ‘FALSE’, this information will not be shown.
  
  _Reference_:
       OpenMP specification v4.5 (https://www.openmp.org), Section 4.12
*************** _Reference_:
*** 1875,1887 ****
  
  File: libgomp.info,  Node: OMP_DEFAULT_DEVICE,  Next: OMP_DYNAMIC,  Prev: OMP_DISPLAY_ENV,  Up: Environment Variables
  
! 4.3 'OMP_DEFAULT_DEVICE' - Set the device used in target regions
  ================================================================
  
  _Description_:
!      Set to choose the device which is used in a 'target' region, unless
!      the value is overridden by 'omp_set_default_device' or by a
!      'device' clause.  The value shall be the nonnegative device number.
       If no device with the given device number exists, the code is
       executed on the host.  If unset, device number 0 will be used.
  
--- 1875,1887 ----
  
  File: libgomp.info,  Node: OMP_DEFAULT_DEVICE,  Next: OMP_DYNAMIC,  Prev: OMP_DISPLAY_ENV,  Up: Environment Variables
  
! 4.3 ‘OMP_DEFAULT_DEVICE’ - Set the device used in target regions
  ================================================================
  
  _Description_:
!      Set to choose the device which is used in a ‘target’ region, unless
!      the value is overridden by ‘omp_set_default_device’ or by a
!      ‘device’ clause.  The value shall be the nonnegative device number.
       If no device with the given device number exists, the code is
       executed on the host.  If unset, device number 0 will be used.
  
*************** _Reference_:
*** 1894,1906 ****
  
  File: libgomp.info,  Node: OMP_DYNAMIC,  Next: OMP_MAX_ACTIVE_LEVELS,  Prev: OMP_DEFAULT_DEVICE,  Up: Environment Variables
  
! 4.4 'OMP_DYNAMIC' - Dynamic adjustment of threads
  =================================================
  
  _Description_:
       Enable or disable the dynamic adjustment of the number of threads
       within a team.  The value of this environment variable shall be
!      'TRUE' or 'FALSE'.  If undefined, dynamic adjustment is disabled by
       default.
  
  _See also_:
--- 1894,1906 ----
  
  File: libgomp.info,  Node: OMP_DYNAMIC,  Next: OMP_MAX_ACTIVE_LEVELS,  Prev: OMP_DEFAULT_DEVICE,  Up: Environment Variables
  
! 4.4 ‘OMP_DYNAMIC’ - Dynamic adjustment of threads
  =================================================
  
  _Description_:
       Enable or disable the dynamic adjustment of the number of threads
       within a team.  The value of this environment variable shall be
!      ‘TRUE’ or ‘FALSE’.  If undefined, dynamic adjustment is disabled by
       default.
  
  _See also_:
*************** _Reference_:
*** 1912,1925 ****
  
  File: libgomp.info,  Node: OMP_MAX_ACTIVE_LEVELS,  Next: OMP_MAX_TASK_PRIORITY,  Prev: OMP_DYNAMIC,  Up: Environment Variables
  
! 4.5 'OMP_MAX_ACTIVE_LEVELS' - Set the maximum number of nested parallel regions
  ===============================================================================
  
  _Description_:
       Specifies the initial value for the maximum number of nested
       parallel regions.  The value of this variable shall be a positive
!      integer.  If undefined, then if 'OMP_NESTED' is defined and set to
!      true, or if 'OMP_NUM_THREADS' or 'OMP_PROC_BIND' are defined and
       set to a list with more than one item, the maximum number of nested
       parallel regions will be initialized to the largest number
       supported, otherwise it will be set to one.
--- 1912,1925 ----
  
  File: libgomp.info,  Node: OMP_MAX_ACTIVE_LEVELS,  Next: OMP_MAX_TASK_PRIORITY,  Prev: OMP_DYNAMIC,  Up: Environment Variables
  
! 4.5 ‘OMP_MAX_ACTIVE_LEVELS’ - Set the maximum number of nested parallel regions
  ===============================================================================
  
  _Description_:
       Specifies the initial value for the maximum number of nested
       parallel regions.  The value of this variable shall be a positive
!      integer.  If undefined, then if ‘OMP_NESTED’ is defined and set to
!      true, or if ‘OMP_NUM_THREADS’ or ‘OMP_PROC_BIND’ are defined and
       set to a list with more than one item, the maximum number of nested
       parallel regions will be initialized to the largest number
       supported, otherwise it will be set to one.
*************** _Reference_:
*** 1933,1939 ****
  
  File: libgomp.info,  Node: OMP_MAX_TASK_PRIORITY,  Next: OMP_NESTED,  Prev: OMP_MAX_ACTIVE_LEVELS,  Up: Environment Variables
  
! 4.6 'OMP_MAX_TASK_PRIORITY' - Set the maximum priority
  ======================================================
  
  number that can be set for a task.
--- 1933,1939 ----
  
  File: libgomp.info,  Node: OMP_MAX_TASK_PRIORITY,  Next: OMP_NESTED,  Prev: OMP_MAX_ACTIVE_LEVELS,  Up: Environment Variables
  
! 4.6 ‘OMP_MAX_TASK_PRIORITY’ - Set the maximum priority
  ======================================================
  
  number that can be set for a task.
*************** _Reference_:
*** 1952,1969 ****
  
  File: libgomp.info,  Node: OMP_NESTED,  Next: OMP_NUM_TEAMS,  Prev: OMP_MAX_TASK_PRIORITY,  Up: Environment Variables
  
! 4.7 'OMP_NESTED' - Nested parallel regions
  ==========================================
  
  _Description_:
       Enable or disable nested parallel regions, i.e., whether team
       members are allowed to create new teams.  The value of this
!      environment variable shall be 'TRUE' or 'FALSE'.  If set to 'TRUE',
       the number of maximum active nested regions supported will by
       default be set to the maximum supported, otherwise it will be set
!      to one.  If 'OMP_MAX_ACTIVE_LEVELS' is defined, its setting will
       override this setting.  If both are undefined, nested parallel
!      regions are enabled if 'OMP_NUM_THREADS' or 'OMP_PROC_BINDS' are
       defined to a list with more than one item, otherwise they are
       disabled by default.
  
--- 1952,1969 ----
  
  File: libgomp.info,  Node: OMP_NESTED,  Next: OMP_NUM_TEAMS,  Prev: OMP_MAX_TASK_PRIORITY,  Up: Environment Variables
  
! 4.7 ‘OMP_NESTED’ - Nested parallel regions
  ==========================================
  
  _Description_:
       Enable or disable nested parallel regions, i.e., whether team
       members are allowed to create new teams.  The value of this
!      environment variable shall be ‘TRUE’ or ‘FALSE’.  If set to ‘TRUE’,
       the number of maximum active nested regions supported will by
       default be set to the maximum supported, otherwise it will be set
!      to one.  If ‘OMP_MAX_ACTIVE_LEVELS’ is defined, its setting will
       override this setting.  If both are undefined, nested parallel
!      regions are enabled if ‘OMP_NUM_THREADS’ or ‘OMP_PROC_BINDS’ are
       defined to a list with more than one item, otherwise they are
       disabled by default.
  
*************** _Reference_:
*** 1976,1987 ****
  
  File: libgomp.info,  Node: OMP_NUM_TEAMS,  Next: OMP_NUM_THREADS,  Prev: OMP_NESTED,  Up: Environment Variables
  
! 4.8 'OMP_NUM_TEAMS' - Specifies the number of teams to use by teams region
  ==========================================================================
  
  _Description_:
       Specifies the upper bound for number of teams to use in teams
!      regions without explicit 'num_teams' clause.  The value of this
       variable shall be a positive integer.  If undefined it defaults to
       0 which means implementation defined upper bound.
  
--- 1976,1987 ----
  
  File: libgomp.info,  Node: OMP_NUM_TEAMS,  Next: OMP_NUM_THREADS,  Prev: OMP_NESTED,  Up: Environment Variables
  
! 4.8 ‘OMP_NUM_TEAMS’ - Specifies the number of teams to use by teams region
  ==========================================================================
  
  _Description_:
       Specifies the upper bound for number of teams to use in teams
!      regions without explicit ‘num_teams’ clause.  The value of this
       variable shall be a positive integer.  If undefined it defaults to
       0 which means implementation defined upper bound.
  
*************** _Reference_:
*** 1994,2000 ****
  
  File: libgomp.info,  Node: OMP_NUM_THREADS,  Next: OMP_PROC_BIND,  Prev: OMP_NUM_TEAMS,  Up: Environment Variables
  
! 4.9 'OMP_NUM_THREADS' - Specifies the number of threads to use
  ==============================================================
  
  _Description_:
--- 1994,2000 ----
  
  File: libgomp.info,  Node: OMP_NUM_THREADS,  Next: OMP_PROC_BIND,  Prev: OMP_NUM_TEAMS,  Up: Environment Variables
  
! 4.9 ‘OMP_NUM_THREADS’ - Specifies the number of threads to use
  ==============================================================
  
  _Description_:
*************** _Reference_:
*** 2014,2037 ****
  
  File: libgomp.info,  Node: OMP_PROC_BIND,  Next: OMP_PLACES,  Prev: OMP_NUM_THREADS,  Up: Environment Variables
  
! 4.10 'OMP_PROC_BIND' - Whether threads may be moved between CPUs
  ================================================================
  
  _Description_:
       Specifies whether threads may be moved between processors.  If set
!      to 'TRUE', OpenMP threads should not be moved; if set to 'FALSE'
       they may be moved.  Alternatively, a comma separated list with the
!      values 'PRIMARY', 'MASTER', 'CLOSE' and 'SPREAD' can be used to
       specify the thread affinity policy for the corresponding nesting
!      level.  With 'PRIMARY' and 'MASTER' the worker threads are in the
!      same place partition as the primary thread.  With 'CLOSE' those are
       kept close to the primary thread in contiguous place partitions.
!      And with 'SPREAD' a sparse distribution across the place partitions
       is used.  Specifying more than one item in the list will
       automatically enable nesting by default.
  
!      When undefined, 'OMP_PROC_BIND' defaults to 'TRUE' when
!      'OMP_PLACES' or 'GOMP_CPU_AFFINITY' is set and 'FALSE' otherwise.
  
  _See also_:
       *note omp_get_proc_bind::, *note GOMP_CPU_AFFINITY::, *note
--- 2014,2037 ----
  
  File: libgomp.info,  Node: OMP_PROC_BIND,  Next: OMP_PLACES,  Prev: OMP_NUM_THREADS,  Up: Environment Variables
  
! 4.10 ‘OMP_PROC_BIND’ - Whether threads may be moved between CPUs
  ================================================================
  
  _Description_:
       Specifies whether threads may be moved between processors.  If set
!      to ‘TRUE’, OpenMP threads should not be moved; if set to ‘FALSE’
       they may be moved.  Alternatively, a comma separated list with the
!      values ‘PRIMARY’, ‘MASTER’, ‘CLOSE’ and ‘SPREAD’ can be used to
       specify the thread affinity policy for the corresponding nesting
!      level.  With ‘PRIMARY’ and ‘MASTER’ the worker threads are in the
!      same place partition as the primary thread.  With ‘CLOSE’ those are
       kept close to the primary thread in contiguous place partitions.
!      And with ‘SPREAD’ a sparse distribution across the place partitions
       is used.  Specifying more than one item in the list will
       automatically enable nesting by default.
  
!      When undefined, ‘OMP_PROC_BIND’ defaults to ‘TRUE’ when
!      ‘OMP_PLACES’ or ‘GOMP_CPU_AFFINITY’ is set and ‘FALSE’ otherwise.
  
  _See also_:
       *note omp_get_proc_bind::, *note GOMP_CPU_AFFINITY::, *note
*************** _Reference_:
*** 2043,2065 ****
  
  File: libgomp.info,  Node: OMP_PLACES,  Next: OMP_STACKSIZE,  Prev: OMP_PROC_BIND,  Up: Environment Variables
  
! 4.11 'OMP_PLACES' - Specifies on which CPUs the threads should be placed
  ========================================================================
  
  _Description_:
       The thread placement can be either specified using an abstract name
       or by an explicit list of the places.  The abstract names
!      'threads', 'cores', 'sockets', 'll_caches' and 'numa_domains' can
       be optionally followed by a positive number in parentheses, which
!      denotes the how many places shall be created.  With 'threads' each
!      place corresponds to a single hardware thread; 'cores' to a single
       core with the corresponding number of hardware threads; with
!      'sockets' the place corresponds to a single socket; with
!      'll_caches' to a set of cores that shares the last level cache on
!      the device; and 'numa_domains' to a set of cores for which their
       closest memory on the device is the same memory and at a similar
       distance from the cores.  The resulting placement can be shown by
!      setting the 'OMP_DISPLAY_ENV' environment variable.
  
       Alternatively, the placement can be specified explicitly as
       comma-separated list of places.  A place is specified by set of
--- 2043,2065 ----
  
  File: libgomp.info,  Node: OMP_PLACES,  Next: OMP_STACKSIZE,  Prev: OMP_PROC_BIND,  Up: Environment Variables
  
! 4.11 ‘OMP_PLACES’ - Specifies on which CPUs the threads should be placed
  ========================================================================
  
  _Description_:
       The thread placement can be either specified using an abstract name
       or by an explicit list of the places.  The abstract names
!      ‘threads’, ‘cores’, ‘sockets’, ‘ll_caches’ and ‘numa_domains’ can
       be optionally followed by a positive number in parentheses, which
!      denotes the how many places shall be created.  With ‘threads’ each
!      place corresponds to a single hardware thread; ‘cores’ to a single
       core with the corresponding number of hardware threads; with
!      ‘sockets’ the place corresponds to a single socket; with
!      ‘ll_caches’ to a set of cores that shares the last level cache on
!      the device; and ‘numa_domains’ to a set of cores for which their
       closest memory on the device is the same memory and at a similar
       distance from the cores.  The resulting placement can be shown by
!      setting the ‘OMP_DISPLAY_ENV’ environment variable.
  
       Alternatively, the placement can be specified explicitly as
       comma-separated list of places.  A place is specified by set of
*************** _Description_:
*** 2072,2087 ****
       interval, a colon followed by the count is placed after the
       hardware thread number or the place.  Optionally, the length can be
       followed by a colon and the stride number - otherwise a unit stride
!      is assumed.  Placing an exclamation mark ('!') directly before a
       curly brace or numbers inside the curly braces (excluding
       intervals) will exclude those hardware threads.
  
       For instance, the following specifies the same places list:
!      '"{0,1,2}, {3,4,6}, {7,8,9}, {10,11,12}"'; '"{0:3}, {3:3}, {7:3},
!      {10:3}"'; and '"{0:2}:4:3"'.
  
!      If 'OMP_PLACES' and 'GOMP_CPU_AFFINITY' are unset and
!      'OMP_PROC_BIND' is either unset or 'false', threads may be moved
       between CPUs following no placement policy.
  
  _See also_:
--- 2072,2087 ----
       interval, a colon followed by the count is placed after the
       hardware thread number or the place.  Optionally, the length can be
       followed by a colon and the stride number - otherwise a unit stride
!      is assumed.  Placing an exclamation mark (‘!’) directly before a
       curly brace or numbers inside the curly braces (excluding
       intervals) will exclude those hardware threads.
  
       For instance, the following specifies the same places list:
!      ‘"{0,1,2}, {3,4,6}, {7,8,9}, {10,11,12}"’; ‘"{0:3}, {3:3}, {7:3},
!      {10:3}"’; and ‘"{0:2}:4:3"’.
  
!      If ‘OMP_PLACES’ and ‘GOMP_CPU_AFFINITY’ are unset and
!      ‘OMP_PROC_BIND’ is either unset or ‘false’, threads may be moved
       between CPUs following no placement policy.
  
  _See also_:
*************** _Reference_:
*** 2094,2107 ****
  
  File: libgomp.info,  Node: OMP_STACKSIZE,  Next: OMP_SCHEDULE,  Prev: OMP_PLACES,  Up: Environment Variables
  
! 4.12 'OMP_STACKSIZE' - Set default thread stack size
  ====================================================
  
  _Description_:
       Set the default thread stack size in kilobytes, unless the number
!      is suffixed by 'B', 'K', 'M' or 'G', in which case the size is,
       respectively, in bytes, kilobytes, megabytes or gigabytes.  This is
!      different from 'pthread_attr_setstacksize' which gets the number of
       bytes as an argument.  If the stack size cannot be set due to
       system constraints, an error is reported and the initial stack size
       is left unchanged.  If undefined, the stack size is system
--- 2094,2107 ----
  
  File: libgomp.info,  Node: OMP_STACKSIZE,  Next: OMP_SCHEDULE,  Prev: OMP_PLACES,  Up: Environment Variables
  
! 4.12 ‘OMP_STACKSIZE’ - Set default thread stack size
  ====================================================
  
  _Description_:
       Set the default thread stack size in kilobytes, unless the number
!      is suffixed by ‘B’, ‘K’, ‘M’ or ‘G’, in which case the size is,
       respectively, in bytes, kilobytes, megabytes or gigabytes.  This is
!      different from ‘pthread_attr_setstacksize’ which gets the number of
       bytes as an argument.  If the stack size cannot be set due to
       system constraints, an error is reported and the initial stack size
       is left unchanged.  If undefined, the stack size is system
*************** _Reference_:
*** 2113,2125 ****
  
  File: libgomp.info,  Node: OMP_SCHEDULE,  Next: OMP_TARGET_OFFLOAD,  Prev: OMP_STACKSIZE,  Up: Environment Variables
  
! 4.13 'OMP_SCHEDULE' - How threads are scheduled
  ===============================================
  
  _Description_:
!      Allows to specify 'schedule type' and 'chunk size'.  The value of
!      the variable shall have the form: 'type[,chunk]' where 'type' is
!      one of 'static', 'dynamic', 'guided' or 'auto' The optional 'chunk'
       size shall be a positive integer.  If undefined, dynamic scheduling
       and a chunk size of 1 is used.
  
--- 2113,2125 ----
  
  File: libgomp.info,  Node: OMP_SCHEDULE,  Next: OMP_TARGET_OFFLOAD,  Prev: OMP_STACKSIZE,  Up: Environment Variables
  
! 4.13 ‘OMP_SCHEDULE’ - How threads are scheduled
  ===============================================
  
  _Description_:
!      Allows to specify ‘schedule type’ and ‘chunk size’.  The value of
!      the variable shall have the form: ‘type[,chunk]’ where ‘type’ is
!      one of ‘static’, ‘dynamic’, ‘guided’ or ‘auto’ The optional ‘chunk’
       size shall be a positive integer.  If undefined, dynamic scheduling
       and a chunk size of 1 is used.
  
*************** _Reference_:
*** 2133,2154 ****
  
  File: libgomp.info,  Node: OMP_TARGET_OFFLOAD,  Next: OMP_TEAMS_THREAD_LIMIT,  Prev: OMP_SCHEDULE,  Up: Environment Variables
  
! 4.14 'OMP_TARGET_OFFLOAD' - Controls offloading behaviour
  =========================================================
  
  _Description_:
       Specifies the behaviour with regard to offloading code to a device.
!      This variable can be set to one of three values - 'MANDATORY',
!      'DISABLED' or 'DEFAULT'.
  
!      If set to 'MANDATORY', the program will terminate with an error if
       the offload device is not present or is not supported.  If set to
!      'DISABLED', then offloading is disabled and all code will run on
!      the host.  If set to 'DEFAULT', the program will try offloading to
       the device first, then fall back to running code on the host if it
       cannot.
  
!      If undefined, then the program will behave as if 'DEFAULT' was set.
  
  _Reference_:
       OpenMP specification v5.0 (https://www.openmp.org), Section 6.17
--- 2133,2154 ----
  
  File: libgomp.info,  Node: OMP_TARGET_OFFLOAD,  Next: OMP_TEAMS_THREAD_LIMIT,  Prev: OMP_SCHEDULE,  Up: Environment Variables
  
! 4.14 ‘OMP_TARGET_OFFLOAD’ - Controls offloading behaviour
  =========================================================
  
  _Description_:
       Specifies the behaviour with regard to offloading code to a device.
!      This variable can be set to one of three values - ‘MANDATORY’,
!      ‘DISABLED’ or ‘DEFAULT’.
  
!      If set to ‘MANDATORY’, the program will terminate with an error if
       the offload device is not present or is not supported.  If set to
!      ‘DISABLED’, then offloading is disabled and all code will run on
!      the host.  If set to ‘DEFAULT’, the program will try offloading to
       the device first, then fall back to running code on the host if it
       cannot.
  
!      If undefined, then the program will behave as if ‘DEFAULT’ was set.
  
  _Reference_:
       OpenMP specification v5.0 (https://www.openmp.org), Section 6.17
*************** _Reference_:
*** 2156,2168 ****
  
  File: libgomp.info,  Node: OMP_TEAMS_THREAD_LIMIT,  Next: OMP_THREAD_LIMIT,  Prev: OMP_TARGET_OFFLOAD,  Up: Environment Variables
  
! 4.15 'OMP_TEAMS_THREAD_LIMIT' - Set the maximum number of threads imposed by teams
  ==================================================================================
  
  _Description_:
       Specifies an upper bound for the number of threads to use by each
       contention group created by a teams construct without explicit
!      'thread_limit' clause.  The value of this variable shall be a
       positive integer.  If undefined, the value of 0 is used which
       stands for an implementation defined upper limit.
  
--- 2156,2168 ----
  
  File: libgomp.info,  Node: OMP_TEAMS_THREAD_LIMIT,  Next: OMP_THREAD_LIMIT,  Prev: OMP_TARGET_OFFLOAD,  Up: Environment Variables
  
! 4.15 ‘OMP_TEAMS_THREAD_LIMIT’ - Set the maximum number of threads imposed by teams
  ==================================================================================
  
  _Description_:
       Specifies an upper bound for the number of threads to use by each
       contention group created by a teams construct without explicit
!      ‘thread_limit’ clause.  The value of this variable shall be a
       positive integer.  If undefined, the value of 0 is used which
       stands for an implementation defined upper limit.
  
*************** _Reference_:
*** 2175,2181 ****
  
  File: libgomp.info,  Node: OMP_THREAD_LIMIT,  Next: OMP_WAIT_POLICY,  Prev: OMP_TEAMS_THREAD_LIMIT,  Up: Environment Variables
  
! 4.16 'OMP_THREAD_LIMIT' - Set the maximum number of threads
  ===========================================================
  
  _Description_:
--- 2175,2181 ----
  
  File: libgomp.info,  Node: OMP_THREAD_LIMIT,  Next: OMP_WAIT_POLICY,  Prev: OMP_TEAMS_THREAD_LIMIT,  Up: Environment Variables
  
! 4.16 ‘OMP_THREAD_LIMIT’ - Set the maximum number of threads
  ===========================================================
  
  _Description_:
*************** _Reference_:
*** 2192,2204 ****
  
  File: libgomp.info,  Node: OMP_WAIT_POLICY,  Next: GOMP_CPU_AFFINITY,  Prev: OMP_THREAD_LIMIT,  Up: Environment Variables
  
! 4.17 'OMP_WAIT_POLICY' - How waiting threads are handled
  ========================================================
  
  _Description_:
       Specifies whether waiting threads should be active or passive.  If
!      the value is 'PASSIVE', waiting threads should not consume CPU
!      power while waiting; while the value is 'ACTIVE' specifies that
       they should.  If undefined, threads wait actively for a short time
       before waiting passively.
  
--- 2192,2204 ----
  
  File: libgomp.info,  Node: OMP_WAIT_POLICY,  Next: GOMP_CPU_AFFINITY,  Prev: OMP_THREAD_LIMIT,  Up: Environment Variables
  
! 4.17 ‘OMP_WAIT_POLICY’ - How waiting threads are handled
  ========================================================
  
  _Description_:
       Specifies whether waiting threads should be active or passive.  If
!      the value is ‘PASSIVE’, waiting threads should not consume CPU
!      power while waiting; while the value is ‘ACTIVE’ specifies that
       they should.  If undefined, threads wait actively for a short time
       before waiting passively.
  
*************** _Reference_:
*** 2211,2217 ****
  
  File: libgomp.info,  Node: GOMP_CPU_AFFINITY,  Next: GOMP_DEBUG,  Prev: OMP_WAIT_POLICY,  Up: Environment Variables
  
! 4.18 'GOMP_CPU_AFFINITY' - Bind threads to specific CPUs
  ========================================================
  
  _Description_:
--- 2211,2217 ----
  
  File: libgomp.info,  Node: GOMP_CPU_AFFINITY,  Next: GOMP_DEBUG,  Prev: OMP_WAIT_POLICY,  Up: Environment Variables
  
! 4.18 ‘GOMP_CPU_AFFINITY’ - Bind threads to specific CPUs
  ========================================================
  
  _Description_:
*************** _Description_:
*** 2219,2244 ****
       space-separated or comma-separated list of CPUs.  This list may
       contain different kinds of entries: either single CPU numbers in
       any order, a range of CPUs (M-N) or a range with some stride
!      (M-N:S). CPU numbers are zero based.  For example,
!      'GOMP_CPU_AFFINITY="0 3 1-2 4-15:2"' will bind the initial thread
       to CPU 0, the second to CPU 3, the third to CPU 1, the fourth to
       CPU 2, the fifth to CPU 4, the sixth through tenth to CPUs 6, 8,
       10, 12, and 14 respectively and then start assigning back from the
!      beginning of the list.  'GOMP_CPU_AFFINITY=0' binds all threads to
       CPU 0.
  
       There is no libgomp library routine to determine whether a CPU
       affinity specification is in effect.  As a workaround,
!      language-specific library functions, e.g., 'getenv' in C or
!      'GET_ENVIRONMENT_VARIABLE' in Fortran, may be used to query the
!      setting of the 'GOMP_CPU_AFFINITY' environment variable.  A defined
       CPU affinity on startup cannot be changed or disabled during the
       runtime of the application.
  
!      If both 'GOMP_CPU_AFFINITY' and 'OMP_PROC_BIND' are set,
!      'OMP_PROC_BIND' has a higher precedence.  If neither has been set
!      and 'OMP_PROC_BIND' is unset, or when 'OMP_PROC_BIND' is set to
!      'FALSE', the host system will handle the assignment of threads to
       CPUs.
  
  _See also_:
--- 2219,2244 ----
       space-separated or comma-separated list of CPUs.  This list may
       contain different kinds of entries: either single CPU numbers in
       any order, a range of CPUs (M-N) or a range with some stride
!      (M-N:S).  CPU numbers are zero based.  For example,
!      ‘GOMP_CPU_AFFINITY="0 3 1-2 4-15:2"’ will bind the initial thread
       to CPU 0, the second to CPU 3, the third to CPU 1, the fourth to
       CPU 2, the fifth to CPU 4, the sixth through tenth to CPUs 6, 8,
       10, 12, and 14 respectively and then start assigning back from the
!      beginning of the list.  ‘GOMP_CPU_AFFINITY=0’ binds all threads to
       CPU 0.
  
       There is no libgomp library routine to determine whether a CPU
       affinity specification is in effect.  As a workaround,
!      language-specific library functions, e.g., ‘getenv’ in C or
!      ‘GET_ENVIRONMENT_VARIABLE’ in Fortran, may be used to query the
!      setting of the ‘GOMP_CPU_AFFINITY’ environment variable.  A defined
       CPU affinity on startup cannot be changed or disabled during the
       runtime of the application.
  
!      If both ‘GOMP_CPU_AFFINITY’ and ‘OMP_PROC_BIND’ are set,
!      ‘OMP_PROC_BIND’ has a higher precedence.  If neither has been set
!      and ‘OMP_PROC_BIND’ is unset, or when ‘OMP_PROC_BIND’ is set to
!      ‘FALSE’, the host system will handle the assignment of threads to
       CPUs.
  
  _See also_:
*************** _See also_:
*** 2247,2258 ****
  
  File: libgomp.info,  Node: GOMP_DEBUG,  Next: GOMP_STACKSIZE,  Prev: GOMP_CPU_AFFINITY,  Up: Environment Variables
  
! 4.19 'GOMP_DEBUG' - Enable debugging output
  ===========================================
  
  _Description_:
!      Enable debugging output.  The variable should be set to '0'
!      (disabled, also the default if not set), or '1' (enabled).
  
       If enabled, some debugging output will be printed during execution.
       This is currently not specified in more detail, and subject to
--- 2247,2258 ----
  
  File: libgomp.info,  Node: GOMP_DEBUG,  Next: GOMP_STACKSIZE,  Prev: GOMP_CPU_AFFINITY,  Up: Environment Variables
  
! 4.19 ‘GOMP_DEBUG’ - Enable debugging output
  ===========================================
  
  _Description_:
!      Enable debugging output.  The variable should be set to ‘0’
!      (disabled, also the default if not set), or ‘1’ (enabled).
  
       If enabled, some debugging output will be printed during execution.
       This is currently not specified in more detail, and subject to
*************** _Description_:
*** 2261,2272 ****
  
  File: libgomp.info,  Node: GOMP_STACKSIZE,  Next: GOMP_SPINCOUNT,  Prev: GOMP_DEBUG,  Up: Environment Variables
  
! 4.20 'GOMP_STACKSIZE' - Set default thread stack size
  =====================================================
  
  _Description_:
       Set the default thread stack size in kilobytes.  This is different
!      from 'pthread_attr_setstacksize' which gets the number of bytes as
       an argument.  If the stack size cannot be set due to system
       constraints, an error is reported and the initial stack size is
       left unchanged.  If undefined, the stack size is system dependent.
--- 2261,2272 ----
  
  File: libgomp.info,  Node: GOMP_STACKSIZE,  Next: GOMP_SPINCOUNT,  Prev: GOMP_DEBUG,  Up: Environment Variables
  
! 4.20 ‘GOMP_STACKSIZE’ - Set default thread stack size
  =====================================================
  
  _Description_:
       Set the default thread stack size in kilobytes.  This is different
!      from ‘pthread_attr_setstacksize’ which gets the number of bytes as
       an argument.  If the stack size cannot be set due to system
       constraints, an error is reported and the initial stack size is
       left unchanged.  If undefined, the stack size is system dependent.
*************** _Reference_:
*** 2283,2305 ****
  
  File: libgomp.info,  Node: GOMP_SPINCOUNT,  Next: GOMP_RTEMS_THREAD_POOLS,  Prev: GOMP_STACKSIZE,  Up: Environment Variables
  
! 4.21 'GOMP_SPINCOUNT' - Set the busy-wait spin count
  ====================================================
  
  _Description_:
       Determines how long a threads waits actively with consuming CPU
       power before waiting passively without consuming CPU power.  The
!      value may be either 'INFINITE', 'INFINITY' to always wait actively
       or an integer which gives the number of spins of the busy-wait
       loop.  The integer may optionally be followed by the following
!      suffixes acting as multiplication factors: 'k' (kilo, thousand),
!      'M' (mega, million), 'G' (giga, billion), or 'T' (tera, trillion).
!      If undefined, 0 is used when 'OMP_WAIT_POLICY' is 'PASSIVE',
!      300,000 is used when 'OMP_WAIT_POLICY' is undefined and 30 billion
!      is used when 'OMP_WAIT_POLICY' is 'ACTIVE'.  If there are more
       OpenMP threads than available CPUs, 1000 and 100 spins are used for
!      'OMP_WAIT_POLICY' being 'ACTIVE' or undefined, respectively; unless
!      the 'GOMP_SPINCOUNT' is lower or 'OMP_WAIT_POLICY' is 'PASSIVE'.
  
  _See also_:
       *note OMP_WAIT_POLICY::
--- 2283,2305 ----
  
  File: libgomp.info,  Node: GOMP_SPINCOUNT,  Next: GOMP_RTEMS_THREAD_POOLS,  Prev: GOMP_STACKSIZE,  Up: Environment Variables
  
! 4.21 ‘GOMP_SPINCOUNT’ - Set the busy-wait spin count
  ====================================================
  
  _Description_:
       Determines how long a threads waits actively with consuming CPU
       power before waiting passively without consuming CPU power.  The
!      value may be either ‘INFINITE’, ‘INFINITY’ to always wait actively
       or an integer which gives the number of spins of the busy-wait
       loop.  The integer may optionally be followed by the following
!      suffixes acting as multiplication factors: ‘k’ (kilo, thousand),
!      ‘M’ (mega, million), ‘G’ (giga, billion), or ‘T’ (tera, trillion).
!      If undefined, 0 is used when ‘OMP_WAIT_POLICY’ is ‘PASSIVE’,
!      300,000 is used when ‘OMP_WAIT_POLICY’ is undefined and 30 billion
!      is used when ‘OMP_WAIT_POLICY’ is ‘ACTIVE’.  If there are more
       OpenMP threads than available CPUs, 1000 and 100 spins are used for
!      ‘OMP_WAIT_POLICY’ being ‘ACTIVE’ or undefined, respectively; unless
!      the ‘GOMP_SPINCOUNT’ is lower or ‘OMP_WAIT_POLICY’ is ‘PASSIVE’.
  
  _See also_:
       *note OMP_WAIT_POLICY::
*************** _See also_:
*** 2307,2345 ****
  
  File: libgomp.info,  Node: GOMP_RTEMS_THREAD_POOLS,  Prev: GOMP_SPINCOUNT,  Up: Environment Variables
  
! 4.22 'GOMP_RTEMS_THREAD_POOLS' - Set the RTEMS specific thread pools
  ====================================================================
  
  _Description_:
       This environment variable is only used on the RTEMS real-time
       operating system.  It determines the scheduler instance specific
!      thread pools.  The format for 'GOMP_RTEMS_THREAD_POOLS' is a list
!      of optional '[$]@'
!      configurations separated by ':' where:
!         * '' is the thread pool count for this
            scheduler instance.
!         * '$' is an optional priority for the worker threads
!           of a thread pool according to 'pthread_setschedparam'.  In
            case a priority value is omitted, then a worker thread will
            inherit the priority of the OpenMP primary thread that created
            it.  The priority of the worker thread is not changed after
            creation, even if a new OpenMP primary thread using the worker
            has a different priority.
!         * '@' is the scheduler instance name according
            to the RTEMS application configuration.
       In case no thread pool configuration is specified for a scheduler
       instance, then each OpenMP primary thread of this scheduler
       instance will use its own dynamically allocated thread pool.  To
       limit the worker thread count of the thread pools, each OpenMP
!      primary thread must call 'omp_set_num_threads'.
  _Example_:
!      Lets suppose we have three scheduler instances 'IO', 'WRK0', and
!      'WRK1' with 'GOMP_RTEMS_THREAD_POOLS' set to '"1@WRK0:3$4@WRK1"'.
       Then there are no thread pool restrictions for scheduler instance
!      'IO'.  In the scheduler instance 'WRK0' there is one thread pool
       available.  Since no priority is specified for this scheduler
       instance, the worker thread inherits the priority of the OpenMP
!      primary thread that created it.  In the scheduler instance 'WRK1'
       there are three thread pools available and their worker threads run
       at priority four.
  
--- 2307,2345 ----
  
  File: libgomp.info,  Node: GOMP_RTEMS_THREAD_POOLS,  Prev: GOMP_SPINCOUNT,  Up: Environment Variables
  
! 4.22 ‘GOMP_RTEMS_THREAD_POOLS’ - Set the RTEMS specific thread pools
  ====================================================================
  
  _Description_:
       This environment variable is only used on the RTEMS real-time
       operating system.  It determines the scheduler instance specific
!      thread pools.  The format for ‘GOMP_RTEMS_THREAD_POOLS’ is a list
!      of optional ‘[$]@’
!      configurations separated by ‘:’ where:
!         • ‘’ is the thread pool count for this
            scheduler instance.
!         • ‘$’ is an optional priority for the worker threads
!           of a thread pool according to ‘pthread_setschedparam’.  In
            case a priority value is omitted, then a worker thread will
            inherit the priority of the OpenMP primary thread that created
            it.  The priority of the worker thread is not changed after
            creation, even if a new OpenMP primary thread using the worker
            has a different priority.
!         • ‘@’ is the scheduler instance name according
            to the RTEMS application configuration.
       In case no thread pool configuration is specified for a scheduler
       instance, then each OpenMP primary thread of this scheduler
       instance will use its own dynamically allocated thread pool.  To
       limit the worker thread count of the thread pools, each OpenMP
!      primary thread must call ‘omp_set_num_threads’.
  _Example_:
!      Lets suppose we have three scheduler instances ‘IO’, ‘WRK0’, and
!      ‘WRK1’ with ‘GOMP_RTEMS_THREAD_POOLS’ set to ‘"1@WRK0:3$4@WRK1"’.
       Then there are no thread pool restrictions for scheduler instance
!      ‘IO’.  In the scheduler instance ‘WRK0’ there is one thread pool
       available.  Since no priority is specified for this scheduler
       instance, the worker thread inherits the priority of the OpenMP
!      primary thread that created it.  In the scheduler instance ‘WRK1’
       there are three thread pools available and their worker threads run
       at priority four.
  
*************** File: libgomp.info,  Node: Enabling Open
*** 2350,2359 ****
  ******************
  
  To activate the OpenACC extensions for C/C++ and Fortran, the
! compile-time flag '-fopenacc' must be specified.  This enables the
! OpenACC directive '#pragma acc' in C/C++ and '!$acc' directives in free
! form, 'c$acc', '*$acc' and '!$acc' directives in fixed form, '!$'
! conditional compilation sentinels in free form and 'c$', '*$' and '!$'
  sentinels in fixed form, for Fortran.  The flag also arranges for
  automatic linking of the OpenACC runtime library (*note OpenACC Runtime
  Library Routines::).
--- 2350,2359 ----
  ******************
  
  To activate the OpenACC extensions for C/C++ and Fortran, the
! compile-time flag ‘-fopenacc’ must be specified.  This enables the
! OpenACC directive ‘#pragma acc’ in C/C++ and ‘!$acc’ directives in free
! form, ‘c$acc’, ‘*$acc’ and ‘!$acc’ directives in fixed form, ‘!$’
! conditional compilation sentinels in free form and ‘c$’, ‘*$’ and ‘!$’
  sentinels in fixed form, for Fortran.  The flag also arranges for
  automatic linking of the OpenACC runtime library (*note OpenACC Runtime
  Library Routines::).
*************** File: libgomp.info,  Node: OpenACC Runti
*** 2373,2379 ****
  The runtime routines described here are defined by section 3 of the
  OpenACC specifications in version 2.6.  They have C linkage, and do not
  throw exceptions.  Generally, they are available only for the host, with
! the exception of 'acc_on_device', which is available for both the host
  and the acceleration device.
  
  * Menu:
--- 2373,2379 ----
  The runtime routines described here are defined by section 3 of the
  OpenACC specifications in version 2.6.  They have C linkage, and do not
  throw exceptions.  Generally, they are available only for the host, with
! the exception of ‘acc_on_device’, which is available for both the host
  and the acceleration device.
  
  * Menu:
*************** API routines for the OpenACC Profiling I
*** 2447,2453 ****
  
  File: libgomp.info,  Node: acc_get_num_devices,  Next: acc_set_device_type,  Up: OpenACC Runtime Library Routines
  
! 6.1 'acc_get_num_devices' - Get number of devices for given device type
  =======================================================================
  
  _Description_
--- 2447,2453 ----
  
  File: libgomp.info,  Node: acc_get_num_devices,  Next: acc_set_device_type,  Up: OpenACC Runtime Library Routines
  
! 6.1 ‘acc_get_num_devices’ - Get number of devices for given device type
  =======================================================================
  
  _Description_
*************** _Description_
*** 2455,2465 ****
       available for the device type specified in DEVICETYPE.
  
  _C/C++_:
!      _Prototype_:   'int acc_get_num_devices(acc_device_t devicetype);'
  
  _Fortran_:
!      _Interface_:   'integer function acc_get_num_devices(devicetype)'
!                     'integer(kind=acc_device_kind) devicetype'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2455,2465 ----
       available for the device type specified in DEVICETYPE.
  
  _C/C++_:
!      _Prototype_:   ‘int acc_get_num_devices(acc_device_t devicetype);’
  
  _Fortran_:
!      _Interface_:   ‘integer function acc_get_num_devices(devicetype)’
!                     ‘integer(kind=acc_device_kind) devicetype’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2468,2474 ****
  
  File: libgomp.info,  Node: acc_set_device_type,  Next: acc_get_device_type,  Prev: acc_get_num_devices,  Up: OpenACC Runtime Library Routines
  
! 6.2 'acc_set_device_type' - Set type of device accelerator to use.
  ==================================================================
  
  _Description_
--- 2468,2474 ----
  
  File: libgomp.info,  Node: acc_set_device_type,  Next: acc_get_device_type,  Prev: acc_get_num_devices,  Up: OpenACC Runtime Library Routines
  
! 6.2 ‘acc_set_device_type’ - Set type of device accelerator to use.
  ==================================================================
  
  _Description_
*************** _Description_
*** 2477,2487 ****
       kernels region.
  
  _C/C++_:
!      _Prototype_:   'acc_set_device_type(acc_device_t devicetype);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_set_device_type(devicetype)'
!                     'integer(kind=acc_device_kind) devicetype'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2477,2487 ----
       kernels region.
  
  _C/C++_:
!      _Prototype_:   ‘acc_set_device_type(acc_device_t devicetype);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_set_device_type(devicetype)’
!                     ‘integer(kind=acc_device_kind) devicetype’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2490,2514 ****
  
  File: libgomp.info,  Node: acc_get_device_type,  Next: acc_set_device_num,  Prev: acc_set_device_type,  Up: OpenACC Runtime Library Routines
  
! 6.3 'acc_get_device_type' - Get type of device accelerator to be used.
  ======================================================================
  
  _Description_
       This function returns what device type will be used when executing
       a parallel or kernels region.
  
!      This function returns 'acc_device_none' if 'acc_get_device_type' is
!      called from 'acc_ev_device_init_start', 'acc_ev_device_init_end'
       callbacks of the OpenACC Profiling Interface (*note OpenACC
       Profiling Interface::), that is, if the device is currently being
       initialized.
  
  _C/C++_:
!      _Prototype_:   'acc_device_t acc_get_device_type(void);'
  
  _Fortran_:
!      _Interface_:   'function acc_get_device_type(void)'
!                     'integer(kind=acc_device_kind) acc_get_device_type'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2490,2514 ----
  
  File: libgomp.info,  Node: acc_get_device_type,  Next: acc_set_device_num,  Prev: acc_set_device_type,  Up: OpenACC Runtime Library Routines
  
! 6.3 ‘acc_get_device_type’ - Get type of device accelerator to be used.
  ======================================================================
  
  _Description_
       This function returns what device type will be used when executing
       a parallel or kernels region.
  
!      This function returns ‘acc_device_none’ if ‘acc_get_device_type’ is
!      called from ‘acc_ev_device_init_start’, ‘acc_ev_device_init_end’
       callbacks of the OpenACC Profiling Interface (*note OpenACC
       Profiling Interface::), that is, if the device is currently being
       initialized.
  
  _C/C++_:
!      _Prototype_:   ‘acc_device_t acc_get_device_type(void);’
  
  _Fortran_:
!      _Interface_:   ‘function acc_get_device_type(void)’
!                     ‘integer(kind=acc_device_kind) acc_get_device_type’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2517,2523 ****
  
  File: libgomp.info,  Node: acc_set_device_num,  Next: acc_get_device_num,  Prev: acc_get_device_type,  Up: OpenACC Runtime Library Routines
  
! 6.4 'acc_set_device_num' - Set device number to use.
  ====================================================
  
  _Description_
--- 2517,2523 ----
  
  File: libgomp.info,  Node: acc_set_device_num,  Next: acc_get_device_num,  Prev: acc_get_device_type,  Up: OpenACC Runtime Library Routines
  
! 6.4 ‘acc_set_device_num’ - Set device number to use.
  ====================================================
  
  _Description_
*************** _Description_
*** 2526,2538 ****
       DEVICETYPE.
  
  _C/C++_:
!      _Prototype_:   'acc_set_device_num(int devicenum, acc_device_t
!                     devicetype);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_set_device_num(devicenum, devicetype)'
!                     'integer devicenum'
!                     'integer(kind=acc_device_kind) devicetype'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2526,2538 ----
       DEVICETYPE.
  
  _C/C++_:
!      _Prototype_:   ‘acc_set_device_num(int devicenum, acc_device_t
!                     devicetype);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_set_device_num(devicenum, devicetype)’
!                     ‘integer devicenum’
!                     ‘integer(kind=acc_device_kind) devicetype’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2541,2547 ****
  
  File: libgomp.info,  Node: acc_get_device_num,  Next: acc_get_property,  Prev: acc_set_device_num,  Up: OpenACC Runtime Library Routines
  
! 6.5 'acc_get_device_num' - Get device number to be used.
  ========================================================
  
  _Description_
--- 2541,2547 ----
  
  File: libgomp.info,  Node: acc_get_device_num,  Next: acc_get_property,  Prev: acc_set_device_num,  Up: OpenACC Runtime Library Routines
  
! 6.5 ‘acc_get_device_num’ - Get device number to be used.
  ========================================================
  
  _Description_
*************** _Description_
*** 2550,2561 ****
       parallel or kernels region.
  
  _C/C++_:
!      _Prototype_:   'int acc_get_device_num(acc_device_t devicetype);'
  
  _Fortran_:
!      _Interface_:   'function acc_get_device_num(devicetype)'
!                     'integer(kind=acc_device_kind) devicetype'
!                     'integer acc_get_device_num'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2550,2561 ----
       parallel or kernels region.
  
  _C/C++_:
!      _Prototype_:   ‘int acc_get_device_num(acc_device_t devicetype);’
  
  _Fortran_:
!      _Interface_:   ‘function acc_get_device_num(devicetype)’
!                     ‘integer(kind=acc_device_kind) devicetype’
!                     ‘integer acc_get_device_num’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2564,2608 ****
  
  File: libgomp.info,  Node: acc_get_property,  Next: acc_async_test,  Prev: acc_get_device_num,  Up: OpenACC Runtime Library Routines
  
! 6.6 'acc_get_property' - Get device property.
  =============================================
  
  _Description_
       These routines return the value of the specified PROPERTY for the
       device being queried according to DEVICENUM and DEVICETYPE.
       Integer-valued and string-valued properties are returned by
!      'acc_get_property' and 'acc_get_property_string' respectively.  The
!      Fortran 'acc_get_property_string' subroutine returns the string
       retrieved in its fourth argument while the remaining entry points
       are functions, which pass the return value as their result.
  
       Note for Fortran, only: the OpenACC technical committee corrected
       and, hence, modified the interface introduced in OpenACC 2.6.  The
!      kind-value parameter 'acc_device_property' has been renamed to
!      'acc_device_property_kind' for consistency and the return type of
!      the 'acc_get_property' function is now a 'c_size_t' integer instead
!      of a 'acc_device_property' integer.  The parameter
!      'acc_device_property' will continue to be provided, but might be
       removed in a future version of GCC.
  
  _C/C++_:
!      _Prototype_:   'size_t acc_get_property(int devicenum, acc_device_t
!                     devicetype, acc_device_property_t property);'
!      _Prototype_:   'const char *acc_get_property_string(int devicenum,
                      acc_device_t devicetype, acc_device_property_t
!                     property);'
  
  _Fortran_:
!      _Interface_:   'function acc_get_property(devicenum, devicetype,
!                     property)'
!      _Interface_:   'subroutine acc_get_property_string(devicenum,
!                     devicetype, property, string)'
!                     'use ISO_C_Binding, only: c_size_t'
!                     'integer devicenum'
!                     'integer(kind=acc_device_kind) devicetype'
!                     'integer(kind=acc_device_property_kind) property'
!                     'integer(kind=c_size_t) acc_get_property'
!                     'character(*) string'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2564,2608 ----
  
  File: libgomp.info,  Node: acc_get_property,  Next: acc_async_test,  Prev: acc_get_device_num,  Up: OpenACC Runtime Library Routines
  
! 6.6 ‘acc_get_property’ - Get device property.
  =============================================
  
  _Description_
       These routines return the value of the specified PROPERTY for the
       device being queried according to DEVICENUM and DEVICETYPE.
       Integer-valued and string-valued properties are returned by
!      ‘acc_get_property’ and ‘acc_get_property_string’ respectively.  The
!      Fortran ‘acc_get_property_string’ subroutine returns the string
       retrieved in its fourth argument while the remaining entry points
       are functions, which pass the return value as their result.
  
       Note for Fortran, only: the OpenACC technical committee corrected
       and, hence, modified the interface introduced in OpenACC 2.6.  The
!      kind-value parameter ‘acc_device_property’ has been renamed to
!      ‘acc_device_property_kind’ for consistency and the return type of
!      the ‘acc_get_property’ function is now a ‘c_size_t’ integer instead
!      of a ‘acc_device_property’ integer.  The parameter
!      ‘acc_device_property’ will continue to be provided, but might be
       removed in a future version of GCC.
  
  _C/C++_:
!      _Prototype_:   ‘size_t acc_get_property(int devicenum, acc_device_t
!                     devicetype, acc_device_property_t property);’
!      _Prototype_:   ‘const char *acc_get_property_string(int devicenum,
                      acc_device_t devicetype, acc_device_property_t
!                     property);’
  
  _Fortran_:
!      _Interface_:   ‘function acc_get_property(devicenum, devicetype,
!                     property)’
!      _Interface_:   ‘subroutine acc_get_property_string(devicenum,
!                     devicetype, property, string)’
!                     ‘use ISO_C_Binding, only: c_size_t’
!                     ‘integer devicenum’
!                     ‘integer(kind=acc_device_kind) devicetype’
!                     ‘integer(kind=acc_device_property_kind) property’
!                     ‘integer(kind=c_size_t) acc_get_property’
!                     ‘character(*) string’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2611,2633 ****
  
  File: libgomp.info,  Node: acc_async_test,  Next: acc_async_test_all,  Prev: acc_get_property,  Up: OpenACC Runtime Library Routines
  
! 6.7 'acc_async_test' - Test for completion of a specific asynchronous operation.
  ================================================================================
  
  _Description_
       This function tests for completion of the asynchronous operation
       specified in ARG.  In C/C++, a non-zero value will be returned to
       indicate the specified asynchronous operation has completed.  While
!      Fortran will return a 'true'.  If the asynchronous operation has
!      not completed, C/C++ returns a zero and Fortran returns a 'false'.
  
  _C/C++_:
!      _Prototype_:   'int acc_async_test(int arg);'
  
  _Fortran_:
!      _Interface_:   'function acc_async_test(arg)'
!                     'integer(kind=acc_handle_kind) arg'
!                     'logical acc_async_test'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2611,2633 ----
  
  File: libgomp.info,  Node: acc_async_test,  Next: acc_async_test_all,  Prev: acc_get_property,  Up: OpenACC Runtime Library Routines
  
! 6.7 ‘acc_async_test’ - Test for completion of a specific asynchronous operation.
  ================================================================================
  
  _Description_
       This function tests for completion of the asynchronous operation
       specified in ARG.  In C/C++, a non-zero value will be returned to
       indicate the specified asynchronous operation has completed.  While
!      Fortran will return a ‘true’.  If the asynchronous operation has
!      not completed, C/C++ returns a zero and Fortran returns a ‘false’.
  
  _C/C++_:
!      _Prototype_:   ‘int acc_async_test(int arg);’
  
  _Fortran_:
!      _Interface_:   ‘function acc_async_test(arg)’
!                     ‘integer(kind=acc_handle_kind) arg’
!                     ‘logical acc_async_test’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2636,2657 ****
  
  File: libgomp.info,  Node: acc_async_test_all,  Next: acc_wait,  Prev: acc_async_test,  Up: OpenACC Runtime Library Routines
  
! 6.8 'acc_async_test_all' - Tests for completion of all asynchronous operations.
  ===============================================================================
  
  _Description_
       This function tests for completion of all asynchronous operations.
       In C/C++, a non-zero value will be returned to indicate all
       asynchronous operations have completed.  While Fortran will return
!      a 'true'.  If any asynchronous operation has not completed, C/C++
!      returns a zero and Fortran returns a 'false'.
  
  _C/C++_:
!      _Prototype_:   'int acc_async_test_all(void);'
  
  _Fortran_:
!      _Interface_:   'function acc_async_test()'
!                     'logical acc_get_device_num'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2636,2657 ----
  
  File: libgomp.info,  Node: acc_async_test_all,  Next: acc_wait,  Prev: acc_async_test,  Up: OpenACC Runtime Library Routines
  
! 6.8 ‘acc_async_test_all’ - Tests for completion of all asynchronous operations.
  ===============================================================================
  
  _Description_
       This function tests for completion of all asynchronous operations.
       In C/C++, a non-zero value will be returned to indicate all
       asynchronous operations have completed.  While Fortran will return
!      a ‘true’.  If any asynchronous operation has not completed, C/C++
!      returns a zero and Fortran returns a ‘false’.
  
  _C/C++_:
!      _Prototype_:   ‘int acc_async_test_all(void);’
  
  _Fortran_:
!      _Interface_:   ‘function acc_async_test()’
!                     ‘logical acc_get_device_num’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2660,2666 ****
  
  File: libgomp.info,  Node: acc_wait,  Next: acc_wait_all,  Prev: acc_async_test_all,  Up: OpenACC Runtime Library Routines
  
! 6.9 'acc_wait' - Wait for completion of a specific asynchronous operation.
  ==========================================================================
  
  _Description_
--- 2660,2666 ----
  
  File: libgomp.info,  Node: acc_wait,  Next: acc_wait_all,  Prev: acc_async_test_all,  Up: OpenACC Runtime Library Routines
  
! 6.9 ‘acc_wait’ - Wait for completion of a specific asynchronous operation.
  ==========================================================================
  
  _Description_
*************** _Description_
*** 2668,2685 ****
       specified in ARG.
  
  _C/C++_:
!      _Prototype_:   'acc_wait(arg);'
!      _Prototype     'acc_async_wait(arg);'
       (OpenACC 1.0
       compatibility)_:
  
  _Fortran_:
!      _Interface_:   'subroutine acc_wait(arg)'
!                     'integer(acc_handle_kind) arg'
!      _Interface     'subroutine acc_async_wait(arg)'
       (OpenACC 1.0
       compatibility)_:
!                     'integer(acc_handle_kind) arg'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2668,2685 ----
       specified in ARG.
  
  _C/C++_:
!      _Prototype_:   ‘acc_wait(arg);’
!      _Prototype     ‘acc_async_wait(arg);’
       (OpenACC 1.0
       compatibility)_:
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_wait(arg)’
!                     ‘integer(acc_handle_kind) arg’
!      _Interface     ‘subroutine acc_async_wait(arg)’
       (OpenACC 1.0
       compatibility)_:
!                     ‘integer(acc_handle_kind) arg’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2688,2694 ****
  
  File: libgomp.info,  Node: acc_wait_all,  Next: acc_wait_all_async,  Prev: acc_wait,  Up: OpenACC Runtime Library Routines
  
! 6.10 'acc_wait_all' - Waits for completion of all asynchronous operations.
  ==========================================================================
  
  _Description_
--- 2688,2694 ----
  
  File: libgomp.info,  Node: acc_wait_all,  Next: acc_wait_all_async,  Prev: acc_wait,  Up: OpenACC Runtime Library Routines
  
! 6.10 ‘acc_wait_all’ - Waits for completion of all asynchronous operations.
  ==========================================================================
  
  _Description_
*************** _Description_
*** 2696,2709 ****
       operations.
  
  _C/C++_:
!      _Prototype_:   'acc_wait_all(void);'
!      _Prototype     'acc_async_wait_all(void);'
       (OpenACC 1.0
       compatibility)_:
  
  _Fortran_:
!      _Interface_:   'subroutine acc_wait_all()'
!      _Interface     'subroutine acc_async_wait_all()'
       (OpenACC 1.0
       compatibility)_:
  
--- 2696,2709 ----
       operations.
  
  _C/C++_:
!      _Prototype_:   ‘acc_wait_all(void);’
!      _Prototype     ‘acc_async_wait_all(void);’
       (OpenACC 1.0
       compatibility)_:
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_wait_all()’
!      _Interface     ‘subroutine acc_async_wait_all()’
       (OpenACC 1.0
       compatibility)_:
  
*************** _Reference_:
*** 2714,2720 ****
  
  File: libgomp.info,  Node: acc_wait_all_async,  Next: acc_wait_async,  Prev: acc_wait_all,  Up: OpenACC Runtime Library Routines
  
! 6.11 'acc_wait_all_async' - Wait for completion of all asynchronous operations.
  ===============================================================================
  
  _Description_
--- 2714,2720 ----
  
  File: libgomp.info,  Node: acc_wait_all_async,  Next: acc_wait_async,  Prev: acc_wait_all,  Up: OpenACC Runtime Library Routines
  
! 6.11 ‘acc_wait_all_async’ - Wait for completion of all asynchronous operations.
  ===============================================================================
  
  _Description_
*************** _Description_
*** 2723,2733 ****
       on any queue.
  
  _C/C++_:
!      _Prototype_:   'acc_wait_all_async(int async);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_wait_all_async(async)'
!                     'integer(acc_handle_kind) async'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2723,2733 ----
       on any queue.
  
  _C/C++_:
!      _Prototype_:   ‘acc_wait_all_async(int async);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_wait_all_async(async)’
!                     ‘integer(acc_handle_kind) async’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2736,2742 ****
  
  File: libgomp.info,  Node: acc_wait_async,  Next: acc_init,  Prev: acc_wait_all_async,  Up: OpenACC Runtime Library Routines
  
! 6.12 'acc_wait_async' - Wait for completion of asynchronous operations.
  =======================================================================
  
  _Description_
--- 2736,2742 ----
  
  File: libgomp.info,  Node: acc_wait_async,  Next: acc_init,  Prev: acc_wait_all_async,  Up: OpenACC Runtime Library Routines
  
! 6.12 ‘acc_wait_async’ - Wait for completion of asynchronous operations.
  =======================================================================
  
  _Description_
*************** _Description_
*** 2744,2754 ****
       all asynchronous operations enqueued on queue ARG.
  
  _C/C++_:
!      _Prototype_:   'acc_wait_async(int arg, int async);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_wait_async(arg, async)'
!                     'integer(acc_handle_kind) arg, async'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2744,2754 ----
       all asynchronous operations enqueued on queue ARG.
  
  _C/C++_:
!      _Prototype_:   ‘acc_wait_async(int arg, int async);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_wait_async(arg, async)’
!                     ‘integer(acc_handle_kind) arg, async’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2757,2763 ****
  
  File: libgomp.info,  Node: acc_init,  Next: acc_shutdown,  Prev: acc_wait_async,  Up: OpenACC Runtime Library Routines
  
! 6.13 'acc_init' - Initialize runtime for a specific device type.
  ================================================================
  
  _Description_
--- 2757,2763 ----
  
  File: libgomp.info,  Node: acc_init,  Next: acc_shutdown,  Prev: acc_wait_async,  Up: OpenACC Runtime Library Routines
  
! 6.13 ‘acc_init’ - Initialize runtime for a specific device type.
  ================================================================
  
  _Description_
*************** _Description_
*** 2765,2775 ****
       in DEVICETYPE.
  
  _C/C++_:
!      _Prototype_:   'acc_init(acc_device_t devicetype);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_init(devicetype)'
!                     'integer(acc_device_kind) devicetype'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2765,2775 ----
       in DEVICETYPE.
  
  _C/C++_:
!      _Prototype_:   ‘acc_init(acc_device_t devicetype);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_init(devicetype)’
!                     ‘integer(acc_device_kind) devicetype’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2778,2784 ****
  
  File: libgomp.info,  Node: acc_shutdown,  Next: acc_on_device,  Prev: acc_init,  Up: OpenACC Runtime Library Routines
  
! 6.14 'acc_shutdown' - Shuts down the runtime for a specific device type.
  ========================================================================
  
  _Description_
--- 2778,2784 ----
  
  File: libgomp.info,  Node: acc_shutdown,  Next: acc_on_device,  Prev: acc_init,  Up: OpenACC Runtime Library Routines
  
! 6.14 ‘acc_shutdown’ - Shuts down the runtime for a specific device type.
  ========================================================================
  
  _Description_
*************** _Description_
*** 2786,2796 ****
       in DEVICETYPE.
  
  _C/C++_:
!      _Prototype_:   'acc_shutdown(acc_device_t devicetype);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_shutdown(devicetype)'
!                     'integer(acc_device_kind) devicetype'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2786,2796 ----
       in DEVICETYPE.
  
  _C/C++_:
!      _Prototype_:   ‘acc_shutdown(acc_device_t devicetype);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_shutdown(devicetype)’
!                     ‘integer(acc_device_kind) devicetype’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2799,2822 ****
  
  File: libgomp.info,  Node: acc_on_device,  Next: acc_malloc,  Prev: acc_shutdown,  Up: OpenACC Runtime Library Routines
  
! 6.15 'acc_on_device' - Whether executing on a particular device
  ===============================================================
  
  _Description_:
       This function returns whether the program is executing on a
       particular device specified in DEVICETYPE.  In C/C++ a non-zero
       value is returned to indicate the device is executing on the
!      specified device type.  In Fortran, 'true' will be returned.  If
       the program is not executing on the specified device type C/C++
!      will return a zero, while Fortran will return 'false'.
  
  _C/C++_:
!      _Prototype_:   'acc_on_device(acc_device_t devicetype);'
  
  _Fortran_:
!      _Interface_:   'function acc_on_device(devicetype)'
!                     'integer(acc_device_kind) devicetype'
!                     'logical acc_on_device'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2799,2822 ----
  
  File: libgomp.info,  Node: acc_on_device,  Next: acc_malloc,  Prev: acc_shutdown,  Up: OpenACC Runtime Library Routines
  
! 6.15 ‘acc_on_device’ - Whether executing on a particular device
  ===============================================================
  
  _Description_:
       This function returns whether the program is executing on a
       particular device specified in DEVICETYPE.  In C/C++ a non-zero
       value is returned to indicate the device is executing on the
!      specified device type.  In Fortran, ‘true’ will be returned.  If
       the program is not executing on the specified device type C/C++
!      will return a zero, while Fortran will return ‘false’.
  
  _C/C++_:
!      _Prototype_:   ‘acc_on_device(acc_device_t devicetype);’
  
  _Fortran_:
!      _Interface_:   ‘function acc_on_device(devicetype)’
!                     ‘integer(acc_device_kind) devicetype’
!                     ‘logical acc_on_device’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2825,2831 ****
  
  File: libgomp.info,  Node: acc_malloc,  Next: acc_free,  Prev: acc_on_device,  Up: OpenACC Runtime Library Routines
  
! 6.16 'acc_malloc' - Allocate device memory.
  ===========================================
  
  _Description_
--- 2825,2831 ----
  
  File: libgomp.info,  Node: acc_malloc,  Next: acc_free,  Prev: acc_on_device,  Up: OpenACC Runtime Library Routines
  
! 6.16 ‘acc_malloc’ - Allocate device memory.
  ===========================================
  
  _Description_
*************** _Description_
*** 2833,2839 ****
       device address of the allocated memory.
  
  _C/C++_:
!      _Prototype_:   'd_void* acc_malloc(size_t len);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2833,2839 ----
       device address of the allocated memory.
  
  _C/C++_:
!      _Prototype_:   ‘d_void* acc_malloc(size_t len);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2842,2855 ****
  
  File: libgomp.info,  Node: acc_free,  Next: acc_copyin,  Prev: acc_malloc,  Up: OpenACC Runtime Library Routines
  
! 6.17 'acc_free' - Free device memory.
  =====================================
  
  _Description_
!      Free previously allocated device memory at the device address 'a'.
  
  _C/C++_:
!      _Prototype_:   'acc_free(d_void *a);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2842,2855 ----
  
  File: libgomp.info,  Node: acc_free,  Next: acc_copyin,  Prev: acc_malloc,  Up: OpenACC Runtime Library Routines
  
! 6.17 ‘acc_free’ - Free device memory.
  =====================================
  
  _Description_
!      Free previously allocated device memory at the device address ‘a’.
  
  _C/C++_:
!      _Prototype_:   ‘acc_free(d_void *a);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2858,2864 ****
  
  File: libgomp.info,  Node: acc_copyin,  Next: acc_present_or_copyin,  Prev: acc_free,  Up: OpenACC Runtime Library Routines
  
! 6.18 'acc_copyin' - Allocate device memory and copy host memory to it.
  ======================================================================
  
  _Description_
--- 2858,2864 ----
  
  File: libgomp.info,  Node: acc_copyin,  Next: acc_present_or_copyin,  Prev: acc_free,  Up: OpenACC Runtime Library Routines
  
! 6.18 ‘acc_copyin’ - Allocate device memory and copy host memory to it.
  ======================================================================
  
  _Description_
*************** _Description_
*** 2871,2893 ****
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   'void *acc_copyin(h_void *a, size_t len);'
!      _Prototype_:   'void *acc_copyin_async(h_void *a, size_t len, int
!                     async);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_copyin(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_copyin(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!      _Interface_:   'subroutine acc_copyin_async(a, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer(acc_handle_kind) :: async'
!      _Interface_:   'subroutine acc_copyin_async(a, len, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!                     'integer(acc_handle_kind) :: async'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2871,2893 ----
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   ‘void *acc_copyin(h_void *a, size_t len);’
!      _Prototype_:   ‘void *acc_copyin_async(h_void *a, size_t len, int
!                     async);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_copyin(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_copyin(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!      _Interface_:   ‘subroutine acc_copyin_async(a, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer(acc_handle_kind) :: async’
!      _Interface_:   ‘subroutine acc_copyin_async(a, len, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!                     ‘integer(acc_handle_kind) :: async’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2896,2902 ****
  
  File: libgomp.info,  Node: acc_present_or_copyin,  Next: acc_create,  Prev: acc_copyin,  Up: OpenACC Runtime Library Routines
  
! 6.19 'acc_present_or_copyin' - If the data is not present on the device, allocate device memory and copy from host memory.
  ==========================================================================================================================
  
  _Description_
--- 2896,2902 ----
  
  File: libgomp.info,  Node: acc_present_or_copyin,  Next: acc_create,  Prev: acc_copyin,  Up: OpenACC Runtime Library Routines
  
! 6.19 ‘acc_present_or_copyin’ - If the data is not present on the device, allocate device memory and copy from host memory.
  ==========================================================================================================================
  
  _Description_
*************** _Description_
*** 2909,2933 ****
       specifies a contiguous array section.  The second form A specifies
       a variable or array element and LEN specifies the length in bytes.
  
!      Note that 'acc_present_or_copyin' and 'acc_pcopyin' exist for
       backward compatibility with OpenACC 2.0; use *note acc_copyin::
       instead.
  
  _C/C++_:
!      _Prototype_:   'void *acc_present_or_copyin(h_void *a, size_t len);'
!      _Prototype_:   'void *acc_pcopyin(h_void *a, size_t len);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_present_or_copyin(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_present_or_copyin(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!      _Interface_:   'subroutine acc_pcopyin(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_pcopyin(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2909,2933 ----
       specifies a contiguous array section.  The second form A specifies
       a variable or array element and LEN specifies the length in bytes.
  
!      Note that ‘acc_present_or_copyin’ and ‘acc_pcopyin’ exist for
       backward compatibility with OpenACC 2.0; use *note acc_copyin::
       instead.
  
  _C/C++_:
!      _Prototype_:   ‘void *acc_present_or_copyin(h_void *a, size_t len);’
!      _Prototype_:   ‘void *acc_pcopyin(h_void *a, size_t len);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_present_or_copyin(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_present_or_copyin(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!      _Interface_:   ‘subroutine acc_pcopyin(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_pcopyin(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2936,2942 ****
  
  File: libgomp.info,  Node: acc_create,  Next: acc_present_or_create,  Prev: acc_present_or_copyin,  Up: OpenACC Runtime Library Routines
  
! 6.20 'acc_create' - Allocate device memory and map it to host memory.
  =====================================================================
  
  _Description_
--- 2936,2942 ----
  
  File: libgomp.info,  Node: acc_create,  Next: acc_present_or_create,  Prev: acc_present_or_copyin,  Up: OpenACC Runtime Library Routines
  
! 6.20 ‘acc_create’ - Allocate device memory and map it to host memory.
  =====================================================================
  
  _Description_
*************** _Description_
*** 2950,2972 ****
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   'void *acc_create(h_void *a, size_t len);'
!      _Prototype_:   'void *acc_create_async(h_void *a, size_t len, int
!                     async);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_create(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_create(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!      _Interface_:   'subroutine acc_create_async(a, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer(acc_handle_kind) :: async'
!      _Interface_:   'subroutine acc_create_async(a, len, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!                     'integer(acc_handle_kind) :: async'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2950,2972 ----
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   ‘void *acc_create(h_void *a, size_t len);’
!      _Prototype_:   ‘void *acc_create_async(h_void *a, size_t len, int
!                     async);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_create(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_create(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!      _Interface_:   ‘subroutine acc_create_async(a, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer(acc_handle_kind) :: async’
!      _Interface_:   ‘subroutine acc_create_async(a, len, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!                     ‘integer(acc_handle_kind) :: async’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 2975,2981 ****
  
  File: libgomp.info,  Node: acc_present_or_create,  Next: acc_copyout,  Prev: acc_create,  Up: OpenACC Runtime Library Routines
  
! 6.21 'acc_present_or_create' - If the data is not present on the device, allocate device memory and map it to host memory.
  ==========================================================================================================================
  
  _Description_
--- 2975,2981 ----
  
  File: libgomp.info,  Node: acc_present_or_create,  Next: acc_copyout,  Prev: acc_create,  Up: OpenACC Runtime Library Routines
  
! 6.21 ‘acc_present_or_create’ - If the data is not present on the device, allocate device memory and map it to host memory.
  ==========================================================================================================================
  
  _Description_
*************** _Description_
*** 2988,3012 ****
       specifies a contiguous array section.  The second form A specifies
       a variable or array element and LEN specifies the length in bytes.
  
!      Note that 'acc_present_or_create' and 'acc_pcreate' exist for
       backward compatibility with OpenACC 2.0; use *note acc_create::
       instead.
  
  _C/C++_:
!      _Prototype_:   'void *acc_present_or_create(h_void *a, size_t len)'
!      _Prototype_:   'void *acc_pcreate(h_void *a, size_t len)'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_present_or_create(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_present_or_create(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!      _Interface_:   'subroutine acc_pcreate(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_pcreate(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 2988,3012 ----
       specifies a contiguous array section.  The second form A specifies
       a variable or array element and LEN specifies the length in bytes.
  
!      Note that ‘acc_present_or_create’ and ‘acc_pcreate’ exist for
       backward compatibility with OpenACC 2.0; use *note acc_create::
       instead.
  
  _C/C++_:
!      _Prototype_:   ‘void *acc_present_or_create(h_void *a, size_t len)’
!      _Prototype_:   ‘void *acc_pcreate(h_void *a, size_t len)’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_present_or_create(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_present_or_create(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!      _Interface_:   ‘subroutine acc_pcreate(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_pcreate(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3015,3021 ****
  
  File: libgomp.info,  Node: acc_copyout,  Next: acc_delete,  Prev: acc_present_or_create,  Up: OpenACC Runtime Library Routines
  
! 6.22 'acc_copyout' - Copy device memory to host memory.
  =======================================================
  
  _Description_
--- 3015,3021 ----
  
  File: libgomp.info,  Node: acc_copyout,  Next: acc_delete,  Prev: acc_present_or_create,  Up: OpenACC Runtime Library Routines
  
! 6.22 ‘acc_copyout’ - Copy device memory to host memory.
  =======================================================
  
  _Description_
*************** _Description_
*** 3027,3063 ****
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   'acc_copyout(h_void *a, size_t len);'
!      _Prototype_:   'acc_copyout_async(h_void *a, size_t len, int async);'
!      _Prototype_:   'acc_copyout_finalize(h_void *a, size_t len);'
!      _Prototype_:   'acc_copyout_finalize_async(h_void *a, size_t len, int
!                     async);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_copyout(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_copyout(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!      _Interface_:   'subroutine acc_copyout_async(a, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer(acc_handle_kind) :: async'
!      _Interface_:   'subroutine acc_copyout_async(a, len, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!                     'integer(acc_handle_kind) :: async'
!      _Interface_:   'subroutine acc_copyout_finalize(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_copyout_finalize(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!      _Interface_:   'subroutine acc_copyout_finalize_async(a, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer(acc_handle_kind) :: async'
!      _Interface_:   'subroutine acc_copyout_finalize_async(a, len, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!                     'integer(acc_handle_kind) :: async'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3027,3063 ----
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   ‘acc_copyout(h_void *a, size_t len);’
!      _Prototype_:   ‘acc_copyout_async(h_void *a, size_t len, int async);’
!      _Prototype_:   ‘acc_copyout_finalize(h_void *a, size_t len);’
!      _Prototype_:   ‘acc_copyout_finalize_async(h_void *a, size_t len, int
!                     async);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_copyout(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_copyout(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!      _Interface_:   ‘subroutine acc_copyout_async(a, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer(acc_handle_kind) :: async’
!      _Interface_:   ‘subroutine acc_copyout_async(a, len, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!                     ‘integer(acc_handle_kind) :: async’
!      _Interface_:   ‘subroutine acc_copyout_finalize(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_copyout_finalize(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!      _Interface_:   ‘subroutine acc_copyout_finalize_async(a, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer(acc_handle_kind) :: async’
!      _Interface_:   ‘subroutine acc_copyout_finalize_async(a, len, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!                     ‘integer(acc_handle_kind) :: async’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3066,3072 ****
  
  File: libgomp.info,  Node: acc_delete,  Next: acc_update_device,  Prev: acc_copyout,  Up: OpenACC Runtime Library Routines
  
! 6.23 'acc_delete' - Free device memory.
  =======================================
  
  _Description_
--- 3066,3072 ----
  
  File: libgomp.info,  Node: acc_delete,  Next: acc_update_device,  Prev: acc_copyout,  Up: OpenACC Runtime Library Routines
  
! 6.23 ‘acc_delete’ - Free device memory.
  =======================================
  
  _Description_
*************** _Description_
*** 3078,3114 ****
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   'acc_delete(h_void *a, size_t len);'
!      _Prototype_:   'acc_delete_async(h_void *a, size_t len, int async);'
!      _Prototype_:   'acc_delete_finalize(h_void *a, size_t len);'
!      _Prototype_:   'acc_delete_finalize_async(h_void *a, size_t len, int
!                     async);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_delete(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_delete(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!      _Interface_:   'subroutine acc_delete_async(a, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer(acc_handle_kind) :: async'
!      _Interface_:   'subroutine acc_delete_async(a, len, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!                     'integer(acc_handle_kind) :: async'
!      _Interface_:   'subroutine acc_delete_finalize(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_delete_finalize(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!      _Interface_:   'subroutine acc_delete_async_finalize(a, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer(acc_handle_kind) :: async'
!      _Interface_:   'subroutine acc_delete_async_finalize(a, len, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!                     'integer(acc_handle_kind) :: async'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3078,3114 ----
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   ‘acc_delete(h_void *a, size_t len);’
!      _Prototype_:   ‘acc_delete_async(h_void *a, size_t len, int async);’
!      _Prototype_:   ‘acc_delete_finalize(h_void *a, size_t len);’
!      _Prototype_:   ‘acc_delete_finalize_async(h_void *a, size_t len, int
!                     async);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_delete(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_delete(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!      _Interface_:   ‘subroutine acc_delete_async(a, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer(acc_handle_kind) :: async’
!      _Interface_:   ‘subroutine acc_delete_async(a, len, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!                     ‘integer(acc_handle_kind) :: async’
!      _Interface_:   ‘subroutine acc_delete_finalize(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_delete_finalize(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!      _Interface_:   ‘subroutine acc_delete_async_finalize(a, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer(acc_handle_kind) :: async’
!      _Interface_:   ‘subroutine acc_delete_async_finalize(a, len, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!                     ‘integer(acc_handle_kind) :: async’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3117,3123 ****
  
  File: libgomp.info,  Node: acc_update_device,  Next: acc_update_self,  Prev: acc_delete,  Up: OpenACC Runtime Library Routines
  
! 6.24 'acc_update_device' - Update device memory from mapped host memory.
  ========================================================================
  
  _Description_
--- 3117,3123 ----
  
  File: libgomp.info,  Node: acc_update_device,  Next: acc_update_self,  Prev: acc_delete,  Up: OpenACC Runtime Library Routines
  
! 6.24 ‘acc_update_device’ - Update device memory from mapped host memory.
  ========================================================================
  
  _Description_
*************** _Description_
*** 3130,3151 ****
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   'acc_update_device(h_void *a, size_t len);'
!      _Prototype_:   'acc_update_device(h_void *a, size_t len, async);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_update_device(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_update_device(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!      _Interface_:   'subroutine acc_update_device_async(a, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer(acc_handle_kind) :: async'
!      _Interface_:   'subroutine acc_update_device_async(a, len, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!                     'integer(acc_handle_kind) :: async'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3130,3151 ----
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   ‘acc_update_device(h_void *a, size_t len);’
!      _Prototype_:   ‘acc_update_device(h_void *a, size_t len, async);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_update_device(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_update_device(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!      _Interface_:   ‘subroutine acc_update_device_async(a, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer(acc_handle_kind) :: async’
!      _Interface_:   ‘subroutine acc_update_device_async(a, len, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!                     ‘integer(acc_handle_kind) :: async’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3154,3160 ****
  
  File: libgomp.info,  Node: acc_update_self,  Next: acc_map_data,  Prev: acc_update_device,  Up: OpenACC Runtime Library Routines
  
! 6.25 'acc_update_self' - Update host memory from mapped device memory.
  ======================================================================
  
  _Description_
--- 3154,3160 ----
  
  File: libgomp.info,  Node: acc_update_self,  Next: acc_map_data,  Prev: acc_update_device,  Up: OpenACC Runtime Library Routines
  
! 6.25 ‘acc_update_self’ - Update host memory from mapped device memory.
  ======================================================================
  
  _Description_
*************** _Description_
*** 3167,3189 ****
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   'acc_update_self(h_void *a, size_t len);'
!      _Prototype_:   'acc_update_self_async(h_void *a, size_t len, int
!                     async);'
  
  _Fortran_:
!      _Interface_:   'subroutine acc_update_self(a)'
!                     'type, dimension(:[,:]...) :: a'
!      _Interface_:   'subroutine acc_update_self(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!      _Interface_:   'subroutine acc_update_self_async(a, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer(acc_handle_kind) :: async'
!      _Interface_:   'subroutine acc_update_self_async(a, len, async)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!                     'integer(acc_handle_kind) :: async'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3167,3189 ----
       a variable or array element and LEN specifies the length in bytes.
  
  _C/C++_:
!      _Prototype_:   ‘acc_update_self(h_void *a, size_t len);’
!      _Prototype_:   ‘acc_update_self_async(h_void *a, size_t len, int
!                     async);’
  
  _Fortran_:
!      _Interface_:   ‘subroutine acc_update_self(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!      _Interface_:   ‘subroutine acc_update_self(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!      _Interface_:   ‘subroutine acc_update_self_async(a, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer(acc_handle_kind) :: async’
!      _Interface_:   ‘subroutine acc_update_self_async(a, len, async)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!                     ‘integer(acc_handle_kind) :: async’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3192,3198 ****
  
  File: libgomp.info,  Node: acc_map_data,  Next: acc_unmap_data,  Prev: acc_update_self,  Up: OpenACC Runtime Library Routines
  
! 6.26 'acc_map_data' - Map previously allocated device memory to host memory.
  ============================================================================
  
  _Description_
--- 3192,3198 ----
  
  File: libgomp.info,  Node: acc_map_data,  Next: acc_unmap_data,  Prev: acc_update_self,  Up: OpenACC Runtime Library Routines
  
! 6.26 ‘acc_map_data’ - Map previously allocated device memory to host memory.
  ============================================================================
  
  _Description_
*************** _Description_
*** 3201,3207 ****
       memory is specified with the host address H and a length of LEN.
  
  _C/C++_:
!      _Prototype_:   'acc_map_data(h_void *h, d_void *d, size_t len);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3201,3207 ----
       memory is specified with the host address H and a length of LEN.
  
  _C/C++_:
!      _Prototype_:   ‘acc_map_data(h_void *h, d_void *d, size_t len);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3210,3216 ****
  
  File: libgomp.info,  Node: acc_unmap_data,  Next: acc_deviceptr,  Prev: acc_map_data,  Up: OpenACC Runtime Library Routines
  
! 6.27 'acc_unmap_data' - Unmap device memory from host memory.
  =============================================================
  
  _Description_
--- 3210,3216 ----
  
  File: libgomp.info,  Node: acc_unmap_data,  Next: acc_deviceptr,  Prev: acc_map_data,  Up: OpenACC Runtime Library Routines
  
! 6.27 ‘acc_unmap_data’ - Unmap device memory from host memory.
  =============================================================
  
  _Description_
*************** _Description_
*** 3218,3224 ****
       latter specified by H.
  
  _C/C++_:
!      _Prototype_:   'acc_unmap_data(h_void *h);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3218,3224 ----
       latter specified by H.
  
  _C/C++_:
!      _Prototype_:   ‘acc_unmap_data(h_void *h);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3227,3233 ****
  
  File: libgomp.info,  Node: acc_deviceptr,  Next: acc_hostptr,  Prev: acc_unmap_data,  Up: OpenACC Runtime Library Routines
  
! 6.28 'acc_deviceptr' - Get device pointer associated with specific host address.
  ================================================================================
  
  _Description_
--- 3227,3233 ----
  
  File: libgomp.info,  Node: acc_deviceptr,  Next: acc_hostptr,  Prev: acc_unmap_data,  Up: OpenACC Runtime Library Routines
  
! 6.28 ‘acc_deviceptr’ - Get device pointer associated with specific host address.
  ================================================================================
  
  _Description_
*************** _Description_
*** 3235,3241 ****
       the host address specified by H.
  
  _C/C++_:
!      _Prototype_:   'void *acc_deviceptr(h_void *h);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3235,3241 ----
       the host address specified by H.
  
  _C/C++_:
!      _Prototype_:   ‘void *acc_deviceptr(h_void *h);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3244,3250 ****
  
  File: libgomp.info,  Node: acc_hostptr,  Next: acc_is_present,  Prev: acc_deviceptr,  Up: OpenACC Runtime Library Routines
  
! 6.29 'acc_hostptr' - Get host pointer associated with specific device address.
  ==============================================================================
  
  _Description_
--- 3244,3250 ----
  
  File: libgomp.info,  Node: acc_hostptr,  Next: acc_is_present,  Prev: acc_deviceptr,  Up: OpenACC Runtime Library Routines
  
! 6.29 ‘acc_hostptr’ - Get host pointer associated with specific device address.
  ==============================================================================
  
  _Description_
*************** _Description_
*** 3252,3258 ****
       device address specified by D.
  
  _C/C++_:
!      _Prototype_:   'void *acc_hostptr(d_void *d);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3252,3258 ----
       device address specified by D.
  
  _C/C++_:
!      _Prototype_:   ‘void *acc_hostptr(d_void *d);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3261,3267 ****
  
  File: libgomp.info,  Node: acc_is_present,  Next: acc_memcpy_to_device,  Prev: acc_hostptr,  Up: OpenACC Runtime Library Routines
  
! 6.30 'acc_is_present' - Indicate whether host variable / array is present on device.
  ====================================================================================
  
  _Description_
--- 3261,3267 ----
  
  File: libgomp.info,  Node: acc_is_present,  Next: acc_memcpy_to_device,  Prev: acc_hostptr,  Up: OpenACC Runtime Library Routines
  
! 6.30 ‘acc_is_present’ - Indicate whether host variable / array is present on device.
  ====================================================================================
  
  _Description_
*************** _Description_
*** 3274,3294 ****
       In Fortran, two (2) forms are supported.  In the first form, A
       specifies a contiguous array section.  The second form A specifies
       a variable or array element and LEN specifies the length in bytes.
!      If the host memory is mapped to device memory, then a 'true' is
!      returned.  Otherwise, a 'false' is return to indicate the mapped
       memory is not present.
  
  _C/C++_:
!      _Prototype_:   'int acc_is_present(h_void *a, size_t len);'
  
  _Fortran_:
!      _Interface_:   'function acc_is_present(a)'
!                     'type, dimension(:[,:]...) :: a'
!                     'logical acc_is_present'
!      _Interface_:   'function acc_is_present(a, len)'
!                     'type, dimension(:[,:]...) :: a'
!                     'integer len'
!                     'logical acc_is_present'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3274,3294 ----
       In Fortran, two (2) forms are supported.  In the first form, A
       specifies a contiguous array section.  The second form A specifies
       a variable or array element and LEN specifies the length in bytes.
!      If the host memory is mapped to device memory, then a ‘true’ is
!      returned.  Otherwise, a ‘false’ is return to indicate the mapped
       memory is not present.
  
  _C/C++_:
!      _Prototype_:   ‘int acc_is_present(h_void *a, size_t len);’
  
  _Fortran_:
!      _Interface_:   ‘function acc_is_present(a)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘logical acc_is_present’
!      _Interface_:   ‘function acc_is_present(a, len)’
!                     ‘type, dimension(:[,:]...) :: a’
!                     ‘integer len’
!                     ‘logical acc_is_present’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3297,3303 ****
  
  File: libgomp.info,  Node: acc_memcpy_to_device,  Next: acc_memcpy_from_device,  Prev: acc_is_present,  Up: OpenACC Runtime Library Routines
  
! 6.31 'acc_memcpy_to_device' - Copy host memory to device memory.
  ================================================================
  
  _Description_
--- 3297,3303 ----
  
  File: libgomp.info,  Node: acc_memcpy_to_device,  Next: acc_memcpy_from_device,  Prev: acc_is_present,  Up: OpenACC Runtime Library Routines
  
! 6.31 ‘acc_memcpy_to_device’ - Copy host memory to device memory.
  ================================================================
  
  _Description_
*************** _Description_
*** 3306,3313 ****
       of BYTES bytes.
  
  _C/C++_:
!      _Prototype_:   'acc_memcpy_to_device(d_void *dest, h_void *src, size_t
!                     bytes);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3306,3313 ----
       of BYTES bytes.
  
  _C/C++_:
!      _Prototype_:   ‘acc_memcpy_to_device(d_void *dest, h_void *src, size_t
!                     bytes);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3316,3322 ****
  
  File: libgomp.info,  Node: acc_memcpy_from_device,  Next: acc_attach,  Prev: acc_memcpy_to_device,  Up: OpenACC Runtime Library Routines
  
! 6.32 'acc_memcpy_from_device' - Copy device memory to host memory.
  ==================================================================
  
  _Description_
--- 3316,3322 ----
  
  File: libgomp.info,  Node: acc_memcpy_from_device,  Next: acc_attach,  Prev: acc_memcpy_to_device,  Up: OpenACC Runtime Library Routines
  
! 6.32 ‘acc_memcpy_from_device’ - Copy device memory to host memory.
  ==================================================================
  
  _Description_
*************** _Description_
*** 3325,3332 ****
       length of BYTES bytes.
  
  _C/C++_:
!      _Prototype_:   'acc_memcpy_from_device(d_void *dest, h_void *src,
!                     size_t bytes);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3325,3332 ----
       length of BYTES bytes.
  
  _C/C++_:
!      _Prototype_:   ‘acc_memcpy_from_device(d_void *dest, h_void *src,
!                     size_t bytes);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3335,3341 ****
  
  File: libgomp.info,  Node: acc_attach,  Next: acc_detach,  Prev: acc_memcpy_from_device,  Up: OpenACC Runtime Library Routines
  
! 6.33 'acc_attach' - Let device pointer point to device-pointer target.
  ======================================================================
  
  _Description_
--- 3335,3341 ----
  
  File: libgomp.info,  Node: acc_attach,  Next: acc_detach,  Prev: acc_memcpy_from_device,  Up: OpenACC Runtime Library Routines
  
! 6.33 ‘acc_attach’ - Let device pointer point to device-pointer target.
  ======================================================================
  
  _Description_
*************** _Description_
*** 3343,3350 ****
       host-pointer address to pointing to the corresponding device data.
  
  _C/C++_:
!      _Prototype_:   'acc_attach(h_void **ptr);'
!      _Prototype_:   'acc_attach_async(h_void **ptr, int async);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3343,3350 ----
       host-pointer address to pointing to the corresponding device data.
  
  _C/C++_:
!      _Prototype_:   ‘acc_attach(h_void **ptr);’
!      _Prototype_:   ‘acc_attach_async(h_void **ptr, int async);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3353,3359 ****
  
  File: libgomp.info,  Node: acc_detach,  Next: acc_get_current_cuda_device,  Prev: acc_attach,  Up: OpenACC Runtime Library Routines
  
! 6.34 'acc_detach' - Let device pointer point to host-pointer target.
  ====================================================================
  
  _Description_
--- 3353,3359 ----
  
  File: libgomp.info,  Node: acc_detach,  Next: acc_get_current_cuda_device,  Prev: acc_attach,  Up: OpenACC Runtime Library Routines
  
! 6.34 ‘acc_detach’ - Let device pointer point to host-pointer target.
  ====================================================================
  
  _Description_
*************** _Description_
*** 3361,3370 ****
       device-pointer address to pointing to the corresponding host data.
  
  _C/C++_:
!      _Prototype_:   'acc_detach(h_void **ptr);'
!      _Prototype_:   'acc_detach_async(h_void **ptr, int async);'
!      _Prototype_:   'acc_detach_finalize(h_void **ptr);'
!      _Prototype_:   'acc_detach_finalize_async(h_void **ptr, int async);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3361,3370 ----
       device-pointer address to pointing to the corresponding host data.
  
  _C/C++_:
!      _Prototype_:   ‘acc_detach(h_void **ptr);’
!      _Prototype_:   ‘acc_detach_async(h_void **ptr, int async);’
!      _Prototype_:   ‘acc_detach_finalize(h_void **ptr);’
!      _Prototype_:   ‘acc_detach_finalize_async(h_void **ptr, int async);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3373,3379 ****
  
  File: libgomp.info,  Node: acc_get_current_cuda_device,  Next: acc_get_current_cuda_context,  Prev: acc_detach,  Up: OpenACC Runtime Library Routines
  
! 6.35 'acc_get_current_cuda_device' - Get CUDA device handle.
  ============================================================
  
  _Description_
--- 3373,3379 ----
  
  File: libgomp.info,  Node: acc_get_current_cuda_device,  Next: acc_get_current_cuda_context,  Prev: acc_detach,  Up: OpenACC Runtime Library Routines
  
! 6.35 ‘acc_get_current_cuda_device’ - Get CUDA device handle.
  ============================================================
  
  _Description_
*************** _Description_
*** 3381,3387 ****
       same as used by the CUDA Runtime or Driver API's.
  
  _C/C++_:
!      _Prototype_:   'void *acc_get_current_cuda_device(void);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3381,3387 ----
       same as used by the CUDA Runtime or Driver API's.
  
  _C/C++_:
!      _Prototype_:   ‘void *acc_get_current_cuda_device(void);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3390,3396 ****
  
  File: libgomp.info,  Node: acc_get_current_cuda_context,  Next: acc_get_cuda_stream,  Prev: acc_get_current_cuda_device,  Up: OpenACC Runtime Library Routines
  
! 6.36 'acc_get_current_cuda_context' - Get CUDA context handle.
  ==============================================================
  
  _Description_
--- 3390,3396 ----
  
  File: libgomp.info,  Node: acc_get_current_cuda_context,  Next: acc_get_cuda_stream,  Prev: acc_get_current_cuda_device,  Up: OpenACC Runtime Library Routines
  
! 6.36 ‘acc_get_current_cuda_context’ - Get CUDA context handle.
  ==============================================================
  
  _Description_
*************** _Description_
*** 3398,3404 ****
       same as used by the CUDA Runtime or Driver API's.
  
  _C/C++_:
!      _Prototype_:   'void *acc_get_current_cuda_context(void);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3398,3404 ----
       same as used by the CUDA Runtime or Driver API's.
  
  _C/C++_:
!      _Prototype_:   ‘void *acc_get_current_cuda_context(void);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3407,3413 ****
  
  File: libgomp.info,  Node: acc_get_cuda_stream,  Next: acc_set_cuda_stream,  Prev: acc_get_current_cuda_context,  Up: OpenACC Runtime Library Routines
  
! 6.37 'acc_get_cuda_stream' - Get CUDA stream handle.
  ====================================================
  
  _Description_
--- 3407,3413 ----
  
  File: libgomp.info,  Node: acc_get_cuda_stream,  Next: acc_set_cuda_stream,  Prev: acc_get_current_cuda_context,  Up: OpenACC Runtime Library Routines
  
! 6.37 ‘acc_get_cuda_stream’ - Get CUDA stream handle.
  ====================================================
  
  _Description_
*************** _Description_
*** 3416,3422 ****
       API's.
  
  _C/C++_:
!      _Prototype_:   'void *acc_get_cuda_stream(int async);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3416,3422 ----
       API's.
  
  _C/C++_:
!      _Prototype_:   ‘void *acc_get_cuda_stream(int async);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3425,3431 ****
  
  File: libgomp.info,  Node: acc_set_cuda_stream,  Next: acc_prof_register,  Prev: acc_get_cuda_stream,  Up: OpenACC Runtime Library Routines
  
! 6.38 'acc_set_cuda_stream' - Set CUDA stream handle.
  ====================================================
  
  _Description_
--- 3425,3431 ----
  
  File: libgomp.info,  Node: acc_set_cuda_stream,  Next: acc_prof_register,  Prev: acc_get_cuda_stream,  Up: OpenACC Runtime Library Routines
  
! 6.38 ‘acc_set_cuda_stream’ - Set CUDA stream handle.
  ====================================================
  
  _Description_
*************** _Description_
*** 3433,3444 ****
       the queue ASYNC.
  
       This cannot be used to change the stream handle associated with
!      'acc_async_sync'.
  
       The return value is not specified.
  
  _C/C++_:
!      _Prototype_:   'int acc_set_cuda_stream(int async, void *stream);'
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
--- 3433,3444 ----
       the queue ASYNC.
  
       This cannot be used to change the stream handle associated with
!      ‘acc_async_sync’.
  
       The return value is not specified.
  
  _C/C++_:
!      _Prototype_:   ‘int acc_set_cuda_stream(int async, void *stream);’
  
  _Reference_:
       OpenACC specification v2.6 (https://www.openacc.org), section
*************** _Reference_:
*** 3447,3461 ****
  
  File: libgomp.info,  Node: acc_prof_register,  Next: acc_prof_unregister,  Prev: acc_set_cuda_stream,  Up: OpenACC Runtime Library Routines
  
! 6.39 'acc_prof_register' - Register callbacks.
  ==============================================
  
  _Description_:
       This function registers callbacks.
  
  _C/C++_:
!      _Prototype_:   'void acc_prof_register (acc_event_t, acc_prof_callback,
!                     acc_register_t);'
  
  _See also_:
       *note OpenACC Profiling Interface::
--- 3447,3461 ----
  
  File: libgomp.info,  Node: acc_prof_register,  Next: acc_prof_unregister,  Prev: acc_set_cuda_stream,  Up: OpenACC Runtime Library Routines
  
! 6.39 ‘acc_prof_register’ - Register callbacks.
  ==============================================
  
  _Description_:
       This function registers callbacks.
  
  _C/C++_:
!      _Prototype_:   ‘void acc_prof_register (acc_event_t, acc_prof_callback,
!                     acc_register_t);’
  
  _See also_:
       *note OpenACC Profiling Interface::
*************** _Reference_:
*** 3466,3480 ****
  
  File: libgomp.info,  Node: acc_prof_unregister,  Next: acc_prof_lookup,  Prev: acc_prof_register,  Up: OpenACC Runtime Library Routines
  
! 6.40 'acc_prof_unregister' - Unregister callbacks.
  ==================================================
  
  _Description_:
       This function unregisters callbacks.
  
  _C/C++_:
!      _Prototype_:   'void acc_prof_unregister (acc_event_t,
!                     acc_prof_callback, acc_register_t);'
  
  _See also_:
       *note OpenACC Profiling Interface::
--- 3466,3480 ----
  
  File: libgomp.info,  Node: acc_prof_unregister,  Next: acc_prof_lookup,  Prev: acc_prof_register,  Up: OpenACC Runtime Library Routines
  
! 6.40 ‘acc_prof_unregister’ - Unregister callbacks.
  ==================================================
  
  _Description_:
       This function unregisters callbacks.
  
  _C/C++_:
!      _Prototype_:   ‘void acc_prof_unregister (acc_event_t,
!                     acc_prof_callback, acc_register_t);’
  
  _See also_:
       *note OpenACC Profiling Interface::
*************** _Reference_:
*** 3485,3498 ****
  
  File: libgomp.info,  Node: acc_prof_lookup,  Next: acc_register_library,  Prev: acc_prof_unregister,  Up: OpenACC Runtime Library Routines
  
! 6.41 'acc_prof_lookup' - Obtain inquiry functions.
  ==================================================
  
  _Description_:
       Function to obtain inquiry functions.
  
  _C/C++_:
!      _Prototype_:   'acc_query_fn acc_prof_lookup (const char *);'
  
  _See also_:
       *note OpenACC Profiling Interface::
--- 3485,3498 ----
  
  File: libgomp.info,  Node: acc_prof_lookup,  Next: acc_register_library,  Prev: acc_prof_unregister,  Up: OpenACC Runtime Library Routines
  
! 6.41 ‘acc_prof_lookup’ - Obtain inquiry functions.
  ==================================================
  
  _Description_:
       Function to obtain inquiry functions.
  
  _C/C++_:
!      _Prototype_:   ‘acc_query_fn acc_prof_lookup (const char *);’
  
  _See also_:
       *note OpenACC Profiling Interface::
*************** _Reference_:
*** 3503,3517 ****
  
  File: libgomp.info,  Node: acc_register_library,  Prev: acc_prof_lookup,  Up: OpenACC Runtime Library Routines
  
! 6.42 'acc_register_library' - Library registration.
  ===================================================
  
  _Description_:
       Function for library registration.
  
  _C/C++_:
!      _Prototype_:   'void acc_register_library (acc_prof_reg, acc_prof_reg,
!                     acc_prof_lookup_func);'
  
  _See also_:
       *note OpenACC Profiling Interface::, *note ACC_PROFLIB::
--- 3503,3517 ----
  
  File: libgomp.info,  Node: acc_register_library,  Prev: acc_prof_lookup,  Up: OpenACC Runtime Library Routines
  
! 6.42 ‘acc_register_library’ - Library registration.
  ===================================================
  
  _Description_:
       Function for library registration.
  
  _C/C++_:
!      _Prototype_:   ‘void acc_register_library (acc_prof_reg, acc_prof_reg,
!                     acc_prof_lookup_func);’
  
  _See also_:
       *note OpenACC Profiling Interface::, *note ACC_PROFLIB::
*************** File: libgomp.info,  Node: OpenACC Envir
*** 3525,3534 ****
  7 OpenACC Environment Variables
  *******************************
  
! The variables 'ACC_DEVICE_TYPE' and 'ACC_DEVICE_NUM' are defined by
  section 4 of the OpenACC specification in version 2.0.  The variable
! 'ACC_PROFLIB' is defined by section 4 of the OpenACC specification in
! version 2.6.  The variable 'GCC_ACC_NOTIFY' is used for diagnostic
  purposes.
  
  * Menu:
--- 3525,3534 ----
  7 OpenACC Environment Variables
  *******************************
  
! The variables ‘ACC_DEVICE_TYPE’ and ‘ACC_DEVICE_NUM’ are defined by
  section 4 of the OpenACC specification in version 2.0.  The variable
! ‘ACC_PROFLIB’ is defined by section 4 of the OpenACC specification in
! version 2.6.  The variable ‘GCC_ACC_NOTIFY’ is used for diagnostic
  purposes.
  
  * Menu:
*************** purposes.
*** 3541,3547 ****
  
  File: libgomp.info,  Node: ACC_DEVICE_TYPE,  Next: ACC_DEVICE_NUM,  Up: OpenACC Environment Variables
  
! 7.1 'ACC_DEVICE_TYPE'
  =====================
  
  _Reference_:
--- 3541,3547 ----
  
  File: libgomp.info,  Node: ACC_DEVICE_TYPE,  Next: ACC_DEVICE_NUM,  Up: OpenACC Environment Variables
  
! 7.1 ‘ACC_DEVICE_TYPE’
  =====================
  
  _Reference_:
*************** _Reference_:
*** 3550,3556 ****
  
  File: libgomp.info,  Node: ACC_DEVICE_NUM,  Next: ACC_PROFLIB,  Prev: ACC_DEVICE_TYPE,  Up: OpenACC Environment Variables
  
! 7.2 'ACC_DEVICE_NUM'
  ====================
  
  _Reference_:
--- 3550,3556 ----
  
  File: libgomp.info,  Node: ACC_DEVICE_NUM,  Next: ACC_PROFLIB,  Prev: ACC_DEVICE_TYPE,  Up: OpenACC Environment Variables
  
! 7.2 ‘ACC_DEVICE_NUM’
  ====================
  
  _Reference_:
*************** _Reference_:
*** 3559,3565 ****
  
  File: libgomp.info,  Node: ACC_PROFLIB,  Next: GCC_ACC_NOTIFY,  Prev: ACC_DEVICE_NUM,  Up: OpenACC Environment Variables
  
! 7.3 'ACC_PROFLIB'
  =================
  
  _See also_:
--- 3559,3565 ----
  
  File: libgomp.info,  Node: ACC_PROFLIB,  Next: GCC_ACC_NOTIFY,  Prev: ACC_DEVICE_NUM,  Up: OpenACC Environment Variables
  
! 7.3 ‘ACC_PROFLIB’
  =================
  
  _See also_:
*************** _Reference_:
*** 3571,3577 ****
  
  File: libgomp.info,  Node: GCC_ACC_NOTIFY,  Prev: ACC_PROFLIB,  Up: OpenACC Environment Variables
  
! 7.4 'GCC_ACC_NOTIFY'
  ====================
  
  _Description_:
--- 3571,3577 ----
  
  File: libgomp.info,  Node: GCC_ACC_NOTIFY,  Prev: ACC_PROFLIB,  Up: OpenACC Environment Variables
  
! 7.4 ‘GCC_ACC_NOTIFY’
  ====================
  
  _Description_:
*************** File: libgomp.info,  Node: CUDA Streams
*** 3583,3589 ****
  8 CUDA Streams Usage
  ********************
  
! This applies to the 'nvptx' plugin only.
  
     The library provides elements that perform asynchronous movement of
  data and asynchronous operation of computing constructs.  This
--- 3583,3589 ----
  8 CUDA Streams Usage
  ********************
  
! This applies to the ‘nvptx’ plugin only.
  
     The library provides elements that perform asynchronous movement of
  data and asynchronous operation of computing constructs.  This
*************** streams(1).
*** 3592,3618 ****
  
     The primary means by that the asynchronous functionality is accessed
  is through the use of those OpenACC directives which make use of the
! 'async' and 'wait' clauses.  When the 'async' clause is first used with
! a directive, it creates a CUDA stream.  If an 'async-argument' is used
! with the 'async' clause, then the stream is associated with the
! specified 'async-argument'.
  
     Following the creation of an association between a CUDA stream and
! the 'async-argument' of an 'async' clause, both the 'wait' clause and
! the 'wait' directive can be used.  When either the clause or directive
  is used after stream creation, it creates a rendezvous point whereby
  execution waits until all operations associated with the
! 'async-argument', that is, stream, have completed.
  
     Normally, the management of the streams that are created as a result
! of using the 'async' clause, is done without any intervention by the
! caller.  This implies the association between the 'async-argument' and
  the CUDA stream will be maintained for the lifetime of the program.
  However, this association can be changed through the use of the library
! function 'acc_set_cuda_stream'.  When the function 'acc_set_cuda_stream'
  is called, the CUDA stream that was originally associated with the
! 'async' clause will be destroyed.  Caution should be taken when changing
! the association as subsequent references to the 'async-argument' refer
  to a different CUDA stream.
  
     ---------- Footnotes ----------
--- 3592,3618 ----
  
     The primary means by that the asynchronous functionality is accessed
  is through the use of those OpenACC directives which make use of the
! ‘async’ and ‘wait’ clauses.  When the ‘async’ clause is first used with
! a directive, it creates a CUDA stream.  If an ‘async-argument’ is used
! with the ‘async’ clause, then the stream is associated with the
! specified ‘async-argument’.
  
     Following the creation of an association between a CUDA stream and
! the ‘async-argument’ of an ‘async’ clause, both the ‘wait’ clause and
! the ‘wait’ directive can be used.  When either the clause or directive
  is used after stream creation, it creates a rendezvous point whereby
  execution waits until all operations associated with the
! ‘async-argument’, that is, stream, have completed.
  
     Normally, the management of the streams that are created as a result
! of using the ‘async’ clause, is done without any intervention by the
! caller.  This implies the association between the ‘async-argument’ and
  the CUDA stream will be maintained for the lifetime of the program.
  However, this association can be changed through the use of the library
! function ‘acc_set_cuda_stream’.  When the function ‘acc_set_cuda_stream’
  is called, the CUDA stream that was originally associated with the
! ‘async’ clause will be destroyed.  Caution should be taken when changing
! the association as subsequent references to the ‘async-argument’ refer
  to a different CUDA stream.
  
     ---------- Footnotes ----------
*************** library and the CUBLAS and Runtime libra
*** 3640,3646 ****
  
  In this first use case (see below), a function in the CUBLAS library is
  called prior to any of the functions in the OpenACC library.  More
! specifically, the function 'cublasCreate()'.
  
     When invoked, the function initializes the library and allocates the
  hardware resources on the host and the device on behalf of the caller.
--- 3640,3646 ----
  
  In this first use case (see below), a function in the CUBLAS library is
  called prior to any of the functions in the OpenACC library.  More
! specifically, the function ‘cublasCreate()’.
  
     When invoked, the function initializes the library and allocates the
  hardware resources on the host and the device on behalf of the caller.
*************** hardware resources on the host.
*** 3653,3667 ****
  
     Prior to calling the OpenACC function that initializes the library
  and allocate the host hardware resources, you need to acquire the device
! number that was allocated during the call to 'cublasCreate()'.  The
! invoking of the runtime library function 'cudaGetDevice()' accomplishes
  this.  Once acquired, the device number is passed along with the device
  type as parameters to the OpenACC library function
! 'acc_set_device_num()'.
  
!    Once the call to 'acc_set_device_num()' has completed, the OpenACC
  library uses the context that was created during the call to
! 'cublasCreate()'.  In other words, both libraries will be sharing the
  same context.
  
           /* Create the handle */
--- 3653,3667 ----
  
     Prior to calling the OpenACC function that initializes the library
  and allocate the host hardware resources, you need to acquire the device
! number that was allocated during the call to ‘cublasCreate()’.  The
! invoking of the runtime library function ‘cudaGetDevice()’ accomplishes
  this.  Once acquired, the device number is passed along with the device
  type as parameters to the OpenACC library function
! ‘acc_set_device_num()’.
  
!    Once the call to ‘acc_set_device_num()’ has completed, the OpenACC
  library uses the context that was created during the call to
! ‘cublasCreate()’.  In other words, both libraries will be sharing the
  same context.
  
           /* Create the handle */
*************** same context.
*** 3690,3714 ****
  
  In this second use case (see below), a function in the OpenACC library
  is called prior to any of the functions in the CUBLAS library.  More
! specifically, the function 'acc_set_device_num()'.
  
!    In the use case presented here, the function 'acc_set_device_num()'
  is used to both initialize the OpenACC library and allocate the hardware
  resources on the host and the device.  In the call to the function, the
  call parameters specify which device to use and what device type to use,
! i.e., 'acc_device_nvidia'.  It should be noted that this is but one
  method to initialize the OpenACC library and allocate the appropriate
  hardware resources.  Other methods are available through the use of
  environment variables and these will be discussed in the next section.
  
!    Once the call to 'acc_set_device_num()' has completed, other OpenACC
  functions can be called as seen with multiple calls being made to
! 'acc_copyin()'.  In addition, calls can be made to functions in the
! CUBLAS library.  In the use case a call to 'cublasCreate()' is made
! subsequent to the calls to 'acc_copyin()'.  As seen in the previous use
! case, a call to 'cublasCreate()' initializes the CUBLAS library and
  allocates the hardware resources on the host and the device.  However,
! since the device has already been allocated, 'cublasCreate()' will only
  initialize the CUBLAS library and allocate the appropriate hardware
  resources on the host.  The context that was created as part of the
  OpenACC initialization is shared with the CUBLAS library, similarly to
--- 3690,3714 ----
  
  In this second use case (see below), a function in the OpenACC library
  is called prior to any of the functions in the CUBLAS library.  More
! specifically, the function ‘acc_set_device_num()’.
  
!    In the use case presented here, the function ‘acc_set_device_num()’
  is used to both initialize the OpenACC library and allocate the hardware
  resources on the host and the device.  In the call to the function, the
  call parameters specify which device to use and what device type to use,
! i.e., ‘acc_device_nvidia’.  It should be noted that this is but one
  method to initialize the OpenACC library and allocate the appropriate
  hardware resources.  Other methods are available through the use of
  environment variables and these will be discussed in the next section.
  
!    Once the call to ‘acc_set_device_num()’ has completed, other OpenACC
  functions can be called as seen with multiple calls being made to
! ‘acc_copyin()’.  In addition, calls can be made to functions in the
! CUBLAS library.  In the use case a call to ‘cublasCreate()’ is made
! subsequent to the calls to ‘acc_copyin()’.  As seen in the previous use
! case, a call to ‘cublasCreate()’ initializes the CUBLAS library and
  allocates the hardware resources on the host and the device.  However,
! since the device has already been allocated, ‘cublasCreate()’ will only
  initialize the CUBLAS library and allocate the appropriate hardware
  resources on the host.  The context that was created as part of the
  OpenACC initialization is shared with the CUBLAS library, similarly to
*************** the first use case.
*** 3760,3776 ****
  
  There are two environment variables associated with the OpenACC library
  that may be used to control the device type and device number:
! 'ACC_DEVICE_TYPE' and 'ACC_DEVICE_NUM', respectively.  These two
  environment variables can be used as an alternative to calling
! 'acc_set_device_num()'.  As seen in the second use case, the device type
! and device number were specified using 'acc_set_device_num()'.  If
  however, the aforementioned environment variables were set, then the
! call to 'acc_set_device_num()' would not be required.
  
     The use of the environment variables is only relevant when an OpenACC
! function is called prior to a call to 'cudaCreate()'.  If 'cudaCreate()'
  is called prior to a call to an OpenACC function, then you must call
! 'acc_set_device_num()'(2)
  
     ---------- Footnotes ----------
  
--- 3760,3776 ----
  
  There are two environment variables associated with the OpenACC library
  that may be used to control the device type and device number:
! ‘ACC_DEVICE_TYPE’ and ‘ACC_DEVICE_NUM’, respectively.  These two
  environment variables can be used as an alternative to calling
! ‘acc_set_device_num()’.  As seen in the second use case, the device type
! and device number were specified using ‘acc_set_device_num()’.  If
  however, the aforementioned environment variables were set, then the
! call to ‘acc_set_device_num()’ would not be required.
  
     The use of the environment variables is only relevant when an OpenACC
! function is called prior to a call to ‘cudaCreate()’.  If ‘cudaCreate()’
  is called prior to a call to an OpenACC function, then you must call
! ‘acc_set_device_num()’(2)
  
     ---------- Footnotes ----------
  
*************** is called prior to a call to an OpenACC
*** 3779,3786 ****
  Interoperability", in "CUDA Driver API", TRM-06703-001, Version 5.5, for
  additional information on library interoperability.
  
!    (2) More complete information about 'ACC_DEVICE_TYPE' and
! 'ACC_DEVICE_NUM' can be found in sections 4.1 and 4.2 of the OpenACC
  (https://www.openacc.org) Application Programming Interface”, Version
  2.6.
  
--- 3779,3786 ----
  Interoperability", in "CUDA Driver API", TRM-06703-001, Version 5.5, for
  additional information on library interoperability.
  
!    (2) More complete information about ‘ACC_DEVICE_TYPE’ and
! ‘ACC_DEVICE_NUM’ can be found in sections 4.1 and 4.2 of the OpenACC
  (https://www.openacc.org) Application Programming Interface”, Version
  2.6.
  
*************** has gotten enabled: for example, because
*** 3808,4040 ****
  calling into a third-party _library_ for every event that has been
  registered.
  
!    We're not yet accounting for the fact that 'OpenACC events may occur
! during event processing'.  We just handle one case specially, as
! required by CUDA 9.0 'nvprof', that 'acc_get_device_type' (*note
! acc_get_device_type::)) may be called from 'acc_ev_device_init_start',
! 'acc_ev_device_init_end' callbacks.
  
     We're not yet implementing initialization via a
! 'acc_register_library' function that is either statically linked in, or
! dynamically via 'LD_PRELOAD'.  Initialization via 'acc_register_library'
! functions dynamically loaded via the 'ACC_PROFLIB' environment variable
! does work, as does directly calling 'acc_prof_register',
! 'acc_prof_unregister', 'acc_prof_lookup'.
  
     As currently there are no inquiry functions defined, calls to
! 'acc_prof_lookup' will always return 'NULL'.
  
     There aren't separate _start_, _stop_ events defined for the event
! types 'acc_ev_create', 'acc_ev_delete', 'acc_ev_alloc', 'acc_ev_free'.
  It's not clear if these should be triggered before or after the actual
  device-specific call is made.  We trigger them after.
  
     Remarks about data provided to callbacks:
  
! 'acc_prof_info.event_type'
       It's not clear if for _nested_ event callbacks (for example,
!      'acc_ev_enqueue_launch_start' as part of a parent compute
       construct), this should be set for the nested event
!      ('acc_ev_enqueue_launch_start'), or if the value of the parent
!      construct should remain ('acc_ev_compute_construct_start').  In
       this implementation, the value will generally correspond to the
       innermost nested event type.
  
! 'acc_prof_info.device_type'
  
!         * For 'acc_ev_compute_construct_start', and in presence of an
!           'if' clause with _false_ argument, this will still refer to
            the offloading device type.  It's not clear if that's the
            expected behavior.
  
!         * Complementary to the item before, for
!           'acc_ev_compute_construct_end', this is set to
!           'acc_device_host' in presence of an 'if' clause with _false_
            argument.  It's not clear if that's the expected behavior.
  
! 'acc_prof_info.thread_id'
!      Always '-1'; not yet implemented.
  
! 'acc_prof_info.async'
  
!         * Not yet implemented correctly for
!           'acc_ev_compute_construct_start'.
  
!         * In a compute construct, for host-fallback
!           execution/'acc_device_host' it will always be
!           'acc_async_sync'.  It's not clear if that's the expected
            behavior.
  
!         * For 'acc_ev_device_init_start' and 'acc_ev_device_init_end',
!           it will always be 'acc_async_sync'.  It's not clear if that's
            the expected behavior.
  
! 'acc_prof_info.async_queue'
!      There is no 'limited number of asynchronous queues' in libgomp.
!      This will always have the same value as 'acc_prof_info.async'.
  
! 'acc_prof_info.src_file'
!      Always 'NULL'; not yet implemented.
  
! 'acc_prof_info.func_name'
!      Always 'NULL'; not yet implemented.
  
! 'acc_prof_info.line_no'
!      Always '-1'; not yet implemented.
  
! 'acc_prof_info.end_line_no'
!      Always '-1'; not yet implemented.
  
! 'acc_prof_info.func_line_no'
!      Always '-1'; not yet implemented.
  
! 'acc_prof_info.func_end_line_no'
!      Always '-1'; not yet implemented.
  
! 'acc_event_info.event_type', 'acc_event_info.*.event_type'
!      Relating to 'acc_prof_info.event_type' discussed above, in this
       implementation, this will always be the same value as
!      'acc_prof_info.event_type'.
  
! 'acc_event_info.*.parent_construct'
  
!         * Will be 'acc_construct_parallel' for all OpenACC compute
            constructs as well as many OpenACC Runtime API calls; should
            be the one matching the actual construct, or
!           'acc_construct_runtime_api', respectively.
  
!         * Will be 'acc_construct_enter_data' or
!           'acc_construct_exit_data' when processing variable mappings
            specified in OpenACC _declare_ directives; should be
!           'acc_construct_declare'.
  
!         * For implicit 'acc_ev_device_init_start',
!           'acc_ev_device_init_end', and explicit as well as implicit
!           'acc_ev_alloc', 'acc_ev_free', 'acc_ev_enqueue_upload_start',
!           'acc_ev_enqueue_upload_end', 'acc_ev_enqueue_download_start',
!           and 'acc_ev_enqueue_download_end', will be
!           'acc_construct_parallel'; should reflect the real parent
            construct.
  
! 'acc_event_info.*.implicit'
!      For 'acc_ev_alloc', 'acc_ev_free', 'acc_ev_enqueue_upload_start',
!      'acc_ev_enqueue_upload_end', 'acc_ev_enqueue_download_start', and
!      'acc_ev_enqueue_download_end', this currently will be '1' also for
       explicit usage.
  
! 'acc_event_info.data_event.var_name'
!      Always 'NULL'; not yet implemented.
  
! 'acc_event_info.data_event.host_ptr'
!      For 'acc_ev_alloc', and 'acc_ev_free', this is always 'NULL'.
  
! 'typedef union acc_api_info'
!      ... as printed in '5.2.3. Third Argument: API-Specific
!      Information'.  This should obviously be 'typedef _struct_
!      acc_api_info'.
  
! 'acc_api_info.device_api'
       Possibly not yet implemented correctly for
!      'acc_ev_compute_construct_start', 'acc_ev_device_init_start',
!      'acc_ev_device_init_end': will always be 'acc_device_api_none' for
!      these event types.  For 'acc_ev_enter_data_start', it will be
!      'acc_device_api_none' in some cases.
  
! 'acc_api_info.device_type'
!      Always the same as 'acc_prof_info.device_type'.
  
! 'acc_api_info.vendor'
!      Always '-1'; not yet implemented.
  
! 'acc_api_info.device_handle'
!      Always 'NULL'; not yet implemented.
  
! 'acc_api_info.context_handle'
!      Always 'NULL'; not yet implemented.
  
! 'acc_api_info.async_handle'
!      Always 'NULL'; not yet implemented.
  
     Remarks about certain event types:
  
! 'acc_ev_device_init_start', 'acc_ev_device_init_end'
  
!         * When a compute construct triggers implicit
!           'acc_ev_device_init_start' and 'acc_ev_device_init_end'
            events, they currently aren't _nested within_ the
!           corresponding 'acc_ev_compute_construct_start' and
!           'acc_ev_compute_construct_end', but they're currently observed
!           _before_ 'acc_ev_compute_construct_start'.  It's not clear
            what to do: the standard asks us provide a lot of details to
!           the 'acc_ev_compute_construct_start' callback, without
            (implicitly) initializing a device before?
  
!         * Callbacks for these event types will not be invoked for calls
!           to the 'acc_set_device_type' and 'acc_set_device_num'
            functions.  It's not clear if they should be.
  
! 'acc_ev_enter_data_start', 'acc_ev_enter_data_end', 'acc_ev_exit_data_start', 'acc_ev_exit_data_end'
  
!         * Callbacks for these event types will also be invoked for
            OpenACC _host_data_ constructs.  It's not clear if they should
            be.
  
!         * Callbacks for these event types will also be invoked when
            processing variable mappings specified in OpenACC _declare_
            directives.  It's not clear if they should be.
  
     Callbacks for the following event types will be invoked, but dispatch
  and information provided therein has not yet been thoroughly reviewed:
  
!    * 'acc_ev_alloc'
!    * 'acc_ev_free'
!    * 'acc_ev_update_start', 'acc_ev_update_end'
!    * 'acc_ev_enqueue_upload_start', 'acc_ev_enqueue_upload_end'
!    * 'acc_ev_enqueue_download_start', 'acc_ev_enqueue_download_end'
  
     During device initialization, and finalization, respectively,
  callbacks for the following event types will not yet be invoked:
  
!    * 'acc_ev_alloc'
!    * 'acc_ev_free'
  
     Callbacks for the following event types have not yet been
  implemented, so currently won't be invoked:
  
!    * 'acc_ev_device_shutdown_start', 'acc_ev_device_shutdown_end'
!    * 'acc_ev_runtime_shutdown'
!    * 'acc_ev_create', 'acc_ev_delete'
!    * 'acc_ev_wait_start', 'acc_ev_wait_end'
  
     For the following runtime library functions, not all expected
  callbacks will be invoked (mostly concerning implicit device
  initialization):
  
!    * 'acc_get_num_devices'
!    * 'acc_set_device_type'
!    * 'acc_get_device_type'
!    * 'acc_set_device_num'
!    * 'acc_get_device_num'
!    * 'acc_init'
!    * 'acc_shutdown'
  
     Aside from implicit device initialization, for the following runtime
  library functions, no callbacks will be invoked for shared-memory
  offloading devices (it's not clear if they should be):
  
!    * 'acc_malloc'
!    * 'acc_free'
!    * 'acc_copyin', 'acc_present_or_copyin', 'acc_copyin_async'
!    * 'acc_create', 'acc_present_or_create', 'acc_create_async'
!    * 'acc_copyout', 'acc_copyout_async', 'acc_copyout_finalize',
!      'acc_copyout_finalize_async'
!    * 'acc_delete', 'acc_delete_async', 'acc_delete_finalize',
!      'acc_delete_finalize_async'
!    * 'acc_update_device', 'acc_update_device_async'
!    * 'acc_update_self', 'acc_update_self_async'
!    * 'acc_map_data', 'acc_unmap_data'
!    * 'acc_memcpy_to_device', 'acc_memcpy_to_device_async'
!    * 'acc_memcpy_from_device', 'acc_memcpy_from_device_async'
  
  
  File: libgomp.info,  Node: OpenMP-Implementation Specifics,  Next: Offload-Target Specifics,  Prev: OpenACC Profiling Interface,  Up: Top
--- 3808,4040 ----
  calling into a third-party _library_ for every event that has been
  registered.
  
!    We're not yet accounting for the fact that ‘OpenACC events may occur
! during event processing’.  We just handle one case specially, as
! required by CUDA 9.0 ‘nvprof’, that ‘acc_get_device_type’ (*note
! acc_get_device_type::)) may be called from ‘acc_ev_device_init_start’,
! ‘acc_ev_device_init_end’ callbacks.
  
     We're not yet implementing initialization via a
! ‘acc_register_library’ function that is either statically linked in, or
! dynamically via ‘LD_PRELOAD’.  Initialization via ‘acc_register_library’
! functions dynamically loaded via the ‘ACC_PROFLIB’ environment variable
! does work, as does directly calling ‘acc_prof_register’,
! ‘acc_prof_unregister’, ‘acc_prof_lookup’.
  
     As currently there are no inquiry functions defined, calls to
! ‘acc_prof_lookup’ will always return ‘NULL’.
  
     There aren't separate _start_, _stop_ events defined for the event
! types ‘acc_ev_create’, ‘acc_ev_delete’, ‘acc_ev_alloc’, ‘acc_ev_free’.
  It's not clear if these should be triggered before or after the actual
  device-specific call is made.  We trigger them after.
  
     Remarks about data provided to callbacks:
  
! ‘acc_prof_info.event_type’
       It's not clear if for _nested_ event callbacks (for example,
!      ‘acc_ev_enqueue_launch_start’ as part of a parent compute
       construct), this should be set for the nested event
!      (‘acc_ev_enqueue_launch_start’), or if the value of the parent
!      construct should remain (‘acc_ev_compute_construct_start’).  In
       this implementation, the value will generally correspond to the
       innermost nested event type.
  
! ‘acc_prof_info.device_type’
  
!         • For ‘acc_ev_compute_construct_start’, and in presence of an
!           ‘if’ clause with _false_ argument, this will still refer to
            the offloading device type.  It's not clear if that's the
            expected behavior.
  
!         • Complementary to the item before, for
!           ‘acc_ev_compute_construct_end’, this is set to
!           ‘acc_device_host’ in presence of an ‘if’ clause with _false_
            argument.  It's not clear if that's the expected behavior.
  
! ‘acc_prof_info.thread_id’
!      Always ‘-1’; not yet implemented.
  
! ‘acc_prof_info.async’
  
!         • Not yet implemented correctly for
!           ‘acc_ev_compute_construct_start’.
  
!         • In a compute construct, for host-fallback
!           execution/‘acc_device_host’ it will always be
!           ‘acc_async_sync’.  It's not clear if that's the expected
            behavior.
  
!         • For ‘acc_ev_device_init_start’ and ‘acc_ev_device_init_end’,
!           it will always be ‘acc_async_sync’.  It's not clear if that's
            the expected behavior.
  
! ‘acc_prof_info.async_queue’
!      There is no ‘limited number of asynchronous queues’ in libgomp.
!      This will always have the same value as ‘acc_prof_info.async’.
  
! ‘acc_prof_info.src_file’
!      Always ‘NULL’; not yet implemented.
  
! ‘acc_prof_info.func_name’
!      Always ‘NULL’; not yet implemented.
  
! ‘acc_prof_info.line_no’
!      Always ‘-1’; not yet implemented.
  
! ‘acc_prof_info.end_line_no’
!      Always ‘-1’; not yet implemented.
  
! ‘acc_prof_info.func_line_no’
!      Always ‘-1’; not yet implemented.
  
! ‘acc_prof_info.func_end_line_no’
!      Always ‘-1’; not yet implemented.
  
! ‘acc_event_info.event_type’, ‘acc_event_info.*.event_type’
!      Relating to ‘acc_prof_info.event_type’ discussed above, in this
       implementation, this will always be the same value as
!      ‘acc_prof_info.event_type’.
  
! ‘acc_event_info.*.parent_construct’
  
!         • Will be ‘acc_construct_parallel’ for all OpenACC compute
            constructs as well as many OpenACC Runtime API calls; should
            be the one matching the actual construct, or
!           ‘acc_construct_runtime_api’, respectively.
  
!         • Will be ‘acc_construct_enter_data’ or
!           ‘acc_construct_exit_data’ when processing variable mappings
            specified in OpenACC _declare_ directives; should be
!           ‘acc_construct_declare’.
  
!         • For implicit ‘acc_ev_device_init_start’,
!           ‘acc_ev_device_init_end’, and explicit as well as implicit
!           ‘acc_ev_alloc’, ‘acc_ev_free’, ‘acc_ev_enqueue_upload_start’,
!           ‘acc_ev_enqueue_upload_end’, ‘acc_ev_enqueue_download_start’,
!           and ‘acc_ev_enqueue_download_end’, will be
!           ‘acc_construct_parallel’; should reflect the real parent
            construct.
  
! ‘acc_event_info.*.implicit’
!      For ‘acc_ev_alloc’, ‘acc_ev_free’, ‘acc_ev_enqueue_upload_start’,
!      ‘acc_ev_enqueue_upload_end’, ‘acc_ev_enqueue_download_start’, and
!      ‘acc_ev_enqueue_download_end’, this currently will be ‘1’ also for
       explicit usage.
  
! ‘acc_event_info.data_event.var_name’
!      Always ‘NULL’; not yet implemented.
  
! ‘acc_event_info.data_event.host_ptr’
!      For ‘acc_ev_alloc’, and ‘acc_ev_free’, this is always ‘NULL’.
  
! ‘typedef union acc_api_info’
!      ... as printed in ‘5.2.3. Third Argument: API-Specific
!      Information’.  This should obviously be ‘typedef _struct_
!      acc_api_info’.
  
! ‘acc_api_info.device_api’
       Possibly not yet implemented correctly for
!      ‘acc_ev_compute_construct_start’, ‘acc_ev_device_init_start’,
!      ‘acc_ev_device_init_end’: will always be ‘acc_device_api_none’ for
!      these event types.  For ‘acc_ev_enter_data_start’, it will be
!      ‘acc_device_api_none’ in some cases.
  
! ‘acc_api_info.device_type’
!      Always the same as ‘acc_prof_info.device_type’.
  
! ‘acc_api_info.vendor’
!      Always ‘-1’; not yet implemented.
  
! ‘acc_api_info.device_handle’
!      Always ‘NULL’; not yet implemented.
  
! ‘acc_api_info.context_handle’
!      Always ‘NULL’; not yet implemented.
  
! ‘acc_api_info.async_handle’
!      Always ‘NULL’; not yet implemented.
  
     Remarks about certain event types:
  
! ‘acc_ev_device_init_start’, ‘acc_ev_device_init_end’
  
!         • When a compute construct triggers implicit
!           ‘acc_ev_device_init_start’ and ‘acc_ev_device_init_end’
            events, they currently aren't _nested within_ the
!           corresponding ‘acc_ev_compute_construct_start’ and
!           ‘acc_ev_compute_construct_end’, but they're currently observed
!           _before_ ‘acc_ev_compute_construct_start’.  It's not clear
            what to do: the standard asks us provide a lot of details to
!           the ‘acc_ev_compute_construct_start’ callback, without
            (implicitly) initializing a device before?
  
!         • Callbacks for these event types will not be invoked for calls
!           to the ‘acc_set_device_type’ and ‘acc_set_device_num’
            functions.  It's not clear if they should be.
  
! ‘acc_ev_enter_data_start’, ‘acc_ev_enter_data_end’, ‘acc_ev_exit_data_start’, ‘acc_ev_exit_data_end’
  
!         • Callbacks for these event types will also be invoked for
            OpenACC _host_data_ constructs.  It's not clear if they should
            be.
  
!         • Callbacks for these event types will also be invoked when
            processing variable mappings specified in OpenACC _declare_
            directives.  It's not clear if they should be.
  
     Callbacks for the following event types will be invoked, but dispatch
  and information provided therein has not yet been thoroughly reviewed:
  
!    • ‘acc_ev_alloc’
!    • ‘acc_ev_free’
!    • ‘acc_ev_update_start’, ‘acc_ev_update_end’
!    • ‘acc_ev_enqueue_upload_start’, ‘acc_ev_enqueue_upload_end’
!    • ‘acc_ev_enqueue_download_start’, ‘acc_ev_enqueue_download_end’
  
     During device initialization, and finalization, respectively,
  callbacks for the following event types will not yet be invoked:
  
!    • ‘acc_ev_alloc’
!    • ‘acc_ev_free’
  
     Callbacks for the following event types have not yet been
  implemented, so currently won't be invoked:
  
!    • ‘acc_ev_device_shutdown_start’, ‘acc_ev_device_shutdown_end’
!    • ‘acc_ev_runtime_shutdown’
!    • ‘acc_ev_create’, ‘acc_ev_delete’
!    • ‘acc_ev_wait_start’, ‘acc_ev_wait_end’
  
     For the following runtime library functions, not all expected
  callbacks will be invoked (mostly concerning implicit device
  initialization):
  
!    • ‘acc_get_num_devices’
!    • ‘acc_set_device_type’
!    • ‘acc_get_device_type’
!    • ‘acc_set_device_num’
!    • ‘acc_get_device_num’
!    • ‘acc_init’
!    • ‘acc_shutdown’
  
     Aside from implicit device initialization, for the following runtime
  library functions, no callbacks will be invoked for shared-memory
  offloading devices (it's not clear if they should be):
  
!    • ‘acc_malloc’
!    • ‘acc_free’
!    • ‘acc_copyin’, ‘acc_present_or_copyin’, ‘acc_copyin_async’
!    • ‘acc_create’, ‘acc_present_or_create’, ‘acc_create_async’
!    • ‘acc_copyout’, ‘acc_copyout_async’, ‘acc_copyout_finalize’,
!      ‘acc_copyout_finalize_async’
!    • ‘acc_delete’, ‘acc_delete_async’, ‘acc_delete_finalize’,
!      ‘acc_delete_finalize_async’
!    • ‘acc_update_device’, ‘acc_update_device_async’
!    • ‘acc_update_self’, ‘acc_update_self_async’
!    • ‘acc_map_data’, ‘acc_unmap_data’
!    • ‘acc_memcpy_to_device’, ‘acc_memcpy_to_device_async’
!    • ‘acc_memcpy_from_device’, ‘acc_memcpy_from_device_async’
  
  
  File: libgomp.info,  Node: OpenMP-Implementation Specifics,  Next: Offload-Target Specifics,  Prev: OpenACC Profiling Interface,  Up: Top
*************** File: libgomp.info,  Node: OpenMP Contex
*** 4053,4076 ****
  11.1 OpenMP Context Selectors
  =============================
  
! 'vendor' is always 'gnu'.  References are to the GCC manual.
  
! 'arch'                                      'kind'  'isa'
  -----------------------------------------------------------------------
! 'x86', 'x86_64', 'i386', 'i486', 'i586',    'host'  See '-m...'
! 'i686', 'ia32'                                      flags in "x86
                                                      Options"
!                                                     (without '-m')
! 'amdgcn', 'gcn'                             'gpu'   See '-march=' in
                                                      "AMD GCN
                                                      Options"(1)
! 'nvptx'                                     'gpu'   See '-march=' in
                                                      "Nvidia PTX
                                                      Options"
  
     ---------- Footnotes ----------
  
!    (1) Additionally, 'gfx803' is supported as an alias for 'fiji'.
  
  
  File: libgomp.info,  Node: Memory allocation with libmemkind,  Prev: OpenMP Context Selectors,  Up: OpenMP-Implementation Specifics
--- 4053,4076 ----
  11.1 OpenMP Context Selectors
  =============================
  
! ‘vendor’ is always ‘gnu’.  References are to the GCC manual.
  
! ‘arch’                                      ‘kind’  ‘isa’
  -----------------------------------------------------------------------
! ‘x86’, ‘x86_64’, ‘i386’, ‘i486’, ‘i586’,    ‘host’  See ‘-m...’
! ‘i686’, ‘ia32’                                      flags in "x86
                                                      Options"
!                                                     (without ‘-m’)
! ‘amdgcn’, ‘gcn’                             ‘gpu’   See ‘-march=’ in
                                                      "AMD GCN
                                                      Options"(1)
! ‘nvptx’                                     ‘gpu’   See ‘-march=’ in
                                                      "Nvidia PTX
                                                      Options"
  
     ---------- Footnotes ----------
  
!    (1) Additionally, ‘gfx803’ is supported as an alias for ‘fiji’.
  
  
  File: libgomp.info,  Node: Memory allocation with libmemkind,  Prev: OpenMP Context Selectors,  Up: OpenMP-Implementation Specifics
*************** File: libgomp.info,  Node: Memory alloca
*** 4079,4090 ****
  ======================================
  
  On Linux systems, where the memkind library
! (https://github.com/memkind/memkind) ('libmemkind.so.0') is available at
  runtime, it is used when creating memory allocators requesting
  
!    * the memory space 'omp_high_bw_mem_space'
!    * the memory space 'omp_large_cap_mem_space'
!    * the partition trait 'omp_atv_interleaved'
  
  
  File: libgomp.info,  Node: Offload-Target Specifics,  Next: The libgomp ABI,  Prev: OpenMP-Implementation Specifics,  Up: Top
--- 4079,4090 ----
  ======================================
  
  On Linux systems, where the memkind library
! (https://github.com/memkind/memkind) (‘libmemkind.so.0’) is available at
  runtime, it is used when creating memory allocators requesting
  
!    • the memory space ‘omp_high_bw_mem_space’
!    • the memory space ‘omp_large_cap_mem_space’
!    • the partition trait ‘omp_atv_interleaved’
  
  
  File: libgomp.info,  Node: Offload-Target Specifics,  Next: The libgomp ABI,  Prev: OpenMP-Implementation Specifics,  Up: Top
*************** File: libgomp.info,  Node: AMD Radeon,
*** 4106,4153 ****
  =====================
  
  On the hardware side, there is the hierarchy (fine to coarse):
!    * work item (thread)
!    * wavefront
!    * work group
!    * compute unit (CU)
  
     All OpenMP and OpenACC levels are used, i.e.
!    * OpenMP's simd and OpenACC's vector map to work items (thread)
!    * OpenMP's threads ("parallel") and OpenACC's workers map to
       wavefronts
!    * OpenMP's teams and OpenACC's gang use a threadpool with the size of
       the number of teams or gangs, respectively.
  
     The used sizes are
!    * Number of teams is the specified 'num_teams' (OpenMP) or
!      'num_gangs' (OpenACC) or otherwise the number of CU. It is limited
       by two times the number of CU.
!    * Number of wavefronts is 4 for gfx900 and 16 otherwise;
!      'num_threads' (OpenMP) and 'num_workers' (OpenACC) overrides this
       if smaller.
!    * The wavefront has 102 scalars and 64 vectors
!    * Number of workitems is always 64
!    * The hardware permits maximally 40 workgroups/CU and 16
       wavefronts/workgroup up to a limit of 40 wavefronts in total per
       CU.
!    * 80 scalars registers and 24 vector registers in non-kernel
       functions (the chosen procedure-calling API).
!    * For the kernel itself: as many as register pressure demands (number
       of teams and number of threads, scaled down if registers are
       exhausted)
  
     The implementation remark:
!    * I/O within OpenMP target regions and OpenACC parallel/kernels is
!      supported using the C library 'printf' functions and the Fortran
!      'print'/'write' statements.
!    * Reverse offload regions (i.e.  'target' regions with
!      'device(ancestor:1)') are processed serially per 'target' region
       such that the next reverse offload region is only executed after
       the previous one returned.
!    * OpenMP code that has a requires directive with 'unified_address' or
!      'unified_shared_memory' will remove any GCN device from the list of
       available devices ("host fallback").
!    * The available stack size can be changed using the 'GCN_STACK_SIZE'
       environment variable; the default is 32 kiB per thread.
  
  
--- 4106,4153 ----
  =====================
  
  On the hardware side, there is the hierarchy (fine to coarse):
!    • work item (thread)
!    • wavefront
!    • work group
!    • compute unit (CU)
  
     All OpenMP and OpenACC levels are used, i.e.
!    • OpenMP's simd and OpenACC's vector map to work items (thread)
!    • OpenMP's threads ("parallel") and OpenACC's workers map to
       wavefronts
!    • OpenMP's teams and OpenACC's gang use a threadpool with the size of
       the number of teams or gangs, respectively.
  
     The used sizes are
!    • Number of teams is the specified ‘num_teams’ (OpenMP) or
!      ‘num_gangs’ (OpenACC) or otherwise the number of CU. It is limited
       by two times the number of CU.
!    • Number of wavefronts is 4 for gfx900 and 16 otherwise;
!      ‘num_threads’ (OpenMP) and ‘num_workers’ (OpenACC) overrides this
       if smaller.
!    • The wavefront has 102 scalars and 64 vectors
!    • Number of workitems is always 64
!    • The hardware permits maximally 40 workgroups/CU and 16
       wavefronts/workgroup up to a limit of 40 wavefronts in total per
       CU.
!    • 80 scalars registers and 24 vector registers in non-kernel
       functions (the chosen procedure-calling API).
!    • For the kernel itself: as many as register pressure demands (number
       of teams and number of threads, scaled down if registers are
       exhausted)
  
     The implementation remark:
!    • I/O within OpenMP target regions and OpenACC parallel/kernels is
!      supported using the C library ‘printf’ functions and the Fortran
!      ‘print’/‘write’ statements.
!    • Reverse offload regions (i.e.  ‘target’ regions with
!      ‘device(ancestor:1)’) are processed serially per ‘target’ region
       such that the next reverse offload region is only executed after
       the previous one returned.
!    • OpenMP code that has a requires directive with ‘unified_address’ or
!      ‘unified_shared_memory’ will remove any GCN device from the list of
       available devices ("host fallback").
!    • The available stack size can be changed using the ‘GCN_STACK_SIZE’
       environment variable; the default is 32 kiB per thread.
  
  
*************** File: libgomp.info,  Node: nvptx,  Prev:
*** 4157,4208 ****
  ==========
  
  On the hardware side, there is the hierarchy (fine to coarse):
!    * thread
!    * warp
!    * thread block
!    * streaming multiprocessor
  
     All OpenMP and OpenACC levels are used, i.e.
!    * OpenMP's simd and OpenACC's vector map to threads
!    * OpenMP's threads ("parallel") and OpenACC's workers map to warps
!    * OpenMP's teams and OpenACC's gang use a threadpool with the size of
       the number of teams or gangs, respectively.
  
     The used sizes are
!    * The 'warp_size' is always 32
!    * CUDA kernel launched: 'dim={#teams,1,1},
!      blocks={#threads,warp_size,1}'.
!    * The number of teams is limited by the number of blocks the device
       can host simultaneously.
  
     Additional information can be obtained by setting the environment
! variable to 'GOMP_DEBUG=1' (very verbose; grep for 'kernel.*launch' for
  launch parameters).
  
     GCC generates generic PTX ISA code, which is just-in-time compiled by
  CUDA, which caches the JIT in the user's directory (see CUDA
  documentation; can be tuned by the environment variables
! 'CUDA_CACHE_{DISABLE,MAXSIZE,PATH}'.
  
!    Note: While PTX ISA is generic, the '-mptx=' and '-march='
  commandline options still affect the used PTX ISA code and, thus, the
  requirements on CUDA version and hardware.
  
     The implementation remark:
!    * I/O within OpenMP target regions and OpenACC parallel/kernels is
!      supported using the C library 'printf' functions.  Note that the
!      Fortran 'print'/'write' statements are not supported, yet.
!    * Compilation OpenMP code that contains 'requires reverse_offload'
!      requires at least '-march=sm_35', compiling for '-march=sm_30' is
       not supported.
!    * For code containing reverse offload (i.e.  'target' regions with
!      'device(ancestor:1)'), there is a slight performance penalty for
       _all_ target regions, consisting mostly of shutdown delay Per
       device, reverse offload regions are processed serially such that
       the next reverse offload region is only executed after the previous
       one returned.
!    * OpenMP code that has a requires directive with 'unified_address' or
!      'unified_shared_memory' will remove any nvptx device from the list
       of available devices ("host fallback").
  
  
--- 4157,4208 ----
  ==========
  
  On the hardware side, there is the hierarchy (fine to coarse):
!    • thread
!    • warp
!    • thread block
!    • streaming multiprocessor
  
     All OpenMP and OpenACC levels are used, i.e.
!    • OpenMP's simd and OpenACC's vector map to threads
!    • OpenMP's threads ("parallel") and OpenACC's workers map to warps
!    • OpenMP's teams and OpenACC's gang use a threadpool with the size of
       the number of teams or gangs, respectively.
  
     The used sizes are
!    • The ‘warp_size’ is always 32
!    • CUDA kernel launched: ‘dim={#teams,1,1},
!      blocks={#threads,warp_size,1}’.
!    • The number of teams is limited by the number of blocks the device
       can host simultaneously.
  
     Additional information can be obtained by setting the environment
! variable to ‘GOMP_DEBUG=1’ (very verbose; grep for ‘kernel.*launch’ for
  launch parameters).
  
     GCC generates generic PTX ISA code, which is just-in-time compiled by
  CUDA, which caches the JIT in the user's directory (see CUDA
  documentation; can be tuned by the environment variables
! ‘CUDA_CACHE_{DISABLE,MAXSIZE,PATH}’.
  
!    Note: While PTX ISA is generic, the ‘-mptx=’ and ‘-march=’
  commandline options still affect the used PTX ISA code and, thus, the
  requirements on CUDA version and hardware.
  
     The implementation remark:
!    • I/O within OpenMP target regions and OpenACC parallel/kernels is
!      supported using the C library ‘printf’ functions.  Note that the
!      Fortran ‘print’/‘write’ statements are not supported, yet.
!    • Compilation OpenMP code that contains ‘requires reverse_offload’
!      requires at least ‘-march=sm_35’, compiling for ‘-march=sm_30’ is
       not supported.
!    • For code containing reverse offload (i.e.  ‘target’ regions with
!      ‘device(ancestor:1)’), there is a slight performance penalty for
       _all_ target regions, consisting mostly of shutdown delay Per
       device, reverse offload regions are processed serially such that
       the next reverse offload region is only executed after the previous
       one returned.
!    • OpenMP code that has a requires directive with ‘unified_address’ or
!      ‘unified_shared_memory’ will remove any nvptx device from the list
       of available devices ("host fallback").
  
  
*************** File: libgomp.info,  Node: Implementing
*** 4273,4279 ****
  13.3 Implementing ATOMIC construct
  ==================================
  
! The target should implement the '__sync' builtins.
  
     Failing that we could add
  
--- 4273,4279 ----
  13.3 Implementing ATOMIC construct
  ==================================
  
! The target should implement the ‘__sync’ builtins.
  
     Failing that we could add
  
*************** File: libgomp.info,  Node: Implementing
*** 4289,4295 ****
  13.4 Implementing FLUSH construct
  =================================
  
! Expands to the '__sync_synchronize' builtin.
  
  
  File: libgomp.info,  Node: Implementing BARRIER construct,  Next: Implementing THREADPRIVATE construct,  Prev: Implementing FLUSH construct,  Up: The libgomp ABI
--- 4289,4295 ----
  13.4 Implementing FLUSH construct
  =================================
  
! Expands to the ‘__sync_synchronize’ builtin.
  
  
  File: libgomp.info,  Node: Implementing BARRIER construct,  Next: Implementing THREADPRIVATE construct,  Prev: Implementing FLUSH construct,  Up: The libgomp ABI
*************** File: libgomp.info,  Node: Implementing
*** 4305,4311 ****
  13.6 Implementing THREADPRIVATE construct
  =========================================
  
! In _most_ cases we can map this directly to '__thread'.  Except that OMP
  allows constructors for C++ objects.  We can either refuse to support
  this (how often is it used?)  or we can implement something akin to
  .ctors.
--- 4305,4311 ----
  13.6 Implementing THREADPRIVATE construct
  =========================================
  
! In _most_ cases we can map this directly to ‘__thread’.  Except that OMP
  allows constructors for C++ objects.  We can either refuse to support
  this (how often is it used?)  or we can implement something akin to
  .ctors.
*************** thing I can figure is that we do somethi
*** 4360,4366 ****
  
     where the "x=x" and "y=y" assignments actually have different uids
  for the two variables, i.e.  not something you could write directly in
! C. Presumably this only makes sense if the "outer" x and y are global
  variables.
  
     COPYPRIVATE would work the same way, except the structure broadcast
--- 4360,4366 ----
  
     where the "x=x" and "y=y" assignments actually have different uids
  for the two variables, i.e.  not something you could write directly in
! C.  Presumably this only makes sense if the "outer" x and y are global
  variables.
  
     COPYPRIVATE would work the same way, except the structure broadcast
*************** assign team ids.
*** 4420,4426 ****
         void GOMP_parallel_end (void)
  
     Tears down the team and returns us to the previous
! 'omp_in_parallel()' state.
  
  
  File: libgomp.info,  Node: Implementing FOR construct,  Next: Implementing ORDERED construct,  Prev: Implementing PARALLEL construct,  Up: The libgomp ABI
--- 4420,4426 ----
         void GOMP_parallel_end (void)
  
     Tears down the team and returns us to the previous
! ‘omp_in_parallel()’ state.
  
  
  File: libgomp.info,  Node: Implementing FOR construct,  Next: Implementing ORDERED construct,  Prev: Implementing PARALLEL construct,  Up: The libgomp ABI
*************** GNU General Public License
*** 4592,4598 ****
  
                          Version 3, 29 June 2007
  
!      Copyright (C) 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
--- 4592,4598 ----
  
                          Version 3, 29 June 2007
  
!      Copyright © 2007 Free Software Foundation, Inc. 
  
       Everyone is permitted to copy and distribute verbatim copies of this
       license document, but changing it is not allowed.
*************** mail.
*** 5279,5289 ****
  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".
--- 5279,5289 ----
  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".
*************** GNU Free Documentation License
*** 5308,5314 ****
  
                       Version 1.3, 3 November 2008
  
!      Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
--- 5308,5314 ----
  
                       Version 1.3, 3 November 2008
  
!      Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
*************** GNU Free Documentation License
*** 5317,5323 ****
    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
--- 5317,5323 ----
    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
*************** more; major new features or packages con
*** 5828,5834 ****
  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.
  
--- 5828,5834 ----
  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 © 1994 Free Software Foundation, Inc.
       Verbatim copying and redistribution of this section is permitted
       without royalty; alteration is not permitted.
  
*************** Library Index
*** 5882,6052 ****
  
  
  Tag Table:
! Node: Top2083
! Node: Enabling OpenMP4912
! Node: OpenMP Implementation Status5718
! Node: OpenMP 4.56413
! Node: OpenMP 5.06589
! Node: OpenMP 5.111566
! Node: OpenMP 5.215605
! Ref: OpenMP 5.2-Footnote-118528
! Node: OpenMP Technical Report 1118934
! Node: Runtime Library Routines21495
! Node: omp_get_active_level25200
! Node: omp_get_ancestor_thread_num25900
! Node: omp_get_cancellation26830
! Node: omp_get_default_device27644
! Node: omp_get_device_num28323
! Node: omp_get_dynamic29128
! Node: omp_get_initial_device30008
! Node: omp_get_level30752
! Node: omp_get_max_active_levels31379
! Node: omp_get_max_task_priority32100
! Node: omp_get_max_teams32720
! Node: omp_get_max_threads33414
! Node: omp_get_nested34165
! Node: omp_get_num_devices35773
! Node: omp_get_num_procs36294
! Node: omp_get_num_teams36833
! Node: omp_get_num_threads37349
! Node: omp_get_proc_bind38438
! Node: omp_get_schedule39461
! Node: omp_get_supported_active_levels40430
! Node: omp_get_team_num41216
! Node: omp_get_team_size41730
! Node: omp_get_teams_thread_limit42696
! Node: omp_get_thread_limit43458
! Node: omp_get_thread_num44086
! Node: omp_in_parallel44958
! Node: omp_in_final45607
! Node: omp_is_initial_device46281
! Node: omp_set_default_device46974
! Node: omp_set_dynamic47765
! Node: omp_set_max_active_levels48651
! Node: omp_set_nested49573
! Node: omp_set_num_teams50768
! Node: omp_set_num_threads51641
! Node: omp_set_schedule52512
! Node: omp_set_teams_thread_limit53606
! Node: omp_init_lock54608
! Node: omp_set_lock55271
! Node: omp_test_lock56126
! Node: omp_unset_lock57102
! Node: omp_destroy_lock58033
! Node: omp_init_nest_lock58710
! Node: omp_set_nest_lock59445
! Node: omp_test_nest_lock60360
! Node: omp_unset_nest_lock61387
! Node: omp_destroy_nest_lock62402
! Node: omp_get_wtick63153
! Node: omp_get_wtime63745
! Node: omp_fulfill_event64547
! Node: Environment Variables65568
! Node: OMP_CANCELLATION67357
! Node: OMP_DISPLAY_ENV67890
! Node: OMP_DEFAULT_DEVICE68593
! Node: OMP_DYNAMIC69373
! Node: OMP_MAX_ACTIVE_LEVELS69969
! Node: OMP_MAX_TASK_PRIORITY70896
! Node: OMP_NESTED71554
! Node: OMP_NUM_TEAMS72581
! Node: OMP_NUM_THREADS73254
! Node: OMP_PROC_BIND74059
! Node: OMP_PLACES75401
! Node: OMP_STACKSIZE78090
! Node: OMP_SCHEDULE78914
! Node: OMP_TARGET_OFFLOAD79614
! Node: OMP_TEAMS_THREAD_LIMIT80576
! Node: OMP_THREAD_LIMIT81383
! Node: OMP_WAIT_POLICY81993
! Node: GOMP_CPU_AFFINITY82685
! Node: GOMP_DEBUG84415
! Node: GOMP_STACKSIZE84922
! Node: GOMP_SPINCOUNT85753
! Node: GOMP_RTEMS_THREAD_POOLS86957
! Node: Enabling OpenACC89140
! Node: OpenACC Runtime Library Routines90041
! Node: acc_get_num_devices94322
! Node: acc_set_device_type95048
! Node: acc_get_device_type95812
! Node: acc_set_device_num96825
! Node: acc_get_device_num97642
! Node: acc_get_property98441
! Node: acc_async_test100664
! Node: acc_async_test_all101652
! Node: acc_wait102552
! Node: acc_wait_all103415
! Node: acc_wait_all_async104176
! Node: acc_wait_async104928
! Node: acc_init105636
! Node: acc_shutdown106281
! Node: acc_on_device106948
! Node: acc_malloc107952
! Node: acc_free108451
! Node: acc_copyin108878
! Node: acc_present_or_copyin110465
! Node: acc_create112243
! Node: acc_present_or_create113875
! Node: acc_copyout115661
! Node: acc_delete117965
! Node: acc_update_device120212
! Node: acc_update_self121786
! Node: acc_map_data123376
! Node: acc_unmap_data124061
! Node: acc_deviceptr124582
! Node: acc_hostptr125152
! Node: acc_is_present125716
! Node: acc_memcpy_to_device127243
! Node: acc_memcpy_from_device127906
! Node: acc_attach128573
! Node: acc_detach129220
! Node: acc_get_current_cuda_device129999
! Node: acc_get_current_cuda_context130584
! Node: acc_get_cuda_stream131184
! Node: acc_set_cuda_stream131775
! Node: acc_prof_register132446
! Node: acc_prof_unregister133005
! Node: acc_prof_lookup133572
! Node: acc_register_library134093
! Node: OpenACC Environment Variables134659
! Node: ACC_DEVICE_TYPE135231
! Node: ACC_DEVICE_NUM135467
! Node: ACC_PROFLIB135721
! Node: GCC_ACC_NOTIFY136052
! Node: CUDA Streams Usage136272
! Ref: CUDA Streams Usage-Footnote-1138173
! Node: OpenACC Library Interoperability138282
! Ref: OpenACC Library Interoperability-Footnote-1144649
! Ref: OpenACC Library Interoperability-Footnote-2144901
! Node: OpenACC Profiling Interface145109
! Node: OpenMP-Implementation Specifics155153
! Node: OpenMP Context Selectors155442
! Ref: OpenMP Context Selectors-Footnote-1156513
! Node: Memory allocation with libmemkind156581
! Node: Offload-Target Specifics157118
! Node: AMD Radeon157409
! Node: nvptx159593
! Node: The libgomp ABI161895
! Node: Implementing MASTER construct162745
! Node: Implementing CRITICAL construct163162
! Node: Implementing ATOMIC construct163903
! Node: Implementing FLUSH construct164386
! Node: Implementing BARRIER construct164659
! Node: Implementing THREADPRIVATE construct164930
! Node: Implementing PRIVATE clause165585
! Node: Implementing FIRSTPRIVATE LASTPRIVATE COPYIN and COPYPRIVATE clauses166168
! Node: Implementing REDUCTION clause167494
! Node: Implementing PARALLEL construct168054
! Node: Implementing FOR construct169313
! Node: Implementing ORDERED construct171313
! Node: Implementing SECTIONS construct171621
! Node: Implementing SINGLE construct172389
! Node: Implementing OpenACC's PARALLEL construct173103
! Node: Reporting Bugs173363
! Node: Copying173726
! Node: GNU Free Documentation License211278
! Node: Funding236406
! Node: Library Index238932
  
  End Tag Table
  
--- 5882,6052 ----
  
  
  Tag Table:
! Node: Top2081
! Node: Enabling OpenMP4910
! Node: OpenMP Implementation Status5756
! Node: OpenMP 4.56471
! Node: OpenMP 5.06647
! Node: OpenMP 5.111908
! Node: OpenMP 5.216283
! Ref: OpenMP 5.2-Footnote-119406
! Node: OpenMP Technical Report 1119840
! Node: Runtime Library Routines22545
! Node: omp_get_active_level26250
! Node: omp_get_ancestor_thread_num26962
! Node: omp_get_cancellation27920
! Node: omp_get_default_device28766
! Node: omp_get_device_num29457
! Node: omp_get_dynamic30278
! Node: omp_get_initial_device31194
! Node: omp_get_level31954
! Node: omp_get_max_active_levels32593
! Node: omp_get_max_task_priority33326
! Node: omp_get_max_teams33958
! Node: omp_get_max_threads34668
! Node: omp_get_nested35435
! Node: omp_get_num_devices37095
! Node: omp_get_num_procs37628
! Node: omp_get_num_teams38179
! Node: omp_get_num_threads38707
! Node: omp_get_proc_bind39828
! Node: omp_get_schedule40899
! Node: omp_get_supported_active_levels41904
! Node: omp_get_team_num42702
! Node: omp_get_team_size43228
! Node: omp_get_teams_thread_limit44222
! Node: omp_get_thread_limit44996
! Node: omp_get_thread_num45636
! Node: omp_in_parallel46528
! Node: omp_in_final47205
! Node: omp_is_initial_device47907
! Node: omp_set_default_device48628
! Node: omp_set_dynamic49435
! Node: omp_set_max_active_levels50353
! Node: omp_set_nested51295
! Node: omp_set_num_teams52522
! Node: omp_set_num_threads53419
! Node: omp_set_schedule54314
! Node: omp_set_teams_thread_limit55452
! Node: omp_init_lock56478
! Node: omp_set_lock57157
! Node: omp_test_lock58032
! Node: omp_unset_lock59052
! Node: omp_destroy_lock60011
! Node: omp_init_nest_lock60704
! Node: omp_set_nest_lock61455
! Node: omp_test_nest_lock62390
! Node: omp_unset_nest_lock63445
! Node: omp_destroy_nest_lock64488
! Node: omp_get_wtick65255
! Node: omp_get_wtime65859
! Node: omp_fulfill_event66673
! Node: Environment Variables67714
! Node: OMP_CANCELLATION69511
! Node: OMP_DISPLAY_ENV70060
! Node: OMP_DEFAULT_DEVICE70783
! Node: OMP_DYNAMIC71579
! Node: OMP_MAX_ACTIVE_LEVELS72187
! Node: OMP_MAX_TASK_PRIORITY73130
! Node: OMP_NESTED73792
! Node: OMP_NUM_TEAMS74847
! Node: OMP_NUM_THREADS75528
! Node: OMP_PROC_BIND76337
! Node: OMP_PLACES77743
! Node: OMP_STACKSIZE80512
! Node: OMP_SCHEDULE81360
! Node: OMP_TARGET_OFFLOAD82100
! Node: OMP_TEAMS_THREAD_LIMIT83094
! Node: OMP_THREAD_LIMIT83909
! Node: OMP_WAIT_POLICY84523
! Node: GOMP_CPU_AFFINITY85227
! Node: GOMP_DEBUG87006
! Node: GOMP_STACKSIZE87525
! Node: GOMP_SPINCOUNT88364
! Node: GOMP_RTEMS_THREAD_POOLS89636
! Node: Enabling OpenACC91893
! Node: OpenACC Runtime Library Routines92834
! Node: acc_get_num_devices97119
! Node: acc_set_device_type97861
! Node: acc_get_device_type98641
! Node: acc_set_device_num99686
! Node: acc_get_device_num100523
! Node: acc_get_property101342
! Node: acc_async_test103645
! Node: acc_async_test_all104661
! Node: acc_wait105585
! Node: acc_wait_all106476
! Node: acc_wait_all_async107257
! Node: acc_wait_async108025
! Node: acc_init108749
! Node: acc_shutdown109410
! Node: acc_on_device110093
! Node: acc_malloc111125
! Node: acc_free111632
! Node: acc_copyin112071
! Node: acc_present_or_copyin113718
! Node: acc_create115556
! Node: acc_present_or_create117248
! Node: acc_copyout119094
! Node: acc_delete121514
! Node: acc_update_device123877
! Node: acc_update_self125511
! Node: acc_map_data127161
! Node: acc_unmap_data127854
! Node: acc_deviceptr128383
! Node: acc_hostptr128961
! Node: acc_is_present129533
! Node: acc_memcpy_to_device131104
! Node: acc_memcpy_from_device131775
! Node: acc_attach132450
! Node: acc_detach133109
! Node: acc_get_current_cuda_device133908
! Node: acc_get_current_cuda_context134501
! Node: acc_get_cuda_stream135109
! Node: acc_set_cuda_stream135708
! Node: acc_prof_register136391
! Node: acc_prof_unregister136958
! Node: acc_prof_lookup137533
! Node: acc_register_library138062
! Node: OpenACC Environment Variables138636
! Node: ACC_DEVICE_TYPE139224
! Node: ACC_DEVICE_NUM139464
! Node: ACC_PROFLIB139722
! Node: GCC_ACC_NOTIFY140057
! Node: CUDA Streams Usage140281
! Ref: CUDA Streams Usage-Footnote-1142254
! Node: OpenACC Library Interoperability142363
! Ref: OpenACC Library Interoperability-Footnote-1148822
! Ref: OpenACC Library Interoperability-Footnote-2149074
! Node: OpenACC Profiling Interface149290
! Node: OpenMP-Implementation Specifics160092
! Node: OpenMP Context Selectors160381
! Ref: OpenMP Context Selectors-Footnote-1161540
! Node: Memory allocation with libmemkind161616
! Node: Offload-Target Specifics162175
! Node: AMD Radeon162466
! Node: nvptx164738
! Node: The libgomp ABI167136
! Node: Implementing MASTER construct167986
! Node: Implementing CRITICAL construct168403
! Node: Implementing ATOMIC construct169144
! Node: Implementing FLUSH construct169631
! Node: Implementing BARRIER construct169908
! Node: Implementing THREADPRIVATE construct170179
! Node: Implementing PRIVATE clause170838
! Node: Implementing FIRSTPRIVATE LASTPRIVATE COPYIN and COPYPRIVATE clauses171421
! Node: Implementing REDUCTION clause172748
! Node: Implementing PARALLEL construct173308
! Node: Implementing FOR construct174571
! Node: Implementing ORDERED construct176571
! Node: Implementing SECTIONS construct176879
! Node: Implementing SINGLE construct177647
! Node: Implementing OpenACC's PARALLEL construct178361
! Node: Reporting Bugs178621
! Node: Copying178984
! Node: GNU Free Documentation License216551
! Node: Funding241682
! Node: Library Index244207
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/libgomp/testsuite/libgomp.fortran/pr120286.f90 gcc-13.5.0-RC-20260904/libgomp/testsuite/libgomp.fortran/pr120286.f90
*** gcc-13.4.0/libgomp/testsuite/libgomp.fortran/pr120286.f90	Thu Jan  1 00:00:00 1970
--- gcc-13.5.0-RC-20260904/libgomp/testsuite/libgomp.fortran/pr120286.f90	Fri Sep  4 07:35:12 2026
***************
*** 0 ****
--- 1,49 ----
+ ! { dg-do run }
+ !
+ ! PR fortran/120286 - scalar class pointers in OpenMP private/firstprivate
+ ! clauses must preserve association status without taking ownership.
+ 
+ program main
+   implicit none
+ 
+   type foo_t
+     integer :: dummy
+   end type foo_t
+ 
+   type fooPtr_t
+     class(foo_t), pointer :: p
+   end type fooPtr_t
+ 
+   type fooPtrStack_t
+     class(fooPtr_t), allocatable :: list(:)
+   end type fooPtrStack_t
+ 
+   type(fooPtrStack_t) :: x
+   class(foo_t), pointer :: ptr
+   integer :: it, n
+   logical :: ok
+ 
+   allocate (x%list(1))
+   allocate (x%list(1)%p)
+   x%list(1)%p%dummy = 7
+ 
+   do it = 1, 16
+ !$omp parallel do default(none) num_threads(2) private(n, ptr) shared(x)
+     do n = 1, 1
+       ptr => x%list(n)%p
+     end do
+ !$omp end parallel do
+   end do
+ 
+   if (.not. associated (x%list(1)%p)) stop 1
+   if (x%list(1)%p%dummy /= 7) stop 2
+ 
+   ptr => x%list(1)%p
+   ok = .false.
+ 
+ !$omp parallel default(none) num_threads(1) firstprivate(ptr) shared(x, ok)
+   ok = associated (ptr, x%list(1)%p) .and. ptr%dummy == 7
+ !$omp end parallel
+ 
+   if (.not. ok) stop 3
+ end program main
diff -Nrcpad gcc-13.4.0/libiberty/ChangeLog gcc-13.5.0-RC-20260904/libiberty/ChangeLog
*** gcc-13.4.0/libiberty/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/libiberty/ChangeLog	Fri Sep  4 07:35:12 2026
***************
*** 1,3 ****
--- 1,12 ----
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-05  Jakub Jelinek  
+ 
+ 	PR target/124365
+ 	* simple-object.c (handle_lto_debug_sections): Also copy over
+ 	.ARM.attributes section.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/libiberty/simple-object.c gcc-13.5.0-RC-20260904/libiberty/simple-object.c
*** gcc-13.4.0/libiberty/simple-object.c	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libiberty/simple-object.c	Fri Sep  4 07:35:12 2026
*************** handle_lto_debug_sections (const char *n
*** 310,315 ****
--- 310,319 ----
    /* Copy over .BTF section under the same name if present.  */
    else if (strcmp (name, ".BTF") == 0)
      return strcpy (newname, name);
+   /* Copy over .ARM.attributes section under the same name if present.  AArch64
+      aeabi attributes are present in this section.  */
+   else if (strcmp (name, ".ARM.attributes") == 0)
+     return strcpy (newname, name);
    free (newname);
    return NULL;
  }
diff -Nrcpad gcc-13.4.0/libitm/libitm.info gcc-13.5.0-RC-20260904/libitm/libitm.info
*** gcc-13.4.0/libitm/libitm.info	Thu Jun  5 16:28:34 2025
--- gcc-13.5.0-RC-20260904/libitm/libitm.info	Fri Sep  4 07:56:14 2026
***************
*** 1,6 ****
! This is libitm.info, produced by makeinfo version 6.8 from libitm.texi.
  
! Copyright (C) 2011-2023 Free Software Foundation, Inc.
  
     Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.2 or
--- 1,6 ----
! This is libitm.info, produced by makeinfo version 7.1 from libitm.texi.
  
! Copyright © 2011-2023 Free Software Foundation, Inc.
  
     Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.2 or
*************** END-INFO-DIR-ENTRY
*** 15,21 ****
  
     This manual documents the GNU Transactional Memory Library.
  
!    Copyright (C) 2011-2023 Free Software Foundation, Inc.
  
     Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.2 or
--- 15,21 ----
  
     This manual documents the GNU Transactional Memory Library.
  
!    Copyright © 2011-2023 Free Software Foundation, Inc.
  
     Permission is granted to copy, distribute and/or modify this document
  under the terms of the GNU Free Documentation License, Version 1.2 or
*************** File: libitm.info,  Node: Enabling libit
*** 53,61 ****
  1 Enabling libitm
  *****************
  
! To activate support for TM in C/C++, the compile-time flag '-fgnu-tm'
  must be specified.  This enables TM language-level constructs such as
! transaction statements (e.g., '__transaction_atomic', *note C/C++
  Language Constructs for TM:: for details).
  
  
--- 53,61 ----
  1 Enabling libitm
  *****************
  
! To activate support for TM in C/C++, the compile-time flag ‘-fgnu-tm’
  must be specified.  This enables TM language-level constructs such as
! transaction statements (e.g., ‘__transaction_atomic’, *note C/C++
  Language Constructs for TM:: for details).
  
  
*************** File: libitm.info,  Node: C/C++ Language
*** 66,78 ****
  
  Transactions are supported in C++ and C in the form of transaction
  statements, transaction expressions, and function transactions.  In the
! following example, both 'a' and 'b' will be read and the difference will
! be written to 'c', all atomically and isolated from other transactions:
  
       __transaction_atomic { c = a - b; }
  
     Therefore, another thread can use the following code to concurrently
! update 'b' without ever causing 'c' to hold a negative value (and
  without having to use other synchronization constructs such as locks or
  C++11 atomics):
  
--- 66,78 ----
  
  Transactions are supported in C++ and C in the form of transaction
  statements, transaction expressions, and function transactions.  In the
! following example, both ‘a’ and ‘b’ will be read and the difference will
! be written to ‘c’, all atomically and isolated from other transactions:
  
       __transaction_atomic { c = a - b; }
  
     Therefore, another thread can use the following code to concurrently
! update ‘b’ without ever causing ‘c’ to hold a negative value (and
  without having to use other synchronization constructs such as locks or
  C++11 atomics):
  
*************** these stack frames' lifetimes will end b
*** 159,165 ****
  3.3.9 Store allocation
  ----------------------
  
! There is no 'getTransaction' function.
  
  3.3.10 [No changes] Naming conventions
  --------------------------------------
--- 159,165 ----
  3.3.9 Store allocation
  ----------------------
  
! There is no ‘getTransaction’ function.
  
  3.3.10 [No changes] Naming conventions
  --------------------------------------
*************** Currently, this is not implemented.
*** 172,179 ****
  3.4 Types and macros list
  =========================
  
! '_ITM_codeProperties' has changed, *note Starting a transaction:
! txn-code-properties.  '_ITM_srcLocation' is not used.
  
  3.5 Function list
  =================
--- 172,179 ----
  3.4 Types and macros list
  =========================
  
! ‘_ITM_codeProperties’ has changed, *note Starting a transaction:
! txn-code-properties.  ‘_ITM_srcLocation’ is not used.
  
  3.5 Function list
  =================
*************** These functions are not part of the ABI.
*** 195,201 ****
  3.5.5 State manipulation functions
  ----------------------------------
  
! There is no 'getTransaction' function.  Transaction identifiers for
  nested transactions will be ordered but not necessarily sequential
  (i.e., for a nested transaction's identifier IN and its enclosing
  transaction's identifier IE, it is guaranteed that IN >= IE).
--- 195,201 ----
  3.5.5 State manipulation functions
  ----------------------------------
  
! There is no ‘getTransaction’ function.  Transaction identifiers for
  nested transactions will be ordered but not necessarily sequential
  (i.e., for a nested transaction's identifier IN and its enclosing
  transaction's identifier IE, it is guaranteed that IN >= IE).
*************** transaction's identifier IE, it is guara
*** 209,223 ****
  3.5.7.1 Transaction code properties
  ...................................
  
! The bit 'hasNoXMMUpdate' is instead called 'hasNoVectorUpdate'.  Iff it
  is set, vector register save/restore is not necessary for any target
  machine.
  
!    The 'hasNoFloatUpdate' bit ('0x0010') is new.  Iff it is set,
  floating point register save/restore is not necessary for any target
  machine.
  
!    'undoLogCode' is not supported and a fatal runtime error will be
  raised if this bit is set.  It is not properly defined in the ABI why
  barriers other than undo logging are not present; Are they not necessary
  (e.g., a transaction operating purely on thread-local data) or have they
--- 209,223 ----
  3.5.7.1 Transaction code properties
  ...................................
  
! The bit ‘hasNoXMMUpdate’ is instead called ‘hasNoVectorUpdate’.  Iff it
  is set, vector register save/restore is not necessary for any target
  machine.
  
!    The ‘hasNoFloatUpdate’ bit (‘0x0010’) is new.  Iff it is set,
  floating point register save/restore is not necessary for any target
  machine.
  
!    ‘undoLogCode’ is not supported and a fatal runtime error will be
  raised if this bit is set.  It is not properly defined in the ABI why
  barriers other than undo logging are not present; Are they not necessary
  (e.g., a transaction operating purely on thread-local data) or have they
*************** synchronization (e.g., serial mode) migh
*** 226,244 ****
  specification suggests that the latter might be the case, but the former
  seems to be more useful.
  
!    The 'readOnly' bit ('0x4000') is new.  *TODO* Lexical or dynamic
  scope?
  
!    'hasNoRetry' is not supported.  If this bit is not set, but
! 'hasNoAbort' is set, the library can assume that transaction rollback
  will not be requested.
  
     It would be useful if the absence of externally-triggered rollbacks
  would be reported for the dynamic scope as well, not just for the
! lexical scope ('hasNoAbort').  Without this, a library cannot exploit
  this together with flat nesting.
  
!    'exceptionBlock' is not supported because exception blocks are not
  used.
  
  3.5.7.2 [No changes] Windows exception state
--- 226,244 ----
  specification suggests that the latter might be the case, but the former
  seems to be more useful.
  
!    The ‘readOnly’ bit (‘0x4000’) is new.  *TODO* Lexical or dynamic
  scope?
  
!    ‘hasNoRetry’ is not supported.  If this bit is not set, but
! ‘hasNoAbort’ is set, the library can assume that transaction rollback
  will not be requested.
  
     It would be useful if the absence of externally-triggered rollbacks
  would be reported for the dynamic scope as well, not just for the
! lexical scope (‘hasNoAbort’).  Without this, a library cannot exploit
  this together with flat nesting.
  
!    ‘exceptionBlock’ is not supported because exception blocks are not
  used.
  
  3.5.7.2 [No changes] Windows exception state
*************** used.
*** 253,279 ****
  3.5.8 Aborting a transaction
  ----------------------------
  
! '_ITM_rollbackTransaction' is not supported.  '_ITM_abortTransaction' is
! supported but the abort reasons 'exceptionBlockAbort', 'TMConflict', and
! 'userRetry' are not supported.  There are no exception blocks in
  general, so the related cases also do not have to be considered.  To
! encode '__transaction_cancel [[outer]]', compilers must set the new
! 'outerAbort' bit ('0x10') additionally to the 'userAbort' bit in the
  abort reason.
  
  3.5.9 Committing a transaction
  ------------------------------
  
  The exception handling (EH) scheme is different.  The Intel ABI requires
! the '_ITM_tryCommitTransaction' function that will return even when the
  commit failed and will have to be matched with calls to either
! '_ITM_abortTransaction' or '_ITM_commitTransaction'.  In contrast, gcc
  relies on transactional wrappers for the functions of the Exception
  Handling ABI and on one additional commit function (shown below).  This
  allows the TM to keep track of EH internally and thus it does not have
  to embed the cleanup of EH state into the existing EH code in the
! program.  '_ITM_tryCommitTransaction' is not supported.
! '_ITM_commitTransactionToId' is also not supported because the
  propagation of thrown exceptions will not bypass commits of nested
  transactions.
  
--- 253,279 ----
  3.5.8 Aborting a transaction
  ----------------------------
  
! ‘_ITM_rollbackTransaction’ is not supported.  ‘_ITM_abortTransaction’ is
! supported but the abort reasons ‘exceptionBlockAbort’, ‘TMConflict’, and
! ‘userRetry’ are not supported.  There are no exception blocks in
  general, so the related cases also do not have to be considered.  To
! encode ‘__transaction_cancel [[outer]]’, compilers must set the new
! ‘outerAbort’ bit (‘0x10’) additionally to the ‘userAbort’ bit in the
  abort reason.
  
  3.5.9 Committing a transaction
  ------------------------------
  
  The exception handling (EH) scheme is different.  The Intel ABI requires
! the ‘_ITM_tryCommitTransaction’ function that will return even when the
  commit failed and will have to be matched with calls to either
! ‘_ITM_abortTransaction’ or ‘_ITM_commitTransaction’.  In contrast, gcc
  relies on transactional wrappers for the functions of the Exception
  Handling ABI and on one additional commit function (shown below).  This
  allows the TM to keep track of EH internally and thus it does not have
  to embed the cleanup of EH state into the existing EH code in the
! program.  ‘_ITM_tryCommitTransaction’ is not supported.
! ‘_ITM_commitTransactionToId’ is also not supported because the
  propagation of thrown exceptions will not bypass commits of nested
  transactions.
  
*************** transactions.
*** 285,328 ****
       void _ITM_cxa_end_catch (void);
  
     The EH scheme changed in version 6 of GCC. Previously, the compiler
! added a call to '_ITM_commitTransactionEH' to commit a transaction if an
! exception could be in flight at this position in the code; 'exc_ptr' is
  the address of the current exception and must be non-zero.  Now, the
  compiler must catch all exceptions that are about to be thrown out of a
! transaction and call '_ITM_commitTransactionEH' from the catch clause,
! with 'exc_ptr' being zero.
  
     Note that the old EH scheme never worked completely in GCC's
  implementation; libitm currently does not try to be compatible with the
  old scheme.
  
!    The '_ITM_cxa...' functions are transactional wrappers for the
! respective '__cxa...' functions and must be called instead of these in
! transactional code.  '_ITM_cxa_free_exception' is new in GCC 6.
  
     To support this EH scheme, libstdc++ needs to provide one additional
! function ('_cxa_tm_cleanup'), which is used by the TM to clean up the
  exception handling state while rolling back a transaction:
  
       void __cxa_tm_cleanup (void *unthrown_obj, void *cleanup_exc,
                              unsigned int caught_count);
  
!    Since GCC 6, 'unthrown_obj' is not used anymore and always null;
! prior to that, 'unthrown_obj' is non-null if the program called
! '__cxa_allocate_exception' for this exception but did not yet called
! '__cxa_throw' for it.  'cleanup_exc' is non-null if the program is
  currently processing a cleanup along an exception path but has not
! caught this exception yet.  'caught_count' is the nesting depth of
! '__cxa_begin_catch' within the transaction (which can be counted by the
! TM using '_ITM_cxa_begin_catch' and '_ITM_cxa_end_catch');
! '__cxa_tm_cleanup' then performs rollback by essentially performing
! '__cxa_end_catch' that many times.
  
  3.5.10 Exception handling support
  ---------------------------------
  
  Currently, there is no support for functionality like
! '__transaction_cancel throw' as described in the C++ TM specification.
  Supporting this should be possible with the EH scheme explained
  previously because via the transactional wrappers for the EH ABI, the TM
  is able to observe and intercept EH.
--- 285,328 ----
       void _ITM_cxa_end_catch (void);
  
     The EH scheme changed in version 6 of GCC. Previously, the compiler
! added a call to ‘_ITM_commitTransactionEH’ to commit a transaction if an
! exception could be in flight at this position in the code; ‘exc_ptr’ is
  the address of the current exception and must be non-zero.  Now, the
  compiler must catch all exceptions that are about to be thrown out of a
! transaction and call ‘_ITM_commitTransactionEH’ from the catch clause,
! with ‘exc_ptr’ being zero.
  
     Note that the old EH scheme never worked completely in GCC's
  implementation; libitm currently does not try to be compatible with the
  old scheme.
  
!    The ‘_ITM_cxa...’ functions are transactional wrappers for the
! respective ‘__cxa...’ functions and must be called instead of these in
! transactional code.  ‘_ITM_cxa_free_exception’ is new in GCC 6.
  
     To support this EH scheme, libstdc++ needs to provide one additional
! function (‘_cxa_tm_cleanup’), which is used by the TM to clean up the
  exception handling state while rolling back a transaction:
  
       void __cxa_tm_cleanup (void *unthrown_obj, void *cleanup_exc,
                              unsigned int caught_count);
  
!    Since GCC 6, ‘unthrown_obj’ is not used anymore and always null;
! prior to that, ‘unthrown_obj’ is non-null if the program called
! ‘__cxa_allocate_exception’ for this exception but did not yet called
! ‘__cxa_throw’ for it.  ‘cleanup_exc’ is non-null if the program is
  currently processing a cleanup along an exception path but has not
! caught this exception yet.  ‘caught_count’ is the nesting depth of
! ‘__cxa_begin_catch’ within the transaction (which can be counted by the
! TM using ‘_ITM_cxa_begin_catch’ and ‘_ITM_cxa_end_catch’);
! ‘__cxa_tm_cleanup’ then performs rollback by essentially performing
! ‘__cxa_end_catch’ that many times.
  
  3.5.10 Exception handling support
  ---------------------------------
  
  Currently, there is no support for functionality like
! ‘__transaction_cancel throw’ as described in the C++ TM specification.
  Supporting this should be possible with the EH scheme explained
  previously because via the transactional wrappers for the EH ABI, the TM
  is able to observe and intercept EH.
*************** is able to observe and intercept EH.
*** 341,347 ****
  
  If either the source or destination memory region is to be accessed
  nontransactionally, then source and destination regions must not be
! overlapping.  The respective '_ITM_memmove' functions are still
  available but a fatal runtime error will be raised if such regions do
  overlap.  To support this functionality, the ABI would have to specify
  how the intersection of the regions has to be accessed (i.e.,
--- 341,347 ----
  
  If either the source or destination memory region is to be accessed
  nontransactionally, then source and destination regions must not be
! overlapping.  The respective ‘_ITM_memmove’ functions are still
  available but a fatal runtime error will be raised if such regions do
  overlap.  To support this functionality, the ABI would have to specify
  how the intersection of the regions has to be accessed (i.e.,
*************** transactionally or nontransactionally).
*** 357,378 ****
  ----------------------------------------------
  
  Commit actions will get executed in the same order in which the
! respective calls to '_ITM_addUserCommitAction' happened.  Only
! '_ITM_noTransactionId' is allowed as value for the
! 'resumingTransactionId' argument.  Commit actions get executed after
  privatization safety has been ensured.
  
     Undo actions will get executed in reverse order compared to the order
! in which the respective calls to '_ITM_addUserUndoAction' happened.  The
  ordering of undo actions w.r.t.  the roll-back of other actions (e.g.,
  data transfers or memory allocations) is undefined.
  
!    '_ITM_getThreadnum' is not supported currently because its only
  purpose is to provide a thread ID that matches some assumed performance
  tuning output, but this output is not part of the ABI nor further
  defined by it.
  
!    '_ITM_dropReferences' is not supported currently because its
  semantics and the intention behind it is not entirely clear.  The
  specification suggests that this function is necessary because of
  certain orderings of data transfer undos and the releasing of memory
--- 357,378 ----
  ----------------------------------------------
  
  Commit actions will get executed in the same order in which the
! respective calls to ‘_ITM_addUserCommitAction’ happened.  Only
! ‘_ITM_noTransactionId’ is allowed as value for the
! ‘resumingTransactionId’ argument.  Commit actions get executed after
  privatization safety has been ensured.
  
     Undo actions will get executed in reverse order compared to the order
! in which the respective calls to ‘_ITM_addUserUndoAction’ happened.  The
  ordering of undo actions w.r.t.  the roll-back of other actions (e.g.,
  data transfers or memory allocations) is undefined.
  
!    ‘_ITM_getThreadnum’ is not supported currently because its only
  purpose is to provide a thread ID that matches some assumed performance
  tuning output, but this output is not part of the ABI nor further
  defined by it.
  
!    ‘_ITM_dropReferences’ is not supported currently because its
  semantics and the intention behind it is not entirely clear.  The
  specification suggests that this function is necessary because of
  certain orderings of data transfer undos and the releasing of memory
*************** live throughout the life-time of the TM
*** 401,407 ****
  
     *TODO* The intention was always to drop the registration functions
  entirely, and create a new ELF Phdr describing the linker-sorted table.
! Much like what currently happens for 'PT_GNU_EH_FRAME'.  This work kept
  getting bogged down in how to represent the N different code generation
  variants.  We clearly needed at least two--SW and HW transactional
  clones--but there was always a suggestion of more variants for different
--- 401,407 ----
  
     *TODO* The intention was always to drop the registration functions
  entirely, and create a new ELF Phdr describing the linker-sorted table.
! Much like what currently happens for ‘PT_GNU_EH_FRAME’.  This work kept
  getting bogged down in how to represent the N different code generation
  variants.  We clearly needed at least two--SW and HW transactional
  clones--but there was always a suggestion of more variants for different
*************** pointer, whereas the second will raise a
*** 426,433 ****
              __attribute__((__malloc__)) ITM_PURE;
       void _ITM_free (void *) ITM_PURE;
  
!    These functions are essentially transactional wrappers for 'malloc',
! 'calloc', and 'free'.  Within transactions, the compiler should replace
  calls to the original functions with calls to the wrapper functions.
  
     libitm also provides transactional clones of C++ memory management
--- 426,433 ----
              __attribute__((__malloc__)) ITM_PURE;
       void _ITM_free (void *) ITM_PURE;
  
!    These functions are essentially transactional wrappers for ‘malloc’,
! ‘calloc’, and ‘free’.  Within transactions, the compiler should replace
  calls to the original functions with calls to the wrapper functions.
  
     libitm also provides transactional clones of C++ memory management
*************** File: libitm.info,  Node: Internals,  Ne
*** 469,482 ****
  
  libitm supports several ways of synchronizing transactions with each
  other.  These TM methods (or TM algorithms) are implemented in the form
! of subclasses of 'abi_dispatch', which provide methods for transactional
  loads and stores as well as callbacks for rollback and commit.  All
  methods that are compatible with each other (i.e., that let concurrently
  running transactions still synchronize correctly even if different
  methods are used) belong to the same TM method group.  Pointers to TM
  methods can be obtained using the factory methods prefixed with
! 'dispatch_' in 'libitm_i.h'.  There are two special methods,
! 'dispatch_serial' and 'dispatch_serialirr', that are compatible with all
  methods because they run transactions completely in serial mode.
  
  4.1.1 TM method life cycle
--- 469,482 ----
  
  libitm supports several ways of synchronizing transactions with each
  other.  These TM methods (or TM algorithms) are implemented in the form
! of subclasses of ‘abi_dispatch’, which provide methods for transactional
  loads and stores as well as callbacks for rollback and commit.  All
  methods that are compatible with each other (i.e., that let concurrently
  running transactions still synchronize correctly even if different
  methods are used) belong to the same TM method group.  Pointers to TM
  methods can be obtained using the factory methods prefixed with
! ‘dispatch_’ in ‘libitm_i.h’.  There are two special methods,
! ‘dispatch_serial’ and ‘dispatch_serialirr’, that are compatible with all
  methods because they run transactions completely in serial mode.
  
  4.1.1 TM method life cycle
*************** methods because they run transactions co
*** 484,508 ****
  
  The state of TM methods does not change after construction, but they do
  alter the state of transactions that use this method.  However, because
! per-transaction data gets used by several methods, 'gtm_thread' is
  responsible for setting an initial state that is useful for all methods.
  After that, methods are responsible for resetting/clearing this state on
  each rollback or commit (of outermost transactions), so that the
  transaction executed next is not affected by the previous transaction.
  
     There is also global state associated with each method group, which
! is initialized and shut down ('method_group::init()' and 'fini()') when
! switching between method groups (see 'retry.cc').
  
  4.1.2 Selecting the default method
  ----------------------------------
  
  The default method that libitm uses for freshly started transactions
  (but not necessarily for restarted transactions) can be set via an
! environment variable ('ITM_DEFAULT_METHOD'), whose value should be equal
  to the name of one of the factory methods returning abi_dispatch
  subclasses but without the "dispatch_" prefix (e.g., "serialirr" instead
! of 'GTM::dispatch_serialirr()').
  
     Note that this environment variable is only a hint for libitm and
  might not be supported in the future.
--- 484,508 ----
  
  The state of TM methods does not change after construction, but they do
  alter the state of transactions that use this method.  However, because
! per-transaction data gets used by several methods, ‘gtm_thread’ is
  responsible for setting an initial state that is useful for all methods.
  After that, methods are responsible for resetting/clearing this state on
  each rollback or commit (of outermost transactions), so that the
  transaction executed next is not affected by the previous transaction.
  
     There is also global state associated with each method group, which
! is initialized and shut down (‘method_group::init()’ and ‘fini()’) when
! switching between method groups (see ‘retry.cc’).
  
  4.1.2 Selecting the default method
  ----------------------------------
  
  The default method that libitm uses for freshly started transactions
  (but not necessarily for restarted transactions) can be set via an
! environment variable (‘ITM_DEFAULT_METHOD’), whose value should be equal
  to the name of one of the factory methods returning abi_dispatch
  subclasses but without the "dispatch_" prefix (e.g., "serialirr" instead
! of ‘GTM::dispatch_serialirr()’).
  
     Note that this environment variable is only a hint for libitm and
  might not be supported in the future.
*************** independently of the enclosing transacti
*** 522,528 ****
  
     Flat nesting is the default nesting mode, but closed nesting is
  supported and used when transactions contain user-controlled aborts
! ('__transaction_cancel' statements).  We assume that user-controlled
  aborts are rare in typical code and used mostly in exceptional
  situations.  Thus, it makes more sense to use flat nesting by default to
  avoid the performance overhead of the additional checkpoints required
--- 522,528 ----
  
     Flat nesting is the default nesting mode, but closed nesting is
  supported and used when transactions contain user-controlled aborts
! (‘__transaction_cancel’ statements).  We assume that user-controlled
  aborts are rare in typical code and used mostly in exceptional
  situations.  Thus, it makes more sense to use flat nesting by default to
  avoid the performance overhead of the additional checkpoints required
*************** public/shared part of a transaction obje
*** 578,587 ****
  method-group-specific state.
  
     The former category (protected by the serial lock) includes:
!    * The list of active threads that have used transactions.
!    * The tables that map functions to their transactional clones.
!    * The current selection of which method group to use.
!    * Some method-group-specific data, or invariants of this data.  For
       example, resetting a method group to its initial state is handled
       by switching to the same method group, so the serial lock protects
       such resetting as well.
--- 578,587 ----
  method-group-specific state.
  
     The former category (protected by the serial lock) includes:
!    • The list of active threads that have used transactions.
!    • The tables that map functions to their transactional clones.
!    • The current selection of which method group to use.
!    • Some method-group-specific data, or invariants of this data.  For
       example, resetting a method group to its initial state is handled
       by switching to the same method group, so the serial lock protects
       such resetting as well.
*************** also not released before commit.
*** 606,629 ****
  
     Lock acquisition / blocking rules:
  
!    * Transactions must become active or serial before they are allowed
       to use method-group-specific locks or blocking (i.e., the serial
       lock must be acquired before those other locks, either in serial or
       nonserial mode).
  
!    * Any number of threads that do not currently run active transactions
       can block while trying to get the serial lock in exclusive mode.
       Note that active transactions must not block when trying to upgrade
       to serial mode unless there is no other transaction that is trying
       that (the latter is ensured by the serial lock implementation.
  
!    * Method groups must prevent deadlocks on their locks.  In
       particular, they must also be prepared for another active
       transaction that has acquired method-group-specific locks but is
       blocked during an attempt to upgrade to being a serial transaction.
       See below for details.
  
!    * Serial transactions can acquire method-group-specific locks because
       there will be no other active nor serial transaction.
  
     There is no single rule for per-method-group blocking because this
--- 606,629 ----
  
     Lock acquisition / blocking rules:
  
!    • Transactions must become active or serial before they are allowed
       to use method-group-specific locks or blocking (i.e., the serial
       lock must be acquired before those other locks, either in serial or
       nonserial mode).
  
!    • Any number of threads that do not currently run active transactions
       can block while trying to get the serial lock in exclusive mode.
       Note that active transactions must not block when trying to upgrade
       to serial mode unless there is no other transaction that is trying
       that (the latter is ensured by the serial lock implementation.
  
!    • Method groups must prevent deadlocks on their locks.  In
       particular, they must also be prepared for another active
       transaction that has acquired method-group-specific locks but is
       blocked during an attempt to upgrade to being a serial transaction.
       See below for details.
  
!    • Serial transactions can acquire method-group-specific locks because
       there will be no other active nor serial transaction.
  
     There is no single rule for per-method-group blocking because this
*************** to consider a potential deadlock due to
*** 635,649 ****
  
     If there can be upgrades to serial mode after the acquisition of
  per-method-group locks, then TM methods need to avoid those deadlocks:
!    * When upgrading to a serial transaction, after acquiring exclusive
       rights to the serial lock but before waiting for concurrent active
       transactions to finish (*note Serial lock implementation:
       serial-lock-impl. for details), we have to wake up all active
       transactions waiting on the upgrader's per-method-group locks.
!    * Active transactions blocking on per-method-group locks need to
       check the serial lock and abort if there is a pending serial
       transaction.
!    * Lost wake-ups have to be prevented (e.g., by changing a bit in each
       per-method-group lock before doing the wake-up, and only blocking
       on this lock using a futex if this bit is not group).
  
--- 635,649 ----
  
     If there can be upgrades to serial mode after the acquisition of
  per-method-group locks, then TM methods need to avoid those deadlocks:
!    • When upgrading to a serial transaction, after acquiring exclusive
       rights to the serial lock but before waiting for concurrent active
       transactions to finish (*note Serial lock implementation:
       serial-lock-impl. for details), we have to wake up all active
       transactions waiting on the upgrader's per-method-group locks.
!    • Active transactions blocking on per-method-group locks need to
       check the serial lock and abort if there is a pending serial
       transaction.
!    • Lost wake-ups have to be prevented (e.g., by changing a bit in each
       per-method-group lock before doing the wake-up, and only blocking
       on this lock using a futex if this bit is not group).
  
*************** serial lock (read-to-write upgrade is si
*** 700,707 ****
       if (need_blocking) goto slowpath;
  
     Releasing a lock in this spin-lock version then just consists of
! resetting 'tx->shared_state' to inactive or clearing
! 'serial_lock.exclusive'.
  
     However, we can't rely on a pure spinlock because we need to get the
  OS involved at some time (e.g., when there are more threads than CPUs to
--- 700,707 ----
       if (need_blocking) goto slowpath;
  
     Releasing a lock in this spin-lock version then just consists of
! resetting ‘tx->shared_state’ to inactive or clearing
! ‘serial_lock.exclusive’.
  
     However, we can't rely on a pure spinlock because we need to get the
  OS involved at some time (e.g., when there are more threads than CPUs to
*************** slow path, either based on pthread mutex
*** 713,730 ****
  
  libitm has to consider the following cases of reentrancy:
  
!    * Transaction calls unsafe code that starts a new transaction: The
       outer transaction will become a serial transaction before executing
       unsafe code.  Therefore, nesting within serial transactions must
       work, even if the nested transaction is called from within
       uninstrumented code.
  
!    * Transaction calls either a transactional wrapper or safe code,
       which in turn starts a new transaction: It is not yet defined in
       the specification whether this is allowed.  Thus, it is undefined
       whether libitm supports this.
  
!    * Code that starts new transactions might be called from within any
       part of libitm: This kind of reentrancy would likely be rather
       complex and can probably be avoided.  Therefore, it is not
       supported.
--- 713,730 ----
  
  libitm has to consider the following cases of reentrancy:
  
!    • Transaction calls unsafe code that starts a new transaction: The
       outer transaction will become a serial transaction before executing
       unsafe code.  Therefore, nesting within serial transactions must
       work, even if the nested transaction is called from within
       uninstrumented code.
  
!    • Transaction calls either a transactional wrapper or safe code,
       which in turn starts a new transaction: It is not yet defined in
       the specification whether this is allowed.  Thus, it is undefined
       whether libitm supports this.
  
!    • Code that starts new transactions might be called from within any
       part of libitm: This kind of reentrancy would likely be rather
       complex and can probably be avoided.  Therefore, it is not
       supported.
*************** GNU Free Documentation License
*** 804,810 ****
  
                       Version 1.3, 3 November 2008
  
!      Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
--- 804,810 ----
  
                       Version 1.3, 3 November 2008
  
!      Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
*************** GNU Free Documentation License
*** 813,819 ****
    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
--- 813,819 ----
    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
*************** Library Index
*** 1294,1309 ****
  
  
  Tag Table:
! Node: Top1141
! Node: Enabling libitm2045
! Node: C/C++ Language Constructs for TM2440
! Node: The libitm ABI3923
! Ref: txn-code-properties7721
! Node: Internals18814
! Ref: serial-lock-impl28852
! Ref: progress-guarantees33613
! Node: GNU Free Documentation License35891
! Node: Library Index61026
  
  End Tag Table
  
--- 1294,1309 ----
  
  
  Tag Table:
! Node: Top1139
! Node: Enabling libitm2043
! Node: C/C++ Language Constructs for TM2446
! Node: The libitm ABI3949
! Ref: txn-code-properties7763
! Node: Internals19080
! Ref: serial-lock-impl29188
! Ref: progress-guarantees33963
! Node: GNU Free Documentation License36241
! Node: Library Index61379
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/libphobos/ChangeLog gcc-13.5.0-RC-20260904/libphobos/ChangeLog
*** gcc-13.4.0/libphobos/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/libphobos/ChangeLog	Fri Sep  4 07:35:12 2026
***************
*** 1,3 ****
--- 1,22 ----
+ 2025-09-07  Sam James  
+ 
+ 	Backported from master:
+ 	2025-09-07  Sam James  
+ 
+ 	* configure.tgt: Add hppa[12]*-*-linux* as a supported target.
+ 
+ 2025-09-07  Sam James  
+ 
+ 	Backported from master:
+ 	2025-05-06  Sam James  
+ 
+ 	* configure.tgt: Add sparc64-unknown-linux-gnu as a supported target.
+ 
+ 2025-09-07  Matthias Klose  
+ 
+ 	* configure.tgt: Add powerpc64le--linux-gnu as a supported target
+ 	when configured with --with-long-double-format=ieee.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/libphobos/configure.tgt gcc-13.5.0-RC-20260904/libphobos/configure.tgt
*** gcc-13.4.0/libphobos/configure.tgt	Thu Jun  5 16:03:02 2025
--- gcc-13.5.0-RC-20260904/libphobos/configure.tgt	Fri Sep  4 07:35:12 2026
*************** case "${target}" in
*** 36,42 ****
    arm*-*-linux*)
  	LIBPHOBOS_SUPPORTED=yes
  	;;
!   hppa-*-linux*)
  	LIBPHOBOS_SUPPORTED=yes
  	;;
    mips*-*-linux*)
--- 36,42 ----
    arm*-*-linux*)
  	LIBPHOBOS_SUPPORTED=yes
  	;;
!   hppa-*-linux* | hppa[12]*-*-linux*)
  	LIBPHOBOS_SUPPORTED=yes
  	;;
    mips*-*-linux*)
*************** case "${target}" in
*** 45,50 ****
--- 45,59 ----
    power*-*-freebsd*)
  	LIBPHOBOS_SUPPORTED=yes
  	;;
+   powerpc64le-*linux*)
+ 	LIBPHOBOS_SUPPORTED=yes
+ 	case "$ac_configure_args" in
+ 	  *--with-long-double-format=ieee*)
+ 	    ;;
+ 	  *)
+ 	    LIBDRUNTIME_ONLY=yes
+ 	esac
+ 	;;
    power*-*-linux*)
  	LIBPHOBOS_SUPPORTED=yes
  	LIBDRUNTIME_ONLY=yes
*************** case "${target}" in
*** 55,61 ****
    s390*-linux*)
  	LIBPHOBOS_SUPPORTED=yes
  	;;
!   sparc*-*-solaris2.11*)
  	LIBPHOBOS_SUPPORTED=yes
  	;;
    *-*-darwin9* | *-*-darwin1[01]*)
--- 64,70 ----
    s390*-linux*)
  	LIBPHOBOS_SUPPORTED=yes
  	;;
!   sparc64-*-linux* | sparc*-*-solaris2.11*)
  	LIBPHOBOS_SUPPORTED=yes
  	;;
    *-*-darwin9* | *-*-darwin1[01]*)
diff -Nrcpad gcc-13.4.0/libquadmath/libquadmath.info gcc-13.5.0-RC-20260904/libquadmath/libquadmath.info
*** gcc-13.4.0/libquadmath/libquadmath.info	Thu Jun  5 16:28:32 2025
--- gcc-13.5.0-RC-20260904/libquadmath/libquadmath.info	Fri Sep  4 07:56:11 2026
***************
*** 1,7 ****
! This is libquadmath.info, produced by makeinfo version 6.8 from
  libquadmath.texi.
  
! Copyright (C) 2010-2023 Free Software Foundation, Inc.
  
       Permission is granted to copy, distribute and/or modify this
       document under the terms of the GNU Free Documentation License,
--- 1,7 ----
! This is libquadmath.info, produced by makeinfo version 7.1 from
  libquadmath.texi.
  
! Copyright © 2010-2023 Free Software Foundation, Inc.
  
       Permission is granted to copy, distribute and/or modify this
       document under the terms of the GNU Free Documentation License,
*************** END-INFO-DIR-ENTRY
*** 23,29 ****
     Published by the Free Software Foundation 51 Franklin Street, Fifth
  Floor Boston, MA 02110-1301 USA
  
!    Copyright (C) 2010-2023 Free Software Foundation, Inc.
  
       Permission is granted to copy, distribute and/or modify this
       document under the terms of the GNU Free Documentation License,
--- 23,29 ----
     Published by the Free Software Foundation 51 Franklin Street, Fifth
  Floor Boston, MA 02110-1301 USA
  
!    Copyright © 2010-2023 Free Software Foundation, Inc.
  
       Permission is granted to copy, distribute and/or modify this
       document under the terms of the GNU Free Documentation License,
*************** File: libquadmath.info,  Node: Typedef a
*** 62,102 ****
  1 Typedef and constants
  ***********************
  
! The following data type has been defined via 'typedef'.
  
! '__complex128': '__float128'-based complex number
  
     The following macros are defined, which give the numeric limits of
! the '__float128' data type.
  
! 'FLT128_MAX': largest finite number
! 'FLT128_MIN': smallest positive number with full precision
! 'FLT128_EPSILON': difference between 1 and the next larger
       representable number
! 'FLT128_DENORM_MIN': smallest positive denormalized number
! 'FLT128_MANT_DIG': number of digits in the mantissa (bit precision)
! 'FLT128_MIN_EXP': maximal negative exponent
! 'FLT128_MAX_EXP': maximal positive exponent
! 'FLT128_DIG': number of decimal digits in the mantissa
! 'FLT128_MIN_10_EXP': maximal negative decimal exponent
! 'FLT128_MAX_10_EXP': maximal positive decimal exponent
  
!    The following mathematical constants of type '__float128' are
  defined.
  
! 'M_Eq': the constant e (Euler's number)
! 'M_LOG2Eq': binary logarithm of 2
! 'M_LOG10Eq': common, decimal logarithm of 2
! 'M_LN2q': natural logarithm of 2
! 'M_LN10q': natural logarithm of 10
! 'M_PIq': pi
! 'M_PI_2q': pi divided by two
! 'M_PI_4q': pi divided by four
! 'M_1_PIq': one over pi
! 'M_2_PIq': one over two pi
! 'M_2_SQRTPIq': two over square root of pi
! 'M_SQRT2q': square root of 2
! 'M_SQRT1_2q': one over square root of 2
  
  
  File: libquadmath.info,  Node: Math Library Routines,  Next: I/O Library Routines,  Prev: Typedef and constants,  Up: Top
--- 62,102 ----
  1 Typedef and constants
  ***********************
  
! The following data type has been defined via ‘typedef’.
  
! ‘__complex128’: ‘__float128’-based complex number
  
     The following macros are defined, which give the numeric limits of
! the ‘__float128’ data type.
  
! ‘FLT128_MAX’: largest finite number
! ‘FLT128_MIN’: smallest positive number with full precision
! ‘FLT128_EPSILON’: difference between 1 and the next larger
       representable number
! ‘FLT128_DENORM_MIN’: smallest positive denormalized number
! ‘FLT128_MANT_DIG’: number of digits in the mantissa (bit precision)
! ‘FLT128_MIN_EXP’: maximal negative exponent
! ‘FLT128_MAX_EXP’: maximal positive exponent
! ‘FLT128_DIG’: number of decimal digits in the mantissa
! ‘FLT128_MIN_10_EXP’: maximal negative decimal exponent
! ‘FLT128_MAX_10_EXP’: maximal positive decimal exponent
  
!    The following mathematical constants of type ‘__float128’ are
  defined.
  
! ‘M_Eq’: the constant e (Euler's number)
! ‘M_LOG2Eq’: binary logarithm of 2
! ‘M_LOG10Eq’: common, decimal logarithm of 2
! ‘M_LN2q’: natural logarithm of 2
! ‘M_LN10q’: natural logarithm of 10
! ‘M_PIq’: pi
! ‘M_PI_2q’: pi divided by two
! ‘M_PI_4q’: pi divided by four
! ‘M_1_PIq’: one over pi
! ‘M_2_PIq’: one over two pi
! ‘M_2_SQRTPIq’: two over square root of pi
! ‘M_SQRT2q’: square root of 2
! ‘M_SQRT1_2q’: one over square root of 2
  
  
  File: libquadmath.info,  Node: Math Library Routines,  Next: I/O Library Routines,  Prev: Typedef and constants,  Up: Top
*************** File: libquadmath.info,  Node: Math Libr
*** 106,204 ****
  
  The following mathematical functions are available:
  
! 'acosq': arc cosine function
! 'acoshq': inverse hyperbolic cosine function
! 'asinq': arc sine function
! 'asinhq': inverse hyperbolic sine function
! 'atanq': arc tangent function
! 'atanhq': inverse hyperbolic tangent function
! 'atan2q': arc tangent function
! 'cbrtq': cube root function
! 'ceilq': ceiling value function
! 'copysignq': copy sign of a number
! 'coshq': hyperbolic cosine function
! 'cosq': cosine function
! 'erfq': error function
! 'erfcq': complementary error function
! 'exp2q': base 2 exponential function
! 'expq': exponential function
! 'expm1q': exponential minus 1 function
! 'fabsq': absolute value function
! 'fdimq': positive difference function
! 'finiteq': check finiteness of value
! 'floorq': floor value function
! 'fmaq': fused multiply and add
! 'fmaxq': determine maximum of two values
! 'fminq': determine minimum of two values
! 'fmodq': remainder value function
! 'frexpq': extract mantissa and exponent
! 'hypotq': Eucledian distance function
! 'ilogbq': get exponent of the value
! 'isinfq': check for infinity
! 'isnanq': check for not a number
! 'issignalingq': check for signaling not a number
! 'j0q': Bessel function of the first kind, first order
! 'j1q': Bessel function of the first kind, second order
! 'jnq': Bessel function of the first kind, N-th order
! 'ldexpq': load exponent of the value
! 'lgammaq': logarithmic gamma function
! 'llrintq': round to nearest integer value
! 'llroundq': round to nearest integer value away from zero
! 'logbq': get exponent of the value
! 'logq': natural logarithm function
! 'log10q': base 10 logarithm function
! 'log1pq': compute natural logarithm of the value plus one
! 'log2q': base 2 logarithm function
! 'lrintq': round to nearest integer value
! 'lroundq': round to nearest integer value away from zero
! 'modfq': decompose the floating-point number
! 'nanq': return quiet NaN
! 'nearbyintq': round to nearest integer
! 'nextafterq': next representable floating-point number
! 'powq': power function
! 'remainderq': remainder function
! 'remquoq': remainder and part of quotient
! 'rintq': round-to-nearest integral value
! 'roundq': round-to-nearest integral value, return '__float128'
! 'scalblnq': compute exponent using 'FLT_RADIX'
! 'scalbnq': compute exponent using 'FLT_RADIX'
! 'signbitq': return sign bit
! 'sincosq': calculate sine and cosine simultaneously
! 'sinhq': hyperbolic sine function
! 'sinq': sine function
! 'sqrtq': square root function
! 'tanq': tangent function
! 'tanhq': hyperbolic tangent function
! 'tgammaq': true gamma function
! 'truncq': round to integer, towards zero
! 'y0q': Bessel function of the second kind, first order
! 'y1q': Bessel function of the second kind, second order
! 'ynq': Bessel function of the second kind, N-th order
! 'cabsq' complex absolute value function
! 'cargq': calculate the argument
! 'cimagq' imaginary part of complex number
! 'crealq': real part of complex number
! 'cacoshq': complex arc hyperbolic cosine function
! 'cacosq': complex arc cosine function
! 'casinhq': complex arc hyperbolic sine function
! 'casinq': complex arc sine function
! 'catanhq': complex arc hyperbolic tangent function
! 'catanq': complex arc tangent function
! 'ccosq' complex cosine function:
! 'ccoshq': complex hyperbolic cosine function
! 'cexpq': complex exponential function
! 'cexpiq': computes the exponential function of "i" times a
       real value
! 'clogq': complex natural logarithm
! 'clog10q': complex base 10 logarithm
! 'conjq': complex conjugate function
! 'cpowq': complex power function
! 'cprojq': project into Riemann Sphere
! 'csinq': complex sine function
! 'csinhq': complex hyperbolic sine function
! 'csqrtq': complex square root
! 'ctanq': complex tangent function
! 'ctanhq': complex hyperbolic tangent function
  
  
  File: libquadmath.info,  Node: I/O Library Routines,  Next: GNU Free Documentation License,  Prev: Math Library Routines,  Up: Top
--- 106,204 ----
  
  The following mathematical functions are available:
  
! ‘acosq’: arc cosine function
! ‘acoshq’: inverse hyperbolic cosine function
! ‘asinq’: arc sine function
! ‘asinhq’: inverse hyperbolic sine function
! ‘atanq’: arc tangent function
! ‘atanhq’: inverse hyperbolic tangent function
! ‘atan2q’: arc tangent function
! ‘cbrtq’: cube root function
! ‘ceilq’: ceiling value function
! ‘copysignq’: copy sign of a number
! ‘coshq’: hyperbolic cosine function
! ‘cosq’: cosine function
! ‘erfq’: error function
! ‘erfcq’: complementary error function
! ‘exp2q’: base 2 exponential function
! ‘expq’: exponential function
! ‘expm1q’: exponential minus 1 function
! ‘fabsq’: absolute value function
! ‘fdimq’: positive difference function
! ‘finiteq’: check finiteness of value
! ‘floorq’: floor value function
! ‘fmaq’: fused multiply and add
! ‘fmaxq’: determine maximum of two values
! ‘fminq’: determine minimum of two values
! ‘fmodq’: remainder value function
! ‘frexpq’: extract mantissa and exponent
! ‘hypotq’: Eucledian distance function
! ‘ilogbq’: get exponent of the value
! ‘isinfq’: check for infinity
! ‘isnanq’: check for not a number
! ‘issignalingq’: check for signaling not a number
! ‘j0q’: Bessel function of the first kind, first order
! ‘j1q’: Bessel function of the first kind, second order
! ‘jnq’: Bessel function of the first kind, N-th order
! ‘ldexpq’: load exponent of the value
! ‘lgammaq’: logarithmic gamma function
! ‘llrintq’: round to nearest integer value
! ‘llroundq’: round to nearest integer value away from zero
! ‘logbq’: get exponent of the value
! ‘logq’: natural logarithm function
! ‘log10q’: base 10 logarithm function
! ‘log1pq’: compute natural logarithm of the value plus one
! ‘log2q’: base 2 logarithm function
! ‘lrintq’: round to nearest integer value
! ‘lroundq’: round to nearest integer value away from zero
! ‘modfq’: decompose the floating-point number
! ‘nanq’: return quiet NaN
! ‘nearbyintq’: round to nearest integer
! ‘nextafterq’: next representable floating-point number
! ‘powq’: power function
! ‘remainderq’: remainder function
! ‘remquoq’: remainder and part of quotient
! ‘rintq’: round-to-nearest integral value
! ‘roundq’: round-to-nearest integral value, return ‘__float128’
! ‘scalblnq’: compute exponent using ‘FLT_RADIX’
! ‘scalbnq’: compute exponent using ‘FLT_RADIX’
! ‘signbitq’: return sign bit
! ‘sincosq’: calculate sine and cosine simultaneously
! ‘sinhq’: hyperbolic sine function
! ‘sinq’: sine function
! ‘sqrtq’: square root function
! ‘tanq’: tangent function
! ‘tanhq’: hyperbolic tangent function
! ‘tgammaq’: true gamma function
! ‘truncq’: round to integer, towards zero
! ‘y0q’: Bessel function of the second kind, first order
! ‘y1q’: Bessel function of the second kind, second order
! ‘ynq’: Bessel function of the second kind, N-th order
! ‘cabsq’ complex absolute value function
! ‘cargq’: calculate the argument
! ‘cimagq’ imaginary part of complex number
! ‘crealq’: real part of complex number
! ‘cacoshq’: complex arc hyperbolic cosine function
! ‘cacosq’: complex arc cosine function
! ‘casinhq’: complex arc hyperbolic sine function
! ‘casinq’: complex arc sine function
! ‘catanhq’: complex arc hyperbolic tangent function
! ‘catanq’: complex arc tangent function
! ‘ccosq’ complex cosine function:
! ‘ccoshq’: complex hyperbolic cosine function
! ‘cexpq’: complex exponential function
! ‘cexpiq’: computes the exponential function of "i" times a
       real value
! ‘clogq’: complex natural logarithm
! ‘clog10q’: complex base 10 logarithm
! ‘conjq’: complex conjugate function
! ‘cpowq’: complex power function
! ‘cprojq’: project into Riemann Sphere
! ‘csinq’: complex sine function
! ‘csinhq’: complex hyperbolic sine function
! ‘csqrtq’: complex square root
! ‘ctanq’: complex tangent function
! ‘ctanhq’: complex hyperbolic tangent function
  
  
  File: libquadmath.info,  Node: I/O Library Routines,  Next: GNU Free Documentation License,  Prev: Math Library Routines,  Up: Top
*************** File: libquadmath.info,  Node: I/O Libra
*** 208,232 ****
  
  * Menu:
  
! * 'strtoflt128':          strtoflt128,          Convert from string
! * 'quadmath_snprintf':    quadmath_snprintf,    Convert to string
  
  
  File: libquadmath.info,  Node: strtoflt128,  Next: quadmath_snprintf,  Up: I/O Library Routines
  
! 3.1 'strtoflt128' -- Convert from string
  ========================================
  
! The function 'strtoflt128' converts a string into a '__float128' number.
  
  Syntax
!      '__float128 strtoflt128 (const char *s, char **sp)'
  
  _Arguments_:
       S           input string
       SP          the address of the next character in the string
  
!      The argument SP contains, if not 'NULL', the address of the next
       character following the parts of the string, which have been read.
  
  Example
--- 208,232 ----
  
  * Menu:
  
! * ‘strtoflt128’:          strtoflt128,          Convert from string
! * ‘quadmath_snprintf’:    quadmath_snprintf,    Convert to string
  
  
  File: libquadmath.info,  Node: strtoflt128,  Next: quadmath_snprintf,  Up: I/O Library Routines
  
! 3.1 ‘strtoflt128’ -- Convert from string
  ========================================
  
! The function ‘strtoflt128’ converts a string into a ‘__float128’ number.
  
  Syntax
!      ‘__float128 strtoflt128 (const char *s, char **sp)’
  
  _Arguments_:
       S           input string
       SP          the address of the next character in the string
  
!      The argument SP contains, if not ‘NULL’, the address of the next
       character following the parts of the string, which have been read.
  
  Example
*************** Example
*** 244,262 ****
  
  File: libquadmath.info,  Node: quadmath_snprintf,  Prev: strtoflt128,  Up: I/O Library Routines
  
! 3.2 'quadmath_snprintf' -- Convert to string
  ============================================
  
! The function 'quadmath_snprintf' converts a '__float128' floating-point
! number into a string.  It is a specialized alternative to 'snprintf',
  where the format string is restricted to a single conversion specifier
! with 'Q' modifier and conversion specifier 'e', 'E', 'f', 'F', 'g', 'G',
! 'a' or 'A', with no extra characters before or after the conversion
! specifier.  The '%m$' or '*m$' style must not be used in the format.
  
  Syntax
!      'int quadmath_snprintf (char *s, size_t size, const char *format,
!      ...)'
  
  _Arguments_:
       S           output string
--- 244,262 ----
  
  File: libquadmath.info,  Node: quadmath_snprintf,  Prev: strtoflt128,  Up: I/O Library Routines
  
! 3.2 ‘quadmath_snprintf’ -- Convert to string
  ============================================
  
! The function ‘quadmath_snprintf’ converts a ‘__float128’ floating-point
! number into a string.  It is a specialized alternative to ‘snprintf’,
  where the format string is restricted to a single conversion specifier
! with ‘Q’ modifier and conversion specifier ‘e’, ‘E’, ‘f’, ‘F’, ‘g’, ‘G’,
! ‘a’ or ‘A’, with no extra characters before or after the conversion
! specifier.  The ‘%m$’ or ‘*m$’ style must not be used in the format.
  
  Syntax
!      ‘int quadmath_snprintf (char *s, size_t size, const char *format,
!      ...)’
  
  _Arguments_:
       S           output string
*************** _Arguments_:
*** 265,271 ****
  
  Note
       On some targets when supported by the C library hooks are installed
!      for 'printf' family of functions, so that 'printf ("%Qe", 1.2Q);'
       etc. works too.
  
  Example
--- 265,271 ----
  
  Note
       On some targets when supported by the C library hooks are installed
!      for ‘printf’ family of functions, so that ‘printf ("%Qe", 1.2Q);’
       etc. works too.
  
  Example
*************** GNU Free Documentation License
*** 313,319 ****
  
                       Version 1.3, 3 November 2008
  
!      Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
--- 313,319 ----
  
                       Version 1.3, 3 November 2008
  
!      Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
       
  
       Everyone is permitted to copy and distribute verbatim copies
*************** GNU Free Documentation License
*** 322,328 ****
    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
--- 322,328 ----
    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
*************** reported via 
*** 799,812 ****
  
  
  Tag Table:
! Node: Top1633
! Node: Typedef and constants2367
! Node: Math Library Routines3786
! Node: I/O Library Routines7623
! Node: strtoflt1287948
! Node: quadmath_snprintf8708
! Node: GNU Free Documentation License10919
! Node: Reporting Bugs36071
  
  End Tag Table
  
--- 799,812 ----
  
  
  Tag Table:
! Node: Top1631
! Node: Typedef and constants2365
! Node: Math Library Routines3896
! Node: I/O Library Routines8113
! Node: strtoflt1288446
! Node: quadmath_snprintf9226
! Node: GNU Free Documentation License11509
! Node: Reporting Bugs36664
  
  End Tag Table
  
diff -Nrcpad gcc-13.4.0/libsanitizer/ChangeLog gcc-13.5.0-RC-20260904/libsanitizer/ChangeLog
*** gcc-13.4.0/libsanitizer/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/libsanitizer/ChangeLog	Fri Sep  4 07:35:12 2026
***************
*** 1,3 ****
--- 1,31 ----
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-07-20  Jakub Jelinek  
+ 
+ 	PR sanitizer/126307
+ 	* tsan/tsan_trace.h: Cherry-pick llvm-project revision
+ 	cdfdb06c9155080ec97d6e4f4dd90b6e7cefb0ca.
+ 
+ 2026-04-30  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-04-29  Jakub Jelinek  
+ 
+ 	* sanitizer_common/sanitizer_platform_limits_posix.cpp: Cherry picked
+ 	from LLVM commit 3dc4fd6dd41100f051a63642f449b16324389c96.
+ 
+ 2025-07-31  Florian Weimer  
+ 
+ 	Backported from master:
+ 	2025-05-02  Florian Weimer  
+ 		    Tom Stellard  
+ 
+ 	* sanitizer_common/sanitizer_common_interceptors_ioctl.inc: Cherry
+ 	picked from LLVM commit 59978b21ad9c65276ee8e14f26759691b8a65763.
+ 	* sanitizer_common/sanitizer_platform_limits_posix.cpp: Likewise.
+ 	* sanitizer_common/sanitizer_platform_limits_posix.h: Likewise.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc gcc-13.5.0-RC-20260904/libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc
*** gcc-13.4.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libsanitizer/sanitizer_common/sanitizer_common_interceptors_ioctl.inc	Fri Sep  4 07:35:12 2026
*************** static void ioctl_table_fill() {
*** 338,354 ****
    _(SOUND_PCM_WRITE_CHANNELS, WRITE, sizeof(int));
    _(SOUND_PCM_WRITE_FILTER, WRITE, sizeof(int));
    _(TCFLSH, NONE, 0);
- #if SANITIZER_GLIBC
-   _(TCGETA, WRITE, struct_termio_sz);
- #endif
    _(TCGETS, WRITE, struct_termios_sz);
    _(TCSBRK, NONE, 0);
    _(TCSBRKP, NONE, 0);
- #if SANITIZER_GLIBC
-   _(TCSETA, READ, struct_termio_sz);
-   _(TCSETAF, READ, struct_termio_sz);
-   _(TCSETAW, READ, struct_termio_sz);
- #endif
    _(TCSETS, READ, struct_termios_sz);
    _(TCSETSF, READ, struct_termios_sz);
    _(TCSETSW, READ, struct_termios_sz);
--- 338,346 ----
diff -Nrcpad gcc-13.4.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp gcc-13.5.0-RC-20260904/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp
*** gcc-13.4.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp	Fri Sep  4 07:35:12 2026
*************** typedef struct user_fpregs elf_fpregset_
*** 144,159 ****
  #if defined(__mips64)
  # include 
  #endif
! #include 
! #include 
! #include 
! #include 
! #include 
! #include 
! #include 
! #include 
! #include 
! #include 
  #endif  // SANITIZER_ANDROID
  
  #include 
--- 144,158 ----
  #if defined(__mips64)
  # include 
  #endif
! #      include 
! #      include 
! #      include 
! #      include 
! #      include 
! #      include 
! #      include 
! #      include 
! #      include 
  #endif  // SANITIZER_ANDROID
  
  #include 
*************** unsigned struct_ElfW_Phdr_sz = sizeof(El
*** 467,475 ****
    unsigned struct_input_id_sz = sizeof(struct input_id);
    unsigned struct_mtpos_sz = sizeof(struct mtpos);
    unsigned struct_rtentry_sz = sizeof(struct rtentry);
- #if SANITIZER_GLIBC || SANITIZER_ANDROID
-   unsigned struct_termio_sz = sizeof(struct termio);
- #endif
    unsigned struct_vt_consize_sz = sizeof(struct vt_consize);
    unsigned struct_vt_sizes_sz = sizeof(struct vt_sizes);
    unsigned struct_vt_stat_sz = sizeof(struct vt_stat);
--- 466,471 ----
*************** unsigned struct_ElfW_Phdr_sz = sizeof(El
*** 508,515 ****
    unsigned struct_kbsentry_sz = sizeof(struct kbsentry);
    unsigned struct_mtconfiginfo_sz = sizeof(struct mtconfiginfo);
    unsigned struct_nr_parms_struct_sz = sizeof(struct nr_parms_struct);
-   unsigned struct_scc_modem_sz = sizeof(struct scc_modem);
-   unsigned struct_scc_stat_sz = sizeof(struct scc_stat);
    unsigned struct_serial_multiport_struct_sz
        = sizeof(struct serial_multiport_struct);
    unsigned struct_serial_struct_sz = sizeof(struct serial_struct);
--- 504,509 ----
*************** unsigned struct_ElfW_Phdr_sz = sizeof(El
*** 746,758 ****
    unsigned IOCTL_SOUND_PCM_WRITE_FILTER = SOUND_PCM_WRITE_FILTER;
  #endif // SOUND_VERSION
    unsigned IOCTL_TCFLSH = TCFLSH;
-   unsigned IOCTL_TCGETA = TCGETA;
    unsigned IOCTL_TCGETS = TCGETS;
    unsigned IOCTL_TCSBRK = TCSBRK;
    unsigned IOCTL_TCSBRKP = TCSBRKP;
-   unsigned IOCTL_TCSETA = TCSETA;
-   unsigned IOCTL_TCSETAF = TCSETAF;
-   unsigned IOCTL_TCSETAW = TCSETAW;
    unsigned IOCTL_TCSETS = TCSETS;
    unsigned IOCTL_TCSETSF = TCSETSF;
    unsigned IOCTL_TCSETSW = TCSETSW;
--- 740,748 ----
diff -Nrcpad gcc-13.4.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h gcc-13.5.0-RC-20260904/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
*** gcc-13.4.0/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h	Fri Sep  4 07:35:12 2026
*************** extern unsigned struct_hd_geometry_sz;
*** 998,1004 ****
  extern unsigned struct_input_absinfo_sz;
  extern unsigned struct_input_id_sz;
  extern unsigned struct_mtpos_sz;
- extern unsigned struct_termio_sz;
  extern unsigned struct_vt_consize_sz;
  extern unsigned struct_vt_sizes_sz;
  extern unsigned struct_vt_stat_sz;
--- 998,1003 ----
*************** extern unsigned IOCTL_SNDCTL_COPR_SENDMS
*** 1243,1255 ****
  extern unsigned IOCTL_SNDCTL_COPR_WCODE;
  extern unsigned IOCTL_SNDCTL_COPR_WDATA;
  extern unsigned IOCTL_TCFLSH;
- extern unsigned IOCTL_TCGETA;
  extern unsigned IOCTL_TCGETS;
  extern unsigned IOCTL_TCSBRK;
  extern unsigned IOCTL_TCSBRKP;
- extern unsigned IOCTL_TCSETA;
- extern unsigned IOCTL_TCSETAF;
- extern unsigned IOCTL_TCSETAW;
  extern unsigned IOCTL_TCSETS;
  extern unsigned IOCTL_TCSETSF;
  extern unsigned IOCTL_TCSETSW;
--- 1242,1250 ----
diff -Nrcpad gcc-13.4.0/libsanitizer/tsan/tsan_trace.h gcc-13.5.0-RC-20260904/libsanitizer/tsan/tsan_trace.h
*** gcc-13.4.0/libsanitizer/tsan/tsan_trace.h	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libsanitizer/tsan/tsan_trace.h	Fri Sep  4 07:35:12 2026
*************** struct Trace {
*** 190,196 ****
    Mutex mtx;
    IList parts;
    // First node non-queued into ctx->trace_part_recycle.
!   TracePart* local_head;
    // Final position in the last part for finished threads.
    Event* final_pos = nullptr;
    // Number of trace parts allocated on behalf of this trace specifically.
--- 190,196 ----
    Mutex mtx;
    IList parts;
    // First node non-queued into ctx->trace_part_recycle.
!   TracePart* local_head = nullptr;
    // Final position in the last part for finished threads.
    Event* final_pos = nullptr;
    // Number of trace parts allocated on behalf of this trace specifically.
diff -Nrcpad gcc-13.4.0/libstdc++-v3/ChangeLog gcc-13.5.0-RC-20260904/libstdc++-v3/ChangeLog
*** gcc-13.4.0/libstdc++-v3/ChangeLog	Thu Jun  5 16:03:57 2025
--- gcc-13.5.0-RC-20260904/libstdc++-v3/ChangeLog	Fri Sep  4 07:35:12 2026
***************
*** 1,3 ****
--- 1,576 ----
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2025-07-01  Patrick Palka  
+ 
+ 	PR libstdc++/120789
+ 	* include/bits/ranges_algo.h (__remove_if_fn::operator()): Use
+ 	ranges::iter_move(iter) instead of std::move(*iter).
+ 	* testsuite/25_algorithms/remove_if/120789.cc: New test.
+ 
+ 2026-09-03  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2025-07-01  Patrick Palka  
+ 
+ 	PR libstdc++/120789
+ 	* include/bits/ranges_algo.h (__unique_fn::operator()): Use
+ 	ranges::iter_move(iter) instead of std::move(*iter).
+ 	* testsuite/25_algorithms/unique/120789.cc: New test.
+ 
+ 2026-08-25  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-08-24  Jonathan Wakely  
+ 
+ 	PR libstdc++/127006
+ 	* include/std/spanstream (basic_ospanstream(span, openmode)):
+ 	Add correct openmode value to parameter.
+ 	* testsuite/27_io/spanstream/127006.cc: New test.
+ 
+ 2026-08-18  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-08-17  Jonathan Wakely  
+ 
+ 	PR libstdc++/126849
+ 	* include/std/numbers: Fix preprocessor check for
+ 	std::bfloat16_t support.
+ 
+ 2026-08-01  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2026-03-18  Jakub Jelinek  
+ 
+ 	* include/bits/regex_compiler.h (_Compiler::_M_pop): Uglify ret
+ 	variable name.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-04-24  Jonathan Wakely  
+ 
+ 	* include/std/chrono (chrono::__detail::__get_leap_second_info):
+ 	Update expiry date for leap seconds list.
+ 	* src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds):
+ 	Likewise.
+ 	* src/c++20/tzdata.zi: Import new file from 2026a release.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-12-16  Jonathan Wakely  
+ 
+ 	* include/std/chrono (chrono::__detail::__get_leap_second_info):
+ 	Update expiry date for leap seconds list.
+ 	* src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds):
+ 	Likewise.
+ 	* src/c++20/tzdata.zi: Import new file from 2025c release.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-06-11  Jonathan Wakely  
+ 
+ 	PR libstdc++/120390
+ 	* include/bits/stl_construct.h (_Destroy_aux::__destroy_n): New
+ 	static member function.
+ 	(_Destroy_aux::__destroy_n): Likewise.
+ 	(_Destroy_n_aux): Remove.
+ 	(_Destroy(ForwardIterator, ForwardIterator)): Remove
+ 	static_assert. Use is_trivially_destructible instead of
+ 	__has_trivial_destructor.
+ 	(_Destroy_n): Likewise. Use _Destroy_aux::__destroy_n instead of
+ 	_Destroy_n_aux::__destroy_n.
+ 	* testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc:
+ 	Adjust dg-error strings. Move destroy_n tests to ...
+ 	* testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_n_neg.cc:
+ 	New test.
+ 	* testsuite/23_containers/vector/cons/destructible_debug_neg.cc:
+ 	Adjust dg-error strings.
+ 	* testsuite/23_containers/vector/cons/destructible_neg.cc:
+ 	Likewise.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2024-12-02  Jonathan Wakely  
+ 
+ 	* include/bits/stl_construct.h (_Destroy(FwdIter, FwdIter)): Use
+ 	'if constexpr' instead of dispatching to a member function of a
+ 	class template.
+ 	(_Destroy_n(FwdIter, Size)): Likewise.
+ 	(_Destroy_aux, _Destroy_n_aux): Only define for C++98.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2024-03-22  Jonathan Wakely  
+ 
+ 	* include/bits/stl_construct.h (construct_at): Guard
+ 	with feature test macros instead of just __cplusplus.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2024-12-09  Jonathan Wakely  
+ 
+ 	PR libstdc++/102259
+ 	* config/io/basic_file_stdio.cc (basic_file::xsgetn): Limit n to
+ 	_GLIBCXX_MAX_READ_SIZE if that macro is defined.
+ 	* config/os/bsd/darwin/os_defines.h (_GLIBCXX_MAX_READ_SIZE):
+ 	Define to INT_MAX-1.
+ 	* config/os/bsd/freebsd/os_defines.h (_GLIBCXX_MAX_READ_SIZE):
+ 	Likewise.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-03-20  Jonathan Wakely  
+ 
+ 	* src/c++17/fs_path.cc (path::operator+=): Use pointer
+ 	comparison to detect aliasing instead of a loop.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-05-06  Jonathan Wakely  
+ 
+ 	PR libstdc++/120029
+ 	* src/c++17/fs_path.cc (path::operator+=(const path&)): Handle
+ 	parameters that alias the path or one of its components.
+ 	* testsuite/27_io/filesystem/path/concat/120029.cc: New test.
+ 	* testsuite/experimental/filesystem/path/concat/120029.cc: New
+ 	test.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-05-19  Jonathan Wakely  
+ 
+ 	PR libstdc++/120293
+ 	* include/bits/chrono_io.h (_M_format_to_ostream): Add special
+ 	case for local_time convertible to local_days.
+ 	* testsuite/std/time/clock/local/io.cc: Check formatting of
+ 	chrono::local_days.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2024-07-30  Jonathan Wakely  
+ 
+ 	* include/bits/chrono_io.h (__local_fmt_t): Remove unused
+ 	declaration.
+ 	(__formatter_chrono::_M_format_to_ostream): Add explicit
+ 	handling for specializations of __local_time_fmt, including the
+ 	time zone abbreviation in the output if __is_neg is true.
+ 	(formatter>::format): Add comment.
+ 	(formatter>::format): Likewise.
+ 	(formatter
+ 
+ 	Backported from master:
+ 	2026-02-13  Jonathan Wakely  
+ 
+ 	PR libstdc++/121771
+ 	* include/std/tuple (tuple::tuple(const Elements&...)): Use
+ 	type_identity_t to prevent constructor being used for CTAD.
+ 	(tuple::tuple(allocator_arg_t, const A&, const Elements&...)):
+ 	Likewise.
+ 	* testsuite/20_util/tuple/cons/121771.cc: New test.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-03-20  Jonathan Wakely  
+ 
+ 	PR libstdc++/122567
+ 	* src/c++20/tzdb.cc (tzdb::current_zone): Loop over all trailing
+ 	components of /etc/localtime path. Use readlink instead of
+ 	std::filesystem::read_symlink.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-01-07  Jonathan Wakely  
+ 
+ 	PR libstdc++/123100
+ 	* include/std/sstream (basic_stringbuf::str()&&): Handle the
+ 	case where _M_string is not being used for the buffer.
+ 	* testsuite/27_io/basic_stringbuf/str/char/123100.cc: New test.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-05-05  Jonathan Wakely  
+ 
+ 	PR libstdc++/109965
+ 	* doc/doxygen/mainpage.html: Link to topics.html instead of
+ 	modules.html
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2024-12-18  Jonathan Wakely  
+ 
+ 	PR libstdc++/118088
+ 	* include/bits/stl_queue.h (priority_queue(priority_queue&&)):
+ 	Clear the source object after moving from it.
+ 	(priority_queue(priority_queue&&, const Alloc&)): Likewise.
+ 	(operator=(priority_queue&&)): Likewise.
+ 	* testsuite/23_containers/priority_queue/118088.cc: New test.
+ 
+ 2026-05-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-07-08  Jonathan Wakely  
+ 
+ 	PR libstdc++/118681
+ 	* src/c++17/memory_resource.cc (choose_block_size): New
+ 	function.
+ 	(synchronized_pool_resource::do_allocate): Use choose_block_size
+ 	to determine appropriate block size.
+ 	(synchronized_pool_resource::do_deallocate): Likewise
+ 	(unsynchronized_pool_resource::do_allocate): Likewise.
+ 	(unsynchronized_pool_resource::do_deallocate): Likewise
+ 	* testsuite/20_util/synchronized_pool_resource/118681.cc: New
+ 	test.
+ 	* testsuite/20_util/unsynchronized_pool_resource/118681.cc: New
+ 	test.
+ 
+ 2026-03-22  Jakub Jelinek  
+ 
+ 	Backported from master:
+ 	2025-09-08  Jakub Jelinek  
+ 
+ 	PR libstdc++/121827
+ 	* include/precompiled/extc++.h: Don't include ext/cast.h which is an
+ 	internal header.
+ 	* include/ext/pointer.h: Include bits/c++config.h before
+ 	#if _GLIBCXX_HOSTED.
+ 
+ 2026-03-20  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-03-20  Jonathan Wakely  
+ 
+ 	* src/c++20/tzdb.cc [_AIX]: Change #ifndef to #ifdef.
+ 
+ 2026-03-20  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-03-20  Jonathan Wakely  
+ 
+ 	PR libstdc++/124568
+ 	* testsuite/24_iterators/istreambuf_iterator/105580.cc: Add
+ 	no_pch option.
+ 
+ 2026-03-16  Tomasz Kamiński  
+ 
+ 	Backported from master:
+ 	2026-03-05  Tomasz Kamiński  
+ 
+ 	PR libstdc++/124124
+ 	* testsuite/29_atomics/atomic/cons/zero_padding.cc: Limit size of
+ 	test types to four bytes.
+ 
+ 2026-03-16  Tomasz Kamiński  
+ 
+ 	PR libstdc++/105580
+ 	* include/std/streambuf (streambuf::gptr, streambuf::egptr)
+ 	(streambuf::gbump): Surround with pragma disabling -Wnull-dereference.
+ 	* testsuite/24_iterators/istreambuf_iterator/105580.cc: New test.
+ 	(cherry picked from commits
+ 	8758503918a91dacff4dbc7126eced21787fbfc9
+ 	bfc2b87f8244a13ab00e8e3fe2af1d6d18fcaa36
+ 	a523d1ecc89dcb7ea205e3de22d00443d4a0d91d)
+ 
+ 2026-03-13  Patrick Palka  
+ 
+ 	Backported from master:
+ 	2026-02-12  Patrick Palka  
+ 
+ 	PR libstdc++/114865
+ 	* include/std/atomic (atomic<_Tp>::atomic(_Tp)) [C++11]:
+ 	Enable __builtin_clear_padding logic.
+ 	* testsuite/29_atomics/atomic/compare_exchange_padding.cc: Enable
+ 	this test in earlier modes, including C++11.
+ 	* testsuite/29_atomics/atomic/cons/zero_padding.cc [C++11]:
+ 	Enable tests verifying cleared padding bits for a non-static-init
+ 	std::atomic object.
+ 
+ 2026-03-04  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-03-04  Jonathan Wakely  
+ 
+ 	PR libstdc++/124363
+ 	* include/std/string_view: Adjust comment on #endif to match #if
+ 	condition. Likewise for header guard.
+ 
+ 2026-02-27  Tomasz Kamiński  
+ 
+ 	PR libstdc++/123875
+ 	* include/std/atomic (atomic<_Tp>::atomic(_Tp)): Skip __clear_padding
+ 	call for constant evaluation.
+ 	* testsuite/29_atomics/atomic/cons/zero_padding.cc: New test.
+ 	(cherry picked with modifications from commits
+ 	6b550d69fe7cb62ea6e240ce7a4ba29ce33aa1b1
+ 	682c95b808724e6f876ea709b873ac6771704d7b
+ 	060d7c2a9c1fe16d23d98a74287fdb7c73ddb784
+ 	f3ba5ad088cebe117f857329a35b95d18d97a808)
+ 
+ 2026-02-10  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-11-24  Jonathan Wakely  
+ 
+ 	* python/libstdcxx/v6/xmethods.py (ListMethodsMatcher.match):
+ 	Fix lookup for node type.
+ 
+ 2026-02-10  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-11-24  Jonathan Wakely  
+ 
+ 	PR libstdc++/122821
+ 	* python/libstdcxx/v6/xmethods.py (_versioned_namespace): Remove
+ 	global variable.
+ 	(is_specialization_of): Do not use _versioned_namespace. Add
+ 	__debug:: to regex.
+ 
+ 2026-02-10  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2026-02-10  Jonathan Wakely  
+ 
+ 	PR libstdc++/123991
+ 	* include/bits/basic_string.h (compare(size_type, size_type, T)):
+ 	Remove noexcept-specifier.
+ 	(compare(size_type, size_type, T, size_type, size_type)):
+ 	Likewise.
+ 	* include/bits/cow_string.h (compare(size_type, size_type, T)):
+ 	Remove noexcept-specifier.
+ 	(compare(size_type, size_type, T, size_type, size_type)):
+ 	Likewise.
+ 	* testsuite/21_strings/basic_string/operations/compare/char/123991.cc:
+ 	New test.
+ 	* testsuite/21_strings/basic_string/operations/compare/wchar_t/123991.cc:
+ 	New test.
+ 
+ 2026-02-09  Tomasz Kamiński  
+ 
+ 	Backported from master:
+ 	2025-08-26  Tomasz Kamiński  
+ 
+ 	PR libstdc++/90192
+ 	* include/bits/stl_vector.h (vector::_M_fill_append): Declare.
+ 	(vector::fill): Use _M_fill_append instead of _M_fill_insert.
+ 	* include/bits/vector.tcc (vector::_M_fill_append): Define
+ 	(vector::_M_fill_insert): Delegate to _M_fill_append when
+ 	elements are appended.
+ 	* testsuite/23_containers/vector/modifiers/moveable.cc: Updated
+ 	copycount for inserting at the end (appending).
+ 	* testsuite/23_containers/vector/modifiers/resize.cc: New test.
+ 	* testsuite/backward/hash_set/check_construct_destroy.cc: Updated
+ 	copycount, the hash_set constructor uses insert to fill buckets
+ 	with nullptrs.
+ 
+ 2026-01-26  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2024-11-27  Jonathan Wakely  
+ 
+ 	PR libstdc++/105857
+ 	* config/locale/dragonfly/codecvt_members.cc (do_length): Limit
+ 	size of alloca buffer to 4k.
+ 	* config/locale/gnu/codecvt_members.cc (do_length): Likewise.
+ 	* testsuite/22_locale/codecvt/length/wchar_t/105857.cc: New
+ 	test.
+ 
+ 2026-01-23  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-09-12  Jonathan Wakely  
+ 
+ 	PR libstdc++/117276
+ 	* include/pstl/parallel_backend_tbb.h (__func_task::finalize):
+ 	Make deallocation unconditional.
+ 
+ 2026-01-23  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-12-06  Jonathan Wakely  
+ 
+ 	* include/bits/atomic_wait.h (__detail::__atomic_compare): Use
+ 	std::addressof instead of &.
+ 	* include/std/atomic (atomic::wait, atomic::notify_one)
+ 	(atomic::notify_all): Likewise.
+ 
+ 2025-11-18  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-11-17  Jonathan Wakely  
+ 
+ 	PR libstdc++/122726
+ 	* src/filesystem/ops-common.h [_GLIBCXX_FILESYSTEM_IS_WINDOWS]
+ 	(rename): Use __last_system_error to set errno accurately.
+ 	* testsuite/27_io/filesystem/operations/rename.cc: Test
+ 	error_code matches errc::no_such_file_or_directory.
+ 
+ 2025-11-14  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-11-13  Jonathan Wakely  
+ 
+ 	PR libstdc++/122661
+ 	* include/bits/forward_list.h (forward_list::assign(I, I)): Fix
+ 	value category in is_assignable check.
+ 	* testsuite/23_containers/forward_list/modifiers/122661.cc:
+ 	New test.
+ 
+ 2025-09-09  Tomasz Kamiński  
+ 
+ 	Backported from master:
+ 	2025-09-05  Tomasz Kamiński  
+ 
+ 	* doc/html/manual/status.html: Regenerate.
+ 	* doc/xml/manual/status_cxx2011.xml: Add entry for bad_function_call.
+ 	* doc/xml/manual/status_cxx2017.xml: Add entries for bad_any_cast
+ 	and nullptr_t output. Update entry for sf.cmath. Fix stable name for
+ 	mem.res.
+ 
+ 2025-09-09  Tomasz Kamiński  
+ 
+ 	Backported from master:
+ 	2025-09-05  Tomasz Kamiński  
+ 
+ 	* doc/html/manual/status.html: Regenerate the file.
+ 	* doc/xml/manual/status_cxx2017.xml: Addd more entires.
+ 
+ 2025-09-08  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-09-08  Jonathan Wakely  
+ 
+ 	PR libstdc++/120698
+ 	* doc/xml/manual/configure.xml: Do not claim that vtv is enabled
+ 	by default.
+ 	* doc/html/manual/configure.html: Regenerate.
+ 
+ 2025-09-04  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-09-03  Jonathan Wakely  
+ 
+ 	PR libstdc++/110853
+ 	* include/bits/stl_pair.h [C++20] (pair(const T1&, const T2&)):
+ 	Use std::type_identity_t for first parameter.
+ 	* testsuite/20_util/pair/cons/110853.cc: New test.
+ 
+ 2025-09-04  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-09-03  Jonathan Wakely  
+ 
+ 	PR libstdc++/121745
+ 	* include/bits/stl_pair.h (get): Use forward instead of move in
+ 	std::get overloads for rvalue pairs.
+ 	* testsuite/20_util/pair/astuple/get_by_type.cc: Check all value
+ 	categories and cv-qualification.
+ 
+ 2025-09-04  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-07-17  Jonathan Wakely  
+ 
+ 	PR libstdc++/121097
+ 	* include/c_global/cmath (hypot): Use __promote_3 instead of
+ 	__promoted.
+ 
+ 2025-06-11  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-06-04  Jonathan Wakely  
+ 
+ 	PR libstdc++/99832
+ 	* include/bits/chrono.h (system_clock::to_time_t): Add
+ 	always_inline attribute to be agnostic to the underlying type of
+ 	time_t.
+ 	(system_clock::from_time_t): Add always_inline for consistency
+ 	with to_time_t.
+ 	* testsuite/20_util/system_clock/99832.cc: New test.
+ 
+ 2025-06-11  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-06-05  Jonathan Wakely  
+ 
+ 	PR libstdc++/120548
+ 	* include/std/format (__formatter_fp::_M_localize): Do not
+ 	include a leading sign character in the string to be grouped.
+ 	* testsuite/std/format/functions/format.cc: Check grouping when
+ 	sign is present in the output.
+ 
+ 2025-06-11  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2024-09-14  Jonathan Wakely  
+ 
+ 	* include/std/format (__formatter_fp::_M_localize): Add comments
+ 	and micro-optimize string copy.
+ 
+ 2025-06-10  Jonathan Wakely  
+ 
+ 	Backported from master:
+ 	2025-05-20  Jonathan Wakely  
+ 
+ 	* doc/xml/faq.xml: Update URL for archived SGI STL docs.
+ 	* doc/xml/manual/containers.xml: Likewise.
+ 	* doc/xml/manual/extensions.xml: Likewise.
+ 	* doc/xml/manual/using.xml: Likewise.
+ 	* doc/xml/manual/utilities.xml: Likewise.
+ 	* doc/html/*: Regenerate.
+ 
+ 2025-06-06  Giuseppe D'Angelo  
+ 
+ 	Backported from master:
+ 	2025-02-07  Giuseppe D'Angelo  
+ 
+ 	PR libstdc++/118160
+ 	PR libstdc++/100249
+ 	* include/bits/ranges_algo.h (__is_permutation_fn): Avoid a
+ 	dangling reference by storing the result of the iterator
+ 	dereference and the result of the projection in two distinct
+ 	variables, in order to lifetime-extend each one.
+ 	Forward the projected value to the predicate.
+ 	* testsuite/25_algorithms/is_permutation/constrained.cc: Add a
+ 	test with a range returning prvalues. Test it in a constexpr
+ 	context, in order to rely on the compiler to catch UB.
+ 
+ 2025-06-05  Giuseppe D'Angelo  
+ 
+ 	Backported from master:
+ 	2025-03-14  Giuseppe D'Angelo  
+ 
+ 	* include/bits/shared_ptr_base.h (lock): Fixed a compile error
+ 	when calling lock() on a weak_ptr, by removing an
+ 	erroneous usage of element_type from within lock().
+ 	* testsuite/20_util/shared_ptr/requirements/explicit_instantiation/1.cc:
+ 	Add more tests for array types.
+ 	* testsuite/20_util/weak_ptr/requirements/explicit_instantiation/1.cc:
+ 	Likewise.
+ 	* testsuite/20_util/shared_ptr/requirements/1.cc: New test.
+ 	* testsuite/20_util/weak_ptr/requirements/1.cc: New test.
+ 
  2025-06-05  Release Manager
  
  	* GCC 13.4.0 released.
diff -Nrcpad gcc-13.4.0/libstdc++-v3/config/io/basic_file_stdio.cc gcc-13.5.0-RC-20260904/libstdc++-v3/config/io/basic_file_stdio.cc
*** gcc-13.4.0/libstdc++-v3/config/io/basic_file_stdio.cc	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libstdc++-v3/config/io/basic_file_stdio.cc	Fri Sep  4 07:35:12 2026
*************** _GLIBCXX_BEGIN_NAMESPACE_VERSION
*** 336,341 ****
--- 336,347 ----
      if (__ret == 0 && ferror(this->file()))
        __ret = -1;
  #else
+ 
+ #ifdef _GLIBCXX_MAX_READ_SIZE
+     if (__builtin_expect(__n > _GLIBCXX_MAX_READ_SIZE, 0))
+       __n = _GLIBCXX_MAX_READ_SIZE;
+ #endif
+ 
      do
        __ret = read(this->fd(), __s, __n);
      while (__ret == -1L && errno == EINTR);
diff -Nrcpad gcc-13.4.0/libstdc++-v3/config/locale/dragonfly/codecvt_members.cc gcc-13.5.0-RC-20260904/libstdc++-v3/config/locale/dragonfly/codecvt_members.cc
*** gcc-13.4.0/libstdc++-v3/config/locale/dragonfly/codecvt_members.cc	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libstdc++-v3/config/locale/dragonfly/codecvt_members.cc	Fri Sep  4 07:35:12 2026
*************** _GLIBCXX_BEGIN_NAMESPACE_VERSION
*** 226,237 ****
  
      // mbsnrtowcs is *very* fast but stops if encounters NUL characters:
      // in case we advance past it and then continue, in a loop.
!     // NB: mbsnrtowcs is a GNU extension
  
      // A dummy internal buffer is needed in order for mbsnrtocws to consider
      // its fourth parameter (it wouldn't with NULL as first parameter).
      wchar_t* __to = static_cast(__builtin_alloca(sizeof(wchar_t)
! 							   * __max));
      while (__from < __end && __max)
        {
  	const extern_type* __from_chunk_end;
--- 226,239 ----
  
      // mbsnrtowcs is *very* fast but stops if encounters NUL characters:
      // in case we advance past it and then continue, in a loop.
!     // NB: mbsnrtowcs is in POSIX.1-2008
! 
!     const size_t __to_len = 1024; // Size of alloca'd output buffer
  
      // A dummy internal buffer is needed in order for mbsnrtocws to consider
      // its fourth parameter (it wouldn't with NULL as first parameter).
      wchar_t* __to = static_cast(__builtin_alloca(sizeof(wchar_t)
! 							   * __to_len));
      while (__from < __end && __max)
        {
  	const extern_type* __from_chunk_end;
*************** _GLIBCXX_BEGIN_NAMESPACE_VERSION
*** 244,250 ****
  	const extern_type* __tmp_from = __from;
  	size_t __conv = mbsnrtowcs(__to, &__from,
  				   __from_chunk_end - __from,
! 				   __max, &__state);
  	if (__conv == static_cast(-1))
  	  {
  	    // In case of error, in order to stop at the exact place we
--- 246,253 ----
  	const extern_type* __tmp_from = __from;
  	size_t __conv = mbsnrtowcs(__to, &__from,
  				   __from_chunk_end - __from,
! 				   __max > __to_len ? __to_len : __max,
! 				   &__state);
  	if (__conv == static_cast(-1))
  	  {
  	    // In case of error, in order to stop at the exact place we
diff -Nrcpad gcc-13.4.0/libstdc++-v3/config/locale/gnu/codecvt_members.cc gcc-13.5.0-RC-20260904/libstdc++-v3/config/locale/gnu/codecvt_members.cc
*** gcc-13.4.0/libstdc++-v3/config/locale/gnu/codecvt_members.cc	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libstdc++-v3/config/locale/gnu/codecvt_members.cc	Fri Sep  4 07:35:12 2026
*************** _GLIBCXX_BEGIN_NAMESPACE_VERSION
*** 243,254 ****
  
      // mbsnrtowcs is *very* fast but stops if encounters NUL characters:
      // in case we advance past it and then continue, in a loop.
!     // NB: mbsnrtowcs is a GNU extension
  
      // A dummy internal buffer is needed in order for mbsnrtocws to consider
      // its fourth parameter (it wouldn't with NULL as first parameter).
      wchar_t* __to = static_cast(__builtin_alloca(sizeof(wchar_t)
! 							   * __max));
      while (__from < __end && __max)
        {
  	const extern_type* __from_chunk_end;
--- 243,256 ----
  
      // mbsnrtowcs is *very* fast but stops if encounters NUL characters:
      // in case we advance past it and then continue, in a loop.
!     // NB: mbsnrtowcs is in POSIX.1-2008
! 
!     const size_t __to_len = 1024; // Size of alloca'd output buffer
  
      // A dummy internal buffer is needed in order for mbsnrtocws to consider
      // its fourth parameter (it wouldn't with NULL as first parameter).
      wchar_t* __to = static_cast(__builtin_alloca(sizeof(wchar_t)
! 							   * __to_len));
      while (__from < __end && __max)
        {
  	const extern_type* __from_chunk_end;
*************** _GLIBCXX_BEGIN_NAMESPACE_VERSION
*** 261,267 ****
  	const extern_type* __tmp_from = __from;
  	size_t __conv = mbsnrtowcs(__to, &__from,
  				   __from_chunk_end - __from,
! 				   __max, &__state);
  	if (__conv == static_cast(-1))
  	  {
  	    // In case of error, in order to stop at the exact place we
--- 263,270 ----
  	const extern_type* __tmp_from = __from;
  	size_t __conv = mbsnrtowcs(__to, &__from,
  				   __from_chunk_end - __from,
! 				   __max > __to_len ? __to_len : __max,
! 				   &__state);
  	if (__conv == static_cast(-1))
  	  {
  	    // In case of error, in order to stop at the exact place we
diff -Nrcpad gcc-13.4.0/libstdc++-v3/config/os/bsd/darwin/os_defines.h gcc-13.5.0-RC-20260904/libstdc++-v3/config/os/bsd/darwin/os_defines.h
*** gcc-13.4.0/libstdc++-v3/config/os/bsd/darwin/os_defines.h	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libstdc++-v3/config/os/bsd/darwin/os_defines.h	Fri Sep  4 07:35:12 2026
***************
*** 54,57 ****
--- 54,60 ----
  // No support for referencing weak symbols without a definition.
  #define _GLIBCXX_USE_WEAK_REF 0
  
+ // read(2) can return EINVAL for n >= INT_MAX.
+ #define _GLIBCXX_MAX_READ_SIZE (__INT_MAX__ - 1)
+ 
  #endif
diff -Nrcpad gcc-13.4.0/libstdc++-v3/config/os/bsd/freebsd/os_defines.h gcc-13.5.0-RC-20260904/libstdc++-v3/config/os/bsd/freebsd/os_defines.h
*** gcc-13.4.0/libstdc++-v3/config/os/bsd/freebsd/os_defines.h	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libstdc++-v3/config/os/bsd/freebsd/os_defines.h	Fri Sep  4 07:35:12 2026
***************
*** 40,43 ****
--- 40,46 ----
  #define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_CHECK 1
  #define _GLIBCXX_USE_C99_FLOAT_TRANSCENDENTALS_DYNAMIC defined _XOPEN_SOURCE
  
+ // read(2) can return EINVAL for n >= INT_MAX.
+ #define _GLIBCXX_MAX_READ_SIZE (__INT_MAX__ - 1)
+ 
  #endif
diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/doxygen/mainpage.html gcc-13.5.0-RC-20260904/libstdc++-v3/doc/doxygen/mainpage.html
*** gcc-13.4.0/libstdc++-v3/doc/doxygen/mainpage.html	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/doxygen/mainpage.html	Fri Sep  4 07:35:12 2026
***************
*** 38,44 ****
  
  
      Here are entry points to all the pages generated by Doxygen:
     
        
!     
      • Modules
        • 
  
      
      • Namespaces
      
          
--- 38,44 ----
  
  
          Here are entry points to all the pages generated by Doxygen:
     
            
!     
          • Topics
            • 
  
      
          • Namespaces
      
              
diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/html/faq.html gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/faq.html
*** gcc-13.4.0/libstdc++-v3/doc/html/faq.html	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/faq.html	Fri Sep  4 07:35:12 2026
***************
*** 797,803 ****
      Libstdc++-v3 incorporates a lot of code from
      the SGI STL
      (the final merge was from
!     release 3.3).
      The code in libstdc++ contains many fixes and changes compared to the
      original SGI code.
      
              
--- 797,803 ----
      Libstdc++-v3 incorporates a lot of code from
      the SGI STL
      (the final merge was from
!     release 3.3).
      The code in libstdc++ contains many fixes and changes compared to the
      original SGI code.
      
              
diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/html/manual/configure.html gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/configure.html
*** gcc-13.4.0/libstdc++-v3/doc/html/manual/configure.html	Thu Jun  5 16:03:03 2025
--- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/configure.html	Fri Sep  4 07:35:12 2026
***************
*** 268,274 ****
          operations (e.g. the library is configured for armv7 and then code
          is compiled with -march=armv5t) then the program
          might rely on support in libgcc to provide the atomics.
!
--enable-vtable-verify[default]

Use -fvtable-verify=std to compile the C++ runtime with instrumentation for vtable verification. All virtual functions in the standard library will be verified at runtime. Types impacted include locale and --- 268,274 ---- operations (e.g. the library is configured for armv7 and then code is compiled with -march=armv5t) then the program might rely on support in libgcc to provide the atomics. !

--enable-vtable-verify

Use -fvtable-verify=std to compile the C++ runtime with instrumentation for vtable verification. All virtual functions in the standard library will be verified at runtime. Types impacted include locale and diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/html/manual/containers.html gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/containers.html *** gcc-13.4.0/libstdc++-v3/doc/html/manual/containers.html Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/containers.html Fri Sep 4 07:35:12 2026 *************** *** 11,17 **** Yes it is, at least using the old ABI, and that's okay. This is a decision that we preserved when we imported SGI's STL implementation. The following is ! quoted from their FAQ:

The size() member function, for list and slist, takes time proportional to the number of elements in the list. This was a --- 11,17 ---- Yes it is, at least using the old ABI, and that's okay. This is a decision that we preserved when we imported SGI's STL implementation. The following is ! quoted from their FAQ:

The size() member function, for list and slist, takes time proportional to the number of elements in the list. This was a diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/html/manual/ext_numerics.html gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/ext_numerics.html *** gcc-13.4.0/libstdc++-v3/doc/html/manual/ext_numerics.html Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/ext_numerics.html Fri Sep 4 07:35:12 2026 *************** *** 14,20 **** The operation functor must be associative.

The iota function wins the award for Extension With the Coolest Name (the name comes from Ken Iverson's APL language.) As ! described in the SGI documentation, it "assigns sequentially increasing values to a range. That is, it assigns value to *first, value + 1 to *(first + 1) and so on." --- 14,20 ---- The operation functor must be associative.

The iota function wins the award for Extension With the Coolest Name (the name comes from Ken Iverson's APL language.) As ! described in the SGI documentation, it "assigns sequentially increasing values to a range. That is, it assigns value to *first, value + 1 to *(first + 1) and so on." diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/html/manual/ext_sgi.html gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/ext_sgi.html *** gcc-13.4.0/libstdc++-v3/doc/html/manual/ext_sgi.html Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/ext_sgi.html Fri Sep 4 07:35:12 2026 *************** *** 28,39 **** and sets.

Each of the associative containers map, multimap, set, and multiset have a counterpart which uses a ! hashing function to do the arranging, instead of a strict weak ordering function. The classes take as one of their template parameters a function object that will return the hash value; by default, an instantiation of ! hash. You should specialize this functor for your class, or define your own, before trying to use one of the hashing classes.

The hashing classes support all the usual associative container --- 28,39 ---- and sets.

Each of the associative containers map, multimap, set, and multiset have a counterpart which uses a ! hashing function to do the arranging, instead of a strict weak ordering function. The classes take as one of their template parameters a function object that will return the hash value; by default, an instantiation of ! hash. You should specialize this functor for your class, or define your own, before trying to use one of the hashing classes.

The hashing classes support all the usual associative container diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/html/manual/status.html gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/status.html *** gcc-13.4.0/libstdc++-v3/doc/html/manual/status.html Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/status.html Fri Sep 4 07:35:12 2026 *************** the GCC 13 release series. *** 255,260 **** --- 255,263 ---- 20.7.2.0 [util.smartptr.weakptr] what() returns "bad_weak_ptr".

+ 20.8.11.1 [func.wrap.badcall] + what() returns "bad_function_call". +

20.8.9.1.3 [func.bind.place]/1 There are 29 placeholders defined and the placeholder types are CopyAssignable. *************** since C++14 and the implementation is co *** 1054,1060 **** "std::visit: variant is valueless", or "std::visit<R>: variant is valueless".

! 23.12.5.2 [memory.resource.pool.options] Let S equal numeric_limits<size_t>::digits. The limit for maximum number of blocks in a chunk is given by 2N-1, --- 1057,1067 ---- "std::visit: variant is valueless", or "std::visit<R>: variant is valueless".

! 23.8.2 [any.bad_any_cast] ! what() returns "bad any_cast". !

! 23.12.5 [mem.res.pool.options], ! 23.12.5 [mem.res.pool.mem] Let S equal numeric_limits<size_t>::digits. The limit for maximum number of blocks in a chunk is given by 2N-1, *************** since C++14 and the implementation is co *** 1065,1071 **** otherwise 3072 when S > 16, otherwise 768.

! 23.12.6.1 [memory.resource.monotonic.buffer.ctor] The default next_buffer_size is 128 * sizeof(void*). The default growth factor is 1.5.

--- 1072,1078 ---- otherwise 3072 when S > 16, otherwise 768.

! 23.12.6.1 [mem.res.monotonic.buffer.ctor] The default next_buffer_size is 128 * sizeof(void*). The default growth factor is 1.5.

*************** since C++14 and the implementation is co *** 1100,1109 **** races depends on the target C library that provides the function.

29.9.5 [sf.cmath] ! The effect of calling the mathematical special functions with large ! inputs should be documented here.

! 30.10.2.1 [fs.conform.9945] The behavior of the filesystem library implementation will depend on the target operating system. Some features will not be supported on some targets. Symbolic links and file permissions --- 1107,1120 ---- races depends on the target C library that provides the function.

29.9.5 [sf.cmath] ! Calling the mathematical special functions with large inputs is supported ! but the results may be imprecise.

! 30.7.5.2.3 [ostream.inserters] ! NTCTS for nullptr_t is "nullptr". !

! 30.10.2.1 [fs.conform.9945], ! 30.10.2.2 [fs.conform.os] The behavior of the filesystem library implementation will depend on the target operating system. Some features will not be supported on some targets. Symbolic links and file permissions *************** since C++14 and the implementation is co *** 1139,1145 **** Specifically, it is not possible to rename a directory to replace another directory (POSIX requires that to work if the directory being replaced is empty). !

Parallelism 2 TS

9.3 [parallel.simd.abi] max_fixed_size<T> is 32, except when targetting AVX512BW and sizeof(T) is 1. --- 1150,1169 ---- Specifically, it is not possible to rename a directory to replace another directory (POSIX requires that to work if the directory being replaced is empty). !

! 30.10.29.2 [fs.enum.file_type], ! 30.10.34.3 [fs.op.copy], ! 30.10.34.35 [fs.op.status] ! No additional file types are supported, and there are no ! implementation-defined enumerators in ! std::filesystem::file_type. !

! 30.10.32 [fs.class.directory_iterator], ! 30.10.33 [fs.class.rec.dir.itr] ! Any directory-like file types supported by ! opendir/readdir ! (or _wopendir/_wreaddir on Windows). !

Parallelism 2 TS

9.3 [parallel.simd.abi] max_fixed_size<T> is 32, except when targetting AVX512BW and sizeof(T) is 1. diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/html/manual/using_concurrency.html gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/using_concurrency.html *** gcc-13.4.0/libstdc++-v3/doc/html/manual/using_concurrency.html Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/using_concurrency.html Fri Sep 4 07:35:12 2026 *************** The standard places requirements on the *** 40,46 **** races are caused by the library itself or by programs which use the library correctly (as described below). The C++11 memory model and library requirements are a more formal version ! of the SGI STL definition of thread safety, which the library used prior to the 2011 standard.

The library strives to be thread-safe when all of the following conditions are met: --- 40,46 ---- races are caused by the library itself or by programs which use the library correctly (as described below). The C++11 memory model and library requirements are a more formal version ! of the SGI STL definition of thread safety, which the library used prior to the 2011 standard.

The library strives to be thread-safe when all of the following conditions are met: *************** gcc version 4.1.2 20070925 (Red Hat 4.1. *** 243,252 **** threaded and non-threaded code), see Chapter 17.

Two excellent pages to read when working with the Standard C++ containers and threads are ! SGI's ! https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/thread_safety.html and ! SGI's ! https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/Allocators.html.

However, please ignore all discussions about the user-level configuration of the lock implementation inside the STL container-memory allocator on those pages. For the sake of this --- 243,252 ---- threaded and non-threaded code), see Chapter 17.

Two excellent pages to read when working with the Standard C++ containers and threads are ! SGI's ! https://web.archive.org/web/20171221154911/http://www.sgi.com/tech/stl/thread_safety.html and ! SGI's ! https://web.archive.org/web/20171108142526/http://www.sgi.com/tech/stl/Allocators.html.

However, please ignore all discussions about the user-level configuration of the lock implementation inside the STL container-memory allocator on those pages. For the sake of this diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/html/manual/utilities.html gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/utilities.html *** gcc-13.4.0/libstdc++-v3/doc/html/manual/utilities.html Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/html/manual/utilities.html Fri Sep 4 07:35:12 2026 *************** *** 11,16 **** get slightly the wrong idea. In the interest of not reinventing the wheel, we will refer you to the introduction to the functor concept written by SGI as part of their STL, in ! their ! https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/functors.html.

Prev Up Next
Concept Checking Home Pairs
\ No newline at end of file --- 11,16 ---- get slightly the wrong idea. In the interest of not reinventing the wheel, we will refer you to the introduction to the functor concept written by SGI as part of their STL, in ! their ! https://web.archive.org/web/20171209002754/http://www.sgi.com/tech/stl/functors.html.

Prev Up Next
Concept Checking Home Pairs
\ No newline at end of file diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/xml/faq.xml gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/faq.xml *** gcc-13.4.0/libstdc++-v3/doc/xml/faq.xml Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/faq.xml Fri Sep 4 07:35:12 2026 *************** *** 1131,1137 **** Libstdc++-v3 incorporates a lot of code from the SGI STL (the final merge was from ! release 3.3). The code in libstdc++ contains many fixes and changes compared to the original SGI code. --- 1131,1137 ---- Libstdc++-v3 incorporates a lot of code from the SGI STL (the final merge was from ! release 3.3). The code in libstdc++ contains many fixes and changes compared to the original SGI code. diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/xml/manual/configure.xml gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/configure.xml *** gcc-13.4.0/libstdc++-v3/doc/xml/manual/configure.xml Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/configure.xml Fri Sep 4 07:35:12 2026 *************** *** 438,444 **** ! --enable-vtable-verify[default] Use -fvtable-verify=std to compile the C++ runtime with instrumentation for vtable verification. All virtual --- 438,444 ---- ! --enable-vtable-verify Use -fvtable-verify=std to compile the C++ runtime with instrumentation for vtable verification. All virtual diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/xml/manual/containers.xml gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/containers.xml *** gcc-13.4.0/libstdc++-v3/doc/xml/manual/containers.xml Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/containers.xml Fri Sep 4 07:35:12 2026 *************** *** 28,34 **** Yes it is, at least using the old ABI, and that's okay. This is a decision that we preserved when we imported SGI's STL implementation. The following is ! quoted from their FAQ:
--- 28,34 ---- Yes it is, at least using the old ABI, and that's okay. This is a decision that we preserved when we imported SGI's STL implementation. The following is ! quoted from their FAQ:
diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/xml/manual/extensions.xml gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/extensions.xml *** gcc-13.4.0/libstdc++-v3/doc/xml/manual/extensions.xml Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/extensions.xml Fri Sep 4 07:35:12 2026 *************** extensions, be aware of two things: *** 221,232 **** Each of the associative containers map, multimap, set, and multiset have a counterpart which uses a ! hashing function to do the arranging, instead of a strict weak ordering function. The classes take as one of their template parameters a function object that will return the hash value; by default, an instantiation of ! hash. You should specialize this functor for your class, or define your own, before trying to use one of the hashing classes. --- 221,232 ---- Each of the associative containers map, multimap, set, and multiset have a counterpart which uses a ! hashing function to do the arranging, instead of a strict weak ordering function. The classes take as one of their template parameters a function object that will return the hash value; by default, an instantiation of ! hash. You should specialize this functor for your class, or define your own, before trying to use one of the hashing classes. *************** get_temporary_buffer(5, (int*)0); *** 388,394 **** The iota function wins the award for Extension With the Coolest Name (the name comes from Ken Iverson's APL language.) As ! described in the SGI documentation, it "assigns sequentially increasing values to a range. That is, it assigns value to *first, value + 1 to *(first + 1) and so on." --- 388,394 ---- The iota function wins the award for Extension With the Coolest Name (the name comes from Ken Iverson's APL language.) As ! described in the SGI documentation, it "assigns sequentially increasing values to a range. That is, it assigns value to *first, value + 1 to *(first + 1) and so on." diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/xml/manual/status_cxx2011.xml gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/status_cxx2011.xml *** gcc-13.4.0/libstdc++-v3/doc/xml/manual/status_cxx2011.xml Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/status_cxx2011.xml Fri Sep 4 07:35:12 2026 *************** the GCC 13 release series. *** 2614,2619 **** --- 2614,2624 ---- + 20.8.11.1 [func.wrap.badcall] + what() returns "bad_function_call". + + + 20.8.9.1.3 [func.bind.place]/1 There are 29 placeholders defined and the placeholder types are CopyAssignable. diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/xml/manual/status_cxx2017.xml gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/status_cxx2017.xml *** gcc-13.4.0/libstdc++-v3/doc/xml/manual/status_cxx2017.xml Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/status_cxx2017.xml Fri Sep 4 07:35:12 2026 *************** since C++14 and the implementation is co *** 2918,2924 **** ! 23.12.5.2 [memory.resource.pool.options] Let S equal numeric_limits<size_t>::digits. The limit for maximum number of blocks in a chunk is given by 2N-1, --- 2918,2930 ---- ! 23.8.2 [any.bad_any_cast] ! what() returns "bad any_cast". ! ! ! ! 23.12.5 [mem.res.pool.options], ! 23.12.5 [mem.res.pool.mem] Let S equal numeric_limits<size_t>::digits. The limit for maximum number of blocks in a chunk is given by 2N-1, *************** since C++14 and the implementation is co *** 2931,2937 **** ! 23.12.6.1 [memory.resource.monotonic.buffer.ctor] The default next_buffer_size is 128 * sizeof(void*). The default growth factor is 1.5. --- 2937,2943 ---- ! 23.12.6.1 [mem.res.monotonic.buffer.ctor] The default next_buffer_size is 128 * sizeof(void*). The default growth factor is 1.5. *************** since C++14 and the implementation is co *** 2981,2992 **** 29.9.5 [sf.cmath] ! The effect of calling the mathematical special functions with large ! inputs should be documented here. ! 30.10.2.1 [fs.conform.9945] The behavior of the filesystem library implementation will depend on the target operating system. Some features will not be supported on some targets. Symbolic links and file permissions --- 2987,3004 ---- 29.9.5 [sf.cmath] ! Calling the mathematical special functions with large inputs is supported ! but the results may be imprecise. ! 30.7.5.2.3 [ostream.inserters] ! NTCTS for nullptr_t is "nullptr". ! ! ! ! 30.10.2.1 [fs.conform.9945], ! 30.10.2.2 [fs.conform.os] The behavior of the filesystem library implementation will depend on the target operating system. Some features will not be supported on some targets. Symbolic links and file permissions *************** since C++14 and the implementation is co *** 3023,3029 **** If !is_regular_file(p), an error is reported. ! 30.10.15.32 [fs.op.rename] On Windows, filesystem::rename is implemented by calling MoveFileExW and so --- 3035,3041 ---- If !is_regular_file(p), an error is reported. ! 30.10.15.32 [fs.op.rename] On Windows, filesystem::rename is implemented by calling MoveFileExW and so *************** since C++14 and the implementation is co *** 3032,3039 **** Specifically, it is not possible to rename a directory to replace another directory (POSIX requires that to work if the directory being replaced is empty). !
Parallelism 2 TS --- 3044,3067 ---- Specifically, it is not possible to rename a directory to replace another directory (POSIX requires that to work if the directory being replaced is empty). ! + + 30.10.29.2 [fs.enum.file_type], + 30.10.34.3 [fs.op.copy], + 30.10.34.35 [fs.op.status] + No additional file types are supported, and there are no + implementation-defined enumerators in + std::filesystem::file_type. + + + + 30.10.32 [fs.class.directory_iterator], + 30.10.33 [fs.class.rec.dir.itr] + Any directory-like file types supported by + opendir/readdir + (or _wopendir/_wreaddir on Windows). +
Parallelism 2 TS diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/xml/manual/using.xml gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/using.xml *** gcc-13.4.0/libstdc++-v3/doc/xml/manual/using.xml Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/using.xml Fri Sep 4 07:35:12 2026 *************** The standard places requirements on the *** 1796,1802 **** races are caused by the library itself or by programs which use the library correctly (as described below). The C++11 memory model and library requirements are a more formal version ! of the SGI STL definition of thread safety, which the library used prior to the 2011 standard. --- 1796,1802 ---- races are caused by the library itself or by programs which use the library correctly (as described below). The C++11 memory model and library requirements are a more formal version ! of the SGI STL definition of thread safety, which the library used prior to the 2011 standard. *************** gcc version 4.1.2 20070925 (Red Hat 4.1. *** 2081,2090 **** Two excellent pages to read when working with the Standard C++ containers and threads are ! SGI's ! https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/thread_safety.html and ! SGI's ! https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/Allocators.html. However, please ignore all discussions about the user-level configuration of the lock implementation inside the STL --- 2081,2090 ---- Two excellent pages to read when working with the Standard C++ containers and threads are ! SGI's ! https://web.archive.org/web/20171221154911/http://www.sgi.com/tech/stl/thread_safety.html and ! SGI's ! https://web.archive.org/web/20171108142526/http://www.sgi.com/tech/stl/Allocators.html. However, please ignore all discussions about the user-level configuration of the lock implementation inside the STL diff -Nrcpad gcc-13.4.0/libstdc++-v3/doc/xml/manual/utilities.xml gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/utilities.xml *** gcc-13.4.0/libstdc++-v3/doc/xml/manual/utilities.xml Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/doc/xml/manual/utilities.xml Fri Sep 4 07:35:12 2026 *************** *** 22,29 **** get slightly the wrong idea. In the interest of not reinventing the wheel, we will refer you to the introduction to the functor concept written by SGI as part of their STL, in ! their ! https://web.archive.org/web/20171225062613/http://www.sgi.com/tech/stl/functors.html.
--- 22,29 ---- get slightly the wrong idea. In the interest of not reinventing the wheel, we will refer you to the introduction to the functor concept written by SGI as part of their STL, in ! their ! https://web.archive.org/web/20171209002754/http://www.sgi.com/tech/stl/functors.html.
diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/atomic_wait.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/atomic_wait.h *** gcc-13.4.0/libstdc++-v3/include/bits/atomic_wait.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/atomic_wait.h Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 187,193 **** bool __atomic_compare(const _Tp& __a, const _Tp& __b) { // TODO make this do the correct padding bit ignoring comparison ! return __builtin_memcmp(&__a, &__b, sizeof(_Tp)) == 0; } struct __waiter_pool_base --- 187,194 ---- bool __atomic_compare(const _Tp& __a, const _Tp& __b) { // TODO make this do the correct padding bit ignoring comparison ! return __builtin_memcmp(std::addressof(__a), std::addressof(__b), ! sizeof(_Tp)) == 0; } struct __waiter_pool_base diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/basic_string.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/basic_string.h *** gcc-13.4.0/libstdc++-v3/include/bits/basic_string.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/basic_string.h Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_CXX11 *** 3227,3233 **** _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR _If_sv<_Tp, int> compare(size_type __pos, size_type __n, const _Tp& __svt) const - noexcept(is_same<_Tp, __sv_type>::value) { __sv_type __sv = __svt; return __sv_type(*this).substr(__pos, __n).compare(__sv); --- 3227,3232 ---- *************** _GLIBCXX_BEGIN_NAMESPACE_CXX11 *** 3248,3254 **** _If_sv<_Tp, int> compare(size_type __pos1, size_type __n1, const _Tp& __svt, size_type __pos2, size_type __n2 = npos) const - noexcept(is_same<_Tp, __sv_type>::value) { __sv_type __sv = __svt; return __sv_type(*this) --- 3247,3252 ---- diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/chrono.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/chrono.h *** gcc-13.4.0/libstdc++-v3/include/bits/chrono.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/chrono.h Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_INLINE_ABI_NAMESPACE(_V2) *** 1239,1244 **** --- 1239,1245 ---- now() noexcept; // Map to C API + [[__gnu__::__always_inline__]] static std::time_t to_time_t(const time_point& __t) noexcept { *************** _GLIBCXX_BEGIN_INLINE_ABI_NAMESPACE(_V2) *** 1246,1251 **** --- 1247,1253 ---- (__t.time_since_epoch()).count()); } + [[__gnu__::__always_inline__]] static time_point from_time_t(std::time_t __t) noexcept { diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/chrono_io.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/chrono_io.h *** gcc-13.4.0/libstdc++-v3/include/bits/chrono_io.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/chrono_io.h Fri Sep 4 07:35:12 2026 *************** namespace __detail *** 155,160 **** --- 155,161 ---- namespace __detail { // An unspecified type returned by `chrono::local_time_format`. + // This is called `local-time-format-t` in the standard. template struct __local_time_fmt { *************** namespace __detail *** 162,169 **** const string* _M_abbrev; const seconds* _M_offset_sec; }; - - struct __local_fmt_t; } /// @endcond --- 163,168 ---- *************** namespace __format *** 690,702 **** using ::std::chrono::__detail::__utc_leap_second; using ::std::chrono::__detail::__local_time_fmt; if constexpr (__is_specialization_of<_Tp, __local_time_fmt>) - return _M_format_to_ostream(__t._M_time, __fc, false); - else { ! basic_ostringstream<_CharT> __os; ! __os.imbue(_M_locale(__fc)); if constexpr (__is_specialization_of<_Tp, __utc_leap_second>) __os << __t._M_date << ' ' << __t._M_time; else if constexpr (chrono::__is_time_point_v<_Tp>) --- 689,722 ---- using ::std::chrono::__detail::__utc_leap_second; using ::std::chrono::__detail::__local_time_fmt; + basic_ostringstream<_CharT> __os; + __os.imbue(_M_locale(__fc)); + if constexpr (__is_specialization_of<_Tp, __local_time_fmt>) { ! // Format as "{:L%F %T}" ! auto __days = chrono::floor(__t._M_time); ! __os << chrono::year_month_day(__days) << ' ' ! << chrono::hh_mm_ss(__t._M_time - __days); + // For __local_time_fmt the __is_neg flags says whether to + // append " %Z" to the result. + if (__is_neg) + { + if (!__t._M_abbrev) [[unlikely]] + __format::__no_timezone_available(); + else if constexpr (is_same_v<_CharT, char>) + __os << ' ' << *__t._M_abbrev; + else + { + __os << L' '; + for (char __c : *__t._M_abbrev) + __os << __c; + } + } + } + else + { if constexpr (__is_specialization_of<_Tp, __utc_leap_second>) __os << __t._M_date << ' ' << __t._M_time; else if constexpr (chrono::__is_time_point_v<_Tp>) *************** namespace __format *** 708,713 **** --- 728,736 ---- // sys_time with period greater or equal to days: if constexpr (is_convertible_v<_Tp, chrono::sys_days>) __os << _S_date(__t); + // Or a local_time with period greater or equal to days: + else if constexpr (is_convertible_v<_Tp, chrono::local_days>) + __os << _S_date(__t); else // Or it's formatted as "{:L%F %T}": { auto __days = chrono::floor(__t); *************** namespace __format *** 722,732 **** __os << _S_plus_minus[1]; __os << __t; } - - auto __str = std::move(__os).str(); - return __format::__write_padded_as_spec(__str, __str.size(), - __fc, _M_spec); } } static constexpr const _CharT* _S_chars --- 745,755 ---- __os << _S_plus_minus[1]; __os << __t; } } + + auto __str = std::move(__os).str(); + return __format::__write_padded_as_spec(__str, __str.size(), + __fc, _M_spec); } static constexpr const _CharT* _S_chars *************** namespace __format *** 2023,2028 **** --- 2046,2053 ---- _FormatContext& __fc) const { // Convert to __local_time_fmt with abbrev "TAI" and offset 0s. + // We use __local_time_fmt and not sys_time (as the standard implies) + // because %Z for sys_time would print "UTC" and we want "TAI" here. // Offset is 1970y/January/1 - 1958y/January/1 constexpr chrono::days __tai_offset = chrono::days(4383); *************** namespace __format *** 2053,2058 **** --- 2078,2085 ---- _FormatContext& __fc) const { // Convert to __local_time_fmt with abbrev "GPS" and offset 0s. + // We use __local_time_fmt and not sys_time (as the standard implies) + // because %Z for sys_time would print "UTC" and we want "GPS" here. // Offset is 1980y/January/Sunday[1] - 1970y/January/1 constexpr chrono::days __gps_offset = chrono::days(3657); *************** namespace __format *** 2119,2125 **** typename _FormatContext::iterator format(const chrono::__detail::__local_time_fmt<_Duration>& __t, _FormatContext& __ctx) const ! { return _M_f._M_format(__t, __ctx); } private: __format::__formatter_chrono<_CharT> _M_f; --- 2146,2152 ---- typename _FormatContext::iterator format(const chrono::__detail::__local_time_fmt<_Duration>& __t, _FormatContext& __ctx) const ! { return _M_f._M_format(__t, __ctx, /* use %Z for {} */ true); } private: __format::__formatter_chrono<_CharT> _M_f; diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/cow_string.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/cow_string.h *** gcc-13.4.0/libstdc++-v3/include/bits/cow_string.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/cow_string.h Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 2813,2819 **** template _If_sv<_Tp, int> compare(size_type __pos, size_type __n, const _Tp& __svt) const - noexcept(is_same<_Tp, __sv_type>::value) { __sv_type __sv = __svt; return __sv_type(*this).substr(__pos, __n).compare(__sv); --- 2813,2818 ---- *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 2833,2839 **** _If_sv<_Tp, int> compare(size_type __pos1, size_type __n1, const _Tp& __svt, size_type __pos2, size_type __n2 = npos) const - noexcept(is_same<_Tp, __sv_type>::value) { __sv_type __sv = __svt; return __sv_type(*this) --- 2832,2837 ---- diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/forward_list.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/forward_list.h *** gcc-13.4.0/libstdc++-v3/include/bits/forward_list.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/forward_list.h Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_CONTAINER *** 669,675 **** void assign(_InputIterator __first, _InputIterator __last) { ! typedef is_assignable<_Tp, decltype(*__first)> __assignable; _M_assign(__first, __last, __assignable()); } --- 669,675 ---- void assign(_InputIterator __first, _InputIterator __last) { ! typedef is_assignable<_Tp&, decltype(*__first)> __assignable; _M_assign(__first, __last, __assignable()); } diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/ranges_algo.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/ranges_algo.h *** gcc-13.4.0/libstdc++-v3/include/bits/ranges_algo.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/ranges_algo.h Fri Sep 4 07:35:12 2026 *************** namespace ranges *** 561,569 **** for (auto __scan = __first1; __scan != __last1; ++__scan) { ! auto&& __proj_scan = std::__invoke(__proj1, *__scan); auto __comp_scan = [&] (_Tp&& __arg) -> bool { ! return std::__invoke(__pred, __proj_scan, std::forward<_Tp>(__arg)); }; if (__scan != ranges::find_if(__first1, __scan, --- 561,572 ---- for (auto __scan = __first1; __scan != __last1; ++__scan) { ! auto&& __scan_deref = *__scan; ! auto&& __proj_scan = ! std::__invoke(__proj1, std::forward(__scan_deref)); auto __comp_scan = [&] (_Tp&& __arg) -> bool { ! return std::__invoke(__pred, ! std::forward(__proj_scan), std::forward<_Tp>(__arg)); }; if (__scan != ranges::find_if(__first1, __scan, *************** namespace ranges *** 980,986 **** for (; __first != __last; ++__first) if (!std::__invoke(__pred, std::__invoke(__proj, *__first))) { ! *__result = std::move(*__first); ++__result; } --- 983,989 ---- for (; __first != __last; ++__first) if (!std::__invoke(__pred, std::__invoke(__proj, *__first))) { ! *__result = ranges::iter_move(__first); ++__result; } *************** namespace ranges *** 1134,1140 **** if (!std::__invoke(__comp, std::__invoke(__proj, *__dest), std::__invoke(__proj, *__first))) ! *++__dest = std::move(*__first); return {++__dest, __first}; } --- 1137,1143 ---- if (!std::__invoke(__comp, std::__invoke(__proj, *__dest), std::__invoke(__proj, *__first))) ! *++__dest = ranges::iter_move(__first); return {++__dest, __first}; } diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/regex_compiler.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/regex_compiler.h *** gcc-13.4.0/libstdc++-v3/include/bits/regex_compiler.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/regex_compiler.h Fri Sep 4 07:35:12 2026 *************** namespace __detail *** 170,178 **** _StateSeqT _M_pop() { ! auto ret = _M_stack.top(); _M_stack.pop(); ! return ret; } static _FlagT --- 170,178 ---- _StateSeqT _M_pop() { ! auto __ret = _M_stack.top(); _M_stack.pop(); ! return __ret; } static _FlagT diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/shared_ptr_base.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/shared_ptr_base.h *** gcc-13.4.0/libstdc++-v3/include/bits/shared_ptr_base.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/shared_ptr_base.h Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 2065,2071 **** __shared_ptr<_Tp, _Lp> lock() const noexcept ! { return __shared_ptr(*this, std::nothrow); } long use_count() const noexcept --- 2065,2071 ---- __shared_ptr<_Tp, _Lp> lock() const noexcept ! { return __shared_ptr<_Tp, _Lp>(*this, std::nothrow); } long use_count() const noexcept diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/stl_construct.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/stl_construct.h *** gcc-13.4.0/libstdc++-v3/include/bits/stl_construct.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/stl_construct.h Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 88,94 **** __location->~_Tp(); } ! #if __cplusplus >= 202002L template constexpr auto construct_at(_Tp* __location, _Args&&... __args) --- 88,94 ---- __location->~_Tp(); } ! #if __cpp_constexpr_dynamic_alloc // >= C++20 template constexpr auto construct_at(_Tp* __location, _Args&&... __args) *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 108,114 **** inline void _Construct(_Tp* __p, _Args&&... __args) { ! #if __cplusplus >= 202002L if (std::__is_constant_evaluated()) { // Allow std::_Construct to be used in constant expressions. --- 108,114 ---- inline void _Construct(_Tp* __p, _Args&&... __args) { ! #if __cpp_constexpr_dynamic_alloc // >= C++20 if (std::__is_constant_evaluated()) { // Allow std::_Construct to be used in constant expressions. *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 145,157 **** _GLIBCXX14_CONSTEXPR inline void _Destroy(_Tp* __pointer) { ! #if __cplusplus > 201703L std::destroy_at(__pointer); #else __pointer->~_Tp(); #endif } template struct _Destroy_aux { --- 145,161 ---- _GLIBCXX14_CONSTEXPR inline void _Destroy(_Tp* __pointer) { ! #if __cpp_constexpr_dynamic_alloc // >= C++20 std::destroy_at(__pointer); #else __pointer->~_Tp(); #endif } + #pragma GCC diagnostic push + #pragma GCC diagnostic ignored "-Wc++17-extensions" // for if-constexpr + + #if __cplusplus < 201103L template struct _Destroy_aux { *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 162,167 **** --- 166,180 ---- for (; __first != __last; ++__first) std::_Destroy(std::__addressof(*__first)); } + + template + static _GLIBCXX20_CONSTEXPR _ForwardIterator + __destroy_n(_ForwardIterator __first, _Size __count) + { + for (; __count > 0; (void)++__first, --__count) + std::_Destroy(std::__addressof(*__first)); + return __first; + } }; template<> *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 170,176 **** --- 183,198 ---- template static void __destroy(_ForwardIterator, _ForwardIterator) { } + + template + static _ForwardIterator + __destroy_n(_ForwardIterator __first, _Size __count) + { + std::advance(__first, __count); + return __first; + } }; + #endif /** * Destroy a range of objects. If the value_type of the object has *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 184,226 **** typedef typename iterator_traits<_ForwardIterator>::value_type _Value_type; #if __cplusplus >= 201103L ! // A deleted destructor is trivial, this ensures we reject such types: ! static_assert(is_destructible<_Value_type>::value, ! "value type is destructible"); ! #endif ! #if __cplusplus >= 202002L ! if (std::__is_constant_evaluated()) ! return std::_Destroy_aux::__destroy(__first, __last); #endif std::_Destroy_aux<__has_trivial_destructor(_Value_type)>:: __destroy(__first, __last); } - template - struct _Destroy_n_aux - { - template - static _GLIBCXX20_CONSTEXPR _ForwardIterator - __destroy_n(_ForwardIterator __first, _Size __count) - { - for (; __count > 0; (void)++__first, --__count) - std::_Destroy(std::__addressof(*__first)); - return __first; - } - }; - - template<> - struct _Destroy_n_aux - { - template - static _ForwardIterator - __destroy_n(_ForwardIterator __first, _Size __count) - { - std::advance(__first, __count); - return __first; - } - }; - /** * Destroy a range of objects. If the value_type of the object has * a trivial destructor, the compiler should optimize all of this --- 206,225 ---- typedef typename iterator_traits<_ForwardIterator>::value_type _Value_type; #if __cplusplus >= 201103L ! if constexpr (!is_trivially_destructible<_Value_type>::value) ! for (; __first != __last; ++__first) ! std::_Destroy(std::__addressof(*__first)); ! #if __cpp_constexpr_dynamic_alloc // >= C++20 ! else if (std::__is_constant_evaluated()) ! for (; __first != __last; ++__first) ! std::destroy_at(std::__addressof(*__first)); #endif + #else std::_Destroy_aux<__has_trivial_destructor(_Value_type)>:: __destroy(__first, __last); + #endif } /** * Destroy a range of objects. If the value_type of the object has * a trivial destructor, the compiler should optimize all of this *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 233,249 **** typedef typename iterator_traits<_ForwardIterator>::value_type _Value_type; #if __cplusplus >= 201103L ! // A deleted destructor is trivial, this ensures we reject such types: ! static_assert(is_destructible<_Value_type>::value, ! "value type is destructible"); ! #endif ! #if __cplusplus >= 202002L ! if (std::__is_constant_evaluated()) ! return std::_Destroy_n_aux::__destroy_n(__first, __count); #endif ! return std::_Destroy_n_aux<__has_trivial_destructor(_Value_type)>:: __destroy_n(__first, __count); } #if __cplusplus >= 201703L template --- 232,254 ---- typedef typename iterator_traits<_ForwardIterator>::value_type _Value_type; #if __cplusplus >= 201103L ! if constexpr (!is_trivially_destructible<_Value_type>::value) ! for (; __count > 0; (void)++__first, --__count) ! std::_Destroy(std::__addressof(*__first)); ! #if __cpp_constexpr_dynamic_alloc // >= C++20 ! else if (std::__is_constant_evaluated()) ! for (; __count > 0; (void)++__first, --__count) ! std::destroy_at(std::__addressof(*__first)); #endif ! else ! std::advance(__first, __count); ! return __first; ! #else ! return std::_Destroy_aux<__has_trivial_destructor(_Value_type)>:: __destroy_n(__first, __count); + #endif } + #pragma GCC diagnostic pop #if __cplusplus >= 201703L template diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/stl_pair.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/stl_pair.h *** gcc-13.4.0/libstdc++-v3/include/bits/stl_pair.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/stl_pair.h Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 302,308 **** /// Constructor accepting lvalues of `first_type` and `second_type` constexpr explicit(!_S_convertible()) ! pair(const _T1& __x, const _T2& __y) noexcept(_S_nothrow_constructible()) requires (_S_constructible()) : first(__x), second(__y) --- 302,308 ---- /// Constructor accepting lvalues of `first_type` and `second_type` constexpr explicit(!_S_convertible()) ! pair(const type_identity_t<_T1>& __x, const _T2& __y) noexcept(_S_nothrow_constructible()) requires (_S_constructible()) : first(__x), second(__y) *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 1067,1078 **** template constexpr _Tp&& get(pair<_Tp, _Up>&& __p) noexcept ! { return std::move(__p.first); } template constexpr const _Tp&& get(const pair<_Tp, _Up>&& __p) noexcept ! { return std::move(__p.first); } template constexpr _Tp& --- 1067,1078 ---- template constexpr _Tp&& get(pair<_Tp, _Up>&& __p) noexcept ! { return std::forward<_Tp>(__p.first); } template constexpr const _Tp&& get(const pair<_Tp, _Up>&& __p) noexcept ! { return std::forward(__p.first); } template constexpr _Tp& *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 1087,1098 **** template constexpr _Tp&& get(pair<_Up, _Tp>&& __p) noexcept ! { return std::move(__p.second); } template constexpr const _Tp&& get(const pair<_Up, _Tp>&& __p) noexcept ! { return std::move(__p.second); } #if __cplusplus > 202002L template constexpr _Tp&& get(pair<_Up, _Tp>&& __p) noexcept ! { return std::forward<_Tp>(__p.second); } template constexpr const _Tp&& get(const pair<_Up, _Tp>&& __p) noexcept ! { return std::forward(__p.second); } #if __cplusplus > 202002L template, + is_nothrow_move_constructible<_Compare>>::value) + : c(std::move(__q.c)), comp(std::move(__q.comp)) + { __q.c.clear(); } + + priority_queue& + operator=(priority_queue&& __q) + noexcept(__and_, + is_nothrow_move_assignable<_Compare>>::value) + { + c = std::move(__q.c); + __q.c.clear(); + comp = std::move(__q.comp); + return *this; + } + template> explicit priority_queue(const _Alloc& __a) *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 594,600 **** template> priority_queue(priority_queue&& __q, const _Alloc& __a) ! : c(std::move(__q.c), __a), comp(std::move(__q.comp)) { } #endif /** --- 614,621 ---- template> priority_queue(priority_queue&& __q, const _Alloc& __a) ! : c(std::move(__q.c), __a), comp(std::move(__q.comp)) ! { __q.c.clear(); } #endif /** *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 609,616 **** * the copy according to @a __x. * * For more information on function objects, see the ! * documentation on @link functors functor base ! * classes@endlink. */ #if __cplusplus < 201103L template --- 630,636 ---- * the copy according to @a __x. * * For more information on function objects, see the ! * documentation on @link functors functor base classes@endlink. */ #if __cplusplus < 201103L template diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/stl_vector.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/stl_vector.h *** gcc-13.4.0/libstdc++-v3/include/bits/stl_vector.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/stl_vector.h Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_CONTAINER *** 1034,1040 **** resize(size_type __new_size, const value_type& __x) { if (__new_size > size()) ! _M_fill_insert(end(), __new_size - size(), __x); else if (__new_size < size()) _M_erase_at_end(this->_M_impl._M_start + __new_size); } --- 1034,1040 ---- resize(size_type __new_size, const value_type& __x) { if (__new_size > size()) ! _M_fill_append(__new_size - size(), __x); else if (__new_size < size()) _M_erase_at_end(this->_M_impl._M_start + __new_size); } *************** _GLIBCXX_BEGIN_NAMESPACE_CONTAINER *** 1055,1061 **** resize(size_type __new_size, value_type __x = value_type()) { if (__new_size > size()) ! _M_fill_insert(end(), __new_size - size(), __x); else if (__new_size < size()) _M_erase_at_end(this->_M_impl._M_start + __new_size); } --- 1055,1061 ---- resize(size_type __new_size, value_type __x = value_type()) { if (__new_size > size()) ! _M_fill_append(__new_size - size(), __x); else if (__new_size < size()) _M_erase_at_end(this->_M_impl._M_start + __new_size); } *************** _GLIBCXX_BEGIN_NAMESPACE_CONTAINER *** 1805,1810 **** --- 1805,1815 ---- void _M_fill_insert(iterator __pos, size_type __n, const value_type& __x); + // Called by resize(n,x), and the _M_fill_insert(end(), n, x) + _GLIBCXX20_CONSTEXPR + void + _M_fill_append(size_type __n, const value_type& __x); + #if __cplusplus >= 201103L // Called by resize(n). _GLIBCXX20_CONSTEXPR diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/bits/vector.tcc gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/vector.tcc *** gcc-13.4.0/libstdc++-v3/include/bits/vector.tcc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/bits/vector.tcc Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_CONTAINER *** 531,538 **** { if (__n != 0) { ! if (size_type(this->_M_impl._M_end_of_storage ! - this->_M_impl._M_finish) >= __n) { #if __cplusplus < 201103L value_type __x_copy = __x; --- 531,540 ---- { if (__n != 0) { ! if (__position.base() == this->_M_impl._M_finish) ! _M_fill_append(__n, __x); ! else if (size_type(this->_M_impl._M_end_of_storage ! - this->_M_impl._M_finish) >= __n) { #if __cplusplus < 201103L value_type __x_copy = __x; *************** _GLIBCXX_BEGIN_NAMESPACE_CONTAINER *** 627,632 **** --- 629,688 ---- } } + template + _GLIBCXX20_CONSTEXPR + void + vector<_Tp, _Alloc>:: + _M_fill_append(size_type __n, const value_type& __x) + { + if (size_type(this->_M_impl._M_end_of_storage + - this->_M_impl._M_finish) >= __n) + { + _GLIBCXX_ASAN_ANNOTATE_GROW(__n); + this->_M_impl._M_finish = + std::__uninitialized_fill_n_a(this->_M_impl._M_finish, __n, __x, + _M_get_Tp_allocator()); + _GLIBCXX_ASAN_ANNOTATE_GREW(__n); + } + else + { + // Make local copies of these members because the compiler thinks + // the allocator can alter them if 'this' is globally reachable. + pointer __old_start = this->_M_impl._M_start; + pointer __old_finish = this->_M_impl._M_finish; + const size_type __old_size = __old_finish - __old_start; + + const size_type __len = + _M_check_len(__n, "vector::_M_fill_append"); + pointer __new_start(this->_M_allocate(__len)); + pointer __new_finish(__new_start + __old_size); + __try + { + // See _M_realloc_insert above. + __new_finish = std::__uninitialized_fill_n_a( + __new_finish, __n, __x, + _M_get_Tp_allocator()); + std::__uninitialized_move_if_noexcept_a( + __old_start, __old_finish, __new_start, + _M_get_Tp_allocator()); + } + __catch(...) + { + std::_Destroy(__new_start + __old_size, __new_finish, + _M_get_Tp_allocator()); + _M_deallocate(__new_start, __len); + __throw_exception_again; + } + std::_Destroy(__old_start, __old_finish, _M_get_Tp_allocator()); + _GLIBCXX_ASAN_ANNOTATE_REINIT; + _M_deallocate(__old_start, + this->_M_impl._M_end_of_storage - __old_start); + this->_M_impl._M_start = __new_start; + this->_M_impl._M_finish = __new_finish; + this->_M_impl._M_end_of_storage = __new_start + __len; + } + } + #if __cplusplus >= 201103L template _GLIBCXX20_CONSTEXPR diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/c_global/cmath gcc-13.5.0-RC-20260904/libstdc++-v3/include/c_global/cmath *** gcc-13.4.0/libstdc++-v3/include/c_global/cmath Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/c_global/cmath Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 3583,3592 **** { return std::__hypot3(__x, __y, __z); } template ! __gnu_cxx::__promoted_t<_Tp, _Up, _Vp> hypot(_Tp __x, _Up __y, _Vp __z) { ! using __type = __gnu_cxx::__promoted_t<_Tp, _Up, _Vp>; return std::__hypot3<__type>(__x, __y, __z); } --- 3583,3592 ---- { return std::__hypot3(__x, __y, __z); } template ! typename __gnu_cxx::__promote_3<_Tp, _Up, _Vp>::__type hypot(_Tp __x, _Up __y, _Vp __z) { ! using __type = typename __gnu_cxx::__promote_3<_Tp, _Up, _Vp>::__type; return std::__hypot3<__type>(__x, __y, __z); } diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/ext/pointer.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/ext/pointer.h *** gcc-13.4.0/libstdc++-v3/include/ext/pointer.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/ext/pointer.h Fri Sep 4 07:35:12 2026 *************** *** 38,43 **** --- 38,44 ---- #pragma GCC system_header + #include #if _GLIBCXX_HOSTED # include #endif diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/precompiled/extc++.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/precompiled/extc++.h *** gcc-13.4.0/libstdc++-v3/include/precompiled/extc++.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/precompiled/extc++.h Fri Sep 4 07:35:12 2026 *************** *** 37,43 **** #endif #include #include - #include #include #include #include --- 37,42 ---- diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/pstl/parallel_backend_tbb.h gcc-13.5.0-RC-20260904/libstdc++-v3/include/pstl/parallel_backend_tbb.h *** gcc-13.4.0/libstdc++-v3/include/pstl/parallel_backend_tbb.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/pstl/parallel_backend_tbb.h Fri Sep 4 07:35:12 2026 *************** class __root_task *** 521,527 **** friend class __func_task<_Func>; }; ! #else // TBB_INTERFACE_VERSION <= 12000 class __task : public tbb::detail::d1::task { protected: --- 521,527 ---- friend class __func_task<_Func>; }; ! #else // TBB_INTERFACE_VERSION > 12000 class __task : public tbb::detail::d1::task { protected: *************** class __func_task : public __task *** 656,665 **** _PSTL_ASSERT(__parent != nullptr); _PSTL_ASSERT(__parent->_M_refcount.load(std::memory_order_relaxed) > 0); ! if (--__parent->_M_refcount == 0) { _PSTL_ASSERT(__next == nullptr); - __alloc.deallocate(this, *__ed); return __parent; } --- 656,671 ---- _PSTL_ASSERT(__parent != nullptr); _PSTL_ASSERT(__parent->_M_refcount.load(std::memory_order_relaxed) > 0); ! ! auto __refcount = --__parent->_M_refcount; ! ! // Placing the deallocation after the refcount decrement allows another thread to proceed with tree ! // folding concurrently with this task cleanup. ! __alloc.deallocate(this, *__ed); ! ! if (__refcount == 0) { _PSTL_ASSERT(__next == nullptr); return __parent; } diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/std/atomic gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/atomic *** gcc-13.4.0/libstdc++-v3/include/std/atomic Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/atomic Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 230,242 **** atomic& operator=(const atomic&) = delete; atomic& operator=(const atomic&) volatile = delete; constexpr atomic(_Tp __i) noexcept : _M_i(__i) { ! #if __cplusplus >= 201402L && __has_builtin(__builtin_clear_padding) if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>()) ! __builtin_clear_padding(std::__addressof(_M_i)); #endif } operator _Tp() const noexcept { return load(); } --- 230,246 ---- atomic& operator=(const atomic&) = delete; atomic& operator=(const atomic&) volatile = delete; + #pragma GCC diagnostic push + #pragma GCC diagnostic ignored "-Wc++14-extensions" // constexpr ctor body constexpr atomic(_Tp __i) noexcept : _M_i(__i) { ! #if __has_builtin(__builtin_clear_padding) if _GLIBCXX17_CONSTEXPR (__atomic_impl::__maybe_has_padding<_Tp>()) ! if (!std::__is_constant_evaluated()) ! __builtin_clear_padding(std::__addressof(_M_i)); #endif } + #pragma GCC diagnostic pop operator _Tp() const noexcept { return load(); } *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 387,410 **** __cmpexch_failure_order(__m)); } #if __cpp_lib_atomic_wait ! void ! wait(_Tp __old, memory_order __m = memory_order_seq_cst) const noexcept ! { ! std::__atomic_wait_address_v(&_M_i, __old, ! [__m, this] { return this->load(__m); }); ! } ! // TODO add const volatile overload ! void ! notify_one() noexcept ! { std::__atomic_notify_address(&_M_i, false); } ! void ! notify_all() noexcept ! { std::__atomic_notify_address(&_M_i, true); } #endif // __cpp_lib_atomic_wait - }; #undef _GLIBCXX20_INIT --- 391,413 ---- __cmpexch_failure_order(__m)); } #if __cpp_lib_atomic_wait ! void ! wait(_Tp __old, memory_order __m = memory_order_seq_cst) const noexcept ! { ! std::__atomic_wait_address_v(std::addressof(_M_i), __old, ! [__m, this] { return this->load(__m); }); ! } ! // TODO add const volatile overload ! void ! notify_one() noexcept ! { std::__atomic_notify_address(std::addressof(_M_i), false); } ! void ! notify_all() noexcept ! { std::__atomic_notify_address(std::addressof(_M_i), true); } #endif // __cpp_lib_atomic_wait }; #undef _GLIBCXX20_INIT diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/std/chrono gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/chrono *** gcc-13.4.0/libstdc++-v3/include/std/chrono Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/chrono Fri Sep 4 07:35:12 2026 *************** namespace __detail *** 3253,3259 **** }; // The list above is known to be valid until (at least) this date // and only contains positive leap seconds. ! const sys_seconds __expires(1766880000s); // 2025-12-28 00:00:00 UTC #if _GLIBCXX_USE_CXX11_ABI || ! _GLIBCXX_USE_DUAL_ABI if (__ss > __expires) --- 3253,3259 ---- }; // The list above is known to be valid until (at least) this date // and only contains positive leap seconds. ! constexpr sys_seconds __expires(1798416000s); // 2026-12-28 00:00:00 UTC #if _GLIBCXX_USE_CXX11_ABI || ! _GLIBCXX_USE_DUAL_ABI if (__ss > __expires) diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/std/format gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/format *** gcc-13.4.0/libstdc++-v3/include/std/format Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/format Fri Sep 4 07:35:12 2026 *************** namespace __format *** 1738,1762 **** if (__grp.empty() && __point == __dot) return __lstr; // Locale uses '.' and no grouping. ! size_t __d = __str.find(__dot); ! size_t __e = min(__d, __str.find(__exp)); if (__e == __str.npos) __e = __str.size(); ! const size_t __r = __str.size() - __e; auto __overwrite = [&](_CharT* __p, size_t) { ! auto __end = std::__add_grouping(__p, __np.thousands_sep(), __grp.data(), __grp.size(), ! __str.data(), __str.data() + __e); ! if (__r) { if (__d != __str.npos) { ! *__end = __point; ++__end; ++__e; } ! if (__r > 1) ! __end += __str.copy(__end, __str.npos, __e); } return (__end - __p); }; --- 1738,1772 ---- if (__grp.empty() && __point == __dot) return __lstr; // Locale uses '.' and no grouping. ! size_t __d = __str.find(__dot); // Index of radix character (if any). ! size_t __e = min(__d, __str.find(__exp)); // First of radix or exponent if (__e == __str.npos) __e = __str.size(); ! const size_t __r = __str.size() - __e; // Length of remainder. auto __overwrite = [&](_CharT* __p, size_t) { ! // Apply grouping to the digits before the radix or exponent. ! int __off = 0; ! if (auto __c = __str.front(); __c == '-' || __c == '+' || __c == ' ') ! { ! *__p = __c; ! __off = 1; ! } ! auto __end = std::__add_grouping(__p + __off, __np.thousands_sep(), __grp.data(), __grp.size(), ! __str.data() + __off, ! __str.data() + __e); ! if (__r) // If there's a fractional part or exponent { if (__d != __str.npos) { ! *__end = __point; // Add the locale's radix character. ++__end; ++__e; } ! const size_t __rlen = __str.size() - __e; ! // Append fractional digits and/or exponent: ! char_traits<_CharT>::copy(__end, __str.data() + __e, __rlen); ! __end += __rlen; } return (__end - __p); }; diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/std/numbers gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/numbers *** gcc-13.4.0/libstdc++-v3/include/std/numbers Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/numbers Fri Sep 4 07:35:12 2026 *************** __glibcxx_numbers (_Float64, F64); *** 215,221 **** __glibcxx_numbers (_Float128, F128); #endif ! #ifdef __STDCPP_BFLOAT128_T__ __glibcxx_numbers (__gnu_cxx::__bfloat16_t, BF16); #endif --- 215,221 ---- __glibcxx_numbers (_Float128, F128); #endif ! #ifdef __STDCPP_BFLOAT16_T__ __glibcxx_numbers (__gnu_cxx::__bfloat16_t, BF16); #endif diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/std/spanstream gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/spanstream *** gcc-13.4.0/libstdc++-v3/include/std/spanstream Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/spanstream Fri Sep 4 07:35:12 2026 *************** template __s, ios_base::openmode __which = ios_base::out) : __ostream_type(std::__addressof(_M_sb)), ! _M_sb(__s, __which | ios_base::in) { } basic_ospanstream(const basic_ospanstream&) = delete; --- 331,337 ---- basic_ospanstream(std::span<_CharT> __s, ios_base::openmode __which = ios_base::out) : __ostream_type(std::__addressof(_M_sb)), ! _M_sb(__s, __which | ios_base::out) { } basic_ospanstream(const basic_ospanstream&) = delete; diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/std/sstream gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/sstream *** gcc-13.4.0/libstdc++-v3/include/std/sstream Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/sstream Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_CXX11 *** 273,280 **** { if (char_type* __hi = _M_high_mark()) { ! // Set length to end of character sequence and add null terminator. ! _M_string._M_set_length(_M_high_mark() - this->pbase()); } auto __str = std::move(_M_string); _M_string.clear(); --- 273,283 ---- { if (char_type* __hi = _M_high_mark()) { ! if (_M_string.data() == this->pbase()) [[likely]] ! // Set length to end of sequence and add null terminator. ! _M_string._M_set_length(__hi - this->pbase()); ! else ! _M_string.assign(this->pbase(), __hi); } auto __str = std::move(_M_string); _M_string.clear(); diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/std/streambuf gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/streambuf *** gcc-13.4.0/libstdc++-v3/include/std/streambuf Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/streambuf Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 488,493 **** --- 488,497 ---- char_type* eback() const { return _M_in_beg; } + // Required to silence false-positive warnings originating from istream_iterator::operator++, + // see PR105580. + #pragma GCC diagnostic push + #pragma GCC diagnostic ignored "-Wnull-dereference" char_type* gptr() const { return _M_in_cur; } *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 503,508 **** --- 507,513 ---- */ void gbump(int __n) { _M_in_cur += __n; } + #pragma GCC diagnostic pop /** * @brief Setting the three read area pointers. diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/std/string_view gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/string_view *** gcc-13.4.0/libstdc++-v3/include/std/string_view Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/string_view Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_END_NAMESPACE_VERSION *** 904,909 **** #include ! #endif // __cplusplus <= 201402L ! #endif // _GLIBCXX_EXPERIMENTAL_STRING_VIEW --- 904,909 ---- #include ! #endif // C++17 ! #endif // _GLIBCXX_STRING_VIEW diff -Nrcpad gcc-13.4.0/libstdc++-v3/include/std/tuple gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/tuple *** gcc-13.4.0/libstdc++-v3/include/std/tuple Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/include/std/tuple Fri Sep 4 07:35:12 2026 *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 871,884 **** template= 1), _ImplicitCtor<_NotEmpty, const _Elements&...> = true> constexpr ! tuple(const _Elements&... __elements) noexcept(__nothrow_constructible()) : _Inherited(__elements...) { } template= 1), _ExplicitCtor<_NotEmpty, const _Elements&...> = false> explicit constexpr ! tuple(const _Elements&... __elements) noexcept(__nothrow_constructible()) : _Inherited(__elements...) { } --- 871,884 ---- template= 1), _ImplicitCtor<_NotEmpty, const _Elements&...> = true> constexpr ! tuple(const __type_identity_t<_Elements>&... __elements) noexcept(__nothrow_constructible()) : _Inherited(__elements...) { } template= 1), _ExplicitCtor<_NotEmpty, const _Elements&...> = false> explicit constexpr ! tuple(const __type_identity_t<_Elements>&... __elements) noexcept(__nothrow_constructible()) : _Inherited(__elements...) { } *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 982,988 **** _ImplicitCtor<_NotEmpty, const _Elements&...> = true> _GLIBCXX20_CONSTEXPR tuple(allocator_arg_t __tag, const _Alloc& __a, ! const _Elements&... __elements) : _Inherited(__tag, __a, __elements...) { } template= 1), --- 982,988 ---- _ImplicitCtor<_NotEmpty, const _Elements&...> = true> _GLIBCXX20_CONSTEXPR tuple(allocator_arg_t __tag, const _Alloc& __a, ! const __type_identity_t<_Elements>&... __elements) : _Inherited(__tag, __a, __elements...) { } template= 1), *************** _GLIBCXX_BEGIN_NAMESPACE_VERSION *** 990,996 **** _GLIBCXX20_CONSTEXPR explicit tuple(allocator_arg_t __tag, const _Alloc& __a, ! const _Elements&... __elements) : _Inherited(__tag, __a, __elements...) { } template&... __elements) : _Inherited(__tag, __a, __elements...) { } template$' % template_name, x) is not None class LibStdCxxXMethod(gdb.xmethod.XMethod): def __init__(self, name, worker_class): --- 37,43 ---- """ if isinstance(x, gdb.Type): x = x.tag ! return re.match(r'^std::(__\d::|__debug::)?%s<.*>$' % template_name, x) is not None class LibStdCxxXMethod(gdb.xmethod.XMethod): def __init__(self, name, worker_class): *************** class ListMethodsMatcher(gdb.xmethod.XMe *** 445,451 **** if method is None or not method.enabled: return None val_type = class_type.template_argument(0) ! node_type = gdb.lookup_type(str(class_type) + '::_Node').pointer() return method.worker_class(val_type, node_type) # Xmethods for std::vector --- 442,448 ---- if method is None or not method.enabled: return None val_type = class_type.template_argument(0) ! node_type = gdb.lookup_type(str(class_type) + '::_Node_ptr') return method.worker_class(val_type, node_type) # Xmethods for std::vector diff -Nrcpad gcc-13.4.0/libstdc++-v3/src/c++17/fs_path.cc gcc-13.5.0-RC-20260904/libstdc++-v3/src/c++17/fs_path.cc *** gcc-13.4.0/libstdc++-v3/src/c++17/fs_path.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/src/c++17/fs_path.cc Fri Sep 4 07:35:12 2026 *************** path::operator+=(const path& p) *** 866,871 **** --- 866,883 ---- return *this; } + // Handle p += p which would otherwise access dangling pointers after + // reallocating _M_cmpts and _M_pathname. + if (&p == this) [[unlikely]] + return *this += p.native(); + // Handle p += *i where i is in [p.begin(),p.end()), for the same reason. + if (_M_type() == _Type::_Multi && p._M_type() != _Type::_Multi) + { + const auto first = _M_cmpts.begin(), last = first + _M_cmpts.size(); + if (!std::less<>()(&p, first) && std::less<>()(&p, last)) [[unlikely]] + return *this += p.native(); + } + #if _GLIBCXX_FILESYSTEM_IS_WINDOWS if (_M_type() == _Type::_Root_name || (_M_type() == _Type::_Filename && _M_pathname.size() == 1)) diff -Nrcpad gcc-13.4.0/libstdc++-v3/src/c++17/memory_resource.cc gcc-13.5.0-RC-20260904/libstdc++-v3/src/c++17/memory_resource.cc *** gcc-13.4.0/libstdc++-v3/src/c++17/memory_resource.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/src/c++17/memory_resource.cc Fri Sep 4 07:35:12 2026 *************** namespace pmr *** 178,185 **** // versions will not use this symbol. monotonic_buffer_resource::~monotonic_buffer_resource() { release(); } ! namespace { ! // aligned_size stores the size and alignment of a memory allocation. // The size must be a multiple of N, leaving the low log2(N) bits free // to store the base-2 logarithm of the alignment. --- 178,185 ---- // versions will not use this symbol. monotonic_buffer_resource::~monotonic_buffer_resource() { release(); } ! namespace ! { // aligned_size stores the size and alignment of a memory allocation. // The size must be a multiple of N, leaving the low log2(N) bits free // to store the base-2 logarithm of the alignment. *************** namespace pmr *** 217,223 **** return (n + alignment - 1) & ~(alignment - 1); } ! } // namespace // Memory allocated by the upstream resource is managed in a linked list // of _Chunk objects. A _Chunk object recording the size and alignment of --- 217,223 ---- return (n + alignment - 1) & ~(alignment - 1); } ! } // namespace // Memory allocated by the upstream resource is managed in a linked list // of _Chunk objects. A _Chunk object recording the size and alignment of *************** namespace pmr *** 303,310 **** // Helper types for synchronized_pool_resource & unsynchronized_pool_resource ! namespace { ! // Simple bitset with runtime size. // Tracks which blocks in a pool chunk are used/unused. struct bitset --- 303,310 ---- // Helper types for synchronized_pool_resource & unsynchronized_pool_resource ! namespace ! { // Simple bitset with runtime size. // Tracks which blocks in a pool chunk are used/unused. struct bitset *************** namespace pmr *** 631,637 **** static_assert(sizeof(big_block) == (2 * sizeof(void*))); ! } // namespace // A pool that serves blocks of a particular size. // Each pool manages a number of chunks. --- 631,637 ---- static_assert(sizeof(big_block) == (2 * sizeof(void*))); ! } // namespace // A pool that serves blocks of a particular size. // Each pool manages a number of chunks. *************** namespace pmr *** 863,869 **** using big_block::big_block; }; ! namespace { constexpr size_t pool_sizes[] = { 8, 16, 24, --- 863,878 ---- using big_block::big_block; }; ! namespace ! { ! // N.B. it is important that we don't skip any power of two sizes if there ! // is a non-power of two size between them, e.g. must not have pool sizes ! // of 24 and 40 without having a pool size of 32. Otherwise an allocation ! // of 32 bytes with alignment 16 would choose the 40-byte pool which is not ! // correctly aligned for 16-byte alignment. It would be OK (but suboptimal) ! // to have no pool of size 32 if we have pool sizes of 16 and 64 and no ! // non-power of two sizes between those, because the example of (32, 16) ! // would choose the 64-byte pool, which would be correctly aligned. constexpr size_t pool_sizes[] = { 8, 16, 24, *************** namespace pmr *** 978,984 **** using exclusive_lock = lock_guard; #endif ! } // namespace __pool_resource:: __pool_resource(const pool_options& opts, memory_resource* upstream) --- 987,993 ---- using exclusive_lock = lock_guard; #endif ! } // namespace __pool_resource:: __pool_resource(const pool_options& opts, memory_resource* upstream) *************** namespace pmr *** 1070,1081 **** return p; } #ifdef _GLIBCXX_HAS_GTHREADS // synchronized_pool_resource members. /* Notes on implementation and thread safety: * ! * Each synchronized_pool_resource manages an linked list of N+1 _TPools * objects, where N is the number of threads using the pool resource. * Each _TPools object has its own set of pools, with their own chunks. * The first element of the list, _M_tpools[0], can be used by any thread. --- 1079,1111 ---- return p; } + // Determine the appropriate allocation size, rounding up to a multiple + // of the alignment if needed. + static inline size_t + choose_block_size(size_t bytes, size_t alignment) + { + if (bytes == 0) [[unlikely]] + return alignment; + + // Use bit_ceil in case alignment is invalid (i.e. not a power of two). + size_t mask = std::__bit_ceil(alignment) - 1; + // Round up to a multiple of alignment. + size_t block_size = (bytes + mask) & ~mask; + + if (block_size >= bytes) [[likely]] + return block_size; + + // Wrapped around to zero, bytes must have been impossibly large. + return numeric_limits::max(); + } + + #ifdef _GLIBCXX_HAS_GTHREADS // synchronized_pool_resource members. /* Notes on implementation and thread safety: * ! * Each synchronized_pool_resource manages a linked list of N+1 _TPools * objects, where N is the number of threads using the pool resource. * Each _TPools object has its own set of pools, with their own chunks. * The first element of the list, _M_tpools[0], can be used by any thread. *************** namespace pmr *** 1242,1248 **** synchronized_pool_resource:: do_allocate(size_t bytes, size_t alignment) { ! const auto block_size = std::max(bytes, alignment); const pool_options opts = _M_impl._M_opts; if (block_size <= opts.largest_required_pool_block) { --- 1272,1278 ---- synchronized_pool_resource:: do_allocate(size_t bytes, size_t alignment) { ! const auto block_size = choose_block_size(bytes, alignment); const pool_options opts = _M_impl._M_opts; if (block_size <= opts.largest_required_pool_block) { *************** namespace pmr *** 1289,1295 **** synchronized_pool_resource:: do_deallocate(void* p, size_t bytes, size_t alignment) { ! size_t block_size = std::max(bytes, alignment); if (block_size <= _M_impl._M_opts.largest_required_pool_block) { const ptrdiff_t index = pool_index(block_size, _M_impl._M_npools); --- 1319,1325 ---- synchronized_pool_resource:: do_deallocate(void* p, size_t bytes, size_t alignment) { ! size_t block_size = choose_block_size(bytes, alignment); if (block_size <= _M_impl._M_opts.largest_required_pool_block) { const ptrdiff_t index = pool_index(block_size, _M_impl._M_npools); *************** namespace pmr *** 1448,1454 **** void* unsynchronized_pool_resource::do_allocate(size_t bytes, size_t alignment) { ! const auto block_size = std::max(bytes, alignment); if (block_size <= _M_impl._M_opts.largest_required_pool_block) { // Recreate pools if release() has been called: --- 1478,1484 ---- void* unsynchronized_pool_resource::do_allocate(size_t bytes, size_t alignment) { ! const auto block_size = choose_block_size(bytes, alignment); if (block_size <= _M_impl._M_opts.largest_required_pool_block) { // Recreate pools if release() has been called: *************** namespace pmr *** 1465,1471 **** unsynchronized_pool_resource:: do_deallocate(void* p, size_t bytes, size_t alignment) { ! size_t block_size = std::max(bytes, alignment); if (block_size <= _M_impl._M_opts.largest_required_pool_block) { if (auto pool = _M_find_pool(block_size)) --- 1495,1501 ---- unsynchronized_pool_resource:: do_deallocate(void* p, size_t bytes, size_t alignment) { ! size_t block_size = choose_block_size(bytes, alignment); if (block_size <= _M_impl._M_opts.largest_required_pool_block) { if (auto pool = _M_find_pool(block_size)) diff -Nrcpad gcc-13.4.0/libstdc++-v3/src/c++20/tzdata.zi gcc-13.5.0-RC-20260904/libstdc++-v3/src/c++20/tzdata.zi *** gcc-13.4.0/libstdc++-v3/src/c++20/tzdata.zi Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/src/c++20/tzdata.zi Fri Sep 4 07:35:12 2026 *************** *** 1,4 **** ! # version 2025b # This zic input file is in the public domain. R d 1916 o - Jun 14 23s 1 S R d 1916 1919 - O Su>=1 23s 0 - --- 1,5 ---- ! # version 2026a ! # redo posix_only # This zic input file is in the public domain. R d 1916 o - Jun 14 23s 1 S R d 1916 1919 - O Su>=1 23s 0 - *************** R MT 1974 o - S 16 0s 0 - *** 1304,1311 **** R MT 1975 1979 - Ap Su>=15 2 1 S R MT 1975 1980 - S Su>=15 2 0 - R MT 1980 o - Mar 31 2 1 S ! R MD 1997 ma - Mar lastSu 2 1 S ! R MD 1997 ma - O lastSu 3 0 - R O 1918 1919 - S 16 2s 0 - R O 1919 o - Ap 15 2s 1 S R O 1944 o - Ap 3 2s 1 S --- 1305,1312 ---- R MT 1975 1979 - Ap Su>=15 2 1 S R MT 1975 1980 - S Su>=15 2 0 - R MT 1980 o - Mar 31 2 1 S ! R MD 1997 2021 - Mar lastSu 2 1 S ! R MD 1997 2021 - O lastSu 3 0 - R O 1918 1919 - S 16 2s 0 - R O 1919 o - Ap 15 2s 1 S R O 1944 o - Ap 3 2s 1 S *************** Z America/Tijuana -7:48:4 - LMT 1922 Ja *** 2951,2959 **** -8 1 PDT 1951 S 30 2 -8 - PST 1952 Ap 27 2 -8 1 PDT 1952 S 28 2 ! -8 - PST 1954 ! -8 CA P%sT 1961 ! -8 - PST 1976 -8 u P%sT 1996 -8 m P%sT 2001 -8 u P%sT 2002 F 20 --- 2952,2958 ---- -8 1 PDT 1951 S 30 2 -8 - PST 1952 Ap 27 2 -8 1 PDT 1952 S 28 2 ! -8 CA P%sT 1967 -8 u P%sT 1996 -8 m P%sT 2001 -8 u P%sT 2002 F 20 *************** Z Europe/Chisinau 1:55:20 - LMT 1880 *** 3668,3674 **** 3 R MSK/MSD 1990 May 6 2 2 R EE%sT 1992 2 e EE%sT 1997 ! 2 MD EE%sT Z Europe/Dublin -0:25:21 - LMT 1880 Au 2 -0:25:21 - DMT 1916 May 21 2s -0:25:21 1 IST 1916 O 1 2s --- 3667,3674 ---- 3 R MSK/MSD 1990 May 6 2 2 R EE%sT 1992 2 e EE%sT 1997 ! 2 MD EE%sT 2022 ! 2 E EE%sT Z Europe/Dublin -0:25:21 - LMT 1880 Au 2 -0:25:21 - DMT 1916 May 21 2s -0:25:21 1 IST 1916 O 1 2s diff -Nrcpad gcc-13.4.0/libstdc++-v3/src/c++20/tzdb.cc gcc-13.5.0-RC-20260904/libstdc++-v3/src/c++20/tzdb.cc *** gcc-13.4.0/libstdc++-v3/src/c++20/tzdb.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/src/c++20/tzdb.cc Fri Sep 4 07:35:12 2026 *************** *** 35,43 **** #include // atomic, atomic #include // atomic> #include // mutex ! #include // filesystem::read_symlink ! #ifndef _AIX # include // getenv #endif --- 35,47 ---- #include // atomic, atomic #include // atomic> #include // mutex ! #include // quoted ! #if defined(_GLIBCXX_HAVE_READLINK) && defined(_GLIBCXX_HAVE_UNISTD_H) ! # include // readlink ! #endif ! ! #ifdef _AIX # include // getenv #endif *************** namespace std::chrono *** 1191,1198 **** pair, bool> tzdb_list::_Node::_S_read_leap_seconds() { ! // This list is valid until at least 2025-12-28 00:00:00 UTC. ! auto expires = sys_days{2025y/12/28}; vector leaps { (leap_second) 78796800, // 1 Jul 1972 --- 1195,1202 ---- pair, bool> tzdb_list::_Node::_S_read_leap_seconds() { ! // This list is valid until at least 2026-12-28 00:00:00 UTC. ! constexpr auto expires = sys_days{2026y/12/28}; vector leaps { (leap_second) 78796800, // 1 Jul 1972 *************** namespace std::chrono *** 1737,1764 **** tzdb::current_zone() const { // TODO cache this function's result? #ifndef _AIX ! // Repeat the preprocessor condition used by filesystem::read_symlink, ! // to avoid a dependency on src/c++17/fs_ops.o if it won't work anyway. ! #if defined(_GLIBCXX_HAVE_READLINK) && defined(_GLIBCXX_HAVE_SYS_STAT_H) ! error_code ec; ! // This should be a symlink to e.g. /usr/share/zoneinfo/Europe/London ! auto path = filesystem::read_symlink("/etc/localtime", ec); ! if (!ec) { ! auto first = path.begin(), last = path.end(); ! if (std::distance(first, last) > 2) { ! --last; ! string name = last->string(); ! if (auto tz = do_locate_zone(this->zones, this->links, name)) ! return tz; ! --last; ! name = last->string() + '/' + name; ! if (auto tz = do_locate_zone(this->zones, this->links, name)) return tz; } } #endif // Otherwise, look for a file naming the time zone. --- 1741,1828 ---- tzdb::current_zone() const { // TODO cache this function's result? + // Could check the modification time of /etc/localtime, and not re-read + // it if it hasn't changed. reload_tzdb() could clear the cache too, + // to have a way to force a re-read. #ifndef _AIX ! #if defined(_GLIBCXX_HAVE_READLINK) && defined(_GLIBCXX_HAVE_UNISTD_H) ! string_view str; ! char buf[128]; // strlen("../usr/share/zoneinfo/...") is usually < 55 ! string dynbuf; ! // /etc/localtime should be a symlink that ends with a zone name, ! // e.g. /etc/localtime -> /usr/share/zoneinfo/Europe/London ! // https://www.freedesktop.org/software/systemd/man/latest/localtime.html ! // This should work on GNU/Linux, macOS, NetBSD, and OpenBSD. ! // Some FreeBSD systems also use a symlink for /etc/localtime. ! // Use readlink directly to avoid std::filesystem overhead. ! if (auto n = ::readlink("/etc/localtime", buf, sizeof(buf)); n > 0) { ! if (static_cast(n) < sizeof(buf)) ! str = string_view(buf, n); ! else [[unlikely]] { ! // We read the symlink but it didn't fit in buf[], use dynbuf. ! do ! { ! n *= 2; ! dynbuf.resize(n); ! // In gcc-14 and later this uses dynbuf.__resize_and_overwrite: ! { ! auto n2 = ::readlink("/etc/localtime", dynbuf.data(), n); ! if (n2 == -1) // symlink removed or replaced by file?! ! __throw_runtime_error("tzdb: error reading /etc/localtime"); ! dynbuf.resize(n2 < n ? n2 : 0); ! } ! } ! while (dynbuf.empty()); ! str = dynbuf; ! } ! } ! ! if (!str.empty()) ! { ! // Remove any redundant slashes so we can match zone names. ! // e.g. /usr/share/zoneinfo/Europe//London is a valid symlink, ! // but won't match against "Europe/London". ! if (auto pos = str.rfind("//"); pos != str.npos) [[unlikely]] ! { ! if (str.data() != dynbuf.data()) ! dynbuf = str; ! string::size_type spos = pos; ! do ! { ! dynbuf.erase(spos, 1); ! spos = dynbuf.rfind("//", spos); ! } ! while (spos != dynbuf.npos); ! str = dynbuf; ! } ! ! // Check the trailing components of the path against known zone names. ! // Valid IANA times zones can have one, two, or three parts, e.g. ! // "UTC", "Europe/London", and "America/Indiana/Indianapolis". ! // Custom tzdata.zi files could in theory use four or more parts. ! ! auto pos = str.rfind('/'); ! while (pos != str.npos && pos != 0) ! { ! if (auto tz = do_locate_zone(this->zones, this->links, ! str.substr(pos + 1))) return tz; + pos = str.rfind('/', pos - 1); } + // If we didn't match yet, try once more so that we will match + // a symlink to a relative path such as "Europe/London" + // or symlink to an absolute path such as "/Europe/London". + // Both cases seem unlikely because it would require either + // /etc/Europe or /Europe to be a directory (or a symlink to one) + // containing the TZif files, but it's theoretically possible. + // If pos==npos then pos+1 wraps to 0 and we use the whole string. + // If pos==0 then substr(1) discards the leading slash. + if (auto tz = do_locate_zone(this->zones, this->links, + str.substr(pos + 1))) + return tz; } #endif // Otherwise, look for a file naming the time zone. *************** namespace std::chrono *** 1795,1801 **** return tz; } } ! #else // AIX stores current zone in $TZ in /etc/environment but the value // is typically a POSIX time zone name, not IANA zone. // https://developer.ibm.com/articles/au-aix-posix/ --- 1859,1870 ---- return tz; } } ! ! // FIXME: For DragonFly BSD /etc/localtime is a copy of one of the ! // zone files in /usr/share/zoneinfo so we need to compare its contents ! // to each one until we find a match. ! ! #else // _AIX // AIX stores current zone in $TZ in /etc/environment but the value // is typically a POSIX time zone name, not IANA zone. // https://developer.ibm.com/articles/au-aix-posix/ diff -Nrcpad gcc-13.4.0/libstdc++-v3/src/filesystem/ops-common.h gcc-13.5.0-RC-20260904/libstdc++-v3/src/filesystem/ops-common.h *** gcc-13.4.0/libstdc++-v3/src/filesystem/ops-common.h Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/src/filesystem/ops-common.h Fri Sep 4 07:35:12 2026 *************** namespace __gnu_posix *** 155,164 **** if (MoveFileExW(oldname, newname, MOVEFILE_REPLACE_EXISTING | MOVEFILE_COPY_ALLOWED)) return 0; ! if (GetLastError() == ERROR_ACCESS_DENIED) ! errno = EACCES; ! else ! errno = EIO; return -1; } --- 155,161 ---- if (MoveFileExW(oldname, newname, MOVEFILE_REPLACE_EXISTING | MOVEFILE_COPY_ALLOWED)) return 0; ! errno = std::__last_system_error().default_error_condition().value(); return -1; } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/pair/astuple/get_by_type.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/pair/astuple/get_by_type.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/pair/astuple/get_by_type.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/pair/astuple/get_by_type.cc Fri Sep 4 07:35:12 2026 *************** void test01() *** 33,35 **** --- 33,87 ---- const int&& cpsecond __attribute__((unused)) = std::get(std::move(cp)); } + + // PR libstdc++/121745 return of get(pair<_Up, _Tp>&& __p) may be ill-formed + void + test_pr121745(std::pair p) + { + float& pfirst = std::get(std::move(p)); + int& psecond = std::get(std::move(p)); + + const auto& p2 = p; + float& p2first = std::get(std::move(p2)); + int& p2second = std::get(std::move(p2)); + } + + template + using get_t = decltype(std::get(std::declval())); + + // Check that get(Pair) returns Ret + template + constexpr bool verify = std::is_same, Ret>::value; + + template + void + check() + { + // Overloads for accessing first member + static_assert( verify&, T1&>, + "T1& get(pair&)" ); + static_assert( verify&, const T1&>, + "const T1& get(const pair&)" ); + static_assert( verify&&, T1&&>, + "T1&& get(pair&&)" ); + static_assert( verify&&, const T1&&>, + "const T1&& get(const pair&&)" ); + + // Overloads for accessing second member + static_assert( verify&, T2&>, + "T2& get(pair&)" ); + static_assert( verify&, const T2&>, + "const T2& get(const pair&)" ); + static_assert( verify&&, T2&&>, + "T2&& get(pair&&)" ); + static_assert( verify&&, const T2&&>, + "const T2&& get(const pair&&)" ); + } + + void + test_all() + { + check(); + check(); + check(); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/pair/cons/110853.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/pair/cons/110853.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/pair/cons/110853.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/pair/cons/110853.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,10 ---- + // { dg-do compile { target c++17 } } + // PR libstdc++/110853 + // Bad interaction between deduction guide with decay and constraints + // (CTAD, std::pair and function lvalue) + + #include + + void func() {} + std::pair p(1, func); + std::pair& r = p; diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/shared_ptr/requirements/1.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/shared_ptr/requirements/1.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/shared_ptr/requirements/1.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/shared_ptr/requirements/1.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,33 ---- + // { dg-do compile { target c++11 } } + // { dg-require-effective-target hosted } + + #include + #include + + using namespace __gnu_test; + + void + test01() + { + std::shared_ptr ptr; + std::shared_ptr ptr2 = ptr; + + #if __cpp_lib_shared_ptr_arrays >= 201611L + std::shared_ptr ptr_array; + std::shared_ptr ptr_array2 = ptr_array; + std::shared_ptr ptr_array3 = ptr_array; + #endif + } + + void + test02() + { + std::shared_ptr ptr; + std::shared_ptr ptr2 = ptr; + + #if __cpp_lib_shared_ptr_arrays >= 201611L + std::shared_ptr ptr_array; + std::shared_ptr ptr_array2 = ptr_array; + std::shared_ptr ptr_array3 = ptr_array; + #endif + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/shared_ptr/requirements/explicit_instantiation/1.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/shared_ptr/requirements/explicit_instantiation/1.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/shared_ptr/requirements/explicit_instantiation/1.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/shared_ptr/requirements/explicit_instantiation/1.cc Fri Sep 4 07:35:12 2026 *************** template class std::shared_ptr; *** 28,30 **** --- 28,42 ---- template class std::shared_ptr; template class std::shared_ptr; template class std::shared_ptr; + + #if __cpp_lib_shared_ptr_arrays >= 201611L + template class std::shared_ptr; + template class std::shared_ptr; + template class std::shared_ptr; + template class std::shared_ptr; + + template class std::shared_ptr; + template class std::shared_ptr; + template class std::shared_ptr; + template class std::shared_ptr; + #endif diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_n_neg.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_n_neg.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_n_neg.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_n_neg.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,59 ---- + // Copyright (C) 2017-2025 Free Software Foundation, Inc. + // + // This file is part of the GNU ISO C++ Library. This library 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, or (at your option) + // any later version. + + // This library 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 library; see the file COPYING3. If not see + // . + + // { dg-do compile { target c++17 } } + + #include + + // This has a trivial destructor, but should not be destructible! + struct DeletedDtor { + ~DeletedDtor() = delete; + }; + + void + test01() + { + alignas(DeletedDtor) unsigned char buf[sizeof(DeletedDtor)]; + auto p = ::new (buf) DeletedDtor(); + std::destroy_n(p, 1); + } + + class PrivateDtor { + ~PrivateDtor() { } + }; + + void + test02() + { + alignas(PrivateDtor) unsigned char buf[sizeof(PrivateDtor)]; + auto p = ::new (buf) PrivateDtor(); + std::destroy_n(p, 1); + } + + #if __cpp_constexpr_dynamic_alloc // >= C++20 + consteval bool + test03() + { + DeletedDtor* p = nullptr; + std::destroy_n(p, 0); + return true; + } + static_assert(test03()); + #endif + + // { dg-error "deleted function .*DeletedDtor" "" { target *-*-* } 0 } + // { dg-error "PrivateDtor.* is private" "" { target *-*-* } 0 } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/specialized_algorithms/memory_management_tools/destroy_neg.cc Fri Sep 4 07:35:12 2026 *************** test01() *** 29,36 **** { alignas(DeletedDtor) unsigned char buf[sizeof(DeletedDtor)]; auto p = ::new (buf) DeletedDtor(); ! std::destroy(p, p + 1); // { dg-error "here" } ! std::destroy_n(p, 1); // { dg-error "here" } } class PrivateDtor { --- 29,35 ---- { alignas(DeletedDtor) unsigned char buf[sizeof(DeletedDtor)]; auto p = ::new (buf) DeletedDtor(); ! std::destroy(p, p + 1); } class PrivateDtor { *************** test02() *** 42,49 **** { alignas(PrivateDtor) unsigned char buf[sizeof(PrivateDtor)]; auto p = ::new (buf) PrivateDtor(); ! std::destroy(p, p + 1); // { dg-error "here" } ! std::destroy_n(p, 1); // { dg-error "here" } } ! // { dg-error "value type is destructible" "" { target *-*-* } 0 } --- 41,59 ---- { alignas(PrivateDtor) unsigned char buf[sizeof(PrivateDtor)]; auto p = ::new (buf) PrivateDtor(); ! std::destroy(p, p + 1); } ! #if __cpp_constexpr_dynamic_alloc // >= C++20 ! consteval bool ! test03() ! { ! DeletedDtor* p = nullptr; ! std::destroy(p, p); ! return true; ! } ! static_assert(test03()); ! #endif ! ! // { dg-error "deleted function .*DeletedDtor" "" { target *-*-* } 0 } ! // { dg-error "PrivateDtor.* is private" "" { target *-*-* } 0 } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/synchronized_pool_resource/118681.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/synchronized_pool_resource/118681.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/synchronized_pool_resource/118681.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/synchronized_pool_resource/118681.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,6 ---- + // { dg-do run { target c++17 } } + // { dg-require-gthreads "" } + // Bug 118681 - unsynchronized_pool_resource may fail to respect alignment + + #define RESOURCE std::pmr::synchronized_pool_resource + #include "../unsynchronized_pool_resource/118681.cc" diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/system_clock/99832.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/system_clock/99832.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/system_clock/99832.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/system_clock/99832.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,14 ---- + // { dg-options "-O0 -g0 -std=gnu++20" } + // { dg-do compile { target c++20 } } + // { dg-final { scan-assembler-not "system_clock9to_time_t" } } + + // Bug libstdc++/99832 + // std::chrono::system_clock::to_time_t needs ABI tag for 32-bit time_t + + #include + + std::time_t + test_pr99832(std::chrono::system_clock::time_point t) + { + return std::chrono::system_clock::to_time_t(t); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/tuple/cons/121771.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/tuple/cons/121771.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/tuple/cons/121771.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/tuple/cons/121771.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,45 ---- + // { dg-do compile { target c++17 } } + + // Bug 121771 - std::tuple CTAD fails for lvalue reference to function type + + #include + #include + + void func(); + + std::tuple t(func); + std::tuple& r = t; + + struct Explicit { + Explicit(); + explicit Explicit(const Explicit&); + } ex; + + std::tuple t2(func, 1); + std::tuple& r2 = t2; + + std::tuple t2x(ex, func); + std::tuple& r2x = t2x; + + std::tuple t3(1, func, 3); + std::tuple& r3 = t3; + + std::tuple t3x(ex, 2, func); + std::tuple& r3x = t3x; + + std::allocator alloc; + + std::tuple ta(std::allocator_arg, alloc, func); + std::tuple& ra = ta; + + std::tuple ta2(std::allocator_arg, alloc, func, 1); + std::tuple& ra2 = ta2; + + std::tuple ta2x(std::allocator_arg, alloc, ex, func); + std::tuple& ra2x = ta2x; + + std::tuple ta3(std::allocator_arg, alloc, 1, func, 3); + std::tuple& ra3 = ta3; + + std::tuple ta3x(std::allocator_arg, alloc, ex, 2, func); + std::tuple& ra3x = ta3x; diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/118681.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/118681.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/118681.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/unsynchronized_pool_resource/118681.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,58 ---- + // { dg-do run { target c++17 } } + // Bug 118681 - unsynchronized_pool_resource may fail to respect alignment + + #include + #include + #include + + #ifndef RESOURCE + # define RESOURCE std::pmr::unsynchronized_pool_resource + #endif + + bool any_misaligned = false; + + bool + is_aligned(void* p, [[maybe_unused]] std::size_t size, std::size_t alignment) + { + const bool misaligned = reinterpret_cast(p) % alignment; + #ifdef DEBUG + std::printf("allocate(%2zu, %2zu): %p is aligned %scorrectly\n", + size, alignment, p, misaligned ? "in" : ""); + any_misaligned |= misaligned; + return true; + #endif + return ! misaligned; + } + + void + test_alignment(std::pmr::memory_resource& res, bool dealloc) + { + for (std::size_t alignment : { 8, 16, 32, 64 }) + { + for (std::size_t size : { 9, 12, 24, 40, 48, 56, 72 }) + { + void* p1 = res.allocate(size, alignment); + void* p2 = res.allocate(size, alignment); + + VERIFY( is_aligned(p1, size, alignment) ); + VERIFY( is_aligned(p2, size, alignment) ); + + if (dealloc) + { + res.deallocate(p1, size, alignment); + res.deallocate(p2, size, alignment); + } + } + } + } + + int main() + { + RESOURCE res; + test_alignment(res, true); + res.release(); + test_alignment(res, false); + res.release(); + + VERIFY( ! any_misaligned ); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/weak_ptr/requirements/1.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/weak_ptr/requirements/1.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/weak_ptr/requirements/1.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/weak_ptr/requirements/1.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,33 ---- + // { dg-do compile { target c++11 } } + // { dg-require-effective-target hosted } + + #include + #include + + using namespace __gnu_test; + + void + test01() + { + std::weak_ptr ptr; + std::weak_ptr ptr2 = ptr; + + #if __cpp_lib_shared_ptr_arrays >= 201611L + std::weak_ptr ptr_array; + std::weak_ptr ptr_array2 = ptr_array; + std::weak_ptr ptr_array3 = ptr_array; + #endif + } + + void + test02() + { + std::weak_ptr ptr; + std::weak_ptr ptr2 = ptr; + + #if __cpp_lib_shared_ptr_arrays >= 201611L + std::weak_ptr ptr_array; + std::weak_ptr ptr_array2 = ptr_array; + std::weak_ptr ptr_array3 = ptr_array; + #endif + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/20_util/weak_ptr/requirements/explicit_instantiation/1.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/weak_ptr/requirements/explicit_instantiation/1.cc *** gcc-13.4.0/libstdc++-v3/testsuite/20_util/weak_ptr/requirements/explicit_instantiation/1.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/20_util/weak_ptr/requirements/explicit_instantiation/1.cc Fri Sep 4 07:35:12 2026 *************** template class std::weak_ptr; *** 28,30 **** --- 28,42 ---- template class std::weak_ptr; template class std::weak_ptr; template class std::weak_ptr; + + #if __cpp_lib_shared_ptr_arrays >= 201611L + template class std::weak_ptr; + template class std::weak_ptr; + template class std::weak_ptr; + template class std::weak_ptr; + + template class std::weak_ptr; + template class std::weak_ptr; + template class std::weak_ptr; + template class std::weak_ptr; + #endif diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/123991.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/123991.cc *** gcc-13.4.0/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/123991.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/char/123991.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,56 ---- + // { dg-do run { target c++17 } } + + // Bug 123991 - std::string::compare crashes instead of throwing + + #include + #include + #include + #include + + void + test_compare_3arg() + { + std::string_view sv; + std::string s; + static_assert( ! noexcept(s.compare(0, 0, sv)) ); + #ifdef __cpp_exceptions + try + { + (void) s.compare(1, 0, sv); + VERIFY(false); + } + catch (const std::out_of_range&) + { } + #endif + } + + void + test_compare_5arg() + { + std::string_view sv; + std::string s; + static_assert( ! noexcept(s.compare(0, 0, sv, 0, 0)) ); + #ifdef __cpp_exceptions + try + { + (void) s.compare(1, 0, sv, 0, 0); + VERIFY(false); + } + catch (const std::out_of_range&) + { } + + try + { + (void) s.compare(0, 0, sv, 1, 0); + VERIFY(false); + } + catch (const std::out_of_range&) + { } + #endif + } + + int main() + { + test_compare_3arg(); + test_compare_5arg(); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/wchar_t/123991.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/wchar_t/123991.cc *** gcc-13.4.0/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/wchar_t/123991.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/21_strings/basic_string/operations/compare/wchar_t/123991.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,56 ---- + // { dg-do run { target c++17 } } + + // Bug 123991 - std::string::compare crashes instead of throwing + + #include + #include + #include + #include + + void + test_compare_3arg() + { + std::wstring_view sv; + std::wstring s; + static_assert( ! noexcept(s.compare(0, 0, sv)) ); + #ifdef __cpp_exceptions + try + { + (void) s.compare(1, 0, sv); + VERIFY(false); + } + catch (const std::out_of_range&) + { } + #endif + } + + void + test_compare_5arg() + { + std::wstring_view sv; + std::wstring s; + static_assert( ! noexcept(s.compare(0, 0, sv, 0, 0)) ); + #ifdef __cpp_exceptions + try + { + (void) s.compare(1, 0, sv, 0, 0); + VERIFY(false); + } + catch (const std::out_of_range&) + { } + + try + { + (void) s.compare(0, 0, sv, 1, 0); + VERIFY(false); + } + catch (const std::out_of_range&) + { } + #endif + } + + int main() + { + test_compare_3arg(); + test_compare_5arg(); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/22_locale/codecvt/length/wchar_t/105857.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/22_locale/codecvt/length/wchar_t/105857.cc *** gcc-13.4.0/libstdc++-v3/testsuite/22_locale/codecvt/length/wchar_t/105857.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/22_locale/codecvt/length/wchar_t/105857.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,21 ---- + // { dg-do run } + + // Bug libstdc++/105857 codecvt::do_length causes unexpected buffer overflow + + #include + #include + + int main() + { + std::string s(1050, 'a'); + typedef std::codecvt Cvt; + const Cvt& cvt = std::use_facet(std::locale()); + const char* from = s.c_str(); + const char* from_end = s.c_str() + s.size(); + std::size_t max = std::size_t(-1) / 4 + 2; + std::mbstate_t state = std::mbstate_t(); + int n = cvt.length(state, from, from_end, max); + VERIFY( n == s.size() ); + n = cvt.length(state, from, from_end, 2); + VERIFY( n == 2 ); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/23_containers/forward_list/modifiers/122661.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/forward_list/modifiers/122661.cc *** gcc-13.4.0/libstdc++-v3/testsuite/23_containers/forward_list/modifiers/122661.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/forward_list/modifiers/122661.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,20 ---- + // { dg-do compile { target c++11 } } + + // Bug 122661 - Incorrect value category handling in forward_list::assign + + #include + + struct S + { + S(); + S& operator=(S const&) & = delete; + S& operator=(S const&) &&; + }; + + void + test_pr122661() + { + std::forward_list fl; + S* iter = nullptr; + fl.assign(iter, iter); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/23_containers/priority_queue/118088.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/priority_queue/118088.cc *** gcc-13.4.0/libstdc++-v3/testsuite/23_containers/priority_queue/118088.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/priority_queue/118088.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,83 ---- + // { dg-do run { target c++11 } } + + #include + #include + #include + + template + bool + check(std::priority_queue& p) + { + if (!p.empty()) + { + T prev = p.top(); + p.pop(); + while (!p.empty()) + { + if ( prev < p.top() ) + return false; + prev = p.top(); + p.pop(); + } + } + return true; + } + + // A vector-like type that has a non-empty moved-from state. + struct Vector : std::vector + { + using Base = std::vector; + + using Base::Base; + + Vector(const Vector&) = default; + Vector& operator=(const Vector&) = default; + + Vector(Vector&& v) : Base(static_cast(v)) + { + invalidate_heap(v); + } + + Vector(Vector&& v, const std::allocator&) + : Base(static_cast(v)) + { + invalidate_heap(v); + } + + Vector& + operator=(Vector&& v) + { + static_cast(*this) = static_cast(v); + invalidate_heap(v); + return *this; + } + + void invalidate_heap(Base& v) { v = {1,2,3}; } + }; + + void + test_moves() + { + std::priority_queue p; + p.push(1); + p.push(3); + p.push(5); + p.push(2); + p.push(2); + p.push(2); + p.push(2); + std::priority_queue p2 = std::move(p); + VERIFY( check(p) ); + + // Allocator-extended move constructor: + std::priority_queue p3(std::move(p2), std::allocator()); + VERIFY( check(p2) ); + + p2 = std::move(p3); + VERIFY( check(p3) ); + } + + int main() + { + test_moves(); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/23_containers/vector/cons/destructible_debug_neg.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/vector/cons/destructible_debug_neg.cc *** gcc-13.4.0/libstdc++-v3/testsuite/23_containers/vector/cons/destructible_debug_neg.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/vector/cons/destructible_debug_neg.cc Fri Sep 4 07:35:12 2026 *************** test02() *** 43,53 **** std::vector v; } ! // { dg-error "value type is destructible" "" { target *-*-* } 0 } // In Debug Mode the "required from here" errors come from // { dg-error "required from here" "" { target *-*-* } 172 } - - // Needed because of PR c++/92193 - // { dg-prune-output "deleted function" } - // { dg-prune-output "private within this context" } --- 43,50 ---- std::vector v; } ! // { dg-error "deleted function .*DeletedDtor" "" { target *-*-* } 0 } ! // { dg-error "PrivateDtor.* is private" "" { target *-*-* } 0 } // In Debug Mode the "required from here" errors come from // { dg-error "required from here" "" { target *-*-* } 172 } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/23_containers/vector/cons/destructible_neg.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/vector/cons/destructible_neg.cc *** gcc-13.4.0/libstdc++-v3/testsuite/23_containers/vector/cons/destructible_neg.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/vector/cons/destructible_neg.cc Fri Sep 4 07:35:12 2026 *************** test02() *** 42,49 **** std::vector v; // { dg-error "here" } } ! // { dg-error "value type is destructible" "" { target *-*-* } 0 } ! ! // Needed because of PR c++/92193 ! // { dg-prune-output "deleted function" } ! // { dg-prune-output "private within this context" } --- 42,46 ---- std::vector v; // { dg-error "here" } } ! // { dg-error "deleted function .*DeletedDtor" "" { target *-*-* } 0 } ! // { dg-error "PrivateDtor.* is private" "" { target *-*-* } 0 } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/23_containers/vector/modifiers/moveable.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/vector/modifiers/moveable.cc *** gcc-13.4.0/libstdc++-v3/testsuite/23_containers/vector/modifiers/moveable.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/vector/modifiers/moveable.cc Fri Sep 4 07:35:12 2026 *************** test05() *** 109,117 **** // when it doesn't reallocate the buffer. VERIFY(copycounter::copycount == 20 + 1); a.insert(a.end(), 50, c); ! VERIFY(copycounter::copycount == 70 + 2); a.insert(a.begin() + 50, 100, c); ! VERIFY(copycounter::copycount == 170 + 3); } --- 109,119 ---- // when it doesn't reallocate the buffer. VERIFY(copycounter::copycount == 20 + 1); a.insert(a.end(), 50, c); ! // expect when inserting at the end (appending), where existing ! // elements are not modified ! VERIFY(copycounter::copycount == 70 + 1); a.insert(a.begin() + 50, 100, c); ! VERIFY(copycounter::copycount == 170 + 2); } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/23_containers/vector/modifiers/resize.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/vector/modifiers/resize.cc *** gcc-13.4.0/libstdc++-v3/testsuite/23_containers/vector/modifiers/resize.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/23_containers/vector/modifiers/resize.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,69 ---- + // { dg-do run } + + #include + #include + + struct NoAssign + { + NoAssign(int p) : val(p) {} + const int val; + }; + + struct PrivateAssign + { + PrivateAssign(int p) : val(p) {} + PrivateAssign(const PrivateAssign& rhs) : val(rhs.val) {} + + int val; + + private: + PrivateAssign& operator=(const PrivateAssign&); + }; + + #if __cplusplus >= 201102L + struct DeletedAssign + { + DeletedAssign(int p) : val(p) {} + DeletedAssign(const DeletedAssign& rhs) : val(rhs.val) {} + + DeletedAssign& operator=(const DeletedAssign&) = delete; + + int val; + }; + #endif + + template + void + testPR90129() + { + std::vector v; + v.resize(5, T(5)); + VERIFY( v.size() == 5 ); + VERIFY( v.front().val == 5 ); + VERIFY( v.back().val == 5 ); + + v.resize(10, T(10)); + VERIFY( v.size() == 10 ); + VERIFY( v.front().val == 5 ); + VERIFY( v.back().val == 10 ); + + v.resize(7, T(7)); + VERIFY( v.size() == 7 ); + VERIFY( v.front().val == 5 ); + VERIFY( v.back().val == 10 ); + + v.resize(3, T(3)); + VERIFY( v.size() == 3 ); + VERIFY( v.front().val == 5 ); + VERIFY( v.back().val == 5 ); + } + + int main() + { + testPR90129(); + testPR90129(); + #if __cplusplus >= 201102L + testPR90129(); + #endif + return 0; + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/105580.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/105580.cc *** gcc-13.4.0/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/105580.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/24_iterators/istreambuf_iterator/105580.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,16 ---- + // { dg-compile } + // { dg-additional-options "-Wnull-dereference" } + // { dg-add-options no_pch } + + #include + #include + + int main() + { + std::istringstream in("Hello, world"); + std::istreambuf_iterator it(in), end; + std::string ss(it, end); + return 0; + } + + // { dg-bogus "null pointer dereference" "" { target *-*-* } 0 } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/25_algorithms/is_permutation/constrained.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/25_algorithms/is_permutation/constrained.cc *** gcc-13.4.0/libstdc++-v3/testsuite/25_algorithms/is_permutation/constrained.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/25_algorithms/is_permutation/constrained.cc Fri Sep 4 07:35:12 2026 *************** *** 20,25 **** --- 20,26 ---- #include #include + #include #include #include *************** test03() *** 77,86 **** --- 78,99 ---- while (std::next_permutation(std::begin(cx), std::end(cx))); } + constexpr + bool + test04() // PR118160, do not create dangling references + { + int x[] = { 4, 3, 2, 1 }; + auto y = std::views::iota(1, 5); + return ranges::is_permutation(x, y) && ranges::is_permutation(y, x); + } + + static_assert(test04()); + int main() { test01(); test02(); test03(); + VERIFY( test04() ); } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/25_algorithms/remove_if/120789.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/25_algorithms/remove_if/120789.cc *** gcc-13.4.0/libstdc++-v3/testsuite/25_algorithms/remove_if/120789.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/25_algorithms/remove_if/120789.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,36 ---- + // PR libstdc++/120789 - ranges::remove_if should use ranges::iter_move + // { dg-do compile { target c++20 } } + + #include + + struct A + { + bool operator==(const A&) const; + }; + + struct B + { + B(B&&) = delete; + B& operator=(const A&) const; + + operator A() const; + bool operator==(const B&) const; + }; + + struct I + { + using value_type = A; + using difference_type = int; + B operator*() const; + I& operator++(); + I operator++(int); + bool operator==(const I&) const; + friend A iter_move(const I&); + }; + + void + test01() + { + std::ranges::subrange r; + auto [begin, end] = std::ranges::remove_if(r, [](auto&&) { return true; }); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/25_algorithms/unique/120789.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/25_algorithms/unique/120789.cc *** gcc-13.4.0/libstdc++-v3/testsuite/25_algorithms/unique/120789.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/25_algorithms/unique/120789.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,36 ---- + // PR libstdc++/120789 - ranges::unique should use ranges::iter_move + // { dg-do compile { target c++20 } } + + #include + + struct A + { + bool operator==(const A&) const; + }; + + struct B + { + B(B&&) = delete; + B& operator=(const A&) const; + + operator A() const; + bool operator==(const B&) const; + }; + + struct I + { + using value_type = A; + using difference_type = int; + B operator*() const; + I& operator++(); + I operator++(int); + bool operator==(const I&) const; + friend A iter_move(const I&); + }; + + void + test01() + { + std::ranges::subrange r; + auto [begin, end] = std::ranges::unique(r); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char/123100.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char/123100.cc *** gcc-13.4.0/libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char/123100.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/27_io/basic_stringbuf/str/char/123100.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,58 ---- + // { dg-do run } + + #include + #include + + void + test01() + { + const int n = 20; + const char data[n] = "abcde"; + char buf[n] = "0123456789"; + std::string expected("abcde56789\0\0\0\0\0\0\0\0\0\0", n); + + std::ostringstream out; + out.rdbuf()->pubsetbuf(buf, n); + out << data; + VERIFY( out.str() == expected ); + VERIFY( out.str() == expected ); + #if __cplusplus >= 201103L + VERIFY( std::move(out).str() == expected ); + #if __cplusplus >= 202002L && _GLIBCXX_USE_CXX11_ABI + expected.clear(); + #endif + VERIFY( out.str() == expected ); + VERIFY( std::move(out).str() == expected ); + #endif + } + + void + test02() + { + const int n = 20; + const char data[n] = "abcde"; + char buf[n] = "0123456789"; + std::string expected("abcde56789\0\0\0\0\0\0\0\0\0\0", n); + + std::ostringstream out; + out << std::string(n * 2, 'a'); + VERIFY( out.str() == std::string(n * 2, 'a') ); + out.rdbuf()->pubsetbuf(buf, n); + out << data; // writes 6 chars + VERIFY( out.str() == expected ); + VERIFY( out.str() == expected ); + #if __cplusplus >= 201103L + VERIFY( std::move(out).str() == expected ); + #if __cplusplus >= 202002L && _GLIBCXX_USE_CXX11_ABI + expected.clear(); + #endif + VERIFY( out.str() == expected ); + VERIFY( std::move(out).str() == expected ); + #endif + } + + int main() + { + test01(); + test02(); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc *** gcc-13.4.0/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/27_io/filesystem/operations/rename.cc Fri Sep 4 07:35:12 2026 *************** test_directories() *** 170,179 **** --- 170,189 ---- fs::remove_all(dir, ec); } + void + test_pr122726() + { + std::error_code ec; + const auto nonesuch = __gnu_test::nonexistent_path(); + fs::rename(nonesuch, "new-name", ec); + VERIFY( ec == std::make_error_code(std::errc::no_such_file_or_directory) ); + } + int main() { test01(); test_symlinks(); test_directories(); + test_pr122726(); } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/27_io/filesystem/path/concat/120029.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/27_io/filesystem/path/concat/120029.cc *** gcc-13.4.0/libstdc++-v3/testsuite/27_io/filesystem/path/concat/120029.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/27_io/filesystem/path/concat/120029.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,72 ---- + // { dg-do run { target c++17 } } + + // Bug libstdc++/120029 + // Dangling iterator usage in path::operator+=(const path& p) when this == p + + #include + #include + + namespace fs = std::filesystem; + + void + test_root_dir() + { + fs::path p = "/"; + p += p; + p += p; + VERIFY( p == "////" ); + p += p.filename(); + VERIFY( p == "////" ); + p += *std::prev(p.end()); + VERIFY( p == "////" ); + } + + void + test_root_name() + { + fs::path p = "C:/"; + p += p; + p += p; + VERIFY( p == "C:/C:/C:/C:/" ); + p += p.filename(); + VERIFY( p == "C:/C:/C:/C:/" ); + p += *std::prev(p.end()); + VERIFY( p == "C:/C:/C:/C:/" ); + } + + void + test_filename() + { + fs::path p = "file"; + p += p; + p += p; + VERIFY( p == "filefilefilefile" ); + p += p.filename(); + VERIFY( p == "filefilefilefilefilefilefilefile" ); + p += *std::prev(p.end()); + VERIFY( p == "filefilefilefilefilefilefilefilefilefilefilefilefilefilefilefile" ); + } + + void + test_multi() + { + fs::path p = "/home/username/Documents/mu"; + p += p; + p += p; + VERIFY( p == "/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mu" ); + p += p.filename(); + VERIFY( p == "/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mumu" ); + p += *std::prev(p.end()); + VERIFY( p == "/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mumumumu" ); + auto n = std::distance(p.begin(), p.end()); + for (int i = 0; i < n; ++i) + p += *std::next(p.begin(), i); + } + + int main() + { + test_root_dir(); + test_root_name(); + test_filename(); + test_multi(); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/27_io/spanstream/127006.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/27_io/spanstream/127006.cc *** gcc-13.4.0/libstdc++-v3/testsuite/27_io/spanstream/127006.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/27_io/spanstream/127006.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,30 ---- + // { dg-do run { target c++23 } } + + #include + #include + + void + test_pr127006_out() + { + // PR libstdc++/127006 + char buf[3]{}; + std::ospanstream s(buf, std::ios::openmode{}); + VERIFY( s << 'x' ); + VERIFY( buf[0] == 'x' ); + } + + void + test_pr127006_in() + { + char buf[3]{'x'}; + std::ispanstream s(buf, std::ios::openmode{}); + char x; + VERIFY( s >> x ); + VERIFY( x == 'x' ); + } + + int main() + { + test_pr127006_out(); + test_pr127006_in(); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc *** gcc-13.4.0/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/29_atomics/atomic/compare_exchange_padding.cc Fri Sep 4 07:35:12 2026 *************** *** 1,5 **** ! // { dg-options "-std=gnu++20" } ! // { dg-do run { target c++20 } } // { dg-require-atomic-cmpxchg-word "" } // { dg-add-options libatomic } --- 1,4 ---- ! // { dg-do run { target c++11 } } // { dg-require-atomic-cmpxchg-word "" } // { dg-add-options libatomic } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/29_atomics/atomic/cons/zero_padding.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/29_atomics/atomic/cons/zero_padding.cc *** gcc-13.4.0/libstdc++-v3/testsuite/29_atomics/atomic/cons/zero_padding.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/29_atomics/atomic/cons/zero_padding.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,75 ---- + // { dg-do run { target c++11 } } + // { dg-require-atomic-cmpxchg-word "" } + // { dg-add-options libatomic } + + #include + #include + #include + + struct TailPadding { short i; char c; }; + TailPadding ztail{1, 2}; // zeroed-padding + constexpr std::atomic ctail(TailPadding{1,2}); + std::atomic gtail(TailPadding{1,2}); + + struct MidPadding { char c; short i; }; + MidPadding zmid{1, 2}; // zeroed-padding + constexpr std::atomic cmid(MidPadding{1,2}); + std::atomic gmid(MidPadding{1,2}); + + struct BitPadding { int : 4; int i : 5; int : 4; int j : 5; int : 4; }; + BitPadding zbit{1, 2}; // zeroed-padding + constexpr std::atomic cbit(BitPadding{1,2}); + std::atomic gbit(BitPadding{1,2}); + + struct Ctor + { + Ctor() = default; + + constexpr Ctor(char pc, short pi) + : c(pc), i(pi) + {} + + char c; + short i; + }; + + Ctor zctor{1, 2}; // zeroed-padding + constexpr std::atomic cctor(Ctor{1,2}); + std::atomic gctor(Ctor{1,2}); + + template + void test_struct(std::atomic& g, const T& zp) + { + T const d{3, 4}; + T t; + + std::memcpy(&t, &zp, sizeof(T)); + VERIFY( g.compare_exchange_strong(t, d) ); + + static std::atomic st(T{1, 2}); + std::memcpy(&t, &zp, sizeof(T)); + VERIFY( st.compare_exchange_strong(t, d) ); + + thread_local std::atomic tl(T{1, 2}); + std::memcpy(&t, &zp, sizeof(T)); + VERIFY( tl.compare_exchange_strong(t, d) ); + + std::atomic l(T{1, 2}); + std::memcpy(&t, &zp, sizeof(T)); + VERIFY( l.compare_exchange_strong(t, d) ); + + std::atomic* h = new std::atomic(T{1, 2}); + std::memcpy(&t, &zp, sizeof(T)); + VERIFY( h->compare_exchange_strong(t, d) ); + delete h; + + constexpr std::atomic cl(T{1, 2}); + } + + int main() + { + test_struct(gtail, ztail); + test_struct(gmid, zmid); + test_struct(gbit, zbit); + test_struct(gctor, zctor); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/backward/hash_set/check_construct_destroy.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/backward/hash_set/check_construct_destroy.cc *** gcc-13.4.0/libstdc++-v3/testsuite/backward/hash_set/check_construct_destroy.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/backward/hash_set/check_construct_destroy.cc Fri Sep 4 07:35:12 2026 *************** int main() *** 39,88 **** int buckets; - // For C++11 and later add 1 to all counts, because the std::vector used - // internally by the hashtable creates and destroys a temporary object - // using its allocator. - const int extra = __cplusplus >= 201102L ? 1 : 0; - tracker_allocator_counter::reset(); { Container c; buckets = c.bucket_count(); ! ok = check_construct_destroy("empty container", buckets+extra, extra) && ok; } ! ok = check_construct_destroy("empty container", buckets+extra, buckets+extra) && ok; tracker_allocator_counter::reset(); { Container c(arr10, arr10 + 10); ! ok = check_construct_destroy("Construct from range", buckets+10+extra, extra) && ok; } ! ok = check_construct_destroy("Construct from range", buckets+10+extra, buckets+10+extra) && ok; tracker_allocator_counter::reset(); { Container c(arr10, arr10 + 10); c.insert(arr10a[0]); ! ok = check_construct_destroy("Insert element", buckets+11+extra, extra) && ok; } ! ok = check_construct_destroy("Insert element", buckets+11+extra, buckets+11+extra) && ok; tracker_allocator_counter::reset(); { Container c(arr10, arr10 + 10); c.insert(arr10a, arr10a+3); ! ok = check_construct_destroy("Insert short range", buckets+13+extra, extra) && ok; } ! ok = check_construct_destroy("Insert short range", buckets+13+extra, buckets+13+extra) && ok; tracker_allocator_counter::reset(); { Container c(arr10, arr10 + 10); c.insert(arr10a, arr10a+10); ! ok = check_construct_destroy("Insert long range", buckets+20+extra, extra) && ok; } ! ok = check_construct_destroy("Insert long range", buckets+20+extra, buckets+20+extra) && ok; return ok ? 0 : 1; } --- 39,83 ---- int buckets; tracker_allocator_counter::reset(); { Container c; buckets = c.bucket_count(); ! ok = check_construct_destroy("empty container", buckets, 0) && ok; } ! ok = check_construct_destroy("empty container", buckets, buckets) && ok; tracker_allocator_counter::reset(); { Container c(arr10, arr10 + 10); ! ok = check_construct_destroy("Construct from range", buckets+10, 0) && ok; } ! ok = check_construct_destroy("Construct from range", buckets+10, buckets+10) && ok; tracker_allocator_counter::reset(); { Container c(arr10, arr10 + 10); c.insert(arr10a[0]); ! ok = check_construct_destroy("Insert element", buckets+11, 0) && ok; } ! ok = check_construct_destroy("Insert element", buckets+11, buckets+11) && ok; tracker_allocator_counter::reset(); { Container c(arr10, arr10 + 10); c.insert(arr10a, arr10a+3); ! ok = check_construct_destroy("Insert short range", buckets+13, 0) && ok; } ! ok = check_construct_destroy("Insert short range", buckets+13, buckets+13) && ok; tracker_allocator_counter::reset(); { Container c(arr10, arr10 + 10); c.insert(arr10a, arr10a+10); ! ok = check_construct_destroy("Insert long range", buckets+20, 0) && ok; } ! ok = check_construct_destroy("Insert long range", buckets+20, buckets+20) && ok; return ok ? 0 : 1; } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/experimental/filesystem/path/concat/120029.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/experimental/filesystem/path/concat/120029.cc *** gcc-13.4.0/libstdc++-v3/testsuite/experimental/filesystem/path/concat/120029.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/experimental/filesystem/path/concat/120029.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,74 ---- + // { dg-options "-DUSE_FILESYSTEM_TS -lstdc++fs" } + // { dg-do run { target c++11 } } + // { dg-require-filesystem-ts "" } + + // Bug libstdc++/120029 + // Dangling iterator usage in path::operator+=(const path& p) when this == p + + #include + #include + + namespace fs = std::experimental::filesystem; + + void + test_root_dir() + { + fs::path p = "/"; + p += p; + p += p; + VERIFY( p == "////" ); + p += p.filename(); + VERIFY( p == "////////" ); + p += *std::prev(p.end()); + VERIFY( p == "////////////////" ); + } + + void + test_root_name() + { + fs::path p = "C:/"; + p += p; + p += p; + VERIFY( p == "C:/C:/C:/C:/" ); + p += p.filename(); // For Filesystem TS the filename is "." + VERIFY( p == "C:/C:/C:/C:/." ); + p += *std::prev(p.end()); + VERIFY( p == "C:/C:/C:/C:/.." ); + } + + void + test_filename() + { + fs::path p = "file"; + p += p; + p += p; + VERIFY( p == "filefilefilefile" ); + p += p.filename(); + VERIFY( p == "filefilefilefilefilefilefilefile" ); + p += *std::prev(p.end()); + VERIFY( p == "filefilefilefilefilefilefilefilefilefilefilefilefilefilefilefile" ); + } + + void + test_multi() + { + fs::path p = "/home/username/Documents/mu"; + p += p; + p += p; + VERIFY( p == "/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mu" ); + p += p.filename(); + VERIFY( p == "/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mumu" ); + p += *std::prev(p.end()); + VERIFY( p == "/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mu/home/username/Documents/mumumumu" ); + auto n = std::distance(p.begin(), p.end()); + for (int i = 0; i < n; ++i) + p += *std::next(p.begin(), i); + } + + int main() + { + test_root_dir(); + test_root_name(); + test_filename(); + test_multi(); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/std/format/functions/format.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/format/functions/format.cc *** gcc-13.4.0/libstdc++-v3/testsuite/std/format/functions/format.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/format/functions/format.cc Fri Sep 4 07:35:12 2026 *************** test_locale() *** 239,244 **** --- 239,254 ---- s = std::format(eloc, "{0:Le} {0:Lf} {0:Lg}", -nan); VERIFY( s == "-nan -nan -nan" ); + // PR libstdc++/120548 format confuses a negative sign for a thousands digit + s = std::format(bloc, "{:L}", -123.45); + VERIFY( s == "-123.45" ); + s = std::format(bloc, "{:-L}", -876543.21); + VERIFY( s == "-876,543.21" ); + s = std::format(bloc, "{:+L}", 333.22); + VERIFY( s == "+333.22" ); + s = std::format(bloc, "{: L}", 999.44); + VERIFY( s == " 999.44" ); + // Restore std::locale::global(cloc); } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/std/time/clock/gps/io.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/time/clock/gps/io.cc *** gcc-13.4.0/libstdc++-v3/testsuite/std/time/clock/gps/io.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/time/clock/gps/io.cc Fri Sep 4 07:35:12 2026 *************** test01() *** 23,29 **** ss << gt; VERIFY( ss.str() == "2000-01-01 00:00:13" ); - gps_time> gtf = gt; ss.str(""); ss.clear(); ss << (gps_time>(gt) + 20ms); --- 23,28 ---- diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/std/time/clock/local/io.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/time/clock/local/io.cc *** gcc-13.4.0/libstdc++-v3/testsuite/std/time/clock/local/io.cc Thu Jan 1 00:00:00 1970 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/time/clock/local/io.cc Fri Sep 4 07:35:12 2026 *************** *** 0 **** --- 1,102 ---- + // { dg-options "-std=gnu++20" } + // { dg-do run { target c++20 } } + // { dg-timeout-factor 2 } + + #include + #include + #include + + void + test_ostream() + { + using namespace std::chrono; + + auto lt = local_time(1722198122s); + + std::ostringstream ss; + ss << lt; + auto s = ss.str(); + ss.str(""); + ss.clear(); + ss << sys_time{lt.time_since_epoch()}; + auto s2 = ss.str(); + VERIFY( s == s2 ); + } + + void + test_format() + { + using std::format; + using namespace std::chrono; + + auto lt = local_seconds(1722198122s); + + #if __cpp_exceptions + auto args = std::make_format_args(lt); + try + { + (void) std::vformat("{:%Z}", args); + VERIFY(false); + } + catch (const std::format_error&) + { + } + try + { + (void) std::vformat("{:%z}", args); + VERIFY(false); + } + catch (const std::format_error&) + { + } + #endif + + auto s = format("{0:%F %T %a}", lt); + VERIFY( s == "2024-07-28 20:22:02 Sun" ); + + s = format("{}", lt); + VERIFY( s == "2024-07-28 20:22:02" ); + + // Test formatting for chrono::local_time_format and local-time-format-t too: + auto ltf = local_time_format(lt); + s = std::format("{:%F %T %a %b}", ltf); + VERIFY( s == "2024-07-28 20:22:02 Sun Jul" ); + #if __cpp_exceptions + try + { + (void) std::format("{:%Z}", ltf); + VERIFY(false); + } + catch (const std::format_error&) + { + } + try + { + (void) std::format("{:%z}", ltf); + VERIFY(false); + } + catch (const std::format_error&) + { + } + #endif + std::string abbrev = "FOO"; + seconds off = -3600s; + ltf = local_time_format(lt, &abbrev, &off); + s = std::format("{}", ltf); + VERIFY( s == "2024-07-28 20:22:02 FOO" ); + s = std::format("{:%Z %T %F %z %Ez}", ltf); + __builtin_puts(s.c_str()); + VERIFY( s == "FOO 20:22:02 2024-07-28 -0100 -01:00" ); + + s = std::format("{}", local_seconds{}); + VERIFY( s == "1970-01-01 00:00:00" ); + + s = std::format("{}", local_days{}); // PR libstdc++/120293 + VERIFY( s == "1970-01-01" ); + } + + int main() + { + test_ostream(); + test_format(); + } diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/std/time/clock/system/io.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/time/clock/system/io.cc *** gcc-13.4.0/libstdc++-v3/testsuite/std/time/clock/system/io.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/time/clock/system/io.cc Fri Sep 4 07:35:12 2026 *************** test_format() *** 65,77 **** " | 25.708 | 17:26:25.708 | 1 | 51 | 51 | 1 | 51 | 12/19/22" " | 17:26:25 | 22 | 2022 | +0000 | UTC" ); auto loc = std::locale::classic(); auto smod = std::format(loc, "{:%Ec %EC %Od %Oe %OH %OI %Om %OM %OS %Ou %OU" " %Ow %OW %Ex %EX %Oy %Ey %EY %Ez %Oz}", t); s = std::format("{:%c %C %d %e %H %I %m %M %S %u %U" " %w %W %x %X %y %y %Y +00:00 +00:00}", ! std::chrono::time_point_cast(t)); VERIFY( smod == s ); } int main() --- 65,83 ---- " | 25.708 | 17:26:25.708 | 1 | 51 | 51 | 1 | 51 | 12/19/22" " | 17:26:25 | 22 | 2022 | +0000 | UTC" ); + auto st = std::chrono::time_point_cast(t); auto loc = std::locale::classic(); auto smod = std::format(loc, "{:%Ec %EC %Od %Oe %OH %OI %Om %OM %OS %Ou %OU" " %Ow %OW %Ex %EX %Oy %Ey %EY %Ez %Oz}", t); s = std::format("{:%c %C %d %e %H %I %m %M %S %u %U" " %w %W %x %X %y %y %Y +00:00 +00:00}", ! st); VERIFY( smod == s ); + + s = std::format("{}", t); + VERIFY( s == "2022-12-19 17:26:25.708" ); + s = std::format("{0:} {0:=<21}", st); + VERIFY( s == "2022-12-19 17:26:25 2022-12-19 17:26:25==" ); } int main() diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/std/time/clock/tai/io.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/time/clock/tai/io.cc *** gcc-13.4.0/libstdc++-v3/testsuite/std/time/clock/tai/io.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/time/clock/tai/io.cc Fri Sep 4 07:35:12 2026 *************** test01() *** 17,22 **** --- 17,25 ---- auto s = format("{0:%F %T %Z} == {1:%F %T %Z}", st, tt); VERIFY( s == "2000-01-01 00:00:00 UTC == 2000-01-01 00:00:32 TAI" ); + + s = std::format("{:=>21}", tt); + VERIFY( s == "==2000-01-01 00:00:32" ); } int main() diff -Nrcpad gcc-13.4.0/libstdc++-v3/testsuite/std/time/zoned_time/io.cc gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/time/zoned_time/io.cc *** gcc-13.4.0/libstdc++-v3/testsuite/std/time/zoned_time/io.cc Thu Jun 5 16:03:03 2025 --- gcc-13.5.0-RC-20260904/libstdc++-v3/testsuite/std/time/zoned_time/io.cc Fri Sep 4 07:35:12 2026 *************** test_format() *** 38,43 **** --- 38,44 ---- " | 25.708 | 12:26:25.708 | 1 | 51 | 51 | 1 | 51 | 12/19/22" " | 12:26:25 | 22 | 2022 | -0500 | EST" ); + #ifdef _GLIBCXX_USE_WCHAR_T std::wstring ws = std::format(L"{:%a | %A | %b | %B | %c" " | %C | %d | %D | %e | %F | %g | %G | %h" " | %H | %I | %j | %m | %M | %p | %r | %R" *************** test_format() *** 48,53 **** --- 49,55 ---- " | 12 | 12 | 353 | 12 | 26 | PM | 12:26:25 PM | 12:26" " | 25.708 | 12:26:25.708 | 1 | 51 | 51 | 1 | 51 | 12/19/22" " | 12:26:25 | 22 | 2022 | -0500 | EST" ); + #endif auto loc = std::locale::classic(); auto smod = std::format(loc, "{:%Ec %EC %Od %Oe %OH %OI %Om %OM %OS %Ou %OU" *************** test_format() *** 56,61 **** --- 58,72 ---- " %w %W %x %X %y %y %Y -05:00 -05:00}", zoned_time(zone, time_point_cast(t))); VERIFY( smod == s ); + + s = std::format("{}", zt); + VERIFY( s == "2022-12-19 12:26:25.708 EST" ); + s = std::format("{1:=>30}", 1, zt); + VERIFY( s == "===2022-12-19 12:26:25.708 EST" ); + #ifdef _GLIBCXX_USE_WCHAR_T + ws = std::format(L"{:+^34}", zoned_time(zone, t)); + VERIFY( ws == L"++2022-12-19 12:26:25.708000 EST++" ); + #endif } int main()